Reparerte VPN-en DNS, eller ble et bufret svar bare gjenbrukt?

Å åpne en side noen sekunder etter at tunnelen er oppe er ikke bevis for at DNS nå virker, selv om billetten vanligvis sier det. Ingenting i den observasjonen krevde et oppslag: navnet kan ha blitt løst før endringen og gjenbrukt fra en cache som tunnelen aldri rørte. To forskjellige tester gir samme skjermbilde.

Sammenlign hva hver test faktisk øvde på, før du gir endringen æren.

Å laste en side er ikke et oppslag

Hvert lag mellom applikasjonen og resolveren kan huske et svar i levetiden sin. Operativsystemet holder ett, nettleseren holder sitt eget, og en applikasjon med en langvarig tilkobling løser kanskje aldri noe mer i løpet av økten. En innlasting som lykkes etter en tunnelendring kan derfor være en demonstrasjon av hukommelse og ikke av ruting. Fraværet av en feil er ikke tilstedeværelsen av et oppslag.

Den forskjellen endrer hva du bør teste neste gang. Hvis målet er å vise at den nye resolveren svarer, trenger du en spørring som ikke kan betjenes fra en cache du ikke har tømt.

Å lese en bufret suksess som bevis på at en tidligere utilgjengelig server er gjenopprettet, er den dyreste versjonen av denne feilen, fordi den avslutter hendelsen på en falsk forutsetning.

Tell cache-lagene før du konkluderer

Fire er verdt å navngi: applikasjonens egen oppløsning, operativsystemets klientcache, nettleserens interne tilstand og den rekursive resolveren spørringen til slutt når. Hver har en separat levetid og en separat måte å bli tømt på. Å tømme én og teste en annen er måten folk konkluderer med at tømmingen ikke gjorde noe. Én tømmekommando avgjør aldri spørsmålet.

Negative svar blir også bufret. Et navn som ble rapportert som manglende, kan forbli manglende etter at nettverket er rettet, noe som leses som en ødelagt tunnel når det er en TTL som ikke er utløpt. DNS-spesifikasjonen beskriver hvordan disse dataene skal holdes og gjenbrukes.

Registrer hendelsen, ikke inntrykket

Skriv ned hvilken av tre ting som endret seg: posten, veien til resolveren eller en klientinnstilling. En postredigering spres etter sin egen tidsplan, en ruteendring trer i kraft ved gjenoppkobling, og en nettleserinnstilling gjelder bare for den nettleseren. Å slå dem sammen til ett før-og-etter gir en tidslinje ingen kan revidere.

Noter tidspunktet, resolveren som ble brukt og svaret som ble mottatt, inkludert tilfellet der svaret er negativt. Det er et faktum noen andre kan kontrollere.

Gjør sammenligningen to ganger på samme måte

Tøm cachen du har tenkt å teste, behold den opprinnelige observasjonen, og spør deretter på en måte som omgår så mye hukommelse som mulig. Å navngi resolveren eksplisitt forteller deg hva den resolveren vet; det forteller deg ikke hvilken resolver applikasjonen ville valgt.

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

På Windows tømmer klientcache-tømmingen DNS-klientcachen og ingenting annet. Den beskriver ikke en nettlesers private tilstand og tømmer ikke en oppstrøms server, så en test bygget på den kan bare tolkes snevert. Si hvilken cache du tømte når du rapporterer resultatet.

Test deretter selve applikasjonen på nytt med en fersk forespørsel og den tiltenkte resolverpolicyen aktiv. Et resultat produsert under en annen policy overføres ikke.