Tản mạn về DNS

Hệ thống phân giải tên miền (DNS) ra đời năm 1983 để giải quyết sự sụp đổ không thể tránh khỏi của một tệp văn bản duy nhất mang tên HOSTS.TXT — chiếc “danh bạ” chứa toàn bộ bản đồ chuyển đổi từ tên máy tính sang địa chỉ mạng của ARPANET, tiền thân của Internet.

Để hiểu sâu hơn về “nỗi đau” này, chúng ta cần lùi ngược dòng thời gian về giai đoạn bình minh của Internet, trước khi tệp định danh tập trung ấy ra đời.

1. Thời kỳ “Tiền HOSTS.TXT” (1969 – 1971): Kỷ nguyên của những con số thuần túy

Tháng 10 năm 1969, kết nối host-to-host đầu tiên của ARPANET được thực hiện giữa UCLA và SRI. Đến cuối năm 1969, bốn nút mạng đầu tiên — UCLA, SRI, UCSB và Đại học Utah — đã được kết nối. Lúc này, khái niệm “tên máy tính” như google.com hoàn toàn chưa tồn tại.

Để kết nối các máy tính khổng lồ (Host) lại với nhau, người ta dùng một thiết bị gọi là IMP (Interface Message Processor — tiền thân của Router ngày nay). Muốn kết nối từ máy này sang máy khác, các kỹ sư phải ghi nhớ và nhập trực tiếp số cổng phần cứng nhị phân: số 65 cho UCLA, số 2 cho SRI,…

Khi mạng lưới tăng lên vài chục máy, không một bộ não người nào có thể nhớ nổi máy tính của giáo sư A tại Harvard hay viện nghiên cứu B tại MIT nằm ở cổng số mấy. Gõ nhầm một con số đồng nghĩa với việc kết nối thẳng vào máy tính của một cơ quan quân sự hoặc một phòng thí nghiệm hoàn toàn xa lạ.

2. Sự ra đời mang tính “chắp vá” của HOSTS.TXT (1971 – 1974)

Nhận thấy việc bắt con người nhớ các con số là quá tàn nhẫn, năm 1971, bà Peggy Karp thuộc tập đoàn MITRE xuất bản tài liệu RFC 226, đề xuất gán cho mỗi địa chỉ số một cái tên gợi nhớ bằng chữ (Host Mnemonics). Thay vì gõ số, người ta có thể gõ MIT-Multics hay UCLA-A.

Tuy nhiên, buổi đầu vô cùng hỗn loạn: mỗi trường đại học tự giữ một danh sách riêng. Công ty BBN — đơn vị vận hành thiết bị mạng — thỉnh thoảng lại hỏi các kỹ sư “Ông muốn đặt tên máy của ông là gì?” rồi ghi vào một cuốn sổ tay có tên là Network Host Status.

Đến năm 1974, khi sự lộn xộn đã vượt tầm kiểm soát, chính phủ Mỹ giao toàn quyền quản lý cho bà Elizabeth Feinler tại Trung tâm Thông tin Mạng (NIC) thuộc Viện Nghiên cứu Stanford (SRI). Tệp HOSTS.TXT chính thức trở thành chiếc danh bạ tập trung duy nhất cho toàn bộ mạng lưới.

3. Cận cảnh “cơn ác mộng vận hành” mang tên HOSTS.TXT (1974 – 1983)

Hãy thử đóng vai một quản trị viên mạng tại MIT vào năm 1980. Bạn vừa mua một máy tính đắt tiền và muốn đặt tên nó là MIT-MAIL. Quy trình bạn phải trải qua trông như thế này:

1
2
3
4
5
6
7

[Máy tính mới tại MIT]
       │  (1) Muốn đặt tên là "MIT-MAIL"
       ▼
[Gọi điện thoại qua tổng đài] ──► [Bà Elizabeth Feinler tại SRI - Stanford]
                                         │  (2) Gõ thủ công vào tệp HOSTS.TXT
                                         ▼
[Toàn bộ các máy tính khác]  ◄── [Tải lại tệp HOSTS.TXT bằng FTP vào ban đêm]

Bạn không thể tự cấu hình. Bạn phải nhấc máy điện thoại, quay số gọi đến California. Bà Feinler hoặc nhân viên sẽ kiểm tra xem MIT-MAIL đã có ai dùng chưa. Nếu chưa, họ mở tệp văn bản ra, gõ thêm một dòng bằng tay rồi lưu lại.

Tệp này chỉ được cập nhật 1–2 lần một tuần. Các máy tính tại Harvard, Utah, NASA muốn gửi thư cho máy của bạn sẽ phải đợi đến lịch chạy lệnh FTP để tải toàn bộ tệp HOSTS.TXT mới về. Nếu chưa kịp tải, họ sẽ nhận thông báo lỗi: “Không tìm thấy tên miền này”.

Nghẽn cổ chai tại một văn phòng duy nhất

Văn phòng NIC đóng cửa lúc 5 giờ chiều và nghỉ vào ngày lễ. Như cha đẻ DNS Paul Mockapetris từng chia sẻ: nếu bạn thiết lập máy chủ vào tối thứ Sáu, bạn phải đợi đến thứ Hai để máy tính của mình được “định danh” trên mạng.

Khủng hoảng băng thông và đồng bộ

Mỗi khi HOSTS.TXT được cập nhật, mọi máy tính trên ARPANET đều phải kết nối qua FTP để tải lại toàn bộ tệp. Khi quy mô mạng đạt tới hàng ngàn máy, việc tất cả cùng lao vào tải một tệp văn bản khổng lồ từ một máy chủ duy nhất tại Stanford đã làm tê liệt đường truyền. Quá trình phân phối mất hàng ngày trời, dẫn đến tình trạng máy tính này đã đổi địa chỉ nhưng máy kia vẫn dùng dữ liệu cũ, gây mất kết nối liên tục.

Xung đột đặt tên (Flat Namespace)

Hệ thống cũ không có cấu trúc phân cấp như .com, .edu ngày nay — nó là một danh sách phẳng. Nếu MIT đã đăng ký tên máy chủ là mail, thì Harvard hay bất kỳ tổ chức nào khác không thể dùng tên đó nữa. Tìm ra một cái tên chưa ai đặt dần trở thành cơn ác mộng khi mạng lưới ngày một phình to.

4. Cái chết được báo trước và sự khai sinh của DNS

Bước sang đầu những năm 1980, ARPANET chuyển sang giao thức TCP/IP và Internet hiện đại bắt đầu hình thành. Số lượng máy tính không còn dừng ở vài chục mà tăng lên hàng ngàn, rồi hàng chục ngàn. Tệp HOSTS.TXT phình to như một cuốn sách dày cộp. Hàng ngàn máy cùng lúc truy cập vào đúng một chiếc máy chủ tại Stanford để tải tệp này, khiến mạng nghẽn nghiêm trọng và máy chủ SRI-NIC liên tục quá tải rồi sập.

Đó là khoảnh khắc đỉnh điểm của nỗi đau, buộc Paul Mockapetris phải đập bỏ hoàn toàn cơ chế “danh bạ tập trung” để khai sinh ra DNS vào năm 1983 (thông qua các tài liệu RFC 882 và RFC 883). Thực tế DNS vẫn có hệ thống tập trung ở Root Server, nhưng đã được phân tán rộng rãi trên toàn cầu. DNS chữa lành mọi vết thương bằng hai nguyên lý cốt lõi:

• Cơ sở dữ liệu phân tán (Distributed): Không còn một máy chủ trung tâm nào ôm toàn bộ dữ liệu. Trách nhiệm quản lý tên miền được chia nhỏ và phân quyền cho các máy chủ trên toàn cầu.
• Không gian tên phân cấp (Hierarchical): Cấu trúc dạng cây cho phép mail.mit.edu tách biệt hoàn toàn với mail.harvard.edu, giải quyết triệt để vấn đề trùng tên và cho phép Internet mở rộng quy mô đến tận ngày nay.

Một hệ thống tự động, phân tán, không bao giờ phụ thuộc vào bất kỳ một cá nhân hay một chiếc máy chủ đơn lẻ nào — đó chính là di sản mà DNS để lại cho thế giới.

Chúng ta tiếp tục với nội dung hơi học thuật một chút nhé!

5. Vậy DNS là gì?

DNS (Domain Name System — Hệ thống phân giải tên miền) hoạt động như một cuốn danh bạ điện thoại của Internet: tự động dịch các tên miền mà con người dễ nhớ (ví dụ: google.com) thành địa chỉ IP dạng số mà máy tính hiểu được (ví dụ: 142.250.191.14), từ đó thiết lập kết nối đến đúng website cần tìm.

6. Cấu trúc phân cấp của tên miền

Tên miền không đứng độc lập mà được tổ chức theo cấu trúc hình cây lật ngược, đọc từ phải sang trái:

Root Domain (Tên miền gốc) — Gốc của toàn bộ hệ thống, ký hiệu bằng một dấu chấm ., thường được ẩn đi trong thanh địa chỉ trình duyệt.

TLD — Top-Level Domain (Tên miền cấp cao nhất) — Phần đuôi nằm tận cùng bên phải. Gồm hai loại chính:

• gTLD (Generic TLD): Tên miền dùng chung như .com, .net, .org, .edu.
• ccTLD (Country Code TLD): Tên miền quốc gia như .vn (Việt Nam), .us (Mỹ), .jp (Nhật Bản).

SLD — Second-Level Domain (Tên miền cấp hai) — Tên thương hiệu do cá nhân hoặc tổ chức đăng ký trực tiếp dưới TLD. Ví dụ: facebook trong facebook.com.

Subdomain (Tên miền phụ) — Phần nằm trước SLD để phân tách các dịch vụ khác nhau. Ví dụ: mail trong mail.google.com, hay www trong www.example.com.

7. Các thành phần trong hệ thống DNS

Để hiểu DNS hoạt động như thế nào, trước tiên cần phân biệt rõ hai nhóm thành phần: nhóm đi hỏi và nhóm đi trả lời.

Nhóm thực hiện truy vấn (phía người dùng)

DNS Client / Stub Resolver — Phần mềm tích hợp sẵn trên thiết bị của bạn (trong hệ điều hành hoặc trình duyệt). Nó tiếp nhận tên miền bạn gõ, kiểm tra nhanh bộ nhớ đệm nội bộ. Nếu không có, nó gửi đúng một câu hỏi đến Recursor rồi… ngồi chờ kết quả. Khá “lười biếng”, nhưng đó chính xác là nhiệm vụ của nó.

DNS Recursor / Recursive Resolver — Máy chủ trung gian do nhà mạng (Viettel, FPT, VNPT) hoặc các tổ chức công nghệ (Google 8.8.8.8, Cloudflare 1.1.1.1) vận hành. Khi nhận yêu cầu từ DNS Client, Recursor thay mặt bạn chạy khắp Internet, lần lượt gõ cửa từng máy chủ để mang bằng được địa chỉ IP về. Ngoài ra, nó còn lưu kết quả vào cache để phục vụ ngay cho những người dùng khác hỏi cùng tên miền sau đó.

Nhóm trả lời truy vấn (phía máy chủ)

Root Nameserver — Tầng cao nhất trong hệ thống phân cấp. Nó không lưu IP của website cụ thể nào, nhưng biết chính xác máy chủ nào quản lý từng đuôi tên miền. Câu trả lời của nó luôn là: “Tôi không biết google.com ở đâu, nhưng muốn tìm đuôi .com thì đến đây mà hỏi.”

TLD Nameserver — Quản lý toàn bộ thông tin của một phần mở rộng cụ thể (.com, .vn,…). Nó biết tên miền google.com do ai quản lý, và chỉ tiếp Recursor đến đúng cửa: “Tôi không giữ IP của google.com, nhưng đây là Authoritative Nameserver của chính Google.”

Authoritative Nameserver — Điểm dừng cuối cùng và cũng là nguồn sự thật duy nhất. Đây là nơi chủ sở hữu website (thường thông qua các nhà đăng ký tên miền như Cloudflare, GoDaddy, Mắt Bão, P.A Việt Nam,…) cấu hình toàn bộ bản ghi DNS. Nó trả lời dứt khoát: “Tôi là ông chủ của tên miền này. Địa chỉ IP chính xác là 142.250.191.14.”

Điểm khác biệt cốt lõi giữa Recursor và Authoritative

Hai thành phần này thường bị nhầm lẫn vì cùng tên “máy chủ DNS”, nhưng bản chất hoàn toàn khác nhau:

8. Nguyên tắc ủy nhiệm: Cách Root Server “phân quyền” xuống dưới

Root Server không lưu trữ toàn bộ “danh bạ” của Internet — điều đó sẽ tái tạo lại đúng vấn đề của HOSTS.TXT. Thay vào đó, hệ thống hoạt động theo cơ chế ủy nhiệm (Delegation):

Khi tổ chức ICANN/IANA quyết định giao quyền quản lý đuôi .vn cho VNNIC (Trung tâm Internet Việt Nam), một bản ghi ủy quyền (NS record) sẽ được ghi vào Tệp vùng gốc (Root Zone File) trên các Root Server. Bản ghi này đơn giản chỉ nói một điều: “Bất kỳ tên miền nào kết thúc bằng .vn, hãy đến hỏi máy chủ DNS của VNNIC.”

Cơ chế này lan xuống từng tầng: VNNIC ủy quyền example.vn cho chủ sở hữu tên miền đó, chủ tên miền lại ủy quyền subdomain blog.example.vn cho một máy chủ khác nếu muốn. Toàn bộ hệ thống DNS là một chuỗi ủy nhiệm liên tục từ gốc xuống đến lá — không ai ôm toàn bộ dữ liệu, không ai là điểm thất bại duy nhất.

9. Hành trình phân giải tên miền (DNS Resolution)

Toàn bộ quá trình tìm kiếm địa chỉ IP được gọi là DNS Resolution, kéo dài chỉ từ 10 đến 100 mili-giây. Hãy theo dõi từng bước khi bạn gõ https://google.com:

Bước 1 — Kiểm tra bộ nhớ đệm nội bộ (DNS Cache)

Trước khi gửi bất kỳ truy vấn nào ra ngoài, máy tính tự kiểm tra xem địa chỉ IP này đã được lưu sẵn chưa:

• Browser Cache: Trình duyệt tìm trong kho dữ liệu tạm thời của chính nó.
• OS Cache: Nếu trình duyệt không có, hệ điều hành kiểm tra tiếp file hosts và bộ nhớ đệm DNS nội bộ. Nếu tìm thấy và bản ghi chưa hết hạn, quá trình kết thúc ngay tại đây — không cần hỏi bất kỳ máy chủ nào.

Bước 2 — Chuyển yêu cầu cho DNS Recursor

Nếu cache trống, máy tính gửi truy vấn đến DNS Recursor. Từ bước này trở đi, Recursor thay mặt bạn thực hiện toàn bộ hành trình.

Bước 3 — Hỏi Root Nameserver

Recursor gửi câu hỏi đến Root Nameserver. Root Server đọc phần đuôi .com trong tên miền rồi trả lời: “Tôi không biết IP của trang đó, nhưng đây là địa chỉ TLD Nameserver quản lý đuôi .com.”

Bước 4 — Hỏi TLD Nameserver

Recursor đến TLD Nameserver của .com. Máy chủ này tra cứu và chỉ tiếp: “Đây là địa chỉ Authoritative Nameserver của google.com.”

Bước 5 — Hỏi Authoritative Nameserver

Recursor đến đích cuối. Authoritative Nameserver trả về địa chỉ IP chính xác (ví dụ: 142.250.190.46).

Bước 6 — Trả kết quả và lưu cache

Recursor đưa IP về cho máy tính của bạn. IP này được lưu vào DNS Cache với thời hạn nhất định — gọi là TTL (Time To Live, tính bằng giây). Trình duyệt dùng IP đó để gửi yêu cầu HTTP/HTTPS và tải trang web về hiển thị.

Tóm lại:

Để dễ hình dung, quá trình này giống như bạn nhờ một anh xe ôm (Recursor) tìm nhà một người quen tên “Google”. Anh xe ôm không rành đường nên tấp vào chốt dân phòng của phường (Root Server) hỏi thăm. Dân phòng bảo: “Nhà này ở khu phố .com, anh chạy lại hỏi ông tổ trưởng khu phố đó (TLD Server).” Gặp ông tổ trưởng, ông ấy chỉ tiếp: “Nhà Google à? Phải tới hỏi thẳng bác bảo vệ riêng của khu biệt thự đó (Authoritative Server) mới biết số nhà.” Tới nơi, bác bảo vệ lật sổ ra và chốt: “Google ở căn số 142.” Anh xe ôm có được địa chỉ chính xác liền quay về báo cho bạn.

Tại sao chỉ mất vài mili-giây? Hơn 90% truy vấn DNS hàng ngày được giải quyết ngay từ Bước 1 hoặc 2 — từ cache của máy hoặc cache của nhà mạng — không cần chạy đủ cả bốn tầng. Với những truy vấn phải đi toàn hành trình, Root Server và TLD Server sử dụng công nghệ Anycast để tự động kết nối đến máy chủ vật lý gần bạn nhất trên thế giới.

Để trực quan hóa toàn bộ hành trình này, các kỹ sư hệ thống thường sử dụng công cụ dig (có sẵn trên Linux/macOS hoặc WSL). Bằng cách thêm tham số +trace, chúng ta ép dig bỏ qua bộ nhớ đệm và đóng vai trò như một Recursor, đi hỏi tuần tự từ Root Server xuống đến Authoritative Server:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

$ dig +trace google.com

# 1. Đầu tiên, máy tính đi hỏi một trong 13 Root Server để tìm máy chủ quản lý đuôi .com
.                       518400  IN      NS      a.root-servers.net.
...

# 2. Root Server trả lời: "Hãy đến hỏi TLD Server của đuôi .com"
com.                    172800  IN      NS      a.gtld-servers.net.
...

# 3. TLD Server trả lời: "Hãy đến hỏi Authoritative Server của Google"
google.com.             172800  IN      NS      ns1.google.com.
...

# 4. Cuối cùng, ns1.google.com trả về kết quả IP chính xác
google.com.             300     IN      A       142.250.191.14

Đây cũng là phương pháp chẩn đoán sự cố tiêu chuẩn khi một tên miền không thể phân giải. Nếu hành trình bị đứt ở bất kỳ khâu nào, kết quả trả về sẽ chỉ ra chính xác máy chủ nào đang gặp sự cố.

10. Bộ nhớ đệm DNS (DNS Caching)

Caching là lý do DNS có thể phục vụ hàng tỉ truy vấn mỗi ngày mà không sập. Nguyên lý đơn giản: một khi địa chỉ IP đã được phân giải thành công, kết quả được lưu lại ở nhiều tầng — trình duyệt, hệ điều hành, DNS Recursor của nhà mạng — để các lần truy vấn sau không cần lặp lại toàn bộ hành trình.

Thời gian một bản ghi được phép lưu trong cache do chủ sở hữu tên miền kiểm soát thông qua giá trị TTL (Time To Live). TTL cao (vài giờ đến vài ngày) giúp giảm tải cho hệ thống nhưng làm chậm tốc độ cập nhật khi website đổi IP. TTL thấp (vài phút) giúp thay đổi lan truyền nhanh hơn nhưng tăng số lượng truy vấn đến máy chủ gốc. Đây là một sự đánh đổi mà người quản trị hệ thống phải cân nhắc kỹ, đặc biệt trước khi thực hiện migration hoặc thay đổi hạ tầng lớn.

11. Các loại bản ghi DNS phổ biến (DNS Records)

Bản ghi DNS là các tệp cấu hình nằm trong Authoritative Nameserver, chỉ định cách điều phối lưu lượng truy cập của một tên miền:

• Bản ghi A: Ánh xạ tên miền sang địa chỉ IPv4 (ví dụ: 192.0.2.1).
• Bản ghi AAAA: Ánh xạ tên miền sang địa chỉ IPv6.
• Bản ghi CNAME (Canonical Name): Tạo bí danh — trỏ tên miền này sang tên miền khác (ví dụ: www.quorix.io.vn → quorix.io.vn).
• Bản ghi MX (Mail Exchange): Xác định máy chủ chịu trách nhiệm nhận email của tên miền.
• Bản ghi TXT (Text): Chứa chuỗi văn bản thuần túy, thường dùng để xác minh quyền sở hữu tên miền hoặc cấu hình bảo mật email như SPF, DKIM. (Lưu ý lịch sử: Năm 2006, IETF từng giới thiệu một loại bản ghi chuyên dụng tên là SPF - Type 99. Tuy nhiên, do chi phí và độ phức tạp khi cập nhật toàn bộ hệ sinh thái DNS (từ máy chủ đến thư viện phần mềm) để hỗ trợ bản ghi mới là quá lớn, các quản trị viên hệ thống đã tận dụng bản ghi TXT như một giải pháp thay thế. Sự phổ biến của cách làm này buộc IETF phải ban hành RFC 7208 vào năm 2014, chính thức loại bỏ bản ghi SPF chuyên dụng và công nhận việc sử dụng TXT làm tiêu chuẩn bắt buộc).
• Bản ghi NS (Name Server): Xác định máy chủ nào đang giữ quyền quản lý (authoritative) các bản ghi DNS của tên miền đó. Đây cũng chính là bản ghi ủy nhiệm được đề cập ở phần trên.
• Bản ghi SRV (Service): Chỉ định cổng (port) cho các dịch vụ cụ thể (như SIP, Minecraft server).
• Bản ghi CAA (Certificate Authority Authorization): Bản ghi bảo mật quy định Tổ chức cấp phát SSL nào được phép cấp chứng chỉ cho tên miền này.

Lưu ý: CNAME không được phép đứng ở Tên miền gốc (Apex/Root Domain) theo RFC 1034. Nghĩa là bạn được phép tạo www.quorix.io.vn IN CNAME quorix.io.vn. Nhưng bạn KHÔNG THỂ làm ngược lại quorix.io.vn IN CNAME ten-mien-khac.com (vì Apex bắt buộc phải chứa SOA và NS record, mà luật DNS cấm CNAME đứng chung với bất kỳ record nào khác ngoài DNSSEC). Khá nhiều kỹ sư web từng “khóc thét” vì vụ này và phải xài bản ghi ảo ALIAS hoặc ANAME của Cloudflare/Route53 để lách luật.

Cấu trúc một tệp vùng (Zone File) thông thường trông như sau:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

; Bắt đầu tệp vùng - khai báo máy chủ DNS chính và email quản lý
@ IN SOA ns1.example.com. admin.example.com. (
                  2026061801 ; Serial Number - Ngày tháng + số thứ tự
                        3600 ; Refresh - Cập nhật sau 1 giờ
                         900 ; Retry - Thử lại sau 15 phút nếu lỗi
                      604800 ; Expire - Hết hạn sau 1 tuần
                        3600 ; Negative TTL - Cache lỗi trong 1 giờ
)

; Bản ghi NS - Ủy quyền cho các máy chủ DNS chính
@            IN NS  ns1.example.com.
@            IN NS  ns2.example.com.

; Bản ghi A - Ánh xạ miền gốc đến địa chỉ IPv4
@            IN A   [IP_ADDRESS]

; Bản ghi AAAA - Ánh xạ miền gốc đến địa chỉ IPv6
@            IN AAAA [IP_ADDRESS]

; Các bản ghi phụ (subdomains)
www          IN A   [IP_ADDRESS]
api          IN A   [IP_ADDRESS]

; Bản ghi CNAME - Tạo bí danh
campaign     IN CNAME www.example.com.

; Bản ghi MX - Chỉ định máy chủ nhận Email
@            IN MX 10 mail.example.com.
@            IN MX 20 backup-mail.example.com.

; Bản ghi TXT - Thông tin xác thực hoặc chính sách
@            IN TXT "v=spf1 include:_spf.google.com ~all"
@            IN TXT "docusign=01957b38-4f3c-400d-9b1a-d7a09818a57c"

; Bản ghi SRV - Chỉ định dịch vụ SIP (Voice over IP)
_sip._tcp    IN SRV 0 5 5060 sip.example.com.

; Bản ghi CAA - Xác định CA cấp chứng chỉ
@            IN CAA 0 issue "letsencrypt.org"
@            IN CAA 0 issue "comodoca.com"

; Bản ghi PTR - Phục vụ truy vấn ngược (Reverse DNS)
; (Thường nằm trong file reverse zone của nhà cung cấp)

Sự tinh tế của “Negative TTL”: Thông số cuối cùng trong bản ghi SOA (3600) quy định thời gian Negative Caching. Khi một truy vấn trỏ đến tên miền không tồn tại (như ten-mien-ma.com), máy chủ Authoritative sẽ trả về lỗi NXDOMAIN. Trình phân giải (Recursor) sẽ lưu lại kết quả lỗi này trong 1 giờ. Khi nhận được truy vấn tương tự trong khoảng thời gian đó, Recursor sẽ trả về lỗi ngay lập tức từ bộ nhớ đệm mà không cần truy vấn lại. Cơ chế này giúp bảo vệ máy chủ Authoritative khỏi tình trạng quá tải do các truy vấn lỗi lặp lại liên tục.

Phân giải ngược (Reverse DNS) & Bản ghi PTR

Phần lớn các truy vấn DNS thông thường là Forward DNS — ánh xạ tên miền dễ nhớ (như google.com) sang địa chỉ IP. Tuy nhiên, trong quản trị hệ thống, sẽ có những lúc chúng ta chỉ cầm trong tay một dải IP vô danh (trong log của tường lửa, web server…) và cần biết IP đó thuộc về ai. Lúc này, quá trình tra cứu ngược (Reverse DNS) bằng bản ghi PTR (Pointer Record) được kích hoạt.

Bản chất của PTR ngược hoàn toàn với bản ghi A: nó ánh xạ một địa chỉ IP ngược trở lại tên miền (ví dụ: 142.250.191.14 → google.com).

Vấn đề kỹ thuật đặt ra là: DNS được thiết kế để tìm kiếm theo dạng cây phân cấp dựa trên chuỗi văn bản (đọc từ phải sang trái, từ TLD xuống). Vậy làm sao để phân giải một dãy số IP theo cơ chế đó?

Để giải quyết, IETF tạo ra một không gian tên miền đặc biệt là .in-addr.arpa (cho IPv4) và .ip6.arpa (cho IPv6). Khi tra cứu Reverse DNS cho địa chỉ IP 142.250.191.14, hệ thống sẽ đảo ngược thứ tự các octet thành 14.191.250.142.in-addr.arpa. Lý do phải đảo ngược là để khớp với nguyên tắc phân cấp của DNS: octet 142 (phần định danh mạng rộng nhất) nằm bên trái trong IP nhưng khi chuyển sang DNS phải nằm ở bên phải cùng (gần với tên miền gốc nhất).

Vai trò thực tế của Reverse DNS

Trong trải nghiệm duyệt web hàng ngày, Reverse DNS gần như vô hình. Nhưng ở tầng hệ thống, thiếu bản ghi PTR có thể gây ra những đứt gãy nghiêm trọng:

