Resumen

  • El enrutamiento no cambió. Hurricane Electric, RIPEstat (RIS) y CIDR Report coinciden en que AS210860 no anuncia prefijos y no es un tránsito visible; la última visibilidad declarada en la tabla global data del 26 de marzo de 2026, según Hurricane Electric.
  • El registro sigue siendo ilegible de primera mano. La consulta autoritativa de apps.db.ripe.net devolvió de nuevo solo la carcasa de una aplicación JavaScript, sin valores de campo, en esta investigación igual que en la cobertura de septiembre; ningún valor del aut-num puede afirmarse en tiempo presente como hecho de registro.
  • Los espejos coinciden en el aut-num y discrepan en la organización. Dos espejos independientes reproducen campo por campo el mismo aut-num (as-name edeka_digital, org ORG-EDG14-RIPE, estado ASSIGNED, contactos DA9499-RIPE, última modificación 2021-10-27T08:53:15Z), pero uno muestra la organización como «EDEKA Verwaltungs- und Beteiligungs GmbH» con modificación el 2026-05-13 y el otro como «EDEKA DIGITAL GmbH» con modificación el 2021-10-27.
  • «RESERVED» no es un estado de aut-num. La documentación oficial de RIPE limita el atributo status de un aut-num a tres valores generados por software —ASSIGNED, LEGACY y OTHER—, de modo que la fila «RESERVED» sin titular que renderiza RIPEstat apunta a otra capa de datos, no a un cambio del objeto; el conflicto deja de ser una contradicción registral y pasa a ser una diferencia de capa pendiente de lectura autoritativa.
  • La prueba decisiva es de acceso, no de interpretación. La API REST de RIPE (con parámetros sin filtrar y sin formatear, e historial de versiones) y una búsqueda inversa de objetos route/route6 —ninguna ejecutada aquí— son las lecturas concretas que cerrarían o desmentirían la cadena de control.

El resto del artículo desarrolla cada punto con las fechas, los valores de campo y los atributos de fuente que los sostienen.

El enrutamiento: la ausencia como dato medible

Para el plano operativo, la investigación partía de una hipótesis simple: si algo había cambiado desde el 26 de marzo de 2026, alguna de las fuentes de observación más citadas debería reflejarlo. Ninguna lo refleja. Hurricane Electric, el servicio cuyas tablas BGP son la referencia más citada para verificaciones de este tipo, declara que AS210860 no ha sido visible en la tabla de enrutamiento global desde el 26 de marzo de 2026, y su ficha cuantifica el resto del cuadro con precisión de listado: un prefijo IPv4 originado históricamente —193.21.248.0/21, atribuido a EDEKA DIGITAL GmbH—, cero prefijos anunciados actualmente en todas las familias, cero entradas originadas con validez RPKI, cero con invalidez RPKI y un único par BGP observado, AS9211 (Nawork Internet Informationssysteme GmbH) https://bgp.he.net/AS210860.

La vista IPv4 de la misma fuente repite la ausencia desde el 26 de marzo de 2026 y reproduce el objeto aut-num de RIPE con sus mantenedores —RIPE-NCC-END-MNT y EDDI-MNT—, lo que permite verificar que la coincidencia entre ambas vistas no es un artefacto de formato sino una duplicación de contenido https://ipv4.bgp.he.net/AS210860.

RIPEstat, el servicio de observación operado por el propio RIPE NCC, coincide en la sustancia: su panel de información de enrutamiento declara que AS210860 no origina prefijos visibles en RIS y no se ve en RIS como tránsito, y su sección de detalles de prefijos muestra cero registros. Sus paneles llevan sellos de instantánea del 14 de septiembre de 2026 (00:00:00 y 09:03:00), de modo que describen una ventana de observación, no una lectura en vivo; ese matiz importa para el análisis del valor «RESERVED» que se examina más abajo https://stat.ripe.net/resource/AS210860.

CIDR Report cierra el cuarteto de observadores: clasifica el sistema autónomo como «NOT Announced» —no usado actualmente para anunciar prefijos en la tabla global ni como AS de tránsito visible— y lo lista bajo la etiqueta EDEKA_DIGITAL, DE https://www.cidr-report.org/cgi-bin/as-report?as=AS210860&view=2.0. IPinfo, en su capa de agregación comercial, etiqueta al ASN como «Inactive» con cero prefijos, atribuyéndolo a EDEKA Verwaltungs- und Beteiligungs GmbH, registro RIPE, creado el 24 de agosto de 2021 y modificado por última vez el 27 de octubre de 2021 https://ipinfo.io/AS210860.

