DNS (Domain Name System) và bảo mật DNS

1. Tổng quan

Định nghĩa: DNS (Domain Name System — hệ thống tên miền) là hệ thống phân giải tên (name resolution) toàn cầu có tính phân cấp và phân tán (hierarchical & distributed), chuyển đổi qua lại giữa tên miền dễ nhớ đối với con người (ví dụ: www.example.com) và địa chỉ IP mà máy tính dùng để truyền thông (ví dụ: 93.184.216.34).

Thời kỳ đầu của Internet, tên và địa chỉ của mọi máy chủ được chứa trong một tệp văn bản duy nhất (HOSTS.TXT) và phân phối tập trung. Tuy nhiên, khi số lượng máy kết nối bùng nổ, cách dùng một tệp duy nhất này bộc lộ ba giới hạn: chậm phân phối, xung đột tên, và nút thắt cập nhật. Tức là tệp tĩnh tập trung không thể đáp ứng khả năng mở rộng (scalability) của Internet, và để giải quyết điều đó, năm 1983 Paul Mockapetris đã thiết kế DNS kết hợp ý tưởng không gian tên phân cấp với cơ sở dữ liệu phân tán (RFC 882/883, sau đó được chuẩn hóa thành RFC 1034/1035). Giá trị bản chất của DNS nằm ở chỗ “phân cấp không gian tên thành cấu trúc cây và ủy quyền (delegation) quyền quản lý từng vùng (zone) cho các chủ thể độc lập, nhờ đó bất kỳ tổ chức nào trên thế giới cũng có thể quản lý tên của mình mà không cần phê duyệt của trung tâm”.

Nếu không có DNS, mọi giao tiếp web, thư điện tử, API đều phải chỉ định trực tiếp địa chỉ IP, và mỗi lần di chuyển máy chủ hay phân tải đều phải sửa từng client trên toàn thế giới. Ngược lại, nhờ có DNS, có thể tách rời (decoupling) dịch vụ khỏi vị trí vật lý thông qua 'tầng gián tiếp (indirection layer)' là tên miền, và đây trở thành nền tảng của hạ tầng Internet hiện đại như CDN, GSLB (cân bằng tải toàn cầu), định tuyến thư điện tử, phát hiện dịch vụ (service discovery). Tuy nhiên, khi thiết kế, DNS đặt 'tính sẵn sàng và khả năng mở rộng' lên hàng đầu mà không tính đến 'xác thực và tính bảo mật', nên ngày nay nó mang các điểm yếu mang tính cấu trúc như đầu độc bộ nhớ đệm, DDoS khuếch đại, lộ quyền riêng tư, và phải được xem xét cùng với DNSSEC, DoH/DoT để bổ sung.

Tóm tắt các đặc điểm: ① không gian tên phân cấp dạng cây, ② vận hành phân tán thông qua ủy quyền quyền quản lý, ③ bảo đảm hiệu năng · khả năng mở rộng nhờ bộ nhớ đệm dựa trên TTL, ④ truy vấn gọn nhẹ chủ yếu qua UDP/53, ⑤ hướng tới tính nhất quán cuối cùng (eventual consistency).

DNS thường được ví như 'danh bạ điện thoại của Internet', nhưng phép so sánh này đánh giá thấp quy mô và cách vận hành. Nếu danh bạ điện thoại là một danh sách tĩnh, thì DNS là hệ thống động xử lý phân tán theo thời gian thực hàng triệu truy vấn mỗi giây trở lên cho hàng trăm triệu tên miền trên toàn thế giới, và vì không tổ chức nào sở hữu toàn bộ, đây là hạ tầng hiện thực tốt nhất triết lý 'hợp tác phân tán' của Internet. Vì thế, DNS là 'cửa ngõ đầu tiên của mọi giao tiếp', hoạt động trước cả web (HTTP), và khi DNS ngừng hoạt động thì trên thực tế gần như mọi dịch vụ đều không truy cập được, ngoại trừ số rất ít người biết trực tiếp IP. Chính vì 'sự phụ thuộc phổ quát' này mà hiệu năng, tính sẵn sàng, bảo mật của DNS không được coi là vấn đề của từng dịch vụ riêng lẻ mà là vấn đề độ tin cậy của toàn bộ Internet.

2. Không gian tên DNS và cấu trúc tổng thể

