Split DNS pour VPN en 2026 : guide complet, sécurité, cas pratiques et configuration pas à pas

Qu’est-ce que le Split DNS et pourquoi c’est important en 2026

Définition de base et métaphore simple

Le Split DNS est une méthode où différents domaines sont résolus par des serveurs DNS différents, et la redirection vers ces serveurs dépend de règles, de profils VPN et de politiques client. Imaginez un portier à la porte : selon le visiteur, il le dirige. Les domaines externes vont aux résolveurs publics, tandis que les noms internes de l’entreprise sont dirigés vers des DNS privés d’entreprise. Résultat : une séparation claire, moins de fuites, plus de vitesse et un contrôle qui garantit la sécurité. Ça paraît simple, mais le diable est dans les détails, et en 2026, ils sont encore plus nombreux.

Pourquoi cette approche revient-elle au premier plan ? Nous sommes massivement passés à l’hybridation cloud, distribuons nos bureaux, adoptons le Zero Trust, et utilisons DoH, DoT, et même DNS-over-QUIC. Le DNS plat traditionnel ne suit plus : soit il expose trop d’informations à Internet, soit il casse les noms internes. Le Split DNS offre le juste milieu. C’est comme un feu tricolore à un échangeur complexe : la bonne voie, le bon signal, et personne ne double. En prime, il économise des millisecondes, voire des minutes quand il s’agit de déboguer des chaînes de résolution complexes.

Comment le Split DNS s’intègre au VPN

Le VPN crée un tunnel logique. Ensuite, viennent les règles : quel domaine se résout via le DNS d’entreprise, lequel passe par un résolveur public. En général, on configure un transfert conditionnel par liste de zones et domaines, comme corp.local, int.company, svc.cluster.local, en les orientant vers des adresses DNS côté bureau ou cloud. Le reste va vers le fournisseur de l’utilisateur ou vers un résolveur DoH géré et de confiance.

Point important : la politique du client. Windows utilise des tables de règles (NRPT), macOS et iOS avec des profils de configuration orientent les domaines vers certains résolveurs, Android divise partiellement le trafic avec un DNS privé, et Linux via systemd-resolved gère les routes par domaines. Le résultat est clair : le VPN ne doit pas diriger tout le trafic à l’extérieur, il intercepte précisément les domaines voulus. Voilà pourquoi le Split DNS est pratique à la fois pour la performance et la confidentialité.

Différence entre Split DNS et Split Tunneling

Premier malentendu. Le Split Tunneling divise le trafic par sous-réseaux ou applications, contournant partiellement le VPN. Le Split DNS ne divise que la résolution des noms de domaine, ensuite le routage peut être quelconque, y compris tunnel complet. On peut avoir un tunnel VPN complet pour la sécurité, tout en résolvant les domaines externes via un DoH public. Ou inversement, partager le trafic mais forcer tout le DNS via un résolveur interne. Ce sont des mécanismes indépendants, souvent combinés.

Pourquoi c’est important ? Parce que vous pouvez affiner l’équilibre. Moins de risque de fuite sur les noms internes ? Résolvez-les uniquement via DNS interne, et les externes via DoH sur le tunnel. Une meilleure vitesse pour YouTube ou CDN ? Laissez les domaines externes se résoudre près de l’utilisateur en gardant tout ce qui est sensible à l’intérieur. La flexibilité est énorme, avec parfois des gains de dizaines de pourcents en temps de réponse.

Quand le Split DNS n’est pas nécessaire

Pas de domaines internes, pas de zones privées, pas de différence entre noms internes et externes : alors le Split DNS a peu d’intérêt. C’est rare en entreprise, mais cela arrive dans de petites équipes utilisant uniquement du SaaS sans serveurs internes. Autre cas : clients légers strictement isolés sans accès Internet, où la résolution des noms est complètement locale, donc pas besoin de séparation.

Mais dans la majorité des organisations en 2026, il y a toujours des noms internes. Active Directory, services Kubernetes, services en VPC/VNet, API privées, portails internes, service discovery via Consul ou Istio. Là où il y a des zones internes, le Split DNS est un atout. Il évite les résolutions incorrectes vers l’extérieur, protège la confidentialité, et offre une expérience utilisateur transparente : tout fonctionne en coulisses, sans bidouillage des fichiers hosts.

Architecture du Split DNS : les briques fondamentales

Rôles des serveurs DNS : interne, externe et récursif

