Кратко

  • EDE 33 говорит, что при формировании ответа действовал охватывающий запрос отрицательный якорь доверия; он не говорит, что исключение изменило ответ или что данные подлинны.
  • Для аудита нужны шесть раздельных подтверждений: конфигурации, охвата, раскрытия, проверки, транспорта и результата приложения.

У исключения появился свидетель

Сбой DNSSEC ставит оператора перед выбором. Сохранение защиты может лишить пользователей доступа к домену с обычной ошибкой подписи. Отключение проверки может вернуть доступ, но резолвер сознательно отказывается от ключевого контроля. RFC 7646 определяет отрицательный якорь доверия, NTA, как локальное, временное и узко ограниченное исключение в проверяющем рекурсивном резолвере.

Раньше получателю ответа было трудно увидеть это исключение. Оператор мог публиковать список на сайте, но DNS-сообщение не сообщало, что оно создано при активной NTA. Новый рабочий документ DNSOP Disclosure of Negative Trust Anchors in DNS Responses предлагает Extended DNS Error 33 “Negative Trust Anchor”. Редакция 00 датирована 23 сентября 2026 года. Это рабочий Internet-Draft, не RFC и не окончательный консенсус IETF.

Утверждение сигнала узкое: ответ с EDE 33 сформирован при действующей NTA, которая его охватывала. Код должен исходить от рекурсивного резолвера с настроенным исключением; чисто авторитетный сервер, который не выполняет проверку, не должен его добавлять. Оператору следует возвращать код в затронутых ответах, чтобы пользователь или приложение знали: ответ мог не проходить DNSSEC-проверку.

Наблюдаемость улучшается. Подлинность ответа от этого не возникает.

Раскрытие не равно аутентификации

Текст проекта называет EDE 33 диагностическим. Клиент не должен менять обработку протокола только из-за его наличия; код не меняет и обработку бита AD. Так устроен RFC 8914: EDE добавляет контекст, но не заменяет RCODE и не становится командным каналом.

Код не доказывает причинность. Резолвер может включать его, пока NTA активна, даже если исключение материально не повлияло на данный ответ. Чтобы узнать, провалился бы запрос без NTA, нужны журналы валидатора или контролируемое повторение без исключения.

EDE 33 не удостоверяет сами DNS-данные. NTA существует именно для приостановки обычной проверки в заданной области. RFC 4035 описывает работу валидатора и состояния безопасности; диагностический код не восстанавливает цепочку доверия, которую резолвер решил не требовать.

Само раскрытие не имеет встроенной криптографической подписи. Участник на пути может добавить, удалить или изменить EDE. TSIG, SIG(0), DNS over TLS или DNS over HTTPS способны защитить сообщение или участок, однако целый EDE доказывает лишь то, что сообщил идентифицированный резолвер. Он не доказывает доброкачественную причину сбоя, качество расследования или правильность сервиса за полученным адресом.

Шесть отдельных подтверждений

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

Подтверждение охвата показывает, что конкретные QNAME и ответ попадали под NTA в этот момент. Якорь на предке может охватывать дочерний запрос, а несколько NTA могут действовать одновременно.

Подтверждение раскрытия сохраняет сырой ответ, идентификатор резолвера, время и все экземпляры EDE 33. При нескольких экземплярах каждый должен иметь EXTRA-TEXT. Поле d может назвать домен настройки, t — предполагаемый срок; t не гарантирует удаление.

Подтверждение проверки содержит AD/CD, журналы и результат без исключения. EDE не предоставляет этот контрфактический результат.

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

Подтверждение приложения фиксирует, что stub и приложение получили и использовали. Доставка DNS-ответа не гарантирует соединение, правильный контент или успех сервиса.

Сведение шести фактов к одному рождает ошибку: «резолвер указал NTA, значит ответ безопасен». Доказуемо только более скромное: «этот резолвер сообщил, что в данный момент ответ охватывала NTA».

У прозрачности есть граница приватности

EXTRA-TEXT может объяснять имя, причину, ссылку или ожидаемую длительность. Он предназначен для человека и не должен раскрывать частные или чувствительные сведения. Номер заявки, клиент, внутренний hostname или закрытый план реагирования не становятся безопасными внутри DNS-опции.

d и t повышают машинную наблюдаемость, но не силу доказательства. d передаёт заявленную оператором точку настройки, а не право на домен. t — ориентир, а не команда удаления или подтверждённая проверка. Хорошие метаданные помогают заметить дрейф, но не исключают его.

Минимальный общий сигнал, а не центральная лицензия

IETF может стандартизировать минимальный совместимый факт. Оператор резолвера сохраняет право решения и ответственность; оператор домена исправляет авторитетный DNSSEC; клиент выбирает представление диагностики, не превращая её в приказ доверять.

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

Статус и пределы

Примеры в редакции 00 демонстрируют механизм, но не измеряют поддержку. Forwarder может удалить или пересоздать EDE, ограничение UDP может вытеснить дополнительную опцию, а приложение может её не показать. Текст ещё способен измениться.

Тем не менее проект расширяет поверхность доказательств: у прежде скрытого ослабления проверки появляется стандартный свидетель. Задача руководства — не превратить свидетеля в приговор.

Источники