Was am 11. Oktober 2026 passiert
DNSSEC sichert Antworten im Domain Name System über eine Kette von Signaturen ab. An ihrem oberen Ende steht der Key Signing Key der Root-Zone, kurz KSK. Ein validierender Resolver vertraut diesem Schlüssel nicht, weil er ihn irgendwo abfragt, sondern weil er ihn lokal als Vertrauensanker gespeichert hat. Jede Signaturprüfung, von der Root über die Top-Level-Domain bis zur einzelnen Domain, führt auf diesen Anker zurück. Deshalb ist der Wechsel des Root-KSK so heikel: Stimmt der gespeicherte Anker nicht mit dem Schlüssel überein, der die Root-Zone signiert, kann der Resolver nichts mehr als echt bestätigen. Wie die Kette im Einzelnen geprüft wird und welche Fehlerbilder es gibt, beschreibt der Beitrag DNSSEC-Validierung überwachen.
Der Wechsel läuft seit Langem. Die aktuelle Umstellung begann 2024, der neue Schlüssel wurde am 11. Januar 2025 erstmals in der Root-Zone veröffentlicht (ICANN). Seitdem stehen beide Schlüssel nebeneinander in der Zone, signiert hat bisher der alte KSK-2017. Am 11. Oktober 2026 dreht sich das um: Dann veröffentlicht die Root-Zone DNSKEY-Datensätze, die ausschließlich KSK-2024 signiert (Verisign). Jeder validierende Resolver, der KSK-2024 bis dahin nicht in seine Vertrauensanker aufgenommen hat, bekommt ab diesem Tag Fehler bei der Namensauflösung (Verisign). ICANN formuliert es noch deutlicher: Ohne den neuen Schlüssel drohen vollständige Ausfälle der Namensauflösung, die den Nutzern eines Netzes den Internetzugang abschneiden (ICANN). Es ist erst der zweite Wechsel dieses Schlüssels in der Geschichte des DNS (ICANN).
Ergänzend hat ICANN am 11. August 2026 einen aktualisierten Leitfaden veröffentlicht, der erklärt, was Betreiber vor, während und nach dem Rollover erwarten sollten (ICANN). Er richtet sich ausdrücklich an drei Gruppen: an Betreiber validierender Resolver, an Hersteller von DNS-Software und an Betreiber mit manuell konfigurierten Vertrauensankern (ICANN). Wer einen Server mit eigenem Resolver betreibt, gehört zur ersten Gruppe, oft ohne es zu wissen.
Der 11. Oktober 2026 (ICANN) ist ein Sonntag. Wer am Wochenende keine Bereitschaft hat, erfährt von einem Ausfall womöglich erst am Montagmorgen, wenn sich die Warteschlange des Mailservers gefüllt hat und die ersten Bestellungen ohne Zahlungsbestätigung liegen geblieben sind. Die Prüfung gehört deshalb in die Woche davor, nicht in die Woche danach.
Warum die Website grün bleibt, während der Server blind wird
Eine Website zu erreichen und aus einer Website heraus etwas zu erreichen, sind zwei verschiedene Wege. Ein Besucher, der Ihre Adresse aufruft, fragt den Resolver seines Zugangsanbieters oder seines Unternehmensnetzes nach der IP-Adresse. Ihr Server beantwortet danach eine HTTP-Anfrage, für die er selbst keinen Namen auflösen muss. Eine Verfügbarkeitsprüfung von außen folgt genau diesem Weg und meldet deshalb am Stichtag weiter Grün, selbst wenn der Resolver auf Ihrem Server seit Stunden jede Anfrage mit SERVFAIL beantwortet. Anders sieht es aus, sobald der Server selbst nach draußen will. Dann fragt er den Resolver, der in seiner Konfiguration eingetragen ist, und genau der kann nach dem Stichtag scheitern. Betroffen sind vor allem diese vier Wege:
Ein Mailserver sucht für jede ausgehende Nachricht den MX-Eintrag des Empfängers. Scheitert die Auflösung, bleiben Rechnungen, Links zum Zurücksetzen von Passwörtern und Bestellbestätigungen in der Warteschlange liegen, bis die Zustellversuche aufgeben.
Datenabgleiche, Feed-Exporte, Sicherungen auf einen entfernten Speicher: Alles, was einen Hostnamen anspricht, bricht mit einer Meldung wie „Could not resolve host“ ab. Ohne Überwachung fällt das erst auf, wenn die Daten fehlen.
Ausgehende Webhooks an eine Warenwirtschaft, ein CRM oder ein Ticketsystem erreichen ihr Ziel nicht mehr. Viele Systeme versuchen es einige Male erneut und verwerfen die Nachricht dann, ohne dass im Shop ein Fehler sichtbar wird.
Die Kasse ruft beim Zahlungsdienstleister eine Autorisierung ab, die Versandlogik holt Tarife und Etiketten. Beides braucht die Namensauflösung. Die Startseite lädt, der Bestellabschluss scheitert.
Genau diese Asymmetrie macht den Rollover zu einem Monitoring-Thema und nicht nur zu einem Punkt auf der Liste der Administration. Wer ausschließlich prüft, ob die Startseite antwortet, misst die Richtung, die am 11. Oktober intakt bleibt. Aufschlussreicher ist die Frage, ob der Server selbst noch Namen auflösen und Verbindungen nach draußen aufbauen kann. Wie ein Ausfall der Validierungskette in der Praxis aussieht, zeigte schon der Ausfall der .de-Zone: Auch dort lag der Fehler nicht auf den betroffenen Websites, sondern in der Kette darüber, und die Folgen hingen davon ab, welchen Resolver ein System nutzte.
Wie weit die Umstellung schon ist
Die gute Nachricht zuerst: Die meisten Resolver sind vorbereitet. Mehr als 95 Prozent der meldenden Resolver haben KSK-2024 laut Auswertung von ICANN erkannt und übernommen, und die Kurve verläuft fast genauso wie beim erfolgreichen Rollover 2018 (ICANN). Verisign kommt zu einem ähnlichen Bild: Nach rund 500 Tagen zeigen beide Umstellungen eine Übernahme des neuen Schlüssels von über 95 % (Verisign). Grundlage dieser Zahlen sind Vertrauensanker-Signale nach RFC 8145, die Resolver an die Root-Server senden (Verisign). Das ist eine Stichprobe der Resolver, die solche Signale überhaupt schicken, Stand Juli 2026 (Verisign), und keine Vollerhebung aller Resolver im Netz. Die Tabelle stellt beide Umstellungen nebeneinander:
| Merkmal | Rollover 2018 | Rollover 2026 |
|---|---|---|
| Neuer Schlüssel | KSK-2017 | KSK-2024 |
| Umstellung | Oktober 2018, ein Jahr später als geplant (ICANN) | 11. Oktober 2026 (ICANN) |
| Übernahme nach rund 500 Tagen | über 95 % (Verisign) | über 95 % (Verisign) |
| Messgrundlage | Signale nach RFC 8145, damals deutlich kleinere Stichprobe (Verisign) | Signale nach RFC 8145, Stichprobe Stand Juli 2026 (Verisign) |
| Vorlauf | Verschiebung um ein Jahr nach Datenlage (ICANN) | Ein 2023 erzeugter Schlüssel wurde verworfen, die Hardware hatte das Ende ihrer Unterstützung erreicht (Verisign) |
Warum erst jetzt? Die Root-Zone ist seit 2010 mit DNSSEC signiert, ihr KSK wurde 2018 zum ersten Mal gewechselt (Verisign). Ursprünglich sollte der Schlüssel alle drei Jahre wechseln (Verisign). Die Pandemie unterbrach 2021 die Schlüsselzeremonien vor Ort (Verisign), und ein 2023 erzeugter Schlüssel musste wieder verworfen werden, weil die Hardware-Sicherheitsmodule, die ihn schützen, das Ende ihrer Unterstützung erreicht hatten (Verisign). Erst danach entstand der heutige KSK-2024.
Die schlechte Nachricht steckt im Rest. Etwa 3,5 % der signalisierenden Quellen halten noch KSK-2010, einen Schlüssel, der 2010 erzeugt und 2019 widerrufen wurde (Verisign). Das zeigt, wie lange ein veralteter Anker überlebt, wenn eine Konfiguration einmal eingefroren ist. Dazu kommt: Die Stichprobe erfasst nur Resolver, die Signale senden. Ein Mailserver in einer lange nicht angefassten virtuellen Maschine oder eine Appliance im Serverschrank eines Mittelständlers taucht in keiner Statistik auf. Für die eigene Infrastruktur hilft deshalb keine Quote, sondern nur ein Blick in die Konfiguration. ICANN rät ausdrücklich dazu, die Konfiguration von Hand zu prüfen, statt anzunehmen, dass die automatische Aktualisierung funktioniert hat (ICANN).
Welche Server besonders gefährdet sind
Gefährdet ist nicht, wer DNSSEC für die eigene Domain eingeschaltet hat, sondern wer DNSSEC-Antworten validiert. Das sind in der Regel Resolver, die auf dem Server selbst oder im eigenen Netz laufen. Besonders genau hinsehen sollten Sie bei diesen Konstellationen:
- Server mit lokalem validierendem Resolver - Mailserver setzen häufig einen eigenen Resolver ein, damit Abfragen für DANE oder Sperrlisten verlässlich funktionieren. Genau diese Resolver validieren.
- Container-Images mit mitgelieferter Ankerdatei - die Datei zeigt den Stand vom Bautag. Stammt das Image aus der Zeit vor Januar 2025, als der neue Schlüssel erstmals in der Root-Zone veröffentlicht wurde (ICANN), kann KSK-2024 darin fehlen, bis das Image neu gebaut wird.
- Appliances und eingebettete Systeme - Firewalls, Router und Speichersysteme mit fest eingebautem Anker bekommen einen neuen Schlüssel nur über ein Firmware-Update.
- Resolver ohne Schreibrechte auf ihr Ankerverzeichnis - die automatische Aktualisierung erkennt den neuen Schlüssel, kann ihn aber nicht dauerhaft speichern (ICANN).
- Manuell gepflegte Vertrauensanker - etwa in einer statischen Konfigurationsdatei, die bei der Einrichtung einmal kopiert wurde. Der ICANN-Leitfaden nennt Betreiber mit manuell konfigurierten Ankern ausdrücklich (ICANN).
- Systeme, die kurz vor dem Stichtag aus einem alten Abbild neu entstehen - ihnen fehlt die Zeit, den Schlüssel automatisch zu übernehmen.
Nach dem Verfahren aus RFC 5011 muss ein Resolver einen neuen Schlüssel 30 Tage lang beobachten, bevor er ihm automatisch vertraut (ICANN). Verisign ergänzt die Bedingung, dass er ihn in dieser Zeit auch validieren können muss (Verisign). Daraus folgt eine unbequeme Rechnung: Ein Resolver, der mit einem alten Anker erst in den letzten 30 Tagen vor dem 11. Oktober gestartet wird, schafft die automatische Übernahme nicht mehr rechtzeitig. Wird er nach dem Stichtag gestartet, fehlt ihm von Anfang an die Grundlage, den neuen Schlüssel zu validieren. Für neu aufgesetzte Systeme gilt deshalb: Der Anker muss schon im Abbild stimmen.
Checkliste: den Vertrauensanker prüfen
Der Schlüssel, nach dem Sie suchen, hat den Key Tag 38696 (ICANN). Verisign nennt denselben Wert als Kennung des richtigen Schlüssels (Verisign). Wo er steht, hängt von der Resolver-Software ab: bei ISC BIND in bind.keys, bei Unbound und PowerDNS Recursor in root.key, bei Knot Resolver in root.keys (ICANN). Die Pfade unterscheiden sich je nach Distribution und Paket, die Dateinamen sind aber ein guter Einstieg für die Suche. Gehen Sie für jeden Server mit eigenem Resolver diese Schritte durch:
- Resolver bestimmen: Welcher Resolver steht in /etc/resolv.conf oder in der Konfiguration des Netzwerkdienstes? Zeigt der Eintrag auf 127.0.0.1 oder eine Adresse im eigenen Netz, betreiben Sie selbst einen Resolver oder nutzen einen im Unternehmen. Steht dort 127.0.0.53, arbeitet der lokale Stub von systemd-resolved: Ob er selbst validiert, legt seine Konfiguration fest, und seine Weiterleitung zeigt, welcher Resolver dahinter steht.
- Ankerdatei finden und den Key Tag 38696 darin nachweisen. Fehlt er, ist der Resolver nicht vorbereitet.
- Zustand ablesen, wo die Software ihn ausweist: Unbound führt in seiner Ankerdatei zu jedem Schlüssel einen Zustand nach RFC 5011. Für KSK-2024 sollte dort VALID stehen, nicht ADDPEND.
- Schreibrechte prüfen: Der Resolver-Prozess muss in das Verzeichnis schreiben dürfen, in dem er seine Schlüssel ablegt, sonst bleibt die automatische Aktualisierung wirkungslos (ICANN).
- Automatische Aktualisierung einschalten, wo sie abgeschaltet ist, oder die Software aktualisieren. Aktuelle Versionen werden laut Verisign in den meisten Fällen mit KSK-2024 ausgeliefert oder haben ihn über RFC 5011 übernommen (Verisign).
- Ergebnis festhalten: Datum, Server, Datei, gefundener Key Tag. Diese Notiz ist am Montag nach dem Stichtag mehr wert als jede Erinnerung.
Die dig-Abfrage zeigt mit dem Flag ad, dass Ihr Resolver die Antwort validiert hat. Bis zum 11. Oktober signiert aber noch der alte Schlüssel, und ein Resolver, der nur KSK-2017 kennt, besteht diesen Test genauso. Aussagekräftig für den Stichtag ist allein der Nachweis von Key Tag 38696 im Anker. Das ad-Flag lohnt sich trotzdem, und zwar am Tag danach: als schneller Beleg, dass die Validierung nach der Umstellung weiter funktioniert.
Container-Images und Appliances: der Anker von gestern
Die größte Gefahr liegt selten auf dem Server, den jemand täglich pflegt. Sie liegt in Abbildern, die irgendwann gebaut und danach nur noch gestartet werden. Ein Container-Image, das einen Resolver samt Ankerdatei enthält, konserviert den Stand seines Bautags. Läuft der Container lange genug, kann RFC 5011 den Anker zur Laufzeit nachziehen, sofern der Prozess schreiben darf und das Verzeichnis nicht bei jedem Neustart verworfen wird. Wird der Container dagegen regelmäßig neu erzeugt, beginnt jeder Start wieder beim alten Anker, und die Beobachtungszeit fängt jedes Mal von vorn an. Nach dem 11. Oktober wird aus diesem Schönheitsfehler beim ersten Start ein vollständiger Ausfall der Namensauflösung. Am einfachsten fangen Sie das beim Bau ab:
# Anker beim Bau aktualisieren; unbound-anchor endet auch dann mit 1, wenn es den Anker neu gesetzt hat
RUN unbound-anchor -a /var/lib/unbound/root.key || true
# Bau abbrechen, wenn der Vertrauensanker KSK-2024 nicht enthält
RUN grep -q 38696 /var/lib/unbound/root.key \
|| (echo "Vertrauensanker ohne Key Tag 38696"; exit 1)Bei Appliances ist der Weg kürzer und zugleich schwieriger. Kürzer, weil es nur einen Ansprechpartner gibt, den Hersteller. Schwieriger, weil der Anker oft in der Firmware steckt und nur mit einem Update wechselt. Fragen Sie für jede Firewall, jeden Router und jedes Speichersystem mit eingebautem DNS nach, ob die installierte Version KSK-2024 enthält. Dass solche Nachzügler kein theoretisches Problem sind, zeigt die Vorgeschichte: Der erste Rollover war für 2017 geplant und wurde um ein Jahr verschoben, weil viele Betreiber ihre Systeme noch nicht auf den neuen Schlüssel umgestellt hatten (ICANN). Verisign nutzte die Zeit auch, um Softwareentwickler anzusprechen, die den Schlüssel in ihrem Code nicht aktualisiert hatten (Verisign).
Was am Stichtag schiefgehen kann und woran Sie es erkennen
Ein fehlender Anker kündigt sich nicht an. Bis zum Stichtag läuft alles normal, danach scheitern Namensauflösungen, sobald der Resolver die Schlüssel der Root-Zone neu abruft und sie nicht mehr bestätigen kann. Weil Antworten im Cache bis zum Ablauf ihrer Gültigkeitsdauer weiterverwendet werden, kommt der Ausfall nicht zwingend in der ersten Minute. Er kann zeitversetzt einsetzen und zunächst nur einzelne Namen treffen. Das macht die Fehlersuche mühsam: Ein Dienst funktioniert noch, der nächste nicht, und der Zusammenhang mit dem Rollover ist nicht offensichtlich. Diese Symptome sind typisch:
| Symptom | Wo es auffällt | Was eine Prüfung von außen zeigt |
|---|---|---|
| SERVFAIL bei Abfragen über den lokalen Resolver | Protokoll des Resolvers, Kommandozeile | nichts, die Website antwortet normal |
| „Could not resolve host“ in Cronjob-Ausgaben | Mail an den Cron-Benutzer, die selbst nicht zugestellt wird | nichts |
| Wachsende Mail-Warteschlange | Mailserver, Nachfragen zu fehlenden Bestätigungen | nichts |
| Zeitüberschreitungen beim Bezahlen | Kasse, Fehlerprotokoll der Anwendung | nur, wenn der Bestellprozess selbst geprüft wird |
| Ausbleibende Webhooks | Empfängersystem, oft erst Tage später | nichts |
Die letzte Spalte ist der Kern des Problems. Eine Verfügbarkeitsprüfung von außen ist für diesen Fehler blind, weil sie den Weg nutzt, der intakt bleibt. Hinzu kommt ein Nebeneffekt, der den Schaden vergrößern kann: Scheitert eine Namensauflösung erst nach einer Wartezeit, halten Anfragen ihre Prozesse länger fest. Hängen genug Seitenaufrufe an einer Schnittstelle, deren Name nicht mehr aufgelöst wird, füllt sich der Pool der Worker, und irgendwann antwortet auch die Website langsam oder gar nicht mehr. Wie sich das in den Antwortzeiten zeigt, bevor der erste 502 kommt, beschreibt der Beitrag zum vollen Worker-Pool.
So hilft XICTRAQ und wo die Grenze liegt
Ein besonders verlässlicher Melder für einen Resolver, der nicht mehr auflöst, ist ein Signal, das der Server selbst nach draußen schicken muss. Genau so arbeitet das Heartbeat-Monitoring von XICTRAQ: Ein Cronjob auf Ihrem Server ruft in einem festen Rhythmus eine Ping-Adresse auf. Kommt der Ping innerhalb der eingestellten Toleranz nicht an, löst XICTRAQ einen Alarm aus. Der Aufruf braucht einen Hostnamen und damit die Namensauflösung des Servers. Kann dessen Resolver nach dem Stichtag nicht mehr validieren, bleibt der Ping aus, und genau das ist das Signal, das Sie brauchen. Grundlagen und Muster für solche Überwachungen beschreibt der Beitrag über Heartbeat-Monitoring für Cronjobs.
#!/bin/sh
# Prüft die Namensauflösung über den Resolver dieses Servers und
# meldet sich nur, wenn alle Namen aufgelöst werden.
# Beispielnamen durch die eigenen Schnittstellen ersetzen.
for host in zahlung.example.invalid versand.example.invalid; do
getent hosts "$host" >/dev/null || exit 1
done
curl -fsS --max-time 10 \
https://api.xictraq.com/api/heartbeat/IHRE-ID/ping >/dev/null
# Crontab-Eintrag, alle fünf Minuten:
# */5 * * * * /usr/local/bin/dns-heartbeat.shDie Schleife über die Hostnamen Ihrer wichtigsten Schnittstellen ist dabei mehr als eine Verdopplung. Der Ping würde auch ohne sie ausbleiben, weil api.xictraq.com ebenfalls aufgelöst werden muss. Die Schleife fängt aber den Fall ab, in dem ein Name noch aus dem Cache kommt und ein anderer schon scheitert. Mit getent nutzt das Skript denselben Weg über die Systemkonfiguration wie Mailserver, PHP und die meisten anderen Programme auf dem Server. Eine sofortige Fehlermeldung über die Fail-Adresse hilft in diesem Fall übrigens nicht, denn auch sie braucht einen aufgelösten Namen. Hier ist das Ausbleiben das Signal. Wie Sie Start, Ende und Fehlschlag eines Laufs getrennt melden, beschreibt die Dokumentation der Heartbeat-Schnittstelle.
Zweiter Baustein ist das API-Monitoring. XICTRAQ ruft dabei einen Endpunkt von außen auf und prüft die Antwort, etwa den HTTP-Status, die Antwortzeit oder einen Wert im JSON. Das lässt sich für den Rollover nutzen: Legen Sie auf Ihrem Server einen kleinen Prüf-Endpunkt an, der intern die Namen Ihrer Zahlungs- und Versandschnittstellen auflöst und das Ergebnis als JSON zurückgibt, zum Beispiel in einem Feld dns_ok. XICTRAQ misst dann den Endpunkt, der Endpunkt misst Ihren Resolver. Die Startseite bleibt grün, der Prüf-Endpunkt meldet den Fehler, und der Alarm läuft über dieselben Kanäle wie alle anderen, die Sie in der Alarmierung eingerichtet haben.
Dritter Baustein ist das DNS- und Domain-Monitoring mit DNSSEC-Prüfung. Sie fragt Ihre Domain über einen öffentlichen, validierenden Resolver ab und wertet aus, ob dieser die Antwort als authentifiziert bestätigt. Damit wissen Sie, ob Ihre eigene Zone von außen sauber validiert. Einen einmaligen Blick darauf erlaubt auch das öffentliche Werkzeug zur DNSSEC-Prüfung einer Domain. Für den Rollover ist das eine hilfreiche Abgrenzung: Validiert Ihre Zone draußen einwandfrei, während der Heartbeat ausbleibt, liegt die Ursache mit hoher Wahrscheinlichkeit beim Resolver Ihres Servers und nicht bei Ihrer Domain.
XICTRAQ liest keine Ankerdateien auf Ihrem Server und fragt Ihren Resolver nicht direkt ab. Die DNSSEC-Prüfung im DNS-Monitoring läuft über einen öffentlichen Resolver und sagt deshalb nichts darüber, ob Ihr eigener Resolver KSK-2024 kennt. Den Nachweis von Key Tag 38696 erbringt allein der Blick in die Konfiguration. Heartbeat und Prüf-Endpunkt melden die Folgen, wenn der Schlüssel fehlt, und zwar innerhalb der Toleranz, die Sie selbst festlegen.
Am Stichtag fällt nicht die Website aus, sondern ihr Blick nach draußen. Eine Prüfung, die nur von außen hineinschaut, kann das nicht sehen. Ein Server, der sich selbst melden muss, schon.
— XICTRAQ
Nach dem Stichtag: den Montagmorgen richtig lesen
Falls am Stichtag oder am Tag danach trotzdem etwas ausfällt, hilft eine feste Reihenfolge. Sie verhindert, dass ein Team stundenlang an Schnittstellen und Zugangsdaten sucht, obwohl die Ursache eine Ebene tiefer liegt:
- Auf dem betroffenen Server einen bekannten Namen über den eingestellten Resolver abfragen. Kommt SERVFAIL zurück, während derselbe Name über einen anderen Resolver aufgelöst wird, ist die Validierung die wahrscheinlichste Ursache.
- Die Ankerdatei auf Key Tag 38696 prüfen, wie in der Checkliste oben beschrieben.
- Den Anker aktualisieren: die Resolver-Software auf eine aktuelle Version bringen oder die Ankerdatei mit dem Werkzeug der Software neu erzeugen und den Resolver danach neu starten.
- Warteschlangen abarbeiten lassen: Mailserver stellen aufgestaute Nachrichten nach, sobald die Auflösung wieder funktioniert. Webhooks, die schon verworfen wurden, müssen dagegen gezielt neu ausgelöst werden.
- Den Heartbeat beobachten: Kommt der Ping wieder an, ist der Weg nach draußen frei.
Ein Wort zur Abkürzung, die in solchen Momenten naheliegt: Die DNSSEC-Validierung abzuschalten, beseitigt das Symptom sofort, nimmt aber zugleich den Schutz vor gefälschten Antworten weg. Wer das als Notbehelf nutzt, sollte den Schritt dokumentieren und ihm einen festen Termin für die Rücknahme geben. Sonst wird aus einer Nacht mit Ausfall ein Jahr ohne Validierung.
Gehen Sie die Checkliste in der Woche vor dem 11. Oktober für jeden Server mit eigenem Resolver einmal durch, auch für die, die kaum jemand auf dem Zettel hat: den alten Mailserver, das Staging-System, die virtuelle Maschine für Exporte. Richten Sie für jeden dieser Server einen Heartbeat ein, der nur ankommt, wenn die Namensauflösung funktioniert. Dann meldet sich ein Ausfall am Sonntag von selbst, statt am Montag von Kunden gemeldet zu werden.
Die Dokumentation dieser Prüfung hat noch einen zweiten Nutzen. Wer für Kunden Server betreut, wird zunehmend nach Nachweisen gefragt, dass Sicherheitsrisiken aktiv behandelt werden. Ein Vermerk mit Datum, Server und gefundenem Key Tag ist ein solcher Nachweis, ebenso die Historie eines Heartbeats. Welche Belege Versicherer und Auftraggeber bei Websites typischerweise sehen wollen, beschreibt der Beitrag zu Cyberversicherung und Website-Nachweisen.
Dieser Beitrag stützt sich auf: den Beitrag „Preparing for the Root Zone KSK Rollover: What You Need to Know“ im ICANN-Blog, die Auswertung „The 2024-2026 Root Zone KSK Rollover: Updates and Observations“ im Verisign-Blog sowie die ICANN-Pressemitteilung vom 11. August 2026 zum Leitfaden „What to Expect During the Root KSK Rollover“, der in allen sechs UN-Sprachen und auf Portugiesisch vorliegt (ICANN). Anteile übernommener Schlüssel beruhen auf Vertrauensanker-Signalen nach RFC 8145, also auf einer Stichprobe meldender Resolver und nicht auf allen Resolvern im Netz. Befehle und Pfade sind Beispiele für verbreitete Installationen und können je nach System abweichen.