DoT - технический разбор - 2026

Published: 2026-08-19

DoT (DNS over TLS) — протокол шифрования DNS-трафика поверх транспортного уровня безопасности (TLS), стандартизированный в RFC 7858 (май 2016, Standards Track, рабочая группа IETF DPRIVE). DoT решает фундаментальную проблему классического DNS: с момента создания протокола в 1983 году (RFC 1034/1035) все DNS-запросы передаются в открытом виде, что делает их уязвимыми для прослушивания и модификации любым атакующим, имеющим доступ к сетевому каналу. Эта статья представляет собой максимально полный технический разбор DoT: от базового протокола до профилей аутентификации, вопросов производительности, противодействия трафик-анализу, сравнения с альтернативами (DoH, DoQ) и практических рекомендаций операторам DNS-сервисов.

Введение

DNS (Domain Name System) — одна из самых старых и фундаментальных служб интернета. Почти каждый запрос, который делает пользователь — открытие веб-страницы, отправка почты, подключение к мессенджеру — начинается с DNS-разрешения имени. При этом по умолчанию DNS-запросы и ответы передаются без какого-либо шифрования через UDP-пакеты на порту 53. Это означает, что любой наблюдатель на пути следования трафика (провайдер, оператор Wi-Fi, администратор сети, злоумышленник) может:

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

Проблемы приватности DNS подробно разбираются в RFC 7626 (DNS Privacy Considerations). В ответ на эти угрозы IETF организовала рабочую группу DPRIVE (DNS PRIVate Exchange), результатом работы которой стал ряд протоколов, из которых основными являются:

DoT (DNS over TLS) — RFC 7858, шифрование поверх TCP+TLS, порт 853;
DoDTLS (DNS over DTLS) — RFC 8094, экспериментальный, шифрование поверх DTLS;
DoH (DNS over HTTPS) — RFC 8484, шифрование поверх HTTP/2 или HTTP/3, порт 443;
DoQ (DNS over QUIC) — RFC 9250, шифрование поверх QUIC v1, порт 853/UDP.

Важно сразу отметить фундаментальное различие между DoT и DNSSEC. DNSSEC (RFC 4033) обеспечивает целостность и аутентичность DNS-данных — он позволяет клиенту проверить, что ответ действительно подписан владельцем зоны, но намеренно не защищает приватность: DNSSEC-запросы и ответы так же видны наблюдателю, как и обычные. DoT, наоборот, решает задачу конфиденциальности — скрывает содержимое запросов от посторонних, но не доказывает подлинность данных. Эти два механизма независимы и дополняют друг друга; в RFC 7858 прямо подчёркивается: «использование одного не уменьшает необходимости и полезности другого».

Область применения DoT — прежде всего сегмент «stub resolver → рекурсивный резолвер», то есть путь от конечного устройства пользователя до рекурсивного DNS-сервера, который разрешает имена. Согласно уставу рабочей группы DPRIVE, применение протокола на сегменте «рекурсивный → авторитативный» формально находится вне скоупа стандарта, хотя ничего не мешает использовать его и там.

Исторический контекст и эволюция

DNS без защиты

Классический DNS (RFC 1034, RFC 1035) был разработан в эпоху, когда интернет считался доверенной средой. Протокол не предусматривал шифрования: сообщения передаются в открытом виде, длина ответа по UDP ограничена 512 байтами (без расширения EDNS0, RFC 6891), а сопоставление запросов и ответов осуществляется по 16-битному идентификатору транзакции (Message ID). Отсутствие криптографии породило целый класс атак: DNS spoofing, DNS cache poisoning (уязвимость Камински, 2008), DNS rebinding, перехват запросов на уровне провайдера.

DNSSEC, появившийся в середине 2000-х, решил задачу целостности, но явно оставил приватность за скобками: подписанные зоны видны любому наблюдателю, а подписывание не скрывает ни QNAME (запрашиваемое имя), ни типы записей. Более того, распространение DNSSEC сделало DNS-ответы существенно больше (NXDOMAIN с NSEC3-цепочками почти всегда превышает 512 байт), что усилило зависимость от TCP-транспорта — и это сыграло важную роль в появлении DoT.

Предшественники и альтернативные попытки

До появления DoT предпринимались и другие попытки шифровать DNS, перечисленные в RFC 7858:

DNSCurve — шифрование с использованием криптографии на эллиптических кривых, не получило широкого распространения;
DNSCrypt — протокол шифрования DNS-запросов, используемый рядом публичных резолверов, но не стандартизированный в IETF;
Confidential DNS — ранняя концепция конфиденциального DNS;
IPSECA — применение IPsec для защиты DNS-трафика.

Рабочая группа DPRIVE, помимо TLS, рассматривала также DNS over DTLS (проект стал RFC 8094). Примечательна история отклонения идеи «STARTTLS для DNS»: ранние черновики предлагали выставлять бит «TLS OK» в EDNS(0)-флагах и использовать «dummy-запрос» (имя STARTTLS, тип TXT, класс CH) для согласования TLS. Как поясняется в разделе 7 RFC 7858 (Design Evolution), от этой схемы отказались по трём причинам:

бит «TLS OK» делает downgrade-атаки тривиальными и неотличимыми от неисправных middlebox-устройств;
dummy-запрос добавляет лишний RTT задержки;
неопределённость во взаимодействии с middlebox.

Аналогично был отклонён вариант «DNS over DTLS на порту 53»: сервер, не поддерживающий DTLS, интерпретировал бы DTLS-запрос как обычный DNS-ответ (бит QR=1), что приводит к нежелательным коллизиям. Выделенный well-known порт для TLS позволил избежать и лишней латентности, и неверной интерпретации.

Хронология ключевых стандартов

Документ	Название	Статус	Год
RFC 7858	DNS over TLS	Standards Track	2016
RFC 7766	DNS Transport over TCP	Standards Track	2016
RFC 7828	edns-tcp-keepalive	Standards Track	2016
RFC 7830	EDNS(0) Padding Option	Standards Track	2016
RFC 8094	DNS over DTLS	Experimental	2017
RFC 8310	Usage Profiles for DoT/DoDTLS	Standards Track	2018
RFC 8467	Padding Policies for EDNS(0)	Experimental	2018
RFC 8484	DNS over HTTPS (DoH)	Proposed Standard	2018
RFC 8932	Recommendations for DNS Privacy	BCP 232	2020
RFC 9102	TLS DNSSEC Chain Extension	Standards Track	2021
RFC 9250	DNS over QUIC (DoQ)	Standards Track	2022

Основной стандарт: RFC 7858

RFC 7858 «Specification for DNS over Transport Layer Security (TLS)» — ядро DoT. Документ определяет, как устанавливать, использовать и закрывать защищённые DNS-сессии, и содержит обязательные требования (MUST/SHOULD) для клиентов и серверов. Рассмотрим его положения максимально подробно.

Установление сессии и порт 853

По умолчанию DNS-сервер, поддерживающий DoT, обязан (MUST) слушать TCP-соединения на порту 853 — если только он не имеет взаимного соглашения с клиентами об использовании другого порта. Аналогичное требование предъявляется к клиенту: он обязан (MUST) устанавливать TCP-соединение на порт 853, если с сервером не согласован иной порт.

Ключевые нормативные положения:

использование порта, отличного от 853, требует взаимного соглашения — и клиент, и сервер должны иметь соответствующую конфигурационную опцию; никакого автоматического обнаружения альтернативного порта протоколом не предусмотрено;
альтернативный порт MUST NOT быть портом 53, но может принадлежать к диапазону «first-come, first-served» по классификации IANA;
первый обмен данными на TCP-соединении MUST быть началом TLS-handshake по процедурам RFC 5246 (TLS 1.2) с учётом рекомендаций BCP 195 (RFC 7525).

Запрет на порт 53 имеет принципиальный характер: он исключает двусмысленность «TLS или не TLS» на одном порту и снижает риск downgrade-атак. Если бы DoT и обычный DNS делили порт 53, атакующий мог бы заставить клиента молча переключиться с зашифрованного на открытый режим.

Запрет cleartext-трафика

RFC 7858 содержит жёсткие требования по недопущению передачи открытых DNS-сообщений по каналам DoT:

DNS-клиенты и серверы MUST NOT использовать порт 853 для передачи cleartext DNS-сообщений;
клиенты MUST NOT отправлять, а серверы MUST NOT отвечать на незашифрованные DNS-сообщения на любом порту, выделенном под DoT — в том числе после неудавшегося TLS-handshake.

Обоснование: смешение защищённых и незащищённых данных создаёт серьёзные проблемы безопасности, поэтому TCP-соединения на порту, выделенном под DoT, зарезервированы исключительно для зашифрованной связи. Это же правило действует при использовании TCP Fast Open: при переустановке соединения клиент и сервер должны немедленно начинать или возобновлять TLS-handshake, не обмениваясь открытым DNS.

Дополнительная мера против downgrade-атак: клиенты SHOULD запоминать IP-адреса серверов, не поддерживающих DoT (включая таймауты, отказы в соединении и сбои TLS-handshake), и не запрашивать у них DoT в течение разумного периода — например, одного часа на сервер.

TLS-handshake и аутентификация

После установления TCP-соединения клиент переходит к TLS-handshake, следуя лучшим практикам BCP 195 (RFC 7525). RFC 7858 сознательно не предлагает новых механизмов аутентификации — «этот документ не предлагает новых идей аутентификации». То, как клиент аутентифицирует сервер, зависит от выбранного профиля приватности (подробнее — в разделах ниже):

при профиле Opportunistic Privacy клиент может вообще не требовать аутентификации сервера;
при профиле Out-of-Band Key-Pinned Privacy клиент использует доверенный набор SPKI-отпечатков (SPKI Fingerprint pin set).

Из BCP 195 (RFC 7525), на которое ссылается RFC 7858, вытекают обязательные требования к TLS-конфигурации:

MUST NOT: SSLv2, SSLv3; SHOULD NOT: TLS 1.0 и 1.1 (когда доступна более новая версия);
MUST поддерживать и предпочитать TLS 1.2 (на сегодняшний день — TLS 1.3, RFC 8446);
MUST NOT: NULL-шифры, RC4, шифры силой менее 112 бит, export-level шифры (40/56 бит), static RSA;
MUST поддерживать и предпочитать шифры с forward secrecy (DHE/ECDHE): например, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;
SHOULD отключать TLS-компрессию (защита от атак класса CRIME);
клиенты MUST NOT выполнять fallback ниже защищённых версий при downgrade;
renegotiation — только с расширением renegotiation_info (RFC 5746);
TLS-реализации MUST поддерживать расширение SNI (Server Name Indication) для протоколов, которым оно полезно; для DoT применение SNI — вопрос локальной политики (SNI передаётся в открытом виде, см. раздел об анализе угроз).

Фреймирование сообщений

Поскольку DoT работает поверх TCP, а классический DNS — потоковый протокол, каждое сообщение должно быть разграничено. RFC 7858 требует (MUST), чтобы все сообщения — запросы и ответы — в установленной TLS-сессии использовали двухоктетное поле длины, описанное в разделе 4.2.2 RFC 1035.

Техническая деталь из RFC 1035: сообщению предшествует двухбайтовое поле длины, которое задаёт длину сообщения без учёта самого поля длины. Поле — беззнаковое 16-битное число в сетевом порядке байт (big-endian). Максимальная длина DNS-сообщения по TCP/TLS — 65535 байт.

Требование эффективности: клиенты и серверы SHOULD передавать поле длины и само сообщение TCP-стекам одним вызовом записи (например, одним системным вызовом write()), чтобы увеличить вероятность попадания всех данных в один TCP-сегмент. Причина — исторические проблемы реализаций: некоторые серверы вели себя некорректно, если первый read() с TCP-уровня не содержал и поле длины, и всё сообщение целиком, вплоть до обрыва сессии. RFC 7766 уточняет: DNS-серверы MUST NOT закрывать соединение только потому, что первый read не содержит всего DNS-сообщения.

Дополнительное требование безопасности: серверы SHOULD сбрасывать idle-таймер только при получении полного DNS-сообщения, а не любого сегмента — защита от slow-read атаки, при которой злоумышленник удерживает соединение в полуоткрытом состоянии, передавая данные по одному байту.

Pipelining и сопоставление ответов

Для минимизации задержек RFC 7858 требует (SHOULD) конвейеризации запросов: клиент не должен ждать ответа на предыдущий запрос перед отправкой следующего. Серверы, особенно рекурсивные, MUST ожидать приёма конвейеризованных запросов, SHOULD обрабатывать их конкурентно (как UDP-запросы) и отвечать на все.

Поскольку ответы могут приходить в порядке, отличном от порядка запросов (out-of-order processing), критически важным становится сопоставление ответов с запросами:

клиенты MUST сопоставлять ответы с выдающимися запросами на том же TLS-соединении по Message ID;
если ответ содержит Question Section, клиент MUST дополнительно проверять поля QNAME, QCLASS и QTYPE;
при повторной отправке запросов клиенты MUST NOT переиспользовать Message ID невыполненного (in-flight) запроса — иначе возможны коллизии при out-of-order обработке на сервере.

В RFC 7766 подчёркивается: stub- и recursive-резолверы MUST уметь обрабатывать ответы, приходящие не в порядке отправки запросов, независимо от используемого транспорта. Некорректное сопоставление ответов может иметь серьёзные последствия для интероперабельности.

Переиспользование соединений и закрытие

Одно из самых важных отличий DoT от классического DNS-over-TCP: успешное согласование TLS означает готовность обеих сторон держать idle-соединения открытыми, независимо от таймаутов и рекомендаций для DNS-over-TCP без TLS. То есть:

клиенты и серверы SHOULD NOT немедленно закрывать соединение после каждого ответа;
соединения SHOULD переиспользоваться для последующих запросов, пока есть ресурсы;
клиенты SHOULD переиспользовать одно TCP-соединение к рекурсивному резолверу (альтернатива — локальный кэширующий резолвер с DoT, держащий системное соединение наружу).

