Comment surveiller les changements de nameservers de vos domaines

Pour surveiller les changements de nameservers, il faut deux choses : relever régulièrement les records NS du domaine (ainsi que les nameservers déclarés au registre) et comparer avec l'état précédent. Vous pouvez le scripter avec cron et dig, ou laisser un service de surveillance DNS capturer l'état, calculer le diff et vous envoyer un email quand quelque chose bouge. L'enjeu est simple : les nameservers décident quel fournisseur DNS répond pour toute la zone. Un changement de NS que vous n'avez pas prévu est soit une erreur, soit une attaque en cours, et dans les deux cas mieux vaut le savoir le jour même. Voici pourquoi ce record mérite une alerte dédiée, comment interpréter un changement selon le contexte, et la mise en place pas à pas.

Pourquoi les nameservers méritent une alerte dédiée

La plupart des records DNS pointent vers une seule chose. Un record A déplace votre site, un record MX déplace vos emails. Le record NS est à part : il confie l'autorité sur toute la zone à un jeu de serveurs. Qui contrôle ces serveurs peut réécrire tous les records d'un coup, en silence, y compris les TXT qui authentifient vos emails et les CNAME derrière vos outils SaaS.

Un changement de nameservers légitime est un événement rare. On migre du DNS par défaut de son registrar vers Cloudflare, ou de Cloudflare vers Route 53, une fois tous les quelques années, et on le sait puisqu'on a changé les nameservers soi-même. Tout changement hors de ce scénario est suspect par défaut.

Une subtilité justifie de surveiller les NS sous deux angles. Le registre stocke les nameservers déclarés pour le domaine (visibles en RDAP), tandis que les résolveurs utilisent les records NS réellement servis en DNS. Les deux listes coïncident normalement. Quand elles divergent, quelque chose est à moitié migré, mal configuré ou en train d'être détourné, et la divergence est un signal en soi, avant même qu'un dysfonctionnement ne soit visible.

Ce qu'un changement de NS signifie selon le contexte

Contexte	Signification probable
Votre domaine, migration prévue	Changement attendu, vérifiez et passez à autre chose
Votre domaine, rien de prévu	Prestataire qui a agi sans prévenir, ou compte compromis
Registre et DNS en désaccord	Migration incomplète ou détournement, à investiguer aujourd'hui
Domaine tiers que vous suivez	Nouvel hébergeur ou prestataire, préparation de lancement, ou changement de mains

Sur vos propres domaines

Si vous aviez planifié une migration, l'alerte confirme que le changement est passé. Si rien n'était prévu, il reste deux explications. La première : une agence, un freelance ou un hébergeur disposant d'un accès a fait une modification sans l'annoncer. La seconde est pire : quelqu'un est entré dans votre compte registrar et a repointé le domaine. C'est exactement ainsi que commence un détournement DNS, et plus vous le détectez tôt, plus les dégâts restent limités.

Une précision honnête s'impose : les données DNS disent ce qui a changé et quand le changement a été détecté, pas qui l'a fait. Pour trouver l'auteur, consultez le journal d'audit de votre compte registrar et interrogez les personnes qui y ont accès. L'intérêt de l'alerte, c'est de lancer cette conversation le jour même plutôt que des semaines plus tard.

Sur des domaines de tiers que vous suivez

Pour un domaine que vous ne contrôlez pas, un changement de nameservers est du renseignement. Un concurrent qui passe de nameservers d'hébergement mutualisé à Cloudflare ou AWS investit dans son infrastructure. Un domaine parké qui bascule vers de vrais nameservers précède souvent un lancement. Et un domaine dont les NS sautent vers un prestataire sans rapport a peut-être changé de propriétaire de fait, quoi qu'en dise encore le WHOIS. Si vous suivez des domaines de clients, de filiales ou de concurrents, les changements de NS comptent parmi les signaux les plus forts que les données publiques peuvent donner.

Mettre en place l'alerte avec Domain Sentinel

Le tout prend deux minutes par domaine :

1. Ajoutez le domaine à votre watchlist.
2. Ouvrez la page de détail du domaine et activez la surveillance DNS. Les contrôles par défaut incluent les records NS de l'apex de la zone : les changements de nameservers sont couverts sans sélection manuelle.
3. Pas d'étape trois pour le côté registre : les notifications de changement couvrent déjà les nameservers déclarés au registre, tirés des données RDAP du domaine.

Les deux contrôles sont quotidiens. Les données de registre sont rafraîchies à 03:00 et le relevé DNS tourne à 04:00 : un changement de nameservers est donc repéré en moins d'un jour, pas en quelques secondes. Pour les NS, ce compromis tient la route : les changements légitimes sont planifiés, et même en cas d'attaque, un email le jour même vaut mieux que l'apprendre par vos clients.

Quand quelque chose change, l'email d'alerte montre l'avant et l'après du record, ce qui permet de distinguer d'un coup d'œil une migration connue d'un prestataire inconnu.

Vérifier l'état actuel manuellement

Avant d'activer la surveillance, notez ce que vos nameservers sont censés être. Interrogez les NS résolus :

dig NS example.com

Recoupez avec un second résolveur public pour écarter un cache périmé :

dig NS example.com @1.1.1.1
dig NS example.com @8.8.8.8

Comparez ensuite avec les nameservers déclarés au registre, via un lookup RDAP ou l'outil de lookup DNS. Les deux listes doivent coïncider exactement. Si elles diffèrent déjà avant même de commencer, voilà votre première enquête.

Partir d'une base saine

Prenez cinq minutes maintenant : listez vos domaines critiques, notez les nameservers attendus pour chacun, et vérifiez que registre et résolution concordent. Puis mettez ces domaines sur une watchlist avec la surveillance DNS activée. À partir de là, la règle est simple : toute alerte de nameservers non planifiée, et toute divergence entre registre et résolution, s'investigue le jour même.