[jingle]

— Bonjour à toutes et à tous, bienvenue sur Graf'hit 94.9, vous écoutez La Voix Est Libre,

une émission créée par Picasoft, une association compiégnoise qui s'est donnée pour mission

notamment de sensibiliser les citoyens et les citoyennes aux enjeux du numérique et

qui héberge des services web libres et respectueux de la vie privée.

Alors pour l'émission d'aujourd'hui, je suis avec Talitha, salut Talitha.

— Salut Quentin.

— Et puis on va parler DNS, alors qu'est-ce que c'est DNS ?

Eh bien c'est tout l'objectif de cette émission, de découvrir en détail et pour

ce faire, on a le plaisir et l'honneur de recevoir Stéphane Bortzmeyer.

Bonjour Stéphane.

— Bonjour.

— Alors Stéphane, tu es ingénieur à l'AFNIC, l'AFNIC encore donc un acronyme

dont on ne sait pas bien ce que c'est dans le grand public.

Tu es à l'origine d'un des premiers sites français qui a été mis en ligne,

pionnier de la promotion du chiffrement en France.

Tu es notamment spécialiste des questions de DNS et tu écris beaucoup à ce sujet

et sur plein d'autres sujets sur ton blog bortzmeyer.org.

Talitha, je te passe la main pour les questions.

— Donc bonjour Stéphane, pour les questions, comme l'a soulevé Quentin, la première chose qu'on se demande,

c'est vraiment l'AFNIC, on n'en entend jamais parler et pourtant, c'est une association dont le rôle est essentiel

dans le fonctionnement du web, notamment en France.

Est-ce que tu peux nous expliquer un peu ce que c'est et surtout, quel est ton rôle dans cette association ?

— Alors, c'est vrai que l'infrastructure, on n'en entend jamais parler.

Ce n'est pas spécifique aux réseaux informatiques.

L'infrastructure, c'est tout ce qui est indispensable mais qu'on ne voit pas,

sauf quand il y a une panne et là, on s'en rend compte.

Et effectivement, une infrastructure essentielle pour l'Internet,

c'est le système des noms de domaines,

Domain Name System en anglais, DNS.

Donc, c'est tout ce qui permet, ces noms de domaines qu'on voit dans les publicités, sur les côtés des bus,

c'est tout ce qui leur permet de fonctionner.

Donc, vous voulez vous connecter sur Wikipédia, vous avez un nom de domaine, fr.wikipedia.org.

Le système des noms de domaines, c'est tout ce qui va faire qu'à partir de ce nom-là,

vous allez pouvoir atterrir au bon endroit, visiter le bon serveur et avoir les bons articles sous licence libre

que vous vouliez consulter.

Le rôle de l'AFNIC dans ce système qui est complexe, où il y a plein d'acteurs,

c'est d'être un registre de noms de domaines.

Donc, le registre, c'est un type avec une plume d'oie qui écrit sur un parchemin la liste des noms de domaines réservés.

Bon, en fait, il n'y a pas vraiment de parchemin, c'est une base de données.

Mais le concept est le même, c'est l'organisation qui garde trace de la liste de tous les noms de domaines existants,

des serveurs qui vont contenir les données sur ces domaines,

des contacts qu'il faut contacter s'il y a un problème administratif ou technique,

et qui s'assurent notamment de l'unicité de ces noms.

Le rôle de l'AFNIC va aussi plus loin, puisqu'il faut aussi gérer les serveurs de noms,

donc les machines qui distribueront ces informations.

Et puis, il y a d'autres serveurs, on a déjà entendu parler de whois,

qui permet d'accéder aux informations sociales, donc les contacts, leurs noms, leurs adresses,

leurs noms, sauf s'ils sont des personnes physiques, auquel cas le nom n'est pas diffusé.

Donc c'est toute cette activité qui, effectivement, n'est pas visible en temps normal,

mais est crucial quand il y a... est crucial quand même, et on s'en rend compte quand il y a un problème.

Alors moi, là-dedans, je n'ai pas de responsabilité opérationnelle,

je m'occupe de la formation, de la veille technologique, de la normalisation technique,

puisque l'Internet, ça fonctionne parce qu'il y a des normes que tout le monde

suit, des normes techniques que tout le monde suit,

qui permettent à un navigateur web libre comme Firefox de consulter un site web

et d'arriver sur une plateforme privatrice, ou le contraire,

parce que tout le monde suit la même norme technique, donc c'est un gros travail d'élaboration.

Et puis, je m'occupe effectivement de questions pointues liées au DNS,

où je... quand il y a des problèmes particuliers liés au DNS.

— Ok, très bien.

Et donc, en quoi est-ce que le DNS est carrément un élément critique du fonctionnement d'Internet ?

Alors, le DNS est un élément critique, parce que simplement, s'il est en panne,

pour la grande majorité des usages, c'est comme s'il n'y avait pas d'Internet du tout.

Ça s'est vu des fois dans certaines pannes, où pour l'utilisateur, pour monsieur ou madame tout le monde,

c'est vraiment comme s'il n'y avait pas d'Internet du tout, en effet, pratiquement toutes les transactions sur Internet,

commencent par un appel au DNS, puisqu'il faut commencer par obtenir des informations techniques à partir d'un nom de domaine.

Donc, vous vous connectez sur... vous voulez aller sur Wikipédia, le nom de domaine, ça va être fr.wikipedia.org,

votre navigateur Web va avoir besoin de l'adresse IP du serveur Web qui héberge Wikipédia,

pour ça, il fait appel au nom de domaine, plus précisément à deux composants essentiels :

les serveurs faisant autorité pour un nom de domaine qui connaissent ces informations et qui les diffusent.

Donc, dans le cas de .fr, c'est ceux de l'AFNIC ; dans le cas de Wikipédia.org, c'est ceux de la Fondation qui est derrière Wikipédia.

Et l'autre composant essentiel, c'est les résolveurs, qui sont des serveurs qui sont hébergés typiquement

sur votre fournisseur d'accès Internet ou par votre service informatique quand vous êtes dans les locaux de votre employeur.

Et ce sont eux qui vont interroger successivement plusieurs serveurs faisant autorité jusqu'à avoir la réponse qui va être renvoyée à Monsieur Tout-le-Monde,

ou plus exactement à son navigateur, et lui permettre, à la fin de se connecter, il va être content, il va pouvoir s'instruire, il va pouvoir regarder plein de choses.

Donc, du fait que tout commence par une requête au DNS, s'il est en panne, c'est comme s'il n'y avait pas d'Internet.

Donc, c'est vraiment une ressource critique.

