Warum nutzen die meisten Domains immer noch kein DNSSEC?

**Drei Gruende.** Erstens machen es **Registrare** sperrig: in vielen Control-Panels musst du noch immer manuell einen DS-Record zwischen DNS-Host und Registrar kopieren, mit handgefuehrten Key-Rotationen. Zweitens **operatives Risiko**: bei einer Fehlkonfiguration bricht die Domain **nur fuer Nutzer auf validierenden Resolvern** (rund 30 % weltweit), und das ist der schlimmste Bug, weil er fuer die durchfuehrende Person unsichtbar ist. Drittens ist der **Business-Case unscharf**: Endnutzer sehen DNSSEC nicht, kein Browser zeigt ein Schloss dafuer, also schafft es nie auf die Launch-Checkliste. Die Verbreitung liegt je nach Statistik bei **5 bis 10 % der .com-Domains**.

Was genau ist die Vertrauenskette?

Eine Kette aus **Signaturen** von deiner Domain hinauf zu einem Schluessel, dem alle vertrauen. Deine Zone signiert ihre Records mit einem **ZSK** (Zone Signing Key). Der ZSK selbst wird vom **KSK** (Key Signing Key) signiert. Der Hash des KSK wird als **DS-Record** in der Parent-Zone (`.com`) veroeffentlicht. Der ZSK von `.com` signiert diesen DS-Record, der KSK von `.com` wird in einen DS-Record bei der **Root** gehasht, und der **Root-KSK** ist der globale Trust-Anchor, den jeder Resolver mitbringt. Brich ein Glied und die ganze Kette kollabiert fuer diese Domain.

KSK vs ZSK: was ist der Unterschied?

Der **ZSK (Zone Signing Key)** signiert die eigentlichen Records deiner Zone (A, MX, TXT, ...). Er wird oft rotiert (alle paar Wochen oder Monate), weil er stark genutzt wird. Der **KSK (Key Signing Key)** signiert nur das DNSKEY-Set. Er wird selten rotiert (jaehrlich oder weniger), weil jede Rotation den **DS-Record beim Parent** aktualisieren muss, ein TTL-Tanz ueber mehrere Tage. Die Aufteilung erlaubt es, den lauten ZSK ohne Registrar-Anfassen zu rotieren. **Flags 256 = ZSK, 257 = KSK** im DNSKEY-Record.

Warum sind DS-Records beim Parent so wichtig?

Ein DS-Record ist das **einzige, was die Parent-Zone ueber deine DNSSEC-Keys veroeffentlicht**. Es ist ein vom Parent signierter Hash deines KSK. Wenn ein Resolver deine Domain validiert, laeuft er **top-down**: er vertraut der Root, der Root-DS belegt, dass er `.com` vertrauen kann, der DS von `.com` belegt, dass er `example.com` vertrauen kann. **Kein DS beim Parent = keine Kette = dein DNSKEY wird ignoriert**, auch wenn er perfekt gueltig ist. Das ist die mit Abstand haeufigste Ursache fuer ein "kaputtes DNSSEC"-Urteil: jemand hat DNSSEC beim DNS-Host eingeschaltet, aber den DS nie in den Registrar eingefuegt.

Wie greifen Angreifer eine Domain ohne DNSSEC an?

**Zwei klassische Angriffe.** (1) **Cache-Poisoning**: ein Angreifer schiebt eine gefaelschte Antwort schneller zum Resolver als die legitime und injiziert so eine falsche IP fuer z. B. deine Bank. Ohne DNSSEC kann der Resolver die Antworten nicht unterscheiden. Dan Kaminskys Offenlegung 2008 machte das im Internet-Massstab praktikabel. (2) **On-Path-DNS-Spoofing**: jeder, der DNS-Traffic abfangen kann (boeses WLAN, ISP, Nationalstaat), kann seine eigene Antwort einschieben. DNSSEC laesst beide Angriffe fail-closed werden: die Signatur verifiziert nicht, der Resolver liefert SERVFAIL, keine IP. Der Angreifer kann die Domain dosen, aber sie nicht imitieren.

