A Root Key Trust Anchor Sentinel for DNSSEC
RFC 8509
Yes
No Objection
Recuse
Note: This ballot was opened for revision 15 and is now closed.
Alvaro Retana No Objection
Warren Kumari Recuse
Recusing because author. ADs, avoid balloting with this weird trick..... :-P
(Terry Manderson; former steering group member) Yes
(Adam Roach; former steering group member) No Objection
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/").
(Alexey Melnikov; former steering group member) No Objection
Benjamin asked: The first one may just be something that I missed, but does this document actually say anywhere that there needs to be a real zone with real configured A and/or AAAA records for the query names used for these tests? The Appendix sort-of-mentions it, but I feel like there needs to be a mention in the main body text. The same question bothered me a lot and made understanding purpose of the document hard. Please clarify this early on in the document.
(Alissa Cooper; former steering group member) No Objection
(Ben Campbell; former steering group member) No Objection
Just a couple of nits: §1, the two bullet points: "... DNS resolution environment resolvers is ready...": Plural mismatch, although I wonder if both "environment" and "resolvers" were intended to be there. "... negatively impacted an upcoming root KSK rollover.": Missing word after "impacted"?
(Benjamin Kaduk; former steering group member) (was Discuss) No Objection
Thanks for addressing my Discuss points -- the text in the github version of
this document helps a lot, and I'm happy with the direction we're going in
for the more general case.
[original ballot comments preserved below]
Other than my Discuss points, I just have a number of essentially editorial
nits.
Abstract
This document specifies a mechanism that
will allow an end user and third parties to determine the trusted key
state for the root key of the resolvers that handle that user's DNS
queries. [...]
This wording feels confusing to me; I think what it's trying to say is "the
root key(s) that are in use by the resolver" but am having a hard time
grouping these words to achieve that meaning. (Is "trust" really necessary
to mention, here?)
Section 1
RRSIG RRs contain a Key Tag field whose value is equal to
the Key Tag of the DNSKEY RR that was used to generate the
corresponding signature.
nit: Is the RR used to generate the signature, or just the key?
o Users may wish to ascertain whether their DNS resolution
environment resolvers is ready for an upcoming root KSK rollover.
nit: I think there's a singular/plural mismatch or similar here, maybe
"environment's resolver"?
o Researchers want to perform Internet-wide studies about the
proportion of users who will be negatively impacted an upcoming
root KSK rollover.
nit: "by an upcoming"
If a browser or operating system is configured with multiple
resolvers, and those resolvers have different properties (for
example, one performs DNSSEC validation and one does not), the
sentinel test described in this document can still be used, but it
nit: this usage of "but" feels a bit misplaced to me, as the thing being
warned about is more that the test may produce indeterminate or
inconsistent results. Or perhaps that the assumptions it makes may not
necessarily hold in the specific environments being described (i.e., "these
environments").
makes a number of assumptions about DNS resolution behaviour that may
not necessarily hold in all environments. If these assumptions do
not hold (such as, for example, requiring the stub resolver to query
the next recursive resolver in the locally configured set upon
receipt of a SERVFAIL response code) then this test may produce
indeterminate or inconsistent results. In some cases where these
assumptions do not hold, repeating the same test query set may
generate different results.
Section 1.1
Please use the RFC 8174 boilerplate.
Section 3
I'll note without further comment that we had a long thread on ietf@
relevant to the term "slave resolver".
Section 3.1
If the resolver is non-validating, and it has a single forwarder,
then the resolver will presumably mirror the capabilities of the
forwarder target resolver.
Perhaps this is just me misreading the previous paragraph's introduction to
what is clearly a more widely known term of art, but in "has a single
forwarder" is the thing of which there is only one the "one or more other
resolvers" that the "forwarder" is relaying queries to? It's just weird
for the word "forwarder" mean a different protocol participant when used as
a noun vs. adjective. Or perhaps this is meant to be possessive; the
"forwarder's target resolver"?
As noted in the directorate review, "use the CD bit" needs disambiguation.
Section 4
nit: missing trailing 'r' in the section title
Section 4.3
Maybe call out that these are the same general categories of query as in
Section 3 but the key tag used is different for some queries?
It's also a bit weird to use new notation for this section as opposed to
consistent notation between the different types of test.
(Deborah Brungard; former steering group member) No Objection
(Martin Vigoureux; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
(Suresh Krishnan; former steering group member) No Objection