Resumen

  • KSK-2024 empezó a firmar la zona raíz del DNS en la fecha prevista, el 11 de octubre de 2026. ICANN afirma que no había observado indicios de una interrupción operativa generalizada.
  • Ese estado público confirma el cambio de firma en la raíz, no que todos los resolutores hayan adoptado la nueva clave ni que no hubiera fallos locales. KSK-2017 seguirá siendo un ancla de confianza válida hasta las etapas posteriores de revocación y retirada.

Un cambio puede ser exitoso en un sentido y quedar pendiente en otro

La página de ICANN sobre la transición registra un hecho concreto: a las 14:00 UTC del 11 de octubre, KSK-2024 comenzó a firmar la zona raíz. Añade que no se habían observado indicios de interrupción generalizada y que el seguimiento continuaría. IANA también registra la nueva clave como activa y a KSK-2017 como una clave que ya no firma. Son hechos importantes, siempre que se mantenga su alcance exacto.

El cambio de firma de la zona raíz no significa que cada resolutor recursivo validador haya aceptado la clave sucesora. La raíz publica datos DNS firmados; los resolutores recursivos los validan en nombre de sus clientes. Para hacerlo, cada resolutor necesita un ancla de confianza local desde la que construir la cadena. Si no dispone de KSK-2024 cuando debe validar el nuevo estado de firma, DNSSEC puede fallar en ese resolutor. Sus usuarios podrían verse afectados sin que la raíz mundial ni todo el DNS estén caídos.

Conviene separar al menos cuatro capas de evidencia: la publicación y firma de la clave en la raíz; el estado de confianza de cada resolutor; el software y el mecanismo que incorporan la clave; y el resultado de resolución observado por los usuarios. Un registro de una capa no sustituye las pruebas de las demás.

El largo plazo de preparación responde a que los resolutores son independientes

IANA publicó KSK-2024 mucho antes de activarla. La clave apareció en la zona raíz el 11 de enero de 2025; IANA esperaba que los resolutores compatibles con RFC 5011 empezaran a confiar en ella el 10 de febrero. Casi dos años de prepublicación permitieron que los sistemas compatibles la aprendieran mientras la clave anterior aún firmaba la zona. En julio, la guía de ICANN dijo que más del 95% de los resolutores que reportaban la habían reconocido o adoptado. Es una señal amplia de preparación entre quienes reportaban, no un censo de todos ni una tasa de éxito posterior al cambio.

RFC 5011 explica por qué publicar y confiar son estados distintos. Un resolutor automático observa la nueva clave en un conjunto DNSKEY validado, espera un periodo de retención y verifica después que la clave siga presente antes de aceptarla como ancla. La retención mínima es de 30 días, sujeta a la regla del TTL original. Cada resolutor mantiene ese estado local según lo que ve y guarda. Un calendario central puede ofrecer tiempo; no certifica los archivos, la configuración del software ni la validación de toda una flota.

La experiencia de 2018 demuestra el límite. La revisión de ICANN dice que el primer cambio se aplazó después de que datos de última hora indicaran que muchos resolutores de ISP y operadores de red no estaban listos. Tras la transición, los patrones de consultas DNSKEY sugirieron que algunos seguían sin estarlo; aun así, la revisión no encontró cortes importantes y calificó de pequeña la perturbación visible para los usuarios. También señaló que cada operador administra sus resolutores y que el operador de la raíz no podía medirlos ni controlarlos todos.

Por eso la actualización de 2026 habla de ausencia de señales generalizadas, no de éxito universal.

Octubre es el cambio de firma, no el fin del ciclo

La secuencia aún continúa. Según el calendario actual de IANA, KSK-2017 dejó de firmar el 11 de octubre de 2026, pero sigue siendo un ancla válida. Está previsto que publique el bit REVOKE el 11 de enero de 2027 y que se retire de la zona raíz el 22 de marzo. Son transiciones posteriores distintas, con efectos propios en cada resolutor. No se debe presentar el cambio de octubre como la eliminación inmediata de la clave anterior ni como el fin de toda confianza en ella.

Los sistemas siguen distintas vías: actualización automática, paquetes del proveedor, archivos de anclas mantenidos a mano, firmware de equipos o resolutores gestionados. Una organización puede usar varias. Que exista un paquete no demuestra que esté instalado; que la clave figure en la configuración no prueba que la actualización vaya a persistir; y una consulta correcta desde un punto de prueba no representa todos los caminos de clientes. Son estados operativos separados.

ICANN recomienda a quienes operan resolutores validadores comprobar que KSK-2024, etiqueta 38696, esté en su configuración y no dar por hecho que la actualización automática funcionó. IANA identifica el XML firmado de anclas como fuente normativa de parámetros y remite a las instrucciones de cada proveedor. Hay un objetivo claro para comprobar localmente, aunque la evidencia del conjunto de resolutores siga distribuida.

Qué demuestra el registro público

La documentación pública permite decir que la nueva clave comenzó a firmar en la fecha prevista, que ICANN no había observado indicios de interrupción generalizada cuando publicó su estado y que la revocación y retirada de la clave antigua siguen pendientes. No ofrece un inventario por resolutor, un denominador posterior al cambio, un porcentaje global de adopción ni un recuento de usuarios afectados. Tampoco puede deducirse de la ausencia de incidentes publicados que ningún sistema o cliente tuviera problemas.

No hace falta desacreditar la actualización; hay que describirla a la escala correcta. El operador de la raíz informa sobre la firma y las señales que observa. El operador recursivo puede informar sobre su estado local y su validación. El proveedor conoce la distribución de paquetes y actualizaciones. El prestador del servicio ve el impacto en sus propios clientes. Ninguno tiene por sí solo una vista completa.

Después de una transición programada, la pregunta no es solo si se cumplió la fecha. También hay que comprobar si la cadena de evidencia llega a los sistemas dependientes y si las últimas etapas conservan una ruta de recuperación. La respuesta pública de 2026 es favorable, pero acotada: la raíz cambió a tiempo y no se habían observado interrupciones generalizadas. El resto debe verificarse en resolutores y servicios; aún faltan los hitos de enero y marzo de 2027.