Recursive vs Authoritative DNS (and Why It Matters for Security)
.jpeg)
Quick answer: A recursive DNS server does the asking. It receives a query from a client, walks the DNS hierarchy on the client's behalf, caches the result, and returns a final answer. An authoritative DNS server does the answering. It holds the actual zone data for a domain and responds only for the domains it owns. The distinction matters for security because protective DNS products sit at the recursive resolver, which is the only place in the chain that sees every query from every one of your devices. It's also why cache poisoning targets recursive servers and registrar hijacking targets authoritative ones.
New here? Start with What Is DNS Security? and DNS Attack Protection.
The four types of DNS servers
Before the comparison, here are the four participants. Numbered, because a query touches them in this order.
- Stub resolver. The small DNS client built into your operating system. It doesn't walk the hierarchy. It asks one configured server and takes the answer.
- Recursive resolver. The workhorse. It accepts queries from clients and performs recursion: asking root, TLD, and authoritative servers in sequence until it has an answer. It caches aggressively.
- Root and TLD servers. The referral layer. Root servers point to TLD servers for
.com,.org,.ioand the rest. TLD servers point to the authoritative servers for a specific domain. Neither answers your actual question. - Authoritative name server. The source of record. It holds the zone file for a domain and returns the real answer for names inside it.
What is recursive DNS?
Recursive DNS is the process of chasing a name down the hierarchy until you reach a definitive answer, and a recursive DNS server is the machine that does the chasing.
Your ISP runs one. Your corporate network probably runs one. Public resolvers like 1.1.1.1, 8.8.8.8, and Quad9's 9.9.9.9 are recursive resolvers offered as a service. Every protective DNS product is, at its core, a recursive resolver with a policy engine bolted to it.
DNS recursion exists so that your laptop doesn't have to know how the internet is organized. It asks one question and gets one answer.
What is authoritative DNS?
An authoritative DNS server holds the zone data for one or more domains and answers only for those domains. If you own example.com, your authoritative servers hold its A records, MX records, TXT records, and CNAMEs. Ask them about anotherdomain.com and they'll tell you they don't know.
Authoritative servers are usually run by your DNS hosting provider, your registrar, or your cloud platform. They never query anyone else on your behalf. They answer, or they refer.
Recursive vs authoritative DNS, side by side
| Recursive DNS | Authoritative DNS | |
|---|---|---|
| Core job | Asks other servers until it finds an answer | Holds and returns the answer for its own domains |
| Who runs it | ISPs, enterprises, public resolvers, protective DNS vendors | Domain owners, DNS hosting providers, registrars |
| Scope of knowledge | Any domain, by asking | Only the zones it's authoritative for |
| Caches results | Yes, this is central to how it works | No, it serves from its own zone data |
| Talks to clients directly | Yes | Only when a recursive resolver or client asks it |
| Sees your users' queries | Yes, all of them | Only queries for its own domains |
| Where filtering happens | Here | Not here |
| Main attack risk | Cache poisoning, resolver hijacking, DDoS | Registrar and zone compromise, DDoS, hijacking |
Walking one query end to end
Say you type blog.example.com into a browser on a laptop that has never visited it.
Step 1. The stub resolver in your OS checks its local cache. Nothing. It sends a query to the configured recursive resolver, usually over UDP port 53, or over DoH or DoT if configured.
Step 2. The recursive resolver checks its own cache. If another user asked recently and the TTL hasn't expired, it answers immediately and the walk stops here. Cache hits are the majority of real-world traffic.
Step 3. On a miss, the resolver asks a root server. The root doesn't know blog.example.com, but it knows who runs .com, so it returns a referral to the .com TLD servers.
Step 4. The resolver asks a .com TLD server. That server returns a referral to the authoritative name servers for example.com.
Step 5. The resolver asks one of those authoritative servers for blog.example.com. The authoritative server returns the A record: an IP address, with a TTL.
Step 6. The recursive resolver caches the answer for the length of the TTL and returns it to your stub resolver.
Step 7. Only now does your laptop open a TCP connection to that IP and begin the TLS handshake. DNS is done. Everything interesting about the session is still ahead.
Four servers, one answer, usually in well under 100 milliseconds. The second person to ask gets it in single-digit milliseconds from cache.
Why the difference matters for security
Protective DNS lives at the recursive resolver
Every DNS filtering product intercepts at step 2. That position is what gives it power: the recursive resolver is the one point in the chain that sees every query from every device you've pointed at it, before any connection opens.
It's also what bounds it. The resolver sees a domain name and a record type. It doesn't see the path, the payload, the file, or the account, because none of that exists yet at step 2. We cover that boundary in detail in DNS-layer security: what it catches and what it structurally can't.
Position determines visibility. That's the single most useful thing to take from this post.
Authoritative DNS is a control you own, not a filter you apply
Your authoritative servers don't protect your users. They represent you to everyone else. Securing them means locking down registrar access, enabling registrar and registry locks, signing your zone with DNSSEC, and monitoring your records for unauthorized change.
An attacker who edits your authoritative records can point your domain anywhere, and every recursive resolver on the internet will faithfully hand that answer to your customers. That's DNS hijacking, and the fix lives at the authoritative side.
Cache poisoning targets the recursive side
Because recursive resolvers cache, an attacker who can get a forged answer accepted into a cache can redirect every user of that resolver for the life of the TTL. Source port randomization, transaction ID randomization, and DNSSEC validation are the defenses. This is why "just point at a public resolver" is a real security decision and not only a performance one.
Resolver configuration is an enforcement decision
If your users' devices can change which recursive resolver they use, your DNS policy is advisory. Browsers that default to DNS over HTTPS send queries straight past your resolver. Malware that hardcodes an IP address never asks at all.
Enforcing on the device rather than on the network closes that gap, which is one reason agent-based inspection ends up in the stack alongside DNS.
Where dope.security fits
We're not a DNS product, and this post isn't a pitch. For completeness: dope.security is an SSE platform whose agent runs an on-device SSL proxy, inspecting application and internet traffic locally instead of backhauling it to a data center. Because it inspects on the endpoint after the connection opens, it sees the things a recursive resolver structurally can't: the full URL, the file, and the tenant identifier inside a decrypted request.
Run both. DNS handles step 2. Inspection handles step 7.
Conclusion
Recursive DNS asks. Authoritative DNS answers. Security products that filter domains sit on the recursive side, which is why they see every query and why they see only the name.
If you want the layer that reads what comes after the lookup, start a free trial or book a 20-minute demo.
Frequently Asked Questions
What is recursive DNS?
Recursive DNS is the process where a resolver takes a client's query and asks other DNS servers in sequence, root, then TLD, then authoritative, until it has a definitive answer. A recursive DNS server performs that walk on behalf of clients and caches the result so the next identical query is answered instantly.
What is the difference between recursive and authoritative DNS?
A recursive DNS server asks other servers until it finds an answer and can answer for any domain. An authoritative DNS server holds the zone data for specific domains and answers only for those. Recursive servers cache; authoritative servers serve from their own records.
Which type of DNS server does DNS filtering use?
DNS filtering happens at the recursive resolver. That's the only point in the chain that sees every query from every device you've configured, before any connection opens. Authoritative servers only see queries for the domains they own, so they're the wrong place to filter your own users.
What are the types of DNS servers?
There are four: the stub resolver in your operating system, the recursive resolver that walks the hierarchy, the root and TLD servers that provide referrals, and the authoritative name server that holds the real zone data for a domain.
Is a public resolver like 1.1.1.1 recursive or authoritative?
Public resolvers such as 1.1.1.1, 8.8.8.8 and 9.9.9.9 are recursive. They accept queries from anyone, walk the hierarchy, cache aggressively, and return answers. Some of them, including Quad9, also apply threat blocklists at that recursive position.
Why does DNS recursion matter for cache poisoning?
Recursive resolvers cache answers to stay fast, so a forged response accepted into the cache is served to every client of that resolver until the TTL expires. Defenses include source port and transaction ID randomization, DNSSEC validation, and encrypted transport between client and resolver.
Can an authoritative DNS server be hijacked?
Yes. If an attacker gains access to your registrar account or your DNS hosting console, they can rewrite your records, and every recursive resolver on the internet will serve that answer as legitimate. Registrar locks, multi-factor authentication, DNSSEC signing, and record monitoring are the defenses.
Related reading
- What Is DNS Security? A Practical Guide for 2026
- DNS-Layer Security: What It Catches, and What It Structurally Can't
- DNS Attack Protection: The Threats DNS Security Actually Stops
- DNS Security Solutions Compared: Where Each One Stops
- URL Filtering vs DNS Filtering: What's the Difference?
- What Is a Secure Web Gateway?
.jpeg)