Tres precisiones sobre la calidad de esta evidencia. Primera: que varios servicios independientes coincidan en la ausencia no la convierte en una medición continua; cada uno deriva de instantáneas periódicas de la tabla global, y la propia página de Hurricane Electric lleva una marca de actualización (julio de 2026 según la síntesis de septiembre), de modo que sus cifras deben leerse como un listado, no como un testigo en tiempo real.

Segunda: el único par observado con valor concreto en esta investigación es AS9211, según Hurricane Electric; la cobertura de septiembre registró una atribución adicional de AS32787 (Akamai Technologies) al ASN, pero esa atribución no apareció en la porción del espejo IP.CC examinada aquí, por lo que no puede citarse con valores de esta ventana.

Tercera: una derivación de PeeringDB documentada por la cobertura de septiembre seguía autodeclarando diez prefijos IPv4 y uno IPv6 para este ASN, en contradicción directa con todas las observaciones de enrutamiento; esa cifra no fue replicada por ningún observador de la tabla global y permanece sin conciliar.

El registro: la lectura autoritativa vuelve a fallar

La pregunta más simple de todas —¿qué dice hoy el registro de RIPE sobre AS210860?— sigue sin respuesta de primera mano. La URL autoritativa de la interfaz web de la base de datos para el objeto aut-num devolvió, en la recuperación de esta investigación del 30 de septiembre de 2026, únicamente el título de la aplicación —«Webupdates — RIPE Network Coordination Centre»— y ninguna línea RPSL. La razón es estructural: db-web-ui es una aplicación renderizada en el cliente, cuyo contenido se descarga mediante JavaScript después de la carga de la página, de modo que una lectura ordinaria obtiene la carcasa y no los valores https://apps.db.ripe.net/db-web-ui/lookup?key=AS210860&type=aut-num.

El fallo es idéntico al documentado por la cobertura de septiembre de 2026, que también se topó con la carcasa en su única consulta al punto autoritativo. La conclusión de entonces conserva plena vigencia y queda reforzada: sin lectura autoritativa, todo valor registral publicado —incluidos los que este artículo reproduce— es derivado de espejos con instantáneas de frescura no declarada.

La ruta de salida está documentada por el propio RIPE NCC. La API REST de la base de datos admite consultas de un solo objeto por fuente, tipo de objeto y clave, con parámetros unfiltered y unformatted y salida JSON, y expone el historial de versiones de un objeto a través de una ruta de versiones numeradas; por omisión, la salida filtra atributos como las direcciones de notificación https://docs.db.ripe.net/How-to-Query-the-RIPE-Database/RESTful-API-Queries. Ninguno de esos puntos finales fue consultado en esta investigación, de modo que los valores en vivo siguen sin verificar de primera mano; la sección final identifica exactamente qué resolvería cada lectura.

Dos espejos, un aut-num idéntico

El objeto aut-num es la unidad mínima de identidad del ASN en el registro: declara el nombre, la organización a la que se asigna, los contactos, el estado y los mantenedores. Dos espejos independientes del WHOIS de RIPE reproducen ese objeto con campos idénticos. El espejo de IPIP.NET devuelve el bloque siguiente, de forma prácticamente textual en la recuperación de esta investigación https://whois.ipip.net/AS210860:

aut-num:        AS210860
as-name:        edeka_digital
org:            ORG-EDG14-RIPE
import:         from AS9211 accept ANY
export:         to AS9211 announce AS210860
import:         from AS13237 accept ANY
export:         to AS13237 announce AS210860
admin-c:        DA9499-RIPE
tech-c:         DA9499-RIPE
status:         ASSIGNED
mnt-by:         RIPE-NCC-END-MNT
mnt-by:         EDDI-MNT
created:        2021-08-24T08:30:41Z
last-modified:  2021-10-27T08:53:15Z
source:         RIPE

