Schlagwort: DNSSEC (Seite 4 von 4)

DNSSEC (Domain Name System Security Extensions) schützt DNS-Antworten vor Fälschung. Ein anfragender Resolver kann damit prüfen, ob die gelieferten Zonendaten tatsächlich vom autorisierten Nameserver stammen und unterwegs nicht verändert wurden. DNSSEC wurde als Mittel gegen Cache Poisoning entwickelt — Serverauthentifizierung findet nicht statt.

Die Vertrauenskette

Was mich beim ersten Lesen zu DNSSEC durcheinandergebracht hat, war das Umherwerfen mit Begriffen: KSK, ZSK, DNSKEY, RRSIG, DS. Im Grunde ist es einfach:

Der KSK (Key Signing Key) hat eine Aufgabe: den ZSK unterschreiben. Der KSK wird als DS-Record in der übergeordneten Zone hinterlegt. Der ZSK (Zone Signing Key) hat auch nur eine Aufgabe: die eigentlichen Zonendaten unterschreiben.

Es beginnt bei der Root-Zone. Die Root-Server wissen, welche Nameserver für die TLDs zuständig sind. Die TLD-Server wissen, welche Nameserver für die einzelnen Domains zuständig sind. Jede Ebene signiert ihre Zone und veröffentlicht den DS-Record der Ebene darunter. So entsteht eine durchgehende Kette vom Root-KSK bis zu meiner Zone.

Will ein Angreifer dafür sorgen, dass www.kernel-error.org auf seinen Server zeigt, hat er zwei Möglichkeiten:

1. Er antwortet auf die Delegation-Anfrage mit seinem eigenen Nameserver.
2. Er antwortet mit gefälschter Absenderadresse schneller als der echte Server.

Mit DNSSEC kann der Resolver beide Angriffe erkennen — die gefälschte Antwort hat keine gültige Signatur.

DNSSEC in BIND aktivieren

Auf dem autoritativen Nameserver muss DNSSEC-Validierung aktiv sein. In modernen BIND-Versionen (ab 9.16) reicht im options-Block:

options {
    dnssec-validation auto;
};

auto bedeutet, dass BIND den eingebauten Root-Trust-Anchor nutzt und diesen bei KSK-Rollovers automatisch aktualisiert (RFC 5011). Der alte dnssec-enable yes wurde in BIND 9.18 entfernt — DNSSEC ist seitdem immer aktiv.

Zone signieren — der moderne Weg

Seit BIND 9.16 gibt es dnssec-policy. Damit übernimmt BIND die Schlüsselerzeugung, das Signieren und den Key-Rollover vollautomatisch:

zone "kernel-error.org" {
    type primary;
    file "kernel-error.org";
    dnssec-policy default;
    inline-signing yes;
};

Die default-Policy verwendet ECDSAP256SHA256 (Algorithmus 13) — schneller und sicherer als das früher übliche NSEC3RSASHA1 mit 4096-Bit-Schlüsseln. inline-signing yes bedeutet: BIND signiert die Zone im Speicher, die Zonendatei auf der Platte bleibt unsigniert und lässt sich wie gewohnt bearbeiten.

Zone manuell signieren

Wer mehr Kontrolle will oder eine ältere BIND-Version hat, kann die Schlüssel von Hand erzeugen. KSK erstellen:

$ dnssec-keygen -a ECDSAP256SHA256 -f KSK -n ZONE kernel-error.org
Kkernel-error.org.+013+12345

ZSK erstellen:

$ dnssec-keygen -a ECDSAP256SHA256 -n ZONE kernel-error.org
Kkernel-error.org.+013+67890

Die öffentlichen Teile (*.key) in die Zonendatei einbinden und signieren:

$ cat Kkernel-error.org.+013+*.key >> kernel-error.org

$ dnssec-signzone -S -K /pfad/zu/keys -o kernel-error.org kernel-error.org
Verifying the zone using the following algorithms: ECDSAP256SHA256.
Zone signing complete:
Algorithm: ECDSAP256SHA256: ZSKs: 1, KSKs: 1 active, 0 stand-by
kernel-error.org.signed

