为什么需要 RFC 7505（Null MX）？

Question

因特网工程任务组RFC 7505描述明确不应接收电子邮件的域/主机的 MX 记录。这是通过将 MX 指向域名系统根来实现的。例如，

nomail.example.com. 86400 IN MX 0 "."

为什么需要这样做？据我了解，使用 TLD 下的域名可以明确驳斥invalid。例如，

nomail.example.com. 86400 IN MX 0 "spam.invalid."
nomail.example.com. 86400 IN MX 10 "null.invalid."

我看到 RFC 2782 DNS SRV 同样指定“目标为 '.' 表示该服务在此域中绝对不可用。” 所以我想我的问题是：

为什么我们要使用 DNS 根来表示“不可用”，而它invalid已经发挥了这一功能？

Answer 1

因为这不是你应该用.invalid的东西。就像.example它是用于本地测试和文档一样。

此外，使用.invalid仍然会导致其他事情发生 - 额外的 DNS 查找和在邮件服务器上排队以重试，这是我脑海中想到的一次。

使用该"."格式应该会导致立即发生硬故障。导致 MTA 立即停止尝试传送。至少 RFC 的简介是这么写的。

Answer 2

整个问题涉及几个不同的方面，需要考虑所有这些方面才能回答为什么 RFC7505 增加了一些有用的内容。

首先，RFC7505 之前对如何进行邮件传递的定义没有办法明确地表明不应该对具有地址记录的名称进行任何邮件传递尝试。

从RFC7505 第 1 节：

SMTP 客户端具有用于识别接受域电子邮件的服务器的规定顺序。[RFC5321] 第 5 节详细介绍了这一点；本质上，SMTP 客户端首先查找 DNS MX RR，如果未找到，则返回查找 DNS A 或 AAAA RR。因此，这会用电子邮件服务语义使 DNS 记录（具有不同的主要任务）过载。

如果域没有 MX 记录，发件人将尝试将邮件投递到域的 A 或 AAAA 记录中的地址的主机。如果 A/AAAA 地址没有 SMTP 侦听器，则在发送邮件传输代理 (MTA) 放弃之前，邮件将反复尝试投递很长时间（通常为一周）。如果邮件被错误转发，这将延迟通知发件人，并会消耗发件人的资源。

本文档定义了一个空 MX，它将导致对域的所有邮件传递尝试立即失败，而无需域创建专用于阻止传递尝试的 SMTP 侦听器。

然后就是 RFC7505 如何实现这一点的问题（IN MX 0 .）。

从RFC7505 第 3 节：

3. 指定空 MX 的 MX 资源记录

为了表明某个域不接受电子邮件，它会通告单个 MX RR（参见 [RFC1035] 的第 3.3.9 节），其中包含一个 RDATA 部分，该部分由首选项编号 0 和一个零长度标签组成，在主文件中写为“.”作为交换域，以表示该域不存在邮件交换器。由于“.”不是有效的主机名，因此空 MX 记录不会与普通 MX 记录混淆。 使用“.”作为伪主机名表示没有可用的服务，这是以 SRV RR 为模型的 [RFC2782] 中也有类似的含义。

通告空 MX 的域不得通告任何其他 MX RR。

（强调添加）

如这里所述，“null MX”的实现细节基于SRVRR 类型中已建立的模式。模仿它是有意义的，因为SRVRR 类型或多或少是MXRR 类型的通用版本。

因此，在定义时，基本上已经做出了决定SRVRR 型。

那么，为什么不使用“.invalid”呢？

从RFC2606 第2节：

“.invalid” 适用于在线构建那些肯定无效的、一眼就能看出无效的域名。

从这里可以看出，这个保留的 TLD 是供人类使用的。在软件中没有定义对此进行特殊处理的先例。

当然，它可以用一些不同的方式来实现，但他们选择采用最小的方法.，这不是一个有效的主机名，因此不会干扰正常使用。