← DNS ServersServer Type

Authoritative Nameserver

The final authority for a domain's DNS records. Authoritative nameservers hold the zone files that define every hostname, IP address, mail server, and security policy for a domain. Every DNS lookup ultimately terminates here.

Overview

Where DNS Records Live

When you log into your DNS provider (Cloudflare, Route 53, your registrar's DNS panel) and add an A record, you are editing a zone file stored on authoritative nameservers. These servers hold the canonical, definitive records for your domain — they are the only servers that can answer with the AA (Authoritative Answer) bit set in the DNS response.

Recursive resolvers cache answers from authoritative servers, but they always eventually trace back here when a cache entry expires. If you change a DNS record, the old value remains cached at resolvers until the TTL expires — which is why lowering TTL before a planned change is standard practice.

You must have at least two authoritative nameservers for a domain (primary and one or more secondaries) to be resilient to single-server failure. Most managed DNS providers handle this transparently across their anycast infrastructure.

Authoritative Answer (AA bit)A DNS response with the AA bit set came directly from an authoritative nameserver. A response without it was served from a resolver's cache or via referral. You can check this with dig +norecurse thedns.guru @ns1.example.com
Primary vs SecondaryThe primary nameserver holds the master copy of the zone and is where changes are made. Secondary nameservers receive copies via zone transfer (AXFR/IXFR). All are equally authoritative for read queries — only the primary accepts updates.
Zone Files

DNS Record Types Reference

The record types you'll encounter in a typical zone file

SOAStart of Authority

Every zone has exactly one SOA record. It identifies the primary nameserver, the responsible party's email, the zone serial number, and timing parameters for zone transfers (refresh, retry, expire) and negative caching (minimum TTL).

@ IN SOA ns1.example.com. admin.example.com. ( 2024041201 ; serial (YYYYMMDDnn) 3600 ; refresh 900 ; retry 604800 ; expire 300 ) ; min TTL
NSName Server

Lists the authoritative nameservers for the zone. At least two NS records are required for redundancy. These must match the NS records registered at your TLD registry (the "delegation"). Child zones can have their own NS records for sub-delegation.

@ IN NS ns1.example.com. @ IN NS ns2.example.com.
A / AAAAAddress Records

Maps a hostname to an IPv4 (A) or IPv6 (AAAA) address. The most common record type. Multiple A records for the same name enable round-robin load balancing. Lowest latency impact on resolution.

www IN A 203.0.113.42 www IN AAAA 2001:db8::1 mail IN A 203.0.113.50
CNAMECanonical Name

An alias pointing one name to another. Resolution follows the chain until an A/AAAA is found. Cannot coexist with other records at the same name (the "CNAME at apex" problem) — use ANAME/ALIAS records for apex domains.

shop IN CNAME stores.example.net. blog IN CNAME blogs.example.org.
MXMail Exchanger

Specifies mail servers for the domain along with a priority value (lower = preferred). The mail server value must resolve to an A/AAAA record — it cannot be a CNAME. Multiple MX records provide mail failover.

@ IN MX 10 mail1.example.com. @ IN MX 20 mail2.example.com.
TXTText Record

Free-form text data used for SPF, DKIM, DMARC, domain verification, and other purposes. Multiple TXT records at the same name are concatenated for SPF. Max 255 chars per string, multiple strings allowed per record.

@ IN TXT "v=spf1 include:_spf.google.com ~all" @ IN TXT "google-site-verification=abc123" _dmarc IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
SRVService Locator

Generalized service discovery record. Specifies host, port, priority, and weight for a service. Used by SIP, XMPP, and many enterprise protocols.

_sip._tcp IN SRV 10 60 5060 sipserver.example.com.
CAACertification Authority Authorization

Restricts which Certificate Authorities may issue SSL/TLS certificates for the domain. Checked by CAs before issuance. Helps prevent unauthorized certificate issuance.

@ IN CAA 0 issue "letsencrypt.org" @ IN CAA 0 issuewild "comodoca.com"
Replication

Zone Transfers: AXFR vs IXFR

How secondary nameservers stay synchronized with the primary

AXFR — Full Zone Transfer

Transfers the entire zone file from primary to secondary. Used for initial synchronization or after out-of-sync recovery. The secondary polls the primary at the interval defined in the SOA refresh field, comparing the SOA serial number. If the primary's serial is higher, an AXFR is initiated.

For large zones (millions of records), AXFR is expensive. Modern implementations support IXFR (Incremental Zone Transfer) — which transfers only the changed records since the last known serial, dramatically reducing bandwidth and processing time.

Zone Transfer Flow

Secondary polls primary (SOA query)

Secondary sends SOA query to primary at refresh interval. Compares serial numbers.

Serial mismatch detected

If primary serial > secondary serial, the secondary initiates a transfer request.

IXFR attempted first

Secondary requests IXFR with its current serial. Primary sends only the delta (added/removed records).

Fallback to AXFR if needed

If primary cannot serve IXFR (no history for that serial range), a full AXFR transfer occurs.

Zone reloaded

Secondary atomically replaces the old zone with the new data. SOA serial is updated.

; SOA Timing Fields ; These control zone transfer behavior @ IN SOA ns1.example.com. admin.example.com. ( 2024041201 ; Serial — increment on every change ; Format: YYYYMMDDnn (or any increasing int) 3600 ; Refresh — how often secondary polls (sec) 900 ; Retry — if refresh fails, retry after (sec) 604800 ; Expire — secondary discards zone after (sec) ; if it can't reach primary (7 days) 300 ) ; Minimum TTL — used for negative caching ; NOTIFY — Push-based transfer trigger ; Primary sends NOTIFY to secondaries when zone ; changes, so they don't have to wait for refresh. ; Defined in RFC 1996. Supported by BIND, PowerDNS.
Security: Restrict Zone TransfersUnrestricted AXFR lets anyone download your entire zone file — a goldmine for attackers (full DNS map of your infrastructure). Always restrict AXFR to specific secondary IPs using allow-transfer in BIND or equivalent ACLs.
# Test zone transfer (AXFR) dig AXFR thedns.guru @ns1.example.com # Should be refused from unauthorized IPs: # ;; Transfer failed. # Verify NS records match delegation dig thedns.guru NS +short
Security

DNSSEC Zone Signing

Cryptographically authenticating authoritative DNS responses

DNSSEC adds digital signatures to DNS records so resolvers can verify that responses came from the correct authoritative nameserver and were not tampered with in transit. When you enable DNSSEC, your zone is signed with a private key, and the public key is published in DNSKEY records.

Signing uses two key pairs. The Zone Signing Key (ZSK) signs individual resource records. The Key Signing Key (KSK) signs only the DNSKEY record set. The KSK's hash (DS record) is submitted to your TLD registry to establish the chain of trust from the root.

  • Each record set gets an accompanying RRSIG (Resource Record Signature) record
  • NSEC / NSEC3 records prove the authenticated non-existence of names (NXDOMAIN)
  • ZSKs are rotated frequently (every 30–90 days); KSKs are rotated annually
  • Managed DNS providers (Cloudflare, Route 53) handle signing automatically
  • Enabling DNSSEC increases zone file size ~3× due to signature records
; DNSSEC records in a signed zone ; DNSKEY — public key published in zone @ IN DNSKEY 256 3 13 ( ; ZSK, Algorithm 13 = ECDSA P-256 oJMRESz5E4g4bFJjE9s/... ...) @ IN DNSKEY 257 3 13 ( ; KSK (bit 257 = SEP flag set) mdsswUyr3DPW132mOi8V... ...) ; RRSIG — signature over an RRset thedns.guru. IN RRSIG A 13 2 3600 ( 20240501000000 20240401000000 12345 thedns.guru. base64signaturedata==) ; DS record (submitted to TLD registry) ; Links parent zone to child zone's KSK thedns.guru. IN DS 12345 13 2 ( sha256hashofksk...)
Check DNSSEC statusdig thedns.guru +dnssec +shortdig thedns.guru DS
Providers

Authoritative DNS Providers

Self-hosting vs managed DNS — and which managed platform to choose

🟠 Cloudflare DNS
Free + Pro

Fastest average global response times. Free tier includes DDoS protection, analytics, and DNSSEC. Anycast across 300+ datacenters. API and Terraform support.

🟡 AWS Route 53
Pay-per-use

Deep integration with AWS services (ELB, CloudFront, EC2). Health-check routing, latency-based routing, geolocation routing. $0.50/zone/month + per-query pricing.

🔵 Google Cloud DNS
Pay-per-use

100% uptime SLA. Global anycast. Works natively with GCP services. $0.20/zone/month. Supports DNSSEC and private zones for VPC.

⚙️ NS1 / IBM
Enterprise

Advanced traffic management with Filter Chain routing. Used by high-traffic apps needing sophisticated load balancing and failover logic.

🖥️ BIND (Self-hosted)
Open Source

The reference DNS implementation from ISC. Extremely flexible and feature-complete. Requires infrastructure management — not recommended unless you have specific control requirements.

PowerDNS (Self-hosted)
Open Source

High-performance authoritative DNS with SQL backend. Excellent API for programmatic zone management. Used by many domain registries and hosting providers.

Recommendation for most domainsUse a managed authoritative DNS provider like Cloudflare (free) or AWS Route 53. Managed providers handle anycast, DNSSEC signing, zone redundancy, and DDoS protection automatically. Self-hosting authoritative DNS is only justified when you need deeply custom routing logic or regulatory data-residency requirements.
Diagnostics

Querying Authoritative Nameservers

Query authoritative directly (bypass cache)

# Find authoritative NS for domain dig thedns.guru NS +short # Query it directly with +norecurse dig thedns.guru A +norecurse \ @ns1.cloudflare.com # Check AA bit in response dig thedns.guru A @ns1.cloudflare.com

Verify SOA and serial

# Check SOA record dig thedns.guru SOA +short # Compare primary vs secondary serial dig thedns.guru SOA @ns1.example.com dig thedns.guru SOA @ns2.example.com # Should show same serial if in sync

Check DNSSEC chain

# Verify DS record at TLD dig thedns.guru DS # Get DNSKEY from authoritative dig thedns.guru DNSKEY +dnssec # Full DNSSEC verification delv thedns.guru A +vtrace

Test zone transfer restriction

# Attempt AXFR (should be refused # from unauthorized sources) dig AXFR thedns.guru @ns1.example.com # If it succeeds, zone transfers # are unrestricted — fix ASAP!