• Bộ lọc Anti-Spam (Email Server): Đây là trường hợp sử dụng bắt buộc nhất của PTR. Khi một máy chủ lạ (IP 1.2.3.4) gửi thư đến hệ thống của Gmail, Gmail lập tức tra cứu ngược IP này. Nếu PTR trả về đúng mail.example.com (khớp với bản ghi A cấu hình ban đầu) thì thư mới có cơ hội vào Inbox. Một máy chủ mail không có bản ghi PTR hoặc cấu hình sai sẽ bị các hệ thống lớn từ chối nhận email (Reject) ngay từ cửa ngõ, hoặc đẩy thẳng vào thư mục Spam.
• Network Logging và Security: Trong các báo cáo phân tích lưu lượng mạng hoặc log truy cập, Reverse DNS tự động “phiên dịch” hàng ngàn IP thành các hostname cụ thể (ví dụ: crawl.googlebot.com thay vì 66.249.66.1), giúp quản trị viên nhận diện nhanh các bot tìm kiếm hợp lệ, hoặc khoanh vùng được nguồn tấn công từ một dải mạng cụ thể.

Đặc quyền cấu hình bản ghi PTR

Một điểm khác biệt lớn nhất giữa cấu hình Forward DNS (các bản ghi A, CNAME, TXT) và Reverse DNS nằm ở quyền sở hữu.

Với tên miền, bạn mua từ GoDaddy hay Namecheap và có toàn quyền chỉnh sửa file zone trên Cloudflare. Nhưng với IP, bạn đang “thuê” hạ tầng. Quyền tạo bản ghi PTR thuộc về đơn vị đang nắm giữ (allocate) dải IP gốc đó — tức là Nhà cung cấp dịch vụ mạng (ISP) hoặc Cloud Provider (AWS, Azure, DigitalOcean).

Bạn không thể tự thêm bản ghi PTR trên giao diện quản lý tên miền của mình. Để thiết lập, bạn phải yêu cầu trực tiếp ISP hoặc nhà cung cấp máy chủ cập nhật bản ghi này. Đây cũng là lý do vì sao việc tự dựng một Mail Server tại nhà bằng đường truyền mạng cá nhân thường thất bại: hầu hết các ISP không hỗ trợ cấu hình PTR cho IP động hoặc các gói cước hộ gia đình.

12. Hạ tầng thực tế: 13 địa chỉ, 12 tổ chức, hơn 2.000 máy chủ

(Lưu ý: Đây là 13 địa chỉ IPv4, ngày nay chúng đi kèm với 13 địa chỉ IPv6 tương ứng)

DNS không tập trung quyền lực vào một thực thể duy nhất mà phân chia chặt chẽ qua ba tầng: định danh kỹ thuật, tổ chức quản lý và hạ tầng vật lý.

13 địa chỉ IP đại diện

Về mặt kỹ thuật, toàn bộ hệ thống Root DNS chỉ có 13 địa chỉ IP định danh, tương ứng với các tên miền từ a.root-servers.net đến m.root-servers.net. Con số 13 mang tính lịch sử: trong kỷ nguyên đầu Internet, các gói tin truy vấn cấu hình gốc bị giới hạn tối đa 512 bytes bởi giao thức UDP. Thực tế, sau khi trừ đi phần tiêu đề (header), không gian còn lại đủ để nhét vừa vặn 14 địa chỉ IP. Tuy nhiên, ngài Jon Postel và tổ chức IANA đã quyết định chỉ chọn con số 13, chủ động chừa lại một “chỗ trống” (spare room) làm vùng đệm dự phòng cho các phần mở rộng giao thức (extension) không lường trước sau này.

12 tổ chức quản lý độc lập

Để đảm bảo không một chính phủ hay tập đoàn nào có thể “tắt” Internet, ICANN (thông qua IANA) phân quyền vận hành 13 cụm IP này cho 12 cơ quan hoàn toàn độc lập:

Hơn 2.000 máy chủ vật lý nhờ Anycast

Mặc dù chỉ có 13 địa chỉ IP logic, quyền lực vật lý được nhân bản thành hơn 2.000 máy chủ vật lý đặt tại hơn 130 quốc gia — thông qua công nghệ IP Anycast.

Cơ chế hoạt động: mỗi tổ chức quản lý (ví dụ RIPE NCC với cụm K) đặt hàng trăm máy chủ vật lý rải khắp các châu lục, tất cả cùng dùng chung một địa chỉ IP. Khi bạn gửi truy vấn, các bộ định tuyến (Router) trên mạng Internet toàn cầu tự động dẫn gói tin đến máy chủ vật lý gần bạn nhất về mặt mạng lưới (Network Topology) thông qua giao thức định tuyến BGP. Anycast đo lường bằng số trạm trung chuyển (hop) chứ không phải vị trí địa lý. Thường thì khoảng cách mạng tỷ lệ thuận với địa lý, nhưng thỉnh thoảng một máy chủ ở Hong Kong có đường truyền peering trực tiếp (ít hop hơn) lại được ưu tiên hơn một máy chủ ở quốc gia lân cận.

Ý nghĩa của sự phân quyền

Nhờ cơ chế này, hệ thống DNS đạt được khả năng kháng lỗi tối đa. Nếu một cụm máy chủ bị tấn công DDoS và sập hoàn toàn, 12 cụm còn lại vẫn hoạt động bình thường. Nếu một trạm Anycast vật lý tại Châu Á bị hỏng, dòng dữ liệu tự động chuyển hướng sang trạm kế cận trong vài giây — mà người dùng không hề hay biết.

13. Bảo mật và quyền riêng tư: Gót chân Achilles của DNS

Kiến trúc DNS nguyên bản năm 1983 không có một dòng nào dành cho bảo mật hay quyền riêng tư. Khi Paul Mockapetris thiết kế DNS, mục tiêu duy nhất là cứu Internet khỏi sự sụp đổ của HOSTS.TXT. Mạng ARPANET lúc bấy giờ là một môi trường “thân thiện” — các nhà khoa học và kỹ sư tin tưởng nhau tuyệt đối, không ai nghĩ đến chuyện giả mạo hay nghe lén.

Sự ngây thơ thuở sơ khai đó đã để lại hai lỗ hổng chí mạng cấu thành nên những cuộc chiến bảo mật và quyền riêng tư kéo dài đến tận ngày nay:

1. Truy vấn dạng văn bản thuần túy (Plaintext): Mọi yêu cầu tra cứu tên miền được gửi đi dưới dạng văn bản không được mã hóa, giống như việc bạn hỏi đường bằng một tấm bưu thiếp không phong bì, khiến bất kỳ ai trên đường đi cũng có thể đọc lén nội dung.
2. Không có cơ chế xác thực nguồn gốc: Hệ thống không có cách nào để xác nhận rằng câu trả lời nhận được thực sự đến từ máy chủ có thẩm quyền (authoritative server) chứ không phải từ một kẻ mạo danh.

Bản chất “hớ hênh” của một truy vấn DNS truyền thống (lỗ hổng số 1) có thể được quan sát rõ ràng thông qua các công cụ bắt gói tin như Wireshark hoặc tcpdump. Nếu chúng ta giám sát lưu lượng mạng trên cổng 53 (cổng mặc định của DNS) và thực hiện truy vấn đến facebook.com:

1

$ sudo tcpdump -i eth0 -n -A port 53

Kết quả trả về trên terminal sẽ hiển thị toàn bộ nội dung gói tin:

1
2

18:05:22.123 IP 192.168.1.5.54321 > 8.8.8.8.53: 4567+ A? facebook.com. (30)
E..>..@.@....... ......1.5....^..........facebook.com.....

Ở cuối gói tin, tên miền facebook.com xuất hiện hoàn toàn dưới dạng văn bản thô (Plaintext). Điều này đồng nghĩa với việc nhà mạng (ISP), bộ định tuyến Wi-Fi tại quán cà phê, hay bất kỳ ai có khả năng can thiệp vào đường truyền mạng LAN đều có thể dễ dàng biết được bạn đang truy cập trang web nào.

14. Cuộc chiến bảo mật: Chống giả mạo bản ghi

DNS Cache Poisoning — Khi máy chủ nhà mạng bị đầu độc

Hãy tưởng tượng DNS như việc gửi một tờ giấy hỏi đường qua bưu điện, không phong bì, không niêm phong. Bất kỳ ai chạm tay vào tờ giấy đó đều có thể sửa nội dung trước khi nó đến đích.

Khi bạn gõ facebook.com, máy chủ DNS của nhà mạng (ISP) — nếu chưa có trong cache — phải đi hỏi các máy chủ cấp trên. DNS truyền thống dùng giao thức UDP và chỉ dùng một mã số ngẫu nhiên 16-bit gọi là Transaction ID để khớp câu hỏi với câu trả lời. Đây chính là lỗ hổng:

1. Kẻ tấn công rình rập máy chủ ISP đang đi hỏi đường.
2. Hacker lập tức bắn hàng ngàn gói tin giả, mỗi gói kèm một mã Transaction ID đoán mò khác nhau, cùng nội dung: “Facebook nằm ở IP 1.2.3.4 (máy chủ của tôi) đấy!”
3. Vì UDP là “ai đến trước thắng” — nếu một gói tin giả đến trước gói tin thật dù chỉ một phần triệu giây và mã Transaction ID trùng khớp, máy chủ ISP sẽ tin ngay.
4. ISP lưu IP giả này vào cache. Trong suốt vài tiếng sau đó, toàn bộ khách hàng của nhà mạng gõ facebook.com đều bị dẫn đến trang web giả mạo — mà trình duyệt không hề cảnh báo.

