DNSSEC: standard Internet pour la signature de noms de domaine

Chaque utilisateur et chaque site sur le World Wide Web possède sa propre adresse IP. Cette dernière est unique et composée de plusieurs chiffres. Ce qu’on appelle un système de nom de domaine permet de convertir ces adresses IP numériques en noms de domaine pratiques à retenir et à écrire, comme IONOS.fr par exemple. Il est responsable de l’attribution des noms de domaine, ou résolution de noms, et est par conséquent un des services les plus importants de réseau basé sur les adresses IP. A partir des différents noms de serveurs (ou serveurs DNS) existants, il transforme des noms en toutes lettres en adresses IP et permet au client de créer le contact souhaité.  

La communication entre système de nom de domaine et client vous épargne de forts risques en termes de sécurité : comme l’identité de l’expéditeur n’est pas vérifiée, le destinataire ne peut pas déterminer si la réponse DNS reçue vient vraiment du serveur interrogé. Si un agresseur se connecte entre le système de nom de domaine et le client, il peut envoyer la mauvaise adresse IP au destinataire. DNSSEC a été développé en 2011 pour éviter ce problème, et ce aussi pour les extensions .fr gérées par l’AFNIC.

Ce qu’on appelle Domain Name System Security Extensions (DNSSEC) désigne différents standards d’Internet qui complètent le système de nom de domaine avec une authentification des sources et qui garantissent l’authenticité et l’intégrité des données. Après que la version originale de DNSSEC de 1999 se soit révélée non adaptée aux plus grands réseaux, il a fallu attendre quelques années pour voir une extension de sécurité DNS apparaître en 2005 (dans les trois RFCs ou Requests for Comments : RFC 4033, RFC 4034 et RFC 4035) avant de devenir un nouveau standard. Cela a seulement commencé au niveau de la racine d’Internet en 2010 : 13 systèmes de nom de domaine à la racine ont été créés pour la dislocation des noms de domaine de premier niveau. 

DNSSEC s’appuie sur un système de clé publique mais cryptée, un procédé de cryptage asymétrique avec lequel les parties impliquées n’échangent pas de clé secrète commune mais combinées (une clé publique avec une clé privée). On parle de couples de clés. Les unités d’informations DNS, ou liste des enregistrements DNS, sont munies d’une signature digitale via cette clé privée. A l’aide de la clé publique, cette signature est vérifiée par le Client et par conséquent, elle confirme l’authenticité de la source.

Chaque système de nom de domaine est responsable d’une zone précise. Vous trouverez une liste complète des enregistrements DNS dans le fichier des zones, où ces dernières sont décrites. Pour cette raison, tout système de nom de domaine possède sa propre clé de zone, avec laquelle il devient capable de protéger la liste d’enregistrements DNS. La clé publique de la clé de zone est intégrée au fichier de zones en tant que DNSKEY Resource Record (pour liste d’enregistrement DNS) et chaque unité d’information est signée. Les listes d’enregistrement RRSIG servent de complément à cet égard. Cette combinaison subsiste, peu importe si elle est stockée dans le cache ou transmise à un autre système de nom de domaine. Enfin elle atterrit sur le Client qui a effectué la demande, et qui peut effectuer une signature à l’aide d’un DNS resolver et valider une clé publique.

Pour faciliter la gestion des clés et créer une chaîne de confiance, il existe, en dehors des clés de zone, des clés de signature de clé à la syntaxe identique qui confirment l’authenticité de la clé de zone respective.

Les DNS Resolver sont des modules de logiciels d’un Client, qui chargent les informations du système de nom de domaine. La demande est faite soit itérativement soit récursivement. Dans le premier cas le Resolver reçoit l’information souhaitée ou un renvoi au système de nom de domaine le plus proche et procède de cette façon jusqu’à ce que l’adresse soit résolue. Les Resolver qui travaillent récursivement sont aussi appelés en anglais stub-Resolver et sont typiques pour les clients tels que les navigateurs Web par exemple : ils envoient une demande au système de nom de domaine dans le réseau local ou celui du fournisseur. Si l’information demandée n’est pas contenue dans l’ensemble des données, la dissolution complète de l’adresse reste la responsabilité du serveur qui envoie des demandes itératives.

Pour profiter du DNSSEC, un Resolver est nécessaire pour valider les informations supplémentaires.  Dans ce but, le resolver doit être compatible avec les mécanismes d‘extensions de protocoles pour DNS (EDNS), car la validation ne peut être activée que dans l’en-tête DNS.

L’expansion de DNSSEC s’avère surtout difficile jusqu’à présent en raison de prérequis complexes : la technique doit non seulement être compatible avec les pages des fournisseurs, mais aussi avec celles des visiteurs. Les propriétaires de noms de domaine sont dépendants du fait que les bureaux d’enregistrement organisent et soient compatibles avec ce cryptage. Les utilisateurs n’ont pas d’influence sur le fait qu’un site Web soit protégé ou non par des signatures DNSSEC. Ils ont de plus besoin d’un Resolver valide. Pour profiter de cela, vous devez exploiter votre propre Resolver, comme Bind par exemple, utiliser une extension de navigateur Web telle que DNSSEC Validator ou bien chercher un fournisseur qui contrôle les signatures DNSSEC.  Il faut prendre en compte le fait que DNSSEC signe et authentifie seulement la résolution de noms de domaine, tandis que les données transmises ne sont pas protégées. Il est donc nécessaire de recourir à un protocole de communication servant au cryptage des données échangées comme TLS. Les problèmes suivants ont de plus freiné la confiance des utilisateurs pour cette technique de sécurité DNS :

• La forte charge des systèmes de noms de domaine peut faciliter des attaques par déni de service, causées par l’indisponibilité d’un service.
• La chaîne de confiance DNSSEC est mise à mal dans la mesure où les clés publiques sont réparties dans le système de nom de domaine.
• Sans Resolver DNS propre servant à la validation, il existe une probabilité d’attaque entre Client et système de nom de domaine du fournisseur, même si ce dernier vérifie les signatures DNSSEC.