Am 5. Mai 2026 konnten Millionen Nutzer zeitweise keine .de-Domains aufrufen – oder auch nicht, je nachdem, welchen DNS-Resolver sie verwendeten. Wer seinen Internetanbieter-Resolver nutzte, surfte ungestört weiter. Wer Google Public DNS, Cloudflare oder Quad9 eingestellt hatte, stand vor Fehlermeldungen.

Zwei Nutzergruppen, dieselbe Infrastruktur, völlig verschiedene Erfahrungen. Der Grund lag nicht in der jeweiligen Domain, nicht beim Hoster, nicht beim eigenen Netzwerk – sondern in einer fehlerhaften kryptografischen Signatur in der .de-Zonendatei der DENIC, dem deutschen Registry-Betreiber.

Dieser Vorfall illustriert ein grundlegendes Spannungsfeld, das in der täglichen Systembetreuung oft im Hintergrund bleibt: DNS ist eine sicherheitskritische Infrastrukturschicht – und gleichzeitig eine, die historisch bedingt wenig Schutzmechanismen mitbringt. DNSSEC, DoT, DoH und DoQ sind Versuche, das zu ändern.

Wozu DNSSEC? Die Angriffsszenarien

Um zu verstehen, warum DNSSEC existiert, hilft ein Blick auf das, was DNS ohne Schutzmechanismen ermöglicht. Das Domain Name System wurde in den 1980er-Jahren entworfen – in einer Zeit, in der das Internet ein überschaubares Forschungsnetzwerk war und Vertrauen unter Teilnehmern als selbstverständlich galt. Authentizität und Integrität von DNS-Antworten waren kein Designziel. Das rächt sich bis heute.

• DNS Cache Poisoning ist einer der bekanntesten Angriffsvektoren. Ein Angreifer schickt einem rekursiven Resolver gefälschte DNS-Antworten, bevor die legitime Antwort des autoritativen Nameservers eintrifft. Gelingt das, speichert der Resolver die manipulierte IP-Adresse im Cache und leitet alle nachfolgenden Nutzer, die dieselbe Domain abfragen, auf einen Server des Angreifers um. Bei reinen HTTP-Verbindungen, E-Mail-Infrastruktur oder internen Diensten ohne TLS ist das direkt gefährlich. Bei HTTPS erkennt der Browser ein ungültiges Zertifikat und warnt den Nutzer – ein stilles Hijacking ist hier also nicht ohne weiteres möglich. DNS-Spoofing dient in solchen Szenarien dennoch als Vorstufe: etwa kombiniert mit einem Angriff auf die Zertifikatsvalidierung über BGP-Hijacking, oder in Umgebungen, in denen Nutzer Zertifikatswarnungen routinemäßig wegklicken.
• Die sogenannte Kaminsky-Attacke aus dem Jahr 2008 verschärfte das Problem erheblich. Dan Kaminsky zeigte, dass ein Angreifer durch massenhaftes Raten der 16-Bit-Transaction-ID einen Resolver innerhalb von Sekunden vergiften kann. Als kurzfristiger Fix etablierte sich daraufhin die Source Port Randomization: Resolver wählen den UDP-Quellport für jede Anfrage zufällig, was den Adressraum für Brute-Force-Angriffe aufbläht und die Attacke erheblich erschwert. Eine echte Lösung war das aber nicht – Source Port Randomization erhöht den Aufwand, macht Cache Poisoning unter günstigen Bedingungen jedoch nicht unmöglich.
• DNS Hijacking auf ISP-Ebene ist ein weiteres Angriffsszenario, das oft unterschätzt wird. Kompromittierte oder korrumpierte Infrastruktur beim Internetanbieter kann DNS-Anfragen umleiten, ohne dass der Nutzer eine realistische Chance hat, das zu bemerken – sofern keine kryptografische Validierung stattfindet. Ähnliches gilt für Man-in-the-Middle-Angriffe in öffentlichen Netzwerken: Wer im Hotel-WLAN einen nicht verschlüsselten DNS-Resolver verwendet, gibt seine Anfragen im Klartext preis und ist anfällig für Manipulation.

