Resumen

  • El plan del tercer trimestre dice que la renovación sigue en curso y que Amsterdam ya fue renovado, pero la página está fechada el 11 de junio y no revela la situación actual de Londres o Tokio.
  • La disponibilidad global demuestra que la redundancia de K-root funciona; no basta para aceptar un cambio local. Cada centro necesita una constancia limitada, segura y corregible.

La fracción que falta detrás de «en curso»

El plan trimestral de DNS y K-root explica que los equipos de los centros principales de Amsterdam, Londres y Tokio alcanzaron el final de su vida útil tras siete años de operación. El estado del trabajo es «en curso» y una nota añade que Amsterdam fue renovado.

La lectura aritmética sería 1 de 3. La lectura operativa necesita más estados. Un centro puede haber terminado la sustitución y seguir bajo observación. Puede haber recuperado IPv4 y no IPv6. Puede haber restaurado el anuncio sin cerrar una excepción. También puede haberse revertido una parte. Nada de esto se atribuye a los tres centros: son las posibilidades que desaparecen cuando una fila resume tres límites de cambio.

El Plan de Actividades y Presupuesto 2026 fijó el compromiso de renovar los equipos principales de K-root antes de julio de 2026. Sin embargo, la página trimestral indica que su última actualización fue el 11 de junio. No es válido usar esa página para declarar un incumplimiento posterior, ni para suponer que el silencio equivale a ejecución. El reloj documental y el reloj material son cosas distintas.

También importa la topología pública. La política de interconexión de K-root enumera cinco centros principales: Amsterdam, Fráncfort, Londres, Miami y Tokio. El programa se refiere a tres, no a todos. Amsterdam se asocia con AMS-IX y NL-IX; Londres con LINX y LONAP; Tokio con JPNAP y DIX-IE. Cada lugar tiene, por tanto, una frontera pública de enrutamiento propia, aunque el detalle interno deba seguir protegido.

La señal verde global no es una recepción local

La página del servicio K-root describe nodos distribuidos mediante anycast IPv4 e IPv6, con prefijos anunciados desde AS25152 y servidores que ejecutan BIND, Knot o NSD. La misma dirección de servicio puede conducir a centros distintos según el punto y el momento de observación.

En RIPE-859, el RIPE NCC afirma que puede retirar centros o componentes para mantenimiento sin que K-root quede indisponible como conjunto. RSSAC001v2 espera precisamente que el mantenimiento de un elemento no derribe todo el servicio.

Por eso una consulta correcta puede ser un testigo incompleto. Puede haber llegado a otro centro. Un gráfico estable puede probar que la carga se redistribuyó, no que el equipo nuevo del lugar previsto superó sus pruebas. Confundir las dos conclusiones penalizaría el éxito de la arquitectura: se exigiría a la redundancia que hiciera visible el cambio que fue diseñada para absorber.

El registro actual de K-root clasifica Amsterdam, Londres y Tokio como sitios globales operativos con tres instancias cada uno. Es una referencia útil para la identidad de los centros. No es una lista de materiales. Sus marcas de actualización son anteriores al programa 2026 y no codifican una decisión de aceptación. «Operativo» no puede convertirse en «renovación aceptada».

Una constancia pequeña y suficiente

El acta propuesta no debe exponer números de serie, disposición de bastidores, umbrales de capacidad ni métodos sensibles. Debe probar el contorno de la decisión.

Primero, identidad y alcance: código público estable del sitio y clases de componente afectadas—enrutador, servidor DNS, borde de conectividad o ruta de supervisión—junto con una referencia no sensible a la generación anterior y la nueva. Eso permite saber qué significa la palabra «renovado» cuando se consulte años después.

Segundo, tiempo: ventana aprobada, inicio y fin reales, y cierre del período de observación. La restauración del anuncio anycast no tiene por qué coincidir con la aceptación. Para IPv4 e IPv6 se deben mantener por separado retirada, regreso, visibilidad externa y excepción.

Tercero, pruebas tipadas. Alcanzar el sitio, recibir una respuesta DNS, comprobar que la respuesta es correcta, confirmar la actualidad de la zona raíz y observar una distribución razonable de tráfico son verificaciones diferentes. Cada una necesita método, versión, intervalo y resultado. La lista puede ser pública sin revelar los parámetros que ayudarían a atacar el sistema.

Cuarto, salidas reversibles: aceptado, aceptado con excepción, restaurado bajo observación o revertido. Un responsable, un revisor, una fecha y un historial de correcciones convierten mediciones sueltas en una decisión institucional. El indicador del programa se deriva después de las tres actas; nunca las sustituye.

Atlas y RSSAC002 ayudan, pero no firman

RIPE-859 menciona vigilancia continua y observaciones distribuidas desde más de diez mil puntos de RIPE Atlas. Además, existe un archivo público RSSAC002 que llega a 2026.

La especificación RSSAC002v5 normaliza archivos diarios sobre tiempo de carga de zona, volumen de tráfico, tamaños y códigos de respuesta y, opcionalmente, fuentes únicas. Estos datos pueden detectar discontinuidades y acotar un antes y un después. No guardan necesariamente la generación del equipo, la causa del cambio, la decisión de reversión ni la firma de aceptación.

La respuesta adecuada es enlazar, no duplicar. El acta debería referenciar el conjunto exacto de mediciones y explicar qué demuestra cada una. Una muestra Atlas corrobora una experiencia desde determinados puntos y rutas; no inspecciona el interior del centro. Una serie de tráfico muestra cantidades; no atribuye por sí sola una variación. Una comprobación de zona cubre actualidad; no certifica el retorno de las dos familias de direcciones.

Seguridad no significa opacidad total

La defensa del RIPE NCC merece prioridad. La información minuciosa sobre equipos puede convertirse con el tiempo en un mapa de vulnerabilidades. Los umbrales y las condiciones de conmutación pueden ser sensibles. Algunas pruebas pierden valor si su diseño es conocido. Y la ausencia de una prueba pública no demuestra que no exista una prueba interna.

RIPE-859 añade controles sustantivos: al menos dos y normalmente tres bases de código DNS, dos implementaciones de routers BGP por software y dos implementaciones de routers físicos. Esa diversidad obliga a describir la aceptación por clases sin simplificarla a un único modelo de caja.

El plan de expansión de K-root de 2015 relataba, para nodos alojados, una secuencia prudente: dejar de anunciar el prefijo de un lugar que afectara negativamente al servicio, desviar el tráfico y reactivar el anuncio después de resolver y verificar el problema. No es evidencia del procedimiento de los centros principales en 2026. Sí demuestra que retirar, probar y reanunciar son resultados publicables sin entregar la arquitectura interna.

Los planes trimestrales archivados cuentan otra renovación tras siete años: los firmantes DNSSEC conservaron la plataforma elegida, cambiaron el hardware y el proyecto quedó marcado como completado en el tercer trimestre de 2025. Ese antecedente no prueba nada sobre K-root. Muestra que el RIPE NCC puede distinguir «en curso» de «completado»; el avance siguiente es hacer que el segundo estado nazca de decisiones por sitio.

Tres actas preservarían una memoria comparable para el próximo ciclo. Permitirían revisar cuánto duró cada retirada, qué familias regresaron, qué clase de evidencia se usó, qué excepción quedó abierta y cuándo terminó la observación. La disponibilidad protege al público en el momento del cambio. La trazabilidad protege el aprendizaje cuando el cambio ya no puede repetirse.