DoH/DoT : l’amélioration de confidentialité qui casse le DNS à horizon partagé (correctif inclus)

Ce qui casse réellement : DNS à horizon partagé vs DNS chiffré

Le DNS à horizon partagé est une astuce ancienne et ennuyeuse qui fonctionne parce que le choix du résolveur par le client est prévisible. Vous publiez des réponses différentes
pour un même nom selon l’origine de la requête. À l’intérieur du réseau, app.corp.example résout sur une adresse RFC1918.
À l’extérieur, il résout sur une adresse publique ou NXDOMAIN. Ce n’est pas de la « sécurité » en soi, mais c’est absolument un mécanisme sur lequel reposent de nombreux contrôles de sécurité
et des designs de routage.

Le DNS chiffré change la relation avec le résolveur. Avec DoH/DoT, le trafic DNS est encapsulé dans TLS et—plus important—les clients peuvent
choisir des résolveurs hors de votre contrôle. Cela signifie :

• Vos zones internes pourraient ne jamais être consultées.
• Vos forwarders conditionnels pourraient ne jamais s’exécuter.
• Vos contrôles d’accès basés sur DNS (listes autorisées/bloquées, sinkholes, télémétrie de sécurité) pourraient ne rien voir.
• Le « poussez ces serveurs DNS et ces domaines de recherche » du VPN devient plus une suggestion qu’une obligation.

L’idée reçue courante est « DoH/DoT, c’est juste du chiffrement ; ça ne change pas le DNS. » En pratique, cela change qui répond. C’est ça qui casse.
Le gain en confidentialité et la perte opérationnelle sont le même événement.

DoT vs DoH en termes opérationnels

DoT tourne typiquement sur TCP/853 vers un résolveur. Ça ressemble à « un protocole DNS avec TLS ». Il est souvent configuré au niveau de l’OS
(le « Private DNS » d’Android est un exemple célèbre). On l’identifie plus facilement par le port, mais il n’est pas toujours simple à intercepter de façon responsable.

DoH circule sur HTTPS (TCP/443) et utilise un format requête/réponse HTTP. C’est « le DNS déguisé en trafic web », et ce n’est même pas une insulte—c’est précisément l’idée.
Il se fond dans le trafic. Il profite de l’infrastructure HTTPS et des middleboxes existants. Il contourne aussi beaucoup de contrôles réseau parce qu’il ressemble à toute autre requête web.

La défaillance du split-horizon provient généralement d’un de ces schémas :

1. DoH du navigateur qui prend le pas sur le DNS de l’OS. Votre résolveur OS pointe vers le DNS du VPN, mais le navigateur envoie des requêtes vers un endpoint DoH public.
2. DoT au niveau de l’OS configuré vers un résolveur public. Le poste est « sécurisé mais erroné » toute la journée.
3. Double pile de résolveurs en compétition. Le client essaye plusieurs résolveurs ; le public gagne à cause de la latence et met en cache la mauvaise réponse.
4. Portail captif / infrastructure d’interception créent des cas limites. Le client voit des échecs TLS, bascule, et vous vous retrouvez avec de la non‑déterminisme.

Une petite blague, parce qu’on l’a bien méritée : le DNS chiffré, c’est comme chuchoter votre question dans un mégaphone pointé vers le service d’assistance de quelqu’un d’autre.
Privé ? Oui. Utile ? Ça dépend de qui répond.

Faits et historique utiles pour les discussions avec sécurité et produit

Ce ne sont pas des anecdotes de quiz. C’est le type de contexte que vous utilisez pour prendre une décision dans une revue de changement sans besoin d’un débat de deux heures.

1. Les problèmes de confidentialité DNS préexistent à DoH/DoT depuis des décennies. « Le DNS est en clair » a toujours été vrai ; ce qui a changé, c’est que les navigateurs et les OS ont commencé à agir en conséquence.
2. DoT (RFC 7858) est arrivé avant DoH (RFC 8484). La première réponse standard de l’industrie était « TLS sur un port DNS-spécifique », pas « HTTP partout ».
3. Les navigateurs ont popularisé le choix du résolveur comme fonctionnalité produit. Cela a déplacé la sélection du résolveur des opérateurs de réseau vers les éditeurs d’applications.
4. Le DNS à horizon partagé est plus ancien que la plupart des produits VPN utilisés aujourd’hui. La technique précède de loin le marketing « zero trust ».
5. Le DNS d’entreprise n’est pas juste nom→IP. C’est souvent le plan de distribution pour la découverte de services, les enregistrements SRV, et les flux de validation de certificats internes.
6. DNSSEC n’encrypte pas. Il authentifie les réponses, mais ne masque pas les requêtes et n’empêche pas l’observation en chemin des noms interrogés.
7. EDNS Client Subnet (ECS) a parfois dégradé la confidentialité pour certains utilisateurs. Il peut divulguer des informations réseau client aux serveurs autoritaires pour améliorer le routage CDN.
8. Certaines plateformes implémentent un DNS chiffré « opportuniste ». Si le résolveur le supporte, il est utilisé ; sinon, repli silencieux. Cela peut créer un comportement dépendant de l’environnement.
9. Les résolveurs ne se valent pas. Différents résolveurs récursifs ont des politiques de cache, des filtrages et des caches négatifs différents. Vous pouvez obtenir des réponses différentes pour un même nom.

