Giao diện
🎯 Mục tiêu
🎯 Sau bài này bạn sẽ nắm được:
- Hiểu toàn bộ DNS resolution path: từ browser cache đến authoritative nameserver
- Biết các record types quan trọng và khi nào dùng cái nào
- Hiểu TTL trade-offs và tác động lên failover speed vs performance
- Biết cách DNS được dùng cho load balancing và high availability
DNS Resolution — Hệ thống danh bạ của Internet
Ngày 4 tháng 10 năm 2021, Facebook biến mất khỏi Internet trong suốt 6 tiếng. Không phải server bị hack, không phải database bị xoá — mà là một thay đổi cấu hình BGP khiến các DNS server của Facebook trở nên unreachable. Domain facebook.com đơn giản là không còn tồn tại trên bản đồ Internet. 3.5 tỷ người dùng không thể truy cập nền tảng, không phải vì server down, mà vì DNS không thể resolve tên miền thành địa chỉ IP.
Điều đáng suy ngẫm là: ngay cả các kỹ sư bên trong Facebook cũng không thể truy cập hệ thống nội bộ để sửa lỗi — bởi vì hệ thống nội bộ cũng phụ thuộc vào DNS. Nhân viên phải lái xe đến data center, dùng physical access để khôi phục. Sự cố này gây thiệt hại ước tính $100 triệu doanh thu và khiến cả thế giới nhận ra một sự thật: DNS là thành phần critical nhất của Internet infrastructure mà hầu hết developer không bao giờ nghĩ đến.
Mỗi khi bạn gõ một URL vào trình duyệt, có một cuộc hành trình phức tạp diễn ra trong vài chục millisecond — từ domain name đến IP address, qua nhiều tầng cache và nameserver. Hiểu rõ cuộc hành trình này là nền tảng để bạn thiết kế hệ thống resilient, fast, và globally available.
Bức tranh tư duy
DNS giống hệ thống 114 (tổng đài danh bạ) của Việt Nam thời xưa.
Hãy tưởng tượng bạn muốn gọi điện cho một người quen ở tỉnh khác. Bạn biết tên họ, nhưng không biết số điện thoại. Quy trình diễn ra như sau:
- Bạn nhìn sổ ghi chú cá nhân (browser cache) — nếu đã ghi lần trước thì gọi luôn, xong.
- Bạn hỏi người nhà (OS cache) — ai đó trong nhà có thể nhớ số.
- Không ai nhớ → bạn gọi 114 (recursive resolver) — tổng đài tra cứu hộ bạn.
- 114 hỏi: "Tỉnh nào?" → chuyển đến tổng đài tỉnh (root nameserver → TLD nameserver).
- Tổng đài tỉnh: "Xã nào?" → chuyển đến bưu điện xã (authoritative nameserver).
- Bưu điện xã trả lời số chính xác → 114 đọc cho bạn → bạn ghi lại vào sổ (cache).
- Lần sau gọi lại → bạn nhìn sổ ghi chú → không cần gọi 114 nữa.
Mấu chốt là: mỗi tầng trong hệ thống đều có thể "nhớ" kết quả (caching), và chỉ khi không ai nhớ thì mới cần hỏi tầng cao hơn. Đây chính là kiến trúc hierarchical caching của DNS.
💡 Takeaway: DNS resolution là một chuỗi câu hỏi — mỗi tầng hoặc trả lời ngay (cache hit), hoặc chuyển tiếp lên tầng kế. Kết quả được cache trên đường về, giảm load cho toàn hệ thống.
Cốt lõi kỹ thuật
DNS Resolution Path chi tiết
Khi bạn gõ example.com vào trình duyệt, đây là chính xác những gì xảy ra:
Giải thích từng bước:
| Bước | Thành phần | Hành động | Latency ước tính |
|---|---|---|---|
| 1-2 | Browser + OS Cache | Tra cứu local, gần như instant | < 1ms |
| 3-4 | Recursive Resolver | ISP hoặc public resolver (8.8.8.8, 1.1.1.1) kiểm tra cache | 1-5ms |
| 5-6 | Root Nameserver | 13 root server clusters toàn cầu, anycast routing | 10-30ms |
| 7-8 | TLD Nameserver | VeriSign quản lý .com, VNNIC quản lý .vn | 10-30ms |
| 9-10 | Authoritative NS | Nameserver mà domain owner cấu hình (Cloudflare, Route 53...) | 10-50ms |
Worst case: DNS lookup có thể mất 50-200ms nếu tất cả cache đều miss. Đây là lý do DNS latency phải nằm trong latency budget khi thiết kế hệ thống.
DNS Record Types — Bảng tham chiếu
| Record | Ý nghĩa | Ví dụ | Khi nào dùng? |
|---|---|---|---|
| A | Domain → IPv4 | example.com → 93.184.216.34 | Trỏ domain đến server |
| AAAA | Domain → IPv6 | example.com → 2606:2800:220:1:... | IPv6 support |
| CNAME | Alias → tên khác | www.example.com → example.com | Subdomain aliasing, CDN integration |
| MX | Mail exchange | example.com → mail.example.com (priority 10) | Email routing |
| NS | Nameserver delegation | example.com → ns1.example.com | DNS authority delegation |
| TXT | Text record | v=spf1 include:_spf.google.com ~all | Email auth (SPF/DKIM), domain verification |
| SRV | Service discovery | _sip._tcp.example.com → sip.example.com:5060 | Microservice discovery |
| PTR | Reverse DNS | 34.216.184.93.in-addr.arpa → example.com | Email verification, logging |
Lưu ý quan trọng cho architect:
- CNAME không dùng được ở apex domain (
example.com). Chỉ dùng cho subdomain (www.example.com). Nhiều DNS provider cung cấp "ALIAS" hoặc "ANAME" record để giải quyết hạn chế này. - MX record có priority — số nhỏ hơn = ưu tiên cao hơn. Luôn cấu hình ít nhất 2 MX record để có redundancy.
- TXT record ngày càng quan trọng — SPF, DKIM, DMARC cho email; domain verification cho Google, AWS, v.v.
TTL Trade-offs — Câu hỏi mà architect phải trả lời
TTL (Time To Live) quyết định kết quả DNS được cache bao lâu. Đây là một trong những trade-off quan trọng nhất khi thiết kế hệ thống phân tán.
| TTL | Ưu điểm | Nhược điểm | Use case |
|---|---|---|---|
| Rất thấp (30-60s) | Failover nhanh, DNS changes apply gần như tức thì | Tăng load lên DNS servers, tăng latency do lookup thường xuyên | Active failover, blue-green deploy, incident response |
| Trung bình (300-3600s) | Cân bằng giữa performance và flexibility | Failover mất 5-60 phút | Most production services |
| Cao (86400s+) | Giảm DNS lookup, improve performance, giảm cost | Slow failover, khó thay đổi IP khi cần | Stable services, CDN endpoints, nameserver records |
TTL trong thực tế:
; Ví dụ DNS zone file
; Production API — cần failover nhanh
api.example.com. 60 IN A 10.0.1.100
api.example.com. 60 IN A 10.0.2.100
; CDN endpoint — ổn định, TTL cao
static.example.com. 86400 IN CNAME d111.cloudfront.net.
; Nameserver records — rất ổn định
example.com. 86400 IN NS ns1.example.com.
example.com. 86400 IN NS ns2.example.com.⚠️ Gotcha: Dù bạn đặt TTL thấp, không có gì đảm bảo mọi resolver sẽ tôn trọng giá trị đó. Một số ISP resolver cache lâu hơn TTL quy định. Trong thực tế, expect DNS propagation mất 5-30 phút ngay cả với TTL thấp.
GeoDNS và DNS-based Load Balancing
DNS không chỉ resolve tên thành IP — nó còn là công cụ load balancing và traffic routing mạnh mẽ ở tầng global.
Các chiến lược DNS-based routing
| Chiến lược | Cơ chế | Ưu điểm | Hạn chế |
|---|---|---|---|
| Round-robin DNS | Nhiều A record, rotate thứ tự | Đơn giản, không cần infra đặc biệt | Không health check, phân phối không đều |
| GeoDNS | Trả IP khác nhau dựa trên vị trí client | Latency thấp, data locality | Cần DNS provider hỗ trợ, IP geo database không 100% chính xác |
| Weighted DNS | Gán weight cho mỗi record | Canary deploy, gradual migration | Limited granularity |
| Health-check DNS | Tự động remove unhealthy endpoint | High availability | DNS caching delay failover |
Ví dụ cấu hình GeoDNS (AWS Route 53):
; Geolocation routing policy
api.example.com. 60 IN A 103.21.244.0 ; Asia
api.example.com. 60 IN A 52.84.12.0 ; North America
api.example.com. 60 IN A 35.158.0.0 ; Europe
api.example.com. 60 IN A 52.84.12.0 ; Default (fallback)Limitation quan trọng: DNS caching có nghĩa là khi bạn thay đổi routing (ví dụ failover một DC), user vẫn có thể kết nối tới DC cũ cho đến khi cache hết hạn. Đây là lý do GeoDNS thường được kết hợp với anycast hoặc application-level routing cho true instant failover.
WARNING
🤔 Trade-off Question
"Bạn đang thiết kế một global service cần 99.99% uptime. DNS TTL nên đặt bao nhiêu?"
Đây là câu hỏi không có đáp án duy nhất — và đó chính là điều interviewer muốn thấy bạn phân tích.
Tension cốt lõi:
- TTL cao → ít DNS lookup hơn → performance tốt hơn → nhưng failover chậm
- TTL thấp → failover nhanh → nhưng tăng DNS load và latency
Đáp án phụ thuộc vào failover strategy:
| Strategy | TTL khuyến nghị | Lý do |
|---|---|---|
| DNS là primary failover | 30-60s | Cần DNS change propagate nhanh |
| Anycast / BGP-based failover | 300-3600s | Failover xảy ra ở network layer, không cần DNS change |
| Application-level failover | 300-600s | Client retry logic tự handle, DNS chỉ cần reasonable |
| Hybrid (DNS + health check) | 60-120s | DNS remove unhealthy endpoint, cần propagate trong ~2 phút |
Câu trả lời mẫu cho interview:
"Tôi sẽ đặt TTL 60 giây cho production API endpoints và kết hợp với health-check integrated DNS (Route 53 hoặc Cloudflare). Điều này cho phép failover trong ~1-2 phút. Đồng thời, tôi sẽ dùng anycast cho critical services để có instant failover ở network layer, không phụ thuộc DNS propagation. Với 99.99% uptime (tức chỉ cho phép ~52 phút downtime/năm), 1-2 phút DNS failover là chấp nhận được nếu xảy ra ít lần."
💬 Caselet: WhatsApp và bài toán kết nối 2 tỷ thiết bị
WhatsApp phải giải quyết một bài toán DNS rất đặc thù: kết nối hơn 2 tỷ thiết bị trên toàn cầu tới server gần nhất, nhưng DNS chỉ quan trọng ở thời điểm thiết lập kết nối — không phải mỗi request.
Khi bạn mở WhatsApp, ứng dụng thực hiện DNS lookup để tìm server gần nhất (ví dụ chatd.whatsapp.net). GeoDNS trả về IP của data center Singapore cho user ở Việt Nam, US-East cho user ở Mỹ. Sau khi resolve xong, WhatsApp thiết lập một persistent WebSocket connection — từ đây, mọi message đều đi qua connection đã mở, không cần DNS lookup nữa.
Điều thú vị là TTL strategy của WhatsApp phải cân bằng hai yếu tố mâu thuẫn: TTL đủ thấp để failover nhanh khi một DC gặp sự cố (người dùng mới sẽ kết nối tới DC khác), nhưng đủ cao để không overwhelm DNS infrastructure khi hàng triệu thiết bị reconnect đồng thời sau một network blip.
Một edge case thú vị: khi user di chuyển giữa các quốc gia (ví dụ bay từ Việt Nam sang Nhật), connection cũ tới Singapore DC vẫn hoạt động qua WebSocket. Chỉ khi connection bị ngắt (đổi mạng, mất sóng) thì DNS re-resolution mới xảy ra — lúc đó GeoDNS có thể trả về Tokyo DC thay vì Singapore. Đây là lý do WhatsApp cần cơ chế connection migration bên cạnh DNS.
Health check cũng đóng vai trò then chốt: nếu Singapore DC gặp sự cố, health-check DNS sẽ ngừng trả IP của DC đó. Người dùng mới ở Việt Nam sẽ được route tới DC backup (có thể là Hong Kong hoặc Tokyo). Người dùng đang có connection sẵn sẽ bị disconnect khi DC down, và khi reconnect, DNS sẽ đưa họ tới DC healthy.
Bài học cho architect: Với persistent-connection applications (WebSocket, gRPC streaming, MQTT), DNS resolution chỉ quan trọng tại connection establishment time, không phải per-request. Điều này ảnh hưởng cách bạn thiết kế TTL, failover strategy, và connection lifecycle management.
Sai lầm điển hình
⚠️ Cạm bẫy
1. Quên DNS khi estimate latency budget
Nhiều engineer estimate API latency = server processing time + network round trip, nhưng quên mất DNS lookup có thể mất 50-200ms nếu cache miss. Đặc biệt nghiêm trọng với microservices gọi nhiều external services.
Giải pháp: Luôn include DNS latency trong latency budget. Sử dụng connection pooling và persistent connections để giảm tần suất DNS lookup. Pre-resolve critical domains khi application startup.
⚠️ Cạm bẫy
2. Đặt TTL quá cao → không thể failover nhanh
TTL 86400 (24 giờ) cho production API nghe có vẻ hợp lý để giảm load. Nhưng khi incident xảy ra và bạn cần chuyển traffic sang backup DC, user vẫn kết nối tới DC cũ trong tới 24 giờ.
Giải pháp: Production endpoints nên có TTL 60-300 giây. Chỉ dùng TTL cao cho static resources, CDN endpoints, và nameserver records.
⚠️ Cạm bẫy
3. Dùng CNAME ở apex domain
; ❌ SAI — CNAME tại apex domain
example.com. IN CNAME myapp.herokuapp.com.
; ✅ ĐÚNG — dùng A record hoặc ALIAS
example.com. IN A 52.84.12.0
; hoặc với provider hỗ trợ ALIAS:
example.com. IN ALIAS myapp.herokuapp.com.Theo RFC 1034, CNAME tại apex domain conflict với các record khác (MX, NS, TXT). Nhiều DNS provider sẽ reject hoặc gây behavior không đoán trước.
Giải pháp: Dùng ALIAS/ANAME record (Cloudflare, Route 53 hỗ trợ) hoặc A record tại apex. CNAME chỉ dùng cho subdomain.
⚠️ Cạm bẫy
4. Không setup DNS redundancy
Chỉ cấu hình 1 nameserver → nếu NS đó down, toàn bộ domain không resolve được. Đây chính xác là dạng single point of failure mà DNS được thiết kế để tránh.
Giải pháp: Luôn cấu hình ít nhất 2 nameserver (khuyến nghị 3-4), đặt ở các mạng khác nhau. Dùng secondary DNS provider (ví dụ primary Cloudflare, secondary Route 53) cho critical domains.
✅ Checklist triển khai
Checklist ghi nhớ
Kiến thức nền tảng
- [ ] Hiểu 6 bước DNS resolution: Browser Cache → OS Cache → Recursive Resolver → Root NS → TLD NS → Authoritative NS
- [ ] Biết 13 root server clusters sử dụng anycast, không phải chỉ 13 server vật lý
- [ ] Phân biệt được recursive resolver vs authoritative nameserver
- [ ] Hiểu tại sao DNS dùng UDP (port 53) cho queries nhỏ và TCP cho zone transfer
Record Types
- [ ] Biết khi nào dùng A vs CNAME vs ALIAS record
- [ ] Hiểu MX record priority (số nhỏ = ưu tiên cao)
- [ ] Biết CNAME không dùng được ở apex domain
- [ ] Hiểu TXT record dùng cho SPF/DKIM/domain verification
TTL & Performance
- [ ] Chọn TTL phù hợp với failover strategy (60s cho active failover, 300-3600s cho stable services)
- [ ] Include DNS latency (50-200ms worst case) trong latency budget
- [ ] Hiểu DNS propagation có thể lâu hơn TTL do ISP resolver behavior
High Availability
- [ ] Cấu hình ít nhất 2 nameserver cho mọi domain
- [ ] Dùng GeoDNS cho global services để route user tới DC gần nhất
- [ ] Kết hợp DNS health check với failover strategy
- [ ] Cân nhắc secondary DNS provider cho critical domains
Bài tập luyện tập
🧠 Quiz
Câu 1: DNS Resolution Order
Khi browser cần resolve api.example.com, thứ tự tra cứu đúng là gì?
- [ ] Root NS → TLD NS → Recursive Resolver → Authoritative NS
- [ ] Authoritative NS → TLD NS → Root NS → Browser Cache
- [x] Browser Cache → OS Cache → Recursive Resolver → Root NS → TLD NS → Authoritative NS
- [ ] Recursive Resolver → Browser Cache → Root NS → Authoritative NS
Giải thích
DNS resolution luôn bắt đầu từ local cache gần nhất trước: browser cache → OS cache. Nếu miss, query được gửi đến recursive resolver, và resolver mới bắt đầu hỏi từ root → TLD → authoritative. Thứ tự này tối ưu cho performance vì hầu hết lookup đều hit cache ở tầng thấp.
🧠 Quiz
Câu 2: CNAME tại Apex Domain
Tại sao example.com IN CNAME myapp.herokuapp.com là không hợp lệ theo DNS standard?
- [ ] CNAME không hỗ trợ external domain
- [ ] Apex domain không thể có DNS record
- [x] CNAME tại apex conflict với các record khác (MX, NS, SOA) vì RFC quy định CNAME không được coexist
- [ ] CNAME chỉ hoạt động với IPv6
Giải thích
Theo RFC 1034, khi một domain có CNAME record, nó không được có bất kỳ record type nào khác. Nhưng apex domain (example.com) bắt buộc phải có NS record và SOA record. Do đó CNAME tại apex domain tạo ra conflict không thể giải quyết. Giải pháp: dùng A record, hoặc ALIAS/ANAME record (non-standard nhưng được nhiều provider hỗ trợ).
🧠 Quiz
Câu 3: TTL Strategy
Bạn đang migrate production API từ AWS sang GCP. Hiện tại TTL của api.example.com là 86400 giây (24 giờ). Bạn nên làm gì trước khi migrate?
- [ ] Migrate ngay, TTL không ảnh hưởng
- [ ] Tăng TTL lên 172800 (48 giờ) để giảm DNS load trong quá trình migrate
- [x] Giảm TTL xuống 60-300 giây vài ngày trước, migrate, rồi tăng TTL lại sau khi ổn định
- [ ] Xóa tất cả DNS record rồi tạo mới
Giải thích
Đây là pattern TTL lowering before migration — best practice kinh điển:
- Trước migration (24-48h): Giảm TTL xuống 60-300s. Chờ đủ thời gian để TTL cũ hết hạn ở mọi cache.
- Thực hiện migration: Đổi IP trong DNS record. Với TTL thấp, traffic sẽ chuyển sang server mới trong vài phút.
- Sau migration (ổn định): Tăng TTL lại về 3600-86400s để optimize performance.
Nếu migrate khi TTL vẫn 24h, một số user sẽ kết nối tới server cũ (đã tắt) trong tối đa 24 giờ.
🧠 Quiz
Câu 4: GeoDNS Limitation
GeoDNS route user Việt Nam tới Singapore DC (IP: 103.x.x.x). Khi Singapore DC gặp sự cố và bị remove khỏi DNS, user Việt Nam vẫn không thể kết nối DC khác trong vài phút. Nguyên nhân là gì?
- [ ] GeoDNS không hỗ trợ failover
- [x] DNS response cũ (trỏ tới Singapore DC) vẫn nằm trong cache của recursive resolver và client, chưa hết TTL
- [ ] User Việt Nam không có route tới DC khác
- [ ] Authoritative nameserver cũng bị down
Giải thích
Đây là DNS caching delay — limitation cơ bản của DNS-based failover. Dù health check remove Singapore IP khỏi DNS response ngay lập tức, các resolver đã cache response cũ vẫn trả về IP cũ cho đến khi TTL hết hạn. Với TTL 60s, delay tối đa là ~60s. Với TTL 3600s, delay có thể lên tới 1 giờ. Đây là lý do nhiều hệ thống kết hợp DNS failover với anycast hoặc application-level retry để giảm impact.
🏗️ Architecture Drag-and-Drop: Sắp xếp đúng thứ tự DNS Resolution
Thử thách: Sắp xếp 6 thành phần sau theo đúng thứ tự mà DNS query đi qua (từ client đến kết quả cuối cùng):
Các khối cần sắp xếp (đã xáo trộn):
| Khối | Thành phần |
|---|---|
| 🔀 | Root Nameserver |
| 🔀 | Browser Cache |
| 🔀 | TLD Nameserver (.com) |
| 🔀 | OS Cache |
| 🔀 | Recursive Resolver |
| 🔀 | Authoritative Nameserver |
Vị trí đích:
| Thứ tự | Thành phần |
|---|---|
| 1️⃣ | ❓ |
| 2️⃣ | ❓ |
| 3️⃣ | ❓ |
| 4️⃣ | ❓ |
| 5️⃣ | ❓ |
| 6️⃣ | ❓ |
🔑 Đáp án
| Thứ tự | Thành phần | Giải thích |
|---|---|---|
| 1️⃣ | Browser Cache | Kiểm tra cache nội bộ trình duyệt trước tiên |
| 2️⃣ | OS Cache | Hệ điều hành có DNS cache riêng (stub resolver) |
| 3️⃣ | Recursive Resolver | ISP hoặc public resolver (8.8.8.8) thực hiện lookup hộ client |
| 4️⃣ | Root Nameserver | 13 root clusters — trả lời "TLD .com ở đâu?" |
| 5️⃣ | TLD Nameserver (.com) | Quản lý registry .com — trả lời "example.com do NS nào quản lý?" |
| 6️⃣ | Authoritative Nameserver | NS cuối cùng — trả về IP chính xác của domain |
Mẹo nhớ: Từ gần → xa, từ cache → authority. Mỗi tầng hoặc trả lời ngay, hoặc chỉ đường tới tầng kế tiếp.