DNSSEC-Root-Key-Rollover für den 11. Oktober 2026 angesetzt

DNSSEC ist das System digitaler Signaturen, mit dem ein Computer überprüfen kann, ob eine Antwort, die er vom Domain Name System erhalten hat, echt ist, und einer seiner wichtigsten Schlüssel steht kurz vor dem Austausch. Diese Änderung war eines von vier Themen, die auf der APNIC 62 diskutiert wurden, der Konferenz des Asia Pacific Network Information Centre, die vom 4. bis 10. September 2026 in Mumbai, Indien, stattfand, wo Netzbetreiber, Forscher und Experten für Internetinfrastruktur zusammenkamen, um Betriebserfahrungen und aktuelle Herausforderungen auszutauschen. APNICs Bericht über die Technical Session 1, Internet Operations, wurde von George Michaelson am 21. September 2026 veröffentlicht.

Marcin Siodelski, ein leitender Softwareentwickler beim Internet Systems Consortium (ISC), stellte Stork vor, ein neues Management-Tool. Die DHCP- und BIND-Software von ISC ist seit Jahrzehnten zentral für die Bereitstellung von Internetdiensten, und obwohl die Organisation heute vielleicht am besten für den Betrieb des globalen F-Root-DNS-Dienstes bekannt ist, bleibt die Softwareentwicklung ein Kernbestandteil ihrer Mission. BIND 9 treibt weiterhin DNS-Dienste weltweit an, sowohl als autoritativer Server (die Maschine, die die offiziellen Einträge einer Domain hält) als auch als rekursiver Resolver (die Maschine, die Antworten im Auftrag eines Nutzers nachschlägt). Kea DHCP ersetzt den alten ISC-DHCP-Server, der das Ende seiner Lebensdauer erreicht hat. Da DHCP-Umgebungen, also die Systeme, die automatisch Netzwerkadressen vergeben, komplex sein können, wird Stork als bedeutender Fortschritt präsentiert: eine grafische Managementplattform, die mit BIND 9 und PowerDNS sowie mit Prometheus und Grafana für Monitoring, Reporting, Dashboards und eine webbasierte Verwaltungsschnittstelle integriert ist.

DHCP bleibt ein grundlegender Bestandteil der Netzwerkdienstbereitstellung. Es verwaltet Pools von IP-Adressen, weist Subnetze zu und pflegt statische Adress- und Präfixzuweisungen für bestimmte Maschinen, die durch MAC-Adressen (die in eine Netzwerkkarte eingebaute Hardwarekennung) oder Client-Identifikatoren identifiziert werden. Über Kea können Betreiber Hochverfügbarkeitskonfigurationen, Failover-Systeme, Lease-Verfolgung und Protokollinspektion verwalten, und Marcin demonstrierte Grafana-Integrationen, Subnetzverwaltungsschnittstellen und Konfigurationswerkzeuge. DNS-Management ist eine relativ neue Ergänzung für Stork, und seine Integration mit BIND 9 ermöglicht es Betreibern, komplexe DNS-Umgebungen über eine einzige Schnittstelle zu verwalten, zu überwachen und zu berichten, was Transparenz über große Serverbereitstellungen hinweg schafft und hilft, Betriebsteams und DNS-Infrastruktur zu verbinden. Die aktuellen Funktionen konzentrieren sich auf Monitoring, Konfigurationsansichten, Zonen-Browsing und Zonentransfer-Überwachung, einschließlich der Erkennung von Seriennummern-Abweichungen zwischen Servern, die anzeigen, dass zwei Kopien derselben Zone auseinandergedriftet sind. Die PowerDNS-Integration ist noch experimentell und zielt darauf ab, eine einheitliche Verwaltungserfahrung über gemischte Bereitstellungen hinweg zu bieten. Weitere Funktionen sind geplant, darunter die Erkennung und Entfernung veralteter DNS-Einträge in dynamischen DNS-Umgebungen, was eng mit der DHCP-Pool-Verwaltung zusammenhängt, sowie Zonenklonung und -validierung, Bearbeitung der BIND 9-Konfiguration, Unterstützung für DNS-Katalogzonen und erweitertes BIND 9-Protokollmonitoring. Diese Funktionen sollen im Laufe von 2026 und 2027 veröffentlicht werden.

