Office 365 DNS Details

Tiefere Einblicke in die DNS-Auflösung von Microsoft Cloud-Diensten. Der Zugriff auf Dienste in der Cloud erfolgt über DNS-Namen, die vom DNS-Server auf IP-Adressen aufgelöst und vom Client angesprochen werden. Interessant wird es, wenn es ganz viele Clients an vielen Orten der Welt über unterschiedlicher Provider gibt die nicht einen Server sondern eine ganze Farm ansprechen, die ebenfalls weltweit verteilt sind. Ein Client sollte dann die "netztechnisch nächsten" Systeme ansprechen. Office 365 aber auch andere Anbieter nutzen dazu ausgeklügelte technischen aus GeoDNS, Anycast-Adressen u.a. Damit diese funktionieren, müssen Sie natürlich ihre Namensauflösung richtig konfigurieren.

Aufgabenstellung

Microsoft wie auch andere Anbieter betreiben eigenen sehr große WAN-Verbundnetzwerke mit vielen Übergängen zum Internet. Wenn ihr Postfach in Amsterdam liegt, sie selbst aber auf Dienstreise am Zuckerhut (Rio de Janeiro) weilen, dann versuchen die Anbieter die Verbindung schon vor Ort in ihre eigenes Netzwerk zu lenken und nicht erst über das langsamere Internet in Amsterdam anzukommen. Das bedeutet aber, dass der Service abhängig vom Netzstandort des Clients die passenden Eingänge ausliefern muss. Dazu gibt es mehrere Optionen:

Option Funktionsweise Risiken

GeoDNS

Der Service kann über die IP-Adresse der DNS-Abfrage erkennen wo der Client ist und eine passende IP-Adresse als DNS-Antwort ausliefern.

Fehleranfällig bei falscher Client-Konfiguration

AnyCast IP

