Кратко

  • В записи RIPE NCC от 30 октября указано, что обновления базы данных периодически не проходили 28 октября с 11:42 до 19:40 UTC. Первоначальная карточка закрыла инцидент в 19:32 UTC.
  • По итогам проверки ни один неудачный запрос не изменил бы обратную делегацию: запрос не содержал изменений либо не прошёл предварительную проверку Zonemaster. В двух карточках указаны уровни воздействия «major» и «none».

Поздняя запись RIPE NCC продлевает окно сбоев на восемь минут после первоначального закрытия инцидента. 28 октября первая карточка перевела RIPE Database в мониторинг после исправления в 20:23 CET и отметила инцидент решённым в 20:32 CET — это 19:32 UTC. Дополнение, опубликованное 30 октября, указывает, что обновления периодически не проходили до 19:40 UTC.

Уточнённое начало тоже меняет картину. Сбои начались в 11:42 UTC, а первое публичное сообщение о расследовании появилось в 20:04 CET, то есть в 19:04 UTC. Между ними семь часов и 22 минуты. Первоначальная карточка говорила о необработанных обновлениях и затронутых объектах domain, влияющих на обратный DNS; уровень воздействия был «major».

Поздний разбор сужает последствия неудачных запросов. Ни один из них не изменил бы обратную делегацию: одни запросы не содержали изменений, другие не прошли предварительные проверки Zonemaster. В документации RIPE Database по обратному DNS объясняется, что объект domain запрашивает делегацию, а проверка серверов имён предшествует её распространению RIPE NCC.

Речь идёт о неудачных попытках записи, а не об изменённых этими запросами делегациях. При этом API показывает для первого инцидента «major», а для связанного дополнения — «none» и не объясняет разницу. Число неудачных запросов и их объекты также не опубликованы. Эти данные позволили бы операторам понять, какие отправки можно закрыть без проверки каждого объекта.

Источники