Aller au contenu principal

3. Serving (Service)

Cette section décrit le comportement des entités qui incluent des fonctions de serveur de noms sensible à la sécurité. Dans de nombreux cas, ces fonctions feront partie d'un serveur de noms récursif sensible à la sécurité, mais un serveur de noms faisant autorité sensible à la sécurité a certaines des mêmes exigences.

Un serveur de noms sensible à la sécurité doit (MUST) prendre en charge l'extension de taille de message EDNS0 ([RFC2671]), doit (MUST) prendre en charge une taille de message d'au moins 1220 octets, et devrait (SHOULD) prendre en charge une taille de message de 4000 octets.

Un serveur de noms sensible à la sécurité qui reçoit une requête DNS qui n'inclut pas le pseudo-RR OPT EDNS ou dont le bit DO est effacé doit (MUST) traiter les RR RRSIG, DNSKEY et NSEC comme il le ferait pour tout autre RRset et ne doit pas (MUST NOT) effectuer les traitements supplémentaires décrits ci-dessous.

DNSSEC alloue deux nouveaux bits dans l'en-tête du message DNS :

  • Bit CD (Checking Disabled) : Contrôlé par les résolveurs
  • Bit AD (Authentic Data) : Contrôlé par les serveurs de noms

Un serveur de noms sensible à la sécurité doit (MUST) copier le bit CD d'une requête dans la réponse correspondante. Un serveur de noms sensible à la sécurité doit (MUST) ignorer le paramétrage du bit AD dans les requêtes.

3.1. Authoritative Name Servers (Serveurs de noms faisant autorité)​

Lors de la réception d'une requête pertinente dont le bit DO du pseudo-RR OPT EDNS est défini, un serveur de noms faisant autorité sensible à la sécurité pour une zone signée doit (MUST) inclure des RR RRSIG, NSEC et DS supplémentaires, selon les règles suivantes :

  • Les RR RRSIG qui peuvent être utilisés pour authentifier une réponse doivent (MUST) être inclus dans la réponse selon les règles de la section 3.1.1
  • Les RR NSEC qui peuvent être utilisés pour fournir un déni d'existence authentifié doivent (MUST) être inclus automatiquement dans la réponse selon les règles de la section 3.1.3
  • Soit un RRset DS soit un RR NSEC prouvant qu'aucun RR DS n'existe doit (MUST) être inclus automatiquement dans les délégations selon les règles de la section 3.1.4

3.1.1. Including RRSIG RRs in a Response (Inclusion des RR RRSIG dans une réponse)​

Lors de la réponse à une requête dont le bit DO est défini, un serveur de noms faisant autorité sensible à la sécurité devrait (SHOULD) tenter d'envoyer des RR RRSIG qu'un résolveur sensible à la sécurité peut utiliser pour authentifier les RRsets dans la réponse.

Règles :

  • Lors du placement d'un RRset signé dans la section Answer, le serveur de noms doit (MUST) également placer ses RR RRSIG dans la section Answer
  • Lors du placement d'un RRset signé dans la section Authority, le serveur de noms doit (MUST) également placer ses RR RRSIG dans la section Authority
  • Lors du placement d'un RRset signé dans la section Additional, le serveur de noms doit (MUST) également placer ses RR RRSIG dans la section Additional
  • Si l'espace ne permet pas l'inclusion des RR RRSIG dans les sections Answer ou Authority, le serveur de noms doit (MUST) définir le bit TC

3.1.2. Including DNSKEY RRs in a Response (Inclusion des RR DNSKEY dans une réponse)​

Lors de la réponse à une requête dont le bit DO est défini et qui demande les RR SOA ou NS à l'apex d'une zone signée, un serveur de noms faisant autorité sensible à la sécurité pour cette zone peut (MAY) retourner le RRset DNSKEY de l'apex de la zone dans la section Additional.

Le RRset DNSKEY et les RR RRSIG associés ont une priorité inférieure à toute autre information qui serait placée dans la section Additional.

3.1.3. Including NSEC RRs in a Response (Inclusion des RR NSEC dans une réponse)​

Lors de la réponse à une requête dont le bit DO est défini, un serveur de noms faisant autorité sensible à la sécurité pour une zone signée doit (MUST) inclure des RR NSEC dans chacun des cas suivants :

No Data (Pas de données) : La zone contient des RRsets qui correspondent exactement à <SNAME, SCLASS> mais ne contient aucun RRset qui correspond exactement à <SNAME, SCLASS, STYPE>.

Name Error (Erreur de nom) : La zone ne contient aucun RRset qui correspond à <SNAME, SCLASS> exactement ou via l'expansion de nom joker.

Wildcard Answer (Réponse joker) : La zone ne contient aucun RRset qui correspond exactement à <SNAME, SCLASS> mais contient un RRset qui correspond à <SNAME, SCLASS, STYPE> via l'expansion de nom joker.

Wildcard No Data (Joker sans données) : La zone ne contient aucun RRset qui correspond exactement à <SNAME, SCLASS> et contient un ou plusieurs RRsets qui correspondent à <SNAME, SCLASS> via l'expansion de nom joker, mais ne contient aucun RRset qui correspond à <SNAME, SCLASS, STYPE> via l'expansion de nom joker.

3.1.3.1. Including NSEC RRs: No Data Response (Inclusion de RR NSEC : Réponse sans données)​