Champika Wijayatunga, ICANNs Technical Engagement Director für den asiatisch-pazifischen Raum, erklärte den bevorstehenden Rollover des DNSSEC-Root-Key-Signing-Key (KSK), der für den 11. Oktober 2026 geplant ist. Er legte die DNSSEC-Vertrauenskette dar, die auf dem Trust Anchor der Root-Zone beruht. Ein Trust Anchor steht an der Spitze der Hierarchie und kann nicht gegen einen anderen Schlüssel validiert werden: Systeme müssen so konfiguriert werden, dass sie ihn als vertrauenswürdigen Ausgangspunkt behandeln, als Axiom. Der Schlüssel, der ausgetauscht wird, ist die öffentliche Hälfte eines Paares aus öffentlichem und privatem Schlüssel; der private Schlüssel bleibt offline in ICANN-verwalteten Hardware-Sicherheitsmodulen an sicheren Einrichtungen an der Ost- und Westküste der Vereinigten Staaten. Private Schlüssel erzeugen die kryptografischen Signaturen über DNS-Daten, während veröffentlichte öffentliche Schlüssel es Resolvern ermöglichen, die Authentizität, Integrität und Vollständigkeit dieser Daten zu überprüfen. Regelmäßige Rollovers gelten als gute Betriebspraxis: Sie reduzieren langfristige Sicherheitsrisiken und ermöglichen die Einführung stärkerer Algorithmen und Schlüssellängen, wenn sich die Technologie weiterentwickelt, was für aufkommende Bedrohungen wie Quantencomputing wichtig ist, die die effektive Lebensdauer von RSA-Schlüsselpaaren verkürzen könnten. ICANN führt das Schlüsselmanagement durch öffentliche Schlüsselzeremonien an beiden Einrichtungen durch, an denen Trusted Community Representatives teilnehmen, und die Zeremonien werden live gestreamt. Unter normalen Umständen würde Schlüsselmaterial alle drei bis vier Jahre erneuert, obwohl dieser Rollover verzögert wurde. Betreiber, die DNSSEC-Validierung durchführen, müssen sicherstellen, dass ihre Resolver-Systeme ihre Trust Anchors aktuell halten: Viele Systeme aktualisieren automatisch über RFC 5011, aber einige Bereitstellungen erfordern manuellen Eingriff, und Wijayatunga betonte, wie wichtig es ist, zu überprüfen, wie sich Resolver während und nach dem Rollover verhalten. Aktualisierte Trust Anchors sind bei IANA erhältlich und können unabhängig von RFC 5011-Updates validiert werden.

Geoff Huston, Chief Scientist von APNIC, untersuchte die anhaltenden Herausforderungen des X.509-Zertifikatsmanagements, des Systems, das die von HTTPS und TLS verwendeten Authentifizierungs- und Datenschutzmechanismen untermauert. Ein Zertifikat ist die Bestätigung der Identität durch einen Dritten: Die ausstellende Zertifizierungsstelle ist eine private Organisation, die kryptografische Berechtigungsnachweise auf der Grundlage von Informationen erstellt, die von Antragstellern geliefert werden, und sie ist nicht unbedingt die Behörde, die einen Firmennamen, einen Domainnamen oder irgendeine andere Form von Identität ausgestellt hat. Am Beispiel einer nicht autorisierten Banking-Website stellte Huston eine einfache Frage: Verhindert der Widerruf von Zertifikaten tatsächlich, dass Menschen eine kompromittierte Website nutzen? Am Beispiel von www.westpac.com.au zeigte er, dass die Domain auf eine von Amazon gehostete Infrastruktur aufgelöst wird und nicht auf eine direkt von Westpac betriebene Infrastruktur, und dass die Website ein Zertifikat verwendet, das vor mehr als neun Monaten von DigiCert ausgestellt wurde. Über einen solchen Zeitraum könnten verschiedene Sicherheitsvorfälle auftreten, darunter die Kompromittierung der Zertifizierungsstelle, der Diebstahl eines Schlüssels oder ein operativer Fehler, und das Schwierige ist, wie ein Zertifikat ungültig gemacht werden kann, wenn eines dieser Ereignisse eintritt.

