Rekursion nicht verfügbar: eine DNS-Richtlinie, kein kaputter Tunnel

Der interne Name wird aufgelöst, und derselbe Server beantwortet einen externen Namen mit einer Ablehnung zur Rekursion. Diese Kombination ist kein Widerspruch. Eigene Zonen zu veröffentlichen und das gesamte Internet aufzulösen sind zwei getrennte Dienste, die ein Server anbieten kann, und er kann den ersten ohne den zweiten leisten. Behandeln Sie die Ablehnung als Richtlinienaussage und prüfen Sie dann, ob die Richtlinie zum Entwurf passt.

Eine Ablehnung und eine Zeitüberschreitung sind verschiedene Antworten

Notieren Sie den Namen, den Abfragetyp, den antwortenden Server, den Status und die zurückgegebenen Datensätze. Eine Rekursionswarnung macht eine autoritative Antwort, die mit ihr ankam, nicht automatisch ungültig. Schreiben Sie den Status auf, bevor Sie ihn deuten. Ein Status, der eine Stunde später aus dem Gedächtnis rekonstruiert wird, ist eine andere Tatsache.

Der DNS-Header trägt eine Anfrage nach Rekursion und einen Hinweis, ob der Server sie anbietet, und die Protokollspezifikation hält diese Flags getrennt von den Antwortdaten. Deshalb kann eine Antwort nützlich sein und trotzdem eine Beschwerde tragen. Eine Zeitüberschreitung, eine negative Antwort und eine Ablehnung sind drei verschiedene Ergebnisse. Jedes zeigt auf eine andere Schicht, und nur die Ablehnung ist der Server, der Ihnen von Richtlinie erzählt.

Lesen Sie zuerst den Statuscode und entscheiden Sie dann, ob die Warnung für diese Abfrage wichtig ist. Eine autoritative Antwort, die die Zone nennt, ist brauchbar, auch wenn das Rekursionsbit abgelehnt wird. Eine Ablehnung ohne Antwort ist ein Richtlinienergebnis, kein kaputter Paketweg.

Was der Resolver als Ihre Quelle festgehalten hat

Der Client kann aus einem Adresspool außerhalb der erlaubten Rekursionsbereiche des Servers kommen, oder eine Übersetzung lässt ihn wie ein Gateway aussehen. Die eigene Adapteradresse des Clients ist kein Beweis dafür, was der Resolver empfangen hat. Fragen Sie den Administrator des Servers nach der beobachteten Quelle, statt sie von Ihrer Seite des Weges abzuleiten. Die beiden Adressen können sich an jedem übersetzenden Hop unterscheiden.

Fragen Sie denselben Namen vom Client und von einem Host ab, dem der Server bereits vertraut. Der Unterschied zwischen den beiden Antworten ist die Quellenbedingung, und er ist nützlicher als jede der Antworten allein.

dig +short host.corp.example
dig +short example.com

Wenn die Bereitstellung Rekursion für VPN-Clients will, autorisiert der Administrator den passenden Quellenbereich über die eigenen Kontrollen des Servers. Rekursion für jedes Netz zu öffnen, damit ein Test besteht, ist eine viel größere Änderung als die, die getestet wird. Schreiben Sie den autorisierten Bereich neben die Regel, denn die nächste prüfende Person wird fragen, welchen Quellen die Richtlinie dienen sollte. Ein Quellenbereich ohne Eigentümer ist der Weg, auf dem ein vorübergehender Test dauerhaft wird.

Geteiltes DNS ist ein Entwurf, kein Fehler

Manche Bereitstellungen schicken nur Arbeitsdomänen an den privaten Resolver und alles andere an einen anderen zugelassenen Resolver. Das ist ein Entwurf für die Abfrageweiterleitung und kein Beweis dafür, dass der private Server eine lockerere Richtlinie braucht. Unter diesem Entwurf ist ein externer Name, der über den privaten Resolver scheitert, das beabsichtigte Ergebnis und kein Fehler. Die Ablehnung ist der Entwurf, der funktioniert, kein zu dämpfendes Symptom.

Ein öffentlicher Resolver kann das Surfen wiederherstellen, während er interne Namen bricht oder private Abfragen dorthin schickt, wo sie nicht hingehören. Schreiben Sie das beabsichtigte Verhalten auf, bevor Sie eine Resolveradresse ändern.

Prüfen Sie die Richtlinie mit zwei Abfragen

Fragen Sie nach der beabsichtigten Korrektur einen erlaubten privaten Namen und einen externen Namen vom tatsächlichen Client ab. Was zurückkommt, sollte das sein, was die Richtlinie verspricht, nicht nur eine leisere Diagnose. Notieren Sie den antwortenden Server bei jeder Antwort und vergleichen Sie dann das Paar mit der Richtlinie. Der Vergleich ist der Test, und eine einzelne erfolgreiche Abfrage ist es nicht.

resolvectl query host.corp.example
resolvectl query example.com

Wenn der private Name funktioniert und der öffentliche abgelehnt wird, tut die Richtlinie, was sie sagt. Wenn der private Name ebenfalls scheitert, liegt das Problem in der Zone, der Route oder der Quellenautorisierung, und Rekursion ist eine Ablenkung. Beide Ergebnisse sind nützlich, und jedes schließt die Hälfte der verbleibenden Hypothesen aus.

Lesen Sie die Ablehnung als Beleg

Eine Ablehnung ist eine Antwort. Sie bedeutet, dass der Server die Abfrage erhielt und die angeforderte Arbeit verweigerte, was sich von einem Paket unterscheidet, das nie ankam. Dieser Unterschied ist die ganze Diagnose. Protokollieren Sie sie als Antwort und nicht als Konnektivitätsfehler.

Dieser Unterschied sagt Ihnen, wo Sie nachsehen müssen: in den Protokollen des Servers, seiner Zugriffsrichtlinie und der Quelle, die er festgehalten hat. Eine Firewall-Änderung kann eine Richtlinienablehnung nicht beheben, und eine Richtlinienänderung kann eine fehlende Route nicht beheben. Halten Sie die beiden Hypothesen getrennt, bis eine von ihnen Belege hat.

Schreiben Sie das Ergebnis und den Eigentümer der Richtlinie ins Ticket, damit die nächste Person bei der Entscheidung beginnt und nicht bei der Warnung. Nennen Sie den autorisierten Quellenbereich und die beiden Namen, die Sie getestet haben. Ein Ticket mit diesen drei Fakten lässt sich erneut ausführen; eines, das sagt "Rekursion ist kaputt", nicht.