DNSSEC adressiert dabei explizit die Integrität und Authentizität von DNS-Antworten – nicht ihre Vertraulichkeit. Ob jemand mithört, welche Domains abgefragt werden, ist eine andere Frage. Dazu kommen DoT, DoH und DoQ ins Spiel, die weiter unten behandelt werden.

Wie DNSSEC funktioniert

DNSSEC baut auf asymmetrischer Kryptografie auf. Die Kernidee: Jede DNS-Zone signiert ihre Resource Records kryptografisch. Ein Resolver kann diese Signaturen gegen den öffentlichen Schlüssel der Zone prüfen und so sicherstellen, dass die Antwort tatsächlich vom legitimen Zonenbetreiber stammt und nicht manipuliert wurde.

Die Vertrauenskette beginnt an der DNS-Root-Zone, die von IANA/ICANN verwaltet wird. Deren öffentlicher Schlüssel – der sogenannte Trust Anchor – ist in DNSSEC-validierenden Resolvern fest hinterlegt. Von dort zieht sich die Kette nach unten:

• Die Root-Zone signiert die Schlüssel der TLD-Zonen (also etwa .de, .com, .org).
• Die TLD-Registry (im Fall von .de: DENIC) signiert die Schlüssel der darunter liegenden Domains.
• Der Domainbetreiber signiert die eigenen Resource Records.

Technisch funktioniert das über mehrere Record-Typen:

• DNSKEY: Enthält den öffentlichen Schlüssel der Zone. Es gibt zwei Varianten: den Key Signing Key (KSK), der nur zum Signieren des DNSKEY-Sets verwendet wird, und den Zone Signing Key (ZSK), mit dem alle übrigen Records signiert werden.
• RRSIG: Eine digitale Signatur über einen Resource Record Set (RRset). Jeder signierte Record bekommt einen zugehörigen RRSIG.
• DS (Delegation Signer): Ein Hash des DNSKEY-Records einer untergeordneten Zone, der in der übergeordneten Zone hinterlegt ist. Über DS-Records wird die Vertrauenskette zwischen Zonen hergestellt.
• NSEC / NSEC3: Signierte Nachweise über die Nicht-Existenz eines Records. Fragt ein Resolver nach einem DS-Record, der nicht existiert, liefert die Zone einen NSEC3-Record als kryptografisch signierten Beweis dafür. Genau hier lag der Fehler beim DENIC-Vorfall: Ein NSEC3-Record war mit einer kryptografisch fehlerhaften RRSIG-Signatur ausgeliefert worden – mit der Folge, dass validierende Resolver die gesamte Vertrauenskette als ungültig einstuften und mit SERVFAIL antworteten.

Beim Validierungsprozess baut ein Resolver die Kette von der Root bis zur angefragten Domain nach und prüft jeden Schritt. Schlägt einer dieser Schritte fehl, verweigert ein strikt validierender Resolver die Antwort – unabhängig davon, ob die Domain selbst korrekt konfiguriert ist oder nicht. Das ist kein Fehler im Design, sondern Absicht: Ein Resolver, der bei einer ungültigen Signatur trotzdem antwortet, untergräbt den gesamten Schutzmechanismus.

Warum viele Resolver DNSSEC ignorieren

Wenn DNSSEC so sinnvoll ist, warum validieren dann so viele ISP-Resolver keine DNSSEC-Signaturen? Die Antwort ist weniger technischer als betrieblicher Natur.

• Supportaufwand bei Fehlkonfigurationen: Betreiber einer Domain, die DNSSEC falsch konfiguriert hat – etwa weil RRSIG-Signaturen abgelaufen sind oder DS-Records nach einem Providerwechsel nicht aktualisiert wurden – landet mit einer korrekt validierenden Resolver-Infrastruktur umgehend in der Nichterreichbarkeit. Für ISPs, die Millionen Endkunden betreuen, bedeutet das: mehr Supportanrufe, mehr Eskalationen, mehr Erklärungsbedarf gegenüber Kunden, die nicht verstehen, warum eine Website "kaputt" ist, obwohl sie von anderen erreichbar ist. Das hat historisch dazu geführt, dass viele ISPs DNSSEC-Validierung bewusst nicht aktiviert haben.
• Legacy-Infrastruktur: Ältere Router, Firmware-Versionen und DNS-Implementierungen kommen mit DNSSEC-Erweiterungen teilweise nicht zurecht. DNSSEC-Antworten sind deutlich größer als herkömmliche DNS-Antworten, was auf manchen Pfaden zu Fragmentierungsproblemen führt. ISPs, die heterogene Kundenumgebungen betreuen, haben jahrelang auf Kompatibilität gesetzt.
• Fehlende regulatorische Verpflichtung: In Deutschland gibt es keine gesetzliche Pflicht zur DNSSEC-Validierung für ISPs. Ohne Verpflichtung und ohne direkten Kundendruck fehlte lange der Anreiz, die Komplexität auf sich zu nehmen.

