MX pointing to CNAME

[Peter Dambier]

Pete Ehlke wrote:
> On Tue May 30, 2006 at 18:46:37 +0200, Peter Dambier wrote:
> 
>>If you ask the inventors of CNAME they will tell you CNAME was not a good
>>idea after all. If you can, avoid them. They will at best cost time to look
>>up.
>>
> 
> Oh, really? References for this claim are where, exactly? DJB has ranted
> about this at some length in the past, and his acolytes tend to parrot
> the words, but please, show me where "the inventors of CNAME" have said
> such a thing.
> 


http://www.ietf.org/rfc/rfc1912.txt

...
Don't go overboard with CNAMEs.  Use them when renaming hosts, but
plan to get rid of them (and inform your users).
...
Also, having chained records such as CNAMEs pointing to CNAMEs may
make administration issues easier, but is known to tickle bugs in
some resolvers that fail to check loops correctly.  As a result some
hosts may not be able to resolve such names.
...
Having NS records pointing to a CNAME is bad and may conflict badly
with current BIND servers.  In fact, current BIND implementations
will ignore such records, possibly leading to a lame delegation.
...


To: namedroppers at ops.ietf.org
Subject: another question about interpretation of the scriptures: cname chains
From: Paul Vixie <paul at vix.com>
Date: Mon, 03 Apr 2006 17:18:28 +0000

i know that an authority server can emit an incomplete cname chain if it
leads outside the servers's authority zone(s).  but what should a recursive
server return if a cname chain from the qname leads to an NXDOMAIN?  my
intuition says "return NXDOMAIN" since the nonterminal cname chain has no
value and no meaning to an RD=1 initiator.  but i note with dismay that BIND
actually emits the nonterminal chain as if it were an answer to the question.


http://www.ietf.org/rfc/rfc2308.txt

7.15. Nonterminal or wildcard CNAMEs are not well specified by
    [RFC1035] and their use will probably lead to unpredictable results.
    Their use is discouraged.


http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-11.txt
...
Abstract

     This is an update to the wildcard definition of RFC 1034.  The
     interaction with wildcards and CNAME is changed, an error
     condition removed, and the words defining some concepts central
     to wildcards are changed.  The overall goal is not to change
     wildcards, but to refine the definition of RFC 1034.


So I guess resolvers written before March 13, 2006 might interpret
CNAME differently from resolvers written after March 13, 2006

Kind regards
Peter and Karin Dambier


-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: peter at peter-dambier.de
mail: peter at echnaton.serveftp.com
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/