DNS Deep Dive

DNS translates names to addresses. The conceptual model is simple; the operational reality is full of edge cases. DNS issues are a frequent source of production problems — slow lookups, stale caches, propagation delays, DNS-server failures.

This page covers the parts that matter for application engineers.

How resolution works

When a process needs to resolve example.com:

  1. Local cache: OS or process-level cache. Fast.
  2. Stub resolver in the OS sends UDP query to configured DNS server.
  3. Recursive resolver (your ISP, 8.8.8.8, etc.) does the actual work:
    • Queries root nameservers
    • Queries TLD nameservers (.com)
    • Queries authoritative nameservers for example.com
    • Returns answer
  4. Response cached at multiple levels with TTL.
  5. Address returned to your process.

The recursive resolver does most of the heavy work. The stub on your machine is simple.

Record types

Common types:

For application code, A/AAAA is dominant. CNAME is common for "point to managed service" patterns (CloudFront distribution, ALB).

Caching and TTL

Every DNS response includes a TTL. Resolvers cache for that duration.

Common TTLs:

TTL trade-off:

When planning a change, lower the TTL well in advance (1 day before), make the change, raise the TTL after.

Propagation

"DNS propagation" is the time for changes to be visible everywhere. Determined by:

You can lower TTL in advance to bound propagation. Once the new value is published, all caches expire within their TTL and pick up the new value.

The "DNS takes 24-48 hours to propagate" advice exists because:

  1. Some old records had 24-hour TTLs
  2. Resolver caching is sometimes longer than TTL says
  3. Some resolvers misbehave

For most modern setups with reasonable TTLs, propagation is minutes, not days.

DNS in cloud

Cloud providers offer managed DNS:

Features beyond basic resolution:

These are useful for managing global services without per-region client logic.

DNS as load balancing

Common pattern: DNS returns multiple A records; clients pick one.

example.com → 10.0.0.1, 10.0.0.2, 10.0.0.3

Pros:

Cons:

For traffic distribution within a data center, dedicated load balancers are better. DNS load balancing is for cross-region or cross-data-center routing.

Common DNS issues

Stale cache

Application has cached IP that's no longer valid. Causes:

For long-running connections to a hostname that may move (managed databases, cloud services), build in periodic re-resolution.

Lookups blocking

DNS resolution is synchronous. A slow DNS server makes every connection slow.

In Java: InetAddress.getByName() blocks. Use a connection pool or async resolution.

IPv6 vs. IPv4

If a hostname has both A and AAAA records, the application picks one. Some networks have broken IPv6; the application falls back to IPv4 after timeout. The fallback adds latency.

Modern apps use "happy eyeballs" — try both simultaneously, pick the first to succeed.

DNSSEC

DNS responses are not authenticated by default. DNSSEC provides cryptographic signing. Adoption is partial; most public DNS doesn't use it. Server-to-server within infrastructure usually skips DNSSEC.

CNAME at apex

The DNS spec doesn't allow CNAME at the apex of a domain (example.com, not www.example.com). Some providers offer "ALIAS" or "ANAME" records that simulate this; behavior varies.

For services hosted at apex pointing to cloud-managed endpoints, this can be awkward.

Common failure patterns

Further Reading