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

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根表示“不可用” ？

因为那不是您应该使用.invalid的。就像.example是用于本地测试和文档编制。

此外，使用.invalid仍然会引起其他情况-在邮件服务器上进行其他DNS查找和排队以重试一次。

使用该"."格式应该会立即导致严重失败。使MTA立即停止尝试传送。至少这是RFC简介的读取方式。

整个问题涉及几个不同方面，所有这些方面都必须考虑在内，以回答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. 指定Null MX的MX资源记录

   为了表明域不接受电子邮件，它会发布一个MX RR（请参阅[RFC1035]的3.3.9节），其中的RDATA节由首选项号0和零长度标签组成，在主文件中写为“。 ”，作为交换域，表示该域不存在邮件交换器。自“。” 不是有效的主机名，则不能将空MX记录与普通MX记录混淆。 指某东西的用途 ”。” 作为伪主机名，表示没有可用的服务在SRV RR [ RFC2782 ]上建模，其含义类似。

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

（强调）

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

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

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

从RFC2606第2节：

“ .invalid”旨在用于域名的在线构建，这些域名肯定是无效的，并且一目了然是无效的。

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

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