La conclusion opérationnelle : DoH/DoT n’a pas été inventé pour ennuyer les entreprises. Il a été inventé parce que le DNS en clair est une responsabilité. Votre travail est de
conserver cette amélioration de confidentialité sans laisser les logiciels endpoints choisir aléatoirement votre plan de contrôle.

Modes de défaillance : comment ça se manifeste en production

1) Les noms internes résolvent sur des IP publiques (ou pas du tout)

La panne classique du split-horizon : jira.corp.example résout sur quelque chose de public, ou NXDOMAIN, parce que le résolveur public ne connaît pas votre zone interne.
Votre DNS interne aurait renvoyé 10.30.4.17. À la place vous n’obtenez rien — ou pire, un nom CDN public non intentionnel.

Cela affecte fortement les utilisateurs VPN car ils s’attendent à ce que « les noms internes fonctionnent lorsque le VPN est actif ». Mais si le résolveur du client contourne le VPN,
le VPN n’est plus qu’un routeur sophistiqué sans idée du nom que vous avez tapé.

2) SSO et validation de certificats partent en vrille

Les applis internes s’appuient souvent sur des CA internes, des répondeurs OCSP internes, des IdP internes, et des points de service dont les noms existent uniquement en interne.
Si le poste interroge un résolveur externe et obtient NXDOMAIN, vous voyez :

• Boucles de redirection SSO (le hostname IdP ne résout pas)
• « Impossible de valider le certificat » (endpoints OCSP/CRL inaccessibles)
• Échecs partiels bizarres où l’appli se charge mais l’authentification échoue

3) Les contrôles de sécurité basés sur DNS perdent en visibilité

Si votre programme de sécurité dépend des logs DNS, du blocage, du sinkholing ou de la détection d’anomalies, DoH peut percer un trou. Pas parce que le chiffrement est mauvais,
mais parce que la requête n’atteint jamais votre résolveur. La première fois que vous l’apprenez sera pendant un incident, ce qui est un moment terrible pour apprendre quoi que ce soit.

4) « Ça ne casse que sur certains ordinateurs portables » (le pire cas)

La diversité des endpoints transforme cela en cauchemar. Un utilisateur a Android Private DNS réglé sur un résolveur public. Un autre utilise un navigateur avec DoH activé.
Un autre est sur une build gérée où vous avez désactivé DoH, mais leur client VPN a sa propre pile DNS. Vous obtenez un mélange de comportements qui ressemble à un réseau instable.

5) Kubernetes / service mesh ajoute une couche de confusion supplémentaire

Dans les clusters, vous avez déjà CoreDNS, des stub domains et la découverte de services en-cluster. Si des nœuds ou pods commencent à utiliser DoH/DoT externes, vous pouvez obtenir
une résolution différente entre l’hôte et le pod, ou entre des pods sur différents nœuds. Déboguer le « DNS » devient déboguer trois piles DNS à la fois.

Mode opératoire de diagnostic rapide (vérifier 1/2/3)

Quand des noms internes cassent, ne commencez pas par des captures de paquets. Commencez par prouver quel résolveur répond réellement et si le client contourne le chemin prévu.
L’objectif est de réduire le problème à : mauvais résolveur, bon résolveur mais mauvaise réponse, ou bonne réponse mais le trafic ne peut pas l’atteindre.

Vérifier 1 : Identifier le résolveur réellement utilisé

• Sur le client, vérifiez les serveurs DNS configurés (interface VPN vs interface Wi‑Fi).
• Vérifiez si le navigateur ou l’OS utilise DoH/DoT vers un résolveur externe.
• Vérifiez avec une requête ciblant explicitement votre résolveur interne et comparez.

Vérifier 2 : Comparer les réponses interne vs externe

• Interrogez le résolveur interne pour le nom en échec.
• Interrogez un résolveur public connu pour le même nom.
• Si les réponses diffèrent, votre split-horizon fonctionne — et le client choisit le mauvais horizon.

Vérifier 3 : Valider le chemin et la politique

• Si le client utilise correctement le DNS interne, vérifiez le forwarding, les vues et les ACLs sur le résolveur.
• Vérifiez les règles de firewall : le client est‑il autorisé à atteindre le DNS interne sur 53/udp et 53/tcp ?
• Vérifiez les interceptions DNS sur les réseaux invités ou les appliances « sécurité » qui réécrivent le DNS.

Ce n’est qu’après ces trois vérifications que vous creusez dans les caches, les TTL négatifs, le comportement EDNS, et les choses vraiment amusantes.

Tâches pratiques : commandes, sorties et la décision que vous prenez

