NXDOMAIN über ein VPN bedeutet keinen Tunnelausfall

Es ist verlockend, eine fehlgeschlagene Abfrage als Beweis dafür zu lesen, dass der Tunnel zusammengebrochen ist, besonders wenn der Name zehn Minuten zuvor noch funktionierte. Die Antwort sagt etwas anderes. NXDOMAIN ist eine abgeschlossene DNS-Transaktion, in der ein Resolver erklärt hat, dass der abgefragte Name nicht existiert; ein defekter Tunnel erzeugt meist Stille, einen Timeout oder einen Auflösungsversuch gegen den falschen Server. Die wireshark-freie Version des Arguments ist eine Abfrage, ein Antwortender und ein Antwortcode, und dieses Trio ist es wert, vor jeder Konfigurationsänderung festgehalten zu werden.

Was die Antwort tatsächlich belegt

DNS trennt Ergebnisse, die Clients oft zu einem einzigen Fehler zusammenfassen. Ein Name, der nicht existiert, erzeugt eine negative Antwort mit dem Code NXDOMAIN, während ein Name, der existiert, aber keinen Datensatz des angefragten Typs hat, eine erfolgreiche Antwort mit leerem Antwortabschnitt erzeugt. Beides wirkt auf eine Anwendung wie nichts Brauchbares, und nur eines davon bedeutet, dass der Name falsch ist.

Dieser Unterschied entscheidet, wohin die Reparatur gehört. Ein fehlender AAAA-Datensatz auf einem Host mit einem A-Datensatz ist kein fehlender Host, und ein Zertifikat neu auszustellen oder einen Tunnel neu aufzubauen, um dem nachzujagen, verschwendet den einzigen verfügbaren Hinweis. Die Unterscheidung bestimmt auch die Form der Nacharbeit: Ein Namensproblem wird in der Zone behoben, und ein Typenproblem wird behoben, indem nach dem richtigen Datensatz gefragt wird oder indem akzeptiert wird, dass die Adressfamilie schlicht fehlt.

Der Mythos: Ein fehlender privater Name bedeutet, dass der Tunnel versagt hat

Der Mythos überlebt, weil die beiden Ereignisse so oft zusammenkommen. Ein Client verbindet sich mit dem VPN, das Betriebssystem behält einen Resolver, dem es bereits vertraute, und der interne Name, den es jetzt braucht, wird bei einem Server erfragt, der von der privaten Zone noch nie gehört hat. Dieser Server antwortet ehrlich und negativ. Der Tunnel trägt das Paket; die Antwort betrifft lediglich einen Namensraum, den der Antwortende nicht bedient.

Split-Horizon-Anordnungen machen das zur Routine: Derselbe Zonenname existiert öffentlich und intern mit unterschiedlichen Inhalten, und nur der interne Resolver kennt die privaten Datensätze. Eine autoritativ wirkende negative Antwort zu erhalten, ist daher ein Beleg dafür, welcher Resolver geantwortet hat, nicht ein Beleg für den Zustand der Schnittstelle.

Zwei Konfigurationsdetails entscheiden über den Ausgang. Der Tunnel muss den internen Resolver pushen oder auswählen, und der Client muss diese Auswahl auf den nachgeschlagenen Namen anwenden. Eine Regel pro Domäne, die ein Suffix nennt, das leicht von dem eingegebenen Datensatz abweicht, schickt die Abfrage auf den öffentlichen Weg, und die Antwort wird korrekt und nutzlos sein.

Fragen Sie den richtigen Resolver mit dem richtigen Namen

Halten Sie den Antwortenden fest, bevor Sie das Urteil festhalten. Eine Abfrage, die nicht zeigt, welcher Server geantwortet hat, kann ein Richtlinienproblem nicht von einem Namensraumproblem unterscheiden, und die beiden haben unzusammenhängende Korrekturen.

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

Die ersten beiden Zeilen zeigen, was der lokale Resolver entschieden hat und wen er fragen würde. Die +search-Abfrage bildet nach, was eine Anwendung tut, wenn sie ein Suchsuffix anhängt, was oft die eigentliche Abfrage ist und nicht die in ein Diagnosewerkzeug getippte. Die letzte Zeile fragt den internen Server direkt und umgeht die Client-Richtlinie; wenn das gelingt, während die einfache Abfrage scheitert, ist die Zone in Ordnung und das Routing der Abfragen nicht.

Negatives Caching erklärt die Verzögerung nach einer Korrektur

Negative Antworten werden konstruktionsbedingt gecacht, und RFC 2308 beschreibt, wie die Lebensdauer des negativen Caches aus dem Autoritätsdatensatz der Zone abgeleitet wird. Das Korrigieren eines Datensatzes oder einer Resolver-Regel garantiert daher keine sofortige Änderung am Client, und eine Abfrage zu wiederholen, die weiterhin die gecachte Antwort liefert, beweist nichts Neues. Nur ein anderer Antwortender, ein anderer Name oder ein geleerter Cache liefert frische Belege.

Leeren Sie den lokalen Cache und wiederholen Sie dann dieselbe Abfrage gegen denselben Antwortenden. Auf Systemen mit dem lokalen Resolver-Dienst ist das ein Befehl; auf anderen ist es ein Dienstneustart oder ein Plattformwerkzeug, und das konkrete Werkzeug ist weniger wichtig als ein danach wiederholter identischer Test.

Trennen Sie den Namen vom Pfad

Sobald der Name zur erwarteten privaten Adresse auflöst, ist DNS als Thema erledigt und der Anwendungspfad wird die nächste Frage. Ein Host, der Abfragen beantwortet, aber eine Verbindung ablehnt, hat ein anderes Problem, und weiter Resolver zu justieren, nachdem eine Antwort korrekt ist, ist der Weg, auf dem ein Vorfall drei unzusammenhängende Änderungen bekommt. Vergleichen Sie die aufgelöste Adresse mit der, auf der der Dienst tatsächlich lauscht, bevor Sie annehmen, dass beide übereinstimmen.

Bewahren Sie das Protokoll auf: die Abfrage, den Antwortenden, den Code und die aufgelöste Adresse. Dieser Datensatz ist auch das, was einen späteren Bericht überprüfbar macht, und er ist der Unterschied zwischen einer Diagnose und einer Geschichte über einen Tunnel, der langsam wirkte.