DNS Cache und TTL

Wenn sich im DNS wenig ändert, dann kann ein hoher TTL-Wert die Information lange im Cache halten und so die Anfragen reduzieren, Performance steigern und Verfügbarkeit verbessern. Outlook.office365.com macht aber ganz was anderes.

Ausgangslage

Bei meinen Checks mit End2End EWS und anderen Diensten löse ich natürlich den Namen "Outlook.office365.com" auf. Da alle Outlook Clients mit einem Office 365 Postfach diesen Namen nutzen, muss Microsoft die Auflösung natürlich hinsichtlich geografischer Nähe und Verfügbarkeit optimieren. Früher hat der DNS-Server anhand des anfragenden Clients den netztechnisch besten Zugangspunkt geliefert. Mittlerweile wird per Anycast-DNS eine verteilte IP-Adresse geliefert und per BGP-Routing der Weg bestimmt. Dennoch kann es ja mal passieren, dass eine Änderung auch eine Änderung des Ziels erforderlich macht. Daher habe ich mit mal die Namensauflösung rund um outlook.office365.com angeschaut. Dass es dabei aber dennoch zu Aussetzern kommen kann, zeigt das folgende Monitoring:

Eine Dauerüberwachung der TCP-Erreichbarkeit hat mir gezeigt, dass hier eine Unterbrechung stattgefunden hat. Allerdings war nicht die TCP-Verbindung gestört sondern die Namensauflösung. Ursache war hier also, dass ein DNS-Server, der als Forwarder genutzt wurde, nicht mehr liefern konnte. Daher habe ich mich auf die Spurensuche begeben, wie der DNS-Name eigentlich aufgelöst und im Cache vorgehalten wird.

Einfache Namensauflösung

Ich habe zuerst meinen lokalen DNS-Cache gelöscht, einen PING gestartet und dann den Eintrag im Cache angeschaut.

PS C:\>Clear-DnsClientCache

PS C:\>Test-Connection outlook.office365.com | ft -AutoSize

Source   Destination           IPV4Address   IPV6Address Bytes Time(ms)
------   -----------           -----------   ----------- ----- --------
FC-T480S outlook.office365.com 52.97.137.178             32    20
FC-T480S outlook.office365.com 52.97.137.178             32    39
FC-T480S outlook.office365.com 52.97.137.178             32    19
FC-T480S outlook.office365.com 52.97.137.178             32    47



PS C:\>Get-DnsClientCache -Entry outlook.office365.com

Entry                     RecordName                Record Status    Section TimeTo Data   Data
                                                    Type                     Live   Length
-----                     ----------                ------ ------    ------- ------ ------ ----
outlook.office365.com     outlook.office365.com     CNAME  Success   Answer       2      8 outlook.ha.office365.com
outlook.office365.com     outlook.ha.office365.com  CNAME  Success   Answer       2      8 outlook.ms-acdc.office.com
outlook.office365.com     outlook.ms-acdc.office... A      Success   Answer       2      4 52.97.137.178
outlook.office365.com     outlook.ms-acdc.office... A      Success   Answer       2      4 52.97.139.178
outlook.office365.com     outlook.ms-acdc.office... A      Success   Answer       2      4 52.97.147.2
outlook.office365.com     outlook.ms-acdc.office... A      Success   Answer       2      4 40.101.88.178

Eigentlich sieht die Antwort ganz ordentlich aus. Aber der sehr kurze TTL irritierte mich. Vielleicht liegt das aber daran, das mein DNS-Server diese Daten schon hatte und mir nur seine Restlaufzeit angezeigt hat. Ich habe also die Anfrage mehrfach wiederholt und gesehen, dass der TTL erst auf 1 und auf 0 und danach auf 60 gegangen ist.

Analyse mit Resolve-DNS gegen Google

Also habe ich einfach mal den DNS-Server gewechselt und gleich bei Google und Co nachgefragt

PS C:\> Resolve-DnsName outlook.office365.com  -Server 8.8.8.8 | ft *

