Bạn gặp DNS vì một trong hai việc: cần đổi máy chủ phân giải trên thiết bị (vai người dùng Internet), hoặc cần quản trị bản ghi cho website và email (vai chủ tên miền). Hai việc này khác nhau hoàn toàn, và bài viết tách rõ theo từng vai để bạn đọc đúng phần […]
Bạn gặp DNS vì một trong hai việc: cần đổi máy chủ phân giải trên thiết bị (vai người dùng Internet), hoặc cần quản trị bản ghi cho website và email (vai chủ tên miền). Hai việc này khác nhau hoàn toàn, và bài viết tách rõ theo từng vai để bạn đọc đúng phần mình cần.
DNS (Domain Name System) là hệ thống phân giải tên miền: dịch một tên miền dễ nhớ như tenten.vn sang địa chỉ IP của máy chủ lưu trữ website đó, và làm ngược lại khi cần. Cách dễ hình dung nhất là so với một danh bạ điện thoại: bạn nhớ tên người cần gọi, danh bạ tra ra đúng số điện thoại tương ứng để máy quay số. DNS làm chính xác việc đó, nhưng cho tên miền và địa chỉ IP.
Hệ thống này ra đời năm 1983, do Paul Mockapetris thiết kế và công bố qua RFC 882 và RFC 883. Trước đó, toàn bộ Internet tra cứu địa chỉ bằng một file văn bản duy nhất tên HOSTS.TXT. Một tổ chức trung tâm cập nhật file này và phân phối thủ công tới từng máy. Cách này còn dùng được khi Internet có vài trăm máy chủ, nhưng vỡ trận khi số lượng tên miền tăng theo cấp số nhân. Vì vậy, DNS giải quyết đúng giới hạn đó bằng cách phân tán việc lưu trữ và tra cứu ra hàng nghìn máy chủ trên toàn cầu, thay vì dồn vào một file tập trung.
Một hiểu lầm phổ biến là hình dung DNS như “một máy chủ ở đâu đó”. Trên thực tế, DNS không phải một máy chủ đơn lẻ, mà là mạng lưới phân cấp gồm nhiều tầng máy chủ khác vai trò, phối hợp với nhau để trả lời một truy vấn. Chẳng hạn, khi bạn gõ tenten.vn vào trình duyệt, trình duyệt chưa thể kết nối ngay. Nó cần địa chỉ IP thật của máy chủ đang lưu website đó trước, và DNS chính là bước trung gian bắt buộc để lấy được IP này.
Từ đây, DNS xuất hiện trong đời bạn theo hai vai tách biệt. Là người dùng Internet, bạn gặp DNS khi thiết bị cần chọn một máy chủ để gửi truy vấn phân giải, và bạn có quyền đổi máy chủ đó. Là chủ tên miền, bạn gặp DNS khi khai báo bản ghi để website, email hoạt động đúng dưới tên miền của mình. Phần lớn nhầm lẫn khi đọc về DNS đến từ việc gộp chung hai việc này. Bài viết sẽ đi lần lượt: cơ chế chung trước, rồi vai người dùng, rồi vai chủ tên miền.
DNS phân giải một tên miền bằng cách truy vấn tuần tự qua 4 tầng máy chủ, mỗi tầng biết một phần của câu trả lời. Đây là mô hình hiện hành, khác với cách một số bài tiếng Việt vẫn mô tả DNS chỉ có “Root” và “Local”: cách chia đó bỏ sót hẳn tầng TLD và tầng Authoritative, hai tầng thực sự giữ thông tin phân giải cuối cùng.
Khi thiết bị của bạn cần phân giải một tên miền chưa có trong cache, truy vấn đi qua 4 tầng theo trình tự sau:

