DNS avec VPN sans douleur : comment bloquer les fuites, corriger la résolution et configurer le cache

Ce qui se passe vraiment avec le DNS sous VPN : explications simples sans magie

Comment le trajet du trafic change quand on active le VPN

Vous avez cliqué sur Connecter dans votre client VPN préféré. Ça paraît simple : tout le trafic passe par le tunnel. Mais pour le DNS, c’est souvent plus compliqué. Par défaut, le système d’exploitation choisit où envoyer les requêtes de résolution de noms, selon la liste des résolveurs, la priorité des interfaces et la politique des applications. Le VPN ajoute une interface virtuelle avec sa propre route. Pourtant, votre navigateur ou un service système peut continuer à utiliser l’ancien DNS fourni par le FAI. C’est là que naissent fuites et bizarreries.

Imaginez une autoroute avec une voie VIP payante. Les gros véhicules empruntent cette voie. Mais les petites requêtes DNS zigzaguent parfois encore sur les anciennes routes. La cause ? La politique du résolveur : certains font confiance au système, d’autres utilisent DoH intégré, d’autres encore ne s’adaptent pas au tunnel. Mais la logique est claire : pour la confidentialité et la stabilité, il faut un parcours unique et prévisible pour le DNS à l’intérieur du VPN.

En 2026, la plupart des clients WireGuard, OpenVPN et agents SASE d’entreprise savent déjà pousser des paramètres DNS corrects et bloquer les « fuites » vers l’extérieur. Mais pas de miracles. Si un résolveur DoH est activé sur l’hôte, le navigateur peut continuer à interroger son fournisseur cloud. Donc les règles doivent être cohérentes : qui commande, qui suit, et où exactly les paquets UDP sur le port 53, TCP 853 pour DoT et HTTPS pour DoH doivent atterrir.

Pourquoi le DNS est un trafic particulier (et souvent problématique)

Le DNS fonctionne vite, discrètement et fréquemment. Chaque page web génère des dizaines de requêtes. Toute erreur ou désynchronisation se ressent instantanément : site inaccessible, contenu modifié, géolocalisation qui change à l’improviste. Ajoutez à cela la mise en cache à plusieurs niveaux (navigateur, OS, client VPN, résolveur local, fournisseur), et vous obtenez une cascade de délais d’expiration et d’anciennes entrées. Avec un VPN activé, on cherche aussi la confidentialité : on ne veut pas que le fournisseur voie les domaines consultés. Et la fuite DNS fait justement ça — elle fuit, souvent à l’insu de l’utilisateur.

En plus, le DNS ne se limite pas au port 53. Les variantes chiffrées DoH et DoT sont devenues un standard de fait. Les navigateurs adorent DoH. Les résolveurs système sur Windows et Linux chiffrent de plus en plus les requêtes par défaut. iOS et Android activent le Private DNS. Beau, non ? Mais dans le contexte VPN, la question se pose : qui décide, le tunnel ou l’application ? Sans un schéma clair, on finit dans un labyrinthe de politiques conflictuelles où plusieurs règles s'écrasent mutuellement et la configuration finale mêle trois résolveurs différents.

Symptômes : comment détecter que le DNS dysfonctionne à cause du VPN

Chargement lent, temporisations étranges, pages parfois accessibles, parfois non

On connaît tous ça. Le site s’affiche mais pas les images. Ou le contraire : la page d’accueil charge vite, mais le panier bloque. VPN activé, ça s’améliore. Cinq minutes plus tard, c’est pire. Classique paradoxe DNS. Pourquoi ? Sans doute parce qu’une partie des noms passe par le résolveur système, l’autre par le DNS du tunnel. Le cache du navigateur joue à faire fluctuer la situation. Parfois Ctrl+F5 aide, parfois non. Frustrant ? Clairement.

Un indicateur précis : les erreurs DNS_PROBE_FINISHED_NXDOMAIN ou SERVFAIL dans le diagnostic. Ou des retards répétés d’1-2 secondes avant chargement, surtout au premier accès. Quand le tunnel modifie le MTU, les paquets DNS volumineux avec EDNS peuvent se fragmenter et être perdus. Résultat : une requête passe parce qu’elle est petite, l’autre échoue. Autre signe : les sites avec contenu géo-dépendant. S’ils affichent soudain un contenu décalé, c’est sûrement que certaines requêtes ne sont pas résolues où il faut.

