Этап 11 — Шифрованный DNS: DoT, DoH, DoQ, ODoH и ECH

Десять этапов мы разбирали путь запроса как инженеры: кто куда идёт и почему. Теперь посмотрим на тот же путь глазами наблюдателя на стыке — и увидим, что первая же операция, резолв имени, до сих пор во многих сетях идёт открытым текстом. За семь лет IETF закрыл эту дыру четырьмя протоколами, и последний кирпич — шифрование имени в самом TLS — стал стандартом в марте 2026 года. Этот урок про то, что именно закрыто, что осталось открытым и что всё это меняет для инженера сети.

Рабочая ситуация

«Заявка в NOC оператора: „После обновления браузеров у нас перестала работать корпоративная фильтрация — сотрудники открывают что угодно, хотя на резолвере блок-лист на месте. При этом служебный портал по внутреннему имени перестал открываться совсем: `nslookup` его находит, браузер — нет. Что вы сломали?“»

Оператор ничего не ломал. Браузер начал ходить в свой DoH-резолвер мимо корпоративного — и мимо блок-листа, и мимо split-horizon-зоны с внутренними именами. К концу урока ты сможешь объяснить это заказчику по шагам и предложить решение, которое не сводится к «запретите обновления».

Подумай до объяснения

Ты включил DoH к публичному резолверу. Сколько имён сайтов после этого видит провайдер — ноль или столько же, сколько раньше?
DoT легко заблокировать одним правилом фильтра, DoH — почти нельзя. Оба возят один и тот же DNS. В чём разница?
Если ключ для шифрования имени сайта лежит в DNS, а DNS шифруется ключом… откуда берётся первый ключ?

Что узнаешь

Что именно видит наблюдатель на стыке при открытом DNS — по полям, а не «в общем»
Как устроены DoT (RFC 7858), DoH (RFC 8484) и DoQ (RFC 9250) и чем они отличаются на проводе
Почему DoT блокируется одним правилом, а DoH — нет, и что из этого следует для оператора
Как клиент узнаёт про шифрованный резолвер: DDR (RFC 9462) через DNS и DNR (RFC 9463) через DHCP/RA
Что развязывает ODoH (RFC 9230) и почему это не то же самое, что «двойное шифрование»
Зачем нужен ECH (RFC 9849) и почему без него шифрование DNS не скрывает имя сайта
Как продиагностировать «браузер не резолвит, а nslookup резолвит» за четыре шага
Что делать оператору и админу сети, когда абонент ушёл на чужой резолвер

Вспомни из прошлых уроков

Из этапа 2: stub-резолвер в ОС спрашивает рекурсивный резолвер, тот обходит дерево и кэширует по TTL. Шифрование, о котором пойдёт речь, защищает только первый участок — от stub к рекурсивному.
Оттуда же, раздел про DoT и DoH: мы уже назвали эти протоколы. Сегодня разбираем их до полей и до эксплуатационных последствий.
Из этапа 5: в ClientHello клиент кладёт расширение SNI — имя сервера, к которому идёт. Это поле — ключ ко всему уроку.
Из этапа 6: QUIC живёт поверх UDP и не страдает от блокировки головы очереди. Ровно по этой причине появился DoQ.

1. Что видно в открытом DNS — по полям

Классический DNS — это UDP на порт 53 без единого байта шифрования и без подписи транспорта. Не «слабое шифрование», а его полное отсутствие: пакет читается любым устройством на пути так же легко, как его читает сам резолвер.

Наблюдателем может быть кто угодно на трассе: коммутатор с зеркалом порта, точка Wi-Fi в кафе, маршрутизатор оператора, система DPI. Ему не нужно ничего взламывать — достаточно смотреть. Вот что он получает из одного-единственного запроса:

QNAME — имя, которое спрашивают, в открытом виде: bank.example.com.
QTYPE — тип записи: A, AAAA, MX, HTTPS. По типу видно, чего хочет клиент.
Адрес источника — кто спрашивает: конкретный абонент, конкретное устройство.
Время — когда спрашивал, как часто, в каком порядке.
Ответ целиком — какие адреса вернулись и с каким TTL.

