3. Der RRSIG-Ressourceneintrag (The RRSIG Resource Record)
DNSSEC verwendet Public-Key-Kryptographie, um DNS-Ressourceneintragssätze (RRsets) zu signieren und zu authentifizieren. Digitale Signaturen (digital signatures) werden in RRSIG-Ressourceneinträgen gespeichert und im DNSSEC-Authentifizierungsprozess verwendet, der in [RFC4035] beschrieben ist. Ein Validierer (validator) kann diese RRSIG RRs verwenden, um RRsets aus der Zone zu authentifizieren. Der RRSIG RR MUSS nur verwendet werden, um Verifizierungsmaterial (digitale Signaturen) zu tragen, das zur Sicherung von DNS-Operationen verwendet wird.
Ein RRSIG-Eintrag enthält die Signatur für einen RRset mit einem bestimmten Namen, einer Klasse und einem Typ. Der RRSIG RR gibt ein Gültigkeitsintervall (validity interval) für die Signatur an und verwendet Algorithm, Signer's Name und Key Tag, um den DNSKEY RR zu identifizieren, der den öffentlichen Schlüssel enthält, mit dem ein Validierer die Signatur verifizieren kann.
Da jeder autoritative RRset in einer Zone durch eine digitale Signatur geschützt werden muss, müssen RRSIG RRs für Namen vorhanden sein, die einen CNAME RR enthalten. Dies ist eine Änderung gegenüber der traditionellen DNS-Spezifikation [RFC1034], die besagte, dass wenn ein CNAME für einen Namen vorhanden ist, dies der einzige zulässige Typ für diesen Namen ist. In einer signierten Zone MÜSSEN RRSIG und NSEC (siehe Abschnitt 4) für denselben Namen wie ein CNAME-Ressourceneintrag existieren.
Der Type-Wert für den RRSIG RR-Typ ist 46.
Der RRSIG RR ist klassenunabhängig.
Ein RRSIG RR MUSS dieselbe Klasse haben wie der RRset, den er abdeckt.
Der TTL-Wert eines RRSIG RR MUSS mit dem TTL-Wert des RRset übereinstimmen, den er abdeckt. Dies ist eine Ausnahme von den [RFC2181]-Regeln für TTL-Werte einzelner RRs innerhalb eines RRset: Einzelne RRSIG RRs mit demselben Besitzernamen haben unterschiedliche TTL-Werte, wenn die RRsets, die sie abdecken, unterschiedliche TTL-Werte haben.
3.1. RRSIG RDATA Wire Format
Das RDATA für einen RRSIG RR besteht aus einem 2-Oktett-Type Covered-Feld, einem 1-Oktett-Algorithm-Feld, einem 1-Oktett-Labels-Feld, einem 4-Oktett-Original TTL-Feld, einem 4-Oktett-Signature Expiration-Feld, einem 4-Oktett-Signature Inception-Feld, einem 2-Oktett-Key Tag, dem Signer's Name-Feld und dem Signature-Feld.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Covered | Algorithm | Labels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Expiration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Inception |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Tag | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Signature /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1.1. Das Type Covered-Feld (The Type Covered Field)
Das Type Covered-Feld identifiziert den Typ des RRset, der durch diesen RRSIG-Eintrag abgedeckt wird.
3.1.2. Das Algorithm Number-Feld (The Algorithm Number Field)
Das Algorithm Number-Feld identifiziert den kryptographischen Algorithmus, der zum Erstellen der Signatur verwendet wurde. Eine Liste der DNSSEC-Algorithmustypen finden Sie in Anhang A.1.
3.1.3. Das Labels-Feld (The Labels Field)
Das Labels-Feld gibt die Anzahl der Labels im ursprünglichen Besitzernamen des RRSIG RR an. Die Bedeutung dieses Feldes besteht darin, dass ein Validierer es verwendet, um zu bestimmen, ob die Antwort aus einem Wildcard synthetisiert wurde. Wenn ja, kann es verwendet werden, um zu bestimmen, welcher Besitzername beim Generieren der Signatur verwendet wurde.
Um eine Signatur zu validieren, benötigt der Validierer den ursprünglichen Besitzernamen, der zum Erstellen der Signatur verwendet wurde. Wenn der ursprüngliche Besitzername ein Wildcard-Label ("*") enthält, wurde der Besitzername möglicherweise während des Antwortprozesses vom Server erweitert. In diesem Fall muss der Validierer den ursprünglichen Besitzernamen rekonstruieren, um die Signatur zu validieren. [RFC4035] beschreibt, wie das Labels-Feld verwendet wird, um den ursprünglichen Besitzernamen zu rekonstruieren.
Der Wert des Labels-Feldes DARF NICHT das Null-Label (Root), das den Besitzernamen beendet, oder das Wildcard-Label (falls vorhanden) zählen. Der Wert des Labels-Feldes MUSS kleiner oder gleich der Anzahl der Labels im RRSIG-Besitzernamen sein. Zum Beispiel hat "www.example.com." einen Labels-Feldwert von 3, und "*.example.com." hat einen Labels-Feldwert von 2. Root (".") hat einen Labels-Feldwert von 0.
Obwohl das Wildcard-Label nicht in der Zählung enthalten ist, die im Labels-Feld des RRSIG RR gespeichert ist, ist das Wildcard-Label Teil des Besitzernamens des RRset, wenn die Signatur generiert oder verifiziert wird.
3.1.4. Original TTL-Feld (Original TTL Field)
Das Original TTL-Feld gibt die TTL des abgedeckten RRset an, wie sie in der autoritativen Zone erscheint.
Das Original TTL-Feld ist notwendig, da ein Caching-Resolver den TTL-Wert eines gecachten RRset dekrementiert. Um eine Signatur zu validieren, benötigt ein Validierer die ursprüngliche TTL. [RFC4035] beschreibt, wie der Original TTL-Feldwert verwendet wird, um die ursprüngliche TTL zu rekonstruieren.
3.1.5. Felder Signature Expiration und Inception (Signature Expiration and Inception Fields)
Die Felder Signature Expiration und Inception geben einen Gültigkeitszeitraum für die Signatur an. Der RRSIG-Eintrag DARF NICHT vor dem Inception-Datum für die Authentifizierung verwendet werden und DARF NICHT nach dem Expiration-Datum für die Authentifizierung verwendet werden.
Die Feldwerte Signature Expiration und Inception geben ein Datum und eine Uhrzeit in Form einer vorzeichenlosen 32-Bit-Zahl von Sekunden seit dem 1. Januar 1970 00:00:00 UTC an, wobei Schaltsekunden ignoriert werden, in Netzwerk-Byte-Reihenfolge. Das längste Intervall, das durch dieses Format ohne Überlauf ausgedrückt werden kann, beträgt ungefähr 136 Jahre. Ein RRSIG RR kann einen Expiration-Feldwert haben, der numerisch kleiner ist als der Inception-Feldwert, wenn der Expiration-Feldwert nahe am 32-Bit-Überlaufpunkt liegt oder wenn die Signatur langlebig ist. Aus diesem Grund MÜSSEN alle Vergleiche, die diese Felder betreffen, "Seriennummernarithmetik" (Serial number arithmetic) verwenden, wie in [RFC1982] definiert. Als direkte Folge können die in diesen Feldern enthaltenen Werte nicht auf Daten verweisen, die mehr als 68 Jahre in der Vergangenheit oder Zukunft liegen.
3.1.6. Das Key Tag-Feld (The Key Tag Field)
Das Key Tag-Feld enthält den Key Tag-Wert des DNSKEY RR, der diese Signatur validiert, in Netzwerk-Byte-Reihenfolge. Anhang B erklärt, wie Key Tag-Werte berechnet werden.
3.1.7. Das Signer's Name-Feld (The Signer's Name Field)
Der Wert des Signer's Name-Feldes identifiziert den Besitzernamen des DNSKEY RR, den ein Validierer verwenden soll, um diese Signatur zu validieren. Das Signer's Name-Feld MUSS den Namen der Zone des abgedeckten RRset enthalten. Ein Sender DARF NICHT DNS-Namenskompression im Signer's Name-Feld verwenden, wenn er einen RRSIG RR überträgt.
3.1.8. Das Signature-Feld (The Signature Field)
Das Signature-Feld enthält die kryptographische Signatur, die das RRSIG RDATA (ohne das Signature-Feld) und den RRset abdeckt, der durch den RRSIG-Besitzernamen, die RRSIG-Klasse und das RRSIG Type Covered-Feld angegeben ist. Das Format dieses Feldes hängt vom verwendeten Algorithmus ab, und diese Formate werden in separaten Begleitdokumenten beschrieben.
3.2. RRSIG RR Präsentationsformat (The RRSIG RR Presentation Format)
Das Präsentationsformat des RDATA-Teils ist wie folgt:
Das Type Covered-Feld wird als RR-Typ-Mnemonik dargestellt. Wenn das Mnemonik nicht bekannt ist, MUSS die TYPE-Darstellung wie in [RFC3597], Abschnitt 5 beschrieben, verwendet werden.
Der Algorithm-Feldwert MUSS entweder als vorzeichenlose Dezimalzahl oder als Algorithmus-Mnemonik dargestellt werden, wie in Anhang A.1 spezifiziert.
Der Labels-Feldwert MUSS als vorzeichenlose Dezimalzahl dargestellt werden.
Der Original TTL-Feldwert MUSS als vorzeichenlose Dezimalzahl dargestellt werden.
Die Signature Expiration- und Inception-Feldwerte MÜSSEN entweder als vorzeichenlose Dezimalzahl dargestellt werden, die Sekunden seit dem 1. Januar 1970 00:00:00 UTC angibt, oder in der Form YYYYMMDDHHmmSS in UTC, wobei:
- YYYY das Jahr ist (0001-9999)
- MM die Monatsnummer ist (01-12)
- DD der Tag des Monats ist (01-31)
- HH die Stunde in 24-Stunden-Notation ist (00-23)
- mm die Minute ist (00-59)
- SS die Sekunde ist (00-59)
Implementierungen, die diese Felder Menschen präsentieren, SOLLTEN das Format YYYYMMDDHHmmSS verwenden.
Das Key Tag-Feld MUSS als vorzeichenlose Dezimalzahl dargestellt werden.
Der Signer's Name-Feldwert MUSS als Domänenname dargestellt werden.
Das Signature-Feld MUSS als Base64-Kodierung der Signatur dargestellt werden. Leerzeichen sind im Base64-Text erlaubt. Für eine Definition der Base64-Kodierung siehe [RFC3548].
3.3. RRSIG RR Beispiel (RRSIG RR Example)
Der folgende RRSIG RR speichert die Signatur für den A-RRset von host.example.com.
host.example.com. 86400 IN RRSIG A 5 3 86400 20050322173103 (
20050220173103 2642 example.com.
oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )
Die ersten vier Felder geben den Besitzernamen, TTL, Klasse und RR-Typ (RRSIG) an. Das "A" repräsentiert das Type Covered-Feld. Wert 5 ist das Algorithm-Feld. Wert 3 ist das Labels-Feld. Wert 86400 ist das Original TTL-Feld, das der für den A-RRset verwendete TTL-Wert war. Die Zeitwerte 20050322173103 und 20050220173103 sind jeweils die Signature Expiration- und Inception-Daten. Wert 2642 ist das Key Tag, und example.com. ist der Signer's Name. Der verbleibende Text ist eine Base64-Kodierung des Signature-Feldes.
Navigation verwandter Kapitel: