文章目录
  1. 1. 确认问题所在
  2. 2. 技术剖析
  3. 3. 解决方法

前不久为了提升自己的逼格,设置了一个域名邮箱,之前用着还蛮好的,收件发件速度都不错,也没有出现丢件的情况。不过,最近查看我的域名邮箱时,发现最近一段时间内一封邮件也没有收到,真是奇怪呢,即使没什么订阅服务,起码也有广告吧,我不敢相信腾讯能把邮箱过滤系统做得如此好。

所以我马上用QQ邮箱给自己的域名邮箱发了个文件,发现是可以收到的,都是自家服务,能收到也不能说明什么问题吧。我又用126、163、阿里邮箱一一测试了一下,发现果然是收不到邮件,直接提示我“对方服务器未响应,重新投递中”,之后就是“发送不成功,详细原因请查看退信”,真是坑爹啊!我不甘心,又用outlook、gmail发了一下,发现可以收到邮件,我勒个CACA……什么鬼?我第一反应就是国内的服务果然是不行,辣鸡一个,第二反应是看来腾讯是不打算维护这个服务了吧,毕竟免费,免费没好货……

直到我查看了QQ邮箱的帮助中心,发现了这么一段话,“有些域名提供商的的域名设置中,如果之前存在纯域名的CNAME记录,则可能会导致MX记录无法生效。”才慢慢意识到可能是我DNS设置的问题,腾讯表示很受伤害,无故躺枪(o´・ェ・`o),正巧最近上的网络操作系统也正在配置DNS服务,所以让我们来一起看看这其中的问题到底出在哪里吧。

确认问题所在

经过查询资料,发现,果然是DNS的锅,腾讯表示不背这个锅,哈哈。我的域名下有个裸域CNAME,如下所示,在此的基础上,又有个裸域MX,MDZZ~。在传统的DNS服务商的设置下,CNAME和MX配置不在同一个节点下,会使域名配置系统出现记录互斥现象,就像我现在所遇到的这样,但是我这个只是其中一种而已,更多的问题有待大家发现,哈哈~以下我们来具体剖析一下。

1
2
CNAME @ - pages.coding.me.
MX @ 10 mxdomain.qq.com.

技术剖析

进行到现在,明眼人一看就知道这应该是早期设计上留下的问题了吧,所以我们去RFC(Request For Comments(RFC),是一系列以编号排定的文件。基本的互联网通信协议都有在RFC文件内详细说明。)看看。果然不出我所料,找到这么一个文件。

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记录指向了一个域名节点,为了确保不会出现不同的解析结果,那么这个域名节点将不在接受其他的记录值了。

在Windows上cmd通过nslookup查询mx,得到结果如下:
nslookup查询MX
在Linux上通过dig查询mx,得到结果如下:
dig查询mx

果然没错,竟然出现的是CNAME记录中指向的域名节点的MX记录解析,更尴尬的是pages.coding.me又CNAME记录指向了pages.coding.net,coding.net的MX记录指向的是webmaster.ffdns.net,看得我尴尬症都犯了……

从上面我们可以得知我们设置的MX记录并没有生效,取而代之的反而是我们设置的CNAME记录指向的域名节点设置的MX记录。所以可以想象到我的域名邮箱的邮件实际上请求的地址是webmaster.ffdns.net,而不是我的域名邮箱所在的mxdomain.qq.com,因此我的邮箱就收不到邮件了,那么又有一个问题来了,为什么国外的outlook、gmail发的邮件我能够收到呢?为什么他们能找到我的邮箱地址,好奇怪啊!额,这个我现在还没找到原因,在这里先标记一下吧,待日后找到答案,再来开篇文章详谈。

总结一下,递归DNS服务器在查询某个常规的域名记录(非CNAME记录)时,如果在服务器本地cache中找到该域名有对应的CNAME记录,则会优先使用该别名记录来重新启用查询。上面的nslookup和dig都向我们显示了这种情况的存在。

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

实际上除了CNAME和MX不能共存外,已经注册了CNAME类型的域名记录是不能再注册除DNSSEC相关类型记录(RRSIG、NSEC等)之外的任何其他类型记录(包括MX、A、NS等记录)。原因同理可得,哈哈。

这大概也就是为什么一般我们的网站都是以www开头的域名访问,而不直接使用裸域作A记录、CNAME记录访问。但是绝大多数网站都能使用裸域访问,我们比较常规的做法都是设置301或是302跳转来解决这个问题的。

解决方法

  1. 不要同时在裸域下使用CNAME记录和MX记录(哈哈,说了跟没说一样)
  2. 让CNAME记录下的域名节点使用的MX记录指向和你裸域MX指向同一个域名节点(这个是可行的,毕竟国内比较好的邮件服务商屈指可数,就那么几家)
  3. 让裸域CNAME记录到自己的www域名节点上,然后让www域名节点CNAME记录到pages.coding.me域名节点上,最好让MX记录指向mxdomain.qq.com域名节点(即你的域名邮箱服务商的地址)。这种做法类似于第4中的方案,我用的是DNSPod提供的服务,不知道是DNSPod家的特性,还是其他家也存在相同的效果,这个后面有时间的话再进行检验。

所以我就果断将自己的DNS解析改为如下:

1
2
3
CNAME @ - www.krzer.com.
CNAME www - pages.coding.me.
MX @ 10 mxdomain.qq.com.

然后我们来测试一下:
同样的,在Windows上cmd通过nslookup查询mx,得到结果如下:
nslookup查询MX
同样的,在Linux上通过dig查询mx,得到结果如下:
dig查询MX

完美,查询的结果都符合预期,再试试用126、163、阿里邮箱发一下邮件看看,(咚咚咚,你的快递到了~,额,不小心又开始自己胡思乱想了@_@),邮件秒收,完美~(可是心里总是感觉慌慌的,总觉得哪里不太对劲,时间是检验真理的唯一标准,这个得看看今后的表现怎么样了,就先这样吧~)

  1. 此外网上还提供了一种方法,有些DNS域名解析系统(例如CloudXNS)具备隐式CNAME扩展记录类型(即LINK记录),它可以隐藏当前这一层的配置,直接接管下一层的结果。因此,CloudXNS也可以获得“将MX和CNAME共同配置”类似的解决方案。

如下图所示(此图来源于网上),在www下配置CNAME到CDN服务提供商,然后在@下配置MX和LINK记录,将www作为被LINK的域名。

CloudXNS解决方案

OK,就先写到这里吧,这些就目前来看,都是不完美的解决方案,可能偶尔会存在邮件服务失效的问题吧,但是目前我也拿不出证据说丢件什么的,在我的测试下,现在都表现得很完美呢!第一次写博客写到深夜,竟然一点都不觉得困,感觉慢慢喜欢上了写文章,喜欢这种思想到文字之间,慢慢沉淀的感觉,或许我以后可能会成为一个写点杂文的作家呢,哈哈!(再一次陷入深深的意淫中,无法自拔……)好了,该睡觉了,别吹牛了,晚安,美好的世界!

文章出自:Krzer http://www.krzer.com/版权所有。本站文章除注明出处外,皆为作者原创文章,可自由引用,但请注明来源。

文章目录
  1. 1. 确认问题所在
  2. 2. 技术剖析
  3. 3. 解决方法