about AUTHORITY SECTION

Chris Buxton chris.p.buxton at gmail.com
Fri Jul 8 07:04:35 UTC 2011


On Jul 7, 2011, at 6:32 PM, Feng He wrote:
> 2011/7/8 Kevin Darcy <kcd at chrysler.com>:
>> I think it's worth emphasizing that in the first case, the contents of the
>> Authority Section were *mandatory* (see RFC 2308, Negative Caching), whereas
>> in the second case the authoritative nameserver was *optionally* providing
>> NS records in the Authority Section. It could have legally left the
>> Authority Section completely empty, and in fact many load-balancers,
>> pretending (to various degrees of competence) to be authoritative
>> nameservers, will give responses that look like that.
>> 
> 
> In the second case I think the NS records should be there in the
> Authority Section.
> Consider this case:
> 
> example.com.  IN   NS    dns.example.com.
> l2.example.com.  IN  NS   dns.example.com.
> l3.l2.example.com.  IN  NS   dns.example.com.
> 
> When a query for example, dig l3.l2.example.com @dns.example.com, the
> nameserver answser without the Authority Section, then the client
> won't know the answer is in which authority zone.

While that is correct, it is also unimportant. Everything will work as expected if the resolver never finds that out. Ditto if the resolver does discover it.

As for Kevin's assertion that the SOA record in the authority section is required for a negative response, this is also incorrect. RFC 2308 is a proposed standard, not a standard. Further, section 8 of this RFC does not say explicitly that an SOA must be included in a negative response, only that it must be cached (presumably only if present). We might ask the author, Mark Andrews, for clarification of this point.

RFCs 1034 and 1035 permit a negative answer with no content in the authority section; all modern name servers should handle this correctly. While this prevents caching of the negative answer, it should still be treated as a final negative answer to the query being worked on.

Regards,
Chris Buxton
BlueCat Networks


More information about the bind-users mailing list