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

Question

今天，我们有 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 记录有什么问题吗？

Answer 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.

您现在面临的最大问题是MX示例中记录的 TTL都是三周，而您的更改是next week。我强烈建议您请求延迟此切换，并将 TTL 降低到大约 10 分钟的某个时间。切换完成后，您可以再次提高 TTL。