Le DNS, le protocole qu'on ne regarde jamais

Éditorial

Chaque connexion commence par une question posée en clair à un résolveur que l'on n'a, le plus souvent, pas choisi. DNSSEC, DoT et DoH corrigent chacun une partie du problème, et aucun ne dispense de la vraie décision : à qui confier la liste de tout ce qu'on consulte.

Mis à jour le 25 septembre 2026~24 min de lecture12 sections

papy cyber

→ Lire l’explication complète de la marmotte

La question avant la question

Toute connexion sur Internet commence par un aveu. Avant d’ouvrir le moindre canal chiffré, avant de vérifier le moindre certificat, avant d’afficher le moindre cadenas rassurant, votre machine doit transformer un nom en adresse. Elle pose donc une question, et cette question contient, en toutes lettres, le nom de ce que vous vous apprêtez à faire : la banque, l’avocat, le site de rencontres, le forum sur le surendettement dont vous n’avez encore parlé à personne.

Ce protocole s’appelle le DNS. Il a été conçu à une époque où Internet comptait peu de machines, dont les administrateurs se connaissaient par leur prénom et se prêtaient volontiers des câbles. On y réglait les problèmes de sécurité par la bonne éducation. Le DNS a gardé de cette origine un tempérament confiant, bavard et serviable, qui ferait un excellent concierge et un détestable garde du corps.

Il est aussi le protocole le moins regardé de toute la pile. On audite TLS, on discute des suites cryptographiques, on débat de la durée de vie des certificats avec une passion de théologiens. Le DNS, lui, marche. Il marche si bien qu’on l’oublie, et on l’oublie si bien qu’on ne remarque pas qu’il raconte à un tiers, en permanence et en clair, la liste de tout ce qu’on consulte.

La thèse de cet éditorial est la suivante : dans une résolution de nom, il y a toujours un témoin, et les techniques récentes n’ont jamais supprimé ce témoin ; elles ont choisi lequel. DNSSEC garantit que la réponse est authentique, pas qu’elle est discrète. DNS over TLS et DNS over HTTPS rendent la question illisible pour le réseau, au prix de la confier tout entière à un résolveur. Le choix du résolveur est donc une décision de sécurité, probablement la plus sous-estimée de toutes, et presque tout le monde la laisse prendre par un réglage par défaut dont il ignore l’existence.

Une résolution, vue de près

Rappelons le mécanisme, sans lequel on ne comprend rien à la suite ; le détail est dans la page consacrée aux services d’infrastructure DNS, DHCP et NTP.

Votre système d’exploitation contient un petit client, le résolveur de souche (stub resolver), qui ne sait presque rien faire. Il transmet la question à un résolveur récursif, dont l’adresse lui a été fournie, en général, par le réseau sur lequel vous êtes connecté : la box à la maison, le Wi-Fi de la gare, le réseau de l’entreprise. C’est ce résolveur récursif qui fait le vrai travail.

S’il n’a pas la réponse en cache, il interroge un serveur racine, qui ne connaît pas la réponse mais sait qui gère la zone de premier niveau (.fr, .org, .com). Il interroge alors le serveur de cette zone, qui ne connaît pas davantage la réponse mais sait qui fait autorité pour le domaine demandé. Il interroge enfin le serveur faisant autorité pour ce domaine, qui, lui, sait. La réponse redescend, le résolveur la met en cache pour une durée fixée par le propriétaire du domaine (le TTL), et la transmet à votre machine.

C’est une chaîne de délégations d’une grande élégance, et d’une grande naïveté. Chaque maillon croit ce que lui dit le maillon suivant, parce qu’il n’a, historiquement, aucun moyen de faire autrement. La résolution est un jeu du téléphone où chacun répète fidèlement ce qu’on lui a soufflé, sans jamais pouvoir vérifier que c’était bien la bonne personne qui soufflait.