S'il ment ou s'il est détourné, s'il y a une faille de sécurité, on peut être amené à tout autre endroit que celui qu'on voulait avoir.

Donc, c'est très important de soigner l'ensemble de l'écosystème DNS, qu'il soit bien géré, supervisé, qu'on fasse attention aux failles de sécurité,

que l'on fasse attention aux autorisations diverses,

il ne faut pas que je puisse, par exemple, modifier le nom de domaine de Picasoft ou de Wikipédia.

Il faut qu'un domaine ne puisse être modifié que par son titulaire ou les personnes qu'il a désigné.

Donc, voilà en quoi c'est une infrastructure critique.

Même si elle est purement logicielle, quand je dis infrastructure, les gens pensent des fois à du matériel, des trucs qu'on peut toucher, comme les câbles, par exemple.

Non, c'est purement logiciel le DNS, mais c'est quand même critique.

— D'accord. Mais donc, du coup, par rapport aux failles de sécurité dont tu as parlé, notamment le mensonge,

quelles sont les différentes actions qu'on peut faire dessus ?

Et voilà, comment est-ce qu'on travaille sur le DNS pour le maintenir et le sécuriser ?

— Alors, un exemple récent, par exemple, parce que ça a occupé une bonne partie de mon week-end,

c'est la faille log4shell, qui a fait pas mal de bruit récemment.

Donc, un composant logiciel libre utilisé dans un très grand nombre de programmes.

Un composant un peu planqué, un peu caché.

les utilisateurs ne voient pas une bibliothèque utilisée par les programmeurs,

qui est vraiment dans plein de programmes, probablement dans plein de machines sur l'Internet,

qui avait une faille de sécurité sérieuse.

Donc, pas mal d'acteurs de l'Internet ont passé le week-end à chercher,

à vérifier si leurs applications utilisaient log4j, la bibliothèque en question,

et si oui, si elle était vulnérable, et si elle l'était, les mises à jour ou les... [coupure] ...de tous les gens qui sont dans l'opérationnel,

c'est-à-dire qui font fonctionner l'Internet au quotidien, ça affecte aussi.

Donc, le DNS, il se trouve que la plupart, je crois, des registres de nombres de domaines

utilisent des programmes écrits en Java, le langage pour lequel la bibliothèque, log4j, est utilisée.

Donc, ça faisait potentiellement pas mal de problèmes qui auraient pu arriver, ou pas,

mais en tout cas, il fallait vérifier de toute façon.

Et les deux grands problèmes typiques, le risque de panne, ça, c'est le principal risque.

Ça ne s'est jamais produit depuis la création de l'AFNIC,

mais si ça se produisait, par exemple, suite à une panne matérielle,

suite à une attaque par déni de service, suite à des problèmes comme ça,

si on se retrouvait avec une partie des domaines qui ne fonctionnent plus,

ça serait évidemment catastrophique.

Il y a eu un cas réel il y a quelques années, par exemple, quand le domaine national turc .tr,

a fait l'objet d'une attaque par déni de service, qui était apparemment politiquement motivée,

donc une attaque qui visait à empêcher le domaine de fonctionner,

et ça avait malheureusement marché.

Donc, plus aucun nom de domaine ne se terminant au .tr ne fonctionnait,

donc plus personne ne pouvait visiter, par exemple, les sites web dont le nom se terminait en .tr,

ou les écrire à des gens dont l'adresse de courrier électronique se terminait en .tr,

enfin, vraiment la grosse catastrophe.

Donc, il y a tout un travail qui est fait pour éviter ça, à la fois,

préventif, avoir beaucoup de machines bien connectées et de supervision

pour s'assurer que tout ça fonctionne en permanence.

On passe beaucoup de temps à regarder des écrans avec du vert, et puis quand il y a du rouge dessus,

c'est qu'il y a un problème, il faut faire quelque chose, donc c'est un travail opérationnel permanent,

puisque le DNS doit fonctionner 24 heures sur 24, 7 jours sur 7, pas une milliseconde d'interruption,

puisqu'il y a certains services qui tournent sur l'Internet, qui sont cruciaux.

L'Internet, ça ne sert pas qu'à regarder des vidéos de chat,

il y a aussi des applications vraiment critiques, qui doivent marcher tout le temps.

L'autre gros problème, effectivement, c'est le risque de détournement de nom de domaine.

C'est compliqué, la sécurité des noms de domaine, il y a beaucoup d'aspects,

et donc, en gros, il s'agit de vérifier que le système respecte bien les autorisations,

qu'on ne puisse pas modifier le nom de domaine de quelqu'un d'autre,

surveiller qu'il n'y ait pas de failles qui vont apparaître.

C'est tout un travail aussi, qu'il faudrait des heures et des heures pour détailler tout l'aspect sécurité des noms de domaine.

Mais il y a beaucoup de choses derrière pour que ça fonctionne bien.

Là aussi, on en entend parler quand il y a un problème.

Par exemple, il y a deux ou trois ans, le nom de domaine de Wikileaks avait été détourné comme ça.

Quelqu'un avait réussi, je ne sais pas comment, je n'ai pas les détails,

mais on avait constaté que le nom de domaine avait été détourné,

que l'adresse IP données en échange de ce nom de domaine

pointait vers un serveur web qui n'était pas celui de Wikileaks.

Les médias, en général, avaient mal rendu compte de l'affaire,

comme c'est souvent le cas en sécurité,

en prétendant que le serveur web de Wikileaks avait été piraté.

Ce n'est pas du tout vrai.

C'était une attaque indirecte.

Le nom de domaine était détourné,

et donc, emmenait vers un autre serveur web

qui contenait un message insultant pour Wikileaks.

Donc, voilà le genre de choses.

Qui occupe les gens qui gèrent les noms de domaine,

et qui font...

Vraiment, le point important, c'est ce côté opérationnel.

C'est-à-dire, c'est quelque chose qui,

comme l'eau, comme l'électricité,

doit fonctionner en permanence,

malgré les pannes, les attaques, les problèmes,

comme log4shell récemment.

— Merci Stéphane pour ces réponses qui sont claires et complètes.

On te remercie également d'avoir été avec nous ce matin.

Et bonne journée à toi.

— Merci, au revoir.

— Merci beaucoup Stéphane, au revoir.

Bon, eh bien, on a bien dégrossi le sujet.

C'est chouette.

On va pouvoir enchaîner en essayant de détailler un petit peu

les sujets que Stéphane a abordés.

Comme il l'a dit, c'est vrai que DNS,

c'est un sujet qui, en plus d'être très peu souvent traité,

