Aller au contenu principal

2. Zone Signing (Signature de zone)

DNSSEC introduit le concept de zones signées (Signed Zones). Une zone signée inclut des enregistrements DNS Public Key (DNSKEY), Resource Record Signature (RRSIG), Next Secure (NSEC), et (optionnellement) Delegation Signer (DS) selon les règles spécifiées dans les sections 2.1, 2.2, 2.3 et 2.4, respectivement. Une zone qui n'inclut pas ces enregistrements selon les règles de cette section est une zone non signée (Unsigned Zone).

DNSSEC nécessite une modification de la définition de l'enregistrement de ressource CNAME ([RFC1035]). La section 2.5 modifie le RR CNAME pour permettre aux RR RRSIG et NSEC d'apparaître au même nom de propriétaire qu'un RR CNAME.

DNSSEC spécifie le placement de deux nouveaux types de RR, NSEC et DS, qui peuvent être placés du côté parental d'une coupure de zone (Zone Cut) (c'est-à-dire, à un point de délégation). C'est une exception à l'interdiction générale de placer des données dans la zone parente à une coupure de zone. La section 2.6 décrit ce changement.

2.1. Including DNSKEY RRs in a Zone (Inclusion des RR DNSKEY dans une zone)​

Pour signer une zone, l'administrateur de la zone génère une ou plusieurs paires de clés publique/privée et utilise la ou les clés privées pour signer les RRsets faisant autorité dans la zone. Pour chaque clé privée utilisée pour créer des RR RRSIG dans une zone, la zone devrait (SHOULD) inclure un RR DNSKEY de zone contenant la clé publique correspondante. Un RR DNSKEY de clé de zone doit (MUST) avoir le bit Zone Key du champ flags RDATA défini (voir Section 2.1.1 de [RFC4034]). Les clés publiques associées à d'autres opérations DNS peuvent (MAY) être stockées dans des RR DNSKEY qui ne sont pas marqués comme clés de zone mais ne doivent pas (MUST NOT) être utilisés pour vérifier les RRSIG.

Si l'administrateur de zone a l'intention qu'une zone signée soit utilisable autrement qu'en tant qu'îlot de sécurité (Island of Security), l'apex de la zone doit (MUST) contenir au moins un RR DNSKEY pour agir comme point d'entrée sécurisé dans la zone. Ce point d'entrée sécurisé pourrait ensuite être utilisé comme cible d'une délégation sécurisée via un RR DS correspondant dans la zone parente (voir [RFC4034]).

2.2. Including RRSIG RRs in a Zone (Inclusion des RR RRSIG dans une zone)​

Pour chaque RRset faisant autorité dans une zone signée, il doit (MUST) y avoir au moins un enregistrement RRSIG qui répond aux exigences suivantes :

  • Le nom de propriétaire RRSIG est égal au nom de propriétaire RRset
  • La classe RRSIG est égale à la classe RRset
  • Le champ Type Covered RRSIG est égal au type RRset
  • Le champ Original TTL RRSIG est égal au TTL du RRset
  • Le TTL du RR RRSIG est égal au TTL du RRset
  • Le champ Labels RRSIG est égal au nombre d'étiquettes dans le nom de propriétaire RRset, sans compter l'étiquette racine nulle et sans compter l'étiquette la plus à gauche si c'est un joker
  • Le champ Signer's Name RRSIG est égal au nom de la zone contenant le RRset
  • Les champs Algorithm, Signer's Name et Key Tag RRSIG identifient un enregistrement DNSKEY de clé de zone à l'apex de la zone

Le processus de construction du RR RRSIG pour un RRset donné est décrit dans [RFC4034]. Un RRset peut (MAY) avoir plusieurs RR RRSIG associés. Notez que les RR RRSIG étant étroitement liés aux RRsets dont ils contiennent les signatures, les RR RRSIG, contrairement à tous les autres types de RR DNS, ne forment pas de RRsets.

Un RR RRSIG lui-même ne doit pas (MUST NOT) être signé, car signer un RR RRSIG n'ajouterait aucune valeur et créerait une boucle infinie dans le processus de signature.

