Check del dominio

Cosa verifica

Un monitor del dominio legge l’insieme NS all’apex di un dominio registrabile da ciascuna delle sue regioni a ogni intervallo. Chiede direttamente a ogni nameserver autoritativo il SOA della zona e confronta i seriali, così emergono una deriva della replica, un nameserver irraggiungibile o uno che non serve la zona. Poi legge la scadenza della registrazione via WHOIS e valida DNSSEC, cioè il record DS al parent, la DNSKEY e la RRSIG che scade per prima.

Da usare quando

• Un dominio porta traffico o posta di produzione, e la sua delega deve restare coerente su tutti i nameserver, compreso un secondario gestito da qualcun altro.
• Una registrazione non deve scadere senza che nessuno se ne accorga. La data di scadenza deve diventare un rilievo con 14 giorni di anticipo di default, o alla soglia che imposti tu.
• Il dominio è firmato con DNSSEC, e una RRSIG scaduta o una validazione BOGUS deve aprire un incident, non aspettare il primo reclamo.

Per singoli record e insiemi di risposte usa il check del record DNS. Per SPF, DMARC e CAA usa il check di igiene DNS. Una singola label non è un dominio registrabile e viene rifiutata al salvataggio del monitor.

Scorri di lato per esaminare la vista del prodotto.

app.perstat.io

Configurazione

Dominio. Un dominio registrabile con almeno 2 label, come example.com, senza schema, percorso o spazi. Il check legge l’insieme NS all’apex esattamente di questo nome.

Come si svolge un check

1. Quando scatta un check, ogni regione legge l’insieme NS all’apex tramite il resolver del proprio nodo. Un lookup fallito o un insieme vuoto fa fallire il check già a questo punto.
2. Ogni nameserver viene risolto nei suoi indirizzi, prima IPv4 e poi IPv6 come ripiego. Viene interrogato direttamente per il SOA della zona, e il budget di 10 s del check concede fino a 5 s per nameserver. Conta il primo indirizzo che risponde, e ogni nameserver riceve il proprio sotto-risultato con seriale e indirizzo.
3. Poi viene giudicato il componente zona. Nessun SOA da nessun nameserver fa fallire il check. Un nameserver atteso mancante, seriali divergenti o una risposta solo da una parte dei nameserver rendono il check degradato.
4. La scadenza della registrazione viene letta via WHOIS: IANA indica il server WHOIS del TLD, quel server viene interrogato sulla porta TCP 43 e la data di scadenza viene estratta. La risposta resta in cache nel processo della sonda per 24 h, così ogni nodo sonda interroga il registro una volta al giorno, non a ogni intervallo. Ciascuna delle 2 query WHOIS, a IANA e al server del TLD, ha un timeout di 8 s.
5. DNSSEC viene validato tramite il resolver validante del nodo, controllando il record DS al parent, la DNSKEY e la RRSIG che scade per prima. Una RRSIG con 3 giorni o meno rimanenti è degradata, e una firma scaduta o una validazione BOGUS fa fallire il check. Un dominio non firmato supera questo componente.
6. Il componente peggiore determina il risultato, e la riga di dettaglio porta tutti e 3 i componenti. Il nodo chiude con un errore un’esecuzione che supera 120 s. Il risultato della regione va al control plane, dove la regola di alert decide se un fallimento apre un incident una volta raggiunto il quorum.

Scorri di lato per esaminare la vista del prodotto.

app.perstat.io

Cosa contiene un risultato

Zona e delega

La riga dice quanti nameserver hanno risposto, se i loro seriali SOA coincidono e quale seriale porta la zona. Se un nameserver atteso manca dall’insieme NS, la riga nomina invece quello.

Per nameserver

Un sotto-risultato per nameserver autoritativo: SOA serial 2026091301 @ 203.0.113.53, NS IP not resolvable, oppure nessun SOA con l’ultimo errore restituito dal server.

Scadenza della registrazione

Giorni alla scadenza della registrazione. Dentro la finestra di avviso la riga recita registration expires in 12d. Senza una risposta utilizzabile dal registro recita expiry unknown (WHOIS could not determine it).

DNSSEC

