DNSSEC et sécurité DNS sur votre réseau local

Informatec Digital » Ressources » DNSSEC et sécurité DNS sur votre réseau local

Internet repose sur quelques composants essentiels que nous ne voyons presque jamais, mais qui sont présents à chaque fois que nous ouvrons un navigateur. L'un des plus importants est le système de noms de domaine (DNS). Lorsque nous parlons de DNSSEC et de sécurité sur un réseau local , nous parlons en réalité de renforcer cette infrastructure afin de prévenir les redirections frauduleuses, l'usurpation d'identité et autres attaques graves.

Auparavant, la priorité était simplement de garantir le bon fonctionnement du système ; aujourd’hui, nous savons que cela ne suffit plus. Le DNS a vu le jour dans les années 80 sans que l’on prenne en compte les cyberattaques massives, mais il est désormais indispensable non seulement pour la résolution de noms, mais aussi pour la validation de l’authenticité et de l’intégrité de chaque réponse . C’est là qu’intervient DNSSEC, et plus récemment, des propositions comme E-DNSSEC, qui visent également à renforcer la confidentialité — un facteur essentiel pour la sécurité de votre réseau local ou d’entreprise.

Qu'est-ce que le DNS et pourquoi est-il si crucial pour la sécurité ?

Le système de noms de domaine (DNS ) est l'annuaire téléphonique d'Internet : il traduit les noms faciles à retenir (comme www.example.com) en adresses IP numériques compréhensibles par les ordinateurs (par exemple, 192.168.2.15 ou une adresse IPv6). Sans ce mécanisme, nous devrions mémoriser des nombres au lieu de noms, ce qui serait totalement impraticable.

Cette infrastructure est organisée comme une base de données distribuée structurée en arborescence , avec une zone racine au sommet, suivie des domaines de premier niveau (TLD tels que .es, .com, .org), puis des domaines et sous-domaines. Chaque portion de cette base de données est appelée « zone » et est hébergée sur un ou plusieurs serveurs de noms faisant autorité, qui publient les informations « officielles » pour chaque domaine.

Lorsque votre ordinateur, votre téléphone portable ou tout autre appareil souhaite accéder à un site web, il commence par interroger un résolveur DNS , qui fait partie du système d'exploitation. Ce résolveur envoie la requête à un serveur DNS récursif (généralement celui de votre fournisseur d'accès à Internet, celui de votre entreprise ou un serveur public comme Google DNS , OpenDNS ou Quad9). Ce serveur récursif recherche ensuite la réponse en interrogeant plusieurs serveurs faisant autorité jusqu'à trouver l'adresse IP correcte.

Les résolveurs récursifs mettent en cache les réponses qu'ils reçoivent afin d'accélérer les requêtes suivantes. Ce système est très efficace, mais il permet également à un attaquant d' « empoisonner le cache DNS » et d'y insérer de fausses données , de sorte que de nombreuses requêtes ultérieures soient résolues avec ces informations manipulées sans que l'utilisateur ne s'en aperçoive.

Le problème majeur réside dans le fait que, dans sa conception initiale, le DNS ne dispose d'aucun moyen fiable de vérifier l'authenticité des réponses . Le résolveur vérifie essentiellement que la réponse semble provenir de la même adresse IP que celle interrogée, mais cette adresse IP source peut être usurpée relativement facilement. Cela permet des attaques par redirection silencieuses vers des sites frauduleux qui imitent, par exemple, le site web de votre banque.

Limitations de sécurité du DNS traditionnel

Le protocole DNS a été créé à une époque où la sécurité n'était pas une priorité. C'est pourquoi nous savons aujourd'hui que les requêtes et les réponses DNS transitent en clair , sans chiffrement, et que les données enregistrées peuvent être falsifiées sans protection supplémentaire.

