DNS entre bureaux : faire résoudre les noms d’hôtes partout (Windows + Linux)

Ce que vous résolvez vraiment : « nom » → « routage » → « politique »

« Faire résoudre les noms d’hôtes partout » semble être un problème uniquement DNS. En pratique, c’est une chaîne en trois parties :
le résolveur du client choisit un serveur DNS, ce serveur DNS renvoie une réponse (ou pas), puis votre
pile réseau/sécurité décide si l’IP résultante est joignable.

Vous pouvez avoir un DNS parfait et échouer quand même parce que la réponse est « correcte » mais inutile : le bureau obtient
une IP interne de datacenter qui n’est pas routée sur le VPN ; ou il obtient un enregistrement ancien parce que la réplication
accuse du retard ; ou il obtient la réponse « publique » parce que le split-horizon est mal configuré. Inversement, vous pouvez avoir
un routage en ordre et échouer parce que le résolveur est lent, des délais d’attente pluriseconds s’additionnent, et votre application
épuise son propre budget de retry.

Mon objectif tranché : choisir une source d’autorité pour les noms internes, faire en sorte que chaque bureau puisse y accéder
(directement ou via redirection), et rendre les clients déterministes sur les serveurs DNS qu’ils utilisent. Puis vérifier avec
des commandes reproductibles, pas des impressions.

Faits et brève histoire utiles en production

• Le DNS est plus ancien que l’internet moderne tel que vous l’expérimentez. Les RFC DNS datent de 1987, remplaçant le modèle centralisé HOSTS.TXT qui ne montait pas.
• Le « DNS split-horizon » n’est pas un bricolage ; c’est un modèle. Fournir des réponses différentes selon la source de la requête est courant en entreprise et chez les CDN.
• Windows a rendu le DNS problématique pour tout le monde. Active Directory dépend du DNS (enregistrements SRV) pour localiser les contrôleurs de domaine, Kerberos, LDAP, et plus.
• Le TTL est un instrument peu précis. Des TTL courts réduisent les données obsolètes mais augmentent le volume de requêtes et exposent la latence à travers les liens WAN.
• Le caching négatif existe. Si un client demande un nom et reçoit NXDOMAIN, cet échec peut être mis en cache ; « j’ai corrigé » peut ne pas se propager instantanément.
• Les suffixes de recherche sont à la fois productivité et piège. « ping printer01 » peut résoudre rapidement… ou lancer une parade de requêtes échouées à travers plusieurs suffixes.
• systemd-resolved a changé le modèle mental par défaut sur Linux. Sur beaucoup de distributions, /etc/resolv.conf est un stub et la logique réelle vit derrière un écouteur local.
• EDNS0 et paquets DNS plus grands sont normaux aujourd’hui. Les pare-feu qui « aident » en bloquant fragments ou grandes réponses UDP peuvent casser sélectivement le DNS moderne.
• DNSSEC n’est pas la même chose que « DNS sécurisé ». DNSSEC valide l’authenticité ; il n’encrypte pas les requêtes. (DoH/DoT sont l’histoire du chiffrement.)

Une citation à garder sur un post-it, parce que les pannes DNS adorent se propager : L’espoir n’est pas une stratégie. — Gene Kranz.
(C’est court, et cela s’applique gênamment bien à « ça résout en général ».)

Une architecture cible qui ne pourrit pas

Choisissez votre espace de noms interne sérieusement

Utilisez un domaine que vous possédez. Si vous avez déjà Active Directory, c’est typiquement votre domaine DNS AD, et vous
devriez le traiter comme votre autorité de nommage interne. Si vous n’avez pas AD, vous avez quand même besoin d’une zone interne
avec une propriété claire. L’ère du « utilisons .local » doit rester en 2006 où elle appartient.

La résolution de noms entre bureaux devient simple quand vos noms internes sont :

• Autoritatifs en un seul endroit (ou un ensemble de serveurs autoritatifs synchronisés)
• Accessibles depuis tous les bureaux (directement ou via redirection)
• Cohérents avec le routage (les réponses sont joignables depuis l’emplacement du client)

Choisissez un modèle et tenez-vous-y

Voici les modèles qui fonctionnent en production. Choisissez-en un selon votre taille et vos contraintes :

1. DNS AD intégré partout (recommandé si vous avez AD).
   Mettez au moins un DC capable de DNS dans chaque bureau, utilisez la réplication AD, et gardez les clients pointés vers le DNS local.
   Cela réduit la sensibilité au WAN et localise les pannes.
2. DNS central autoritatif + résolveurs de branche en redirection.
   Les bureaux exécutent des résolveurs en cache qui redirigent les requêtes pour les zones internes vers le siège ; tout le reste va en amont.
   Cela marche bien si vous ne souhaitez pas de DC dans les branches.
3. Split-horizon avec vues interne et externe.
   Même nom, réponses différentes en interne et en externe. Utile quand le DNS public existe pour votre domaine mais que les réponses internes doivent différer (endpoints VPN, VIP internes, etc.).

Ce que j’évite : « Chaque site utilise des résolveurs publics (Google/Cloudflare), et on saupoudre des fichiers hosts pour les noms internes. »
Ce n’est pas une conception ; c’est un futur rapport d’incident.

Blague #1 : Le DNS, c’est comme les commérages au bureau : le mauvais enregistrement se répand plus vite que la correction.

Fondations Windows : DNS AD, Sites et réplication de zone

Le DNS AD n’est pas optionnel si vous attendez un AD qui se comporte

Dans un environnement AD, le DNS fait deux jobs : il résout les enregistrements A/AAAA comme tout DNS, et il publie la localisation des services
via des enregistrements SRV. Quand les bureaux se plaignent « la connexion est lente », la cause racine est souvent le DNS : les clients
découvrent des contrôleurs de domaine à travers le WAN, ou ne trouvent pas de catalogue global, ou expirent sur des recherches SRV parce qu’ils
pointent vers un résolveur qui ne voit pas la zone AD.

Utilisez Sites and Services pour contrôler où les clients se connectent

Si vous avez plusieurs bureaux et que vous n’utilisez pas correctement les Sites AD, vous laissez le volant sur le toit de la voiture.
Définissez des sous-réseaux par bureau, mappez-les aux sites, et assurez-vous que chaque site a des contrôleurs de domaine locaux (ou au moins
des forwarders DNS locaux pour les zones AD). Sinon, les clients s’authentifieront volontiers sur « un DC quelconque » à travers un lien lent,
et vous blâmerez « le VPN ».

La portée de réplication des zones est une décision de sécurité et de performance

Pour les zones AD-intégrées, les choix de portée de réplication (domain-wide vs forest-wide vs partitions d’application personnalisées)
affectent ce qui est copié où. Répliquez seulement ce dont vous avez besoin. L’objectif est une résolution prévisible, pas « tout partout ».

Les forwarders conditionnels sont la méthode mature pour la résolution croisée

Si vous avez plusieurs forêts AD ou des domaines internes séparés (fréquent après des fusions), les forwarders conditionnels vous gardent sain d’esprit.
Ils évitent aussi la « récursion complète partout » qui est lente et difficile à sécuriser.

Fondations Linux : resolv.conf, systemd-resolved et recherche DNS

Sachez quelle pile de résolveur vous utilisez réellement

Sur Linux moderne, vous pouvez avoir :

• le résolveur stub de glibc lisant /etc/resolv.conf directement
• systemd-resolved agissant comme stub local (souvent 127.0.0.53) avec DNS par lien
• NetworkManager gérant les résolveurs et écrivant resolv.conf ou parlant à resolved
• dnsmasq/unbound tournant localement comme cache/forwarder

Beaucoup de pannes viennent d’hypothèses mal alignées : quelqu’un édite /etc/resolv.conf à la main, NetworkManager
le « corrige » en retour, et l’utilisateur conclut « Linux ignore les paramètres DNS ». Non, il ignore vos modifications manuelles.

Les domaines de recherche et « ndots » peuvent créer des échecs fantômes

Le comportement du résolveur Linux inclut des suffixes search et l’option ndots. Si ndots:5
est en jeu (commun dans Kubernetes, parfois copié par erreur dans des serveurs), alors une recherche pour
fileserver01 peut provoquer plusieurs tentatives avec suffixes avant d’essayer « tel quel ». Sur un WAN, c’est un multiplicateur de latence.

Rendez Linux déterministe dans les branches

Dans une configuration multi-bureaux, les serveurs Linux devraient pointer vers les résolveurs locaux en priorité. Si vous ne pouvez pas
déployer de résolveurs locaux, assurez-vous au moins que les résolveurs distants sont joignables et à faible latence. « Deux IP DNS aléatoires
dans resolv.conf » sans plan, c’est comment la moitié de vos requêtes partent sur le VPN parce que le résolveur tourne ou bascule.

Tâches pratiques : commandes, sorties et décisions (Windows + Linux)

Voici des vérifications réelles que vous pouvez exécuter aujourd’hui. Chacune inclut (1) la commande, (2) ce que signifie la sortie, et
(3) la décision à prendre ensuite. Le travail DNS n’est pas un séminaire philosophique ; c’est un sport de mesure.

Task 1 (Linux): Identify who owns DNS on this host

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 May  3 10:12 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Signification : Ce système utilise le fichier stub de systemd-resolved ; éditer /etc/resolv.conf directement ne persistera pas.

Décision : Utilisez resolvectl et les paramètres de votre gestionnaire réseau, pas des modifications manuelles.

Task 2 (Linux): Show effective DNS servers and search domains

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

Link 2 (ens160)
Current Scopes: DNS
     DNS Servers: 10.20.0.10 10.20.0.11
      DNS Domain: branch1.corp.example.com corp.example.com

Signification : Le DNS est par lien ; la machine préférera ces serveurs et appliquera ces suffixes de recherche.

Décision : Confirmez que ces IP sont des résolveurs locaux au site. Si ce sont des IP du siège, attendez de la latence et planifiez un résolveur de branche.

Task 3 (Linux): Check raw resolver config (for ndots/search surprises)

cr0x@server:~$ cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search branch1.corp.example.com corp.example.com

Signification : Les applications interrogeront le stub local ; les suffixes de recherche seront essayés.

Décision : Si les recherches de noms courts sont lentes, envisagez de réduire la taille de la liste de recherche et assurez-vous que l’utilisation de noms courts est intentionnelle.

Task 4 (Linux): Confirm which server answers, and whether it’s authoritative

cr0x@server:~$ dig fileserver01.corp.example.com +noall +answer +authority +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41457
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

fileserver01.corp.example.com. 300 IN A 10.30.4.21

Signification : Le drapeau aa indique une réponse autoritative du serveur répondant.

Décision : Si vous attendez une réponse autoritative mais ne voyez pas aa, vous tapez peut-être sur un forwarder/cache ; vérifiez la chaîne de forward et la source de vérité.

Task 5 (Linux): Catch “DNS works, but it’s slow”

cr0x@server:~$ dig fileserver01.corp.example.com @10.20.0.10 +stats
;; ANSWER SECTION:
fileserver01.corp.example.com. 300 IN A 10.30.4.21

;; Query time: 412 msec
;; SERVER: 10.20.0.10#53(10.20.0.10)
;; WHEN: Sat Dec 28 10:12:55 UTC 2025
;; MSG SIZE  rcvd: 74

Signification : 412 ms, c’est du domaine WAN. Pour un résolveur intra-site, vous voulez des dizaines de millisecondes ou moins.

Décision : Si le temps de requête est systématiquement élevé, déployez un résolveur cache local dans le bureau ou corrigez le routage/MTU/pare-feu sur UDP/53.

Task 6 (Linux): Verify the resolver is reachable and not blocked (UDP and TCP)

cr0x@server:~$ nc -vz -u 10.20.0.10 53
Connection to 10.20.0.10 53 port [udp/domain] succeeded!
cr0x@server:~$ nc -vz 10.20.0.10 53
Connection to 10.20.0.10 53 port [tcp/domain] succeeded!

Signification : Les ports UDP et TCP 53 sont joignables. TCP compte pour les grosses réponses et les retries de truncation.

Décision : Si UDP fonctionne mais TCP échoue, corrigez les règles de pare-feu ; certains enregistrements (DNSSEC, beaucoup de SRV) vont échouer de manière intermittente.

Task 7 (Linux): Observe DNS retries and which names are being tried

cr0x@server:~$ sudo tcpdump -ni ens160 port 53 -c 8
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens160, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:13:11.120134 IP 10.20.1.55.56621 > 10.20.0.10.53: 11209+ A? fileserver01.branch1.corp.example.com. (55)
10:13:11.170221 IP 10.20.1.55.56621 > 10.20.0.10.53: 28041+ A? fileserver01.corp.example.com. (45)
10:13:11.220401 IP 10.20.1.55.56621 > 10.20.0.10.53: 19901+ AAAA? fileserver01.corp.example.com. (45)

Signification : Le client essaie d’abord les noms avec suffixe de recherche, puis le domaine de base, puis AAAA.

Décision : Si ces premières tentatives de recherche sont inutiles et lentes (délai NXDOMAIN), réduisez les domaines de recherche ou utilisez des FQDN dans les configs.

Task 8 (Windows): Show what DNS servers and suffixes a client actually uses

cr0x@server:~$ ipconfig /all
Windows IP Configuration

   Host Name . . . . . . . . . . . : WKS-221
   Primary Dns Suffix  . . . . . . .  : corp.example.com
   DNS Servers . . . . . . . . . . . : 10.20.0.10
                                       10.20.0.11
   Connection-specific DNS Suffix  . . : branch1.corp.example.com

Signification : Le client a un suffixe principal et un suffixe spécifique à la connexion, et les essaiera pendant la résolution.

Décision : Si les serveurs DNS listés ne sont pas locaux au site, corrigez les options DHCP ou GPO ; ne laissez pas les portables des branches pointer par défaut vers le DNS du siège.

Task 9 (Windows): Prove whether the DNS server can answer for the zone

cr0x@server:~$ nslookup
> server 10.20.0.10
Default Server:  dns-branch1.corp.example.com
Address:  10.20.0.10
> set type=soa
> corp.example.com
corp.example.com
        primary name server = dc1.corp.example.com
        responsible mail addr = hostmaster.corp.example.com
        serial  = 2457
        refresh = 900 (15 mins)
        retry   = 600 (10 mins)
        expire  = 86400 (1 day)
        default TTL = 3600 (1 hour)

Signification : Vous avez obtenu un SOA, donc le serveur peut parler de manière autoritative (ou au moins peut le récupérer de façon fiable).

Décision : Si le SOA échoue ou expire, ce n’est pas un problème côté client. Corrigez la joignabilité du service DNS ou la configuration de forwarding/hébergement de zone.

Task 10 (Windows): Check which server answered and whether recursion is involved

cr0x@server:~$ nslookup fileserver01.corp.example.com 10.20.0.10
Server:  dns-branch1.corp.example.com
Address:  10.20.0.10

Name:    fileserver01.corp.example.com
Address: 10.30.4.21

Signification : Vous avez forcé un serveur DNS spécifique. Bien. Vous avez éliminé « le client choisit le mauvais serveur ».

Décision : Si cela fonctionne mais que la même recherche sans spécifier le serveur échoue, corrigez la liste et l’ordre des serveurs DNS du client.

Task 11 (Windows Server / AD): Validate AD DNS health quickly

cr0x@server:~$ dcdiag /test:dns /v
Directory Server Diagnosis

Performing initial setup:
   Trying to find home server...
   Home Server = DC1
   * Identified AD Forest.
   Done gathering initial info.

Doing DNS tests...

   DNS Tests are running and not hung. Please wait a few minutes...
   PASS: Basic (Domain membership)
   PASS: Forwarders/Root hints
   PASS: Delegation
   PASS: Records registration

Signification : Les tests DNS de base ont réussi sur ce DC.

Décision : Si cela échoue uniquement dans les branches, concentrez-vous sur la réplication/topologie/forwarding entre sites, pas sur « le DNS est tombé partout ».

Task 12 (Windows Server): Inspect conditional forwarders (when merging domains)

cr0x@server:~$ Get-DnsServerConditionalForwarderZone

ZoneName             MasterServers        ReplicationScope
--------             -------------        ----------------
corp.partner.example {192.0.2.53,192.0.2.54} Forest
lab.example.com      {10.50.0.10}          Domain

Signification : Des forwarders conditionnels existent et se répliquent ; la portée vous indique jusqu’où.

Décision : Si les serveurs DNS de branche n’ont pas le forwarder, corrigez la portée de réplication ou créez-le sur les rôles DNS appropriés.

Task 13 (Linux): Identify whether your BIND/unbound is forwarding correctly

cr0x@server:~$ sudo named-checkconf -p | sed -n '1,80p'
options {
        directory "/var/cache/bind";
        recursion yes;
        allow-recursion { 10.20.0.0/16; };
};

zone "corp.example.com" {
        type forward;
        forward only;
        forwarders { 10.10.0.10; 10.10.0.11; };
};

Signification : Ce résolveur redirige la zone interne vers le DNS du siège et n’essaiera pas d’autres méthodes (forward only).

Décision : Si le DNS du siège est injoignable, la résolution de branche pour cette zone échouera totalement. Envisagez d’ajouter une autorité locale si vous avez besoin d’autonomie en branche.

Task 14 (Linux): Confirm caching behavior and TTL sanity

cr0x@server:~$ dig fileserver01.corp.example.com @10.20.0.10 +noall +answer
fileserver01.corp.example.com. 300 IN A 10.30.4.21
cr0x@server:~$ dig fileserver01.corp.example.com @10.20.0.10 +noall +answer
fileserver01.corp.example.com. 297 IN A 10.30.4.21

Signification : Le TTL décrémente, donc le cache fonctionne (la seconde réponse est servie depuis le cache ou un chemin de cache proche).

Décision : Si le TTL ne décrémente pas et que les temps de réponse restent élevés à chaque fois, vous ne cachez pas ; corrigez le choix du résolveur ou la configuration du forwarder local.

Task 15 (Windows): Flush client cache when testing record changes

cr0x@server:~$ ipconfig /flushdns
Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

Signification : Le cache du client est vidé.

Décision : Utilisez ceci lors de la validation d’une correction. Si cela « corrige » temporairement, le problème sous-jacent peut être un TTL/stale/replication, pas une magie côté client.

Task 16 (Linux): Flush systemd-resolved cache (if applicable)

cr0x@server:~$ sudo resolvectl flush-caches
cr0x@server:~$ resolvectl statistics
DNSSEC supported by current servers: no

Cache
  Current Cache Size: 0
          Cache Hits: 118
        Cache Misses: 54

Signification : Cache vidé ; les statistiques montrent un comportement antérieur hits/misses.

Décision : Si le nombre de misses est énorme et que les serveurs sont distants, vous payez la latence WAN à répétition. Ajoutez un cache local.

Trois mini-histoires d’entreprise (comment ça casse en réalité)

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

