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 website 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?

It can show one. Monitoring that knows the expected value of each A, MX or NS record flags an unexpected change at its next check, which is how most hijacks first become visible. Tools that also validate DNSSEC can catch tampering with a signed zone. Neither says who made the change; the registrar and DNS provider logs do.

What Is DNS Monitoring?

Reviewed by Ionut Caval · Updated October 2026

DNS monitoring is the continuous, external checking that a domain's DNS records resolve and return the expected values, catching unexpected record changes and resolution failures before they take an otherwise healthy website or its email offline. Some tools also time how fast the lookups answer.

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 outside 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.
CAA: names the certificate authorities allowed to issue certificates for the domain.

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.

Tools differ in which of these they cover. Pulsetic's DNS monitoring watches record values: it checks the A, AAAA, CNAME, MX, NS, TXT and CAA records on a domain and its www subdomain every hour and logs each change, but it does not time lookups or validate DNSSEC. A name that stops resolving is caught by an uptime check instead, because the website stops answering.

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.

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 website 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?

It can show one. Monitoring that knows the expected value of each A, MX or NS record flags an unexpected change at its next check, which is how most hijacks first become visible. Tools that also validate DNSSEC can catch tampering with a signed zone. Neither says who made the change; the registrar and DNS provider logs do.

Put these metrics to work. Monitor your website free.

2-minute setup · Cancel any time
Create Free Account

Your Dashboard

No credit card needed