为什么需要 RFC 7505 (Null MX)？

Question

IETF 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，同样指定了“'的目标”。意味着该服务在该域中绝对不可用。” 所以我想我的问题是：

invalid既然已经提供了这个功能，为什么要使用 DNS 根来表示“不可用” ？

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 节），其中包含一个由首选项编号 0 和零长度标签组成的 RDATA 部分，在主文件中写为“. "，作为交换域，表示一个域不存在邮件交换器。自从 ”。” 不是有效的主机名，空 MX 记录不能与普通 MX 记录混淆。 指某东西的用途 ”。” 作为一个伪主机名，意味着没有可用的服务是在 SRV RR [ RFC2782 ] 上建模的，它具有类似的含义。

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

（强调）

正如这里所指出的，“空 MX”的实现细节基于来自SRVRR 类型的已经建立的模式。模仿这一点是有意义的，因为SRVRR 类型或多或少是 RR 类型的通用版本MX。

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

那么，为什么不利用.invalid呢？

来自RFC2606 section2：

“.invalid”用于在线构建肯定无效且一目了然无效的域名。

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

当然，它可以以某种不同的方式实现，但他们选择了使用的最小方法.，这不是有效的主机名，因此无论如何都不会干扰正常使用。