Subject: let CNAME and DNAME coexist at a node?

From: "Adam M. Costello" <[email-masked]>
Date: Sun, 27 Jul 2003 23:58:53 +0000

A node is not allowed to have both a CNAME record and a DNAME record,
but I think such a combination would be harmless and useful.

(But I don't have a lot of practice reasoning about DNS resolution, so
please read the following critically and watch for errors.)

RFC 1034 says:

    If a CNAME RR is present at a node, no other data should be present;

RFC 2672 reiterates that rule:

    If a DNAME RR is present at a node N, there may be other data at N
    (except a CNAME or another DNAME)

RFC 1035 gives the following reasons for its prohibition of combining
CNAME with other resource record types at a node:

    this ensures that the data for a canonical name and its aliases
    cannot be different.  This rule also insures that a cached CNAME can
    be used without checking with an authoritative server for other RR
    types.

These reasons don't apply to the combination of CNAME and DNAME.  The
CNAME record affects queries for the owner name itself, but has no
effect on queries for its descendants.  Conversely, the DNAME record
affects queries for the descendents, but has no effect on queries for
the owner name itself (except explicit queries for DNAME records, which
would be unaffected by the CNAME record).

In short, CNAME and DNAME don't get in each other's way at all; their
jurisdictions are non-overlapping.

It would be useful to have both CNAME and DNAME at the same node.  For
example, supposed I wanted example.net to be an alternate spelling of
example.com, so that

  (a) http://www.example.net/ reaches the same web server as
      http://www.example.com/

  (b) [email-masked] reaches the same mail server as
      [email-masked]

  (c) http://example.net/ reaches the same web server as
      http://example.com/

  (d) [email-masked] reaches the same mail server as
      [email-masked]

I could accomplish (a) and (b) (but not (c) and (d)) using DNAME:

    example.net. DNAME example.com.

I could accomplish (c) and (d) (but not (a) and (b)) using CNAME:

    example.net. CNAME example.com.

If I were allowed to use CNAME and DNAME together, I could accomplish
all four:

    example.net. CNAME example.com.
                 DNAME example.com.

Without being able to use CNAME and DNAME together, the best I can do is
use DNAME only, and simulate the effect of CNAME by keeping the A and MX
records synchronized for example.net and example.com (in two separate
zones).

The only way I can see to completely alias an entire domain (a node
and all its descendants) is to combine CNAME and DNAME.  Before RFC
2672 is advanced to draft standard, should it be revised to allow this
combination (updating RFC 1034)?

AMC

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: [email-masked]
Date: Thu, 07 Aug 2003 13:09:27 +1000

> would be unaffected by the CNAME record).

	What is the behaviour of a cache that isn't aware of your new
	rules with the following query sequence?

		dig example.net CNAME
		dig example.net DNAME
 
>   (c) http://example.net/ reaches the same web server as

	Solve the general problem of supporting http://example.net/
	pointing to some arbitary server.  Its solution space will
	cover this.
 
>   (d) [email-masked] reaches the same mail server as

	[email-masked] DOES NOT EXIST if you use a CNAME.
	MTA's re-write [email-masked] -> [email-masked].

	A MX record pointing to the same server avoids the
	re-write.

--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Adam M. Costello" <[email-masked]>
Date: Thu, 7 Aug 2003 04:13:39 +0000

> 	rules with the following query sequence?

Oh dear, that's a problem.  The server will cache the CNAME pointing
from example.net to example.com, and then when it gets the DNAME query
for example.net, it will try to chase down a DNAME record belonging to
example.com rather than example.net.

That might be a show-stopper.

> 	pointing to some arbitary server.  Its solution space will

I thought the general problem had already been solved, and the solution
is to make example.net be a CNAME for the server.  I guess I don't
understand what you mean.

> 	MTA's re-write [email-masked] -> [email-masked].

Only for the SMTP commands (like MAIL and RCPT).  The only header fields
affected by this rewriting are Received and Return-Path.  The fields
that users typically see (To, From, Cc, Reply-To, etc) are not rewritten
(at least, they shouldn't be according to RFC 1123 section 5.2.6).
Therefore, from a user's perspective, [email-masked] exists and works
like any other address, even if example.net has a CNAME record.

AMC

---

From: "D. J. Bernstein" <[email-masked]>
Date: 7 Aug 2003 04:34:29 -0000

> 	MTA's re-write [email-masked] -> [email-masked].

Your understanding of the situation is obsolete. We MTA implementors
really don't like having to do this, and at some point we're going to
stop. RFC 2821 (paying no attention to backwards compatibility) allows
MTA implementors to stop doing this already. Bottom line: You can't rely
on SMTP clients to rewrite aliases.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago