DNS over HTTPS passe tout droit devant vos contrôles

Il existe un moyen, pour n’importe quoi sur votre réseau, de résoudre un nom sans que votre serveur DNS entende jamais la question. Aucun réglage modifié sur la machine, aucun droit d’administrateur, rien que vous trouveriez dans un journal. La requête part comme une requête HTTPS ordinaire sur le port 443, va vers un résolveur quelque part sur internet, et revient avec une réponse que votre propre résolveur aurait refusé de donner.

La liste de blocage ne se déclenche jamais. Le flux de menaces ne reçoit jamais la requête. La ligne de journal que vous seriez allé chercher n’a jamais été écrite.

Cela s’appelle DNS over HTTPS, DoH en abrégé, et cela a été conçu pour une bonne raison. Le DNS en clair circule en texte lisible sur le port 53 : le café, l’aéroport et votre fournisseur d’accès peuvent lire chaque nom que vous résolvez et changer les réponses si l’envie leur en prend. DoH enveloppe la requête dans le même chiffrement que le reste du web et la cache dans la foule. Comme mesure de confidentialité pour une personne sur un réseau hostile, il fait exactement ce qu’il annonce.

Le problème, c’est que ce qu’il neutralise et ce sur quoi vous comptez sont une seule et même chose.

Votre résolveur n’est pas qu’un service de résolution. C’est un point de contrôle : là où un domaine reconnu malveillant reçoit une réponse vide, là où une requête vers un serveur de commande apparaît dans un journal, là où le DNS de protection refuse le domaine de maliciel avant que la connexion ne soit établie. DoH retire la requête à votre résolveur et la confie à un résolveur que vous n’avez jamais choisi, et tous les contrôles que vous aviez accrochés à ce résolveur partent avec elle.

Ceci n’est pas un plaidoyer contre le chiffrement du DNS. Le DNS chiffré est une bonne chose, et la dernière section de cet article explique comment le faire tourner. C’est un plaidoyer sur qui choisit le résolveur, car ce choix est tout l’enjeu, et DoH a été conçu pour vous le retirer et le donner au navigateur, à l’application et, si vous n’y prenez pas garde, à l’attaquant.

Ce qu’est vraiment DoH

Ôtez l’emballage marketing et DoH est une requête web ordinaire qui se trouve porter une question DNS.

Le DNS ordinaire est un petit message binaire envoyé en UDP ou TCP vers le port 53. DoH place ce même message, ou une version JSON de celui-ci, dans une requête HTTPS vers un serveur web qui parle le protocole ; la réponse est une réponse HTTPS¹. C’est toute l’idée.

RFC 8484 l’a normalisé en octobre 2018, et l’intention n’a jamais été cachée. Le but, dit sa propre introduction, est « allowing web applications to access DNS information via existing browser APIs »¹.

Des API de navigateur existantes. Une page web. Personne n’a découvert cela comme un effet secondaire gênant des années plus tard. C’est écrit dans le premier paragraphe du standard, posé comme l’objectif.

Voici une résolution faite à la manière DoH, depuis une ligne de commande, contre un résolveur public, demandant example.com :

$ curl -s -H 'accept: application/dns-json' \
    'https://cloudflare-dns.com/dns-query?name=example.com&type=A'
{"Status":0,"TC":false,"RD":true,"RA":true,"AD":true,"CD":false,
 "Question":[{"name":"example.com","type":1}],
 "Answer":[{"name":"example.com","type":1,"TTL":146,
            "data":"23.192.228.80"}]}

Aucun client spécial. Aucun port sauf 443. Une seule requête HTTPS, de la même forme que le chargement d’une page web, et un nom résolu par une machine à l’autre bout du monde qui n’a jamais entendu parler de votre réseau ni de vos règles. Google fait tourner le même point d’accès, Quad9 aussi, et des dizaines d’autres.

Regardez maintenant ce que voit votre pare-feu. Une connexion TLS vers un serveur web sur 443, qu’il ne peut pas lire à l’intérieur parce que c’est justement l’objet de TLS, et qu’il ne peut pas distinguer des centaines d’autres qui s’ouvrent à chaque seconde vers des réseaux de diffusion de contenu, de l’analytique et des publicités. La question DNS a disparu. Elle a quitté les lieux déguisée en trafic web et personne à la porte n’a pu voir son visage.

Il y a trois façons pour un client de déplacer une résolution DNS, et il vaut la peine de les mettre côte à côte, car la différence est tout le sujet de cet article.

Le DNS ordinaire est lisible et blocable, et c’est précisément pour cela qu’il était facile à contrôler et facile à espionner. DoT chiffre la requête mais garde son propre port : vous pouvez donc encore le refuser à la frontière. DoH est celui sans aucune prise : chiffré comme DoT, mais partageant le seul port que vous ne pourrez jamais fermer, de sorte que le seul levier qui reste est quel résolveur le client a choisi, et c’est ce levier qui fait l’objet de cet article.

Qui choisit le résolveur