Das Ergebnis ist eine zweigeteilte DNS-Landschaft: Technikaffine Nutzer, Unternehmen mit explizit konfiguriertem DNS und moderne Betriebssysteme mit aktiviertem DoH/DoT landen bei validierenden Resolvern wie Google, Cloudflare oder Quad9. Die Mehrheit der Privatnutzer landet beim ISP-Resolver, der DNSSEC oft durchwinkt. Das hat beim DENIC-Vorfall dazu geführt, dass der Ausfall für einen großen Teil der Nutzer unsichtbar blieb – was einerseits praktisch war, andererseits genau das Schutzniveau widerspiegelt, das diese Nutzer im Alltag haben.

Negative Trust Anchors als Notfalllösung

Der DENIC-Vorfall hat eine Grundspannung in der IT-Sicherheit sichtbar gemacht, die in der Praxis häufig unterschätzt wird: IT-Sicherheit besteht nicht nur aus Vertraulichkeit (Confidentiality) und Integrität (Integrity), sondern gleichrangig auch aus Verfügbarkeit (Availability). Das sogenannte CIA-Dreieck ist kein Ranking, sondern ein Gleichgewicht. Wer im Namen der Integrität die Verfügbarkeit opfert, hat ein Sicherheitsproblem anderer Art geschaffen.

Genau hier setzt RFC 7646 an, der das Konzept der Negative Trust Anchors (NTA) definiert. Ein NTA ist ein administrativ gesetzter Ausnahme-Eintrag in einem validierenden Resolver, der DNSSEC-Validierung für eine bestimmte Zone temporär aussetzt. Der Resolver behandelt diese Zone dann so, als wäre sie nicht DNSSEC-gesichert – liefert also Antworten aus, auch wenn die Signaturprüfung scheitern würde.

Cloudflare hat diesen Mechanismus während des DENIC-Vorfalls für die .de-Zone eingesetzt. Das bedeutet konkret: Nutzer von 1.1.1.1 konnten .de-Domains trotz der fehlerhaften NSEC3-Signatur erreichen, weil Cloudflare die Validierung für .de temporär außer Kraft gesetzt hatte. DNSSEC-Schutz für .de war in diesem Zeitraum für diese Nutzer nicht aktiv – aber DNS funktionierte.

NTAs sind ausdrücklich als kurzfristiges Instrument gedacht. RFC 7646 beschreibt sie als Notfallmaßnahme für genau solche Szenarien: wenn ein Fehler auf Registry-Ebene validierende Resolver in die Knie zwingt und die Behebung Zeit braucht. Der entscheidende Punkt ist, dass NTAs administrativ gesetzt werden – also von dem, der den Resolver betreibt – und nicht automatisch greifen. Ein Resolver, der bei jeder fehlgeschlagenen Validierung still auf Non-Validation zurückfällt, würde DNSSEC als Schutzmechanismus vollständig aushöhlen.

Für Unternehmen, die eigene validierende Resolver betreiben, ist NTA-Unterstützung ein sinnvolles Feature im Incident-Response-Prozess. BIND, Unbound und Knot Resolver unterstützen NTAs. Die Entscheidung, einen NTA zu setzen, sollte dokumentiert, zeitlich begrenzt und an einen definierten Freigabeprozess geknüpft sein.

Die letzte Meile: DoT, DoH und DoQ

DNSSEC löst ein spezifisches Problem: Es stellt sicher, dass DNS-Antworten authentisch und unverändert sind. Es löst aber kein Vertraulichkeitsproblem. Eine DNSSEC-validierte DNS-Antwort kann trotzdem im Klartext über das Netzwerk übertragen werden – sichtbar für jeden, der den Traffic mitliest.

