Fixade VPN:en DNS, eller återanvändes bara ett cachat svar?

Att öppna en sida några sekunder efter att tunneln kommit upp är inte bevis för att DNS nu fungerar, även om biljetten vanligtvis säger det. Ingenting i den observationen krävde en fråga: namnet kan ha lösts före ändringen och återanvänts från en cache som tunneln aldrig rörde. Två olika tester ger samma skärmbild.

Jämför vad varje test faktiskt övade på innan du ger ändringen äran.

Att ladda en sida är inte en fråga

Varje lager mellan programmet och resolvern får komma ihåg ett svar under sin livstid. Operativsystemet håller ett, webbläsaren håller sitt eget, och ett program med en långvarig anslutning kanske aldrig löser något mer under sessionen. En laddning som lyckas efter en tunneländring kan därför vara en demonstration av minne snarare än av routing. Avsaknaden av ett fel är inte närvaron av en fråga.

Den skillnaden ändrar vad du bör testa härnäst. Om målet är att visa att den nya resolvern svarar behöver du en fråga som inte kan betjänas från en cache som du inte har tömt.

Att läsa en cachad framgång som bevis för att en tidigare oåtkomlig server har återhämtat sig är den dyraste versionen av detta misstag, eftersom det avslutar incidenten på en falsk premiss.

Räkna cacharna innan du drar slutsatser

Fyra är värda att nämna: programmets egen upplösning, operativsystemets klientcache, webbläsarens interna tillstånd och den rekursiva resolver som frågan till slut når. Var och en har en separat livstid och ett separat sätt att tömmas. Att tömma en och testa en annan är hur människor drar slutsatsen att tömningen inte gjorde något. Ett tömningskommando avgör aldrig frågan.

Negativa svar cachas också. Ett namn som rapporterades saknas kan förbli saknat efter att nätverket rättats, vilket läses som en trasig tunnel när det är en TTL som inte har gått ut. DNS-specifikationen beskriver hur dessa data ska hållas och återanvändas.

Registrera händelsen, inte intrycket

Skriv ned vilken av tre saker som ändrades: posten, vägen till resolvern eller en klientinställning. En postredigering sprids enligt sitt eget schema, en ruttändring träder i kraft vid återanslutning, och en webbläsarinställning gäller bara för den webbläsaren. Att slå ihop dem till ett enda före-och-efter ger en tidslinje som ingen kan granska.

Notera tiden, resolvern som användes och svaret som togs emot, inklusive fallet där svaret är negativt. Det är ett faktum som någon annan kan kontrollera.

Gör jämförelsen två gånger på samma sätt

Töm cachen du tänker testa, behåll den ursprungliga observationen och fråga sedan på ett sätt som kringgår så mycket minne som möjligt. Att namnge resolvern uttryckligen säger vad den resolvern vet; det säger inte vilken resolver programmet skulle ha valt.

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

På Windows tömmer tömningen av klientcachen DNS-klientcachen och ingenting annat. Den beskriver inte en webbläsares privata tillstånd och tömmer inte en uppströms server, så ett test byggt på den kan bara tolkas snävt. Säg vilken cache du tömde när du rapporterar resultatet.

Testa sedan själva programmet igen med en färsk begäran och den avsedda resolverpolicyn aktiv. Ett resultat som producerats under en annan policy överförs inte.