Кратко

  • В уведомлении ARIN о работах 28 июля 2026 года сказано, что Whois, Whois-RWS, RDAP, IRR и репозиторий RPKI останутся работоспособными, но обновления в это время публиковаться не будут.
  • ARIN Online, RESTful Provisioning, RPKI Up/Down и RPKI Repository Publication должны были стать недоступными; REST-вызовы могли попасть в очередь и потребовать повторной отправки.
  • В приложении C к годовому отчёту за 2025 год приведены шесть значений доступности: 99,9, 99,9, 99,9, 100, 100 и 99,9 процента, но нет поля для актуальности, возраста данных, последней публикации или авторитетного обновления.
  • Карточка сервиса с двумя часами позволила бы отдельно показывать чтение, приём записи, авторитетную публикацию и сверку очереди, не называя плановые работы инцидентом.

В реестре цепочка изменения редко сводится к одному действию. Запрос можно принять; объект можно подготовить; состояние можно опубликовать; после окна обслуживания очередь можно сверить. Наличие ответа в начале этой цепочки не является квитанцией о её конце.

Именно такую границу задаёт сообщение ARIN, опубликованное 14 июля 2026 года. На время работ 28 июля недоступными должны были быть ARIN Online, RESTful Provisioning, RPKI Up/Down и RPKI Repository Publication. Одновременно Whois, Whois-RWS, RDAP, IRR и репозиторий RPKI должны были продолжать работу. Отдельно указано, что обновления не будут публиковаться. Вызовы RESTful Provisioning могли оказаться в очереди и впоследствии потребовать повторной отправки.

Из этого нельзя сделать вывод, что чей-то вызов был потерян, что пользователю выдали устаревшие данные, что восстановление не состоялось или что был нанесён ущерб. Источник этого не говорит. Он документирует более узкую и полезную вещь: чтение, приём изменения, публикация авторитетного состояния и послеремонтная сверка — разные состояния, которые могут не совпасть во времени.

Сохранившийся доступ к чтению — не фикция

У ARIN есть сильный практический довод в пользу такого режима. Выключение всех читателей на время остановки записи лишило бы операторов уже опубликованной информации. Whois или RDAP остаются полезными для просмотра существующей записи. IRR продолжает выдавать опубликованное состояние. В RPKI проверяющее программное обеспечение опирается на опубликованные подписанные объекты и локальный кэш; пауза новой публикации не делает уже проверяемый материал бессмысленным.

Страницы ARIN о hosted RPKI, Repository Publication Service, Trust Anchor Locator и терминах RPKI описывают связанные, но различные роли центра сертификации, публикации, репозитория и полагающейся стороны. Этого достаточно, чтобы объяснить, почему подписанный кэш может оставаться проверяемым при паузе новой публикации. Этого недостаточно, чтобы назначить единый допустимый возраст данных или утверждать что-либо о конкретной задержке.

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

Страница статуса ARIN уже группирует публичные компоненты. Это не свидетельство о внутренних панелях, поставщиках, топологии или целях восстановления. Но это подтверждает, что публичный сервис допускает различение нескольких состояний, а не только общий световой сигнал.

Что именно сообщает годовая таблица

Приложение C к годовому отчёту ARIN за 2025 год перечисляет ARIN Online, Whois/RDAP, Resource Public Key Infrastructure, RDAP Bootstrap, Internet Routing Registry и Registration Transaction Service. Результаты за 2025 год идут в последовательности 99,9, 99,9, 99,9, 100, 100 и 99,9 процента; ниже приведены показатели компонентов.

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

Однако в зафиксированной таблице на странице 24 нет колонки или метки freshness, data age, last published либо authoritative update. Вывод ограничен этой таблицей. Он не доказывает отсутствие внутренних метрик, не описывает все публичные экраны и не говорит, что у ARIN нет механизмов восстановления. Он говорит, что читатель данного отчёта не получает из него времени последнего продвижения авторитетного состояния.

В режиме плановой паузы высокая доступность и остановленная публикация поэтому не противоречат друг другу. Первое отвечает на вопрос «могу ли я получить ответ?». Второе — на вопрос «насколько свежим может быть авторитетное состояние за этим ответом?». Для обеих сторон реестра нужны разные часы.

Публичная карточка двух времён

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

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

Это не единый норматив для RPKI, RDAP, IRR и регистрационной транзакции. У них разные функции и разные допустимые задержки. Это также не запрос на раскрытие устройства системы. Это точное описание того, что публичная граница может обещать. Снимок статуса вправе сообщать «All Systems Operational» в момент получения; время последней авторитетной публикации и статус сверки очереди — другие факты, а не опровержение первого.

Источники

  1. Уведомление ARIN о технических работах
  2. Годовой отчёт ARIN за 2025 год, приложение C
  3. Отчёты ARIN об уровне сервиса
  4. Страница статуса ARIN и сводка API
  5. Hosted RPKI, RPS, TAL и термины RPKI