Resumen

  • El contacto de abuso es una cadena de objetos: un atributo abuse-c en el objeto de recurso apunta a un role object con un abuse-mailbox protegido. Mantenerlo correcto es obligación del titular del recurso —el LIR o el LIR patrocinador—, no del registro.
  • Cuando los titulares no actuaron, fue el propio RIPE NCC quien creó contactos de relleno en diciembre de 2013 y noviembre de 2014, usando direcciones de la lista de miembros y del LIR patrocinador; muchos de esos correos nunca fueron limpiados.
  • En 2016 el propio registro reconoció que la obligación «ha resultado difícil de hacer cumplir, porque abuse-c no es un atributo obligatorio en el esquema de la base de datos RIPE»: la política y el esquema discrepan desde entonces.
  • Las cifras operativas del registro (~90.000 contactos distintos, con un 6–8% de fallos semanales de verificación en 2024; 93% aprobado sobre 77.168 buzones en 2019) miden entregabilidad, nunca respuesta humana.

Una cadena de objetos con un eslabón humano

La política que gobierna los contactos de abuso nació de la propuesta comunitaria 2011-06 (proposal 2011-06) y se concretó en ripe-563 (ripe-563), hoy evolucionada en ripe-705 (ripe-705). El diseño: todo inetnum, inet6num y aut-num debe llevar un atributo abuse-c que referencia un role object con un único abuse-mailbox, protegido contra eliminación mientras esté referenciado. La jerarquía permite herencia: los objetos más específicos heredan el contacto del objeto que los cubre salvo que referencien otra organización.

El mantenimiento recae en el titular del recurso. Según la documentación de implementación (abuse-c information), los miembros mantienen sus objetos de organización y rol; los usuarios finales de recursos PI lo hacen a través de su LIR patrocinador.

Los placeholders creados por el propio registro

Cuando los titulares no actuaron, el registro actuó por ellos. Desde diciembre de 2013 el RIPE NCC estableció abuse-c para recursos cuyos LIR no habían definido contacto, usando el correo de cada LIR de la lista de miembros; en noviembre de 2014 añadió automáticamente el contacto del LIR patrocinador a organizaciones patrocinadas no actualizadas (RIPE Labs, ripe-563).

En enero de 2016, Tim Bruijnzeels (RIPE NCC) documentó en la lista anti-abuse-wg las consecuencias: los LIR se llevaron «sorpresas desagradables» al descubrir su correo en el abuse-c de organizaciones que patrocinaban, las referencias obsoletas no se limpiaron, y el propio registro admitió que «en la práctica ha resultado difícil hacerlo cumplir, dado que abuse-c no es un atributo obligatorio en el esquema de la base de datos RIPE» (hilo anti-abuse-wg, enero 2016).

Objetos de rol sin personas

En las cadenas de reventa, la guía operativa del registro admite que el objeto de rol del cliente «no necesita referenciar ningún objeto person» y es público sin límites de consulta (FAQ abuse-c para asignaciones). El contacto nombrado puede ser, pues, un buzón vacío sin responsable identificable.

Qué miden las cifras

En RIPE 87, Marco Schmidt (Servicios de Registro) expuso alrededor de 90.000 contactos abuse-c distintos —~20.000 en objetos de organización LIR, ~58.000 en objetos de recursos, ~15.000 en recursos independientes—, unas 2.000 verificaciones semanales y «alrededor del 6 al 8% de esos correos falla», precisando que un fallo no implica necesariamente un contacto inactivo (transcripción RIPE 87). En RIPE 80 (2019), de 77.168 buzones distintos, 71.711 (93%) pasaron la validación automática y 5.457 (7%) fallaron (presentación RIPE 80); esa misma presentación reconoce que la política vigente «no proporciona validación suficiente de la disponibilidad real» del buzón y que su intención no es examinar cómo se monitoriza ni cómo se gestionan los casos.

El mecanismo verificado en RIPE 87 comprueba formato, registros DNS y que el buzón acepta correo; solo si falla se envía un enlace de verificación, se abre un ticket y se contacta al LIR (presentación RIPE 87 AAWG).

Fuentes complementarias