DNS over HTTPS (DoH) et DNS over TLS (DoT) : confidentialité sans compromettre les réseaux d’entreprise

Ce que vous changez réellement en activant DoH/DoT

Le DNS classique utilise principalement UDP/53 (et TCP/53 pour les grosses réponses, DNSSEC et transferts de zone). Il est rapide, omniprésent
et douloureusement observable. L’observabilité fonctionne dans les deux sens : votre FAI peut voir où vous allez, et n’importe qui
se trouvant sur le chemin avec une capture de paquets et de mauvaises intentions aussi.

DoT (DNS over TLS) encapsule le DNS dans TLS, généralement sur le port 853. DoH (DNS over HTTPS) encapsule le DNS dans HTTP/2 ou HTTP/3 sur TLS,
généralement sur le port 443. Les deux chiffrent la question et la réponse. Les deux protègent contre les observateurs passifs du réseau.
Aucun des deux ne rend le DNS « sécurisé » au sens de « correct » — cela reste une combinaison d’intégrité du résolveur,
de validation DNSSEC et de ne pas baser tout votre parc sur des impressions subjectives.

Dans les réseaux d’entreprise, le DNS est plus que la résolution de noms :

• Colle d’identité : découverte de services internes, AD, Kerberos et flux SSO.
• Point de politique : listes de blocage, sinkholes, filtrage par catégorie et contrôle de fuite de données.
• Télémetry : les journaux DNS sont un système d’alerte précoce peu coûteux.
• Ségrégation : le split‑horizon DNS est la manière de garder les noms internes internes.

Chiffrez le DNS sans plan et vous n’« augmentez » pas seulement la confidentialité. Vous contournez silencieusement vos propres contrôles.
Puis, la première fois que quelqu’un ne peut pas joindre un hôte interne parce que son portable interroge un résolveur public,
vous entendrez une phrase qui devrait être illégale dans les industries réglementées : « Mais ça marche sur mon Wi‑Fi à la maison. »

Faits et historique pertinents pour les opérations

• Le DNS est apparu en 1983 (ère RFC 882/883). Il a été conçu pour un réseau plus clément où « chiffrement partout » n’était pas la norme.
• DNSSEC a débuté à la fin des années 1990 et a mûri dans les années 2000. Il protège l’authenticité, pas la confidentialité. Les gens confondent souvent.
• La signature de la zone racine est active depuis 2010, rendant la validation DNSSEC pertinente de bout en bout pour de nombreux domaines, si votre résolveur valide réellement.
• DoT a été normalisé en 2016 (RFC 7858). C’est propre, direct et évident sur le réseau : TLS sur le port 853 a tendance à ressortir.
• DoH a été normalisé en 2018 (RFC 8484). Il se cache à l’intérieur du HTTPS normal, ce qui est à la fois l’intérêt et la source de la douleur opérationnelle.
• Firefox a activé DoH par défaut dans certaines régions vers 2019–2020 via le déploiement TRR. Les entreprises l’ont découvert de manière amusante : avec des tickets.
• EDNS0 a étendu le DNS pour que les réponses puissent dépasser 512 octets en UDP, réduisant la remontée vers TCP — excellent pour les performances, pénible pour des middleboxes qui n’ont jamais appris.
• La minimisation du QNAME est devenue une bonne pratique pour réduire les fuites de données vers les serveurs faisant autorité. C’est une aide à la confidentialité même sans DoH/DoT, mais cela dépend du comportement du résolveur.
• Encrypted ClientHello (ECH) est la prochaine frontière : il peut cacher le SNI. Quand l’ECH deviendra courant, « bloquer DoH par SNI » deviendra vite fragile.

L’industrie ne s’est pas réveillée un matin en décidant d’encrypter le DNS pour le fun. C’était une réaction à la surveillance omniprésente,
aux manipulations DNS au niveau FAI, et au fait que le DNS en clair est un beacon de traçage avec une excellente disponibilité.

Modèle de menace : qui vous protégez, et contre quoi

« Confidentialité » n’est pas une fonctionnalité ; c’est une décision sur les adversaires. Pour les réseaux d’entreprise, vous avez généralement trois catégories :

1) Observateurs passifs sur des réseaux non fiables

Wi‑Fi de café, réseaux d’hôtel, aéroports. DoH/DoT aide beaucoup ici. Si vous avez des travailleurs distants et pas de VPN toujours actif,
le DNS chiffré est l’un des rares contrôles qui fonctionne encore quand le réseau est hostile.

2) Altérations en chemin

Portails captifs, malwares injectant des NXDOMAIN, « aide » des FAI redirigeant les fautes de frappe vers des pages publicitaires. TLS supprime la plupart de cela.
DNSSEC aide aussi, mais le déploiement de DNSSEC est inégal et beaucoup de stubs ne valident pas ; ce sont les résolveurs qui le font.

3) Vos propres contrôles d’entreprise (oui, vous êtes un adversaire ici)

Vous consignez le DNS pour la détection. Vous bloquez des domaines connus malveillants. Vous orientez les zones internes vers des serveurs internes.
Le DNS chiffré peut contourner ces contrôles à moins que vous ne fournissiez un résolveur chiffré sanctionné et n’obligiez les clients à l’utiliser.

