Cattura Split-DNS: dite dove è stata presa ogni osservazione

Due persone diagnosticano lo stesso problema Split-DNS e ottengono indirizzi del resolver diversi. Una ha usato uno strumento di ricerca, una seconda ha catturato pacchetti sull’adattatore e una terza ha letto la diagnostica del client stesso. Nessuna mente, e nessuna descrive la stessa fase. Dare un nome al punto di osservazione trasforma una contraddizione in una mappa.

Una ricerca, più punti di osservazione

Per un solo nome interno ci sono almeno cinque posti da guardare: l’applicazione e l’API del resolver che chiama, la politica di dominio effettiva sul client, una cattura sull’adattatore o sul filtro, un confine di gateway controllato e il resolver che riceve davvero la query.

Ognuno risponde a una domanda diversa, e nessuno da solo dimostra dove è andata la query.

Una cattura sull’adattatore mostra pacchetti, non intenzioni. Non dice quale resolver ha scelto il client, e una cattura vuota può significare una risposta in cache o un’altra API del resolver invece di un pacchetto scartato. Trattate ogni osservazione come prova di una fase. Poi montate le fasi in un percorso.

Il filtro del client sta tra l’applicazione e il cavo

Un client VPN con Split-DNS applica la corrispondenza dei domini prima che il pacchetto lasci la macchina. I nomi nel suffisso instradato nel tunnel vanno al resolver interno; tutto il resto va a quello locale. Il filtro è politica, e la politica può variare per piattaforma e versione del client.

La guida Split-DNS di Secure Client di Cisco copre la corrispondenza dei domini e il filtro di Windows, e separa ciò che vede un’applicazione quando usa l’API nativa del resolver da ciò che vede uno strumento come nslookup. Sono proprio queste distinzioni il punto.

Partite dal profilo effettivo e da una normale ricerca dell’applicazione. Qualsiasi test che nomini un server esplicito è una deviazione deliberata; spiegatela con la diagnostica del client stesso e non lasciate che diventi il criterio di accettazione.

nslookup segue un percorso diverso da quello dell’applicazione

nslookup costruisce la propria query DNS e può aggirare la politica del resolver del sistema operativo. Questo lo rende utile per porre una domanda precisa a un server preciso, e fuorviante per verificare ciò che un’applicazione vivrà.

In Windows la tabella dei criteri di risoluzione dei nomi decide quale suffisso usa quale server. Leggerla mostra la politica che l’applicazione seguirà, ed è spesso il pezzo mancante.

Leggete la politica e poi ponete la stessa domanda tramite il resolver normale:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

I resolver cifrati nascondono la query, non la connessione

Un browser con il proprio resolver DNS-over-HTTPS è un caso del tutto diverso. La query esce dentro TLS, quindi una cattura di pacchetti mostra una connessione verso un indirizzo del resolver ma non il nome richiesto.

Stabilite prima la politica gestita del browser, poi confrontatela con una ricerca del sistema operativo. Un browser autorizzato a scegliere il proprio resolver potrebbe non vedere affatto la politica Split-DNS.

La stessa cautela vale per qualsiasi client che porti con sé il proprio resolver. Una cattura che identifica la connessione remota non è prova del nome della query. Se vi serve il nome, prendetelo dai log del resolver stesso o dalla diagnostica dell’applicazione, con le regole sulla privacy applicabili.

Confrontate con un test etichettato

Scegliete un nome interno approvato per il test, più un nome pubblico che non porti alcun significato sensibile. Per ciascuno, annotate l’ora, il tipo di record, la risposta e la politica attesa.

Dove è consentito, confrontate la ricezione del resolver con una sola osservazione ristretta del client o del gateway:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

Non inviate mai nomi privati a resolver pubblici non correlati solo per creare un confronto, e oscurate tutto ciò che condividete. Infine, separate una risposta DNS corretta dalla connessione al servizio che segue: l’indirizzo privato risolto ha ancora bisogno di una rotta e di un’autorizzazione applicativa.