Reparerte VPN-en DNS, eller vart eit bufra svar berre brukt om att?

Å opne ei side nokre sekund etter at tunnelen er oppe er ikkje prov på at DNS no verkar, sjølv om billetten vanlegvis seier det. Ingenting i den observasjonen kravde eit oppslag: namnet kan ha vorte løyst før endringa og brukt om att frå ein cache som tunnelen aldri rørte. To ulike testar gjev same skjermbilete.

Samanlikn kva kvar test faktisk øvde på, før du gjev endringa æra.

Å laste ei side er ikkje eit oppslag

Kvart lag mellom programmet og resolvaren kan hugse eit svar i levetida si. Operativsystemet held eitt, nettlesaren held sitt eige, og eit program med ei langvarig tilkopling løyser kanskje aldri noko meir i løpet av økta. Ei innlasting som lukkast etter ei tunnelendring kan difor vere ein demonstrasjon av minne og ikkje av ruting. Fråværet av ein feil er ikkje tilstadeværet av eit oppslag.

Den skilnaden endrar kva du bør teste neste gong. Viss målet er å vise at den nye resolvaren svarar, treng du ei spørjing som ikkje kan tenast frå ein cache du ikkje har tømt.

Å lese ein bufra suksess som prov på at ein tidlegare utilgjengeleg tenar er komen tilbake, er den dyraste versjonen av denne feilen, fordi han avsluttar hendinga på ein falsk føresetnad.

Tel cache-laga før du konkluderer

Fire er verd å nemne: programmet si eiga oppløysing, klientcachen til operativsystemet, den interne tilstanden til nettlesaren og den rekursive resolvaren spørjinga til slutt når. Kvar har ei separat levetid og ein separat måte å bli tømd på. Å tømme éin og teste ein annan er måten folk konkluderer med at tømminga ikkje gjorde noko. Éin tømmekommando avgjer aldri spørsmålet.

Negative svar blir også bufra. Eit namn som vart rapportert som manglande, kan halde fram med å mangle etter at nettverket er retta, noko som blir lese som ein øydelagd tunnel når det er ein TTL som ikkje er utlopen. DNS-spesifikasjonen skildrar korleis desse dataa skal haldast og brukast om att.

Registrer hendinga, ikkje inntrykket

Skriv ned kva av tre ting som endra seg: posten, vegen til resolvaren eller ei klientinnstilling. Ei postendring spreier seg etter sin eigen tidsplan, ei ruteendring tek til ved gjenoppkopling, og ei nettlesarinnstilling gjeld berre for den nettlesaren. Å slå dei saman til eitt før-og-etter gjev ei tidslinje ingen kan revidere.

Noter tidspunktet, resolvaren som vart brukt og svaret som vart motteke, inkludert tilfellet der svaret er negativt. Det er eit faktum nokon andre kan kontrollere.

Gjer samanlikninga to gonger på same måte

Tøm cachen du har tenkt å teste, hald på den opphavlege observasjonen, og spør deretter på ein måte som omgår så mykje minne som mogleg. Å namngje resolvaren eksplisitt fortel deg kva den resolvaren veit; det fortel deg ikkje kva resolvar programmet ville ha valt.

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

På Windows tømmer klientcache-tømminga DNS-klientcachen og ingenting anna. Ho skildrar ikkje ein privat tilstand i nettlesaren og tømmer ikkje ein oppstraums tenar, så ein test bygd på henne kan berre tolkast snevert. Sei kva cache du tømde når du rapporterer resultatet.

Test deretter sjølve programmet på nytt med ei fersk førespurnad og den tiltenkte resolvarpolicyen aktiv. Eit resultat produsert under ein annan policy blir ikkje overført.