Ce qui rend cela important, c’est qu’une machine moderne porte cinq choses différentes qui peuvent chacune décider où va le DNS, et vous n’en contrôlez qu’une seule par défaut.

Le système d’exploitation demande le résolveur que votre réseau a distribué par DHCP ou par annonces de routeur. Celui-là est le vôtre, et c’est le modèle que tout ce qui est plus ancien qu’environ 2019 supposait : un résolveur, distribué par le réseau, ce qui explique pourquoi les contrôles DNS au niveau réseau ont fonctionné pendant trente ans.

Le navigateur a rompu cela. Firefox et Chrome embarquent tous deux la mécanique pour faire leur propre DoH, vers un résolveur choisi par leur éditeur, par-dessus votre tête, ne se retirant que lorsqu’ils repèrent un réseau administré. Et une application peut porter son propre client DoH et un résolveur codé en dur dans son code, décidé à la compilation ; elle ne lit pas votre DHCP et ne demande rien. Beaucoup de logiciels légitimes le font déjà.

Un script sur une page web est celui qui devrait vous arrêter, car il n’a besoin de rien d’installé du tout. Cette commande curl ci-dessus est une seule requête HTTPS, et un navigateur passe sa vie à faire des requêtes HTTPS. Quelques lignes de JavaScript sur n’importe quelle page qu’un utilisateur ouvre peuvent envoyer des résolutions vers un point d’accès DoH public, parce que les grands fournisseurs autorisent délibérément les requêtes cross-origin pour que les applications web puissent les utiliser, le but affiché dans RFC 8484. La page que vous lisez pourrait résoudre des noms via un résolveur dans un autre pays à l’instant même, et vous ne verriez qu’une connexion HTTPS de plus.

Et le maliciel choisit son propre résolveur pour la raison évidente : il ne veut pas que vous voyiez qui il appelle. Il porte le résolveur dans son code, l’atteignant souvent par adresse pour qu’il n’y ait aucune résolution d’amorçage à capter, et n’a besoin de votre autorisation pour rien de tout cela.

Relisez cette colonne. Les trois du bas n’exigent aucun droit d’administrateur, aucun réglage modifié, et rien qui apparaisse dans le système d’exploitation. Le contrôle que vous avez mis des années à bâtir, un résolveur, une liste de blocage, un journal, supposait que la ligne du haut était la seule ligne. Elle ne l’est plus depuis des années.

Le tour même que les éditeurs de navigateurs redoutaient

Le cas de la page web n’est ni théorique ni récent. C’est ainsi que les assistants de protocole sont détournés : une page web émet des octets, quelque chose en aval agit dessus, et ne peut pas dire qu’ils venaient de la page d’un attaquant plutôt que d’un vrai client, parce que sur le fil ils sont identiques. Avec DoH, la pièce en aval est un résolveur public, qui répond sans aucun moyen de savoir que le JavaScript qui demande venait d’une page d’hameçonnage, et votre résolveur, celui avec la liste de blocage et le journal, n’a jamais été sur le chemin pour avoir un avis. Pas un trou percé à travers vos contrôles, mais une route bâtie autour d’eux, pavée du même chiffrement que vous recommandez à tout le monde d’utiliser.

C’est déjà le canal de l’auteur de maliciels

Vous n’avez pas à imaginer comment cela sert. C’est documenté depuis des années, par des chercheurs nommés, sur de vrais échantillons, et la trajectoire ne va que dans un sens : du robot criminel en 2019 à l’outil de renseignement d’État l’année suivante, et plus chargée chaque année depuis, avec de nouvelles portes dérobées qui débarquent encore en 2026.

Godlua, le premier cas largement signalé, était une porte dérobée pour Linux et Windows dont l’analyse note qu’il « uses DNS over HTTPS to get the C2 name to ensure secure communication between the bots, the Web Server and the C2 »². Sur un réseau qui surveille le port 53, résoudre votre serveur de commande est un cadeau pour le défenseur. Par DoH, il n’y a rien à observer.

La phrase de Proofpoint sur PsiXBot est celle qui mérite d’être citée, un éditeur de renseignement sur les menaces qui dit tout haut ce qui se murmure. Utiliser DoH pour la commande et le contrôle, écrivaient-ils, « should be a warning shot for the cybersecurity community as there are no simple solutions to help identify an infected host or the process of receiving instructions »³. Aucune solution simple, de la part de ceux dont le métier est de les trouver.

Puis OilRig a monté d’un cran. La description de Kaspersky est exactement le changement dont parle cet article : « instead of plain text requests to port 53, they would use port 443 in encrypted packets », avec un outil qui « allows DoH queries to Google and Cloudflare services »⁴. Une opération de renseignement national, se servant des fournisseurs DoH publics comme tuyau pour faire sortir des données volées au-delà de tout ce qui surveillait le DNS.