El espejo IP.CC reproduce exactamente los mismos campos para el mismo objeto: as-name edeka_digital, organización ORG-EDG14-RIPE, las mismas políticas simétricas de importación y exportación frente a AS9211 y AS13237, los mismos contactos DA9499-RIPE en las funciones administrativa y técnica, el mismo estado ASSIGNED, los mismos dos mantenedores, la misma fecha de creación (2021-08-24T08:30:41Z) y la misma de última modificación (2021-10-27T08:53:15Z). Su pie de servicio indica «RIPE Database Query Service version 1.117 (SHETLAND)», una instantánea sin fecha explícita https://ip.cc/topic/asn/AS210860/.

Conviene ser exacto sobre qué prueba esta coincidencia y qué no. Prueba que los dos espejos comparten una misma captura del objeto y que sus copias no han divergido en el aut-num. No prueba nada sobre la frescura de esa captura: un espejo puede reproducir fielmente un objeto que dejó de ser actual hace meses. Tampoco acredita el valor de los campos; replica la salida del WHOIS, y la única capa capaz de corroborar el valor actual del objeto —el registro autoritativo o su API— es precisamente la que sigue inaccesible.

La organización: el punto donde los espejos se separan

El objeto organización es donde la coincidencia termina. El espejo de IPIP.NET, citado en la sección anterior, muestra el objeto ORG-EDG14-RIPE con el nombre «EDEKA Verwaltungs- und Beteiligungs GmbH», número de registro «District court Hamburg HRB 90516», tipo de organización LIR, país DE y dirección en New-York-Ring 6, 22297 Hamburg, creado el 2021-06-10T07:41:43Z y modificado por última vez el 2026-05-13T07:28:38Z; su contacto de abuso es AR63310-RIPE.

El espejo IP.CC, también citado antes, muestra el mismo identificador ORG-EDG14-RIPE con un nombre distinto —«EDEKA DIGITAL GmbH»— y una fecha de última modificación distinta: 2021-10-27T08:58:29Z. La divergencia es doble y del mismo tipo: nombre de la organización y fecha de modificación. Dado que ambos espejos reproducen el mismo identificador de objeto, la explicación más plausible es una diferencia de frescura o de filtrado entre copias del WHOIS, no dos objetos distintos; pero mientras el punto autoritativo sea ilegible, tampoco esta hipótesis puede verificarse.

El nombre de la organización no es un detalle de formato, porque la misma oscilación aparece fuera de los espejos. Las páginas de Hurricane Electric titulan el ASN «EDEKA Verwaltungs- und Beteiligungs GmbH», mientras que su propia fila del prefijo históricamente originado atribuye 193.21.248.0/21 a «EDEKA DIGITAL GmbH» —la misma divergencia de nombres dentro de una sola página.

Una capa más abajo de calidad, el agregador IPGeolocation.io diverge de todos los anteriores: nombra como organización «RIPE Network Coordination Centre», país NL, tipo BUSINESS, fecha de asignación «N/A» y cero rutas IPv4 e IPv6; su respuesta WHOIS cruda reproduce un as-block «AS208885 - AS214345» con fecha de creación y modificación 2026-07-13T14:17:33Z, sin cuerpo del objeto aut-num https://ipgeolocation.io/browse/asn/AS210860. El espejo de IPIP.NET, en cambio, muestra un as-block «AS208189 - AS214345» con fecha 2026-02-12T14:40:05Z como contenedor del ASN. Ambos rangos contienen numéricamente a AS210860, y que dos copias presenten bloques contenedores distintos con fechas distintas es otra señal de copias desincronizadas o filtradas de manera diferente. El perfil de este agregador —nombres por omisión del bloque IANA/RIPE NCC cuando no resuelve el titular— sugiere que sus campos de nivel ASN deben tratarse como poco fiables más que como evidencia contradictoria.

El valor «RESERVED»: lo que la documentación oficial acota

El conflicto de estatus descrito en septiembre se mantenía sin adjudicar: RIPEstat renderiza la fila RIR del ASN como «RIPE NCC | RESERVED | -», con nombre y titular vacíos, mientras que los espejos del WHOIS muestran «status: ASSIGNED» bajo una organización con nombre https://stat.ripe.net/resource/AS210860.

