Subject: [dnsext] Comments on draft-ietf-dnsext-rfc2672bis-dname-18.txt

From: Brian Wellington <[email-masked]>
Date: Thu, 7 Jan 2010 15:09:49 -0800

Section 5.2 of this draft includes:

   A server MUST reject a dynamic update message that attempts to add a
   DNAME RR at a name that already has a CNAME RR or another DNAME RR
   associated with that name.

Is there a rationale for this text?  It's a pretty drastic departure from existing DDNS behavior.

RFC 2136, section 3.4.2.2 says:

   In the case of a CNAME Update RR and a non-CNAME Zone RRset or vice
   versa, ignore the CNAME Update RR, otherwise replace the CNAME Zone RR
   with the CNAME Update RR.

I don't see any reason why a CNAME would be replaced by an update with a non-DNAME record, but an update with a DNAME record would cause the update to fail.

RFC 2136, section 3.4.2.2 also says:

   In case of duplicate RDATAs (which for SOA RRs is always
   the case, and for WKS RRs is the case if the ADDRESS and PROTOCOL
   fields both match), the Zone RR is replaced by Update RR.

Section 2.4 (of this draft) defines DNAME as a singleton type, and while RFC 2136 doesn't use the word singleton, this text appears to be describing the same scenario.  As above, it's not clear why DNAME would be handled differently from other singleton types.

Additionally, if there is a reason for this change, the document should be more clear than "MUST reject"; that is, what the correct response code should be.

Brian