Resumen

  • El Abuse Contact Finder traduce un recurso numérico —prefijo, dirección IP o ASN— en el contacto de abuso registrado para ese recurso y en el RIR autoritativo que lo administra; su propia documentación advierte de que la información es, en muchos casos, incorrecta o no está disponible.
  • La validación que exige la política 2017-02 comprueba el formato, las entradas DNS y, mediante ping, que el buzón exista y pueda aceptar correo; no envía ningún mensaje y no examina qué ocurre con los reportes que llegan a ese buzón.
  • La evidencia independiente muestra que la respuesta humana es la excepción y que la mitigación depende del reportero y de la categoría del abuso, no de que el contacto figure en el registro.

Qué devuelve el buscador

El endpoint documenta tres entradas posibles —un prefijo, una dirección IP individual o un ASN— y dos salidas principales: abuse_contacts, la lista de direcciones de abuso, y authoritative_rir, el registro que autoriza el recurso. La propia documentación incorpora una advertencia poco frecuente en una herramienta oficial: la información devuelta es "in many cases incorrect or not available". El registro describe así su propio resultado como una aproximación razonable, no como una garantía.

Desde 2015 el widget muestra únicamente la dirección abuse-c registrada, en línea con la política ripe-563, y ofrece al reportero un texto que puede añadir a su mensaje para indicar que localizó el contacto mediante el Abuse Contact Finder (guía del widget). RIPE-658, dirigido a CERT y a gestores de abuso, presenta la base de datos del RIPE y RIPEstat entre las herramientas para encontrar "the best matching abuse contact" de un recurso y describe abuse-c como "the preferred way to report any form of abuse" (RIPE-658).

La división de responsabilidades que el registro declara

La página de orientación sobre abuso del RIPE NCC es explícita sobre dónde termina su función. Indica al usuario que introduzca una dirección IP en RIPEstat para ver el contacto de abuso de la red a la que pertenece, y señala que es el operador de red —no el RIPE NCC— quien debe gestionar el reporte; el NCC solo se ocupa de que los contactos sean válidos y estén actualizados, y concluye: "There is nothing we can do if a network operator chooses not to reply" (orientación sobre abuso).

Esa frase no es una excusa administrativa: delimita la arquitectura de responsabilidad del sistema. El registro responde de la exactitud del directorio; el operador, del tratamiento del caso. Ninguna de las dos partes asume por contrato el resultado del reporte.

Lo que la validación comprueba

Bajo la política 2017-02, la herramienta de validación del RIPE NCC busca errores de formato, verifica las entradas DNS, detecta direcciones señuelo o trampa y comprueba mediante ping que el buzón exista y pueda aceptar correo. No envía correo alguno, no exige ninguna acción si la validación pasa y deja fuera de su alcance los recursos legacy. La misma página añade: "We have no say in what network operators do with any abuse reports they receive" (método de validación).

El objeto de la verificación es, por tanto, la alcanzabilidad técnica del buzón. La pregunta "¿y después qué?" queda fuera de la política por decisión de diseño, no por omisión.

Las cifras del registro

El resumen de implementación de 2017-02 cuantifica el esfuerzo: 77.168 atributos abuse-mailbox distintos, de los cuales 71.711 (93%) superaron la validación automatizada y 5.457 (7%) fallaron; el consenso sobre la política se alcanzó el 1 de junio de 2018 y la implementación completa llegó el 10 de octubre de 2019; unos 8.000 atributos se actualizaron en 2019 y la validación inicial requirió tres personas a tiempo completo con carácter temporal, con entre el 20% y el 25% de los tickets en seguimiento manual (resumen de implementación). Una actualización de progreso de mayo de 2019 ofrecía otro corte: alrededor de 9.500 contactos actualizados sobre unos 67.000 comprobados —cifra que incluye duplicados—, cerca del 60% de los casos resueltos sin intervención del personal y unos 50 recursos independientes que cambiaron de estatus de patrocinio (actualización de progreso). Ambas series describen el mismo patrón: una mayoría de contactos correctos o corregibles y una minoría persistente que exige trabajo humano.

El límite que el propio registro escribió