Cela ouvre la porte à plusieurs types d'attaques, notamment l'empoisonnement du cache DNS et les attaques de type « homme du milieu ». Dans les deux cas, l'attaquant injecte des réponses falsifiées, ce qui amène les utilisateurs à se retrouver sur des sites web qu'il contrôle sans qu'ils ne remarquent rien d'anormal, puisque le nom de domaine affiché dans le navigateur reste légitime.

Imaginez que vous accédiez au site web de votre banque : votre ordinateur demande l’adresse IP du domaine de la banque au serveur récursif, mais un pirate a trompé ce dernier en lui faisant accepter une fausse réponse avec l’adresse IP d’un site web identique qu’il contrôle . L’utilisateur saisit ses identifiants, pensant que tout est normal, et le cybercriminel les reçoit en clair pour les utiliser ultérieurement sur le véritable site.

Des mécanismes tels que les signatures de transaction (TSIG) , définies dans la RFC 2845, servent à protéger certaines opérations entre serveurs DNS (par exemple, les transferts de zone entre serveurs maître et esclave et les mises à jour dynamiques). TSIG permet à deux machines partageant une clé secrète de vérifier l'identité de l'autre extrémité et l'intégrité des messages en transit.

Cependant, TSIG a une portée très limitée : il n’authentifie pas l’origine « réelle » des données DNS ; il garantit seulement que l’échange entre deux serveurs spécifiques n’a pas été altéré. Si les informations originales d’une zone ont déjà été compromises ou manipulées avant d’atteindre ces serveurs, TSIG ne le détectera pas. Par conséquent, bien qu’il soit couramment utilisé pour les transferts de zone, il ne résout pas le problème fondamental de l’authenticité des données DNS publiées.

Qu'est-ce que DNSSEC et quelle est sa contribution à la sécurité ?

Pour pallier ces faiblesses, les extensions de sécurité du système de noms de domaine (DNSSEC) ont été développées . DNSSEC ne remplace pas le DNS classique, mais l'étend en ajoutant une couche de sécurité permettant de vérifier que les données reçues sont légitimes et n'ont pas été altérées.

DNSSEC repose sur la cryptographie à clé publique (cryptographie asymétrique) . Chaque zone DNS possède une paire de clés : une clé privée, gardée secrète, et une clé publique, publiée sur le serveur DNS lui-même. Le propriétaire de la zone utilise la clé privée pour signer numériquement les enregistrements de cette zone ; la clé publique sert à vérifier ces signatures.

Lorsqu'un serveur récursif interroge un domaine via DNSSEC, il reçoit, outre les informations habituelles (par exemple, l'adresse IP associée au nom de domaine), les signatures numériques et les clés publiques nécessaires à la validation . Le serveur récursif vérifie ensuite ces signatures à l'aide des clés publiques publiées ; si la vérification réussit, les données sont considérées comme authentiques et inchangées depuis leur signature.

En cas d'échec de la validation, le résolveur détecte une anomalie (par exemple, une tentative d'usurpation d'identité ou de falsification lors de la transmission) et renvoie au client un code d'erreur, généralement SERVFAIL . Ainsi, l'utilisateur ne reçoit pas de données potentiellement malveillantes ; de son point de vue, il constatera simplement que la page ne se charge pas ou affiche une erreur.

DNSSEC introduit également le concept de chaîne de confiance , qui s'appuie sur la hiérarchie DNS existante. La zone racine signe les clés des domaines de premier niveau (tels que .es, .com), lesquels signent à leur tour les clés de leurs domaines enfants, et ainsi de suite, de sorte que tout domaine peut être validé à l'aide d'un point de confiance unique : la clé publique de la zone racine.

Clés KSK et ZSK, enregistrements et chaîne de confiance

Pour une sécurité renforcée, DNSSEC utilise deux types de clés : la clé de signature de clé (KSK) et la clé de signature de zone (ZSK) . Bien que techniquement identiques (d’un point de vue cryptographique), leur fonction diffère au sein du système.

