[DNSOP] Adam Roach's No Objection on draft-ietf-dnsop-kskroll-sentinel-15: (with COMMENT)

[Adam Roach <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-dnsop-kskroll-sentinel-15: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I am balloting "no objection," although I share Benjamin's concerns about the
claiming of leaf nodes in the DNS system. However, I think that issue is larger
than just this document, and that we are unlikely to come to an agreement within
the DNS community about how to handle it in a reasonable amount of time.

I have some additional comments, below.

---------------------------------------------------------------------------

§4:

> 4.  Sentinel Tests from Hosts with More than One Configured Resolve

Nit: "...Resolvers"

---------------------------------------------------------------------------

§4.2:

One of the implicit assumptions of this section appears to be that the client
performing this test will necessarily be using gethostbyname() (or something
similar), and at the mercy of the underlying library with regard to the test
assumptions. On systems where the list of configured resolvers can be retrieved
programmatically (e.g., 'scutil --dns' under OS X, or the contents of /etc/hosts
on most other Unices), I would guess that more reliable results could be
achieved by treating the three bullets in section 4.2 as requirements on the
testing client rather than assumptions that may make the results invalid if they
don't hold.

Concretely: I believe it would be useful to add text to this section suggesting
that clients can achieve more reliable results by bypassing the local stub
resolver and implementing queries themselves (in a fashion similar to the
popular "dig" utility), which allows them to ensure that these assumptions are
true.

---------------------------------------------------------------------------

Appendix A:

This walkthrough uses the name "bogus.example.com" for the bogus record used in
the testing. I've gone looking through the document and cannot determine whether
this is canonical or just the name this example uses. I presume it's the latter.
It's probably worth adding text to this example which explains that the choice
of "bogus" by Geoff is a site-local decision. What I'd like to avoid is having
situations where people hardcode "bogus" into some tooling suite, and then cause
sites like "github.io" grief in the case that the (already-registered) user with
a username of "bogus" attempts to set up a page at "https://bogus.github.io/").