Resumen

  • APNIC informa de que uno de sus firewalls de red detectó un fallo de hardware y reinició entre las 19:10 y las 19:18, UTC+10, del 28 de agosto de 2026.
  • El aviso incluye MyAPNIC, la API del registro, Orbit, FTP, los protocolos de aprovisionamiento y publicación RPKI, y la descarga RPKI mediante rsync.
  • No hay evidencia pública de pérdida o corrupción de datos, operaciones duplicadas ni incidente de seguridad. Tampoco hay un cierre separado para tareas aceptadas, colas o representaciones de cada servicio.
  • Un comprobante por clase de operación puede indicar recepción, aceptación, confirmación, visibilidad, repetición segura y vaciado de cola sin revelar datos de miembros ni la topología privada.

El dato tranquilizador y la pregunta pendiente

El anuncio de APNIC contiene más precisión que una alerta genérica. Fija el comienzo a las 19:10 y el final a las 19:18 en UTC+10. Identifica el desencadenante como un fallo de hardware detectado por un firewall de red, tras el cual el equipo reinició. APNIC trabaja con el proveedor y dice que mejorará la conmutación del tráfico entre firewalls. El canal RSS conserva la misma descripción.

Ocho minutos es un dato tranquilizador. Sin embargo, «servicio afectado» no dice si una conexión fue rechazada, una petición quedó sin respuesta, una tarea ya había sido aceptada, una publicación se retrasó o una lectura falló mientras el objeto seguía intacto. El aviso no atribuye esos resultados y el análisis no debe inventarlos.

La pregunta legítima es otra: cuando regresó el tráfico, ¿qué estado tenían las operaciones que podían haber quedado a ambos lados del corte?

La API separa enviar, aceptar y completar

La documentación de lanzamiento de la API explica que sirve para recuperar información de delegaciones y administrar registros Whois, DNS inverso, ROA y objetos de ruta. Por tanto, algunas llamadas leen; otras cambian un estado que luego aparece en superficies públicas o de cuenta.

APNIC describe un modelo asíncrono. Cada actualización crea un objeto de tarea y el cliente recibe una dirección para consultar su progreso. Cuando la tarea termina, allí aparece el resultado. También indica que ciertos lotes de DNS inverso y gestión abstracta de rutas se aplican transaccionalmente cuando es posible.

Ese diseño evita reducir una actualización a la duración de una conexión HTTP. Una llamada puede no haber llegado. Puede haber llegado y no haber sido admitida. Puede existir ya como tarea. Puede haber concluido aunque el cliente no recibiera la última respuesta. Cada caso exige una acción distinta.

Repetir es razonable en el primero; consultar la tarea es mejor en el tercero; escribir de nuevo tras una confirmación incierta puede añadir ruido en el cuarto. El aviso del 28 de agosto no afirma que ocurriera ninguno de ellos. Simplemente no expone qué rama corresponde a las tareas alrededor del intervalo.

MyAPNIC y la API, además, son dos vistas de funciones comunes. APNIC dice que una modificación de rutas realizada en la API aparece en MyAPNIC y viceversa. Volver a abrir el portal prueba que una lectura responde; no demuestra por sí sola que una tarea anterior finalizó ni que ambas vistas se reconciliaron al mismo segundo.

Un cierre útil diría si no se aceptaron escrituras, si las tareas aceptadas se completaron, si queda una cola, o si la evidencia no permite saberlo. «Firewall recuperado» no es una respuesta equivocada; es una respuesta a otra capa.

Un mensaje y un archivo plantean riesgos opuestos

Orbit es la plataforma de comunicación comunitaria de APNIC y la evolución de sus listas de correo. Una persona puede leer un archivo, publicar una intervención o recibir correo. Si falla una lectura, repetirla suele ser inocuo. Si se desconoce si una publicación fue aceptada, reenviarla sin comprobar el archivo puede crear un duplicado. El correo retrasado tiene un tercer criterio de fin.

FTP es distinto. El formato de intercambio estadístico de los RIR define archivos públicos sin control de acceso, nombres persistentes para la edición más reciente y elementos de validación. Un fallo de descarga no implica que el archivo esté dañado. Una edición nueva puede haberse generado pero no estar visible en un acceso concreto. El alias latest puede necesitar una comprobación separada de su archivo fechado.

