4. L'enregistrement de ressource NSEC (The NSEC Resource Record)
L'enregistrement de ressource NSEC énumère deux choses distinctes : le nom de propriétaire suivant (dans l'ordre canonique de la zone) qui contient des données faisant autorité ou un RRset NS de point de délégation (delegation point), et l'ensemble des types RR présents au nom de propriétaire du RR NSEC [RFC3845]. L'ensemble complet des RR NSEC dans une zone indique quels RRsets faisant autorité existent dans une zone et forme également une chaîne de noms de propriétaires faisant autorité dans la zone. Ces informations sont utilisées pour fournir un déni d'existence authentifié (authenticated denial of existence) pour les données DNS, comme décrit dans [RFC4035].
Étant donné que chaque nom faisant autorité dans une zone doit faire partie de la chaîne NSEC, des RR NSEC DOIVENT être présents aux noms contenant un RR CNAME. Il s'agit d'un changement par rapport à la spécification DNS traditionnelle [RFC1034], qui stipulait que si un CNAME est présent pour un nom, c'est le seul type autorisé pour ce nom. Dans une zone signée, RRSIG (voir section 3) et NSEC DOIVENT exister au même nom que l'enregistrement de ressource CNAME.
Voir [RFC4035] pour une discussion sur la façon dont un signataire de zone détermine précisément quels RR NSEC il doit inclure dans une zone.
La valeur de type pour le type RR NSEC est 47.
Le RR NSEC est indépendant de la classe.
Le RR NSEC DEVRAIT avoir la même valeur TTL que le champ TTL minimum SOA. Cela est dans l'esprit de la mise en cache négative ([RFC2308]).
4.1. Format de transmission RDATA NSEC (NSEC RDATA Wire Format)
Le RDATA du RR NSEC est tel qu'indiqué ci-dessous :
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. Le champ Next Domain Name (The Next Domain Name Field)
Le champ Next Domain contient le nom de propriétaire suivant (dans l'ordre canonique de la zone) qui possède des données faisant autorité ou contient un RRset NS de point de délégation ; voir la section 6.1 pour une explication de l'ordre canonique. La valeur du champ Next Domain Name dans le dernier enregistrement NSEC de la zone est le nom de l'apex de zone (zone apex) (le nom de propriétaire du RR SOA de la zone). Cela indique que le nom de propriétaire du RR NSEC est le dernier nom dans l'ordre canonique de la zone.
Un émetteur NE DOIT PAS utiliser la compression de nom DNS sur le champ Next Domain Name lors de la transmission d'un RR NSEC.
Les noms de propriétaires des RRsets pour lesquels la zone donnée n'est pas faisant autorité (comme les enregistrements de colle (glue records)) NE DOIVENT PAS être listés dans le Next Domain Name à moins qu'au moins un RRset faisant autorité n'existe au même nom de propriétaire.
4.1.2. Le champ Type Bit Maps (The Type Bit Maps Field)
Le champ Type Bit Maps identifie les types de RRset qui existent au nom de propriétaire du RR NSEC.
L'espace de type RR est divisé en 256 blocs de fenêtre, chacun représentant les 8 bits de poids faible de l'espace de type RR de 16 bits. Chaque bloc ayant au moins un type RR actif est encodé en utilisant un seul octet de numéro de fenêtre (de 0 à 255), un seul octet de longueur de bitmap (de 1 à 32) indiquant le nombre d'octets utilisés pour le bitmap du bloc de fenêtre, et jusqu'à 32 octets (256 bits) de bitmap.
Les blocs sont présents dans le RDATA du RR NSEC dans l'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 le bloc de fenêtre, dans l'ordre des bits réseau. Le premier bit est le bit 0. Pour le bloc de fenêtre 0, le bit 1 correspond au type RR 1 (A), le bit 2 correspond au type RR 2 (NS), et ainsi de suite. Pour le bloc de fenêtre 1, le bit 1 correspond au type RR 257, le bit 2 correspond au type RR 258, et ainsi de suite. Si un bit est défini, cela indique qu'un RRset de ce type est présent pour le nom de propriétaire du RR NSEC. Si un bit est effacé, cela indique qu'aucun RRset de ce type n'est présent pour le nom de propriétaire du RR NSEC.
Les bits représentant les pseudo-types (pseudo-types) DOIVENT être effacés, car ils n'apparaissent pas dans les données de zone. S'ils sont rencontrés, ils DOIVENT être ignorés lors de la lecture.
Les blocs sans types présents NE DOIVENT PAS être inclus. Les octets zéro de fin dans le bitmap DOIVENT être omis. La longueur du bitmap de chaque bloc est déterminée par le code de type avec la valeur numérique la plus élevée, dans ce bloc, parmi l'ensemble des types RR présents au nom de propriétaire du RR NSEC. Les octets zéro de fin non spécifiés DOIVENT être interprétés comme des octets zéro.
Le bitmap pour le RR NSEC à un point de délégation nécessite une attention particulière. Les bits correspondant au RRset NS de délégation et à tous les RRsets pour lesquels la zone parente possède des données faisant autorité DOIVENT être définis ; les bits correspondant à tout RRset non-NS pour lequel le parent n'est pas faisant autorité DOIVENT être effacés.
Une zone NE DOIT PAS inclure un RR NSEC pour tout nom de domaine qui ne contient que des enregistrements de colle.
4.1.3. Inclusion de noms génériques dans NSEC RDATA (Inclusion of Wildcard Names in NSEC RDATA)
Si un nom de propriétaire générique (wildcard) apparaît dans une zone, l'étiquette générique ("*") est traitée comme un symbole littéral et est traitée de la même manière que tout autre nom de propriétaire aux fins de génération des RR NSEC. Les noms de propriétaires génériques apparaissent dans le champ Next Domain Name sans aucune expansion générique. [RFC4035] décrit l'impact des génériques sur le déni d'existence authentifié.
4.2. Format de présentation RR NSEC (The NSEC RR Presentation Format)
Le format de présentation de la partie RDATA est le suivant :
Le champ Next Domain Name est représenté comme un nom de domaine.
Le champ Type Bit Maps est représenté comme une séquence de mnémoniques de types RR. Lorsque le mnémonique n'est pas connu, la représentation TYPE décrite dans la section 5 de [RFC3597] DOIT être utilisée.
4.3. Exemple de RR NSEC (NSEC RR Example)
Le RR NSEC suivant identifie les RRsets associés à alfa.example.com. et identifie le nom faisant autorité suivant après alfa.example.com.
alfa.example.com. 86400 IN NSEC host.example.com. (
A MX RRSIG NSEC TYPE1234 )
Les quatre premiers champs de texte spécifient le nom, le TTL, la classe et le type RR (NSEC). L'entrée host.example.com. est le nom faisant autorité suivant après alfa.example.com. dans l'ordre canonique. Les mnémoniques A, MX, RRSIG, NSEC et TYPE1234 indiquent qu'il existe des RRsets A, MX, RRSIG, NSEC et TYPE1234 associés au nom alfa.example.com.
La section RDATA du RR NSEC ci-dessus serait encodée comme suit :
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
En supposant qu'un validateur puisse authentifier cet enregistrement NSEC, il pourrait être utilisé pour prouver que beta.example.com n'existe pas, ou pour prouver qu'il n'y a pas d'enregistrement AAAA associé à alfa.example.com. Le déni d'existence authentifié est discuté dans [RFC4035].
Navigation des chapitres connexes :