L’objectif réel en entreprise n’est pas « désactiver DoH ». C’est « faire en sorte que le DNS chiffré transite par notre résolveur, là où il doit être ».
Bloquer est un instrument brutal. Parfois nécessaire, rarement suffisant.

Une idée paraphrasée qui hante les opérations depuis des décennies : l’espoir n’est pas une stratégie — attribuée à Edsger W. Dijkstra (paraphrase, pas verbatim).
Si vous « espérez » que les clients n’utiliseront pas des points de terminaison DoH publics, vous êtes déjà en retard.

DoH vs DoT : différences pratiques (pas le marketing)

Transport et visibilité

• DoT : TLS sur le port 853. Facile à identifier et à appliquer en politique au pare‑feu. Aussi facile à casser accidentellement si les règles d’egress sont strictes.
• DoH : HTTPS sur le port 443. Difficile à distinguer du trafic web ordinaire sans interception TLS, contrôles sur les postes ou listes de points de terminaison connues.

Points de contrôle opérationnels

Si vous pouvez gérer les postes (MDM/GPO), DoH est maîtrisable : vous pouvez définir les résolveurs système, configurer les politiques « secure DNS »
et lier un résolveur d’entreprise. Si vous ne pouvez pas gérer les postes, DoH devient « une fonctionnalité de navigateur qui est maintenant votre problème réseau ».

Caractéristiques de performance

DoH peut emprunter des connexions HTTPS existantes, réutiliser TCP/TLS et bien se comporter sur HTTP/2. Dans certains environnements c’est plus rapide,
notamment sur des réseaux sujets à pertes. Dans d’autres, cela ajoute de la latence et de la complexité proxy. DoT est plus simple : une session TLS vers un résolveur,
beaucoup de requêtes.

Middleboxes et proxies

Les proxies d’entreprise comprennent souvent HTTP ; ils ne comprennent pas la « sémantique DNS dans HTTPS ». Un proxy peut bien relayer DoH
tandis que votre équipe de sécurité perd la visibilité DNS, ce qui revient à verrouiller la porte d’entrée tout en retirant les murs.

Blague n°1 : le DNS est le seul système où vous pouvez être en panne, opérationnel et « fonctionner comme prévu » en même temps, selon qui pose la question.

Comment le DNS d’entreprise casse : split‑horizon, proxies et middleboxes « utiles »

Split‑horizon DNS et pourquoi DoH/DoT peut le contourner

Le split‑horizon signifie que les clients internes obtiennent des réponses internes pour les noms internes, et les clients externes obtiennent des réponses externes.
Il sert à :

• Des noms d’hôtes accessibles uniquement en interne (par ex. git.corp)
• Des réponses différentes selon la localisation (interne vs externe)
• Sécurité : ne pas divulguer la topologie interne

Si un portable utilise DoH public (par exemple vers un résolveur sur Internet) lorsqu’il est sur VPN — ou pire, lorsqu’il est dans vos locaux — il peut :

• Ne pas résoudre les noms internes (incident de disponibilité)
• Résoudre vers des adresses publiques (risque d’exfiltration de données, routage incorrect)
• Fuir les schémas de requêtes internes vers une partie externe (problème de confidentialité et de confidentialité des données)

Contrôles de sécurité basés sur le DNS et ce que le DNS chiffré leur fait

Si vous bloquez des domaines malveillants au niveau du résolveur, et que les clients contournent ce résolveur, vous venez d’échanger « prévenir » contre « détecter plus tard »
(si vous le pouvez même). Et beaucoup d’organisations ne le peuvent pas. Elles exécutent des règles SIEM qui supposent l’existence de journaux DNS.

Le chiffrement n’est pas l’ennemi. Le chiffrement non géré l’est.

Middleboxes qui maltraitent les fonctionnalités DNS modernes

Même avec le DNS en clair, des middleboxes peuvent casser des choses :
EDNS0, DNSSEC, UDP fragmenté, fallback TCP. Avec DoT/DoH, les modes de défaillance changent :
boîtiers d’inspection TLS qui bloquent des SNI inconnus, proxies HTTP qui expirent des connexions longues,
et NAT d’egress qui churnent les ports assez vite pour rendre les résolveurs instables.

Architecture recommandée pour l’entreprise : résolveurs privés + politique + chiffrement contrôlé

L’étoile du nord

Fournir un service de résolveur d’entreprise qui supporte :

• Zones internes (autorisées ou transférées)
• Récursivité validée (validation DNSSEC activée)
• Politique de menaces (RPZ ou équivalent), avec contrôle des changements
• Points d’écoute chiffrés (DoT et/ou DoH) pour les clients
• Journalisation respectueuse de la confidentialité et avec durée de rétention définie
• Haute disponibilité (anycast ou au moins sites redondants)

Où terminer le chiffrement

Terminez DoH/DoT sur vos résolveurs, pas sur une boîte périmétrique aléatoire qui n’a aucun contexte DNS.
Gardez le résolveur proche (en termes réseau) des clients quand c’est possible ; la latence compte.
Ensuite, votre résolveur peut parler à des résolveurs en amont ou à des serveurs faisant autorité en utilisant :

