Aller au contenu Aller au menu principal Aller au menu secondaire Aller au pied de page

Un nouveau pas pour la vie privée lors de l’utilisation du DNS

Accueil > Observatoire & ressources > Papiers d’experts > Un nouveau pas pour la vie privée lors de l’utilisation du DNS
Le 22/11/2021

L'introduction

Le RFC 9156, « DNS Query Name Minimisation to Improve Privacy » vient d’être publié. Ce RFC normalise une méthode pour diminuer la quantité d’informations diffusée lors d’une requête DNS et est donc important pour réduire les atteintes à la vie privée lors de l’utilisation de ce protocole.

Le problème

Comme expliqué dans le RFC 7626, « DNS privacy considerations », l’utilisateur du DNS, c’est-à-dire tout utilisateur de l’Internet, va informer indirectement, via les requêtes DNS émises par sa machine, sur ses activités internetiennes. Ainsi, s’il visite le site Web des Alcooliques Anonymes, un certain nombre de gérants de serveurs DNS, ou d’opérateurs des réseaux qui y donnent accès, verront une requête DNS pour le nom www.alcooliques-anonymes.fr, information que le visiteur aurait probablement préféré garder pour lui.
Il y a des années que l’IETF, l’organisme qui normalise le protocole DNS, travaille à réduire cette fuite d’informations. Souvent, quand on parle de protéger la vie privée, on ne pense qu’au chiffrement des communications. Le chiffrement est certainement un outil utile pour se protéger contre l’indiscrétion d’un tiers qui écouterait le trafic. Mais il ne résout pas tous les problèmes. Par exemple, il ne protège pas contre le destinataire de la communication. Si j’utilise un réseau social accessible via le Web, la communication se fera sans doute en HTTPS, donc chiffrée, mais cela ne protégera que contre d’éventuels observateurs du trafic réseau, pas contre les gérants du réseau social, qui verront toujours tout. Le chiffrement ne suffit donc pas, il faut aussi minimiser les données envoyées.
Le RGPD (Règlement Général sur la Protection des Données), par exemple, insiste bien sur l’importance de cette minimisation, et répète à plusieurs reprises le « principe de minimisation des données ». Son article 5 dit que les données récoltées doivent être « adéquates, pertinentes et limitées à ce qui est nécessaire au regard des finalités pour lesquelles elles sont traitées (minimisation des données) ». Ainsi, si on veut faire des statistiques sur l’âge des utilisateurs d’un service, leur demander leur date de naissance complète est tout à fait anormal : l’année suffirait.
Or, le DNS, avant cette technique de minimisation décrite dans ce RFC, envoyait plus d’informations que « ce qui est nécessaire au regard des finalités ». Les serveurs faisant autorité recevaient le nom complet demandé, même quand, n’ayant pas une connaissance complète de tous les noms de domaine, le ou les derniers composants de ce nom auraient suffi. (Vous pouvez voir le fonctionnement de la résolution DNS dans cette vidéo de l’Afnic.)

La solution

La technique normalisée dans le RFC 9156 est simple : un résolveur DNS ne doit pas transmettre aux serveurs faisant autorité le nom de domaine complet qu’on lui a envoyé, mais seulement la partie strictement nécessaire. Pour reprendre l’exemple de www.alcooliques-anonymes.fr cité plus haut, le résolveur n’enverra aux serveurs racine que fr (les serveurs de la racine ne connaissent que les domaines de premier niveau), et aux serveurs de l’Afnic que alcooliques-anonymes.fr, pas le nom complet. (Si vous connaissez bien le DNS, vous noterez que les choses sont évidemment un peu plus compliquées que cela, lisez le RFC pour avoir tous les détails.)
Il est amusant de noter que bien des vidéos que l’on trouve au hasard du Web et qui expliquent « le fonctionnement du DNS en trois minutes » étaient incorrectes car elles montraient un résolveur minimisant des données, bien avant la publication du RFC original !
Cette technique de minimisation avait à l’origine été décrite dans le RFC 7816, qui avait à l’IETF le statut d’« expérience ». Depuis des années que cette « expérience » a été largement déployée, les avantages de la minimisation de la question, et son absence d’inconvénients sérieux, ont permis d’avancer et le nouveau RFC, le 9156, qui remplace le 7816, a désormais le statut de norme technique.
Cette nouvelle norme a été écrite par Paul Hoffman (ICANN), Ralph Dolmans (NLnet Labs) et votre serviteur, à l’Afnic. Les NLnet Labs développent une bonne partie des logiciels libres qui font tourner le DNS d’aujourd’hui, comme le résolveur Unbound, Ralph ayant été le programmeur qui a modifié Unbound pour y introduire la minimisation des questions. On voit que l’IETF est toujours soucieuse de concret, et de s’assurer que les normes techniques sont réalistes, et peuvent être programmées sans causer de problèmes majeurs. L’expérience de Ralph a donc été très utile.

Le déploiement

Aujourd’hui, divers tests effectués sur les résolveurs, ou via des systèmes de mesure comme les sondes RIPE Atlas, indiquent qu’entre un tiers et une moitié des utilisateurs de l’Internet utilisent un résolveur DNS qui minimise les questions. Si ce n’est pas le cas du vôtre, demandez à votre service informatique d’activer cette protection ! La publication de ce RFC et le nouveau statut de norme de cette technique devrait aider à ce qu’elle se répande.

La technique

Les techniciens et techniciennes peuvent tester leur résolveur DNS en https://tcmdns.dev.dns-oarc.net/. Parmi les tests, il y a celui de la minimisation des données, mais la présentation des résultats est complexe.