La teva VPN empeny tres servidors DNS: quin respon?

Obre la pàgina de configuració després de connectar-te i veuràs tres adreces DNS; la pregunta de l’auditoria és quina va atendre la teva darrera consulta. El nombre per si sol no respon res, perquè un enviament del client, una interfície física i una política per domini escriuen tots a la mateixa vista. Aquestes entrades tenen àmbits diferents, i l’àmbit, no la posició, decideix qui respon. Comença separant les fonts i després prova la que posseeix el nom que t’importa.

Per què la llista és més llarga que el teu perfil

Un client VPN empeny adreces de resolució per a l’enllaç del túnel, i el sistema operatiu les manté al costat del que ja tenia la interfície física. Un router, una concessió DHCP corporativa, una segona VPN i una política per domini aporten cadascun la seva pròpia entrada. Per això tres adreces a la pàgina poden significar tres àmbits en lloc de tres candidats per a una tasca. Llegir el nombre com a prova d’una fuita és el primer error d’aquesta auditoria.

Dins d’una interfície, un client sí que prova els seus servidors en ordre, així que una llista ordenada no és sense sentit. El que no és una cua és la vista combinada, on les entrades del perfil, de l’enllaç físic i de les regles per domini seuen una al costat de l’altra sense una única classificació. Aquesta distinció decideix què proves: l’ordre explica el comportament dins d’un àmbit, i l’àmbit explica tota la resta.

El DNS xifrat trenca el quadre des de dins d’una aplicació. Un navegador o un client de xat amb el seu propi resolutor DNS-over-HTTPS envia consultes completament més enllà de la llista del sistema operatiu, així que les adreces de la pàgina de configuració descriuen trànsit que l’aplicació mai no va generar. Revisa la configuració de resolutor de la pròpia aplicació abans de culpar el perfil per un nom que va sortir malament.

Què diu cadascuna de les tres comprovacions

Cada font deixa la seva marca en un lloc diferent, i cap ordre única les mostra totes. Aquest és el mapatge que val la pena tenir al costat de la pàgina de configuració:

En un sistema que utilitza systemd-resolved, resolvectl status és l’autoritat, perquè informa del DNS per enllaç juntament amb els dominis d’encaminament. macOS respon mitjançant scutil --dns, que enumera els resolutors amb àmbit en l’ordre en què es proven. Windows divideix les dues meitats: Get-DnsClientServerAddress per als servidors per interfície i Get-DnsClientNrptPolicy per a les regles de sufix. Executa l’ordre que correspon al resolutor realment en ús, perquè una màquina amb un entorn de contenidors i un resolutor d’escriptori pot tenir-ne més d’un instal·lat.

Un resolutor de reserva que no pot respondre per la teva zona

Una segona entrada sol ser-hi per disponibilitat, i la disponibilitat només funciona si la reserva coneix els noms. Demana a un resolutor públic un nom d’amfitrió intern i retorna NXDOMAIN, o una resposta comodí d’un domini de cerca que no té res a veure amb tu. Un failover que ningú no va comprovar produeix llavors una caiguda just en el moment en què cal.

Split DNS existeix per evitar-ho: els sufixos de l’empresa van a un resolutor que té la zona, i els noms públics queden a la ruta predeterminada. El disseny és sòlid, i depèn que la llista de sufixos sigui completa. Microsoft documenta la política de resolutor per sufix que impulsa això a Windows, i la mateixa idea apareix com a dominis d’encaminament a systemd-resolved i com a resolutors amb àmbit a macOS.

Compara les zones que la reserva pot respondre amb els sufixos presents a la política. Aquesta comparació troba el buit abans que un usuari informi que un lloc intern va deixar de resoldre’s després d’un canvi de túnel.

Consulta a través de la política, no a la vora

Consulta a través del resolutor del sistema operatiu, perquè una consulta directa a un servidor evita la política i només informa del que diria aquell servidor. La diferència entre les dues respostes és tot l’afer:

resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53

Si la consulta del sistema retorna una adreça privada mentre la consulta directa retorna NXDOMAIN, la política funciona i la reserva és el punt feble. Si totes dues retornen la mateixa resposta pública, el nom s’està resolent fora de l’àmbit que pretenies, i la llista de sufixos és on cal mirar. Guarda les dues sortides, perquè una discussió sobre resolutors es tanca abans amb dues línies que amb una captura de la pàgina de configuració.

Després exercita la ruta de fallada, perquè una reserva que ningú no va provar és una suposició. Converteix el resolutor preferit en un forat negre per a una consulta i observa quina adreça torna:

ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32

Esborra aquesta ruta tan bon punt acabi la consulta, o la persona següent hereta un misteri. Si els noms interns encara es resolen en aquesta finestra, alguna cosa fora de l’àmbit previst els va respondre. Si en canvi esgoten el temps, falta la reserva o està ben delimitada, i el registre del propi resolutor et diu quina de les dues coses va ser.

Decideix: conservar, delimitar o eliminar

Conserva un segon resolutor quan respon a l’espai de noms que necessites i continua accessible sota el perfil. Delimita’l quan només ha de veure un sufix i res més, i elimina’l quan no té ni àmbit ni propòsit documentat. Una entrada sense feina és una fuita futura sense benefici, i un valor predeterminat del proveïdor no és un propòsit.

Registra el resultat en quatre columnes: sufix, resolutor, interfície i responsable. Aquesta línia respon la següent pregunta d’auditoria més de pressa que qualsevol captura, i sobreviu a l’actualització del client que reordena la llista en silenci.