Hier setzen DNS over TLS (DoT), DNS over HTTPS (DoH) und DNS over QUIC (DoQ) an. Allen drei gemeinsam ist, dass die DNS-Kommunikation zwischen dem Endgerät und dem Resolver verschlüsselt wird. Sie unterscheiden sich vor allem in Transport und Implementierungskontext:

• DoT (RFC 7858) kommuniziert über Port 853 mit TLS. Der Vorteil: klar erkennbar und filterbar im Netzwerk. Der Nachteil aus Nutzersicht: Firewalls und restriktive Netzwerke blockieren Port 853 häufig.
• DoH (RFC 8484) verpackt DNS-Anfragen als HTTPS-Requests über Port 443. Das macht DoH nahezu ununterscheidbar von normalem Web-Traffic – was die Filterung erschwert und in Unternehmensumgebungen zu Sichtbarkeitsproblemen führen kann. Browser wie Firefox und Chrome aktivieren DoH zunehmend standardmäßig, was bedeutet, dass DNS-Anfragen aus diesen Anwendungen am lokalen Resolver vorbeigehen können.
• DoQ (RFC 9250) nutzt das QUIC-Protokoll als Transport. Geringere Latenz, bessere Performance bei Verbindungsaufbau – in der Praxis noch wenig verbreitet, aber von Resolvern wie Cloudflare (1.1.1.1) bereits unterstützt.

Aus Sicht der Systembetreuung ist DoH besonders relevant, weil es die DNS-Kontrolle im Netzwerk untergräbt: Wer im Unternehmen DNS-basiertes Filtering, Malware-Blocking oder Logging betreibt, verliert die Kontrolle über Anfragen, die DoH-fähige Anwendungen direkt an externe Resolver schicken. Gruppenrichtlinien und explizite DoH-Konfiguration auf Endpunkten sind hier gefragt.

Die verbleibende Schwachstelle: SNI

DoT und DoH verschlüsseln die DNS-Anfrage – aber die aufgerufene Domain ist oft trotzdem sichtbar. Der Server Name Indicator (SNI) im TLS-Handshake überträgt den Hostnamen im Klartext, damit der Server das richtige Zertifikat auswählen kann. Ein Beobachter auf dem Netzwerkpfad sieht also, welche Domain der Client aufruft – auch ohne DNS-Anfragen mitlesen zu können.

Encrypted Client Hello (ECH), der Nachfolger von ESNI, adressiert dieses Problem. ECH verschlüsselt den SNI-Teil des TLS-Handshakes – benötigt dafür aber selbst funktionierende DNS-Infrastruktur: Der Client muss einen HTTPS-Resource-Record der Zieldomain abrufen, der den öffentlichen ECH-Schlüssel des Servers enthält. Damit schließt sich der Kreis: Ohne ein integer funktionierendes, sicheres DNS kann auch die Verschlüsselung des TLS-Handshakes nicht sicher initialisiert werden.

DNSSEC und ECH sind in dieser Hinsicht keine unabhängigen Schutzmechanismen, sondern aufeinander angewiesene Schichten. Die Unterstützung wächst: Cloudflare, Firefox und Chrome unterstützen ECH bereits. Für eine vollständige Ende-zu-Ende-Vertraulichkeit auf Domainebene braucht es das Zusammenspiel von DoH/DoT, ECH und entsprechender Serverunterstützung auf der Gegenseite.

DNSSEC und DoT/DoH ergänzen sich damit, adressieren aber verschiedene Probleme: DNSSEC schützt die Integrität der Antwort, DoT/DoH die Vertraulichkeit des Transports. Keines ersetzt das andere.

Wie überprüfe ich meinen Resolver?

Ob der eigene Resolver DNSSEC tatsächlich validiert, lässt sich mit wenigen Handgriffen prüfen. Das Tool dnscheck.tools führt im Browser eine Reihe von DNS-Testabfragen durch und zeigt strukturiert, welche Schutzfunktionen der verwendete Resolver unterstützt und durchsetzt.

