EXTENSIONS DE SÉCURITÉ DU SYSTÈME DE NOMS DE DOMAINE (DNSSEC)

En contribuant à protéger les utilisateurs contre les redirections vers des sites frauduleux et des adresses détournées, le protocole DNSSEC (Extensions de sécurité du système de noms de domaine) peut renforcer la confiance qu'ils accordent à Internet.


Click to play
close

Le DNS (Domain Name System), le système d'adresse d'Internet, est le composant crucial de l'infrastructure d'Internet. Sans lui, Internet ne peut pas fonctionner. Il n'a toutefois pas été conçu en tenant compte de la sécurité. Il est par conséquent vulnérable aux attaques d'homme du milieu et à l'empoisonnement du cache. Ces menaces utilisent des données falsifiées pour rediriger le trafic d'Internet vers des sites frauduleux et des adresses détournées.

Lorsqu'un utilisateur ou un périphérique qui ne soupçonne rien atteint le site frauduleux, les cybercriminels peuvent potentiellement récupérer des données de carte de crédit, voler les mots de passe des utilisateurs, espionner des communications VoIP, installer des logiciels malveillants ou afficher des images ou du texte nuisant à la marque légitime ou fournissant des informations trompeuses. Dans la mesure où un seul serveur de noms DNS peut faire office de point de résolution de nom pour des milliers d'utilisateurs, l'impact potentiel d'une attaque MITM ou d'un empoisonnement de cache peut être considérable.

AVANTAGES DU PROTOCOLE DNSSEC

Choisissez un rôle ci-dessous pour découvrir comment le protocole DNSSEC vous concerne, ainsi que son rôle dans notre stratégie d'authentification d'Internet de bout en bout.

Bureaux d'enregistrement Opérateurs de sites Web FAI

FORMATION DNSSEC

Verisign s'implique dans le développement du protocole DNSSEC depuis 2000 et poursuit sa collaboration avec la communauté technique d'Internet.

Mode de fonctionnement du protocole DNSSEC
Chronologie du protocole DNSSEC
Rôle de Verisign dans le protocole DNSSEC

FAQ sur le protocole DNSSEC


Le protocole DNSSEC protège la communauté Internet des données DNS falsifiées en utilisant une cryptographie de clé publique pour apposer une signature numérique aux données de zone ayant autorité. La validation DNSSEC garantit aux utilisateurs qu'il s'agit bien les données provenant de la source spécifiée et qu'elles n'ont pas été modifiées lors de leur transit. Le protocole DNSSEC peut également prouver qu'un nom de domaine n'existe pas.

Bien que le protocole DNSSEC améliore la sécurité du DNS, il ne s'agit pas d'une solution exhaustive. Elle ne protège pas contre les attaques par déni de service distribué (DDoS), ne garantit pas la confidentialité des échanges de données, ne chiffre pas les données des sites Web, ni ne prévient l'usurpation d'adresse IP ou le phishing. Les autres couches de protection, telles que la limitation des attaques par déni de service distribué (DDoS), les renseignements de sécurité, le chiffrement SSL (Secure Sockets Layer), la validation de site et l'authentification bifactorielle, sont tout aussi essentielles pour garantir un Internet plus sûr. Ces mécanismes doivent être utilisés conjointement avec le protocole DNSSEC.

Le protocole DNSSEC affecte tous les composants présents dans l'écosystème de l'infrastructure Internet. Son déploiement efficace nécessite la participation de nombreux acteurs de la communauté Internet. Les registres, bureaux d'enregistrement, inscrivants de nom de domaine, fournisseurs de matériel et de logiciels, FAI, organismes gouvernementaux et utilisateurs ordinaires d'Internet ont tous un rôle à jouer pour en assurer le succès et apporter des améliorations vitales à la sécurité d'Internet. Le protocole DNSSEC profite :

  • à la communauté Internet, grâce à l'amélioration de la sécurité dans les zones qui sont signées ;
  • aux bureaux d'enregistrement, en leur permettant de proposer des services de signature de domaines à leurs clients ;
  • aux FAI, grâce à l'amélioration de la sécurité des données retournées à leurs clients ;
  • aux utilisateurs, en les protégeant des failles du DNS comme l'empoisonnement du cache et les attaques MITM.

