DNS servers come in two fundamental flavors: authoritative servers that hold zone data, and recursive resolvers that fetch answers on behalf of clients. Understanding the distinction is essential for configuring, debugging, and securing DNS.
What Makes a Server Authoritative
An authoritative nameserver is the source of truth for a DNS zone. It has the actual zone data loaded — either from a zone file or a database — and can answer definitively for names in that zone.
The AA Flag
When an authoritative server responds to a query, it sets the AA (Authoritative Answer) flag in the DNS header:
; Response header
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
^^
Authoritative Answer flag is set
This flag tells the client: “This answer comes from the source of truth, not from a cache.”
Primary vs Secondary
Authoritative servers can be primary (master) or secondary (slave):
Primary server: Holds the original zone data. Edits happen here.
Secondary server: Receives zone data via zone transfer (AXFR/IXFR) from the primary. It’s authoritative too — it’s not a cache. Both primary and secondary servers set the AA flag.
Why use secondaries?
- Redundancy: If the primary fails, secondaries continue serving
- Geographic distribution: Place secondaries near users for lower latency
- Load distribution: Spread query load across multiple servers
What Authoritative Servers Don’t Do
Authoritative servers typically don’t:
- Cache data from other zones
- Perform recursive resolution
- Follow referrals
If you query an authoritative server for example.com about www.google.com, it should refuse or return a referral — it’s not authoritative for google.com.
How Recursive Resolvers Work
A recursive resolver does the heavy lifting of DNS resolution. When it receives a query, it doesn’t just check local data — it traverses the DNS hierarchy to find the answer.
The Recursive Algorithm
When a recursive resolver receives a query for www.example.com (and it’s not cached):
- Start at the root: Query a root server for
www.example.com - Follow the referral: Root says “ask
.comTLD servers” - Query the TLD: TLD says “ask
example.comnameservers” - Query authoritative: Get the actual answer
- Cache everything: Store the answer and intermediate referrals
- Return the answer: Send the final response to the client
The resolver does all this work so clients (stub resolvers) don’t have to. It’s called “recursive” because it recursively follows the delegation chain.
The RA Flag
When a resolver supports recursion, it sets the RA (Recursion Available) flag in responses:
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
^^
Recursion Available
Clients can check this flag to know if the server will do recursive resolution.
Caching Is the Killer Feature
Recursive resolvers cache aggressively. A busy resolver might cache millions of records. When a query hits the cache, the resolver responds immediately without any network traffic to authoritative servers.
This is why changing DNS records takes time to propagate — recursive resolvers worldwide have the old data cached.
Major Public Resolvers
Several organizations operate public recursive resolvers that anyone can use:
Google Public DNS (8.8.8.8 / 8.8.4.4)
Launched in 2009, Google’s resolver is one of the most widely used. IPv6 addresses: 2001:4860:4860::8888 and 2001:4860:4860::8844.
Features:
- DNSSEC validation
- DNS over HTTPS (DoH) at
dns.google - DNS over TLS (DoT)
- Global anycast deployment
Privacy: Google logs queries but anonymizes IP addresses after 24-48 hours. They do not block content.
Cloudflare DNS (1.1.1.1 / 1.0.0.1)
Launched in 2018 with a focus on privacy. IPv6: 2606:4700:4700::1111 and 2606:4700:4700::1001.
Features:
- DNSSEC validation
- DoH at
cloudflare-dns.com/dns-query - DoT on port 853
- Fastest resolver in many benchmarks
Privacy: Cloudflare commits to never logging client IP addresses. Query logs are purged within 24 hours. Audited by KPMG.
Family-friendly variants:
1.1.1.2/1.0.0.2— blocks malware1.1.1.3/1.0.0.3— blocks malware and adult content
Quad9 (9.9.9.9)
Non-profit resolver with built-in security. IPv6: 2620:fe::fe.
Features:
- DNSSEC validation
- Threat intelligence integration (blocks malicious domains)
- DoH and DoT support
Privacy: Quad9 does not log source IP addresses. They’re based in Switzerland with strong privacy protections.
OpenDNS (208.67.222.222 / 208.67.220.220)
Now owned by Cisco. Offers both free and enterprise tiers.
Features:
- Content filtering options
- Phishing/malware protection
- Custom blocklists (with account)
Comparison
| Resolver | Focus | Blocks Malware | Blocks Content |
|---|---|---|---|
| Google (8.8.8.8) | Performance | No | No |
| Cloudflare (1.1.1.1) | Privacy/Speed | Optional (1.1.1.2) | Optional (1.1.1.3) |
| Quad9 (9.9.9.9) | Security | Yes | No |
| OpenDNS | Filtering | Yes | Configurable |
Resolver Selection and Privacy
Your DNS resolver sees every domain you visit. This is a significant privacy consideration.
ISP Resolvers
By default, most home networks use ISP-provided resolvers (configured via DHCP). Issues:
- Privacy: ISPs can log and monetize your query data
- Censorship: Some ISPs block domains at the resolver level
- Performance: ISP resolvers may be slower or less reliable
Using Public Resolvers
Switching to a public resolver like 1.1.1.1 or 8.8.8.8 is easy:
Router level: Change DNS settings in your router to affect all devices
Device level: Configure DNS in network settings
Application level: Some browsers (Firefox, Chrome) support DoH with specific resolvers
Self-Hosting Resolvers
For maximum privacy, run your own recursive resolver:
- Unbound: Popular open-source resolver
- Pi-hole: DNS sinkhole for ad blocking with optional recursive resolution
- dnscrypt-proxy: Supports encrypted DNS protocols
Self-hosting means your queries go directly to authoritative servers — no third party sees all your DNS traffic.
EDNS Client Subnet (ECS)
Here’s a privacy/performance tradeoff: EDNS Client Subnet (RFC 7871).
The Problem
Consider a user in Tokyo querying through a recursive resolver in California. The authoritative server for a CDN sees the query coming from California and returns an IP address optimized for California — not Tokyo.
The user gets routed to a faraway server, increasing latency.
The Solution (and Tradeoff)
With ECS, the recursive resolver includes a portion of the client’s IP address in the query:
; Query with ECS
; CLIENT-SUBNET: 203.0.113.0/24
The authoritative server can now return Tokyo-optimized results. The CDN knows (approximately) where the actual client is located.
Privacy Implications
ECS reveals part of your IP address to authoritative servers. This erodes some privacy benefits of using a central resolver.
Different resolvers handle ECS differently:
- Google: Sends ECS by default
- Cloudflare: Does NOT send ECS (privacy-focused)
- Quad9: Does NOT send ECS
If you’re privacy-conscious, prefer resolvers that don’t send ECS. The latency tradeoff is usually minimal.
Running Both: Split Roles
Large organizations often run both authoritative servers and recursive resolvers:
- Authoritative servers: Serve the organization’s own zones to the internet
- Internal recursive resolvers: Serve employee queries, with caching and policy enforcement
These are separate services, sometimes on separate machines. A server can do both, but mixing roles complicates security and configuration.
Key Takeaways
- Authoritative servers hold zone data and set the AA flag
- Recursive resolvers traverse the DNS hierarchy and cache results
- Primary/secondary is an authoritative distinction; both are authoritative
- Major public resolvers include Google (8.8.8.8), Cloudflare (1.1.1.1), and Quad9 (9.9.9.9)
- Your resolver sees all your queries — choose based on privacy/performance needs
- EDNS Client Subnet trades privacy for geo-optimized responses
- Self-hosting a resolver maximizes privacy but requires maintenance
Understanding these roles clarifies how DNS queries flow and where to look when troubleshooting. In the next chapter, we’ll explore the root servers — the 13 identities that anchor the entire DNS hierarchy.