est extrêmement complexe,

notamment du point de vue de sa sécurité.

Donc, on va aller recommencer par la base

pour bien ancrer les esprits.

Est-ce que, Talitha, ça te dit de nous faire un petit rappel sur la base de DNS

et pourquoi est-ce qu'on s'en sert, on va dire, le plus traditionnellement ?

— Mais bien entendu, Quentin.

Donc, ce que je vais dire là maintenant

va peut-être recouper légèrement ce qu'a dit notre invité.

Mais on va replacer les termes pour partir sur des bases claires.

Donc, d'abord, DNS, c'est Domain Name System.

Donc, c'est un système de domaines de nom.

Et donc, ce système, il va définir les règles

sur lesquelles on s'accorde pour gérer un problème informatique donné et se comprendre sur le sujet.

Donc, c'est quoi la problématique dans le cadre du DNS ?

En fait, c'est simple. Pour parler entre eux,

les ordinateurs ont des adresses, comme nous.

Il faut bien avoir une adresse pour savoir vers qui aller.

Sauf que pour les ordinateurs, c'est un ensemble de chiffres qui peut être assez long

et pas très manipulable au quotidien.

Et donc, cette adresse s'appelle une adresse IP.

Pour ne pas avoir besoin de les manipuler au quotidien,

on va associer à chaque adresse IP un nom.

Donc, un nom de notre langage à nous, donc, beaucoup plus facile à exploiter

que ce soit pour les administrateurs réseau ou pour les utilisateurs, en fait.

Donc, par exemple, si vous voulez aller sur le site de Picasoft,

vous allez vous rendre sur le site https://picasoft.net

Sauf qu'en réalité, picasoft.net, ça ne mène nulle part en soi.

Ce qui va se passer, c'est que le DNS va gérer le passage du terme

picasoft.net à l'adresse réelle du serveur Picasoft qui va vous permettre d'accéder à la page web.

Donc, c'est pour cela qu'il existe ce qu'on appelle des serveurs DNS.

Il faut bien faire attention avec les serveurs DNS puisqu'il en existe deux types.

On va avoir les serveurs de nom, qu'on appelle parfois serveurs faisant autorité

comme l'avait souligné Stéphane, et ces serveurs sont chargés

de stocker les données de correspondance entre les adresses IP et les noms de domaine.

Donc, c'est eux qui ont les tables de correspondance et qui ont la donnée principale.

Et à côté de ça, on a également les résolveurs.

Les résolveurs vont faire le lien, en fait,

entre les machines qui ont recours au DNS pour accéder à une adresse

et l'adresse en question.

— Oui, c'est l'intermédiaire entre les serveurs de nom

qui ont la table dont tu parlais et le client qui, lui, veut savoir,

par exemple, à quelle IP correspond picasoft.net.

— Exactement. Donc, pour illustrer ça avec un exemple,

on va garder l'exemple de picasoft.net. Donc, si je veux accéder au site picasoft.net,

mon ordinateur va demander, au résolveur, c'est où picasoft.net ?

Le résolveur, à son tour, va demander au serveur de nom,

OK, donc picasoft.net, ça correspond à quelle adresse IP ?

Le serveur de nom lui donne l'adresse IP,

le résolveur peut me renvoyer l'adresse réelle de la machine de Picasoft

et ainsi, je peux me connecter au site.

Donc, voilà, ce rappel, c'était principalement pour

faire attention aux confusions sur le vocabulaire

parce que dans le langage courant,

on utilise pas mal les termes DNS, serveur DNS,

mais les termes sont plus précis que ça.

— Merci, Talitha, pour avoir reposé les bases.

Donc, bien sûr, quand on dit qu'une fois que vous avez interrogé le résolveur,

vous pouvez utiliser l'adresse pour contacter le site, c'est pas vous directement,

c'est bien votre navigateur, votre ordinateur qui fait tout ça en arrière-plan. Alors, comme

l'a dit Stéphane, DNS, c'est un système qui est absolument crucial pour le

fonctionnement d'Internet, puisque toute requête, toute action

qui implique un nom de domaine doit nécessairement passer par DNS afin d'obtenir

une adresse IP qu'un ordinateur sait contacter.

Donc, pas de serveur DNS, ça veut dire, notamment sur le web,

pas d'accès au service, quand bien même

celui-là est en pleine forme et fonctionnel.

Stéphane nous a donné un exemple,

on a un autre exemple récent avec Facebook qui, suite

à une erreur de configuration réseau, avait rendu ses serveurs de noms

inaccessibles. Et donc, à chaque fois que quelqu'un essayait d'aller sur Facebook,

eh bien, simplement, le serveur de noms ne répondait pas, donc on n'avait

pas d'adresse IP, donc c'est comme si Facebook n'existait pas.

Et donc, c'est d'autant plus crucial aujourd'hui qu'un des premiers

problèmes qu'on va traiter là tout de suite, qui est lié à DNS,

c'est le fait que les serveurs de noms,

donc les serveurs faisant autorité, soient très centralisés

Alors oui, on va parler que des problèmes aujourd'hui, puisque

c'est vraiment notre moto ici.

Alors en fait, on a une étude qui a été faite récemment

qui essaie de regarder qui sont les principaux fournisseurs de serveurs de noms, puisque la

plupart des sites web et des entreprises, ou quoi, n'hébergent pas leurs propres serveurs

de noms, ce qui est un problème. Et sur les 100 000 sites les plus visités, selon le classement

Alexa, eh bien, 24% de ces sites utilisent Cloudflare,

une grande entreprise qui a notamment fourni des serveurs de noms. AWS,

donc Amazon Web Services, pour 12%, et GoDaddy pour 4%. Et donc, c'est-à-dire

que pour 38% des 100 000 premiers sites du classement Alexa, on a seulement

3 fournisseurs de serveurs de noms. Donc si jamais il y avait une panne sur

un de ces fournisseurs, eh bien, ça ferait un quart du web qui serait inaccessible.

Notamment en 2016, Dyn, qui est aussi un fournisseur de serveurs de noms,

qui propose aux entreprises, a été victime d'une grande attaque par déni de service,

qui a paralysé les opérations de l'entreprise et par la même, qui a interrompu

toutes les opérations de résolution de non de domaine pour plus de 175 000 sites

web. Donc là, on commence à s'apercevoir qu'il y a quand même beaucoup de

problèmes qui se jouent de manière un petit peu invisible. Mais avant

de réattaquer sur le vif du sujet, peut-être qu'on peut se demander comment est-ce que

