Monitoring

DNS Monitoring + Troubleshooting Workflow

DNS is invisible until it breaks, and then it looks like everything is broken. A small monitoring workflow — one A record, one MX record, one CNAME — turns the messiest class of outage into one of the most predictable.

DNS Monitoring & Troubleshooting Workflow — Catch Resolution Failures Early · How to monitor DNS records, detect propagation issues, and walk a calm operational workflow that isolates resolver, registrar, and origin problems. · /dns-monitoring-and-troubleshooting-workflow

The operational problem with DNS

DNS issues masquerade as outages. The site is up, the origin is healthy, the cert is valid — but users get connection errors because their resolver returned the wrong answer, an old answer, or no answer at all. Without DNS monitoring you spend the first thirty minutes of every incident proving it isn't DNS. With it, you know in one poll.

The records worth monitoring

  • A / AAAA — the foundation. Alert if the value changes unexpectedly.
  • MX — email-dependent businesses lose money silently when MX records drift.
  • CNAME — third-party services (CDNs, status pages, marketing platforms) frequently change their underlying targets.
  • NS — nameserver delegation. A change here is almost always either intentional or catastrophic.
  • TXT (SPF, DKIM, DMARC) — broken records here don't bring the site down, they quietly destroy email deliverability.

A calm DNS troubleshooting workflow

  1. Run a DoH lookup with the tool above. Confirm the record exists and matches expectations.
  2. If the value is wrong, check the registrar — a recent change may not have propagated yet.
  3. If the value is correct but users complain, the issue is downstream (their resolver, ISP cache, or local DNS).
  4. If the lookup itself fails, check your nameservers directly via the NS record path.
  5. Save the hostname as a recurring DNS monitor so the next drift is caught automatically.

Pairing DNS monitoring with uptime

Uptime tells you the site is unreachable. DNS monitoring tells you why. Running them side by side reduces mean-time-to-diagnosis from twenty minutes to one — and that's true whether you're a one-person team or a 50-person operations group.

Recommended next steps

Diagnostic workflow

  1. 1
    Resolve the record now

    Confirm the current DNS answer using DoH.

    DNS lookup
  2. 2
    Diagnose DNS server errors

    When the resolver itself is the problem.

    Fix DNS
  3. 3
    Reference common errors

    NXDOMAIN, SERVFAIL, and the fixes for each.

    DNS errors
  4. 4
    Save as recurring monitor

    Get alerted on unexpected record changes.

    Configure monitor
  5. 5
    Return to dashboard

    Review DNS monitors alongside uptime and SSL.

    Open dashboard

Frequently asked questions

Why monitor DNS separately from uptime?

An uptime check times out when DNS breaks — but it can't tell you whether the problem is DNS, the origin, or routing. A dedicated DNS check answers that in one query.

How fast does a DNS change propagate?

As fast as your TTL allows. A 300-second TTL means changes are visible within five minutes; a 24-hour TTL means a full day of mixed responses. Lower TTLs before planned changes.

What records should I monitor?

A and AAAA for the apex and www, MX for email-critical domains, CNAME for any third-party hostname (CDN, status page), and SPF/DKIM/DMARC TXT records for deliverability.

What does a DNS hijack look like?

Your A record suddenly points to an IP you don't own. Monitoring with expected-value alerts catches this within one poll cycle — long before users notice.

Is DoH (DNS-over-HTTPS) more reliable to monitor?

Yes — DoH avoids the local resolver caching surprises that make traditional DNS debugging frustrating. The checker above uses DoH for consistent answers across regions.

Continue reading

Educational guide. Diagnostic checks run entirely in your browser.