Dans l’architecture Split DNS, on a toujours au moins deux types de résolveurs : internes (autoritaires pour les zones privées et souvent récursifs pour les hôtes internes) et externes (résolveurs publics ou autoritaires pour les zones publiques). Parfois, un troisième niveau apparaît : résolveurs en edge dans le cloud, qui font cache et distribution. Ce schéma en étages réduit la latence et la charge sur les liens principaux.

Les DNS internes connaissent vos zones privées : par exemple corp.local, priv.company, internal.zone, svc.cluster.local. Les résolveurs publics n’en ont aucune idée et ne doivent pas en avoir. Le récursif met en cache les résultats, tandis que les serveurs autoritaires donnent la réponse finale. Important de bien dissocier : les zones internes restent à l’intérieur, et les externes ne doivent pas entrer sans contrôle. C’est la garantie d’une route propre, prévisible et maîtrisée.

Zones, transfert conditionnel, stub et forward

Le classique du Split DNS est le Conditional Forwarding, où vous définissez une règle : si le domaine finit par .corp.local, envoyer vers 10.10.10.10 et 10.10.10.11. Les zones forward conviennent bien à l’intégration inter-unités ou lors de fusions-acquisitions : chaque équipe gère ses zones, mais la politique globale répartit les requêtes correctement. Les zones stub simplifient la délégation : vous ne copiez pas les enregistrements, vous indiquez qui est autoritaire, et le résolveur sait où aller.

Pourquoi c’est pratique ? Vous évitez les doublons. Pas besoin d’avoir les mêmes enregistrements en deux endroits et risquer une désynchronisation. En 2026, la plupart des DNS d’entreprise gèrent forward, stub et modes mixtes. En plus, on peut configurer RPZ pour filtrer le contenu malveillant et bloquer les domaines risqués à la frontière sans toucher les zones internes. Résultat : un routage logique et administré pour chaque nom.

Résolveur sur client : ordre, cache et durée de vie

Le client est notre petit chef d’orchestre. Il décide vers qui envoyer en premier, comment respecter le TTL, et combien de temps garder le cache. Sous Windows, c’est géré par NRPT et les priorités d’interfaces. macOS et iOS utilisent des profils de configuration avec le serveur DNS et la liste des domaines associée. Android a des politiques avec DNS privé et parfois MDM avec contrôle applicatif. Linux, via systemd-resolved, sait router par domaines et interfaces, un vrai allié du Split DNS.

Le cache est crucial. Vous ne voulez pas interroger le cloud chaque minute pour un même enregistrement A. Mais un TTL trop long nuit aux mises à jour et migrations. En 2026, un TTL raisonnable pour services dynamiques internes est de 30 à 300 secondes, pour les stables de 15 à 60 minutes. Cela évite de saturer les résolveurs et bloque pas les déploiements. Pensez aussi au cache négatif pour que les NXDOMAIN ne bombardent pas le système à répétition.

DNS chiffré : DoH, DoT et DNS-over-QUIC

Le chiffrement DNS est devenu un standard de facto. DoH, DoT, et DNS-over-QUIC protègent contre la surveillance et la falsification. Mais avec un VPN, on a déjà du chiffrement. Faut-il un double ? Parfois oui. Si vous voulez vous prémunir du spoofing DNS sur le réseau local avant l’entrée dans le tunnel, ou forcer la résolution des domaines externes via un DoH de confiance même avec VPN actif. Alors vous activez DoH côté client, en réglant bien les règles pour que les domaines internes ne sortent pas.

Le principal est d’éviter les conflits. Si le client force DoH pour toutes les requêtes, il peut ne pas voir vos zones privées. La solution : une politique Split DNS qui précise clairement : les domaines internes passent par le résolveur d’entreprise à l’intérieur du tunnel, les externes par DoH vers un fournisseur approuvé ou votre résolveur managé. En 2026, beaucoup de MDM et apps VPN supportent ça nativement, il suffit d’appliquer les règles méticuleusement.

Cas d’usage en entreprise du Split DNS

Active Directory et zones internes

Si vous avez AD, le Split DNS s’impose dans l’architecture. Des domaines comme corp.local ou ad.company.internal doivent être résolus strictement par les contrôleurs de domaine ou internes de confiance. Simple raison : les enregistrements SRV et LDAP sont critiques pour l’authentification, GPO et services. S’ils sortent par erreur, attendez-vous à un flot de tickets et des nuits blanches. Le Split DNS oriente les requêtes AD via les canaux internes, évitant les mauvaises surprises.

En plus, AD aime la rigueur : les enregistrements PTR, des CNAME corrects, un GC et des sites bien configurés. La séparation DNS facilite le diagnostic. Vous voyez quelle zone interne est servie par quels serveurs, et contrôlez indépendamment leur réplication. On gagne du temps à chercher l’erreur. Plutôt que de chasser partout, vous allez directement au bon endroit réparer. Avec le travail à distance et les connexions hybrides, ce sont des heures, voire des jours sauvés.

