Bài 20 — DNS — Route 53, Cloud DNS, Azure DNS

Mở đầu — vì sao bài này quan trọng

Hãy tưởng tượng bạn vừa thuê một cửa hàng ở mặt tiền đường Nguyễn Huệ. Cửa hàng có địa chỉ số nhà rõ ràng, nhưng nếu không ai biết cái tên cửa hàng của bạn ứng với số nhà nào, thì dù bạn trang trí đẹp đến đâu cũng chẳng có khách bước vào. DNS chính là "danh bạ" giúp cả thế giới tìm được cửa hàng của bạn: người dùng gõ vietnamcos.com, còn máy tính thì chỉ hiểu địa chỉ IP dạng 103.21.244.10. DNS là lớp phiên dịch giữa hai thế giới đó.

Trong khóa học này, ở các bài trước bạn đã học về VPC (mạng riêng ảo) — nơi máy chủ của bạn "sống". Nhưng có máy chủ mà không có DNS thì cũng như có nhà mà không có địa chỉ trên bản đồ. Bài này tập trung vào Managed DNS — dịch vụ DNS được các nhà cung cấp cloud vận hành hộ bạn: Amazon Route 53, Google Cloud DNS, và Azure DNS. Chúng ta sẽ đi từ khái niệm bản ghi (record) cơ bản, đến những tính năng "cao cấp" mà chỉ managed DNS mới làm được: health check, failover, và định tuyến thông minh (routing policy).

Đây là kiến thức nền tảng mà bất kỳ ai làm DevOps, vận hành hệ thống, hay thậm chí chỉ quản lý website công ty cũng phải nắm. Một cấu hình DNS sai có thể làm sập cả một dịch vụ trong nhiều giờ — và tôi sẽ chỉ cho bạn những cái bẫy thường gặp để tránh.

Khái niệm cốt lõi

DNS hoạt động như thế nào

Khi người dùng gõ shop.congty.vn vào trình duyệt, một chuỗi truy vấn diễn ra trong vài mili-giây:

• Trình duyệt hỏi resolver (thường là DNS của nhà mạng VNPT, Viettel, hoặc 8.8.8.8 của Google).
• Resolver hỏi lần lượt: root server → server quản lý .vn → server quản lý congty.vn.
• Server cuối cùng — gọi là authoritative name server (máy chủ có thẩm quyền) — trả về địa chỉ IP.

Managed DNS chính là dịch vụ đóng vai trò authoritative name server này. Khi bạn dùng Route 53, Cloud DNS hay Azure DNS, bạn đang giao cho họ giữ "cuốn sổ" chứa toàn bộ bản ghi tên miền của bạn, và họ đảm bảo cuốn sổ này được nhân bản trên hàng trăm máy chủ khắp thế giới để trả lời nhanh và không bao giờ chết.

Các loại bản ghi (record) bạn phải thuộc lòng

Một zone (vùng) DNS là tập hợp các bản ghi cho một tên miền. Mỗi bản ghi có một loại (type):

• A record: trỏ tên miền tới địa chỉ IPv4. Ví dụ shop.congty.vn → 103.21.244.10.
• AAAA record: trỏ tới địa chỉ IPv6 (đọc là "quad-A"). Ví dụ shop.congty.vn → 2001:db8::1.
• CNAME record: bí danh (alias) trỏ tên miền này tới một tên miền khác. Ví dụ www.congty.vn → congty.vn. Lưu ý: không được đặt CNAME ở tên miền gốc (apex domain, tức congty.vn không có www).
• MX record: chỉ định máy chủ email nhận thư cho tên miền. Ví dụ email @congty.vn sẽ được giao tới máy chủ mail nào. MX có thêm giá trị priority (số nhỏ hơn = ưu tiên cao hơn).
• TXT record: chứa văn bản tự do, thường dùng để xác minh quyền sở hữu tên miền (Google Search Console), và cấu hình chống giả mạo email như SPF, DKIM, DMARC.
• NS record: chỉ định name server có thẩm quyền cho zone.

TTL — con dao hai lưỡi

