Summary

  • RIPE NCC registra fallos intermitentes de la base y de delegaciones inversas hasta las 19:40 UTC del 28 de octubre.
  • La página de la incidencia marca la resolución a las 20:32 CET (19:32 UTC); la revisión del 30 de octubre dice que ninguna solicitud fallida habría cambiado una delegación.

La primera actualización de la página de estado describió un problema activo: algunas modificaciones de la base de RIPE no se procesaban y ciertos objetos de dominio afectaban también al servicio de DNS inverso. El incidente duró desde las 11:42 hasta las 19:40 UTC del 28 de octubre. RIPE NCC aplicó una corrección, vigiló el servicio y marcó el incidente como resuelto a las 20:32 CET.

El 28 de octubre hay que convertir ambas horas al mismo huso. El calendario de horario de verano de 2026 de la Comisión Europea fija el cambio al horario estándar el 25 de octubre; por tanto, las 20:32 CET son las 19:32 UTC. El historial de RIPE sitúa el final del periodo afectado a las 19:40 UTC. La hora de resolución queda ocho minutos antes del final indicado.

Dos días después, el registro público precisó el resultado. Al revisar las solicitudes fallidas, RIPE NCC concluyó que ninguna habría producido un cambio en una delegación inversa. Algunas no contenían ningún cambio; las demás no superaron las comprobaciones previas de Zonemaster. La ruta de actualización fallaba, pero las solicitudes examinadas no habían pasado las comprobaciones necesarias para modificar el registro.

Esa diferencia es la noticia. Un fallo puede interrumpir una operación sin cambiar el estado que debía controlar. RIPE NCC dice que la creación, modificación o eliminación de delegaciones inversas falló de forma intermitente; su revisión posterior dice que esas solicitudes no habrían alterado las delegaciones de todos modos. El historial ofrece ambos datos, pero no cuántas solicitudes hubo en cada grupo.

RIPE NCC no ha aclarado si las actualizaciones se reanudaron a las 19:32 o a las 19:40 UTC; una hora de recuperación corregida y normalizada permitiría saber si es un desfase de visualización o si la incidencia se cerró antes de terminar el periodo afectado.

La cronología resulta útil. A las 20:04 CET, RIPE NCC informó de actualizaciones que no se procesaban y de objetos de dominio que afectaban al DNS inverso. A las 20:23 anunció que había aplicado una corrección y empezaba a vigilar los resultados. A las 20:32 dio el incidente por resuelto. El 30 de octubre añadió la explicación sobre las solicitudes. Las primeras entradas describen la recuperación del servicio; la última delimita el efecto sobre el estado del registro.

La cronología pasa de las actualizaciones fallidas a la corrección y la vigilancia, y después a la revisión de las solicitudes. Publicar el resultado de los reintentos mostraría si quedaron cambios válidos pendientes tras recuperar el servicio.

Registros: cronología del incidente de RIPE NCC; historial de estado y actualización del 30 de octubre; calendario de horario de verano de 2026 de la Comisión Europea.