DNS — phân giải tên miền hoạt động thế nào

TL;DR: Máy định tuyến theo IP, người nhớ theo tên: DNS là hệ tra cứu biến tên thành IP. Không có database trung tâm — tên miền là một cây phân cấp, root biết các TLD (.com, .vn), TLD biết authoritative server của từng domain, authoritative giữ bản ghi thật. Trình duyệt hỏi một recursive resolver, nó đi hỏi hộ cả chuỗi root → TLD → authoritative rồi trả kết quả, cache lại theo TTL. Lần đầu tốn vài chục ms; lần sau gần như 0 nhờ cache. dig +trace cho bạn xem từng bước.

Gõ google.com, khoảng 20ms sau bạn đã có IP của nó — từ một hệ thống không có cơ sở dữ liệu trung tâm nào chứa "mọi tên miền trên đời". Hàng trăm triệu domain, thay đổi liên tục, mà tra ra trong chớp mắt. Làm sao?

Bí mật là phân cấp + cache. Bài này (đào sâu chặng DNS bạn đã gặp lướt ở Module 1) giải thích cây tên miền, ai hỏi ai, và vì sao nó vừa nhanh vừa không cần trung tâm.

1. Analogy — Hỏi đường phân cấp

Bạn tìm "phòng Kế toán, công ty X, toà nhà Y". Bạn không hỏi một "người biết tuốt". Bạn hỏi lễ tân toà nhà Y, họ chỉ tầng của công ty X; lên tới nơi, bạn hỏi tiếp tân công ty X, họ chỉ phòng Kế toán. Mỗi cấp chỉ biết "cấp dưới kế tiếp ở đâu", không ai giữ toàn bộ bản đồ.

2. Cây tên miền phân cấp

Tên miền là một cây lộn ngược, gốc ở trên:

• Root (ký hiệu .): 13 nhóm root server, biết server của mọi TLD.
• TLD (Top-Level Domain): .com, .vn, .org… mỗi TLD biết authoritative server của các domain dưới nó.
• Authoritative server: nơi giữ bản ghi thật của một domain (vd google.com) — câu trả lời cuối cùng.

Ba bậc này chỉ giữ dữ liệu. Phần đi hỏi hộ bạn thuộc về một vai trò khác: recursive resolver.

3. Recursive resolver vs authoritative

Hai vai trò khác nhau, dễ lẫn:

• Recursive resolver (thường của ISP, hoặc 8.8.8.8, 1.1.1.1): nhận câu hỏi từ bạn rồi đi hỏi hộ cả chuỗi root → TLD → authoritative, gom kết quả trả về. Nó làm việc thay bạn.
• Authoritative server: chỉ trả lời về domain nó phụ trách, không đi hỏi ai. Nó là nguồn sự thật.

Trình duyệt bạn chỉ nói chuyện với recursive resolver (qua một stub resolver nhỏ trong OS).

Thử ngẫmresolver của ISP đột nhiên chậm 2 giây cho mọi tên miền, kể cả tên bạn vừa tra xong 10 giây trước. Với mô hình recursive và authoritative ở trên, bậc nào đáng nghi, và vì sao "vừa tra xong" lại là manh mối quan trọng?

4. Query flow — một lần tra "nguội"

Lần đầu hỏi www.example.com (chưa cache gì):

Recursive resolver đi từng bậc, mỗi bậc chỉ vào hơn một chút, tới authoritative thì có câu trả lời cuối (bản ghi A = IPv4). Rồi nó trả về và nhớ lại.

5. TTL & cache — vì sao lần sau nhanh?

Mỗi bản ghi DNS kèm TTL (Time To Live) — số giây được phép cache. Kết quả được cache ở nhiều tầng: trình duyệt, OS, recursive resolver. Lần sau hỏi lại trong thời hạn TTL, câu trả lời tới thẳng từ cache, không đi lại cả chuỗi, gần như 0 ms.

Hệ quả thực tế là propagation: khi bạn đổi IP của domain, các nơi đang cache bản cũ vẫn dùng IP cũ tới khi TTL hết. Vì vậy trước khi chuyển server, người ta hạ TTL xuống thấp vài ngày trước, để khi cắt sang IP mới các cache hết hạn nhanh.

