Un “no”. Registro DMARC trovato" è un punto di partenza per la diagnosi. Può riflettere una policy realmente mancante, una query per il nome sbagliato, una modifica in un account DNS inattivo, una risposta più vecchia memorizzata nella cache o un errore di risoluzione.
Prima di pubblicare un altro record, stabilisci cosa ha richiesto lo strumento e quali server autorevoli controllano quella risposta. Conserva il codice di risposta DNS e tutti i dati TXT restituiti. Questo separa un record assente da un record che esiste ma non può essere recuperato tramite un particolare percorso di ricerca.
Cattura l'esatta ricerca non riuscita
Registra lo strumento, il dominio richiesto, il timestamp, il risolutore e la risposta DNS completa, ove disponibile. Salvare il record della policy corrente e la configurazione DNS prima della modifica.
Questi comandi BIND dig illustrativi non vengono eseguiti qui. Sostituisci i nomi della documentazione con la destinazione approvata e il server delegato effettivo. IL Manuale di scavo BIND definisce il server, il nome, il tipo e le opzioni di query. La sezione dell'autorità aiuta a mantenere il contesto della risposta negativa; i commenti mantengono lo stato dell'intestazione e i flag. Una semplice query per il dominio Da visibile example.com inizia qui:
dig _dmarc.example.com . TXT +noall +risposta +autorità +commentiConserva lo stato della risposta e la sezione della risposta. Una visualizzazione solo breve può nascondere la distinzione tra un nome senza dati TXT rilevanti e un errore di risoluzione.
Identificare chi controlla la risposta DNS pubblica
Questo problema diventa spesso un problema di proprietà. Un'azienda potrebbe aver acquistato il dominio da un provider, spostato il proprio sito web altrove e delegato DNS a un terzo account. Un record aggiunto nel pannello sbagliato può sembrare completo senza avere alcun effetto sui controlli della posta elettronica pubblica.
Chiedi all'operatore di identificare l'attuale host DNS autorevole e di mostrare la sua risposta per il nome previsto. Evita di pagare per correzioni ripetute senza un percorso di pubblicazione dimostrato. Chiedi anche se l'avviso riguarda il tuo dominio principale, un sottodominio di invio o un'identità diversa utilizzata da un'applicazione.
Controlla il nome e l'account di pubblicazione
Controlla la delega autorevole per la zona, inclusa una zona secondaria delegata separatamente, se ne esiste una. Interroga direttamente un server autorevole pertinente, utilizzando il suo nome effettivo:
dig @ ns1.example.net _dmarc.example.com . TXT +norecurse +noall +risposta +autorità +commentiSe l'editor DNS aggiunge automaticamente la zona, inserendo _dmarc.example.com potrebbe pubblicare accidentalmente _dmarc.example.com.example.com. In un altro editor, solo inserendo _dmarc potrebbe essere sbagliato. Controlla il nome del proprietario finale pubblicato anziché prescrivere lo stesso formato di input per ogni fornitore.
Altri errori frequenti includono a registrazione TXT nella radice del dominio, una modifica a un account DNS inattivo, una modifica non salvata o una ricerca del dominio di invio errato.
Distinguere l'assenza dall'errore di ricerca
- Osservazione: NXDOMAIN ; Cosa indagare: il nome richiesto viene segnalato come inesistente
- Osservazione: NOERROR senza dati TXT rilevanti; Su cosa indagare: il nome richiesto non ha una risposta TXT applicabile in quella risposta
- Osservazione: SERVFAIL ; Cosa indagare: Risoluzione non riuscita; ispezionare l'autorità, la delega, la convalida e le dipendenze
- Osservazione: esiste una risposta autorevole ma la risposta ricorsiva differisce; Cosa indagare: stato della cache, vista del risolutore, percorso di delega e tempistica
- Osservazione: diversi record di politiche candidate; Cosa indagare: un problema relativo al set di record, non una semplice condizione di record mancante
Gli stati DNS e la distinzione tra risposte negative sono descritti in RFC 1035 §4.1.1, RFC 2308 §2.1 E RFC 2308 §2.2. Non considerare SERVFAIL come un'autorizzazione a pubblicare un altro record. Il record potrebbe esistere ma non essere disponibile tramite il percorso di risoluzione con errore. Allo stesso modo, un record mancante in corrispondenza del nome di un bambino non determina se un destinatario può scoprire una politica applicabile altrove ai sensi RFC 9989 §4.10.1.
Esempio realizzato: il record si trova in una zona inattiva
Consideriamo questa indagine illustrativa. Aggiunge un amministratore _dmarc al pannello DNS del registrar. La delega pubblica, tuttavia, punta a un host DNS separato utilizzato durante una precedente migrazione del sito Web.
Il pannello del registrar mostra il valore previsto. Una query diretta all'autorità attualmente delegata non lo restituisce. Un'attesa più lunga non può rendere autorevole una zona inattiva.
La correzione consiste nel pubblicare tramite l'autorità effettiva, con l'apposita approvazione. Successivamente, conserva la risposta autorevole e confronta l'osservazione ricorsiva. La modifica dei server dei nomi solo per rendere efficace il pannello precedente potrebbe interrompere record web e di posta non correlati, quindi si tratta di un cambiamento separato e molto più ampio.
Confronta le risposte autorevoli e quelle memorizzate nella cache
Sotto RFC 2308 §5, un risolutore può memorizzare nella cache una risposta negativa precedente. Un nuovo record autorevole può quindi coesistere temporaneamente con un'osservazione ricorsiva a risposta mancante. Lo svuotamento della cache di un laptop non cancella lo stato del risolutore di un ricevitore esterno.
Confrontare l'autorità e le osservazioni ricorsive rilevanti con i timestamp. Se i server autorevoli non sono d'accordo, indaga sul loro stato pubblicato. Se DNS interno e quello pubblico differiscono, stabilire quale visualizzazione utilizza il destinatario della posta esterno.
Evita di promettere che tutte le risposte convergeranno dopo un numero fisso di minuti. Diagnosticare il percorso effettivo e memorizzare nella cache le prove.
Correggere il processo di pubblicazione
Trattare il risultato come un problema di proprietà del controllo quando rivela responsabilità DNS poco chiare, account abbandonati o delega non gestita. Registra chi può apportare modifiche, quale zona è attiva e in che modo un secondo revisore verifica il risultato.
Un'osservazione di policy mancante è un risultato di configurazione. Non è stabilito che a phishing campagna ha avuto successo, che ogni sottodominio non ha una policy o che ogni messaggio ricevuto fallisce DMARC. Mantieni separate queste conclusioni e raccogli le prove richieste da ciascuna.
Verificare la politica e un messaggio reale
Dopo la correzione prevista, conferma la ricerca della politica applicabile e testa un messaggio legittimo reale tramite il servizio pertinente. Verificare il risultato dell'autenticazione attendibile e allineamento.
Utilizzo il flusso di lavoro di creazione del record quando una nuova politica è effettivamente necessaria. Se la policy è visibile ma la posta non funziona, spostati in diagnosi di allineamento. Se una vecchia guida e un nuovo ricevitore differiscono al momento della scoperta, includerli Preparazione DMARCbis nell'indagine.
Il pratico takeaway
Chiudi il risultato con il percorso di pubblicazione corretto e la risposta autorevole risultante. Quindi verificare la politica applicabile e un messaggio realmente legittimo. Ciò lascia una diagnosi riproducibile invece di un risultato del controllo inspiegabile.
Mantenere la decisione e le prove separate
Per l'apparecchio della zona inattiva, scegliere l'autorità attiva come obiettivo di pubblicazione proposto; non modificare la delega semplicemente per rendere rilevante un pannello obsoleto. Esamina il flag di risposta autorevole e il contesto completo della risposta, non solo il testo restituito. RFC 8767 §4 consente l'utilizzo di risposte obsolete qualificanti oltre la scadenza del TTL, quindi un TTL non è una scadenza di convergenza universale. Non è stata eseguita alcuna ricerca o modifica della configurazione.