Leistungsvorteile

Einführung: Ursachen und Risikominderungen der DNS-Latenz

Da Webseiten immer komplexer werden und auf Ressourcen aus vielen Domains verweisen, können DNS-Lookups einen erheblichen Engpass bei der Suche verursachen. Wenn ein Client einen DNS-Resolver über das Netzwerk abfragen muss, kann dies je nach Nähe und Anzahl der Nameserver, die der Resolver abfragen muss, sehr hoch sein. Häufig sind mehr als zwei Nameserver vorhanden, können aber auftreten. Im folgenden Screenshot sehen Sie als Beispiel die Zeitangaben, die vom Tool für die Geschwindigkeit auf der Website erfasst wurden. Jeder Balken stellt eine Ressource dar, auf die von der Seite verwiesen wird. Die schwarzen Segmente kennzeichnen DNS-Lookups. Auf dieser Seite werden innerhalb der ersten elf Sekunden, in denen die Seite geladen wird, 13 Lookups durchgeführt. Obwohl mehrere der Suchvorgänge parallel durchgeführt werden, zeigt der Screenshot, dass fünf serielle Suchzeiten erforderlich sind, wobei mehrere Sekunden der Seitenladezeit berücksichtigt werden.

Es gibt zwei Komponenten für die DNS-Latenz:

  • Latenz zwischen dem Client (Nutzer) und dem DNS-Auflösungsserver In den meisten Fällen hängt das mit den üblichen Einschränkungen für Umlaufzeiten in vernetzten Systemen zusammen: geografische Entfernung zwischen Client- und Servermaschinen, Netzwerküberlastung, Paketverlust und lange erneute Übertragungsverzögerungen (im Durchschnitt eine Sekunde), überlastete Server, Denial-of-Service-Angriffe usw.
  • Latenz zwischen dem Auflösen von Servern und anderen Nameservern. Diese Latenzquelle ist vor allem auf die folgenden Faktoren zurückzuführen:
    • Cache-Fehler. Wenn eine Antwort nicht aus dem Resolver-Cache bereitgestellt werden kann, aber rekursiv die Abfrage anderer Nameserver erfordert, ist die erhöhte Netzwerklatenz erheblich, insbesondere wenn die autoritativen Server geografisch remote entfernt sind.
    • Unzureichende Bereitstellung Wenn DNS-Resolver überlastet sind, müssen sie Anfragen und Antworten zur DNS-Auflösung in die Warteschlange stellen und beginnen, Pakete zu löschen und noch einmal zu übertragen.
    • Schädlicher Traffic. Auch wenn ein DNS-Dienst überdimensioniert ist, kann DoS-Traffic eine übermäßige Belastung der Server verursachen. Ebenso können Angriffe im Stil von Kaminsky Flood Resolver mit Abfragen umfassen, die garantiert den Cache umgehen und ausgehende Anfragen zur Lösung erfordern.

Wir sind der Meinung, dass der Cache-Fehlerfaktor die Hauptursache für die DNS-Latenz ist. Darauf gehen wir weiter unten ein.

Cache-Fehler

Selbst wenn ein Resolver über ausreichende lokale Ressourcen verfügt, lassen sich die grundlegenden Verzögerungen bei der Kommunikation mit Remote-Nameservern nur schwer vermeiden. Mit anderen Worten: Wenn der Resolver gut genug bereitgestellt wird, damit Cache-Treffer serverseitig keine Zeit benötigen, bleiben Cache-Fehler in Bezug auf die Latenz sehr teuer. Zum Beheben eines Fehlers muss ein Resolver mit mindestens einem, aber oft zwei oder mehr externen Nameservern kommunizieren. Der Googlebot-Web-Crawler hat eine durchschnittliche Auflösung von 130 ms für Nameserver festgestellt, die darauf reagieren. Bei vollen 4–6% der Anfragen kommt es jedoch einfach zu einer Zeitüberschreitung, da der UDP-Paketverlust verloren geht und Server nicht erreichbar sind. Wenn wir Fehler wie Paketverlust, tote Nameserver, DNS-Konfigurationsfehler usw. berücksichtigen, beträgt die tatsächliche durchschnittliche End-to-End-Auflösungszeit 300 bis 400 ms. Es gibt jedoch eine hohe Varianz und einen Longtail.

Obwohl die Cache-Fehlerrate bei DNS-Servern variieren kann, sind Cache-Fehler aus den folgenden Gründen grundsätzlich schwierig zu vermeiden:

  • Internetgröße und Wachstum. Ganz einfach, im Zuge des Wachstums des Internets, sowohl durch das Hinzufügen neuer Nutzer als auch über neue Websites, sind die meisten Inhalte von geringem Interesse. Einige Websites (und folglich auch die DNS-Namen) sind zwar sehr beliebt, die meisten sind jedoch nur für wenige Nutzer interessant. Sie werden selten aufgerufen, sodass die meisten Anfragen zu Cache-Fehlern führen.
  • Niedrige Gültigkeitsdauer (TTL). Der Trend hin zu niedrigeren DNS-TTL-Werten bedeutet, dass Auflösungen häufiger gesucht werden müssen.
  • Cache-Isolierung. DNS-Server werden normalerweise hinter Load-Balancern bereitgestellt, die Abfragen nach dem Zufallsprinzip verschiedenen Maschinen zuweisen. Dies führt dazu, dass jeder einzelne Server einen separaten Cache behält, anstatt die im Cache gespeicherten Auflösungen aus einem gemeinsamen Pool wiederverwenden zu können.

