Debian 13 Split DNS pour VPN et LAN : une configuration propre qui ne casse pas après un redémarrage

octobre 11, 2025 • février 3, 2026 • Lecture : 24 min • Views: 8

Cet article vous a aidé ?

Le DNS fractionné est l’un de ces problèmes qui « devrait être ennuyeux » et qui se transforme en week-end gâché parce que quelqu’un a redémarré un portable, le VPN s’est reconnecté,
et soudain git.company.internal se résout sur l’internet public (ou pire, ne se résout plus du tout).
Si vous avez déjà vu un déploiement en production bloquer parce qu’un agent de build a perdu le DNS interne en cours d’exécution, vous connaissez la sensation : ce n’est pas spectaculaire,
c’est juste coûteux.

Debian 13 peut gérer proprement le DNS fractionné. L’astuce est de choisir un seul plan de contrôle DNS et de faire en sorte que tout le reste lui fournisse des informations.
Cet article vous donne une configuration qui survit aux redémarrages, aux changements de Wi‑Fi, aux reconnexions VPN et aux serveurs DHCP « serviables ».

Ce que vous construisez (et ce que vous ne construisez pas)

Le DNS fractionné signifie : certains domaines se résolvent via des serveurs DNS spécifiques, tandis que tout le reste utilise votre DNS « normal ».
Exemple typique :

*.corp.internal et *.svc.cluster.local se résolvent via les serveurs DNS du VPN
tout le reste se résout via le DNS du LAN (ou des résolveurs publics)

Vous ne construisez pas une ferme de serveurs DNS. Vous mettez en place une configuration de résolveur côté client déterministe qui :
(1) oriente les bons noms vers les bons résolveurs, (2) n’expose pas les requêtes internes au DNS public, et (3) reste stable après redémarrage.

Votre ennemi n’est pas la complexité DNS. C’est la concurrence entre gestionnaires DNS. Les systèmes Debian ont souvent plusieurs acteurs qui tirent sur /etc/resolv.conf :
NetworkManager, systemd-resolved, clients VPN, clients DHCP, et parfois le dotfile de quelqu’un datant de 2014.

Faits intéressants et courte histoire (parce que le contexte évite la douleur)

Le DNS fractionné précède la mode VPN : les entreprises l’ont utilisé tôt pour des zones à horizon séparé où les noms internes ne doivent jamais se résoudre à l’extérieur.
Le format de /etc/resolv.conf est volontairement simple—tellement simple qu’il ne peut pas exprimer le routage par domaine. Le DNS fractionné nécessite quelque chose de plus intelligent.
Les « domaines de routage » de systemd-resolved (le concept ~domain) sont conçus précisément pour exprimer « ce suffixe va au DNS de ce lien ».
La limite classique des « 3 serveurs nameserver » dans resolv.conf n’est pas que du folklore : de nombreux résolveurs se comportent encore ainsi et l’ordre peut vous jouer des tours.
La mise en cache négative (se souvenir du NXDOMAIN) peut rendre le DNS hanté : on répare le serveur, et les clients échouent encore jusqu’à l’expiration du cache.
Les domaines de recherche sont plus vieux que la plupart des outils VPN modernes, et ils sont souvent mal utilisés. Une longue liste de recherche augmente la charge de requêtes et les surprises.
Les « fuites DNS » concernent souvent la fiabilité plutôt que la confidentialité. Les zones internes interrogées via le DNS public retournent NXDOMAIN et cassent les applications.
De nombreux VPN d’entreprise imposaient historiquement une prise de contrôle complète du DNS parce que les anciens clients ne pouvaient pas faire de routage par domaine ; cette habitude persiste.

Une idée paraphrasée de Werner Vogels (CTO d’Amazon) : tout échoue, tout le temps ; concevez les systèmes en supposant que l’échec est normal.
Le DNS fractionné est une petite version de cette philosophie—conçevez pour les basculements d’interface et les reconnexions.

Choix d’architecture qui tiennent réellement

Choisir un seul propriétaire des décisions DNS

Sur Debian 13, l’approche la plus propre est : laisser systemd-resolved être le moteur de politique du résolveur.
Laisser NetworkManager (ou votre client VPN) lui fournir des serveurs DNS et des domaines spécifiques aux liens.
Puis pointer /etc/resolv.conf vers le stub de resolved.

Ce qu’il faut éviter : une pile de résolveurs « choisissez votre aventure » où NetworkManager écrit /etc/resolv.conf,
le VPN l’écrase, et un script post-up essaie de le réparer. Ça marche jusqu’à ce que ça ne marche plus—et en général ça casse après un redémarrage.

Comprendre les deux modes de resolved

Écouteur stub : votre système pointe vers 127.0.0.53 (stub local), et resolved fait le routage en amont et la mise en cache.
Resolv.conf étranger / direct : les applications interrogent directement les serveurs en amont. C’est là que le DNS fractionné meurt silencieusement.

Le VPN doit publier des domaines, pas seulement des serveurs

Un VPN qui ne pousse que des serveurs DNS sans indiquer « quels domaines me reviennent » est en train de provoquer une bagarre.
Vous voulez soit :

l’interface VPN obtient des domaines de routage comme ~corp.internal, ~company.local
ou au moins des domaines de recherche (moins précis, plus risqué)

La priorité DNS n’est pas une impression

La sélection DNS suit des règles. Les résolveurs choisissent les serveurs selon le lien, la route et la correspondance de domaine. Si vous ne définissez pas de priorités,
le « gagnant » peut changer quand les métriques d’interface changent (le roaming Wi‑Fi est excellent pour ça).

Blague #1 : Le DNS est le seul système où « c’est mis en cache » est accepté à la fois comme explication et comme alibi.

Mode d’emploi pour un diagnostic rapide

Quand le DNS fractionné casse, ne commencez pas par éditer des fichiers. Répondez rapidement à trois questions :
quel résolveur est actif, quel lien possède le domaine, et quel chemin de requête l’application utilise.

Première étape : systemd-resolved est-il vraiment aux commandes ?

Vérifiez si /etc/resolv.conf pointe vers le stub
Vérifiez resolvectl status pour les DNS spécifiques aux liens

Deuxième étape : le domaine est-il routé vers le lien VPN ?

resolvectl query git.corp.internal et vérifiez qu’il utilise le serveur DNS du VPN
Confirmez que le lien VPN a ~corp.internal (domaine de routage), pas seulement un domaine de recherche générique

Troisième étape : votre application contourne-t-elle le résolveur OS ?

Les navigateurs, runtimes de conteneurs et certains SDK peuvent faire leur propre DNS ou mettre en cache
Comparez avec getent hosts versus dig et comparez les résultats

Test rapide pour repérer l’engorgement

Si resolvectl query est rapide mais que l’application est lente : suspectez la mise en cache côté app, des paramètres proxy ou DoH/DoT intégrés à l’app.
Si resolvectl query est lent : suspectez un serveur DNS injoignable, des problèmes de MTU sur le VPN, ou UDP/TCP 53 bloqués.
Si seuls certains domaines échouent : suspectez des domaines de routage, des conflits split-horizon, ou un cache négatif obsolète.

Prérequis et vérifications de base

Debian 13 est généralement fourni avec systemd et peut exécuter systemd-resolved. NetworkManager est courant sur postes de travail et portables ; sur serveurs vous utiliserez peut‑être systemd-networkd ou ifupdown. Ce guide suppose que vous utilisez NetworkManager ou que vous avez une interface VPN que vous pouvez configurer.

Décidez du comportement souhaité avant de toucher quoi que ce soit :

Voulez‑vous que seuls les domaines internes utilisent le DNS du VPN (préféré) ?
Ou voulez‑vous que tout le DNS passe par le VPN lorsqu’il est connecté (parfois requis par la politique) ?
Devez‑vous prendre en charge des serveurs DNS IPv4 et IPv6 ?

Configuration recommandée : systemd-resolved comme plan de contrôle DNS

1) S’assurer que resolved fonctionne

Si resolved n’est pas actif, tout le reste devient du ruban adhésif. Activez-le et rendez‑le ennuyeux.

2) Pointer /etc/resolv.conf vers le stub

Vous voulez que /etc/resolv.conf soit un lien symbolique vers le resolv.conf stub de systemd. C’est l’ancre qui survit au redémarrage.
Si vous laissez d’autres outils l’écrire, vous aurez une personnalité DNS différente chaque lundi.

3) Laisser NetworkManager parler à resolved

NetworkManager peut s’intégrer à systemd-resolved. Lorsqu’il le fait, les serveurs DNS et les domaines deviennent des propriétés par lien, ce qui est exactement ce que nécessite le DNS fractionné.

4) Attacher des domaines de routage au lien VPN

La magie est la syntaxe des domaines de routage : ~corp.internal. Le tilde signifie « envoyer les requêtes pour ce domaine vers le DNS de ce lien ».
Sans cela, vous retournez à la roulette globale du DNS.

Split DNS avec NetworkManager : WireGuard et OpenVPN

WireGuard via NetworkManager

WireGuard est propre, mais l’écosystème autour varie. Si vous le gérez via NetworkManager, définissez le DNS et les domaines dans le profil de connexion WireGuard.
Certaines implémentations poussent aussi le DNS via des scripts ; évitez cela si possible—gardez une seule autorité.

OpenVPN via NetworkManager

OpenVPN pousse souvent « dhcp-option DNS » et « dhcp-option DOMAIN ». NetworkManager peut traduire cela en paramètres de lien pour resolved.
L’important est de s’assurer que les domaines deviennent des domaines de routage (ou au moins des domaines de recherche), et que la priorité DNS n’autorise pas le LAN à voler les noms internes.

Blague #2 : Le DNS VPN est comme un organigramme d’entreprise—techniquement documenté, émotionnellement imprévisible.

Optionnel : dnsmasq local pour les cas récalcitrants

Je préfère systemd-resolved seul pour les clients Debian. Mais il existe des cas limites :

Vous avez besoin de règles de transfert conditionnel qu’une application legacy spécifique attend.
Vous voulez reproduire un vieux schéma d’entreprise : « envoyer corp.internal vers 10.x, tout le reste vers l’ISP ».
Vous traitez un environnement où l’outillage VPN ne peut pas communiquer de façon fiable les domaines à resolved.

Dans ces cas, dnsmasq peut agir comme un forwarder local avec politique, et resolved peut le forwarder—ou vous pouvez sauter resolved et laisser NetworkManager alimenter dnsmasq.
Le risque est d’augmenter la complexité. La complexité est acceptable quand elle est documentée et stable. Elle n’est pas acceptable quand elle est accidentelle.

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

Ces tâches sont écrites comme si vous étiez de garde : vous exécutez une commande, interprétez la sortie, puis décidez quoi faire ensuite.
Ne « testez pas des trucs ». Changez une variable à la fois.

Task 1: Confirm Debian is using systemd-resolved

cr0x@server:~$ systemctl status systemd-resolved --no-pager
● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
     Active: active (running) since Mon 2025-12-29 08:41:12 UTC; 2h 13min ago
       Docs: man:systemd-resolved.service(8)

Signification : « active (running) » est non négociable pour ce design.
Décision : S’il est inactive/désactivée, activez‑la avant de toucher au DNS du VPN.

Task 2: Verify what owns /etc/resolv.conf

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

Signification : Ce lien symbolique est la partie « résistante au redémarrage ».
Décision : S’il pointe ailleurs (ou est un fichier régulier), corrigez‑le ; sinon vous déboguez une cible mouvante.

Task 3: Inspect resolved’s global and per-link DNS view

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 192.168.1.1
       DNS Servers: 192.168.1.1
        DNS Domain: lan

Link 2 (enp3s0)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 192.168.1.1
       DNS Servers: 192.168.1.1
        DNS Domain: lan

Link 5 (wg0)
    Current Scopes: DNS
         Protocols: -DefaultRoute
       DNS Servers: 10.20.30.53 10.20.30.54
        DNS Domain: ~corp.internal ~svc.cluster.local

