The one machine that actually holds the record
Authoritative means exactly one thing: when the question reaches this server, the answer it returns is final and carries no asterisk.
What authoritative actually means
Somewhere in every delegation chain there is a server that stops asking. Every other machine in the path — the stub inside the application, the recursive resolver at your ISP or in your data centre, the forwarders stacked in between — holds a copy, a guess, or a cached approximation. The authoritative server holds the record itself, and it holds it because a human or a provisioning system put it there deliberately.
The IANA ↗ definition is functional rather than philosophical: an authoritative nameserver is the one listed in the NS records for a zone, and the one whose SOA record names that zone as its own. When a resolver receives an answer with the AA bit — the Authoritative Answer flag — set in the DNS message header, it knows the machine that responded is not relaying from cache. It is reading from its own data. That flag is defined in RFC 1035, section 4.1.1 ↗, and it has not changed in meaning since 1987.
What can change, and often does, is whether the server deserves that flag. An authoritative server that has loaded a stale zone file, or that is running as a secondary whose last successful transfer was three days ago, will still set the AA bit. The bit reflects the server's role, not the freshness of its data. This is not a flaw in the protocol — it is a reason to care about operational hygiene at the zone level rather than trusting the flag alone.
The corollary matters just as much: a recursive resolver must never set the AA bit on an answer it assembled from cache. When it does, something has gone badly wrong with the implementation or the configuration. The resolver's job is to ask on behalf of a client and believe what authoritative servers tell it, then report that answer with its AA bit clear. Conflating the two roles — answering authoritatively for a zone while also resolving queries for outside zones — is not illegal, but it puts pressure on code paths that were not designed to share state, and it creates the conditions for cache poisoning.
The path that ends here
A query starts with a stub resolver that typically knows only the address of a recursive resolver, nothing more. The recursive resolver knows the root hints: a small static list of addresses for the root servers, published and maintained by IANA and updated when operators need it. From there it descends the tree, collecting referrals. Each referral hands it a new set of NS records and, where the nameserver names fall inside the delegated zone, glue records carrying the corresponding addresses. Every step is a referral until the step is not — until the server that receives the query sets the AA bit and returns data from its own zone.
That moment of finality is where the authoritative server's configuration becomes the ground truth for everyone downstream. The recursive resolver will cache what it receives, bounded by the TTL on each record. Clients behind that resolver will see the cached copy. If the authoritative server is wrong — wrong address, wrong TTL, wrong record type — every copy propagates that wrongness faithfully and efficiently. The resolver's cache does not validate; it trusts. DNSSEC can provide a cryptographic chain of custody from the root zone down to the signed record, but DNSSEC validates the signature, not the intent behind the data. Signing a wrong record makes it a verifiably wrong record.
This is why the authoritative tier is where configuration errors do their worst damage quickly. A typo in a recursive resolver's configuration might affect the operator's own resolution. A typo in an authoritative zone file — published and signed and served — propagates to every resolver that caches the answer, across every ISP, cloud edge and enterprise forwarder that has queried for it, and stays there until each cached copy individually expires.
What the server actually does, and what it does not
An authoritative server receives a query, looks up the question in its zone data, and returns whatever it finds. That sounds simple, and in well-designed implementations it nearly is. NLnet Labs' NSD was built explicitly on this constraint: authoritative-only, no cache, no recursion, small attack surface. Knot DNS from CZ.NIC takes a similar position on separation. ISC's BIND and PowerDNS can serve both roles, which is useful and also the source of an entire category of misconfiguration where a server answers recursively for queries it should be refusing.
The authoritative server does not follow CNAME chains outside its own zone. It does not retry. It does not ask anyone else. If the question names a record in a zone it has loaded, it answers. If the question names a record in a zone it has not loaded, it returns a REFUSED or a SERVFAIL depending on implementation and configuration. The moment it starts chasing answers on behalf of clients, it has become a resolver — and if it does that without the protections a purpose-built resolver carries, it is an open resolver, which is a separate and serious operational problem.
Lame delegation is what happens when the parent zone's NS records point at a server that has not loaded the zone in question. The authoritative flag never gets set because the server has nothing to be authoritative about. The resolver gets a SERVFAIL or a referral that leads nowhere, and the zone is effectively unreachable for the TTL duration of the bad delegation. This is not an exotic failure; it is one of the most common causes of complete zone outages, and it is entirely invisible from the authoritative server's own logs the queries it receives are simply refused, which is correct behaviour for a machine that does not hold the zone, so nothing in its logs looks like a fault.
When a resolver receives an answer with the AA bit — the Authoritative Answer flag — set in the DNS message header, it knows the machine that responded is not relaying from cache.
The secondary side of authoritative service adds its own surface for error. A secondary is authoritative for a zone it received via zone transfer from a primary. It will serve that zone, AA bit set, until the SOA's expiry timer runs out — even if the primary has been unreachable for days and the data is ageing badly. Zone transfers are triggered by SOA serial comparison: if the serial on the primary has not increased, the secondary assumes nothing has changed and does not pull. An operator who edits a zone file without incrementing the serial has, from every secondary's perspective, done nothing at all. The secondaries serve the old version, confidently and correctly, until the serial moves.
These failure modes — lame delegation, stale secondaries, silent misconfiguration on a mixed recursive-authoritative server — share a structural cause. The authoritative server is the end of the chain. There is no further layer to catch what it gets wrong. A recursive resolver has retries, fallback, multiple server addresses to try. The authoritative server has the data or it does not, and if it does not the query dies there. Getting the authoritative tier right is not the glamorous part of DNS operations, but it is the part where the errors are most total and the propagation is fastest.
Getting the authoritative tier right is not the glamorous part of DNS operations, but it is the part where the errors are most total and the propagation is fastest.