Ne négligez pas les problèmes intermittents. Quand tout plante d’un coup, c’est visible. Mais plus agaçant, c’est quand ça plante par intermittence, comme un volant qui a du jeu : la voiture tient la route, on s’habitue, puis soudain on dérape. Le DNS avec VPN, c’est pareil.

Le contenu et la géolocalisation « dansent » : les services croient que vous êtes ailleurs

Vous activez un VPN avec sortie par exemple aux Pays-Bas, mais la plateforme video affiche la bibliothèque russe, turque ou un mélange incohérent. Pourquoi ? Fuite DNS. Le site détermine la géo non seulement par IP, mais aussi par l’endroit où le nom CDN est résolu. Si la requête passe par le DNS du fournisseur en dehors du tunnel, le CDN renvoie l’adresse la plus proche de ce fournisseur. Ce qui rallonge le trafic, affiche un mauvais contenu et fait chuter la vitesse.

Test simple : interrogez en ligne de commande dig ou nslookup et regardez l’en-tête Adresse du serveur. Si c’est l’adresse du fournisseur et non celle du résolveur VPN ou DoH/DoT choisi, vous avez une fuite. Parfois c’est l’inverse : vous croyez chiffrer, mais le navigateur force son DoH avec DDR (Discovery of Designated Resolvers). La requête part vers un bon résolveur HTTPS, mais en contournant le tunnel VPN, ce qui fabrique une géolocalisation hybride bizarre.

En 2026, les architectures hybrides se répandent : les applis sélectionnent leur DNS chiffré et migrent même sur QUIC. Pratique, mais côté VPN c’est source de nouvelles fuites. D’où l’importance de gérer les priorités : qui est maître dans la chaîne, et à quel niveau garantissons-nous chiffrement et routage.

Fuite DNS : comment détecter et bloquer sans mysticisme

On vérifie les fuites : commandes manuelles, utilitaires et domaines « test »

On commence simple. Activez le VPN et lancez nslookup example.com ou dig example.com. Regardez le serveur indiqué dans Server ou la section SERVER. Est-ce le résolveur cible ? Par exemple 10.14.0.1 pour un DNS d’entreprise derrière le tunnel, ou public 1.1.1.1/9.9.9.9/8.8.8.8 mais via tunnel. Si vous voyez l’adresse du fournisseur, c’est une fuite. Si vous voyez un DoH dans le navigateur mais qui sort hors VPN, c’est aussi une fuite, même chiffrée.

Testez différents noms : simples, sous-domaines, longs (pour activer EDNS et grosses réponses). Comparez avec/sans VPN. Si les réponses diffèrent, une partie passe ailleurs. Utilisez des adresses tests comme resolver-test ou des zones inexistantes qui révèlent qui résout (beaucoup de fournisseurs VPN proposent des domaines internes à cet effet, vérifiez votre documentation).

Astuce : activez la journalisation sur le résolveur local (ex : systemd-resolved ou dnsmasq) et observez les domaines réellement traités. Si les logs sont vides mais la résolution fonctionne, les requêtes passent à côté. Sous Windows, utilisez pktmon intégré ou trace PowerShell, sur Linux tcpdump avec le filtre udp port 53 ou ports 853/443 pour DoT/DoH.

Comment bloquer les fuites : politique client, règles OS et réglages d’applications

Au cœur de la lutte : une politique unifiée. Sur OpenVPN Windows, activez block-outside-dns et register-dns. Sur le serveur, poussez « dhcp-option DNS X.X.X.X ». Sur WireGuard, spécifiez DNS = 10.14.0.1 dans le profil client et assurez-vous que AllowedIPs couvre ce résolveur. En split tunneling, ajoutez le résolveur aux réseaux routés via tunnel. Et vérifiez IPv6 : les fuites passent souvent par lui quand IPv4 est bien fermé.

Pensez aux applications. Un navigateur avec DoH activé peut ignorer le résolveur système. Indiquez alors dans le navigateur un DoH accessible via VPN (ex : DoH interne sur port 443 dans le tunnel), ou désactivez DoH intégré si la confidentialité repose sur le tunnel. Sur Windows, utilisez le DoH système lié au résolveur VPN et activez Encrypted DNS uniquement pour ce serveur. Sur Linux avec systemd-resolved, configurez DNS et Domains pour wg0 ou tun0, activez DNSSEC, limitez fallback si besoin.