c'est arrivé DNS, comment on faisait au tout début d'Internet, voire même avant Internet, Talitha ?

— Eh bien, en fait, au tout début d'Internet, même avant le web, en 1969,

toutes les correspondances entre les noms de domaine et les adresses IP tenaient en un seul fichier.

C'était un fichier qui était commun à tous les utilisateurs d'Internet,

puisqu'à cette époque, il n'y en avait pas..., enfin, c'était gérable.

Et ce fichier s'appelait hosts.txt, il était centralisé.

En quelques années, c'est devenu assez

ingérable, étant donné la grande augmentation du nombre d'utilisateurs.

Et donc, ça n'a plus été possible de fonctionner avec juste un fichier.

Et c'est alors qu'on a créé... Il y a eu plusieurs solutions proposées, mais

en 1983, la solution proposée qui a été retenue, ça a été le DNS, donc

un système qui permet la résolution de noms, mais pas avec un seul fichier centralisé,

comme ça l'était initialement, mais en redistribuant la tâche de

résolution de noms à plusieurs serveurs qui sont organisés hiérarchiquement.

Et donc, Quentin, quelle est donc cette hiérarchie dans le DNS ?

— Quel ping-pong endiablé !

Non, mais effectivement, c'est pas possible, en fait, quand on voit la

quantité de noms de domaine qu'il existe aujourd'hui, de travailler avec un espèce

d'annuaire global et centralisé. Ce serait déjà pas possible et sans doute pas souhaitable.

Donc, DNS, c'est un système qui a été pensé dès le début pour être hiérarchique

et distribué. Donc, il n'y a pas de pouvoir central ni d'annuaire global, comme je l'ai dit.

Alors, comment est-ce qu'on la voit, cette hiérarchie ?

Eh bien, en fait, on la voit quand on regarde un nom de domaine. Un nom de domaine, on voit bien

qu'il est composé souvent de plusieurs parties. Par exemple, picasoft.net,

on a le picasoft et le net.

Et donc, le système des noms de domaine, c'est une hiérarchie,

on peut voir ça comme un arbre, dont le sommet unique est appelé la racine.

Et on représente la racine par un point,

c'est, en fait, virtuellement comme si on rajoutait un point à la fin de tous

les noms de domaine. Donc, « picasoft.net. ».

On ne le met pas par commodité.

Donc, à partir d'un domaine, on peut créer un ou plusieurs sous-domaines.

Et ce qui se passe, c'est que chaque partie d'un domaine

va correspondre à ce qu'on appelle une zone DNS.

Alors, je m'explique. Par exemple, fr, c'est une zone

DNS. Et tout ce qu'il y a en dessous d'fr, par exemple,

gouv.fr, eh bien, gouv va être une autre zone DNS.

Et en fait, ce qui se passe, c'est que dans ce cas-là,

la zone fr, a délégué la gestion de la zone gouv aux personnes qui gèrent la zone gouv.

Et donc, on peut avoir ce système hiérarchique au sens où chaque zone délègue

à des sous-zones qui correspondent aux sous-domaines.

Alors, je vais donner un autre exemple. picasoft.net, donc la racine, c'est le point qui aurait à la fin,

Le point net est une autre zone gérée par, sans doute, une organisation comme l'AFNIC qui gère les points fr,

picasoft.net, ça, c'est une zone que nous, on gère. Et tout ce qui est en dessous de picasoft.net, par exemple,

tout ce qui est en .test.picasoft.net, c'est aussi nous qui le gérons.

Donc, en fait, on a une zone qui descend jusqu'à l'infini en dessous de picasoft.net.

Donc, les domaines qui se trouvent immédiatement

sous la racine, on les appelle domaines de premier niveau ou TLD pour Top Level

Domain. Donc, ça, c'est tous les .fr, .net, .org, etc.

Et ceux qui ne correspondent pas à une extension de pays

sont des domaines génériques, donc, gTLD, générique TLD,

par exemple, les .org ou les .com. Et donc, pour la résolution, c'est exactement pareil.

On va, quand un résolveur essaye de nous dire qu'est-ce que c'est pad.picasoft.net,

eh bien, en fait, il va commencer par interroger la racine pour avoir tous les serveurs qui sont capables de lui dire

où aller demander les informations pour .net.

Ensuite, il va demander aux serveurs qui ont les informations pour .net où je peux trouver pad.picasoft.net.

Ces serveurs-là vont dire non, ce n'est pas nous qui nous en occupons, c'est les serveurs de nom picasoft.net qu'on peut trouver à cette adresse-là.

Donc, mon résolveur va ensuite aller interroger les serveurs de picasoft.net qui vont dire, ah ben moi,

j'ai l'information et l'adresse de pad.picasoft.net, c'est cette adresse IP.

Alors, on note peut-être pour terminer que en pratique, il y a tout un système, et c'est important pour la suite aussi, de cache.

Ça veut dire que les résolveurs, très souvent, vont retenir des informations qu'on leur a données

de manière à ne pas aller tout le temps réinterroger à chaque requête les serveurs racines, voire les serveurs de .net, puisque sinon,

vu les millions, dizaines de millions de requêtes, sans doute plus, qui ont lieu à chaque seconde,

les serveurs racines devraient répondre la même information ou trouver les infos pour .net, .fr, .org en permanence.

Alors, maintenant qu'on a laborieusement esquissé une idée de comment fonctionnait le système hiérarchique des noms de domaine,

on va voir que ça pose pas mal de problèmes dont Stéphane a déjà un petit peu parlé.

Et pour le premier problème, c'est un problème de vie privée.

Talitha, si tu veux prendre la main.

— Bien évidemment. Le problème de vie privée, en fait, c'est que

comme on l'a précisé au début, ce sont des grosses structures qui détiennent la majorité des DNS qu'on utilise au quotidien.

Ça va être Google, Cloudflare ou encore nos fournisseurs d'accès Internet.

Et donc, comme ce sont eux qui effectuent la résolution de nom, ils récupèrent tous les noms de domaine, toutes les

adresses des sites auxquels on veut accéder.

Donc, en fait, on est en train de faire on est en train de fournir à d'autres institutions notre historique de navigation.

Comme on peut l'imaginer, ça pose un problème de vie privée en fonction de la structure en question. Une solution qui existe par rapport à ça, c'est d'aller faire,

d'aller avoir recours à un résolveur libre, mais c'est compliqué et c'est parfois compliqué à mettre en place au quotidien.

Et donc, c'est une solution existante, mais pas forcément commune ou viable.

— Oui, d'autant que, en fait, sur la plupart de nos appareils, on n'est même pas au courant que les résolveurs qui sont préconfigurés,

