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

[Richard Barnes <[e-mail]>]

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
>>
>
>