DNS split-horizon : faire résoudre les noms LAN sans perturber l’Internet public

Tout fonctionne… jusqu’à ce que ça ne fonctionne plus. Vous ajoutez un joli nom d’hôte interne comme git.company.com pointant vers une IP privée,
et soudain les ordinateurs portables sur le Wi‑Fi invité ne peuvent plus atteindre le vrai site public. Ou pire : le nom interne fuit vers l’extérieur,
et maintenant votre infrastructure « privée » discute avec des inconnus.

Le DNS split-horizon — aussi appelé DNS split-brain — est la solution adulte : des réponses différentes selon l’endroit d’où vient la requête.
Bien fait, les noms LAN se résolvent proprement, la résolution publique reste correcte, et vos astreintes dorment. Mal fait, vous inventez de nouveaux
modes de panne passionnants.

Ce qu’est réellement le DNS split-horizon (et ce que ce n’est pas)

Le DNS split-horizon signifie que votre infrastructure DNS renvoie des enregistrements différents pour un même nom selon le contexte réseau du client :
IP source, interface, état VPN, ou règles explicites de « vue ». Le cas classique est que des clients internes résolvent app.example.com
en 10.10.20.30 tandis que des clients externes le résolvent en 203.0.113.10 derrière un CDN ou un WAF.

Le DNS split-horizon n’est pas « utilisez un suffixe interne comme .lan et tout ira bien ». Ça peut marcher pour un labo domestique,
mais en entreprise cela tend à créer des angles vifs : mobilité des appareils, split tunneling VPN, TLS interne, et la réalité inconfortable
que les humains taperont ce qui ressemble au nom public.

Aussi : le split-horizon n’est pas un bouton magique de performance. Le DNS est déjà rapide lorsque vous ne cassez pas la mise en cache ou ne créez pas de boucles.
L’objectif est la justesse et la résolution prévisible. « Prévisible » est le mot-clé. Un résolveur qui répond vite mais de façon incohérente est juste
un générateur de pannes à grande vitesse.

Un modèle mental clair

• Serveurs autoritatifs publient la « vérité » pour une zone (ou plusieurs vérités, via des vues).
• Résolveurs récursifs recherchent des réponses pour le compte des clients et mettent en cache les résultats.
• Résolveurs stubs résident sur les clients et transmettent les questions à un résolveur récursif.

Le split-horizon peut être implémenté au niveau autoritatif (deux « vérités » autoritatives selon la source) ou au niveau récursif (surcharger des noms spécifiques
en interne tout en utilisant sinon le DNS public). Les deux fonctionnent. Un seul tend à évoluer proprement dans votre organisation, selon qui possède quoi.

Blague n°1 : le DNS est le seul système où « ça marchait hier » est considéré comme une preuve solide de rien du tout.

Faits historiques et éléments pratiques pour argumenter

Ce sont des points de contexte courts et concrets. Ils sont utiles quand vous essayez de convaincre les équipes sécurité, réseau et applicatives
d’arrêter de faire des choses « créatives » avec les noms.

1. Le DNS précède les hypothèses de sécurité modernes. Le DNS primitif (milieu des années 1980) a été conçu pour des réseaux coopératifs ; l’intégrité et
   l’authenticité sont venues plus tard, ajoutées via DNSSEC.
2. Le split-horizon est devenu populaire avec les pare-feu périmétriques. Quand NAT et modèles DMZ sont devenus courants, un même nom avait souvent
   besoin de réponses différentes pour le routage interne vs externe.
3. Les plages IP privées RFC 1918 (1996) ont normalisé l’idée que l’adressage interne est fondamentalement différent du routage public—et le DNS a dû refléter cette réalité.
4. « Split-brain DNS » est plus ancien que le cloud. Le modèle existait bien avant les VPC ; le cloud a simplement facilité l’existence de nombreux
   « internals » avec des noms qui se chevauchent et des zones partiellement possédées.
5. La mise en cache DNS explique pourquoi vos changements « ne fonctionnent pas ». Le TTL et le comportement de mise en cache négative (mise en cache de NXDOMAIN)
   expliquent fréquemment pourquoi un ordinateur voit le nouvel enregistrement et un autre non.
6. Les domaines de recherche DNS sont une arme à double tranchant. Beaucoup de résolveurs ajoutent des suffixes de recherche et génèrent plusieurs requêtes.
   Des listes de recherche mal configurées peuvent produire des résolutions surprenantes et des fuites.
7. Le suffixe .local est spécial dans de nombreuses piles. Il est utilisé par mDNS (multicast DNS). L’utiliser pour du DNS unicast est un piège classique
   du type « ça marche sur ma machine ».
8. EDNS Client Subnet a changé la façon de voir « où vous êtes ». Certains résolveurs publics peuvent transmettre des indices de sous-réseau client aux CDN.
   C’est bon pour la performance et déroutant pour le débogage.
9. DNS over HTTPS et DNS over TLS compliquent le contrôle en entreprise. Si les clients contournent votre résolveur, votre logique split-horizon peut ne jamais s’exécuter.

Décisions d’architecture qui comptent en production

1) Choisir la stratégie de namespace : même nom vs nom différent

Vous avez deux grandes approches :

