Os nomes internos curtos fallan na VPN: o sufixo que nunca ves
Un nome curto só funciona porque un sufixo de busca o completa. Compare o nome completo e o curto para separar unha falta de sufixo dun fallo do resolvedor.
O nome curto funcionaba na oficina e falla na VPN, mentres que o nome completo se resolve sen problemas. Non hai nada roto. Un nome espido como intranet non é un nome completo; o cliente engade un sufixo da súa lista de busca e pregunta polo resultado. Se o perfil de VPN non fornece ese sufixo, a coñecida forma curta deixa de existir.
Ese é todo o mito. O DNS non se rompeu, cambiou a política de busca.
Un nome espido non é un nome
Cando escribes unha soa etiqueta, o resolvedor ten que decidir que preguntar. Proba o nome tal como se dá e despois engade entradas da lista de busca unha a unha ata que algo responde. En Linux, resolv.conf controla esa orde cos axustes search e ndots. En Windows, a lista de sufixos e a política de resolución de nomes fan o equivalente. Quita o sufixo e o resolvedor non terá nada que engadir.
Un nome curto que funciona é, polo tanto, proba dunha política, non proba dun servidor DNS san.
Que fan a lista de sufixos e o enderezo do resolvedor
Estas dúas cousas confúndense constantemente. O enderezo do resolvedor di a quen preguntar; a lista de sufixos di sobre que nome preguntar. Unha VPN pode darlle un resolvedor privado sen sufixo, ou un sufixo co resolvedor equivocado. Só un deses fallos parece unha caída de DNS.
Compróbeos por separado, porque arranxar o equivocado consome unha xanela de soporte.
| 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 |
Tres síntomas, tres responsables distintos.
Probe primeiro o nome completo
Pida o nome plenamente cualificado documentado polo administrador, non unha suposición. Un FQDN que funciona demostra que o resolvedor é accesible e que o rexistro existe, o que elimina a metade das causas posibles cunha soa consulta. Use unha ferramenta que mostre que servidor respondeu, para non ler un resultado na caché.
Manteña a proba privada. Enviar variantes internas a un resolvedor público revela nomes e proba unha política que ninguén pretendía.
Onde vai a corrección
Corrixa o perfil propietario ou o sistema de xestión que o xera. Unha edición manual da configuración local do resolvedor normalmente desaparece ao reconectar, ou aplícase a todas as redes ás que se une a máquina, o que é peor.
En Windows, inspeccione a política efectiva en lugar da caixa que recorda. Get-DnsClientNrptPolicy mostra as regras de resolución de nomes que realmente están en vigor.
En macOS, scutil --dns imprime a configuración do resolvedor por interface de ámbito, incluídos os dominios de busca que empurrou a VPN.
En Linux, lea a liña search en /etc/resolv.conf, pero comprobe se un cliente de VPN a reescribiu. Se o ficheiro está xestionado, edite a fonte de verdade en lugar do ficheiro renderizado. Unha liña search antiga herdada dunha rede anterior é unha causa habitual.
Que gardar xunto ao perfil
Garde o nome completo corrixido, a lista de sufixos e o enderezo do resolvedor xunto ao perfil do cliente. A seguinte persoa que informe de que o sitio intranet non funciona poderá comparar tres valores coñecidos en lugar de comezar desde unha páxina en branco.
E se só falla a forma curta, dígao no ticket. Esa frase aforra unha tarde ao equipo de resolvedores.