La documentación oficial de RIPE permite ahora acotar ese conflicto con precisión. Según la descripción oficial de los objetos primarios, el atributo status de un aut-num es un atributo generado con exactamente tres categorías: «ASSIGNED» (números de sistema autónomo asignados por el RIPE NCC), «LEGACY» y «OTHER» (cualquier aut-num que no sea una de las anteriores); el usuario no puede establecer, eliminar ni cambiar este valor, que el software determina a partir de la información de registro del recurso y establece cuando el objeto se actualiza. «RESERVED» no figura entre los tres valores posibles de un aut-num https://docs.db.ripe.net/RPSL-Object-Types/Descriptions-of-Primary-Objects/.

La lectura directa es que la fila de RIPEstat no describe el atributo status del aut-num sino otra capa de datos —el estado de la información de registro de recursos—, y que presentarla como un cambio de estatus del objeto sería un error de capa. La lectura cauta añade dos cautelas. Primera: RIPEstat no ofrece nota explicativa sobre esa fila, y sus sellos de instantánea del 14 de septiembre de 2026 no permiten descartar que refleje una capa desactualizada.

Segunda: la misma documentación de RIPE registra un mecanismo por el que un objeto puede quedarse sin titular —la retirada del atributo sponsoring-org por parte del RIPE NCC en el intervalo entre contratos—, de modo que un estado sin titular no es una condición imposible en el marco de RIPE; es precisamente por eso que la fila merece una lectura autoritativa antes de ser descartada o de ser tomada como cambio registral. Este artículo no cierra la cuestión; la reencuadra: de contradicción entre fuentes a diferencia entre capas cuya resolución exige la lectura de primera mano que sigue pendiente.

Los objetos de ruta: la pieza que sigue sin leerse

En el marco de RIPE, el objeto aut-num no enumera prefijos. La documentación oficial citada en la sección anterior es explícita: los prefijos se vinculan al origen mediante objetos route (IPv4) o route6 (IPv6) separados, y en ausencia del atributo mnt-routes, los mantenedores declarados en mnt-by del aut-num son quienes autorizan la creación de esos objetos de ruta.

Ningún espejo consultado en esta investigación mostró un objeto route o route6 para AS210860 ni para 193.21.248.0/21. Pero esa ausencia tiene un límite metodológico declarado: una consulta por clave de número de sistema autónomo no abarca el espacio de objetos de ruta, que exige una búsqueda inversa por origen. La ausencia de objetos de ruta en las salidas espejadas no prueba, por tanto, que no existan; prueba que el instrumento aplicado no estaba diseñado para encontrarlos.

La única evidencia de origen histórico procede de la vista de Hurricane Electric citada al principio: un prefijo originado, 193.21.248.0/21, atribuido a EDEKA DIGITAL GmbH, hoy sin anuncios. Un prefijo que una vez apareció en la tabla global implica, en el marco de RIPE, la existencia pasada de una autorización que lo respaldaba; su existencia presente, su mantenimiento y su estado de ROA no están verificados de primera mano en esta investigación.

Los ceros de RPKI de la vista de Hurricane Electric —cero válidos, cero inválidos— miden las entradas originadas en esa vista, no el estado de autorización del recurso; confundir ambas cosas sería exactamente el tipo de error de capa que este artículo intenta evitar.

Qué cambia respecto de septiembre de 2026

La cobertura de BTW publicada el 10 y el 11 de septiembre de 2026 definió una cadena de control de cuatro capas —lo registrado, lo autorizado, lo observado y lo controlado— y concedió expresamente que no podía cerrarla: el paquete de fuentes de entonces no recuperó los valores de campo en vivo, incluido el estado de ROA actual y el contenido de los objetos de ruta. Esta investigación se propuso actualizar esa condición en tres frentes concretos —anuncios, validez RPKI y detalle registral— y el resultado, punto por punto, es el siguiente.

En anuncios, sin cambio: los tres observadores coinciden en la ausencia continua de anuncios desde el 26 de marzo de 2026, y ninguno registra un evento posterior. En RPKI, sin medición nueva: las entradas válidas e inválidas de la vista de Hurricane Electric siguen siendo cero, pero el estado de ROA del recurso no fue medido de primera mano. En detalle registral, dos cambios documentales.

