Heeft de VPN DNS gerepareerd, of alleen een gecacht antwoord hergebruikt?

Een pagina openen enkele seconden nadat de tunnel omhoogkomt is geen bewijs dat DNS nu werkt, hoewel het ticket dat meestal zegt. Niets in die observatie vereiste een query: de naam kan vóór de wijziging zijn opgelost en hergebruikt uit een cache die de tunnel nooit heeft aangeraakt. Twee verschillende tests produceren hetzelfde scherm.

Vergelijk wat elke test werkelijk heeft geoefend voordat u de wijziging de eer geeft.

Een pagina laden is geen query

Elke laag tussen de toepassing en de resolver mag een antwoord voor zijn levensduur onthouden. Het besturingssysteem houdt er één bij, de browser houdt zijn eigen cache bij, en een toepassing met een langdurige verbinding lost tijdens de sessie misschien nooit meer iets op. Een laadactie die na een tunnelwijziging slaagt, kan dus een demonstratie van geheugen zijn en niet van routering. De afwezigheid van een fout is niet de aanwezigheid van een query.

Dat onderscheid verandert wat u hierna moet testen. Als het doel is aan te tonen dat de nieuwe resolver antwoordt, hebt u een query nodig die niet uit een cache kan worden bediend die u niet hebt geleegd.

Een gecacht succes lezen als bewijs dat een eerder onbereikbare server is hersteld, is de duurste versie van deze fout, omdat het incident op een valse aanname wordt gesloten.

Tel de caches voordat u concludeert

Vier verdienen een naam: de eigen resolutie van de toepassing, de clientcache van het besturingssysteem, de interne status van de browser en elke recursieve resolver die de query uiteindelijk bereikt. Elk heeft een aparte levensduur en een aparte manier om te worden geleegd. Eén legen en een andere testen is hoe mensen concluderen dat het legen niets heeft gedaan. Eén leegcommando beslecht de vraag nooit.

Negatieve antwoorden worden ook gecacht. Een naam die als ontbrekend is gemeld, kan ontbrekend blijven nadat het netwerk is gecorrigeerd, wat als een kapotte tunnel wordt gelezen terwijl het een TTL is die nog niet is verlopen. De DNS-specificatie beschrijft hoe deze gegevens moeten worden bewaard en hergebruikt.

Leg de gebeurtenis vast, niet de indruk

Noteer welke van drie dingen is veranderd: de record, het pad naar de resolver of een clientinstelling. Een recordbewerking verspreidt zich volgens zijn eigen schema, een routewijziging wordt van kracht bij opnieuw verbinden, en een browserinstelling geldt alleen voor die browser. Ze samenvoegen tot één voor-en-na levert een tijdlijn op die niemand kan controleren.

Noteer de tijd, de gebruikte resolver en het ontvangen antwoord, ook het geval waarin het antwoord negatief is. Dat is een feit dat iemand anders kan controleren.

Voer de vergelijking twee keer op dezelfde manier uit

Leeg de cache die u wilt testen, bewaar de oorspronkelijke observatie en vraag daarna op een manier die zoveel mogelijk geheugen omzeilt. De resolver expliciet benoemen vertelt u wat die resolver weet; het vertelt u niet welke resolver de toepassing zou hebben gekozen.

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

Op Windows leegt het legen van de clientcache de DNS-clientcache en niets anders. Het beschrijft geen privéstatus van een browser en leegt geen upstreamserver, dus een test die daarop is gebouwd kan alleen eng worden geïnterpreteerd. Zeg welke cache u hebt geleegd wanneer u het resultaat rapporteert.

Test daarna de werkelijke toepassing opnieuw met een vers verzoek en het beoogde resolverbeleid actief. Een resultaat dat onder een ander beleid is geproduceerd, wordt niet overgedragen.