DNS Records & Concepts
What is recursive DNS?
Recursive DNS is the process by which a DNS resolver takes on the full responsibility of resolving a domain name query on behalf of a client, querying multiple servers in the DNS hierarchy until it finds the definitive answer and returns it. When a browser asks a recursive resolver to look up example.com the resolver does not simply say “I don’t know, ask someone else”, it performs all the necessary queries itself, working through root nameservers, TLD nameservers, and authoritative nameservers in sequence until it has the answer.
The word recursive describes the resolver’s commitment to the client, it takes the query and recursively follows the DNS delegation chain until resolution is complete, then returns a final answer. This stands in contrast to iterative DNS resolution where a server responds to each query with either the answer or a referral to another server, leaving the client to make the next query itself.
Recursive DNS is how virtually all end-user DNS resolution works. When a browser on a home network resolves a domain name the device sends one query to the ISP’s resolver or a public resolver like 1.1.1.1. The resolver handles everything from there, querying root nameservers, following referrals to TLD nameservers, reaching the authoritative nameserver, and returning the final answer. The browser asks one question and gets one answer. The recursive resolver does all the work in between.
How recursive DNS resolution works
The recursive resolution process follows a specific path through the DNS hierarchy. Each step either returns the answer or provides information about where to find it, guiding the resolver closer to the authoritative source.
Initial query from client: a browser or application sends a DNS query to its configured recursive resolver. The query specifies the domain name, example.com: and the record type, typically A for an IPv4 address. The client’s role ends here. Everything that follows is the resolver’s responsibility.
Resolver cache check: before making any external queries the resolver checks its cache. If it resolved the same domain recently and the cached result has not expired it returns the cached answer immediately. No external queries needed. This is the most common outcome for popular domains, the resolver’s cache absorbs the vast majority of queries.
Root nameserver query: if the resolver has no cached result it queries one of the root nameservers. The resolver maintains a built-in list of root nameserver addresses, the hints file, updated periodically. Root nameservers do not know the IP address for example.com but they know which nameservers are authoritative for .com. They return a referral, the NS records and glue A records for the .com TLD nameservers.
TLD nameserver query: the resolver queries one of the .com TLD nameservers returned in the previous step. The TLD nameserver knows which nameservers are authoritative for example.com: the domain was registered with this information when the domain was created. The TLD nameserver returns the NS records for example.com: the specific nameservers delegated to handle DNS for that domain.
Authoritative nameserver query: the resolver queries one of the authoritative nameservers for example.com. The authoritative nameserver holds the zone data, the actual DNS records configured by the domain owner. For an A record query it returns the IP address, 93.184.216.34: and the TTL value.
Response caching and return: the resolver caches the response for the TTL duration and returns the IP address to the client. The client uses the IP address to establish a connection. The recursive resolution is complete.
The full recursive process, querying root, TLD, and authoritative nameservers, typically completes in 20 to 100 milliseconds. With caching most queries complete in microseconds.
Recursive vs iterative DNS resolution
The distinction between recursive and iterative DNS resolution clarifies the different roles that resolvers and authoritative nameservers play.
Recursive resolution: the resolver takes full responsibility for finding the answer. The client sends one query and receives one final answer. The resolver performs all intermediate queries, to root nameservers, TLD nameservers, authoritative nameservers, without the client being involved. The resolver bears the computational and network cost of the full resolution process. This is how recursive resolvers, the servers that end users communicate with, operate.
Iterative resolution: a server responds to each query with either the final answer or a referral, pointing to another server that might know the answer. The querying party must follow up with the referred server itself. Root nameservers and authoritative nameservers operate iteratively, when a recursive resolver queries them they either return the answer or refer to another server rather than performing the lookup themselves.
In practice recursive and iterative resolution work together. The client uses recursive resolution, sending one query to its resolver and expecting a complete answer. The resolver uses iterative resolution to work through the DNS hierarchy, querying root nameservers, following referrals to TLD nameservers, following further referrals to authoritative nameservers. The resolver combines iterative queries at each level to deliver a recursive result to the client.
The recursive resolver’s relationship to authoritative nameservers
Recursive resolvers and authoritative nameservers serve complementary but distinct roles in the DNS infrastructure. Understanding the relationship between them explains how the DNS system distributes its workload.
Authoritative nameservers: hold the definitive DNS records for specific DNS zones. They answer queries about the zones they are responsible for with authoritative answers, not cached copies but the current zone data. Authoritative nameservers do not perform recursive lookups, they only answer questions about their own zones and refer to other nameservers for everything else.
Recursive resolvers: perform lookups on behalf of clients by querying multiple nameservers. They cache results to avoid repeating lookups. They do not hold zone data, they are clients of authoritative nameservers rather than holders of authoritative information.
The workload division is efficient. Authoritative nameservers only need to handle queries about their own zones, a fraction of the total DNS query volume. Recursive resolvers absorb the enormous volume of client queries and handle most of them from cache. Only a small fraction of queries, cache misses, require the resolver to query authoritative nameservers directly.
Recursive DNS and caching
Caching is inseparable from recursive DNS resolution. Without caching every query would require the full recursive resolution process, querying root nameservers, TLD nameservers, and authoritative nameservers, for every single lookup. The query volume to authoritative nameservers would be impossibly large.
DNS caching allows recursive resolvers to store the results of previous lookups and serve them to subsequent queries without any external resolution. A resolver that has recently looked up example.com serves all subsequent queries for example.com from its cache until the cached record expires. The authoritative nameserver for example.com sees only a small fraction of the total query volume, the cache misses.
The effectiveness of resolver caching depends on two factors, the DNS TTL and the resolver’s query volume. Higher TTLs mean records are cached longer, fewer cache misses and fewer queries to authoritative nameservers. Higher query volumes for the same domain mean a cached record is shared among more queries, each cached lookup absorbs more queries before expiring.
The relationship between recursive DNS caching and DNS propagation is the primary reason DNS changes do not take effect globally and instantly. Cached records in recursive resolvers worldwide continue to be served until their TTL expires. The propagation window, the period during which some resolvers serve old cached values while others have fetched updated values, is determined by the TTL that was set on the record before the change was made.
Recursive DNS query flags
DNS queries include flags that specify the resolution behaviour expected by the client. The RD flag, Recursion Desired, is the flag that tells a resolver whether the client wants recursive resolution.
RD flag set: the client wants the resolver to perform recursive resolution, finding the full answer and returning it. This is the flag set in virtually all client queries to recursive resolvers. The resolver performs the full recursive process and returns a complete answer.
RD flag not set: the client does not want recursive resolution. It wants either the authoritative answer, if the resolver is authoritative for the zone, or a referral to another server. This is how iterative queries work. DNS tools like dig can send non-recursive queries for diagnostic purposes.
The RA flag, Recursion Available, is set in DNS responses by resolvers that support recursive resolution. It tells the client that recursive queries are supported. Most recursive resolvers set the RA flag in all responses.
dig for non-recursive query: the +norecurse option in dig sends queries with the RD flag unset:
This returns whatever the queried server has cached or is authoritative for without triggering recursive resolution. Useful for diagnosing what a specific resolver currently has cached for a domain.
Recursive DNS and DNSSEC validation
Recursive resolvers play a critical role in DNSSEC, DNS Security Extensions, validation. DNSSEC adds cryptographic signatures to DNS records allowing resolvers to verify that responses have not been tampered with.
Validating resolvers: recursive resolvers that perform DNSSEC validation check the cryptographic signatures on DNS records as part of the resolution process. If a record’s signature does not verify correctly, because the record was modified in transit or forged, the validating resolver rejects the response rather than caching and serving it.
Validation chain: DNSSEC validation follows the same delegation hierarchy as DNS resolution itself. The root zone is signed. Each TLD zone is signed and has its public key published in the root zone. Each registered domain can be signed with its public key published in the TLD zone. A validating resolver follows this chain of trust from the root downward to verify the signatures on records.
Validation failure behaviour: when a validating resolver cannot verify a DNSSEC signature it returns SERVFAIL to the client rather than the unverified record. From the client’s perspective the lookup fails, a different experience from NXDOMAIN which indicates a non-existent domain. SERVFAIL from a DNSSEC validation failure requires investigation of the DNSSEC configuration on the authoritative nameserver.
Non-validating resolvers: resolvers that do not perform DNSSEC validation forward DNSSEC signatures in responses but do not check them. Clients can perform their own validation using the signatures in the response, stub validation, but most browsers and applications do not implement this. The security benefit of DNSSEC depends on validating resolvers being in the resolution path.
Open recursive resolvers and security risks
An open recursive resolver is a resolver that answers recursive queries from any IP address, not just from specific authorised clients. Open resolvers are a security concern for two main reasons.
DNS amplification attacks: DNS queries are small, typically 30 to 60 bytes. DNS responses for certain query types, particularly ANY queries, can be very large, hundreds to thousands of bytes. An attacker who sends small spoofed queries with a victim’s IP address as the source to open resolvers receives large responses directed at the victim, amplifying the attack traffic significantly. Open resolvers that respond to ANY queries from any source are unwitting participants in these attacks.
Responsible resolver operators restrict recursive query access, accepting queries only from specific IP ranges such as their own customers or internal networks, and rate-limit responses to prevent amplification attack participation.
Cache poisoning surface: open resolvers that accept queries from arbitrary sources have a larger attack surface for cache poisoning. Attackers can send crafted queries to open resolvers attempting to trigger poisoning conditions. Restricting resolver access to authorised clients reduces this surface.
Major public resolvers, 8.8.8.8, 1.1.1.1, 9.9.9.9: are intentionally open, they provide public DNS resolution as a service. They mitigate the associated risks through rate limiting DNSSEC validation and other security measures rather than by restricting access.
Recursive DNS in redirect management
Recursive DNS resolution is the foundation on which redirect management operates, the process that routes visitors to redirect infrastructure before any HTTP redirect can be served.
Full resolution for new visitors: a visitor who has never visited a domain performs the full recursive resolution process, root nameserver query, TLD nameserver query, authoritative nameserver query, before any connection to the redirect infrastructure is established. The recursive resolution adds 20 to 100 milliseconds of latency before the first HTTP request can be made.
Cached resolution for returning visitors: a visitor who has recently visited the domain, or whose resolver has recently resolved it for any other client, receives the cached result immediately. The recursive resolution cost is eliminated for subsequent visits within the TTL window.
Resolver propagation during domain connection: when a domain is connected to redirect infrastructure by updating DNS records the updated records propagate to recursive resolvers as their cached copies of the old records expire. Different resolvers receive updated records at different times depending on when they last cached the old records and what TTL was set. The full recursive resolution process fetches the updated record from the authoritative nameserver after the cached old record expires.
TTL management for redirect setup: lowering TTL before connecting a domain to redirect infrastructure accelerates the propagation of the updated records to recursive resolvers worldwide. A TTL of 300 seconds means recursive resolvers fetch updated records within five minutes of the TTL change propagating. This minimises the window during which some visitors are routed to the old server while others reach the redirect infrastructure.
Checking recursive resolution behaviour
Several tools and techniques help observe how recursive DNS resolution is working for a domain.
dig +trace: follows the full recursive resolution process step by step showing every query and response in the chain, from root nameserver referral through TLD nameserver referral to authoritative nameserver answer:
This output shows exactly which nameservers were queried at each step what they returned and how the resolver followed the delegation chain to reach the authoritative answer. Invaluable for diagnosing delegation issues misconfigured NS records and unexpected resolution paths.
dig +norec: queries a resolver without requesting recursive resolution, showing what the resolver has cached rather than triggering a fresh recursive lookup:
If the resolver has the record cached it returns it. If it does not it returns a referral, which nameserver to query next, without performing the recursive lookup itself.
Comparing recursive resolver results: querying multiple public resolvers shows what each has cached and whether propagation has reached them:
Consistent results across resolvers indicate propagation is complete. Differences indicate propagation is still in progress, some resolvers have the new record while others still have the cached old value.