Le RRset NS qui apparaît au nom de l'apex de la zone doit (MUST) être signé, mais les RRsets NS qui apparaissent aux points de délégation (c'est-à-dire, les RRsets NS dans la zone parente qui délèguent le nom aux serveurs de noms de la zone enfant) ne doivent pas (MUST NOT) être signés. Les RRsets d'adresses de collage (Glue) associés aux délégations ne doivent pas (MUST NOT) être signés.

Il doit (MUST) y avoir un RRSIG pour chaque RRset utilisant au moins un DNSKEY de chaque algorithme dans le RRset DNSKEY de l'apex de la zone.

2.3. Including NSEC RRs in a Zone (Inclusion des RR NSEC dans une zone)​

Chaque nom de propriétaire dans la zone qui a des données faisant autorité ou un RRset NS de point de délégation doit (MUST) avoir un enregistrement de ressource NSEC. Le format des RR NSEC et le processus de construction du RR NSEC pour un nom donné sont décrits dans [RFC4034].

La valeur TTL pour tout RR NSEC devrait (SHOULD) être la même que le champ de valeur TTL minimale dans le RR SOA de la zone.

Un enregistrement NSEC (et son RRset RRSIG associé) ne doit pas (MUST NOT) être le seul RRset à un nom de propriétaire particulier. C'est-à-dire que le processus de signature ne doit pas (MUST NOT) créer de RR NSEC ou RRSIG pour des nœuds de nom de propriétaire qui n'étaient pas le nom de propriétaire d'un RRset avant que la zone ne soit signée.

Le bitmap de type de chaque enregistrement de ressource NSEC dans une zone signée doit (MUST) indiquer la présence à la fois de l'enregistrement NSEC lui-même et de son enregistrement RRSIG correspondant.

2.4. Including DS RRs in a Zone (Inclusion des RR DS dans une zone)​

L'enregistrement de ressource DS établit des chaînes d'authentification entre les zones DNS. Un RRset DS devrait (SHOULD) être présent à un point de délégation lorsque la zone enfant est signée. Le RRset DS peut (MAY) contenir plusieurs enregistrements, chacun référençant une clé publique dans la zone enfant utilisée pour vérifier les RRSIG dans cette zone. Tous les RRsets DS dans une zone doivent (MUST) être signés, et les RRsets DS ne doivent pas (MUST NOT) apparaître à l'apex d'une zone.

Un RR DS devrait (SHOULD) pointer vers un RR DNSKEY qui est présent dans le RRset DNSKEY de l'apex de l'enfant, et le RRset DNSKEY de l'apex de l'enfant devrait (SHOULD) être signé par la clé privée correspondante.

Le TTL d'un RRset DS devrait (SHOULD) correspondre au TTL du RRset NS délégant.

2.5. Changes to the CNAME Resource Record (Modifications de l'enregistrement de ressource CNAME)​

Si un RRset CNAME est présent à un nom dans une zone signée, des RRsets RRSIG et NSEC appropriés sont requis (REQUIRED) à ce nom. Un RRset KEY à ce nom pour des besoins de mise à jour dynamique sécurisée est également autorisé ([RFC3007]). D'autres types ne doivent pas (MUST NOT) être présents à ce nom.

C'est une modification de la définition CNAME originale donnée dans [RFC1034]. La définition originale du RR CNAME ne permettait à aucun autre type de coexister avec un enregistrement CNAME, mais une zone signée nécessite des RR NSEC et RRSIG pour chaque nom faisant autorité.

2.6. DNSSEC RR Types Appearing at Zone Cuts (Types de RR DNSSEC apparaissant aux coupures de zone)​

DNSSEC a introduit deux nouveaux types de RR qui sont inhabituels en ce qu'ils peuvent apparaître du côté parental d'une coupure de zone. Du côté parental d'une coupure de zone (c'est-à-dire, à un point de délégation), les RR NSEC sont requis (REQUIRED) au nom de propriétaire. Un RR DS pourrait également être présent si la zone déléguée est signée et cherche à avoir une chaîne d'authentification vers la zone parente.

Cette spécification met à jour la spécification DNS originale pour permettre les types de RR NSEC et DS du côté parent d'une coupure de zone. Ces RRsets font autorité pour le parent lorsqu'ils apparaissent du côté parent d'une coupure de zone.

2.7. Example of a Secure Zone (Exemple de zone sécurisée)​

L'annexe A montre un exemple complet d'une petite zone signée.

Dernière mise à jour le