4. Der NSEC-Ressourceneintrag (The NSEC Resource Record)
Der NSEC-Ressourceneintrag listet zwei separate Dinge auf: den nächsten Besitzernamen (in der kanonischen Reihenfolge der Zone), der autoritative Daten oder einen NS-RRset eines Delegationspunkts (delegation point) enthält, und die Menge der RR-Typen, die beim Besitzernamen des NSEC RR vorhanden sind [RFC3845]. Die vollständige Menge der NSEC RRs in einer Zone zeigt an, welche autoritativen RRsets in einer Zone existieren, und bildet auch eine Kette von autoritativen Besitzernamen in der Zone. Diese Informationen werden verwendet, um eine authentifizierte Existenzverweigerung (authenticated denial of existence) für DNS-Daten bereitzustellen, wie in [RFC4035] beschrieben.
Da jeder autoritative Name in einer Zone Teil der NSEC-Kette sein muss, MÜSSEN NSEC RRs bei 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 (siehe Abschnitt 3) und NSEC für denselben Namen wie der CNAME-Ressourceneintrag existieren.
Siehe [RFC4035] für eine Diskussion darüber, wie ein Zonensignierer genau bestimmt, welche NSEC RRs er in eine Zone aufnehmen muss.
Der Type-Wert für den NSEC RR-Typ ist 47.
Der NSEC RR ist klassenunabhängig.
Der NSEC RR SOLLTE denselben TTL-Wert wie das SOA Minimum TTL-Feld haben. Dies entspricht dem Geist des negativen Cachings ([RFC2308]).
4.1. NSEC RDATA Wire Format
Das RDATA des NSEC RR ist wie unten gezeigt:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Next Domain Name /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Type Bit Maps /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1.1. Das Next Domain Name-Feld (The Next Domain Name Field)
Das Next Domain-Feld enthält den nächsten Besitzernamen (in der kanonischen Reihenfolge der Zone), der autoritative Daten besitzt oder einen NS-RRset eines Delegationspunkts enthält; siehe Abschnitt 6.1 für eine Erklärung der kanonischen Reihenfolge. Der Wert des Next Domain Name-Feldes im letzten NSEC-Eintrag in der Zone ist der Name der Zonenspitze (zone apex) (der Besitzername des SOA RR der Zone). Dies zeigt an, dass der Besitzername des NSEC RR der letzte Name in der kanonischen Reihenfolge der Zone ist.
Ein Sender DARF NICHT DNS-Namenskompression im Next Domain Name-Feld verwenden, wenn er einen NSEC RR überträgt.
Besitzernamen von RRsets, für die die gegebene Zone nicht autoritativ ist (wie Glue-Einträge), DÜRFEN NICHT im Next Domain Name aufgelistet werden, es sei denn, mindestens ein autoritativer RRset existiert beim selben Besitzernamen.
4.1.2. Das Type Bit Maps-Feld (The Type Bit Maps Field)
Das Type Bit Maps-Feld identifiziert die RRset-Typen, die beim Besitzernamen des NSEC RR existieren.
Der RR-Typraum ist in 256 Fensterblöcke aufgeteilt, von denen jeder die unteren 8 Bits des 16-Bit-RR-Typraums darstellt. Jeder Block, der mindestens einen aktiven RR-Typ hat, wird unter Verwendung eines einzelnen Oktetts Fensternummer (von 0 bis 255), eines einzelnen Oktetts Bitmap-Länge (von 1 bis 32) kodiert, das die Anzahl der für die Bitmap des Fensterblocks verwendeten Oktette angibt, und bis zu 32 Oktetten (256 Bits) Bitmap.
Blöcke sind im NSEC RR RDATA in aufsteigender numerischer Reihenfolge vorhanden.
Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
wobei "|" die Verkettung bezeichnet.
Jede Bitmap kodiert die unteren 8 Bits von RR-Typen innerhalb des Fensterblocks in Netzwerk-Bit-Reihenfolge. Das erste Bit ist Bit 0. Für Fensterblock 0 entspricht Bit 1 dem RR-Typ 1 (A), Bit 2 entspricht dem RR-Typ 2 (NS) und so weiter. Für Fensterblock 1 entspricht Bit 1 dem RR-Typ 257, Bit 2 entspricht dem RR-Typ 258 und so weiter. Wenn ein Bit gesetzt ist, zeigt es an, dass ein RRset dieses Typs für den Besitzernamen des NSEC RR vorhanden ist. Wenn ein Bit gelöscht ist, zeigt es an, dass kein RRset dieses Typs für den Besitzernamen des NSEC RR vorhanden ist.
Bits, die Pseudo-Typen darstellen, MÜSSEN gelöscht sein, da sie nicht in Zonendaten erscheinen. Falls sie auftreten, MÜSSEN sie beim Lesen ignoriert werden.
Blöcke ohne vorhandene Typen DÜRFEN NICHT eingeschlossen werden. Nachgestellte Null-Oktette in der Bitmap MÜSSEN weggelassen werden. Die Länge der Bitmap jedes Blocks wird durch den Typcode mit dem größten numerischen Wert innerhalb dieses Blocks unter der Menge der RR-Typen bestimmt, die beim Besitzernamen des NSEC RR vorhanden sind. Nicht spezifizierte nachgestellte Null-Oktette MÜSSEN als Null-Oktette interpretiert werden.
Die Bitmap für den NSEC RR an einem Delegationspunkt erfordert besondere Aufmerksamkeit. Bits, die dem Delegations-NS-RRset und allen RRsets entsprechen, für die die Elternzone autoritative Daten hat, MÜSSEN gesetzt sein; Bits, die einem Nicht-NS-RRset entsprechen, für das die Elternzone nicht autoritativ ist, MÜSSEN gelöscht sein.
Eine Zone DARF NICHT einen NSEC RR für einen Domänennamen enthalten, der nur Glue-Einträge enthält.
4.1.3. Einbeziehung von Wildcard-Namen in NSEC RDATA (Inclusion of Wildcard Names in NSEC RDATA)
Wenn ein Wildcard-Besitzername in einer Zone erscheint, wird das Wildcard-Label ("*") als literales Symbol behandelt und zum Zweck der Generierung von NSEC RRs genauso behandelt wie jeder andere Besitzername. Wildcard-Besitzernamen erscheinen im Next Domain Name-Feld ohne jegliche Wildcard-Erweiterung. [RFC4035] beschreibt die Auswirkungen von Wildcards auf die authentifizierte Existenzverweigerung.
4.2. NSEC RR Präsentationsformat (The NSEC RR Presentation Format)
Das Präsentationsformat des RDATA-Teils ist wie folgt:
Das Next Domain Name-Feld wird als Domänenname dargestellt.
Das Type Bit Maps-Feld wird als Sequenz von RR-Typ-Mnemoniks dargestellt. Wenn das Mnemonik nicht bekannt ist, MUSS die TYPE-Darstellung wie in Abschnitt 5 von [RFC3597] beschrieben verwendet werden.
4.3. NSEC RR Beispiel (NSEC RR Example)
Der folgende NSEC RR identifiziert die RRsets, die mit alfa.example.com. verbunden sind, und identifiziert den nächsten autoritativen Namen nach alfa.example.com.
alfa.example.com. 86400 IN NSEC host.example.com. (
A MX RRSIG NSEC TYPE1234 )
Die ersten vier Textfelder geben den Namen, TTL, Klasse und RR-Typ (NSEC) an. Der Eintrag host.example.com. ist der nächste autoritative Name nach alfa.example.com. in kanonischer Reihenfolge. Die Mnemoniks A, MX, RRSIG, NSEC und TYPE1234 zeigen an, dass es A-, MX-, RRSIG-, NSEC- und TYPE1234-RRsets gibt, die mit dem Namen alfa.example.com. verbunden sind.
Der RDATA-Abschnitt des obigen NSEC RR würde wie folgt kodiert werden:
0x04 'h' 'o' 's' 't'
0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e'
0x03 'c' 'o' 'm' 0x00
0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x20
Angenommen, ein Validierer kann diesen NSEC-Eintrag authentifizieren, könnte er verwendet werden, um zu beweisen, dass beta.example.com nicht existiert, oder um zu beweisen, dass es keinen AAAA-Eintrag gibt, der mit alfa.example.com. verbunden ist. Die authentifizierte Existenzverweigerung wird in [RFC4035] diskutiert.
Navigation verwandter Kapitel: