Кратко

  • RFC 8914 переносит Extended DNS Error в EDNS option 15: 16-битный INFO-CODE и необязательный UTF-8 EXTRA-TEXT. EDE дополняет базовый RCODE, не заменяет его; получатель продолжает обработку RCODE и не обязан действовать по диагнозу.
  • EDE — утверждение resolver или forwarder о собственном наблюдении, а не end-to-end-доказательство причины. Посредник может отбросить или создать option заново, а при нехватке места UDP объяснение удаляется раньше основного DNS-результата.
  • Надёжная цепочка связывает raw bytes, отправивший hop, RCODE, cache, upstream-попытки, DNSSEC trace, локальное правило, retry и независимое подтверждение. Один код не должен отключать validation или выбирать менее безопасный resolver.

Когда точность формулировки путают с точностью причины

SERVFAIL объединяет разные события. Validator мог увидеть просроченную подпись, resolver — потерять доступ к authority, а локальная policy — заблокировать ответ. EDE делает различия переносимыми.

Но надпись «DNSSEC Bogus» выглядит окончательным вердиктом. На деле она может зависеть от конкретного trust anchor, неверных часов, старого cache, версии ПО или заключения, унаследованного от upstream. Код позволяет найти наблюдение, но не исключает конкурирующие объяснения.

Диагноз может открыть ticket, определить нужный packet capture и направить запрос команде. Сам по себе он не вправе отключить DNSSEC, принять подменные данные, навсегда перевести трафик на менее строгий resolver или публично назначить виновного.

Малый option содержит несколько независимых решений

RFC 8914 определяет EDE как EDNS option code 15. Первые два octet содержат INFO-CODE, затем может идти предназначенный человеку UTF-8 EXTRA-TEXT. Программа не должна разбирать текст как команду. В одном ответе допустимы несколько EDE, а option сочетается с любым RCODE, включая NOERROR.

Базовый RCODE остаётся главным контрактом. Распознать, показать, сохранить, поднять alert и изменить поведение — разные локальные решения. Стандарт не даёт отправителю удалённое управление получателем через диагностическую подпись.

Реестр IANA создаёт общий словарь. RFC 8914 первоначально определил коды 0–24 для DNSSEC, stale answer, forged, blocked, censored, filtered, prohibited, сетевых ошибок и недоступной authority. Реестр продолжает расти и разделяет публичные и private диапазоны. Регистрация согласует значение номера, но не удостоверяет истинность конкретного сообщения.

Forwarder меняет автора объяснения

Между stub и authority могут стоять корпоративный forwarder, фильтр и recursive resolver. RFC 8914 позволяет forwarder отбросить полученный EDE или создать новый из собственной обработки. Передавая upstream-информацию, он должен по возможности назвать источник в тексте.

Гибкость нужна работающим системам, но требует provenance. Хранение последнего code стирает разницу между прямым наблюдением, наследованием и пересозданием. Минимальная запись включает процесс, endpoint, node, version, transport, upstream attempt, сработавшее правило и полный порядок options.

Защищённый канал отвечает на другой вопрос. Аутентифицированный или шифрованный DNS может связать peer на одном hop, но не доказывает правильность его объяснения удалённого сбоя. В незащищённом UDP или TCP on-path-участник способен изменить option. Целостность транспорта не равна причинным полномочиям.

При дефиците размера объяснение исчезает первым

EDNS из RFC 6891 предоставляет пространство options, но UDP-ответ ограничен. RFC 8914 предписывает при превышении сначала убрать EXTRA-TEXT, затем EDE целиком, а при оставшемся превышении выставить TC по правилам DNS. Большой подписанный ответ может сохранить SERVFAIL, потеряв пояснение.

Отсутствие EDE не доказывает отсутствие диагноза. Наличие не доказывает, что каждый hop видел то же сообщение. Canary должен покрывать отсутствие option, один и несколько кодов, обратный порядок, unknown/private значения, пустой и длинный текст, невалидный UTF-8, удаление в UDP, TCP retry и forwarder с preserve/drop/recreate.

EXTRA-TEXT — недоверенные данные

Свободный текст ускоряет работу и одновременно может раскрыть номер аккаунта, имя клиента, внутренний blocklist, backend address или непубличное правило. Control characters и двунаправленные последовательности способны исказить log и интерфейс. RFC 8914 прямо отмечает privacy risk.

Evidence store сохраняет исходные bytes с узким доступом. Аналитик видит безопасно декодированную строку, публичная поверхность — минимально очищенный вариант. Retention получает срок. Автоматизация не извлекает команды из EXTRA-TEXT.

Running Code соединяет EDE с разной локальной policy

Unbound поддерживает EDE, объяснение serve-expired и DNS Error Reporting по RFC 9567. BIND может прикреплять forged, blocked, censored, filtered и prohibited к результатам Response Policy Zone. PowerDNS Recursor отправляет Extended Resolution Errors и способен пояснять Negative Trust Anchor.

Это подтверждает рабочее внедрение, но trigger остаётся локальным. Один wire code появляется из разных фактов в зависимости от продукта, версии и configuration. Аудит должен пройти от bytes к реально исполненному правилу, а не остановиться на названии RFC.

RFC 8767 показывает то же разделение для stale data. EDE объясняет, почему отдан старый ответ; допустимый возраст, область и момент прекращения определяет resolver. Объяснение не создаёт бессрочного разрешения.

RESINFO и Report-Channel увеличивают и наблюдаемость, и риск

RFC 9606 позволяет через exterr в RESINFO объявлять поддерживаемые EDE-коды. Это помогает обнаружению возможностей, но различия anycast nodes, версий или конфигураций могут сделать объявление неточным. Как использовать его, решает клиент локально.

RFC 9567 кодирует QTYPE, QNAME и EDE в новый report query, чтобы оператор authority увидел failure validator. Механизм ускоряет ремонт, но создаёт стоимость, рекурсию и privacy risk, поэтому глубина и объём ограничиваются. В канале нет mutual authentication. TCP или DNS Cookies повышают доверие к источнику, но не доказывают содержание.

Сила подхода — в тонком общем слое: option, registry и базовая обработка общие; отображение, retention, alert, report и fallback остаются локальными. Packet canaries и running code подтверждают реальное поведение каждой версии и каждого hop.

Источники