Không gian tên DNS là cấu trúc cây ngược (inverted tree) với đỉnh là gốc (root, .), bên dưới là TLD (Top-Level Domain), tên miền cấp hai, tên miền con. Mỗi nút có một nhãn (label) tối đa 63 byte, và toàn bộ FQDN (Fully Qualified Domain Name) không được vượt quá 255 byte. Cấu trúc phân cấp này quan trọng vì nó cho phép chỉ cần bảo đảm 'tính duy nhất (uniqueness)' của tên ở phạm vi cục bộ. Tức là người quản lý vùng example.com chỉ cần ngăn xung đột tên trong vùng của mình, không cần điều phối với toàn thế giới.

Ủy quyền được thực hiện theo đơn vị 'vùng (zone)'. Vùng là phần liên tục của không gian tên do một chủ thể quản lý chịu trách nhiệm, và vùng cấp trên ủy quyền bằng cách dùng bản ghi NS trỏ tới máy chủ tên có thẩm quyền (authoritative name server) của vùng cấp dưới. Ví dụ, gốc ủy quyền TLD .com, và TLD .com ủy quyền máy chủ tên của example.com. Nhờ chuỗi ủy quyền này, có thể phân giải toàn cục mà không máy chủ nào nắm giữ toàn bộ dữ liệu.

graph TD
    ROOT["Gốc (.) 13 máy chủ gốc logic"] --> COM["Máy chủ tên TLD .com"]
    ROOT --> KR["Máy chủ tên TLD .kr"]
    ROOT --> ORG["Máy chủ tên TLD .org"]
    COM --> EX["Máy chủ tên có thẩm quyền example.com"]
    KR --> COKR["Máy chủ tên có thẩm quyền co.kr"]
    EX --> WWW["Bản ghi A/AAAA www.example.com"]
    EX --> MAIL["Bản ghi MX mail.example.com"]
    CLIENT["Client (Stub Resolver)"] -.truy vấn.-> RESOLVER["Bộ phân giải đệ quy (Recursive Resolver, bộ nhớ đệm)"]
    RESOLVER -.truy vấn lặp.-> ROOT
    RESOLVER -.truy vấn lặp.-> COM
    RESOLVER -.truy vấn lặp.-> EX

Có bốn chủ thể cốt lõi cấu thành hạ tầng DNS. Thứ nhất, stub resolver là client chức năng tối thiểu được tích hợp trong hệ điều hành hoặc trình duyệt, ủy thác truy vấn cho bộ phân giải đệ quy. Thứ hai, bộ phân giải đệ quy (recursive resolver, caching resolver) thay mặt client lần lượt ghé thăm gốc→TLD→máy chủ có thẩm quyền để tìm và trả về câu trả lời cuối cùng, rồi lưu kết quả vào bộ nhớ đệm trong thời gian TTL. Tiêu biểu là bộ phân giải của ISP hay Google 8.8.8.8, Cloudflare 1.1.1.1. Thứ ba, máy chủ tên có thẩm quyền (authoritative server) là nguồn gốc cuối cùng nắm giữ dữ liệu gốc của một vùng cụ thể. Thứ tư, máy chủ gốc được vận hành với 13 địa chỉ logic (A~M), nhưng thực tế được nhân bản thành hàng nghìn phiên bản vật lý trên toàn thế giới bằng công nghệ Anycast để bảo đảm tính sẵn sàng và tốc độ phản hồi.

Trong cấu trúc này, cơ chế hiệu năng cốt lõi là bộ nhớ đệm (caching). Mỗi bản ghi được gán một TTL (Time To Live), và bộ phân giải đệ quy không truy vấn lại máy chủ cấp trên cho đến khi TTL hết hạn. TTL ngắn thì thay đổi được phản ánh nhanh nhưng tải lên gốc · TLD tăng; TTL dài thì giảm tải nhưng khi đổi IP, việc phản ánh trên toàn thế giới bị chậm. Vì vậy, khi lên kế hoạch di chuyển máy chủ, thông lệ thực tế là hạ TTL trước xuống khoảng 300 giây. Chính bộ nhớ đệm này làm cho DNS trở thành hệ thống 'nhất quán cuối cùng', đồng thời cũng là điểm trở thành mục tiêu của tấn công đầu độc bộ nhớ đệm (cache poisoning).

