Resumen

  • RIPE NCC dice que una breve interrupción de red hizo conmutar el balanceador principal el 28 de octubre. Una configuración errónea llevó las conexiones nuevas de actualización Whois a una base de solo lectura; las conexiones existentes siguieron en la base principal.
  • El intervalo de fallos publicado abarca las 11:42–19:40 UTC. RIPE NCC revisó las solicitudes fallidas de delegación inversa y concluyó que ninguna habría cambiado una delegación: no contenían cambios o fallaban las comprobaciones previas de zonemaster.

El balanceador cambió; el destino también

El informe posterior de RIPE NCC, publicado el 3 de noviembre, describe una cadena corta y contundente. Una interrupción breve afectó al enlace de red del balanceador principal. El sistema pasó al de reserva. Su configuración enviaba las nuevas conexiones de actualización Whois a una base de datos de solo lectura en lugar de a la primaria. Las sesiones de aplicación ya abiertas conservaban la conexión con la primaria y no sufrieron ese desvío.

Ahí está la intermitencia. No hacía falta que la base principal fallara y se recuperara a cada instante. El mismo servicio podía aceptar una operación por una conexión vieja y rechazar otra por una conexión nueva. Para el operador que solo ve su intento, el comportamiento parece caprichoso. Para quien conoce el trayecto de las conexiones, es una separación determinista entre dos caminos.

RIPE NCC sitúa los fallos de actualización del 28 de octubre entre 11:42 y 19:40 UTC. En el aviso original habló de actualizaciones no procesadas y de objetos con efecto sobre DNS inverso. La explicación de la ruta equivocada llegó en el informe posterior. No se publicó el ajuste concreto mal configurado ni cuántas conexiones nuevas o actualizaciones fallaron. Un registro de rutas y resultados por método de envío permitiría medirlo.

La revisión del DNS inverso acota el impacto conocido. RIPE NCC afirma que ninguna de las solicitudes fallidas de delegación inversa habría modificado la delegación. Algunas no proponían cambios; otras fallaban las pruebas previas de zonemaster. El error de encaminamiento de escrituras fue real, pero esas solicitudes no establecen una delegación válida perdida.

Una respuesta HTTP no es el acta del objeto

Según la guía de procesamiento de RIPE, cada objeto se procesa por separado y el remitente recibe una confirmación con el resultado. La guía de confirmaciones recuerda que Syncupdates puede devolver HTTP 200 aunque una operación concreta haya fallado. El resumen de éxitos y errores, seguido de la lectura del objeto, importa más que el estado verde del balanceador. El postmortem permite identificar la falla de ruta; el registro público no asigna resultados a usuarios o métodos concretos.