A DNS server can be online and still cause problems. It may respond slowly, return an outdated record, serve stale zone data, or fail to resolve certain domains. A basic uptime check can miss all of these issues.
Effective DNS monitoring goes beyond checking whether a server responds. It measures how quickly queries are resolved, verifies that the returned answers are correct, checks whether DNS data is synchronized across servers, and tracks failures that could affect users and applications.
This guide covers the key DNS monitoring metrics to track, how to set practical alert thresholds, and which checks can help identify DNS problems before they turn into user-facing incidents.
Why DNS monitoring goes beyond uptime
DNS availability is only the starting point. A server can respond to test queries and still have problems that affect applications and users.
Effective DNS monitoring covers four areas:
- Availability: Is the DNS service reachable and returning valid responses?
- Performance: How long do queries take to resolve, and are response times increasing over time?
- Accuracy: Is the server returning the answer clients are expected to receive? A fast response with an outdated or incorrect IP address is still a DNS failure.
- Operational health: Are secondary zones synchronized? Are DNSSEC signatures valid? Are key rollovers progressing as expected? Are query failures or other DNS metrics changing significantly from their normal pattern?
These checks work together. A DNS server can pass an availability check while returning an incorrect answer, and a secondary server can remain reachable while serving increasingly stale zone data. Monitoring only uptime can therefore leave important DNS problems undetected.
DNS availability monitoring
Availability monitoring should cover every DNS server that clients depend on, not just the primary resolver.
This is particularly important in environments with primary and secondary authoritative DNS servers. A secondary server can remain reachable and continue answering queries even after it stops receiving zone updates. If the primary server later becomes unavailable, clients may be directed to a secondary that is still online but serving stale data.
Monitor each DNS server independently and verify more than network reachability. A useful availability check should confirm that the DNS service is accepting queries and returning a valid response.
A simple test with dig is: <pre><code>dig @10.1.1.10 example.com +time=3 +tries=1</code></pre>
Set the timeout based on your environment and the expected response time of the monitored server. It should be short enough to detect meaningful service delays rather than allowing an unusually slow response to be treated as healthy simply because the server eventually responds.
For networks with multiple sites, run availability checks from locations that reflect where clients actually connect. A resolver may be reachable from a data center but inaccessible from a branch because of a routing, firewall, or access-control issue.
What should trigger an availability alert?
Alert when a DNS server repeatedly fails to return a valid response within the expected response window. A single failed probe does not necessarily indicate a DNS outage, as transient packet loss or an issue between the monitoring system and the server can cause an isolated failure.
Use consecutive failed checks or failures detected from multiple monitoring locations to distinguish a likely DNS service issue from a temporary problem with the monitoring path.
DNS resolution latency
DNS latency is easy to overlook because users rarely see a DNS timeout directly. Instead, applications may appear slow while they wait for a hostname to resolve.
Measure the time taken to resolve representative queries and track the results over time. Average latency is useful for spotting overall trends, but it can hide occasional slow responses. p95 and p99 latency show how long the slower queries are taking and can reveal degradation that an average alone might miss.
| Metric | What it tells you | What to watch for |
|---|---|---|
| Average latency | Overall DNS response-time trend | A sustained increase from the normal baseline |
| p95 latency | Response time for the slower 5% of queries | Repeated increases during normal operating periods |
| p99 latency | Response time for the slowest 1% of queries | Large spikes or a growing long tail |
| Timeout rate | Percentage of queries that do not receive a response within the monitoring window | A sustained increase above the normal baseline |
Do not apply the same latency threshold to every DNS query. A cached lookup for an internal hostname on the same LAN as the resolver will normally be much faster than a recursive lookup that requires queries to upstream DNS servers.
For example, if an internal cached lookup normally completes in a few milliseconds but starts taking 50 or 100 milliseconds, the change is worth investigating even if the DNS server is still responding within the application's timeout period.
Look at latency as a trend rather than reacting to every individual spike. A gradual increase over several hours or days can point to growing query load, network delays, upstream DNS problems, or configuration issues before they develop into an outage.
DNS resolution accuracy
A DNS server can respond quickly and still return the wrong answer. Resolution accuracy monitoring verifies that critical DNS queries return the records clients are expected to receive.
Monitor selected hostnames against known or expected answers. This is particularly useful for critical internal services, application endpoints, load balancers, and other systems where an unexpected IP address can make a service unreachable or send traffic to the wrong destination.
For example: dig app.corp.example.com @10.1.1.10
The monitoring system can compare the returned address with the expected value and alert when it changes unexpectedly. This can help detect stale records, unintended DNS changes, and DNS data that no longer matches the current infrastructure.
Where multiple DNS servers are expected to return the same answer, query each server independently and compare the results. An unexpected difference can indicate stale zone data, an incomplete update, or a configuration problem.
Forward and reverse DNS consistency
Where forward and reverse DNS are designed to correspond, monitor both directions.
A forward lookup resolves a hostname to an IP address, while a reverse lookup uses the IP address to query its PTR record. For systems that require forward-confirmed reverse DNS, the PTR result should correspond to the expected hostname.
dig A server01.corp.example.com
dig -x 10.1.2.34
A mismatch does not necessarily indicate a DNS problem. Some environments intentionally use different names in PTR records, and not every IP address requires a corresponding reverse record. Monitor forward and reverse consistency where it is part of the expected DNS design.
For more information about DNS records and how they are managed, see our DNS record management guide.
Monitoring split-horizon DNS
Split-horizon DNS requires answer validation from the appropriate network locations. The same hostname may legitimately return a private IP address to an internal client and a public IP address to an external client.
Define the expected answer for each monitoring location rather than treating different responses as an error. If an internal resolver unexpectedly returns a public address, for example, the change could indicate a DNS configuration or availability problem and should be investigated.
For details on configuring split-horizon DNS, see our DNS configuration guide.
DNS query failure rates
Individual NXDOMAIN or SERVFAIL responses do not necessarily indicate a problem. What matters is whether their frequency changes significantly from the normal pattern.
Track DNS response codes as a percentage of total queries rather than relying only on raw counts. A resolver handling one million queries a day will naturally generate more NXDOMAIN responses than one handling ten thousand queries, even when both are operating normally.
NXDOMAIN rate
NXDOMAIN means the queried name does not exist according to the responding DNS server. A temporary increase can follow a DNS change, application deployment, expired service, or client configuration issue.
A sustained increase is more useful as a monitoring signal. Compare the current rate with the resolver's normal baseline and identify which clients, domains, or locations are contributing to the change.
Avoid treating a fixed NXDOMAIN percentage as universally abnormal. Environments with frequent short-name lookups, extensive search-domain use, or changing application workloads may have a higher normal NXDOMAIN rate than others.
SERVFAIL rate
SERVFAIL indicates that the resolver could not complete the lookup successfully. Possible causes include unreachable upstream DNS servers, DNSSEC validation problems, broken delegations, or other issues along the resolution path.
The scope of the increase can help narrow down the problem. SERVFAIL affecting a small number of domains may point to those domains or their authoritative DNS infrastructure. A broader increase across external queries is more likely to involve the recursive resolver, its forwarders, or the upstream resolution path.
What should trigger an alert?
Start with the normal failure rate for each resolver and alert when it rises significantly above that baseline and remains elevated across several consecutive monitoring intervals.
The amount of deviation should reflect the environment. For example, an increase from a 1% baseline to 5% is more significant than an increase from 15% to 19%. This makes baseline-based alerting more useful than applying the same fixed threshold to every DNS environment.
When a threshold is breached, identify the affected clients, domains, and response codes before treating it as a widespread DNS outage.
DNS zone health and synchronization
Availability monitoring cannot tell you whether authoritative DNS data is current. That requires a separate zone-health check.
In primary-secondary DNS deployments, monitor whether secondary servers are receiving current zone data. The SOA serial number provides a simple way to compare the zone version on the primary and secondary. If a secondary remains behind the primary beyond the expected refresh period, investigate the difference.
Key monitoring signals include:
- SOA serial differences between primary and secondary servers.
- Repeated AXFR or IXFR failures.
- Secondary zones remaining behind beyond the expected refresh interval.
- Unexpected differences in authoritative nameserver responses.
For commands and configuration guidance on comparing SOA serials, see our DNS configuration and validation guide.
Zone transfer failures deserve particular attention because a secondary can remain available while its copy of the zone becomes stale. If that secondary later handles queries during a primary failure, clients may receive outdated records when they need the DNS service most.
For troubleshooting zone transfers, including REFUSED responses and authorization problems, see our DNS troubleshooting guide.
DNSSEC monitoring
DNSSEC adds another dimension to DNS monitoring by requiring you to track the validity of signed data and the operational status of key rollovers.
A DNSSEC-validating resolver can reject a response when a signature has expired or when the chain of trust cannot be validated. To the user, the result may simply appear as a DNS resolution failure, often returned as SERVFAIL.
Monitor the following DNSSEC signals:
- Monitor RRSIG validity to identify signatures that are approaching or have exceeded their validity period.
- Verify DNSKEY availability and consistency to ensure that the expected signing keys are published and available.
- Check the chain of trust to confirm that the parent zone’s DS records correspond to the expected DNSKEY records in the child zone.
- Periodically validate important DNSSEC-signed zones using an external or independent resolver to confirm successful validation.
- Monitor key rollover status to ensure that planned rollovers progress correctly and each stage is completed within the expected timeframe.
Set warning periods according to the signing and rollover process used in your environment. A 30-day warning may provide useful time for operational planning, but it should complement monitoring of the actual signature validity period and the organization's documented rollover schedule.
After a DNSSEC key rollover, perform an independent validation check to confirm that the parent-zone DS records and child-zone DNSKEY data form the expected chain of trust. This helps catch incomplete or incorrect rollover changes before they cause widespread validation failures.
For DNSSEC concepts, the chain of trust, and related attack scenarios, see our DNS security guide. This section focuses on the operational signals that are useful for DNS monitoring.
DNS monitoring for security anomalies
DNS query data can reveal behavioral changes that are worth monitoring even when DNS monitoring is not being used as a dedicated security solution. Useful signals include changes in query volume, response-code distribution, source-IP activity, queried domains, record types, and query-name patterns. The focus should be on meaningful deviations from normal behavior rather than isolated events.
For example, a sudden increase in queries from a single client, an unusual concentration of NXDOMAIN responses from one source, or a new pattern of high-volume queries to an uncommon external domain may warrant investigation. These signals become more useful when compared with historical DNS behavior and correlated with endpoint or network events.
For the underlying attack techniques and their indicators, including DNS tunneling, cache poisoning, and DNS-based exfiltration, see our DNS security guide.
Also verify that client DNS traffic actually passes through the resolvers you monitor. Clients using unauthorized external DNS services or DNS over HTTPS (DoH) can create visibility gaps and make query-based monitoring incomplete. See our DNS over HTTPS guide for more information.
How to establish DNS monitoring thresholds
There is no single latency or failure-rate threshold that works for every DNS environment. A resolver serving a small office can have different traffic and response patterns from one serving a large data center or a global branch network.
Start by measuring normal DNS behavior before turning every metric into an alert.
Measure normal DNS behavior first
Run resolution latency checks, track response codes, and record timeout rates during normal operating periods. Include both typical and busy periods so the baseline reflects the range of conditions the resolver normally handles. For relatively stable environments, one to two weeks of data can provide a useful starting point.
Use percentiles for latency, not averages
Record p50, p95, and p99 latency. The average can hide occasional slow queries, while percentiles show how the slower portion of queries is behaving.
The p95 value is particularly useful for detecting performance changes that may not have a noticeable effect on the average. Set an initial degraded-performance threshold above the normal p95 and adjust it based on observed behavior during busy periods and known traffic changes.
Set failure-rate alerts relative to the baseline
Track normal NXDOMAIN, SERVFAIL, REFUSED, and timeout rates for each resolver. Alert when a metric remains meaningfully above its normal range rather than reacting to isolated responses or applying the same fixed percentage everywhere.
A deviation that persists across several consecutive monitoring intervals is generally more useful as an alert signal than a short-lived spike.
Separate warning and critical severity
Use a warning when a metric moves outside its normal range and warrants investigation. Reserve critical alerts for conditions with a credible risk of service impact, such as repeated resolver failures, widespread SERVFAIL responses, or a secondary zone remaining stale beyond its expected refresh interval.
Revisit thresholds after infrastructure changes
DNS traffic and response patterns can change when applications move to the cloud, new branches are added, namespaces are redesigned, or the resolver architecture changes. Recalibrate thresholds after significant infrastructure changes rather than assuming the previous baseline still applies.
The goal is not to alert on every unusual DNS event. Effective thresholding identifies changes significant enough to require action while allowing normal variation to pass without generating noise.
DNS monitoring with ManageEngine OpUtils
ManageEngine OpUtils provides DNS monitoring within its IP Address Manager capabilities, bringing DNS information together with IP address and DHCP data in a centralized console. This helps network teams investigate DNS-related issues alongside the underlying network information.
OpUtils can identify DNS forward and reverse lookup failures and provide visibility into DNS names associated with IP addresses. This helps administrators investigate situations where DNS information does not match the current state of the network, such as stale or inconsistent DNS records.
By combining DNS information with IPAM and DHCP data, OpUtils gives administrators more context when investigating IP address changes and DNS-related issues instead of requiring them to compare separate systems. OpUtils also supports Microsoft DNS management, allowing administrators to edit and delete DNS records directly from the platform.
For cloud DNS environments, OpUtils supports AWS Route 53 zone and record management, including zone discovery, zone creation and deletion, record creation, editing and deletion, and routing-policy support.
For organizations implementing a broader DDI workflow, bringing DNS, DHCP, and IP address information together in OpUtils can simplify day-to-day administration and provide additional context when troubleshooting network and addressing issues.
Download a free 30-day trial or schedule a personalized demo to explore DNS monitoring and management capabilities in OpUtils.
FAQs on DNS server monitoring
What is DNS monitoring?
DNS monitoring is the ongoing monitoring of DNS infrastructure to determine whether it is available, responsive, accurate, and operating as expected. Depending on the environment, it can include resolver availability, lookup latency, answer validation, response-code rates, zone synchronization, DNSSEC validation, and selected DNS activity patterns.