DNS trên TLS cùng VPN: phần nào được bảo vệ

DNS trên TLS mã hóa trao đổi giữa máy khách và resolver mà nó chọn, và resolver vẫn đọc tên. Câu đó giải quyết phần lớn sự nhầm lẫn quanh DoT cùng VPN. Đường hầm quyết định truy vấn đã mã hóa đi theo tuyến nào, trong khi resolver vẫn biết người ta hỏi gì. Không cơ chế nào thay thế cơ chế kia, và không cơ chế nào làm cơ chế kia thành thừa.

Bốn kiểm tra quyết định liệu cách bố trí bạn có phải là cách bạn nghĩ mình có.

Kiểm tra 1: mã hóa bao phủ những gì

DoT bọc trao đổi DNS trong TLS, nên người quan sát trên tuyến thấy một kết nối đến địa chỉ và cổng chứ không phải một tên trong truy vấn. Chính resolver giải mã và trả lời. Hãy so sánh với DNS trên HTTPS: cả hai đều mã hóa và dùng các phương tiện vận chuyển khác nhau, nên mạng cho phép lưu lượng web không tự động cho phép kết nối DoT.

Sự khác biệt đó quan trọng khi một cổng bắt giữ hoặc một hộp trung gian lọc cho phép 443 và chặn 853. Công cụ chạy được ở đó không phải bằng chứng rằng cái kia sẽ chạy được.

Kiểm tra 2: truy vấn đi theo tuyến nào

Tuyến là câu hỏi về chính sách máy khách. Có thể tiếp cận resolver DoT qua đường hầm, bên ngoài nó, hoặc qua một đường thay đổi theo mạng. Việc nào xảy ra phụ thuộc vào các tuyến và vào việc máy khách có tự bảo vệ ổ cắm DNS của mình hay không. Một đường hầm bắt toàn bộ lưu lượng thường mang theo cả truy vấn, bất kể địa chỉ resolver nói gì.

Thấy địa chỉ resolver của bên thứ ba trong một bài kiểm tra không chứng minh có né tránh, và thấy mã hóa không chứng minh đúng người nhận dự định. Hãy đọc resolver và tuyến riêng rẽ, rồi quyết định xem cặp đó có phải cặp bạn đã thiết kế.

Kiểm tra 3: tên nội bộ

Một tổ chức công bố tên nội bộ cần một resolver giữ những bản ghi đó. Dịch vụ DoT công cộng không biết không gian tên riêng của bạn, và việc trỏ máy khách vào nó bảo đảm những tên đó sẽ thất bại. Đây là sự thoái lui thực tế phổ biến nhất khi ai đó bật DNS mã hóa trên một thiết bị được quản lý.

Giữ resolver nội bộ cho các hậu tố nội bộ và mã hóa chặng đó nếu chính sách yêu cầu, thay vì thay nó bằng một nhà cung cấp công cộng.

Kiểm tra 4: hành vi khi thất bại

Cấu hình resolver nghiêm ngặt mà không có resolver tiếp cận được tạo ra lỗi phân giải tên trong khi đường hầm vẫn dựng. Hãy xem chế độ của nền tảng và dự phòng được ghi tài liệu của nó thay vì chạm vào khóa hay chứng chỉ.

Một dự phòng âm thầm dùng DNS thường là quyết định chính sách, không phải tiện lợi. Hãy quyết định xem lỗi nên hiển thị hay nên hạ xuống thứ yếu hơn, và viết câu trả lời ra.

Tin chứng chỉ, không tin câu trả lời

Dùng tên máy chủ của nhà cung cấp và cấu hình xác minh được ghi tài liệu cho dịch vụ. Tắt các kiểm tra TLS để một resolver lạ trả lời cho bạn một kênh mã hóa đến một điểm cuối chưa xác minh, điều này tệ hơn truy vấn thường mà nó thay thế ở một khía cạnh cụ thể: nó trông có vẻ an toàn. Đặc tả DNS over TLS trình bày kỳ vọng xác thực đằng sau kiểm tra đó.

Câu trả lời từ một resolver bạn không thể xác thực là một khẳng định, không phải kết quả.

Điều này để lại gì chưa giải thích

DoT không giấu tên khỏi resolver, không giấu địa chỉ đích của kết nối khỏi mạng và không quyết định truy vấn có đi qua đường hầm hay không. Đó là ba câu hỏi riêng với ba câu trả lời riêng.

Hãy viết danh tính resolver, tuyến trung chuyển và chính sách tên nội bộ thành ba dòng. Câu hỏi DNS tiếp theo bạn nhận được sẽ là một trong số đó.