• Même FQDN à l’intérieur et à l’extérieur (par ex. git.company.com résout en interne sur RFC1918 et en externe sur IP publique/CDN). C’est
  le plus ergonomique pour les humains et les applications. C’est aussi le plus facile à mal configurer par accident.
• Nom interne différent (par ex. git.internal.company.com ou git.corp). Cela réduit les risques de conflit avec le DNS public
  mais augmente la friction opérationnelle : certificats, redirections, CORS, callbacks OAuth, et comportement des utilisateurs.

Opinion : si vous exploitez des applications internes sérieuses utilisées par de vraies personnes et que les appareils bougent (portables, téléphones, VPN), utilisez le même FQDN et faites
le split-horizon correctement. Si c’est un petit labo statique, des noms internes différents sont acceptables—jusqu’au moment où vous commencez à émettre du TLS et à vous intégrer
à des SaaS, et là vous regretterez de ne pas avoir choisi la voie ennuyeuse.

2) Décider où se produit la séparation : autoritatif vs récursif

Implémentez le split-horizon au niveau autoritatif lorsque vous contrôlez la zone et avez besoin de réponses déterministes pour sources internes/externes.
Exemple : vues BIND, instances NSD séparées, ou vues split dans les DNS cloud.

Implémentez le split-horizon au niveau récursif lorsque vous souhaitez garder le DNS autoritatif public simple et surcharger uniquement un petit ensemble de noms en interne.
Exemple : zones locales Unbound, overrides dnsmasq, ou forwarding conditionnel vers des serveurs autoritatifs internes.

Opinion : pour les entreprises, préférez la séparation au bord récursif plus une zone autoritative interne propre. Mettez le moins de « politique » possible dans des serveurs
autoritatifs partagés entre environnements. Pour des réseaux plus petits, une seule instance BIND avec vues est parfaitement acceptable tant que vous la traitez comme de la production
et testez les changements.

3) Évitez les « zones fantômes » à moins d’aimer les surprises

Une zone fantôme est quand un serveur DNS interne fait semblant d’être autoritatif pour une zone publique (par exemple company.com) mais ne contient qu’une poignée
d’enregistrements. Tout le reste devient NXDOMAIN ou des réponses obsolètes. Cela casse des choses de façon qui ressemble à de la magie maudite.

Si vous devez surcharger une zone publique, faites-le avec :

• des vues autoritatives qui contiennent encore une vue complète de la zone, ou
• des overrides récursifs pour des noms spécifiques, tout en laissant les autres noms se résoudre publiquement.

4) Stratégie TTL : assez bas pour les changements, pas si bas que vous surchargez les caches

Le TTL n’est pas « la rapidité du DNS ». Le TTL est la durée pendant laquelle votre erreur persiste.

Pour des overrides internes qui peuvent changer pendant une réponse d’incident (failover, DR), des TTL de 30–300 secondes sont courants. Pour des enregistrements internes stables,
300–3600 secondes conviennent. Pour des enregistrements publics derrière des CDN, vous suivez généralement les règles du fournisseur.

Des TTL bas augmentent le volume de requêtes et amplifient les pannes lorsque les résolveurs oscillent. Des TTL élevés augmentent le temps de rétablissement quand il faut déplacer un point de terminaison.
Choisissez intentionnellement, par classe d’enregistrement, et mesurez le QPS des résolveurs avant d’« optimiser ».

5) Faites de DNSSEC une décision consciente, pas un accident

La validation DNSSEC est de plus en plus courante (résolveurs d’entreprise, certains FAI). Le split-horizon peut interagir mal avec DNSSEC si vous servez
des réponses signées/non signées différentes, ou si vous surchagez des noms publics signés en interne sans contrôler les clés de signature.

Conseils pratiques :

• Si vous surchargez des noms dans une zone publique signée, faites-le au niveau récursif avec précaution, ou attendez-vous à des échecs de validation si les clients valident indépendamment.
• Si vous contrôlez la signature de la zone, vous pouvez signer les deux vues—mais gardez à l’esprit la complexité opérationnelle.

6) Tenez compte des clients modernes : DoH, VPN et résolveurs « utiles » des OS

Le split-horizon suppose que vous savez où le client envoie le DNS. Mais les navigateurs et les OS ont leurs opinions :

• DNS over HTTPS peut contourner complètement votre résolveur. Vos noms internes ne se résoudront pas et votre politique ne s’appliquera pas.
• systemd-resolved peut faire du DNS par interface et du routage des requêtes par domaine. C’est excellent quand c’est configuré. C’est
  déroutant quand ce n’est pas le cas.
• Le split tunneling VPN peut router le DNS différemment du trafic, créant un chaos « DNS dit interne, paquets vont à l’extérieur ».

Architectures de référence : les trois modèles sensés

Pattern A : vues autoritatives (vues BIND) + récursion interne

Vous exploitez un ensemble de serveurs autoritatifs qui répondent aux clients externes avec des enregistrements publics et aux clients internes avec des enregistrements privés,
en fonction d’ACL IP source. Les résolveurs internes les interrogent, les résolveurs externes les interrogent, tout le monde est « content ».

Avantages : même nom de zone, politique claire, déterminisme. Inconvénients : les vues sont complexes à configurer ; des erreurs peuvent faire fuiter des enregistrements internes
ou servir des zones incomplètes ; les tests demandent de la discipline.

