Leistungsvorteile

Einführung: Ursachen und Behebung von DNS-Latenzen

Da Webseiten immer komplexer werden und auf Ressourcen aus zahlreichen Domains verweisen, können DNS-Lookups zu einem erheblichen Engpass beim Surfen werden. Wenn ein Client einen DNS-Resolver über das Netzwerk abfragen muss, kann die einhergehende Latenz erheblich sein. Dies hängt von der Entfernung und der Anzahl der Nameserver ab, die der Resolver abfragen muss. Mehr als zwei sind selten, können aber auftreten. Der folgende Screenshot zeigt beispielsweise die Timings, die vom Tool Page Speed zur Messung der Webleistung erfasst wurden. Jeder Balken steht für eine Ressource, auf die von der Seite verwiesen wird. Die schwarzen Segmente zeigen DNS-Lookups an. Auf dieser Seite werden in den ersten 11 Sekunden, in denen die Seite geladen wird, 13 Lookups durchgeführt. Obwohl mehrere Lookups parallel ausgeführt werden, zeigt der Screenshot, dass fünf serielle Suchzeiten erforderlich sind, was mehrere Sekunden der gesamten Seitenladezeit von 11 Sekunden ausmacht.

Die DNS-Latenz hat zwei Komponenten:

  • Latenz zwischen dem Client (Nutzer) und dem DNS-Auflösungsserver. In den meisten Fällen liegt dies vor allem an den üblichen Einschränkungen der Umlaufzeit (Round Trip Time, RTT) in vernetzten Systemen: geografische Entfernung zwischen Client- und Servermaschinen, Netzwerküberlastung, Paketverlust und lange Sendeverzögerungen (im Durchschnitt eine Sekunde), überlastete Server, Denial-of-Service-Angriffe usw.
  • Die Latenz zwischen der Auflösung von Servern und anderen Nameservern. Diese Latenzquelle wird hauptsächlich durch die folgenden Faktoren verursacht:
    • Cache-Fehler. Wenn eine Antwort nicht aus dem Cache eines Resolvers bereitgestellt werden kann, aber eine rekursive Abfrage anderer Nameserver erforderlich ist, ist die zusätzliche Netzwerklatenz erheblich, insbesondere wenn die autoritativen Server geografisch entfernt sind.
    • Unzureichende Bereitstellung. Wenn DNS-Resolver überlastet sind, müssen sie DNS-Auflösungsanfragen und -antworten in die Warteschlange stellen und möglicherweise Pakete löschen und noch einmal übertragen.
    • Schädlicher Traffic. Selbst wenn ein DNS-Dienst überdimensioniert ist, kann DoS-Traffic die Server zu stark belasten. Auch bei Angriffen nach Kaminsky können Resolver mit Abfragen überflutet werden, die den Cache garantiert umgehen und ausgehende Anfragen zur Lösung erfordern.

Wir glauben, dass der Cache-Fehlerfaktor die Hauptursache für die DNS-Latenz ist, und erläutern ihn weiter unten.

Cache-Fehler

Selbst wenn ein Resolver über zahlreiche lokale Ressourcen verfügt, lassen sich die grundlegenden Verzögerungen im Zusammenhang mit der Kommunikation mit Remote-Nameservern nur schwer vermeiden. Mit anderen Worten: Wenn der Resolver gut genug bereitgestellt ist, sodass Cache-Treffer auf der Serverseite null Zeit in Anspruch nehmen, bleiben Cache-Fehler in Bezug auf die Latenz sehr teuer. Um einen Fehler zu verarbeiten, muss ein Resolver mit mindestens einem, aber häufig mit zwei oder mehr externen Nameservern kommunizieren. Beim Betrieb des Googlebot-Web-Crawlers haben wir eine durchschnittliche Auflösungszeit von 130 ms für antwortende Nameserver festgestellt. Bei vollen 4 bis 6% der Anfragen tritt jedoch einfach eine Zeitüberschreitung auf, da UDP-Paketverluste und Server nicht erreichbar sind. Wenn wir Fehler wie Paketverluste, ungenutzte Nameserver, DNS-Konfigurationsfehler usw. berücksichtigen, beträgt die tatsächliche durchschnittliche End-to-End-Auflösungszeit 300 bis 400 ms. Es gibt jedoch starke Abweichungen und eine langfristige Abweichung.

