THE MAP
A hostname lookup is not one conversation.
A typical application asks a local resolver interface for a name. That stub resolver may consult local hosts files, caches, VPN policy, enterprise search domains, or a configured recursive resolver. The recursive resolver may answer from cache or pursue referrals toward authoritative name servers. Those authorities may themselves expose multiple records, DNSSEC material, aliases, and different answers by geography or policy.
By the time an application receives an IP address, several systems may have participated. When the answer is wrong or absent, “the DNS server” is often not a useful singular noun.
STUB RESOLVER
The failure can begin before a packet leaves the machine.
Applications usually do not implement the entire DNS resolution process themselves. They call operating-system or runtime resolver APIs. Local policy can therefore shape results before the network is consulted.
Hosts files, search suffixes, local caches, browser-specific secure-DNS settings, VPN clients, container runtime configuration, split-DNS rules, and enterprise agents can all influence which query is actually sent and where it goes.
If one application resolves a name while another on the same machine does not, that difference is evidence. Compare the resolver path before assuming the authority is inconsistent.
RECURSIVE RESOLVER
Recursive DNS is a caching system with opinions about time.
A recursive resolver exists partly to avoid asking the hierarchy the same question repeatedly. It caches positive answers for their TTLs and can also cache negative answers. That means two clients using different resolvers can receive different results during a change even when every server involved is behaving according to protocol.
“It works on my phone but not the office network” may indicate resolver cache state, policy, filtering, a stale delegation, a split-horizon environment, or a different upstream path. The difference is not evidence that one device possesses mystical networking talent.
TTL
DNS changes propagate through expiration, not magic.
TTL values tell caching resolvers how long a record may be reused before refresh. Lowering a TTL immediately before a migration can help only after old higher-TTL answers have already aged out. Changing the record and then lowering the TTL is a popular way to discover causality in the wrong order.
When troubleshooting a migration, record the old value, old TTL, new value, new TTL, change time, resolver queried, and the remaining TTL in observed responses. “Propagation” becomes much less mysterious when time is treated as part of the state.
NEGATIVE CACHING
Failure can be cached too.
An NXDOMAIN response or other negative information can be cached. A name created moments after a negative lookup may therefore remain unavailable through some resolvers until the negative cache lifetime expires.
This is why repeated clicking is not always a diagnostic technique. The resolver may be faithfully replaying a previously valid negative answer.
Capture the response code, authority information, TTL-related values, and which resolver produced the answer. If a direct authoritative query succeeds while the recursive resolver continues returning a negative answer, the problem has narrowed dramatically.
AUTHORITY
The authoritative server can be correct while the delegation is wrong.
A zone can be perfectly configured on its own name server and still be unreachable through normal resolution if the parent delegation points somewhere else, glue is wrong, a name server address is stale, or the zone is not consistently served across the advertised authority set.
Ask separately: what does the parent say the name servers are, and what do those name servers say for the zone? If the answers disagree, the location of the defect becomes visible.
This distinction matters because changing records inside the zone will not repair a broken path to the zone.
CNAME + ALIAS CHAINS
One name can delegate meaning to another name.
Aliases increase flexibility and increase the number of places a lookup can fail. A CNAME target can be missing, misconfigured, unexpectedly long-lived in cache, or dependent on another provider. Application platforms may add additional alias-like behavior at zone apexes through provider-specific mechanisms.
When a lookup involves aliases, trace the chain explicitly. Record each owner name, record type, target, TTL, and final address answer. “The hostname resolves” hides whether it resolved through the path you intended.
TRANSPORT
DNS is not permanently married to one tiny UDP packet.
Traditional DNS commonly uses UDP for ordinary queries, but TCP has long been part of the protocol and becomes important for responses that do not fit, zone transfers, and other cases. Modern encrypted resolver transports add still more paths.
Firewalls that allow one transport but mishandle another can produce intermittent-looking failures tied to response size or query type. EDNS extends what DNS can carry over UDP, but middleboxes can still create unpleasant archaeology.
If small queries work and larger or DNSSEC-related queries fail, inspect transport behavior instead of concluding that a record type is cursed.
DNSSEC
A signed zone adds validation state, not merely more records.
DNSSEC lets validating resolvers detect certain forms of tampering and prove authenticated denial of existence. It also creates a chain of trust that can fail if signatures expire, keys roll incorrectly, DS records disagree with the child zone, or validation state is otherwise broken.
A non-validating path and a validating resolver can therefore behave differently against the same zone. When DNSSEC is involved, distinguish name data exists from the validator accepts the chain.
SPLIT DNS
Different answers may be intentional.
Enterprise networks, VPNs, private cloud environments, and internal service discovery systems often return answers that differ from the public DNS view. This can be correct design.
Problems appear when clients land on the wrong side of that policy boundary: VPN connected but resolver not switched, resolver switched but routes absent, container inherits host DNS that cannot reach internal authorities, or public fallback returns an address that is valid only outside the network.
Always record the resolver address and network context with a result. A DNS answer without its viewpoint is incomplete evidence.
DIAGNOSTIC METHOD
Walk the chain instead of restarting random services.
1. Define the exact name and record type. A, AAAA, MX, TXT, SRV, CAA, and others answer different questions.
2. Ask the local resolver path. Record the application or tool behavior and configured resolver.
3. Query the recursive resolver directly. Preserve response code, answer, authority, additional data, and TTLs.
4. Identify the authoritative set. Follow delegation from the parent where necessary.
5. Query authorities directly. Compare them with each other and with the recursive answer.
6. Inspect aliases and DNSSEC state. Follow every dependency actually used.
7. Compare another network or resolver. Differences reveal cache or policy boundaries.
8. Use packet capture only when it answers a remaining question. Do not begin with a pcap because the toolbar button looked serious.
FAILURE PATTERNS
What common symptoms often narrow.
One resolver wrong, authority correct: stale cache, policy, validation failure, or resolver-specific problem.
All authorities disagree: zone deployment inconsistency or provider synchronization issue.
Authority correct, parent delegation wrong: registrar/delegation layer.
Works off VPN, fails on VPN: split-DNS, resolver routing, or policy boundary.
A works, AAAA fails: record-family or IPv6-specific configuration, not “DNS” generically.
Small replies work, larger ones fail: transport, fragmentation, EDNS, firewall, or middlebox behavior deserves attention.
New name still NXDOMAIN through some resolvers: negative caching may be doing exactly what it was told.
BOTTOM LINE
Resolution is a distributed state machine with memory.
DNS feels simple because the application call is simple. Underneath, the system is hierarchical, cached, delegated, policy-sensitive, and time-dependent.
When a name fails, identify which layer produced the answer before changing the layer you happen to control.
That one habit prevents a remarkable amount of ceremonial rebooting.
SOURCE TRAIL
Protocol references.
RFC 1034 — Domain Names: Concepts and Facilities
RFC 1035 — Domain Names: Implementation and Specification
RFC 2308 — Negative Caching of DNS Queries
RFC 7766 — DNS Transport over TCP
RFC 4033 — DNS Security Introduction and Requirements