Primero, la divergencia entre espejos en el objeto organización —nombre y fecha de última modificación, 2026-05-13 frente a 2021-10-27— es ahora una divergencia documentada entre dos fuentes independientes de esta ventana; la síntesis de septiembre reportó la fecha de mayo de 2026 desde un único espejo, sin contraste posible. Segundo, el conflicto de estatus ya no queda suspendido entre fuentes: la documentación oficial de RIPE excluye «RESERVED» como valor de aut-num, lo que convierte la fila de RIPEstat en una señal de otra capa de datos y no en un cambio del objeto.

Lo que no cambió es la condición estructural del caso: el punto autoritativo volvió a ser ilegible, así que todos los valores siguen siendo espejo-derivados, y la cadena entre el nombre DFINFRA —una función de contacto (DA9499-RIPE) dentro del objeto aut-num— y cualquier operación real de red sigue igual de abierta que cuando se definió.

La cadena de control: lo que hoy puede afirmarse

Capa registrada: existe, pero solo a través de espejos. Dos copias independientes muestran un aut-num estable desde el 27 de octubre de 2021, con estado ASSIGNED, organización ORG-EDG14-RIPE, contactos administrativo y técnico DA9499-RIPE y mantenedores RIPE-NCC-END-MNT y EDDI-MNT; la capa autoritativa sigue inaccesible para lectura ordinaria.

Capa autorizada: lo observable es la negación de la autorización de anuncios. Cero entradas RPKI válidas e inválidas en la vista de Hurricane Electric y ningún anuncio desde el 26 de marzo de 2026; los mantenedores declarados serían la autoridad de escritura de los objetos de ruta, pero ninguno fue observado.

Capa observada: ausencia. No hay origen, no hay tránsito, no hay prefijos, y no hay pares más allá del único registrado por Hurricane Electric, AS9211.

Capa controlada: nada. Ninguna fuente de este paquete vincula a un actor identificable con la operación actual de routers, decisiones de enrutamiento o consecuencias comerciales verificables. El nombre DFINFRA aparece en el registro —según los espejos— como una función de contacto dentro del objeto aut-num; un puntero administrativo de ese tipo identifica a quién notificar, no quién opera. La distancia entre ambas cosas es, en sentido estricto, la brecha que este caso sigue sin cerrar.

La próxima prueba observable

Cada lectura pendiente corresponde a una pregunta distinta, y todas están al alcance de instrumentos documentados públicamente.

Primera, la lectura autoritativa del aut-num por la API REST de la base de datos de RIPE —con los parámetros sin filtrar y sin formatear, y con el historial de versiones del objeto— resolvería simultáneamente cuatro cuestiones abiertas: el estado vigente del objeto, el nombre real de la organización, la fecha real de su última modificación y la secuencia histórica de cambios que explica por qué los espejos divergen. Si el historial no registra cambios desde 2021, la divergencia es de frescura de espejos; si registra uno en mayo de 2026, la fecha del espejo de IPIP.NET es la correcta y la de IP.CC, la obsoleta.

Segunda, la búsqueda inversa de orígenes mostraría si existe hoy algún objeto route o route6 con origen AS210860, y qué mantenedor lo autoriza; su ausencia confirmaría que el ASN carece incluso de aserción administrativa de anuncio, y su presencia sin anuncios marcaría una aserción sin operación.

Tercera, la capa de información de registro que alimenta la fila «RESERVED» de RIPEstat —contrastada contra el WHOIS autoritativo— diría si esa fila describe el estado de la información de registro de recursos y por qué difiere de los espejos.

Cuarta, la vigilancia continua de eventos RIS: cualquier origen, retiro o cambio de ruta atribuido a AS210860 sería el primer hecho operacional del ASN desde el 26 de marzo de 2026, y alteraría el cuadro completo en una sola observación.

La condición que invalidaría la tesis de este artículo es exactamente esa: un anuncio verificado. Hasta que ocurra, la descripción precisa del caso es la que abrió este texto —cero rutas desde marzo, un registro leíble solo en espejos y una brecha de control que ninguna interpretación, por cuidadosa que sea, puede sustituir por la lectura de primera mano pendiente.

La ficha de la entidad DFINFRA en el directorio de BTW está disponible en https://btw.media/es/directory/dfinfra.