Route 53 - Soll ich meine SPF-Einträge als TXT-Einträge duplizieren?

Amazon Route 53 unterstützt sowohl "SPF Records" als auch "TXT Records". Die meiste Dokumentation, die ich lese, fordert mich auf, meinen SPF-Datensatz als TXT-Datensatz aufzulisten. Ich verstehe, dass der SPF-Datensatz ein neuerer Standard ist. Ist es daher richtig, dass ich meine SPF-Einträge so dupliziere, dass sie als SPF-Einträge und TXT-Einträge aufgeführt sind, um die Abwärtskompatibilität zu gewährleisten und gleichzeitig dem neuen Standard zu folgen? Ich bin mit DNS nicht vertraut, bin mir also nicht sicher, ob dies Probleme verursachen würde oder ob ich mich überhaupt darum kümmern sollte, sie zu duplizieren?

Meine Aufzeichnungen lauten wie folgt:

"v=spf1 include:_spf.google.com include:amazonses.com -all"
"spf2.0/pra include:_spf.google.com include:amazonses.com -all"

Es ist nicht richtig, dass der SPFRR-Typ der neuere Standard ist (im Kontext des gewünschten SPF-Verhaltens). In der experimentellen Phase der SPF-Spezifikation wurde ein neuer Datensatztyp zugewiesen, der Migrationspfad war jedoch unklar und wurde seitdem aufgegeben.

In der aktuellen Version der SPF- Spezifikation heißt es speziell:

SPF - Einträge muss als DNS - TXT (Typ 16) Resource Record veröffentlicht (RR) [RFC1035] nur . Der Zeicheninhalt des Datensatzes wird als [US-ASCII] codiert. Die Verwendung alternativer DNS-RR-Typen wurde in der SPF-Versuchsphase unterstützt, jedoch eingestellt.

Im Jahr 2003, als SPF zum ersten Mal entwickelt wurde, waren die Anforderungen für die
Zuweisung eines neuen DNS-RR-Typs erheblich strenger als heute. Darüber hinaus war die Unterstützung für die einfache Bereitstellung neuer DNS-
RR-Typen auf DNS-Servern und Bereitstellungssystemen nicht weit verbreitet
. Entwickler von SPF fanden es daher einfacher und
praktischer, den TXT RR-Typ für SPF-Datensätze zu verwenden.

In ihrer Überprüfung von [RFC4408] kam die SPFbis-Arbeitsgruppe zu dem Schluss, dass das Übergangsmodell für den doppelten RR-Typ grundlegend fehlerhaft war, da es
keinen gemeinsamen RR-Typ enthielt, den die Implementierer bedienen
und überprüfen mussten. Viele Alternativen wurden in Betracht gezogen, um
dieses Problem zu lösen , aber letztendlich kam die Arbeitsgruppe zu dem Schluss, dass eine
signifikante Migration auf den SPF-RR-Typ in absehbarer Zukunft
sehr unwahrscheinlich ist und dass die beste Lösung für die Lösung dieses
Interoperabilitätsproblems darin besteht, die Unterstützung für den SPF-RR-Typ abzubrechen
SPF-Version 1. Weitere Informationen finden Sie in Anhang A von [RFC6686].

Die Umstände, unter denen SPF vor einem Jahrzehnt erstmals eingesetzt wurde, sind einzigartig. Wenn ein zukünftiges SPF-Update entwickelt wird, bei dem
vorhandene SPF-Datensätze nicht wiederverwendet werden, kann der SPF-RR-Typ verwendet werden. Die Verwendung
des TXT RR-Typs durch SPF für strukturierte Daten sollte in keiner Weise als
Präzedenzfall für zukünftige Protokolldesigner angesehen werden. Weitere Informationen zu
Entwurfsüberlegungen bei der Verwendung neuer DNS-RR-Typen finden Sie in
[RFC5507].

Als Nebenbemerkung gab es in Ihrem Beispiel auch einen Absender-ID-Datensatz (leider als "spf2.0" bezeichnet, obwohl es sich um eine andere Spezifikation handelt). Die Regeln für diesen Datensatztyp sind noch experimentell und stimmen mit der experimentellen Version des SPF überein Es wurden keine Updates veröffentlicht.

Ja, dupliziere sie; Ich weiß nicht ohne weiteres, welches Verhältnis von SPF-Prüfern tatsächlich den aktuellen Standard für den Datensatztyp unterstützt, aber wenn ich eine wilde Vermutung anstellen würde, würde ich wetten, dass wahrscheinlich 10% der Prüfer nicht nur einen SPFDatensatz betrachten TXT.