George, you should know better than to claim that a mechanism that requires resolver updates will have "immediate benefit" :)
I do not find this mechanism terribly compelling. It is not useful in the short run, as noted above. And it has the wrong architecture for the long run. What zone operators need, for KSK roll-overs and other evolution decisions, is telemetry about the capabilities of the resolvers they serve. In order for an approach like this to provide that telemetry, one would need a broad-scale client-side measurement system. While such systems exist (Geoff and George being expert practitioners), they have a lot of problems -- they're expensive to operate at scale; they're extremely limited in terms of what they can measure and how reliably; and they impose much more overhead than is needed here. We shouldn't be building a telemetry system for the DNS that has hard-coded assumptions about web ads or dedicated probes. It would be far better to build a telemetry mechanism that operated directly between resolvers and authoritative servers. There are a variety of ways you could do this. In today's world, you could have some record by which an authoritative server could advertise a telemetry submission point. In a DOH world, you could have the resolver provide a Link header telling the authoritative server where it could pick up information about resolver capabilities. None of these are hard to build (and they don't interfere with the "fast path" of the resolver) and they provide much more high quality information. If you need data for the KSK roll that we're already a decade late for, gather it in a way that doesn't require a resolver upgrade. (Deploy a dedicated temporary TLD if you need to.) If you're trying to solve the long-run telemetry problem, then build it properly. --Richard On Thu, Nov 16, 2017 at 3:34 AM, George Michaelson <g...@algebras.org> wrote: > I support adoption of this work. Its a sensible, simple proposal which > has immediate benefit, and can be used by anyone to test the ability > of their nominated resolver to recognise specific keys, and their > trust state. > > I believe as a community, at large, we need code deployed into the > resolvers in the wild, and we need a document specifying the behaviour > we need deployed into those resolvers. We can use this to inform > ourselves of operational risk under keychange. We can know as > individuals, as organizations what we will see, if keys change. I > think this is quite powerful. compared to measurement of what > resolvers see, or what authoritatives or roots see, going back to > these service-providers themselves. This method informs the client > side of the transaction. Thats big. > > I'm not saying we shouldn't do other things, or measure. I'm saying > that this proposal has a qualitative aspect which I think is > different, and good. > > -George > > On Thu, Nov 16, 2017 at 4:23 PM, tjw ietf <tjw.i...@gmail.com> wrote: > > All > > > > The author has rolled out a new version addressing comments from the > meeting > > on Monday, and we feel it’s ready to move this along. > > > > This starts a Call for Adoption for draft-huston-kskroll-sentinel > > > > The draft is available here: > > https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/ > > > > Please review this draft to see if you think it is suitable for adoption > by > > DNSOP, and comments to the list, clearly stating your view. > > > > Please also indicate if you are willing to contribute text, review, etc. > > > > This call for adoption ends: 30 November 2017 23:59 > > > > Thanks, > > tim wicinski > > DNSOP co-chair > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
