DNS and Route 53

The Domain Name System (DNS) translates human-readable domain names into IP addresses. When a user types example.com, recursive resolvers query authoritative name servers to resolve the domain to an IP address. This hierarchy starts at root servers, moves to TLD servers (.com, .org), and finally to authoritative name servers that hold the actual records. Understanding DNS record types is essential for cloud networking.

A records map a domain to an IPv4 address (example.com to 93.184.216.34). AAAA records do the same for IPv6. CNAME records alias one domain to another (www.example.com to example.com); they cannot be used at the zone apex (the root domain itself) because the zone apex must have authoritative records. MX records specify mail servers for a domain and include priority values for fallback. TXT records store arbitrary text, commonly used for domain verification (SPF, DKIM, DMARC for email authentication). SRV records define host and port for specific services. NS records delegate a subdomain to specific name servers.

Route 53 is AWS's authoritative DNS service. Hosted zones are containers for DNS records for a domain. Public hosted zones respond to DNS queries from the internet; private hosted zones resolve resources within one or more VPCs using Amazon DNS servers. Creating a hosted zone in Route 53 automatically generates four name servers (NS records). You must delegate your domain to these name servers at your registrar to make Route 53 the authoritative source for your domain's DNS.

Record sets in Route 53 include a name, type, value, and TTL (Time To Live). TTL determines how long resolvers cache the record before re-querying. Short TTLs (60 seconds) enable fast failover but increase query costs and load. Long TTLs (300-3600 seconds) reduce costs and improve latency but slow change propagation. The default TTL is 300 seconds. Route 53 also supports alias records, which map to AWS resources (ALBs, CloudFront distributions, S3 website endpoints) and automatically track IP changes, offering a significant advantage over standard CNAME records.

Route 53 supports multiple routing policies that determine which value is returned for a DNS query. The simple routing policy returns a single value with no special logic, suitable for most single-resource configurations. Weighted routing distributes traffic across multiple resources based on assigned weights (0-255). A resource with weight 100 and another with weight 50 receive approximately 67% and 33% of traffic respectively. This enables gradual rollouts, A/B testing, and canary deployments.

Latency-based routing returns the region with the lowest network latency to the requester. Route 53 maintains latency measurements to AWS regions and selects the optimal endpoint. This is ideal for multi-region architectures where user experience depends on response time. Failover routing monitors a primary resource and redirects traffic to a secondary resource when the primary becomes unhealthy. This requires health checks and is the foundation of DNS-based disaster recovery.

Geolocation routing returns different values based on the geographic location of the resolver (continent, country, or state). This enables content localization, regulatory compliance (restricting access by country), and language-specific routing. Geoproximity routing is similar but allows biasing toward specific regions using a bias value from -99 to 99, enabling fine-grained traffic distribution. Multivalue answer routing returns multiple healthy IP addresses, providing basic load balancing without a dedicated load balancer.

Health checks are critical for failover and weighted routing. Route 53 health checks poll endpoints at configurable intervals (30 seconds or 10 seconds for fast health checks). A health check fails after three consecutive failures and recovers after three consecutive successes. You can check HTTP/HTTPS endpoints (validating response codes), TCP connections, or even CloudWatch alarms. Health checks can monitor parent health checks to create composite health checks, enabling complex dependency monitoring. For private hosted zones, health checks use CloudWatch metrics since internal endpoints are not publicly reachable.