Post by Richard HectorActually I followed up an off-list reply I got, and added
logging {
category resolver { null; };
};
to my named.conf.options - based on the suggestion that most/all of
what would be logged in that category would be stuff I can't do
anything about. Is that reasonable?
Yep. Take that out if you need to debug a really weird problem. But
yeah, most of that class of errors just tell you that there is broken
stuff on the Internet.
Post by Richard HectorIncidentally, on the subject of SOA records - either I'm confused
about the last entry, or People are Wrong on the Internet.
Most references call it 'Minimum TTL', where 'DNS & BIND' 4th ed calls
it 'Negative Caching TTL'. RFC 2038 (from 998) says the minimum ttl
usage is deprecated.
It was defined as the "minimum TTL" in RFC 1035. To quote the
scriptures, it is "the unsigned 32 bit minimum TTL field that should be
exported with any RR from this zone."
In practice, BIND did not implement this. Nobody noticed.
What they did notice was that hosts would ask for the same non-existent
data over and over without caching the fact that it wasn't there, but
because it wasn't there, there was no way to communicate how long it
should retain that fact. TTLs follow RRs; no RR, no TTL.
So RFC 2308 re-purposed the "minimum TTL" field to the "negative TTL"
field to be the "negative TTL". What that means is that an authoritative
server, on being asked for an RRset that doesn't exist, will return a
response that contains no data (and an NXDOMAIN code if the name doesn't
exist at all, or NOERROR if the name exists but not the class/type
requested), with an SOA record in the authority section. Normally, the
server will manufacture the TTL of the SOA from negative TTL field of
the SOA. For example, given:
domain. 3600 SOA primary.domain. contact.domain. 1354100330 3600
600 3600000 300
the response to does-not-exist.domain. will be:
domain. 300 SOA primary.domain. contact.domain. 1354100330 3600
600 3600000 300
the TTL coming from the SOA. On the other hand, an actual query for the
SOA will give the former record in response, because that's a real
record and has a real, not manufactured, TTL. That is, the TTL for the
SOA record is an hour, but the negative TTL is 5 minutes.
RFC 2308 states that the smaller of the SOA record's own TTL and the
negative TTL value should be sent as the TTL for a negative answer, and
it is this TTL that applies to caching of that answer. So now you can
ask for "does-not-exist.domain" as many times as you like, and your DNS
forwarder will only bother the authoritative nameservers for "domain"
about it once every five minutes.
Post by Richard HectorSo the problem is essentially that the response indicated a lame delegation
to itself?
No, the problem is that the response was "out of bailiwick", i.e. we
expected an answer that referred to the something in the zone we asked
for ("ns-os1.qq.com", and we know that from the NS records we got from
the "qq.com" nameservers), and got an answer about its parent zone
("qq.com"), which wasn't expected.
Imagine of I could answer a query to my domain with a response that (if
processed) affected further processing of a parent zone, or even the
root zone? That would be a bad thing, right? Well, that type of
behaviour is what BIND is detecting, reporting and discarding in this case.
-- don