Sotto RFC 9989 §9.2, un temporaneo DMARC errore significa che la valutazione ha riscontrato un problema che potrebbe risolversi in un tentativo successivo. Ciò non significa che il dominio non abbia policy o che la posta legittima abbia definitivamente fallito l'autenticazione.
Trattare il risultato come l'inizio di un'indagine di risoluzione. Stabilire quale ricerca richiesta non è riuscita, se i dati esistono presso la sua autorità e cosa ha impedito al sistema ricevente di ottenere una risposta utilizzabile.
Cattura la valutazione fallita
Salva il risultato attendibile completo o la risposta SMTP restituita, l'ora, il dominio e il percorso di invio. Prendere nota del metodo di autenticazione a cui appartiene l'errore. Un temporaneo SPF O DKIM il problema non è automaticamente uguale a dmarc=temperror.
Conserva il nome esatto della ricerca e il tipo di record quando i log li espongono. Una query TXT di policy, una dipendenza SPF e a Selettore DKIM la ricerca può coinvolgere nomi e autorità diversi. Testare solo la radice del dominio può non rilevare la dipendenza non riuscita.
Conserva un piccolo pacchetto di prove prima di apportare modifiche. Le query ripetute potrebbero avere esito positivo dopo l'incidente, quindi una risposta corretta successiva non può sostituire il record di errore originale.
Seguire un percorso decisionale basato sulla risposta
Questa è una tabella decisionale diagnostica, non una mappatura universale dallo stato DNS a una disposizione email:
- Osservazione della query: risposta completa pertinente con NOERROR; Cosa stabilisce: quella query ha restituito dati utilizzabili in quel momento; Prossima indagine: confrontala con l'osservazione precedente del ricevente
- Osservazione della query: risposta completa senza dati; Cosa stabilisce: Il set di record richiesto non è stato trovato in quel contesto di risposta; Prossima indagine: controlla il nome esatto, l'autorità, gli alias e il rilevamento
- Osservazione della query: NXDOMAIN senza complicazioni alias; Cosa stabilisce: Il nome del proprietario interrogato non esiste; Prossima indagine: confermare l'ambito della query e il fallback applicabile
- Osservazione della query: SERVFAIL ; Cosa stabilisce: La risoluzione non è stata completata con successo; Prossima indagine: ispezionare i log di autorità, delega, convalida e risolutore
- Osservazione della domanda: RIFIUTATA; Cosa stabilisce: un server ha rifiutato la richiesta; Prossima indagine: verificare la policy di query e il ruolo previsto del server
- Osservazione della query: Timeout; Cosa stabilisce: Nessuna risposta utilizzabile è arrivata entro i limiti del tentativo; Prossima indagine: verifica raggiungibilità, trasporto, perdita e integrità del server
I codici di risposta DNS sono definiti da RFC 1035 §4.1.1; risposte negative di RFC 2308 §2.1 E RFC 2308 §2.2. Una query per _dmarc.example.com riguarda il nome del proprietario. La sua risposta negativa non dimostra di per sé che example.com non esiste. Seguire le catene di alias prima di attribuire un'assenza al nome originale richiesto.
Confrontare percorsi autorevoli e ricorsivi
Innanzitutto identificare i server autorevoli corretti, inclusi eventuali sottodomini delegati. Metti alla prova il nome pertinente presso ciascuna autorità e confronta le risposte. Se le autorità non sono d'accordo, indaga sullo stato di servizio della zona e sui recenti cambiamenti.
Quindi ispezionare il percorso ricorsivo utilizzato dal sistema ricevente interessato dove sono disponibili prove. Confronta il tempo della query, lo stato, la risposta e il TTL. Il risolutore locale di un operatore e un ricevitore remoto possono avere stati di memorizzazione nella cache o di convalida diversi.
La seguente trascrizione abbreviata fittizia illustra il confronto:
14:02 UTC | risolutore ricorsivo R | _dmarc.example.com TXT | SERVFAIL 14:04 UTC | server autorevole A | stesso nome/tipo | NOERROR, la policy ha restituito le 14:04 UTC | server autorevole B | stesso nome/tipo | NOERROR, la policy ha restituito le 14:09 UTC | risolutore R dopo la riparazione esaminata | stesso nome/tipo | NOERRORETali osservazioni restringono l’indagine verso il percorso ricorsivo o intermedio. Non dimostrano la causa senza registri e non stabiliscono ciò che ha vissuto ogni destinatario.
Includere la convalida DNSSEC nell'indagine
Sotto RFC 4035 §5.5, un risolutore di convalida può rifiutare i dati che falliscono DNSSEC convalida anche quando una query diretta a un server autorevole restituisce testo. Controlla le prove di delega e convalida, comprese le modifiche alla chiave o alla firma, utilizzando gli strumenti e i log supportati dal team DNS responsabile.
Una risposta diretta da parte di un'autorità non riproduce di per sé la decisione di convalida del ricevente. Allo stesso modo, un SERVFAIL non dimostra un problema DNSSEC ; può avere diverse cause.
Riparare il difetto di convalida accertato, se presente. La disabilitazione della convalida per nascondere il sintomo non costituisce una prova del ripristino del percorso di risoluzione sicura previsto.
Testare sia UDP che TCP, ove pertinente
Il trasporto DNS può essere parte del fallimento. Una piccola query UDP riuscita non stabilisce che una risposta più ampia, un tentativo di risposta troncata o TCP funzioni lungo lo stesso percorso.
RFC 7766 RFC 7766 §5 richiede implementazioni DNS generiche per supportare sia UDP che TCP. Confronta il nome e il tipo rilevanti su ciascun trasporto durante la diagnosi di guasti legati alla raggiungibilità o alle dimensioni. Esaminare il flag di troncamento e le prove di rete anziché presumere che ogni timeout abbia la stessa causa.
Un test di trasporto è un'osservazione diagnostica. Non dovrebbe essere trasformato in una soluzione alternativa di produzione che ignori il risolutore previsto o il percorso di convalida senza una progettazione rivista.
Mantenere separate l'assenza e la risoluzione fallita
Sotto RFC 2308 §5, le risposte negative possono essere memorizzate nella cache, così come i dati positivi. Un record appena aggiunto può rimanere assente in una vista ricorsiva fino alla scadenza del precedente stato negativo della cache. Ciò è diverso dal fatto che un server autorevole sia irraggiungibile.
Un difetto di configurazione può persistere anche mentre l'errore osservato rimane classificato come temporaneo. “Temporaneo” descrive la categoria di valutazione, non una promessa che l’attesa riparerà una delega o una firma infranta.
Utilizzo la guida ai record mancanti per assenza confermata e il flusso di lavoro della pubblicazione per verificare il nome e l'autorità effettivi.
Verificare il ripristino prima di riconsiderare la policy
Attuale RFC 9989 §4.10.1 lascia la gestione degli errori DNS di ricerca delle policy al destinatario. La guida alla valutazione in RFC 9989 §5.3.6 afferma che le query DNS richieste non completate a causa di errori DNS non stabiliscono un superamento o un fallimento DMARC e la politica di valutazione del proprietario del dominio non può essere applicata a quel risultato incompleto. La gestione del ricevitore può comunque differire.
La modifica di p non ripara una ricerca richiesta irraggiungibile. Ripristinare innanzitutto la risoluzione utilizzabile, quindi ripetere il test dello stesso percorso e ispezionare i nuovi risultati specifici del metodo. Conserva qualsiasi decisione di ripristino aziendale come modifica con ambito separato.
La registrazione finale dovrebbe identificare la dipendenza fallita, la causa accertata, la riparazione e le prove del destinatario dopo il ripristino. Ciò rende più facile diagnosticare il prossimo fallimento intermittente senza indebolire di riflesso una politica funzionante.
Mantenere la decisione e le prove separate
Per la trascrizione fittizia 14:02–14:09, il successo dell'autorità si restringe ma non identifica la componente fallita. Richiedere il risolutore effettivo o la ricerca della rete prima di nominare DNSSEC , il trasporto o un server particolare come causa. RFC 8767 §4 consente l'uso qualificante di risposte obsolete; la sola freschezza non è un orologio di interruzione o ripristino universale. Queste osservazioni sono strumenti didattici inventati, non test eseguiti.