DNS Monitoring Functionality and Feature Updates
The Domain Name Server (DNS) system is one of the most important building blocks of the Internet, and yet, it is often misunderstood and taken for granted. The DNS system is like the foundation of a house mostly hidden, ignored, and not discussed.
However, like a house with foundation problems, if there are DNS problem everything on top of, or dependent on the DNS system – networks, connectivity, user experience – is impacted. Therefore, we believe the DNS process is an integral part of monitoring. Because if a DNS process fails, then most users are unable to access the online resources being consumed.
By default, Dotcom-Monitor resolves host names starting from root servers. Resolving host names from root servers ensures that a DNS chain is not broken and host names can be resolved to their proper IP address during the check. While resolving the host name from the root server provides the most comprehensive check, for some clients and under certain circumstances it can cause issues.
Monitoring issues due to resolving the host name from the root server
- Increased total time to monitor – Total time to perform the monitoring check is increased because a DNS resolution can take a couple seconds. In some instances, when a monitoring instance especially is fast (i.e. an HTTP pixel download) the DNS resolution may account for a majority of the total time to perform the monitoring. As such, the monitoring will not reflect an average user’s experience of the website, or online resource. Therefore, if a client is more interested in monitoring for a repeat visitor’s experience of a website, then monitoring DNS propagation from the root server is not appropriate.
- DNS resolution cannot be controlled, therefore DNS issues are irrelevant – In some cases, the DNS resolution process is not under a client’s control, therefore they prefer to ignore DNS issues and outages. While it is important to be aware of DNS resolution issues as it prohibits end user access to services, it is not helpful for a client is to receive monitoring alerts and reports over DNS issues they cannot control.
Controlling DNS Resolution Performance Checks
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:
1. Device Cached (default option) – When this option is set, Dotcom-Monitor will resolve a host name once-per-instance of a 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 have determined that 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. So, 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.
2. Non-cached – When this option is set, every check resolves the host name propagating from 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.
3. TTL Live – This option best mimics a real-user’s experience. Dotcom-Monitor resolves the host name once and caches it for the Time-to-Live (TTL) value on the monitoring location. TTL value may vary from a few seconds to a few weeks. TTL is controlled by the DNS server hosting the name.
It is important to note, that if the TTL Live option is set and the 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.
4. Specific DNS server – This option will query a specified DNS server to resolve a host to an IP address. 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.
Using DNS Resolution options to solve specific issues
As noted above, each DNS resolution option has pros and cons. The ability to customize the DNS resolution process allows for flexibility that best serves a specific situation and need. In general, the default option, Device Cached, is most often recommended. However, under certain circumstance other DNS resolution options may be a valuable solution for addressing specific issues.
