Technical guide

DNS monitoring and split-DNS troubleshooting for Linux servers

Intermittent DNS failures can make a healthy server appear broken. Effective troubleshooting requires repeated observations, direct resolver queries, transport comparison, and knowledge of which IP address each hostname is actually expected to return.

DNS failure can look like server failure

When a website becomes unreachable, DNS is only one possible cause. The same symptom can come from routing, TLS, Nginx, an application, a firewall, or the server itself.

Automated recovery should therefore avoid restarting services or rebooting hosts based only on a failed hostname lookup.

Know which resolver the server is actually using

Linux systems may obtain DNS configuration from static network settings, DHCP, Netplan, systemd-resolved, VPN software, containers, or other network-management layers.

Troubleshooting should begin with the effective resolver state rather than assuming that a configuration file represents what the system is currently using.

Query the intended resolver directly

A normal application lookup may pass through a local stub resolver or caching layer. Directly querying the intended DNS server helps reveal whether that resolver itself is producing the expected answer.

This is especially useful in private networks where the same hostname may intentionally resolve to one address internally and another address publicly.

Compare UDP and TCP DNS answers

DNS commonly uses UDP, but TCP is also part of normal DNS operation. Comparing answers over both transports can reveal inconsistent forwarding, interception, firewall behavior, or resolver paths.

If the same resolver returns different IPv4 answers over UDP and TCP, that disagreement is operational evidence worth recording rather than treating either response as automatically correct.

Validate the answer against the expected IP address

A DNS request can succeed technically while still returning the wrong address for the environment being monitored.

For split-DNS environments, monitoring should optionally compare the returned IPv4 address with the address that hostname is expected to use from that resolver.

An unexpected public address returned inside a private network can create intermittent routing failures even though DNS itself appears to be responding normally.

Compare delegation, authoritative DNS, and public resolvers

Resolver-path evidence answers only part of the question. Public monitoring can also compare the delegated nameserver set with the expected provider, query each configured authoritative nameserver directly, and compare multiple public recursive resolvers for the expected public address.

These layers should be classified separately. Delegation drift, authoritative disagreement, public-resolver disagreement, and an unexpected IPv4 address are different failure modes and should not be collapsed into a generic server-down condition.

Verify content identity, not only HTTP status

A public endpoint can return HTTP 200 while serving a registrar parking page, stale provider placeholder, or another site. Monitoring should therefore verify a stable semantic marker that identifies the intended site rather than treating status code alone as proof of correct public availability.

Public recursive resolvers provide independent DNS evidence. An HTTP request made by the same observer, however, is still evidence from that observer's network path and is not a genuine independent off-network Internet witness.

Intermittent DNS requires repeated observation

One successful lookup does not prove an intermittent DNS problem is gone. A resolver can behave correctly for hundreds of queries and still produce an incorrect response later.

Repeated probes over time are more useful than a single diagnostic snapshot. Monitoring should record anomalies while avoiding noisy alerts for every individual lookup.

Preserve evidence when the failure occurs

Useful incident evidence includes:

• hostname queried
• resolver address
• UDP answer
• TCP answer
• observed delegated nameservers
• authoritative nameserver answers
• public recursive resolver answers
• expected IPv4 address
• semantic content-identity result
• timestamp
• HTTP or TLS symptoms occurring at the same time
• effective resolver configuration
• default route and gateway state

Capturing this information during the incident is far more useful than trying to reconstruct the resolver path after everything has returned to normal.

Do not confuse configuration source with effective state

Linux network configuration can contain declarations that are later overridden by another file or management layer. A source file may still show DHCP or old DNS servers even when the effective merged configuration is static and correct.

Diagnostic tools should distinguish configuration drift from active behavior before recommending changes.

Correlate DNS failures with other symptoms

A DNS mismatch occurring at the same time as HTTP, TLS, or semantic content-identity failure provides stronger evidence than any one check alone.

When several hostnames fail through the same resolver or network path, monitoring may classify them as one infrastructure incident rather than sending a separate alert for every affected site.

Avoid recovery actions when DNS evidence is ambiguous

Restarting Nginx or rebooting a Linux server cannot correct every DNS problem. If local services are healthy while resolver evidence is inconsistent, the safer action is usually to alert and preserve the running system.

Recovery authority should remain close to the component actually proven unhealthy.

Related recovery guides

Read the Linux server automatic recovery guide for the broader monitoring and recovery architecture.

For reverse-proxy-specific failures, see the Nginx monitoring and automatic recovery guide.

For application and service-level recovery, see the systemd service monitoring and automatic recovery guide.

For certificate failures and expiration monitoring, see the SSL certificate monitoring and TLS expiration alerting guide.

For broader host and infrastructure health monitoring, see the Linux server health monitoring guide.

RecoverNode also documents its testing and safety methodology, including DNS resilience testing, ambiguous evidence, incident correlation, and recovery boundaries.