Розробка

Google Public DNS тихо включили підтримку DNS over TLS

Раптово, без попереднього анонсу, на 8.8.8.8 заробив DNS over TLS. Раніше Google анонсував тільки підтримку DNS over HTTPS.

Публічний резолвер від компанії CloudFlare з IP-адресою 1.1.1.1 підтримує DNS over TLS з моменту запуску проекту.

Навіщо це потрібно

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

C DNS over SSL/HTTPS запити надсилаються всередині зашифрованого тунелю так, що провайдер не може підмінити або переглянути запит.

А з приходом шифрування імені домену сертифікатів X. 509 (ESNI) стануть неможливі блокування через DPI по SNI (Server Name Indication, спеціальне поле, в якому передається ім’я домену в першому TLS-пакеті), які зараз застосовуються в деяких великих провайдерів.

Як це працює

На TCP-порт:853 виконується TLS-підключення, при цьому перевірка сертифіката резолвера відбувається з використанням системних кореневих сертифікатів, точно так само, як HTTPS у браузері. Це позбавляє від необхідності додавати які-небудь ключі вручну. Всередині тунелю виконується звичайний DNS-запит. Це створює менше накладних витрат порівняно з DNS over HTTPS, який додає HTTP-заголовки до запиту та відповіді.

На жаль, на поточний момент лише в Android 9 (Pie) підтримка DNS over TLS вбудована в системний резолвер. Інструкція по налаштуванню для Android 9.

Для інших систем пропонується використовувати сторонній демон, а системний резолвер направляти на localhost (127.0.0.1).

Налаштування на macOS

Розберемо налаштування DNS over TLS на останній версії macOS, на прикладі резолвера knot

Установка

 

brew install knot-resolver

За замовчуванням knot буде працювати як звичайний рекурсивний резолвер, подібно dnsmasq.

Редагуємо конфіг

 

nano /usr/local/etc/kresd/config

І додаємо в кінець файлу:


policy.add(
policy.all(
policy.TLS_FORWARD({
 {'8.8.8.8', hostname='8.8.8.8'},
 {'8.8.4.4', hostname='8.8.4.4'}
})))

У підсумку мій конфіг виглядає так:
Розкрити спойлер

-- Config file example useable for personal resolver.
-- The goal is to have a validating resolver with tiny memory footprint,
-- while actively tracking and refreshing frequent records to lower user latency.
-- Refer to manual: https://knot-resolver.readthedocs.io/en/latest/daemon.html#configuration

-- Listen on localhost (default)
-- net = { '127.0.0.1', '::1' }

-- Drop root privileges
-- user('knot-resolver', 'knot-resolver')

-- Auto-maintain root TA
trust_anchors.file = 'root.keys'

-- Load Useful modules
modules = {
 'policy', -- Block queries to local zones/bad sites
 'hints', -- Load /etc/hosts and allow custom root hints
 'stats', -- Track internal statistics
 'predict', -- Prefetch expiring/frequent records
}

-- Smaller cache size
cache.size = 10 * MB

policy.add(
policy.all(
policy.TLS_FORWARD({
 {'8.8.8.8', hostname='8.8.8.8'},
 {'8.8.4.4', hostname='8.8.4.4'}
})))

Детальніше про hostname і перевірку SSL-сертифікатаПараметр hostname в даному випадку — Common Name (CN) або Subject Alt Name (SAN) сертифіката. Тобто, доменне ім’я, для якого випущений сертифікат. По ньому перевіряється справжність сертифіката сервера.

Ось які значення SAN сертифікат, який використовується при підключенні на 8.8.8.8:853

dns.google
8888.google
8.8.4.4
8.8.8.8 
2001:4860:4860:0:0:0:0:64 
2001:4860:4860:0:0:0:0:6464
2001:4860:4860:0:0:0:0:8844
2001:4860:4860:0:0:0:0:8888

Будь-яке з цих значень можна використовувати в якості параметра hostname. Якщо ж ви будете розгортати власний публічний рекурсивний резолвер, у вас навряд чи вийде випустити X. 509-сертифікат на IP-адресу, тому в параметрі hostname доведеться вказувати доменне ім’я.

Запуск демона

 

sudo brew services start knot-resolver

Перевірити, чи успішно запустився демон, можна командою:

sudo lsof -i -P -n | grep kresd

процес kresd повинен слухати порт 53 на localhost.

Якщо щось пішло не так, дивимося лог помилок:

cat /usr/local/var/log/kresd.log

 

Перевірка роботи резолвера

 

dig @127.0.0.1 habr.com

Перевіряємо, що локальний резолвер відповідає коректно.

Встановлення в якості системної резолвера

Якщо все працює правильно, можна призначити системний резолвер у властивостях мережевого адаптера:

UPD

У чому різниця між DNSCrypt, DNSSEC, DNS over SSL/HTTPS.

DNSCrypt може працювати по UDP і TCP. Підключення на порт 443. Для шифрування використовується власний протокол, який відрізняється від HTTPS. Може бути легко виділений з допомогою DPI. Це скоріше чернетка, який тестували до впровадження DNS over SSL/HTTPS, так як він не має RFC, тобто не є офіційним стандартом інтернету. Найвірогідніше, в недалекому часу він буде повністю витіснено останніми.

DNS over TLS (DoT) — TCP-з’єднання відбувається на порт 853, всередині тунелю передається звичайний DNS-запит. Провайдер бачить, що це запит DNS але не може в нього втрутитися. При інших рівних, DNS over TLS має бути трохи менше накладних витрат на кожен запит, ніж over HTTPS.

DNS over HTTP (DoH) — TCP-підключення на порт 443, подібно звичайному HTTPS. Всередині інший формат запиту, з HTTP-заголовків. Однак для провайдера такий запит буде видно як звичайне HTTPS-з’єднання. Гадаю, цей протокол був придуманий на випадок, коли DNS-запити до чужих серверів будуть заблоковані, щоб маскувати під звичайний веб трафік. А також, щоб браузери могли самі резолвить домени і не створювати при цьому аномальний трафік.

По суті, DNS over HTTPS і over TLS — одне і те ж, з трохи відрізняється форматом запитів. Обидва ці протоколу прийняті в якості стандартів і мають RFC. Найімовірніше, найближчим часом ми побачимо масове поширення їх обох.

DNSSEC — протокол цифрового підпису DNS-записів. Не має відносини до шифруванню, так як всі запити передаються у відкритому вигляді. Може працювати як по старому класичному протоколом DNS, тобто UDP/TCP порт 53, так і всередині DNS over SSL/HTTPS. Метою DNSSEC є підтвердження автентичності записів DNS. Власник домену може додати публічний ключ на кореневі сервера доменної зони і підписувати всі записи на майстер NS-сервери. По суті, до кожної DNS записи, наприклад, A-записи або MX-запису, додається ще одна запис типу RRSIG, що містить підпис. Процедура валідації DNSSEC на рекурсивном резолвере дозволяє встановити, чи дійсно ця запис була створена власником домену.

Related Articles

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *

Check Also

Close
Close