Debian 13 : DNS chiffré (TLS/HTTPS) — activer sans casser les réseaux d’entreprise (cas n°51)

Le DNS chiffré est une amélioration qui semble ennuyeuse jusqu’au moment où vous êtes de garde à 02:00 en train d’analyser une capture et que vous réalisez que la moitié du parc fuit des noms internes vers le Wi‑Fi sur lequel il s’est connecté. Vous voulez DNS over TLS (DoT) ou DNS over HTTPS (DoH) pour la confidentialité, l’intégrité et parfois simplement la fiabilité.

Les réseaux d’entreprise, cependant, ont des exigences : split‑horizon, résolveurs internes avec politique, proxys qui interceptent, clients VPN qui « aident », et les équipes conformité qui veulent savoir où partent vos requêtes. Debian 13 sait gérer proprement le DNS chiffré, mais il faut respecter l’environnement sinon vous créez une panne à retardement.

Ce que vous modifiez réellement (et ce que vous ne modifiez pas)

Sur Debian 13, la façon pratique de « activer le DNS chiffré » est de confier la résolution de noms à systemd-resolved et de lui indiquer soit :
a) vos résolveurs d’entreprise en DoT s’ils le supportent, ou
b) un forwarder DoH/DoT contrôlé que vous administrez (recommandé), ou
c) un résolveur public (seulement si la politique l’autorise et que vous assumez les conséquences).

La distinction clé : activer DoT/DoH sur un client ne répare pas magiquement le DNS. Cela change la sécurité de transport entre le client et son résolveur configuré. Si votre résolveur en amont utilise encore du DNS en clair, votre requête quitte ensuite votre réseau sans chiffrement. Cela peut être acceptable ; cela peut aussi être exactement le problème de conformité que vous vouliez résoudre.

De plus : chiffrer le DNS n’arrête pas le SNI, ECH, le suivi basé sur les adresses IP, ou le fait que quelqu’un peut toujours voir où vous vous connectez. Cela réduit simplement la fuite passive des requêtes DNS et rend certaines manipulations plus difficiles.

Avis pratique : en entreprise, ne pointez pas les postes directement vers des DoH publics au hasard. Exécutez un forwarder (ou mettez à niveau vos résolveurs internes) pour que la politique, la split‑horizon, la journalisation et la réponse aux incidents continuent de fonctionner.

Faits et contexte à répéter en réunion

• Le DNS a été conçu en assumant un réseau bienveillant. Le protocole de base est UDP/53, issu d’une mentalité des années 1983 : rapide, sujet à pertes, et facile à observer ou usurper.
• DNSSEC ajoute de l’intégrité, pas de la confidentialité. Il peut valider les réponses mais vos questions voyagent encore en clair à moins d’utiliser DoT/DoH.
• DoT standardisé par RFC 7858 (2016). C’est le DNS dans TLS, typiquement TCP/853, lisible comme du trafic « DNS-ish ».
• DoH standardisé par RFC 8484 (2018). C’est le DNS sur HTTPS, généralement TCP/443, qui peut se fondre dans le trafic web et contrarier les équipes firewall.
• Les navigateurs ont déclenché l’opposition en entreprise. Les déploiements « automatiques » de DoH dans les navigateurs ont cassé des zones internes dans beaucoup d’organisations, rendant les équipes réseau réticentes par défaut.
• Le split‑horizon DNS est une fonctionnalité, pas un bricolage. Des noms internes comme corp.example doivent résoudre différemment à l’intérieur et à l’extérieur ; le DNS chiffré n’enlève pas cette exigence, il amplifie les erreurs.
• Les portails captifs détestent le DNS chiffré. Si vous ne pouvez pas résoudre le nom du portail sans accepter d’abord les conditions, le DNS « intelligent » peut vous maintenir hors ligne.
• Beaucoup de résolveurs d’entreprise supportent déjà le chiffrement. Les versions modernes de BIND, Unbound et certains appliances DNS peuvent faire DoT/DoH — mais les certificats et la politique doivent être gérés délibérément.
• La journalisation centrale est souvent non négociable. Les équipes sécurité s’appuient sur les journaux DNS pour les enquêtes ; contourner les résolveurs internes peut être traité comme une violation de politique, pas comme de l’innovation.

DoT vs DoH : choisir l’outil adapté à votre réseau

DoT : prévisible, ami des firewalls (au sens entreprise)

