3. The NSEC3 Resource Record (NSEC3-Ressourcendatensatz)

Der NSEC3 Resource Record (RR) liefert eine authentifizierte Verneinung der Existenz für DNS Resource Record Sets (RRSets).

Der NSEC3 RR listet RR-Typen auf, die am ursprünglichen Owner-Namen (original owner name) des NSEC3 RR vorhanden sind. Er enthält den nächsten gehashten Owner-Namen (next hashed owner name) in der Hash-Reihenfolge (hash order) der Zone. Die vollständige Menge der NSEC3 RRs in einer Zone zeigt, welche RRSets am ursprünglichen Owner-Namen des RR existieren, und bildet eine Kette gehashter Owner-Namen in der Zone. Diese Information dient dazu, eine authentifizierte Verneinung der Existenz für DNS-Daten zu liefern. Zum Schutz vor Zonenaufzählung sind die in NSEC3 RRs verwendeten Owner-Namen kryptographische Hashes (cryptographic hashes) des ursprünglichen Owner-Namens, als einzelnes Label dem Zonennamen vorangestellt. Der NSEC3 RR gibt an, welche Hash-Funktion zum Aufbau des Hashs verwendet wird, welches Salt (salt) genutzt wird und wie viele Iterationen (iterations) der Hash-Funktion über den ursprünglichen Owner-Namen ausgeführt werden. Die Hash-Technik wird in Abschnitt 5 vollständig beschrieben.

Gehashte Owner-Namen unsignierter Delegationen können aus der Kette ausgelassen werden. Ein NSEC3 RR, dessen Spanne den Hash eines Owner-Namens oder eines „next closer“-Namens einer unsignierten Delegation abdeckt, wird als Opt-Out-NSEC3 RR bezeichnet und durch das Vorhandensein eines Flags gekennzeichnet.

Der Owner-Name für den NSEC3 RR ist die Base32-Kodierung des gehashten Owner-Namens, als einzelnes Label dem Zonennamen vorangestellt.

Der Typwert für den NSEC3 RR ist 50.

Das NSEC3-RR-RDATA-Format ist klassenunabhängig und wird unten beschrieben.

Die Klasse (class) MUSS dieselbe sein wie die Klasse des ursprünglichen Owner-Namens.

Der NSEC3 RR SOLLTE denselben TTL-Wert wie das Minimum-TTL-Feld der SOA haben. Dies entspricht dem Geist des negativen Cachings (negative caching) [RFC2308].

3.1. RDATA Fields (RDATA-Felder)

3.1.1. Hash Algorithm (Hash-Algorithmus)

Das Feld Hash Algorithm identifiziert den kryptographischen Hash-Algorithmus, der zur Bildung des Hash-Werts (hash-value) verwendet wird.

Die Werte für dieses Feld sind im in Abschnitt 11 definierten NSEC3-Hash-Algorithmus-Register festgelegt.

3.1.2. Flags (Flags)

Das Feld Flags enthält 8 Ein-Bit-Flags, die unterschiedliche Verarbeitung anzeigen können. Alle undefinierten Flags müssen null sein. Das einzige von dieser Spezifikation definierte Flag ist das Opt-Out-Flag.

3.1.2.1. Opt-Out Flag

Ist das Opt-Out-Flag gesetzt, deckt der NSEC3-Datensatz null oder mehr unsignierte Delegationen ab.

Ist das Opt-Out-Flag gelöscht, deckt der NSEC3-Datensatz null unsignierte Delegationen ab.

Das Opt-Out-Flag gibt an, ob dieser NSEC3 RR unsignierte Delegationen abdecken darf. Es ist das niederwertigste Bit im Feld Flags. Details zur Verwendung dieses Flags siehe Abschnitt 6.

3.1.3. Iterations (Iterationen)

