Patrik, On Jul 7, 2014, at 10:02 PM, Patrik Fältström <[email protected]> wrote: >> The main argument against slaving the root I've seen appears to me to be >> FUD: "people running resolvers are too stupid to configure slaving the root >> correctly so root data will go stale!" (paraphrased). > > I am a bit disappointed that you David do summarize the arguments against > this proposal in this way.
Sorry to disappoint you by stating how the main arguments against the draft appear to me. > What I have recommended Warren to do is to properly list the arguments, make > a proper analysis (an attack tree would be one good start) because my largest > fear is that the various issues that might look like weaknesses of the > proposal must be analyzed, and that they are not. I'm sure Warren will do an outstanding job if he chooses to obey your recommendation. Perhaps one of the undoubtedly many reasons for your disappointment is that I am taking the system as it currently exists (as least as I understand it). As far as I am aware, that system does not have any solution to: > - Lack of DNSSEC validation > - The fact not all data in the root zone is signed > - Lack of legal protection of the root zone itself Do you believe the current system addresses these concerns? If so, how? With respect to the others: > - Recovery process when bad data end up in the resolver (cache v.s. auth) As I've pointed out, if bad data is being served to clients of a resolver, those affected can call up their resolver operator and demand they fix it. Since the users of the resolver may actually be paying customers, there might even be a chance that the resolver operator will listen. What would be the recovery process if the existing root server system distributed bad data? If "I" root started serving bad data, how would anyone non-technical know even who to call? Assume they know how to call their ISP's help desk and that help desk is able to figure out it is the "I" root server that is serving the bad data. How will that help desk implement a fix on the "I" root server? What is the likely timeframe from detection of problem to fix compared to the slaving the root scenario? More generally, what recourse does _anyone_ have if a root server operator (say) chooses not to upgrade bandwidth to their root when it drops the majority of queries? Or goes off the air for a few days? Or doesn't deploy IPv6? > - Routing issues (which is what I see the largest burden of a root server > operator) Must have missed this one and am unsure what it means in this context. What routing issues were asserted that resolver operators that slave the root are going to have? It would seem to me that the slaving the root approach can vastly simplify the routing (no need for inter-AS anycast) so I must be missing something. > - Political/regulative implications (to ensure a different TA is used than > ICANN) I'm confused. Did you mean to stop someone from using a different TA? What's to stop someone from doing that now? > ...and possibly more. Yes, perhaps there are more and perhaps if Warren obeys your recommendation, they'll be discovered. However, as many people have pointed out, _people are already slaving the root_ and oddly disaster has not befallen the Internet (or the customers of the folks that are slaving the root) as yet. Quoting Ralf Weber: "The draft doesn't require every resolver to slave the zone, but merly is an information that this is a possible way to do it and I assume that large resolver operators would benefit from it [...] It in the end of course comes down to do we want to document what is out there anyway or do we want to hide our heads in the sand. Especially for an operational group I would prefer the former." > Once again, this is such a large issue that I would prefer a bit better > arguments than what is demonstrated here. Actually, since it is opt-in, it doesn't seem to be that large of an issue to me, but perhaps that's because I'm not a root server operator and have no particular interest in maintaining the status quo. > Yes, I know you wrote in affection, but let this remind all of us that we can > do better. Undoubtedly "we" can. Regards, -drc
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
