DNS da VPN incorrecto? Un servidor autoritativo pode estar obsoleto

Conecta a VPN e un nome de host resólvese no enderezo de onte, ou en nada. Desconecta e volve funcionar. O reflexo é culpar o resolutor que impuxo o túnel, pero a causa máis común é un servidor de nomes publicado que deixou de recibir actualizacións da zona. A ruta nova simplemente chegou a outra autoridade distinta da que orixinou a resposta que tiñas na caché.

O síntoma cambia co resolutor

Un resolutor recursivo devolve o que lle dixo unha autoridade e despois conserva esa resposta durante o TTL. Se o túnel impón outro resolutor, ou cambia a ruta de xeito que o antigo xa non sexa alcanzable, o cliente pregunta a outra autoridade e obtén outra resposta. O dominio non cambiou nese momento; a túa visión del si.

Por iso o mesmo nome pode funcionar nunha oficina e fallar desde un hotel, e por iso baleirar a caché local só axuda ás veces. Baleirar a caché envía a pregunta outra vez á mesma autoridade.

A proba que os distingue é unha consulta directa a cada servidor publicado.

Consulta cada autoridade directamente

Comeza pola delegación e non por unha lista que recordes. Pregunta ao pai polo conxunto NS e despois consulta cada nome dese conxunto para o rexistro que che interesa. Dúas consultas do mesmo nome en autoridades distintas dinche de inmediato se a zona é coherente.

dig +short NS example.com
dig @ns1.dns.example app.example.com A
dig @ns2.dns.example app.example.com A

Fai o mesmo cos rexistros NS do ápice da zona, porque a delegación do pai e o conxunto NS propio da zona poden discrepar tras unha migración. Os números de serie do SOA son o seguinte que hai que comparar, e un secundario moi atrasado é un problema de transferencia, non de resposta.

Executa esas consultas desde a rede que falla, non só desde o teu escritorio.

Separa as vistas previstas das rotas

Algúns dominios responden a propósito de forma distinta segundo a rexión ou o grupo de resolutores, e as configuracións de horizonte dividido son normais en redes empresariais.

A cuestión é se a diferenza está documentada e é estable. Unha vista non prevista vese distinta: unha autoridade ten un rexistro que as demais nunca recibiron, ou fáltalle un que todas comparten. A guía RFC 2182 de selección e despregamento trata a dispoñibilidade autoritativa como unha responsabilidade compartida, e ese é o marco correcto aquí. A redundancia só existe se cada servidor publicado pode responder cos datos previstos, non só aceptar unha conexión no porto 53.

Un servidor que responde SERVFAIL é máis fácil de diagnosticar que un que responde con seguridade e de forma errónea.

Unha migración expón o que unha caché ocultaba

Durante un cambio de provedor cambian dúas localizacións autoritativas: a delegación do pai e os rexistros NS propios da zona. As dúas hai que actualizalas, e as dúas gárdanse en caché durante os seus TTL. Se un servidor antigo segue en pé e segue servindo a zona anterior, os clientes cuxos resolutores lle preguntan seguirán recibindo a resposta antiga moito despois de que a migración parecese completa.

Ese é exactamente o estado que oculta unha caché de longa duración. A estación de traballo que funcionou toda a semana falaba cun resolutor que tiña unha resposta fresca da nova autoridade, mentres o vello seguía repartindo datos obsoletos a todos os demais.

Cambiar o resolutor nun portátil arranxa ese portátil e nada máis.

Arranxa a zona, non o resolutor

Identifica que servidores deben ser autoritativos para a zona, corrixe a zona xestionada ou a delegación para que cada un deles sirva os datos previstos, e mantén a redundancia que planificaches. Borrar un servidor de nomes porque unha saída VPN recibiu unha resposta estraña reduce a dispoñibilidade e deixa a incoherencia no seu sitio.

Despois volve executar as consultas directas desde as dúas redes e espera a que caduque o TTL do rexistro que cambiaste.

Confirma que a resposta é estable desde cada autoridade, e escribe a vista prevista na documentación da zona para que a próxima diferenza sexa doada de clasificar.