Glue Records for TLDs

Stefan Probst stefan.probst at opticom.v-nam.net
Sun Jul 30 08:25:41 UTC 2000


Dear Everybody,

thanks for your patience!

The public education of Stefan continues ...
(With some others lurking probably ;-)  )

I combine here again some posts, in order not to split the thread too
much.
Thanks for all the others who answered, but are not mentioned here...


On 28 Jul 2000 21:22:52 -0700, I wrote:
-------------------------
>
> Dear all,
>
> according to my little understanding, you need "glue records" in the
> parent's zone, if you want an authoritative NS having a host name inside
> the domain it is serving:
> 
> subdomain     IN NS ns.subdomain.domain.com. ; NS inside subdomain
> ns.subdomain  IN A  x.x.x.x                  ; that's the glue record
(?)

At 18:43 29.07.00 +0100, James Raftery wrote:
-------------------------
> Yep - exactly right.

Thanks, James! A little "yep" encourages every pupil ;-)

I continued:
-------------------------
> On the other side, the root servers are not authoritative (or something
> like that), but are always only referring to another name servers, which
> might mean, that they do not have "glue records".

At 14:12 29.07.00 GMT, Jesper Skriver answered:
-------------------------
> They do have glue records for the RR's that need it.
> 
> Your misunderstanding probably comes from the fact that the root servers
> (normally) doesn't serve second level domains.

Knowing now, that I was wrong, I tried to back-trace my misunderstanding.
I thought, that a name server would give authoritative answers for every
record in its zone file. Obviously wrong. Authoritative answers are given
for all (?) records, except NS records which delegate a subdomain to
another name server:

If there are records

host.domain.com    IN A  x.x.x.x
sub.domain.com     IN NS ns.servers.com

and I queried for "host.domain.com" I would get an authoritative answer,
but not when querrying for "sub.domain.com".
This applied to the root servers: Nobody would in real-life (except tests)
ask a root server for the root. Usually they are asked for a TLD, and then
- since TLDs are delegated - an unauthoritative answer is returned. (OK, I
know, that some servers in the domain "root-servers.net" are also
authoritative for a few ccTLDs and gTLDs). So, in real-life situation you
would never get an authoritative answer from them, but always be forwarded
to another server. I think this is what they meant, when I read something
somewhere, that you don't get an authoritative answer from a root server.

About the glue records in the root: I remember only the entries for
delegating NS records in NetSol's web-interface, therefore I assumed that
no other entries are possible.

Eric Hall (thanks, Eric!) wrote to me:
-------------------------
> IANA currently manages the ccTLD delegation data. There are some notes
> on http://www.iana.org/cctld/cctld.htm with links to a form that has to
> be filled out and e-mailed to them (it's near the bottom of the page).

This finally clarified everything - - - I thought, until I looked at the
example below:

At 11:23 29.07.00 +0300, Thor Kottelin wrote:
------------------------
> They [the root servers] are authoritative for the root zone,
> and they do include glue records for their subdomains.
> This is a piece of the root zone:
> 
> fi                      172800	NS	hydra.helsinki.fi
> hydra.helsinki.fi       172800	A	128.214.4.29
> fi                      172800	NS	r2d2.jvnc.net
> r2d2.jvnc.net           172800	A	128.121.50.2
> fi                      172800	NS	ns.eu.net
> ns.eu.net               172800	A	192.16.202.11
> fi                      172800	NS	ns.tele.fi
> ns.tele.fi              172800	A	193.210.18.18
> ns.tele.fi              172800	A	193.210.19.19
> fi                      172800	NS	prifi.eunet.fi
> prifi.eunet.fi          172800	A	193.66.1.146
> fi                      172800	NS	ns.uu.net
> ns.uu.net               172800	A	137.39.1.3

I tried a.root-servers.net to query for "hydra.helsinki.fi.".

nslookup: non-authoritative answer:
> set q=a
> hydra.helsinki.fi.
Server:  a.root-servers.net
Address:  198.41.0.4

Non-authoritative answer:
Name:    hydra.helsinki.fi
Address:  128.214.4.29

dig:
starserver% dig @a.root-servers.net. hydra.helsinki.fi.

; <<>> DiG 8.2 <<>> @a.root-servers.net. hydra.helsinki.fi. 
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 7
         ^^^^^^^^ the missing "aa" flag indicates that the answer
                  is non-authoritative (?)

;; QUERY SECTION:
;;      hydra.helsinki.fi, type = A, class = IN

;; ANSWER SECTION:
hydra.helsinki.fi.      2D IN A         128.214.4.29

;; AUTHORITY SECTION:
FI.                     2D IN NS        hydra.helsinki.fi.
FI.                     2D IN NS        NS.EU.NET.
FI.                     2D IN NS        NS.TELE.FI.
FI.                     2D IN NS        PRIFI.EUNET.FI.
FI.                     2D IN NS        NS.UU.NET.
FI.                     2D IN NS        T.NS.VERIO.NET.

;; ADDITIONAL SECTION:
hydra.helsinki.fi.      2D IN A         128.214.4.29
NS.EU.NET.              2D IN A         192.16.202.11
NS.TELE.FI.             2D IN A         193.210.18.18
NS.TELE.FI.             2D IN A         193.210.19.19
PRIFI.EUNET.FI.         2D IN A         193.66.1.146
NS.UU.NET.              2D IN A         137.39.1.3
T.NS.VERIO.NET.         2D IN A         192.67.14.16

If "hydra.helsinki.fi." has a glue record (A record) in the root, then
there should be an authoritative answer, or not?

But then I remembered, what Eric wrote:
-------------------------
> Think of glue data as being static cache entries

Since cache entries are returned as "non-authoritative", this would
explain, why the root server's answer for "hydra.helsinki.fi." was
non-authoritative.
(and one more reason why i had the misunderstanding about the
non-authoritative root servers)

But since there is an A record for it in the root zone, the answer would
always be given, independent of the name servers for the "fi." or
"helsinki.fi." domain.

If glue records are "static cache entries" and therefore no authoritative
answers can be obtained (?), how can I check, whether the glue record is
really there? In other words: How can I know, that the non-authoritative
answer for "hydra.helsinki.fi." which I get from a root server is really
from a glue record in the root zone and not from an A record in the fi.
zone on any of the authoritative servers of the "fi." domain? Do I need to
exclude/prohibit recursion when asking the root server?

Is this understanding already sufficient for first grade in DNS
Kindergarten, or do I need some more baby sitting? ;-)



In subdued expectation of your next lesson... ;-)

Stefan






More information about the bind-users mailing list