Ce sont les tâches que j’exécute réellement pendant les incidents. Chacune contient : commande, sortie d’exemple, ce que cela signifie, et la décision qu’elle entraîne.
Adaptez les noms d’hôtes et adresses IP à votre environnement.

Task 1: See which DNS servers systemd-resolved thinks you’re using (Linux)

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 1.1.1.1
        DNS Domain: corp.example

Link 2 (wg0)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.20.0.53
       DNS Servers: 10.20.0.53
        DNS Domain: corp.example

Signification : Vous avez à la fois un résolveur interne (10.20.0.53) et un résolveur public configuré (1.1.1.1).
Même si wg0 semble correct, certains résolveurs vont rivaliser ou basculer.

Décision : Supprimez les résolveurs publics des postes gérés quand le split-horizon est requis, ou imposez le routage par domaine avec un résolveur local stub.

Task 2: Check if systemd-resolved is using DNS-over-TLS

cr0x@server:~$ resolvectl dnsovertls
Global setting: no
Link 2 (wg0): no
Link 3 (wlp0s20f3): no

Signification : DoT n’est pas activé ici. Si vous voyez quand même des cassures du split-horizon, cherchez du DoH côté navigateur ou un agent tiers.

Décision : Orientez vos investigations vers les réglages du navigateur, les logiciels de sécurité endpoint, ou la fonctionnalité Private DNS sur Android/iOS.

Task 3: Compare answers from internal vs public resolvers (dig)

cr0x@server:~$ dig +short jira.corp.example @10.20.0.53
10.30.4.17

cr0x@server:~$ dig +short jira.corp.example @1.1.1.1

Signification : Le résolveur interne renvoie l’IP privée ; le résolveur public ne renvoie rien (NXDOMAIN ou vide pour politique).

Décision : Ce n’est pas un incident « application indisponible ». C’est un problème de sélection du résolveur. Corrigez le routage du résolveur côté client, pas l’appli.

Task 4: Confirm whether a browser is doing DoH by observing connections (Linux)

cr0x@server:~$ sudo ss -tpn | grep -E ':443' | head
ESTAB 0 0 192.168.1.50:52114 104.16.248.249:443 users:(("firefox",pid=2148,fd=91))
ESTAB 0 0 192.168.1.50:52122 8.8.8.8:443 users:(("firefox",pid=2148,fd=93))

Signification : Le navigateur parle à des IP publiques sur 443. C’est normal pour le web. La question est de savoir si l’une d’elles est un endpoint DoH.
Si vous suspectez DoH vers un fournisseur spécifique, corrélez avec les IP d’endpoints connues de votre allowlist/intel, ou inspectez SNI/chemins HTTP dans un environnement contrôlé.

Décision : Si c’est un poste d’entreprise géré, désactivez DoH dans le navigateur via politique ou pointez‑le vers votre service DoH interne.

Task 5: Confirm DNS queries are hitting your resolver (tcpdump on resolver)

cr0x@server:~$ sudo tcpdump -ni eth0 port 53 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:41:11.225318 IP 10.20.14.22.52433 > 10.20.0.53.53: 12345+ A? jira.corp.example. (35)
12:41:11.225902 IP 10.20.0.53.53 > 10.20.14.22.52433: 12345* 1/0/0 A 10.30.4.17 (51)

Signification : Au moins un client utilise votre résolveur pour ce nom. Si l’utilisateur indique toujours un échec, le problème peut être le cache sur le client,
un résolveur différent utilisé de façon intermittente, ou le routage/firewall vers l’IP renvoyée.

Décision : Si vous ne voyez aucune requête pendant un test utilisateur, le client contourne votre résolveur (DoH/DoT ou serveur DNS différent).

Task 6: Check for DoT traffic (TCP/853) leaving a client subnet (firewall or host)

cr0x@server:~$ sudo tcpdump -ni eth0 tcp port 853 -c 3
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:42:09.114220 IP 10.20.14.22.48932 > 9.9.9.9.853: Flags [S], seq 366451, win 64240, options [mss 1460,sackOK,TS val 248490 ecr 0,nop,wscale 7], length 0

Signification : Ce client tente du DoT vers un résolveur public. Si votre split-horizon dépend du DNS interne, c’est une cause directe.

Décision : Bloquez les sorties 853 depuis les réseaux d’entreprise (avec exceptions pour votre propre service DoT), et appliquez la politique sur les endpoints.

Task 7: Inspect Windows DNS server selection (PowerShell)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -AutoSize"
InterfaceAlias ServerAddresses
-------------- --------------
Wi-Fi          {192.168.1.1}
CorpVPN        {10.20.0.53, 10.20.0.54}

Signification : Le Wi‑Fi a son propre DNS (souvent le routeur domestique), et le VPN a un DNS interne. Windows préfère typiquement l’interface VPN pour le DNS quand elle est bien configurée,
mais les métriques et les règles NRPT comptent.

