[Yeti DNS Discuss] Out-of-bailiwick glue in the root zone

["Davey(宋林健)"]

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    192.31.80.34

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.

Cheers,
Davey

> 在 2015年8月20日，12:12，Shane Kerr <shane at biigroup.cn> 写道：
> 
> All,
> 
> 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    192.31.80.34
> 
> 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... 
> 
> Cheers,
> 
> --
> Shane
> 
> 
> 
> _______________________________________________
> discuss mailing list
> discuss at lists.yeti-dns.org
> http://lists.yeti-dns.org/mailman/listinfo/discuss

---------------------------
Davey Song(宋林健)
BII Lab
ljsong at biigroup.cn



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yeti-dns.org/pipermail/discuss/attachments/20150820/8a881e61/attachment.html>