Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

[Job Snijders <[e-mail]>]

On Thu, May 03, 2018 at 06:15:49PM +1000, Geoff Huston wrote:
> We have submitted -12 of this draft which we believe incorperates the
> substantive review comments made during the WG Last Call period that
> were posted to the WG Mailing List.
> 
> > Editors: Please take “concern about a description of current
> > implementation status” as WGLC input, and consider what you might be
> > able to add to the draft to address it. 
> 
> We have also taken the implementation comments posted to the WG
> mailing list and collected them in a new section titled
> "Implementation Experience” in the light of Suzanne’s request
> 
> So we would like to pass this draft back to the WG Chairs at this
> point for your review for potential submission as an RFC.

1/ While this is a step in the right direction, I'm not yet entirely
impressed by the 'Implementation Experience' section. Is it somehow hard
to write an implementation report that describes which implementations
comply with the BCP 14 / RFC 8174 terms used in
draft-ietf-dnsop-kskroll-sentinel? Are the authors experiencing some
blocker in this regard?

2/ Moving the Walkthrough Example to the end of the document as an
appendix has greatly improved the readability of the document.

3/ Section 3 states: "The responses received from queries to resolve
each of these names would allow us to infer a trust key state of the
resolution environment.".
>From what I understand, in today's DNS world we can only reasonably
expect to do one query per packet. It is well understood that many
operators use BGP-4 anycasting (ECMP), the likes of dnsdist, and/or
simple UDP loadbalancers. I think it may be good to document that
running 3 queries (in essence 3 independent experiments) may not
generate sufficient data to properly infer the state (or any state) of
the resolution environment. Each query (as part of a single sentinel
data gathering session) may be handled by an entirely different resolver
with different keys, contaminating any lookup in the proposed truth
tables. Section 4 covers a number of cases where the results are
indeterminate. It maybe should be added to Section 4 that the client has
no awareness of how the resolver environment is constructed, and thus
requiring multiple independent queries to infer state has its downsides.

Kind regards,

Job