Probar DNS dividido sin filtrar nombres internos

Consultar un nombre interno en un resolutor público filtra el nombre y se salta la regla que querías probar. La consulta llega a un servidor que no controlas, la respuesta viene de un espacio de nombres que no debería haberlo visto y el resultado no dice nada sobre si el DNS dividido funciona. Probar DNS dividido significa probar la ruta del resolutor que una aplicación usa de verdad. Esa ruta la elige el sistema operativo, la lista de dominios del perfil de VPN y, a veces, el navegador.

Elige dos nombres y predice primero las dos respuestas

Pide al responsable de la red un nombre de prueba interno documentado y elige un nombre público corriente que no diga nada sobre la organización. Anota qué debería ocurrir con cada uno antes de ejecutar nada: el nombre interno debería llegar al resolutor del túnel y devolver una dirección interna, mientras que el nombre público debería resolverse a través del resolutor que el sistema usa normalmente. Esas dos predicciones son la prueba, porque sin ellas cualquier respuesta se puede justificar después. Mantén la pareja fija entre ejecuciones para que una comparación posterior signifique algo.

Comprueba las reglas efectivas, no las previstas. La lista de dominios asociada a la conexión VPN decide qué sufijos van a cada resolutor, y una errata en esa lista produce una división verosímil pero incorrecta. En un dispositivo gestionado, usa la ruta de diagnóstico del administrador, ya que las anulaciones locales pueden restablecerse por política en la siguiente comprobación.

Anota la predicción junto a la respuesta observada en el mismo tique. Una prueba sin predicción no puede fallar, y una prueba que no puede fallar no enseña nada.

Prueba la ruta que usa la aplicación, no un servidor que hayas elegido

Un comando que nombra un resolutor explícitamente prueba ese resolutor y nada más. Te dice si el servidor interno responde, lo cual es útil, y no te dice si una aplicación envía allí el nombre. Prueba primero por la ruta normal: resuelve el nombre interno como lo haría una aplicación y después resuelve el nombre público de la misma forma. Solo después consulta servidores concretos para encontrar dónde diverge el comportamiento.

Los navegadores complican el panorama, porque los ajustes de DNS seguro pueden saltarse por completo el resolutor del sistema. Un navegador configurado con su propio resolutor cifrado nunca ve la división, y el fallo parece un perfil de VPN roto. Comprueba ese ajuste antes de cambiar el túnel.

Repite la consulta tras reconectar si la cuestión es la restauración. Una respuesta en caché de antes de la reconexión puede hacer que una división restaurada correctamente parezca mejor o peor de lo que es.

Registra la categoría de la respuesta, no solo el éxito o el fallo

Anota cuál de cuatro cosas ocurrió: una dirección interna, una dirección pública, una respuesta negativa o un tiempo de espera agotado. Cada una tiene un significado distinto. Una dirección interna para el nombre interno es el éxito esperado; una dirección pública para un nombre interno sugiere que la consulta salió del túnel; una respuesta negativa del servidor autoritativo apunta a un registro ausente en lugar de a un fallo de enrutamiento; y un tiempo de espera agotado indica problemas de accesibilidad o un resolutor que nunca recibió la consulta. Éxito y fallo son demasiado gruesos para actuar sobre ellos.

Ten en cuenta la caché antes de interpretar una consulta nueva ausente, porque una respuesta negativa guardada en caché parece idéntica a un nombre que no existe. Captura la respuesta antes de borrar nada con controles admitidos, ya que la primera respuesta es la prueba.

Interpreta las dos ramas sin adivinar

Si el nombre interno se resuelve correctamente y la aplicación sigue fallando, el resolutor hizo su trabajo y los siguientes sospechosos son las rutas y los permisos del propio recurso. Si el nombre privado llegó a un resolutor público, la regla de división no se aplica a esa consulta, así que revisa la lista de dominios y cualquier política del navegador con el propietario del espacio de nombres. Esas dos ramas tienen propietarios distintos, y por eso registrar cuál viste importa más que registrar que algo se rompió.

Oculta los datos sensibles de la salida compartida manteniendo la estructura: qué espacio de nombres, qué regla, qué categoría de respuesta. La respuesta de un resolutor puede llevar direcciones internas y nombres de host, y un tique es un hogar duradero para ambos.

Después entrega el resultado al propietario del espacio de nombres con las dos categorías que observaste y los nombres eliminados. Es una conversación de cinco minutos en lugar de una semana de especulación.