• DNS en clair (acceptable sur des réseaux contrôlés, mais moins privé)
• DoT vers l’amont (bon compromis)
• DNS over QUIC (émergent ; à considérer comme « labo de test » sauf si vous avez confiance)

Stratégie de contrôle côté client

• Postes gérés : configurer DoH/DoT au niveau OS vers vos résolveurs ; verrouiller le « secure DNS » du navigateur vers le résolveur système ou l’endpoint d’entreprise.
• Postes non gérés / BYOD : vous pourriez avoir besoin de contrôles réseau (filtrage d’egress, politiques de portail captif, NAC) et d’une procédure documentée « si vous voulez l’accès, utilisez notre DNS ».

Ne confondez pas « bloquer DoH public » avec « résoudre le problème »

Bloquer des points de terminaison DoH connus par IP ou SNI, c’est un jeu du chat et de la souris. Cela peut réduire le risque rapidement, mais ce n’est pas durable
à mesure que l’Internet évolue vers l’ECH et que les fournisseurs hébergent DoH derrière des CDN. La stratégie à long terme est le contrôle des postes et
la fourniture d’un meilleur chemin : votre propre résolveur sécurisé avec des performances comparables.

Blague n°2 : La manière la plus simple de trouver une dépendance non documentée est d’activer DoH et d’observer quelles applications internes commencent immédiatement à hurler.

Trois mini‑histoires d’entreprise venues du terrain

Mini‑histoire 1 : L’incident causé par une fausse hypothèse

Une entreprise de taille moyenne a diffusé une note « amélioration de la confidentialité » : « Activez Secure DNS dans votre navigateur. » Cela semblait inoffensif.
L’équipe sécurité appréciait l’idée. Le helpdesk aussi, car ça semblait réduire les problèmes Wi‑Fi.
Personne ne s’est demandé quel résolveur serait utilisé.

En une semaine, des applications web internes ont commencé à échouer pour des travailleurs distants sur VPN. L’échec était curieusement sélectif :
certains utilisateurs pouvaient atteindre intranet.corp, d’autres obtenaient des timeouts, et quelques‑uns étaient redirigés vers une page publique.
L’équipe réseau a vérifié les routes split‑tunnel et les paramètres DNS du VPN. Tout semblait correct.

La mauvaise hypothèse était simple : « Si vous êtes sur VPN, vous devez utiliser le DNS de l’entreprise. » Faux.
Les navigateurs envoyaient des requêtes DoH vers des résolveurs publics via le tunnel VPN (ou parfois en dehors, selon le routage client),
contournant les vues DNS internes. Les noms internes n’étaient pas résolus publiquement, donc ils échouaient. Certains noms existant publiquement
résolvaient vers des services publics, ce qui est une variante plus intéressante du problème.

La solution n’a pas été « désactiver DoH ». La solution a été de fournir un point de terminaison DoH d’entreprise, de configurer les navigateurs gérés pour l’utiliser,
et d’imposer sur les postes que le « secure DNS » utilise les résolveurs d’entreprise. Les zones internes sont redevenues cohérentes,
et l’équipe sécurité a récupéré la télémetrie DNS — au niveau du résolveur, pas sur le réseau.

Mini‑histoire 2 : L’optimisation qui a mal tourné

Une grande entreprise a décidé de réduire la latence DNS en déployant une couche de cache locale sur des routeurs de succursales.
L’idée : mettre en cache agressivement, réduire le trafic en amont, accélérer le chargement des pages. Quelqu’un a transformé l’honoration des TTL en suggestion.
Soudain, des domaines SaaS courants étaient mis en cache « assez longtemps ».

Puis un grand fournisseur SaaS a déplacé certains endpoints pendant un incident de leur côté. L’entreprise continuait de répondre avec des enregistrements A/AAAA obsolètes.
Les utilisateurs voyaient des échecs intermittents selon la succursale dans laquelle ils se trouvaient. Les journaux du résolveur semblaient propres.
Les captures de paquets semblaient propres. Tout était « correct » sauf la réalité.

La situation a empiré avec DoH : les navigateurs liés à un résolveur DoH public obtenaient des réponses fraîches, tandis que les dispositifs gérés utilisant le cache de succursale gardaient des réponses obsolètes.
Deux réalités, une seule entreprise. Chaque fil de débogage commençait par « Pour moi ça marche. »
Cette phrase devrait être considérée comme une substance dangereuse.

La correction a été ennuyeuse : respecter les TTL, garder des tailles de cache raisonnables et arrêter d’essayer d’être plus malin que les opérateurs faisant autorité.
Ajouter une surveillance côté résolveur pour des taux de hit cache anormalement élevés sur des domaines qui changent rapidement. La performance compte, mais la justesse est une fonctionnalité.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une organisation financière avait une règle : chaque changement DNS devait être mis en scène via une paire de résolveurs de test, avec un groupe canari de clients,
et avec une voie de rollback préapprouvée. Personne n’aimait ça. Ça ressemblait à de la paperasserie pour des paquets.

