AWS Route 53¶

Three functions in one service:
  1. Domain Registration    → buy and manage domain names
  2. DNS Management         → host DNS records for your domains
  3. Health Checking        → monitor endpoints and failover automatically

User types: ibtisam-iq.com in browser

Step 1: Browser checks local DNS cache (OS cache)
  → If cached and TTL not expired → use cached IP, done

Step 2: Browser asks Recursive Resolver (your ISP or 8.8.8.8)
  → Recursive Resolver checks its own cache
  → If cached → return IP, done

Step 3: Recursive Resolver asks Root Name Server (.)
  → Root Server: "I don't know ibtisam-iq.com, but .com is handled by these TLD servers"
  → Returns TLD server addresses for .com

Step 4: Recursive Resolver asks TLD Name Server (.com)
  → TLD: "I don't know the IP, but the authoritative server is ns-123.awsdns-45.com"
  → Returns authoritative server addresses

Step 5: Recursive Resolver asks Authoritative Name Server (Route 53)
  → Route 53: "ibtisam-iq.com → 3.14.15.92"
  → Returns the actual IP address

Step 6: Browser connects to 3.14.15.92
  → Result cached by Recursive Resolver for TTL duration

Key insight:
  Root Server   → knows who handles each TLD (.com, .io, .pk)
  TLD Server    → knows which name server is authoritative for each domain
  Auth Server   → knows the actual IP (Route 53 is this for your domain)
  Only the Authoritative Server has your real DNS records

Your personal site setup (example):
  GoDaddy     → Registrar (you own ibtisam-iq.com)
  Cloudflare  → DNS provider + CDN + WAF
  GitHub Pages → Hosting (where HTML/CSS/JS files live)

Flow:
  User → Cloudflare DNS (resolves domain) → Cloudflare Edge (CDN cache)
       → GitHub Pages (origin server, if cache miss)

Step 1: Create Hosted Zone in Route 53 for your domain
  → Route 53 gives you 4 name servers:
    ns-1234.awsdns-12.com
    ns-5678.awsdns-34.net
    ns-9012.awsdns-56.org
    ns-3456.awsdns-78.co.uk

Step 2: Log in to GoDaddy → change Name Servers to the above 4
  → GoDaddy now says: "For ibtisam-iq.com, ask Route 53"
  → Propagation: 24–48 hours for global DNS caches to update

You are delegating DNS authority from GoDaddy → Route 53
GoDaddy still owns the domain registration
Route 53 now controls all DNS records

Public Hosted Zone: ibtisam-iq.com
  → api.ibtisam-iq.com → 3.14.15.92    (public EC2)
  → www.ibtisam-iq.com → CloudFront
  → mail.ibtisam-iq.com → MX records

Private Hosted Zone: internal.corp
  → db.internal.corp → 10.0.2.15       (private RDS IP)
  → cache.internal.corp → 10.0.3.8     (private ElastiCache)
  (Only visible to EC2 inside your VPC — internet cannot resolve these)

Name: ibtisam-iq.com
Type: A
Value: 3.14.15.92
TTL: 300

Usage: point root domain or subdomain to an IPv4 address

Name: ibtisam-iq.com
Type: AAAA
Value: 2001:0db8:85a3::8a2e:0370:7334
Usage: IPv6 traffic

Name: www.ibtisam-iq.com
Type: CNAME
Value: ibtisam-iq.com
TTL: 300

Usage: alias one domain to another
Restriction: CNAME CANNOT be used at the zone apex (root domain)
  ❌ ibtisam-iq.com CNAME something.com   ← invalid per DNS spec
  ✅ www.ibtisam-iq.com CNAME something.com  ← valid (subdomain)

Name: ibtisam-iq.com
Type: MX
Priority: 10
Value: mail.ibtisam-iq.com

Multiple MX records with different priorities → mail tries lowest priority number first

Name: ibtisam-iq.com
Type: TXT
Value: "v=spf1 include:_spf.google.com ~all"       ← SPF (prevents email spoofing)
Value: "google-site-verification=abc123..."         ← verify domain for Google Search Console
Value: "MS=ms12345..."                              ← verify for Microsoft 365

