3. SPF Records (Record SPF)

Un record SPF è un record DNS che dichiara quali host sono autorizzati (e quali non lo sono) a utilizzare il nome di dominio nelle identità "HELO" e "MAIL FROM". In linea generale, il record divide gli host in insiemi autorizzati e non autorizzati (sebbene alcuni host possano non appartenere a nessuna delle due categorie).

I record SPF sono rappresentati come una singola stringa di testo trovata nell'RDATA di un singolo record di risorsa DNS TXT; non sono consentiti record SPF multipli con lo stesso nome proprietario. Il formato del record e il processo di selezione dei record sono descritti di seguito nella sezione 4. Un record di esempio è il seguente:

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

Questo record ha versione "spf1" e contiene tre direttive: "+mx", "a:colo.example.com/28" (implicito "+"), e "-all".

Ogni record SPF è posizionato nell'albero DNS al nome proprietario a cui appartiene, non in un sottodominio sotto il nome proprietario. Questo è simile ai record SRV [RFC2782].

L'esempio in questa sezione potrebbe essere pubblicato dalla seguente riga in un file di zona del dominio:

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

Poiché i record TXT hanno usi multipli, notare gli altri record TXT pubblicati lì per altri scopi. Possono causare problemi di limiti di dimensione (vedere sezione 3.4), e si deve prestare attenzione ad assicurarsi che solo i record SPF siano utilizzati per l'elaborazione SPF.

Gli ADMD che pubblicano record SPF dovrebbero mantenere al minimo la quantità di informazioni DNS necessarie per valutare il record. Le sezioni 4.6.4 e 10.1.1 forniscono alcuni consigli sul meccanismo "include" e sui modificatori "redirect" concatenati.

3.1 DNS Resource Records (Record di risorse DNS)

I record SPF devono essere pubblicati esclusivamente come record di risorse (RR) DNS TXT (tipo 16) [RFC1035]. Il contenuto in caratteri del record è codificato come [US-ASCII]. La fase di sperimentazione SPF supportava l'uso di un tipo di RR DNS alternativo, ma questo è stato ora abbandonato.

Nel 2003, quando SPF fu sviluppato per la prima volta, i requisiti per l'assegnazione di un nuovo tipo di RR DNS erano più severi di oggi. Inoltre, il supporto per il facile dispiegamento di nuovi tipi di RR DNS nei server DNS e nei sistemi di configurazione non era ampiamente distribuito. Pertanto, gli sviluppatori di SPF trovarono più facile e pratico utilizzare il tipo di RR TXT per memorizzare i record SPF.

Durante la revisione di [RFC4408], il gruppo di lavoro SPFbis concluse che il suo modello di transizione a doppio tipo di RR era fondamentalmente difettoso perché non conteneva un tipo di RR universale che gli implementatori dovevano fornire e verificare. Furono considerate molte alternative per risolvere questo problema, ma alla fine il gruppo di lavoro concluse che la probabilità di una migrazione al tipo di RR SPF in un futuro prevedibile era molto bassa e che la migliore soluzione a questo problema di interoperabilità era rimuovere il supporto per il tipo di RR SPF da SPF versione 1. Per ulteriori informazioni, vedere l'appendice A di [RFC6686].

Le circostanze attorno al dispiegamento iniziale di SPF un decennio fa erano uniche. Se in futuro viene sviluppato un aggiornamento di SPF che non riutilizza i record SPF esistenti, potrebbe utilizzare il tipo di RR SPF. L'uso da parte di SPF del tipo di RR TXT per memorizzare dati strutturati non deve in alcun modo essere considerato un precedente per i futuri progettisti di protocolli. Un'ulteriore discussione delle considerazioni di progettazione quando si utilizzano nuovi tipi di RR DNS può essere trovata in [RFC5507].

3.2 Multiple DNS Records (Record DNS multipli)

Un nome di dominio non deve mai avere record multipli che porterebbero una verifica di autorizzazione a selezionare record multipli. Vedere la sezione 4.5 per le regole di selezione.

3.3 Multiple Strings in a Single DNS Record (Stringhe multiple in un singolo record DNS)

Come definito in [RFC1035] sezioni 3.3 e 3.3.14, un singolo record DNS di testo può essere composto da stringhe multiple. Se un record pubblicato contiene stringhe di caratteri multiple, il record deve essere trattato come queste stringhe concatenate senza aggiunta di spazi. Ad esempio:

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

è equivalente a:

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

I record TXT contenenti stringhe multiple sono utili per costruire record che superano la lunghezza massima di 255 ottetti per una stringa di caratteri in un singolo record TXT.

3.4 Record Size (Dimensione del record)

I record SPF pubblicati per un dato nome di dominio dovrebbero essere mantenuti sufficientemente piccoli affinché il risultato della query per esso si adatti in 512 ottetti. Altrimenti, è possibile superare i limiti del protocollo DNS. Questo limite UDP è definito in [RFC1035] sezione 2.3.4, sebbene sia stato aumentato da [RFC2671]. Rimanere sotto i 512 ottetti dovrebbe impedire alle implementazioni DNS più vecchie di passare a TCP e consentire l'uso di UDP senza supporto EDNS0 [RFC6891]. Poiché la dimensione della risposta dipende da molte cose al di fuori dello scopo di questo documento, può essere data solo la seguente guida: se la dimensione del messaggio DNS, la lunghezza combinata dei nomi DNS e del testo di tutti i record di un dato tipo è inferiore a 450 ottetti, allora la risposta DNS dovrebbe adattarsi in un pacchetto UDP. A causa di firewall e altri problemi che interferiscono con il funzionamento DNS su TCP o l'uso di EDNS0, i record troppo lunghi per adattarsi in un singolo pacchetto UDP possono essere silenziosamente ignorati dai validatori SPF.

Si noti che nel calcolare la dimensione della risposta per una query in formato TXT, tutti gli altri record TXT pubblicati al nome di dominio devono essere considerati. Allo stesso modo, le dimensioni delle risposte di tutte le query relative a SPF devono essere valutate per adattarsi in un singolo pacchetto UDP di 512 ottetti (cioè, dimensione del messaggio DNS limitata a 450 ottetti).

3.5 Wildcard Records (Record wildcard)

L'uso di record wildcard per la pubblicazione è scoraggiato, e se vengono utilizzati, si deve usare cautela. Se una zona contiene record MX wildcard, potrebbe voler pubblicare una dichiarazione wildcard, ma deve essere soggetta agli stessi requisiti e problemi. In particolare, la dichiarazione deve essere ripetuta per qualsiasi host con record RR qualsiasi e i loro sottodomini. Consideriamo l'esempio da [RFC1034] sezione 4.3.3. Su questa base, possiamo fare quanto segue:

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"

Per ogni nome all'interno della zona, il record SPF deve essere elencato due volte: una volta per quel nome e una volta con un wildcard per coprire l'albero sotto quel nome, per coprire tutti i domini utilizzati nella posta in uscita.