What Is the Difference Between Authoritative and Recursive DNS Servers?

When someone says "the DNS server," they could mean two completely different machines doing two completely different jobs. One kind of server holds the official records for your domain and answers questions about it. The other kind holds nothing of its own — it goes out and asks the first kind on your behalf, then remembers the answer. Mixing them up is behind a surprising number of support tickets: people "flush the DNS server" when they meant their resolver, or edit records at their registrar and wonder why their ISP still returns the old IP.

If you already know how DNS works at a high level and have read about the role of a DNS resolver, this article goes one step further. It puts authoritative and recursive servers side by side: what each one stores, how their responses differ on the wire, how to tell which one you're talking to, why you should never run both roles on the same public-facing server, and which one to blame when something goes wrong.

The Short Version

An authoritative DNS server is the source of truth for one or more zones. When you add an A record in your DNS provider's dashboard, that record ends up on their authoritative servers. They answer only for the zones they host, and they answer from data they own.

A recursive DNS server (also called a recursive resolver or full-service resolver) doesn't own any zones. It accepts questions from clients — laptops, phones, web servers — and does the legwork of walking the DNS hierarchy until it reaches the authoritative server that knows the answer. It then caches that answer for the record's TTL so the next client gets it instantly.

A useful analogy: the authoritative server is the company's official records office, and the recursive resolver is a researcher who knows which office to phone, writes down what they're told, and reuses their notes until they expire.

Side-by-Side Comparison

Aspect	Authoritative server	Recursive resolver
Primary job	Publish the records for zones it hosts	Find answers for any name on behalf of clients
Data source	Zone files or a provider database	Cache, plus answers fetched from authoritative servers
Who queries it	Recursive resolvers across the internet	End-user devices and applications (stub resolvers)
Answers for	Only its own zones	Any domain on the internet
aa flag in responses	Set (authoritative answer)	Not set (answer came from elsewhere)
ra flag in responses	Usually not set	Set (recursion available)
Caches other people's data	No	Yes, honoring TTLs
Typical examples	Cloudflare DNS, Route 53 hosted zones, BIND with recursion no	1.1.1.1, 8.8.8.8, 9.9.9.9, ISP resolvers, Unbound
Who configures it	Domain owner or DNS host	ISP, network admin, or the user
Exposure	Must be reachable by the whole internet	Should only serve its own users

The rest of this article unpacks the rows that matter most in practice.

How a Lookup Flows Between the Two

Consider a browser asking for www.example.com with an empty cache:

1. The device's stub resolver sends a query with the RD (recursion desired) bit set to its configured recursive resolver.
2. The recursive resolver asks a root name server, which replies with a referral to the .com servers.
3. The resolver asks a TLD name server for .com, which replies with another referral — the NS records for example.com.
4. The resolver asks one of those nameservers. This is the authoritative server for example.com, and it returns the actual A record with the aa flag set.
5. The resolver caches the answer and hands it back to the stub resolver.

Notice that the root and TLD servers are themselves authoritative — just for higher levels of the tree. The root servers are authoritative for the root zone, the .com servers are authoritative for com., and your provider's servers are authoritative for example.com. "Authoritative" isn't a tier; it's a role that every level of the hierarchy plays for its own zone. The recursive resolver is the only participant that never answers from its own zone data.

Reading the Difference in dig Output

The clearest way to see the distinction is to query both kinds of server directly and compare the header flags. First, ask the authoritative server for example.com, with recursion turned off:

dig +norecurse example.com A @hera.ns.cloudflare.com

The relevant part of the response looks like this:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14566
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com.  300 IN A 172.66.147.243
example.com. 300 IN A 104.20.23.154

The aa flag tells you this server is authoritative for the zone. There's no ra flag, because it won't recurse for you. The TTL shows the full configured value (300), because the record is coming straight from the zone rather than a cache.

Now ask a public recursive resolver the same question:

dig example.com A @1.1.1.1

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com.  187 IN A 104.20.23.154
example.com.  187 IN A 172.66.147.243

Here rd echoes your request for recursion, ra says the server offers it, and ad means the resolver validated the answer with DNSSEC. There's no aa — the resolver is relaying someone else's data. The TTL is lower than 300 because the record has been sitting in the resolver's cache and is counting down.

Finally, try asking an authoritative server about a zone it doesn't host:

dig +norecurse www.wikipedia.org A @hera.ns.cloudflare.com

A properly configured authoritative server returns REFUSED (or an empty referral) rather than going off to look it up. That refusal is exactly what you want — it's the server staying in its lane.

Checking the Flags Programmatically

If you're building monitoring that confirms your nameservers are answering authoritatively, you can check the AA bit with dnspython:

import dns.flags
import dns.message
import dns.query
import dns.resolver

zone = "example.com"

# Find the zone's nameservers and pick the first one's IPv4 address
ns_name = str(dns.resolver.resolve(zone, "NS")[0].target)
ns_ip = dns.resolver.resolve(ns_name, "A")[0].address

# Build a query with recursion desired turned OFF
query = dns.message.make_query(zone, "A")
query.flags &= ~dns.flags.RD

response = dns.query.udp(query, ns_ip, timeout=3)

print(f"Nameserver: {ns_name} ({ns_ip})")
print("Authoritative (AA):", bool(response.flags & dns.flags.AA))
print("Recursion available (RA):", bool(response.flags & dns.flags.RA))
for rrset in response.answer:
    print(rrset)

