Skip to content

DNS and monitoring

Every check aimed at a hostname begins with a step most people never think about: turning the name into an IP address. When DNS breaks, a perfectly healthy server becomes unreachable for everyone — which makes DNS one of the most common, and most overlooked, causes of downtime.

How resolution works

When anything — a browser, a mail server, a monitoring probe — needs to reach mail.example.com, it asks a resolver. The resolver either answers from cache or walks the hierarchy: the root servers point to the servers for the top-level domain (.com, .sa), which point to the domain's authoritative nameservers, which hold the actual records — an A record mapping the name to an IP, MX records for mail, and so on. The answer is then cached for the record's TTL (time to live), often minutes to hours.

Caching is why DNS is fast — and why changes take time to be seen everywhere: resolvers around the world keep serving the old answer until their cached copy expires. That's what "propagation" actually is.

How DNS causes downtime

  • An expired domain registration. Miss one renewal and every service under the domain disappears at once — web, mail, APIs — while the servers themselves stay perfectly healthy.
  • Bad records. A mistyped A record, an entry deleted during a migration, an IP that no longer exists.
  • Propagation surprises. After you change a record, some users reach the new address while others still get the cached old one — failures that look random and intermittent.
  • Nameserver outages. If the authoritative nameservers are down, the domain stops resolving everywhere, no matter how healthy the infrastructure behind it is.

How it surfaces in monitoring

UpAll doesn't have a dedicated DNS check type — and you don't need one for coverage. Any HTTP, Ping, or TCP monitor whose target is a hostname has to resolve that name before it can probe anything. When resolution fails, the check fails — and the recorded error says so explicitly: a "could not resolve host" style message rather than a timeout or a refused connection. Since alert emails include the last error, you'll know within minutes that the problem is the name, not the server.

Two practical consequences:

  • Monitor the hostname your clients actually use, not the IP. A monitor pointed at a raw IP bypasses DNS entirely — it will stay green through a DNS failure that has taken the site down for every real user.
  • Pair name and IP when you want fast diagnosis. Add a second monitor on the server's IP: if the hostname monitor fails while the IP monitor stays up, the problem is almost certainly DNS.

Finally, treat domain renewal dates as something to track on a calendar, not something to discover through monitoring: a check tells you quickly that the domain has lapsed, but by then the downtime has already started.