DNS Monitoring

DNS monitoring in UptimeHunt resolves a hostname for a chosen record type on a schedule and tracks whether the resolver responds, what records it returns, and how quickly. Use it to detect DNS propagation failures, unexpected record changes, missing entries, or degraded resolver performance.

Configuration

Required Parameters

Hostname — The domain or hostname to query. Examples: example.com, mail.example.com, _dmarc.example.com. The query is made exactly as entered; no leading or trailing dots are added.

Record Type — The DNS record type to request. Default: A.

Optional Parameters

Nameserver — IP address or hostname of the resolver to query. Leave blank to use the system default resolver on each probe. Setting an explicit value (e.g. 1.1.1.1 or 8.8.8.8) lets you monitor a specific resolver rather than whatever the probe's OS uses.

Timeout (seconds) — How long to wait for the resolver to reply, in seconds. Default: 5. Applied to both the per-query timeout and the overall request lifetime.

Service Name — Human-readable label shown in the dashboard and alerts.

Enabled — Toggle to pause and resume monitoring without deleting the service.

Check Interval — How often the check runs, in seconds. Default: 180 s. Minimum depends on your plan (Free: 300 s, Pro: 60 s, Team: 30 s, Enterprise: 10 s).

How It Works

On each check interval, the prober:

1. Builds a DNS resolver pointed at the configured nameserver (or the system default).
2. Issues a query for the configured hostname and record type.
3. Waits up to the configured timeout for a reply.
4. Records each returned record's value, type, and TTL, plus the total query time in milliseconds.

Reachability vs. empty results — the prober distinguishes two different failure modes:

• NXDOMAIN or no records of this type — the resolver replied and said the name or record type does not exist. The check is marked reachable = true with record_count = 0. This is data, not a transport failure. The default assertion (dns_record_count ≥ 1) catches it and marks the service down.
• Resolver unreachable or query timed out — the prober could not get a reply at all. The check is marked reachable = false and the service is marked down immediately, regardless of any assertions.

Assertions / Response Validation

Configure assertions in the Expectations tab of the service to define what counts as healthy. If no assertions are configured, the default dns_record_count ≥ 1 is applied automatically.

See Expectations for the full expectations editor reference.

dns_record_count — Record count equals N

Checks that the resolver returned exactly N records. Default severity: degraded.

When to use: Enforce that a round-robin A record always resolves to a fixed number of IPs, or confirm that a TXT record set contains exactly one entry.

Example: An A record for a service load-balanced across three addresses should always return three answers — a dns_record_count equals 3 assertion at degraded severity will alert you if a host is dropped from DNS without removing the service.

dns_record_exists — Record exists

Checks that at least one record was returned. Default severity: down.

When to use: A simpler alternative to dns_record_count ≥ 1 when you only need to confirm the name resolves to something. Pair with dns_record to also verify the returned values.

dns_record — Record value in set

Checks that at least one returned record's value is in the list you specify. Default severity: down.

When to use: Verify that an A record resolves to a known IP address, that an MX record points at a specific mail host, or that a TXT record contains an expected SPF/DKIM string. Specify each acceptable value as a separate entry in the set.

Example: An A record for api.example.com should always resolve to 198.51.100.10 or 198.51.100.11 — add both IPs to the set. If DNS starts returning a different address (e.g. after a misconfigured change) the assertion fails and an incident is opened.

dns_ttl — TTL at least N

Checks that every returned record's TTL is at least N seconds. Default severity: degraded.

When to use: Catch accidental TTL drops before they cause widespread propagation delays. For example, a TTL unexpectedly lowered to 60 s ahead of a planned migration is normal; a TTL of 60 s that persists long after the migration may indicate a forgotten change that will cause unnecessary resolver churn.

Examples

Monitor that a hostname resolves to an expected IP

Service Name:  Production API — A record
Hostname:      api.example.com
Record Type:   A
Nameserver:    (blank — system default)
Timeout:       5
Assertions:
  dns_record_exists      severity: down
  dns_record in set      198.51.100.10, 198.51.100.11    severity: down

The service is healthy as long as at least one returned A record is in the allowed set. A DNS hijack or misconfigured record immediately triggers an incident.

Verify that an MX record is present at a specific resolver

Service Name:  Mail Routing — MX via Cloudflare
Hostname:      example.com
Record Type:   MX
Nameserver:    1.1.1.1
Timeout:       5
Assertions:
  dns_record_exists      severity: down
  dns_ttl ≥ 300          severity: degraded

Running the check against 1.1.1.1 lets you confirm that Cloudflare's resolver sees the current MX record, independently of what the probe's local resolver caches. A TTL below 5 minutes triggers a degraded alert without opening a full incident.

Detect unexpected SPF record changes

Service Name:  SPF Record Integrity
Hostname:      example.com
Record Type:   TXT
Interval:      300
Assertions:
  dns_record_count equals 1   severity: degraded
  dns_record in set            v=spf1 include:_spf.example.com ~all    severity: down

A second TXT record appearing (count ≠ 1) signals a degraded state for investigation. If the SPF value itself changes, the dns_record assertion fires down and opens an incident.

Related Documentation

• Services Management
• Service Details
• Expectations
• Creating Your First Service