BIND 9 seems to be hiding necessary glue at the apex

[Mark Andrews]

In message <20150527153425.521d73e0 at casual>, Shane Kerr writes:
> 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.

Actually it responds correctly.  There is no requirement for a NS
query to return the addresses of the nameservers.  This includes
the root zone.  The only time when address records are required is
when you are returning a referral and the names of the nameservers
are below the current zone.

> 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.

Actually they don't.  They can go back to the sbelt and request the
addresses records.  A RFC 1035 compliant recursive server will do
this.

> 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.

NSD incorrectly promotes glue to answer.  They have been informed
of this bug in the past.  Additional records added to a NS query
to a zone's servers are answers not glue.

> ------------------------------------------------------------------------
> 
> 
> 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.

Nope.  You just go to the parent server and get a new referral.  In
the root zones case this is going to the sbelt data.

> 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
> _______________________________________________
> bind-workers mailing list
> bind-workers at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-workers
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org