Mỗi bản ghi có một giá trị TTL (Time To Live), tính bằng giây, cho biết resolver được phép cache (lưu tạm) kết quả trong bao lâu. TTL cao (ví dụ 86400 = 1 ngày) giúp giảm tải và tăng tốc, nhưng khi bạn đổi IP thì phải chờ cả ngày để thay đổi lan ra toàn cầu. TTL thấp (ví dụ 60 giây) giúp thay đổi nhanh nhưng tăng số truy vấn. Mẹo kinh điển: trước khi migrate hay đổi IP, hạ TTL xuống 60–300 giây vài ngày trước, đổi xong rồi mới nâng lại.

Điều làm Managed DNS "cao cấp" hơn DNS thường

DNS truyền thống (như của nhà đăng ký tên miền) chỉ trả về một câu trả lời tĩnh. Managed DNS trên cloud thêm những "siêu năng lực":

• Health check + failover: Route 53 tự động kiểm tra "sức khỏe" của endpoint (ping HTTP/TCP định kỳ). Nếu máy chủ chính chết, DNS tự động ngừng trả về IP của nó và chuyển sang IP dự phòng. Đây chính là ý cốt lõi trong ghi chú gốc của bài.
• Routing policy (chính sách định tuyến) — trả về câu trả lời khác nhau tùy hoàn cảnh:

- Latency-based: trả về server gần người dùng nhất về độ trễ. - Geolocation / Geoproximity: định tuyến theo vị trí địa lý (khách ở Việt Nam vào server Singapore, khách ở Mỹ vào server Virginia). - Weighted: chia lưu lượng theo tỷ lệ, ví dụ 90% vào phiên bản cũ, 10% vào phiên bản mới (canary release). - Failover: chủ động/dự phòng như trên.

Bảng so sánh nhanh ba nhà cung cấp

Điểm cần nhớ: ở AWS, health check/routing nằm ngay trong Route 53. Ở Azure, phần định tuyến thông minh tách ra dịch vụ riêng tên Traffic Manager, còn Azure DNS lo phần bản ghi cơ bản.

Tình huống thực tế

Tình huống 1: Sàn thương mại điện tử Việt failover khi data center gặp sự cố

Một công ty thương mại điện tử tại TP.HCM (gọi là "ShopViet") chạy website trên hai vùng: chính ở AWS Singapore (ap-southeast-1), dự phòng ở AWS Tokyo (ap-northeast-1). Trong đợt sale 12/12, họ lo lắng nếu Singapore quá tải hoặc gặp sự cố hạ tầng thì mất doanh thu.

Họ cấu hình Route 53 với failover routing: một bản ghi Primary trỏ về Load Balancer ở Singapore kèm health check ping đường dẫn /healthz mỗi 30 giây; một bản ghi Secondary trỏ về Tokyo. Đúng 21h ngày 12/12, Load Balancer ở Singapore bắt đầu trả về lỗi 503 do một service phụ thuộc bị nghẽn. Health check phát hiện sau 3 lần thất bại liên tiếp (khoảng 90 giây), Route 53 tự động ngừng trả IP Singapore và trả về IP Tokyo.

Diễn giải: Vì họ đã đặt TTL của bản ghi là 60 giây, phần lớn người dùng chuyển sang Tokyo trong vòng 2–3 phút. Doanh thu chỉ hụt vài phút thay vì cả tối.

Bài học: Failover không phải là "tức thì" — nó bị giới hạn bởi tần suất health check cộng với TTL. Muốn chuyển nhanh, phải hạ cả hai. Và luôn tạo một endpoint /healthz phản ánh đúng sức khỏe thật (kiểm tra cả database phía sau), chứ đừng chỉ trả về "200 OK" một cách vô nghĩa.

Tình huống 2: Startup fintech dùng weighted routing để triển khai an toàn

Một startup fintech ở Hà Nội cần nâng cấp API thanh toán từ phiên bản v2 lên v3. Vì đây là hệ thống tiền bạc, họ không dám "bật công tắc" chuyển 100% một lúc.

Họ dùng weighted routing của Cloud DNS (vì hạ tầng chạy trên GCP): tạo hai nhóm bản ghi cho api.fintechvn.com, một trỏ về cụm v3 với trọng số 5, một trỏ về cụm v2 với trọng số 95. Nghĩa là chỉ 5% lưu lượng thật đi vào phiên bản mới. Họ theo dõi log lỗi và độ trễ trong 48 giờ, thấy ổn thì nâng dần lên 20%, 50%, rồi 100%.