Pattern B : overrides récursifs (Unbound/dnsmasq) + autoritatif public reste public

La zone publique reste telle quelle, hébergée où elle est. À l’intérieur du LAN, vous exécutez des résolveurs récursifs qui surchargent des noms spécifiques
(ou transfèrent certaines zones) vers des serveurs autoritatifs internes.

Avantages : couplage minimal ; facile à raisonner ; moins de façons de casser l’Internet public. Inconvénients : vous dépendez maintenant des clients qui utilisent votre résolveur ;
DoH peut vous contourner ; vous avez besoin de HA pour les résolveurs.

Pattern C : sous-domaine interne séparé + forwarding conditionnel

Mettez les noms internes sous un sous-domaine délégué comme corp.company.com et forwardez cette zone en interne. Le DNS public ne la publie pas ou publie
seulement ce que vous voulez rendre public.

Avantages : séparation propre ; moins de conflits ; DNSSEC plus simple si vous signez la zone interne séparément. Inconvénients : les humains taperont toujours le nom public ;
les applis s’intègrent avec des callbacks publics ; vous aurez besoin de split pour certains noms de toute façon.

Opinion : le Pattern B est le meilleur par défaut pour la plupart des organisations. Le Pattern A est puissant quand vous avez vraiment besoin de « même nom, deux vérités » au
niveau autoritatif. Le Pattern C est une couverture confortable qui fonctionne jusqu’à ce qu’elle ne fonctionne plus.

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

Ce sont des tâches réelles que vous pouvez exécuter pendant la conception, le déploiement et la réponse aux incidents. Chacune inclut : la commande, une sortie d’exemple,
ce que cela signifie, et la décision que vous prenez.

Task 1: Confirm which resolver your host is actually using

cr0x@server:~$ resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server: 10.10.0.53
       DNS Servers: 10.10.0.53 10.10.0.54
        DNS Domain: corp.company.com
Link 2 (ens192)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 10.10.0.53
       DNS Servers: 10.10.0.53 10.10.0.54

Ce que cela signifie : systemd-resolved est en jeu ; le DNS va vers 10.10.0.53/.54. Il y a un indice de routage de domaine pour corp.company.com.

Décision : Si des utilisateurs signalent « les noms internes ne se résolvent pas », vérifiez qu’ils utilisent bien ces résolveurs. Si vous voyez du DNS public
(FAI, 1.1.1.1, 8.8.8.8), vous n’avez pas de split-horizon ; vous avez de l’espoir.

Task 2: Prove the split with a targeted query to internal resolver

cr0x@server:~$ dig @10.10.0.53 app.company.com +noall +answer
app.company.com.        60      IN      A       10.10.20.30

Ce que cela signifie : Le résolveur interne renvoie une IP privée avec TTL 60.

Décision : Si c’est correct, votre vue/override interne fonctionne. Ensuite : vérifiez ce que voit le public.

Task 3: Compare against public resolution (without trusting your resolver)

cr0x@server:~$ dig @1.1.1.1 app.company.com +noall +answer
app.company.com.        300     IN      A       203.0.113.10

Ce que cela signifie : La réponse publique diffère (attendu en split-horizon). Le TTL est plus élevé.

Décision : Si le public renvoie l’IP privée, vous avez une fuite. Si le public renvoie NXDOMAIN, vous avez probablement shadow-zoné et cassé l’Internet pour vous-même.

Task 4: Identify where an answer came from (authoritative vs cache)

cr0x@server:~$ dig @10.10.0.53 app.company.com +norecurse
; <<>> DiG 9.18.24-1 <<>> @10.10.0.53 app.company.com +norecurse
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
app.company.com.        60      IN      A       10.10.20.30

Ce que cela signifie : aa indique que le serveur se considère comme autoritatif pour cette réponse.

Décision : Si vous attendiez un override récursif et voyez aa, vous pourriez servir une vue/zone que vous n’aviez pas prévue (risque d’ombrage).

Task 5: Check for negative caching (NXDOMAIN that won’t die)

cr0x@server:~$ dig @10.10.0.53 newhost.corp.company.com +noall +answer +authority
corp.company.com.       900     IN      SOA     ns1.corp.company.com. hostmaster.corp.company.com. 2025123101 3600 600 1209600 60

Ce que cela signifie : Pas de section answer ; l’autorité montre le SOA. Le résolveur a probablement mis en cache un NXDOMAIN ; le TTL négatif découle souvent du minimum/TTL négatif du SOA.

Décision : Si vous venez de créer newhost, attendez la fin du cache négatif, videz le cache, ou réduisez le TTL négatif dans le SOA pour les zones qui changent souvent.

Task 6: Flush resolver cache safely (systemd-resolved)

cr0x@server:~$ resolvectl flush-caches
cr0x@server:~$ resolvectl statistics
DNSSEC supported by current servers: no
Transactions               Current Transactions: 0
Cache                       Current Cache Size: 12
Cache                         Cache Hits: 221
Cache                       Cache Misses: 45

Ce que cela signifie : Cache vidé ; les statistiques montrent le comportement en cours.

Décision : Si le vidage « corrige » les choses de manière répétée, vous avez un problème de TTL/cache négatif ou des réponses en amont incohérentes.

Task 7: Validate BIND zone integrity before reload (no hero reloads)

cr0x@server:~$ named-checkzone corp.company.com /etc/bind/zones/db.corp.company.com
zone corp.company.com/IN: loaded serial 2025123101
OK

Ce que cela signifie : Le fichier de zone est analysable, le serial présent, BIND est peu susceptible de le rejeter.

Décision : Si ça échoue, ne rechargez pas. Corrigez la syntaxe d’abord ; sinon vous risquez de servir une zone plus ancienne ou de faire échouer la vue entièrement.

Task 8: Validate BIND configuration (views and ACLs are where the bodies are)

cr0x@server:~$ named-checkconf -z
zone corp.company.com/IN: loaded serial 2025123101
zone company.com/IN: loaded serial 2025123105

Ce que cela signifie : La config est syntaxiquement valide et les zones se chargent.

Décision : Si named-checkconf retourne des erreurs, ne redémarrez pas BIND. Corrigez la config ; un redémarrage sous charge est une bonne façon d’être rappelé deux fois.

Task 9: Confirm which view a client hits (BIND querylog)

cr0x@server:~$ sudo rndc querylog on
cr0x@server:~$ sudo tail -n 3 /var/log/named/query.log
31-Dec-2025 11:03:22.918 client @0x7f2c8c1a: query: app.company.com IN A +E(0)K (10.10.0.53) [view "internal"]
31-Dec-2025 11:03:23.104 client @0x7f2c8c2b: query: app.company.com IN A +E(0)K (10.10.0.53) [view "external"]
31-Dec-2025 11:03:23.201 client @0x7f2c8c2b: query: www.company.com IN A +E(0)K (10.10.0.53) [view "external"]

Ce que cela signifie : Deux clients (ou sources NATées) sont classés dans des vues différentes.

Décision : Si un client interne est étiqueté external, corrigez les ACL, les adresses source ou le comportement NAT. N’ajoutez pas « un autre enregistrement » ; c’est comme ça qu’on crée un désastre au ralenti.

Task 10: Detect forwarding loops (the silent resolver killer)

cr0x@server:~$ dig @10.10.0.53 corp.company.com SOA +time=1 +tries=1
;; communications error to 10.10.0.53#53: timed out
;; no servers could be reached

Ce que cela signifie : Le résolveur expire rapidement. En coulisses, cela arrive souvent quand le résolveur A forwarde vers le résolveur B qui forwarde vers A.

Décision : Vérifiez la configuration des forwarders et assurez-vous qu’il existe une source autoritative terminale pour les zones internes. Coupez la boucle ; puis observez la latence des requêtes revenir à la normale.

Task 11: Inspect Unbound local overrides (what is it lying about?)

cr0x@server:~$ sudo unbound-control list_local_zones
corp.company.com. transparent
company.com. nodefault

Ce que cela signifie : corp.company.com est géré de façon transparente ; company.com est surchargé (nodefault) ce qui peut ombrager les données publiques.

Décision : Si vous n’aviez pas l’intention de surcharger largement company.com, retirez-le ou restreignez-le à des overrides d’hôtes spécifiques.

Task 12: Query Unbound for local data and see whether it’s authoritative-ish

cr0x@server:~$ dig @10.10.0.53 app.company.com +noall +answer +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61545
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
app.company.com.        60      IN      A       10.10.20.30

Ce que cela signifie : Il s’agit d’un comportement récursif (rd/ra) plutôt que d’autoritatif (aa absent). Bon pour les patterns « override de noms spécifiques ».

Décision : Si vous attendiez des réponses autoritatives, vous déboguez le mauvais niveau. Si vous attendiez de la récursion et voyez aa, autre chose répond.

Task 13: Verify conditional forwarding (Windows/AD environments)

cr0x@server:~$ dig @10.10.0.10 _ldap._tcp.dc._msdcs.corp.company.com SRV +noall +answer
_ldap._tcp.dc._msdcs.corp.company.com. 600 IN SRV 0 100 389 dc01.corp.company.com.

Ce que cela signifie : Le DNS AD renvoie des enregistrements SRV ; le forwarding pour corp.company.com fonctionne probablement.

Décision : Si les requêtes SRV échouent de façon intermittente, traitez cela d’abord comme un problème de routage split-horizon (mauvais résolveur sur certains clients)
avant d’accuser Kerberos.

Task 14: Check if clients are bypassing you with DoH (browser-level reality check)

cr0x@server:~$ sudo tcpdump -ni any port 53 -c 5
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
11:09:41.120421 ens192 In  IP 10.10.50.21.53821 > 10.10.0.53.53: 31614+ A? app.company.com. (33)
11:09:41.120987 ens192 Out IP 10.10.0.53.53 > 10.10.50.21.53821: 31614 1/0/0 A 10.10.20.30 (49)
11:09:44.908112 ens192 In  IP 10.10.50.21.34620 > 10.10.0.53.53: 1720+ A? www.company.com. (33)
11:09:44.908621 ens192 Out IP 10.10.0.53.53 > 10.10.50.21.34620: 1720 1/0/0 A 203.0.113.10 (49)
5 packets captured

Ce que cela signifie : Au moins pour ces requêtes, le client utilise le DNS classique vers votre résolveur.

