NXDOMAIN: Diagnose a DNS Security Anomaly

A rise in NXDOMAIN means that more DNS lookups are receiving a response indicating that a name does not exist. For a SOC, the useful question is which device is requesting which names, through which resolver, and what changed before the activity began. A counter alone cannot distinguish an application failure, a blocking policy and a suspicious program.

Diagnosis starts with a complete response and an identified endpoint. It ends with a decision supported by evidence: correct a configuration, explain a filtering action, continue an investigation or specify what information is still missing.

Read the exact resolution result

An empty answer does not automatically mean NXDOMAIN. Record the response code, requested record type, answer and authority sections, and the address of the server queried. When using a tool such as dig, initially avoid abbreviated output that hides these fields.

RFC 2308 on negative caching distinguishes NXDOMAIN, which concerns a nonexistent name, from NODATA, where the name exists but has no data of the requested type. It also explains that NXDOMAIN can refer to the final target of a CNAME chain. These distinctions change which name you need to investigate.

In this fictional example, api.service.example exists as an alias, but its old destination no longer resolves:

question: api.service.example. A
answer:   api.service.example. CNAME ancien.service.example.
status:   NXDOMAIN

The investigation concerns ancien.service.example, followed by the configuration that retains this alias. Declaring the entire service.example domain nonexistent would lead to the wrong diagnosis. SERVFAIL requires a different investigation again: the server was unable to complete resolution.

Reconstruct the path from endpoint to resolver

Identify the resolver actually used when the event occurred. System DNS, browser DNS, a VPN and an enterprise gateway can follow different paths. A command run on your own computer does not necessarily reproduce the affected endpoint’s situation.

For each observation, preserve the UTC time, asset, full name, query type, resolver, response code and process when collected. Add the originating network and VPN state. These details make comparisons reproducible and prevent two legitimate DNS views from being mistaken for contradictory results.

For an internal zone, query only the servers intended by your architecture. Sending its name to a public resolver exposes internal information without resolving a private DNS view problem. The guide to monitoring encrypted DNS explains why some queries bypass the usual collection point.

Establish whether a policy caused the response

A filtering product can return a negative result to the client. Review its decision log for the exact name, endpoint, time and matching rule. A blocklist match is an explanation to verify, rather than an intrinsic property of the domain.

If the resolver supplies Extended DNS Errors, record them. RFC 8914 includes blocking and filtering indications that supplement the DNS response code. Their absence does not prove that no policy was applied: the product or collection path might not expose them.

For a public domain, compare the result with an authorized lookup from a point where that policy does not apply. Document the difference without bypassing the block to visit the site. This comparison establishes where the response originated; it does not establish whether the destination is safe.

Separate negative caching from broken configuration

A DNS change can be correct at the authoritative servers while some clients still see an earlier failure. Capture the resolver’s response and the authoritative responses, including their timestamps and available SOA information. Repeat after an interval consistent with the cache lifetime observed.

Preserve the first observation before flushing caches. A flush might restore service, but it also removes evidence explaining why a group of clients was failing. Prefer a controlled test on one endpoint and record any cache clearing performed.

Consider a fictional incomplete migration. An application requests collecte-v1.service.example every minute. Newer endpoints received an updated configuration, while several old agents still use this deleted name. Failures cluster around one version, one signed process and a regular interval. The correction should address the application deployment without creating a blanket monitoring exception.

Measure the anomaly at the right level

Compare failed requests with the total volume from the same asset, over the same period and through the same sensor. An absolute increase as more endpoints become active means something different from new behavior on a single server.

Group names by suffix, then examine the individual values. Repeated typing errors, automatically appended suffixes and application-generated names require different responses. Keep a representative sample, including successful resolutions close to the failures.

Repetition alone does not establish malicious behavior. To assess that hypothesis, look for an unexpected process, an unusual parent, a newly created task or corroborating network activity. The method for correlating DNS, IP and process evidence describes the records needed to connect these observations.

Make a decision that another analyst can review

An established configuration error calls for a targeted fix, an owner and verification after deployment. Expected blocking calls for confirmation of the rule and its scope. Unexplained local activity calls for endpoint investigation, even when every DNS request fails.

Separate facts from unknowns in the ticket. For example: “The identified process requests an old service name; the authoritative servers no longer publish it; no other destinations have been examined.” This supports the repair without claiming that every possibility of compromise has been excluded.

For a suspicious public domain, consult its reputation report and retain the dated result alongside your collected evidence. Reputation adds context to the decision. It cannot replace the DNS status the client actually received or the identity of the program that initiated the lookup.