Le DNS dit aux machines où trouver votre site et où livrer le courrier. S’il change sans que vous l’ayez décidé, le trafic peut partir ailleurs alors que l’hébergement d’origine est intact. Une sonde qui ne fait que demander la page voit encore l’ancienne adresse tant que les caches n’ont pas expiré. Surveiller le DNS, c’est comparer les enregistrements autoritaires à une valeur que vous avez notée, et alerter dès qu’ils diffèrent.
Ce n’est pas la même alerte que l’expiration du nom de domaine. Le domaine peut être valide et la zone pointée vers un serveur qui n’est pas le vôtre. L’échéance du nom se suit à part, voir nom de domaine expiré.
Les enregistrements qui comptent
Notez la valeur normale, pas seulement « le DNS marche ». Une surveillance sans valeur attendue ne sait pas qu’un changement est mauvais.
| Enregistrement | Il décide | Alerte si |
|---|---|---|
| NS | Quel serveur fait autorité sur la zone | La liste des NS change |
| A et AAAA | L’adresse du site | L’IP n’est plus celle de l’hébergeur |
| CNAME | Un alias vers un autre nom (CDN, boutique) | La cible change |
| MX | Où arrive le courrier du domaine | Le serveur de messagerie change |
| TXT (SPF, vérification) | L’autorisation d’envoyer, ou une preuve de propriété | L’enregistrement disparaît ou change |
Les NS sont le niveau le plus grave : celui qui les contrôle peut réécrire tout le reste. Un changement de NS non prévu se traite tout de suite, auprès du registrar, pas le lendemain. Un changement de A est presque aussi grave pour le site. Un MX cassé laisse le site en ligne et coupe les e-mails, y compris les messages de réinitialisation de mot de passe : la panne est invisible sur la home.
Le TTL est le temps pendant lequel un résolveur a le droit de garder l’ancienne réponse. Un TTL de plusieurs heures veut dire que, après un détournement, une partie du public voit encore l’ancien site, et après une correction, une partie voit encore le mauvais. La sonde doit interroger les serveurs autoritaires (ceux des NS), pas seulement un résolveur public qui peut être en retard. Compléter par un second résolveur aide à voir ce que le public reçoit déjà.
Changement prévu ou incident
Toute différence avec la valeur notée est une alerte. Ensuite seulement on classe :
- Prévu : migration, nouveau CDN, changement d’e-mail. On vérifie que la nouvelle valeur est bien celle du chantier, puis on met à jour la référence. On ne « désactive l’alerte DNS » pour la semaine.
- Non prévu : personne n’a de chantier ouvert. On considère une erreur (mauvais compte, prestataire, copier-coller) ou une prise de contrôle du registrar ou du DNS. On reprend la main sur le compte, on remet la valeur, on cherche comment la modification a été autorisée.
Le journal des changements doit contenir la ligne DNS du jour, avec l’ancienne et la nouvelle valeur. Sans cette ligne, l’alerte de 22 h n’a pas de contexte. La personne d’astreinte ne doit pas deviner si le nouveau CNAME est celui du CDN signé le matin.
Une sonde HTTP reste nécessaire : le DNS peut être correct et le serveur en 502. L’inverse est vrai aussi. Le monitoring SiteGarde, branché sur l’URL publique, ne remplace pas la comparaison des enregistrements. Il voit un symptôme plus tard, quand les caches ont basculé et que la page a changé ou ne répond plus. Les deux contrôles se règlent ensemble.
Le certificat est encore un autre objet. On peut pointer le DNS au bon endroit et présenter un certificat qui ne couvre pas le nom. Ne concluez pas « le DNS est bon » parce que le cadenas s’affiche sur votre poste : votre résolveur a peut-être l’ancienne IP.
Mettre la référence par écrit
- Exportez NS, A ou AAAA, CNAME, MX et les TXT utiles. C’est la référence.
- Faites comparer cette référence à la zone autoritaire au moins une fois par jour. Un contrôle plus fréquent se justifie si vous craignez une prise de compte, pas pour le TTL lui-même.
- Envoyez l’alerte à quelqu’un qui peut ouvrir le registrar, pas seulement à la boîte générale du marketing.
- Après chaque changement volontaire, mettez à jour la référence le jour même. Une référence périmée alerte en boucle, et la boucle finit ignorée.
- Gardez la double authentification sur le registrar. La meilleure sonde DNS ne sert à rien si n’importe qui peut valider un transfert de zone depuis une session ouverte.
Quand vous ajoutez un sous-domaine (une boutique, un outil), ajoutez son enregistrement à la référence. L’accueil peut être stable pendant que app.exemple.fr pointe dans le vide ou vers un ancien serveur de test.