Resumen

  • El archivo histórico rpkic_run.sh selecciona rpkic_rpkiv5_cache en ambas acciones, pero lo monta primero en /var/cache/rpki-client y después en /root/cache.
  • Docker distingue el volumen de su destino dentro del contenedor. Conservar el primero no demuestra que la aplicación utilice el segundo como caché.
  • Las dos acciones mantienen la misma cadena de imagen, los argumentos comunes y el montaje de las anclas de confianza. Los otros tres lanzadores revisados mantienen sus destinos respectivos.
  • La revisión observa en septiembre de 2026 un commit del 1 de abril de 2024. No ejecuta una prueba ni acredita una pérdida de datos, un fallo operativo o una nueva migración.

La variable que se esconde detrás del nombre

La promesa del experimento no consiste en arrancar dos contenedores cualquiera. El README del repositorio de LACNIC pide iniciar una parte confiante contra el servicio actual, esperar a que complete una primera ejecución y llene su caché, detenerla y volver a ejecutarla contra el servicio de sustitución. El estado previo tiene un papel explícito: debe acompañar a la aplicación durante la comparación.

La parte confiante es el software que procesa material RPKI y obtiene información de encaminamiento validada. Probarla con un estado ya adquirido permite estudiar una situación diferente de la de una instalación que descubre todo desde cero. Una prueba en frío no es por ello una mala prueba. El problema empieza cuando se la presenta, sin comprobarlo, como la secuencia con continuidad de caché que propone el documento.

En el lanzador de rpki-client, el nombre del volumen no cambia. Las acciones current y rpkiv5 utilizan rpkic_rpkiv5_cache. Lo que cambia es la parte derecha del montaje: /var/cache/rpki-client en la primera y /root/cache en la segunda. El mismo almacenamiento del anfitrión se expone en otra dirección dentro del contenedor. Esa diferencia permite preguntar por el control del experimento. No permite concluir que el contenido haya desaparecido.

La documentación oficial de Docker explica la separación entre origen y destino. Un volumen con nombre puede sobrevivir al contenedor que lo utilizó y reutilizarse en otro. Su destino indica el directorio donde será visible dentro de ese contenedor. El nombre identifica qué almacenamiento se selecciona; no establece por sí solo qué directorio consultará el programa. El acceso efectivo es una relación adicional que debe demostrarse.

El lanzador tampoco basta para demostrar lo contrario. La imagen podría contener una configuración, un alias de directorios o un punto de entrada que hiciera útiles ambas rutas. No se ha inspeccionado esa imagen ni se ha verificado el lugar que utiliza como caché. Por tanto, siguen abiertas tanto la posibilidad de continuidad como la de un estado inicial diferente. Convertir una ruta distinta en una pérdida observada sería tan apresurado como convertir un nombre estable en continuidad certificada.

El cambio de servicio no es el único dato de una comparación

El README describe una sustitución de resolución de nombres para dirigir la segunda acción al nuevo servicio RRDP, la superficie de recuperación de repositorios nombrada en los scripts. Después propone comparar manualmente las salidas, por ejemplo el número de cargas útiles validadas de origen de ruta, o VRP. La secuencia resulta comprensible: mantener el estado de la parte confiante mientras cambia el servicio que consulta.

Eso es una intención de diseño, no un resultado ejecutado. En los materiales examinados no aparece una constancia de ejecución emparejada que establezca dónde leyó realmente la aplicación, qué contenido estaba disponible antes de la segunda acción y cómo se obtuvo la salida. La revisión no afirma que nadie realizara pruebas internas. Delimita lo que este paquete público permite sostener sin inventar el historial operativo.

El tamaño de una salida es una observación razonable, pero responde a una pregunta limitada. Dos conjuntos pueden tener el mismo número de elementos y contener elementos distintos. No se ha observado aquí una diferencia de ese tipo. El punto es lógico: un total igual no demuestra identidad de conjuntos, y tampoco demuestra de dónde se obtuvo cada elemento. Si la afirmación es continuidad de un estado previamente validado, hay que vincular el resultado con ese estado.

Una comparación que no establezca la caché inicial puede mezclar el efecto del servicio nuevo con el de una aplicación que comienza desde otras condiciones. Eso no convierte el resultado en inútil. Lo hace menos específico. Podría servir como ensayo de descubrimiento en frío y no como ensayo con caché poblada. La disciplina necesaria es nombrar la situación que realmente se ha probado, en lugar de trasladarle la intención escrita en el README.

