DNS chiffré : DoH, DoT et ce que ça change vraiment

Par La rédaction de Mon-Adresse-IP.net·Publié le 21 août 2026·

Chiffrer ses requêtes DNS est l'une des rares mesures de confidentialité qui se règlent en deux minutes et qui changent réellement quelque chose. Encore faut-il savoir ce que DoH et DoT protègent, ce qu'ils laissent parfaitement visible, et pourquoi ils cassent parfois le contrôle parental, le portail d'un hôtel ou l'accès à l'intranet.

Le problème : ce que voit un intermédiaire sur le port 53

Toute connexion commence par une question : quelle adresse IP se cache derrière ce nom de domaine ? C'est le rôle du DNS, détaillé dans notre guide du DNS. Le protocole a été normalisé en 1987 par les RFC 1034 et 1035, à une époque où le chiffrement généralisé n'était ni envisagé ni réaliste. Résultat : par défaut, une requête DNS voyage en clair sur le port 53, en UDP le plus souvent, en TCP quand la réponse est trop volumineuse.

Concrètement, chaque équipement traversé entre votre appareil et le résolveur peut lire le nom demandé et la réponse renvoyée. Cela inclut : la box ou le routeur, l'exploitant du réseau Wi-Fi auquel vous êtes connecté, votre fournisseur d'accès, et tout opérateur de transit sur le chemin. Le résolveur lui-même, qui est par défaut celui de votre opérateur, voit évidemment tout.

Deux propriétés distinctes sont en cause, et il est utile de ne pas les confondre :

• L'absence de confidentialité : les noms que vous demandez constituent un journal de navigation très fidèle. Un seul chargement de page déclenche souvent une dizaine de requêtes vers des domaines de mesure d'audience, de publicité ou d'hébergement d'images, qui en disent parfois plus long que le domaine principal.
• L'absence d'authentification du transport : rien n'empêche un intermédiaire de répondre à votre place. C'est le principe même de la redirection des erreurs de saisie vers une page de recherche, longtemps pratiquée par des opérateurs, et celui des portails captifs. C'est aussi le vecteur d'attaque le plus simple sur un réseau Wi-Fi public : un faux résolveur suffit à envoyer les visiteurs ailleurs.

Une nuance rarement mentionnée : le cache limite l'exposition. Une fois un nom résolu, votre système et votre navigateur conservent la réponse pendant la durée de vie indiquée dans l'enregistrement : le TTL, décrit dans notre page sur les types d'enregistrements DNS. L'absence de requête ne signifie donc pas l'absence de visite, et inversement, une salve de requêtes au réveil d'un téléphone ne traduit pas nécessairement une activité de l'utilisateur.

DoT, DoH, DoQ : trois façons de chiffrer

Les trois protocoles répondent au même problème : établir un canal chiffré et authentifié entre votre appareil (le « client » ou stub) et le résolveur récursif. Ils diffèrent uniquement par le transport utilisé, et cette différence a des conséquences politiques bien plus que techniques.

DoT : DNS over TLS

Normalisé par la RFC 7858 en 2016, DoT encapsule les messages DNS habituels dans une session TLS, sur le port 853 en TCP. Le client vérifie le certificat du résolveur contre son nom d'hôte : c'est le mode « strict », le seul qui protège réellement contre un intermédiaire actif. Un mode « opportuniste » existe, qui bascule en clair si le chiffrement échoue ; il améliore la confidentialité face à un observateur passif mais ne résiste pas à une interception délibérée.

La caractéristique déterminante de DoT est son port dédié. Un administrateur réseau voit immédiatement qu'un appareil fait du DNS chiffré, vers quel résolveur, à quels horaires et pour quel volume : sans jamais lire les noms demandés. Il peut aussi bloquer le port 853 d'un simple filtre, ce qui coupe net la résolution sur les appareils configurés en mode strict.

DoH : DNS over HTTPS

Normalisé par la RFC 8484 en 2018, DoH transporte le même message DNS binaire dans une requête HTTPS classique, sur le port 443, avec le type de contenu application/dns-message. La requête peut être envoyée en POST, ou en GET avec la question encodée dans un paramètre d'URL, ce qui la rend cachable par l'infrastructure HTTP.

