Probar DNS dividido sen filtrar nomes internos

Consultar un nome interno nun resolutor público filtra o nome e salta a regra que querías probar. A consulta chega a un servidor que non controlas, a resposta vén dun espazo de nomes que non debería telo visto e o resultado non di nada sobre se o DNS dividido funciona. Probar DNS dividido significa probar a ruta do resolutor que unha aplicación usa de verdade. Esa ruta escóllena o sistema operativo, a lista de dominios do perfil de VPN e, ás veces, o navegador.

Escolle dous nomes e predí primeiro as dúas respostas

Pide ao responsable da rede un nome de proba interno documentado e escolle un nome público corrente que non diga nada sobre a organización. Anota que debería ocorrer con cada un antes de executar nada: o nome interno debería chegar ao resolutor do túnel e devolver un enderezo interno, mentres que o nome público debería resolverse a través do resolutor que o sistema usa normalmente. Esas dúas predicións son a proba, porque sen elas calquera resposta se pode xustificar despois. Mantén a parella fixa entre execucións para que unha comparación posterior signifique algo.

Comproba as regras efectivas, non as previstas. A lista de dominios asociada á conexión VPN decide que sufixos van a cada resolutor, e un erro tipográfico nesa lista produce unha división verosímil pero incorrecta. Nun dispositivo xestionado, usa a ruta de diagnóstico do administrador, xa que as anulacións locais poden restablecerse por política na seguinte comprobación.

Anota a predición xunto á resposta observada no mesmo tícket. Unha proba sen predición non pode fallar, e unha proba que non pode fallar non ensina nada.

Proba a ruta que usa a aplicación, non un servidor que escolleses

Un comando que nomea un resolutor explicitamente proba ese resolutor e nada máis. Diche se o servidor interno responde, o cal é útil, e non che di se unha aplicación envía alí o nome. Proba primeiro pola ruta normal: resolve o nome interno como o faría unha aplicación e despois resolve o nome público da mesma forma. Só despois consulta servidores concretos para atopar onde diverxe o comportamento.

Os navegadores complican o panorama, porque os axustes de DNS seguro poden saltar por completo o resolutor do sistema. Un navegador configurado co seu propio resolutor cifrado nunca ve a división, e o fallo parece un perfil de VPN roto. Comproba ese axuste antes de cambiar o túnel.

Repite a consulta tras reconectar se a cuestión é a restauración. Unha resposta na caché de antes da reconexión pode facer que unha división restaurada correctamente pareza mellor ou peor do que é.

Rexistra a categoría da resposta, non só o éxito ou o fallo

Anota cal de catro cousas ocorreu: un enderezo interno, un enderezo público, unha resposta negativa ou un tempo de espera esgotado. Cada unha ten un significado distinto. Un enderezo interno para o nome interno é o éxito esperado; un enderezo público para un nome interno suxire que a consulta saíu do túnel; unha resposta negativa do servidor autoritativo apunta a un rexistro ausente en lugar de a un fallo de encamiñamento; e un tempo de espera esgotado indica problemas de accesibilidade ou un resolutor que nunca recibiu a consulta. Éxito e fallo son demasiado grosos para actuar sobre eles.

Ten en conta a caché antes de interpretar unha consulta nova ausente, porque unha resposta negativa gardada na caché parece idéntica a un nome que non existe. Captura a resposta antes de borrar nada con controis admitidos, xa que a primeira resposta é a proba.

Interpreta as dúas ramas sen adiviñar

Se o nome interno se resolve correctamente e a aplicación segue fallando, o resolutor fixo o seu traballo e os seguintes sospeitosos son as rutas e os permisos do propio recurso. Se o nome privado chegou a un resolutor público, a regra de división non se aplica a esa consulta, así que revisa a lista de dominios e calquera política do navegador co propietario do espazo de nomes. Esas dúas ramas teñen propietarios distintos, e por iso rexistrar cal viches importa máis que rexistrar que algo se rompeu.

Oculta os datos sensibles da saída compartida mantendo a estrutura: que espazo de nomes, que regra, que categoría de resposta. A resposta dun resolutor pode levar enderezos internos e nomes de host, e un tícket é un fogar duradeiro para ambos.

Despois entrega o resultado ao propietario do espazo de nomes coas dúas categorías que observaches e os nomes eliminados. É unha conversa de cinco minutos en lugar dunha semana de especulación.