Fin du projet « DNS et vie privée » à l’IETF

Accueil > Observatoire & ressources > Papiers d’experts > Fin du projet « DNS et vie privée » à l’IETF

Le 12/01/2026

Le 11 juillet 2025, l’IETF (Internet Engineering Task Force), une des organisations de normalisation de l’Internet, a annoncé la dissolution du groupe de travail DPRIVE, qui travaillait sur la question de la vie privée dans le DNS. L’Afnic ayant beaucoup participé à ce groupe, c’est l’occasion de faire un petit bilan. Mais commençons tout de suite par un point important : cette dissolution n’est pas un échec, bien au contraire, le travail a été accompli !

Un peu de contexte sur le DNS

Le DNS (Domain Name System) est un service critique de l’Internet. Il permet, à partir d’un nom de domaine, de récupérer des informations techniques (comme par exemple des adresses IP) qui sont indispensables à la grande majorité des activités sur l’Internet¹. Mais comme presque toute opération sur l’Internet commence par une requête DNS, le DNS est également une source d’information pour tous ceux, et ils sont nombreux, qui veulent surveiller l’activité des internautes. C’est ainsi que, dans les programmes aux noms pittoresques de la NSA, révélés par Snowden, un programme était dédié à la surveillance du DNS, « More cow bell ».

Le danger de surveillance est d’autant plus grand que le traitement d’une requête DNS passe par plusieurs serveurs, parfois éloignés². En outre, beaucoup de personnes ont peu de connaissances sur l’infrastructure de l’Internet, ce qui fait que les risques pour la vie privée liés au DNS sont souvent moins bien compris. Au contraire des questions de vie privées liées au Web, qui ont fait l’objet d’innombrables articles et débats, celles du DNS sont encore rarement perçues.

Certaines personnes relativisent le risque en disant qu’une requête DNS ne donne pas beaucoup d’informations, uniquement un nom de domaine qui intéresse quelqu’un. Si ce nom est fr.wikipedia.org, il n’y a en effet que peu de problèmes, presque tout le monde visite Wikipédia. Mais si ce nom est alcooliques-anonymes.fr, on voit tout de suite que c’est plus délicat.

Deux points techniques pour finir : contrairement à la quasi-totalité des protocoles applicatifs de l’Internet, le DNS n’utilisait pas du tout le chiffrement³, toutes les communications étaient en clair. Et deuxième point, le résolveur DNS envoyait traditionnellement la totalité du nom demandé à tous les serveurs faisant autorité qu’il contactait. Si l’utilisateur voulait visiter www.phy.cam.ac.uk, les serveurs de la racine voyaient la requête complète, alors que le TLD (Top-Level Domain, ici .uk) aurait suffi.

Un peu de contexte sur l’IETF

L’IETF (Internet Engineering Task Force) est une des organisations de normalisation de l’Internet, c’est-à-dire qu’elle crée les normes techniques qui permettent à un Internet hétérogène (beaucoup de matériels et de logiciels d’origines différentes) de fonctionner. Elle est notamment active sur l’infrastructure logicielle de l’Internet, donc pas le matériel, ni les applications que voit l’utilisateur, mais tout ce qui est entre matériel et applications, dont le DNS.

L’IETF est organisée en groupes de travail, chacun chargé d’un sujet particulier⁴. Une particularité de l’IETF, par rapport à bien d’autres organisations de normalisation, est que la grande majorité de ces groupes sont transitoires. Ils sont créés pour une tâche bien précise, formalisée dans une charte, et fermés lorsqu’elle est accomplie ou lorsque le projet n’a débouché sur rien. Ce dernier cas arrive, soit parce que, l’IETF étant formée de volontaires, il n’y a pas eu suffisamment d’intérêt pour le projet, soit parce que le problème s’est révélé insoluble, ou en tout cas n’obtenait pas de consensus. Mais la fin d’un groupe de travail n’est pas forcément le signe d’un échec, cela peut signifier que les objectifs indiqués dans la charte du groupe ont été atteints.

L’histoire du projet

Revenons maintenant au groupe DPRIVE (DNS PRIVate Exchange⁵ ). Sa genèse remonte à l’année 2013, quelques mois après les révélations d’Edward Snowden. Dans un avion en route vers Vancouver, pour une réunion IETF où la question de la lutte contre la surveillance de masse allait être le sujet principal⁶, plusieurs spécialistes du DNS, dont votre serviteur, discutent, et décident qu’il faut aussi faire quelque chose pour le DNS, et plusieurs idées surgissent, notamment l’importance de marcher sur deux jambes, en chiffrant les communications mais aussi en minimisant les données envoyées. À l’atterrissage, le projet était prêt.

À Vancouver, le projet n’avait été discuté qu’informellement. Quelques jours après, le 12 novembre 2013, le premier brouillon de discussion est publié, draft-koch-perpass-dns-confidentiality. Le 27 novembre 2013, un second brouillon de discussion du problème est disponible. Il se nomme draft-bortzmeyer-dnsop-dns-privacy et, comme toujours à l’IETF où tout est public, son histoire peut être suivie en ligne. Rappelons qu’à l’IETF, n’importe qui peut écrire un tel brouillon et le faire publier. Il n’y a de validation que syntaxique. Ces documents n’avaient donc, à l’époque, aucun statut officiel.

Une autre étape importante a lieu à Londres en mars 2014, dans une autre réunion IETF, où se tenait une BoF⁷. Une BoF est une réunion qui a pour but de mieux définir un problème. La plupart des groupes de travail de l’IETF ont vu leur création précédée d’une BoF. Les BoF sont spécifiées dans le RFC 5434. Celle de Londres était réunie sous le nom DNSE (pour DNS Encryption), un nom malheureux car il se focalisait sur une solution, et pas sur le problème, et oubliait la minimisation des données, technique souvent oublié dans les discussions sur la préservation de la vie privée. Plusieurs participants s’étaient alors opposés au projet, à la fois avec des arguments traditionalistes (« on a toujours fait comme ça ») et en relativisant les menaces sur la vie privée (le point de vue traditionnel des Étatsuniens). Néanmoins, la BoF fut un succès, malgré ces quelques objections, et le travail continua. Le 11 mars 2014, fut créée la liste de diffusion ⁸ dns-privacy, pour aider à discuter du problème, et le premier message disait « Welcome to the dns-privacy list. This is where we’ll have those discussions surrounding DNS privacy and confidentiality. ».

Le groupe de travail DPRIVE a finalement été créé le 16 septembre 2014, avec une charte indiquant que le groupe devait travailler sur une description du problème, et sur des solutions (non spécifiées au début). Une contrainte importante était le maintien de la compatibilité avec le DNS existant. Pas question de développer un protocole de remplacement du DNS. Un premier brouillon a été adopté par le groupe et publié le 26 octobre 2014, et est devenu un document de travail officiel du groupe, le draft-ietf-dprive-problem-statement, qui deviendra par la suite le RFC 7626. Ce premier RFC du groupe, qui décrivait en détail le problème à résoudre, sera suivi de dix autres RFC, normalisant notamment plusieurs façons de chiffrer les communications DNS, comme le RFC 7858, en 2016, qui normalise DNS sur TLS (DoT, pour DNS over TLS⁹).

Notez que DPRIVE n’a pas été le seul groupe de travail IETF à plancher sur la protection de la vie privée dans le cas du DNS. La minimisation des requêtes (QNAME minimization, où on n’envoie aux serveurs faisant autorité qu’une partie du nom de domaine demandé par l’utilisateur) sera traitée par un groupe existant, DNSOP, qui publiera en mars 2016 le RFC 7816, dont le premier brouillon, draft-bortzmeyer-dns-qname-minimisation, avait été publié deux ans avant¹⁰. Et un autre groupe de travail sera impliqué, DOH (DNS over HTTPS), qui se chargera de normaliser DNS sur HTTPS dans le RFC 8484 en octobre 2018.

Outre les divers problèmes techniques¹¹, le projet a rencontré des difficultés variées. Il y a eu des oppositions de principe au chiffrement, accusé de diminuer la visibilité des opérateurs, ainsi que des questions de brevets car, oui, il y avait un brevet sur la minimisation des requêtes. Comme la plupart des brevets logiciels, il n’avait rien d’original, la technique ayant déjà été utilisée, mais pas forcément bien documentée et donc pas facile à prouver. Il y a eu aussi des inquiétudes non fondées, comme la crainte que la minimisation des requêtes ne casse le DNS existant.

