type code roll draft comments

[Edward Lewis <[e-mail]>]

#        Legacy Resolver Compatibility for Delegation Signer
#        draft-ietf-dnsext-dnssec-2535typecode-change-02.txt
#

# Abstract
#
#    As the DNS Security (DNSSEC) specifications have evolved, the
#    syntax and semantics of the DNSSEC resource records (RRs) have
#    changed.  Many deployed nameservers understand variants of these
#    semantics.  Dangerous interactions can occur when a resolver that
#    understands an earlier version of these semantics queries an
#    authoritative server that understands the new delegation signer
#    semantics, including at least one failure scenario that will cause
#    an unsecured zone to be unresolvable.  This document proposes that
#    these interactions be avoided by changing the type codes and
#    mnemonics of the DNSSEC RRs (SIG, KEY, and NXT).

One thorny issue is that it is not just name servers that understand 
some variants, but that some DHCP servers do also, and this is why 
SIG(0) has
become an annoying issue.

(Yes, I'm being a PITA about documenting the rationale again.)

# 1. Introduction
#
#    incompatible with the semantics in [RFC2535].  Answers provided by

A nit: For consistency (see also text in 1.2), refer to RFC 2535 as "RFC
2535", with the reference ("[RFC2535]") appearing just once.  I'd recommend
this for other RFC's too.

# 1.1 Terminology
#
#    In this document, the term "unsecure delegation" means any
#    delegation for which no DS record appears at the parent.  An
#    "unsecure referral" is an answer from the parent containing an NS
#    RRset and a proof that no DS record exists for that name.

And you are referring (heh) to "NS referrals" and not "CNAME referrals".

# 1.2 The Problem

The "trigger" or last straw prompting this.  There are many decent 
reasons to change the protocol parameters when a standard recycles at 
a certain level, especially Proposed, but there is one problem in 
particular that launched this effort.

I would also add the observation that in RFC 2308 (NCACHE), looking 
at "NODATA REPSONSE: TYPE 1." and then considering that in the olden 
days an NXT was thought to be an SOA-replacement in negative answers, 
it seems as if the presence of the no-DS record is indicating a 
negative answer, not a positive answer indicating an "end of 
security."

# 2.1. Change SIG, KEY, and NXT type codes
#
#    include NXT records in the authority section.  The simplest way to
#    do that is to change the type codes for SIG, KEY, and NXT.

Well, "simplest" would be to just change NXT as you mention in 2.2. 
Changing all three would be conceptually nicer, especially given that 
blindly changing SIG and KEY leaves us in a hung state with SIG(0) 
(as non-DNS elements are already experimenting with it).

# 2.5. Do nothing
#
#    and, due to underspecification in those documents, interpret any

s/s/ s/

# 3. Protocol changes
#
#    If a resolver receives the old types, it SHOULD treat them as

You mean KEY and NXT.?.

#    Authoritative servers SHOULD NOT serve SIG, KEY, or NXT records.

Authoritative servers ought not edit the zones they have loaded.  Are 
you saying that the server ought to refuse to load zones with these 
and ought to refuse updates that attempt to add these records?

I'm confused.  If a SIG(0) is seen and a DNSKEY isn't allowed to have 
generated it, where does the public key come from to validate the 
SIG(0) at the end of the message?

# 4. IANA Considerations
#    Types 24 (SIG) is retained for SIG(0) [RFC2931] use only.  Types 25
#    and 30 (KEY and NXT) should be marked as Obsolete.

I can see NXT being obsoleted.  But I am not clear from the text whey 
the KEY is also.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

...as graceful as a blindfolded bull in a china shop...

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>