Une entreprise de taille moyenne avait deux bureaux et un petit datacenter. Ils ont ajouté rapidement un troisième bureau, « VPN temporaire »,
configuration DHCP « temporaire », « tout temporaire ». Le DHCP du nouveau bureau distribuait des résolveurs publics parce que « DNS c’est DNS ».
Les noms internes devaient fonctionner via des fichiers hosts pendant « quelques semaines ».

Un lundi, une mise à jour Windows s’est propagée, et les portables ont commencé à préférer IPv6. Les résolveurs publics ont renvoyé
un enregistrement AAAA public pour un nom censé être interne (quelqu’un avait accidentellement créé un enregistrement correspondant
lors d’une migration web des mois plus tôt). Résultat : les clients ont tenté d’atteindre un service interne via Internet, ont échoué,
et l’application a interprété cela comme « service down », déclenchant une chaîne d’appels.

La mauvaise hypothèse n’était pas « IPv6 est étrange ». La mauvaise hypothèse était : les noms internes ne fuient pas.
Ils fuient — par collisions, par erreurs de split-horizon, par des colle-copier d’enregistrements entre zones. Une fois que l’équipe a forcé
tous les clients de branche à utiliser des résolveurs internes (et créé une zone interne appropriée avec split-horizon),
le problème a disparu.

La leçon : « DNS temporaire » devient permanent, juste avec une documentation pire.

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

Une autre organisation poursuivait des plaintes de performance dans une branche. Un ingénieur a abaissé les TTLs sur toute la zone interne
à quelque chose de microscopique pour que « les changements se propagent plus vite ». Ça a marché — les changements se sont propagés plus vite.
Mais cela a aussi transformé le DNS en un flux WAN constant car la branche n’avait pas de cache local et les seuls serveurs DNS étaient au siège.

Personne n’a remarqué jusqu’à ce qu’une mise à jour de pare-feu introduise légèrement plus de latence sur UDP/53 à cause de nouvelles règles d’inspection.
Soudain, des applications qui faisaient plusieurs résolutions par transaction ont commencé à échouer. Pas parce que le DNS était tombé,
mais parce que le temps de résolution agrégé dépassait le budget de timeout de l’application.

Ils ont remonté les TTLs, ajouté un petit résolveur cache dans la branche, et imposé une règle : les changements de TTL nécessitent une revue
de performance quand des liens WAN sont impliqués. « Propagation rapide » c’est bien ; « dépendance WAN amplifiée » ne l’est pas.

Blague #2 : Mettre un TTL de 5 secondes partout, c’est comme programmer des exercices d’évacuation quotidiens — techniquement tout le monde est prêt, pratiquement personne ne travaille.

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

Une grande entreprise exécutait un DNS intégré AD avec un DC par site et une politique cohérente : les clients n’utilisent que des serveurs DNS locaux,
et ces serveurs redirigent les requêtes externes vers un petit ensemble de résolveurs en amont contrôlés. Ils avaient aussi une habitude opérationnelle simple :
chaque ticket de changement de site incluait une checklist de validation DNS et une « capture dig depuis la branche » équivalente.

Une nuit, un incident transporteur a dégradé partiellement le MPLS entre deux régions. La latence a grimpé, la perte de paquets est apparue, et plusieurs
équipes ont commencé à signaler des « pannes aléatoires ». L’équipe DNS n’a pas paniqué. Ils avaient déjà des résolveurs locaux, donc la plupart des requêtes
sont restées en site. L’authentification est restée stable parce que les clients ne cherchaient pas des contrôleurs de domaine distants.

Les quelques échecs observés ont été rapidement tracés : des forwarders conditionnels pour une zone partenaire ne pointaient que vers des résolveurs
dans la région affectée. Ils ont ajouté une seconde cible de forwarder dans une autre région, testé, et sont passés à autre chose.

Rien d’héroïque n’est arrivé. C’est le point. Une conception ennuyeuse réduit le nombre de choses qui peuvent devenir excitantes.

Feuille de diagnostic rapide

Quand « le nom d’hôte ne se résout pas au bureau B » arrive dans votre file, l’objectif est de trouver le goulot d’étranglement en quelques minutes, pas
de méditer sur la théorie DNS. Exécutez ceci dans l’ordre.

Première étape : confirmez que c’est DNS, pas joignabilité

• Depuis le client en échec : résolvez le FQDN en spécifiant un serveur (nslookup/dig). Si cela échoue, le chemin DNS est cassé.
• Si ça résout, essayez de joindre l’IP (ping/curl/vérification de port). Si cela échoue, le routage/pare-feu/politique est le problème.

Deuxième étape : trouvez quel serveur DNS le client utilise réellement

• Windows : ipconfig /all et confirmez la liste des serveurs DNS et les suffixes.
• Linux : resolvectl status ou inspectez /etc/resolv.conf selon la pile.
• Recherchez le split-brain : le VPN pousse un DNS, le DHCP pousse un DNS différent, NetworkManager tourne, etc.

Troisième étape : déterminez si le serveur DNS est autoritatif ou forwarder