Obwohl die Cache-Fehlerrate je nach DNS-Server variieren kann, sind Cache-Fehler aus den folgenden Gründen grundlegend schwierig zu vermeiden:

  • Größe und Wachstum des Internets Einfach gesagt, während das Internet wächst, sowohl durch das Hinzufügen neuer Nutzer als auch durch neue Websites, ist der Großteil der Inhalte von grenzwertigem Interesse. Einige Websites (und folglich DNS-Namen) sind zwar sehr beliebt, die meisten sind jedoch nur für wenige Nutzer von Interesse und werden selten aufgerufen. Die meisten Anfragen führen daher zu Cache-Fehlern.
  • Niedrige Gültigkeitsdauer (TTL). Der Trend zu niedrigeren DNS-TTL-Werten bedeutet, dass Auflösungen häufiger gesucht werden müssen.
  • Cache-Isolation. DNS-Server werden in der Regel hinter Load-Balancern bereitgestellt, die Abfragen nach dem Zufallsprinzip verschiedenen Maschinen zuweisen. Dies führt dazu, dass jeder einzelne Server einen separaten Cache betreibt, anstatt im Cache gespeicherte Auflösungen aus einem gemeinsamen Pool wiederzuverwenden.

Risikominderungen

In Google Public DNS haben wir mehrere Ansätze zur Beschleunigung von DNS-Lookups implementiert. Einige dieser Ansätze sind recht Standard, andere sind experimentell:

  • Server angemessen bereitstellen, um die Last durch den Clienttraffic, einschließlich schädlicher Traffic, zu bewältigen.
  • Verhindert DoS- und Verstärkerangriffe. Obwohl es sich dabei hauptsächlich um ein Sicherheitsproblem handelt und weniger als offene Resolver betroffen sind, wirkt sich die Verhinderung von DoS-Angriffen auch auf die Leistung aus, da die zusätzliche Belastung von DNS-Servern entlastet wird. Informationen zu den Ansätzen, die wir verwenden, um die Wahrscheinlichkeit von Angriffen zu minimieren, finden Sie auf der Seite zu den Sicherheitsvorteilen.
  • Load-Balancing für gemeinsam genutztes Caching zur Verbesserung der aggregierten Cache-Trefferquote im Bereitstellungscluster.
  • Weltweite Abdeckung für die Nähe zu allen Nutzern.

Bereitstellungscluster angemessen bereitstellen

DNS-Resolver im Cache müssen teurere Vorgänge ausführen als autoritative Nameserver, da viele Antworten nicht aus dem Speicher bereitgestellt werden können. Stattdessen erfordern sie die Kommunikation mit anderen Nameservern und erfordern daher viel Netzwerkeingabe/-ausgabe. Darüber hinaus sind offene Resolver in hohem Maße anfällig für Cache-Poisoning-Versuche, die die Cache-Fehlerrate (solche Angriffe senden speziell Anfragen für falsche Namen, die nicht aus dem Cache aufgelöst werden können) sowie DoS-Angriffe, die die Traffic-Last erhöhen, erhöhen. Wenn Resolver nicht angemessen bereitgestellt werden und die Last nicht mithalten können, kann sich dies sehr negativ auf die Leistung auswirken. Pakete werden gelöscht und müssen noch einmal übertragen werden, Nameserver-Anfragen müssen in die Warteschlange gestellt werden usw. All diese Faktoren tragen zu Verzögerungen bei.

