I nomi interni brevi falliscono sulla VPN: il suffisso che non vedi mai
Un nome breve funziona solo perché un suffisso di ricerca lo completa. Confronta il nome completo e quello breve per separare una mancanza di suffisso da un guasto del resolver.
Il nome breve funzionava in ufficio e fallisce sulla VPN, mentre il nome completo si risolve senza problemi. Niente è rotto. Un nome nudo come intranet non è un nome completo; il client aggiunge un suffisso dalla sua lista di ricerca e chiede il risultato. Se il profilo VPN non fornisce quel suffisso, la familiare forma breve smette di esistere.
Questo è tutto il mito. Il DNS non si è rotto, è cambiata la politica di ricerca.
Un nome nudo non è un nome
Quando digiti una sola etichetta, il resolver deve decidere cosa chiedere. Prova il nome così com’è, poi aggiunge le voci della lista di ricerca una alla volta finché qualcosa risponde. Su Linux, resolv.conf controlla quell’ordine con le impostazioni search e ndots. Su Windows, la lista dei suffissi e la politica di risoluzione dei nomi fanno l’equivalente. Togli il suffisso e il resolver non ha più nulla da aggiungere.
Un nome breve che funziona è quindi prova di una politica, non prova di un server DNS sano.
Cosa fanno la lista dei suffissi e l’indirizzo del resolver
Queste due cose vengono confuse continuamente. L’indirizzo del resolver dice a chi chiedere; la lista dei suffissi dice su quale nome interrogare. Una VPN può darti un resolver privato senza suffisso, o un suffisso con il resolver sbagliato. Solo uno di questi guasti sembra un’interruzione del DNS.
Controllali separatamente, perché riparare quello sbagliato brucia una finestra di supporto.
| What you see | Likely cause |
|---|---|
| Full name resolves, short name fails | Suffix or search list missing |
| Neither resolves | Resolver unreachable or wrong domain rule |
| Both resolve, resource fails | Route or service permission |
Tre sintomi, tre responsabili diversi.
Prova prima il nome completo
Chiedi il nome completamente qualificato documentato dall’amministratore, non un’ipotesi. Un FQDN che funziona prova che il resolver è raggiungibile e che il record esiste, il che elimina metà delle cause possibili con una sola query. Usa uno strumento che mostri quale server ha risposto, così non leggi un risultato in cache.
Tieni il test privato. Inviare varianti interne a un resolver pubblico rivela nomi e verifica una politica che nessuno intendeva.
Dove va la correzione
Correggi il profilo proprietario o il sistema di gestione che lo genera. Una modifica manuale alla configurazione locale del resolver di solito scompare alla riconnessione, oppure si applica a ogni rete a cui la macchina si unisce, il che è peggio.
Su Windows, ispeziona la politica effettiva invece della casella che ricordi. Get-DnsClientNrptPolicy mostra le regole di risoluzione dei nomi realmente in vigore.
Su macOS, scutil --dns stampa la configurazione del resolver per interfaccia con scope, inclusi i domini di ricerca che la VPN ha spinto.
Su Linux, leggi la riga search in /etc/resolv.conf, ma controlla se un client VPN l’ha riscritta. Se il file è gestito, modifica la fonte di verità invece del file renderizzato. Una riga search obsoleta rimasta da una rete precedente è una causa comune.
Cosa conservare insieme al profilo
Conserva il nome completo corretto, la lista dei suffissi e l’indirizzo del resolver accanto al profilo del client. La prossima persona che segnala che il sito intranet è giù potrà confrontare tre valori noti invece di partire da una pagina bianca.
E se solo la forma breve fallisce, dillo nel ticket. Quella frase risparmia un pomeriggio al team dei resolver.