Due server DNS su un adattatore non separano gli spazi dei nomi

Elencare due resolver su un adattatore sembra un modo per inviare un dominio a un server e un altro dominio all’altro, e nulla nell’elenco dei resolver funziona così. Windows risolve per nome, e la decisione su quale server interrogare proviene da oggetti di criterio anziché da un elenco ordinato di indirizzi. Il modello mentale da sostituire è la coda: non esiste un primo server per il dominio A né un secondo server per il dominio B. Esiste un insieme di regole per spazio dei nomi che nomina i server in modo esplicito, e una volta che queste regole esistono, l’elenco dell’adattatore smette di essere interessante.

Il mito: due indirizzi separano due domini

La convinzione sopravvive perché funziona per caso quando un server risponde a tutto e il secondo è solo un ripiego. Un client interroga il primo server, quel server inoltra o esegue ricorsione, e la risposta arriva; nessuno nota quale resolver deteneva davvero la zona. L’illusione si rompe nel momento in cui i due spazi dei nomi vivono in zone private separate senza inoltro tra loro, perché allora il primo server risponde con autorità che il nome non esiste. Una risposta negativa del primo server non attiva il ripiego, poiché il client ha ricevuto una risposta definitiva e non un errore.

Un elenco ordinato non ha alcun concetto di dominio, quindi non può esprimere l’intento. Ciò che l’elenco controlla davvero è quale server viene interrogato per primo e quale viene provato per secondo, e entrambe le risposte valgono allo stesso modo per ogni nome.

Che cosa usa davvero Windows per scegliere

La tabella dei criteri di risoluzione dei nomi abbina un nome agli spazi dei nomi configurati e seleziona i server e le opzioni per quella corrispondenza. Le regole possono essere configurate localmente, distribuite tramite criteri di gruppo o fornite da un profilo VPN, e il criterio effettivo è una combinazione e non un unico elenco. Per questo la prima diagnostica è sempre lo stato effettivo: una regola creata localmente che perde contro un criterio gestito produce un laboratorio che non si comporta affatto come la sua configurazione suggerisce. Le regole sono anche confrontate per specificità, così una voce ampia di spazio dei nomi può oscurare una ristretta in modi invisibili in un elenco di elementi configurati. Leggere l’ordine effettivo è l’unico modo per vedere quale regola vince.

Get-DnsClientNrptRule
Get-DnsClientNrptPolicy -Effective

Il primo comando elenca ciò che è configurato sulla macchina; il secondo mostra ciò che il client applicherà davvero, comprese le voci provenienti da altrove. Se l’output effettivo contiene spazi dei nomi gestiti, il proprietario di quel criterio è il posto giusto per chiedere la modifica, non l’elenco locale delle regole. Entrambi i comandi leggono solo lo stato, quindi eseguirli prima che qualcuno accetti la modifica non costa nulla.

Una regola per spazio dei nomi, conservate l’oggetto

Una volta compreso lo stato effettivo, create una regola per spazio dei nomi e conservate l’oggetto che ogni comando restituisce. I nomi visualizzati sono etichette per le persone, e l’identificatore univoco nell’oggetto restituito è poi il bersaglio affidabile per l’eliminazione. Scrivete entrambi gli identificatori nella stessa nota di modifica che registra gli spazi dei nomi e i resolver, perché la sessione che li ha creati non sarà quella che pulisce.

$svcRule = Add-DnsClientNrptRule -Namespace ".svc.internal.example" -NameServers "10.60.0.53" -DisplayName "VPN lab services" -PassThru
$resRule = Add-DnsClientNrptRule -Namespace ".research.internal.example" -NameServers "10.61.0.53" -DisplayName "VPN lab research" -PassThru
$svcRule | Select-Object Name, Namespace, NameServers
$resRule | Select-Object Name, Namespace, NameServers

Il punto iniziale indica una corrispondenza di suffisso, quindi la regola copre app.svc.internal.example e qualsiasi altra cosa sotto di esso. I due indirizzi qui appartengono al piano di routing proprio di questo laboratorio; una regola non crea una zona, non installa una rotta e non autorizza l’applicazione che alla fine si connette, e la documentazione di Add-DnsClientNrptRule spiega esattamente quale parametro fa cosa.

Notate cosa non fanno questi comandi: sono validi per tutta la macchina, non sono limitati a una sessione VPN, e sopravvivono alla chiusura della finestra. Un laboratorio che lo dimentica lascia criteri dietro di sé una volta scomparso il tunnel.

Dimostrate che il client ha scelto il server

Chiedere a un server specifico se conosce un nome dimostra che il server può rispondere, il che non è la stessa affermazione del fatto che il client abbia scelto quel server. Il test che conta risolve un nome reale attraverso il percorso ordinario del client e poi conferma quale resolver se ne è occupato, idealmente mentre il tunnel che fornisce la rotta è attivo. Se il tunnel è inattivo, una regola correttamente delimitata punta comunque a un server irraggiungibile, che è un problema di routing e non di criterio. Testate entrambi gli stati per poterli distinguere in seguito.

Resolve-DnsName app.svc.internal.example
Resolve-DnsName build.research.internal.example
Resolve-DnsName app.svc.internal.example -DnsOnly -NoHostsFile

Attenzione alle risposte in cache del periodo precedente all’esistenza delle regole, e alle applicazioni che aggirano del tutto il resolver di sistema con il proprio DNS cifrato. I suffissi di ricerca sono un’altra funzione separata: una regola può scegliere un resolver per un nome completo senza insegnare a Windows ad espandere un nome host nudo in quello spazio dei nomi.

Rimuovete esattamente ciò che avete creato

La pulizia è il punto in cui un laboratorio diventa una storia ammonitrice. Eliminare ogni regola sulla macchina è rapido e rimuove criteri da cui dipende qualcun altro, quindi usate gli identificatori catturati quando le regole sono state create, e rileggete lo stato effettivo dopo per confermare che la macchina è tornata dov’era. Se la sessione che le ha create non c’è più, la nota di modifica è l’unico posto in cui gli identificatori esistono. È questa la ragione per scriverli prima che venga eseguito il primo comando, e non dopo.

Remove-DnsClientNrptRule -Name $svcRule.Name -Force
Remove-DnsClientNrptRule -Name $resRule.Name -Force
Get-DnsClientNrptPolicy -Effective

Per una distribuzione e non per un laboratorio, la questione della durata conta quanto la regola. Un profilo VPN può portare le regole dello spazio dei nomi e scegliere se persistono oltre la connessione; una regola che persiste mentre il resolver è irraggiungibile lascia i client a preferire un server morto, e una regola limitata alla connessione scompare quando scompare il tunnel. Decidete quale di questi comportamenti serve al servizio, indicate chi possiede la regola, e lasciate la divisione dell’autorità documentata accanto al profilo anziché nella memoria di qualcuno su un laboratorio.