Was ist DNSSEC?

Das Domain Name System (DNS) ist das Telefonbuch des Internets. Es übersetzt deinedomain.de in eine IP-Adresse, einen Mailserver-Hostnamen oder einen TXT-Record. Aber das ursprüngliche DNS-Protokoll aus den 1980er Jahren wurde ohne Sicherheit entworfen — DNS-Antworten haben keine Signatur. Wer eine Antwort liefert, wird grundsätzlich geglaubt.

Das öffnet zwei klassische Angriffe:

Cache-Poisoning — Ein Angreifer manipuliert die DNS-Cache eines Resolvers (z.B. dein ISP oder ein Mailserver) und schleust gefälschte Antworten ein. Der berühmte Kaminsky-Angriff von 2008 hat genau das auf großer Skala demonstriert.
DNS-Spoofing — Ein Angreifer auf dem Netzwerkpfad fängt DNS-Anfragen ab und antwortet schneller als der echte Resolver mit einer manipulierten IP-Adresse.

Die Folge: dein Mailserver liefert Mails an den falschen MX, dein Browser landet auf einer Phishing-Seite, dein TLS-Zertifikat-Check zeigt das Falsche an. Alle DNS-basierten Sicherheitsmechanismen werden wertlos, wenn das DNS selbst manipuliert ist.

DNSSEC behebt das.

DNSSEC (Domain Name System Security Extensions, definiert in RFC 4033-4035) erweitert DNS um digitale Signaturen. Jeder DNS-Record wird vom Domain-Inhaber signiert, und ein validierender Resolver kann die Signatur gegen eine Vertrauenskette prüfen, die bis zur DNS-Root reicht.

Vereinfacht: DNSSEC ist für DNS, was HTTPS für HTTP ist — Authentizität und Integrität, aber keine Verschlüsselung. DNSSEC verbirgt nicht, was du anfragst (dafür gibt es DNS-over-HTTPS oder DNS-over-TLS), sondern garantiert, dass die Antwort echt und unverändert ist.

Wie funktioniert es?

DNSSEC fügt vier neue Record-Typen hinzu, die zusammen eine kryptografische Vertrauenskette bilden.

Die vier Record-Typen

Record	Zweck
DNSKEY	Der öffentliche Schlüssel deiner Zone. Mehrere können koexistieren (z.B. KSK = Key Signing Key, ZSK = Zone Signing Key).
RRSIG	Die Signatur über einen Record-Set. Jeder DNS-Record bekommt eine RRSIG mitgeliefert.
DS	Ein Hash deines DNSKEY, veröffentlicht in der übergeordneten Zone (typischerweise beim Registrar/TLD). Damit verankerst du deine Zone in der Vertrauenskette.
NSEC / NSEC3	Authenticated Denial of Existence — beweist, dass ein Name nicht existiert, statt einfach nichts zu antworten.

Die Vertrauenskette

Wenn ein validierender Resolver mail.deinedomain.de auflöst, läuft folgendes ab:

Root-Zone (.) signiert die DNSKEY der TLD .de — das wird durch das DNS Trust Anchor abgesichert (öffentlicher Root-KSK, hardcodiert in jedem validierenden Resolver)
TLD-Zone (.de) signiert die DS deiner Domain deinedomain.de
Deine Zone (deinedomain.de) signiert mit ihrer ZSK alle deine Records — A, MX, TXT, TLSA usw.

Wenn auch nur ein Glied dieser Kette bricht, schlägt die Validierung fehl und der Resolver liefert SERVFAIL zurück. Das ist gewollt — lieber gar keine Antwort als eine möglicherweise manipulierte.

Das AD-Bit

Wenn ein validierender Resolver eine Antwort erfolgreich validiert hat, setzt er in der DNS-Antwort das AD-Bit (Authenticated Data). Anwendungen, die DNSSEC-aware sind — z.B. ein DANE-fähiger Mailserver — prüfen dieses Bit, bevor sie der Antwort vertrauen.

