Los nombres internos cortos fallan en la VPN: el sufijo que nunca ves
Un nombre corto solo funciona porque un sufijo de búsqueda lo completa. Compare el nombre completo y el corto para separar una falta de sufijo de un fallo del resolutor.
El nombre corto funcionaba en la oficina y falla en la VPN, mientras que el nombre completo se resuelve sin problemas. No hay nada roto. Un nombre desnudo como intranet no es un nombre completo; el cliente añade un sufijo de su lista de búsqueda y pregunta por el resultado. Si el perfil de VPN no proporciona ese sufijo, la conocida forma corta deja de existir.
Ese es todo el mito. El DNS no se rompió, cambió la política de búsqueda.
Un nombre desnudo no es un nombre
Cuando escribe una sola etiqueta, el resolutor debe decidir qué preguntar. Prueba el nombre tal como se da y luego añade entradas de la lista de búsqueda una a una hasta que algo responde. En Linux, resolv.conf controla ese orden con los ajustes search y ndots. En Windows, la lista de sufijos y la política de resolución de nombres hacen lo equivalente. Quite el sufijo y el resolutor no tendrá nada que añadir.
Un nombre corto que funciona es, por tanto, prueba de una política, no prueba de un servidor DNS sano.
Qué hacen la lista de sufijos y la dirección del resolutor
Estas dos cosas se confunden constantemente. La dirección del resolutor dice a quién preguntar; la lista de sufijos dice sobre qué nombre preguntar. Una VPN puede darle un resolutor privado sin sufijo, o un sufijo con el resolutor equivocado. Solo uno de esos fallos parece una caída de DNS.
Compruébelos por separado, porque arreglar el equivocado consume una ventana 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.
Pruebe primero el nombre completo
Pida el nombre plenamente cualificado documentado por el administrador, no una suposición. Un FQDN que funciona demuestra que el resolutor es accesible y que el registro existe, lo que elimina la mitad de las causas posibles con una sola consulta. Use una herramienta que muestre qué servidor respondió, para no leer un resultado en caché.
Mantenga la prueba privada. Enviar variantes internas a un resolutor público revela nombres y prueba una política que nadie pretendía.
Dónde va la corrección
Corrija el perfil propietario o el sistema de gestión que lo genera. Una edición manual de la configuración local del resolutor suele desaparecer al reconectar, o se aplica a todas las redes a las que se une la máquina, lo cual es peor.
En Windows, inspeccione la política efectiva en lugar de la casilla que recuerda. Get-DnsClientNrptPolicy muestra las reglas de resolución de nombres que realmente están en vigor.
En macOS, scutil --dns imprime la configuración del resolutor por interfaz de ámbito, incluidos los dominios de búsqueda que la VPN entregó.
En Linux, lea la línea search en /etc/resolv.conf, pero compruebe si un cliente de VPN la ha reescrito. Si el archivo está gestionado, edite la fuente de verdad en lugar del archivo renderizado. Una línea search antigua heredada de una red anterior es una causa habitual.
Qué guardar junto al perfil
Guarde el nombre completo corregido, la lista de sufijos y la dirección del resolutor junto al perfil del cliente. La siguiente persona que informe de que el sitio intranet no funciona podrá comparar tres valores conocidos en lugar de empezar desde una página en blanco.
Y si solo falla la forma corta, dígalo en el ticket. Esa frase ahorra una tarde al equipo de resolutores.