DNS record check · Perstat

On this page

What it verifies
Configuration
How a check runs
What a result contains
States and severity
Plans and limits
From the pipeline or an agent
Limits
Related check types

What it verifies

A DNS monitor resolves one record type for one name from each of its regions at every interval. By default the probe’s own resolver answers, so the check sees the zone as a whole. A nameserver named in the config is asked directly, with no cache in between, which shows when one server of a group fails or answers differently. The answer is judged against your assertions and, if it passes, validated against DNSSEC. It can also be compared with the last answer set of another monitor in the organization, so 2 names that must agree fail the check when they diverge.

Use it when

A name must keep resolving to a known address, mail exchanger, or alias, such as the web host, the MX record, or a CNAME to a provider.
Every server of a nameserver group must answer, and answer the same. Create one monitor per server, each with server set to that server.
Two names must agree, for example the apex and www, or the same record in 2 zones. A cross-reference to the sibling monitor turns a divergence into a failed check.

It compares one record type of one name. For NS and SOA consistency across the authoritative servers, registration expiry, and the DNSSEC state of a whole domain, use the domain check. Use the DNS hygiene check for SPF, DMARC, and CAA as a posture, and the HTTP(S) or TCP check for whether the service behind the address answers.

The monitor form with type DNS: the name perstat.io, record type A, and the optional nameserver field with its help text. It also shows the assertions for answer text, answer regex, and the list of expected values. — The DNS form: domain, record type, optional nameserver, and the 3 assertions. Real product UI, sample data.

Configuration

Target. The config field name holds the name to query, and the form labels it Domain. Saving checks only the format and does not resolve the name. It accepts a hostname without scheme, path, or spaces, an IP literal, or a single label, with labels of up to 63 characters and 253 in total.

Field	Required	Values and default	Meaning
`name`Domain	yes	Hostname, single label accepted	The name whose records are queried.
`record_type`Record	optional	`A` (default), `AAAA`, `MX`, `TXT`, `CNAME`, `NS`	The record type to query. The form always sends one, and an API request without it queries `A`.
`expected`Answer contains (text)	optional	String	At least one record of the answer must contain this text. Several assertions combine with AND.
`expected_regex`Answer matches regex	optional	Regular expression	At least one record of the answer must match this pattern. An invalid pattern ends the check as an error.
`expected_all`Expected values (all contained)	optional	List of strings, one per line in the form	Every listed value must be contained in at least one record of the answer. Use it when the whole set matters, for example the NS records of a zone.
`server`Nameserver (optional)	optional	Hostname or IP. Default: the probe’s own resolver	The nameserver to ask directly, with no cache in between. Empty means the probe’s own resolver, which sees the zone as a whole.
`cross_ref`Cross-reference monitor	optional	`{"monitor": "<monitor id>", "mode": "identical"}`. Mode `identical` (default), `subset`, or `overlap`	Compares this answer set with the last answer set of another monitor in the organization. Mode `identical` demands equal sets, `subset` demands that every value here is in the other set, and `overlap` demands at least one shared value.
`interval_seconds`Check interval	optional	Default 300 s. Range: plan minimum to 24 h	How often each region runs the check. A value outside the range is raised to the plan minimum or capped at 24 h, not rejected.
`regions`Regions	optional	Subset of na, eu, as, sa, af, oce. Default: the plan’s regions	Which continents run the check. Omit it and the plan picks its default set.

How a check runs

Each region due for the interval first compiles the regular expression and resolves the record type. An invalid pattern or an unsupported type ends the check as an error before any query is sent.
The resolver is chosen: the node’s own measurement resolver, or the nameserver named in server. That nameserver’s hostname is resolved through the node’s resolver and validated against the blocked ranges, which include loopback, private, link-local, and cloud metadata addresses.
The query runs and is timed, and the lookup time is the check’s latency. The DNS engine does not apply the monitor’s fixed 10 s limit to the lookup itself, and the node stops any run after 120 s.
An empty answer fails the check. Otherwise expected, expected_regex, and expected_all combine with AND.
A passing answer is followed by the DNSSEC check on DS, DNSKEY, and RRSIG expiry. A bogus chain or an expired signature fails the check, and every other outcome leaves the result as it is.
The control plane applies the cross-reference when it records a passed result with a non-empty answer set. An unknown mode acts as identical, and a mismatch fails the check with severity critical. A failed verdict then enters the incident evaluation, and the alert policy (regions and consecutive checks) decides when an incident opens.

