为什么裸域名不可以设置 CNAME？

有效的防止不懂DNS的瞎J8用，跟设想的完全不一致后不是折腾客服就是去喷DNS服务……

可以设置的。但是不是标准的实现。

根域名CName和MX记录会冲突。
这个一搜索就出来了。

可以设置，但是会爆炸！

@Delbert 真的吗？可是它跟MX纪录是不一样的东西，为什么会冲突啊？

CloudFlare 应该是用的 AnyCast 技术吧，超脱了 CNAME 的范畴了。

http://www.faqs.org/rfcs/rfc1034.html see 3.6.2

总之rfc允许根域名设置cname，但是 "If a CNAME RR is present at a node, no other data should be present"

@Pseric 自行搜索 “”CNAME 和 MX 记录冲突

CNAME和其他记录的名称相同都会产生一些问题。

裸域名可以设置CNAME啊，DNSPOD可以。而且就算cname和mx冲突了，还不影响dnspod解析。。

只能说CloudFlare表示无压力……

我跳进过这样的坑，和MX记录冲突了

@TakanashiAzusa DNSPOD自己的协议，不符合RFC的

@wy315700 能用就好ww，而且QQ邮箱那个和cname的必定冲突。。

@TakanashiAzusa 以后挪走了就会知道了，非标准还是少用

如果同时设置了 CNAME (example.cname.net) 和 MX (mail.example.com) 记录，那么在查询 MX 记录的时候，DNS 服务器应该返回 CNAME example.cname.net 然后让客户端继续查询 example.cname.net 的 MX 记录还是直接返回 MX mail.example.com？

CNAME 意思就是所有东西转到你设置的记录，所以 MX 就强行被转跑了啊

如果不需要 MX 记录，那么 cname 没问题，否则会有可能引起冲突。

我的博客 ttt.tt 就没设置 MX 记录，所以设置了 cname 记录

| ू•ૅω•́)ᵎᵎᵎ 我也设置过，没爆炸…

我就是用的dnspod，裸域名cname到一家cdn，mx到qq域名邮箱。两年半了没出啥问题…

@dant 原来如此，你这么说明就懂了！谢谢，受教了！

@aiguozhedaodan 丢件了你也不知道啊
@sumhat anycast和cname有任何关系？

@geekzu 没什么关系，只是想到了昨天的一个贴子 https://www.v2ex.com/t/204308

When a DNS resolver encounters a CNAME record while looking for a regular resource record, it will restart the query using the canonical name instead of the original name. (If the resolver is specifically told to look for CNAME records, the canonical name (right-hand side) is returned, rather than restarting the query.)

An alias defined in a CNAME record must have no other resource records of other types (MX, A, etc.). (RFC 1034 section 3.6.2, RFC 1912 section 2.4) The exception is when DNSSEC is being used, in which case there can be DNSSEC related records such as RRSIG, NSEC, etc. (RFC 2181 section 10.1)

1. 首先裸域是可以设置CNAME的，但是根据RFC，如果设置了CNAME就不能设置其他记录，DNSPod现在可以同时在裸域添加MX和CNAME记录，但是在添加CNAME记录的时候会提示与MX记录有冲突。

2. 很多域名会在裸域设置MX记录，导致CNAME和MX记录冲突问题，原因就是17楼@dant提出的问题，如果递归DNS是根据RFC协议，先查找CNAME，再找CNAME值的MX，如果CNAME记录值上没有设置MX记录，这时候就会导致MX失效。如果递归DNS没有按照RFC协议直接查询MX记录，或者在当前递归上没有缓存CNAME记录，那么这时候MX就不会失效。

3. 如果一定要同时设置MX记录和CNAME记录，DNSPod已经开始部署解决方案，可以部分解决CNAME记录和MX记录冲突的问题。

如果用户的CNAME记录链一直到最后的A记录都在DNSPod上解析，并且所有CNAME指向的域名都开启了CNAME加速功能（如果CNAME完全指向本域名的其他子域名则可以不用开启CNAME加速），那么我们在解析CNAME记录的时候会检查该子域名是否设置了MX记录，如果设置了MX记录则直接返回最终的A记录，不再返回中间的CNAME。这样递归上就不会同时存在CNAME和MX记录，从而避免找不到MX记录。

该功能已经在免费套餐上灰度了一段时间，10个节点灰度了2个节点：113.108.80.138和125.39.208.193，预计2个月时间可以全部灰度完成。

具体可以看下面的测试用例，前面两个是已经灰度的情况，第三个是未灰度的情况。
~$ nslookup loveping.xyz 113.108.80.138
Server: 113.108.80.138
Address: 113.108.80.138#53

Name: loveping.xyz
Address: 1.1.1.1

~$ nslookup loveping.xyz 125.39.208.193
Server: 125.39.208.193
Address: 125.39.208.193#53

Name: loveping.xyz
Address: 1.1.1.1

~$ nslookup loveping.xyz 112.90.82.194
Server: 112.90.82.194
Address: 112.90.82.194#53

loveping.xyz canonical name = cnametest.loveping.xyz.
cnametest.loveping.xyz canonical name = cnametest1.loveping.xyz.
Name: cnametest1.loveping.xyz
Address: 1.1.1.1


4. 当然这个方案存在的缺陷也比较明显，就是所有域名都要在DNSPod解析才能解决，那有没有其他解决方案呢，当然是有的。前面说了从RFC来看，应该先查找CNAME，再找CNAME的MX记录。那么对应的解决方案就是让你的CDN厂商在CNAME域名上增加与裸域相同的MX记录，当然如果CNAME到的是自己的其他域名的话，可以自己增加，同时为了兼容未严格按照RFC协议实现的递归DNS，裸域的MX建议继续保留。

这个方案好像非常好，可以完美的解决CNAME和MX冲突的问题，但也只是看上去完美而已，如果你不是大客户的话，CDN厂商没有可能给你单独支持的，因为支持该功能，CDN厂商需要给你分配完全单独的CNAME域名和调度系统，不能和任何其他域名重复，并且在需要修改调度的时候，需要同时修改该CNAME域名的调度，MX记录有修改时也需要联系CDN厂商给你改。而且是每多一个客户，就需要多维护一套，所以小客户是不可能使用的。

@TakanashiAzusa
@aiguozhedaodan
@wy315700
@dant


每条记录都有设置一个TTL，如果本地DNS对这个TTL严格遵守的话，MX是否被CNAME递归取决于哪条记录值先被获取。
同一域下同时存在MX和CNAME的情况下，
如果本地DNS更新MX记录值在前面，那么MX和CNAME的值在这整个TTL的时间内都是正确的；
但如果本地DNS先更新CNAME记录值，那么你的MX的最终结果会被CNAME影响，会递归到被CNAME的域名下重启查询。

具体测试可以参照我写的这篇文章： http://www.tuicool.com/articles/miEvUnb
大家也可以照着我文中的测试步骤重现下。

由于我们CloudXNS中限制了共存关系，其中的共存测试举例就是拿到dnspod上去配置和测试的。

至于你们说的配置在dnspod上多年并未察觉，只是因为邮件本来就不是一个即时的沟通工具，晚个TTL再收发也不会有什么感觉。不是吗？

@CinderellaCiCi 我想问下，就是如你所言，邮件服务有时候解析会有问题，那如果这个时间段有人发了邮件过来的话，应该是没办法收件的，那这份邮件会被邮件服务提供商自动重发么（还是说这个看不同的服务商的策略？有些丢了就是丢了

从前有DNS服务商不提示这个问题，我就掉进收不到邮件的坑里了