A DMARC il rollback dovrebbe ripristinare la comunicazione prevista preservando le prove necessarie per spiegare cosa è successo. La modifica del record è solo una parte di quel lavoro. Il team deve anche sapere quale servizio legittimo ha fallito, quale policy il destinatario potrebbe aver visto e cosa giustificherà un altro tentativo.
Preparare il percorso di ripristino prima del cambiamento. Quando arriva un incidente, un valore precedente, un nome del proprietario e un percorso di approvazione testato sono più utili di una ricerca improvvisata tramite screenshot.
Registrare lo stato che potrebbe necessitare di ripristino
Salva il record completo impostato con l'esatto nome del proprietario DNS interessato, insieme al TTL, ai server autorevoli e all'ora di raccolta. Mantieni le policy applicabili del genitore e del sottodominio quando sono importanti per la scoperta. Un valore p copiato da solo può omettere indirizzi di reporting o allineamento impostazioni modificate contemporaneamente.
Mantieni la modifica approvata come differenza leggibile. Identificare lo scopo di ogni tag modificato e la persona autorizzata che può ripristinare la configurazione precedente. Revisione rilevamento delle policy dei sottodomini prima di presumere che la modifica di un record genitore cambi la valutazione di ogni bambino.
Archivia le prove dell'amministrazione DNS separatamente dagli esempi di messaggi sensibili. Entrambi necessitano di un accesso adeguato, ma non è necessario che una registrazione dell'incidente riproduca il contenuto riservato di un cliente.
Definire un fattore scatenante che distingua il fallimento dal sospetto
Scegliere criteri concreti di rollback per il cambiamento: ad esempio, un rifiuto verificato di un flusso legittimo critico attribuibile alla nuova policy e l’incapacità di riparare quel flusso entro la finestra di risposta concordata.
Solo un reclamo di supporto avvia un'indagine; non stabilisce che DMARC sia la causa. Cattura il testo SMTP completo restituito, il servizio e l'account, l'ora, il dominio del destinatario, il dominio Da visibile e i registri di invio disponibili. Per la posta consegnata, conservare un messaggio originale rappresentativo e i risultati dell'autenticazione del destinatario attendibile in RFC 8601 §7.1.
Anche un basso tasso di superamento complessivo necessita di contesto. Il traffico non autorizzato può fallire durante una distribuzione integra. Chiedersi quale percorso commerciale legittimo è interessato prima di indebolire la politica.
Separare la riparazione del mittente dal ripristino della policy
Se un'applicazione ha un'identità di firma errata, una correzione dell'applicazione supportata potrebbe rappresentare il ripristino appropriato. Se l'ampio cambiamento della politica sta causando un impatto consequenziale, ripristinare la politica approvata in precedenza mentre viene esaminata la richiesta.
Evita di cambiare SPF, DKIM, DMARC e la piattaforma di invio contemporaneamente, a meno che l'incidente non lo richieda e ogni modifica viene registrata. Diverse modifiche simultanee rendono più difficile attribuire miglioramenti o insuccessi.
Il ripristino della policy non ripara l'autenticazione sottostante o il difetto di allineamento. Mantieni aperto il difetto con un proprietario, prove e un requisito di ripetizione del test.
Provare un ripristino controllato
Questo esercizio fittizio illustra la tenuta dei registri, non un vero e proprio test di produzione:
- Orario: 10:00 UTC; Evento: la politica approvata cambia da nessuna a quarantena; Prove conservate: set di record vecchi e nuovi completi, TTL e approvazione
- Orario: 10:08 UTC; Evento: il flusso di lavoro della fattura riceve un rifiuto correlato alla politica; Prove conservate: risposta restituita, account di invio e identificatori del messaggio
- Orario: 10:13 UTC; Evento: il proprietario dell'incidente autorizza il ripristino pianificato; Prove conservate: decisione e ambito interessato
- Orario: 10:16 UTC; Evento: valore DMARC completo precedente ripristinato con lo stesso nome del proprietario; Prove conservate: risposta DNS autorevole e ricevuta di modifica
- Ora: 10:26 UTC; Evento: un nuovo tentativo di fattura controllata viene accettato presso un destinatario di prova; Prove conservate: nuovo risultato SMTP e prove di autenticazione ricevute
L'ultima riga mostra quel particolare tentativo attraverso quel percorso. Ciò non dimostra che ogni destinatario abbia scartato una risposta precedente memorizzata nella cache o che tutti i messaggi dei clienti siano stati recuperati.
Durante una prova, esercita il vero percorso di amministrazione e approvazione in un ambiente di test appropriato. Registra chi può apportare la modifica e cosa succede se quella persona o provider DNS non è disponibile.
È previsto che le visualizzazioni DNS e i periodi dei report si sovrappongano
Un risolutore può conservare una risposta DNS precedente; RFC 8767 §4 consente l'utilizzo di risposte obsolete qualificanti oltre la scadenza del TTL, pertanto il TTL non è una scadenza per la rimozione globale garantita. L'abbassamento di un TTL dopo che un risolutore ha memorizzato nella cache una risposta precedente e di lunga durata non riduce retroattivamente la durata rimanente della cache di quella risposta.
Dopo aver ripristinato il record, interroga i server autorevoli e le relative viste ricorsive, quindi testa nuovamente il percorso di posta interessato. Una nuova risposta autorevole dimostra i dati attuali della zona; non dimostra ciò che attualmente utilizza ogni ricevitore remoto.
Mantieni la segnalazione attiva ove opportuno. RFC 9990 §3.3 spiega che un cambiamento di politica all’interno di un periodo di riferimento può produrre un rapporto che combina le disposizioni previste da diverse versioni di politica. Alcune implementazioni potrebbero invece produrre più report. Annota la sequenza temporale dell'incidente anziché considerare un singolo campo della policy come prova che ogni messaggio nel periodo utilizzava quella versione esatta.
Ripristinare una configurazione completa e valida
Utilizzare il nome esatto del proprietario previsto e riconciliare il set di record esistente. Sotto RFC 9989 §4.10, non aggiungere una seconda policy DMARC accanto alla prima nel tentativo di sovrascriverla. Conservare le destinazioni di reporting approvate e qualsiasi autorizzazione di destinazione esterna necessaria in RFC 9990 §4 a meno che il ripristino non li modifichi esplicitamente.
Controllare l'intera politica risultante per eventuali modifiche involontarie. Un ripristino che modifica silenziosamente l'allineamento o l'ambito del sottodominio è una nuova decisione politica, non un semplice ripristino.
Utilizzo il flusso di lavoro della registrazione per la pubblicazione e la guida alla rendicontazione per interpretare le prove successive.
Chiudere il ripristino e la correzione separatamente
Il ripristino viene stabilito quando i flussi di lavoro interessati definiti soddisfano i test concordati e la configurazione viene verificata entro i limiti noti. La riparazione si chiude solo quando viene compresa la causa e il percorso di invio è stato corretto o la politica prevista è stata riconsiderata.
La modifica successiva dovrebbe includere le prove mancanti che hanno causato il fallimento del primo tentativo. Le linee guida sull'interoperabilità in RFC 9989 §7.4 significa anche che il rifiuto potrebbe essere inappropriato per un dominio generico dei dipendenti. Un cambiamento fallito può rivelare che la politica proposta stessa necessita di una decisione diversa.
Tenere insieme le prove originali, l'esito negativo, la decisione di ripristino e il nuovo test riuscito. Quella traccia rende più veloce la successiva approvazione perché spiega cosa è cambiato, cosa è recuperato e cosa resta irrisolto.
Mantieni specifica l'azione successiva
Nella sequenza temporale immaginaria, l'accettazione delle 10:26 è un'osservazione di recupero, non una prova che il difetto di autenticazione è stato riparato. Mantenere aperto l'elemento di riparazione del mittente e confrontare separatamente i risultati effettivi del nuovo metodo. La tempistica di 26 minuti non è una promessa di recupero o un intervallo di attesa raccomandato. Per questo articolo non si è verificato alcun ripristino DNS , autorizzazione o nuovo tentativo di messaggio.