Domain-Check · Perstat

Auf dieser Seite

Was er prüft
Konfiguration
So läuft ein Check ab
Was ein Ergebnis enthält
Zustände und Schwere
Tarife und Grenzen
Aus der Pipeline oder von einem Agenten
Grenzen
Verwandte Checktypen

Was er prüft

Ein Domain-Monitor liest in jedem Intervall aus jeder seiner Regionen die NS-Menge am Apex einer registrierbaren Domain. Er fragt jeden autoritativen Nameserver direkt nach dem SOA der Zone und vergleicht die Serials. Das deckt Replikationsdrift auf, einen unerreichbaren Nameserver oder einen, der die Zone nicht ausliefert. Danach liest er den Ablauf der Registrierung über WHOIS und validiert DNSSEC, mit dem DS-Record beim Parent, dem DNSKEY und dem RRSIG, das zuerst abläuft.

Wann Sie ihn einsetzen

Eine Domain trägt Produktionsverkehr oder Mail, und ihre Delegation muss über alle Nameserver konsistent bleiben, auch über einen Secondary, den jemand anderes betreibt.
Eine Registrierung darf nicht unbemerkt auslaufen. Das Ablaufdatum soll in der Voreinstellung 14 Tage vorher zum Befund werden oder an der Schwelle, die Sie setzen.
Die Domain ist per DNSSEC signiert, und ein abgelaufenes RRSIG oder eine BOGUS-Validierung soll einen Incident öffnen, statt auf die erste Beschwerde zu warten.

Für einzelne Records und Antwortmengen nutzen Sie den DNS-Record-Check. Für SPF, DMARC und CAA nutzen Sie den DNS-Hygiene-Check. Ein einzelnes Label ist keine registrierbare Domain, und Perstat lehnt es beim Speichern des Monitors ab.

Das Monitor-Formular mit Typ Domain: das Domain-Feld, das Textfeld für erwartete Nameserver mit einem je Zeile und die Warnschwelle für den Ablauf der Registrierung in Tagen. — Das Domain-Formular: Domain, erwartete NS und die Warnschwelle für den Ablauf der Registrierung. Echte Produktoberfläche, Beispieldaten.

Konfiguration

Domain. Eine registrierbare Domain mit mindestens 2 Labels, etwa example.com, ohne Schema, Pfad oder Leerzeichen. Der Check liest die NS-Menge am Apex genau dieses Namens.

Feld	Pflicht	Werte und Voreinstellung	Bedeutung
`domain`Domain	ja	Registrierbare Domain, mindestens 2 Labels	Die Domain, deren Delegation, Registrierung und DNSSEC-Zustand der Check prüft.
`expected_ns`Erwartete NS (optional)	optional	Liste von Nameserver-Namen. Formular: einer je Zeile oder durch Kommas getrennt	Jeder gelistete Name muss in der NS-Menge am Apex erscheinen, Groß- und Kleinschreibung und ein abschließender Punkt zählen nicht. Fehlt ein Name, wird der Check eingeschränkt, und nicht gelistete Nameserver in der Zone sind kein Befund.
`warn_days`Warnen bei Restlaufzeit (Tage)	optional	Tage, Voreinstellung 14	Läuft die Registrierung innerhalb so vieler Tage aus, wird der Check eingeschränkt. Anders als das Warnfenster eines Zertifikats ändert diese Schwelle den Zustand des Monitors.
`interval_seconds`Prüfintervall	optional	Voreinstellung 300 s. Bereich: Minimum des Tarifs bis 24 h	Wie oft jede Region den Check ausführt. Einen Wert außerhalb des Bereichs hebt Perstat auf das Minimum des Tarifs an oder begrenzt ihn auf 24 h, statt ihn abzulehnen.
`regions`Regionen	optional	Teilmenge aus na, eu, as, sa, af, oce. Voreinstellung: die Regionen des Tarifs	Welche Kontinente den Check ausführen. Ohne Angabe wählt der Tarif seine Voreinstellung.

So läuft ein Check ab

