O teu VPN empuxa tres servidores DNS: cal responde?

Abre a páxina de axustes tras conectarte e verás tres enderezos DNS; a pregunta da auditoría é cal atendeu a túa última consulta. O número por si só non responde nada, porque un empuxón do cliente, unha interface física e unha política por dominio escriben todos na mesma vista. Esas entradas teñen ámbitos distintos, e o ámbito, non a posición, decide quen responde. Empeza separando as fontes e despois proba a que posúe o nome que che importa.

Por que a lista é máis longa que o teu perfil

Un cliente VPN empuxa enderezos de resolutor para a ligazón do túnel, e o sistema operativo manténos xunto ao que xa tiña a interface física. Un router, unha concesión DHCP corporativa, unha segunda VPN e unha política por dominio achegan cada un a súa propia entrada. Por iso tres enderezos na páxina poden significar tres ámbitos en lugar de tres candidatos para unha tarefa. Ler o número como proba dunha fuga é o primeiro erro desta auditoría.

Dentro dunha interface, un cliente si proba os seus servidores en orde, así que unha lista ordenada non carece de sentido. O que non é unha cola é a vista combinada, onde as entradas do perfil, da ligazón física e das regras por dominio se sentan unha ao lado da outra sen unha única clasificación. Esa distinción decide que probas: a orde explica o comportamento dentro dun ámbito, e o ámbito explica todo o demais.

O DNS cifrado rompe o cadro desde dentro dunha aplicación. Un navegador ou un cliente de chat co seu propio resolutor DNS-over-HTTPS envía consultas por completo máis aló da lista do sistema operativo, así que os enderezos da páxina de axustes describen tráfico que a aplicación nunca xerou. Revisa o axuste de resolutor da propia aplicación antes de culpar ao perfil por un nome que saíu mal.

Que di cada unha das tres comprobacións

Cada fonte deixa a súa marca nun lugar distinto, e ningún comando único as mostra todas. Esta é a asignación que convén ter xunto á páxina de axustes:

Nun sistema que usa systemd-resolved, resolvectl status é a autoridade, porque informa do DNS por ligazón xunto cos dominios de encamiñamento. macOS responde mediante scutil --dns, que enumera os resolutores con ámbito na orde en que se proban. Windows divide as dúas metades: Get-DnsClientServerAddress para os servidores por interface e Get-DnsClientNrptPolicy para as regras de sufixo. Executa o comando que corresponda ao resolutor realmente en uso, porque unha máquina cun contorno de contedores e un resolutor de escritorio pode ter máis dun instalado.

Un resolutor de reserva que non pode responder pola túa zona

Unha segunda entrada adoita estar aí por dispoñibilidade, e a dispoñibilidade só funciona se a reserva coñece os nomes. Pide a un resolutor público un nome de host interno e devolve NXDOMAIN, ou unha resposta comodín dun dominio de busca que non ten nada que ver contigo. Un failover que ninguén comprobou produce entón unha caída xusto no momento en que se necesita.

Split DNS existe para evitalo: os sufixos da empresa van a un resolutor que ten a zona, e os nomes públicos quedan na ruta predeterminada. O deseño é sólido, e depende de que a lista de sufixos estea completa. Microsoft documenta a política de resolutor por sufixo que impulsa isto en Windows, e a mesma idea aparece como dominios de encamiñamento en systemd-resolved e como resolutores con ámbito en macOS.

Compara as zonas que a reserva pode responder cos sufixos presentes na política. Esa comparación atopa o oco antes de que un usuario informe de que un sitio interno deixou de resolverse tras un cambio de túnel.

Consulta a través da política, non ao seu redor

Consulta a través do resolutor do sistema operativo, porque unha consulta directa a un servidor evita a política e informa só do que diría ese servidor. A diferenza entre as dúas respostas é todo o asunto:

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

Se a consulta do sistema devolve un enderezo privado mentres a consulta directa devolve NXDOMAIN, a política funciona e a reserva é o punto débil. Se ambas devolven a mesma resposta pública, o nome estase resolvendo fóra do ámbito que pretendías, e a lista de sufixos é onde hai que mirar. Garda ambas as saídas, porque unha discusión sobre resolutores zánxase antes con dúas liñas que cunha captura da páxina de axustes.

Despois exercita a ruta de fallo, porque unha reserva que ninguén probou é unha suposición. Converte o resolutor preferido nun burato negro para unha consulta e observa que enderezo volve:

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

Borra esa ruta en canto termine a consulta, ou a seguinte persoa herda un misterio. Se os nomes internos seguen resolvéndose nesa ventá, algo fóra do ámbito previsto os respondeu. Se en cambio esgotan o tempo, falta a reserva ou está ben delimitada, e o propio rexistro do resolutor diche cal das dúas cousas foi.

Decide: conservar, delimitar ou eliminar

Conserva un segundo resolutor cando responde ao espazo de nomes que necesitas e segue accesible baixo o perfil. Delimítao cando deba ver un sufixo e nada máis, e elimínao cando non teña nin ámbito nin propósito documentado. Unha entrada sen traballo é unha fuga futura sen beneficio, e un valor predeterminado do provedor non é un propósito.

Rexistra o resultado en catro columnas: sufixo, resolutor, interface e responsable. Esa liña responde á seguinte pregunta de auditoría máis rápido que calquera captura, e sobrevive á actualización do cliente que reordena a lista en silencio.