La tua VPN spinge tre server DNS: quale risponde?

Apri la pagina delle impostazioni dopo la connessione e tre indirizzi DNS sono elencati; la domanda dell’audit è quale ha gestito la tua ultima query. Il numero da solo non risponde a nulla, perché una spinta del client, un’interfaccia fisica e una politica per dominio scrivono tutti nella stessa vista. Queste voci portano ambiti diversi, e l’ambito, non la posizione, decide chi risponde. Inizia separando le fonti, poi prova quella che possiede il nome che ti interessa.

Perché la lista è più lunga del tuo profilo

Un client VPN spinge indirizzi di resolver per il collegamento del tunnel, e il sistema operativo li tiene accanto a ciò che l’interfaccia fisica aveva già. Un router, una lease DHCP aziendale, una seconda VPN e una politica per dominio aggiungono ciascuno la propria voce. Quindi tre indirizzi nella pagina possono significare tre ambiti anziché tre candidati per un compito. Leggere il numero come prova di una fuga è il primo errore di questo audit.

All’interno di un’interfaccia un client prova davvero i suoi server in ordine, quindi una lista ordinata non è priva di senso. Ciò che non è una coda è la vista unita, dove le voci del profilo, del collegamento fisico e delle regole per dominio stanno una accanto all’altra senza un unico ordine. Quella distinzione decide cosa provare: l’ordine spiega il comportamento dentro un ambito, e l’ambito spiega tutto il resto.

Il DNS cifrato rompe il quadro dall’interno di un’applicazione. Un browser o un client di chat con il proprio resolver DNS-over-HTTPS invia le query completamente oltre la lista del sistema operativo, quindi gli indirizzi nella pagina delle impostazioni descrivono traffico che l’app non ha mai generato. Controlla l’impostazione del resolver dell’app prima di incolpare il profilo per un nome uscito male.

Cosa dice ciascuno dei tre controlli

Ogni fonte lascia il proprio segno in un punto diverso, e nessun comando unico le mostra tutte. Questa è la mappatura che vale la pena tenere accanto alla pagina delle impostazioni:

Su un sistema che usa systemd-resolved, resolvectl status è l’autorità, perché riporta il DNS per collegamento insieme ai domini di instradamento. macOS risponde tramite scutil --dns, che elenca i resolver con ambito nell’ordine in cui vengono provati. Windows divide le due metà: Get-DnsClientServerAddress per i server per interfaccia e Get-DnsClientNrptPolicy per le regole di suffisso. Esegui il comando che appartiene al resolver realmente in uso, perché una macchina con un runtime per container e un resolver desktop può averne più di uno installato.

Un resolver di riserva che non può rispondere per la tua zona

Una seconda voce di solito c’è per la disponibilità, e la disponibilità funziona solo se il ripiego conosce i nomi. Chiedi a un resolver pubblico un nome host interno e restituisce NXDOMAIN, oppure una risposta con caratteri jolly da un dominio di ricerca che non ha nulla a che fare con te. Un failover che nessuno ha verificato produce allora un’interruzione proprio nel momento in cui serve.

Split DNS esiste per evitarlo: i suffissi aziendali vanno a un resolver che detiene la zona, e i nomi pubblici restano sul percorso predefinito. Il progetto è solido, e dipende dal fatto che la lista dei suffissi sia completa. Microsoft documenta la politica del resolver per suffisso che guida tutto questo su Windows, e la stessa idea compare come domini di instradamento in systemd-resolved e come resolver con ambito su macOS.

Confronta le zone a cui il ripiego può rispondere con i suffissi presenti nella politica. Quel confronto trova il vuoto prima che un utente segnali che un sito interno ha smesso di risolversi dopo un cambio di tunnel.

Interroga attraverso la politica, non attorno ad essa

Interroga attraverso il resolver del sistema operativo, perché una query diretta a un server aggira la politica e riporta solo ciò che quel server direbbe. La differenza tra le due risposte è tutto il punto:

resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53

Se la query di sistema restituisce un indirizzo privato mentre la query diretta restituisce NXDOMAIN, la politica funziona e il ripiego è il punto debole. Se entrambe restituiscono la stessa risposta pubblica, il nome viene risolto fuori dall’ambito previsto, e la lista dei suffissi è il posto da guardare. Conserva entrambi gli output, perché una discussione sul resolver si chiude prima con due righe che con uno screenshot della pagina delle impostazioni.

Poi esercita il percorso di guasto, perché un ripiego che nessuno ha provato è una supposizione. Trasforma il resolver preferito in un buco nero per una query e osserva quale indirizzo torna:

ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32

Elimina quella rotta appena la query finisce, altrimenti la persona successiva eredita un mistero. Se i nomi interni si risolvono ancora in quella finestra, qualcosa fuori dall’ambito previsto ha risposto. Se invece scadono, il ripiego manca o è correttamente delimitato, e il registro del resolver ti dice quale delle due cose è stato.

Decidi: conservare, delimitare o rimuovere

Conserva un secondo resolver quando risponde allo spazio dei nomi che ti serve e resta raggiungibile sotto il profilo. Delimitalo quando deve vedere un solo suffisso e nient’altro, e rimuovilo quando non ha né ambito né scopo documentato. Una voce senza lavoro è una fuga futura senza beneficio, e un valore predefinito del fornitore non è uno scopo.

Registra il risultato in quattro colonne: suffisso, resolver, interfaccia e responsabile. Quella riga risponde alla prossima domanda dell’audit più in fretta di qualsiasi screenshot, e sopravvive all’aggiornamento del client che riordina la lista in silenzio.