Die Frage als Ganzes berührt einige verschiedene Aspekte, die alle berücksichtigt werden müssen, um zu beantworten, warum RFC7505 etwas Nützliches hinzufügt.
Erstens kann in der Definition der E-Mail-Zustellung vor RFC7505 nicht eindeutig angegeben werden, dass für einen Namen mit Adressdatensätzen keine E-Mail-Zustellungsversuche durchgeführt werden sollten.
Aus RFC7505 Abschnitt 1 :
SMTP-Clients haben eine vorgeschriebene Reihenfolge zum Identifizieren eines Servers, der E-Mails für eine Domain akzeptiert. Abschnitt 5 von [RFC5321] behandelt dies im Detail. Im Wesentlichen schlägt der SMTP-Client zuerst eine DNS-MX-RR nach und greift auf eine DNS-A- oder AAAA-RR zurück, wenn diese nicht gefunden wird. Daher wird ein DNS-Eintrag (der eine andere primäre Aufgabe hat) mit einer E-Mail-Dienstsemantik überladen.
Wenn für eine Domain keine MX-Einträge vorhanden sind, versuchen die Absender, E-Mails an die Hosts an den Adressen in den A- oder AAAA-Einträgen der Domain zuzustellen. Wenn an den A / AAAA-Adressen keine SMTP-Listener vorhanden sind, wird die Nachrichtenübermittlung über einen längeren Zeitraum, normalerweise eine Woche, wiederholt, bevor der sendende Mail Transfer Agent (MTA) aufgibt. Dies verzögert die Benachrichtigung des Absenders bei fehlgeleiteten E-Mails und beansprucht Ressourcen beim Absender.
In diesem Dokument wird ein Null-MX definiert, bei dem alle E-Mail-Zustellungsversuche an eine Domäne sofort fehlschlagen, ohne dass Domänen SMTP-Listener erstellen müssen, um Zustellungsversuche zu verhindern.
Dann ist da noch die Frage, wie RFC7505 dies implementiert ( IN MX 0 .).
Aus RFC7505 Abschnitt 3 :
MX-Ressourceneinträge mit Angabe von Null-MX
Um anzuzeigen, dass eine Domain keine E-Mails akzeptiert, wirbt sie für eine einzelne MX-RR (siehe Abschnitt 3.3.9 von [RFC1035]) mit einem RDATA-Abschnitt, der aus der Präferenznummer 0 und einer Bezeichnung mit der Länge Null besteht und in Masterdateien als "geschrieben ist. msgstr "" "als Austauschdomäne, um anzuzeigen, dass für eine Domäne kein Mail - Austauscher vorhanden ist. Schon seit "." ist kein gültiger Hostname, ein Null-MX-Eintrag kann nicht mit einem normalen MX-Eintrag verwechselt werden.
Die Verwendung von "." Als Pseudo-Hostname bedeutet, dass kein verfügbarer Dienst auf der SRV-RR [ RFC2782 ] modelliert ist, wo er eine ähnliche Bedeutung hat.
Eine Domain, die einen Null-MX annonciert, DARF KEINE andere MX-RR annoncieren.
(Betonung hinzugefügt)
Wie hier angemerkt, basieren die Implementierungsdetails für den "Null-MX" auf einem bereits festgelegten Muster vom SRVRR-Typ. Es ist sinnvoll, dies nachzuahmen, da der SRVRR-Typ mehr oder weniger eine verallgemeinerte Version des MXRR-Typs ist.
Die Entscheidung wurde also im Wesentlichen bereits bei der Definition des SRVRR-Typs getroffen .
Warum also nicht nutzen .invalid?
Aus RFC2606 Abschnitt2 :
".invalid" ist für die Online-Erstellung von Domain-Namen vorgesehen, die mit Sicherheit ungültig sind und auf den ersten Blick offensichtlich ungültig sind.
Wie hier zu sehen ist, ist diese reservierte TLD für den menschlichen Verzehr bestimmt. Es gibt keinen Präzedenzfall dafür, eine spezielle Behandlung in Software zu definieren.
Sicherlich hätte es auf andere Weise implementiert werden können, aber sie entschieden sich für den minimalen Ansatz der Verwendung ., der kein gültiger Hostname ist und daher die normale Verwendung sowieso nicht beeinträchtigt.