Кратко

  • Традиционные RCODE сжимают множество причин в несколько общих исходов. RFC 8914 выделил EDNS-опцию 15 под Extended DNS Error: 16-битный INFO-CODE и необязательный текст EXTRA-TEXT в UTF-8 позволяют сообщить причину, не заменяя исходный код ответа.
  • EDE может сопровождать SERVFAIL, NXDOMAIN, REFUSED и даже NOERROR; в одном сообщении допустимо несколько EDE. Получатель всё равно обязан обрабатывать RCODE по его собственным правилам: диагноз не превращает просроченные, подделанные или отвергнутые данные в допустимый ответ.
  • Новая наблюдаемость создала цепочку хранения свидетельства. Пересылающий резолвер может скрыть, передать или заново сформулировать объяснение; при нехватке места EDE удаляется раньше основных данных; свободный текст способен раскрыть частную информацию, а без защищённой транзакции подробный диагноз остаётся неподтверждённым.

Ночная панель показывает восемь тысяч одинаковых красных отметок SERVFAIL. По счётчику невозможно понять, произошёл ли один массовый отказ авторитетных серверов, восемь тысяч повторов закэшированной ошибки или серия корректных отказов валидатора принимать повреждённые подписи. График объединяет разные истории, потому что на проводе они закончились одним и тем же результатом.

От различия зависит первое безопасное действие. При недоступной авторитетной стороне нужно исследовать маршруты и доступность. При DNSSEC Bogus переход к резолверу без проверки подписей не ремонтирует зону, а снимает требование доказательства. При Cached Error немедленный повтор к тому же узлу может лишь заново прочитать прежний отрицательный вывод.

Долгое время DNS хорошо передавал результат, но плохо передавал происхождение результата. Extended DNS Error, или EDE, не стал расширенным вердиктом. Он стал приложенным объяснением, чья полезность как раз основана на подчинённом положении.

Короткий код стирал путь к результату

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

Но SERVFAIL может возникнуть, пока сервер загружает зону, когда ни один авторитетный адрес не достижим, когда не удаётся собрать доказательство DNSSEC, когда подпись должна быть отвергнута либо когда резолвер возвращает ранее сохранённый отказ. REFUSED тоже не сообщает, неавторитетен ли сервер, запрещён ли конкретный клиент или сработало правило фильтрации.

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

RCODE при этом не ошибался. Во всех перечисленных случаях SERVFAIL мог оставаться правильным межсистемным исходом. Не хватало не нового результата, а второго, ограниченного слоя — подсказки о том, как был получен уже переданный исход.

EDNS дал расширению место сбоку

RFC 6891 ранее ввёл псевдозапись OPT и пространство опций EDNS. OPT присутствует в сообщении DNS, но не является обычными данными зоны. Это позволило наращивать возможности и метаданные, не расширяя заново каждое старое поле и не заставляя прежние реализации понимать новую семантику.

Опубликованный в 2020 году RFC 8914 закрепил за EDE номер опции 15. Полезная нагрузка начинается с 16-битного INFO-CODE. Оставшиеся октеты, если они есть, образуют необязательный EXTRA-TEXT в UTF-8.

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

EDE разрешено прикладывать к SERVFAIL, NXDOMAIN, REFUSED, NOERROR и другим кодам, если запрос содержал OPT. В ответе может быть несколько таких опций. Получатель должен уметь принять их, но не обязан действовать по каждой.

Главное ограничение сформулировано жёстко: EDE не меняет обработку RCODE. SERVFAIL с пояснением DNSSEC Bogus остаётся неуспехом. NOERROR с Stale Answer остаётся успешным классом ответа, но сообщает о возрасте данных. Объяснение сужает поиск причины, не получает права пересмотреть исход.

Валидационный сбой отделили от неопределённости

Особенно важен новый словарь для DNSSEC. RFC 4035 различает состояния Bogus и Indeterminate. В первом случае цепочка доверия должна строиться, но проверка не удаётся. Причиной может быть атака, ошибка конфигурации либо повреждение. Во втором резолвер не способен определить, должны ли данные быть подписаны, потому что не получил необходимые записи DNSSEC.

RFC 8914 выделил для этих состояний разные диагностические номера. Отдельные коды появились также для неподдерживаемого алгоритма DNSKEY, неподдерживаемого типа дайджеста DS, истёкшей или ещё не вступившей в силу подписи, отсутствующих DNSKEY и RRSIG, неснятого признака ключа зоны и недостающего доказательства NSEC.

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

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

Предупреждение оказалось совместимо с успехом

Диагностическая опция нужна не только рядом с явным отказом. Рекурсивный резолвер может не обновить истёкшие данные, но решить, что старая запись лучше полного перерыва. RFC 8767 ограничивает такую устойчивость. Код EDE 3 обозначает старый положительный ответ, а код 19 — старый NXDOMAIN.

Поэтому NOERROR и Stale Answer могут сосуществовать. RCODE характеризует текущий вид результата, а EDE — состояние и происхождение данных. Разрешение временно продолжить работу не делает запись свежей и не стирает необходимость восстановить обновление.

Похожим образом код Forged Answer сообщает, что политика изменила возвращаемые данные, хотя ответ всё же присутствует. Когда политика предотвращает ответ, разные коды описывают разные поверхности управления: Blocked относится к внутренней политике безопасности оператора резолвера, Censored — к внешнему требованию, Filtered — к фильтрации по запросу клиента.

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

У закэшированного отказа появился паспорт

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

Код Cached Error сообщает, что текущий SERVFAIL получен из такого сохранённого состояния. Он не превращает сбой в авторитетные данные зоны. Зато оператор понимает: немедленный повтор к тому же резолверу может проверить только кэш, а не заново пройти отказавший участок.

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

Посредник мог изменить голос ошибки

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

RFC 8914 оставляет решение о пересылке местной политике. Резолвер может подавить принятую EDE, передать её дальше или сформировать новую опцию, пересказывающую информацию. При передаче ему рекомендуется указать источник в EXTRA-TEXT, иначе клиент воспримет диагноз как собственное утверждение ближайшего резолвера.

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

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

В переполненном пакете объяснение жертвуют первым

Размер DNS-сообщения по-прежнему ограничен. Длинный человеческий текст способен вытолкнуть UDP-ответ за пределы размера, заявленного запрашивающей стороной. RFC 8914 требует в таком случае удалять EDE раньше остальных данных ответа и устанавливать бит усечения.

Этот приоритет выражает архитектурный договор. Диагностика полезна, но ответ и его доказательства важнее. Отсутствие EDE после усечения не означает, что сервер не распознал причину. Многословное пояснение может уничтожить собственную наблюдаемость: исчезнуть на границе размера или вынудить переход на TCP.

Одного захвата конечного пакета потому недостаточно. В журналах стоит хранить факт создания EDE, её удаления, передачи или замены, размер OPT, объявленный предел UDP, решение об усечении и выбранный транспорт. Иначе молчание невозможно отличить от диагностической информации, принесённой в жертву доставке основных данных.

Конкретный текст не получил доверия автоматически

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

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

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

Реестр параметров DNS IANA фиксирует опцию 15 и актуальные назначения INFO-CODE. Это доказывает координацию идентификаторов и ссылок. Реестр не доказывает, что конкретные резолверы создают EDE, честно её пересылают, защищают канал, показывают пользователям или правильно классифицируют сбой.

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