Contexte et enjeux
Dans la plupart des organisations, le service de noms de domaine (DNS) n’est remarqué que lorsqu’une panne survient. L’article cite un incident où, après vingt minutes d’investigation, l’ingénieur a découvert un enregistrement pointant vers un serveur désactivé ou une zone qui ne synchronisait plus depuis trois jours. Cette situation montre que le DNS relie applications, services cloud, messagerie et systèmes d’identité, mais qu’il est souvent géré comme une composante secondaire, sans processus de changement formel ni propriétaire clairement défini.
Gestion du changement DNS
Modifier un enregistrement DNS constitue un changement d’infrastructure. Un simple A record peut rendre une application inaccessible, un MX record erroné bloque la livraison du courrier pour l’ensemble du domaine, et un NS record incorrect empêche la résolution de chaque nom d’hôte d’une zone. L’article souligne que les réponses DNS restent en cache après la correction, ce qui prolonge l’impact. Il recommande de réduire le TTL bien avant la modification, en laissant le temps aux résolveurs de vider leurs caches. Après le déploiement, la validation doit couvrir le serveur primaire, les serveurs secondaires et les résolveurs situés dans les réseaux réellement utilisés, afin d’éviter les faux positifs liés à une simple mise à jour du serveur maître.
Redondance et tests de bascule
De nombreuses entreprises possèdent un serveur DNS secondaire, mais la simple présence d’un second n’est pas suffisante. La redondance ne fonctionne que si le serveur secondaire reste synchronisé et capable de répondre de façon autonome. Les transferts de zone peuvent échouer silencieusement, entraînant un retard de plusieurs heures ou jours sans alerte. De plus, placer le primaire et le secondaire sur la même infrastructure physique ou réseau ne protège pas contre une panne de ce segment. L’article insiste sur la nécessité de vérifier régulièrement la synchronisation, d’utiliser des infrastructures indépendantes et de réaliser des tests de bascule planifiés, notamment en arrêtant volontairement le serveur primaire pour confirmer la continuité du service.
Gestion de la dérive et contrôle d’accès
Le phénomène de « DNS drift » se produit progressivement : un serveur désactivé laisse son enregistrement A actif, une adresse IP réaffectée conserve son PTR, ou un CNAME n’est jamais mis à jour après une migration. Chaque petite incohérence s’accumule et peut conduire à des résolutions erronées, voire à la redirection de trafic vers des systèmes non autorisés. L’article recommande de comparer régulièrement les données de zone avec les attributions DHCP, les baux IP et l’inventaire des actifs, voire d’intégrer DNS, DHCP et IPAM pour automatiser la cohérence. Par ailleurs, un accès en écriture trop large constitue un risque opérationnel et de sécurité. Appliquer le principe du moindre privilège, restreindre les droits de modification aux zones détenues par chaque équipe, limiter les transferts de zone aux serveurs secondaires autorisés et empêcher l’exposition des résolveurs récursifs à Internet renforcent la stabilité du service.
