MX that points to CNAME instead of A?

[David Wolfskill]

One of the things my employer does is provide an email filtering
service; this has historically been implemented by having a hostname
(for each of our sites) that has several A records (one for each
of our SMTP servers at the given site), then having the customers set up
their MX records to point to each of these hostnames (with appropriate
weights), e.g:

[Our zone file...]
mx.site1.example.net	IN	A	192.168.5.1
			IN	A	192.168.5.2
			IN	A	192.168.5.3
			IN	A	192.168.5.4

mx.site2.example.net	IN	A	192.168.6.1
			IN	A	192.168.6.2
			IN	A	192.168.6.3
			IN	A	192.168.6.4

mx.site3.example.net	IN	A	192.168.7.1
			IN	A	192.168.7.2
			IN	A	192.168.7.3
			IN	A	192.168.7.4

[Customer zone files...]
customer1.example.com	IN	MX	10 mx.site1.example.net.
			IN	MX	20 mx.site2.example.net.
			IN	MX	20 mx.site3.example.net.

customer2.example.com	IN	MX	10 mx.site2.example.net.
			IN	MX	20 mx.site1.example.net.
			IN	MX	20 mx.site3.example.net.

customer3.example.com	IN	MX	10 mx.site3.example.net.
			IN	MX	20 mx.site1.example.net.
			IN	MX	20 mx.site2.example.net.


This works, but involves a degree of uncertainty as to how a given
message will actually flow, so there's some awkwardness in researching
specific cases where (e.g.), it is alleged that a given message was
received by our systems, but not received  by our customer's systems.
(Yes, I'm acutely aware of the value of logging to other systems, and
have been advocating that for over a year.  Hasn't happened yet; I'm not
holding my breath.)

So several weeks ago, certain folks at work decided that we needed
to use Akamai to accomplish the "failover" instead of the above
approach.  Thus, in lieu of the above, we'd have somethinng like:

[Our zone file...]
mx.example.net		IN	CNAME	mx.example.net.akadns.com.

mx.example.net		IN	CNAME	mx.example.net.akadns.com.

mx.example.net		IN	CNAME	mx.example.net.akadns.com.

[Customer zone files...]
customer1.example.com	IN	MX	10 mx.example.net.

customer2.example.com	IN	MX	10 mx.example.net.

customer3.example.com	IN	MX	10 mx.example.net.

[Akamai stuff...
$ORIGIN akadns.com.
mx.example.net		IN	A	192.168.5.1
			IN	A	192.168.5.2
			IN	A	192.168.5.3
			IN	A	192.168.5.4

with the ability to switch, given certain criteria, to:
mx.example.net		IN	A	192.168.6.1
			IN	A	192.168.6.2
			IN	A	192.168.6.3
			IN	A	192.168.6.4

or:
mx.example.net		IN	A	192.168.7.1
			IN	A	192.168.7.2
			IN	A	192.168.7.3
			IN	A	192.168.7.4


Now, my recollection was that MX records need to refer to things that
have A records -- nothing else need apply, certainly not CNAME records.

So when our group was asked if we had any issues with the proposal, I
was all set to rip it to shreds -- professionally, of course, as we had
been informed that certain folks "high on the food chain" had a rather
vested interest in the approach.

But when I perused RFC 2821, what I found was:

|5. Address Resolution and Mail Handling
|
|   Once an SMTP client lexically identifies a domain to which mail will
|   be delivered for processing (as described in sections 3.6 and 3.7), a
|   DNS lookup MUST be performed to resolve the domain name [22].  The
|   names are expected to be fully-qualified domain names (FQDNs):
|   mechanisms for inferring FQDNs from partial names or local aliases
|   are outside of this specification and, due to a history of problems,
|   are generally discouraged.  The lookup first attempts to locate an MX
|   record associated with the name.  If a CNAME record is found instead,
|   the resulting name is processed as if it were the initial name.  If
|   no MX records are found, but an A RR is found, the A RR is treated as
|   if it was associated with an implicit MX RR, with a preference of 0,
|   pointing to that host.  If one or more MX RRs are found for a given
|   name, SMTP systems MUST NOT utilize any A RRs associated with that
|   name unless they are located using the MX RRs; the "implicit MX" rule
|   above applies only if there are no MX records present.  If MX records
|   are present, but none of them are usable, this situation MUST be
|   reported as an error.

which, at the time, I interpreted as sanctioning the use of CNAMEs in
determining how to deliver mail.  So I wrote back that the approach
seems technically OK, though there may be old or broken software that
won't cope (since RFC 821 didn't refer to CNAMEs at all anywhere).

But on reviewing it again, I think it's referring to finding a CNAME
instead of an MX -- *not* finding an MX that points to a CNAME
record instead of an A record.

My current copy of _DNS and BIND_ is at work, and I'm unable to fetch it
(for reasons that aren't relevant to this discussion); I'm not able to
find anything definitive on the situation at hand in my older 3rd
edition.

Can someone point me to something clearly definitive on the topic?

Thanks!

Peace,
david
-- 
David H. Wolfskill				david at catwhisker.org
Anything and everything is a (potential) cat toy.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://www.baylisa.org/pipermail/baylisa/attachments/20070604/a56aa27e/attachment.bin>