# Authoritative vs Recursive Resolvers Canonical: https://learndns.org/learn/2-5-authoritative-recursive/ > Understanding the two types of DNS servers — authoritative nameservers and recursive resolvers — and how they work together. 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): 1. **Start at the root**: Query a root server for `www.example.com` 2. **Follow the referral**: Root says "ask `.com` TLD servers" 3. **Query the TLD**: TLD says "ask `example.com` nameservers" 4. **Query authoritative**: Get the actual answer 5. **Cache everything**: Store the answer and intermediate referrals 6. **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 malware - `1.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.