Ils ont introduit DoT pour les postes gérés, terminant sur leurs résolveurs internes, et ont conservé le DNS en clair comme fallback pour les appareils legacy.
Pendant le déploiement, un problème de connectivité amont a provoqué des échecs sporadiques de handshake TLS depuis un centre de données vers les listeners DoT.
Le groupe canari l’a vu en premier — faible rayon d’impact, alertes sonores.

Parce qu’ils disposaient d’instrumentation sur la latence des résolveurs, les taux d’erreur de handshake TLS et la répartition des clients par site, ils ont rapidement
isolé le problème à une mise à jour de politique de pare‑feu spécifique qui impactait les sessions TLS longue durée. Ils ont annulé cette politique spécifique,
pas le déploiement DoT entier. Les utilisateurs ont à peine remarqué.

Rien d’héroïque n’est arrivé. C’est pour ça que ça a fonctionné. Quand vous rendez les changements DNS ennuyeux, vous pouvez dormir.

Tâches pratiques : commandes, sorties et la décision à prendre

La manière la plus rapide d’arrêter de se disputer sur DoH/DoT est de collecter des preuves. Ci‑dessous des tâches éprouvées sur le terrain que vous pouvez exécuter sur des hôtes Linux
(ou dans des containers de dépannage) et quoi faire selon les résultats. Adaptez les noms d’hôtes et IP à votre environnement.

Task 1: Confirm which resolver the host is actually using

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.20.0.53
       DNS Servers: 10.20.0.53 10.20.0.54
        DNS Domain: corp.example

Signification : Le résolveur système pointe vers 10.20.0.53/10.20.0.54. Si les utilisateurs déclarent « DoH a cassé le DNS », mais que l’OS pointe vers les résolveurs d’entreprise, le contournement est probablement dans une application (navigateur) ou un client VPN.

Décision : Si les serveurs DNS sont publics ou inattendus, corrigez d’abord l’attribution DNS via DHCP/VPN. S’ils sont corrects, investiguez le DoH au niveau applicatif.

Task 2: Observe live DNS traffic to see if UDP/53 is even being used

cr0x@server:~$ sudo tcpdump -ni any '(udp port 53 or tcp port 53 or tcp port 853)' -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
12:01:11.120345 eth0  Out IP 10.20.10.15.38422 > 10.20.0.53.53: 1234+ A? intranet.corp.example. (38)
12:01:11.121004 eth0  In  IP 10.20.0.53.53 > 10.20.10.15.38422: 1234* 1/0/0 A 10.50.1.20 (54)
10 packets captured

Signification : Le DNS en clair a lieu. Si vous ne voyez rien sur 53/853 alors que les résolutions fonctionnent, DoH (443) est probablement en jeu.

Décision : Si vous devez faire respecter le DNS d’entreprise, passez à la politique endpoint/navigateur ou implémentez la détection réseau pour des motifs DoH.

Task 3: Test resolution against corporate resolver explicitly

cr0x@server:~$ dig @10.20.0.53 intranet.corp.example A +noall +answer
intranet.corp.example. 60 IN A 10.50.1.20

Signification : Le résolveur d’entreprise peut résoudre le nom interne. Si les utilisateurs ne le peuvent pas, le problème est le chemin client, pas les données serveur.

Décision : Si ceci fonctionne mais que les applications utilisateur échouent, recherchez les paramètres split‑DNS, le contournement DoH, ou les différences de domaine de recherche.

Task 4: Compare with a public resolver to detect split-horizon leakage

cr0x@server:~$ dig @1.1.1.1 intranet.corp.example A +noall +comments +answer
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 22110

Signification : Le résolveur public ne connaît pas le nom interne. Si des postes utilisent DoH public, les noms internes échoueront.

Décision : Fournissez DoH/DoT d’entreprise pour les clients gérés ; bloquez ou restreignez le DNS chiffré public lorsque la politique l’exige.

Task 5: Check whether systemd-resolved is configured for DoT

cr0x@server:~$ grep -R 'DNSOverTLS\|DNSSEC\|DNS=' /etc/systemd/resolved.conf /etc/systemd/resolved.conf.d 2>/dev/null
/etc/systemd/resolved.conf:DNS=10.20.0.53 10.20.0.54
/etc/systemd/resolved.conf:DNSOverTLS=opportunistic
/etc/systemd/resolved.conf:DNSSEC=allow-downgrade

Signification : DoT opportuniste signifie qu’il essaiera DoT quand c’est supporté, mais reviendra en arrière. C’est plus sûr pour la compatibilité, plus faible pour l’exigence « chiffrer absolument ».

Décision : Pour les réseaux gérés, préférez « strict » seulement si vos résolveurs sont toujours accessibles et surveillés.

Task 6: Verify DoT connectivity to your resolver endpoint

cr0x@server:~$ openssl s_client -connect dns.corp.example:853 -servername dns.corp.example -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = dns.corp.example
Verification: OK

Signification : Le handshake TLS réussit, le certificat vérifie. Si cela échoue, les clients DoT feront fallback (opportuniste) ou échoueront (strict).

