BIND über ein VPN: bedingte Weiterleitung oder Stub-Zone?

Ihr Büro-Resolver beantwortet alles außer einem Unternehmens-Namensraum, und der Unternehmens-DNS-Server, der ihn kennt, steht hinter einem VPN. BIND kann diese einzelne Zone auf drei verschiedene Arten an den Upstream übergeben, und sie scheitern unterschiedlich. Bedingte Weiterleitung ist die kleinste Verpflichtung, eine Stub-Zone behält die Delegationsdaten, und eine Secondary behält eine vollständige Kopie. Entscheiden Sie nach dem, was der Upstream zulässt, und danach, was Ihr Resolver halten soll, nicht nach dem Snippet, das Sie zuerst gefunden haben.

Drei Anordnungen für einen Namensraum

Bedingte Weiterleitung: die kleinste Verpflichtung

Nehmen Sie einen Büro-Resolver unter 192.168.10.53 und einen Unternehmensserver unter 10.40.0.53 an, der über einen freigegebenen Tunnel erreichbar ist. Die Deklaration besteht aus drei Zeilen, und die interessante Zeile ist forward only, denn sie ändert das Fehlerverhalten, nicht den Pfad.

zone "corp.example" {
    type forward;
    forward only;
    forwarders { 10.40.0.53; };
};

Mit forward only liefert ein nicht erreichbarer Upstream ein SERVFAIL für diese Zone statt eines Rückfalls auf iterative Auflösung. Das ist für einen privaten Namensraum meist gewünscht, denn der Rückfall würde private Namen an einen öffentlichen Resolver schicken und eine unbrauchbare Antwort aus dem Internet zurückbringen. Die BIND-Referenz dokumentiert beide Richtlinien, und der Unterschied ist wichtiger, als das Snippet vermuten lässt. Fügen Sie die Zone in die bestehende Konfiguration ein, statt eine Zone zu ersetzen, die für denselben Namen bereits existiert.

Stub oder Secondary: wenn die Delegation zählt

Eine Stub-Zone fragt den Unternehmensserver nach den NS-Einträgen der Zone und fragt dann die autoritativen Server direkt. Wählen Sie sie, wenn die Upstream-Region groß oder unterteilt ist und Ihr Resolver der Delegation folgen soll, statt alles an eine Adresse zu binden. Der Preis ist eine Abhängigkeit davon, dass die NS-Daten aktuell sind, und davon, dass jeder aufgeführte Namensserver von der Quelladresse Ihres Resolvers erreichbar ist.

zone "corp.example" {
    type stub;
    masters { 10.40.0.53; };
};

zone "corp.example" {
    type secondary;
    primaries { 10.40.0.53; };
    file "corp.example.db";
};

Eine Secondary antwortet aus lokalen Daten und übersteht einen Upstream-Ausfall, und das ist der Grund, die Transfer-Abhängigkeit zu akzeptieren. Das bedeutet auch, dass Ihr Resolver nun eine Kopie einer Zone hält, die ihm nicht gehört, sodass der Dateipfad, die Transfer-ACL auf dem Primary und die Aktualisierungstimer Teil Ihrer Betriebsfläche werden.

Die Prüfung, die zwischen ihnen entscheidet

BIND erzeugt seine eigene ausgehende Abfrage, die Frage ist also nicht, ob ein Laptop 10.40.0.53 erreicht, sondern ob der Resolver-Host es tut, und zwar von der Quelladresse, die der Unternehmensserver sieht. Fragen Sie den Kernel, dann den Server, in dieser Reihenfolge.

ip route get 10.40.0.53
named-checkconf
rndc reload corp.example
dig @10.40.0.53 corp.example NS +norecurse
dig @192.168.10.53 portal.corp.example

Erlauben Sie UDP und TCP auf dem Pfad: eine abgeschnittene Antwort erzwingt TCP, und eine Richtlinie, die nur UDP zulässt, erzeugt zeitweilige Fehler, die wie Paketverlust aussehen. Die Unternehmensseite braucht sowohl eine Accept-Regel für die Quelle Ihres Resolvers als auch eine Rückroute dorthin; diese Quelle kann die geroutete Adresse des Resolvers oder eine ausdrücklich übersetzte sein, und sie ist selten eine Adresse aus einem Client-Pool. Scheitert die NS-Abfrage, kann eine Stub-Zone nicht funktionieren, egal wie sich die Forward-Zone verhält.

Prüfen Sie die Antwort, nicht den Tunnel

Fragen Sie über den Büro-Resolver einen Namen ab, nach dem Sie noch nie gefragt haben, und prüfen Sie den Authority-Abschnitt der Antwort, ob sie aus der Unternehmenszone kam. Eine gecachte Antwort beweist nichts über den aktuellen Pfad, und eine erfolgreiche direkte Abfrage beim Upstream beweist nicht, dass Ihr Resolver diese Zone gewählt hat. Wiederholen Sie dieselbe Abfrage über TCP, um zu bestätigen, dass der Pfad Kürzung übersteht.

Halten Sie Clients auf den Büro-Resolver gerichtet, und lassen Sie die DNSSEC-Validierung an. Ein Browser, der mit einem unabhängigen verschlüsselten Resolver konfiguriert ist, umgeht diese Anordnung vollständig, und die Validierung abzuschalten, damit eine unerwartete Antwort korrekt aussieht, tauscht einen sichtbaren Fehler gegen einen unsichtbaren.

Notieren Sie, welchen der drei Typen Sie gewählt haben und warum. Die nächste Person, die die Zone scheitern sieht, braucht diesen Satz mehr als die Konfigurationsdatei.