Root und .com sind signiert, warum sind so wenige Domains geschuetzt?

Weil **das Signieren des Parents notwendig, aber nicht hinreichend ist**. Signierte Root und `.com` heisst nur, dass sie **fuer deinen DS-Record buergen koennen**, wenn du einen veroeffentlichst. Wenn deine Domain selbst keinen DNSKEY und keinen passenden DS veroeffentlicht, endet die Kette bei `.com` und deine Records reisen die letzte Strecke **ungeschuetzt**. Rund 95 % der `.com`-Domains sind heute genau in diesem Zustand: die Autobahn bis zu deiner Ausfahrt ist signiert, die Abfahrt nicht.

Verlangsamt DNSSEC die DNS-Aufloesung?

**Ein bisschen, nicht genug, um Nutzer zu stoeren.** Ein validierender Resolver macht zusaetzliche Anfragen (fuer DNSKEY- und RRSIG-Records) und ein bisschen Signatur-Mathe. Im Cold-Cache sind das **20 bis 80 ms**. Im Warm-Cache praktisch null. Die Response-Pakete sind groesser (Signaturen sind dick), was historisch Probleme mit alten Middleboxes machte, die DNS ueber 512 Byte verwarfen, aber das heutige **EDNS0** und DNS over TCP / TLS / HTTPS handhabt das problemlos. Moderne Algorithmen wie **ECDSAP256SHA256** und **ED25519** liefern Signaturen, die **5 bis 10x kleiner** als RSA2048 sind, was die meisten Groessen-Beschwerden behoben hat.

RSASHA256 vs ECDSAP256SHA256 vs ED25519: welcher Algorithmus?

**ECDSAP256SHA256 (Algorithmus 13)** ist der aktuelle Default fuer neue Deployments: kleine Keys (256 Bit), kleine Signaturen, universelle Resolver-Unterstuetzung. **ED25519 (Algorithmus 15)** ist noch kleiner und schneller, aber eine winzige Minderheit alter Resolver faellt dafuer noch in "insecure" zurueck (behandelt die Zone als unsigniert), daher nur eine gute Wahl, wenn du keine Legacy-Kompatibilitaet brauchst. **RSASHA256 (Algorithmus 8)** dominiert noch immer den realen Traffic (die `.com`-Zone signiert damit), ist felsenfest, aber Signaturen sind 5 bis 10x groesser. Vermeide **RSASHA1 (5, 7)** und **RSAMD5 (1)**: sie sind deprecated und Resolver beginnen, sie rundweg abzulehnen.

Mein Validator sagt "Broken Chain". Wie troubleshoote ich?

**Fuenf Punkte, in Reihenfolge.** (1) **Passt der DS-keyTag beim Parent zu einem KSK-keyTag beim Child?** Eine Diskrepanz erklaert 80 % der Ausfaelle, meist durch eine KSK-Rotation ohne Registrar-Update. (2) **Sind die Signaturen (RRSIG) abgelaufen?** Signaturen haben ein Gueltigkeitsfenster, typisch 7 bis 30 Tage. Wenn dein Signer ausfaellt, laufen Signaturen ab und die Kette bricht um Mitternacht. (3) **Hast du kuerzlich den Algorithmus rotiert?** Der Wechsel von RSA zu ECDSA erfordert Doppelsignieren fuer ein TTL-Fenster. (4) **Pruefe das Algorithmus-Feld im DS-Record beim Parent** gegen das, womit deine Zone tatsaechlich signiert. (5) Nutze **dnsviz.net** fuer einen tieferen Trace, sobald dieses Tool dir die kaputte Ebene gezeigt hat.

DNSSEC Validator - kostenlos

Was dieses Tool leistet