Phần lớn truy vấn thực tế không cần đi hết cả 4 tầng, nhờ cơ chế cache (bộ nhớ đệm lưu tạm kết quả đã tra). Trình duyệt, hệ điều hành và cả recursive resolver đều tạm giữ kết quả đã phân giải trong bộ nhớ. Vì vậy, khi bạn hoặc người dùng khác trên cùng resolver truy cập lại một tên miền vừa tra, resolver trả thẳng kết quả từ cache. Nhờ đó, thời gian phân giải tính bằng mili giây thay vì phải hỏi lại toàn bộ chuỗi 4 tầng.
Thời gian một bản ghi được phép nằm trong cache gọi là TTL (time to live), do chủ tên miền đặt cho từng bản ghi khi khai báo. TTL càng dài, resolver càng ít phải hỏi lại authoritative server, nhưng thay đổi bản ghi cũng lan chậm hơn tới người dùng cuối, điều sẽ quay lại ở phần trỏ DNS phía dưới.
Về mặt kỹ thuật, truy vấn giữa thiết bị và resolver gọi là recursive query: resolver có trách nhiệm trả về câu trả lời cuối cùng, không đẩy việc lại cho thiết bị. Truy vấn giữa resolver và các tầng root/TLD/authoritative gọi là iterative query: mỗi tầng chỉ trả lời “hỏi tiếp ở đâu” thay vì tự đi hỏi hộ. Phân biệt này chủ yếu có ý nghĩa khi debug (dò lỗi) hệ thống DNS, không ảnh hưởng tới cách bạn dùng DNS hằng ngày.
Trong 4 tầng trên, recursive resolver là tầng duy nhất người dùng cuối chọn được. Root, TLD và authoritative server đều cố định theo tên miền và ngoài tầm kiểm soát của bạn. Vì vậy, khi mọi người nói “đổi DNS”, họ đang nói đến việc đổi recursive resolver, không phải đổi cả hệ thống. Phần tiếp theo đi vào đúng lựa chọn này.
Bạn nên chọn recursive resolver dựa trên bốn tiêu chí đo được: tốc độ thực tế từ vị trí của bạn, chính sách lọc nội dung, hỗ trợ mã hóa truy vấn, và chính sách log. Không có một DNS “nhanh nhất” đúng cho tất cả, vì tốc độ phụ thuộc khoảng cách mạng tới máy chủ gần bạn nhất. Khoảng cách này khác nhau theo từng nhà mạng và khu vực.
Trước khi so sánh, bạn cần phân biệt hai nhóm resolver:
Một khái niệm khác cần nắm trước khi đọc bảng dưới là DoH/DoT (DNS over HTTPS/DNS over TLS): đây là chuẩn mã hóa truy vấn DNS trên đường truyền, giúp truy vấn không bị đọc trộm hoặc giả mạo giữa đường. Bảng so sánh dưới đây liệt kê các resolver phổ biến theo địa chỉ IPv4, khả năng lọc nội dung, và hỗ trợ DoH/DoT:
|
Resolver |
Địa chỉ IPv4 |
Lọc nội dung |
Hỗ trợ DoH/DoT |
Ghi chú |
|
Google Public DNS |
8.8.8.8 / 8.8.4.4 |
Không lọc |
Có |
Tốc độ ổn định toàn cầu, không chặn nội dung |
|
Cloudflare |
1.1.1.1 / 1.0.0.1 |
Không lọc (bản gốc) |
Có |
1.1.1.2 chặn malware, 1.1.1.3 chặn thêm nội dung người lớn |
|
Quad9 |
9.9.9.9 |
Chặn domain độc hại |
Có |
Dữ liệu đe dọa tổng hợp từ nhiều nguồn threat intelligence |
|
OpenDNS (Cisco) |
208.67.222.222 |
Lọc theo gia đình (tùy chọn) |
Có |
Cấu hình được nhiều mức lọc theo tài khoản |
|
AdGuard DNS |
94.140.14.14 |
Chặn quảng cáo, tracker |
Có |
Có bản chặn thêm nội dung người lớn riêng |
Từ bảng trên, khuyến nghị theo từng tình huống cụ thể:
Một điểm bạn cần lưu ý khi tham khảo danh sách DNS trên mạng: nhiều bài liệt kê cả các dịch vụ đã ngừng hoạt động. Ví dụ, Norton ConnectSafe đã dừng từ năm 2018 nhưng vẫn xuất hiện trong không ít bài so sánh. Vì vậy, trước khi dùng một resolver lạ, bạn nên kiểm tra trang chính thức của nhà cung cấp thay vì tin theo danh sách cũ.
Thay vì tin lời quảng cáo “DNS nhanh nhất”, bạn tự đo được bằng hai cách:
Vì tốc độ phụ thuộc vị trí địa lý và nhà mạng, kết quả đo ở nhà bạn có thể khác hẳn kết quả trên một bài đánh giá viết cho thị trường khác.
Sau khi đã chọn resolver theo tiêu chí ở phần trên, bước tiếp theo là đổi DNS trên đúng thiết bị hoặc router bạn dùng. Cách thao tác khác nhau theo từng nền tảng, nhưng bản chất đều là thay địa chỉ recursive resolver mặc định bằng địa chỉ bạn chọn.
Trên Windows 11 và 10, vào Settings, chọn Network & Internet, mở thuộc tính của adapter mạng đang dùng, rồi tìm mục DNS server assignment và chuyển sang Manual để nhập địa chỉ resolver mới. Với máy chạy bản Windows đời cũ hơn hoặc quen giao diện cũ, đường dẫn tương đương vẫn còn trong Control Panel, qua Network and Sharing Center.
Windows 11 còn cho bật DNS over HTTPS ngay trong màn hình cấu hình DNS này, miễn là resolver bạn chọn có hỗ trợ DoH (như các resolver ở bảng phần trên).

