What you’ll learn
- Distinguish recursive resolvers from authoritative servers
- Describe how caching and TTLs affect an answer
- Identify where to look when a DNS lookup fails
The two sides of DNS
Most DNS lookups involve two different jobs. A recursive resolver finds an answer on behalf of a client and caches what it learns. An authoritative server publishes the official data for a DNS zone. Treating those roles as interchangeable makes troubleshooting much harder.
Your device usually sends its question to a configured recursive resolver. If that resolver already has a valid cached answer, it can respond immediately. If not, it follows referrals through the DNS hierarchy until it reaches a server authoritative for the requested name.
A lookup, step by step
For a name such as app.example.com, a resolver may ask a root server where to find the .com namespace, then ask a .com server where to find example.com, and finally ask an example.com authoritative server for the record. In practice, caching means resolvers rarely repeat every step for every query.
- The client checks local name information and sends a query to its resolver
- The resolver returns a cached answer or starts iterative discovery
- Referrals lead the resolver toward the authoritative zone
- The final answer is returned and cached for its remaining TTL
TTL is a consistency tradeoff
A record’s time to live (TTL) tells caches how long they may reuse the data. A long TTL reduces query volume and improves resilience when authoritative servers are briefly unreachable. A short TTL lets changes become visible sooner, but increases dependency on the authoritative service.
Changing a TTL does not invalidate copies that are already cached. If you plan a migration, reduce the TTL early enough for older cached values to expire before the change.
A useful troubleshooting order
Start with the exact name, record type, and resolver the client is using. Then compare the recursive answer with the authoritative data. Check response codes, delegation, TTL, DNSSEC validation status, search suffixes, and split-horizon views before assuming the application is at fault.
Ask three questions: Who did the client ask? Who is authoritative? Is the answer still cached?
References and further reading
KnowDDI lessons are explanatory guides. Standards and primary documentation remain the authority for implementation decisions.