N’oubliez pas de bloquer en sortie l’UDP 53 hors VPN pendant la connexion. Dur mais efficace. Pareil pour DoT/DoH si vous voulez tout passer par un résolveur interne. C’est une configuration fine, mais sans surprises.

Échecs de résolution : quand les domaines ne se résolvent pas du tout ou par intermittence

Causes locales : cache, MTU, firewall, priorité des interfaces

Les échecs les plus fréquents sont locaux. Un cache garde une vieille entrée A ou AAAA alors que la réalité a changé. Résultat : NXDOMAIN pour vous, mais pas pour un autre PC. Solution simple : videz le cache du navigateur et celui système. Windows : ipconfig /flushdns, macOS : dscacheutil -flushcache et killall mDNSResponder, Linux avec systemd : resolvectl flush-caches. Si vous avez un résolveur local (dnsmasq, Unbound), redémarrez-le. Ça prend deux minutes et évite des heures de galère.

MTU et fragmentation sont aussi sournois. En tunnel VPN, le MTU est souvent plus bas que sur le réseau physique. Les grosses réponses DNS avec EDNS (ex : DNSSEC) ne passent pas sans fragmentation, qui est souvent bloquée sur certains routeurs. On voit alors des timeouts ou SERVFAIL. Baissez le MTU du tunnel (1280-1380 pour WireGuard par exemple) ou désactivez temporairement le tuning EDNS pour diagnostiquer. Simple et efficace, que ce soit chez vous ou en bureau distant.

La priorité des interfaces décide quel résolveur est choisi en premier. Si l’interface VPN n’a pas de métrique plus haute, le système peut continuer à utiliser le Wi-Fi avec son DNS ancien. Vérifiez la liste, la métrique et l’ordre des adaptateurs. Sur Windows dans les options avancées réseau ou via PowerShell, sur Linux avec la table de routage et resolved. Firewall ? Parfois les règles locales bloquent UDP 53 sur la nouvelle interface. Contrôlez ça clairement.

Causes réseau et protocolaires : DoH, DoT, IPv6, DNSSEC et EDNS

Au niveau protocole, c’est plus subtil. Si vous forcez DoT vers un résolveur externe, mais que le tunnel VPN bloque TCP 853 ou demande un proxy, les requêtes ne passent pas. Pour DoH, même chose : HTTPS vers le résolveur cloud peut contourner le tunnel si l’application ne gère pas les routes. En 2026, beaucoup de clients attachent DoH au VPN, mais pas tous. Vérifiez : activez uniquement le tunnel, bloquez la sortie, assurez-vous que DoH répond encore.

IPv6 est une autre histoire. Vous pensez IPv4, mais le système résout aussi en v6. Si le VPN ne route pas IPv6 ou ne fournit pas une adresse résolveur en v6, une partie des requêtes échouent. Deux solutions : désactiver temporairement IPv6 pour diagnostiquer ou configurer totalement le v6 dans le tunnel, résolveur et préfixes inclus. DNSSEC : avec mauvaise gestion de fragmentation et MTU, la validation casse. EDNS : parfois il faut réduire la taille du buffer ou éviter la fragmentation pour que les réponses arrivent intactes.

Il y a aussi ECH : chiffrement du ClientHello en TLS qui cache le SNI. Ça ne touche pas directement le DNS, mais combiné à DoH et les politiques d’interception, ça peut modifier le routage HTTPS du résolveur. Conclusion : vérifiez toute la chaîne, du résolveur système à l’interface tunnel, pour éviter les surprises.

Cache DNS : pièges et astuces pour le maîtriser

Où vit le cache : navigateur, OS, résolveur local, client VPN

Le cache est multi-couches. Le navigateur conserve son propre cache. L’OS a le sien. Le résolveur local (dnsmasq, Unbound, systemd-resolved) ajoute un niveau. Et parfois le client VPN lui-même stocke des réponses, surtout les agents Zero Trust. Vous nettoyez un cache, mais une vieille réponse survit dans un autre. Drôle et frustrant. La bonne approche : nettoyer systématiquement par couches en vérifiant le TTL.

