Зашифрований DNS без VPN приховує запит, а не вашу адресу

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

Запишіть мету перед запуском будь-якого тесту.

Крок 1: назвіть захист, який ви справді хочете

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

VPN служить третій і, залежно від постачальника, першій. Жоден з інструментів не є надмножиною іншого.

Крок 2: виберіть резолвер і перевірте його справжність

DNS over TLS загортає запит у сеанс TLS з резолвером, а DNS over HTTPS загортає його в HTTP-запит; RFC 7858 і RFC 8484 описують обидва, і жодному не потрібен тунель. Операційно важливо, щоб сертифікат перевірявся за іменем, яке ви налаштували, бо зашифрований сеанс із неправильною стороною гірший за відкритий текст із правильною. Це означає суворий режим там, де платформа його пропонує, а не опортуністичний режим, який відступає, коли перевірка не вдається. Перевірте сеанс безпосередньо, перш ніж довіряти налаштуванню: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

Рукостискання має назвати налаштований вами резолвер і повернути ланцюжок, який можна перевірити.

Крок 3: вирішіть, як поводитися при збої

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

У systemd-resolved це означає DNSOverTLS=yes а не opportunistic; а в Android це означає режим імені хоста Private DNS замість автоматичного.

Перевірте, що насправді діє, за допомогою resolvectl status | grep -i -A1 "dns over tls", бо drop-in-файл, який жодного разу не перезавантажували, нічого не змінює.

Крок 4: перевірте, чи додатки дотримуються системного резолвера

Браузер із власним налаштуванням безпечного DNS повністю обходить конфігурацію системи, як і контейнерний runtime із вбудованим резолвером або мовний runtime, що читає жорстко закодований список. Або змусьте їх дотримуватися системи, або налаштуйте їх явно і запишіть це. Потім подивіться на поведінку відкату кожного з них, бо не всі вони відмовляють закрито. Інвентар на практиці короткий: браузер, контейнерний runtime і будь-який клієнт VPN, який ви теж запускаєте.

Приватні імена організації залишаються на схваленому внутрішньому резолвері. Надсилати їх до публічного сервісу, щоб тест виглядав охайно, — це навмисне створення іншої проблеми.

Крок 5: читайте тест витоку щодо вимоги

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

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

Запишіть критерій приймання мовою мети: ці пошуки використовують цей перевірений резолвер за цих умов. Усе ширше — це твердження, яке ви не можете перевірити.