As I imagine you've heard, part of the problem with resolver-authoritative telemetry interfaces is that the deployed infrastructure is not so simple; it also includes forwarders, changed resolvers, caches, middleware that interferes with the query path and/or drops queries that don't look normal... It's a jungle out there. Looking at the closest tree from just outside the edge of the jungle is actually much easier than speculating about what bizarre horrors lie within it.
> On 27 Nov 2017, at 13:36, Richard Barnes <r...@ipv.sx> wrote: > > 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
