Guide de mise en place du DNS over HTTPS

Le DNS over HTTPS (DoH), c'est sans doute le gain de confidentialité le moins cher que je puisse offrir à une équipe, et c'est aussi celui que les gens ratent le plus souvent. Il emballe tes requêtes dans du TLS 1.3 sur le port 443, du coup sur le réseau elles ressemblent à n'importe quel autre trafic HTTPS. Voici la totale, telle que je la mets en place pour de vrai : ce que le DoH t'apporte (et ce qu'il ne t'apporte pas, en douce), comment l'activer sur les clients Windows, Linux et macOS, comment monter ton propre resolver avec unbound et dnsdist, et comment l'imposer en bordure sur pfSense et OPNsense sans rendre aveugles tes outils de monitoring.

Le DNS chiffré, c'est sans doute le gain de confidentialité le moins cher que je puisse offrir à une équipe. Et c'est aussi, bizarrement, celui que les gens ratent le plus souvent. Le DNS over HTTPS (DoH) emballe tes requêtes dans du TLS 1.3 sur le port 443, du coup sur le réseau elles ressemblent à n'importe quel autre trafic HTTPS. Je l'ai déployé sur tout un parc, une fois. Et puis j'ai passé un après-midi franchement pénible à expliquer à la sécu pourquoi leur dashboard DNS s'était retrouvé complètement dans le noir. Alors laisse-moi t'épargner cette conversation. Voici la totale, telle que je la mets en place pour de vrai : ce que le DoH t'apporte (et ce qu'il ne t'apporte pas, en douce), comment l'activer sur les clients Windows, Linux et macOS, comment monter ton propre resolver avec unbound et dnsdist, comment l'imposer en bordure de réseau sur pfSense / OPNsense, plus les astuces de monitoring et de policy qui l'empêchent de rendre aveugles les outils sur lesquels tu t'appuies déjà.

Contre quoi le DoH protège vraiment

Quelques fuites sont réellement bouchées ici, et ça vaut le coup d'être précis là-dessus. L'observation on-path : le Wi-Fi du café, le réseau de l'hôtel, ton FAI un peu trop curieux. Aucun d'eux ne peut plus lire quels hostnames tu résous. L'injection de requêtes off-path : forger une réponse DNS au niveau du portail captif n'est plus une petite blague à deux balles, parce que désormais l'attaquant doit casser la session TLS pour y arriver. La surveillance de masse : ce FAI qui revendait ton DNS en clair comme de « l'analytics » te regarde maintenant juste serrer la main à une seule IP Cloudflare. C'est tout ce qu'il récupère.

Maintenant la partie que tout le monde survole. Les gens jurent que le DoH fait une poignée de trucs qu'il ne fait carrément pas. Il ne va pas cacher où tu vas. Le SYN TCP et le SNI révèlent l'IP et l'hôte à la seconde où tu te connectes après la requête. Il ne va pas cacher tes requêtes à celui qui fait tourner le resolver, donc Cloudflare, Google et NextDNS voient encore absolument tout ce que tu demandes. Et il ne touche pas du tout au plan de données. Seule la requête est scellée. La session HTTPS qui suit, c'est une autre histoire. J'ai vu des gens intelligents traiter le DoH comme un VPN. Ce n'en est pas un, et honnêtement, ce contresens-là te grillera plus vite que n'importe quelle faute de frappe dans une config.

Choisir un fournisseur DoH, ou s'auto-héberger

Pour tout ce qui est corporate, je finis presque toujours sur du DoH auto-hébergé placé devant un resolver récursif interne. Tes requêtes ne quittent jamais le bâtiment. Tu gardes quand même la protection on-path qui t'avait donné envie de DoH au départ. Les fournisseurs publics sont parfaits pour un laptop nomade. Ils deviennent beaucoup plus durs à défendre dès que le juridique demande, à voix haute, où partent exactement les requêtes.

Postes Windows 10/11

Windows embarque le DoH nativement depuis Windows 10 21H2 et Windows 11 22H2, donc sur tout ce qui est à jour tu n'as pas du tout besoin d'un client tiers. Bien sûr, tu peux cliquer dans l'interface (Paramètres, Réseau, Paramètres DNS, Chiffré uniquement). Moi je le fais en PowerShell, parce que ça se scripte proprement sur tout un parc et que je n'ai pas envie de cocher la même case quatre cents fois.

Set-DnsClientDohServerAddress `
    -ServerAddress 1.1.1.1 `
    -DohTemplate 'https://cloudflare-dns.com/dns-query' `
    -AllowFallbackToUdp $false `
    -AutoUpgrade $true

Set-DnsClientServerAddress -InterfaceAlias 'Ethernet' -ServerAddresses 1.1.1.1, 1.0.0.1
Get-DnsClientDohServerAddress | Format-Table