DoT utilise un port distinct (853). C’est une bénédiction : vous pouvez l’autoriser quand c’est approprié, le bloquer quand la politique l’exige, et l’identifier dans les logs de flux sans prétendre que chaque session TLS est « juste du trafic web ».

Si votre entreprise a une frontière de sécurité où l’egress est strictement contrôlé, DoT est généralement plus facile à négocier. Vous pouvez prouver ce que c’est. Vous pouvez aussi le router vers un cluster de résolveurs interne et conserver la split‑horizon.

DoH : pratique, parfois politiquement radioactif

DoH circule sur HTTPS. C’est pratique pour les clients nomades car le 443 est presque toujours ouvert. C’est aussi pourquoi certains réseaux le considèrent comme « exfiltration DNS déguisée en navigation web ». Si votre proxy fait de l’inspection TLS, DoH peut casser de façons amusantes à moins que vous ne contrôliez les deux bouts.

Utilisez DoH quand vous avez un endpoint connu et géré (votre propre front‑end DoH, ou un fournisseur approuvé par l’entreprise) et que vous comprenez comment il se comporte avec les proxys, le mTLS et l’interception de certificats.

Vérité sèche : quand vous dites à l’équipe firewall que vous voulez « DNS over HTTPS », ils entendent « Je veux contourner la politique en catimini ». Ils n’ont peut‑être pas tort.

Modes de défaillance en entreprise : où le DNS chiffré meurt

Split‑horizon et domaines de recherche

Si les clients contournent les résolveurs internes, les zones internes échouent. Votre file de tickets se remplit de « le VPN est cassé » et « le serveur Git est inaccessible » alors que tout est techniquement « up ». La solution n’est pas « désactiver DoH », mais « arrêter de contourner le résolveur qui connaît les zones privées ».

Interception par proxy et découpe‑inspect TLS

Les proxys d’entreprise qui interceptent TLS peuvent faire échouer DoH de deux manières opposées : soit ils le bloquent purement et simplement, soit ils le MITM et présentent une CA d’entreprise que votre client DoH ne fait pas confiance. Si le client est strict (comme il devrait l’être), vous obtenez des timeouts et des comportements de fallback mystérieux.

Paramètres DNS du VPN écrasés

Les clients VPN poussent souvent des serveurs DNS et des domaines. Si vous forcez DoT/DoH au niveau OS et ignorez le DNS par lien, vous pouvez envoyer des requêtes pour des zones internes hors du tunnel. Félicitations, vous venez de créer une fuite de données et un incident de fiabilité en une seule manœuvre.

Middleboxes qui « aident » en réécrivant

Certains réseaux réécrivent les réponses DNS (portails captifs, contrôles parentaux, filtres anti‑malware). Si vous les contournez, vous contournez la fonctionnalité. Parfois c’est l’objectif. Parfois cette fonctionnalité est ce qui permet aux invités d’accéder à la page de connexion Wi‑Fi. Choisissez votre douleur.

Régressions de performance liées au handshake et au cache cassé

Les handshakes TLS ne sont pas gratuits. Avec une bonne réutilisation de connexion, le surcoût est mineur. Avec des réseaux mauvais, des connexions éphémères, ou des résolveurs mal réglés, vous pouvez ajouter une latence notable. Les gens remarquent la latence DNS car elle se manifeste par « Internet est lent » et personne ne crée un ticket précis.

Procédure de diagnostic rapide

Quand le DNS chiffré « ne fonctionne pas », ne devinez pas. Ne tournez pas de boutons au hasard. Exécutez toujours les mêmes trois vérifications pour trouver rapidement le goulot d’étranglement.

1. Première étape : confirmer qui fait le DNS et quels serveurs sont utilisés.
   Si le système utilise encore un ancien /etc/resolv.conf fourni par DHCP, aucune de vos options systemd-resolved ne compte.
2. Deuxième étape : confirmer la reachabilité du transport (853 pour DoT, 443 pour le endpoint DoH).
   Un port bloqué ressemble à un « timeout DNS » et fait perdre des heures sauf si vous le vérifiez immédiatement.
3. Troisième étape : confirmer la validation du certificat/SNI/nom (DoT surtout).
   Si le certificat du résolveur ne correspond pas à ce que le client attend, systemd-resolved va se dégrader silencieusement selon la configuration. Décidez si vous voulez le mode strict ou opportuniste, puis appliquez‑le.