Daher ist es wichtig, dass DNS-Resolver für die Eingabe/Ausgabe eines hohen Volumens bereitgestellt werden. Dies umfasst die Bewältigung möglicher DDoS-Angriffe, bei denen die einzige effektive Lösung darin besteht, viele Maschinen überdimensionieren zu lassen. Gleichzeitig ist es jedoch wichtig, die Cache-Trefferquote beim Hinzufügen von Computern nicht zu verringern. Dies erfordert die Implementierung einer effektiven Load-Balancing-Richtlinie, die im Folgenden erläutert wird.

Load-Balancing für gemeinsames Caching

Das Skalieren der Resolver-Infrastruktur durch Hinzufügen von Maschinen kann tatsächlich nach hinten losgehen und die Cache-Trefferquote verringern, wenn das Load-Balancing nicht korrekt durchgeführt wird. In einer typischen Bereitstellung befinden sich mehrere Maschinen hinter einem Load-Balancer, der den Traffic mithilfe eines einfachen Algorithmus wie Round Robin gleichmäßig auf jede Maschine verteilt. Dies hat zur Folge, dass jeder Computer einen eigenen unabhängigen Cache unterhält, sodass der im Cache gespeicherte Inhalt auf den Computern isoliert ist. Wenn jede eingehende Abfrage an eine zufällige Maschine verteilt wird, kann die effektive Cache-Fehlerrate je nach Art des Traffics proportional erhöht werden. Bei Namen mit langen TTLs, die wiederholt abgefragt werden, kann die Cache-Fehlerrate beispielsweise durch die Anzahl der Maschinen im Cluster erhöht werden. Bei Namen mit sehr kurzen TTLs, die nur selten abgefragt werden oder zu nicht im Cache speicherbaren Antworten führen (0 TTL und Fehler), wird die Cache-Fehlerrate nicht wirklich durch das Hinzufügen von Maschinen beeinflusst.

Um die Trefferrate für im Cache speicherbare Namen zu erhöhen, ist es wichtig, Server über ein Load-Balancing zu verteilen, damit der Cache nicht fragmentiert wird. In Google Public DNS gibt es zwei Caching-Ebenen. In einem Maschinenpool in der Nähe des Nutzers enthält ein kleiner Cache pro Maschine die beliebtesten Namen. Wenn eine Abfrage nicht von diesem Cache erfüllt werden kann, wird sie an einen anderen Pool von Rechnern gesendet, die den Cache nach Namen partitionieren. Bei diesem Cache der zweiten Ebene werden alle Abfragen für denselben Namen an denselben Computer gesendet, wobei der Name entweder im Cache gespeichert wird oder nicht.

Bereitstellungscluster für eine breite geografische Abdeckung verteilen

Für geschlossene Resolver ist dies kein wirkliches Problem. Bei offenen Resolvern gilt: Je näher sich Ihre Server bei Ihren Nutzern befinden, desto geringer ist die Latenz auf Clientseite. Außerdem kann eine ausreichende geografische Abdeckung auch indirekt die End-to-End-Latenz verbessern, da Nameserver in der Regel Ergebnisse zurückgeben, die für den Standort des DNS-Resolvers optimiert sind. Wenn also ein Inhaltsanbieter gespiegelte Websites auf der ganzen Welt hostet, geben die Nameserver dieses Anbieters die IP-Adresse in der Nähe des DNS-Resolvers zurück.

Google Public DNS wird in Rechenzentren auf der ganzen Welt gehostet und verwendet Anycast-Routing, um Nutzer an das geografisch nächstgelegene Rechenzentrum weiterzuleiten.

Darüber hinaus unterstützt Google Public DNS das EDNS-Client-Subnetz (ECS), eine DNS-Protokollerweiterung für Resolver, die den Clientstandort an Nameserver weiterleitet. Diese können standortabhängige Antworten zurückgeben, die für die tatsächliche Client-IP-Adresse und nicht für die IP-Adresse des Resolvers optimiert sind. Weitere Informationen finden Sie in diesen FAQs. Google Public DNS erkennt automatisch Nameserver, die das EDNS-Client-Subnetz unterstützen.