What is an authoritative name server?

Sajjad
DNS
10 Oct, 2026

An authoritative name server is a DNS server that holds the official, original records for a domain and answers questions about that domain from its own data. When a resolver asks it for the A record of www.example.com, it doesn't look anything up elsewhere or rely on a cache. It replies directly from the zone it's been configured with, and it marks the reply with the AA (Authoritative Answer) flag to show the answer is definitive. Every registered domain needs at least one authoritative name server, and in practice should have two or more. If you use a DNS provider such as Cloudflare, Route 53, or your registrar's DNS, their servers are your authoritative name servers.

Authoritative servers are the end of the line for every DNS lookup: the root and TLD servers only point the way, and resolvers only pass answers along. In this article you'll learn how authoritative servers differ from resolvers, what kinds of answer they give, how primary and secondary servers keep each other in sync, how resolvers choose between them, how to run a simple one yourself, and how to check that yours are healthy and consistent.

Authoritative Servers vs Resolvers

DNS servers fall into two broad groups that do opposite jobs.

	Authoritative name server	Recursive resolver
Holds	The real records for specific zones	No records of its own, only a cache
Answers questions about	Only the zones it hosts	Any domain on the internet
Contacts other servers?	No	Yes, it follows referrals from the root down
Who queries it	Resolvers all over the internet	Clients on its own network or service
Key response flag	`aa` (authoritative answer)	`ra` (recursion available)
Examples	Cloudflare DNS, Route 53, NS1, BIND, NSD, Knot DNS, PowerDNS	ISP resolvers, 1.1.1.1, 8.8.8.8, Unbound

The same software can sometimes do both, BIND being the classic example, but mixing the roles on one server is discouraged. An authoritative server should answer for its own zones and refuse to recurse for anyone.

Finding a Domain's Authoritative Name Servers

The authoritative servers for a domain are listed in its NS records:

dig example.com NS +short

ns1.example.net.
ns2.example.net.

Those are the servers your registrar has told the TLD about, and the same list should appear inside your zone. To query one of them directly and confirm it's really authoritative, send a non-recursive query:

dig @ns1.example.net www.example.com A +norecurse

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31514
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
www.example.com.        300     IN      A       203.0.113.10

The aa flag is the key. A response from a resolver's cache never carries it, which is also why nslookup labels resolver answers "Non-authoritative answer".

How an Authoritative Server Answers

When a query arrives, the server finds the zone that's the closest match for the name and responds in one of a handful of ways.

1. A Normal Answer

The name exists and has records of the requested type. The server returns them with aa set and status NOERROR. If the name is a CNAME, it returns the CNAME and, if the target is in a zone it also hosts, the target's records too.

2. NXDOMAIN: The Name Doesn't Exist

dig @ns1.example.net nope.example.com A +norecurse

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31038
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
example.com.            3600    IN      SOA     ns1.example.net. hostmaster.example.com. 2026101001 7200 3600 1209600 3600

The server includes the zone's SOA record so resolvers know how long to cache this negative answer.

3. NODATA: The Name Exists but Not That Type

If www.example.com has an A record but no AAAA record, a query for AAAA returns NOERROR with an empty answer section and the SOA in the authority section. This is different from NXDOMAIN, and resolvers treat it differently.

4. A Referral for a Delegated Subdomain

If part of the zone has been delegated, for example dev.example.com handed to separate servers, the parent zone's authoritative server returns a referral to those servers instead of an answer, just like a TLD server does.

5. REFUSED: Not My Zone

Ask an authoritative-only server about a domain it doesn't host and it refuses:

dig @ns1.example.net www.example.org A +norecurse

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 46522
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

That's exactly the right behaviour. If it returned an answer with the ra flag instead, it would be acting as an open resolver.

Primary and Secondary Servers

Most domains are served by several authoritative servers for redundancy. Traditionally, one of them is the primary (historically called the master) and the others are secondaries (historically slaves).