Из этого набора собирается полная история просмотров: не «зашёл в интернет», а «в 09:14 открыл почту работодателя, в 09:40 — сайт клиники, в 12:02 — сервис поиска работы». Причём собирается пассивно, без участия сайтов и без единого изменения в трафике.

Аналогия

Открытый DNS — это когда ты в справочном бюро вокзала громко спрашиваешь: «Как пройти к дому Иванова на Садовой, 12?» Разговор с самим Ивановым потом может быть шёпотом, но вся очередь уже знает, к кому ты идёшь. Шифрование DNS — это записка справочной вместо крика. А шифрование имени в TLS (ECH) — это когда ты ещё и не произносишь адрес вслух, подходя к подъезду.

Что видит наблюдатель на стыке: три уровня закрытости

Ни один режим не прячет IP-адрес назначения и объём трафика: это физика маршрутизации, а не свойство протокола.

2. DoT — DNS over TLS (RFC 7858)

Самое прямое решение: взять тот же DNS-обмен и положить его внутрь TLS-сессии. Никакой новой упаковки, никакого HTTP — те же байты запроса и ответа, просто внутри шифрованного канала.

Транспорт: TCP, порт 853. Порт зарезервирован IANA именно под DoT, и клиенты используют его по умолчанию.
Формат: обычное DNS-сообщение с двухбайтовым префиксом длины — как в DNS по TCP.
Кто говорит: stub-резолвер (или ОС целиком) с рекурсивным резолвером. Дальше по дереву резолвер идёт как обычно.
Соединение: держится открытым и переиспользуется. Рукопожатие TLS окупается только при повторных запросах, поэтому одноразовые соединения для DoT — антипаттерн.

Главное свойство DoT — честность на проводе. Отдельный порт означает, что администратор сети видит, кто и куда шифрует DNS, и может это разрешить или запретить осознанно. То же свойство оборачивается слабостью там, где шифрование хотят подавить: одно правило фильтра deny tcp any any eq 853 — и DoT в этой сети нет.

Ловушка новичка

Многие думают, что «DoT — это DNS-запрос, зашифрованный от резолвера». Нет: резолвер читает запрос полностью, иначе он не смог бы на него ответить. Шифруется канал до резолвера, то есть защита от наблюдателя по пути, а не от адресата. Вопрос доверия к самому резолверу шифрованием транспорта не решается — его решает выбор резолвера и, отчасти, ODoH.

3. DoH — DNS over HTTPS (RFC 8484)

DoH решает ту же задачу приватности, но с другой инженерной целью: сделать DNS-трафик неотличимым от обычного веб-трафика и доступным прямо из приложения, без обращения к системному резолверу.

Транспорт: HTTPS, порт 443 — тот же, что у любого сайта.
Упаковка: DNS-сообщение кладётся телом HTTP-обмена с типом содержимого application/dns-message.
Методы: POST кладёт сообщение в тело; GET передаёт его в параметре dns= в кодировке base64url, что позволяет кэшировать ответ средствами HTTP.
Адрес точки входа: задаётся URI-шаблоном. Путь /dns-query — конвенция, закреплённая механизмом обнаружения (см. раздел 6), а не жёсткое требование самого RFC 8484.

Ключевое следствие — DoH нельзя выключить фильтром по порту. Соединение к резолверу выглядит как соединение к сайту: тот же 443, тот же TLS, та же форма. Отличить его можно только по адресу назначения (список известных публичных резолверов) или по поведенческим признакам — и то и другое ненадёжно и обходится сменой резолвера.

Второе следствие серьёзнее для эксплуатации: DoH обычно включает приложение, а не операционная система. Браузер с собственным DoH-резолвером перестаёт спрашивать ОС — и мимо него проходят и корпоративный блок-лист, и split-horizon-зона с внутренними именами, и файл hosts в части сценариев. Именно это стоит за заявкой из начала урока.

4. DoQ — DNS over QUIC (RFC 9250)

DoT наследует от TCP неприятное свойство: потерянный сегмент задерживает всё, что пришло после него, — блокировка головы очереди. Для DNS это заметно, потому что запросы мелкие, независимые и их много. DoQ переносит тот же обмен на QUIC.