DNSSEC bei deinem Provider aktivieren

DNSSEC ist ein Zwei-Schritte-Prozess: signieren (beim DNS-Hoster) und verankern (beim Registrar).

Schritt 1: Bei deinem DNS-Hoster aktivieren

Die meisten modernen DNS-Provider unterstützen DNSSEC kostenlos:

Provider	Pfad
Cloudflare	DNS → Settings → DNSSEC → Enable
AWS Route 53	Hosted Zone → DNSSEC signing → Enable
Google Cloud DNS	Zone → DNSSEC → On
Hetzner DNS Console	Zone → DNSSEC aktivieren
deSEC.io	automatisch aktiv

Der Hoster generiert das Schlüsselpaar und beginnt, deine Zone zu signieren. Du bekommst dann einen DS-Record angezeigt — eine Zeile mit Key Tag, Algorithm, Digest Type und Digest.

Schritt 2: DS-Record beim Registrar veröffentlichen

Den DS-Record musst du bei dem Registrar eintragen, bei dem deine Domain registriert ist (nicht zwingend der DNS-Hoster). Der Registrar leitet ihn an die TLD-Registry weiter, die ihn in der übergeordneten Zone publiziert — damit ist deine Zone in der Vertrauenskette verankert.

Registrar	Pfad
INWX	Domain → DNSSEC
Hetzner	Console → Domain → DNSSEC
Cloudflare Registrar	automatisch (Ein-Klick, falls DNS auch bei Cloudflare)
GoDaddy	DNS → DNSSEC
Strato	Domainverwaltung → DNS-Einstellungen → DNSSEC

Wichtig: Reihenfolge einhalten — erst signieren, dann DS publizieren. Wenn der DS schon in der Parent-Zone steht, bevor deine Zone signiert ist, wird die Domain bogus und für validierende Resolver unauffindbar (SERVFAIL).

DACH-Sonderfall: united-domains und Strato

Manche deutsche Registrare akzeptieren DS-Records nur, wenn auch deren eigene Nameserver verwendet werden. Beispiele: united-domains, Strato, 1blu. Wenn deine DNS bei Cloudflare, AWS oder einem anderen Drittanbieter liegt, hast du dort keine DNSSEC-Option — eine Geschäftsentscheidung, keine technische Notwendigkeit.

Dein Ausweg: Domain zu einem Registrar transferieren, der DS bei externen Nameservern akzeptiert (INWX, Hetzner, Cloudflare Registrar). Die Domain bleibt erreichbar, nur die Registry-Zuordnung wechselt.

Verifikation

Nach dem Setup willst du wissen, ob DNSSEC tatsächlich greift. Drei zuverlässige Wege:

# Cloudflare DoH abfragen, AD-Bit prüfen
curl -s "https://cloudflare-dns.com/dns-query?name=deinedomain.de&type=SOA&do=1" \
     -H "Accept: application/dns-json" | jq '.AD'
# Ausgabe: true → DNSSEC aktiv und valide

dnsviz.net — visuelle Trust-Chain-Analyse, zeigt grafisch, wo die Kette gegebenenfalls bricht
DMARCPulse — wir checken DNSSEC für jede überwachte Domain via DoH gegen Cloudflare 1.1.1.1 und alarmieren bei Bogus-Status

Propagation kann 24-48 Stunden dauern, bis die TLD den DS in der Parent-Zone publiziert hat.

Häufige Fallstricke

