DNS Monitoring
Incident Management is now generally available! Incident Management is now generally available!

DNS Monitoring

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.

DNS Monitoring is currently in public beta.

Setup

DNS Monitoring metrics are collected automatically by the system probe with agent v7.23+. Once installed, a ‘DNS’ tab is accessible in the Network Performance Monitoring product by default - no extra steps are necessary.

Queries

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 pod_name or 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:

Metrics

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:

MetricDescription
DNS requestsThe number of DNS requests made from the client.
DNS requests / secondThe rate of DNS requests made by the client.
DNS response timeThe average response time of the DNS server to a request from the client.
TimeoutsThe number of timed out DNS requests from the client (displayed as a percentage of all DNS responses).
ErrorsThe number of requests from the client that generated DNS error codes (displayed as a percentage of all DNS responses).
SERVFAILThe number of requests from the client that generated SERVFAIL (DNS server failed to respond) codes (displayed as a percentage of all DNS responses).
NXDOMAINThe number of requests from the client that generated NXDOMAIN (domain name does not exist) codes (displayed as a percentage of all DNS responses).
OTHERThe number of requests from the client that generated error codes that are not NXDOMAIN or SERVFAIL (displayed as a percentage of all DNS responses).
FailuresThe total number of timeouts and errors in DNS requests from the client (displayed as a percentage of all DNS responses).

Table

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.

Sidepanel

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

Further Reading