3. Services fournis par la sécurité DNS
Les extensions de sécurité du système de noms de domaine (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 pour le déni authentifié de l'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 d'en-tête de message: Checking Disabled (CD) et Authenticated Data (AD). Afin de prendre en charge les tailles de messages DNS plus grandes résultant de l'ajout des RR DNSSEC, DNSSEC nécessite é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 résolveur conscient de la sécurité puisse indiquer dans ses requêtes qu'il souhaite recevoir des RR DNSSEC dans les messages de réponse.
Ces services protègent contre la plupart des menaces pesant sur le système de noms de domaine décrites dans [RFC3833]. Veuillez consulter la section 12 pour une discussion des limitations de ces extensions.
3.1. 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 cryptographiquement aux RRsets DNS. Ces signatures numériques sont stockées dans un nouvel enregistrement de ressource, l'enregistrement RRSIG. Typiquement, il y aura 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 résolveur 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 serveurs de noms autoritaires de la zone. (Les clés publiques pour les mécanismes d'authentification des transactions DNS peuvent également apparaître dans les zones, comme décrit dans [RFC2931], mais DNSSEC lui-même s'occupe de la sécurité des objets des données DNS, et non de la sécurité des canaux des transactions DNS. Les clés associées à la sécurité des transactions peuvent être stockées dans différents types de RR. Voir [RFC3755] pour plus de détails.)
Un résolveur conscient de la sécurité peut apprendre la clé publique d'une zone soit en ayant une ancre de confiance configurée dans le résolveur, soit par résolution DNS normale. Pour permettre cette dernière, 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 toute sécurité et devraient être stockées hors ligne lorsque cela est pratique. 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 soit par une clé d'authentification configurée, soit par une autre clé qui a été authentifiée précédemment. Les résolveurs conscients de la sécurité authentifient les informations de zone en formant une chaîne d'authentification d'une clé publique nouvellement apprise à une clé publique d'authentification précédemment connue, qui à son tour a été configurée dans le résolveur ou doit avoir été apprise et vérifiée précédemment. Par conséquent, le résolveur 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 résolveur peut avoir à obtenir la clé via une requête DNS. Pour aider les résolveurs conscients de la sécurité à établir cette chaîne d'authentification, les serveurs de noms conscients de la sécurité tentent d'envoyer la ou les signatures nécessaires pour authentifier la ou les clés publiques d'une zone dans le message de réponse DNS avec 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 impliquées dans la signature des délégations à travers les 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 à la ou 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 la ou les clés privées correspondant à une ou plusieurs des clés publiques dans 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 résolveur conscient de la sécurité construit normalement cette chaîne d'authentification de la racine de la hiérarchie DNS jusqu'aux zones feuilles en se basant sur la connaissance configurée de la clé publique de la racine. La politique locale, cependant, peut également permettre à un résolveur 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 racine, peut ne pas fournir de connaissance configurée de la clé publique racine, ou peut empêcher le résolveur 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 par lesquels un résolveur conscient de la sécurité peut déterminer si la signature d'un RRset est "valide" au sens de DNSSEC. Dans l'analyse finale, cependant, l'authentification des clés et des données DNS est une question de 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 une discussion plus approfondie.
3.2. Authentification de la non-existence de nom et de type
Le mécanisme de sécurité décrit dans la section 3.1 ne fournit qu'un moyen de signer les RRsets existants dans une zone. Le problème de la fourniture de 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 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. L'utilisation des enregistrements NSEC nécessite une représentation et un ordre canoniques pour les 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 dans une zone et énumèrent les types de RRsets présents aux noms existants. Chaque enregistrement NSEC est signé et authentifié en utilisant les mécanismes décrits dans la section 3.1.