Die aktuelle Störung rund um .de-Domains zeigt ein unbequemes, aber wichtiges Prinzip: Auch die stabilsten Bausteine des Internets sind nicht unfehlbar.

Die DENIC, seit Jahrzehnten Betreiber der .de-Zone und Synonym für Stabilität, hat Probleme im Kontext von DNSSEC eingeräumt. Für viele kam das überraschend – schließlich gilt .de als eine der robustesten und bestverwalteten TLDs weltweit.

Doch genau hier liegt der Denkfehler.

Infrastruktur-Vertrauen ist kein Designprinzip

In vielen Architekturen wird implizit angenommen, dass bestimmte externe Abhängigkeiten „einfach funktionieren“:

• TLD-Betreiber liefern korrekte Zonen
• DNS-Auflösung ist jederzeit verfügbar
• Validierungsmechanismen wie DNSSEC erhöhen ausschließlich die Sicherheit

Das stimmt – bis es nicht mehr stimmt.

DNSSEC ist ein gutes Beispiel: Es erhöht die Integrität der Namensauflösung, führt aber gleichzeitig zu einem härteren Failure Mode. Wenn Validierung fehlschlägt, gibt es kein „best effort“ mehr – sondern schlicht kein Ergebnis.

Der eigentliche Fehler: Monokultur

Das Problem ist nicht, dass eine Organisation wie die DENIC Fehler macht. Das Problem ist, wenn die eigene Architektur keine Alternativen vorsieht.

Typische Anti-Patterns:

• Single-TLD-Abhängigkeit (.de only)
• Keine fallback-fähigen Domains
• Harte Abhängigkeit von DNSSEC-validierenden Resolvern ohne Monitoring
• Kein unabhängiger Out-of-Band-Zugriff (z. B. direkte IPs, alternative Endpunkte)

Was robuste Architekturen anders machen

Resiliente Systeme gehen davon aus, dass jede externe Abhängigkeit ausfallen kann – unabhängig von Reputation oder Historie.

Konkrete Maßnahmen:

• Multi-TLD-Strategie
  Kritische Services zusätzlich unter .eu oder anderen TLDs bereitstellen
• DNS-Provider- und Resolver-Diversität
  Unterschiedliche Pfade testen und aktiv überwachen
• Gezielter Einsatz von DNSSEC
  Sicherheit vs. Verfügbarkeit bewusst abwägen, insbesondere bei kritischen Public-Endpunkten
• Fallback-Zugänge
  Direkte IP-Endpunkte, alternative Hostnames oder VPN-Zugänge für Notfälle
• Monitoring auf Validierungsebene
  Nicht nur „ist DNS erreichbar?“, sondern „ist DNSSEC-validierte Auflösung erfolgreich?“

Die aktuelle Störung ist kein Einzelfall und auch kein „Versagen“ einer einzelnen Organisation. Sie ist ein Reminder für ein fundamentales Prinzip:

Vertrauen ist gut – Architektur ist besser.

Wer seine Systeme so baut, dass selbst zentrale Instanzen wie die DENIC temporär ausfallen dürfen, ohne dass alles stehen bleibt, hat die richtige Lektion gelernt.

Oder pragmatischer formuliert:

Plane so, als würde irgendwann jede Abhängigkeit brechen.

Update 06.05.2026 – Technische Einordnung der .de-Störung

Die Ursache der aktuellen .de-Probleme ist inzwischen klarer eingegrenzt:
Laut mehreren Quellen handelte es sich nicht um einen Angriff, sondern um einen Fehler im Zuge eines DNSSEC ZSK-Rollovers (Zone Signing Key) innerhalb der .de-Zone.

Was ist konkret passiert?

Beim DNSSEC-Betrieb werden Zonen kryptographisch signiert. Dabei kommen zwei Schlüsseltypen zum Einsatz:

• KSK (Key Signing Key) – signiert die DNSKEY-Records
• ZSK (Zone Signing Key) – signiert die eigentlichen Zonendaten

Im Rahmen eines geplanten Rollovers wird der ZSK regelmäßig ausgetauscht. Genau hier ist es offenbar zu einem Fehler gekommen – etwa durch:

• inkonsistente Signaturen
• fehlerhafte Key-Verteilung
• oder Timing-/Propagation-Probleme im Signierungsprozess

Das Resultat: Validierende Resolver konnten die Signaturen nicht mehr korrekt verifizieren.

Warum war das Verhalten so „uneinheitlich“?

Das zentrale Symptom war:

SERVFAIL bei DNSSEC-validierenden Resolvern

Allerdings trat das nicht überall gleichzeitig oder identisch auf. Der Grund liegt im verteilten Charakter von DNS: Resolver cachen sowohl gültige als auch fehlerhafte Antworten unterschiedlich lange, einige Resolver validieren strikt, andere sind permissiver konfiguriert. Unterschiedliche Cache-Stände führten zu scheinbar zufälliger Erreichbarkeit.

Das führte zu dem klassischen Effekt:
„Bei mir geht’s – bei dir nicht.“

Das eigentliche Problem ist nicht der konkrete Fehler im DNSSEC-Rollover. Solche Fehler können – bei jeder Organisation – passieren. Auch bei einer Instanz wie der DENIC.

Die entscheidende Frage ist eine andere:

Warum kann ein einzelnes Ereignis in einer einzigen TLD so weitreichende Auswirkungen auf eure Services haben?

Wenn die Antwort lautet „weil alles ausschließlich unter .de läuft“, dann ist das kein technisches Detail – sondern ein strukturelles Risiko.

Single-TLD-Strategien sind ein Single Point of Failure

Viele Setups setzen implizit auf eine einzelne TLD – und genau da liegt der Fehler! Damit entsteht eine harte Abhängigkeit von genau dieser einen Infrastruktur – inklusive aller ihrer Prozesse (wie DNSSEC-Rollover).

Ein Fehler wie dieser zeigt dann unmittelbar Wirkung:

• Kein Fallback
• Keine alternative Namensauflösung
• Keine Möglichkeit, Traffic umzulenken

Konsequenz: Architektur statt Vertrauen

Wer kritische Systeme betreibt, sollte sich ernsthaft fragen:

• Gibt es alternative Domains unter anderen TLDs (.eu, .es, .fr, etc.)?
• Sind diese technisch einsatzbereit oder nur „geparkt“?
• Wird DNSSEC-Verhalten aktiv überwacht (nicht nur „DNS up/down“)?
• Existieren Out-of-Band-Zugänge (IP, VPN, alternative Hostnames)?

Denn am Ende gilt:

Nicht die Zuverlässigkeit einer einzelnen Organisation entscheidet über eure Verfügbarkeit – sondern eure Fähigkeit, mit deren Ausfall umzugehen.