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. Correct.
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. Agree on the technical nature of AS112 and that it goes largely unnoticed. That’s why I don’t like the notion of drawing conclusions that scalingroot-XX might work based on AS112 experience. It’s flawed. 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. No, in case that K-root (sorry guys ;)) has a failure it is less likely that L-root has one as well. In the case of scalingroot-XX propagated failures due to a single operator are higher. 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. Now at least I know who to contact. See the issues with the root instances in Beijing and how quickly the could be resolved once noticed. 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). Good. Thanks. 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.) Yes it applies the same way to Warren’s draft. 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. I would be happy to help with work to quantify the problem. As said, I think there are more ways to go about this and it seems that the “I want my own root server” is taking centre stage without there necessarily being a need for that. 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. Many tales to tell ...
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
