2. Zone Signing (Zonensignierung)
DNSSEC führt das Konzept signierter Zonen (Signed Zones) ein. Eine signierte Zone enthält DNS Public Key (DNSKEY), Resource Record Signature (RRSIG), Next Secure (NSEC) und (optional) Delegation Signer (DS) Einträge gemäß den in den Abschnitten 2.1, 2.2, 2.3 bzw. 2.4 angegebenen Regeln. Eine Zone, die diese Einträge nicht gemäß den Regeln in diesem Abschnitt enthält, ist eine unsignierte Zone (Unsigned Zone).
DNSSEC erfordert eine Änderung der Definition des CNAME-Ressourceneintrags ([RFC1035]). Abschnitt 2.5 ändert den CNAME-RR, um RRSIG- und NSEC-RRs zu ermöglichen, am selben Besitzernamen wie ein CNAME-RR zu erscheinen.
DNSSEC spezifiziert die Platzierung von zwei neuen RR-Typen, NSEC und DS, die auf der elterlichen Seite eines Zonenschnitts (Zone Cut) (d.h. an einem Delegationspunkt) platziert werden können. Dies ist eine Ausnahme vom allgemeinen Verbot, Daten in der Elternzone an einem Zonenschnitt zu platzieren. Abschnitt 2.6 beschreibt diese Änderung.
2.1. Including DNSKEY RRs in a Zone (Einbeziehung von DNSKEY-RRs in eine Zone)
Um eine Zone zu signieren, generiert der Zonenverwalter ein oder mehrere öffentliche/private Schlüsselpaare und verwendet den/die privaten Schlüssel, um autoritative RRsets in der Zone zu signieren. Für jeden privaten Schlüssel, der zum Erstellen von RRSIG-RRs in einer Zone verwendet wird, sollte (SHOULD) die Zone einen Zonen-DNSKEY-RR enthalten, der den entsprechenden öffentlichen Schlüssel enthält. Ein Zonenschlüssel-DNSKEY-RR muss (MUST) das Zone Key-Bit des Flags-RDATA-Feldes gesetzt haben (siehe Abschnitt 2.1.1 von [RFC4034]). Öffentliche Schlüssel, die mit anderen DNS-Operationen verbunden sind, können (MAY) in DNSKEY-RRs gespeichert werden, die nicht als Zonenschlüssel markiert sind, dürfen aber nicht (MUST NOT) zur Verifizierung von RRSIGs verwendet werden.
Wenn der Zonenverwalter beabsichtigt, dass eine signierte Zone anders als als Sicherheitsinsel (Island of Security) verwendbar ist, muss (MUST) der Zonen-Apex mindestens einen DNSKEY-RR enthalten, um als sicherer Einstiegspunkt in die Zone zu fungieren. Dieser sichere Einstiegspunkt könnte dann als Ziel einer sicheren Delegierung über einen entsprechenden DS-RR in der Elternzone verwendet werden (siehe [RFC4034]).
2.2. Including RRSIG RRs in a Zone (Einbeziehung von RRSIG-RRs in eine Zone)
Für jedes autoritative RRset in einer signierten Zone muss (MUST) mindestens ein RRSIG-Eintrag vorhanden sein, der die folgenden Anforderungen erfüllt:
- Der RRSIG-Besitzername ist gleich dem RRset-Besitzernamen
- Die RRSIG-Klasse ist gleich der RRset-Klasse
- Das RRSIG Type Covered-Feld ist gleich dem RRset-Typ
- Das RRSIG Original TTL-Feld ist gleich der TTL des RRsets
- Die TTL des RRSIG-RR ist gleich der TTL des RRsets
- Das RRSIG Labels-Feld ist gleich der Anzahl der Labels im RRset-Besitzernamen, ohne das Null-Root-Label zu zählen und ohne das linkeste Label zu zählen, wenn es ein Wildcard ist
- Das RRSIG Signer's Name-Feld ist gleich dem Namen der Zone, die das RRset enthält
- Die RRSIG Algorithm-, Signer's Name- und Key Tag-Felder identifizieren einen Zonenschlüssel-DNSKEY-Eintrag am Zonen-Apex
Der Prozess zum Konstruieren des RRSIG-RR für ein gegebenes RRset wird in [RFC4034] beschrieben. Ein RRset kann (MAY) mehrere RRSIG-RRs zugeordnet haben. Beachten Sie, dass RRSIG-RRs, da sie eng mit den RRsets verbunden sind, deren Signaturen sie enthalten, im Gegensatz zu allen anderen DNS-RR-Typen keine RRsets bilden.
Ein RRSIG-RR selbst darf nicht (MUST NOT) signiert werden, da das Signieren eines RRSIG-RR keinen Wert hinzufügen und eine Endlosschleife im Signierungsprozess erzeugen würde.
Das NS-RRset, das am Zonen-Apex-Namen erscheint, muss (MUST) signiert werden, aber die NS-RRsets, die an Delegationspunkten erscheinen (d.h. die NS-RRsets in der Elternzone, die den Namen an die Nameserver der Kindzone delegieren), dürfen nicht (MUST NOT) signiert werden. Glue-Adress-RRsets, die mit Delegierungen verbunden sind, dürfen nicht (MUST NOT) signiert werden.
Es muss (MUST) ein RRSIG für jedes RRset unter Verwendung mindestens eines DNSKEY jedes Algorithmus im Zonen-Apex-DNSKEY-RRset geben.
2.3. Including NSEC RRs in a Zone (Einbeziehung von NSEC-RRs in eine Zone)
Jeder Besitzername in der Zone, der autoritative Daten oder ein Delegationspunkt-NS-RRset hat, muss (MUST) einen NSEC-Ressourceneintrag haben. Das Format von NSEC-RRs und der Prozess zum Konstruieren des NSEC-RR für einen gegebenen Namen wird in [RFC4034] beschrieben.
Der TTL-Wert für jeden NSEC-RR sollte (SHOULD) derselbe sein wie das Mindest-TTL-Wertfeld im Zonen-SOA-RR.
Ein NSEC-Eintrag (und sein zugehöriges RRSIG-RRset) darf nicht (MUST NOT) das einzige RRset an einem bestimmten Besitzernamen sein. Das heißt, der Signierungsprozess darf nicht (MUST NOT) NSEC- oder RRSIG-RRs für Besitzernamensknoten erstellen, die vor der Signierung der Zone nicht der Besitzername eines RRsets waren.
Die Typ-Bitmap jedes NSEC-Ressourceneintrags in einer signierten Zone muss (MUST) das Vorhandensein sowohl des NSEC-Eintrags selbst als auch seines entsprechenden RRSIG-Eintrags anzeigen.
2.4. Including DS RRs in a Zone (Einbeziehung von DS-RRs in eine Zone)
Der DS-Ressourceneintrag etabliert Authentifizierungsketten zwischen DNS-Zonen. Ein DS-RRset sollte (SHOULD) an einem Delegationspunkt vorhanden sein, wenn die Kindzone signiert ist. Das DS-RRset kann (MAY) mehrere Einträge enthalten, die jeweils auf einen öffentlichen Schlüssel in der Kindzone verweisen, der zur Verifizierung der RRSIGs in dieser Zone verwendet wird. Alle DS-RRsets in einer Zone müssen (MUST) signiert sein, und DS-RRsets dürfen nicht (MUST NOT) am Apex einer Zone erscheinen.
Ein DS-RR sollte (SHOULD) auf einen DNSKEY-RR zeigen, der im Apex-DNSKEY-RRset des Kindes vorhanden ist, und das Apex-DNSKEY-RRset des Kindes sollte (SHOULD) vom entsprechenden privaten Schlüssel signiert sein.
Die TTL eines DS-RRsets sollte (SHOULD) mit der TTL des delegierenden NS-RRsets übereinstimmen.
2.5. Changes to the CNAME Resource Record (Änderungen am CNAME-Ressourceneintrag)
Wenn ein CNAME-RRset an einem Namen in einer signierten Zone vorhanden ist, sind entsprechende RRSIG- und NSEC-RRsets an diesem Namen erforderlich (REQUIRED). Ein KEY-RRset an diesem Namen für sichere dynamische Aktualisierungszwecke ist ebenfalls zulässig ([RFC3007]). Andere Typen dürfen nicht (MUST NOT) an diesem Namen vorhanden sein.
Dies ist eine Modifikation der ursprünglichen CNAME-Definition in [RFC1034]. Die ursprüngliche Definition des CNAME-RR erlaubte es keinen anderen Typen, mit einem CNAME-Eintrag zu koexistieren, aber eine signierte Zone erfordert NSEC- und RRSIG-RRs für jeden autoritativen Namen.
2.6. DNSSEC RR Types Appearing at Zone Cuts (DNSSEC-RR-Typen an Zonenschnitten)
DNSSEC führte zwei neue RR-Typen ein, die insofern ungewöhnlich sind, als sie auf der elterlichen Seite eines Zonenschnitts erscheinen können. Auf der elterlichen Seite eines Zonenschnitts (d.h. an einem Delegationspunkt) sind NSEC-RRs am Besitzernamen erforderlich (REQUIRED). Ein DS-RR könnte auch vorhanden sein, wenn die delegierte Zone signiert ist und eine Authentifizierungskette zur Elternzone haben möchte.
Diese Spezifikation aktualisiert die ursprüngliche DNS-Spezifikation, um NSEC- und DS-RR-Typen auf der Elternseite eines Zonenschnitts zuzulassen. Diese RRsets sind für die Eltern autoritativ, wenn sie auf der Elternseite eines Zonenschnitts erscheinen.
2.7. Example of a Secure Zone (Beispiel einer sicheren Zone)
Anhang A zeigt ein vollständiges Beispiel einer kleinen signierten Zone.