Queries of type NS have answers in Authority Section

[Ladislav Vobr]

barry, I have noticed it many times, bind later than 8.3.4 show the glue 
data in the authority section, and these are being cached by recursive 
servers as a *glue* credibility, bind versions before show it in the 
answer sections, and thus other recursive servers cache it as *answer* 
credibility and providing it to +norec and +rec clients as a final 
answer.... very very weird to me too.

whole internet is not sure about what is *answer* and what *glue* and 
recursive servers refuse to show it even with the +norec, root servers 
as well some are 8.3.4 some are later, showing different things.


8.3.4
# dig ns ladislav.name.ae

; <<>> DiG 8.3 <<>> ns ladislav.name.ae
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2
;; flags: qr rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 5
;; QUERY SECTION:
;;      ladislav.name.ae, type = NS, class = IN

;; ANSWER SECTION:
ladislav.name.ae.       3H IN NS        fake2.ladislav.name.ae.
ladislav.name.ae.       3H IN NS        fake3.ladislav.name.ae.
ladislav.name.ae.       3H IN NS        fake4.ladislav.name.ae.
ladislav.name.ae.       3H IN NS        fake5.ladislav.name.ae.
ladislav.name.ae.       3H IN NS        fake1.ladislav.name.ae.

;; ADDITIONAL SECTION:
fake2.ladislav.name.ae.  3H IN A  10.2.2.2
fake3.ladislav.name.ae.  3H IN A  10.3.3.3
fake4.ladislav.name.ae.  3H IN A  10.4.4.4
fake5.ladislav.name.ae.  3H IN A  10.5.5.5
fake1.ladislav.name.ae.  3H IN A  10.1.1.1

;; Total query time: 8 msec
;; FROM: auhnic1 to SERVER: default -- 127.0.0.1
;; WHEN: Wed Sep  1 10:01:32 2004
;; MSG SIZE  sent: 34  rcvd: 214


9.2.2
# dig ns ladislav.name.ae +norec

; <<>> DiG 9.2.2 <<>> ns ladislav.name.ae +norec
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54766
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 8

;; QUESTION SECTION:
;ladislav.name.ae.              IN      NS

;; AUTHORITY SECTION:
ae.                     24847   IN      NS      SEC3.APNIC.NET.
ae.                     24847   IN      NS      NS-EXT.VIX.COM.
ae.                     24847   IN      NS      NS.RIPE.NET.
ae.                     24847   IN      NS      NS1.UAENIC.ae.
ae.                     24847   IN      NS      NS2.UAENIC.ae.

;; ADDITIONAL SECTION:
SEC3.APNIC.NET.         12309   IN      A       202.12.28.140
SEC3.APNIC.NET.         1954    IN      AAAA    2001:dc0:1:0:4777::140
NS-EXT.VIX.COM.         12309   IN      A       204.152.184.64
NS-EXT.VIX.COM.         1662    IN      AAAA    2001:4f8:0:2::13
NS.RIPE.NET.            12310   IN      AAAA    2001:610:240:0:53::193
NS.RIPE.NET.            15062   IN      A       193.0.0.193
NS1.UAENIC.ae.          1572    IN      A       213.42.0.226
NS2.UAENIC.ae.          7042    IN      A       195.229.0.186

;; Query time: 1 msec
;; SERVER: 213.42.20.20#53(213.42.20.20)
;; WHEN: Wed Sep  1 09:46:54 2004
;; MSG SIZE  rcvd: 319




Barry Margolin wrote:
> I've been trying to troubleshoot a problem that one of my customers is 
> having resolving a .gov domain.  I noticed that when you query the 
> authoritative servers for .gov for the NS records of a 2nd-level domain, 
> it puts the answers in the Authority section rather than the Answer 
> section:
> 
> $ dig whitehouse.gov ns @a.gov.zoneedit.com +norec
> 
> ; <<>> DiG 9.2.2 <<>> whitehouse.gov ns @a.gov.zoneedit.com +norec
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29041
> ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;whitehouse.gov.        IN NS
> 
> ;; AUTHORITY SECTION:
> whitehouse.gov.      10800 IN NS NS1-AUTH.SPRINTLINK.NET.
> whitehouse.gov.      10800 IN NS NS2-AUTH.SPRINTLINK.NET.
> whitehouse.gov.      10800 IN NS NS3-AUTH.SPRINTLINK.NET.
> 
> I'm not sure yet if this is what is actually causing my customer's 
> problem, but it also confuses dnsreport.com.  I've had to depend on this 
> site lately because at work I'm behind firewalls that make it difficult 
> for me to do direct DNS queries out to the Internet (I've got to take 
> this up with my management -- my DNS expertise is one of the reasons 
> they hired me).
>