When you type a domain name into your browser, two fundamentally different types of DNS servers spring into action to turn that name into an IP address. One knows the answer. The other knows how to find it. Understanding the difference between these two roles, authoritative and recursive, is the key to understanding how DNS actually works, and why certain problems happen the way they do.
This distinction explains why DNS propagation takes time, why some users can reach a site while others can't, how DNS caching works, and why certain attacks target one type of server over the other. If you've ever been confused about DNS behavior, the authoritative versus recursive distinction is usually at the heart of it.
This guide explains both roles, how they work together, and why the difference matters.
The Two Roles in DNS
DNS resolution involves two distinct types of servers with different jobs:
Authoritative DNS servers hold the actual DNS records for a domain. They are the source of truth. When an authoritative server for yourcompany.com is asked for that domain's records, it answers from its own configured data. It's "authoritative" because it has the real, definitive answer.
Recursive DNS servers (also called recursive resolvers) don't hold any domain's records themselves. Instead, they do the work of finding answers by querying authoritative servers on behalf of clients. When your computer needs to resolve a name, it asks a recursive resolver, which then goes and finds the answer.
An analogy: imagine you want to know a fact from a specific book. The authoritative server is the library that holds that exact book. The recursive resolver is the research assistant who knows how to navigate the library system, find the right library, locate the book, and bring you the answer. You ask the assistant (recursive), and they consult the library (authoritative).
How Recursive Resolution Works
When you type www.yourcompany.com into your browser, here's what the recursive resolver does on your behalf:
- Your device asks the recursive resolver (usually your ISP's resolver, or a public one like 8.8.8.8 or 1.1.1.1): "What is the IP for www.yourcompany.com?"
- The resolver asks a root server: "Where can I find information about .com domains?" The root server responds with the addresses of the .com TLD nameservers.
- The resolver asks a .com TLD server: "Where can I find information about yourcompany.com?" The TLD server responds with the authoritative nameservers for yourcompany.com.
- The resolver asks the authoritative server: "What is the IP for www.yourcompany.com?" The authoritative server responds with the actual answer.
- The resolver returns the answer to your device, and your browser connects to that IP.
This process is called recursion because the resolver keeps asking questions until it reaches the authoritative source. The resolver does all this work so your device doesn't have to. Your device makes one simple request and gets one answer.
The DNS Hierarchy
The recursive resolution process follows the hierarchical structure of DNS, which reads from right to left:
- Root zone (.): The top of the hierarchy. Root servers know where the TLD servers are. There are 13 root server addresses (operated via anycast across hundreds of physical servers worldwide).
- Top-Level Domain (TLD) servers: Handle .com, .org, .net, country codes like .uk and .de, and so on. They know which authoritative servers handle each domain under their TLD.
- Authoritative servers: Hold the actual records for individual domains. This is where your domain's A, MX, TXT, and other records live.
Each level only knows about the level below it. The root doesn't know your website's IP. It only knows where .com is. The .com servers don't know your IP either. They only know where your domain's authoritative servers are. Only your authoritative servers know the actual answer.
The Role of Caching
If recursive resolvers performed the full resolution process for every single query, DNS would be slow and the root and TLD servers would be overwhelmed. Caching solves this.
When a recursive resolver gets an answer, it caches that answer for a period of time defined by the record's TTL (Time to Live). Subsequent queries for the same record are answered from the cache without repeating the full resolution process.
This caching is why:
- DNS is fast: Most queries are answered from cache in milliseconds.
- DNS propagation takes time: When you change a record, recursive resolvers around the world keep serving the cached old value until their TTL expires. We covered this in detail in our DNS propagation guide.
- Different users see different results during changes: Resolvers cached your record at different times, so they expire and refresh at different times.
Authoritative servers don't cache in the same way. They always serve the current configured records. The caching happens at the recursive resolver layer.
Key Differences Summarized
| Property | Authoritative | Recursive |
|---|---|---|
| Holds domain records | Yes | No |
| Finds answers for clients | No | Yes |
| Caches answers | No | Yes |
| Source of truth | Yes | No |
| Who operates it | Domain owner / DNS provider | ISP / public resolver / org |
| Examples | Cloudflare, Route 53 (hosting your zone) | 8.8.8.8, 1.1.1.1, ISP resolvers |
| Configured by | You (your records) | Whoever runs the resolver |
Where the Confusion Comes From
Some providers, like Cloudflare and Google, operate both authoritative and recursive services, which adds to the confusion. For example:
- Cloudflare DNS (1.1.1.1) is a public recursive resolver that anyone can use to resolve names.
- Cloudflare's authoritative DNS is a separate service that hosts your domain's records if you use Cloudflare as your DNS provider.
These are different products serving different roles, even though they come from the same company. When someone says "I use Cloudflare DNS," they might mean either the recursive resolver (1.1.1.1) or the authoritative hosting, depending on context.
Similarly, Google operates both Google Public DNS (8.8.8.8, recursive) and Google Cloud DNS (authoritative hosting). Same company, different roles.
Why the Difference Matters for Security
The two server types face different threats:
Threats to Authoritative Servers
- Unauthorized record changes: If an attacker gains access to your authoritative DNS (through a compromised provider account or registrar), they can change your records, redirecting traffic and email. This is DNS hijacking.
- DDoS attacks: Authoritative servers can be targeted to make a domain unresolvable. They can also be abused as reflectors in amplification attacks.
- Lame delegation: If your authoritative servers aren't correctly configured to serve your zone, resolution fails.
Threats to Recursive Resolvers
- Cache poisoning: An attacker tricks a recursive resolver into caching a false record, redirecting all users of that resolver to a malicious destination. DNSSEC defends against this by letting resolvers verify authenticity.
- Open resolver abuse: Recursive resolvers that answer anyone's queries can be abused in amplification attacks.
- Resolver hijacking: Malware can change a device's configured resolver to a malicious one that returns false answers.
Understanding which server type is involved helps diagnose and defend against the right threats. If users are being redirected, is it because your authoritative records were changed (hijacking) or because a resolver was poisoned (cache poisoning)? The answer determines your response.
How DNS Assistant Fits
DNS Assistant monitors your authoritative DNS, the source of truth for your domains, by checking what resolvers actually receive when they query your records. This dual perspective matters:
- Authoritative record monitoring: DNS Assistant tracks the records your authoritative servers are configured to serve, alerting you when they change. This catches unauthorized changes to your source of truth.
- Resolution verification: By querying your records the way a recursive resolver would, DNS Assistant confirms that your authoritative servers are responding correctly and that resolution works end to end.
- NS delegation monitoring: DNS Assistant verifies that your authoritative nameservers are correctly delegated and responding, catching lame delegation issues.
- DNSSEC validation: DNS Assistant validates the chain of trust that lets recursive resolvers verify your authoritative records are authentic.
Whether an issue originates at your authoritative servers, in the delegation chain, or in how records resolve, DNS Assistant gives you visibility into the health of your DNS from source to resolution.
Check Your DNS
Use the DNS lookup tool at dnsassistant.com/tools to query your domain's records and see how they resolve, including your authoritative nameservers (NS records). Run a Free Domain Risk Report for a comprehensive view of your DNS configuration.
For continuous monitoring of your authoritative DNS with real-time alerting, sign up at dnsassistant.com.
Top comments (0)