3. SPF Records (SPF-Einträge)

Ein SPF-Eintrag ist ein DNS-Eintrag, der erklärt, welche Hosts autorisiert sind (und welche nicht), den Domainnamen in den Identitäten "HELO" und "MAIL FROM" zu verwenden. Grob gesagt teilt der Eintrag Hosts in erlaubte und nicht erlaubte Mengen ein (obwohl einige Hosts möglicherweise zu keiner der beiden Kategorien gehören).

SPF-Einträge werden als eine einzelne Textzeichenfolge dargestellt, die im RDATA eines einzelnen DNS TXT-Ressourceneintrags gefunden wird; mehrere SPF-Einträge mit demselben Eigentümernamen sind nicht erlaubt. Das Eintragsformat und der Prozess zur Auswahl von Einträgen werden im Folgenden in Abschnitt 4 beschrieben. Ein Beispiel-Eintrag ist wie folgt:

v=spf1 +mx a:colo.example.com/28 -all

Dieser Eintrag hat die Version "spf1" und enthält drei Direktiven: "+mx", "a:colo.example.com/28" (implizites "+") und "-all".

Jeder SPF-Eintrag wird im DNS-Baum am Eigentümernamen platziert, zu dem er gehört, nicht in einer Subdomain unter dem Eigentümernamen. Dies ist ähnlich wie bei SRV-Einträgen [RFC2782].

Das Beispiel in diesem Abschnitt könnte durch die folgende Zeile in einer Domain-Zonendatei veröffentlicht werden:

example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all"

Da TXT-Einträge mehrere Zwecke haben, beachten Sie andere TXT-Einträge, die dort für andere Zwecke veröffentlicht wurden. Sie können Größenbeschränkungsprobleme verursachen (siehe Abschnitt 3.4), und es muss darauf geachtet werden, sicherzustellen, dass nur SPF-Einträge für die SPF-Verarbeitung verwendet werden.

ADMDs, die SPF-Einträge veröffentlichen, sollten die Menge an DNS-Informationen, die zur Bewertung des Eintrags erforderlich ist, auf ein Minimum beschränken. Abschnitt 4.6.4 und Abschnitt 10.1.1 geben einige Hinweise zum "include"-Mechanismus und verketteten "redirect"-Modifikatoren.

3.1 DNS Resource Records (DNS-Ressourceneinträge)

SPF-Einträge müssen ausschließlich als DNS TXT (Typ 16) Ressourceneinträge (RR) [RFC1035] veröffentlicht werden. Der Zeicheninhalt des Eintrags ist als [US-ASCII] kodiert. Die SPF-Experimentierungsphase unterstützte die Verwendung eines alternativen DNS RR-Typs, aber dies wurde nun eingestellt.

Im Jahr 2003, als SPF erstmals entwickelt wurde, waren die Anforderungen für die Zuweisung eines neuen DNS RR-Typs strenger als heute. Darüber hinaus war die Unterstützung für die einfache Bereitstellung neuer DNS RR-Typen in DNS-Servern und Konfigurationssystemen nicht weit verbreitet. Daher fanden die SPF-Entwickler es einfacher und praktischer, den TXT RR-Typ zur Speicherung von SPF-Einträgen zu verwenden.

Bei der Überprüfung von [RFC4408] kam die SPFbis-Arbeitsgruppe zu dem Schluss, dass ihr Dual-RR-Typ-Übergangsmodell grundlegend fehlerhaft war, da es keinen universellen RR-Typ enthielt, den Implementierer bereitstellen und überprüfen mussten. Viele Alternativen wurden zur Lösung dieses Problems in Betracht gezogen, aber letztendlich kam die Arbeitsgruppe zu dem Schluss, dass die Wahrscheinlichkeit einer Migration zum SPF RR-Typ in absehbarer Zukunft sehr gering war und die beste Lösung für dieses Interoperabilitätsproblem darin bestand, die Unterstützung für den SPF RR-Typ aus SPF Version 1 zu entfernen. Weitere Informationen finden Sie in Anhang A von [RFC6686].

Die Umstände rund um die anfängliche Bereitstellung von SPF vor einem Jahrzehnt waren einzigartig. Wenn in Zukunft ein SPF-Update entwickelt wird, das bestehende SPF-Einträge nicht wiederverwendet, könnte es den SPF RR-Typ verwenden. Die Verwendung des TXT RR-Typs durch SPF zur Speicherung strukturierter Daten sollte keinesfalls als Präzedenzfall für zukünftige Protokolldesigner angesehen werden. Eine weitere Diskussion über Designüberlegungen bei der Verwendung neuer DNS RR-Typen finden Sie in [RFC5507].