Si ces trois points sont bons, les suspects restants sont : routage DNS conditionnel, interception proxy, échecs de validation DNSSEC, ou problèmes de performance/capacité côté résolveur.

Tâches pratiques : commandes, sorties et décisions

Ce sont les tâches de terrain que j’exécute réellement sur des hôtes Debian quand j’active DoT/DoH ou débogue pourquoi l’ordinateur d’un utilisateur ne résout pas git.corp.example sur le VPN.

Chaque tâche inclut : commande, sortie d’exemple, ce que cela signifie, et la décision que vous prenez.

Task 1 — Identify the active resolver stack

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Dec 30 09:12 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Signification : /etc/resolv.conf pointe vers le stub systemd, donc les applications interrogeront 127.0.0.53 et systemd-resolved fera le travail en amont.

Décision : Si vous ne voyez pas un lien symbolique vers le stub/real resolv.conf de systemd, corrigez cela d’abord ; sinon vous modifierez des paramètres que rien n’utilise.

Task 2 — Confirm systemd-resolved is running and authoritative

cr0x@server:~$ systemctl status systemd-resolved --no-pager
● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
     Active: active (running) since Tue 2025-12-30 09:10:21 UTC; 6min ago
       Docs: man:systemd-resolved.service(8)
   Main PID: 612 (systemd-resolve)
     Status: "Processing requests..."

Signification : Le service de résolution tourne.

Décision : S’il est inactive/désactivé, activez‑le correctement ou choisissez une autre pile de résolveur (Unbound, dnscrypt-proxy, etc.) — mais ne faites pas un demi‑actif des deux.

Task 3 — Inspect current DNS configuration per link (split DNS reality check)

cr0x@server:~$ resolvectl status
Global
       Protocols: +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (ens192)
    Current Scopes: DNS
         Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 10.20.30.40
       DNS Servers: 10.20.30.40 10.20.30.41
        DNS Domain: corp.example

Signification : Le DNS provient des serveurs d’entreprise sur cette interface ; DNS-over-TLS est actuellement désactivé.

Décision : Conservez le DNS par lien. Ne forcez pas une configuration globale sauf si vous êtes sûr de ne pas casser les domaines fournis par le VPN.

Task 4 — Verify that DoT/DoH capability exists in your systemd-resolved build

cr0x@server:~$ resolvectl --version
systemd 258 (258.2-1)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +BPF_FRAMEWORK
+IDN2 +XZ +ZSTD +BZIP2 +LZ4 +ACL +BLKID +CURL +ELFUTILS +FIDO2 +TPM2 +PWQUALITY +P11KIT
default-hierarchy=unified

Signification : Un systemd moderne est présent ; le support DoT est standard ici. Le support DoH dépend des options de compilation et de la version, donc vérifiez dans votre environnement Debian 13.

Décision : Si DoH est requis et que votre build ne l’inclut pas (ou si la politique exige un client DoH dédié), prévoyez un forwarder local comme Unbound faisant DoT en amont, ou un proxy DoH que vous gérez.

Task 5 — Check whether DNS is currently leaking to public resolvers

cr0x@server:~$ grep -vE '^\s*#|^\s*$' /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search corp.example

Signification : Les applications utilisent le stub local ; la sélection d’amont est masquée derrière resolved.

Décision : Si vous voyez ici une IP publique, vous contournez déjà le DNS d’entreprise. Décidez si c’est autorisé avant d’ajouter le chiffrement.

Task 6 — Prove basic resolution works before encrypting anything

cr0x@server:~$ resolvectl query debian.org
debian.org: 151.101.194.132 151.101.2.132 151.101.66.132 151.101.130.132
          -- Information acquired via protocol DNS in 21.5ms.
          -- Data is authenticated: no

Signification : Le DNS de base fonctionne. Ne changez pas le transport quand la base est déjà cassée.

Décision : Si ceci échoue, corrigez d’abord le routage/DHCP/DNS du VPN. Le DNS chiffré ne vous sauvera pas d’un problème de « mauvais serveur DNS ».

Task 7 — Enable DoT in systemd-resolved (opportunistic vs strict)

Éditez /etc/systemd/resolved.conf. Pour l’entreprise, commencez par DoT opportuniste si vous doutez des certificats, puis passez au strict.

cr0x@server:~$ sudoedit /etc/systemd/resolved.conf

