[DNSOP] Comments on draft-ietf-dnsop-kskroll-sentinel-11

[Edward Lewis <[e-mail]>]

1.

##    which they are generated.  The Key Tag is a 16-bit value computed
##    from the RDATA portion of a DNSKEY RR using a formula similar to a
##    ones-complement checksum.  RRSIG RRs contain a Key Tag field whose

Suggest a reference to the section where the formula is defined, lest the
words here be taken as the definition.

"The Key Tag is a 16-bit value computed from the RDATA portion of a DNSKEY RR using a formula found in "Key Tag Calculation" (Appendix B of "Resource Records for the DNS Security Extensions" [RFC 4034]), a formula similar to a ones-complement checksum."

...the latter is not true for the original DNSSEC Security Algorithm, a factoid only significant in trivia games.   (See Appendix B.1 of the same document.)

2.

##    validating resolvers.  The KSK sentinel method cannot provided him

s/provided/provide/

3.

##    "invalid" resource.  His resolver resolves the root-key-sentinel-is-
##    ta-02323.example.com name normally (it contacts the example.com
##    authoritative servers, etc); as it supports the sentinel mechanism,
##    just before Dave's recursive server send the reply to Dave's stub, it

s/send/sends/
Truth is, I can't quite parse the sentence

##    performs the KSK Sentinel check (see below).  The QNAME starts with

4.

Unanswered[1] question from before:

Why is this specific to the root zone?

One reason to make this more general (than the root) is testing.  What if, in about two years, new implementations arrive and the operator of a root zone KSK wants to run tests?  It would be helpful to be able to have a test zone set up where secure entry points can be rotated in the name of testing code bases.  (In the same sense as this test tool: https://automated-ksk-test.research.icann.org/)

Beyond that, there are no other rules or conventions in the protocol specific to one (absolute) name.  Not even "the reverse map" is special to the protocol.  (Perhaps this is too philosophical a topic.)

If this test mechanism only works for the root zone, then other operators exercising Automated Updates will not be able to make use of it.  There are two operators at the TLD level of the global public Internet DNS who exhibit Automated Updates (one has confirmed to me they do), for the sake of clarity, these operators do not include ICANN.  I have never searched in other trees nor deeper in the global public Internet for any operator following Automated Updates nor making use of seeded trust anchors outside the root zone.

[1] - About a month ago, I sent an open question to the list:

https://www.ietf.org/mail-archive/web/dnsop/current/msg22047.html

I missed any public replies to the question, I had one private exchange that said the WG preferred root-only without an explanation.  I'm not saying there's been no rationale given, but I haven't seen any reason.  There may be a good reason, again, I just haven't seen one.