Was ist DNSSEC? Ein verständlicher Leitfaden zur DNS-Sicherheit

DNSSEC — kurz für DNS Security Extensions — ist die einzige verbreitete Verteidigung gegen DNS-Cache-Poisoning, den Angriff, mit dem ein Netzwerk-Angreifer Resolver darüber täuschen kann, wohin Ihre Domain zeigt. Es ist seit 2005 Standard, jeder große TLD signiert seine Zone, und alle großen Managed-DNS-Anbieter unterstützen es. Wenn Ihre öffentliche Domain DNSSEC nicht aktiviert hat, vertrauen Sie darauf, dass niemand zwischen Ihren Nutzern und Ihrem autoritativen Nameserver die Mittel oder Motivation hat, sie an einen schädlichen Ort umzuleiten. Diese Wette ist nicht mehr vernünftig.

Dieser Leitfaden ist der verständliche Einstieg: Was DNSSEC tatsächlich macht, warum es existiert, wie die Vertrauenskette auf hoher Ebene funktioniert und was Sie von Ihrem DNS-Anbieter erwarten sollten. Für die operative Mechanik — KSK- vs. ZSK-Rollen, Schlüssel-Rollover, Algorithmuswahl — lesen Sie den tieferen Leitfaden DNSSEC-Schlüsselverwaltung, sobald Sie die Grundlagen kennen.

Was DNSSEC tut (und was nicht)

DNSSEC fügt digitale Signaturen zu DNS-Datensätzen hinzu. Wenn Ihr autoritativer Nameserver einen A-Datensatz zurückgibt, der besagt, dass example.com auf 192.0.2.1 zeigt, gibt er außerdem eine kryptografische Signatur über diesen Datensatz zurück. Ein Resolver, der DNSSEC-Validierung unterstützt, kann die Signatur gegen den öffentlichen Schlüssel Ihrer Zone prüfen — und diesen öffentlichen Schlüssel gegen eine Kette bis hinauf zu einem fest verdrahteten Vertrauensanker — und die Antwort ablehnen, wenn die Signaturen nicht validieren.

Das ist die ganze Aufgabe. DNSSEC:

• ✅ Beweist, dass die Antwort vom richtigen autoritativen Server kommt. Ein Man-in-the-Middle kann keinen Datensatz fälschen, ohne die Signatur zu brechen.
• ✅ Erkennt Manipulation auf der Leitung oder im Cache. Selbst wenn der Cache eines Resolvers vergiftet ist, validieren die Signaturen nicht.
• ✅ Beweist, dass ein Datensatz nicht existiert (auch negative Antworten werden über NSEC/NSEC3-Datensätze signiert).

DNSSEC tut nicht:

• ❌ DNS-Anfragen oder -Antworten verschlüsseln. Wer den Verkehr beobachtet, sieht weiterhin, was Sie nachschlagen. Verwenden Sie DNS over HTTPS oder DNS over TLS dafür.
• ❌ Die Struktur Ihrer Zone verbergen. DNSSEC-Signaturen sind öffentlich; jeder kann sie abrufen.
• ❌ TLS oder HTTPS ersetzen. DNSSEC schützt das DNS selbst; sobald Sie eine IP-Adresse haben, liegt die Sicherheit der Verbindung beim Anwendungsprotokoll.
• ❌ Vor kompromittierten autoritativen Servern schützen. Wer Ihren Nameserver kontrolliert, kann mit Ihren privaten Zonenschlüsseln signieren, was er will. DNSSEC vertraut dem Schlüsselinhaber.

Warum es DNSSEC gibt — Das Cache-Poisoning-Problem

Das ursprüngliche DNS-Protokoll aus den 1980ern wurde für ein Netzwerk entworfen, in dem niemand aktiv betrog. Resolver fragten autoritative Server in Klartext-UDP nach Antworten und vertrauten allem, was zurückkam, solange die Quell-IP und eine 16-Bit-Transaktions-ID übereinstimmten.

Dieses Vertrauensmodell hielt bis 2008, als Dan Kaminsky praktisches Cache-Poisoning im großen Stil demonstrierte. Der Angriff funktioniert so:

1. Der Angreifer veranlasst einen rekursiven Resolver, einen Namen unter seiner Kontrolle aufzulösen (anything.example.com).
2. Während der Resolver auf eine Antwort vom autoritativen Server wartet, flutet der Angreifer ihn mit gefälschten Antworten und rät die 16-Bit-Transaktions-ID.
3. Wenn eine gefälschte Antwort das Rennen gewinnt, cacht der Resolver die Antwort des Angreifers — einen gefälschten A-Datensatz für example.com — und liefert ihn für die gesamte TTL bei jeder weiteren Anfrage.