Pour un équipement intermédiaire, une requête DoH ressemble à n'importe quelle connexion web vers un serveur donné. C'est un avantage décisif sur un réseau hostile ou censurant : bloquer DoH suppose de connaître et de filtrer les adresses des résolveurs, une liste qui change en permanence. C'est symétriquement un casse-tête pour un administrateur légitime, qui perd d'un coup son meilleur point d'observation : dans beaucoup d'organisations, les journaux DNS sont la principale source de détection des machines compromises, un poste infecté se trahissant par les noms qu'il interroge.

DoQ : DNS over QUIC

Normalisé plus récemment par la RFC 9250, DoQ transporte le DNS sur QUIC, en UDP, sur le port 853 également. Il apporte les qualités de QUIC : établissement de session plus rapide, absence de blocage en tête de file lorsqu'une réponse tarde, et surtout continuité lors d'un changement de réseau, passer de la Wi-Fi à la 5G ne casse pas la session. C'est le transport le mieux adapté aux liens mobiles et aux liaisons à pertes.

Sa prise en charge reste toutefois nettement plus rare que celle de DoH côté clients grand public. On le rencontre surtout dans des résolveurs locaux, des applications spécialisées et quelques résolveurs publics. À signaler également : DNSCrypt, antérieur à ces normes et jamais passé par l'IETF, encore utilisé par certains outils, et qui reste une option valable sans être un standard.

Comparatif des quatre modes de résolution

Ce que le chiffrement du DNS ne fait pas

C'est la section qui détermine si la mesure vaut la peine dans votre cas. Le DNS chiffré supprime une source d'information parmi plusieurs ; il ne rend rien invisible.

La destination finale reste visible

Une fois le nom résolu, votre appareil ouvre une connexion vers l'adresse IP obtenue. Cette adresse, elle, circule évidemment en clair dans chaque paquet : c'est le principe même du routage. Votre opérateur sait donc à quelles adresses vous parlez, quand, pendant combien de temps et avec quels volumes. L'hébergement mutualisé et les réseaux de diffusion de contenu introduisent une ambiguïté (des milliers de sites peuvent partager la même adresse), mais cette ambiguïté est un effet de bord, pas une protection conçue pour vous.

Le nom du site figure encore dans la poignée de main TLS

Au tout début d'une connexion HTTPS, le client annonce le nom du serveur qu'il souhaite joindre dans une extension appelée SNI (Server Name Indication), afin que l'hébergeur sache quel certificat présenter. Cette extension est envoyée en clair, y compris en TLS 1.3. La version 1.3 a bien chiffré le certificat du serveur, qui trahissait auparavant le nom lui aussi ; il reste le SNI. Autrement dit : sur une majorité de connexions, un observateur situé sur le chemin lit toujours le nom du site visité, même avec un DNS parfaitement chiffré.

ECH : la brique manquante, et son état réel

ECH (Encrypted Client Hello) est le mécanisme conçu pour combler exactement cette faille : il chiffre le début de la négociation TLS, SNI compris, à l'aide d'une clé publique que le site publie dans le DNS, dans un enregistrement de type HTTPS. Le lien avec notre sujet est direct : ECH n'a de sens que si la requête DNS qui récupère cette clé est elle-même chiffrée, sans quoi il suffirait de lire cette requête pour retrouver le site visé. DoH et ECH forment donc un couple, pas deux options concurrentes.

Quelques réserves honnêtes, cependant. La spécification est restée longtemps à l'état de brouillon à l'IETF et son déploiement dépend entièrement des hébergeurs : si le site que vous visitez ne publie pas de configuration ECH, vous n'y gagnez rien, quel que soit votre navigateur. Lorsque ECH fonctionne, le nom visible depuis l'extérieur devient celui du fournisseur qui héberge le site, ce qui révèle l'hébergeur mais plus la page : c'est un gain réel, pas une invisibilité. Enfin, certains réseaux et certains pays bloquent purement et simplement les connexions qui utilisent ECH, ce qui provoque des pannes difficiles à diagnostiquer.

Vous déplacez la confiance, vous ne la supprimez pas

C'est le point le plus important. Chiffrer le DNS ne signifie pas que personne ne voit vos requêtes : cela signifie que seul le résolveur que vous avez choisi les voit, à la place de votre opérateur. Vous remplacez un tiers de confiance par un autre. Les questions à se poser sont donc les mêmes que pour un opérateur : qui exploite ce service, sous quelle juridiction, que dit sa politique de confidentialité, quelle est la durée de conservation des journaux, ces journaux sont-ils liés à votre adresse IP ?