Environnements hybrides multi-cloud

AWS, Azure, GCP, et on-premise : la norme en 2026. Chaque plateforme gère ses zones privées ou s’intègre au DNS local. Le Split DNS permet d’orienter les requêtes entre elles de façon transparente : un service AWS est résolu via Route 53 Private Hosted Zone, un service Azure via Private DNS, les systèmes locaux via BIND ou Windows DNS. L’utilisateur ne s’en rend pas compte, vous pilotez tout depuis une console de politiques unique.

Ajoutez Kubernetes. Les noms internes type svc.cluster.local doivent être résolus uniquement dans le cluster ou via un résolveur d’entreprise qui sait vers CoreDNS où rediriger. Le conditional forwarder fait communiquer ces mondes. Indispensable avec les service mesh et interactions inter-clusters. Sans Split DNS, attendez-vous à des timeouts imprévisibles et des boucles bizarres. Avec lui, vous avez une route nette et un comportement attendu.

Séparation par business unit et fusions-acquisitions

Quand une société en rachète une autre, la première difficulté, ce sont les collisions de noms et zones. Les deux côtés ont internal.local, mail.internal, api.int, sans oublier les reliquats historiques. Le Split DNS avec zones forward et stub aide à gérer cette phase en douceur. Vous déléguez temporairement des zones, réalisez la convergence des politiques, et unifiez les schémas de noms petit à petit. Les utilisateurs ne voient pas le double monde sous le capot, grâce à un résolveur unique avec des règles bien définies.

Au sein d’un même groupe, c’est pratique aussi. Par exemple, la sécurité bancaire gère ses zones et filtrages RPZ, tandis que la R&D a ses zones expérimentales à TTL court. Avec le Split DNS, vous posez les rails sans empêcher les équipes locales d’avancer vite. C’est un équilibre entre contrôle et agilité. Plus l’entreprise est rapide, plus il faut éviter un gros carcan homogène, en laissant de la flexibilité en périphérie.

Sites distants, SD-WAN et SASE

Les sites distants fonctionnent avec SD-WAN et SASE, les utilisateurs mobiles sur LTE. Le Split DNS permet d’indiquer un résolveur par scénario. Sur site : cache local et forward vers le hub. En mobilité : agent client qui sait quels domaines envoyer dans le tunnel, lesquels résoudre localement via DoH. Hors ligne temporaire ? Le cache et le cache négatif aident à patienter le temps que la connexion revienne.

Dans l’architecture SASE, le résolveur devient un contrôleur politique. Il vérifie catégories de domaines, niveaux de risque, menaces, décide d’autoriser, de rediriger ou de bloquer. Le Split DNS dans ce paysage est une carte : quels domaines sont de confiance, lesquels passent seulement par le tunnel, lesquels en quarantaine. Le tout sans changer les habitudes utilisateurs. Ils tapent des adresses, cliquent des liens, et le système choisit sans interruption la bonne route.

Sécurité et vie privée : garder DNS sous contrôle

Fuites DNS : comment les détecter et les combler

Une fuite DNS survient quand des requêtes pour des noms internes ou des domaines sensibles quittent le chemin prévu. Par exemple, vont sur Internet en contournant le VPN ou vers un résolveur public qui enregistre tout. On vérifie de trois façons : logs système client, supervision au niveau passerelle, tests synthétiques qui envoient des listes de domaines et comparent où arrivent les réponses. En 2026, des agents disponibles surveillent passivement la pile DNS et alertent si la politique est violée.

On colmate les fuites par politique et priorités. On écrit des règles explicites pour zones privées, on désactive les résolveurs publics automatiques côté client, et on utilise DoH/DoT vers le résolveur d’entreprise pour éviter l’interception. Ne négligez pas les réseaux invités Wi-Fi, où un attaquant peut injecter un faux DHCP. Un client avec une politique Split DNS claire sait reconnaître ses domaines et refuse les mauvaises indications.

Filtrage, RPZ et Zero Trust

RPZ — Response Policy Zone — est notre filtre anti-toxines. Vous pouvez bloquer phishing, malwares et C2 au niveau DNS, sans attendre l’antivirus. Associé au Split DNS, c’est un outil fin : les domaines internes peuvent contourner le filtre si prévu, les externes se font tester et bloquer. Zero Trust ajoute du contexte : qui est l’utilisateur, son profil de risque, son appareil. La même zone peut être gérée différemment selon les signaux de risque.