3. Nguyên lý hoạt động của DNS — truy vấn đệ quy và truy vấn lặp

Phân giải DNS được thực hiện bằng sự kết hợp của hai cách truy vấn có bản chất khác nhau. Giữa client và bộ phân giải đệ quy dùng truy vấn đệ quy (recursive query). Client yêu cầu “hãy cho tôi câu trả lời hoàn chỉnh”, và bộ phân giải chịu trách nhiệm tìm câu trả lời. Ngược lại, giữa bộ phân giải và các máy chủ ở từng cấp dùng truy vấn lặp (iterative query). Nếu không biết câu trả lời, mỗi máy chủ chỉ trả về tham chiếu (referral) tới máy chủ cấp dưới với ý “hãy hỏi tiếp bên dưới”. Sự phân vai này quan trọng vì nó tập trung công việc tìm kiếm nặng nề tại một bộ phân giải và tái sử dụng kết quả qua bộ nhớ đệm, nhờ đó giảm đáng kể tổng lượng truy vấn của toàn bộ Internet.

sequenceDiagram
    participant C as Client Stub
    participant R as Bộ phân giải đệ quy
    participant Root as Máy chủ gốc
    participant TLD as Máy chủ TLD .com
    participant Auth as Máy chủ có thẩm quyền example.com
    C->>R: www.example.com A? (truy vấn đệ quy)
    R->>Root: www.example.com A? (truy vấn lặp)
    Root-->>R: ".com thì hãy hỏi máy chủ TLD" (tham chiếu NS)
    R->>TLD: www.example.com A? (truy vấn lặp)
    TLD-->>R: "example.com thì hãy hỏi máy chủ có thẩm quyền" (tham chiếu NS)
    R->>Auth: www.example.com A? (truy vấn lặp)
    Auth-->>R: 93.184.216.34 (phản hồi có thẩm quyền, kèm TTL)
    R-->>C: 93.184.216.34 (phản hồi cuối cùng + lưu đệm)

Xét luồng cụ thể, khi người dùng yêu cầu www.example.com, stub resolver gửi truy vấn đệ quy tới bộ phân giải đệ quy. Nếu không có câu trả lời trong bộ nhớ đệm, bộ phân giải trước tiên hỏi máy chủ gốc, và gốc trả về tham chiếu NS của máy chủ TLD .com. Bộ phân giải lại hỏi máy chủ TLD để nhận tham chiếu tới máy chủ có thẩm quyền của example.com, cuối cùng nhận bản ghi A thực tế (93.184.216.34) từ máy chủ có thẩm quyền, chuyển cho client và lưu đệm trong thời gian TTL. Truy vấn đầu tiên phải qua nhiều vòng đi-về (round-trip) như vậy, nhưng các truy vấn giống hoặc tương tự sau đó được xử lý ngay từ bộ nhớ đệm và trả lời trong vài mili giây. Trong thực tế, tỷ lệ trúng bộ nhớ đệm thường từ 80~90% trở lên, nghĩa là phần lớn truy vấn DNS kết thúc tại bộ nhớ đệm của bộ phân giải mà không đi tới máy chủ cấp trên.

Về tầng giao vận, DNS mặc định sử dụng cổng UDP 53. Vì phân giải tên là thao tác đơn lẻ, dung lượng nhỏ, nên UDP không có chi phí thiết lập kết nối là có lợi. Tuy nhiên, khi phản hồi vượt quá 512 byte (giới hạn UDP truyền thống) hoặc khi cần độ tin cậy như chuyển vùng (zone transfer, AXFR/IXFR), DNS chuyển sang (fallback) cổng TCP 53. Trong môi trường hiện đại có phản hồi lớn như dữ liệu ký DNSSEC, thông lệ chuẩn là dùng EDNS0 (RFC 6891) để mở rộng payload UDP lên tới 4096 byte nhằm giảm việc thử lại bằng TCP.

