DNSSEC: standard Internet pour la signature de noms de domaine

Chaque uti­li­sa­teur 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 nu­mé­riques en noms de domaine pratiques à retenir et à écrire, comme IONOS.fr par exemple. Il est res­pon­sable de l’at­tri­bu­tion des noms de domaine, ou ré­so­lu­tion de noms, et est par con­sé­quent un des services les plus im­por­tants de réseau basé sur les adresses IP. A partir des dif­fé­rents noms de serveurs (ou serveurs DNS) existants, il trans­forme des noms en toutes lettres en adresses IP et permet au client de créer le contact souhaité.  

La com­mu­ni­ca­tion entre système de nom de domaine et client vous épargne de forts risques en termes de sécurité : comme l’identité de l’ex­pé­di­teur n’est pas vérifiée, le des­ti­na­taire ne peut pas dé­ter­mi­ner 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 des­ti­na­taire. DNSSEC a été développé en 2011 pour éviter ce problème, et ce aussi pour les ex­ten­sions .fr gérées par l’AFNIC.

Ce qu’on appelle Domain Name System Security Ex­ten­sions (DNSSEC) désigne dif­fé­rents standards d’Internet qui com­plè­tent le système de nom de domaine avec une au­then­ti­fi­ca­tion des sources et qui ga­ran­tis­sent l’au­then­ti­cité 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 ap­pa­raî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 dis­lo­ca­tion des noms de domaine de premier niveau. 

DNSSEC s’appuie sur un système de clé publique mais chiffrée, un procédé de chif­fre­ment asy­mé­trique avec lequel les parties im­pli­qué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’in­for­ma­tions DNS, ou liste des en­re­gis­tre­ments 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 con­sé­quent, elle confirme l’au­then­ti­cité de la source.

Chaque système de nom de domaine est res­pon­sable d’une zone précise. Vous trouverez une liste complète des en­re­gis­tre­ments 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’en­re­gis­tre­ments 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’en­re­gis­tre­ment DNS) et chaque unité d’in­for­ma­tion est signée. Les listes d’en­re­gis­tre­ment RRSIG servent de com­plé­ment à cet égard. Cette com­bi­nai­son 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 con­fir­ment l’au­then­ti­cité de la clé de zone res­pec­tive.

Les DNS Resolver sont des modules de logiciels d’un Client, qui chargent les in­for­ma­tions du système de nom de domaine. La demande est faite soit ité­ra­ti­ve­ment soit ré­cur­si­ve­ment. Dans le premier cas le Resolver reçoit l’in­for­ma­tion 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 tra­vail­lent ré­cur­si­ve­ment sont aussi appelés en anglais stub-Resolver et sont typiques pour les clients tels que les na­vi­ga­teurs Web par exemple : ils envoient une demande au système de nom de domaine dans le réseau local ou celui du four­nis­seur. Si l’in­for­ma­tion demandée n’est pas contenue dans l’ensemble des données, la dis­so­lu­tion complète de l’adresse reste la res­pon­sa­bi­lité du serveur qui envoie des demandes ité­ra­tives.

Pour profiter du DNSSEC, un Resolver est né­ces­saire pour valider les in­for­ma­tions sup­plé­men­taires.  Dans ce but, le resolver doit être com­pa­tible avec les mé­ca­nismes d‘ex­ten­sions de pro­to­coles pour DNS (EDNS), car la va­li­da­tion 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 com­pa­tible avec les pages des four­nis­seurs, mais aussi avec celles des visiteurs. Les pro­prié­taires de noms de domaine sont dé­pen­dants du fait que les bureaux d’en­re­gis­tre­ment or­ga­ni­sent et soient com­pa­tibles avec ce chif­fre­ment. Les uti­li­sa­teurs n’ont pas d’influence sur le fait qu’un site Web soit protégé ou non par des sig­na­tures 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 na­vi­ga­teur Web telle que DNSSEC Validator ou bien chercher un four­nis­seur qui contrôle les sig­na­tures DNSSEC.  Il faut prendre en compte le fait que DNSSEC signe et au­then­ti­fie seulement la ré­so­lu­tion de noms de domaine, tandis que les données trans­mises ne sont pas protégées. Il est donc né­ces­saire de recourir à un protocole de com­mu­ni­ca­tion servant au chif­fre­ment des données échangées comme TLS. Les problèmes suivants ont de plus freiné la confiance des uti­li­sa­teurs 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’in­dis­po­ni­bi­lité 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 va­li­da­tion, il existe une pro­ba­bi­lité d’attaque entre Client et système de nom de domaine du four­nis­seur, même si ce dernier vérifie les sig­na­tures DNSSEC.