Attention à ne pas surfiltrer. Une trop grande agressivité génère des faux positifs, surtout avec DevOps et environnements de test où les noms sont dynamiques. Bonne pratique : listes blanches pour zones critiques, processus d’exceptions clairs pour 24-72 heures, et surveillance des retours en arrière. Le filtrage doit être comme une ceinture de sécurité : il ne gêne pas la route mais sauve la vie au bon moment.

Confidentialité et minimisation des logs

Le DNS raconte votre vie en ligne. Pas besoin de stocker plus que nécessaire. Minimisez les données personnelles : ne loguez pas les requêtes complètes quand c’est inutile, tronquez les IP au préfixe, stockez seulement des statistiques agrégées. En 2026, de plus en plus d’entreprises adoptent un stockage court (7–30 jours) pour les logs bruts et gardent uniquement des agrégats à long terme. Suffisant pour enquêtes et tendances, plus sûr pour les utilisateurs.

Pensez au consentement et aux obligations légales. Expliquez dans la politique quelles zones sont filtrées, quelles données sont conservées et combien de temps. Ça sonne bureaucratique ? Un peu, mais ça évite bien des tracas lors d’audits et construit la confiance en interne. Quand les règles sont claires, on travaille plus sereinement, sans bricoler à l’aveugle.

DNSSEC, DANE et hygiène mail

DNSSEC signe les réponses pour éviter les falsifications. Pour les zones internes, c’est parfois surdimensionné, mais pour les publiques c’est désormais la norme. DANE complète en liant les certificats au DNS. Combiné au Split DNS, vous séparez responsabilités : rapide et flexible en interne, strict et signé dehors. Cela réduit les risques MITM et facilite l’automatisation des vérifications.

Les enregistrements mail SPF, DKIM et DMARC méritent une attention particulière. Assurez-vous qu’ils soient cohérents entre zones internes et externes. Si vous avez différents domaines pour systèmes mail internes et externes, le Split DNS doit garantir que clients et serveurs voient les enregistrements prévus. Autrement, c’est livraison instable, perte de réputation et files d’attente saturées.

Configuration pas à pas du Split DNS pour stacks populaires

Windows Server DNS et VPN IKEv2 ou Always On VPN

Commencez par les zones. Dans Windows DNS, créez les zones internes de recherche directe pour domaines privés. Configurez ensuite les Conditional Forwarders vers les serveurs autoritaires des domaines voisins, dans d’autres segments ou cloud. Vérifiez la réplication, activez un TTL raisonnable, et ajoutez les PTR nécessaires pour AD et logs. Puis la politique client : via GPO, déployez NRPT qui redirige les domaines *.corp.local et *.svc.company vers les DNS du tunnel.

Pour VPN IKEv2 ou Always On VPN, inscrivez dans le profil les adresses DNS d’entreprise et la liste des domaines. Activez le filtrage des règles split-domaine pour éviter que le client tente de résoudre les noms privés via un résolveur public. Testez pas à pas : d’abord les zones internes, puis externes, enfin les scénarios mixtes comme un domaine externe redirigé vers un reverse proxy interne.

BIND ou Unbound avec WireGuard et OpenVPN

BIND offre flexibilité, Unbound rapidité et cache intégré. Créez une zone forward pour les domaines privés et indiquez les serveurs autoritaires. Pour les domaines externes, activez la récursion, mais orientez-la vers votre DoH/DoT upstream ou les conseils racines locaux. Dans WireGuard, ajoutez dans la config la liste des domaines au résolveur client ou appliquez des scripts qui ajustent systemd-resolved pour ces zones. En OpenVPN, utilisez push dhcp-option DOMAIN-ROUTE pour définir les routes DNS si le client le supporte.

Vérifiez soigneusement. Utilisez dig ou drill pour noms internes et externes. Comparez les temps de réponse avec cache activé ou non. Mesurez la charge du résolveur en pointe. Gardez les logs au début, puis réduisez la verbosité. Sans ça, vous serez noyé dans les événements et raterez l’essentiel au milieu du bruit.

pfSense ou OPNsense et DoT/DoH

pfSense et OPNsense disposent de résolveurs et forwarders intégrés. Configurez le Conditional Forwarding via l’interface graphique, en indiquant zones privées et adresses. Activez DoT pour les requêtes externes vers fournisseurs de confiance, et laissez le trafic interne en UDP classique ou TLS si la politique l’exige. Activez le cache et des limites raisonnables. Mettez en place un Health Check : le résolveur doit basculer vite vers un upstream de secours pour éviter les délais utilisateurs.

