Was ist DNSSEC? Funktionsweise und sicheres Aktivieren

Das klassische DNS hat keine Möglichkeit zu beweisen, dass eine Antwort echt ist. Ein Resolver schickt eine Frage per UDP und glaubt der ersten plausiblen Antwort. Wer eine solche Antwort einschleusen oder verändern kann (durch Cache Poisoning, ein kompromittiertes Netz oder einen manipulierten Resolver), kann Nutzer auf einen anderen Server schicken. DNSSEC, die DNS Security Extensions, schließt diese Lücke, indem es DNS-Daten mit digitalen Signaturen versieht. Ein Resolver kann so prüfen, ob eine Antwort wirklich vom Inhaber der Zone stammt und unterwegs nicht verändert wurde.

Auf den meisten Domains lohnt es sich, DNSSEC einzuschalten. Zugleich ist es eine der wenigen DNS-Funktionen, die eine Domain bei unachtsamem Umgang vollständig vom Netz nehmen können. Beide Seiten kommen im Folgenden zur Sprache.

Was DNSSEC leistet und was nicht

Es bietet:

Herkunftsnachweis und Integrität: Die Records wurden von demjenigen veröffentlicht, der die Schlüssel der Zone hält, und wurden nicht verändert.
Authentifizierte Nichtexistenz: einen signierten Nachweis, dass ein Name oder Record-Typ nicht existiert, damit auch „diese Domain gibt es nicht“ nicht gefälscht werden kann.

Es bietet nicht:

Verschlüsselung. Anfragen und Antworten bleiben für jeden auf dem Weg lesbar. Für die Vertraulichkeit sind DNS over TLS oder DNS over HTTPS zuständig; sie schützen die Strecke zwischen Client und Resolver und ergänzen DNSSEC, statt es zu ersetzen.
Schutz vor einem kompromittierten DNS-Konto. Kann ein Angreifer Ihre Zone bearbeiten, signiert der Anbieter dessen Records ebenso bereitwillig.
Schutz der Web-Sitzung. Dafür ist TLS da. DNSSEC stellt sicher, dass Sie die richtige Adresse erreichen; das Zertifikat beweist, dass der Server der ist, für den er sich ausgibt.
Irgendetwas für Nutzer, deren Resolver nicht validiert. Viele große öffentliche Resolver und Provider validieren; nicht alle tun es.

Wie es funktioniert

DNSSEC fügt eine Handvoll Record-Typen hinzu:

Record	Wo	Zweck
`RRSIG`	neben jedem Record-Set	die Signatur über dieses Set (etwa über alle `A`-Records von `www`)
`DNSKEY`	Zonen-Apex	die öffentlichen Schlüssel der Zone
`DS`	in der Elternzone	ein Hash des Schlüssels der Kindzone; das Glied in der Kette
`NSEC` / `NSEC3`	in der ganzen Zone	beweist, welche Namen und Typen nicht existieren
`CDS` / `CDNSKEY`	Zonen-Apex	erlaubt der Kindzone, DS-Änderungen automatisch an die Elternzone zu signalisieren

Die meisten Zonen verwenden zwei Schlüssel. Der Zone-Signing Key (ZSK) signiert die Records. Der Key-Signing Key (KSK) signiert nur das DNSKEY-Set, und der Hash des KSK ist es, der als DS-Record in der Elternzone veröffentlicht wird. Diese Aufteilung erlaubt es, den ZSK häufig zu wechseln, ohne die Elternzone einzubeziehen. Manche Anbieter verwenden stattdessen einen einzigen kombinierten Schlüssel (CSK); das Prinzip ist dasselbe.

Die Vertrauenskette

Ein validierender Resolver vertraut von Haus aus genau einer Sache: dem öffentlichen Schlüssel der Root-Zone, die seit 2010 signiert ist. Alles Weitere wird daraus abgeleitet:

root DNSKEY  (trust anchor, built into the resolver)
   └─ signs  DS for "com"          → matches com's DNSKEY
         └─ signs  DS for "example.com"   → matches example.com's DNSKEY
               └─ signs  www.example.com A 192.0.2.10

