Glossary
DNS monitoring
DNS monitoring is checking that a domain's DNS records still resolve, and still resolve to what you expect.
DNS monitoring checks the name resolution step that happens before any request to your service. It asks the question directly — does this name resolve, and does it resolve to the address it should — rather than inferring it from whether a page loaded.
It earns its own check because DNS failures are both total and invisible from the inside. When a record is deleted, an expiry passes, a registrar lock changes something, or a provider has an incident, every customer stops being able to reach you at once while your servers sit perfectly healthy, serving nobody, logging nothing unusual. Application-level monitoring inside your network typically resolves through a cache and keeps working long after the outside world has stopped.
The second half — checking WHAT it resolves to, not just that it resolves — catches the quieter problems: a record pointed at a decommissioned host, an accidental change during a migration, a hijacked or misconfigured zone. Those resolve perfectly and take you somewhere wrong, which no availability check on the intended destination will ever notice.
Propagation is the thing that makes DNS incidents confusing to diagnose. A change does not take effect everywhere at once; resolvers hold the old answer until its TTL expires. A monitor asking one resolver may see the new record while customers on another still see the old one, so the honest reading of a DNS check is always "this is what one resolver said just now".
| Record | What it does | Why monitor it |
|---|---|---|
| A and AAAA | Point a name at an IPv4 or IPv6 address. | If it disappears or changes, every visitor lands nowhere or somewhere wrong. |
| CNAME | Makes one name an alias of another. | An alias left pointing at a deleted host breaks the site and can be taken over. |
| MX | Names the servers that receive the domain's email. | A missing or wrong MX loses inbound mail while the website stays up. |
| NS | Hands the zone to its authoritative name servers. | A broken delegation takes every name under the domain offline at once. |
| TXT | Free text, used for SPF, DKIM, DMARC and ownership proofs. | A broken SPF or DKIM record sends your outgoing mail to spam. |
| CAA | Lists the certificate authorities allowed to issue for the domain. | A wrong CAA record makes the next certificate renewal fail. |
Questions
What does a DNS monitor check?
It asks for one record on your domain, on a schedule, and fails when the query errors or the answer comes back empty. Some DNS monitors go further and compare the answer with an expected value, which also catches a record that resolves to the wrong place.
How do you monitor DNS?
Pick the records your service cannot live without: usually the A or AAAA record of each public hostname, plus MX if you receive email. Check each one every few minutes or more often. Keep an eye on the domain's registration date too, because an expired domain stops resolving everywhere at once.
What is DNS query monitoring?
Another name for the same job: sending real DNS queries on a schedule and checking the answers that come back. How long each query takes is worth watching too, because a slow name server adds its delay to the first visit of anyone whose resolver has no cached answer.
Why does my domain resolve for me but not for my users?
Resolvers cache each answer for the record's TTL, so after a change some of them keep serving the old one until it expires. That is propagation, and it is why a DNS change can look finished from one network and broken from another. Lower the TTL a day before a planned change.
Is DNS monitoring the same as uptime monitoring?
No, but they overlap. An uptime check on a website has to resolve the name first, so a total DNS failure shows up there as a failed check. A DNS monitor names the cause directly, and it catches failures an uptime check never sees, like a broken MX record that stops email while the site stays up.
In Uptimely
Uptimely's DNS monitor queries one record type you choose (A, AAAA, CNAME, MX, NS, TXT, SOA, PTR, SRV or CAA), through the probe's own resolver (you cannot choose a name server), and fails when the query errors or comes back empty. It checks that the record resolves, not what it resolves to. The separate Domain monitor checks that the domain itself still exists, by DNS and then by WHOIS.
Uptimely's DNS monitors check the records you choose as often as every minute on every plan, and alert you when one stops resolving.
Start monitoring free →Product feature
Related terms
Part of the Uptimely monitoring glossary — plain definitions of the vocabulary uptime monitoring, incident response and status pages are discussed in. Something here read wrong to you? Email support@getuptimely.com.