Décision : Si les utilisateurs se plaignent mais que vous ne voyez pas de trafic sur le port 53, suspectez DoH/DoT ou des bizarreries de portail captif. Votre split-horizon
ne peut pas aider s’il ne voit jamais la question.

Task 15: Confirm reverse DNS matches the forward split (or you’ll break audits and some auth)

cr0x@server:~$ dig @10.10.0.53 -x 10.10.20.30 +noall +answer
30.20.10.10.in-addr.arpa. 300 IN PTR app.company.com.

Ce que cela signifie : Un PTR existe et pointe vers le nom attendu.

Décision : Si la résolution inverse manque ou pointe vers un nom public, corrigez-la. Certains systèmes (mail, logs, outils de sécurité) utilisent la rDNS pour la corrélation et les contrôles.

Task 16: Measure DNS latency and detect timeouts (the real “DNS is slow” test)

cr0x@server:~$ dig @10.10.0.53 app.company.com +stats +noall +answer
app.company.com.        60      IN      A       10.10.20.30
;; Query time: 2 msec
;; SERVER: 10.10.0.53#53(10.10.0.53) (UDP)
;; WHEN: Wed Dec 31 11:12:12 UTC 2025
;; MSG SIZE  rcvd: 49

Ce que cela signifie : 2 ms est sain sur LAN.

Décision : Si vous voyez 200–2000 ms, suspectez des problèmes de forwarding, perte de paquets, MTU avec EDNS, ou un résolveur surchargé. Corrigez la latence avant de toucher aux retries applicatifs.

Blague n°2 : si vous voulez cacher des détails d’infrastructure, ne les mettez pas dans le DNS—le DNS est essentiellement l’interphone du bureau.

Mode opératoire de diagnostic rapide

Quand la résolution casse, vous n’avez pas le temps pour la philosophie. Vous devez trouver le goulot et décider qui le gère : client, résolveur,
serveur autoritatif, ou chemin réseau. Voici la check-list que j’exécute avant de laisser quelqu’un « juste redémarrer le DNS ».

Première étape : confirmer le chemin DNS du client

• Vérifiez quels serveurs DNS l’hôte utilise (resolvectl status sur Linux, paramètres réseau ailleurs).
  S’il n’utilise pas votre résolveur interne, le split-horizon n’est pas en place.
• Exécutez tcpdump sur le résolveur : voyez-vous les requêtes du client ?
  Si non, suspectez DoH/DoT, VPN, ou un autre résolveur.

Deuxième étape : comparer les réponses interne vs publique pour un même nom

• Interrogez directement le résolveur interne avec dig @internal.
• Interrogez un résolveur public connu avec dig @1.1.1.1 (ou votre baseline préférée).
• Si le public est « mauvais », votre autoritatif public est incorrect ou fuit.
  Si l’interne est « mauvais », votre override/vue/forwarding interne est incorrect.

Troisième étape : déterminer si la réponse est autoritative, mise en cache, ou en échec en amont

• +norecurse et inspection des flags : aa signifie autoritatif.
• Recherchez les timeouts : des communications error répétés indiquent généralement un réseau ou des boucles de forwarding.
• Vérifiez la mise en cache négative : un SOA dans l’autorité sans réponses indique souvent un NXDOMAIN en cache.

Quatrième étape : isoler le transport et les problèmes EDNS

• Si l’UDP échoue mais que le TCP fonctionne, suspectez MTU/fragmentation ou règles de pare-feu.
• Si le DNS fonctionne pour de petites réponses mais échoue pour des réponses volumineuses, suspectez des problèmes de tampon EDNS.

Cinquième étape : confirmer la classification vue/ACL (si vous utilisez des vues)

• Activez brièvement les logs de requêtes et identifiez quelle vue les clients frappent.
• Corrigez les ACLs ou le comportement NAT ; ne colmatez pas avec des enregistrements dupliqués.

Une citation à garder quand des gens demandent « un correctif rapide » qui est en réalité un pari :
idée paraphrasée — John Allspaw : le travail consiste à comprendre le système ; blâmer les gens n’améliore pas la fiabilité.

Erreurs courantes : symptômes → cause → correction

1) « L’application interne fonctionne sur le VPN mais pas sur le Wi‑Fi du bureau »

Symptôme : Même portable, réseau différent, réponse différente.

Cause : Différents résolveurs par interface ; le Wi‑Fi du bureau distribue du DNS public, le VPN pousse du DNS interne (ou inversement).

Correction : Standardisez les options DNS DHCP ; utilisez le routage par domaine (split DNS) sur le client VPN pour que seuls les domaines internes aillent vers les résolveurs internes ; vérifiez avec resolvectl status.

2) « Certains utilisateurs obtiennent l’ancienne IP pendant des heures »

Symptôme : Réponses obsolètes longtemps après le changement.

Cause : TTL trop élevé, ou résolveurs de cache intermédiaires (y compris box domestiques) ignorant votre comportement ; la mise en cache négative pour NXDOMAIN aussi.

Correction : Réduisez le TTL avant les migrations ; videz les caches sur les résolveurs contrôlés ; communiquez que les résolveurs non gérés seront en retard. Pour NXDOMAIN, ajustez le TTL négatif du SOA si approprié.

3) « Les utilisateurs publics résolvent des IP privées pour nos services »

