Кратко

  • ZONEMD связывает каноническое содержимое всей зоны с конкретным серийным номером SOA; для доказательства происхождения, а не только случайной порчи, требуется DNSSEC.
  • Совпадение означает, что полученная копия соответствует объекту издателя. Оно не подтверждает правильность записей и не решает, всегда ли блокировка кандидата безопаснее последней заведомо исправной зоны.

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

RFC 8976 добавляет к зоне переносимый дайджест. Зоны распространяются по AXFR, IXFR, через файлы, архивы и политические ленты. Защита канала подтверждает передачу, но не обязательно остаётся с объектом после сеанса. ZONEMD позволяет проверить автономную копию позднее.

Значимая запись находится на вершине зоны и имеет тип 63. В ней четыре поля: серийный номер SOA, схема колляции, алгоритм хеширования и дайджест. При проверке номер ZONEMD обязан точно совпадать с SOA, связывая доказательство с конкретной версией.

Схема SIMPLE использует канонический wire-формат и порядок DNSSEC из RFC 4034. Комментарии, пробелы, регистр и текстовый порядок не меняют идентичность. Glue и скрытые делегированием данные включаются, идентичные дубликаты учитываются один раз. Временный ZONEMD на вершине и покрывающая его RRSIG исключаются. Вне вершины ZONEMD не имеет проверочного смысла по этой спецификации.

В актуальном реестре IANA SIMPLE имеет номер 1, SHA-384 — 1, SHA-512 — 2. SIMPLE/SHA-384 обязателен для поддержки. Во время перехода допустимы разные уникальные пары; достаточно совпадения по поддерживаемой и разрешённой локальной политикой паре. Старую пару после перехода следует убрать, иначе остаётся более слабый путь принятия.

Проверка начинается с ожидания DNSSEC. Получатель использует локальные якоря и проверенный DS родителя, чтобы установить, должна ли зона быть подписана и должен ли существовать ZONEMD. Затем валидируются SOA и ZONEMD, отклоняются повторяющиеся пары, проверяются серия, схема, алгоритм и длина. Только после этого вся зона канонизируется и сравнивается.

В неподписанной зоне злоумышленник может изменить и записи, и дайджест. ZONEMD остаётся полезной контрольной суммой против обрыва, случайной порчи или расхождения копий, но не доказывает источник. DNSSEC привязывает утверждение к принятому доверию; общую модель и ограничения описывает RFC 4033. DNSSEC защищает RRset, ZONEMD добавляет целую зону — это взаимодополнение.

Но и вместе они не понимают деловой смысл. Ошибочно удалённый MX, адрес резерва вместо основного или чрезмерная RPZ-запись могут быть легитимно опубликованы и корректно подписаны. Совпадение отвечает, кто опубликовал какой объект, а не были ли верны заявка, договор и профессиональное решение.

Документация реализаций показывает отдельность последствий. Knot DNS разделяет zonemd-verify при загрузке/обновлении и генерацию SHA-384/SHA-512; по умолчанию они не действуют, а большие зоны требуют времени и CPU. Unbound отдельно настраивает проверку, отказ при отсутствии и разрешительный режим, который журналирует ошибку без блокировки. PowerDNS предлагает явную проверку файла. Поддержка типа 63 не равна единой политике остановки.

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

RFC 5936 даёт полезный принцип AXFR: принять и проверить кандидата, после успеха атомарно загрузить; при ошибке удалить кандидата и продолжить обслуживать прежнюю версию. ZONEMD усиливает проверку кандидата, но не требует уничтожать последнюю исправную копию.

Старой копии нужен предел возраста. Риск устаревания различен для локального корня, корпоративной зоны и RPZ. Локальная политика задаёт срок, эскалацию и владельца исключения — общий дайджест не знает ущерба конкретного сервиса.

Доказательство также зависит от времени. SOA и соответствующий ZONEMD публикуются вместе; подпись ZONEMD не должна снова изменить SOA. После смены KSK даже ещё действующая подпись может стать непроверяемой, если нужный DS или якорь уже недоступен.

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

Аудит должен разделять кандидата, каноническую идентичность, происхождение DNSSEC, семантику, локальный допуск, загруженную версию и наблюдаемые ответы. Работы Heng Lu о приоритете работающего кода, минимальной начальной спецификации и локальном будущем решении и слоях реальности дают дисциплину: общая проверка может быть детерминированной, а последствия остаются за оператором.

На странице errata RFC 8976 зафиксирована техническая поправка: в примере приложения частный SHA-384 показан слишком коротким. Нормативные 48 октетов не меняются. Открытая запись такого ограничения — часть целостности источников.

Поэтому «дайджест совпал» — не финал. Нужны серия, цепочка доверия, алгоритм, версия проверяющего ПО, решение о карантине или допуске, срок старой зоны и подтверждение фактических авторитетных ответов. Лишь эта цепочка превращает криптографический факт в операционное доказательство.