Le TTL est important. Si le résolveur donne un TTL élevé, une entrée obsolète peut durer des heures. En 2026, certaines politiques forcent un cache agressif pour économiser du trafic, notamment sur mobiles. Dans ces cas, un résolveur local capable d’ignorer temporairement le TTL sur certains domaines (en le réduisant pour le débogage) est précieux, notamment lors de migrations de CDN.

Un autre point : le split DNS. Certains domaines internes se résolvent d’un côté, d’autres publics de l’autre. Le cache local doit connaître les suffixes et ne pas mélanger les réponses. Sinon un IP externe peut « masquer » un service interne. Soignez bien les search domains et routes dans votre profil VPN.

Comment nettoyer le cache sans casser le reste

Procédure rapide. D’abord, navigateur : videz son cache DNS dans ses réglages ou redémarrez-le. Ensuite, OS. Windows : ipconfig /flushdns, parfois netsh winsock reset aide en cas de pile saturée. macOS : dscacheutil -flushcache et killall mDNSResponder (une classique toujours efficace). Linux : resolvectl flush-caches ou redémarrage du résolveur local. Avec dnsmasq : service dnsmasq restart. Sur AdGuard Home ou Pi-hole, videz via leur interface ou commande.

Après nettoyage, refaites les tests avec dig et nslookup, observez si les adresses et vitesses changent. Et n’oubliez pas le cache dans le client VPN : certains agents d’entreprise exigent un reset manuel via console intégrée. Rare mais ça existe. Le maître mot : ne pas tout effacer d’un coup. Étape par étape, vérifier et noter.

Architecture DNS correcte avec VPN en 2026 : du réseau domestique au bureau

Split DNS et Split Tunneling : comment faire fonctionner sans casse

Le split tunneling économise du trafic et réduit la latence. Mais avec le DNS, c’est un terrain miné sans règles claires. Premier principe : les suffixes de domaines internes doivent se résoudre uniquement via le résolveur tunnel. Configurez domains ou search domains et route-only pour sous-réseaux adéquats dans le profil VPN. Second principe : pour les domaines publics, décidez où résoudre — tunnel ou dehors — et fixez-le. Variante simple : un résolveur système unique toujours joignable via tunnel, minimisant les fuites.

Pour WireGuard, précisez DNS dans la config client et activez AllowedIPs pour l’adresses du résolveur. Pour OpenVPN, poussez « dhcp-option DOMAIN-SEARCH corp.local » et « dhcp-option DNS 10.14.0.1 ». Sous Windows, activez block-outside-dns. Dans SASE et Zero Trust, affectez politiques par groupes utilisateur/appareils avec domaines à résoudre spécifiques. Ajoutez une surveillance : sans elle, split DNS tourne à la loterie.

Pensez au fallback. Si le résolveur principal est injoignable, le système passe discrètement au secondaire. Un danger : fuites cachées. Mieux vaut un refus clair qu’un détour silencieux. En 2026, beaucoup de clients supportent le mode strict : sans DNS tunnel, aucune requête ne part.

Chiffrement par défaut : DoH, DoT, ECH, ODoH et DDR sans mauvaises surprises

Le chiffrement DNS n’est plus une exception. DoH et DoT sont intégrés aux réglages standards de Windows, Android et navigateurs modernes. DDR (Discovery of Designated Resolvers) automatise l’appariement d’un résolveur chiffré à un résolveur non chiffré connu. C’est prometteur, mais dans l’univers VPN, il faut maîtriser : qui décide du résolveur, l’appli ou la politique tunnel ?

Schéma optimal : une source de vérité unique. Avec un résolveur DoH interne à l’entreprise, configurez-le dans le client et bloquez l’extérieur DoH/DoT avec le VPN actif. Pour un usage privé, choisissez un résolveur fiable (1.1.1.1, 9.9.9.9, 8.8.8.8 ou NextDNS) accessible via tunnel. Pour ECH, l’essentiel est que le trafic HTTPS du résolveur soit stable. ODoH offre plus de confidentialité en séparant requête et transport mais augmente la latence — à appliquer selon besoin.

Conclusion simple : chiffrez le DNS, pas vos sources de vérité. Un seul résolveur, une politique claire, des routes nettes. Alors le VPN sera allié, pas adversaire. Et bonne nouvelle, en 2026, les clients loggent bien l’état DoH/DoT. Vérifiez ces logs, souvent la clé pour comprendre un « ça marchait hier ».

