Кратко

  • Проект DNS Filtering Transparency передаёт идентификатор оператора базы данных и идентификатор инцидента. Такая пара указывает на запись, но не удостоверяет её связь с фильтрацией, которую наблюдало приложение, и не обязывает резолвер раскрывать конкретную ссылку.
  • Затем самостоятельное решение принимает приложение. Оно хранит локальную копию предлагаемого реестра, выбирает поддерживаемых или доверенных операторов и определяет, показывать ли запись. Регистрация задаёт шаблон URI, но не подтверждает инцидент и не узаконивает политику.
  • Загрузка страницы может раскрыть IP-адрес пользователя и его интерес к чувствительному имени. Явное действие пользователя становится третьим решением, которое нельзя смешивать с отправкой резолвера и показом приложения.

Замысел легко оценить. Вместо невнятной ошибки браузер сообщает, что разрешение имени было отфильтровано, и предлагает сведения о происшествии. Человек перестаёт считать вмешательство политического или организационного правила обычной поломкой и получает шанс найти путь исправления ошибки.

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

У этих участников разные полномочия, факты и стимулы. Если сохранить только последнюю картинку, их выборы превращаются в мнимое единое объяснение. Из записи исчезают неотправленные варианты, подавленные приложением источники и ссылка, которую пользователь не открыл из-за риска для приватности.

Пара идентификаторов задаёт маршрут, но не доказывает событие

draft-ietf-dnsop-filtering-transparency-00 опубликован 1 августа 2026 года как первая версия рабочей группы DNSOP. Он добавляет к структурированным данным ошибки список fdbs. В каждом элементе db обозначает оператора базы инцидентов фильтрации, а id — конкретную запись. Несколько пар в одном списке должны относиться к одному исходному инциденту.

Резолвер не передаёт произвольный URL или свободный текст для прямого показа. Приложение ищет db в локальной копии предлагаемого реестра IANA, получает шаблон URI уровня 1 или 2 и подставляет id. Это мешает неизвестному сетевому резолверу использовать доверенный облик браузера для продвижения любого адреса.

Формальное ограничение не удостоверяет соответствие. В разделе о безопасности прямо сказано, что механизм не подтверждает реальную связь пережитого приложением инцидента с представленными сведениями. Контролирующая резолвер сторона может взять существующую пару, которая открывает настоящую страницу, и ошибочно связать её с другим запросом.

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

Не менее важен статус документа. Версия 00 — действующий Internet-Draft, принятый DNSOP взамен индивидуального проекта. Это не RFC; Datatracker пока не указывает предполагаемый статус RFC. Механизм можно серьёзно исследовать, не превращая меняющееся предложение в уже установленную обязанность IETF.

Первое решение: что включит резолвер

Проект не требует передавать конкретные сведения. Резолвер выбирает поддерживаемых операторов баз данных и применяет собственные механизмы, чтобы решить, когда и для каких случаев приложить запись. Исходящий список по определению является отбором, а не полной описью возможных объяснений.

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

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

На стороне резолвера нужно сохранять время, сведения об аутентифицированной связи с DNS-службой, если она была, код EDE, отправленные пары, правило отбора и известные неотправленные альтернативы. Чувствительные имена и персональные данные требуют минимизации и строгого доступа. Сам факт выбора при этом удалять нельзя.

Второе решение: чья версия попадёт в интерфейс

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

Поэтому два устройства с одинаковым DNS-ответом способны показать разное. Одно знает db и строит ссылку, второе ещё не получило запись. Один клиент принимает сведения только от явно настроенного резолвера, другой дополнительно сверяет список доверия. Одна ОС отдаёт структурированные поля браузеру, другая их скрывает.

Финальный экран не раскрывает место расхождения. Нет ссылки — неизвестно, промолчал ли резолвер, устарел ли локальный реестр, отказала ли политика доверия или данные не пропустил хост. Есть ссылка — известно лишь, что приложение решило её распространить, а не что оно проверило распоряжение или аргументацию.

Локальная копия создаёт проблему времени. Контакт записи может изменить шаблон URI, тогда как проект предупреждает о потенциально долгом обновлении приложений. Для восстановления адреса, доступного пользователю в день события, нужна именно та версия копии. Сегодняшняя запись IANA не доказывает вчерашний маршрут.

Сам факт регистрации также не является знаком качества. Предлагается правило «первым пришёл — первым обслужен», хотя IANA может отклонять обманные или фиктивные заявки. RFC 8126 объясняет, что такой порядок обычно не предполагает содержательной проверки сверх формы, уникальности и минимальных административных данных. Реестр связывает идентификатор с шаблоном, но не ручается за рассказ об инциденте.

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

Третье решение: объяснение создаёт новый след

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

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

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

Минимизация не второстепенна. Система, созданная для объяснения вмешательства, не должна становиться более подробным средством наблюдения за теми, кто пытается его понять. Аудиту нужна последовательность решений, а не бессрочная история чувствительных интересов.

Структура, шифрование и регистрация не заменяют доверие

Предложение опирается на Structured Error Data for Filtered DNS. Этот проект делает поля машинно обрабатываемыми, но запрещает автоматически доверять им, показывать их или использовать в решениях безопасности без надлежащей проверки. Для передачи структурированных данных он требует шифрованный DNS-транспорт.

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

RFC 7754 показывает более раннюю часть цепи. Субъект, задающий политику блокирования, может отличаться от субъекта, который её исполняет. Между законом, административным правилом, политикой оператора, архитектурой и реализацией смысл переводится несколько раз, и на каждом переходе возникают побочные эффекты. Быстрое уведомление помогает исправлению, но протокол не решает правовой или этический вопрос конкретной фильтрации.

Квитанция цепочки раскрытия

Daniel Kade предлагает три связанных раздела. Раздел резолвера хранит наблюдение, статус аутентификации, EDE, выданные пары, правило выбора и известные пропуски. Раздел приложения фиксирует снимок реестра, использованный шаблон, настройки поддержки и доверия, решение о показе и класс сообщения. Раздел пользователя отмечает, был ли предложен переход, предшествовало ли ему явное действие, применялся ли прокси и чем закончился запрос.

Неизвестное остаётся неизвестным. Неаутентифицированную личность резолвера нельзя дописывать позже. Неизвестной причине пропуска нельзя придумывать объяснение. Старую копию нельзя заменять текущей. Изменившуюся страницу нельзя выдавать за историческое содержание. Независимо найденное распоряжение или правило связывается как отдельный источник со своей цепочкой происхождения и не выводится из db и id.

Квитанция не делает фильтрацию законной или оправданной. Она делает путь объяснения подотчётным. Можно увидеть, где исчезла ссылка, почему приложение её не показало и какой риск создавал переход. Тогда аккуратное сообщение не сможет изображать общее решение трёх участников, которого в действительности не было.

Источники