[ietf-dkim] New Thread: Use of CNAME in place of NS subdomain delegation

[Douglas Otis]

On Aug 30, 2006, at 6:57 AM, Wietse Venema wrote:

> Douglas Otis:
>> A CNAME outside DNS also comes at the expense of adding a DNS  
>> transaction and a point of failure.  A CNAME transcription error  
>> used at some point in the future may take a while to resolve when  
>> it does become problem.  This may be difficult to resolve when the  
>> CNAME appears to point to a valid key.  Scaling may create  
>> namespace densities where such errors are not always apparent and  
>> could be induced by either the provider or the domain owner.  It  
>> is not as simple as put these CNAMES "here" pointing "there", the  
>> g=, s=, t= and TTL are also details a domain owner may wish to be  
>> able to alter.
>
> Thanks for bringing up an argument that can be applied against any  
> form of delegation.

This and other comments were specific to your suggestion.  CNAME had  
been raised on the list, with the conclusion the less said the  
better.  Discovering the cause of an expected problem is usually  
preceded with an anxious phone call, often late at night.  Uncovering  
lame configurations subsequent to an automated rollover, or CNAME  
related failure requiring prodding are implementation specific.   
Unexpected problems are a serious pitfall however.  It may not be  
long before support staff ban the "defective" service.  These issues  
relate to postponed employment and fragile CNAME implementations  
outside the DNS.


> Regardless of whether one uses DNS built-in methods (CNAME=leaf  
> node delegation, NS=interior node delegation), or application- 
> defined methods such as indirection via TXT records, there will be  
> extra network I/O, there will be opportunity for bad TTL  
> information, delegation to a non-existent target, and there will be  
> loss of control over the information that a delegatee hands out.

CNAME can hide latent issues when used for "future" exchanges.  The  
automated CNAME redirections outside the DNS are unfortunately less  
than elegant in some cases.


> These issues are inherent with delegation, and since everything  
> rides on top of DNS anyway, it seems to me that application-defined  
> delegation methods that attempt to side-step DNS "problems" just  
> add their own problems to it.

The number of entities involved in making a change represents a  
greater concern, not DNS itself.  Scaling will be a sizable effort  
just for DKIM policy to enable millions of email-addresses to  
designate their "prolocutor of address validity".  This does not  
involve restructuring DNS zones or cooperative efforts of 3 or 4  
entities.  A "prolocutor designate" must indicate when the email- 
address is valid.  While validating an email-address is not a  
function of DKIM, "asserting" when an email-address is valid should  
be a function of DKIM that extends beyond the signing domain.   
Without this ability, the value of DKIM drops to its lowest  
denominator.  The efforts to administer such designations can be done  
autonomously, and should not alter the "reputation" dynamics.

An email-address signed by a designated domain may be annotated  
differently than an email-address within the signing domain.  This  
annotation still provides significant protections for millions of  
users.  There is little to justify that allowing users to list a  
"prolocutor designate" is too complicated and a horrendous security  
concern.  This sounds too much like "People still can't tell when  
their email is valid.  Well, let them delegate their zones with NS  
records."

It is balderdash to describe designating a domain as representing a  
security concern in comparison to allocating one's namespace or  
allowing access to private keys.  A designation does not affect the  
integrity of a signature one iota.  It does allow market forces to  
elect "prolocutor designates" that have demonstrated the greatest  
integrity in a very democratic fashion.  Three cheers for the  
"prolocutor designates". : )

-Doug