DNSSEC — “Căn cước công dân” kỹ thuật số cho bản ghi DNS

Giải pháp đến vào đầu những năm 2000 với DNSSEC (Domain Name System Security Extensions). Thay vì mã hóa nội dung, DNSSEC bổ sung chữ ký số mã hóa vào từng bản ghi DNS:

• Khi facebook.com đăng ký địa chỉ IP, họ dùng một khóa bí mật (Private Key) để ký lên bản ghi đó.
• Khi máy chủ ISP nhận câu trả lời, nó dùng khóa công khai (Public Key) — được xác thực ngược lên tận Root Server — để kiểm tra chữ ký.
• Nếu hacker gửi IP giả, chữ ký sẽ không khớp. Resolver có validation lập tức vứt bỏ gói tin và báo lỗi kết nối. Nói ngắn gọn, DNSSEC giúp chống giả mạo dữ liệu DNS, nhưng không phải áo giáp toàn năng bảo vệ người dùng khỏi mọi thủ đoạn chuyển hướng hay lừa đảo trên mạng.

Về mặt vận hành, việc triển khai DNSSEC ngày nay đã được các nhà cung cấp tự động hóa đáng kể. Quá trình thiết lập cơ bản thường bao gồm ba bước:

1. Khởi tạo khóa tại Authoritative Nameserver: Người quản trị bật tính năng DNSSEC trên giao diện quản lý DNS (như Cloudflare, AWS Route53). Hệ thống sẽ tự sinh cặp khóa (Public/Private Key) và dùng Private Key để ký điện tử lên toàn bộ các bản ghi DNS hiện có.
2. Cập nhật bản ghi DS (Delegation Signer): Giao diện quản lý DNS sẽ cung cấp một đoạn mã gọi là bản ghi DS. Quản trị viên cần khai báo đoạn mã này với Nhà đăng ký tên miền (Registrar - ví dụ Namecheap, GoDaddy).
3. Thiết lập chuỗi tin cậy: Nhà đăng ký sẽ đẩy bản ghi DS này lên TLD Server (ví dụ máy chủ quản lý đuôi .com). Hành động này tạo thành một mắt xích xác thực nguyên vẹn từ Root Server xuống TLD Server và cuối cùng là Authoritative Server của tên miền.

Để xác minh một tên miền đã được cấu hình DNSSEC hợp lệ, chúng ta có thể sử dụng công cụ dig kèm tham số +dnssec. Nếu hệ thống hoạt động đúng, kết quả trả về sẽ luôn đi kèm một bản ghi chữ ký điện tử RRSIG tương ứng với bản ghi truy vấn:

1
2
3
4

$ dig +dnssec google.com
...
google.com.  300  IN  A  142.250.191.14
google.com.  300  IN  RRSIG  A 8 2 300 2026...

Sự xuất hiện của bản ghi RRSIG khẳng định rằng phản hồi DNS này chưa bị giả mạo hay thay đổi trên đường truyền.

Giới hạn của DNSSEC: Nó đảm bảo dữ liệu bạn nhận được là chính xác, nhưng không hề mã hóa nội dung truy vấn. Nhà mạng hoặc kẻ nghe lén vẫn biết chính xác bạn đang tìm trang web nào. Đây là nơi cuộc chiến thứ hai bắt đầu.

15. Cuộc chiến quyền riêng tư: Chống nghe lén và kiểm duyệt

Dù có DNSSEC, mọi câu hỏi DNS của bạn — facebook.com, baomoi.com, hay bất kỳ tên miền nào — vẫn truyền đi như chữ thường trên đường phố. Nhà mạng (ISP), quản trị viên mạng Wi-Fi công cộng, hay chính phủ đều có thể đọc, ghi lại, thậm chí chặn truy cập dựa trên tên miền trong truy vấn của bạn.

Để lấy lại quyền riêng tư, kỷ nguyên DNS mã hóa bùng nổ với ba giao thức cốt lõi.

DNS over TLS (DoT — RFC 7858)

DoT đóng gói toàn bộ lưu lượng DNS vào một đường ống mã hóa TLS (cùng công nghệ bảo mật với HTTPS) và truyền qua cổng 853 — một cổng riêng biệt dành cho mục đích này.

Điểm mạnh của DoT là bảo mật cực tốt ở tầng hệ điều hành, được Android hỗ trợ mặc định qua tính năng Private DNS. Nhưng chính vì chạy trên một cổng riêng biệt, nó lộ diện quá rõ: quản trị viên mạng hoặc tường lửa doanh nghiệp/quốc gia có thể dễ dàng chặn cổng 853 để ép người dùng quay về DNS không mã hóa truyền thống.

DNS over HTTPS (DoH — RFC 8484)

DoH tinh vi hơn ở chỗ nó ngụy trang các truy vấn DNS vào bên trong lưu lượng web thông thường. Thay vì dùng cổng riêng, DoH giấu câu hỏi DNS vào các gói HTTP/2 hoặc HTTP/3 và đẩy qua cổng 443 — cổng tiêu chuẩn của mọi trang web HTTPS trên thế giới.

Hãy tưởng tượng bạn đang ở trong một công ty có quy định kiểm duyệt mạng nghiêm ngặt:

• Với DoT: Bạn bỏ câu hỏi vào hộp sắt bảo mật, gửi qua đường ống cổng 853. Người canh gác nhìn thấy ngay: “À, DNS bảo mật — tao không đọc được, nhưng tao chặn luôn cổng 853.” Mất kết nối.
• Với DoH: Bạn bỏ câu hỏi vào một chiếc hộp trông giống hệt mọi hộp dữ liệu web thông thường, gửi cùng dòng người tấp nập qua cổng 443. Về lý thuyết, người canh gác khó phân biệt đâu là DNS, đâu là web thông thường. Đã từng có “huyền thoại” cho rằng chặn DoH đồng nghĩa với làm sập toàn bộ Internet. Tuy nhiên trên thực tế, các “phù thủy” quản trị mạng doanh nghiệp (Sysadmin) vẫn rình rập và chặn DoH mỗi ngày bằng cách khóa cứng IP tĩnh của các máy chủ DoH công cộng nổi tiếng (như 1.1.1.1, 8.8.8.8), hoặc dùng Tường lửa kiểm tra gói tin sâu (DPI) để tóm gọn các yêu cầu /dns-query và cắt đứt ngay từ vòng gửi xe. Lúc này, trình duyệt sẽ đành “cụp đuôi” và quay về dùng DNS không mã hóa truyền thống do nội mạng cấp.

Các trình duyệt như Chrome và Firefox đã hỗ trợ DNS-over-HTTPS, nhưng không có nghĩa là nó luôn được dùng ở mọi nơi. Chrome có cơ chế Secure DNS tự động nâng cấp nếu nhà cung cấp hiện tại hỗ trợ, còn Firefox cũng bật DoH mặc định ở một số khu vực, nhưng trải nghiệm thực tế vẫn phụ thuộc vào quốc gia, chính sách mạng và cấu hình của từng người dùng.

Oblivious DNS over HTTPS (ODoH — RFC 9230)

Dù có DoH, vẫn còn một vấn đề: nhà cung cấp DNS công cộng như Cloudflare hay Google vẫn biết đồng thời địa chỉ IP của bạn và tên miền bạn tìm kiếm.

ODoH giải quyết bằng cách đưa vào một máy chủ trung gian (Proxy):

• Thiết bị của bạn mã hóa truy vấn rồi gửi đến Proxy.
• Proxy xóa sạch địa chỉ IP của bạn trước khi chuyển tiếp đến máy chủ DNS gốc.
• Kết quả: Proxy chỉ biết bạn là ai nhưng không biết bạn tìm gì. Máy chủ DNS chỉ biết bạn tìm gì nhưng không biết bạn là ai. Không thực thể nào nắm đủ cả hai mảnh thông tin.

16. Điểm mù cuối cùng: Khi DNS mã hóa vẫn chưa đủ

Bạn đã bật DoH, câu hỏi DNS được giấu kín. Máy tính tìm được IP của trang web muốn vào — giả sử 104.26.12.34. Nhưng một địa chỉ IP ngày nay (đặc biệt của các CDN lớn như Cloudflare) có thể phục vụ hàng triệu trang web khác nhau. Làm sao máy chủ biết bạn muốn vào trang nào?

Đây là lúc trình duyệt gửi một gói tin chào hỏi (Client Hello) để bắt đầu kết nối HTTPS. Và trong gói tin đó, bắt buộc phải có một trường gọi là SNI — Server Name Indication, ghi rõ bằng văn bản thô tên trang web cụ thể bạn muốn truy cập.

Nhà mạng không bắt được bạn ở bước DNS, nhưng bắt sống bạn ở bước SNI. Họ vẫn biết chính xác bạn đang vào trang web nào để chặn hoặc theo dõi — dù bạn đã bật mọi loại DNS mã hóa.

17. ECH — Mảnh ghép còn lại

