Кратко

  • Редакция 27 документа Structured Error Data for Filtered DNS находится в очереди RFC Editor. Она предлагает I-JSON в EXTRA-TEXT для пояснения Extended DNS Error, но ещё не стала нумерованным RFC, а окончательные значения не назначены.
  • Аутентифицированные DoT, DoH или DoQ защищают связь клиента с выбранным резолвером. Они сами по себе не подтверждают автора политики выше по цепочке, её правовое основание, верность классификации или действие приложения.

Хорошо оформленное пояснение не является доверенностью

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

Datatracker указывает, что draft-ietf-dnsop-structured-dns-error-27, датированный 30 июля 2026 года и обновлённый 19 августа, имеет состояние RFC Ed Queue. Предполагаемый статус — Proposed Standard, а RFC Editor ожидает назначения редактора. Номера RFC у текста нет; в нём остаются места для будущих значений IANA. Нельзя утверждать, что коды уже окончательны, поддержка универсальна или внедрение повсеместно.

RFC 8914 уже определяет Extended DNS Errors для блокировки, фильтрации, цензуры и подменённого ответа. Дополнительный текст предназначался для диагностики человеком. Новый проект позволяет клиенту отправить пустую опцию SDE EDNS, сообщая, что он понимает объект I-JSON в поле EDE EXTRA-TEXT.

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

Запрос формата не означает согласия с фильтром

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

Сервер по-прежнему может вернуть пустой ответ, NXDOMAIN или нежелательный подменённый адрес. Если клиент объявил SDE и сервер выдаёт связанный с фильтрацией EDE, обычно следует добавить структурированные детали. Проект отличает политику сетевого оператора от политики DNS-оператора и предлагает ещё не назначенный код для блокировки сервером DNS выше по цепочке.

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

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

Шифрование заканчивается вместе с соединением

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

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

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

Это граница происхождения, а не недостаток TLS. Для реконструкции ответственности вне DNS-пакета нужно хранить выбор резолвера, конфигурацию upstream, режим пересылки, версию политики, источник классификации, время и историю исправлений.

Старые пересыльщики усиливают риск. Прокси, не понимающий EDE, способен передать контролируемый атакующим EXTRA-TEXT. Проект предлагает принимать EDE только от явно настроенных DNS-серверов или использовать сведения о резолвере из RFC 9606. Доверие создаётся проверенной связью, а не видом JSON.

Канал помощи может стать каналом воздействия

Контакт нужен для исправления ложных срабатываний. Злонамеренный резолвер способен направить пользователя к атакующему, выдать себя за организацию и убедить раскрыть данные или установить ложное средство исправления. Свободное обоснование усиливает давление.

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

Создание и обновление списка организаций оставлено вне проекта. Это правильная граница. Глобальный протокольный реестр не может решить, вправе ли компания, школа, семья, ISP или публичный орган связывать конкретного пользователя. Сторона, несущая ущерб от ошибки, должна управлять отношением и его отзывом.

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

Короткий TTL ускоряет новый вопрос, а не доказывает исправление

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

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

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

У конфиденциальности тоже должен быть владелец. Структурированные поля могут раскрыть фильтрующую организацию, её правила и домен, который искал пользователь. Их нельзя передавать или журналировать у третьих лиц без ведома пользователя. Экспорт всех ошибок в удалённую аналитику способен отменить приватность, полученную зашифрованным DNS на пути.

Пояснение даёт доказательство, но не финальную команду

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

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

Институциональная проверка проста: кто выбрал резолвер, кто принял политику, кто поставил классификацию, кто исправляет ошибку и кто решает локальное последствие? SDE помогает увидеть эту цепь. Без неё аккуратная структура лишь придаёт неподтверждённому утверждению вид полномочий.

Sources