Décision : Confirmez les métriques d’interface et ajoutez des règles de résolution de noms pour que corp.example utilise toujours le résolveur VPN.

Task 8: Check Windows Name Resolution Policy Table (NRPT)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-DnsClientNrptRule | Select-Object Namespace,NameServers,DirectAccess | Format-List"
Namespace    : .corp.example
NameServers  : {10.20.0.53, 10.20.0.54}
DirectAccess : False

Signification : Les requêtes pour *.corp.example doivent aller vers les résolveurs internes indépendamment de la configuration DNS générale.

Décision : Si absent, ajoutez NRPT (via GPO/MDM). C’est l’un des moyens les plus propres de préserver le split-horizon sur une flotte Windows.

Task 9: Confirm macOS resolver domains and order

cr0x@server:~$ scutil --dns | sed -n '1,80p'
DNS configuration

resolver #1
  search domain[0] : corp.example
  nameserver[0] : 10.20.0.53
  nameserver[1] : 10.20.0.54
  if_index : 12 (utun3)
  flags    : Request A records
  reach    : 0x00000002 (Reachable)

resolver #2
  nameserver[0] : 192.168.1.1
  if_index : 6 (en0)
  reach    : 0x00000002 (Reachable)

Signification : Le résolveur VPN est scindé sur corp.example. C’est bien. Si des utilisateurs échouent encore, suspectez un DoH applicatif ou un résolveur qui n’honore pas les domaines scindés.

Décision : Conservez les résolveurs scindés ; déployez un profil DoH géré si vous avez besoin d’un DNS chiffré sans perdre le split-horizon.

Task 10: Test whether the internal resolver can recurse and forward correctly

cr0x@server:~$ dig +nocmd +noall +answer www.example.net @10.20.0.53
www.example.net.  300  IN  A  93.184.216.34

Signification : Le résolveur interne peut atteindre les upstreams et répondre pour des noms internet. S’il ne peut pas, les clients peuvent « aider » en basculant vers des résolveurs publics.

Décision : Réparez l’egress et la latence du résolveur interne. Si le DNS interne est lent ou instable, l’adoption de DoH multiplie les incidents.

Task 11: Check BIND view/ACL logic (named-checkconf)

cr0x@server:~$ sudo named-checkconf -z /etc/bind/named.conf
zone corp.example/IN: loaded serial 2026020401
zone 0.20.10.in-addr.arpa/IN: loaded serial 2026020401
zone example.com/IN: loaded serial 2026011502

Signification : La configuration se parse et les zones chargent. Cela ne prouve pas que la bonne vue correspond au client, mais élimine « erreur de saisie » comme cause immédiate.

Décision : Si les zones chargent mais que les clients obtiennent de mauvaises réponses, validez la correspondance de vue par IP source et testez depuis plusieurs sous‑réseaux.

Task 12: Validate Unbound forwarding and local-zone behavior

cr0x@server:~$ sudo unbound-control status
version: 1.17.1
verbosity: 1
threads: 4
modules: 2 [ validator iterator ]
uptime: 86400 seconds
options: control(yes)

cr0x@server:~$ sudo unbound-control list_local_zones | grep corp.example
corp.example. transparent

Signification : Unbound est opérationnel et a une entrée local-zone pour le domaine interne. « transparent » signifie qu’il résoudra en utilisant local-data si présent, sinon il recurse/forward.

Décision : Si vous exigez un comportement strict interne seulement, préférez « static » ou utilisez des local-data explicites et bloquez la fuite vers la récursion publique.

Task 13: Spot negative caching hurting you (dig +trace and SOA TTL)

cr0x@server:~$ dig jira.corp.example @1.1.1.1 +noall +authority
corp.example.  900  IN  SOA  ns1.public-dns.example. hostmaster.public-dns.example. 1 7200 900 1209600 900

Signification : Si un résolveur public renvoie un SOA dans la section authority pour NXDOMAIN, le TTL de cache négatif peut provoquer « ça continue d’échouer même après correction ».

Décision : Videz les caches sur le client/résolveur quand c’est possible, et réduisez les TTL négatifs sur les zones publiques que vous gérez si approprié.

Task 14: Detect clients bypassing DNS by checking resolver logs (example: BIND querylog)

cr0x@server:~$ sudo tail -n 3 /var/log/named/query.log
04-Feb-2026 12:44:11.112 client @0x7f0a3c: query: jira.corp.example IN A +E(0)K (10.20.14.22)
04-Feb-2026 12:44:11.114 client @0x7f0a3c: query: ocsp.corp.example IN A +E(0)K (10.20.14.22)
04-Feb-2026 12:44:11.116 client @0x7f0a3c: query: idp.corp.example IN A +E(0)K (10.20.14.22)

Signification : Vous pouvez confirmer quels clients interrogent réellement le DNS interne. Si un utilisateur reproduit une panne et vous ne voyez pas de lignes de log correspondantes,
son appareil ne vous interroge pas. C’est le fait clé dont vous avez besoin pour une conversation politique.

