Domain Name System (DNS)

DNS (Domain Name System) translates a domain name like api.example.com into an IP address like 203.0.113.42 so your browser knows which server to connect to. It is a hierarchical, distributed database organized as a tree.

Resolution process: (1) Your browser checks its local cache. (2) If not cached, it asks the OS, which checks /etc/hosts and the OS resolver cache. (3) The OS resolver queries the configured recursive resolver (usually your ISP or a public resolver like 8.8.8.8). (4) The recursive resolver walks the DNS hierarchy: root nameserver → TLD nameserver (.com, .org) → authoritative nameserver for the domain. (5) The authoritative nameserver returns the answer. (6) The recursive resolver caches it for the TTL duration and returns it to the OS. (7) The OS caches it and returns it to the browser.

Each step is cached at multiple levels, so subsequent lookups are fast — usually under 1 ms from cache.

The most important DNS record types in system design:

A record: maps a hostname to an IPv4 address. example.com → 203.0.113.42. AAAA record: maps a hostname to an IPv6 address. CNAME (Canonical Name): maps a hostname to another hostname. www.example.com → example.com. Used for aliases. Cannot be used at the zone apex (root domain). NS (Name Server): specifies which servers are authoritative for a domain. Required for DNS delegation. MX (Mail Exchange): specifies mail servers for the domain. TXT: stores arbitrary text, commonly used for domain verification (SPF, DKIM, DMARC) and security. SOA (Start of Authority): contains metadata about the zone — primary nameserver, admin email, serial number, and refresh/retry/expiry intervals.

TTL (Time To Live) is how long a resolver is allowed to cache a DNS record before it must re-query the authoritative server. It is set by the domain owner in the zone file.

Short TTL (30–60 seconds): resolvers re-query frequently. Use when you need the ability to change IPs quickly — for example, during a failover, a migration, or a blue/green deployment. Downside: more queries hit your nameserver, and every user gets a slightly stale result during the TTL window.

Long TTL (300–3600 seconds): resolvers cache aggressively. Reduces query load on your nameserver and speeds up resolution for repeat visitors. Downside: changes take longer to propagate globally. If you need to change an IP, users with the old record cached keep hitting the old server until their TTL expires.

Best practice: run a short TTL (60–300s) normally for operational flexibility. Before a planned migration, drop the TTL to 60s 24–48 hours in advance so most clients have already picked up the low TTL before you make the IP change.

DNS can route traffic beyond simple hostname-to-IP mapping:

Weighted round robin: return different IP addresses with different weights. 80% of traffic goes to IP-A, 20% to IP-B. Used for A/B testing, gradual rollouts, and blue/green deployments.

Latency-based routing: the resolver returns the IP of the server with the lowest measured latency from the requesting client's region. Used by Route 53 and other global DNS services to route each user to the nearest data center.

Geolocation routing: return different IPs based on the geographic location of the client. Route EU users to EU servers, US users to US servers. Used for compliance (data residency), localization, and latency optimization.

Failover routing: primary record is returned normally; if a health check detects the primary is unhealthy, the DNS service automatically returns the secondary record. A managed form of active-passive failover using DNS.

Health checks: modern DNS services (Route 53, Cloudflare) run continuous health checks against your endpoints and automatically remove unhealthy IPs from DNS responses.

DNS is usually the first layer of a distributed system that a user's request touches. Design decisions:

Managed DNS services (Route 53, Cloudflare DNS, Google Cloud DNS) provide anycast DNS infrastructure, global health-check-based routing, and sub-millisecond resolution latency from edge nodes. Do not host your own nameservers for production services — the operational cost and reliability risk are not worth it.

DNS is eventually consistent — changes propagate over TTL windows and some resolvers ignore TTL and cache longer. Never rely on DNS as a real-time coordination mechanism. Assume propagation can take minutes to hours for full global consistency.

For service discovery within a cluster (microservices calling each other), DNS is often used in combination with a sidecar or service mesh (Kubernetes DNS, Consul DNS) to resolve service names to current pod/instance IPs without requiring clients to know about the registry directly.