Drift DNS : définition, causes et comment le détecter

Votre site fonctionne, vos e-mails partent, personne ne se plaint. Pourtant, la zone DNS de votre domaine ne correspond peut-être plus du tout à ce que vous croyez avoir configuré. Un serveur de noms remplacé lors d'un transfert, un enregistrement MX modifié par le service informatique du client, une clé DKIM perdue pendant une migration : c'est ce qu'on appelle le drift DNS. Voici ce que recouvre ce terme, d'où vient le problème, et comment le détecter avant qu'il ne se transforme en panne ou en faille.

Qu'est-ce qu'un drift DNS ?

Le terme vient de l'infrastructure : on parle de configuration drift (dérive de configuration) quand l'état réel d'un système s'écarte de l'état attendu, documenté ou validé. Appliqué au DNS, le drift DNS désigne tout écart entre :

• la configuration de référence d'un domaine : ce que vous avez décidé, documenté, versionné ;
• la configuration réellement publiée par les serveurs DNS faisant autorité, et visible par le reste d'Internet.

Le drift peut être brutal (un changement de serveurs de noms) ou progressif (des enregistrements TXT ajoutés au fil des années, un vieux A qui pointe encore vers un serveur résilié). Il peut être légitime mais non documenté, accidentel ou malveillant. Dans tous les cas, il a une caractéristique commune : il est silencieux. Le DNS continue de répondre, simplement pas ce que vous attendez.

Pourquoi c'est dangereux

Le DNS décide où vont vos visiteurs et vos e-mails. Un écart sur certains enregistrements a des conséquences immédiates :

• NS : qui contrôle les serveurs de noms contrôle tout le domaine.
• MX : qui contrôle les MX reçoit vos e-mails, y compris les liens de réinitialisation de mot de passe.
• A, AAAA et CNAME : ils déterminent le serveur qui répond à vos visiteurs.
• TXT : SPF, DKIM et DMARC conditionnent la délivrabilité et la protection contre l'usurpation.
• CAA : il conditionne l'émission, et donc le renouvellement, de vos certificats.

Le délai entre le changement et ses effets aggrave le problème : à cause des caches DNS, une modification peut ne produire ses effets qu'après plusieurs heures, et on cherche alors la cause au mauvais endroit.

Les causes les plus fréquentes

1. Migration d'hébergement : le nouvel hébergeur recrée la zone à partir de ce qu'il détecte ou de ce qu'on lui donne. Les enregistrements « invisibles » (DKIM, vérifications de services, sous-domaines peu utilisés) disparaissent.
2. Activation d'un CDN ou d'un proxy : l'import automatique de la zone est rarement exhaustif, et le changement de serveurs de noms remplace toute la zone d'un coup.
3. Transfert ou renouvellement de domaine : certains registrars réappliquent leurs serveurs de noms par défaut lors d'un transfert ou après une période d'expiration.
4. Multiplicité des intervenants : agence, freelance, service informatique du client, prestataire e-mail. Chacun modifie « sa » partie de la zone sans prévenir les autres.
5. Services tiers : un outil SaaS demande d'ajouter ou de remplacer un enregistrement MX ou SPF lors de sa mise en service.
6. Fin d'un service : l'offre DNS de l'ancien hébergeur est résiliée alors que les serveurs de noms pointent toujours vers lui.
7. Compromission : accès au compte du registrar ou de l'hébergeur DNS, puis modification ciblée d'un MX ou d'un sous-domaine, faite pour passer inaperçue. Nous détaillons ces scénarios dans notre article sur les attaques DNS discrètes.

Trois exemples concrets de drift

Les serveurs de noms changés en silence

Un domaine est transféré vers un nouveau registrar pour regrouper la facturation. Le registrar applique ses propres serveurs de noms, qui publient une zone vide ou une page de parking. Le site et la messagerie continuent de fonctionner quelque temps grâce aux caches, puis tombent. Le lien avec le transfert, effectué plusieurs heures auparavant, n'est pas évident pour l'équipe qui constate la panne.

Le MX modifié sans concertation

Le service informatique d'un client adopte une solution de filtrage anti-spam et remplace les MX. Le SPF n'est pas mis à jour, l'agence qui gère le site n'est pas prévenue. Les e-mails du formulaire de contact, envoyés par le site, commencent à échouer DMARC chez certains destinataires. Personne ne fait le lien pendant des semaines.

La clé DKIM perdue pendant une migration

Après un changement d'hébergeur DNS, l'enregistrement google._domainkey n'a pas été recopié. Les e-mails partent toujours, mais sans signature DKIM valide. Si la politique DMARC est stricte et que SPF n'est pas aligné pour certaines sources, les messages sont rejetés.

Détecter un drift DNS pas à pas

1. Définir une référence

Pas de détection sans référence. Exportez la zone depuis votre hébergeur DNS (la plupart proposent un export au format BIND) et conservez-la dans un dépôt Git ou, a minima, dans un document daté. Chaque modification volontaire doit mettre à jour cette référence.

2. Interroger les serveurs faisant autorité, pas un résolveur

Un résolveur public renvoie des réponses en cache, avec un TTL qui décroît : comparer ses réponses d'un jour à l'autre génère de faux écarts. Interrogez directement les serveurs de la zone :

dig +short NS exemple.fr
ns1.hebergeur-dns.net.
ns2.hebergeur-dns.net.

dig @ns1.hebergeur-dns.net exemple.fr MX +norecurse +noall +answer
exemple.fr.   3600   IN   MX   10 mx1.fournisseur-mail.fr.
exemple.fr.   3600   IN   MX   20 mx2.fournisseur-mail.fr.

3. Vérifier la délégation chez le registre

Les serveurs de noms réellement utilisés sont ceux publiés par le registre de l'extension (l'Afnic pour le .fr), pas ceux listés dans votre zone. Un écart entre les deux est lui-même un drift à corriger :

dig +short NS fr.
dig @$(dig +short NS fr. | head -1) exemple.fr NS +norecurse +noall +authority

Vous pouvez aussi suivre toute la chaîne de résolution depuis la racine avec dig +trace exemple.fr.

4. Surveiller le numéro de série SOA

Le champ serial de l'enregistrement SOA est généralement incrémenté à chaque modification de la zone. C'est un indicateur rapide qu'un changement a eu lieu, même s'il ne dit pas lequel :

dig +short SOA exemple.fr
ns1.hebergeur-dns.net. hostmaster.exemple.fr. 2026091401 10800 3600 604800 3600

5. Prendre un instantané et le comparer

Un petit script suffit pour commencer :

#!/bin/sh
DOMAINE=exemple.fr
NS=$(dig +short NS "$DOMAINE" | head -1)
for nom in "$DOMAINE" "www.$DOMAINE" "_dmarc.$DOMAINE" "google._domainkey.$DOMAINE"; do
  for type in NS A AAAA CNAME MX TXT CAA; do
    dig @"$NS" "$nom" "$type" +norecurse +noall +answer
  done
done | sort > "instantane-$(date +%F).txt"

diff reference.txt "instantane-$(date +%F).txt" && echo "Aucun écart"

Planifié chaque jour avec cron et relié à un envoi d'e-mail en cas de différence, ce script détecte déjà une bonne partie des drifts.

6. Classer les écarts par criticité

Tous les changements ne se valent pas. Une classification simple évite de noyer les alertes importantes :

Les limites d'un script maison

Le script ci-dessus est un bon début, mais il montre vite ses limites :

• il ne connaît que les noms que vous lui donnez, pas les sous-domaines ajoutés depuis ;
• il ne gère ni les réponses variables (répartition géographique, rotation d'adresses IP), ni l'aplatissement de CNAME pratiqué par certains hébergeurs DNS ;
• il ne dit pas si un changement est grave, ni ce qu'il casse ;
• il repose sur une machine, une tâche cron et une adresse e-mail qui peuvent eux-mêmes tomber en panne sans prévenir ;
• il ne s'étend pas facilement à des dizaines de domaines.

Réagir à un drift détecté

1. Qualifier : le changement est-il légitime ? Consultez l'historique du compte chez le registrar ou l'hébergeur DNS et interrogez les intervenants.
2. S'il est légitime : mettez à jour la référence et vérifiez ses effets de bord (SPF après un changement de MX, CAA après un changement de CDN).
3. S'il ne l'est pas : restaurez la configuration de référence, changez les mots de passe des comptes concernés, activez la double authentification et le verrouillage du domaine chez le registrar.
4. Dans tous les cas : notez l'incident et sa cause, pour corriger le processus qui l'a permis.

Pour aller plus loin sur la méthode, lisez notre article expliquant pourquoi ne pas surveiller les modifications DNS est une erreur stratégique et notre guide pour surveiller la configuration DNS de votre nom de domaine.

Checklist anti-drift

• Une configuration de référence existe pour chaque domaine, et elle est à jour.
• La délégation NS chez le registre correspond aux NS de la zone.
• Les comptes registrar et DNS ont la double authentification activée et une liste d'accès connue.
• Chaque modification volontaire est notée, avec son auteur et sa raison.
• Les écarts sont détectés automatiquement, au moins une fois par jour.
• Les alertes critiques (NS, MX) arrivent en temps réel à une personne identifiée.

Détecter le drift sans maintenir de script

Domains Defender compare en continu les enregistrements publiés de vos domaines avec leur état précédent et vous alerte à chaque changement : immédiatement pour ce qui est urgent, dans un récapitulatif quotidien pour le reste, par e-mail, Slack, Discord ou webhook. Le plan gratuit surveille un domaine (configuration DNS, certificat SSL et expiration du nom de domaine), de quoi mettre en place une détection de drift en quelques minutes, sans serveur ni tâche planifiée à maintenir.