Eine niedrige DNS-Latenz ist ein entscheidender Faktor für schnelles Arbeiten im Internet. Um sie zu minimieren, ist es wichtig, sorgfältig die DNS-Server auszuwählen und . Doch zuerst sollten überflüssige Anfragen beseitigt werden.
Genau deshalb wurde DNS ursprünglich als ein stark cachierbares Protokoll entwickelt. Zonenadministratoren legen die Lebensdauer (TTL) für einzelne Einträge fest, und Resolvers nutzen diese Informationen zur Speicherung von Einträgen im Speicher, um unnötigen Datenverkehr zu vermeiden.
Ist Caching effektiv? Vor ein paar Jahren hat meine kleine Studie gezeigt, dass es nicht perfekt ist. Lassen Sie uns den aktuellen Stand der Dinge betrachten.
Um Informationen zu sammeln, habe ich gepatcht, um den TTL-Wert für die Antwort zu speichern. Dieser wird als das minimale TTL seiner Einträge für jede eingehende Anfrage definiert. Dies gibt einen guten Überblick über die Verteilung der TTL im echten Datenverkehr und berücksichtigt auch die Beliebtheit einzelner Anfragen. Die geänderte Serverversion lief einige Stunden.
Der resultierende Datensatz besteht aus 1.583.579 Einträgen (name, qtype, TTL, timestamp). Hier ist die Gesamtheit der TTL-Verteilung (X-Achse ist die TTL in Sekunden):
Abgesehen von einem kleinen Anstieg bei 86.400 (hauptsächlich für SOA-Einträge) ist offensichtlich, dass die TTLs im niedrigen Bereich liegen. Schauen wir uns das genauer an:
Nun, TTLs von mehr als 1 Stunde sind statistisch nicht signifikant. Lassen Sie uns daher auf den Bereich 0−3600 konzentrieren:
Die meisten TTLs liegen zwischen 0 und 15 Minuten:
Die überwältigende Mehrheit liegt zwischen 0 und 5 Minuten:
Das ist nicht besonders 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 bei drei Vierteln liegt sie bei 5 Minuten oder weniger.
Aber warten Sie, es ist tatsächlich noch schlimmer. Denn das sind TTLs von autoritativen Servern. Client-Resolver (z. B. Router, lokale Caches) erhalten TTLs von übergeordneten Resolvern, und diese verringern sich jede Sekunde.
Das bedeutet, dass der Client jede Aufnahme im Durchschnitt nur für die Hälfte der ursprünglichen TTL verwenden kann, bevor er eine neue Anfrage sendet.
Könnten diese sehr niedrigen TTLs nur für ungewöhnliche Anfragen gelten und nicht für beliebte Webseiten und APIs? Lassen Sie uns das überprüfen:
Die X-Achse ist TTL, die Y-Achse ist die Popularität von Anfragen.
Leider lassen sich die beliebtesten Anfragen auch am schlechtesten cachen.
Lassen Sie uns näher heranzoomen:
Fazit: Es ist wirklich schlecht. Es war schon vorher schlecht und ist jetzt noch schlimmer geworden. DNS-Caching ist praktisch nutzlos geworden. Da immer weniger Menschen den DNS-Resolver ihres Anbieters verwenden (aus guten Gründen), wird die Verzögerung deutlicher spürbar.
DNS-Caching ist nur für Inhalte nützlich geworden, die niemand besucht.
Bitte beachten Sie auch, dass Software niedrige TTLs interpretieren kann.
Warum ist das so?
Warum wird für DNS-Einträge so ein niedriger TTL-Wert festgelegt?
- Veraltete Lastenausgleicher verwenden die Standardeinstellungen.
- Es gibt Mythen, dass das DNS-Lastenausgleich von TTL abhängt (das ist nicht der Fall – seit den Zeiten von Netscape Navigator wählen Clients eine zufällige IP-Adresse aus einer RR-Gruppe und versuchen transparent eine andere, wenn sie sich nicht verbinden können).
- Administratoren möchten Änderungen sofort anwenden, da sich die Planung so einfacher gestalten lässt.
- Der DNS-Server-Administrator oder Lastenausgleichs-Manager sieht seine Aufgabe darin, die Konfiguration effizient bereitzustellen, die von den Nutzern angefordert wird, anstatt die Leistung von Websites und Services zu optimieren.
- Niedrige TTLs bieten seelische Ruhe.
- Menschen setzen anfangs niedrige TTLs für Tests und vergessen dann, diese zu ändern.
Ich habe die 'Fehlerbehebung bei Ausfällen' nicht aufgenommen, da sie zunehmend irrelevant wird. Wenn es notwendig ist, Nutzer in ein anderes Netz umzugeleiten, nur um eine Fehlerseite anzuzeigen, wenn absolut alles andere ausgefallen ist, ist eine Verzögerung von mehr als 1 Minute wohl akzeptabel.
Darüber hinaus bedeutet eine einminütige TTL, dass, wenn die autoritativen DNS-Server länger als 1 Minute blockiert sind, niemand anderen Zugriff auf abhängige Dienste hat. Und Redundanz hilft nicht, wenn das Problem auf einen Konfigurationsfehler oder einen Hack zurückzuführen ist. Auf der anderen Seite werden bei vernünftigen TTLs viele Kunden die vorherige Konfiguration weiterhin verwenden und niemals etwas bemerken.
Die niedrigen TTL-Werte sind größtenteils auf CDN-Dienste und Lastenausgleich zurückzuführen, insbesondere wenn sie CNAME mit niedrigen TTL-Werten und Einträge mit ebenfalls 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
Jedes Mal, wenn ein CNAME oder einer der A-Einträge abläuft, muss eine neue Anfrage gesendet werden. Beide haben einen TTL von 30 Sekunden, aber sie stimmen nicht überein. Der tatsächliche durchschnittliche TTL beträgt 15 Sekunden.
Aber warte! Es wird noch schlimmer. Einige Resolver verhalten sich in einer solchen Situation mit zwei 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 funktioniert 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. Eins hat eine angemessene TTL, doch das ist völlig nutzlos. In den anderen hat der ursprüngliche TTL nur 60 Sekunden, aber für die Domains akamai.net beträgt die maximale TTL 20 Sekunden, und keiner davon ist in Phase.
Wie sieht es mit den Domains aus, die ständig Apples 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 die TTL bleibt die meiste Zeit bei 1 Sekunde, wenn 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 beträgt der TTL-Wert 60 Sekunden, ebenso wie bei den Facebook-Domains. Und wiederum betrachtet aus der Sicht des Clients, halbieren sich diese Werte.
Wie wäre es mit der Festlegung einer minimalen TTL?
Mit dem Namen, der Anfragetyp, der TTL und dem ursprünglich gespeicherten Zeitstempel habe ich ein Skript geschrieben, um 1,5 Millionen Anfragen zu simulieren, die durch einen Cache-Resolver laufen, um das Volumen an überflüssigen Anfragen zu bewerten, die aufgrund abgelaufener Cache-Einträge gesendet werden.
47,4 % der Anfragen wurden nach Ablauf der bestehenden Einträge gemacht. Das ist unangemessen hoch.
Wie würde sich die Cache-Speicherung auswirken, wenn ein minimaler TTL gesetzt wird?
Die X-Achse zeigt die minimalen TTL-Werte an. 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 Ablaufdatum abgelaufen ist und der eine neue Anfrage macht.
Der Anteil der „überflüssigen“ Anfragen sinkt von 47 % auf 36 % durch einfaches Setzen eines minimalen TTL von 5 Minuten. Bei einem minimalen TTL von 15 Minuten reduziert sich die Anzahl dieser Anfragen auf 29 %. Ein minimaler TTL von 1 Stunde senkt sie auf 17 %. Ein erheblicher Unterschied!
Wie wäre es, wenn wir nichts auf der Serverseite ändern, sondern stattdessen minimale TTLs in den Client-DNS-Caches (Router, lokale Resolver) festlegen?
Die Anzahl der erforderlichen Anfragen sinkt von 47 % auf 34 %, wenn ein minimaler TTL von 5 Minuten eingestellt wird, auf 25 % bei einem Minimum von 15 Minuten und auf 13 % bei einem Minimum von 1 Stunde. Ein optimierter Wert könnte 40 Minuten betragen.
Die Auswirkungen dieser minimalen Änderung sind enorm.
Welche Folgen hat das?
Natürlich kann der Dienst zu einem neuen Cloud-Anbieter, einem neuen Server oder einem neuen Netzwerk migriert werden, wobei von den Kunden erwartet wird, dass sie die neuesten DNS-Einträge nutzen. Ein ausreichend niedriger TTL hilft, einen solchen Übergang sanft und unauffällig zu gestalten. Doch beim Übergang auf neue Infrastruktur wird nicht erwartet, dass die Kunden innerhalb von 1 Minute, 5 Minuten oder 15 Minuten auf neue DNS-Einträge umschalten. Eine Mindestlebensdauer von 40 Minuten anstelle von 5 Minuten hindert die Benutzer nicht daran, auf den Dienst zuzugreifen.
Das würde jedoch die Latenz erheblich reduzieren und die Vertraulichkeit sowie Zuverlässigkeit verbessern, indem unnötige Anfragen vermieden werden.
Natürlich sagen die RFCs, dass der TTL strikt eingehalten werden sollte. Aber die Realität ist, dass das DNS-System zu ineffizient geworden ist.
Wenn Sie mit autoritativen DNS-Servern arbeiten, überprüfen Sie bitte Ihre TTL. Brauchen Sie wirklich so lächerlich niedrige Werte?
Natürlich gibt es gute 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 verä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 den gleichen Gründen.
Wenn Sie einen lokalen DNS-Cache wie betreiben, der minimale TTLs zulässt, nutzen Sie diese Funktion. Das ist in Ordnung. Es wird nichts Schlechtes passieren. Setzen Sie die minimale TTL auf etwa 40 Minuten (2400 Sekunden) bis 1 Stunde. Ein völlig vernünftiger Bereich.
Quelle: habr.com