Dieses Tool laeuft die DNSSEC-Vertrauenskette fuer eine beliebige Domain ab und zeigt dir Ebene fuer Ebene, ob sie korrekt signiert ist. Du bekommst die Root (.), die TLD (z. B. `.com`) und deine Domain, jeweils mit ihren DNSKEY-Records, dem DS-Record bei der Parent-Zone, dem Algorithmus (RSASHA256, ECDSAP256, ED25519, ...) und dem Key-Tag.

Die eigentliche kryptografische Pruefung uebernimmt Cloudflares validierender Resolver 1.1.1.1: wir lassen ihn die Signaturen pruefen und lesen sein AD-Flag (Authenticated Data) zurueck. Gruen bedeutet signiert und validiert, gelb bedeutet, dass diese Ebene schlicht kein DNSSEC nutzt, rot bedeutet, dass Signaturen oder DS-Records nicht passen und die Kette gebrochen ist.

So benutzt du es

Domain eingeben wie `cloudflare.com` (kein `https://`, kein Pfad).
Validate DNSSEC klicken. Wir fragen DoH nach DNSKEY auf jeder Ebene und nach DS beim Parent.
Die Chain-Karte von oben nach unten lesen: Root, dann TLD, dann deine Domain. Jede Karte ist farbcodiert.
Gruen = signiert und authentifiziert. Gelb = kein DNSSEC auf dieser Ebene (kein Fehler, nur ungeschuetzt). Rot = gebrochene Kette, Clients koennen die Domain ablehnen.
Die DS/DNSKEY-Tabellen pruefen: die Key-Tags muessen zwischen einem Child-DNSKEY und dem Parent-DS uebereinstimmen. Algorithmus und Digest-Typ verraten, welche Krypto im Einsatz ist.
Beispiel-Chips ausprobieren: cloudflare.com, paypal.com, ietf.org sind voll signiert. example.com ist signiert, aber die Subzone nicht, daher landet sie in "partial".

Wann das nuetzlich ist

Sechs Situationen, in denen ein DNSSEC-Chain-Validator besser ist als rohes `dig +trace +dnssec`:

Audit fuer eine gerade aktivierte DNSSEC-Domain. Du hast den Schalter beim Registrar umgelegt, den DS-Record am Parent eingefuegt und musst jetzt bestaetigen, dass beide Seiten zusammenpassen. Die Chain-Visualisierung macht eine Key-Tag-Diskrepanz in Sekunden sichtbar.
"DNSSEC validation failure"-Fehler debuggen. Endnutzer sehen ploetzlich nur auf validierenden Resolvern (Cloudflare, Google, Quad9) ein `SERVFAIL`. Die rote Karte lokalisiert die kaputte Ebene und die Meldung erklaert den Grund.
Pre-Launch-Check fuer Banking, Behoerden und jede Hochvertrauens-Domain. Voll signiertes DNSSEC blockt eine ganze Angriffsklasse (Cache-Poisoning, On-Path-DNS-Spoofing). Bestaetige es vor dem Live-Gang.
Zwei Domains nebeneinander vergleichen. Lass `deinebank.de` gegen einen Wettbewerber laufen und sieh, wer DNSSEC tatsaechlich ausrollt.
Eine Parent-Zone-Rotation verifizieren. Du hast den KSK beim Registry gerollt, einen neuen DS eingereicht und willst bestaetigen, dass die Propagation fertig ist und das AD-Flag wieder true ist.
DNSSEC lehren. Die drei Ebenen (Root, TLD, SLD) plus die Records pro Ebene sind die sauberste Art, Delegation und Vertrauen jemandem zu erklaeren, der das noch nie gesehen hat.

Fragen und Antworten

