Note that I only listed a hand full of issues I immediately think of that I think needs to be compared and evaluated. Like Suzanne wrote. In some cases there is no difference between an auth server and cache, in other cases there might be.
> On 8 jul 2014, at 16:18, Paul Hoffman <paul.hoff...@vpnc.org> wrote: > >> On Jul 7, 2014, at 10:02 PM, Patrik Fältström <p...@frobbit.se> wrote: >> >> - Recovery process when bad data end up in the resolver (cache v.s. auth) > > That's the "cache has gone stale" issue that David raised. It is dealt with > in the current draft. There is no other way for "bad data" to be in the cache > other than by having it come from a signed root zone that has changed. Not all data in a signed zone is signed. But I appreciate you say you feel you have been thinking about it. My point is that I really really really want to know that the unsigned info in a signed zone is NOT treated differently in an auth server than a cache. Once again, I list questions. >> - Routing issues (which is what I see the largest burden of a root server >> operator) > > The draft does not impose any "routing issue" on the root. In fact, it says > that the signed root might be gotten from entities that are not root zone > operators. I understand my statement was weird. Today when clients get "weird responses" they look where they get the response from, identify one of the 13 ip addresses and contact the root server that quite often do various monitoring and protection of the routing of that very IP address. I.e. responding to DNS queries is one thing, managing one of the key ip addresses is another. Yes, I understand that is not really an issue if the resolver is auth for the root zone. > >> - Lack of DNSSEC validation > > The draft says repeatedly that the information is only entered if it is > DNSSEC validated. If you can find any sentence in the draft that says > differently, I'll fix it immediately. How is that policed? Yes, people can say that "that already happens" which of course is true. But I see a difference between recommending this and just making it possible, from the IETF. > >> - The fact not all data in the root zone is signed > > That is a statement with no effect. If the data is not signed when it is > retrieved from the signed root zone, it will be unsigned when retrieved using > normal queries to the root zone. See above. >> - Political/regulative implications (to ensure a different TA is used than >> ICANN) > > That is a statement with no effect. Nothing in the draft changes the TA used > to validate the root zone, so a validating recursive resolver acts > identically whether it uses the mechanism or not. Not really. If you are auth, then queries by definition do not "leak" to a place where a different TA is needed. >> - Lack of legal protection of the root zone itself > > Please try to explain this. The root zone operators current serve the root > zone signed with DNSSEC. This draft doesn't change that, so there are no new > legal implications. The root server operators (at least for example the three outside of the US) have an MOU with ICANN that say we will serve the zone ICANN serves. Where is the same protection between end users in $state using $isp under $regulative_policy that the same zone is served? In this case I want $state to have for example have signed a treaty saying the root zone is not to be modified. >> ...and possibly more. > > That is not helpful. Well, I was responding to drc that wrote something in affect, and my intention was to show a subset of issues to address and look at, as a longer list that what drc listed. >> ...and of course a combination of these. > > Umm, that is not helpful either. That was to protect myself. For example, the fact not everything in the root zone is signed, ability to sign and produce a new root server with new TA with not a complete root zone in $state under some interesting $regulation. Possibly using the same (or different ip addresses) than what is used today. I hope proponents of this proposal can explain why this is different than an alternate root. >> Once again, this is such a large issue that I would prefer a bit better >> arguments than what is demonstrated here. > > The reason that there are not arguments in the -01 draft to deal with your > issues above is that they seem unrelated to the draft. It is hard to have a > section that says "Someone objected that this does X, but they are wrong" > that has a finite length. > >> Yes, I know you wrote in affection, but let this remind all of us that we >> can do better. > > Sure, but bringing up issues that are just as true whether or not the draft > is implemented is not "doing better". Having a list of issues that come from > what the draft changes would be great: we can deal with those. Understood. Once again, I responded more to the mail from drc than address the draft per se. Patrik > > --Paul Hoffman > > P.S. None of the above relates to Joe's big issue, which is that implementing > the draft doesn't help anyone much. To me, that's a much more valid (and > measurable) criticism than anything on the list above. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
