Captura de Split-DNS: diga dónde se tomó cada observación

Dos personas diagnostican el mismo problema de Split-DNS y obtienen direcciones de resolutor distintas. Una usó una herramienta de consulta, otra capturó paquetes en el adaptador y una tercera leyó los diagnósticos del propio cliente. Ninguna miente y ninguna describe la misma etapa. Nombrar el punto de observación convierte una contradicción en un mapa.

Una consulta, varios puntos de observación

Para un solo nombre interno hay al menos cinco lugares donde mirar: la aplicación y la API de resolutor que llama, la política de dominio efectiva en el cliente, una captura en el adaptador o el filtro, un límite de puerta de enlace controlado y el resolutor que recibe realmente la consulta.

Cada uno responde a una pregunta distinta, y ninguno por sí solo demuestra adónde fue la consulta.

Una captura en el adaptador muestra paquetes, no intención. No dice qué resolutor eligió el cliente, y una captura vacía puede significar una respuesta en caché o otra API de resolutor en lugar de un paquete descartado. Trate cada observación como prueba de una etapa. Después ensamble las etapas en un camino.

El filtro del cliente se sitúa entre la aplicación y el cable

Un cliente VPN con Split-DNS aplica la coincidencia de dominios antes de que el paquete salga de la máquina. Los nombres del sufijo tunelizado van al resolutor interno; todo lo demás va al local. El filtro es política, y la política puede variar según la plataforma y la versión del cliente.

La guía de Split-DNS de Secure Client de Cisco cubre la coincidencia de dominios y el filtro de Windows, y separa lo que ve una aplicación cuando usa la API de resolutor nativa de lo que ve una herramienta como nslookup. Esas distinciones son el punto.

Empiece por el perfil efectivo y una consulta normal de la aplicación. Cualquier prueba que nombre un servidor explícito es un desvío deliberado; use los diagnósticos del propio cliente para explicarlo y no deje que se convierta en el criterio de aceptación.

nslookup sigue un camino distinto al de la aplicación

nslookup construye su propia consulta DNS y puede saltarse la política de resolutor del sistema operativo. Eso lo hace una herramienta útil para hacer una pregunta concreta a un servidor concreto, y una herramienta engañosa para probar lo que experimentará una aplicación.

En Windows, la tabla de política de resolución de nombres decide qué sufijo usa qué servidor. Leerla muestra la política que seguirá la aplicación, que a menudo es la pieza que falta.

Lea la política y después haga la misma pregunta por el resolutor normal:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Los resolutores cifrados ocultan la consulta, no la conexión

Un navegador con su propio resolutor DNS-over-HTTPS es un caso completamente distinto. La consulta sale dentro de TLS, así que una captura de paquetes muestra una conexión a una dirección de resolutor pero no el nombre que se pregunta.

Averigüe primero la política gestionada del navegador y luego compárela con una consulta del sistema operativo. Puede que un navegador autorizado a elegir su propio resolutor nunca vea la política de Split-DNS.

La misma precaución se aplica a cualquier cliente que incluya su propio resolutor. Una captura que identifica la conexión remota no es prueba sobre el nombre de la consulta. Si necesita el nombre, tómelo de los registros del propio resolutor o de los diagnósticos de la aplicación, con las reglas de privacidad que correspondan.

Compare con una prueba etiquetada

Elija un nombre interno aprobado para la prueba, además de un nombre público que no conlleve ningún significado sensible. Para cada uno, registre la hora, el tipo de registro, la respuesta y la política que esperaba.

Donde se permita, compare la recepción del resolutor con una observación estrecha del cliente o de la puerta de enlace:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

Nunca envíe nombres privados a resolutores públicos no relacionados solo para crear una comparación, y redacte todo lo que comparta. Por último, separe una respuesta DNS correcta de la conexión al servicio que sigue: la dirección privada resuelta todavía necesita una ruta y una autorización de la aplicación.