En 2019, la propuesta de política 2019-04 planteó validar al menos cada seis meses si el abuse-mailbox está presente y puede recibir mensajes. Su página contiene la frase que resume el debate: "This validation process will not check how the abuse cases are processed". El análisis de impacto del RIPE NCC estimó que un régimen semestral sobre unos 93.000 atributos generaría más de 32.000 tickets por ronda —64.000 al año— y alrededor de 19.200 tickets manuales anuales. La propuesta fue retirada el 8 de septiembre de 2020 y el 26 de octubre de 2020 el colectivo de presidentes de grupos de trabajo confirmó la decisión de los copresidentes del Grupo de Trabajo Anti-Abuso tras una apelación (propuesta 2019-04). La comunidad consideró y descartó ampliar la frecuencia de una verificación que, en cualquier caso, nunca iba a medir el tratamiento de los casos.

El estado estacionario

En RIPE 87, en 2023, el RIPE NCC describió el régimen consolidado: validación anual de unos 19.600 contactos en objetos de organización LIR, 58.100 en objetos de recurso LIR y 15.400 en objetos de recurso independiente; alrededor de 2.000 contactos comprobados cada semana y una tasa de fallo recurrente del 6% al 8%. Un abuse-c inválido en un objeto de recurso se sustituye por el abuse-c operativo del LIR; un abuse-c de LIR inválido desencadena una investigación extensa. Si un miembro permanece sin responder durante mucho tiempo, la membresía puede ser terminada. En una limpieza de ASN se contactó a más de 4.000 titulares y se recuperaron unos 2.150 ASN (54%) (RIPE 87).

Qué observan quienes envían los reportes

La perspectiva de quien reporta es más incómoda. Un experimento controlado y aleatorizado que envió 480 reportes de abuso a proveedores de alojamiento y propietarios de sitios web recibió 89 respuestas: 11 (12%) eran claramente humanas y 78 (88%) generadas por máquina. El mismo trabajo encontró que muchas partes notificadas no respondieron pero sí remediaron el problema, de modo que la ausencia de respuesta no equivale a ausencia de gestión; además, los informes detallados aumentan de forma significativa las tasas de limpieza (experimento con 480 reportes).

Un estudio de 2026 basado en los datos internos de abuso de un proveedor de alojamiento añade el matiz de categoría: la notificación al cliente y la mitigación dependen en gran medida del reportero y del tipo de abuso. Los reportes relacionados con material de abuso sexual infantil y con spam conducen a acciones de mitigación, mientras que las infracciones de derechos de autor y los escaneos de puertos suelen quedar desatendidos; el reporte individual, en general, se ignora con facilidad (estudio NDSS 2026).

Las guías operativas asumen ese entorno. La sección de preguntas frecuentes sobre reporte de incidentes de CSIRT.CZ explica cómo averiguar qué organización es responsable de una dirección IP a través de las bases de datos de los RIR, señala que el contacto de abuso registrado es la vía para reportar incidentes originados en una asignación y recomienda escalar a CSIRT.CZ solo si no se recibe una respuesta razonable en varios días (CSIRT.CZ).

Lo que queda sin documentar

Ninguna de las fuentes revisadas para este informe establece una métrica de resultado auditada de forma independiente para los reportes enviados a direcciones abuse-c. Tampoco existe un desglose público por etapas de los fallos de validación —formato, DNS o ping— ni consta que la terminación de membresía se haya aplicado efectivamente a un miembro que no responde. Las cifras de 2023 pueden no reflejar la cadencia actual, y los estudios académicos citados se refieren a proveedores de alojamiento y a abuso web o DNS, no específicamente a buzones abuse-c del RIPE. El expediente del directorio sobre esta herramienta (RIPEstat Abuse Contact Finder) reúne su comportamiento documentado y sirve de punto de partida para seguir esas lagunas.

Esa asimetría es el hallazgo central. El registro mide con precisión creciente lo que puede medir —que un buzón existe y acepta correo— y ha construido un proceso de tickets, limpiezas de ASN y validación anual alrededor de esa medida. Lo que ocurre después del envío queda, por diseño, fuera de su alcance y fuera de su contabilidad pública.