Nada prueba que esas situaciones sucedieran. Precisamente por eso, el aviso no debe convertirse ni en acusación ni en garantía. Un estado breve —solo lectura interrumpida, publicación aplazada, objeto sin cambios, referencia verificada, cola vaciada o desconocido— bastaría para orientar al consumidor.

RPKI no es una sola conversación

La declaración de prácticas RPKI de APNIC distingue el aprovisionamiento, la publicación, la exposición del repositorio por rsync y la exposición por RRDP. Son interfaces con participantes y sentidos diferentes.

La RFC 6492 define intercambios de petición y respuesta para aprovisionar certificados de recursos. La RFC 8181 define cómo un editor entrega objetos al repositorio. La RFC 8182 define RRDP sobre HTTPS para que las partes usuarias sincronicen los datos.

El aviso enumera juntos los protocolos de aprovisionamiento y publicación y, por separado, RPKI rsync. No menciona RRDP. Esa ausencia no permite concluir que RRDP funcionó, falló o estuvo fuera del camino del firewall. Solo establece que el texto público no le atribuye un estado.

Tampoco una interrupción en la descarga demuestra un efecto inmediato en el encaminamiento. Los validadores recopilan objetos, los validan localmente y alimentan otras decisiones según sus ciclos. No se publica aquí la edad de una caché, la caducidad de un objeto ni el comportamiento de un validador.

El cierre debe formular preguntas específicas. ¿Obtuvo respuesta la petición de aprovisionamiento? ¿El repositorio confirmó la publicación o el editor debe repetirla? ¿El conjunto servido por rsync volvió consistente? ¿Se observó RRDP y con qué alcance? Mantener las preguntas separadas evita que el acrónimo RPKI convierta varios flujos en un supuesto único apagón.

Un aviso corto puede tener un cierre posterior

APNIC tenía buenas razones para publicar pronto. Un anuncio inicial ayuda a correlacionar síntomas y demuestra que el equipo ha identificado una clase de fallo. Esperar a reconciliar todas las tareas antes de alertar sería contraproducente.

El reloj agregado también sirve para disponibilidad. APNIC explica en su informe del cuarto trimestre de 2025 que combina sondas externas con el porcentaje de peticiones exitosas visto por los usuarios y evita contar dos veces el mismo periodo. Ya existe, por tanto, una práctica pública de separar una observación del extremo y el resultado de las peticiones.

La extensión lógica es un cierre en dos tiempos. Primero, el aviso rápido: causa conocida hasta ese momento, superficies y reloj de infraestructura. Después, un comprobante operativo: qué clases de trabajo fueron aceptadas, cuál concluyó, qué representación se verificó y cuándo se vació cualquier cola.

El comprobante mínimo

Un identificador de incidente puede agrupar todo el episodio sin imponer un estado único. Debajo, cada fila identifica interfaz, sentido y tipo de operación: actualización de miembro, consulta de tarea, mensaje o lectura comunitaria, publicación o descarga de archivo, aprovisionamiento RPKI, publicación RPKI, lectura rsync y observación RRDP cuando corresponda.

Las etiquetas no necesitan revelar contenido: no recibido, rechazado antes de aceptación, aceptado, confirmado, revertido, pendiente, visible, seguro de repetir, solo consultar, desconocido. El regreso de la interfaz, el vaciado de la cola y la comprobación entre representaciones deben tener tiempos propios.

APNIC puede publicar bandas de error y guardar los registros detallados bajo control. No hacen falta direcciones internas, credenciales, nombres de miembros, ROA concretas, textos de mensajes ni números de serie del equipo. Si una revisión cambia el estado, la corrección debe conservar el valor anterior y su fecha.

El incidente del firewall terminó a las 19:18 según APNIC. Esa hora responde a una pregunta de infraestructura. Una escritura termina al conocer su aceptación y efecto; una publicación termina al conocer el estado del repositorio; una lectura termina con una representación comprobable. Agruparlas es sensato. Confundir sus finales no lo es.

Fuentes