• Interrogez SOA/NS pour la zone contre le serveur en question.
• Si c’est un forwarder, testez la joignabilité des forwarders depuis ce serveur DNS (pas depuis votre laptop).
• Vérifiez les échecs de fallback TCP et les problèmes de truncation liés à EDNS.

Quatrième étape : vérifiez latence et retries

• Mesurez le temps de requête avec dig +stats.
• Utilisez tcpdump/Wireshark pour voir les requêtes répétées, l’expansion des suffixes de recherche et les timeouts.
• Si la latence est élevée, implémentez un cache local et rapprochez l’autorité interne des utilisateurs.

Cinquième étape : validez la correction des données (stale/mauvaise réponse)

• Comparez l’IP retournée avec le routage attendu par bureau.
• Vérifiez les TTLs et le caching négatif.
• Si AD-intégré : confirmez la santé de la réplication AD et que l’enregistrement existe là où vous pensez qu’il existe.

Choix de conception : forwarders vs zones stub vs récursion partout

Forwarders conditionnels : la réponse par défaut pour le DNS inter-bureaux

Les forwarders conditionnels disent : « pour les requêtes dans la zone X, interrogez ces serveurs spécifiques. » Ils sont simples, audités et prévisibles.
En bureaux, un résolveur en cache local avec forwarders conditionnels vous donne de bonnes performances sans dupliquer l’autorité de zone.

Mode d’échec : si les cibles des forwarders ne sont que dans un site, ce site devient une dépendance cachée. Ajoutez au moins deux cibles
dans des domaines de défaillance différents quand c’est possible.

Zones stub : utiles quand vous voulez une logique de renvoi, pas un forwarding complet

Les zones stub récupèrent les NS (et parfois les A glue) pour une zone et les tiennent à jour. Elles sont pratiques quand vous voulez que le résolveur
apprenne dynamiquement les serveurs autoritatifs, plutôt que d’épingler une liste fixe de forwarders.

Mode d’échec : les zones stub ont toujours besoin de joignabilité aux serveurs autoritatifs. Si votre routage est asymétrique ou filtré, vous pouvez obtenir
une résolution « intermittente » qui fait discuter tout le monde.

Récursion complète partout : tentante, mais désordonnée

Laisser chaque serveur DNS faire une récursion complète vers Internet peut fonctionner, mais cela étend votre surface d’attaque, complique la journalisation,
et rend le filtrage egress plus difficile. En entreprise, il est généralement plus propre de centraliser la récursion vers un petit ensemble de résolveurs
et d’y forwarder.

Split-horizon : faites-le délibérément ou ne le faites pas

Le split-horizon DNS est approprié quand la même zone existe publiquement et en interne mais avec des réponses différentes.
La seule façon saine de l’opérer est avec une responsabilité claire, des tests explicites, et des politiques sur qui voit quelle vue.

Mode d’échec : quelqu’un met à jour le DNS public mais oublie l’interne (ou vice versa). C’est comme ça qu’on obtient « ça marche en hotspot mobile »
et « ça échoue en VPN » en même temps.

Erreurs courantes : symptôme → cause racine → correction

1) « nslookup fonctionne mais l’appli échoue toujours »

Symptôme : La recherche manuelle réussit ; l’application signale « host not found » ou expire.

Cause racine : L’appli utilise un chemin de résolution différent (DNS de container, cache JVM, différences dans /etc/nsswitch.conf),
ou l’application essaie AAAA en premier et expire sur la connectivité IPv6.

Correction : Vérifiez la résolution depuis le runtime de l’appli (dans le container, sous le même utilisateur, dans le même namespace réseau). Vérifiez le comportement AAAA et le routage IPv6.
Envisagez de réduire les TTLs du cache JVM seulement si vous comprenez le coût.

2) « Seul un bureau peut résoudre les noms courts »

Symptôme : ping fileserver01 fonctionne au siège mais échoue en branche ; le FQDN fonctionne partout.

Cause racine : La configuration des suffixes de recherche diffère entre sites (DHCP/GPO/NetworkManager), ou la branche n’a pas le suffixe DNS principal.

Correction : Standardisez les listes de suffixes via les options DHCP et/ou GPO ; réduisez la prolifération des suffixes. Préférez les FQDNs dans les configurations critiques.

3) « La résolution est lente uniquement via le VPN »

Symptôme : Les recherches prennent 500–2000 ms ; les applis expirent ; les captures montrent des retries.

Cause racine : Les clients de branche interrogent le DNS du siège via le VPN ; pas de cache local ; problèmes MTU/fragmentation provoquent la perte de réponses DNS ; TCP/53 bloqué.

Correction : Déployez un résolveur cache local ou un DC/DNS local ; corrigez le MTU et autorisez TCP/53 ; assurez-vous que la taille EDNS UDP n’est pas cassée par des middleboxes.

4) « Reçoit aléatoirement la mauvaise IP »