Auf jeder Ebene bürgt die Elternzone für den Schlüssel der Kindzone, indem sie einen DS-Record veröffentlicht und signiert. Lässt sich jedes Glied prüfen, ist die Antwort secure, und der Resolver setzt das Flag ad (authenticated data). Hat eine Zone keinen DS in ihrer Elternzone, ist sie schlicht insecure: Sie wird wie gewöhnliches, unsigniertes DNS behandelt, ohne Schaden. Existiert aber ein DS, und die Signaturen lassen sich nicht prüfen (falscher Schlüssel, abgelaufene Signatur, fehlendes RRSIG), lautet das Ergebnis bogus, und der Resolver liefert SERVFAIL. Für Nutzer hinter validierenden Resolvern hört die Domain auf zu existieren.

Dieser letzte Fall ist das gesamte Betriebsrisiko von DNSSEC, und er erklärt die Regeln, die folgen.

Ein Detail, das man kennen sollte: Signaturen laufen ab. Jedes RRSIG hat einen Beginn und ein Ablaufdatum. Der Signierer muss regelmäßig neu signieren. Verwaltete DNS-Anbieter tun das automatisch; ein selbst betriebener Signierer, der stehen bleibt, erzeugt ein oder zwei Wochen später einen Ausfall.

DNSSEC mit dig prüfen

Gibt es einen DS-Record in der Elternzone (soll die Domain also signiert sein)?

$ dig +short example.com DS
31589 13 2 3490A6806D47F17A34C29E2CE80E8A999FFBE4BE...

Die Felder sind Key Tag, Algorithmus (13 = ECDSA P-256 mit SHA-256, die übliche moderne Wahl), Digest-Typ (2 = SHA-256) und der Digest.

Veröffentlicht die Zone Schlüssel und Signaturen?

$ dig +dnssec +multi example.com DNSKEY
$ dig +dnssec www.example.com A
www.example.com.  3600 IN A      192.0.2.10
www.example.com.  3600 IN RRSIG  A 13 3 3600 20261004000000 20260920000000 31589 example.com. oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr...

Validiert sie? Fragen Sie einen validierenden Resolver und sehen Sie sich die Flags an:

$ dig www.example.com A @1.1.1.1 | grep flags
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, ...

ad bedeutet, dass der Resolver die Antwort validiert hat. Um einen DNSSEC-Fehler von anderen Fehlern zu unterscheiden, wiederholen Sie eine fehlschlagende Abfrage mit abgeschalteter Prüfung:

$ dig www.example.com A @1.1.1.1          # status: SERVFAIL
$ dig www.example.com A @1.1.1.1 +cd      # status: NOERROR, answer present

Normalerweise SERVFAIL, mit +cd aber eine Antwort: Das ist das Kennzeichen einer kaputten DNSSEC-Konfiguration. delv www.example.com (bei BIND enthalten) validiert lokal und erklärt, wo die Kette reißt.

DNSSEC aktivieren

Drei Beteiligte müssen es unterstützen: die TLD (fast alle tun es), der DNS-Anbieter (signiert die Zone) und der Registrar (gibt den DS an die Registry weiter).

Schalten Sie das Signieren beim DNS-Anbieter ein. Er erzeugt Schlüssel und beginnt, DNSKEY- und RRSIG-Records zu veröffentlichen. An diesem Punkt kann nichts kaputtgehen, denn ohne DS ist die Zone weiterhin „insecure“.
Prüfen Sie die signierte Zone: dig +dnssec gegen die Nameserver des Anbieters sollte RRSIGs für Ihre Records zeigen. Warten Sie mindestens eine TTL, damit die Caches die signierten Daten halten.
Veröffentlichen Sie den DS-Record.
- Sind Registrar und DNS-Anbieter dasselbe Unternehmen, ist das meist ein Klick oder geschieht automatisch.
- Andernfalls kopieren Sie die DS-Werte (Key Tag, Algorithmus, Digest-Typ, Digest) vom DNS-Anbieter in das DNSSEC-Formular des Registrars. Manche Registrare fragen stattdessen nach dem DNSKEY und berechnen den DS selbst. Kopieren Sie sorgfältig; ein falsches Zeichen macht die Domain bogus.
- Manche Registries und Registrare fragen CDS/CDNSKEY-Records ab und legen den DS selbst an oder aktualisieren ihn. Wenn Ihrer das tut, bevorzugen Sie diesen Weg.
Prüfen Sie die Kette mit den Befehlen oben und einem externen Validator, von mehr als einem Resolver aus.
Überwachen Sie. Ablaufende Signaturen und nicht passende DS-Records kündigen sich nicht an, bevor sie fehlschlagen.

