Le monitoring de nom de domaine vérifie que le nom existe encore, qu’il se résout, et que les serveurs de noms sont ceux que vous avez choisis. Il ne lit pas le HTML. Un contrôle de page peut rester vert jusqu’à la veille de l’expiration, puis plus rien ne se résout. Les deux surveillances se complètent. Les confondre mène à chercher une panne PHP alors que le registre a suspendu le nom.
Expiration et renouvellement
La date qui compte est celle du bureau d’enregistrement, pas celle d’un rappel dans un agenda personnel. Le renouvellement automatique échoue si la carte est expirée, si le compte du registrar est verrouillé, ou si une confirmation manuelle est exigée. Le site, lui, continue de répondre jusqu’au jour dit.
Relevez la date assez tôt pour agir pendant les jours ouvrés. Un préavis de trente jours laisse le temps de joindre le registrar. Un préavis de quarante-huit heures tombe souvent le week-end, et le guide des incidents hors bureau rappelle pourquoi ce délai se paye en durée. Après expiration, une période de rédemption existe chez beaucoup de registres, avec un coût et un délai qui ne sont plus ceux d’un renouvellement simple. Ne comptez pas dessus comme sur un filet normal.
Vérifiez aussi que vous savez qui est titulaire du compte registrar. Une agence qui a déposé le nom pour un client et qui n’est plus en contrat est une cause classique de nom non renouvelé. Le monitoring de la date n’ouvre pas le compte à votre place : il dit qu’il faut l’ouvrir.
Résolution et serveurs de noms
Un nom sain se résout en enregistrements A ou AAAA (et parfois CNAME) cohérents avec l’hébergement actuel. Le contrôle DNS note :
- le nom se résout-il, ou répond-il NXDOMAIN / SERVFAIL ;
- les adresses obtenues sont-elles celles attendues, si vous les avez figées dans le contrat de surveillance ;
- les serveurs de noms (NS) sont-ils toujours les vôtres.
Un NS qui change sans migration prévue est soit une erreur de délégation, soit une prise de contrôle du domaine. Dans les deux cas, le trafic peut partir vers une autre machine tout en gardant le même nom. Le contrôle HTTP suivra alors cette autre machine et pourra afficher un 200 qui n’est pas votre site. D’où l’intérêt de coupler le test de NS et le contenu attendu : le bon HTML sur la mauvaise délégation ne tient pas longtemps, mais le NS changeant est le signal le plus précoce.
Le DNSSEC cassé (signatures expirées, enregistrement DS orphelin après un changement de NS) se voit comme un échec de résolution pour les résolveurs qui valident, et comme un succès pour les autres. Si seulement une partie des visiteurs n’arrive plus, pensez à cette piste avant de redémarrer le serveur web.
La propagation n’est pas une panne. Après un changement voulu, des résolveurs gardent l’ancienne réponse le temps du TTL. Un contrôle qui exige la nouvelle adresse dès la première minute produira de faux échecs. Attendez le TTL, ou acceptez les deux adresses pendant la bascule.
Deux contrôles, deux conclusions
| Symptôme | Domaine | Page |
|---|---|---|
| Nom inexistant | expiration ou NS retirés | le HTTP n’a pas lieu |
| Mauvaise adresse IP | zone DNS | le serveur joint n’est pas le vôtre |
| 500 ou 503 | le nom se résout | l’application ou l’origine est en cause |
| Certificat invalide | le nom est bon | le certificat ne couvre pas ce nom, ou il est expiré |
Le test d’URL mélange volontairement une partie de ces étapes, parce qu’un visiteur les subit en chaîne. Pour corriger, séparez-les. Si la résolution échoue, inutile de chercher dans les journaux PHP. Si elle réussit et que le code est 500, inutile d’appeler le registrar.
SiteGarde contrôle des URL, donc le nom est résolu à chaque essai : un DNS mort apparaît comme un échec de contrôle. La date d’expiration, elle, ne se déduit pas d’un 200. Mettez un rappel sur le registrar, ou un contrôle dédié à cette date, en plus des pages.