Split-DNS für Microsoft-365-Hybrid: DNS-Design hinter der Sophos, das nicht wehtut

Halb Hybrid, halb Chaos — so fühlen sich viele Microsoft-365-Umgebungen an, wenn die Namensauflösung nie sauber durchdacht wurde: Autodiscover findet intern etwas anderes als extern, Outlook wirft Zertifikatswarnungen, und interner Verkehr nimmt absurde Umwege über die Firewall. Die Kurzantwort vorab: Die Lösung heißt Split-DNS (auch Split-Brain-DNS) — derselbe Name bekommt intern und extern unterschiedliche, jeweils ehrliche Antworten: mail.firma.de zeigt draußen auf die öffentliche IP der XGS-WAF, drinnen direkt auf den Exchange. Richtig gebaut verschwinden damit drei Plagen auf einen Schlag: die Zertifikatswarnungen (interne Clients sprechen endlich den Namen, der im öffentlichen Zertifikat steht), das Hairpinning (interner Verkehr macht keinen U-Turn mehr an der Firewall) und das Autodiscover-Roulette. Dieser Artikel liefert das Zielbild, die Umsetzung auf Windows-DNS und der XGS — die hier eine ehrliche Nebenrolle spielt —, die kritischen Einträge im Detail und die Diagnose-Werkzeuge, mit denen du das Design systematisch beweist statt hoffst.

Warum Microsoft-365-Hybrid-Umgebungen Split-DNS fast immer brauchen

Der Kern des Problems ist eine Kollision zweier Welten am selben Namen. Welt eins: Von außen muss mail.firma.de auf die öffentliche IP zeigen, hinter der die XGS-WAF den Exchange veröffentlicht — das ist die Publishing-Architektur aus [LINK: B4], und sie ist für Externe genau richtig: Jeder Zugriff läuft durch den bewachten Eingang. Welt zwei: Von innen wäre exakt dieser Weg Unsinn — der Client steht zwei Switch-Ports vom Server entfernt und soll trotzdem erst zur öffentlichen Adresse hinaus und per Kehrtwende wieder hinein? Dazu kommt die Zertifikatsfrage, die das Thema von der Kür zur Pflicht macht: Öffentliche Zertifizierungsstellen stellen seit Jahren keine Zertifikate mehr auf interne Namen aus (server01.firma.local ist nicht bescheinigungsfähig), weshalb die Exchange-Dienst-URLs im Hybrid durchgängig auf öffentliche Namen wie mail.firma.de umgestellt sind — auch für interne Clients. Sprechen interne Clients nun den Servernamen an, hagelt es Warnungen; sprechen sie den öffentlichen Namen ohne interne Auflösung an, landen sie beim U-Turn.

Split-DNS löst beide Konflikte mit einem Prinzip: Ein Name, zwei Antworten — jede für ihr Publikum die richtige. Die interne Zone antwortet den eigenen Clients mit der internen Server-IP (direkter Weg, passendes Zertifikat, volle LAN-Geschwindigkeit), die öffentliche Zone antwortet der Welt mit der WAF-Adresse (bewachter Eingang, alle Schutzmechanismen). Wichtig für die Einordnung: Das ist kein Trick und keine Bastellösung, sondern seit jeher das von Microsoft vorausgesetzte Design für Hybrid-Umgebungen — praktisch jede Exchange-Hybrid-Anleitung nimmt stillschweigend an, dass es existiert. Die Skizze zeigt beide Pfade nebeneinander; der Rest des Artikels baut sie.

Skizze 1: Derselbe Name, zwei ehrliche Antworten — intern der kurze Weg mit passendem Zertifikat, extern der bewachte Eingang über die XGS-WAF.

Zielbild: welche Namen intern anders auflösen müssen

Bevor Zonen entstehen, gehört die Liste auf den Tisch: Welche Namen brauchen überhaupt eine interne Sonderantwort? Die Antwort ist erfreulich kurz, und genau das ist die Design-Botschaft — Split-DNS ist ein Skalpell, keine Kettensäge. Split-brain gehören ausschließlich Namen, deren Dienst intern unter anderer Adresse erreichbar ist als extern: der Exchange-Zugangsname (mail.firma.de), Autodiscover — und, in der Praxis oft vergessen, der Webauftritt samt Domänen-Apex, sobald die interne Zone die komplette Domain abbildet (dazu gleich mehr). Ausdrücklich nicht split-brain gehören Namen, die ohnehin in die Cloud zeigen: Die SIP-CNAMEs, der MX, die Verifizierungs- und Dienst-Einträge von Microsoft 365 — sie lösen intern wie extern auf dieselben Microsoft-Ziele auf, und jede interne Kopie wäre nur eine zusätzliche Fehlerquelle. Der Faktenkasten destilliert die drei Pflicht-Kandidaten; die Detailbehandlung je Eintragstyp folgt im vierten Kapitel.