Important : si vous utilisez DoH sur clients, assurez-vous que vos règles ne cassent pas les domaines internes. Souvent, il faut forcer des exceptions pour zones internes et routage DNS strict par tunnel. Testez depuis différents réseaux — box domestique, réseau mobile, Wi-Fi invité — pour détecter les bizarreries réseau avant que les utilisateurs ne les remarquent.

MikroTik, Conditional Forwarding et routes

MikroTik avec RouterOS sait faire forwarder et cacher. Créez des routes statiques pour les domaines privés, indiquez les résolveurs internes, activez le cache avec limite TTL. Définissez des adresses de secours pour basculer si un noeud tombe. Si vous avez un accès hybride, créez des règles par interface VPN pour que le DNS des zones internes passe toujours via le tunnel.

Testez toute modification en groupes pilotes réduits. La réalité est têtue : un vieux routeur, un logiciel atypique. Mieux vaut détecter une incompatibilité en pilote qu’en production. Gardez vos templates de configuration sous versionning — ça sauve des heures en cas de retour en arrière.

Plateformes clientes et politiques

Windows 11 et 12 : NRPT, priorités et DoH

Windows peut cibler clairement des domaines vers des résolveurs via NRPT. Utilisez GPO ou MDM pour distribuer les règles : pour *.corp.local, *.int.company, *.svc.cluster.local, orientez vers DNS internes dans le tunnel. Activez Prefer DoH pour les résolveurs externes si vous souhaitez chiffrer la résolution externe, avec des exceptions pour les domaines internes. Vérifiez l’ordre des interfaces, pour que le VPN ait priorité sur les zones concernées.

N’oubliez pas le Split DNS avec Always On VPN. Le client doit comprendre quelles requêtes passeront par tunnel. En 2026, les clients gèrent mieux les scénarios mixtes, mais des conflits subtils restent. Tracez les logs au déploiement, créez un lab de test et suivez checklists avant un large déploiement.

macOS et iOS : profils, per-app VPN et NetworkExtension

macOS et iOS utilisent des profils de configuration pour définir listes de domaines, résolveurs, et règles per-app VPN. Pratique : vous pouvez router les apps d’entreprise via tunnel avec DNS interne, et laisser le navigateur utiliser DoH externe. La synchronisation est clé : si une app a son propre résolveur, assurez-vous qu’elle ne contredise pas la politique système.

En 2026, Apple a accéléré la pile DNS et amélioré le cache. Attention à la logique de retry : si le résolveur répond lentement, le système peut switcher vers un autre profil. Un réglage fin des timeout et priorités évite de faux basculements. Et optimisez les listes de domaines : pas une encyclopédie. Des règles courtes et précises sont toujours plus stables.

Android 14 et 15 : Private DNS et MDM

Android permet d’activer Private DNS via DoT et de gérer partiellement les règles via MDM. Si vous avez un agent d’entreprise, servez-vous-en pour Split DNS : domaines internes vers résolveur d’entreprise, le reste via DoT vers un fournisseur approuvé. Le per-app VPN aide à segmenter le trafic app par app, utile en BYOD où on ne veut pas toucher aux apps perso des employés.

Contrôlez les appareils de différents constructeurs. Chacun interprète parfois « créativement » les standards. Une politique identique sur papier fonctionne différemment sur deux modèles. Pilotes, retours utilisateurs, corrections rapides : c’est la recette pour éviter une avalanche d’avis négatifs. Et oui, expliquez l’intérêt aux utilisateurs. Lorsqu’ils comprennent les bénéfices, ils mettent plus volontiers à jour leurs profils et ne sabotent pas les réglages.

Linux : systemd-resolved et routages par domaines

systemd-resolved est excellent pour le Split DNS. Vous pouvez assigner des résolveurs par interface et domaine, fixer des priorités, activer cache et cache négatif. L’intégration avec NetworkManager simplifie la vie : quand le VPN monte, les règles s’appliquent, quand il descend elles s’enlèvent. Avec WireGuard, vous pouvez utiliser des scripts pour ajouter les routes DNS à la montée de l’interface.

Pensez aux spécificités des conteneurs et Kubernetes sur hôte. Si vous lancez des clusters dev ou gros conteneurs, ils peuvent utiliser leurs propres résolveurs. Assurez-vous que les zones d’entreprise ne disparaissent pas dans le vide. Mieux vaut fixer explicitement les règles en conteneur que d’aller chercher des timeouts étranges sur des services qui « se sont réparés tout seuls » au bout d’une demi-heure grâce au TTL.

Conseils pratiques et checklist

Planification des domaines et zones inverses

