7. Authoritative Server Considerations

7.1. Zone Signing

Les zones utilisant NSEC3 doivent satisfaire les propriétés suivantes :

Chaque nom de titulaire de la zone qui possède des RRSets autoritaires DOIT avoir un RR NSEC3 correspondant. Les noms de titulaires correspondant à des délégations non signées PEUVENT avoir un RR NSEC3 correspondant. Toutefois, s'il n'y a pas de RR NSEC3 correspondant, il DOIT exister un RR NSEC3 Opt-Out qui couvre le nom « next closer » vers la délégation. Les autres RR non autoritaires ne sont pas représentés par des RR NSEC3.
Chaque non-terminal vide DOIT avoir un RR NSEC3 correspondant, sauf si le non-terminal vide provient uniquement d'une délégation non sécurisée couverte par un RR NSEC3 Opt-Out.
La valeur TTL de tout RR NSEC3 DEVRAIT être la même que le champ TTL minimum du RR SOA de la zone.
Le champ Type Bit Maps de chaque RR NSEC3 d'une zone signée DOIT indiquer la présence de tous les types présents au nom de titulaire d'origine, à l'exception des types uniquement apportés par le RR NSEC3 lui-même. En particulier, le type NSEC3 n'apparaît jamais dans les Type Bit Maps.

Les étapes suivantes décrivent une méthode de construction correcte des RR NSEC3. Ce n'est pas la seule méthode possible.

Choisir l'algorithme de hachage et les valeurs de sel et d'itérations.
Pour chaque nom de titulaire d'origine unique dans la zone, ajouter un RR NSEC3.
- Si Opt-Out est utilisé, les noms de titulaires des délégations non signées PEUVENT être exclus.
- Le nom de titulaire du RR NSEC3 est le hachage du nom de titulaire d'origine, préfixé comme une seule étiquette au nom de la zone.
- Le champ Next Hashed Owner Name est laissé vide pour l'instant.
- Si Opt-Out est utilisé, positionner le bit Opt-Out à 1.
- Pour la détection de collision, suivre optionnellement le nom de titulaire d'origine avec le RR NSEC3.
- De plus, pour la détection de collision, créer optionnellement un RR NSEC3 supplémentaire correspondant au nom de titulaire d'origine avec l'étiquette astérisque préfixée (comme si un joker existait en enfant de ce nom), suivre ce nom de titulaire d'origine, et marquer ce RR NSEC3 comme temporaire.
Pour chaque RRSet au nom de titulaire d'origine, positionner le bit correspondant dans le champ Type Bit Maps.
Si la différence du nombre d'étiquettes entre le sommet et le nom de titulaire d'origine est supérieure à 1, des RR NSEC3 supplémentaires sont nécessaires pour chaque non-terminal vide entre le sommet et le nom de titulaire d'origine. Ce processus peut produire des RR NSEC3 avec des noms de titulaires hachés dupliqués. Optionnellement, pour la détection de collision, suivre les noms de titulaires d'origine de ces RR NSEC3 et créer des RR NSEC3 temporaires pour les collisions de joker de façon analogue à l'étape 1.
Trier l'ensemble des RR NSEC3 selon l'ordre de hachage.
Fusionner les RR NSEC3 au nom de titulaire haché identique en les remplaçant par un seul RR NSEC3 dont le champ Type Bit Maps est l'union des types représentés par l'ensemble des RR NSEC3. Si le nom de titulaire d'origine a été suivi, les collisions peuvent être détectées à la fusion, car tous les RR NSEC3 correspondants devraient avoir le même nom de titulaire d'origine. Écarter tout RR NSEC3 temporaire éventuel.
Dans chaque RR NSEC3, insérer le nom de titulaire haché suivant à partir de la valeur du RR NSEC3 suivant dans l'ordre de hachage. Le nom de titulaire haché suivant du dernier RR NSEC3 de la zone contient la valeur du nom de titulaire haché du premier RR NSEC3 dans l'ordre de hachage.
Enfin, ajouter un RR NSEC3PARAM au sommet de zone avec les mêmes champs Hash Algorithm, Iterations et Salt.

Si une collision de hachage est détectée, il faut choisir un nouveau sel et recommencer le processus de signature.

7.2. Zone Serving

Cette spécification modifie les réponses DNS avec DNSSEC générées par les serveurs autoritaires. En particulier, elle remplace l'usage des RR NSEC dans ces réponses par des RR NSEC3.

Dans les cas de réponse suivants, les RR NSEC prescrits par DNSSEC [RFC4035] sont remplacés par des RR NSEC3 qui prouvent les mêmes faits. Les réponses qui ne contiendraient pas de RR NSEC restent inchangées.

Lorsque plusieurs RR NSEC3 sont renvoyés, tous DOIVENT utiliser les mêmes algorithme de hachage, itérations et sel. La valeur du champ Flags DOIT être zéro ou un.

7.2.1. Closest Encloser Proof

Pour de nombreuses réponses NSEC3, une preuve de l'encloser le plus proche (closest encloser) est requise. Il s'agit de prouver qu'un ancêtre du QNAME est l'encloser le plus proche du QNAME.

Cette preuve consiste en (au plus) deux RR NSEC3 distincts :

Un RR NSEC3 qui correspond à l'encloser le plus proche (prouvable).
Un RR NSEC3 qui couvre le nom « next closer » vers l'encloser le plus proche.

Le premier RR NSEC3 propose essentiellement un encloser le plus proche candidat et prouve que cet encloser existe bien. Le second prouve que l'encloser candidat est bien le plus proche, et que le QNAME (et tout ancêtre entre le QNAME et l'encloser le plus proche) n'existe pas.

Ces RR NSEC3 sont collectivement appelés la « preuve d'encloser le plus proche » dans la suite.

Par exemple, la preuve d'encloser le plus proche pour le nom de titulaire inexistant « alpha.beta.gamma.example. » peut prouver que « gamma.example. » est l'encloser le plus proche. La réponse contiendrait le RR NSEC3 correspondant à « gamma.example. », et aussi le RR NSEC3 couvrant « beta.gamma.example. » (le nom « next closer »).

Avec Opt-Out (section 6), il peut être impossible de prouver l'encloser le plus proche réel parce qu'il fait partie ou est couvert par une portée Opt-Out sur une délégation non sécurisée. Dans ce cas, on utilise l'encloser le plus proche prouvable au lieu de l'encloser réel. Autrement dit, on utilise le nom autoritaire englobant le plus proche. L'ensemble de RR NSEC3 utilisé pour cette preuve est alors appelé « preuve d'encloser le plus proche prouvable ».

7.2.2. Name Error Responses

Pour prouver la non-existence du QNAME, la réponse DOIT inclure une preuve d'encloser le plus proche et un RR NSEC3 couvrant le RR joker (inexistant) à l'encloser le plus proche. Cette collection d'au plus trois RR NSEC3 prouve à la fois que le QNAME n'existe pas et qu'aucun joker susceptible de correspondre au QNAME n'existe non plus.

Par exemple, si « gamma.example. » est l'encloser le plus proche prouvable du QNAME, un RR NSEC3 couvrant « *.gamma.example. » est inclus dans la section autorité de la réponse.

7.2.3. No Data Responses, QTYPE is not DS

Le serveur DOIT inclure le RR NSEC3 qui correspond au QNAME. Ce RR NSEC3 NE DOIT PAS avoir les bits correspondant au QTYPE ni à CNAME positionnés dans son champ Type Bit Maps.

7.2.4. No Data Responses, QTYPE is DS

S'il existe un RR NSEC3 correspondant au QNAME, le serveur DOIT le renvoyer dans la réponse. Les bits DS et CNAME NE DOIVENT PAS être positionnés dans le Type Bit Maps de ce RR NSEC3.

S'il n'existe pas de RR NSEC3 correspondant au QNAME, le serveur DOIT renvoyer une preuve d'encloser le plus proche prouvable pour le QNAME. Le RR NSEC3 couvrant le nom « next closer » DOIT avoir le bit Opt-Out positionné (c'est vrai par définition ; sinon quelque chose est incorrect).

Si le serveur est autoritaire des deux côtés d'une coupure de zone au QNAME, le serveur DOIT renvoyer la preuve depuis le côté parent de la coupure.

7.2.5. Wildcard No Data Responses

S'il y a correspondance joker pour le QNAME mais que le QTYPE n'est pas présent à ce nom, la réponse DOIT inclure une preuve d'encloser le plus proche pour le QNAME et DOIT inclure le RR NSEC3 correspondant au joker. Cette combinaison prouve à la fois que le QNAME n'existe pas en lui-même et qu'un joker correspondant au QNAME existe. L'encloser le plus proche du QNAME DOIT être l'ancêtre immédiat du RR joker (sinon quelque chose est incorrect).

7.2.6. Wildcard Answer Responses

S'il y a correspondance joker pour le QNAME et le QTYPE, outre le RRSet joker étendu renvoyé dans la section réponse, il faut renvoyer la preuve que la correspondance joker était valide.

Cette preuve consiste à montrer à la fois que le QNAME n'existe pas et que l'encloser le plus proche du QNAME et l'ancêtre immédiat du joker sont identiques (le bon joker a été utilisé).

À cette fin, le RR NSEC3 couvrant le nom « next closer » de l'ancêtre immédiat du joker DOIT être renvoyé. Il n'est pas nécessaire de renvoyer un RR NSEC3 correspondant à l'encloser le plus proche, car l'existence de cet encloser est prouvée par la présence du joker étendu dans la réponse.

7.2.7. Referrals to Unsigned Subzones

S'il existe un RR NSEC3 correspondant au nom de délégation, ce RR NSEC3 DOIT être inclus dans la réponse. Le bit DS dans les cartes de types du RR NSEC3 NE DOIT PAS être positionné.

Si la zone est Opt-Out, il peut ne pas exister de RR NSEC3 pour la délégation. Dans ce cas, la preuve d'encloser le plus proche prouvable DOIT être incluse dans la réponse. Le RR NSEC3 inclus qui couvre le nom « next closer » pour la délégation DOIT avoir le drapeau Opt-Out à un (sauf erreur).