Deux propriétés de conception méritent d’être gardées en tête pour la suite. D’abord, les requêtes circulent historiquement en clair, sur UDP pour l’essentiel, sans aucune protection de confidentialité ni d’intégrité. Ensuite, la seule chose qui permettait à un résolveur de reconnaître la bonne réponse parmi les paquets reçus était un identifiant de requête de seize bits, complété plus tard par un port source aléatoire. Seize bits, c’est un peu plus de soixante-cinq mille possibilités : de quoi décourager un distrait, pas un obstiné.

Qui voit quoi

Posons la même question que pour les messageries : pas « qu’est-ce qui fuit ? » mais « vers qui ? ». Dans une résolution classique, sans aucune des protections dont nous parlerons, la distribution des regards est la suivante.

Le réseau local et le fournisseur d’accès voient tout : la question, la réponse, l’heure, et l’adresse de la machine qui demande. Le Wi-Fi du café sait que vous avez cherché le site de votre banque. Le fournisseur d’accès sait, à la requête près, quels noms votre foyer a résolus, à quelle heure, et avec quelle constance. C’est un journal de navigation complet, qui n’a même pas besoin d’être déduit : il suffit de lire.

Le résolveur récursif voit tout aussi, par définition, puisqu’il reçoit la question. Dans la configuration par défaut, ce résolveur est celui du fournisseur d’accès : les deux premiers témoins n’en font donc qu’un, ce qui simplifie la vie de tout le monde, à commencer par celle du témoin.

Les serveurs racine et de premier niveau voient beaucoup moins qu’on le craint parfois. Ils voient la question du résolveur, pas celle de l’utilisateur final : l’adresse source est celle du résolveur, qui agrège des milliers de clients. Et grâce au cache, la racine n’est consultée que rarement. Historiquement, pourtant, le résolveur envoyait le nom complet à chaque étage, y compris à ceux qui n’en avaient pas besoin ; la minimisation des noms de requête (QNAME minimisation) corrige cela en ne révélant à chaque serveur que la partie du nom qui le concerne. C’est un progrès discret et réel, du genre qui ne fait l’objet d’aucune conférence de presse.

Le serveur faisant autorité voit la question, et l’adresse du résolveur. Il ne voit pas la vôtre, sauf si le résolveur a la gentillesse de la lui transmettre. Et il arrive qu’il l’ait : l’extension dite EDNS Client Subnet permet au résolveur d’indiquer au serveur faisant autorité un préfixe de l’adresse du client, afin que celui-ci renvoie l’adresse du serveur le plus proche géographiquement. C’est très utile aux réseaux de diffusion de contenu. C’est aussi une fuite délibérée d’une information de localisation vers un tiers que vous n’avez jamais consulté, au nom de votre confort. Le confort a bon dos ; il a surtout de grandes oreilles.

Enfin, la réponse elle-même trahit, même quand la question est cachée : l’adresse IP obtenue sera, dans l’instant qui suit, la destination d’une connexion visible par tout le réseau. Un observateur qui ne voit pas le DNS voit encore à qui l’on parle ensuite. Retenez ce point ; il reviendra comme un créancier.

L’empoisonnement, ou la crédulité industrielle

Avant de parler de confidentialité, parlons d’authenticité, parce que c’est là que le DNS a d’abord failli, et de manière spectaculaire.

Puisqu’un résolveur accepte la première réponse plausible qui correspond à sa question, un attaquant qui parvient à lui en glisser une fausse avant la vraie peut empoisonner son cache : pendant toute la durée de vie de l’entrée, tous les clients de ce résolveur recevront la mauvaise adresse. On ne pirate pas la victime ; on pirate l’annuaire qu’elle consulte, ce qui est plus économique et touche tout le quartier à la fois.