La clé ZSK sert à signer tous les enregistrements de ressources de la zone (A, AAAA, MX, etc.). Elle est généralement renouvelée régulièrement afin de minimiser les risques, car toute compromission de cette clé affecterait tous les enregistrements de la zone. La clé KSK, quant à elle, est principalement utilisée pour signer la clé de zone (ZSK) elle-même, et son hachage est publié en tant qu'enregistrement DS (Delegation Signer) dans la zone parente.

Grâce à cette séparation des rôles, la modification de la ZSK est simplifiée : il suffit de générer une nouvelle ZSK, de la signer avec la KSK, de la publier dans les enregistrements DNSKEY de la zone et de laisser les résolveurs mettre à jour leurs informations. Il n’est pas nécessaire de modifier la zone parente, car le DS continue de pointer vers la même KSK, qui reste stable plus longtemps.

DNSSEC ajoute plusieurs types d'enregistrements spécifiques au protocole DNS, conçus pour la signature et la validation des données. Parmi les plus importants figurent DNSKEY, RRSIG, DS, NSEC/NSEC3 et NSEC3PARAM . Tous permettent de mettre en place une logique d'authentification sans modifier le fonctionnement de base des requêtes.

L'enregistrement DNSKEY stocke la clé publique de la zone , nécessaire à la vérification des signatures. L'enregistrement RRSIG contient la signature numérique associée à un ensemble spécifique d'enregistrements (un « ensemble d'enregistrements de ressources »). L'enregistrement DS est un hachage de la clé DNSKEY de la zone enfant, publiée dans la zone parente et servant de maillon dans la chaîne de confiance.

Les enregistrements NSEC et NSEC3 sont utilisés pour fournir un déni d'existence authentifié ; c'est-à-dire pour prouver cryptographiquement qu'un nom de domaine ou un enregistrement n'existe pas, empêchant ainsi les attaques qui tentent d'insérer de fausses réponses indiquant que quelque chose n'existe pas alors qu'il existe réellement (ou vice versa).

Chaîne de confiance et validation de la réponse DNSSEC

La chaîne de confiance de DNSSEC est construite en reliant les enregistrements DNSKEY et DS de la racine au domaine à valider . Le point de départ est la clé publique de la zone racine, qui sert d'ancre de confiance et est généralement configurée directement dans les résolveurs récursifs.

Par exemple, si vous souhaitez valider un domaine comme mywebsite.es, le processus logique serait le suivant : le résolveur fait confiance à la clé publique racine, qui signe la clé .es ; la zone .es publie un enregistrement DS correspondant à la clé KSK de mywebsite.es ; en validant cet enregistrement DS avec la clé .es, le résolveur fait confiance à la clé DNSKEY de mywebsite.es et, à partir de là, peut vérifier les RRSIG sur tous ses enregistrements.

Si une signature valide est manquante à un moment quelconque de la chaîne, ou si la signature de données (DS) est absente à l'endroit prévu, la chaîne de confiance est rompue. Dans ce cas, le serveur récursif effectuant la validation considère les données comme non sécurisées et, selon sa configuration, soit ne répond pas avec les enregistrements demandés, soit marque la réponse comme invalide.

Cette relation hiérarchique implique également que, pour que DNSSEC soit pleinement efficace, il ne suffit pas de signer uniquement votre zone : la zone parente (par exemple, .es) et la zone racine doivent également être signées et leurs enregistrements DNS correctement publiés. Actuellement, la zone racine DNS, la quasi-totalité des domaines génériques de premier niveau (gTLD) et de nombreux domaines de premier niveau de code pays (ccTLD) sont déjà signés.

Lorsqu'un serveur récursif avec validation DNSSEC activée détecte une signature non valide ou un lien manquant, la réponse renvoyée au client est généralement accompagnée d'un code d'erreur RCODE SERVFAIL. Cela peut dérouter l'utilisateur final (« le site web ne fonctionne pas »), mais du point de vue de la sécurité, il s'agit d'une mesure de protection contre les données potentiellement manipulées.