DNSSEC ist eine Reihe von Erweiterungen, die kryptografische Signaturen zu DNS-Antworten hinzufuegt. Eine normale DNS-Anfrage gibt "example.com liegt auf 1.2.3.4" zurueck, ohne dass man beweisen koennte, dass das wirklich vom echten DNS-Server von example.com kommt. DNSSEC haengt eine Signatur an diese Antwort plus eine Vertrauenskette bis hinauf zur Root-Zone, damit ein validierender Resolver bestaetigen kann, dass die IP vom legitimen Eigentuemer veroeffentlicht wurde und niemand sie unterwegs manipuliert hat. Es ist ein Schutz gegen Cache-Poisoning und On-Path-DNS-Spoofing, nicht gegen Site-Uebernahme oder gestohlene Credentials.

Was dieses Tool leistet

So benutzt du es

Domain eingeben wie `cloudflare.com` (kein `https://`, kein Pfad).

Validate DNSSEC klicken. Wir fragen DoH nach DNSKEY auf jeder Ebene und nach DS beim Parent.

Die Chain-Karte von oben nach unten lesen: Root, dann TLD, dann deine Domain. Jede Karte ist farbcodiert.

Gruen = signiert und authentifiziert. Gelb = kein DNSSEC auf dieser Ebene (kein Fehler, nur ungeschuetzt). Rot = gebrochene Kette, Clients koennen die Domain ablehnen.

Die DS/DNSKEY-Tabellen pruefen: die Key-Tags muessen zwischen einem Child-DNSKEY und dem Parent-DS uebereinstimmen. Algorithmus und Digest-Typ verraten, welche Krypto im Einsatz ist.

Beispiel-Chips ausprobieren: cloudflare.com, paypal.com, ietf.org sind voll signiert. example.com ist signiert, aber die Subzone nicht, daher landet sie in "partial".

Wann das nuetzlich ist

Sechs Situationen, in denen ein DNSSEC-Chain-Validator besser ist als rohes `dig +trace +dnssec`:

Audit fuer eine gerade aktivierte DNSSEC-Domain. Du hast den Schalter beim Registrar umgelegt, den DS-Record am Parent eingefuegt und musst jetzt bestaetigen, dass beide Seiten zusammenpassen. Die Chain-Visualisierung macht eine Key-Tag-Diskrepanz in Sekunden sichtbar.
"DNSSEC validation failure"-Fehler debuggen. Endnutzer sehen ploetzlich nur auf validierenden Resolvern (Cloudflare, Google, Quad9) ein `SERVFAIL`. Die rote Karte lokalisiert die kaputte Ebene und die Meldung erklaert den Grund.
Pre-Launch-Check fuer Banking, Behoerden und jede Hochvertrauens-Domain. Voll signiertes DNSSEC blockt eine ganze Angriffsklasse (Cache-Poisoning, On-Path-DNS-Spoofing). Bestaetige es vor dem Live-Gang.
Zwei Domains nebeneinander vergleichen. Lass `deinebank.de` gegen einen Wettbewerber laufen und sieh, wer DNSSEC tatsaechlich ausrollt.
Eine Parent-Zone-Rotation verifizieren. Du hast den KSK beim Registry gerollt, einen neuen DS eingereicht und willst bestaetigen, dass die Propagation fertig ist und das AD-Flag wieder true ist.
DNSSEC lehren. Die drei Ebenen (Root, TLD, SLD) plus die Records pro Ebene sind die sauberste Art, Delegation und Vertrauen jemandem zu erklaeren, der das noch nie gesehen hat.

Fragen und Antworten

DNSSEC Validator

Was dieses Tool leistet

So benutzt du es

Wann das nuetzlich ist

Fragen und Antworten

Passende Tools

DNS-Lookup

Reverse-DNS-Suche (PTR-Eintrag)

E-Mail DNS Checker

WHOIS-Lookup

DKIM-Schlüsselpaar-Generator

DNSSEC Validator

Was dieses Tool leistet

So benutzt du es

Wann das nuetzlich ist

Fragen und Antworten

Passende Tools

DNS-Lookup

Reverse-DNS-Suche (PTR-Eintrag)

E-Mail DNS Checker

WHOIS-Lookup

DKIM-Schlüsselpaar-Generator