David Conrad wrote: > Ed, > > On Nov 27, 2013, at 6:00 AM, Edward Lewis <ed.le...@neustar.biz> wrote: > > My excuse is - operators limit "the effort expended in fighting entropy." > > Imagine an average operations environment operating as most environments go. > > ... > > Eventually one day something breaks and then... .... ...include here "the > > only one who can fix it has left." > > I suspect this argument applies _far_ more to configuring/operating DNSSEC > than it does to slaving the root zone, particularly when you take into > account the rolling of the root key. For one thing, consider the time > intervals between change events that might cause problems. > > > I'd argue that the resolver admin is also incentivized to do a good or > > better job too. Joe's right in general, > > Actually, he isn't... :) > > Slaving a zone is not (or perhaps should not be, despite BIND configuration > language) rocket science. Hand wringing about poor resolver operators being > unable to master the complexities feels like the "don't look behind the > curtain" scene of the Wizard of Oz.
i'm curious as to exactly what this root zone slaved resolver configuration looks like and how it would behave. i don't believe i've ever set up a resolver like that before. if i understand things right, this config could only be achieved with particular resolver implementations that combine authoritative and recursive service into the same server, and the only implementation i know of that does that is BIND 9. i believe unbound, powerdns, BIND 10, djbdns, etc. are all either recursive only, or split recursive and authoritative service into separate daemons, afaik. but i'm not familiar with any of the closed source implementations. if such a config is possible, how is it supposed to work with DNSSEC? if the DNS server loads a bad copy of the root zone somehow during an AXFR, does it use its configured root trust anchor to determine that its copy of the zone doesn't validate, or does the act of configuring the root zone as an authoritative zone make it more trustworthy, thus overriding the need to do DNSSEC validation at the root level? > The root represents one of the few single points of failure on the Internet. > Continued reliance on that single point of failure, particularly in the days > of multi-hundred of gigabit DoS attack at the flip of a switch potential, is > ... questionable. Given the lack of ability for the Internet operations > community to effectively deploy BCP 38, I anticipate this situation to only > get worse. Arguments along the lines of "but anycast!" don't really help > when the root instances you get routed to have fallen over due to the latest > DoS attack. Yes, the system as a whole can still be said to be responsive, > but you're SOL. > > I would agree that existing resolver technology makes it more challenging > than it should be to decentralize the root. Fixing that is long overdue IMHO. well, here's a crazy idea: now that the root zone is signed, add a 14th root letter, and allow AS112-style service for this new root's service addresses. that way a local network could serve the root zone locally (not announcing the service prefixes to any of its peers or upstreams), and thus would still have at least one root server available in the case of a catastrophe, and it wouldn't be dependent on any implementation specifics or even configuration settings in the recursive DNS server in order to achieve. it would require building a resilient AXFR network apart from the current root operators, though, as well as a set of public operators to backstop the service prefixes to serve networks that don't have local instances. -- Robert Edmonds _______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