Une fois les trois premiers, et essentiels RFC, les RFC 7626, 7816 et 7858, publiés, fin 2016, le groupe DPRIVE a été nettement moins actif. Il y a eu des ajouts utiles, comme le bourrage des communications chiffrées, dans le RFC 8467 ou comme le RFC 8932 qui décrit les politiques de vie privée des serveurs DNS. Et certains des RFC originaux ont connu des nouvelles versions, techniques comme pour le RFC 7818 remplacé par le RFC 9156, avec un algorithme légèrement différent, compte-tenu de l’expérience acquise entre-temps, ou parfois plus politiques, pour tenir compte des critiques habituelles que suscite le chiffrement, par exemple qu’il diminue les possibilités de surveillance (ce qui est bien son but). Plusieurs projets, comme le chiffrement de la communication entre le résolveur et les serveurs faisant autorité¹², n’ont pas réellement débouché, malgré quelques tentatives. L’IETF travaillant sur la base du volontariat, quand le travail n’avance plus, l’action habituelle est de fermer le groupe, en attendant une autre occasion. Le groupe DPRIVE a donc été dissous le 11 juillet 2025, après un peu plus de dix ans d’existence.

Vous avez pu noter dans cet article que l’IETF est très transparente. Tout le travail officiel est fait en public et archivé¹³, ce qui a été bien pratique pour écrire cet article.

Le bilan

Pour un projet IETF, « DNS et vie privée » a été relativement rapide. Entre la première réunion officielle, la BoF à Londres, et la publication des trois RFC essentiels, il ne s’est écoulé qu’un peu plus de deux ans. Pour un travail collectif, impliquant des dizaines d’acteurs de pays et d’opinions différents, ce n’est pas si mal. Et cela alors même qu’on dit souvent que les procédures internes de l’IETF sont lentes et rigides.

Le gros du travail a été l’écriture de trois RFC, le 7626 décrivant le problème, le 7816 sur la minimisation des requêtes, et le 7858 sur le chiffrement du DNS. Non seulement la norme technique a été écrite mais elle a largement été déployée. La minimisation des requêtes est aujourd’hui mise en œuvre dans tous les résolveurs, et souvent activée. Un test fait avec les sondes RIPE Atlas de France en novembre 2025 montre qu’une grande majorité de résolveurs semble utiliser cette minimisation.

Des systèmes d’exploitation grand public comme Android ont un client DoT intégré (Microsoft Windows 11 utilise DoH) et tous les résolveurs DNS publics acceptent DoT et DoH.

En résumé, le projet « DNS et vie privée » a été un succès, d’abord parce qu’il a réussi à faire en sorte que la question de la vie privée dans le DNS soit prise en compte, ensuite parce qu’il a permis la mise au point, puis le déploiement, de techniques qui protègent mieux cette vie privée.

1 Il y a quelques exceptions. Par exemple, les techniques pair-à-pair, comme Bitcoin, ne dépendent pas du DNS mais, en pratique, la très grande majorité de leurs utilisateurs utilisent ces services en passant par un site Web, donc ont quand même besoin du DNS. Je vous laisse chercher d’autres exceptions.

2 En termes techniques : une requête DNS passe par de nombreux AS, multipliant le nombre d’acteurs qui peuvent la voir passer.

3 Rappelons que DNSSEC utilise la cryptographie mais ne chiffre pas, il rend un service tout à fait différent, l’authentification des données, via une signature.

4 La liste est disponible sur le Datatracker, un des principaux outils de travail en ligne de l’IETF.

5 Mais c’est aussi bien sûr un jeu de mots avec le mot anglais deprive, priver de, en l’occurrence priver les surveillants d’informations.

6 C’est suite à cette réunion que sera publié le RFC 7258, où l’IETF s’engageait à tout faire pour rendre plus difficile la surveillance de masse.

7 Birds of a Feather, de la locution anglophone « birds of a feather flock together », équivalent de « qui se ressemble, s’assemble ».

8 Le cœur du travail de l’IETF se fait sur des listes de diffusion. Les réunions physiques ne sont pas censées prendre de décisions.

9 Au moins une autre proposition, qui n’a pas été adoptée, était de développer un nouveau protocole cryptographique, au lieu d’utiliser le classique TLS.

10 Sur une idée originale d’Olaf Kolkman.

11 Pour lesquels, comme d’habitude, les hackathons de l’IETF ont été une grande aide.

12 Les protocoles DoT et DoH n’ont été normalisés que pour une communication entre la machine de l’utilisateur final et le résolveur. Notez que le RFC 9539 tentait d’aborder la communication avec les serveurs faisant autorité, mais a été très peu déployé.

13 Le travail plus ancien est nettement moins bien archivé. Par exemple, lors de la mise au point de la QNAME minimization, qui débouchera sur le RFC 7816, une question avait été posée : pourquoi le DNS ne minimise t-il pas la requête et pourquoi transmet-il le nom complet ? Et, d’ailleurs, où est-il spécifié qu’il faut obligatoirement transmettre le nom complet ? La réponse n’était écrite nulle part et les gens qui avaient connu les débuts du DNS n’était pas trop sûrs de la réponse.