Diễn giải: Đến ngày thứ ba, họ phát hiện v3 có một lỗi timeout hiếm gặp khi gọi cổng thanh toán nội địa NAPAS. Vì chỉ 5% lưu lượng bị ảnh hưởng, họ hạ trọng số v3 về 0 ngay lập tức, sửa lỗi, rồi thử lại.

Bài học: DNS-level weighting là một cách canary release rẻ và đơn giản, không cần service mesh phức tạp. Nhưng nhớ nhược điểm: DNS caching khiến tỷ lệ không chính xác tuyệt đối — nếu một resolver cache kết quả, tất cả người dùng sau resolver đó sẽ dính cùng phiên bản. Vì vậy weighted DNS phù hợp cho canary sơ bộ, không thay thế được cho việc chia lưu lượng chính xác ở tầng load balancer.

Tình huống 3: Website tin tức và cái bẫy CNAME ở apex domain

Một tòa soạn báo điện tử muốn dùng CDN cho tên miền gốc baomoi.vn (không có www). Bạn kỹ thuật cấu hình một CNAME trỏ baomoi.vn → cdn-provider.net như hướng dẫn của CDN. Kết quả: email của tòa soạn chết sạch, và một số trình duyệt báo lỗi.

Diễn giải: Theo chuẩn DNS (RFC 1034), apex domain không được có CNAME vì apex bắt buộc phải có các bản ghi khác như NS và SOA, mà CNAME lại yêu cầu "không có bản ghi nào khác cùng tên". Khi thêm CNAME ở apex, MX record (dùng cho email) bị vô hiệu.

Bài học: Đây là lý do các nhà cung cấp cloud tạo ra bản ghi đặc biệt: Alias record của Route 53 (miễn phí, trỏ apex tới CloudFront, ALB, S3...) hoặc ALIAS/ANAME ở các dịch vụ khác. Chúng hoạt động giống CNAME nhưng ở phía server, không vi phạm chuẩn. Khi cần trỏ apex domain tới một dịch vụ cloud, hãy dùng Alias, đừng dùng CNAME.

Hướng dẫn từng bước

Ví dụ thực tế: đưa tên miền hocdevops.vn (đăng ký tại một registrar Việt Nam như PA Vietnam) về quản lý bằng Route 53, và cấu hình cho một website chạy trên EC2.

Bước 1 — Tạo Hosted Zone. Vào Route 53 → Create hosted zone → nhập hocdevops.vn, chọn loại Public. AWS sẽ sinh ra 4 name server (dạng ns-123.awsdns-45.com).

Bước 2 — Trỏ NS tại nhà đăng ký. Đăng nhập vào trang quản lý tên miền tại PA Vietnam, tìm mục "Name servers", thay 4 NS mặc định bằng 4 NS mà AWS vừa cấp. Đây là bước "trao chìa khóa" — kể từ đây Route 53 là authoritative cho tên miền của bạn. Việc lan truyền có thể mất vài giờ.

Bước 3 — Tạo A record. Trong hosted zone, Create record: tên hocdevops.vn, type A, giá trị là IP public của EC2 (hoặc chọn Alias trỏ tới Load Balancer). Đặt TTL 300 giây khi mới setup.

Bước 4 — Tạo bản ghi phụ. Thêm CNAME www.hocdevops.vn → hocdevops.vn. Thêm MX nếu dùng email. Thêm TXT cho SPF/DMARC nếu gửi email.

Bước 5 — Cấu hình health check (nếu cần HA). Route 53 → Health checks → tạo check ping http://<IP>/healthz mỗi 30 giây. Sau đó sửa A record chính thành routing type Failover — Primary, gắn health check vừa tạo, và thêm một A record Secondary trỏ về server dự phòng.

Bước 6 — Kiểm tra. Dùng lệnh dig hocdevops.vn hoặc nslookup hocdevops.vn để xác nhận. Kiểm tra cả dig hocdevops.vn NS để chắc name server đã đúng của AWS.

Quy trình ở Cloud DNS và Azure DNS gần như tương tự: tạo zone → lấy NS → cập nhật tại registrar → thêm record. Chỉ khác tên gọi và giao diện.

