Split-DNS für Exchange-Umgebungen
Dieser Artikel erklärt, was Split-DNS ist, in welchen Szenarien es zum Einsatz kommt und welche Bedeutung es für Exchange On-Premises, Exchange Hybrid und Exchange Online hat. Er dient als konzeptionelle Grundlage, auf die andere KB-Artikel zu AutoDiscover, Zertifikaten und Namespace-Design verweisen können.
Grundlagen Split-DNS
Split-DNS, manchmal auch Split-Brain-DNS genannt, bezeichnet eine DNS-Konfiguration, bei der für dieselbe Domain oder denselben Namespace je nach Quelle unterschiedliche Antworten geliefert werden. Aus dem internen Netzwerk und aus dem Internet. Technisch wird das meist in zwei getrennten Zonen realisiert. Eine interne Zone, die auf den internen DNS-Servern gehostet wird und nur für Clients im Firmennetzwerk erreichbar ist, sowie eine externe Zone, die öffentlich über das Internet auflösbar ist und beim externen DNS-Provider liegt.
Der entscheidende Punkt ist, dass beide Zonen denselben Domainnamen verwenden können, aber unterschiedliche IP-Adressen oder CNAME-Ziele zurückgeben. Ein Client im internen Netz, der zum Beispiel mail.contoso.com auflöst, bekommt eine interne IP-Adresse, während derselbe Name von außen auf eine öffentliche IP-Adresse oder einen Reverse-Proxy zeigt.
Anwendungsfälle
Split-DNS wird unabhängig von Exchange in vielen Szenarien eingesetzt, ist jedoch insbesondere im Exchange-Umfeld relevant.
Die wichtigsten Anwendungsfälle sind AutoDiscover, bei dem interne und externe Clients denselben AutoDiscover-Namespace verwenden sollen, aber unterschiedliche Endpunkte erreichen müssen. Ein weiterer Fall ist der einheitliche Namespace für OWA, ECP, EWS und ActiveSync, damit Nutzer unabhängig vom Standort dieselbe URL verwenden können, ohne dass sich für sie etwas ändert.
Split-DNS vermeidet außerdem Hairpin-NAT, also die Situation, in der ein interner Client über die öffentliche IP-Adresse auf einen Dienst zugreifen will, der eigentlich im selben Netzwerksegment steht, und die Anfrage dabei unnötig über die Firewall nach außen und wieder zurückgeleitet werden müsste.
Bedeutung für Exchange On-Premises
In einer reinen On-Premises-Umgebung ist Split-DNS meist die Grundlage für ein sauberes Namespace-Design. Typischerweise wird ein einheitlicher externer Namespace wie mail.contoso.com für AutoDiscover und alle Client-Zugriffsprotokolle verwendet. Intern zeigt derselbe Name idealerweise auf ein internes Load-Balancer-VIP oder direkt auf die Exchange-Server, während er extern auf die öffentliche IP des Reverse-Proxys oder der Firewall zeigt.
Wichtig ist hier das Zusammenspiel mit dem SAN-Zertifikat auf den Exchange-Servern. Da intern und extern derselbe Name verwendet wird, reicht ein Zertifikat mit diesem einen Namen aus, es müssen keine zusätzlichen internen Namen wie der interne FQDN der Exchange-Server im Zertifikat enthalten sein, sofern Outlook Anywhere korrekt konfiguriert ist und keine Legacy-Verbindungsmethoden mehr verwendet werden.
Bedeutung für Exchange Hybrid
In Hybrid-Szenarien gewinnt Split-DNS noch mehr an Bedeutung, weil hier zusätzlich die AutoDiscover-Weiterleitung zwischen On-Premises und Exchange Online eine Rolle spielt. Für Postfächer, die bereits in Exchange Online liegen, muss der AutoDiscover-Request letztlich bei Microsoft 365 landen, während für On-Premises-Postfächer weiterhin der lokale AutoDiscover-Endpunkt zuständig ist. Diese Steuerung erfolgt in der Regel über den SCP-Eintrag im Active Directory für interne Clients sowie über den öffentlichen DNS-Eintrag oder die AutoDiscover-Weiterleitung für externe Clients.
Eine typische Stolperfalle in Hybrid-Umgebungen ist, dass die interne Split-DNS-Zone veraltete Einträge enthält, die noch auf den alten On-Premises-AutoDiscover-Endpunkt verweisen, obwohl bereits alle Postfächer migriert wurden. Das führt dazu, dass interne Clients unnötig über den On-Premises-Server geroutet werden, was Latenz und in manchen Fällen sogar Fehlermeldungen bei der Profilerstellung verursachen kann.
Bedeutung für Exchange Online
Für reine Exchange-Online-Umgebungen ohne Hybrid-Anbindung ist Split-DNS in der klassischen Form meist nicht mehr notwendig, da es keine interne Exchange-Infrastruktur mehr gibt, die intern anders erreichbar sein müsste als extern. Trotzdem kann Split-DNS auch hier eine Rolle spielen, etwa wenn Unternehmen aus Compliance- oder Netzwerksicherheitsgründen den Datenverkehr zu Microsoft 365 über bestimmte Proxy- oder Firewall-Pfade lenken wollen und dafür interne DNS-Einträge für Namen wie outlook.office365.com anpassen.
Solche Eingriffe sind in der Praxis selten sinnvoll und sollten nur mit Bedacht und in Abstimmung mit Microsofts Empfehlungen zu Netzwerkkonnektivität erfolgen, da sie leicht zu Performance-Problemen führen können.
Zuständigkeiten und Abstimmung
Ein Punkt, der in der Praxis häufig unterschätzt wird, ist die organisatorische Zuständigkeit für DNS. In vielen Unternehmen liegt die Verwaltung der internen und externen DNS-Zonen nicht beim Exchange-Team, sondern bei einem separaten Netzwerk- oder Infrastrukturteam. Änderungen an Split-DNS-Einträgen, etwa das Anlegen eines neuen internen AutoDiscover-Eintrags oder die Anpassung eines bestehenden CNAME-Eintrags, können sich auf andere Dienste auswirken, die denselben Namespace oder dieselbe Zone nutzen. Bevor du also Änderungen an der Split-DNS-Konfiguration planst oder umsetzt, sprich das grundsätzlich mit dem zuständigen DNS- oder Netzwerkteam ab. Das gilt besonders für Änderungen an TTL-Werten, da diese die Geschwindigkeit auswirken, mit der eine spätere Korrektur wirksam wird, sowie für die Einführung komplett neuer interner Zonen.
Bekannte Probleme
Ein häufiges Problem ist, dass die interne Zone nach Migrationen oder Serverwechseln nicht aktualisiert wird und dadurch veraltete Einträge bestehen bleiben. Auch DNS-Caching auf Client-Seite oder auf zwischengeschalteten Resolvern kann dazu führen, dass Änderungen scheinbar nicht wirken, obwohl die Zone bereits korrekt angepasst wurde. In Hybrid-Umgebungen kommt es zudem vor, dass die interne Zone versehentlich Einträge für Dienste enthält, die eigentlich zu Exchange Online geroutet werden sollten, was zu inkonsistentem Verhalten zwischen unterschiedlichen Clients führen kann, je nachdem, ob sie sich im internen Netz befinden oder nicht.