Symptôme : Les requêtes externes renvoient des IP RFC1918 ou des noms d’hôtes internes.

Cause : Mauvaise classification d’ACL de vue, NAT faisant apparaître des requêtes externes comme internes, ou un résolveur récursif exposé accidentellement sur Internet.

Correction : Verrouillez la récursion aux réseaux internes seulement ; validez les vues avec des logs de requêtes ; assurez-vous que les réponses publiques proviennent uniquement de la vue/zone externe.

4) « Tout dans company.com est NXDOMAIN en interne sauf quelques enregistrements »

Symptôme : Des sites publics sous votre domaine cassent en interne.

Cause : Zone fantôme : le DNS interne est autoritatif pour company.com mais n’a pas le contenu complet de la zone.

Correction : Arrêtez de servir des zones autoritatives partielles. Hébergez une zone complète en interne avec synchronisation appropriée, ou faites des overrides par enregistrement au niveau récursif.

5) « Le DNS timeout aléatoirement sous charge »

Symptôme : Timeouts intermittents, latence élevée, clients qui retentent.

Cause : Boucles de forwarding, résolveur surchargé, perte de paquets, ou limitation de rate par le pare-feu. Des TTL bas peuvent amplifier cela en augmentant le QPS.

Correction : Tracez les chemins de forwarding ; coupez les boucles ; augmentez la capacité des résolveurs ; ajustez les TTLs ; assurez-vous que le pare-feu autorise UDP/TCP 53 de façon fiable sur les segments internes.

6) « Ça marche avec dig mais les navigateurs échouent »

Symptôme : La résolution en ligne de commande est correcte ; le navigateur ne peut pas joindre les noms internes.

Cause : Le navigateur utilise DoH vers un résolveur public, contournant les overrides DNS internes.

Correction : Gérez les politiques DoH via des contrôles d’entreprise ; fournissez un endpoint DoH interne si nécessaire ; vérifiez avec des captures et des audits des paramètres navigateur.

7) « Les certificats ne correspondent pas après un changement split-horizon »

Symptôme : Erreurs TLS en interne après avoir pointé un nom vers une IP privée.

Cause : Le service interne ne présente pas le certificat pour le nom public, ou la terminaison TLS diffère en interne vs externe.

Correction : Terminez TLS de façon cohérente ; utilisez des certificats avec SAN corrects ; ne comptez pas sur le fait que « les utilisateurs internes cliqueront pour accepter ». Ils ne le feront pas, et ils n’en ont pas à le faire.

Trois micro-histoires d’entreprise (et les leçons qu’elles ont coûtées)

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

Une société SaaS de taille moyenne voulait que les utilisateurs internes atteignent le « chemin rapide » vers leur environnement de staging. Quelqu’un a suggéré
le split-horizon pour staging.company.com : en interne résout vers un load balancer privé ; en externe vers un endpoint public durci.

Le changement est arrivé un vendredi après-midi, parce que bien sûr. En une heure, les tickets support sont arrivés : des ingénieurs sur des réseaux domestiques
ne pouvaient plus atteindre staging, et certains utilisateurs au bureau voyaient des avertissements de certificat. L’hypothèse immédiate était « le load balancer est down. » Ce n’était pas le cas.

La mauvaise hypothèse : ils croyaient que « interne » signifiait « requêtes originant de notre plage d’IP publique ». Leur ACL de vue DNS traitait tout le trafic NATé sortant du bureau
comme interne—ok. Mais leur concentrateur VPN NATait aussi les utilisateurs distants derrière le même bloc d’IP de sortie. Selon l’état des routes, un utilisateur pouvait être classé
comme DNS-interne tandis que son trafic passait toujours par l’internet public sans accès au load balancer privé.

Le résultat fut une scission désagréable : le DNS disait « allez en privé », le routage disait « vous ne pouvez pas », et le navigateur disait « je déteste votre certificat ». La correction
fut embarrassante de simplicité : classer les vues selon des sous-réseaux sources qui représentent réellement la joignabilité interne, pas seulement « des trucs qu’on possède ».
Ils sont aussi passés au routage DNS par domaine sur le client VPN pour que les noms internes aillent aux résolveurs internes seulement quand le VPN est actif et que les routes existent.

Leçon : le split-horizon ne porte pas sur l’identité ou la propriété. Il porte sur la joignabilité. Si votre vue « interne » inclut des clients qui ne peuvent pas atteindre les services internes,
vous avez construit une machine à confusion.

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

Une grande entreprise avait une configuration acceptable : résolveurs récursifs par site, forwarding conditionnel pour les zones internes, et résolution publique pour le reste.
Quelqu’un a regardé les taux de requêtes DNS et a décidé qu’on pouvait « réduire le trafic » en augmentant les TTLs internes à plusieurs heures.

Ça a bien marché dans les graphiques. Le QPS des résolveurs a chuté. Les caches avaient l’air chauds et confortables. Puis une maintenance routinière a nécessité de déplacer un VIP
de service interne vers un autre sous-réseau à cause d’une re-segmentation réseau. L’enregistrement DNS a changé, et la moitié du parc a continué d’atteindre l’ancienne IP jusqu’à l’expiration des caches.
Certaines applications avaient leur propre cache DNS en plus, parce que pourquoi avoir un cache quand on peut en avoir trois.

