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.

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