MX pointing to CNAME

[Mark Andrews]

> 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.
> ...

	BIND ignores them because they cannot work in all cases.

	Take this simple example

		@ SOA ....
		@ NS foo
		foo CNAME bar
		bar A 1.2.3.4

	The parent would have to hold glue CNAME and A records and
	the referral would have to include them in the additional
	section.

	e.g.
		child NS foo.child
		foo.child CNAME bar.child
		bar.child A 1.2.3.4

	To make them work you would need to change the additional
	data processing rules to look for and chase CNAME records
	for NS records.  You would need to accept CNAMEs as glue
	in addition to A and AAAA records.  Resolvers would need
	to be changed to accept CNAME records in the additonal
	section.

	As a simple delegation won't work with a CNAME record, BIND
	does not attempt to make the few case where it could succeed
	work.

	BIND 9.4.0 should reject the above child zone at load time.


> 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/
> 
> 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org