L’incident n’était pas spectaculaire. Il était pire : il était lent. Pannes intermittentes, récupérations partielles, et une vague d’appels au support où chaque équipe voyait un symptôme différent.
Quelques résolveurs ont été vidés ; d’autres non. Certains utilisateurs ont été « réparés » en redémarrant leur portable. Ce n’est pas une réparation ; c’est un rituel.

Le post-mortem a abouti à une stratégie TTL plus nuancée : TTL bas pour les endpoints participant au failover/migration, TTL modéré pour les enregistrements stables, et des runbooks clairs
pour l’invalidation des caches. Ils ont aussi introduit la pratique d’abaisser temporairement les TTL avant des basculements planifiés—parce que la prévoyance opérationnelle coûte moins cher que les héroïques.

Leçon : une « optimisation » DNS qui ignore la vélocité des changements n’est que de la douleur différée avec de meilleurs graphiques.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la journée

Une entreprise financière appliquait le split-horizon pour plusieurs noms critiques : portails d’authentification, API internes, et quelques endpoints partenaires joignables uniquement sur des
réseaux privés. Ils avaient deux niveaux de résolveurs récursifs par datacenter, plus un cluster autoritatif interne pour corp.company.com. Rien de fancy—juste redondant, monitoré et documenté.

Un matin, un changement réseau en amont a causé une perte de paquets intermittente vers un des noeuds autoritatifs. Les résolveurs récursifs ont commencé à expirer pour un sous-ensemble de requêtes.
C’est souvent là que les choses dégénèrent en « le DNS est en panne », suivies de redémarrages aléatoires et d’un gel des changements.

Mais leur pratique ennuyeuse a joué : ils avaient des vérifications DNS continues depuis chaque site qui interrogeaient un enregistrement canari et mesuraient la latence.
L’alerte n’était pas « DNS down ». C’était « latence DNS augmentée, noeud autoritatif A injoignable par intermittence depuis le site X ». Ils avaient aussi les logs de requêtes prêts à être activés brièvement,
et un chemin de secours connu.

Ils ont évacué le noeud autoritatif défaillant de l’ensemble des forwarders des résolveurs, le trafic s’est stabilisé, et l’incident s’est terminé sans toucher les déploiements applicatifs.
Plus tard, le réseau a corrigé la perte de paquets. Pas de drame, pas d’héroïsme, pas de « on a rebooté tout et ça a marché ».

Leçon : la redondance est la condition minimale. L’observabilité et le basculement contrôlé sont ce qui vous empêche de deviner à 3h du matin.

Listes de contrôle / plan étape par étape

Plan étape par étape : implémenter le split-horizon sans se faire du mal

1) Définir les noms et les audiences

• Listez les FQDN qui ont besoin de réponses internes vs externes différentes.
• Définissez « interne » par la joignabilité (sous-réseaux/routes VPN), pas par « gens qu’on aime ».
• Décidez si les appareils en mobilité doivent fonctionner sans couture (généralement oui).

2) Choisir le point d’application

• Privilégiez les overrides récursifs/forwarding conditionnel quand l’autoritatif public est détenu par une autre équipe/fournisseur.
• Utilisez des vues autoritatives quand vous devez publier la même zone avec deux jeux de réponses et que vous contrôlez le DNS autoritatif.

3) Construire la redondance des résolveurs en premier

• Au moins deux résolveurs récursifs internes par site ou par domaine de panne.
• Verrouillez la récursion aux réseaux internes seulement.
• Surveillez la latence des requêtes, le taux de SERVFAIL et la santé des upstreams.

4) Implémenter les overrides de façon ciblée

• Surchargez des noms d’hôtes spécifiques (A/AAAA/CNAME) avant de surcharger des zones entières.
• Si vous devez surcharger une zone, assurez-vous de pouvoir servir une vue de zone complète, pas une ombre partielle.

5) Bien régler les TTLs et planifier les migrations

• Utilisez des TTL bas pour les noms susceptibles d’être déplacés pendant des incidents ou des déploiements.
• Abaissez le TTL avant les basculements planifiés ; remontez-le ensuite si approprié.
• Souvenez-vous de la mise en cache négative ; ajustez le SOA si nécessaire pour les zones dynamiques.

6) Valider depuis plusieurs points de vue

• Depuis le LAN, sur VPN, et depuis l’internet externe.
• Depuis au moins un client géré et un client « étrange » (BYOD/téléphone).
• Vérifiez les enregistrements forward et reverse là où ils importent.

7) Contrôler le comportement DoH/DoT

• Décidez si les clients peuvent utiliser des résolveurs DoH externes.
• Si non, faites appliquer via des politiques d’entreprise et des contrôles réseau quand c’est possible.
• Si oui, acceptez que les noms internes ne se résoudront pas à moins de fournir un endpoint DoH interne.

8) Documenter la liste « ce qui casse si le DNS casse »

• Auth (Kerberos/OIDC), dépôts de paquets, dépendances de synchronisation temporelle, endpoints PKI internes.
• Priorisez la surveillance pour ces noms et zones.

Checklist opérationnelle : avant de changer le split-horizon

