DS Resource Record

DS-RR (Delegation Signer Resource Record) dienen der Verkettung von DNSSEC-signierten Zonen. Dadurch können mehrere DNS-Zonen zu einer Chain of Trust zusammengefasst werden, deren Validierung Kenntnis eines einzigen öffentlichen Schlüssels erfordert, der als Vertrauensanker für die Kette dient.

DNSSEC verwendet zum Nachweis der Authentizität digitale Signaturen, die mit asymmetrischen Kryptosystemen erstellt werden. Der Besitzer einer Domain signiert die Resource Records mit einem nur ihm bekannten privaten Schlüssel. Ein Resolver, der DNSSEC unterstützt, überprüft die Signaturen mit einem öffentlichen Schlüssel, womit die Authentizität nachgewiesen wird.

Ein Grundproblem hierbei ist die Verteilung der öffentlichen Schlüssel: Wie kann ein Domainbesitzer seinen öffentlichen Schlüssel publik machen? Wie kann der DNSSEC-Resolver die Authentizität eines öffentlichen Schlüssels überprüfen? Da es im Domain Name System sehr viele Domains über verschiedene Zuständigkeitsgrenzen hinweg gibt, muss die Schlüsselverteilung skalieren. Zudem müssen kryptographische Schlüssel regelmäßig erneuert werden, sodass eine manuelle Schlüsselverteilung zu den Resolvern unpraktikabel wäre.

Die Grundidee bei DNSSEC ist es, die öffentlichen Schlüssel aller beteiligten DNS-Zonen zu verketten und den obersten Schlüssel als Vertrauensanker (englisch trust anchor) zu verwenden. Nur der Vertrauensanker muss den Validierern vorab bekannt sein, was die Schlüsselverteilung vereinfacht. Die Echtheit der übrigen Schlüssel kann durch Validierung der Vertrauenskette überprüft werden.

Für die Schlüsselverteilung setzt DNSSEC den DNSKEY Resource Record und für die Verkettung den DS Resource Record ein. Ein DS Resource Record enthält den kryptographischen Hashwert eines öffentlichen Schlüssels und wird in der Eltern-Zone abgelegt, wo er mit dem Schlüssel der Eltern-Zone signiert wird. Dadurch entsteht eine kryptographische Bindung zwischen den Schlüsseln zweier Zonen.

Ein weiterer Zweck des DS Resource Records ist es, zu signalisieren, dass die Sub-Zone mit DNSSEC signiert ist. Fehlt der DS Resource Record (und ist das Fehlen durch NSEC oder NSEC3 nachgewiesen), so kann der Resolver ableiten, dass für die Sub-Zone keine DNSSEC-Validierung durchzuführen ist. Dadurch ist eine Koexistenz von signierten und unsignierten Zonen möglich, ohne dass ein Angreifer dies für einen Downgrade-Angriff ausnutzen kann.

Der DS Resource Record wurde ursprünglich 2003 als RFC 3658 veröffentlicht^[1] und in RFC 4034 aktualisiert.^[2]

Ein DS-Record tritt immer gemeinsam mit einem NS Resource Record auf. Beide verweisen auf eine Subzone. Im DS-Record liegt der Hash des Secure Entry Points der Subzone. Jeder DS-Eintrag wird mit dem Zonenschlüssel der Zone, in der er sich befindet, digital unterschrieben. Damit kann der Öffentliche Schlüssel dieser Subzone validiert werden. Eine Subzone kann ihrerseits DS-Records enthalten, die auf weitere Subzonen verweisen. Dadurch entsteht ausgehend von der obersten Zone eine Kette, die sogenannte Chain of Trust.

Ein DS-RR besteht aus den folgenden Feldern:

Label

Name der zu verkettenden Subzone

Typ

DS (Typcode 43)

ID

Identifikationsnummer (key tag)

Verschlüsselungsverfahren

3=DSA/SHA1, 5=RSA/SHA1, 6=DSA-NSEC3-SHA1, 7=RSASHA1-NSEC3-SHA1, 8=RSA/SHA-256, 10=RSA/SHA-512, 12=GOST R 35.10-2001, 13=ECDSA-P256/SHA256, 14=ECDSA-P384/SHA384, 15=ED25519, 16=ED448^[3]

Das genannte Verfahren wird nicht verwendet, um den Hash kryptographisch abzusichern, sondern nennt das verwendete Signierverfahren des referenzierten Schlüssels.

Die Verfahren 1, 2 und 4 sind nicht für Zonensignaturen freigegeben. Alle weiteren Verfahren sind entweder nicht definiert oder nicht freigegeben.

Hash-Typ

1=SHA-1, 2=SHA-256, 3=GOST R 34.11-94, 4=SHA-384

Der Hash-Typ 1 (SHA-1) ist aus Rückwärtskompatibilitätsgründen noch erlaubt, wird aber nicht empfohlen.

Hash

Der mit dem oben erwähnten Typ erzeugte Hash eines DNSKEY Records.

Der DS-Record kann aus dem DNSKEY berechnet werden, aber nicht umgekehrt. Hierfür wird mit der Hash über die folgenden Werte des DNSKEYs berechnet.

Beispiel:

SHA_256(DNSKEY owner name | Flags | Protocol | Algorithm | Public Key)

Das Zeichen | steht für die Aneinanderreihung der Werte. Der öffentliche Schlüssel darf keine Leerzeichen enthalten und muss aus dem Base64 Format dekodiert werden.

In diesem Beispiel wird aus der Zone example.org heraus per Delegation auf die Subzone filiale1.example.org verwiesen. Der im DS-record aufgeführte Hash-Wert entspricht dem Schlüsselunterzeichnungs-Schlüssel der Subzone filiale1.example.org.

filiale1.example.org. NS nsf
filiale1.example.org. DS; Typ
                           52037    ; Identifikationsnummer
                           1        ; Verschlüsselungsverfahren
                           1        ; Hash-Typ
                           378929E92D7DA04267EE87E802D75C5CA1B5D280

Um in eine Chain of Trust aufgenommen zu werden, muss der öffentliche Schlüssel einer Zone der übergeordneten Zone übermittelt werden. Das kann schwierig sein, wenn diese von einer Instanz außerhalb des eigenen Einflussbereichs verwaltet wird und bietet daher Angriffspunkte.

• R. Arends, R. Austein, M. Larson, D. Massey, S. Rose: RFC: 4034 – Resource Records for the DNS Security Extension. März 2005 (englisch).
• RFC: 4509 – Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records. (englisch).
• RFC: 6605 – ECDSA for DNSSEC. (englisch).

1. ↑ O. Gudmundsson: RFC: 3658 – Delegation Signer (DS) Resource Record (RR). Dezember 2003 (englisch).
2. ↑ R. Arends, R. Austein, M. Larson, D. Massey, S. Rose: RFC: 4034 – Resource Records for the DNS Security Extension. März 2005 (englisch).
3. ↑ DNS Security Algorithm Numbers. IANA.