Die Ausgabe gliedert sich in zwei Bereiche. Zunächst zeigt das Tool die ermittelten öffentlichen IP-Adressen des Nutzers sowie die tatsächlich verwendeten DNS-Resolver mit ihrer jeweiligen IP-Adresse, dem Reverse-DNS-Eintrag, dem AS-Betreiber und dem Standort. Das ist besonders aufschlussreich in Unternehmensumgebungen, wo der tatsächlich aktive Resolver nicht immer mit dem in den Netzwerkeinstellungen eingetragenen übereinstimmt.

Der zweite Bereich zeigt die DNSSEC-Validierungsergebnisse. Das Tool prüft vier Szenarien gegen drei Signaturalgorithmen – ECDSA P-256, ECDSA P-384 und Ed25519:

• Valid signature: Korrekt signierte Antworten werden akzeptiert.
• Invalid signature: Manipulierte Signaturen werden abgelehnt.
• Expired signature: Abgelaufene Signaturen werden abgelehnt.
• Missing signature: Fehlende Signaturen werden als Fehler gewertet.

Ein vollständig validierender Resolver liefert in allen zwölf Kombinationen "PASS". Daneben weist das Tool aus, ob der Resolver IPv6, EDNS und DoH unterstützt sowie die Antwortlatenz.

Wer tiefer diagnostizieren möchte, kann mit dig direkt gegen verschiedene Resolver testen:

# Testet, ob der Resolver eine absichtlich fehlerhafte DNSSEC-Domain ablehnt
dig @8.8.8.8 sigfail.verteiltesysteme.net A

# Sollte SERVFAIL liefern bei validierendem Resolver
# Mit deaktivierter Validierung (+cd) sollte NOERROR kommen
dig @8.8.8.8 +cd sigfail.verteiltesysteme.net A

Die Domain sigfail.verteiltesysteme.net ist bewusst mit ungültiger DNSSEC-Signatur konfiguriert und dient genau diesem Testzweck.

Empfehlenswerte DNS-Alternativen

Die Wahl des DNS-Resolvers ist eine Entscheidung mit Auswirkungen auf Sicherheit, Datenschutz und Performance. Die wichtigsten öffentlichen Alternativen im Überblick:

• Cloudflare DNS – 1.1.1.1 / 1.0.0.1 Cloudflare betreibt einen der schnellsten öffentlichen Resolver weltweit. DNSSEC-Validierung ist aktiv, DoT und DoH werden unterstützt, DoQ ebenfalls. Cloudflare verpflichtet sich vertraglich, keine Nutzerdaten zu verkaufen und Query-Logs innerhalb von 25 Stunden zu löschen. Kritikpunkt: US-amerikanischer Anbieter, Sitz in San Francisco, unterliegt US-Recht inklusive möglicher Behördenanfragen. Cloudflare bietet zudem 1.1.1.2 (mit Malware-Blocking) und 1.1.1.3 (mit Malware- und Adult-Content-Blocking) als Varianten an.
• Google Public DNS – 8.8.8.8 / 8.8.4.4 Weit verbreitet, zuverlässig, schnell. DNSSEC-Validierung aktiv, DoT und DoH unterstützt. Googles Datenschutzversprechen ist differenzierter als das von Cloudflare: Query-Daten werden für Debugging und Missbrauchsabwehr bis zu 48 Stunden gespeichert, anschließend anonymisiert. Für datenschutzbewusste Umgebungen ist das ein relevanter Faktor – Google ist ein Werbeunternehmen, dessen Geschäftsmodell auf Daten basiert. Ebenfalls US-amerikanischer Anbieter.
• Quad9 – 9.9.9.9 / 149.112.112.112 Betrieben von der gleichnamigen Schweizer Non-Profit-Organisation, gegründet unter anderem von IBM und dem Global Cyber Alliance. DNSSEC-Validierung aktiv, DoT und DoH unterstützt. Besonderheit: Quad9 blockt automatisch Domains, die auf Threat-Intelligence-Listen geführt werden – Malware-Distribution, Phishing, Botnet-Command-Server. Die Blocklisten werden von mehreren Sicherheitsorganisationen gepflegt. Für Systemadministratoren, die keinen eigenen DNS-Sinkhole betreiben, ist das ein nützliches Sicherheitsnetz. Sitz in der Schweiz bedeutet: Schweizer Datenschutzrecht, kein US-Cloud-Act-Einfluss.
• DNS.SB – 185.222.222.222 / 45.11.45.11 Weniger bekannt als die großen Anbieter, technisch aber solide aufgestellt. DNSSEC-Validierung ist aktiv, DoT und DoH werden unterstützt. Betreiber ist die xTom GmbH mit Sitz in Düsseldorf – damit gilt deutsches Recht und die DSGVO, was DNS.SB gegenüber den US-amerikanischen Alternativen datenschutzrechtlich in eine günstigere Position rückt. Kein Logging nach eigenen Angaben. Für Umgebungen, in denen europäische Jurisdiktion Pflicht ist, aber weder Quad9 noch ein selbst betriebener Resolver infrage kommt, eine beachtenswerte Option.
• AdGuard DNS – 94.140.14.14 / 94.140.15.15 Das Unternehmen hinter AdGuard wurde von russischen Entwicklern gegründet, die operative Gesellschaft AdGuard Software Limited ist jedoch auf Zypern registriert und unterliegt damit EU-Recht. DNSSEC-Validierung ist aktiv, DoT, DoH und DoQ werden unterstützt. AdGuard positioniert sich stärker als die anderen Anbieter dieser Liste als Filterdienst: Werbe- und Tracker-Blocking stehen im Vordergrund und sind für viele Endanwender das eigentliche Argument.

