must authority section be populated for a NOERROR response with the AA bit set?

Jonathan de Boyne Pollard J.deBoynePollard at Tesco.NET
Wed Nov 24 04:42:54 UTC 2004

IT> Can someone point me to the relevant RFC that covers this:


IT> When a nameserver authoritative for foo returns a (positive)
IT> NOERROR response for foo with the authoritative bit set,
IT> is the response required to include authority records?

No. See RFC 1034 section 4.3.1 (which comprises two of the many errors 
in that document, note, being wrongly indented and badly worded) and 
consider the type 3 examples in RFC 2308 section 2.  The inclusion of 
delegation information along with the answer is merely an optimisation, 
attempting to ensure that the delegation information in caching 
resolving proxy DNS servers does not expire, and thus that it does not 
have to be explicitly looked up again.

IT> A customer tells me that under some circumstances, a BIND 9.3.0
IT> nameserver attempting to resolve "" will produce
IT> the "multiple RRs of singleton type" error when confronted with the
IT> response above.

That's nothing to do with the "authority" section.

You are not the first person to be seeing multiple "CNAME" resource 
records for "*" domain names recently, and the problem is 
not confined to users of ISC's BIND.  Users of Microsoft's DNS server 
are seeing this as well.  Notice the TTLs of 0 seconds on the various 
"CNAME" resource records that Princeton is publishing, which is foolish 
and needless.  I have my suspicions that both softwares follow client-side 
alias chains during query resolution in the same way, and that a latent 
problem in that common mechanism is being triggered by the daft 0 second 
TTLs.  What to do when part of the client-side alias chain, that one is 
building up in a complete answer, that one has already obtained expires 
as one is looking up the remainder of the complete answer is one of the 
many things that one has to think hard about when writing a resolving 
proxy DNS server.  And it _is_ possible to get things wrong in a way 
that produces the results that you and others are seeing.  I don't have 
the time at the moment to review the code to test my suspicions, though.

More information about the bind-users mailing list