Der traditionelle Mechanismus ist die X.509-Certificate Revocation List (CRL), die die Seriennummern von Zertifikaten veröffentlicht, denen nicht mehr vertraut werden sollte; im Prinzip ruft ein Browser die Liste ab, validiert ihre Signatur und prüft, ob das ihm vorliegende Zertifikat dort erscheint. Huston zeigte ein Beispiel einer Liste, die wöchentlich aktualisiert wurde und 17.527 widerrufene Zertifikate enthielt. In der Praxis ist der Prozess viel zu langsam, um eine routinemäßige Browser-Validierung zu unterstützen: Er ist technisch solide, wird aber selten wie ursprünglich beabsichtigt verwendet. Das Online Certificate Status Protocol (OCSP), definiert in RFC 2560, bot eine Alternative durch Echtzeit-Statusabfragen, schafft jedoch Datenschutzbedenken, indem es die Browsing-Aktivität offenlegt, und birgt potenzielle Denial-of-Service-Risiken durch zentralisierte Abfragen, und seine Bereitstellung bleibt unvollständig und inkonsistent. HTTPS und TLS unterstützen auch OCSP-Stapling, bei dem ein Server während des TLS-Handshakes eine signierte OCSP-Antwort liefert; das verbessert den Datenschutz und reduziert die Latenz, doch ein kompromittierter Server wird kaum einen Nachweis dafür liefern, dass sein eigenes Zertifikat widerrufen wurde, was die Wirksamkeit des Mechanismus einschränkt. Die Browser-Unterstützung variiert erheblich. Let's Encrypt, heute die weltweit größte Zertifizierungsstelle, stellte seine OCSP-Dienste 2025 ein, nachdem es über Akamai mehr als 140.000 Anfragen pro Sekunde bearbeitet hatte, und die Unterstützung für Must Staple verschwand praktisch gleichzeitig. Chrome hat sich 2014 nicht mehr auf OCSP verlassen und Stapling nie als primären Validierungsmechanismus übernommen, während Safari einen anderen Ansatz verfolgt.

Huston testete die Zertifikatsausstellung und -widerrufung mit Let's Encrypt innerhalb eines siebentägigen CRL-Veröffentlichungszyklus. Das widerrufene Zertifikat erschien tatsächlich auf der Liste, aber Chrome und Safari erkannten den Widerruf nicht. Firefox tat es. Angesichts des Marktanteils von Chrome und Safari bleibt die Zertifikatswiderrufung in der Praxis weitgehend unwirksam. Eine Reaktion war die Verkürzung der Zertifikatslebensdauern: Let's Encrypt hat die Gültigkeit von Zertifikaten von 90 Tagen auf 45 Tage reduziert, und einige Zertifizierungsstellen stellen jetzt Zertifikate mit einer Gültigkeit von nur sechs Tagen aus. Huston argumentierte, dass selbst dies unzureichend ist, weil Sicherheitsvorfälle in Millisekunden auftreten, während Zertifikatslebensdauern noch in Tagen gemessen werden. Als Alternative schlug er die Nutzung von DNS und seinen eingebauten Cache-Ablaufmechanismen vor. DANE (DNS-based Authentication of Named Entities), kombiniert mit DNSSEC, ermöglicht die Veröffentlichung von Schlüsselmaterial mit viel kürzeren Lebensdauern, und es existiert auch ein gestapeltes DANE-Modell, das Funktionalität ähnlich wie X.509-Zertifikate und OCSP-Stapling bietet. Er kam zu dem Schluss, dass die Erreichung wirklich kurzlebiger Web-Anmeldeinformationen einen Wechsel weg vom X.509-Ökosystem hin zu DNSSEC-basierten Vertrauensmodellen erfordern könnte, und dass die Herausforderung darin besteht, von einer Infrastruktur, die um Zertifikatslebensdauern in Tagen herum entworfen wurde, zu einer zu gelangen, die fast sofort auf Bedrohungen reagieren kann.

Ritesh Mukherjee, ein Produktmanagement-Leiter für NOS und KI bei Nokia, diskutierte die nächste Stufe der Sicherheit für BGP, das Protokoll, mit dem Netzwerke sich gegenseitig mitteilen, welche Adressen sie erreichen können. Route Origin Validation (ROV) überprüft, ob ein Netzwerk autorisiert ist, eine Route zu originieren, während Autonomous System Provider Authorization (ASPA) hilft, die Integrität des AS-Pfads zu validieren, der Liste der Netzwerke, die eine Route durchläuft. Er präsentierte mehrere Beispiele für Routing-Vorfälle.