Symptôme : Parfois résout en 10.x, parfois en 192.168.x, parfois en IP publique.

Cause racine : Split-horizon mal appliqué, ou les clients utilisent des serveurs DNS mélangés (un interne, un public), ou des enregistrements obsolètes avec TTLs différents.

Correction : Imposer les serveurs DNS via DHCP/VPN/GPO ; retirer les résolveurs publics des clients internes ; auditer les politiques split-horizon et garantir des vues cohérentes.

5) « Un nouvel enregistrement existe au siège mais pas en branche »

Symptôme : DC1 le résout ; DC2 en branche renvoie NXDOMAIN.

Cause racine : Problèmes de réplication AD, portée de réplication de zone mal configurée, ou serveur DNS de branche ne tenant pas la zone.

Correction : Vérifiez la santé de la réplication AD ; confirmez que la zone est AD-intégrée et que la portée de réplication inclut ce serveur DNS ; corrigez les liens et horaires de site si nécessaire.

6) « Les serveurs Linux ignorent les paramètres DNS que nous avons poussés »

Symptôme : Vous définissez resolv.conf ; il revient en arrière ; le comportement change après reboot.

Cause racine : systemd-resolved/NetworkManager gère resolv.conf, ou le DHCP écrase les paramètres par interface.

Correction : Configurez le DNS via le gestionnaire correct (resolvectl/paramètres NetworkManager), ou exécutez un résolveur local et pointez vers 127.0.0.1.

7) « L’adhésion au domaine fonctionne, mais les connexions sont lentes dans un bureau »

Symptôme : L’adhésion réussit ; plus tard les logons prennent du temps ; les mises à jour GPO sont lentes.

Cause racine : Les clients découvrent des DC dans un autre site à cause de sous-réseaux AD Sites manquants/mal configurés, ou la branche pointe vers un DNS non-AD.

Correction : Définissez les sous-réseaux et mappez-les aux sites ; assurez local DC/DNS ou forwarding pour les zones AD ; vérifiez la résolution des enregistrements SRV localement.

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

Étape par étape : faire résoudre les noms d’hôtes partout (le plan « fais ceci, pas cela »)

1. Choisissez votre autorité interne.
   Si vous avez AD, l’autorité DNS interne est le DNS AD. Sinon, choisissez BIND/Windows DNS comme source autoritaire et documentez la propriété.
2. Inventoriez les zones et les chevauchements.
   Listez les zones internes, les zones externes, et les collisions éventuelles (même nom utilisé à plusieurs endroits).
3. Définissez un DNS local par bureau.
   Idéal : un DC avec DNS dans chaque bureau. Bon : une petite VM résolveur cache dans chaque bureau avec des forwarders conditionnels vers le siège.
4. Standardisez la distribution des DNS clients.
   DHCP pour les postes fixes, profils VPN pour les utilisateurs distants, et GPO là où c’est approprié. Retirez les résolveurs publics des clients internes.
5. Mettez en place des forwarders conditionnels (ou des zones stub) pour les besoins inter-domaines.
   Particulièrement après des fusions ou quand des zones partenaires existent.
6. Maîtrisez le split-horizon.
   Si vous en avez besoin, formalisez-le : vue interne vs vue externe, contrôle de changement cohérent, et tests explicites depuis chaque bureau.
7. Alignez le routage.
   Ne retournez pas des IP que le site requérant ne peut pas router. Si vous avez des VIP spécifiques au site, vous aurez peut-être besoin de réponses site-aware.
8. Testez depuis chaque bureau avec des commandes reproductibles.
   Utilisez les mêmes noms d’hôtes, mesurez les temps de requête, et vérifiez quel serveur a répondu.
9. Ajoutez du logging et des alertes basiques.
   Alertez sur les timeouts de résolveur, les pics de SERVFAIL, et la joignabilité des forwarders. Les problèmes DNS sont rarement silencieux ; on les ignore juste.
10. Documentez les parties ennuyeuses.
    Quels serveurs sont « autorisés », quelles zones sont internes, comment ajouter des enregistrements, et comment valider depuis chaque bureau.

Checklist opérationnelle : avant de déclarer « DNS corrigé »

• Les clients dans chaque bureau utilisent les serveurs DNS prévus (pas de résolveurs publics infiltrés).
• Les noms internes se résolvent en IP routables depuis chaque bureau.
• La latence des requêtes est acceptable (mesurez, ne devinez pas).
• TCP/53 fonctionne de bout en bout pour les résolveurs.
• Les listes de suffixes de recherche sont cohérentes et non gonflées.
• La réplication AD (si utilisée) est saine et les zones se répliquent à la bonne portée.
• Les caches sont compris : TTLs, caching négatif, et quand vider pendant les tests.

FAQ

1) Chaque bureau doit-il avoir son propre serveur DNS ?

