AKEP: Fehlerhafter DNSSEC-Rollover macht .al-Domains unerreichbar

Unternehmen und Produkt

AKEP ist die albanische Regulierungsbehörde für elektronische Kommunikation und zugleich der Registry-Betreiber der länderspezifischen Top-Level-Domain .al.

Der Namensraum wird von albanischen Behörden, Banken, Medienunternehmen, Unternehmen, Universitäten, Online-Services und Privatpersonen genutzt. Da .al an der Spitze der nationalen DNS-Hierarchie Albaniens steht, kann eine Fehlkonfiguration auf Registry-Ebene jede darunterliegende Domain beeinträchtigen.

DNS Security Extensions (DNSSEC) ergänzen die reguläre DNS-Auflösung um eine kryptografische Überprüfung. Bei einer signierten Top-Level-Domain gilt:

• Die DNS-Root-Zone veröffentlicht einen Delegation-Signer-Eintrag.
• Dieser Eintrag verweist auf einen vertrauenswürdigen DNSKEY der Top-Level-Domain.
• Die autoritativen Nameserver veröffentlichen den entsprechenden Schlüssel.
• Validierende Resolver vergleichen beide Einträge.
• Stimmen sie nicht überein, wird die Vertrauenskette unterbrochen und die Validierung schlägt fehl.

Was war passiert?

Vor dem Incident stimmte der DS-Eintrag in der Root-Zone mit dem DNSKEY überein, der von den autoritativen .al-Nameservern veröffentlicht wurde.

Gegen 14:15 Uhr UTC veröffentlichte AKEP einen neuen DNSKEY und stellte die Auslieferung des bisherigen Schlüssels ein. Die Root-Zone war zu diesem Zeitpunkt noch nicht aktualisiert worden und verwies weiterhin auf die Key-ID 26319.

Wenn validierende Resolver der Vertrauenskette von der Root-Zone aus folgten, konnten sie den referenzierten Schlüssel auf den .al-Nameservern nicht finden. Daher lehnten sie die Antworten für .al ab und gaben SERVFAIL zurück.

Die Fehlerkette war wie folgt:

• AKEP veröffentlichte einen neuen DNSKEY.
• Der bisherige Schlüssel wurde zu früh entfernt.
• Der DS-Eintrag in der Root-Zone verwies weiterhin auf den bisherigen Schlüssel.
• Keiner der veröffentlichten Schlüssel stimmte mit dem vertrauenswürdigen Root-Eintrag überein.
• Die DNSSEC-Validierung schlug fehl.
• Nutzer erhielten zunehmend Fehler bei der DNS-Auflösung.
• Die Auswirkungen nahmen zu, als gültige zwischengespeicherte DNS-Einträge abliefen.

Gegen 17:00 Uhr UTC entfernte AKEP den neuen DNSKEY, stellte den bisherigen Schlüssel jedoch nicht wieder her. Damit waren für .al keine DNSKEY-Einträge mehr veröffentlicht, während die Root-Zone die Domain weiterhin als DNSSEC-signiert auswies. Die Validierung schlug daher weiterhin fehl.

Gegen 19:15 Uhr UTC entfernte AKEP den DS-Eintrag für .al aus der Root-Zone. Resolver behandelten .al daraufhin als nicht signiert und verlangten keine DNSSEC-Validierung mehr. Die Verfügbarkeit wurde wiederhergestellt, allerdings stand für die Top-Level-Domain vorübergehend keine kryptografische Authentifizierung mehr zur Verfügung.

Der Incident entwickelte sich zu einem weitreichenden Ausfall, weil DNSSEC nach dem Fail-Closed-Prinzip arbeitet. Kann die Vertrauenskette nicht verifiziert werden, lehnen Resolver auch legitime Antworten ab, anstatt das Risiko einzugehen, gefälschte DNS-Daten zurückzugeben.

Timeline