Et cela ne s’est pas arrêté là. Cela s’est répandu. Dès 2023, ChamelGang disposait d’une porte dérobée Linux en C++, ChamelDoH, faisant tourner tout son canal de commande par DoH, envoyant des requêtes DNS TXT à ses propres serveurs de noms via Google et Cloudflare ; le chercheur qui l’a trouvée a noté que la détection comme la prévention « become difficult », parce que le transport chiffré ne peut être intercepté et qu’une requête malveillante ne peut être distinguée d’une vraie⁵. En décembre 2025, la CISA a décortiqué BRICKSTORM, une porte dérobée liée à la Chine qui empile HTTPS, WebSockets et TLS imbriqué et « also uses DNS-over-HTTPS (DoH) » pour enfouir son C2 dans le trafic web ordinaire⁶. Dès février 2026, ce n’était plus qu’un savoir-faire de métier : Cisco Talos a repéré Dohdoor, qui « securely sends encrypted DNS requests to Cloudflare’s DNS server over HTTPS port 443 » pour trouver son serveur de commande, s’introduisant par hameçonnage dans des écoles et des hôpitaux américains⁷.

Voilà la forme de la chose. Pas une technique qui a eu son heure puis s’est effacée, mais une que davantage de mains reprennent chaque année. Le problème empire, il ne s’améliore pas, et une nouvelle famille pointe désormais à date fixe.

Une seule propriété a fait le travail dans chacun d’eux : la requête est partie en HTTPS sur 443 et le résolveur du défenseur ne l’a jamais vue. Pas une faiblesse que quelqu’un pourrait trouver un jour. Une fonctionnalité que des attaquants ont livrée encore et encore, dont plusieurs États.

Et soyons clairs sur la raison pour laquelle ce tableau se remplit, année après année. Chaque famille qui y figure franchit une porte que les auteurs de DoH avaient été prévenus de laisser ouverte, dans le texte même du standard, et qu’ils ont laissée ouverte quand même⁸. Ce n’était pas une négligence. C’était une myopie, choisie exprès, par des gens parmi lesquels figurait le propre technologue d’ICANN. Alors je vais le dire comme c’est : sur ce point, ICANN sont des facilitateurs de cybercriminalité. Prévenus dans le texte même du standard de ce qui allait casser, leurs gens y ont apposé leur nom malgré tout, et le tableau ci-dessus est ce qui s’est engouffré par la brèche. Le crime n’est pas une surprise. C’est la facture d’une décision, et de qui a pris cette décision, c’est le sujet du reste de cet article.

Et malgré tout cela, DoH n’achète même pas ce que les gens supposent : la protection contre une réponse falsifiée. Chiffrer le saut vers un résolveur n’est pas authentifier ce que le résolveur renvoie, et un serveur DoH peut tout de même retourner un enregistrement falsifié. Le standard l’admet, disant que la règle contre les serveurs non configurés « does not guarantee protection against invalid data »⁹.

Le seul mécanisme qui authentifie une réponse DNS est DNSSEC, et DoH n’est pas cela. Pire, pour presque tous les clients DNSSEC est validé au résolveur récursif, pas sur l’appareil : le client se contente de croire le résolveur sur parole que la réponse a bien été vérifiée. DNSSEC ne vous a donc jamais protégé qu’à hauteur de la confiance que vous accordiez au résolveur qui faisait la vérification, et le vrai coup de DoH est de confier cette confiance à un opérateur distant que vous ne pouvez ni voir ni auditer.

Ainsi DoH peut vous rendre plus susceptible d’atterrir sur un site falsifié, pas moins : les défenses locales qui auraient attrapé une réponse détournée, le flux de DNS de protection, le propre filtrage de l’opérateur, sont précisément les choses que vous avez contournées, et tout ce qui reste, c’est la parole d’un opérateur distant, prise sur confiance.

Et rien de tout cela n’est une idée neuve sur laquelle DoH aurait trébuché par accident. Filtrer les domaines malveillants au résolveur est exactement ce que fait OpenDNS depuis près de vingt ans, bloquant l’hameçonnage et les maliciels pour des millions d’utilisateurs avant même que la réponse ne leur parvienne, et c’est le modèle que Cisco a payé pour posséder en 2015¹⁰. Deux décennies de sécurité au niveau du résolveur qui protégeaient des gens qui n’avaient jamais rien configuré, et DoH a sapé tout le modèle d’un seul coup : pointez l’application vers son propre résolveur, et OpenDNS, ou tout ce que votre réseau a choisi, n’est plus sur le chemin.

Pourquoi l’ancienne réponse a cessé de marcher

Tant que le DNS a vécu sur le port 53, la réponse réseau était simple. Forcez chaque client à utiliser votre résolveur, et bloquez le port 53 en sortie partout ailleurs à la frontière. Une machine qui cherchait à joindre un serveur DNS externe se faisait refuser : elle devait donc passer par le vôtre, et vos contrôles s’appliquaient à tout. Grossier, et ça marchait.

DoH tue cela d’un seul geste en utilisant 443. Vous ne pouvez pas bloquer le 443 en sortie. C’est le web. Le port que vous fermeriez pour forcer le DNS à passer par votre résolveur est donc celui que vous ne pouvez jamais fermer, et le chiffrement qui empêche votre FAI d’espionner vous empêche aussi de distinguer une résolution DoH d’un chargement de page.