Commencez par une carte. Quelles zones sont internes, externes, où est l’autorité, où la récursion. Définissez les zones inverses pour les sous-réseaux clés et créez les PTR là où c’est utile pour les logs et la sécurité. Ne prenez pas de TLD exotiques pour internes, utilisez des zones privées standards ou des sous-domaines existants. Cela facilite les intégrations et élimine les risques de collision.

Évaluez comment les utilisateurs saisissent les adresses. S’ils utilisent des noms courts, vous devrez gérer suffixes de recherche et listes Suffix Search List fiables. Mais attention à ne pas en abuser : trop de suffixes engendrent des requêtes et délais inutiles. L’équilibre est 1 à 3 suffixes en général, plus des règles claires quand utiliser un FQDN.

Performance, cache et limites

Le cache est votre allié si vous maîtrisez le TTL. Pour services dynamiques, mettez un TTL court, et employez un cache agressif en périphérie : les résolveurs de sites déchargent les nœuds centraux. Activez la protection anti-tempête : limites par nom et blocages de retry infinis. En 2026, les résolveurs élastiques sont la mode : ils augmentent automatiquement leurs capacités sous charge et redescendent la nuit.

Profilez les temps de réponse. Un DNS normal se situe entre 20–40 ms interne et 40–120 ms externe. Des pics à 300–500 ms indiquent un souci : cache surchargé, problème upstream, conflit DoH/VPN. Localisez le goulot et gardez un SLO. Nous sommes à l’ère du SRE, le DNS aussi est une histoire SRE.

Monitoring, alertes et SLO

Activez trois niveaux de surveillance : tests synthétiques sur listes de domaines, métriques des résolveurs (QPS, NXDOMAIN, SERVFAIL, cache hits), et tracés de sessions utilisateurs pour incidents complexes. Configurez des alertes pas sur chaque micro-anomalie, mais sur des écarts persistants. Laissons le système supporter 10 minutes de pic avant d’éveiller un ingénieur nocturne.

Créez des dashboards : zones internes, externes, erreurs par type, percentiles de latence. Regardez p95 et p99, plus parlants que la moyenne. Formez votre équipe à les lire. Une bonne visualisation économise des heures de réunions. Compris vite, réparé vite, on revient vite aux priorités métier.

Documentation, formation et gestion des changements

Rédigez des règles claires et simples. Quelle zone est où, qui en répond, quelles exceptions sont autorisées et comment les formaliser. Les débutants et intervenants transverses doivent saisir le tableau en 10–15 minutes. C’est possible en évitant le jargon et en gardant l’essentiel. Un portail interne avec guides courts fait des miracles.

Appliquez une gestion des changements : petits lots, déploiements canaris, retours rapides. Testez chaque changement sur pilote et consignez les résultats. Les erreurs en Split DNS ne sont pas fatales, mais très agaçantes pour les utilisateurs. On peut donc les éviter avec de la discipline et en ne changeant pas tout d’un coup.

Cas réels : réussites et échecs

Banque de 30 000 employés

La banque avait trois zones AD et deux zones cloud privées, plus une vitrine publique dans un domaine séparé. Les utilisateurs se plaignaient de latences jusqu’à 1,5 s dans client bancaire et CRM. Nous avons mis en place Split DNS avec forward pour zones cloud, optimisé TTL à 120 s pour services stables et 30 s pour Kubernetes. Ajouté RPZ antiphishing. Résultat : p95 de résolution est passé de 420 ms à 110 ms, les logins sont devenus instantanés.

Le point bloquant ? DoH trop agressif sur clients captait les domaines internes via résolveur public. Corrigé par politique d’exceptions, tout s’est stabilisé. Leçon : ne faites pas confiance aux réglages par défaut, surtout sur un parc hétérogène.

Start-up multi-cloud avec déploiements rapides

La start-up avait prod sur AWS et tests sur GCP, avec CICD qui migrent entre zones toutes les deux semaines. Géré avec Split DNS et forward zones dynamiques automatisées depuis Git. Les développeurs voyaient les nouvelles entrées en quelques minutes, les utilisateurs résolvaient toujours les bonnes adresses. Le cache en périphérie économisait la bande passante.

Un bug rigolo est apparu avec CDN et ECS : le cache géo-sélectif était faussement choisi à cause de l’extension EDNS. Réglé en limitant ECS sur certains domaines. Parfois, le paramétrage fin, c’est un peu de magie. Au final, la livraison de contenu a gagné 12–18 % en p95.

Industrie et réseaux de sites

