Users of Dotcom-Monitor have extensive control over how a DNS resolution is performed for their monitoring tasks. Based on extensive user feedback, four different DNS options for resolving host names are available for monitoring tasks.

Device Cached (DEFAULT OPTION) means the cached name server (NS) address retrieved during monitoring of a previous task (device cache) will initially be used for monitoring. If the device cache does not have the needed address, then an automatic inquiry for the address from root DNS servers will be conducted. When this option is set, Dotcom-Monitor will resolve a host name once-per-instance of a device check. So, if there are references to the same host name in one or more tasks within the same device, then the DNS lookup will occur once and then be cached for the duration of the check-in that device. Most checks are fairly quick and performed in under one minute, so there is no reason to resolve the same host every few seconds. The downside of this option is that performance data can vary per task in the same device. If you monitor two URLs in the same device that are on the same host, the first URL always will be slower, because it will include the DNS lookup time, while the second URL will use the cached DNS IP address and DNS resolution will be very fast.

This type of cache is common for only tasks with an identical DNS Resolve Mode.

Non-Cached means the device cache (cache of preceding tasks) will not be used, so each new execution demands a separate inquiry to DNS root servers.
This is useful for ensuring uniform times since the DNS lookup will be performed each time. However, the non-cache option can significantly increase the load on DNS servers and also increases the response time for monitoring tasks. This option is not available for the browser-based BrowserView or UserView monitoring platforms since it is not practical to resolve same the host name hundreds of times within a few seconds of the check. For example, think of a web page that has many elements on the same server all having separate DNS resolutions from the root server. In that type of scenario, resolving once per check is sufficient.

TTL Cached means NS cache formed during monitoring of preceding tasks (device cache) will initially be used for monitoring. If the device cache does not have the needed address, then an automatic inquiry for the address will be conducted from the local DNS server. 

This option best mimics a real-user’s experience.

It is important to note, that if the TTL option is set and the specified DNS server fails, then Dotcom-Monitor might not detect the failure until the TTL expires (which can take days or weeks). This option is recommended only if monitoring for a proper DNS resolution is not a priority.

This type of cache is common for only tasks with an identical DNS Resolve Mode.

External DNS Server means a specified IP address will be considered as a DNS server address and polled for NS data.

This is useful in specific situations, for example, if you know most of your clients use a public caching service, such as Google’s 8.8.8.8, or 8.8.4.4 In this case, you can set the DNS Server to one of Google’s IPs. As long as the specified Google DNS provides a valid response Dotcom-Monitor will not detect a DNS error, even if a DNS server responsible for the domain does not work properly.

Another situation involves if you know the servers responsible for name resolution and do not care about the whole DNS chain resolution. In this case, you can specify the DNS server to use for DNS resolution. This option can provide better DNS resolve times as well since Dotcom-Monitor does not have to propagate a lookup from the root server and can go directly to the proper DNS server. However, this option might not detect all DNS-related problems.

Each separate address creates a different cache. So, for example, if two tasks under one device have different external DNS (different IPs), then there will be two different caches.