Ar arranxou a VPN o DNS ou só reutilizou unha resposta na caché?

Abrir unha páxina segundos despois de que o túnel se levante non demostra que o DNS xa funcione, aínda que o ticket adoita dicilo. Nada nesa observación esixía unha consulta: o nome puido resolverse antes do cambio e reutilizarse desde unha caché que o túnel nunca tocou. Dúas probas distintas producen a mesma pantalla.

Compare que exerceu realmente cada proba antes de atribuír o mérito ao cambio.

Cargar unha páxina non é unha consulta

Cada capa entre a aplicación e o resolvedor pode recordar unha resposta durante a súa vida útil. O sistema operativo garda unha, o navegador garda a súa, e unha aplicación cunha conexión de longa duración pode non volver resolver nada durante a sesión. Unha carga que ten éxito tras un cambio de túnel pode ser, por tanto, unha demostración de memoria e non de enrutamento. A ausencia dun fallo non é a presenza dunha consulta.

Esa distinción cambia o que debería probar a continuación. Se o obxectivo é demostrar que o novo resolvedor responde, necesita unha consulta que non poida servirse desde unha caché que non baleirou.

Ler un éxito na caché como proba de que un servidor antes inalcanzable se recuperou é a versión máis cara deste erro, porque pecha o incidente sobre unha premisa falsa.

Conte as cachés antes de concluír

Catro merecen nome: a resolución propia da aplicación, a caché de cliente do sistema operativo, o estado interno do navegador e o resolvedor recursivo que a consulta acaba alcanzando. Cada unha ten unha vida útil separada e unha forma separada de baleirarse. Baleirar unha e probar outra é como a xente conclúe que o baleirado non fixo nada. Unha orde de baleirado nunca resolve a cuestión.

As respostas negativas tamén se almacenan na caché. Un nome que se informou como ausente pode seguir ausente despois de corrixir a rede, o que se le como un túnel roto cando é un TTL que non caducou. A especificación DNS describe como se deben conservar e reutilizar estes datos.

Rexiste o evento, non a impresión

Anote cal das tres cousas cambiou: o rexistro, o camiño ata o resolvedor ou un axuste do cliente. A edición dun rexistro propágase segundo o seu propio calendario, un cambio de ruta surte efecto ao reconectar, e un axuste do navegador só se aplica a ese navegador. Colapsalas nun único antes e despois produce unha cronoloxía que ninguén pode auditar.

Anote a hora, o resolvedor en uso e a resposta recibida, incluído o caso en que a resposta sexa negativa. Iso é un feito que outra persoa pode comprobar.

Faga a comparación dúas veces da mesma maneira

Baleire a caché que pretende probar, conserve a observación orixinal e despois consulte dunha forma que evite tanta memoria como sexa posible. Nomear o resolvedor explicitamente dille que sabe ese resolvedor; non lle di que resolvedor tería elixido a aplicación.

resolvectl flush-caches
ipconfig /flushdns
dig +noall +answer internal.example @10.44.0.53
dig +short internal.example

En Windows, o baleirado da caché de cliente borra a caché de cliente DNS e nada máis. Non describe o estado privado dun navegador nin baleira un servidor ascendente, así que unha proba baseada nel só se pode interpretar de forma estreita. Diga que caché baleirou sempre que informe do resultado.

Despois, volva probar a aplicación real cunha solicitude nova e a política de resolvedor prevista activa. Un resultado producido cunha política distinta non se transfire.