Fwd: .info root servers responding in authority section, not answer section?

Brian Wellington Brian.Wellington at nominum.com
Sat Oct 20 03:23:25 UTC 2001

On Fri, 19 Oct 2001, R. Scott Perry wrote:

> >We have a web site that runs tests on domain names (
> >http://www.dnsreport.com ), to check for some obvious DNS problems with
> >domains.  It is not working properly with the .info domains.  The problem
> >is that the root servers for .info (tld1.nominum.com and tld2.nominum.com)
> >are answering NS queries for .info domains with 0 answers, placing the NS
> >records in the authority section.  The DNS engine we use will report this
> >as a "does not exist" condition.  The root servers for other TLDs will list
> >the NS records in the answer section (with corresponding A records in the
> >additional section).
> >
> >For example:
> >
> >Looking up the NS record for declude.com at a.gtld-servers.net returns 2
> >answers (the NS records) and 2 additional records (the A records for the
> >two nameservers in the answer section).
> >
> >Looking up the NS record for declude.info at tld1.nominum.com returns 0
> >answers, and the 2 NS records in the authority section.
> >
> >Are both types of responses correct?  Why the inconsistency?  I checked a
> >few RFCs (1034/1035/2181) and wasn't able to figure out what section covers
> >this.

This answer is correct.  From RFC 1034, section 4.3.2, bullet 3:

         b. If a match would take us out of the authoritative data,
            we have a referral.  This happens when we encounter a
            node with NS RRs marking cuts along the bottom of a

            Copy the NS RRs for the subzone into the authority
            section of the reply.  Put whatever addresses are
            available into the additional section, using glue RRs
            if the addresses are not available from authoritative
            data or the cache.  Go to step 4.

The server running on these machines is correctly returning a referral.
Note also that BIND 9 has the same behavior.  BIND 8 returns NS records in
the answer section, which is incorrect behavior.


More information about the bind-users mailing list