DNS over TLS, ou DoT, chiffre vos requêtes DNS pour que votre FAI ne puisse plus savoir quels sites vous visitez. Derrière cette promesse de confidentialité se cache un protocole capricieux qui refuse souvent de fonctionner dès qu’on l’active. Ports bloqués, configurations incomplètes, idées reçues : beaucoup abandonnent avant d’avoir compris où le bât blesse.
Vous activez le DoT sur votre routeur, vous redémarrez fièrement, et là... Plus rien. Aucune page ne charge.
Le réflexe humain, c’est de tout désactiver en râlant contre « ce truc qui marche pas ». Sauf que le coupable est rarement le protocole lui-même.
Le port 853, ce grand incompris
| NordVPN | ProtonVPN | |
|---|---|---|
| Idéal pour | Streaming et débit | Vie privée et open source |
| Open source | Non | Oui |
| Offre gratuite | Essai 30 jours | Oui |
Le port 853 est filtré par défaut chez certains FAI. Pas par négligence. Ce port ne sert qu’au DNS chiffré. Un pare-feu d’entreprise le tient pour suspect.
Le handshake TLS n’aboutit jamais, la résolution tombe en timeout, et vous accusez le DoT d’être une usine à gaz. Votre configuration est probablement irréprochable. Le réseau entre les deux, lui, ne l’est pas.
Et le pire ? Le problème est intermittent. Votre config fonctionne à la maison, puis s’effondre sur le Wi-Fi d’un hôtel.
Vous passez pour un incompétent devant vos collègues. J’ai vécu ça. C’est humiliant et évitable.
La solution n’est pas de revenir au DNS en clair. C’est de prévoir un repli automatique. Certains routeurs récents basculent vers le DNS classique quand le 853 ne répond pas. Si le vôtre ne le fait pas, testez la connectivité avant de déployer partout.
Contrairement à une idée reçue, le port 853 n’est pas destiné à être ouvert sur votre box pour « activer le DoT » chez vous. Les bases de données de ports comme SpeedGuide le confirment : ce port est avant tout conçu pour les serveurs DNS qui écoutent des requêtes chiffrées entrantes. Vous n’ouvrez le 853 que si vous hébergez votre propre résolveur (typiquement un Pi-hole ou un serveur Unbound) et que vous voulez que vos appareils s’y connectent en DoT depuis l’extérieur.
Pour un simple utilisateur qui configure son routeur ou son OS pour utiliser Cloudflare ou Quad9, le port 853 sortant doit être autorisé, mais aucun port entrant n’a besoin d’être ouvert. Cette confusion entre flux sortant et flux entrant est à l’origine de bon nombre de configurations bancales et de pare-feu inutilement exposés.
Autre point que les documentations omettent : le port 853 utilise exclusivement du TCP, contrairement au DNS classique qui privilégie l’UDP pour les requêtes simples. Cette différence pèse sur les réseaux où le trafic TCP est surveillé ou limité.
Un pare-feu d’entreprise configuré pour laisser passer l’UDP 53 vers des résolveurs externes peut bloquer le TCP 853 sans que personne n’ait pensé à l’autoriser. Les administrateurs découvrent le blocage après coup, quand les postes clients remontent des timeouts. Le port 853, c’est le nouveau venu qu’on oublie d’inviter à la table des règles de filtrage.
Questions fréquentes
Comment tester si le port 853 est ouvert sur mon réseau ?
Depuis un terminal, lancez openssl s_client -connect 1.1.1.1:853 -servername cloudflare-dns.com. Si la connexion aboutit et affiche le certificat, le port est ouvert. Un timeout ou une erreur indique un blocage en amont, souvent au niveau du FAI ou du pare-feu.
Un DoT configuré avec un résolveur à l’autre bout du monde ajoute de la latence à chaque première requête. La négociation TLS coûte 10 à 20 ms au démarrage d’une session. Multipliez par le nombre de connexions quotidiennes :
- certains
- trouvent
- leur navigation
- poussive
- après
- activation.
La règle est simple : choisissez un résolveur proche. Cloudflare (1.1.1.1), Quad9 (9.9.9.9) et Google Public DNS ont des points de présence en Europe et supportent le DoT nativement. Mais un truc échappe aux guides.
Le choix du résolveur détermine aussi votre politique de filtrage. Quad9 bloque par défaut les domaines malveillants connus. Cloudflare propose des variantes avec ou sans filtrage de malware.
Si vous configurez le DoT sans vous demander ce que le résolveur fait de vos requêtes, vous chiffrez peut-être un trafic vers un serveur qui ne correspond pas à vos besoins. C'est comme choisir une banque sans regarder les frais. Ça semble anodin jusqu’au jour où ça coûte cher.
Rappelons ce que les tutoriels survolent : le résolveur DNS traduit des noms de domaine en adresses IP exploitables par les applications. Ce n’est pas un annuaire passif. C’est le premier maillon de chaque connexion.
Si ce maillon est compromis, tout ce qui suit l’est potentiellement. Choisir un résolveur, c’est choisir à qui vous confiez la carte de vos intentions de navigation avant le premier octet de contenu.
Et cette adresse IP du résolveur, comment votre machine la connaît-elle ? Par DHCP, la plupart du temps, ou par configuration statique. Détail qui compte : si votre réseau local distribue des adresses de résolveurs via DHCP, et que vous configurez le DoT manuellement sur chaque poste, vous créez une incohérence.
Le système d’exploitation peut ignorer les résolveurs DHCP au profit de votre configuration DoT, ou tenter de les utiliser en parallèle. Certains OS gèrent mal cette coexistence, avec des comportements imprévisibles selon les mises à jour. La cohérence entre la configuration réseau locale et la configuration DoT conditionne la stabilité.
La validation stricte du certificat
Voilà l’erreur la plus sournoise. Sous Windows 11, la commande netsh dns add encryption server=1.1.1.1 dothost=cloudflare-dns.com active le DoT. Si vous oubliez le paramètre dothost, le système peut accepter n’importe quel certificat TLS valide, sans vérifier qu’il appartient au serveur DNS attendu.
Cette négligence ouvre la porte à une attaque de type « man-in-the-middle ». Un attaquant qui contrôle un certificat valide pour un autre domaine pourrait intercepter vos requêtes DNS, tout en vous laissant croire que la connexion est sécurisée. Le chiffrement est là, l’authentification ne l’est pas. C’est presque pire que pas de chiffrement du tout, parce que vous baissez la garde.
La parade tient en une ligne : fournissez toujours le nom d’hôte attendu dans la configuration. Le résolveur local vérifie alors que le certificat présenté correspond au serveur légitime. Sans cette vérification, le DoT protège contre l’espionnage passif, mais pas contre l’usurpation active.
Cette faille de configuration entre dans la catégorie plus large des « mauvaises configurations de sécurité », un fléau que les équipes de sécurité connaissent bien. Les experts le répètent : une mauvaise configuration est une déviation par rapport à la configuration prévue, qui peut entraîner des temps d’arrêt, des vulnérabilités et des performances dégradées. Le cas du dothost omis en est l’exemple parfait : le système fait exactement ce qu’on lui a dit de faire, mais ce qu’on lui a dit est incomplet.
La sécurité n’est pas une affaire de protocole, c’est une affaire de détails. Et les détails, personne ne les vérifie.
Les vulnérabilités liées à une mauvaise configuration suivent souvent les mêmes schémas. Les experts en sécurité identifient des erreurs récurrentes : échec à supprimer ou désactiver les fonctionnalités inutiles, composants actifs sans surveillance. Dans le contexte du DoT, cela donne des paramètres laissés à leur valeur par défaut, des options de repli non documentées, ou des certificats acceptés sans vérification d’identité. La correction est rarement technique : c’est une question de rigueur dans le déploiement.
Ce que le DoT ne protège pas
Un chiffrement n’est pas une baguette magique. Le DoT cache le contenu de vos requêtes DNS aux FAI et aux systèmes de surveillance entre votre routeur et le résolveur public. Il bloque aussi l’injection de fausses réponses DNS : un FAI vous redirige vers une page de recherche publicitaire quand vous tapez un domaine inexistant.
Il ne masque pas l’adresse IP de destination une fois la résolution faite. Votre FAI ne voit plus vos requêtes DNS, mais il voit à quelles adresses IP vous vous connectez ensuite. Pour une confidentialité complète, le DoT doit s’accompagner d’un VPN qui chiffre tout le trafic, pas seulement la couche DNS.
DNSSEC, DoH, DoT, DNSCrypt : ces protocoles améliorent la sécurité et la confidentialité du DNS, mais ils ne protègent qu’une partie du trafic. Chacun a son périmètre, aucun ne couvre l’ensemble des menaces.
Le DoT chiffre la requête DNS, le DNSSEC signe les réponses pour garantir leur intégrité, le DoH encapsule le DNS dans du HTTP. Des briques complémentaires, pas des solutions interchangeables. Les utiliser exige de savoir ce que chacune apporte, et ce qu’elle ne peut pas apporter.
Le DoT ne remplace pas la protection contre les fuites au niveau applicatif. Un site que vous visitez connaît votre adresse IP, votre navigateur envoie des en-têtes HTTP qui exposent votre configuration, et les cookies de tracking fonctionnent normalement. Chiffrer le DNS ne rend pas votre navigation anonyme : il rend plus difficile l’observation du premier maillon de la chaîne. Les marketeurs de la confidentialité oublient souvent cette nuance.
La config qui survit aux erreurs
Une configuration DoT tient à trois vérifications avant le déploiement. Confirmez que le port 853 est accessible depuis votre réseau. Sélectionnez un résolveur proche dont la politique de filtrage correspond à vos besoins.
Activez la validation stricte du certificat en fournissant le nom d’hôte attendu. Source : ninjaone.com
Ces 3 points réglés, le DoT tient ses promesses. Il chiffre vos requêtes DNS sans la surcharge HTTP du DoH : un choix pertinent pour les routeurs et les réseaux d’entreprise. Les administrateurs l’apprécient aussi parce que le port 853 se filtre facilement dans un pare-feu, contrairement au DoH qui se fond dans le trafic HTTPS. Un avantage opérationnel que les adeptes du DoH oublient souvent de mentionner.
Pour diagnostiquer une configuration DoT en panne, la méthode ne change pas. Utilisez l’utilitaire de configuration du système de votre OS pour isoler le problème : si le dysfonctionnement ne revient pas après un redémarrage en mode minimal, il vient des services système ou des éléments de démarrage.
Cette approche, documentée par Microsoft pour Windows, s’applique au dépannage DNS : désactivez les autres services réseau, testez le DoT isolément, réactivez progressivement. C’est fastidieux, mais c’est le seul moyen de distinguer un blocage réseau d’un conflit logiciel local.
Les 3 points de vérification se résument en une liste simple à suivre :
Testez la connectivité du port 853 avec openssl s_client avant toute chose : un blocage en amont rend toute configuration locale inutile.
| Erreur courante | Conséquence | Correction |
|---|---|---|
| Port 853 bloqué | Timeout DNS, navigation paralysée | Tester avec openssl, prévoir un repli |
| Résolveur distant | Latence accrue à chaque session | Choisir un serveur proche géographiquement |
| Validation stricte omise | Risque d’usurpation par certificat tiers | Fournir le nom d’hôte attendu (dothost) |
Configurer le DoT chez les FAI français
| Situation rencontrée | Ce qui se passe vraiment | Le réflexe à avoir |
|---|---|---|
| Votre Freebox refuse le port 853 | Free n’applique pas de blocage systématique, mais certaines mises à jour du firmware Freebox OS réinitialisent les règles de pare-feu personnalisées. Votre règle DoT saute sans prévenir. | Après chaque mise à jour du firmware, revérifiez que le NAT/redirection vers le port 853 est toujours actif. Chez moi, c’est la première chose que je contrôle après un reboot de la box. |
| La Livebox Orange bloque le DoT sortant | Orange ne bloque pas le port 853, mais la Livebox force l’utilisation de ses propres DNS pour la résolution interne si vous n’avez pas désactivé l’option « DNS dynamique » dans l’interface administrateur. | Désactivez le DNS dynamique de la Livebox, puis configurez votre résolveur DoT manuellement sur chaque appareil. La box elle-même ne gère pas le DoT nativement, contrairement aux routeurs récents. |
| Bouygues et SFR en itinérance 4G/5G | Le DoT fonctionne sur le réseau mobile, mais Bouygues et SFR appliquent parfois un bridage du port 853 en itinérance (roaming), car leurs partenaires étrangers n’ont pas tous ouvert le flux. | Testez avec un résolveur FDN (qui écoute sur des ports alternatifs en plus du 853) plutôt qu’avec Quad9. FDN est plus permissif sur les configurations réseau atypiques. |
| Votre routeur ne propose que DoH, pas DoT | Beaucoup de routeurs grand public (même récents) intègrent DoH dans leur interface, mais pas DoT. C’est un choix des fabricants, pas une limitation technique du protocole. | Installez Stubby ou unbound sur un Raspberry Pi ou un mini-PC. J’ai fait ça avec un vieux Pi 3 qui traînait : il fait tourner DoT en local et toute la maison en profite sans toucher à la box. |
Les questions qui reviennent
Quand on parle de configuration du DNS over TLS, on oublie souvent que les problèmes viennent rarement du protocole lui-même, mais de la synchronisation entre plusieurs machines. Un utilisateur expliquait qu’il ne cherchait plus à reproduire manuellement ses réglages sur chaque poste : il préférait extraire la liste des paquets installés (via un simple dpkg --get-selections sous APT, avec un équivalent dans l’univers RPM) et la réinjecter ailleurs. Pour la configuration elle-même, copier le dossier personnel ou les fichiers de dotfiles suffisait. Sa remarque vaut aussi pour vos résolveurs DoT : vous gagnez du temps en traitant la config comme un fichier à versionner, pas comme un réglage à refaire à la main.
Ce même utilisateur pointait une limite qu’on rencontre aussi avec le DoT : tester dix distributions ou dix résolveurs, ce n’est pas sa définition de « ça marche du premier coup ». Et il ajoutait une vérité d’expérience : ce qui fonctionnait il y a un an ne fonctionne pas forcément deux versions plus tard. Ne considérez jamais votre configuration DoT comme figée. Un résolveur qui répond parfaitement aujourd’hui peut changer de politique de journalisation, de filtrage ou de routage demain. Vous devez prévoir de revérifier, pas d’installer une fois pour toutes.
Sur un parc de cent postes, ce même retour d’expérience change complètement d’échelle. L’auteur trouvait étrange de configurer cent ordinateurs individuellement : il évoquait des outils de gestion de configuration (Puppet, Chef) ou des montages réseau (NFS) selon le contexte. Transposé au DoT, le principe est identique : déployer une résolution DNS chiffrée sur un parc ne se fait pas machine par machine. Vous centralisez la configuration, vous la distribuez, et vous gardez la main pour la modifier. Sinon, vous passez vos nuits à répéter les mêmes clics sur cent écrans.
Enfin, un autre participant décrivait un outil de recherche structurée qui annotait les usages d’un identifiant, citait les plages de numéros de lignes et affichait la définition directement si elle était courte. L’intérêt n’était pas la précision d’un serveur de langage complet, mais la simplicité : pas de démon, lisible par un humain, sans configuration dans la plupart des cas. C’est exactement l’état d’esprit qu’on devrait avoir face à une panne de DoT : avant de lancer un diagnostic lourd, commencez par un outil simple qui vous montre où le blocage se produit. La réponse est souvent plus proche qu’on ne le croit.
Mon avis
Regard OPJ · numéro du 15 octobre 2026
Ce que j'ai décortiqué il y a deux semaines
Des années de réquisitions. Deux faits, deux remèdes. Les abonnés les ont déjà lus. Vous, pas encore.
iOS 27 neutralise votre bloqueur de pubs DNS sans vous demander votre avis
La mise à jour iOS 27 embarque un réglage appelé Connectivity Assist. Activé par défaut, il contourne les bloqueurs de publicité basés sur le DNS comme NextDNS, AdGuard ou Pi-hole.
Ce que je fais : Je désactive Connectivity Assist sur tous mes appareils iOS dès la mise à jour installée. Ensuite, je vérifie que mon bloqueur DNS fonctionne encore.
Amazon équipe ses livreurs de lunettes qui photographient tout
Amazon a construit des lunettes connectées avec caméras intégrées pour ses livreurs. Elles prennent des photos de tout ce que le livreur voit, y compris les personnes et les propriétés.
Ce que je fais : Je n'achète plus rien sur Amazon quand je peux l'éviter. Et si un livreur arrive avec ces lunettes, je lui demande de les retirer avant d'ouvrir.
La lettre complète en contient trois, avec mon regard d'ancien OPJ et le détail de chaque remède. Inscrivez-vous, et recevez tout de suite le PDF de cet article.
En cliquant, vous recevez le PDF et vous inscrivez à la newsletter. Gratuit, sans pub, désabonnement en un clic.
Ou passez directement à la version complète :
Sans engagement, résiliable en un clic.
Le DoT répond à une vraie faille, mais il souffre d’un déficit de pédagogie. Les documentations techniques expliquent le protocole, rarement les pièges de déploiement. Résultat : beaucoup d’utilisateurs activent le DoT, constatent un problème, et reviennent au DNS par frustration.
À leur place, j’aurais fait pareil.
Ce n’est pas une fatalité. Une configuration correcte prend 10 minutes si vous savez où regarder. Le port 853, le choix du résolveur et la validation du certificat : ces 3 points couvrent l’essentiel des échecs.
Le reste, c’est de la littérature technique. Et qui a envie de lire de la littérature technique un mardi soir ?
Puis-je utiliser le DoT sur un réseau d’entreprise ?
Oui, et c’est même le contexte où il est le plus pertinent. Le port dédié 853 permet aux administrateurs de surveiller et de filtrer le trafic DNS chiffré, ce que le DoH rend beaucoup plus difficile. Prévoyez simplement des règles de pare-feu claires pour autoriser le port 853 vers les résolveurs de confiance.
Les documents que j'ai ouverts
| RFC 7858: Specification for DNS over Transport Layer Security (TLS) ↗ |
| RFC 7858, Specification for DNS over Transport Layer Security (TLS) ↗ |
Le DoT vu par un ancien OPJ, ce que le chiffrement change pour l’enquête
Quand j’étais en brigade, une réquisition au FAI prenait 24 heures pour obtenir un nom et une adresse. C’était la base de l’enquête numérique : on savait où vous alliez, et on savait qui vous étiez.
Le DNS, c’était la première porte qu’on ouvrait. Votre box interrogeait le résolveur de votre opérateur et ce résolveur notait tout. Chaque nom de domaine résolu, chaque site visité, horodaté et stocké.
Sur une réquisition DNS, je regardais toujours l’heure de la première résolution. C’est elle qui trahit le moment exact où la personne s’est connectée.
Article utile ? Dites-le à Google. Ajoutez ce blog à vos sources préférées : un clic, et vous le retrouverez dans vos recherches (et l’AI Mode) au lieu du contenu recyclé par des robots. C’est votre façon de reprendre le contrôle sur ce que vous lisez.
Et si vous avez aimé, partagez (c’est le meilleur coup de pouce pour un blog indépendant qui publie sans algorithme ni sponsor déguisé).
Un clic, gratuit. Nécessite d’être connecté à votre compte Google.
Encore un article sur DoT... Et toujours pas un mot sur ceux qui bloquent le port 853 en entreprise. Franchement, ça sert à quoi de pondre un topo si c'est pour ignorer le vrai problème ?