Surveillance DNS vs monitoring d'uptime : ce que chacun détecte

Le monitoring d'uptime vérifie que votre service répond. La surveillance DNS vérifie que votre configuration DNS est toujours celle que vous avez voulue. Le premier observe le symptôme : une page qui charge, un endpoint qui renvoie 200. La seconde observe l'une des causes les plus sournoises de pannes et de détournements : des records modifiés sans que personne ne l'ait décidé. Les deux se recouvrent très peu. Un record A détourné laisse votre tableau d'uptime au vert pendant que le trafic part vers le serveur de quelqu'un d'autre, et une application plantée laisse votre DNS impeccable pendant que vos clients regardent une page d'erreur. Les équipes dont l'activité repose sur leur domaine finissent avec les deux, chacun sur son périmètre.

Ce que fait chaque type de surveillance

Le monitoring d'uptime envoie des requêtes HTTP ou des pings périodiques vers vos endpoints, en général toutes les minutes, et alerte quand une requête expire ou renvoie un code d'erreur. Il répond à une seule question : le service est-il joignable en ce moment ?

La surveillance DNS prend des snapshots périodiques de vos records (A, AAAA, MX, TXT, CNAME, NS) et compare chaque snapshot au précédent. Elle alerte sur toute différence. Elle répond à une autre question : ma configuration est-elle encore celle que j'ai définie ?

	Monitoring d'uptime	Surveillance DNS
Ce qui est vérifié	Réponse HTTP, ping, temps de réponse	Valeurs des records DNS
Fréquence typique	Toutes les 30 secondes à 5 minutes	Une à quelques fois par jour
Déclencheur d'alerte	Timeout, code d'erreur, lenteur	Tout record différent du snapshot précédent
Protège contre	Serveur planté, erreurs applicatives, certificat expiré	Records détournés, email cassé, dérive silencieuse
Angle mort	Les changements qui laissent le site répondre	Les pannes qui ne touchent pas aux records

L'écart de fréquence n'est une faiblesse ni d'un côté ni de l'autre. La disponibilité change à la seconde, donc les checks d'uptime tournent en continu. Les records DNS changent rarement, donc un diff quotidien attrape presque toute modification non autorisée ou accidentelle pendant qu'elle est encore assez récente pour être tracée.

Ce que le monitoring d'uptime ne voit pas

Trois types d'incidents passent au travers d'un check de disponibilité.

L'email cassé

Un record MX modifié ou un SPF abîmé ne fait tomber aucune page web. Votre site charge, tous les checks d'uptime passent, et vos emails sortants finissent en spam ou disparaissent. Personne ne ping un record MX. Si vos inscriptions, vos factures ou votre support passent par l'email, surveiller les records SPF, DKIM et DMARC est le seul moyen automatisé de l'apprendre avant vos clients.

Le détournement propre

Un attaquant qui redirige votre record A vers un serveur qu'il contrôle n'a aucune raison de servir des erreurs. Il sert un site qui fonctionne, souvent une copie parfaite du vôtre, et collecte identifiants ou données bancaires. Chaque check HTTP renvoie 200. Vu de l'outil d'uptime, il ne s'est rien passé. Seul un diff au niveau des records montre que votre domaine pointe désormais vers un endroit où il n'avait jamais pointé. C'est le scénario central de la détection du détournement DNS.

La dérive de configuration

Quelqu'un supprime un record TXT pendant un nettoyage. Un CNAME est écrasé par un script d'automatisation. Les NS changent lors d'une migration de prestataire et personne ne le documente. Rien de tout cela ne casse le site aujourd'hui. Cela ressort des semaines plus tard sous la forme d'une vérification de domaine qui échoue, d'un sous-domaine mort ou d'une authentification email en panne, et à ce moment-là plus personne ne se souvient de ce qui a changé ni quand. Un diff de records transforme chacun de ces cas en alerte datée et précise.

Ce que la surveillance DNS ne voit pas

La symétrie vaut dans les deux sens. Un serveur qui plante, un certificat qui expire, une application qui se met à renvoyer des 500, une base de données qui ralentit chaque page : vos records DNS peuvent être irréprochables pendant tout ce temps. Les snapshots de records ne disent rien de la machine derrière l'adresse IP, ni si elle est vivante, rapide, ou sert le bon contenu. Ce territoire appartient au monitoring d'uptime et au monitoring applicatif, et aucun outil DNS ne les remplace.

Construire les deux couches

La mise en place est simple. Placez un moniteur d'uptime sur vos endpoints critiques ; les options solides ne manquent pas, et plusieurs sont gratuites pour de petits besoins. Placez une surveillance DNS sur les domaines qui portent votre production et votre email.

Domain Sentinel couvre cette seconde couche. Il prend des snapshots quotidiens de vos records DNS, les compare à ceux de la veille et vous alerte par email au moindre changement, sur l'apex et le www par défaut, plus les hostnames personnalisés que vous ajoutez. Il surveille aussi le versant registre via RDAP : statuts EPP, dates d'expiration et nameservers déclarés, ce qui attrape les problèmes côté registrar avant même qu'ils n'atteignent le DNS.

Pour être clair sur la frontière : Domain Sentinel ne fait pas de monitoring d'uptime. Pas de ping, pas de requêtes HTTP, aucune mesure de disponibilité ni de temps de réponse. Si votre serveur tombe, c'est un outil d'uptime dédié qui vous préviendra, et il a toute sa place à côté.

Deux questions pour auditer votre couverture

Si mon record MX changeait cette nuit, qui me préviendrait ? Si mon serveur tombait cette nuit, qui me préviendrait ? Répondez honnêtement aux deux. Toute réponse qui ressemble à « un client, un jour » désigne la couche qui vous manque, et chacune s'ajoute en quelques minutes.