Hierbei liefern die DNS-Server immer die gleiche IP-Adresse aus, die aber nicht nur einem Server, sondern durch viele Server bedient wird. Eine IP-Adresse muss im Internet nicht einmalig sein, wenn der Service und das Routing damit zurecht kommt. (Siehe auch Anycast-Routing

Nur für geeignete Applikationen, z.B. DNS

Service Redirect

Die erste Verbindung landet noch irgendwo und ist weniger kritisch, da der Server dann über das verwendete Protokoll (z.B. HTTP 301/302 Moved, oder SIP redirect) dem Client den "besten Server" liefert. So ist man nicht mehr direkt von DNS abhängig, da es pro Standort einen eigenen Namen für den Service gibt

Selten für Geo-Redundanz genutzt. Eher zur statischen Lastverteilung, z.B. GMX

Microsoft nutzt Office 365 unterschiedliche Lösungen, die teils "historische" und teils technisch begründet sind. Dies kann sich aber auch jederzeit ändern.

Richtige DNS Konfiguration

Die Schlüsselkomponente neben einer schnellen Internetanbindung übe kurze Wege ist eine korrekte DNS-Konfiguration. Hier kann sehr viel falsch gemacht werden.

Ein Client in einer Firma oder per VPN aus dem Homeoffice fragt in der Regel die internen DNS-Server des Unternehmens, damit eine interne Namensauflösung sichergestellt ist. Der Client kann sich an diesem DNS-Service in der Regel auch selbst registrieren und damit aufgelöst werden. Interessant wird es nun, wenn der Client auch externe Adressen, wie eben Office 365 auflösen soll. Ein Administrator könnte auf dem Client ein DNS-Routing konfigurieren, damit nur bestimmte Domains über die internen DNS-Server aufgelöst werden und alle anderen Domänen einen anderen Weg gehen. Das Verfahren wurde durch Direct Access als NRPT bekannt, funktioniert aber auch ohne Direct-Access. In den meisten Firmen wird aber der intern gefragte DNS-Server die externen Namen für den Client über Forwarder oder die Root-Server abfragen. Hier können sehr viele Fehler gemacht werden, die zwar eine schnelle Namensauflösung ermöglichen aber falsche Ergebnisse liefern. Was hilft mit eine schnelle Telefonauskunft, wenn die verwendete Leitung dann nicht gut ist?

Diverse Anbieter wie Google (8.8.8.8/8.8.4.4), QuadNine (9.9.9.9) oder 1.1.1.1 bieten kostenfrei superschnelle DNS-Server an, die aber im Bezug auf verteilte Cloud-Dienste nicht immer die optimalen Antworten liefern, was sich später noch zeigen wird.

Für eine korrekte Namensauflösung mit verteilten Cloud-Diensten ist es aber erforderlich, dass der Dienstanbieter einschätzen kann, wo sich ihre Clients befindet und vor allem welchen Weg die Verbindung nutzt. Der Anbieter hat in der Regel viele Übergänge zum Internet und es wäre sehr ineffektiv wenn ihr Client den falschen Eingang nutzt. Wenn die verschiedenen Eingänge durch individuelle IP-Adressen unterschieden werden, dann liefert die DNS-Abfrage den besten Eingang nur dann, wenn der DNS-Server den Client verorten kann. Dabei geht es weniger um die geografische Region in einem Land oder einer Stadt sondern eher der Standort im "Netz", Auch Provider haben individuelle Peerings u.a.

Als Grundregel kann gelten: Die DNS-Auflösung sollte den gleichen Weg nehmen, wie die Datenpakete zum Service.

Für ihre Client (Homeoffice) oder den eigenen DNS-Service (Im Firmennetzwerk) bedeutet dies:

  • Fragen sie die Root-Server
  • Fragen sie den DNS-Service ihres Internetprovider
  • Fragen Sie nicht einen fremden DNS-Server

Für alle drei Fälle beschreibe ich eine Bewertung, mit der die Argumentation verständlich werden sollte.

Optimal: Root-Server

Wenn Sie die Root-Server fragen, dann erhalten sie von diesen einen Verweis auf den Top-Level-Zonen-Server, der sie weiter zum DNS-Server für die Zone verweist.

Ihre DNS-Anfrage dauert beim ersten mal länger, da die drei oder mehr Anfragen brauchen bis sie eine Antwort haben aber der DNS-Server der Ziel-Zone kann ihnen anhand ihrer Source-IP-Adresse die beste Antwort liefern.

Bei den nächsten Anfragen sind viele Daten noch in ihrem eigenen Cache, so dass weitre Abfragen schneller erfolgen. Aber kein Cache eines fremden DNS-Service verfälscht die Informationen

Ok: Provider-DNS

Privatanschlüsse fragen in der Regel ihren DSL-Router, der nicht die Root-Server fragt sondern einen DNS-Service des Zugangsproviders. Auch bei Internetanbindungen bieten die Provider DNS-Server an, die sie nutzen können.

Meist sind die hier gegeben Antworten auch richtig.

Sie könnten aber ungünstig sein, wenn der Provider mehrere Verbindungen (Peerings) zum Cloud-Service hat aber die eigenen DNS-Server eben woanders stehen.

Die Firma (3) fragt ja den Provider-DNS (4) in dessen Rechenzentrum. Der Provider-DNS nutzt den "nächsten" Übergang 1, um die Antworten von Microsoft zu erhalten. Microsoft sieht die Anfrage von Übergang 1 und liefert die passende IP. besser wäre sowohl für den Kunden aber auch den Provider, wenn Microsoft den Übergang 2 liefern würde. Allerdings bleibt der Verkehr innerhalb des Providers und wenn er geschickt ist, erkennt er dies und kann mit BGP-Routen und DNS-Tuning gegensteuern.

Als Privatkunden wäre der Aufwand zur Optimierung zu hoch. Als Firmenanschluss sollten Sie prüfen, welche Nachteile die Nutzung der Provider-DNS-Server bezüglich Verfügbarkeit und gelieferte antworten mit sich bringt.

Schlecht: Zentral-DNS

Rein historisch finde ich bei vielen Firmen immer noch die gleichen Konstellation vor.

  • Der Client in der Niederlassung fragt den lokalen Active Directory DNS
  • Der DNS-Server in der Niederlassung nutzt als "Forwarder" die Zentrale
  • Der zentrale AD-DNS fragt dann direkt oder per Firewall im Internet nach

Das schlechte Ergebnis ist vorhersehbar: Der Client in der Niederlassung bekommt den falschen Zugangspunkt der Zentrale

Das ist schlecht, wenn der Client selbst einen Internet-Ausgang hat. Das Problem betrifft auch VPN-Clients

Schlecht: 3rd Party DNS

Ich finde immer wieder Konfigurationen, bei denen eine Administrator in guter Absicht die Root-Server entlasten und den wackeligen Provider-DNS umgehen will und stattdessen einen freien DNS-Server (8.8.8.8(8.8.4.4/9.9.9.9/1.1.1.1 o.ä.) als Forwarder konfiguriert. Diese Server liefern allesamt sehr schnell die Daten, die aber nicht akkurat sind. Das Bild der Namensauflösung entspricht dem eines Provider-DNS aber mit entfernteren Standorten.

Der DNS-Server der Firma fragt nun den 3rd-Party-DNS, der bei einem anderen Provider steht aber schnell erreichbar ist und dank Caching für ganz viele Client die Antwort sehr schnell liefert. Allerdings hat Office 365 die Anfragen über das Peering 1 bekommen und liefert entsprechend die Antwort für Peering 1. Schade nur, dass der Kunde mit seinem Provider eigentlich das Peering 2 nutzen sollte.

Natürlich sind die Microsoft Dienste auch über die Peering 1 Adresse erreichbar. Die Daten laufen dabei nicht mal durch Provider 1 und Provider 2, da Microsoft per BGP-Routing auch die entfernen Adressen über Peering 1 zur Verfügung stellt. Allerdings muss Microsoft den Verkehr dann doch zur realen IP-Adresse leiten, was sie auch gut sehen können.

Man sollte sich in dem Zuge auch fragen, warum Google, Quad9 und Cloudflare eigene DNS-Server betreiben und diese "kostenfrei" jedem im Internet zugänglich machen. Die Anbieter machen das sicher nicht, weil sie etwas zu verschenken haben, sondern weil sie natürlich damit auch erfahren, welche IP-Adressen, welche Internetadressen ansprechen. Wenn sie hinter so einer IP-Adresse sich dann z.B. an einem Google-Konto oder einer Webseite anmelden, dann kann zur IP-Adresse auch eine Person verbunden werden. So fügen sich viele kleine Bausteine zusammen.

Tabelle der Dienste

Mit dem Wissen habe ich nun einige interessante DNS-Namen über verschiedene Server in der Welt abgefragt und die Ergebnisse verglichen

Service

Name

IP

Exchange Online

GeoDNS

AMS-efz.ms-acdc.office.com

FRA-efz.ms-acdc.office.com
LHR-efz.ms-acdc.office.com

SFX-efz.ms-acdc.office.com

SJC-efz.ms-acdc.office.com
CPQ-efz.ms-acdc.office.com

unterschiedliche Adressen

SharePoint/OneDrive

Anycast DNS

spo-0004.spo-msedge.net

13.107.136.9

Teams HTTP

Anycast DNS

s-0005.s-msedge.net

52.113.194.132
2620:1ec:42::132

Teams RTP

Inband IP

Kein DNS

13.107.64.0/18
52.112.0.0/14
52.120.0.0/14

Sie sehen hier unterschiedliche Ansätze. Exchange Online nutzt tatsächlich "GeoDNS"-Adressen, d.h. abhängig vom Standort des anfragenden Clients wird der optimale Frontend-Server geliefert. SharePoint und Teams nutzen aber Anycast-DNS, d.h. die gleiche IP-Adresse ist weltweit identisch. Aber keine Sorge, da stehen wirklich viele Server mit der gleichen IP-Adresse in den unterschiedlichen Standorten.

Exchange Online

Nach der etwas längeren Einleitung stellt sich die Frage, wie ich als Anwender oder Administrator so eine ungünstige Konfiguration erkennen kann und welche Produkte davon betroffen sind. Ich nutze dazu immer gerne die Exchange-Zugänge zu Office 365. Der Name ist allseits bekannt:

outlook.office365.com

Was hindert mich, einfach diesen Namen per DNS aufzulösen und per PING anzusprechen. Ein einfaches "Ping" sagt schon rech viel.

Zum einen ist gut zu sehen, dass ich den Server erreichen kann und zwischen 15-24ms entfernt bin. Interessant ist aber auch der Flughafencode im realen Namen, der hier ganz klar auf Amsterdam zielt. Das klingt schon mal stimmig und "nahe bei".

Dass es aber auch falsch laufen kann, sehen Sie bei der Verwendung eines "falschen DNS-Servers"

PS C:\>(Resolve-DnsName -Type A -Server $dnsserver -Name outlook.office365.com)[1].namehost

Ich habe von meinem Homeoffice-Anschluss (Deutsche Glasfaser) unterschiedliche DNS-Server angefragt und das System dann er PING angesprochen.

Ich habe die DNS-Anfragen immer mehrfach gemacht, damit die Antwort wirklich nur die DNS-Laufzeit liefert. Der DNS-Server braucht ja selbst ein paar Millisekunden um die Daten selbst zu besorgen. Spätestens bei der zweiten Anfrage sollte der gleiche Server die Daten im Cache haben.

Die Seite https://www.ungefiltert-surfen.de/ listet in der Regel jede Menge DNS-Server, mit denen Sie solche Abfragen prüfen können.

DNS-Server Region Name DNS Ping-Zeit Host Ping-Zeit

185.22.44.50 (aus Fritz!Box)

DG, Deutschland

AMS-efz.ms-acdc.office.com

11ms

19ms

1.1.1.1

?

FRA-efz.ms-acdc.office.com

12ms

17ms

8.8.8.8

?

AMS-efz.ms-acdc.office.com

14ms

19ms

9.9.9.9

?

FRA-efz.ms-acdc.office.com

14ms

17ms

193.183.18.21

Schweden

sxf-efz.ms-acdc.office.com

18ms

17ms

211.75.48.98

Taiwan

hkg-efz.ms-acdc.office.com

na

205ms

72.51.45.108

Los Angeles, USA

SJC-efz.ms-acdc.office.com

196ms

160ms

172.98.193.42

Atlanta, USA

LYH-efz.ms-acdc.office.com

120ms

100ms

186.215.225.243

Rio de Janeiro, Brasilien

CPQ-efz.ms-acdc.office.com

234ms

202ms

Es gibt immer wieder Aussagen, dass ein ICMP-Ping von Providern priorisiert wird, damit die als Kunde eine "schnelle Verbindung" annehmen und Engpässe nicht auffallen. Dann nehmen wir die Zeiten einfach als kürzeste Laufzeit. Es fallen hier mehrere Dinge auf:

  • DNS-Server-Standort bestimmt Frontend Server
    Ich frage DNS-Server in der Welt die dann für mich den Namen auflösen. Es ist gut zu sehen, dass Microsoft geografisch "nahe" Frontend-Services ausliefert
  • DNS-Server Performance ist natürlich entfernungsabhängig
    Es ist kein Wunder, dass eine Anfrage aus Deutschland zu einen DNS-Server entsprechend lange dauert. Die Laufzeit des UDP-Pakets zum DNS-Server bei der zweiten Anfrage ist daher durchaus geeignet, um die Entfernung zum DNS-Server zu ermitteln. So können Sie zumindest eine VPN-Verbindung mit einem sehr weit entfernten DNS-Server ermitteln.
  • Multicast DNS ist fast gleich schnell wie der eigene Provider
    Die Abfrage von Google, Quad9 und Cloudflare sind nur minimal langsamer als der eigene Provider-DNS. Aber die Ergebnisse variieren, wenngleich die beiden Frontend-Server etwas gleich schnell erreichbar sind
  • Falscher Frontend Server ist langsam
    Wenn ich den falschen DNS-Server frage und z.B. einen weit entfernten Namen anspreche, dann ist das Paket sehr lange unterwegs. Wenn Sie hier einen Traceroute machen, denn sehen sie aber schon, dass das Paket "schnell" bei Microsoft landet aber dann im Microsoft WAN zum entfernten Frontend geht. Dieses Fehlrouting könnte Microsoft sicherlich optimieren.

Traceroute

Sie haben aber nun gesehen, dass ich mit einer falschen DNS-Auflösung auch einen weit entfernten Frontend-Eingang als Ziel erhalten. Ein Traceroute zeigt mit den Weg der Pakete recht einfach. Am Beispiel von SJC-efz.ms-acdc.office.com ergibt dies:

PS C:\> tracert  SJC-efz.ms-acdc.office.com

Routenverfolgung zu SJC-efz.ms-acdc.office.com [52.96.42.66] über maximal 30 Hops:

  1     1 ms     1 ms     1 ms  fritz.box [192.168.178.1]
  2     7 ms     6 ms     5 ms  100.68.0.1
  3    11 ms     9 ms    10 ms  100.127.1.13
  4     8 ms    10 ms     9 ms  185.22.46.72
  5    16 ms    15 ms    13 ms  ams-ix-1.microsoft.com [80.249.209.20]
  6    16 ms    17 ms    14 ms  ae21-0.icr01.ams21.ntwk.msn.net [104.44.232.164]
  7   160 ms   158 ms   161 ms  be-100-0.ibr01.ams21.ntwk.msn.net [104.44.22.235]
  8   164 ms   162 ms   162 ms  be-9-0.ibr01.lon24.ntwk.msn.net [104.44.18.144]
  9   163 ms   162 ms   162 ms  be-1-0.ibr01.lon22.ntwk.msn.net [104.44.16.55]
 10   163 ms   162 ms   164 ms  be-10-0.ibr01.nyc30.ntwk.msn.net [104.44.18.152]
 11   165 ms   160 ms   160 ms  be-5-0.ibr01.ewr30.ntwk.msn.net [104.44.7.103]
 12   161 ms   158 ms   157 ms  be-2-0.ibr01.cle30.ntwk.msn.net [104.44.7.94]
 13   160 ms   159 ms   159 ms  be-3-0.ibr01.ch4.ntwk.msn.net [104.44.7.112]
 14   163 ms   162 ms   161 ms  be-1-0.ibr01.ch2.ntwk.msn.net [104.44.7.217]
 15   161 ms   162 ms   162 ms  be-7-0.ibr01.dsm05.ntwk.msn.net [104.44.19.251]
 16   160 ms   162 ms   162 ms  be-2-0.ibr04.dsm05.ntwk.msn.net [104.44.17.35]
 17   163 ms   165 ms   162 ms  be-8-0.ibr04.cys04.ntwk.msn.net [104.44.28.255]
 18   161 ms   162 ms   162 ms  be-7-0.ibr04.by21.ntwk.msn.net [104.44.28.213]
 19   163 ms   163 ms   164 ms  ae142-0.icr02.by21.ntwk.msn.net [104.44.22.176]
 20     *        *        *     Zeitüberschreitung der Anforderung.
 21     *        *        *     Zeitüberschreitung der Anforderung.
 22     *        *        *     Zeitüberschreitung der Anforderung.
 23     *        *        *     Zeitüberschreitung der Anforderung.
 24     *        *        *     Zeitüberschreitung der Anforderung.
 25   158 ms   158 ms   161 ms  52.96.42.66

Sie sehen hier sehr gut, dass beim Hop 5 der Übergang ins Microsoft erfolgt. Mit 15ms ist das auf jeden Fall noch "nahe". Der Sprung über den Teil ist bei Hop 7 gut zu sehen, da hier die Laufzeit auf ca. 160ms steigt.

Das bedeutet aber auch, dass Microsoft den Verkehr dann nicht zum Frontend Server in Europa sondern durch das eigene Netzwerk bis nach SFR routet. Wenn mein Outlook sich dann mit dem Frontend Server dort verbindet, muss der den Request wieder über den Atlantik zu einem Frontend Server in Amsterdam senden, da nur der den aktuellen Postfachserver zum Postfach in Amsterdam kennt. (Siehe auch End2End EWS)

Spätestens hier sollten Sie erkennen, wie wichtig die richtige DNS-Auflösung ist. Ein VPN-Client oder eine Niederlassung mit lokalem Ausgang ins Internet sollte besser nicht den zentralen Firmen-DNS fragen.

Office365.com-Zone

In einer zweiten Messreihe habe ich mir die Information beschafft, welche DNS-Server die Zone "office365.com" bereitstellen. Bei mir war dies:

C:\>nslookup -q=NS office365.com
Server:  fritz.box
Address:  192.168.178.1

Nicht autorisierende Antwort:
office365.com   nameserver = nse24.o365filtering.com
office365.com   nameserver = nse13.o365filtering.com
office365.com   nameserver = ns2-38.azure-dns.net
office365.com   nameserver = ns4-38.azure-dns.info
office365.com   nameserver = nse12.o365filtering.com
office365.com   nameserver = nse21.o365filtering.com
office365.com   nameserver = ns3-38.azure-dns.org
office365.com   nameserver = ns1-38.azure-dns.com

Bei wiederholten Abfragen, habe ich immer die gleichen DNS-Server bekommen. Wenn ich aber z.B. den Server in Atlante gefragt habe, wurde eine andere Liste geliefert

C:\>nslookup -q=NS office365.com  172.98.193.42
Server:  ns0.backplanedns.org
Address:  172.98.193.42

Nicht autorisierende Antwort:
office365.com   nameserver = ns4-38.azure-dns.info
office365.com   nameserver = ns1-38.azure-dns.com
office365.com   nameserver = ns2-38.azure-dns.net
office365.com   nameserver = ns3-38.azure-dns.org
office365.com   nameserver = nse24.o365filtering.com
office365.com   nameserver = nse21.o365filtering.com
office365.com   nameserver = nse13.o365filtering.com
office365.com   nameserver = nse12.o365filtering.com

Insofern ist es schon wichtig zu wiesen, zu welchem Server man letztlich verwiesen wird.

Ich habe keine Kenntnisse, ob die Root-Server und die Top-Level-Domain-Server abhängig von der anfrgenden IP-Adresse auf naheliegende Server verweisen. Allerdings sind viele Server sowieso über Anycast-IP-Adressen erreichbar, so dass man "naheliegende " Server erreicht.

Ich habe mit aber mal die mir gemeldeten Server per PING geprüft: Bei einer Iterativen Abfrage über die Root-Server würde mein DNS-Resolver nach ein paar Hops ja diese Server direkt fragen. Leider sind sie per PING nicht erreichbar. Ich habe dann die Zeit für eine Namensauflösung gemessen.

PS C:\> Measure-Command {Resolve-DnsName outlook.office365.com -Type cname -Server nse13.o365filtering.com}

Auch diesen Befehl habe ich mehrfach ausgeführt (Warm-Up), damit der DNS-Server selbst schon im Cache war. Die erste Anfrage dauert ja immer etwas länger.

DNS-Server Ping-Zeit DNS Latenz

nse24.o365filtering.com

na

174ms

nse13.o365filtering.com

na

33ms

ns2-38.azure-dns.net

na

22ms

ns4-38.azure-dns.info

na

21ms

nse12.o365filtering.com

na

101ms

nse21.o365filtering.com

na

160ms

ns3-38.azure-dns.org

na

29ms

ns1-38.azure-dns.com

na

20ms

Sie sehen auch hier, dass durchaus Server dabei sind, die wohl weiter entfernt stehen müssen, da die höhere Latenzzeit sicher nicht durch eine lokale Verarbeitung begründet werden kann. Das bedeutet aber, dass ich hier nicht immer den "nächsten" und "schnellsten" DNS-Server bekommen.

Allerdings sollten Sie immer bedenken, dass es pro Netzwerk nur eine DNS-Abfrage bedarf, um zum Namen "outlook.office365.com" die entsprechenden IP-Adressen zu erhalten. Die Geschwindigkeit der DNS-Abfrage ist nicht wirklich maßgeblich für die Performance.

Sie wissen aber nun, dass Exchange Online per GeoDNS zur Anfrage die IP-Adresse des naheliegenden Frontend-Pools liefert. Wenn Sie den über eine falsche DNS-Auflösung einen Pool in einem anderen Land erreichen, dann wird alles deutlich langsamer. Über den Einfluss von Packetloss und Latenzzeit auf den Durchsatz habe ich auf Latenzzeiten und 200ms und TCP Window Scaling, Latenz und Durchsatz, RWIN schon viel geschrieben

Caching und TTL

Wenn Office 365 mit GeoDNS den Client zu einem naheliegenden Frontend-Server lenkt, dann könnte Microsoft auch eine aktive Verkehrslenkung und Ausfallbehandlung realisieren. Der DNS-Server müsste einfach abhängig vom Status der Server und der WAN-Links die aktuell weniger belasteten IP-Adressen ausliefern. Das funktioniert natürlich nur, wenn die Cache-Instanzen zwischen Client und Office 365 die Antworten nicht allzu lange vorhalten. Damit kommt der "Time to Live (TTL) in den Blickpunkt. Ein Resolve-DNSName liefert Klarheit:

Auch diesen Aufruf müssen Sie mehrfach starten und schauen, was das Maximum der Werte ist, da ein Cache die Daten verfälscht.

PS C:\> Resolve-DnsName outlook.office365.com | ft name,querytype,ttl

Name                       QueryType TTL
----                       --------- ---
outlook.office365.com          CNAME   45
outlook.ms-acdc.office.com     CNAME   45
AMS-efz.ms-acdc.office.com      AAAA   8
AMS-efz.ms-acdc.office.com      AAAA   8
AMS-efz.ms-acdc.office.com      AAAA   8
AMS-efz.ms-acdc.office.com      AAAA   8
AMS-efz.ms-acdc.office.com         A  10
AMS-efz.ms-acdc.office.com         A  10
AMS-efz.ms-acdc.office.com         A  10
AMS-efz.ms-acdc.office.com         A  10

Interessant ist, dass die Werte hier sehr kurz angegeben sind. Die CNAME-Einträge werden hier zwar 45 Sekunden gehalten, aber die A-Records auf die eigentlichen Server sind gerade mal 10 Sekunden lang gültig. Der TCP-Stack ihres Clients muss für eine neue Verbindung meist wieder nachfragen. Daher versucht Outlook auch Verbindungen bestehen zu lassen.

Interessant ist aber, wenn ich den Nameserver für die Zone "outlook365.com" nach den Einträgen frage.

PS C:\> Resolve-DnsName outlook.office365.com -Server nse24.o365filtering.com | ft name,querytype,ttl

Name                   QueryType  TTL
----                   ---------  ---
outlook.office365.com      CNAME  300
ms-acdc.office.com            NS 3600
ms-acdc.office.com            NS 3600
ms-acdc.office.com            NS 3600
ms-acdc.office.com            NS 3600
ns4-ms-acdc.office.com         A 3600
ns3-ms-acdc.office.com         A 3600
ns2-ms-acdc.office.com         A 3600
ns1-ms-acdc.office.com         A 3600

Diese Werte sind mit 3600 Sekunden (1h) wieder ganz normal. Ich hätte hier die gleichen Werte erwartet.

Exchange Hybrid

Wer schon einmal Exchange im Hybrid-Mode installiert hat, weiß um den Send-Connector, der alle Mails an "<tenantname>.mail.onmicrosot.com" direkt er MX-Lookup zur Cloud sendet. Da musste ich dann auch gleich mal schauen, was da bei DNS-Anfrage geliefert wird. Zuerst macht mein lokaler Exchange Server einen MX-Lookup für beide Domains

PS C:\> Resolve-DnsName -Type MX msxfaq.onmicrosoft.com

Name                          Type  TTL   Section    NameExchange                              Preference
----                          ----  ---   -------    ------------                              ----------
msxfaq.onmicrosoft.com        MX    3600  Answer     msxfaq.mail.protection.outlook.com        0

PS C:> Resolve-DnsName  msxfaq.mail.protection.outlook.com

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
msxfaq.mail.protection.outlook.com             A      10    Answer     104.47.1.36
msxfaq.mail.protection.outlook.com             A      10    Answer     104.47.2.36
PS C:\> Resolve-DnsName -Type MX msxfaq.mail.onmicrosoft.com

Name                          Type  TTL   Section    NameExchange                                            Preference
----                          ----  ---   -------    ------------                                            ----------
msxfaq.mail.onmicrosoft.com   MX    3600  Answer     msxfaq-mail-onmicrosoft-com.mail.protection.outlook.com 10


PS C:\> Resolve-DnsName  msxfaq-mail-onmicrosoft-com.mail.protection.outlook.com

Name                                                    Type TTL Section IPAddress
----                                                    ---- --- ------- ---------
msxfaq-mail-onmicrosoft-com.mail.protection.outlook.com A    10  Answer  104.47.1.36
msxfaq-mail-onmicrosoft-com.mail.protection.outlook.com A    10  Answer  104.47.2.36

Resolve-DNSName liefert immer nur zwei Namen aber wenn Sie die Anfrage häufiger machen, sehen Sie am Ende drei IP-Adressen. Interessant ist natürlich auch hier, wie weit die Systeme entfernt sind und wie andere DNS-Server in der weiten Welt die Adressen auflösen.

DNS-Server Region IP-Adresse DNS Ping-Zeit Host Ping-Zeit

185.22.44.50 (aus Fritz!Box)

DG, Deutschland

104.47.0.36
104.47.1.36
104.47.2.36

 

 

1.1.1.1

?

104.47.0.36
104.47.1.36
104.47.2.36

 

 

8.8.8.8

?

104.47.0.36
104.47.1.36
104.47.2.36

 

 

9.9.9.9

?

104.47.0.36
104.47.1.36
104.47.2.36

 

 

193.183.18.21

Schweden

104.47.0.36
104.47.1.36
104.47.2.36

 

 

211.75.48.98

Taiwan

104.47.0.36
104.47.1.36
104.47.2.36

 

 

72.51.45.108

Los Angeles, USA

Refer auf NS-Server

 

 

172.98.193.42

Atlanta, USA

Refer auf NS-Server

 

 

186.215.225.243

Rio de Janeiro, Brasilien

Refer auf NS-Server

 

 

104.47.118.145
ns1-proddns.glbdns.o365filtering.com

Microsoft

104.47.0.36
104.47.1.36
104.47.2.36

 

 

Alle DNS-Server, die ich weltweit angefragt habe, lieferten alle die gleichen drei IP-Adressen. Im Internet gibt es ja nette Services, die eine Verbindung aus verschiedenen Stellen versuchen. Hier sehen Sie, dass Hong Kong und Iran schon weiter weg sind. Die IP-Adresse ist also eher nicht in der Nähe.


Quelle: https://check-host.net/check-tcp?host=104.47.1.36:25

Auf der anderen Seite sind diese IP-Adressen nicht nur aus europäischen Metropolen schnell erreichbar, sondern auch aus den USA. Vielleicht hat Microsoft keine Eingänge in Asien aber die IP-Adressen sind sicher sowohl in USA als auch Europa "nahe" erreichbar, was wieder ein Hinweis auf Anycast-IP-Adressen ist. Dennoch bleibt noch die Frage, ob alle Tenants die gleichen Adressen nutzen. Da hilft nur eine Stichprobe.

<tenantname>-mail-onmicrosoft-com.mail.protection.outlook.com
Tenantname IP-Adressen SMTP HELO-Antwort Region Airport

msxfaq

104.47.0.36
104.47.1.36
104.47.2.36
HE1EUR01FT010, HE1EUR01FT026
VE1EUR01FT010
DB5EUR01FT031
EU Helinki
Wien
Dublin

basf

104.47.4.36
104.47.5.36
104.47.6.36
AM5EUR02FT060, AM5EUR02FT061, AM5EUR02FT013,...
HE1EUR02FT013.  HE1EUR02FT009, HE1EUR02FT002,...
VE1EUR02FT053, VE1EUR02FT052, VE1EUR02FT056,...
EU Amsterdam
Helsinki
Wien
dell
sony
104.47.36.36
104.47.37.36
104.47.38.36
SN1NAM02FT037, SN1NAM02FT032, SN1NAM02FT033,...
CY1NAM02FT064, CY1NAM02FT030, CY1NAM02FT031,...
BL2NAM02FT027, BL2NAM02FT018, BL2NAM02FT014,...
NA
Cheyenne (CYS)

samsung

104.47.108.36
104.47.109.36
SL2KOR01FT008, SL2KOR01FT014
PS2KOR01FT012, PS2KOR01FT004
KR Seoul
(PUS) Süd Korea (?)
Weitere Tenants ? ? ? ?

Ich habe noch einige weitere Tenants versucht aber nur drei "Cluster" von Servern gefunden. Es kann durchaus mehr geben und speziell in Nordamerika könnte es weitere Eingänge geben. Interessanterweise gibt es aber in Asien nur zwei IP-Adressen. Die IP-Adressen sind aber genau auf jeweils ein Datacenter gemappt und werden dort von sehr vielen Servern bedient. Microsoft kombiniert hier "GeoDNS" mit Loadbalancern für Port 25.

Wenn Sie eine geografisch verteilte Exchange Organisation betreiben, dann kann das dazu führen, dass Sie als europäische Firma mit einem Tenant in Amsterdam die Zugänge in Europa bekommen. Ein Exchange Server in USA würde dann auch diese Adressen ansprechen. Das ist aber nicht kritisch, da selbst bei einer Verbindung zu einem Server in einer anderen Region der Übergang normalerweise "lokal" erfolgt. Ein TraceRoute aus Europa nach Asien zeigt das der Übergang schon "lokal" ist.

C:\>tracert samsung-mail-onmicrosoft-com.mail.protection.outlook.com

Routenverfolgung zu samsung-mail-onmicrosoft-com.mail.protection.outlook.com [104.47.109.36] über maximal 30 Hops:

  1     1 ms     1 ms     1 ms  fritz.box [192.168.178.1]
  2     8 ms    10 ms     6 ms  100.68.0.1
  3     9 ms     8 ms    10 ms  100.127.1.13
  4     9 ms     8 ms     9 ms  185.22.46.72
  5    16 ms     *       29 ms  ams-ix-1.microsoft.com [80.249.209.20]
  6    17 ms    15 ms    18 ms  ae22-0.icr01.ams30.ntwk.msn.net [104.44.232.167]
  7   226 ms   225 ms   227 ms  be-100-0.ibr01.ams30.ntwk.msn.net [104.44.22.215]
  8   228 ms   226 ms   228 ms  be-8-0.ibr01.fra21.ntwk.msn.net [104.44.19.235]
  9   224 ms   249 ms   224 ms  be-6-0.ibr01.zrh20.ntwk.msn.net [104.44.18.78]
 10   229 ms   230 ms   232 ms  be-4-0.ibr01.gva20.ntwk.msn.net [104.44.18.51]
 11   225 ms   285 ms   224 ms

Der Übergang zum großen Microsoft Global Network ist bei Hop5 in Amsterdam. Dann aber müssen die Pakete schon nach Asien. Microsoft könnte natürlich die Verbindung so steuern, dass die Mails vor Ort abgeliefert und dann von Exchange intern nach Asien übertragen werden. Ich vermute aber, dass juristische Dinge dagegen sprechen. So landen die Mails eben nicht auf einem Relay-Server in der "falschen" Region.

Teams

Der zweite große Dienst ist Microsoft Teams. Hier kommt auch die zentrale URL "https://teams.microsoft.com" zum Einsatz, mit der sich alle Clients verbinden. Das ist es aber nicht alleine, denn der Teams Client greift im Hintergrund auch auf andere URLs zu. Microsoft kombiniert hier eine zentrale URL und "Redirect"-Dienste zu Services, die optimiert für den Benutzer sind. Ein Mitschnitt mit Fiddler auf den Teams-Prozess zeigt gleich mehrere URLs

Viele URLs sind unter teams.microsoft.com zu finden aber die Zugriffe auf das Exchange Postfach aber auch noch Rückgriffe auf Skype-Ressourcen müssen beachtet werden.

Ich konnte noch ermitteln. ob die URLs sich an meinem "Homeserver" mit den Daten orientieren oder auch eine geografische Komponente haben.

Auch hier ist die DNS-Abfrage interessant.

PS C:\> Resolve-DnsName teams.microsoft.com

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
teams.microsoft.com            CNAME  9     Answer     teams.office.com
teams.office.com               CNAME  9     Answer     teams-office-com.s-0005.s-msedge.net
teams-office-com.s-0005.s-msed CNAME  9     Answer     s-0005.s-msedge.net

PS C:\> Resolve-DnsName s-0005.s-msedge.net

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
s-0005.s-msedge.net                            AAAA   87    Answer     2620:1ec:42::132
s-0005.s-msedge.net                            A      115   Answer     52.113.194.132

Auch hier ist wieder eine CNAME-Kette zu finden, bei der teams.microsoft.com auf teams.office.com verweist und weiter über "teams-office-com.s-0005.s-msedge.net" zum Namen s-0005.s-msedge.net. Interessant ist hier aber, dass nur genau eine IP-Adresse geliefert wird. Ich habe auch hier die Adresse gegen die verschiedenen DNS-Server der Welt geprüft

DNS-Server Region Name IPv4-Addresse IPv6-Addresse Host Ping-Zeit

185.22.44.50 (aus Fritz!Box)

DG, Deutschland

s-0005.s-msedge.net

52.113.194.132

2620:1ec:42::132

15ms

1.1.1.1

?

s-0005.s-msedge.net

52.113.194.132

2620:1ec:42::132

"

8.8.8.8

?

s-0005.s-msedge.net

52.113.194.132

2620:1ec:42::132

"

9.9.9.9

?

s-0005.s-msedge.net

52.113.194.132

2620:1ec:42::132

"

193.183.18.21

Schweden

s-0005.s-msedge.net

52.113.194.132

2620:1ec:42::132

"

211.75.48.98

Taiwan

s-0005.s-msedge.net

52.113.194.132

2620:1ec:42::132

"

72.51.45.108

Los Angeles, USA

s-0005.s-msedge.net

52.113.194.132

2620:1ec:42::132

"

172.98.193.42

Atlanta, USA

s-0005.s-msedge.net

52.113.194.132

2620:1ec:42::132

"

186.215.225.243

Rio de Janeiro, Brasilien

s-0005.s-msedge.net

52.113.194.132

2620:1ec:42::132

"

Ich kann also jeden Server in der Welt fragen und bekomme immer die gleiche Antwort. Ich würde das als sicheres Zeichen für "AnyCast-IP-Adressen" ansehen, bei denen viele Server in der Welt alle die gleiche IP-Adresse haben und den Rest unter sich ausmachen.

Hier macht es keinen Sinn von meinem Einzelsystem dann die immer gleiche Adresse anzusprechen. Interessanter wäre hier dann tatsächlich die Ermittlung der Routen von verschiedenen Standorten in der Welt samt Leitweg.

Aus dem Fiddler-Trace sind aber auch Namen zu finden, die dann wieder auf geografische Eigenschaften schließen lassen. Den folgenden Request würde ich so interpretieren, dass mein Client sich mit einem Teams Frontend in Frankreich unterhält, um meinen Status zu pflegen.

GET https://francecentral-prod.notifications.teams.microsoft.com/users/8:orgid:<guid>/endpoints/<guid>/events/poll HTTP/1.1

Die Adresse muss der Client über ein "Inband-Provisioning" erhalten haben. Hier wäre dann die Frage zu stellen, ob ein Client in den USA auch diesen Service nutzt.

Der zweite wichtige Endpunkt bei Teams sind die Media Relays (TURN-Server). Wie bei Skype for Business werden diese Adressen aber nicht per DNS übertragen. Microsoft betreibt sehr viele TURN-Server und nach meinem Wissen bekommt der Client einen "verfügbaren" Server, zu dem er sich dann per IP-Adresse direkt über Port 3478 verbindet. Abhängig von dem Inhalt (Audio, Video, Daten) wird der Client dann sowieso zu einem weiteren Server und eigene Ports (Audio = 3479, Video = 3480, Daten = 3481) weiterleitet.

Hier ist also DNS gar nicht gefragt sondern Teams muss selbst anhand des Client-Standorts irgendwie einen naheliegenden TURN-Server finden. Hier können wir nur auf das Wissen und das Know-how von Teams und Microsoft vertrauen, die aber anhand der Telemetrie-Daten sicherlich einen sehr guten Überblick über die Wege im Internet haben.

SharePoint

Der dritte große Bereich ist die Datenablage in SharePoint/OneDrive, die ebenfalls per HTTPS und zwei Namen angesprochen werden:

  • <tenantname>.sharepoint.com
    Unter der Adresse ist die Sharepoint-Seite des Tenants erreichbar
  • <tenantname>-my.sharepoint.com
    Clients nutzen diese Adresse, um auf die persönlichen OneDrive-Laufwerke zuzugreifen.

Die weiteren Anfrage haben ich mit dem Tenant von Net at Work gemacht, der in Europa liegt. Sie können die gleichen Aktionen aber mit jedem Tenant wiederholen. Der Besitzer eines Tenant kann das auch gar nicht verhindern, da die Anfragen ja einfach anonym sind.

PS C:\> Resolve-DnsName netatwork.sharepoint.com -Server 72.51.45.108 | ft -AutoSize

Name                                                              Type  TTL Section NameHost
----                                                              ----  --- ------- --------
netatwork.sharepoint.com                                          CNAME 30  Answer  1224-ipv4e.clump.prod.aa-rt.sharepoint.com
1224-ipv4e.clump.prod.aa-rt.sharepoint.com                        CNAME 30  Answer  19963-ipv4e.farm.prod.aa-rt.sharepoint.com
19963-ipv4e.farm.prod.aa-rt.sharepoint.com                        CNAME 30  Answer  19963-ipv4e.farm.prod.sharepointonline.com.akadns.net
19963-ipv4e.farm.prod.sharepointonline.com.akadns.net             CNAME 30  Answer  19963-ipv4.farm.prod.aa-rt.sharepoint.com.spo-0004.spo-msedge.net
19963-ipv4.farm.prod.aa-rt.sharepoint.com.spo-0004.spo-msedge.net CNAME 30  Answer  spo-0004.spo-msedge.net

So ganz konnte ich noch nicht ermitteln, was der Grund dieser Verkettungen von CNAME-Einträgen ist. Ein HTTPS-Abruf direkt auf https://spo-0004.spo-msedge.net liefert natürlich eine Zertifikatswarnung:

Damit verrät die Cloud aber auch, unter welchem Namen dieser Server eigentlich erreichbar ist. Das ist die Eingangstür zu allen SharePoint-Seiten und nicht nur meines eigenen Tenant. Wie es dann dahinter weiter geht, kann ich natürlich nichts direkt sehen.

Auch hier habe ich mehrere DNS-Server in der Welt gefragt und immer die gleiche Antwort bekommen

DNS-Server Region Name IPv4-Addresse IPv6-Addresse Host Ping-Zeit

185.22.44.50 (aus Fritz!Box)

DG, Deutschland

spo-0004.spo-msedge.net

13.107.136.9

 

15ms

Interessant ist nun natürlich die Frage, wie schnell der Server aus den verschiedenen Ecken der Welt zu erreichen ist. Geografisch wird es von verschiedenen Diensten in England (London) gesehen. Aber das ist wohl nur das Peering

Da ich aufgrund on Corona grade nicht in den USA bin, habe ich Tenants gesucht, die vielleicht in den USA oder APAC sind. Aber die Auflösung war hier dann auch interessant:

Tenant Geo-Location SharePoint Name IPv4-Addresse IPv6-Addresse Host Ping-Zeit

microsoft.sharepoint.com

WW

spo-0004.spo-msedge.net

13.107.136.9

Keine

15ms

ibm.sharepoint.com

NA

spo-0004.spo-msedge.net

13.107.136.9

Keine

"

novell.sharepoint.com

AS

spo-0004.spo-msedge.net

13.107.136.9

Keine

"

dell.sharepoint.com

NA

spo-0004.spo-msedge.net

13.107.136.9

Keine

"

Anscheinend nutzt Microsoft auch für SharePoint weltweit die gleichen IP-Adressen, die dann natürlich je nach Netzwerkstandort zu einem nahegelegenen Eingangspunkt geroutet werden. Im Header einer HTTP-Antwort sieht man den Namen des Frontend-Servers.

PS C:\> (Invoke-WebRequest https://dell.sharepoint.com/_layouts/15/SPAndroidAppManifest.aspx).headers."X-MSEdge-Ref"
Ref A: A37ABC1A84E448AE9DB99E8D5337FA60 Ref B: AM3EDGE0915 Ref C: 2020-08-28T16:15:23Z

Hier war das dann wohl der "AM3EDGE0915". Bei Gelegenheit muss ich mir die Daten auch noch mal von einem anderen Standort besorgen

DNS Optimierung

Ich kann ja verstehen, wenn Firmen nicht auf spezielle Forwarder verzichten wollen. Auch die Umstellung von Niederlassungen auf lokale Breakouts mit IP-Routung und Firewall ist nicht immer sofort möglich. Sie könnten aber vielleicht nur Office 365 optimieren.

Ich finde diese Ansätze nicht gut aber manchmal geben Fakten solche temporäre Lösungen vor.

An den meisten Standorten gibt es heute ja schon eine WAN-Verbindung, die entweder auch Internet könnte oder sie können eine zweite Leitung mit Internet recht schnell und einfach legen lassen. Dann bleibt aber immer noch das Problem der Firewall und Proxy Server. Wer bislang auf eine zentrale Schutzlösung am Hauptstandort vertraut hat, müsste für dezentrale Internetzugänge weitere Systeme kaufen und installieren.

Dann überlegen wie mal, wie sie vielleicht so einen lokalen Zugang nur für Office 365 nutzen könnten. Das ist durchaus möglich. Sie müssten ...

  • ... die Office 365 Subnetze anders routen
    Sie lassen das Default-Gateway in den Niederlassungen weiterhin auf die Zentrale zeigen aber pflegen die Microsoft Subnetze über den Internet-Zugang. Zusätzlich könnten Sie auf dem Router noch Access-Listen pflegen, damit manuelle Routen bei findigen Anwendern nicht funktionieren
  • DNS für Office 365 Zonen
    Wenn die Client den lokalen DNS-Server fragen, der dann bisher die zentralen Server als Forwarder nutzte, sind die Antworten natürlich nicht optimal. Windows DNS-Server kennen schon seit längerem die Funktion von "Selektiven Forwardern" oder "Stub-zonen", mit denen Sie dem DNS-Server sagen können, dass bestimmte Adressen eben nicht den normalen Forwarder nutzen, sondern z.B. die DNS-Server des Zugangsproviders. Bei den Office 365-Domänen könnten Sie direkt die Microsoft DNS-Server fragen, die sich aber auch mal ändern könnten. Hier ist eine Überwachung notwendig. Oder sie addieren die Root-Server für diese ausgewählte Domänen. Vergessen sie aber nicht auch die IP-Adressen dieser Server per IP-Leitweg über den lokalen Ausgang zu leiten.

So sollten Clients in dem Standort per DNS nicht mehr die zentralen Dienste hinsichtlich Office 365 fragen und die gelieferten IP-Adressen sind per Routing-Tabelle auf den lokalen Internet-Zugang geleitet.

Daher sage ich immer: DNS-Anfragen und IP-Routing der Nutzdaten sollten immer den gleichen Pfad nutzen.

Office 365: DNS-Routing

Achtung bei Multi Provider Peering

Eine letzte Situation kann ihnen noch Probleme bereiten. Gerade größere Firmen nutzen nicht nur einen Provider zum Internetzugang und für eingehende Verbindungen. Sie haben ein Provider-Independent-Subnet und betreiben zwei oder noch mehr Verbindungen zum Internet über unterschiedliche Provider. Sie nutzen dazu in der Regel das Border Gateway Protokoll (BGP), um die eigenen Subnetze Richtung Internet bekannt zu geben. Über den Weg lernen auch die eigenen Router die Leitwege zum Internet. Eine eingehende Verbindung sollte ja idealerweise über den gleichen Provider beantwortet werden.

Das gilt aber auch für ausgehende Verbindungen. Wenn Sie nun ausgehend die Root-Server oder einen Provider-DNS fragen ,dann bekommen Sie die passenden Antworten für eben die IP-Adresse, mit der Sie die Anfrage gestellt haben. Die gehört ihnen aber wurde von einem ihrer Provider weiter geleitet. Da wird es nun interessant, wie Microsoft diese Situation bewertet.

Es kann ja sein, dass Microsoft über Provider 1 ihnen z.B. Frankfurt liefert aber ober Provider 2 dann wieder Amsterdam. Ungeschickt wäre es dann, das Paket zur IP-Adresse in Amsterdam über den Provider 1 zu senden. Auch die Frage der Rückantwort ist hier zu berücksichtigen. Das Paket kommt könnte ja über ein anderes Gateway bei der Firewall aufschlagen. Normalerweise passiert hier aber nichts.

Viel tiefer möchte ich hier nicht auf diesen Sonderfall eingehen.

Weitere Links