Usines, machines, SCADA et des dizaines de vieux contrôleurs. Là, le Split DNS évitait le chaos : les noms internes des systèmes d’usine étaient résolus localement et de manière prévisible. Nous avons déployé des résolveurs légers avec cache dans chaque site, configuré les forwards vers le hub, et appliqué des TTL stricts. Quand la liaison tombait, la production ne s’arrêtait pas grâce au cache qui contenait les enregistrements critiques.

Le souci venait des vieilles imprimantes, des récursifs inattendus, et des « smart » switchs avec leur propre DHCP. Nous avons stoppé les distributions tierces, renforcé les contrôles et ajouté du monitoring sur les portails pour repérer l’origine des requêtes. Après une semaine de nettoyage, le réseau est devenu plus calme, et les incidents rares.

Secteur public et conformité

Dans ce secteur, la confidentialité est particulièrement stricte. Nous avons segmenté les zones, déployé DNSSEC sur les domaines publics, limité la conservation des logs personnels, et imposé un stockage déterminé. Les requêtes externes passaient via DoH vers des résolveurs de confiance, les internes restaient dans le périmètre VPN. L’équipe audit était satisfaite, les utilisateurs n’ont rien remarqué — et c’est le plus beau compliment.

Le point clé : documentation et reproductibilité. Sans règles claires, un audit tourne vite au cauchemar. Avec Split DNS, vous montrez votre transparence : voici les règles, les surveillances, les logs, les exceptions. Tranquille, simple, sans mystères.

Erreurs fréquentes et corrections

Doublons d’enregistrements et split-horizon

La pire erreur : avoir deux copies des mêmes enregistrements à plusieurs endroits. Un jour ils concordent, celui d’après ils divergent, et les utilisateurs finissent désespérés. La solution : utiliser forward ou stub plutôt que de copier. Qu’une source fasse autorité, le reste est aménagement de la route. C’est plus simple à gérer et à expliquer pourquoi une réponse est celle-ci et pas une autre.

Le split-horizon n’est pas intrinsèquement mauvais, mais demande une discipline stricte. Si vos réponses diffèrent entre clients internes et externes, surveillez le TTL et mettez à jour les deux en même temps. Sinon, vous aurez des cas où un utilisateur mobile voit une chose, un collègue au bureau une autre. Très déconcertant.

Mauvais ordre de résolveurs sur clients

Un autre piège. Le client peut interroger d’abord le résolveur public, puis celui d’entreprise, ce qui fait que les noms internes « n’existent pas ». On corrige via priorités d’interfaces, règles NRPT, et routes DNS explicitement définies. Testez le comportement sur chaque plateforme. N’espérez pas que « par défaut ça marche bien ».

Ajoutez un diagnostic simple pour le support : une checklist de 5–7 étapes pour savoir où va la requête. Cela réduit le temps de résolution par plusieurs fois. L’équipe ne noiera plus les ingénieurs avec les questions basiques, mais investiguera vite et orientera bien l’incident.

EDNS, ECS et surprises CDN

Les extensions EDNS et ECS influencent la localisation des caches CDN. Parfois, elles font que l’utilisateur obtient un nœud pas du tout proche. Vérifiez si votre résolveur transmet ECS, et comment. Pour certains domaines, mieux vaut restreindre ECS pour plus de stabilité dans la réponse. Les résultats surprennent souvent : la latence baisse, les pics disparaissent, et les plaintes aussi.

N’hésitez pas à tester sur un petit groupe. Mesurez avant de déployer globalement. Les fournisseurs CDN aiment « tourner les boutons » côté serveur, et un réglage fin peut vous donner un gain de 10–20 % de vitesse si vous êtes en phase avec leur politique.

Certificats, PTR et zones inverses

SSL et mutual TLS détestent le désordre DNS. Si CN et SAN pointent vers des domaines parfois mal résolus, vous aurez des erreurs de handshake. Mettez de l’ordre : noms internes pour résolveur interne, externes pour externe. Maintenez les PTR sur les systèmes clés, sinon diagnostics et SIEM seront comme un mots croisés sans indices.

Les zones inverses sont souvent oubliées. Puis on s’étonne que l’analyse ne marche pas ou que l’audit marque tout comme des « visiteurs inconnus ». Activez les PTR là où c’est important, et fixez un TTL sage. C’est un détail qui sauve les nerfs.

Tendances 2026 et quoi déployer dès maintenant

ZTNA et périmètre défini par logiciel

Zero Trust et SDP transforment l’architecture d’accès. Le Split DNS devient partie de la politique contextuelle : le résolveur voit utilisateur, appareil, application, risque, et décide où envoyer la requête et quelle réponse donner. On passe du simple « où interroger » à un « pourquoi répondre et à qui » intelligent.