Décision : Traitez le contournement comme un problème de conformité des endpoints gérés, pas comme un « réglage du serveur DNS ».

Le correctif : conserver la confidentialité et le split-horizon

Le bon correctif dépend de votre modèle de menace et de votre tolérance à l’autonomie des endpoints. Mais le mauvais correctif est toujours le même :
prétendre que le DNS chiffré n’arrivera pas. Il est déjà là.

Voici l’objectif de conception : les clients doivent utiliser un DNS chiffré vers des résolveurs que vous opérez ou en qui vous avez explicitement confiance, et ils doivent utiliser
votre résolveur interne pour les domaines internes à chaque fois. Vous pouvez y parvenir par la politique, l’architecture, ou un mélange des deux.

Modèle A : Faites fonctionner vos propres endpoints DNS chiffrés (recommandé)

Si vous voulez le gain de confidentialité et que vous gérez un réseau sérieux, vous devriez fournir un service DNS chiffré :
DoT sur 853 et/ou DoH sur 443. Placez‑le proche des utilisateurs, anycastez‑le si possible, et loggez de façon responsable.

Ensuite, configurez les endpoints (via MDM/GPO) pour utiliser votre service DNS chiffré, pas un service public aléatoire.
Pour le split-horizon, votre résolveur doit appliquer la même logique de vues que votre DNS interne existant, ou il doit forwarder les zones internes au bon endroit.

Détail opérationnel important : vous avez besoin de planification de capacité et de supervision de la latence. Si votre endpoint DNS chiffré est plus lent que les résolveurs publics,
les clients et les applis vont « aider » en basculant. Ce n’est pas de la mauvaise volonté ; c’est l’expérience utilisateur.

Modèle B : Imposer le routage par domaine (NRPT / résolveurs scindés / split DNS)

Si vous ne pouvez pas centraliser complètement le choix du résolveur, imposez au moins le routage des domaines internes :
*.corp.example, *.svc.cluster.local et autres namespaces internes doivent aller vers des résolveurs internes.
C’est le rail minimal viable pour la sécurité du split-horizon.

• Windows : Les règles NRPT sont vos amies. Elles sont ennuyeuses, ce qui explique leur efficacité.
• macOS : résolveurs scindés via profils VPN ; vérifiez avec scutil --dns.
• Linux : systemd-resolved supporte les domaines par lien ; NetworkManager peut les pousser via le VPN.

Modèle C : Bloquez ce qu’il faut, mais n’imaginez pas que c’est « réglé »

Bloquer TCP/853 sortant réduit le contournement DoT. Bloquer DoH est plus difficile car il passe par HTTPS.
Vous pouvez bloquer des endpoints DoH connus, mais les listes évoluent et les CDN bougent.

Si vous choisissez de bloquer DoH au réseau, faites‑le en connaissance de cause :

• Vous jouerez au chat et à la souris à moins d’utiliser aussi la gestion des endpoints.
• Vous pourriez casser des services HTTPS légitimes si vous êtes trop large.
• Certaines applications retomberont sur du DNS en clair. Acceptable ou inacceptable selon votre politique.

Modèle D : Cessez d’utiliser des noms internes qui entrent en collision avec le DNS public

Une grande part de la douleur vient de namespaces internes mal séparés. Si vous utilisez des noms qui collident avec des domaines publics réels,
vous créez de l’ambiguïté même sans DoH. Le DNS chiffré rend simplement l’ambiguïté plus visible, plus vite.

Utilisez un sous‑domaine que vous contrôlez publiquement (comme corp.example) pour un usage interne. Évitez les TLD internes « fantaisie » et évitez les noms qui dépendent
du suffixe de recherche pour des systèmes critiques. Si vous devez conserver des noms hérités, traitez‑les comme une dette technique et planifiez la migration.

Modèle E : Rendez le DNS interne assez fiable pour que les utilisateurs ne cherchent pas d’alternatives

C’est la vérité peu glamour : les gens activent DoH/DoT parce que le DNS est un problème de confidentialité et parce que le DNS de leur FAI est souvent lent ou douteux.
Si votre DNS interne est lent, instable ou bloqué par vos propres règles de firewall, les utilisateurs vont le contourner.

Les bases de la fiabilité :

• Résolveurs redondants dans chaque site/région majeure.
• Politique de forwarding claire pour les zones internes et pour la récursion internet.
• Supervision : latence, taux de SERVFAIL, taux de NXDOMAIN, top QNAMEs, santé des upstreams.
• Contrôle de changement strict pour les délégations de zone et les enregistrements split-horizon.

Une citation, parce que c’est toujours vrai dans le monde DNS. Werner Vogels (idée paraphrasée) : « Tout échoue tout le temps ; concevez pour que les systèmes continuent à fonctionner. »

Deuxième petite blague, puis on revient au travail : le DNS à horizon partagé ressemble beaucoup aux organigrammes d’entreprise — tout le monde pense savoir qui répond, jusqu’à ce qu’il demande à la mauvaise personne.