Tính sẵn sàng của máy chủ có thẩm quyền được bảo đảm bằng dự phòng sơ cấp/thứ cấp (primary/secondary, master/slave). Máy chủ sơ cấp nắm giữ dữ liệu vùng gốc, còn máy chủ thứ cấp sao chép nó bằng chuyển vùng (zone transfer). Khi đó, thay vì AXFR sao chép toàn bộ mỗi lần, dùng IXFR (Incremental Zone Transfer) chỉ truyền phần thay đổi sẽ tiết kiệm băng thông, và việc cập nhật được xác định bằng cách phát hiện sự tăng số sê-ri (serial number) của bản ghi SOA. Vì chuyển vùng có thể làm lộ cấu trúc mạng nội bộ, nguyên tắc bảo mật là phải giới hạn chỉ cho các máy chủ thứ cấp được cấp phép và xác thực bằng TSIG (Transaction Signature). Nhờ cấu trúc dự phòng này, ngay cả khi máy chủ sơ cấp gặp sự cố, nhiều máy chủ có thẩm quyền vẫn tiếp tục trả lời, duy trì tính sẵn sàng cao của DNS.

Một yếu tố dễ bị bỏ qua trong tối ưu hiệu năng là bộ nhớ đệm phủ định (negative caching, RFC 2308). Phản hồi cho tên không tồn tại (NXDOMAIN) cũng phải được lưu đệm thì mới ngăn được các truy vấn vô hiệu lặp lại đổ về máy chủ cấp trên, và thời gian lưu đệm khi đó được xác định bằng giá trị TTL tối thiểu của bản ghi SOA của vùng đó. Nếu không có bộ nhớ đệm phủ định, các truy vấn tên miền con không tồn tại do gõ nhầm hay do bot sẽ đi thẳng tới máy chủ có thẩm quyền làm tăng tải, và thực tế tấn công dồn dập NXDOMAIN (flood) bị lạm dụng như một kỹ thuật DDoS. Thiết kế coi ngay cả câu trả lời 'không có' là đối tượng lưu đệm như vậy chính là điều nâng đỡ khả năng mở rộng của DNS.

4. Các loại bản ghi tài nguyên (Resource Record) chính

Đơn vị cơ bản của dữ liệu DNS là bản ghi tài nguyên (RR), và mỗi bản ghi gồm tên / TTL / lớp (IN) / loại / giá trị. Hiểu các loại bản ghi không phải là việc học thuộc đơn thuần mà là nắm bắt “mỗi loại tồn tại để đáp ứng yêu cầu dịch vụ nào”. Ví dụ, A/AAAA đảm nhận điểm đến của truy cập web, MX đảm nhận định tuyến thư, SRV đảm nhận phát hiện dịch vụ, CAA đảm nhận kiểm soát cấp phát chứng chỉ. Bảng dưới đây là phần tóm tắt bổ trợ; trong bài làm thực tế nên trình bày kèm ngữ cảnh xuất hiện của từng bản ghi.

Loại	Vai trò	Ví dụ/ghi chú
A	Tên miền → địa chỉ IPv4	`www.example.com → 93.184.216.34`
AAAA	Tên miền → địa chỉ IPv6	Bắt buộc khi chuyển đổi IPv6
CNAME	Bí danh (ủy quyền cho tên chính tắc)	Bị hạn chế dùng ở tên miền gốc
MX	Chỉ định máy chủ thư (kèm độ ưu tiên)	Giá trị ưu tiên thấp được ưu tiên
NS	Ủy quyền máy chủ tên có thẩm quyền của vùng	Cốt lõi của chuỗi ủy quyền
SOA	Thông tin khởi đầu · quản lý vùng (số sê-ri · chu kỳ cập nhật)	Mỗi vùng 1 bản ghi
PTR	IP → tên miền (tra cứu ngược)	`in-addr.arpa`
TXT	Văn bản tùy ý (SPF · DKIM · xác minh)	Dùng rộng rãi cho xác thực thư
SRV	Vị trí dịch vụ (máy chủ · cổng)	SIP · LDAP v.v.
CAA	Giới hạn CA được phép cấp chứng chỉ	Ngăn cấp phát sai
DNSKEY/RRSIG/DS/NSEC	Ký · xác minh · chứng minh không tồn tại của DNSSEC	Xem phần chuyên sâu ở mục 4

