Зачем нужен 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, также указывает, что «цель». означает, что услуга явно не доступна в этом домене. " Итак, я предполагаю, что мой вопрос:

Почему мы должны использовать корень DNS, чтобы означать «недоступен», когда invalidуже выполняет эту функцию?

Потому что это не то, что вы должны использовать .invalidдля. Как будто .exampleэто предназначено для локального тестирования и документации.

Кроме того, использование по- .invalidпрежнему приводит к дополнительным вещам - дополнительным поискам DNS и очередям на почтовом сервере для повторных попыток выполнить одну из них.

"."Предполагается, что использование формата приведет к немедленному серьезному сбою. Причинение MTA немедленно прекратить попытки доставки. По крайней мере, так выглядит введение в RFC.

Вопрос в целом затрагивает несколько разных аспектов, которые необходимо учитывать, чтобы ответить, почему RFC7505 добавляет что-то полезное.

Во-первых, определение порядка доставки почты до RFC7505 не имеет способа четко указать, что не следует предпринимать попытки доставки почты для имени, имеющего адресные записи.

Из RFC7505 раздел 1 :

У клиентов SMTP есть предписанная последовательность для идентификации сервера, который принимает электронную почту для домена. Раздел 5 [RFC5321] описывает это подробно; по сути, 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 (см. Раздел 3.3.9 [RFC1035]) с разделом RDATA, состоящим из номера предпочтения 0 и метки нулевой длины, записанной в основных файлах как ". ", как домен обмена, для обозначения отсутствия почтового обменника для домена. Поскольку "." не является допустимым именем хоста, пустая запись MX не может быть перепутана с обычной записью MX. Использование "." в качестве псевдо-имени хоста, означающего, что никакая доступная услуга не смоделирована на SRV RR [ RFC2782 ], где оно имеет аналогичное значение.

   Домен, который рекламирует нулевой MX, НЕ ДОЛЖЕН рекламировать другие MX RR.

(выделение добавлено)

Как отмечено здесь, подробности реализации для «нулевого MX» основаны на уже установленном шаблоне из SRVтипа RR. Имеет смысл имитировать это, поскольку SRVтип RR более или менее является обобщенной версией типа MXRR.

Итак, решение по существу было принято уже при определении SRVтипа RR .

Итак, почему бы не использовать .invalid?

Из RFC2606 раздел2 :

«.invalid» предназначен для использования в онлайновом построении доменных имен, которые, несомненно, являются недействительными и которые, на первый взгляд, являются недействительными.

Как можно увидеть здесь, этот зарезервированный TLD предназначен для потребления человеком. Нет прецедента определения специальной обработки этого в программном обеспечении.

Конечно, это могло бы быть реализовано каким-то другим способом, но они решили использовать минимальный подход к использованию ., который не является допустимым именем хоста и, таким образом, не мешает нормальному использованию в любом случае.