The primary holds the editable copy of the zone, either as a zone file or in a database.
Secondaries hold read-only copies, which they fetch from the primary using zone transfers: AXFR for a full copy or IXFR for just the changes.
When the zone changes, the primary sends a NOTIFY message to the secondaries, which then check the zone's SOA serial number and transfer the update if it has increased.
Secondaries also poll the primary on a schedule set by the SOA refresh and retry timers, in case a NOTIFY is missed.

From a resolver's point of view, every server listed in the NS records is equally authoritative. There's no way to tell a primary from a secondary from the outside, and resolvers don't prefer one over the other.

A common variation is a hidden primary: the primary isn't listed in the NS records at all and isn't reachable from the internet. It only feeds the public secondaries, which keeps the editable copy of your zone out of reach of attackers.

Large managed DNS providers don't usually use classic zone transfers internally. They store zones in distributed databases and push changes to every server in their anycast network, but the effect is the same: every listed server gives the same answers.

How Resolvers Choose Between Name Servers

When a domain has several authoritative servers, a resolver has to pick one for each query. Most resolvers:

Start with an unknown estimate for each server, often trying them in a random order.
Measure the round-trip time of each response.
Prefer the servers that respond fastest, while occasionally retrying slower ones in case they've improved.
Move on to another server if one times out or returns an error.

This means a single slow or broken server doesn't usually take a domain down, but it does slow down a share of lookups, especially from resolvers that haven't learned to avoid it yet. Having servers on different networks, ideally with anycast, keeps lookups fast for everyone.

Managed DNS vs Running Your Own

Most domain owners use a managed DNS provider, and for good reason. Running authoritative DNS well means handling global anycast, DDoS protection, monitoring and DNSSEC key management. Still, it helps to know what's involved.

Option	Good for	Things to consider
Registrar DNS	Simple sites, getting started	Features and performance vary widely
Managed DNS provider	Most businesses	Anycast, APIs, DNSSEC and analytics included
Self-hosted	Full control, internal zones, learning	You're responsible for uptime, security and updates
Hybrid	Redundancy across providers	Keeping multiple providers in sync

Popular Authoritative Server Software

BIND 9: The most widely known DNS server. It can act as both an authoritative server and a resolver.
NSD: An authoritative-only server from NLnet Labs, designed to be small, fast and secure.
Knot DNS: A high-performance authoritative server from CZ.NIC with strong automatic DNSSEC signing.
PowerDNS Authoritative Server: Can serve zones from databases such as PostgreSQL or MySQL, which suits hosting providers.
CoreDNS: A flexible, plugin-based server best known as the DNS server inside Kubernetes.

A Minimal Authoritative Server With NSD

To see how simple an authoritative server can be, here's a minimal NSD setup on Debian or Ubuntu:

sudo apt update
sudo apt install nsd

Create a zone file at /etc/nsd/zones/example.com.zone:

$ORIGIN example.com.
$TTL 3600

@       IN  SOA  ns1.example.com. hostmaster.example.com. (
                 2026101001  ; serial
                 7200        ; refresh
                 3600        ; retry
                 1209600     ; expire
                 3600 )      ; negative caching TTL

        IN  NS   ns1.example.com.
        IN  NS   ns2.example.com.

ns1     IN  A    192.0.2.53
ns2     IN  A    198.51.100.53

@       IN  A    203.0.113.10
www     IN  A    203.0.113.10
@       IN  MX   10 mail.example.com.
mail    IN  A    203.0.113.20

Then point NSD at it in /etc/nsd/nsd.conf:

server:
    ip-address: 0.0.0.0
    ip-address: ::0
    hide-version: yes

zone:
    name: "example.com"
    zonefile: "/etc/nsd/zones/example.com.zone"

Check both files and start the server:

sudo nsd-checkzone example.com /etc/nsd/zones/example.com.zone
sudo nsd-checkconf /etc/nsd/nsd.conf
sudo systemctl restart nsd

zone example.com is ok

Test it locally:

dig @127.0.0.1 www.example.com A +norecurse +noall +answer +comments | grep -E "flags|IN"

;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
www.example.com.        3600    IN      A       203.0.113.10

NSD never offers recursion, so there's nothing to switch off. When you edit the zone, increase the serial and run sudo nsd-control reload example.com. For a production setup you'd add at least one secondary on a separate network, firewall rules, monitoring and, ideally, DNSSEC.

Checking That Your Authoritative Servers Agree

Every authoritative server for a zone should return the same data. If one secondary has stopped receiving updates, some users will get stale answers depending on which server their resolver happens to pick.

The quickest check is to compare SOA serial numbers across all your name servers. dig has a built-in option for this:

dig +nssearch example.com

SOA ns1.example.net. hostmaster.example.com. 2026101001 7200 3600 1209600 3600 from server 192.0.2.53 in 14 ms.
SOA ns1.example.net. hostmaster.example.com. 2026101001 7200 3600 1209600 3600 from server 198.51.100.53 in 22 ms.

Matching serials mean the servers are in sync. If you'd rather script it, this loop asks each name server for the serial directly:

domain=example.com
for ns in $(dig +short "$domain" NS); do
  serial=$(dig +short +norecurse @"$ns" "$domain" SOA | awk '{print $3}')
  printf '%-25s %s\n' "$ns" "${serial:-NO ANSWER}"
done

ns1.example.net.          2026101001
ns2.example.net.          2026101001

You can do the same from PowerShell on Windows:

$domain = "example.com"
Resolve-DnsName -Name $domain -Type NS |
  Where-Object Type -eq "NS" |
  ForEach-Object {
    $soa = Resolve-DnsName -Name $domain -Type SOA -Server $_.NameHost -DnsOnly |
      Where-Object Type -eq "SOA"
    "{0,-25} {1}" -f $_.NameHost, $soa.SerialNumber
  }

Some managed providers don't use incrementing serials in a meaningful way, so on those, compare the actual records you care about instead.

Best Practices for Authoritative DNS

Use at least two name servers, on different networks and ideally in different locations. Many registries require two.
Prefer anycast for public zones. It improves speed and resilience against outages and DDoS attacks.
Disable recursion on authoritative servers so they can't be abused as open resolvers.
Restrict zone transfers to your known secondaries only.
Keep NS records consistent between your zone and the registrar's delegation.
Monitor every server, not just the first one, and alert on serial mismatches.
Enable DNSSEC if your provider and registrar support it, and follow the correct order when changing providers.
Protect your accounts: Two-factor authentication on your DNS provider and registrar accounts stops most hijacking attempts.

FAQ: Authoritative Name Servers

It means the server holds the original records for a zone and answers from them directly, rather than from a cache. Its responses carry the AA flag to show they're definitive.

At least two, and many domains use four or more. They should be on separate networks so a single outage can't make the domain unreachable. Managed providers usually assign two to four anycast name servers.

The primary holds the editable copy of the zone. Secondaries hold read-only copies they fetch from the primary using zone transfers. To resolvers, all listed servers are equally authoritative.

Because the answer came from your resolver's cache, not directly from the domain's authoritative server. To get an authoritative answer, query one of the domain's name servers directly, for example nslookup www.example.com ns1.example.net.

Yes. You can list name servers from two providers, as long as both serve identical records. This is done either with zone transfers from one to the other, or by pushing the same changes to both through their APIs or infrastructure-as-code tools.

Not necessarily. Your registrar is where you bought the domain. Your authoritative DNS provider is whoever runs the name servers listed in your NS records. Many registrars offer DNS hosting, but you can point your domain at any provider.

Conclusion

An authoritative name server is the source of truth for a domain's DNS. It holds the zone, answers only for the names it's responsible for, and marks every reply with the aa flag. Root and TLD servers simply lead resolvers to it, and resolvers cache what it says, so the accuracy and availability of your authoritative servers determine whether your website and email can be found at all.

Whether you use a managed provider or run NSD, BIND or Knot yourself, the essentials are the same: at least two servers on separate networks, no recursion, restricted zone transfers, consistent data across every server, and regular checks with dig +nssearch. Get those right and the rest of DNS can do its job.