Check del record DNS

Cosa verifica

Un monitor DNS risolve un tipo di record per un nome da ciascuna delle sue regioni a ogni intervallo. Per default risponde il resolver della sonda, così il check vede la zona nel suo insieme. Un nameserver indicato nella configurazione viene interrogato direttamente, senza cache in mezzo, e questo rivela quando un server di un gruppo fallisce o risponde diversamente. La risposta viene giudicata contro le tue asserzioni e, se le supera, validata contro DNSSEC. Può anche essere confrontata con l’ultimo insieme di risposte di un altro monitor dell’organizzazione, così 2 nomi che devono coincidere fanno fallire il check quando divergono.

Da usare quando

• Un nome deve continuare a risolvere verso un indirizzo, un mail exchanger o un alias noti, come l’host web, il record MX o un CNAME verso un provider.
• Ogni server di un gruppo di nameserver deve rispondere, e rispondere allo stesso modo. Crea un monitor per server, ciascuno con server impostato a quel server.
• Due nomi devono coincidere, per esempio l’apex e www, oppure lo stesso record in 2 zone. Un riferimento incrociato al monitor gemello trasforma una divergenza in un check fallito.

Confronta un tipo di record di un nome. Per la coerenza di NS e SOA tra i server autoritativi, la scadenza della registrazione e lo stato DNSSEC di un intero dominio usa il check del dominio. Usa il check di igiene DNS per SPF, DMARC e CAA come postura, e il check HTTP(S) o della porta TCP per sapere se il servizio dietro l’indirizzo risponde.

Scorri di lato per esaminare la vista del prodotto.

app.perstat.io

Configurazione

Target. Il campo di configurazione name contiene il nome da interrogare, e il modulo lo etichetta Dominio. Il salvataggio controlla solo il formato e non risolve il nome. Accetta un hostname senza schema, percorso o spazi, un letterale IP o una singola label, con label fino a 63 caratteri e 253 in totale.

Come si svolge un check

1. Quando scatta un check, ogni regione compila prima l’espressione regolare e risolve il tipo di record. Un pattern non valido o un tipo non supportato chiude il check come errore prima che parta qualsiasi query.
2. Viene scelto il resolver: il resolver di misura del nodo, oppure il nameserver indicato in server. L’hostname di quel nameserver viene risolto tramite il resolver del nodo e validato contro gli intervalli bloccati, che comprendono gli indirizzi loopback, privati, link-local e di metadata cloud.
3. La query viene eseguita e cronometrata, e il tempo del lookup è la latenza del check. Il motore DNS non applica al lookup in sé il limite fisso di 10 s del monitor, e il nodo interrompe qualsiasi esecuzione dopo 120 s.
4. Una risposta vuota fa fallire il check. Altrimenti expected, expected_regex ed expected_all si combinano in AND.
5. A una risposta superata segue il controllo DNSSEC su DS, DNSKEY e scadenza delle RRSIG. Una catena bogus o una firma scaduta fa fallire il check, e ogni altro esito lascia il risultato com’è.
6. Il control plane applica il riferimento incrociato quando registra un risultato superato con un insieme di risposte non vuoto. Una modalità sconosciuta si comporta come identical, e una discrepanza fa fallire il check con gravità critica. Un verdetto fallito entra poi nella valutazione degli incident, e la regola di alert (regioni e check consecutivi) decide quando si apre un incident.

Scorri di lato per esaminare la vista del prodotto.

app.perstat.io

Cosa contiene un risultato

Risposta

La riga di dettaglio elenca i record della risposta, separati da virgole. Con un nameserver indicato, segue l’indirizzo che ha risposto come (via IP).

Tempo di lookup

Il tempo della query per regione è la latenza del risultato.

Insieme delle risposte

Il control plane conserva l’insieme normalizzato delle risposte di ogni check superato: in minuscolo, ordinato e senza duplicati. Un riferimento incrociato confronta questo insieme. Via API non fa parte del risultato del check.

Livello della causa

Un fallimento sul target viene attribuito al livello target_dns. Le evidenze dell’incident lo mostrano, così un record mancante non viene archiviato come guasto di rete.

Regione

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

Stati e gravità

• okLa risposta contiene almeno un record e ogni asserzione corrisponde. DNSSEC non è bogus, nessuna firma è scaduta e il riferimento incrociato, se impostato, coincide.
• downLa risposta non contiene record, un’asserzione non corrisponde o il riferimento incrociato diverge. Il check fallisce anche con una catena DNSSEC bogus, una RRSIG scaduta, un errore di lookup diverso da NXDOMAIN o un nameserver indicato che non si riesce a risolvere.
• erroreIl nome non esiste (NXDOMAIN), la regex non è valida, il tipo di record non è supportato, oppure il nameserver indicato sta su un indirizzo privato o interno. Conta come disservizio con gravità critica.

Confermato dal quorum: di default, 2 regioni devono segnalare il guasto prima che si apra un incident. Per questo tipo il motore non restituisce uno stato degradato, solo superato, fallito o errore. 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. Gli 11 tipi di check regionali condividono questa quota.

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": "Apex A record",
  "type": "dns",
  "interval_seconds": 60,
  "config": {
    "name": "example.com",
    "record_type": "A",
    "expected": "203.0.113.10"
  }
}

Ogni interfaccia, con il suo limite

Limiti

• Un tipo di record per monitor. Un nome con un record A e uno AAAA richiede 2 monitor.
• Non c’è confronto di SOA, seriale o delega tra i server autoritativi. Lo copre il check del dominio.
• I record TXT vengono confrontati come testo, non analizzati.
• Con server puntato a un indirizzo anycast, ogni regione raggiunge l’istanza più vicina. La riga di dettaglio mostra l’indirizzo effettivamente interrogato.
• Questo tipo non accetta address_families e non restituisce sotto-risultati per indirizzo. Esegue una query per regione, tramite il resolver del nodo o il nameserver indicato.
• Un nome che non esiste (NXDOMAIN) è un errore, non un’asserzione fallita. Entrambi aprono un incident una volta raggiunto il quorum.
• Il riferimento incrociato richiede un monitor della stessa organizzazione con almeno un insieme di risposte registrato: un monitor DNS, oppure un monitor del dominio con il suo insieme NS. Un target senza insieme di risposte lascia inattivo il riferimento incrociato, così il risultato resta com’è stato misurato. API e MCP accettano solo l’ID pubblico del monitor, e il modulo offre un selettore con ogni monitor del progetto.

Tipi di check correlati

• Check del dominioDelega su ogni nameserver autoritativo, scadenza della registrazione e DNSSEC di un dominio registrabile.
• Check di igiene DNSSPF, DMARC con la sua policy e CAA di un dominio, valutati come postura e mai come disservizio.
• Check HTTP(S)Disponibilità e risposta di un URL, con asserzioni su stato, body e TLS.
• Check della porta TCPSe una porta accetta una connessione, a scelta con il certificato servito su di essa.

Tutti i tipi di check