Trên macOS, vào System Settings, chọn Wi-Fi, mở Details của mạng đang kết nối, rồi tìm mục DNS để thêm hoặc thay địa chỉ resolver. Thao tác cần lặp lại cho từng mạng Wi-Fi bạn dùng thường xuyên, vì macOS lưu cấu hình DNS riêng theo từng mạng.

Trên Android từ phiên bản 9 trở lên, bạn dùng tính năng Private DNS thay vì nhập IP thủ công cho từng Wi-Fi. Tính năng này nhận một hostname hỗ trợ DoT (DNS over TLS), ví dụ dns.google hoặc one.one.one.one, và áp dụng cho mọi kết nối mạng của máy, kể cả khi đổi Wi-Fi.
Trên iPhone và iPad, bạn đổi DNS theo từng mạng Wi-Fi riêng lẻ trong phần cấu hình mạng, hoặc cài một profile DoH do resolver cung cấp để áp dụng mã hóa truy vấn cho toàn thiết bị.

Đổi DNS ngay tại router giúp mọi thiết bị trong nhà dùng chung một resolver mà không cần cấu hình lại từng máy. Tuy nhiên, bạn cần lưu ý: thiết bị nào đã tự đặt DNS riêng (theo các bước ở trên) sẽ ghi đè cấu hình của router. Vì vậy, đổi ở router không đảm bảo áp dụng cho toàn bộ thiết bị nếu trước đó bạn từng chỉnh tay.
Sau khi đổi DNS ở bất kỳ đâu, thiết bị vẫn có thể dùng bản ghi cũ trong cache một thời gian. Để nhận DNS mới ngay, xóa cache DNS bằng lệnh tương ứng theo hệ điều hành:
ipconfig /flushdns trong Command Prompt.dscacheutil -flushcache rồi sudo killall -HUP mDNSResponder trong Terminal.
Đổi DNS ở phần trên là việc của người dùng Internet, chọn resolver để phân giải nhanh và đúng ý mình. Từ đây, bài chuyển sang vai còn lại: chủ tên miền, người phải khai báo bản ghi để tên miền của mình trỏ đúng tới website và email. Phần này là kiến thức nền bắt buộc trước khi bạn trỏ DNS ở phần kế tiếp.
Bản ghi DNS (DNS record) là một dòng khai báo lưu tại authoritative server, quy định tên miền hoặc tên miền phụ trả lời thế nào cho từng loại truy vấn. Bảng dưới đây liệt kê các loại bản ghi phổ biến nhất, cùng chức năng và ví dụ dùng thật:
|
Loại |
Chức năng |
Ví dụ dùng thật |
|
A |
Trỏ tên miền sang địa chỉ IPv4 |
tenten.vn → 103.x.x.x |
|
AAAA |
Trỏ tên miền sang địa chỉ IPv6 |
Dùng khi hosting hỗ trợ IPv6 song song IPv4 |
|
CNAME |
Đặt bí danh, trỏ một tên miền phụ sang tên miền khác |
www.example.com → example.com |
|
MX |
Định tuyến email đến đúng máy chủ mail |
mail.example.com xử lý toàn bộ email @example.com |
|
TXT |
Lưu chuỗi văn bản để xác minh hoặc chống giả mạo |
SPF, DKIM cho email; xác minh quyền sở hữu tên miền với Google |
|
NS |
Chỉ định nameserver quản lý zone (tập hợp bản ghi của tên miền) |
Trỏ ns1.tenten.vn, ns2.tenten.vn |
|
SOA |
Lưu thông tin quản trị của zone (email quản trị, số serial) |
Tự sinh khi tạo zone, ít khi chỉnh tay |
|
PTR |
Phân giải ngược từ IP về tên miền |
Dùng cho uy tín email server, tránh bị đánh dấu spam |
|
CAA |
Giới hạn tổ chức nào được cấp chứng chỉ SSL cho tên miền |
Chỉ cho phép một CA cụ thể cấp SSL |
|
SRV |
Khai báo dịch vụ đặc thù chạy trên cổng cụ thể |
VoIP, một số dịch vụ nhắn tin nội bộ |
Nhóm bản ghi liên quan tới email (MX cùng TXT chứa SPF/DKIM) đáng chú ý hơn các nhóm còn lại. Sai một dòng ở đây không làm sập website, mà làm toàn bộ email của doanh nghiệp ngừng nhận hoặc rơi vào thư rác. Trong khi đó, nhiều tài liệu phổ biến chỉ liệt kê A, CNAME, MX mà bỏ qua SOA, PTR, CAA. Vì vậy chủ tên miền thường không biết các bản ghi này tồn tại cho tới khi gặp sự cố liên quan.
Toàn bộ bảng bản ghi ở trên nằm tại nameserver, máy chủ giữ zone (tập hợp bản ghi) của một tên miền. Nơi nào đang giữ nameserver của tên miền, nơi đó chính là “nguồn sự thật” quyết định website và email của bạn chạy ra sao, bất kể hosting đặt ở đâu.
Trỏ DNS là bước gắn tên miền với đúng hosting và hệ thống email đang dùng. Bạn thực hiện theo một trong hai cách sau:
Các bước trỏ DNS về cơ bản giống nhau trên hầu hết giao diện quản trị tên miền:

Bạn nên điều chỉnh TTL của các bản ghi này theo thời điểm. Trước khi chuyển hosting, bạn hạ TTL xuống thấp, khoảng 300 giây, để khi đổi bản ghi, thay đổi lan tới người dùng nhanh hơn. Sau khi cấu hình đã ổn định, bạn nâng lại TTL lên mức 3600 giây trở lên, giúp giảm số lần resolver phải hỏi lại authoritative server.
Dù trỏ đúng, website chưa chắc chạy ngay lập tức, vì còn phải qua giai đoạn DNS propagation. Đây là quá trình thay đổi bản ghi lan tới toàn bộ resolver trên thế giới, kéo dài từ vài phút tới 48 giờ tùy TTL cũ và cache còn lại ở từng nơi. Phần lớn trường hợp “trỏ rồi mà web chưa lên” là do đang trong giai đoạn lan truyền này, không phải do cấu hình sai. Vì vậy, nếu bạn sửa đi sửa lại bản ghi trong lúc chờ, quá trình lan truyền chỉ chậm thêm.
Để kiểm tra sau khi trỏ, bạn dùng lại lệnh nslookup hoặc dig để đối chiếu địa chỉ IP thực tế mà bản ghi đang trả về, hoặc dùng công cụ dnschecker.org để xem tình trạng lan truyền theo từng khu vực trên thế giới. Ba lỗi bạn hay gặp nhất khi trỏ DNS là: quên tạo bản ghi cho www bên cạnh bản ghi @, quên khai lại MX sau khi đổi nameserver, và đặt TTL quá cao khiến việc đổi bản ghi lan chậm hơn cần thiết.
Nếu bạn đăng ký tên miền .vn tại TENTEN, toàn bộ quy trình trên thực hiện trong cùng một giao diện quản trị qua hệ thống Managed DNS: tạo bản ghi A, CNAME, MX và trỏ về hosting mà không cần chuyển qua nhiều bảng điều khiển tách rời.
DNS được thiết kế từ năm 1983, khi bảo mật chưa phải ưu tiên hàng đầu của giao thức Internet. Vì vậy, DNS không có bước xác thực nguồn gốc truy vấn hay phản hồi, và đặc điểm này khiến nó trở thành mục tiêu tấn công phổ biến. Theo IDC Global DNS Threat Report 2023 (khảo sát thực hiện cho EfficientIP), 90% tổ chức được khảo sát từng gặp ít nhất một cuộc tấn công liên quan DNS trong năm, với chi phí thiệt hại trung bình khoảng 1,1 triệu USD mỗi vụ.

