Кратко

  • Положительный Delegation Type в подписанной зоне может быть принят и при снятом ADT, но это не создаёт обязательства проверять его наличие в последующих referrals.
  • Криптографическая защита от удаления новых данных возникает только при сочетании подписи зоны, установленного ADT, DNSSEC-валидации и проверки NSEC или NSEC3; частичное развёртывание оставляет разрыв.

Миграция выглядела почти завершённой. В родительской зоне появились новые записи делегирования, они были подписаны, совместимые резолверы их читали. Флаг ADT планировали включить на следующем этапе, после дополнительного наблюдения. В этот промежуток злоумышленник мог удалить новые записи из referral и оставить традиционный NS, не нарушив обязательство, которого зона ещё не объявила.

Данные уже говорили: «новый механизм существует». Ключи ещё не говорили: «его отсутствие должно считаться вмешательством».

Именно эту переходную щель описывает revision 11 документа DNS Protocol Modifications for Delegation Extensions. Internet-Draft датирован 17 сентября 2026 года, истекает 21 марта 2027 года и остаётся активной работой DNSOP для Standards Track. Это не окончательный RFC, не отчёт о внедрении и не свидетельство поддержки конкретным продуктом. Нормативные требования проекта нельзя выдавать за наблюдаемую практику.

Три разных состояния миграции

Первое состояние — способность понимать формат. Проект предлагает бит 2 EDNS(0) для DE. Совместимый резолвер устанавливает его в запросе; совместимый рекурсивный резолвер возвращает бит совместимому stub, сообщая о поддержке Delegation Types.

Второе состояние — наличие самих данных. При DE=1 авторитетный сервер включает в referral типы NS-Omitting, NS-Preserving и Private, существующие в точке делегирования. On-Demand-типы без явного запроса не включаются.

Третье состояние — аутентифицированное обязательство обнаруживать отсутствие данных. Его создаёт ADT, предложенный для бита 14 DNSKEY. Валидатор получает ADT из уже проверенного DNSKEY RRset делегирующей зоны. Если хотя бы один ключ несёт ADT, referral обязан содержать NSEC- или NSEC3-доказательство наличия или отсутствия Delegation Types.

Эти состояния могут появиться не одновременно. Программное обеспечение способно понимать DE, зона — публиковать подписанный новый тип, но ADT — оставаться снятым. Называть такой этап «защищённым внедрением» значит присвоить данным свойство, которое ключевой материал ещё не обещал.

Положительная подпись не доказывает отсутствие удаления

Подпись Delegation Type RRset позволяет проверить запись, если она пришла. ADT решает иной вопрос: что должен сделать валидатор, если запись не пришла.

При установленном ADT валидатор сопоставляет NS-Omitting, NS-Preserving и Private RRsets в Authority section с Type Bit Maps аутентифицированного NSEC или NSEC3. Если карта говорит, что тип есть, а referral его не содержит, ответ считается изменённым и игнорируется. On-Demand может присутствовать в карте и отсутствовать в обычном referral — это предусмотрено его семантикой.

При снятом ADT такая проверка согласованности не применяется. Проект отдельно указывает, что положительный DELEG RRset не следует объявлять DNSSEC-bogus лишь из-за снятого ADT. Полученная подписанная запись может быть валидной. Но атакующий способен добиться ситуации, где она вообще не будет получена, а валидатор не имеет объявленного ключами основания требовать доказательство её существования.

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

DE можно удалить из текущего запроса

Если авторитетный сервер получает DE=0, он действует в режиме совместимости и рассматривает новые типы как обычные данные. Там, где есть NS, он может вернуть традиционный referral. Там, где новых типов достаточно для делегирования и NS уже нет, старый клиент получит отрицательный ответ.

Злоумышленник на пути может снять DE до авторитетного сервера. Сервер корректно ответит так, будто клиент не умеет новый механизм. Можно также удалить NS-Omitting RRsets и связанные доказательства из ответа, оставив неподписанный NS. Эхо DE между stub и рекурсивным сервисом не подписывает участок до авторитетной зоны.

ADT противостоит этому потому, что обязательство живёт не в изменяемом запросе, а в ранее проверенном DNSKEY RRset. Даже после удаления DE валидатор ожидает доказательство. Но только если зона подписана, ADT установлен, DNSSEC действительно проверяется и правило исполняется.

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

Номер типа задаёт политику referral

Предлагаемый диапазон 0xF0000xF1FF разделён по поведению. 0xF0000xF07F — NS-Omitting: данных достаточно без NS. 0xF0800xF0FF — NS-Preserving: они дополняют NS. 0xF1000xF1EF — On-Demand. 0xF1F00xF1FF — Private Use с сохранением NS.

При наличии любого NS-Omitting-типа сервер не включает NS, даже если рядом есть сохраняющие типы или запрос был QTYPE=NS. Резолвер использует новые данные, а присутствующий NS игнорирует, не валидирует и не кэширует. Без NS-Omitting основой остаётся NS.

Следовательно, распределение кода — часть протокола. Если тип, предназначенный заменить NS, попадёт в сегмент NS-Preserving, универсальная реализация, ещё не знающая этот конкретный тип, выполнит неверную политику. Expert Review должен проверять соответствие сегмента, безопасность обработки неизвестного типа и совместимость с DNSSEC, а не только уникальность номера.

Переход запрещает удобный скрытый откат

Если резолвер знает, что NS-Omitting RRset существует, но его содержимое непригодно, он не должен возвращаться к NS. Он рассматривает SLIST так, будто она содержит недоступные серверы. Цель — не допустить тихого возврата к обычному, потенциально незашифрованному DNS-транспорту.

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

С другой стороны, обнаруженный downgrade может закончиться отказом без ответа пользователю. Это правильный безопасный результат, но не успех сервиса. Панель должна показывать оба факта, не награждая слабый fallback за доступность и не скрывая влияние корректного отказа.

Отрицательный ответ остаётся отрицательным

Когда делегирование состоит только из новых типов и не имеет NS, неосведомлённый резолвер с DE=0 получает отрицательный ответ. Серверу рекомендуется добавить EDE 34 “New Delegation Only”. Код объясняет несовместимость, но не добавляет клиенту нужную функцию.

Удаление DE может использоваться для отказа в обслуживании. При валидированном ADT отрицательный ответ должен нести требуемое NSEC/NSEC3-доказательство; голый ответ отклоняется. Для Compact Denial of Existence нельзя использовать NXNAME-ответ, скрывающий биты типов в точке делегирования: нужно обычное доказательство Name Error.

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

Кандидат ещё не использован

Проект расширяет SLIST: теперь это множество, способное хранить разные виды делегирования, а одинаковое значение представляется один раз. Циклические зависимости и неограниченная обработка всё равно возможны, поэтому нужны пределы.

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

Полная трасса должна разделять DE на каждом участке, проверенный DNSKEY и ADT, NSEC/NSEC3, сегмент типа, решение об NS, кандидатов SLIST, реально выбранный сервер, транспорт и конечный ответ. Тогда видно, где именно закончилась миграция.

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

Источники