Configurations pas à pas : Windows, macOS, Linux, iOS et Android

Windows 11/10 : résolveur système, OpenVPN et WireGuard

Commençons par Windows. Étape 1 : vérifiez la liste des interfaces et leurs métriques. Mettez la priorité sur l’adaptateur VPN. Étape 2 : sous OpenVPN, ajoutez block-outside-dns et register-dns dans le profil client. Sur le serveur, poussez « dhcp-option DNS 10.14.0.1 » et éventuellement « redirect-gateway def1 ». Étape 3 : pour WireGuard, dans le config client, indiquez DNS = 10.14.0.1 et assurez-vous que AllowedIPs couvre ce résolveur. En split tunneling, ajoutez les domaines recherchés dans la liste.

Étape 4 : activez l’Encrypted DNS système pour le résolveur choisi — uniquement s’il est accessible via tunnel. Indiquez le modèle DoH et vérifiez l’état dans les paramètres réseau. Étape 5 : videz le cache — ipconfig /flushdns. En cas de soucis Winsock, faites netsh winsock reset puis redémarrage. Étape 6 : testez les fuites. nslookup example.com doit montrer un serveur tunnel. Bloquez temporairement l’UDP 53 sortant via firewall pendant le VPN si besoin.

Bonus : sous Windows 11, vérifiez que le navigateur ne force pas un DoH contournant le système. Si la politique est « tout par tunnel », alignez navigateur et résolveur système, ou paramétrez un DoH navigateur accessible par VPN. N’oubliez pas IPv6 : configurez-le via tunnel ou désactivez-le pour diagnostiquer.

macOS et iOS : profils, Résolveur et mDNSResponder

Sur macOS, beaucoup repose sur les profils et l’ordre des services. Étape 1 : assurez-vous que le service VPN a une priorité plus élevée dans la liste réseau. Étape 2 : pour les profils d’entreprise, ajoutez DNS et suffixes de domaines dans le profil VPN. Étape 3 : en cas de souci de résolution, videz le cache avec dscacheutil -flushcache et redémarrez mDNSResponder avec killall mDNSResponder. C'est rapide et fiable.

Sur iOS, la clé est dans le profil et la politique applitive. Beaucoup de clients assignent un résolveur interne à la connexion et bloquent le DNS sortant. Vérifiez l’option annihilant les contournements DNS hors tunnel dans l’appli VPN. Si vous utilisez Private Relay en parallèle, des conflits de routes et d’enregistrement DoH dans le navigateur peuvent survenir. Désactivez Private Relay pendant les tests, laissez VPN et DNS système actifs.

Dans tous les cas, testez la résolution de domaines tests, comparez au résultat attendu. Sur macOS, scutil --dns permet d’observer quel résolveur est utilisé pour quels domaines. En split DNS, configurez impérativement Domains pour l’interface VPN afin d’éviter que les zones internes ne partent hors tunnel.

Linux et Android : systemd-resolved, dnsmasq et Private DNS

Sous Linux en 2026, systemd-resolved est souvent le chef d’orchestre DNS. Étape 1 : associez l’interface tunnel (wg0/tun0) au résolveur attendu : spécifiez DNS et Domains. Étape 2 : vérifiez resolvectl status pour confirmer priorités et ordre de recherche. Étape 3 : si dnsmasq ou Unbound sont présents, configurez forwarding et split DNS pour que les domaines internes ne sortent pas hors tunnel. Étape 4 : vérifiez les routes IPv6 et le MTU, baissez-le si besoin.

Sur Android, allez dans Réseau et Internet, activez Private DNS vers un résolveur choisi si vous souhaitez chiffrer localement. Mais attention : ce trafic doit transiter par le VPN. Si le client VPN ne capture pas le trafic DoH/DoT, vous aurez des fuites partielles. Aujourd’hui, beaucoup de clients proposent un mode interception DNS. Activez-le, testez sur plusieurs domaines.

Linux et Android aiment le cache. N’oubliez pas de faire resolvectl flush-caches sous Linux et redémarrez l’appli VPN sur Android en changeant de profil. Dans les cas complexes, déployez un résolveur local sur le routeur (ex : dnsmasq sur OpenWrt) et routez tout via tunnel. Ce setup est souvent plus stable et prévisible.

Debug et monitoring : outils et scénarios qui fonctionnent vraiment

dig, nslookup, resolvectl, pktmon, tcpdump : quand et comment les utiliser

Pas de bouton magique, mais les bonnes questions. Qui répond au DNS ? Où vont les paquets ? Peut-on détecter un timeout ? Sous Windows, commencez avec nslookup et pktmon. Avec la commande pktmon start --etw -p, vous pouvez tracer le trafic basique et voir si des paquets sortent sur l’interface inattendue. Sous Linux, tcpdump -i wg0 udp port 53 montre le trafic DNS dans le tunnel. Silence = résolution sans tunnel ou via DoH.

dig est précieux avec ses options. Testez dig +tcp pour vérifier DoT et grosses réponses. Examinez SERVER et AUTHORITY. Comparez les résultats selon le MTU. Avec systemd-resolved, resolvectl query domaine indique quel serveur a répondu et en combien de temps. Sur macOS, scutil --dns illustre les priorités des résolveurs et domaines. N’oubliez pas le firewall : il peut silencieusement bloquer UDP 53 ou TCP 853 sur l’interface tunnel.

Pour les applis DoH, activez logs détaillés. Navigateurs et agents entreprise en 2026 affichent enfin à quel résolveur DoH ils se connectent, via quelle interface et avec quels codes d’erreur. Une mine d’or pour le debug : vous voyez tout de suite si la cause est un conflit de routage ou un souci résolveur.

Logs, métriques et alertes : pour un réseau maison ou bureau sans surprises

Chez vous, des métriques simples suffisent : temps de résolution initiale, taux NXDOMAIN/SERVFAIL, taille du cache, TTL. Faites ça via votre résolveur local ou routeur. Mettez en place un tableau simple : si le taux d’erreurs monte dès que VPN s’active, agissez vite. En entreprise, ajoutez des contrôles synthétiques : un robot qui toutes les 60 secondes résout les domaines clés avec/sans VPN. Toute différence est une alerte.

N’hésitez pas à alerter sur MTU et fragmentation, si votre matos le permet. Une fois par semestre, faites un audit : qui est le résolveur principal, forwarding, politiques DoH/DoT, points de fallback. Petites corrections trimestrielles assurent plus de stabilité qu’une grande révision tous les trois ans. Et pour finir, rédigez une documentation. Dans un an, quand vous vous demanderez pourquoi MTU vaut 1280 ici et pas 1420, un changelog clair vous sauvera de l’oubli.

Cas pratiques : situations réelles et solutions efficaces

Cas 1 : fuite DoH dans le navigateur avec VPN d’entreprise

Contexte : un collaborateur se plaint que certains services le voient « chez lui », d’autres « au bureau ». VPN connecté, accès aux systèmes internes OK. Diagnostic : tcpdump sur le tunnel ne montre pas de DNS, mais la résolution fonctionne. Les logs navigateur révèlent un DoH connecté à un résolveur cloud extérieur. Chiffré, mais hors tunnel. Solution : dans la politique VPN, activation de l’interception DoH avec assignation d’un DoH interne sur port 443 dans le tunnel. Désactivation de DDR auto dans le navigateur temporairement. Résultat : géolocalisation stabilisée, fuites disparues.

Conclusion : chiffrer sans contrôler le routage, ce n’est pas la confidentialité. Le secret est où passe le trafic, pas seulement comment il est chiffré.

Cas 2 : résolution instable à cause du MTU et EDNS

Contexte : les sites s’ouvrent mais parfois répondent par SERVFAIL, surtout ceux avec DNSSEC activé. Relance après une seconde : OK. Avec VPN, ça empire. Diagnostic : grosses réponses fragmentées perdues. MTU tunnel à 1420, un appareil sur le chemin coupe les fragments. Solution : baisse du MTU à 1280, limitation du bufsize EDNS dans le résolveur local. Résultat : stabilité améliorée, plus de timeout.

Conclusion : EDNS est top quand le réseau est sympa. Sinon, adaptez-vous.

Cas 3 : split DNS et caches « gelés »

Contexte : un domaine interne a parfois un IP externe, service inaccessible, et se remet tout seul une dizaine de minutes plus tard. Diagnostic : le résolveur local met en cache une réponse externe à cause d’un suffixe interne mal configuré en split DNS. Le navigateur empile ce cache. Solution : configuration stricte des Domains pour l’interface tunnel, ajout d’une règle de forward stricte pour corp.local, purge coordonnée des caches navigateur, OS et résolveur. Résultat : plus de récidive.

