DNS (Domain Name System) is a foundational component of internet infrastructure, translating human-readable domain names (like "example.com") into IP addresses that machines use to communicate. The DNS Test is designed to monitor and validate the performance, availability, and resolution accuracy of DNS name servers and records.
Catchpoint allows you to specify a particular name server to monitor (Direct), or it can emulate a recursive DNS resolver that does not cache records, returning results from whichever server is resolved (Experience). This is referred to as "experience" testing because it reflects the actual experience of users accessing the system.
DNS Test Use Cases
- DNS Resolution Performance Monitoring: Measure response times from authoritative and recursive DNS servers to detect latency issues affecting user experience.
- DNS Server Availability: Continuously verify the uptime and responsiveness of primary and secondary DNS servers to ensure high availability.
- Record Accuracy Validation: Ensure DNS records (A, AAAA, CNAME, MX, TXT, etc.) resolve correctly and reflect the intended configuration across global resolvers.
- Propagation Tracking: Monitor how quickly DNS changes propagate across different regions and ISPs, helping validate TTL settings and update effectiveness.
- Geo-DNS Behavior Analysis: See how DNS responses vary by geographic location to validate CDN configurations, load balancing, and regional routing policies.
- Redirection and CNAME Chain Testing: Detect excessive or broken CNAME chains that may impact resolution speed or reliability.
- Reliable DNS Transport Testing: Use TCP instead of UDP to test DNS resolution over a reliable connection, ensuring compatibility with firewalls, large responses, and DNS-over-TCP configurations.
- Nameserver Identity Resolution: Choose between BIND.HOSTNAME or NSID methods to retrieve nameserver identity information for enhanced visibility and diagnostics during DNS testing.
DNS Test Results
In this example, the Records page for a DNS test run shows a timeout error.
DNS Test Configuration
Below are the various test settings and metrics supported by DNS test.
DNS Test Properties | |
|---|---|
| Name | A name used to identify this test. |
| Description | Optional additional information about the test |
| Monitor | Experience: The test emulates a recursive DNS Resolver with cache disabled. Measures the time it takes to resolve a domain, reflecting real user experience |
| Direct: You specify which name server this test will monitor. | |
| Test Domain | The domain you are testing (e.g. www.domain.com) You can also use Macros to add variables to the domain. See Macros for more information. |
| DNS Server | The IP address or hostname of the name server you want to monitor. (Only displayed when Monitor is set to "Direct.") |
| Query Type | The exact DNS query this test will perform. |
| Location | The Product or Folder containing this test (read only). |
| Status | Determines whether this test is currently Active or Inactive |
DNS Test Advanced Settings | |
|---|---|
| Cache TLD Nameserver Queries | Directs DNS to Cache requests made to Top-Level Domain (TLD) servers for the discovery of Authoritative Name Servers. The monitor will store the list of NS records provided by the TLDs, but it will not show any impact from the TLDs. |
| Debug Primary Host on Failure | Runs Ping, Traceroute, and DNS traversal to the primary host on test failure. |
| DNS Recursive Resolution Disabled | With a recursive name query, the DNS client requires that the DNS server responds to the client with either the requested resource record or an error message stating that the record or domain name does not exist. If enabled, the DNS server cannot refer the DNS client to a different DNS server. Useful for monitoring performance of specific servers. |
| EDNS Subnet | Allows you to specify an IP subnet to include in the query to the server. The server uses this information to resolve to an IP address that is near the IP subnet. |
| Enable TCP for DNS Test Type protocol | DNS tests use UDP by default. This setting allows you to use TCP instead. |
| Favor Fastest Round-Trip Nameserver | Tells the agent to use the nameserver with the lowest RTT 80% of the time. |
| Nameserver Hostname lookup Mechanism | Allows you to specify BIND.HOSTNAME or NSID. |
| Try Next Nameserver on Failure | If enabled, when a DNS query fails the test retries the query on the next server.
By default, the Catchpoint DNS agent fails the test if a NS server query fails. The reason for this behavior is to catch and notify you of any problems in your DNS infrastructure.
However, this is not the default behavior for recursive DNS resolvers used by end-users. By default, when a DNS query fails they retry the query on the next NS server.
This setting tells the agent to behave the same way, and query the next server.
Please note that this feature will delay the detection of a problem on a NS server.
Note
When this setting is enabled in the DNS Experience test, the Catchpoint Agent retries Maximum 3 times 3 different NS for 1.5seconds each on the same level. Exception
We do not move to the next nameserver when you get a hard failure such as ServerFail- Server failure in your DNS experience test. We move to the next nameserver only when Nameservers timeouts. |
| Enable MTU Path Discovery | Enables collection of Traceroute Path MTU data. Only works with DNS test if additional monitor is enabled to run traceroute. |
| Additional Monitor | Runs an additional Traceroute from the same node to the destination.The supported additional monitors are:
|
Supported Metrics | |
|---|---|
| # A | The number of DNS requests to A servers |
| # AAAA | The number of DNS requests to AAAA servers |
| # CNAME | The number of DNS requests to CNAME servers |
| # NS | The number of DNS requests to nameservers |
| # Purged Runs | The number of test runs manually excluded from calculation for purposes of SLA accuracy. |
| # Runs | Total number of test runs for the defined time period. |
| # Test Errors | The total number of test runs that failed. This is the sum of all of the following types of test failures:
|
| # Test Failures | The total number of elements that Catchpoint was unable to connect to, receive a response from, or load on the page. |
| % Adjusted Availability | Ignoring any purged runs, the percentage of test runs where the primary URL server was reached and the test was completed (i.e. there was not a Test Error.) |
| % Availability | The percentage of test runs where the primary URL server was reached and the test was completed (i.e. there was not a Test Error.) Availability is calculated as: (# Test Runs - # Test Errors) / # Test Runs |
| % Downtime | The percentage of test runs where the primary URL server was unavailable, unreachable, or otherwise failed (i.e. there was a Test Error.) Downtime is calculated as: # Test Errors / # Test Runs |
| % Frustrated | The percentage of test runs that exceeded the Apdex “frustrated” threshold. |
| % Not Frustrated | The percentage of test runs that completed in less time than the Apdex “frustrated” threshold. This is equivalent to: % Satisfied + % Tolerating |
| % Ping Packet Loss | The percentage of pings packets sent which did not receive a response. Calculated as: (# packets received / # packets sent) * 100 |
| % Satisfied | The percentage of test runs that completed in less time than the Apdex “Satisfied” threshold. |
| % Tolerating | The percentage of test runs that exceeded the Apdex “Satisfied” threshold but completed in less time than the “Frustrated” threshold. |
| Apdex | A scoring mechanism that translates performance metrics of diverse applications into generic “User Satisfaction” levels using predefined response time thresholds. You can use default Apdex thresholds or configure your own on a per basis. For more details about Apdex, visit http://www.apdex.org/ |
| Experience Score | A composite metric that captures the overall experience of a user on a scale of 0-100. |
| Ping Round Trip (ms) | Average time between sending a ping packet and receiving a response. |
| Response (ms) | The total time from the initial request until receiving the last packet of response data. It is the sum of DNS + Connect + ssl + Send + Wait + Load for all elements. |
| Signal Quality | Measures the quality of the WLAN connection in terms of data transfer speed. It indicates what percent of the available network are you using to move data (upload / download). 99% is as good as it gets in terms of signal quality. |
| Signal Strength (dBm) | This number represents the power the clients device is receiving from the Access Point / Wi-Fi router. A number of -30 dBm indicates excellent while a number of -70dBm indicates very poor signal strength. |
| Test Time (ms) | One cohesive metric that applies to all test types and indicates the total duration of the test run. Test Time is equivalent to Response, Test Response (Transaction and web tests) and ping RTT (Trace Route tests), and is used when calculating Apdex. Test Time is not available for Request, Host, or Zone charting. |