Les deux moyens que vous emploieriez pour reprendre le contrôle, fermer le port et lire le trafic, ont tous deux disparu par conception. Vaincre exactement ces deux-là, aux mains d’un réseau hostile, est ce pour quoi DoH a été bâti.

Et lire le trafic n’est pas l’échappatoire que cela paraît, car il n’y a qu’une seule façon de le faire : casser et inspecter tout le trafic. Pour voir le DNS à l’intérieur d’une connexion 443, il vous faut faire l’homme du milieu sur chaque connexion HTTPS du réseau, poser votre propre certificat racine sur chaque appareil, et déchiffrer puis rechiffrer le tout. C’est ce à quoi un nombre croissant d’administrateurs en sont réduits, pour regagner la visibilité qu’une seule règle de pare-feu leur donnait gratuitement.

Et c’est un bien plus mauvais marché : vous avez affaibli TLS pour tout, mis une boîte de déchiffrement sur le chemin de chaque connexion et de chaque session bancaire, et bâti une cible unique qui compromet le tout, une posture contre laquelle US-CERT a mis en garde sans détour¹¹. Le contrôle proportionné a été cassé, alors le contrôle disproportionné est ce qui reste.

Voilà le piège. Le mécanisme qui protège un journaliste sur le WiFi d’un aéroport contre un réseau hostile est celui qui protège un maliciel sur votre réseau contre vous, et le protocole ne peut pas distinguer les deux. Un résolveur qu’on contourne ne sait pas s’il est un censeur ou une équipe de sécurité. Il sait seulement qu’il a été mis à l’écart.

La bonne réponse a toujours été DNS over TLS

Voici ce qui vend la mèche. Chiffrer le DNS n’a jamais eu besoin de tout ceci. C’était fait deux ans avant DoH, d’une manière qui laissait la personne qui gère le réseau capable de faire son travail.

DNS over TLS, RFC 7858, date de mai 2016. Son résumé dit à quoi il sert dès la première ligne : « provide privacy for DNS », un chiffrement qui « eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network »¹². C’est tout le dossier de la confidentialité, réglé : le café et le FAI mis dehors exactement comme avec DoH, parce que la requête est chiffrée de bout en bout.

Et il a été coécrit par Paul Hoffman, qui a ensuite coécrit le standard DoH aussi¹. Pas deux camps rivaux, donc. Les mêmes gens, qui avaient déjà résolu la confidentialité, la résolvant à nouveau d’une autre manière.

Qui est Hoffman a son importance, car cela dit d’où c’est venu. Il n’est pas un simple spectateur du DNS : son nom figure sur plus de quatre-vingts RFC, dont le standard de terminologie du DNS, et il fait ce travail comme technologue à l’ICANN¹³. Le standard qui a caché le DNS sur 443 a donc été coécrit de l’intérieur de l’ICANN, l’organisme américain qui décide de ce qui va dans la racine.

Et l’ICANN n’est pas le gardien désintéressé que le mot laisse entendre. J’ai exposé son bilan séparément : bâtie en Californie, responsable devant la Californie, et prête à se servir de sa position sur l’espace de noms pour ses propres fins. Ce n’était pas une campagne de confidentialité venue de la marge. C’était l’établissement qui tient la racine, réglant une seconde fois un dossier de confidentialité qu’il avait déjà réglé en 2016, d’une manière qui écartait l’opérateur réseau.

Demandez donc ce que la seconde manière a ajouté, car la confidentialité n’en faisait pas partie.

La seule case qui a changé est la dernière. DoT tourne sur son propre port, 853 : l’opérateur peut donc voir que c’est du DNS et décider de son sort, l’autoriser vers le résolveur sanctionné, le refuser ailleurs. DoH place la même requête chiffrée sur 443 et la mêle au web, où l’opérateur ne peut pas la distinguer.

Même confidentialité, même chiffrement. La seule différence entre les deux standards est de savoir si la personne qui gère le réseau peut encore voir son propre DNS. Ce n’est pas une fonctionnalité de confidentialité. La confidentialité a été livrée en 2016. C’est une fonctionnalité de contournement, et c’est la seule chose que DoH ajoute.

Et ils le savaient. C’est documenté, pas déduit. Les propres Considérations opérationnelles de RFC 8484 le disent clairement : « Filtering or inspection systems that rely on unsecured transport of DNS will not function in a DNS over HTTPS environment due to the confidentiality and integrity protection provided by TLS »⁸.

Ces systèmes sont les outils de sécurité qui protègent déjà les utilisateurs : le blocage des maliciels et des serveurs de commande, les flux de DNS de protection, les filtres de protection de l’enfance, l’inspection en entreprise. Le standard les nomme, dans son propre texte, comme les choses qui cessent de fonctionner. Casser un outillage qui défendait déjà des gens était un choix, fait en toute connaissance de cause et livré activé par défaut. Connaître l’effet et le choisir quand même est une décision dont on peut leur demander des comptes.