Un détail technique mérite l'attention : l'extension EDNS Client Subnet permet à un résolveur de transmettre une partie de votre préfixe IP aux serveurs faisant autorité, afin que les réseaux de diffusion de contenu vous orientent vers un serveur proche. Certains résolveurs publics l'utilisent pour préserver les performances, d'autres s'y refusent par principe de confidentialité. Ce choix est documenté par les opérateurs sérieux ; il fait partie des critères de sélection, au même titre que le filtrage éventuel des domaines malveillants. Si vous comparez plusieurs résolveurs, notre guide changer de serveur DNS détaille la procédure sur chaque système.

Le second segment reste en clair

DoH, DoT et DoQ ne chiffrent que le trajet entre vous et le résolveur récursif. Derrière lui, les échanges entre ce résolveur et les serveurs faisant autorité (la racine, les serveurs de .fr, ceux du domaine visé) se déroulent très majoritairement en clair, sur le port 53. Des travaux existent pour chiffrer aussi ce second segment de façon opportuniste, mais leur déploiement reste marginal. Parler de « DNS chiffré de bout en bout » est donc abusif : on chiffre le premier saut, celui qui vous concerne le plus directement, pas la chaîne entière.

Ce n'est pas de l'anonymat

Le chiffrement du DNS ne masque pas votre adresse IP aux sites que vous visitez, n'efface aucun cookie et ne change rien à l'empreinte de votre navigateur, qui vous identifie sans avoir besoin de savoir quel résolveur vous utilisez. Il ne modifie pas davantage les obligations légales de conservation qui pèsent sur les opérateurs français, décrites dans notre page consacrée à ce que votre FAI conserve. Si votre objectif est de dissimuler votre adresse aux sites visités, c'est d'un VPN qu'il s'agit, avec les contreparties propres à cette solution. Le DNS chiffré, lui, est une mesure d'hygiène, utile et peu coûteuse, à sa place dans un ensemble.

Où activer le DNS chiffré, et qui gagne en cas de conflit

Trois niveaux d'activation coexistent, et c'est là que se joue l'essentiel des mauvaises surprises : leur hiérarchie décide du résolveur réellement interrogé, souvent à l'insu de l'utilisateur.

Dans le navigateur

Firefox, Chrome, Edge et les navigateurs dérivés proposent tous un réglage « DNS sécurisé » ou « DNS via HTTPS » dans leurs paramètres de confidentialité. Le navigateur résout alors les noms lui-même, en DoH, sans passer par le résolveur du système. Deux comportements méritent d'être connus :

• La bascule automatique : en mode automatique, les navigateurs basés sur Chromium vérifient si le résolveur configuré sur la machine figure dans leur liste de fournisseurs connus proposant DoH ; si oui, ils passent au même fournisseur en version chiffrée. Vous gardez donc votre résolveur, en mieux protégé, sans rien changer.
• Le domaine témoin : Firefox interroge un nom spécial (use-application-dns.net) avant d'activer sa résolution chiffrée ; si le réseau répond que ce nom n'existe pas, le navigateur en déduit qu'un filtrage local est en place et renonce à DoH. C'est le mécanisme officiel qui permet à un réseau familial ou d'entreprise de signaler qu'il ne souhaite pas être contourné.

Safari ne propose aucun réglage de ce type : il suit la configuration du système, ce qui est cohérent avec l'approche d'Apple par profils.

Dans le système

1. Windows 11 Paramètres, Réseau et Internet, puis Wi-Fi ou Ethernet, Attribution du serveur DNS, Modifier. En mode manuel, un menu « Chiffrement DNS préféré » propose « Chiffré uniquement (DNS sur HTTPS) ». Le système n'accepte au départ que les résolveurs de sa liste interne ; les autres s'ajoutent en ligne de commande avec netsh dns add encryption. Windows 10 ne dispose pas de cette interface.
2. Android 9 et suivants Paramètres, Réseau et Internet, DNS privé. Le mode « Nom d'hôte du fournisseur » active DoT en mode strict pour tout l'appareil, y compris en données mobiles. Le mode « Automatique » tente DoT de façon opportuniste vers le résolveur du réseau et retombe en clair s'il ne répond pas.
3. iOS et macOS Aucun réglage natif : la configuration passe par un profil DNS chiffré, installé soit par une application, soit par un fichier de configuration. Le profil apparaît ensuite dans Réglages, Général, VPN et gestion de l'appareil, et peut être désactivé d'un geste : utile face à un portail captif.
4. Linux Avec systemd-resolved, l'option DNSOverTLS=yes dans /etc/systemd/resolved.conf active DoT en mode strict, opportunistic en mode dégradé. Pour DoH, unbound et knot-resolver ne savent pas relayer vers un serveur chiffré : il faut un relais spécialisé (dnscrypt-proxy, cloudflared ou dnsproxy) placé devant le résolveur local et configuré pour relayer vers un résolveur chiffré.

