Кратко

  • Аутентифицированный шифрованный сеанс DNS подтверждает свойства транспорта до резолвера, но не обращение с запросом после расшифрования.
  • RPS из RFC 8932 позволяет сопоставлять заявления операторов, однако транспорт, обработка, хранение и доступ, а также дальнейшая передача требуют собственных датированных свидетельств.

В незнакомой сети ноутбук соединяется не с локальным DNS по открытому протоколу, а с заранее выбранным сервисом через TLS, HTTPS или QUIC. Владелец точки доступа больше не может без труда читать имена, а злоумышленнику на этом отрезке сложнее подменить ответ. Клиент проверяет, с каким сервисом он разговаривает. Это существенная защита.

Но в конце канала запрос необходимо расшифровать. Рекурсивный резолвер ищет ответ в кэше, проверяет его или задаёт новые вопросы другим серверам. Оператор в принципе видит имя и транспортные идентификаторы. Он выбирает поля журналирования, срок хранения, круг допущенных сотрудников, способы связывания сеансов, правила изменения ответов и состав сведений, отправляемых дальше.

Именно здесь проходит полезная граница RFC 8932 Recommendations for DNS Privacy Service Operators. Документ опубликован в октябре 2020 года как BCP 232. Его авторы — Sara Dickinson, Benno Overeinder, Roland van Rijswijk-Deij и Allison Mankin. Профиль Dickinson в IETF перечисляет восемь RFC, включая RFC 8932 и RFC 9250 о DNS поверх QUIC, а также её роль председателя Privacy Enhancements and Assessments Research Group. RIPE Labs называет её сооснователем Sinodun IT. Эти данные подтверждают длительную коллективную работу, но не единоличное изобретение шифрованного DNS и не управление чужими резолверами.

RFC 8932 сочетает рекомендации по эксплуатации с формой публичного описания — Recursive operator Privacy Statement, или RPS. Она не навязывает всем одну политику. Общий порядок тем помогает сравнивать обязательства и текущую практику, а также отличать измеряемые свойства от заявленных. Само наличие RPS не является сертификатом и не заменяет юридическую оценку.

Первое свидетельство относится к связи клиента с резолвером. Оно фиксирует конечную точку и имя аутентификации, протокол, результат проверки сертификата, версию TLS или QUIC, заполнение пакетов, доступность и поведение при отказе. RFC 8310 описывает профили DNS over TLS, RFC 8484 — DNS over HTTPS, RFC 9250 — DNS через выделенные соединения QUIC. Все они защищают конкретный участок. Ни один не доказывает, что оператор забудет запрос после его расшифрования.

Шифрованный транспорт также не заменяет DNSSEC. RFC 8932 прямо разделяет эти механизмы: они решают разные задачи. Если клиент не проверяет DNSSEC сам, аутентифицированное соединение не доказывает, что проверку выполнил резолвер. Клиент может лишь доверять выставленному биту AD. Сертификат TLS подтверждает сторону транспортного сеанса, а не криптографическое происхождение каждого полученного DNS-ответа.

Второе свидетельство описывает обработку внутри сервиса. Какой режим валидации использован? Ответ взят из кэша? Сработало правило безопасности, исключение или блок-лист? Были ли разные соединения объединены по IP-адресу, возобновлению сеанса, HTTP-заголовкам, характеристикам TLS или рисунку запросов? RFC 9076 отмечает, что зашифрованный входящий DNS-трафик иногда можно сопоставить с открытыми вопросами, которые рекурсивный резолвер отправляет наружу.

Постоянный выбор одного шифрованного сервиса делает понятнее, кто видит запросы в разных сетях. Одновременно тот же оператор может легче узнавать пользователя при переходе между сетями. Уменьшить число наблюдателей в пути и ограничить корреляцию на конечной точке — разные меры. Доказательство первой нельзя выдавать за доказательство второй.

Фильтрация ответов тоже относится к обработке. RFC 8932 предлагает раскрывать изменения ради сетевой безопасности, исполнения обязательного правового решения, добровольного снижения юридического риска, коммерческой цели или иной причины. Следует описывать происхождение и управление списками. Конфиденциальный канал вполне может принести изменённый ответ; словосочетание «защищённый DNS» не объясняет обе характеристики.

Третье свидетельство охватывает хранение и доступ. RFC 8932 рекомендует сводить сохранение к минимуму или полностью отказываться от него. Если данные нужны, их следует шифровать и по возможности агрегировать, псевдонимизировать либо анонимизировать. Срок журнала ограничивается эксплуатационной необходимостью и применимыми требованиями, а доступ — сотрудниками, которым он нужен для работы.

Заявление «удаляем через семь дней» фиксирует обещание, а не факт удаления. Результат правила жизненного цикла показывает обработку конкретного набора. Модель ролей определяет, кому доступ положен; журнал доступа — кто воспользовался им на деле. Шифрование накопителя не исключает существование выгруженной копии. Псевдонимизация также не равна анонимности: устойчивый заменитель позволяет связывать действия во времени и иногда обратим, если доступна таблица или метод.

Четвёртое свидетельство следует за данными, покидающими резолвер. Для рекурсивного поиска нужны обращения к другим резолверам или авторитетным серверам. RFC 8932 рекомендует минимизацию QNAME, чтобы каждый уровень видел только необходимую часть имени; RFC 9156 обновляет этот порядок. EDNS Client Subnet лучше не применять, а при необходимости следует передавать самый короткий работоспособный префикс и раскрывать фактическое правило.

Независимый тест может заметить, что конкретный запрос в данный момент был минимизирован и не содержал ECS. Такой результат ценен именно в своих границах: время, точка наблюдения и тестовый случай. Он не покрывает все имена, пересылки и исключения. Он тем более не видит последующую передачу сохранённой копии. Безупречная защита первого участка не гарантирует бережного второго.

Поэтому RPS должна отвечать на предметные вопросы. Считаются ли IP-адреса персональными данными? Что собирается, хранится, передаётся, продаётся или сдаётся в пользование? Каковы способы минимизации, условия передачи и исключения? Какие связанные организации и источники финансирования участвуют? Сопоставляются ли DNS-данные с другими сведениями о человеке? Почему фильтруются ответы? Практическая часть добавляет действующие точки подключения, аутентификацию, работу с вышестоящими серверами, отклонения от политики и поддержку.

Сильная RPS служит указателем на доказательства. Обещание минимизировать QNAME ведёт к конфигурации и внешнему тесту. Срок хранения — к правилу и результатам удаления. Ограничение доступа — к ролям и аудируемым событиям. Передача данных называет получателя, цель, поля, условие и дату прекращения. Отчёты о прозрачности и независимые аудиты расширяют наблюдение, если сохраняют период и охват.

Но указатель не является исполнением. У аудита есть выборка и исключения, у измерения — позиция наблюдателя, у отчёта — пределы доступа автора. Опубликованная RPS может отстать от живой настройки. Это не делает приватность непознаваемой. Это требует подбирать для каждого утверждения надлежащего свидетеля и явно ограничивать срок его показаний.

Практическое наследие Dickinson и соавторов — публичный язык для решений, которые раньше скрывались за словом «шифрование». Профессиональная проверка продолжается после вопроса о канале: кто принимает решение по прибытии запроса, какой след его подтверждает и когда это подтверждение перестаёт быть актуальным?

Источники