Jeder Nutzer dieses Resolvers — potenziell Millionen Menschen — wird heimlich an den vom Angreifer gewählten Ort umgeleitet. Web-Verkehr, E-Mail, Software-Updates: alles wird zum Angreiferserver geleitet, bis der Cache-Eintrag abläuft.

Die DNS-Community reagierte mit drei Schutzschichten:

1. Quell-Port-Randomisierung an Resolvern (RFC 5452, 2009) — machte das Rennen viel schwerer durch 16 zusätzliche Bits Unvorhersehbarkeit.
2. DNS over HTTPS / DNS over TLS auf der Strecke Resolver-zu-Client — verschlüsselte das Gespräch, sodass ein Angreifer im lokalen Netz Anfragen weder sehen noch verändern kann.
3. DNSSEC auf der Strecke Autoritativ-zu-Resolver — fügte kryptografische Signaturen hinzu, sodass ein vergifteter Cache ungültige Signaturen erzeugt, die ein validierender Resolver ablehnt.

DNSSEC ist die einzige der drei Lösungen, die das eigentliche Problem auf der autoritativen Ebene wirklich löst. Quell-Port-Randomisierung erschwert den Angriff; DoH/DoT verändert nur, wer die Anfrage sehen kann, nicht wer Antworten fälschen kann. DNSSEC verifiziert die Antwort selbst.

Die Vertrauenskette — Eine hochrangige Sicht

Was DNSSEC im Internet-Maßstab funktionsfähig macht, ist, dass Resolver Ihren spezifischen öffentlichen Schlüssel nicht im Voraus kennen müssen. Stattdessen wandern sie eine Vertrauenskette von einem fest verdrahteten Wurzelschlüssel hinunter zu Ihrer Zone:

Wurzelzone (.)
    │  signiert mit Wurzel-KSK
    │  veröffentlicht DS-Datensatz für .com in der Wurzel
    ▼
.com TLD
    │  signiert mit .com-KSK
    │  veröffentlicht DS-Datensatz für example.com in .com
    ▼
example.com
    │  signiert alle Datensätze mit eigenen Schlüsseln
    │  Signatur am angeforderten Datensatz
    ▼
A-Datensatz: example.com → 192.0.2.1

Ein validierender Resolver folgt dieser Kette in umgekehrter Richtung:

1. Er erhält den signierten A-Datensatz von Ihrem autoritativen Server.
2. Er holt den DS-Datensatz für example.com von den .com-Nameservern und prüft, dass der Hash mit dem KSK Ihrer Zone übereinstimmt.
3. Er holt den DS-Datensatz für .com von den Wurzel-Nameservern und prüft den Hash gegen den KSK der .com-Zone.
4. Er prüft die Signatur der Wurzelzone gegen den fest verdrahteten Vertrauensanker (den Wurzel-KSK, ebenfalls von IANA unter https://data.iana.org/root-anchors/ veröffentlicht).

Wenn ein Glied der Kette nicht validiert, wird die Antwort als nicht vertrauenswürdig behandelt. Die meisten validierenden Resolver geben SERVFAIL zurück, statt eine möglicherweise manipulierte Antwort auszuliefern.

Sie müssen die Mechanik nicht verstehen, um DNSSEC zu nutzen. Ihr DNS-Anbieter generiert und rotiert die Schlüssel für Sie; Ihre einzige Aufgabe ist es, ein Stück — den DS-Datensatz — bei Ihrem Registrar zu veröffentlichen, damit die Kette Ihre Zone erreicht.

Für die volle mechanische Aufschlüsselung — KSK- vs. ZSK-Rollen, RRSIG-Datensätze, NSEC/NSEC3 zur authentifizierten Negativantwort — siehe Wie DNSSEC funktioniert.

So erkennen Sie, dass eine Domain DNSSEC nutzt

Führen Sie dig mit dem +dnssec-Flag gegen einen validierenden Resolver aus:

dig +dnssec example.com @1.1.1.1

Achten Sie auf zwei Dinge:

1. RRSIG-Datensätze im Antwortabschnitt, gepaart mit jedem abgefragten Datensatz-Set. Das sind die Signaturen.
2. Das AD-Flag (Authenticated Data) im Antwort-Header, das anzeigt, dass der Resolver die Kette erfolgreich validiert hat.

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
                                ^^
                                 │
                          AD-Flag gesetzt = Validierung erfolgreich
 
;; ANSWER SECTION:
example.com.         300  IN  A      192.0.2.1
example.com.         300  IN  RRSIG  A 13 2 300 20260601000000 ...
                                         ^^
                                          │
                                   Signaturdatensatz

Wenn Sie RRSIGs sehen, aber kein AD-Flag, validiert der Resolver nicht — versuchen Sie 1.1.1.1 oder 9.9.9.9, beide validieren standardmäßig. Wenn Sie keine RRSIGs sehen, ist die Zone nicht signiert.

Zur Visualisierung zeichnen DNSViz und der Verisign DNSSEC Debugger die volle Vertrauenskette und markieren Brüche.

Wann Sie DNSSEC aktivieren sollten

Kurz gesagt: immer, für jede öffentliche Domain.

Besonders wichtig in folgenden Fällen:

• Vertrauenskritische Dienste — Banken, E-Commerce, Identitätsanbieter, Behörden — wo ein erfolgreicher Cache-Poisoning-Angriff direkte Folgen hat.
• E-Mail — DNSSEC ist Voraussetzung für DANE/TLSA, das SMTP-TLS gegen Downgrade-Angriffe schützt. MTA-STS ist eine Teilalternative für Organisationen, die noch nicht DANE-fähig sind.
• EU-regulierte Einrichtungen unter NIS2 — Artikel 21(2)(h) verlangt „Leitlinien und Verfahren für den Einsatz von Kryptografie." Ein DNS-Anbieter, der DNSSEC nicht anbietet, oder ein Deployment ohne aktivierte DNSSEC, läuft Gefahr, als nicht konform eingestuft zu werden. Siehe den NIS2-und-DNS-Leitfaden für die vollständige Zuordnung.
• Compliance-getriebene Umgebungen — PCI DSS, HIPAA, ISO 27001 und verschiedene nationale Rahmen führen DNSSEC als empfohlene oder erwartete Kontrolle.

Es gibt im Wesentlichen keine Situationen, in denen DNSSEC für eine öffentliche Zone eine schlechte Idee ist. Die historischen Einwände — operative Komplexität, Schlüsselverwaltungsrisiko, Resolver-Kompatibilität — sind weitgehend durch Managed-DNS-Anbieter gelöst, die Schlüsselgenerierung, -rotation und DS-Veröffentlichung automatisch erledigen.

Worauf Sie bei einem DNSSEC-fähigen DNS-Anbieter achten sollten

Bei der Bewertung der DNSSEC-Unterstützung eines DNS-Anbieters fragen Sie:

DNSSEC bei DNScale aktivieren

DNScale aktiviert DNSSEC mit einem Klick pro Zone:

1. Öffnen Sie im Dashboard die Zone.
2. Klicken Sie auf DNSSEC aktivieren. DNScale generiert einen CSK (Combined Signing Key) mit ECDSA P-256.
3. Kopieren Sie den angezeigten DS-Datensatz zu Ihrem Registrar. Manche Registrare nehmen ihn direkt an; manche per API; manche verlangen weiterhin manuelle Eingabe.
4. Warten Sie 24–48 Stunden auf die Verbreitung des DS am TLD.
5. Verifizieren Sie mit dig +dnssec ihredomain @1.1.1.1 und prüfen Sie das AD-Flag.

Schlüsselrotation, Signatur-Erneuerung und Synchronisation mit der übergeordneten Zone laufen automatisch. Algorithmus-Aktualisierungen sind koordinierte Rollover, die DNScale ohne kundenseitig sichtbaren Ausfall durchführt.

Für die vollständige Schritt-für-Schritt-Anleitung inklusive registrarspezifischer Hinweise siehe DNSSEC-Setup-Leitfaden für DNScale. Für die zugrunde liegende Mechanik siehe Wie DNSSEC funktioniert und DNSSEC-Schlüsselverwaltung.

Quellen

• RFC 4033 — Einführung und Anforderungen der DNS Security Extensions
• RFC 4034 — Resource Records für die DNS Security Extensions
• RFC 4035 — Protokollanpassungen für die DNS Security Extensions
• RFC 5155 — DNSSEC Hashed Authenticated Denial of Existence (NSEC3)
• RFC 6781 — DNSSEC Operational Practices, Version 2
• RFC 8901 — Multi-Signer-DNSSEC-Modelle
• IANA Root Zone Trust Anchors
• DNSViz — Visualisierer für DNSSEC-Vertrauensketten
• Verisign DNSSEC Debugger

Weiterführende Lektüre

• Wie DNSSEC funktioniert — KSK/ZSK/DS/DNSKEY-Mechanik
• DNSSEC-Schlüsselverwaltung — operative Rollover-Verfahren
• DNSSEC-Setup-Leitfaden für DNScale — Produkt-Walkthrough
• DNSSEC vs DNS over HTTPS — Integrität vs. Privatsphäre
• NIS2 und DNS-Compliance — regulatorische Zuordnung
• DNS-Cache-Poisoning — der Angriff, den DNSSEC schlägt