What Is Authoritative DNS
What is authoritative DNS comes down to one distinction almost every guide blurs: there’s a difference between a server that knows an answer and a server that has the answer. An authoritative nameserver stores the official DNS records for a domain, the source of truth, and responds with the final, definitive answer to a query. It doesn’t ask another server for help. It only answers for the specific zones, the portions of the domain namespace, it directly controls. For the record types this server actually stores, see DNS records explained: A, CNAME, MX, and more.
Authoritative vs Recursive DNS: The Critical Difference
Authoritative DNS server vs recursive is the comparison that trips up most people learning DNS for the first time. A recursive resolver, the server, often run by your ISP or a provider like Cloudflare, is the one doing the searching, working through the delegation chain on your behalf until it finds the right answer. An authoritative server is the one holding that answer to begin with. A recursive resolver is like a librarian tracking down a specific document across several archives. An authoritative server is the actual archive holding the original.
Recursive Resolvers Are Not Authoritative, Even If They Say They Are
Some public DNS services present answers in a way that makes them look authoritative, and this causes real confusion on forums where people conflate “using Cloudflare’s DNS” with “being authoritative” for their domain. The technical giveaway is the AA flag, the Authoritative Answer flag set in a DNS response header, which is only present when the answer genuinely came from the source of truth rather than a cached copy relayed by a recursive resolver.
How Authoritative DNS Works: The Delegation Chain
Authority in DNS doesn’t sit in one place. It flows downward through a chain, and no single server “knows” your entire domain outright:
- A root server knows which server is authoritative for the top-level domain, like .com
- That TLD server knows which nameservers are authoritative for your specific domain, like example.com
- Your domain’s authoritative nameserver holds the actual record, for instance that www.example.com resolves to a specific IP address
The root doesn’t know your domain directly. It delegates that responsibility down the chain, one level at a time, until the query reaches the server that actually holds the answer. This is the part most explanations skip, treating “root server” and “authoritative server” as interchangeable when they sit at opposite ends of the same chain.
Types of Authoritative Servers
Primary (Master) Servers
A primary server, also called a master server, holds the read-write zone file, the file where actual changes to DNS records get made. When you update a record, this is the server where that update originates.
Secondary (Slave) Servers
A secondary server holds a read-only copy of the zone, pulled from the primary, and exists purely for redundancy. If a domain has only one authoritative server and it goes down, that domain becomes unresolvable. Secondary servers are why domains typically list at least two authoritative nameservers in their NS records, an NS record being the DNS record type that identifies which servers are authoritative for a domain.
Hidden Primary Servers
A hidden primary is a master server that isn’t listed in the domain’s public NS records at all. It pushes updates to the public secondary servers, which are the ones resolvers actually query, while staying off the public record itself. This is considered a security best practice, since it removes the actual write-access server from direct public exposure, but it’s a detail almost never mentioned outside operational DNS documentation.
| Type | Role | Publicly Listed? |
|---|---|---|
| Primary (Master) | Holds the read-write zone file where changes are made | Sometimes |
| Secondary (Slave) | Holds a read-only copy for redundancy | Yes, in NS records |
| Hidden Primary | Master server not listed publicly, pushes updates to secondaries | No |
Primary vs Secondary Authoritative DNS in Practice
The practical reason both exist together is fault tolerance. Primary vs secondary authoritative DNS isn’t about one being more “real” than the other, both hold authoritative answers, it’s about where changes happen versus where redundant copies live. If a secondary server fails, resolvers simply query the remaining ones. If the primary fails but secondaries remain reachable, the domain still resolves correctly for existing records, though new changes can’t be made until the primary is restored.
The Records That Make It Work
An SOA record, or Start of Authority record, sits at the top of every DNS zone and contains administrative information: the primary nameserver, a contact address, and the TTL parameters, the time-to-live values that govern how long resolvers should cache records from this zone before checking again. NS records, separately, are what actually publish which servers are authoritative for a given domain, telling the rest of the internet where to send queries.
Operational Realities No Beginner Guide Covers
One Server Can’t Safely Do Both Jobs
Software like BIND9 technically supports running authoritative and recursive functions on the same server, and this shows up repeatedly in configuration discussions as a source of real misconfiguration. A server handling recursion for a network should generally not also be authoritative for public zones, since combining the two roles increases exposure to certain attack patterns and complicates troubleshooting when something goes wrong.
Authoritative Servers Are a Target for Amplification Attacks
DNS amplification attacks exploit authoritative servers directly, using spoofed queries designed to generate large responses directed at a victim rather than the actual requester. This is a genuine operational concern for anyone running their own authoritative DNS infrastructure, and it’s part of why the DNS-level protections covered in what is DNS filtering exist as a broader category.
What Happens if Authoritative DNS Goes Down
If every authoritative server for a domain becomes unreachable, the domain stops resolving for new visitors. Existing cached answers on resolvers around the internet may keep working temporarily, but only until their TTL expires, at which point resolvers have nowhere left to get a fresh answer. This is a real operational risk, distinct from the deliberate manipulation covered in what is a DNS hijack, where records are changed rather than simply unreachable.
Choosing Authoritative DNS for Your Domain
Domain owners generally have three practical options: using the registrar’s default authoritative DNS servers, pointing to a third-party DNS provider instead, or self-hosting authoritative DNS using software like BIND9, Knot, NSD, or PowerDNS. Most people use their registrar’s default without ever needing to change it, but understanding that this choice exists clarifies why “my registrar’s DNS” and “authoritative DNS” aren’t actually separate things, the registrar is simply one common provider of it.
Security: DNSSEC and Authoritative Records
DNSSEC adds cryptographic signatures to authoritative DNS records, allowing a resolver to verify that a response genuinely came from the authoritative source and wasn’t tampered with in transit. This directly protects against cache poisoning, the attack where forged records get inserted into a resolver’s cache, since a resolver validating DNSSEC signatures can detect and reject a forged response that doesn’t match the authoritative signature.
FAQ
Can I run my own authoritative DNS server?
Yes. Software like BIND9, Knot, NSD, or PowerDNS lets you host authoritative DNS yourself instead of relying on your registrar or a third-party provider.
What’s the difference between my registrar’s DNS and authoritative DNS?
Your registrar typically provides authoritative DNS servers for your domain by default, but authoritative DNS itself is a role, not a specific company. You can use your registrar’s servers or point your domain to a different authoritative provider entirely.
Why do domains need more than one authoritative nameserver?
Redundancy. If one authoritative server becomes unreachable, the others can still answer queries, keeping the domain resolvable.
