8. Validator Considerations

8.1. Responses with Unknown Hash Types

Le validateur DOIT ignorer les RR NSEC3 dont le type de hachage est inconnu. En pratique, les réponses qui ne contiennent que de tels RR NSEC3 seront en général jugées frauduleuses (bogus).

8.2. Verifying NSEC3 RRs

Le validateur DOIT ignorer les RR NSEC3 dont la valeur du champ Flags n'est ni zéro ni un.

Le validateur PEUT traiter une réponse comme frauduleuse si elle contient des RR NSEC3 avec des valeurs différentes d'algorithme de hachage, d'itérations ou de sel pour cette zone.

8.3. Closest Encloser Proof

Pour vérifier une preuve d'encloser le plus proche, le validateur DOIT trouver le nom le plus long X tel que :

X est un ancêtre du QNAME correspondant à un RR NSEC3 présent dans la réponse. C'est un candidat pour l'encloser le plus proche, et
Le nom d'une étiquette de plus que X (tout en restant ancêtre du QNAME ou égal au QNAME) est couvert par un RR NSEC3 présent dans la réponse.

Un algorithme possible est le suivant :

Poser SNAME=QNAME. Effacer le drapeau.
Vérifier si SNAME existe :
- S'il n'y a pas de RR NSEC3 dans la réponse qui correspond à SNAME (c'est-à-dire dont le nom de titulaire est le hachage de SNAME préfixé comme une seule étiquette au nom de la zone), effacer le drapeau.
- S'il y a un RR NSEC3 qui couvre SNAME, positionner le drapeau.
- S'il y a un RR NSEC3 correspondant et que le drapeau est positionné, la preuve est complète et SNAME est l'encloser le plus proche.
- S'il y a un RR NSEC3 correspondant mais que le drapeau n'est pas positionné, la réponse est frauduleuse.
Tronquer SNAME d'une étiquette par la gauche, aller à l'étape 2.

Une fois l'encloser le plus proche trouvé, le validateur DOIT vérifier que le RR NSEC3 dont le nom de titulaire d'origine est l'encloser le plus proche provient de la bonne zone. Le bit de type DNAME NE DOIT PAS être positionné, et le bit NS ne peut être positionné que si le bit SOA l'est. Sinon, un attaquant pourrait les utiliser pour nier à tort l'existence de RR dont le serveur n'est pas autoritaire.

Dans la suite, l'expression « preuve d'encloser le plus proche (prouvable) pour X » signifie que l'algorithme ci-dessus (ou un algorithme équivalent) prouve que X n'existe pas en montrant qu'un ancêtre de X est son encloser le plus proche.

8.4. Validating Name Error Responses

Le validateur DOIT vérifier qu'il existe une preuve d'encloser le plus proche pour le QNAME dans la réponse et qu'il existe un RR NSEC3 couvrant le joker à l'encloser le plus proche (nom formé en préfixant l'étiquette astérisque à l'encloser le plus proche).

8.5. Validating No Data Responses, QTYPE is not DS

Le validateur DOIT vérifier qu'un RR NSEC3 correspondant au QNAME est présent et que les types QTYPE et CNAME ne sont pas positionnés dans son Type Bit Maps.

Ce test couvre aussi le cas où le RR NSEC3 existe en raison d'un non-terminal vide, auquel cas le Type Bit Maps peut être vide.

8.6. Validating No Data Responses, QTYPE is DS

S'il existe un RR NSEC3 correspondant au QNAME dans la réponse, ce RR NSEC3 NE DOIT PAS avoir les bits DS et CNAME positionnés dans son Type Bit Maps.

S'il n'existe pas tel RR NSEC3, le validateur DOIT vérifier qu'une preuve d'encloser le plus proche prouvable pour le QNAME est présente et que le RR NSEC3 couvrant le nom « next closer » a le bit Opt-Out positionné.

8.7. Validating Wildcard No Data Responses

Le validateur DOIT vérifier une preuve d'encloser le plus proche pour le QNAME et DOIT trouver un RR NSEC3 correspondant au nom joker obtenu en préfixant l'étiquette astérisque à l'encloser le plus proche. De plus, les bits QTYPE et CNAME NE DOIVENT PAS être positionnés dans le RR NSEC3 correspondant au joker.

8.8. Validating Wildcard Answer Responses

Le RRSet de réponse joker vérifié fournit au validateur un (candidat) encloser le plus proche pour le QNAME. Cet encloser est l'ancêtre immédiat du joker générateur.

Les validateurs DOIVENT vérifier qu'un RR NSEC3 couvrant le nom « next closer » du QNAME est présent dans la réponse. Cela prouve que le QNAME n'existait pas et que le bon joker a servi à générer la réponse.

8.9. Validating Referrals to Unsigned Subzones

Le nom de délégation dans une référence est le nom de titulaire du RRSet NS dans la section autorité de la réponse de référence.

S'il existe un RR NSEC3 correspondant au nom de délégation, le validateur DOIT s'assurer que le bit NS est positionné et que le bit DS ne l'est pas dans le Type Bit Maps du RR NSEC3. Le validateur DOIT aussi s'assurer que le RR NSEC3 provient de la bonne zone (parent) : le bit SOA ne doit pas être positionné dans le Type Bit Maps de ce RR NSEC3.

La présence du bit NS implique l'absence du bit DNAME ; il n'est pas nécessaire de vérifier le bit DNAME.

S'il n'existe pas de RR NSEC3 correspondant au nom de délégation, le validateur DOIT vérifier une preuve d'encloser le plus proche prouvable pour le nom de délégation et que le bit Opt-Out est positionné dans le RR NSEC3 couvrant le nom « next closer » vers ce nom de délégation.