Un DNS pubblico che funziona non significa che Active Directory sia trovabile

La VPN si connette, il browser apre un sito pubblico e il portatile continua a non riuscire ad accedere al dominio. La conclusione abituale è che il DNS vada bene perché i nomi si risolvono. Non va bene, e il motivo è che un test nel browser esercita una sola interrogazione di una catena che un client aggiunto al dominio richiede. L’individuazione del dominio chiede prima i record di servizio, poi gli indirizzi dei controller che quei record nominano e infine una rotta verso le porte su cui quei controller sono in ascolto. Una risposta pubblica non soddisfa nessuno di questi passaggi.

Il mito: i nomi si risolvono, quindi il DNS è a posto

Che un sito pubblico si risolva dice solo che qualche resolver ha risposto a una interrogazione A o AAAA per un nome in una zona pubblica. Active Directory usa lo stesso protocollo per un’altra domanda: dove sono i servizi del dominio e quale controller deve usare questo client. La domanda è espressa come record SRV sotto una zona intitolata al dominio, e un resolver pubblico ricorsivo non ha motivo di tenerli.

Quando il record manca, il resolver restituisce una risposta negativa, che è una risposta DNS valida e non un’interruzione. Il client ripiega allora sulle informazioni sui controller in cache se ne ha, ed è esattamente per questo che un desktop può sembrare a posto per ore e fallire dopo un riavvio o un cambio di password.

Che cosa chiede davvero un client di dominio, in ordine

Per un dominio come corp.example, l’interrogazione generica del localizzatore è _ldap._tcp.dc._msdcs.corp.example. Le risposte SRV nominano controller candidati e le loro porte, poi il client ha bisogno dei record di indirizzo per quei nomi host prima di poter aprire una connessione. L’individuazione consapevole del sito aggiunge interrogazioni sotto il sottodominio del sito, e le risposte determinano quali controller sono preferiti, non quale sia obbligatorio.

nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example

Seguite la catena in quell’ordine, dalla rete in cui si verifica il problema. Un nome host che si risolve in un indirizzo irraggiungibile è un guasto di routing, non un guasto DNS. Un controller raggiungibile a cui mancano i record del localizzatore è un guasto DNS, non un guasto di routing. I due producono lamentele degli utenti simili e riparazioni del tutto diverse.

Perché un resolver pubblico risponde e l’accesso si rompe lo stesso

Se l’adattatore consegna al client un resolver pubblico, i nomi pubblici funzionano e lo spazio dei nomi interno no. Aggiungere un secondo resolver pubblico non aiuta, perché nessuno dei due detiene la zona. Nemmeno il consueto elenco «prima interno, poi pubblico» si comporta come una regola per dominio: una risposta negativa del primo server è una risposta legittima, e il client non riprova il secondo server solo perché la risposta era vuota.

Entrambi i resolver interni, se ne gestite due, devono detenere lo spazio dei nomi di AD ed essere raggiungibili dalla rete attuale del client. È questa la parte che i progetti a tunnel diviso rompono: la VPN può trasportare la sottorete del tunnel mentre il resolver interno si trova su un prefisso che il tunnel non instrada, così l’interrogazione esce verso un resolver che non può rispondervi.

Windows applica anche un criterio di risoluzione dei nomi che può indirizzare spazi dei nomi specifici verso server specifici, e gli indirizzi DNS mostrati dall’adattatore non sono tutta la storia. Cambiare l’elenco dell’adattatore senza cambiare quel criterio può lasciare intatta la configurazione effettiva, ed è per questo che una correzione che sembra applicata non ha alcun effetto.

Tenete d’accordo il DNS del tunnel e le sue rotte

Un profilo VPN che spinge un resolver ma non il prefisso che lo contiene crea un resolver che il client non può raggiungere; uno che spinge il prefisso senza alcun resolver lascia il client a interrogare quello locale. Trattate la coppia come un unico elemento di configurazione e verificate entrambi dopo ogni cambio di profilo, perché un invio riordinato o un nuovo criterio di tunnel diviso può separarli.

Verificate anche che cosa fa il client con l’impostazione inviata. Alcuni client applicano il server DNS solo all’interfaccia del tunnel e lasciano al suo posto il resolver dell’adattatore fisico, quindi quale vince dipende dalla metrica dell’interfaccia e dal nome interrogato. Se la risposta interna arriva solo quando l’adattatore fisico è disabilitato, quello è il meccanismo da correggere, non i record del dominio.

Accettate con una chiamata di individuazione e una sola operazione reale

Un test di accettazione utile esegue l’interrogazione del localizzatore e poi compie una vera operazione autenticata, come aprire una condivisione basata sulla directory o richiedere un ticket. Fatelo prima della transizione VPN e di nuovo dopo, sulla stessa macchina, senza riavvio nel mezzo. Le credenziali in cache e le sessioni già aperte faranno volentieri sembrare sano un percorso rotto, quindi un accesso riuscito al desktop non è il test.

Le raccomandazioni di Microsoft per il client DNS tracciano la stessa linea tra risolvere lo spazio dei nomi interno e inoltrare le interrogazioni pubbliche a monte, e questa è la disposizione da conservare quando si introduce una VPN.

Se il guasto è solo lento e non fallito, tenete il ritardo separato dalla diagnosi. Un timeout durante l’individuazione può venire da un controller irraggiungibile, da una porta bloccata o da un resolver che risponde tardi, e nessuno di questi è dimostrato dalla sola attesa. Registrate l’interrogazione reale, la sua risposta e il tentativo di connessione prima di cambiare un’impostazione del resolver.