ECH (Encrypted Client Hello) là công nghệ được thiết kế để lấp nốt lỗ hổng SNI. Năm 2026, IETF chính thức chuẩn hóa giao thức này qua RFC 9849, đánh dấu bước ngoặt xóa bỏ hoàn toàn điểm mù cuối cùng trong chuỗi bảo mật duyệt web.

Kỹ thuật “chia đôi” gói tin

Nỗ lực trước đó mang tên ESNI (Encrypted SNI) đã thất bại không chỉ vì rò rỉ một vài siêu dữ liệu, mà chí mạng nhất là bài toán phân phối khóa (Key Distribution). ESNI bắt thiết bị phải lấy được khóa công khai của máy chủ thông qua chính truy vấn DNS, khiến hệ thống mắc kẹt trong vòng lặp “con gà và quả trứng” (nếu DNS bị ngắt hay sửa thì ESNI tịt ngòi). Thêm vào đó, nó không xử lý tốt kịch bản một IP máy chủ chứa nhiều chứng chỉ SSL của các trang web khác nhau (Multi-CDN). ECH giải quyết triệt để vấn đề này bằng cách bọc một gói tin bên trong một gói tin khác nhằm tạo cơ chế thử lại êm ái (fallback) ngay cả khi khóa giải mã bị lệch:

• ClientHelloOuter (Vỏ ngoài — công khai): Chỉ chứa địa chỉ của một máy chủ trung gian chung — thường là CDN lớn như Cloudflare, Fastly hay Akamai. Bất kỳ ai nghe lén đều chỉ thấy bạn đang kết nối đến “Cloudflare”.
• ClientHelloInner (Lõi trong — mã hóa): Mới là phần chứa tên trang web thật sự bạn muốn vào. Toàn bộ lõi này được mã hóa bằng khóa công khai của máy chủ đích — chỉ máy chủ đó mới giải mã được.

Hành trình kết nối khi bật DoH + ECH

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

[Máy tính của bạn]
       │  (1) Hỏi qua DoH: "IP và khóa công khai ECH của bi-mat.com là gì?"
       ▼
[Máy chủ DNS mã hóa] ──► Trả về IP của Cloudflare + Khóa công khai ECH
       │
       │  (2) Máy tính dùng khóa này mã hóa "bi-mat.com" vào ClientHelloInner
       │  (3) Đặt lõi đó vào vỏ ClientHelloOuter ghi đích là "cloudflare.com"
       ▼
[Nhà mạng / ISP] ──► Chỉ đọc được "cloudflare.com" → Cho qua
       │
       ▼
[Hệ thống Cloudflare] ──► Dùng khóa bí mật giải mã → Kết nối đến bi-mat.com

Kết quả: Việc nhìn lén tên miền trở nên khó khăn hơn rất nhiều. Bước DNS bị mã hóa bởi DoH. Bước chào hỏi bị mã hóa bởi ECH. Dù vậy, người dùng không hoàn toàn “vô hình” — người quan sát mạng vẫn có thể thấy IP đích, thời điểm kết nối hay mẫu lưu lượng, và vẫn có thể dùng các biện pháp chặn thô bạo như chặn thẳng IP hoặc toàn bộ cụm hạ tầng.

Câu chuyện của ECH ở hiện tại

Tin vui là cuộc chiến quyền riêng tư đang dần nghiêng về phía người dùng. ECH đang được triển khai dần trong hệ sinh thái trình duyệt và hạ tầng CDN. Firefox đã bật ECH mặc định ở các phiên bản hiện đại; Chrome/Chromium cũng hỗ trợ và có chính sách cấu hình liên quan. Thậm chí, khi thư viện nền tảng OpenSSL 4.0 ra mắt, công nghệ này đã thâm nhập sâu vào cả hệ sinh thái máy chủ. Nếu một trang web dùng Cloudflare, khả năng cao là bạn đã được bảo vệ bởi ECH, dù mức độ hỗ trợ thực tế còn phụ thuộc vào sự đồng bộ giữa trình duyệt và máy chủ đích.

Mặt trái của tấm huy chương: Quyền riêng tư của bạn tăng lên, đồng nghĩa với việc bộ phận IT ở các công ty hay trường học… khóc ròng. Trước đây họ dùng tường lửa để “đọc” SNI xem nhân viên có đang lướt web cấm hay không. Nay với ECH, tường lửa bị “bịt mắt” hoàn toàn. Trò chơi mèo đuổi chuột lại tiếp diễn khi các quản trị viên mạng đành phải dùng những biện pháp mạnh tay hơn như ép cài chứng chỉ riêng (SSL Inspection) lên máy công ty để giải mã luồng dữ liệu, hoặc chặn đứng luôn mọi cổng liên quan đến DoH.

18. DNS Spoofing và DNS Hijacking: Hai khuôn mặt của cùng một mối đe dọa

Ngoài Cache Poisoning đã đề cập, còn hai dạng tấn công DNS phổ biến khác cần phân biệt rõ.

DNS Spoofing là hành vi lừa dối nhất thời — kẻ tấn công tiêm IP giả vào đường truyền hoặc bộ nhớ đệm mà không cần chạm vào cấu hình hệ thống. Ngoài Cache Poisoning, dạng phổ biến thứ hai là Man-in-the-Middle: kẻ tấn công dùng kỹ thuật ARP Spoofing để biến máy của hắn thành “trạm trung chuyển” bắt buộc cho toàn bộ lưu lượng mạng từ thiết bị của bạn. Khi đó, mọi câu hỏi DNS đều đi qua tay hắn trước — không cần đoán Transaction ID, chỉ cần chặn và ném lại IP giả.

DNS Hijacking thì khác về bản chất — đây là hành vi chiếm quyền kiểm soát cấu hình hệ thống một cách “hợp lệ” về mặt kỹ thuật:

• Router Hijacking: Kẻ tấn công khai thác lỗ hổng bảo mật của Router Wi-Fi nhà bạn (thường do mật khẩu quản trị vẫn để mặc định admin/admin) để đổi địa chỉ DNS sang máy chủ độc hại do chúng tự dựng. Từ đó, mọi thiết bị trong nhà — điện thoại, máy tính, tivi — đều bị kiểm soát.
• Rogue DNS Server: Các tổ chức tội phạm tự vận hành máy chủ DNS công cộng chứa đầy bản ghi giả, rồi dụ dỗ người dùng tự tay cấu hình sang dùng DNS của chúng với lý do “tăng tốc mạng” hay “vượt tường lửa”.
• Domain Hijacking: Nguy hiểm nhất. Kẻ tấn công không đụng đến người dùng mà hack thẳng vào tài khoản của chủ sở hữu tên miền tại nhà đăng ký (GoDaddy, Namecheap,…) rồi sửa bản ghi NS sang máy chủ của chúng. Lúc này toàn bộ hệ thống DNS toàn cầu — kể cả các Root Server — đều dẫn người dùng đến trang giả, vì thông tin bị sửa từ tận thượng nguồn.

19. UDP và TCP: Nghệ thuật cân bằng giữa tốc độ và độ tin cậy

Một trong những hiểu lầm phổ biến nhất về Hệ thống phân giải tên miền là: “DNS chỉ chạy trên giao thức UDP”.

Thực tế, DNS sử dụng cả hai giao thức UDP và TCP trên cùng một Cổng 53. Sự kết hợp này là một nghệ thuật cân bằng hoàn hảo giữa tốc độ (hiệu năng) và độ tin cậy (an toàn dữ liệu).

UDP — Ưu tiên tốc độ

Hơn 90% các truy vấn DNS thông thường hàng ngày đều chạy qua UDP (User Datagram Protocol). Lý do là bởi UDP là giao thức không hướng kết nối (Connectionless). Máy tính của bạn chỉ cần ném một gói tin câu hỏi duy nhất đến máy chủ DNS, và máy chủ ném trả lại một gói tin câu trả lời duy nhất. Không có bước bắt tay (Handshake), không có thiết lập đường truyền.

Khi Internet phục vụ hàng tỷ truy vấn DNS mỗi giây, tốc độ là yếu tố sống còn. Nếu mỗi lần tìm một trang web đều phải làm thủ tục kết nối rườm rà, hạ tầng toàn cầu sẽ nghẽn ngay lập tức.

Tuy nhiên, UDP nguyên bản có một giới hạn: theo tiêu chuẩn DNS gốc (RFC 1035), một gói tin DNS qua UDP tối đa chỉ 512 bytes. Nhiều người lầm tưởng đây là giới hạn vật lý của UDP (thực tế UDP chứa được tới 65KB). Con số 512 bytes là một sự lựa chọn an toàn (design choice). IPv4 quy định mọi mạng phải truyền được gói tin tối thiểu 576 bytes mà không bị băm vụn (IP Fragmentation). Lấy 576 trừ 20 bytes IP Header, trừ 8 bytes UDP Header, còn lại 548 bytes. Để an toàn tuyệt đối, các nhà thiết kế chốt làm tròn xuống 512 bytes. Nếu câu trả lời dài hơn, gói tin bị cắt cụt và bật cờ TC=1 (Truncated) — tín hiệu báo cho phía nhận biết phải chuyển sang TCP để lấy đủ dữ liệu.

TCP — Ưu tiên độ tin cậy

