BIND 9 seems to be hiding necessary glue at the apex
paul at redbarn.org
Sat May 30 10:21:51 UTC 2015
Mark Andrews wrote:
> In message <20150527153425.521d73e0 at casual>, Shane Kerr writes:
>> 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.
your answer, while technically correct, misses the point.
in the bind4/bind8 era, when root name servers had names like
ns.isc.org, the addresses of these name servers were published as part
of the root zone, and returned with priming responses. you are certainly
correct that this was not necessary, and that any recursive server
hearing such a response would have been capable of reusing its hint data
to reach the root name servers a second time in order to get told where
ORG was, who could then tell us where ISC.ORG was, who could then tell
us the address of NS.ISC.ORG. you should recall that i added that "glue
chase" logic to an early version of bind8, and the result was a
devastating self-inflicted DDoS against the root name servers.
in the bind9 era, root name servers are all under a common parent
(root-servers.org), and each root name server makes itself a secondary
of that zone. the result is that addresses are returned with the
priming-query result. i do not believe that this confluence is necessary
therefore i am asking for a feature change whereby if a zone contains
below-zone-cut AAAA or A rrsets which are referenced by any NS RR in the
zone (whether apex or not), it is both transferred in AXFR and served as
glue. any zone operator who does not want this behaviour can simply
avoid adding their "glue" AAAA and/or A RRsets to their zone.
i don't want to have to switch to a non-BIND9 server just to get the
behaviour i'm describing.
i am willing to commission a patch and contribute that patch to ISC if
that would help at all.
More information about the bind-workers