Décision : Si la vérification échoue, corrigez certificats/SAN/chaîne. Si la connexion échoue, corrigez pare‑feu/NAT/MTU.

Task 7: Confirm your resolver is listening on 853 and/or 443

cr0x@server:~$ sudo ss -lntp | egrep '(:53|:853|:443)\s'
LISTEN 0      4096      0.0.0.0:53        0.0.0.0:*    users:(("unbound",pid=1442,fd=6))
LISTEN 0      4096      0.0.0.0:853       0.0.0.0:*    users:(("unbound",pid=1442,fd=8))
LISTEN 0      4096      0.0.0.0:443       0.0.0.0:*    users:(("caddy",pid=1310,fd=5))

Signification : Unbound sur 53/853, et un serveur web sur 443 (souvent utilisé comme frontend DoH). Si 853 n’écoute pas, DoT ne fonctionnera pas.

Décision : Assurez‑vous que les listeners correspondent à votre plan de déploiement ; ne publiez pas « DoT disponible » si ce n’est pas le cas.

Task 8: Measure resolver latency and detect packet loss symptoms

cr0x@server:~$ dig @10.20.0.53 www.example.com A +stats +tries=1 +timeout=1
;; Query time: 8 msec
;; SERVER: 10.20.0.53#53(10.20.0.53) (UDP)
;; WHEN: Tue Dec 31 12:05:22 UTC 2025
;; MSG SIZE  rcvd: 56

Signification : 8ms est sain pour un résolveur proche. Si vous voyez des timeouts ou des pics à 800ms+, vous avez des problèmes de chemin réseau, de surcharge ou de lenteur en amont.

Décision : Si les pics de latence coïncident avec les déploiements DoT/DoH, vérifiez le surcoût TLS, la réutilisation des connexions et la capacité des tables d’état du pare‑feu.

Task 9: Inspect whether clients are using public DoH endpoints (Linux host perspective)

cr0x@server:~$ sudo ss -tnp | awk '$4 ~ /:443$/ {print $5}' | head
34.120.54.55:443
104.16.249.249:443
1.1.1.1:443

Signification : Des connexions vers des plages CDN communes et des IP de résolveurs connus apparaissent. Ce n’est pas la preuve absolue de DoH (443 sert à tout),
mais c’est une piste.

Décision : Si vous voyez des connexions longues répétées vers des fournisseurs DoH connus lors d’incidents DNS, testez les paramètres de secure DNS du navigateur et les politiques d’entreprise.

Task 10: Check local stub resolver behavior and caching

cr0x@server:~$ resolvectl statistics
Transactions: 18234
Cache Hits:  12011
Cache Misses: 6223
DNSSEC Verdicts: secure=0 insecure=0 bogus=0 indeterminate=0

Signification : Un fort taux de cache hits est normal. Des verdicts DNSSEC à zéro suggèrent que le stub ne valide pas, ou que la validation est désactivée en amont.

Décision : Décidez où la validation DNSSEC doit avoir lieu (généralement sur les résolveurs récursifs d’entreprise). Vérifiez qu’elle est activée là‑bas, pas nécessairement sur chaque poste.

Task 11: Validate DNSSEC on the corporate resolver (from a client)

cr0x@server:~$ dig @10.20.0.53 dnssec-failed.org A +dnssec +noall +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1512

Signification : Un résolveur validant devrait retourner SERVFAIL pour des zones DNSSEC volontairement brisées.

Décision : Si vous obtenez un enregistrement A normal, votre résolveur ne valide pas DNSSEC. Décidez si c’est acceptable ; pour beaucoup d’entreprises, ce ne devrait pas être le cas.

Task 12: Identify whether a proxy is interfering with DoH (common in corporate networks)

cr0x@server:~$ curl -I --connect-timeout 3 https://dns.corp.example/dns-query
HTTP/2 405
server: caddy
date: Tue, 31 Dec 2025 12:07:11 GMT

Signification : Vous avez atteint le point de terminaison DoH. Un 405 est acceptable pour un mismatch GET/HEAD selon l’implémentation ; l’important est que TLS+HTTP fonctionne de bout en bout.

Décision : Si cela expire ou retourne une page de blocage proxy, corrigez les allowlists proxy ou les règles de contournement pour le point de terminaison DoH d’entreprise.

Task 13: Verify firewall egress policy for DoT

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain output {
    type filter hook output priority 0; policy accept;
  }
  chain forward {
    type filter hook forward priority 0; policy drop;
    tcp dport { 53, 853, 443 } accept
  }
}

Signification : La chaîne forward autorise 853. Si 853 n’est pas autorisé depuis les VLAN clients vers les VIP des résolveurs, DoT échouera.

Décision : Autorisez 853 uniquement vers vos résolveurs, pas vers tout Internet, sauf si vous aimez les contournements surprises.

Task 14: On the resolver, check for saturation (CPU, sockets, open files)

cr0x@server:~$ sudo pidstat -p $(pgrep -x unbound) 1 3
Linux 6.8.0 (dns01) 	12/31/2025 	_x86_64_	(8 CPU)

12:08:01 PM   UID       PID    %usr %system  %CPU  Command
12:08:02 PM  unbound   1442    38.00   6.00 44.00  unbound
12:08:03 PM  unbound   1442    41.00   7.00 48.00  unbound