DNSSEC introduit également deux fonctionnalités clés : l’authentification de l’origine des données , qui permet de vérifier que les enregistrements proviennent bien de la zone attendue, et la protection de l’intégrité , qui garantit que les informations n’ont pas été modifiées depuis leur signature par le propriétaire de la zone avec sa clé privée.

Attaques atténuées par DNSSEC et leur relation avec TLS/HTTPS

La mise en œuvre de DNSSEC contribue à se protéger contre plusieurs menaces courantes. Premièrement, elle rend l'usurpation de réponses DNS extrêmement difficile , car l'attaquant devrait générer des signatures valides sans connaître la clé privée de la zone, ce qui est cryptographiquement impossible si les clés sont correctement gérées.

De plus, DNSSEC réduit le risque d' empoisonnement du cache sur les serveurs récursifs en empêchant l'acceptation de réponses manipulées dont la validation de signature échoue. Il complique également les attaques de type « homme du milieu » (MITM) sur le trafic DNS, où un attaquant modifie les réponses en transit : si la réponse échoue à la validation, le résolveur la rejette.

Il est important de comprendre ce que DNSSEC ne fait pas. Ces extensions ne sont pas conçues pour chiffrer le contenu des requêtes ou des réponses . Tout le trafic DNS, même avec DNSSEC, transite toujours en clair, sauf si vous utilisez d'autres technologies complémentaires (telles que DoT, DoH ou des solutions de type E-DNSSEC). DNSSEC vise à garantir l'authenticité et l'intégrité des données reçues, et non à masquer votre requête.

Cela le différencie clairement des protocoles comme TLS et HTTPS . Alors que HTTPS chiffre le trafic entre le navigateur et le serveur web pour empêcher les tiers d'espionner ou de modifier la communication, DNSSEC se contente de signer les données DNS pour détecter les usurpations d'identité. Un site peut utiliser HTTPS sans DNSSEC ou DNSSEC sans HTTPS, mais la combinaison des deux offre une protection bien plus complète contre l'usurpation d'identité et l'espionnage.

Des organisations comme l'ICANN et l'IETF promeuvent depuis des années l'adoption généralisée de DNSSEC par les registres, les bureaux d'enregistrement, les fournisseurs d'accès à Internet et les opérateurs de réseau. L'objectif est d'accroître le nombre de zones signées et la validation active de ces zones par un nombre croissant de résolveurs, afin que l'utilisateur lambda puisse bénéficier de ces garanties cryptographiques sans aucune action particulière.

DNSSEC dans les domaines .es et obligations du propriétaire

Dans le cas spécifique de l'Espagne, le service des domaines « .es », géré par Red.es, a depuis longtemps intégré des technologies et des procédures supplémentaires afin d'améliorer la qualité et la sécurité du service DNS sous le code pays « .es ». Parmi ces mesures figure la mise en œuvre du protocole de sécurité DNSSEC, conforme aux spécifications de l'IETF.

Les domaines .es sont responsables de la signature de la zone de premier niveau .es et de l'obtention de l'autorisation auprès du serveur DNS racine, s'intégrant ainsi à la chaîne de confiance mondiale. Cela signifie que si vous possédez un domaine .es, vous pouvez tirer parti de cette infrastructure pour sécuriser votre propre domaine avec DNSSEC.

En tant que propriétaire de domaine, la procédure générale pour activer DNSSEC consiste à s'assurer que vos serveurs DNS faisant autorité publient la zone signée. Cela implique généralement de générer une clé publique pour votre zone, de signer les enregistrements, de publier la clé DNS, puis de soumettre les éléments de clé (ou l'enregistrement DS lui-même) au registre ou à votre registraire afin qu'ils puissent créer l'enregistrement DS correspondant dans la zone parente.

En pratique, de nombreux fournisseurs d'hébergement DNS et bureaux d'enregistrement proposent déjà une option assez simple pour activer DNSSEC, parfois aussi simple que de cocher une case dans le panneau de contrôle. Cependant, cette fonctionnalité peut engendrer des frais annuels modiques, variables selon le fournisseur et le niveau de service.