C’est pourquoi le cadrage sur la confidentialité ne survit pas à la chronologie. Une fois que DoT existe, la confidentialité ne peut pas être la raison de DoH, parce que la confidentialité était déjà réglée, par le même auteur, deux ans plus tôt. La confidentialité était donc l’écran de fumée.

Ôtez-le et regardez ce que le second standard a réellement mis en marche : une course aux armements. Il a pris un contrôle qui tenait en une ligne de pare-feu et l’a transformé en poursuite permanente, résolveurs contre listes de blocage contre nouveaux résolveurs, l’opérateur perdant par défaut, et une poignée d’entreprises américaines tenant le texte en clair au bout du compte.

Appelez cela un effet secondaire d’une fonctionnalité de confidentialité si vous voulez. À la lumière des faits, DoT déjà livré et le standard lui-même admettant qu’il casserait le filtrage, c’est bien le but, et la confidentialité était le mot peint sur la boîte. Et il a été poussé fort sous ce mot, par les parties qui y gagnaient.

Ceux qui le vendaient comme de la confidentialité étaient les éditeurs de navigateurs, et les bénéficiaires n’étaient pas que les utilisateurs.

Puis-je demander pourquoi, si le but était la confidentialité, la réponse n’a pas été le standard de DNS chiffré qui existait déjà et gardait l’opérateur dans la boucle, mais un second bâti pour que l’opérateur ne puisse pas voir ? Je ne demande pas qui a signé. Je demande quelle part de la « confidentialité » exigeait d’écarter la seule personne responsable du réseau.

Parce que c’est là la vraie cible, et c’est l’administrateur réseau : le professionnel responsable de la sécurité et de la sûreté du réseau, traité en adversaire par défaut. DoH ne supprime même pas la surveillance dont se plaignait l’argumentaire de confidentialité. Comme l’a exposé Bert Hubert de PowerDNS, le DNS était « typically provided by the operator of a network », et le déplacer vers un tiers par défaut est « a net-negative for privacy for everyone », parce que ce tiers « gets a complete log per device of all DNS queries, in a way that can even be tracked across IP addresses »¹⁴.

Les requêtes ne sont pas cachées. Elles sont remises à un opérateur de résolveur américain à la place de l’administrateur, et l’administrateur est la seule partie écartée. Les éditeurs le savent aussi. La logique du « détecter un réseau administré et se retirer » de la section suivante existe précisément parce que le défaut passe outre l’administrateur, et ils ont livré l’interrupteur plutôt que de changer le défaut.

Demandez maintenant qui gagne à faire passer le DNS devant l’opérateur. La figure d’affiche est le journaliste sur le WiFi hostile d’un aéroport, et cette personne est réelle. L’industrie de la publicité et du pistage l’est aussi, dont les domaines franchissent la liste de blocage d’un réseau dès qu’une application ou un navigateur les résout par DoH.

Le blocage au niveau réseau, le Pi-hole, la liste de blocage d’entreprise, le résolveur filtrant, fonctionne en répondant au nom d’un pisteur par rien. DoH est la façon dont le nom obtient quand même une réponse. Et le plus gros opérateur de résolveur DoH public est Google¹⁵, une régie publicitaire qui livre aussi DoH dans son propre navigateur¹⁶.

Une fonctionnalité de confidentialité, vendue par l’entreprise qui vend le pistage, dont la conception défait l’outil que les gens font tourner pour le bloquer. Faites-en ce que vous voulez. Je me suis fait mon idée.

Même la version grossière de cette objection a été exprimée. En juillet 2019, l’association professionnelle des FAI britanniques a nommé Mozilla « Internet Villain » pour un DoH qui « bypass UK filtering obligations and parental controls, undermining internet safety standards in the UK »¹⁷. Ils avaient choisi une cible maladroite et un cadrage pire encore, se sont fait huer, et ont retiré la nomination.

Ôtez la politique, cependant, et l’observation qui la sous-tendait était juste, et elle tient que le contrôle contourné soit un filtre de protection de l’enfance, une liste de blocage d’entreprise ou un Pi-hole dans une pièce d’amis. DoH est bâti pour faire passer le DNS devant celui qui gère le réseau.

Et ce n’est pas une petite affaire, car DoH est désormais le plus difficile des trois à bloquer, tout court. DoT est sur 853, où un réseau peut encore le refuser. DoH non : de toutes les façons dont le DNS peut quitter un réseau, c’est celle sans aucune prise, ce qui en fait le plus gros risque de tous.

Cela touche la loi, pas seulement la sécurité. Au Royaume-Uni, le blocage qui a force de loi tourne chez le FAI par le DNS : la liste de la Internet Watch Foundation sur les images d’abus sexuels d’enfants, et les injonctions de la Haute Cour au titre de la section 97A sur le droit d’auteur, sont appliquées par filtrage DNS et IP sur le résolveur remis au client¹⁸.

