DNS через TLS разом із VPN: яка частина захищена

DNS через TLS шифрує обмін між клієнтом і резолвером, який він вибрав, а резолвер усе одно читає ім'я. Це речення знімає більшу частину плутанини навколо DoT разом із VPN. Тунель вирішує, яким шляхом піде зашифрований запит, а резолвер усе одно дізнається, про що запитали. Жоден механізм не замінює інший, і жоден не робить інший зайвим.

Чотири перевірки вирішують, чи та схема у вас, про яку ви думаєте.

Перевірка 1: що покриває шифрування

DoT загортає обмін DNS у TLS, тому спостерігач на шляху бачить з'єднання до адреси й порту, а не ім'я в запиті. Сам резолвер розшифровує й відповідає. Порівняйте з DNS через HTTPS: обидва шифрують і використовують різні транспорти, тож мережа, яка дозволяє веб-трафік, не дозволяє автоматично з'єднання DoT.

Ця різниця важлива, коли портал перехоплення або фільтрувальний проміжний блок дозволяє 443 і блокує 853. Інструмент, який працював там, не є доказом, що спрацює інший.

Перевірка 2: яким маршрутом іде запит

Маршрут — це питання політики клієнта. До резолвера DoT можна дістатися через тунель, поза ним або шляхом, що змінюється разом із мережею. Який саме варіант станеться, залежить від маршрутів і від того, чи захищає клієнт власний сокет DNS. Тунель, що перехоплює весь трафік, зазвичай забирає запит із собою, хоч би що казала адреса резолвера.

Побачити в тесті адресу стороннього резолвера не доводить обхід, а побачити шифрування не доводить потрібного отримувача. Читайте резолвер і шлях окремо, потім вирішіть, чи це та пара, яку ви проєктували.

Перевірка 3: внутрішні імена

Організації, яка публікує внутрішні імена, потрібен резолвер, що зберігає ці записи. Публічний сервіс DoT не знає вашого приватного простору імен, і спрямування клієнта на нього гарантує, що ці імена не розв'яжуться. Це найчастіша практична регресія, коли хтось вмикає зашифрований DNS на керованому пристрої.

Залиште внутрішній резолвер для внутрішніх суфіксів і шифруйте цю ділянку, якщо цього вимагає політика, замість того щоб замінювати його публічним провайдером.

Перевірка 4: поведінка при збої

Суворе налаштування резолвера без доступного резолвера дає збій розв'язання імен, поки тунель залишається піднятим. Дивіться на режим платформи та її задокументований запасний варіант, а не чіпайте ключі чи сертифікати.

Запасний варіант, який мовчки використовує звичайний DNS, — це рішення політики, а не зручність. Вирішіть, чи збій має бути видимим, чи має спускатися до чогось слабшого, і запишіть відповідь.

Довіряйте сертифікату, а не відповіді

Використовуйте ім'я хоста провайдера та конфігурацію перевірки, задокументовані для сервісу. Вимкнення перевірок TLS, щоб відповів незнайомий резолвер, дає вам зашифрований канал до неперевіреної кінцевої точки, що в одному конкретному відношенні гірше за замінений звичайний запит: це виглядає безпечно. Специфікація DNS через TLS викладає очікування автентифікації, що стоїть за цією перевіркою.

Відповідь від резолвера, який ви не можете автентифікувати, — це твердження, а не результат.

Що це залишає нез'ясованим

DoT не приховує ім'я від резолвера, не приховує адресу призначення з'єднання від мережі й не вирішує, чи запит ішов через тунель. Це три окремі питання з трьома окремими відповідями.

Запишіть ідентичність резолвера, транзитний шлях і політику внутрішніх імен як три рядки. Наступне питання про DNS, яке вам поставлять, буде одним із них.