Signification : Si votre résolveur utilise 50% CPU de façon soutenue, vous tenez le coup jusqu’à un certain point. Des pics soudains lors du déploiement DoH peuvent indiquer un surcoût TLS ou des inondations de requêtes.

Décision : Scalez horizontalement (plus d’instances), activez la réutilisation des connexions sur les frontends DoH, et rate‑limitez les clients abusifs plutôt que de pénaliser tout le monde.

Task 15: Confirm logs show the client subnet/source you expect (NAT hides sins)

cr0x@server:~$ sudo tail -n 5 /var/log/unbound/unbound.log
[1735646910] unbound[1442:0] info: 10.20.10.15 www.example.com. A IN
[1735646911] unbound[1442:0] info: 10.20.10.15 intranet.corp.example. A IN
[1735646912] unbound[1442:0] info: 10.20.10.15 api.vendor.example. AAAA IN

Signification : Vous pouvez attribuer des requêtes aux IP clients. Si tout vient d’une passerelle NAT, la valeur médico‑légale diminue.

Décision : Évitez le NAT entre clients et résolveurs quand c’est possible. Si inévitable, incluez des identifiants clients au niveau DoH (avec précaution) ou utilisez des résolveurs par site.

Guide de diagnostic rapide

Quand DoH/DoT est impliqué, la mémoire muscle habituelle du débogage DNS échoue parce que vous ne pouvez plus voir les requêtes sur UDP/53.
Ce playbook est conçu pour la réalité d’astreinte : trouvez le goulot d’étranglement en quelques minutes, pas en écrivant un roman dans le canal d’incident.

Première étape : déterminer si le client contourne le DNS d’entreprise

• Vérifiez les paramètres du résolveur OS (resolvectl status ou équivalent).
• Vérifiez la politique secure DNS du navigateur (géré vs activé par l’utilisateur).
• Cherchez l’absence de requêtes UDP/53 alors que la navigation « résout » encore (signe de DoH).

Pourquoi : Si le client n’utilise pas votre résolveur, rien d’autre que vous faites ne compte.

Deuxième étape : confirmer la reachabilité et la santé TLS vers le point de terminaison chiffré d’entreprise

• Pour DoT : openssl s_client -connect ...:853 (vérifier le certificat, le temps de handshake).
• Pour DoH : curl -I https://... (réponse HTTP, interférence proxy).

Pourquoi : La plupart des échecs DoT en entreprise ne sont pas des « bugs DNS ». Ce sont des problèmes TLS/certificats/politiques d’egress.

Troisième étape : valider la justesse du résolveur et le comportement en amont

• dig @resolver internal.name et dig @resolver external.name
• Vérifiez les pics de SERVFAIL ; testez DNSSEC sur un domaine volontairement mauvais
• Regardez l’UC du résolveur et les limites des descripteurs de fichiers

Pourquoi : Si le résolveur est surchargé ou mal configuré, le chiffrement rend simplement la panne plus difficile à voir.

Quatrième étape : isoler les problèmes de chemin réseau (MTU, tables d’état, proxies)

• Les problèmes MTU apparaissent comme des échecs de handshake TLS ou des blocages intermittents.
• L’épuisement des tables d’état du pare‑feu se traduit par des échecs aléatoires sur de nombreux clients.
• Les timeouts proxy se manifestent par des requêtes DoH échouant uniquement depuis le réseau interne.

Erreurs courantes (et comment elles échouent en production)

1) Symptom: Internal names fail only in browsers; OS tools work

Cause racine : DoH du navigateur activé vers un résolveur public ; l’OS utilise toujours le DNS d’entreprise.

Correction : Imposer une politique de navigateur : « utiliser le résolveur système » ou « utiliser le point de terminaison DoH d’entreprise ». Fournir un service DoH d’entreprise fonctionnel hors VPN et sur VPN.

2) Symptom: Random DNS failures after enabling DoT “strict”

Cause racine : Mismatch de certificat (SAN incorrect), chaîne intermédiaire manquante, ou pare‑feu bloquant intermittente le port 853.

Correction : Corrigez la PKI d’abord. Puis autorisez 853 uniquement vers vos résolveurs. Ajoutez de la surveillance sur le taux de réussite des handshakes TLS.

3) Symptom: Some sites load slowly; resolver latency looks fine

Cause racine : DoH via un proxy ajoute du head‑of‑line blocking ou du churn de connexions ; réutilisation HTTP/2 non fonctionnelle ; proxy inspecte et retarde.

Correction : Contournez le proxy pour le point de terminaison DoH d’entreprise. Assurez la persistance et HTTP/2. Envisagez DoT si les proxies sont inévitables.

4) Symptom: Security team loses DNS visibility overnight

Cause racine : Les clients sont passés silencieusement à DoH public (mise à jour du navigateur, fonctionnalité OS), contournant les résolveurs et les journaux d’entreprise.

Correction : Gestion des endpoints : désactiver DoH public, configurer DoH/DoT d’entreprise. Réseau : restreindre l’egress vers des points DoH connus si nécessaire, mais considérez cela comme temporaire.