cr0x@server:~$ grep -nE '^(DNS=|DNSOverTLS=|Domains=|FallbackDNS=)' /etc/systemd/resolved.conf
9:DNS=10.20.30.40#dns.corp.example 10.20.30.41#dns.corp.example
12:FallbackDNS=
15:Domains=~corp.example ~.
20:DNSOverTLS=opportunistic

Signification : Vous épinglez les résolveurs internes et fournissez le nom TLS attendu (#dns.corp.example) pour que la validation du certificat puisse fonctionner lorsque vous passez en strict. La ligne Domains= indique le routage DNS conditionnel : ~corp.example est routé vers ces serveurs ; ~. indique la route par défaut.

Décision : Utilisez opportunistic pour le premier déploiement. Passez à yes (strict) une fois que vous avez vérifié les certificats et les middleboxes.

Task 8 — Restart resolved and validate that the config is active

cr0x@server:~$ sudo systemctl restart systemd-resolved
cr0x@server:~$ resolvectl status | sed -n '1,25p'
Global
       Protocols: +LLMNR -mDNS +DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Signification : +DNSOverTLS indique que DoT est activé globalement. Cela ne garantit pas que chaque amont le supporte ; ça signifie que le client va essayer.

Décision : S’il affiche encore -DNSOverTLS, votre config n’est pas lue ou a été remplacée par un drop‑in. Enquêtez avant de continuer.

Task 9 — Confirm queries are going to the intended resolver, not “whatever”

cr0x@server:~$ resolvectl query git.corp.example
git.corp.example: 10.55.8.19
               -- Information acquired via protocol DNS in 6.3ms.
               -- Data is authenticated: no

Signification : Le nom interne se résout ; la split‑horizon est intacte.

Décision : Si les noms internes échouent après activation de DoT, vous les avez probablement routés vers le mauvais amont (les résolveurs publics globaux sont le coupable habituel).

Task 10 — Detect whether port 853 is blocked (the “it times out” classic)

cr0x@server:~$ nc -vz 10.20.30.40 853
nc: connect to 10.20.30.40 port 853 (tcp) timed out: Operation now in progress

Signification : TCP/853 n’est pas joignable (firewall, ACL, résolveur non à l’écoute). DoT opportuniste retombera sur du DNS en clair ; DoT strict cassera la résolution.

Décision : Si la politique autorise DoT, ouvrez le 853 vers le VIP du résolveur. Si la politique l’interdit, n’activez pas DoT strict sur les clients ; faites le chiffrement à l’intérieur du réseau à la place (client→résolveur interne en clair, résolveur interne→amont chiffré).

Task 11 — Validate resolver certificate and SNI using OpenSSL

cr0x@server:~$ openssl s_client -connect 10.20.30.40: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 résolveur présente un certificat correspondant à dns.corp.example, et l’hôte fait confiance à l’AC émettrice.

Décision : Si la vérification échoue, ne passez pas en DoT strict avant d’avoir corrigé la distribution des AC ou le nom serveur dans DNS=.

Task 12 — Check logs for resolved’s decision-making (it will tell you, if you ask)

cr0x@server:~$ journalctl -u systemd-resolved --since "10 min ago" --no-pager | tail -n 12
Dec 30 09:15:33 server systemd-resolved[612]: Using DNS server 10.20.30.40 for interface ens192.
Dec 30 09:15:33 server systemd-resolved[612]: Switching to DNS server 10.20.30.41 for interface ens192.
Dec 30 09:16:02 server systemd-resolved[612]: Server returned error NXDOMAIN, ignoring.
Dec 30 09:16:44 server systemd-resolved[612]: DNS-over-TLS negotiation failed with 10.20.30.40:853: Connection timed out

Signification : Vous obtenez des preuves explicites : négociation échouée, changement de serveur, ou NXDOMAIN. C’est votre fil d’Ariane.

Décision : Timeout de connexion → problème réseau/port. Échec de vérification → problème PKI. NXDOMAIN → routage DNS conditionnel ou contenu du mauvais résolveur.

Task 13 — Measure latency and caching behavior (because “encrypted” can become “slow”)

cr0x@server:~$ resolvectl statistics
Transactions: 224
  Cache Hits: 141
  Cache Misses: 83
DNSSEC Verdicts: 0
DNSSEC Supported: no
DNSSEC NTA: 0

Signification : Le ratio de hit du cache vous donne une impression rapide. S’il est proche de zéro sur un système chargé, quelque chose ne va pas (applications contournant le stub, ou cache désactivé ailleurs).

Décision : Faible ratio de hits + plaintes de latence : assurez‑vous que tout le monde utilise 127.0.0.53, et que vous ne redémarrez pas resolved constamment (oui, ça arrive).

Task 14 — Prove which process is sending DNS if you suspect bypass

cr0x@server:~$ sudo ss -ntup | awk '$5 ~ /:53$|:853$|:443$/ {print}'
tcp   ESTAB 0 0 10.9.1.12:45652 10.20.30.40:853 users:(("systemd-resolve",pid=612,fd=25))

Signification : La connexion DoT vient de systemd-resolve, comme prévu.

Décision : Si vous voyez des applications se connecter directement à des IP publiques sur 53/853/443, vous avez un contournement. Traitez‑le par la politique (et parfois des règles d’egress firewall).

Task 15 — Verify that DHCP/VPN aren’t clobbering DNS unexpectedly

cr0x@server:~$ nmcli dev show ens192 | sed -n '1,80p'
GENERAL.DEVICE:                         ens192
GENERAL.STATE:                          100 (connected)
IP4.DNS[1]:                             10.20.30.40
IP4.DNS[2]:                             10.20.30.41
IP4.DOMAIN[1]:                          corp.example

Signification : NetworkManager fournit les serveurs DNS d’entreprise et le domaine. Bien. C’est la base pour le DNS conditionnel.

Décision : Si vous voyez des serveurs DNS inattendus ici (Wi‑Fi d’hôtel, VPN, etc.), décidez lequel doit l’emporter et configurez le routage par lien plutôt qu’un marteau global.

Task 16 — Check firewall policy locally (don’t assume the network is the only firewall)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,80p'
table inet filter {
  chain output {
    type filter hook output priority 0; policy accept;
  }
}

Signification : Le pare‑feu local ne bloque pas la sortie 853/443. S’il le faisait, vous verriez des drops explicites.

Décision : Si la politique locale bloque 853, corrigez localement ou acceptez que DoT ne puisse pas fonctionner sur cet hôte.

Listes de contrôle / plan étape par étape (déploiement sûr)

Step 0 — Decide what “enterprise-safe” means in your org

• Les zones internes doivent‑elles résoudre ? Si oui, les clients doivent utiliser les résolveurs internes pour ces zones.
• Les journaux DNS doivent‑ils être centralisés ? Si oui, ne contournez pas les résolveurs internes. Chiffrez client→résolveur si possible ; sinon chiffrez résolveur→amont.
• Des proxys sont‑ils en place ? Si oui, considérez DoH comme « nécessitant une conception », pas comme « un interrupteur à basculer ».
• La validation stricte des certificats est‑elle requise ? Généralement oui. Mais faites un déploiement contrôlé pour éviter des pannes massives.

Step 1 — Inventory current DNS behavior

• Collectez resolvectl status depuis des hôtes représentatifs : sur LAN, sur VPN, sur Wi‑Fi, dans un segment DC.
• Identifiez où existe le split DNS : domaines, forwarders conditionnels, comportement de type NRPT.
• Confirmez si les résolveurs internes supportent DoT/DoH aujourd’hui (et s’ils ont des certificats corrects).

Step 2 — Prefer “encrypt to your resolver,” not “bypass your resolver”

Si vos résolveurs internes parlent DoT avec un certificat valide : faites‑le. C’est le modèle le plus propre pour les entreprises.
S’ils ne le peuvent pas : déployez une petite couche de forwarding gérée (Unbound/BIND) qui accepte le DNS en clair des clients et fait de l’amont chiffré à l’intérieur de votre périmètre de confiance.

Step 3 — Roll out opportunistic DoT first, with monitoring

• Activez DNSOverTLS=opportunistic sur un groupe pilote.
• Surveillez : latence DNS, taux d’erreur, CPU des résolveurs, nombre de connexions TCP/853, et signalements d’utilisateurs sur « internet lent ».
• Regardez les journaux pour les échecs de négociation. Corrigez la reachabilité et les certificats avant de passer en strict.

Step 4 — Move to strict DoT where possible

Une fois que vous pouvez valider les certificats de façon fiable (openssl s_client ci‑dessus), passez en strict : cela empêche la dégradation silencieuse vers le texte clair lorsque un middlebox bloque le 853.

cr0x@server:~$ sudo perl -0777 -i -pe 's/DNSOverTLS=opportunistic/DNSOverTLS=yes/g' /etc/systemd/resolved.conf
cr0x@server:~$ sudo systemctl restart systemd-resolved
cr0x@server:~$ resolvectl status | sed -n '1,12p'
Global
       Protocols: +LLMNR -mDNS +DNSOverTLS DNSSEC=no/unsupported

Step 5 — Keep split DNS explicit

Quand vous avez besoin de résolution interne et externe, soyez explicite sur le routage. Laissez les zones d’entreprise aller vers les résolveurs d’entreprise, et tout le reste suivre la route par défaut.
Le pire plan est « un résolveur public global pour tout ». Ce n’est pas un plan ; c’est comment vous découvrez quelles équipes savent crier le plus fort.

Step 6 — Document the exception cases (they will happen)

• Réseaux avec portail captif
• Segments DC restreints qui bloquent l’egress 853/443
• Systèmes avec agents fournisseurs qui codent en dur le DNS
• Applications héritées qui embarquent leurs propres bibliothèques de résolution

Trois micro‑histoires d’entreprise (pourquoi c’est plus difficile qu’il n’y paraît)

Mini-story 1 — The incident caused by a wrong assumption

Une entreprise de taille moyenne a décidé de « moderniser le DNS ». Un ingénieur bien intentionné a supposé que le DNS chiffré n’était qu’une amélioration de confidentialité, fonctionnellement équivalente au DNS en clair. Ils ont activé DoH sur un sous‑ensemble d’ordinateurs Debian, pointant vers un fournisseur public parce que c’était « fiable ».

Le lundi matin fut un lent incendie. Rien n’a explosé immédiatement. Mais les développeurs sur VPN ont commencé à signaler des échecs intermittents de résolution de services internes. Le support a vu un motif : les utilisateurs qui avaient récemment redémarré avaient plus de problèmes. Les utilisateurs restés allumés tout le week‑end allaient bien. C’est le genre de motif qui vous fait soupçonner le caching, pas l’infrastructure.

L’hypothèse erronée était simple : « DNS est DNS ». En réalité, leurs résolveurs internes faisaient de la split‑horizon pour corp.example, retournant des VIP internes seulement quand la requête venait du réseau interne ou du pool d’adresses VPN. Les résolveurs publics ont fait ce que font les résolveurs publics : soit ne rien retourner, soit retourner des adresses externes destinées aux partenaires. Certains services étaient accessibles en externe, mais avec des chemins d’authentification différents. Chaos discret.

La correction n’a pas été dramatique. Ils ont arrêté de contourner le DNS d’entreprise. Ils ont rétabli les portables pour utiliser les résolveurs internes, puis ont amélioré la couche de résolveur interne pour fournir un transport chiffré aux utilisateurs nomades via un endpoint géré. La leçon : les améliorations de confidentialité sont aussi des changements réseau. Traitez‑les comme tels.

Mini-story 2 — The optimization that backfired

Une autre organisation voulait réduire la latence DNS entre sites globaux. Quelqu’un a proposé : « Forçons un endpoint DoH global sur le 443. Il traversera tous les firewalls, et HTTP/2 multiplexera les requêtes. Plus rapide, non ? » Ça semblait moderne. Ça l’était. C’était aussi naïf sur la géographie et les proxys.

Le déploiement a commencé dans une région où le HTTPS sortant était forcé via un proxy explicite avec inspection TLS. Le client DoH ne faisait pas confiance au certificat MITM du proxy pour cet endpoint. Les recherches DNS ont commencé à se bloquer parce que le système essayait DoH en premier, attendait, puis retombait en arrière. Le fallback était bloqué aussi, parce que l’UDP/53 sortant était refusé par la politique (comme il se doit sur ce réseau).

Les utilisateurs percevaient « chaque site met dix secondes à commencer à se charger ». Ce n’étaient pas les sites. C’étaient les résolutions DNS qui timoutaient sur chaque nouveau nom jusqu’au réchauffement des caches ou aux nouvelles tentatives des applications. Quelques applications géraient, d’autres thrashaient.

Le post‑mortem fut franc : l’optimisation supposait un chemin internet propre. Les entreprises en ont rarement un. Ils ont reconstruit le design autour de résolveurs internes par région et ont utilisé DoT à l’intérieur de points d’egress contrôlés. Le DNS est devenu plus rapide, et la sécurité a arrêté de regarder le projet de travers.

Mini-story 3 — The boring but correct practice that saved the day

Une organisation fortement régulée avait une règle : pas de changement de politique DNS côté client sans groupe canari, et pas de canari sans rollback automatisé. Tout le monde rouspétait car cela ralentissait les « petites » améliorations. Puis ils ont essayé d’activer DoT en mode strict pour les résolveurs d’entreprise sur des endpoints Debian.

Le groupe canari a remonté des alertes en quelques minutes. Pas parce que DoT était cassé partout, mais parce qu’un site avait encore une vieille règle de firewall qui autorisait l’UDP/53 vers le VIP du résolveur mais bloquait le TCP/853. Le mode opportuniste l’aurait masqué ; le mode strict a échoué correctement. Les utilisateurs de ce site ne pouvaient plus rien résoudre.

L’automatisation les a immédiatement ramenés en arrière vers opportunistic, et l’incident est resté contenu. L’équipe réseau a corrigé la politique du firewall, puis le canari a réussi, puis le déploiement a continué. Personne n’a été appelé à minuit. Le processus ennuyeux n’a pas seulement « réduit le risque » ; il a transformé une arête vive en une petite ecchymose.

La fiabilité consiste souvent à refuser de faire la même erreur partout à la fois.

Erreurs courantes : symptômes → cause racine → fix

1) “Internal domains don’t resolve after enabling DoH/DoT”

