Nach Albaniens .al-Ausfall durch fehlgeschlagenen DNSSEC-Rollover: 1.1.1.1 offenbart nun Validierungs-Umgehungen

Mitte Juli 2026 ging ein routinemäßiger Sicherheitsprozess für Albaniens Ländercode-Top-Level-Domain .al schief und legte die gesamte Domain lahm. Die Ursache war ein fehlgeschlagener DNSSEC-Rollover, das Verfahren, bei dem die kryptografischen Schlüssel ersetzt werden, mit denen die DNS-Einträge von .al signiert werden. Am 14. Juli 2026 veröffentlichte der Cloudflare-Ingenieur Sebastiaan Neuteboom einen detaillierten Incident-Report, der erklärt, wie der öffentliche DNS-Resolver des Unternehmens, 1.1.1.1, Benutzern nun mitteilt, wenn er die DNSSEC-Validierung absichtlich umgeht. Das neue Signal erscheint als Extended DNS Error Code 33, auch EDE 33 genannt, und macht bisher unsichtbare "Negative Trust Anchors" für alle Betroffenen sichtbar.

Zunächst eine kurze Erinnerung an die Grundlagen. Das Domain Name System (DNS) ist das Telefonbuch des Internets: Es wandelt benutzerfreundliche Namen wie google.al in numerische IP-Adressen um, die Computer für die Verbindung nutzen. DNSSEC, kurz für Domain Name System Security Extensions, fügt eine Schicht digitaler Signaturen zu DNS-Einträgen hinzu, sodass ein Resolver, der Server, der diese Auflösung durchführt, überprüfen kann, dass die Antwort nicht von einem Angreifer verändert wurde. Wenn DNSSEC korrekt funktioniert, folgt ein Resolver einer Vertrauenskette von der Wurzel des DNS bis hinunter zur spezifischen Domain. Wenn ein Glied in dieser Kette unterbrochen ist, schlägt die Validierung fehl und der Resolver gibt normalerweise einen Fehler zurück. Ein Negative Trust Anchor (NTA) ist jedoch eine manuelle Konfiguration, die einen Resolver anweist, eine bestimmte Zone, wie .al, vorübergehend so zu behandeln, als wäre sie überhaupt nicht mit DNSSEC signiert. Resolver-Betreiber verwenden NTAs, wenn die DNSSEC-Einrichtung einer Zone falsch konfiguriert oder fehlerhaft ist, um die Domains der Zone für Benutzer erreichbar zu halten, während das zugrunde liegende Problem behoben wird. Bisher geschah diese Umgehung still, sodass Benutzer, Website-Betreiber und Überwachungswerkzeuge keine Ahnung hatten, dass ihre DNS-Antworten nicht vollständig validiert wurden.

Cloudflares Bericht zeigt, wie das in der Praxis am Beispiel der Domain google.al aussieht. Wenn 1.1.1.1 während eines aktiven NTA für die .al-Zone eine Abfrage für google.al erhält, gibt es eine normale Antwort mit dem Statuscode NOERROR zurück, was bedeutet, dass die Abfrage erfolgreich war. Aber an diese Antwort sind zwei Extended DNS Error Codes angehängt. Der erste, EDE 9, heißt DNSKEY Missing und zeigt den eigentlichen DNSSEC-Fehler: Die Vertrauenskette war unterbrochen, sodass die Validierung nicht erfolgreich sein konnte. Der zweite ist der neue EDE 33, der für Negative Trust Anchor steht und dem Client mitteilt, dass 1.1.1.1 einen Negative Trust Anchor angewendet und die Antwort trotzdem ausgeliefert hat. Zusammen geben diese beiden Codes volle Transparenz: Die Antwort ist echt und vollständig, wurde aber nicht mit DNSSEC validiert. Da der NTA die gesamte .al-Zone abdeckt, gibt 1.1.1.1 EDE 33 bei jeder Antwort zurück, die während des aktiven NTA generiert wird, selbst für eine Domain unter .al, die überhaupt kein DNSSEC verwendet. Dies ist beabsichtigt, erklärt Cloudflare, da der NTA für die gesamte Zone gilt und der Resolver bei jeder Antwort, die unter ihm ausgeliefert wird, gleichermaßen transparent sein möchte.

