Кратко

  • RFC 9432 помещает перечень зон-участников и их свойства в обычную DNS-зону. Потребитель может автоматически добавить, удалить или перенастроить участника; его авторитетные данные передаются отдельно.
  • Корректность схемы версии 2, аутентификация партнёра, локальная допустимость имени, право каталога распоряжаться состоянием и фактическое применение в работающем сервере — разные доказательства.
  • Безопасный потребитель сохраняет последний валидный мир при поломанном каталоге, ограничивает допустимых участников независимо от канала, ведёт происхождение по каталогу и метке, останавливает массовые изменения, архивирует восстанавливаемое состояние и проверяет внешние авторитетные ответы.

Авария, в которой всё было зелёным

Система учёта формирует каталог для большого парка вторичных DNS-серверов. После изменения прав доступа запрос к учёту возвращает пустой набор. Генератор воспринимает его как достоверный результат, повышает SOA serial и выпускает новую зону с корректными SOA, NS и единственным version со значением 2.

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

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

При разборе инцидента недостаточно показать подпись транзакции и serial. Нужно восстановить, что видел генератор, какой нормализованный diff получил потребитель, почему локальная политика допустила его, каким состоянием каталог имел право распоряжаться и что в итоге отвечал DNS.

Каталог управляет присутствием, а не содержимым

Catalog Zone — обычная DNS-зона со специальной интерпретацией. PTR под zones называют участников, уникальная метка связывает с ними свойства, а TXT version задаёт версию 2. Переносится этот объект через AXFR или IXFR.

Записи A, AAAA, MX, NS и DNSSEC самой зоны-участника в каталоге не находятся. После добавления участника потребитель создаёт локальную конфигурацию и отдельно получает его данные от первичных серверов.

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

Доказательство должно пройти весь путь: каталог, решение допуска, активная конфигурация, трансфер участника, загрузка и внешняя авторитетная проверка.

Пять вопросов вместо одного статуса

Правильна ли структура? Версия должна быть единственной и поддерживаемой. PTR RRset участника содержит одно значение. Разные метки не должны повторять одну зону. Известное свойство неправильной формы ломает каталог. Неподдерживаемые записи игнорируются.

Кто передал объект? TSIG аутентифицирует DNS-транзакцию. Зонный трансфер поверх TLS может защитить канал и конфиденциальность. Эти средства подтверждают настроенного партнёра и наблюдаемое сообщение, но не внутренний запрос к его базе клиентов.

Что ему разрешено конфигурировать? RFC 9432 отмечает, что административный контроль над обслуживаемыми зонами полностью переходит к производителю каталога, и советует потребителю ограничивать допустимых участников регулярным выражением, другой базой или иным подходящим способом.

Чьё состояние предлагается удалить? Каталог может удалить зону и связанные данные лишь тогда, когда именно он изначально создал эту конфигурацию.

Что произошло в работающей системе? Запись в хранилище конфигурации не равна загрузке зоны, а загрузка на одном узле не равна согласованному авторитетному ответу всего парка.

Ответ «catalog valid» относится только к первому вопросу.

Поломанный каталог безопаснее правдоподобной ошибки

Если отсутствует версия, повторяется участник или нарушена форма известного свойства, потребитель не должен обрабатывать объект как каталог. Когда ранее корректный каталог становится поломанным, уже настроенных участников нельзя удалять или перенастраивать. После перезапуска следует продолжать обслуживать последний валидный набор.

Так сохраняется известное состояние при входе, который нельзя однозначно понять. Но пустой каталог можно понять однозначно, и в этом его опасность. Он способен соответствовать всем правилам версии 2 и всё же быть результатом отказа учёта.

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

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

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

Когда участник исчезает из конкретного каталога, потребитель не имеет права удалять зону и её состояние, если она была создана статически или другим каталогом. Исходный каталог — часть полномочия, а не справочная метка.

Локальный реестр должен связывать имя с каталогом происхождения, уникальной меткой, первым принятым serial, применённым профилем, созданными хранилищами и последующими изменениями. Текущий перечень активных зон этой истории не содержит.

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

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

Метка без смысла задаёт смысл миграции

Уникальная метка участника не обязана описывать зону. Тем не менее её изменение трактуется как удаление и немедленное новое добавление, то есть как сброс связанного состояния.

В coo метка определяет, перейдёт ли состояние к новому каталогу. Старый каталог указывает новый; потребитель ждёт появления участника у нового и повторно проверяет, что указание старого ещё действует. Затем одинаковая метка позволяет сохранить состояние.

Это удобно для согласованной смены оператора, но способно передать журналы, таймеры, ключи и частные данные без отдельного решения. Если передача не нужна, старый владелец должен изменить метку и вызвать сброс до coo или одновременно с ним.

Кроме того, потребители могут увидеть две стороны миграции в разном порядке. Добавление в новом каталоге до обработки удаления в старом выглядит как конфликт имени. Часть восстановления RFC оставляет за пределами протокола; может потребоваться принудительный повторный трансфер и диагностика каждого потребителя.

group и ext действуют только по местному соглашению

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

Свойства под ext являются частными для реализации и не обещают универсальной совместимости. Реестр IANA для версии 2 включает zones, version, coo, group и пространство *.ext. Регистрация координирует имена, но не превращает частное слово в глобальную команду.

Это соответствует Minimum Initial Specification Хэн Лу: общая часть остаётся малой, детерминированной и локально проверяемой. Последующие решения принимают участники. Публикация свойства — лишь предложение; реальностью оно становится после добровольной реализации и наблюдаемого исполнения.

Реализации расширяют модель по-разному

BIND документирует автоматическое добавление, удаление и перенастройку, версии 1 и 2, сброс по изменению метки и coo. Минимальный интервал регулирует темп, но не проверяет содержание.

Knot DNS связывает группы с локальными профилями и указывает, что исключённый участник очищается немедленно вместе с зонным файлом, журналом, таймерами и ключами DNSSEC, с описанным исключением для файла. Обновление каталога может вызвать и более широкую перезагрузку зон.

PowerDNS документирует роли производителя и потребителя версии 2, coo, несколько групп и уникальное значение, сигнализирующее сброс. Поддерживаемые backend-системы и свойства имеют собственные границы.

Поэтому совместимость с RFC 9432 — начало проверки, а не её итог. Для каждой версии нужны опыты с поломанным и пустым каталогом, конфликтом, неизвестной группой, удалением, сменой метки, неполной миграцией, перезапуском и восстановлением. Running-Code Primacy требует наблюдать бинарный результат.

Досье, которое связывает решение с пакетом

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

Для удаления добавляются инвентарь состояния, идентификатор архива, время очистки и крайний срок восстановления. Для coo — наблюдения обоих каталогов, сохранение или сброс метки и явное решение о передаче состояния. Секреты и полный чувствительный каталог не попадают в обычные журналы.

Такое досье отвечает без догадок: что опубликовал производитель; кого подтвердил канал; что допустил потребитель; каким состоянием каталог имел право распоряжаться; что выполнила программа; что смог разрешить пользователь.

Источники