QueryType Server                     NameHost                   Name                        Type CharacterSet Section DataLength TTL
--------- ------                     --------                   ----                        ---- ------------ ------- ---------- ---
    CNAME outlook.ha.office365.com   outlook.ha.office365.com   outlook.office365.com      CNAME      Unicode  Answer         58  12
    CNAME outlook.ms-acdc.office.com outlook.ms-acdc.office.com outlook.ha.office365.com   CNAME      Unicode  Answer         62  12
     AAAA                                                       outlook.ms-acdc.office.com  AAAA      Unicode  Answer         16  12
     AAAA                                                       outlook.ms-acdc.office.com  AAAA      Unicode  Answer         16  12
     AAAA                                                       outlook.ms-acdc.office.com  AAAA      Unicode  Answer         16  12
     AAAA                                                       outlook.ms-acdc.office.com  AAAA      Unicode  Answer         16  12
        A                                                       outlook.ms-acdc.office.com     A      Unicode  Answer          4  22
        A                                                       outlook.ms-acdc.office.com     A      Unicode  Answer          4  22
        A                                                       outlook.ms-acdc.office.com     A      Unicode  Answer          4  22
        A                                                       outlook.ms-acdc.office.com     A      Unicode  Answer          4  22

Aber auch hier ist der TTL mit 12 bzw. 22 Sekunden ungewöhnlich klein. Ein normaler DNS-Eintrag hat meist 3600 Sekunden.

Analyse des autoritativen Zone

Die Instanz, die mir zuverlässig sagen kann, wie ein Server aufgelöst wird, ist natürlich der autoritative DNS-Server für diese Domain. Bei office365.com kann ich das mit folgendem Befehl ermitteln:

PS C:\>Resolve-DnsName -Type ns office365.com  | ft *

QueryType Server                 NameHost               Name          Type CharacterSet    Section DataLength   TTL
--------- ------                 --------               ----          ---- ------------    ------- ----------   ---
       NS ns3.msft.net           ns3.msft.net           office365.com   NS      Unicode     Answer          8 73657
       NS ns1a.o365filtering.com ns1a.o365filtering.com office365.com   NS      Unicode     Answer          8 73657
       NS ns4a.o365filtering.com ns4a.o365filtering.com office365.com   NS      Unicode     Answer          8 73657
       NS ns2a.o365filtering.com ns2a.o365filtering.com office365.com   NS      Unicode     Answer          8 73657
       NS ns2.msft.net           ns2.msft.net           office365.com   NS      Unicode     Answer          8 73657
       NS ns1.msft.net           ns1.msft.net           office365.com   NS      Unicode     Answer          8 73657
       NS ns4.msft.net           ns4.msft.net           office365.com   NS      Unicode     Answer          8 73657
        A                                               ns2.msft.net     A      Unicode Additional          4 73657
     AAAA                                               ns2.msft.net  AAAA      Unicode Additional         16 73657
        A                                               ns4.msft.net     A      Unicode Additional          4 73657
     AAAA                                               ns4.msft.net  AAAA      Unicode Additional         16 73657

Da gibt es also schon den NS1.MSFT.NET bis NS4.MSFT.NET, die auch mit einem hohen TTL versehen sind. Die Zone "office365.com" selbst hat folgenden SOA-Record:

PS C:\> Resolve-DnsName -Type SOA office365.com.  -Server ns1.msft.net

Name                        Type TTL   Section    PrimaryServer               NameAdministrator           SerialNumber
----                        ---- ---   -------    -------------               -----------------           ------------
office365.com               SOA  300   Answer     ch1mgt0101dc120.prdmgt01.pr msnhst.microsoft.com        2014518737
                                                  od.exchangelabs.com

Name       : ch1mgt0101dc120.prdmgt01.prod.exchangelabs.com
QueryType  : A
TTL        : 3600
Section    : Additional
IP4Address : 141.251.224.214


Name       : ch1mgt0101dc120.prdmgt01.prod.exchangelabs.com
QueryType  : AAAA
TTL        : 3600
Section    : Additional
IP6Address : 2a01:111:e400:f5ce::22

Ein TTLS von 300 ist schon niedriger. Die Einträge für den primären Nameserver sind aber abweichen dann wieder mit 3600 Sekunden angegeben. Also frage ich einfach mal direkt diese DNS-Server nach dem Eintrag:

PS C:\>Resolve-DnsName outlook.office365.com -Server ns2.msft.net | fl

Name     : outlook.office365.com
Type     : CNAME
TTL      : 300
Section  : Answer
NameHost : outlook.ha.office365.com

Hier kommt also ein TTL von 300 Sekunden zurück. Selbst bei mehreren Anfragen kommt immer wieder dieser Wert zurück.

Andere Einträge

Ich habe zur Sicherheit noch ein paar andere Einträge direkt bei den Microsoft Servers abgefragt.

PS C:\>Resolve-DnsName -Type A <name> -Server ns1.msft.net
Name Antwort TTL

portal.office365.com

CNAME portal.microsoftonline.com
CNAME geo.portal.microsoftonline.akadns.net
CNAME eur.portal.microsoftonline.akadns.net

900
900
300

portal.microsoftonline.akadns.net

SOA

60

portal.microsoftonline.akadns.net

NS

180

www.microsoft.com

CNAME www.microsoft.com-c-3.edgekey.net

3600

portal.windowsazure.com

CNAME portal.azure.com
CNAME portal.azure.com.trafficmanager.net

900
900

Die Microsoft Server antworten also mit einer gegenüber dem SOA-Eintrag verkürzten Gültigkeitsdauer von 900 Sekunden oder weniger auf direkte Abfragen.

DNS-Server Forwarder

Nun war ich natürlich gespannt, was da auf dem Weg von meinem Client zu Microsoft passiert. Bei DNS fragen Clients ja in der Regel den lokalen DNS-Server, der dann vielleicht den Forwarder der Firewall fragt, die ihrerseits den DNS-Service des Internet Providers nutzt. In meinem Netzwerk sieht die Kette wie folgt aus:

Client ->  Windows DNS ->  Firewall -> EWETEL DNS -> ? - Microsoft DNS

Wie der DNS-Server des Providers die Namen auflöst, kann ich nicht sagen. Ich kann nur vermuten, das er vielleicht direkt die Root-Server nutzt oder einen Upstreams DNS des übergeordneten Providers. Laut peeringdb.com hat EWE aber Verbindungen zu DECIS, AMS-IX u.a. und zumindest keinen sichtbaren Upstream-Carrier und der Traceroute zu Office 365 geht auch über das DECIX mit 100 GBit. Also frage ich einfach mal nach Outlook.office365.com den Pfad entlang. Die Abfrage habe ich pro Server mehrfach durchgeführt, da der von Caching-Servern gelieferte TTL immer dem TTL der Restwertzeit im Cache entspricht und daher absteigend ist.

Dieser Test funktioniert natürlich nur, wenn die Firewall eine direkte DNS-Anfrage über Port 53/UDP nicht verhindert oder umleitet.

DNS-Server TTL

Windows DNS-Server (192.168.1.1)

0-23 Sek

Firewall Resolver

55-0 Sek

EWETEL DNS ( 212.6.108.143)

51-60 Sek

Microsoft DNS (ns1.microsoft.com)

300 Sek

Ich habe die gleiche Anfrage auch mit anderen DNS-Servern von anderen Kunden und über andere Provider versucht und immer war 60 Sekunden die magische Grenze. Einzig die autoritative Quelle für einen Eintrag liefert zuverlässig die 300 Sekunden. Ich frage mich aber, warum die Forwarder und ihr Cache nicht die 300 Sekunden ausschöpfen. Im Windows DNS-Server kann ich zwar die Daten im Cache sehen, aber hier ist ein TTL von "statisch" sichtbar, was aber nicht mit einem statischen Eintrag verwechselt werden darf.

Wenn ich alte KB-Artikel (Q198408) aus NT4 Zeiten finde, dann gibt es auch da einen Parameter MaxCacheTtl, der mit Windows NT4 SP4 im April 1998 addiert wurde und anscheinend immer noch funktioniert.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dns\Parameters]
"MaxCacheTtl "=dword:fe986400

Eine Gewähr kann ich dazu leider nicht geben

Auch für den DNS-Client gibt es entsprechende Blogs:

Es handelt sich dabei um folgenden Eintrag:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters]
"MaxCacheTtl "=dword:fe986400

Der Default ist maximal 1 Tag aber geringere TTLs der Antwort werden natürlich genutzt.

Risiko von hohen TTL-Werten

Die Herausforderung beim Betreiben eines DNS-Server ist eher, dass der Cache durch einen überlangen TTL überladen werden könnte. Stellen Sie sich vor ich bin ein Angreifer und bereite folgendes Szenario vor

  • Meine DNS-Zone mit TTL von 1 Jahr
    Ich bin also Besitzer einer eigenen DNS-Zone deren TTL-werte ich anpassen kann.
  • 1 Millionen TXT Einträge mit z.B. 1 kbyte Payload
    Dann lege ich sehr viele TXT-Records an, die alle möglichst viel Daten enthalten und einen ebenso langen TTL vorgeben
  • Dann frage ich den anzugreifenden DNS-Server an
    Den Server muss ich natürlich erreichen können und ein gut konfigurierte Server nimmt solche Anfragen nach anderen externen Namen nur von den eigenen Kunden-Netzwerken an.

Dank des sehr langen TTL würde der Cache meine Daten sehr lange halten. genug Zeit für mich mit vielen langsameren DNS-Abfragen einfach den Cache weiter zu füllen. Der Cache belegt Speicher und die Suche im Cache kann je nach verwendeter Software auch langsam werden.

Auch wenn der Angriff nur theoretisch ist, wird so verständlich, dass ein DNS-Cache sich nicht zwingend an den TTLs der autoritativen Zone halten muss und gerne auch kürzere Werte annehmen darf. Der Preis dafür ist, dass ein Client bei einer erneuten Anfrage wieder eine rekursive Anfrage auslöst. Der maximale TTL sollte also nicht zu hoch sein.

Zusammenfassung

DNS-Anfragen sollten möglichst aktuelle Werte liefern und so kann der Betreiber der autoritativen Zone mit dem TTL spielen, z.B.: um ihn vor Veränderungen schon mal herunter zu setzen. Das hilft dabei, dass Werte im Cache ausreichend schnell verfallen und eine neue Anfrage die neuen Werte zügig übernimmt. Auch ein DNS-Cache-Betreiber wird ein Interesse daran haben, Werte eine bestimmte Zeit im Cache zu halten, damit die anfragenden Clients sehr schnell eine Antwort erhalten und nicht erneut eine rekursive Auflösung gestartet werden muss. Auf der anderen Seite muss er Speicherplatz und Aktualität abwägen. Microsoft nutzt einen relativ kurzen TTL von ca. 300 Sekunden. Allerdings scheinen die meisten Cache-Systeme einen kürzeren Wert von ca. 60 Sekunden vorzugeben, so dass der TTL des Betreibers gar nicht zum Zuge kommt.

Sie sollten sich aber nicht verwirren lassen, wenn Sie bei einer DNS-Abfrage auch eine Antwort mit meinem TTL von deutlich kürzer Zeit erhalten. Das können Sie als Hinweis darauf verstehen, dass jemand anderes den Namen schon kurz vorher abgefragt hat. Der Cache liefert ihnen die Antwort dann mit der verbleibenden Restlaufzeit zurück.

Als Betreiber einer DNS-Zone sollten Sie sich aber bewusst sein, dass auch relativ hohe TTL-Werte bei ihren DNS-Einträgen nicht verhindern, dass die Cache-Server und Forwarder kleinere Werte annehmen und daher häufiger nachfragen. Wenn Sie eine geplante Downtime überbrücken wollen, dann sollten zumindest die DNS-Dienste weiter erreichbar sein, damit die Systeme, die sie erreichen wollen, nicht auch noch eine fehlende Namensauflösung anmeckern und vielleicht die falsche Entscheidung treffen. Gerade bei Mailservern habe ich es schon erlebt, dass ein "Host not reachable" dazu führt, dass die Mails mehrere Stunden oder Tage immer wieder versucht wird. Kommt aber ein "Host not resolvable", dann sollte ein Mailserver die Nachricht auch zurückstellen und nicht sofort mit einem NDR antworten.

Weitere Links