Кратко

  • На RIPE 93 RIPE NCC сообщила примерно о 8 000 недоставляемых адресов электронной почты; с RIPE 92 их число оставалось примерно на том же уровне.
  • По словам команды, они затрагивают около 1% ежедневных уведомлений об обновлениях. Документация RIPE Database предписывает отправлять уведомления по электронной почте.

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

Команда RIPE Database на RIPE 93 назвала масштаб этого разрыва: около 8 000 адресов электронной почты не доставляют сообщения, примерно столько же, сколько после RIPE 92. Команда оценила затронутую долю ежедневных уведомлений об обновлениях примерно в 1%. Адреса периодически перепроверяют и возвращают в статус доставляемых, если письма снова проходят. В презентации уведомления назвали важными: именно они сообщают пользователям об изменении в базе.

У двух цифр разные знаменатели. 8 000 — это количество недоставляемых адресов; 1% — доля затронутых ежедневных уведомлений. Это не означает, что ошибочны 1% объектов базы, что не проходят 1% обновлений или что каждое письмо на эти адреса потеряно. Публичные данные показывают повторяющуюся проблему доставки, а не взлом или порчу записей.

Документация RIPE Database об уведомлениях отделяет подтверждение обновления от сообщений людям, которые следят за операциями над объектами. Подтверждение может прийти по электронной почте или через другое HTTP-соединение. Уведомления же всегда отправляются по электронной почте. Подтверждение отвечает отправителю изменения; уведомление предназначено для обозначенных получателей, которые должны заметить его. Получение одного сообщения не доказывает получение другого.

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

RIPE NCC говорит, что периодически перепроверяет адреса и возвращает в рабочий статус те, которые снова принимают почту. Но в открытом протоколе нет интервала проверок, количества неудачных сообщений, доли восстановления или разбивки по владельцам адресов и объектам. Любой из этих фактов мог бы изменить очерёдность исправлений. Подтверждённая публичная цифра уже ясна: около 8 000 адресов недоставляемы, а примерно 1% ежедневных уведомлений об обновлениях затронут.

Практический вопрос — что происходит между «почтовый сервер отказал» и «кто-то исправил контакт». Отказ доставки полезен, только если попадает в видимую очередь, связан с записями, которые зависят от адреса, и даёт нужному сопровождающему простой способ его обновить. Повторная проверка может обнаружить, что адрес снова заработал; сама по себе она не заменит устаревший адрес актуальным.

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

Проблема не в том, что электронная почта устарела. Она по-прежнему сообщает операторам в разных сетях, что запись изменилась. Риск начинается, когда заполненное поле принимают за доказательство живого пути до читателя. Реестр хранит память системы; доставка позволяет ответственным людям ею воспользоваться.

Источники: протокол Database Working Group RIPE 93 · документация RIPE Database об уведомлениях · протокол Database Working Group RIPE 92