On Aug 28, 2006, at 2:48 PM, Wietse Venema wrote:
For long-term applications, the need to pre-create
selector2006/2007/etc. is an inconvenience. For short-term
applications, however, a CNAME may have more benefits. It allows a
site maintain control over what names are delegated. With
delegation of an entire DNS subtree there is less control over the
delegated name space.
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.
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.
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.
Wietse
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html