Recursive vs authoritative DNS servers: who answers what

An authoritative DNS server holds the records for a zone and answers only for that zone. A recursive resolver does the legwork for clients: it asks other servers, follows referrals, caches what it learns and returns a final answer. Most DNS trouble comes from confusing the two roles.

The two roles in plain terms

The original DNS specification, RFC 1034, calls the client side a resolver and the data side a name server. A name server is authoritative for the zones it holds complete data for, and it may also cache data about other parts of the tree. Answers from authoritative data carry the AA bit, so a requester can tell them apart from cached answers.

A stub resolver on your laptop or in a container usually does no lookups itself. It hands the question to a recursive server and waits.

How a lookup walks the tree

Name servers must support iterative answers, which means they reply with a referral toward a closer server. Recursion is optional, and it is negotiated with the RD (recursion desired) and RA (recursion available) bits.

A cold lookup runs roughly like this:

1. The stub asks the recursive resolver for a name.
2. The resolver asks a root server, which refers it to the servers for the top level domain.
3. Those refer it to the servers for the zone that owns the name.
4. The authoritative server for that zone gives the answer, and the resolver caches it and passes it back.

A parent zone delegates a subtree by placing NS records at the zone cut. Those NS records are not authoritative data for the parent. If the delegated server's name sits below the cut, the parent also needs glue address records, or the resolver cannot reach it.

Why the split matters for operations

A few practical consequences follow from the design:

• You can run authoritative servers without offering recursion to anyone. Mixing the two on one public host is a common source of abuse and cache problems.
• RFC 1034 says every zone should be available from at least two servers, so one failure does not take the zone offline.
• When authoritative and cached data both exist for a name, authoritative data wins. Cached data is treated as good enough for normal use while its TTL counts down.
• A CNAME at a node means no other data should be present there. This is why you cannot put a CNAME at a zone apex that also needs SOA and NS records.

Where the attacks land

Attacks differ by role. Against a recursive resolver, the goal is usually to poison its cache so clients get a forged answer. Against authoritative infrastructure, the goals are availability attacks, tampering with zone data through stolen registrar or hosting credentials, or abusing dangling records. For related reading, see dangling DNS and subdomain takeover and DNS attack techniques and defenses.

When debugging, ask which role is failing. If the authoritative server answers correctly when queried directly but clients see something else, look at the recursive layer and its cache. If the authoritative answer itself is wrong, fix the zone.

Where Safeguard fits

Safeguard does not run your DNS, certificates or network routes. It covers the code around them: dependency and SBOM scanning, reachability analysis and policy gates for the libraries your applications use. You can try a free scan at gold.safeguard.sh/scan.

Quick check

Sources

• RFC 1034, Domain Names: Concepts and Facilities

Last reviewed: 19 October 2026.