Кратко

  • RIPE NCC опубликовала разбор инцидента с NRTM и раздельными файлами в 15:03 CEST 13 августа 2026 года.
  • В отчёте говорится, что невалидный объект RPSL остановил поток зеркалирования, и с этого момента клиенты рассинхронизировались.
  • RIPE NCC сообщает, что изменила обработку символов новой строки и поведение NRTM; оба исправления ожидаются в Whois 1.124 27 августа.

Некорректный объект столкнулся с правилом остановки потока

RIPE NCC сообщает, что сервис зеркалирования NRTM был затронут примерно с 00:06 UTC 2 августа до 12:30 UTC 4 августа. В разборе от 13 августа указан непосредственный механизм сбоя: в RIPE Database был записан невалидный объект RPSL, сервис NRTM дошёл до этого объекта и остановился, и с этого момента клиенты рассинхронизировались с базой данных.

На странице инцидента уже было зафиксировано зависимое последствие. Предоставление обратного DNS опирается на NRTM, и пока шло расследование, обновления доменных объектов не появлялись в глобальной DNS. Позднее RIPE NCC сообщила, что ожидавшие обработки обновления доменных объектов были обработаны и опубликованы, а 4 августа отметила инцидент как устранённый. Разбор не является утверждением о каждом зеркале или каждом подчинённом резолвере; он объясняет задокументированный путь сервиса, который дал сбой.

Два защитных изменения с датой будущего релиза

В отчёте невалидный объект связывается с изменением кода в релизе Whois 1.122, внедрённым в апреле. В атрибутах descr: и remarks: были случайно разрешены дополнительные символы новой строки, из-за чего в базу можно было записать невалидный RPSL. RIPE NCC сообщает, что изменила замену кодовых точек UTF-8 таким образом, что лишние переводы строк больше не записываются.

Также сообщается, что ранее сервер NRTM завершался с внутренней ошибкой вместо того, чтобы пропустить невалидный объект RPSL. Заявленное новое поведение — пропускать невалидный объект и записывать ошибку в журнал; команда базы данных сможет затем исправить его, чтобы обновление позже появилось в потоке. Оба изменения запланированы в предстоящем релизе Whois 1.124, который ожидается в четверг 27 августа. Это опубликованный план, а не свидетельство того, что релиз уже состоялся.

Урок для контроля — непрерывность, а не невидимость

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

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

Источники