Aller au contenu principal

6. Forme canonique et ordre des enregistrements de ressources

Ce document définit la forme canonique (canonical form) et l'ordre canonique (canonical order) des enregistrements de ressources utilisés pour signer et vérifier les ensembles d'enregistrements de ressources (RRset). L'utilisation d'une forme canonique garantit que la signature reste valide même lorsque la forme de présentation (presentation) de la zone change (par exemple lorsqu'un transfert de zone entre serveurs de noms compresse les noms de domaine ou modifie la casse).

6.1. Forme canonique​

Lors de la signature ou de la vérification d'un enregistrement de ressources, les enregistrements de ressources constituant l'entrée de signature (signature input) DOIVENT être représentés sous forme canonique. La forme canonique d'un enregistrement de ressources est la suivante :

  • le nom du propriétaire (OWNER NAME) DOIT être représenté sous forme de nom de domaine canonique (voir section 6.2) ;
  • toute partie du RDATA ayant la forme d'un nom de domaine DOIT être représentée sous forme de nom de domaine canonique (voir section 6.2) ;
  • si le type d'enregistrement de ressources définit des champs RDATA ayant la forme d'un nom de domaine (par exemple les enregistrements NS, MX, CNAME, SOA, PTR, etc.), ces noms de domaine DOIVENT également être représentés sous forme canonique (sans compression, en minuscules) ;
  • tous les noms de domaine DOIVENT être sans compression ;
  • toute partie de nom de domaine apparaissant sous la forme d'une chaîne de caractères () DOIT être représentée sous forme canonique et NE DOIT PAS être compressée ;
  • pour les types DNSSEC définis dans ce document (DNSKEY, RRSIG, DS, NSEC), le RDATA DOIT être écrit champ par champ en forme binaire, selon le format et l'ordre prescrits aux sections 2, 3, 4 et 5.

Les règles détaillées sont les suivantes :

  1. pour l'enregistrement de ressources DNSKEY : la forme canonique du RDATA est la concaténation, dans l'ordre, des flags (16 bits), du protocole (8 bits), de l'algorithme (8 bits) et de la clé publique (chaîne d'octets en forme ligne) ;
  2. pour l'enregistrement de ressources RRSIG : la forme canonique du RDATA est la concaténation, dans l'ordre, du type couvert, de l'algorithme, du nombre de labels, du TTL d'origine, de l'expiration de la signature, du début de la signature, de la clé étiquette, du nom du signataire (nom de domaine canonique) et de la signature ;
  3. pour l'enregistrement de ressources DS : la forme canonique du RDATA est la concaténation, dans l'ordre, de la clé étiquette, de l'algorithme, du type de condensé et du condensé ;
  4. pour l'enregistrement de ressources NSEC : la forme canonique du RDATA est la concaténation, dans l'ordre, du nom de domaine suivant (forme canonique) et de la carte de bits de type (encodée selon la section 5.1).

6.2. Forme canonique d'un nom de domaine​

La forme canonique (canonical form) d'un nom de domaine est définie comme suit :

  • les caractères US-ASCII dans le nom de domaine DOIVENT être représentés en minuscules (c'est-à-dire, lorsque l'on choisit de ne pas distinguer la casse, utiliser les minuscules). Par exemple, les caractères « A » à « Z » DOIVENT être mis en correspondance avec « a » à « z » ;
  • le nom de domaine DOIT être sans compression (c'est-à-dire ne pas utiliser de pointeurs de compression de labels) ;
  • le nom de domaine DOIT être représenté sous forme ligne (wire format) complète et non compressée, se terminant par un label vide (label de longueur nulle).

6.3. Ordre canonique​

L'ordre canonique des enregistrements de ressources (canonical RR order) sert à déterminer l'ordre relatif des enregistrements de ressources au sein d'un RRset, ainsi que l'ordre des noms et des types dans une zone (utilisé par exemple par les enregistrements NSEC). L'ordre canonique est défini comme suit :

  1. trier d'abord par le nom du propriétaire en forme canonique, sans distinction de casse, en utilisant l'ordre canonique des noms de domaine (voir ci-dessous). Si le nom du propriétaire ne permet pas de départager (c'est-à-dire si les noms sont égaux), passer à l'étape suivante ;

  2. trier ensuite par la classe (CLASS) de l'enregistrement de ressources par ordre numérique croissant (pour DNSSEC, la classe est généralement IN). Si la classe est égale, passer à l'étape suivante ;

  3. trier ensuite par le type (TYPE) de l'enregistrement de ressources par ordre numérique croissant ;

  4. trier enfin, pour les enregistrements à l'intérieur d'un RRset ayant le même nom de propriétaire, la même classe et le même type, par l'ordre binaire du RDATA canonique (canonical RDATA order) croissant :

    • pour les types dont le RDATA contient des noms de domaine, comparer les noms de domaine en forme canonique (sans distinction de casse) ;
    • pour les enregistrements SOA, comparer dans l'ordre des champs MNAME, RNAME, SERIAL, REFRESH, RETRY, EXPIRE, MINIMUM, chaque champ étant comparé en sa forme canonique ;
    • pour les types contenant plusieurs noms de domaine (par exemple un enregistrement MX où une priorité est suivie du nom de domaine cible), comparer d'abord les champs autres que les noms de domaine, puis comparer les noms de domaine en forme canonique ;
    • pour les types DNSSEC définis dans ce document, comparer octet par octet selon l'ordre binaire du RDATA prescrit à la section 6.1.

Ordre canonique des noms de domaine (canonical DNS name order) : deux noms de domaine sont comparés label par label, de la fin (label le plus à droite) vers le début, chaque label étant comparé en ordre d'octets sans distinction de casse. Par exemple, le nom « a.example. » vient avant « b.example. », et « example. » vient avant « a.example. ».

6.4. Traitement de la signature et de la vérification​

Lors de la signature d'un RRset, le signataire DOIT écrire chaque enregistrement de ressources du RRset dans l'entrée de signature selon les formes et l'ordre canoniques des sections 6.1 à 6.3, puis appliquer l'algorithme de signature (voir [RFC4035]). Le validateur DOIT reconstruire l'entrée de signature de la même manière et vérifier la signature.

Navigation entre sections :