> For the complete documentation index, see [llms.txt](https://docs.thousandeyes.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.thousandeyes.com/product-documentation/tests/dns-tests.md).
# 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 (such as 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](https://docs.thousandeyes.com/product-documentation/internet-and-wan-monitoring/viewing-data/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 (such as those provided by ISPs, Google, or Cloudflare).
### DNS Server Test Metrics
* **Availability**: The percentage of DNS queries that successfully return a valid response, defined as a non-error response (such as not NXDOMAIN, SERVFAIL, or timeout) containing the requested record type (such as A or 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 (such as IP addresses for A/AAAA records, mail servers for MX records) and associated metadata (such as TTL and record type).
* **Error**: Specific errors encountered during DNS queries, such as DNS response codes (such as NXDOMAIN for non-existent domains, SERVFAIL for server failures), timeouts (default 3s, configurable), or protocol errors (such as 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:
1. In the ThousandEyes platform, navigate to **Network & Synthetics > Test Settings**.
2. Click the **Add New Test** button in the upper right corner of the screen.
3. From the menu that appears, select the card titled **DNS Server**, located on the bottom right.
4. The configuration page is divided into the following sections: Basic Settings, Network and DNS Settings, and Additional Settings.
### DNS Server Test Basic Settings
| Setting | Description |
| ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Domain** | The domain name to be queried, such as google.com. No domain is entered by default. This setting also includes:
- Query Type: The DNS record type to request. Options are A, AAAA, ANY, CNAME, DNSKEY, DS, MX, NS, NSEC, PTR, RRSIG, SOA, and TXT. The default is A.
> 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. Options are IN (Internet) and CH (CHAOSnet). The default is IN.
|
| **DNS Servers** | The DNS servers that will be queried. You can manually enter server IP addresses or click **Look up servers** to automatically populate this field with the authoritative name servers for the specified domain. No DNS servers are selected by default. Manually added servers use port 53. |
| **How often the test runs** | The frequency at which the test runs. Options are 1, 2, 5, 10, 15, 30, or 60 minutes. The default is 2 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. No agents are selected by default. For help, see [Using the Agent Selector](https://docs.thousandeyes.com/product-documentation/tests/working-with-test-settings#using-the-agent-selector). |
| **Alerts** | Enable or disable alerts for this test and assign one or more alert rules. Alerts are enabled by default, and default alert rules are selected when available. The dropdown shows the number of selected rules out of the total available. |
| **Tags** | Assign test tags to this test for filtering and organization. No tags are selected by default. |
| **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.
| Setting | Description |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Test execution schedule** | Determines the timing of test rounds for all assigned agents.
- Default: All agents start the test simultaneously at each interval. This is selected by default.
- Randomized Start Time: Staggers agent start times randomly within the test interval. Use to prevent traffic bursts.
|
| **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. This option is enabled by default.
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. This option is disabled by default.
> 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. This option is enabled by default.
- 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. This option is enabled by default.
|
| **Protocol** | The transport layer protocol (TCP or ICMP) used for the accompanying network measurements (loss, latency, jitter). The default is TCP. |
| **Path trace mode** | When In session is selected, the path trace is performed within an established TCP session. This option is selected by default when the Protocol is set to TCP.
> Note: This mode is designed for environments where stateful firewalls (such as Palo Alto Networks or 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 SACK: Forces SACK-based 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. The default is **Not fixed**. Use this to simulate network load or validate Quality of Service (QoS) policies. |
| **Number of path traces** | Sets the number of path traces (1 to 10) performed in each test round. The default is 1. 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 (such as 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. This option is disabled by default. Disable this to send an iterative query, which is useful for testing authoritative servers directly. |
| **IPv6 policy** | Selects the name resolution preference for network measurements. Options are **Agent's policy**, **IPv4 only**, **Prefer IPv6**, and **Force IPv6**. The default is **Agent's policy**. This setting overrides the IPv6 policy configured at the agent level. |
### DNS Server Test Additional Settings
| Setting | Description |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Description** | An optional, user-defined description for the test. This field is blank by default. 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. No suppression windows are selected by default. 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 (such as 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](https://www.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:
```
"Dead end for " + dnsName + " " + dnsType
```
For example:
```
;; ERROR: Dead end for login.microsoftonline.com A
```
This error is returned when:
1. an answer has not been received, and
2. 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:
```
;; ERROR: Server c.root-servers.net responded with AA flag unset (non-authoritative answer) for login.microsoftonline.com A
```
### Manually Configuring DNS Trace Tests
To configure a DNS Trace test, use the following settings.
#### Basic Settings
| Setting | Description |
| ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Domain** | The domain name to be queried (for example, `google.com`). No domain is entered by default. |
| **Record type** | Specifies the type of DNS resource record (RR) to request. The default is A. Options include:
- A: Maps a domain to an IPv4 address.
- AAAA: Maps a domain to an IPv6 address.
- ANY: Requests all available record types. Note: Some modern DNS servers restrict ANY queries.
- CNAME: Creates an alias from one domain name to another.
- MX: Specifies the mail servers for a domain.
- NS: Lists the authoritative name servers for a domain.
- PTR: Maps an IP address back to a domain name (reverse DNS).
- SOA: Provides start of authority information for a DNS zone.
- TXT: Stores arbitrary text data (often used for SPF, DKIM, etc.).
- DNSSEC Types: DNSKEY, DS, NSEC, RRSIG.
|
| **Test name** | A name for the test. This auto-populates with the domain name but can be manually edited. |
| **How often test runs** | The frequency at which the test runs. The default is 2 minutes. More frequent intervals are recommended for critical services. |
| **Where test runs from** | Select one or more ThousandEyes Agents to run the test from. No agents are selected by default. Agents act as observation points to collect performance data. |
| **Alerts** | Enable or disable alerts for this test and assign one or more alert rules. Alerts are enabled by default, and default alert rules are selected when available. |
| **Tags** | Assign test tags to this test for filtering and organization. No tags are selected by default. |
#### Advanced Settings
| Setting | Description |
| --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Transport** | The transport protocol used for the DNS query.
- UDP: (Default) The standard, fast protocol for most DNS queries.
- TCP: A reliable protocol used for larger DNS responses (like with DNSSEC) or when UDP fails.
|
| **Test execution schedule** | Determines the timing of test rounds for all assigned agents.
- Default: All agents start the test simultaneously at each interval. This is selected by default.
- Randomized Start Time: Staggers agent start times randomly within the test interval. Use to prevent traffic bursts.
|
#### Additional Settings (Optional)
| Setting | Description |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| **Description** | An optional, user-defined description for the test. This field is blank by default. |
| **Alert suppression window** | Temporarily disables all alerts for this test for a defined period. No suppression windows are selected by default. |
## DNSSEC Test
[DNSSEC](https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions) 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](https://dnssec-tools.org/).
### Manually Configuring DNSSEC Tests
To configure a DNSSEC test, use the following settings.
#### Basic Settings
| Setting | Description |
| ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Domain** | The domain name to be queried (for example, `google.com`). No domain is entered by default. |
| **Record type** | Specifies the type of DNS resource record (RR) to request. The default is A. Options are A, AAAA, ANY, CNAME, DNSKEY, DS, MX, NS, NSEC, PTR, RRSIG, SOA, and TXT. DNSSEC-specific options include:
- DNSKEY: Stores the public key used for DNSSEC validation.
- DS: Links a delegated zone to its signed keys for DNSSEC.
- NSEC: Used in DNSSEC to prove that a name does not exist in a zone.
- RRSIG: Contains the digital signature for a DNS record set.
|
| **Test name** | A name for the test. This auto-populates with the domain name but can be manually edited. |
| **How often test runs** | The frequency at which the test runs. The default is 2 minutes. More frequent intervals are recommended for critical services. |
| **Where test runs from** | Select one or more ThousandEyes Agents to run the test from. No agents are selected by default. Agents act as observation points to collect performance data. |
| **Alerts** | Enable or disable alerts for this test and assign one or more alert rules. Alerts are enabled by default, and default alert rules are selected when available. |
| **Tags** | Assign test tags to this test for filtering and organization. No tags are selected by default. |
#### Test Execution Schedule
| Setting | Description |
| --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Test execution schedule** | Determines the timing of test rounds for all assigned agents.
- Default: All agents start the test simultaneously at each interval. This is selected by default.
- Randomized Start Time: Staggers agent start times randomly within the test interval. Use to prevent traffic bursts.
|
#### Additional Settings (Optional)
| Setting | Description |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| **Description** | An optional, user-defined description for the test. This field is blank by default. |
| **Alert suppression window** | Temporarily disables all alerts for this test for a defined period. No suppression windows are selected by default. |
## 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.