Eine niedrige DNS-Latenz ist ein Schlüsselfaktor für schnelles Surfen im Internet. Um dies zu minimieren, ist es wichtig, DNS-Server und anonymes Relay sorgfältig auszuwählen. Aber das erste, was Sie tun müssen, ist, nutzlose Abfragen loszuwerden.

Aus diesem Grund wurde DNS ursprünglich als hoch zwischengespeichertes Protokoll erstellt. Zonenadministratoren legen eine Lebensdauer (TTL) für einzelne Datensätze fest, und Resolver verwenden diese Informationen beim Speichern von Datensätzen im Speicher, um unnötigen Datenverkehr zu vermeiden.

Ist das Caching effizient? Vor ein paar Jahren ergab meine kleine Recherche, dass es nicht perfekt war. Schauen Sie sich den aktuellen Stand der Dinge an.

Um Informationen zu sammeln, habe ich den verschlüsselten DNS-Server gepatcht, um den TTL-Wert für die Antwort zu speichern. Es ist als die minimale TTL seiner Einträge für jede eingehende Anforderung definiert. Dies gibt einen guten Überblick über die Verteilung des realen TTL-Verkehrs und berücksichtigt auch die Beliebtheit einzelner Anforderungen. Die gepatchte Version des Servers funktionierte mehrere Stunden.

Der resultierende Datensatz besteht aus 1.583.579 Datensätzen (Name, Q-Typ, TTL, Zeitstempel). Hier ist die allgemeine Verteilung von TTL (die X-Achse ist TTL in Sekunden):



Abgesehen von dem kleinen Hügel auf 86.400 (hauptsächlich für SOA-Datensätze) ist es ziemlich offensichtlich, dass TTLs im niedrigen Bereich liegen. Schauen wir uns das genauer an:



Nun, TTLs über 1 Stunde sind statistisch nicht signifikant. Konzentrieren Sie sich dann auf den Bereich 0−3600:



Die meisten TTL von 0 bis 15 Minuten:



Die überwiegende Mehrheit von 0 bis 5 Minuten:



Das ist nicht sehr gut.

Die kumulative Verteilung macht das Problem noch offensichtlicher:



In der Hälfte der DNS-Antworten beträgt die TTL 1 Minute oder weniger und in drei Vierteln 5 Minuten oder weniger.

Aber warte, es ist tatsächlich schlimmer. Immerhin ist dies TTL von autorisierenden Servern. Client-Resolver (z. B. Router, lokale Caches) empfangen jedoch TTLs von höheren Resolvern und nehmen jede Sekunde ab.

Somit kann der Client jeden Datensatz im Durchschnitt für die Hälfte der ursprünglichen TTL verwenden, wonach er eine neue Anforderung sendet.

Vielleicht betreffen diese sehr niedrigen TTLs nur ungewöhnliche Anfragen, nicht beliebte Websites und APIs? Mal sehen:



Die X-Achse ist TTL, die Y-Achse ist die Abfragebeliebtheit.

Leider werden die beliebtesten Abfragen auch am schlechtesten zwischengespeichert.

Vergrößern:



Fazit: Alles ist wirklich schlecht. Es war vorher schlecht, aber es wurde schlimmer. DNS-Caching ist praktisch unbrauchbar geworden. Da weniger Benutzer (aus gutem Grund) den DNS-Resolver ihres Internetdienstanbieters verwenden, wird die Zunahme der Latenz immer deutlicher.

DNS-Caching ist nur für Inhalte nützlich, die niemand besucht.

Beachten Sie auch, dass Software niedrige TTLs möglicherweise anders interpretiert.

Warum so?

Warum ist eine so kleine TTL für DNS-Einträge festgelegt?

• Veraltete Load Balancer behalten die Standardeinstellungen bei.
  
• Es gibt Mythen, dass der DNS-Lastenausgleich von TTL abhängt (dies ist nicht der Fall - seit Netscape Navigator wählen Clients eine zufällige IP-Adresse aus dem RR-Satz aus und versuchen transparent eine andere, wenn sie keine Verbindung herstellen können.)
  
• Administratoren möchten die Änderungen sofort übernehmen, da die Planung einfacher ist.
  
• Der Administrator des DNS-Servers oder des Load Balancers sieht seine Aufgabe darin, die von den Benutzern angeforderte Konfiguration effektiv bereitzustellen, anstatt Websites und Dienste zu beschleunigen.
  
• Niedrige TTL 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 dies alles weniger relevant ist. Wenn Sie Benutzer nur in ein anderes Netzwerk umleiten müssen, um die Fehlerseite anzuzeigen, ist wahrscheinlich eine Verzögerung von mehr als 1 Minute akzeptabel, wenn absolut alles andere fehlerhaft ist.

Darüber hinaus bedeutet Minuten-TTL, dass niemand sonst auf die abhängigen Dienste zugreifen kann, wenn autorisierende DNS-Server länger als 1 Minute blockiert sind. Und Redundanz hilft nicht, wenn die Ursache ein Konfigurationsfehler oder ein Hack ist. Andererseits verwenden viele Clients mit angemessenen TTLs weiterhin die vorherige Konfiguration und werden nie etwas bemerken.

Bei niedrigen TTLs sind hauptsächlich CDN-Dienste und Load Balancer schuld, insbesondere wenn sie CNAME mit kleinen TTLs und Datensätze mit ebenso kleinen (aber unabhängigen) TTLs kombinieren:

  $ fill 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 ein CNAME oder einer der A-Datensätze abläuft, müssen Sie eine neue Anfrage senden. Beide haben eine 30-Sekunden-TTL, die jedoch nicht übereinstimmt. Die tatsächliche durchschnittliche TTL beträgt 15 Sekunden.

Aber warte! Noch schlimmer. Einige Resolver verhalten sich in dieser Situation mit zwei zugehörigen niedrigen TTLs sehr schlecht:

  $ burn 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 funktioniert wahrscheinlich mit BIND. Wenn Sie diese Anfrage weiterhin senden, wird immer eine TTL von 1 zurückgegeben. Im Wesentlichen wird raw.githubusercontent.com 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. Aw. Man hat eine anständige TTL, aber es ist völlig nutzlos. In anderen CNAMEs beträgt die anfängliche TTL 60 Sekunden, aber für akamai.net Domänen akamai.net maximale TTL 20 Sekunden, und keine von ihnen ist in Phase.

Was ist mit Domains, die ständig Apple-Geräte abfragen?

  $ Bohrer 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 Level3-Resolvers die meiste Zeit 1 Sekunde lang 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

 $ fill 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 

safebrowsing.googleapis.com eine TTL von 60 Sekunden, genau wie bei Facebook-Domains. Auch aus Sicht des Kunden werden diese Werte halbiert.

Wie wäre es mit 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 zusätzlicher Anforderungen zu schätzen, die aufgrund eines abgelaufenen Cache-Eintrags gesendet wurden.

47,4% der Anfragen wurden nach Ablauf des vorhandenen Datensatzes gestellt. Das ist unangemessen hoch.

Was wirkt sich auf das Caching aus, wenn die minimale TTL festgelegt ist?



Die X-Achse ist der minimale TTL-Wert. Datensätze mit Quell-TTLs über diesem Wert sind nicht betroffen.

Y-Achse - Prozentsatz der Anforderungen eines Clients, der bereits einen zwischengespeicherten Datensatz hat, der jedoch abgelaufen ist und eine neue Anforderung stellt.

Der Prozentsatz der "zusätzlichen" Anfragen wird von 47% auf 36% reduziert, indem einfach die minimale TTL in 5 Minuten festgelegt wird. Wenn Sie die minimale TTL in 15 Minuten festlegen, wird die Anzahl dieser Anforderungen auf 29% reduziert. Eine minimale TTL von 1 Stunde reduziert sie auf 17%. Der große Unterschied!

Wie wäre es, wenn Sie nichts auf der Serverseite ändern, sondern stattdessen die minimale TTL in Client-DNS-Caches (Router, lokale Resolver) festlegen?



Die Anzahl der erforderlichen Anforderungen wird von 47% auf 34% reduziert, wenn die minimale TTL in 5 Minuten festgelegt wird, auf 25% bei mindestens 15 Minuten und bis zu 13% bei mindestens 1 Stunde. Vielleicht ist der optimale Wert 40 Minuten.

Die Auswirkungen dieser minimalen Änderung sind enorm.

Was sind die Auswirkungen?

Natürlich kann der Dienst an einen neuen Cloud-Anbieter, einen neuen Server oder ein neues Netzwerk übertragen werden, sodass Kunden die neuesten DNS-Einträge verwenden müssen. Und eine ausreichend kleine TTL hilft dabei, einen solchen Übergang reibungslos und nahtlos durchzuführen. Mit dem Übergang zu einer neuen Infrastruktur erwartet niemand, dass Kunden innerhalb von 1 Minute, 5 Minuten oder 15 Minuten zu neuen DNS-Einträgen wechseln. Durch die Festlegung einer Mindestlebensdauer von 40 Minuten anstelle von 5 Minuten wird der Benutzer nicht daran gehindert, auf den Dienst zuzugreifen.

Dies reduziert jedoch die Latenz erheblich und erhöht die Vertraulichkeit und Zuverlässigkeit, wodurch unnötige Anforderungen vermieden werden.

Natürlich sagen RFCs, dass Sie TTL strikt durchsetzen müssen. In Wirklichkeit ist das DNS-System jedoch zu ineffizient geworden.

Wenn Sie mit autorisierenden DNS-Servern arbeiten, überprüfen Sie bitte Ihre TTL. Brauchen Sie wirklich so lächerlich niedrige Werte?

Natürlich gibt es gute Gründe, kleine TTLs für DNS-Einträge festzulegen. Aber nicht für 75% des DNS-Verkehrs, der praktisch unverändert bleibt.

Und wenn Sie aus irgendeinem Grund wirklich eine niedrige TTL für DNS verwenden müssen, stellen Sie gleichzeitig sicher, dass das Caching auf Ihrer Site nicht aktiviert ist. Aus den gleichen Gründen.

Verwenden Sie diese Funktion, wenn Sie über einen lokalen DNS-Cache wie dnscrypt-proxy verfügen , mit dem Sie die minimale TTL festlegen können. Es ist in Ordnung. Es wird nichts Schlimmes passieren. Stellen Sie die minimale TTL zwischen ungefähr 40 Minuten (2400 Sekunden) und 1 Stunde ein. Ziemlich vernünftige Reichweite.