TCP (Transmission Control Protocol) là giao thức hướng kết nối. Nó yêu cầu quy trình bắt tay 3 bước (3-way handshake) phức tạp để đảm bảo dữ liệu truyền đi không bị mất mát hoặc sai lệch. DNS chuyển sang dùng TCP trong ba trường hợp chính:

Dữ liệu vượt quá 512 bytes — Khi câu trả lời chứa quá nhiều thông tin (danh sách dài địa chỉ IP dự phòng, khóa mã hóa của DNSSEC,…), gói UDP bị đánh dấu TC=1 Trình duyệt nhận được tín hiệu này sẽ hiểu: “Dữ liệu dài quá, hãy thiết lập kết nối TCP để tải toàn bộ phần còn lại về”. Việc này sẽ làm chậm quá trình phân giải tên miền đi một chút nhưng đảm bảo tính toàn vẹn của dữ liệu.

Zone Transfer — Máy chủ DNS không hoạt động độc lập. Máy chủ phụ (Slave DNS) phải định kỳ sao chép toàn bộ cơ sở dữ liệu tên miền từ máy chủ chính (Master DNS) qua một tiến trình gọi là Zone Transfer (dùng bản ghi AXFR hoặc IXFR). Vì tệp này rất lớn và không được phép sai một bit, TCP là lựa chọn bắt buộc.

DNS mã hóa (DoT, DoH) — Ban đầu, DoT và DoH chủ yếu chạy trên nền TLS và TCP, vốn yêu cầu đường truyền ổn định có xác thực và kiểm soát luồng. Tuy nhiên, DNS bảo mật hiện đại không còn giới hạn ở TCP: DoH có thể chạy qua HTTP/3 trên nền QUIC (dùng UDP), và IETF cũng đã ra mắt tiêu chuẩn riêng DNS-over-QUIC (RFC 9250). Do đó, TCP không còn là nền tảng duy nhất, mà cốt lõi nằm ở lớp bảo mật và giao thức vận chuyển cụ thể đang được dùng.

EDNS0 — Nỗ lực “nới rộng” giới hạn của UDP

Để giảm thiểu việc phải chuyển sang TCP (vốn chậm hơn và tốn tài nguyên hơn), năm 1999 tiêu chuẩn EDNS0 (Extension Mechanisms for DNS — RFC 2671/6891) ra đời. EDNS0 cho phép các thiết bị mạng hiện đại thông báo cho nhau: “Tôi có thể xử lý gói UDP lớn hơn — hãy gửi tối đa 4096 bytes đi, đừng giới hạn ở 512 bytes nữa.”

Nhờ EDNS0, phần lớn truy vấn DNSSEC dung lượng lớn ngày nay vẫn chạy mượt trên UDP mà không cần tốn tài nguyên chuyển đổi sang TCP. Nhưng như chúng ta sẽ thấy ngay dưới đây, chính khả năng mở rộng này của EDNS0 vô tình trở thành một đòn bẩy nguy hiểm trong tay kẻ tấn công.

20. DNS Amplification DDoS — Khi DNS bị biến thành vũ khí

DNS Amplification là một trong những kiểu tấn công từ chối dịch vụ nguy hiểm nhất trong lịch sử Internet. Kẻ tấn công không cần băng thông khổng lồ — chúng chỉ cần lợi dụng đúng hai đặc tính của UDP để biến một truy vấn 60 bytes thành trận bão dữ liệu hàng gigabit dội thẳng vào nạn nhân.

Hai đặc tính đó là: tính không kết nối (dễ giả mạo địa chỉ người gửi) và sự chênh lệch kích thước lớn giữa câu hỏi và câu trả lời.

Bước 1 — Giả mạo địa chỉ người gửi (IP Spoofing)

Với TCP, bạn không thể giả mạo địa chỉ IP — bởi vì bước bắt tay 3 chiều đòi hỏi phải nhận và gửi gói tin xác nhận từ chính địa chỉ đó. Nếu địa chỉ giả, kết nối bị hủy ngay.

UDP không có bước bắt tay nào cả. Hacker chỉ cần tạo một gói tin câu hỏi DNS, rồi điền vào phần “địa chỉ người gửi” không phải IP của mình mà là IP của nạn nhân — có thể là máy chủ của một ngân hàng hay trang thương mại điện tử. Máy chủ DNS nhận gói tin, không hề nghi ngờ gì, và lịch sự gửi câu trả lời về đúng địa chỉ nạn nhân đó.

Bước 2 — Khuếch đại kích thước câu trả lời

Nếu câu hỏi 60 bytes chỉ thu về câu trả lời 60 bytes, cuộc tấn công chẳng có ý nghĩa gì. Hacker cần một đòn bẩy dung lượng.

Trong quá khứ, phương thức phổ biến nhất là gửi truy vấn dạng ANY — yêu cầu máy chủ DNS trả về toàn bộ thông tin cấu hình của tên miền. Do bị lạm dụng quá nhiều, IETF đã ban hành RFC 8482, cho phép các máy chủ DNS từ chối cung cấp dữ liệu đầy đủ và chỉ trả về một thông báo tối thiểu (minimal response) đối với truy vấn ANY. Vì vậy, các cuộc tấn công hiện đại đã chuyển hướng sang khai thác DNSSEC: chúng truy vấn bản ghi TXT hoặc các bản ghi thông thường kèm theo cờ DO (DNSSEC OK). Máy chủ DNS buộc phải đính kèm các chữ ký số mật mã có kích thước rất lớn vào câu trả lời. Nhờ EDNS0 cho phép mở rộng giới hạn UDP lên 4096 bytes, một câu trả lời có thể phình to từ 60 bytes lên đến 3.000–4.000 bytes. Tỷ lệ khuếch đại đạt từ 50:1 đến gần 100:1 — chỉ cần gửi đi 1MB truy vấn bẩn, hacker có thể tạo ra gần 100MB dữ liệu rác dội thẳng vào nạn nhân.

Bước 3 — Mượn tay hàng ngàn máy chủ DNS công cộng

Để tạo ra băng thông tấn công hàng trăm Gbps hoặc Tbps, hacker mượn lực của các Open DNS Resolver — những máy chủ DNS công cộng được cấu hình lỏng lẻo, sẵn sàng trả lời bất kỳ ai gửi câu hỏi đến mà không lọc nguồn gốc.

1
2
3
4
5
6
7
8

[Mạng Botnet của Hacker] — Gửi lệnh ANY ~60 bytes, giả IP nạn nhân
               │
               ▼  (Sử dụng IP giả mạo của NẠN NHÂN)
[Hàng ngàn Open DNS Resolver trên toàn cầu] — Đóng vai gương phản chiếu
               │
               │  Phình to thành gói ~4.000 bytes × hàng triệu gói/giây
               ▼
[Máy chủ Nạn nhân] — Bị nghẽn sạch băng thông và SẬP HỆ THỐNG

Hacker ra lệnh cho mạng botnet đồng loạt gửi hàng triệu câu hỏi nhẹ đến hàng ngàn Open Resolver khắp thế giới, tất cả đều mang địa chỉ giả của nạn nhân. Hàng ngàn máy chủ đó lập tức phản hồi — nhưng câu trả lời được khuếch đại 100 lần lại dội thẳng vào nạn nhân. Đường truyền nghẽn hoàn toàn. Dịch vụ sập.

Điều khiến cuộc tấn công này đặc biệt khó đối phó là hacker hoàn toàn ẩn danh: nạn nhân chỉ nhìn thấy IP của các máy chủ DNS đang gửi dữ liệu đến, không bao giờ lần ra được dấu vết thật sự. Và các gói tin dội vào đều là phản hồi DNS hợp lệ về mặt kỹ thuật — rất khó để tường lửa phân biệt đâu là tấn công, đâu là lưu lượng sạch.

Để khắc chế loại hình này, thế giới phải áp dụng công nghệ BCP 38 (Ingress Filtering) để các nhà mạng chủ động chặn các gói tin giả mạo IP ngay từ nguồn, đồng thời các công ty lớn phải sử dụng các dịch vụ lá chắn giảm thiểu DDoS đám mây (như Cloudflare, Akamai) sở hữu các đường ống băng thông cực đại để “hấp thụ” và sàng lọc sạch các trận bão dữ liệu này trước khi nó chạm tới máy chủ gốc.

21. RRL — Khi máy chủ DNS tự “khóa miệng”

RRL (Response Rate Limiting) là tính năng bảo mật được tích hợp trực tiếp vào các phần mềm máy chủ DNS như BIND, NSD hay Knot DNS, cho phép máy chủ tự phát hiện khi nó đang bị lợi dụng làm công cụ tấn công và chủ động triệt tiêu sức mạnh của kẻ tấn công — mà không cần tắt dịch vụ hay ảnh hưởng đến người dùng thật.

Nói một cách dễ hiểu, RRL giống như một “bộ phanh tự động”. Khi máy chủ DNS phát hiện có ai đó đang mượn miệng mình để la hét dội bom người khác, nó sẽ lập tức “tự khóa miệng” hoặc “nói nhỏ lại” để triệt tiêu sức mạnh của kẻ tấn công.

Cách RRL nhận diện tấn công

RRL không chặn bừa bãi. Nó liên tục theo dõi các câu trả lời chuẩn bị gửi đi và gom chúng thành các nhóm dựa trên “vân tay” gồm ba yếu tố: địa chỉ IP đích, loại bản ghi được hỏi (ANY, TXT, NS,…) và tên miền được hỏi.