RFC не даёт конкретных рекомендаций по значениям таймаутов для idle-соединений; полезные ориентиры даёт RFC 7828 (edns-tcp-keepalive): EDNS0-опция с code 11, формат «OPTION-CODE (2 октета) | OPTION-LENGTH (2 октета) | TIMEOUT (0 или 2 октета)», таймаут задаётся в единицах 100 мс. Клиенты MUST NOT включать эту опцию в UDP-запросы, но MAY — в TCP; ответ сервера с TIMEOUT=0 означает, что клиенту следует не отправлять больше запросов и инициировать закрытие.

Порядок закрытия соединений:

серверы SHOULD при закрытии использовать TLS close_notify — это переносит TCP-состояние TIME-WAIT на клиентов;
close_notify обязателен по RFC 5246 §7.2.1: каждая сторона обязана отправить close_notify перед закрытием стороны записи; другая сторона обязана ответить собственным close_notify и немедленно закрыть соединение, отбрасывая отложенные записи; данные, полученные после closure alert, игнорируются — это защита от truncation-атак;
клиенты и серверы, держащие idle-соединения открытыми, MUST быть устойчивы к закрытию соединения любой из сторон;
серверы MAY закрыть соединение в любой момент (например, при нехватке ресурсов);
клиенты MUST обрабатывать резкие закрытия (abrupt closes) и быть готовы переустанавливать соединения и повторять запросы;
клиенты SHOULD повторять неотвеченные запросы, если соединение закрылось до получения всех ответов;
если сервер обнаружил, что клиент закрыл сессию до отправки всех ответов, он MUST NOT пытаться их отправить (но MAY закэшировать).

Ограничение числа соединений (RFC 7766 §6.2.2): для пары клиент/сервер рекомендуется не более одного соединения для регулярных запросов, одного для zone transfers и одного на каждый протокол поверх TCP. Серверы MAY ограничивать число соединений с одного IP/подсети, но лимиты должны быть существенно мягче клиентских ориентиров (за одним IP может стоять NAT и несколько резолверов).

Профили приватности

RFC 7858 определяет два профиля использования:

1. Opportunistic Privacy Profile (оппортунистическая приватность). Аналогия — opportunistic security в SMTP (RFC 7435): «человек не требует приватности, но желает её, когда это возможно». Клиент может узнать о TLS-резолвере из недоверенного источника (например, DHCP-опции DNS-сервера по RFC 3646), после чего попытаться установить DoT-соединение на 853. С таким обнаруженным сервером клиент может как проверять его подлинность, так и не проверять. Такой выбор максимизирует доступность и производительность, но оставляет клиента уязвимым для on-path атак, снимающих приватность. Итоговая гарантия профиля: «оппортунистическая приватность доступна любому клиенту, но обеспечивает приватность только при отсутствии активных on-path атакующих».

2. Out-of-Band Key-Pinned Privacy Profile (приватность с внеполосным пинингом ключей). Применим там, где между клиентом и сервером уже существует установленное доверие (корпоративный stub-to-recursive, договорные отношения с провайдером DNS-сервиса, публичный резолвер). Клиент получает сильные гарантии приватности, подключаясь только к серверам, которые может аутентифицировать:

операторы должны предоставлять пины, специфичные для сервиса: публичные ключи конечного субъекта (end entity) или ключи специализированного частного CA — но не ключи публичного CA общего назначения;
клиент аутентифицирует сервер сопоставлением набора SPKI-отпечатков по аналогии с RFC 7469 (HPKP);
администраторы SHOULD разворачивать backup pin вместе с primary pin для бесшовной ротации ключей;
проверка: после TLS-handshake клиент вычисляет SPKI-отпечатки публичных ключей из валидированной сертификатной цепочки сервера (или из raw public key, если сервер его предоставляет); при точном совпадении хотя бы с одним пином соединение продолжается; в противном случае несовпадение SPKI-проверки MUST трактоваться как невосстановимая ошибка (non-recoverable error);
обязательные алгоритмы: отпечаток вычисляется как SHA-256 (RFC 6234) от DER-кодированного ASN.1-представления SPKI X.509-сертификата; представление отпечатка — base64-строка (RFC 4648); дополнительные типы отпечатков MAY поддерживаться.

В Appendix A RFC 7858 приведён практический пример: клиент соединяется на порт 853, сервер присылает цепочку из трёх сертификатов (A, B, C) и подписывает ServerKeyExchange ключом из сертификата A. Клиент последовательно вычисляет SHA-256 от SPKI сертификатов A, B, C и сравнивает с пинами; если ни один SPKI криптографически валидной цепочки не совпал ни с одним пином, клиент закрывает соединение с ошибкой и помечает IP-адрес как нерабочий.

Разница между профилями:

Аспект	Opportunistic	Out-of-Band Key-Pinned
Источник знания о сервере	недоверенный (DHCP и т.п.)	доверенная внеполосная конфигурация
Аутентификация сервера	опциональна	обязательна (SPKI-пины)
Устойчивость к MITM/downgrade	нет	да (несовпадение пина — невосстановимая ошибка)
Поведение при сбое	запоминание сервера ~1 час	MAY агрессивный ретрай

Производительность

Раздел 5 RFC 7858 систематизирует затраты DoT по трём категориям: латентность, состояние (память), обработка (CPU).

Латентность:

по сравнению с UDP, DNS over TCP добавляет один RTT на установку TCP-соединения;
TCP Fast Open (RFC 7413) может устранить этот RTT, если есть информация от предыдущих соединений (данные в SYN);
TLS-handshake добавляет ещё два RTT (в терминах TLS 1.2); итого: UDP = +0 RTT, TCP = +1 RTT, TCP+TLS = +3 RTT;
клиенты и серверы должны поддерживать keepalive (переиспользование) и out-of-order обработку для амортизации затрат на установку соединения;
быстрое возобновление TLS-сессий (RFC 5077) дополнительно снижает задержку установки и избавляет DNS-сервер от хранения per-client состояния (stateless-тикеты);
TLS False Start может дать снижение задержки в определённых ситуациях, но его использование небезопасно без строгого соблюдения дополнительных требований (RFC 7918).

Состояние: connection-oriented TCP требует дополнительного состояния на сервере и в ядре, и в приложении; проблема особенно актуальна для серверов с большим числом клиентов; память-оптимизированный TLS добавляет лишь скромное состояние поверх TCP. Меньшие значения таймаутов уменьшают число одновременных соединений; серверы могут упреждающе закрывать соединения при превышении лимитов ресурсов.

Обработка: алгоритмы TLS-шифрования дают незначительно более высокое использование CPU; серверы могут отказывать новым DoT-клиентам при превышении лимитов обработки.

Число соединений: для минимизации состояния серверов и времени установки клиенты SHOULD минимизировать создание новых TCP-соединений. Использование локального агрегатора DNS-запросов (особого типа форвардера) позволяет держать одно активное DoT-соединение от клиентского компьютера к серверу.

Анализ угроз

RFC 7858 честно очерчивает границы своей защитной модели. Цель DoT — только защита от подслушивания DNS-сообщений (приватность), а не решение всех проблем безопасности DNS. Перечень остаточных рисков:

Атаки на сам TLS — person-in-the-middle и protocol downgrade: общие атаки на TLS. Клиенты и серверы MUST следовать рекомендациям BCP 195. Отслеживание клиентами серверов, известных поддержкой TLS, позволяет обнаруживать downgrade-атаки. Для серверов без истории соединений и видимой поддержки TLS клиент в зависимости от профиля может: (а) попробовать другой сервер, (б) продолжить без TLS, (в) отказаться пересылать запрос.
Middlebox-устройства (RFC 3234) вмешиваются в обычное DNS-разрешение; использование выделенного порта DoT должно избегать такого вмешательства. Клиенты при неудаче TLS могут либо откатиться на незашифрованный DNS, либо подождать и повторить позже (зависит от профиля).
Модификация cleartext-взаимодействий: любые DNS-взаимодействия в открытом виде могут быть изменены MITM-атакующим; поэтому клиенты MAY отбрасывать закэшированную информацию о возможностях сервера, рекламируемую в открытом виде.
Трафик-анализ / side-channel: RFC 7858 не специфицирует средств против известных утечек трафик-анализа. Даже с зашифрованными сообщениями хорошо расположенный наблюдатель может извлечь детали из анализа таймингов и размеров сообщений. Рекомендация — padding (EDNS(0) Padding Option, RFC 7830), однако простые схемы паддинга сами по себе могут быть недостаточны.

Что остаётся видимым наблюдателю на канале DoT: сам факт TCP-соединения на порт 853, IP-адреса клиента и сервера, тайминги, объёмы и длины TLS-записей (база для трафик-анализа), а также открытые поля handshake — в первую очередь SNI, который в TLS 1.2 передаётся в открытом виде в ClientHello. Имена доменов внутри DNS-запросов скрыты.

Профили использования: RFC 8310

RFC 8310 (март 2018, Standards Track) «Usage Profiles for DNS over TLS and DNS over DTLS» уточняет и развивает модель RFC 7858, вводя строгую типологию профилей, механизмы аутентификации и требования к серверам.

Authentication Domain Name (ADN)

ADN — доменное имя, используемое для аутентификации privacy-enabling DNS-сервера. Это DNS-ID, конструируемый клиентом как reference identifier по RFC 6125 для TLS-аутентификации сервера.

Суть проблемы, которую решает ADN: у клиента есть bootstrap-проблема — stub-резолвер обычно знает только IP-адрес DNS-сервера, а для PKIX-аутентификации нужно имя. ADN связывает стабильный, узнаваемый идентификатор с провайдером DNS-услуг. Клиент конструирует ровно один reference identifier — сам ADN — и проверяет его в subjectAltName сертификата. Правила проверки:

клиент MUST проверить полный путь сертификации по RFC 5280;
сравнение ADN — по правилам RFC 6125 §6;
клиент MUST смотреть только на subjectAltName (DNS-ID) и MUST NOT проверять поле Subject.

Источники получения ADN (раздел 7 RFC 8310) — четыре способа:

Full Direct Configuration: ADN и IP получены out-of-band (конфигурационный файл или API клиента).
Direct Configuration of ADN Only: задан только ADN; IP клиент узнаёт через meta-query A/AAAA к недоверенному сетевому резолверу (например, полученному от DHCP по RFC 3646) в режиме Opportunistic Privacy. Атака на meta-query возможна; DNSSEC-валидация может её обнаружить. Клиент MAY кэшировать полученные IP.
Dynamic Discovery: стандартного способа на момент написания RFC не было; при Strict Privacy источник динамического обнаружения MUST считаться безопасным и доверенным; для Opportunistic это требование не действует.
DHCP: стандартный DHCP даёт только IP (RFC 2132 §3.8), но не ADN; RFC не специфицирует DHCP-расширение, но оговаривает, что будущее расширение должно учитывать RFC 7227 §8 и RFC 3315 §23. Для Strict Privacy требуется безопасная связь с DHCP-сервером.

Strict и Opportunistic профили

RFC 8310 формализует два профиля:

Strict Privacy Profile:

шифрование и успешная аутентификация обязательны;
при недоступности — жёсткий отказ (hard failure): «клиент MUST прервать соединения с сервером, когда ни один механизм проверки не успешен»;
«клиент MUST NOT начинать отправку DNS-запросов, пока хотя бы один privacy-enabling сервер не станет доступен»;
клиент MUST NOT в процессе резолвинга конкретного запроса откатываться из Strict в Opportunistic (это обесценило бы защиту);
клиент MUST использовать либо один из источников ADN из раздела 7, либо SPKI pin set по RFC 7858;
при bootstrap через captive portal разрешены техники типа dnssec-trigger, но система MUST оповестить пользователя, что DNS не приватный.

Opportunistic Privacy Profile:

шифрование/аутентификация «по возможности» (Opportunistic Security, RFC 7435);
каскад исходов: A+E (аутентифицированное+зашифрованное) → E (просто зашифрованное) → cleartext;
клиент SHOULD пытаться получить лучший вариант, MAY согласиться на промежуточный и может откатиться на cleartext ради получения ответа (например, если латентность важнее митигации);
клиент, знающий аутентификационную информацию о сервере, SHOULD пытаться аутентифицировать сервер — это позволяет детектировать (не предотвращать) активные атаки: при сбое аутентификации «с точки зрения безопасности следует считать, что идёт активная атака», поэтому алгоритм выбора nameserver может избегать неаутентифицировавшийся сервер при наличии альтернатив;
клиент, реализующий Opportunistic, SHOULD также реализовать Strict;
клиент с DoT/DoDTLS SHOULD NOT быть по умолчанию настроен на только-cleartext.

Таблица защиты от атак (таблица 1 из раздела 5):

Профиль	Соединение	Пассивный атакующий	Активный атакующий
Strict	A+E	защита (P)	защита (P)
Opportunistic	A+E	защита (P)	защита (P)
Opportunistic	E	защита (P)	нет защиты (N), детекция (D)
Opportunistic	cleartext	нет защиты (N), детекция (D)	нет защиты (N), детекция (D)

Шесть механизмов аутентификации

RFC 8310 (таблица 2, раздел 6.3) перечисляет шесть способов установить подлинность сервера:

SPKI pin set + IP (out-of-band, статически) — проверка сравнением SPKI из handshake с пинами; совместимо с raw public keys (RFC 7250); минимальная утечка (SNI не используется при соединении по IP).
ADN + IP (out-of-band, статически) — PKIX-проверка по сертификату.
ADN only — IP динамически через meta-query к network-provided серверу (A/AAAA); утечка meta-query, митигируется DNSSEC-валидацией.
DHCP — оба параметра (ADN+IP) динамически; требует нестандартного DHCP-опциона; для Strict требует доверенного DHCP.
DANE — TLSA через прямые DNS meta-queries; запись MUST быть валидирована DNSSEC по RFC 6698; требует DNSSEC-валидирующий stub.
TLS DNSSEC Chain Extension — цепочку (TLSA + CNAME + external records) передаёт сам сервер в handshake (RFC 9102); меньше латентность, не нужен network-provided DNS-сервер при статическом ADN+IP.

