i think we're about to enter a non-discuss period for scalingroot-XX, yet this message touches other topics.
> Wolfgang Nagele (AusRegistry) <mailto:wolfgang.nag...@ausregistry.com.au> > Friday, November 14, 2014 1:48 PM > Hi, > > One of my biggest concerns about the current proposal is that it seems > to suggest that AS112 works. actually, the proposal doesn't mention AS112, but my discussion of the proposal here has mentioned AS112. > > I would like to find some definition of “works” and how we come to > that conclusion. In my experience there are AS112 nodes out there that > are misconfigured in many ways (RIPE Atlas be your friend). Returning > SERVFAILs, wrong data, etc. While wrong data is safeguarded by using > DNSSEC in this proposal, malfunction is likely to occur still and can > be just as bad. because AS112 only serves in-addr for non-routable address space (as described in RFC 1918), its failures are mostly benign -- it's rare to find someone who cares that the PTR for 10.0.0.73 has some particular value. in that way AS112 is a terrible canary for the scalingroot-XX coal mine, because data failures in the root zone are extremely noticeable and important. in other words the only reason we run AS112 at all is to keep the queries out of more important servers (like the root servers or the in-addr.arpa servers), whereas we have a broader and more powerful motive to run root servers. for that same reason, i'm not very worried. failures in AS112 servers go mostly unnoticed and as a result they might not be fixed quickly or ever. failures in root name service are extremely visible and will be noticed and fixed pretty quickly. so, in a way, AS112's weakness is scalingroot-00's strength. > In the current system this issue is lessened due to the many different > operators. i think you mean that the issue is lessened due to the small number of well known highly visible operators, since in scalingroot-XX, there would be millions of operators rather than a dozen or so operators. > Within a given enterprise or ISP that would have limited impact and > one could just point the finger at them and not care (although I don’t > agree with that either). However route leaks are going to occur as > they have in the past (no-export stripping happens by accident) and > will start to have impact on users outside of that admin/routing domain. route leaks also occur for the existing root name server anycast nodes. we're not inventing new trouble here. > Assuming that local routes are always the routes that are chosen first > is a flawed assumption. Routing is integral to this proposal and > cannot be disregarded if you wanna find a workable solution. as i tried to explain in the circleid post last week... http://www.circleid.com/posts/20141107_secure_unowned_hierarchical_anycast_root_name_service_and_apologia/ ...the routing issues are integral to the proposal (as you say) and are in no way disregarded (as you ask). > > From a TLD operator perspective I think it’s a huge step backwards > that we will loose our update propagation assurance. Will I have to > rely on the RRSIG expiry as my worst case scenario for a zone update > to be fully propagated? With the sort of requirements that are put on > TLD operators and DNS operators these days that sounds completely > unacceptable path to me. It’s very different from AS112 where there is > are simple zones that are configured as master and then remain that way. my primary reason for answering this message on-list rather than privately is to ask you whether your stated concern also applies to draft-wkumari-dnsop-root-loopback? (it would seem so, in which case, that part of this thread should continue here, even while the parts related narrowly to scalingroot-XX should be paused for now.) > > ... > > In closing, this draft proposes a solution to a problem that hasn’t > been quantified and has no measure of success. Personally I think > that’s bad practice. i hope you'll make time to come to hong kong on december 8-9 to inform the discussion with your perspective. mine is: several of us have, and many of us could, construct a simple, cheap, effective method to ddos all 300+ root name servers, untraceably and unstoppably. please do the thought experiment. we can repeat it as a group "bar bof" thought experiment in hong kong if you wish. but in any case i'm going to make that harder; while no service can ever be "ddos-impossible" we can and should work toward "ddos-difficult". i pushed f-root into global anycast on the strength of m-root's pioneering early success with it. i applaud l-root's efforts. but i'm not satisfied that any number of hundreds of servers, or any number of dozens of operators, can serve the internet as it has become and as it will be. -- Paul Vixie
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