Nếu trong vòng một giây, máy chủ nhận thấy hàng ngàn câu hỏi cùng hỏi về một tên miền X, cùng loại bản ghi Y, và toàn bộ câu trả lời chuẩn bị đổ về cùng một địa chỉ IP Z — đó chắc chắn là dấu hiệu của IP Spoofing. RRL lập tức kích hoạt.

Ba biện pháp phản công

Giới hạn tỷ lệ phản hồi (Drop): Máy chủ đặt hạn mức — ví dụ tối đa 5 phản hồi/giây cho mỗi “vân tay” trùng khớp. Mọi gói tin vượt quá hạn mức bị vứt vào sọt rác mà không phản hồi. Đòn bẩy 100:1 lập tức sụp đổ: hacker gửi đi 1.000 câu hỏi, máy chủ chỉ trả lời 5, 995 câu còn lại biến mất.

Kỹ thuật “nói lửng” (Slip): Vứt bỏ hoàn toàn có một rủi ro: người dùng thật vô tình bị trùng vân tay mạng sẽ mất kết nối. RRL giải quyết bằng cơ chế Slip — cứ khoảng 2–3 gói tin bị chặn, máy chủ thả cho 1 gói đi qua, nhưng đã được “phẫu thuật”: toàn bộ dữ liệu phản hồi bị cắt sạch, chỉ còn lại một gói tin cực nhẹ kèm cờ TC=1.

Ép lộ diện qua TCP: Đây là nước cờ thông minh nhất. Khi gói tin TC=1 dội về địa chỉ IP của nạn nhân, hệ thống phân kỳ thành hai nhánh:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

[Hacker gửi 1.000 gói tin UDP giả IP nạn nhân]
                    │
                    ▼
          [Máy chủ DNS có RRL]
                    │
       ┌────────────┴────────────┐
       ▼ (950 gói vượt hạn mức)   ▼ (50 gói được thả - Cơ chế Slip)
  [Bị VỨT BỎ hoàn toàn]      [Cắt cụt dữ liệu + Bật bit TC=1]
                                 │
                                 ▼ dội về
                          [Địa chỉ IP Nạn nhân]
                                 │
            ┌────────────────────┴────────────────────┐
            ▼ (Nếu là Nạn nhân thật)                   ▼ (Nếu là Hacker giả mạo)
    Tự động chuyển sang TCP ──► Vào mạng OK      Không thể bắt tay TCP ──► Tấn công THẤT BẠI

• Nếu đó là nạn nhân thật: hệ thống của họ nhận TC=1, tự động chuyển sang TCP, thực hiện bắt tay 3 bước bằng IP thật và kết nối bình thường.
• Nếu đó là địa chỉ giả của hacker: không có ai thật sự ngồi ở đầu dây đó để nhận TC=1 và thực hiện bắt tay TCP. Cuộc tấn công tự vô hiệu hóa.

Trước khi có RRL, quản trị viên mạng chỉ có một lựa chọn duy nhất khi bị lợi dụng: tắt hoàn toàn tính năng phản hồi công cộng, chấp nhận ảnh hưởng đến cả người dùng tốt. RRL thay đổi cục diện — máy chủ DNS vừa giữ vững cổng phục vụ cộng đồng, vừa có khả năng tự vệ chủ động, phân biệt và triệt tiêu hành vi lạm dụng mà không tốn quá nhiều tài nguyên xử lý.

Lời kết: Trụ cột thầm lặng của Internet

Hơn 40 năm trôi qua, từ một tệp HOSTS.TXT sơ khai do vài người cập nhật bằng tay, DNS đã phình to thành một mạng lưới phân tán khổng lồ, gánh vác hàng tỷ thiết bị trên toàn cầu. Khởi đầu là một giải pháp tình thế để con người khỏi phải nhớ những con số IP vô hồn, DNS ngày nay đã trở thành một “chiến trường ngầm” thực sự — nơi diễn ra cuộc chạy đua vũ trang không hồi kết giữa một bên là bảo mật, quyền riêng tư (DNSSEC, DoH, ECH) và một bên là đánh cắp dữ liệu, kiểm duyệt hay tấn công mạng.

Dù kiến trúc bên dưới có chằng chịt và phức tạp đến mấy, việc bảo vệ bản thân trên không gian mạng đôi khi lại bắt đầu từ những bước rất nhỏ:

• Nếu bạn là một Webmaster hay Sysadmin: Hãy bỏ chút thời gian tìm hiểu và cấu hình DNSSEC cho tên miền của mình. Quan trọng không kém, hãy bật xác thực hai bước (2FA) cho tài khoản ở nhà đăng ký. Hạ tầng có xịn đến đâu mà mất tài khoản quản trị thì mọi nỗ lực cũng đổ sông đổ biển.
• Nếu bạn là người dùng Internet cá nhân: Hãy ưu tiên dùng các trình duyệt hiện đại và đảm bảo tính năng DNS bảo mật (DoH) đã được kích hoạt. Lịch sử duyệt web là tài sản riêng tư, đừng để nó dễ dàng bị thu thập.
• Và với chiếc Wi-Fi ở nhà: Xin đừng giữ lại cặp mật khẩu huyền thoại admin/admin trên cục Router. Đổi mật khẩu quản trị là cách đơn giản nhất để tránh viễn cảnh cả mạng nội bộ bị âm thầm chuyển hướng sang các máy chủ lừa đảo.

DNS có lẽ giống như không khí vậy: chẳng ai buồn để tâm khi nó hoạt động trơn tru, nhưng Internet sẽ lập tức “ngạt thở” nếu nó gặp sự cố. Hiểu về DNS không chỉ để xây dựng hệ thống cho chuẩn, mà còn để chúng ta biết cách “sinh tồn” an toàn hơn trong một kỷ nguyên số đầy rẫy cạm bẫy vô hình.

Cảm ơn bạn đã dành thời gian đọc đến những dòng cuối cùng của một bài viết khá dài và có hơi “nặng đô” về mặt kỹ thuật thế này. Mong rằng những dòng tản mạn vừa rồi đã mang đến cho bạn góc nhìn mới mẻ và thú vị hơn về một giao thức tưởng chừng như đã quá quen thuộc. Chúc bạn luôn có những trải nghiệm thú vị và an toàn trên Internet. Hẹn gặp lại bạn ở những bài viết tiếp theo tại Quorix Việt Nam. Và mình là Chooky!

Tài liệu tham khảo

1. Lịch sử và Kiến trúc nền tảng (IETF RFCs):

• RFC 226 (1971): Standardization of Host Mnemonics — Bước khởi thủy cho việc đặt tên máy tính (Host).
• RFC 882 & 883 (1983): Domain Names — Cột mốc lịch sử khi Paul Mockapetris khai sinh ra hệ thống DNS.
• RFC 1034 & 1035 (1987): Domain Names: Concepts, Facilities and Implementation — Tiêu chuẩn cốt lõi định hình DNS hiện đại (quy định giới hạn UDP 512 bytes và luật cấm CNAME ở tên miền gốc).
• RFC 2308 (1998): Negative Caching of DNS Queries — Tiêu chuẩn cho phép lưu bộ nhớ đệm các truy vấn lỗi (NXDOMAIN) thông qua thông số cuối cùng của bản ghi SOA.

2. Tiêu chuẩn Bản ghi & Vận hành:

• RFC 4408 (2006) & RFC 7208 (2014): Sender Policy Framework (SPF) — Lịch sử hình thành bản ghi Type 99 và quyết định khai tử để chuyển sang dùng bản ghi TXT làm tiêu chuẩn bắt buộc.
• RFC 8482 (2019): Providing Minimal-Sized Responses to DNS ANY Queries — Giấy phép từ chối cung cấp dữ liệu toàn phần cho truy vấn ANY để ngăn chặn thảm họa tấn công khuếch đại DDoS.

3. Tiêu chuẩn Bảo mật và Quyền riêng tư:

• DNSSEC: Domain Name System Security Extensions — Tập hợp các tiêu chuẩn bảo mật nhằm ký điện tử lên các bản ghi DNS.
• RFC 7858 (2016): Specification for DNS over Transport Layer Security (DoT).
• RFC 8484 (2018): DNS Queries over HTTPS (DoH).
• RFC 9230 (2022): Oblivious DNS over HTTPS (ODoH).
• RFC 9250 (2022): DNS over Dedicated QUIC Connections — Hiện thực hóa việc gửi truy vấn DNS bảo mật qua nền tảng QUIC/UDP.
• RFC 9849 (2026): TLS Encrypted Client Hello (ECH) — Giải pháp vá lỗ hổng rò rỉ SNI (Server Name Indication) để ẩn danh hóa hoàn toàn chuỗi bắt tay TLS.

4. Khảo cứu Tổ chức và Hạ tầng:

• IANA (Internet Assigned Numbers Authority): Cơ sở dữ liệu và danh sách 13 định danh máy chủ gốc (Root Servers).
• Root-Servers.org: Hệ thống thông tin, lưu lượng và bản đồ phân bố của hơn 2.000 trạm vật lý Anycast đang vận hành mạng lưới Root DNS toàn cầu.