← DNS: understand and diagnose resolution
01 / 5 · 18 MIN

Resolver, authority, and client context

Identify who answered and distinguish authoritative data from cached data.

Concept and mechanism

An application may use the system resolver, its own cache, or a configured resolution service. A recursive resolver obtains an answer for the client and may reuse cached data. An authoritative server answers for zones it serves. These roles may exist in the same product but have different responsibilities. Delegation connects a zone to the authority for a child zone; a broken link may prevent reaching records that exist at the final server.

Guided application

During investigation, record the full name, requested type, queried server, client origin, and time. Compare a query to the application’s resolver with a directed authoritative query where authorized and reachable. A correct answer from your laptop does not demonstrate a pod, server, or private network path. With distinct DNS views, different answers may be intentional. Confirm the expected context first, then look for inconsistencies within it. Changing the wrong server does not fix the affected client.

IN PRACTICE

A private API resolves on a VPN-connected laptop but not on the batch server. Compare resolvers and forwarding for the private zone.

Common pitfalls

Concluding DNS is healthy from one origin; confusing a cached answer with authoritative publication.

Related topics: Records, aliases, and query type · TTL, negative caching, and controlled change

Take this idea with you

DNS evidence needs name, type, server, origin, and time.

Create account

Reference: RFC 1034: DNS concepts · DNS RFC 1034/1035 with RFC 2181, 2308, 3596, 4033, 7766 and 8767; dig BIND 9.20