Кратко

  • RFC 9877 определяет geofeed1, отношение ссылки geofeed и тип application/geofeed+csv, позволяя сетевому объекту RDAP указывать на geofeed по HTTPS.
  • Ссылка доказывает наличие пути обнаружения в конкретном ответе. Она сама по себе не доказывает свежесть строк, физическое присутствие сети или местонахождение человека.
  • Надёжное применение сохраняет диапазон исходного объекта, отбрасывает чужие строки, проверяет полномочия издателя и возраст данных, а затем отдельно разрешает использование результата.

Запрос по IP-адресу возвращает самый специфичный сетевой объект. Ссылки на geofeed в нём нет. Клиент поднимается к родительскому объекту — и ссылка появляется. Соблазнительно назвать найденную строку местоположением адреса. Но на каждом шаге изменялась область, в которой источник мог быть релевантен.

RFC 9877, опубликованный IETF как Standards Track в октябре 2025 года, стандартизирует именно обнаружение. В обычном массиве links IP-объекта можно передать отношение geofeed, HTTPS-адрес и рекомендуемый тип application/geofeed+csv. Идентификатор geofeed1 сообщает клиенту о поведении расширения.

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

Условное обязательство geofeed1

Сервер, заявляющий geofeed1 в rdapConformance, обязан включать его в ответы поиска и запросов с IP-сетевыми объектами, а также в справочный ответ. Если у него есть URL geofeed для конкретного объекта и он может его вернуть, ссылка должна присутствовать. Регуляторные или сходные ограничения могут помешать раскрытию.

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

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

HTTPS защищает канал и аутентифицирует веб-узел средствами WebPKI. Но он не доказывает, что оператор узла полномочен говорить о каждом префиксе в CSV. Подлинность транспортной точки и полномочия в отношении адресного пространства — разные доказательства.

Родительский объект расширяет контекст, а не истину

По RFC 9082 IP-запрос возвращает наиболее специфичный объект, покрывающий адрес или диапазон. RFC 9877 учитывает ситуацию, когда geofeed есть только у менее специфичного родителя, и предлагает клиенту рассмотреть рекурсивный подъём.

Вместе со ссылкой необходимо сохранять границу. Если общий файл содержит ресурсы за пределами объекта, который дал ссылку, все такие строки следует игнорировать. Корректно загруженный CSV не получает право описывать весь свой состав в контексте запроса.

RFC 8805 рекомендует проверять, что издатель полномочен говорить о соответствующих ресурсах. Начальная загрузка из RFC 9224 помогает найти RDAP-службу, способную авторитетно описать распоряжение ресурсом. Она усиливает происхождение указателя, но не подтверждает физическую точность каждой географической строки.

Geofeed — это опубликованное держателем заявление об операционной географии префикса. Оно может быть намеренно грубым, отставать от перемещения инфраструктуры или описывать точку обслуживания, не совпадающую с путём каждого клиента. Anycast, мобильные сети и многострановые корпоративные сети особенно плохо укладываются в одну координату. Честная запись звучит как «заявленная география этого диапазона на такую-то дату», а не «человек найден».

Аутентификация не утверждает смысл

RFC 9632, заменивший RFC 9092, описывает необязательную аутентификацию RPKI. Действительная подпись может лучше связать файл с сертификатом, покрывающим адресное пространство. Она не делает географическое содержание безошибочным, не обновляет устаревшие данные и не разрешает блокировку или иное значимое действие.

Системе нужны отдельные состояния: ссылка обнаружена, файл получен, транспорт проверен, исходный диапазон сохранён, строки отфильтрованы, издатель проверен, подпись оценена, возраст рассчитан, основание обработки подтверждено, применение разрешено, результат наблюдался. Единственное поле «место определено» лишает организацию возможности найти источник ошибки.

Частота запросов также задаёт предел. RFC 9877 запрещает частые обращения в реальном времени, создающие чрезмерную нагрузку. RFC 9632 советует следовать HTTP-сигналам свежести, а без них загружать не чаще раза в неделю. Текущий вызов API не превращает недельный источник в данные реального времени.

Приватность — самостоятельное ограничение. Издатель обязан избегать раскрытия места нахождения любого человека, а оператор реестра должен оценить, допускает ли функция его регуляторная среда. Удобное обнаружение не отменяет ограничения цели и соразмерности.