DNSSEC für eigene Domains aktivieren

Wer DNSSEC für eine eigene Domain einrichten will, muss zwei Voraussetzungen erfüllen: Der DNS-Hosting-Anbieter muss die Zone signieren können, und der Registrar muss den daraus resultierenden DS-Record an die übergeordnete TLD-Registry weitergeben. Beide Schritte sind notwendig – keiner allein genügt.

Registrar und DNS-Hosting-Anbieter prüfen

Registrar und DNS-Hosting sind nicht zwingend dieselbe Stelle. Wer seine Domain bei Anbieter A registriert hat, aber die Nameserver bei Anbieter B oder einem selbst betriebenen Nameserver betreibt, muss sicherstellen, dass beide Seiten DNSSEC unterstützen. Nicht alle Registrare akzeptieren DS-Record-Einträge; das ist vor einer Aktivierung zu klären. Wer die DNS-Verwaltung auslagern möchte, ist mit Diensten wie deSEC oder Cloudflare DNS gut bedient – beide übernehmen die Zonensignierung automatisch und liefern den DS-Record zur Übergabe an den Registrar.

Aktivierungsablauf

Der typische Ablauf sieht so aus: Der DNS-Hosting-Anbieter generiert einen Zone Signing Key (ZSK) und einen Key Signing Key (KSK), signiert alle Resource Records der Zone und stellt einen DS-Record bereit. Dieser DS-Record – ein Hash des KSK – wird über den Registrar an die TLD-Registry übermittelt, die ihn in der übergeordneten Zone veröffentlicht. Damit ist die Vertrauenskette geschlossen. Viele Anbieter übernehmen diesen Prozess heute weitgehend automatisiert. Wer BIND ab Version 9.16 oder Knot DNS selbst betreibt, kann die Zonensignierung und das Key-Rollover per dnssec-policy ebenfalls automatisieren – manuell bleibt in der Regel nur die Einreichung des DS-Records beim Registrar, sofern dieser keine API-Anbindung bietet.

Nach der Aktivierung lässt sich die korrekte Einrichtung mit dig prüfen:

# DS-Record in der übergeordneten Zone prüfen
dig example.de DS +short

# DNSKEY der eigenen Zone abrufen
dig example.de DNSKEY +short

# DNSSEC-Validierung gegen öffentlichen Resolver testen
dig @9.9.9.9 example.de A +dnssec

Für eine grafische Analyse der gesamten Vertrauenskette ist dnsviz.net das geeignete Werkzeug: Es visualisiert jeden Schritt von der Root-Zone bis zur eigenen Domain und macht Fehlkonfigurationen auf einen Blick erkennbar. zonemaster.net ergänzt das um detaillierte Einzelprüfungen nach RFC-Konformität.

