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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
