Resumen

  • Un registro de RIPE NCC publicado el 30 de octubre sitúa los fallos intermitentes de actualización entre las 11:42 y las 19:40 UTC del 28 de octubre. La ficha inicial declaró la resolución a las 19:32 UTC.
  • La revisión dice que ninguna solicitud fallida habría cambiado una delegación inversa: no llevaba cambios o no superó las comprobaciones de predelegación de Zonemaster. Las fichas asignan impactos distintos: “major” y “none”.

La historia está repartida en dos fichas de RIPE NCC. La original pasó a vigilancia tras una corrección a las 20:23 CET del 28 de octubre y quedó resuelta a las 20:32 CET, es decir, a las 19:32 UTC. Un registro añadido el 30 de octubre describe fallos intermitentes hasta las 19:40 UTC. La ventana que RIPE da ahora termina ocho minutos después del cierre que publicó ese día.

También empieza mucho antes de que apareciera el aviso. La ficha posterior sitúa el inicio a las 11:42 UTC; la nota pública de investigación se publicó a las 20:04 CET, 19:04 UTC. Entre ambas horas hay siete horas y veintidós minutos. La primera ficha llamó “major” al impacto y dijo que algunos objetos de dominio afectaban al servicio de DNS inverso.

La investigación posterior acota el efecto de las solicitudes fallidas. Ninguna habría cambiado una delegación inversa: unas no incluían cambios; otras no superaron las comprobaciones de predelegación de Zonemaster. La documentación de RIPE Database sobre DNS inverso explica que un objeto domain solicita la delegación y que las comprobaciones de los servidores preceden a su propagación.

Eso es un fallo de escritura, no una modificación perdida del registro de delegaciones. La API de estado conserva “major” para el incidente inicial y “none” para el seguimiento enlazado, sin explicar el cambio. Tampoco publica cuántas solicitudes fallaron ni qué objetos estaban implicados. Ese recuento permitiría saber cuántos operadores pueden cerrar sus registros sin revisar cada envío.

Fuentes