Ist ein Check fällig, liest jede Region die NS-Menge am Apex über den eigenen Resolver des Knotens. Eine fehlgeschlagene Abfrage oder eine leere Menge lässt den Check an dieser Stelle fehlschlagen.
Der Knoten löst jeden Nameserver auf seine Adressen auf, IPv4 zuerst und IPv6 ersatzweise. Er fragt ihn direkt nach dem SOA der Zone, und das Check-Budget von 10 s erlaubt bis zu 5 s je Nameserver. Die erste Adresse, die antwortet, zählt, und jeder Nameserver erhält ein eigenes Teilergebnis mit Serial und Adresse.
Danach bewertet der Prüfpunkt die Zonenkomponente. Liefert kein Nameserver ein SOA, schlägt der Check fehl. Ein fehlender erwarteter Nameserver, abweichende Serials oder nur ein Teil antwortender Nameserver ergibt eingeschränkt.
Den Ablauf der Registrierung liest der Prüfpunkt über WHOIS: IANA nennt den WHOIS-Server der TLD, der Prüfpunkt fragt diesen Server über TCP-Port 43 und parst das Ablaufdatum. Die Antwort bleibt 24 h im Prozess des Prüfpunkts gecacht, deshalb fragt jeder Prüfknoten die Registry einmal am Tag und nicht in jedem Intervall. Jede der 2 WHOIS-Abfragen, an IANA und an den TLD-Server, hat einen Timeout von 8 s.
Der validierende Resolver des Knotens prüft DNSSEC, mit dem DS-Record beim Parent, dem DNSKEY und dem RRSIG, das zuerst abläuft. Ein RRSIG mit 3 Tagen oder weniger Restlaufzeit ergibt eingeschränkt, eine abgelaufene Signatur oder eine BOGUS-Validierung lässt den Check fehlschlagen. Eine unsignierte Domain besteht diese Komponente.
Die schlechteste Komponente bestimmt das Ergebnis, und die Detailzeile trägt alle 3 Komponenten. Einen Lauf über 120 s beendet der Knoten mit einem Fehler. Die Region sendet ihr Ergebnis an die Control Plane, wo die Alarmregel entscheidet, ob ein Fehlschlag einen Incident öffnet, sobald das Quorum einig ist.

Die Monitoransicht eines Domain-Checks für perstat.io mit Uptime und dem Zonenurteil. Sie zeigt außerdem eine Zeile je Nameserver mit SOA-Serial und Adresse, den Ablauf der Registrierung und den DNSSEC-Zustand. — Die Monitoransicht: Nameserver mit SOA-Serials, Ablauf der Registrierung und DNSSEC für perstat.io. Echte Produktoberfläche, Beispieldaten.

Was ein Ergebnis enthält

Zone und Delegation: Die Zeile nennt, wie viele Nameserver geantwortet haben, ob ihre SOA-Serials übereinstimmen und welches Serial die Zone trägt. Fehlt ein erwarteter Nameserver in der NS-Menge, nennt die Zeile stattdessen diesen.
Je Nameserver: Ein Teilergebnis je autoritativem Nameserver: SOA serial 2026091301 @ 203.0.113.53, NS IP not resolvable oder kein SOA mit dem letzten Fehler, den der Server zurückgab.
Ablauf der Registrierung: Tage bis zum Ablauf der Registrierung. Innerhalb des Warnfensters lautet die Zeile registration expires in 12d. Ohne brauchbare Antwort der Registry lautet sie expiry unknown (WHOIS could not determine it).
DNSSEC: Die Zeile lautet DNSSEC valid (RRSIG 12d) oder not DNSSEC signed, oder sie nennt eine Signatur, die innerhalb von 3 Tagen abläuft. Sie meldet BOGUS, wenn ein DS-Record existiert, die Validierung aber fehlschlägt. Das Ergebnis DNSSEC not checkable (DNSKEY not resolvable) besteht ebenfalls.
Abfragezeit: latency_ms trägt die Dauer der NS-Abfrage und der SOA-Abfragen. Die WHOIS-Abfrage und die DNSSEC-Validierung gehören nicht dazu.
Nameserver: values trägt die NS-Menge am Apex, wie sie gelesen wurde, in Kleinschreibung und ohne abschließenden Punkt.
Ursachenschicht: Perstat ordnet eine fehlgeschlagene oder eingeschränkte Komponente dem DNS des Ziels zu (target_dns). Eine fehlgeschlagene NS-Abfrage ordnet es nach ihrem Fehler ein: NXDOMAIN oder NODATA als target_dns, alles andere als unknown.
Region: Jedes Ergebnis trägt die Region, die es gemessen hat. Teilergebnisse je IP-Familie oder je Adresse gibt es bei diesem Typ nicht.

