Sicherung der DNS-Root: Test von sechs Namensschemata und der Weg zum DNSSEC-Schutz

Jedes Mal, wenn Sie eine Webadresse in Ihren Browser eingeben, wird ein globales System namens Domain Name System (DNS) im Hintergrund aktiv. Seine Aufgabe ist es, menschenfreundliche Namen wie „example.com“ in die numerischen IP-Adressen zu übersetzen, die Computer verwenden, um einander zu finden. An der Spitze dieser Hierarchie stehen die Root-Server, eine Reihe von autoritativen Verzeichnissen, die Anfragen an den richtigen Teil des Internets weiterleiten. Es gibt 13 verschiedene Root-Server-Identitäten, die mit A bis M unter der Domäne `root-servers.net` bezeichnet werden. Obwohl es sich nur um 13 Maschinen anhört, teilen sich in Wirklichkeit Tausende von Servern auf der ganzen Welt diese Identitäten mithilfe einer Technik namens Anycast, die Ihre Anfrage aus Gründen der Geschwindigkeit und Ausfallsicherheit an die nächstgelegene verfügbare Instanz weiterleitet.

Die Domäne `root-servers.net` wurde 1995 erstellt und liegt wie jede andere Domäne innerhalb der Top-Level-Domäne (TLD) `.net`. Diese Anordnung erzeugt ein klassisches Henne-Ei-Problem: Um einen Root-Server zu finden, muss ein DNS-Resolver (die Software, die Adressen für Sie nachschlägt) zuerst den Namen dieses Root-Servers auflösen, aber um einen Namen zu finden, der auf `.net` endet, muss er einen Root-Server fragen, wo die `.net`-Zone zu finden ist. Diese zirkuläre Abhängigkeit wird durch einen cleveren Trick aufgebrochen: Wenn ein Resolver zum ersten Mal startet, erhält er eine spezielle Antwort namens Priming-Response, die zusätzliche Daten enthält, die als Glue-Records bekannt sind. Diese Datensätze liefern die direkten IP-Adressen der Root-Server, sodass der Resolver sie sofort kontaktieren kann, ohne in einer Endlosschleife stecken zu bleiben.

Die Priming-Response ist kritisch, hat aber eine Sicherheitsschwäche: Die darin enthaltenen Glue-Records sind nicht durch DNSSEC (Domain Name System Security Extensions) geschützt. DNSSEC fügt DNS-Daten digitale Signaturen hinzu, sodass Resolver überprüfen können, dass die erhaltenen Informationen authentisch und nicht von einem Angreifer manipuliert wurden. Da die Glue-Records unsigniert sind, könnte ein böswilliger Akteur theoretisch einem Resolver gefälschte Root-Server-Adressen zuführen und seine gesamte Sicht auf das Internet kapern. Diese Sorge führte zu einer technischen Analyse namens RSSAC 028, die 2017 für ICANN erstellt wurde und das Namensschema der Root-Server untersuchte sowie prüfte, ob DNSSEC auf `root-servers.net` angewendet werden könnte. Das Hinzufügen von DNSSEC-Signaturen würde die Priming-Response vertrauenswürdig machen, könnte aber auch die Größe der Antwort über das seit langem bestehende 512-Byte-Limit des älteren UDP-Protokolls hinaus aufblähen, das für DNS verwendet wird, was möglicherweise die Abwärtskompatibilität mit vielen älteren Geräten und Netzwerken bricht.

Fast ein Jahrzehnt später bleibt die Frage weiterhin Gegenstand aktiver Forschung. In einer kürzlichen Folge des PING-Podcasts diskutierte der Forscher Willem Toorop von NLnet Labs eine Messstudie, die in Zusammenarbeit mit SIDN durchgeführt wurde und sechs Kandidaten-Namensschemata für die Root-Server testete. Das Ziel war zu sehen, welcher Ansatz das Hinzufügen von DNSSEC am besten unterstützen würde, während die Priming-Response klein genug bleibt, um in ein einzelnes 512-Byte-UDP-Paket zu passen, eine entscheidende Anforderung, um sicherzustellen, dass das globale DNS weiterhin reibungslos für alle funktioniert, unabhängig vom Alter ihrer Ausrüstung. Die Studie produzierte zwei detaillierte Berichte: einen im Jahr 2023 von SIDN Labs und einen Folgebericht im Jahr 2024, der sich mit den in RZERC 002 identifizierten Risiken befasst. Beide Berichte sind jetzt öffentlich verfügbar, und die in den Experimenten verwendete Resolver-Testumgebung wird von NLnet Labs auf GitHub gepflegt.

Die Ergebnisse zeigten einige unerwartete Ergebnisse. Die Anwendung von DNSSEC auf das aktuelle Namensschema würde die Priming-Response tatsächlich über die Größenbeschränkung hinaus treiben, was Fragmentierung und Ausfälle in älteren Netzwerken riskiert. Bestimmte alternative Namenskonventionen könnten jedoch die notwendigen Informationen kompakter verpacken, sodass es machbar wird, die Antwort zu signieren, ohne die Größenbeschränkung zu brechen. Die Studie hob auch hervor, dass die Sicherung der Root-Server-Namen das Risiko von umgeleitetem Abfrageverkehr erheblich reduzieren würde, bei dem ein Angreifer einen Resolver dazu bringt, Abfragen an einen unechten Server zu senden. Obwohl keine sofortige Änderung am Root-Server-Namenssystem geplant ist, liefert die Forschung eine wichtige Evidenzbasis für die Internet Engineering Task Force (IETF) und die breitere Gemeinschaft, um die Kompromisse zwischen Sicherheit, Kompatibilität und betrieblicher Einfachheit abzuwägen.

Für normale Internetnutzer mögen diese tiefgreifenden Infrastrukturdebatten weit vom täglichen Surfen entfernt erscheinen. Doch sie betreffen direkt die Vertrauenswürdigkeit jedes Website-Besuchs, E-Mail-Checks und App-Updates. Während das Rätsel der Root-Server-Benennung gelöst wird, können Sie jetzt Schritte unternehmen, um Ihre eigene DNS-Sicherheit zu stärken. Die Verwendung eines modernen verschlüsselten DNS-Protokolls wie DNS-over-HTTPS (DoH) oder DNS-over-TLS (DoT) verhindert, dass Lauscher und Angreifer Ihre DNS-Abfragen ausspionieren oder verändern. Viele datenschutzorientierte Resolver, einschließlich AEU DNS, bieten DoH und DoT mit integrierter DNSSEC-Validierung an, was Ihnen eine sofortige Schutzschicht gegen Adress-Spoofing und Verkehrsabfangen bietet. Durch die Annahme eines solchen Dienstes tragen Sie dazu bei, dass Ihr Gerät immer den richtigen Internet-Wegweisern folgt, auch während sich das globale DNS hin zu einer stärkeren Authentifizierung seiner Wurzel entwickelt.