Domaines et certificats
Le DNS complet, le certificat servi, la fiche du domaine au registre et l'email, relevés toutes les 6 heures pour le domaine de production et ses sous-domaines — avec l'historique de ce qui a changé et 3 alertes.
Mis à jour le 25 septembre 2026
Sur cette page
- Ce que PostShip fait
- Le relevé
- Le domaine de production et les sous-domaines
- Ce qui a changé
- Régler
- Ce qui déclenche une alerte
- Limites et plans
- Dépannage
- « Fiche introuvable au registre »
- « Seuls les sous-domaines de … peuvent être suivis ici »
- Le DNS a changé sans que j'aie rien fait
- Pourquoi « TLS 1.0/1.1 encore acceptés » est-il orange ?
- Domaine et DNS
- Ce que PostShip vérifie
- Régler
- Ce qui déclenche une alerte
- Limites et plans
- Dépannage
La page Santé dit en 4 verdicts si le domaine va bien. Domaines et certificats (Projet → Surveillance → Domaines) fait le détail : tout ce qu'il y a sous le site, relu régulièrement, comparé d'un relevé à l'autre, et gardé dans le temps. C'est là qu'on voit un CNAME changer un mardi sans déploiement, un certificat signé par un émetteur qu'on n'a jamais choisi, ou un domaine qui expire dans 3 semaines.
Ce que PostShip fait
Le relevé
Toutes les 6 heures — et tout de suite après un déploiement — PostShip relève chaque domaine suivi du projet :
| Pièce | Ce qui est lu | D'où |
|---|---|---|
| DNS | A, AAAA, CNAME, MX, NS, TXT, CAA, le TTL le plus court, la validation DNSSEC | un résolveur DNS-over-HTTPS |
| Certificat | l'émetteur, les noms couverts, la chaîne jusqu'à la racine, le protocole négocié, les jours restants, et si TLS 1.0/1.1 sont encore acceptés | une poignée de main TLS avec le serveur |
| Domaine | le registrar, les dates d'enregistrement et d'expiration, les statuts (transfert verrouillé, suspendu…), les serveurs de noms, DNSSEC | la fiche RDAP du registre |
| SPF, DKIM, DMARC — les mêmes contrôles que Email (DNS) | le DNS | |
| Certificats émis | les certificats signés pour le domaine ces 7 derniers jours et leurs émetteurs — voir Certificats | les journaux de transparence |
L'email et les certificats émis se lisent au domaine enregistrable (boutique.fr), pas à chaque sous-domaine. Une lecture qui échoue — résolveur muet, registre en panne — ne remplace pas la dernière bonne : la carte garde ce qu'elle savait et dit ce qui n'a pas pu être lu.
Le domaine de production et les sous-domaines
Le domaine de l'URL de production est suivi d'office, dès la première visite de la page. Vous ajoutez les autres hôtes à la main — www, api, app, statut — pourvu qu'ils soient sous le même domaine : chacun a son propre certificat et son propre DNS, et c'est souvent l'API oubliée dont le certificat expire. Jusqu'à 1 domaine par projet avec Découverte, 5 avec Pro, 25 avec Pro Plus. Si l'URL de production change, l'ancien domaine reste suivi comme sous-domaine et le nouveau prend la place.
Ce qui a changé
Chaque relevé est comparé au précédent, pièce par pièce, et chaque différence est inscrite : « CNAME : a.vercel.app → b.netlify.app », « Émetteur : Let's Encrypt → Google Trust Services », « Expiration : 2027-03-01 → 2028-03-01 ». L'ordre des valeurs ne compte jamais. La liste, en bas de page, dit le domaine, la date, la pièce, l'avant et l'après — et marque ce qui a alerté.
Régler
Rien à régler pour le relevé lui-même. « Relever maintenant », en haut de page, force un passage (au plus un toutes les 10 minutes). Les 3 alertes se débrayent une par une dans Alertes → Règles d'alerte : DNS modifié, Domaine bientôt expiré, Certificat inattendu — toutes allumées par défaut.
Ce qui déclenche une alerte
Tout changement s'inscrit ; seuls ceux-ci alertent, avec le diff dans le message :
- DNS modifié : un CNAME, des serveurs de noms, un MX ou un CAA qui change ; des adresses A ou AAAA toutes remplacées ou disparues ; un SPF ou un DMARC réécrit. Une partie des adresses qui tourne — un CDN — n'alerte pas, ni un TXT de vérification qui change.
- Domaine bientôt expiré : à 30, 7 et 1 jour de la date d'expiration au registre, puis le jour où il a expiré. Une alerte par palier, jamais 2.
- Certificat inattendu : le site sert un certificat d'un autre émetteur que la fois d'avant, ou un émetteur jamais vu vient d'en signer un pour votre domaine dans les journaux de transparence.
Les alertes partent sur vos canaux et par email au propriétaire du projet ; un compte qui a tout coupé (vacances) n'en reçoit pas. Un renouvellement de certificat, un TTL, un nom couvert de plus, un registrar qui change : de l'historique, pas une alerte.
Limites et plans
| Découverte | Pro | Pro Plus | |
|---|---|---|---|
| La page | Oui | Oui | Oui |
| Domaines suivis par projet | 1 | 5 | 25 |
| Relevé toutes les 6 heures, historique, alertes | Oui | Oui | Oui |
La page Santé reste ouverte à tous. Voir les plans.
Dépannage
« Fiche introuvable au registre »
Certaines extensions ne publient pas de RDAP, et quelques registres refusent les lectures automatiques. La date d'expiration se vérifie alors chez votre bureau d'enregistrement ; le DNS et le certificat, eux, sont relevés normalement.
« Seuls les sous-domaines de … peuvent être suivis ici »
Un projet suit un domaine et ce qu'il y a dessous. Un autre domaine — le site d'un autre client, un domaine de redirection — est un autre projet.
Le DNS a changé sans que j'aie rien fait
C'est exactement le cas que la page attrape. Vérifiez chez votre registrar (accès, dernière connexion, transfert en cours) et chez votre hébergeur (un projet supprimé, un domaine réassigné). Si le changement est le vôtre, l'entrée reste dans l'historique et dit quand.
Pourquoi « TLS 1.0/1.1 encore acceptés » est-il orange ?
Ces versions sont cassées depuis des années et refusées par les navigateurs récents ; un serveur qui les accepte encore le fait par oubli de configuration. Rien n'est cassé : c'est à corriger chez l'hébergeur ou dans la configuration du serveur.
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é.
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 2 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. 3 raisons de dériver, et seulement 3 :
| 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.
2 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 6 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 4 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 4 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 2 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. 12 é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 → Surveillance → 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 ici : un résolveur muet ; un premier déploiement ; une rotation partielle d'adresses. L'expiration du domaine s'affiche, orange puis rouge ; l'alerte à 30, 7 et 1 jour, le DNS complet relevé toutes les 6 heures et les sous-domaines sont sur Domaines et certificats.
Limites et plans
| Découverte | Pro | Pro Plus | |
|---|---|---|---|
| Cartes Santé et frise | Oui | Oui | Oui |
| Alerte de dérive DNS | Non | Oui | Oui |
Sur Découverte, la dérive est relevée à chaque déploiement et s'affiche, sans alerter : l'alerte de dérive DNS est une alerte de qualité de déploiement, à partir de Pro. Voir les plans.
Dépannage
Pourquoi la carte DNS dit-elle « il faut 2 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.