Кратко

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

Верный результат может скрывать причину

SERVFAIL объединяет разные состояния: отвергнутую цепочку DNSSEC, недоступный авторитативный сервер, неготовность сервиса или политическую блокировку. Получатель знает о сбое, но не обязательно знает, какой контроль его вызвал.

RFC 8914 добавляет контекст через опцию EDNS 15. Она содержит 16-битный информационный код и необязательный UTF-8-текст. При наличии OPT в запросе EDE может сопровождать SERVFAIL, NXDOMAIN, REFUSED, NOERROR и другие ответы. Реестр различает устаревший ответ, DNSSEC Bogus, истёкшую подпись, блокировку, недоступную авторитативную сторону, сетевую ошибку и неверные данные.

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

Объяснение не является полномочием

Код устаревших данных не разрешает продлевать кэш. DNSSEC Bogus не разрешает отключать валидацию или ставить negative trust anchor. Недоступность авторитативной стороны не разрешает бесконечные повторы или переход к непроверенному резолверу. Для каждого действия нужны отдельный владелец, доказательства и граница риска.

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

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

Доверие наследуется от транзакции

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

До действия нужно отдельно сохранить отправивший переход, защиту транспорта, RCODE, код и текст. Неаутентифицированное объяснение нельзя показывать как вывод безопасности. Исходный ответ следует сохранить для проверки другими свидетельствами.

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

RFC 6891 определяет EDNS как расширение между соседними участниками. OPT несёт управление одной транзакцией и не кэшируется и не хранится в зоне. Неизвестные опции могут игнорироваться. Авторитативный сервер, рекурсивный резолвер, stub и приложение могут видеть разные части события.

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

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

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

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

В контрфактическом случае результат остаётся, контекст исчезает

Без EDE DNS и RCODE продолжают работать. Исчезает дополнительное объяснение. EDE снижает неопределённость, но не создаёт доступность или новые полномочия.

Задача руководства — владеть цепочкой от результата к объяснению, от объяснения к подтверждению и от доказательств к отдельно санкционированному действию. Протокол даёт только первое звено.

Доказательства и границы

Факты взяты из RFC 8914, RFC 6891 и реестра IANA. Выводы об эксплуатации и управлении являются редакционными заключениями. Обвинений в адрес операторов или продуктов нет.

Источники