{"id":294,"date":"2026-06-20T08:00:00","date_gmt":"2026-06-20T08:00:00","guid":{"rendered":"https:\/\/shattered.io\/fr\/2026\/06\/20\/dns-over-https-doh\/"},"modified":"2026-06-20T08:00:00","modified_gmt":"2026-06-20T08:00:00","slug":"dns-over-https-doh","status":"publish","type":"post","link":"https:\/\/shattered.io\/fr\/2026\/06\/20\/dns-over-https-doh\/","title":{"rendered":"DNS over HTTPS (DoH) : 12 \u00c9tapes, 30 Min [2026]"},"content":{"rendered":"\n

Chaque fois que vous tapez une adresse dans votre navigateur, votre appareil envoie une requ\u00eate DNS en clair, lisible par votre fournisseur d’acc\u00e8s \u00e0 Internet, par les administrateurs r\u00e9seau, et par quiconque intercepte votre trafic sur le chemin. Le protocole DNS traditionnel fonctionne sur le port 53, sans chiffrement, depuis 1983. DNS over HTTPS (DoH)<\/strong> r\u00e9sout ce probl\u00e8me en encapsulant les requ\u00eates DNS dans du trafic HTTPS chiffr\u00e9 sur le port 443, les rendant indiscernables du reste de votre navigation web.<\/p>\n\n\n\n

Ce tutoriel vous guide \u00e0 travers 12 \u00e9tapes concr\u00e8tes pour activer et configurer DNS over HTTPS sur tous vos appareils (navigateurs, Windows, macOS, Linux) et vous montre comment impl\u00e9menter un client DoH en Node.js 18+. Temps estim\u00e9 : 30 minutes pour la configuration compl\u00e8te.<\/p>\n\n\n\n

Qu’est-ce que DNS over HTTPS et pourquoi c’est important<\/h2>\n\n\n\n

Le syst\u00e8me DNS (Domain Name System) traduit les noms de domaine comme shattered.io<\/code> en adresses IP comme 104.21.17.6<\/code>. Sans chiffrement, cette traduction se fait en clair sur le port UDP\/TCP 53. Concr\u00e8tement, votre FAI voit chaque site que vous visitez, m\u00eame si la connexion au site lui-m\u00eame est chiffr\u00e9e en HTTPS. C’est une fuite de confidentialit\u00e9 structurelle, exploit\u00e9e massivement pour la publicit\u00e9 cibl\u00e9e, le blocage de sites, et la surveillance.<\/p>\n\n\n\n

La RFC 8484<\/a>, publi\u00e9e par l’IETF en octobre 2018, standardise DNS over HTTPS. Le principe : les requ\u00eates DNS sont encod\u00e9es selon le format DNS wire format ou JSON, puis transmises via une requ\u00eate HTTPS vers un r\u00e9solveur compatible DoH. Pour un observateur externe, ces requ\u00eates ressemblent exactement \u00e0 du trafic HTTPS normal. Le protocole concurrent, DNS over TLS (DoT, RFC 7858), offre un chiffrement similaire mais utilise le port 853, plus facilement identifiable et bloquable.<\/p>\n\n\n\n

En 2026, la part de march\u00e9 de DoH d\u00e9passe 40% des requ\u00eates DNS mondiales selon les donn\u00e9es de Cloudflare<\/a>. Firefox l’active par d\u00e9faut en France depuis la version 91 pour les utilisateurs qui n’ont pas configur\u00e9 leur propre r\u00e9solveur DNS. Chrome 83 a introduit le “Secure DNS” avec bascule automatique vers DoH si le r\u00e9solveur configur\u00e9 supporte le protocole. La question n’est donc plus de savoir si DoH est pertinent, mais comment le configurer correctement pour maximiser la confidentialit\u00e9 sans casser sa connectivit\u00e9.<\/p>\n\n\n\n

Avantages et limites de DNS over HTTPS<\/h2>\n\n\n\n

DoH apporte 4 b\u00e9n\u00e9fices mesurables. Premi\u00e8rement, la confidentialit\u00e9 vis-\u00e0-vis du FAI : votre op\u00e9rateur ne peut plus enregistrer les domaines que vous consultez. Deuxi\u00e8mement, la r\u00e9sistance \u00e0 la manipulation DNS : les attaques de type DNS hijacking, qui redirigent silencieusement votre trafic vers des serveurs malveillants, deviennent impossibles \u00e0 r\u00e9aliser sur le trajet entre votre appareil et le r\u00e9solveur DoH. Troisi\u00e8mement, la protection contre la censure DNS : les blocages au niveau DNS impos\u00e9s par les FAI (comme les blocages de sites de streaming ou de jeux en ligne en France) sont contourn\u00e9s. Quatri\u00e8mement, DoH est r\u00e9sistant aux attaques de type MITM sur les requ\u00eates DNS, contrairement au DNS classique.<\/p>\n\n\n\n

Les limites sont r\u00e9elles et m\u00e9ritent d’\u00eatre comprises. DoH ne chiffre pas votre trafic IP, il chiffre uniquement la r\u00e9solution de nom. Votre IP source reste visible. Les informations SNI (Server Name Indication) dans les handshakes TLS r\u00e9v\u00e8lent encore le domaine cible \u00e0 un observateur r\u00e9seau, bien que eSNI\/ECH (Encrypted Client Hello) commence \u00e0 combler cette lacune. Par ailleurs, DoH d\u00e9place la confiance de votre FAI vers votre fournisseur DoH (Cloudflare, Google, NextDNS). Ce n’est pas une anonymisation mais un changement d’interlocuteur. Enfin, DoH peut interf\u00e9rer avec des configurations r\u00e9seau d’entreprise, les portails captifs Wi-Fi, et les r\u00e9solveurs DNS internes des r\u00e9seaux priv\u00e9s.<\/p>\n\n\n\n

Comparaison des fournisseurs DNS over HTTPS<\/h2>\n\n\n\n

Le choix du fournisseur DoH est la d\u00e9cision la plus importante de cette configuration. Les crit\u00e8res cl\u00e9s sont la politique de logs, la vitesse de r\u00e9solution, le filtrage de contenu malveillant, et la localisation des serveurs.<\/p>\n\n\n\n

Fournisseur<\/th>URL DoH<\/th>IP primaire<\/th>Latence (France)<\/th>Logs<\/th>Filtrage malware<\/th><\/tr><\/thead>
Cloudflare 1.1.1.1<\/strong><\/td>https:\/\/cloudflare-dns.com\/dns-query<\/td>1.1.1.1<\/td>~3 ms<\/td>Aucun (audit\u00e9 KPMG)<\/td>Non (standard)<\/td><\/tr>
Cloudflare 1.1.1.2<\/strong><\/td>https:\/\/security.cloudflare-dns.com\/dns-query<\/td>1.1.1.2<\/td>~3 ms<\/td>Aucun (audit\u00e9 KPMG)<\/td>Oui (malware)<\/td><\/tr>
Google Public DNS<\/strong><\/td>https:\/\/dns.google\/dns-query<\/td>8.8.8.8<\/td>~8 ms<\/td>25 h (anonymis\u00e9s)<\/td>Non<\/td><\/tr>
Quad9<\/strong><\/td>https:\/\/dns.quad9.net\/dns-query<\/td>9.9.9.9<\/td>~12 ms<\/td>Aucun<\/td>Oui (malware + phishing)<\/td><\/tr>
AdGuard DNS<\/strong><\/td>https:\/\/dns.adguard.com\/dns-query<\/td>94.140.14.14<\/td>~15 ms<\/td>Aucun<\/td>Oui (malware + publicit\u00e9s)<\/td><\/tr>
NextDNS<\/strong><\/td>https:\/\/dns.nextdns.io\/{profil}<\/td>Variable<\/td>~5 ms<\/td>Optionnel<\/td>Personnalisable<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Pour la France, Cloudflare 1.1.1.1 offre la latence la plus faible (3 ms en moyenne) et publie un audit annuel de sa politique de non-conservation des logs, r\u00e9alis\u00e9 par KPMG. Quad9<\/a>, bas\u00e9 en Suisse sous le droit helv\u00e9tique, est le choix privil\u00e9gi\u00e9 pour ceux qui veulent \u00e9viter les serveurs am\u00e9ricains tout en b\u00e9n\u00e9ficiant d’un filtrage de malware actif. NextDNS<\/a>, avec sa console de configuration d\u00e9taill\u00e9e, s’adresse aux administrateurs qui veulent contr\u00f4ler finement le filtrage.<\/p>\n\n\n\n

Pr\u00e9requis<\/h2>\n\n\n\n

Pour suivre ce tutoriel dans son int\u00e9gralit\u00e9, vous avez besoin de :<\/p>\n\n\n\n

  • Navigateur :<\/strong> Firefox 122+, Chrome 120+, Edge 120+, Brave 1.62+ ou Safari 17+ (macOS)<\/li>
  • Syst\u00e8me d’exploitation :<\/strong> Windows 11 22H2+, macOS Ventura 13+, ou Ubuntu 22.04 LTS \/ Debian 12+<\/li>
  • Node.js 18.x ou 20.x LTS<\/strong> (pour la section impl\u00e9mentation DoH)<\/li>
  • curl 7.76+<\/strong> (pour les tests en ligne de commande)<\/li>
  • Droits administrateur<\/strong> sur le syst\u00e8me pour les configurations au niveau OS<\/li>
  • Acc\u00e8s Internet<\/strong> sur le port 443 (HTTPS) sans inspection TLS profonde de l’entreprise<\/li><\/ul>\n\n\n\n

    \u00c9tape 1 : Activer DNS over HTTPS dans Firefox<\/h2>\n\n\n\n

    Firefox est le navigateur le plus avanc\u00e9 dans l’impl\u00e9mentation de DoH. Il propose trois modes : d\u00e9sactiv\u00e9, activ\u00e9 avec repli (utilise DoH si disponible, sinon DNS classique), et activ\u00e9 sans repli (bloque la r\u00e9solution si DoH \u00e9choue). Pour la confidentialit\u00e9 maximale, utilisez le mode sans repli, mais sachez qu’il peut bloquer l’acc\u00e8s sur les r\u00e9seaux avec portails captifs.<\/p>\n\n\n\n

    Ouvrez Firefox et acc\u00e9dez \u00e0 about:preferences#privacy<\/code>. Faites d\u00e9filer jusqu’\u00e0 la section “S\u00e9curit\u00e9 DNS”. Cochez “Activer le DNS s\u00e9curis\u00e9” et s\u00e9lectionnez le niveau de protection souhait\u00e9. Dans la liste d\u00e9roulante “Utiliser le fournisseur”, choisissez l’un des fournisseurs pr\u00e9configur\u00e9s ou s\u00e9lectionnez “Personnalis\u00e9” pour entrer l’URL de votre fournisseur pr\u00e9f\u00e9r\u00e9. Pour Cloudflare : entrez https:\/\/cloudflare-dns.com\/dns-query<\/code>. Pour Quad9 : https:\/\/dns.quad9.net\/dns-query<\/code>.<\/p>\n\n\n\n

    Pour les utilisateurs qui pr\u00e9f\u00e8rent la configuration via l’interface about:config<\/code>, trois pr\u00e9f\u00e9rences contr\u00f4lent le comportement DoH :<\/p>\n\n\n\n

    \/\/ about:config dans Firefox\n\/\/ Activer DoH en mode strict (sans repli DNS classique)\n\/\/ network.trr.mode valeurs : 0=d\u00e9sactiv\u00e9, 2=avec repli, 3=strict, 5=d\u00e9sactiv\u00e9 entreprise\nnetwork.trr.mode = 3\n\n\/\/ D\u00e9finir l'URL du r\u00e9solveur DoH\nnetwork.trr.uri = \"https:\/\/cloudflare-dns.com\/dns-query\"\n\n\/\/ Forcer la r\u00e9solution de l'URI DoH via l'IP directe (\u00e9vite le probl\u00e8me bootstrap)\n\/\/ Le probl\u00e8me bootstrap : comment r\u00e9soudre le nom du r\u00e9solveur DoH sans DNS classique ?\nnetwork.trr.bootstrapAddress = \"1.1.1.1\"<\/code><\/pre>\n\n\n\n
    Le mode 3 est recommand\u00e9 pour la confidentialit\u00e9 maximale. Firefox affiche une ic\u00f4ne de bouclier dans la barre d’adresse quand DoH est actif pour la page courante. V\u00e9rifiez que l’ic\u00f4ne est pr\u00e9sente apr\u00e8s avoir sauvegard\u00e9 les param\u00e8tres.<\/p>\n\n\n\n
    \u00c9tape 2 : Configurer DoH dans Chrome et Chromium<\/h2>\n\n\n\n
    Google Chrome impl\u00e9mente DoH sous le nom “Secure DNS”. Par d\u00e9faut, Chrome bascule automatiquement vers DoH si le r\u00e9solveur DNS actuellement configur\u00e9 (via DHCP ou OS) supporte le protocole. Cette approche dite “upgrade” est plus conservatrice que Firefox mais plus transparente pour l’utilisateur final.<\/p>\n\n\n\n
    Pour configurer Chrome, naviguez vers chrome:\/\/settings\/security<\/code>. Dans la section “Utilisation d’un DNS s\u00e9curis\u00e9”, cochez “Avec” et s\u00e9lectionnez un fournisseur dans la liste, ou entrez une URL personnalis\u00e9e. Pour une configuration via les politiques d’entreprise (d\u00e9ploiement sur plusieurs postes), Chrome accepte les param\u00e8tres via les GPO Windows ou via un fichier de politique JSON sur macOS\/Linux :<\/p>\n\n\n\n
    # Configuration Chrome via politique JSON (Linux\/macOS)\n# Fichier : \/etc\/chromium\/policies\/managed\/dns_over_https.json\n{\n  \"DnsOverHttpsMode\": \"secure\",\n  \"DnsOverHttpsTemplates\": \"https:\/\/cloudflare-dns.com\/dns-query\"\n}\n\n# Sur Windows, via PowerShell (cr\u00e9e la cl\u00e9 de registre GPO)\n# HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Google\\Chrome\nSet-ItemProperty -Path \"HKLM:\\SOFTWARE\\Policies\\Google\\Chrome\" `\n  -Name \"DnsOverHttpsMode\" -Value \"secure\" -Type String\nSet-ItemProperty -Path \"HKLM:\\SOFTWARE\\Policies\\Google\\Chrome\" `\n  -Name \"DnsOverHttpsTemplates\" -Value \"https:\/\/cloudflare-dns.com\/dns-query\" -Type String<\/code><\/pre>\n\n\n\n
    La valeur “secure” pour DnsOverHttpsMode<\/code> impose DoH strict. La valeur “automatic” permet le repli vers DNS classique. Cette configuration s’applique identiquement \u00e0 Chromium, Brave (avec les politiques Chromium), et Edge en mode g\u00e9r\u00e9.<\/p>\n\n\n\n
    \u00c9tape 3 : Activer DoH dans Edge et Brave<\/h2>\n\n\n\n
    Microsoft Edge expose le param\u00e8tre DoH via edge:\/\/settings\/privacy<\/code>, dans la section “S\u00e9curit\u00e9”. Edge ajoute une option pour utiliser le r\u00e9solveur DoH de Microsoft en dehors de l’Union Europ\u00e9enne, et https:\/\/dns.quad9.net\/dns-query<\/code> pour les utilisateurs en Europe, conform\u00e9ment aux exigences de localisation des donn\u00e9es RGPD.<\/p>\n\n\n\n
    Brave impl\u00e9mente DoH nativement et propose son propre r\u00e9solveur via son partenariat avec Quad9. La configuration s’effectue dans brave:\/\/settings\/security<\/code>, section “Utiliser un DNS s\u00e9curis\u00e9”. Brave a la particularit\u00e9 de d\u00e9sactiver automatiquement DoH quand Tor est actif dans les onglets Brave Private Windows, pour \u00e9viter les fuites de r\u00e9solution DNS qui trahiraient l’identit\u00e9 de l’utilisateur. C’est un comportement par d\u00e9faut qui prot\u00e8ge les utilisateurs avanc\u00e9s d’une erreur courante.<\/p>\n\n\n\n
    \u00c9tape 4 : Configurer DoH au niveau syst\u00e8me sous Windows 11<\/h2>\n\n\n\n
    La configuration DoH au niveau navigateur ne chiffre les requ\u00eates DNS que pour ce navigateur sp\u00e9cifique. Les applications syst\u00e8me, les jeux, les clients email, et tous les autres logiciels continuent d’utiliser le DNS classique. Pour une protection compl\u00e8te, il faut configurer DoH au niveau du syst\u00e8me d’exploitation.<\/p>\n\n\n\n
    Windows 11 22H2 int\u00e8gre DoH nativement dans le stack r\u00e9seau. Pour l’activer : ouvrez Param\u00e8tres, allez dans R\u00e9seau et Internet, puis s\u00e9lectionnez votre connexion r\u00e9seau (WiFi ou Ethernet). Cliquez sur “Modifier l’attribution du serveur DNS”. Passez de “Automatique (DHCP)” \u00e0 “Manuel”. Activez IPv4, entrez 1.1.1.1<\/code> comme DNS pr\u00e9f\u00e9r\u00e9, et dans la liste d\u00e9roulante “Chiffrement DNS”, s\u00e9lectionnez “Chiffr\u00e9 uniquement (DNS sur HTTPS)”.<\/p>\n\n\n\n
    Pour les utilisateurs avanc\u00e9s et le d\u00e9ploiement automatis\u00e9, la m\u00eame configuration via PowerShell (administrateur) :<\/p>\n\n\n\n
    # PowerShell (administrateur) - Configurer DoH sur Windows 11\n# \u00c9tape 1 : Lister les interfaces r\u00e9seau disponibles\nGet-DnsClientServerAddress\n\n# \u00c9tape 2 : Configurer les serveurs DNS (adapter \"Wi-Fi\" selon votre interface)\nSet-DnsClientServerAddress -InterfaceAlias \"Wi-Fi\" -ServerAddresses \"1.1.1.1\",\"1.0.0.1\"\n\n# \u00c9tape 3 : Enregistrer les templates DoH pour chaque serveur\nAdd-DnsClientDohServerAddress -ServerAddress \"1.1.1.1\" `\n    -DohTemplate \"https:\/\/cloudflare-dns.com\/dns-query\" `\n    -AllowFallbackToUdp $false `\n    -AutoUpgrade $true\n\nAdd-DnsClientDohServerAddress -ServerAddress \"1.0.0.1\" `\n    -DohTemplate \"https:\/\/cloudflare-dns.com\/dns-query\" `\n    -AllowFallbackToUdp $false `\n    -AutoUpgrade $true\n\n# \u00c9tape 4 : V\u00e9rifier la configuration\nGet-DnsClientDohServerAddress\n\n# Sortie attendue :\n# ServerAddress DohTemplate                              AllowFallbackToUdp AutoUpgrade\n# ------------- -----------                              ------------------ -----------\n# 1.1.1.1       https:\/\/cloudflare-dns.com\/dns-query    False              True\n# 1.0.0.1       https:\/\/cloudflare-dns.com\/dns-query    False              True<\/code><\/pre>\n\n\n\n
    Le param\u00e8tre AllowFallbackToUdp $false<\/code> impose DoH strict. AutoUpgrade $true<\/code> active la mise \u00e0 niveau automatique depuis DNS classique vers DoH pour les serveurs qui supportent les deux protocoles.<\/p>\n\n\n\n
    \u00c9tape 5 : Activer DoH sous macOS avec cloudflared<\/h2>\n\n\n\n
    macOS Ventura (13) et Sonoma (14) supportent DoH via des profils de configuration r\u00e9seau (format .mobileconfig), installables via l’application Configuration Apple ou MDM. Pour les utilisateurs avanc\u00e9s, l’approche la plus flexible est d’utiliser cloudflared<\/code>, le daemon officiel de Cloudflare, comme proxy DoH local.<\/p>\n\n\n\n
    # Installation de cloudflared sur macOS via Homebrew\nbrew install cloudflared\n\n# D\u00e9marrer cloudflared comme proxy DoH local sur le port 5053\n# (Port 53 n\u00e9cessite les droits root, 5053 fonctionne sans sudo)\ncloudflared proxy-dns --port 5053 --upstream \"https:\/\/cloudflare-dns.com\/dns-query\"\n\n# Pour l'activer en service syst\u00e8me (d\u00e9marre automatiquement au boot)\nsudo cloudflared service install --legacy\n\n# V\u00e9rifier que cloudflared \u00e9coute\nsudo lsof -i :5053\n\n# Tester la r\u00e9solution DNS via le proxy local\ndig @127.0.0.1 -p 5053 cloudflare.com A<\/code><\/pre>\n\n\n\n
    Une fois cloudflared<\/code> en cours d’ex\u00e9cution sur 127.0.0.1:5053<\/code>, configurez macOS pour utiliser 127.0.0.1<\/code> comme serveur DNS : Pr\u00e9f\u00e9rences Syst\u00e8me, R\u00e9seau, s\u00e9lectionnez votre interface, puis dans “Avanc\u00e9” et “DNS”, ajoutez 127.0.0.1<\/code> en premier serveur DNS et supprimez les autres. Toutes les applications du syst\u00e8me enverront leurs requ\u00eates DNS vers cloudflared<\/code>, qui les transmettra chiffr\u00e9es via DoH vers Cloudflare.<\/p>\n\n\n\n
    \u00c9tape 6 : Configurer DoH sous Linux avec dnscrypt-proxy<\/h2>\n\n\n\n
    Sur Linux, dnscrypt-proxy<\/code> est l’outil de r\u00e9f\u00e9rence pour activer DoH au niveau syst\u00e8me. Il supporte aussi bien DoH que DNSCrypt, g\u00e8re la rotation entre plusieurs fournisseurs, et propose un filtrage de contenu via des listes de blocage. Contrairement \u00e0 systemd-resolved<\/code> qui supporte DNS over TLS (DoT) via DNSOverTLS=yes<\/code> mais pas DoH nativement dans la plupart des distributions en 2026, dnscrypt-proxy g\u00e8re les deux protocoles.<\/p>\n\n\n\n
    # Installation de dnscrypt-proxy sur Ubuntu 22.04 \/ Debian 12\nsudo apt update && sudo apt install -y dnscrypt-proxy\n\n# V\u00e9rifier les conflits : systemd-resolved peut \u00e9couter sur le port 53\nsudo ss -tulnp | grep ':53'\n\n# Si systemd-resolved occupe le port 53, d\u00e9sactiver son stub resolver\nsudo sed -i 's\/#DNSStubListener=yes\/DNSStubListener=no\/' \/etc\/systemd\/resolved.conf\nsudo systemctl restart systemd-resolved\n\n# V\u00e9rifier que le port 53 est libre\nsudo ss -tulnp | grep ':53'\n\n# Cr\u00e9er le r\u00e9pertoire de cache pour dnscrypt-proxy\nsudo mkdir -p \/var\/cache\/dnscrypt-proxy\n\n# D\u00e9marrer et activer le service\nsudo systemctl enable --now dnscrypt-proxy\nsudo systemctl status dnscrypt-proxy<\/code><\/pre>\n\n\n\n
    Modifiez ensuite le fichier de configuration principal pour activer DoH avec les fournisseurs souhait\u00e9s. Le fichier se trouve dans \/etc\/dnscrypt-proxy\/dnscrypt-proxy.toml<\/code> :<\/p>\n\n\n\n
    # \/etc\/dnscrypt-proxy\/dnscrypt-proxy.toml (extraits cl\u00e9s \u00e0 modifier)\n\n# \u00c9couter sur localhost, port 53\nlisten_addresses = ['127.0.0.1:53', '[::1]:53']\n\n# Utiliser des serveurs sp\u00e9cifiques (DoH uniquement)\nserver_names = ['cloudflare', 'quad9-dnscrypt-ip4-filter-pri']\n\n# Exiger l'absence de logs c\u00f4t\u00e9 serveur\nrequire_nolog = true\n\n# Activer DNSSEC\nrequire_dnssec = true\n\n# Activer uniquement les serveurs DoH (et pas DNSCrypt)\n# Mettre \u00e0 true pour DoH uniquement\ndoh_servers = true\ndnscrypt_servers = false\n\n# Sources de liste de serveurs\n[sources]\n  [sources.'public-resolvers']\n  urls = ['https:\/\/raw.githubusercontent.com\/DNSCrypt\/dnscrypt-resolvers\/master\/v3\/public-resolvers.md']\n  cache_file = '\/var\/cache\/dnscrypt-proxy\/public-resolvers.md'\n  minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'\n  refresh_delay = 72\n\n# Configurer \/etc\/resolv.conf pour pointer vers dnscrypt-proxy\n# echo \"nameserver 127.0.0.1\" | sudo tee \/etc\/resolv.conf<\/code><\/pre>\n\n\n\n
    \u00c9tape 7 : V\u00e9rifier que DoH fonctionne correctement<\/h2>\n\n\n\n
    La v\u00e9rification est une \u00e9tape critique. Beaucoup d’utilisateurs pensent avoir activ\u00e9 DoH alors que le navigateur ou l’OS utilise encore le DNS classique comme repli. Plusieurs m\u00e9thodes permettent de confirmer que les requ\u00eates DNS passent bien par DoH.<\/p>\n\n\n\n
    Test 1 :<\/strong> v\u00e9rification via la page de diagnostic Cloudflare. Naviguez vers https:\/\/1.1.1.1\/help<\/code>. La page affiche si votre connexion utilise DoH (DNS over HTTPS: Yes<\/code>) et si DNSSEC est activ\u00e9. Cloudflare affiche aussi l’adresse IP du r\u00e9solveur qui a trait\u00e9 votre requ\u00eate, permettant de confirmer que c’est bien leurs serveurs et non ceux de votre FAI.<\/p>\n\n\n\n
    Test 2 :<\/strong> requ\u00eate DoH directe via curl pour tester l’API JSON de Cloudflare :<\/p>\n\n\n\n
    # Tester l'API DoH de Cloudflare directement (format JSON)\ncurl -s -H \"Accept: application\/dns-json\" \\\n  \"https:\/\/cloudflare-dns.com\/dns-query?name=example.com&type=A\" | python3 -m json.tool\n\n# Sortie attendue :\n# {\n#   \"Status\": 0,          <-- 0 = NOERROR (succ\u00e8s)\n#   \"TC\": false,\n#   \"RD\": true,\n#   \"RA\": true,\n#   \"AD\": true,           <-- Authentic Data = DNSSEC valid\u00e9\n#   \"CD\": false,\n#   \"Question\": [{\"name\": \"example.com.\", \"type\": 1}],\n#   \"Answer\": [\n#     {\n#       \"name\": \"example.com.\",\n#       \"type\": 1,        <-- Type A (IPv4)\n#       \"TTL\": 86400,\n#       \"data\": \"93.184.216.34\"\n#     }\n#   ]\n# }\n\n# Tester avec Quad9 pour comparaison\ncurl -s -H \"Accept: application\/dns-json\" \\\n  \"https:\/\/dns.quad9.net\/dns-query?name=shattered.io&type=A\" | python3 -m json.tool\n\n# V\u00e9rifier l'absence de trafic DNS classique (port 53) pendant la navigation\n# Lancez cette commande, naviguez 30 secondes, puis arr\u00eatez avec Ctrl+C\n# Aucune ligne = toutes les requ\u00eates passent par DoH\nsudo tcpdump -i any -n 'port 53 and not host 127.0.0.1' 2>\/dev\/null<\/code><\/pre>\n\n\n\n
    Le champ \"Status\": 0<\/code> indique une r\u00e9solution r\u00e9ussie (NOERROR). \"AD\": true<\/code> confirme que DNSSEC a valid\u00e9 la r\u00e9ponse. Si la commande tcpdump<\/code> ne produit aucune sortie pendant la navigation, toutes les requ\u00eates passent bien par DoH sur le port 443 et non en clair sur le port 53.<\/p>\n\n\n\n
    \u00c9tape 8 : Impl\u00e9menter un client DNS over HTTPS en Node.js<\/h2>\n\n\n\n
    Node.js 18 et sup\u00e9rieur int\u00e8gre l’API fetch<\/code> nativement, ce qui simplifie l’impl\u00e9mentation d’un client DoH sans d\u00e9pendances externes. L’API JSON de Cloudflare (format application\/dns-json<\/code>) est plus accessible que le format binaire DNS wire (format application\/dns-message<\/code>) d\u00e9fini dans la RFC 8484. Voici un client DoH complet qui interroge plusieurs types de records DNS :<\/p>\n\n\n\n
    \/\/ doh-client.js - Client DNS over HTTPS pour Node.js 18+\n\/\/ Usage : node doh-client.js\n\nconst DOH_PROVIDERS = {\n  cloudflare: 'https:\/\/cloudflare-dns.com\/dns-query',\n  google:     'https:\/\/dns.google\/dns-query',\n  quad9:      'https:\/\/dns.quad9.net\/dns-query',\n};\n\n\/**\n * R\u00e9sout un nom de domaine via DNS over HTTPS\n * @param {string} hostname - Nom de domaine \u00e0 r\u00e9soudre\n * @param {string} type - Type de record ('A', 'AAAA', 'MX', 'TXT', 'CNAME', 'NS')\n * @param {string} provider - Fournisseur ('cloudflare', 'google', 'quad9')\n * @returns {Promise<Array>} Tableau de records DNS\n *\/\nasync function resolveDoH(hostname, type = 'A', provider = 'cloudflare') {\n  const baseUrl = DOH_PROVIDERS[provider];\n  if (!baseUrl) throw new Error(`Fournisseur DoH inconnu : ${provider}`);\n\n  const url = new URL(baseUrl);\n  url.searchParams.set('name', hostname);\n  url.searchParams.set('type', type);\n\n  const response = await fetch(url.toString(), {\n    headers: { 'Accept': 'application\/dns-json' },\n    signal: AbortSignal.timeout(5000), \/\/ Timeout 5 secondes\n  });\n\n  if (!response.ok) {\n    throw new Error(`Erreur HTTP DoH ${response.status} : ${response.statusText}`);\n  }\n\n  const data = await response.json();\n\n  \/\/ Codes d'erreur DNS : 0=NOERROR, 1=FORMERR, 2=SERVFAIL, 3=NXDOMAIN, 5=REFUSED\n  if (data.Status !== 0) {\n    const errors = { 1: 'FORMERR', 2: 'SERVFAIL', 3: 'NXDOMAIN', 5: 'REFUSED' };\n    throw new Error(`Erreur DNS ${data.Status} : ${errors[data.Status] || 'UNKNOWN'}`);\n  }\n\n  return { records: data.Answer || [], dnssecValid: data.AD === true };\n}\n\nasync function main() {\n  try {\n    \/\/ Records A via Cloudflare\n    const { records: aRecords, dnssecValid } = await resolveDoH('cloudflare.com', 'A');\n    console.log('Records A de cloudflare.com (via Cloudflare DoH) :');\n    aRecords.forEach(r => console.log(`  ${r.data} (TTL: ${r.TTL}s)`));\n    console.log(`DNSSEC valid\u00e9 : ${dnssecValid ? 'OUI' : 'NON'}`);\n\n    \/\/ Records MX via Quad9\n    const { records: mxRecords } = await resolveDoH('google.com', 'MX', 'quad9');\n    console.log('\\nRecords MX de google.com (via Quad9 DoH) :');\n    mxRecords.forEach(r => console.log(`  ${r.data} (TTL: ${r.TTL}s)`));\n\n    \/\/ Test NXDOMAIN (domaine inexistant)\n    try {\n      await resolveDoH('ce-domaine-nexiste-pas-12345.fr', 'A');\n    } catch (err) {\n      console.log(`\\nTest NXDOMAIN : ${err.message}`); \/\/ Attendu : Erreur DNS 3 : NXDOMAIN\n    }\n  } catch (error) {\n    console.error('Erreur :', error.message);\n    process.exit(1);\n  }\n}\n\nmain();<\/code><\/pre>\n\n\n\n
    Ex\u00e9cutez avec node doh-client.js<\/code>. La sortie attendue :<\/p>\n\n\n\n
    Records A de cloudflare.com (via Cloudflare DoH) :\n  104.16.132.229 (TTL: 300s)\n  104.16.133.229 (TTL: 300s)\nDNSSEC valid\u00e9 : OUI\n\nRecords MX de google.com (via Quad9 DoH) :\n  10 smtp.google.com. (TTL: 3600s)\n\nTest NXDOMAIN : Erreur DNS 3 : NXDOMAIN<\/code><\/pre>\n\n\n\n
    Mesure de performance : DoH vs DNS classique en Node.js<\/h3>\n\n\n\n
    Un benchmark simple compare la latence de r\u00e9solution DoH versus DNS classique. La premi\u00e8re r\u00e9solution DoH est plus lente (handshake TLS inclus). Les r\u00e9solutions suivantes b\u00e9n\u00e9ficient de la r\u00e9utilisation de connexion HTTP\/2 et du cache DNS c\u00f4t\u00e9 r\u00e9solveur :<\/p>\n\n\n\n
    \/\/ benchmark-doh.js - Comparer DoH vs DNS classique en Node.js 18+\nconst dns = require('dns').promises;\n\nasync function benchmark(hostname, iterations = 5) {\n  \/\/ DNS classique via le r\u00e9solveur syst\u00e8me\n  const classicTimes = [];\n  for (let i = 0; i < iterations; i++) {\n    const start = performance.now();\n    await dns.resolve4(hostname);\n    classicTimes.push(performance.now() - start);\n  }\n\n  \/\/ DNS over HTTPS via Cloudflare\n  const dohTimes = [];\n  const url = `https:\/\/cloudflare-dns.com\/dns-query?name=${hostname}&type=A`;\n  for (let i = 0; i < iterations; i++) {\n    const start = performance.now();\n    await fetch(url, { headers: { Accept: 'application\/dns-json' } });\n    dohTimes.push(performance.now() - start);\n  }\n\n  const avg = arr => (arr.reduce((a, b) => a + b, 0) \/ arr.length).toFixed(1);\n  console.log(`Benchmark pour \"${hostname}\" (${iterations} it\u00e9rations) :`);\n  console.log(`  DNS classique : ${avg(classicTimes)} ms (moyenne)`);\n  console.log(`  DoH 1re requ\u00eate : ${dohTimes[0].toFixed(1)} ms (TLS inclus)`);\n  console.log(`  DoH derni\u00e8re requ\u00eate : ${dohTimes[iterations-1].toFixed(1)} ms (connexion r\u00e9utilis\u00e9e)`);\n  console.log(`  DoH moyenne : ${avg(dohTimes)} ms`);\n}\n\nbenchmark('google.com');<\/code><\/pre>\n\n\n\n
    \u00c9tape 9 : Configuration avanc\u00e9e avec NextDNS<\/h2>\n\n\n\n
    NextDNS se distingue des autres fournisseurs DoH par son niveau de personnalisation. Chaque compte cr\u00e9e un profil avec un identifiant unique (ex : abc123<\/code>), ce qui g\u00e9n\u00e8re un endpoint DoH personnalis\u00e9 : https:\/\/dns.nextdns.io\/abc123<\/code>. Via la console NextDNS, configurez des listes de blocage (EasyList, oisd, AdGuard DNS Filter), des r\u00e8gles de r\u00e9\u00e9criture DNS, des blocages parentaux par cat\u00e9gorie, et visualisez les requ\u00eates DNS en temps r\u00e9el.<\/p>\n\n\n\n
    Pour les entreprises, NextDNS propose une journalisation conforme au RGPD avec stockage optionnel en Europe (Allemagne) ou pas de stockage du tout. Le plan gratuit couvre 300 000 requ\u00eates par mois, ce qui suffit pour un foyer de 4 personnes sur tous les appareils. Les plans payants d\u00e9marrent \u00e0 1,99 \u20ac\/mois sans limite.<\/p>\n\n\n\n
    L’API NextDNS permet de g\u00e9rer la configuration et d’extraire des statistiques pour int\u00e9gration dans des tableaux de bord :<\/p>\n\n\n\n
    # API NextDNS - exemples de gestion (remplacer PROFILE_ID et API_KEY)\nPROFILE_ID=\"votre_profil_id\"\nAPI_KEY=\"votre_cle_api_nextdns\"\n\n# Statistiques des derni\u00e8res 24 heures\ncurl -s \"https:\/\/api.nextdns.io\/profiles\/${PROFILE_ID}\/analytics\/status?from=-24h\" \\\n  -H \"X-Api-Key: ${API_KEY}\" | python3 -m json.tool\n\n# Ajouter un domaine \u00e0 la liste blanche (\u00e9viter blocages l\u00e9gitimes)\ncurl -s -X POST \"https:\/\/api.nextdns.io\/profiles\/${PROFILE_ID}\/allowlist\" \\\n  -H \"X-Api-Key: ${API_KEY}\" \\\n  -H \"Content-Type: application\/json\" \\\n  -d '{\"id\": \"example.com\", \"active\": true}'\n\n# Tester la connectivit\u00e9 DoH avec votre profil NextDNS personnalis\u00e9\ncurl -s -H \"Accept: application\/dns-json\" \\\n  \"https:\/\/dns.nextdns.io\/${PROFILE_ID}?name=cloudflare.com&type=A\"<\/code><\/pre>\n\n\n\n
    \u00c9tape 10 : DoH sur un routeur avec pfSense et OPNsense<\/h2>\n\n\n\n
    Configurer DoH directement sur le routeur pr\u00e9sente un avantage majeur : tous les appareils du r\u00e9seau (smartphones, t\u00e9l\u00e9viseurs connect\u00e9s, consoles de jeu) b\u00e9n\u00e9ficient du chiffrement DNS sans configuration individuelle. pfSense et OPNsense supportent DoH via leurs packages Unbound.<\/p>\n\n\n\n
    Sur OPNsense<\/strong>, la configuration DoT (DNS over TLS, protocole similaire \u00e0 DoH) s’effectue dans Services, Unbound DNS, DNS over TLS. Ajoutez les serveurs Cloudflare (1.1.1.1<\/code>, hostname TLS : cloudflare-dns.com<\/code>) et 1.0.0.1<\/code>. Pour du DoH natif, OPNsense propose le plugin os-unbound-plus<\/code> ou l’installation de cloudflared<\/code> comme package syst\u00e8me. Avec OPNsense 24.7+, l’interface graphique propose une option “Queries over HTTPS” directement dans la configuration DNS Resolver.<\/p>\n\n\n\n
    Sur pfSense Plus 24.11<\/strong>, allez dans Services, DNS Resolver. Dans la section “Custom Options”, ajoutez la directive Unbound pour utiliser un serveur DoH upstream en combinant Unbound avec cloudflared<\/code> install\u00e9 via le gestionnaire de paquets FreeBSD. Pi-hole peut \u00e9galement \u00eatre combin\u00e9 avec DoH en configurant cloudflared<\/code> comme upstream DNS vers le port 5053 local, puis en pointant Pi-hole vers 127.0.0.1:5053<\/code>.<\/p>\n\n\n\n
    \u00c9tape 11 : Combiner DoH avec DNSSEC<\/h2>\n\n\n\n
    DoH chiffre le transport des requ\u00eates DNS, mais ne garantit pas l’int\u00e9grit\u00e9 des r\u00e9ponses. DNSSEC (DNS Security Extensions, RFC 4033) ajoute des signatures cryptographiques sur les zones DNS, permettant de v\u00e9rifier que la r\u00e9ponse n’a pas \u00e9t\u00e9 alt\u00e9r\u00e9e. DoH + DNSSEC forme une protection compl\u00e8te : chiffrement du transport ET int\u00e9grit\u00e9 des donn\u00e9es.<\/p>\n\n\n\n
    V\u00e9rifier le support DNSSEC d’un domaine via l’API DoH :<\/p>\n\n\n\n
    # V\u00e9rifier DNSSEC via l'API DoH (champ \"AD\" = Authentic Data = DNSSEC valid\u00e9)\ncurl -s -H \"Accept: application\/dns-json\" \\\n  \"https:\/\/cloudflare-dns.com\/dns-query?name=cloudflare.com&type=A\" | \\\n  python3 -c \"import json,sys; d=json.load(sys.stdin); print('DNSSEC valid\u00e9 :', 'OUI' if d.get('AD') else 'NON')\"\n\n# Sortie : DNSSEC valid\u00e9 : OUI\n\n# V\u00e9rifier avec un domaine sans DNSSEC\ncurl -s -H \"Accept: application\/dns-json\" \\\n  \"https:\/\/cloudflare-dns.com\/dns-query?name=example.com&type=A\" | \\\n  python3 -c \"import json,sys; d=json.load(sys.stdin); print('DNSSEC valid\u00e9 :', 'OUI' if d.get('AD') else 'NON')\"\n\n# Sortie : DNSSEC valid\u00e9 : NON  (example.com n'utilise pas DNSSEC)\n\n# V\u00e9rifier via dig si disponible\ndig +dnssec cloudflare.com @1.1.1.1 | grep -E \"flags:|RRSIG\"\n# Chercher \"ad\" dans les flags = DNSSEC valid\u00e9 par le r\u00e9solveur<\/code><\/pre>\n\n\n\n
    Tous les grands fournisseurs DoH (Cloudflare, Quad9, NextDNS) valident DNSSEC par d\u00e9faut. Si un domaine retourne \"AD\": true<\/code>, la cha\u00eene de confiance DNSSEC depuis la zone racine jusqu’au domaine est valid\u00e9e. Quad9 bloque par d\u00e9faut les domaines dont la validation DNSSEC \u00e9choue, offrant une protection suppl\u00e9mentaire contre les attaques de type DNS spoofing.<\/p>\n\n\n\n
    \u00c9tape 12 : Surveillance des requ\u00eates DNS et d\u00e9tection d’anomalies<\/h2>\n\n\n\n
    M\u00eame avec DoH actif, maintenir une visibilit\u00e9 sur les requ\u00eates DNS du r\u00e9seau est utile pour d\u00e9tecter des comportements anormaux (malware DGA, exfiltration de donn\u00e9es via DNS tunnel). Trois approches compl\u00e9mentaires permettent de surveiller les requ\u00eates tout en maintenant le chiffrement DoH.<\/p>\n\n\n\n
    Approche 1 : utiliser la console de logs NextDNS ou AdGuard DNS avec journalisation activ\u00e9e. Ces fournisseurs stockent les requ\u00eates dans leur interface web pour une dur\u00e9e configurable (de 1 heure \u00e0 2 ans). Approche 2 : d\u00e9ployer dnscrypt-proxy avec journalisation locale activ\u00e9e dans dnscrypt-proxy.toml<\/code>. Approche 3 : un script Node.js pour analyser les logs DNS et d\u00e9tecter les patterns suspects comme les domaines g\u00e9n\u00e9r\u00e9s algorithmiquement (DGA) :<\/p>\n\n\n\n
    \/\/ dns-anomaly-detector.js - D\u00e9tection d'anomalies DNS en Node.js 18+\n\/\/ Analyse les domaines NXDOMAIN pour d\u00e9tecter les malwares DGA\n\nconst fs = require('fs');\nconst readline = require('readline');\n\nconst LOG_FILE = '\/var\/log\/dnscrypt-proxy\/nx.log'; \/\/ Adapter selon votre config\n\n\/\/ Patterns suspects : DGA (Domain Generation Algorithm) utilis\u00e9 par les malwares\n\/\/ Les malwares g\u00e9n\u00e8rent des centaines de domaines al\u00e9atoires pour trouver leur C2\nconst SUSPICIOUS_PATTERNS = [\n  \/^[a-z0-9]{15,}\\.(com|net|org)$\/i, \/\/ Domaines tr\u00e8s longs et al\u00e9atoires\n  \/\\.(tk|ml|ga|cf|gq)$\/i,             \/\/ TLDs gratuits souvent abus\u00e9s\n  \/^[a-z]{3,5}[0-9]{4,8}\\.\/i,         \/\/ Combinaison lettres-chiffres suspecte\n];\n\nasync function detectAnomalies() {\n  if (!fs.existsSync(LOG_FILE)) {\n    console.log(`Fichier log introuvable : ${LOG_FILE}`);\n    console.log('Activez query_log dans dnscrypt-proxy.toml');\n    return;\n  }\n\n  const fileStream = fs.createReadStream(LOG_FILE);\n  const rl = readline.createInterface({ input: fileStream, crlfDelay: Infinity });\n\n  let total = 0;\n  const suspicious = [];\n  const domainFrequency = new Map();\n\n  for await (const line of rl) {\n    const parts = line.split('\\t');\n    if (parts.length < 3) continue;\n    const [timestamp, domain] = parts;\n    total++;\n\n    \/\/ Compter les requ\u00eates par domaine de base\n    const baseDomain = domain.split('.').slice(-2).join('.');\n    domainFrequency.set(baseDomain, (domainFrequency.get(baseDomain) || 0) + 1);\n\n    const isSuspicious = SUSPICIOUS_PATTERNS.some(p => p.test(domain));\n    if (isSuspicious) suspicious.push({ timestamp, domain });\n  }\n\n  console.log(`Total requ\u00eates NXDOMAIN analys\u00e9es : ${total}`);\n\n  \/\/ Alerter si plus de 20 sous-domaines NXDOMAIN pour un m\u00eame domaine de base\n  \/\/ (indicateur fort de malware DGA ou d'exfiltration DNS)\n  const highFrequency = [...domainFrequency.entries()]\n    .filter(([, count]) => count > 20)\n    .sort(([, a], [, b]) => b - a);\n\n  if (highFrequency.length > 0) {\n    console.warn('\\nALERTE - Domaines avec plus de 20 NXDOMAIN (possible DGA) :');\n    highFrequency.forEach(([d, c]) => console.warn(`  ${d}: ${c} requ\u00eates`));\n  }\n\n  if (suspicious.length > 0) {\n    console.warn(`\\nALERTE - ${suspicious.length} domaine(s) au pattern suspect :`);\n    suspicious.slice(0, 10).forEach(d => console.warn(`  ${d.timestamp} - ${d.domain}`));\n  }\n\n  if (highFrequency.length === 0 && suspicious.length === 0) {\n    console.log('Aucune anomalie DNS d\u00e9tect\u00e9e.');\n  }\n}\n\ndetectAnomalies().catch(console.error);<\/code><\/pre>\n\n\n\n
    Les 8 pi\u00e8ges courants avec DNS over HTTPS<\/h2>\n\n\n\n
    Pi\u00e8ge 1 : Mode de repli DNS actif sans le savoir.<\/strong> Par d\u00e9faut, Chrome et Firefox activent DoH en mode “automatique avec repli” : si le r\u00e9solveur DoH est inaccessible, le navigateur bascule silencieusement vers le DNS classique du syst\u00e8me. Cette fuite passe inaper\u00e7ue. Passez en mode strict (Firefox network.trr.mode = 3<\/code>, Chrome DnsOverHttpsMode = \"secure\"<\/code>) et acceptez que certains r\u00e9seaux soient momentan\u00e9ment inaccessibles.<\/p>\n\n\n\n
    Pi\u00e8ge 2 : Portails captifs Wi-Fi cass\u00e9s.<\/strong> Les portails captifs (h\u00f4tels, a\u00e9roports, campus) interceptent les requ\u00eates DNS pour rediriger vers leur page d’authentification. Avec DoH strict actif, le portail ne peut plus intercepter vos requ\u00eates, et vous semblez n’avoir pas acc\u00e8s \u00e0 Internet, alors que la connexion fonctionne. Solution : d\u00e9sactiver temporairement DoH sur les r\u00e9seaux Wi-Fi publics ou passer en mode avec repli sur ces r\u00e9seaux.<\/p>\n\n\n\n
    Pi\u00e8ge 3 : Split-horizon DNS d’entreprise cass\u00e9.<\/strong> Les r\u00e9seaux d’entreprise utilisent souvent un DNS interne qui r\u00e9sout des noms priv\u00e9s (ex : intranet.entreprise.com<\/code>, serveur.local<\/code>) vers des IPs internes. DoH interroge le r\u00e9solveur externe (Cloudflare, Quad9) qui ne conna\u00eet pas ces zones priv\u00e9es : toutes les r\u00e9solutions internes \u00e9chouent. Solution : configurer une liste de domaines exclus de DoH dans Firefox via network.trr.excluded-domains<\/code>, ou maintenir un DNS interne avec DoT\/DoH.<\/p>\n\n\n\n
    Pi\u00e8ge 4 : Confusion entre DoH et DoT.<\/strong> DNS over TLS (DoT) chiffre les requ\u00eates DNS sur le port 853 via une session TLS d\u00e9di\u00e9e. DNS over HTTPS (DoH) les encapsule dans HTTP\/2 sur le port 443. systemd-resolved sous Linux active DoT avec DNSOverTLS=yes<\/code> mais ne supporte pas DoH nativement sur Ubuntu 22.04 et Debian 12. Si vous configurez DNSOverTLS=yes<\/code> en pensant activer DoH, vous activez DoT. Les deux chiffrent le DNS, mais seul DoH sur le port 443 est indiscernable du trafic HTTPS normal.<\/p>\n\n\n\n
    Pi\u00e8ge 5 : VPN qui court-circuite DoH.<\/strong> Un client VPN actif remplace g\u00e9n\u00e9ralement les param\u00e8tres DNS du syst\u00e8me pour forcer l’utilisation du r\u00e9solveur DNS du VPN. Si votre VPN est mal configur\u00e9 ou ne supporte pas DoH, toutes vos requ\u00eates DNS passeront en clair par le r\u00e9solveur du VPN, contournant la configuration DoH. V\u00e9rifiez que votre fournisseur VPN expose un r\u00e9solveur DoH (Mullvad et ProtonVPN le font), ou configurez DoH dans chaque application individuellement plut\u00f4t qu’au niveau syst\u00e8me.<\/p>\n\n\n\n
    Pi\u00e8ge 6 : Performance d\u00e9grad\u00e9e par la cr\u00e9ation r\u00e9p\u00e9t\u00e9e de connexions.<\/strong> Chaque nouvelle connexion HTTPS vers le r\u00e9solveur DoH implique un handshake TLS 1.3 (~20-50 ms selon la latence). Sur HTTP\/2, les requ\u00eates suivantes multiplexent la connexion existante sans overhead TLS. Si votre application Node.js cr\u00e9e une nouvelle connexion fetch<\/code> pour chaque requ\u00eate DNS, la latence est 10x sup\u00e9rieure au DNS classique. Solution : r\u00e9utiliser les connexions via un client HTTP avec keepAlive: true<\/code> ou utiliser une biblioth\u00e8que DoH qui g\u00e8re le pool de connexions.<\/p>\n\n\n\n
    Pi\u00e8ge 7 : Applications qui ignorent le DNS syst\u00e8me.<\/strong> Chrome, Firefox en mode DoH actif, et certains clients P2P impl\u00e9mentent leur propre r\u00e9solveur DNS et ignorent le r\u00e9solveur configur\u00e9 au niveau OS. Sur ces applications, m\u00eame avec dnscrypt-proxy actif sur le port 53, leurs requ\u00eates DNS passent directement vers des serveurs hardcod\u00e9s dans l’application. V\u00e9rification : capturer le trafic avec Wireshark sur les ports 53 et 443 simultan\u00e9ment pour identifier ces applications.<\/p>\n\n\n\n
    Pi\u00e8ge 8 : Fausse impression d’anonymat complet.<\/strong> DoH masque vos requ\u00eates DNS \u00e0 votre FAI et aux op\u00e9rateurs r\u00e9seau interm\u00e9diaires. Mais le fournisseur DoH voit toutes vos requ\u00eates. Cloudflare, bien qu’audit\u00e9 annuellement, reste une entreprise am\u00e9ricaine. Pour une confidentialit\u00e9 DNS plus robuste, combinez DoH avec un VPN dont le r\u00e9solveur DNS utilise lui-m\u00eame DoH, ou utilisez un r\u00e9solveur DoH auto-h\u00e9berg\u00e9 sur un VPS europ\u00e9en avec dnscrypt-proxy<\/code>.<\/p>\n\n\n\n
    D\u00e9pannage : 10 probl\u00e8mes courants et leurs solutions<\/h2>\n\n\n\n
    Sympt\u00f4me<\/th>Cause probable<\/th>Solution<\/th><\/tr><\/thead>
    Sites web inaccessibles apr\u00e8s activation DoH<\/td>Mode strict actif, r\u00e9solveur DoH inaccessible<\/td>Passer en mode avec repli, v\u00e9rifier connectivit\u00e9 vers l’URL DoH avec curl<\/td><\/tr>
    Wi-Fi public inaccessible (portail captif)<\/td>DoH strict bloque l’interception DNS du portail<\/td>D\u00e9sactiver temporairement DoH ou passer en mode automatique<\/td><\/tr>
    Ressources intranet non r\u00e9solues<\/td>DNS split-horizon incompatible avec r\u00e9solveur DoH externe<\/td>Ajouter domaines internes dans network.trr.excluded-domains<\/code> (Firefox)<\/td><\/tr>
    curl DoH retourne erreur 400<\/td>Header Accept manquant ou URL mal form\u00e9e<\/td>Ajouter -H \"Accept: application\/dns-json\"<\/code> \u00e0 la commande curl<\/td><\/tr>
    dnscrypt-proxy ne d\u00e9marre pas<\/td>Port 53 occup\u00e9 par systemd-resolved<\/td>D\u00e9sactiver stub resolver : DNSStubListener=no<\/code> dans \/etc\/systemd\/resolved.conf<\/td><\/tr>
    Firefox revient au DNS classique apr\u00e8s red\u00e9marrage<\/td>Extension (uBlock, VPN) surcharge les param\u00e8tres DNS<\/td>V\u00e9rifier about:config, d\u00e9sactiver extensions DNS temporairement<\/td><\/tr>
    Quad9 bloque des sites l\u00e9gitimes<\/td>Faux positif dans le filtre de malware Quad9<\/td>Tester avec Cloudflare 1.1.1.1, signaler le faux positif sur quad9.net<\/td><\/tr>
    DoH tr\u00e8s lent (500+ ms par requ\u00eate)<\/td>Nouvelle connexion TLS cr\u00e9\u00e9e pour chaque requ\u00eate<\/td>Activer HTTP\/2 et keepalive dans le client HTTP, impl\u00e9menter un cache DNS local<\/td><\/tr>
    Mobile Android ignore DoH configur\u00e9<\/td>Android utilise Private DNS (DoT port 853), pas DoH<\/td>Param\u00e8tres, Connexions, DNS priv\u00e9 : entrer 1dot1dot1dot1.cloudflare-dns.com<\/code><\/td><\/tr>
    DNSSEC \u00e9choue (AD=false<\/code>) sur Quad9<\/td>Domaine sans DNSSEC ou validation DNSSEC bloqu\u00e9e<\/td>Comportement normal si le domaine n’impl\u00e9mente pas DNSSEC, utiliser Cloudflare 1.1.1.1 si blocage g\u00eanant<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Diagnostic avanc\u00e9 : identifier la source des requ\u00eates DNS en clair<\/h3>\n\n\n\n
    Pour diagnostiquer avec pr\u00e9cision quelle application envoie encore des requ\u00eates DNS classiques malgr\u00e9 DoH actif, utilisez ss<\/code> ou lsof<\/code> sous Linux pour identifier les processus qui \u00e9tablissent des connexions sur le port 53 :<\/p>\n\n\n\n
    # Identifier les processus qui utilisent le port 53 (DNS classique)\nsudo ss -tulnp | grep ':53'\n# ou\nsudo lsof -i :53 -P -n\n\n# Capturer toutes les requ\u00eates DNS classiques en temps r\u00e9el et identifier leur source\nsudo tcpdump -n -i any 'udp port 53 or tcp port 53' -l 2>\/dev\/null | \\\n  head -20\n\n# Sur Linux : trouver quel processus fait des requ\u00eates DNS en clair\nsudo strace -e trace=network -f -p $(pgrep -f \"nom_du_processus\") 2>&1 | \\\n  grep \"connect\\|sendto\" | grep \"53\"\n\n# Sous Windows PowerShell\nGet-NetUDPEndpoint -LocalPort 53 | ForEach-Object {\n    $proc = Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue\n    [PSCustomObject]@{PID=$_.OwningProcess; Nom=$proc.Name; Port=$_.LocalPort}\n}<\/code><\/pre>\n\n\n\n
    Conseils avanc\u00e9s pour administrateurs r\u00e9seau et d\u00e9veloppeurs<\/h2>\n\n\n\n
    DoH en entreprise avec r\u00e9solveur interne.<\/strong> Les organisations peuvent d\u00e9ployer leur propre r\u00e9solveur DoH interne via Unbound, dnscrypt-proxy en mode serveur, ou des solutions commerciales comme Cloudflare Gateway ou Cisco Umbrella. Cette approche “secure split DNS” offre DoH aux employ\u00e9s tout en maintenant la r\u00e9solution des noms internes et la visibilit\u00e9 sur les requ\u00eates DNS pour le SOC.<\/p>\n\n\n\n
    DoH dans Kubernetes via CoreDNS.<\/strong> CoreDNS 1.9+ supporte les transports TLS et HTTPS pour les requ\u00eates upstream. Modifiez le ConfigMap CoreDNS pour ajouter le transport TLS vers Cloudflare : forward . tls:\/\/1.1.1.1 tls:\/\/1.0.0.1 { tls_servername cloudflare-dns.com }<\/code> dans le Corefile. Les pods du cluster b\u00e9n\u00e9ficient alors du chiffrement DNS sans modification de leurs applications.<\/p>\n\n\n\n
    Conformit\u00e9 RGPD des fournisseurs DoH.<\/strong> En France et dans l’UE, le transfert de donn\u00e9es de navigation DNS vers des serveurs am\u00e9ricains peut cr\u00e9er une tension avec le RGPD (Articles 44-49, transferts vers pays tiers). Quad9 (bas\u00e9 en Suisse) et ses serveurs en Europe, ou un r\u00e9solveur DoH auto-h\u00e9berg\u00e9 sur un VPS en France ou en Allemagne, sont des alternatives conformes sans questions de transferts hors UE. Cloudflare propose des Data Processing Agreements RGPD et localise les requ\u00eates europ\u00e9ennes dans ses datacenters en France, Allemagne, et Pays-Bas.<\/p>\n\n\n\n
    DoH et monitoring DNSSEC automatis\u00e9.<\/strong> Automatisez la surveillance de la validit\u00e9 DNSSEC pour vos domaines critiques. Un script cron qui interroge l’API DoH toutes les heures et alerte via Webhook Slack ou email si le champ AD<\/code> passe de true<\/code> \u00e0 false<\/code> peut d\u00e9tecter des compromissions de zone DNS ou des attaques BGP hijacking ciblant vos domaines.<\/p>\n\n\n\n
    Comparaison des m\u00e9thodes de d\u00e9ploiement DoH<\/h2>\n\n\n\n
    M\u00e9thode<\/th>Port\u00e9e<\/th>Difficult\u00e9<\/th>Appareils couverts<\/th>R\u00e9sistance VPN<\/th><\/tr><\/thead>
    Configuration navigateur (Firefox\/Chrome)<\/td>1 navigateur uniquement<\/td>Facile (GUI)<\/td>1 app sur 1 appareil<\/td>Faible (VPN override)<\/td><\/tr>
    Windows 11 (param\u00e8tres r\u00e9seau)<\/td>OS complet<\/td>Moyen<\/td>Toutes apps Windows<\/td>\u00c9lev\u00e9e (VPN override OS)<\/td><\/tr>
    cloudflared (macOS\/Linux)<\/td>OS complet<\/td>Moyen (CLI)<\/td>Toutes apps<\/td>\u00c9lev\u00e9e (VPN override OS)<\/td><\/tr>
    dnscrypt-proxy (Linux)<\/td>OS complet<\/td>Avanc\u00e9 (config fichier)<\/td>Toutes apps<\/td>Variable<\/td><\/tr>
    Configuration routeur (pfSense\/OPNsense)<\/td>R\u00e9seau entier<\/td>Avanc\u00e9 (admin r\u00e9seau)<\/td>Tous appareils du LAN<\/td>Nulle (en amont du VPN client)<\/td><\/tr>
    R\u00e9solveur DoH auto-h\u00e9berg\u00e9<\/td>R\u00e9seau entier + contr\u00f4le total<\/td>Expert (infra VPS)<\/td>Tous appareils<\/td>Nulle<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Questions fr\u00e9quentes sur DNS over HTTPS<\/h2>\n\n\n\n
    DoH remplace-t-il un VPN ?<\/h3>\n\n\n\n
    Non. DoH chiffre uniquement les requ\u00eates DNS. Votre adresse IP reste visible \u00e0 tous les sites que vous visitez, et le contenu de vos connexions (hors DNS) n’est pas chiffr\u00e9 ou anonymis\u00e9 par DoH. Un VPN chiffre l’int\u00e9gralit\u00e9 de votre trafic et masque votre IP, mais son r\u00e9solveur DNS peut ne pas utiliser DoH. Les deux sont compl\u00e9mentaires : un VPN avec r\u00e9solveur DoH interne (comme Mullvad ou ProtonVPN) vous offre chiffrement du trafic, masquage d’IP, et chiffrement DNS simultan\u00e9ment.<\/p>\n\n\n\n
    DoH fonctionne-t-il sur Android et iOS ?<\/h3>\n\n\n\n
    Android 9+ supporte “DNS priv\u00e9” (DNS over TLS, pas DoH). Pour Cloudflare en DoT sur Android : Param\u00e8tres, Connexions, Param\u00e8tres r\u00e9seau suppl\u00e9mentaires, DNS priv\u00e9, puis entrez 1dot1dot1dot1.cloudflare-dns.com<\/code>. Pour du DoH natif sur Android, des applications comme 1.1.1.1 (Cloudflare) cr\u00e9ent un VPN local qui intercepte les requ\u00eates DNS et les convertit en DoH. Sur iOS 14+, des profils de configuration DoH\/DoT s’installent via l’application Apple Configurator ou l’app 1.1.1.1 de Cloudflare qui g\u00e9n\u00e8re un profil .mobileconfig.<\/p>\n\n\n\n
    Mon FAI peut-il bloquer DoH ?<\/h3>\n\n\n\n
    Techniquement oui, mais c’est difficile. DoH utilise le port 443 comme tout trafic HTTPS standard. Un FAI qui voudrait bloquer DoH devrait soit bloquer les IPs des r\u00e9solveurs DoH (1.1.1.1, 8.8.8.8, 9.9.9.9), coupant du m\u00eame coup des services l\u00e9gitimes, soit inspecter le SNI des connexions TLS. L’adoption d’ECH (Encrypted Client Hello) rendra cette inspection de plus en plus inefficace. En France, aucun FAI ne bloque activement les r\u00e9solveurs DoH publics connus en 2026.<\/p>\n\n\n\n
    DoH am\u00e9liore-t-il les performances DNS ?<\/h3>\n\n\n\n
    La r\u00e9ponse d\u00e9pend de votre situation de d\u00e9part. Si votre r\u00e9solveur DNS actuel (celui de votre FAI ou du DHCP) est lent ou g\u00e9ographiquement distant, passer \u00e0 Cloudflare 1.1.1.1 (3 ms depuis la France) peut acc\u00e9l\u00e9rer significativement la r\u00e9solution DNS. Si votre r\u00e9solveur actuel est d\u00e9j\u00e0 rapide, la premi\u00e8re r\u00e9solution DoH sera plus lente (handshake TLS ~20-50 ms), mais les suivantes seront comparables gr\u00e2ce au multiplexage HTTP\/2 et au cache DNS c\u00f4t\u00e9 r\u00e9solveur.<\/p>\n\n\n\n
    Quelle est la diff\u00e9rence entre DoH et DoT ?<\/h3>\n\n\n\n
    DNS over TLS (DoT, RFC 7858) chiffre les requ\u00eates DNS via TLS sur le port d\u00e9di\u00e9 853. DNS over HTTPS (DoH, RFC 8484) les encapsule dans HTTP\/2 sur le port 443. Les deux offrent un chiffrement \u00e9quivalent en termes de s\u00e9curit\u00e9. La diff\u00e9rence principale est la discr\u00e9tion : DoH sur le port 443 est indiscernable du trafic HTTPS normal, tandis que DoT sur le port 853 est facilement identifiable et bloquable par les pare-feux. Pour les particuliers, DoH est g\u00e9n\u00e9ralement pr\u00e9f\u00e9rable. Pour les entreprises qui veulent distinguer le trafic DNS du reste pour le filtrer ou l’auditer, DoT sur le port 853 est plus simple \u00e0 g\u00e9rer.<\/p>\n\n\n\n
    Comment DoH interagit-il avec Pi-hole ?<\/h3>\n\n\n\n
    Pi-hole est un r\u00e9solveur DNS local qui filtre les publicit\u00e9s mais ne supporte pas DoH nativement. Pour combiner Pi-hole et DoH : installez cloudflared<\/code> sur le m\u00eame serveur que Pi-hole, configurez cloudflared pour \u00e9couter sur le port 5053, puis configurez Pi-hole pour utiliser 127.0.0.1:5053<\/code> comme serveur DNS upstream dans Param\u00e8tres, DNS. Pi-hole filtre les publicit\u00e9s localement, et cloudflared transmet les requ\u00eates non bloqu\u00e9es via DoH vers Cloudflare. Le r\u00e9seau entier b\u00e9n\u00e9ficie du blocage de publicit\u00e9s Pi-hole ET du chiffrement DNS DoH.<\/p>\n\n\n\n
    Comment v\u00e9rifier que mes donn\u00e9es DNS ne fuitent pas ?<\/h3>\n\n\n\n
    Utilisez le test de diagnostic Cloudflare sur https:\/\/1.1.1.1\/help<\/code>. Ce test effectue plusieurs r\u00e9solutions DNS et identifie quel r\u00e9solveur r\u00e9pond \u00e0 vos requ\u00eates. Si le test retourne les serveurs de votre FAI plut\u00f4t que les serveurs de votre fournisseur DoH configur\u00e9, vous avez une fuite DNS. Les causes les plus fr\u00e9quentes sont un VPN actif qui surcharge les param\u00e8tres DNS, une application qui utilise son propre r\u00e9solveur DNS interne, ou un mode DoH “avec repli” qui bascule vers DNS classique sans vous en informer.<\/p>\n\n\n\n
    Couverture associ\u00e9e<\/h2>\n\n\n\n
    Pour approfondir la protection de votre vie priv\u00e9e num\u00e9rique et la s\u00e9curit\u00e9 r\u00e9seau :<\/p>\n\n\n\n