Umsetzung auf Windows-DNS und der XGS

In AD-Umgebungen ist der Ort der Umsetzung gesetzt: die Windows-DNS-Server der Domänencontroller, denn dort fragen die Clients ohnehin. Für den Bau gibt es zwei Wege, die die Skizze gegenüberstellt. Weg A ist die komplette Schattenzone: eine interne, autoritative Zone firma.de, in der die Sondernamen intern zeigen und alle übrigen öffentlichen Einträge als Kopie nachgepflegt werden. Dieser Weg ist unvermeidbar, wenn die AD-Domäne selbst firma.de heißt — dann existiert die Zone konstruktionsbedingt, und es hilft kein Jammern: Ab jetzt gewinnt sie jede interne Anfrage zur Domain, und jede Änderung an der öffentlichen Zone (neuer Hoster fürs Web, neuer Shop, neuer Dienst) muss intern nachgezogen werden — ein Pflege-Abo auf Lebenszeit, dessen vergessene Raten der Praxis-Kasten illustriert. Weg B ist das Skalpell: Pinpoint-Zonen — je eine Mini-Zone exakt für den einen Namen (Zone »mail.firma.de« mit einem einzigen A-Eintrag auf gleicher Ebene). Alles andere läuft unangetastet an die öffentliche Auflösung durch. Wenn die AD-Domäne anders heißt (firma.local, corp.firma.de), ist das die klar bessere Bauweise: minimale Pflege, kein Abo.

Und die XGS? Die spielt eine ehrliche Nebenrolle, und die hat zwei Bühnen. Bühne eins: als Glied der Auflösungskette — die Domänencontroller können die XGS als Weiterleitungsziel nutzen, und deren DNS-Anfragen-Routing erlaubt saubere bedingte Weiterleitungen je Domäne (praktisch etwa für Namen, die durch den Azure-Tunnel zu Cloud-Ressourcen aufgelöst werden müssen — das Zusammenspiel mit der VNet-Welt behandelt der Azure-Artikel). Bühne zwei: als DNS-Antwortgeber für Netze ohne Windows-DNS — Gastnetz, DMZ, Geräte-VLANs; dort helfen die lokalen DNS-Hosteinträge der XGS, einzelne Namen intern korrekt zu beantworten, ohne gleich einen Server hinzustellen. Was die XGS dagegen nicht sein sollte: der primäre DNS für domänengebundene Clients — die gehören an die DCs, schon wegen der AD-eigenen Dienste-Einträge. Kurz: Windows-DNS ist die Hauptbühne, die XGS der nützliche Nebendarsteller.

Skizze 2: Schattenzone (Pflege-Abo, aber unvermeidbar bei AD-Domäne = öffentliche Domain) gegen Pinpoint-Zonen (chirurgisch, erste Wahl bei getrennten Namensräumen).

Autodiscover, MX und SIP-Einträge im Detail

Jetzt die Einzelbetrachtung der Einträge, die im Hybrid regelmäßig Fragen aufwerfen — die Tabelle fasst sie zusammen. Autodiscover ist der wichtigste und empfindlichste: Extern zeigt autodiscover.firma.de als A-Eintrag auf die WAF (der Pfad ist veröffentlicht und für Cloud wie Clients erreichbar, siehe Publishing-Artikel), intern als Split-brain-Eintrag direkt auf den Exchange. Die klassischen Fehlerbilder bei kaputtem internem Autodiscover: Outlook-Profile lassen sich intern nicht einrichten, obwohl es extern klappt, oder der Client fischt sich über die Ausweichlogik eine unpassende Quelle und produziert Zertifikatswarnungen. Der MX dagegen ist ein reiner Außen-Eintrag: Er gehört in die öffentliche Zone und zeigt im Standard-Setup auf Exchange Online — die komplette Mailfluss-Logik dazu steht in [LINK: B5]; intern braucht ihn niemand, denn der Exchange stellt per Smarthost zu, nicht per MX-Abfrage. Nur die Schattenzonen-Fahrer sollten ihn der Vollständigkeit halber intern spiegeln, damit Diagnosewerkzeuge intern wie extern dasselbe Bild zeigen.

