VPN-DNS falsch? Ein autoritativer Server kann veraltet sein

VPN verbinden, und ein Hostname löst auf die Adresse von gestern auf oder auf gar nichts. Trennen, und es funktioniert wieder. Der Reflex ist, den Resolver zu beschuldigen, den der Tunnel vorgegeben hat, doch die häufigere Ursache ist ein veröffentlichter Namensserver, der keine Zonenupdates mehr erhielt. Der neue Pfad erreichte einfach eine andere autoritative Quelle als die, aus der die zwischengespeicherte Antwort stammte.

Das Symptom ändert sich mit dem Resolver

Ein rekursiver Resolver gibt zurück, was eine autoritative Quelle ihm gesagt hat, und behält diese Antwort für die TTL. Schiebt der Tunnel einen anderen Resolver vor oder ändert den Pfad so, dass der alte nicht mehr erreichbar ist, fragt der Client eine andere autoritative Quelle und erhält eine andere Antwort. Die Domain änderte sich in diesem Moment nicht; Ihr Blick darauf änderte sich.

Deshalb kann derselbe Name in einem Büro funktionieren und aus einem Hotel scheitern, und deshalb hilft das Leeren eines lokalen Caches nur manchmal. Das Leeren des Caches schickt die Frage wieder an dieselbe autoritative Quelle.

Der entscheidende Test ist eine direkte Abfrage an jeden veröffentlichten Server.

Jede autoritative Quelle direkt abfragen

Beginnen Sie bei der Delegation und nicht bei einer Liste, an die Sie sich erinnern. Fragen Sie die übergeordnete Zone nach dem NS-Satz und fragen Sie dann jeden Namen aus diesem Satz nach dem Datensatz, der Sie interessiert. Zwei Abfragen desselben Namens bei verschiedenen autoritativen Servern zeigen sofort, ob die Zone konsistent ist.

dig +short NS example.com
dig @ns1.dns.example app.example.com A
dig @ns2.dns.example app.example.com A

Dasselbe gilt für die NS-Datensätze an der Zonenspitze, denn die Delegation der übergeordneten Zone und der eigene NS-Satz der Zone können nach einer Migration voneinander abweichen. Seriennummern im SOA sind das Nächste, was zu vergleichen ist, und ein weit zurückliegender sekundärer Server ist ein Transferproblem und kein Antwortproblem.

Führen Sie diese Abfragen aus dem Netz aus, das scheitert, nicht nur von Ihrem Schreibtisch.

Beabsichtigte Ansichten von defekten trennen

Manche Domains antworten absichtlich je nach Region oder Resolver-Gruppe unterschiedlich, und Split-Horizon-Konfigurationen sind in Unternehmensnetzen normal.

Die Frage ist, ob der Unterschied dokumentiert und stabil ist. Eine unbeabsichtigte Ansicht sieht anders aus: eine autoritative Quelle hat einen Datensatz, den die anderen nie erhalten haben, oder ihr fehlt einer, den alle teilen. Die RFC 2182 zu Auswahl und Betrieb behandelt autoritative Verfügbarkeit als gemeinsame Verantwortung, und das ist hier der richtige Rahmen. Redundanz existiert nur, wenn jeder veröffentlichte Server die beabsichtigten Daten beantworten kann und nicht bloß eine Verbindung auf Port 53 annimmt.

Ein Server, der SERVFAIL antwortet, ist leichter zu diagnostizieren als einer, der selbstsicher und falsch antwortet.

Eine Migration legt offen, was ein Cache verdeckte

Beim Anbieterwechsel ändern sich zwei autoritative Stellen: die Delegation der übergeordneten Zone und die eigenen NS-Datensätze der Zone. Beide müssen aktualisiert werden, und beide werden für ihre TTLs zwischengespeichert. Bleibt ein alter Server online und bedient weiter die frühere Zone, erhalten Clients, deren Resolver ihn fragen, noch lange die alte Antwort, nachdem der Wechsel abgeschlossen aussah.

Genau diesen Zustand verbirgt ein langlebiger Cache. Die Workstation, die die ganze Woche funktionierte, sprach mit einem Resolver, der eine frische Antwort der neuen autoritativen Quelle hielt, während die alte weiter veraltete Daten an alle anderen ausgab.

Den Resolver auf einem Laptop zu ändern, repariert diesen Laptop und sonst nichts.

Reparieren Sie die Zone, nicht den Resolver

Bestimmen Sie, welche Server für die Zone autoritativ sein sollen, korrigieren Sie die verwaltete Zone oder die Delegation, sodass jeder von ihnen die beabsichtigten Daten liefert, und behalten Sie die geplante Redundanz. Einen Namensserver zu löschen, weil ein VPN-Ausgang eine seltsame Antwort erhielt, verringert die Verfügbarkeit und lässt die Inkonsistenz bestehen.

Führen Sie danach die direkten Abfragen aus beiden Netzen erneut aus und warten Sie die TTL des geänderten Datensatzes ab.

Bestätigen Sie, dass die Antwort von jeder autoritativen Quelle stabil ist, und schreiben Sie die beabsichtigte Ansicht in die Zonendokumentation, damit der nächste Unterschied leicht einzuordnen ist.