What is an Authoritative Name Server?

An authoritative DNS server stores the official DNS records for a domain and provides the final answer to DNS queries.


Authoritative DNS server workflow

What is an Authoritative DNS Server? #

An authoritative DNS server is the server that holds the official DNS records for a domain.

When a recursive resolver performs DNS resolution, the final step of the lookup process is querying the authoritative server responsible for the domain.

authoritative DNS server works together with DNS resolvers and the global DNS hierarchy.

The authoritative server responds with the definitive DNS records such as:

Unlike recursive resolvers, authoritative servers do not perform external DNS lookups. They answer queries directly from their configured zone data.

Role of Authoritative Servers in DNS Resolution #

During DNS resolution, the resolver navigates through the DNS hierarchy until it reaches the authoritative nameservers responsible for a domain.

  1. A client queries a recursive resolver.
  2. The resolver queries the root servers.
  3. The root servers return the TLD nameservers.
  4. The resolver queries the TLD servers.
  5. The TLD servers return the domain's authoritative nameservers.
  6. The resolver queries the authoritative server.
  7. The authoritative server returns the requested record.

The response from the authoritative server is the final answer used by the resolver.

DNS Zones and Zone Files #

Authoritative servers store domain information in DNS zones.

A zone contains all DNS records associated with a domain and is typically stored in a zone file.

For example, a simple zone file might contain:

$TTL 3600
@       IN SOA  ns1.example.net. admin.example.net. (
                2026030801
                3600
                1800
                604800
                86400 )

        IN NS   ns1.example.net.
        IN NS   ns2.example.net.

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

This file defines the authoritative DNS records for example.net.

Primary and Secondary Authoritative Servers #

Most domains are served by multiple authoritative servers to ensure reliability and redundancy.

Two common roles exist:

Secondary servers retrieve zone updates from the primary server using mechanisms such as:

This ensures that multiple authoritative servers always serve the same DNS data.

Example BIND Authoritative Configuration #

In BIND, a simple authoritative configuration may look like:

zone "example.net" {
    type master;
    file "/var/named/example.net.zone";
};

For a secondary server:

zone "example.net" {
    type slave;
    masters { 192.0.2.10; };
    file "slaves/example.net.zone";
};

This configuration allows the secondary server to automatically synchronize zone data from the primary.

Authoritative DNS and Global Infrastructure #

Large DNS providers often deploy authoritative servers across multiple geographic locations using DNS Anycast.

In an Anycast deployment, many servers advertise the same IP address through BGP.

Internet routing automatically directs queries to the nearest or best-performing node.

This architecture provides:

Even smaller organizations can deploy authoritative DNS servers in multiple datacenters to improve resilience and availability.

Authoritative DNS and Security #

Authoritative DNS servers are responsible for publishing secure and reliable DNS data.

Modern authoritative infrastructures commonly support:

These technologies help protect DNS infrastructure against tampering, spoofing, and unauthorized updates.

Inspecting an Authoritative DNS Server with dig #

DNS administrators frequently use the dig tool to inspect the behavior of an authoritative DNS server and verify that it is returning correct responses.

The following example queries the SOA record of a domain directly from a local authoritative server:

dig +norecurse soa @127.0.0.1 assetcrypt.com

Example output:

; <<>> DiG 9.18 <<>> soa @127.0.0.1 assetcrypt.com
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60996
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 2720c041c5939de70100000069adcde0ec777149d2b09a55 (good)

;; QUESTION SECTION:
;assetcrypt.com. IN SOA

;; ANSWER SECTION:
assetcrypt.com. 3600 IN SOA globaldns1.planisys.net. hostmaster.planisys.com. 2024120220 10800 3600 604800 3600

;; AUTHORITY SECTION:
assetcrypt.com.		3600	IN	NS	globaldns2.planisys.net.
assetcrypt.com.		3600	IN	NS	globaldns1.planisys.net.

Authoritative Answer (AA Flag) #

The response header contains several DNS flags:

flags: qr aa rd

The AA flag stands for Authoritative Answer.

When this flag is present, it indicates that the server responding to the query is authoritative for the requested domain.

In other words, the DNS server is returning the data directly from its own zone file rather than from a cache.

Recursion Warning #

The output also contains the warning:

WARNING: recursion requested but not available

The rd flag (Recursion Desired) is set automatically by dig.

Authoritative DNS servers typically operate with recursion disabled for security and performance reasons.

This warning simply indicates that the server received a recursive request but ignored it because it is configured as an authoritative-only server.

EDNS (Extension Mechanisms for DNS) #

The OPT PSEUDOSECTION indicates that the query uses EDNS (Extension Mechanisms for DNS).

EDNS: version: 0, flags:; udp: 1232

EDNS extends the original DNS protocol to support additional features, including:

The value udp: 1232 represents the maximum UDP payload size supported by the resolver.

The response also includes a DNS COOKIE:

COOKIE: 2720c041c5939de70100000069adcde0ec777149d2b09a55 (good)

DNS cookies are a lightweight security mechanism defined in RFC 7873.

They help protect authoritative servers against DNS amplification attacks by verifying that the client is able to receive packets at its source address.

Because the cookie exchange requires a valid round-trip, spoofed IP addresses cannot easily generate large DNS responses.

The SOA Record #

The response contains the SOA (Start of Authority) record for the domain:

assetcrypt.com. 3600 IN SOA
globaldns1.planisys.net.
hostmaster.planisys.com.
2024120220
10800
3600
604800
3600

The SOA record defines important parameters for the zone, including:

The serial number is especially important because it is used by secondary DNS servers to detect when the zone has been updated.

Why These Fields Matter #

Understanding the structure of DNS responses helps operators verify that their authoritative DNS infrastructure is functioning correctly.

The combination of:

confirms that the DNS server is behaving as a properly configured authoritative nameserver.

The AUTHORITY Section #

When querying an authoritative DNS server using dig +norecurse, the response may include an AUTHORITY SECTION.

;; AUTHORITY SECTION:
assetcrypt.com. 3600 IN NS globaldns2.planisys.net.
assetcrypt.com. 3600 IN NS globaldns1.planisys.net.

The AUTHORITY SECTION lists the nameservers responsible for the domain.

These NS (Name Server) records identify the authoritative DNS servers that host the zone.

In this example, the domain assetcrypt.com is served by two authoritative nameservers:

DNS standards require that domains normally be served by multiple authoritative servers to provide redundancy and high availability.

If one nameserver becomes unreachable, resolvers can query another server listed in the delegation.

These NS records are also published in the parent zone (for example the .com registry), allowing recursive resolvers to locate the authoritative servers for the domain.

When the query is sent directly to an authoritative server with +norecurse, the server returns these NS records as confirmation that it is authoritative for the zone.

Related DNS Topics

Request Information

captcha
Can't read it? Click refresh
Planisys 2025 © All rights reserved.