DNS monitoring with Uptime Kuma: catch misconfigurations early

DNS is the quiet layer of the internet. When it works, you do not think about it. When it breaks, nothing else works either — websites are unreachable, email stops flowing, APIs time out, and the symptoms often look nothing like a DNS problem. For UK businesses, DNS misconfigurations are a leading cause of self-inflicted downtime, and they are almost always preventable with a little monitoring. This guide covers how to use Uptime Kuma's DNS monitor to catch DNS problems before they become customer-facing incidents. If you are new to Uptime Kuma, the plain-English introduction is the best place to start before reading this one.

Why DNS monitoring matters

HTTP(s) monitoring tells you whether customers can reach your site. DNS monitoring tells you whether the directions to your site still point to the right address. The two catch different failures, and you want both.

Three patterns of DNS failure regularly affect UK businesses. The first is accidental record deletion or modification: someone edits DNS to add a new subdomain and inadvertently removes or changes an existing one. The second is malicious modification: a compromised DNS account is used to redirect traffic to an attacker-controlled address, often briefly and often during out-of-hours windows when the change is least likely to be noticed. The third is propagation or nameserver issues: a legitimate change was made but has not propagated evenly, so some customers see the new record while others see the old.

An HTTP(s) monitor only catches the first and third of these if the failure happens to affect the specific resolver path that Uptime Kuma is using. DNS monitoring catches all three directly by watching the records themselves. For the broader context on what DNS-caused downtime actually costs, see our true cost of downtime for UK businesses.

There is also a fourth category that is easy to overlook: legitimate but unannounced changes. A colleague makes a valid DNS change as part of a migration or experiment, without notifying the wider team. The change itself is fine; the fact that nobody else knew it had happened is not. DNS monitoring with an Expected Result field surfaces these within the monitor's interval, which gives the team a chance to confirm the change was intended before it causes confusion during an incident review.

What the Uptime Kuma DNS monitor checks

Uptime Kuma's DNS monitor is straightforward. You configure it with a hostname to resolve, a record type (A, AAAA, CNAME, MX, TXT, NS, SOA, CAA) and, optionally, an expected value. The monitor resolves the record at each interval and, if you have supplied an expected value, compares it against the result. If the record is missing, malformed, or different from the expected value, the monitor flips to down and fires an alert.

The practical setup fields are roughly:

• Hostname: the name to resolve, for example www.your-brand.co.uk or your-brand.co.uk.
• Resolver Server: which DNS server to query. The default (your Uptime Kuma host's own resolver) works for most cases; specifying 1.1.1.1 or 8.8.8.8 checks a well-known public recursive resolver; specifying your authoritative nameservers directly checks what your DNS provider is serving.
• Resolver Port: 53 is the default; change only if you are querying a non-standard DNS server.
• DNS Record Type: A is the default; pick whichever record you want to monitor.
• Expected Result: the value the record should return. Leave blank if you only want to be alerted when the query fails entirely; fill in if you want to detect unexpected content as well as outright failure.

The monitor runs at whatever interval you configure. DNS records change relatively slowly in normal operation, so 5-minute intervals are perfectly sensible for most cases; aggressive 30-second intervals add little useful signal and generate unnecessary queries against your resolver.

Record types worth watching

Not every DNS record type is worth monitoring, but the common ones are.

A (IPv4 address) and AAAA (IPv6 address). The core "where is this name" records. Monitor the A record for your apex domain, for www, and for any subdomain that represents a distinct service — api, status, admin, app. AAAA records are worth monitoring for the same names if your infrastructure supports IPv6; accidental drops of AAAA records happen more often than people assume because not every DNS tooling workflow touches v6 consistently.

CNAME (canonical name alias). Common for CDN-fronted services — your www record is often a CNAME to a Cloudflare, Fastly or Vercel hostname. Monitor the CNAME target, because a bad CNAME change silently redirects your whole site somewhere unexpected.

MX (mail exchanger). If you run business email, unexpected MX changes stop email flowing. Monitor MX records on your primary email domain.

TXT records. Used for SPF, DKIM, DMARC (email authentication), domain verification for various services, and a grab-bag of other metadata. SPF and DMARC TXT records are particularly worth watching — accidentally deleting them can cause outgoing email to land in spam or be rejected outright.

NS and SOA. Your nameservers and the start-of-authority record. Changes here are rare and usually intentional, but also the ones with the most dramatic consequences. Monitoring NS records specifically catches the worst DNS incident pattern — someone accidentally pointing your domain at the wrong nameservers.

CAA records. Specify which Certificate Authorities are permitted to issue certificates for your domain. If you have a CAA policy, monitor it; an unexpected CAA change is often the first sign of an account compromise.

A pragmatic starting point for a typical UK business domain is five DNS monitors: an A record monitor for the apex domain, an A or CNAME monitor for www, an MX monitor for the mail domain, a TXT monitor for the DMARC record, and a TXT monitor for the SPF record. That covers more than 90% of the failure modes that DNS-caused downtime surfaces through. Larger estates can extend from there.

Detecting unexpected DNS changes

The Expected Result field is what turns a DNS monitor from a generic reachability check into a change-detection tool. Set it to the current known-good value and Uptime Kuma will flag any deviation, immediately. This is particularly useful for three scenarios.

Change control for critical records. If your DMARC policy record or your NS records should only change after a proper change-management process, an unexpected change is either a mistake or a compromise — both warrant immediate investigation.

Detecting half-deployed changes. Legitimate DNS changes sometimes get stuck halfway through — a new record was added, but the old record was not removed, or vice versa. Setting a DNS monitor with the expected new value catches the in-between state.

Catching silent rollbacks. Some DNS providers cache or template records in ways that can silently revert a recent change, particularly when multiple people edit the same zone. An expected-value monitor fires the moment the record reverts, giving you a chance to fix it before propagation carries the rollback to every resolver.

Common DNS failure modes

Knowing the failure modes helps you configure the right monitors in the first place. Here are the ones UK businesses hit most often.

Accidental record removal. The most common. Someone tidies up a DNS zone and accidentally deletes an active record. DNS monitoring catches this instantly; without it, the first sign is usually an angry customer ticket.

Mistyped record value. A hand-edited A record with a fat-finger typo in the IP address, or a CNAME with a small spelling error. The record exists, it just does not point to the right place.

Partial propagation. A change made at the authoritative nameserver takes time to propagate through recursive resolvers. If you need to verify propagation, query multiple resolver servers — 1.1.1.1, 8.8.8.8, 9.9.9.9 — with separate monitors and compare.

Registrar-level changes. The authoritative nameservers for a domain are defined at the registrar, not at the DNS provider. A change made at the registrar to redelegate the zone to a different DNS provider can look like a total DNS failure to anyone watching record values. Monitor NS records to catch this.

Expired domain. If the domain registration lapses, DNS for it stops working. The underlying registration is not something Uptime Kuma monitors directly, but the symptom — all DNS records for the domain become unresolvable — is very much within the DNS monitor's scope.

DNSSEC validation failure. For domains protected with DNSSEC, a mismatched or expired signature record causes validating resolvers to refuse the answer. Symptom from a monitor's perspective is intermittent resolution — some resolvers accept, others reject.

Resolver-side caching. Even when your authoritative records are correct, a stale cache entry at a major public resolver can serve the wrong value to a large slice of customers for up to the record's TTL. There is little you can do from outside the resolver except wait, but monitoring against multiple resolvers makes it obvious that the authoritative record is fine and the problem is downstream.

TTL-related visibility. Records with very long TTLs — hours or days — are slow to propagate any change. If you are about to make a planned change, temporarily reducing the TTL for a day beforehand narrows the window in which old values can be cached anywhere in the world. Monitor the TTL during the transition to confirm it has dropped as intended.

Authoritative vs recursive checks

DNS has two types of servers involved in any resolution: authoritative servers (the ones that actually hold your records) and recursive servers (the ones most clients use, which ask the authoritative servers on their behalf and cache the answer). Uptime Kuma can query either.

Most of the time you want to query a recursive resolver, because that is what real clients use. Querying 1.1.1.1 tells you what the Cloudflare recursive resolver has cached for your domain right now, which is a good approximation of what a customer using Cloudflare DNS sees. Querying 8.8.8.8 does the same for Google's resolver.

Occasionally you want to query an authoritative server directly — your own nameservers, from your DNS provider. This tells you what your DNS provider is serving, before any resolver caching. Useful when you have just made a change and want to confirm the source of truth has been updated, without waiting for propagation.

A sensible pattern for critical domains is to configure two DNS monitors per record: one against a recursive resolver and one against your authoritative nameservers. The pair together distinguishes between "the record itself is wrong" and "the record is right but something is wrong with propagation or caching".

If you need even stronger coverage — for example during a DNS provider migration, or when debugging a subtle propagation problem — configure a small fleet of DNS monitors against three or four different public recursive resolvers (Cloudflare, Google, Quad9 and OpenDNS cover the vast majority of UK traffic). If all four return the same value you can be confident the change has propagated evenly; if one returns a stale value, you know that specific resolver's cache is the source of the trouble.

UK-specific considerations

Several DNS concerns particularly affect UK businesses.

.uk and .co.uk registration. The UK ccTLD is managed by Nominet, and registration is subject to specific UK rules. Renewal reminders from Nominet or your registrar do get lost occasionally; monitoring at least the A record for your apex domain catches the case where renewal did not happen and the registry removed your delegation.

Shared hosting with many customers. Small UK hosting providers often share a single set of nameservers across thousands of customer domains. An issue at that provider affects many customers simultaneously and is often diagnosed faster from customer-side monitoring than from the provider's own internal dashboards.

GDPR implications of DNS compromise. A DNS redirection that points customer-bound traffic to an attacker-controlled server counts as a personal data breach under UK GDPR. The 72-hour notification window applies. Detecting the redirection quickly, with a DNS monitor flagging the unexpected change, buys you hours that would otherwise be spent on forensics.

Public sector domains. .gov.uk, .nhs.uk and related domains have additional governance around DNS changes. Monitoring to ensure changes have actually landed — or, equally, that changes have not silently reverted — is straightforward with Uptime Kuma and is not supported out-of-the-box by most commercial monitoring tools.

CDN and edge-network records. Many UK sites sit behind CDNs that aggressively rewrite DNS to route traffic to the nearest edge. The authoritative records for these services legitimately change, sometimes several times a day, without any action from you. Do not configure Expected Result values for such records — you will generate a stream of false-positive alerts. Monitor only that the record resolves at all, not that it resolves to a specific value.

Combining DNS with HTTP monitoring

DNS monitoring and HTTP(s) monitoring are complementary. They catch different things, they point you at different parts of the stack when something is wrong, and having both gives you much better diagnostic signal than either alone.

A typical healthy setup for a UK business domain looks like:

• HTTP(s) monitor on https://your-brand.co.uk/ (main site health)
• HTTP(s) monitor on https://your-brand.co.uk/specific-path (authenticated or critical page)
• DNS A record monitor on your-brand.co.uk against a recursive resolver
• DNS A record monitor on www.your-brand.co.uk (because the www redirect sometimes diverges)
• DNS MX monitor on your mail domain
• DNS TXT monitor on your SPF and DMARC records

When the HTTP monitor fires but the DNS monitors are green, you know it is a web-layer issue: server, application, CDN. When the DNS monitor fires but HTTP monitors are still green (because they are using a different resolver path), you know DNS is partially wrong. When both fire, you know something larger has happened. The diagnostic speed this buys you is worth the fifteen minutes of extra setup.

Our HTTP(s) monitoring guide covers the details on the web-layer monitors. Together with the DNS monitors described here, you have the base case fully covered. For routing the alerts to somewhere a human reads, see our SMTP notifications guide.

Summary

DNS is the layer most UK businesses think about least and lose most time to. Uptime Kuma's DNS monitor is straightforward to configure and catches the three most common DNS failure patterns — accidental change, malicious change and propagation problems — directly, without relying on an HTTP-level symptom. Watch your A and CNAME records against a recursive resolver as the baseline; add authoritative checks where source-of-truth verification matters; watch MX and critical TXT records if they are part of business-critical infrastructure. Combine DNS monitoring with HTTP monitoring for the diagnostic clarity that neither provides alone. The cost in setup time is tiny; the pay-off the first time a DNS change goes sideways is enormous.

Frequently asked questions