3.2 Multiple DNS Records (Mehrere DNS-Einträge)

Ein Domainname darf niemals mehrere Einträge haben, die dazu führen würden, dass eine Autorisierungsprüfung mehrere Einträge auswählt. Siehe Abschnitt 4.5 für die Auswahlregeln.

3.3 Multiple Strings in a Single DNS Record (Mehrere Strings in einem einzelnen DNS-Eintrag)

Wie in [RFC1035] Abschnitt 3.3 und Abschnitt 3.3.14 definiert, kann ein einzelner Text-DNS-Eintrag aus mehreren Strings bestehen. Wenn ein veröffentlichter Eintrag mehrere Zeichenstrings enthält, muss der Eintrag als diese Strings behandelt werden, die ohne Hinzufügen von Leerzeichen aneinandergehängt sind. Zum Beispiel:

IN TXT "v=spf1 .... first" "second string..."

ist äquivalent zu:

IN TXT "v=spf1 .... firstsecond string..."

TXT-Einträge, die mehrere Strings enthalten, sind nützlich für den Aufbau von Einträgen, die die maximale Länge von 255 Oktetten für eine Zeichenfolge in einem einzelnen TXT-Eintrag überschreiten.

3.4 Record Size (Eintragsgröße)

SPF-Einträge, die für einen bestimmten Domainnamen veröffentlicht werden, sollten klein genug gehalten werden, damit das Abfrageergebnis in 512 Oktette passt. Andernfalls besteht die Möglichkeit, DNS-Protokollgrenzen zu überschreiten. Dieses UDP-Limit ist in [RFC1035] Abschnitt 2.3.4 definiert, obwohl es durch [RFC2671] erhöht wurde. Unter 512 Oktetten zu bleiben sollte verhindern, dass ältere DNS-Implementierungen auf TCP zurückgreifen, und ermöglicht die Verwendung von UDP ohne EDNS0 [RFC6891]-Unterstützung. Da die Antwortgröße von vielen Dingen abhängt, die außerhalb des Umfangs dieses Dokuments liegen, kann nur die folgende Anleitung gegeben werden: Wenn die Größe der DNS-Nachricht, die kombinierte Länge der DNS-Namen und des Textes aller Einträge eines bestimmten Typs weniger als 450 Oktette beträgt, sollte die DNS-Antwort in ein UDP-Paket passen. Aufgrund von Firewalls und anderen Problemen, die den DNS-Betrieb über TCP oder die Verwendung von EDNS0 stören, können Einträge, die zu lang sind, um in ein einzelnes UDP-Paket zu passen, von SPF-Validatoren stillschweigend ignoriert werden.

Beachten Sie, dass bei der Berechnung der Antwortgröße für eine TXT-Format-Abfrage alle anderen TXT-Einträge, die am Domainnamen veröffentlicht wurden, berücksichtigt werden müssen. Ebenso müssen die Antwortgrößen aller SPF-bezogenen Abfragen bewertet werden, um in ein einzelnes 512-Oktett-UDP-Paket zu passen (d.h. DNS-Nachrichtengröße begrenzt auf 450 Oktette).

3.5 Wildcard Records (Wildcard-Einträge)

Die Verwendung von Wildcard-Einträgen für die Veröffentlichung wird entmutigt, und wenn sie verwendet werden, muss Vorsicht walten. Wenn eine Zone Wildcard-MX-Einträge enthält, möchte sie möglicherweise eine Wildcard-Deklaration veröffentlichen, muss jedoch denselben Anforderungen und Problemen unterliegen. Insbesondere muss die Deklaration für jeden Host mit beliebigen RR-Einträgen und deren Subdomains wiederholt werden. Betrachten Sie das Beispiel aus [RFC1034] Abschnitt 4.3.3. Basierend darauf können wir Folgendes tun:

EXAMPLE.COM. MX 10 A.EXAMPLE.COM
EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"

*.EXAMPLE.COM. MX 10 A.EXAMPLE.COM
*.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"

A.EXAMPLE.COM. A 203.0.113.1
A.EXAMPLE.COM. MX 10 A.EXAMPLE.COM
A.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"

*.A.EXAMPLE.COM. MX 10 A.EXAMPLE.COM
*.A.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"

Für jeden Namen innerhalb der Zone muss der SPF-Eintrag zweimal aufgelistet werden: einmal für diesen Namen und einmal mit einem Wildcard, um den Baum unter diesem Namen abzudecken, um alle in ausgehenden E-Mails verwendeten Domains abzudecken.