Кратко

  • 28 августа 2026 года IETF открыла до 11 сентября Last Call по проекту Best Current Practice для движков публикации RPKI и репозиториев RRDP и rsync. Документ пока не стал утверждённой BCP.
  • Новая notification не должна становиться видимой раньше связанных snapshot и delta. При нескольких backend-узлах запросы должны оставаться в одной согласованной версии либо данные должны попасть на все узлы до открытия уведомления хотя бы на одном.
  • Новые session и serial подтверждают ответ одной точки. Они не подтверждают доступность всех байтов, RPKI-валидацию, изменение результата RP, применение в маршрутизаторе или движение пакетов.

Relying party получает notification с новым serial и ссылкой на delta. Следующий запрос балансировщик отправляет на другой узел. Уведомление туда уже скопировали, delta — ещё нет. Клиент получает 404. Затем старая keepalive-сессия приводит его к выведенному из пула серверу, где serial меньше.

Криптография здесь может быть исправна. Несогласованность создал сам порядок раскрытия состояния.

Last Call от 28 августа делает этот механизм текущим вопросом для сообщества. Проект руководства принимает комментарии до 11 сентября. Это ещё не окончательный консенсус и не свидетельство происшествия у конкретного оператора.

Указатель обязан ждать содержимое

RFC 8182 разделяет notification, snapshot и delta. Уведомление сообщает session, serial и адреса синхронизации. Публикуя его, сервис заявляет не только о наличии XML-файла, но и о готовности всех ссылок.

На одном сервере можно полностью записать данные и последним шагом заменить указатель. В кластере есть два пути. Привязка последовательных запросов к одному узлу сохраняет его локальную хронологию. Глобальный порядок сначала разносит snapshot и delta на все узлы, а затем открывает notification. Оба варианта запрещают клиенту соединять новый индекс со старым хранилищем.

В публичную поверхность входят CDN и кэш. Кэшированный до создания файла ответ 404 способен скрывать уже готовую delta. Слишком долгий кэш notification задерживает состояние. Keepalive к отключённому серверу продолжает отдавать старую session. Поэтому отчёт оркестратора — намерение; внешний canary, прошедший реальный путь, — наблюдение.

Регрессия serial также не имеет единого толкования. RFC 8182 не задаёт обязательную реакцию RP. Некоторые реализации заново загружают snapshot. Это способ восстановления, а не доказательство, что большее число свежее и правильнее.

Ошибка в малом файле порождает большие загрузки

После неудачной delta RP может запросить более крупный snapshot. Если не удался и он, происходит переход на rsync. В следующем цикле RRDP клиент снова может начать со snapshot. Преждевременная notification превращает инкремент в повторные полные передачи для множества клиентов.

Проект рекомендует следить за пропускной способностью, памятью, дисковым I/O и неожиданными переходами на snapshot с помощью canary RP вне сети оператора. Объём нужно связывать с session, serial, backend, URI, возрастом кэша и HTTP-результатом. Иначе обычный спрос и восстановительная петля выглядят одинаково.

Старые snapshots и deltas предлагается сохранять ещё два часа после исчезновения ссылок из текущей notification. Это помогает медленным запросам, но защищает прошлое. Оно не создаёт новую delta, которая должна была появиться раньше её индекса. Ограничение генерации delta примерно одним разом в минуту снижает нагрузку, но не отменяет порядок.

В цепочке публикации нет универсальной квитанции

CA создаёт подписанные объекты и передаёт изменения в publication engine по RFC 8181. Запрос list перед обновлением показывает расхождение состояний. Несколько PDU в одном multi-element query уменьшают риск частичного применения единой операции.

Дальше каждый документ говорит только за себя. Реестр CA отражает намерение. Ответ RFC 8181 — приём движком. Notification — объявление endpoint. HTTP-загрузка — полученные байты. RP отдельно проверяет сертификаты, manifest, CRL и подписанные объекты. Затем следуют передача результата маршрутизатору, локальная политика, FIB и наблюдение пакета.

Доступный объект может отсутствовать в действующем manifest или не пройти хэш и цепочку. Валидная ROA не доказывает наличие текущего BGP-анонса. Это практический пример слоёв реальности Heng Lu: индекс, объект, решение и результат нельзя сжимать в один зелёный статус.

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

Растущий serial не является часами

Serial задаёт последовательность внутри session. Он не измеряет возраст или истинность. Задержанные данные могут идти под растущими номерами; свежий объект может не пройти проверку.

Если восстановление из старой копии вернуло содержимое назад, проект требует reset RRDP session и рекомендует уведомить зависимые CA о полной синхронизации. Reset честно обозначает разрыв. Он не восстанавливает утраченные ROA, недавно созданных publishers или истекающий manifest.

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

Notification-last не доказывает правильность маршрута. Оно делает проверяемым первый публичный шаг: названные байты уже существуют там, где клиент должен их получить.

Sources