Name: ibtisam-iq.com
Type: NS
Value: ns-1234.awsdns-12.com
       ns-5678.awsdns-34.net
       ...

Delegates authority for domain (or subdomain) to these name servers

Name: 92.15.14.3.in-addr.arpa
Type: PTR
Value: mail.ibtisam-iq.com

Usage: verify that IP 3.14.15.92 belongs to ibtisam-iq.com
Used by: email servers to validate sending IP

Usage: Kubernetes, SIP, XMPP
Format: priority weight port target

Problem:
  You have an ELB: my-lb-123.us-east-1.elb.amazonaws.com
  You want: ibtisam-iq.com → my ELB
  But CNAME cannot be set on zone apex (ibtisam-iq.com)

Solution: Alias Record
  Name: ibtisam-iq.com
  Type: A (Alias)
  Alias target: my-lb-123.us-east-1.elb.amazonaws.com
  → Works at zone apex ✅
  → Route 53 automatically resolves the ELB to its current IP(s)
  → If ELB IPs change, Alias auto-updates — no manual intervention

TTL = how long (seconds) a DNS resolver should cache the record before asking again

Low TTL (60–300s):
  ✅ DNS changes propagate quickly
  ❌ More DNS queries → more Route 53 cost
  Use before planned changes (reduce TTL 24h before migration)

High TTL (3600–86400s):
  ✅ Faster response (cache hit), less Route 53 cost
  ❌ DNS changes take longer to propagate
  Use for stable records that rarely change

Practical rule:
  Normal operations:      300s–3600s
  Before a migration:     Set to 60s (24hrs in advance)
  After migration stable: Increase back to 3600s

One record → one or more IPs (no health checks on single record)
Multiple IPs in one record → client picks one at random

Use: single backend, basic setups
Limitation: no health checks → client may pick unhealthy IP

Multiple records with same name, different weights
Route 53 distributes traffic proportionally to weights

Example:
  Record A: 10.0.0.1  Weight: 70
  Record B: 10.0.0.2  Weight: 20
  Record C: 10.0.0.3  Weight: 10
  → 70% → A, 20% → B, 10% → C

Use cases:
  A/B testing new version (send 5% to v2)
  Gradual traffic migration (shift 0→10→50→100% to new region)
  Load distribution across servers

Weight = 0 → record not served (stop traffic without deleting record)

Routes user to the AWS Region with lowest network latency (not geographic distance)
Route 53 measures latency from user's location to each configured region

Example:
  User in Pakistan:
    Record: ec2-us-east-1.amazonaws.com   Region: us-east-1    latency: 180ms
    Record: ec2-me-south-1.amazonaws.com  Region: me-south-1   latency: 40ms
    → Route to me-south-1 (Bahrain) ✅

Note: latency ≠ geographic proximity always — routing is based on measured network

Primary record: serves traffic when healthy
Secondary record: serves traffic when primary health check fails

Primary:   10.0.0.1  Type: PRIMARY   Health check: required
Secondary: 10.0.0.2  Type: SECONDARY Health check: optional

Flow:
  Primary healthy → all traffic → primary
  Primary fails health check → Route 53 automatically serves secondary
  Primary recovers → traffic returns to primary

Use case: active-passive disaster recovery