Faites passer la moitié DNS de cela devant, par DoH, et le blocage ne s’applique pas à ce client. Une cour peut ordonner le blocage d’un site, on peut sommer un réseau de l’appliquer, et un navigateur qui résout par DoH trouve l’adresse quand même, par un canal que le réseau ne peut ni voir ni fermer. Appliquer une loi sur le cyberespace ou une décision de justice au niveau du réseau, là où cela a toujours été fait, devient quasiment impossible.

Et c’est là que la facture retombe sur tout le monde, pas seulement sur le réseau. Cassez le contrôle proportionné, le contrôle chirurgical qui bloquait un domaine nommé au résolveur au titre d’une décision de justice, et l’État ne renonce pas. Il se saisit d’un instrument plus grossier. L’Online Safety Act britannique est cet instrument : de vastes obligations pour les plateformes, des vérifications d’âge imposées, et l’Ofcom derrière avec les amendes, un régime qui touche chaque utilisateur et chaque service du pays¹⁹.

Je ne défends pas cette loi. Je montre d’où est venue la pression pour elle. Quand l’outil étroit qui appliquait la loi au réseau cesse de marcher, vous n’obtenez pas moins d’application, vous obtenez une application plus grossière, plus large, plus intrusive, visant tout le monde, parce que la version ciblée ne tient plus. C’est le prix à payer pour avoir cassé un contrôle de base, et ceux qui l’ont cassé ne sont pas ceux qui le paient.

Et ICANN s’en moque éperdument, car depuis la Californie ce n’est pas son problème. Quand un blocage échoue ou qu’une plateforme manque à ses obligations, ce n’est pas ICANN qui se retrouve devant un tribunal, c’est l’opérateur, la plateforme, l’entreprise, face à l’Ofcom et aux amendes. Les conséquences retombent sur tous ceux en aval d’une décision dont l’organisme qui l’a prise n’a jamais à répondre.

Alignez les conséquences et elles ont toutes la même forme : une chose que le réseau appliquait au résolveur, et qu’il ne peut plus.

DoT était la réponse honnête. Il chiffre votre DNS et laisse l’opérateur capable de faire son travail. DoH a gardé le chiffrement et a ajouté une chose par-dessus : l’opérateur ne peut plus le voir. Tout le reste à son sujet découle de ce seul choix.

Conçu aux États-Unis, contesté partout ailleurs

Rien de tout cela ne s’arrête à la Manche, et le lire comme un problème britannique le réduit à une fraction de sa taille. La même forme parcourt toute l’Europe et va jusqu’à l’Australie. Un instrument juridique à un bout, un blocage DNS sur le réseau à l’autre.

L’Australie fait ordonner par sa Cour fédérale aux FAI de désactiver l’accès aux sites contrefaisants étrangers en vertu de la section 115A du Copyright Act²⁰. Le Portugal se passe entièrement du tribunal : un protocole administratif par lequel les ayants droit signalent à un organisme nommé MAPINET, et les FAI bloquent par DNS sous quinze jours ouvrables²¹. Des lois différentes, une même hypothèse porteuse, et c’est l’hypothèse que DoH fait sauter sous chacune d’elles. Que le client résolve via le résolveur qu’on lui a remis.

Alors regardez ce que fait un État quand cette hypothèse s’effondre. Il cesse de s’appuyer sur le FAI et se met à ordonner aux résolveurs publics eux-mêmes de renvoyer la mauvaise réponse. Ce n’est pas une prévision. C’est une pile de jugements, et elle ne cesse de grandir.

Lisez cela comme une seule chose, pas cinq. Quelques entreprises américaines ont réécrit le DNS pour la planète entière, de leur propre autorité, ont cassé le contrôle proportionné que chacun de ces pays avait bâti, et ont laissé les tribunaux se débrouiller avec les décombres. Les réponses que donnent ces firmes, traînées devant un tribunal différent tous les quelques mois, vous disent exactement le poids que le reste du monde a pour elles. L’une fait appel et crie à la censure. L’une échoue la requête sans rien dire à l’utilisateur. Et OpenDNS, le résolveur qui a filtré tranquillement les maliciels pendant vingt ans et que ce billet a déjà présenté comme le modèle à copier, ne discute pas du tout. Il se coupe pour la France et pour le Portugal plutôt que de les servir à ces conditions²⁶.

Arrêtez-vous sur cette dernière. C’est le bon exemple de tout ce billet qui quitte la pièce. Le service qui protégeait des gens n’ayant jamais rien configuré trouve désormais un pays entier plus facile à abandonner qu’à servir, et la raison remonte tout droit à une décision de conception prise en Californie par des gens qui n’ont jamais eu à penser à un tribunal français ou portugais.

Voilà le motif, et je vais le nommer. C’est ce que l’ingénierie des plateformes américaines fait à tout ce qui n’est pas les États-Unis. Elle construit pour son propre marché, expédie le résultat au monde par défaut, et traite la loi de chaque autre pays, chaque régulateur, chaque communauté laissée en aval du changement comme le désordre de quelqu’un d’autre à nettoyer.

