DNSSEC – DNS Security Extensions

Abkürzung: DNSSEC

Das Domain Name System wurde ohne Sicherungsmechanismen entworfen. Eine Antwort gilt als echt, wenn sie zur Anfrage passt und von der erwarteten Adresse kommt — Eigenschaften, die ein Angreifer nachbilden kann. DNSSEC fügt die fehlende Prüfung hinzu, indem es die Daten selbst signiert.

Entscheidend ist, was DNSSEC nicht tut: Es verbirgt nichts. Anfragen und Antworten bleiben im Klartext lesbar. Für Vertraulichkeit sind andere Verfahren zuständig.

Was signiert wird

Nicht die Antwort auf eine Anfrage, sondern die Daten in der Zone. Die Signaturen entstehen beim Einrichten der Zone und liegen darin als zusätzliche Einträge:

Ein autoritativer Server rechnet nichts; er liefert die vorbereiteten Signaturen mit aus. Die Prüfung erfolgt beim Resolver.

Die Vertrauenskette

Hier liegt der eigentliche Kunstgriff. Der öffentliche Schlüssel einer Zone steht in der Zone selbst — er könnte also mitgefälscht werden. Deshalb liegt sein Hashwert als DS-Eintrag nicht in der eigenen, sondern in der übergeordneten Zone, und ist dort wiederum signiert:

Wurzelzone  .            DNSKEY  ← Vertrauensanker im Resolver
                         DS für net.
    │
    ▼
Zone        net.         DNSKEY  (passt zum DS oben)
                         DS für netzikon.net.
    │
    ▼
Zone        netzikon.net. DNSKEY (passt zum DS oben)
                          RRSIG über die A-Einträge

Der Resolver arbeitet sich von oben nach unten durch. Sein einziger vorab bekannter Wert ist der Schlüssel der Wurzelzone — der Vertrauensanker, der mit der Software ausgeliefert wird. Das ist dieselbe Konstruktion wie bei der Zertifikatskette, nur mit genau einem Anker statt hunderter.

Daraus folgt der häufigste Betriebsfehler: Wird die Zone signiert, aber kein DS-Eintrag beim Registrar hinterlegt, prüft niemand etwas. Umgekehrt ist es gefährlicher — bleibt ein alter DS-Eintrag stehen, nachdem die Schlüssel gewechselt wurden, schlägt die Prüfung fehl und die Domain ist für validierende Resolver nicht mehr auflösbar. Nicht langsam, nicht mit Warnung: nicht auflösbar.

Der Nachweis der Nichtexistenz

Ein eigentümliches Problem: Auch die Antwort „diesen Namen gibt es nicht" muss signiert sein, sonst könnte ein Angreifer einen existierenden Namen wegfälschen. Vorab signieren lässt sich aber nur, was vorhanden ist.

Gelöst wird das über die alphabetische Nachbarschaft. Ein NSEC-Eintrag sagt: „Zwischen mail und www liegt nichts." Das ist signierbar und beweist die Nichtexistenz jedes Namens dazwischen.

Der Nebeneffekt ist, dass sich damit die gesamte Zone abschreiten lässt — jede Antwort nennt den nächsten existierenden Namen. NSEC3 ersetzt die Namen deshalb durch Hashwerte. Ganz verhindern lässt sich das Aufzählen auch damit nicht, es wird nur aufwendiger.

Die Algorithmen

Lange standen die Vorgaben, welche Signaturverfahren ein Resolver beherrschen muss, in RFC 8624. Dieses Dokument ist seit RFC 9904 obsolet, und die Änderung ist mehr als ein Nummernwechsel: Die verbindliche Liste wohnt jetzt in den IANA-Registries für DNSSEC-Algorithmen, nicht mehr in einem RFC. Der Grund ist Beweglichkeit — eine Registry lässt sich fortschreiben, ohne jedes Mal ein RFC zu ersetzen.

An den Einstufungen der Verfahren hat RFC 9904 selbst nichts geändert; das bleibt künftigen Dokumenten überlassen. Wer wissen will, was heute gilt, schaut also in die Registry, nicht in ein RFC.

In der Praxis dominieren die Verfahren über elliptische Kurven, weil RSA-Signaturen die Antworten groß machen — und Größe ist bei DNS ein knappes Gut.

Warum die Verbreitung stockt

DNSSEC ist seit Jahren einsetzbar und wird trotzdem nur von einem Teil der Zonen genutzt. Die Gründe sind durchweg betrieblicher Natur.

Der Fehlerfall ist hart. Eine abgelaufene Signatur oder ein nicht nachgezogener DS-Eintrag macht die Domain unerreichbar. Ohne DNSSEC wäre dieselbe Zone weiter erreichbar. Das Risiko liegt also sichtbar beim Betreiber, der Nutzen eher diffus beim Nutzer.

Signaturen laufen ab. Anders als ein Zertifikat, das jemand bemerkt, erneuern sich RRSIG-Einträge automatisiert — oder eben nicht, wenn die Automatik stillsteht. Ein Überwachungspunkt mehr.

Schlüsselwechsel sind heikel. Ein Wechsel muss mit der übergeordneten Zone abgestimmt sein und die Zwischenspeicher der Resolver überdauern. Dafür gibt es Verfahren, aber sie brauchen Geduld und Reihenfolge.

Die Prüfung hilft nur, wenn jemand prüft. Validiert der Resolver des Nutzers nicht, bringt die signierte Zone diesem Nutzer nichts. Der Anteil validierender Resolver ist gestiegen, aber nicht vollständig.

Was darauf aufbaut

Ist die DNS-Antwort belegbar, lassen sich darüber weitere Angaben verankern. Das ist der eigentliche Mehrwert gegenüber der puren Fälschungssicherheit.

CAA legt fest, welche Zertifizierungsstellen ausstellen dürfen. Ohne DNSSEC ist diese Angabe auf dem Weg zur Stelle fälschbar.

DANE hinterlegt den Fingerabdruck eines TLS-Zertifikats im DNS. Damit lässt sich eine Verbindung gegen das DNS prüfen statt gegen die Zertifizierungsstellen — im Mailverkehr zwischen Servern verbreitet, im Web praktisch nicht.

Encrypted Client Hello holt den Serverschlüssel aus dem DNS, siehe Server Name Indication. Ohne gesicherte Auflösung ließe sich dieser Schlüssel austauschen.

Abgrenzung

DNSSEC belegt Echtheit, DNS over HTTPS und DNS over TLS stellen Vertraulichkeit her. Die beiden Eigenschaften sind unabhängig: Eine verschlüsselte Abfrage bei einem Resolver, der nicht validiert, liefert vertraulich übertragene Fälschungen. Eine validierte Antwort im Klartext ist echt, aber für jeden mitlesbar.

Sinnvoll ist beides zusammen — verschlüsselter Transport zu einem validierenden Resolver.