При комбинировании ADN и SPKI pin set клиент SHOULD требовать совпадения обоих механизмов; пины обрабатываются по правилам RFC 7469 §2.6; общий результат аутентификации успешен только при успехе обоих механизмов.

DANE и TLSA

Механизм DANE (DNS-based Authentication of Named Entities) якорит доверие через DNSSEC. TLSA-записи для DoT живут в домене, полученном префиксом перед ADN:

_853._tcp.[ADN] — для TLS;
_853._udp.[ADN] — для DTLS.

Поддерживаются все DANE-опции RFC 6698, включая PKIX-TA(0), PKIX-EE(1), DANE-EE(3); комбинация DANE-EE(3) + selector SPKI(1) + raw public keys (RFC 7250) — режим, где период действия определяется только свойствами TLSA RRset. Операционные аспекты TLSA TTL и сроков подписи — RFC 7671 §13.

Важные ограничения:

DANE требует DNSSEC-валидирующего стуба — без него механизм недоступен (на момент написания RFC такие стубы были редки);
в неподписанной зоне или при отсутствии TLSA цепочка DNSSEC не может быть построена; клиент Strict-профиля должен прервать соединение;
при работе TLS DNSSEC Chain Extension: если цепочка не валидируется — клиент MUST игнорировать её и использовать другие credentials (например, PKIX), иначе — abort;
DNSSEC-валидация способна детектировать атаку на meta-query, что может привести к отсутствию DNS-услуги в обоих профилях.

Требования к серверам и (D)TLS-профиль

Privacy-enabling DNS server (раздел 2 и 4 RFC 8310) обязан:

MUST реализовывать DNS over TLS (RFC 7858);
MAY реализовывать DNS over DTLS (RFC 8094);
SHOULD предлагать хотя бы один credential (PKIX-сертификат для ADN или DNSSEC-валидируемую TLSA-запись);
реализовывать (D)TLS-профиль раздела 9.

(D)TLS Protocol Profile (раздел 9):

MUST следовать RFC 7525 (BCP 195), кроме версии TLS;
MUST реализовывать только (D)TLS 1.2 или новее (TLS 1.3/DTLS 1.3 — опционально);
MUST NOT предлагать/использовать TLS-компрессию (атаки CRIME);
MUST: session resumption без серверного состояния (RFC 5077) — обновление RFC 7858;
MUST: raw public keys (RFC 7250) — уменьшают ServerHello; клиент MUST объявлять поддержку raw public keys только при предварительно сконфигурированном SPKI pin set;
SHOULD: TLS False Start (RFC 7918) и Cached Information Extension (RFC 7924) — пропуск повторной передачи сертификата.

Вопрос ALPN: при деплое DoT и DoH на одном IP требуется использование ALPN-значения «dot» (зарегистрировано в реестре TLS ALPN) — рекомендация RFC 8932 §5.1.3.1.

Fallback-поведение клиентов

Strict Privacy:

сбой аутентификации/шифрования = жёсткий отказ;
никакого отката на cleartext;
запрет деградации внутри запроса;
при временной недоступности (captive portal) — bootstrap по техникам dnssec-trigger с обязательным алертом пользователю.

Opportunistic Privacy:

каскад: A+E → E → cleartext;
Appendix A (не-нормативный): клиент, реализующий и TLS, и DTLS, должен пробовать аутентифицироваться через оба протокола до отказа/отката; Opportunistic-клиент должен перепробовать все доступные серверы (возможно, параллельно), чтобы получить A+E-соединение, прежде чем откатываться;
клиенты обязаны отслеживать и кэшировать, какие серверы поддерживают DoT/DoDTLS и какие ранее аутентифицировались.

Дополнительные требования раздела 11: клиенты SHOULD поддерживать механизмы DANE и SHOULD предоставлять опцию конфигурации, ограничивающую аутентификацию только ими (без fallback на чистую PKIX). Контрмеры трафик-анализу: клиенты и серверы SHOULD реализовать EDNS(0) padding (RFC 7830, политики — RFC 8467); клиенты SHOULD реализовать privacy election через edns-client-subnet (RFC 7871) — при отсутствии опции с SOURCE PREFIX-LENGTH=0 сервер может утечь адрес клиента апстрим-серверам.

DNS поверх TCP: RFC 7766

RFC 7766 (март 2016, Standards Track) заменяет RFC 5966 и обновляет RFC 1035 и RFC 1123. Он критически важен для DoT, поскольку последний целиком опирается на TCP-транспорт.

TCP становится обязательным

RFC 1123 §6.1.3.2 гласил, что резолверы и рекурсивные серверы MUST поддерживать UDP и SHOULD поддерживать TCP; многие реализаторы трактовали TCP как опциональную возможность. RFC 7766 ужесточает требования:

все general-purpose DNS-реализации MUST поддерживать и UDP, и TCP;
авторитативные серверы MUST поддерживать TCP — чтобы не ограничивать размер ответов одним UDP-пакетом;
рекурсивные серверы и форвардеры MUST поддерживать TCP;
stub-резолверы (библиотеки ОС) MUST поддерживать TCP.

Требование «UDP first» ослаблено: stub- и recursive-резолверы MAY выбирать TCP или UDP по локальным операционным причинам; TCP MAY использоваться до любых UDP-запросов; при наличии открытого TCP-соединения его SHOULD переиспользовать. Ответ MUST отправляться по тому же транспорту, что и запрос, а для TCP — MUST на том же самом соединении.

Терминология

Persistent connection — соединение, не закрываемое ни сервером, ни клиентом после первого ответа;
Connection Reuse — множество запросов/ответов по одному соединению;
Idle DNS-over-TCP session — клиент считает сессию idle при отсутствии ожидающих отправки и неотвеченных запросов; сервер — когда ответил на все полученные запросы;
Pipelining — отправка нескольких запросов без ожидания ответов;
Out-of-Order Processing — конкурентная обработка запросов и отправка ответов по мере готовности.

Требования к таймаутам и закрытию

idle-таймауты: рекомендованный серверный application-level idle-период по умолчанию — порядка секунд; MAY быть дольше при достатке ресурсов; минимум «несколько секунд» нужен для поддержки последовательности SOA+AXFR на одном соединении; при перегрузке/атаке серверы MAY использовать нулевой таймаут;
slow-read attack: сервер SHOULD сбрасывать idle-таймер только при получении полного DNS-сообщения;
клиенты MUST минимизировать idle-время сессий; SHOULD закрывать idle-соединение, если таймаут не согласован сигналингом (edns-tcp-keepalive);
серверы MUST NOT закрывать соединение из-за неполного первого read.

