Resumen

  • Las actualizaciones de RIPE Database fallaron de forma intermitente durante casi ocho horas el 28 de octubre, incluidas las solicitudes de DNS inverso.
  • RIPE NCC concluyó después que ninguna solicitud fallida habría cambiado una delegación: unas no contenían cambios y otras fallaron las comprobaciones de Zonemaster.

Una delegación inversa parece un registro sencillo hasta que alguien intenta cambiarla. La dirección IP debe traducirse a una zona, esa zona debe apuntar a servidores que respondan y la solicitud debe superar controles antes de llegar al DNS público. La falla de RIPE Database del 28 de octubre interrumpió ese recorrido, pero la investigación posterior acotó el efecto: ninguna de las solicitudes fallidas habría cambiado el estado de una delegación.

RIPE NCC situó las fallas intermitentes entre las 11:42 y las 19:40 UTC. Su primer aviso, a las 20:04 CET, indicó que algunas actualizaciones no se procesaban y que ciertos objetos de dominio afectaban el servicio de DNS inverso. A las 20:23 informó que había aplicado una corrección y observaba el resultado; a las 20:32 marcó el incidente como resuelto.

El dato decisivo llegó el 30 de octubre. RIPE NCC dijo que las solicitudes fallidas se dividían en dos tipos: algunas no contenían cambios; las demás no superaban las pruebas de predelegación de Zonemaster. Por eso ninguna habría producido un cambio en la delegación inversa.

La escala técnica explica por qué importa esa frase. Un bloque IPv4 /22, por ejemplo, requiere cuatro zonas inversas /24 en la documentación de RIPE. Cada objeto de dominio registra una zona y sus servidores de nombres. RIPE Database utiliza esos objetos para generar las zonas que RIPE NCC publica en el DNS. Un cambio aceptado puede aparecer en la zona padre y, después, llegar a los resolutores.

La solicitud y la publicación pasan por etapas. Los servidores deben responder correctamente; RIPE rechaza una actualización si alguna prueba devuelve ERROR o CRITICAL. Incluso después de una actualización exitosa, la documentación indica que la información de delegación puede tardar hasta 24 horas en aparecer en DNS. El incidente afectó el procesamiento de solicitudes; la revisión posterior encontró que las solicitudes fallidas no habrían alterado la delegación publicada.

Esa precisión es mejor que llamar “cambio DNS” a todo error de actualización. Un fallo de escritura, un objeto modificado y una zona publicada describen estados distintos. RIPE NCC no publicó cuántas solicitudes fallaron ni la causa técnica; esos datos permitirían medir la magnitud y explicar el incidente.

Fuentes