Транспорт: QUIC поверх UDP, порт 853 (тот же номер, но UDP — это другой порт, чем TCP/853 у DoT).
Что даёт: шифрование уровня TLS, но независимые потоки — потеря пакета одного запроса не тормозит остальные; восстановление потерь эффективнее, чем у голого UDP.
Где применяется: и на участке stub → рекурсивный, и на участке рекурсивный → авторитетный.

По видимости для оператора DoQ ближе к DoT, чем к DoH: у него свой порт, его видно и можно подавить. Это не недостаток протокола — это следствие честного выделения номера.

Три способа увезти один и тот же DNS-обмен

Содержимое во всех трёх случаях одно и то же — DNS-сообщение. Отличается только конверт и, как следствие, заметность на стыке.

5. Что выбирать: сравнение по задачам

Свойство	DoT (7858)	DoH (8484)	DoQ (9250)
Порт по умолчанию	853/TCP	443/TCP	853/UDP (QUIC)
Отличим на стыке	да, по порту	нет, сливается с HTTPS	да, по порту
Блокировка одним правилом	тривиальна	практически невозможна	тривиальна
Блокировка головы очереди	есть (TCP)	есть у HTTP/2, нет у HTTP/3	нет
Кто обычно включает	операционная система	приложение (браузер)	ОС и резолверы
Кэширование средствами HTTP	нет	да, для метода GET	нет

Практический вывод для трёх ролей. Администратору корпоративной сети удобнее DoT: его видно, им можно управлять, он настраивается централизованно в ОС. Пользователю в недоверенной сети практичнее DoH: его труднее подавить. Оператору и держателю резолвера интересен DoQ: он снимает задержки на потерях и лучше держит всплески.

6. Как клиент вообще узнаёт про шифрованный резолвер

Прописать адрес руками — не масштабируется. IETF закрыл вопрос двумя документами, опубликованными в ноябре 2023 года. Их часто путают, хотя они решают задачу с разных сторон.

DDR — RFC 9462, обнаружение через сам DNS. У клиента уже есть адрес обычного резолвера (из DHCP или настроек). Он спрашивает у него запись SVCB для служебного имени _dns.resolver.arpa и получает описание шифрованных точек входа: протокол, порт, путь. Ничего в сети менять не надо — работает поверх существующей конфигурации.

DNR — RFC 9463, объявление от сети. Сеть сама сообщает адрес шифрованного резолвера через опции DHCP и через Router Advertisement в IPv6. Это путь администратора: он декларирует «вот наш DoH/DoT/DoQ», и клиенты подхватывают его без обнаружения через DNS.

Проверка подлинности. В обоих случаях клиент обязан убедиться, что шифрованная точка входа принадлежит тому же оператору резолвера — иначе обнаружение превращается в удобный способ увести клиента на чужой сервер.

Для инженера СПД здесь важное следствие: DNR — это инструмент оператора. Если абонентам нужен ваш резолвер, объявляйте его шифрованную точку входа через DHCP, а не пытайтесь запретить чужие. Запреты обходятся, объявление — работает.

7. ODoH — развязать «кто» и «что» (RFC 9230)

Шифрование транспорта убирает наблюдателя с провода, но не убирает знание у самого резолвера: он по-прежнему видит и адрес клиента, и содержимое запроса. Экспериментальный документ RFC 9230, опубликованный в июне 2022 года, предлагает разнести эти два знания по разным сторонам.

Клиент шифрует запрос ключом цели. Не ключом прокси — именно целевого резолвера. Получается конверт, который прокси открыть не может.

Прокси пересылает конверт. Прокси видит адрес клиента, но не видит имени внутри. Для цели обращение приходит от прокси.

Цель расшифровывает и отвечает. Целевой резолвер знает, что спрашивают, но не знает, кто именно: адрес клиента до него не доходит.

Ответ идёт обратно тем же путём. Он тоже зашифрован для клиента, поэтому прокси не читает и ответ.

Где здесь граница гарантии

Развязка держится ровно до тех пор, пока прокси и цель не сговорились и не принадлежат одному владельцу. Это не математическая гарантия, а организационная: два независимых оператора вместо одного. Поэтому ODoH — Experimental, а не Standards Track, и поэтому выбор пары «прокси + цель» здесь важнее выбора одного резолвера в обычном DoH.

8. ECH — последний кирпич (RFC 9849)

