Resumen

  • draft-ietf-dnsop-dnssec-keyrestore-02 estudia una avería concreta: una clave privada queda inoperable y no hay copia útil, aunque todavía existe una zona prefirmada completa con firmas válidas.
  • La salida segura combina el vencimiento de RRSIG, la propagación de DNSKEY, la publicación del DS por el padre, la carga de secundarios y la retirada tras los TTL. Esos relojes pertenecen a actores distintos.
  • Conviene conservar un recibo de tiempos de recuperación que asigne decisión y evidencia a cada transición. Es una recomendación de Daniel Kade, no una obligación de la IETF.

Que un dominio responda no demuestra que pueda cambiar. Tras perder una clave de firma, el operador puede seguir sirviendo exactamente los datos antiguos y sus RRSIG. El fallo permanece oculto hasta que haga falta modificar un RRset o se acerque la fecha de expiración. La continuidad presente y la capacidad de producir el siguiente estado son dos propiedades diferentes.

La revisión 02 de DNSSEC Key Restore apareció el 10 de agosto de 2026. Es un Internet-Draft activo del grupo DNSOP y el documento renderizado señala una intención Informational. Sigue siendo trabajo en curso: no es RFC, BCP ni norma definitiva. Tampoco prueba que RIPE NCC, afiliación de los autores, haya desplegado un servicio. Se limita a zonas prefirmadas y excluye la firma en línea y la zona raíz.

“Restaurar” se refiere a recuperar la función de firma. Si la clave privada desapareció sin respaldo utilizable, la propuesta no la reconstruye. Introduce material nuevo y conserva durante el tiempo necesario las claves públicas y firmas antiguas que aún sostienen la validación.

El tiempo válido no es tiempo libre

El borrador define una clave privada inoperable por su incapacidad para firmar. Puede deberse a hardware, desastre, error operativo o acción maliciosa. No equivale automáticamente a una clave comprometida. Si el secreto sigue funcionando y puede estar en manos de un adversario, la respuesta debe considerar uso hostil; si no funciona, el problema inmediato es mantener continuidad. La etiqueta del incidente determina poderes y prioridades.

Al fallar la clave, la zona puede seguir correctamente firmada. Muchas RRSIG duran días, pero esa referencia descriptiva no constituye un plazo garantizado. El margen real depende de las expiraciones concretas de toda la zona, de lo que sirven los autoritativos y de las combinaciones que guardan los validadores.

Durante ese margen quizá no sea posible cambiar una dirección, retirar un destino comprometido, corregir correo o añadir una prueba nueva. La zona está disponible porque conserva una fotografía anterior. Confundir esa fotografía con normalidad puede posponer la recuperación hasta que quede demasiado poco margen.

El impulso contrario también es peligroso. Si el software elimina una DNSKEY porque no encuentra su parte privada, o reemplaza los RRSIG antiguos antes de que el relevo esté listo, puede fabricar un estado bogus. La revisión exige retener las claves públicas y recomienda conservar las firmas; si el firmante las quita, el operador puede tener que reponerlas a mano.

La ZSK se recupera dentro del hijo, hasta cierto punto

Cuando se pierde una ZSK pero la KSK funciona, se puede publicar una ZSK nueva dentro del RRset DNSKEY y firmar ese conjunto con la KSK existente. La clave no está lista cuando aparece en el primario. Debe propagarse por los autoritativos y sobrevivir al horizonte de caché de DNSKEY: Ipub = Dprp + TTLkey.

Después comienza la firma con la ZSK nueva. La antigua sigue publicada mientras termina la firma, se propaga la zona y caducan de los cachés los RRSIG generados con ella. El intervalo se expresa como Iret = Dsgn + Dprp + TTLsig. La avería, publicación, disponibilidad, activación y retirada tienen marcas temporales propias.

Este escenario conserva la cadena de confianza, pero puede congelar cambios. En las actas de IETF 126 se recoge la observación de que perder solo la ZSK no destruye la continuidad. Es correcto y, a la vez, insuficiente para declarar recuperado el servicio: continuidad de validación no significa capacidad de editar la zona.

La KSK obliga a cruzar la frontera del padre

Una KSK nueva necesita un DS en el padre. La revisión emplea Double-DS: presentar el nuevo DS, esperar su registro y publicación, permitir su propagación y el transcurso del TTL, y solo entonces activar la KSK de reemplazo en el hijo.

La publicación ocurre tras el retraso de registro, Tpub = Tsbm + Dreg. La preparación requiere después IpubP = DprpP + TTLds. Ninguna optimización del firmante puede decidir cuánto tarda el padre ni vaciar los cachés de los resolvers. RFC 7583 ya advertía que los tiempos de una KSK ligada al padre no están enteramente bajo control del gestor de la zona.