5) Symptom: Split‑horizon answers are inconsistent between subnets

Cause racine : Piles de résolveurs multiples (caches de succursales, résolveurs centraux, DoH public) avec règles de transfert et caches différents.

Correction : Consolidez la politique : un seul service résolveur avec vues cohérentes ; conservez des résolveurs de succursale mais gérés centralement ; arrêtez le « caching créatif ».

6) Symptom: High SERVFAIL rate to external domains only

Cause racine : Échecs de validation DNSSEC à cause de domaines amont cassés, d’une heure incorrecte, ou de fragments UDP/TCP fallback bloqués.

Correction : Assurez que TCP/53 est autorisé en sortie depuis les résolveurs. Vérifiez le NTP sur les résolveurs. Utilisez des réglages DNSSEC raisonnables ; ne désactivez pas globalement la validation parce qu’un domaine est cassé.

7) Symptom: DoH works off-network, fails on corporate LAN

Cause racine : Inspection SSL ou proxy bloque le point de terminaison DoH, ou un portail captif intercepte le 443 sur certains segments.

Correction : Autorisez/bypassez le point de terminaison DoH d’entreprise de l’interception. Si vous devez inspecter, terminez prudemment et préservez la sémantique — ou acceptez que vous cassez la confidentialité.

8) Symptom: Resolver CPU spikes after enabling DoH

Cause racine : Le surcoût TLS a été déplacé vers le résolveur sans plan de capacité ; ou le endpoint DoH n’a pas de réutilisation de connexion et ouvre trop de sessions.

Correction : Externalisez le TLS sur un frontend dédié avec keepalive ; scalez le pool de résolveurs ; implémentez des quotas et des limites par client.

Listes de contrôle / plan pas à pas

Étape 1 : Décidez de la position de l’entreprise (écrivez‑la)

• Fournissez‑vous un service DNS chiffré d’entreprise ? (Vous devriez.)
• Exigez‑vous le chiffrement hors‑réseau ? Sur‑réseau ?
• Quels journaux conservez‑vous, et pourquoi ? Qui y a accès ?
• Quelles zones internes ne doivent jamais fuir ?

Étape 2 : Construisez le service résolveur comme une dépendance de niveau‑0

• Résolveurs redondants par site ou région.
• Règles de forwarding et de split‑horizon cohérentes.
• Validation DNSSEC activée sur les résolveurs récursifs.
• RPZ/flux de menaces avec contrôle des changements et rollback.
• Tests de capacité : QPS, handshakes TLS, nombre de connexions.

Étape 3 : Ajoutez des endpoints DoT et/ou DoH — intentionnellement

• DoT sur 853 pour les clients gérés, plus simple à raisonner.
• DoH sur 443 pour les réseaux hostiles et environnements proxy lourds, mais faites‑en un service de première classe (surveillez‑le).
• Certificats d’une CA interne/publique de confiance selon le cas ; inclure les SAN corrects.
• Rendez les endpoints accessibles depuis le VPN et depuis Internet si la main d’œuvre distante en a besoin (avec considérations DDoS).

Étape 4 : Faites appliquer la politique côté endpoints

• DNS au niveau OS : définissez les résolveurs d’entreprise.
• Navigateur : forcez le « secure DNS » vers le endpoint d’entreprise ou le résolveur système.
• Empêchez l’override par l’utilisateur là où votre modèle de risque l’exige (environnements réglementés).

Étape 5 : Contrôles réseau (à utiliser avec parcimonie, mais soyez prêts)

• Autorisez DoT (853) seulement vers les résolveurs d’entreprise ; bloquez vers Internet si la politique l’exige.
• Pour DoH, privilégiez les contrôles endpoint ; utilisez la détection réseau comme filet de sécurité.
• Documentez les exceptions (Wi‑Fi invité, BYOD, laboratoires).

Étape 6 : Surveillance qui détecte les vraies pannes

• Résolveur : QPS, latence, taux SERVFAIL/NXDOMAIN, ratio hit cache, RTT amont.
• DoT : taux d’erreur de handshake TLS, nombre de sessions, alertes d’expiration de certificats.
• DoH : distribution des statuts HTTP, p95 de latence, codes d’erreur proxy, métriques de réutilisation de connexion.
• Expérience client : requêtes synthétiques pour noms internes et externes depuis chaque site.

Étape 7 : Plan de déploiement qui respecte le rayon d’impact

• Groupe canari (IT + quelques utilisateurs expérimentés).
• Expansion graduelle par site/région.
• Rollback : étapes claires pour restaurer la politique d’endpoint et le routage.
• Runbook d’incident : inclure « le client contourne‑t‑il le résolveur ? » comme première vérification.

FAQ

1) Les entreprises doivent‑elles autoriser DoH ?

Oui, mais pas en mode « chacun utilise le résolveur que son navigateur préfère ». Fournissez un endpoint DoH d’entreprise et gérez les clients pour l’utiliser.
Si vous ne pouvez pas gérer les clients, vous devrez peut‑être restreindre DoH public pour préserver le split‑horizon et les contrôles de sécurité.

