RRSIG Resource Record

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Mit RRSIG Resource Record bzw. Signature Resource Record können im Rahmen von DNSSEC (DNS Security) beliebige Resource Records digital unterschrieben werden. Der RRSIG-Typ löste 2004 den nahezu identischen SIG Resource Record ab.

Hintergrund[Bearbeiten | Quelltext bearbeiten]

Ein Benutzer, der auf einen DNS-Anfrage eine Antwort erhält (z. B. eine IP-Adresse), kann nicht sicher sein, dass die Antwort auch wirklich von einem regulären Nameserver stammt und dass sie nicht auf dem Transportweg verfälscht wurde. Die Lösung von DNSSEC ist es, Resource Records digital zu unterschreiben.

Eine digitale Signatur setzt ein Public-Key-Verfahren voraus. Der Nameserver, der für eine Zone autoritativ ist, unterschreibt die Resource Records mit seinem privaten Schlüssel. Resolver können die digitale Unterschrift mit dem öffentlichen Schlüssel der Zone validieren. Die digitale Signaturen werden mittels RRSIG Resource Record übertragen.

Die Signatur eines RRSIG Resource Record beglaubigt eine Menge von Resource Records (englisch RR set), die denselben Namen, dieselbe Klasse und denselben Typ haben. Im einfachsten Fall besteht die Menge aus einem einzelnen Resource Record, dessen Echtheit durch den RRSIG Resource Record beglaubigt wird.

Aufbau[Bearbeiten | Quelltext bearbeiten]

Ein RRSIG Resource Record besteht aus den folgenden Feldern:

Name
des digital unterschriebenen RRs
Aktuelle TTL
gibt an, wie lange dieser Eintrag im Cache gehalten werden darf
Klasse
zu der der signierte RR gehört
RRSIG
RR Typ um den es sich handelt (Typ 46)
Typ
des unterschriebenen RR – z. B. A, NS, SOA
Signaturalgorithmus
3 = DSA/SHA-1
5 = RSA/SHA-1
6 = DSA/SHA-1/NSEC3
7 = RSA/SHA-1/NSEC3
8 = RSA/SHA-256
10 = RSA/SHA-512
12 = GOST R 34.10-2001
13 = ECDSA/Curve P-256/SHA-256
14 = ECDSA/Curve P-384/SHA-384
15 = Ed25519 (EdDSA/Curve25519/SHA-512)[1][2]
16 = Ed448 (EdDSA/Curve448/SHAKE256)[1][2]
[3]
Anzahl der Namenskomponenten
erforderlich zur Validierung von Wildcard-Records
TTL
zum Zeitpunkt der Unterschrift
Endzeitpunkt
Datum bis zu dem die Unterschrift gültig ist
Anfangszeitpunkt
Datum ab dem die Unterschrift gültig ist
ID-Nummer
identifiziert den unterzeichnenden DNSKEY, um zwischen mehreren Signaturen zu unterscheiden (engl. key tag)
Name des Unterzeichners
entspricht dem Zonennamen, unter dem der DNSKEY abgerufen werden kann
digitale Signatur
die Signatur wird in einem Binärformat übertragen und in Zonendateien bzw. zu Präsentationszwecken mit Base64 kodiert dargestellt

Beispiel[Bearbeiten | Quelltext bearbeiten]

In diesem Beispiel wird ein A Resource Record digital unterschrieben:

www.child.example. 1285    A    1.2.3.15
www.child.example. 1285    IN                ; Klasse zu der der RR gehört
                           RRSIG             ; RR ist vom Typ RRSIG
                           A                 ; Signierter Typ ist A
                           8                 ; Verwendeter Signieralgorithmus
                           3                 ; Name hat 3 Komponenten
                           1285              ; Original-TTL
                           (
                           20040327122207    ; Endzeitpunkt
                           20040226122207    ; Anfangszeitpunkt
                           22004             ; ID des verwendeten Schlüssels
                           child.example.    ; Name des Unterzeichners
                           BMTLR80WnKndatr77...BtprR9SLKoZUiPWX ; Hashwert
                           )

Weblinks[Bearbeiten | Quelltext bearbeiten]

  • RFC 4033 – DNS-Security Extension. (englisch).
  • RFC 4034 – Resource Records for the DNS Security Extensions. (englisch).

Einzelnachweise[Bearbeiten | Quelltext bearbeiten]

  1. a b RFC 8080 – Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC. 2017 (englisch).
  2. a b RFC 8032 – Edwards-Curve Digital Signature Algorithm (EdDSA). 2017 (englisch).
  3. iana.org