A e rregulloi VPN-ja DNS-në, apo thjesht ripërdori një përgjigje të ruajtur në cache?

Hapja e një faqeje sekonda pasi tuneli ngrihet nuk është provë që DNS-ja tani funksionon, ndonëse tiketa zakonisht thotë kështu. Asgjë në atë vëzhgim nuk kërkonte një pyetje: emri mund të jetë zgjidhur para ndryshimit dhe ripërdorur nga një cache që tuneli nuk e preku kurrë. Dy teste të ndryshme prodhojnë të njëjtin ekran.

Krahasoni çfarë ushtroi vërtet secili test përpara se t’ia atribuoni ndryshimit.

Ngarkimi i një faqeje nuk është pyetje

Çdo shtresë midis aplikacionit dhe zgjidhësit lejohet të mbajë mend një përgjigje gjatë jetës së saj. Sistemi operativ mban një, shfletuesi mban të vetin, dhe një aplikacion me lidhje afatgjatë mund të mos zgjidhë më asgjë gjatë sesionit. Prandaj, një ngarkim i suksesshëm pas ndryshimit të tunelit mund të jetë një demonstrim i kujtesës dhe jo i rrugëtimit. Mungesa e një dështimi nuk është prania e një pyetjeje.

Ky dallim ndryshon atë që duhet të testoni më pas. Nëse qëllimi është të tregoni se zgjidhësi i ri përgjigjet, ju nevojitet një pyetje që nuk mund të shërbehet nga një cache që nuk e keni pastruar.

Të lexosh një sukses të ruajtur si provë se një server më parë i paarritshëm është rikuperuar është versioni më i kushtueshëm i këtij gabimi, sepse e mbyll incidentin mbi një premisë të gabuar.

Numëroni cache-t përpara se të përfundoni

Katër meritojnë të përmenden: zgjidhja e vetë aplikacionit, cache-i i klientit të sistemit operativ, gjendja e brendshme e shfletuesit dhe çdo zgjidhës rekurziv që pyetja arrin në fund. Secili ka një jetë të veçantë dhe një mënyrë të veçantë pastrimi. Të pastrosh një dhe të testosh një tjetër është mënyra se si njerëzit përfundojnë se pastrimi nuk bëri asgjë. Një komandë pastrimi nuk e zgjidh kurrë çështjen.

Edhe përgjigjet negative ruhen në cache. Një emër i raportuar si mungues mund të mbetet mungues pasi rrjeti korrigjohet, gjë që lexohet si tunel i prishur kur është një TTL që nuk ka skaduar. Specifikimi DNS përshkruan se si duhet të mbahen dhe ripërdoren këto të dhëna.

Regjistroni ngjarjen, jo përshtypjen

Shkruani cila nga tri gjërat ndryshoi: regjistri, rruga drejt zgjidhësit ose një cilësim i klientit. Redaktimi i një regjistri përhapet sipas kalendarit të vet, një ndryshim rruge hyn në fuqi kur rilidheni, dhe një cilësim i shfletuesit vlen vetëm për atë shfletues. Bashkimi i tyre në një të vetme para-dhe-pas prodhon një kronologji që askush nuk mund ta verifikojë.

Shënoni kohën, zgjidhësin e përdorur dhe përgjigjen e marrë, përfshirë rastin kur përgjigja është negative. Ky është një fakt që dikush tjetër mund ta kontrollojë.

Kryeni krahasimin dy herë në të njëjtën mënyrë

Pastrojeni cache-in që synoni të testoni, mbani vëzhgimin origjinal dhe më pas pyetni në një mënyrë që anashkalon sa më shumë kujtesë. Përmendja shprehimisht e zgjidhësit ju tregon çfarë di ai zgjidhës; nuk ju tregon cilin zgjidhës do të kishte zgjedhur aplikacioni.

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

Në Windows, pastrimi i cache-it të klientit pastron cache-in e klientit DNS dhe asgjë tjetër. Ai nuk përshkruan gjendjen private të një shfletuesi dhe nuk pastron një server të sipërm, prandaj një test i ndërtuar mbi të mund të interpretohet vetëm ngushtë. Thoni cilin cache pastruat sa herë që raportoni rezultatin.

Më pas ritestoni aplikacionin aktual me një kërkesë të re dhe politikën e synuar të zgjidhësit aktive. Një rezultat i prodhuar nën një politikë tjetër nuk transferohet.