O DNS da VPN funciona, mas os nomes .local ainda falham: quem os resolve?

Duas máquinas na mesma VPN, o mesmo nome de host, e apenas uma delas o resolve: a diferença normalmente não é o túnel, mas qual resolutor respondeu. Num desktop Linux esse nome pode passar pelo comutador de serviços de nomes, pelo stub do systemd-resolved ou por um resolutor que a aplicação trouxe consigo, e cada um deles aplica a sua própria regra ao mesmo sufixo. É no sufixo que as regras divergem, porque .local não é um rótulo neutro. Descubra qual caminho o programa que falha realmente segue antes de mudar a ordem em que algo é executado.

Dois resolutores, duas respostas diferentes

Uma pesquisa tradicional do glibc percorre a linha hosts: em nsswitch.conf e pergunta a cada módulo por sua vez até um responder. Um cliente que fala com o systemd-resolved através do stub listener pergunta, em vez disso, a um único processo, e esse processo aplica política por enlace mais os seus próprios casos especiais. Uma aplicação que traz o seu próprio resolutor, ou que liga uma biblioteca que o faz, pode contornar ambos. Um nome de host pode, portanto, ter três donos numa mesma máquina, e só um deles sabe o que a VPN pretendia.

Identifique o dono antes de mudar qualquer coisa, porque a correção é diferente para cada um dos três. Um navegador e uma ferramenta de linha de comandos no mesmo desktop podem legitimamente discordar, e essa discordância é a pista, não o erro. Se o navegador resolve o nome e a ferramenta não, está a depurar um caminho de resolutor e não uma rota da VPN. Confirme a rota em separado, para que uma falha de encaminhamento não seja confundida com uma falha do serviço de nomes. Quando ambos concordam, a falha está acima do host e a configuração do resolutor aqui não vale outra edição.

Que comando perguntou realmente ao seu resolutor

Dois comandos só de leitura respondem a perguntas relacionadas, e compará-los localiza o problema mais depressa do que ler a configuração. Use um nome interno real e mantenha a saída privada, porque os registos internos continuam internos. Execute ambos na mesma sessão em que corre o programa que falha:

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

O primeiro pergunta através dos módulos configurados, que é o que um programa típico experimenta. O segundo pergunta diretamente ao systemd-resolved e relata o enlace, o protocolo e o servidor que respondeu. Consultar o servidor corporativo por endereço prova apenas que o servidor detém o registo, porque não diz nada sobre se a aplicação alguma vez lhe perguntou. Leia o enlace que transporta a VPN e os domínios que declara, e depois compare essa lista com o sufixo no nome que falha.

Por que .local ignora a sua zona unicast

a referência do systemd-resolved afirma que nomes com várias etiquetas que terminam em .local vão normalmente para DNS multicast quando o mDNS está ativado, em vez de irem para o DNS unicast comum. O RFC 6762 reserva esse espaço de nomes para multicast de enlace local, por isso uma zona corporativa pode ter um registo correto que nunca é consultado para esse sufixo. O túnel pode encaminhar o resolutor na perfeição e ainda assim perder a corrida. Um ping bem-sucedido a partir da cache não diz nada sobre a pesquisa que acabou de acontecer.

Há uma exceção documentada, e resolve a maioria destes casos: quando um enlace declara esse sufixo como domínio de pesquisa ou domínio de encaminhamento, o daemon mantém-no no caminho unicast e salta o caso especial de multicast. Isso é política por enlace e não uma preferência global. Duas máquinas com o mesmo servidor VPN podem comportar-se de forma diferente quando um perfil de rede declara o domínio e o outro não, por isso leia o perfil ativo e não o que recorda ter editado.

A exceção estreita vence uma reordenação global

Para uma zona existente que não pode renomear, faça com que os donos do resolutor e da VPN declarem o domínio na ligação que o transporta. Uma entrada de domínio de encaminhamento para esse único sufixo mais o endereço de servidor previsto é uma alteração pequena com um dono nomeado, e vive com o enlace em vez de num ficheiro editado à mão.

Também sobrevive a uma desconexão, porque a política do enlace é reaplicada quando o enlace regressa. Editar o nsswitch.conf partilhado é a alternativa tentadora e a mais dispendiosa, porque altera o comportamento de pesquisa para cada nome da máquina, incluindo a descoberta local. Desativar o daemon multicast também não é equivalente: remove o comportamento local sem ensinar a zona corporativa a nenhum resolutor. Se o serviço é novo e não herdado, coloque-o sob um subdomínio controlado pela sua organização e salte a competição por completo. Escolha a exceção estreita quando o nome está fixo no firmware ou impresso numa etiqueta, e escolha um subdomínio novo quando ainda controla o cliente.

O que demonstrar depois da alteração

Demonstre a correção com a pesquisa própria da aplicação e não com uma ferramenta que instalou para testar, e limpe qualquer cache que possa responder no seu lugar. Depois confirme o caminho do resolutor e o enlace que serviu a resposta. Por fim verifique que a descoberta local se comporta como antes da alteração, porque a impressora que deixa de aparecer é a parte que as pessoas notam por último. Estes três comandos verificam o nome, o caminho e a identidade TLS nessa ordem:

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

Um endereço correto com o certificado errado continua a fazer falhar um cliente estrito, por isso verifique o nome que a aplicação espera quando a resolução funcionar. Confirme que o serviço aceita ligações a partir do endereço da VPN e não apenas do intervalo do escritório. Escreva o âmbito do domínio, o servidor e o dono na documentação da ligação. Caso contrário, a próxima pessoa que encontrar esta falha recorrerá à mesma edição global que você acabou de evitar.