Die DNS-Latenz (Domain Name System) ist eine Schlüsselkomponente für ein gutes Online-Erlebnis. Um die DNS-Latenz zu minimieren, spielt die sorgfältige Auswahl von DNS-Servern und Anonymisierungsrelays eine wichtige Rolle.
Der beste Weg, die Latenz zu minimieren, besteht jedoch darin, zunächst keine nutzlosen Abfragen zu senden. Aus diesem Grund wurde das DNS vom ersten Tag an als stark zwischenspeicherbares Protokoll konzipiert. Einzelne Datensätze haben eine Time-to-Live (TTL), die ursprünglich von Zonenadministratoren festgelegt wurde, und Resolver verwenden diese Informationen, um diese Datensätze im Speicher zu speichern, um unnötigen Datenverkehr zu vermeiden.
Ist Caching effizient? Eine schnelle Studie, die ich vor ein paar Jahren gemacht habe, hat gezeigt, dass es Raum für Verbesserungen gibt. Heute möchte ich einen neuen Blick auf den aktuellen Stand der Dinge werfen.
Dazu habe ich einen verschlüsselten DNS-Server gepatcht, um die ursprüngliche TTL einer Antwort, definiert als die minimale TTL ihrer Datensätze, für jede eingehende Abfrage zu speichern. Dies gibt uns einen guten Überblick über die TTL-Verteilung des realen Datenverkehrs, berücksichtigt aber auch die Beliebtheit einzelner Abfragen.
Diese gepatchte Version wurde für ein paar Stunden laufen gelassen. Der resultierende Datensatz besteht aus 1.583.579 Tupeln (Name, qtype, TTL, timestamp). Hier ist die Gesamt-TTL-Verteilung (die X–Achse ist die TTL in Sekunden):
Neben einem vernachlässigbaren Anstieg bei 86.400 (hauptsächlich für SOA-Datensätze) ist es ziemlich offensichtlich, dass TTLs im niedrigen Bereich liegen. Vergrößern wir:
Okay, TTLs über 1 Stunde sind statistisch unbedeutend. Konzentrieren wir uns auf den Bereich 0-3.600:
Und wo die meisten TTLs zwischen 0 und 15 Minuten liegen:
Die überwiegende Mehrheit liegt zwischen 0 und 5 Minuten:
Das ist nicht großartig. Die kumulative Verteilung kann das Problem noch offensichtlicher machen:
Die Hälfte des Internets hat eine TTL von 1 Minute oder weniger und drei Viertel eine TTL von 5 Minuten oder weniger.
Aber warte, das ist tatsächlich schlimmer. Dies sind TTLs, wie sie von autorisierenden Servern definiert werden. TTLs, die von Client-Resolvern (z. B. Routern, lokalen Caches) abgerufen werden, erhalten jedoch eine TTL, die von Upstream-Resolvern jede Sekunde dekrementiert wird. Im Durchschnitt beträgt die tatsächliche Dauer, die ein Client einen zwischengespeicherten Eintrag verwenden kann, bevor eine neue Abfrage erforderlich ist, die Hälfte der ursprünglichen TTL.
Möglicherweise betreffen diese sehr niedrigen TTLs nur ungewöhnliche Abfragen und nicht beliebte Websites und APIs. Werfen wir einen Blick darauf:
Leider sind die beliebtesten Abfragen auch die sinnlosesten für den Cache. Lassen Sie uns vergrößern:
Urteil: Es ist wirklich schlimm, oder besser gesagt, es war schon schlimm, und es ist schlimmer geworden. DNS-Caching ist nahezu nutzlos geworden. Da weniger Personen den DNS-Resolver ihres Internetdienstanbieters verwenden (aus guten Gründen), wird die erhöhte Latenz deutlicher. DNS-Caching ist nur für Inhalte nützlich, die niemand besucht. Beachten Sie auch, dass Software niedrige TTLs unterschiedlich interpretieren kann.
Warum?
Warum werden DNS-Einträge mit so niedrigen TTLs gesetzt?
- Legacy Load Balancer werden mit den Standardeinstellungen belassen.
- Die urbane Legende, dass DNS-basierter Lastenausgleich von TTLs abhängt (nicht).
- Administratoren möchten, dass ihre Änderungen sofort angewendet werden, da dies möglicherweise weniger Planungsaufwand erfordert.
- Als DNS- oder Load-Balancer-Administrator ist es Ihre Aufgabe, die gewünschte Konfiguration effizient bereitzustellen und Websites und Dienste nicht schnell zu machen.
- Niedrige TTLs geben Sicherheit.
Ich schließe ‚für Failover‘ nicht in diese Liste ein, da dies immer weniger relevant geworden ist. Wenn die Absicht besteht, Benutzer in ein anderes Netzwerk umzuleiten, nur um eine Failover-Seite anzuzeigen, wenn absolut alles andere brennt, ist eine Verzögerung von mehr als einer Minute wahrscheinlich akzeptabel.
CDNs und Load-Balancer sind größtenteils schuld, insbesondere wenn sie CNAME-Datensätze mit kurzen TTLs kombinieren, wobei Datensätze auch kurze (aber unabhängige) TTLs haben:
$ drill raw.githubusercontent.comraw.githubusercontent.com. 9 IN CNAME github.map.fastly.net.github.map.fastly.net. 20 IN A 151.101.128.133github.map.fastly.net. 20 IN A 151.101.192.133github.map.fastly.net. 20 IN A 151.101.0.133github.map.fastly.net. 20 IN A 151.101.64.133
Jedes Mal, wenn der CNAME oder einer der A-Datensätze abläuft, muss eine neue Abfrage gesendet werden. Beide haben eine 30-Sekunden-TTL, sind aber nicht in Phase. Die tatsächliche durchschnittliche TTL beträgt 15 Sekunden.
Aber warte! Das ist schlimmer. Einige Resolver verhalten sich in einer solchen Situation mit niedrigem TTL-CNAME + niedrigen TTL-Datensätzen ziemlich schlecht:
$ drill raw.githubusercontent.com @4.2.2.2raw.githubusercontent.com. 1 IN CNAME github.map.fastly.net.github.map.fastly.net. 1 IN A 151.101.16.133
Dies ist der Resolver von Level3, der meiner Meinung nach BIND ausführt. Wenn Sie diese Abfrage weiterhin senden, ist die zurückgegebene TTL immer 1. Im Wesentlichen, raw.githubusercontent.com wird niemals zwischengespeichert.
Hier ist ein weiteres Beispiel für eine Low-TTL-CNAME + Low-TTL-records-Situation mit einem sehr beliebten Namen:
$ drill detectportal.firefox.com @1.1.1.1detectportal.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.106a1089.dscd.akamai.net. 10 IN A 104.123.50.88
Nicht weniger als drei CNAME-Einträge. AUA. Einer von ihnen hat eine anständige TTL, aber es ist völlig nutzlos. Andere CNAMEs haben eine ursprüngliche TTL von 60 Sekunden; die akamai.net namen haben eine maximale TTL von 20 Sekunden und nichts davon ist in Phase.
Wie wäre es mit einem, das Ihre Apple-Geräte ständig abfragen?
$ drill 1-courier.push.apple.com @4.2.2.21-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.84gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
Die gleiche Konfiguration wie Firefox und die TTL bleibt die meiste Zeit bei Verwendung des Level3-Resolvers bei 1.
Was ist mit Dropbox?
$ drill client.dropbox.com @8.8.8.8client.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.2client.dropbox.com. 1 IN CNAME client.dropbox-dns.com.client.dropbox-dns.com. 1 IN A 162.125.64.3
safebrowsing.googleapis.com hat eine TTL von 60 Sekunden. Facebook-Namen haben eine TTL von 60 Sekunden. Und auch aus Kundensicht sollten diese Werte halbiert werden.
Wie wäre es mit einer minimalen TTL?
Unter Verwendung des ursprünglich gespeicherten Namens, des Abfragetyps, der TTL und des Zeitstempels habe ich ein Skript geschrieben, das die über 1,5 Millionen Abfragen simuliert, die einen Caching-Resolver durchlaufen, um abzuschätzen, wie viele Abfragen aufgrund eines abgelaufenen Cache-Eintrags gesendet wurden. 47,4% der Abfragen wurden nach Ablauf eines vorhandenen, zwischengespeicherten Eintrags durchgeführt. Dies ist unangemessen hoch.
Was wären die Auswirkungen auf das Caching, wenn eine minimale TTL festgelegt würde?
Die X-Achse ist die minimale TTL, die eingestellt wurde. Datensätze, deren ursprüngliche TTL höher als dieser Wert war, waren nicht betroffen. Die Y-Achse ist der Prozentsatz der Abfragen, die von einem Client durchgeführt wurden, der bereits einen zwischengespeicherten Eintrag hatte, aber eine neue Abfrage durchgeführt wurde und der zwischengespeicherte Eintrag abgelaufen war.
Die Anzahl der Abfragen sinkt von 47% auf 36%, wenn nur eine minimale TTL von 5 Minuten festgelegt wird. Wenn Sie eine TTL von mindestens 15 Minuten festlegen, sinkt die Anzahl der erforderlichen Abfragen auf 29%. Eine minimale TTL von 1 Stunde lässt es auf 17% fallen. Das ist ein signifikanter Unterschied!
Wie wäre es, wenn Sie nichts serverseitig ändern, sondern stattdessen Client-DNS-Caches (Router, lokale Resolver und Caches …) eine minimale TTL festlegen?
Die Anzahl der erforderlichen Abfragen sinkt von 47% auf 34%, indem eine minimale TTL von 5 Minuten festgelegt wird, auf 25% bei einem Minimum von 15 Minuten und auf 13% bei einem Minimum von 1 Stunde. 40 Minuten vielleicht ein Sweet Spot. Die Auswirkungen dieser minimalen Änderung sind enorm.
Was sind die Auswirkungen?
Natürlich kann ein Dienst zu einem neuen Cloud-Anbieter, einem neuen Server oder einem neuen Netzwerk wechseln, sodass Clients aktuelle DNS-Einträge verwenden müssen. Und einigermaßen niedrige TTLs tragen dazu bei, den Übergang reibungsfrei zu gestalten. Niemand, der zu einer neuen Infrastruktur wechselt, erwartet jedoch, dass Clients die neuen DNS-Einträge innerhalb von 1 Minute, 5 Minuten oder 15 Minuten verwenden.
Wenn Sie eine TTL von mindestens 40 Minuten anstelle von 5 Minuten festlegen, können Benutzer nicht auf den Dienst zugreifen. Es wird jedoch die Latenz drastisch reduzieren und den Datenschutz (mehr Abfragen = mehr Tracking-Möglichkeiten) und die Zuverlässigkeit verbessern, indem unnötige Abfragen vermieden werden.
Natürlich sagen RFCs, dass TTLs strikt eingehalten werden sollten. Aber die Realität ist, dass das DNS ineffizient geworden ist.
Wenn Sie autoritative DNS-Server betreiben, überprüfen Sie bitte Ihr TTLs. Müssen diese wirklich lächerlich niedrig sein?
Lesen Sie: So wählen Sie DNS-TTL-Werte
Sicher, es gibt gute Gründe, niedrige DNS-TTLs zu verwenden. Aber nicht für 75% des Internets, um Inhalte bereitzustellen, die größtenteils unveränderlich, aber sinnlos im Cache sind. Und wenn Sie aus irgendeinem Grund wirklich niedrige DNS-TTLs verwenden müssen, stellen Sie auch sicher, dass der Cache auch auf Ihrer Website nicht funktioniert. Aus den gleichen Gründen.
Wenn Sie einen lokalen DNS-Cache wie dnscrypt-proxy verwenden, mit dem minimale TTLs festgelegt werden können, verwenden Sie diese Funktion. Das ist okay. Nichts Schlimmes wird passieren. Stellen Sie diese minimale TTL auf etwas zwischen 40 Minuten (2400 Sekunden) und 1 Stunde ein; Dies ist ein durchaus vernünftiger Bereich.
Adaptiert vom Originalbeitrag, der auf 00f.net