Resumen

  • El informe de octubre de APNIC combina una lectura de julio de las señales de resolutores RFC 8145 con nuevas pruebas RFC 8509 en sistemas finales. Los porcentajes aproximados de 90 % y 70 % corresponden a vías de observación distintas y no se pueden restar ni promediar.
  • La tabla de redes sirve para orientar comprobaciones, no para calificar a un proveedor ni estimar cuántos clientes están expuestos. Cada operador debe probar sus propios resolutores validadores.

Análisis

Todo porcentaje necesita una vía de observación

Dos días antes de un cambio programado de la clave DNSSEC de la raíz, un porcentaje de preparación parece responder a la pregunta decisiva. Si la mayoría de los resolutores ya tiene la clave sucesora, el cambio debería salir bien; si no, alguien debería detenerlo. El problema está en “la mayoría”. Una señal de un resolutor, una prueba enviada desde la red de un usuario y las personas que dependen de esa red no son unidades intercambiables.

El informe de APNIC del 9 de octubre, redactado el día 8, presenta dos observaciones sobre KSK-2024. La primera utiliza RFC 8145: los resolutores validadores pueden señalar los identificadores de las claves que aceptan mediante consultas visibles para los operadores de servidores autoritativos. La segunda emplea el Root Key Trust Anchor Sentinel de RFC 8509. La prueba viaja desde un sistema final y su respuesta permite inferir el estado de confianza del resolutor. La clave y la fecha son las mismas; lo que se mide, no.

La explicación de RFC 8145 contiene un matiz relevante. APNIC describe su gráfico de julio como indicativo de que cerca del 90 % de los resolutores que emiten señales había añadido KSK-2024. La actualización de Verisign del 28 de julio dice que la adopción entre las fuentes que señalizan superó el 95 % tras unos 500 días. APNIC atribuye el gráfico a Verisign, pero las publicaciones no ofrecen una fecha de extracción y una definición comunes que permitan al lector conciliar ambas cifras. Podrían referirse a cortes o resúmenes diferentes; el texto disponible no lo aclara.

Es una laguna documental que conviene conservar, no una prueba de que una medición fallara.

El 70 % reciente está aún más lejos de una comparación directa. APNIC indica que su plataforma de medición basada en publicidad realizaba unos 16 millones de pruebas de sistemas finales al día. Cerca de 6 millones mostraban que el sistema estaba detrás de un resolutor recursivo que validaba DNSSEC, y alrededor de 1,8 millones daban una señal clara de compatibilidad con RFC 8509. De las pruebas que parecían admitir el mecanismo, cerca del 70 % informó que KSK-2024 estaba cargada. El denominador es ese subconjunto probado con señal clara, no los 16 millones de pruebas, todos los resolutores validadores ni todos los usuarios de Internet.

Dos mecanismos, dos preguntas

RFC 8145 permite que un resolutor validador indique los identificadores de las claves presentes en su cadena de confianza. Define dos métodos opcionales: una opción EDNS o una consulta especial. En el caso de la raíz, los operadores de infraestructura autoritativa pueden observar esas señales. Los datos muestran cómo cambia el estado declarado entre las fuentes que las envían.

Eso no revela cuántos hogares, empresas o servicios dependen de cada resolutor. Algunos resolutores recursivos atienden a millones de usuarios; otros, a una sola organización o equipo. La existencia de reenviadores también puede alterar lo que ve el operador de la raíz. Por tanto, el porcentaje de señales enviadas responde a una pregunta sobre esas señales, no sobre la exposición de los usuarios.

RFC 8509 toma otra ruta. La prueba envía consultas DNS formadas especialmente; un resolutor validador compatible responde de acuerdo con si confía o no en una clave raíz concreta. APNIC utiliza una plataforma publicitaria para enviar las pruebas desde distintos sistemas finales. La observación se acerca más a la ruta de resolución de un sistema probado, pero sigue dependiendo de que su resolutor admita el mecanismo y de que la respuesta pueda clasificarse. No identifica todos los resolutores detrás de ese sistema ni cuenta a todos los usuarios que comparten uno.

La prueba RIPE Atlas del 5 de octubre aporta otra perspectiva, no una comprobación universal. Las sondas en 2.900 sistemas autónomos produjeron 1.230 comportamientos compatibles con la carga de la nueva clave y 47 compatibles con que no se hubiera cargado. Son resultados de sondas dentro de esas redes. No significan que se examinaran todos los sistemas de esos 2.900 AS ni que se conozca el número de clientes que depende de cada resultado.

