DNS and global load balancing are foundational to any internet-scale system. Understanding how DNS resolution works, how GeoDNS routes traffic, and how Anycast achieves global availability are essential for senior engineering interviews at companies like Cloudflare, Akamai, and any company operating a global platform.
DNS Resolution: The Full Chain
User types "api.example.com":
1. Browser cache (TTL-based, typically 60s)
2. OS stub resolver → OS cache (/etc/hosts, local cache)
3. Recursive resolver (ISP or 8.8.8.8 / 1.1.1.1)
├── Resolver cache hit? → return cached answer
└── Cache miss → iterative resolution:
a. Root nameservers (13 logical servers, Anycast)
→ "com. is at .com TLD servers: a.gtld-servers.net"
b. .com TLD servers
→ "example.com is at ns1.example.com"
c. Authoritative nameserver (ns1.example.com)
→ "api.example.com → 203.0.113.10, TTL 60"
4. Recursive resolver caches answer, returns to client
5. Client connects to 203.0.113.10Record Types
| Record | Purpose | Example |
|---|---|---|
| A | Domain → IPv4 | api.example.com → 1.2.3.4 |
| AAAA | Domain → IPv6 | api.example.com → 2001:db8::1 |
| CNAME | Alias to another domain | www → api.example.com |
| MX | Mail exchange | example.com → mail.example.com |
| TXT | Arbitrary text (SPF, DKIM) | v=spf1 include:sendgrid.net |
| NS | Authoritative nameservers | example.com → ns1.example.com |
| SRV | Service location + port | _https._tcp → host:port |
GeoDNS: Route by Client Location
GeoDNS authoritative server receives query from resolver IP:
1. Look up resolver IP in GeoIP database (MaxMind, IP2Location)
2. Map IP → region (US-EAST, EU-WEST, APAC)
3. Return A record for nearest data center:
US client → 203.0.113.10 (us-east-1 VIP)
EU client → 198.51.100.5 (eu-west-1 VIP)
APAC client → 192.0.2.20 (ap-southeast-1 VIP)
Limitation: resolver IP ≠ client IP
- ISP resolvers aggregate client traffic → wrong geolocation
- Fix: EDNS Client Subnet (ECS): resolver forwards /24 client subnet
to authoritative nameserver for accurate geolocation
TTL tuning for GeoDNS:
Normal operation: TTL 60-300s (fast propagation)
Before planned failover: lower TTL to 30s
After failover stabilized: raise TTL back to 300sAnycast: The Global Load Balancing Technique
Anycast: same IP address announced from multiple locations via BGP
- 1.1.1.1 is Cloudflare's anycast IP, announced from 300+ PoPs
- Internet routing (BGP) naturally routes to the closest PoP
- No DNS changes needed — routing is done at the network layer
How it works:
PoP-US: BGP announces "I have route to 1.1.1.1"
PoP-EU: BGP announces "I have route to 1.1.1.1"
PoP-APAC: BGP announces "I have route to 1.1.1.1"
EU client packet → nearest BGP hop → chooses PoP-EU
(if PoP-EU goes down, BGP reconverges → routes to PoP-US)
Used by: DNS (root servers, Cloudflare 1.1.1.1),
CDN edge nodes, DDoS scrubbing centersGlobal Load Balancing Architecture
Tier 1: DNS-Based Routing (GeoDNS or Traffic Manager)
api.example.com → regional VIP (per-client-location)
Tier 2: Regional Load Balancer (L4/L7)
Regional VIP → pool of application servers
Health checks: TCP (L4), HTTP GET /health (L7)
Algorithms: round-robin, least-connections, IP-hash
Tier 3: Service Mesh / Internal LB
Service-to-service within region (Envoy sidecar, AWS ALB)
Full path:
Client → GeoDNS → Regional LB (AWS ALB/GCP GLB) → InstanceHealth Checks and Failover
DNS-based failover flow:
Health checker → polls endpoint every 10s
3 consecutive failures → mark unhealthy
→ Update DNS: remove unhealthy A record
→ Clients get healthy IP on next DNS resolution
→ TTL determines propagation lag (reason to keep TTL low)
Active-passive vs active-active:
Active-passive: traffic only to primary; failover to secondary
(simpler, but wastes capacity)
Active-active: traffic to all regions simultaneously
(requires sticky sessions or stateless services)
GeoDNS serves each region its own VIP — all VIPs are "active"CDN Integration
CNAME delegation to CDN:
api.example.com CNAME api.example.com.cdn.cloudflare.net
→ Cloudflare resolves to nearest edge PoP IP
Request flow with CDN:
1. Client → CDN edge (nearest PoP)
2. Cache hit → return cached response (no origin touch)
3. Cache miss → CDN → origin server → cache response
4. CDN returns to client with cache headers
Cache-Control strategy:
Static assets: Cache-Control: max-age=31536000, immutable
API responses: Cache-Control: no-cache (or short TTL + ETag)
HTML pages: Cache-Control: max-age=60, stale-while-revalidate=300Rate of Propagation and TTL Strategy
DNS change propagation is NOT instant — it's TTL-limited:
- Each cached answer lives until TTL expires
- Change propagation = up to current-TTL seconds
- During outage: lowering TTL only helps for future resolvers
Best practice playbook:
24h before planned migration:
Lower TTL from 3600s → 300s
Wait 1 hour for old long-TTL caches to expire
Migration time:
Update A record
Propagation < 300s (5 min) for most resolvers
After stabilization:
Raise TTL back to 3600sDNSSEC: Securing DNS
Problem: DNS responses can be forged (cache poisoning attack)
DNSSEC: cryptographic signatures on DNS records
Chain of trust:
Root zone signs → .com zone public key
.com zone signs → example.com zone public key
example.com signs → A record for api.example.com
Resolver validates chain from root → authoritative
Forged responses fail signature verification → rejected
Adoption: ~30% of domains signed; ~50% of resolvers validate
Trade-offs: higher response size, more complex key management,
zone enumeration possible with NSEC recordsInterview Discussion Points
- DNS vs Load Balancer for failover: DNS failover is slow (TTL-bounded) and coarse-grained. L4/L7 load balancers detect failures in seconds and route around them without DNS changes. Use DNS for region-level routing, LB for instance-level routing.
- Why not always use Anycast? Anycast is great for UDP (DNS) but problematic for TCP — a connection can be torn apart if BGP reconverges and packets route to a different PoP mid-connection. Mitigation: GRE tunneling back to a central origin, or application-level reconnect logic.
- CNAME flattening: CNAME records cannot coexist with other records at the zone apex (example.com). Route53, Cloudflare use “ALIAS” or “CNAME flattening” — they resolve the CNAME target and return its A records directly, enabling apex-domain CDN delegation.
- How does Cloudflare handle 300+ PoPs? Each PoP runs the full stack (DNS resolver, DDoS scrubbing, WAF, HTTP proxy, cache). Anycast routes clients to nearest PoP. Within a PoP, traffic is load-balanced across servers. PoPs share a global configuration store but cache and handle traffic independently.
{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “How does GeoDNS route traffic to the nearest data center?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “GeoDNS authoritative nameservers look up the querying resolver’s IP address in a GeoIP database (e.g., MaxMind) to determine its geographic region, then return the A record pointing to the nearest data center’s VIP. The limitation is that resolver IP often doesn’t match client location (ISP resolvers aggregate many clients). EDNS Client Subnet (ECS) solves this: the resolver forwards the client’s /24 subnet to the authoritative nameserver, enabling accurate geolocation. TTLs are kept short (60-300s) to enable fast failover when a region goes down.”
}
},
{
“@type”: “Question”,
“name”: “What is Anycast and how is it different from GeoDNS for global traffic routing?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Anycast advertises the same IP address from multiple geographic locations via BGP. Internet routing naturally directs packets to the topologically closest location announcing that IP. Unlike GeoDNS (which routes at DNS resolution time using IP geolocation), Anycast routes at the network layer for every packet u2014 no DNS changes needed. Anycast is ideal for UDP (DNS, NTP) and short TCP sessions but tricky for long-lived TCP connections since BGP reconvergence can redirect mid-connection packets to a different PoP. Cloudflare uses Anycast for both its 1.1.1.1 DNS resolver and its CDN edge nodes.”
}
},
{
“@type”: “Question”,
“name”: “Why should DNS TTLs be lowered before a planned failover or migration?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “DNS answers are cached by resolvers for the duration of the TTL. If your current A record has TTL=3600 and you change it, the old IP stays cached for up to an hour in resolvers worldwide. To minimize failover time, lower TTL to 30-300s at least one TTL-cycle before the planned change (so caches expire with the new short TTL). After the change, cached entries expire quickly and clients resolve the new IP. After stabilization, raise TTL back to a higher value (1800-3600s) to reduce resolver load and improve performance.”
}
}
]
}