Thử ngẫmsite vừa đổi hosting, TTL cũ để 86400 giây. Một đồng nghiệp báo curl vẫn ra IP server cũ sau nửa ngày — do đâu, và lần chuyển sau bạn sẽ làm khác gì?

6. Tự trace bằng dig

dig example.com +short chỉ in IP cuối. Muốn thấy cả chuỗi, dùng dig +trace: chính dig đóng vai recursive resolver, hỏi root, rồi TLD, rồi authoritative, in từng bậc ra màn hình (output rút gọn, đã bỏ vài dòng chữ ký DNSSEC, cơ chế ký số xác thực bản ghi, ngoài phạm vi bài này):

dig +trace example.com
# .                    518400  IN  NS  a.root-servers.net.
# .                    518400  IN  NS  b.root-servers.net.
# ;; Received 525 bytes from 1.1.1.1#53(1.1.1.1) in 3 ms
#
# com.                 172800  IN  NS  a.gtld-servers.net.   # <- root chi sang TLD .com
# com.                 172800  IN  NS  b.gtld-servers.net.
# ;; Received 1170 bytes from 198.41.0.4#53(a.root-servers.net) in 20 ms
#
# example.com.         172800  IN  NS  a.iana-servers.net.   # <- TLD chi sang authoritative
# example.com.         172800  IN  NS  b.iana-servers.net.
# ;; Received 200 bytes from 192.5.6.30#53(a.gtld-servers.net) in 40 ms
#
# example.com.         3600    IN  A   93.184.216.34         # <- ban ghi that
# ;; Received 56 bytes from 199.43.135.53#53(a.iana-servers.net) in 60 ms

Đọc từ trên xuống, ba khối này là đúng ba bậc trong hình ở mục 4. Khối đầu là root: nó không biết example.com, chỉ đưa ra danh sách server của .com. Khối thứ hai là TLD .com: cũng không có IP, chỉ chỉ tiếp sang a.iana-servers.net, authoritative của example.com. Khối cuối mới có bản ghi A, câu trả lời thật. Dòng Received ... from dưới mỗi khối cho biết câu trả lời đó tới từ máy nào, và tổng mấy chục ms cộng dồn là cái giá của một lần tra "nguội" mà cache ở mục 5 xoá đi.

7. Pitfall — hiểu nhầm thường gặp

❌ Nhầm 1: "Có một server DNS trung tâm chứa mọi tên miền." ✅ Không hề. DNS là phân tán + phân cấp: root chỉ biết TLD, TLD chỉ biết authoritative, mỗi authoritative chỉ giữ domain của mình. Không nơi nào giữ tất cả.

❌ Nhầm 2: "Đổi DNS là có hiệu lực ngay." ✅ Còn TTL: các cache giữ bản cũ tới khi hết hạn. Đổi IP mà TTL 3600 thì có client dùng IP cũ tới một giờ. Hạ TTL trước khi chuyển.

❌ Nhầm 3: "Recursive resolver và authoritative là một." ✅ Recursive đi hỏi hộ (làm việc thay bạn); authoritative là nguồn sự thật (chỉ trả lời domain của nó, không hỏi ai). Hai vai trò tách biệt.

8. 📚 Deep Dive — tài liệu gốc

9. Tóm tắt

• Tên miền là cây phân cấp: root → TLD (.com) → authoritative (giữ bản ghi thật). Không có database trung tâm.
• Recursive resolver đi hỏi hộ cả chuỗi; authoritative chỉ trả lời domain của mình. Trình duyệt chỉ nói với recursive (qua stub resolver).
• Query flow nguội: resolver hỏi root → TLD → authoritative, nhận A record (IP), trả về và cache theo TTL.
• TTL/cache khiến lần sau ~0ms nhưng gây propagation khi đổi DNS — hạ TTL trước khi chuyển server.
• dig +trace cho xem từng bậc trong cây phân cấp — cách trực quan nhất để "thấy" DNS hoạt động.

10. Tự kiểm tra

Bài tiếp theo: DNS record types & debug — A, CNAME, MX và dig