DNSSEC est une technologie ancienne, la version actuelle ayant été normalisée en 2005 et la signature de la racine du DNS (et du .fr) remontant à 2011. Pour autant, son déploiement est loin d’être universel1, alors même que les menaces sur la sécurité du DNS ne cessent de préoccuper décideurs et opérationnels. Pourquoi cette dysphorie et comment la combler ?
État de la menace
Le DNS est un service crucial de l’internet. Il est à la base de la plupart des activités qu’on effectue sur le réseau. S’il est en panne, plus rien ne fonctionne. S’il est détourné ou mensonger, on peut être redirigé vers n’importe où. Le problème est connu depuis longtemps : des bits qui circulent sur le réseau sont à la merci d’une modification par des acteurs situés sur le trajet. Mais le DNS a une vulnérabilité supplémentaire : reposant par défaut sur le protocole UDP, qui ne fournit aucune authentification, même simpliste, de l’adresse IP de l’émetteur, il permet à un attaquant d’injecter de fausses réponses dans le résolveur2, fausses réponses qui seront ensuite transmises au client.
Il n’est pas facile de donner des chiffres précis sur l’utilisation de ces attaques dans la nature3. Par construction, les attaques par empoisonnement du résolveur sont très discrètes et, a priori, n’ont pas fait l’objet d’études. Mais les expériences en laboratoire montrent qu’elles sont parfaitement possibles.
DNSSEC
La solution à tous ces problèmes d’authentification (vérifier que les données viennent bien de la source attendue) et d’intégrité (vérifier que les données n’ont pas été modifiées en route) est bien connue dans le monde de l’internet, c’est la cryptographie. Plus précisément, il s’agit d’utiliser un des services que fournit la cryptographie ; la signature des données. Le gérant d’un domaine signe les données et toute modification ultérieure de ces données invalidera la signature. Un éventuel attaquant pourra toujours modifier les bits, mais l’opération sera détectée. Il n’est ainsi plus possible d’être détourné de son domaine vers un site web d’hameçonnage sans s’en apercevoir.
Insistons sur un point : pour que DNSSEC protège, deux acteurs différents doivent agir ; le gérant technique du domaine, qui doit signer son domaine, et celui du résolveur, qui doit valider les signatures.
Déploiement
La cryptographie étant d’usage extrêmement banal aujourd’hui sur internet, on peut s’étonner que DNSSEC, qui n’utilise que des solutions cryptographiques classiques, ne soit pas universellement déployé. C’est malheureusement un problème fréquent en sécurité de manière générale (et en cybersécurité en particulier) : à chaque attaque, on s’inquiète, on s’indigne, on se promet de faire mieux mais, quelques semaines après, tout est oublié et on continue comme avant. Et DNSSEC souffre également du fait que de nombreuses autres faiblesses de sécurité existent, et qu’elles peuvent être considérées comme plus cruciales. Pour ne prendre qu’un exemple, si une organisation n’applique pas les mises à jour de sécurité immédiatement sur ses serveurs, mais au contraire les laisse vulnérables pendant des mois, voire des années, il ne serait pas raisonnable de presser pour un déploiement de DNSSEC : il y a plus urgent.
Par conséquent, DNSSEC est aujourd’hui insuffisamment déployé. La racine et l’écrasante majorité des TLD (dont le .fr, bien sûr) sont signées avec DNSSEC4. Mais beaucoup de domaines de deuxième niveau (ou plus bas) ne sont pas signés.
Une autre difficulté doit-être signalée. De nombreux résolveurs valident/vérifient ces signatures. C’est notamment le cas du fournisseur d’accès Free, ou de la totalité des grands résolveurs DNS publics, comme ceux de Google, de Quad9, de Cloudflare ou du futur résolveur DNS4EU poussé par la Commission Européenne. Mais certains résolveurs ne valident toujours pas les signatures.
Comprendre, mettre en œuvre et maintenir DNSSEC
Pour encourager ce déploiement, l’Afnic organise une formation DNSSEC de deux jours à destination des personnes en charge de la gestion, maintenance et supervision d’infrastructure DNS, que ce soit du côté des serveurs faisant autorité, hébergeant des zones DNS, ou du côté des résolveurs.
Pour que les participants soient en capacité au quotidien de comprendre, mettre en œuvre et fournir DNSSEC pour leurs clients/utilisateurs, la formation comprend une révision du fonctionnement du DNS, une exposition détaillée des risques, une explication du fonctionnement de DNSSEC et des travaux pratiques variés, sur machines Unix.
En conclusion
Aujourd’hui, DNSSEC est un composant nécessaire de la sécurité du DNS. L’objectif est de généraliser son déploiement. L’Afnic participe activement à ce déploiement, par son activité opérationnelle sur le .fr, bien sûr, mais aussi par son activité de formation, et par le développement de logiciels de tests DNS et DNSSEC, notamment Zonemaster.
1 – https://stats.labs.apnic.net/dnssec
2 – On cite souvent ici le nom de Dan Kaminsky, qui n’a pas inventé cette attaque, mais qui l’a considérablement perfectionnée en 2008.
3 – Il faut rappeler que la quasi-totalité des données chiffrées sur le nombre d’attaques informatiques est faite au doigt mouillé, sans méthodologie précise et documentée.
4 – D’autant plus que l’ICANN l’impose aux TLD qui sont sous contrat avec elle.