The monitor view of a DNS check on the A record of perstat.io. It shows 6 regions, uptime 100%, 12 checks in 24 hours, and the alerting rule with a quorum of 2 of 6 regions. It also shows the availability bar and the tabs for recent checks, status changes, and incidents. — The monitor view: uptime, check count, the quorum rule, and the availability bar for the A record of perstat.io. Real product UI, sample data.

What a result contains

Answer: The detail line lists the records of the answer, separated by commas. With a named nameserver, the address that answered follows as (via IP).
Lookup time: The time of the query per region is the result’s latency.
Answer set: The control plane keeps the normalized answer set of every passed check: lowercase, sorted, and deduplicated. A cross-reference compares this set. It is not part of the check result over the API.
Cause layer: A failure at the target is attributed to the layer target_dns. The incident evidence shows it, so a missing record is not filed as a network fault.
Region: Every result carries the region that measured it. There are no sub-results per IP family or address.

States and severity

okThe answer holds at least one record and every assertion matches. DNSSEC is not bogus, no signature has expired, and the cross-reference, where set, agrees.
downThe answer holds no records, an assertion misses, or the cross-reference diverges. The check also fails on a bogus DNSSEC chain or an expired RRSIG. A lookup failure other than NXDOMAIN, or a named nameserver that cannot be resolved, fails it too.
errorThe name does not exist (NXDOMAIN), the regex is invalid, the record type is unsupported, or the named nameserver sits on a private or internal address. It counts as an outage with severity critical.

Confirmed by quorum: by default, 2 regions must report the failure before an incident opens. The engine returns no degraded state for this type, only passed, failed, or error. The organization default asks for 2 regions and 2 consecutive checks. A monitor can carry its own rule (count or percent, consecutive checks, and minimum duration).

Plans and limits

Shortest interval: Free allows 300 s, Pulse 60 s, and Sentinel 30 s. Command allows 15 s and Enterprise 10 s, both only through MCP. The web form offers 30 s, 1 min, 5 min, 15 min, and 1 h.
Regions: Free runs 2 of 6 regions and Pulse 3 of 6. All 6 are available from Sentinel.
Monitors: Free includes 10 probe monitors, Pulse 50, Sentinel 150, and Command 500. Enterprise quotas are custom. The 11 probe types share this quota.

Compare every plan limit

From the pipeline or an agent

The same config works in the deploy step, in an MCP client such as Claude Code, and in the form above. create_monitor needs an organization-wide API key. If you omit regions, the plan picks its default.

{
  "name": "Apex A record",
  "type": "dns",
  "interval_seconds": 60,
  "config": {
    "name": "example.com",
    "record_type": "A",
    "expected": "203.0.113.10"
  }
}

Every interface, with its boundary

Limits

One record type per monitor. A name with an A and an AAAA record needs 2 monitors.
There is no SOA, serial, or delegation comparison across the authoritative servers. The domain check covers that.
TXT records are matched as text, not parsed.
With server pointed at an anycast address, every region reaches its nearest instance. The detail line shows the address actually asked.
This type takes no address_families and returns no per-address sub-results. It runs one query per region, through the node’s resolver or the named nameserver.
A name that does not exist (NXDOMAIN) is an error, not a failed assertion. Both open an incident once the quorum agrees.
The cross-reference needs a monitor of the same organization with at least one recorded answer set: a DNS monitor, or a domain monitor with its NS set. A target without an answer set leaves the cross-reference inactive, so the result stays as measured. API and MCP accept only the monitor’s public ID, and the form offers a picker with every monitor of the project.

All check types