众所周知 , CNAME记录一向不能存在于裸域下 , 否则会导致一系列尴尬的问题 . CNAME又称别名记录 , 将一个域的记录指向另一个域 , 而不是一个IP , 这样适合CDN根据来访地址分配节点 ; 也可以避免某些虚拟主机频繁换IP你又懒得跟着他一起换的问题。。。。 那么为啥它不能放在裸域上呢 ? 因为它 “别名” 的性质 . 假设abc.com被CNAME到了xyz.com , 访问abc.com时返回xyz.com的IP , 看上去没啥问题 . 但是如果请求MX记录 , NS就懵了 : 我应该去找abc.com下的MX , 但是它已经CNAME给了xyz.com , 我应该去查xyz.com的MX呀 ! 一番踌躇后 , NS选择了后者 . 于是你的邮件就华丽丽地丢了 . 而且 , 裸域CNAME不只影响MX , 还影响NS和SOA , 这才是最可怕的 . 所以IETF规定裸域不准CNAME , 各种NS服务商也会禁止用户这样做 . 但是 , 域名前面的www白白增加了域名长度 , 既不美观也没逼格 . 于是 , 各大NS推出了私有记录类型 , 来用特殊方式允许裸域使用CNAME . 目前博主已知的几家支持这种私有记录的有 : - [Dnsimple](https://dnsimple.com) 的ALIAS记录 - [DNS Made Easy](https://www.dnsmadeeasy.com/) / [Amazon Route53](https://aws.amazon.com/route53/) 的ANAME记录 - [Cloudflare](https://www.cloudflare.com) 的CNAME记录 其实这些记录内容都是一样的 , 只是叫法不同 . 而且除了Cloudflare之外都是收费的 , 不愿意花银子的同学就可以用Cloudflare . 这些私有记录实现裸域CNAME的方式大同小异 , 博主用的Dnsimple , 就拿它举例吧 . 假设abc.com使用了高端大气的ALIAS记录 , NS收到对abc.com的请求后也变成递归DNS , 向ALIAS指向的xyz.com请求A记录 , 再将返回的A记录当作A记录给请求方 . 这样在dig中看 , abc.com其实是个A记录 . 如果请求abc.com的MX , NS一看这裸域没有CNAME , 就干脆地给了abc.com的MX . 就这样 , 实现了裸域无痛CNAME . 目前[https://gstc.me\](https://gstc.me) 就由Dnsimple的ALIAS记录驱动 . 大伙可以去dig下 .