Dúas persoas diagnostican o mesmo problema de Split-DNS e obteñen enderezos de resolutor distintos. Unha usou unha ferramenta de consulta, outra capturou paquetes no adaptador e unha terceira leu os diagnósticos do propio cliente. Ningunha mente e ningunha describe a mesma etapa. Nomear o punto de observación converte unha contradición nun mapa.

Unha consulta, varios puntos de observación

Para un só nome interno hai polo menos cinco lugares onde mirar: a aplicación e a API de resolutor que chama, a política de dominio efectiva no cliente, unha captura no adaptador ou no filtro, un límite de pasarela controlado e o resolutor que recibe realmente a consulta.

Cada un responde a unha pregunta distinta, e ningún por si só demostra onde foi a consulta.

Unha captura no adaptador mostra paquetes, non intención. Non di que resolutor escolleu o cliente, e unha captura baleira pode significar unha resposta na caché ou outra API de resolutor en lugar dun paquete descartado. Trate cada observación como proba dunha etapa. Despois ensamble as etapas nun camiño.

O filtro do cliente sitúase entre a aplicación e o cable

Un cliente VPN con Split-DNS aplica a coincidencia de dominios antes de que o paquete saia da máquina. Os nomes do sufixo tunelizado van ao resolutor interno; todo o demais vai ao local. O filtro é política, e a política pode variar segundo a plataforma e a versión do cliente.

A guía de Split-DNS de Secure Client de Cisco cobre a coincidencia de dominios e o filtro de Windows, e separa o que ve unha aplicación cando usa a API de resolutor nativa do que ve unha ferramenta como nslookup. Esas distincións son o punto.

Comece polo perfil efectivo e unha consulta normal da aplicación. Calquera proba que nomee un servidor explícito é un desvío deliberado; use os diagnósticos do propio cliente para explicalo e non deixe que se converta no criterio de aceptación.

nslookup segue un camiño distinto ao da aplicación

nslookup constrúe a súa propia consulta DNS e pode saltar a política de resolutor do sistema operativo. Iso fai del unha ferramenta útil para facer unha pregunta concreta a un servidor concreto, e unha ferramenta enganosa para probar o que experimentará unha aplicación.

En Windows, a táboa de política de resolución de nomes decide que sufixo usa que servidor. Lela mostra a política que seguirá a aplicación, que a miúdo é a peza que falta.

Lea a política e despois faga a mesma pregunta polo resolutor normal:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Os resolutores cifrados ocultan a consulta, non a conexión

Un navegador co seu propio resolutor DNS-over-HTTPS é un caso completamente distinto. A consulta sae dentro de TLS, así que unha captura de paquetes mostra unha conexión a un enderezo de resolutor pero non o nome que se pregunta.

Averigüe primeiro a política xestionada do navegador e despois compárea cunha consulta do sistema operativo. Pode que un navegador autorizado a escolle-lo seu propio resolutor nunca vexa a política de Split-DNS.

A mesma precaución se aplica a calquera cliente que inclúa o seu propio resolutor. Unha captura que identifica a conexión remota non é proba sobre o nome da consulta. Se necesita o nome, tómelo dos rexistros do propio resolutor ou dos diagnósticos da aplicación, coas regras de privacidade que correspondan.

Compare cunha proba etiquetada

Escolla un nome interno aprobado para a proba, ademais dun nome público que non teña ningún significado sensible. Para cada un, rexistre a hora, o tipo de rexistro, a resposta e a política que esperaba.

Onde se permita, compare a recepción do resolutor cunha observación estreita do cliente ou da pasarela:

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

Nunca envíe nomes privados a resolutores públicos non relacionados só para crear unha comparación, e redacte todo o que comparta. Por último, separe unha resposta DNS correcta da conexión ao servizo que segue: o enderezo privado resolto aínda necesita unha ruta e unha autorización da aplicación.

Artigos relacionados