Кратко

  • RIPE NCC связывает сбой 28 октября с кратким обрывом сетевой линии основного балансировщика. После перехода на резервный ошибочная настройка направляла новые соединения для обновления Whois в базу только для чтения; существующие соединения оставались на основной базе.
  • Период прерывистых неудач указан как 11:42–19:40 UTC. Позднее RIPE NCC установила, что неудачные запросы на обратное делегирование не изменили бы делегирование: часть не содержала изменений, остальные не прошли предварительную проверку zonemaster.

Соединение определяло судьбу записи

В разборе, опубликованном 3 ноября, RIPE NCC описывает последовательность без загадочной «нестабильности». На основном балансировщике на короткое время прервалась сетевая линия. Трафик переключился на резервный. Оттуда новые соединения приложения для обновлений Whois шли к базе только для чтения вместо основной базы. Уже открытые соединения сохранили путь к основной и не пострадали.

Поэтому отказ был неравномерным. Клиент с прежним соединением мог получить нормальный путь записи; клиент с новой сессией упирался в копию, которая предназначена для чтения. Сетевая доступность резервного балансировщика скрывала провал операции более высокого уровня. Регистру нужна не красивая диаграмма резервирования, а принятая правка конкретного объекта.

RIPE NCC относит неудачные обновления 28 октября к интервалу от 11:42 до 19:40 UTC. Первое сообщение о происшествии говорило о непрошедших обновлениях и объектах, связанных с обратным DNS. В ноябрьском разборе появился технический маршрут ошибки. Публично не названы неправильный параметр, число неудачных новых соединений и разбивка по способам подачи обновлений. Датированный снимок настройки и журнал результатов показали бы масштаб.

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

Квитанция важнее доступности узла

Описание обработки объектов RIPE говорит, что объекты из сообщения обрабатываются по отдельности, после чего отправитель получает подтверждение. Руководство по подтверждениям предупреждает: ответ HTTP 200 у Syncupdates может сопровождаться отказами отдельных операций. Оператору нужен итог нужной правки и проверка объекта в реестре. Индикатор исправного балансировщика сообщает лишь о работе маршрута до некоторой точки.