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 explique les DNSSEC et décrit les avantages de leur utilisation.

Brève description du fonctionnement du DNS

Afin de comprendre les extensions de sécurité du système des noms de domaine (DNSSEC), il est bon d'avoir des connaissances de base du système des noms de domaine (DNS).

Le fonctionnement même de l'Internet dépend largement du DNS. Une page web consultée, un e-mail envoyé, une photo récupérée d'un réseau social : toutes ces interactions ont recours au DNS afin de traduire les noms de domaine conviviaux (tels que icann.org) en adresses IP (telles que 192.0.43.7 et 2001:500:88:200::7) requises par les serveurs, les routeurs et autres périphériques réseau afin d'acheminer le trafic sur Internet vers la destination souhaitée.

L'utilisation d'Internet sur tout dispositif commence avec le DNS. Prenons l'exemple d'un utilisateur qui saisit, sur son téléphone, le nom d'un site web dans le navigateur. Le navigateur utilise le résolveur basique, qui fait partie du système d'exploitation du dispositif, afin de lancer le processus de traduction du nom de domaine du site web en une adresse IP (Internet Protocol). Un résolveur basique est un client DNS très simple qui transmet la demande de données DNS d'une application à un client DNS plus complexe appelé résolveur récursif. De nombreux opérateurs de réseaux ont recours à des résolveurs récursifs afin de traiter les demandes DNS, ou requêtes, envoyées par des dispositifs sur leur réseau.  (Des opérateurs et organisations de plus petite taille ont parfois recours à des résolveurs récursifs d'autres réseaux, y compris des résolveurs récursifs exploités en tant que service au public tels que Google Public DNS, OpenDNS et Quad9.)

Le résolveur récursif identifie, ou résout, la réponse à la requête DNS envoyée par le résolveur basique. Ce processus de résolution impose au résolveur récursif d'envoyer ses propres requêtes DNS, généralement à différents serveurs de noms faisant autorité. Les données DNS de chaque nom de domaine sont stockées sur un serveur de nom faisant autorité quelque part sur Internet. Les données DNS d'un domaine sont connues sous le nom de zone. Certaines organisations exploitent leurs propres serveurs de noms afin de publier leurs zones, mais les organisations sous-traitent en général cette fonction à des tiers. Différents types d'organisations hébergent les zones DNS pour le compte d'autres, notamment des bureaux d'enregistrement, des registres, des sociétés d'hébergement web, des fournisseurs de serveurs réseaux, entre autres.

Le DNS en soi n'est pas sécurisé

Le DNS a été conçu dans les années 1980 alors qu'Internet était bien plus petit, et la sécurité n'était alors pas une priorité. De ce fait, quand un résolveur récursif envoie une requête à un serveur de nom faisant autorité, le résolveur n'a 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 à laquelle le résolveur a envoyé la requête originale. Mais s'en remettre à l'adresse IP source d'une réponse ne constitue pas un solide mécanisme d'authentification étant donné que 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 détecter facilement une réponse falsifiée à l'une de ses requêtes. Un attaquant peut facilement se faire passer pour le serveur faisant autorité à qui le résolveur a envoyé la requête originale en usurpant une réponse semblant provenir de ce serveur faisant autorité. En d'autres termes, un attaquant peut rediriger un utilisateur vers un site potentiellement malveillant sans que l'utilisateur ne s'en aperçoive.

Les résolveurs récursifs mettent en cache les données DNS qu'ils reçoivent des serveurs de noms faisant autorité afin d'accélérer le processus de résolution. Si un résolveur basique 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 qui 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 en ayant fait la requête.

Comme exemple de la menace que représente une attaque par empoisonnement du cache, pensez à ce qui se passe lorsqu'un utilisateur consulte le site web de sa banque. Le dispositif de l'utilisateur envoie une requête à son serveur de nom récursif configuré à propos de l'adresse IP du site web de la banque. Mais un attaquant pourrait avoir empoisonné le résolveur avec une adresse IP ne dirigeant pas vers le site légitime mais vers un site web créé par l'attaquant. Ce site web frauduleux se fait passer pour le site web de la banque, ce qui semble tout à fait probable. L'utilisateur, qui n'a pas conscience de la fraude, saisit, comme d'habitude, son nom et son mot de passe. Malheureusement, l'utilisateur a sans le savoir fournit ses identifiants bancaires à l'attaquant qui pourra ensuite se connecter en tant qu'utilisateur sur le site web légitime de la banque afin de transférer des fonds ou de réaliser des opérations non autorisées.

Les extensions de sécurité du DNS (DNSSEC)

Les ingénieurs du Groupe de travail de génie Internet (IETF), l'organisation responsable des normes et protocoles du DNS, se sont depuis longtemps rendu compte que le manque d'authentification renforcée du DNS posait problème. Les travaux visant à trouver une solution ont débuté dans les années 1990, donnant lieu aux extensions de sécurité du système des noms de domaine (DNSSEC).

Les DNSSEC renforcent l'authentification du DNS en utilisant des signatures numériques basées sur la cryptographie à clé publique. Avec les DNSSEC, les requêtes DNS et les réponses ne sont pas elles-mêmes signées cryptographiquement, ce sont les données DNS qui sont signées par le propriétaire des données.

