Resumen

  • Un commit de Whois del 10 de septiembre cambia NrtmService para que enumere y resuelva fuentes con NrtmSourceSlaveDao, conectado de forma explícita al datasource de lectura.
  • La búsqueda de la última notificación puede repetir su consulta en el primario cuando el resultado del esclavo está vacío, pero esa lógica empieza después de que el servicio haya obtenido el objeto fuente.
  • El código no demuestra despliegue, retraso real ni indisponibilidad. Para el momento excepcional de activar una fuente basta un comprobante de admisión del catálogo.

Los sistemas distribuidos suelen fallar en los sustantivos. Se dice que «la consulta» tiene respaldo, cuando en realidad lo tiene una consulta concreta; se dice que «la fuente» está disponible, cuando una tabla la reconoce y otra parte ya produjo sus archivos. El commit 252681a0865d5a10dbcfeaeeaf81bf33ef2c3855 del RIPE NCC permite separar esos sustantivos.

La modificación fue registrada a las 10:56 UTC del 10 de septiembre de 2026 y se titula «Use read-only (slave) source DAO in NRTMv4 Service». El parche es pequeño: NrtmSourceDao pasa a ser el bean principal, aparece una subclase de veinte líneas llamada NrtmSourceSlaveDao y NrtmService sustituye su dependencia anterior por la nueva. La subclase conserva las mismas consultas pero recibe nrtmSlaveDataSource.

La defensa de la decisión es convincente. El catálogo de fuentes es pequeño y estable; las solicitudes públicas son numerosas. Separar esas lecturas del primario reduce presión sobre el camino de escritura y hace más clara la función de servicio. NRTMv4 añade su propia disciplina: una notificación firmada, hashes de snapshots y deltas, sesiones y versiones. Además, el DAO que recupera la última notificación ya tiene un respaldo del esclavo al maestro.

El hallazgo no invalida nada de eso. Delimita el respaldo.

Primero se admite el nombre

El NrtmSourceDao original consulta la tabla source y devuelve el id y el nombre de sus filas. Su constructor usa nrtmMasterDataSource; el nuevo descendiente inyecta el datasource de lectura. En el servicio, esa lista desempeña dos funciones que no son equivalentes a recuperar el contenido de una notificación.

La ruta raíz genera enlaces. Recorre las fuentes que devuelve getSources() y crea para cada una la URL de su Update Notification File. Si una fila todavía no está en la vista de lectura, no aparece en ese escaparate.

La ruta de archivos hace algo más normativo: decide si el nombre solicitado es válido. En el caso de una notificación, evalúa findLastNotification(getSource(source)). getSource() vuelve a leer la lista, busca la coincidencia exacta y, si no existe, lanza una petición incorrecta con «Invalid source».

El orden de evaluación de Java resuelve la duda. Antes de entrar en findLastNotification, debe terminar getSource. Una ausencia en el catálogo de lectura detiene la solicitud sin dar turno al componente que conoce el primario.

Ese componente, UpdateNotificationFileSourceAwareDao, está diseñado con cautela. Primero ejecuta su consulta de payload. Si no obtiene nada y el contexto es SLAVE, construye la fuente maestra correspondiente, cambia temporalmente el contexto, repite la consulta y restaura el original incluso si hay una excepción. Es un respaldo para una notificación que aún no aparece por el primer camino después de que la fuente ya ha sido reconocida.

No es un respaldo para reconocer la fuente. Presentarlo como tal exigiría saltarse el orden real del programa. La lista raíz tampoco dispone de ese segundo intento.

Una ventana de alta, no una acusación sobre el servicio

En régimen normal, las filas de las fuentes configuradas pueden llevar mucho tiempo en ambas bases. Si la réplica ya las contiene, la nueva lectura devuelve lo esperado y la recuperación de notificaciones sigue protegida. No hay en el material capturado una métrica de replicación, un error observado ni un consumidor afectado.