Conclusion : le split DNS demande rigueur. Un suffixe raté et c’est des heures de débogage perdues.

Checklist quotidienne : simple et efficace

Essentiel pour un maximum d’efficacité

- Vérifiez qui résout : nslookup ou dig, regardez SERVER. - Assurez-vous que le résolveur VPN est dans la route et prioritaire. - Nettoyez les caches dans l’ordre : navigateur, OS, résolveur local. - Bloquez l’UDP 53 sortant et DoH/DoT externes si besoin. - Harmonisez la politique de chiffrement : un résolveur, une vérité. - Testez IPv6 séparément : configurez-le ou désactivez-le temporairement. - Contrôlez MTU, EDNS et DNSSEC sur grosses réponses.

Cette liste est banale mais ultra efficace. Vos nerfs et vos utilisateurs vous remercieront.

Et si « tout est fait mais le souci persiste »

Décomposez la tâche. 1) La résolution du domaine marche-t-elle via le tunnel en direct vers le résolveur local ? 2) La réponse arrive-t-elle en temps normal ? 3) Le désactivation du DoH intégré dans l’appli change-t-elle quelque chose ? 4) La baisse du MTU à 1280 modifie-t-elle la situation ? 5) Que montre tcpdump sur l’interface tunnel ? Avec des « oui/non » à chaque étape, vous trouverez plus vite la racine.

Ne craignez pas de revenir temporairement à un schéma simple et fiable : un tunnel, un résolveur, routage complet, sans split ni DoH dehors. Si ça marche stable, réintroduisez la complexité couche par couche jusqu’à détecter le point de rupture.

FAQ : l’essentiel en bref

Réponses rapides

Pourquoi un site est parfois plus lent au premier chargement avec VPN ?

Parce que la requête DNS fraîche peut suivre un nouveau chemin, sans cache encore en place. Et si le navigateur utilise son DoH, il établit une nouvelle connexion TLS au résolveur. Ca ajoute 100-300 ms. Après mise en cache et sessions établies, ce délai disparaît presque. Si le retard persiste, contrôlez MTU et timers suspects sur grosses réponses.

Pourquoi une fuite DNS est-elle pire malgré le cryptage du VPN ?

La fuite DNS révèle quels domaines vous consultez. Même avec chiffrement du contenu, le fait que vous contactiez un domaine reste visible par le fournisseur ou tiers si les requêtes sortent hors tunnel. Cela perturbe aussi la géolocalisation et rallonge les trajets, donc moins de confidentialité et plus de problèmes de vitesse et d’accès.

Faut-il toujours activer DoH ou DoT avec VPN ?

Pas forcément, mais c’est judicieux si le résolveur chiffré est accessible via tunnel et correspond à votre politique. L’important : une source unique de vérité. Activer DoH dans le navigateur et avoir un DNS « officiel » VPN ailleurs crée un conflit. Choisissez une méthode et stabilisez les routes.

Cas complexes

Certains domaines DNSSEC disparaissent via VPN. Que faire ?

Vérifiez MTU et fragmentation. Les grosses réponses DNSSEC échouent souvent si la fragmentation est bloquée dans le tunnel. Baissez MTU à 1280-1380, configurez le résolveur pour réduire la taille des réponses EDNS, puis testez à nouveau. Si ça passe, vous étiez sur la bonne piste.

Peut-on combiner split tunneling et DoH système chiffré sans fuite ?

Oui, si le trafic DoH est strictement routé via tunnel et les contournements bloqués. Configurez un DoH système accessible uniquement par VPN, et bloquez le DoH/DoT extérieur pendant la connexion. Ainsi les domaines publics sont chiffrés et routés prévisiblement, les internes via split DNS avec résolveur corporate.

Faut-il désactiver IPv6 pour simplifier ?

Temporairement oui, pour déboguer si vous suspectez fuites ou routes instables. Mais en permanence non conseillé. En 2026, de plus en plus de services et résolveurs utilisent IPv6. Mieux vaut bien configurer IPv6 dans le tunnel que vivre avec des rustines. Mais pour des tests rapides, désactiver IPv6 accélère la recherche du problème.