Dieser Artikel ist der erste Teil einer mehrteiligen Serie zum Thema Netzwerkvoraussetzungen bei Microsoft 365. Part 1 beschäftigt sich mit dem Thema Namensauflösung.
Eine gut funktionierende Namensauflösung bei den Microsoft 365 Diensten ist unumgänglich für einen reibungslosen Betrieb der Microsoft Dienste. In diesem Artikel erkläre ich anhand von ein paar Beispielen, worauf speziell zu achten ist.
Normalerweise möchte man sich bei der Nutzung von Cloud Diensten keine Gedanken um das Thema Netzwerk machen. Man kauft ja schließlich fertige Dienste ein, bei denen der Anbieter schon dafür sorgt, dass Netzwerkseitig alles passt. Oft braucht man das auch nicht, da in kleineren Firmen das Netzwerk nicht sehr komplex ist und es keine Besonderheiten gibt, die einem Probleme machen können. Es gibt aber Firmennetzwerke, die einen ausführlichen Blick auf das Thema Netzwerk benötigen. Ein aktuelles Projekt brachte mich dazu, das Thema Netzwerk sehr viel genauer zu betrachten, als es in Vergangenheit nötig war. Meine Erfahrungen daraus möchte ich in diesem Artikel vertiefen.
DNS-Auflösung
Um ein Ziel im „Internet“ zu erreichen, muss der Client zunächst wissen, welchen Server er ansprechen muss. Die Hostnamen der Microsoft 365 Dienste müssen deshalb über einen DNS-Server auf die entsprechende IP-Adresse übersetzt werden. Bei einfachen Webseiten gibt es normalerweise keine Besonderheiten. Zu meinem Blog gibt es genau eine IP-Adresse des entsprechenden Webservers. Alle Anfragen, egal von wo aus der Welt diese kommen, werden zum selben Webserver mit derselben IP-Adresse geschickt.
In größeren Cloud-Konstrukten ist dies aber anders. Auf jedem Kontinent stehen mehrere Rechenzentren von Microsoft, welche die Services für Kunden bereithalten. Die Verbindung zum Exchange Online Mailserver läuft aber immer über den Hostnamen outlook.office.com.
Jetzt muss per Geo-DNS der am besten zu erreichende Server dem Client zurückgemeldet werden. Was dabei eine nicht optimale DNS-Abfrage für Folgen haben kann, möchte ich anhand von zwei Beispielen erläutern.
Der Optimalfall
Gehen wir zunächst von einem für Cloud Dienste optimalen Fall aus. Wir denken an eine kleine Firma mit vielleicht 30-50 Mitarbeitern und einem einzelnen Büro. Das Büro hat ein VLAN und einen Internetzugang. Alle Clients erhalten per DHCP vom Router ihre IP-Konfiguration und so werden alle DNS-Abfragen über den DNS-Server des Internetproviders abgehandelt. Die Mitarbeiter im Homeoffice benötigen kein VPN, da bereits alle Dienste über Microsoft 365 genutzt werden. Es gibt nur eine einfache Firewall, und der ausgehende Internetzugang ist nicht reglementiert. Der Begriff Proxyserver wurde bislang von niemandem im Unternehmen in den Mund genommen.
Wie verhalten sich nun die Cloud Dienste?
Hier wird es vermutlich keine Probleme geben. Da die Clients über den DNS-Server des Internetproviders die Hostnamen der entsprechenden Microsoft 365 Endpunkte auflösen, werden die naheliegendsten IP-Adressen vom Microsoft Rechenzentrum aufgelöst. Im Optimalfall gibt es vom Internetprovider direkt ein Peering zum Microsoft Global Network (MGN), sodass die Datenpakete nicht mehr über ein öffentliches Peering laufen, sondern direkt zu Microsoft geroutet werden. Dies spart Hops und sorgt für geringe Latenzen. Hier ein Beispiel von meinem Internetanschluss aus:
In diesem Tracert sieht man gut, dass outlook.office.com auf eine IP-Adresse in Frankfurt am Main aufgelöst wird. Hop 3-6 sind IP-Adressen meines Internetproviders (Vodafone). Ab Hop 7 gehen die Anfragen in Düsseldorf ins MGN und von dort aus über eigene Glasfaserstrecken von Microsoft ins Microsoft RZ in Frankfurt am Main.
Mein Provider hat demnach ein direktes Peering zu Microsoft. Viel kürzer können an einem privaten Internetanschluss die Datenpakete nicht bei Microsoft landen. Insgesamt 13ms vergehen, bis die Datenpakete am zuständigen Server angekommen sind.
Unternehmen mit mehreren globalen Standorten
Aber wo kann es jetzt Probleme geben? Denken wir nun an ein global agierendes Unternehmen. Der Firmensitz und somit auch die IT-Verantwortlichen sind in Australien beheimatet. Es gibt jedoch ein Büro in Düsseldorf. Da auch viele interne Server per VPN angesprochen werden müssen, wird der DNS-Server der VPN Appliance genutzt. Das VPN ist als Split-Tunnel konfiguriert. Es werden also nur die Anfragen an interne (per VPN erreichbare) Ressourcen durch den VPN-Tunnel geroutet. Die DNS Auflösung geht aber in jedem Fall an den DNS-Server am Firmenhauptsitz in Australien, damit die internen Hostnamen der über VPN erreichbaren Server aufgelöst werden können. Was soll da schon schiefgehen?
Nunja, das sieht man recht schnell mit einem erneuten Tracert auf die Adresse, die vom DNS-Server in Australien zurückgegeben wird. Der Name lässt es bereits vermuten, der Microsoft Server befindet sich in Sydney.
Im Vergleich zum ersten Beispiel sieht man schnell, dass die Datenpakete deutlich länger unterwegs sind. Zwar landen diese vom gleichen Internetanschluss auch ab Hop 7 im MGN, brauchen dann aber ca. 250ms länger, bis der Zielserver in Sydney erreicht wird. Der Weg bis nach Sydney ist halt doch etwas länger… Zwischen Hop 8 und 9 liegt vermutlich ein Seekabel zwischen Europa und Australien.
Öffentliche DNS-Server
Viele Netzwerkadministratoren setzen gerne DNS-Server wie z.B. 8.8.8.8, 9.9.9.9 oder 1.1.1.1 ein. Diese DNS-Server sind zwar sehr performant, können aber die Namensauflösung stören, wenn es um das Finden des am schnellsten zu erreichenden Servers über das MGN geht. Der DNS-Server des Internetproviders ist stets vorzuziehen.
Hier habe ich zwei DNS-Abfragen gemacht. Zunächst über die quad9 DNS-Server, und danach über den DNS-Server meines Routers, der an den DNS-Server meines Internetanbieters weiterleitet. Man sieht schön, wie unterschiedlich die DNS-Antworten sind. Die erste Antwort kommt von einem Microsoft DNS-Server aus Amsterdam, die zweite von einem Microsoft DNS-Server aus Hessen (Frankfurt).
Lessons Learned
Was lernen wir daraus? Jede Dependance eines Unternehmens sollte stets die DNS-Auflösung des lokalen Internetanbieters bzw. Internet Breakouts nutzen, um die Pakete auch zum richtigen (besten) Zielserver zu senden. Firmen, die interne WANs nutzen, müssen spätestens mit Einführung von Cloud-Diensten umdenken. Microsoft hat schließlich nicht umsonst mehrere Rechenzentren weltweit in Betrieb. Diesen Vorteil sollte man auch nutzen und nicht durch falsche DNS-Abfragen zunichtemachen.
