Hat das VPN DNS repariert oder nur eine gecachte Antwort wiederverwendet?

Eine Seite wenige Sekunden nach dem Aufbau des Tunnels zu öffnen ist kein Beweis dafür, dass DNS jetzt funktioniert, auch wenn das Ticket dies meist behauptet. Nichts an dieser Beobachtung erforderte eine Abfrage: Der Name könnte vor der Änderung aufgelöst und aus einem Cache wiederverwendet worden sein, den der Tunnel nie berührt hat. Zwei verschiedene Tests erzeugen denselben Bildschirm.

Vergleichen Sie, was jeder Test tatsächlich geübt hat, bevor Sie der Änderung den Erfolg zuschreiben.

Eine Seite zu laden ist keine Abfrage

Jede Schicht zwischen der Anwendung und dem Resolver darf sich eine Antwort für ihre Lebensdauer merken. Das Betriebssystem hält eine, der Browser hält seine eigene, und eine Anwendung mit einer langlebigen Verbindung löst während der Sitzung möglicherweise nie wieder etwas auf. Ein Ladevorgang, der nach einem Tunnelwechsel gelingt, kann daher eine Vorführung des Gedächtnisses statt des Routings sein. Die Abwesenheit eines Fehlers ist nicht die Anwesenheit einer Abfrage.

Diese Unterscheidung ändert, was Sie als Nächstes testen sollten. Wenn das Ziel ist zu zeigen, dass der neue Resolver antwortet, brauchen Sie eine Abfrage, die nicht aus einem Cache bedient werden kann, den Sie nicht geleert haben.

Einen gecachten Erfolg als Beweis zu lesen, dass sich ein zuvor unerreichbarer Server erholt hat, ist die teuerste Variante dieses Fehlers, weil sie den Vorfall auf einer falschen Annahme abschließt.

Zählen Sie die Caches, bevor Sie schließen

Vier lohnen sich zu nennen: die eigene Auflösung der Anwendung, der Client-Cache des Betriebssystems, der interne Zustand des Browsers und der rekursive Resolver, den die Abfrage schließlich erreicht. Jeder hat eine eigene Lebensdauer und eine eigene Art, geleert zu werden. Einen zu leeren und einen anderen zu testen ist der Weg, auf dem Menschen schließen, dass das Leeren nichts bewirkt hat. Ein Leerungsbefehl entscheidet die Frage nie.

Auch negative Antworten werden gecacht. Ein Name, der als fehlend gemeldet wurde, kann nach der Korrektur des Netzwerks fehlend bleiben, was als defekter Tunnel gelesen wird, wenn es eine TTL ist, die noch nicht abgelaufen ist. Die DNS-Spezifikation beschreibt, wie diese Daten gehalten und wiederverwendet werden sollen.

Halten Sie das Ereignis fest, nicht den Eindruck

Notieren Sie, welche von drei Dingen sich geändert hat: der Eintrag, der Pfad zum Resolver oder eine Clienteinstellung. Eine Eintragsänderung breitet sich nach ihrem eigenen Zeitplan aus, eine Routenänderung wirkt beim erneuten Verbinden, und eine Browsereinstellung gilt nur für diesen Browser. Sie zu einem einzigen Vorher und Nachher zusammenzufassen erzeugt eine Zeitleiste, die niemand prüfen kann.

Notieren Sie die Zeit, den verwendeten Resolver und die erhaltene Antwort, auch den Fall, in dem die Antwort negativ ist. Das ist eine Tatsache, die jemand anderes überprüfen kann.

Führen Sie den Vergleich zweimal auf dieselbe Weise durch

Leeren Sie den Cache, den Sie testen wollen, behalten Sie die ursprüngliche Beobachtung und fragen Sie dann auf eine Weise ab, die so viel Gedächtnis wie möglich umgeht. Den Resolver ausdrücklich zu nennen sagt Ihnen, was dieser Resolver weiß; es sagt Ihnen nicht, welchen Resolver die Anwendung gewählt hätte.

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

Unter Windows leert das Leeren des Client-Caches den DNS-Client-Cache und nichts anderes. Es beschreibt keinen privaten Browserzustand und leert keinen Upstream-Server, daher kann ein darauf aufbauender Test nur eng interpretiert werden. Sagen Sie, welchen Cache Sie geleert haben, wann immer Sie das Ergebnis melden.

Testen Sie dann die eigentliche Anwendung erneut mit einer frischen Anfrage und der beabsichtigten Resolver-Richtlinie aktiv. Ein unter einer anderen Richtlinie erzeugtes Ergebnis überträgt sich nicht.