Frage Warum ist RFC 7505 (Null MX) notwendig?


IETF RFC 7505 beschreibt MX-Einträge für eine Domain / einen Host, die explizit keine E-Mails erhalten sollen. Dies wird erreicht, indem der MX auf das Domain Name System root verwiesen wird. Zum Beispiel,

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

Warum ist das nötig? Nach meinem Verständnis ist eine explizite Widerlegung durch die Verwendung von Domains unter der TLD möglich invalid. Zum Beispiel,

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

Ich sehe, dass RFC 2782, DNS SRV, ebenfalls angibt, dass "ein Ziel von". bedeutet, dass der Dienst in dieser Domäne nicht verfügbar ist. " Ich nehme an, meine Frage ist:

Warum sollten wir den DNS-Stamm verwenden, um "nicht verfügbar" wann zu bedeuten invalid dient schon diese Funktion?


18
2017-08-13 21:10


Ursprung


Das ist jedoch keine explizite Widerlegung! Es sind nur ungültige Daten. - Michael Hampton♦


Antworten:


Weil das nicht das ist, was Sie verwenden sollen .invalid zum. Mögen .example Es ist für lokale Tests und Dokumentation gedacht.

Zusätzlich mit .invalid verursacht immer noch zusätzliche Dinge - zusätzliche DNS-Lookups und Warteschlangen auf dem Mail-Server für Wiederholungen für einen von Kopf bis Fuß.

Verwendung der "." Format soll einen sofortigen harten Fehler verursachen. Veranlassen Sie den MTA, den Versand sofort zu stoppen. So liest sich zumindest das Intro zum RFC.


21
2017-08-13 21:29



Vielen Dank. Die aber BCP: 32 / RFC 2606 Abschnitt 2 liest "'.invalid" ist für den Einsatz bei der Online-Konstruktion von Domain-Namen gedacht, die sicher ungültig sind und die auf einen Blick offensichtlich sind, sind ungültig. " 2606 sagt nichts, um anzuzeigen, dass ".invalid" nur für lokale Tests gedacht ist. Es ist für jede Domäne, die, naja, ungültig sein muss - Alpha Whiskey
Ok, ich kann verstehen, warum etwas, das aussieht, als wäre es der Name eines Hosts, im Vergleich zu "." - Alpha Whiskey
@ AlphaWhiskey Es ist Menschen wer kann etwas "sehen" und Schlüsse ziehen. Computer benötigen explizite Anweisungen. - Michael Hampton♦
um fair zu sein, es ist nicht gerade schwer, Computern in diesem speziellen Fall explizite Anweisungen zu geben. - muhmuhten
@res Es ist noch einfacher nicht um Computern explizite Anweisungen zu geben. - musiKk


Die Frage als Ganzes berührt ein paar verschiedene Aspekte, die alle berücksichtigt werden müssen, um zu beantworten, warum RFC7505 etwas Nützliches hinzufügt.


Vor allem die Definition vor dem RFC 7505, wie die E-Mail-Zustellung erfolgen soll, bietet keine Möglichkeit, sauber anzugeben, dass für einen Namen mit Adressdatensätzen keine E-Mail-Zustellversuche unternommen werden sollten.

Von RFC7505 Abschnitt 1:

SMTP-Clients haben eine vorgeschriebene Reihenfolge zum Identifizieren eines Servers   Das akzeptiert E-Mails für eine Domain. Abschnitt 5 von [RFC5321] umfasst   das im Detail; Im Wesentlichen sucht der SMTP-Client zuerst einen DNS-MX   RR, und wenn das nicht gefunden wird, fällt es zurück, nach einem DNS A zu suchen   oder AAAA RR. Daher überlädt dies einen DNS-Eintrag (der ein a   verschiedene primäre Mission) mit einer E-Mail-Service-Semantik.

