8. DNSSEC général

La plupart des termes DNSSEC sont définis dans [RFC4033], [RFC4034], [RFC4035] et [RFC5155]. Les termes qui ont causé de la confusion dans la communauté DNS sont mis en évidence ici.

Conscient de DNSSEC et non conscient de DNSSEC (DNSSEC-aware and DNSSEC-unaware): Ces deux termes, qui sont utilisés dans certains RFC, n'ont pas été formellement définis. Cependant, la Section 2 de [RFC4033] définit de nombreux types de résolveurs et validateurs, incluant "non-validating security-aware stub resolver" (résolveur stub conscient de la sécurité non validant), "non-validating stub resolver" (résolveur stub non validant), "security-aware name server" (serveur de noms conscient de la sécurité), "security-aware recursive name server" (serveur de noms récursif conscient de la sécurité), "security-aware resolver" (résolveur conscient de la sécurité), "security-aware stub resolver" (résolveur stub conscient de la sécurité), et "security-oblivious 'anything'" (tout 'inconscient de la sécurité'). (Notez que le terme "validating resolver" (résolveur validant), qui est utilisé à certains endroits dans les documents liés à DNSSEC, n'est également pas défini.)

Zone signée (Signed zone): "Une zone dont les RRsets sont signés et qui contient des enregistrements DNSKEY, Resource Record Signature (RRSIG), Next Secure (NSEC), et (optionnellement) DS correctement construits." (Cité de [RFC4033], Section 2.) Il a été noté dans d'autres contextes que la zone elle-même n'est pas réellement signée, mais tous les RRsets pertinents dans la zone sont signés. Néanmoins, si une zone qui devrait être signée contient des RRsets qui ne sont pas signés (ou exclus), ces RRsets seront traités comme bogus, donc la zone entière doit être gérée d'une manière ou d'une autre.

Il convient également de noter que, depuis la publication de [RFC6840], les enregistrements NSEC ne sont plus requis pour les zones signées: une zone signée pourrait inclure des enregistrements NSEC3 à la place. [RFC7129] fournit un commentaire de fond supplémentaire et un certain contexte pour les mécanismes NSEC et NSEC3 utilisés par DNSSEC pour fournir des réponses de déni d'existence authentifiées.

Zone non signée (Unsigned zone): La Section 2 de [RFC4033] définit ceci comme "une zone qui n'est pas signée". La Section 2 de [RFC4035] définit ceci comme "Une zone qui n'inclut pas ces enregistrements [enregistrements DNSKEY, Resource Record Signature (RRSIG), Next Secure (NSEC), et (optionnellement) DS correctement construits] selon les règles de cette section". Il y a une note importante à la fin de la Section 5.2 de [RFC4035] qui définit une situation supplémentaire dans laquelle une zone est considérée comme non signée: "Si le résolveur ne prend en charge aucun des algorithmes listés dans un RRset DS authentifié, alors le résolveur ne sera pas capable de vérifier le chemin d'authentification vers la zone enfant. Dans ce cas, le résolveur DEVRAIT traiter la zone enfant comme si elle n'était pas signée."

NSEC: "L'enregistrement NSEC permet à un résolveur conscient de la sécurité d'authentifier une réponse négative pour la non-existence de nom ou de type avec les mêmes mécanismes utilisés pour authentifier d'autres réponses DNS." (Cité de [RFC4033], Section 3.2.) En bref, un enregistrement NSEC fournit un déni d'existence authentifié.

"L'enregistrement de ressource NSEC liste deux choses séparées: le nom de propriétaire suivant (dans l'ordre canonique de la zone) qui contient des données autoritaires ou un RRset NS de point de délégation, et l'ensemble des types RR présents au nom de propriétaire du RR NSEC." (Cité de la Section 4 de RFC 4034)

NSEC3: Comme l'enregistrement NSEC, l'enregistrement NSEC3 fournit également un déni d'existence authentifié; cependant, les enregistrements NSEC3 atténuent l'énumération de zone et prennent en charge l'Opt-Out. Les enregistrements de ressource NSEC3 sont définis dans [RFC5155].

Notez que [RFC6840] dit que [RFC5155] "est maintenant considéré comme faisant partie de la famille de documents de sécurité DNS comme décrit par la Section 10 de [RFC4033]". Cela signifie que certaines des définitions des RFC antérieurs qui ne parlent que des enregistrements NSEC devraient probablement être considérées comme parlant à la fois de NSEC et NSEC3.