Une fois la zone signée et le système de noms de domaine (DNS) publié avec succès, votre domaine intègre la chaîne de confiance DNSSEC. Dès lors, les résolutions DNS pour votre domaine peuvent être validées cryptographiquement par les résolveurs compatibles DNSSEC, ce qui renforce la confiance des utilisateurs et réduit le risque d'usurpation d'identité.

DNSSEC sur le réseau local : validation côté utilisateur

Du point de vue d'un utilisateur final ou d'une entreprise soucieuse de la sécurité de son réseau local, la question essentielle est : comment bénéficier de DNSSEC ? La bonne nouvelle, c'est qu'aucune configuration individuelle n'est nécessaire sur chaque ordinateur , à condition que votre serveur DNS récursif (celui utilisé par vos ordinateurs) prenne en charge DNSSEC.

Pour cela, il vous suffit que votre fournisseur DNS (votre FAI, un résolveur public ou le DNS interne de votre organisation) dispose d'un serveur récursif avec la validation DNSSEC activée et correctement configurée . La quasi-totalité des résolveurs modernes prennent en charge DNSSEC depuis des années ; son activation ne nécessite généralement que quelques modifications de leur fichier de configuration et l'ajout de l'ancre de confiance racine.

Une fois la validation activée, lorsqu'un ordinateur du réseau local interroge un domaine signé, le résolveur récursif vérifie toutes les signatures et la chaîne de confiance avant de renvoyer la réponse. En cas de non-concordance, aucune réponse n'est renvoyée et l'utilisateur voit un message d'erreur, l'empêchant ainsi de se connecter à un site potentiellement frauduleux.

Pour vérifier si votre domaine est protégé par DNSSEC, plusieurs outils en ligne sont disponibles, tels que DNSSEC Analyzer et d'autres utilitaires de validation . Lorsque vous saisissez votre domaine, vous devriez voir des enregistrements comme RRSIG (signatures cryptographiques), DNSKEY (clés publiques) et DS (hachage de la clé DNSKEY dans la zone parente). Si l'outil indique qu'aucune signature numérique n'est associée aux enregistrements, votre domaine sera considéré comme « non signé » ou « non sécurisé ».

Si, après cette vérification, vous constatez que votre domaine ou les serveurs DNS utilisés sur votre réseau local ne bénéficient pas du protocole DNSSEC, il est conseillé de contacter votre fournisseur d'accès à Internet pour en demander l'activation. S'il ne propose pas cette option, il serait judicieux d' envisager de changer de fournisseur pour un fournisseur prenant en charge la validation DNSSEC, ce qui renforcerait la sécurité de votre entreprise et de vos clients.

Limites du DNSSEC : confidentialité et autres aspects

Malgré ses nombreux avantages, DNSSEC n'est pas une solution miracle à tous les problèmes de sécurité DNS. Un problème majeur réside dans l' absence de confidentialité des requêtes . Les paquets DNS, même avec DNSSEC, circulent toujours en clair ; par conséquent, toute personne ayant accès au trafic (par exemple, sur un réseau Wi-Fi public non sécurisé ) peut voir quels domaines sont interrogés.

Il n'offre par ailleurs aucun contrôle d'accès ni aucune protection spécifique contre les attaques par déni de service (DoS ou DDoS) . De fait, l'ajout de données supplémentaires (signatures, clés, enregistrements additionnels) augmente la taille des réponses DNS, ce qui peut être exploité lors d'attaques par amplification si l'infrastructure n'est pas correctement configurée et protégée.

En revanche, DNSSEC introduit une certaine complexité opérationnelle : la gestion des paires de clés est nécessaire , la rotation des clés ZSK et KSK est requise, la publication DS dans la zone parente doit être coordonnée et il faut s’assurer de l’absence d’incohérences susceptibles de rompre la chaîne de confiance. Une erreur dans ces procédures peut empêcher un domaine de se valider correctement, entraînant des interruptions de service apparentes.