Lỗi thường gặp & mẹo

• Quên đổi NS tại registrar. Bạn tạo hosted zone rất đẹp nhưng tên miền vẫn dùng NS cũ → không bản ghi nào có hiệu lực. Luôn kiểm tra bằng dig <domain> NS.
• Đặt CNAME ở apex domain. Như tình huống 3 — dùng Alias/ANAME thay thế.
• TTL quá cao khi migrate. Hạ TTL xuống 60–300 giây vài ngày trước khi đổi IP, đừng đợi đến lúc đổi mới hạ (vì bản ghi TTL cũ vẫn còn hiệu lực trong cache).
• Health check trỏ tới endpoint "giả khỏe". /healthz chỉ trả 200 mà không kiểm tra database → server chết database mà DNS vẫn tưởng khỏe. Health check phải phản ánh sức khỏe thật của toàn chuỗi.
• Tưởng DNS thay đổi là tức thì. DNS luôn có độ trễ lan truyền do caching ở resolver và trình duyệt. Kiên nhẫn, và đừng dựa vào DNS để chuyển đổi trong mili-giây — việc đó là của load balancer.
• Nhầm zone Public và Private. Private hosted zone chỉ phân giải bên trong VPC. Nếu bạn cần cả trong lẫn ngoài phân giải cùng tên, phải hiểu rõ split-horizon DNS.
• Mẹo dọn dẹp: đặt TXT/DKIM đúng chuẩn để email không rơi vào spam. Nhiều đội bỏ quên DMARC và bị giả mạo email.
• Mẹo chi phí: Route 53 tính phí theo số hosted zone và số truy vấn. Với dự án nhỏ, chi phí thường vài chục nghìn đồng/tháng — rất rẻ so với giá trị uptime mang lại.

Bài tập thực hành

• Vẽ sơ đồ truy vấn: Khi người dùng ở Đà Nẵng gõ www.hocdevops.vn, hãy vẽ lại toàn bộ hành trình từ resolver → root → .vn → authoritative → IP. Ghi rõ ở bước nào caching xảy ra.

• Thiết kế bản ghi: Cho một website chạy trên Load Balancer (apex domain) và một blog chạy trên nền tảng bên thứ ba (subdomain blog). Liệt kê đầy đủ các record cần tạo: dùng loại nào cho apex, loại nào cho www, loại nào cho blog? Giải thích vì sao.

• Kịch bản failover: Bạn có server chính ở HCM và dự phòng ở Hà Nội, TTL đang là 3600 giây, health check 30 giây/lần, ngưỡng 3 lần lỗi. Ước tính thời gian tối đa người dùng bị gián đoạn khi server chính chết. Sau đó đề xuất cách rút ngắn con số này.

• Thực hành lệnh: Trên máy của bạn, chạy dig google.com A, dig google.com MX, và dig google.com TXT. Đọc và giải thích ý nghĩa các bản ghi trả về.

Tóm tắt

Managed DNS là dịch vụ authoritative name server do cloud vận hành, giúp bạn quản lý tên miền với độ sẵn sàng cực cao và thêm những tính năng thông minh mà DNS truyền thống không có. Bạn cần thuộc các loại bản ghi cơ bản (A, AAAA, CNAME, MX, TXT, NS) và hiểu vai trò của TTL trong việc lan truyền thay đổi.

Điểm khác biệt lớn nhất của managed DNS là health check + failover và routing policy (latency, geolocation, weighted, failover) — cho phép bạn xây hệ thống tự phục hồi và triển khai an toàn ngay ở tầng DNS. Route 53 tích hợp sẵn mọi thứ; Cloud DNS tương tự; còn Azure tách phần định tuyến thông minh sang Traffic Manager.

Ba cái bẫy cần khắc cốt ghi tâm: đừng quên đổi NS tại registrar, đừng đặt CNAME ở apex (dùng Alias), và đừng hạ TTL vào phút chót. Nắm vững những điều này, bạn đã có nền tảng vững để bước tiếp sang các bài về CDN và Load Balancer — nơi DNS sẽ tiếp tục là "người dẫn đường" cho lưu lượng của bạn.