Wenn eine Domain keine MX-Datensätze enthält, versuchen Absender, Nachrichten zuzustellen   an die Hosts an den Adressen in den A- oder AAAA-Datensätzen der Domäne. Ob   Es gibt keine SMTP-Listener an den A / AAAA-Adressen, Nachrichtenübermittlung   wird wiederholt für eine lange Zeit, in der Regel eine Woche versucht,   bevor der sendende Mail Transfer Agent (MTA) aufgibt. Dieser Wille   bei fehlgeleiteter Mail und   verbraucht Ressourcen beim Absender.

Dieses Dokument definiert einen Null-MX, der die gesamte E-Mail-Zustellung verursacht   Versuche, eine Domäne sofort auszufallen, ohne Domänen zu benötigen   um SMTP-Listener zu erstellen, die dafür vorgesehen sind, Zustellversuche zu verhindern.


Dann gibt es die Frage, wie RFC7505 dies implementiert (IN MX 0 .).

Von RFC7505 Abschnitt 3:

  1. MX-Ressourcendatensätze, die Null MX angeben

    Um anzuzeigen, dass eine Domain keine E-Mails akzeptiert, macht sie Werbung für a   einzelne MX RR (siehe Abschnitt 3.3.9 in [RFC1035]) mit einem RDATA-Abschnitt   bestehend aus Präferenz Nummer 0 und einer Null-Länge-Label, in geschrieben   Master-Dateien als ".", als Exchange-Domain, um das dort zu bezeichnen   existiert kein Mail-Exchanger für eine Domain. Schon seit "." ist kein gültiger Host   Name, ein Null-MX-Eintrag kann nicht mit einem normalen MX-Eintrag verwechselt werden.    Die Verwendung von "." als Pseudo-Hostname, was bedeutet, dass kein Dienst verfügbar ist   basierend auf der SRV RR [RFC2782] wo es eine ähnliche Bedeutung hat.

    Eine Domain, die einen Null-MX bewirbt, MUSS KEINE anderen MX-Anzeigen anbieten   RR.

(Betonung hinzugefügt)

Wie hier angemerkt, basieren die Implementierungsdetails für das "null MX" auf einem bereits etablierten Muster aus dem SRV RR-Typ Es macht Sinn, dies als das zu imitieren SRV RR-Typ mehr oder weniger ist eine verallgemeinerte Version des MX RR-Typ

So wurde die Entscheidung im Wesentlichen bereits bei der Definition des. Getroffen SRV RR-Typ.


Also, warum nicht nutzen? .invalid?

Von RFC2606 section2:

".invalid" ist für den Online-Aufbau von Domains vorgesehen     Namen, die sicher ungültig sind und bei denen es offensichtlich ist     der Blick ist ungültig.

Wie hier zu sehen ist, ist diese reservierte TLD für den menschlichen Verzehr bestimmt. Es gibt keinen Präzedenzfall, um eine spezielle Handhabung in Software zu definieren.

Sicher hätte es auf eine andere Art und Weise umgesetzt werden können, aber sie entschieden sich für den minimalen Ansatz der Verwendung .Dies ist kein gültiger Hostname und stört daher nicht den normalen Gebrauch.


9
2017-08-13 22:33



Soweit ich das beurteilen kann, gibt es keinen technischen Grund . hätte nicht als MX-Eintrag verwendet werden können, wenn A- oder AAAA-Datensätze im Stammverzeichnis veröffentlicht wurden. Wenn ich tippe telnet . 25 Es sucht sicherlich nach A- und AAAA-Datensätzen an der Wurzel. - kasperd
@ Kasperd Während das DNS-Protokoll es sicher darstellen kann, glaube ich nicht, dass Adressdatensätze bei . oder (vor RFC7505) Angabe . als die EXCHANGE Wert für ein MX Aufzeichnung wäre tatsächlich gültig. (Es ist kein gültiger Hostname.) - Håkan Lindqvist
Gültig oder nicht - Ich kann mir leicht Implementierungen vorstellen, die, wenn sie mit einem MX-Eintrag konfrontiert werden, der auf eine Domain ohne A-Einträge verweist, die Lieferung noch Tage lang wiederholt, bevor sie aufgeben. - kasperd