Informe de DNS de la VPN: què cal incloure perquè es pugui reproduir

«El DNS està trencat» és una conclusió, i no és una conclusió sobre la qual algú pugui actuar. La part útil d’un informe és la forma de la fallada: quin nom, a través de quin resolutor, amb quina resposta. Tres detalls converteixen una queixa en una cosa reproduïble, i tots tres es poden compartir sense risc un cop les parts privades s’han reetiquetat. El que segueix és el mínim que necessita un informe de DNS de VPN abans que ningú pugui ajudar.

Una categoria de nom, no un veredicte

Comenceu pel nom mateix i classifiqueu-lo: públic, intern, curt, completament qualificat o servit per un sufix concret. Un nom intern que falla mentre els noms públics es resolen apunta a la selecció de resolutor, no a l’abast. Si fallen tots els noms, apunta al camí fins al resolutor, que és una investigació diferent amb proves diferents. La categoria porta el diagnòstic, i la cadena exacta es pot amagar.

Digueu si la fallada necessita que el túnel estigui aixecat o si passa després que es desconnecti. Un nom que només es trenca mentre la VPN és activa implica la configuració per enllaç, mentre que un que es trenca després de desconnectar implica estat residual. Els informes normalment ho ometen i després es pregunten per què el primer suggeriment no ajuda.

Registreu el camí del resolutor

Una consulta enviada a un servidor triat explícitament i la cerca ordinària d’una aplicació són experiments diferents. Digueu quin dels dos ha produït la fallada, perquè una consulta manual a un servidor que funciona només demostra que el servidor funciona. Les ordres següents separen el camí del sistema d’una pregunta directa.

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

La sortida d’estat anomena els servidors per enllaç i els dominis d’encaminament, que és on es decideix el split DNS. La crida a getent segueix el mateix camí que l’aplicació, inclòs l’ordre de nsswitch. La consulta directa evita tots dos i prova un sol servidor aïlladament. Informeu de quin dels tres ha fallat i quin ha funcionat, i el lector ja no ha de endevinar el camí.

Indiqueu la comparació controlada

Canvieu una variable i digueu què ha canviat. Que els noms públics es resolguin mentre els interns fallen és un problema de selecció; que tots els noms expirin és un problema de camí; i un nom privat que es resol a una adreça pública és una fuita cap al resolutor equivocat. Dues d’aquestes tres coses no tenen res a veure amb si el túnel està aixecat. Un informe que afirma que totes les consultes estan trencades normalment conté una comparació que mai es va fer.

Separeu la resolució del lliurament. Quan el nom es resol i el lloc encara falla, l’etapa DNS ha tingut èxit i l’informe ho ha de dir, perquè el pas següent és una ruta o un oient, no un resolutor. Aquesta única distinció estalvia una ronda de preguntes més sovint que qualsevol fragment de registre.

Amagueu l’espai de noms, conserveu les relacions

Els noms interns es poden substituir sempre que les substitucions preservin l’estructura. Assigneu cada servidor i sufix diferent a una etiqueta estable, i manteniu aquesta assignació fora de la còpia compartida. Substituir cada host intern pel mateix marcador de posició destrueix exactament la prova que l’informe necessita, perquè el lector ja no pot veure que un sufix es va resoldre i un altre no. La mateixa regla s’aplica a les adreces: conserveu les relacions de prefix i canvieu els bits d’host si la política ho exigeix.

Envieu el registre pel canal verificat i deixeu fora el que el diagnòstic no necessita mai. Les contrasenyes, les claus privades i els noms d’empreses no relacionades no formen part d’una pregunta de DNS. El que el lector necessita és la categoria de la fallada, el camí del resolutor, l’error exacte i l’única comparació que heu fet.