Ha arreglat el VPN el DNS, o només ha reutilitzat una resposta en memòria cau?

Obrir una pàgina segons després que el túnel s’aixequi no demostra que el DNS ja funcioni, tot i que el tiquet normalment ho diu. Res d’aquella observació no requeria una consulta: el nom pot haver-se resolt abans del canvi i reutilitzat d’una memòria cau que el túnel no va tocar. Dues proves diferents produeixen la mateixa pantalla.

Compareu què va exercitar realment cada prova abans d’atribuir el mèrit al canvi.

Carregar una pàgina no és fer una consulta

Cada capa entre l’aplicació i el resoledor pot recordar una resposta durant la seva vida útil. El sistema operatiu en guarda una, el navegador guarda la seva, i una aplicació amb una connexió de llarga durada pot no resoldre mai res més durant la sessió. Una càrrega que té èxit després d’un canvi de túnel pot ser, per tant, una demostració de memòria i no d’encaminament. L’absència d’una fallada no és la presència d’una consulta.

Aquesta distinció canvia què heu de provar a continuació. Si l’objectiu és demostrar que el nou resoledor respon, necessiteu una consulta que no es pugui servir des d’una memòria cau que no hàgiu buidat.

Llegir un èxit en memòria cau com a prova que un servidor abans inaccessible s’ha recuperat és la versió més cara d’aquest error, perquè tanca l’incident amb una premissa falsa.

Compteu les memòries cau abans de concloure

N’hi ha quatre que val la pena nomenar: la resolució pròpia de l’aplicació, la memòria cau del client del sistema operatiu, l’estat intern del navegador i el resoledor recursiu que la consulta acaba assolint. Cadascuna té una vida útil separada i una manera separada de buidar-se. Buidar-ne una i provar-ne una altra és com la gent conclou que el buidatge no va fer res. Una ordre de buidatge mai no resol la qüestió.

Les respostes negatives també es guarden a la memòria cau. Un nom que es va informar com a absent pot continuar absent després de corregir la xarxa, cosa que es llegeix com un túnel trencat quan és un TTL que no ha caducat. L’especificació DNS descriu com s’han de conservar i reutilitzar aquestes dades.

Anoteu l’esdeveniment, no la impressió

Anoteu quina de les tres coses ha canviat: el registre, el camí cap al resoledor o una configuració del client. L’edició d’un registre es propaga segons el seu propi calendari, un canvi de ruta entra en vigor en reconnectar-se, i una configuració del navegador només s’aplica a aquell navegador. Col·lapsar-les en un sol abans i després produeix una cronologia que ningú no pot auditar.

Anoteu l’hora, el resoledor en ús i la resposta rebuda, inclòs el cas que la resposta sigui negativa. Això és un fet que algú altre pot comprovar.

Feu la comparació dues vegades de la mateixa manera

Buideu la memòria cau que voleu provar, conserveu l’observació original i després consulteu d’una manera que eviti tanta memòria com sigui possible. Nomenar el resoledor explícitament us diu què sap aquell resoledor; no us diu quin resoledor hauria triat l’aplicació.

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

A Windows, el buidatge de la memòria cau del client buida la memòria cau del client DNS i res més. No descriu l’estat privat d’un navegador ni buida un servidor superior, així que una prova basada en això només es pot interpretar de manera estreta. Digueu quina memòria cau heu buidat sempre que informeu del resultat.

Després torneu a provar l’aplicació real amb una sol·licitud nova i la política de resoledor prevista activa. Un resultat produït amb una política diferent no es transfereix.