O seu VPN envia três servidores DNS: qual responde?

Abra a página de definições após ligar e três endereços DNS aparecem; a pergunta da auditoria é qual deles tratou da sua última consulta. O número por si só não responde a nada, porque um empurrão do cliente, uma interface física e uma política por domínio escrevem todos na mesma vista. Essas entradas têm âmbitos diferentes, e o âmbito, não a posição, decide quem responde. Comece por separar as fontes e depois teste a que possui o nome que lhe interessa.

Porque é que a lista é mais longa do que o seu perfil

Um cliente VPN envia endereços de resolvedor para a ligação do túnel, e o sistema operativo mantém-nos ao lado do que a interface física já tinha. Um router, um aluguer DHCP empresarial, uma segunda VPN e uma política por domínio contribuem cada um com a sua própria entrada. Três endereços na página podem, por isso, significar três âmbitos em vez de três candidatos para uma tarefa. Ler o número como prova de uma fuga é o primeiro erro desta auditoria.

Dentro de uma interface, um cliente tenta de facto os seus servidores por ordem, pelo que uma lista ordenada não é sem sentido. O que não é uma fila é a vista combinada, onde as entradas do perfil, da ligação física e das regras por domínio ficam lado a lado sem uma única classificação. Essa distinção decide o que testa: a ordem explica o comportamento dentro de um âmbito, e o âmbito explica tudo o resto.

O DNS cifrado quebra o quadro a partir do interior de uma aplicação. Um navegador ou cliente de chat com o seu próprio resolvedor DNS-over-HTTPS envia consultas completamente fora da lista do sistema operativo, pelo que os endereços na página de definições descrevem tráfego que a aplicação nunca gerou. Verifique a definição de resolvedor da própria aplicação antes de culpar o perfil por um nome que saiu mal.

O que diz cada uma das três verificações

Cada fonte deixa a sua marca num local diferente, e nenhum comando único as mostra todas. Este é o mapeamento que vale a pena guardar ao lado da página de definições:

Num sistema que usa systemd-resolved, resolvectl status é a autoridade, porque reporta o DNS por ligação juntamente com os domínios de encaminhamento. O macOS responde através de scutil --dns, que lista os resolvedores com âmbito pela ordem em que são tentados. O Windows divide as duas metades: Get-DnsClientServerAddress para servidores por interface e Get-DnsClientNrptPolicy para as regras de sufixo. Execute o comando que corresponde ao resolvedor realmente em uso, porque uma máquina com um ambiente de contentores e um resolvedor de ambiente de trabalho pode ter mais do que um instalado.

Um resolvedor de reserva que não consegue responder pela sua zona

Uma segunda entrada existe geralmente para disponibilidade, e a disponibilidade só funciona se a reserva conhecer os nomes. Peça a um resolvedor público um nome de anfitrião interno e ele devolve NXDOMAIN, ou uma resposta com caráter genérico de um domínio de pesquisa que nada tem a ver consigo. Um failover que ninguém verificou produz então uma falha exatamente no momento em que é necessário.

O Split DNS existe para o evitar: os sufixos da empresa vão para um resolvedor que detém a zona, e os nomes públicos ficam no caminho predefinido. O desenho é sólido, e depende de a lista de sufixos estar completa. A Microsoft documenta a política de resolvedor por sufixo que impulsiona isto no Windows, e a mesma ideia aparece como domínios de encaminhamento no systemd-resolved e como resolvedores com âmbito no macOS.

Compare as zonas a que a reserva pode responder com os sufixos presentes na política. Essa comparação encontra a lacuna antes de um utilizador relatar que um sítio interno deixou de resolver após uma mudança de túnel.

Consulte através da política, não à volta dela

Consulte através do resolvedor do sistema operativo, porque uma consulta direta a um servidor contorna a política e reporta apenas o que esse servidor diria. A diferença entre as duas respostas é todo o assunto:

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

Se a consulta do sistema devolve um endereço privado enquanto a consulta direta devolve NXDOMAIN, a política funciona e a reserva é o ponto fraco. Se ambas devolvem a mesma resposta pública, o nome está a ser resolvido fora do âmbito que pretendia, e a lista de sufixos é o local onde olhar. Guarde ambas as saídas, porque uma discussão sobre resolvedores resolve-se mais depressa com duas linhas do que com uma captura da página de definições.

Depois exercite o caminho de falha, porque uma reserva que ninguém testou é uma suposição. Transforme o resolvedor preferido num buraco negro para uma consulta e observe que endereço volta:

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

Apague essa rota assim que a consulta terminar, ou a pessoa seguinte herda um mistério. Se os nomes internos ainda resolverem nessa janela, algo fora do âmbito previsto respondeu-lhes. Se em vez disso expirarem, falta a reserva ou está corretamente delimitada, e o próprio registo do resolvedor diz-lhe qual das duas coisas foi.

Decida: manter, delimitar ou remover

Mantenha um segundo resolvedor quando responde ao espaço de nomes de que precisa e continua acessível sob o perfil. Delimite-o quando só deve ver um sufixo e mais nada, e remova-o quando não tem âmbito nem propósito documentado. Uma entrada sem trabalho é uma fuga futura sem benefício, e um valor predefinido do fornecedor não é um propósito.

Registe o resultado em quatro colunas: sufixo, resolvedor, interface e responsável. Essa linha responde à próxima pergunta da auditoria mais depressa do que qualquer captura, e sobrevive à atualização do cliente que reordena a lista em silêncio.