Eine niedrige DNS-Verzögerung ist ein SchlĂŒsselmerkmal fĂŒr schnelles Arbeiten im Internet. Um sie zu minimieren, ist es wichtig, die DNS-Server sorgfĂ€ltig auszuwĂ€hlen und . Aber zuerst sollten wir uns von unnötigen Anfragen befreien.
Deshalb wurde DNS ursprĂŒnglich als stark cachebarer Protokoll entwickelt. Zonenadministratoren setzen die Lebensdauer (TTL) fĂŒr einzelne EintrĂ€ge fest, und Resolver verwenden diese Informationen beim Speichern von EintrĂ€gen im Speicher, um unnötigen Datenverkehr zu vermeiden.
Ist das Caching effizient? Vor ein paar Jahren zeigte meine kleine Untersuchung, dass es nicht perfekt ist. Schauen wir uns die aktuelle Situation an.
FĂŒr die Datensammlung habe ich gepatcht, um den Wert von TTL fĂŒr die Antwort zu speichern. Dies wird als das minimale TTL seiner EintrĂ€ge fĂŒr jede eingehende Anfrage definiert. Das gibt einen guten Ăberblick ĂŒber die Verteilung von TTL im realen Datenverkehr und berĂŒcksichtigt auch die Beliebtheit einzelner Anfragen. Die gepatchte Version des Servers lief einige Stunden.
Der resultierende Datensatz besteht aus 1 583 579 EintrÀgen (Name, QType, TTL, Zeitstempel). Hier ist die allgemeine Verteilung von TTL (X-Achse ist TTL in Sekunden):
UnabhĂ€ngig von einem kleinen HĂŒgel bei 86 400 (hauptsĂ€chlich fĂŒr SOA-EintrĂ€ge) ist es ziemlich offensichtlich, dass die TTL im niedrigen Bereich liegen. Lassen Sie uns nĂ€her hinsehen:
Gut, TTLs ĂŒber 1 Stunde sind statistisch nicht signifikant. Lassen Sie uns also auf den Bereich 0â3600 konzentrieren:
Die Mehrheit der TTLs liegt zwischen 0 und 15 Minuten:
Der ĂŒberwiegende Teil liegt zwischen 0 und 5 Minuten:
Das ist nicht besonders gut.
Die kumulierte Verteilung macht das Problem noch offensichtlicher:
In der HÀlfte der DNS-Antworten betrÀgt die TTL 1 Minute oder weniger, und bei drei Vierteln liegt sie bei 5 Minuten oder weniger.
Aber warten Sie, es ist tatsĂ€chlich noch schlimmer. Denn dies sind TTLs von autoritativen Servern. Client-Resolver (z. B. Router, lokale Caches) erhalten TTLs von ĂŒbergeordneten Resolvern, und diese nehmen jede Sekunde ab.
Der Client kann also tatsĂ€chlich jeden Eintrag im Durchschnitt fĂŒr die HĂ€lfte der ursprĂŒnglichen TTL verwenden, bevor er eine neue Anfrage sendet.
Vielleicht betreffen diese sehr niedrigen TTLs nur ungewöhnliche Anfragen und nicht beliebte Websites und APIs? Lassen Sie uns das sehen:
Die X-Achse ist TTL, die Y-Achse ist die Beliebtheit der Anfragen.
Leider werden die beliebtesten Anfragen auch am schlechtesten gecached.
Lassen Sie uns das nÀher ansehen:
Das Urteil: Es ist wirklich alles schlecht. Es war schon vorher schlecht, und jetzt ist es noch schlimmer geworden. DNS-Caching ist praktisch nutzlos geworden. Da immer weniger Menschen den DNS-Resolver ihres Providers aus berechtigten GrĂŒnden nutzen, wird die Verzögerung immer offensichtlicher.
DNS-Caching ist nur fĂŒr Inhalte nĂŒtzlich geworden, die niemand besucht.
Beachten Sie auch, dass Software niedrige TTLs interpretieren kann.
Warum ist das so?
Warum wird fĂŒr DNS-EintrĂ€ge eine so niedrige TTL festgelegt?
- Veraltete Lastverteiler haben die Standardeinstellungen beibehalten.
- Es gibt Mythen, dass die DNS-Lastverteilung von der TTL abhĂ€ngt (das ist nicht der Fall â seit Netscape Navigator wĂ€hlen Clients eine zufĂ€llige IP-Adresse aus einer RR-Gruppe und versuchen transparent eine andere, wenn sie keine Verbindung herstellen können).
- Administratoren möchten Ănderungen sofort vornehmen, da dies die Planung erleichtert.
- Der Administrator des DNS-Servers oder des Lastverteilers sieht seine Aufgabe darin, die Konfiguration, die die Benutzer anfordern, effizient bereitzustellen und nicht die Leistung von Websites und Diensten zu steigern.
- Niedrige TTLs geben Seelenfrieden.
- Menschen setzen zunÀchst niedrige TTLs zu Testzwecken und vergessen dann, diese zu Àndern.
Ich habe âFailoverâ nicht in die Liste aufgenommen, da dies zunehmend irrelevant ist. Wenn Benutzer nur fĂŒr die Anzeige einer Fehlermeldung in ein anderes Netzwerk umgeleitet werden mĂŒssen, wenn absolut alles andere kaputt ist, ist eine Verzögerung von mehr als 1 Minute wahrscheinlich akzeptabel.
DarĂŒber hinaus bedeutet eine einminĂŒtige TTL, dass, wenn die autoritativen DNS-Server lĂ€nger als 1 Minute blockiert sind, niemand mehr auf abhĂ€ngige Dienste zugreifen kann. Und Redundanz hilft nicht, wenn die Ursache ein Konfigurationsfehler oder ein Hackerangriff ist. Andererseits werden mit angemessenen TTLs viele Clients weiterhin die vorherige Konfiguration nutzen und nichts bemerken.
FĂŒr niedrige TTLs sind zu einem groĂen Teil CDN-Dienste und LastverteilungsgerĂ€te verantwortlich, insbesondere wenn sie CNAMEs mit niedrigen TTLs und EintrĂ€ge mit Ă€hnlichen (aber unabhĂ€ngigen) niedrigen TTLs kombinieren:
$ drill raw.githubusercontent.com raw.githubusercontent.com. 9 IN CNAME github.map.fastly.net. github.map.fastly.net. 20 IN A 151.101.128.133 github.map.fastly.net. 20 IN A 151.101.192.133 github.map.fastly.net. 20 IN A 151.101.0.133 github.map.fastly.net. 20 IN A 151.101.64.133
Jedes Mal, wenn ein CNAME oder einer der A-EintrĂ€ge ablĂ€uft, muss eine neue Anfrage gesendet werden. Beide haben ein TTL von 30 Sekunden, aber es stimmt nicht ĂŒberein. Das tatsĂ€chliche durchschnittliche TTL wird 15 Sekunden betragen.
Aber warten Sie! Es wird noch schlimmer. Einige Resolver verhalten sich in dieser Situation mit zwei miteinander verbundenen niedrigen TTLs sehr schlecht:
$ drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 IN CNAME github.map.fastly.net. github.map.fastly.net. 1 IN A 151.101.16.133
Der Level3-Resolver arbeitet wahrscheinlich mit BIND. Wenn Sie diese Anfrage weiterhin senden, wird immer ein TTL von 1 zurĂŒckgegeben. Im Wesentlichen, raw.githubusercontent.com wird niemals zwischengespeichert.
Hier ist ein weiteres Beispiel fĂŒr eine solche Situation mit einer sehr beliebten Domain:
$ drill detectportal.firefox.com @1.1.1.1 detectportal.firefox.com. 25 IN CNAME detectportal.prod.mozaws.net. detectportal.prod.mozaws.net. 26 IN CNAME detectportal.firefox.com-v2.edgesuite.net. detectportal.firefox.com-v2.edgesuite.net. 10668 IN CNAME a1089.dscd.akamai.net. a1089.dscd.akamai.net. 10 IN A 104.123.50.106 a1089.dscd.akamai.net. 10 IN A 104.123.50.88
Mindestens drei CNAME-EintrĂ€ge. Autsch. Einer hat ein ordentliches TTL, aber das ist völlig nutzlos. Bei den anderen CNAME wird das ursprĂŒngliche TTL auf 60 Sekunden gesetzt, aber fĂŒr Domains akamai.net betrĂ€gt das maximale TTL 20 Sekunden, und keines von ihnen ist synchron.
Was ist mit Domains, die stÀndig Apple-GerÀte abfragen?
$ drill 1-courier.push.apple.com @4.2.2.2 1-courier.push.apple.com. 1253 IN CNAME 1.courier-push-apple.com.akadns.net. 1.courier-push-apple.com.akadns.net. 1 IN CNAME gb-courier-4.push-apple.com.akadns.net. gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.84 gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
Dasselbe Problem wie bei Firefox, und das TTL bleibt die meiste Zeit bei 1 Sekunde, wenn der Level3-Resolver verwendet wird.
Dropbox?
$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 IN A 162.125.67.3 $ drill client.dropbox.com @4.2.2.2 client.dropbox.com. 1 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 IN A 162.125.64.3
Bei dem Eintrag safebrowsing.googleapis.com ist der Wert TTL 60 Sekunden, wie bei den Facebook-Domains. Und wieder einmal werden diese Werte seitens des Clients halbiert.
Wie sieht es mit der Festlegung eines minimalen TTL aus?
Mit dem Namen, dem Abfragetyp, dem TTL und dem ursprĂŒnglich gespeicherten Zeitstempel habe ich ein Skript geschrieben, um 1,5 Millionen Abfragen zu simulieren, die durch einen zwischenspeichernden Resolver gehen, um das Volumen der ĂŒberflĂŒssigen Anfragen zu bewerten, die aufgrund eines abgelaufenen Cache-Eintrags gesendet wurden.
47,4 % der Anfragen wurden nach Ablauf eines bestehenden Eintrags gestellt. Das ist unangemessen hoch.
Wie wird sich die Festlegung eines minimalen TTL auf das Caching auswirken?
Die X-Achse sind die minimalen TTL-Werte. EintrĂ€ge mit ursprĂŒnglichen TTLs ĂŒber diesem Wert sind nicht betroffen.
Die Y-Achse zeigt den Prozentsatz der Anfragen von einem Client, der bereits einen zwischengespeicherten Eintrag hat, dessen GĂŒltigkeitsdauer jedoch abgelaufen ist, und der eine neue Anfrage stellt.
Der Anteil "ĂŒberflĂŒssiger" Anfragen sinkt durch die einfache Festlegung eines minimalen TTLs von 5 Minuten von 47 % auf 36 %. Bei einer Festlegung des minimalen TTLs von 15 Minuten sinkt die Anzahl dieser Anfragen auf 29 %. Ein minimaler TTL von 1 Stunde reduziert sie auf 17 %. Ein erheblicher Unterschied!
Wie wÀre es, nichts auf der Serverseite zu Àndern, sondern stattdessen die minimalen TTLs in den DNS-Caches der Clients (Router, lokale Resolver) zu setzen?
Die erforderliche Anzahl an Anfragen sinkt bei der Festlegung eines minimalen TTLs von 5 Minuten von 47 % auf 34 %, auf 25 % mit einem Minimum von 15 Minuten und auf 13 % mit einem Minimum von 1 Stunde. Möglicherweise liegt der optimale Wert bei 40 Minuten.
Die Auswirkungen dieser minimalen Ănderung sind gewaltig.
Was sind die Konsequenzen?
NatĂŒrlich kann der Service auf einen neuen Cloud-Anbieter, einen neuen Server oder ein neues Netzwerk umgestellt werden, was von den Clients erfordert, die neuesten DNS-EintrĂ€ge zu verwenden. Ein ausreichend niedriger TTL hilft, einen solchen Ăbergang sanft und unauffĂ€llig zu gestalten. Aber bei einem Wechsel zur neuen Infrastruktur erwartet niemand, dass die Clients innerhalb von 1 Minute, 5 Minuten oder 15 Minuten auf neue DNS-EintrĂ€ge umsteigen. Das Setzen einer minimalen Lebensdauer von 40 Minuten anstelle von 5 Minuten wird den Benutzern nicht den Zugang zum Dienst verwehren.
Dies wĂŒrde jedoch die Latenz erheblich reduzieren und die PrivatsphĂ€re sowie ZuverlĂ€ssigkeit erhöhen, indem unnötige Anfragen vermieden werden.
NatĂŒrlich besagen die RFCs, dass man sich strikt an die TTL halten sollte. Aber die RealitĂ€t ist, dass das DNS-System viel zu ineffizient geworden ist.
Wenn Sie mit autoritativen DNS-Servern arbeiten, ĂŒberprĂŒfen Sie bitte Ihre TTLs. Brauchen Sie wirklich so lĂ€cherlich niedrige Werte?
NatĂŒrlich gibt es triftige GrĂŒnde fĂŒr die Festlegung niedriger TTLs fĂŒr DNS-EintrĂ€ge. Aber nicht fĂŒr 75 % des DNS-Traffics, der sich praktisch nicht Ă€ndert.
Und wenn Sie aus irgendwelchen GrĂŒnden wirklich niedrige TTLs fĂŒr DNS verwenden mĂŒssen, stellen Sie sicher, dass auf Ihrer Website kein Caching aktiviert ist. Aus denselben GrĂŒnden.
Wenn Sie einen lokalen DNS-Cache haben, wie , die es Ihnen ermöglicht, minimale TTLs festzulegen, verwenden Sie diese Funktion. Das ist in Ordnung. Nichts Schlimmes wird passieren. Stellen Sie die minimale TTL auf etwa zwischen 40 Minuten (2400 Sekunden) und 1 Stunde ein. Ein durchaus angemessener Bereich.
Quelle: habr.com