Et le gouvernement d’origine soutient ces firmes jusqu’au bout. En février 2025, la Maison-Blanche a apposé son nom à un mémorandum qualifiant les lois numériques des autres pays d’« extorsion à l’étranger » des entreprises américaines, nommant le Royaume-Uni et l’UE et pointant le représentant au commerce vers des droits de douane en guise de réponse²⁷. Six mois plus tard, un régulateur américain a écrit à une douzaine de firmes technologiques américaines pour les avertir qu’obéir à l’Online Safety Act britannique ou au Digital Services Act de l’UE pourrait elle-même enfreindre la loi américaine²⁸. Lisez cela deux fois. Le pays dont les entreprises ont cassé les contrôles dit maintenant à ces entreprises que se conformer à la réponse d’une autre démocratie à la casse est l’infraction.

Cela dit tout. Une loi votée par un parlement élu à Westminster ou à Bruxelles est requalifiée, depuis Washington, en attaque contre l’Amérique, et l’on ordonne aux firmes de l’ignorer. Ce n’est pas qu’elles aient pesé le reste du monde et tranché contre lui. Le reste du monde n’a jamais été sur la balance.

Le correctif n’est pas d’interdire le chiffrement

La conclusion paresseuse est donc “block DoH”, et elle est fausse, de la même façon que “block ICMP” est faux sur le pare-feu. Vous ne voulez pas revenir au DNS non chiffré. Les résolutions en clair sur le port 53 sont une vraie exposition, et y revenir pour regagner de la visibilité, c’est troquer un trou contre un autre.

Ce que vous avez réellement perdu, ce n’était pas le chiffrement. C’était le choix du résolveur. Reprenez-le donc et laissez le chiffrement exactement où il est.

La forme est la même que celle qui répare le DNS dans un domaine Active Directory : l’argument n’est jamais “désactiver la fonctionnalité”, c’est “décider qui a le droit de la conduire”. Voici ce que cela veut dire, par parties.

Faites tourner du DNS chiffré vous-même. Montez un résolveur qui sert DoH et DoT, pas seulement le port 53, pour qu’un client qui veut du chiffrement l’obtienne de vous. Vous ne pouvez pas dire aux clients « no DoH » et le penser vraiment en ne leur offrant aucun résolveur chiffré à eux. Donnez-leur-en un, et gardez dessus la liste de blocage, le flux de menaces et la journalisation comme avant.

Annoncez-le, pour que les clients le trouvent exprès. Discovery of Designated Resolvers (RFC 9462) permet à un client d’interroger un nom spécial, d’apprendre le résolveur chiffré propre à son réseau, et de basculer en DoH ou DoT vers celui-ci automatiquement²⁹. Un client compatible DDR chiffre alors son DNS et utilise le vôtre : la confidentialité que l’utilisateur voulait et le contrôle dont vous aviez besoin, d’un seul geste.

Répondez à l’interrupteur propre du navigateur. Firefox vérifie un domaine canari, use-application-dns.net, avant d’activer DoH par défaut : répondez-lui par NXDOMAIN ou SERVFAIL et Firefox se retire vers le résolveur système³⁰. Deux limites honnêtes, toutes deux dans les mots de Mozilla. Le canari « only applies to users who have DoH enabled as the default option. It does not apply for users who have made the choice to turn on DoH by themselves »³⁰. C’est donc un signal de désactivation par défaut, pas un verrou, et il ne fait rien sur l’application et le maliciel, qui n’ont rien demandé au navigateur.

Fixez la politique du navigateur là où vous administrez la machine. Sur un appareil qui vous appartient, ne comptez pas sur le canari. Le DnsOverHttpsMode de Chrome prend off, automatic et secure, et la documentation de Google indique que, s’il n’est pas défini, « for managed devices DNS-over-HTTPS queries will not be sent »³¹ ; Chrome désactive son propre DoH automatique dès qu’il repère une politique d’entreprise¹⁶. Pointez-le vers votre résolveur, ou mettez-le sur off et laissez DDR porter le chiffrement. Firefox a les réglages correspondants Enabled, ProviderURL et Locked³². Machine administrée, décision administrée, et la ligne que vous pouvez réellement fermer.

Refusez les solutions de repli à la frontière. Les règles sont courtes, et elles disent toutes la même chose : du DNS, quel qu’il soit, vers l’extérieur, uniquement depuis votre résolveur.

Vous n’attraperez pas chaque point d’accès DoH par adresse, et vous ne le pouvez pas, car un nouveau n’est qu’un serveur web et il n’y a pas de fin aux serveurs web. Alors mesurez ce que ce blocage coûte désormais. Pour faire à DoH ce que block 53 outbound faisait gratuitement, vous tirez une liste d’adresses de serveurs DoH que quelqu’un d’autre continue de scanner pour vous : les listes de blocage entretenues existent parce que c’est la seule voie qui reste, et l’une d’elles re-résout chaque domaine DoH public connu vers ses adresses IP actuelles toutes les heures, par tâche planifiée, et diffuse les changements³³. C’est le marché que le contournement a imposé.

