Könnte DNS die Sicherheitslücken im Internet-Routing lösen? Frische Ideen vom IETF 126

Die Internet Engineering Task Force (IETF) versammelte sich Ende Juli 2026 in Wien zu ihrer 126. Tagung, bei der Netzwerkingenieure seit langem bestehende Herausforderungen bewältigten, wie Internetverkehr seinen Weg rund um den Globus findet. Im Mittelpunkt dieser Diskussionen stand das Border Gateway Protocol (BGP), das System, mit dem Netzwerke bekannt geben, welche IP-Adressen sie kontrollieren und wie sie zu erreichen sind. Obwohl es für normale Nutzer oft unsichtbar ist, können die Sicherheitsschwächen von BGP zu Verkehrshijacking, Überwachung und Ausfällen führen. In diesem Jahr tauchte eine frische Idee auf: die Verwendung des Domain Name Systems (DNS), um Vertrauen in Routing-Ankündigungen zu bringen.

Ein Thema, das Aufmerksamkeit erregte, war die unerwartete Manipulation des BGP-ORIGIN-Attributs. Wenn ein Router mehrere Pfade zum selben Ziel hat, verwendet er einen strengen achtstufigen Entscheidungsprozess, um den besten auszuwählen. Nach dem Vergleich lokaler Präferenzen und der AS-Pfadlänge schaut er auf den ORIGIN-Code, ein Label, das anzeigen sollte, wie eine Route ursprünglich in BGP gelangte. Die drei Möglichkeiten sind ‚i‘ (aus einem internen Routing-Protokoll gelernt), ‚e‘ (vom inzwischen veralteten Exterior Gateway Protocol) und ‚?‘ (unvollständig, typischerweise von statischen Routen). Theoretisch sollte dieser Code nach dem Setzen nie geändert werden, aber Forscher zeigten in der IEPG-Sitzung, dass einige Netzwerke ihn umgeschrieben haben. Indem sie Routen auf den Wert ‚e‘ ändern, zwingen sie andere Router, bestimmte Pfade zu priorisieren und die übliche AS-Pfadlängen-Vergleich zu übergehen. Diese Praxis trat erstmals 2023 auf und wächst: Messungen sehen den EGP-Origin-Wert jetzt bei einem bemerkenswerten Prozentsatz der BGP-Ankündigungen. Ein Betreiber gab offen zu, diesen Trick zu nutzen, um Verkehr von entfernten Routern fernzuhalten, und nutzte dabei die höhere Priorität von ORIGIN im Auswahlalgorithmus. Doch wenn jedes Netzwerk dasselbe täte, würde der Vorteil verschwinden, ein klassischer Fall von „es funktioniert nur, wenn ich der Einzige bin, der es tut“.

Bemühungen, BGP mit kryptografischer Sicherheit zu versehen, laufen seit über zwei Jahrzehnten, aber der Fortschritt ist langsam. Das AS_PATH-Attribut, das die Kette der autonomen Systeme (AS) auflistet, die eine Route durchlaufen hat, ist besonders anfällig für Fälschungen. Bestehende Lösungen wie BGPsec signierten den vollständigen Pfad, kämpften jedoch mit teilweiser Bereitstellung: Wenn ein Hop auf dem Weg es nicht unterstützte, brach die Signaturkette. Ein neuerer Ansatz ist die Autonomous System Provider Authorization (ASPA), bei der jedes AS eine Liste seiner vorgelagerten Provider veröffentlicht. Idealerweise wird jede AS-Beziehung bekannt, sodass unplausible Pfade erkannt werden können, wie ein Kundennetzwerk, das sich als Transit-Provider ausgibt. Allerdings erzeugt die teilweise Bereitstellung in einer Welt, in der nur einige tausend ASPA-Objekte in der Resource Public Key Infrastructure (RPKI) veröffentlicht wurden, Mehrdeutigkeit. Ist eine fehlende Beziehung ein Peer, ein Tier-1-Netzwerk ohne Provider oder einfach ein AS, das seine Daten nicht veröffentlicht hat? Zur Unterstützung können Netzwerke AS0 als Provider auflisten, um zu signalisieren, dass sie transitfrei sind, aber die Interpretation bleibt komplex. Der ASPA-Entwurf hat in fast zehn Jahren 27 Überarbeitungen durchlaufen, doch Router-Hersteller haben bei der Implementierung gezögert und warten auf einen stabilen RFC, bevor sie Ressourcen binden.

Vor diesem Hintergrund bietet PAVA (PAth VAlidation) ein deutlich einfacheres Modell, und es stützt sich stark auf das DNS. Die Kernidee besteht darin, einen AS-Pfad in überlappende Tripletts (und Endpaare) zu zerlegen. Beispielsweise wird ein Pfad aus vier AS zu drei Tripletts, die jeweils ein Zwei- oder Drei-Schritt-Segment darstellen. Jedes AS würde dann seine angrenzenden Beziehungen in seiner eigenen DNS-Zone veröffentlichen und DNSSEC für Authentizität nutzen. Die DNS-Einträge würden angeben, ob jede Verbindung eine ‚aufwärts‘- (Kunde-zu-Provider), ‚abwärts‘- (Provider-zu-Kunde) oder ‚Gipfel‘- (Peer-zu-Peer) Beziehung ist. Durch die Überprüfung dieser Einträge können BGP-Router erkennen, ob ein Pfad eine ungültige Sequenz enthält, wie einen Sprung von einem Provider zu einem anderen ohne Aufwärts-Abwärts-Übergang. Da DNSSEC-Signaturen an dieselben kryptografischen Schlüssel gebunden werden können, die bereits im Vertrauensanker von RPKI gespeichert sind, wird die Validierung nahtlos. Dieser Ansatz macht nicht nur ein separates, ressourcenhungriges Synchronisationsprotokoll überflüssig (die derzeitige Achillesferse der RPKI), sondern ermöglicht auch eine inkrementelle Bereitstellung: Wenn ein AS keine PAVA-Einträge veröffentlicht, wird der Pfad einfach als nicht validiert behandelt und nicht blockiert. Die Präsentation beim IETF 126 zeigte, wie DNS, eine global skalierte und robuste Infrastruktur, die Last der effizienten Verteilung von Routing-Sicherheitsdaten übernehmen könnte.

Für normale Internetnutzer sind diese Debatten über Routing-Sicherheit wichtiger, als sie scheinen mögen. Wenn BGP-Pfade gekapert werden, ob versehentlich oder böswillig, kann Verkehr über Abhörpunkte umgeleitet oder vollständig ausgelöscht werden. Ein DNS-basiertes Validierungssystem wie PAVA würde solche Angriffe erheblich erschweren, insbesondere in Kombination mit einer weiten Verbreitung von DNSSEC. In der Zwischenzeit können Einzelpersonen Maßnahmen ergreifen, um ihre eigene Gefährdung zu reduzieren. Die Verwendung eines datenschutzorientierten DNS-Resolvers, der DNSSEC und verschlüsselten Transport (wie DoH oder DoT) unterstützt, stellt sicher, dass der erste Schritt jeder Verbindung, der DNS-Lookup, authentifiziert und vor neugierigen Blicken geschützt ist. AEU DNS bietet beispielsweise DNS-over-HTTPS mit integrierter Werbe- und Tracker-Blockierung und hilft Benutzern, bösartige Domains zu vermeiden, die in Routing-Angriffen verwendet werden könnten. Während das IETF diese Vorschläge weiter verfeinert, beginnt ein vertrauenswürdigeres Internet mit einfachen, benutzerseitigen Entscheidungen, die die End-to-End-Sicherheit stärken.