Symptômes : git.corp.example NXDOMAIN ou résout vers des IP externes ; les utilisateurs VPN tombent sur de mauvais endpoints.

Cause racine : Contournement des résolveurs internes qui servent les zones split‑horizon ; override DNS global ignorant le routage par lien.

Correctif : Utilisez les résolveurs internes pour ~corp.example avec DNS conditionnel. Ne pointez pas les clients directement vers des résolveurs publics. Validez avec resolvectl status et resolvectl query.

2) “Everything is slow, but not down”

Symptômes : Pages et installations de paquets font une pause avant de se connecter ; blocages intermittents ; les retries « arrangent » le problème.

Cause racine : Timeouts DoH/DoT suivis de fallback, souvent dus à 853 bloqué, interception proxy, ou mismatch de certificat.

Correctif : Vérifiez la reachabilité (nc -vz ... 853), la validation du certificat (openssl s_client), et les logs resolved. Préférez le mode strict seulement quand le chemin est propre ; sinon vous créez de la latence liée aux timeouts.

3) “DoT strict mode breaks on one site only”

Symptômes : Fonctionne au siège, échoue dans une succursale ; même image, réseau différent.

Cause racine : Firewall/ACL spécifique au site autorise UDP/53 mais bloque TCP/853, ou route 853 différemment.