Der neue Code behebt auch ein früheres Melde-Problem aus einem ähnlichen Vorfall in der deutschen Top-Level-Domain .de. In diesem früheren Fall gab 1.1.1.1 fälschlicherweise EDE 22 zurück, was "No Reachable Authority" bedeutet, anstatt den zugrunde liegenden DNSSEC-Fehler anzuzeigen. Während des .al-Vorfalls gab der Resolver korrekt EDE 9 zusammen mit EDE 33 zurück und lieferte so ein präzises Bild dessen, was schiefging. Der Internet-Draft, der EDE 33 definiert, wurde als individueller Beitrag zur DNS Operations (DNSOP) Working Group der Internet Engineering Task Force (IETF) eingereicht. Die Internet Assigned Numbers Authority (IANA) hat die Codenummer 33 bereits zugewiesen. Cloudflare dankt Babak Farrokhi von Quad9, einem Mitautor des Entwurfs, und weist darauf hin, dass das Kommandozeilenwerkzeug kdig aus dem Knot-Projekt EDE 33 jetzt namentlich erkennt. Ein Pull-Request, um die gleiche Unterstützung zum Unbound-DNS-Resolver hinzuzufügen, wird derzeit überprüft. Der Entwurf wird beim IETF-Treffen in Wien vom 18. bis 24. Juli 2026 diskutiert.

Diese Entwicklung ist wichtig, weil DNSSEC-Fehler auf Top-Level-Domain-Ebene, wenn auch selten, alle Domains unter der betroffenen TLD gleichzeitig und alle validierenden Resolver gleichermaßen betreffen. Der .al-Vorfall, der kurz nach .de kam, zeigt, dass Negative Trust Anchors ein notwendiges operatives Werkzeug sind. Aber bis EDE 33 war ihre Verwendung für Endbenutzer unsichtbar. Mit diesem Code schließt 1.1.1.1 eine Lücke, die RFC 7646, der Standard, der ursprünglich definierte, wie Resolver mit DNSSEC-Validierungsfehlern umgehen sollten, offen gelassen hat. Jetzt sagt eine Antwort, die unter einem Negative Trust Anchor ausgeliefert wird, dies direkt aus und gibt Betreibern, Überwachungswerkzeugen und normalen Benutzern die Informationen, die sie benötigen, um genau zu verstehen, was der Resolver getan hat und warum. Der Internet-Draft ist im IETF-Datatracker verfügbar, und Feedback kann an die DNSOP-Mailingliste gesendet werden. Cloudflare verweist die Leser außerdem auf die Seite "Wie funktioniert DNSSEC?" für weitere Hintergrundinformationen und auf Cloudflare Radar für Echtzeit-DNS-Trends und TLD-Daten.

Für Website-Besitzer und IT-Teams ist die Lektion klar: DNSSEC-Fehlkonfigurationen können eine gesamte Top-Level-Domain lahmlegen, daher sind regelmäßige Überwachung und sorgfältige Schlüssel-Rollover-Planung unerlässlich. Für normale Internetnutzer bietet die Wahl eines Resolvers, der EDE-Codes meldet, eine Möglichkeit zu sehen, wann DNS-Antworten nicht vollständig validiert wurden. Ein datenschutzfreundlicher, verschlüsselter DNS-Dienst wie AEU DNS fügt eine weitere Schutzschicht hinzu, indem er Ihre DNS-Abfragen Ende-zu-Ende verschlüsselt, und seine Unterstützung für DNSSEC und erweiterte Fehlercodes bedeutet, dass Sie ähnliche Transparenz erhalten, wenn etwas schiefgeht. Indem Sie auf diese Signale achten, können Sie vermeiden, durch ein Netzwerkproblem oder einen DNS-Angriff in die Irre geführt zu werden.