• Gegen 14:15 Uhr UTC: AKEP veröffentlicht einen neuen DNSKEY für .al und zieht den bisherigen Schlüssel mit der Key-ID 26319 zurück.
• Gegen 14:15 Uhr UTC: Der DS-Eintrag in der Root-Zone verweist weiterhin auf den zurückgezogenen Schlüssel und unterbricht damit die DNSSEC-Vertrauenskette.
• Nach 14:15 Uhr UTC: Mit dem Auslaufen zwischengespeicherter DNS-Einträge beginnen validierende Resolver, SERVFAIL zurückzugeben.
• Vor 17:15 Uhr UTC: Cloudflare versucht, AKEP zu kontaktieren, und informiert die DNS-Community über den DNS-OARC-Mattermost-Kanal.
• Gegen 17:00 Uhr UTC: AKEP entfernt den neuen DNSKEY, ohne den bisherigen Schlüssel wiederherzustellen.
• 17:15 Uhr UTC: Cloudflare schließt die Bereitstellung eines Negative Trust Anchor für alle Nutzer von 1.1.1.1 ab.
• Nach 17:15 Uhr UTC: Cloudflare-Nutzer können .al-Domains wieder auflösen, die Antworten werden jedoch nicht per DNSSEC validiert.
• Gegen 19:15 Uhr UTC: AKEP entfernt den DS-Eintrag für .al aus der DNS-Root-Zone.
• Nach 19:15 Uhr UTC: Die allgemeine DNS-Auflösung funktioniert wieder, da .al als nicht signiert behandelt wird.
• 4. Juli 2026: Cloudflare entfernt seinen Negative Trust Anchor.
• 14. Juli 2026: Cloudflare berichtet, dass .al weiterhin nicht signiert ist.
• Stand 5. August 2026: Die IANA-Root-Zone enthält wieder einen DS-Eintrag für .al mit dem Key-Tag 46645.

Time to Detect (TTD): Nicht öffentlich bekannt gegeben.

Time to Resolve (TTR): Etwa fünf Stunden – von der unterbrochenen Vertrauenskette um 14:15 Uhr UTC bis zur Entfernung des DS-Eintrags aus der Root-Zone um 19:15 Uhr UTC. Für Nutzer von 1.1.1.1 stellte Cloudflare die DNS-Auflösung nach etwa drei Stunden wieder her.

Wer war betroffen?

• Nutzer, die über DNSSEC-validierende Resolver auf .al-Domains zugriffen.
• Albanische Regierungswebsites und öffentliche Dienste.
• Banken und Finanzinstitute.
• Medienunternehmen und andere Unternehmen.
• Universitäten und Bildungseinrichtungen.
• E-Mail-Systeme, APIs und interne Anwendungen, die .al-Hostnamen verwendeten.

Der Ausfall hing nicht davon ab, wo ein Service gehostet wurde. Jede Domain unterhalb von .al konnte unerreichbar werden, da die Validierung bereits auf Ebene der übergeordneten Top-Level-Domain fehlschlug.

Die Auswirkungen variierten je nach Verhalten des Resolvers und Zustand des Caches. Resolver mit noch gültigen zwischengespeicherten Einträgen konnten vorübergehend weiterhin Antworten liefern, während nicht validierende Resolver möglicherweise weiterhin DNS-Antworten ohne DNSSEC-Schutz zurückgaben.

Wie reagierten AKEP und Cloudflare?

AKEP entfernte gegen 17:00 Uhr UTC zunächst den neuen DNSKEY. Dadurch wurde jedoch weder der fehlende bisherige Schlüssel wiederhergestellt noch die Vertrauenskette repariert.

Gegen 19:15 Uhr UTC entfernte AKEP den DS-Eintrag aus der Root-Zone. Dadurch wurde die Verfügbarkeit wiederhergestellt, da .al fortan als nicht signiert behandelt wurde.

Cloudflare gab zunächst, wie von DNSSEC vorgesehen, SERVFAIL zurück. Nachdem das Unternehmen versucht hatte, AKEP zu kontaktieren und die DNS-OARC-Community informiert hatte, setzte Cloudflare einen Negative Trust Anchor ein.

Der NTA wies 1.1.1.1 vorübergehend an, .al als nicht signiert zu behandeln. Cloudflare gab außerdem Folgendes zurück:

• EDE 9 — DNSKEY Missing: Kennzeichnete die unterbrochene DNSSEC-Vertrauenskette.
• EDE 33 — Negative Trust Anchor: Zeigte an, dass die Validierung umgangen wurde.

Damit funktionierte die DNS-Auflösung wieder, während der damit verbundene Sicherheitskompromiss für Clients und Monitoring-Tools sichtbar blieb.

Wie kommunizierte AKEP?

Der Bericht von Cloudflare nennt weder einen öffentlichen Incident-Bericht noch eine Statusseite oder einen Maßnahmenplan von AKEP.

Cloudflare gab an, bei dem Versuch, den Betreiber zu erreichen, keine Antwort erhalten zu haben. Die von AKEP veröffentlichten Kontaktadressen lagen selbst unterhalb von .al, sodass derselbe DNS-Ausfall auch den primären Kommunikationskanal beeinträchtigen konnte.

