Recursive resolvers and caches

When your app needs an address, it asks the operating system. The operating system passes the question to a recursive resolver it has been configured to use.

There are two resolvers in this story, and it pays to keep them apart.

Stub and recursive

The one on your device is a stub resolver. It’s small and lazy on purpose. It doesn’t talk to the root servers. It sends one question upstream and says “please do the recursion for me.”

You can see this request in a dig response. The rd flag means recursion was desired. The ra flag means the server that replied offers recursion.

The recursive resolver does the real work. On a cold lookup it walks from root to TLD to authoritative server, follows CNAME aliases, validates DNSSEC if configured, and returns one finished answer.

The cache

Then it caches the result. Every answer has a TTL that says how long the resolver may reuse it.

The cache key is at least the name, the record type, and the class. A cached A answer doesn’t answer an MX question for the same name. Different question, different cache entry.

Let’s watch a TTL count down. Run this twice, a few seconds apart:

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

The second run is usually faster and shows a smaller TTL. That’s a cache hit.

Be careful with the opposite conclusion though. 1.1.1.1 is anycast, so your second query may land on a different server with a different cache. An equal or higher TTL doesn’t prove there’s no caching. It proves you hit a different cache.

Negative answers get cached too

Ask for a name that doesn’t exist and the resolver remembers that too. Create the record a minute later and that resolver may keep saying “doesn’t exist” until the negative entry expires.

And there isn’t just one cache. Your browser has one. The operating system has one. Your router may have one. Then the recursive resolver. “Clear your browser cache” is rarely the whole DNS diagnosis.

Resolvers disagree, and that’s normal

Two resolvers can give different answers for a while. They cached at different times, or they apply different filtering and validation rules. When you compare, always name the resolver with @ so you know who you’re asking.

Try this: query one A record twice through the same resolver. Write down the TTL, the query time, and the rd and ra flags. Which observations point to a cache hit? Which ones don’t prove anything?