DNS Tests
ThousandEyes DNS Tests are designed to monitor and troubleshoot Domain Name System (DNS) performance, availability, and security. These tests help organizations ensure reliable DNS resolution, critical for online services, by evaluating DNS servers, tracing query paths, and validating DNS Security Extensions (DNSSEC). ThousandEyes offers three DNS test types: DNS Server, DNS Trace, and DNSSEC, each targeting specific aspects of DNS infrastructure.
DNS Server Test
DNS Server tests evaluate the performance and reliability of specific DNS servers (authoritative or recursive) by querying them for a target domain and record type (e.g., A, AAAA, MX). Upon selecting a specific domain and the servers to be queried, agents will run DNS and network layer performance metrics for all targeted servers. For more information on viewing DNS Server test results, see Using the DNS Server View.
Use Cases for DNS Server Tests
Assess the responsiveness and reliability of authoritative or recursive DNS servers to ensure fast resolution for users.
Verify that DNS servers return correct records to prevent misrouting or outages.
Evaluate DNS server performance across regions to optimize user experience or validate GeoDNS/Global Server Load Balancing (GSLB).
Identify cache poisoning attacks where recursive resolvers return forged records.
Diagnose issues with recursive resolvers (e.g., provided by ISPs, Google, Cloudflare).
DNS Server Test Metrics
Availability: The percentage of DNS queries that successfully return a valid response, defined as a non-error response (e.g., not NXDOMAIN, SERVFAIL, or timeout) containing the requested record type (e.g., A, MX). Plottable on the timeline.
Resolution Time: The time taken to resolve a DNS query, measured in milliseconds, from sending the query to receiving a valid response. Plottable on the timeline.
Response: The DNS response data returned by the server, including the resolved records (e.g., IP addresses for A/AAAA records, mail servers for MX records) and associated metadata (e.g., TTL, record type).
Error: Specific errors encountered during DNS queries, such as DNS response codes (e.g., NXDOMAIN for non-existent domains, SERVFAIL for server failures), timeouts (default 3s, configurable), or protocol errors (e.g., malformed responses).
DNS Server Test Views
Timeline (DNS Server Layer)
Map
Table
This example depicts a DNS Server test for thousandeyes.com:
Other Included Tests
BGP test
Agent-to-server test
Manually Configuring DNS Server Tests
To configure a DNS Server test:
In the ThousandEyes platform, navigate to Network & Synthetics > Test Settings.
Click the + button in the upper right corner of the screen.
Under the DNS Tests section, select the card titled DNS Server Performance and Availability.
The configuration page is divided into the following sections: Basic Settings, Network and DNS Settings, and Additional Settings.
DNS Server Test Basic Settings
Domain
The domain name to be queried, such as google.com. This setting also includes:
Query Type: The DNS record type to request, such as A, AAAA, CNAME, MX, PTR. > Note: For PTR records, the IP address must be in the reverse DNS format (
171.106.181.72.in-addr.arpa). Only /32 PTR lookups are supported.Query Class: The record class for the query. Typically IN (Internet).
DNS Servers
The DNS servers that will be queried. You can manually enter server IP addresses or click Lookup Servers to automatically populate this field with the authoritative name servers for the specified domain.
How often the test runs
The frequency at which the test runs. Options are 1, 2, 5, 10, 15, 30, or 60 minutes. More frequent intervals are recommended for critical DNS infrastructure.
Where the test runs from
Select one or more ThousandEyes Cloud or Enterprise Agents to run the test from. For help, see Using the Agent Selector.
Alerts
Enable or disable alerts for this test and assign one or more alert rules. The dropdown shows the number of selected rules out of the total available.
Labels
Assign agent labels to this test for filtering and organization. The dropdown shows the number of selected labels out of the available.
Test Name
A name for the test. The name auto-populates from the domain being queried but can be manually edited. The maximum length is 255 characters.
DNS Server Test Network and DNS Settings
By default, a DNS Server test focuses on DNS resolution metrics like availability and resolution time. To gain deeper insight and correlate DNS performance with the underlying network path, you can enable network measurements.
Perform Network Measurements
When this toggle is enabled, the test will run a concurrent agent-to-server network test to each DNS server specified in the test. This captures essential network-layer metrics like packet loss, latency, and jitter, and allows you to visualize the network path and BGP routing data to the server. Enabling this option is highly recommended for comprehensive root cause analysis, as it helps you determine if slow DNS resolutions or query failures are caused by issues with the DNS server itself or by problems on the network path.
Define which data to collect
Select the types of network data to collect during the test.
Bandwidth: Measures available network bandwidth by sending a series of packet streams ("packet trains") to the server. The test is iterative: it starts with a small stream (100 packets) and may increase in size (up to 2000 packets) until a stable throughput measurement is calculated based on packet delay analysis. > Note: This option does not increase test unit consumption but does generate additional traffic, which may impact performance on resource-constrained networks. It is recommended to keep this option disabled for tests using agents on routers or switches.
Maximum Transmission Unit (MTU): Determines the Maximum Transmission Unit (MTU) size along the network path to identify issues related to packet fragmentation.
Collect BGP data: Correlates network data with BGP routing data. Tests with IPv4 targets use IPv4 BGP monitors, and tests with IPv6 targets use IPv6 BGP monitors.
Protocol
The transport layer protocol (TCP or ICMP) used for the accompanying network measurements (loss, latency, jitter).
Path trace mode
When In Session is selected, the path trace is performed within an established TCP session. > Note: This mode is designed for environments where stateful firewalls (e.g., Palo Alto Networks, Juniper SRX) might otherwise block standard path trace packets.
Probing mode
Defines the TCP probing method used for network measurements. This setting is available only when the Protocol is set to TCP.
Prefer SACK: (Default) Uses a single TCP connection with Selective Acknowledgement (SACK) for efficient, low-overhead measurements.
Force SYN: Sends a stream of up to 50 SYN packets from unique source ports. Use this method if SACK is not supported or is blocked in the network path.
Transmission rate
Controls the rate at which packets are sent for network measurements. Use this to simulate network load or validate Quality of Service (QoS) policies.
Number of path traces
Sets the number of path traces (3 to 10) performed in each test round. Increasing the number helps discover and visualize multiple or asymmetric network paths.
Transport
The transport protocol used to send the DNS query.
UDP: (Default) The standard protocol for most DNS queries. It is fast and connectionless.
TCP: Used for DNS queries that require a reliable connection, such as those expecting large responses (e.g., with DNSSEC) or for zone transfers.
Send recursive queries
When enabled, sets the Recursion Desired (RD) flag in the DNS query. This instructs the target server to perform a full recursive lookup, mimicking how a client resolver (like an ISP's DNS) would resolve a domain. Disable this to send an iterative query, which is useful for testing authoritative servers directly.
DNS Server Test Additional Settings
Description
An optional, user-defined description for the test. Use this field to add context, change history, or other notes for fellow users.
Alert suppression window
Temporarily disables all alerts for this test for a defined period. Use this feature for planned maintenance windows to prevent false-positive alerts.
DNS Trace Test
Large DNS zones are divided into various smaller child zones with each child zone having dedicated authoritative DNS servers. When a DNS request is made the parent zone will refer the request to authoritative DNS server in the child zone. In this scenario ensuring DNS requests are correctly pointed to authoritative servers by a parent server and also the authoritative server being correctly configured to assert authority becomes crucial. The DNS Trace test helps validate this critical delegation. A DNS Trace test will verify delegations from each parent zone to child zone.
Use Cases for DNS Trace Tests
Verify the delegation of DNS records are being performed between parent and child zones as expected.
Observe the DNS hierarchy of a target domain from various vantage points.
DNS Trace Test Metrics
Here are the key metrics available for DNS Trace tests:
Availability: The percentage of DNS traces that successfully resolve the target domain. A successful trace is one that receives a valid, non-error response (e.g., not NXDOMAIN or SERVFAIL) from the final authoritative name server. Plottable on the timeline.
Final Query Time (ms): The round-trip time, in milliseconds, for the final query in the trace that successfully resolves the target domain. This measures the responsiveness of the authoritative name server. Plottable on the timeline.
Status (includes Trace): A summary of the test outcome, indicating whether the domain was successfully resolved. This field also provides access to the detailed, step-by-step trace showing the full resolution path from the initial resolver to the authoritative name server.
Mappings: The resulting records returned by the final, successful DNS query. For an A record query, this will be the resolved IP address(es). For an MX record query, it will be the mail server hostnames.
Failed Queries: The total number of individual DNS queries within the trace that resulted in an error, such as a timeout or a SERVFAIL response.
Total Queries: The total number of individual DNS queries sent during the entire resolution process, including both successful and failed queries.
Final Server Queried: The IP address and name (if available) of the final DNS server that was queried in the resolution path. For a successful trace, this is typically the authoritative name server that provided the final answer.
Example DNS Trace Test Results
Below is the test validating a record for thousandeyes.com.
Non-Authoritative Nameservers in DNS Trace Tests
During a DNS trace test, it is possible that a non-authoritative answer is received from a server in the path. The explanation below provides further details on what is happening and why.
Normally, a failed DNS Trace test terminates with the following error:
For example:
This error is returned when:
an answer has not been received, and
no further referral data exists.
To successfully terminate a trace requires that the Answer section has one or more non-CNAME records, and the Authoritative Answer (AA) flag in the DNS header is set. Normally, when we have an answer, the answer comes from an authoritative nameserver which will set the AA flag. So, what happens when an answer is received, but it’s from an unconfirmed source?
We have observed that the Answer section can be populated by non-authoritative nameservers (spoofed or otherwise) without AA being set. In that situation, a different error message is returned. Whenever there is a non-zero Answer section that does not contain either a CNAME, or a record matching the type of the target record, you’ll see an error message similar to the following example:
DNSSEC Test
DNSSEC tests verify the digital signature of DNS resource records and hence validate the authenticity of resource records according to Domain Name System Security Extensions. A DNSSEC test adds security validation to a DNS trace test and complements it.
Use Cases for DNSSEC Tests
Verify valid DNS signatures are being sent out along with DNS records.
Validate DNS records based in DNSSEC.
Observe the DNSSEC Trust Chain and Data Chain.
DNSSEC Test Metrics
Validity indicates whether the DNS response has been successfully authenticated using the DNS Security Extensions (DNSSEC) protocol. This involves a cryptographic verification process where the agent checks the digital signatures associated with the DNS records and validates them against a chain of trust leading back to the root zone. The primary goal is to ensure the authenticity and integrity of the DNS data, protecting users from forged DNS responses and attacks like cache poisoning.
DNSSEC Validity status can have one of the following values:
Valid: The DNS record has a valid digital signature, and the chain of trust is intact. The response is authentic and can be trusted.
Invalid (or Bogus): The signature is incorrect, the cryptographic keys are mismatched, or the chain of trust is broken. This indicates a potential security issue or a significant DNSSEC misconfiguration.
Insecure: The domain (or a parent domain in the delegation path) does not support DNSSEC. The response is not protected by digital signatures, but this is the expected state for domains that have not implemented the protocol. It is not an error, but rather an indication that the domain's authenticity cannot be cryptographically verified.
Example DNSSEC Test Results
Below is a sample DNSSEC test to A record for dnssec-tools.org.
Manually Configuring DNS Tests
Note: The user interface for Test Settings is being updated. The information on this page may not reflect the new experience. The documentation will be updated shortly to align with these improvements.
Test Type: DNS trace or DNSSEC.
Test Name: This optional parameter gives the test a human-readable label. When no test name is provided in this field, the value in the Domain field is used as the test name. A test name cannot exceed 255 characters.
Domain: Three fields.
Domain name, entered in the format
google.com. Do not enter a full URL, just the domain name itself.
Interval: How frequently this test will be run.
Agents: This drop-down lists the ThousandEyes Cloud Agents and (optionally) Enterprise Agents agents that are available to your account. Select one or more agents to assign them to this test.
Alerts: When the Enable box is checked, the alert rules selected in drop-down list will be active for the test. You can select alert rules with the drop-down list, and create, modify and delete alert rules with the Edit Alert Rules link.
DNS Test Outputs
DNS Domain Trace and DNSSEC tests return a map of locations showing availability by location for the DNS record requested, returning the average query time.
DNS server tests query the authoritative nameservers from each location, showing availability and resolution time by location. In addition to these metrics, network measurements can be enabled on DNS server tests, which provides access to network measurement details (and outputs) against each authoritative nameserver specified in the test.
Last updated