DNSSEC – Qu’est-ce que c’est et pourquoi est-ce important ?
Vous souhaitez en savoir plus sur les extensions de sécurité du système des noms de domaine (DNSSEC) ? Cliquez sur l'image ci-dessous pour explorer notre infographie qui décrit le DNSSEC et les avantages de son déploiement.
Contenu:
Description succincte du fonctionnement du DNS
Pour comprendre les extensions de sécurité du DNS (DNSSEC), il est utile d'avoir une connaissance, ne serait-ce que sommaire, du système des noms de domaine (DNS).
Le bon fonctionnement de l'Internet dépend essentiellement du DNS. Toute consultation de page Web, tout envoi de courriel, tout téléchargement d'image depuis les réseaux sociaux passe par le DNS. Plus précisément, le DNS convertit les noms de domaine faciles à mémoriser par les humains, tels qu'icann.org, en des adresses IP comme 192.0.43.7 et 2001:500:88:200 ::7, indispensables aux serveurs, routeurs et autres dispositifs réseau pour acheminer le trafic Internet vers la bonne destination.
L'utilisation d'Internet, quel que soit le périphérique, commence par une requête DNS. C'est ainsi que lorsqu'un utilisateur saisit le nom d'un site Web dans le navigateur de son téléphone, ce navigateur enclenche en premier lieu la conversion du nom de domaine en adresse IP (protocole Internet). Cette opération est lancée à l'initiative du résolveur minimum du système d'exploitation du dispositif, client DNS très simple, qui relaie la demande de données DNS faite par une application vers une composante plus complexe, dit résolveur récursif, qui n'est autre qu'un serveur DNS. Nombre d'opérateurs de réseaux exploitent des résolveurs récursifs pour traiter les demandes DNS, ou requêtes, envoyées par des dispositifs sur leur réseau. (Les opérateurs et organisations de moindre envergure utilisent parfois des résolveurs récursifs tiers, voire des résolveurs récursifs déployés en tant que service public, tels que Google Public DNS, OpenDNS et Quad9.)
Le résolveur récursif recherche, ou résout, la réponse à la requête DNS envoyée par le résolveur minimum. Pour ce faire, il envoie ses propres requêtes DNS, généralement à différents serveurs de noms faisant autorité. En effet, chaque domaine dispose de données DNS qui lui sont propres et qui sont stockées, quelque part sur Internet, sur un serveur de nom faisant autorité. L'ensemble des données DNS du domaine constituent une « zone ». Si certaines organisations exploitent leurs propres serveurs de noms afin de publier leurs zones, la plupart confient cette fonction à des tiers, notamment des bureaux d'enregistrement, des registres, des sociétés d'hébergement Web et des fournisseurs de serveurs de réseau, qui hébergent les zones DNS pour le compte d'autres entités.
Le DNS en soi n'est pas sécurisé
Le DNS a été créé dans les années 1980, époque à laquelle l'Internet était beaucoup plus restreint ; la sécurité n'était pas une considération primordiale lors de conception. De ce fait, quand un résolveur récursif envoie une requête à un serveur de nom faisant autorité, le résolveur ne dispose d'aucun moyen de vérifier l'authenticité de la réponse. Le résolveur peut uniquement vérifier que la réponse semble bien provenir de la même adresse IP que celle à laquelle il a envoyé la requête originale. Or, se fier à l'adresse IP source d'une réponse est loin d'être suffisant comme mécanisme robuste d'authentification, puisque l'adresse IP source d'un paquet de réponses DNS peut être aisément falsifiée, ou usurpée. Tel que le DNS a été originalement conçu, un résolveur ne peut facilement détecter une réponse falsifiée à l'une de ses requêtes. Un attaquant pourrait aisément se faire passer pour le serveur faisant autorité auquel le résolveur a adressé la requête initiale et, par usurpation du DNS, renvoyer au résolveur une réponse frauduleuse qui semble provenir de ce serveur. En d'autres termes, un attaquant peut rediriger un utilisateur, à l'insu de celui-ci, vers un site potentiellement malveillant.
Afin d'accélérer la résolution des requêtes, les résolveurs récursifs mettent en cache les données DNS reçues des serveurs de noms faisant autorité. Si un résolveur minimum demande des données DNS que le résolveur récursif détient dans son cache, le résolveur récursif peut répondre immédiatement, sans devoir envoyer dans un premier temps une requête à un ou plusieurs serveurs faisant autorité. Toutefois, le recours au cache présente un inconvénient : si un attaquant envoie une réponse DNS falsifiée et que celle-ci est acceptée par un résolveur récursif, l'attaquant a empoisonné le cache du résolveur récursif. Le résolveur renverra alors les données DNS frauduleuses à d'autres dispositifs qui en font la requête.
Prenons, pour illustrer la menace que pose une attaque par empoisonnement du cache, le cas d'un utilisateur qui tente de se connecter au site Web de sa banque. Le périphérique de cet utilisateur envoie, à son serveur de nom récursif configuré, une requête à propos de l'adresse IP du site Web de la banque. Or, un attaquant pourrait avoir empoisonné le résolveur avec une adresse IP qui ne correspond pas au site légitime, mais à un site Web créé par l'attaquant. Ce site Web frauduleux se fait passer pour le site Web de la banque et lui ressemble trait pour trait. L'utilisateur, qui n'a pas conscience de la fraude, saisit son nom et son mot de passe, comme à l'accoutumée. Le résultat est dramatique : sans le vouloir, l'utilisateur a transmis ses identifiants bancaires à l'attaquant ; ce dernier peut dès lors se connecter au site Web officiel de la banque en tant que cet utilisateur pour effectuer des transferts de fonds ou d'autres opérations illicites.
Les extensions de sécurité des noms de domaine
Dans les années 1990, les ingénieurs du Groupe de travail de génie Internet (IETF), l'organisation qui fixe les normes du protocole DNS, se sont rendu compte que le manque d'authentification renforcée du DNS posait problème. Ils ont donc élaboré les extensions de sécurité du système des noms de domaine (DNSSEC).
Le DNSSEC renforce l'authentification du DNS en utilisant des signatures numériques basées sur la cryptographie à clé publique. Avec le DNSSEC, les requêtes DNS et leurs réponses ne sont pas elles-mêmes signées cryptographiquement ; ce sont plutôt les données DNS qui sont signées par leur propriétaire.
Chaque zone DNS possède une paire de clés publique-privée. Le propriétaire de la zone utilise la clé privée de sa zone afin de signer les données DNS dans la zone et de générer des signatures numériques sur ces données. Comme le terme « clé privée » l'indique, cet élément de clé est gardé secret par le propriétaire de la zone. La clé publique de la zone, en revanche, est publiée dans la zone même afin que quiconque puisse l'extraire. Tout résolveur récursif qui cherche des données dans cette zone récupère également la clé publique de la zone, qui lui servira alors à valider l'authenticité des données DNS. Le résolveur confirme que la signature numérique des données DNS qu'il a extraites est valide. En cas de validation réussie, les données DNS sont légitimes et sont renvoyées à l'utilisateur. À défaut de validation réussie, le résolveur suppose qu'il s'agit d'une attaque, rejette les données et renvoie une erreur à l'utilisateur.
Le DNSSEC ajoute deux fonctionnalités importantes au protocole du DNS :
- l'authentification de l'origine des données, laquelle permet au résolveur de vérifier cryptographiquement que les données qu'il a reçues proviennent bien de la zone d'où elles sont censées provenir ;
- la protection de l'intégrité des données, qui permet au résolveur de vérifier que les données n'ont pas été modifiées en cours de transmission, puisqu'elles ont été signées à l'origine par le propriétaire de la zone avec la clé privée de la zone.
Faire confiance aux clés DNSSEC
Chaque zone publie sa clé publique, qu'un résolveur récursif extrait afin de valider les données dans la zone. Mais comment un résolveur peut-il être sûr de l'authenticité de la clé publique d'une zone ? La clé publique d'une zone est signée, à l'instar des autres données de la zone. Toutefois, elle n'est pas signée par la clé privée de la zone, mais par la clé privée de la zone mère. Ainsi, la clé publique de la zone icann.org est signée par la zone org. La zone mère est chargée, en plus de publier une liste des serveurs de noms faisant autorité de la zone enfant, d'attester l'authenticité de la clé publique de sa zone enfant. Chaque clé publique de zone est signée par sa zone mère, sauf celle de la zone racine : elle n'a pas de zone mère chargée de signer sa clé.
La clé publique de la zone racine constitue donc un important point de départ pour la validation des données DNS. Si un résolveur fait confiance à la clé publique de la zone racine, il peut faire confiance aux clés publiques des zones de premier niveau signées par la clé privée de la racine, telles que la clé publique de la zone org. Et comme le résolveur peut faire confiance à la clé publique de la zone org, il peut faire confiance aux clés publiques qui ont été signées par leur clé privée respective, telles que la clé publique d'icann.org. (Dans la pratique actuelle, la zone mère ne signe pas directement la clé de la zone enfant – le mécanisme étant en réalité plus complexe, mais l'effet est le même que si la zone mère avait signé la clé de la zone enfant.)
La séquence de clés cryptographiques signant d'autres clés cryptographiques est appelée chaîne de confiance. La clé publique au début d'une chaîne de confiance est appelée ancre de confiance. Un résolveur possède une liste d'ancres de confiance qui sont des clés publiques pour différentes zones auxquelles le résolveur fait implicitement confiance. La plupart des résolveurs sont configurés avec une seule ancre de confiance : la clé publique de la zone racine. En faisant confiance à cette clé qui se trouve au sommet de la hiérarchie du DNS, un résolveur peut construire une chaîne de confiance jusqu'à n'importe quelle zone de l'espace des noms du DNS dès lors que toutes les zones intermédiaires sont signées.
Valider et signer avec le DNSSEC
Afin de garantir une sécurité généralisée d'Internet, les DNSSEC doivent être largement déployés. Or, loin d'être automatique, l'activation du DNSSEC requiert à l'heure actuelle une action spécifique tant du côté des opérateurs de réseau au niveau de leurs résolveurs récursifs que de celui des propriétaires de noms de domaine au niveau des serveurs faisant autorité pour leur zone. Les opérateurs de résolveurs et de serveurs faisant autorité sont incités de différentes façons à activer le DNSSEC sur leurs systèmes. Lorsqu'ils le font, davantage d'utilisateurs sont assurés de recevoir des réponses authentifiées à leurs requêtes DNS. En d'autres termes, un utilisateur se voit garanti d'arriver à la destination en ligne souhaitée.
La validation DNSSEC est prise en charge depuis longtemps par la quasi-totalité des résolveurs récursifs courants et son activation, très simple, ne nécessite que la modification de quelques lignes du fichier de configuration. Dès lors, lorsqu'un utilisateur demande au résolveur des données DNS qui proviennent de zones signées et que ces données ont été falsifiées, l'utilisateur n'obtiendra (et cela est délibéré) aucune donnée en retour. En détectant l'attaque et en empêchant l'utilisateur de recevoir les données falsifiées, le DNSSEC protège ce dernier contre l'obtention de données falsifiées d'une zone signée.
Signer des zones avec le DNSSEC comporte quelques étapes, mais des millions de zones signent leurs données DNS afin que les utilisateurs de résolveurs validants puissent être assurés d'obtenir des données fiables. Presque tous les logiciels des serveurs de noms faisant autorité courants prennent en charge la signature des zones, et un grand nombre de fournisseurs tiers d'hébergement DNS prennent également en charge le DNSSEC. En règle générale, l'activation du DNSSEC pour une zone auprès d'un fournisseur d'hébergement est relativement simple : bien souvent, il suffit de cocher une case.
Pour qu'un propriétaire de zone déploie le DNSSEC en signant les données de sa zone, la zone mère de celle-ci et sa zone mère, jusqu'à la zone racine, doivent également être signées afin que le DNSSEC soit le plus efficace possible. Une chaîne continue de zones signées commençant au niveau de la zone racine permet à un résolveur de construire une chaîne de confiance à partir de la zone racine afin de valider les données. Par exemple, afin de déployer efficacement le DNSSEC dans la zone icann.org, la zone org doit être signée ainsi que la zone racine. Heureusement, la zone racine du DNS est signée depuis 2010, et tous les domaines génériques de premier niveau (gTLD) ainsi que bon nombre de domaines de premier niveau géographique (ccTLD) le sont également.
La dernière étape du déploiement du DNSSEC dans une zone consiste à transmettre à la zone mère l'élément de clé publique de la zone nouvellement signée. Comme vu précédemment, la zone mère signe la clé publique de la zone enfant et permet la construction d'une chaîne de confiance de la zone mère à la zone enfant.
Aujourd'hui, le propriétaire d'une zone doit généralement communiquer manuellement l'élément de clé publique de cette zone vers la zone mère, souvent via son bureau d'enregistrement. Tout comme le propriétaire d'une zone interagit avec son bureau d'enregistrement afin de procéder à d'autres changements de la zone, tels que la liste des serveurs de noms faisant autorité pour la zone, il interagit également avec le bureau d'enregistrement afin de mettre à jour l'élément de clé publique de la zone. Alors que ce processus est actuellement mené manuellement, les protocoles récemment mis au point devraient permettre à l'avenir d'automatiser ce processus.
Prochaines étapes pour le DNSSEC
Au fur et à mesure du déploiement du DNSSEC, le DNS peut devenir une base pour les autres protocoles qui nécessitent un moyen de stocker des données en toute sécurité. De nouveaux protocoles ont vu le jour, reposant sur le DNSSEC et ne fonctionnant de ce fait que dans les zones signées. C'est ainsi que l'authentification d'entités nommées basée sur le DNS (DANE) permet la publication de clés de sécurité de la couche transport (TLS) dans des zones pour des applications telles que le transport de courrier. DANE permet de vérifier l'authenticité de clés publiques sans avoir recours aux autorités de certification. L'utilisation de DANE est aussi un moyen de renforcer la confidentialité des requêtes DNS.
En 2018, l'ICANN a modifié pour la première fois l'ancre de confiance pour la racine du DNS, un processus qui s'est révélé riche en enseignements sur le DNSSEC. De plus, de nombreux opérateurs de résolveurs ont alors pris connaissance du DNSSEC et activé sa validation, ce qui a contribué à éclairer davantage la communauté mondiale sur le fonctionnement global du système. L'ICANN collabore également avec diverses parties prenantes de la communauté Internet — dont des gouvernements, des opérateurs de TLD, des fournisseurs d'hébergement DNS, des fournisseurs de services Internet (FSI) et des opérateurs de réseau mobile (MNO) — afin d'accroître le déploiement de DNSSEC tant au niveau de la signature que de la validation.
En 2024, l'ICANN a généré une nouvelle ancre de confiance pour la racine du DNS ; cette nouvelle ancre devrait devenir active en 2026. L'ICANN espère une adoption accrue du DNSSEC dans les prochaines années, tant par les opérateurs de résolveurs que par les propriétaires de zones. Cela signifierait qu'un plus grand nombre d'utilisateurs, où qu'ils soient, pourraient bénéficier de la solide garantie cryptographique offerte par les DNSSEC, à savoir l'obtention de réponses authentiques du DNS à leurs requêtes.
Ressources
Ce que fait l'ICANN en matière de DNSSEC
-
Informations IANA sur le DNSSEC
Cette page contient des informations sur le rôle de l'IANA en tant qu'opérateur de la clé de signature de clé pour la zone racine du DNS : ancres de confiance et roulements, éléments de cérémonie KSK, politiques et procédures de gestion des clés de la zone racine, etc. -
Relation avec la communauté technique
Cette page contient des informations sur l'équipe de l'ICANN chargée de mener et de faciliter, auprès de diverses parties prenantes de la communauté Internet, des initiatives de renforcement des capacités techniques et de sensibilisation afin de contribuer au maintien d'un écosystème DNS sécurisé.
Pour approfondir
- L'ICANN publie une nouvelle ancre de confiance DNSSEC pour 2026, aout 2026
- Retour sur deux ans de soutien au déploiement de DNSSEC en Afrique et au Moyen-Orient, Yazid Akanho, octobre 2022
- Participation de plus de 3000 parties prenantes aux séances d'échange de la région LAC de l'ICANN en 2021, Nicolás Antoniello et Daniel Fink, décembre 2021
- Le roulement récent de la KSK :résumé et prochaines étapes, octobre 2018
- Cinq années de formations techniques au sein de l'APAC pour garantir la sécurité, la stabilité et la résilience de l'Internet, Champika Wijayatunga, septembre 2018
Pour trouver d'autres billets de blog de l'ICANN sur le DNSSEC, utilisez le mot-clé « DNSSEC » dans le champ de recherche de cette page.
Documents de l'ICANN
- OCTO-035 : Observer les cycles de vie des clés DNSSEC, juillet 2022
- OCTO-033 : Utilisation de l'algorithme DNSSEC en 2022, avril 2022
- OCTO-029 : Guide de déploiement DNSSEC pour les ccTLD, novembre 2021
- OCTO-012 : Revue du roulement 2018 de la KSK du DNSSEC, juillet 2020
- OCTO-006 : DNSSEC : sécuriser le DNS, mise à jour juillet 2020
- Archives du projet DNSSEC : documents archivés provenant de certains projets de la communauté relatifs au développement et à l'évolution du DNSSEC dans la zone racine. Ces documents ne doivent pas être considérés comme des informations à jour sur les opérations et ne sont fournis qu'à des fins d'historique.