Informe de DNS de la VPN: qué incluir para que se pueda reproducir

«El DNS está roto» es una conclusión, y no es una conclusión sobre la que alguien pueda actuar. La parte útil de un informe es la forma del fallo: qué nombre, a través de qué resolutor, con qué respuesta. Tres detalles convierten una queja en algo reproducible, y los tres se pueden compartir sin riesgo una vez que las partes privadas se han renombrado. Lo que sigue es el mínimo que necesita un informe de DNS de VPN antes de que nadie pueda ayudar.

Una categoría de nombre, no un veredicto

Empiece por el nombre mismo y clasifíquelo: público, interno, corto, totalmente cualificado o servido por un sufijo concreto. Un nombre interno que falla mientras los nombres públicos se resuelven apunta a la selección de resolutor y no a la accesibilidad. Si fallan todos los nombres, apunta a la ruta hacia el resolutor, que es otra investigación con otras pruebas. La categoría lleva el diagnóstico, y la cadena exacta se puede ocultar.

Diga si el fallo necesita que el túnel esté levantado o si ocurre después de desconectarse. Un nombre que solo se rompe mientras la VPN está activa implica la configuración por enlace, mientras que uno que se rompe tras desconectar implica un estado residual. Los informes suelen omitirlo y luego se preguntan por qué no ayuda la primera sugerencia.

Registre la ruta del resolutor

Una consulta enviada a un servidor elegido explícitamente y la búsqueda ordinaria de una aplicación son experimentos distintos. Diga cuál de los dos produjo el fallo, porque una consulta manual a un servidor que funciona solo demuestra que el servidor funciona. Los comandos siguientes separan la ruta del sistema de una pregunta directa.

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

La salida de estado nombra los servidores por enlace y los dominios de enrutamiento, que es donde se decide el split DNS. La llamada a getent sigue la misma ruta que la aplicación, incluido el orden de nsswitch. La consulta directa evita ambas y prueba un solo servidor de forma aislada. Informe de cuál de los tres falló y cuál funcionó, y el lector ya no tiene que adivinar la ruta.

Indique la comparación controlada

Cambie una variable y diga qué cambió. Que los nombres públicos se resuelvan mientras los internos fallan es un problema de selección; que todos los nombres agoten el tiempo es un problema de ruta; y un nombre privado que se resuelve a una dirección pública es una fuga hacia el resolutor equivocado. Dos de esas tres cosas no tienen nada que ver con si el túnel está levantado. Un informe que afirma que todas las consultas están rotas suele contener una comparación que nunca se ejecutó.

Separe la resolución de la entrega. Cuando el nombre se resuelve y el sitio sigue fallando, la etapa de DNS tuvo éxito y el informe debería decirlo, porque el siguiente paso es una ruta o un oyente y no un resolutor. Esa única distinción ahorra una ronda de preguntas más a menudo que cualquier extracto de registro.

Oculte el espacio de nombres, conserve las relaciones

Los nombres internos se pueden sustituir siempre que las sustituciones preserven la estructura. Asigne cada servidor y sufijo distinto a una etiqueta estable, y mantenga esa asignación fuera de la copia compartida. Sustituir cada host interno por el mismo marcador destruye justo la prueba que el informe necesita, porque el lector ya no puede ver que un sufijo se resolvió y otro no. La misma regla se aplica a las direcciones: conserve las relaciones de prefijo y cambie los bits de host si la política lo exige.

Envíe el registro por el canal verificado y deje fuera lo que el diagnóstico nunca necesita. Las contraseñas, las claves privadas y los nombres de empresas no relacionadas no forman parte de una pregunta de DNS. Lo que el lector necesita es la categoría del fallo, la ruta del resolutor, el error exacto y la única comparación que realizó.