Rettede VPN’en DNS, eller blev et cachet svar blot genbrugt?

At åbne en side få sekunder efter, at tunnelen er oppe, er ikke bevis for, at DNS nu virker, selvom billetten normalt siger det. Intet i den observation krævede et opslag: navnet kan være blevet opløst før ændringen og genbrugt fra en cache, som tunnelen aldrig rørte. To forskellige tests giver den samme skærm.

Sammenlign, hvad hver test faktisk udøvede, før du giver ændringen æren.

Indlæsning af en side er ikke et opslag

Hvert lag mellem applikationen og resolveren må huske et svar i sin levetid. Styresystemet holder et, browseren holder sit eget, og en applikation med en langvarig forbindelse opløser måske aldrig noget igen i sessionen. En indlæsning, der lykkes efter en tunnelændring, kan derfor være en demonstration af hukommelse snarere end af routing. Fraværet af en fejl er ikke tilstedeværelsen af et opslag.

Den forskel ændrer, hvad du bør teste næste gang. Hvis målet er at vise, at den nye resolver svarer, har du brug for en forespørgsel, der ikke kan betjenes fra en cache, du ikke har ryddet.

At læse en cachet succes som bevis for, at en tidligere utilgængelig server er kommet sig, er den dyreste version af denne fejl, fordi den lukker hændelsen på en falsk forudsætning.

Tæl cache-lagene, før du konkluderer

Fire er værd at nævne: applikationens egen opløsning, styresystemets klientcache, browserens interne tilstand og den rekursive resolver, som forespørgslen til sidst når. Hver har en separat levetid og en separat måde at blive ryddet på. At rydde én og teste en anden er måden, hvorpå folk konkluderer, at rydningen ikke gjorde noget. Én ryddekommando afgør aldrig spørgsmålet.

Negative svar bliver også cachet. Et navn, der blev rapporteret som manglende, kan forblive manglende, efter netværket er rettet, hvilket læses som en brudt tunnel, når det er en TTL, der ikke er udløbet. DNS-specifikationen beskriver, hvordan disse data skal holdes og genbruges.

Notér hændelsen, ikke indtrykket

Skriv ned, hvilken af tre ting der ændrede sig: posten, vejen til resolveren eller en klientindstilling. En postredigering spredes efter sin egen tidsplan, en ruteændring træder i kraft ved genopkobling, og en browserindstilling gælder kun for den browser. At slå dem sammen til ét før-og-efter giver en tidslinje, som ingen kan revidere.

Notér tidspunktet, den anvendte resolver og det modtagne svar, inklusive tilfældet, hvor svaret er negativt. Det er et faktum, som en anden kan kontrollere.

Udfør sammenligningen to gange på samme måde

Ryd den cache, du vil teste, behold den oprindelige observation, og spørg derefter på en måde, der omgår så meget hukommelse som muligt. At navngive resolveren eksplicit fortæller dig, hvad den resolver ved; det fortæller dig ikke, hvilken resolver applikationen ville have valgt.

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

På Windows rydder klientcache-rydningen DNS-klientcachen og intet andet. Den beskriver ikke en browsers private tilstand og rydder ikke en opstrøms server, så en test bygget på den kan kun fortolkes snævert. Sig, hvilken cache du ryddede, når du rapporterer resultatet.

Test derefter selve applikationen igen med en frisk anmodning og den tilsigtede resolverpolitik aktiv. Et resultat produceret under en anden politik overføres ikke.