Resumen

  • El objeto de rol DFINFRA (nic-hdl DA9499-RIPE) sigue siendo el contacto administrativo y técnico registrado del AS210860, mientras la red no anuncia prefijos desde el 26 de marzo de 2026 según Hurricane Electric.
  • Un perfil derivado de PeeringDB mantiene una autodeclaración contradictoria: diez prefijos IPv4, un prefijo IPv6 y política de interconexión abierta.
  • Los espejos públicos del mismo registro discrepan entre sí en nombre de la organización, estado del objeto y fechas; cada consumidor debe reconciliar esas diferencias por su cuenta.
  • Ninguna fuente pública conservada contiene catálogo de servicios, cliente, precio, contrato ni cifra de ingresos atribuible a la operación detrás de AS210860.

La pregunta central de este informe no es quién es DFINFRA. Esa pregunta ya se respondió con evidencia de registros: DFINFRA es un objeto de rol en la base de datos RIPE, con identificador nic-hdl DA9499-RIPE, creado el 10 de junio de 2021 y sin modificación desde el 27 de octubre de 2021, que actúa como contacto administrativo y técnico del sistema autónomo AS210860. La organización registrada detrás del aut-num es ORG-EDG14-RIPE, asociada en los espejos conservados a EDEKA Verwaltungs- und Beteiligungs GmbH (HRB 90516, tribunal de Hamburgo), una sociedad de participación del grupo de distribuidores EDEKA [https://www.northdata.de/EDEKA%20Verwaltungs-%20und%20Beteiligungs%20GmbH,%20Hamburg/HRB%2090516].

La pregunta es otra: una vez que el nombre persiste en el registro y la operación desaparece de la observación, ¿quién soporta el coste de averiguarlo? En los mercados de infraestructura, un registro no es solo documentación; es un insumo de decisión. Un operador que evalúa interconexión, un cliente que evalúa dependencia de red y un analista que evalúa un activo todos consumen la misma capa de datos públicos, y todos se enfrentan al mismo problema cuando esa capa se contradice a sí misma.

Lo que dice cada capa del registro

La divergencia entre declaración y observación es medible y está fechada. Hurricane Electric mantiene que AS210860 no es visible en la tabla global de enrutamiento desde el 26 de marzo de 2026, con cero prefijos anunciados en ambos protocolos y un único par observado, AS9211 [https://bgp.he.net/AS210860]. Su vista IPv4 repite las mismas cifras y muestra un objeto aut-num reproducido con los contactos anonimizados, lo que ya es una primera capa de distorsión del registro original [https://ipv4.bgp.he.net/AS210860]. CIDR Report, observador independiente que se alimenta de datos BGP similares, clasifica el sistema autónomo de forma coincidente: no anuncia prefijos ni funciona como tránsito visible [https://www.cidr-report.org/cgi-bin/as-report?as=AS210860&view=2.0]. IPinfo etiqueta el ASN como inactivo, con cero prefijos y atribución a EDEKA Verwaltungs- und Beteiligungs GmbH en el registro RIPE [https://ipinfo.io/AS210860].

Frente a esas observaciones, la superficie autodeclarada dice otra cosa. Un registro derivado de PeeringDB para la red "EDEKA DIGITAL, AS210860" declara diez prefijos IPv4 y un prefijo IPv6, una política de interconexión abierta y tipo de red sin especificar [https://hostdir.net/networks/as210860-edeka-digital]. Es una declaración, no una observación: nadie validó esos diez prefijos contra la tabla global, y la tabla global dice que no existen en tránsito.

El registro como sistema de espejos divergentes

El segundo problema de verificación es que no existe una única reproducción pública del registro RIPE para este objeto; existen al menos cinco, y discrepan. El espejo de IPIP.NET reproduce el aut-num con nombre de organización EDEKA Verwaltungs- und Beteiligungs GmbH y una última modificación del objeto de organización fechada el 13 de mayo de 2026 [https://whois.ipip.net/AS210860]. El espejo de IP.CC reproduce el mismo objeto con el nombre EDEKA DIGITAL GmbH y última modificación del 27 de octubre de 2021, y además lista un upstream de AS32787 (Akamai) que contradice la observación de un único par AS9211 en Hurricane Electric [https://ip.cc/topic/asn/AS210860/]. El punto de consulta autoritativo del RIPE NCC es la fuente primaria correcta, pero su interfaz pública no expone los valores del objeto a los agregadores de búsqueda, de modo que la reproducción capturable de esa fuente en esta investigación quedó vacía [https://apps.db.ripe.net/db-web-ui/lookup?key=AS210860&type=aut-num].

A esta discordancia de nombres se suma una discordancia de estados. CheckIP lista el ASN como "Active", con una fecha de registro de marzo de 2025 que contradice las fechas de creación de 2021 del registro RIPE [https://checkip.com/asn/AS210860/]. IODA, el sistema de detección de apagones de Georgia Tech, monitorea el ASN bajo el nombre edeka_digital y expone series de tiempo de sondas activas y visibilidad BGP, pero la ventana observada en septiembre de 2026 no arroja en la evidencia conservada un valor numérico de visibilidad distinto de cero [https://ioda.inetintel.cc.gatech.edu/asn/210860].

Qué añade la cobertura previa y qué falta

BTW ya ha publicado una secuencia de investigaciones sobre este objeto. Un informe de septiembre de 2026 documentó la divergencia entre el registro y los observadores de enrutamiento, la ausencia de modificación del rol desde octubre de 2021 y los conflictos entre espejos, y definió las condiciones observables que falsificarían la imagen de una red silenciosa: un reanuncio de prefijos, una edición del perfil de PeeringDB, una edición del aut-num o de los objetos de ruta [https://btw.media/en/governance/rir-watchdog/ripe-ncc/story/dfinfra-as210860-routing-evidence-september-2026]. Otra investigación ejecutó la mitad comercial de la prueba: en diecinueve fuentes públicas conservadas, ninguna contiene catálogo de servicios, cliente, precio, contrato, compromiso de capacidad ni cifra de ingresos atribuible a la red detrás de AS210860 [https://btw.media/en/governance/rir-watchdog/ripe-ncc/story/dfinfra-as210860-zero-announced-prefixes]. Un tercer informe construyó el libro mayor del ciclo de vida: el rol DFINFRA se creó el 10 de junio de 2021, unas diez semanas antes del aut-num (24 de agosto de 2021); el AS declara relaciones de tránsito con AS9211 y AS13237, pero solo AS9211 aparece observado; y hay un conflicto aún sin resolver sobre el estado del objeto en las herramientas de RIPEstat [https://btw.media/en/governance/rir-watchdog/ripe-ncc/story/dfinfra-as210860-lifecycle-ledger]. Una nota anterior trazó el límite entre la señal de registro y la verificación operativa, concluyendo que el encadenamiento registro→control operativo estaba definido pero no probado [https://btw.media/en/dfinfra-as210860-registry-signal-and-verification-boundary].

Lo que ninguna de esas piezas examinó —y lo que este informe añade— es la estructura de costes del problema. El registro no genera el coste de verificación; lo transfiere. El objeto persiste sin modificación, la observación dice cero, la autodeclaración dice diez, y la carga de reconciliar esas tres capas recae íntegramente en cada consumidor individual: cada operador de interconexión, cada cliente potencial y cada analista repite el mismo trabajo.

El mecanismo económico

El mecanismo es sencillo de enunciar y costoso de ejecutar. Un registro de enrutamiento declara intenciones y atribuciones; la tabla global de BGP muestra hechos; PeeringDB recoge autodeclaraciones. En un operador sano, las tres capas convergen y la verificación es barata: se mira, coincide, se decide.

Cuando divergen, la verificación se vuelve un proyecto: hay que consultar múltiples espejos, resolver conflictos de nombres de organización (aquí, dos denominaciones diferentes para el mismo objeto ORG-EDG14-RIPE en fechas diferentes), distinguir estados declarados de estados observados y, aun así, llegar a una conclusión de forma negativa: no se puede probar que no haya negocio, solo que ninguna evidencia pública conservada lo muestra.

Para un mercado de infraestructura, ese coste no es abstracto. Las decisiones de interconexión se toman contra perfiles autodeclarados; las decisiones de compra contra catálogos; las decisiones de inversión contra registros de propiedad. Cuando un objeto persiste en la capa declarativa después de que su red desaparece de la capa observable, cada una de esas decisiones hereda una verificación extra, y el coste de esa verificación no lo paga quien mantiene el registro desalineado, sino cada contraparte que decide si confiar.

Condiciones que resolverían la pregunta

La ventaja de un análisis basado en evidencia es que las condiciones de resolución son precisas. La imagen actual de una red silenciosa con un contacto de registro persistente quedaría falsificada por cualquiera de estos hechos: un reanuncio de prefijos por AS210860 visible de forma independiente; una edición del perfil derivado de PeeringDB que corrija la autodeclaración; una modificación del aut-num o del rol DA9499-RIPE en la base autoritativa del RIPE; o una primera declaración de servicio, cliente o capacidad por parte de la organización registrada.

Ninguna de esas condiciones se ha cumplido en la evidencia conservada hasta la fecha de este informe.