Bài 41 — DNS Operations và CDN — Operations Management for Tech

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

Nếu bạn từng gặp cảnh website "sập" trên máy đồng nghiệp nhưng vẫn chạy bình thường trên máy mình, hoặc một khách hàng ở Đà Nẵng phàn nàn trang load chậm trong khi khách ở TP.HCM thấy nhanh vù vù, thì bạn đã chạm vào đúng hai mảnh ghép của bài học hôm nay: DNS và CDN.

DNS (Domain Name System) là "danh bạ điện thoại" của Internet — nó dịch tên miền dễ nhớ như vietcombank.com.vn thành địa chỉ IP mà máy tính hiểu. CDN (Content Delivery Network) là mạng lưới máy chủ đặt rải rác khắp thế giới, giúp nội dung được phục vụ từ điểm gần người dùng nhất. Cả hai đứng ở tầng ngoài cùng của hệ thống — nghĩa là khi chúng hỏng, không một request nào chạm được tới ứng dụng của bạn, dù backend có khỏe đến đâu.

Với một người làm Operations, hiểu DNS và CDN không phải chuyện "hay thì biết". Rất nhiều sự cố nghiêm trọng nhất trong lịch sử ngành đều bắt nguồn từ đây: một bản ghi DNS sai chính tả, một chứng chỉ TLS hết hạn trên CDN, một cấu hình TTL quá dài khiến việc chuyển đổi máy chủ mất nửa ngày mới có hiệu lực. Bài này sẽ trang bị cho bạn nền tảng để vận hành, gỡ lỗi và ra quyết định đúng ở tầng hạ tầng mà mọi thứ khác phụ thuộc vào.

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

DNS là gì và hoạt động ra sao

Khi bạn gõ một tên miền vào trình duyệt, một chuỗi truy vấn phân giải (resolution) diễn ra chỉ trong vài chục mili-giây:

Trình duyệt hỏi resolver (thường là DNS server của nhà mạng, hoặc 1.1.1.1 của Cloudflare, 8.8.8.8 của Google).
Resolver hỏi root server để biết ai quản lý đuôi .vn hoặc .com.
Root chỉ tới TLD server (Top-Level Domain), server này chỉ tiếp tới authoritative server — nơi thực sự giữ bản ghi của tên miền.
Authoritative server trả về địa chỉ IP, resolver cache lại rồi trả cho trình duyệt.

Điểm mấu chốt cần nhớ: kết quả được cache ở nhiều tầng, và thời gian cache do một tham số tên TTL (Time To Live) quyết định.

Các loại bản ghi DNS quan trọng

Đây là "bảng chữ cái" mà bất kỳ ai làm Ops đều phải thuộc:

A record — trỏ tên miền tới một địa chỉ IPv4. Ví dụ shop.tiki.vn → 203.0.113.10.
AAAA record — giống A nhưng trỏ tới IPv6 (đọc là "quad-A").
CNAME record — tạo bí danh (alias), trỏ một tên miền tới một tên miền khác. Ví dụ www.tiki.vn → tiki.vn. Lưu ý: CNAME không được đặt ở đỉnh tên miền (apex/root như tiki.vn) theo chuẩn gốc — đây là bẫy kinh điển.
MX record — chỉ định máy chủ nhận email cho tên miền, kèm số ưu tiên (priority) thấp hơn được ưu tiên trước.
TXT record — chứa văn bản tùy ý, dùng cho SPF, DKIM, DMARC (chống giả mạo email) và để xác minh quyền sở hữu tên miền với Google, Facebook...
NS record — chỉ định authoritative server nào quản lý tên miền.
SOA record — thông tin "khai sinh" của zone: serial, thời gian refresh, retry.

TTL — tham số quyền lực nhất mà ai cũng quên

TTL quyết định bản ghi được cache bao lâu (tính bằng giây). Đặt TTL 3600 nghĩa là các resolver trên toàn thế giới sẽ nhớ kết quả trong 1 giờ. Điều này có hai mặt:

TTL dài (ví dụ 86400 = 1 ngày): giảm tải truy vấn, phân giải nhanh, nhưng khi bạn đổi IP thì phải chờ cả ngày để mọi nơi cập nhật.
TTL ngắn (ví dụ 60): linh hoạt, đổi IP là gần như tức thì, nhưng nhiều truy vấn hơn.

Mẹo vàng của dân Ops: trước khi làm việc lớn (chuyển máy chủ, đổi nhà cung cấp), hãy hạ TTL xuống 60–300 giây vài ngày trước, thực hiện chuyển đổi, rồi nâng lại. Nhiều người quên bước này và trả giá bằng nhiều giờ downtime.

CDN là gì

CDN là mạng lưới các máy chủ biên (edge server / PoP — Point of Presence) đặt tại nhiều thành phố. Thay vì mọi người dùng phải kéo nội dung từ máy chủ gốc (origin) — có thể đặt ở Singapore hay Mỹ — CDN lưu bản sao (cache) nội dung tại edge gần người dùng.

Lợi ích cốt lõi:

Giảm latency: người dùng Hà Nội lấy ảnh từ PoP ở Hà Nội thay vì từ origin ở Mỹ.
Giảm tải origin: phần lớn request tĩnh (ảnh, CSS, JS, video) được edge phục vụ, origin chỉ xử lý phần động.
Chống DDoS và bảo vệ TLS: CDN đứng chắn phía trước, hấp thụ tấn công.

Nội dung được phân loại thành static (ảnh, file — cache dễ) và dynamic (kết quả tùy user — khó cache, thường bỏ qua hoặc cache có điều kiện). Các header như Cache-Control, ETag, Expires điều khiển hành vi cache. Khái niệm quan trọng: cache hit (edge có sẵn, phục vụ ngay) so với cache miss (edge phải hỏi origin). Tỷ lệ cache hit ratio càng cao thì CDN càng hiệu quả.

DNS và CDN gặp nhau ở đâu

Đây là điểm nhiều người mơ hồ. Để "cắm" một CDN vào tên miền, bạn thường trỏ bản ghi DNS (thường là CNAME) tới hostname của CDN. Ví dụ cdn.sendo.vn → sendo.cloudfront.net. Từ đó, DNS của CDN sẽ dùng kỹ thuật anycast hoặc geo-DNS để trả về IP của edge gần người dùng nhất. Vậy nên DNS và CDN không phải hai thứ tách rời — CDN vận hành được là nhờ lớp DNS thông minh phía sau.

Tình huống thực tế

Tình huống 1: Sàn TMĐT chuyển origin và quên hạ TTL

Một sàn thương mại điện tử tại TP.HCM (gọi là "ShopViet") quyết định chuyển hệ thống từ một VPS cũ sang cụm server mới với IP khác. Đội kỹ thuật cập nhật A record vào 9 giờ sáng thứ Bảy, tự tin rằng "đổi xong là chạy".

Vấn đề: TTL của bản ghi đang đặt ở 86400 giây (24 giờ). Suốt cả ngày thứ Bảy, một phần lớn người dùng vẫn bị resolver của nhà mạng trỏ về VPS cũ — nơi đã bị tắt. Kết quả: khoảng 40% khách hàng thấy trang trắng hoặc lỗi, đúng vào ngày cao điểm cuối tuần. Đội Ops hoảng loạn không hiểu vì sao "IP đã đổi rồi mà vẫn lỗi".

Bài học: DNS có tính chất phân tán và cache theo TTL. Việc chuyển đổi không tức thời. Quy trình đúng là hạ TTL xuống 300 giây từ 2–3 ngày trước, giữ VPS cũ chạy song song thêm ít nhất 1 chu kỳ TTL sau khi đổi (chiến lược "để cả hai cùng sống" trong giai đoạn chuyển tiếp), rồi mới tắt server cũ.

Tình huống 2: Chứng chỉ TLS hết hạn trên CDN của một ngân hàng số

