---
title: DNS monitors
description: Check that a DNS record resolves, and optionally that it resolves to the value you expect.
sidebar:
  label: DNS
---

{/* Source of truth: packages/shared/src/monitors.ts — dnsConfigSchema,
    DnsRecordTypes. */}

A DNS monitor resolves a record and reports whether the lookup succeeded — and,
if you tell it what to expect, whether the answer was right.

## Configuration

| Setting | Allowed values | Default |
| --- | --- | --- |
| `host` | the name to resolve | required |
| `recordType` | `ANY`, `A`, `AAAA`, `CNAME`, `MX`, `TXT`, `NS`, `SRV` | `ANY` |
| `nameServer` | a specific resolver to ask | system resolver |
| `expectedValue` | the answer the record must contain | none |

## Checking against a specific nameserver

Leaving `nameServer` empty checks what the world sees through normal recursive
resolution. Setting it asks one server directly, which is how you catch a
provider whose nodes disagree with each other, or confirm that a change has
landed on your authoritative servers before the TTL expires everywhere else.

## What to watch

| Record | Why it matters |
| --- | --- |
| `A` / `AAAA` on your apex | Your site is unreachable if this breaks, whatever the servers are doing |
| `MX` | A dropped MX record silently stops inbound mail |
| `NS` | Catches an expired or misdelegated zone |
| `TXT` | SPF, DKIM and domain-verification records that quietly expire |

## DNS versus DNS Diff

A DNS monitor checks the answer against a value **you specified**. Use it when
you know what the record should be.

[DNS Diff](/monitors/dns-diff) checks the answer against **what it was last
time** and flags any change. Use it when you do not have a fixed expected value
but want to know the moment one appears.

:::note
TTLs make DNS checks lag reality. A record you just changed may keep resolving
to the old value for as long as the previous TTL allowed. Pin `nameServer` to
your authoritative server when you need an answer that is not cached.
:::