Das Konzept
Grundsätzlich ist das DNS so konzipiert, dass es eine weltweit konsistente Zuordnung zwischen einem Namen und einer Ressource erzeugt. Deswegen gibt es pro Zone nur eine federführende Zonendatei auf dem Primary Master, von der Eins-zu-Eins-Kopien auf dem Secondary Master vorliegen. Der Standard legt viel Wert auf diese Konsistenz, damit es eben nicht zu einer Split-Zone kommt. Unter Split-Zone versteht man eine Zone, zu der unterschiedliche Informationen vorliegen, je nachdem, welchen DNS-Server man fragt.
Dieses grundlegende Konzept wird durch Split-DNS aufgeweicht: statt einer einzigen Zonendatei gibt es mindestens zwei. Jedoch hängt die Antwort bei einer Split-Zone nicht davon ab, wen man fragt, sondern wer fragt. Über ein Regelwerk wird festgelegt, wer welche Antwort erhält.
Zwei Anwendungsbeispiele
Zur Veranschaulichung ein einfaches Beispiel: Ein Unternehmen bietet seinen Gästen ein Gäste-WLAN an, für die Mitarbeiter gibt es ein anderes. Wer im Gäste-WLAN ist, kann zwar auf das ganze Internet zugreifen, aber nur auf wenige Server im internen Netz, beispielsweise den DNS-Server und den internen Webserver mit der Speisekarte der Kantine. Letzterer ist allerdings aus dem Internet heraus nicht erreichbar.
Abbildung 1: Extra View für Gäste
Eine Lösung könnte nun so aussehen (vgl. Abbildung 1):
- Im Gäste-WLAN bekommen die Clients Adressen aus dem Bereich 192.168.100.0/24.
- Clients im Corporate-WLAN bekommen, wie alle anderen internen Clients, Adressen aus dem Bereich 10.0.0.0/8
- Für die Domain internal.example.net gibt es zwei Zonendateien: Eine (1) beinhaltet alle internen Systeme, die andere (2) nur die IP-Adresse des internen Webservers.
- Ein IP-basiertes Regelwerk stellt nun sicher, dass Clients mit einer Quelladresse aus dem 192.168.100.0/24er-Netz nur die Daten in der Zonendatei (2) zu sehen bekommen.
Das Verfahren ist nicht auf den internen Gebrauch begrenzt, sondern kann auch für Domains genutzt werden, die im Internet propagiert werden. Insbesondere für Anwendungen, die in Public Clouds gehostet werden, kann eine Split-DNS-Lösung sinnvoll sein.
Die in der Cloud gehosteten Webserver sollen für Interessenten aus dem Internet heraus natürlich erreichbar sein. Dafür ist http und https auf den Firewalls zwischen Internet und Cloud freigegeben. Alle anderen Ports sind jedoch aus Sicherheitsgründen gesperrt. Nun muss es internen Mitarbeitern aber möglich sein, trotzdem auf die Webserver zuzugreifen. Dazu gibt es ein VPN zwischen dem Unternehmen und der Cloud. Über das VPN darf beispielsweise auch mittels ssh zur Administration auf den Webserver zugegriffen werden.
Eine Lösung wird in Abbildung 2 dargestellt:
- Für die Domain example.com gibt es zwei Zonendateien. In einer steht die öffentliche IP-Adresse des WWW-Servers, in der anderen die private IP-Adresse aus dem 10er-Netz.
- Will ein interner Client auf www zugreifen, bekommt er die IP 10.10.10.80 genannt. Die Verbindung wird über das VPN hergestellt.
- Ein externer Client bekommt für www die 195.222.12.244 genannt. Die Verbindung kommt also über das Internet zustande und muss somit durch die zuvor erwähnte Firewall. Damit ist nur http und https erlaubt.
Abbildung 2: Split-DNS und Cloud
Neben diesen beiden Beispielen gibt es noch eine Reihe weiterer Anwendungsmöglichkeiten, in denen ein Split-DNS zur Anwendung kommen kann.
Die Alternativen
Das Problem von Split-DNS ist, dass man im Grunde zwei Zonen für eine Domain pflegen muss. Dass man dabei den Standard arg strapaziert, mag noch angehen, zumal es sich um eine seit Langem etablierte Praxis handelt, die in gängigen Produkten stabil funktioniert. Die eigentlichen Gefahren liegen woanders:
- Bei der Pflege zweier Datensätze steigt das Risiko von Administrationsfehlern. Insbesondere bei großen Datenmengen kann es leicht unübersichtlich werden und so zu fatalen Fehlern kommen, wie z.B., dass eigentlich interne IP-Adressen öffentlich bekannt werden.
- Zwar werden die Zonendateien zwischen den DNS-Servern repliziert, jedoch gilt das nicht für die Konfigurationen. Das Regelwerk, wer was zu sehen bekommt, ist Bestandteil der Konfiguration. Es muss also administrativ sichergestellt sein, dass auf allen DNS-Servern eine Zone konsistent ist.
Damit stellt sich die Frage, welche Alternativen es gibt. Eine, die man sogar bei Microsoft Azure finden kann, besteht darin, mehrere Primary Master mit unterschiedlichen Zonendateien bereitzustellen. Beispielsweise einen in der DMZ für den Zugriff aus dem Internet und einen in der internen Umgebung. Allerdings bestehen die oben beschriebenen Gefahren damit weiterhin.
Es ist eine gängige Alternative, gleich mit unterschiedlichen Domains zu arbeiten: eine für intern und eine für extern. Beispielsweise comconsult.de für den internen Gebrauch, comconsult.com für den externen. Der Nachteil dieses Vorgehens ist, dass es Systeme geben kann, die sowohl intern als auch extern angesprochen werden, vom Internet kommend jedoch durch ein NAT-Gateway erreichbar sind. Zum Beispiel soll der Mailserver intern wie extern erreichbar sein. Intern hat er die IP-Adresse 10.10.10.25, extern die IP-Adresse des NAT-Gateways. Da man den Mailclients für gewöhnlich nur einen Namen für den Mailserver nennt, hat man nun ein Problem, das man mit Split-DNS nicht hätte.
Fazit
Split-DNS kann helfen, bestimmte Probleme bei der Namensauflösung zu meistern. Jedoch sollte man lieber in homöopathischen Dosen davon Gebrauch machen und überlegen, ob es nicht einfachere Lösungen gibt.
Teile diesen Eintrag