This is the second of two parts. Read Part 1:
Monitoring DNS is not simply a matter of checking whether a record resolves. A comprehensive approach follows four key principles:
DNS monitoring is most effective when it targets specific signals that reveal problems with record integrity, server behavior and real-world performance.
The key groups of tests:
Mapping tests verify that users are directed to an appropriate DNS server based on location. This matters because the closest healthy server usually provides the fastest response. If a user’s request is sent across a country or to another continent, latency increases and resilience decreases.
Different managed DNS providers use different methods to determine which server responds to a query. Many compare the geographic location of the querying IP address to the locations of the available servers.
Some DNS providers and public resolvers use the EDNS (Extension Mechanisms for DNS) Client Subnet extension, which includes part of the requester’s subnet in the query. This can help the provider return a geographically appropriate answer, although support for this feature varies due to privacy considerations.
The purpose of this DNS mapping test is to confirm that queries from different regions are answered by the nearest server and that this behavior is consistent. It can also reveal Anycast drift, where some regions are unexpectedly routed to distant or unhealthy POPs due to Border Gateway Protocol path changes. A fast local resolution is often expected to complete within a few tens of milliseconds on major networks.
Record-level tests verify that the data used to resolve a domain name is accurate, consistent and uncompromised. These checks help detect misconfiguration, operational drift and signs of tampering.
Delegation checks confirm that each step in the DNS hierarchy is correct. The test walks from the root to the top-level domain and then to the authoritative zone. For example, it verifies that the nameservers listed for a domain, such as example.com, match what the .com zone expects and that those servers provide correct answers. It also catches common failure modes such as mismatched NS records between parent and child zones.
Once delegation is confirmed, each nameserver should respond reliably over both UDP and TCP. A failure to answer over TCP may indicate a configuration error or a firewall blocking traffic.
It is also useful to verify that the root hints file, when applicable, contains accurate information about root server names and IP addresses. This file is usually preconfigured by providers but should not be assumed infallible.
Start of Authority records contain the serial number and timing values for a zone. Changes to these values give context to shifts in DNS behavior. Sudden differences in serial numbers across nameservers may indicate incomplete zone transfers or unintended updates. In environments where zone files rarely change, any unexpected serial change warrants investigation.
Mail exchange and service records play a central role in email delivery and service discovery. Attackers sometimes target MX records to intercept sensitive communications, so it is important to verify that these records resolve correctly and point to the intended mail or service hosts.
These checks also confirm that record priorities are correct. Misconfigured preference values may send traffic to the wrong server, including servers without proper filtering or authentication controls. For SRV records, verifying that the target hosts actually exist and have matching A/AAAA records helps catch common operational errors.
Primary and secondary nameservers must hold identical zone data. Zone transfer tests verify that secondary servers have received the most recent updates and that no transfer failures or mismatches exist. If a transfer does not complete or if servers fall out of sync, queries may fail or return inconsistent data.
DNSSEC (Domain Name System Security Extensions) provide cryptographic verification for DNS data. Monitoring ensures that DNSSEC is enabled where intended, that the necessary key and signature records are present, and that signatures have not expired. Missing or outdated DNSSEC records can cause validation failures at resolvers. It is also important to track DS records at the parent zone, as mismatched or stale DS entries are a leading cause of DNSSEC-related outages.
Performance tests measure how quickly and consistently a domain resolves and whether recent changes have propagated across global resolvers.
Propagation refers to how long it takes for a record change to reach resolvers worldwide. Until propagation is complete, some users will continue receiving old answers. Depending on TTLs and caching behavior, global propagation may take up to several days. Monitoring helps confirm when changes have fully taken effect.
Experience tests run recursive queries from multiple points along the DNS path. These tests show end-to-end resolution time and reveal patterns in resolver load, cache efficiency and upstream performance. Elevated memory usage, CPU spikes or increased QPS (queries per second) on authoritative servers can also be identified through sustained testing.
For internal zones, experience tests may highlight heavy disk activity that indicates frequent zone transfers. Experience tests can also reveal intermittent Tor root server delays, which often go unnoticed without continuous measurement.
A and AAAA records may occasionally diverge in unexpected ways. Comparing cached answers to freshly queried answers helps identify mismatches, missing IPv6 records or configurations that favor one address family. This also helps detect scenarios where content delivery networks (CDNs) return different addresses than expected based on geography or policy.
Latency can be influenced by resolver load, network capacity, cache misses, delays at the top-level domain layer or slow authoritative servers. Performance tests should measure both the latency from the user to the resolver and the latency incurred during the resolver’s lookup chain.
Packet loss and network instability between nameservers and resolvers may cause intermittent failures. Connectivity tests identify when issues are rooted in the network rather than in the DNS configuration itself. This is especially relevant for Anycast deployments, where a single unhealthy path can create regional failures while the global service appears healthy.
Teams that operate their own DNS infrastructure should monitor the health of the servers themselves. Important metrics include:
Server-level visibility helps identify when performance issues stem from hardware limits or software constraints.
Monitoring DNS is complicated by the fact that many testing tools operate within cloud provider environments. Tests run from within the same cloud region as the authoritative server or application may show near-zero latency that does not reflect the wider internet.
This effect can create misleading results, suggesting that DNS performance is better than what end users actually experience. For an accurate view, monitoring should occur from diverse, internet-connected vantage points rather than solely from cloud-hosted agents.
It is also important to separate your DNS and CDN providers. If both services are tied to the same provider, an outage in the CDN can take your DNS offline as well, making the failure far more widespread and difficult to diagnose. Keeping these layers independent reduces the chance that a single provider outage can disrupt your entire digital footprint.
DNS reliability depends on continuous measurement, distributed visibility and a clear understanding of how users experience resolution across networks. By monitoring mapping, record integrity and performance, teams can detect problems early and maintain dependable digital experiences.
A thoughtful monitoring program does not require complex tooling. It requires awareness, consistent testing and disciplined change management. Start with the essentials outlined here and expand as your services and traffic grow.
YOUTUBE.COM/THENEWSTACK
Tech moves fast, don’t miss an episode. Subscribe to our YouTube
channel to stream all our podcasts, interviews, demos, and more.
Source: thenewstack.io…