Opt-out (Exclusion): "Le drapeau Opt-Out indique si ce RR NSEC3 peut couvrir des délégations non signées." (Cité de [RFC5155], Section 3.1.2.1.) L'Opt-out aborde les coûts élevés de sécurisation d'une délégation vers une zone non sécurisée. Lors de l'utilisation de l'Opt-Out, les noms qui sont une délégation non sécurisée (et les non-terminaux vides qui sont uniquement dérivés de délégations non sécurisées) ne nécessitent pas d'enregistrement NSEC3 ou ses enregistrements RRSIG correspondants. Les enregistrements NSEC3 Opt-Out ne sont pas capables de prouver ou nier l'existence des délégations non sécurisées. (Adapté de [RFC7129], Section 5.1)

Énumération de zone (Zone enumeration): "La pratique de découvrir le contenu complet d'une zone via des requêtes successives." (Cité de [RFC5155], Section 1.3.) Ceci est également parfois appelé "zone walking" (parcours de zone). L'énumération de zone est différente de la supposition de contenu de zone où le devineur utilise un grand dictionnaire de labels possibles et envoie des requêtes successives pour eux, ou compare le contenu des enregistrements NSEC3 contre un tel dictionnaire.

Clé de signature de clé (KSK - Key signing key): Des clés DNSSEC qui "signent uniquement le RRset DNSKEY apex dans une zone." (Cité de [RFC6781], Section 3.1)

Clé de signature de zone (ZSK - Zone signing key): "Des clés DNSSEC qui peuvent être utilisées pour signer tous les RRsets dans une zone qui nécessitent des signatures, autres que le RRset DNSKEY apex." (Cité de [RFC6781], Section 3.1) Notez que les rôles KSK et ZSK ne sont pas mutuellement exclusifs: une seule clé peut être à la fois KSK et ZSK en même temps. Notez également qu'une ZSK est parfois utilisée pour signer le RRset DNSKEY apex.

Clé de signature combinée (CSK - Combined signing key): "Dans les cas où la différenciation entre la KSK et la ZSK n'est pas faite, c'est-à-dire où les clés ont le rôle à la fois de KSK et de ZSK, nous parlons d'un schéma de signature de type unique." (Cité de [RFC6781], Section 3.1) Ceci est parfois appelé "combined signing key" (clé de signature combinée) ou CSK. C'est la pratique opérationnelle, et non le protocole, qui détermine si une clé particulière est une ZSK, une KSK ou une CSK.

Point d'entrée sécurisé (SEP - Secure Entry Point): Un drapeau dans le RDATA DNSKEY qui "peut être utilisé pour distinguer entre les clés qui sont destinées à être utilisées comme point d'entrée sécurisé dans la zone lors de la construction de chaînes de confiance, c'est-à-dire qu'elles sont (ou seront) pointées par des RR DS parentaux ou configurées comme ancre de confiance. Par conséquent, il est suggéré que le drapeau SEP soit défini sur les clés qui sont utilisées comme KSK et non sur les clés qui sont utilisées comme ZSK, tandis que dans les cas où une distinction entre une KSK et une ZSK n'est pas faite (c'est-à-dire pour un schéma de signature de type unique), il est suggéré que le drapeau SEP soit défini sur toutes les clés." (Cité de [RFC6781], Section 3.2.3.) Notez que le drapeau SEP n'est qu'un indice, et sa présence ou son absence ne peut pas être utilisée pour disqualifier un RR DNSKEY donné d'être utilisé comme KSK ou ZSK pendant la validation.

Politique DNSSEC (DP - DNSSEC Policy): Une déclaration qui "énonce les exigences de sécurité et les normes à mettre en œuvre pour une zone signée DNSSEC." (Cité de [RFC6841], Section 2)

Déclaration de pratiques DNSSEC (DPS - DNSSEC Practice Statement): "Un document de divulgation de pratiques qui peut soutenir et être un document supplémentaire à la politique DNSSEC (si elle existe), et il énonce comment la gestion d'une zone donnée implémente les procédures et contrôles à un haut niveau." (Cité de [RFC6841], Section 2)