Hay controles positivos en el propio archivo

El script de rpki-client no abandona todos los controles. Selecciona rpki/rpki-client:8.2 en ambas acciones. Mantiene el enlace del directorio local de anclas de confianza a /etc/tals, la cadena compartida -s 480 -c -v -v -v y las opciones comunes de ejecución separada y DNS personalizado. Las imágenes alternativas que se ven en el archivo están comentadas; no son versiones que esas acciones ejecuten.

También conserva el origen del volumen. Esa continuidad es evidencia positiva y debe acompañar la crítica. La observación concreta no es que el almacenamiento se haya sustituido o eliminado, sino que se ha cambiado su destino. Si se demuestra que la imagen accede al volumen en ambas ubicaciones de manera equivalente, la preocupación por la continuidad del acceso se reduce. La solución documental podría ser pequeña porque la pregunta también lo es.

La cadena de imagen no equivale a una identidad de imagen inspeccionada. No se ha descargado una imagen, confirmado su resumen criptográfico, revisado su punto de entrada ni comprobado enlaces simbólicos o permisos. Tampoco se asigna un significado de versión a los argumentos sin pruebas adicionales. Se constata que las mismas cadenas aparecen a ambos lados. Esa distinción evita que una lectura de código se presente como auditoría del contenedor.

La acción de sustitución añade una asociación del nombre RRDP a 96.126.99.186. Es un dato histórico del experimento, no una dirección contactada durante esta investigación. Cambiar el servicio tiene sentido dentro de una migración. Cambiar además dónde se expone el volumen plantea otra condición que debe explicarse. Si ambas rutas terminan en el mismo lugar efectivo para el programa, no hay por qué atribuirle un arranque sin caché.

Tres lanzadores que no mueven ese destino

El contexto inmediato impide generalizar. El lanzador de FORT mantiene /root/cache en sus dos acciones, aunque añade asociaciones de nombres RRDP y de repositorio para la sustitución. El lanzador más reciente de Routinator mantiene /home/routinator/.rpki-cache; la variante anterior a 0.12 mantiene ese destino en su propio par y selecciona la cadena de imagen v0.10.1.

No son pruebas de que esas aplicaciones reutilizaran datos correctamente. Son comparaciones de instrucciones publicadas. Aun así, muestran que cambiar el destino del volumen no es una exigencia general del enfoque del repositorio. La discrepancia observada pertenece al par de rpki-client. No acredita una deficiencia de todos los validadores, de la infraestructura de producción de LACNIC o de los operadores que pudieran haber consultado el material.

Hay otros parámetros visibles que conviene conservar como secundarios. El lanzador reciente de Routinator utiliza en la acción actual unos argumentos de servidor con --refresh=120; en la acción nueva escribe otra cadena sin esa opción explícita. No se ha establecido el valor efectivo por defecto. El archivo dnsmasq incluye asociaciones de direcciones de sustitución y otras antiguas comentadas, pero no demuestra qué servicio DNS funcionaba realmente durante una prueba.

El README contempla editar la opción DNS cuando ese servicio no se utiliza. Eso añade una razón para registrar el entorno real y no deducirlo únicamente de los archivos. Esta revisión no afirma que la referencia estuviera ya dirigida al servicio nuevo ni que hubiese un intervalo de actualización anómalo. Esas historias requieren observaciones que no se han obtenido y distraerían de la diferencia de montaje que sí está documentada.

Una fecha también limita la conclusión

La lectura corresponde al commit fdbecab2890e0da2f9a393ac4be2659d14f54ca2, del 1 de abril de 2024, consultado el 14 de septiembre de 2026. No anuncia una migración actual ni determina cómo se ejecutó la anterior. La advertencia del README sobre una autoridad de certificación hija aún no replicada pertenece a esa descripción histórica. No debe reciclarse como acusación de una ausencia presente.

Docker explica además que un montaje puede ocultar el contenido que ya existía en el directorio de la imagen y que un volumen inicialmente vacío puede recibir contenido previo según el comportamiento de copia por defecto. Son reglas de la plataforma, no observaciones de esta aplicación. Importan porque distinguen el contenido de la imagen, el contenido del volumen y la ubicación donde ambos se exponen.

Fuentes

La base documental reúne el README histórico, el lanzador de rpki-client, el de FORT, el de Routinator reciente, la variante antigua, la configuración DNS y la documentación de Docker. Son siete documentos en dos sitios de publicación, no siete investigaciones independientes. No se ha ejecutado ningún comando de contenedor o validador.