La riga recita DNSSEC valid (RRSIG 12d) o not DNSSEC signed, oppure nomina una firma che scade entro 3 giorni. Riporta BOGUS quando esiste un record DS ma la validazione fallisce. Anche il risultato DNSSEC not checkable (DNSKEY not resolvable) passa.

Tempo di lookup

latency_ms porta la durata del lookup NS e delle query SOA. Il lookup WHOIS e la validazione DNSSEC non ne fanno parte.

Nameserver

values porta l’insieme NS all’apex com’è stato letto, in minuscolo e senza il punto finale.

Livello della causa

Un componente fallito o degradato viene attribuito al DNS del target (target_dns). Un lookup NS fallito viene classificato in base al suo errore: NXDOMAIN o NODATA come target_dns, tutto il resto come unknown.

Regione

Ogni risultato porta la regione che l’ha misurato. Per questo tipo non ci sono sotto-risultati per famiglia IP o per indirizzo.

Stati e gravità

• okOgni nameserver risponde con lo stesso seriale SOA, e ogni nameserver atteso è presente. La registrazione scade oltre warn_days da oggi, e DNSSEC valida oppure il dominio non è firmato. Un lookup WHOIS senza risposta utilizzabile mantiene questo stato e riporta expiry unknown.
• degradatoUn nameserver atteso manca dall’insieme NS, i seriali SOA divergono oppure risponde solo una parte dei nameserver. Il check è degradato anche quando la registrazione scade entro warn_days o una RRSIG scade entro 3 giorni.
• downIl lookup NS fallisce o non restituisce record, oppure nessun nameserver consegna un SOA. Il check fallisce anche quando la registrazione è scaduta, DNSSEC è BOGUS o una RRSIG è scaduta.
• erroreIl dominio è vuoto oppure il resolver del nodo non può essere inizializzato. Conta come disservizio con gravità critica.

Confermato dal quorum: di default, 2 regioni devono segnalare il guasto prima che si apra un incident. Il default dell’organizzazione richiede 2 regioni e 2 check consecutivi. Un monitor può avere una regola propria (numero o percentuale, check consecutivi e durata minima).

Piani e limiti

Intervallo minimo

Free consente 300 s, Pulse 60 s e Sentinel 30 s. Command consente 15 s ed Enterprise 10 s, entrambi solo tramite MCP. Il modulo web offre 30 s, 1 min, 5 min, 15 min e 1 h.

Regioni

Free usa 2 regioni su 6 e Pulse 3 su 6. Tutte e 6 sono disponibili da Sentinel.

Monitor

Free include 10 monitor di sonda, Pulse 50, Sentinel 150 e Command 500. Le quote di Enterprise sono su misura. Il conteggio copre gli 11 tipi di check regionali.

Confronta tutti i limiti

Dalla pipeline o da un agente

La stessa config funziona nello step di deploy, in un client MCP come Claude Code e nel modulo qui sopra. create_monitor richiede una chiave API valida per tutta l’organizzazione. Se ometti regions, il piano sceglie il suo default.

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

Ogni interfaccia, con il suo limite

Limiti

• La scadenza arriva da WHOIS e può non essere disponibile. Non c’è RDAP. Un TLD senza rinvio IANA, o con una risposta che il parser non capisce, riporta expiry unknown e resta ok.
• Non vengono letti né il blocco presso il registrar né lo stato del trasferimento.
• La soglia di avviso delle RRSIG è fissa a 3 giorni. warn_days vale solo per la registrazione.
• Non ci sono famiglie di indirizzi né sotto-risultati per indirizzo. I nameserver vengono interrogati prima su IPv4 e su IPv6 solo come ripiego.
• Non vengono controllati i singoli record, e nemmeno SPF, DMARC e CAA. Il check del record DNS copre i record, e il check di igiene DNS copre SPF, DMARC e CAA.
• L’insieme NS della delega al parent non viene confrontato con l’insieme NS all’apex.

Tipi di check correlati

• Check del record DNSUn tipo di record di un nome, risolto da ogni regione e confrontato con la risposta che ti aspetti.
• Check di igiene DNSSPF, DMARC con la sua policy e CAA di un dominio, valutati come postura e mai come disservizio.
• Check del certificato TLSScadenza, emittente e soggetto di un certificato tramite handshake TLS diretto, con un avviso prima della scadenza.

Tutti i tipi di check