Rò rỉ DNS thực sự tiết lộ gì?

DNS chuyển tên miền thành IP; mỗi trang được truy cập tạo một yêu cầu có thể nhận diện. Truy vấn DNS để lộ tên miền chính xác, thời gian, tần suất và trình phân giải. Nội dung không bị lộ nhưng lộ trình đủ để lập hồ sơ. Cần phân biệt với rò rỉ IP, khi IP thật xuất hiện ngoài đường hầm và mức nghiêm trọng là tức thời. Rò rỉ DNS làm hoạt động duyệt nhìn thấy được mà không lộ IP; mức nghiêm trọng tùy mô hình đe dọa — thực tế nhưng không tối quan trọng trong sử dụng phổ thông, rất nghiêm trọng với báo chí, hoạt động xã hội hoặc kiểm duyệt. VPN đáng tin phải hướng tới không rò rỉ trong mọi trường hợp.

Bốn nguyên nhân thực tế

  • Hệ điều hành chọn giao diện “hiệu quả nhất”: khi có Wi-Fi, Ethernet và đường hầm, nếu VPN không đặt đúng ưu tiên, một số truy vấn đi qua giao diện vật lý. Thường gặp trên Windows, gián đoạn trên macOS, hiếm hơn trên Linux.
  • Split tunneling không quản lý DNS: ứng dụng nằm ngoài đường hầm phân giải tên miền qua nhà cung cấp Internet; ứng dụng dùng chung ngăn xếp mạng cũng có thể đi theo.
  • IPv6 không được hỗ trợ hoặc chặn đúng: nhiều VPN vẫn chỉ xử lý IPv4; trên mạng IPv6, truy vấn AAAA đi thẳng ra ngoài — IPv4 dùng DNS VPN còn IPv6 dùng DNS nhà mạng, xác nhận rò rỉ.
  • Ứng dụng có trình phân giải DNS riêng (DoH/DoT): Firefox, Chrome, một số ứng dụng nhắn tin hoặc game tự quản lý DNS; truy vấn không đi theo DNS của đường hầm mà tới Cloudflare hoặc Google. Ứng dụng chủ động bỏ qua hệ thống nhưng hiệu ứng giống rò rỉ.

Rò rỉ DNS và dual-stack: rủi ro IPv6

Trên hệ thống dual-stack, IPv4 và IPv6 hoạt động cùng lúc, VPN có thể bảo vệ IPv4 nhưng để truy vấn DNS IPv6 thoát ra. Nếu ứng dụng VPN không xử lý rõ IPv6 bằng cách định tuyến trong đường hầm hoặc vô hiệu hóa sạch, truy vấn sẽ đi qua ngăn xếp IPv6 cục bộ tới DNS hệ thống, thường là của nhà cung cấp Internet. Lưu lượng IPv4 được đóng gói đúng nhưng tên miền vẫn lộ — một rò rỉ âm thầm, phổ biến ở nơi IPv6 bật mặc định như Windows, macOS và hầu hết Linux.

Kiểm tra rò rỉ DNS theo từng bước

Kiểm tra nhanh trong trình duyệt

  1. Bật VPN.
  2. Mở DNSLeakTest ở chế độ Extended, BrowserLeaks DNS hoặc IPLeak.net.
  3. Chạy kiểm tra đầy đủ và quan sát máy chủ DNS được phát hiện.
  4. Thử lại sau khi kết nối lại mạng hoặc chuyển giữa Wi-Fi với mạng di động.

Kết quả bình thường: máy chủ thuộc VPN hoặc đúng trình phân giải bạn chủ động cấu hình. Kết quả bất thường: xuất hiện DNS nhà cung cấp Internet, trình phân giải IPv6 cục bộ còn tồn tại hoặc vị trí DNS vẫn là vị trí kết nối trong khi máy chủ VPN ở nơi khác. Chỉ một dòng ngoài đường dự kiến cũng đủ báo hiệu rò rỉ.

Kiểm tra nhanh chỉ bao phủ trình duyệt, có thể xử lý IPv6 chưa đầy đủ và phụ thuộc dịch vụ bên thứ ba. Đây là chẩn đoán ban đầu tốt, không phải bằng chứng toàn diện.

Kiểm tra nâng cao: bắt gói mạng

