[Yeti DNS Discuss] Out-of-bailiwick glue in the root zone
ljsong at biigroup.cn
Thu Aug 20 07:14:44 UTC 2015
I would like to supplement some background and discussions for some people
who may first join us.
The Yeti modification from IANA
When Yeti DNS project firstly conceived, it has complete fealty to IANA as the DNS
name space manager. All IANA top-level domain names will be precisely expressed
in the Yeti DNS system, including all TLD data and meta-data. To make Yeti testbed
run, we do have some modification from IANA root zone file to yeti root zone file.
The detailed modification we document in https://github.com/BII-Lab/Yeti-Project/blob <https://github.com/BII-Lab/Yeti-Project/blob>
/master/doc/Yeti-DM-Setup.md#modifications <https://github.com/BII-Lab/Yeti-Project/blob/master/doc/Yeti-DM-Setup.md#modifications>. One of the major modifications from
current IANA root zone is that we replace the NS records [a-m].root- <http://root-servers.org/>servers.org <http://root-servers.org/>
with yeti root servers;
Note that that IANA root servers are not only authoritative for root zone , but also
root-server.net <http://root-server.net/> and .arpa (performance consideration or historical reason). In Yeti,
there is no requirement to server root-server.net <http://root-server.net/> by yeti server because we do not
require a special unified domain format for our root server. In addition, we regard
.arpa as a kind of TLD like .com and .net. So we have a consensus that Yeti servers
are aimed only to serve root zone. Just recently, Yeti DMs cease to edit the .arpa
NS RRset in the root zone in each DM and ask the operator to remove ARPA zone
from their server.
The observation and discussion
This .arpa recovery process triggered a bug finding existing in Knot server who dose
not return the right extra A&AAAA information of .arpa even after root zone update.
Anyone who are interested with this finds please trace the thread “ A weird behavior of
Knot “ in this mailing list. But this is not the observation and discussion I want to
introduce and explore here.
After ceasing the modification of .arpa NS Record, when people dig ns query for .arpa against each
yeti root server, some root server return the extra A&AAAA address of [a-m].root-servers.net <http://root-servers.net/>
in the additional section, but some don’t. I traced that inconsistency, and found it is due to that
one of our DM produce a zone file with [a-m].root-servers.org <http://root-servers.org/> as .arpa’s ns records but without
A&AAAA records. So there comes up with two questions :
1) Is there any criteria whether to contain A&AAAA RRset of NS domain for TLD/ccTLD?
2) How should Yeti do for .arpa’s ns servers [a-m].root-servers.org <http://root-servers.org/> ?
Most of us (Yeti coordinators) hold the view that only necessary glue (needed to avoid loops) should be
included in the root zone. That is to say, we should not add the A&AAAA address of [a-m].root-servers.net <http://root-servers.net/>
into the Yeti zone file. but we still found many cases that IANA’s root zone file contain such non-glue
records, such as:
abb. 172800 IN NS d5.nstld.com.
d5.nstld.com. 172800 IN A 126.96.36.199
The coordinators finally decide until IANA makes this change, or Yeti decides to have an experiment
involving this change, we have no policy which would allow us to edit
the IANA root zone content in this way.
> 在 2015年8月20日，12:12，Shane Kerr <shane at biigroup.cn> 写道：
> We had a brief discussion about some records in the root zone amongst
> the coordinators, but I wanted to ask about it here.
> The root zone has a bunch of out-of-bailiwick glue (also called
> "optional glue" some places).
> Davey found this example (there are many more):
> abb. 172800 IN NS d5.nstld.com.
> d5.nstld.com. 172800 IN A 188.8.131.52
> d5.nstld.com is under the .COM domain, and it is not glue for the .COM
> domain itself. As I understand it, a careful resolver will ignore
> this to avoid possibly corrupting its cache.
> So my question is... what is the purpose of these records? Is it just
> historical? Or is it an artifact of the IANA zone generation process
> where they include these records "just in case"? Or concern about
> resolvers that somehow don't get out-of-bailiwick NS records properly
> (which really won't work at all)?
> There may be a rule about being allowed to use these responses in the
> context of resolving a single name, as long as these IP addresses are
> not added to a cache... I don't know. The data is not signed by DNSSEC
> so I don't see how it can be trusted (an attacker can modify a reply
> with a signed ANSWER section and change the ADDITIONAL section freely).
> I'm thinking we should run an experiment where the Yeti root servers
> use "minimal-responses" or the equivalent to see if it works, and
> possibly a follow-up experiment where we actually remove this
> unnecessary glue from the Yeti root zone itself...
> discuss mailing list
> discuss at lists.yeti-dns.org
ljsong at biigroup.cn
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the discuss