c'est ceux de Google. Comme tu dis, c'est pas forcément évident d'aller l'échanger sur le téléphone ou autre.

— Oui, voilà, c'est le genre de problème où la solution est simple, mais le plus gros pas, c'est d'aller savoir qu'il y a un problème.

— Exactement. Ensuite, un deuxième souci qui est assez généralisé, c'est le problème de la censure et

ce qu'on appelle les DNS menteurs. Donc, c'est des raisonneveurs qui vont nous renvoyer une fausse réponse.

Donc, là, je reprends la définition que j'ai récupérée dans un rapport de l'AFNIC sur le filtrage.

Le filtrage consiste à modifier le processus normal de résolution d'un nom d'un serveur vers une adresse IP, soit en bloquant

la réponse, soit en répondant un message d'erreur, soit en retournant l'adresse d'un autre serveur indiquant généralement que l'accès à ce site est interdit.

Donc, on a plein, plein d'exemples en France avec Sci-hub, dont on a parlé dans les émissions sur l'Open Science, qui contient une des versions piratées de beaucoup de papiers d'articles scientifiques en accès libre,

ou de The Pirate Bay, un site de Torrent.

Donc, ce qui se passe dans ces cas-là, c'est que le gouvernement français demande à la plupart des fournisseurs d'accès Internet français de mentir au niveau de leur résolveur,

quand on leur demande à quelle adresse IP appartient ce service.

Dans ce cas-là, ils répondent simplement « Non, je ne connais pas ce service », alors qu'ils savent très bien quelle est l'adresse IP. Donc, ça fait comme s'il n'existait pas,

alors qu'en réalité, il est bien accessible. On a un autre exemple en 2016, où une erreur de redirection de certains sites Internet

pour les clients de Orange faisait que les sites comme Google ou Wikipédia étaient redirigés vers la page de blocage des sites incitants au terrorisme

ou en faisant l'apologie qui est hébergée par le ministère de l'Intérieur. Donc, on se réveille un matin, on va aller sur Wikipédia et hop, on a une page qui nous dit qu'on a essayé d'aller sur un site

terroriste, donc un exemple un peu visible de DNS menteur que le grand public a pu voir, mais en général, on ne s'en rend pas bien compte.

Donc, c'est un peu finalement plus ou moins la même solution que Talita ait proposée. Pour les problèmes de vie privée,

on essaie d'utiliser, un résolveur de quelqu'un en qui on a confiance et qui est respectueux de la vie privée,

par exemple, qui pourrait être proposé par un CHATONS ou un FAI associatif comme la FDN,

parce qu'en général, ces résolveurs sont aussi libres, c'est-à-dire qu'ils ne vont pas mentir.

Donc là, c'est la même réponse. Alors, sachant que en général, les résolveurs de Google ne mentent pas,

mais eux ne font enfin, il faut accepter les conditions d'utilisation de Google qui, comme chacun sait, sont très respectueuses de notre vie privée.

— Quand tu dis que les résolveurs libres ne vont pas mentir, quel est le lien un peu plus explicite entre un service libre et le fait qu'ils ne mentent pas à ses utilisateurs ?

— Alors, il n'y a pas de lien direct, c'est plus une sorte d'heuristique, c'est aux doigts mouillés, c'est qu'en général,

les CHATONS ou autres associations qui proposent des services basés sur des logiciels libres, etc., en général font attention à la vie privée, mais je pense qu'ici, oui, c'est plus la terminologie libre.

Il y a les résolveurs qui ne mentent pas, dont fait partie Google, ceux de la FDN, etc., et ceux qui sont respectueux de la vie privée, comme ceux de 42L et/ou de la FDN.

— Oui, dans le domaine du libre, il y a une plus grosse confiance, quoi.

— Oui, en général. Après, ce n'est pas une règle absolue. Bien sûr.

Alors, le problème, même si on utilise un résolveur, allez, libre et respectueux de la vie privée,

c'est que ça ne résout pas, en fait, tous les problèmes.

Alors, la première chose qui reste à résoudre, c'est la gestion de la vie privée, mais au niveau des intermédiaires.

Parce que, comment dire, déjà, les requêtes DNS sont faites entièrement en clair,

c'est-à-dire que n'importe qui qui est entre vous et le résolveur DNS peut espionner la requête dans les tuyaux et donc voir quel site vous avez essayé de consulter.

Donc, c'est bien d'avoir un fournisseur, un résolveur en bout de chaîne qui respecte la vie privée,

mais ça ne résout pas ce problème d'espionnage au milieu.

Et, même avec ça, il reste un souci central, c'est que si quelqu'un arrive à se faire passer pour un résolveur DNS,

c'est-à-dire se met, par exemple, entre vous et le vrai résolveur DNS,

c'est comme s'il contrôlait entièrement le résolveur et même comme s'il contrôlait entièrement le serveur de nom, puisqu'il va pouvoir vous répondre

n'importe quoi. Donc, imaginez si, par exemple, la zone fr se fait avoir, tout ce qui est en dessous de .fr potentiellement pourra renvoyer des fausses informations,

et même si la zone fr ne se fait pas avoir, si quelqu'un entre vous et les résolveur disent n'importe quoi pour la zone fr.

Donc, pour illustrer, on a un exemple plus concret. Par exemple, en Turquie, en 2014, donc, contexte politique très tendu, le gouvernement turc a essayé de bloquer, notamment,

Twitter et YouTube. Donc, pour ce faire, ils ont commencé, comme on fait en France, par du mensonge DNS classique.

Donc, demander aux FAI de dire qu'ils ne connaissaient pas Twitter, globalement, à leur résolveur.

Mais, comme les Turcs, ils étaient malins et qu'ils utilisaient, justement, des résolveurs DNS qui ne mentent pas, et c'était d'ailleurs ceux de Google à l'époque,

eh bien, le gouvernement turc s'est décidé à usurper carrément les résolveurs de Google en interceptant les requêtes qui lui étaient

destinées directement sur le matériel réseau de son fournisseur d'accès à Internet Turkish Telecom,

en se faisant donc passer pour les résolveurs DNS de Google.

Et le tout sans que ce soit détectable par le client.

Alors, comment c'est possible ?

Eh bien, tout simplement parce que DNS a été créé à l'époque où Internet n'était pas un réseau public

où il fallait une carte pour entrer, et donc n'a pas de mécanisme de sécurité qui a été pensé et intégré pour garantir l'authenticité des réponses et leur intégrité.

Donc, au-delà de pouvoir faire une censure à si large échelle, ce qui est déjà très grave,