Una respuesta administrativa de “aceptado” no es el DS publicado. El DS publicado en un servidor tampoco es todavía evidencia de disponibilidad en todos los autoritativos y cachés relevantes. El recibo, la aplicación y la preparación para activar deben permanecer separados.

Con una CSK inoperable se juntan ambas dificultades. La misma clave protegía el DNSKEY y el resto de la zona. La recuperación necesita el recorrido Double-DS y, además, restablecer la firma de datos. La retirada prudente incorpora el tiempo de firma, la propagación del hijo y el mayor TTL entre DNSKEY y RRSIG.

La excepción manual tiene su propia autoridad

CDS y CDNSKEY automatizan en condiciones ordinarias el mantenimiento del DS. Pero una ZSK o CSK inoperable no puede autenticar los registros nuevos que pedirían el cambio. La revisión lleva esa operación al canal manual. Ahí reaparecen preguntas que la automatización escondía: quién representa al hijo, quién verifica la clave, quién autoriza saltarse el proceso automático y quién confirma que el padre publicó lo aprobado.

Los secundarios añaden otra frontera. Para evitar modificar un SOA que no puede volver a firmarse con la clave antigua, el operador puede mantener su valor al introducir la DNSKEY nueva. Sin cambio de SOA, IXFR o AXFR puede no disparar la carga habitual. Será necesario forzarla en los secundarios. Ver la clave correcta en el primario no demuestra coherencia en toda la constelación autoritativa.

Un RRset DNSKEY nuevo también invalida el digest ZONEMD anterior. Debe generarse y firmarse otro. La sección de implementación sobre Knot DNS indica que la generación manual del nuevo digest no está disponible en el procedimiento probado. Es un límite concreto y valioso, no una evaluación de todo el mercado de firmantes.

En IETF 126 se pidió comparar mejor TTL y expiración de firmas y documentar implementaciones. El ponente informó de una prueba con Knot DNS y la presidencia solicitó una sección específica. La revisión 02 incorpora esa capa. El registro respalda experiencia acotada; no permite afirmar interoperabilidad entre proveedores.

Un recibo que no comprime el proceso

El recibo de tiempos de recuperación empieza por clasificar el fallo, indicar el rol de la clave y calcular la expiración más temprana que limita la zona servida. Debe guardar prueba de que DNSKEY y RRSIG antiguos continúan presentes, así como observaciones de la clave nueva en las instancias autoritativas y los valores de propagación y TTL usados.

Para KSK y CSK, el documento operativo separa presentación, autenticación, aceptación, publicación observada y fin del horizonte de caché en el padre. Para los secundarios, identifica cada carga forzada y el contenido resultante. Para ZONEMD, registra el digest nuevo o la excepción aprobada. Al final, distingue nueva firma completada, muestra validada, momento seguro de retirada y eliminación real.

No hace falta revelar secretos. Nunca se publican la clave privada ni la configuración del HSM. Hashes de artefactos, key tags, tiempos, RRsets observados, versiones de política y roles responsables permiten auditar la secuencia sin abrir el entorno criptográfico.

Tampoco debe fingir omnisciencia. Nadie ve todos los cachés recursivos. Los TTL producen límites conservadores y las sondas distribuidas aportan muestras. Por eso importan las entradas del cálculo. Un tercero puede revisar Dprp, TTLkey, TTLds, TTLsig y Dsgn; no puede revisar un semáforo verde que oculta cómo se obtuvo.

El estado final merece el mismo rigor. Presentado, aceptado, publicado, listo, activo, elegible para retirar y eliminado designan hechos diferentes. Llamar “recuperación” a cualquiera de ellos por separado adelanta la conclusión.

La contribución del borrador es mostrar cómo aprovechar las firmas supervivientes sin romper la validación. No promete un SLA universal, ni ve todos los cachés, ni autoriza cualquier excepción manual. Su consecuencia de gobernanza es más amplia: el tiempo restante constituye un presupuesto compartido. Se protege cuando cada operador responde por el reloj que controla y entrega evidencia al siguiente.

Fuentes

  1. DNSSEC Key Restore — revisión 02
  2. Registro del documento en Datatracker
  3. Historial del borrador
  4. Actas de DNSOP en IETF 126
  5. Documentos activos de DNSOP
  6. Carta de DNSOP
  7. RFC 9364: DNS Security Extensions
  8. RFC 7583: tiempos de rotación de claves DNSSEC
  9. RFC 8078: gestión de DS mediante CDS/CDNSKEY
  10. RFC 8976: digest de zonas DNS
  11. RFC 9499: terminología DNS