cname quick question

[Jim Reid]

>>>>> "Brad" == Brad Knowles <brad.knowles at skynet.be> writes:

    Brad> At 12:06 AM +0000 3/8/01, Jim Reid wrote:
    >> The new DNAME record does this, though it probably should be
    >> used for a definite period of time - say for a migration
    >> project - rather than as a permanent fixture to some (old)
    >> domain name.

    Brad> 	Hmm.  Do you know of any code that recognizes and
    Brad> makes proper use of DNAMEs? 

The BIND9 name server.

    Brad> Should we be working hard to get this into sendmail, postfix, etc...?

I don't think so. If the applications query a BIND9 server, DNAME just
works:
	% dig example.com dname
	...
	;; ANSWER SECTION:
	example.com.            86400   IN      DNAME   rfc1035.com.
	...
	% dig gromit.example.com
	...
	;; ANSWER SECTION:
	example.com.            86400   IN      DNAME   rfc1035.com.
	gromit.example.com.     86400   IN      CNAME   gromit.rfc1035.com.
	gromit.rfc1035.com.     86400   IN      A       62.6.242.9
	gromit.rfc1035.com.     86400   IN      A       62.6.242.6
	...
	% ping gromit.example.com
	ping gromit.example.com
	PING gromit.example.com (62.6.242.6): 56 data bytes
	64 bytes from 62.6.242.6: icmp_seq=0 ttl=255 time=0.704 ms
	64 bytes from 62.6.242.9: icmp_seq=1 ttl=255 time=0.551 ms
	64 bytes from 62.6.242.9: icmp_seq=2 ttl=255 time=0.589 ms

The first thing to note here is that the local example.com zone file
only has NS records, a SOA and the DNAME. That zone file contains no
names for gromit.example.com at all. The CNAME for gromit.example.com
in the answer from the second dig does not really exist: the name
server faked it on the fly.

There could be some issues for mail systems that get CNAMEs returned
when they look for MX records because of DNAME trickery but I don't
think these would be show-stoppers.