Un développeur appelle depuis chez lui : « L'API répond en 20 ms au bureau, 800 ms dehors. » Vous ouvrez dig api.example.com sur le laptop : l'IP est celle du load balancer public. Lui, connecté au VPN, obtient l'IP d'un pod interne non routé depuis Internet. Le ticket devient urgent quand la prod déploie un certificat valide seulement sur le nom interne.
Le split-horizon existe pour servir deux vérités DNS légitimes selon l'origine de la requête. Mal câblé, il devient une machine à confusion : fuites d'IP privées, certificats TLS incohérents, caches resolver qui mentent.
Principe : une question, plusieurs réponses
Le split-horizon (ou split DNS) renvoie des enregistrements différents selon le réseau source : bureau/VPN vs Internet. Un db.example.com peut pointer vers 10.0.1.50 pour les admins et 203.0.113.10 pour le public.
C'est normal et souvent souhaitable pour réduire la latence interne et éviter d'exposer des services d'administration. Ce n'est pas du DNS menteur au sens malveillant : c'est une politique de visibilité.
Où ça casse en production
| Symptôme | Cause fréquente |
|---|---|
| Site public inaccessible en interne | Hairpin NAT absent, split mal configuré |
| IP RFC1918 dans VirusTotal | Zone interne servie publiquement par erreur |
| Certificat SAN manquant | Nom interne utilisé par le front public |
| Résolution lente | Forwarders internes/externes en boucle |
Le pire scénario : un enregistrement interne synchronisé vers un DNS public par script cron non relu.
Modèles de déploiement
Deux zones : corp.internal (non déléguée) + example.com (publique). Clair pour les équipes.
Vues BIND / policies Unbound : un moteur, ACL par subnet. Exige discipline de config.
DNS cloud + Private Link : Route 53 Resolver, Azure Private DNS, Cloud DNS private — la frontière devient réseau + IAM.
Choisissez selon qui opère le DNS et combien de sites physiques vous avez.
Synchronisation et gouvernance
Les enregistrements communs (MX, TXT SPF, DKIM) doivent rester identiques des deux côtés sauf exception documentée. Automatisez la réplication des parties communes ; isolez les overrides internes dans des fichiers ou labels dédiés.
Chaque changement doit répondre : « Qui voit quoi ? » et « Quel resolver est utilisé sur laptop VPN coupé ? »
Tests avant chaque changement
Depuis Internet : dig +trace, DNSSEC si actif, comparer avec un resolver public.
Depuis VPN : même requêtes, vérifier IP et TTL.
Depuis réseau invité : s'assurer qu'aucun forwarder interne n'est accessible.
Journalisez les diffs de zone comme du code applicatif.
Documentation vivante
Tableau : FQDN | vue interne | vue externe | owner | last verified.
Review à chaque onboarding service interne.
Test VPN off + on same laptop quarterly.
Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.
Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.
Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.
Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.
Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.
Tenez runbook daté, métriques avant/après, revue post-incident — la discipline cumulative évite la panique du vendredi soir.
Documentation split-horizon
Table FQDN interne/externe/owner/verified. Test VPN laptop trimestriel. TLS interne : renouvellement couvre les deux vues.
Décider et avancer sans angle mort
- Lister chaque FQDN avec sa réponse interne, externe, le propriétaire métier et la date de dernière vérification.
- Séparer les zones — views BIND, policies Route 53 split, ou DNS interne dédié ; évitez un seul fichier zone « presque pareil ».
- Tester depuis le laptop — VPN activé et désactivé sur les mêmes URLs critiques (API, git, monitoring).
- Restreindre les transferts AXFR — alertez si la serial SOA diverge entre vues ou si un secondaire public fuit une IP interne.
- Documenter le runbook onboarding — chaque nouveau service interne ajoute une ligne au tableau avant mise en prod.
Pour dimensionner l'hébergement DNS interne vs managé, parcourez l'annuaire, le comparateur et nos guides réseau.
Questions fréquentes
Split-horizon et DNS public, peut-on mélanger ?
Oui, mais seules les vues externes doivent être déléguées publiquement. Les noms internes ne doivent jamais apparaître dans une zone servie sur Internet sans filtrage.
Faut-il deux zones distinctes ou une seule avec vues ?
Deux zones séparées (internal.example / example.com) simplifient la gouvernance. Les vues sur un même serveur BIND conviennent si la politique ACL est stricte et auditée.
Que faire quand le VPN tombe ?
Prévoyez un resolver de secours, des enregistrements de bascule temporaires côté externe, et un runbook qui n'exige pas l'accès interne pour restaurer le service public.
Comment éviter qu'un laptop hors VPN résolve en interne ?
N'exposez pas de forwarders internes sur des réseaux non maîtrisés ; utilisez des suffixes DNS internes non délégués publiquement et des policies split-tunnel explicites.
Avant d'ajouter une vue interne, écrivez la phrase : « Un ingénieur sans VPN doit pouvoir… » — si la fin est « …rien », vous avez un point unique de défaillance.