一、问题来源

自我们CloudXNS系统开通了客服QQ后，被问到最多的问题就是：“为什么你们系统会提示MX和CNAME不能共存，但我用别的域名解析系统都没有这样的提示呀？”

网站建设哪家好，找创新互联建站！专注于网页设计、网站建设、微信开发、小程序开发、集团企业网站建设等服务项目。为回馈新老客户创新互联还提供了额尔古纳免费建站欢迎大家使用！

原来，很多站长们需要使用到cdn，大部分加速服务提供的都是CNAME模式；而同时，MX企业邮件记录也必须配置到同一个节点下。由于很多系统在域名配置管理时并没有做记录的互斥限制，按照大家在别的系统中的配置习惯搬到我们CloudXNS之后，却没法奏效。

因此就出现了如上问题。

二、技术剖析

RFC 1034（http://tools.ietf.org/pdf/rfc1034）章节3.6.2中指出：

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.

大意就是说如果CNAME资源记录出现在一个域名节点，为了确保不会出现不同的解析结果，这个域名节点将不再接受其他记录值。

我们来测试一下。

假设为DNS域chinatesters.cn注册了下面的两条记录：

                    @    MX       10  mx.ym.163.com.

                    @    CNAME        fastweb.com.cn.

下面是在递归服务器（不能使用该域的授权服务器）上dig查询的结果：

         查询CNAME返回如下：

        查询MX返回如下：

我们可以看到MX记录查询的结果与上文中注册记录并不一致，而为其CNAME记录值所配置的MX记录，即对CNAME记录做的递归查询得到的结果。

但如果在递归服务器的CNAME记录TTL过期后再来做查询，只是把查询的顺序颠倒， （即先查询MX记录，再查询CNAME记录）则有可能得到期望的正确结果。

总结一下，递归DNS服务器在查询某个常规域名记录（非CNAME记录）时，如果在本地cache中已有该域名有对应的CNAME记录，则会开始用该别名记录来重启查询。上文中dig查询MX记录测试示例即对应于这种情况。

因此，即使某些域名解析系统网页上并未限制用户同时填写CNAME和MX的操作，但只要将CNAME和MX配置到一起，上述问题也一定是存在的，它会导致邮件服务偶尔出现异常。

实际上除了CNAME和MX不能共存外，已经注册了CNAME类型的域名记录是不能再注册除DNSSEC相关类型记录（RRSIG、NSEC等）之外的任何其他类型记录（包括MX、A、NS等记录）。理由同上，这里就不一一做演示了。

三、解决方案

我们CloudXNS系统在标准记录类型上的互斥关系设定及提醒是完全遵循DNS规范的，而这样的规范设定却对大家在域名配置上造成了一定困扰。

不过，细心的网友发现，CloudXNS具备隐式CNAME扩展记录类型（即LINK记录），它可以隐藏当前这一层的配置，直接接管下一层的结果。因此，CloudXNS也可以获得“将MX和CNAME共同配置”类似的解决方案。

如下图所示，在www下配置CNAME到CDN服务提供商，然后在@下配置MX和LINK记录，将www作为被LINK的域名。

我们用dig验证一下：

        查询MX返回如下：

        查询CNAME返回如下：

当然，这样的配置也同样会存在邮件服务偶尔失效的问题。

因此，CloudXNS系统即将为大家给出一个终极解决方案，可以完美的解决这个问题！届时，您的邮件服务可以永远正常使用，同时也可享受到网络加速的快感，可谓兼得鱼和熊掌。

我们将在2015年2月第二周推出网络云安全加速的功能，该功能模块会整合我司（@北京快网）CDN服务提供的部分核心内容，包括访问加速、网站防火墙、防盗链、DDOS防护、CC防护等多项加速及安全保护功能。届时您只需要给您的域名一个开关点击，一切即可高枕无忧。

悄悄透露部分页面：

四、参考文献

RFC 1034英文原版：http://tools.ietf.org/pdf/rfc1034

中文译文参考：http://download.csdn.net/detail/weicq2000/4627738