Eines betraf Reliance (AS18101), das Telegram-Präfixe blackholte. Das RIPE RIS-System erkannte das Ereignis schnell als falsche Routenoriginierung, und Telegram reagierte mit der Ankündigung spezifischerer Präfixe, die AS18101 ebenfalls propagierte; weil diese Ankündigungen über Indien hinausgingen, wählten Übersee-Netzwerke scheinbar kürzere Pfade. Der Vorfall wurde zu einem BGP-Hijack, weil Daten des Internet Routing Registry zeigten, dass AS18101 nicht autorisiert war, die betroffenen Routen zu originieren, und ROV hätte das Problem erkannt und eine breitere Ausbreitung verhindert. Dennoch erzwingen derzeit nur 27 % der autonomen Systeme ROV, und die Akzeptanz in Indien bleibt besonders niedrig. Ein zweites Beispiel betraf SingNet (AS3758): Eine Routenankündigung von AS17894 wurde von AS37100 gefiltert, aber der Verkehr wurde dennoch über Sparkle (AS6762) umgeleitet, das eine spezifischere Route propagierte. Seacom hatte ROV aktiviert, aber seine Abhängigkeit von Sparkle verringerte den Nutzen, was zeigt, wie teilweise Bereitstellung blinde Flecken schafft, die es Hijacks ermöglichen, in Teilen der default-free zone zu bestehen, dem Kern des Internets, der Verkehr ohne Ausweichpfad weiterleitet. Ein dritter Fall war ein Route Leak von Vodafone Idea (AS55410), das Tausende von Präfixen ankündigte, die Bharti Airtel (AS9498) anschließend propagierte, was zu weitverbreiteter Verkehrsfehlleitung in Richtung AS55410 führte. Geringe ROV-Akzeptanz, begrenzte Pfadfilterung und das Fehlen von Maximum-Prefix-Kontrollen trugen alle zum Ausmaß dieses Vorfalls bei.

Diese Beispiele veranschaulichen Routing-Sicherheitsherausforderungen, die Netzwerke im asiatisch-pazifischen Raum seit fast zwei Jahrzehnten betreffen. Die ROV-Bereitstellung in der Region bleibt hinter anderen Regional Internet Registry-Regionen zurück, obwohl einige Volkswirtschaften, darunter Vietnam, Indonesien und die Philippinen, stärkere Bereitstellungsniveaus erreicht haben; Indien hat 88 % Route Origin Authorization-Abdeckung erreicht, aber die Durchsetzung bleibt begrenzt. Mukherjee schlug ein dreiteiliges Schutzmodell vor: BMP zur Anomalieerkennung, ASPA zur Pfadvalidierung und ROV mit Durchsetzung. Er hob auch RAVEN hervor, Nokias BGP Routing Security Monitor, der über Nokias GitHub-Repository verfügbar ist und Betreibern hilft, ihre Routing-Sicherheitsexposition zu bewerten, bevor sie Blockierungsrichtlinien durchsetzen. RAVEN läuft als einzelne Binärdatei, empfängt Routing-Daten über BMP und kann mit RPKI-Validatoren wie Routinator integriert werden; es unterstützt auch Grafana-Dashboards, Webhooks, FlowSpec-Integration und Kommandozeilen-Audits. Die Bereitstellung von BMP am Adj-RIB-In, der Tabelle der von einem Nachbarn empfangenen Routen, bevor Richtlinien angewendet werden, bietet Einblick in das Routing-Verhalten und kann Betreibern helfen, bessere Nachbarn zu werden. Er befürwortete nachdrücklich Maximum-Prefix-Limits auf eBGP-Sitzungen, um zu verhindern, dass Route Leaks die Routing-Infrastruktur überlasten, und ermutigte zur langfristigen Bereitstellung von ASPA, von ROV mit Drop-Richtlinien und zur aktiven Teilnahme an MANRS.

Für alltägliche Nutzer laufen die Themen der Sitzung alle auf Vertrauen hinaus: die Schlüssel, die DNS-Antworten signieren, die Zertifikate, die beweisen sollen, dass eine Website die ist, die sie zu sein vorgibt, und die Routing-Informationen, die entscheiden, ob der Verkehr den richtigen Ort erreicht. Die meisten Heimrouter und Provider-Resolver werden die DNSSEC-Schlüsseländerung automatisch handhaben, aber wer seinen eigenen Resolver betreibt oder von jemandem abhängt, der dies tut, sollte nach dem 11. Oktober 2026 prüfen, ob die Validierung noch funktioniert, denn ein Resolver, der stillschweigend aufhört zu validieren, hat einen Schutz verloren, den er zuvor hatte. Für Leser, die lieber überhaupt nicht von einem Provider-Resolver abhängen möchten, ist AEU DNS ein privater, verschlüsselter DNS-Dienst, und seine öffentliche Dokumentation beschreibt die DNSSEC-Validierung und den No-Logs-Ansatz, den er bietet, sodass jeder die Details prüfen und entscheiden kann, ob er zu ihm passt.