mail.china.com. 398 IN CNAME mail.china.com.cachecn.com.
mail.china.com.cachecn.com. 300 IN MX 10 mx-mail-china-com.icoremail.net.
web.mail.china.com. 500 IN CNAME mail-china-com.icoremail.net.
mail-china-com.icoremail.net. 180 IN A 220.127.116.11
mail-china-com.icoremail.net. 180 IN A 18.104.22.168
Those with developers that don’t read RFC 1034 which tried to prevent
this from happening.
The domain system provides such a feature using the canonical name
(CNAME) RR. A CNAME RR identifies its owner name as an alias, and
specifies the corresponding canonical name in the RDATA section of the
RR. If a CNAME RR is present at a node, no other data should be
present; 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.
3. Start matching down, label by label, in the zone. The
matching process can terminate several ways:
a. If the whole of QNAME is matched, we have found the
If the data at the node is a CNAME, and QTYPE doesn’t
match CNAME, copy the CNAME RR into the answer section
of the response, change QNAME to the canonical name in
the CNAME RR, and go back to step 1.
Otherwise, copy all RRs which match QTYPE into the
answer section and go to step 6.
This is a singular CNAME (“copy the CNAME”) record without any other
data present at the node (“the data at the node is a CNAME”). Now
DNSSEC relaxes this slightly to allow RRSIG and KEY to co-exist
with a (singular) CNAME record.
MTA’s that follow RCF 822 will rewrite email@example.com as
MTA’s that follow RFC 2822 or RFC 5322 won’t preform the rewrite.
The better solution for this would be two MX records.
mail.china.com. IN MX 10 mx-mail-china-com.icoremail.net.
mail.china.com.cachecn.com. IN MX 10 mx-mail-china-com.icoremail.net.
It would be a alternative to a CNAME.
You you are publishing email addresses as user@domain then there
really should be a MX record at domain. There really doesn’t need
to be a double level of indirection.
Today you get:
;; ANSWER SECTION:
mail.china.com. 500 IN CNAME mail.china.com.cachecn.com.
mail.china.com.cachecn.com. 201 IN MX 10 mx-mail-china-com.icoremail.net.
A better cleaner setup would be:
;; ANSWER SECTION:
mail.china.com. 500 IN MX 10 mx-mail-china-com.icoremail.net.
I suspect that almost all of the presure to change the CNAME behaviour
for MX records came about because people abused CNAME for HTTP. It
has never been hard to add new record types to the DNS. People
just thought it was hard so they never started the process. As a
result SMTP behaviour was changed rather than the simple thing of
adding a record for HTTP to the DNS.
You end up with stupid sets of records like these because people
wern’t willing to do the little bit of effort to actually get a