The script resolves the zone's NS records, sends a non-recursive query directly to one nameserver, and prints whether the AA and RA bits are set. If AA ever comes back false for your own zone, that nameserver has lost the zone — a classic sign of a lame delegation where the parent zone points at a server that no longer hosts it.

Why You Shouldn't Combine Both Roles

Older BIND setups often ran authoritative and recursive service in the same process on the same IP. It works, but it's now considered bad practice for three reasons:

1. Cache poisoning risk. A server that both caches external data and serves authoritative data can, under some bugs and misconfigurations, mix the two. Separating them means a poisoned cache can never contaminate the records you publish.
2. Open resolver abuse. An authoritative server must answer anyone on the internet. If it also recurses for anyone, it's an open resolver — a ready-made reflector for DNS amplification attacks.
3. Confusing behavior. A combined server will happily answer for zones it doesn't own (from cache), which hides delegation mistakes. When the parent zone stops pointing at you, a combined server keeps "working" for internal users while the rest of the internet fails.

An authoritative-only BIND configuration

If you run your own DNS server with BIND, the authoritative role should explicitly disable recursion:

// /etc/bind/named.conf.options — authoritative only
options {
    directory "/var/cache/bind";
    recursion no;
    allow-query { any; };
    allow-transfer { none; };
    dnssec-validation no;   // validation is a resolver job
    minimal-responses yes;
};

zone "example.com" {
    type primary;
    file "/etc/bind/zones/db.example.com";
};

recursion no; is the key line: the server answers authoritatively for example.com and refuses everything else. Run named-checkconf before reloading to catch syntax errors.

A recursive-only Unbound configuration

The resolver role belongs on a separate machine or at least a separate IP, restricted to your own networks:

# /etc/unbound/unbound.conf — recursive resolver only
server:
    interface: 192.0.2.53
    access-control: 0.0.0.0/0 refuse
    access-control: 192.0.2.0/24 allow
    access-control: 127.0.0.0/8 allow
    hide-identity: yes
    hide-version: yes
    prefetch: yes
    auto-trust-anchor-file: "/var/lib/unbound/root.key"

This tells Unbound to listen on one internal address, refuse queries from anywhere except your LAN and localhost, prefetch popular records before they expire, and validate DNSSEC using the root trust anchor. Check it with unbound-checkconf before restarting.

Which One Do You Actually Control?

For most site owners the answer is clear-cut:

• You control the authoritative side through your DNS host — Cloudflare, Route 53, your registrar's DNS, or your own BIND server. Every record change you make lands here, and it's visible instantly when you query those nameservers directly.
• You don't control most recursive resolvers. Your visitors use their ISP's resolver, a public resolver, or a corporate one. They cache your records according to the TTL you published, and you can't force them to drop it early.

This is why "propagation" is really a recursive-caching phenomenon. Your authoritative servers have the new record the moment you save it; the delay is resolvers holding the old answer until its TTL runs out. If you want changes to take effect quickly, lower the TTL on the record well before you change it.

You do control the recursive resolver on your own devices and network — you can switch to a public resolver or run one locally. That's the right lever for privacy, filtering, and speed for your own users, but it does nothing for your visitors.

Troubleshooting: Which Server Is Wrong?

When a record doesn't resolve as expected, query both kinds of server and compare:

# 1. What does the authoritative server say? (the truth)
dig +norecurse www.example.com A @ns1.example.com

# 2. What does a recursive resolver say? (the cached view)
dig www.example.com A @8.8.8.8

# 3. Follow the delegation chain from the root yourself
dig +trace www.example.com A

The first command shows what you've actually published. The second shows what one popular resolver currently has cached. The third makes dig behave like a recursive resolver itself, starting from the root and following referrals, so you can see where the chain breaks.

Read the results this way:

• Authoritative is wrong: fix the record at your DNS host. No amount of cache flushing will help.
• Authoritative is right, recursive is stale: wait for the TTL to expire, or flush the cache on resolvers you control.
• Authoritative is right but +trace fails at the delegation step: the NS records at your registrar don't match the servers that host your zone.
• Authoritative server returns REFUSED or no aa flag for your own zone: the zone isn't loaded on that server, or you're querying the wrong nameserver.

---

Authoritative vs Recursive DNS FAQ

Conclusion

Authoritative and recursive DNS servers are two halves of the same system, and almost every DNS problem gets easier to solve once you know which half you're looking at. Authoritative servers publish the truth for the zones they host, mark their answers with the aa flag, and should refuse to answer for anyone else. Recursive resolvers own nothing, find answers on behalf of clients, and cache them for as long as the TTL allows — which is where propagation delays and stale results come from.

In practice: make record changes on your authoritative provider, use dig +norecurse against your nameservers to confirm what you've actually published, and treat recursive resolvers as caches you can influence only through TTLs. If you run your own infrastructure, keep the two roles separate — an authoritative server with recursion no and a resolver locked down to your own networks is safer and much easier to debug.

Here are some useful references for going deeper on authoritative and recursive DNS:

1. RFC 1034: Domain Names - Concepts and Facilities — the original description of name servers, resolvers, and recursive versus iterative queries.
2. RFC 9499: DNS Terminology — the IETF's current definitions of authoritative servers, recursive resolvers, stub resolvers, and related terms.
3. Cloudflare Learning Center: What is a DNS server? — a clear walkthrough of recursive resolvers, root, TLD, and authoritative servers.
4. BIND 9 Documentation: BIND 9 Administrator Reference Manual — configuration reference for authoritative and recursive BIND deployments.
5. NLnet Labs: Unbound Documentation — official documentation for the Unbound validating recursive resolver.