En 2008, le chercheur Dan Kaminsky a montré que cette attaque, que l’on croyait bornée par la durée des caches, pouvait être répétée à volonté en interrogeant des sous-domaines inexistants, chacun offrant une nouvelle occasion de deviner l’identifiant. La correction d’urgence, coordonnée entre éditeurs de logiciels, a consisté pour l’essentiel à rendre aléatoire le port source des requêtes, ce qui multiplie l’espace à deviner. Cela a suffi à rendre l’attaque impraticable dans la plupart des cas. Cela n’a pas rendu le DNS digne de confiance : cela l’a rendu plus difficile à tromper au hasard. La nuance est de celles que les attaquants apprécient.

Il reste en outre une manière de tromper un résolveur sans rien deviner : être sur le chemin. Un attaquant placé entre le résolveur et le serveur faisant autorité, ou entre vous et votre résolveur, n’a pas besoin de deviner quoi que ce soit ; il répond. Et il y a plus radical encore, qui fera l’objet de l’éditorial suivant : détourner, au niveau du routage d’Internet, les adresses mêmes des serveurs faisant autorité.

DNSSEC : l’authenticité sans la discrétion

La réponse de fond au problème d’authenticité s’appelle DNSSEC. Son principe est d’une rigueur admirable : chaque zone signe ses enregistrements, et la clé qui signe une zone est elle-même attestée par la zone parente, jusqu’à la racine, dont la clé publique sert d’ancre de confiance. Un résolveur qui valide peut ainsi vérifier, étage par étage, que la réponse reçue est bien celle que le propriétaire du domaine a publiée, et qu’elle n’a été ni forgée ni altérée. La racine est signée depuis 2010 ; la clé qui l’ancre a été renouvelée en 2018, au terme d’une opération préparée pendant des années avec une prudence de démineur.

Il faut dire tout de suite ce que DNSSEC n’est pas, parce que la confusion est répandue et quelquefois entretenue. DNSSEC ne chiffre rien. Les questions et les réponses circulent toujours en clair ; elles sont simplement accompagnées de signatures. DNSSEC garantit que la réponse est authentique. Il ne garantit en rien qu’elle est discrète. Un observateur du réseau voit exactement la même chose qu’avant, avec des signatures en plus, ce qui lui fait simplement davantage d’octets à ignorer.

Il faut aussi dire où s’arrête la validation. Dans la configuration la plus courante, c’est le résolveur récursif qui valide, puis qui transmet à votre machine une réponse accompagnée d’un drapeau indiquant « j’ai vérifié ». Entre le résolveur et vous, ce drapeau circule en clair et sans protection. Sur ce dernier kilomètre, DNSSEC ne protège que si votre machine valide elle-même, ou si le lien vers le résolveur est protégé par ailleurs. Autrement dit, DNSSEC vous garantit que le résolveur n’a pas été trompé, à condition que vous fassiez confiance au résolveur pour vous le dire. On a déjà vu des garanties plus autonomes.

Enfin, DNSSEC a des effets de bord. Pour prouver qu’un nom n’existe pas, il fallait publier des enregistrements signés qui énumèrent, de proche en proche, les noms existants de la zone, ce qui permettait de la parcourir entièrement (zone walking). La variante qui remplace les noms par leurs condensats rend ce parcours plus coûteux sans le rendre impossible, pour la même raison qui rend illusoire le hachage des numéros de téléphone : un ensemble de noms plausibles se parcourt. Les signatures grossissent aussi les réponses, ce qui en fait de meilleurs projectiles pour les attaques par amplification. Et DNSSEC ajoute une manière nouvelle et très efficace de tomber en panne : une signature expirée, une clé mal renouvelée, et tout un domaine devient injoignable pour tous les résolveurs qui valident. Le protocole est ainsi fait qu’il punit plus sévèrement l’administrateur étourdi que l’attaquant médiocre.

C’est sans doute pourquoi son déploiement est si inégal : largement validé du côté des grands résolveurs, beaucoup moins signé du côté des domaines. Les proportions varient selon les extensions et les sources ; je ne les citerai pas, n’ayant pas de chiffre dont je sois sûr à la date où j’écris.

# Obtenir une réponse accompagnée de ses signatures (enregistrements RRSIG).
# Le drapeau « ad » dans l'en-tête signifie que le résolveur dit avoir validé.
dig +dnssec example.org A