Die kritischen Betriebsszenarien

Zwei Situationen verdienen besondere Aufmerksamkeit:

1. RRSIG-Ablauf: DNSSEC-Signaturen haben ein Ablaufdatum. Läuft eine RRSIG ab, ohne dass der Anbieter sie erneuert hat, antworten validierende Resolver mit SERVFAIL – die Domain ist für einen Teil der Nutzer nicht mehr erreichbar. Wer einen Managed-DNS-Anbieter nutzt, sollte explizit klären, ob die Signaturerneuerung automatisch erfolgt. Wer selbst signiert, braucht ein Monitoring der RRSIG-Ablaufdaten mit ausreichend Vorlaufzeit – ein Alert sollte mindestens sieben bis zehn Tage vor Ablauf ausgelöst werden, damit genug Zeit für Fehlersuche und Eskalation bleibt.
2. DNS-Provider-Migration: Der gefährlichste Moment im DNSSEC-Betrieb ist ein Wechsel des DNS-Hosting-Anbieters. Wer einfach die Nameserver-Einträge auf einen neuen Anbieter umstellt, ohne vorher den DS-Record zu entfernen oder zu aktualisieren, erzeugt eine gebrochene Vertrauenskette – mit der Folge, dass DNSSEC-validierende Resolver die Domain nicht mehr auflösen. Der korrekte Ablauf: erst DS-Record beim Registrar entfernen und die TTL des DS-Records in der übergeordneten Zone abwarten, dann Nameserver umstellen, dann DNSSEC beim neuen Anbieter aktivieren und den neuen DS-Record einreichen.

Wann DNSSEC aktivieren – und wann nicht

DNSSEC ist für Domains sinnvoll, die für Dienste mit erhöhtem Schutzbedarf genutzt werden – insbesondere für E-Mail-Infrastruktur. Hier ist DANE (DNS-based Authentication of Named Entities) der entscheidende Faktor: DANE ermöglicht es, TLS-Zertifikate für Mailserver über TLSA-Records direkt in DNS zu verankern und damit unabhängig von klassischen Certificate Authorities zu validieren. Das schließt eine strukturelle Schwachstelle im E-Mail-Transport, die STARTTLS allein nicht löst.

DANE setzt zwingend DNSSEC voraus – ohne signierte Zone kein vertrauenswürdiger TLSA-Record. Weitere sinnvolle Einsatzgebiete sind VPN-Gateways, Authentifizierungsendpunkte und öffentliche APIs. Für reine Weiterleitungsdomains ohne aktive Dienste ist der Aufwand geringer zu gewichten. Wer DNSSEC aktiviert, übernimmt damit auch die Betriebsverantwortung – und sollte sicherstellen, dass Monitoring und Eskalationspfade stehen, bevor die erste Signatur in der TLD-Zone landet.

Fazit

Der DENIC-Vorfall vom 5. Mai war ein seltenes Ereignis – ein Fehler auf TLD-Registry-Ebene, der genau die Nutzer traf, die das höchste DNS-Sicherheitsniveau eingestellt hatten. Das ist kein Argument gegen DNSSEC, sondern für ein differenzierteres Verständnis von DNS-Sicherheit.

DNSSEC schützt die Integrität der Namensauflösung. DoT und DoH schützen den Transport. NTAs wie in RFC 7646 ermöglichen pragmatisches Incident-Response-Management ohne dauerhaften Sicherheitsverlust. Und ein validierender Resolver – ob selbst betrieben oder als Dienst bezogen – ist kein Nice-to-have, sondern Grundlage für jeden DNS-Sicherheitsansatz, der diesen Namen verdient.

Für Systemadministratoren lautet die praktische Konsequenz: Resolver-Konfiguration dokumentieren, DNSSEC-Validierung prüfen (dnscheck.tools), RRSIG-Ablaufdaten der eigenen Domains monitoren und einen definierten Eskalationspfad zum Registrar für den Fall haben, dass der Fehler – wie bei DENIC – nicht im eigenen Bereich liegt. Und nicht zuletzt: DNSSEC für die eigenen Domains konfigurieren.

DNS ist keine Set-and-forget-Infrastruktur. Das hat der Mai 2026 einmal mehr gezeigt.