Die SIP-Einträge schließlich sind ein Fall fürs Aufräumen mit Augenmaß: sip.firma.de und lyncdiscover.firma.de stammen aus der Skype-for-Business-Ära und zeigen als CNAMEs auf Microsofts Cloud-Ziele — sie sind intern wie extern identisch, brauchen also ausdrücklich kein Split-brain, und in reinen Teams-Umgebungen sind sie meist nur noch historisches Inventar, das niemandem wehtut, solange es korrekt in die Cloud zeigt. Die Gefahr lauert auch hier nur in der Schattenzone: Fehlen die CNAMEs intern, verhalten sich alte Clients und Prüfwerkzeuge drinnen anders als draußen — wieder das Nachpflege-Abo. Generell gilt für alle Cloud-Zeiger: Eine Wahrheit genügt, und die wohnt draußen — intern nur spiegeln, wenn die Zonen-Bauweise es erzwingt.

Hairpinning vermeiden

Was passiert eigentlich, wenn Split-DNS fehlt und der interne Client die öffentliche Adresse bekommt? Dann entsteht das Hairpinning, benannt nach der Haarnadelkurve: Das Paket läuft vom Client zur Firewall (Ziel: die eigene öffentliche IP), die XGS muss es per NAT-Kehrtwende zurück ins selbe LAN drehen — sofern NAT-Reflexion überhaupt konfiguriert ist, denn ohne sie endet der Versuch schlicht im Nichts, was das Fehlerbild »geht von draußen, aber nicht von drinnen« erklärt. Funktioniert die Reflexion, bleibt ein Verkehrsmuster mit drei eingebauten Ärgernissen: Jedes Byte quert das LAN doppelt und die Firewall komplett, die Firewall wird zum Flaschenhals für Verkehr, der sie nichts anginge, und der Server sieht als Absender die Firewall statt des Clients. Die Skizze stellt U-Turn und Direktweg gegenüber; der Faktenkasten liefert die Zahlen für die Diskussion mit dem Kollegen, der findet, »funktioniert doch«.

Skizze 3: Links der U-Turn mit NAT-Reflexion als Dauerprovisorium, rechts der Direktweg per Split-DNS — die Firewall sieht internen Verkehr gar nicht erst.

Test- und Diagnosewerkzeuge

Ein DNS-Design beweist man, man glaubt es nicht — und die Beweisführung ist dankbar simpel, weil sie mit Bordmitteln auskommt. Das Grundmuster jeder Prüfung: dieselbe Frage zweimal stellen — einmal an den internen DNS (den die Clients nutzen), einmal explizit an einen öffentlichen Resolver — und die Antworten vergleichen. Für die Split-brain-Namen müssen sie sich unterscheiden (intern die Server-IP, extern die WAF-Adresse), für alle Cloud-Zeiger müssen sie identisch sein; jede Abweichung von diesem Muster ist ein Befund. Dazu kommen die funktionalen Proben: die Zertifikatsprüfung im Browser gegen den internen Namen (erscheint das öffentliche Zertifikat ohne Warnung?), die Outlook-Autokonfigurationsprüfung über das Tray-Symbol (welche URLs findet der Client wirklich?) und von außen der Remote Connectivity Analyzer als externe Gegenprobe. Die Tabelle liefert die Kommandos samt Erwartungswerten — gebaut als Abnahme-Checkliste: einmal komplett nach der Einrichtung, danach die betroffenen Zeilen bei jeder Änderung.

FAQ — häufige Fragen zu Split-DNS im Microsoft-365-Hybrid

Was ist Split-DNS und wann brauche ich es?

Split-DNS (auch Split-Brain- oder Split-Horizon-DNS) bedeutet: Derselbe Name wird intern und extern unterschiedlich beantwortet — jeweils mit der für das Publikum richtigen Adresse. Extern zeigt mail.firma.de auf die öffentliche IP, hinter der die Firewall den Dienst veröffentlicht; intern zeigt derselbe Name direkt auf den Server im LAN. Brauchen tust du es immer dann, wenn ein Dienst unter seinem öffentlichen Namen auch von innen genutzt wird und intern unter anderer Adresse erreichbar ist — im Microsoft-365-Hybrid also praktisch immer, denn die Exchange-URLs laufen zwingend auf öffentlichen Namen (interne Namen sind nicht mehr zertifizierbar), und ohne interne Sonderantwort erzeugen die eigenen Clients entweder Zertifikatswarnungen oder Hairpin-Verkehr über die Firewall. Die ehrliche Abgrenzung: Wer keinerlei On-Prem-Dienste unter öffentlichen Namen betreibt, braucht kein Split-DNS — eine Wahrheit genügt. Für alle anderen ist es kein Extra, sondern das von Microsoft stillschweigend vorausgesetzte Fundament des Hybrid-Designs.

