Toàn bộ quá trình phân giải DNS — từ trình duyệt đến root server qua bao nhiêu bước?

1. Quy trình đầy đủ 8 bước

┌─────────────────────────────────────────────────────────────┐
│  Trình duyệt (Chrome / Firefox) — gõ google.com             │
└────────────────┬────────────────────────────────────────────┘
                 │ ① Bộ nhớ đệm DNS của trình duyệt (Chrome ~60s)
                 ↓ miss
┌─────────────────────────────────────────────────────────────┐
│  Stub resolver của hệ điều hành + bộ nhớ đệm DNS hệ thống   │
└────────────────┬────────────────────────────────────────────┘
                 │ ② Bộ nhớ đệm hệ thống miss → gửi truy vấn UDP tới router
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  Chuyển tiếp DNS của router gia đình + bộ nhớ đệm router    │
└────────────────┬────────────────────────────────────────────┘
                 │ ③ Bộ nhớ đệm router miss → chuyển tiếp tới resolver đệ quy của ISP
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  Resolver đệ quy ISP / công cộng (1.1.1.1 / 8.8.8.8 / 223.5.5.5) │
│  Cache hit: trả về ngay, toàn bộ quá trình mất 1-5ms        │
│  Cache miss: vào quy trình "tra cứu đầy đủ" bên dưới        │
└────────────────┬────────────────────────────────────────────┘
                 │ ④ Hỏi root NS "google.com ở đâu?"
                 ↓
        13 nhóm root nameserver (a~m.root-servers.net)
                 │ ⑤ Trả lời "Tôi không biết, hãy hỏi NS của .com: a.gtld-servers.net"
                 ↓
        Máy chủ có thẩm quyền của TLD .com (Verisign)
                 │ ⑥ Trả lời "Tôi cũng không có đủ, hãy hỏi NS của google.com: ns1.google.com"
                 ↓
        Máy chủ có thẩm quyền của google.com (do chính Google vận hành)
                 │ ⑦ Trả lời "Bản ghi A của google.com = 142.250.x.x"
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  ⑧ Resolver đệ quy lưu đệm câu trả lời (theo TTL) và        │
│     trả về cho máy khách — mọi lớp dọc đường cũng           │
│     tự lưu một bản sao                                      │
└─────────────────────────────────────────────────────────────┘

Điểm mấu chốt: trong thực tế, quy trình đầy đủ 8 bước gần như không bao giờ xảy ra. Địa chỉ IP của các trang lớn gần như luôn nằm sẵn trong bộ nhớ đệm của resolver đệ quy, nên người dùng thông thường chỉ đi tới bước ④ là đã nhận được phản hồi. Chỉ những tên miền ít người biết, trang lâu không ai truy cập, TTL đã hết hạn hoặc tên miền mới đăng ký mới kích hoạt toàn bộ quy trình.

2. Giải thích 5 lớp bộ nhớ đệm DNS

Khi DNS được thiết kế vào năm 1983, người ta đã tính đến một thực tế: số lượt tra cứu nhiều gấp 100.000 lần số lần thay đổi. Vì vậy bộ nhớ đệm có ở khắp nơi, mỗi lớp giữ dữ liệu trong một khoảng TTL (Time To Live).

3. Truy vấn đệ quy và truy vấn lặp — khái niệm then chốt

3.1 Đệ quy (Recursive)

Máy khách (trình duyệt / stub của hệ điều hành) nói với resolver đệ quy của ISP: "Hãy tìm IP của google.com giúp tôi — tôi không quan tâm bạn làm thế nào." Resolver đệ quy phải hoàn tất toàn bộ quá trình tra cứu và trả về kết quả cuối cùng.

3.2 Lặp (Iterative)

Khi resolver đệ quy làm việc với root, TLD và các máy chủ có thẩm quyền, quá trình trao đổi đó là lặp — nó hỏi root, root bảo "hãy hỏi .com", nó đi hỏi .com, .com bảo "hãy hỏi google", nó đi hỏi google. Mỗi bước chỉ đi qua một chặng — không phải kiểu "tôi hỏi root và root lo hết mọi thứ cho tôi".

4. Tự kiểm tra — dig +trace

dig +trace buộc thực hiện một lượt tra cứu lặp đầy đủ và hiển thị từng bước:

$ dig +trace cleanip.io

; <<>> DiG 9.10.6 <<>> +trace cleanip.io
;; global options: +cmd

; ① Chặng 1 — hỏi root (.)
.                       518400  IN      NS      a.root-servers.net.
.                       518400  IN      NS      b.root-servers.net.
... (13 bản ghi NS của root)
;; Received 525 bytes from 127.0.0.53#53 in 5 ms

; ② Chặng 2 — hỏi TLD .io
io.                     172800  IN      NS      a0.nic.io.
io.                     172800  IN      NS      b0.nic.io.
... (4 NS của .io)
;; Received 822 bytes from 198.41.0.4#53(a.root-servers.net) in 121 ms

; ③ Chặng 3 — hỏi máy chủ có thẩm quyền của cleanip.io
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 109 bytes from 156.154.150.6#53(a0.nic.io) in 53 ms