Chaque zone DNS a une paire de clés publique-privée. Le propriétaire de la zone utilise la clé privée de la 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, ce matériel de clé est gardé secret par le propriétaire de la zone. Toutefois, la clé publique de la zone 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 la zone extrait également la clé publique de la zone qu'il utilise afin de valider l'authenticité des données DNS. Le résolveur confirme que la signature numérique des données DNS qu'il a extraite est valide. Si c'est le cas, les données DNS sont légitimes et sont renvoyées à l'utilisateur. Si la signature n'est pas valide, le résolveur suppose qu'il s'agit d'une attaque, écarte les données, et renvoie une erreur à l'utilisateur.

Les DNSSEC ajoutent deux importantes fonctions au protocole du DNS :

• L'authentification de l'origine des données permet au résolveur de vérifier cryptographiquement que les données qu'il a reçues proviennent bien de la zone qu'il pense être la source des données.
• La protection de l'intégrité des données permet au résolveur de savoir que les données n'ont pas été modifiées en transit 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 des 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, comme les autres données de la zone. Toutefois, la clé publique n'est pas signée par la clé privée de la zone mais par la clé privée de la zone mère. Par exemple, la clé publique de la zone icann.org est signée par la zone org. En plus d'être chargée de publier une liste des serveurs de noms faisant autorité de la zone enfant, la zone mère est également chargée d'attester l'authenticité de la clé publique de sa zone enfant. Chaque clé publique d'une 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, telle 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 actuel est 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 n'importe où dans l'espace des noms du DNS dès lors que toutes les zones du trajet sont signées.

Validation et signature avec les DNSSEC

Afin de garantir une sécurité généralisée d'Internet, les DNSSEC doivent être largement déployés. Les DNSSEC ne sont pas automatiques : ils doivent actuellement être spécifiquement activés par des opérateurs de réseaux au niveau de leurs résolveurs récursifs et également par des propriétaires de noms de domaine au niveau des serveurs faisant autorité de leur zone. Les opérateurs de résolveurs et de serveurs faisant autorité sont encouragés de différentes façons à activer les 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. Un utilisateur peut tout simplement avoir l'assurance de finir à la destination en ligne souhaitée.

Il est facile pour les résolveurs récursifs d'activer la validation des DNSSEC. De fait, presque tous les résolveurs courants le font depuis de nombreuses années. Cette activation implique de changer juste quelques lignes dans le fichier de configuration du résolveur. À partir de là, lorsqu'un utilisateur demande au résolveur des données DNS qui proviennent des zones signées, et que les données ont été manipulées, l'utilisateur n'obtiendra (délibérément) aucune donnée en retour. Les DNSSEC protègent l'utilisateur contre l'obtention de données incorrectes d'une zone signée en détectant l'attaque et en empêchant l'utilisateur de recevoir les données manipulées.

La signature de zones avec les DNSSEC implique de prendre quelques mesures, 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 de zones, et un grand nombre de fournisseurs d'hébergement DNS tiers prennent également en charge les DNSSEC. En règle générale, l'activation de DNSSEC pour une zone avec un fournisseur d'hébergement est relativement simple : il suffit souvent de cocher une case.

Pour qu'un propriétaire de zone déploie des DNSSEC en signant les données de sa zone, la zone mère du propriétaire de la zone et la zone mère de la zone mère du propriétaire de la zone, jusqu'à la zone racine, doivent également être signées afin que les DNSSEC soient les plus efficaces 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 les DNSSEC dans la zone icann.org, la zone org doit être signée ainsi que la zone racine. Heureusement, la zone racine du DNS a été signée depuis 2010, et tous les gTLD ainsi que bon nombre de ccTLD ont également été signés.

La dernière étape du déploiement des DNSSEC dans une zone est la suivante : le matériel de clé publique de la zone nouvellement signée doit être envoyé à la zone mère. 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 entre la zone mère et la zone enfant.

Aujourd'hui, le propriétaire d'une zone doit normalement communiquer manuellement le matériel de clé publique de la zone vers la zone mère. Dans la plupart des cas, la communication est réalisée via le bureau d'enregistrement du propriétaire de la zone. 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é de la zone, le propriétaire de la zone interagit également avec le bureau d'enregistrement afin de mettre à jour le matériel de clé publique de la zone. Alors que ce processus est actuellement mené manuellement, les protocoles récemment développés devraient permettre à l'avenir d'automatiser ce processus.

Prochaines étapes pour les DNSSEC

Au fur et à mesure du déploiement des DNSSEC, le DNS peut devenir une base pour les autres protocoles qui doivent trouver un moyen de stocker les données en toute sécurité. Les nouveaux protocoles développés ont recours aux DNSSEC et peuvent ainsi uniquement travailler dans des zones signées. Par exemple, 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 courriers. La DANE permet de vérifier l'authenticité de clés publiques qui ne reposent pas sur des autorités de certification. De nouvelles façons de renforcer la confidentialité des requêtes DNS permettront également d'utiliser la DANE à l'avenir.

En 2018, l'ICANN a modifié pour la première fois l'ancre de confiance pour la racine du DNS. De nombreux enseignements ont été tirés sur les DNSSEC lors de ce processus. En outre, un grand nombre d'opérateurs de résolveurs ont pris connaissance des DNSSEC et ont activé la validation, et le monde a pu avoir une vision plus claire du fonctionnement de l'ensemble du système des DNSSEC. Au cours des prochaines années, l'ICANN espère observer une adoption à plus grande échelle des DNSSEC par les opérateurs de résolveurs et les propriétaires de zones. Cela signifierait que plus d'utilisateurs, partout dans le monde, pourraient bénéficier de la solide garantie cryptographique des DNSSEC et être assurés d'obtenir des réponses authentiques du DNS à leurs requêtes.