Cloudflare informierte die DNS-Operations-Community und veröffentlichte später den ausführlichen technischen Bericht, der als Hauptquelle für diese Analyse dient.

Wichtige Erkenntnisse für andere Teams

• Key-Overlap sicherstellen: Den bisherigen Schlüssel erst zurückziehen, wenn der neue DNSKEY und der passende übergeordnete DS-Eintrag vollständig propagiert und extern validiert wurden.
• Rollovers wie Deployments behandeln: Peer Reviews, automatisierte Prüfungen, Monitoring, Rollback-Verfahren und formale Freigaben vorsehen.
• Die vollständige Vertrauenskette validieren: Vom DS-Eintrag in der Root-Zone bis zum autoritativen DNSKEY testen.
• DNS-Caching berücksichtigen: Propagationszeiten und Cache-Laufzeiten müssen berücksichtigt werden, bevor ein alter Schlüssel zurückgezogen wird.
• Unabhängige Notfallkontakte vorhalten: Kontaktkanäle des Registry-Betreibers dürfen nicht ausschließlich von der betriebenen Domain abhängen.
• NTAs mit Bedacht einsetzen: Negative Trust Anchors stellen die Verfügbarkeit wieder her, indem sie den DNSSEC-Schutz vorübergehend deaktivieren.
• Umgehung der Validierung transparent machen: Extended-DNS-Error-Codes helfen Anwendungen zu erkennen, warum die Validierung übersprungen wurde.
• Wiederherstellung der Sicherheit separat verfolgen: Eine wiederhergestellte DNS-Auflösung bedeutet nicht zwangsläufig, dass auch der DNSSEC-Schutz wieder aktiv ist.

Zusammenfassung

Am 3. Juli 2026 unterbrach ein von AKEP durchgeführter DNSSEC-Rollover die Vertrauenskette der albanischen Top-Level-Domain .al. Der Betreiber veröffentlichte einen neuen DNSKEY und zog die Key-ID 26319 zurück, bevor der DS-Eintrag in der Root-Zone aktualisiert worden war. Mit dem Auslaufen zwischengespeicherter DNS-Einträge gaben validierende Resolver SERVFAIL zurück. Bis 17:15 Uhr UTC hatte Cloudflare für alle Nutzer von 1.1.1.1 einen Negative Trust Anchor ausgerollt und mit EDE 9 und EDE 33 auf den fehlenden Schlüssel sowie die umgangene Validierung hingewiesen. Gegen 19:15 Uhr UTC entfernte AKEP den DS-Eintrag aus der Root-Zone. Dadurch wurde die DNS-Auflösung wiederhergestellt, .al blieb jedoch zunächst nicht signiert. Cloudflare berichtete noch am 14. Juli über diesen Zustand; bis zum 5. August war der IANA-Root-Zone wieder ein neuer DS-Eintrag für .al hinzugefügt worden.

So kann ilert helfen

DNSSEC-Ausfälle können Websites, E-Mail-Systeme und APIs beeinträchtigen, obwohl die zugrunde liegende Hosting-Infrastruktur weiterhin einwandfrei funktioniert.

• Alarmierung bei Validierungsfehlern: SERVFAIL, fehlende DNSKEYs, DS-Abweichungen und Metriken zu Signaturfehlern können an die zuverlässige und handlungsorientierte Alarmierung von ilert weitergeleitet werden, um DNSSEC-Ausfälle schnell zu erkennen.
• Zusammengehörige Alarmierungen gruppieren: Alarmierungen von Websites, APIs, E-Mail-Systemen und synthetischen Checks können in einem DNS-bezogenen Incident zusammengeführt werden.
• An Spezialisten eskalieren: DNS-, Netzwerk-, Plattform- und Security-Teams werden über dedizierte Eskalationsrichtlinien benachrichtigt.
• Notfallkommunikation absichern: Dank der Multi-Channel-Alarmierung werden Responder per SMS, Sprachanruf, Push-Benachrichtigung und Messaging-Plattformen erreicht, die nicht von der betroffenen Domain abhängig sind.
• Auswirkungen kommunizieren: Über die ilert Statusseiten kann kommuniziert werden, dass die DNS-Auflösung fehlschlägt, während die Anwendungen selbst weiterhin verfügbar sind.
• Postmortem unterstützen: Der fehlgeschlagene Rollover kann anhand der Resolver-Metriken, des Alarmierungsverlaufs, der Incident-Timeline und der Aktivitäten der Responder rekonstruiert werden.