Кратко

  • 0,006% — это доля случаев Whois-запроса, в которых вернулся объект NONAUTH; около 20% — доля запросов NRTM, искавших обновления этого источника. Это не сопоставимые доли пользователей или трафика.
  • Дальнейшая очистка пока имеет статус «Starting». До удаления нужно определить набор объектов, правило, уведомление, перенос и проверку после изменения.

Поиск и зеркалирование измеряют разное

Whois отвечает на отдельный запрос. NRTM передаёт изменения базы, чтобы поддерживать локальную копию. Запись может редко появляться в ответе на конкретный поиск и при этом регулярно запрашиваться по отдельному каналу обновлений. Здесь нет противоречия: наблюдаются разные пути данных.

17 июля 2025 года RIPE NCC сообщила в рассылке Database WG, что объекты RIPE-NONAUTH возвращались примерно в 0,006% случаев Whois-запросов. В том же сообщении говорилось, что около 20% запросов NRTM спрашивали об обновлениях NONAUTH. Период наблюдения, абсолютные знаменатели и число уникальных клиентов зеркал в сообщении не указаны. Поэтому эти проценты нельзя делить, вычитать или сводить к одной доле использования.

Показатель 0,006% отвечает на ограниченный вопрос: как часто объект NONAUTH попадал в измеренные ответы Whois. Он не показывает, сколько отдельных сетей зависело от таких ответов, насколько они были важны для работы и что эти сети получали из локального зеркала. Он также не охватывает пользователей, которые ограничивают запрос авторитетными источниками. RIPE NCC отмечает, что Whois по умолчанию включает NONAUTH, а игнорирование атрибута source может привести к доверию неавторитетной записи. Параметр «-s RIPE» ограничивает поиск источником RIPE.

Доля 20% отвечает на другой вопрос: какая часть запросов NRTM просила обновления NONAUTH. Из неё не следует, поступали ли запросы от многих клиентов или от нескольких автоматизированных систем, повторявших обращения; были ли все передачи успешными; использовались ли полученные данные в действующей сети. Одна задача может создавать много запросов, а другой потребитель может загружать ежедневный файл вместо потока обновлений. Этот процент не подсчитывает операторов, клиентов, трафик, зеркала или зависимости.

Основание для очистки есть, но есть и пробел в доказательствах

RIPE-NONAUTH выделили в 2018 году для определённых неавторитетных объектов ресурсов вне региона. У RIPE NCC есть обоснованная причина проверять данные, чьё происхождение или актуальность могут быть неизвестны. В оперативном отчёте RIPE 90 за май 2025 года также говорилось менее чем о ста изменениях в год и постепенном сокращении набора данных. Это повод проверить назначение каждой записи, но не доказательство того, что все оставшиеся объекты избыточны.

Обсуждались конкретные правила: например, совпадение с действительным ROA или с маршрутным объектом в другой базе RIR. Согласно проекту протокола RIPE 91, RIPE NCC отправила чуть более 2 000 уведомлений хранителям потенциально затронутых объектов. Было получено 33 ответа: 23 просили не удалять объекты; с десятью владельцами обсудили использование и помогли создать альтернативы в авторитетных базах. Эти ответы показывают, что перенос требует работы, но не являются репрезентативным опросом всех потребителей. Ответившие могут отличаться от тех, кто промолчал; количество писем не равно числу зеркал.

На RIPE 92 Job Snijders поддержал удаление маршрутов с соответствующими действительными ROA или объектами маршрутов в других базах RIR. AMS-IX сообщила, что её route-серверы перестали использовать NONAUTH несколько лет назад, без жалоб и операционных последствий. Это полезное свидетельство, ограниченное одним оператором и его способом перехода. RIPE NCC попросила других операторов, всё ещё зависящих от NONAUTH, сообщить об этом. Протокол фиксирует обсуждение, а не решение о закрытии базы.

«Starting» — не график удаления

План RIPE Database на четвёртый квартал 2026 года, обновлённый 17 сентября, сообщает о намерении предложить дальнейшую очистку после обсуждения в рассылке и на RIPE 92. Статус пункта — «Starting». План не называет окончательный список объектов, правила сопоставления, дату, срок уведомления, исключения или изменение сервиса NRTM. Сокращение числа записей не означает закрытие базы; ни один из этих шагов не описан как уже выполненный.

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

Для этого не нужна вечная программа телеметрии. Нужна версия доказательств для каждого значимого изменения пути данных: правило, уведомление, альтернатива, срок перехода, ограниченный тест и условие остановки, если поведение отличается от ожидаемого. Удаление точных дублей — одно решение; удаление всех объектов, покрытых действительным ROA, — другое. Прекращение NRTM было бы третьим. Если назвать всё это «использованием», исчезнут различия, на которых должно основываться решение.

Источники