Recursive Resolver
The workhorse of everyday DNS. A recursive resolver accepts queries from clients and does whatever it takes to find a definitive answer — querying root servers, TLD servers, and authoritative nameservers on your behalf.
The "Full-Service" Resolver
When your browser needs to resolve thedns.guru into an IP address, the request goes first to a recursive resolver — typically the one configured by your DHCP server or manually set in your network settings.
Unlike stub resolvers (the minimal resolver built into your operating system), a recursive resolver will follow the DNS delegation tree from root to TLD to authoritative nameserver until it has a definitive answer. It then caches the result for the record's TTL and returns it to the client.
The word "recursive" refers to the DNS RECURSION DESIRED (RD) flag in the query, which tells the resolver to perform this full lookup on the client's behalf rather than returning a referral.
How a Recursive Resolver Works
Step-by-step resolution when no cache entry exists
Client sends a query
Your OS stub resolver sends a UDP (or TCP) DNS query to the configured recursive resolver, typically on port 53. The query sets the RD (Recursion Desired) bit to 1.
Resolver checks its cache
The resolver first looks up the QNAME in its local cache. If a valid (non-expired) entry exists — positive or negative — it returns it immediately without any upstream queries.
Priming / Root hints query
On a cache miss, the resolver consults its root hints file to find the addresses of root nameservers. If the resolver's cache of root NS records has expired, it performs a "priming query" to refresh them.
Iterative queries down the hierarchy
The resolver queries a root nameserver for the QNAME. The root returns a referral to the TLD nameservers. The resolver then queries the TLD, which refers it to the authoritative nameservers. Finally, the authoritative NS returns the answer.
DNSSEC validation (if enabled)
Validating resolvers verify the chain of trust from the IANA root KSK through the zone's RRSIG and DNSKEY records. If validation fails, SERVFAIL is returned to the client.
Cache the response, return to client
The resolver stores each response in its cache keyed by (QNAME, QTYPE, QCLASS) for the record's TTL. The answer is returned to the client. Subsequent queries for the same name are served from cache.
Cache Behavior & TTL
Caching is what makes DNS fast at scale
Successful DNS responses are cached for the record's TTL. During this window any identical query is answered from cache without contacting upstream servers.
NXDOMAIN (name does not exist) responses are also cached, up to the SOA minimum TTL or the value in the AUTHORITY section — whichever is smaller.
Some resolvers can serve expired cache entries for a configurable window while re-validating in the background, reducing latency during upstream outages.
Resolvers may enforce a minimum TTL (e.g., 30 seconds) to prevent cache thrashing, and a maximum TTL to limit stale data. These are configurable in resolver software.
Choosing a Recursive Resolver
Popular third-party options beyond your ISP's default
Privacy-first resolver that does not log querier IPs. Consistently fastest globally. Also offers 1.1.1.2 (malware blocking) and 1.1.1.3 (malware + adult content).
Largest DNS service by query volume. Strong anycast network with global coverage. Logs limited metadata for 48 hours and anonymized data for longer-term analysis.
Security-focused resolver that blocks malicious domains using 25+ threat intel feeds. Non-profit operated. Strong privacy policy with no IP logging.
Offers both a free tier and enterprise FamilyShield (adult content filtering). One of the earliest public DNS services. Supports DNSSEC validation.
Fully configurable cloud-based resolver with per-device logs, blocklists, parental controls, and analytics. Free tier available; paid plans for higher query volume.
Default for most home users. Performance varies widely by provider. Typically located geographically close to you. May inject ads on NXDOMAIN or log queries.
DNS-over-? — Encrypted Resolver Protocols
Classic DNS sends queries in plaintext. These protocols add encryption.
| Protocol | Port | Standard | Notes |
|---|---|---|---|
| DNS (classic) | 53 | RFC 1035 | UDP preferred; falls back to TCP for responses > 512 bytes or with EDNS(0). |
| DNS-over-TLS (DoT) | 853 | RFC 7858 | Wraps DNS in TLS. Dedicated port — easy for network admins to block. |
| DNS-over-HTTPS (DoH) | 443 | RFC 8484 | Sends DNS queries as HTTPS POST/GET. Blends with web traffic; hard to block. |
| DNS-over-QUIC (DoQ) | 853 | RFC 9250 | Uses QUIC transport (0-RTT resume). Lowest latency encrypted option. |
| DNSCrypt | 443 / 5443 | — | Older protocol by OpenDNS. Not an IETF standard but widely deployed. |
Testing Your Recursive Resolver
Useful commands for querying and debugging resolver behavior
Query a specific resolver
Inspect resolver cache
Trace the full resolution
Test DoH endpoint
Related Topics
The first stop in iterative resolution — recursive resolvers query root servers to find TLD nameservers.
Authoritative NameserverThe final answer comes from authoritative nameservers, which recursive resolvers cache and serve to clients.
Cache PoisoningResolver caches are the primary target of poisoning attacks — DNSSEC validation is the defense.