DNS mã hóa không VPN che giấu truy vấn, không che địa chỉ của bạn

Một bài kiểm tra rò rỉ DNS hiển thị mạng nhà của bạn không phải bằng chứng rằng DNS mã hóa đã thất bại, và cũng không phải bằng chứng rằng có gì đó đã hoạt động. Bài kiểm tra trả lời một câu hỏi: truy vấn này từ mạng này đã đến trình phân giải nào. Việc đó có phải vấn đề hay không phụ thuộc vào việc bạn đang bảo vệ điều gì và khỏi ai.

Viết ra mục tiêu trước khi chạy bất kỳ bài kiểm tra nào.

Bước 1: gọi tên sự bảo vệ bạn thực sự muốn

Ba mục tiêu bị trộn lẫn. Có thể bạn muốn một người quan sát trên đường đi ngừng đọc các truy vấn. Có thể bạn muốn một trình phân giải cụ thể ngừng nhận chúng. Có thể bạn muốn các trang web bạn truy cập ngừng thấy địa chỉ nhà của bạn. DNS mã hóa phục vụ mục tiêu thứ nhất, thay đổi ai đáp ứng mục tiêu thứ hai, và không làm gì cho mục tiêu thứ ba.

VPN phục vụ mục tiêu thứ ba và, tùy nhà cung cấp, cả mục tiêu thứ nhất. Không công cụ nào là tập cha của công cụ kia.

Bước 2: chọn một trình phân giải và xác minh danh tính của nó

DNS over TLS bọc truy vấn trong một phiên TLS với trình phân giải, và DNS over HTTPS bọc nó trong một yêu cầu HTTP; RFC 7858 và RFC 8484 mô tả cả hai, và không cái nào cần đường hầm. Điều quan trọng trong vận hành là chứng chỉ phải được xác minh với tên bạn đã cấu hình, vì một phiên mã hóa với bên sai còn tệ hơn văn bản thuần với bên đúng. Điều đó có nghĩa là chế độ nghiêm ngặt ở nơi nền tảng cung cấp, không phải chế độ cơ hội lùi lại khi xác minh thất bại. Kiểm tra phiên trực tiếp trước khi tin vào cài đặt: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

Bắt tay phải nêu tên trình phân giải bạn đã cấu hình và trả về một chuỗi mà bạn có thể xác minh.

Bước 3: quyết định hành vi khi thất bại

Mỗi bản triển khai có một chính sách cho trình phân giải mã hóa không thể tiếp cận, và chính sách đó là quyết định về quyền riêng tư. Chế độ nghiêm ngặt làm tra cứu thất bại, điều này hiển nhiên và gây khó chịu. Chế độ cơ hội thử lại bằng văn bản thuần, điều này vô hình và phá hỏng mục đích đúng vào ngày nó quan trọng. Hãy chọn có chủ đích, rồi ghi lựa chọn bên cạnh yêu cầu.

Trên systemd-resolved, lựa chọn là: DNSOverTLS=yes thay vì opportunistic; trên Android, đó là chế độ tên máy chủ của Private DNS thay vì tự động.

Kiểm tra điều gì thực sự có hiệu lực bằng resolvectl status | grep -i -A1 "dns over tls", vì một tệp drop-in chưa bao giờ được tải lại thì không thay đổi gì.

Bước 4: kiểm tra xem ứng dụng có tuân theo trình phân giải của hệ thống không

Một trình duyệt có cài đặt DNS an toàn riêng sẽ bỏ qua hoàn toàn cấu hình hệ thống, và một runtime container có trình phân giải nhúng hay một runtime ngôn ngữ đọc danh sách mã hóa cứng cũng vậy. Hoặc khiến chúng tuân theo hệ thống, hoặc cấu hình chúng một cách rõ ràng và ghi lại. Sau đó xem hành vi dự phòng của từng cái, vì không phải tất cả đều thất bại theo hướng đóng. Danh sách trên thực tế ngắn: trình duyệt, runtime container và bất kỳ ứng dụng VPN nào bạn cũng chạy.

Các tên riêng của tổ chức vẫn ở trên trình phân giải nội bộ đã được phê duyệt. Gửi chúng đến một dịch vụ công cộng để bài kiểm tra trông gọn gàng là cố ý tạo ra một vấn đề khác.

Bước 5: đọc bài kiểm tra rò rỉ đối chiếu với yêu cầu

Một bài kiểm tra báo cáo trình phân giải bất ngờ là một gợi ý, không phải phán quyết. Nó có thể đã quan sát trình phân giải mã hóa bạn định dùng, một cài đặt riêng của ứng dụng, hoặc một lần lùi về văn bản thuần mà bạn không biết. So sánh trình phân giải được báo cáo với những gì bước 2 đã cấu hình, và so sánh kết quả với mục tiêu từ bước 1.

Nếu mục tiêu là giữ truy vấn tránh xa mạng cục bộ, một bài kiểm tra hiển thị trình phân giải thông thường của bạn là một phát hiện thật. Nếu mục tiêu là ẩn danh khi duyệt web, không cài đặt DNS nào có thể mang lại điều đó.

Viết dòng chấp nhận bằng ngôn ngữ của mục tiêu: những tra cứu này dùng trình phân giải đã xác minh này trong những điều kiện này. Bất cứ điều gì rộng hơn là một tuyên bố bạn không thể kiểm tra.