Domaine et DNS
La dérive DNS relevée à chaque déploiement, l'expiration du domaine lue par RDAP, et la frise de la page Santé qui raconte ce qui a bougé.
Mis à jour le 11 septembre 2026
Sur cette page
- Ce que PostShip vérifie
- La dérive DNS, à chaque déploiement
- L'expiration du domaine
- Les quatre cartes de la page Santé
- La frise « Ce qui a changé »
- Régler
- Ce qui déclenche une alerte
- Limites et plans
- Dépannage
- Pourquoi la carte DNS dit-elle « il faut deux relevés » ?
- Pourquoi aucune alerte alors qu'une adresse A a changé ?
- Pourquoi « Date de renouvellement inconnue » ?
Un site peut répondre 200 depuis l'ancien hébergeur pendant des heures alors que le domaine a déjà été confié à autre chose — un transfert raté, un CNAME resté sur l'ancien projet, un enregistrement A remplacé d'un bloc. Aucune vérification de page ne le voit. La page Santé du projet regarde ce qu'il y a sous le site : les enregistrements DNS, la date de fin du domaine, le certificat servi, et ce qui a changé entre deux déploiements.
Ce que PostShip vérifie
La dérive DNS, à chaque déploiement
Quand un déploiement est reçu (webhook ou détection par empreinte), PostShip résout l'hôte du projet — enregistrements A, AAAA et CNAME — et mémorise le relevé. Puis il le compare au relevé du déploiement précédent, sur le même hôte. Trois raisons de dériver, et seulement trois :
| Raison | Phrase de l'alerte |
|---|---|
records_gone | le domaine ne résout plus vers aucune adresse |
cname_changed | l'enregistrement CNAME a changé |
a_replaced | les adresses A ont été entièrement remplacées |
La comparaison est volontairement étroite. Un DNS en round-robin rend les mêmes adresses dans un ordre différent, et un CDN fait tourner une partie de son pool en permanence : l'ordre ne compte jamais, et un changement partiel des adresses A n'est pas une dérive — seule la perte de toute adresse en commun l'est. Sans cette règle, la fonction serait de celles qu'on désactive en une semaine.
Deux silences délibérés. Au premier déploiement, il n'y a rien à comparer : pas d'alerte. Et quand le résolveur ne répond pas, rien n'est relevé ni conclu : « je n'ai pas pu poser la question » n'est pas « il n'y a rien ». Un changement de l'URL de base du projet est un nouveau domaine, pas une dérive de l'ancien.
L'expiration du domaine
La page Santé demande au service RDAP (rdap.org) la date d'expiration du domaine — le champ standard de la RFC 9083. Calculée à l'ouverture de la page et gardée six heures, pour que rafraîchir la page ne devienne pas un trafic RDAP sans borne. Si la réponse ne se lit pas proprement, la carte dit « Date de renouvellement inconnue » plutôt que de deviner.
Les quatre cartes de la page Santé
| Carte | Vert | Orange | Rouge |
|---|---|---|---|
| Certificat SSL | plus de 30 jours | 8 à 30 jours, ou dernière lecture en erreur | 7 jours ou moins |
| DNS | enregistrements stables | les enregistrements ont changé | aucun enregistrement A ni AAAA |
| Expiration du domaine | plus de 60 jours | 31 à 60 jours | 30 jours ou moins |
| Indexabilité | le site reste indexable | — | des points bloquent l'indexation |
Le pire des quatre commande la phrase du haut de page : « tout va bien » ne peut pas s'afficher au-dessus d'une carte rouge. Et « au vert » ne se dit que de ce qui a été mesuré : tant qu'une carte est grise, le résumé dit que ces contrôles n'ont pas encore de données.
La frise « Ce qui a changé »
En bas de la page, une chronologie fondue de deux sources : les changements DNS entre relevés consécutifs (avant → après), et les renouvellements du certificat servi — quand sa date de fin change d'une vérification SSL à l'autre. Douze événements au plus, et seulement les changements : un relevé par déploiement fait des centaines de lignes identiques. Un domaine sain rend une chronologie vide, et la page le dit comme une bonne nouvelle. Quand un certificat est renouvelé le lendemain d'un changement de DNS, c'est la proximité des deux lignes qui raconte la migration.
Régler
Rien à régler. La dérive DNS est relevée dès qu'un hébergeur est connecté ou qu'un déploiement est détecté ; la page Santé (Projet → Santé) se remplit seule. Le certificat servi suppose une cible SSL : la carte propose de l'ajouter si le projet n'en a pas. Les contrôles du site ont chacun leur ligne sur la même page.
Ce qui déclenche une alerte
Une dérive, dès le déploiement qui la révèle, sans attendre de confirmation : l'alerte « Dérive DNS » porte l'hôte et la ou les raisons, séparées par « · ». Elle suit vos canaux, vos heures calmes et vos fenêtres de maintenance. La même dérive, encore présente au déploiement suivant, n'alerte pas une seconde fois : l'empreinte de l'alerte est l'ensemble des raisons.
Une dérive coûte 20 points au Ship Score du déploiement (catégorie « dérive DNS »).
Ce qui ne sonne pas : l'expiration du domaine (elle s'affiche, orange puis rouge, mais n'envoie rien) ; un résolveur muet ; un premier déploiement ; une rotation partielle d'adresses.
Limites et plans
| Free | Pro | Team | |
|---|---|---|---|
| Cartes Santé et frise | Oui | Oui | Oui |
| Alerte de dérive DNS | Non | Oui | Oui |
Free ne reçoit pas de webhook de déploiement ; la dérive y est relevée seulement quand un déploiement est détecté autrement, et elle s'affiche sans alerter. Voir les plans.
Dépannage
Pourquoi la carte DNS dit-elle « il faut deux relevés » ?
Un relevé est pris à chaque déploiement, pas à chaque cycle. La première comparaison attend donc votre deuxième déploiement. La frise le dit de la même façon.
Pourquoi aucune alerte alors qu'une adresse A a changé ?
Parce qu'une autre est restée. Une rotation partielle est le fonctionnement normal d'un CDN ; seul le remplacement complet est une dérive. La frise, elle, ne montre que les vraies dérives — une rotation partielle n'y apparaît pas non plus.
Pourquoi « Date de renouvellement inconnue » ?
Tous les registres ne publient pas la date d'expiration par RDAP, et certaines extensions ne répondent pas du tout. Ce n'est pas un défaut de votre domaine : vérifiez la date chez votre bureau d'enregistrement.