On 29/11/12 19:58, Richard Hector wrote:
Actually 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.
Incidentally, 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. On 29/11/12 17:40, Martin D Kealey wrote:
So 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