Trois mini-récits d’entreprise issus du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a déployé un nouveau client VPN avec du « DNS sécurisé » dans le discours marketing. L’équipe réseau a supposé que cela signifiait « il utilise nos serveurs DNS,
mais chiffrés ». Ils l’ont approuvé rapidement car, franchement, ils en avaient assez des débats sur le DNS en clair et voulaient la victoire.

Deux semaines plus tard, des développeurs ont commencé à signaler que Git interne sur HTTPS échouait de façon intermittente avec des erreurs de certificat.
Le nom d’hôte résolvait parfois sur une IP interne, parfois sur une IP publique appartenant à un service complètement différent ayant un nom similaire.
Le navigateur affichait un mismatch de certificat, les utilisateurs passaient outre dans certains cas (parce que bien sûr ils le faisaient), et vous obtenez maintenant un incident accompagné de mauvaises habitudes.

La cause racine n’était pas TLS. Ce n’était pas le service Git. C’était le choix du résolveur. La fonction « DNS sécurisé » du client VPN activait DoH vers un résolveur tiers par défaut.
Quand le VPN était actif, le DNS interne fonctionnait encore pour certaines applis. Mais les navigateurs avec DoH devenaient cohérents-mais-avec-le-mauvais-résolveur, et les échecs paraissaient aléatoires parce que différentes applis utilisaient différentes piles.

Le correctif a été douloureusement simple et politiquement ennuyeux : ils ont désactivé le DoH tiers du client VPN et publié un endpoint DoH interne.
Ils ont ensuite écrit une politique d’une page : « Les appareils d’entreprise utilisent les résolveurs d’entreprise. Les appareils personnels sur le Wi‑Fi invité font ce qu’ils veulent. »
La vraie leçon était aussi simple : n’approuvez jamais du « DNS sécurisé » sans demander « sécurisé vers quel résolveur ? »

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation a tenté d’améliorer les performances pour les travailleurs distants en poussant un résolveur public comme DNS secondaire.
Le résolveur interne était joignable via le VPN, mais la latence était plus élevée depuis certaines régions. L’idée était : « si l’interne est lent, le public sera rapide, et seuls les noms internes ont besoin du DNS interne. »
Cette phrase contient la graine de l’incident.

Le premier signe de problème a été un pic de tickets helpdesk : « Certains outils internes sont en panne, mais seulement pour les personnes distantes. »
Les ingénieurs ont fait des tests rapides et ont vu que les résolveurs internes allaient bien. Les applis étaient up. Le VPN était up. Pourtant la résolution de noms était incohérente.
Certains clients résolvaient api.corp.example vers une IP interne, d’autres obtenaient NXDOMAIN.

Le retournement est venu du comportement de course entre résolveurs et du cache. Certains clients interrogeaient les deux résolveurs ; le public répondait plus vite avec NXDOMAIN,
qui fut mis en cache. Plus tard, même quand le résolveur interne aurait répondu correctement, le client n’a pas reposé la question — il faisait confiance au cache négatif.
Une « optimisation » de performance est devenue une panne de cohérence.

Le correctif a été de retirer les résolveurs publics de la configuration VPN et de déployer des résolveurs internes régionaux (ou forwarders) proches des utilisateurs.
Ils ont aussi revu les TTL de cache négatif quand ils en contrôlaient la valeur. La nouvelle règle : n’ajoutez jamais un « résolveur de secours » qui ne peut pas répondre à vos zones internes.
Ce n’est pas une sauvegarde. C’est une bifurcation de la réalité.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une grande entreprise avait déjà standardisé un namespace interne dédié (corp.example) et documenté les règles de forwarding conditionnel
entre leur DNS on‑prem et leurs zones privées cloud. Ils avaient aussi des politiques endpoint désactivant le DoH géré par le navigateur sauf s’il pointait vers le service DoH d’entreprise.
C’était ennuyeux. C’était aussi efficace.

Pendant un incident internet plus large affectant un réseau de résolveurs publics populaire, ils ont eu moins de problèmes que leurs pairs.
Leurs appareils d’entreprise ne dépendaient pas du DNS externe pour les noms internes, et leurs résolveurs internes avaient des upstreams redondants pour la récursion internet.
Les applis internes restèrent accessibles. Les utilisateurs VPN continuèrent à travailler. Le helpdesk eut une journée tranquille, ce qui est le plus proche d’un trophée pour les équipes ops.

Le moment décisif s’est produit en salle de crise : quelqu’un a suggéré « dites juste aux gens d’utiliser ce DNS public temporairement. »
L’équipe DNS a refusé — pas parce qu’elle était têtue, mais parce qu’elle avait déjà joué ce film et n’aimait pas la fin.
À la place, ils ont augmenté la capacité sur les résolveurs internes et resserré temporairement les règles egress qui autorisaient du DoT non géré.

