Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel

[Richard Barnes <[e-mail]>]

As tempting as it may be to do the easy thing, it's not always the best use
of resources.  Looking at the closest tree might be easy for one observer,
but when you try to do it with enough observers to have a result that's
useful for the King of the Jungle, you end up with similar tangles.

I don't think that it make sense to infer from the failure of RFC 8145 that
resolver/authoritative telemetry isn't possible -- just that it's not
possible with the heavy-weight machinery in that mechanism.  To the degree
that the DNS still works at all, there must be some channel by which
information can be faithfully passed from authoritative to resolver, which
can presumably be used to bootstrap telemetry.  Maybe it's a TXT record
with an HTTP URL; maybe it's a funny CNAME.

Maybe you can't build a road through the jungle, but there are still rivers
that make it through, which can carry a message in a bottle.

On Mon, Nov 27, 2017 at 2:06 PM, Joe Abley <[e-mail]> wrote:

> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]> 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/dnsop
> > >
> >
> > _______________________________________________
> > DNSOP mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dnsop
> >
> >
> > _______________________________________________
> > DNSOP mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dnsop
>
>