Por que sua entrada em /etc/hosts não chega ao DNS da VPN

Você adicionou um nome em /etc/hosts, conectou-se à VPN e esperava que o registro aparecesse para todos. Isso não acontece, e a surpresa costuma vir com um segundo sintoma: o nome resolve na sua máquina e falha na de um colega, o que parece um serviço DNS da VPN quebrado e na verdade é o arquivo hosts fazendo exatamente o que foi projetado para fazer. Um arquivo hosts é configuração local de resolução de nomes, não uma atualização de zona, e nada em uma conexão VPN normal o envia.

Hosts é uma substituição local, não uma atualização de zona

O arquivo é uma lista de mapeamentos que as bibliotecas de serviço de nomes consultam antes de, ou em vez de, perguntar a um servidor DNS. Uma linha como 10.40.0.20 build.corp.example muda o que as aplicações daquela única máquina concluem. Não cria um registro, não viaja pelo túnel, e o servidor DNS para o qual o túnel aponta não tem ideia de que ela existe.

Por isso a falha é assimétrica. Seu cliente obtém uma resposta do arquivo. Outro cliente pergunta ao servidor DNS da VPN, que não retorna nada, e a aplicação informa que o nome não existe. As duas máquinas se comportam corretamente; apenas uma tem uma substituição que a outra nunca viu.

Dois comandos, dois componentes diferentes

A forma mais rápida de encerrar a discussão é tornar a diferença visível em dois comandos, ambos executados no cliente que tem a entrada hosts:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

O primeiro pergunta ao próprio caminho de busca do sistema, que em um sistema glibc típico lê arquivos locais antes do DNS. O segundo envia uma consulta DNS diretamente ao servidor naquele endereço e não consulta arquivos locais de forma alguma. Quando o primeiro retorna sua entrada e o segundo retorna NXDOMAIN, você provou que o registro não existe no DNS e que sua máquina responde a partir de uma substituição local.

A ordem é configurável, e vale a pena verificá-la antes de concluir qualquer coisa sobre uma distribuição específica. Veja a linha hosts: em /etc/nsswitch.conf; hosts: files dns consulta primeiro os arquivos. Não copie esse exemplo sobre uma configuração que funciona só para mudar a ordem, porque sistemas reais costumam listar fontes adicionais e entradas de serviço condicionais que o exemplo não contém.

systemd-resolved turva o teste

Em um sistema que usa systemd-resolved, o stub local também serve nomes da base de dados hosts. Por isso consultar 127.0.0.53 não é um teste independente do servidor remoto, embora pareça uma consulta DNS e se comporte como tal. Você pode confirmar o que o resolvedor sabe e quais servidores ele perguntaria com:

resolvectl query build.corp.example
resolvectl status

A saída de status nomeia os servidores DNS por link, e é assim que você descobre se o link da VPN recebeu algum resolvedor. Essa pergunta é separada da entrada hosts e é a que vale a pena fazer quando um nome privado falha para todos os usuários e não para um.

As aplicações podem adicionar outra camada. Um navegador com sua própria configuração de DNS-over-HTTPS, um contêiner com sua própria configuração de resolvedor ou um ambiente de execução que armazena consultas durante toda a vida do processo podem responder cada um de forma diferente do sistema. Teste a aplicação que lhe importa em vez de supor que um comando descreve todos os programas da máquina.

O que realmente compartilha um nome pela VPN

Se um nome privado precisa funcionar para todos, ele precisa de um proprietário que o resolvedor de todos consiga alcançar. A resposta limpa é publicar o registro em uma zona gerenciada e tornar essa zona resolvível pelo caminho DNS previsto da VPN. O registro passa a ter uma única fonte de verdade, uma trilha de auditoria e um ciclo de vida, e ninguém precisa lembrar qual laptop carrega uma substituição local.

Distribuir arquivos hosts é uma alternativa legítima, e é gestão de endpoints em vez de serviço de nomes. Se você escolher isso, o arquivo tem de ser implantado, versionado e removido por aquilo que gerencia o parque, e é assim que deve ser descrito no projeto. «A VPN cuida disso» não é uma descrição desse processo.

O registro dinâmico de DNS é um terceiro mecanismo, com suas próprias permissões, autenticação de atualizações e tempo de vida do registro. Ele não decorre de uma entrada hosts, e também não decorre de um cliente apenas se conectar, a menos que o servidor e o cliente tenham sido ambos configurados para isso. Um registro que aparece sozinho é sinal de que alguém habilitou atualizações seguras e um cliente que se registra sozinho, e essa configuração pertence ao registro de projeto e não a uma thread de solução de problemas. Se ninguém consegue dizer quem é o dono dessa configuração, trate o registro automático como não verificado e mantenha a zona gerenciada como fonte de verdade.

Um nome resolvido não é uma rota

Resolução de nomes e alcançabilidade são coisas separadas, e um mapeamento local desatualizado é a forma clássica de confundi-las. Uma entrada hosts que aponta para um endereço que mudou continuará selecionando o host obsoleto muito depois de o DNS ser corrigido, e o sintoma parece uma falha de roteamento em um nome que resolve bem.

Então, quando o relatório é «o nome resolve mas o serviço não é alcançável», compare a consulta do sistema com uma consulta explícita ao servidor DNS da VPN e depois verifique o endereço obtido contra o que o serviço realmente usa. A referência do systemd-resolved documenta as fontes locais que ele consulta, e esse é o mapa de que você precisa para essa comparação.

Depois corrija a substituição por meio do proprietário dela. Remover uma linha do seu próprio arquivo hosts não faz nada pelos doze laptops que receberam a mesma linha de um script de implantação, e essa é a versão deste problema que as pessoas realmente têm.