Dotcom-Monitor users 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

Device cached is the default option and 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

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 option 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

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

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 (8.8.8.8, 8.8.4.4) or Cloudflare (1.1.1.1). 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.

  • DNS Monitoring Basics

    What Does DNS Stand For?

    The domain name system is one of the fundamental technologies of the modern Internet environment since information about the IP address of the requested host is a prerequisite for receiving a response to any request on the Internet. The IP address itself is a numerical value like “100.123.145.167”, which is difficult to memorize for an average Internet user. All IP addresses over the Internet are unique numerical values. In addition to its complex structure, IP addresses of a host on the Internet is not always stable and can be changed, for example, upon changing the hosting. Thus, to make network addresses more comfortable to use for an average Internet user the Domain Name System (DNS) was introduced. Instead of using numerical IP addresses, humans use alphabetic domain names to access resources connected to the Internet (computers, web servers, other devices).

    DNS provides translation of the symbolic domain name requested by the client into the IP address of the server that serves this domain zone. DNS utilizes dedicated hosts named DNS servers to store resources’ records and process DNS requests. A DNS server can independently resolve network addresses that related to its area of responsibility, or forward requests for zones that it does not serve to DNS servers along the DNS lookup chain.

    A DNS server that is responsible to pass DNS requests from a client (e.g., browsers) to other DNS servers to satisfy the client’s DNS query is called DNS recursor or DNS Recursive Server. A DNS query usually starts with a DNS recursor. Generally, ISP’s DNS servers work as DNS recursive resolvers.

    A DNS server that stores DNS resource records and can return necessary IP addresses to clients without redirecting the request to other DNS servers is called an authoritative DNS server. Authoritative DNS servers are usually servers at the end of the DNS lookup chain.

    Besides DNS recursive resolvers and authoritative DNS servers, there are two more types of intermediate servers involved in the DNS lookup process – root nameservers that send a DNS request to a more specific location and top-level domain servers that serve the last part of a hostname (for example, .com, .uk, etc.).

    How DNS Resolution Works in Web Browsers

    Once you have typed in an URL in your browser, the browser uses your Internet service provider’s (ISP) DNS server to find the IP address of the server that hosts the requested website. The addresses of these DNS servers usually are sent by a hosting provider upon connection or must be specified manually in the IP connection parameters. In other words, when you enter a domain name, for example, google.com, into the address bar of your browser, a resolver request is generated to the local DNS servers that are installed automatically for your Internet connection, or that you have specified for your Internet connection.

    After receiving a request, the local DNS server looks in its cache for information about mapping the domain to an IP address and, if it does not find the required IP address, a request is passed to one of the currently available root DNS servers. Simply put, the local server may not have the information it needs in its cache, but it can communicate with other DNS servers.

    While the browser is waiting for a response, the local DNS server contacts the world’s main servers – the root DNS servers – and asks for an IP address for google.com. The root DNS server stores reference information only about DNS servers for domain zones. Thus, the root DNS server does not know the IP address of the requested domain but stores the IP addresses of DNS servers that are responsible for all domains in the zone of the requested domain, for google.com these are the DNS servers of the .com domain zone.

    The local DNS server receives the IP address of one of these DNS servers and tries to find a requested IP on that server. This DNS server also does not know Google’s IP address, but it knows that the reference information for google.com is hosted by the authoritative DNS servers that are registered for this domain in NS records.

    The local DNS server receives the IP address of one of these DNS servers in the .com domain and passes the DNS request to the authoritative DNS server. This authoritative DNS server stores the desired IP address and sends it to the local DNS server.

    The local DNS server receives the correct IP address and passes the IP address for the requested hostname to the browser.

    The browser gets the google.com IP address, connects to its server directly and loads the website.

    In general, the DNS lookup process is so fast that a user does not notice whether the entire DNS lookup chain was polled or not.

    DNS Errors to Monitor

    As was mentioned above, the DNS server can sequentially query other DNS servers during the execution of a recursive query and temporarily store the information contained in the responses in the cache memory. In this case, the DNS server does not need to re-request a domain’s IP address and simply can use the corresponding address that is already have been cached. The maximum allowed time of storing such information in the cache is specified in the TTL field of the resource record. DNS caching is one of the vulnerabilities that hackers use to redirect traffic to hacker websites. This type of fraud involving the spoofing of IP addresses in the cache of DNS servers is called DNS cache poisoning.

    Also, DNS server attacks such as DNS tunneling, DNS amplification attacks, DDoS attacks, or various types of hardware/network failures can lead to DNS outages and negatively affect the performance of web services.

    DNS Monitoring with Dotcom-Monitor

    If attackers have changed your DNS settings, you have to be the first person who is notified. Dotcom-Monitor provides the DNS monitoring tool that can be used as a proactive measure to defend your DNS settings. When the system detects that your hostname is resolved to another IP address than you specified or other issues occurred while executing DNS lookup, the error will be generated, and the alert notification will be sent to the specified notification addresses. So, you can react immediately to the threat before your users were driven to the phishing and malware websites.