Informe de DNS da VPN: que incluír para que se poida reproducir

«O DNS está roto» é unha conclusión, e non é unha conclusión sobre a que alguén poida actuar. A parte útil dun informe é a forma do fallo: que nome, a través de que resolutor, con que resposta. Tres detalles converten unha queixa en algo reproducible, e os tres se poden compartir sen risco unha vez que as partes privadas se renomearon. O que segue é o mínimo que necesita un informe de DNS de VPN antes de que ninguén poida axudar.

Unha categoría de nome, non un veredicto

Comece polo nome mesmo e clasifíqueo: público, interno, curto, totalmente cualificado ou servido por un sufixo concreto. Un nome interno que falla mentres os nomes públicos se resolven apunta á selección de resolutor e non á accesibilidade. Se fallan todos os nomes, apunta á ruta cara ao resolutor, que é outra investigación con outras probas. A categoría leva o diagnóstico, e a cadea exacta pódese ocultar.

Diga se o fallo necesita que o túnel estea levantado ou se ocorre despois de desconectarse. Un nome que só se rompe mentres a VPN está activa implica a configuración por ligazón, mentres que un que se rompe tras desconectar implica un estado residual. Os informes adoitan omitilo e logo pregúntanse por que non axuda a primeira suxerencia.

Rexistre a ruta do resolutor

Unha consulta enviada a un servidor elixido explicitamente e a busca ordinaria dunha aplicación son experimentos distintos. Diga cal dos dous produciu o fallo, porque unha consulta manual a un servidor que funciona só demostra que o servidor funciona. Os comandos seguintes separan a ruta do sistema dunha pregunta directa.

resolvectl status --no-pager
getent hosts host.internal
dig +short host.internal @10.20.30.53

A saída de estado nomea os servidores por ligazón e os dominios de enrutamento, que é onde se decide o split DNS. A chamada a getent segue a mesma ruta que a aplicación, incluída a orde de nsswitch. A consulta directa evita ambas e proba un só servidor de forma illada. Informe de cal dos tres fallou e cal funcionou, e o lector xa non ten que adiviñar a ruta.

Indique a comparación controlada

Cambie unha variable e diga que cambiou. Que os nomes públicos se resolvan mentres os internos fallan é un problema de selección; que todos os nomes esgoten o tempo é un problema de ruta; e un nome privado que se resolve a un enderezo público é unha fuga cara ao resolutor incorrecto. Dúas desas tres cousas non teñen nada que ver con se o túnel está levantado. Un informe que afirma que todas as consultas están rotas adoita conter unha comparación que nunca se executou.

Separe a resolución da entrega. Cando o nome se resolve e o sitio segue fallando, a etapa de DNS tivo éxito e o informe debería dicilo, porque o seguinte paso é unha ruta ou un oínte e non un resolutor. Esa única distinción aforra unha rolda de preguntas máis a miúdo que calquera extracto de rexistro.

Oculte o espazo de nomes, conserve as relacións

Os nomes internos pódense substituír sempre que as substitucións preserven a estrutura. Asigne cada servidor e sufixo distinto a unha etiqueta estable, e manteña esa asignación fóra da copia compartida. Substituír cada host interno polo mesmo marcador destrúe xustamente a proba que o informe necesita, porque o lector xa non pode ver que un sufixo se resolveu e outro non. A mesma regra aplícase aos enderezos: conserve as relacións de prefixo e cambie os bits de host se a política o esixe.

Envíe o rexistro pola canle verificada e deixe fóra o que o diagnóstico nunca necesita. Os contrasinais, as claves privadas e os nomes de empresas non relacionadas non forman parte dunha pregunta de DNS. O que o lector necesita é a categoría do fallo, a ruta do resolutor, o erro exacto e a única comparación que realizou.