A reparat VPN-ul DNS-ul sau doar a reutilizat un răspuns din cache?

Deschiderea unei pagini la câteva secunde după ce tunelul pornește nu dovedește că DNS-ul funcționează acum, deși tichetul spune de obicei acest lucru. Nimic din acea observație nu necesita o interogare: numele poate fi fost rezolvat înainte de schimbare și reutilizat dintr-un cache pe care tunelul nu l-a atins niciodată. Două teste diferite produc același ecran.

Comparați ce a exersat de fapt fiecare test înainte de a atribui meritul schimbării.

Încărcarea unei pagini nu este o interogare

Fiecare strat dintre aplicație și rezolvator poate reține un răspuns pe durata vieții sale. Sistemul de operare păstrează unul, browserul îl păstrează pe al său, iar o aplicație cu o conexiune de lungă durată poate să nu mai rezolve nimic în timpul sesiunii. Prin urmare, o încărcare reușită după o schimbare de tunel poate fi o demonstrație de memorie, nu de rutare. Absența unei erori nu este prezența unei interogări.

Această distincție schimbă ce ar trebui să testați în continuare. Dacă scopul este să arătați că noul rezolvator răspunde, aveți nevoie de o interogare care nu poate fi servită dintr-un cache pe care nu l-ați golit.

A citi un succes din cache ca dovadă că un server anterior inaccesibil și-a revenit este cea mai scumpă versiune a acestei greșeli, pentru că închide incidentul pe o premisă falsă.

Numărați cache-urile înainte de a concluziona

Patru merită numite: rezolvarea proprie a aplicației, cache-ul client al sistemului de operare, starea internă a browserului și orice rezolvator recursiv la care ajunge în final interogarea. Fiecare are o durată de viață separată și o modalitate separată de golire. Să golești unul și să testezi altul este modul în care oamenii concluzionează că golirea nu a făcut nimic. O singură comandă de golire nu lămurește niciodată întrebarea.

Și răspunsurile negative sunt stocate în cache. Un nume raportat ca lipsă poate rămâne lipsă după corectarea rețelei, ceea ce se citește ca un tunel defect, deși este un TTL care nu a expirat. Specificația DNS descrie cum trebuie păstrate și reutilizate aceste date.

Înregistrați evenimentul, nu impresia

Notați care dintre cele trei lucruri s-a schimbat: înregistrarea, calea către rezolvator sau o setare a clientului. Editarea unei înregistrări se propagă după propriul calendar, o schimbare de rută intră în vigoare la reconectare, iar o setare a browserului se aplică doar acelui browser. Reducerea lor la un singur înainte-și-după produce o cronologie pe care nimeni nu o poate verifica.

Notați ora, rezolvatorul folosit și răspunsul primit, inclusiv cazul în care răspunsul este negativ. Acesta este un fapt pe care altcineva îl poate verifica.

Faceți comparația de două ori în același fel

Goliți cache-ul pe care intenționați să îl testați, păstrați observația inițială și apoi interogați într-un mod care ocolește cât mai multă memorie. Numirea explicită a rezolvatorului vă spune ce știe acel rezolvator; nu vă spune ce rezolvator ar fi ales aplicația.

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

În Windows, golirea cache-ului client golește cache-ul client DNS și nimic altceva. Nu descrie starea privată a unui browser și nu golește un server din amonte, așa că un test construit pe el poate fi interpretat doar îngust. Spuneți ce cache ați golit ori de câte ori raportați rezultatul.

Apoi retestați aplicația reală cu o cerere nouă și politica de rezolvator dorită activă. Un rezultat produs sub o altă politică nu se transferă.