Recursive vs Authoritative DNS Servers Explained

Every DNS lookup involves two very different kinds of server doing two very different jobs. A recursive resolver chases down the answer on your behalf and remembers it. An authoritative server holds the real records for a zone and hands them out when asked. Confusing the two is the root of a lot of DNS misunderstanding, including the popular idea that changes have to slowly propagate across the internet. This guide separates the two roles, walks a query through both, and shows where caching and TTLs sit in between.

The two roles

An authoritative server is the source of truth for a zone. When you edit your DNS records at your provider, you are editing the data its authoritative servers will return. Ask an authoritative server for a name it owns and it answers from its own zone data, flagging the reply as authoritative.

A recursive resolver owns no zones. Its job is to take your question, walk the DNS tree until it finds an authoritative server that knows the answer, and return that answer to you. It then caches the result so the next identical question can be answered instantly without repeating the walk. The resolver your laptop or phone uses is run by your ISP, or by a public service such as 1.1.1.1 or 8.8.8.8.

Walking a single lookup

Suppose a fresh resolver, with an empty cache, is asked for www.example.com. It does not know the answer, so it asks a chain of authoritative servers, each one pointing it closer to the target.

1. It asks a root server, which does not know www.example.com but is authoritative for the root and refers the resolver to the .com servers.
2. It asks a .com server, which refers it to the authoritative nameservers for example.com.
3. It asks one of example.com's nameservers, which is authoritative for the zone and returns the A record for www.example.com.

You can watch this exact sequence of referrals with a trace, which is the recursive process laid out step by step:

$ dig +trace www.example.com
.                    NS   a.root-servers.net.      ; root refers to TLD
com.                 NS   a.gtld-servers.net.      ; TLD refers to the zone
example.com.         NS   ns1.example-dns.com.     ; zone's authoritative NS
www.example.com.     A    203.0.113.10             ; authoritative answer

Compare the flags when you query a resolver versus the authoritative server directly. The authoritative answer carries the aa (authoritative answer) flag; the resolver's cached reply does not.

# Ask the authoritative server directly: note "flags: ... aa"
$ dig @ns1.example-dns.com www.example.com | grep flags
;; flags: qr aa rd; QUERY: 1, ANSWER: 1

# Ask a recursive resolver: no "aa", but it answers from cache
$ dig @1.1.1.1 www.example.com | grep flags
;; flags: qr rd ra; QUERY: 1, ANSWER: 1

Where caching and TTLs sit

Caching lives entirely in the recursive resolver, and it is governed by the TTL (time to live) that the authoritative server attaches to each record. When the resolver receives an answer, it stores it and starts a countdown equal to the TTL. Until that countdown reaches zero, every client behind that resolver gets the cached answer without the resolver asking again.

This is the single most important thing to understand about DNS behavior. The authoritative data changes the instant you save it, but resolvers around the world keep serving their cached copies until each one's TTL expires. A record with a one-hour TTL can be served from caches for up to an hour after you change it.

; The number before IN is the TTL in seconds
www.example.com.   3600   IN   A   203.0.113.10
;                  ^^^^ resolvers may cache this answer for up to 1 hour

Propagation is really just caching

People describe a DNS change as needing to propagate, as if the new value physically spreads across the internet. That picture is misleading. Your authoritative servers update immediately. What you are actually waiting for is the old answer to age out of the many independent recursive caches that already stored it. There is no central distribution; there is only a collection of resolvers, each holding your record until its own TTL runs out.

This explains two everyday experiences. First, lowering a record's TTL a day before a planned change makes the switch feel fast, because caches hold the old value for a shorter time. Second, a change can look live for you but stale for a colleague, simply because your two resolvers cached at different moments and their TTLs expire at different times.

It also explains why there is no button anywhere that forces the world to update instantly. No one operates all those resolvers, and each honors the TTL you set. The only levers you truly hold are the TTL you publish ahead of a change and the authoritative data itself. Everything downstream is other people's caches quietly counting down.

Flushing versus waiting

You can shorten the wait on a machine you control by flushing its cache, but it helps to know which cache you are clearing. Your own operating system keeps a small cache, and so does the recursive resolver upstream of you. Flushing your OS cache does nothing about the resolver's cache, which you usually cannot flush at all. For a resolver you do not control, the only universal remedy is to wait out the TTL.

• Your OS cache: clearable with a local command, affects only your machine.
• The recursive resolver's cache: usually not clearable by you; expires on its own TTL.
• Authoritative data: never cached by itself; always current.

See both layers for yourself

The clearest way to internalize the difference is to query an authoritative server directly and compare it to what resolvers return. Use the Valla DNS lookup to query your authoritative nameservers and the propagation checker to see what resolvers worldwide currently hold, and the gap between the two is exactly the caching you have been waiting on. Pair this with our guides on DNS TTL strategy and on flushing your DNS cache to take control of that wait.