Correctif : Alignez la politique réseau entre sites. Si impossible, gardez le mode opportuniste pour ce site ou terminez DoT sur un résolveur local dans le réseau de la succursale.

4) “It works on Ethernet but fails on Wi‑Fi/captive portal”

Symptômes : Sur Wi‑Fi public vous n’atteignez rien tant que vous ne désactivez pas le DNS chiffré ; le portail n’apparaît jamais.

Cause racine : Les portails captifs dépendent de l’interception DNS/HTTP ; le DNS chiffré empêche le flux d’interception.

Correctif : Fournissez un basculement basé sur la politique pour les profils nomades, ou permettez le fallback en clair sur les réseaux « non fiables » si votre modèle de risque l’autorise. Mieux : utilisez un VPN géré qui apporte le DNS à l’intérieur du tunnel après authentification du portail.

5) “DNSSEC failures appear after turning on encryption”

Symptômes : Certains domaines échouent avec SERVFAIL ; les logs mentionnent DNSSEC ou validation.

Cause racine : Pas causé directement par le chiffrement ; cela expose des changements de comportement du résolveur, la gestion EDNS0, ou des middleboxes qui mutilent les réponses.

Correctif : Confirmez si votre résolveur valide DNSSEC et si des middleboxes altèrent les réponses. Si votre environnement ne peut pas le supporter, n’activez pas la validation DNSSEC en périphérie sans précaution.

6) “Some apps still use plaintext DNS even after you ‘enabled DoT’”

Symptômes : Une capture montre de l’UDP/53 vers des serveurs aléatoires ; ou une app résout même quand resolved est arrêté.

Cause racine : Applications utilisant leurs propres résolveurs (conteneurs, runtimes de langage, agents VPN) ou contournant le chemin de résolution glibc.

Correctif : Auditez avec ss, les réglages DNS du runtime conteneur, et les contrôles d’egress. Faites respecter un chemin de résolveur unique pour les endpoints gérés, ou documentez explicitement les exceptions.

FAQ

1) Should I enable DoH or DoT on Debian 13 endpoints by default?

En entreprise : par défaut, favorisez DoT vers vos résolveurs (ou votre forwarder géré). DoH convient quand vous contrôlez l’endpoint et la chaîne proxy. Évitez le direct‑to‑public sauf si la politique l’autorise explicitement.

2) What’s the safest first rollout mode?

DoT opportuniste. Il tente le chiffrement mais ne cassera pas le DNS si un site bloque le 853. Utilisez cette phase pour découvrir les lacunes de politique, puis passez au strict quand c’est possible.

3) If we already have DNSSEC, do we still need DoT/DoH?

Oui, si vous tenez à la confidentialité des requêtes et à la résistance à la surveillance passive. DNSSEC protège l’intégrité des réponses (si validées), pas la confidentialité des questions.