Bốn kiểu tấn công phổ biến nhất khai thác đúng lỗ hổng thiếu xác thực đó:

DNSSEC (DNS Security Extensions) là cơ chế đối phó trực tiếp với những rủi ro trên. Mỗi bản ghi được ký bằng chữ ký số, nhờ đó resolver xác thực được bản ghi nhận về đúng là do chủ tên miền công bố, không bị chỉnh sửa dọc đường. Tại Việt Nam, VNNIC đã ký DNSSEC cho toàn bộ zone .vn trên hệ thống DNS quốc gia từ cuối năm 2016, theo lộ trình được phê duyệt tại Quyết định 1524/QĐ-BTTTT năm 2014. Ngoài ra, VNNIC còn vận hành Cổng tiếp nhận phản ánh lạm dụng tên miền từ ngày 14/5/2024, kênh chính thức để báo cáo các hành vi lạm dụng liên quan tên miền .vn và tên miền quốc tế tại Việt Nam.
DoH và DoT, đã nhắc ở phần chọn DNS, còn có vai trò bảo mật riêng: mã hóa truy vấn trên đường truyền. Truy vấn dạng thường truyền dưới dạng văn bản thô, trong khi truy vấn mã hóa khiến kẻ tấn công đứng giữa (trên cùng mạng Wi-Fi công cộng, hoặc tại một điểm trung chuyển mạng) khó nghe lén hoặc giả mạo phản hồi DNS hơn.
Với vai trò chủ tên miền, một số việc nên làm định kỳ để giảm rủi ro:
DNS không đòi hỏi hai vai người dùng và chủ tên miền hiểu sâu như nhau. Nếu bạn là người dùng Internet, chọn đúng recursive resolver theo tiêu chí đo được là đủ, không cần quan tâm tới bản ghi hay nameserver. Nếu bạn là chủ tên miền, bản ghi DNS phải được bạn quản trị như một tài sản vận hành, vì cấu hình sai ở đây khiến website và email ngừng hoạt động trước bất kỳ lỗi nào khác trong hệ thống.
Có ba điểm dễ nhầm giữa hai vai này đáng nhắc lại:
Nếu bạn đang chuẩn bị đăng ký hoặc quản trị tên miền .vn, kiểm tra tên miền và trải nghiệm thử hệ thống Managed DNS tại Tenten.vn để thấy toàn bộ bước tạo bản ghi và trỏ DNS gói trong một giao diện quản trị duy nhất.