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.
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
DNS evidence needs name, type, server, origin, and time.
Reference: RFC 1034: DNS concepts · DNS RFC 1034/1035 with RFC 2181, 2308, 3596, 4033, 7766 and 8767; dig BIND 9.20