Le postmortem fut court et presque ennuyeux : la pratique ennuyeuse (namespaces stables, forwarding documenté, politique endpoint) a réduit le rayon d’impact.
Tout n’a pas besoin d’une solution innovante. Parfois il suffit d’une politique qui survit à la réalité.

Erreurs courantes : symptôme → cause racine → correctif

1) Symptom: “VPN is connected but internal domains don’t resolve”

Cause racine : DoH du navigateur ou Private DNS de l’OS contourne le résolveur fourni par le VPN.

Correctif : Faites appliquer la politique endpoint : désactivez DoH/DoT tiers ou pointez‑les vers le DNS chiffré d’entreprise ; ajoutez des règles par domaine pour corp.example.

2) Symptom: “It works for ping, fails in browser”

Cause racine : Piles de résolveurs différentes. Les outils CLI utilisent le DNS de l’OS ; le navigateur utilise DoH.

Correctif : Alignez la politique de résolveur. Dans les environnements gérés, configurez centralement DoH du navigateur. Dans les environnements non gérés, publiez des recommandations et rendez les applis internes accessibles via le DNS public + auth si approprié.

3) Symptom: “Some users get NXDOMAIN for internal names after a change”

Cause racine : Cache négatif d’un résolveur public ou d’un forwarder interne renvoyant NXDOMAIN avec un TTL long.

Correctif : Videz les caches quand c’est possible ; réduisez les TTL négatifs sur les zones que vous gérez ; arrêtez d’envoyer des noms internes vers des résolveurs incapables d’y répondre.

4) Symptom: “DNS logs show nothing during user tests”

Cause racine : Contournement via DoH/DoT, résolveurs codés en dur, ou agent local.

Correctif : Identifiez le contournement : bloquez 853 sortant quand la politique le permet ; appliquez les réglages DoH ; utilisez la conformité endpoint pour détecter des configurations DNS non conformes.

5) Symptom: “Internal names sometimes resolve to public IPs”

Cause racine : Le split-horizon existe mais le client utilise de façon intermittente le mauvais horizon (DNS multi‑homme, comportement de course).

Correctif : Éliminez les résolveurs publics des configurations d’entreprise ; utilisez des domaines scindés/NRPT ; assurez‑vous que les résolveurs internes ont faible latence et haute disponibilité.

6) Symptom: “Security team sees drop in DNS telemetry”

Cause racine : DoH vers des résolveurs tiers ; le filtrage DNS sort de votre chemin.

Correctif : Fournissez DoH/DoT d’entreprise avec journalisation et politique ; faites appliquer l’usage des résolveurs via MDM/GPO ; envisagez des contrôles applicatifs qui ne supposent pas la visibilité DNS.

7) Symptom: “Kubernetes pods can’t resolve internal zones but nodes can”

Cause racine : Configuration DNS des pods ou cache local du nœud forwardant vers des résolveurs externes ; stub domains manquants.

Correctif : Configurez CoreDNS stubDomains/forward pour les zones internes ; assurez‑vous que les résolveurs node ne utilisent pas DoH/DoT publics pour les namespaces internes.

Listes de contrôle / plan pas à pas

Étapes pas à pas : stabiliser le split-horizon sous la pression DoH/DoT

1. Inventaire des namespaces internes. Listez les zones internes et les hostnames critiques. Si vous ne pouvez pas les lister, vous ne pouvez pas les protéger.
2. Décidez de la politique de résolveur. Choisissez une option : « résolveurs d’entreprise uniquement » (géré) ou « application de routage par domaine seulement » (hybride).
3. Déployez des endpoints DNS chiffrés d’entreprise. Proposez DoH/DoT comme service supporté avec HA, supervision et contrôle de changement.
4. Configurez les endpoints via MDM/GPO. Désactivez DoH/DoT tiers ; définissez les résolveurs d’entreprise ; appliquez NRPT / domaines scindés.
5. Bloquez TCP/853 sortant quand approprié. Autorisez des exceptions pour vos propres résolveurs. Documentez explicitement les exceptions.
6. Gérez DoH délibérément. Soit :
   • Autorisez DoH d’entreprise et bloquez les DoH tiers connus lorsque possible, ou
   • Autorisez DoH en général mais assurez‑vous que les domaines internes sont résolus via des canaux internes (NRPT / résolveurs scindés).
7. Rendez le DNS interne rapide. Ajoutez des forwarders régionaux, du caching et de la redondance. Supervisez latence et taux d’erreur.
8. Testez avec de vrais clients. Validez sur Windows/macOS/Linux plus au moins une plateforme mobile si vous la supportez.
9. Operationalisez : logs + tableaux de bord. Suivez le volume de requêtes par résolveur, SERVFAIL, NXDOMAIN et les domaines principaux. Surveillez les chutes soudaines (contournement).
10. Rédigez le runbook. Incluez le mode opératoire de diagnostic rapide et les 12+ tâches ci‑dessus. Vous vous remercierez plus tard.

Checklist pour revue de changement (logique imprimable)

