China.com重新推出了它的免费邮箱服务，后缀是@mail.china.com。查询其DNS设置，得知是coremail驱动的服务。如下是MX记录：
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.
如下是webmail域名的记录：
web.mail.china.com. 500 IN CNAME mail-china-com.icoremail.net.
mail-china-com.icoremail.net. 180 IN A 120.31.134.213
mail-china-com.icoremail.net. 180 IN A 120.31.134.214
它们都指向icoremail.net这个域名。whois该域名，显示由盈世科技coremail.cn所有，网易也用的这套系统。虽然China.com提供免费服务一向很不靠谱，但coremail自身是靠谱的。
疑惑之处在于，前述MX记录是一条CNAME。按照RFC，CNAME不能与其他资源类型共存。对于mail.china.com这个邮件域，肯定需要MX，但它同时又设置了一条CNAME，DNS客户端会如何解析？关于这个问题，ISC的Mark Andrews有2封回复信。
其一：
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.and
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
node.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 protected] as
[email protected].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
clean setup.
这个问题讨论过多次。总体上一个zone不要设置为CNAME，它会导致MX、NS、SOA等其他类型记录查询不正常，参考这篇文档。