4) Will encrypted DNS break split-horizon DNS?

Pas intrinsèquement. Contourner le résolveur interne casse le split‑horizon. Chiffrer le transport vers le résolveur interne le préserve.

5) How do I keep compliance logging while using encrypted DNS?

Continuez d’utiliser les résolveurs internes où la journalisation et la politique résident. Chiffrez du point final au résolveur (DoT) ou au moins du résolveur vers l’amont. Ne dispersez pas le DNS des endpoints vers des fournisseurs externes aléatoires.

6) What about proxies and TLS inspection?

DoT évite généralement l’interception par proxy par conception (ce n’est pas HTTPS), mais peut être bloqué par des règles d’egress. DoH rentre souvent en collision avec l’inspection sauf si le client fait confiance à la CA interceptante ou si vous exemptez ce trafic — ce sont des décisions de politique, pas des « correctifs » techniques simples.

7) How can I prove we’re actually using DoT?

Cherchez +DNSOverTLS dans resolvectl status, confirmez les sessions TCP/853 depuis systemd-resolve via ss, et validez le certificat du résolveur avec openssl s_client.

8) Should I set public fallback DNS servers?

En entreprise : généralement non. Des serveurs de secours publics peuvent contourner silencieusement les zones internes et la journalisation. Si vous avez besoin de résilience, exécutez plusieurs résolveurs internes et assurez‑vous que le routage vers eux fonctionne partout (LAN, VPN, succursales).

9) Does enabling DoH/DoT stop DNS-based filtering?

Cela peut le faire si le filtrage repose sur l’interception du DNS en clair en transit. Cela peut être souhaité ou violer la politique. La réponse adaptée en entreprise est d’effectuer le filtrage sur le résolveur que vous contrôlez et de chiffrer le transport vers lui.

Conclusion : prochaines étapes à exécuter cette semaine

Le DNS chiffré sur Debian 13 n’est pas difficile. Le faire sans casser les réseaux d’entreprise consiste surtout à respecter la façon dont les entreprises utilisent réellement le DNS : split‑horizon, application des politiques et routage prévisible.

Prochaines étapes qui rapportent vite :

1. Choisissez un modèle : endpoint→résolveur interne chiffré (meilleur), ou résolveur interne→amont chiffré (second meilleur), et évitez endpoint→résolveur public sauf si la politique l’autorise.
2. Exécutez la procédure de diagnostic rapide sur un groupe pilote et corrigez les bloqueurs ennuyeux : reachabilité TCP/853, certificats, et comportement DNS par lien.
3. Déployez DoT opportuniste avec surveillance, puis passez en strict lorsque vous pouvez prouver que le chemin et la PKI sont corrects.
4. Documentez la gestion des exceptions pour les portails captifs et les clients VPN bizarres. Vous en aurez besoin.

Une idée paraphrasée de W. Edwards Deming s’applique bien ici : Sans données, vous n’êtes qu’une personne de plus avec une opinion. Mesurez avant de basculer en mode strict.

Blague #1 : Le DNS est le seul système où « c’est toujours le réseau » est à la fois un cliché et souvent un fait.

Blague #2 : Le DNS chiffré ne réparera pas votre organigramme, mais il révélera qui possède la politique d’egress — généralement par accident.