DNSSEC in einfacher Sprache

Modul 8: Sicherheit und Problembehebung · Lesezeit: 11 Minuten

Lernziel: Nach dieser Lektion können Sie in einfacher Sprache erklären, was DNSSEC schützt, wie die Vertrauenskette funktioniert und warum es bei einem Umzug schiefgehen kann.

Kernbegriffe: DNSSEC, Signatur (RRSIG), Schlüssel (DNSKEY), DS-Eintrag, Vertrauenskette, validierender Resolver, SERVFAIL

Das Problem: Woher wissen Sie, dass eine Antwort echt ist?

In Modul 1 haben Sie gesehen, dass ein Resolver eine Reihe von Anfragen stellt: an die Root, an den TLD-Server und an den autoritativen Nameserver. Die zurückkommende Antwort wird geglaubt und im Cache gespeichert. Das gewöhnliche DNS prüft aber nicht, ob diese Antwort wirklich vom richtigen Nameserver stammt. Ein Angreifer, der eine falsche Antwort schickt, bevor die echte Antwort ankommt, kann einen Resolver glauben lassen, dass example.com unter 203.0.113.66 statt unter 192.0.2.10 erreichbar ist. Das nennt man Cache Poisoning: Der Cache ist „vergiftet“, und jeder, der diesen Resolver verwendet, landet auf dem falschen Server.

DNSSEC (DNS Security Extensions) löst dieses Problem, indem Antworten signiert werden. Der Resolver kann dann prüfen, ob eine Antwort echt ist und unterwegs nicht verändert wurde.

Was DNSSEC tut und was nicht

Das ist das Wichtigste, was Sie sich merken sollten:

Eine Signatur funktioniert wie ein Siegel auf einem Briefumschlag: Jeder kann den Brief lesen, aber Sie sehen sofort, ob jemand ihn geöffnet hat.

Die drei Bestandteile

DNSSEC fügt einige Recordtypen hinzu. Sie müssen diese nicht selbst anlegen (das übernimmt Ihr DNS-Verwalter oder Ihr Panel), aber Sie werden ihnen begegnen:

• DNSKEY: der öffentliche Schlüssel der Zone. Damit kann jeder die Signaturen prüfen.
• RRSIG: die Signatur zu einer Gruppe von Einträgen. Jede A-, MX- oder TXT-Antwort erhält eine RRSIG. Eine Signatur hat ein Start- und ein Enddatum: Die Zone muss also regelmässig neu signiert werden.
• DS (Delegation Signer): ein kurzer „Fingerabdruck“ des Schlüssels Ihrer Zone. Dieser steht nicht in Ihrer eigenen Zone, sondern beim Elternteil: für example.com also bei der Registry von .com (Verisign), für eine .nl-Domain bei SIDN (der Registry von .nl in den Niederlanden).

So sieht eine signierte Antwort aus (gekürzt):

$ dig example.com A +dnssec +noall +answer
example.com.  3600  IN  A      192.0.2.10
example.com.  3600  IN  RRSIG  A 13 2 3600 20261119000000 20261029000000 30794 example.com. s7yJ5o...

In der RRSIG sehen Sie unter anderem das Algorithmus (13 = ECDSA P-256 mit SHA-256), das Enddatum (19. November 2026), das Startdatum und die Schlüsselnummer (30794).

Die Vertrauenskette

Warum steht die DS beim Elternteil? Weil ein Schlüssel in Ihrer eigenen Zone nichts beweist: Ein Angreifer könnte ebenfalls einen eigenen Schlüssel mitschicken. Deshalb verläuft die Prüfung von oben nach unten:

1. Der Resolver vertraut dem Schlüssel der Root. Dieser ist in jedem validierenden Resolver fest eingebaut (der Trust Anchor).
2. Die Root hat eine DS für .com, signiert mit dem Root-Schlüssel. So weiss der Resolver, welchen Schlüssel .com haben sollte.
3. Die .com-Zone hat eine DS für example.com, signiert mit dem .com-Schlüssel.
4. Die Zone example.com hat einen DNSKEY, der zu dieser DS passt, und damit lassen sich alle RRSIGs prüfen.

Jedes Glied beweist das nächste. Bricht ein Glied, ist die gesamte Kette unzuverlässig.

Ein validierender Resolver (die meisten grossen öffentlichen Resolver und zunehmend auch Provider) prüft diese Kette. Stimmt sie, erhalten Sie die Antwort. Stimmt sie nicht, liefert der Resolver keine Antwort, sondern den Fehlerstatus SERVFAIL. Für den Besucher sieht es dann so aus, als würde die Website gar nicht existieren, während Ihre Einträge eigentlich in Ordnung sein könnten.

Das können Sie selbst sehen, anhand einer Domain, die absichtlich kaputt gemacht wurde:

$ dig dnssec-failed.org A @1.1.1.1
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL
; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for dnssec-failed.org.)

Mit +cd („checking disabled“) bitten Sie den Resolver, die Prüfung zu überspringen. Erhalten Sie dann doch eine Antwort, wissen Sie sicher, dass es an DNSSEC liegt:

$ dig +cd dnssec-failed.org A @1.1.1.1 +short
96.99.227.255

Eine Domain ohne DNSSEC (keine DS beim Elternteil) liefert kein SERVFAIL: Sie ist dann einfach nicht signiert und wird als „ungesichert“ durchgelassen.

Wo es schiefgeht: Umzug und Schlüsselwechsel

DNSSEC selbst geht fast nie kaputt. Es geht schief, wenn die DS bei der Registry nicht mehr zum Schlüssel in der Zone passt. Das passiert vor allem:

• Bei einem Umzug der Nameserver oder des DNS-Anbieters. Der neue Anbieter signiert mit einem eigenen Schlüssel, aber bei der Registry steht noch die DS des alten Anbieters. Folge: SERVFAIL für jeden mit einem validierenden Resolver. Das ist der klassische Fehler nach einem Umzug.
• Bei einem Schlüsselwechsel, bei dem die neue DS nicht (rechtzeitig) an die Registry übermittelt wurde.
• Wenn die Signaturen ablaufen, weil die Zone nicht mehr neu signiert wird.

Die sichere Reihenfolge bei einem Umzug lautet daher:

1. Entfernen Sie die DS bei der Registry (oder lassen Sie sich vom neuen Anbieter eine DS liefern, die Sie hinzufügen).
2. Warten Sie, bis die TTL der alten DS abgelaufen ist.
3. Wechseln Sie die Nameserver.
4. Aktivieren Sie DNSSEC beim neuen Anbieter und lassen Sie die neue DS bei der Registry eintragen.

Viele Registrare und Panels regeln das heutzutage automatisch, solange Domain und DNS beim selben Anbieter liegen. Liegen sie bei unterschiedlichen Anbietern, müssen Sie die DS selbst übertragen.

Selbst überprüfen: DNSViz, Zonemaster und internet.nl

Sie müssen die Kette nicht mit dig selbst nachverfolgen. Es gibt kostenlose Tools, die das für Sie erledigen und das Ergebnis anzeigen.

