[Yeti DNS Discuss] 转发: BIND 9 seems to be hiding necessary glue at the apex

Davey Song (宋林健) ljsong at biigroup.cn
Fri May 29 07:19:31 UTC 2015


FYI

-----邮件原件-----
发件人: bind-workers-bounces at lists.isc.org
[mailto:bind-workers-bounces at lists.isc.org] 代表 Mark Andrews
发送时间: 2015年5月28日 11:54
收件人: Shane Kerr
抄送: bind-workers at isc.org
主题: Re: BIND 9 seems to be hiding necessary glue at the apex


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
_______________________________________________
bind-workers mailing list
bind-workers at lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-workers





More information about the discuss mailing list