Definire il problema prima di cambiare DNS
A ricerca nulla la diagnosi significa più di " DNS non ha fornito l'indirizzo previsto". RFC 7208 descrive le query pertinenti che restituiscono una risposta positiva con zero risposte o una risposta di errore del nome. Queste sono comunemente chiamate ricerche void. Un timeout o un errore del server non rientrano nella stessa categoria di risposta. Trattare tutte le ricerche non riuscite come nulle può trasformare un incidente del risolutore temporaneo in una raccomandazione errata per riscrivere una policy del mittente valida.
Lo standard afferma che le implementazioni DOVREBBERO limitare le ricerche void a due. Consente un limite configurabile e in questo caso ne consiglia due come predefiniti. Il superamento del limite applicabile produce permerror. Preservare queste distinzioni normative: due non è un MUST universale incondizionato in ogni implementazione, ma un revisore non dovrebbe nemmeno presumere che un ricevitore sconosciuto abbia aumentato il suo limite. RFC 7208 , sezione 4.6.4
Mantieni due contatori separati
Il generale SPF i limiti di budget hanno valutato i termini che causano DNS, tra cui include, a, mx, ptr, esiste e reindirizza. Il vincolo di nullità riguarda la qualificazione delle risposte vuote o inesistenti riscontrate in sede di valutazione. Si sovrappongono nelle conseguenze operative ma misurano cose diverse. Una politica può incontrare risposte vuote problematiche prima di esaurire il suo budget complessivo. Un lungo percorso di dipendenza di successo può esaurire il termine budget senza produrre risposte vuote.
Il conteggio delle acquisizioni dei pacchetti, il conteggio degli accessi alla cache del risolutore e il conteggio dei termini SPF non sono intercambiabili. La memorizzazione nella cache può modificare l'attività di rete senza che la politica logica sia libera di valutare. Allo stesso modo, un termine sintattico può richiedere ulteriore lavoro di risoluzione o avere i propri vincoli supplementari. Mantieni il termine valutato, il nome della query estesa, il tipo di record, la classificazione della risposta e i totali parziali in campi distinti. RFC 7208 , sezione 4.6.4
Raccogliere dettagli di risposta sufficienti per classificare l'evento
Per un'indagine autorizzata proposta, conservare il nome e il tipo di query, il codice di risposta DNS , il conteggio delle risposte, i record restituiti pertinenti, il contesto del risolutore e il timestamp. Conserva la risposta grezza o una trascrizione strutturata fedele, non solo un'etichetta verde o rossa sulla dashboard. Una risposta positiva senza risposte non dovrebbe essere riformulata silenziosamente come NXDOMAIN . Entrambi possono essere importanti per annullare la contabilità, ma il loro significato DNS e i percorsi di risoluzione possono differire.
Registra se la ricerca è stata effettivamente raggiunta dal valutatore SPF . Uno strumento di rilevamento statico può esplorare le dipendenze che il messaggio specifico non valuta mai. Tale esplorazione può rivelare rischi, ma non è una prova che il messaggio abbia consumato quelle ricerche. Identificare l'indirizzo di connessione, l'input del mittente e il ramo della politica in modo che un altro revisore possa capire perché un meccanismo è stato valutato o ignorato.
Conserva gli errori separatamente. Un timeout, un registro di raccolta troncato o un risolutore inaccessibile rappresentano un'incertezza che necessita di una propria classificazione. Non sostituire le osservazioni mancanti con una risposta presunta vuota. L'indagine dovrebbe essere riproducibile senza richiedere al revisore di dedurre i tipi di risposta dalla prosa.
Interpretare i meccanismi prima di proporre una riparazione
Esiste un meccanismo che verifica se il dominio espanso dispone di dati di indirizzo nel modo definito dallo standard. Un meccanismo confronta gli indirizzi rilevanti con il client che si connette. I loro risultati non corrispondenti non dimostrano, di per sé, che l’editore abbia commesso un errore. Alcune politiche utilizzano intenzionalmente controlli di esistenza. La domanda diagnostica è se il percorso effettivo rimane entro i limiti applicabili e se la dipendenza serve ancora allo scopo di autorizzazione previsto.
Un target di inclusione inesistente merita una spiegazione diversa. Include valuta ricorsivamente una policy; un risultato none figlio viene mappato su permerror , anziché essere trattato come un normale nonmatch che fallisce in modo sicuro. Pertanto un report può riscontrare dati DNS mancanti e presentare un errore di inclusione più immediato rispetto a una spiegazione del limite di void cumulativo. Spiega il primo errore supportato, non tutte le conseguenze immaginabili dello stesso nome mancante. RFC 7208 , sezione 5.2, 5.3 e 5.7
Scheda operativa e criteri di accettazione
Preparare un foglio di lavoro con colonne per passaggio, politica di inclusione, meccanismo, destinazione estesa, tipo di query, codice di risposta, conteggio di risposte, totale di termini logici, totale di annullamento e decisione di continuazione. Includere la configurazione documentata del limite di vuoto del valutatore, se disponibile. Se tale configurazione è sconosciuta, enunciare l'ipotesi ed evitare di attribuirla a un servizio ricevente reale senza prove.
Per ogni sospetta risposta vuota, assegnare un proprietario che possa confermare se l'obiettivo è attuale. Un errore tipografico, la dipendenza da un fornitore in pensione, un test di esistenza intenzionale e prove temporaneamente non disponibili richiedono risposte diverse. Documentare la correzione proposta e i percorsi del mittente che potrebbe influenzare. Non sostituire mai un fornitore indovinato semplicemente perché il suo nome sembra familiare.
L'accettazione richiede un percorso coerente e un preciso ramo fallimentare, non semplicemente un minor numero di termini in una bozza di record. Il revisore dovrebbe essere in grado di identificare quale risposta è stata classificata come nulla, quando è stata superata la soglia configurata e perché quell'evento ha determinato il risultato. Dopo qualsiasi modifica approvata separatamente, sarebbero nuovamente necessarie prove attuali poiché le dipendenze e le cache del fornitore potrebbero differire dall'istantanea della pianificazione.
Diagnosi fittizia: risposte vuote contro un risolutore non disponibile
Immaginate una politica del tutto fittizia che raggiunga tre controlli di esistenza in ordine, ciascuno dei quali restituisca una risposta positiva con zero risposte. Supponiamo che un valutatore immaginario sia configurato con un limite di nullità pari a due e senza corrispondenze o errori precedenti. Alla terza risposta qualificante, la traccia proposta identifica il limite superato e permerror . Questo è uno scenario esplicativo, non un evento eseguito o un reclamo nei confronti di qualsiasi fornitore.
Cambia la terza osservazione in un timeout. La diagnosi non può più dire che questa risposta fosse la terza risposta nulla. L'investigatore deve preservare l'errore DNS temporaneo e la gestione da parte del valutatore, piuttosto che forzare l'evento nella spiegazione precedente. Cambia la seconda osservazione in una risposta di indirizzo positiva che corrisponda al meccanismo di esistenza e il ramo successivo potrebbe non essere mai raggiunto.
Queste variazioni mostrano perché un elenco semplice di nomi host non risolti non è sufficiente. I fatti rilevanti sono la semantica della risposta, l'ordine e il punto terminale. Mostrano anche perché lo stesso testo politico può produrre percorsi diversi per input o stati DNS diversi senza implicare che un osservatore abbia fabbricato il suo risultato.
Mantenere le prove originali e i cancelli di rilascio aperti
Per questo manoscritto non è stato richiesto alcun dominio pubblico o privato. Il foglio di lavoro è un metodo proposto e la diagnosi elaborata è fittizia. Il catalogo richiede un percorso annotato che mostri ogni termine conteggiato e l'esatto ramo fallito; tale requisito rimane aperto fino a quando non esistono prove effettivamente autorizzate e vengono riviste.
Una pubblicazione dovrebbe etichettare il contesto del risolutore, il tempo di raccolta e le ipotesi del valutatore. Non dovrebbe rivendicare un comportamento del ricevitore universale dalla soglia configurabile di un'implementazione. L'applicabilità della fonte, la revisione umana, le prove originali, i percorsi di produzione, l'accessibilità visiva e il rilascio del proprietario rimangono aperti. Qualsiasi riparazione DNS effettiva appartiene a un processo di modifica autorizzato separatamente con un inventario corrente del mittente e un piano di ripristino.