DNSViz (https://dnsviz.net/) zeichnet die gesamte Kette als Grafik. So verwenden Sie es:

1. Geben Sie auf der Startseite den Domainnamen in das Suchfeld ein (nur den Namen, ohne https:// und ohne www) und klicken Sie auf Go.
2. DNSViz zeigt die letzte Analyse an. Ist diese veraltet, oder haben Sie gerade etwas geändert, klicken Sie auf Update now. Nach wenigen Sekunden sehen Sie die Grafik.
3. Lesen Sie die Grafik von oben nach unten: oben die Root (.), darunter die TLD (zum Beispiel nl), unten Ihre Domain. Jede Zone ist ein Rahmen.

Was Sie in der Grafik sehen:

Die Kette folgen Sie so: Die DS (beim Elternteil) zeigt auf den DNSKEY (in Ihrer Zone), und dieser DNSKEY setzt mit einer RRSIG seine Signatur unter die Einträge. Das ist genau die Kette aus dieser Lektion, nur grafisch dargestellt.

Die Farben zeigen an, ob alles stimmt:

• Blau: sicher (secure). Die Kette verläuft ununterbrochen von der Root bis zu diesem Bestandteil.
• Schwarz: nicht signiert (insecure). Es gibt keine DS, also gibt es nichts zu prüfen. Das ist kein Fehler, die Domain verwendet einfach kein DNSSEC.
• Rot: kaputt (bogus). Eine DS passt nicht zu einem Schlüssel, oder eine Signatur stimmt nicht. Ein validierender Resolver liefert dann SERVFAIL.
• Violett (bei einer Signatur): Die Signatur ist abgelaufen oder noch nicht gültig. Die Zone wird nicht mehr neu signiert.
• Gelb: eine Warnung, zum Beispiel ein Nameserver, der nicht richtig antwortet, oder ein Algorithmus, den das Tool nicht kennt.
• Grau und gepunktet: Es wird auf einen Schlüssel verwiesen, der nicht vorhanden ist. Sehen Sie einen gepunkteten DNSKEY unter einer DS, steht beim Elternteil noch eine DS eines alten Schlüssels: der klassische Fehler nach einem Umzug.

Neben einem Bestandteil kann ein kleines Dreieck (Warnung) oder ein rundes Fehlerzeichen stehen. Fahren Sie mit der Maus darüber, oder schauen Sie in die Liste unter der Grafik: Dort steht in Worten, was nicht stimmt.

Probieren Sie es einmal mit sidn.nl (alles blau) und mit dnssec-failed.org (rot, mit einem gepunkteten Schlüssel unter der DS).

Weitere Tools, die dasselbe aus einem anderen Blickwinkel betrachten:

• Zonemaster (https://zonemaster.net/): prüft Ihre gesamte Zone so, wie es eine Registry tut, auch DNSSEC. Das Ergebnis ist eine Liste mit Grün (gut), Orange (Warnung) und Rot (Fehler).
• internet.nl (https://internet.nl/): Der Website- und E-Mail-Test zeigt unter anderem, ob DNSSEC für Ihre Domain und Ihre Mailserver in Ordnung ist, mit grünen Häkchen oder roten Kreuzen.
• Verisign DNSSEC Debugger (https://dnssec-debugger.verisignlabs.com/): geht die Kette Schritt für Schritt durch und setzt bei jedem Schritt ein grünes Häkchen oder ein rotes Kreuz. Nützlich, wenn Sie nach einem konkreten Fehler suchen.

Verwenden Sie diese Tools nach jeder Änderung an DNSSEC, und vor allem vor und nach einem Umzug. Lassen Sie das Tool ruhig erneut analysieren: Auch diese Tools arbeiten mit Caches und TTLs.

In der Praxis: So sieht es in einem Panel aus

In Mein WebOké aktivieren Sie DNSSEC bei einer Domain unter DNSSEC/DANE; das Panel erzeugt die Schlüssel und übermittelt die DS an die Registry. In DirectAdmin und bei externen Anbietern wie Cloudflare heisst es meist „DNSSEC aktivieren“; Cloudflare zeigt Ihnen dann einen DS-Eintrag, den Sie selbst bei Ihrem Registrar eintragen müssen. Andere Panels funktionieren ähnlich: Es gibt immer einen Schritt „Schlüssel erzeugen“ (beim DNS-Anbieter) und einen Schritt „DS bei der Registry“ (beim Registrar).

Zusammenfassung

• DNSSEC signiert DNS-Antworten, damit ein Resolver prüfen kann, dass sie echt sind. Es verschlüsselt nichts.
• DNSKEY ist der Schlüssel, RRSIG die Signatur, DS der Fingerabdruck beim Elternteil.
• Die Prüfung verläuft wie eine Kette von der Root bis zu Ihrer Domain. Bricht ein Glied, liefert ein validierender Resolver SERVFAIL.
• Fast alle Probleme entstehen dadurch, dass die DS bei der Registry nicht mehr passt, oft nach einem Umzug.
• Mit dig +cd sehen Sie, ob ein Problem an DNSSEC liegt.
• DNSViz zeichnet die Kette: Blau ist sicher, Schwarz ist nicht signiert, Rot ist kaputt. Zonemaster, internet.nl und der Verisign DNSSEC Debugger sind gute zweite Meinungen.

Quiz

Aufgabe

Aufgabe Z8.1: DNSSEC sehen. Finden Sie heraus, welche von zwei Domains DNSSEC korrekt eingerichtet hat und welche absichtlich kaputt gemacht wurde: sidn.nl und dnssec-failed.org. Fragen Sie für beide den DS-Eintrag und den A-Eintrag über einen validierenden Resolver ab (zum Beispiel 1.1.1.1 oder 9.9.9.9), mit dig oder einem Online-Tool. Tragen Sie ein: die Schlüsselnummer (Key Tag, die erste Zahl) der DS von sidn.nl, und den Status, den Sie für dnssec-failed.org erhalten.

Aufgabe Z8.1b: DNSViz lesen. Analysieren Sie nlnetlabs.nl in DNSViz (https://dnsviz.net/, geben Sie den Namen ein und klicken Sie auf Go; klicken Sie auf Update now, wenn die Analyse veraltet ist). Lesen Sie die Grafik und tragen Sie ein: (1) den Status von nlnetlabs.nl (sicher, nicht signiert oder kaputt), (2) die Algorithmusnummer der DNSKEY-Einträge (steht in jedem Oval als alg=), (3) wie viele DNSKEY-Ovale in der Zone von nlnetlabs.nl stehen, (4) die Schlüsselnummer (id=) des grau gefüllten DNSKEY, auf den die DS zeigt, und (5) den Status, den DNSViz für dnssec-failed.org angibt. Die Prüfung fragt die gleichen Daten live ab.

Aufgabe O8.1: Drei DNSSEC-Demozonen beurteilen. Wir haben drei Demozonen bereitgestellt: signed-demo.dnspractice.com (korrekte Kette), broken-demo.dnspractice.com (absichtlich kaputt) und unsigned-demo.dnspractice.com (nicht signiert). Finden Sie für jede Zone heraus, ob sie sicher, kaputt oder nicht signiert ist, zum Beispiel mit DNSViz oder mit dig +dnssec (achten Sie auf das AD-Flag, und probieren Sie bei einem SERVFAIL auch +cd). Wählen Sie unten für jede Zone Ihre Antwort.

Weiterführende Informationen

Diese Artikel beschreiben die Schritte in den Panels von WebOké; bei anderen Anbietern heissen die Schaltflächen anders.

• WebOké Anleitung 5.8: DNSSEC und DANE
• Was ist DNSSEC?
• DNSSEC aktivieren
• Website oder E-Mail funktioniert nach einem Umzug oder einer DNS-Änderung nicht: Überprüfen Sie Ihre Domain