Một ngân hàng số ở Đông Nam Á dùng CDN để phục vụ toàn bộ web và app. Chứng chỉ TLS cấu hình thủ công trên CDN có hạn 1 năm. Đội phụ trách đổi người, không ai theo dõi ngày hết hạn. Đúng nửa đêm ngày chứng chỉ hết hạn, mọi kết nối HTTPS qua CDN bắt đầu báo lỗi "certificate expired". App hiển thị màn hình trắng, người dùng không đăng nhập được, tổng đài quá tải.

Điều trớ trêu: origin vẫn khỏe mạnh 100%, database ổn, backend ổn. Sự cố nằm hoàn toàn ở lớp edge của CDN. Mất gần 2 giờ mới khôi phục vì phải liên hệ nhà cung cấp CDN cấp lại chứng chỉ và propagate ra toàn bộ PoP.

Bài học: Hạ tầng DNS/CDN có những "quả bom hẹn giờ" âm thầm: chứng chỉ TLS, domain sắp hết hạn gia hạn, thẻ thanh toán CDN hết hạn. Phải có monitoring cho ngày hết hạn (alert trước 30 và 7 ngày), và ưu tiên chứng chỉ tự động gia hạn (như ACM của AWS hay Let's Encrypt) thay vì thủ công.

Tình huống 3: Cache sai khiến người dùng nhìn thấy dữ liệu của nhau

Một startup giao đồ ăn dùng CDN để tăng tốc. Do cấu hình sai, họ vô tình cho CDN cache cả trang /tai-khoan — vốn là nội dung động chứa thông tin cá nhân. Một người dùng ở Cần Thơ mở trang tài khoản và thấy... tên, số điện thoại của một khách hàng khác. Nguyên nhân: edge server đã cache response của user A rồi phục vụ lại cho user B vì URL giống nhau và không có header Cache-Control: private, no-store.

Bài học: Đây là lỗi vừa nghiêm trọng về vận hành vừa vi phạm quyền riêng tư. Nguyên tắc bất di bất dịch: nội dung động, có xác thực, chứa dữ liệu cá nhân thì KHÔNG BAO GIỜ được cache công khai. Luôn gắn Cache-Control: private, no-store cho endpoint nhạy cảm, và chỉ cache những gì thật sự tĩnh và dùng chung.

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

Dưới đây là quy trình thực chiến để cấu hình và vận hành DNS + CDN cho một dịch vụ web.

Bước 1 — Kiểm kê và hạ TTL trước. Trước bất kỳ thay đổi lớn nào, dùng lệnh dig để xem cấu hình hiện tại và hạ TTL:

dig +short A shopviet.vn
dig shopviet.vn A          # xem TTL trong phần ANSWER

Hạ TTL xuống 300 giây và chờ hết chu kỳ TTL cũ trước khi thao tác tiếp.

Bước 2 — Cấu hình bản ghi gốc. Thiết lập A/AAAA cho apex domain trỏ tới origin, CNAME cho www và các subdomain, MX + TXT (SPF/DKIM) cho email. Kiểm tra lại bằng:

dig shopviet.vn ANY
dig MX shopviet.vn

Bước 3 — Cắm CDN. Tạo phân phối (distribution) trên CDN (Cloudflare, CloudFront, Fastly...), khai báo origin. CDN sẽ cấp một hostname như d123.cloudfront.net. Trỏ subdomain cdn.shopviet.vn (hoặc chuyển toàn bộ traffic) tới hostname này bằng CNAME.

Bước 4 — Cấu hình chính sách cache. Đặt header đúng cho từng loại nội dung:

Ảnh/CSS/JS có version: Cache-Control: public, max-age=31536000, immutable
HTML: Cache-Control: public, max-age=0, must-revalidate
Trang cá nhân/API xác thực: Cache-Control: private, no-store

Bước 5 — Bật HTTPS và tự động gia hạn chứng chỉ. Dùng chứng chỉ do CDN quản lý tự động thay vì upload thủ công.

Bước 6 — Kiểm thử. Xác nhận cache hit bằng cách xem response header (X-Cache: Hit hoặc cf-cache-status: HIT). Test từ nhiều vùng địa lý.

Bước 7 — Giám sát. Theo dõi cache hit ratio, latency theo vùng, ngày hết hạn chứng chỉ và tên miền. Chuẩn bị sẵn thao tác purge/invalidate cache khi cần đẩy nội dung mới ngay lập tức.

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

Đặt CNAME ở apex domain. Chuẩn DNS không cho phép CNAME tại tenmien.vn. Giải pháp: dùng tính năng "CNAME flattening" (Cloudflare) hoặc bản ghi ALIAS/ANAME của nhà cung cấp.

Quên hạ TTL trước khi migrate. Đã nói ở tình huống 1 — luôn hạ TTL trước 48–72 giờ.

Cache nhầm nội dung động. Kiểm tra kỹ, không cho cache endpoint có xác thực. Khi nghi ngờ, mặc định no-store.

Không có kế hoạch invalidation. Deploy phiên bản mới nhưng người dùng vẫn thấy CSS/JS cũ do edge cache. Mẹo: đặt version vào tên file (app.a1b2c3.js) để mỗi bản build có URL mới, tránh phải purge thủ công.

Bỏ quên dig khi debug. Khi có sự cố, đừng đoán mò. Chạy dig @8.8.8.8 tenmien.vn và dig @1.1.1.1 tenmien.vn để so sánh — nếu các resolver trả kết quả khác nhau, bạn đang gặp vấn đề propagation.

Không giám sát ngày hết hạn. Đặt alert cho chứng chỉ TLS và hạn tên miền. Mất tên miền vì quên gia hạn là thảm họa không thể cứu vãn nhanh.

Mẹo dùng geo-DNS/anycast: với dịch vụ đa vùng, tận dụng anycast để tự động định tuyến người dùng tới edge gần nhất — nền tảng của mọi CDN hiện đại.

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

Thực hành dig: Chọn 3 tên miền lớn (ví dụ vnexpress.net, shopee.vn, google.com). Dùng dig để tìm A record, TTL, MX record và NS record của từng tên. Ghi lại xem tên nào dùng CDN (gợi ý: A record trỏ tới IP của Cloudflare/CloudFront, hoặc CNAME lộ ra hostname của CDN).

Phân tích cache header: Mở DevTools trình duyệt (tab Network), truy cập một trang tin lớn của Việt Nam. Tìm các response header Cache-Control, X-Cache / cf-cache-status. Phân loại: file nào được cache, file nào không, và giải thích vì sao.

Thiết kế kế hoạch migration: Viết ra quy trình 7 bước để chuyển một website từ nhà cung cấp A sang B mà không downtime, nêu rõ mốc thời gian hạ/nâng TTL và cách kiểm chứng ở mỗi bước.

Tình huống xử lý sự cố: Giả sử người dùng báo "web load được ảnh cũ dù đã deploy bản mới 30 phút trước". Liệt kê các bước chẩn đoán và cách khắc phục dùng invalidation + versioning.

Tóm tắt

DNS và CDN là tầng ngoài cùng mà mọi request đều đi qua trước khi chạm tới ứng dụng — hỏng ở đây nghĩa là hỏng tất cả, dù backend hoàn hảo. Bạn cần thuộc các loại bản ghi cốt lõi (A, AAAA, CNAME, MX, TXT, NS), hiểu sâu vai trò của TTL trong việc cache và migration, và nắm nguyên tắc hạ TTL trước khi thay đổi lớn.

Về CDN, hãy nhớ ba giá trị: giảm latency, giảm tải origin, và bảo vệ trước tấn công. Bí quyết vận hành nằm ở việc cấu hình đúng cache policy cho từng loại nội dung — tuyệt đối không cache dữ liệu động/cá nhân — cùng chiến lược versioning và invalidation để đẩy nội dung mới.

Cuối cùng, hai bài học đắt giá từ thực tế: luôn giám sát ngày hết hạn của chứng chỉ TLS và tên miền, và luôn dùng dig để debug thay vì đoán mò. Nắm vững những điều này, bạn đã kiểm soát được một trong những lớp hạ tầng âm thầm nhưng quyền lực nhất của mọi hệ thống tech.