> Evan Hunt <mailto:e...@isc.org> > Friday, November 14, 2014 10:33 AM > > ... > > I believe there's more scope for an incompetent or malicious root server > operator to block, surveil, or deceive me, and while there are defenses I > can deploy against some misbehaviors, I think we need to be cautious about > about a potential increase in the number of bad actors and failure modes.
because the global routing table is fundamentally insecure, such that more or less anybody can announce more or less anything, where the announcements may not be long lived nor widely propagated, i think you're already facing and living in the dangerous situation that you're saying scalingroot-00 presents. the merits of this proposal should be judged on engineering economics and risk management: what's the average and worst case and best case if we adopt, vs. what's the average and worst case and best case if we don't? i estimate that more traffic goes awry or undeliverable in today's 13-server internet than will be so under this million-server proposal, and that the delta will trend upward with topological density and complexity. > ... > While I don't particularly share Andrew's > camel's-nose-on-the-slippery-slope > concerns about a root zone with a modified NS rrset, if I were going > to use > it myself, it would *only* be because I was deploying a local root > instance > on my own network or on the local host. If I weren't going to deploy it > myself, then I'd stick to the traditional roots. I may not be typical > in that respect, but if I am, then there's no need for unowned anycast > anyway. those words are very insightful. because either the vixie/lee -or- the kumari/hoffman proposal requires changes to each participating RDNS to "opt-in" to the proposed method, the difference is in the scope of those changes (add forwarding logic, add a loopback stealth root server; or, change your root hints), i believe that the scalingroot-XX (-01 should come out before december 8's hong kong workshop) should advise participating RDNS operators to gauge the reliability and attack resilience of their coreward Internet routing path, and consider operating their own "unowned anycast" instances locally if they lack full trust or accountability with their upstreams. vixie -- Paul Vixie
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
