[Yeti DNS Discuss] 答复: One funny naming scheme for root name servers, to test

[Davey Song(宋林健)]

Actually It is discussed as one possible proposal in one RRSAC Caucus
document about naming scheme for root server. I quote the analysis of this
naming scheme in that document as follows : 

Instead of having individual names for each root server, the set of root
servers could be given one name (such as “rt-all”) and that one name has
the 13 IPv4 addresses and (currently) 11 IPv6 addresses of the root servers
as RRsets. The new zone would be administered by either IANA or some other
entity.

Possible advantages of this scheme are:
* All data for the root servers is in exactly one place.
* The priming data is always accessible unless all of the root servers are
down.
* No synchronization is needed with other zones (such as what is needed for
the current naming scheme).
* The names and the addresses in the response to a priming query are
entirely protected by DNSSEC.
* Authentication of priming query responses requires only a single key.
There are no additional DS records or additional keys for subordinate zones.
* It is syntactically elegant because the zone is clearly authoritative for
its own name servers. There is no ambiguity where the content could be
found.

Possible drawbacks of this scheme are:
* This abandons the current lettering scheme, making discussions of
individual root server operators difficult.
* The process of deciding who administers the new zone could be contentious.
* The size of the response for a query that requests DNSSEC information
would be significantly increased because it will include 26 RRSIG records
(for the A and AAAA records) in the Additional section of the response.
* There will be possible name collisions from search lists (similar to the
possibility of name collisions that happen any time a new TLD is added to
the root zone) for this one name.


Actually we are preparing the naming scheme like bii.yeti-dn, wide.yeti-dns
with a non-delegated TLD in Lab test phase.

Davey
-----邮件原件-----
发件人: discuss [mailto:discuss-bounces at lists.yeti-dns.org] 代表 Stephane
Bortzmeyer
发送时间: 2016年4月7日 2:51
收件人: discuss at lists.yeti-dns.org
主题: [Yeti DNS Discuss] One funny naming scheme for root name servers, to
test

Suggestion from Paul Hoffman: use just one name, and one IP address per
server. So, for instance:

.             IN    NS     the-real-and-only.root.
the-real-and-only.root.  IN AAAA 240c:f:1:22::6
                         IN AAAA 2a01:4f8:161:6106:1::10
                         IN AAAA 2001:e30:1c1e:1::333
                         IN AAAA 2a02:ec0:200::1
                         IN AAAA 2001:4b98:dc2:45:216:3eff:fe4b:8c5b
                         IN AAAA 2001:67c:217c:6::2
                         IN AAAA 2a02:2810:0:405::250
                         IN AAAA 2001:6d0:6d06::53
                         IN AAAA 2001:1398:1:21::8001
                         IN AAAA 2001:559:8000::6
                         IN AAAA 2001:200:1d9::35
                         IN AAAA 2604:6600:2000:11::4854:a010
                         IN AAAA 2001:620:0:ff::29
                         IN AAAA 2a02:cdc5:9715:0:185:5:203:53
                         IN AAAA 2001:1608:10:167:32e::53

In theory, it should work because RFC 1034 is crystal-clear: "[in case of
failure] The client should try other servers and server addresses before
repeating a query to a specific address of a server." So, the client, the
resolver, will try all the IP *addresses* of the-real-and-only.root before
giving in.

On the other hand, not every implementer reads the RFC and some resolvers
will try only other *names* and thus failed the first time they will
encounter a problem.

A good way to test it would be to add deliberately unreachable addresses to
the above set.
_______________________________________________
discuss mailing list
discuss at lists.yeti-dns.org
http://lists.yeti-dns.org/mailman/listinfo/discuss