On 8 jul 2014, at 08:22, David Conrad <d...@virtualized.org> wrote: > On Jul 7, 2014, at 10:02 PM, Patrik Fältström <p...@frobbit.se> 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.
That I understand, and I myself react like that regarding arguments both in favor and against the proposal. One could say the discussion is a typical non-constructive IETF discussion which too many are. >> 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? The discussion about these things, and the differences between a cache and authoritative server I would like to have in a room where people are not shouting at each other. There are differences, and you know that as well as I. > 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. The market economy forces fixing things is correct. What I was thinking of is for example the difference between restarting a caching resolver and re-priming an auth server. Sure, everyone can learn both recovery mechanisms, but "restart your server" is quite simple task. Once again, I want the arguments listed. > 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? You here list a few to me different problems. If people get wrong data from the IP address of "I" they call Netnod. > 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? That is, as you know, also an "interesting" discussion. >> - 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. What I want to have examined is how to ensure the right data is coming to whoever wants it, and who is responsible to clean up when there are issues. Today, as you say yourself, the responsibility is on the root server operators. >> - 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? I see it as a big difference between having auth data (explicitly changed) within a difficult democracy and having caches of the data. Sure, some of them have already implemented what you talk about but having IETF explicitly saying auth data is coming from recursive resolvers will from my point of view drastically increase the amount of blocked DNS traffic across the global Internet and that will indeed impact network neutrality. >> ...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." I am not talking about situations where good people slave the root zone. I am talking about disaster recovery. >> 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. I do not see it as opt-in. Definitely not. I see this draft be a tool that is used to force opt in to a different root zone than what ICANN is managing. A very effective tool regarding fragmenting the Internet. And having an incoming CTO of ICANN requesting fragmentation of the Internet actually worries me a bit. Because of this, I think it must proven that increased deployment of this technology will not increase fragmentation of the Internet. >> Yes, I know you wrote in affection, but let this remind all of us that we >> can do better. > > Undoubtedly "we" can. Are you sure? ;-) Patrik
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
