Zwei Standorte, eine private DNS-Zone: Wem gehören die Einträge?

Sie fügen einen Host am grünen Standort hinzu, er wird für grüne Benutzer aufgelöst, und das gelbe Büro erhält weiterhin NXDOMAIN. Das ist kein VPN-Fehler und kein defekter Resolver; es ist eine Eigentumslücke in der privaten Zone. Zwei unabhängig bearbeitete Eintragslisten werden nicht zu einer Zone, nur weil die Standorte einander erreichen können. Die Lösung ist ein Veröffentlichungsplan, keine weitere Firewall-Regel.

Das Symptom benennt den fehlenden Eigentümer

Jeder Standort hat wahrscheinlich eine lokale Überschreibung, einen Pi-hole-Eintrag oder eine dnsmasq-Zeile, die jemand hinzufügte, als ein Name gebraucht wurde. Der grüne Eintrag existiert nur auf dem grünen Resolver, also fragt ein Client am gelben Standort seinen eigenen Resolver und erhält ein wahrheitsgemäßes "kein solcher Name". Eine veraltete Antwort sieht anders aus: Der Host wurde verschoben, ein Standort aktualisierte seine Kopie, und der andere liefert weiterhin die alte Adresse.

Keines der beiden Muster wird durch ein Leeren des Caches dauerhaft behoben. Der Cache eines weiterleitenden Resolvers ist eine Kopie einer Antwort, die er einmal erhalten hat, keine Autorität, die neue Namen veröffentlicht; ein Cache, der heute funktioniert, sagt nichts über den Host von morgen. Die BIND-Dokumentation beschreibt primäre, sekundäre, rekursive und weiterleitende Rollen genau aus diesem Grund getrennt.

Die Entwurfsfrage ist also eng und beantwortbar: Wer darf einen Eintrag anlegen, und wie erreicht dieser Eintrag jeden Resolver, der dafür antworten muss?

Option A: eine autoritative Zone mit Sekundärservern

Betreiben Sie einen Primärserver für internal.example.com und lassen Sie unterstützte Sekundärserver die Zone an jedem Standort beziehen. Der rekursive Resolver jedes Standorts fragt seinen lokalen Sekundärserver, sodass Antworten aus einer autoritativen Quelle statt aus einem Cache kommen, und eine einmal vorgenommene Änderung wird übertragen statt neu getippt.

Diese Anordnung verlangt ausdrückliche Entscheidungen, die sich leicht aufschieben und teuer überspringen lassen. Wer darf die Zone bearbeiten? Welche Server dürfen sie übertragen, und über welche Adressen? Was sollen Clients sehen, während der Tunnel zwischen den Standorten ausgefallen ist? Ein Sekundärserver antwortet weiter aus seiner letzten Kopie, was normalerweise das gewünschte Verhalten ist, aber es muss eine erklärte Wahl sein und keine Überraschung während einer Störung.

Beschränken Sie Zonentransfers auf die bekannten Sekundärserver nach Adresse und verwenden Sie Transaktionssignaturen, wo die Implementierung sie unterstützt. Ein offener Transfer ist eine Kopie Ihres internen Namensraums für jeden, der den Port erreicht.

Der Preis ist Koordination: ein Bearbeitungspfad, eine Änderungsprüfung und ein gemeinsames Verständnis davon, wer Bereitschaft hat, wenn ein Eintrag falsch ist.

Option B: eine Subdomain pro Standort

Delegieren Sie green.internal.example.com an den grünen Standort und yellow.internal.example.com an den gelben. Jeder Standort wird für seine eigenen Namen autoritativ, und die übergeordnete Zone trägt nur die Delegationseinträge. Der Streit um eine Datei verschwindet, und ein lokales Team kann einen Host hinzufügen, ohne auf eine zentrale Änderung zu warten.

Die Delegation muss in der übergeordneten Zone existieren, mit NS-Einträgen, die auf die autoritativen Server des Standorts zeigen. Eine bedingte Weiterleitung für die Subdomain ist eine gültige Alternative, wenn eine vollständige Delegation unpraktisch ist, aber das ist eine Resolver-Einstellung und keine veröffentlichte Tatsache, also braucht jeder Resolver dieselbe Regel.

Der Preis verschiebt sich, statt zu verschwinden: Die übergeordnete Zone braucht weiterhin einen Eigentümer, und ein neuer Standort ist jetzt eine Änderung an zwei Stellen statt an einer.

Lassen Sie jeden Resolver der Wahl folgen

Geben Sie Clients den freigegebenen Resolver und die Suchdomäne über ihre unterstützte Konfiguration, und stellen Sie sicher, dass der Resolver eine erlaubte VPN-Route zu jedem entfernten DNS-Server hat, den er abfragen muss. Anwendungen brauchen außerdem Routen zu den privaten Adressen, die diese Antworten zurückgeben, denn ein korrekter Name ohne Pfad ist immer noch eine gebrochene Verbindung.

Wenn Pi-hole die lokale Auflösung liefert, notieren Sie, welche Einträge es besitzt und welche Abfragen es weiterleitet. Zwei unabhängig bearbeitete Pi-hole-Listen replizieren weiterhin nicht. In Pi-hole v6 werden benutzerdefinierte dnsmasq-Zeilen über hostseitige Optionen wie TOML, CLI oder Umgebungsvariablen gesetzt und nicht über die API bereitgestellt; das Laden von Dateien aus /etc/dnsmasq.d/ ist eine separate Option, die standardmäßig ausgeschaltet ist.

Testen Sie dann von beiden Seiten mit einem Namen, der überall sichtbar sein sollte:

$ dig +short newhost.green.internal.example.com @10.20.0.53
10.20.0.41
$ dig +short newhost.green.internal.example.com @10.30.0.53
10.20.0.41
$ dig SOA internal.example.com @10.30.0.53

Die SOA-Antwort sagt Ihnen, ob der gelbe Resolver sich für autoritativ hält, einen Sekundärserver abfragt oder nur weiterleitet. Das sind unterschiedliche Entwürfe mit unterschiedlichen Fehlerarten, und die Antwort benennt meist, welchen Sie tatsächlich umgesetzt haben.

Schließen Sie mit drei Abnahmefällen ab: ein Name von jedem Standort, ein innerhalb einer Stunde geänderter Eintrag und die Verbindung zwischen den Standorten nicht verfügbar. Ein Entwurf, der nur den ersten besteht, hat einen Veröffentlichungsplan auf dem Papier und eine lokale Überschreibung in der Produktion.