NXDOMAIN a través dunha VPN non significa unha caída do túnel

É tentador ler unha consulta fallida como proba de que o túnel colapsou, sobre todo cando o nome funcionaba dez minutos antes. A resposta di outra cousa. NXDOMAIN é unha transacción DNS completada na que un resolutor declarou que o nome consultado non existe; un túnel roto adoita producir silencio, un tempo de espera esgotado ou un intento de resolución contra o servidor equivocado. A versión do argumento sen wireshark é unha consulta, un respondedor e un código de resposta, e esa terna merece quedar rexistrada antes de calquera cambio de configuración.

Que establece realmente a resposta

O DNS separa resultados que os clientes adoitan fundir nun único fallo. Un nome que non existe produce unha resposta negativa co código NXDOMAIN, mentres que un nome que existe pero non ten ningún rexistro do tipo solicitado produce unha resposta correcta cunha sección de respostas baleira. Ambos parecen nada útil para unha aplicación, e só un deles significa que o nome é incorrecto.

Esa diferenza decide onde corresponde a reparación. Un rexistro AAAA ausente nun host que ten un rexistro A non é un host ausente, e reemitir un certificado ou reconstruír un túnel para perseguilo desperdicia a única pista dispoñible. A distinción tamén fixa a forma do seguimento: un problema de nomes corríxese na zona, e un problema de tipo corríxese pedindo o rexistro correcto ou aceptando que a familia de enderezos simplemente non está.

O mito: un nome privado ausente significa que o túnel fallou

O mito sobrevive porque os dous sucesos chegan tan a miúdo xuntos. Un cliente conéctase á VPN, o sistema operativo conserva un resolutor no que xa confiaba, e o nome interno que agora necesita pregúntase a un servidor que nunca oíu falar da zona privada. Ese servidor responde con honestidade e de forma negativa. O túnel transporta o paquete; a resposta só trata dun espazo de nomes que o respondedor non serve.

As disposicións de horizonte dividido fan que isto sexa rutineiro: o mesmo nome de zona existe publicamente e de forma interna con contidos distintos, e só o resolutor interno coñece os rexistros privados. Obter unha resposta negativa que parece autoritativa é, por tanto, proba de que resolutor respondeu, non proba do estado da interface.

Dous detalles de configuración deciden o resultado. O túnel ten que empurrar ou seleccionar o resolutor interno, e o cliente ten que aplicar esa selección ao nome que se consulta. Unha regra por dominio que nomee un sufixo lixeiramente distinto do rexistro que vostede escribiu enviará a consulta pola ruta pública, e a resposta será correcta e inútil.

Pregunte ao resolutor correcto co nome correcto

Rexistre o respondedor antes de rexistrar o veredicto. Unha consulta que non mostra que servidor respondeu non pode distinguir un problema de política dun problema de espazo de nomes, e os dous teñen arranxos non relacionados.

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

As dúas primeiras liñas mostran que decidiu o resolutor local e a quen preguntaría. A consulta +search reproduce o que fai unha aplicación cando engade un sufixo de busca, que a miúdo é a consulta real e non a escrita nunha ferramenta de diagnóstico. A última liña pregunta directamente ao servidor interno, saltándose a política do cliente; se iso ten éxito mentres a consulta simple falla, a zona está ben e o encamiñamento das consultas non.

A caché negativa explica o atraso tras unha corrección

As respostas negativas gárdanse na caché por deseño, e RFC 2308 describe como se deriva a vida útil da caché negativa do rexistro de autoridade da zona. Por tanto, corrixir un rexistro ou unha regra de resolutor non garante un cambio inmediato no cliente, e reintentar unha consulta que segue devolvendo a resposta na caché non demostra nada novo. Só un respondedor distinto, un nome distinto ou unha caché baleirada producen probas frescas.

Baleire a caché local e logo repita a mesma consulta contra o mesmo respondedor. En sistemas que usan o servizo de resolutor local iso é unha orde; noutros é un reinicio do servizo ou unha utilidade da plataforma, e a ferramenta concreta importa menos que repetir despois unha proba idéntica.

Separe o nome da ruta

Unha vez que o nome resolve ao enderezo privado esperado, o DNS queda terminado como tema e a ruta da aplicación pasa a ser a seguinte pregunta. Un host que responde ás consultas pero rexeita unha conexión ten outro problema, e seguir axustando resolutores despois dunha resposta correcta é como un incidente adquire tres cambios non relacionados. Compare o enderezo resolto co que o servizo escoita realmente antes de supor que ambos coinciden.

Conserve a transcrición: a consulta, o respondedor, o código e o enderezo resolto. Ese rexistro é tamén o que fai verificable un informe posterior, e é a diferenza entre un diagnóstico e unha historia sobre un túnel que parecía lento.