On Tue, Nov 11, 2014 at 06:14:44PM -0500, Andrew Sullivan wrote:
> But my point is that it's a different zone. Once you allow for the
> possibility that an apex record could change in this zone, why not
> change other records too?
Because that's not necessary to address the technical issue this proposal
is intended to address, and t would be undesirable for a host of other
reasons, so, you know, let's not do that.
> And who gets to control this other zone?
Same people that control the root zone now.
> It's no longer "the root zone", by definition. It's an alternative
> zone, it seems to me.
Yes, but with changes explicitly limited to the NS RRset, and not
affecting any delegation content.
Of course, this does suggest the idea of simply updating the one-and-only
root zone to contain a single additional NS record:
. IN NS [a-m].root-servers.net.
. IN NS local-root.
local-root. IN A 127.12.12.12
On a system that had a server listening and serving root at 127.12.12.12,
a recursive resolver would prefer to use it for root queries because of the
very short RTT. On a system that didn't, a few queries would be wasted to
determine that the local-root address was nonresponsive, and then the
server would carry on using the traditional roots. This is kind of a
hybrid of the Lee/Vixie and Kumari/Hoffman mechanisms: ohh lord,
kum-ba-yah. :)
For the record, I'm not comfortable with the Lee/Vixie proposal that new
root server addresses be globally routable and anycasted by anyone who
wants to, but I'd be fine with it if they were localhost addresses, as
above, or reserved nonroutable addresses similar to (but distinct from)
RFC 1918 addresses. I also think Kumari/Hoffman has most of the same
benefits at lower cost.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
