> John Levine <mailto:jo...@taugh.com> > Sunday, November 09, 2014 2:57 PM > > As I understand it, the proposal is to add another root server, the > "X" root, with A and AAAA records pointing at addresses that will > never be globally routed, with an invitation to networks of whatever > size to provide a root running on those addresses visible to hosts on > their own network.
no. nothing like that. i had no idea that the scalingroot-00 draft was that hard to understand. you have completely misunderstood the real intent, but, that misunderstanding is almost certainly the fault of the draft authors. > > Other than "it would be wrong", what's the practical difference > between that and just running your own server at the addresses of, > say, the B root? The routes should only be in your own network, and > shouldn't be exported to anyone else, so if BGP signatures make other > people reject your route, that's a feature. This hack of course has > the advantage that you can do it right now. we intend that iana craft a second root zone, published in parallel with the existing one, each being synchronized in terms of tld content, and each signed with the then-current iana signing key. the second one will only have two NS RR's at its apex, not thirteen. those two NS RR's will each point to one A and one AAAA, in disparite /24's and /48's. so, four new routing slots will be consumed by this proposal. the networks having these new IPv4 and IPv6 addresses will be routed globally by anyone who cares to, for example by the existing root name servers. they can also be routed non-globally by anyone who cares to, for example into the loopback network of an RDNS server, or into a LAN via its exit gateway, or into a campus or ISP or region using no-export routing advertisements. RDNS operators who want this "alternative IANA root zone" will have to change their root hints, and will be strongly advised to only do this if they have DNSSEC validation and root key rollover support. hopefully that's easier to understand than the draft, or the circleid article, and i take full responsibility for the in-clarity of both. -- Paul Vixie
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