Bản ghi PTR đảm nhận tra cứu ngược (reverse lookup) cũng có ý nghĩa thực tiễn lớn. Nếu chiều thuận là tên→IP thì PTR phân giải IP→tên, được biểu diễn bằng cách sắp xếp IP theo thứ tự ngược dưới các tên miền đặc biệt in-addr.arpa (IPv4) · ip6.arpa (IPv6). Ứng dụng tiêu biểu của PTR là lọc thư rác trên máy chủ thư: máy chủ nhận thư kiểm tra xem kết quả tra cứu ngược của IP gửi có khớp với chiều thuận không (forward-confirmed reverse DNS) để loại bỏ người gửi giả mạo. Do đó, khi tự vận hành máy chủ thư, việc không cấu hình PTR có thể dẫn đến thư hợp lệ bị xử lý như thư rác — đây là ví dụ cụ thể về việc một bản ghi DNS gắn trực tiếp với độ tin cậy của dịch vụ.

Sự khác biệt giữa CNAME và bản ghi A là điểm thường bị nhầm lẫn trong thực tế. A ánh xạ trực tiếp tên tới IP, còn CNAME ủy quyền tên sang một 'tên chính tắc (canonical name)' khác. Chuỗi CNAME linh hoạt nhưng gây thêm tra cứu làm tăng độ trễ, và không thể dùng ở tên miền gốc (zone apex) do ràng buộc RFC rằng CNAME không thể cùng tồn tại với SOA · NS. Để vượt qua điều này, các nhà cung cấp CDN cung cấp các bản ghi mở rộng của nhà cung cấp như ALIAS/ANAME. Một ví dụ thực tiễn khác, SPF · DKIM · DMARC để chống giả mạo email đều đưa chính sách vào bản ghi TXT để phân phối, đây là ví dụ tiêu biểu cho thấy DNS được dùng như 'kênh phân phối chính sách tin cậy' vượt ra ngoài việc chuyển đổi địa chỉ đơn thuần.

5. Các mối đe dọa bảo mật DNS và so sánh

DNS là giao thức dựa trên UDP được thiết kế mà không có cơ chế toàn vẹn · xác thực, nên phải đối mặt với nhiều mối đe dọa. Không nên chỉ liệt kê các mối đe dọa mà phải hiểu cả nguyên nhân mang tính cấu trúc 'vì sao cuộc tấn công đó thành công'.

Đầu độc bộ nhớ đệm (Cache Poisoning) là tấn công trong đó kẻ tấn công chèn trước một phản hồi giả mạo vào bộ phân giải đệ quy, khiến bộ phân giải lưu đệm IP sai. UDP xác minh nguồn gửi yếu, và tính xác thực của phản hồi chỉ được đối chiếu bằng ID truy vấn (16 bit) và cổng nguồn, nên có thể đoán vét cạn. Kỹ thuật do Dan Kaminsky công bố năm 2008 đã dùng tên miền con để lặp lại vô hạn cơ hội đoán, chứng minh mức độ nghiêm trọng của lỗ hổng này, và để đối phó, việc ngẫu nhiên hóa cổng nguồn (source port randomization) và cuối cùng là áp dụng DNSSEC đã được thúc đẩy. DDoS khuếch đại · phản xạ DNS (Amplification/Reflection) là tấn công kết hợp đặc tính DNS dùng truy vấn nhỏ để tạo phản hồi lớn (hệ số khuếch đại hàng chục lần) với khả năng giả mạo nguồn gửi của UDP, dội một lượng lớn phản hồi vào IP nạn nhân. Sự cố Dyn DNS do botnet Mirai gây ra năm 2016 là ví dụ tiêu biểu cho thấy khi bản thân hạ tầng DNS trở thành mục tiêu tấn công, vô số dịch vụ như Twitter, Netflix có thể đồng loạt tê liệt. Ngoài ra còn có DNS tunneling (kênh rò rỉ dữ liệu · C2 giấu dữ liệu trong truy vấn DNS để vượt qua thiết bị bảo mật), chiếm đoạt tên miền con (subdomain takeover), chiếm đoạt tên miền (domain hijacking) (chiếm tài khoản tại nhà đăng ký) v.v.

Mối đe dọa	Nguyên nhân gốc	Biện pháp đối phó chính
Đầu độc bộ nhớ đệm	Không có xác minh tính xác thực của phản hồi (ID 16 bit)	DNSSEC, ngẫu nhiên hóa cổng, mã hóa 0x20
DDoS khuếch đại	Giả mạo nguồn UDP + phản hồi lớn	RRL (giới hạn tốc độ phản hồi), Anycast, BCP38
DNS tunneling	Giám sát payload truy vấn chưa đầy đủ	Phân tích lưu lượng · phát hiện bất thường, kiểm tra payload
Chiếm đoạt tên miền con	Ủy quyền CNAME bị bỏ quên	Dọn dẹp bản ghi không dùng, xác minh quyền sở hữu
Chiếm đoạt tên miền	Tài khoản nhà đăng ký yếu	Registry lock, MFA, DNSSEC

