DNS-Dienst Quad9 hat massive Lastprobleme in Frankfurt

Sie nutzen Quad9 als DNS-Resolver und Webseiten bauen sich neuerdings laaaangsam auf? Wir haben beim beliebten DNS-Anbieter nachgehakt.

In Pocket speichern vorlesen Druckansicht 111 Kommentare lesen

(Bild: designium/Shutterstock.com)

Lesezeit: 3 Min.

Der gemeinnützige DNS-Dienst Quad9 scheint am eigenen Erfolg zu leiden: Derzeit ist der für Deutschland zuständige Servercluster in Frankfurt massiv überlaufen. Auf DNS-Anfragen reagiert er momentan zu einem sehr hohen Prozentsatz gar nicht, zeitweise erreicht der Verlust mit einem Drittel (30-35%) ein exorbitantes Niveau. Antworten kommen gelegentlich erst nach ein bis zwei Sekunden.

Wenn der kürzlich in die datenschutzfreundlichere Schweiz umgezogene Dienst als einziger DNS-Resolver im Router hinterlegt ist, verzögern Loss und hohe Latenz beispielsweise den vollständigen Aufbau von Webseiten erheblich. Denn der DNS-Resolver muss erst Domainnamen wie ct.de zu IP-Adressen (193.99.144.80 und 2a02:2e0:3fe:1001:302::) übersetzen, bevor Browser Seitenelemente laden können.

Der Effekt wirft auch Fritzboxen aus der Bahn, auf denen Quad9 mit dem verschlüsselnden Protokoll DNS over TLS (DoT) als Resolver (Übersetzer zwischen Domainnamen und IP-Adressen) eingerichtet ist. Einem Leser half dann nur, seinen Router die Internetverbindung neu aufbauen zu lassen – was bei 50 DoT-Abrissen binnen einer Woche schnell lästig wird.

Das Linux-Tool dnsping deckt auf, dass Quad9s Servercluster in Frankfurt zurzeit massive Lastprobleme hat. Woher die DNS-Antwort kommt, erschließt sich mit einem "dig +nsid @9.9.9.10 ct.de | grep NSID". Dabei fällt der Name des jeweiligen Resolvers heraus, beispielsweise res720.fra.rrdns.pch.net.

Die gegenwärtige Quad9-Unzuverlässigkeit führt nicht nur in Netzen hinter Routern zu einem scheinbar sehr langsamen Internet, sondern auch wenn man es direkt auf dem Smartphone als DNS-Resolver eingerichtet hat: Bei ausbleibender Antwort stellen Clients ihre Namensanfragen nach einem Timeout – typischerweise 5 Sekunden – erneut. Wenn sie dann eine Antwort bekommen, können sie beispielsweise für Webseiten endlich Bilder oder eingebettete Elemente anderer Sites nachladen. Je höher der Loss, desto langsamer wird die Seite komplett aufgebaut.

Die c't-Redaktion hat schon vor zwei Wochen mit unverschlüsselten DNS-Anfragen einen ungewöhnlich hohen Loss im einstelligen Prozentbereich beobachtet, vereinzelt auch mehr, und dies an den Quad9-Support gemeldet. Der nannte ein stetig wachsendes DNS-Anfragevolumen als Grund für die Aussetzer des Frankfurter Clusters. Quad9 arbeite daran, die Kapazität in Frankfurt zu erhöhen und neue Server netztechnisch in der Nähe zu aktivieren, um diese Region besser zu versorgen.

Seitdem hat sich wenig gebessert. Am Vormittag des 29. September maßen wir mit dem Linux-Tool dnsping 23 Prozent Verlust bei einer mittleren Antwortzeit von 135 Millisekunden. Andere Systeme antworten typischerweise in unter 20 ms und mit weit geringerem Loss (maximal 0,1 Prozent). Auf unsere erneute Anfrage hieß es seitens Quad9, es würden gerade neue Server für den Frankfurter Cluster vorbereitet. Als gemeinnützige Non-Profit-Organisation sei man auf Spenden seiner Nutzerschaft angewiesen und könne die Infrastruktur nicht in der gleichen Geschwindigkeit ausbauen wie kommerzielle Anbieter.

Wer derzeit Quad9 als alleinigen DNS-Resolver einsetzt und einen trägen Webseitenaufbau feststellt, sollte vorübergehend auf einen anderen Dienst ausweichen – und eventuell für die Ertüchtigung der Quad9-Infrastruktur spenden (Link auf der Quad9-Seite). Die Lage kann man aber auch damit entspannen, dass man in der Konfiguration des jeweiligen Routers oder Software-Clients einfach weitere Resolver einträgt. Das ist beim Software-Client Stubby auch deshalb empfehlenswert, weil er die DNS-Anfragen an die eingetragenen Resolver streut und so die Privatsphäre noch etwas besser schützt.

(ea)