BIND 9 seems to be hiding necessary glue at the apex

Shane Kerr shane at time-travellers.org
Wed May 27 15:34:25 UTC 2015


All,

Over at the Yeti DNS project we are configuring replacement root
servers. http://yeti-dns.org/

We discovered that BIND 9 does not seem to be responding properly.

Here is part of a write-up about the issue:

------------------------------------------------------------------------

Desired Response
----------------
When a resolver is priming, it does a query to one of the root server
addresses that it knows about. This is described in this IETF draft:

https://tools.ietf.org/html/draft-ietf-dnsop-resolver-priming

You can create a query that looks like this with the "dig" command:

$ dig @a.root-servers.net -t ns +norecurse +edns +nodnssec .

The "@a.root-servers.net" can be replaced with any name or address
that serves the root zone, for example "@bii.dns-lab.net". 

The response contains the _names_ of the root servers in the answer
section:

.			518400	IN	NS	a.root-servers.net.
.			518400	IN	NS	b.root-servers.net.
  ...
.			518400	IN	NS	m.root-servers.net.

This is the list of name servers that carries the root zone.

The response carries the _addresses_ of the root servers in the
additional section:

a.root-servers.net.	518400	IN	A	198.41.0.4
b.root-servers.net.	518400	IN	A	192.228.79.201
  ...
m.root-servers.net.	518400	IN	AAAA	2001:dc3::35

The additional section data is what the resolvers need to actually
perfrom recursion.


Serving the Additional Section
------------------------------
Root zone file has:

net.                    172800  IN      NS      a.gtld-servers.net.
  ...
a.gtld-servers.net.     172800  IN      AAAA    2001:503:a83e::2:30
  ...

Because there are glue records for the "net" domain, BIND 9 will not
return the "a.root-servers.net" addresses in the additional section.

In the general case, being able to get to "net" authority servers is
enough to eventually get to "a.root-servers.net" so the IP addresses
configured in the root zone are not necessary glue.

In the case of root priming, however, we *do* want to see the
addresses for the "root-servers.net" servers. It is not technically
necessary, but resolvers expect this information.

The solution to this is to make the root servers answer for the
"root-servers.net" zone, as a sort of special case. When BIND 9 is
configured this way, it will add in glue to responses to the priming
query.

Note that NSD does not need to be configured for the
"root-servers.net" zone, and happily returns glue in the additional
section, whether configured for the "root-servers.net" zone or not.

------------------------------------------------------------------------


We would like to avoid the case where the root servers have to be
authoritative for "root-servers.net" in order to return the proper
glue. (We are planning on having root servers that fall under different
domains, and do not want to have the root servers authoritative for all
of them.)


Paul Vixie pointed out that this is actually not just a root problem in
particular, but probably affects any zone where the apex NS contains
names that have been delegated.


I am not sure, but I think this is an artifact of how the rbtdb works
now. I can poke around in the code to try to get it to return glue in
this case, but I'd like to discuss it with the BIND 9 team to see if
this is going to get rejected out of hand before I spend a day or two
trying to jawbone the code into submission. (Even better if someone
could just say "oh yeah here's the one line fix for this".) ;)


So... would a change to include glue for apex NS names that have been
delegated likely be accepted or not? We're pretty sure this would be the
correct behavior, although of course I am always willing to be
convinced otherwise.

Cheers,

--
Shane


More information about the bind-workers mailing list