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

Mark_Andrews at isc.org Mark_Andrews at isc.org
Sat Oct 20 06:17:15 UTC 2001


> 
> > 
> > On Fri, 19 Oct 2001, R. Scott Perry wrote:
> > 
> <snip>
> > > >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
> >             zone.
> > 
> >             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.
> > 
> > Brian
> 
> 
> Regardless of which behavior is correct, my BIND 9.2.0rc7 gives SERVFAIL
> when asked for NS records of declude.info. To me that says there's a bug in
> BIND 9.2.0rc7 or the Nominum TLD servers or the declude.info data.
> 
> napa 36 #dig txt chaos version.bind
> 
> ; <<>> DiG 9.2.0rc7 <<>> txt chaos version.bind
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13781
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;version.bind.                  CH      TXT
> 
> ;; ANSWER SECTION:
> version.bind.           0       CH      TXT     "9.2.0rc7"
> 
> ;; Query time: 5 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Fri Oct 19 20:49:29 2001
> ;; MSG SIZE  rcvd: 51
> 
> napa 37 #dig ns declude.info
> 
> ; <<>> DiG 9.2.0rc7 <<>> ns declude.info
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 34440
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;declude.info.                  IN      NS
> 
> ;; Query time: 75 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Fri Oct 19 20:49:37 2001
> ;; MSG SIZE  rcvd: 30
> 

	Nothing wrong here.  The nameservers for declude.info are lame
	and your nameserver cannot get authoritative answers.  Now if you
	make a non-recursive query you will see that your server knows
	where to get the answers from.

	Note the NS records in the info server are *glue* records.  Glue
	records should not be returned in the answer section.

	Mark

; <<>> DiG 8.3 <<>> +norec declude.info ns 
;; res options: init defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1344
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
;; QUERY SECTION:
;;	declude.info, type = NS, class = IN

;; AUTHORITY SECTION:
declude.info.		23h57m54s IN NS  udns2.ultradns.net.
declude.info.		23h57m54s IN NS  udns1.ultradns.net.

;; ADDITIONAL SECTION:
udns1.ultradns.net.	1d23h57m54s IN A  204.69.234.1
udns2.ultradns.net.	1d23h57m55s IN A  204.74.101.1

;; Total query time: 2 msec
;; FROM: drugs.dv.isc.org to SERVER: default -- 127.0.0.1
;; WHEN: Sat Oct 20 16:08:27 2001
;; MSG SIZE  sent: 30  rcvd: 114

--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at isc.org


More information about the bind-users mailing list