Теперь ответ на вопрос из начала урока. Ты включил DoH: DNS-запрос не виден. Клиент получил адрес и открывает TLS уже к самому сайту. И в первом же сообщении — ClientHello — кладёт расширение SNI с именем сервера открытым текстом: оно нужно серверу, чтобы выбрать сертификат, а зашифровать его нечем, ключ ещё не согласован.

Наблюдателю не нужен твой DNS. Он читает SNI — и знает имя сайта. Шифрование DNS в одиночку закрывает форточку при распахнутой двери.

Encrypted Client Hello закрывает и дверь. Механизм получил номер RFC 9849 и статус Proposed Standard в марте 2026 года. Идея: клиент шифрует настоящий ClientHello открытым ключом сервера и вкладывает его внутрь внешнего, «обложечного» ClientHello с нейтральным именем. Наблюдатель видит обращение к обложке, сервер разворачивает вложенное сообщение и обслуживает настоящее имя.

Откуда берётся ключ? Из DNS. RFC 9460 ввёл записи SVCB и HTTPS и держит для этого параметр с номером 5 и именем ech. Отсюда — жёсткая связка, которая и объясняет, почему два сюжета этого урока нельзя разделить:

Круг замыкается

ECH нужен, чтобы шифрование DNS имело смысл — иначе имя утекает через SNI. Шифрование DNS нужно, чтобы ECH имел смысл — иначе наблюдатель подменит или вырежет запись с ключом, клиент не получит ECHConfig и честно откатится на открытый SNI. Работают только вместе; по отдельности каждый закрывает половину.

9. Что это меняет для инженера СПД и админа сети

Разберём последствия по ролям — без «приватность победила» и без «интернет сломался».

Фильтрация по DNS перестаёт быть надёжной. Родительский контроль, корпоративные блок-листы, RPZ на резолвере — всё это работало, пока клиент спрашивал ваш резолвер. Браузер с собственным DoH этого не делает.
Split-horizon ломается первым. Внутренние имена, которые резолвятся только вашим сервером, у ушедшего клиента не резолвятся вовсе. Симптом узнаваемый: nslookup (идёт через ОС) находит имя, браузер (идёт через свой DoH) — нет.
Статистика DNS-запросов на резолвере перестаёт отражать реальность. Мониторинг «топ запрашиваемых доменов» тихо теряет часть абонентов и показывает неполную картину как полную — это опаснее, чем не иметь статистики вовсе.
Запрет 853 подавляет DoT и DoQ, но не DoH. Результат — вы вытесняете управляемый и видимый шифрованный DNS, оставляя невидимый. Это ухудшает вашу же наблюдаемость.
Рабочий ответ — объявить свой резолвер, а не запрещать чужие. Поднимите DoH/DoT на своём резолвере и объявите его через DNR; в корпоративной сети — раздайте политику браузера. Клиент, у которого есть штатный шифрованный резолвер, обычно и остаётся на нём.

10. Плейбук: «в браузере имя не резолвится, в консоли резолвится»

Порядок — от самой дешёвой проверки к самой дорогой. Каждый шаг либо закрывает гипотезу, либо сужает круг.

Шаг 1. Развести резолверы. Сравни nslookup имя (идёт через системный резолвер) и открытие имени в браузере. Расхождение — почти наверняка браузер ушёл на собственный DoH. Стоимость проверки: 10 секунд.

Шаг 2. Посмотреть на клиента. В браузере — страница внутренней диагностики сети, где видно, какой защищённый DNS используется. В Windows — Get-DnsClientDohServerAddress, в Linux — resolvectl status. Здесь видно и адрес, и режим.

Шаг 3. Проверить, куда реально идёт трафик. На стыке или на хосте посмотри соединения: 853 — DoT или DoQ; 443 к адресу известного публичного резолвера — DoH. Отсутствие 53/UDP при живом браузере — сильный признак.

Шаг 4. Проверить свою сторону. Резолвится ли имя на самом корпоративном резолвере, отдаётся ли SVCB для _dns.resolver.arpa, объявляется ли DNR по DHCP. Часто выясняется, что штатной шифрованной точки входа просто нет — и клиенту некуда возвращаться.