La hipótesis operativa se limita a una transición: crear una fuente, reconstruir una fila, recuperar un datasource, cambiar una configuración o volver a sincronizar. Durante ese proceso, la escritura principal podría haber aceptado el nombre antes de que el servicio lo vea en lectura. Si sucede, el índice raíz no lo enseñaría y la ruta directa lo consideraría inválido antes de consultar la notificación en el primario.

El condicional es importante. La consecuencia está en el código; la premisa no está probada. Tampoco lo está el despliegue del commit. Una rama pública no identifica por sí sola una versión productiva. No cabe hablar de una caída, datos antiguos, pérdida de registros o vulnerabilidad de seguridad.

Las réplicas ofrecen aislamiento y capacidad a cambio de una posible diferencia temporal. El objetivo no es expulsarlas, sino reconocer que unas decisiones soportan mejor esa diferencia que otras. Servir repetidamente un conjunto asentado no plantea la misma exigencia que declarar público un nombre nuevo.

NRTMv4 protege el objeto que sí llega al cliente

La revisión 11 del borrador draft-ietf-grow-nrtm-v4, vigente en el Datatracker durante la captura, define la sincronización unidireccional de registros IRR sobre HTTPS. El servidor publica un Update Notification File, un Snapshot File activo y cero o más Delta Files.

La notificación utiliza JSON Web Signature. El cliente conoce la URL, el nombre de la base IRR y la clave pública. Debe comprobar que la fuente declarada coincide, validar la firma y comparar los hashes SHA-256 de snapshot y deltas. El session_id delimita la secuencia de versiones. Cuando cambia, el cliente vuelve al snapshot actual para no construir continuidad sobre un historial que quizá ya no existe.

Son controles sustantivos. Responden quién firmó la notificación, si cada archivo conserva su contenido y si la secuencia pertenece a la misma sesión. No pueden certificar que la fila interna usada para admitir el nombre haya llegado a la réplica antes de abrir el servicio. Si la puerta rechaza el nombre, el cliente nunca recibe la notificación cuya firma sabe examinar.

No se desprende de ello que el protocolo deba anunciar la topología de almacenamiento. La posición de replicación, los hosts y los ids internos no son datos para un espejo público. La garantía ausente pertenece al alta operativa del productor.

Un comprobante para el instante de activación

El control proporcionado es un comprobante de admisión del catálogo. Puede ser privado. Su misión es enlazar la creación de una fuente con la primera evidencia de que el camino de servicio está listo para aceptarla.

Debería incluir el nombre de la fuente, la generación de configuración o despliegue, la aprobación en el lado de escritura, el datasource previsto para servir y una marca de que ese datasource ya observa la entrada. Después agregaría la primera recuperación y validación de una notificación firmada por el camino real, el session_id y la versión vistos, la referencia de la clave, una prueba del índice raíz y otra de la URL directa. Responsable, hora de activación, criterio de reversión y relación con el comprobante que lo sustituya cerrarían el expediente.

No hace falta publicar nombres de bases, offsets, ids ni credenciales. La afirmación controlable es que una generación concreta fue visible en el lado de servicio antes de que la fuente cambiara a estado activo.

El procedimiento puede automatizarse: aprobar en escritura, esperar la observación en lectura, validar el primer artefacto firmado desde el camino de servicio y sólo entonces anunciar. Si el hito no llega a tiempo, se retiene el alta o se habilita un camino temporal, acotado y revocable.

También conviene probar por separado los dos huecos. Un test prepara la fuente en el primario y la oculta en la réplica para verificar la política de admisión. Otro hace visible la fuente y deja ausente el payload de notificación para ejercitar el respaldo ya existente. Una única prueba de «retraso de réplica» podría pasar sin tocar el umbral que importa.

La ventaja del comprobante es económica además de probatoria. No obliga a que millones de futuras lecturas paguen por una transición infrecuente. Sitúa el control precisamente donde cambia el conjunto de nombres admisibles.

Fuentes