[RFCI-Discuss] Interesting Question

[Alex van den Bogaerdt]

On Sun, Dec 04, 2005 at 01:39:41PM -0800, Derek J. Balling wrote:

> Ponder the output of something like, a.root-servers.net:

which are, according to their name, responsible for the root.

> $ dig @a.root-servers.net megacity.org ns

You are asking for a domain not being a direct child of the
top level.

A zone cut is the place where a new zone is formed.  In this example,
it is the "org." zone which is a zone of its own.

NS records in the root zone are NOT authoritative answers because
those records exist as glue only.  For authoritative answers you'd
have to ask one of the authoritative nameservers for "org.".

> Similarly, if I was to query ultradns:
> 
> $ dig @tld1.ultradns.net megacity.org ns

"megacity.org." is a zone of its own.  Again, the server you
queried has no authoritative knowledge.

> Why is it, then, that if I was to query gtld-servers.net servers,  
> looking for a .com domain, I get something completely different?

> $ dig @a.gtld-servers.net yahoo.com ns

> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43866
> ;; flags: qr rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 5

I'm not sure if this is correct or not.  The answer you got is not
authoritative.  That is correct, as the name server records are
a property of its child zone.  It's only the missing authority
that bites you.  The server does have knowledge on the RR you
queried it for, and did try to help you by presenting it to you.

Interestingly, when you query "dig @a.gtld-servers.net yahoo.com" it
does work as expected:

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15110
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 5

probably because the gtld server does not have an A record but does
know first hand where to get it.

> .... as near as I can tell this is the absolute *worst* condition  
> possible, or should be from my understanding of the DNS results:
> 
> (a) the "aa" flag is not set. The answer is not considered  
> authoritative.
> (b) there are "0" authority records sent. No direction is given as to  
> where one might find an authoritative answer

<grin> and there your script failed.  Life sucks. 

> And, bonus points to anyone except Ralf or Phil Kizer who can guess  
> why I noticed this discrepancy....

You are writing a script that follows the path from the root down to
the authoritative server, and it failed.  I hope the implied workaround
I presented above does help.

Alex