Dns Infrastructure

Production engineering guide for dns infrastructure covering patterns, implementation strategies, and operational best practices.

DNS infrastructure is the foundation of networked services: a distributed, hierarchical system that maps human-readable names to network addresses, enabling services to be discovered and reached across the globe. It matters when a service fails to resolve, when a new deployment cannot be accessed, or when a DNS change introduces latency or downtime. This page details the operational mechanics of DNS infrastructure—how zones are managed, how records are resolved, how caching and replication work, and how failure modes propagate through the system.

Managing DNS Zones

A DNS zone is a named portion of the DNS namespace, typically corresponding to a domain. It contains resource records (RRs) that define how names resolve to addresses, mail servers, and other services. Zones are managed in files known as zone files, which use a standard format based on the DNS Resource Record (RR) syntax.

A typical zone file for example.com begins with a SOA (Start of Authority) record, followed by multiple RRs:

$ORIGIN example.com.
$TTL 300
@       IN SOA  ns1.example.com. admin.example.com. (
                        2024051501  ; serial
                        3600        ; refresh
                        1800        ; retry
                        604800      ; expire
                        300         ; minimum TTL
                        )
        IN NS   ns1.example.com.
        IN NS   ns2.example.com.
        IN A    192.0.2.1
www     IN A    192.0.2.10
mail    IN A    192.0.2.20
        IN MX 10 mail.example.com.
api     IN CNAME www.example.com.

The SOA record defines the zone's authoritative nameserver, the primary server (ns1.example.com), and key timing parameters. The TTL (Time to Live) sets the default caching duration for all records unless overridden.

To deploy a new zone, the zone file is transferred from a master server to one or more slave servers using AXFR (full zone transfer) or IXFR (incremental zone transfer). A slave server periodically polls the master using the SOA query:

$ dig @ns1.example.com SOA example.com

The slave compares the serial number in the SOA response with its own. If the master’s serial is higher, it fetches the updated zone via AXFR:

$ dig @ns1.example.com example.com AXFR

The response includes all records in the zone, and the slave updates its local copy.

Configuring and Operating Nameservers

Nameservers are the authoritative servers for one or more DNS zones. A nameserver runs a DNS daemon—typically BIND, Unbound, or CoreDNS—each implementing the standard DNS protocol over UDP and TCP.

A BIND configuration file (named.conf) defines zones and their sources:

zone "example.com" {
    type master;
    file "/var/dns/zones/example.com.db";
    allow-update { 192.0.2.10; };
    notify yes;
    also-notify { 192.0.2.20; };
};

This configuration tells BIND to serve example.com as a master zone, load its data from /var/dns/zones/example.com.db, accept updates from 192.0.2.10, and notify 192.0.2.20 when the zone changes.

When a nameserver receives a query, it performs recursive or iterative resolution. A recursive query asks the nameserver to return the final answer or a failure, while an iterative query allows the client to follow referrals.

For example, resolving api.example.com:

$ dig @8.8.8.8 api.example.com

The resolver at 8.8.8.8 first queries the root servers (.) for api.example.com, then follows the referrals to example.com’s nameservers, and finally receives an answer with the A record for api.example.com.

Caching and TTL Propagation

Caching is critical for DNS performance and scalability. Each DNS record has a TTL, which determines how long a resolver or caching server can use that record before refreshing it.

A resolver (like systemd-resolved, dnsmasq, or unbound) caches answers locally. When it receives a response, it stores the record with the TTL and uses it for subsequent queries.

A TTL of 300 seconds (5 minutes) means a client or intermediate server can use the record for up to 5 minutes without rechecking. After that, it issues a query for the same name:

$ dig @192.0.2.1 api.example.com

The server checks its cache. If the record is present and not expired, it responds directly. If expired, it may refresh from upstream or query the authoritative server.

TTL values are often set hierarchically: short TTLs for frequently changing records (e.g., CNAME, A), and long TTLs for stable records (e.g., NS, MX).

A common failure mode is TTL misalignment: a record is updated, but the old TTL causes a mix of responses across the network. For example, updating the A record for api.example.com to point to 192.0.2.11 but the TTL is 3600 seconds. Clients that fetched the record before the update continue using 192.0.2.10 for 60 minutes, creating a transient inconsistency during a rollout.

Zone Transfers and Dynamic Updates

Zone transfers (AXFR/IXFR) are used to synchronize master and slave servers. AXFR sends the entire zone, while IXFR sends only the differences since a known serial.

A slave server can be configured to pull updates automatically:

zone "example.com" {
    type slave;
    masters { 192.0.2.1; };
    file "/var/dns/slave/example.com.db";
    refresh 1800;
    retry 300;
    expire 604800;
    minimum 300;
};

The slave queries the master every refresh seconds. If the master’s SOA serial has changed, it initiates an AXFR or IXFR transfer.

Dynamic updates allow clients or services to register their own records in a zone. A client sends a DNS UPDATE message over UDP or TCP:

$ dig -t UPDATE +short @ns1.example.com

An example update adds a new A record:

; Update: example.com.
; Add: www.example.com. 300 IN A 192.0.2.15

The nameserver applies the update and returns a response with status codes:

A common failure mode is update propagation delay: a client registers a record, but the nameserver does not immediately serve it. This happens when the update is applied to a zone in memory but not yet written to disk. The zone may be served from a stale in-memory copy.

Failure Modes and Diagnostics

DNS infrastructure silently fails when records are stale, servers are unreachable, or updates are not propagated.

A nameserver may be unreachable if its A record is incorrect or if the server’s IP address changes. A dig query can reveal this:

$ dig @ns1.example.com example.com
;; ANSWER SECTION:
example.com.    300 IN A    192.0.2.1
;; AUTHORITY SECTION:
example.com.    300 IN NS   ns1.example.com.
example.com.    300 IN NS   ns2.example.com.

If ns1.example.com returns an A record pointing to 192.0.2.1, but 192.0.2.1 is down, the resolver must resolve ns1.example.com first, potentially causing a cascade of failures.

A common diagnostic is dig +trace, which shows the full path of resolution:

$ dig +trace api.example.com

This outputs:

; <<>> DiG 9.18.12 <<>> +trace api.example.com
;; global options: +cmd
.                       3600    IN  NS  a.root-servers.net.
.                       3600    IN  NS  b.root-servers.net.
; ...
example.com.          300     IN  NS  ns1.example.com.
example.com.          300     IN  NS  ns2.example.com.
api.example.com.      300     IN  A   192.0.2.10

The trace reveals the chain: root servers → example.com servers → final answer.

Another failure mode is zone transfer timeout: a slave server fails to complete an AXFR due to a slow network or large zone. The master may time out, and the slave may fall back to IXFR or use a cached copy.

A critical silent failure is SOA serial mismatch: two masters report different serials, but the slave does not detect the change. This occurs when the master updates the zone but forgets to increment the serial number. The slave continues using an old version.

Monitoring and Maintenance

Monitoring DNS infrastructure involves checking:

A basic health check script uses dig and systemd:

#!/bin/bash
set -e

DOMAIN="example.com"
NAMESERVERS=("ns1.example.com" "ns2.example.com")

for ns in "${NAMESERVERS[@]}"; do
    echo "Checking $ns..."
    dig @${ns} ${DOMAIN} +short
done


for ns in "${NAMESERVERS[@]}"; do
    echo "SOA serial for $ns:"
    dig @${ns} SOA ${DOMAIN} +short
done

A failure in dig returns a non-zero exit code, triggering alerts.

Maintenance includes periodic zone file validation, serial number audits, and backup of zone files. A daily cron job may dump all zones:

0 2 * * * /usr/local/bin/dump-zones.sh

This script generates a zone-dump-$(date +%Y%m%d).tar.gz with all zone files, metadata, and logs.

DNS Resolution in Practice

When a service starts, it must resolve its hostname. A container in Kubernetes might resolve api.example.com via kube-dns:

apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  containers:
    - name: app
      image: myapp:v1
      env:
        - name: API_HOST
          value: "api.example.com"

The container’s DNS resolver queries 10.96.0.10 (the kube-dns service) and receives an A record.

If the A record is stale, the service may fail to connect. The container logs may show:

ERROR: Failed to connect to api.example.com: No such host

A nslookup from within the container confirms the issue:

$ nslookup api.example.com
Server:         10.96.0.10
Address:        10.96.0.10#53

Name:   api.example.com
Address: 192.0.2.10

But the actual A record is 192.0.2.11. The resolution is correct, but the record is not cached or not updated.

In this state, the service remains unavailable until the TTL expires, or until a manual dig or nslookup refreshes the cache.

Summary of Key Patterns

DNS infrastructure is not a single system but a layered, distributed protocol that must be understood as a whole. Its patterns—how records are stored, transferred, cached, and resolved—form the backbone of every networked service.

This page was rewritten on 18 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.