Recursive resolvers and caches

Your application normally asks the operating system for a name. The system sends that question to a configured recursive resolver.

The small resolver in your device is often called a stub resolver. It usually asks for recursion rather than contacting the DNS hierarchy itself. In a dig response, the rd flag shows that recursion was desired and ra shows that the server offers it.

The recursive resolver works on your behalf. On a cold lookup, it can follow referrals from root to top-level-domain to authoritative servers, follow aliases, validate DNSSEC when configured, and return a completed answer.

It also caches the result. The cache key includes at least the name, record type, and class: a cached A answer does not answer an MX question. Each record’s TTL limits how long it may be reused.

Watch a cached TTL decrease:

dig @1.1.1.1 A flaviocopes.com +noall +answer
dig @1.1.1.1 A flaviocopes.com +noall +answer

The second query may be faster and show a smaller remaining TTL. It might also reach a different anycast resolver instance, so identical or higher values do not prove caching is absent.

Negative answers are cached too. A recent NXDOMAIN can remain after you create the missing record. Your browser, operating system, local network, and recursive resolver can each add a cache, which is why “clear the browser” is not a complete DNS diagnosis.

Different resolvers can disagree temporarily because they cached answers at different times or apply different validation and filtering policies. Ask a named resolver explicitly when comparing results.

Your action is to query one A record twice through the same resolver. Record the TTL, query time, rd, and ra flags, then explain which observations suggest a cache hit and which remain inconclusive.