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


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



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

Truth is, I can't quite parse the sentence

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


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: 

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:


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.

DNSOP mailing list

Reply via email to