Thêm vào đó, DNS còn bị lạm dụng để che giấu hạ tầng tấn công. DGA (Domain Generation Algorithm), trong đó mã độc mỗi ngày sinh ra một lượng lớn tên miền ngẫu nhiên và chỉ đăng ký một phần trong số đó làm máy chủ C2, vô hiệu hóa việc chặn bằng danh sách đen đơn thuần; còn typosquatting · tấn công đồng hình IDN (IDN homograph), đăng ký tên miền trông giống về mặt thị giác để lừa người dùng, là thủ đoạn quen thuộc của lừa đảo (phishing). Vì các mối đe dọa này khó đối phó chỉ bằng chặn tĩnh, cần kết hợp các kỹ thuật phát hiện động như phân tích entropy của mẫu truy vấn, đánh giá uy tín tên miền dựa trên học máy. Trên thực tế, các nhà cung cấp bảo mật lớn phân tích hàng trăm tỷ bản ghi log truy vấn DNS mỗi ngày để sớm nhận diện tên miền độc hại mới.

Các biện pháp đối phó hoạt động ở các tầng khác nhau nên phải được hiểu cùng nhau. Ví dụ, DNSSEC cung cấp 'toàn vẹn · xác thực' nhưng không cung cấp 'tính bảo mật', nên vấn đề quyền riêng tư được DoH/DoT giải quyết riêng. Ngược lại, DoH/DoT ngăn nghe lén · thao túng bằng cách mã hóa đoạn truyền, nhưng không bảo đảm được dữ liệu mà bộ phân giải trả về là 'câu trả lời thật của máy chủ có thẩm quyền', nên bổ trợ lẫn nhau với DNSSEC. Việc không có cơ chế nào che phủ được mọi mối đe dọa như vậy là hàm ý cốt lõi của bảo mật DNS.

6. Chuyên sâu — Xu hướng mới nhất của DNSSEC và DNS mã hóa (DoH/DoT)

DNSSEC (DNS Security Extensions, RFC 4033~4035) gán chữ ký số (RRSIG) cho mỗi tập bản ghi (RRset), và kiểm tra phản hồi có bị giả mạo · sửa đổi hay không thông qua 'chuỗi tin cậy (chain of trust)' liên kết tính xác thực của khóa xác minh (DNSKEY) với bản ghi DS của vùng cấp trên. Đỉnh của sự tin cậy là khóa công khai của vùng gốc, và KSK rollover (Key Signing Key Rollover) — thay khóa định kỳ — được thực hiện lần đầu năm 2018, là sự kiện lịch sử khi các bộ phân giải trên toàn thế giới đồng loạt chuyển sang tin cậy khóa gốc mới. Để ngăn phản hồi giả mạo cho tên không tồn tại, DNSSEC cung cấp 'chứng minh không tồn tại (authenticated denial of existence)' bằng NSEC/NSEC3, trong đó NSEC3 dùng hàm băm để khắc phục vấn đề NSEC làm lộ nguyên tên và bị lạm dụng cho duyệt vùng (zone walking).

graph TD
    RootKSK["KSK vùng gốc (neo tin cậy)"] --> RootDS["DS của .com do gốc ký"]
    RootDS --> ComKey["DNSKEY của .com"]
    ComKey --> ComDS["DS của example.com do .com ký"]
    ComDS --> ExKey["DNSKEY của example.com"]
    ExKey --> RRSIG["Xác minh chữ ký bản ghi A (RRSIG)"]
    RRSIG --> VALID["Hoàn tất xác thực toàn vẹn · nguồn gốc"]