Si la zone contient des RRsets correspondant à <SNAME, SCLASS> mais ne contient aucun RRset correspondant à <SNAME, SCLASS, STYPE>, alors le serveur de noms doit (MUST) inclure le RR NSEC pour <SNAME, SCLASS> avec ses RR RRSIG associés dans la section Authority.

3.1.3.2. Including NSEC RRs: Name Error Response (Inclusion de RR NSEC : Réponse d'erreur de nom)​

Si la zone ne contient aucun RRset correspondant à <SNAME, SCLASS> exactement ou via l'expansion de nom joker, alors le serveur de noms doit (MUST) inclure les RR NSEC suivants dans la section Authority :

  • Un RR NSEC prouvant qu'il n'y a pas de correspondance exacte pour <SNAME, SCLASS>
  • Un RR NSEC prouvant que la zone ne contient aucun RRset qui correspondrait à <SNAME, SCLASS> via l'expansion de nom joker

3.1.3.3. Including NSEC RRs: Wildcard Answer Response (Inclusion de RR NSEC : Réponse joker)​

Si la zone ne contient aucun RRset qui correspond exactement à <SNAME, SCLASS> mais contient un RRset qui correspond à <SNAME, SCLASS, STYPE> via l'expansion de nom joker, le serveur de noms doit (MUST) inclure la réponse étendue par joker et les RR RRSIG étendus par joker correspondants dans la section Answer et doit (MUST) inclure dans la section Authority un RR NSEC prouvant que la zone ne contient pas de correspondance plus proche.

3.1.3.4. Including NSEC RRs: Wildcard No Data Response (Inclusion de RR NSEC : Réponse joker sans données)​

Le serveur de noms doit (MUST) inclure les RR NSEC suivants dans la section Authority :

  • Un RR NSEC prouvant qu'il n'y a pas de RRsets correspondant à STYPE au nom de propriétaire joker
  • Un RR NSEC prouvant qu'il n'y a pas de RRsets dans la zone qui auraient été une correspondance plus proche

3.1.4. Including DS RRs in a Response (Inclusion des RR DS dans une réponse)​

Les RR DS ne sont présents qu'aux points de délégation. Le RR DS à un point de délégation établit la chaîne d'authentification dans la zone enfant. Un serveur de noms sensible à la sécurité renvoyant une délégation doit (MUST) tenter de retourner le RRset DS avec ses RR RRSIG associés dans la section Authority.

Si un RRset DS n'existe pas au point de délégation, le serveur de noms doit (MUST) retourner un RR NSEC qui prouve que le RRset DS n'existe pas.

3.1.5. Responding to Queries for Type AXFR or IXFR (Réponse aux requêtes de type AXFR ou IXFR)​

DNSSEC ne modifie pas le protocole de transfert de zone DNS. Un serveur de noms faisant autorité sensible à la sécurité doit (MUST) inclure les RR DNSSEC appropriés (RR RRSIG, NSEC, DS et DNSKEY) dans les transferts de zone.

3.1.6. The AD and CD Bits in an Authoritative Response (Les bits AD et CD dans une réponse faisant autorité)​

Un serveur de noms faisant autorité sensible à la sécurité doit (MUST) effacer le bit AD dans les réponses à moins que le serveur de noms ne fasse autorité pour la zone qui contient tous les RRsets dans les sections Answer et Authority et que tous les RR RRSIG et NSEC nécessaires soient inclus.

Un serveur de noms faisant autorité sensible à la sécurité doit (MUST) copier le bit CD de la requête vers la réponse.

3.2. Recursive Name Servers (Serveurs de noms récursifs)​

Un serveur de noms récursif sensible à la sécurité est une entité qui agit comme un résolveur sensible à la sécurité (voir Section 4) et fournit également un service de requête sensible à la sécurité à d'autres résolveurs ou résolveurs stub.

3.2.1. The DO Bit (Le bit DO)​

Un serveur de noms récursif sensible à la sécurité doit (MUST) définir le bit DO dans les requêtes qu'il envoie aux serveurs de noms faisant autorité lorsque le bit DO était défini dans la requête reçue par le serveur de noms récursif.

3.2.2. The CD Bit (Le bit CD)​

Le bit CD (Checking Disabled) contrôle si un serveur de noms récursif sensible à la sécurité effectue la validation DNSSEC. Lorsque le bit CD est défini, un serveur de noms récursif sensible à la sécurité ne devrait pas (SHOULD NOT) effectuer la validation DNSSEC mais devrait (SHOULD) toujours récupérer les RR DNSSEC.

3.2.3. The AD Bit (Le bit AD)​

Le bit AD (Authentic Data) indique si les données dans les sections Answer et Authority ont été vérifiées par un résolveur sensible à la sécurité conformément aux politiques de la politique de sécurité locale de ce résolveur.

Un serveur de noms récursif sensible à la sécurité doit (MUST) définir le bit AD dans une réponse si :

  • Les RRsets dans les sections Answer et Authority ont été validés avec succès
  • Ou la réponse a été reçue avec le bit AD défini d'un serveur en amont qui est approuvé

3.3. Example DNSSEC Responses (Exemples de réponses DNSSEC)​

L'annexe B contient des exemples détaillés de réponses DNSSEC pour divers scénarios incluant :

  • Réponses positives
  • Erreurs de nom
  • Erreurs sans données
  • Délégations vers des zones signées et non signées
  • Extensions par joker
Dernière mise à jour le