Кратко

  • RFC 8901 — информационный документ, отражающий консенсус IETF, а не обязательный стандарт и не доказательство поддержки многоподписной DNSSEC конкретным провайдером.
  • В обеих моделях DNSKEY RRset каждого провайдера содержит активные ZSK всех участников. Иначе резолвер может закешировать ключи A, при переключении получить подпись B и отвергнуть ответ.
  • Владелец зоны до аварии координирует обмен ключами, связь KSK с DS родителя, общие алгоритмы и сроки ротации. Второй поставщик остаётся лишь возможным путём, пока эта цепочка доказательств не собрана.

Сервер доступен, а цепочка проверки — нет

Два независимых провайдера подписывают и обслуживают одну зону. Валидирующий резолвер проходит secure delegation, получает у Provider A набор DNSKEY, проверяет его через родительский DS и сохраняет в кеше. Пока запись ещё действительна, A становится недоступен. Резолвер обращается к B, который возвращает данные с RRSIG от собственного ZSK.

B работает, но ответ может оказаться бесполезным. Если в наборе от A нет активного ZSK провайдера B, у резолвера нет аутентифицированного открытого ключа. Он может опросить другие серверы, увеличить задержку или исчерпать попытки раньше клиента. RFC 8901 не меняет резолвер; она требует общего публичного состояния, с которым обычная проверка переживает смену пути.

Разные сети, договоры и записи NS показывают возможные авторитетные пути. Они не доказывают, что подпись B проверяется состоянием, полученным у A. Резервирование завершено лишь тогда, когда переключается и криптографический путь.

Две модели хранения, один инвариант

В модели 1 владелец зоны хранит общий KSK и управляет DS родителя. У каждого провайдера свой ZSK. Владелец собирает открытые ZSK, строит общий DNSKEY RRset, подписывает KSK и раздаёт всем. Даже без изменения ключей подпись набора нужно обновлять до истечения срока.

У родителя один вход, а провайдеры показывают один подписанный объект. Однако хранение KSK, периодическая подпись, доступ к API и доставка превращаются в общую критическую поверхность. Одна устаревшая копия разделяет эксплуатационную реальность.

В модели 2 у каждого провайдера собственные KSK и ZSK. Каждый импортирует открытые ZSK остальных и подписывает DNSKEY своим KSK. Родитель публикует DS для каждого KSK. Закрытые ключи распределены, но общего публичного состояния больше: ротация KSK у A меняет его путь в родителе, а ротация ZSK меняет DNSKEY, который обязан публиковать B.

Ротация — распределённая транзакция

В модели 1 A не может сразу подписывать новым ZSK. Владелец получает ключ, добавляет его в общий набор, подписывает и развёртывает у всех. Активация ждёт распространения и TTL DNSKEY; удаление старого ключа — пока данные и кеши от него больше не зависят. Смена KSK дополнительно проходит через родительский DS.

В модели 2 A может подписать свой DNSKEY, но передаёт новый ZSK владельцу для импорта у B. Использование в обычных данных ждёт импорта, распространения на всех авторитетных поверхностях и TTL. Удаление проходит тот же путь в обратном порядке.

«Ключ создан», «API 200» или одна правильная выборка не являются квитанцией непрерывности. Надёжная последовательность фиксирует экспорт, принятие владельцем, импорт у каждого провайдера, публикацию на каждой поверхности, истечение TTL, независимую проверку ответов A и B, и только затем активацию или вывод.

Алгоритмы и отрицательные ответы

Участники используют общий алгоритм DNSSEC или один набор алгоритмов. Если DNSKEY объявляет несколько, требования RFC 4035 распространяются на RRsets зоны. Несовместимые решения не становятся совместимыми из-за двух компаний.

Доказательства NSEC или NSEC3 находятся в отрицательном ответе, поэтому разные методы технически возможны. Но смешение NSEC и NSEC3 отменяет защиту NSEC3 от простого перечисления, а постоянные различия снижают эффективность отрицательного кеша. RFC 8901 предпочитает один метод и минимальные различия.

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

Чего документ не доказывает

RFC 8901 не доказывает поддержку API, внедрение, измеренный сбой, прирост доступности или распространённость. DNSSEC-валидация также не доказывает коммерческие полномочия, здоровье приложения или переключение трафика; она подтверждает ограниченную криптографическую связь наблюдаемых данных.

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

Источники