Check de domaine

Ce qu’il vérifie

Un monitor de domaine lit le jeu NS à l’apex d’un domaine enregistrable depuis chacune de ses régions, à chaque intervalle. Il interroge directement chaque serveur de noms faisant autorité sur le SOA de la zone et compare les numéros de série. Une réplication en retard, un serveur injoignable ou un serveur qui ne sert pas la zone devient ainsi visible. Il lit ensuite l’expiration du domaine via WHOIS et valide DNSSEC, avec l’enregistrement DS au parent, la DNSKEY et le RRSIG qui expire en premier.

À utiliser quand

• Un domaine porte du trafic de production ou du mail, et sa délégation doit rester cohérente sur tous les serveurs de noms, y compris un secondaire exploité par quelqu’un d’autre.
• L’enregistrement d’un domaine ne doit pas expirer sans que personne ne le remarque. La date d’expiration doit devenir un constat 14 jours à l’avance par défaut, ou au seuil que vous fixez.
• Le domaine est signé DNSSEC, et un RRSIG expiré ou une validation BOGUS doit ouvrir un incident, pas attendre la première réclamation.

Pour des enregistrements individuels et des ensembles de réponses, utilisez le check d’enregistrement DNS. Pour SPF, DMARC et CAA, utilisez le check d’hygiène DNS. Une étiquette seule n’est pas un domaine enregistrable et elle est refusée lors de la sauvegarde du monitor.

Balayez horizontalement pour examiner la vue du produit.

app.perstat.io

Configuration

Domaine. Un domaine enregistrable d’au moins 2 étiquettes, comme example.com, sans schéma, chemin ni espace. Le check lit le jeu NS à l’apex de ce nom exact.

Déroulement d’un check

1. Chaque région dont l’intervalle est échu lit le jeu NS à l’apex par le résolveur du nœud. Une résolution en échec ou un jeu vide fait échouer le check sur-le-champ.
2. Chaque serveur de noms est résolu en adresses, IPv4 d’abord et IPv6 en repli. Il est interrogé directement sur le SOA de la zone, et le budget de 10 s du check accorde 5 s au plus par serveur de noms. La première adresse qui répond compte, et chaque serveur de noms reçoit son propre sous-résultat avec numéro de série et adresse.
3. Le composant zone est jugé ensuite. Si aucun serveur de noms ne livre de SOA, le check échoue. Un serveur de noms attendu manquant, des numéros de série divergents ou une partie seulement des serveurs de noms qui répond donne dégradé.
4. L’expiration du domaine est lue via WHOIS : l’IANA nomme le serveur WHOIS du TLD, ce serveur est interrogé en TCP sur le port 43, et la date d’expiration est extraite. La réponse reste en cache 24 h dans le processus de la sonde, si bien que chaque nœud de sonde interroge le registre une fois par jour, et non à chaque intervalle. Chacune des 2 requêtes WHOIS, vers l’IANA et vers le serveur du TLD, a un délai de 8 s.
5. DNSSEC est validé par le résolveur validant du nœud, avec l’enregistrement DS au parent, la DNSKEY et le RRSIG qui expire en premier. Un RRSIG à 3 jours ou moins de son expiration donne dégradé, et une signature expirée ou une validation BOGUS fait échouer le check. Un domaine non signé passe ce composant.
6. Le pire composant fixe le résultat, et la ligne de détail porte les 3 composants. Le nœud termine en erreur une exécution qui dépasse 120 s. Le résultat de la région part au plan de contrôle, où la politique d’alerte décide si un échec ouvre un incident une fois le quorum atteint.

Balayez horizontalement pour examiner la vue du produit.

app.perstat.io

Ce que contient un résultat

Zone et délégation

La ligne indique combien de serveurs de noms ont répondu, si leurs numéros de série SOA concordent et quel numéro porte la zone. Si un serveur de noms attendu manque au jeu NS, la ligne le nomme à la place.

Par serveur de noms

Un sous-résultat par serveur de noms faisant autorité : SOA serial 2026091301 @ 203.0.113.53, NS IP not resolvable, ou pas de SOA avec la dernière erreur renvoyée par le serveur.

Expiration du domaine

Les jours restants avant l’expiration du domaine. Dans la fenêtre d’avertissement, la ligne affiche registration expires in 12d. Sans réponse exploitable du registre, elle affiche expiry unknown (WHOIS could not determine it).

DNSSEC

La ligne affiche DNSSEC valid (RRSIG 12d) ou not DNSSEC signed, ou nomme une signature qui expire sous 3 jours. Elle signale BOGUS quand un enregistrement DS existe mais que la validation échoue. Le résultat DNSSEC not checkable (DNSKEY not resolvable) passe aussi.