Шаг 5. Закрепить решением, а не запретом. Поднять DoH/DoT на своём резолвере, объявить его, а для управляемых машин — задать политикой. Запрет 853 оставить только как осознанную меру, понимая, что DoH он не трогает.

11. Ловушки и заблуждения

«Включил DoH — провайдер больше ничего не видит». Видит: адрес назначения, объём и тайминг трафика, а до ECH — ещё и имя сайта в SNI. Что действительно исчезает — детальный журнал имён с привязкой ко времени, собираемый пассивно с порта 53.

«DoT и DoH — это разные степени шифрования». Степень одна и та же: TLS. Отличается только конверт и, как следствие, заметность. Выбор между ними — про управляемость и обходимость, а не про стойкость.

«DNSSEC делает шифрование DNS ненужным». Это ортогональные вещи. DNSSEC подписывает содержимое ответа и защищает от подмены, но подписанный ответ читается наблюдателем так же свободно, как неподписанный. Шифрование прячет, подпись подтверждает; одно другое не заменяет.

«ODoH — это DoH с двойным шифрованием». Дело не в количестве слоёв, а в разделении знания между двумя независимыми сторонами. Два слоя шифрования до одного и того же сервера не дали бы ничего.

«Хватит запретить 853, и абоненты вернутся на наш резолвер». Вернутся те, кто использовал DoT. Пользователи DoH не заметят изменения. Итог — вы ослепили себя сильнее, чем их.

12. Мини-лаба: попробуй прямо сейчас

Всё выполняется на своей машине, ничего настраивать в сети не нужно.

Сделай DoH-запрос руками. В терминале:
```
curl -sS -H 'accept: application/dns-message' \
  'https://cloudflare-dns.com/dns-query?name=example.com&type=A' \
  -H 'accept: application/dns-json'
```
Ожидаемый результат: JSON с полем Answer и адресом. Обрати внимание: обычный HTTPS-запрос, никакого порта 53. Именно так это выглядит и для наблюдателя.
Посмотри, что отдаёт запись HTTPS. dig HTTPS cloudflare.com (или nslookup -type=HTTPS cloudflare.com). Ожидаемый результат: строка с параметрами сервиса; если сайт публикует ECHConfig, увидишь параметр ech с длинной base64-строкой — это и есть ключ для шифрования ClientHello.
Проверь, чем резолвит твоя ОС. Linux: resolvectl status — смотри строки про DNS-серверы и режим DoT. Windows PowerShell: Get-DnsClientDohServerAddress. Ожидаемый результат: список известных системе шифрованных резолверов; пустой список означает, что ОС ходит открытым DNS.
Сравни с браузером. Открой настройки безопасности браузера и найди «защищённый DNS». Ожидаемый результат: у большинства современных браузеров он включён и указывает на публичный резолвер — то есть не тот, который показал шаг 3. Это и есть расхождение из плейбука.

13. Словарик урока

Термин	English	Что означает
DoT	DNS over TLS	DNS внутри TLS-сессии, TCP-порт 853 (RFC 7858)
DoH	DNS over HTTPS	DNS телом HTTP-обмена, порт 443 (RFC 8484)
DoQ	DNS over QUIC	DNS поверх QUIC, UDP-порт 853 (RFC 9250)
ODoH	Oblivious DoH	Прокси + цель: никто не знает пару «кто и что» (RFC 9230)
ECH	Encrypted Client Hello	Шифрование ClientHello, включая SNI (RFC 9849)
ECHConfig	ECH configuration	Ключ и параметры ECH, публикуемые в записи HTTPS
SVCB / HTTPS RR	service binding record	Записи параметров подключения к сервису (RFC 9460)
DDR	Discovery of Designated Resolvers	Поиск шифрованной точки входа через сам DNS (RFC 9462)
DNR	Discovery of Network-designated Resolvers	Объявление резолвера сетью по DHCP и RA (RFC 9463)
SNI	Server Name Indication	Имя сервера в ClientHello; до ECH — открытым текстом
Split-horizon	split-horizon DNS	Разные ответы для внутренних и внешних клиентов

14. Задачи самопроверки

Реши сам, потом раскрой ответ.

1. В офисе закрыли 853/TCP. Через день часть сотрудников всё ещё обходит блок-лист. Что произошло и что делать?