EDNS0 и размеры сообщений

Без EDNS0 лимит UDP-ответа — 512 байт; при TC=1 выполняется retry по TCP. EDNS0 (RFC 6891) позволяет UDP-ответы до объявленного клиентом buffer size, но пакеты больше path MTU фрагментируются, а фрагментация ненадёжна: файрволы блокируют фрагменты, устройства отказываются обрабатывать DNS с EDNS0-опциями (RFC 5625). MTU в ядре интернета — около 1500 байт, и DNSSEC-подписанные ответы регулярно её превышают. Вывод RFC 7766: единственный стандартизированный UDP-механизм решения проблемы размера признан неадекватным, поэтому TCP — легитимный транспорт.

TFO и предупреждение для DoT

TCP Fast Open (RFC 7413) переносит данные в SYN, экономя до 1 RTT; защита от спуфинга — server-supplied cookie; при anycast-деплойменте все узлы за одним IP должны использовать один ключ для генерации cookie. Для DoT TFO опасен тем, что данные запроса могут попасть в SYN в открытом виде: реализатор обязан обеспечить, чтобы в SYN попадал только TLS ClientHello (зашифрованный), а не DNS-запрос.

Padding и трафик-анализ: RFC 8467

RFC 8467 (октябрь 2018, Experimental) определяет политики дополнения сообщений для EDNS(0). Базовый механизм — EDNS(0) Padding option (RFC 7830, code 12, минимальный размер 4 октета). Padding осмыслен только на зашифрованном транспорте (DoT/DoDTLS/DoQ/DoH).

Общие правила

padding MUST быть последней EDNS(0)-опцией перед отправкой;
размер сообщения, подаваемый в алгоритм, MUST вычисляться без двухоктетного length-поля TCP (иначе наблюдаемый размер выдаёт транспорт и подсказывает исходную длину);
на дешёвых линках и батарейных устройствах следует взвешивать выигрыш в конфиденциальности против трафика.

Рекомендуемая стратегия: Block-Length Padding

Стратегия основана на эмпирическом исследовании Дэниела Гиллмора (NDSS 2017, «Empirical DNS Padding Policy»):

клиенты SHOULD дополнять запросы до ближайшего кратного 128 октетам;
сервер, получивший запрос с Padding-опцией, MUST дополнить ответ (по RFC 7830 §4) и SHOULD — до кратного 468 октетам.

Число 468 выбрано так, чтобы 3 блока (1404 байта) помещались в типичный MTU; блоки, кратные большим долям MTU, могут вызвать фрагментацию. Даже пустая Padding-опция добавляет 4 октета. «Очень большие блоки» (почти как Maximal): 288 байт для запроса (максимум one-question query по TCP без EDNS0-опций) и EDNS0 buffer size сервера для ответов. Недостаток: при известном публичном размере блока наблюдатель предсказывает диапазон и выводит минимальную длину исходного сообщения.

Прочие стратегии

Стратегия	Суть	Вердикт
Maximal-Length	всё до максимума протокола	максимальная скрытность размера, но расточительно; почти всегда > MTU → фрагментация; NOT RECOMMENDED
Random-Length	случайное число октетов	по распределению наблюдаемых длин атакующий выводит исходную длину; NOT RECOMMENDED
Random-Block-Length	случайный выбор блока из нескольких	больше разнообразия размеров; дороже в реализации; требует исследований
No Padding	без дополнения	MUST NOT (если только не осталось < 4 октетов)
Fixed-Length	константный паддинг	легко вычисляется из одного незашифрованного сообщения; MUST NOT, кроме тестов

Ограничения padding

Padding не скрывает: факт того, что трафик — DNS; timing-каналы; число пар запрос/ответ. Контрмеры (cover traffic, джиттер задержек) — вне скоупа RFC. Усилия клиента могут быть сведены на нет сервером с неэффективной политикой ответов — клиенту имеет смысл выбирать сервер с сопоставимой политикой.

TLS 1.3 и DoT

TLS 1.3 (RFC 8446, август 2018) радикально изменил картину для всех протоколов поверх TLS, включая DoT.

Что меняет TLS 1.3

handshake сокращается с ~2 RTT (TLS 1.2) до 1 RTT; всё после ServerHello шифруется (EncryptedExtensions, Certificate, CertificateVerify, Finished);
cipher suites: только AEAD; MUST: TLS_AES_128_GCM_SHA256; SHOULD: TLS_AES_256_GCM_SHA384 и TLS_CHACHA20_POLY1305_SHA256;
key exchange: MUST secp256r1, SHOULD X25519;
session resumption: RFC 5077 (session tickets) и session IDs заменены на PSK (pre-shared keys) + NewSessionTicket; клиент, предлагающий PSK, SHOULD также прислать key_share, чтобы сервер мог отказаться от resumption; PSK можно комбинировать с (EC)DHE для forward secrecy; PSK-only теряет PFS для прикладных данных;
record padding (раздел 5.4): любая TLS-запись может быть дополнена нулевыми октетами; Application Data может иметь пустой content (генерация cover traffic); Handshake и Alert с пустым content запрещены; лимит полного TLSInnerPlaintext — 2^14+1 октетов (или record_size_limit, RFC 8449); политика padding вынесена из TLS: прикладной протокол со своим padding предпочтителен — прямая отсылка к DNS (EDNS0 Padding).

Почему 0-RTT неприменим в DoT

0-RTT (early data) — режим, при котором клиент отправляет данные на первом флайте, зашифровав их ключами early data. RFC 8446 прямо предупреждает, что свойства 0-RTT слабее обычных:

0-RTT не обеспечивает forward secrecy (шифруется только под PSK);
нет гарантий невоспроизводимости (non-replay) между соединениями.

Для DoT это принципиально по нескольким причинам:

DNS-запрос формально идемпотентен, но не является «replay-safe» в смысле приватности: реплей запроса заставляет рекурсор выполнить исходящие запросы к авторитативным серверам, и наблюдатель может по таймингу/трафику резолвера выяснить, какое имя запрашивалось (это прямо разбирается в RFC 9250 §7.1);
риск cache-timing oracle (RFC 8446 §E.5): реплей в другой кэш-узел + замер задержки отдельным соединением определяет, адресуется ли тот же ресурс;
переупорядочивание сообщений и перегрузка rate-limiter'ов;
RFC 8446 §E.5: «приложения MUST NOT использовать 0-RTT без профиля, определяющего его использование» — для DoT такого профиля нет; RFC 7858 не специфицирует 0-RTT вовсе.

Серверы, поддерживающие 0-RTT, обязаны реализовать анти-replay механизмы (раздел 8 RFC 8446): single-use tickets (БД билетов с удалением при использовании), ClientHello recording (ключ хранения — валидированные части ClientHello; допустимы Bloom-фильтры с обязательным отклонением при совпадении), freshness checks (реалистичное окно ~10 секунд). Важно: freshness check недостаточен сам по себе — внутри окна возможны миллиарды реплеев.