• Ce changement affectera‑t‑il quel résolveur répond aux noms d’entreprise ?
• La solution prend‑elle en charge des vues split-horizon ou du forwarding conditionnel ?
• Avons‑nous une réponse pour DoH au niveau navigateur et DoT au niveau OS ?
• Que se passe‑t‑il en cas de défaillance partielle (comportement de repli) ?
• Avons‑nous des métriques de latence et d’erreurs sur les résolveurs d’entreprise ?
• Y a‑t‑il une politique explicite pour les appareils non gérés ?

FAQ

1) Is DoH “bad for enterprises”?

Non. Le DoH non géré est problématique pour les entreprises. Le DoH géré est acceptable, souvent meilleur. Le conflit porte sur le plan de contrôle, pas sur le chiffrement.

2) Should I block DoH everywhere?

Seulement si vous pouvez imposer une alternative qui satisfait confidentialité et fiabilité. Bloquer à l’aveugle provoque souvent un repli vers le DNS en clair ou pousse les utilisateurs vers des contournements.
Mieux : fournissez du DoH/DoT d’entreprise et gérez le choix du résolveur.

3) Why does split-horizon DNS exist if it’s so fragile?

Parce que c’est efficace et simple quand le chemin vers le résolveur est stable. Il devient fragile lorsque les endpoints choisissent des résolveurs dynamiquement ou contournent totalement le résolveur du réseau.
Cette fragilité est gérable avec des politiques et du routage par domaine.

4) Does DNSSEC solve this?

DNSSEC aide à vérifier l’authenticité des réponses DNS. Il n’encrypte pas les requêtes et n’empêche pas que les endpoints utilisent le mauvais résolveur.
Vous pouvez (et devriez souvent) utiliser DNSSEC en parallèle de DoH/DoT, mais ce n’est pas un substitut.

5) If I run internal DoH, do I still need split-horizon?

Si vous avez des endpoints internes uniquement, oui. DoH ne remplace pas le split-horizon ; il change le transport. Vous avez toujours besoin de vues / règles de forwarding pour que les noms internes résolvent correctement.

6) What’s the safest minimum fix if I can’t do a big project?

Imposer le routage par domaine pour les namespaces internes (NRPT / domaines scindés) et retirer les résolveurs publics des configurations gérées.
Puis bloquez TCP/853 sortant pour réduire le DoT non géré.

7) How do I handle mobile devices?

Traitez‑les comme une classe séparée. S’ils sont gérés, poussez un profil DNS et restreignez les réglages Private DNS. S’ils sont BYOD non gérés, ne présumez pas que le split-horizon fonctionnera.
Fournissez les applis internes via le DNS public avec une authentification forte, ou utilisez un conteneur/profil géré.

8) Why does adding a “backup” public DNS server cause outages?

Parce que ce n’est pas une sauvegarde pour les zones internes. Certains clients l’utiliseront en priorité en raison de la latence, des métriques d’interface ou de la logique de retry. Ensuite, le cache négatif rend la panne persistante.
Si un résolveur ne peut pas répondre à vos zones internes, ce n’est pas un secondaire sûr.

9) Can I rely on search domains instead of fully qualified names?

Pour la commodité, oui. Pour la fiabilité critique, non. Les domaines de recherche multiplient l’ambiguïté et créent des voies de fuite confuses lorsque les clients utilisent des résolveurs publics.
Utilisez des FQDN pour les services critiques et gardez les namespaces internes non ambigus.

10) What’s the best metric to detect DoH bypass?

Une chute soudaine du volume de requêtes vers vos résolveurs internes, en particulier depuis des réseaux où le nombre d’endpoints n’a pas changé.
Couplez cela avec des observations egress (TCP/853, endpoints DoH connus) et des rapports de conformité endpoint.

Conclusion : étapes suivantes exécutable cette semaine

DoH et DoT ne sont pas une mode passagère, et ce ne sont pas vos ennemis. C’est la direction par défaut de l’industrie : plus de chiffrement, plus d’autonomie endpoint, moins d’hypothèses sur le réseau.
Le DNS à horizon partagé fonctionne encore — si vous arrêtez de supposer que les clients vous interrogeront gentiment.

Étapes pratiques :

1. Exécutez le mode opératoire de diagnostic rapide sur un utilisateur en panne réel et documentez quel résolveur a répondu.
2. Retirez le « DNS public secondaire » des profils VPN et des configurations des endpoints gérés.
3. Implémentez le routage par domaine pour les namespaces internes (NRPT / résolveurs scindés) comme socle.
4. Planifiez et déployez des endpoints DoH/DoT d’entreprise, puis poussez‑les via MDM/GPO.
5. Surveillez la latence et les taux d’erreur des résolveurs ; traitez le DNS comme une infrastructure de production, parce que c’en est une.

La confidentialité est une victoire. La fiabilité est non négociable. Vous pouvez avoir les deux — mais seulement si vous concevez pour le DNS chiffré au lieu d’espérer qu’il ne remarquera pas votre split-horizon.