Resumen

  • APNIC programó tres horas de mantenimiento de seguridad en Brisbane para el 15 de octubre y advirtió de posibles interrupciones de hasta cinco minutos en los servicios enumerados.
  • Su historial de estado registra ahora 2 h 56 de mantenimiento de DASH y 1 min 2 s para el repositorio RPKI, pero no mide cuánto tiempo estuvo inaccesible ninguno de ellos.

El registro público aporta ahora más detalle sobre la ventana de trabajo que un porcentaje de disponibilidad por sí solo, pero menos que un informe de impacto. APNIC programó actualizaciones de seguridad de los equipos de red de sus centros de datos de Brisbane entre las 06:00 y las 09:00 UTC+10 del 15 de octubre. Ese intervalo corresponde a las 20:00–23:00 UTC del 14 de octubre. El aviso decía que los servicios enumerados podían sufrir interrupciones de hasta cinco minutos.

El historial de APNIC muestra ahora dos registros de mantenimiento como completados. El de DASH va de las 20:03:29 a las 23:00:00 UTC y muestra una duración de 2 h 56. La entrada separada del repositorio RPKI va de las 21:51:30 a las 21:52:32, es decir, 1 min 2 s. Las dos actualizaciones de estado “In Progress” remiten al aviso del 15 de octubre.

Esos tiempos corresponden a registros etiquetados “Network maintenance”. No miden cuánto tiempo estuvieron DASH o el repositorio fuera de alcance. Los cinco minutos del aviso describen una interrupción posible, no una duración de pérdida de servicio observada. Junto a esas entradas, el historial no publica fallos de sondas, acciones de usuarios afectados, resultados de transacciones ni una prueba de recuperación para cada componente.

La hora de la consulta también importa. En una comprobación anterior, a las 09:16 UTC+10, el evento seguía como próximo y los valores de disponibilidad mostraban 100 %; el historial actual incluye registros de mantenimiento completados para componentes concretos. Esas nuevas líneas precisan la cronología del estado de mantenimiento, pero no calculan retrospectivamente la disponibilidad. APNIC no explica por qué la entrada de DASH abarca casi toda la ventana anunciada ni si los usuarios experimentaron una interrupción.

El aviso enumeraba servicios para miembros, API, web, RPKI y otros. Por eso los operadores necesitan distinguir el registro de mantenimiento de un fallo o una recuperación del servicio. Estas entradas no demuestran una interrupción de publicación RPKI, un efecto en el enrutamiento, daños a los miembros ni la caída de alguno de los dos componentes.

Fuentes: aviso de servicio de APNIC del 15 de octubre, APNIC Services Status y el informe anterior de Theo March sobre el cálculo público de disponibilidad de APNIC.