Lokale Kopien der DNS-Root-Zone können Resolver-Datenverkehr erhöhen, wie Forscher feststellen

Ein Forschungsprojekt, das im APNIC-PING-Podcast am 3. September 2026 besprochen wurde, hat ergeben, dass das lokale Bereitstellen der DNS-Root-Zone in bestimmten Konfigurationen mehr Netzwerkverkehr erzeugen kann als die gewöhnlichen Abfragen, die es reduzieren soll. Die Arbeit wurde von Ilyas Rahimi durchgeführt, der kürzlich seinen Master in Security and Network Engineering an der Universität Amsterdam (UvA) abgeschlossen hat, sowie von Willem Toorop von NLnet Labs. Ilyas absolvierte das OS3-Masterprogramm an der UvA, das seinen Namen von seinem Fokus auf Open Standards, Open Software und Open Security ableitet. NLnet Labs befindet sich auf dem Campus der UvA, und Willem arbeitet seit vielen Jahren eng mit dem Programm zusammen und betreut während der Masterarbeit studentische Forschung zu DNS und DNSSEC. Im Rahmen des Programms absolvieren die Studierenden zwei einmonatige originäre Forschungsprojekte, wobei das zweite die Grundlage für ihre Masterarbeit bildet.

Die DNS-Root-Zone sitzt an der Spitze der DNS-Hierarchie. Im Alltag ist das DNS (Domain Name System) das Adressbuch des Internets, das benutzerfreundliche Domainnamen in maschinenlesbare Adressen übersetzt. Die Root-Zone ist die oberste Liste aller Domain-Endungen wie .com, .org und Ländercode-Endungen. Ein DNS-Resolver ist der Server oder das Programm, das diese Abfragen im Namen Ihrer Geräte durchführt. Normalerweise fragt ein Resolver die Root-Server, um zu erfahren, welche Top-Level-Domain als Nächstes angefragt werden soll. Lokal bereitgestellte Root ist ein Resolver-Modell, das eine Kopie dieser Root-Zone vorab lädt und speichert. Eine lokale Kopie ermöglicht es Resolvern, Abfragen für nicht existierende Top-Level-Domains schnell zu beenden, und kann einige Datenschutzvorteile bieten, da die Notwendigkeit reduziert wird, die Root-Server für auflösbare Namen anzufragen. Es gibt derzeit einen Vorschlag in der IETF (Internet Engineering Task Force), dies zu einer Best Current Practice zu machen, also einer empfohlenen Vorgehensweise im Internet.

Ilyas untersuchte drei öffentliche Resolver-Codebasen, BIND, Unbound und Knot Resolver, in vier verschiedenen Konfigurationen. Seine Forschung untersuchte sowohl den In-Band-Abruf der Root-Zone, d. h. der Resolver holt die Zone über seinen eigenen DNS-Mechanismus, als auch den Abruf über HTTPS, die verschlüsselte Version des Webprotokolls. Dies sind die beiden Hauptmethoden, mit denen ein Resolver eine Kopie der Root-Zone erhalten kann. Die Wahl der Resolver-Software und der Abrufmethode ist wichtig, weil jede Implementierung die Zone anders behandelt und diese Unterschiede im tatsächlichen Netzwerkverkehr sichtbar werden.

Die Messungen ergaben zwei bemerkenswerte Ergebnisse. Erstens identifizierte Ilyas einen Fehler in Unbound, der einen Anstieg des Datenverkehrs verursachte. Unbound ist ein weit verbreiteter Open-Source-DNS-Resolver, sodass ein Fehler, der zusätzlichen Datenverkehr verursacht, viele Netzwerke betreffen kann. Zweitens stellte er fest, dass der Aktualisierungszyklus der Root-Zone eine überraschend große Menge an Netzwerkverkehr erzeugen kann, wenn die Zone abgerufen wird. In einigen Fällen übertraf dies den Verkehr, der mit den weitaus häufigeren, aber viel kleineren Abfragen an Root-Server für nicht zwischengespeicherte Daten verbunden ist. Mit anderen Worten: Der periodische Download einer vollständigen Root-Zone-Kopie kann die Einsparungen durch den Wegfall vieler kleiner Abfragen überwiegen. Der Kompromiss hängt davon ab, wie oft der Resolver die Zone aktualisiert und wie er sie abruft.

In diesem Bereich gibt es noch mehr zu tun. Da die Masterarbeitskomponente des OS3-Programms nun mehr Zeit im Studiengang erhält, hofft Willem, die Zusammenarbeit mit UvA-Studierenden fortzusetzen und die Messarbeiten auszuweiten. Er hat auch untersucht, wie sich das System bei inkrementellen Zonenaktualisierungen, bekannt als IXFR, verhält, anstatt jedes Mal die gesamte Root-Zone abzurufen. IXFR überträgt nur die geänderten Teile einer DNS-Zone, was die Datenmenge bei jeder Aktualisierung reduzieren könnte. Die Quelle verweist auch auf weiterführende Literatur: Ilyas Rahimis Masterarbeit mit dem Titel "Local root serving by default: Quantifying the traffic trade-off", eine Präsentation, die Ilyas über seine Arbeit bei NLnet Labs hielt, einen IETF-Entwurf für einen BCP-Vorschlag von Warren Kumari mit dem Titel "Populating resolvers with the root zone", ein Beispiel für inkrementell signierte Root-Zustände in einem Git-Repository von Willem Toorop auf codeberg sowie das RSSAC-02-Dokument "Measurements of the Root Server System" von ICANN.

Für normale Internetnutzer und Unternehmen, die einen DNS-Resolver wählen, zeigt diese Forschung, dass das Verhalten des Resolvers nicht neutral ist. Etwas, das effizient klingt, wie das lokale Speichern einer Kopie der Root-Zone, kann unerwartete Verkehrskosten verursachen, je nachdem, wie es implementiert und aktualisiert wird. Es ist eine Erinnerung daran, dass die Software hinter Ihren DNS-Abfragen aktuell gehalten werden sollte, da Fehler zusätzliche Last verursachen können, selbst wenn die Idee solide ist. Für Leser, die einen Resolver möchten, der von Natur aus privat und sicher ist, bietet ein datenschutzorientierter verschlüsselter DNS-Dienst wie AEU DNS DNS über HTTPS, TLS und QUIC mit einer No-Logs-Richtlinie, sodass Ihre Abfragen vertraulich bleiben, während der Betreiber Root-Zonen-Updates im Hintergrund verwaltet. Das bietet Ihnen den Vorteil eines sorgfältig betriebenen Resolvers, ohne dass Sie selbst Zonenaktualisierungsintervalle einstellen oder Resolver-Software debuggen müssen.