Risikominderungen

In Google Public DNS haben wir verschiedene Ansätze implementiert, um die DNS-Lookup-Zeiten zu verkürzen. Einige dieser Ansätze sind eher Standard, andere sind experimentell:

  • Bereitstellung von Servern ordnungsgemäß, um die Last aus dem Client-Traffic einschließlich schädlichem Traffic zu bewältigen.
  • DoS- und Verstärkungsangriffe verhindern Dies ist zwar vor allem ein Sicherheitsproblem und betrifft geschlossene Resolver weniger als offene. Allerdings bietet die Verhinderung von DoS-Angriffen auch einen Leistungsvorteil, da die zusätzliche Belastung des DNS-Servers entfällt. Informationen zu den Ansätzen, mit denen wir die Wahrscheinlichkeit von Angriffen minimieren, finden Sie auf der Seite zu den Sicherheitsvorteilen.
  • Load-Balancing für gemeinsames Caching, um die aggregierte Cache-Trefferquote im Bereitstellungscluster zu verbessern
  • Globale Abdeckung für Nähe zu allen Nutzern

Entsprechende Bereitstellungscluster bereitstellen

Caching-DNS-Resolver müssen teurere Vorgänge ausführen als autoritative Nameserver, da viele Antworten nicht aus dem Arbeitsspeicher verarbeitet werden können. Stattdessen erfordern sie eine Kommunikation mit anderen Nameservern und erfordern daher eine hohe Netzwerkeingabe/-ausgabe. Außerdem sind offene Resolver sehr anfällig für Cache-Vergiftungsversuche, die die Cache-Fehlerrate erhöhen (solche Angriffe senden insbesondere Anfragen für gefälschte Namen, die nicht aus dem Cache aufgelöst werden können) sowie DoS-Angriffe, die die Traffic-Auslastung erhöhen. Wenn Resolver nicht angemessen bereitgestellt werden und nicht mit der Last Schritt halten können, kann sich dies sehr negativ auf die Leistung auswirken. Pakete werden gelöscht, 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 Ein- und Ausgabe mit hohem Volumen bereitgestellt werden. Dazu gehört auch der Umgang mit möglichen DDoS-Angriffen, deren einzige effektive Lösung eine Überdimensionierung mit vielen Computern ist. Gleichzeitig ist es jedoch wichtig, die Cache-Trefferquote nicht zu verringern, wenn Sie Maschinen hinzufügen. Dazu ist die Implementierung einer effektiven Load-Balancing-Richtlinie erforderlich, die wir weiter unten besprechen.

Load-Balancing für gemeinsames Caching

Durch das Skalieren der Resolver-Infrastruktur durch Hinzufügen von Maschinen können die Cache-Trefferquote tatsächlich reduziert und die Cache-Trefferquote verringert werden, wenn das Load-Balancing nicht ordnungsgemäß ausgeführt wird. In einer typischen Bereitstellung befinden sich mehrere Maschinen hinter einem Load-Balancer, der Traffic mithilfe eines einfachen Algorithmus wie Round Robin gleichmäßig auf jede Maschine verteilt. Das führt dazu, dass jede Maschine einen eigenen unabhängigen Cache unterhält, sodass die im Cache gespeicherten Inhalte auf den Computern isoliert werden. Wenn jede eingehende Abfrage auf 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 beispielsweise die Cache-Fehlerrate durch die Anzahl der Maschinen im Cluster erhöht werden. (Bei Namen mit sehr kurzen TTLs, die sehr selten abgefragt werden oder zu nicht im Cache speicherbaren Antworten (0 TTL und Fehler) führen, wird die Cache-Fehlerrate beim Hinzufügen von Computern nicht beeinflusst.

Um die Trefferrate für im Cache speicherbare Namen zu erhöhen, ist es wichtig, dass ein Load-Balancing für Server ausgeführt wird, damit der Cache nicht fragmentiert ist. In Google Public DNS gibt es zwei Ebenen des Cachings. In einem Maschinenpool, der sich in unmittelbarer Nähe zum Nutzer befindet, enthält ein kleiner Cache pro Computer die beliebtesten Namen. Wenn eine Abfrage in diesem Cache nicht erfüllt werden kann, wird sie an einen anderen Maschinenpool gesendet, der den Cache nach Namen partitioniert. Bei diesem Cache der zweiten Ebene werden alle Abfragen nach demselben Namen an den gleichen Computer gesendet, auf dem der Name entweder im Cache gespeichert ist oder nicht.

Bereitstellungscluster für eine breite geografische Abdeckung verteilen

Bei geschlossenen Resolvern stellt das kein Problem dar. Bei offenen Resolvern gilt: Je näher sich deine Server an den Nutzern befinden, desto weniger Latenz wird ihnen auf der Clientseite angezeigt. Darüber hinaus kann eine ausreichende geografische Abdeckung die End-to-End-Latenz indirekt erhöhen, da Nameserver in der Regel Ergebnisse zurückgeben, die für den Standort des DNS-Resolvers optimiert sind. Wenn also ein Contentanbieter 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 weltweit in Rechenzentren gehostet und verwendet Anycast-Routing, um Nutzer zum geografisch nächstgelegenen Rechenzentrum weiterzuleiten.

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