Nomes internos curtos falham na VPN: o sufixo que você nunca vê
Um nome curto só funciona porque um sufixo de pesquisa o completa. Compare o nome completo e o curto para separar uma falha de sufixo de uma falha do resolvedor.
O nome curto funcionava no escritório e falha na VPN, enquanto o nome completo é resolvido sem problemas. Nada está quebrado. Um nome nu como intranet não é um nome completo; o cliente acrescenta um sufixo da sua lista de pesquisa e pergunta pelo resultado. Se o perfil de VPN não fornecer esse sufixo, a forma curta familiar deixa de existir.
É todo o mito. O DNS não quebrou, a política de pesquisa mudou.
Um nome nu não é um nome
Quando você digita um único rótulo, o resolvedor precisa decidir o que perguntar. Ele tenta o nome tal como dado e depois acrescenta entradas da lista de pesquisa uma a uma até algo responder. No Linux, o resolv.conf controla essa ordem com as definições search e ndots. No Windows, a lista de sufixos e a política de resolução de nomes fazem o equivalente. Retire o sufixo e o resolvedor não terá nada a acrescentar.
Um nome curto que funciona é, portanto, prova de uma política, não prova de um servidor DNS saudável.
O que fazem a lista de sufixos e o endereço do resolvedor
Esses dois são confundidos constantemente. O endereço do resolvedor diz a quem perguntar; a lista de sufixos diz sobre qual nome perguntar. Uma VPN pode dar um resolvedor privado sem sufixo, ou um sufixo com o resolvedor errado. Apenas uma dessas falhas parece uma queda de DNS.
Verifique-os separadamente, porque corrigir o errado consome uma janela de suporte.
| What you see | Likely cause |
|---|---|
| Full name resolves, short name fails | Suffix or search list missing |
| Neither resolves | Resolver unreachable or wrong domain rule |
| Both resolve, resource fails | Route or service permission |
Três sintomas, três responsáveis diferentes.
Teste o nome completo primeiro
Peça o nome totalmente qualificado documentado pelo administrador, não um palpite. Um FQDN que funciona prova que o resolvedor está acessível e que o registro existe, o que elimina metade das causas possíveis com uma única consulta. Use uma ferramenta que mostre qual servidor respondeu, para não ler um resultado em cache.
Mantenha o teste privado. Enviar variantes internas a um resolvedor público revela nomes e testa uma política que ninguém pretendia.
Onde fica a correção
Corrija o perfil proprietário ou o sistema de gestão que o gera. Uma edição manual na configuração local do resolvedor costuma desaparecer na reconexão, ou aplicar-se a todas as redes a que a máquina se junta, o que é pior.
No Windows, inspecione a política efetiva em vez da caixa que você lembra. Get-DnsClientNrptPolicy mostra as regras de resolução de nomes que realmente estão em vigor.
No macOS, scutil --dns imprime a configuração do resolvedor por interface com escopo, incluindo os domínios de pesquisa que a VPN empurrou.
No Linux, leia a linha search em /etc/resolv.conf, mas verifique se um cliente VPN a reescreveu. Se o arquivo for gerenciado, edite a fonte da verdade em vez do arquivo renderizado. Uma linha search antiga deixada por uma rede anterior é uma causa comum.
O que guardar junto ao perfil
Guarde o nome completo corrigido, a lista de sufixos e o endereço do resolvedor ao lado do perfil do cliente. A próxima pessoa que relatar que o site intranet está fora do ar poderá comparar três valores conhecidos em vez de começar de uma página em branco.
E se apenas a forma curta falhar, diga isso no ticket. Essa frase poupa uma tarde à equipe de resolvedores.