Sur le réseau

La solution la plus complète consiste à installer un résolveur local sur le réseau, sur un petit ordinateur monocarte ou un NAS, et à le distribuer par DHCP à tous les appareils. Ce résolveur relaie ensuite les requêtes en DoT ou DoH vers l'extérieur. L'intérêt : les objets connectés, téléviseurs et consoles, qui n'offrent aucun réglage DNS, se retrouvent protégés sans intervention. La limite : beaucoup de ces appareils embarquent une adresse de résolveur public en dur et ignorent le DHCP, ce qui oblige à rediriger le port 53 sortant sur le routeur pour les ramener dans le rang. Toutes les box ne permettent pas de modifier le DNS distribué ; notre panorama des FAI français précise les marges de manœuvre selon les opérateurs.

Qui l'emporte : la règle de priorité

Les effets de bord concrets

Le filtrage parental ou d'entreprise cesse de s'appliquer

La quasi-totalité des filtres familiaux, des solutions de contrôle parental des opérateurs et des passerelles de sécurité d'entreprise reposent sur le DNS : ils répondent une adresse de blocage à la place de l'adresse réelle. Dès qu'un navigateur pose ses questions ailleurs, en HTTPS, le filtre n'est plus sur le chemin. L'effet est souvent involontaire : un adolescent qui accepte une proposition de « DNS sécurisé » n'a pas cherché à contourner quoi que ce soit.

Les parades existent, à condition d'être honnête sur leur portée : publier une réponse négative pour le domaine témoin de Firefox, désactiver le DNS sécurisé par stratégie d'entreprise sur Chrome et Edge, bloquer le port 853 en sortie, et remplacer le filtre par un résolveur filtrant qui parle lui-même DoH. Aucune de ces mesures ne résiste à un utilisateur déterminé et technicien ; elles suffisent en revanche à éviter les contournements accidentels, qui représentent l'immense majorité des cas.

Le portail captif ne s'ouvre plus

Un portail d'hôtel, d'aéroport ou de train fonctionne en interceptant vos requêtes DNS pour vous rediriger vers sa page de connexion. Avec un DNS chiffré en mode strict, l'interception échoue : aucun nom ne se résout, la page d'accueil n'apparaît jamais, et le symptôme ressemble à « connecté au Wi-Fi, mais pas d'Internet ». Le mode « DNS privé strict » d'Android en est le cas d'école.

1. Repérez le symptôme Le Wi-Fi est associé, l'adresse IP est obtenue, mais aucun site ne se charge et aucun portail n'apparaît.
2. Désactivez temporairement Repassez le DNS privé en « Automatique » sur Android, désactivez le profil DNS sur iOS, ou le DNS sécurisé du navigateur.
3. Ouvrez le portail Saisissez directement une adresse en HTTP, jamais en HTTPS : la redirection d'un portail ne peut pas s'opérer sur une connexion chiffrée sans provoquer une alerte de sécurité.
4. Réactivez immédiatement Une fois l'accès obtenu, remettez le chiffrement : c'est précisément sur ce type de réseau qu'il est le plus utile, comme le rappelle notre guide sur le Wi-Fi public.

Les noms internes ne se résolvent plus : le DNS scindé en télétravail

Beaucoup d'entreprises pratiquent le « DNS scindé » (split-horizon) : le nom intranet.entreprise.fr renvoie une adresse privée lorsqu'il est interrogé depuis le réseau interne ou le VPN, et rien du tout, ou une adresse publique différente, depuis l'extérieur. Si votre navigateur résout ce nom lui-même par DoH, il obtient la réponse publique, et l'application interne devient inaccessible alors que le VPN fonctionne parfaitement.

Le diagnostic est simple : si le nom fonctionne dans un terminal mais pas dans le navigateur, la résolution chiffrée du navigateur est en cause. Les corrections passent par les listes d'exclusion de domaines prévues à cet effet, par les stratégies d'entreprise qui désactivent le DoH sur les postes gérés, ou par les règles de résolution que le client VPN installe sur le système et que le navigateur, lui, ignore. Les navigateurs modernes excluent bien de la résolution chiffrée les noms figurant dans le fichier hosts et les domaines à usage local, mais c'est une précaution à vérifier, pas une garantie universelle.

