Authoritative Servers

When you query www.google.com, the root server refers you to .com's TLD servers. The TLD server refers you to Google's authoritative servers. And there, finally, you get an answer: the IP address you were looking for.

Authoritative servers are the endpoint of the DNS referral chain. They are the servers that actually know the answer—not through caching, not through referrals, but because they are configured as the source of truth for a domain's DNS records. Understanding authoritative servers means understanding where DNS data originates and how domain owners control their Internet presence.

An authoritative nameserver is a DNS server that has been delegated authority over a specific zone and maintains the definitive records for that zone. When an authoritative server answers a query, it's not providing cached information or referrals—it's providing the actual, official answer.

Key characteristics of authoritative responses:

1. The AA (Authoritative Answer) flag is set: This flag in the DNS response header indicates the server is authoritative for the queried zone

2. Answers come from configured zone data: Not from a cache, not from another server's response

3. The server is listed in NS records: The parent zone (e.g., the TLD) delegates authority by referencing the server in NS records

4. The server has the zone loaded: The zone file (or dynamic data) is actively maintained on the server

The distinction from recursive resolvers:

It's crucial to distinguish authoritative servers from recursive resolvers:

Zone ownership:

A server becomes authoritative for a zone through two requirements:

1. Delegation: The parent zone contains NS records pointing to the server
2. Configuration: The server has the zone loaded and configured to answer authoritatively

For reliability, domains typically have multiple authoritative servers. These are classified as primary (master) and secondary (slave) servers, though this terminology is evolving toward primary and replica.

Primary Server (Master)

The primary server is where zone data originates. It's the source of truth:

• Zone file edits are made here (or API/dynamic updates target here)
• DNSSEC signing happens here (for most configurations)
• Serial number increments occur here
• Notifies secondary servers when changes occur

Secondary Server (Slave/Replica)

Secondary servers obtain their zone data from the primary through zone transfers:

• Read-only copies of the zone
• Periodically check for updates (based on SOA refresh interval)
• Receive NOTIFY messages when the primary updates
• Serve identical authoritative responses to the primary

From the resolver's perspective, there's no difference:

Critically, resolvers don't know or care which server is primary vs. secondary. All authoritative servers listed in NS records are equally valid. The resolver might query any of them and will receive the same authoritative data (assuming proper synchronization).

Hidden primary configuration:

Some organizations use a hidden primary setup:

• The true primary server is not listed in NS records
• It only serves zone transfers to advertised secondaries
• All public-facing servers are secondaries

This provides security benefits: the server where zone edits occur isn't exposed to query traffic or direct attacks.

A zone file is the definitive specification of a zone's DNS records. Historically a text file in a format specified by RFC 1035, zone files remain the standard way to represent DNS zone data, even when stored in databases or managed through APIs.

Zone file anatomy:

Understanding key elements:

$ORIGIN directive: Sets the base domain for relative names. When you write www without a trailing dot, it becomes www.example.com. based on $ORIGIN.

$TTL directive: Sets the default Time-To-Live for records without explicit TTLs. Resolvers cache records for this duration.

SOA record fields:

Common record types in zone files:

For secondary servers to maintain up-to-date copies of zone data, they need to synchronize with the primary. This happens through zone transfers.

AXFR (Full Zone Transfer)

AXFR transfers the complete zone from primary to secondary:

1. Secondary connects to primary via TCP on port 53
2. Secondary sends AXFR query for the zone
3. Primary transmits all records in the zone
4. Secondary replaces its existing zone data with the transferred data

AXFR is used for:

• Initial secondary setup (no existing zone data)
• When IXFR fails or isn't supported
• Periodically to ensure full consistency

IXFR (Incremental Zone Transfer)

IXFR transfers only the changes since a specified serial number:

1. Secondary sends IXFR request with its current SOA serial
2. Primary compares serials:
   • If primary has changes, sends only the deltas
   • If change history isn't available, falls back to AXFR
3. Secondary applies the incremental changes

IXFR is much more efficient for large zones with frequent small changes. A zone with 100,000 records might change 10 records; IXFR transfers 10 records instead of 100,000.

The NOTIFY mechanism:

Zone transfer security:

Zone transfers expose your entire zone data. Securing them is critical:

Organizations have several options for running authoritative DNS, each with tradeoffs:

1. Self-Hosted DNS

Running your own authoritative servers (e.g., BIND, PowerDNS, Knot DNS, NSD):

Advantages:

• Full control over configuration and data
• No third-party dependencies
• Can implement custom features
• No recurring per-query costs

Disadvantages:

• Requires infrastructure investment (multiple servers, geographic distribution)
• Need expertise to configure, secure, and maintain
• You're responsible for DDoS mitigation
• Must maintain 24/7 availability

2. Managed DNS Providers

Delegating authoritative DNS to specialized providers:

3. Hybrid Approaches

Many organizations use a combination:

• Primary self-hosted, secondaries with provider: Maintain control over zone editing while leveraging provider Anycast for performance
• Multi-provider redundancy: Use two managed providers (e.g., Route 53 + Cloudflare) for ultimate resilience
• Self-hosted with CDN integration: Run authoritative DNS but front with a CDN's DNS for DDoS protection

Choosing the right approach:

Understanding how authoritative servers respond to queries—including edge cases—is essential for troubleshooting and designing robust DNS configurations.

Response types from authoritative servers:

NODATA vs. NXDOMAIN distinction:

This distinction is subtle but important:

• NXDOMAIN: The name xyz.example.com doesn't exist at all. No record of any type exists for this name.

• NODATA: The name example.com exists, but you asked for an AAAA record and only A records exist. The name is there; the requested type isn't.

Both return NOERROR status code; the difference is in the response content:

• NODATA: Empty answer section, SOA in authority section
• NXDOMAIN: NXDOMAIN status, SOA in authority section

Negative caching:

When an authoritative server returns NXDOMAIN or NODATA, resolvers cache this negative result according to the SOA MINIMUM field (300 seconds in the example above). This prevents repeated queries for non-existent names.

DNSSEC and authenticated denial:

DNSSEC provides authenticated denial of existence—cryptographic proof that a name doesn't exist:

• NSEC records: List existing names in order; prove gaps where names don't exist
• NSEC3 records: Hashed version of NSEC; prevents zone enumeration

This prevents attackers from spoofing NXDOMAIN responses.

Running reliable authoritative DNS requires attention to redundancy, distribution, security, and operational practices. Here are industry best practices:

Redundancy requirements:

TTL considerations:

Common TTL mistakes:

1. Setting TTL too low without reason: Generates excessive query load
2. Forgetting to lower TTL before changes: If TTL is 24 hours, you must wait 24 hours for changes to propagate
3. Using TTL=0: Forces resolvers to query every time; legitimate for some use cases but usually excessive
4. Inconsistent TTLs: Same record with different TTLs from different servers causes unpredictable behavior