[dnsext] Issue with RFC 4034, section 3 and section 4

Edward Lewis <Ed.Lewis@neustar.biz> Fri, 31 July 2009 21:16 UTC

Mime-Version: 1.0
Message-Id: <a06240800c698e34372b3@[10.31.200.165]>
Date: Fri, 31 Jul 2009 17:12:12 -0400
To: namedroppers@ops.ietf.org
From: Edward Lewis <Ed.Lewis@neustar.biz>
Subject: [dnsext] Issue with RFC 4034, section 3 and section 4
Cc: ed.lewis@neustar.biz
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

I'm doing a review of RFC 4034 and found something I'm concerned 
about.  Not a protocol issue but a specification issue.

Section 3 The RRSIG Resource Record

3rd paragraph reads:

#   Because every authoritative RRset in a zone must be protected by a
#   digital signature, RRSIG RRs must be present for names containing a
#   CNAME RR.  This is a change to the traditional DNS specification
#   [RFC1034], which stated that if a CNAME is present for a name, it is
#   the only type allowed at that name.  A RRSIG and NSEC (see Section 4)
#   MUST exist for the same name as a CNAME resource record in a signed
#   zone.

The text I am concerned about is "RRSIG RRs must be present for names 
containing a CNAME RR."  My concern is over the word "containing" 
with DNAME's CNAME-synthesis in the back of my mind.

I'd suggest a clarification be made (and carried in any appropriate 
document vehicle) to say:

..., even an explicitly defined CNAME RR(set) MUST have an a set of 
associated RRSIG(s). ("Explicitly defined" excludes CNAME RRsets that 
result from a wild card synthesis [RFC4592] or DNAME synthesis 
[RFC2672/bis].)

Note that in the orginal text, "must" is not capitalized.  I am 
supposing that is due to an editorial oversight.


4.  The NSEC Resource Record

2nd paragraph reads:

#   Because every authoritative name in a zone must be part of the NSEC
#   chain, NSEC RRs must be present for names containing a CNAME RR.
#   This is a change to the traditional DNS specification [RFC1034],
#   which stated that if a CNAME is present for a name, it is the only
#   type allowed at that name.  An RRSIG (see Section 3) and NSEC MUST
#   exist for the same name as does a CNAME resource record in a signed
#   zone.

Again, "must" appears in small letters.  The text that needs to be 
cleaned up is "An RRSIG (see Section 3) and NSEC MUST exist for the 
same name as does a CNAME resource record in a signed zone."  But in 
this case, the clean up is not so important.

Bearing in mind 4034 predates 5155 and any update won't:

Domain names that own an explicit CNAME (excluding synthesized as a 
result of a wild card or DNAME) MUST have an NSEC RRset and its 
associated RRSIG (see section 3) records, if the zone uses NSEC-style 
negative answers.

Editorial note to that:  1, we have to define "NSEC-style negative 
answers" in a glossary as "a configuration of DNSSEC in which a zone 
uses NSEC records whenever a negative result is needed to be 
expressed" - as opposed to NSEC3-style which has to expand the 
definition to treat opt-out.  2, The text does not mention NSEC3 
because NSEC3 would be owned by a hash name, not a name with CNAME 
unless the hash name manages to be a name that would have a CNAME.


-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

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

[dnsext] Issue with RFC 4034, section 3 and secti… Edward Lewis