Temps de résolution

latency_ms porte la durée de la résolution NS et des requêtes SOA. La requête WHOIS et la validation DNSSEC n’en font pas partie.

Serveurs de noms

values porte le jeu NS à l’apex tel qu’il a été lu, en minuscules et sans point final.

Couche de cause

Un composant en échec ou dégradé est attribué au DNS de la cible (target_dns). Une résolution NS en échec est classée selon son erreur : NXDOMAIN ou NODATA en target_dns, tout le reste en unknown.

Région

Chaque résultat porte la région qui l’a mesuré. Ce type n’a pas de sous-résultat par famille IP ni par adresse.

États et gravité

• okChaque serveur de noms répond avec le même numéro de série SOA, et chaque serveur de noms attendu est présent. L’enregistrement du domaine expire au-delà de warn_days à compter d’aujourd’hui, et DNSSEC est validé ou le domaine n’est pas signé. Une requête WHOIS sans réponse exploitable conserve cet état et affiche expiry unknown.
• dégradéUn serveur de noms attendu manque au jeu NS, les numéros de série SOA divergent, ou une partie seulement des serveurs de noms répond. Le check est aussi dégradé quand l’enregistrement du domaine expire dans les warn_days ou qu’un RRSIG expire sous 3 jours.
• en panneLa résolution NS échoue ou ne renvoie aucun enregistrement, ou aucun serveur de noms ne livre de SOA. Le check échoue aussi quand l’enregistrement du domaine a expiré, que DNSSEC est BOGUS ou qu’un RRSIG a expiré.
• erreurLe domaine est vide ou le résolveur du nœud ne peut pas être initialisé. Cet état compte comme une panne de gravité critique.

Confirmé par quorum : par défaut, 2 régions doivent signaler l’échec avant l’ouverture d’un incident. La règle par défaut de l’organisation exige 2 régions et 2 checks consécutifs. Un monitor peut porter sa propre règle (nombre ou pourcentage, checks consécutifs et durée minimale).

Offres et limites

Intervalle minimal

Free permet 300 s, Pulse 60 s et Sentinel 30 s. Command permet 15 s et Enterprise 10 s, les deux uniquement par MCP. Le formulaire web propose 30 s, 1 min, 5 min, 15 min et 1 h.

Régions

Free utilise 2 régions sur 6 et Pulse 3 sur 6. Les 6 sont disponibles à partir de Sentinel.

Monitors

Free inclut 10 monitors de sonde, Pulse 50, Sentinel 150 et Command 500. Les quotas Enterprise sont sur mesure. Le décompte couvre les 11 types de checks régionaux.

Comparer toutes les limites

Depuis le pipeline ou un agent

La même config fonctionne dans l’étape de déploiement, dans un client MCP comme Claude Code et dans le formulaire ci-dessus. create_monitor exige une clé API valable pour toute l’organisation. Si vous omettez regions, l’offre applique sa valeur par défaut.

{
  "name": "Company domain",
  "type": "domain",
  "interval_seconds": 300,
  "config": {
    "domain": "example.com",
    "expected_ns": ["ns1.example.net", "ns2.example.net"],
    "warn_days": 30
  }
}

Chaque interface, avec sa limite

Limites

• L’expiration vient de WHOIS et peut être indisponible. Il n’y a pas de RDAP. Un TLD sans renvoi IANA, ou dont la réponse échappe à l’analyseur, affiche expiry unknown et reste ok.
• Ni le verrou du registrar ni le statut de transfert ne sont lus.
• Le seuil d’avertissement RRSIG est fixé à 3 jours. warn_days ne s’applique qu’à l’enregistrement du domaine.
• Aucune famille d’adresses ni sous-résultat par adresse. Les serveurs de noms sont interrogés d’abord en IPv4, et en IPv6 seulement en repli.
• Ni les enregistrements individuels ni SPF, DMARC et CAA ne sont vérifiés. Le check d’enregistrement DNS couvre les enregistrements, et le check d’hygiène DNS couvre SPF, DMARC et CAA.
• Le jeu NS de délégation au parent n’est pas comparé au jeu NS à l’apex.

Types de checks liés

• Check d’enregistrement DNSUn type d’enregistrement d’un nom, résolu depuis chaque région et comparé à la réponse que vous attendez.
• Check d’hygiène DNSSPF, DMARC avec sa politique et CAA d’un domaine, notés comme posture et jamais comme panne.
• Check de certificat TLSExpiration, émetteur et sujet d’un certificat par handshake TLS direct, avec un avertissement avant l’expiration.

Tous les types de checks