Dans le protocole DNSSEC, chaque zone possède une paire de clés publique/privée. La clé publique de la zone est publiée à l'aide du DNS, alors que la clé privée de la zone est conservée en toute sécurité et parfaitement stockée hors ligne. La clé privée d'une zone signe les données DNS individuelles comprises dans cette zone, en créant des signatures numériques qui sont également publiées à l'aide du DNS. Le protocole DNSSEC utilise un modèle de confiance rigide. Cette chaîne de confiance va d'une zone parent à une zone enfant. Les zones de niveau supérieur (parent) apposent leur signature (ou certifient) les clés publiques des zones de niveau inférieur (enfant). Les serveurs de noms ayant autorité pour ces zones peuvent être gérés par des bureaux d'enregistrement, des FAI, des entreprises d'hébergement Web ou les opérateurs de site Web (inscrivants) eux-mêmes.

Lorsqu'un utilisateur final souhaite accéder à un site Web, un résolveur de stub au sein du système d'exploitation de l'utilisateur demande l'enregistrement du nom de domaine à un serveur de noms récursif, situé chez un FAI. Une fois que le serveur a demandé cet enregistrement, il demande également la clé DNSSEC associée à la zone. Cette clé permet au serveur de vérifier que les informations qu'il reçoit sont identiques à l'enregistrement du serveur de noms ayant autorité.

Si le serveur de noms récursif détermine que l'enregistrement d'adresse a été envoyé par le serveur de noms ayant autorité et n'a pas été modifié durant le transit, il résout le nom de domaine, et l'utilisateur peut accéder au site. Ce processus est appelé validation. Si l'enregistrement d'adresse a été modifié ou n'est pas issu de la source déclarée, le serveur de noms récursif n'autorise pas l'utilisateur à accéder à l'adresse frauduleuse. Le protocole DNSSEC peut également prouver qu'un nom de domaine n'existe pas.

Le puzzle complet de la sécurité Internet est constitué de nombreuses pièces. Le protocole DNSSEC peut limiter les risques de sécurité causés par les attaques de l'homme du milieu et l'empoisonnement du cache, mais ne constitue pas une solution de sécurité globale. Le protocole DNSSEC ne résout pas un grand nombre des problèmes de sécurité sur Internet comme l'usurpation d'adresse ou le phishing. Pour cette raison, d'autres couches de protection, comme les certificats SSL et l'authentification bifactorielle, sont cruciales pour qu'Internet soit sûr pour tous.

La communauté Internet n'a pas encore mis en place de système standardisé pour informer les utilisateurs d'une attaque. Une solution possible consisterait à développer des navigateurs « compatibles DNSSEC » qui notifieraient les utilisateurs qu'ils sont dirigés vers une destination authentifiée.

En juillet 2010, Verisign, en collaboration avec l'IANA (Internet Assigned Numbers Authority) et le département du Commerce des États-Unis (DoC), a achevé le déploiement du protocole DNSSEC dans la zone racine (point de départ de la hiérarchie DNS). Verisign l'a également activé sur la zone .edu en juillet 2010, en collaboration avec EDUCAUSE et le DoC, sur .net en décembre 2010 et sur .com en mars 2011.

Notre stratégie de déploiement du protocole DNSSEC consiste à commencer par les plus petites zones, d'évaluer chaque déploiement et d'en tirer les enseignements avant de passer à la zone suivante. La zone .com étant la plus vaste, nous la signerons en dernier. Nous souhaitons acquérir autant d'expérience que possible avant de nous attaquer au domaine qui gère la majorité des transactions commerciales et des communications Internet du monde entier.

Un déploiement réussi du protocole DNSSEC apporte des avantages importants à la communauté Internet mondiale en augmentant la confiance pour une multitude d'activités Internet, notamment le commerce en ligne, la banque en ligne, le courrier électronique, la VoIP et la distribution de logiciels en ligne. Cependant, la responsabilité de la réussite du protocole DNSSEC repose sur l'ensemble de la communauté Internet. La réussite exige une participation active et coordonnée des inscrivants, des bureaux d'enregistrement, des sociétés d'hébergement, des développeurs de logiciels, des fournisseurs de matériel, des gouvernements, des technologues d'Internet et des coalitions.

