La VPN ha risolto il DNS o ha solo riutilizzato una risposta in cache?

Aprire una pagina pochi secondi dopo l’attivazione del tunnel non dimostra che il DNS ora funzioni, anche se il ticket di solito lo afferma. Nulla in quell’osservazione richiedeva una query: il nome potrebbe essere stato risolto prima del cambio e riutilizzato da una cache che il tunnel non ha mai toccato. Due test diversi producono la stessa schermata.

Confrontate ciò che ogni test ha realmente esercitato prima di attribuire il merito al cambio.

Caricare una pagina non è una query

Ogni livello tra l’applicazione e il resolver può ricordare una risposta per tutta la sua durata. Il sistema operativo ne conserva una, il browser conserva la sua, e un’applicazione con una connessione di lunga durata potrebbe non risolvere più nulla durante la sessione. Un caricamento che riesce dopo un cambio di tunnel può quindi essere una dimostrazione di memoria anziché di instradamento. L’assenza di un errore non è la presenza di una query.

Questa distinzione cambia ciò che dovreste testare dopo. Se l’obiettivo è mostrare che il nuovo resolver risponde, serve una query che non possa essere servita da una cache che non avete svuotato.

Leggere un successo in cache come prova che un server prima irraggiungibile si è ripreso è la versione più costosa di questo errore, perché chiude l’incidente su una premessa falsa.

Contate le cache prima di concludere

Quattro meritano un nome: la risoluzione propria dell’applicazione, la cache client del sistema operativo, lo stato interno del browser e qualsiasi resolver ricorsivo che la query finisca per raggiungere. Ciascuna ha una durata separata e un modo separato di essere svuotata. Svuotarne una e testarne un’altra è il modo in cui le persone concludono che lo svuotamento non ha fatto nulla. Un comando di svuotamento non risolve mai la questione.

Anche le risposte negative vengono messe in cache. Un nome segnalato come assente può restare assente dopo la correzione della rete, il che viene letto come un tunnel rotto quando è un TTL che non è scaduto. La specifica DNS descrive come questi dati devono essere conservati e riutilizzati.

Registrate l’evento, non l’impressione

Annotate quale delle tre cose è cambiata: il record, il percorso verso il resolver o un’impostazione del client. La modifica di un record si propaga secondo il proprio calendario, un cambio di rotta entra in vigore alla riconnessione e un’impostazione del browser vale solo per quel browser. Ridurle a un unico prima-e-dopo produce una cronologia che nessuno può verificare.

Annotate l’ora, il resolver in uso e la risposta ricevuta, incluso il caso in cui la risposta sia negativa. È un fatto che qualcun altro può controllare.

Eseguite il confronto due volte allo stesso modo

Svuotate la cache che intendete testare, conservate l’osservazione originale, poi interrogate in modo da aggirare quanta più memoria possibile. Nominare esplicitamente il resolver vi dice cosa sa quel resolver; non vi dice quale resolver avrebbe scelto l’applicazione.

resolvectl flush-caches
ipconfig /flushdns
dig +noall +answer internal.example @10.44.0.53
dig +short internal.example

Su Windows, lo svuotamento della cache client cancella la cache client DNS e nulla più. Non descrive lo stato privato di un browser e non svuota un server a monte, quindi un test costruito su di esso può essere interpretato solo in modo ristretto. Dite quale cache avete svuotato ogni volta che riportate il risultato.

Poi verificate di nuovo l’applicazione reale con una richiesta nuova e la politica del resolver prevista attiva. Un risultato prodotto con una politica diversa non si trasferisce.