Sollte die Sophos XGS als DNS-Server dienen?

Als Hauptdarsteller: nein — als Nebendarsteller: gern. In AD-Umgebungen gehören die Clients an die Windows-DNS-Server der Domänencontroller, denn dort leben die AD-Dienste-Einträge, ohne die Anmeldung und Gruppenrichtlinien nicht funktionieren; die Split-brain-Zonen wohnen konsequenterweise ebenfalls dort. Die XGS hat in dieser Kette zwei sinnvolle Rollen: Erstens als Weiterleitungsglied — die DCs können sie als Forwarder nutzen, und ihr DNS-Anfragen-Routing erlaubt bedingte Weiterleitungen je Domäne, etwa für Namen, die durch den Azure-Tunnel aufgelöst werden müssen. Zweitens als Antwortgeber für Netze ohne Windows-DNS: Im Gastnetz, in Geräte-VLANs oder der DMZ helfen die lokalen DNS-Hosteinträge der XGS, einzelne interne Namen korrekt zu beantworten, ohne dafür einen Server bereitzustellen. Vermeiden sollte man zweierlei: domänengebundene Clients direkt auf die XGS zu zeigen (AD-Funktionen leiden) und die Split-brain-Logik über Firewall-Hosteinträge statt ordentlicher Zonen abzubilden. Kurz: Windows-DNS baut das Design, die XGS rundet es ab.

Warum bekommen interne Clients Zertifikatswarnungen?

Weil Name und Zertifikat nicht zusammenpassen — und dafür gibt es im Hybrid zwei Standardwege. Weg eins: Der Client spricht den Server unter einem internen Namen an (servername.firma.local oder die nackte IP), das präsentierte Zertifikat lautet aber auf mail.firma.de — öffentliche CAs stellen auf interne Namen schlicht nichts mehr aus, also kann der interne Name nie im Zertifikat stehen. Die Ursache sitzt dann meist in den Exchange-Dienst-URLs, die nicht vollständig auf den öffentlichen Namen umgestellt wurden, oder in einem Autodiscover, das intern die falsche Quelle findet. Weg zwei: Der Client spricht zwar den richtigen Namen, landet aber am falschen Endpunkt — etwa weil ohne Split-DNS die öffentliche Adresse angesteuert wird und unterwegs ein Gerät mit anderem Zertifikat antwortet. Die Diagnose-Reihenfolge: erst per Browser prüfen, welches Zertifikat intern unter https://mail.firma.de erscheint, dann per Outlook-Autokonfigurationstest die tatsächlich verteilten URLs ansehen, zuletzt per nslookup die interne Auflösung klären. In neun von zehn Fällen ist danach klar, ob URLs, Autodiscover oder die fehlende interne Zone der Täter ist.

Wie löse ich autodiscover intern korrekt auf?

Das Standardrezept: ein interner A-Eintrag autodiscover.firma.de auf die interne Exchange-IP — als Pinpoint-Zone, wenn die AD-Domäne anders heißt, oder als Eintrag in der ohnehin vorhandenen Schattenzone. Damit findet jeder interne Client (und jedes Diagnose-Werkzeug) den Wegweiser auf dem kurzen Weg, das öffentliche Zertifikat passt, und die externe Auflösung auf die WAF bleibt davon unberührt. Dazu gehören zwei flankierende Prüfungen: Erstens müssen die Exchange-Dienst-URLs konsistent auf den öffentlichen Namen zeigen — ein korrekter DNS-Eintrag hilft wenig, wenn Autodiscover anschließend URLs mit internem Servernamen verteilt. Zweitens der Domänen-Apex-Klassiker: Clients probieren in ihrer Suchlogik auch https://firma.de/autodiscover — zeigt der Apex intern auf etwas Unerwartetes (bei Schattenzonen gern die Domänencontroller!), fangen sich Clients dort Umwege oder Warnungen. Der Beweis ist zweiteilig: intern die Outlook-Autokonfigurationsprüfung, extern der Remote Connectivity Analyzer — erst wenn beide grün sind, ist Autodiscover wirklich fertig.

