Kapitel 2: Wie DNSSEC funktioniert

Bevor Sie DNSSEC in Ihrer Umgebung einrichten, lohnt sich ein Blick auf die Mechanismen, die hinter den Kulissen arbeiten. Dieses Kapitel erklärt die Bausteine von DNSSEC — Schlüsselpaare, Signatur-Records und die Vertrauenskette — so, dass Sie die Konfigurationsschritte in den folgenden Kapiteln nicht nur ausführen, sondern auch verstehen können. Wer bereits mit den Grundlagen vertraut ist, kann direkt zu Kapitel 3 springen.

Zwei Schlüsseltypen: ZSK und KSK

DNSSEC verwendet asymmetrische Kryptografie mit zwei getrennten Schlüsselpaaren pro Zone. Diese Trennung hat einen praktischen Grund: Die Schlüssel haben unterschiedliche Lebensdauern und Sicherheitsanforderungen.

Der Zone Signing Key (ZSK) signiert die eigentlichen DNS-Einträge einer Zone — A-Records, MX-Records, TXT-Records und alle anderen. Er wird häufig gewechselt (in der Praxis monatlich bis quartalsweise), weil er regelmäßig für Signaturen verwendet wird und ein Kompromittierung durch Kryptoanalyse mit der Zeit wahrscheinlicher wird.

Der Key Signing Key (KSK) signiert ausschließlich den DNSKEY-Record-Satz — also die öffentlichen Schlüssel der Zone selbst. Er wird seltener gewechselt (in der Praxis jährlich), da sein Hash (der DS-Record) in der übergeordneten Zone hinterlegt ist und ein Wechsel Koordination mit dem Registrar erfordert.

Die DNSSEC-Record-Typen

DNSSEC führt vier neue DNS-Record-Typen ein, die zusammen das Signatur- und Validierungssystem bilden.

DNSKEY enthält die öffentlichen Schlüssel der Zone (sowohl ZSK als auch KSK). Validierende Resolver benötigen diese Schlüssel, um die Signaturen der DNS-Einträge zu prüfen.

RRSIG (Resource Record Signature) enthält die kryptografische Signatur eines DNS-Eintrags. Zu jedem signierten Record-Typ existiert ein zugehöriger RRSIG-Record. Die Signatur enthält neben dem eigentlichen Signaturwert auch den Gültigkeitszeitraum — ein häufiger Fehlerfall sind abgelaufene RRSIG-Records, die zu SERVFAIL-Antworten führen (dazu mehr in Kapitel 7).

DS (Delegation Signer) ist der Vertrauensanker zwischen den Ebenen der DNS-Hierarchie. Er enthält einen Hash des KSK der untergeordneten Zone und wird in der übergeordneten Zone gespeichert. Für Ihre Domain beispiel.de liegt der DS-Record in der .de-Zone bei DENIC. Dieser Record ist das Bindeglied, das die Chain of Trust ermöglicht.

NSEC / NSEC3 (Next Secure) beweist die Nichtexistenz eines DNS-Eintrags. Ohne NSEC könnte ein Angreifer eine gefälschte „dieser Eintrag existiert nicht"-Antwort einschleusen. NSEC listet den nächsten existierenden Eintrag in alphabetischer Reihenfolge auf, was allerdings das Aufzählen aller Einträge einer Zone ermöglicht (Zone Walking). NSEC3 löst dieses Problem, indem es gehashte Eintragnamen verwendet.

Die Chain of Trust

Die Vertrauenskette (Chain of Trust) ist das zentrale Konzept von DNSSEC. Sie verbindet jede signierte Zone mit der DNS-Root-Zone über eine lückenlose Kette kryptografischer Verweise.

Der Ablauf am Beispiel von beispiel.de:

1. Die Root-Zone (.) signiert ihren eigenen DNSKEY-Record-Satz. Die öffentlichen Schlüssel der Root-Zone sind in jedem validierenden Resolver als Trust Anchor hinterlegt — das ist der Ausgangspunkt.
2. Die Root-Zone enthält einen DS-Record für .de, der den KSK der .de-Zone referenziert. Der Resolver kann nun die Signatur der .de-Zone prüfen.
3. Die .de-Zone (betrieben von DENIC) enthält einen DS-Record für beispiel.de, der den KSK Ihrer Zone referenziert.
4. Ihre Zone beispiel.de enthält die mit dem ZSK signierten DNS-Einträge (A, MX, TXT etc.) und die zugehörigen RRSIG-Records.

Jede Ebene verweist auf die nächste, und der Resolver arbeitet sich von der Root bis zur Zielzone vor. Fehlt an irgendeiner Stelle der DS-Record oder stimmt der Hash nicht überein, bricht die Kette ab und die Validierung schlägt fehl.

Wie ein Resolver validiert

Wenn ein validierender Resolver eine Anfrage für beispiel.de erhält, durchläuft er folgende Schritte:

1. Er fragt den DNSKEY-Record von beispiel.de ab und erhält den öffentlichen ZSK und KSK.
2. Er prüft, ob der Hash des KSK mit dem DS-Record in der .de-Zone übereinstimmt.
3. Er prüft, ob der DNSKEY-Record-Satz korrekt mit dem KSK signiert ist (RRSIG über DNSKEY).
4. Er prüft, ob der angefragte Record (z. B. A-Record) korrekt mit dem ZSK signiert ist (RRSIG über A).
5. Wenn alle Prüfungen bestanden sind, liefert er die Antwort mit gesetztem AD-Flag (Authenticated Data) an den Client.

Schlägt eine Prüfung fehl — etwa weil eine Signatur abgelaufen ist oder der DS-Record nicht zum KSK passt — antwortet der Resolver mit SERVFAIL. Der Nutzer sieht dann eine nicht erreichbare Domain. Das ist beabsichtigt: Eine nicht validierbare Antwort wird als potenziell manipuliert behandelt.

Key Rollover: Warum Schlüssel ablaufen

Kryptografische Schlüssel haben eine begrenzte Lebensdauer. Je länger ein Schlüssel im Einsatz ist, desto mehr signierte Daten stehen für potenzielle Kryptoanalyse zur Verfügung. DNSSEC sieht daher regelmäßige Schlüsselwechsel (Key Rollovers) vor.

Beim ZSK-Rollover wird ein neuer ZSK erzeugt und beide Schlüssel (alt und neu) für eine Übergangszeit parallel veröffentlicht. Sobald der neue Schlüssel in allen Resolver-Caches angekommen ist, werden die Signaturen auf den neuen Schlüssel umgestellt und der alte entfernt. Dieser Vorgang kann automatisiert werden (BIND dnssec-policy, Windows DNS automatischer Rollover).

Beim KSK-Rollover muss zusätzlich der DS-Record in der übergeordneten Zone aktualisiert werden — das erfordert Koordination mit dem Registrar oder dem TLD-Betreiber. RFC 5011 beschreibt ein Verfahren, mit dem Resolver neue Trust Anchors automatisch übernehmen können, sofern sie die Zone kontinuierlich beobachten. Die Details zu beiden Rollover-Verfahren finden Sie in Kapitel 5 (Linux) und Kapitel 4 (Active Directory).