Eine niedrige DNS-Latenz ist der SchlĂŒssel zum schnellen Surfen im Internet. Um dies zu minimieren, ist es wichtig, DNS-Server sorgfĂ€ltig auszuwĂ€hlen . Der erste Schritt besteht jedoch darin, nutzlose Abfragen loszuwerden.
Aus diesem Grund wurde DNS ursprĂŒnglich als hochgradig zwischenspeicherbares Protokoll konzipiert. Zonenadministratoren legen eine GĂŒltigkeitsdauer (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 Caching effektiv? Vor ein paar Jahren ergab meine kleine Recherche, dass es nicht perfekt war. Werfen wir einen Blick auf den aktuellen Stand der Dinge.
Um Informationen zu sammeln, habe ich gepatcht um den TTL-Wert fĂŒr die Antwort zu speichern. Sie ist als minimale TTL ihrer DatensĂ€tze fĂŒr jede eingehende Anfrage definiert. Dies gibt einen guten Ăberblick ĂŒber die TTL-Verteilung des realen Traffics und berĂŒcksichtigt auch die Beliebtheit einzelner Anfragen. Die gepatchte Version des Servers funktionierte mehrere Stunden lang.
Der resultierende Datensatz besteht aus 1 DatensÀtzen (Name, qtype, TTL, Zeitstempel). Hier ist die gesamte TTL-Verteilung (X-Achse ist TTL in Sekunden):
Abgesehen von einem kleinen Anstieg bei 86 (hauptsÀchlich bei SOA-DatensÀtzen) ist es ziemlich klar, dass die TTLs im niedrigen Bereich liegen. Lass uns genauer hinschauen:
Okay, TTLs von mehr als 1 Stunde sind statistisch nicht signifikant. Dann konzentrieren wir uns auf den Bereich 0â3600:
Die meisten TTLs liegen zwischen 0 und 15 Minuten:
Die ĂŒberwiegende Mehrheit liegt zwischen 0 und 5 Minuten:
Es ist nicht sehr gut.
Die kumulative Verteilung macht das Problem noch offensichtlicher:
Die HĂ€lfte der DNS-Antworten hat eine TTL von 1 Minute oder weniger und drei Viertel haben eine TTL von 5 Minuten oder weniger.
Aber warte, es ist tatsĂ€chlich schlimmer. SchlieĂlich handelt es sich hierbei um TTL von autorisierenden Servern. Allerdings erhalten Client-Resolver (z. B. Router, lokale Caches) eine TTL von Upstream-Resolvern und diese verringert sich jede Sekunde.
Der Client kann also tatsĂ€chlich jeden Eintrag fĂŒr durchschnittlich die HĂ€lfte der ursprĂŒnglichen TTL verwenden, bevor er eine neue Anfrage sendet.
Vielleicht gelten diese sehr niedrigen TTLs nur fĂŒr ungewöhnliche Anfragen und nicht fĂŒr beliebte Websites und APIs? Werfen wir einen Blick darauf:
Die X-Achse ist TTL, die Y-Achse ist die AbfragepopularitÀt.
Leider lassen sich die beliebtesten Abfragen auch am schlechtesten zwischenspeichern.
Zoomen wir hinein:
Urteil: Es ist wirklich schlimm. Es war schon vorher schlimm, aber es wurde noch schlimmer. DNS-Caching ist praktisch nutzlos geworden. Da (aus guten GrĂŒnden) immer weniger Menschen den DNS-Resolver ihres Internetdienstanbieters nutzen, macht sich der Anstieg der Latenz deutlicher bemerkbar.
DNS-Caching ist nur noch fĂŒr Inhalte sinnvoll geworden, die niemand besucht.
Bitte beachten Sie auch, dass die Software möglicherweise interpretieren Sie niedrige TTLs.
Warum ist das so?
Warum sind DNS-EintrÀge auf eine so niedrige TTL eingestellt?
- Ăltere Load Balancer wurden mit den Standardeinstellungen belassen.
- Es gibt Mythen, dass der DNS-Lastausgleich von TTL abhĂ€ngt (das stimmt nicht â seit den Tagen von Netscape Navigator haben Clients eine zufĂ€llige IP-Adresse aus einer Reihe von RRs ausgewĂ€hlt und es transparent mit einer anderen IP-Adresse versucht, wenn sie keine Verbindung herstellen konnten).
- Administratoren möchten Ănderungen sofort anwenden, damit sie einfacher zu planen sind.
- Der Administrator eines DNS-Servers oder Load Balancers sieht seine Aufgabe darin, die von Benutzern angeforderte Konfiguration effizient bereitzustellen und nicht darin, Websites und Dienste zu beschleunigen.
- Niedrige TTLs geben Ihnen Sicherheit.
- Die Leute stellen zunÀchst niedrige TTLs zum Testen ein und vergessen dann, sie zu Àndern.
Ich habe âFailoverâ nicht in die Liste aufgenommen, da es immer weniger relevant wird. Wenn Sie Benutzer auf ein anderes Netzwerk umleiten mĂŒssen, nur um eine Fehlerseite anzuzeigen, obwohl absolut alles andere kaputt ist, ist eine Verzögerung von mehr als einer Minute wahrscheinlich akzeptabel.
DarĂŒber hinaus bedeutet eine TTL von einer Minute, dass niemand anderes auf abhĂ€ngige Dienste zugreifen kann, wenn autorisierende DNS-Server lĂ€nger als eine Minute blockiert sind. Und Redundanz nĂŒtzt nichts, wenn die Ursache ein Konfigurationsfehler oder ein Hack ist. Andererseits werden viele Clients bei vernĂŒnftigen TTLs weiterhin die vorherige Konfiguration verwenden und nie etwas bemerken.
CDN-Dienste und Load Balancer sind gröĂtenteils fĂŒr niedrige TTLs verantwortlich, insbesondere wenn sie CNAMEs mit niedrigen TTLs und DatensĂ€tze mit ebenso niedrigen (aber unabhĂ€ngigen) 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
Immer wenn der CNAME oder einer der A-EintrÀge ablÀuft, muss eine neue Anfrage gesendet werden. Beide haben eine 30-Sekunden-TTL, aber das ist nicht dasselbe. Die tatsÀchliche durchschnittliche TTL betrÀgt 15 Sekunden.
Aber warte! Es ist noch schlimmer. Einige Resolver verhalten sich in dieser Situation mit zwei damit 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 lĂ€uft wahrscheinlich auf BIND. Wenn Sie diese Anfrage weiterhin senden, wird immer eine TTL von 1 zurĂŒckgegeben. Im Wesentlichen gilt: raw.githubusercontent.com wird nie 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. Ja. Man hat eine anstĂ€ndige TTL, aber die ist völlig nutzlos. Andere CNAMEs haben eine anfĂ€ngliche TTL von 60 Sekunden, jedoch fĂŒr DomĂ€nen akamai.net Die maximale TTL betrĂ€gt 20 Sekunden und keine davon ist in Phase.
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
Das gleiche Problem wie bei Firefox und TTL bleibt bei Verwendung des Level1-Resolvers die meiste Zeit bei 3 Sekunde hÀngen.
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 der Aufnahme safebrowsing.googleapis.com Der TTL-Wert betrÀgt 60 Sekunden, wie bei Facebook-Domains. Und wiederum halbieren sich diese Werte aus Sicht des Kunden.
Wie wÀre es mit der Festlegung einer minimalen TTL?
Unter Verwendung des Namens, des Anforderungstyps, der TTL und des ursprĂŒnglich gespeicherten Zeitstempels habe ich ein Skript geschrieben, um 1,5 Millionen Anforderungen zu simulieren, die einen Caching-Resolver durchlaufen, um die Menge unnötiger Anforderungen abzuschĂ€tzen, die aufgrund eines abgelaufenen Cache-Eintrags gesendet wurden.
47,4 % der Anfragen wurden gestellt, nachdem ein bestehender Datensatz abgelaufen war. Das ist unangemessen hoch.
Welche Auswirkungen hat es auf das Caching, wenn die minimale TTL festgelegt ist?
Die X-Achse zeigt die minimalen TTL-Werte. DatensĂ€tze mit Quell-TTLs ĂŒber diesem Wert sind nicht betroffen.
Die Y-Achse ist der Prozentsatz der Anfragen von einem Client, der bereits ĂŒber einen zwischengespeicherten Eintrag verfĂŒgt, dieser jedoch abgelaufen ist und eine neue Anfrage stellt.
Der Anteil der âExtraâ-Anfragen wird von 47 % auf 36 % reduziert, indem einfach die minimale TTL auf 5 Minuten gesetzt wird. Durch die Festlegung der Mindest-TTL auf 15 Minuten sinkt die Anzahl dieser Anfragen auf 29 %. Eine Mindest-TTL von 1 Stunde reduziert sie auf 17 %. Bedeutender Unterschied!
Wie wÀre es, wenn Sie auf der Serverseite nichts Àndern, sondern stattdessen die minimale TTL in Client-DNS-Caches (Router, lokale Resolver) festlegen?
Die Anzahl der erforderlichen Anfragen sinkt von 47 % auf 34 % bei einer Mindest-TTL von 5 Minuten, auf 25 % bei mindestens 15 Minuten und auf 13 % bei mindestens 1 Stunde. Vielleicht sind 40 Minuten optimal.
Die Auswirkungen dieser kleinen Ănderung sind enorm.
Was sind die Konsequenzen?
NatĂŒrlich kann der Dienst zu einem neuen Cloud-Anbieter, einem neuen Server oder einem neuen Netzwerk verschoben werden, wobei von den Clients verlangt wird, die neuesten DNS-EintrĂ€ge zu verwenden. Und ein relativ kleiner TTL hilft dabei, einen solchen Ăbergang reibungslos und unmerklich zu gestalten. Aber beim Ăbergang zu einer neuen Infrastruktur erwartet niemand, dass Kunden innerhalb von 1 Minute, 5 Minuten oder 15 Minuten auf neue DNS-EintrĂ€ge migrieren. Wenn Sie die Mindest-TTL auf 40 Minuten statt auf 5 Minuten festlegen, werden Benutzer nicht daran gehindert, auf den Dienst zuzugreifen.
Dadurch wird jedoch die Latenz erheblich reduziert und der Datenschutz und die ZuverlÀssigkeit verbessert, indem unnötige Anfragen vermieden werden.
NatĂŒrlich sagen die RFCs, dass TTL strikt eingehalten werden muss. Die RealitĂ€t ist jedoch, dass das DNS-System zu ineffizient geworden ist.
Wenn Sie mit autorisierenden DNS-Servern arbeiten, ĂŒberprĂŒfen Sie bitte Ihre TTLs. Braucht man wirklich solch lĂ€cherlich niedrige Werte?
NatĂŒrlich gibt es gute GrĂŒnde, kleine TTLs fĂŒr DNS-EintrĂ€ge festzulegen. Aber nicht fĂŒr die 75 % des DNS-Verkehrs, die praktisch unverĂ€ndert bleiben.
Und wenn Sie aus irgendeinem Grund wirklich niedrige TTLs fĂŒr DNS verwenden mĂŒssen, stellen Sie gleichzeitig sicher, dass auf Ihrer Site kein Caching aktiviert ist. Aus den gleichen GrĂŒnden.
Wenn ein lokaler DNS-Cache ausgefĂŒhrt wird, z Mit dieser Funktion können Sie minimale TTLs festlegen. Es ist in Ordnung. Es wird nichts Schlimmes passieren. Stellen Sie die minimale TTL auf etwa 40 Minuten (2400 Sekunden) und 1 Stunde ein. Eine recht vernĂŒnftige Reichweite.
Source: habr.com
