What Is DNS Monitoring?

DNS monitoring is the continuous, external checking that a domain's DNS records resolve correctly, return the expected values, and respond fast, catching resolution failures, slow lookups, and unexpected record changes before they take an otherwise healthy site offline.

DNS is the lookup layer that turns a hostname like pulsetic.com into an IP address. If that lookup fails or returns the wrong answer, a perfectly healthy server becomes unreachable: the origin is up, responding, and serving traffic, but no client can find it. Because of this, DNS monitoring runs as an external health check from several geographic vantage points rather than from inside your own network.

Each record carries a TTL (time to live) in seconds that tells resolvers how long to cache the answer. A record with a TTL of 3600 is cached for one hour, so an edit can take up to that long to reach any given resolver. Across the global resolver population the conventional worst case is 24 to 48 hours, since every resolver expires its cache on its own clock. Operators lower the TTL to 300 (five minutes) a day or two before a planned migration to shrink that window.

Record types worth monitoring

  • A and AAAA: map the hostname to an IPv4 and IPv6 address; a wrong value sends users to the wrong server.
  • CNAME: aliases one name to another, common for CDN and SaaS endpoints.
  • MX: routes email; a broken MX record silently stops inbound mail.
  • NS: delegates the zone to its authoritative nameservers.
  • TXT: holds SPF, DKIM, and domain-verification strings that affect deliverability and trust.

What to alert on

A healthy uncached lookup completes in roughly 100ms or less, and cached answers often return in under 30ms. Treat anything consistently above 200ms as slow, since it adds directly to TTFB on every cold connection. Sustained times above 200ms usually point to a routing problem or an overloaded nameserver.

  • A monitored record value changed unexpectedly (possible hijack or fat-finger edit).
  • An NXDOMAIN response, meaning the name no longer resolves at all.
  • Lookup time crossing your slow threshold, for example above 200ms.
  • A DNSSEC validation failure, which makes signed zones untrusted.
  • A nameserver that is unreachable or times out.

Pair DNS monitoring with API monitoring and origin checks so an incident report tells you whether the name failed to resolve or the server behind it failed to answer. The two failure modes look identical to an end user but need very different fixes.

See also: Domain & DNS monitoring

Frequently asked questions

  • How is DNS monitoring different from uptime monitoring?

    Uptime monitoring connects to your server and confirms it answers requests. DNS monitoring checks the resolution step that happens first: that the hostname maps to the right address from external resolvers. A site can pass uptime checks from inside your network while DNS fails for the public, so the two together close the gap.

  • What is a good DNS lookup time?

    An uncached lookup from a nearby resolver should finish in about 100ms or less, and cached answers often return in under 30ms. Resolution times that hold above 200ms are noticeable and usually indicate a routing issue or an overloaded nameserver. Lookup latency adds to time to first byte on every new connection.

  • How long do DNS changes take to propagate?

    It depends on the record's TTL. A TTL of 3600 means resolvers cache the old value for up to one hour after a change, and across all resolvers worldwide the practical worst case is 24 to 48 hours. Lowering the TTL to 300 before an edit cuts the maximum wait to about five minutes.

  • Can DNS monitoring detect a hijack?

    Yes. By recording the expected value of each A, MX, or NS record and comparing it on every check from multiple resolvers, monitoring flags any unexpected change within the check interval, often under a minute. A sudden value change or a DNSSEC validation failure is a strong signal that a record was tampered with or misconfigured.