Pour un domaine, pousse-le via la stratégie de groupe : Configuration ordinateur, Modèles d'administration, Réseau, Client DNS, Configurer la résolution de noms DNS over HTTPS (DoH) puis choisis Autoriser le DoH ou Exiger le DoH. Sache exactement ce que Exiger signifie avant de l'activer. Ça tue complètement le fallback en clair, donc à la seconde où ton endpoint tombe, ces clients n'ont plus de DNS du tout. Plus rien. C'est exactement le comportement que tu veux sur une image verrouillée, et exactement le comportement qui noie le help desk dès qu'un laptop se balade sur le Wi-Fi d'un hôtel.

Postes Linux (systemd-resolved + stubby)

Sur un Linux récent tu as en gros deux options bien propres. Pars sur systemd-resolved si le DoT (DNS over TLS) te convient. Même modèle de menace, config plus courte. Si tu as vraiment besoin de DoH sur le réseau, stubby ou dnsdist t'y amène. Et honnêtement ? Sur un serveur, le DoT suffit largement quasiment à chaque fois. Je ne sors le DoH que quand je me bats avec un réseau qui bloque activement le port 853, ce qui arrive, mais pas souvent.

# DoT via systemd-resolved (Ubuntu 24.04+, Fedora 39+, Debian 12+)
sudo tee /etc/systemd/resolved.conf.d/doh.conf <<'EOF'
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com
DNSOverTLS=yes
DNSSEC=yes
Cache=yes
EOF
sudo systemctl restart systemd-resolved
resolvectl status   # confirm "+DNSOverTLS=yes"

Quand tu veux vraiment du vrai DoH, stubby pointé vers un upstream compatible DoH est le truc le plus léger que j'aie trouvé qui marche tout seul, sans chichi :

sudo apt install -y stubby
sudo sed -i 's/listen_addresses:.*/listen_addresses: [ 127.0.0.1@5353 ]/' /etc/stubby/stubby.yml
# Point /etc/resolv.conf or NetworkManager at 127.0.0.1:5353

Postes macOS (profil de configuration)

macOS Ventura et au-delà veut un profil de configuration signé (.mobileconfig) pour ça. Il n'y a pas de petit interrupteur planqué dans le GUI, hélas. Sur un parc tu le pousseras depuis ton MDM, quelle que soit la solution que tu payes déjà (Jamf, Mosyle, Kandji, à toi de voir). Pour un seul laptop posé sur ton bureau, tu peux juste déposer le profil à la main :

<dict>
  <key>DNSSettings</key>
  <dict>
    <key>DNSProtocol</key><string>HTTPS</string>
    <key>ServerURL</key><string>https://cloudflare-dns.com/dns-query</string>
  </dict>
  <key>PayloadType</key><string>com.apple.dnsSettings.managed</string>
</dict>

Charge-le depuis Réglages Système, Confidentialité et sécurité, Profils puis vérifie ton boulot avec scutil --dns. Tu cherches protocol: HTTPS à côté de chaque entrée de resolver. Pas là ? Alors le profil n'a pas pris, et macOS ne dira gentiment rien à ce sujet.

Le DoH sur ton propre resolver (unbound + dnsdist)

Le montage sur lequel je reviens toujours : dnsdist en façade qui gère le DoH, unbound qui fait la vraie récursion juste derrière, les deux sur la même machine. Tu n'as pas besoin de gros matériel pour ça. Un Hetzner CAX21 ou un petit mini-PC N100 avalera des milliers de QPS sans transpirer. J'ai fait tourner exactement ça pour un petit bureau sur du matériel qui a coûté moins qu'un mois de certaine facture SaaS, et c'est juste resté là à faire son taf.

-- /etc/dnsdist/dnsdist.conf
addDOHLocal('0.0.0.0:443', '/etc/letsencrypt/live/dns.example.com/fullchain.pem',
                          '/etc/letsencrypt/live/dns.example.com/privkey.pem',
            { '/dns-query' }, { reusePort=true, idleTimeout=30 })
newServer({ address='127.0.0.1:5353', name='unbound', useClientSubnet=false })

# /etc/unbound/unbound.conf.d/local.conf
server:
  interface: 127.0.0.1@5353
  access-control: 127.0.0.1/32 allow
  cache-min-ttl: 60
  cache-max-ttl: 86400
  prefetch: yes
  qname-minimisation: yes
  hide-identity: yes
  hide-version: yes

Pointe tes clients vers https://dns.example.com/dns-query et voilà, c'est tout. Chaque saut de la chaîne de résolution t'appartient désormais. Aucun tiers ne voit les requêtes, et c'est toi qui décides ce qui (s'il y a lieu) finit un jour dans les logs. Ce qui est, au fond, la seule raison pour laquelle je me casse la tête à faire tourner le mien.

