Ein Entwickler ruft von zu Hause aus an: „Die API antwortet im Büro in 20 ms, außerhalb in 800 ms.“ Sie öffnen „dig api.example.com“ auf dem Laptop: Die IP ist die des öffentlichen Load Balancers. Er, verbunden mit dem VPN, bezieht die IP eines internen, nicht gerouteten Pods aus dem Internet. Das Ticket wird dringend, wenn die Produktion ein Zertifikat bereitstellt, das nur für den internen Namen gültig ist.
Split-Horizon dient dazu, abhängig vom Ursprung der Abfrage zwei legitime DNS-Wahrheiten bereitzustellen. Schlecht verkabelt wird es zu einer Verwirrungsmaschine: private IP-Lecks, inkonsistente TLS-Zertifikate, lügende Resolver-Caches.
Prinzip: eine Frage, mehrere Antworten
Split-Horizon (oder Split-DNS) gibt je nach Quellnetzwerk unterschiedliche Datensätze zurück: Desktop/VPN vs. Internet. Ein „db.example.com“ kann für Administratoren auf „10.0.1.50“ und für die Öffentlichkeit auf „203.0.113.10“ verweisen.
Dies ist normal und oft wünschenswert, um die interne Latenz zu reduzieren und die Offenlegung administrativer Dienste zu vermeiden. Dabei handelt es sich nicht um DNS-Lügen im böswilligen Sinne: Es handelt sich um eine Sichtbarkeitsrichtlinie.
Wo es in der Produktion kaputt geht
| Symptom | Gemeinsame Ursache |
|---|---|
| Öffentliche Website intern nicht zugänglich | Hairpin-NAT fehlt, Split falsch konfiguriert |
| IP RFC1918 in VirusTotal | Interner Bereich, der fälschlicherweise öffentlich bedient wird |
| SAN-Zertifikat fehlt | Interner Name, der von der öffentlichen Front verwendet wird |
| Langsame Auflösung | Interne/externe Schleifenweiterleitungen |
Worst-Case-Szenario: Ein interner Datensatz wird durch ein ungelesenes Cron-Skript mit einem öffentlichen DNS synchronisiert.
Bereitstellungsmodelle
Zwei Zonen: „corp.internal“ (nicht delegiert) + „example.com“ (öffentlich). Klar für die Teams.
BIND-Ansichten/Richtlinien ungebunden: eine Engine, ACL pro Subnetz. Erfordert Konfigurationsdisziplin.
Cloud DNS + Private Link: Route 53 Resolver, Azure Private DNS, Cloud DNS Private – die Grenze wird zu Netzwerk + IAM.
Wählen Sie basierend darauf, wer das DNS betreibt und wie viele physische Standorte Sie haben.
Synchronisierung und Governance
Gemeinsame Datensätze (MX, TXT SPF, DKIM) müssen auf beiden Seiten identisch bleiben, sofern keine dokumentierte Ausnahme vorliegt. Automatisieren Sie die Replikation öffentlicher Bereiche; Isolieren Sie interne Überschreibungen in dedizierten Dateien oder Etiketten.
Jede Veränderung muss antworten: „Wer sieht was?“ » und „Welcher Resolver wird beim Laptop-VPN-Schnitt verwendet?“
Tests vor jeder Änderung
Aus dem Internet: „dig +trace“, DNSSEC falls aktiv, mit einem öffentlichen Resolver vergleichen.
Vom VPN: gleiche Anfragen, IP und TTL prüfen.
Vom Gastnetzwerk: Stellen Sie sicher, dass kein interner Forwarder erreichbar ist.
Die Protokollzone unterscheidet sich vom Anwendungscode.
Lebendige Dokumentation
Tabelle: FQDN | Innenansicht | Außenansicht | Eigentümer | zuletzt überprüft.
Überprüfung bei jedem internen Onboarding-Service.
Testen Sie VPN aus + vierteljährlich auf demselben Laptop.
Führen Sie ein datiertes Runbook, Vorher-/Nachher-Kennzahlen und eine Überprüfung nach dem Vorfall – kumulative Disziplin vermeidet Panik am Freitagabend.
Führen Sie ein datiertes Runbook, Vorher-/Nachher-Kennzahlen und eine Überprüfung nach dem Vorfall – kumulative Disziplin vermeidet Panik am Freitagabend.
Führen Sie ein datiertes Runbook, Vorher-/Nachher-Kennzahlen und eine Überprüfung nach dem Vorfall – kumulative Disziplin vermeidet Panik am Freitagabend.
Führen Sie ein datiertes Runbook, Vorher-/Nachher-Kennzahlen und eine Überprüfung nach dem Vorfall – kumulative Disziplin vermeidet Panik am Freitagabend.
Führen Sie ein datiertes Runbook, Vorher-/Nachher-Kennzahlen und eine Überprüfung nach dem Vorfall – kumulative Disziplin vermeidet Panik am Freitagabend.
Führen Sie ein datiertes Runbook, Vorher-/Nachher-Kennzahlen und eine Überprüfung nach dem Vorfall – kumulative Disziplin vermeidet Panik am Freitagabend.
Split-Horizon-Dokumentation
Interne/externe/Eigentümer/verifizierte FQDN-Tabelle. Vierteljährlicher Laptop-VPN-Test. Internes TLS: Die Aktualisierung deckt beide Ansichten ab.
Entscheide dich und gehe ohne blinden Fleck voran
- Listen Sie jeden FQDN auf mit seiner internen und externen Antwort, dem Geschäftsinhaber und dem Datum der letzten Überprüfung.
- Getrennte Zonen – zeigt BIND, Route 53-Split-Richtlinien oder dediziertes internes DNS an; Vermeiden Sie eine einzelne „nahezu gleiche“ Zonendatei.
- Test vom Laptop aus – VPN aktiviert und deaktiviert auf denselben kritischen URLs (API, Git, Überwachung).
- AXFR-Übertragungen einschränken – Warnung, wenn die serielle SOA zwischen den Ansichten abweicht oder wenn ein öffentlicher Sekundärserver eine interne IP preisgibt.
- Dokumentieren Sie das Onboarding-Runbook – jeder neue interne Dienst fügt der Tabelle eine Zeile hinzu, bevor er in die Produktion geht.
Um die Größe von internem oder verwaltetem DNS-Hosting zu bestimmen, durchsuchen Sie das Verzeichnis, den Vergleicher und unsere Netzwerk-Anleitungen.
Häufig gestellte Fragen
Split-Horizon und öffentliches DNS, können wir das kombinieren?
Ja, aber nur externe Ansichten sollten öffentlich delegiert werden. Interne Namen sollten in keinem Bereich des Internets ohne Filterung auftauchen.
Sollten wir zwei separate Bereiche haben oder nur einen mit Aussicht?
Zwei separate Zonen (internal.example / example.com) vereinfachen die Governance. Ansichten auf demselben BIND-Server sind geeignet, wenn die ACL-Richtlinie streng und überwacht ist.
Was tun, wenn das VPN ausfällt?
Stellen Sie einen Backup-Resolver, temporäre Failover-Datensätze auf der externen Seite und ein Runbook bereit, das keinen internen Zugriff erfordert, um den öffentlichen Dienst wiederherzustellen.
Wie kann verhindert werden, dass ein Laptop außerhalb des VPN intern aufgelöst wird?
Setzen Sie interne Weiterleitungen nicht in unkontrollierten Netzwerken frei. Verwenden Sie interne, nicht öffentlich delegierte DNS-Suffixe und explizite Split-Tunnel-Richtlinien.
Bevor Sie eine interne Sicht hinzufügen, schreiben Sie den Satz: „Ein Techniker ohne VPN sollte in der Lage sein …“ – wenn die Endung „…nichts“ lautet, liegt ein Single Point of Failure vor.