Resumen

  • RIPE-563 hizo obligatorio el atributo abuse-c en los objetos inetnum, inet6num y aut-num: el objeto de rol referenciado debe llevar una única dirección abuse-mailbox, disponible públicamente vía WHOIS y las API, capaz de recibir mensajes y sin imponer un formulario web al remitente. Al entrar en vigor, la exigencia no se extendía a los recursos de internet heredados.
  • Bajo la propuesta de política 2017-02, Regular abuse-c Validation, RIPE NCC valida estos atributos de forma proactiva al menos una vez al año, empezando por controles técnicos automatizados que no envían correo.
  • Un fallo marca el atributo como inválido y abre una cadena de escalada: ticket al LIR responsable, enlace de validación para cerrar falsos positivos, dos intentos de contacto más con una semana de intervalo, seguimiento del personal por teléfono u otro canal y, como último recurso, un procedimiento que puede terminar en el cierre del miembro y el desregistro de recursos de internet.
  • La validación evalúa presencia y alcanzabilidad, no el tratamiento de los casos de abuso. Las cifras reportadas por el registro sitúan en torno al 10–25 % los atributos posiblemente incorrectos o inactivos en una prueba inicial, y en cerca del 92,5 % la aprobación del control automatizado en una ronda posterior.

Un atributo obligatorio, un solo buzón

Para cualquier red en la región de servicio de RIPE NCC, el registro público que responde «¿a quién aviso?» es un atributo, no una relación. Cada objeto inetnum, inet6num y aut-num debe referenciar un objeto de rol con una única dirección abuse-mailbox, y RIPE-563 —la política que introdujo el requisito abuse-c— fijó los términos de esa promesa: la dirección debe estar públicamente disponible vía WHOIS y las API del registro, debe poder recibir mensajes y no puede imponer un formulario web al remitente (RIPE-563; requisitos del atributo). Una limitación vino integrada desde el inicio: al entrar en vigor, el requisito no se extendía a los recursos de internet heredados. Esa frontera sigue importando cada vez que un registro público se lee como prueba de que una red tiene un contacto responsable.

Una validación anual que no envía correo

Con la propuesta de política 2017-02, Regular abuse-c Validation, RIPE NCC no espera a que las quejas revelen una dirección muerta: valida los atributos abuse-mailbox de forma proactiva, al menos una vez al año. La primera etapa es automatizada y deliberadamente silenciosa: no se envía correo. El sistema busca errores de formato en la dirección, ejecuta comprobaciones DNS, detecta direcciones falsas o señuelo (bogus o honeypot) y comprueba que el buzón pueda aceptar correo (documentación del proceso). Los fallos que esto detecta son los que de otro modo permanecerían invisibles en la operación diaria: una errata, un dominio que ya no resuelve, una dirección que nunca existió.

Del atributo inválido al cierre del miembro

Una validación fallida no es solo un aviso: cambia el registro. El atributo se marca como inválido y se genera un ticket para el LIR responsable —el LIR patrocinador en el caso de recursos independientes—. Se envía un enlace de validación al propio buzón para que un falso positivo funcional pueda cerrarse. Si no hay respuesta, se intenta el contacto dos veces más con una semana de intervalo; después, un miembro del personal prueba por teléfono u otro canal; y como último recurso, RIPE NCC puede iniciar su procedimiento de cierre de miembros y desregistro de recursos de internet (cadena de escalada). La progresión merece leerse despacio: empieza corrigiendo una dirección de correo y termina exponiendo el propio registro.

La frontera: presencia y alcanzabilidad, no tratamiento

El proceso de validación comprueba que el atributo está presente y que el buzón es alcanzable; no evalúa cómo se gestionan los casos de abuso una vez recibidos (alcance del control, controles técnicos, resultados reportados). No es un defecto de ejecución: es el perímetro declarado del control. Un recurso puede ser perfectamente conforme sin que nada garantice que un reporte recibido sea leído, encaminado o cerrado. Y conviene recordar de dónde viene esa descripción: la documentación del propio registro es la única fuente disponible sobre lo que la validación mide, así que se lee como la posición de una parte interesada, no como una verificación independiente.

Cifras declaradas, dos medidas distintas

Los documentos de RIPE NCC reportan dos series de cifras (resultados reportados). Una prueba temprana de la herramienta de validación sugería que en torno al 10–25 % de los atributos abuse-mailbox podían ser incorrectos o estar inactivos. Una ronda de validación posterior reportó que cerca del 92,5 % superaba el control técnico automatizado. Las dos cifras no miden la misma población ni lo mismo: una prueba de herramienta y una tasa de aprobación de una ronda completa no se leen como una curva. En ambos casos son cifras declaradas por el registro, no auditadas de forma independiente aquí; establecen un orden de magnitud, no una tendencia. Sobre el punto más sensible —qué ocurre con los reportes tras su recepción— RIPE NCC ha señalado que deberían recopilarse y publicarse periódicamente estadísticas anonimizadas sobre el tratamiento de los casos de abuso. Los documentos disponibles no permiten establecer si esa publicación ha comenzado, con qué frecuencia ni con qué nivel de detalle.

Un buzón alcanzable no es una reparación

Lo que la validación compra es una condición previa: la posibilidad de que un reporte llegue a un operador. Lo que no compra es la respuesta, que depende de los procesos, el personal y los incentivos de cada LIR —elementos que el registro no mide—. Para quien envía un reporte, la diferencia es concreta: un contacto validado garantiza que un mensaje puede depositarse, no que será atendido. La ficha RIPE NCC — contactos de abuso del directorio sigue esa distinción entre alcanzabilidad y tratamiento.