Un editor DNS che riporta un limite di 255 caratteri non significa necessariamente tuo SPF la policy deve diventare più record. Il formato DNS TXT consente più stringhe di caratteri all'interno di un record di risorse. SPF tratta i loro contenuti come un valore continuo. La sfida operativa è preservare il testo previsto mantenendo gestibili la policy e le relative risposte DNS .
Separa tre diversi limiti
Innanzitutto, una singola stringa di caratteri TXT è limitata a 255 ottetti. Il contenuto SPF è ASCII, quindi i suoi caratteri ordinari occupano ciascuno un ottetto. Un singolo registrazione TXT può contenere più di una stringa di questo tipo. La sezione 3.3 RFC 7208 consente esplicitamente tale rappresentazione.
In secondo luogo, la risposta DNS ha una dimensione. Include nomi, metadati dei record e altri record TXT restituiti con il nome del proprietario, non solo testo SPF . La sezione 3.4 consiglia di mantenere le risposte DNS SPF sufficientemente piccole per la gestione UDP legacy da 512 ottetti. Si tratta di una raccomandazione di compatibilità, non di un massimo universale di 512 caratteri per SPF . Le moderne funzionalità di trasporto DNS non eliminano tutti i problemi di risoluzione, firewall o troncamento.
In terzo luogo, la valutazione SPF ha limiti di risorse. La suddivisione del testo in stringhe non riduce l'elaborazione di inclusione nidificata o il limite di dieci termini che causano la ricerca. Una politica breve può superare tale limite di valutazione; un elenco più lungo di indirizzi espliciti potrebbe non esserlo. Valuta la sintassi, il trasporto DNS e i costi di valutazione in modo indipendente.
Preservare gli spazi deliberatamente
SPF concatena le stringhe senza inserire spazi. In una rappresentazione di file di zona, "v=spf1 ip4:192.0.2.10 " "ip4:198.51.100.20 -all" produce la politica continua prevista perché la prima stringa termina con uno spazio. La rimozione di quello spazio unisce i due meccanismi adiacenti in testo non valido.
Gli indirizzi di sola documentazione riportati sopra sono illustrativi. Non sono valori autorizzati per il tuo dominio. Le virgolette rappresentano la sintassi di presentazione del file di zona; se li inserisci in un editor DNS ospitato dipende dall'interfaccia documentata di quel provider. Alcuni editor dividono automaticamente i valori lunghi, mentre altri espongono campi stringa separati. Verifica la risposta fornita invece di presumere che la visualizzazione dell'editor corrisponda al formato wire.
Non creare un secondo record di risorse TXT che inizia v=spf1 per trattenere il resto. Selezionati multipli Registri SPF produrre permerror. Al contrario, non eliminare i record di verifica TXT non correlati perché uno strumento diagnostico visualizza diverse risposte TXT .
Controllare il valore pubblicato
Cattura la risposta TXT autorevole e identifica quali stringhe appartengono a ciascun record di risorsa. Ricostruire il valore SPF concatenando solo le stringhe all'interno del suo unico record. Controlla gli spazi ad ogni confine diviso e assicurati che ci sia un indicatore di versione, meccanismi validi e la dichiarazione finale prevista.
Quindi testa le risposte DNS ricorsive dalle reti che contano. Se una risposta viene troncata o la risoluzione non riesce, esamina il trasporto DNS e la configurazione del provider anziché eliminare meccanismi arbitrari. DNSSEC e l'insieme di risposte più ampio può influenzare la dimensione della risposta; un semplice conteggio dei caratteri non è un test completo della dimensione del pacchetto.
Preferire la pulizia politica all’imballaggio intelligente
Una politica in crescita spesso segnala servizi accumulati. La revisione include meccanismi inutilmente ampi e autorizzazioni duplicate prima di aumentare la complessità. Conservare gli attuali meccanismi gestiti dal provider, quando appropriato, anziché copiare gli attuali indirizzi IP esclusivamente per abbreviare o rimodellare il record. Gli indirizzi appiattiti manualmente possono diventare obsoleti quando i provider cambiano l'infrastruttura.
Per una policy che necessita ancora di più stringhe, salva il testo non diviso desiderato insieme alla rappresentazione pubblicata. Ciò offre ai futuri amministratori un obiettivo di confronto stabile. Una riformattazione innocua dell'editor non deve essere confusa con un cambiamento della politica semantica.
Verificare il risultato rivolto al lettore
Dopo una modifica approvata, testare fonti rappresentative e una fonte senza eguali con un valutatore attento agli standard, quindi ispezionare i risultati effettivi dei ricevitori affidabili. Registrare il valore ricostruito, le osservazioni sulla risposta e i risultati della valutazione. Chiudi il problema quando sia la rappresentazione DNS che il comportamento di autorizzazione sono corretti, non semplicemente quando l'editor accetta il salvataggio.
Ricostruire una risposta alla domanda
Quello che segue è un esercizio diagnostico sintetico, non una query che abbiamo eseguito o un record pubblicare. Sostituisci il nome del proprietario effettivo SPF con un autorevole verificato server dei nomi prima di utilizzare questi comandi di sola lettura. Questi modelli utilizzano nomi di esempio riservati.
dig @ ns1.example.net example.com TXT +noall +risposta dig example.com TXT +noall +rispostaIl primo comando chiede al server autorevole specificato; il secondo utilizza il risolutore configurato su quella macchina. Una risposta da un risolutore ricorsivo non dimostra che ogni ricevitore vede gli stessi dati. Se necessario, interroga esplicitamente un altro risolutore noto con @indirizzo-server.
Risposta sintetica:
example.com . 300 IN TXT " v=spf1 ip4:192.0.2.10 " " ip4:198.51.100.20 -all "Valore ricostruito:
v=spf1 ip4:192.0.2.10 ip4:198.51.100.20 -allSenza lo spazio finale nella prima stringa, il limite diventa 192.0.2.10ip4: 198.51.100.20 . L'editor potrebbe accettare i dati TXT , ma ciò non rende valida la politica SPF . Al contrario, due record di risposta separati, ciascuno dei quali inizia con v=spf1 rappresentano un problema con policy multiple, non una soluzione di suddivisione delle stringhe.
Salva il server interrogato, il nome del proprietario, il timestamp e la risposta. Ricostruisci un record alla volta, confrontalo con la policy di non suddivisione prevista, quindi valuta separatamente l'autorizzazione del mittente. I comandi controllano la rappresentazione DNS ; non eseguono una valutazione SPF completa. Vedere RFC 7208 Sezione 3.3 per concatenazione e Sezione 4.6.4 per i limiti di valutazione.