3. The NSEC3 Resource Record

Le Resource Record (RR) NSEC3 fournit un déni d'existence authentifié pour les Resource Record Sets (RRSets) DNS.

Le RR NSEC3 liste les types de RR présents au nom de titulaire d'origine du RR NSEC3. Il inclut le nom de titulaire haché suivant dans l'ordre de hachage de la zone. L'ensemble complet des RR NSEC3 d'une zone indique quels RRSets existent pour le nom de titulaire d'origine du RR et forme une chaîne de noms de titulaires hachés dans la zone. Ces informations servent à fournir un déni d'existence authentifié pour les données DNS. Pour se prémunir contre l'énumération de zone, les noms de titulaires utilisés dans le RR NSEC3 sont des hachages cryptographiques du nom de titulaire d'origine, préfixés comme une seule étiquette au nom de la zone. Le RR NSEC3 indique quelle fonction de hachage est utilisée pour construire le hachage, quel sel (salt) est employé, et combien d'itérations de la fonction de hachage sont appliquées sur le nom de titulaire d'origine. La technique de hachage est entièrement décrite à la section 5.

Les noms de titulaires hachés des délégations non signées peuvent être exclus de la chaîne. Un RR NSEC3 dont l'intervalle couvre le hachage d'un nom de titulaire ou le nom « next closer » d'une délégation non signée est appelé RR NSEC3 Opt-Out et est signalé par la présence d'un drapeau.

Le nom de titulaire du RR NSEC3 est l'encodage base32 du nom de titulaire haché, préfixé comme une seule étiquette au nom de la zone.

La valeur de type du RR NSEC3 est 50.

Le format RDATA du RR NSEC3 est indépendant de la classe et est décrit ci-dessous.

La classe DOIT être la même que celle du nom de titulaire d'origine.

Le RR NSEC3 DEVRAIT avoir la même valeur TTL que le champ TTL minimum du SOA. C'est dans l'esprit de la mise en cache négative [RFC2308].

3.1. RDATA Fields

3.1.1. Hash Algorithm

Le champ Hash Algorithm identifie l'algorithme de hachage cryptographique utilisé pour construire la valeur de hachage.

Les valeurs de ce champ sont définies dans le registre des algorithmes de hachage NSEC3 défini à la section 11.

3.1.2. Flags

Le champ Flags contient 8 drapeaux d'un bit pouvant indiquer des traitements distincts. Tous les drapeaux non définis doivent être à zéro. Le seul drapeau défini par cette spécification est le drapeau Opt-Out.

3.1.2.1. Opt-Out Flag

Si le drapeau Opt-Out est positionné, l'enregistrement NSEC3 couvre zéro ou plusieurs délégations non signées.

Si le drapeau Opt-Out est effacé, l'enregistrement NSEC3 couvre zéro délégation non signée.

Le drapeau Opt-Out indique si ce RR NSEC3 peut couvrir des délégations non signées. C'est le bit le moins significatif du champ Flags. Voir la section 6 pour le détail de l'usage de ce drapeau.

3.1.3. Iterations

Le champ Iterations définit le nombre de fois supplémentaires où la fonction de hachage a été exécutée. Plus d'itérations renforcent la résistance de la valeur de hachage aux attaques par dictionnaire, mais au prix d'un coût de calcul plus élevé pour le serveur et le résolveur. Voir la section 5 pour l'usage de ce champ, et la section 10.3 pour les limites sur la valeur.

3.1.4. Salt Length

Le champ Salt Length définit la longueur du champ Salt en octets, entre 0 et 255.

3.1.5. Salt

Le champ Salt est concaténé au nom de titulaire d'origine avant le hachage afin de se défendre contre les attaques par dictionnaire précalculé. Voir la section 5 pour l'emploi du sel.

3.1.6. Hash Length

Le champ Hash Length définit la longueur du champ Next Hashed Owner Name, entre 1 et 255 octets.

3.1.7. Next Hashed Owner Name

Le champ Next Hashed Owner Name contient le nom de titulaire haché suivant dans l'ordre de hachage. Cette valeur est au format binaire. Étant donné l'ensemble ordonné de tous les noms de titulaires hachés, le champ Next Hashed Owner Name contient le hachage d'un nom de titulaire qui suit immédiatement le nom de titulaire du RR NSEC3 considéré. La valeur du champ Next Hashed Owner Name dans le dernier RR NSEC3 de la zone est identique au nom de titulaire haché du premier RR NSEC3 de la zone dans l'ordre de hachage. Contrairement au nom de titulaire du RR NSEC3, la valeur de ce champ n'inclut pas le nom de zone suffixé.

