NXDOMAIN after DNS changes: negative caching and rollout

Core idea

Resolvers can cache proof that a name does not exist. Creating the record immediately after NXDOMAIN leaves some clients with the negative answer until its DNS lifetime expires; changing a proxy does not necessarily change resolver state.

For NXDOMAIN after DNS changes: negative caching and rollout, distinguish device, router, proxy endpoint, exit IP, ASN, and geolocation estimate. They describe different points in a network. A database may return a regional center or carrier gateway, so an IP result must never be presented as a person's exact physical address.

What the primary source establishes

Distinguish NXDOMAIN from SERVFAIL, inspect the negative TTL, and publish a proxy hostname without random cache flushing.

The primary source, RFC 2308 — Negative DNS Caching, RFC 9520 — DNS Error Caching, RFC 1034 — DNS Concepts, RFC 1035 — DNS Implementation, RFC 4035 — DNSSEC Protocol, defines the technical baseline but not every client and provider configuration. Read the normative behavior with its version and then verify your implementation. Treat anything beyond the source as a product feature that needs separate confirmation.

Controlled lab

Choose a unique label in an owned zone, configure a short safe negative TTL, and obtain NXDOMAIN. Publish a documentation endpoint and compare the authority with two recursive resolvers. Produce a DNSSEC validation failure in an isolated zone and require the monitor to report SERVFAIL separately.

Step-by-step verification

Query a nonexistent name in an owned authoritative zone through known resolvers and record response code, SOA, and TTL. Publish A or AAAA and repeat at a modest schedule.

Draw the client-to-endpoint path and mark DNS, NAT, and proxying. Capture direct and proxied address family, exit IP, ASN, claimed region, and time. Repeat mobile-network runs because carrier gateways may change without physical movement.

Compare product location, actual ASN, and at least two independent databases. City disagreement can fit normal accuracy limits. Verify country before a strict-country session; use device location with explicit permission when a workflow truly needs coordinates.

• Capture NXDOMAIN and SOA
• Publish A or AAAA
• Observe two resolvers
• Distinguish a SERVFAIL control

Evidence to retain

Record qname and qtype, resolver, time, RCODE, authority SOA, TTL, DNSSEC flags, addresses, and publish time. Exclude production internal names.

Record a masked IP or internal ID, address family, ASN, organization, network type, database, and update date. Collect evidence in one time window. Do not publish connection credentials or unnecessary coordinates.

Define report columns and time format before the run. A result without context becomes a guess: the address, cache state, and changed condition are unknown. Record controlled failures as well as successes so the check proves that it can distinguish states.

Interpreting the result

SERVFAIL is a different category caused by validation, timeout, or authority errors. Permanently replacing a hostname with an IP can break certificate identity and future address changes.

Resolvers can cap TTL and applications add caches. A lab cannot guarantee every ISP update time.

One successful run confirms only one client, route, and moment. Repeat while changing one variable and state the limits. When observation conflicts with documentation, rule out cache, client version, and intermediaries before creating a reproducible support case.

Worked decision process

Draw NXDOMAIN after DNS changes: negative caching and rollout as device, gateway, public NAT, proxy entrance, proxy exit, DNS, and origin, with address family and measurement point. This prevents local addresses from entering remote allowlists and separates entry-server location from exit geography.

Correlate geography with ASN and observation time. Databases age differently, carrier gateways are shared, and anycast changes paths. A city mismatch is not proof of failure; verify country and exit IP in the same session as the application request.

Troubleshoot local DNS and routes, entry connectivity, authentication, exit family, and destination reachability in order. Ping does not test HTTP CONNECT. After a fix, repeat the original small scenario with the same DNS and destination.

Common mistakes

Do not allowlist 192.168.x.x on an external service, confuse CGNAT with a proxy, or treat an ISP label as proof of a mobile device. IPv6 and DNS handling also vary by client, so validate the full path with the actual application.

Stop when errors rise, a source returns a limit, the task would require bypassing protection, or secrets enter logs. Save sanitized diagnostics and correct the cause first. More concurrency or another IP can hide the fault and add load without improving evidence.

Rollout and maintenance criteria

Define the decision boundary before rollout: which observation permits continuation, which requires review, and which stops the workflow. Record acceptable error ratio, maximum wait, and the owner of every exception so a temporary failure cannot silently become permanent configuration.

Review real load, cost, and quality after the first week. Schedule a small control after client, proxy-service, or network changes. Archive outdated instructions with their replacement date and reason so operators do not follow conflicting configurations.

Operational checklist

Turn the successful experiment into a short procedure covering owner, safe configuration, limits, and stop conditions. Every run needs a terminal status. After browser, library, or network changes, run a small control before the main queue.

• Every route address is labeled
• DNS and NAT are separate
• Direct and proxy exits are compared
• Database date is known
• City is not treated as exact
• Client compatibility is verified