Кратко

  • ZONEMD связывает SOA Serial с дайджестом всей зоны в каноническом порядке, включая glue и скрытые данные. Поэтому успешно переданная копия с ожидаемой версией всё равно может быть отклонена, если её содержимое отличается.
  • DNSSEC позволяет аутентифицировать обязательство издателя; без DNSSEC дайджест защищает только от случайной порчи. Ни один вариант не доказывает правильность политики или загрузку поколения на всех узлах — для этого нужны отдельные свидетельства активации и работы.

В журнале релиза всё выглядело завершённым. AXFR дошёл до конца. Получатель записал файл и успешно разобрал его. В SOA стоял Serial из утверждённой заявки. Однако между сборкой и staging-каталогом исчезла одна glue-запись.

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

RFC 8976 определяет ZONEMD для другого утверждения. Запись на apex несёт message digest данных зоны в покое. Получатель строит ту же каноническую последовательность RR, рассчитывает собственное значение и сравнивает его с опубликованным. Один отсутствующий включаемый RR оставляет Serial прежним, но меняет дайджест. Так проверка версии превращается в проверку конкретного объекта перед активацией.

Порядок поколений не равен идентичности содержимого

Поле Serial в SOA появилось в RFC 1035. RFC 1982 описал сравнение ограниченных чисел, включая переход через максимальное значение. Вторичный сервер может локально решить, какое поколение новее, без единого мирового времени.

Serial выбирает издатель; он не вычисляется из всех RR. Две ветви сборки могут выпустить разное содержимое с одним номером. После передачи файл может измениться на диске, а SOA — остаться целой. Restore способен соединить старые данные с ожидаемым номером. Сравнение числа с таким же числом не обнаруживает ни один из этих случаев.

В RDATA ZONEMD входят Serial, Scheme, Hash Algorithm и Digest. Serial явно привязывает обязательство по содержимому к именованному поколению. SOA отвечает на вопрос, какую версию объявил издатель. ZONEMD отвечает, какое полное каноническое содержимое он закрепил за этой версией. Эти доказательства дополняют, но не заменяют друг друга.

Передача решает ещё одну задачу. RFC 1995 задаёт инкрементальный IXFR, а RFC 5936 — полную передачу AXFR. Они доставляют или реконструируют кандидата. Но после помещения в хранилище, копирования, восстановления, перезапуска и load прежняя транзакция не остаётся доказательством целостности всего объекта. ZONEMD переносит проверку за пределы канала.

SIMPLE канонизирует смысл DNS, а не оформление файла

ZONEMD получил RR type 63. Стандартизованная схема SIMPLE имеет значение 1 и обязательна к поддержке. SHA-384, Hash Algorithm 1, также обязателен; публикуются все 48 октетов. SHA-512, Algorithm 2, следует поддерживать с полными 64 октетами. Текущее распределение кодов хранит реестр параметров DNS IANA.

SIMPLE не хеширует буквальный текст master file. Комментарии, пробелы и регистр могут отличаться при одинаковых DNS-данных. RR переводятся в несжатый canonical wire format и сортируются по RFC 4034; RRsets одного owner дополнительно упорядочиваются по числовому RR TYPE. Два по-разному оформленных файла могут дать один результат, но семантическое отличие не скрывается форматированием.

Правила включения охватывают всю зону, кроме явных исключений. Glue учитывается. Occluded data учитываются. Полностью одинаковые дубликаты входят один раз. Данные вне зоны не становятся частью обязательства из-за соседства в файле. В подписанной зоне учитываются DNSSEC RR, кроме apex ZONEMD placeholder и RRSIG, которая позднее покроет итоговый ZONEMD RRset.

Эта полнота не заменяет DNSSEC. DNSSEC аутентифицирует RRsets и доказательства существования или отсутствия, необходимые при проверке ответов. Полная зона как распространяемый артефакт включает делегационные и glue-данные, которые защищены не так, как обычный подписанный authoritative RRset в child. ZONEMD связывает весь объект для авторитетных серверов, репозиториев и других получателей полной копии.

Цена следует из полноты. При изменении одного RR SIMPLE снова проходит всю зону. RFC 8976 считает подход более подходящим для небольших или стабильных зон и потенциально непрактичным для крупных или динамичных. Решение должно опираться на замеры: расчёт и проверка обязаны помещаться с запасом в минимальный интервал обновления и распространения, включая повтор после сбоя.

Последовательность публикации не даёт подписи сдвинуть собственную цель

Если добавить ZONEMD после DNSSEC-подписи, изменятся type bitmaps NSEC или NSEC3 на apex. Поэтому старые ZONEMD и покрывающие подписи сначала удаляются, а placeholder добавляется до подписания. Доказательства отсутствия сразу отражают присутствие нового типа.

После подписи рассчитывается SIMPLE digest по канонической последовательности. Apex placeholder не входит, как и RRSIG, которая должна покрыть финальный ZONEMD RRset. Затем временное значение заменяется результатом, а соответствующая подпись создаётся или обновляется.

Создание подписи ZONEMD не должно снова увеличивать SOA Serial. Соответствующие SOA и ZONEMD публикуются одновременно. Иначе действие, аутентифицирующее обязательство, изменило бы поколение, которое это обязательство описывает.

Поэтому для доказательства недостаточно сохранить шестнадцатеричную строку из запроса. Публикационный receipt связывает source snapshot, утверждённую политику, версии builder и signer, Serial, Scheme, алгоритм, Digest, контекст DNSSEC-ключей и момент атомарного переключения. Только такая цепочка показывает, где возникло расхождение: в источнике, сборке, подписи или распространении.

Проверка начинается с ожидаемого уровня защиты

Получатель сначала определяет, должен ли присутствовать DNSSEC. Основанием служат локальные trust anchors и, для нерутовой зоны, при необходимости валидированная DS-цепочка в parent. Контекст проверки задаёт RFC 4035.

Если подписи ожидаются, проверяются существование apex ZONEMD и подписи SOA и ZONEMD. Доказанное DNSSEC отсутствие означает, что digest verification не может состояться. Если RRset должен существовать, но его нет в полученной копии, результат не является успешным. Не допускается и тихое понижение невалидной подписи до checksum только потому, что локальное значение совпало.

Затем проверяется структура. В RRset с несколькими ZONEMD каждая пара Scheme/Hash Algorithm должна быть уникальна. Локальная политика может игнорировать неприемлемую пару. Для каждого разрешённого кандидата Serial обязан точно совпасть с SOA, схема и алгоритм — поддерживаться, длина — быть корректной, а рассчитанный Digest — равняться полученному.

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

Статус должен содержать причину. Ожидаемый ZONEMD отсутствует, DNSSEC chain недоступна, Serial различается, пара дублируется, схема не поддерживается, длина неверна и содержимое не совпало — это разные домены отказа. Один красный индикатор стирает данные, необходимые для retry, карантина, rollback или эскалации.

Без DNSSEC злоумышленник пересчитает и дайджест

В неподписанной зоне ZONEMD работает как checksum против случайного усечения, ошибки передачи или порчи хранения, пока исходный Digest остаётся неизменным. Тот, кто способен намеренно изменить зону, способен рассчитать новое значение и заменить запись. От такого противника реальной защиты нет.

DNSSEC делает удаление или изменение обязательства обнаружимым и аутентифицирует SOA/ZONEMD до trust anchor. Но доказано лишь то, что уполномоченный издатель закрепил именно это содержимое. Уполномоченный процесс может безупречно подписать ошибочную делегацию. Совпадение не подтверждает право собственности, легитимность заявки, корректность политики, безопасность приложения или фактическую загрузку на всей флоте.

TSIG защищает другую границу. RFC 8945 аутентифицирует DNS-транзакции общим секретом и полезен для AXFR/IXFR peers. После записи, копирования, restore или reload MAC прежней транзакции не остаётся прикреплённым к полной зоне. ZONEMD позволяет повторно проверить объект после завершения канала.

Даже подписанное доказательство ограничено временем. Удаление DS или смена trust anchor может помешать исторической проверке, хотя ZONEMD RRSIG выглядит действующей по собственным срокам. Долговременный архив сохраняет контекст доверия, применённый в момент активации, а не только файл зоны.

Отказ от неверной зоны может стать отказом в обслуживании

Сервер может проверить кандидата в staging и не выполнять load при несовпадении. Так повреждённая копия не становится authoritative state.

Тот же контроль создаёт хрупкость доступности. Ошибка публикации, различие canonicalization или потерянный RR при проверке похожи на умышленное вмешательство. Hard fail делает недоступными и корректные данные зоны. Если несколько провайдеров реагируют по-разному, пользователи в разных сетях видят разные поколения.

Поэтому RFC 8976 допускает постепенное внедрение: сначала warning, затем error после накопления опыта. Документ ICANN RZERC003 рассматривал введение ZONEMD в root zone как координацию между Maintainer, операторами, разработчиками и пользователями локальных копий. Из этого не следует универсальная root-политика; следует необходимость согласовать несколько доменов отказа до enforcement.

Зрелая политика различает три пути. Проверенный кандидат допускается к активации. Несовпавший уходит в quarantine, а ранее проверенное поколение продолжает работу ограниченное время. Неполное свидетельство — например, сбой trust chain вместо различия содержимого — требует временного и атрибутированного решения fail-open или fail-closed.

Предыдущее поколение не может служить бесконечно. Известная целостность сохраняется, свежесть расходуется. Refresh, expire, темп изменений и последствия определяют staleness budget. Rollback должен быть испытан как самостоятельный процесс: объект сохранён, независимо перепроверен, загружается и наблюдается в авторитетных ответах.

Активационный receipt должен дойти до выдаваемого ответа

Авторитетный DNS может распределяться между провайдерами и множеством anycast-площадок, как описывает RFC 8901. Успешная проверка на staging-host не доказывает загрузку всей флоты. Успешный reload API не доказывает ответы процесса. Запрос в одном catchment не охватывает остальные.

Receipt соединяет пять границ. У издателя — source, Serial и подписанный Digest. В транспорте или репозитории — identity объекта, размер, локальный hash и custody events. У verifier — ожидаемый DNSSEC, trust anchors, разрешённая пара, вычисленное значение и причина. При активации — старое и новое поколения, решение и load result. В runtime — SOA, ZONEMD и выбранные включённые RR по требуемому охвату.

Canaries не должны ограничиваться SOA, иначе повторят исходную слепую зону. Они проверяют чувствительные к делегациям имена, выбранный glue, подписанные RRsets и отрицательные ответы, сохраняя authoritative identity и точку наблюдения. Hyperlocal root по RFC 8806 требует собственного доказательства для локальной копии и refresh path; состояние публичной root-флоты не доказывает состояние локального resolver.

Закрытие требует отрицательного свидетельства. После отказа или отката отвергнутые Digest и поколение должны исчезнуть из staging eligibility, работающих процессов и выборочных ответов. Наличие правильной версии в нескольких местах не исключает забытый узел с неправильной.

Источники