Resumen

  • Una rotación DNSSEC recorre varios estados de clave; no cabe en la hora de una ceremonia.
  • La propagación autoritativa, el vencimiento de cachés, el DS padre y la espera de anclas avanzan con relojes distintos.
  • El material anterior sigue siendo necesario mientras alguna combinación de validación pueda depender de él.
  • Un expediente operativo debe gobernar la activación, el retiro y la eliminación.

Imaginemos una ceremonia programada que termina sin alertas. La nueva DNSKEY está publicada, el firmante produce firmas válidas y el panel marca éxito. A la hora prevista se elimina la clave anterior. Poco después, un grupo de clientes que usa resolvers validadores empieza a recibir SERVFAIL, aunque las sondas cercanas a los servidores autoritativos siguen funcionando.

La criptografía no cambió. El modelo operativo confundió varios relojes con el de la ceremonia.

RFC 7583 presenta la rotación como una secuencia temporal de estados: generada, publicada, preparada, activa, retirada, muerta y eliminada. Una clave puede ser visible sin estar preparada, estar activa sin ser utilizable por todos los resolvers o estar retirada mientras datos almacenados aún dependen de ella. La seguridad exige mantener al menos una ruta válida a través de las combinaciones cambiantes de DNSKEY, RRSIG y, en una KSK, DS.

El primer reloj es la propagación autoritativa. Publicar una clave en el primario no la instala de inmediato en todos los servidores. RFC 7583 incluye la demora de propagación en el intervalo previo al estado preparado. RFC 6781 aplica la misma disciplina al método de prepublicación de una ZSK: introducir la nueva DNSKEY, dejar que llegue al conjunto autoritativo y mantenerla durante el TTL de DNSKEY antes de usarla para firmar datos de producción.

El segundo reloj pertenece a las cachés. Un validador puede conservar un conjunto DNSKEY antiguo mientras obtiene una RRSIG nueva, o retener una firma antigua mientras actualiza las claves. El método debe mantener compatibles esas combinaciones. En la prepublicación, la clave nueva espera antes de usarse y la anterior permanece después del cambio de firmas. En la firma doble, ambas generaciones se solapan, con respuestas más grandes a cambio de una ventana sencilla.

El tercer reloj es la delegación padre. La rotación de una ZSK puede permanecer dentro de la zona. La de una KSK normalmente une la DNSKEY hija con un DS publicado por el padre. El hijo puede enviar un DS, pero el envío no equivale a su publicación en DNS. Debe observar el nuevo DS, considerar el TTL del anterior y conservar la ruta previa hasta que la sucesora sea utilizable.

El cuarto reloj afecta a los resolvers que mantienen anclas configuradas mediante RFC 5011. Una clave SEP nueva entra en espera. El resolver debe completar el periodo de espera y después recuperar y validar otro conjunto DNSKEY que aún contenga la clave. El periodo de incorporación es de treinta días o la expiración del TTL original, lo que sea mayor. Para la retirada, un ancla solo llega al estado Removed tras las observaciones de revocación o ausencia previstas; después, su estado se conserva treinta días antes de limpiar el registro interno. Esa retención corresponde al estado del ancla en el resolver y no es un plazo genérico que autorice borrar una DNSKEY de la zona. Ese reloj vive dentro del validador y queda fuera del control directo de la zona.

No son cuatro versiones del mismo contador. Cada reloj comienza con un hecho observado distinto, pertenece a un componente distinto y acredita una transición distinta. “Clave publicada” no autoriza su activación. Una firma válida desde una sonda no autoriza eliminar la predecesora. Un recibo del portal del padre no prueba el vencimiento de las cachés. El mero paso de treinta días no prueba la observación posterior exigida por RFC 5011.

El objeto de evidencia útil es un expediente operativo de la rotación. Identifica zona, método, etiquetas de clave y algoritmos; registra cuándo cada clave pasa por sus estados; conserva observaciones DNSKEY, RRSIG y DS desde puntos nombrados; documenta TTL, límites de propagación y validez de firmas; y separa envío, visibilidad en los servidores autoritativos y vencimiento de caché.

Para poblaciones RFC 5011, el registro añade el punto de confianza, la primera observación validada, el final de la espera y la observación posterior que completa la aceptación. Para todas, conserva resultados de validación por grupos representativos de resolvers. También nombra quién puede autorizar cada transición y qué evidencia activa una reversión.

Así cambia la declaración de cierre. “La ceremonia se ejecutó” describe acciones de gestión. “La clave nueva está activa” describe un estado compatible con el método elegido. “La clave anterior puede eliminarse” afirma que ninguna caché o ancla aplicable sigue necesitándola. Pueden ocurrir en fechas próximas, pero son afirmaciones diferentes.

Fuentes

RFC 7583 — tiempos de rotación de claves DNSSEC; RFC 6781 — prácticas operativas DNSSEC; RFC 5011 — actualización automatizada de anclas DNSSEC.