Кратко

  • По сообщению APNIC, 28 августа 2026 года с 19:10 до 19:18 по UTC+10 сетевой межсетевой экран обнаружил аппаратную неисправность и перезапустился.
  • В список попали MyAPNIC, API реестра, Orbit, FTP, протоколы RPKI для выдачи сертификатов и публикации, а также RPKI rsync.
  • Публичные данные не подтверждают потерю или порчу данных, повторное обновление либо инцидент безопасности. Они также не показывают отдельно приём задач, фиксацию результата, опустошение очередей и согласованность представлений.
  • Минимальная квитанция по типу операции могла бы различать «не получено», «принято», «зафиксировано», «видимо», «можно повторить», «следует опрашивать» и «неизвестно» под одним идентификатором инцидента.

Восемь минут — граница устройства, а не любого действия

В объявлении APNIC от 28 августа начало указано в 19:10, окончание — в 19:18 по UTC+10. Один сетевой межсетевой экран обнаружил аппаратный сбой и перезапустился. Это вызвало перебои в перечисленных сервисах. APNIC расследует причину вместе с поставщиком оборудования и улучшает переключение трафика между межсетевыми экранами. RSS-лента фиксирует те же время и формулировку.

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

APNIC не распределяет эти состояния по сервисам. Поэтому нельзя ни приписывать ущерб, ни считать все операции автоматически завершёнными в 19:18. В это время закончился инфраструктурный инцидент в принятом APNIC смысле. Работа, пересекавшая его, могла иметь другую точку конца.

У API есть очередь задач за пределами соединения

В описании запуска API реестра APNIC указывает, что интерфейс получает сведения о делегировании и управляет записями Whois, обратным DNS, ROA и объектами маршрутов. Он не только читает, но и меняет состояние.

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

Это разделяет отправку HTTP-запроса и завершение его работы. Соединение может оборваться до получения запроса сервером, после получения, но до приёма, после создания задачи или после фиксации изменения, когда финальный ответ уже не дошёл до клиента.

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

MyAPNIC представляет те же функции с другой стороны. APNIC пишет, что изменения маршрутов через API появляются в MyAPNIC, а обновления портала видны через API. Открывшийся после сбоя портал доказывает новый успешный запрос чтения. Он сам по себе не доказывает завершение прежней задачи или одновременную согласованность обоих представлений.

Для участника полезны иные формулировки: записи в окне не принимались; принятые задачи сверены; часть задач ещё выполняется; состояние не наблюдаемо. Возврат трафика — условие для такой сверки, но не её результат.

Повтор чтения Orbit и повтор публикации — разные решения

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

В уведомлении назван Orbit целиком. Это не подтверждает потерю публикации и не исключает очередь; просто конкретный путь не обозначен.

FTP относится к публичной раздаче данных. Формат обмена статистикой RIR предусматривает общедоступные файлы без контроля доступа, постоянное имя для последней версии и материалы проверки.

Ошибка скачивания не означает порчу файла. Датированный выпуск может быть создан, но ещё не доступен через отдельный путь. Ссылку latest и её датированную цель можно проверять раздельно. Ни один сценарий не доказан. Именно поэтому статус должен быть узким: нарушалось только чтение, публикация задержалась, объект не менялся, указатель проверен либо состояние неизвестно.

RPKI — это несколько направлений обмена

Certification Practice Statement APNIC разделяет протокол выдачи ресурсных сертификатов, протокол публикации, доступ к репозиторию по rsync и доступ по RRDP. Издатель сертификата и субъект, публикатор и репозиторий, репозиторий и полагающаяся сторона выполняют разные действия.

RFC 6492 задаёт запросы и ответы для выдачи ресурсных сертификатов. RFC 8181 определяет операции публикации. RFC 8182 описывает RRDP поверх HTTPS.

APNIC назвала «RPKI Provisioning and Publication protocol», затем отдельно RPKI rsync. RRDP не упомянут. Молчание не означает ни его работоспособность, ни отказ, ни нахождение за иной границей сбоя. Уведомление просто не присваивает ему состояние.

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

Закрывающие вопросы должны следовать направлению протокола. Получил ли запрос выдачи соответствующий ответ? Принял ли репозиторий публикацию или её следует повторить? Вернулся ли rsync-набор в согласованном виде? Наблюдался ли RRDP? Такое разделение не предполагает плохой исход; оно не даёт одному сокращению скрыть несколько состояний.

Быстрое уведомление не обязано быть полным отчётом

Требовать от APNIC сверить все задачи и очереди до первого сообщения было бы неразумно. Раннее уведомление помогает сопоставить пользовательские ошибки с известным событием. В нём уже названы причина, поверхности и направление исправления.

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

Поэтому первое сообщение может остаться коротким. После внутренней сверки к нему можно добавить компактную матрицу состояния операций.

Минимальная квитанция без раскрытия секретов

Строка квитанции указывает интерфейс, направление и класс: обновление участника, опрос задачи, чтение или публикация сообщества, создание или получение файла, выдача RPKI, публикация RPKI, чтение rsync и, при включении, наблюдение RRDP.

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

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

В 19:18 APNIC завершила инцидент межсетевого экрана. Запись реестра заканчивается, когда известны её приём и эффект. Публикация — когда известен результат репозитория. Чтение — когда потребитель получил проверяемое представление. Один инцидент способен связать эти часы. Он не должен выдавать их за одни и те же.

Источники