Skip to content

Recursive DNS lookup

A stub resolver never sees the four-step walk the previous article traced with dig +trace. It sends one query and gets back one answer — success, or a clear failure like NXDOMAIN. Nothing about a root server, a .com referral, or example.com's own name servers ever reaches it. That single-request, single-response experience is what a recursive lookup actually is: not the absence of complexity, but a server agreeing to absorb all of it on the client's behalf.

The RD and RA flags, in practice

The command-line tools module already introduced dig's flags line without dwelling on what each letter promises. Two of them are the whole mechanism recursion runs on:

dig example.com A

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
  • rd (Recursion Desired) — set by the client, in the query. It's a request: "if you don't have the answer yourself, go get it for me." A stub resolver sets this bit automatically on every query it sends; you're not choosing it by hand in normal use.
  • ra (Recursion Available) — set by the server, in the response. It's a promise, not an echo: "yes, I'm willing to do that work." A server can receive a query with rd set and still refuse — some authoritative-only servers do exactly that, since chasing referrals on a stranger's behalf isn't their job.

Put those two bits together and a recursive resolver's actual contract becomes precise: given rd, and willing to honor it (ra), it performs however many queries the previous article's four-step walk required — root, then TLD, then authoritative — entirely on its own, and only replies once it has a real answer or has exhausted every avenue and can report a genuine failure.

What "doing the work" costs the resolver

None of that work is free. A cache miss against an unfamiliar domain means the resolver itself becomes the client in several new queries — to a root server, then a TLD server, then an authoritative server — before it can answer the one query it originally received. That's real latency stacked in front of the client's request, and it's exactly why the caching behavior the previous article described matters in production: a resolver serving a large user base amortizes that cost across everyone, since the second person to ask for a popular domain gets the cached answer immediately, no walk required.

This is also the reason public recursive resolvers like 1.1.1.1 and 8.8.8.8 are worth reaching for specifically, and not just as a personal preference. A resolver with a large, constantly-refreshed cache across millions of users has already done the walk for almost any popular domain before you ask — a query that would take four hops on a cold resolver often comes back from a warm one in a single round trip.

When "open to anyone" becomes a liability

Recursion being available is the whole point for a resolver meant to serve clients — but not every DNS server should offer it, and one specific misconfiguration turns a helpful default into an attack vector: an open resolver, a recursive DNS server that answers recursive queries from any source on the internet rather than restricting itself to a known set of clients, like an organization's own network.

The abuse pattern is straightforward once you see it. According to Imperva, an open resolver doesn't authenticate where a query actually came from, "which means they respond to requests from anywhere on the internet" — and DNS runs over UDP, which the previous article already established has no connection handshake to verify a sender's address against. An attacker spoofs the source address on a DNS query, putting the victim's IP in that field instead of their own, and sends it to an open resolver. The resolver does exactly what recursion promises: performs the lookup and sends the full answer — to the spoofed address, not the attacker. Imperva gives a concrete figure for how lopsided that exchange can be: a roughly 60-byte query can produce a response up to 4,000 bytes, "an amplification factor of approximately 66.7" — meaning an attacker's own modest bandwidth gets multiplied into a flood the victim actually receives, a pattern known as a DNS amplification attack.

Don't run a resolver that answers the whole internet

A DNS server you operate — for a home lab, an internal service, or anything else — should only accept recursive queries from networks you control. Most resolver software (BIND, Unbound, dnsmasq) restricts recursion by default or makes it one explicit configuration line to lock down; leaving it open to 0.0.0.0/0 turns your server into free infrastructure for attacking someone else, often without you noticing until an upstream provider flags the traffic.

Practice exercises

  1. Run dig <any-domain> A against your system's default resolver and check whether the response includes ra in the flags line. Then try the same query against a server you'd expect to answer authoritatively only, and compare.
  2. Explain, in your own words, why a spoofed source address is a prerequisite for DNS amplification — what would happen to the attacker's spoofed request if UDP required a handshake first, the way TCP does?
  3. A colleague proposes running a recursive resolver on a cloud VM's public IP, reachable from anywhere, "for convenience." Using the open-resolver risk above, explain what you'd change about that plan before deploying it.

Recursion is what a resolver promises a client. The next article looks at the other side of the same exchange — what the root, TLD, and authoritative servers actually did in the four-step walk, none of which offered anything close to what recursion provides.

Sources