DS vor Signatur — wenn du den DS beim Registrar einträgst, bevor deine Zone vollständig signiert ist, wird die Domain bogus. Sofort den DS entfernen, bis die Signierung fertig ist.
Algorithm-Mismatch — moderne DNS-Hoster nutzen ECDSAP256SHA256 (Algorithm 13). Manche ältere Registrar-Frontends bieten nur RSA/SHA-256 (Algorithm 8) an. Achte darauf, dass beide Seiten dasselbe Verfahren verwenden.
Schlüsselrotation vergessen — manche DNS-Hoster rotieren ZSKs automatisch, andere nicht. Bei manuellem Setup eine ZSK-Rotation alle 30-90 Tage einplanen, KSKs seltener.
Externe Subdomains nicht delegiert — wenn du Subdomains an Drittanbieter delegierst (z.B. mail.deinedomain.de zu einem externen Mail-Provider), muss auch die Subdomain DNSSEC haben oder als insecure delegation markiert werden.
CD-Bit ignorieren — Resolver, die mit CD=1 (Checking Disabled) anfragen, wollen explizit keine Validierung. Anwendungen sollten standardmäßig validieren lassen.

Wer sollte DNSSEC nutzen?

Kurzantwort: jeder, der eine Domain für E-Mail oder sicherheitsrelevante Dienste betreibt.

Längere Antwort:

DANE-Voraussetzung — DANE-SMTP funktioniert ausschließlich auf DNSSEC-signierten Domains. Ohne DNSSEC kein TLSA, keine Cert-Pinning-Sicherheit für eingehende E-Mail.
Compliance — DSGVO und BSI-Empfehlungen sehen DNSSEC für sicherheitsrelevante Domains explizit vor. Im DACH-Raum ist die Adoption für .de-TLDs vergleichsweise hoch.
Phishing-Schutz — DNS-Spoofing ist eine reale Angriffsmethode auf öffentlichem WLAN, kompromittierten Routern, ISP-Infrastruktur. DNSSEC schließt diese Lücke.
Markenintegrität — wenn deine MX, A oder TXT-Records manipuliert werden, leidet die Reputation deiner Domain. DNSSEC bindet die Authentizität jedes Records an dich.

Ist DNSSEC ein Allheilmittel? Nein. Es ersetzt nicht TLS, schützt nicht vor kompromittierten Endgeräten, verhindert keine Phishing-E-Mails an sich. Aber es schließt eine fundamentale Lücke, auf die alle anderen DNS-basierten Sicherheitsstandards bauen — DMARC, DKIM, MTA-STS, DANE, BIMI.

Fazit

DNSSEC macht DNS verifizierbar. Statt blind dem Resolver zu vertrauen, prüft dein System die Signaturkette von der Root-Zone bis zur Antwort. Es ist die Grundlage, auf der modernes DANE-SMTP aufbaut, und ein Pflicht-Baustein für sicherheitsbewusste Domain-Inhaber.

Die Aktivierung ist bei den meisten DNS-Hostern Ein-Klick. Der einzige Stolperstein ist die DS-Veröffentlichung beim Registrar — und das auch nur, wenn dein Registrar externe Nameserver mit DNSSEC nicht unterstützt.

DMARCPulse überwacht den DNSSEC-Status jeder eingebundenen Domain kontinuierlich. Bei aktivem DNSSEC bekommst du grünes Licht im Dashboard. Bei bogus Validierungsfehlern (DS-Mismatch, abgelaufene Schlüssel) sendet DMARCPulse einen kritischen Alarm — bevor deine Domain für DANE-fähige Empfänger unauffindbar wird. Außerdem ist DNSSEC die Voraussetzung für die DANE-Empfehlungen, die DMARCPulse für jede Domain ausliefert. Starte noch heute.

Zusammenfassung

DNSSEC signiert DNS-Antworten kryptografisch und verhindert Spoofing/Cache-Poisoning
Aktivierung erfolgt zweistufig: signieren beim DNS-Hoster + DS-Record beim Registrar publizieren
Voraussetzung für DANE-SMTP — ohne DNSSEC kein TLSA-Pinning
Manche DACH-Registrare (united-domains, Strato) unterstützen DNSSEC nicht bei externen Nameservern — Transfer zu INWX/Hetzner/Cloudflare Registrar löst das
DMARCPulse überwacht DNSSEC kontinuierlich und alarmiert kritisch bei Bogus-Status

Was ist DNSSEC? — DNS-Antworten signieren und verifizieren

Das Problem: DNS vertraut blind