; ④ Cuối cùng nhận được câu trả lời
cleanip.io.             300     IN      A       104.21.x.x
cleanip.io.             300     IN      A       172.67.x.x
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 154 bytes from 173.245.59.108#53(nolan.ns.cloudflare.com) in 12 ms

Phân tích:

• Toàn bộ quá trình mất 5 + 121 + 53 + 12 = 191 ms — lần tra cứu nguội đầu tiên quả thật chậm
• Nhưng một giây sau tra lại cùng tên miền chỉ mất 1-2 ms, vì bộ nhớ đệm đệ quy của ISP đã có sẵn (TTL 300 giây)
• 104.21.x.x / 172.67.x.x là địa chỉ CDN của Cloudflare — IP máy chủ gốc thật của trang chúng tôi được ẩn sau CDN

5. Giải thích TTL — bộ nhớ đệm thực sự kéo dài bao lâu

TTL (Time To Live) là trường mà máy chủ có thẩm quyền dùng để báo cho mọi resolver đệ quy "bạn chỉ được lưu đệm tối đa chừng này", tính bằng giây.

Lưu ý: TTL là "thời gian lưu đệm tối đa" — từng resolver có thể xóa bộ nhớ đệm sớm hơn, nhưng không bao giờ được kéo dài. Vì vậy dù TTL có thẩm quyền là 1 giờ, một số resolver vẫn có thể truy vấn lại chỉ sau 10 phút.

Cạm bẫy: Trước khi đổi IP, hãy rút ngắn TTL trước (1-5 phút) và chờ TTL cũ hết hạn hoàn toàn rồi mới chuyển — nếu không, một số người dùng sẽ tiếp tục truy cập IP cũ trong hơn một giờ.

6. Tra cứu nhanh các loại bản ghi DNS

7. Tối ưu DNS — làm sao để phân giải nhanh hơn

7.1 Chọn recursive resolver ở gần

Trung Quốc đại lục: 223.5.5.5 (Alibaba) / 119.29.29.29 (DNSPod) phân giải các trang trong nước nhanh nhất. Nơi khác: 1.1.1.1 (Cloudflare, mạng anycast phủ rộng nhất) / 8.8.8.8 (Google). Xemdanh bạ resolver DNS công cộng.

7.2 Bật DoH (DNS-over-HTTPS)

Mã hóa truy vấn DNS qua HTTPS giúp ISP không thể xem hay sửa đổi chúng (chặn kiểu chiếm quyền NXDOMAIN). Chrome, Firefox và Edge đều hỗ trợ — chỉ cần bật trong phần cài đặt.

7.3 Làm nóng trước (DNS Prefetch)

Thêm <link rel="dns-prefetch" href="//api.example.com"> vào <head> của trang web để trình duyệt phân giải sẵn khi rảnh — đến lúc yêu cầu thật diễn ra thì đã trúng bộ nhớ đệm.

7.4 Dùng CDN + NS Anycast

Đặt NS có thẩm quyền của bạn trên Anycast (Cloudflare / Route 53) để người dùng khắp thế giới hỏi tới điểm gần nhất — giảm độ trễ của bước ③ từ 100ms xuống 10ms.

7.5 Đặt TTL hợp lý

Đặt TTL dài (1-7 ngày) cho các bản ghi hiếm khi thay đổi (NS / MX); đặt TTL ngắn (5-60 phút) cho các bản ghi A có thể cần chuyển đổi.

8. Câu hỏi thường gặp

8.1 Đã đổi DNS nhưng không có tác dụng — vì sao?

Trước tiên, hãy nghĩ xem TTL hiện tại là bao nhiêu. Sau khi đổi DNS, mọi recursive resolver vẫn tiếp tục trả về IP cũ cho đến khi TTL cũ hết hạn. "Cập nhật toàn cầu" thường mất khoảng 2× TTL (do các resolver không đồng bộ với nhau).

• Phía máy khách: ipconfig /flushdns (Windows) / sudo killall -HUP mDNSResponder (macOS)
• Chờ bộ nhớ đệm của recursive resolver công cộng hết hạn: 1.1.1.1 / 8.8.8.8 đều có công cụ "purge" riêng để xóa thủ công

8.2 Có người truy cập được, có người không — đầu độc DNS

Thường gặp khi truy cập trang nước ngoài từ Trung Quốc đại lục — GFW chèn phản hồi DNS giả / ISP chiếm quyền truy vấn. Chuyển sang DoH (DNS mã hóa trên trình duyệt) có thể vượt qua phần lớn trường hợp đầu độc DNS.

8.3 Đăng ký tên miền xong bao lâu thì dùng được?

Sau khi đăng ký, cơ quan quản lý TLD đẩy bản ghi NS của bạn lên các máy chủ có thẩm quyền cấp cao nhất của .com / .net v.v. — thường mất 15 phút đến 24 giờ. Tên miền .cn / .com.cn có thể cần đăng ký ICP mới phân giải được trong Trung Quốc đại lục.