The objective of the DNS Experience monitor is to track the performance and availability of the nameservers that a DNS recursion would traverse to get an answer for the DNS query. In other words, it mimics a recursive DNS resolver, but it is not one exactly, as its purpose is to monitor. It will go to the TLD's nameservers and then follow the authoritative nameservers and any CNAMEs until it gets the answers.
By default, the monitor does not query or count the ROOT servers. It does account for the TLDs by default, but this can be disabled by enabling Cache TLD Nameserver Queries. When this setting is enabled, the monitor will act like the TLDs were cached and their performance will not impact the measure test time (it will show as 0).
Nameserver Selection Logic
By default, the monitor will pick one of the NS records from the TLDs at random, with an equal chance of selecting each NS. This method is used by default in order to provide balanced monitoring of all nameservers in the path. This logic can be switched by enabling Favor Fastest Round-Trip Nameserver. When this setting is enabled, the monitor performs similar logic to BIND, in that it tracks the RTT of the various nameservers encountered, and then favors the fastest (lowest RTT) nameserver in most (80%) of the queries. Note that this does not completely stop the monitor from querying the slower ones. The monitor needs to continuously track the RTT of all nameservers in case another one becomes the fastest and should be preferred. This means there is always a 20% chance a given request will go to a server other than the current fastest. Logic of this type is implemented in all recursive DNS servers.
Note that our DNS monitor tracks RTT by nameserver IP using data from all tests, so the data used to determine the fastest Nameserver is not specific to each test configuration. This provides the largest pool of data for determining the fastest nameserver and ensures consistent behavior accross tests.
The DNS monitor will rely on the “glue records” or “additional records” for following the authoritative nameservers. If the monitor picks a nameserver that does not have any glue records, it will rely on its local “recursive dns server” to discover the IP of the nameserver domain – it will not try to recurse it.
By design, the monitor does not have many of the features a recursive DNS server has, like caching of answers for the specified TTL or security measures around nameserver validations and DNSSEC. (DNSSEC is supported by the DNS Direct monitor, but it does not perform DNSSEC recursion.)