# Valider localement la chaîne de confiance, sans croire le résolveur sur parole
# (delv est fourni avec les outils BIND et embarque l'ancre de la racine).
delv example.org A

Ces deux commandes sont en lecture seule : elles interrogent, elles ne modifient rien. La différence entre les deux résume tout le paragraphe précédent : dig vous rapporte ce que le résolveur affirme, delv vérifie par lui-même.

Chiffrer la question : DoT, DoH, et le témoin qui change

DNSSEC a traité l’authenticité ; restait la discrétion. Deux protocoles s’en chargent, qui procèdent de la même idée : placer la conversation entre votre machine et le résolveur dans un tunnel TLS.

DNS over TLS (DoT) ouvre une connexion TLS dédiée, sur un port qui lui est propre, et y fait passer les requêtes DNS. Le détail est exposé dans la page consacrée à DNS over TLS. DNS over HTTPS (DoH) fait la même chose, mais en déguisant les requêtes DNS en requêtes web ordinaires, sur le port de HTTPS, de sorte qu’elles se confondent avec le reste du trafic. Il existe des variantes plus récentes, sur QUIC notamment, qui ne changent pas le raisonnement.

Dans les deux cas, le réseau local et le fournisseur d’accès ne voient plus la question. Ils voient une connexion chiffrée vers un résolveur. C’est un vrai gain, et il serait mesquin de le minimiser : le Wi-Fi du café cesse de tenir le journal de vos recherches.

Mais regardons ce qui s’est passé. Avant, la question était vue par le réseau et par le résolveur, qui étaient souvent la même entité : le fournisseur d’accès. Désormais, elle n’est plus vue que par le résolveur, qui est une entité choisie, souvent différente, et souvent plus grande. Le chiffrement du DNS n’a pas supprimé le témoin ; il en a désigné un seul, et lui a donné l’exclusivité. On a fermé les fenêtres qui donnaient sur la rue, et on a remis toutes les clés au même voisin. Si ce voisin est plus digne de confiance que la rue, c’est une amélioration. Sinon, c’est une concentration.

Et la concentration n’est pas une hypothèse d’école. Lorsqu’un navigateur active DoH par défaut vers un résolveur qu’il a choisi, des millions de requêtes qui étaient dispersées entre des centaines de fournisseurs d’accès convergent vers une poignée d’opérateurs. Chacun a peut-être d’excellentes politiques de confidentialité ; l’ensemble forme un point d’observation que le DNS n’avait jamais connu. On a décentralisé le risque vers le haut.

Il reste ensuite la fuite que j’annonçais plus haut. Même si la question DNS est parfaitement cachée, la connexion qui suit part vers une adresse IP visible, et, sauf déploiement de l’extension qui chiffre l’indication de nom de serveur dans TLS, le nom du site est de toute façon transmis en clair au moment d’ouvrir cette connexion. Chiffrer le DNS sans cela, c’est tirer les rideaux en laissant son nom sur la sonnette.

# Interroger un résolveur public en DNS over TLS (outil kdig, paquet knot-dnsutils).
# +tls-ca et +tls-hostname exigent un certificat valide pour le nom annoncé :
# sans eux, le chiffrement est opportuniste et n'authentifie pas le résolveur.
kdig @9.9.9.9 +tls-ca +tls-hostname=dns.quad9.net example.org A

La remarque du commentaire n’est pas un détail. Un chiffrement qui ne vérifie pas l’identité du résolveur protège contre un observateur passif, pas contre un intermédiaire actif qui se ferait passer pour lui. C’est la différence entre une conversation chuchotée et une conversation chuchotée à la bonne personne.

Le résolveur est une décision de sécurité

Nous y voilà. Si toutes les techniques convergent vers un résolveur qui voit tout, alors le choix de ce résolveur n’est pas un réglage technique : c’est le choix de la personne à qui l’on confie la liste exhaustive de ce qu’on fait en ligne. Personne ne confierait son agenda au premier venu. Presque tout le monde confie son historique de navigation à celui que le réseau lui a indiqué.

