intermediate · 6 min

Recursive vs Authoritative DNS

Who walks the tree, who holds the truth

Two completely different jobs share the name 'DNS server'. Knowing which is which is the difference between fixing an outage in minutes and chasing the wrong layer for hours.

When people say 'DNS server' they could mean one of two very different things. Conflating them is the most common reason DNS debugging goes sideways.

The recursive resolver

A **recursive resolver** answers any question for its clients by doing the legwork: it walks root → TLD → authoritative, caches what it learns, and hands back the result. Your laptop's stub resolver just asks it and trusts the answer. Examples: your ISP's resolver, 1.1.1.1, 8.8.8.8, a corporate resolver, or `systemd-resolved` forwarding upstream.

The authoritative server

An **authoritative server** holds the actual records for a zone (it 'is the source of truth' for, say, `example.com`). It never goes looking elsewhere — it answers from its own zone data, or says 'not here' (NXDOMAIN), or delegates a subzone. Examples: Route 53, Cloud DNS, your own BIND/NSD.

💻

you

stub

🧭

resolver

recursive

🌳

root

🏷️

TLD

.com

📜

auth

example.com

the recursive resolver walks the tree → the authoritative server gives the final answer

A cold query: the recursive resolver walks the hierarchy so your stub doesn't have to.

🔑Recursive = asks on your behalf and caches. Authoritative = owns the records. Root and TLD servers are authoritative for the *delegation*, not for your zone.

Why this matters in an outage

If `dig @your-resolver name` is wrong but `dig @authoritative name` is right → it's caching/the resolver, not the zone.
If `dig @authoritative name` is also wrong → the zone data is wrong; fix it at the source.
If different users see different answers → they're using different recursive resolvers.

That single comparison — resolver answer vs authoritative answer — resolves a huge fraction of real DNS incidents.

Commands to try

$ dig example.com

Ask your default recursive resolver; read the ;; SERVER line.

$ dig +trace example.com

Watch the recursive walk: root → TLD → authoritative.

$ dig @ns.example-auth.net example.com

Ask the authoritative server directly and compare.

Common mistakes

✗ Editing the zone when only one resolver is wrong.

✓ Compare resolver vs authoritative first — a stale cache isn't a zone bug.

✗ Assuming everyone uses the same resolver.

✓ Confirm the ;; SERVER line; corporate/VPN/split setups vary per client.

Related quests

▸ Ask the Resolver ▸ Follow the Trail