Die gefährlichen Momente

Wechsel des DNS-Anbieters oder der Nameserver. Der DS in der Elternzone zeigt auf den Schlüssel des alten Anbieters. Wer die Nameserver umstellt, ohne sich darum zu kümmern, macht die Domain bogus. Entweder entfernen Sie den DS, warten dessen TTL ab (oft ein Tag), ziehen um und schalten DNSSEC danach wieder ein; oder Sie führen eine abgestimmte Multi-Signer-Migration durch. Die vollständige Abfolge steht in Nameserver ohne Ausfall wechseln.
DNSSEC abschalten. Die Reihenfolge ist die Umkehrung des Einschaltens: zuerst den DS entfernen, dessen TTL abwarten und erst dann das Signieren beenden. Das Signieren abzuschalten, während der DS noch veröffentlicht ist, ist der klassische selbst verursachte Ausfall.
Transfer der Domain zu einem anderen Registrar, wenn der alte Registrar auch das DNS hostet. Siehe Domain umziehen.
Schlüsselwechsel bei selbst betriebenen Signierern. Ein KSK-Rollover bezieht die Elternzone ein und muss dem Muster veröffentlichen–warten–umschalten–warten–entfernen folgen. Bei einem verwalteten Anbieter ist das dessen Aufgabe.

Bedenken Sie, dass das Absenken Ihrer eigenen TTLs bei einer gerissenen Kette nicht hilft: Die TTL des DS-Records legt die Elternzone fest.

Häufige Fehler

Den DS mit einer falschen Nummer für Algorithmus oder Digest-Typ einfügen.
Nach dem Wechsel des DNS-Anbieters einen alten DS stehen lassen.
Das Signieren abschalten, bevor der DS entfernt ist.
Ein selbst betriebener Signierer, dessen Cron-Job gestorben ist; alles funktioniert, bis die Signaturen ablaufen.
NSEC wählen, ohne zu wissen, dass es das Aufzählen der Namen der Zone erlaubt („Zone Walking“). NSEC3 oder die Techniken für minimale Antworten, die große Anbieter einsetzen, erschweren das.
Veraltete Algorithmen (RSA/SHA-1) verwenden, obwohl ECDSA P-256 kleinere Antworten liefert und von aktuellen Validatoren durchgehend unterstützt wird.
Annehmen, DNSSEC sei in Ordnung, weil die Website bei Ihnen funktioniert. Ihr Resolver validiert womöglich nicht.

Lohnt es sich?

Für die meisten Domains bei einem verwalteten DNS-Anbieter: ja. Es kostet nichts, es sind ein oder zwei Klicks, und es beseitigt eine Klasse von Angriffen, die für Sie sonst unsichtbar wäre. Der Preis ist betriebliche Disziplin in den wenigen oben genannten Momenten. Wenn Ihr Team den DNS-Anbieter beiläufig wechselt und niemand für das Registrar-Konto zuständig ist, bringen Sie das zuerst in Ordnung.

Mit OrbitProbe prüfen

Die DNS-Abfrage von OrbitProbe zeigt die Records, die öffentliche Resolver für Ihre Domain zurückgeben, mit ihren TTLs. Eine signierte Domain, die von validierenden Resolvern plötzlich gar keine Records mehr liefert, während die Oberfläche Ihres Anbieters normal aussieht, ist das Muster, das Sie erkennen sollten: Gehen Sie direkt zum +cd-Test oben. Die Sicht der Registry auf die Delegation, einschließlich der Angabe, ob sie als signiert markiert ist, erscheint in den Registrierungsdaten, wie in WHOIS und RDAP beschrieben.