Amazon Route 53 là dịch vụ Domain Name System (DNS) có tính sẵn sàng cao và khả năng mở rộng của AWS. Tên "Route 53" lấy từ cổng 53 - cổng tiêu chuẩn của giao thức DNS.
DNS (Domain Name System) là hệ thống "danh bạ điện thoại" của Internet, chuyển đổi tên miền thành địa chỉ IP.
Quan trọng: DNS là hệ thống phân tán toàn cầu, KHÔNG phải do AWS quản lý. Route 53 chỉ là một trong nhiều dịch vụ Authoritative DNS mà bạn có thể chọn.
┌─────────────────────────────────────────────────────────────────────────────┐│ DNS Cache Layers ││ ││ ① Browser Cache ││ └── Chrome, Firefox... cache DNS records ││ └── Thời gian: vài phút đến vài giờ ││ └── Clear: chrome://net-internals/#dns ││ ││ ② OS Cache (Local DNS Cache) ││ └── Windows: DNS Client service ││ └── Linux: systemd-resolved, nscd ││ └── macOS: mDNSResponder ││ └── Clear: ipconfig /flushdns (Windows), sudo dscacheutil -flushcache ││ ││ ③ DNS Resolver Cache (ISP hoặc Public DNS) ││ └── ISP DNS servers ││ └── Google 8.8.8.8 ││ └── Cloudflare 1.1.1.1 ││ └── Cache theo TTL của record ││ ││ ④ Authoritative DNS (Route 53) ││ └── KHÔNG cache - đây là nguồn chính thức! │└─────────────────────────────────────────────────────────────────────────────┘
Flow khi query:
Browser gõ example.com │ ▼① Check Browser Cache ──── Có? → Dùng luôn, XONG │ Không ▼② Check OS Cache ────────── Có? → Dùng luôn, XONG │ Không ▼③ Hỏi DNS Resolver ─────── Có cache? → Trả về, XONG │ Không ▼④ Resolver hỏi Root → TLD → Authoritative DNS (Route 53) │ ▼ Cache kết quả theo TTL tại ③②① rồi trả về
DNS Zone = "Vùng quản lý" của một domain và các subdomain của nó. DNS Zone chứa tất cả DNS records liên quan đến domain đó.
┌─────────────────────────────────────────────────────────────────┐│ Domain: example.com ││ │ ││ ▼ ││ DNS Zone: Chứa tất cả thông tin DNS của domain ││ │ ││ ├── NS record (ai quản lý zone này) ││ ├── SOA record (metadata zone) ││ ├── A record (domain → IP) ││ ├── CNAME record (alias) ││ └── ... các records khác │└─────────────────────────────────────────────────────────────────┘
Khi bạn tạo một Hosted Zone, AWS tự động tạo 2 loại records bắt buộc:
┌─────────────────────────────────────────────────────────────────┐│ KHI TẠO HOSTED ZONE, AWS TỰ ĐỘNG TẠO: ││ ││ ① NS Record (Name Server) ││ └── Chỉ ra 4 name servers quản lý zone này ││ ││ ② SOA Record (Start of Authority) ││ └── Metadata quản trị của zone │└─────────────────────────────────────────────────────────────────┘
NS Record chứa danh sách 4 Name Servers của AWS quản lý zone của bạn:
┌─────────────────────────────────────────────────────────────────┐│ Route 53 assign 4 Name Servers cho Hosted Zone của bạn: ││ ││ ns-123.awsdns-45.com (TLD .com) ││ ns-456.awsdns-78.net (TLD .net) ││ ns-789.awsdns-12.org (TLD .org) ││ ns-012.awsdns-34.co.uk (TLD .co.uk) ││ ││ → 4 TLDs khác nhau = High Availability! ││ → Nếu .com TLD bị sự cố, vẫn còn .net, .org, .co.uk hoạt động ││ → Phân tán trên 100+ AWS Edge Locations toàn cầu │└─────────────────────────────────────────────────────────────────┘
Khi nào cần dùng NS Record?
Khi bạn mua domain ở nhà cung cấp khác (GoDaddy, Namecheap...) và muốn dùng Route 53 quản lý DNS
→ Copy 4 NS này vào cài đặt nameserver của domain tại registrar
SOA Record = "Giấy chứng nhận quyền sở hữu" của DNS Zone, chứa thông tin quản trị.
┌─────────────────────────────────────────────────────────────────┐│ SOA RECORD - MỤC ĐÍCH: ││ ││ ① Xác định ai là "chủ" của zone ││ └── Primary name server, admin email ││ ││ ② Đồng bộ giữa Primary và Secondary DNS servers ││ └── Serial number: tăng mỗi khi có thay đổi ││ └── Refresh: Secondary check Primary sau bao lâu ││ └── Retry: Nếu fail, thử lại sau bao lâu ││ └── Expire: Ngừng phục vụ nếu mất liên lạc quá lâu ││ ││ ③ Negative Caching (TTL cho "không tìm thấy") ││ └── Cache "record không tồn tại" trong bao lâu │└─────────────────────────────────────────────────────────────────┘
Khi workload trong VPC cần resolve domain private của hệ thống on-premises (qua Site-to-Site VPN/Direct Connect), bạn dùng Route 53 Resolver endpoints + forwarding rules.
EC2/App trong VPC -> VPC Resolver (VPC+2) -> Rule forward cho domain on-prem (vd: corp.internal) -> Route 53 Resolver Outbound Endpoint -> On-prem DNS server (qua Site-to-Site VPN / DX) -> Trả kết quả ngược lại về ứng dụng
Nếu có nhiều A records cùng tên domain, DNS trả về tất cả IPs và client chọn random:
┌─────────────────────────────────────────────────────────────────┐│ Type: A │ Name: example.com │ Value: 152.42.220.42 ││ Type: A │ Name: example.com │ Value: 152.42.220.43 ││ Type: A │ Name: example.com │ Value: 152.42.220.44 │└─────────────────────────────────────────────────────────────────┘Query example.com → DNS trả về 3 IPs → Client chọn RANDOM 1→ Đây gọi là "DNS Round Robin" (Load Balancing đơn giản)→ Nhược điểm: Không có health check, server chết vẫn có thể được chọn!→ Production nên dùng Load Balancer thay vì nhiều A records!
DNS query chỉ định rõ loại record cần lấy - không phải random!
Browser cần IP để kết nối website:Query: "Cho tôi A record của example.com"→ DNS trả về: 54.231.12.45Email client gửi email:Query: "Cho tôi MX record của example.com"→ DNS trả về: mail.google.com
Ứng dụng
Query Type
Tại sao?
Browser (Chrome, Firefox)
A hoặc AAAA
Cần IP để kết nối
Email client (Gmail, Outlook)
MX
Cần mail server
DNS tools (dig, nslookup)
Bạn chỉ định
Debug
# Test với dig commanddig A example.com # Query A recorddig MX example.com # Query MX recorddig NS example.com # Query NS recorddig ANY example.com # Query tất cả records
RFC DNS quy định: Nếu một domain có CNAME record, thì nó KHÔNG ĐƯỢC có bất kỳ record nào khác (NS, MX, TXT, SOA...).
┌─────────────────────────────────────────────────────────────────┐│ Tại sao CNAME bị "cấm" ở Zone Apex? │├─────────────────────────────────────────────────────────────────┤│ ││ Zone Apex (example.com) BẮT BUỘC phải có: ││ ├── NS Record (ai quản lý domain này) ││ ├── SOA Record (metadata zone) ││ └── Thường có MX Record (nhận email @example.com) ││ ││ Nếu đặt CNAME cho example.com: ││ ├── CNAME sẽ "đá bay" tất cả NS, SOA, MX records ││ └── → Domain KHÔNG hoạt động được! ││ ││ ❌ KHÔNG THỂ: ││ example.com CNAME myapp.elb.amazonaws.com ││ example.com NS ns-123.awsdns.com ← BỊ XÓA! ││ example.com MX mail.google.com ← BỊ XÓA! ││ ││ ✅ CÓ THỂ (subdomain không có NS/SOA bắt buộc): ││ www.example.com CNAME myapp.elb.amazonaws.com ││ │└─────────────────────────────────────────────────────────────────┘
Giải pháp: Dùng A Record hoặc Alias Record cho Zone Apex.
Alias KHÔNG PHẢI là A record, KHÔNG PHẢI là CNAME - nó là loại record riêng:
┌─────────────────────────────────────────────────────────────────┐│ ALIAS = Hybrid! │├─────────────────────────────────────────────────────────────────┤│ ││ Bên trong (cách cấu hình): Giống CNAME ││ └── Trỏ đến domain: myapp.elb.amazonaws.com ││ ││ Bên ngoài (trả về cho client): Giống A RECORD ││ └── Trả về IP: 54.231.12.45 ││ ││ → Alias = "CNAME trá hình thành A record" │└─────────────────────────────────────────────────────────────────┘
Route 53 KHÔNG cache. Route 53 là nguồn gốc (Authoritative DNS), nó giữ thông tin chính thức. Người cache là các trạm trung gian:
┌────────────────────────────────────────────────────────────────────┐│ AI CACHE? ││ ││ ① Browser (Chrome, Firefox...) ✅ CACHE ││ └── Lưu DNS trong vài phút đến vài giờ ││ ││ ② Hệ điều hành (Windows, macOS, Linux) ✅ CACHE ││ └── OS có DNS Cache riêng ││ ││ ③ DNS Resolver (ISP hoặc Google 8.8.8.8) ✅ CACHE ││ └── Đây là nơi cache NHIỀU NHẤT theo TTL ││ ││ ④ Route 53 (Authoritative DNS) ❌ KHÔNG CACHE ││ └── Đây là NGUỒN GỐC, không cần cache ai cả │└────────────────────────────────────────────────────────────────────┘
example.com │ │ Weight: 70 ├─────────────────────▶ Server A (Production) │ │ Weight: 20 ├─────────────────────▶ Server B (Production) │ │ Weight: 10 └─────────────────────▶ Server C (Canary/Testing)→ 70% traffic → A, 20% → B, 10% → C
Use cases:
Load balancing giữa các regions
Canary deployment (test tính năng mới với % nhỏ users)
A/B testing
Blue-green deployment
Công thức tính %:
Traffic % = (Weight của record) / (Tổng tất cả weights) × 100Ví dụ: Weight A=70, B=20, C=10Traffic A = 70 / (70+20+10) = 70%
Định tuyến đến region có latency thấp nhất đến user.
User ở Tokyo User ở Paris │ │ ▼ ▼ ┌─────────────────────────────────────────────────────┐ │ Route 53 tra bảng latency │ │ Tokyo → ap-northeast-1: 20ms │ │ Tokyo → eu-west-1: 250ms │ │ Paris → ap-northeast-1: 300ms │ │ Paris → eu-west-1: 15ms │ └─────────────────────────────────────────────────────┘ │ │ ▼ ▼ ap-northeast-1 eu-west-1 (Japan) (Ireland)
AWS KHÔNG đo latency real-time. Thay vào đó, họ dùng bảng latency data đã được tính toán trước:
┌─────────────────────────────────────────────────────────────────┐│ Cách AWS xác định latency │├─────────────────────────────────────────────────────────────────┤│ ││ 1️⃣ AWS đã đo sẵn (cập nhật định kỳ): ││ ┌─────────────────────────────────────────────────────────┐ ││ │ Latency Table (pre-computed) │ ││ │ │ ││ │ Vietnam → ap-southeast-1 (Singapore): ~30ms │ ││ │ Vietnam → us-east-1 (N. Virginia): ~200ms │ ││ │ Vietnam → eu-west-1 (Ireland): ~250ms │ ││ └─────────────────────────────────────────────────────────┘ ││ ││ 2️⃣ Khi user query DNS: ││ ┌─────────────────────────────────────────────────────────┐ ││ │ User query → Route 53 xem IP nguồn (DNS Resolver) │ ││ │ │ │ ││ │ ▼ │ ││ │ Xác định user ở đâu → Tra bảng latency │ ││ │ │ │ ││ │ ▼ │ ││ │ Trả về IP của server có latency thấp nhất │ ││ └─────────────────────────────────────────────────────────┘ ││ │└─────────────────────────────────────────────────────────────────┘
Bước
Mô tả
1. Thu thập data
AWS đo latency từ nhiều điểm trên thế giới đến các AWS Regions
2. Xây dựng latency table
Tạo mapping: Location → Region → Latency
3. Cập nhật định kỳ
Data được refresh thường xuyên (không real-time)
4. Sử dụng IP nguồn
Route 53 dùng IP của DNS resolver để xác định vị trí
[!WARNING]
Latency dựa trên IP của DNS Resolver, không phải IP của user!
User ở Vietnam dùng Google DNS (8.8.8.8 - server ở US):→ Route 53 thấy IP từ US → Có thể trả về server US!Giải pháp: Dùng DNS resolver gần với bạn (ISP DNS)
Lưu ý: Latency-based routing đo network latency, không phải geographic distance.
Disaster recovery: Primary → Secondary khi primary fails. Còn gọi là Active-Passive HA.
Health Check │ ▼example.com ───▶ Primary (Active) │ │ │ │ UNHEALTHY! │ ▼ └────────▶ Secondary (Standby) ← Traffic tự động chuyển qua
Cấu hình:
Primary record + Health check
Secondary record (failover target)
┌─────────────────────────────────────────────────────────────────┐│ Primary healthy? ││ │ ││ ├── YES → Trả về Primary IP ││ │ ││ └── NO → Trả về Secondary IP │└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐│ Route 53 Geolocation ││ ││ User từ Vietnam ──────▶ Server Singapore ││ User từ Japan ──────▶ Server Tokyo ││ User từ France ──────▶ Server Paris ││ User từ nơi khác ──────▶ Default Server ││ (bắt buộc phải có!) │└─────────────────────────────────────────────────────────────────┘
Use cases:
Phục vụ content theo ngôn ngữ/region
Tuân thủ regulations (GDPR - data phải ở EU)
Restricting content distribution
Quan trọng: Luôn tạo Default record để xử lý các locations không match!
Định tuyến dựa trên IP address range của client (CIDR blocks).
┌─────────────────────────────────────────────────────────────────┐│ Client IP │ Target │├───────────────────────────┼─────────────────────────────────────┤│ 24.232.0.0/16 │ Server A (Comcast users) ││ 203.0.113.0/24 │ Server B (Enterprise network) ││ 10.0.0.0/8 │ Server C (Internal VPN) │└─────────────────────────────────────────────────────────────────┘
Use cases:
ISP-specific routing
Enterprise customer routing
Migrating traffic từ network này sang network khác
[!TIP]
Active-Passive = Chỉ 1 server hoạt động, server kia standby (Failover)
Active-Active = Tất cả servers cùng hoạt động, chia sẻ traffic (Weighted, Latency, Geo...)
Route 53 Health Checkers (15+ locations) │ │ HTTP GET /health ▼┌─────────────────┐│ Your Server ││ ││ Response: ││ HTTP 200 OK │ ← Healthy nếu 2xx hoặc 3xx│ "OK" │ ← Có thể check text trong response└─────────────────┘
✓ LUÔN dùng Alias cho AWS resources - Miễn phí queries - Hỗ trợ zone apex - Auto-update IP✗ KHÔNG dùng CNAME cho AWS resources - Tốn phí - Không dùng được cho zone apex
Key insight: "Độc lập" = mỗi region tự chạy được. Chính vì vậy khi 1 region chết, region còn lại vẫn sống và tiếp nhận traffic. Route 53 Health Checks là "người gác cổng" tự động chuyển hướng.