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