Кратко

  • Уведомление APNIC назначает работы в сетевой среде GCP на 29 сентября 2026 года, с 10:00 до 12:00 по UTC+10. В перечне находятся DASH, notification.apnic.net, REx и AS0 ROA Service. APNIC пишет, что простоя не ожидается. Это прогноз о будущих работах, а не сообщение об аварии или доказательство свежести опубликованного состояния.
  • Действующая политика APNIC, пункт 5.1.4, предписывает включать в AS0 пространство под управлением APNIC, имеющее статус Available или Reserved, и исключать префикс при его делегировании. Численного срока для этого действия в пункте нет.
  • Материалы запуска 2020 года описывали удаление и повторную публикацию менее чем за пять минут при обычных условиях. Историческая цель помогает поставить проверяемый вопрос, но не устанавливает подтверждённый SLA на 2026 год и не свидетельствует о задержке во время ещё не состоявшейся смены сети.
  • Для AS0 используется отдельный TAL, который оператор добавляет по собственному решению. APNIC настоятельно рекомендует предупреждения и наблюдение вместо автоматического отбрасывания BGP-маршрутов. Результат для конкретной сети зависит от её проверки и политики маршрутизации.

Что скрывается за одинаковым статусом «работает»

В списке сервисных обновлений объявление датировано 24 сентября. Окно обслуживания откроется только через пять дней. Документ даёт время, перечисляет четыре затронутые службы и прогнозирует отсутствие простоя. Он не утверждает, что у всех четырёх одна база данных, одна система подписи или один отказоустойчивый контур. Дежурная фраза в конце с извинением за возможные неудобства от «outage» не является отчётом о произошедшем сбое и не отменяет более конкретный прогноз.

Если проверять каждый сервис простым HTTP-запросом, получится ответ на ограниченный вопрос: доступна ли конечная точка в определённый момент из определённого места. Для панели это полезное начало. Для службы уведомлений важна ещё доставка или доступность нужного сообщения. Для REx — состояние выдаваемых данных. У AS0 дополнительный предмет проверки: соответствует ли полученный подписанный объект актуальному состоянию префикса в реестре. Старый объект в принципе может продолжать успешно скачиваться. Здесь нет данных, что APNIC действительно отдаёт старое состояние; это лишь причина не выдавать тест доступности за проверку актуальности.

Есть историческая перекличка: 31 июля 2025 года APNIC перечисляла те же четыре службы при обновлении Kubernetes и тоже не ожидала простоя. Повторяющийся список показывает, что AS0 входит в круг сервисов, о техническом обслуживании которых APNIC публично сообщает. Он не доказывает, что за год не изменилась архитектура, способы публикации или границы возможного отказа. Список продуктов нельзя читать как схему инфраструктуры.

Когда прежнее отрицание должно исчезнуть

RFC 6483, раздел 4, описывает ROA с origin AS 0 как отрицание допустимости происхождения маршрута для указанного префикса и его более специфичных частей. APNIC применяет его к не делегированному IPv4- и IPv6-пространству, которым управляет сама. В текущей политике основанием служат отметки Available и Reserved в расширенном файле делегированной статистики. Когда блок получает держателя, старое утверждение о не делегированном пространстве должно перестать его покрывать. Политика прямо требует исключения такого префикса из AS0.

Важность срока видна из доклада о внедрении на APNIC 50. В 2020 году APNIC сообщала, что текущие изменения делегаций отражались и в основной, и в AS0-ветви RPKI в течение пяти минут. В докладе упоминались внутренний компонент, связанный с событиями реестра, облачный репозиторий публикации и постоянное наблюдение. Тогдашняя публикация в блоге называла менее пяти минут в нормальных условиях целью, которой отвечала развёрнутая система. Шесть лет спустя это не позволяет автоматически утверждать, что цель и устройство системы не изменились. Современный текст политики требует исключать префикс, но просмотренные материалы не дают действующего численного предела для сентябрьского окна.

Возможную задержку нужно раскладывать по событиям. Первое — принятие делегации авторитетным реестром. Второе — вычисление новой области действия AS0. Третье — размещение изменённого подписанного объекта в репозитории. Четвёртое — первое независимое получение этой версии. У сети, установившей отдельный TAL, появится ещё и собственный цикл обновления валидатора. APNIC отвечает за свой реестр и публикацию; она не задаёт расписание всех внешних валидаторов. Если один валидатор обновился поздно, это само по себе не доказывает, что APNIC опубликовала поздно.

И наоборот, внутреннее время публикации ещё не описывает то, что внешняя сторона смогла получить в тот же момент.

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

Раздельный TAL оставляет выбор оператору

APNIC публикует AS0 под собственным Trust Anchor Locator, чтобы его не использовали случайно вместе с обычной опорой доверия RPKI. Это граница принятия информации внешним участником. Она не служит доказательством физически самостоятельного хостинга и не устраняет автоматически возможное влияние работ в сетевом окружении GCP. Документ 2020 года говорит об облачной публикации, объявление 2026 года — о GCP; из этих двух фактов нельзя восстановить нынешнюю топологию.

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

Сентябрьское уведомление не показывает ни устаревший объект, ни статус Invalid для реального маршрута, ни потерю связности.

После обслуживания полезно было бы развести два результата. Сохранилась ли доступность перечисленных служб? Если в окно произошла делегация, требующая обновления AS0, когда изменились версия реестра, подписанный объект и его внешняя доступность? Какой текущий временной ориентир использует APNIC, если он существует? При отсутствии соответствующей делегации честным результатом будет «путь обновления не испытывался таким событием». Это предложение к публичной отчётности, а не уже взятое APNIC обязательство и не обвинение в отсутствии внутреннего мониторинга.

Работы могут завершиться без какого-либо происшествия. Это не делает проверку бессмысленной: исправное подключение к службе и правильная версия её утверждения о ресурсах — разные свойства. Для AS0 важно сохранить возможность доказать каждое из них отдельно.

Источники