DNS-Sicherheit: DNSSEC, DANE & CAA für E-Mail-Infrastruktur
SPF, DKIM, DMARC und MTA-STS sind alle DNS-basiert — ohne DNSSEC ist die gesamte E-Mail-Authentifizierung auf Sand gebaut. Dieses Kapitel deckt DNSSEC (RFC 4033/4034/4035), DANE TLSA-Records für Mailserver (RFC 6698/7672) und CAA-Records zur Kontrolle der Zertifikatsausstellung (RFC 8659) ab — mit Schritt-für-Schritt-Anleitungen für 16 Provider in 5 Kategorien.
Warum DNS-Sicherheit für E-Mail existenzkritisch ist
SPF, DKIM, DMARC und MTA-STS sind allesamt DNS-Records. Der empfangende Mailserver fragt bei jeder eingehenden E-Mail Ihre DNS-Zone ab, um die Authentizität zu prüfen — das macht DNS zum Single Point of Failure Ihrer gesamten E-Mail-Sicherheit. Wer DNS-Antworten fälschen kann (Cache-Poisoning, BGP-Hijacking, Resolver-Kompromittierung), umgeht alle Authentifizierungsmechanismen, ohne dass Sender oder Empfänger es bemerken.
DNSSEC (RFC 4033 ff.) schützt vor allen drei Klassen von DNS-Manipulation, indem es jede DNS-Antwort kryptografisch signiert. MX-Records, SPF-Records, DKIM-Public-Keys, DMARC-Policies und MTA-STS-TXT-Records werden so vor Manipulation geschützt. Ergänzend sichert DANE (RFC 6698/7672) die TLS-Verbindung zum MX-Host und CAA (RFC 8659) regelt, welche Zertifizierungsstellen TLS-Zertifikate für Ihre Domain ausstellen dürfen. Der Wolf-Agents Email Security Check prüft alle drei Schichten — DNSSEC-Chain, TLSA-Records und CAA-Records — automatisch in einem Scan.
Ohne DNSSEC ist die gesamte E-Mail-Authentifizierung kompromittierbar
Ein erfolgreicher DNS-Hijacking-Angriff erlaubt einem Angreifer, gleichzeitig MX-Records auf eigene Server umzuleiten (Mail-Interception), SPF-Records durch eigene IPs zu ersetzen (autorisierter Spam-Versand), DKIM-Public-Keys auszutauschen (gefälschte Signaturen bestehen), DMARC-Policies auf p=none zu setzen (Enforcement deaktiviert) und MTA-STS-Policies zu manipulieren (TLS-Erzwingung aufgehoben). Alle fünf Angriffe sind für die Domain-Inhaber zunächst unsichtbar, weil ausgehende E-Mails normal funktionieren. DNSSEC schließt diese Lücke an der Wurzel — die Resolver verwerfen manipulierte Antworten. Quelle: RFC 4033 § 3 (Services).
DNSSEC: Chain of Trust, Algorithmen und Schlüsselverwaltung
DNSSEC (DNS Security Extensions, RFC 4033 für Einführung, RFC 4034 für Resource-Record-Typen, RFC 4035 für Protokollmodifikationen) erweitert DNS um Datenherkunfts-Authentifizierung und Integritätsschutz — nicht aber Vertraulichkeit. RFC 4033 § 3 nennt explizit, dass DNSSEC weder Vertraulichkeit noch Schutz vor Denial-of-Service liefert. Die Kernidee: Jede DNS-Antwort wird mit dem privaten Schlüssel der Zone signiert (RRSIG-Record), und der Resolver validiert die Signatur über eine Chain of Trust bis zum bekannten Trust Anchor der Root-Zone.
DNS-Lookup-Sequenz mit DNSSEC-Validierung
Sequence-Diagramm: Client fragt Resolver, Resolver verfolgt die Delegations-Kette Root → TLD → Authoritativer NS und validiert die DNSSEC-Signaturkette. Bei erfolgreicher Validierung wird das AD-Flag (Authenticated Data) gesetzt — Voraussetzung für DANE, MTA-STS und CA/B-SC-085v2-Pflicht ab 15.3.2026.
Chain of Trust — von der Root-Zone bis zu Ihrer Domain
Root Zone (.) ← Trust Anchor (öffentlich bekannt)
│ DS + DNSKEY + RRSIG
▼
TLD-Zone (.de / .com / .at / .ch)
│ DS + DNSKEY + RRSIG
▼
Ihre Domain (example.com)
│ DNSKEY + RRSIG für jeden Record
▼
MX, SPF, DKIM, DMARC, MTA-STS, TLSA …
→ Alle kryptografisch signiertValidierende Resolver kennen ausschließlich den Trust Anchor der Root-Zone (RFC 4033 § 5: „a validating resolver will have to obtain the initial values of its trust anchors via some secure or trusted means outside the DNS protocol“). Über DS-Records (Delegation Signer, RFC 4034 § 5) wird die Vertrauenskette zur jeweils tieferen Zone weitergegeben. Wenn nur eine Stufe nicht signiert ist oder ein Signatur-Fehler auftritt, klassifiziert der Resolver die Antwort als Bogus (vier mögliche Validierungs-Zustände nach RFC 4033 § 5: Secure, Insecure, Bogus, Indeterminate) und verwirft sie.
DNSSEC-Resource-Records nach RFC 4034
| Record | Typ-Nummer | Funktion |
|---|---|---|
| DNSKEY | 48 | Öffentlicher Schlüssel der Zone (Flags + Protocol + Algorithm + Public Key) |
| RRSIG | 46 | Kryptografische Signatur für jeden RRset (Type Covered + Algorithm + Expiration + Signature) |
| DS | 43 | Delegation Signer beim Parent — Hash des Child-DNSKEY (Key Tag + Algorithm + Digest) |
| NSEC | 47 | Authentifizierter Nichtexistenz-Beweis (Next Owner Name + Type Bit Map) |
| NSEC3 | 50 | Wie NSEC, aber mit Hash-Wert statt Klartext-Name (RFC 5155, Schutz vor Zone-Walking) |
Algorithmus-Empfehlung: ECDSAP256SHA256 (Algorithmus 13) für neue Deployments
Nach RFC 8624 § 3.1 ist ECDSAP256SHA256 (Algorithmus 13) der empfohlene Standard-Algorithmus: „ECDSAP256SHA256 is the RECOMMENDED DNSKEY algorithm for use by new DNSSEC deployments, and users of RSA-based algorithms SHOULD upgrade to ECDSAP256SHA256.“ RSASHA256 (Algorithmus 8) bleibt nach RFC 8624 MUST für Implementierungen, wird aber zugunsten von ECDSA P-256 schrittweise abgelöst. Ed25519 (Algorithmus 15) ist nach IANA-Registry RECOMMENDED, aber noch nicht überall verfügbar. Cloudflare setzt laut developers.cloudflare.com/dns/dnssec zeichengenau auf „Algorithm 13 - Cloudflare's preferred cipher choice“. Quelle: IANA DNSSEC Algorithm Numbers Registry.
KSK vs. ZSK und Schlüssel-Rotation
DNSSEC unterscheidet zwei Schlüssel-Rollen: Key Signing Key (KSK) signiert den DNSKEY-RRset selbst und ist über den DS-Record beim Registrar verankert (Rotation = Registrar-Update); Zone Signing Key (ZSK) signiert alle anderen Records (Rotation = nur Zone-intern, häufiger). Diese Aufteilung erlaubt schnelle ZSK-Rotation (wöchentlich/monatlich) ohne Registrar-Aktion, während die KSK seltener rotiert wird (jährlich oder ad hoc). Cloudflare dokumentiert keinen spezifischen Rotations-Mechanismus öffentlich — auf Cloudflare-Side erfolgt die Rotation automatisch; der Registrar-DS-Record bleibt typisch konstant. Bei manuellem DNS (Self-Hosted BIND/NSD) übernimmt OpenDNSSEC oder BIND-9 inline-signing die Rotation automatisch.
NSEC vs. NSEC3 — Zone-Walking-Schutz
NSEC-Records (RFC 4034) verraten alle existierenden Hostnamen einer Zone („It is trivial to enumerate the contents of a zone“, RFC 4033 § 8 als Limitation). RFC 5155 (NSEC3) hasht die Namen kryptografisch und erschwert das Zone-Walking. Empfehlung: NSEC3 mit Opt-Out für stark delegierte Zonen (TLD-Registries); für End-Domain-Zonen ist NSEC oft ausreichend. Die meisten Provider (Cloudflare, IONOS, deSEC) entscheiden das selbstständig — kein manueller Eingriff nötig.
DS-Record beim Registrar — der häufigste DNSSEC-Fehler
Der häufigste DNSSEC-Konfigurationsfehler: DNSSEC beim DNS-Provider aktiviert, aber den DS-Record beim Registrar vergessen. Ohne DS-Record beim Parent existiert keine Vertrauenskette — validierende Resolver klassifizieren die Zone als Insecure (nicht Bogus, aber auch nicht Secure). DNSSEC ist dann praktisch wirkungslos. Bei DENIC (.de), .at-NIC, .ch-NIC und SWITCH gibt es jeweils eigene Registrar-Workflows zur DS-Record-Hinterlegung. Wenn Sie DNS und Registrar bei demselben Provider haben (z.B. Cloudflare-Registrar + Cloudflare DNS, IONOS-Registrar + IONOS DNS), erfolgt die DS-Synchronisation typischerweise automatisch.
Algorithmus-13-Konvergenz bei Hyperscalern (Mehrwert-Stand 2026-05-18)
Mehrere große DNS-Provider konvergieren auf ECDSAP256SHA256 (Algorithmus 13) als Default: Cloudflare bezeichnet ihn auf developers.cloudflare.com/dns/dnssec als „Cloudflare's preferred cipher choice“. Microsoft Azure DNS dokumentiert zeichengenau auf learn.microsoft.com/en-us/azure/dns/dnssec (Abruf 2026-05-18): „Zones are DNSSEC signed using Elliptic Curve Digital Signature Algorithm (ECDSAP256SHA256).“ Zudem implementiert Azure DNS gemäß derselben Quelle RFC 9824 (Compact Denial of Existence) als Nachfolger von NSEC/NSEC3 — Microsoft begründet: „The older iterations of NSEC and NSEC3 are not used by Azure DNS because they allow zone enumeration or offline dictionary attacks.“ Netcup setzt im CCP ebenfalls Algorithmus 13 als Default. Konsequenz für Migration: Wer von RSASHA256 (Algorithmus 8) zu Algorithmus 13 migriert, folgt damit dem von RFC 8624 § 3.1 empfohlenen Pfad und der dokumentierten Hyperscaler-Konvergenz.
DNSSEC Chain of Trust — Root → TLD → Apex → signierte RRSets
Hierarchische 4-Stufen-Trust-Chain: Root-Zone signiert mit KSK-2017 Trust Anchor (out-of-band Distribution per RFC 4033 § 5) → TLD-Zone (.de/.com/.at/.ch) via DS-Record an Root → Apex-Zone (example.com) via DS-Record an TLD → einzelne RRSets (MX/SPF/DKIM/DMARC/MTA-STS/TLSA/CAA) mit RRSIG. Schutz aller E-Mail-Authentifizierungs-Records vor Cache-Poisoning und DNS-Spoofing.
DNSSEC Signing + Validation — DS-DNSKEY-RRSIG Sequence
Vertikale Sequence mit 4 Lanes: Signer (ZSK + KSK) → DNS-Server → Validierender Resolver → Parent-Zone/Registrar. Wie ein RRSet via ZSK signiert wird (→ RRSIG), wie der DNSKEY-RRSet via KSK signiert wird (→ DS-Hash beim Parent), und wie der Resolver die Chain-of-Trust validiert bis zum AD-Flag (Authenticated Data, RFC 4035 § 3.2.3).
NSEC vs NSEC3 — Zone-Walking-Schutz im Vergleich
Side-by-Side-Vergleich: NSEC (RFC 4034 § 4) als Klartext-Owner-Name-Verkettung — Zone enumerierbar (Zone-Walk möglich). NSEC3 (RFC 5155) als hash-basierte Verkettung mit Salt + Iterationen — Zone vor Walking geschützt. Opt-Out-Annotation für TLD-Registries (RFC 5155 § 6).
DNSSEC-Algorithmus-Migration — Timeline 2005-2026
Horizontale Zeitachse mit Algorithmus-Bubbles und IANA-Status-Markierung: Alg. 5 RSASHA1 (NOT RECOMMENDED, 2005) → Alg. 7 RSASHA1-NSEC3 (NOT RECOMMENDED, 2009) → Alg. 8 RSASHA256 (MUST, 2009) → Alg. 13 ECDSAP256SHA256 (MUST + RECOMMENDED, 2012) → Alg. 15 Ed25519 (RECOMMENDED future, 2017). Provider-Defaults: Cloudflare/Netcup/deSEC = Alg. 13.
DNSSEC-Validierungs-Stages — 4 Resolver-Zustände (RFC 4033 § 5)
4-Zustands-State-Diagram nach RFC 4033 § 5: Secure (grün, DNSKEY + RRSIG + DS-Chain valid + AD-Flag), Insecure (gelb, kein DS-Record, Zone explizit unsigniert), Bogus (rot, DS vorhanden aber Signatur-Fehler), Indeterminate (grau, Resolver kann nicht entscheiden). Transitions-Bedingungen + Anwendungsbeispiele + Praxis-Konsequenzen.
DANE: TLSA-Records für Mailserver-Authentifizierung
DANE (DNS-Based Authentication of Named Entities) bindet TLS-Server-Zertifikate kryptografisch an DNS-Namen via TLSA-Records. Statt der klassischen Web-PKI (mit über 100 vertrauenswürdigen CAs, von denen jede einzelne Ihre Domain ausstellen könnte) erlauben TLSA-Records exakt zu definieren, welches Zertifikat oder welcher Public-Key am MX-Host akzeptabel ist. Für SMTP definiert RFC 7672 die opportunistische Anwendung — downgrade-resistente Verschlüsselung statt klassischer StartTLS-Beliebigkeit.
TLSA-Record-Struktur (RFC 6698 § 2)
; DANE TLSA-Record für MX-Host (RFC 7672 § 3.1.3)
; Format: _._. IN TLSA
_25._tcp.mx1.example.com. IN TLSA 3 1 1 53eede6fbcd34c0eba3...
; Bedeutung der drei Zahlen (RFC 6698 § 2.1):
; Usage 3 = DANE-EE (Domain-issued End-Entity, RFC 7672 empfohlen)
; Selector 1 = SubjectPublicKeyInfo (Public-Key statt Voll-Cert)
; Matching 1 = SHA-256-Hash
;
; Voraussetzung (RFC 7672 § 3): DNSSEC am MX-Host UND am TLSA-Record
; (sonst ignoriert der Sender den Record). Jeder TLSA-Record hat drei Felder (RFC 6698 § 2.1): Certificate Usage (0-3, was bindet der Record?), Selector (0 = volles Zertifikat, 1 = SubjectPublicKeyInfo) und Matching Type (0 = exakt, 1 = SHA-256, 2 = SHA-512). Für SMTP empfiehlt RFC 7672 zwei Usage-Werte: DANE-EE (3) für End-Entity-Zertifikate (am häufigsten — kein PKIX-Check nötig, einzelne Mailserver-Domain) und DANE-TA (2) für Trust-Anchor-Zertifikate (Hosting-Provider mit vielen Customer-Domains). PKIX-EE (1) und PKIX-TA (0) werden für Port-25-SMTP explizit nicht empfohlen, weil MTAs keine umfassenden CA-Trust-Stores haben.
DANE setzt DNSSEC zwingend voraus
Ohne DNSSEC sind TLSA-Records wirkungslos. RFC 7672 § 3 fordert: TLSA-Records müssen DNSSEC-signiert sein, sonst werden sie vom sendenden Mailserver ignoriert. Ein aktivierter DANE-Modus ohne aktive DNSSEC-Kette führt nicht zu Fehlern — sondern dazu, dass DANE einfach übersprungen wird. Die Lookup-Reihenfolge nach RFC 7672 § 2.2.1: „An MX hostname with worse preference that has TLSA records MUST NOT preempt one with better preference that has none.“ — der sendende Server folgt strikt der MX-Priorität und nutzt DANE nur, wenn am gewählten MX-Host TLSA-Records vorhanden sind.
DANE vs. MTA-STS — wann welche Methode?
DANE (RFC 7672) sichert SMTP-Transport über DNS-basierte TLSA-Records und braucht zwingend DNSSEC. MTA-STS (RFC 8461) löst dasselbe Problem über eine HTTPS-Policy auf mta-sts.example.com und funktioniert ohne DNSSEC (Policy-Abruf läuft über klassische PKI). Pragmatische Empfehlung: Self-Hosted-Mailserver mit eigenem DNSSEC → DANE als Hauptlösung (Postfix/Exim/Mailcow). Cloud-Provider (Microsoft 365, Google Workspace), die keine TLSA-Records auf ihren MX-Hosts veröffentlichen → MTA-STS als Ersatz. Wer beides aktivieren kann, erhöht die Resilienz: DANE für hochsichere Pfade, MTA-STS als Fallback. Quelle: RFC 7672 § 3.
DANE-, DNSSEC- und CAA-Test-Tools (Mehrwert-Recherche 2026-05-18)
Für die Verifikation einer DNSSEC+DANE+CAA-Konfiguration sind drei externe Tools etabliert: DNSViz (dnsviz.net) ist laut Eigenbeschreibung „a tool for visualizing the status of a DNS zone“ — entwickelt von Sandia National Laboratories mit Unterstützung durch Verisign und DNS-OARC, Open-Source auf GitHub. Verisign DNSSEC Debugger (dnssec-debugger.verisignlabs.com) erlaubt das Setzen von Custom-Trust-Anchors und alternativen Nameservern für tiefes Chain-of-Trust-Debugging. Für SMTP-DANE prüft der DANE SMTP Validator (dane.sys4.de) — laut Footer „Brought to you by Viktor Dukhovni, dotplex and sys4“ — TLSA-Records speziell für E-Mail-Übertragungen und listet häufige Implementierungsfehler dokumentiert. Praxis-Empfehlung: zuerst DNSViz für Visual-Audit, dann Verisign-Debugger für Chain-Detail bei Bogus-Befund, abschließend DANE SMTP Validator pro MX-Host vor Production-Release.
TLSA-Rollover-Strategie nach RFC 7671 § 8.1 (V4-Information-Gain 2026-05-18)
Bei jedem TLS-Zertifikat-Wechsel (Let's-Encrypt-Renewal alle 60–90 Tage, Sectigo/DigiCert-Renewals 1-jährig oder kürzer) droht ein DANE-Bounce, wenn der TLSA-Record nicht synchron aktualisiert wird. RFC 7671 § 8.1 „Key Rollover with Fixed TLSA Parameters“ empfiehlt die Current+Next-Pre-Publishing-Strategie zeichengenau: „TLSA records matching the existing server certificate chain (or raw public keys) are first augmented with corresponding records matching the future keys, at least two Times to Live (TTLs) or longer before the new chain is deployed.“ Praktisch heißt das: zwei TLSA-Records (alter + neuer Public-Key-Hash) gleichzeitig veröffentlichen, mindestens zwei TTL-Zyklen vor dem Cert-Wechsel — erst danach den alten TLSA-Record entfernen. Selector 1 (SubjectPublicKeyInfo) bleibt stabil, wenn der private Key beim Renewal nicht rotiert wird (acme-mailcow + certbot --reuse-key Default-Verhalten). Automatisierungs-Pattern: Postfix Pre-Renewal-Hook, Cloudflare-API, Hetzner DNS API + hash-slinger, deSEC API. Cross-Reference: Postfix Pre-Renewal-Hook-Pattern und Mailcow extra.cf Renewal-Workflow.
DANE TLSA Handshake — Mailserver-zu-Mailserver-Authentifizierung
8-Schritte-Sequence mit 4 Lanes (Sender-MTA / DNS-Resolver mit DNSSEC / Empfänger-MTA / CA optional): MX-Lookup → DNSKEY-Validierung → TLSA-Lookup → STARTTLS → Cert/PubKey-Hash gegen TLSA-Record vergleichen. Bei Match: Mail verschlüsseln + senden. Bei Mismatch: Connection-Abbruch (kein STARTTLS-Downgrade möglich).
Self-Hosted DANE-Stack — DNS + MTA + TLS in 3 Schichten
Horizontale 3-Schichten-Architektur einer Self-Hosted-DANE-Konfiguration: Schicht 1 DNS-Layer (signierte Zone mit TLSA-Record, BIND + OpenDNSSEC). Schicht 2 MTA-Layer (Postfix 2.11+ smtp_tls_security_level=dane / Exim SUPPORT_DANE=yes + GnuTLS 3.0.0+ / Mailcow Postfix-Container). Schicht 3 TLS-Layer (Let's Encrypt + posttls-finger-Validierung + hash-slinger-TLSA-Generation).
CAA: Certification Authority Authorization
Ein CAA-Record (RFC 8659) ist ein DNS-Eintrag, der festlegt, welche Zertifizierungsstellen TLS-Zertifikate für Ihre Domain ausstellen dürfen. Vor jeder Zertifikatsausstellung muss eine konforme CA prüfen, ob für die angefragte Domain (oder eine übergeordnete Domain) ein CAA-Record existiert — und die Ausstellung verweigern, wenn die eigene CA nicht autorisiert ist. CAA schützt dadurch vor versehentlicher oder bösartiger Zertifikatsausstellung über kompromittierte CAs.
CAA-Record-Syntax (RFC 8659 § 3 + § 4.2)
; CAA-Records nach RFC 8659 § 4 — drei Tags
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issuewild ";" ; Keine Wildcards zulassen
example.com. IN CAA 0 iodef "mailto:security@example.com"
; Subdomain mit anderem Issuer:
mta-sts.example.com. IN CAA 0 issue "letsencrypt.org"
; Bedeutung:
; issue = autorisierte CA für Standard-Zertifikate
; issuewild = autorisierte CA für Wildcard-Zertifikate (";" = blockiert)
; iodef = Incident-Kontakt bei CAA-Violation
Drei Tags definiert RFC 8659: issue autorisiert eine CA für reguläre Zertifikate (Wert = CA-Domain oder ";" für komplettes Verbot), issuewild autorisiert für Wildcard-Zertifikate (überschreibt issue, wenn vorhanden) und iodef ist die Incident-Kontakt-URL (mailto: / http: / https:) für CAA-Violation-Reporting. Die CA durchsucht die DNS-Hierarchie aufwärts (von mta-sts.example.com → example.com → com) und nutzt den ersten gefundenen CAA-RRset. Critical Flag (Bit 0): Wenn gesetzt und der Tag unbekannt, MUSS die CA die Ausstellung verweigern — schützt vor zukünftigen Semantik-Erweiterungen.
CAA und MTA-STS — kritische Wechselwirkung
MTA-STS verlangt ein TLS-Zertifikat auf mta-sts.example.com. Wenn Ihr CAA-Record nur eine spezifische CA autorisiert (z.B. issue "letsencrypt.org"), MUSS der MTA-STS-Hosting-Provider eine Let's-Encrypt-Zertifikatsausstellung unterstützen — sonst schlägt die Zertifikatsausstellung fehl und MTA-STS wird wirkungslos. Praktische Lösung: Wenn Sie CAA-Records nutzen, mindestens auf mta-sts-Subdomain eine kompatible CA autorisieren. Bei mehreren Diensten in einer Zone (Web auf Cloudflare = Cloudflare-CA, Mail auf eigenem Server = Let's Encrypt) entweder mehrere issue-Tags am Apex setzen oder pro Subdomain spezifische CAA-Records.
CA/Browser-Forum Ballot SC-085v2 — DNSSEC-Pflicht bei CAA-Lookups ab 15. März 2026
Das CA/Browser-Forum hat im Juni 2025 mit Ballot SC-085v2 beschlossen, dass alle öffentlichen CAs ab dem 15. März 2026 DNSSEC-Validierung bei CAA-Lookups und Domain Control Validation (DCV) durchführen müssen. Ohne aktive DNSSEC-Kette werden CAA-Records als „nicht autoritativ“ behandelt — und CAs müssen restriktiver werden. Praxis-Impact: Wer heute CAA + DNSSEC korrekt konfiguriert, ist Launch-Day-Ready für SC-085v2. Wer CAA ohne DNSSEC betreibt, riskiert Zertifikats-Ausstellungs-Verzögerungen ab März 2026. Parallel reduziert Ballot SC-081v3 die maximale TLS-Zertifikatslaufzeit stufenweise: 200 Tage ab 15.3.2026, 100 Tage ab 15.3.2027, 47 Tage ab 15.3.2029 — Automatisierungs-Pflicht für Zertifikat-Erneuerung steigt erheblich.
CAA Authorization-Flow — CA-Issuance-Validation + CA/B SC-085v2
DNS-Hygiene: Verwaiste Records und SubdoMailing-Prävention
DNSSEC schützt vor Manipulation bestehender Records — nicht vor Übernahme verwaister Records. Die Anfang 2024 von Guardio Labs aufgedeckte SubdoMailing-Kampagne nutzt genau diese Lücke: Über 8.000 Domains (darunter MSN, VMware, McAfee, CBS, UNICEF) wurden durch verwaiste CNAMEs und abgelaufene SPF-Includes für massiven Spam-Versand missbraucht — alle Spam-Mails mit gültigem SPF, DKIM und DMARC, weil die Angreifer die DNS-Records legitim kontrollieren.
Wie SubdoMailing technisch funktioniert
; Verwaister CNAME — Angreifer übernimmt die Ziel-Domain
old-newsletter.example.com. IN CNAME abandoned-saas-provider.com.
; ↑
; Wenn abandoned-saas-provider.com vom Angreifer registriert wird,
; kontrolliert er den vollen Hostnamen old-newsletter.example.com
; — inklusive aller TLS-Zertifikate, die er per ACME ausstellen kann.
; Abgelaufener SPF-Include — analoge Übernahme
example.com. IN TXT "v=spf1 include:defunct-service.com -all"
; ↑
; Der include verleiht alle IPs der übernommenen Domain Sender-Autorität
; — Spam wird mit gültigem SPF+DKIM+DMARC verschickt.
Der Angreifer scannt automatisiert große Domain-Bestände nach CNAMEs, die auf abgelaufene oder gelöschte Dienst-Domains zeigen. Findet er einen Treffer, registriert er die abgelaufene Domain neu — und kontrolliert damit den vollen Subdomain-Hostnamen der Opfer-Organisation. Inklusive TLS-Zertifikat (via ACME ausstellbar) und gültiger SPF-/DKIM-Authentifizierung. Verwaiste SPF-Includes funktionieren analog: include:defunct-service.com verleiht der übernommenen Domain Sender-Autorität für die Original-Domain. Schutzmaßnahme: regelmäßiges DNS-Audit (mindestens vierteljährlich), automatisches Monitoring auf SPF-Include-Changes, sofortige Entfernung von CNAMEs bei Dienst-Abschaltung.
Pflicht-Checkliste DNS-Hygiene (mindestens vierteljährlich)
- CNAME-Audit: Alle CNAMEs ihrer Zone listen (
dig AXFR @ns example.comoder Provider-Export), Ziel-Domains auf Aktivität prüfen. Verwaiste CNAMEs sofort entfernen. - SPF-Include-Validierung: Alle
include:-Mechanismen in der SPF-Kette manuell prüfen — verwaiste Service-Provider entfernen. Wolf-Agents Scanner zählt das SPF-10-Lookup-Limit automatisch. - MX-Konsistenz: MX-Hostnamen auf Auflösbarkeit testen — bei Provider-Wechsel alte MX-Records ohne Verzögerung löschen.
- TXT-Records: Alte Verifikations-TXTs (Google-Site-Verification, Facebook-Domain-Verification) regelmäßig prüfen und obsolete Einträge entfernen.
- DS-Record-Konsistenz: DS-Record beim Registrar gegen DNSKEY beim DNS-Provider verifizieren — Asymmetrie ist häufigster DNSSEC-Bogus-Grund.
- CAA-Records: Bei jeder Änderung des CA-Mix (Hinzunahme neuer Dienste mit eigenen Zertifikaten) die CAA-Liste aktualisieren — sonst blockiert die CAA-Politik unbeabsichtigt neue Zertifikatsausstellungen.
Bedrohungs-Cluster: SubdoMailing-Deep-Dive (T1584.001) und Email-Spoofing. Das Wolf-Agents Attack-Surface-Monitoring überwacht CT-Logs via Certstream-Integration und alarmiert sofort, wenn für Ihre Subdomains ungewöhnliche TLS-Zertifikate ausgestellt werden — ein Frühwarn-Signal für SubdoMailing-Übernahme-Versuche.
SubdoMailing Anti-Pattern — Angriffs-Sequence in 4 Schritten
4-stufige Angriffs-Sequence: Schritt 1 Verwaisung (Opfer-Domain hat verwaisten CNAME auf abgelaufene Service-Domain) → Schritt 2 Übernahme (Angreifer registriert die abgelaufene Domain) → Schritt 3 ACME-Cert (Angreifer veröffentlicht eigenen TLS-Cert) → Schritt 4 Spam-Versand mit gültigem SPF (via include) + DKIM (am übernommenen Host) + DMARC-Pass — alles authentisch. Guardio Labs 2024: 8.000+ Opfer-Domains, 5 Mio Spam-Mails/Tag.
DNS-Provider-Wahl im DACH-Raum für E-Mail-Sicherheit
Die Wahl des DNS-Providers entscheidet implizit über die Verfügbarkeit von DNSSEC und damit über die Wirksamkeit von DANE. Die folgende Matrix beschreibt den Stand der DNSSEC-Unterstützung bei den im DACH-Raum gängigen Providern (Stand der jeweiligen offiziellen Doku, Abruf 2026-05-16). Hetzner DNS ist hier ein bewusst konservativ formulierter Fall: Die letzte explizit datierte Hetzner-Doku zu DNSSEC stammt vom Oktober 2018 (veröffentlicht 25. März 2020) und beschreibt DNSSEC dort als nicht unterstützt — den aktuellen Status der Hetzner DNS Console sollten Sie pro Zone selbst im Panel verifizieren.
| Provider | DNSSEC-Signing | CAA | DANE-Eignung | Quelle |
|---|---|---|---|---|
| Cloudflare DNS | Ja, Alg. 13 (1-Click) | Ja | Voll geeignet | developers.cloudflare.com |
| Hetzner DNS Console | Stand Hetzner-Doku Oktober 2018: nicht unterstützt — aktueller Status im Panel prüfen | Ja | Eingeschränkt — siehe Hetzner-Panel-Bestätigung | docs.hetzner.com |
| IONOS | Ja, automatisch bei IONOS-Nameservern | Ja | Voll geeignet (mit IONOS-Mail) | ionos.de/hilfe |
| Netcup | Ja, im CCP-Panel | Ja | Voll geeignet | netcup.com |
| Strato Domain Guard | Ja, je nach TLD | Ja | Voll geeignet (TLD-abhängig) | strato.de/faq |
| deSEC.io (Berlin) | Ja, by default | Ja | Voll geeignet (für DANE empfohlen) | desec.io |
Wann DNS-Provider-Wechsel sinnvoll ist
Ein Provider-Wechsel allein für DNSSEC ist meistens nicht nötig — die meisten DACH-Hoster bieten heute Domain-Verwaltung mit DNSSEC-Aktivierung an. Wenn Ihr aktueller Provider DNSSEC nicht unterstützt (oder die Doku unklar ist), gibt es zwei Strategien: (1) Komplett-Wechsel zu einem DNSSEC-nativen Provider wie deSEC, Cloudflare oder INWX. (2) Split-Setup: Domain-Registrierung beim aktuellen Provider lassen, nur die Nameserver auf einen DNSSEC-fähigen DNS-Hoster umstellen (z.B. Hetzner-Registrar + deSEC-Nameserver). Bei Strategie 2 muss der DS-Record manuell beim Registrar gepflegt werden — bei Strategie 1 erfolgt das oft automatisch. Wolf-Agents-Empfehlung: Vor jedem Wechsel den Email Security Check laufen lassen, um die DNS-Kette zu dokumentieren — und nach dem Wechsel erneut, um die Validität zu bestätigen.
DNS-Provider sind nicht Mail-Provider
Cloudflare DNS und Hetzner DNS sind reine DNS-Hosting-Dienste — sie betreiben in dieser Funktion keine eigenen Mailserver. Der MX-Record zeigt auf einen externen Mailserver Ihrer Wahl (Microsoft 365, Google Workspace, Postfix/Mailcow auf eigenem Server, Proton Mail mit Custom Domain). Cloudflare ergänzt optional „Email Routing“ als kostenlosen Forward-Service mit eigenen Hostnamen (route1-3.mx.cloudflare.net), Hetzner DNS hat keine vergleichbare Funktion. Diese Trennung ist relevant für die SPF/DKIM/DMARC-Konfiguration: Die SPF-Records müssen das Mail-Backend autorisieren, nicht den DNS-Provider.
Multi-Provider-DNSSEC-Setup (V4-Information-Gain 2026-05-18)
Wer NIS2 lit. c (Aufrechterhaltung des Betriebs) auf der DNS-Schicht hart umsetzt, betreibt nicht nur einen Primary-DNS-Provider, sondern auch einen Secondary-DNS-Provider (Multi-NS-Anycast über Provider-Grenzen). Bei DNSSEC entsteht dabei eine Sonderfrage: Welcher Provider signiert die Zone? Es gibt drei Patterns: (1) Primary-Signed, Secondary-Replicated — der Primary signiert, Secondaries replizieren die signierte Zone unmodifiziert per AXFR/IXFR. Funktioniert mit allen DNSSEC-fähigen Sekundären (z.B. Cloudflare Primary + deSEC Secondary mit AXFR-Push) und ist das Standard-Pattern. (2) Multi-Signer-DNSSEC nach RFC 8901 — beide Provider signieren mit eigenen Schlüsseln, alle DNSKEYs werden in einem gemeinsamen RRset publiziert. Cloudflare unterstützt das per dnssec_multi_signer-Flag (API). Komplexer, aber resilient gegen Single-Provider-Outage auf der Signing-Schicht. (3) Unsigned-Secondary-Fallback — nur Primary signiert, Secondary serviert unsigniert. Anti-Pattern, weil Resolver bei Failover Bogus-Antworten bekommen können — nicht empfohlen. Praxis-Empfehlung für DACH-KMU: Pattern 1 (Primary Cloudflare/Netcup + Secondary deSEC mit AXFR) ist der pragmatische Sweet-Spot. Pattern 2 ist Enterprise-Setup mit RFC-8901-Audit-Aufwand.
DNS-Lookup-Budget-Cross-Reference (V4-Information-Gain 2026-05-18)
DNSSEC + DANE erhöhen die DNS-Lookup-Last pro Mail-Übertragung — bei jedem MX-Lookup kommen DNSKEY-, DS- und RRSIG-Lookups hinzu, plus TLSA-Lookups bei DANE-fähigem Mailserver. Das ist im Resolver typisch transparent gecacht (DNSKEY-TTLs 3600 s und länger), kann aber bei SPF-Lookup-Budget-Limits relevant werden: RFC 7208 § 4.6.4 begrenzt SPF-Mechanismen auf max. 10 DNS-Lookups pro Validierung — der mx-Mechanismus zählt alle MX-Records als zusätzliche A/AAAA-Lookups, und jeder weitere include: ist ein Lookup-Slot. Wenn Sie SPF mit mehreren Providern (Microsoft 365 + Sendgrid + Mailchimp + custom) kombinieren, sind 10 Lookups schnell erreicht — DNSSEC selbst zählt zwar nicht direkt im SPF-Limit, aber die zusätzliche Latenz an einem signierten Provider kann das Lookup-Timing verschieben. Cross-Reference: SPF-Kapitel-Index und MX-Infrastruktur-Kapitel-Index (SPF-Lookup-Budget-Block).
Cross-Provider-Übersicht: DNS-Wettbewerber neben Cloudflare/Hetzner DNS (Mehrwert-Stand 2026-05-18)
Über die DACH-Tabelle hinaus gibt es weitere DNS-Provider mit relevanten DNSSEC-Profilen. Quad9 (quad9.net, Sitz Zürich c/o SWITCH, Werdstrasse 2): Privacy-Resolver mit Standard-IP 9.9.9.9 + 149.112.112.112 — die empfohlene Konfiguration enthält laut Quad9-Doku „Recommended: Malware Blocking, DNSSEC Validation“. Quad9 ist also ein validierender Resolver, kein DNS-Hoster — relevant als Test-Resolver für Eigenprüfungen. NextDNS Inc. (nextdns.io, AS34939) ist ebenfalls Privacy-Resolver mit DNSSEC-Validierung und Log-Storage wahlweise in USA, EU, UK oder Schweiz. AWS Route 53 (aws.amazon.com/route53/features) ist Enterprise-DNS-Hoster mit DNSSEC-Signing (laut AWS-Feature-Seite: „Enable DNSSEC signing for all existing and new public hosted zones“) plus DNSSEC-Validierung im Route-53-Resolver — geeignet für AWS-zentrische Stacks. Microsoft Azure DNS nutzt ECDSAP256SHA256 und RFC 9824 (siehe Mehrwert-Block in Sektion 2). deSEC.io (Berlin, gemäß GitHub-Profil „desec-io“ Berliner Open-Source-Projekt mit aktiver Sponsor-Community; die exakte Rechtsform der Trägerorganisation ist über die JavaScript-basierte deSEC-Website ohne JS-Rendering nicht direkt verifizierbar — laut deSEC-Marketing-Material und Drittquellen tritt deSEC öffentlich als gemeinnütziger Verein auf, die Detail-Verifikation der Vereinssatzung erfordert tiefere Provider-Recherche) wird laut Provider-Marketing als „Free Secure DNS“ mit DNSSEC-by-Default betrieben und ist die natürliche EU-Alternative bei US-CLOUD-Act-Sensitivität.
DNS-Provider-Architektur — Managed vs Split-Setup vs Self-Hosted
Drei Architektur-Patterns nebeneinander: Pattern A Managed-DNS bei Registrar (IONOS-Registrar + IONOS-DNS, automatische DS-Sync), Pattern B Split-Setup (Hetzner-Robot + deSEC/Cloudflare, manuelle DS-Eintragung), Pattern C Self-Hosted BIND/NSD/Knot mit OpenDNSSEC-Inline-Signing. DS-Sync-Pfeile + Aufwand-Indikator.
DNSSEC-Coverage-Matrix — 16 Provider × 3 Dimensionen
Heatmap: 16 DACH-relevante DNS-Provider in 4 Kategorien (Cloud / DACH-DE / DACH-CH/AT / Self-Hosted) × 3 Dimensionen (Native DNSSEC-Signing / DS-Auto-Sync zu Registrar / CAA+TLSA-Record-Support). Konservativ-Markierung für Hetzner-DNS-Console (Stand Oktober 2018). Mehrwert-Spalten: SWITCH-Auto-Sync (Hostpoint), .at-NIC-Sync (World4You), Alg. 13 (Cloudflare/Netcup), 1-Click vs CCP-Multi-Step.
NIS2 lit. h Konformität durch DNSSEC, DANE und CAA
NIS2 Art. 21 Abs. 2 lit. h fordert „Konzepte und Verfahren für den Einsatz von Kryptografie und Verschlüsselung“ — DNSSEC ist eine direkt prüfbare technische Maßnahme, die diese Anforderung für die DNS-Schicht erfüllt. DANE TLSA-Records erfüllen lit. h zusätzlich auf der Transport-Schicht; CAA-Records ergänzen lit. b (Sicherheit für Netz- und Informationssysteme) durch nachweisbare Kontrolle der Zertifikatsausstellung. Die EU-Durchführungsverordnung 2024/2690 fordert in Erwägungsgrund 8 explizit „best practices for DNS security“ — DNSSEC ist hier eine zentrale Best Practice, ohne dass die Verordnung den Begriff DNSSEC selbst nennt.
NIS2 Art. 21 Abs. 2 lit. h
„Konzepte und Verfahren für den Einsatz von Kryptografie und Verschlüsselung“. DNSSEC + DANE TLSA bilden den prüfbaren Nachweis für die DNS- und MTA-Trust-Schicht. Ergänzend lit. c (Backup-DNS für Aufrechterhaltung des Betriebs) und lit. b (DNS-Audit-Prozesse als Risiko-Mitigation).
BSI IT-Grundschutz APP.3.9
Der BSI-Baustein „DNS-Server“ (Edition 2023) listet DNSSEC-Validierung als Schutzmaßnahme gegen DNS-Spoofing und Cache-Poisoning auf. Die genauen Mindeststandards sind im aktuellen IT-Grundschutz-Kompendium auf bsi.bund.de publiziert (Direktlink-Recherche 2026-05-16 zur Bestätigung empfohlen).
EU 2024/2690 (NIS2-Durchführungs-VO)
Erwägungsgrund 8 fordert „best practices for DNS security, and for internet routing security and routing hygiene“ sowie Erwägungsgrund 8 zur „deployment of internationally agreed and interoperable modern email communications standards“. DNSSEC + DANE + CAA bilden die operative Umsetzung dieser Best Practices, ohne dass die VO einzelne Standards namentlich vorschreibt.
NIS2 Art. 23 Meldepflichten: Ein erfolgreicher DNS-Hijacking-Angriff auf die MX-/MTA-STS-Records mit Klartext-Mitlesen von Geschäfts-E-Mails qualifiziert in der Regel als „erheblicher Sicherheitsvorfall“ — 24-Stunden-Frühwarnung, 72-Stunden-Vorfallsmeldung, Abschlussbericht innerhalb eines Monats. DNSSEC-signierte Zonen mit dokumentierter Chain-of-Trust und Wolf-Agents-Monitoring-Logs sind im Forensik-Prozess die zentrale Beweis-Grundlage.
DACH-Spezifika: In der Schweiz ergänzt das revidierte Datenschutzgesetz (revDSG) Art. 8 (Datensicherheit) die NIS2-Logik um eine eigene Pflicht zur „angemessenen technischen Maßnahmen“ — DNSSEC ist Stand der Technik. In Österreich setzt das NISG 2026 (BGBl. I Nr. 94/2025, Beschluss 12.12.2025, Kundmachung 23.12.2025) die EU-Richtlinie zum 1. Oktober 2026 in nationales Recht um — Zentrale Behörde wird das Bundesamt für Cybersicherheit (BMI nachgeordnet), offizielle Anlaufstelle nis.gv.at. Wolf-Agents-Kunden mit AT-Bezug können DNSSEC + DANE + CAA bereits jetzt als prüfbare Maßnahmen einrichten.
Der Wolf-Agents Email Security Check prüft alle 165 Kriterien — inklusive DNSSEC-Chain-Validierung von der Root-Zone, TLSA-Records auf allen MX-Hosts, CAA-Records am Apex und auf MTA-STS-Subdomains. Das Monitoring überwacht den DNS-Stack alle 6 Stunden, erkennt unautorisierte Änderungen (z.B. neue MX-Records, DS-Record-Asymmetrie) und alarmiert via Toast-Notifications, E-Mail oder Slack/Teams-Webhook. Ergänzend nutzt das Attack-Surface-Monitoring CT-Log-Monitoring via Certstream-Integration — neue TLS-Zertifikate für Ihre Subdomains werden als Frühwarn-Signal für SubdoMailing-Übernahmen erkannt.
Wolf-Agents CT-Log + DNSSEC Monitoring-Pipeline — 6 Stationen
Horizontale 6-Stationen-Pipeline: Stack-Detection (NS-Pattern + MX-Hostname Provider-Fingerprint) → DNSSEC-Chain-Validierung (Root → TLD → Apex → AD-Flag) → TLSA-Lookup an MX-Hosts → CAA-Lookup (Apex + mta-sts-Subdomain) → Certstream-Integration (CT-Log-Monitoring, Docker Port 8888) → Alarmierung via Customer-Alert-Hub S35 (Toast / Email / Slack / Teams). 6-h-Diff-Tracking in PostgreSQL + Unbound Port 5353 (100% EU).
DNS-Sicherheits-Anleitung für Ihren Provider:
Wie steht Ihre Domain bei DNS-Sicherheit?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.
Häufig gestellte Fragen
Was ist DNSSEC und warum ist es für E-Mail kritisch?
DNSSEC (DNS Security Extensions, RFC 4033/4034/4035) signiert DNS-Antworten kryptografisch und schützt damit vor Cache-Poisoning, DNS-Hijacking und Spoofing-Angriffen auf MX-, SPF-, DKIM-, DMARC- und MTA-STS-Records. Ohne DNSSEC kann ein Angreifer im Netzwerkpfad alle E-Mail-Authentifizierungs-Records fälschen — SPF/DKIM/DMARC werden wertlos. DNSSEC schließt diese Lücke durch eine Chain of Trust von der Root-Zone bis zur eigenen Domain.
Was ist DANE und wann brauche ich TLSA-Records?
DANE (DNS-Based Authentication of Named Entities, RFC 6698) bindet TLS-Server-Zertifikate kryptografisch an den DNS-Namen via TLSA-Records. Für SMTP definiert RFC 7672 die Anwendung: Statt der klassischen CA-PKI prüft der sendende Mailserver den TLSA-Record des MX-Hosts unter `_25._tcp.<mx-hostname>`. Vorteile: Resistenz gegen kompromittierte oder fehlerhafte Zertifizierungsstellen, downgrade-resistente Verschlüsselung. Voraussetzung: DNSSEC muss aktiv sein — ohne DNSSEC sind TLSA-Records wirkungslos.
Was ist CAA und wozu brauche ich es?
CAA (Certification Authority Authorization, RFC 8659) ist ein DNS-Record, mit dem Sie festlegen, welche Zertifizierungsstellen für Ihre Domain TLS-Zertifikate ausstellen dürfen. Beispiel: `example.com CAA 0 issue "letsencrypt.org"` erlaubt ausschließlich Let's Encrypt. Andere CAs müssen die Ausstellung verweigern. Das verhindert, dass Angreifer durch kompromittierte CAs gültige Zertifikate für Ihre Domain ausstellen können — insbesondere für MTA-STS-Subdomains wie `mta-sts.example.com`.
Wie hängen DNSSEC, DANE und MTA-STS zusammen?
DNSSEC sichert die DNS-Schicht. DANE (TLSA-Records) und MTA-STS (HTTPS-Policy) sichern die Transport-Schicht. DANE setzt DNSSEC zwingend voraus (RFC 7672), MTA-STS funktioniert auch ohne DNSSEC, weil der Policy-Abruf über HTTPS mit klassischer PKI-Validierung läuft. Praktische Empfehlung: DNSSEC immer aktivieren (NIS2 lit. h); DANE für eigene Mailserver (höchste Sicherheit), MTA-STS als komplementärer Schutz für Cloud-Mailserver (Microsoft 365, Google Workspace), die kein DANE-Signing anbieten.
Welche DNS-Provider unterstützen DNSSEC?
Direkt im DNS-Panel mit 1-Click oder automatisch: Cloudflare DNS (ECDSAP256SHA256, Algorithmus 13), IONOS (automatische Verwaltung bei eigenen Nameservern), Netcup (CCP-Panel), Strato Domain Guard, deSEC (DNSSEC by default, Berlin), INWX. Hetzner DNS Console hatte laut Stand der offiziellen Hetzner-Dokumentation (Oktober 2018, veröffentlicht 2020) noch keinen nativen DNSSEC-Signing-Support — der aktuelle Stand muss im DNS-Console-Panel pro Zone bestätigt werden. Alternative: Domain bei Hetzner-Registrar belassen, DNS-Verwaltung zu deSEC oder Cloudflare migrieren.
Was ist die SubdoMailing-Kampagne?
SubdoMailing ist eine 2024 aufgedeckte Angriffs-Kampagne, bei der über 8.000 Domains (darunter MSN, VMware, McAfee, CBS, UNICEF) durch verwaiste DNS-Records (CNAMEs auf abgelaufene Domains, abgelaufene SPF-Includes) für Spam-Versand missbraucht wurden — alle mit gültigem SPF, DKIM und DMARC. Die Angriffs-Kette nutzt fehlende DNS-Hygiene: Wer DNS-Records nicht regelmäßig auditiert, ermöglicht solche Übernahmen. Schutzmaßnahme: regelmäßige DNS-Audits, Entfernung verwaister CNAMEs, Validierung aller SPF-Includes.
Wie wirkt DNSSEC im NIS2-Kontext?
NIS2 Art. 21 Abs. 2 lit. h fordert „Konzepte und Verfahren für den Einsatz von Kryptografie und Verschlüsselung“. DNSSEC ist eine direkt prüfbare technische Maßnahme, die diese Anforderung für die DNS-Schicht erfüllt. Ergänzend lit. c (Sicherung der Aufrechterhaltung des Betriebs) bei Backup-DNS-Konfigurationen und lit. b (Risikoanalyse und Sicherheit für Netz- und Informationssysteme) für DNS-Audit-Prozesse. Die EU-Durchführungsverordnung 2024/2690 fordert in Erwägungsgrund 8 explizit „best practices for DNS security“ — DNSSEC ist hier eine zentrale Best Practice, ohne dass die Verordnung den Begriff DNSSEC selbst nennt.