6. Opt-Out

6. Opt-Out

Dans cette spécification, comme dans [RFC4033], [RFC4034] et [RFC4035], les RRSets NS aux points de délégation ne sont pas signés et peuvent être accompagnés d'un RRSet DS. Lorsque le bit Opt-Out est effacé, l'état de sécurité de la zone enfant est déterminé par la présence ou l'absence de ce RRSet DS, prouvé cryptographiquement par le RR NSEC3 signé au nom de titulaire haché de la délégation. Positionner le drapeau Opt-Out modifie ce comportement en autorisant des délégations non sécurisées dans la zone signée sans RR NSEC3 correspondant au nom de titulaire haché de la délégation.

On dit qu'un RR NSEC3 Opt-Out couvre une délégation si le hachage du nom de titulaire ou le nom « next closer » de la délégation se situe entre le nom de titulaire du RR NSEC3 et le nom de titulaire haché suivant.

Un RR NSEC3 Opt-Out n'affirme ni l'existence ni la non-existence des délégations non sécurisées qu'il peut couvrir. Cela permet d'ajouter ou de retirer ces délégations sans recalculer ni re-signer les RR de la chaîne NSEC3. En revanche, les RR NSEC3 Opt-Out affirment bien l'(in)existence des autres RRSets autoritaires.

Un RR NSEC3 Opt-Out PEUT avoir le même nom de titulaire d'origine qu'une délégation non sécurisée. Dans ce cas, la délégation est prouvée non sécurisée par l'absence du bit DS dans la carte de types, et le RR NSEC3 signé affirme bien l'existence de la délégation.

Les zones utilisant Opt-Out PEUVENT mélanger des RR NSEC3 Opt-Out et non Opt-Out. Si un RR NSEC3 n'est pas Opt-Out, il NE DOIT PAS y avoir de noms de titulaires hachés de délégations non sécurisées (ni d'autres RR) entre lui et le nom indiqué par le nom de titulaire haché suivant dans le RDATA NSEC3. S'il est Opt-Out, il DOIT uniquement couvrir des noms de titulaires hachés ou des noms « next closer » hachés de délégations non sécurisées.

Les effets du drapeau Opt-Out sur la signature, le service et la validation des réponses sont traités dans les sections suivantes.