Plusieurs critères devraient guider ce choix, et aucun n’est affiché sur le carton.

La journalisation. Que conserve le résolveur, combien de temps, sous quelle forme ? Un résolveur qui garde les adresses des clients avec les noms demandés détient un fichier d’une précision redoutable. Un résolveur qui ne garde que des agrégats anonymes est un moindre mal. Comme pour les messageries, il s’agit d’une politique déclarée, pas d’une propriété vérifiable de l’extérieur.

La juridiction. Le droit applicable au résolveur détermine qui peut exiger ses journaux, et dans quelles conditions. Ce n’est pas un critère technique, c’est donc un critère que les techniciens oublient.

La transmission aux tiers. Le résolveur envoie-t-il un préfixe de votre adresse aux serveurs faisant autorité ? Pratique-t-il la minimisation des noms ? Valide-t-il DNSSEC ? Ces trois questions ont des réponses, publiées par la plupart des résolveurs sérieux ; il suffit de les lire, ce qui les distingue des conditions générales d’utilisation, qu’il suffit de ne pas lire.

Le filtrage. Un résolveur peut refuser de résoudre certains noms : domaines malveillants connus, publicités, contenus bloqués par décision de justice ou par choix de l’opérateur. C’est tantôt une protection, tantôt une censure, et souvent les deux selon le point de vue. Qui choisit le résolveur choisit aussi ce qui, pour lui, n’existe pas.

La disponibilité. Un résolveur injoignable, c’est un Internet éteint, puisque presque rien ne fonctionne sans résolution. Concentrer tous ses œufs dans le même résolveur, c’est aussi concentrer ses pannes.

Le cas de l’entreprise

Dans une organisation, le problème se présente à l’envers, et il fâche. Le résolveur interne n’y est pas un témoin indiscret : c’est un instrument de défense. Il résout les noms internes qui n’existent pas sur Internet, il bloque les domaines malveillants, il journalise les requêtes pour détecter une machine infectée qui interroge un serveur de commande. Le DNS est, pour une équipe de sécurité, l’un des journaux les plus riches et les moins chers qui soient.

Or DoH, précisément parce qu’il se fond dans le trafic web, permet à une application de contourner ce résolveur sans que personne ne s’en aperçoive. Un navigateur qui active DoH vers un résolveur public échappe au filtrage, perd l’accès aux noms internes, et soustrait ses requêtes à la surveillance défensive. Un logiciel malveillant qui fait de même obtient, gratuitement, un canal de commande que les outils de détection classiques ne voient plus. La technique qui protège le particulier du Wi-Fi du café protège aussi le maliciel de l’équipe de sécurité, avec la même impartialité.

Les éditeurs de navigateurs ont prévu des mécanismes pour que DoH se désactive dans les réseaux gérés, par exemple par des politiques d’entreprise, ou, pour certains navigateurs, par un nom de domaine « canari » que le résolveur local peut choisir de ne pas résoudre pour signaler qu’il ne veut pas être contourné. Ces mécanismes varient d’un logiciel à l’autre et d’une version à l’autre : c’est typiquement le genre de détail qu’il faut vérifier dans la documentation du jour et non dans un dossier de septembre.

Le meilleur argument contraire

Tout ce qui précède pourrait laisser croire que le chiffrement du DNS est une fausse bonne idée. Ce serait une erreur, et la position opposée mérite d’être exposée dans sa meilleure version.

Premier argument : le témoin par défaut était le pire possible. Le fournisseur d’accès connaît déjà votre identité civile, votre adresse postale et votre moyen de paiement. Lui laisser en plus la liste des noms résolus, c’est confier le journal au seul acteur capable de le rattacher sans effort à une personne. Un résolveur tiers, s’il ne journalise pas les adresses des clients, sait beaucoup moins qui vous êtes. Déplacer le témoin vers quelqu’un qui en sait moins sur vous est un gain net, même si ce quelqu’un est plus gros.