Zustände und Schwere

okJeder Nameserver antwortet mit demselben SOA-Serial, und jeder erwartete Nameserver ist vorhanden. Die Registrierung läuft später als warn_days ab heute aus, und DNSSEC validiert oder die Domain ist unsigniert. Eine WHOIS-Abfrage ohne brauchbare Antwort behält diesen Zustand und meldet expiry unknown.
eingeschränktEin erwarteter Nameserver fehlt in der NS-Menge, die SOA-Serials weichen ab, oder nur ein Teil der Nameserver antwortet. Eingeschränkt ist der Check auch, wenn die Registrierung innerhalb von warn_days ausläuft oder ein RRSIG innerhalb von 3 Tagen abläuft.
ausgefallenDie NS-Abfrage schlägt fehl oder liefert keine Records, oder kein Nameserver liefert ein SOA. Der Check schlägt auch fehl, wenn die Registrierung abgelaufen ist, DNSSEC BOGUS ist oder ein RRSIG abgelaufen ist.
FehlerDie Domain ist leer, oder der Resolver des Knotens lässt sich nicht initialisieren. Das zählt als Ausfall mit Schwere critical.

Per Quorum bestätigt: Standardmäßig müssen 2 Regionen den Fehler melden, bevor Perstat einen Incident öffnet. Die Voreinstellung der Organisation verlangt 2 Regionen und 2 aufeinanderfolgende Checks. Ein Monitor kann eine eigene Regel tragen (Anzahl oder Prozent, aufeinanderfolgende Checks und Mindestdauer).

Tarife und Grenzen

Kürzestes Intervall: Free erlaubt 300 s, Pulse 60 s und Sentinel 30 s. Command erlaubt 15 s und Enterprise 10 s, beide nur über MCP. Das Webformular bietet 30 s, 1 min, 5 min, 15 min und 1 h.
Regionen: Free nutzt 2 von 6 Regionen und Pulse 3 von 6. Alle 6 stehen ab Sentinel bereit.
Monitore: Free enthält 10 regionale Monitore, Pulse 50, Sentinel 150 und Command 500. Die Kontingente in Enterprise sind individuell. Die Zahl gilt für die 11 regionalen Checktypen.

Alle Tarifgrenzen vergleichen

Aus der Pipeline oder von einem Agenten

Dieselbe config gilt im Deploy-Schritt, in einem MCP-Client wie Claude Code und im Formular oben. create_monitor braucht einen API-Schlüssel für die ganze Organisation. Wenn Sie regions weglassen, wählt der Tarif seine Voreinstellung.

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

Jede Schnittstelle mit ihrer Grenze

Grenzen

Der Ablauf kommt aus WHOIS und kann fehlen. Es gibt kein RDAP. Eine TLD ohne IANA-Verweis oder mit einer Antwort, die der Parser nicht versteht, meldet expiry unknown und bleibt ok.
Registrar-Lock und Transferstatus liest der Check nicht.
Die Warnschwelle für RRSIG liegt fest bei 3 Tagen. warn_days gilt nur für die Registrierung.
Es gibt keine Adressfamilien und keine Teilergebnisse je Adresse. Der Check fragt Nameserver zuerst über IPv4 und nur ersatzweise über IPv6.
Einzelne Records prüft der Check nicht, ebenso wenig SPF, DMARC und CAA. Records deckt der DNS-Record-Check ab, SPF, DMARC und CAA der DNS-Hygiene-Check.
Die Delegations-NS-Menge beim Parent vergleicht der Check nicht mit der NS-Menge am Apex.

Alle Checktypen