Routes based on the geographic location of the DNS query origin
  (the country/continent of the user's recursive resolver)

Records:
  Location: US → 1.2.3.4
  Location: EU → 5.6.7.8
  Location: Default → 9.10.11.12  ← REQUIRED fallback for unmatched locations

Example:
  French user → EU record
  Brazilian user → Default record (no South America record)
  US user → US record

Use cases:
  Legal compliance (GDPR — EU users must hit EU servers)
  Content localization (language-specific content)
  Blocking regions (no default record = users from other regions get NXDOMAIN)

Routes based on geographic distance between user and resource
  WITH optional bias to expand/shrink effective geographic region

Bias: +1 to +99 (expand region) or -1 to -99 (shrink region)

Bias formula:
  Biased distance = actual distance × [1 - (bias/100)]
  Positive bias = resource appears closer → attracts more traffic
  Negative bias = resource appears farther → attracts less traffic

Example:
  Server A: us-east-1, bias: +50
  Server B: eu-west-1, bias: 0
  User equidistant between A and B:
    → A gets more traffic (positive bias makes A appear 50% closer)

Use case:
  Shift traffic from one region to another gradually
  Requires Route 53 Traffic Flow (visual editor)

Returns up to 8 healthy IP addresses per DNS query
Client randomly picks one from the returned list

Similar to: Simple routing with multiple IPs
Difference: integrates with health checks — unhealthy IPs removed from response

Use case:
  Distribute traffic across multiple web servers without a load balancer
  NOT a replacement for a proper load balancer (ELB)

Routes based on client's IP address CIDR range
You define CIDR collections → map each collection to an endpoint

Example:
  CIDR: 203.0.113.0/24 (corporate network) → internal server
  CIDR: 0.0.0.0/0 (everyone else) → public server

Use cases:
  Corporate VPN users → internal resources
  ISP-specific routing (partner ISPs → dedicated capacity)
  Regional routing by known IP ranges

Monitors: IP address or domain name
Protocol: HTTP, HTTPS, TCP
Interval: 30s (standard) or 10s (fast — additional cost)
Failure threshold: 3 failures = unhealthy (configurable 1–10)
String matching: check for specific string in response body (first 5,120 bytes)

Health check passes if:
  HTTP/HTTPS: response code 2xx or 3xx AND (optional) string found
  TCP: connection established successfully

Combines results of multiple child health checks
Logic options: AND (all must pass), OR (any must pass), NOT
Min healthy count: specify minimum N children must be healthy

Use case:
  Application is healthy only if: web layer healthy AND database layer healthy
  → Create child checks for each → calculated check combines them

Based on a CloudWatch alarm state (OK / ALARM / INSUFFICIENT_DATA)
Use case: private resources (EC2 in VPC) — Route 53 health checkers
          cannot reach private IPs directly
  → Create CloudWatch metric on private resource
  → Create alarm on that metric
  → Route 53 monitors the alarm state

Route 53 health checkers run from public internet
  → Cannot reach private EC2 instances or private RDS

Solution:
  1. CloudWatch Metric + Alarm on private resource
  2. Route 53 Calculated/CloudWatch Alarm health check monitors the alarm
  → Indirect but effective health monitoring

You can delegate a subdomain to a different hosted zone or team:

Main company:  example.com           hosted in central Route 53
API team:      api.example.com       delegated to team's own hosted zone

In main hosted zone:
  NS record: api.example.com → ns-api-1.awsdns-xx.com
                                 ns-api-2.awsdns-xx.net
  → DNS queries for api.example.com forwarded to team's name servers
  → Team manages all api.example.com records independently

domain: ibtisam-iq.com
  → Route 53 Alias → CloudFront distribution
  → CloudFront origin → S3 static bucket

Benefits:
  HTTPS on root domain (Alias + ACM certificate)
  Global CDN caching
  No direct S3 access (bucket can be private, only CloudFront reads it)

Every VPC has a built-in DNS resolver at:
  VPC base IP + 2 (e.g., 10.0.0.2 for a 10.0.0.0/16 VPC)
Resolves: AWS public hostnames, private hosted zones attached to VPC

On-premises DNS servers can resolve AWS private hosted zone records

On-premises → VPN/Direct Connect → Inbound Endpoint (in VPC)
  → Route 53 Resolver resolves private hosted zone record
  → Returns IP → back to on-premises application

Use case: on-premises app calls internal AWS microservice by private DNS name

VPC resources can resolve on-premises DNS names

EC2 in VPC → Outbound Endpoint → forwarding rule → on-premises DNS server
  → On-premises server resolves corp.internal domain
  → Returns IP → EC2 connects to on-premises resource

Use case: AWS Lambda needs to connect to on-premises database using internal hostname

Forwarding rule: "for domain corp.internal, forward queries to 10.1.1.53"
System rule: built-in rules for AWS private hosted zones (auto-managed)
Recursive rule: default — resolve everything else using public DNS