Authoritative DNS, TTLs, and caching behaviour · Linux

The authoritative server is the source of truth for a zone. It returns answers without recursing. Understanding its records - especially SOA - and how TTLs propagate is essential for designing a zone that is reliable and changes quickly when needed.

Authoritative vs recursive

Role	Behaviour
Recursive	Accepts client queries, walks the chain, caches answers
Authoritative	Holds the zone records, returns answers for its zone, does not recurse

A host that runs an authoritative server is a name server (NS). A host that runs a recursive resolver is a resolver.

Most production environments use both, but they are different services:

Authoritative: serves your zones (example.com) to the world.
Recursive: serves your hosts’ queries by contacting authoritative servers on their behalf.

Tools like BIND, Knot, NSD, and PowerDNS run authoritative servers. Tools like Unbound, Knot Resolver, and systemd- resolved run recursive resolvers.

The SOA record

The Start of Authority (SOA) record describes the zone:

dig example.com SOA +noall +answer

Output:

example.com.    3600    IN    SOA    ns1.example.com. admin.example.com. 2025010101 7200 3600 1209600 3600

Fields, left to right:

MNAME: the primary master name server (ns1.example.com).
RNAME: the admin email (admin.example.com; @ becomes .).
SERIAL: zone serial number. Incremented on every zone change. Secondary servers poll and reload when the serial increases. Convention: YYYYMMDDNN.
REFRESH: seconds a secondary waits before checking the master for updates (7200 = 2 hours).
RETRY: seconds a secondary waits before retrying after a failed refresh (3600 = 1 hour).
EXPIRE: seconds a secondary keeps serving the zone after the master has been unreachable (1209600 = 14 days).
MINIMUM: the negative cache TTL (3600 = 1 hour). Also historically the default TTL for all records in the zone.

TTL strategy

Every record has a TTL. The TTL tells resolvers how long to cache. Picking the right TTL is a trade-off:

TTL	Trade-off
Short (60-300s)	Fast propagation of changes. Higher query load on authoritative servers.
Medium (3600s, 1 hour)	Reasonable balance. Changes take up to an hour to propagate.
Long (86400s, 1 day)	Low query load. Changes take up to a day to propagate.

For records that rarely change (mail servers, web servers), medium to long TTLs are appropriate. For records that change often (CDN endpoints, failovers), short TTLs are needed.

Failover TTL

If a service can move between data centres (DNS-based failover, geo-routing, active-active), the TTL determines how long it takes for traffic to shift:

60s TTL: shifts in ~60s, but every cache misses every 60s.
300s TTL: shifts in ~5 min, cache hit rate is high.
3600s TTL: shifts in ~1 hour.

For a CDN, 60-300s is typical. For a static VIP, 3600s is fine. For a maintenance window, lower the TTL a day or two ahead of the change so resolvers pick up the new value.

SOA tuning

The EXPIRE value determines how long secondaries keep serving when the master is unreachable. For a healthy zone, 14 days is fine. For a frequently-changing zone, you may want 7 days.

The REFRESH and RETRY values determine how quickly secondaries pick up changes. Lower values mean faster propagation to secondaries (and faster recovery from master outages) at the cost of more polling traffic.

Common record types in a zone

dig example.com ANY +noall +answer

Type	Purpose
SOA	Zone metadata
NS	Authoritative name servers for the zone
A	IPv4 address of a name
AAAA	IPv6 address of a name
CNAME	Alias to another name
MX	Mail server for the zone
TXT	Free-form text (SPF, DKIM, verification)
SRV	Service locator (used by many protocols)
CAA	Which CAs may issue certificates for the zone

A typical zone has SOA, NS, MX, A/AAAA for each host, and TXT records for SPF, DKIM, and domain verification.

Glue records

When a TLD returns the NS records for example.com, it may also return the A records for the NS hostnames (glue). Without glue, the resolver has to look up the NS hostnames before it can contact them. Most authoritative servers publish glue to avoid this.

dig +trace example.com | grep -A5 'NS'

If the NS records include A or AAAA records in the ADDITIONAL SECTION, glue is published.

DNSSEC

DNSSEC signs records so a resolver can verify they have not been tampered with. The chain of trust runs from the root signed zone, through TLDs, to your zone.

dig example.com +dnssec +noall +answer

The ad flag (authenticated data) indicates DNSSEC validation succeeded.

DNSSEC validation failures surface as SERVFAIL, not as the underlying answer. A misconfigured DNSSEC chain can take your zone offline for validating resolvers.

Operational discipline

Document your TTL strategy.
Lower TTLs before planned changes; raise them after.
Monitor SOA serial increments (zone changes) and EXPIRE-elapsed (master unreachable).
Verify DNSSEC chain with an external validator (dnsviz.net, verisigninc.com).