Les blocages administratifs cessent de fonctionner

En France, une partie des blocages de sites décidés par l'autorité judiciaire ou administrative est mise en œuvre au niveau des résolveurs DNS des opérateurs. C'est le cas des blocages prononcés en matière de contrefaçon, des mesures visant les sites de retransmission sportive illicite, du blocage administratif prévu par la LCEN pour les contenus terroristes et pédopornographiques (qui redirige vers une page du ministère de l'Intérieur) ou encore des décisions relatives aux sites pour adultes ne vérifiant pas l'âge de leurs visiteurs. Utiliser un autre résolveur, chiffré ou non, rend ces blocages inopérants.

Le sujet a d'ailleurs évolué : des décisions de justice ont étendu des obligations de blocage à des résolveurs publics tiers, et l'un d'eux a préféré cesser de servir les utilisateurs français plutôt que de les appliquer. Sur le plan juridique, deux choses sont à distinguer : le choix d'un résolveur DNS est libre et n'est pas en soi une infraction ; en revanche, l'accès à un contenu illicite reste soumis au droit applicable, et le fait d'être passé par un autre résolveur ne modifie ni la nature du contenu ni la responsabilité de celui qui le consulte ou le diffuse. Cette page décrit un mécanisme technique ; elle ne constitue pas un conseil juridique.

Des performances parfois moins bonnes

Un résolveur public éloigné, ou qui refuse de transmettre votre préfixe réseau aux serveurs faisant autorité, peut vous orienter vers un serveur de diffusion de contenu géographiquement moins proche que celui qu'aurait choisi le résolveur de votre opérateur. La différence est mesurable et se vérifie soi-même en comparant les temps de réponse vers les adresses obtenues, avec les commandes décrites dans notre guide ping et traceroute. À l'inverse, le maintien d'une session TLS ouverte vers le résolveur évite d'établir une connexion à chaque requête et compense en partie ce surcoût.

DNSSEC : authenticité, pas confidentialité

DNSSEC est régulièrement présenté comme une alternative au DNS chiffré. C'est un contresens : les deux mécanismes traitent des problèmes différents et se complètent.

DNSSEC ajoute des signatures cryptographiques aux enregistrements DNS. Chaque zone signe ses données, et une chaîne de confiance remonte jusqu'à la racine, signée depuis 2010. Un résolveur validant vérifie ces signatures et peut ainsi détecter qu'une réponse a été fabriquée ou modifiée en chemin : c'est la parade historique à l'empoisonnement de cache. Les enregistrements concernés (DNSKEY, RRSIG, DS) figurent dans notre référence des types d'enregistrements DNS.

Ce que DNSSEC ne fait pas : chiffrer quoi que ce soit. Une réponse signée reste parfaitement lisible par tout intermédiaire. Inversement, DoH et DoT garantissent que vous parlez bien au résolveur choisi, sans écoute ni modification, mais ne disent rien de la véracité de ce que ce résolveur vous répond.

La complémentarité est donc exacte : DNSSEC protège la donnée depuis la zone d'origine jusqu'au résolveur validant ; DoH, DoT ou DoQ protègent le dernier segment, entre ce résolveur et vous. Ce dernier segment est précisément celui que DNSSEC laisse à découvert, car votre appareil ne valide généralement pas lui-même les signatures : il se contente de croire l'indicateur de validation placé par le résolveur, indicateur qu'un intermédiaire pourrait falsifier sur un lien en clair.

Deux réserves de terrain, pour rester honnête : d'une part, la proportion de zones signées reste inégale selon les extensions, .fr est signée, beaucoup de domaines ne le sont pas, et une réponse non signée n'est pas une réponse invalide, simplement une réponse non vérifiable. D'autre part, tout résolveur qui filtre volontairement des domaines (contrôle parental, blocage de publicités) renvoie par construction des réponses qui ne peuvent pas valider : filtrage et validation stricte sont, sur ces domaines-là, incompatibles.

Vérifier que son DNS est réellement chiffré

Il existe des pages de test proposées par les grands résolveurs, mais elles répondent à une question étroite : « la requête que ce navigateur vient de m'envoyer était-elle chiffrée ? ». Elles ne disent rien des autres applications, ni des autres réseaux. Trois méthodes complémentaires donnent une image fiable.

Interroger le système

# Windows 11 : état du chiffrement et résolveurs déclarés
netsh dns show encryption
netsh dns show global

# Linux avec systemd-resolved : chercher la mention +DNSOverTLS
resolvectl status

# Vérifier quel résolveur répond réellement, et en combien de temps
resolvectl query mon-adresse-ip.net

Sur Android, l'écran « DNS privé » affiche le nom d'hôte configuré ; sur iOS, le profil actif apparaît dans les réglages de gestion de l'appareil. Dans Firefox, la page about:networking#dns comporte une colonne indiquant, nom par nom, si la résolution est passée par le résolveur chiffré ; dans les navigateurs Chromium, chrome://net-internals/#dns renseigne l'état du DNS sécurisé.

Observer le trafic

C'est la seule vérification qui ne se laisse pas raconter d'histoires. Si des requêtes DNS en clair continuent de quitter la machine, quelque chose contourne votre configuration :

# Sur la machine (droits administrateur requis)
sudo tcpdump -n -i any port 53

# Aucune ligne ne doit apparaître si tout passe en DoH ou DoT.
# Les requêtes du résolveur local, lui, sont normales.

Sur un réseau domestique, la même observation se fait depuis le routeur en comptant les flux sortants vers le port 53 : c'est ainsi que l'on repère les téléviseurs et objets connectés qui interrogent un résolveur public codé en dur, en ignorant totalement le vôtre.

Les limites de ces vérifications

• Un test positif dans le navigateur ne dit rien du client de messagerie, du gestionnaire de mises à jour ni des applications mobiles.
• Le résultat vaut pour ce réseau, à cet instant. Un réglage par interface peut n'être actif qu'en Wi-Fi et pas en Ethernet, ou l'inverse.
• Une suite de sécurité qui inspecte le trafic chiffré, ou un proxy d'entreprise, peut se placer entre le navigateur et le résolveur : la connexion reste chiffrée, mais pas jusqu'où vous le croyez.
• « Chiffré » ne veut pas dire « privé ». Le résolveur voit tout ; la seule question qui vaille est de savoir ce qu'il en fait.

Que choisir selon votre profil

Particulier, réseau domestique simple

Réglez le chiffrement au niveau du système sur vos appareils principaux, et laissez le navigateur en mode automatique : un seul point de configuration, aucune divergence entre applications. Prenez cinq minutes pour lire la politique de confidentialité du résolveur retenu plutôt que de choisir la première adresse trouvée. Si votre priorité est la performance plutôt que la confidentialité, conserver le résolveur de votre opérateur reste un choix défendable : il est proche, il connaît les infrastructures locales, et il ne vous apprend rien qu'il ne sache déjà.

Télétravailleur

N'activez pas le DoH du navigateur sur une machine qui accède à un réseau d'entreprise : c'est la cause numéro un des noms internes introuvables. Laissez le client VPN imposer son résolveur pendant la connexion, et réservez le chiffrement système aux moments où vous êtes hors tunnel. Si votre organisation fournit un résolveur interne chiffré, utilisez-le : vous cumulez confidentialité sur le lien et résolution correcte des noms internes.

Parent

Un filtre installé sur la box ne survit pas à un navigateur qui fait son propre DoH. La configuration robuste consiste à utiliser un résolveur filtrant qui parle DoH ou DoT, configuré au niveau du système sur les appareils des enfants, complété par le domaine témoin et les stratégies de navigateur pour empêcher les contournements accidentels. Gardez en tête la limite réelle : aucun dispositif technique ne remplace la conversation, et un adolescent motivé trouvera toujours un chemin, un partage de connexion mobile suffit.

Administrateur réseau

Le réflexe défensif est de tout bloquer ; il n'est pas tenable, DoH étant indiscernable du web. L'approche qui fonctionne consiste à offrir mieux que ce que les postes iraient chercher ailleurs : un résolveur interne chiffré, rapide, avec ses journaux et son filtrage, imposé par stratégie sur les navigateurs, complété par la fermeture du port 853 en sortie et la publication d'une réponse négative pour le domaine témoin. Conservez surtout votre point d'observation : les journaux DNS internes restent l'un des meilleurs signaux de compromission d'un poste, et les perdre coûte plus cher que le gain de confidentialité obtenu sur un réseau que vous administrez déjà.

Questions fréquentes