• Exécutez named-checkconf/named-checkzone (ou équivalent) avant reload/restart.
• Confirmez quels clients sont dans quelle vue / quel chemin de forwarding ils utilisent.
• Abaissez les TTLs à l’avance si vous avez besoin d’un rollback rapide.
• Ayez un plan de rollback qui ne nécessite pas de « se souvenir » des modifications.
• Planifiez une fenêtre courte pour activer les logs de requêtes pendant le déploiement, puis désactivez-les (les logs sont utiles ; les disques pleins ne le sont pas).

FAQ

1) Le DNS split-horizon est-il la même chose que le split DNS sur les clients VPN ?

C’est lié, mais pas identique. Le split-horizon est « des réponses différentes selon l’endroit où on pose la question ». Le split DNS sur VPN est « envoyez certaines
requêtes de domaine seulement vers les serveurs DNS du VPN ». Vous voulez souvent les deux : le VPN route les domaines internes vers des résolveurs internes, et ces résolveurs fournissent
les réponses internes.

2) Puis-je utiliser .local pour des noms internes ?

Non. Beaucoup de systèmes considèrent .local comme territoire mDNS. Vous pouvez y arriver dans certains environnements, mais vous paierez continuellement en comportements
de résolution étranges et temps de débogage.

3) Puis-je juste exécuter deux serveurs DNS séparés et basculer le DHCP selon le réseau ?

Vous le pouvez, et parfois c’est suffisant. Le mode panne est la mobilité et les réseaux mixtes : appareils avec résolveurs en cache, overlays VPN, et interfaces multiples.
Le split-horizon est ce que vous faites quand « juste DHCP » cesse d’être déterministe.

4) Quelle est la façon la plus sûre de surcharger quelques noms publics en interne ?

Faites-le au niveau récursif : overrides local-data (Unbound), overrides d’hôtes (dnsmasq), ou forwarding conditionnel pour un sous-domaine interne dédié.
Évitez de devenir autoritatif pour une zone publique entière à moins de pouvoir la servir complètement.

5) Comment empêcher que des enregistrements internes fuient vers l’extérieur ?

N’exposez pas les résolveurs récursifs à Internet. Verrouillez la récursion avec des ACLs. Si vous utilisez des vues, validez la classification des ACL et testez depuis des points
externes. Faites aussi attention aux logs et exports de monitoring—les noms fuient aussi via la télémétrie.

6) Le split-horizon casse-t-il DNSSEC ?

Ça peut. Si les clients valident DNSSEC et que vous surchargez des enregistrements dans une zone signée sans la chaîne de signature correcte, vous pouvez déclencher des échecs de validation.
Gardez les overrides au niveau récursif sous votre contrôle, ou assurez-vous que votre configuration autoritative gère la signature de façon cohérente entre les vues.

7) Pourquoi j’obtiens des réponses différentes depuis des machines différentes sur le même LAN ?

Généralement une des raisons suivantes : résolveurs différents configurés, données en cache avec TTL restant différent, ou sélection DNS par interface (surtout sur les portables avec VPN,
Wi‑Fi et Ethernet docké). Commencez par confirmer les paramètres du résolveur et interrogez le même serveur explicitement avec dig @server.

8) Ai-je besoin de la résolution inverse (PTR) pour des services internes ?

Pas toujours, mais quand vous en avez besoin, vous en avez vraiment besoin : corrélation de logs, certains outils de sécurité, certains flux d’authentification, et le bon sens humain.
Si vous construisez un split-horizon pour quelque chose de critique, traitez les zones inverses comme faisant partie du système, pas comme de la décoration.

9) À quel niveau le TTL doit-il être pour des enregistrements de basculement ?

Assez bas pour que la récupération se fasse en minutes, pas en heures—classiquement 30–300 secondes. Ensuite testez la charge de requêtes et assurez-vous que vos résolveurs peuvent la supporter.
Souvenez-vous aussi que des clients et des bibliothèques peuvent cacher le DNS indépendamment du TTL.

10) Est-ce acceptable de CNAME des noms internes vers des noms publics ou l’inverse ?

Parfois, mais prudence : les chaînes CNAME traversent des frontières et compliquent le comportement split, la mise en cache et les attentes TLS. Préférez des A/AAAA directes quand vous avez besoin
de réponses déterministes, surtout pour des services critiques.

Conclusion : prochaines étapes pratiques

Le DNS split-horizon est un de ces modèles d’infrastructure qui paraît « simple » jusqu’à ce que vous l’osiez sous des conditions réelles : appareils en mobilité,
VPN, caches, DoH, et la change occasionnelle bien intentionnée qui transforme votre namespace en art performance.

Prochaines étapes qui rapportent vite :

• Choisissez votre modèle (vues autoritatives vs overrides récursifs) et notez pourquoi.
• Inventoriez précisément les noms qui nécessitent des réponses split ; gardez la liste petite et intentionnelle.
• Mettez en place des résolveurs récursifs internes redondants et verrouillez la récursion.
• Testez depuis trois points de vue : LAN interne, VPN, et extérieur à l’organisation.
• Intégrez votre runbook de « diagnostic rapide » dans la réalité des astreintes : les commandes ci-dessus, plus un nom canari connu-good.

L’objectif n’est pas un DNS brillant. L’objectif est une résolution de noms ennuyeuse qui reste correcte pendant que tout le reste brûle.