Captura de Split-DNS: digueu on s’ha pres cada observació

Dues persones depuren el mateix problema de Split-DNS i obtenen adreces de resolució diferents. Una va fer servir una eina de consulta, una altra va capturar paquets a l’adaptador i una tercera va llegir el diagnòstic del propi client. Cap d’elles no menteix i cap no descriu la mateixa etapa. Anomenar el punt d’observació converteix una contradicció en un mapa.

Una consulta, diversos punts d’observació

Per a un sol nom intern hi ha almenys cinc llocs on mirar: l’aplicació i l’API de resolució que crida, la política de domini efectiva al client, una captura a l’adaptador o al filtre, un límit de passarel·la controlat i el resolutor que rep realment la consulta.

Cadascun respon una pregunta diferent i cap per si sol no demostra on ha anat la consulta.

Una captura a l’adaptador mostra paquets, no intenció. No diu quin resolutor ha triat el client, i una captura buida pot significar una resposta en memòria cau o una altra API de resolució en lloc d’un paquet descartat. Tracteu cada observació com a prova d’una etapa. Després munteu les etapes en un camí.

El filtre del client se situa entre l’aplicació i el cable

Un client VPN amb Split-DNS aplica la concordança de dominis abans que el paquet surti de la màquina. Els noms del sufix tunelitzat van al resolutor intern; tota la resta va al local. El filtre és política, i la política pot variar segons la plataforma i la versió del client.

La guia de Split-DNS de Secure Client de Cisco cobreix la concordança de dominis i el filtre de Windows, i separa què veu una aplicació quan fa servir l’API de resolució nativa del que veu una eina com nslookup. Aquestes distincions són el punt.

Comenceu pel perfil efectiu i una consulta normal de l’aplicació. Qualsevol prova que anomeni un servidor explícit és un desviament deliberat; feu servir el diagnòstic del propi client per explicar-lo i no deixeu que es converteixi en el criteri d’acceptació.

nslookup segueix un camí diferent del de l’aplicació

nslookup construeix la seva pròpia consulta DNS i pot saltar-se la política de resolució del sistema operatiu. Això el fa una eina útil per fer una pregunta concreta a un servidor concret, i una eina enganyosa per provar què experimentarà una aplicació.

A Windows, la taula de política de resolució de noms decideix quin sufix fa servir quin servidor. Llegir-la mostra la política que seguirà l’aplicació, que sovint és la peça que falta.

Llegiu la política i després feu la mateixa pregunta pel resolutor normal:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Els resolutors xifrats amaguen la consulta, no la connexió

Un navegador amb el seu propi resolutor DNS-over-HTTPS és un cas completament diferent. La consulta surt dins de TLS, així que una captura de paquets mostra una connexió a una adreça de resolutor però no el nom que es demana.

Esbrineu primer la política gestionada del navegador i compareu-la després amb una consulta del sistema operatiu. Pot ser que un navegador autoritzat a triar el seu propi resolutor no vegi mai la política de Split-DNS.

La mateixa precaució s’aplica a qualsevol client que inclogui el seu propi resolutor. Una captura que identifica la connexió remota no és prova sobre el nom de la consulta. Si us cal el nom, traieu-lo dels registres del propi resolutor o del diagnòstic de l’aplicació, amb les regles de privadesa que correspongui.

Compareu amb una prova etiquetada

Trieu un nom intern aprovat per a la prova, més un nom públic que no porti cap significat sensible. Per a cada un, registreu l’hora, el tipus de registre, la resposta i la política que esperàveu.

On es permeti, compareu la recepció del resolutor amb una observació estreta del client o de la passarel·la:

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

No envieu mai noms privats a resolutors públics no relacionats només per crear una comparació, i redacteu tot el que compartiu. Finalment, separeu una resposta DNS correcta de la connexió al servei que la segueix: l’adreça privada resolta encara necessita una ruta i una autorització de l’aplicació.