On Mon, Nov 13, 2017 at 03:45:30PM +0000, Edward Lewis wrote: > On 11/9/17, 12:48, "DNSOP on behalf of Evan Hunt" <dnsop-boun...@ietf.org on > behalf of e...@isc.org> wrote: > > > On Thu, Nov 09, 2017 at 03:48:26PM +0100, Petr Špaček wrote: > > > Nice write-up Edward! You have nicely summarized why Mark and me agree > > > that validator should use longest suffix match when selecting TA to > > > validate data. > > > > +1. > > Hmmm, that wasn't my intent. ;) I had been trying to justify the other > conclusion. But, if my work is leading you towards this "other" conclusion, > I've been taking time to understand why. > > I'm beginning to have a new understanding on this. The overlooked (by me) > point is that we are focusing on a situation where the local operator has > chosen to explicitly configure a trust anchor. Beside code distributions > shipping with the IANA managed KSK (or its DS form) for the global public > Internet's root zone, if any operator wants another trust anchor point, they > have to take explicit action to configure it. The question is - what is the > expectation of the operator in doing this? > > There was a time when TLDs were signed but the root zone was not. Then > operators had to configure trust anchors for the TLDs to enable validation. > When the root zone was signed in 2010, the TLDs had to remind all those with > trust anchors to remove them (before the TLD could change it's KSK). I can > no longer find reports of the efforts to undo TLD trust anchors (Sweden and > maybe CzechRep?) that I thought were once floating around. "Fears" > surrounding this would lead one to favor the more open "any" policies, on the > other hand, mass migration from TLDs to root for the top of the trust chain > was probably a one-time event as a result of the on-set of DNSSEC in the root > zone. >
Yes. And add to that cases were TLDs rolled just before adding to the root. https://eng.registro.br/pipermail/gter/2010-May/027981.html https://eng.registro.br/pipermail/gter/2010-June/028053.html https://eng.registro.br/pipermail/gter/2010-July/028138.html Fred _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
