Recursive vs. authoritative DNS: what's the difference

Two different jobs

A recursive resolver's job is to answer questions on behalf of a client, even though it doesn't hold any of the actual domain data itself, at least not until it's looked something up and cached the answer. When your laptop or phone asks "what's the address for example.com", it's almost always asking a recursive resolver, not the domain's own name servers directly. The resolver then does the legwork described in DNS record types explained: working down from the root, to the TLD, to the name servers authoritative for the domain, before finally getting a real answer back.

An authoritative name server has a completely different job: it's the actual source of truth for one specific zone. It doesn't go looking anything up elsewhere, it holds the real records for that domain and answers directly from them. When a recursive resolver finally reaches the right authoritative server at the end of its chain, that's the only point in the whole process where the answer comes from the actual data rather than a cache or a referral to somewhere else.

Why the distinction matters when something looks wrong

Where a DNS problem lives changes what actually needs fixing, and mixing up recursive and authoritative is a common way to waste time on the wrong fix.

If a record looks wrong from everywhere, consistently, the place to check is the authoritative server's actual zone data. A stale or incorrect record there is the real problem, and every recursive resolver anyone queries is just faithfully reporting what the authoritative server told it.

If a record looks wrong only from some locations, or only sometimes, or clears up on its own after a while, that pattern points at caching on a recursive resolver rather than a fault in the zone itself. Different resolvers cache the same answer for different lengths of time depending on when they last looked it up, so it's entirely normal for one location to see an old answer while another already sees the new one. The fix in that case isn't to edit the zone again, the zone is probably already correct, it's to wait out the record's TTL so the stale cached copies expire on their own.

A quick way to tell them apart while troubleshooting

Querying a recursive resolver, such as the one your device uses by default, gives you what the wider internet currently believes, including anything still cached. Querying the domain's authoritative name servers directly gives you the current, real state of the zone, with no caching in the way. When a lookup tool lets you specify which server to query, pointing it at the authoritative server is the way to confirm what the zone actually says right now, separate from what any particular resolver happens to have cached at that moment. Comparing the two is also a useful step when a connectivity issue turns out not to be DNS at all, see Traceroutes & MTRs for tracing the network path itself once the DNS answer is confirmed correct.