Deuxième argument : le chiffrement protège aussi l’intégrité. Sans chiffrement, n’importe quel intermédiaire peut modifier les réponses DNS, et certains le faisaient, pour rediriger les noms inexistants vers des pages publicitaires, ou pour mettre en œuvre des blocages. DoT et DoH rendent ces manipulations impossibles sur le chemin, ce qui est, pour la neutralité du réseau, une bonne nouvelle que DNSSEC seul n’apportait pas au dernier kilomètre.

Troisième argument : l’argument de l’entreprise est un argument de confort. Une organisation qui dépend de l’inspection du DNS en clair pour détecter ses menaces dépend d’une faiblesse du protocole. Les défenses sérieuses se déplacent vers le poste (où la requête existe forcément en clair avant d’être chiffrée) et vers des politiques de configuration. Regretter la surveillance passive, c’est regretter l’époque où l’on pouvait lire le courrier des employés parce que les enveloppes n’étaient pas collées.

Je trouve les deux premiers arguments décisifs, et le troisième juste pour l’essentiel. Mais aucun ne réfute la thèse : ils montrent que déplacer le témoin peut être une excellente idée, à condition de savoir vers qui on le déplace. C’est exactement ce qui manque dans le déploiement par défaut : un choix a été fait, souvent un bon, mais il a été fait par l’éditeur du logiciel, et l’utilisateur n’en sait rien. Une bonne décision prise à votre place reste une décision prise à votre place.

Ce que je ne sais pas

Je ne sais pas ce que font réellement les résolveurs de leurs journaux. Les politiques publiées sont souvent précises, parfois auditées par des tiers, jamais vérifiables par l’utilisateur. Je peux dire ce qu’un résolveur pourrait apprendre ; je ne peux pas dire ce qu’il garde. Cette incertitude n’est pas propre à un opérateur : elle est structurelle.

Je ne connais pas l’état exact du déploiement. Proportion de domaines signés, proportion de requêtes validées, part du trafic DNS chiffré, adoption de l’extension qui chiffre le nom dans TLS : ces chiffres existent, sont publiés par des organismes de mesure, varient vite, et je n’en ai aucun dont je sois assez sûr pour l’écrire ici.

Je ne sais pas si le résolveur « aveugle » deviendra courant. Il existe des propositions pour séparer ce que voit le résolveur de ce que voit le relais, de sorte qu’aucun des deux ne connaisse à la fois le client et la question (l’une d’elles est connue sous le nom d’Oblivious DoH). C’est, sur le papier, la seule approche qui supprime vraiment le témoin unique, au prix d’un intermédiaire supplémentaire et de l’hypothèse que les deux ne s’entendent pas. Son adoption réelle m’est inconnue.

Je ne sais pas combien de temps le DNS restera la porte d’entrée. Les usages évoluent vers des connexions de longue durée, des réseaux de diffusion de contenu qui servent mille domaines sur les mêmes adresses, des applications qui embarquent leurs propres mécanismes de résolution. Le DNS ne disparaîtra pas ; il est possible qu’il devienne un témoin parmi d’autres, ce qui, pour un témoin, est une forme de retraite.

Ce qui reste

Le DNS est la question qu’on pose avant chaque question, et c’est pour cela qu’il en dit tant. Il a été conçu pour un monde de gens bien élevés ; il est resté bien élevé dans un monde qui ne l’est plus, et ce décalage produit à peu près tous ses problèmes.

Trois choses me semblent acquises. Que l’authenticité et la confidentialité sont deux problèmes distincts, que DNSSEC règle le premier sans toucher au second, et que DoT et DoH règlent le second (vis-à-vis du réseau) sans régler le premier au-delà du résolveur. Que chiffrer le DNS ne supprime pas le témoin, il le choisit, et que ce choix concentre entre peu de mains ce qui était dispersé entre beaucoup. Et que le résolveur est une décision de sécurité : la plus lourde de conséquences parmi celles que l’on prend sans savoir qu’on les prend.

Il y a quelque chose de vexant, pour un métier qui passe ses journées à débattre de longueurs de clés, à constater que la fuite la plus massive de la vie numérique ordinaire tient dans un paramètre réseau que personne n’ouvre. C’est aussi, pour un vieux lecteur de journaux, assez rassurant : l’humanité n’a pas changé, elle confie toujours ses secrets au concierge.

Reste que toute cette discussion suppose un point que nous n’avons jamais questionné : que les paquets envoyés vers l’adresse du résolveur, ou vers celle d’un serveur faisant autorité, arrivent bien à la machine qui porte cette adresse. Sur Internet, cela n’a rien d’évident. L’acheminement repose sur un protocole qui croit ce qu’on lui annonce, comme le DNS avant DNSSEC, mais à une tout autre échelle. C’est le sujet de l’éditorial suivant, et l’on verra qu’il y a pire que de parler au mauvais concierge : c’est de sonner à la bonne porte et d’être accueilli par quelqu’un d’autre. L’éditorial précédent, sur ce que le chiffrement de bout en bout laisse voir, s’arrêtait là où celui-ci commence.

🐝 Ce qui arrive si on s’en passe

Laisser le choix du résolveur à un réglage par défaut revient à confier sans le savoir la liste complète des noms consultés, horodatée et rattachée à une adresse, à un acteur dont la politique de conservation n’a jamais été lue. En entreprise, l’oubli coûte autrement : une application ou un logiciel malveillant qui résout ses noms par un canal chiffré vers l’extérieur échappe au filtrage et disparaît du journal DNS, l’un des rares qui permettent de repérer une machine interrogeant son serveur de commande. Côté authenticité, un résolveur qui ne valide pas les signatures accepte une réponse empoisonnée, et la redirection dure aussi longtemps que l’entrée reste en cache.

🦫 Explication de la marmotte 🍫

Les ordinateurs se retrouvent sur Internet grâce à des adresses numériques, mais les personnes utilisent des noms de sites. Avant chaque connexion, l’ordinateur doit donc demander l’adresse qui correspond au nom : c’est le rôle du système de noms de domaine, appelé DNS. Un petit programme de la machine transmet la question à un serveur appelé résolveur, en général fourni par le réseau utilisé. Si le résolveur ne connaît pas la réponse, il interroge successivement un serveur racine, celui de l’extension, par exemple « .fr », puis le serveur responsable du nom, et il garde la réponse en mémoire pendant une durée fixée. Ces questions circulent historiquement en clair : le réseau local, le fournisseur d’accès et le résolveur voient la liste des sites consultés. De plus, un attaquant peut glisser une fausse réponse que le résolveur croit et garde en mémoire, ce qui envoie tous ses utilisateurs vers une mauvaise adresse. Deux protections existent. La première ajoute aux réponses des signatures vérifiées étage par étage jusqu’à la racine : elle prouve que la réponse est authentique, mais ne cache rien. La seconde chiffre la conversation entre la machine et le résolveur : le réseau ne voit plus les questions, mais le résolveur les voit toutes. Le choix du résolveur décide donc qui connaît la liste des sites consultés. En entreprise, le résolveur interne sert aussi à bloquer et repérer les machines infectées, et le chiffrement vers un résolveur extérieur permet de le contourner.

Pages voisines

La citent

Le DNS, le protocole qu'on ne regarde jamais

Elle cite

: les deux pages se citent l’une l’autre.

Le DNS, le protocole qu'on ne regarde jamais

La question avant la question

Une résolution, vue de près

Qui voit quoi

L’empoisonnement, ou la crédulité industrielle

DNSSEC : l’authenticité sans la discrétion

Chiffrer la question : DoT, DoH, et le témoin qui change

Le résolveur est une décision de sécurité

Le cas de l’entreprise

Le meilleur argument contraire

Ce que je ne sais pas

Ce qui reste

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines