/dns

name: dns
description: This skill should be used when the user asks about "DNS", "domain resolution", "GeoDNS / geo routing", "latency-based routing", "weighted / failover routing", "Route 53 / Cloud DNS", an "A/CNAME/ALIAS record", "anycast", or "DNS TTL / propagation". It gives the global front door that maps a name to the right IP and steers users to the right region or endpoint. Use it whenever a design must direct traffic across regions/data centers, do health-checked failover at the name layer, or expose a stable hostname even if the user doesn't say "DNS".

DNS

DNS is the global front door: it turns a name (`api.example.com`) into an address *before any request reaches your servers*. It is also a routing layer — the same lookup can hand different clients different answers (by region, latency, health, or weight). Get it wrong and clients reach a dead region, fail over in minutes instead of seconds, or cache a bad answer for hours. It is not a load balancer and not a CDN; it decides *which endpoint a client is told to use*, not how bytes are balanced inside that endpoint.

When to reach for this

A service is reachable by a stable hostname; traffic must be steered to the closest or healthiest region/data center; or an endpoint's IP can change (a new load balancer, a failover site) and clients must follow without code changes. Multi-region or multi-data-center designs need DNS to pick the entry point; single-region designs still need it for a stable, movable name.

When NOT to

Routing *inside* one region — that is a load balancer's job (→ `load-balancing`), which reacts in milliseconds, not TTL-bound minutes. Fine-grained per-request or session-aware steering — DNS answers per lookup, then the client caches it. Fast failover with sub-second recovery — DNS failover is gated by TTL and resolver caching; do not promise instant cutover from the name layer. And do not reach for exotic routing policies before a number shows users are spread across regions (YAGNI) — a single `A`/`ALIAS` record is the right default for one region.

Clarify first

• **Geographic spread** — one region or many? Where are the users? (→ `requirements-scoping`)
• **Failover target** — recovery time objective for losing a region: seconds, or "a few minutes is fine"?
• **How dynamic is the endpoint** — fixed IPs, or an LB hostname that changes? (drives `A` vs `CNAME`/`ALIAS`)
• **Steering goal** — closest by latency, by user geography, by weight (canary/A-B), or just round-robin?
• **Staleness tolerance for the mapping** — how long can a client keep a stale answer? (sets the TTL → `back-of-the-envelope`)

The options

**Record type (what the name returns)**

• **`A` / `AAAA`** — name → IPv4 / IPv6. Use when the endpoint has a stable IP.
• **`CNAME`** — name → another name. Use to alias onto a provider hostname; never at the zone apex (`example.com`).
• **`ALIAS` / `ANAME`** (provider-specific) — apex alias to a hostname. Use to point `example.com` at an LB/CDN hostname.
• **`NS` / `MX` / `TXT`** — delegation, mail, verification. Use as the domain requires; not traffic steering.

**Routing policy (which answer a client gets)**

• **Simple** — one answer for everyone. Use for a single endpoint.
• **Weighted** — split by percentage. Use for canary, A/B, or shifting between clusters.
• **Latency-based** — answer the region with lowest measured latency to the resolver. Use to minimize round-trip.
• **Geolocation / GeoDNS** — answer by the *client's* location (data residency, localized content). Use when geography, not latency, must decide.
• **Failover** — primary while healthy, else secondary. Use for active-passive DR.
• **Multivalue** — return several healthy IPs; client picks. Use for cheap client-side spread with health pruning.

**Reachability**

• **Anycast** — one IP advertised from many sites; the network routes to the nearest. Use for resolver/CDN front ends and DDoS resilience (concept lives in `content-delivery`).

Trade-offs

| Option | What it solves | What it worsens | Change it when | |---|---|---|---| | Simple `A`/`ALIAS` | Trivial; one stable name | No steering, no failover; SPOF if the IP dies | Traffic spans regions or needs DR → weighted/latency/failover | | Weighted | Gradual shifts, canary, cluster balancing | Manual/slow; not health-aware unless paired with checks | You need automatic closeness → latency; or automatic cutover → failover | | Latency-based | Lowest RTT per user automatically | Routes to *resolver* location, not user; needs per-region endpoints | Data residency matters more than speed → geolocation | | Geolocation | Compliance, localized answers | Misroutes via VPN/forwarding resolvers; coarse map | Speed matters more than geography → latency-based | | Failover | Automatic active-passive cutover | Recovery bounded by TTL + caching; cold standby risk | RTO must be sub-second → in-region LB, not DNS | | Anycast | Nearest entry + absorbs DDoS | Operationally heavy (BGP); flap on route changes | You only have one site → not worth it |

Behavior under stress

DNS fails in slow, wide ways — a bad answer or an authoritative outage affects *everyone who looks up next*, and lingers as long as TTLs allow.

• **TTL caching delays recovery and propagation.** Resolvers and OS/browser

caches hold answers for the TTL; some ISPs over-cache. A failover or IP change only takes effect as old entries expire — the *effective* recovery time is TTL plus stragglers, not zero.

• **Authoritative DNS as a SPOF.** If your authoritative servers (or a single

managed zone) go down, *nothing* resolves, even though your servers are healthy. Use a provider on anycast across many sites; consider a secondary DNS provider.

• **Health-check stampede / flapping.** Aggressive health checks across many

endpoints can hammer targets, and a flapping check can oscillate answers, scattering clients. Tune interval, failure threshold, and require N consecutive failures (→ `resilience-failure`