2) DoT est‑il plus simple que DoH pour les réseaux d’entreprise ?

Généralement oui. Le port 853 est explicite, plus facile à filtrer et évite les bizarreries liées aux proxies. DoH est utile quand vous devez traverser des réseaux
qui bloquent 853, mais il est plus difficile à contrôler au niveau réseau.

3) Le DNS chiffré arrêtera‑t‑il les malwares ?

Non. Il empêche les observateurs passifs de lire le trafic DNS. Le malware peut toujours résoudre des noms — possiblement de manière plus fiable.
Votre atténuation est la politique au niveau du résolveur (si les clients l’utilisent), la sécurité des endpoints et les contrôles d’egress.

4) Si nous faisons DNSSEC, avons‑nous encore besoin de DoH/DoT ?

DNSSEC et DoH/DoT résolvent des problèmes différents. DNSSEC authentifie les réponses ; DoH/DoT cache les questions et réponses aux observateurs.
Vous voulez la validation DNSSEC sur vos résolveurs, que vous déployiez le chiffrement ou non.

5) Pouvons‑nous bloquer DoH public par SNI ?

Parfois, aujourd’hui. Moins fiable demain en raison de l’ECH et des schémas de fronting CDN. Considérez le blocage SNI comme une mesure de confinement à court terme,
pas comme une stratégie à maintenir sur des années.

6) DoH ne va‑t‑il pas casser notre journalisation DNS ?

Il casse la journalisation « on‑path », sur laquelle vous ne devriez de toute façon pas compter. Il ne casse pas la journalisation du résolveur si les clients utilisent votre résolveur.
Déplacez la visibilité vers la couche résolveur et conservez la rétention en accord avec les besoins légitimes de sécurité/ops.

7) Qu’en est‑il du Wi‑Fi invité et du BYOD ?

Décidez ce que vous optimisez. Si les invités ne doivent pas atteindre de ressources internes, vous pouvez les laisser utiliser un DNS/DoH public.
S’ils ont besoin d’accès interne, traitez‑les comme gérés ou forcez‑les via une méthode d’accès contrôlée (NAC/VDI/VPN).

8) Comment empêcher la fuite de domaines internes vers des résolveurs publics ?

La réponse fiable est la configuration côté endpoint : assurez‑vous que les suffixes internes se résolvent via les résolveurs d’entreprise, et configurez DoH/DoT vers vos endpoints.
Le blocage réseau aide mais ne sera jamais parfait si les clients peuvent encapsuler sur 443.

9) Est‑il risqué d’exploiter notre propre endpoint DoH ?

C’est un service de production, donc oui, il y a des risques. Mais c’est aussi un point de contrôle sur lequel vous comptez déjà (le DNS).
Si vous ne l’exploitez pas, quelqu’un d’autre le fera — pour vos endpoints — sans tenir compte de vos besoins split‑horizon ou de réponse aux incidents.

10) Quel est le « moindre mal » par défaut pour un environnement mixte ?

Des résolveurs récursifs d’entreprise avec validation DNSSEC, transfert de zones internes cohérent, DoT « opportuniste » pour les endpoints gérés,
plus un endpoint DoH d’entreprise pour les navigateurs et les réseaux hostiles. Ensuite resserrez en « strict » là où la surveillance prouve que c’est sûr.

Conclusion : prochaines étapes qui ne vous feront pas honte plus tard

DoH et DoT ne sont pas de simples interrupteurs de confidentialité. Ils déplacent votre plan de contrôle DNS du réseau vers l’endpoint et le résolveur.
Si vous ne fournissez pas un service DNS chiffré de qualité entreprise, vos utilisateurs en adopteront un par accident — via une mise à jour de navigateur,
un basculement OS, ou un article enthousiaste — puis vous le déboguerez à 2 h du matin avec la moitié de votre télémetrie manquante.

Prochaines étapes pratiques :

1. Inventaire : identifiez où le DNS est résolu aujourd’hui (OS, navigateurs, clients VPN, caches de succursale).
2. Construire : déployez des résolveurs récursifs d’entreprise redondants avec validation DNSSEC et règles split‑horizon cohérentes.
3. Chiffrer : ajoutez des endpoints DoT et/ou DoH avec une vraie surveillance (taux de handshake, latence, codes d’erreur).
4. Contrôler : imposez des politiques endpoint et navigateur pour utiliser le DNS chiffré d’entreprise, pas des endpoints publics.
5. Contenir : utilisez les blocages réseau avec parcimonie pour DoT public et des endpoints DoH ciblés lorsque la politique l’exige, mais ne prétendez pas que c’est permanent.
6. Répéter : effectuez des exercices de défaillance — certificat expiré, surcharge de résolveur, panne amont — pour que la première fois ne soit pas en production.

Si vous faites cela correctement, les utilisateurs obtiennent de la confidentialité sur des réseaux hostiles, les équipes sécurité gardent une visibilité DNS utile,
et les applications internes ne s’effondrent pas. L’objectif n’est pas de « gagner » contre le chiffrement. L’objectif est d’exploiter un réseau où le chiffrement est normal et où vos contrôles fonctionnent toujours.