7.2.8. Responding to Queries for NSEC3 Owner Names

Les noms de titulaires des RR NSEC3 ne figurent pas dans la chaîne NSEC3 comme les autres noms. Chaque nom de titulaire NSEC3 est donc couvert par un autre RR NSEC3, ce qui nie en principe l'existence du RR NSEC3. C'est paradoxal, car l'existence d'un RR NSEC3 peut être prouvée par son RRSet RRSIG.

Si toutes les conditions suivantes sont vraies :

le QNAME est égal au nom de titulaire d'un RR NSEC3 existant, et
aucun type de RR n'existe au QNAME ni chez aucun descendant du QNAME,

alors la réponse DOIT être construite comme une réponse d'erreur de nom (section 7.2.2). Autrement dit, le serveur de noms autoritaire se comporte comme si le nom de titulaire du RR NSEC3 n'existait pas.

Les RR NSEC3 sont toutefois renvoyés suite à une requête AXFR ou IXFR.

7.2.9. Server Response to a Run-Time Collision

Si le hachage d'un QNAME inexistant entre en collision avec le nom de titulaire d'un RR NSEC3 existant, le serveur ne peut pas renvoyer de réponse prouvant que le QNAME n'existe pas. Dans ce cas, le serveur DOIT renvoyer une réponse avec un RCODE de 2 (défaillance du serveur).

Avec l'algorithme de hachage SHA-1 spécifié dans ce document, de telles collisions sont hautement improbables.

7.3. Secondary Servers

Les serveurs secondaires (et peut-être d'autres entités) doivent déterminer de façon fiable quels paramètres NSEC3 (hachage, sel, itérations) sont présents à chaque nom de titulaire haché, afin de choisir un ensemble approprié de RR NSEC3 pour les réponses négatives. Cela est indiqué par un RR NSEC3PARAM présent au sommet de zone.

S'il existe plusieurs RR NSEC3PARAM, plusieurs chaînes NSEC3 valides coexistent. Le serveur doit en choisir une, selon tout critère.

7.4. Zones Using Unknown Hash Algorithms

Les zones signées selon cette spécification mais utilisant une valeur d'algorithme de hachage NSEC3 non reconnue ne peuvent pas être servies correctement. De telles zones DEVRAIENT être rejetées au chargement. Les serveurs DEVRAIENT répondre avec RCODE=2 (défaillance) pour les requêtes tombant sous ces zones.

7.5. Dynamic Update

Une zone signée avec NSEC3 peut accepter les mises à jour dynamiques [RFC2136]. Toutefois, NSEC3 pose des considérations particulières.

L'ajout et la suppression de noms dans une zone DOIT tenir compte de la création ou de la suppression des non-terminaux vides.

Lors de la suppression d'un nom avec RR NSEC3 correspondant, tout RR NSEC3 correspondant aux non-terminaux vides créés par ce nom DOIT être supprimé. Plus d'un nom peut affirmer l'existence d'un même non-terminal vide.
Lors de l'ajout d'un nom nécessitant un RR NSEC3, des RR NSEC3 DOIVENT aussi être ajoutés pour tout non-terminal vide créé. S'il n'existe pas de RR NSEC3 correspondant à un non-terminal vide, il doit être créé et ajouté.

La présence d'Opt-Out signifie que certains ajouts ou délégations de noms ne nécessiteront pas de modifier les RR NSEC3 de la zone.

Lors de la suppression d'un RRSet de délégation, si la délégation n'a pas de RR NSEC3 correspondant, elle était en opt-out. Rien d'autre n'est alors requis.
Lors de l'ajout d'un RRSet de délégation, si le nom « next closer » de la délégation est couvert par un RR NSEC3 Opt-Out existant, la délégation PEUT être ajoutée sans modifier les RR NSEC3 de la zone.

La présence d'Opt-Out rend ambiguë la valeur du drapeau Opt-Out à positionner sur les RR NSEC3 nouveaux ou modifiés. Les serveurs DEVRAIENT suivre les règles de base suivantes.

L'idée centrale est de préserver l'état du drapeau Opt-Out du RR NSEC3 couvrant.

Lors de la suppression d'un RR NSEC3, la valeur du drapeau Opt-Out du RR NSEC3 précédent (celui dont le nom de titulaire haché suivant est modifié) ne devrait pas changer.
Lors de l'ajout d'un RR NSEC3, la valeur du drapeau Opt-Out est celle du RR NSEC3 qui couvrait auparavant le nom de titulaire du nouveau RR NSEC3, c'est-à-dire l'ancien RR NSEC3 « précédent ».

Si la zone est cohérente dans son usage du drapeau Opt-Out (tous les RR NSEC3 ont la même valeur), ces règles préservent cette cohérence. Si la zone est partiellement Opt-Out, elles ne préservent pas nécessairement le même schéma d'usage du drapeau.

Pour les zones partiellement Opt-Out, si un schéma logique existe, une politique locale sur le serveur peut le maintenir.