Закрытие 853 подавило DoT и DoQ, но не DoH: он идёт по 443 и по порту неотличим от обычного HTTPS. Решение не в новых запретах, а в том, чтобы дать штатный путь: поднять DoH/DoT на корпоративном резолвере, объявить его через DNR и задать политикой браузера. Тогда шифрованный DNS останется, но пойдёт через сервер, где живёт блок-лист.

2. Клиент жалуется: внутренний портал не открывается в браузере, но nslookup его находит. Твоя первая гипотеза?

Браузер использует собственный DoH-резолвер и не видит внутреннюю зону split-horizon, а nslookup идёт через системный резолвер, который её видит. Проверяется за минуту настройками защищённого DNS в браузере. Лечение — либо исключение для внутренних имён, либо перевод браузера на корпоративную шифрованную точку входа.

3. Ты включил и DoH, и ECH. Что всё ещё видит оператор?

IP-адрес назначения, объём переданных данных и тайминг. Этого достаточно, чтобы понять факт обращения к инфраструктуре конкретного провайдера хостинга, а при выделенном адресе — и к конкретному сайту. Скрыто содержимое запроса и имя сервера, но не сам факт и направление соединения: маршрутизация без адреса назначения невозможна.

4. Почему ECH не спасает, если DNS-запись с ключом подменена по пути?

Ключ ECH клиент берёт из записи HTTPS в DNS. Если наблюдатель вырезал или подменил эту запись, клиент не получает ECHConfig и по правилам совместимости открывает соединение с обычным открытым SNI. Поэтому ECH требует доверенного канала до резолвера — то есть шифрованного DNS. Два механизма работают только в паре.

5. Резолвер оператора обслуживает 200 тысяч абонентов, на потерях растёт задержка ответов. DoT или DoQ?

DoQ. У DoT транспорт — TCP, и потеря одного сегмента задерживает всё, что пришло следом, хотя DNS-запросы друг от друга не зависят. QUIC даёт независимые потоки и более эффективное восстановление потерь, при том же уровне шифрования. Заметность на стыке у обоих одинаковая: у DoQ тоже свой порт 853, только UDP.

15. Источники

RFC 7858 — Specification for DNS over Transport Layer Security (TLS) — DoT, порт 853
RFC 8484 — DNS Queries over HTTPS (DoH) — тип содержимого application/dns-message, методы GET и POST
RFC 9250 — DNS over Dedicated QUIC Connections — DoQ
RFC 9230 — Oblivious DNS over HTTPS — Experimental, июнь 2022
RFC 9460 — Service Binding and Parameter Specification via the DNS (SVCB и HTTPS RR) — реестр SvcParamKeys, ключ 5 «ech»
RFC 9462 — Discovery of Designated Resolvers (DDR) — ноябрь 2023
RFC 9463 — DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR) — ноябрь 2023
RFC 9849 — TLS Encrypted Client Hello — Proposed Standard, март 2026
IANA Service Name and Transport Protocol Port Number Registry — закрепление порта 853

Открытый DNS отдаёт наблюдателю имя, тип запроса, адрес спрашивающего и время — этого хватает на полную историю просмотров. DoT (853/TCP), DoH (443/TCP) и DoQ (853/UDP) возят один и тот же DNS в разных конвертах: DoT и DoQ видно и можно подавить одним правилом, DoH намеренно неотличим от обычного HTTPS. Клиент находит шифрованную точку входа через DDR (по DNS) или получает её от сети через DNR (по DHCP и RA), а ODoH дополнительно разводит знание «кто» и «что» между прокси и целью. Но пока имя сервера уходит открытым в SNI, шифрование DNS закрывает лишь половину: вторую половину закрывает ECH, чей ключ публикуется в записи HTTPS — то есть в самом DNS. Для оператора практический вывод один: объявлять собственный шифрованный резолвер работает, запрещать чужие — нет.

Что дальше

Этим уроком путь HTTPS-запроса закрыт целиком — от резолва имени до ответа приложения и обратно, включая то, как этот путь прячут от наблюдателя. Дальше начинается этап II маршрута: та же инфраструктура, но глазами того, кто её эксплуатирует и автоматизирует. Возвращайся к карте маршрута — и не забывай про повторение: материал этого трека забывается быстрее прочего, потому что применяется реже.