en plus, DNS, il n'est pas seulement utilisé pour pouvoir consulter un site web, récupérer l'adresse IP d'un site web,

mais aujourd'hui, il est utilisé pour plein d'autres choses que cette translation-là et de plus en plus utilisé pour sécuriser Internet. Donc, typiquement,

dans DNS, on va trouver plein d'autres informations que la correspondance nom de domaine IP. Pour un nom de domaine précis, on va par exemple trouver des indications,

qui disent, qui a le droit, quelle IP a le droit d'envoyer des mails pour un nom de domaine ?

Donc, typiquement, quand moi, je reçois un mail qui vient de, je ne sais pas, matermost.picasoft.net, je peux aller vérifier dans la zone DNS de Picasoft

si l'adresse IP du serveur de mail qui me l'a envoyé est bien celle qui a le droit, afin que quelqu'un ne puisse pas usurper les mails en picasoft.net.

Le mail qui est très peu sécurisé de base, comme DNS.

Il y a d'autres informations dans les zones DNS, comme par exemple, on ne va pas en parler ici, ça fera l'objet d'une autre émission sur le mail,

mais tout un tas de choses qui permettent de s'assurer que les mails qu'on reçoit sont bien authentiques et aussi n'ont pas été modifiés sur le trajet.

Donc, là, avec ce qu'on vient de voir, quelqu'un qui peut se faire passer pour le serveur d'un nom de domaine,

peut absolument tout usurper. Et se donner tous les droits, comme faire semblant d'envoyer des mails valides, rediriger sur un autre site.

Et donc, on voit que si jamais ça fonctionnait comme ça en pratique, ce serait dramatique comme ce qui a pu se passer en Turquie. Donc, comment résoudre ce problème ?

Eh bien, c'est une question compliquée, comme l'a expliqué Stéphane dans l'interview. Et donc, avant d'y répondre, on va faire une petite pause et s'écouter une petite musique.

Cette semaine, on va écouter Disrupt de Louis Lingg and the Bombs sur l'album >_...checking system...disruption detected..., qui vient d'être publié et c'est sous licence Creative Commons BY-NC-SA.

Bonne écoute !

[musique]

— De retour dans La Voix Est Libre.

Alors, un résumé très bref de ce qu'on a dit dans la première partie de l'émission.

DNS, c'est le système de nom de domaine qui permet notamment de faire l'association

entre un nom de domaine, quelque chose de facile à retenir comme picasoft.net,

et une adresse IP, comme une adresse physique, une adresse postale pour les humains,

que l'ordinateur utilise pour contacter réellement les services à qui on essaie de parler.

On a vu que c'était un point crucial de l'Internet,

puisqu'à chaque fois qu'on utilise un nom de domaine,

il faut faire une requête à un résolveur DNS qui va pouvoir aller interroger les serveurs de nom qui, eux, contiennent l'information,

quelle IP, par exemple, correspond à quel nom de domaine.

Et donc, que s'il y avait des problèmes de sécurité au niveau de DNS,

c'est tout l'Internet qui s'en trouverait impacté.

Les problèmes de sécurité, ils sont de deux types.

Le premier, c'est les problèmes de confidentialité,

puisque les requêtes DNS transitent sur le réseau entièrement en clair.

Et donc, n'importe quel indiscret qui écouterait le réseau

pourrait intercepter toutes les requêtes DNS que fait votre ordinateur.

Donc, savoir globalement tout votre historique, etc.

Et le deuxième problème, c'est un problème d'authenticité,

n'importe qui pourrait, dans ce monde, puisque DNS a été créé,

à une époque où l'Internet n'était pas public et donc pas sécurisé,

n'importe qui pourrait se faire passer pour un serveur de nom

ou intercepter les requêtes à un résolveur et vous répondre n'importe quoi.

Et donc, les conséquences seraient dramatiques

vu que DNS est tout le temps utilisé pour savoir

quelle est la bonne machine sur laquelle on veut aller,

est-ce que ce mail est bien authentique, etc.

Donc, pour résoudre ces problèmes,

on va utiliser deux techniques qui sont basées sur les maths et la cryptographie,

le chiffrement et la signature.

Et donc, on va essayer d'introduire ça calmement avec des métaphores

pour bien vous convaincre que c'est des méthodes efficaces

et on va voir comment elles sont mises en œuvre ensuite.

Alors, Talitha, c'est parti pour une merveilleuse introduction au chiffrement.

— Donc, pour le chiffrement, en fait,

chiffrement, cryptographie, c'est un peu des mots, des grands mots.

Le principe du chiffrement, c'est vraiment le principe d'un message codé.

Le principe, c'est que si je veux envoyer un message à Quentin

et qu'il y ait juste, Quentin et moi qui le comprenions,

on va se mettre d'accord sur un code qui fait que j'applique une règle sur mon message.

Quentin connaît la règle également et donc, du coup, toutes les personnes entre les deux

qui vont entendre le message vont trouver qu'il n'a aucun sens.

Mais Quentin, à la réception, lui, il pourra réappliquer la règle inverse et comprendre ce qui se passe.

Pour donner une métaphore simple pour comprendre le principe,

on va parler du chiffre de César.

En fait, c'est un système de chiffrement où, pour chaque lettre d'un message, du message initial,

on va décaler de trois lettres vers la droite.

Donc, si la lettre, c'est un A, on va écrire à la place un C. Si la lettre est un B, on va écrire à la place un D, etc.

Donc, j'écris mon message, mon message initial, ce que j'appelle le message en clair.

On appelle un message en clair, en fait, avant chiffrement.

J'écris mon message initial, je lui applique le chiffre de César et je l'envoie à Quentin.

Quentin connaît la règle du chiffre de César,

donc, du coup, il peut redécaler de trois lettres vers la gauche et comprendre ce qui se passe.

Mais, au milieu, toute personne qui a lu le message ne comprend rien, puisque ce ne sont plus les mêmes mots.

C'est ce qu'on appelle le chiffrement symétrique.

On a une seule manière, disons que c'est la même méthode qui est utilisée pour chiffrer et pour déchiffrer.

Cette méthode, on l'appelle une clé. Donc, on a une clé unique.

Le problème du chiffrement symétrique, c'est que, imaginons que Quentin et moi,

on n'ait pas pu se mettre d'accord sur le code de manière sécurisée.

Imaginons qu'il y ait des gens toujours autour ou qu'on soit à distance.

Comment on fait pour se mettre d'accord sur une règle,

puisque, vu qu'on n'a pas de chiffrement avant de faire ce chiffrement,

