Office 365: DNS-Routing
Wer Office 365 nutzen will, muss die Namen per DNS zu IP-Adressen auflösen können. Das betrifft den Client selbst oder einen HTTP-Proxy. Aber auch die einfache Namensauflösung kann trickreich und für eine schlechte Leistung verantwortlich sein, wenn Fehler passieren, die auf den ersten Blick gar nicht ersichtlich sind. Denn Microsoft optimiert die DNS-Antworten abhängig von der IP-Adresse des anfragenden Clients. Am einfachsten ist dies mit Beispielen zu erläutern.
Korrekte Konfiguration
Der Client fragt über den Zugangsprovider per DNS bei Microsoft nach, so dass Microsoft die „Source-IP“ des Providers sehen kann
Entsprechend den „nahegelegenen“ Übergangspunkt ins Microsoft Global Network liefert:
Fehler: Fremd-DNS statt Provider-DNS
Leider hat es sich immer häufiger eingebürgert, dass Firmen oder Personen nicht den DNS-Server ihres Providers erfragen sondern z.B. den Google-Services (8.8.8.8/8.8.4.4) als DNS-Forwarder nutzen.
Nun sieht Microsoft die Anfrage aus einem anderen Netz kommen und liefert eine IP-Adresse als Antwort, die „nahe am Google-DNS“-Server steht. Das ist aber nicht der beste Server für ihre Anbindung
Fehler: Zentral-DNS trotz lokalem Breakout
Für die Nutzung von Office 365 ist es am Besten den kurzen direkten Weg zu nutzen. Wenn eine Firma nun mehrere Standorte hat, dann sind dezentrale Internetausgänge zumindest für die Office 365-Ziele ratsam. Das erfordert aber auch eine entsprechende Namensauflösung. Unschön ist folgende Konstellation:
Das hilft natürlich nicht, wenn der Client in der Niederlassung doch wieder die zentralen DNS-Dienste zur Auflösung nutzt und den Zugang bekommt, der für die Zentrale optimal ist. Der Datenverkehr nutzt dann aber vielleicht den „falschen“ Weg.
Besser: Dezentraler Breakout mit dezentralem DNS
Daher sollte ein dezentraler Breakout auch immer damit verbunden sein, dass die Auflösung der Office 365-Ziele auch dezentral erfolgt.
Abhängig vom Standort sollten Sie also genau
Beispiel DNS
Um die "Auswirkungen" zu zeigen, habe ich von meinem Heimanschluss (Telekom-DSL) drei Mal eine Auflösung gestartet und dabei zuerst meinen DSL-Router genutzt, der sicher den per DHCP zugewiesenen Provider-DNS-Server fragt und dann einmal den "Google-DNS" und einmal den Quad9-DNS Service nach "Outlook.office365.com" befragt und danach einen Traceroute auf die erste IPv4-Adresse gemacht bis zum ersten Zugangspunkt des MGN - Microsoft Global Network.
DNS-Provider | Telekom-DNS | Google (8.8.8.8) | Quad9 (9.9.9.9) |
---|---|---|---|
Antwort |
C:\>nslookup outlook.office365.com Server: fritz.box Address: 192.168.178.1 Nicht autorisierende Antwort: Name: outlook.ms-acdc.office.com Addresses: 2603:1026:203:4f::2 2603:1026:205:15::2 2603:1026:203:8b::2 2603:1026:203:8c::2 40.101.60.226 40.101.9.178 40.101.61.114 40.101.124.210 Aliases: outlook.office365.com outlook.ha.office365.com |
C:\>nslookup outlook.office365.com 8.8.8.8 Server: google-public-dns-a.google.com Address: 8.8.8.8 Nicht autorisierende Antwort: Name: outlook-emeacenter.office365.com Addresses: 2603:1026:200:3c::2 2603:1026:300:ca::2 2603:1026:7:15::2 2603:1026:500:62::2 2603:1026:500:3e::2 2603:1026:203:3b::2 2603:1026:300:e0::2 2603:1026:500:61::2 40.100.174.226 40.100.172.242 40.100.173.50 40.100.174.210 Aliases: outlook.office365.com outlook.ha.office365.com outlook.office365.com.g.office365.com |
C:\>nslookup outlook.office365.com 9.9.9.9 Server: dns.quad9.net Address: 9.9.9.9 Nicht autorisierende Antwort: Name: outlook-emeaeast2.office365.com Addresses: 2603:1026:7:7c::2 2603:1026:300:78::2 2603:1026:7:7d::2 2603:1026:301::2 2603:1026:205::2 2603:1026:4:50::2 2603:1026:6:29::2 2603:1026:203:8d::2 40.101.61.130 40.101.84.2 40.101.69.2 40.96.24.146 40.101.84.18 40.101.124.2 40.101.43.162 40.101.72.130 Aliases: outlook.office365.com outlook.ha.office365.com outlook.office365.com.g.office365.com |
Tracert |
C:\>tracert 40.101.60.226 Routenverfolgung zu 40.101.60.226 über maximal 30 Hops: 1 2 ms 1 ms <1 ms fritz.box [192.168.178.1] 2 5 ms 5 ms 5 ms 62.155.242.220 3 11 ms 11 ms 11 ms 217.5.118.50 4 12 ms 12 ms 13 ms 62.157.250.70 5 21 ms 20 ms 20 ms be-72-0.ibr02.fra30.ntwk.msn.net [104.44.10.0] ... |
C:\>tracert 40.100.174.226 Routenverfolgung zu 40.100.174.226 über maximal 30 Hops 1 1 ms 1 ms 1 ms fritz.box [192.168.178.1] 2 5 ms 5 ms 5 ms 62.155.242.220 3 12 ms 11 ms 11 ms 217.239.46.26 4 12 ms 12 ms 11 ms 62.157.250.70 5 25 ms 25 ms 26 ms be-72-0.ibr02.fra30.ntwk.msn.net [104.44.10.0] ... |
C:\>tracert 40.101.61.130 Routenverfolgung zu 40.101.61.130 über maximal 30 Hops 1 1 ms 1 ms <1 ms fritz.box [192.168.178.1] 2 6 ms 4 ms 5 ms 62.155.242.220 3 12 ms 11 ms 11 ms 217.239.47.46 4 11 ms 12 ms 12 ms 62.157.250.70 5 19 ms 20 ms 20 ms be-72-0.ibr02.fra30.ntwk.msn.net [104.44.10.0] ... |
Hier können Sie sehr gut sehen, dass Microsoft anhand der Anfrage durch den DNS-Server eine passende IP-Adresse liefert. Aber in allen Fällen wird Paket über den gleichen Zugangspunkt geroutet. Das ist aber nur eine Momentaufnahme und sicherlich wird Microsoft per BGP die Leitwege zu seinen Netzwerk zu jedem Peering-Punkt senden. So könnte es sehr wohl sein, dass glücklicherweise hier nun trotz des "falschen" DNS-Servers mit der falschen Antwort der gleiche Übergang genutzt wird. Es kann aber sehr wohl sein, dass dann intern im Microsoft Netzwerk der Verkehr "ungünstig" geroutet wird.
Sonderfall Telekom Hotspot
Auf einen Sonderfall möchte ich noch explizit hinweisen, da er mir bei einer Office 365 Netzwerkdemo einen Streich gespielt hat. Mein Notebook war mit einem Telekom-Hotspot verbunden, an dem ich mich auch auch korrekt angemeldet habe und problemlos arbeiten konnte. Im Laufe der Präsentation und Demo gibt es dann aber auch darum die Besonderheiten des DNS-Routings bei der Verwendung alternativer DNS-Server zu zeigen. Also habe ich nach alternativen Servern über www.ungefiltert-surfen.de gesucht und diese gezielt per NSLOOKUP abgefragt. Die ersten vier Abfragen haben immer ein "FRA-efz.ms-acdc.office.com" geliefert, was schon ungewöhnlich ist.
nslookup outlook.office365.com nslookup outlook.office365.com 1.1.1.1 nslookup outlook.office365.com 8.8.8.8 nslookup outlook.office365.com 9.9.9.9
Das war schon ungewöhnlich, da in der Regel auch immer ein ZHR oder LHR mit dabei ist. Aber als ich dann DNS-Server in Südamerika, Australien und USA befragt habe und auch da eine Antwort mit "FRA" bekommen habe, wurde die Angelegenheit suspekt. Ich kann es mir nur so vorstellen, dass die Telekom bei ihren Hotspot die DNS-Verbindungen über Port 53/UDP abfängt und auf eigene DNS-Server umleitet.
Aus Aspekten der Netzneutralität und der Möglichkeit einer Fehlersuche finde ich dieses Verhalten verwerflich. Die meisten Clients werden eh er DHCP ihre IP-Adresse und die DNS-Server erhalten aber wenn ich explizit einen anderen Service befragen möchte, sollte dies nicht unterbunden werden.
Zusammenfassung
Die korrekte Auflösung der Office 365 Adressen ist daher essentiell für eine effektive Verbindung der Client zum Service. Mit dezentralen Breakouts nutzten die Clients dann den kürzesten Weg über das Internet zum Microsoft Netzwerk. Das ist insbesondere bei Standorten in anderen Kontinenten wichtig und bei der Nutzung von Multi Geo Tenant unerlässlich. Diese essentielle Einstellung ist natürlich in Verbindung mit ExpressRoute noch zu verfeinern. Beim Einsatz von http-Proxy-Servern müssen diese Ziele natürlich auch entsprechend ausgeschlossen oder zu lokalen Proxy-Services umgeleitet werden, damit nicht alle Clients über den „Zentralproxy“ auf die Dienste zugreifen.
Weiter Links
- Office 365
- Office 365 DNS Details
- Office 365 Netzwerkziele
- Office 365 und Proxy Server
- Express Way statt Express Route
- PublicDNS Provider und Probleme
- OpenDNS
- Anycast-IP
- Office 365: Client connectivity
https://support.office.com/en-us/article/Client-connectivity-4232abcf-4ae5-43aa-bfa1-9a078a99c78b?ui=en-US&rs=en-US&ad=US - DNS geolocation for Office 365,
connecting you to your nearest Datacenter
for the fastest connectivity
https://blogs.technet.microsoft.com/onthewire/2014/06/27/dns-geolocation-for-office-365-connecting-you-to-your-nearest-datacenter-for-the-fastest-connectivity/ -
URLs und IP-Adressbereiche von
Office 365
https://support.office.com/de-de/article/URLs-und-IP-Adressbereiche-von-Office-365-8548a211-3fe7-47cb-abb1-355ea5aa88a2 - Implementieren eines geteilten VPN-Tunnels für Office 365
https://docs.microsoft.com/de-de/microsoft-365/enterprise/microsoft-365-vpn-implement-split-tunnel?view=o365-worldwide - Optimieren der Office 365-Konnektivität
für Remotebenutzer mithilfe eines geteilten
VPN-Tunnels
https://docs.microsoft.com/de-de/microsoft-365/enterprise/microsoft-365-vpn-split-tunnel?view=o365-worldwide