Resumen

  • APNIC dice que, mientras se mantenía un nodo del balanceador, el paso para drenar conexiones se aplicó por error al otro nodo y causó una interrupción. La nota enumera ocho servicios afectados, desde el portal de miembros hasta varias funciones de RPKI.
  • El aviso fija el incidente del 1 de octubre entre las 14:44 y las 15:01, UTC+10: son 17 minutos entre las marcas publicadas, aunque el campo de duración indica 15. APNIC anuncia una revisión de sus procedimientos de mantenimiento y conmutación por fallo, sin publicar usuarios afectados ni resultados de validación.

Análisis

La diferencia entre el nodo previsto para mantenimiento y aquel que recibió la orden de drenaje es el dato operativo central del aviso de APNIC, publicado el 2 de octubre. Según la organización, el trabajo se realizaba en un nodo del balanceador, pero el paso de vaciar conexiones se ejecutó sobre el otro y provocó una caída.

La lista oficial incluye ocho servicios: el portal MyAPNIC, registry-api.apnic.net, DASH, la plataforma de notificaciones, REx, RPKI rsync, el protocolo de aprovisionamiento y publicación RPKI y rsc-verifier.apnic.net. El alcance abarca funciones para miembros, del registro y relacionadas con RPKI. La lista muestra lo que APNIC reportó como afectado; no demuestra que los ocho servicios quedaran completamente inaccesibles durante todo el intervalo ni que compartan una misma ruta interna.

La cronología tiene una discrepancia verificable. El aviso marca el inicio a las 14:44 y el final a las 15:01, hora UTC+10. Entre ambas marcas hay 17 minutos, pero APNIC consigna una duración de 15. No se publican segundos ni una explicación que permita conciliarlos. Aunque la diferencia sea pequeña, deja dos medidas distintas para describir el mismo incidente.

APNIC señala que revisará sus procedimientos de mantenimiento y conmutación por fallo para aclararlos y añadir salvaguardas. Eso es una revisión anunciada, no prueba de que una nueva norma haya sido aprobada, probada o aplicada. El aviso no identifica a un responsable, un plazo, una comprobación de la instancia objetivo ni los tiempos de recuperación de cada servicio.

El límite de la evidencia es importante. Entre los afectados aparecen servicios RPKI, pero APNIC no informa de autorizaciones de origen de ruta obsoletas o incorrectas, efectos de enrutamiento, pérdida de datos, incidentes de seguridad ni errores en registros de recursos. Tampoco indica cuántos miembros o usuarios resultaron afectados. El episodio del 1 de octubre es distinto de las dos interrupciones de MyAPNIC de septiembre, con causas declaradas diferentes; no se establece un origen común.

Un seguimiento útil podría dejar constancia, sin revelar topología interna, del nodo previsto, de cómo se confirma el objetivo antes del drenaje, de las pruebas de servicio usadas para cerrar el incidente y del criterio para calcular la duración. Hasta que aparezca esa evidencia, la conclusión defendible es acotada: APNIC atribuye una caída en ocho servicios enumerados a un paso de mantenimiento mal dirigido y dice que revisará sus procedimientos.

Fuentes