Well, that's what I get for providing drive-by feedback. Someone pointed me off-list to RFC 8145 and the operational issues with that. I still think that that calls for a better authoritative/resolver telemetry interface, not some client-side thing.
On Mon, Nov 27, 2017 at 1:10 PM, Richard Barnes <r...@ipv.sx> wrote: > 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