Wireshark trên Windows, macOS hoặc Linux

Wireshark cho biết giao diện được dùng và điểm đến thật của truy vấn. Bắt gói trên giao diện vật lý rồi dùng một trong các bộ lọc:

dns
udp.port == 53 || tcp.port == 53

Nếu truy vấn DNS xuất hiện trên giao diện vật lý trong khi đáng lẽ ở trong đường hầm, rò rỉ được xác nhận. Cách này không tự bao phủ DNS mã hóa qua HTTPS hay TLS; cần quan sát cả kết nối tới trình phân giải DoH/DoT đã cấu hình.

tcpdump trên Linux hoặc macOS

sudo tcpdump -i en0 -n port 53

Thay en0 bằng giao diện vật lý của hệ thống. Công cụ hữu ích để xác nhận rò rỉ gián đoạn sau khi kết nối lại.

Công cụ và giới hạn

  • DNSLeakTest Extended: đơn giản, dễ đọc nhưng bao phủ IPv6 hạn chế.
  • BrowserLeaks DNS: chi tiết hơn cho trình duyệt và IPv6 nhưng không bao phủ mọi ứng dụng.
  • IPLeak.net: hữu ích để đối chiếu DNS, IPv4, IPv6 và WebRTC.
  • Wireshark: kiểm soát đầy đủ nhất nhưng phân tích kỹ thuật hơn.
  • tcpdump: nhẹ và trực tiếp nhưng phải biết giao diện cần quan sát.

Khắc phục rò rỉ DNS

VPN đáng tin phải có kill switch DNS, DNS binding chặt, xử lý đúng hoặc chặn sạch IPv6, và giữ quy tắc DNS khi kết nối lại. Người dùng có thể tắt DoH/DoT trong trình duyệt, tạm tắt IPv6 nếu VPN không hỗ trợ, hạn chế split tunneling, kiểm tra sau mỗi cập nhật hệ điều hành/VPN và xác định ứng dụng dùng DNS riêng như nhắn tin, game, P2P.

DoH/DoT: bảo vệ hay đi vòng?

DoH/DoT bảo vệ truy vấn DNS trước nhà cung cấp Internet hoặc mạng cục bộ thù địch, nhưng khi VPN hoạt động nó có thể gây xung đột định tuyến: VPN mất quyền kiểm soát DNS, truy vấn tới Cloudflare, Google hoặc Quad9 và niềm tin chuyển từ VPN sang trình phân giải ngoài. Trong thực tế: nếu tin VPN, hãy tắt DoH/DoT trong trình duyệt; nếu không tin VPN, DoH/DoT cục bộ có logic nhưng cần tự hỏi vì sao vẫn dùng VPN đó; kết hợp cả hai mà không hiểu đường đi sẽ phá chuỗi bảo vệ.

Rò rỉ DNS không cho thấy gì?

Để tránh phóng đại: rò rỉ DNS không tiết lộ IP thật, nội dung liên lạc mã hóa, thông tin đăng nhập hay trang con chính xác trong một tên miền. Nó cho thấy tên miền, tần suất, trình tự thời gian và dịch vụ đã dùng — đủ để lập hồ sơ hành vi.

Hành động ngay. Kết nối VPN, chạy kiểm tra mở rộng rồi thử lại sau khi kết nối lại. Nếu DNS của nhà cung cấp Internet xuất hiện trở lại dù cấu hình đúng, đó là dấu hiệu trực tiếp về mức trưởng thành kỹ thuật của ứng dụng VPN.

Rò rỉ DNS là thước đo độ trưởng thành của VPN

Rò rỉ DNS không phải chi tiết nhỏ mà là bài kiểm tra cấu trúc. VPN đáng tin phải kiểm soát giao diện mạng, IPv6, split tunneling, trình phân giải và kết nối lại — đặc biệt dual-stack, nơi IPv6 thường bật mặc định và có thể phân giải ngoài đường hầm nếu ứng dụng không xử lý rõ. VPN để truy vấn DNS thoát ra không bảo vệ trọn hoạt động mà chia cắt nó. Độ tin cậy phải được đánh giá bằng hành vi quan sát được: kiểm tra DNS đầy đủ và lặp lại sau khi kết nối lại. Xem thêm tốc độ giao thức và tổng quan giao thức.