Un contrôle qui tenait en une ligne fixe est désormais un abonnement à une cible mouvante, à courir après des serveurs web que n’importe qui peut monter plus vite qu’une liste ne peut les nommer. Le DNS de protection ferme l’autre bout : pointez l’amont de votre résolveur vers un service filtrant comme le PDNS du NCSC, qui « was built to hamper the use of DNS for malware distribution and operation »³⁴, et les mauvais domaines sont refusés avant que la connexion ne soit établie, pour chaque client qui passe par votre résolveur, ce qui, une fois ces règles en place, est la totalité d’entre eux.

Mettez cela face aux cinq lignes de tout à l’heure, et chacune a un contrôle qui la ferme. C’est le test d’un correctif : non pas « avons-nous bloqué DoH », mais « pour chaque chose qui peut choisir un résolveur, qu’est-ce qui l’empêche de choisir le mauvais ».

Rien de tout cela ne désactive le moindre bit de chiffrement. Les clients obtiennent toujours DoH, ils l’obtiennent simplement de vous, et ceux qui essaient de l’obtenir ailleurs se heurtent à un mur. La confidentialité est intacte et le contrôle est de retour. Ainsi, la seule chose que quiconque a perdue est la liberté de choisir un résolveur que vous n’avez jamais approuvé, et cette liberté n’a jamais été la sienne sur un réseau dont vous êtes responsable.

Puis-je demander ce qui a choisi ce résolveur

Voici la question à poser à quiconque vous dit que le réseau va très bien tel quel.

Quand une machine de votre réseau résout un nom, qu’est-ce qui a décidé quel résolveur a répondu ? Si la réponse honnête est « ce que le système a reçu », très bien, mais seulement si vous avez fermé les quatre autres lignes de ce tableau, car sinon c’est « ce que le système a reçu, sauf si le navigateur, une application, une page web ou quelque chose de plus vilain en a décidé autrement, auquel cas je n’en ai aucune idée et aucune trace ». Ce n’est pas une configuration DNS. C’est un espoir, et l’espoir n’attrape rien.

Je ne demande pas qui fait tourner le résolveur. Je demande quoi, sur chaque machine, a le droit de le choisir, et si vous pourriez nommer le résolveur vers lequel chaque résolution est partie hier. Sur un réseau où DoH n’est pas administré, vous ne le pouvez pas, et l’écart, c’est chaque application qui embarque son propre résolveur, chaque page qu’un utilisateur ouvre, et chaque maliciel qui a lu la même recherche que je viens de lier. Trois acteurs de menace nommés ont bâti leurs canaux sur cet écart précis, et l’un répond à un gouvernement.

Un protocole qui retire au réseau le choix du résolveur allait forcément être un cadeau pour quiconque le réseau cherchait à surveiller, et prétendre le contraire parce que le marketing disait « privacy » est la façon dont un contrôle qui comptait se retrouve désactivé par défaut et personne ne journalise le jour où c’est arrivé.

Chiffrez votre DNS. Faites tourner le résolveur vous-même. Annoncez-le, répondez au canari, fixez la politique, fermez la frontière. Gardez le chiffrement et gardez le choix. Vous pouvez avoir les deux, et si vous gérez des réseaux pour vivre, avoir les deux est le métier.

La confidentialité était le mot sur la boîte

Alors, hommage à qui de droit. Merci à l’ICANN, l’organisme américain qui tient la racine et a coécrit ceci de l’intérieur, d’avoir rejoué le manuel de la tech américaine une fois de plus : prendre un problème déjà résolu, envelopper le correctif dans un mot vertueux, et centraliser le résultat sur une poignée d’entreprises américaines qui finissent par tenir le texte en clair.

Et c’est toujours les États-Unis. L’organisme qui tient la racine, le résolveur par défaut de deux navigateurs désormais, la régie publicitaire qui fait tourner le plus gros résolveur public, le pays où atterrit le texte en clair : américain, à chaque fois. C’est un schéma, pas une série de malchances.

La confidentialité était l’écran de fumée. Le DNS était chiffré, privé et encore gouvernable sur le port 853 en 2016, et tous ceux qui comptaient le savaient. Ce que l’établissement a livré par-dessus, c’est un protocole bâti pour aveugler la seule personne responsable du réseau, une course aux armements permanente de listes de blocage re-scannées à l’heure, et des décisions de justice qui s’arrêtent net au navigateur.

Que ce soit de l’incompétence ou de la cupidité, je vous laisse en décider, quoique le bilan que j’ai lié penche d’un côté. Dans les deux cas, cela a eu raison du bon sens.

Et des décisions comme celle-ci sont la raison pour laquelle les appels à retirer la racine à l’ICANN reviennent sans cesse, et pour laquelle ils portent : pour que la communauté internationale ait voix au chapitre, au lieu que l’institution d’un seul pays décide du DNS pour tous les autres et appelle cela de la gérance.

On faisait tout cela avec une seule ligne, avant.