NXDOMAIN su una VPN non significa un guasto del tunnel

È allettante leggere una ricerca fallita come prova che il tunnel è crollato, soprattutto quando il nome funzionava dieci minuti prima. La risposta dice altro. NXDOMAIN è una transazione DNS completata in cui un resolver ha dichiarato che il nome interrogato non esiste; un tunnel rotto di solito produce silenzio, un timeout o un tentativo di risoluzione verso il server sbagliato. La versione dell’argomento senza wireshark è una query, un risponditore e un codice di risposta, e quella terna vale la pena di essere registrata prima di qualsiasi modifica alla configurazione.

Che cosa stabilisce davvero la risposta

Il DNS separa esiti che i client spesso fondono in un unico fallimento. Un nome che non esiste produce una risposta negativa con il codice NXDOMAIN, mentre un nome che esiste ma non ha alcun record del tipo richiesto produce una risposta riuscita con una sezione delle risposte vuota. Entrambi sembrano nulla di utile a un’applicazione, e solo uno dei due significa che il nome è sbagliato.

Questa differenza decide dove va la riparazione. Un record AAAA mancante su un host che ha un record A non è un host mancante, e riemettere un certificato o ricostruire un tunnel per inseguirlo spreca l’unico indizio disponibile. La distinzione fissa anche la forma del seguito: un problema di denominazione si corregge nella zona, e un problema di tipo si corregge chiedendo il record giusto o accettando che la famiglia di indirizzi sia semplicemente assente.

Il mito: un nome privato mancante significa che il tunnel ha fallito

Il mito sopravvive perché i due eventi arrivano così spesso insieme. Un client si connette alla VPN, il sistema operativo conserva un resolver di cui si fidava già, e il nome interno che ora serve viene chiesto a un server che non ha mai sentito parlare della zona privata. Quel server risponde onestamente e in negativo. Il tunnel trasporta il pacchetto; la risposta riguarda solo uno spazio dei nomi che il risponditore non serve.

Le disposizioni a orizzonte diviso rendono tutto questo routine: lo stesso nome di zona esiste pubblicamente e internamente con contenuti diversi, e solo il resolver interno conosce i record privati. Ottenere una risposta negativa che sembra autorevole è quindi prova di quale resolver ha risposto, non prova dello stato dell’interfaccia.

Due dettagli di configurazione decidono l’esito. Il tunnel deve spingere o selezionare il resolver interno, e il client deve applicare quella scelta al nome cercato. Una regola per dominio che nomina un suffisso leggermente diverso dal record digitato manderà la query sul percorso pubblico, e la risposta sarà corretta e inutile.

Interrogate il resolver giusto con il nome giusto

Registrate il risponditore prima di registrare il verdetto. Una ricerca che non mostra quale server ha risposto non può distinguere un problema di policy da un problema di spazio dei nomi, e i due hanno correzioni non correlate.

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

Le prime due righe mostrano che cosa ha deciso il resolver locale e chi interrogherebbe. La ricerca +search riproduce ciò che fa un’applicazione quando aggiunge un suffisso di ricerca, che spesso è la query reale e non quella digitata in uno strumento diagnostico. L’ultima riga interroga direttamente il server interno, aggirando la policy del client; se questo riesce mentre la ricerca semplice fallisce, la zona è a posto e l’instradamento delle query non lo è.

La cache negativa spiega il ritardo dopo una correzione

Le risposte negative vengono messe in cache per progetto, e RFC 2308 descrive come la durata della cache negativa sia derivata dal record di autorità della zona. Correggere un record o una regola del resolver non garantisce quindi un cambiamento immediato sul client, e riprovare una ricerca che continua a restituire la risposta in cache non dimostra nulla di nuovo. Solo un risponditore diverso, un nome diverso o una cache svuotata producono prove fresche.

Svuotate la cache locale, poi ripetete la stessa query contro lo stesso risponditore. Sui sistemi che usano il servizio resolver locale è un solo comando; su altri è un riavvio del servizio o un’utilità della piattaforma, e lo strumento specifico conta meno del ripetere poi un test identico.

Separate il nome dal percorso

Una volta che il nome risolve all’indirizzo privato atteso, il DNS è finito come argomento e il percorso dell’applicazione diventa la domanda successiva. Un host che risponde alle ricerche ma rifiuta una connessione ha un altro problema, e continuare a regolare i resolver dopo una risposta corretta è il modo in cui un incidente raccoglie tre modifiche non correlate. Confrontate l’indirizzo risolto con quello su cui il servizio ascolta davvero prima di presumere che i due coincidano.

Conservate la trascrizione: la query, il risponditore, il codice e l’indirizzo risolto. Quella registrazione è anche ciò che rende verificabile un rapporto successivo, ed è la differenza tra una diagnosi e una storia su un tunnel che sembrava lento.