FAQs

✚ Mein Monitoring meldet SERVFAIL für eine .de-Domain, obwohl der autoritative Nameserver korrekt antwortet. Woran liegt das?

Das klassische Bild eines DNSSEC-Validierungsfehlers in der übergeordneten Zone. Prüfen Sie zunächst mit dig @8.8.8.8 +dnssec <domain> A, ob der validierende Resolver eine EDE-Fehlermeldung mitliefert – etwa "DNSSEC Bogus" oder "Signature Expired". Anschließend lohnt ein Blick auf dnsviz.net, das die gesamte Vertrauenskette visualisiert und den fehlerhaften Schritt eindeutig benennt. Liegt der Fehler nicht in Ihrer eigenen Zone, sondern in der TLD-Zone, ist der Registrar der richtige erste Ansprechpartner – der Fehler liegt dann bei der Registry, nicht bei Ihnen.

✚ Wir wollen den DNS-Hosting-Anbieter wechseln und nutzen DNSSEC. Was ist zu beachten?

Der DS-Record-Übergang ist der kritische Punkt. Entfernen Sie zuerst den DS-Record beim Registrar und warten Sie, bis die TTL des DS-Records in der übergeordneten Zone vollständig abgelaufen ist – erst dann stellen Sie die Nameserver um. Nach erfolgreichem Umzug aktivieren Sie DNSSEC beim neuen Anbieter und reichen den neuen DS-Record ein. Wer diese Reihenfolge nicht einhält, riskiert eine gebrochene Vertrauenskette und damit Unerreichbarkeit für alle Nutzer mit validierenden Resolvern.

✚ DoT oder DoH – was sollten wir im Unternehmen einsetzen?

Das hängt vom Kontext ab. DoT über Port 853 ist im Netzwerk klar erkennbar und filterbar, was die Kontrolle über DNS-Traffic erleichtert – ein Argument für Umgebungen mit zentralem DNS-Monitoring. DoH über Port 443 ist kaum von regulärem HTTPS-Traffic zu unterscheiden, was die Durchsetzung unternehmensweiter DNS-Richtlinien erschwert, da DoH-fähige Anwendungen den lokalen Resolver umgehen können. Für Clients im Unternehmensnetz empfiehlt sich DoT mit einem intern betriebenen oder explizit konfigurierten Resolver; DoH sollte per Gruppenrichtlinie kontrolliert oder auf einen definierten internen Resolver umgeleitet werden.

✚ Was bringt DANE konkret für unseren Mailbetrieb?

DANE erlaubt es, das TLS-Zertifikat eines Mailservers über einen TLSA-Record direkt in DNS zu verankern. Ein empfangender Mailserver kann damit prüfen, ob das vorgelegte Zertifikat mit dem in DNS hinterlegten übereinstimmt – unabhängig von einer externen Certificate Authority. Das schließt eine bekannte Schwachstelle im SMTP-Transport: STARTTLS allein verhindert kein aktives Downgrade auf unverschlüsselte Verbindungen, DANE schon. Voraussetzung ist zwingend DNSSEC auf der eigenen Domain sowie Unterstützung beim Gegenstellen. Postfix und Exim unterstützen DANE; viele große Mailprovider ebenfalls.

✚ Wir betreiben einen rekursiven Resolver. Wie stellen wir sicher, dass DNSSEC-Validierung aktiv ist?

Bei BIND prüfen Sie, ob dnssec-validation auto; in der options-Sektion gesetzt ist – auto lädt den Trust Anchor für die Root-Zone automatisch per RFC 5011. Bei Unbound steuert auto-trust-anchor-file denselben Mechanismus. Nach einer Konfigurationsänderung sollte ein Test gegen sigfail.verteiltesysteme.net zeigen, dass der Resolver mit SERVFAIL antwortet, und ein Test gegen eine korrekt signierte Domain mit NOERROR. Zusätzlich empfiehlt sich dnscheck.tools aus dem Netz der betreffenden Clients, um sicherzustellen, dass tatsächlich der eigene Resolver verwendet wird – und nicht ein vom Betriebssystem oder Browser abweichend konfigurierter DoH-Endpunkt.