Кратко

  • Официальная документация API прямо признаёт, что возвращаемые контактные данные «во многих случаях неверны или недоступны».
  • Поиск работает снизу вверх и возвращает первый найденный abuse-c, не оценивая, способен ли этот оператор действовать.

Детальный разбор

Механика поиска задокументирована: RIPEstat работает снизу вверх — он ищет ссылки abuse-c: в объектах ORGANISATION, связанных с объектами INET(6)NUM для запрошенного префикса, IP или ASN, и возвращает первый найденный (документация API; описание реализации ripe-563). Это значит, что возвращается «самый специфичный» abuse-c из базы, а не обязательно оператор, способный действовать. Если какая-либо ссылка abuse-c: найдена, устаревшие атрибуты abuse-mailbox: вообще не рассматриваются.

Исторически сервис давал больше информации о собственной неопределённости: пятизвёздочная шкала надёжности означала, что пять звёзд — это abuse-c, соответствующий ripe-563 на запрошенном IP, четыре — abuse-mailbox в связанном объекте, три — контакт, найденный только в remarks, две — abuse-mailbox из более специфичного или вышестоящего объекта, который «может не быть правильным контактом», одна — контакт, который «весьма вряд ли» верен (RIPE Labs). В 2015 году эти эвристики убрали: теперь сервис показывает только адрес abuse-c «как указано в RIPE Document 563» — единственный неквалифицированный адрес с дисклеймером уровня API.

В эпоху эвристик ошибку было легко себе представить: старый Abuse Finder выполнял примерно 30–150 отдельных запросов к базе RIPE за один поиск, и задокументированный баг из-за плейсхолдерных данных часто и неверно возвращал собственный плейсхолдерный адрес реестра; другой баг возвращал результаты, не связанные с вводом, потому что первичные и индексированные ключи не уникальны между типами объектов (обновление эвристик). Сотрудник RIPE NCC на странице Labs признал, что «не было процедуры для исправления или валидации контактов для злоупотреблений», заданных держателями ресурсов.