En pratique : agent sur appareil, politique cloud, résolveur managé avec filtrage, routage dynamique via passerelle ZTNA. Idée simple, réalisation complexe. Mais les gains en contrôle et sécurité sont énormes. Commencez petit et évoluez avec la maturité de votre équipe.

DNS-over-QUIC et Encrypted ClientHello

QUIC accélère et rend la connexion plus résiliente à la perte de paquets. DNS-over-QUIC est la continuité logique. En 2026, clients et résolveurs ajoutent ce support activement. Parallèlement, Encrypted ClientHello masque les détails du handshake TLS. Pour le Split DNS, c’est un plus côté confidentialité : moins de métadonnées visibles au périmètre, plus dur pour la surveillance.

Le revers ? Compatibilité et diagnostic. Testez bien. L’activation du QUIC peut perturber certains vieux proxys ou IDS. Mais la tendance est claire : d’ici un à deux ans, ce sera le mode chiffré dominant pour beaucoup de scénarios.

Résolveurs managés avec suggestions IA

Les résolveurs managés de 2026 font beaucoup : auto-réglage du TTL, mise en cache adaptative, alertes sur zones problématiques, anomalies basées sur machine learning. Ils détectent si un domaine devient lent et proposent de baisser le TTL ou changer l’upstream. Ou remarquent qu’un sous-réseau surcharge le cache et suggèrent un rééquilibrage.

Ce n’est pas de la magie, mais presque. Le plus important : garder la main. Toute modification automatique doit passer par un Change Review, même accéléré. Une erreur de résolveur, c’est une demi-journée de chaos demain. Oui à la rapidité, mais pas aux surprises. Les suggestions intelligentes, oui. Les systèmes autonomes, prudence et gradualité.

Réglementation, conformité et données

Les exigences de confidentialité montent. Les entreprises revoient leurs politiques de retention, mettent en place pseudonymisation, séparent métriques opérationnelles et données personnelles. Le Split DNS est du côté vertueux : il réduit les « regards superflus » et oriente les requêtes sensibles vers des résolveurs de confiance. Les logs deviennent plus épurés, le risque de fuite diminue, et l’audit est plus serein.

Un conseil au quotidien : documentez quelles catégories de domaines vont où, qui voit quelles données, et ce qui est logué. Ce n’est pas passionnant, mais ça sauve la mise en cas d’incident. Vous répondez vite aux questions essentielles, sans perdre de temps en recherches chaotiques.

FAQ : l’essentiel en bref

Qu’est-ce que le Split DNS en termes simples

C’est quand différents domaines sont résolus par des serveurs DNS distincts selon des règles. Les noms internes vont au résolveur d’entreprise via VPN, les externes vers un résolveur public ou managé. L’utilisateur voit simplement « ça marche », vous contrôlez confidentialité, vitesse et sécurité.

Quelle différence entre Split DNS et Split Tunneling

Le Split DNS divise uniquement la résolution DNS. Le Split Tunneling divise tout le trafic réseau. On peut les utiliser séparément ou ensemble. Par exemple, garder un tunnel complet pour tout le trafic, mais résoudre les domaines externes via DoH, et les internes via DNS d’entreprise.

Comment savoir si j’ai une fuite DNS

Signes : noms internes qui ne se résolvent pas, réponses bizarres, connexion AD ou portails qui traînent. Vérifiez les logs résolveur, lancez des tests synthétiques, regardez quel résolveur répond aux zones privées. Si ce n’est pas votre DNS d’entreprise, il y a fuite.

Faut-il activer DoH ou DoT avec un VPN déjà en place

Parfois oui. DoH/DoT protègent des falsifications et espionnage avant d’entrer dans le tunnel et après en sortie si vous utilisez un résolveur externe. Mais il faut prévoir des exceptions pour zones internes, afin de ne pas bloquer l’accès aux services privés. L’équilibre entre sécurité et compatibilité est clé.

Peut-on faire du Split DNS sans droits sur les appareils clients

Partiellement. Vous pouvez configurer un résolveur au périmètre et forcer la redirection. Mais l’idéal est une politique centralisée sur clients via MDM ou politiques de groupe. Ainsi les règles sont cohérentes et les contournements inattendus minimisés.

Quelles erreurs reviennent le plus souvent

Doublons d’enregistrements plutôt que forward, mauvais ordre des résolveurs client, TTL trop longs, conflit DoH avec zones internes, monitoring mal configuré. Se règle par discipline, pilotes, checklists et bons defaults. Et oui, simplifiez quand c’est possible.