前言：
本文针对根域名同时实现MX&CNAME记录配置可能产生的风险的技术细节进行剖析
针对可能出现的问题风险提出优化办法
对于该问题的解决提出最佳实践的探索
问题背景
主要需求&DNS实现
- 需要使用主域名配置MX记录，实现邮件系统的寻址功能。
- 需要将主域名配置CNAME记录，达到接入CDN实现网站加速/安全加固等目的。
假设有域名abc.com想要实现如上需求，邮件系统指向腾讯企业邮：mxbiz1.qq.com，CNAME指向网宿CDN，abc.com.wscdns.com.
DNS配置:
| 主机记录 | 记录类型 | 记录值 |
|---|---|---|
| @ | MX | mxbiz1.qq.com. |
| @ | CNAME | abc.com.wscdns.com. |
DNS技术实现风险揭示
如上所示的DNS配置确实可以满足绝大部分情况下的用户需求，但是可能会在部分特殊情况下导致MX记录无法被解析，进而影响邮件收发。下面针对该种配置的错误及技术原理进行剖析。
主要剖析当CNAME记录先于MX记录被递归DNS缓存情况下的问题细节。
违反的RFC说明
直接证明配置违反规范的说明：
如果一个域名节点（泛指一个域名）存在CNAME 记录类型，则不应再存在其他DNS记录类型；
如果递归DNS发现该域名存在CNAME，则无需再向权威服务器检查其他RR类型；
RFC1034原文链接及3.6.2片段如下：
https://datatracker.ietf.org/doc/html/rfc1034:
If a CNAME RR is present at a node, no other data should be present; ……
This rule also insures that a cached CNAME can be used without checking with an authoritative server for other RR types.
当域名存在CNAME时，建议递归DNS的行为：
CNAME RRs会在DNS软件中引发特殊操作。当名称服务器无法在与域名关联的资源集中找到所需的RR时，它会检查资源集是否包含具有匹配类的CNAME记录。如果是这样，名称服务器会在响应中包含CNAME记录，并在CNAME记录的数据字段中指定的域名处重新启动查询。此规则的一个例外是，与CNAME类型匹配的查询不会重新启动。）
RFC1034原文链接及3.6.2片段如下：
https://datatracker.ietf.org/doc/html/rfc1034:
CNAME RRs cause special action in DNS software. When a name server fails to find a desired RR in the resource set associated with the domain name, it checks to see if the resource set consists of a CNAME record with a matching class. If so, the name server includes the CNAME record in the response and restarts the query at the domain name specified in the data field of the CNAME record. The one exception to this rule is that queries which match the CNAME type are not restarted.
风险技术细节推导
正常解析场景：
图待补充
之所以大部分情况下不会触发这种问题，是由于递归DNS上原先不存在该域名节点的CNAME记录，从而收到MX记录其请求时，可以正常向域名权威DNS发起解析请求
存在问题的解析场景：
当LDNS存在CNAME缓存时，不会在向abc.com的权威DNS发起解析查询的动作，而是会根据CNAME的域名向其他权威DNS进行查询。
如果CNAME后域名所在的权威DNS上没有该域名的MX记录，则会导致MX记录解析失败。
优化办法
域名配置层面规避
取消CNAME
即将域名的CNAME解析记录停止，重新配置A记录指向CDN加速节点或者安全站点，配置如下：
DNS配置:
| 主机记录 | 记录类型 | 记录值 |
|---|---|---|
| @ | MX | mxbiz1.qq.com. |
| @ | A | <CDN节点/安全站点> |
优势&风险评估
优势：如果CNAME后域名指向的IP较为固定，且CNAME后域名没有智能解析的策略，可以直接使用这种方式，较为简单和快速。
风险：由于CDN节点一般在各省/各国家/各大洲的解析均不相同，且可能根据用户来源进行智能解析，所以直接更改为A记录的方案可能引发一系列问题。
CNAME后域名配置MX
已知目前的abc.com权威DNS域配置如下：
| 主机记录 | 记录类型 | 记录值 |
|---|---|---|
| @ | MX | mxbiz1.qq.com. |
| @ | CNAME | abc.com.wscdns.com. |
结合“风险技术细节推导”章节——存在问题的解析场景可知，LDNS会再根据CNAME的域名向其他权威DNS查询MX记录，那么只需要将CNAME后的域名配置MX记录也可解决该问题：
那么在wscdns.com.权威域增加如下MX记录配置（CNAME后域名所属权威域）：
| 主机记录 | 记录类型 | 记录值 |
|---|---|---|
| abc.com | A | <CDN资源节点ip> |
| abc.com（新增） | MX（新增） | mxbiz1.qq.com.（新增） |
优化后的解析链路：
优势&风险评估
优势：可较为圆满的解决CNAME与A记录冲突的问题。
风险：
如果在abc.com域下的@域名MX记录发生变更，第三方CNAME域名所属的权威DNS没有随之更改，那么可能导致MX记录变更不完全生效的问题。
第三方CNAME域名所属的权威DNS可能无法满足客户在CNAME后域名配置MX的需求，从而导致该种方案无法实施
如果多个子域名配置了相同的第三方CNAME域名，在针对三方CNAME域名配置MX前，需要考虑多个子域名现在及未来是否存在/新增MX记录，避免影响其他子域名的MX记录导致相关风险。
权威DNS应答机制优化
CNAME“拉平”
这里假设CNAME前和CNAME后的域名全部都在一个权威DNS集群上进行解析，那么通过该种技术方案可避免CNAME记录被其他DNS请求到，具体实现细节如下：
（权威DNS集群省略了应答CNAME的步骤，避免CNAME记录被递归DNS解析到）
前提：
CNAME前后域名必须均在同一个DNS权威集群
DNS权威集群需要支持“CNAME拉平”功能
可参考如下DNSPOD相关文档链接：：
CNAME 和 MX 记录冲突的解决？：https://docs.dnspod.cn/dns/dns-resolve-set/
DNSPOD-CNAME加速：https://docs.dnspod.cn/dns/cname-speed/
优势&风险评估
优势：可以省略回复CNAME记录、直接应答A记录，加快解析速度，避免CNAME&MX在递归DNS产生冲突问题
风险：如果有中间人向LDNS发起CNAME记录解析请求，使递归DNS强制缓存CNAME记录，那么可能导致邮件收发失败。
最佳实践探索
如果不能取消CNAME，以及权威DNS应答机制无法优化的情况下，建议使用“CNAME后域名配置MX”方案
虽然会存在一定的风险，但是这是在违反RFC标准下能够避免风险的”最佳实践探索“。
引用参考
技术文章：RFC1034
技术顾问：姜凤波