3. Services Provided by DNS Security (Services fournis par la sécurité DNS)
Les extensions de sécurité du Domain Name System (DNS) fournissent des services d'authentification de l'origine et d'assurance de l'intégrité pour les données DNS, y compris des mécanismes de preuve authentifiée de la non-existence de données DNS. Ces mécanismes sont décrits ci-dessous.
Ces mécanismes nécessitent des modifications du protocole DNS. DNSSEC ajoute quatre nouveaux types d'enregistrements de ressources : Resource Record Signature (RRSIG), DNS Public Key (DNSKEY), Delegation Signer (DS) et Next Secure (NSEC). Il ajoute également deux nouveaux bits dans l'en-tête des messages : Checking Disabled (CD) et Authenticated Data (AD). Afin de prendre en charge les tailles de messages DNS plus importantes résultant de l'ajout des RR DNSSEC, DNSSEC requiert également la prise en charge d'EDNS0 ([RFC2671]). Enfin, DNSSEC nécessite la prise en charge du bit d'en-tête EDNS DNSSEC OK (DO) ([RFC3225]) afin qu'un resolver conscient de la sécurité puisse indiquer dans ses requêtes qu'il souhaite recevoir les RR DNSSEC dans les messages de réponse.
Ces services protègent contre la plupart des menaces pesant sur le Domain Name System décrites dans [RFC3833]. Veuillez consulter la section 12 pour une discussion des limites de ces extensions.
3.1. Data Origin Authentication and Data Integrity (Authentification de l'origine des données et intégrité des données)
DNSSEC fournit l'authentification en associant des signatures numériques générées de manière cryptographique aux RRsets DNS. Ces signatures numériques sont stockées dans un nouvel enregistrement de ressource, l'enregistrement RRSIG. Il y aura généralement une seule clé privée qui signe les données d'une zone, mais plusieurs clés sont possibles. Par exemple, il peut y avoir des clés pour chacun de plusieurs algorithmes de signature numérique différents. Si un resolver conscient de la sécurité apprend de manière fiable la clé publique d'une zone, il peut authentifier les données signées de cette zone. Un concept DNSSEC important est que la clé qui signe les données d'une zone est associée à la zone elle-même et non aux name servers faisant autorité de la zone. (Les clés publiques pour les mécanismes d'authentification de transaction DNS peuvent également apparaître dans des zones, comme décrit dans [RFC2931], mais DNSSEC concerne lui-même la sécurité objet des données DNS, et non la sécurité de canal des transactions DNS. Les clés associées à la sécurité de transaction peuvent être stockées dans d'autres types de RR. Voir [RFC3755] pour plus de détails.)
Un resolver conscient de la sécurité peut apprendre la clé publique d'une zone soit en ayant une ancre de confiance configurée dans le resolver, soit par une résolution DNS normale. Pour permettre ce dernier cas, les clés publiques sont stockées dans un nouveau type d'enregistrement de ressource, le RR DNSKEY. Notez que les clés privées utilisées pour signer les données de zone doivent être conservées en sécurité et, dans la mesure du possible, stockées hors ligne. Pour découvrir une clé publique de manière fiable via la résolution DNS, la clé cible elle-même doit être signée par une clé d'authentification configurée ou par une autre clé authentifiée précédemment. Les resolvers conscients de la sécurité authentifient les informations de zone en formant une chaîne d'authentification depuis une clé publique nouvellement apprise jusqu'à une clé publique d'authentification connue précédemment, laquelle a à son tour été configurée dans le resolver ou a dû être apprise et vérifiée précédemment. Par conséquent, le resolver doit être configuré avec au moins une ancre de confiance.
Si l'ancre de confiance configurée est une clé de signature de zone, elle authentifiera la zone associée ; si la clé configurée est une clé de signature de clé, elle authentifiera une clé de signature de zone. Si l'ancre de confiance configurée est le hachage d'une clé plutôt que la clé elle-même, le resolver peut devoir obtenir la clé via une requête DNS. Pour aider les resolvers conscients de la sécurité à établir cette chaîne d'authentification, les name servers conscients de la sécurité tentent d'envoyer les signatures nécessaires pour authentifier les clés publiques d'une zone dans le message de réponse DNS, accompagnées de la clé publique elle-même, à condition qu'il y ait de l'espace disponible dans le message.
Le type de RR Delegation Signer (DS) simplifie certaines des tâches administratives liées à la signature de délégations au-delà des frontières organisationnelles. Le RRset DS réside à un point de délégation dans une zone parent et indique la ou les clés publiques correspondant aux clés privées utilisées pour auto-signer le RRset DNSKEY au sommet de la zone enfant déléguée. L'administrateur de la zone enfant, à son tour, utilise les clés privées correspondant à une ou plusieurs des clés publiques de ce RRset DNSKEY pour signer les données de la zone enfant. La chaîne d'authentification typique est donc DNSKEY->[DS->DNSKEY]*->RRset, où « * » désigne zéro ou plusieurs sous-chaînes DS->DNSKEY. DNSSEC permet des chaînes d'authentification plus complexes, telles que des couches supplémentaires de RR DNSKEY signant d'autres RR DNSKEY au sein d'une zone.
Un resolver conscient de la sécurité construit normalement cette chaîne d'authentification depuis la racine de la hiérarchie DNS jusqu'aux zones feuilles, sur la base de la connaissance configurée de la clé publique de la racine. Toutefois, la politique locale peut également permettre à un resolver conscient de la sécurité d'utiliser une ou plusieurs clés publiques configurées (ou hachages de clés publiques) autres que la clé publique de racine, peut ne pas fournir la connaissance configurée de la clé publique de racine, ou peut empêcher le resolver d'utiliser des clés publiques particulières pour des raisons arbitraires, même si ces clés publiques sont correctement signées avec des signatures vérifiables. DNSSEC fournit des mécanismes permettant à un resolver conscient de la sécurité de déterminer si la signature d'un RRset est « valide » au sens de DNSSEC. En dernière analyse, cependant, l'authentification à la fois des clés et des données DNS relève d'une politique locale, qui peut étendre ou même remplacer les extensions de protocole définies dans cet ensemble de documents. Voir la section 5 pour plus de discussion.
3.2. Authenticating Name and Type Non-Existence (Authentification de la non-existence d'un nom et d'un type)
Le mécanisme de sécurité décrit à la section 3.1 ne fournit qu'un moyen de signer les RRsets existants dans une zone. Le problème de fournir des réponses négatives avec le même niveau d'authentification et d'intégrité nécessite l'utilisation d'un autre nouveau type d'enregistrement de ressource, l'enregistrement NSEC. L'enregistrement NSEC permet à un resolver conscient de la sécurité d'authentifier une réponse négative pour la non-existence d'un nom ou d'un type avec les mêmes mécanismes utilisés pour authentifier les autres réponses DNS. L'utilisation d'enregistrements NSEC nécessite une représentation et un ordonnancement canoniques des noms de domaine dans les zones. Les chaînes d'enregistrements NSEC décrivent explicitement les écarts, ou « espaces vides », entre les noms de domaine d'une zone et énumèrent les types de RRsets présents aux noms existants. Chaque enregistrement NSEC est signé et authentifié à l'aide des mécanismes décrits à la section 3.1.