La zone racine d'Internet, les domaines de premier niveau comme .gov, .org, .museum et bon nombre de domaines géographiques ont signé les zones qu'ils gèrent. La mise en œuvre du protocole DNSSEC par d'autres domaines de premier niveau comme .edu, .net et .com est prévue en 2010/2011. Ces domaines de premier niveau on commencé à accepter des noms de domaine de second niveau, signés DNSSEC. Les grands FAI tels que Comcast ont annoncé leur intention d'activer la validation sur les serveurs de noms récursifs qui répondent aux demandes des utilisateurs, et certains bureaux d'enregistrement ont intégré la mise en œuvre de DNSSEC dans leurs feuilles de route. En outre, l'ICANN (Corporation for Assigned Names and Numbers) a ouvert des applications pour les nouveaux domaines de premier niveau et il est probable que les plans d'implémentation DNSSEC constitueront une obligation pour l'acceptation des nouvelles demandes de domaines de premier niveau.

Bien que le protocole DNSSEC et le protocole SSL reposent sur le chiffrement de clé publique, ils remplissent des fonctions très différentes qui se complètent, plutôt que de se substituer l'une à l'autre.

Pour simplifier, le protocole DNSSEC traite la question « Où » et le protocole SSL traite les questions « Qui » et « Comment ».

  •  : le protocole DNSSEC utilise des signatures numériques pour vérifier l'intégrité des données DNS, assurant ainsi que les utilisateurs atteignent l'adresse IP souhaitée. Sa tâche est terminée lorsque l'utilisateur atteint l'adresse. Le protocole DNSSEC ne garantit pas l'identité de l'entité à l'adresse et ne crypte pas les interactions entre l'utilisateur et le site.
  • Qui : SSL utilise les certificats numériques pour valider l'identité d'un site. Lorsque ces certificats sont émis par des autorités de certification tierces réputées, SSL garantit l'identité du propriétaire du site Web auprès des utilisateurs. Toutefois, SSL ne permet pas de garantir que les utilisateurs vont accéder aux sites souhaités et ne les protègent donc pas contre les attaques qui les dirigent vers d'autres sites. En d'autres termes, la validation de site SSL est efficace uniquement si l'utilisateur accède en premier lieu au site souhaité.
  • Comment : SSL utilise également les certificats numériques pour crypter les échanges de données entre un utilisateur et un site afin de protéger la confidentialité des transactions financières, des communications, du commerce en ligne et d'autres interactions sensibles.

La combinaison du protocole DNSSEC et du protocole SSL permet d'augmenter le niveau de sécurité et de confiance sur Internet : les utilisateurs peuvent vérifier de manière fiable les sites auxquels ils accèdent, l'identité des personnes avec lesquelles ils communiquent et le niveau de confidentialité de leurs transactions.

Le mémo 08-23 de l'OMB (Office of Management and Budget) exigeait que le protocole DNSSEC soit déployé dans le domaine de premier niveau .gov au plus tard en janvier 2009 et que les agences fédérales américaines le déploient sur les sites externes pour décembre 2009. Le registre .gov a été signé au début de l'année 2009. L'agence américaine pour les systèmes d'information de la défense prévoit également de respecter les exigences DNSSEC de l'OMB pour le domaine .mil. Aux États-Unis, les réglementations de la FISMA (New Federal Information Security Management Act), demandaient aux agences de signer leurs zones intranet au moyen des DNSSEC au plus tard au milieu de l'année 2010. Pour l'instant, les opérateurs de sites Web publics ne sont pas tenus de sécuriser leur domaine à l'aide du protocole DNSSEC.

1994 : publication de la première version d'une norme éventuelle
1997 : publication de la norme RFC 2065 (DNSSEC est une norme IETF)
1999 : publication de la norme RFC 2535 (révision de la norme DNSSEC)
2005 : révision complète des normes précédemment publiées
RFC 4033 (Présentation et exigences)
RFC 4034 (Nouveaux enregistrements de ressources)
RFC 4035 (Modifications du protocole)
Juillet 2010 : signature de la zone racine
Juillet 2010 : signature du domaine .edu
Décembre 2010 : signature du domaine .net
Février 2011 : le registre compatible DNSSEC .gov est transféré à Verisign
Mars 2011 : signature du domaine .com
Mars 2011 : le service DNS géré de Verisign est renforcé par la prise en charge totale de la compatibilité DNSSEC
Janvier 2012 : Comcast annonce que ses clients utilisent des résolveurs de validation DNSSEC
Mars 2012 : le nombre de domaines de premier niveau signés passe à 90