ECH: скрытие SNI

В TLS 1.3 вне шифрования остаётся SNI в ClientHello — главная утечка целевого домена. Решение — Encrypted Client Hello (ECH), опубликованный как RFC 9849 (март 2026, Standards Track), с бутстрапом через SVCB/HTTPS-записи (SvcParamKey 5 «ech», RFC 9848). Механизм: ClientHello шифруется под публичным ключом client-facing сервера; outer (видимый) и inner (зашифрованный) ClientHello; анонимное множество = домены за одним ECHConfig.

Прямая связь с DNS privacy (в самом RFC 9849):

«SNI-шифрование бесполезно без шифрования DNS-запросов в пути» — ECH не скрывает имя сервера от резолвера;
зашифрованный DNS (DoT/DoH/DoQ) и ECH дополняют друг друга: DoT/DoH/DoQ скрывают от наблюдателя, какие домены резолвятся; ECH скрывает SNI при TLS-соединениях, включая соединение к самому DoH-резолверу;
против downgrade-атак (вырезание ECH из DNS-ответа) — DNSSEC-валидация и SVCB-reliant поведение;
круговая зависимость: чтобы получить ECHConfig, нужно резолвить SVCB — этот запрос должен идти по зашифрованному каналу или быть предсконфигурирован.

Сравнение DoT, DoH и DoQ

Полное сравнение трёх основных протоколов зашифрованного DNS:

Аспект	DoT (RFC 7858)	DoH (RFC 8484)	DoQ (RFC 9250)
Транспорт	TCP + TLS	HTTP/2 (мин. RECOMMENDED) или HTTP/3	QUIC v1 (RFC 9000/9001)
Порт по умолчанию	853/TCP	443/TCP и UDP	853/UDP
Идентификация сервиса	порт + TLS-сертификат	URI Template (https://.../dns-query)	ALPN "doq" + сертификат
Фрейминг	2-октетный length field (RFC 1035 §4.2.2)	media type application/dns-message, без length field	2-октетный length field на каждом stream
Message ID	обязателен; сопоставление по ID + QNAME/QCLASS/QTYPE	ID=0 (HTTP сопоставляет запрос/ответ)	ID MUST = 0 (сопоставление по stream)
Модель	pipelining на одном TCP-потоке	GET (base64url) или POST; мультиплексирование HTTP/2	1 запрос = 1 bidirectional stream; параллельность без HOL-blocking
Кэширование	нет	HTTP-кэши, CDN, прокси; freshness <= min TTL	нет
Padding	EDNS0 (RFC 7830/8467)	EDNS0 + HTTP/2 padding	EDNS0 или QUIC-пакетный padding
Keepalive	edns-tcp-keepalive (RFC 7828)	HTTP idle	edns-tcp-keepalive MUST NOT (QUIC idle timeout)
0-RTT	нет (нет профиля; replay-риски)	есть в HTTP/2-over-QUIC	есть: только OPCODE QUERY и NOTIFY; прочее — очередь, REFUSED + EDE 26 "Too Early" или CONNECTION_CLOSE
HOL-blocking	есть (TCP)	есть при HTTP/2, нет при HTTP/3	нет
Zone transfer (XFR)	возможно (RFC 9103, XoT)	не подходит	явно поддержан: параллельные IXFR/AXFR
Приватность/смешивание	трафик на 853 легко выделяется	смешивается с обычным HTTPS на 443	UDP 853 легко выделяется

Ключевые выводы сравнения:

DoT — базовый зашифрованный канал stub→recursive с минимальным оверхедом поверх классического DNS; узкие места — TCP HOL-blocking и состояние на сервере;
DoH — экосистема браузеров и веба: доступ за файрволами (443), CDN-кэширование, смешение с HTTPS-трафиком против блокировок; минусы — оверхед HTTP, утечки заголовков и cookies;
DoQ — минимальная задержка (0-RTT для безопасных транзакций, нет HOL-blocking), устойчивость к потере пакетов, идеален для мобильных клиентов и zone transfers; риски — replay и линкабильность 0-RTT и resumption, регулируемые жёстче, чем в DoT/DoH.

Рекомендации операторам: RFC 8932

RFC 8932 (октябрь 2020, BCP 232) «Recommendations for DNS Privacy Service Operators» адресован операторам рекурсивных резолверов. Три класса действий = три уровня соответствия: минимальное (митигации угроз), умеренное (+ оптимизации), максимальное (+ дополнительные опции).

На канале клиент–сервер

сервис должен предоставляться по DoT (RFC 7858/8310) или DoH (RFC 8484); DoDTLS — Experimental; DNSCrypt/IPsec/VPN — вне скоупа; шифрование транспорта не отменяет DNSSEC;
сервисы должны давать клиентам возможность аутентифицировать сервер (публичная идентичность, которой будут доверять); для DoT — X.509-сертификаты (RFC 5280) или SPKI pin sets;
управление сертификатами — самый сложный аспект для традиционных DNS-операторов: следовать RFC 7525 §6.5 (revocation), автоматизировать генерацию/продление (например, ACME, RFC 8555), мониторить сертификаты (невалидный сертификат ведёт к недоступности сервиса и откату пользователя на cleartext), выбирать короткий запоминающийся ADN (митигация опечаток, ведущих на сервер атакующего);
DoT-сервис на обоих портах: 853 и 443; при DoH на том же IP — обязательно ALPN «dot»;
оптимизации: OOOR — параллельная обработка конвейерных запросов с ответами не по порядку (RFC 7766); управление TLS-соединениями под RFC 7766 и edns-tcp-keepalive (RFC 7828); опционально DNS Stateful Operations (RFC 8490);
DNSSEC: все DNS privacy-сервисы должны выполнять DNSSEC-валидацию и предоставлять клиенту DNSSEC RRs для самостоятельной валидации; шифрование не даёт невалидирующему клиенту доказательств аутентичности данных (доверие — только AD-биту); шифрованный транспорт решает проблему «DNSSEC roadblocks» от middlebox (RFC 8027);
доступность: зашифрованные сервисы должны иметь доступность не ниже незашифрованных; особая защита от DoS;
паритет сервиса: тот же уровень услуг, что на cleartext-канале (фильтрация или её отсутствие, DNSSEC-валидация и т.п.);
мониторинг: шифрование ломает пассивный перехват трафика; нужны альтернативы — экспорт с самого резолвер-софта (например, dnstap), privacy-сознательный мониторинг (Bloom filters);
TLS-прокси перед DNS-сервером (nginx/haproxy/stunnel) ограничивает: весь трафик выглядит исходящим от прокси, что ломает ACL, Response Rate Limiting, DNS64 (RFC 6147); риск утечки при незашифрованном плече прокси→цель; альтернатива — DNS-aware прокси (dnsdist) с опциями добавления исходной информации (DNS-XPF).

Данные в покое и на выходе

минимизация хранения; при хранении — шифрование, агрегация, псевдонимизация/анонимизация;
логи — только на срок, нужный для работы и законодательства; доступ персоналу по принципу минимума;
QNAME minimization (RFC 7816) — обязательна: иначе авторитативные серверы видят имена запросов;
уважать SOURCE PREFIX-LENGTH=0 в EDNS Client Subnet (RFC 7871 §7.1.2);
если ECS слать — кратчайший операционно-целесообразный префикс и allowlisting апстримов;
агрессивное использование DNSSEC-валидированного кэша (RFC 8198) + NXDOMAIN-спрашивание (RFC 8020) — меньше запросов к авторитативным; локальная копия корневой зоны (RFC 8806) — не светить запросы к корневым серверам;
обфускация апстрим-трафика: апстрим-запросы идут в cleartext; резолвер с маленьким комьюнити рискует раскрыть клиентов — следует примешивать сгенерированный трафик и агрессивный prefetch; малым операторам — форвардить трафик в более крупный резолвер с совместимой privacy-политикой по зашифрованному протоколу (k-anonymity);
не делиться идентифицируемыми данными с третьими сторонами; при особых случаях — публиковать условия.

Анонимизация IP-адресов (Appendix B)

Категоризация (по RFC 6235): format-preserving; prefix preservation; replacement; filtering; generalization; enumeration; reordering/shuffling; random substitution; cryptographic permutation. Конкретные методы:

Google Analytics non-prefix filtering: обнуление младших 8 бит IPv4 и 80 бит IPv6 — слабая анонимизация (расхождение определения города до 17%);
dnswasher (PowerDNS): формат-сохраняющая замена перечислением; таблицы растут без ограничений;
prefix-preserving map (TCPdpriv): недетерминированность, неограниченная память;
Crypto-PAn: криптографическая prefix-preserving псевдонимизация, детерминирована ключом, существенные CPU-затраты;
TSA (Top-hash Subtree-replicated): быстрая, для IPv6 неэффективна по памяти;
ipcipher (PowerDNS): AES-128 для IPv6, ipcrypt для IPv4 — автор признал низкую стойкость ipcrypt (уязвим к атаке);
Bloom filters (DNSBLOOM): определение Indicators of Compromise из подсетей без хранения запросов отдельных пользователей.

Ключевая атака: любая формат-сохраняющая псевдонимизация уязвима к chosen-plaintext атаке (Brekne & Årnes): если атакующий может добиться захвата пакетов целью, слать ей поддельный трафик с произвольными адресами и получить де-идентифицированный лог — ограниченная энтропия IPv4 делает псевдоним обратимым.

Recursive Operator Privacy Statement (RPS)

Для соответствия BCP оператор SHOULD опубликовать RPS с фиксированным порядком разделов (облегчение сравнения):

Policy: заявление, что IP-адреса — персональные данные; какие данные собираются/хранятся/как долго; исключения; связанные организации; корреляция DNS-данных с другой личной информацией; фильтрация результатов по категориям (безопасность сети, обязательные юридические, добровольные юридические, прочие) с указанием происхождения списков;
Practice: отклонения от политики; клиентские возможности по каждому разделу (для DoT — ADN и/или SPKI pin sets и политика ротации); апстрим-возможности; контакты поддержки; ссылки на заявления о обработке данных;
Enforcement: transparency reports; независимый мониторинг (ECS, QNAME-минимизация, padding, фильтрация, аптайм); опционально сторонний аудит.

Практические примеры

Проверка DoT-сервера

Проверить поддержку DoT публичным резолвером можно утилитой dig из пакета bind9-utils (реализация DoT есть в dig начиная с BIND 9.16):

dig +tls @1.1.1.1 example.com
dig +tls @dns.google example.com

Конфигурация локального резолвера

Пример DoT-форвардинга в unbound (файл unbound.conf):

forward-zone:
    name: "."
    forward-tls-upstream: yes
    forward-addr: 1.1.1.1@853#cloudflare-dns.com
    forward-addr: 8.8.8.8@853#dns.google

Синтаксис «ip@port#ADN» соответствует модели RFC 8310: клиент подключается по IP на порт 853 и проверяет сертификат на имя ADN (аутентификация domain name).

Проверка ALPN и сертификата

Исследовать TLS-параметры DoT-эндпоинта можно средствами openssl:

echo | openssl s_client -connect 1.1.1.1:853 -servername cloudflare-dns.com -alpn dot 2>/dev/null | grep -E "ALPN|subject"

Резюме

DNS over TLS — зрелый, стандартизированный протокол шифрования DNS-трафика на сегменте stub→recursive, основанный на двух краеугольных камнях: RFC 7858 (транспорт, порт 853, фреймирование, профили) и RFC 8310 (строгая типология профилей, ADN, DANE, механизмы аутентификации). Ключевые технические факты, которые стоит запомнить:

DoT работает поверх TCP на порту 853; первый обмен — TLS-handshake; cleartext на DoT-портах запрещён безусловно, включая после failed handshake;
фреймирование — двухоктетное поле длины (RFC 1035 §4.2.2); максимальное сообщение — 65535 байт;
сопоставление ответов — по Message ID и (при наличии Question Section) QNAME/QCLASS/QTYPE; ответы могут приходить out of order;
два базовых профиля — Opportunistic (без строгой аутентификации) и Key-Pinned (SPKI-пины, несовпадение — невосстановимая ошибка); RFC 8310 формализует Strict (hard failure при сбое аутентификации) и Opportunistic (каскад A+E → E → cleartext);
аутентификация — по ADN в subjectAltName (PKIX, RFC 6125) или через DANE/TLSA (DNSSEC), или через SPKI pin sets; ADN проверяется строго по subjectAltName, поле Subject не проверяется;
производительность: +1 RTT на TCP (устраняет TFO), +2 RTT на TLS-handshake (устраняет resumption/PSK и False Start); сервер должен минимизировать состояние и держать idle-соединения;
0-RTT в DoT неприменим из-за replay-рисков (тайминг-оракулы, повторные исходящие запросы резолвера); resumption через PSK (TLS 1.3) — безопасен и рекомендован;
трафик-анализ — главный остаточный риск; митигируется EDNS(0) padding (запросы кратно 128, ответы кратно 468 по RFC 8467), но не устраняется полностью (тайминги и число запросов остаются видимыми);
DNSSEC и DoT независимы и дополняют друг друга: одно — целостность, другое — конфиденциальность;
операторам RFC 8932 предписывает DNSSEC-валидацию, QNAME minimization, EDNS0 padding, управление сертификатами (ACME, мониторинг истечения, короткий ADN), публикацию RPS и осторожность с TLS-прокси;
из трёх протоколов зашифрованного DNS DoT — самый простой и минимально накладный; DoH выигрывает в смешивании с HTTPS-трафиком и кэшировании; DoQ — в задержке, мобильных сценариях и zone transfers.

DoT — это не «DNS с шифрованием вообще», а точный протокол с продуманными профилями, ограничениями и осознанными компромиссами. Понимание его внутреннего устройства — необходимое условие для корректного проектирования, деплоймента и аудита современных DNS-инфраструктур.

Ссылки

×