使用与主机名不匹配的 CNAME 替换 MX 记录

使用与主机名不匹配的 CNAME 替换 MX 记录

今天有 5 家公司都使用 Google 的电子邮件服务

example1.com.         3w   IN      MX  10   mail.Google.com.
example2.com.         3w   IN      MX  10   mail.Google.com.
example3.com.         3w   IN      MX  10   mail.Google.com.
example4.com.         3w   IN      MX  10   mail.Google.com.
example5.com.         3w   IN      MX  10   mail.Google.com.

下周我们将使用另一家供应商(思科)。我们可以在 MX 中指向 A 或 CNAME 吗?

example1.com.         3w   IN      MX  10   myCNAMEToCisco.example.com.
example2.com.         3w   IN      MX  10   myCNAMEToCisco.example.com.
example3.com.         3w   IN      MX  10   myCNAMEToCisco.example.com.
example4.com.         3w   IN      MX  10   myCNAMEToCisco.example.com.
example5.com.         3w   IN      MX  10   myCNAMEToCisco.example.com.

我的想法是,我可以换成myCNAMEToCisco.example.com其他任何供应商。我担心的是,当客户说“是”时,可能会出现一些奇怪的验证,helo domain.com并且 220 响应可能包含意外的主机名或域名。

以这种方式使用电子邮件中的 CNAME 或 A 记录是否存在问题?

答案1

MX如果你将记录指向记录,这肯定会产生问题,CNAME因为这违反了标准。最清楚的解释是RFC2181 §10.3

10.3. MX 和 NS 记录

用作 NS 资源记录的值或 MX 资源记录的值的一部分的域名不得是别名。不仅规范在这一点上很明确,而且在这两个位置使用别名既不能像希望的那样发挥作用,也不能很好地实现可能导致这种方法的抱负。此域名必须具有一个或多个地址记录作为其值。目前这些将是 A 记录,但将来提供寻址信息的其他记录类型也可能被接受。它也可以有其他 RR,但绝不能有 CNAME RR。

搜索 NS 或 MX 记录会导致“附加部分处理”,其中与所搜索记录的值相关的地址记录将附加到答案中。这有助于避免在第一次进行查询时很容易预料到的不必要的额外查询。

附加部分处理不包括 CNAME 记录,更不用说可能与从别名派生的规范名称相关联的地址记录。因此,如果别名用作 NS 或 MX 记录的值,则不会返回带有 NS 或 MX 值的地址。这会导致每次查询都产生额外的查询和额外的网络负担。DNS 管理员只需在更新或安装时解析别名并将规范名称直接放入受影响的记录中一次,即可轻松避免这种情况。在某些特殊的困难情况下,NS 查找结果中缺少附加部分地址记录可能会导致请求失败。

你可能能够通过搜索引擎找到轶事证据一些DNS 和 MTA 软件支持此功能,但这应被视为例外,而不是规则。大多数软件作者不会将缺乏此支持视为错误。始终避免将记录MX指向CNAME


你现在面临的最大问题是,你示例中记录的 TTLMX都是三周,而你的更改是下周。我强烈建议您请求延迟此切换,并将 TTL 降低到大约十分钟。切换完成后,您可以再次提高 TTL。

相关内容