Subject: Re: [dnsext] Comments on draft-ietf-dnsext-rfc2672bis-dname-19

From: Douglas Otis <[email-masked]>
Date: Wed, 21 Apr 2010 16:00:41 -0700

On 4/21/10 1:06 PM, George Barwood wrote:
>  Section 2.3
>
>  It would be sensible to allow CNAME to co-exist with DNAME. There is
>  no conflict, since DNAME matchs below the owner, and CNAME matchs at
>  the owner. Forbidding CNAME doesn't seem to have any justification
>  (albeit this was a restriction in the original specification ).

CNAME indicates resources for the name, except those related to DNSSEC, 
are found at the held alias.  DNAME indicates any downward looking node 
holding a DNAME will cause the name being sought be the query name, the 
result of a CNAME being followed, or DNAME's replacing suffix labels of 
the name being sought that match the owner name of the DNAME with the 
held alias.  Seeing DNAME and CNAME at the same node requires CNAME be 
ignored, except for exact matches.  The prohibition still seems 
justified, as this prevents difficulty in assigning the source of a 
resource.  Seems critical, since accurately matching names against 
resources is important when there may be doubts in how this might be cached.

When the goal is to provide equivalent names, a lack of CNAME signatures 
whenever BNAME or DNAME is not understood suggests "equivalency" is not 
possible on that basis.  Section 5.1. "Canonical hostnames cannot be 
below DNAME owners" makes it clear use of name aliases will not result 
in "equivalently" capable domains as well.  Imagine the effect of 
aliasing two ideograms that mean country at a TLD.  IMHO, these issues 
suggest the Shadow zone scheme has greater merit, with the expense of 
multiple certs.  Do you seen another way for security to be retained?

-Doug