Trong môi trường cloud native, vai trò của DNS thậm chí còn đang được mở rộng. Kubernetes dùng CoreDNS làm DNS nội bộ cụm, gán cho pod · service các tên dạng service.namespace.svc.cluster.local, qua đó hiện thực phát hiện dịch vụ (service discovery) giữa các microservice. Tức là dù IP của dịch vụ liên tục thay đổi do co giãn (scale in/out), tên vẫn cố định, nên phía gọi có thể giao tiếp mà không cần để ý đến thay đổi IP. Ngoài ra, DNS chia tầm nhìn (split-horizon) trả về phản hồi khác nhau cho mạng nội bộ doanh nghiệp và bên ngoài là kỹ thuật thực tiễn, trong đó cùng một tên miền nhưng người dùng nội bộ nhận IP riêng còn người dùng bên ngoài nhận IP công cộng, nhằm giảm việc lộ tài sản nội bộ. Như vậy, DNS đang tiến hóa vượt ra ngoài phân giải tên Internet truyền thống để trở thành điểm kiểm soát cốt lõi của môi trường container và zero trust.

Mặt khác, DNS mã hóa ra đời nhắm vào 'quyền riêng tư' mà DNSSEC không xử lý. DoT (DNS over TLS, RFC 7858) mã hóa truy vấn bằng TLS trên cổng 853, còn DoH (DNS over HTTPS, RFC 8484) đưa DNS vào lưu lượng HTTPS trên cổng 443 khiến nó không phân biệt được với lưu lượng web thông thường. Cloudflare, Google, Mozilla vận hành các bộ phân giải DoH công cộng và đã mở rộng việc áp dụng mặc định trên trình duyệt. Tuy nhiên, DoH vừa tăng cường quyền riêng tư vừa khiến thiết bị bảo mật của doanh nghiệp khó giám sát · chặn DNS, dẫn tới đánh đổi (trade-off) là 'giảm khả năng quan sát mạng'. Vì thế, nhiều doanh nghiệp song song áp dụng chính sách bắt buộc dùng bộ phân giải nội bộ và phát hiện DoH. Xu hướng gần đây nhất đang được thảo luận gồm ECH (Encrypted Client Hello) che giấu cả SNI (Server Name Indication), và các công nghệ tăng cường quyền riêng tư như 'Oblivious DoH' khiến ngay cả bộ phân giải cũng không thể đồng thời biết người truy vấn và nội dung truy vấn. Tình hình triển khai chính xác thay đổi theo từng tiêu chuẩn · hiện thực, nên khi áp dụng nên kiểm tra RFC mới nhất và tài liệu của nhà cung cấp.

7. Những điểm cần cân nhắc và hàm ý (dưới góc nhìn Kỹ sư chuyên nghiệp)

Thứ nhất, thiết kế cân bằng giữa tính sẵn sàng, bảo mật và quyền riêng tư. DNS dễ trở thành điểm lỗi đơn (SPOF) của Internet, vì vậy bắt buộc phải phân tán địa lý các máy chủ có thẩm quyền, dùng song song nhiều nhà cung cấp DNS (multi-provider) và áp dụng Anycast. Trên cơ sở đó, kết hợp theo tầng DNSSEC (toàn vẹn) và DoH/DoT (bảo mật), nhưng phải điều phối trước sự đánh đổi giữa việc giảm khả năng quan sát mạng do DoH gây ra với chính sách bảo mật doanh nghiệp.

Thứ hai, chiến lược vận hành dựa trên TTL và đa dự phòng. Để chuẩn bị cho tình huống di chuyển dịch vụ · chuyển đổi dự phòng (failover), quản lý chính sách TTL thời bình một cách có kế hoạch, và dùng cân bằng tải dựa trên DNS liên kết với GSLB · kiểm tra sức khỏe để giảm độ trễ, đồng thời điều phối đánh đổi để TTL không quá ngắn làm tăng tải hạ tầng cấp trên. Phải nhận thức rằng độ trễ vô hiệu hóa bộ nhớ đệm gắn trực tiếp với thời gian khôi phục sự cố (RTO). Đặc biệt, GSLB dựa trên DNS trả về IP của trung tâm dữ liệu tối ưu dựa trên vị trí người dùng · tải máy chủ · độ trễ để phân tán lưu lượng toàn cầu, nhưng có giới hạn là do bộ nhớ đệm của client · bộ phân giải trung gian, việc định tuyến tới nút lỗi vẫn còn tồn tại trong khoảng TTL. Vì thế, cách làm chuẩn với dịch vụ quy mô lớn là đặt phân tán dựa trên DNS ở tầng thứ nhất, nhưng kết hợp nhiều tầng với anycast · bộ cân bằng tải L4/L7 để bổ sung khả năng vòng tránh sự cố tức thời.

