MX pointing to CNAME
Mark_Andrews at isc.org
Wed May 31 00:50:35 UTC 2006
> 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
> > 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.
> 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 18.104.22.168
The parent would have to hold glue CNAME and A records and
the referral would have to include them in the additional
child NS foo.child
foo.child CNAME bar.child
bar.child A 22.214.171.124
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
As a simple delegation won't work with a CNAME record, BIND
does not attempt to make the few case where it could succeed
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.
> 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.
> 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
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
More information about the bind-users