DNS Monitoring provides an overview of DNS server performance to help you identify server-side and client-side DNS issues. By collecting and displaying flow-level DNS metrics, this page can be used to identify:
- The pods or services making DNS requests and the servers receiving those requests.
- The endpoints making the most requests or making requests at the highest rate.
- If a DNS server’s response time to requests has gradually or suddenly increased.
- The DNS servers with a high error rate and the type of errors being emitted.
Before you can begin to use DNS Monitoring, set up Network Performance Monitoring. Also ensure you are using the latest version of the Agent, or at least Agent v7.23+ for Linux OS, and v7.28+ for Windows Server. Once installed, a ‘DNS’ tab is accessible in the Network Performance Monitoring product.
If you are using Kubernetes on Helm, to enable DNS monitoring, you need to set
true in the values.yaml.
Are you looking for Network Device Monitoring instead? See the NPM setup instructions.
Use the source and destination search bars at the top of the page to query for dependencies between a client (source), which makes the DNS request, and a DNS server (destination), which responds to the DNS request. The destination port is automatically scoped to DNS port 53 so that all resulting dependencies match this (client → DNS server) format.
To refine your search to a particular client, aggregate and filter DNS traffic using tags in the source search bar. In the default view, the source is aggregated by the
service tag. Accordingly, each row in the table represents a service that is making DNS requests to some DNS server.
To refine your search to a particular DNS server, filter the destination search bar using tags. To configure your destination display, select one of the following options from the Group by dropdown menu:
dns_server: The server receiving DNS requests. This tag has the same value as
task_name. If those tags are not available,
host_name is used.
host: The host name of the DNS server.
service: The service running on the DNS server.
IP: The IP of the DNS server.
This example shows all flows from pods in the production environment’s availability zone to hosts receiving DNS requests:
Your DNS metrics are displayed through the graphs and the associated table.
Note: The default collection interval is five minutes and retention is seven days.
The following DNS metrics are available:
|DNS requests||The number of DNS requests made from the client.|
|DNS requests / second||The rate of DNS requests made by the client.|
|DNS response time||The average response time of the DNS server to a request from the client.|
|Timeouts||The number of timed out DNS requests from the client (displayed as a percentage of all DNS responses).|
|Errors||The number of requests from the client that generated DNS error codes (displayed as a percentage of all DNS responses).|
|SERVFAIL||The number of requests from the client that generated SERVFAIL (DNS server failed to respond) codes (displayed as a percentage of all DNS responses).|
|NXDOMAIN||The number of requests from the client that generated NXDOMAIN (domain name does not exist) codes (displayed as a percentage of all DNS responses).|
|OTHER||The number of requests from the client that generated error codes that are not NXDOMAIN or SERVFAIL (displayed as a percentage of all DNS responses).|
|Failures||The total number of timeouts and errors in DNS requests from the client (displayed as a percentage of all DNS responses).|
The network table breaks down the above metrics by each source and destination dependency defined by your query.
Configure the columns in your table using the Customize button at the top right of the table.
Narrow down the traffic in your view with the Filter Traffic options.
The sidepanel provides contextual telemetry to help you quickly debug DNS server dependencies. Use the Flows, Logs, Traces, and Processes tabs to determine whether a DNS server’s high number of incoming requests, response time, or failure rate is due to:
- Heavy processes consuming the resources of the underlying infrastructure
- Application errors in the code on the client side
- A high number of requests originating from a particular port or IP
Additional helpful documentation, links, and articles: