Кратко

  • AS210860 не анонсировала ни одного префикса с 26 марта 2026 года, что подтверждается независимыми источниками данных о маршрутизации.
  • Объект роли DFINFRA (nic-hdl DA9499-RIPE) остаётся зарегистрированным административным и техническим контактом автономной системы в базе RIPE NCC.
  • Производная запись PeeringDB продолжает самодекларировать десять префиксов IPv4 и открытую политику пиринга, противореча наблюдаемой маршрутизации.
  • Реестровая поверхность и рыночная поверхность записи разошлись, и ни одна сторона в доступных материалах публично не провела сверку.
  • Вопрос статьи — распределение издержек проверки: каждый потребитель реестра и каждый потенциальный контрагент должен повторять одну и ту же работу независимо.

Состояние сети: нулевой объём анонсированных префиксов

Исходный факт этой истории прост и проверяем. Автономная система AS210860 не объявляет в глобальной таблице маршрутизации ни одного префикса с 26 марта 2026 года. Это состояние фиксируется несколькими независимыми источниками данных: статистикой по конкретному номеру AS https://bgp.he.net/AS210860, списком объявляемых префиксов IPv4 https://ipv4.bgp.he.net/AS210860, агрегированным отчётом о видимости префиксов https://www.cidr-report.org/cgi-bin/as-report?as=AS210860&view=2.0, а также мониторингом отключений и видимости https://ioda.inetintel.cc.gatech.edu/asn/210860 и https://checkip.com/asn/AS210860/.

Предыдущее освещение BTW зафиксировало это состояние как отправную точку анализа: сеть, которая существует на бумаге реестра, но не существует в таблице маршрутизации https://btw.media/en/governance/rir-watchdog/ripe-ncc/story/dfinfra-as210860-zero-announced-prefixes. Отдельный материал собрал доказательственную базу по маршрутизации за сентябрь 2026 года https://btw.media/en/governance/rir-watchdog/ripe-ncc/story/dfinfra-as210860-routing-evidence-september-2026, и третий — проследил жизненный цикл записи https://btw.media/en/governance/rir-watchdog/ripe-ncc/story/dfinfra-as210860-lifecycle-ledger. Новизна настоящей статьи лежит дальше: не в констатации расхождения, а в том, кому оно стоит денег.

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

Реестровый сигнал: роль DFINFRA и связка записей

В базе данных RIPE запись автономной системы доступна через публичный интерфейс поиска https://apps.db.ripe.net/db-web-ui/lookup?key=AS210860&type=aut-num. Она указывает объект роли DFINFRA с идентификатором nic-hdl DA9499-RIPE в качестве административного и технического контакта. Прежние материалы BTW описали этот сигнал и его границу верификации https://btw.media/en/dfinfra-as210860-registry-signal-and-verification-boundary, а также вопрос оперативного контроля, который реестровая запись сама по себе не разрешает https://btw.media/en/dfinfra-as210860-registry-signal-operational-control и https://btw.media/en/dfinfra-as210860-missing-link-registration-operational-control.

Здесь необходимо точное разграничение. Реестровая запись доказывает существование регистрационного объекта и связь контактов с ним. Она не доказывает, кто фактически управляет сетью, кто оплачивает её членство или транзит, и кто вправе изменить или удалить запись. Это стандартная граница верификации реестра WHOIS: реестр фиксирует заявление на момент регистрации, а не текущее операционное состояние. Проблема, которую исследует эта статья, возникает именно потому, что третий слой — самодекларируемая рыночная поверхность — заявляет больше, чем позволяет наблюдаемая маршрутизация.

Самодекларируемая рыночная поверхность

Производная запись PeeringDB, отражённая в сторонних каталогах, продолжает описывать AS210860 как сеть с десятью префиксами IPv4 и открытой политикой пиринга https://ipinfo.io/AS210860. Отраслевой форум по конкретному номеру AS собирает пользовательские наблюдения и вопросы по этой записи https://ip.cc/topic/asn/AS210860/, а каталоги хостинга связывают её с именем EDEKA Digital https://hostdir.net/networks/as210860-edeka-digital. Справочные страницы по AS на региональных сервисах повторяют те же декларации https://whois.ipip.net/AS210860.

Разрыв между слоями формулируется так: заявленный набор из десяти префиксов IPv4 против нуля анонсов в глобальной таблице; заявленная открытая политика пиринга против сети, с которой не с кем устанавливать сессии, потому что нет ни одного объявляемого префикса. Заявление — это не факт; факт — это таблица маршрутизации. Но заявление продолжает транслироваться как рыночная поверхность, потому что ничто в доступных материалах не помечено как устаревшее или отозванное.

Кто несёт издержки проверки: механизм

Экономическая суть проблемы — распределение издержек верификации. Когда реестровая запись, производная запись PeeringDB и наблюдаемая маршрутизация совпадают, проверка стоит почти ноль: контрагент читает декларацию и подтверждает её одним запросом к таблице маршрутизации. Когда они расходятся, каждый участник должен выполнять полную сверку самостоятельно, и результат этой работы не сохраняется нигде, где его увидят следующие участники.

Рассмотрим цепочку сторон, каждая из которых сталкивается с той же задачей:

  1. Потенциальный пиринговый партнёр читает запись с десятью префиксами и открытой политикой и должен проверить, существует ли сеть вообще в таблице маршрутизации.
  2. Поставщик транзита, оценивающий кредитный и операционный риск, должен сверить декларации с фактическим трафиком.
  3. Аналитик безопасности, классифицирующий автономную систему, должен решить, считать ли её активной, спящей или выведенной из эксплуатации — и задокументировать основание.
  4. Потребитель данных о рынке, использующий агрегаторы по AS https://bgp.he.net/AS210860, получает смесь заявлений и наблюдений без указания, какая категория к чему относится.
  5. Сам реестр RIPE NCC, который поддерживает запись и объект роли, не несёт обязательства публично сверять декларации производных сервисов с состоянием маршрутизации.

Механизм, который воспроизводит разрыв, — отсутствие обязательства обновления и отсутствие места, где сверка была бы опубликована один раз для всех. Каждый из перечисленных участников платит издержки повторно. Никто не может амортизировать свою работу, передав результат следующему. Это классическая проблема общественного блага в данных: сверка полезна для всех, но её стоимость падает на того, кто первым в ней нуждается.

Корпоративный контур и границы доказательств

Каталоги связывают AS210860 с именем EDEKA Digital, а немецкий реестр компаний фиксирует EDEKA Verwaltungs- und Beteiligungs GmbH, Гамбург, под номером HRB 90516 https://www.northdata.de/EDEKA%20Verwaltungs-%20und%20Beteiligungs%20GmbH,%20Hamburg/HRB%2090516. Эти связи описывают регистрационный контур, но не отвечают на операционные вопросы: кто владеет записью AS сегодня, кто оплачивает её поддержание и намерена ли какая-либо из сторон её закрыть. Предыдущее освещение BTW уже уточнило вопрос идентичности; настоящая статья намеренно не выходит за пределы этого уточнения и не присваивает сети корпоративное намерение, которого доказательства не содержат.

Границы доказательств важны. Все даты, цифры и статусы в этой статье происходят из перечисленных публичных источников: состояние маршрутизации из агрегаторов и мониторингов, реестровый сигнал из базы RIPE, декларации из производных каталогов, корпоративные записи из публичного реестра компаний. Ни один вывод о будущем не основан на источнике, который не зафиксировал его сам. В частности, статья не утверждает, что запись будет удалена, что ресурсы будут возвращены или что какая-либо сторона признала несоответствие — таких заявлений в доступных материалах нет.

Неопределённости и следующий наблюдаемый признак

Три неопределённости ограничивают выводы. Во-первых, неизвестно, существует ли внутренняя — не публичная — свёртка статуса сети внутри корпоративного контура; её отсутствие в открытых источниках не доказывает её отсутствия вообще. Во-вторых, производные каталоги обновляются с переменной задержкой, поэтому часть расхождения может объясняться задержкой синхронизации, а не принципиальным отказом от обновления. В-третьих, невозможно из публичных данных отличить намеренную приостановку эксплуатации от технической инерции.

Следующий наблюдаемый признак определён: если запись AS210860 будет удалена или контакты будут изменены в базе RIPE https://apps.db.ripe.net/db-web-ui/lookup?key=AS210860&type=aut-num, или если производные каталоги синхронизируют нулевое состояние маршрутизации, или если вновь появятся ненулевые анонсы — любой из этих трёх исходов изменит распределение издержек проверки, описанное в этой статье. Профиль объекта в каталоге BTW: https://btw.media/ru/directory/dfinfra. До этого момента каждый новый контрагент будет повторять одну и ту же сверку с нуля.