forcément, notre règle va être visible par tout le monde.

Donc, ça ne sert plus à rien.

Pour résoudre ce problème,

on a inventé ce qui s'appelle le chiffrement asymétrique.

Au lieu d'avoir une clé unique qui va permettre de chiffrer le message,

on va en utiliser deux. On va expliquer ça avec une autre petite métaphore.

C'est comme si, au lieu de juste envoyer le message à Quentin, je prenais une boîte.

Une boîte en bois, quoi.

Il y a un cadenas dessus et une fente.

Donc, moi, je ferme le cadenas avec une clé.

Cette clé, on va l'appeler la clé privée Je la garde avec moi.

Du coup, moi, je possède une clé physique.

Et ensuite, j'envoie la boîte verrouillée à Quentin.

Donc, tout le monde peut voir la boîte.

Ça, il n'y a pas de problème. Quentin, quand il reçoit la boîte, il va écrire son message.

Donc, son message en clair, en fait. Il va juste écrire ce qu'il a à me dire. Il le met dans la boîte.

Il n'a toujours pas accès à l'intérieur de la boîte. Il n'y a que moi qui peux ouvrir la boîte

puisqu'il n'y a que moi qui ai la clé. Il le renvoie, et donc, à ce moment-là, il n'y a pas de problème à faire circuler le message.

Le message, il est dans la boîte. Tout le monde voit la boîte, tout le monde voit le bout de bois.

Mais personne ne peut lire ce qu'il y a à l'intérieur. Et quand je le reçois, vu que moi, j'ai la clé, je peux ouvrir la boîte, le lire.

Donc, ça, c'est le chiffrement asymétrique où la boîte, c'est ce qu'on va appeler une clé publique.

Tout le monde peut la voir, il n'y a pas de problème. Et la clé, c'est ce qu'on appelle une clé privée.

Si quelqu'un la trouve et a la clé publique et la clé privée, alors il peut lire les messages. Donc, voilà pour un bref rappel du principe du chiffrement sur lequel reposent les principes de signature que va vous expliquer Quentin.

— Oui, carrément. Et d'ailleurs, notons que ce chiffrement-là, c'est celui qui est vraiment utilisé partout sur Internet.

Quand vous avez le cadenas quand vous consultez un site web pour HTTPS, c'est le chiffrement asymétrique qui est utilisé, pour les cartes bancaires, etc.

Ça repose sur ces mêmes principes. Alors, la métaphore de la boîte, elle est très bien pour comprendre le chiffrement.

C'est comme si j'envoyais plein de boîtes à tout le monde que les gens pouvaient mettre plein de messages dedans

et moi, j'étais le seul propriétaire de la clé pour le déchiffrer.

Mais elle ne marche que dans un sens, alors qu'en fait, le vrai chiffrement asymétrique, il marche dans les deux sens.

Ça veut dire que tout ce qui a été chiffré avec ma clé privée,

en réalité, la clé privée peut aussi permettre de faire un chiffrement,

va pouvoir être déchiffré par ma clé publique.

Alors là, à ce stade, on pourrait se demander quel intérêt de chiffrer un truc avec la clé dont je suis le seul propriétaire

et tout le monde pourrait le déchiffrer vu que ma clé publique est publique.

Genre, c'est un peu nul ton truc. Eh bien, en fait, ça permet de faire des signatures.

Une signature, c'est ce qui va permettre de certifier l'authenticité, comme quelque part une signature réelle sur un chèque

ou autre chose, donc c'est bien moi qui ai fait cette signature.

Mais en plus, ça permet aussi de certifier l'intégrité d'un document ou de n'importe quoi,

ce qui est un peu différent de la signature du monde réel. Alors, qu'est-ce que ça veut dire ?

Et comment on fait ? Alors, en résumé, le processus de signature,

on va commencer par calculer une sorte d'empreinte du message ou du document qu'on peut envoyer

et c'est comme, on va dire, une empreinte digitale qui serait unique

pour chaque document. Alors, c'est des maths, on ne rentre pas dans le détail, mais imaginons

que tous les messages du monde, tous les documents aient une empreinte digitale unique.

Donc, on va prendre cette empreinte digitale et puis on va la chiffrer avec la clé privée,

dont je suis le seul à l'avoir, je chiffre l'empreinte et je l'envoie à côté du message que j'envoie en clair

ou que je peux aussi envoyer chiffrer, pourquoi pas.

Ce qui va se passer, c'est que tout le monde peut déchiffrer cette empreinte que j'ai chiffrée

vu que tout le monde a ma clé publique et va pouvoir, à son tour, calculer l'empreinte du message

qui a été effectivement reçue et comparer cette empreinte avec l'empreinte que moi j'avais chiffrée.

Et donc, qu'est-ce qui se passe si jamais c'est la même empreinte ?

Et bien, ça veut dire que le message est intègre, il n'a pas été modifié sur le trajet.

Parce que si quelqu'un avait modifié le message sur le trajet,

pour que ça ne se voit pas, il aurait aussi fallu qu'il modifie l'empreinte chiffrée qui était adjointe au message.

Or, pour pouvoir la modifier, il aurait besoin de ma clé privée.

Sinon, les gens ne pourraient pas déchiffrer l'empreinte avec ma clé publique et se rendraient compte qu'il y a un problème.

Donc, ce mécanisme de signature est extrêmement malin puisque, si jamais la signature d'un message,

je peux la déchiffrer avec la clé publique de quelqu'un, et qu'en plus le contenu, l'empreinte qui est à l'intérieur

est la même que l'empreinte du message effectivement reçue,

j'ai la certitude que c'est bien la personne que j'ai en face qui m'a envoyé

ce message, et qu'en plus, ce message n'a pas été modifié. Ou alors, l'autre alternative, c'est que sa clé privée a été compromise,

mais dans ce cas-là, c'est la merde. C'est comme si les mots de passe sont compromis, ça ne fonctionne pas très bien.

Alors, du coup, quand on revient à nos problèmes de confidentialité

au niveau de DNS, c'est-à-dire que tout le monde peut voir les requêtes qui sont effectuées

entre moi et le résolveur, donc potentiellement voir mon historique, et d'authenticité

à savoir, est-ce que le résolveur qui me répond, me répond vraiment les informations qui sont contenues

dans la zone, dans le serveur de nom ? Eh bien, on utilise le chiffrement et la signature. Le chiffrement

va être utilisé pour la confidentialité sur toute la chaîne, entre moi et le résolveur DNS.

Donc, il y a plein de solutions qui ont été proposées pour implémenter ce chiffrement.

