Kiểm tra rò rỉ DNS: tên resolver không phải tuyến đường

Ba cách bố trí được coi là DNS đúng cho người dùng VPN: truy vấn tới resolver của nhà mạng, truy vấn tới một resolver mã hóa do bạn chọn, và split DNS gửi tên công việc tới tổ chức. Một bài kiểm tra rò rỉ báo cáo một resolver, và nhãn duy nhất đó không thể cho biết bạn thực sự có cách bố trí nào. Hãy quyết định chính sách dự định trước, rồi kiểm tra dựa trên nó. Nếu không, bạn đang so sánh một con số với một cảm giác.

Quyết định điều bạn muốn trước khi đọc kết quả

Nêu chính sách trong một câu: mọi tên tới resolver VPN, mọi tên tới một resolver mã hóa đã chọn, hoặc split DNS với tên nội bộ đi tới tổ chức. Mỗi cách đều biện hộ được cho một người dùng khác nhau, và mỗi cách cho một câu trả lời kỳ vọng khác nhau. Không có câu đó, mọi kết quả khác với ảnh chụp trong bài đăng diễn đàn đều trông đáng lo. Hãy viết chính sách trước lần kiểm tra đầu tiên.

Một bài kiểm tra thực hiện trước khi chính sách được định nghĩa không đo lường gì. Nó tạo ra một tên resolver không có điểm tham chiếu.

Tên resolver không chứng minh tuyến đường hay người nhận

Hai câu hỏi quan trọng: ai đã nhận truy vấn, và tuyến nào đã mang nó. Có thể tới một resolver bên thứ ba qua đường hầm trong khi màn hình cài đặt hiển thị địa chỉ của nhà cung cấp. Nhãn trên trang kiểm tra rò rỉ mô tả góc nhìn của người quan sát, không phải bảng định tuyến của bạn.

Trình duyệt có thể dùng DNS mã hóa riêng trong khi lưu lượng trang đi qua đường hầm, và các câu trả lời trong bộ nhớ đệm có thể cho phép trang tải mà không cần tra cứu mới. Đó là lý do kết quả IP công khai không nói gì về DNS. DoH và DoT bảo vệ truy vấn trên đường tới resolver, và resolver đó vẫn thấy các tên.

resolvectl status
resolvectl query example.com
dig +short example.com

Split DNS làm nhiều resolver trở nên đúng

Một tổ chức có thể gửi tên nội bộ tới DNS của chính mình và mọi thứ khác đi nơi khác. Vì vậy một bài kiểm tra liệt kê nhiều resolver có thể đang mô tả chính sách dự định chứ không phải lỗi. Hãy so sánh tập quan sát được với các quy tắc split DNS đã ghi lại trước khi tắt bất cứ thứ gì. Tắt resolver nội bộ để trang kiểm tra trông sạch hơn sẽ làm hỏng các tên riêng.

Split tunneling và split DNS là những lựa chọn khác nhau: một cái định tuyến gói tin, cái kia định tuyến câu hỏi. Thay đổi tuyến đường hầm không di chuyển việc tra cứu tên, và thay đổi resolver không sửa được đường đi của trang web. IPv6 là câu hỏi thứ ba, vì một kết nối IPv6 không chủ ý không tự động là rò rỉ DNS.

Biến kết quả thành một cuộc điều tra

Ghi lại chính sách dự định và cài đặt DNS an toàn của trình duyệt trước khi kiểm tra. Chạy bài kiểm tra khi đường hầm đang hoạt động, ghi mọi resolver mà nó nêu, và so sánh tập hợp với chính sách chứ không phải với một địa chỉ kỳ vọng duy nhất.

Lặp lại sau khi kết nối lại nếu triệu chứng xuất hiện lúc đó, vì một chính sách áp dụng khi kết nối có thể bị mất sau này. Hãy dùng tài liệu của ứng dụng cho các ngoại lệ DNS nội bộ thay vì đoán cài đặt.

Sửa sự không khớp bạn tìm thấy: lựa chọn trình duyệt, cài đặt DNS của VPN hoặc quy tắc split DNS. Nếu các truy vấn phải dừng khi đường hầm hỏng, kill switch là một cài đặt riêng, và chỉ cấu hình DNS sẽ không cung cấp nó. Đặc tả RFC 8484 hữu ích khi bạn cần giải thích resolver mã hóa che giấu gì và không che giấu gì.