Кратко

  • В сохранённом 14 сентября 2026 года уведомлении RRDP AFRINIC находились 32 последовательные дельты — с серийного номера 96961 по 96992.
  • Публичные отметки Last-Modified первой и последней дельты разделяли 425 минут, однако это наблюдение не гарантирует семичасовой запас для восстановления.
  • По RFC 8182 догнать текущее состояние по дельтам можно, только если доступна вся недостающая последовательность; иначе полагающаяся сторона обрабатывает текущий снимок.
  • Публичная квитанция непрерывности могла бы связать номера со временем, байтами, сменой сессии и проверенным переходом к снимку, не раскрывая пользователей валидаторов.

Как один пропущенный номер меняет задачу

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

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

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

Что было видно в момент фиксации

В 16:49 UTC 14 сентября уведомление RRDP AFRINIC указывало сессию 8fe3109e-2561-4627-8850-83ab94b9bb91 и текущий номер 96992. Оно содержало 32 ссылки на дельты. После сортировки получалась непрерывная последовательность от 96961 до 96992.

Для уведомления был задан max-age=60 и режим stale-if-error. RFC 8182 рекомендует не кешировать постоянно меняющееся уведомление дольше одной минуты. Наблюдавшееся значение соответствует этой рекомендации и не является предметом критики.

Заголовки HTTP дали две временные точки. У дельты 96961 значение Last-Modified было 07:40:05 UTC, у 96992 — 14:45:06 UTC. Разница составила 425 минут. Текущий снимок находился на том же источнике rrdp.afrinic.net и в ограниченной проверке ответил HTTP 200.

Так выглядит достоверная фотография одной публикации. Она не превращает 32 версии в обещание семи часов и пяти минут.

Серийные номера движутся с публикациями

Номер увеличивается при выпуске новой версии репозитория. Сертификаты, CRL, манифесты, ROA и другие объекты меняются неравномерно. Во время законного пакета обновлений много номеров может появиться быстро; в спокойный период те же 32 шага охватят больше времени.

Начало цепочки зависит и от размера. RFC 8182 требует исключать старые дельты, когда их совокупный объём вместе со всеми более новыми станет больше снимка. Это защищает клиента от «инкрементального» пути, который тяжелее полной загрузки. Следовательно, первый публикуемый номер — граница эффективности, которую выбирает репозиторий, а не срок хранения в часах.

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

Квитанция, понятная оператору

Практика сертификации RPKI AFRINIC подтверждает поддержку RRDP и называет адрес уведомления. Документ описывает метод, а живая публикация — текущую сессию. Между ними можно разместить узкий, не персональный журнал непрерывности.

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

Показатели следует держать раздельно. Доступность HTTPS не доказывает корректность каждого подписанного объекта. Корректная криптографическая проверка не определяет политику BGP. CDN, механизм публикации, обработка валидатора и решение сетевого оператора — связанные, но самостоятельные поверхности контроля.

Никакого вывода об отказе

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

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

Основные источники