DNS知识：解决DNS中MX与cname冲突问题DNS拉平cname智能加速

解决DNS中MX与cname冲突问题 DNS拉平 cname智能加速

---

文章目录

今天学到了关于DNS的知识

感谢cr群中ah与熊良辰提供话题技术思路讨论环境：解决方案：使用DNSPod实现DNS拉平/cname智能加速原理介绍：优点：缺点：结论： 今天学到了关于DNS的知识 感谢cr群中ah与熊良辰提供话题技术思路

借鉴网址
https://zhujicankao.com/63594.html

讨论环境：

  1.在网站前置cdn进行嵌套情况下，解决cname解析缓慢，与mx邮箱解析不兼容问题,因为RFC定义里 只有A/AAAA/URL记录能和MX共存,MX解析与cname解析是不能共存的，
  2.在一级域名情况下，一些dns解析不支持@的cname记录解析

MX与cname介绍

解决方案：使用DNSPod实现DNS拉平/cname智能加速

1.拉平原理就是返回CDN读取到的你的cname记录的A记录
2.但DNSPod拉不平DNSSEC的DS记录

原理介绍：

DNS厂商做的智能判断策略，将cname转换为a记录，实现了非定义的共存，与RFC的规范相同。
1.cname记录和mx记录本质上是冲突的
2.dnspod开启了cname加速以后，等于把主域名以A记录形式给反馈，设置的时候是cname形式，他实现是用A记录
3.解决了mx与cname冲突问题，本质上变成了A与mx记录

优点：

看过上图后发现，dnspod的cname加速会很快，一般cname都要经过多层解析，而dnspod直接给最终结果的一个ip了
2.阿里就严格遵照rfc规则来的，所以解析速度会很长

缺点：

  目前dnspod的cname加速是按照运营商来缓存结果他没办法判断你的省份的就近的最终ip是什么，开这个功能只是省去了cname解析中的时间，但不会提高访问质量,反而会有副作用
  因为他只会返回一个和你一个运营商的ip作为结果，但这个节点在哪里是不知道的，可能上海电信解析到内蒙古电信都有这个可能。理论上解析的结果来自于一段时间内第一个人访问的位置。
  例如：A在呼和浩特 用的电信 第一次解析 回源之后CDN分配了乌兰察布电信，一段时间内电信用户访问应该都会走乌兰察布电信

结论：

  建议用子域名来mx做邮箱解析
除非你可以用anycast的cdn，那就可以规避这个问题，不然为了用户访问质量，还是建议关掉这个功能
  但关了以后mx和cname就无法共存了

至此 总结结束~