Imposer le DoH en bordure sur pfSense / OPNsense

Tu peux partir dans deux directions opposées ici, et les deux se défendent parfaitement. Tout le truc tient à une seule question : tu cherches à contrôler le DNS, ou juste à le chiffrer ?

• N'autoriser que ton endpoint DoH. Bloque le TCP 443 vers les IP DoH publiques bien connues depuis le LAN utilisateur, comme ça tout le monde est canalisé vers ton DoH maison et celui de personne d'autre. Le pfBlockerNG de pfSense comme les règles IDS d'OPNsense embarquent déjà des listes maintenues d'endpoints DoH publics, donc tu n'entretiens pas une énorme liste d'IP à la main. Petit avertissement, quand même. Ces listes vieillissent, et un utilisateur déterminé finira par trouver un endpoint que tu as raté.
• Autoriser n'importe quel DoH, bloquer le DNS en clair. Drop l'UDP/53 sortant pour tout sauf le resolver lui-même. Du coup même quand une mise à jour de l'OS repasse discrètement en DNS en clair (ça arrive), ces paquets se prennent un mur et le client est renvoyé vers la résolution chiffrée qu'il l'ait voulu ou non.

Monitoring et le cas du bypass légitime

C'est le piège dont personne ne te prévient, et celui qui m'a bien eu. À la seconde où tu actives le DoH, ta visibilité DNS basée sur les pcap s'éteint. Tous ces logs Zeek et ces filtres tcpdump calés sur l'UDP/53 ? Vides. Vides comme jamais. Donc avant de basculer le commutateur sur tout le parc, débrouille-toi pour savoir comment tu récupères cette visibilité, parce que tu en auras besoin la première fois que tu traqueras un beacon à 2 h du mat. Deux sorties possibles, selon ce que tu cherches.

• Si tu cherches de la détection, termine le DoH sur un resolver que tu contrôles et expédie les requêtes en clair décodées droit dans ton SIEM. Wazuh et la stack SOC homelab peuvent accrocher de l'enrichissement DNSDB aux événements indexés, comme ça tu ne perds pas l'angle threat-hunting juste parce que le réseau est devenu silencieux.
• Si tu cherches de la policy (bloquer les réseaux sociaux, les jeux d'argent ou le C2 de malware par hostname), fais-le sur le resolver, jamais sur le réseau. Essayer de sinkholer chaque endpoint DoH de la planète est un boulot de Sisyphe que tu perdras. J'ai vu des gens intelligents y cramer des semaines entières avant d'abandonner en silence.

Pièges et rollback

• Les portails captifs cassent sous « Exiger le DoH ». Le Wi-Fi des hôtels et des aéroports fonctionne en détournant ton DNS pour te renvoyer vers cette page de login, et Exiger le DoH refuse catégoriquement de jouer le jeu, du coup le laptop reste planté là : pas d'internet, pas d'erreur, aucune raison évidente. Utilise Autoriser plutôt qu'Exiger sur tout ce qui est mobile, ou garde une liste d'exceptions pour les portails captifs. Celle-là, je l'ai apprise dans un salon d'aéroport avec un vol en embarquement, c'est-à-dire précisément le moment où tu n'as pas envie de débugger du DNS.
• Le split-horizon DNS va te mordre, c'est sûr. Tes enregistrements internes company.local ne vivent que sur ton resolver interne, et un endpoint DoH public n'en a jamais entendu parler une seule fois. Laisse le DoH attraper ces requêtes et tes résolutions internes disparaissent purement et simplement dans le vide. Configure le DoH en fallback pour les noms externes uniquement, et assure-toi que les requêtes internes touchent d'abord le resolver interne. Ça, de très loin, c'est la façon la plus courante dont je vois exploser les déploiements DoH.
• Surveille le certificat, ou il fait tomber tout le bâtiment. Laisse ton endpoint DoH expirer son certificat Let's Encrypt en douce et tous les clients perdent le DNS au même instant exact. C'est une panne franchement misérable à découvrir à froid, le café même pas fini. Colle-lui une alerte d'expiration à 7 jours et laisse cron gérer le renouvellement. Ne te fais pas confiance pour t'en souvenir. Personne ne s'en souvient.
• QUIC et DoH3 arrivent, mais de façon inégale. Le DoH3 (sur QUIC / UDP 443) est plus rapide et nettement plus dur à bloquer. Mais le support Windows est encore assez bancal pour que je ne miserais pas un parc dessus pour l'instant, et j'aurai peut-être tort au moment où tu liras ça. Fais du DoH2 sur TCP/443 ton socle. Traite le DoH3 comme un joli bonus pour les clients qui le gèrent proprement.

Sources et lectures complémentaires

• RFC 8484, DNS Queries over HTTPS (DoH)
• RFC 7858, DNS over TLS (DoT)

Questions fréquentes