Estas mediciones parciales siguen siendo útiles si se mantiene claro qué pregunta responde cada una. RFC 8145 muestra lo que comunican los resolutores que envían señales hacia la raíz; RFC 8509 prueba la conducta de rutas compatibles detrás de sistemas finales; RIPE Atlas aporta puntos de observación situados de otra manera. Ninguna ofrece por sí sola un denominador completo y ponderado por usuarios para todo Internet.

Una lista de seguimiento no es un veredicto

La parte más práctica del informe de APNIC no es el porcentaje general. La Tabla 3 presenta las 50 redes con menor tasa observada de aceptación de KSK-2024 durante la semana anterior, tras filtrar las que tenían menos de 1.000 pruebas indicativas de que sus resolutores admitían el mecanismo centinela. El filtro hace que las filas sean más útiles que una observación aislada, pero no las convierte en auditorías de preparación.

La tabla incluye redes de Asia-Pacífico, como National Telecom, en Tailandia, y Teletalk, en Bangladesh. APNIC comunica un 48,4 % para National Telecom en 1.355 pruebas compatibles con el centinela y un 48,2 % para Teletalk en 2.046. Estas cifras señalan cohortes donde merece la pena comprobar más. No prueban que todos los resolutores de esos operadores tengan el mismo estado, que cada respuesta represente a una persona distinta ni que la misma proporción de clientes vaya a perder acceso.

APNIC sugiere que las redes incluidas prueben su propia ruta de resolución, incluso con la página de comprobación operada por Cloudflare, y revisen sus ajustes DNS. Ese es el uso adecuado de la tabla: una pista para el operador, no un dictamen externo. Un proveedor puede gestionar varios servicios recursivos, reenviar parte del tráfico o depender de claves distribuidas por un fabricante. La tabla pública no permite resolver esos detalles.

El calendario contiene tres cambios distintos

El calendario actual de IANA indica que KSK-2024 entró en la zona raíz el 11 de enero de 2025; se esperaba que los resolutores que siguen RFC 5011 empezaran a confiar en ella un mes después. El 11 de octubre de 2026, KSK-2024 tiene previsto empezar a firmar la raíz y KSK-2017 dejar de hacerlo. La revocación de la antigua clave se programa para el 11 de enero de 2027 y su retirada para el 22 de marzo.

Son estados diferentes. “La nueva clave firma” no significa “la antigua ya está revocada”, y la revocación no significa que ya se haya retirado de la zona. El período de espera de RFC 5011 permite que un resolutor observe y valide una clave sucesora antes de aceptarla automáticamente. Pero que exista un mecanismo automático no demuestra que una instalación concreta lo tenga activado, conserve un estado escribible o haya recibido las observaciones necesarias.

También hay que separar las funciones. IANA publica las anclas de confianza y el calendario; ICANN/PTI opera el proceso KSK; Verisign se ocupa, entre otras funciones, del mantenimiento de la zona raíz y de un punto de observación en los servidores raíz; APNIC informa sobre sus mediciones. Cada operador de red sigue siendo responsable de los resolutores recursivos que usan sus clientes. APNIC aporta evidencia, pero no controla la clave raíz ni decide si continúa la transición mundial.

Para un operador, la comprobación inmediata es local: verificar que el resolutor desplegado confía en la clave sucesora correcta, confirmar que la actualización automática o la vía manual aprobada funciona y probar las rutas DNS usadas en producción. IANA publica los archivos de anclas; los fabricantes documentan sus propios procedimientos. Una medición pública puede señalar dónde mirar, pero no puede efectuar esa comprobación por una organización.

La evidencia disponible el 9 de octubre permite una conclusión acotada. La clave sucesora lleva publicada más de un año, una proporción grande de las señales y rutas medidas la informa, y APNIC ha señalado redes donde convendría hacer seguimiento. Las descripciones de 90 %, más de 95 % y 70 % no forman una sola puntuación de preparación. El 11 de octubre, la pregunta operativa será si una ruta validadora concreta acepta la nueva raíz firmada, no cuál de esos porcentajes ocupa el titular.

Fuentes

informe de medición de APNIC del 9 de octubre; calendario de anclas y cambios de IANA; RFC 8145; RFC 8509; RFC 5011; actualización de Verisign del 28 de julio; FAQ operativa de ICANN 2026; prueba de resolutores de Cloudflare.