10. Special Considerations

10.1. Domain Name Length Restrictions

Les zones signées selon cette spécification sont soumises à des contraintes supplémentaires sur la longueur des noms de domaine. En particulier, les zones dont les noms, une fois convertis en noms de titulaires hachés, dépassent la limite de 255 octets imposée par [RFC1035] ne peuvent pas utiliser cette spécification.

La longueur maximale réelle d'un nom de domaine dans une zone donnée dépend à la fois de la longueur du nom de zone (par rapport au nom de domaine complet) et de la fonction de hachage utilisée.

Par exemple, SHA-1 produit un hachage de 160 bits. L'encodage base-32 de 160 bits donne 32 caractères. Ces 32 caractères sont préfixés comme une seule étiquette au nom de la zone, avec un champ longueur d'un octet. La longueur maximale du nom de zone avec SHA-1 est de 222 octets (255 − 33).

10.2. DNAME at the Zone Apex

La spécification DNAME à la section 3 de [RFC2672] comporte une limitation « sans descendants ». Si un RR DNAME est présent au nœud N, il NE DOIT y avoir aucune donnée chez un descendant de N.

Si N est le sommet de zone, des types NSEC3 et RRSIG seront présents chez des descendants de N. Cette spécification met à jour la spécification DNAME pour autoriser les types NSEC3 et RRSIG chez les descendants du sommet, que DNAME soit présent au sommet ou non.

10.3. Iterations

Le nombre d'itérations permet au titulaire de zone de choisir le coût du calcul du hachage, donc le coût de génération d'un dictionnaire. C'est distinct de l'effet du sel, qui empêche l'usage d'un seul dictionnaire précalculé pour toujours.

Le nombre d'itérations influe aussi sur le coût de signature et de service de la zone pour le titulaire, et sur le coût de vérification pour le validateur. Nous imposons donc une limite supérieure fondée sur un nombre d'itérations qui approxime le coût de vérification d'un RRSet.

Les limites se fondent sur la taille de la plus petite clé de signature de zone, arrondie à la valeur de tableau la plus proche (ou arrondie vers le bas si la clé dépasse la plus grande valeur du tableau).

Pour une taille de clé donnée, le titulaire de zone NE DOIT PAS utiliser une valeur d'itérations supérieure au tableau ci-dessous. Après vérification de la signature sur le RR NSEC3, un résolveur PEUT traiter une réponse avec une valeur plus élevée comme non sécurisée.

Key Size	Iterations
1024	150
2048	500
4096	2,500

Ce tableau repose sur une approximation du rapport entre le coût d'un calcul SHA-1 et le coût d'une vérification RSA pour des clés de 1024 bits (150 pour 1), 2048 bits (500 pour 1) et 4096 bits (2500 pour 1).

Le rapport entre SHA-1 et la vérification DSA est plus élevé (1500 pour 1 pour des clés de 1024 bits). Un nombre d'itérations plus élevé dégrade les performances alors que DSA est déjà plus coûteux que RSA pour une même taille de clé. Les valeurs du tableau DOIVENT donc être utilisées quel que soit l'algorithme de clé.

10.4. Transitioning a Signed Zone from NSEC to NSEC3

Lors du passage d'une zone déjà signée et de confiance à cette spécification, il faut éviter les échecs de validation côté client.

La procédure de base est la suivante :

Migrer toutes les DNSKEY vers des DNSKEY utilisant les alias d'algorithme décrits à la section 2. La méthode concrète pour modifier en toute sécurité le RRSet DNSKEY de la zone est hors du périmètre de cette spécification. Le résultat final DOIT être que tous les RR DS dans le parent utilisent les alias d'algorithme indiqués.

Après cette transition, tous les clients NSEC3-unaware traiteront la zone comme non sécurisée. À ce stade, le serveur autoritaire renvoie encore des réponses négatives et joker avec des RR NSEC.
Ajouter des RR NSEC3 signés à la zone, de façon incrémentale ou en une fois. Si l'ajout est incrémental, le dernier RRSet ajouté DOIT être le RRSet NSEC3PARAM.
Dès l'ajout du RRSet NSEC3PARAM, le serveur passe au service des réponses négatives et joker avec des RR NSEC3 conformément à cette spécification.
Retirer les RR NSEC, de façon incrémentale ou en une fois.

10.5. Transitioning a Signed Zone from NSEC3 to NSEC

Pour revenir en toute sécurité à une zone signée DNSSEC [RFC4035], inversez la procédure :

Ajouter les RR NSEC, de façon incrémentale ou en une fois.
Supprimer le RRSet NSEC3PARAM. Le serveur utilisera alors les RR NSEC pour les réponses négatives et joker.
Supprimer les RR NSEC3, de façon incrémentale ou en une fois.
Migrer toutes les DNSKEY vers les identifiants d'algorithme DNSSEC. Après cette transition, les clients NSEC3-unaware traiteront la zone comme sécurisée.