Dann BIND anweisen, die signierte Zonendatei zu laden. Nach jeder Änderung an der Zone muss neu signiert werden — oder man nutzt inline-signing, dann entfällt das.

DS-Record beim Registrar einreichen

Der öffentliche KSK muss als DS-Record in der übergeordneten Zone landen. Bei der DENIC (.de) und den meisten TLD-Registries gibt es dafür ein Webinterface beim Registrar. Man schickt den öffentlichen KSK hin, der Registrar erstellt daraus einen DS-Record und veröffentlicht ihn neben den NS-Records.

Ob der DS-Record gesetzt ist, lässt sich prüfen, indem man die TLD-Nameserver direkt fragt:

$ dig +short kernel-error.org DS @a0.org.afilias-nst.info
12345 13 2 A1B2C3D4...

Prüfen ob alles funktioniert

Mit dig +dnssec eine signierte Domain abfragen. Das ad-Flag (Authenticated Data) in der Antwort zeigt, dass die DNSSEC-Validierung erfolgreich war:

$ dig +dnssec kernel-error.org @8.8.8.8
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

Grafisch lässt sich die gesamte Vertrauenskette mit DNSviz darstellen — einfach die eigene Domain einsetzen:

• kernel-error.de
• kernel-error.org
• kernel-error.com

Stolpersteine

DNSSEC-Signaturen machen DNS-Antworten deutlich größer als die 512 Bytes, die klassisches DNS über UDP erlaubt. EDNS (RFC 6891) hebt dieses Limit auf. Das ist seit 1999 spezifiziert, aber manche Firewalls und Billig-Router haben damit immer noch Probleme — sie filtern große UDP-Pakete oder EDNS-Optionen.

Wichtig: Gehen die Schlüssel verloren oder die signierte Zonendatei brennt ab, hat man ein Problem. Vor jeder großen Änderung (Key-Rollover, Algorithmus-Wechsel) immer die längste TTL der Zone abwarten. Sonst sind gecachte Antworten mit der alten Signatur noch gültig, während die neue Signatur schon aktiv ist — die Zone wird temporär nicht validierbar.

Meinen „analogen“ DNSSEC-Masterplan dazu habe ich mir damals aufgezeichnet:

Was man auf DNSSEC aufbauen kann

Wenn die Zone signiert ist, lassen sich darüber weitere Sicherheitsmechanismen verteilen:

• DANE/TLSA — TLS-Zertifikate per DNS verifizieren, unabhängig von CAs.
• SSHFP — SSH-Hostkey-Fingerprints im DNS hinterlegen. Siehe auch: DNSSEC und SSHFP unter Linux Mint zum Laufen bringen.
• GPG-Keys im DNS — öffentliche Schlüssel über DNS verteilen.

Wer einen DNSSEC-validierenden Resolver sucht — dns.kernel-error.de bietet DNS over TLS und DNS over HTTPS mit DNSSEC-Validierung., DNSSEC: KSK auf 4096 Bit aktualisieren und SHA-512 vorbereiten, OPENPGPKEY: GPG-Schlüssel direkt im DNS veröffentlichen

---

Chronik

Dieser Beitrag wurde 2010 veröffentlicht und dokumentiert meine DNSSEC-Einführung über mehrere Jahre:

• November 2010 — Erste Signierung von kernel-error.org (NSEC3RSASHA1, 4096 Bit).
• Februar 2011 — DS-Record für kernel-error.org endlich in der .org-Zone veröffentlicht. DENIC kündigt Signierung der .de-TLD an.
• Februar 2011 — kernel-error.de signiert, über DENIC-Testbed validierbar.
• Juni 2011 — DENIC signiert .de offiziell, DS-Records in der Root-Zone.
• Februar 2012 — kernel-error.com ebenfalls signiert. Alle drei Domains komplett.
• Mai 2012 — GPG-Keys und SSHFP-Records im DNS hinterlegt.
• August 2013 — DANE/TLSA-Records für alle TLS-Dienste eingerichtet.
• 2024 — Algorithmus-Wechsel auf ECDSAP256SHA256 (Algorithmus 13). Anleitung oben entsprechend aktualisiert.

Siehe auch: DNSSEC und DANE

Fragen? Einfach melden.