Route 53 - Devo duplicare i miei record SPF come record TXT?

Amazon Route 53 supporta sia "Record SPF" che "Record TXT". La maggior parte della documentazione che ho letto mi dice di elencare il mio record SPF come record TXT. Comprendo che il record SPF è uno standard più recente. È quindi corretto duplicare i miei record SPF in modo che siano elencati come record SPF e record TXT per garantire la compatibilità con le versioni precedenti pur seguendo il nuovo standard? Non ho familiarità con il DNS, quindi non sono sicuro che ciò possa causare problemi o se dovrei preoccuparmi di duplicarli?

I miei record sono i seguenti:

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

In realtà non è corretto che il SPFtipo RR sia lo standard più recente (nel contesto del comportamento SPF desiderato). Alla fase sperimentale della specifica SPF è stato assegnato un nuovo tipo di record ma il percorso di migrazione non era chiaro e da allora è stato abbandonato.

La versione corrente delle specifiche SPF specifica specificamente:

Record SPF deve essere pubblicato come DNS TXT (tipo 16) Resource Record (RR) [RFC1035] solo . Il contenuto del carattere del record è codificato come [US-ASCII]. L'uso di tipi di DNS DNS alternativi è stato supportato nella fase sperimentale di SPF ma è stato sospeso.

Nel 2003, quando SPF fu sviluppato per la prima volta, i requisiti per l'
assegnazione di un nuovo tipo di RR DNS erano notevolmente più rigorosi di quanto non lo siano ora. Inoltre, il supporto per una facile implementazione di nuovi
tipi di RR DNS non è stato ampiamente distribuito nei server DNS e nei
sistemi di provisioning . Di conseguenza, gli sviluppatori di SPF hanno trovato più semplice e
pratico utilizzare il tipo TXT RR per i record SPF.

Nella sua revisione di [RFC4408], il gruppo di lavoro SPFbis ha concluso che il suo modello di transizione di tipo RR doppio era fondamentalmente imperfetto poiché non
conteneva alcun tipo RR comune che gli attuatori dovevano servire
e che dovevano controllare. Sono state prese in considerazione molte alternative per risolvere
questo problema, ma alla fine il gruppo di lavoro ha concluso che una
significativa migrazione al tipo di SPF RR nel prossimo futuro
era molto improbabile e che la migliore soluzione per risolvere questo
problema di interoperabilità era quella di eliminare il supporto per il tipo di SPF RR da
Versione SPF 1. Vedere l'Appendice A di [RFC6686] per ulteriori informazioni.

Le circostanze relative alla distribuzione iniziale di SPF dieci anni fa sono uniche. Se fosse sviluppato un futuro aggiornamento di SPF che non
riutilizzava i record SPF esistenti, potrebbe utilizzare il tipo di SPF RR. L'uso
di SPF del tipo TXT RR per i dati strutturati non dovrebbe in alcun modo essere considerato come un
precedente per i futuri progettisti di protocolli. Ulteriori discussioni sulle
considerazioni di progettazione quando si utilizzano nuovi tipi di RR DNS sono disponibili in
[RFC5507].

Come sidenote, c'era anche un record ID mittente (purtroppo indicato come "spf2.0" nonostante fosse una specifica diversa) nel tuo esempio, le regole per quel tipo di record sono ancora sperimentali e corrispondono alla versione sperimentale dell'SPF spec , nessun aggiornamento è stato pubblicato.

Sì, duplicali; Non so con certezza quale rapporto tra gli ispettori SPF effettivamente supporta l'attuale standard per il tipo di record, ma se dovessi fare un'ipotesi sfrenata scommetterei che probabilmente il 10% degli ispettori non guarderebbe SPFsolo un record TXT.