Une des plus populaires aujourd'hui, qui est implémentée dans les navigateurs web,

c'est DoH pour DNS over HTTPS.

Ça consiste à utiliser le protocole sécurisé du web, HTTPS,

et d'encapsuler à l'intérieur de ce protocole les requêtes DNS.

Donc, ça se configure très facilement dans un navigateur.

Alors, on a une association qui fait partie du même collectif

que Picasoft, qui s'appelle 42l, qui propose un tel service,

et donc vous pouvez, par exemple, aller sur 42l.fr

et dans la rubrique services, vous trouverez un lien DoH qui vous explique comment utiliser leur résolveur DNS accessible via DoH,

DNS over HTTPS, dans votre navigateur. Et donc ainsi, toutes les requêtes DNS que font votre navigateur seront sécurisées, personne ne pourra écouter entre les deux.

Puisque, par défaut, vraiment, les fournisseurs d'accès à Internet, vu que c'est les résolveurs par défaut qui sont utilisés,

quand vous vous connectez à votre box, ont tout votre historique.

Donc ça, c'est la première solution pour la confidentialité au niveau des tuyaux, on va dire.

Et pour l'absence d'usurpation, alors là, c'est vraiment, on pourrait faire

une émission entière là-dessus, donc je vais essayer de résumer. On utilise ce qui s'appelle DNSSEC.

DNSSEC, c'est une extension, en fait, de DNS, DNS Security Extensions. Ça a été standardisé en 2005.

Et l'idée, c'est d'utiliser la signature cryptographique pour garantir l'intégrité et l'authenticité des données renvoyées par les résolveurs.

L'idée, elle est simple, c'est que chaque zone a une paire de clés, publiques et privées,

et va signer cryptographiquement l'ensemble de ces enregistrements. Donc, par exemple, à picasoft.net,

on n'utilise pas encore DNSSEC, parce qu'on est des mauvais élèves, mais si picasoft.net avait voulu sécuriser

ce qu'on appelle ces enregistrements, donc les correspondances,

par exemple, entre adresse IP et nom de domaine,

ce qu'on ferait, c'est qu'on dirait ok, très bien, pad.picasoft.net

c'est 91.158.... je ne sais pas quoi, et on adjoindrait un autre enregistrement

qui calculerait l'empreinte du message pad.picasoft.net c'est 91.... machin et qui le chiffrerait avec la clé privée de picasoft.net.

Alors, on pourrait se dire à ce stade, très bien, mais comment est-ce qu'on est sûr ?

Où est stockée finalement la clé publique qui va permettre aux gens de vérifier que l'empreinte est bien la bonne, etc. ?

Eh bien, on la stocke directement dans notre zone, mais pour que... Mais à ce moment-là, n'importe qui pourrait

très bien se mettre au milieu du résolveur et de moi, et puis inventer une fausse paire de clés publiques et privées

et puis faire semblant d'avoir des enregistrements qui sont bien signés, etc.

C'est pour ça que, par-dessus, on va aussi demander aux propriétaires

de la zone .net de stocker et de signer notre clé publique. Alors, ça devient peut-être un peu compliqué

comme gymnastique mentale, mais ça permet, si vous voulez, d'avoir une espèce de chaîne de confiance où on va pouvoir

vérifier, en remontant au fur et à mesure, que la clé publique associée à une zone a bien été signée par la zone du dessus, qui, elle-même,

sa clé publique a bien été signée par la clé privée de la zone du dessus, etc. Donc, tout ça pour dire que, si, dans ce mécanisme-là,

on voulait pouvoir usurper la clé publique de picasoft.net, eh bien, il faudrait réussir à récupérer la clé privée de la zone .net pour signer la fausse clé publique de picasoft.net.

C'est un peu laborieux. Du coup, je pense que c'est déjà pas mal pour une introduction.

Donc, pour résumer, en fait, ces deux solutions, elles ne fonctionnent pas totalement de concert, c'est-à-dire que

le problème de la confidentialité pour les intermédiaires et le problème de l'intégrité, c'est deux solutions qui sont très différentes,

qui sont apportées, c'est une de l'utilisation du chiffrement pour chiffrer, on va dire, de bout en bout, entre moi et le résolveur,

et celui de l'intégrité pour garantir que la zone n'a pas été modifiée, que c'est bien

les propriétaires de la zone qui ont donné les bonnes correspondances entre nom de domaine et adresse IP.

Notamment, c'est pas parce que vous utilisez DoH, donc DNS over HTTPS, que DNSSEC est utilisé. Et d'ailleurs, DNSSEC,

il n'est pas très très utilisé aujourd'hui, quand bien même, ça a été standardisé 2005, la preuve, chez Picasoft,

encore une fois, on n'est pas des bons élèves, puisqu'on gère nous-mêmes notre serveur de nom.

Donc, notamment, il y a assez peu de clients, les clients, c'est votre navigateur ou toute autre chose qui

fait appel à un résolveur, qui vérifie que les enregistrements DNSSEC sont valides, qui vérifient justement, qui font ce travail de déchiffrer

la signature, de vérifier qu'elle correspond bien à l'enregistrement, etc. Je crois que c'est le l'APNIC,

donc c'est pour l'Asie Pacifique, comme l'équivalent de l'AFNIC, qui estime qu'il y a seulement 29% en moyenne d'enregistrements DNSSEC qui sont

validés. Donc, ça veut dire que 70%, si j'interprète bien, je ne suis pas totalement sûr, des requêtes, alors soit des requêtes

générales dans le monde qui ne sont pas validées...., soit 70% des requêtes qui n'utilisent pas DNSSEC,

soit 70% des requêtes qui ont une signature qui ne sont pas vérifiées.

Bref, dans tous les cas, c'est trop peu.

Eh bien, voilà pour moi tout ce que j'avais, à raconter. Je pense

qu'on peut s'arrêter là. C'est déjà pas mal.

— Je pense qu'on a déjà un beau panel de problèmes et de solutions pour aujourd'hui, effectivement.

— Allez, c'est vendu. On s'arrête là.

Vous pouvez, comme d'habitude, retrouver ce podcast, cette émission, sur radio.picasoft.net, où on

mettra les liens de tous les services dont on a parlé, et puis nos sources.

Et puis, n'hésitez surtout pas à aller lire le blog de Stéphane, donc sur bortzmeyer.org, blog dont

on s'est pas mal inspiré pour trouver des exemples et monter nos explications.

Eh bien, d'ici la prochaine émission, on vous souhaite une excellente journée. Salut Talitha, et puis à la prochaine.

— Salut Quentin.