Das Feld Iterations definiert die Anzahl zusätzlicher Ausführungen der Hash-Funktion. Mehr Iterationen erhöhen die Widerstandsfähigkeit des Hash-Werts gegen Wörterbuchangriffe (dictionary attacks), aber mit höheren Rechenkosten für Server und Resolver. Details zur Verwendung dieses Feldes siehe Abschnitt 5, Einschränkungen des Wertes siehe Abschnitt 10.3.

3.1.4. Salt Length (Salt-Länge)

Das Feld Salt Length definiert die Länge des Feldes Salt in Oktetten, mit Werten von 0 bis 255.

3.1.5. Salt (Salt)

Das Feld Salt wird dem ursprünglichen Owner-Namen vor dem Hashen angehängt, um gegen vorberechnete Wörterbuchangriffe (pre-calculated dictionary attacks) zu verteidigen. Details zur Salt-Verwendung siehe Abschnitt 5.

3.1.6. Hash Length (Hash-Länge)

Das Feld Hash Length definiert die Länge des Feldes Next Hashed Owner Name, mit Werten von 1 bis 255 Oktetten.

3.1.7. Next Hashed Owner Name (nächster gehashter Owner-Name)

Das Feld Next Hashed Owner Name enthält den nächsten gehashten Owner-Namen in Hash-Reihenfolge. Dieser Wert liegt im Binärformat vor. Gegeben die geordnete Menge aller gehashten Owner-Namen enthält das Feld Next Hashed Owner Name den Hash eines Owner-Namens, der unmittelbar auf den Owner-Namen des gegebenen NSEC3 RR folgt. Der Wert des Feldes Next Hashed Owner Name im letzten NSEC3 RR der Zone ist derselbe wie der gehashte Owner-Name des ersten NSEC3 RR der Zone in Hash-Reihenfolge. Im Gegensatz zum Owner-Namen des NSEC3 RR enthält der Wert dieses Feldes nicht den angehängten Zonennamen.

3.1.8. Type Bit Maps (Typ-Bitmaps)

Das Feld Type Bit Maps identifiziert die RRSet-Typen, die am ursprünglichen Owner-Namen des NSEC3 RR existieren.

3.2. NSEC3 RDATA Wire Format (NSEC3-RDATA-Drahtformat)

Die RDATA des NSEC3 RR ist wie folgt dargestellt:

                     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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Hash Alg.   |     Flags     |          Iterations           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Salt Length  |                     Salt                      /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Hash Length  |             Next Hashed Owner Name            /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                         Type Bit Maps                         /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Hash Algorithm ist ein einzelnes Oktett.

Das Feld Flags ist ein einzelnes Oktett; das Opt-Out-Flag ist das niederwertigste Bit, wie unten gezeigt:

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|             |O|
+-+-+-+-+-+-+-+-+

Iterations wird als 16-Bit-Vorzeichenlose Ganzzahl mit dem höchstwertigen Bit zuerst dargestellt.

Salt Length wird als vorzeichenloses Oktett dargestellt. Salt Length gibt die Länge des Feldes Salt in Oktetten an. Ist der Wert null, wird das folgende Feld Salt weggelassen.

Salt, falls vorhanden, wird als Folge binärer Oktetts kodiert. Die Länge dieses Feldes wird durch das vorhergehende Feld Salt Length bestimmt.

Hash Length wird als vorzeichenloses Oktett dargestellt. Hash Length gibt die Länge des Feldes Next Hashed Owner Name in Oktetten an.

Der nächste gehashte Owner-Name ist im Gegensatz zum Owner-Namen des NSEC3 RR nicht Base32-kodiert. Es ist der unveränderte binäre Hash-Wert. Er enthält nicht den Namen der enthaltenden Zone. Die Länge dieses Feldes wird durch das vorhergehende Feld Hash Length bestimmt.

3.2.1. Type Bit Maps Encoding (Kodierung der Typ-Bitmaps)

