Authoritative DNS is the part of the DNS system that holds the original records of a zone and answers definitively for the names in it. When an authoritative name server responds, it sets the Authoritative Answer (AA) flag, signaling that the data comes from the zone itself rather than from a cache.
In DNS, authoritative servers form one side of a two-part design. Recursive resolvers look names up on behalf of clients and cache the results, while authoritative servers publish the data and never perform lookups for others. Every domain on the Internet depends on at least two authoritative servers being reachable.
How authoritative DNS fits into a lookup
A DNS lookup follows the delegation chain from the root down. A resolver that knows nothing about example.com asks a root server, which refers it to the .com servers through NS records. The .com servers in turn refer it to the authoritative servers listed for example.com, and those return the final answer.
Each step is a referral or an answer. Root and top-level domain servers are themselves authoritative, but only for their own zones; for lower names they return delegations. When a referral names servers inside the delegated zone, the parent also returns glue records, the IP addresses needed to reach those servers, to avoid a circular dependency.
| Response | Meaning | Key flags or sections |
|---|---|---|
| Authoritative answer | Record exists in the zone | AA flag set, answer section filled |
| Referral | Name lies in a delegated child zone | NS records in authority section, glue |
| NXDOMAIN | Name does not exist | AA flag, SOA in authority section |
| NODATA | Name exists, type does not | NOERROR with empty answer |
| REFUSED | Server is not authoritative for the zone | No data returned |
Primary, secondary and hidden primary setups
Zone data is usually edited on one primary server and copied to secondary servers through zone transfers. A full transfer (AXFR) copies the entire zone, while an incremental transfer (IXFR) sends only changes. NOTIFY messages tell secondaries to fetch updates immediately instead of waiting for the refresh interval in the SOA record.
Many operators use a hidden primary: the primary is not listed in NS records and is not reachable by the public, so it only feeds the public secondaries. This protects the editing system from attacks and lets the public servers be replaced without touching the source of truth. Transfers should be restricted by IP and authenticated with TSIG keys.
| Role | Function | Publicly listed in NS |
|---|---|---|
| Primary | Holds editable master copy | Yes, unless hidden |
| Hidden primary | Master copy behind the scenes | No |
| Secondary | Serves a transferred copy | Yes |
| Anycast node | One of many servers sharing an address | Yes, through a shared name |
TTL, SOA timers and propagation
Authoritative servers do not push changes to resolvers. Resolvers keep records until the TTL expires, so the time a change takes to reach users is governed by the TTL of the old record, not by any propagation process. Lowering the TTL at least one full old-TTL period before a migration is the standard way to make a cutover fast.
The SOA record of a zone defines the serial number and timers that secondaries follow, plus the negative caching TTL that resolvers apply to NXDOMAIN answers.
| Parameter | Typical range | Effect |
|---|---|---|
| Record TTL | 300 s to 86,400 s | How long resolvers cache an answer |
| SOA refresh | 1 to 24 hours | How often secondaries check the serial |
| SOA retry | 10 minutes to 2 hours | Retry interval after a failed refresh |
| SOA expire | 1 to 4 weeks | When secondaries stop answering without the primary |
| Negative TTL | 300 s to 3,600 s | Caching of nonexistent names |
Authoritative DNS compared with recursive DNS
The two roles are separate by design and should not run on the same server facing the Internet. Mixing them creates cache poisoning risks and open resolvers that can be abused for amplification attacks.
| Aspect | Authoritative DNS | Recursive DNS |
|---|---|---|
| Data source | Zone files or database | Cache filled by lookups |
| Who queries it | Resolvers worldwide | Clients of one network or service |
| Answers for | Only its own zones | Any name |
| DNSSEC role | Signs records | Validates signatures |
| Typical operator | Domain owner or DNS hosting provider | ISP, enterprise or public resolver service |
Resilience, DNSSEC and common mistakes
Because a failed authoritative service makes a domain unreachable even when its web servers run, operators distribute servers across different networks and locations, often with anycast so that one IP address is served from many sites. Using two independent DNS providers removes a single vendor as a point of failure, at the cost of keeping both synchronized.
With DNSSEC, the authoritative side signs each record set and publishes the keys, while the parent zone holds a DS record that links the chain of trust. Key rollovers must respect TTLs carefully, because a mismatch between DS and DNSKEY records makes the whole zone fail validation.
- Lame delegation: NS records point to servers that do not serve the zone.
- Forgetting the serial increment, so secondaries never pick up changes.
- All name servers in one network, which a single outage takes down together.
- Long TTLs before a planned migration, which keep users on old addresses for a day or more.
In everyday language
Authoritative DNS is the official address book for a domain. The owner of a website decides what goes in it, such as which server holds the site and where email should be delivered.
Other computers do not ask this book every time. They ask local helpers that remember earlier answers for a while. But when the truth is needed, the authoritative server is the final word, much like the official register at a town hall.
Seen in the real world
An online magazine moves its website to a new hosting provider. Its records are served by two authoritative DNS providers for redundancy, with a hidden primary feeding both through zone transfers.
Two days before the move, the operations team lowers the TTL of the website records from 86,400 seconds to 300 seconds. On migration day they update the A and AAAA records on the hidden primary and increment the serial, and NOTIFY messages push the change to both providers within seconds.
Because resolvers held the old answers for at most five minutes, nearly all readers reach the new servers within minutes. After a week of stable operation, the team raises the TTL again to reduce query load.