Welches Problem löst DNSSEC?
DNS ist von Haus aus unverschlüsselt und unauthentifiziert. Wer einen DNS-Server zwischen Browser und Ziel kompromittiert (oder ein Resolver-Cache vergiftet), kann beliebige IP-Adressen für jede Domain ausliefern — der Browser landet auf einer Fake-Seite, die HTTPS-Zertifikat hin oder her, der Angreifer kann Mails abfangen, Anmeldedaten klauen oder Schadcode ausliefern. DNS-Cache-Poisoning ist seit den frühen 2000ern dokumentiert, der Kaminsky-Angriff 2008 hat das Thema ins Rampenlicht gerückt.
DNSSEC (DNS Security Extensions) löst das per kryptografischer Signatur: Jede DNS-Antwort wird vom autoritativen Server signiert, der Resolver prüft die Signatur, und Manipulationen unterwegs fallen sofort auf. Eine Vertrauenskette von der Root-Zone (.) bis zu deiner Domain garantiert die Echtheit.
Schlüssel-Hierarchie
DNSSEC nutzt zwei Schlüsselpaare:
- ZSK (Zone Signing Key) — signiert die einzelnen Records (A, MX, TXT, ...). Wird häufig rotiert (alle paar Wochen bis Monate), kürzer (1024-2048 Bit RSA oder ECDSA P-256).
- KSK (Key Signing Key) — signiert nur den ZSK. Wird selten rotiert (1-2 Jahre), länger (2048-4096 Bit). Die KSK-Signatur ist es, die die Vertrauenskette zur Eltern-Zone (z. B.
.com) ankert.
Die Trennung erlaubt es, den ZSK zu rotieren, ohne jedes Mal den DS-Record bei der Eltern-Zone (Registrar) zu aktualisieren — das wäre extrem aufwändig.
Die Vertrauenskette
DNSSEC funktioniert von oben nach unten:
- Die Root-Zone hat ihren KSK in jedem Resolver hinterlegt — der Vertrauensanker.
- Die Root signiert den DS-Record (Hash des KSK) der TLD-Zonen (.com, .de, .at, ...).
- Die TLD signiert den DS-Record deiner Domain.
- Deine Domain signiert ihre eigenen DNS-Records.
Bricht die Kette an einer Stelle (z. B. weil deine Domain DNSSEC hat, aber der DS-Record beim Registrar nicht eingetragen ist), dann ist DNSSEC für deine Domain unwirksam — manche Resolver akzeptieren den Eintrag dann gar nicht mehr. Das nennt sich SERVFAIL und legt im Worst Case deine ganze Domain lahm.
DNSSEC aktivieren
Drei Schritte, in dieser Reihenfolge:
- DNS-Hoster: Aktiviere DNSSEC im Hoster-Panel. Cloudflare, Google Cloud DNS, AWS Route 53 und die meisten großen Anbieter haben einen Ein-Klick-Schalter. Der Hoster generiert KSK + ZSK und signiert deine Records.
- DS-Record beim Registrar: Der Hoster zeigt dir einen DS-Record (digestType, keyTag, algorithm, digest). Diesen trägst du beim Domain-Registrar (z. B. NIC.AT, GoDaddy, Namecheap) ein. Damit wird die Vertrauenskette geschlossen.
- Validieren: Über dnsviz.net oder dnssec-debugger.verisignlabs.com prüfen — die Tools zeigen die komplette Vertrauenskette grafisch und decken Lücken auf.
Häufige Fehler
- DS-Record nicht beim Registrar eingetragen: Domain ist plötzlich unerreichbar für DNSSEC-validierende Resolver — sieht für Nutzer aus wie ein Totalausfall.
- Zone- oder Schlüsselrotation vergessen: Abgelaufene Signaturen führen zu SERVFAIL. Automatisierte Rotation ist Pflicht — bei Cloudflare/Route 53 standardmäßig aktiviert.
- Hoster-Wechsel ohne Rollover: Beim Wechsel des DNS-Hosters muss der KSK übertragen oder ein Schlüssel-Rollover durchgeführt werden — sonst Vertrauenskette gebrochen.
- Schwache Algorithmen: RSA-SHA1 ist als unsicher abgekündigt. Empfohlen: RSA-SHA256 (Algorithmus 8) oder ECDSA-P256 (Algorithmus 13).
DNSSEC und DANE
Eine wichtige DNSSEC-Anwendung ist DANE (DNS-based Authentication of Named Entities): Du kannst dann selbst im DNS festlegen, welche TLS-Zertifikate für deine Domain gültig sind — unabhängig von der CA-Vertrauenskette. Macht DNSSEC erst zur vollständigen Vertrauensgrundlage. Wird heute primär für Mail-Server (Postfix, Exim) eingesetzt, der Browser-Support für DANE-via-HTTPS ist begrenzt.