![\"DNS](\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2026\/07\/how-dotcom-monitor-resolves-dns.webp\")
<\/p>\n<\/p>\n
Every monitoring check starts the same way. Before a single byte of your homepage, API response, or SMTP banner comes back, the monitoring agent has to turn a hostname into an IP address. That first step is DNS resolution, and how you configure it changes what your uptime numbers actually mean.<\/p>\n
Most teams never touch the DNS setting on a monitor. They point a check at Dotcom-Monitor gives you four DNS resolve modes for exactly this reason. This guide walks through each one, with the sharpest focus on the choice most people get wrong: caching versus non-caching versus temporary (TTL-based) caching.<\/p>\n DNS is the first hop of nearly every protocol you monitor. A website check, an API monitoring<\/a> call, an email server monitoring<\/a> probe, an ICMP ping monitoring<\/a> test\u2014each one needs an IP address before it can open a connection. So the agent resolves the hostname first, then runs TCP, TLS, and the application-layer request on top of that.<\/p>\n That ordering matters for two reasons. First, DNS lookup time is part of your total response time, so a slow resolver inflates every number downstream. And second, a DNS failure stops the check before it starts. If resolution fails, there is no connection to test, no certificate to validate, no status code to read. The monitor reports a hard failure, and the root cause is one layer below the thing you thought you were watching.<\/p>\n Because DNS sits in front of everything, the way an agent handles that lookup is a real design decision, not a detail. Resolve it fresh on every request and you catch resolver problems fast, but you add load and lookup time to each run. Cache it and your numbers get faster and steadier, but a broken DNS record can hide behind the cache for hours. Dotcom-Monitor’s modes exist to let you pick which tradeoff fits the thing you are actually monitoring. For a deeper look at trimming that first hop, see our guide to improving DNS resolution time<\/a>.<\/p>\n Dotcom-Monitor exposes four DNS resolve modes on a monitoring task. Each one changes where the IP address comes from and how long it sticks around.<\/p>\n Device Cached is the default. Within a single device check, the agent resolves each hostname once and shares that answer across every task in that device for the rest of the run. If a task earlier in the same check already resolved the host, the later task reuses the cached IP. If not, the agent runs a full lookup and caches the result for the duration of the check.<\/p>\n The upside is efficiency. Most checks finish in under a minute, so there is no reason to resolve the same host every few seconds. The catch shows up in per-task timing. If one device monitors two URLs on the same host, the first URL carries the DNS lookup time and the second uses the cached IP, so the second looks faster even though nothing about it is. That is expected behavior, not a bug, but it surprises people reading a waterfall for the first time.<\/p>\n Non-Cached skips the device cache entirely. Every task execution runs its own full DNS lookup, so no run borrows a previous run’s answer. That gives you uniform, comparable timing because every check pays the same full resolution cost.<\/p>\n The tradeoff is load and latency. A fresh lookup on every run adds time to each task and puts more traffic on DNS infrastructure. Non-Cached also is not available for the browser-based BrowserView or UserView platforms. A real page can pull dozens of elements from the same host, and resolving that hostname hundreds of times inside a few seconds is not how a browser works, so resolving once per run is the realistic model there.<\/p>\n TTL Cached behaves like a real resolver on a user’s machine. It honors the record’s time-to-live: the agent caches the resolved address and keeps using it until the TTL expires, then re-resolves through the local DNS server. This is the mode that most closely mimics what an actual visitor experiences, because their browser and OS cache the same way.<\/p>\n The risk lives in that same behavior. If the DNS server backing the record fails while a valid answer is still cached, the monitor may not notice until the TTL runs out, and TTL can be set to hours, days, or longer. So TTL Cached is the right call when you want realistic user-experience timing, and the wrong call when catching a DNS failure quickly is the whole point of the check.<\/p>\n External DNS Server points the lookup at a specific resolver IP that you choose. If you know most of your users sit behind a public resolver like Google (8.8.8.8, 8.8.4.4) or Cloudflare (1.1.1.1), you can test resolution through that exact service. You can also aim at a resolver you know is authoritative for the zone to skip the recursive walk and get faster, more direct lookups.<\/p>\n The limit is coverage. As long as your chosen resolver returns a valid answer, the monitor sees success, even if the DNS server actually responsible for the domain is misbehaving. So this mode tests one resolver’s view of the world, not the whole chain. One more detail worth knowing: each distinct resolver IP gets its own cache, so two tasks pointed at different external servers keep separate caches.<\/p>\n This is the decision that trips people up, so it is worth putting the three side by side. Caching (Device Cached) optimizes for efficiency. Non-caching (Non-Cached) optimizes for comparable, repeatable timing and fast failure detection. Temporary caching (TTL Cached) optimizes for realism by aging out records the way a browser does.<\/p>\napi.example.com<\/code>, pick an interval, and move on. But the resolver behavior underneath that check decides whether you are measuring a real user’s experience, catching DNS failures within seconds, or producing clean response times you can compare across runs. You cannot optimize for all three at once.<\/p>\nWhy DNS Resolution Runs First in Every Check<\/h2>\n
![\"A](\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2026\/07\/dns-check-lifecycle.webp\")
The Four DNS Modes in Dotcom-Monitor<\/h2>\n
Device Cached<\/h3>\n
Non-Cached<\/h3>\n
TTL Cached<\/h3>\n
External DNS Server<\/h3>\n
Caching vs Non-Caching vs Temporary Caching<\/h2>\n
\n