Summary

  • El historial público de APNIC situó el verificador RSC en mantenimiento el 6 de octubre, entre las 01:30 y las 02:45 UTC, durante un cambio de estrategia de despliegue.
  • A las 02:45 el incidente quedó marcado como completado; el RSS de estado registró el servicio como operativo y señaló un tiempo medio de respuesta de 780 milisegundos.

El historial de estado de APNIC registra 75 minutos de mantenimiento de rsc-verifier.apnic.net el 6 de octubre. El aviso en curso decía que el punto de acceso podía no estar disponible mientras se cambiaba la estrategia de despliegue. A las 02:45 UTC pasó a «Maintenance completed». El RSS marcó el componente como operativo a esa misma hora y le atribuyó un tiempo medio de respuesta de 780 milisegundos.

Eso describe un cambio de estado del servicio, no una nota de versión. El registro público no identifica la versión del software ni el cambio realizado, no cuenta a los usuarios afectados, no informa de verificaciones fallidas ni describe una prueba de aceptación. Los 780 milisegundos son una estadística puntual del feed al cierre de la ventana, no un compromiso de servicio ni una prueba de que todos los usuarios pudieran validar un objeto.

La diferencia importa porque el verificador público es solo una vía para comprobar una RPKI Signed Checklist (RSC). APNIC explica que un titular de recursos puede firmar archivos o documentos con un certificado RPKI asociado a direcciones IP o ASN determinados. El destinatario puede comprobar la firma localmente con rpki-client o utilizar el servicio web público de APNIC. El sitio facilita la comprobación, pero no origina la autoridad de la firma.

Por tanto, el registro permite una conclusión acotada: el verificador RSC público entró en mantenimiento y fue declarado operativo a la hora indicada. No demuestra que se interrumpieran la firma de RSC, la emisión de certificados, la publicación de repositorios, el procesamiento de ROA o el enrutamiento BGP. Tampoco dice si un RSC concreto pudo verificarse durante esa ventana. La comprobación local es una vía distinta, siempre que el usuario tenga una herramienta adecuada y los datos RPKI necesarios.

Ese límite es relevante junto a otros avisos recientes de APNIC. El comunicado del 1 de octubre describió un error separado del balanceador que afectó a ocho servicios, incluido el verificador RSC; las fuentes públicas revisadas no vinculan ese episodio con el mantenimiento del 6 de octubre. Un aviso posterior para el 13 de octubre se refería a otro punto: el servicio rsync de RPKI. No son una única interrupción prolongada.

Para quienes usan RSC en procesos BYOIP, de incorporación de clientes o de prueba de titularidad de recursos, un verificador en línea puede simplificar la relación con terceros. Un procedimiento resistente debería aclarar si la otra parte acepta una verificación local, qué implementación reconoce, qué recursos comprueba y cómo conserva el resultado. Así, la disponibilidad del sitio es una cuestión de acceso y no una dependencia criptográfica implícita.

Fuentes