Au sein même du processus DNSSEC, des bits de contrôle présents dans les messages (tels que le bit CD dans les requêtes et le bit AD dans les réponses) influencent la manière dont la validation est effectuée et rapportée. Un attaquant capable de manipuler ces bits dans un environnement non sécurisé pourrait tenter de dégrader la protection offerte par un résolveur récursif. Par conséquent, il est recommandé que les communications entre les résolveurs et les clients utilisant DNSSEC s'effectuent via des canaux sécurisés.

Malgré ces limitations, DNSSEC demeure un élément essentiel pour renforcer l'authenticité et l'intégrité du DNS. Cependant, pour aller plus loin et garantir également la confidentialité des requêtes, il est nécessaire de le combiner à d'autres technologies ou d'évoluer vers des solutions plus avancées.

E-DNSSEC : Vers un DNS authentifié et chiffré

Pour pallier les failles de confidentialité de DNSSEC, le concept d' E-DNSSEC (DNSSEC chiffré) a été proposé . L'idée est d'ajouter un chiffrement aux requêtes DNSSEC afin que, outre leur authentification et leur signature, elles soient également protégées contre toute inspection par des tiers lors de leur transmission sur Internet ou au sein du réseau local.

L'objectif d'E-DNSSEC est d'associer les propriétés de DNSSEC (authenticité et intégrité) à des mécanismes de chiffrement garantissant la confidentialité des requêtes entre le client et le serveur DNSSEC . Ceci renforce la sécurité globale du service DNS, empêchant les observateurs externes de voir quels noms de domaine sont résolus.

Le processus conceptuel consisterait à analyser la requête sur le serveur récursif, à la chiffrer avant de l'envoyer au serveur faisant autorité, puis à la déchiffrer et à la traiter normalement à l'aide de DNSSEC . La réponse, quant à elle, pourrait être renvoyée signée et chiffrée au serveur récursif ou au client, garantissant ainsi la confidentialité tout au long du processus.

Cette combinaison garantirait la sécurité du message DNS de bout en bout : authentification et intégrité assurées par DNSSEC, et protection contre les regards indiscrets grâce à un chiffrement supplémentaire. Dans un réseau local ou d’entreprise, une telle approche pourrait être intégrée à d’autres solutions de sécurité périmétrique.

Aujourd'hui, des propositions comme E-DNSSEC s'inscrivent dans un effort plus vaste visant à renforcer la confidentialité du DNS , aux côtés de technologies telles que DNS over TLS (DoT) et DNS over HTTPS (DoH). L'objectif sous-jacent est clair : le DNS de demain doit être à la fois authentique et confidentiel, et il ne suffit pas de résoudre rapidement les noms de domaine ; la sécurité est également primordiale.

Dans un environnement où les cyberattaques, les usurpations d'identité et les menaces ciblant les infrastructures de base sont de plus en plus sophistiquées, la mise en place de DNSSEC est déjà une exigence de sécurité importante pour tout domaine sérieux, et le passage à des solutions chiffrées comme E-DNSSEC ou similaires apparaît comme une prochaine étape logique pour renforcer davantage la protection des réseaux, y compris les réseaux locaux.

Cet écosystème complet – du DNS classique au DNSSEC en passant par les solutions chiffrées comme E-DNSSEC – démontre que la sécurité DNS n'est pas une option, mais un élément fondamental de l'architecture Internet et de tout réseau local moderne. Disposer de résolveurs qui valident les domaines DNS, de zones signées, de chaînes de confiance rigoureusement maintenues et, à l'avenir, de canaux chiffrés pour les requêtes, fait toute la différence entre un réseau vulnérable et une infrastructure préparée aux défis actuels et futurs.

Article connexe:

Comment activer le DNS sur HTTPS (DoH) sous Windows 11 et améliorer votre confidentialité