Die Kodierung des Feldes Type Bit Maps entspricht der beim NSEC RR verwendeten Kodierung, beschrieben in [RFC4034]. Sie wird hier der Klarheit halber erläutert und präzisiert.

Der RR-Typraum ist in 256 Fensterblöcke (window blocks) unterteilt, die jeweils die niederwertigen 8 Bits des 16-Bit-RR-Typraums darstellen. Jeder Block mit mindestens einem aktiven RR-Typ wird mit einer einzelnen Oktett-Fensternummer (0 bis 255), einer einzelnen Oktett-Bitmap-Länge (1 bis 32), die die Anzahl der Oktetts für die Bitmap des Fensterblocks angibt, und bis zu 32 Oktetts (256 Bits) Bitmap kodiert.

Blöcke stehen in den NSEC3-RR-RDATA in aufsteigender numerischer Reihenfolge.

Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+

wobei „|“ die Verkettung (concatenation) bezeichnet.

Jede Bitmap kodiert die niederwertigen 8 Bits der 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 dem RR-Typ 2 (NS) usw. Für Fensterblock 1 entspricht Bit 1 dem RR-Typ 257, Bit 2 dem RR-Typ 258. Ist ein Bit auf 1 gesetzt, ist ein RRSet dieses Typs am ursprünglichen Owner-Namen des NSEC3 RR vorhanden. Ist ein Bit auf 0 gesetzt, ist kein RRSet dieses Typs am ursprünglichen Owner-Namen des NSEC3 RR vorhanden.

Da Bit 0 in Fensterblock 0 auf den nicht existierenden RR-Typ 0 verweist, MUSS es auf 0 gesetzt sein. Nach der Verifikation MUSS der Validator den Wert von Bit 0 in Fensterblock 0 ignorieren.

Bits, die Meta-TYPEs oder QTYPEs gemäß Abschnitt 3.1 von [RFC2929] darstellen oder in einem nur QTYPEs und Meta-TYPEs vorbehaltenen Bereich liegen, MÜSSEN auf 0 gesetzt sein, da sie nicht in Zonendaten vorkommen. Werden sie angetroffen, MÜSSEN sie beim Lesen ignoriert werden.

Blöcke ohne vorhandene Typen DÜRFEN NICHT enthalten sein. Nachfolgende Null-Oktetts 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 am ursprünglichen Owner-Namen des NSEC3 RR vorhandenen RR-Typen bestimmt. Nicht angegebene nachfolgende Oktetts MÜSSEN als Null-Oktetts interpretiert werden.

3.3. Presentation Format (Darstellungsformat)

Das Darstellungsformat des RDATA-Teils ist wie folgt:

Das Feld Hash Algorithm wird als vorzeichenlose Dezimalzahl dargestellt. Der Wert ist höchstens 255.
Das Feld Flags wird als vorzeichenlose Dezimalzahl dargestellt. Der Wert ist höchstens 255.
Das Feld Iterations wird als vorzeichenlose Dezimalzahl dargestellt. Der Wert liegt zwischen 0 und 65535 einschließlich.
Das Feld Salt Length wird nicht dargestellt.
Das Feld Salt wird als Folge groß-/kleinschreibungsunabhängiger hexadezimaler Ziffern dargestellt. Leerzeichen sind in der Folge nicht erlaubt. Das Feld Salt wird als „-“ (ohne Anführungszeichen) dargestellt, wenn das Feld Salt Length den Wert 0 hat.
Das Feld Hash Length wird nicht dargestellt.
Das Feld Next Hashed Owner Name wird als ungepolsterte Folge groß-/kleinschreibungsunabhängiger Base32-Ziffern ohne Leerzeichen dargestellt.
Das Feld Type Bit Maps wird als Folge von RR-Typ-Mnemonics dargestellt. Ist das Mnemonic unbekannt, MUSS die TYPE-Darstellung gemäß Abschnitt 5 von [RFC3597] verwendet werden.