Oui, à moins que vous n’appréciez que la latence WAN fasse partie de chaque connexion et appel d’application. Un résolveur cache local par bureau suffit souvent.
Si vous avez AD, un DC/DNS local par bureau est le modèle le plus propre.

2) Puis-je simplement utiliser des résolveurs DNS publics et ajouter des enregistrements internes quelque part ?

Pas de manière fiable. Les résolveurs publics ne serviront pas votre zone privée, et faire du split-horizon via l’infrastructure publique n’est pas une façon agréable de passer vos week-ends. Gardez la résolution interne en interne.

3) Qu’est-ce qui est mieux : forwarders conditionnels ou zones stub ?

Les forwarders conditionnels sont plus simples et plus prévisibles. Les zones stub sont utiles quand vous voulez des mises à jour automatiques des listes de serveurs autoritatifs.
Si vous hésitez, choisissez les forwarders conditionnels et gardez la liste de cibles redondante.

4) Pourquoi ça marche au bureau A mais pas au bureau B ?

Généralement une des raisons suivantes : serveurs DNS différents distribués par DHCP/VPN, liste de suffixes de recherche différente, réplication de zone manquante
au DNS de branche, ou mismatch de routage (la branche ne peut pas joindre l’IP retournée). Mesurez lequel, puis corrigez la couche spécifique.

5) Comment gérer le split-horizon DNS en toute sécurité ?

Traitez-le comme du code de production : contrôle de changement, tests depuis l’intérieur et l’extérieur, et séparation claire de la gestion des zones interne vs externe.
Ne laissez pas deux équipes mettre à jour « le même nom » à deux endroits sans coordination.

6) Pourquoi les recherches DNS sont lentes alors que le VPN est « up » ?

« VPN up » signifie juste que certains paquets passent. Le DNS est sensible à la latence, à la perte de paquets, au MTU/fragmentation, et au fallback TCP.
Mesurez le temps de requête, confirmez UDP et TCP 53, et ajoutez du cache local pour réduire la dépendance WAN.

7) Comment standardiser les suffixes de recherche entre Windows et Linux ?

Windows : option DHCP pour le suffixe DNS et GPO pour la liste de suffixes lorsque c’est approprié.
Linux : configurez via NetworkManager/systemd-resolved (ou l’outil de votre distribution), pas en éditant resolv.conf à la main.
Gardez la liste courte ; chaque suffixe supplémentaire est un retard potentiel.

8) Qu’en est-il de DoH/DoT — les branches doivent-elles utiliser un DNS chiffré ?

Pour les zones internes, vous voulez généralement du DNS en clair sur vos segments réseau de confiance, avec une sélection stricte des serveurs et de la journalisation.
DoH/DoT peuvent être utiles pour la confidentialité client vers l’extérieur, mais ils peuvent aussi contourner les politiques DNS de l’entreprise s’ils sont non gérés.
Décidez en connaissance de cause ; ne laissez pas les navigateurs choisir votre résolveur sans contrôle.

9) Combien de serveurs DNS les clients devraient-ils avoir configurés ?

Typiquement deux, idéalement locaux au site. Plus n’est pas toujours mieux ; certains clients tournent ou basculent d’une manière qui crée du trafic inter-sites.
La bonne réponse est « deux serveurs joignables dans le même domaine de défaillance », plus une redondance serveur adéquate derrière.

10) Comment éviter les enregistrements obsolètes dans un DNS multi-bureaux ?

Utilisez des mises à jour dynamiques DNS quand c’est approprié, l’âge/nettoyage (scavenging) dans AD DNS avec précaution, et surveillez la santé de la réplication.
Gardez des TTLs raisonnables ; ne les rendez pas minuscules pour compenser une gestion de cycle de vie d’enregistrements approximative.

Prochaines étapes à réaliser cette semaine

Si vous voulez que les noms d’hôtes se résolvent partout entre bureaux, cessez de traiter le DNS comme une utilité en fond et traitez-le comme un
système de production avec topologie. Placez un résolveur près des utilisateurs. Faites des zones internes une autorité que vous contrôlez.
Utilisez des forwarders conditionnels pour la résolution inter-domaines. Gardez la configuration client cohérente et auditée.

Étapes pratiques :

• Choisissez un bureau de branche et mesurez la latence DNS aujourd’hui (dig +stats / nslookup contre les serveurs prévus).
• Auditez DHCP/VPN/GPO pour que les clients de ce bureau n’utilisent que les résolveurs prévus.
• Déployez un résolveur cache local (ou DC/DNS) dans ce bureau et retestez les temps de requête.
• Standardisez les listes de suffixes de recherche ; supprimez la prolifération accidentelle et les réglages ndots mystérieux.
• Rédigez un runbook DNS d’une page : « Quels serveurs, quelles zones, comment tester, comment changer. » Puis utilisez-le réellement.

Votre récompense est une résolution ennuyeuse et cohérente. Ce que devrait être le DNS : invisible, rapide, et jamais à la une.