Signification : Le lien VPN a des domaines de routage (~corp.internal) et n’est pas la route par défaut pour le DNS.
Décision : Si le lien VPN manque de domaines de routage, le DNS fractionné ne se produira pas. Ajoutez‑les au niveau de la connexion.

Task 4: Confirm a specific internal name routes to the VPN DNS

cr0x@server:~$ resolvectl query git.corp.internal
git.corp.internal: 10.20.40.12                        -- link: wg0
                  (git.corp.internal)

Signification : La requête est passée via le lien wg0.
Décision : Si elle indique link: enp3s0 ou « No appropriate name servers », corrigez les domaines de routage ou la reachabilité DNS.

Task 5: Compare libc resolution path (what most apps use)

cr0x@server:~$ getent hosts git.corp.internal
10.20.40.12     git.corp.internal

Signification : NSS + libc résolvent correctement.
Décision : Si resolvectl query marche mais getent échoue, suspectez une mauvaise configuration NSS ou une application qui contourne le résolveur système.

Task 6: Check NetworkManager is using resolved (not writing resolv.conf directly)

cr0x@server:~$ nmcli general status
STATE      CONNECTIVITY  WIFI-HW  WIFI     WWAN-HW  WWAN
connected  full          enabled  enabled  enabled  enabled

cr0x@server:~$ nmcli -t -f RUNNING,VERSION,STATE general
running:yes
version:1.48.0
state:connected

Signification : NM est actif ; l’étape suivante est de vérifier qu’il est configuré pour utiliser systemd-resolved.
Décision : Si NM n’est pas en cours, vos modifications DNS doivent être effectuées via systemd-networkd ou l’outillage VPN directement.

Task 7: Inspect a VPN connection’s DNS and domains in NetworkManager

cr0x@server:~$ nmcli -f NAME,TYPE,DEVICE connection show --active
NAME            TYPE       DEVICE
Office-WG       wireguard  wg0
Home-LAN        ethernet   enp3s0

cr0x@server:~$ nmcli connection show "Office-WG" | sed -n '1,120p'
connection.id:                          Office-WG
connection.type:                        wireguard
connection.interface-name:              wg0
ipv4.method:                            auto
ipv4.dns:                               10.20.30.53,10.20.30.54
ipv4.dns-search:                        corp.internal,svc.cluster.local
ipv4.ignore-auto-dns:                   yes
ipv6.method:                            disabled

Signification : NM a les DNS et domaines de recherche. Avec l’intégration resolved, ceux‑ci peuvent devenir des domaines de routage.
Décision : Si ipv4.ignore-auto-dns est no sur le LAN, le DHCP peut annuler vos intentions ; ajustez les priorités et ignore-auto-dns si nécessaire.

Task 8: Set VPN-specific DNS servers and search domains (and persist them)

cr0x@server:~$ sudo nmcli connection modify "Office-WG" ipv4.dns "10.20.30.53 10.20.30.54"
cr0x@server:~$ sudo nmcli connection modify "Office-WG" ipv4.dns-search "corp.internal svc.cluster.local"
cr0x@server:~$ sudo nmcli connection modify "Office-WG" ipv4.ignore-auto-dns yes

cr0x@server:~$ sudo nmcli connection down "Office-WG" && sudo nmcli connection up "Office-WG"
Connection 'Office-WG' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/17)
Connection 'Office-WG' successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/19)

Signification : Vous avez rendu explicite et persistant le DNS du VPN dans NM.
Décision : Si après reconnexion resolvectl status n’affiche toujours pas les domaines de routage, vérifiez l’intégration NM/resolved ou utilisez un drop-in resolved.

Task 9: Confirm resolved sees the VPN DNS servers after reconnect

cr0x@server:~$ resolvectl status wg0
Link 5 (wg0)
    Current Scopes: DNS
         Protocols: -DefaultRoute
       DNS Servers: 10.20.30.53 10.20.30.54
        DNS Domain: ~corp.internal ~svc.cluster.local

Signification : Parfait : serveurs DNS scindés par lien et domaines de routage.
Décision : Si les domaines n’ont pas le tilde, vous pouvez encore fonctionner via des domaines de recherche, mais attendez‑vous à des fuites et des bizarreries. Corrigez correctement.

Task 10: Force routing domains on the VPN link via resolved (when the VPN client can’t)

cr0x@server:~$ sudo mkdir -p /etc/systemd/resolved.conf.d
cr0x@server:~$ sudo tee /etc/systemd/resolved.conf.d/wg0-domains.conf >/dev/null <<'EOF'
[Resolve]
EOF

cr0x@server:~$ sudo resolvectl domain wg0 '~corp.internal' '~svc.cluster.local'
cr0x@server:~$ sudo resolvectl dns wg0 10.20.30.53 10.20.30.54

Signification : Vous avez appliqué les paramètres en direct. Remarque : resolvectl domain n’est pas automatiquement persistant au reboot à moins que votre gestionnaire réseau ne les réapplique.
Décision : Utilisez ceci pour du triage ; puis déplacez la configuration dans NetworkManager ou systemd-networkd pour qu’elle survive au redémarrage.

Task 11: Validate you’re not leaking internal queries to public DNS

cr0x@server:~$ resolvectl query doesnotexist.corp.internal
doesnotexist.corp.internal: resolve call failed: 'does not exist' (NXDOMAIN) -- link: wg0

Signification : NXDOMAIN provient du lien VPN. Bien. Cela signifie que la requête est allée là où vous le souhaitiez.
Décision : Si NXDOMAIN provient de votre DNS LAN, votre routage fractionné ne fonctionne pas et les requêtes internes fuient.

Task 12: Check for a “helpful” local stub or conflicting listener on port 53

cr0x@server:~$ sudo ss -ltnup | grep ':53 '
udp   UNCONN 0      0         127.0.0.53%lo:53         0.0.0.0:*    users:(("systemd-resolve",pid=620,fd=13))
tcp   LISTEN 0      4096      127.0.0.53%lo:53         0.0.0.0:*    users:(("systemd-resolve",pid=620,fd=14))

Signification : resolved possède l’écouteur stub. Pas de bind local surprenant.
Décision : Si vous voyez dnsmasq/unbound liant aussi 127.0.0.1:53, décidez qui gagne et désactivez l’autre. « Les deux » n’est pas un plan.

Task 13: Confirm nsswitch is sane for host resolution

cr0x@server:~$ grep -E '^(hosts|networks):' /etc/nsswitch.conf
hosts:          files mdns4_minimal [NOTFOUND=return] dns
networks:       files

Signification : Le DNS est dans la chaîne ; les fichiers locaux ont la priorité.
Décision : Si dns manque, ou si vous avez des modules exotiques, corrigez NSS avant d’accuser resolved.

Task 14: Observe DNS behavior during a VPN reconnect

cr0x@server:~$ journalctl -u systemd-resolved -n 80 --no-pager
Dec 29 10:42:11 server systemd-resolved[620]: Switching to fallback DNS server 192.168.1.1#53.
Dec 29 10:42:25 server systemd-resolved[620]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 10.20.30.53.
Dec 29 10:42:29 server systemd-resolved[620]: DNS server 10.20.30.53#53 connected via wg0.

Signification : resolved s’adapte à la reachabilité des serveurs et à la capacité EDNS0. C’est souvent une raison cachée pour « c’était rapide hier ».
Décision : Si vous voyez des basculements constants, enquêtez sur le MTU, la perte de paquets, ou les règles de pare-feu sur le chemin VPN.

Trois mini-histoires d’entreprise (parce que les cicatrices apprennent)

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

Une entreprise de taille moyenne a déployé un nouveau concentrateur VPN. L’équipe réseau l’a testé avec un client Windows, confirmé que les sites internes fonctionnaient,
puis annoncé la victoire. Les utilisateurs Linux ont reçu pour consigne « utilisez OpenVPN » et on leur a fourni une config qui poussait des serveurs DNS mais pas de domaines.

La mauvaise hypothèse : « Si nous poussons des serveurs DNS internes, les noms internes se résoudront. » Sur les clients Linux, cela signifie souvent que ces serveurs DNS deviennent
préférés globalement. Ensuite, quand les utilisateurs se déconnectaient, la config obsolète restait—ou pire, le résolveur continuait à interroger des serveurs 10.x injoignables.
Les gens ont vécu ça comme un « DNS qui meurt aléatoirement après le VPN ».

La panne n’a pas été un grand bang. Ce fut une hémorragie lente : des runners CI échouaient à récupérer des dépendances parce que la résolution publique fonctionnait, mais les noms d’artefacts internes non.
Les développeurs relançaient les jobs jusqu’à réussite. Vous devinez l’impact sur la planification de capacité.

La correction n’a pas été héroïque. Ils ont cessé de laisser le VPN écraser le DNS global, et ont publié des domaines de routage pour corp.internal et
svc.cluster.local. Les clients Linux envoyaient alors seulement ces suffixes au DNS VPN. Le reste est resté sur le DNS LAN.

La leçon : le DNS fractionné n’est pas un « polish optionnel ». C’est de la justesse. Un DNS VPN sans domaines, c’est comme donner des numéros de téléphone sans indicatifs régionaux.

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

Une autre organisation voulait accélérer les builds. Quelqu’un a remarqué que la latence DNS vers les résolveurs internes via VPN était ~60–120ms aux heures de pointe.
L’optimisation proposée : « Mettons en cache tout agressivement sur les portables avec un résolveur local et augmentons les TTL côté DNS interne. »
Ça semblait raisonnable—jusqu’à ce que non.

Ils ont déployé une couche de cache locale, et la médiane de résolution s’est améliorée. Mais les frontières du DNS fractionné sont devenues floues.
Certains enregistrements internes avaient une courte durée de vie par conception car les services bougeaient derrière des load balancers. La couche de cache gardait sagement de vieilles réponses.
Quand un service basculait, les clients ont continué d’appeler le point mort pendant plusieurs minutes.

Le retournement n’a pas été spectaculaire : le monitoring indiquait que le service était sain et que le basculement avait fonctionné. Seul un sous‑ensemble de clients échouait.
Les caches des résolveurs étaient en cause. Un projet « DNS plus rapide » est devenu un incident « pourquoi seuls les ingénieurs distants sont cassés ».

Le rollback a été douloureux car tout le monde dépendait de l’accélération. La correction à long terme a été de respecter les TTL, mettre en cache de façon responsable,
et cesser de traiter le DNS comme une base de configuration statique. Ce n’en est pas une. C’est un plan de contrôle.

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

Une entreprise globale avait une règle stricte pour les endpoints : un seul propriétaire DNS (le résolveur système), un seul chemin de configuration (profils NetworkManager),
et pas de scripts post‑connexion qui éditent /etc/resolv.conf. Les ingénieurs râlaient parce que cela paraissait bureaucratique.

Puis un patch du gateway VPN a introduit un bug où la liste de serveurs DNS poussée incluait occasionnellement un résolveur injoignable en premier.
Certains clients attendaient le timeout sur le premier serveur puis retombaient ; d’autres restaient bloqués à cause de la logique de retry. Ça aurait pu être un chaos.

Parce qu’ils avaient un design cohérent, le diagnostic a été rapide. Sur les machines affectées, resolvectl status affichait clairement le mauvais serveur DNS sur le lien VPN.
Ils ont pu déployer une mise à jour d’un profil NetworkManager d’une ligne pour réordonner les serveurs DNS et réduire la douleur liée aux retries.

Pas d’héroïsme, pas d’édition manuelle des fichiers sur les portables, pas de « lancez ce script après la connexion ». Juste un changement de configuration ennuyeux qui s’applique à la reconnexion.
L’incident est resté contenu, et le support n’a pas fondu.

Erreurs courantes : symptôme → cause → correction

Symptôme : Le DNS fonctionne jusqu’au redémarrage, puis les noms internes échouent.
Cause : /etc/resolv.conf est un fichier régulier ou géré par le mauvais outil ; resolved n’est pas le stub actif.
Correction : Activez resolved et faites un lien symbolique de /etc/resolv.conf vers /run/systemd/resolve/stub-resolv.conf.
Symptôme : En VPN, le DNS public cesse de fonctionner ou devient lent.
Cause : Les serveurs DNS du VPN sont utilisés comme résolveurs globaux ; ils bloquent la récursion ou ont une mauvaise egress.
Correction : Utilisez des domaines de routage (~corp.internal) pour que seuls les domaines internes atteignent le DNS VPN ; laissez les résolveurs LAN/public pour le reste.
Symptôme : Les domaines internes se résolvent sur des IP publiques (mauvais service, mauvais certificat, erreurs confuses).
Cause : Mismatch split-horizon : les requêtes pour les zones internes vont vers les résolveurs publics en premier.
Correction : Assurez‑vous que le suffixe interne est routé vers le lien VPN ; vérifiez avec resolvectl query montrant link: wg0.
Symptôme : resolvectl query fonctionne, mais un navigateur ou une application Java échoue.
Cause : L’application contourne le résolveur OS (DoH), DNS figé, ou cache applicatif obsolète.
Correction : Confirmez avec getent hosts ; désactivez DoH de l’application ou alignez‑le avec la politique d’entreprise ; redémarrez l’application après les changements DNS.
Symptôme : Seuls certains noms internes échouent, surtout les noms courts.
Cause : Domaine de recherche manquant sur le lien VPN, ou ordre de recherche en conflit entre LAN et VPN.
Correction : Ajoutez des domaines explicites ; privilégiez les FQDN ; réduisez et ordonnez soigneusement les domaines de recherche.
Symptôme : Timeouts aléatoires lors de la résolution de noms internes via VPN.
Cause : Problèmes de MTU/fragmentation sur le chemin VPN, ou le serveur DNS exige un fallback TCP et celui-ci est bloqué.
Correction : Vérifiez les logs de resolved pour le mode dégradé ; testez la reachabilité TCP/53 ; corrigez le MTU ou les règles de pare-feu.
Symptôme : Les requêtes DNS vont vers le mauvais service local sur le port 53.
Cause : Un autre résolveur (dnsmasq/unbound) écoute, ou un réseau de conteneurs détourne le DNS.
Correction : Décidez d’un seul écouteur local ; arrêtez l’autre ; confirmez avec ss -ltnup.

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

Checklist A : Base propre et résistante au redémarrage

Activez et démarrez systemd-resolved.
Faites un lien symbolique /etc/resolv.conf vers le stub resolv.conf de resolved.
Confirmez que resolvectl status affiche resolv.conf mode: stub.
Choisissez un gestionnaire réseau : NetworkManager sur postes, systemd-networkd sur serveurs. Ne les mélangez pas à la légère.

Checklist B : Split DNS VPN qui ne fuit pas

Définissez explicitement les serveurs DNS du VPN (évitez « automatique si ça marche »).
Attachez des domaines de routage au lien VPN : ~corp.internal, ~svc.cluster.local.
Assurez‑vous que le lien VPN n’est pas la route DNS par défaut sauf si la politique l’exige.
Validez avec resolvectl query affichant link: wg0 pour les domaines internes.
Validez que les domaines publics se résolvent toujours via le DNS LAN.

Checklist C : Durcissement pour le monde réel

Gardez les domaines de recherche courts ; évitez d’empiler cinq suffixes corp « au cas où ».
Privilégiez les FQDN dans l’automatisation et la gestion de configuration.
Rendez le comportement DNS observable : apprenez aux gens resolvectl status et resolvectl query.
Testez les boucles de reconnexion : déconnectez/reconnectez le VPN, changez de Wi‑Fi, suspendre/reprendre.
Documentez la source de vérité unique : « le DNS est géré par resolved ; NM l’alimente. »

FAQ

1) Ai‑je vraiment besoin de systemd-resolved pour le DNS fractionné sur Debian 13 ?

Non, mais vous avez besoin de quelque chose capable d’exprimer le routage par domaine. resolved est le plus simple sur Debian 13
et s’intègre bien avec NetworkManager.

2) Quelle est la différence entre domaines de recherche et domaines de routage ?

Les domaines de recherche ajoutent des suffixes aux noms courts (par exemple, git devient git.corp.internal).
Les domaines de routage (~corp.internal) disent à resolved quels serveurs DNS doivent recevoir les requêtes pour ce suffixe.
Utilisez des domaines de routage pour le DNS fractionné. Utilisez les domaines de recherche avec parcimonie.

3) Pourquoi ne pas simplement mettre les serveurs DNS du VPN en premier dans resolv.conf ?

Parce que ça casse dès que le VPN se déconnecte, et parce que ça envoie des requêtes non‑corp vers les résolveurs corp.
Le DNS fractionné, c’est de la justesse, pas seulement « faire fonctionner l’interne quand on est connecté ».

4) J’utilise WireGuard avec wg-quick, pas NetworkManager. Puis‑je quand même faire cela ?

Oui, mais vous devez vous assurer que le DNS et le routage de domaine sont appliqués de façon persistante quand l’interface monte.
Une approche courante est l’intégration via des hooks interface-up—puis vérifiez après redémarrage que les hooks s’exécutent.
Si possible, gérer WireGuard via NetworkManager tend à être plus cohérent sur les portables.

5) Mes serveurs DNS internes ne répondent qu’aux zones internes et refusent la récursion. Est‑ce acceptable ?

C’est acceptable et souvent volontaire. C’est une autre raison pour laquelle vous voulez le DNS fractionné : seuls les suffixes internes doivent atteindre ces serveurs,
tandis que les noms publics se résolvent ailleurs.

6) Pourquoi « NXDOMAIN » persiste‑t‑il parfois après que j’ai corrigé le DNS ?

La mise en cache négative. Les résolveurs et les applications peuvent mettre en cache NXDOMAIN pour un TTL. Redémarrer resolved peut vider son cache,
mais les applications peuvent encore cacher. Lors du dépannage, testez avec des noms nouveaux ou redémarrez l’application.

7) Comment savoir si mon application contourne le résolveur système ?

Comparez les résultats entre getent hosts name et l’application. Si libc résout mais l’application non,
vérifiez l’application pour des paramètres DoH, des résolveurs embarqués, ou une configuration proxy.

8) Dois‑je désactiver IPv6 pour « réparer des problèmes DNS » ?

En général non. Le dual‑stack ajoute de la complexité, mais désactiver IPv6 masque souvent le vrai problème (comme un DNS VPN cassé sur IPv6 ou de mauvaises annonces de routeur).
Corrigez la configuration ; n’amputez pas le réseau.

9) Quand choisir dnsmasq plutôt que systemd-resolved ?

Lorsque vous avez besoin de règles de transfert conditionnel qui ne se mappent pas proprement aux domaines DNS spécifiques aux liens, ou lorsque l’outillage legacy ne peut pas communiquer les domaines fractionnés.
Considérez‑le comme une exception, pas la valeur par défaut.

Conclusion : étapes suivantes qui ne ruineront pas votre lundi

La voie stable sur Debian 13 est simple : systemd-resolved gère la politique DNS ; NetworkManager (ou votre pile réseau) l’alimente avec des serveurs DNS par lien et des domaines de routage.
Faites pointer /etc/resolv.conf vers le stub, et arrêtez de laisser des scripts aléatoires l’écrire.

Prochaines étapes pratiques :

Vérifiez que /etc/resolv.conf est le lien symbolique vers le stub de resolved.
Assurez‑vous que votre lien VPN a des domaines de routage (~corp.internal) et des serveurs DNS VPN dans resolvectl status.
Exécutez trois tests : resolvectl query pour un nom interne, getent hosts pour le même nom, et une requête pour un nom public.
Redémarrez une fois volontairement. S’il casse après un redémarrage planifié, ce n’était jamais stable—juste chanceux temporairement.