Thứ ba, dùng DNS làm trục cốt lõi của giám sát an ninh. Hầu hết C2 của mã độc, lừa đảo, rò rỉ dữ liệu đều đi qua DNS, nên nếu liên kết Protective DNS (DNS bảo vệ), tường lửa DNS (RPZ, Response Policy Zone), phát hiện bất thường dựa trên log DNS với SIEM · XDR thì có thể chặn mối đe dọa từ sớm. Cần tận dụng chiến lược tính hai mặt của DNS: vừa là 'đường tấn công' vừa là 'điểm phát hiện' hiệu quả nhất.

Thứ tư, quản trị và hệ thống kiểm chứng trong giai đoạn chuyển đổi tiêu chuẩn. Tiêu chuẩn liên tục thay đổi như triển khai toàn diện IPv6 (AAAA), KSK rollover của gốc, lan rộng DNS mã hóa, nên tổ chức phải hệ thống hóa quản trị vận hành như tự động hóa ký · xác minh DNSSEC, ngăn chiếm đoạt tên miền bằng registry lock và MFA, phòng ngừa chiếm đoạt tên miền con bằng dọn dẹp bản ghi không dùng. Trong tương lai, vai trò của DNS được dự báo sẽ tiếp tục mở rộng với việc liên kết với kiến trúc zero trust và phát hiện dịch vụ nội bộ trong môi trường cloud native (CoreDNS v.v.).

Thứ năm, góc nhìn về sở hữu hạ tầng, cấu trúc chi phí và chuỗi cung ứng. Tự xây dựng vận hành DNS hay ủy thác cho nhà cung cấp DNS được quản lý (Managed DNS) là vấn đề đánh đổi giữa tính sẵn sàng, chi phí và quyền kiểm soát. Ủy thác cho phép dùng ngay hạ tầng anycast toàn cầu nên hiệu quả về chi phí, nhưng tạo ra sự phụ thuộc vào một nhà cung cấp cụ thể (vendor lock-in) và rủi ro chuỗi cung ứng khi sự cố của nhà cung cấp đó dẫn thẳng tới tê liệt dịch vụ của mình. Các sự cố thực tế của nhà cung cấp DNS lớn lan thành gián đoạn đồng thời nhiều dịch vụ đã minh chứng rủi ro này, nên cần cân nhắc đồng thời việc dùng song song nhiều nhà cung cấp và thiết kế chuyển đổi tự động (failover) khi sự cố. Hơn nữa, không gian tên miền tồn tại trên hệ thống quản trị nối từ ICANN · registry · registrar, nên cần chính thức đưa việc quản lý hết hạn · quyền sở hữu tên miền vào quy trình quản lý tài sản của tổ chức để phòng ngừa sự cố sơ đẳng 'gián đoạn dịch vụ do tên miền hết hiệu lực'.

Tài liệu tham khảo

RFC 1034/1035, Domain Names — Concepts and Implementation/Specification, IETF
RFC 4033/4034/4035, DNS Security Introduction and Requirements (DNSSEC), IETF
RFC 7858, Specification for DNS over Transport Layer Security (DoT), IETF
RFC 8484, DNS Queries over HTTPS (DoH), IETF
RFC 6891, Extension Mechanisms for DNS (EDNS0), IETF
ICANN, tài liệu liên quan KSK Rollover: https://www.icann.org/resources/pages/ksk-rollover
Cloudflare Learning Center, What is DNS?: https://www.cloudflare.com/learning/dns/what-is-dns/
RFC 2308, Negative Caching of DNS Queries (DNS NCACHE), IETF
ICANN Root Server System (Anycast/vận hành máy chủ gốc): https://www.iana.org/domains/root/servers

Tóm tắt một câu: DNS là hệ thống phân giải tên phân cấp, phân tán chuyển đổi tên miền thành IP, bảo đảm khả năng mở rộng nhờ ủy quyền và bộ nhớ đệm nhưng do thiết kế thiếu xác thực · bảo mật nên dễ bị tấn công như đầu độc bộ nhớ đệm, DDoS khuếch đại; cốt lõi là bổ sung bằng DNSSEC (toàn vẹn) và DoH/DoT (bảo mật).