Rapporto DNS VPN: cosa includere perché sia riproducibile

«Il DNS è rotto» è una conclusione, e non è una conclusione su cui un aiutante possa agire. La parte utile di un rapporto è la forma del guasto: quale nome, attraverso quale resolver, con quale risposta. Tre dettagli trasformano un reclamo in qualcosa di riproducibile, e tutti e tre sono sicuri da condividere una volta rinominati i dettagli privati. Quello che segue è il minimo di cui un rapporto DNS VPN ha bisogno prima che qualcuno possa aiutare.

Una categoria di nome, non un verdetto

Parti dal nome stesso e classificalo: pubblico, interno, breve, completamente qualificato o servito da un suffisso specifico. Un nome interno che fallisce mentre i nomi pubblici si risolvono indica la selezione del resolver e non la raggiungibilità. Se falliscono tutti i nomi, indica il percorso verso il resolver, che è un’indagine diversa con prove diverse. La categoria porta la diagnosi, e la stringa esatta può essere oscurata.

Di’ se il guasto richiede che il tunnel sia attivo o se avviene dopo la disconnessione. Un nome che si rompe solo mentre la VPN è attiva implica la configurazione per collegamento, mentre uno che si rompe dopo la disconnessione implica uno stato residuo. I rapporti di solito lo omettono e poi si chiedono perché il primo suggerimento non aiuti.

Registra il percorso del resolver

Una query inviata a un server scelto esplicitamente e la ricerca ordinaria di un’applicazione sono esperimenti diversi. Di’ quale dei due ha prodotto il guasto, perché una query manuale a un server funzionante dimostra solo che il server funziona. I comandi seguenti separano il percorso di sistema da una domanda diretta.

resolvectl status --no-pager
getent hosts host.internal
dig +short host.internal @10.20.30.53

L’output di stato nomina i server per collegamento e i domini di routing, cioè dove si decide lo split DNS. La chiamata a getent segue lo stesso percorso dell’applicazione, incluso l’ordine di nsswitch. La query diretta li aggira entrambi e prova un solo server in isolamento. Indica quale dei tre ha fallito e quale ha funzionato, e il lettore non deve più indovinare il percorso.

Indica il confronto controllato

Cambia una variabile e di’ cosa è cambiato. Che i nomi pubblici si risolvano mentre quelli interni falliscono è un problema di selezione; che ogni nome vada in timeout è un problema di percorso; e un nome privato che si risolve in un indirizzo pubblico è una fuga verso il resolver sbagliato. Due di queste tre cose non hanno nulla a che fare con il fatto che il tunnel sia attivo. Un rapporto che afferma che tutte le query sono rotte di solito contiene un confronto che non è mai stato eseguito.

Separa la risoluzione dalla consegna. Quando il nome si risolve e il sito fallisce ancora, la fase DNS è riuscita e il rapporto dovrebbe dirlo, perché il passo successivo è una rotta o un listener e non un resolver. Quella sola distinzione risparmia un giro di domande più spesso di qualsiasi estratto di log.

Oscura lo spazio dei nomi, conserva le relazioni

I nomi interni possono essere sostituiti, purché le sostituzioni preservino la struttura. Mappa ogni server e suffisso distinto su un’etichetta stabile, e tieni quella mappatura fuori dalla copia condivisa. Sostituire ogni host interno con lo stesso segnaposto distrugge esattamente la prova che il rapporto richiede, perché il lettore non può più vedere che un suffisso si è risolto e un altro no. La stessa regola vale per gli indirizzi: conserva le relazioni di prefisso e cambia i bit dell’host se la policy lo richiede.

Invia il record attraverso il canale verificato e lascia fuori ciò che la diagnosi non richiede mai. Le password, le chiavi private e i nomi di aziende non correlate non fanno parte di una domanda DNS. Ciò che serve al lettore è la categoria del guasto, il percorso del resolver, l’errore esatto e l’unico confronto che hai eseguito.