3.1.8. Type Bit Maps

Le champ Type Bit Maps identifie les types de RRSet présents au nom de titulaire d'origine du RR NSEC3.

3.2. NSEC3 RDATA Wire Format

Le RDATA du RR NSEC3 est le suivant :

                     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 occupe un octet.

Le champ Flags occupe un octet ; le drapeau Opt-Out est le bit le moins significatif, comme ci-dessous :

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

Iterations est un entier non signé 16 bits, bit de poids fort en premier.

Salt Length est un octet non signé. Il représente la longueur du champ Salt en octets. Si la valeur est zéro, le champ Salt suivant est omis.

Salt, s'il est présent, est encodé comme une suite d'octets binaires. La longueur de ce champ est donnée par le Salt Length précédent.

Hash Length est un octet non signé. Il représente la longueur du champ Next Hashed Owner Name en octets.

Le nom de titulaire haché suivant n'est pas encodé en base32, contrairement au nom de titulaire du RR NSEC3. C'est la valeur de hachage binaire brute. Elle n'inclut pas le nom de la zone conteneur. La longueur de ce champ est donnée par le Hash Length précédent.

3.2.1. Type Bit Maps Encoding

L'encodage du champ Type Bit Maps est le même que pour le RR NSEC, décrit dans [RFC4034]. Il est rappelé et précisé ici pour clarté.

L'espace des types de RR est découpé en 256 fenêtres (window blocks), chacune représentant les 8 bits de poids faible de l'espace des types 16 bits. Chaque fenêtre comportant au moins un type actif est encodée avec un numéro de fenêtre sur un octet (0 à 255), une longueur de bitmap sur un octet (1 à 32) indiquant le nombre d'octets de la bitmap de la fenêtre, et jusqu'à 32 octets (256 bits) de bitmap.

Les blocs apparaissent dans le RDATA du RR NSEC3 par ordre numérique croissant.

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

où « | » désigne la concaténation.

Chaque bitmap encode les 8 bits de poids faible des types RR dans la fenêtre, en ordre de bits réseau. Le premier bit est le bit 0. Pour la fenêtre 0, le bit 1 correspond au type RR 1 (A), le bit 2 au type 2 (NS), etc. Pour la fenêtre 1, le bit 1 correspond au type 257, le bit 2 au type 258. Si un bit vaut 1, un RRSet de ce type est présent au nom de titulaire d'origine du RR NSEC3. Si un bit vaut 0, aucun RRSet de ce type n'est présent au nom de titulaire d'origine du RR NSEC3.

Comme le bit 0 de la fenêtre 0 se rapporte au type RR 0 inexistant, il DOIT être à 0. Après vérification, le validateur DOIT ignorer la valeur du bit 0 de la fenêtre 0.

Les bits représentant des Meta-TYPE ou QTYPE comme spécifié à la section 3.1 de [RFC2929], ou dans la plage réservée uniquement aux QTYPE et Meta-TYPE, DOIVENT être à 0, car ils n'apparaissent pas dans les données de zone. S'ils sont rencontrés, ils doivent être ignorés à la lecture.

Les blocs sans aucun type présent NE DOIVENT PAS être inclus. Les octets de fin à zéro dans la bitmap DOIVENT être omis. La longueur de la bitmap de chaque bloc est déterminée par le code de type de valeur numérique la plus grande, dans ce bloc, parmi les types RR présents au nom de titulaire d'origine du RR NSEC3. Les octets de fin non spécifiés DOIVENT être interprétés comme des octets à zéro.

3.3. Presentation Format

Le format de présentation de la partie RDATA est le suivant :

Le champ Hash Algorithm est représenté comme un entier décimal non signé. La valeur maximale est 255.
Le champ Flags est représenté comme un entier décimal non signé. La valeur maximale est 255.
Le champ Iterations est représenté comme un entier décimal non signé. La valeur est entre 0 et 65535 inclus.
Le champ Salt Length n'est pas représenté.
Le champ Salt est représenté comme une suite de chiffres hexadécimaux sans distinction de cas. Aucun espace n'est autorisé dans la suite. Le champ Salt est représenté par « - » (sans guillemets) lorsque Salt Length vaut 0.
Le champ Hash Length n'est pas représenté.
Le champ Next Hashed Owner Name est représenté comme une suite de chiffres base32 sans remplissage, sans distinction de cas, sans espace.
Le champ Type Bit Maps est représenté comme une suite de mnémoniques de types RR. Lorsque le mnémonique est inconnu, la représentation TYPE décrite à la section 5 de [RFC3597] DOIT être utilisée.