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