Was ist DNS-Hairpinning?

Hairpinning (auch NAT-Loopback oder NAT-Reflexion) ist der U-Turn interner Pakete an der eigenen Firewall: Ein interner Client löst einen Namen zur öffentlichen IP auf, schickt sein Paket also Richtung Internet-Kante — und die Firewall muss es per doppeltem NAT zurück ins selbe LAN drehen, aus dem es kam. Streng genommen ist das DNS-Problem die Ursache und das Hairpinning nur das Symptom: Der Client hat schlicht die falsche (nämlich die externe) Antwort bekommen. Die Nebenwirkungen: Ohne konfigurierte NAT-Reflexion scheitert der Zugriff komplett (»geht von draußen, aber nicht von drinnen«), mit ihr quert jedes Byte das LAN doppelt, die XGS wird zum Flaschenhals für Verkehr, der sie nichts anginge, und der Server sieht als Quelle die Firewall statt des Clients. Die richtige Reaktion ist deshalb fast nie »NAT-Reflexion einschalten«, sondern »Split-DNS bauen«: Die Reflexion bleibt als Notlösung für Geräte, die den internen DNS partout nicht nutzen — als Dauerzustand ist sie ein Provisorium mit Stromanschluss.

Wie teste ich mein DNS-Design systematisch?

Mit einem Prüfmuster und einer Checkliste statt mit Einzelaktionen nach Gefühl. Das Muster: jede relevante Frage doppelt stellen — einmal an den internen DNS, einmal explizit an einen öffentlichen Resolver (nslookup name 9.9.9.9) — und die Antworten gegen die Erwartung halten: Split-brain-Namen müssen sich unterscheiden, Cloud-Zeiger müssen identisch sein, und bei Schattenzonen müssen die gespiegelten Einträge (www, Apex) mit der öffentlichen Wahrheit übereinstimmen — jede Drift dort ist ein gefundener zukünftiger Vorfall. Dazu die Funktionsproben: Browser-Zertifikatscheck gegen den internen Namen, Outlook-Autokonfigurationsprüfung für die tatsächlich verteilten URLs, Remote Connectivity Analyzer als externe Gegenprobe. Und schließlich der Rhythmus: die komplette Checkliste einmal zur Abnahme, danach die betroffenen Zeilen bei jeder Änderung an Zonen, Zertifikaten oder Publishing — plus, bei Schattenzonen, der feste Haken im Domain-Änderungsprozess. Die Kommandotabelle ist genau dafür gebaut: ausdrucken, durchgehen, abhaken.

Fazit: Zwei Wahrheiten, sauber getrennt — und Ruhe im Hybrid

Split-DNS ist unspektakuläre Infrastruktur-Hygiene mit spektakulärer Wirkung: drei Namen intern richtig beantwortet, und auf einen Schlag verschwinden Zertifikatswarnungen, Autodiscover-Rätsel und der U-Turn-Verkehr, der die Firewall grundlos beschäftigt. Die Bauentscheidung ist binär: Pinpoint-Zonen als Skalpell, wo die AD-Domäne anders heißt — die Schattenzone samt Pflege-Abo, wo sie gleich heißt, dann aber mit dem Nachpflege-Haken fest im Domain-Prozess. Die XGS spielt ihre Nebenrolle als Weiterleitungsglied und Gastnetz-Antwortgeber, die Hauptbühne gehört dem Windows-DNS. Und der Beweis ersetzt den Glauben: doppelt fragen, vergleichen, abhaken. Ein halber Tag Design-Arbeit — und das Hybrid hört auf, an der Namensauflösung zu kränkeln.

Von hier aus weiter im Cluster: Das Gesamtbild der XGS in Microsoft-Umgebungen zeichnet der Pillar-Artikel [LINK: Pillar]. Wohin die externe Antwort führt — die WAF-Publishing-Architektur samt Pfaden und Zertifikaten — steht in [LINK: B4]. Warum der MX in die Cloud zeigt und wie der Mailfluss drumherum funktioniert, behandelt [LINK: B5]. Und wie die Namensauflösung durch den Azure-Tunnel in Richtung VNet-Ressourcen weitergeht, klärt [LINK: B6].