Resumen

  • Que una zona siga respondiendo con RRSIG vigentes después de perder una clave privada solo demuestra que queda tiempo dentro de un estado ya firmado. No demuestra que la clave sea recuperable ni que exista capacidad para firmar el siguiente cambio.
  • Cada diseño obliga a conservar un solapamiento distinto: Pre-Publication cuando falla la ZSK y la KSK funciona; Double-DS cuando falla la KSK; y Double-DS con retirada conjunta y más larga cuando falla una CSK.
  • La declaración de recuperación necesita pruebas independientes de la publicación en padre e hijo, la expiración de cachés, la carga de todos los servidores autoritativos, la coherencia de SOA, NSEC/NSEC3 y ZONEMD, la validación recursiva y la continuidad de aplicaciones.

La prueba que llega demasiado pronto

Un incidente de DNSSEC puede comenzar con un resultado tranquilizador. La clave privada ha quedado inoperable, pero una consulta desde la oficina devuelve una respuesta autenticada. El monitor muestra Secure. El servidor web acepta TLS. A primera vista, la zona parece haber sobrevivido.

En realidad, esa consulta no ha probado supervivencia futura. Ha probado que un conjunto de datos firmado antes del fallo todavía encaja con una DNSKEY y con una cadena de confianza que ese resolvedor puede construir en ese instante. Las RRSIG suelen conservar validez durante días; una zona prefirmada puede seguir sirviéndolas sin tocar la clave privada. Es una reserva de tiempo muy valiosa, pero agotable.

La distinción está formulada con precisión en draft-ietf-dnsop-dnssec-keyrestore-02: si no existe una copia operativa de la parte privada, la clave no puede restaurarse; sí puede restaurarse la función de firma con material nuevo. A la fecha de verificación, el documento es un Internet-Draft activo del grupo de trabajo DNSOP, revisión 02, actualizado el 10 de agosto de 2026. No es un RFC. Sus autores, Florian Obser y Martin Pels, lo presentan como trabajo en curso de carácter informativo. Se ocupa de registros prefirmados, deja fuera la firma en línea y excluye la zona raíz, cuya distribución de nuevas anclas de confianza puede superar la vida de una RRSIG.

También importa la definición del fallo. «Inoperable» significa que la parte privada de una DNSKEY incluida en la cadena de confianza ya no puede firmar. No es el mismo caso que una clave comprometida pero aún utilizable: allí el riesgo es que un tercero pueda firmar, no solo que el titular haya perdido capacidad.

Los cinco relojes que una pantalla verde oculta

El primer reloj es el de expiración de las RRSIG. Marca el borde duro: cuando una firma antigua vence, ya no sostiene la respuesta. El segundo es el TTL de DNSKEY, que determina cuánto puede sobrevivir en caché un conjunto antiguo de claves. El tercero es TTLds, equivalente en el lado del padre. El cuarto mide la propagación real entre maestros, secundarios, instancias unicast y nodos anycast. El quinto es administrativo: el tiempo entre solicitar un DS, lograr que el padre lo acepte y verlo publicado.

Ninguno puede deducirse del otro. Una solicitud de DS aceptada puede permanecer fuera de la zona padre. Una DNSKEY visible en el maestro puede faltar en un secundario. Una firma válida en una ubicación puede coexistir con una respuesta Bogus en otra cuyo caché conserva una combinación anterior. Las fórmulas de transición solo son conservadoras si los TTL máximos y los retrasos de propagación son conocidos y después se comprueba que la publicación ocurrió.

El margen puede destruirlo el propio operador. Quitar la DNSKEY antigua, descartar RRSIG que todavía sostienen datos o modificar un registro que ya no puede volver a firmarse reduce la ventana. Por ello, el firmante no debe eliminar DNSKEY hasta recibir una instrucción expresa y debería preservar las RRSIG antiguas. Si el software no puede mantenerlas, deben reponerse manualmente antes de publicar, excepto la antigua firma que cubre el RRset DNSKEY. Tampoco conviene añadir un cambio de algoritmo salvo que ya estuviera en curso: primero se recupera con el algoritmo actual y después se realiza una transición ordinaria.

El vocabulario operacional del RFC 7583 ayuda a mantener el orden: publicada, preparada, activa, retirada y muerta son fases diferentes. Los mecanismos de Pre-Publication, Double-Signature y Double-DS del RFC 6781 no son nombres intercambiables; resuelven dependencias de caché distintas.

Cuando la ZSK falla y la KSK todavía obedece

Con KSK y ZSK separadas, una ZSK inoperable impide firmar cambios de datos. La KSK, sin embargo, aún puede autenticar un RRset DNSKEY modificado. Eso deja un único camino útil: Pre-Publication.

En Tpub se añade la nueva ZSK al DNSKEY. Se conservan la antigua ZSK inoperable y todas sus RRSIG. Normalmente no se cambia el SOA y se fuerza a los secundarios a cargar el estado nuevo. La publicación observada en un servidor no hace que la clave esté preparada. Primero debe transcurrir Ipub = Dprp + TTLkey: propagación a todas las instancias autoritativas más la vida del DNSKEY antiguo en caché. La preparación ocurre en Trdy = Tpub + Ipub.

Solo desde Trdy pueden cambiarse los datos y firmarse con la nueva ZSK. En ese momento es posible retirar las RRSIG antiguas, pero no la ZSK antigua publicada. Para eliminarla hace falta Iret = Dsgn + Dprp + TTLsig: tiempo de firma, propagación autoritativa y TTL máximo de las firmas. Un camino de Double-Signature es teóricamente posible, pero resulta más lento para recuperar porque los datos no pueden cambiar durante Dsgn + Dprp + max(TTLkey, TTLsig).

La secuencia exige tres familias de pruebas. La primera confirma que cada instancia conserva el estado antiguo mientras publica la nueva clave. La segunda demuestra que ha pasado TTLkey desde una publicación completa, no desde la edición local. La tercera comprueba nuevas firmas sobre el conjunto de RRsets y mantiene la clave antigua hasta que termine el intervalo de retirada.

Cuando falla la KSK, el hijo no puede certificarse a sí mismo

Una KSK inoperable no puede firmar un DNSKEY cambiado. Por tanto, introducir una KSK nueva únicamente en el hijo no crea un puente de confianza. Hace falta Double-DS en el padre. Si también está perdida la ZSK, se restaura primero la función KSK y se pospone la ZSK; mezclar ambos problemas impediría distinguir qué estado sostiene cada respuesta.

El nuevo DS se entrega al padre en Tsbm. Transcurrido el retraso de registro Dreg, aparece en Tpub. El recibo administrativo solo cubre solicitud o aceptación. La prueba de publicación requiere consultas a las instancias autoritativas del padre. A continuación se espera IpubP = DprpP + TTLds, que cubre la propagación en el padre y el DS antiguo retenido por los resolvedores. La KSK nueva queda preparada en Trdy = Tpub + IpubP.

En la activación, la nueva KSK entra en el RRset DNSKEY del hijo y lo firma. La KSK antigua puede salir de ese RRset; la ZSK permanece. Si esta también es inoperable, se conserva el SOA, se fuerza la carga de secundarios y luego se ejecuta la prepublicación de una ZSK nueva. El DS antiguo del padre debe permanecer durante Iret = DprpC + TTLkey después de activar, para que un resolvedor que aún retenga el DNSKEY antiguo del hijo pueda validar. La retirada del DS no debe ocurrir antes de Trem = Tact + Iret.

CDS y CDNSKEY no eliminan este límite. El RFC 8078 describe su uso para gestionar DS y el RFC 10026 amplía los mecanismos de arranque y registros de decisión, pero una recuperación puede exigir una actualización manual en el padre. Si la ZSK o CSK no firma, los CDS/CDNSKEY recién añadidos carecen de validación criptográfica; además, introducir esos tipos cambia el bitmap NSEC/NSEC3 del ápice, que tampoco puede volver a firmarse con la clave perdida.

Cuando falla una CSK, convergen dos dependencias

Una CSK firma tanto DNSKEY como los datos. Su pérdida combina el bloqueo del padre con la imposibilidad de volver a firmar la zona. Solo sirve un Double-DS ajustado. Se publica el DS nuevo en el padre y se esperan Dreg e IpubP = DprpP + TTLds. Después se activa la CSK nueva en el hijo y se firma DNSKEY, pero se mantienen la CSK antigua inoperable y todas las RRSIG antiguas. El SOA no se cambia por conveniencia y los secundarios se cargan de forma forzada.

Aquí el intervalo de retirada es Iret = Dsgn + DprpC + max(TTLkey, TTLsig). Hasta Trem = Tact + Iret no pueden retirarse conjuntamente el DS antiguo del padre, la CSK antigua y las firmas antiguas, ni reanudarse los cambios normales de zona. El máximo entre los TTL de clave y firma protege a los resolvedores situados en ambos lados de la combinación de cachés. Quitar una pieza porque una sonda ya usa la nueva ruta rompe precisamente la redundancia que hace tolerable la transición.

El problema del contenido que parece no haber cambiado

La recomendación de no incrementar el SOA solo para introducir una DNSKEY nueva en una recuperación de ZSK o CSK evita crear un SOA que la clave antigua no puede firmar. El riesgo no se limita a respuestas positivas. Un tipo nuevo en el ápice altera las pruebas NSEC/NSEC3; los datos existentes pueden validar mientras una consulta por un tipo inexistente se vuelve Bogus.

No tocar el serial, sin embargo, dificulta la convergencia de secundarios basados en IXFR o AXFR. Puede ser necesario ordenar una transferencia o carga manual. Los mecanismos de NOTIFY y transferencia de los RFC 1996 y RFC 9103 ayudan a mover el estado, pero un aviso enviado o un serial coincidente no prueba que todos los servidores hayan cargado contenido idéntico.

Cambiar DNSKEY también invalida un ZONEMD publicado. Debe generarse un nuevo resumen, firmarse y coordinarse con la construcción NSEC/NSEC3 en el orden especificado por el RFC 8976. Un ZONEMD válido ofrece evidencia de integridad del contenido según ese esquema; no sustituye la validación de la delegación ni la observación del servicio. El borrador informa de procedimientos verificados con Knot DNS, pero también de pasos manuales y de una limitación para generar manualmente un ZONEMD nuevo en ese recorrido. Es experiencia con una implementación, no garantía de compatibilidad general.

Qué puede afirmar realmente cada observador

Los RFC 4034, RFC 4035 y RFC 9364 permiten interpretar claves, firmas y resultados de validación, pero no amplían el alcance de una medición. Una DNSKEY antigua y una RRSIG vigente en un servidor prueban un estado antiguo verificable allí y entonces. Una DNSKEY nueva prueba publicación en ese punto. Un DS aceptado prueba un acto administrativo. Una RRSIG nueva válida prueba la relación entre un RRset, una firma y una clave.

Un SOA igual aporta una pista de versión, no identidad criptográfica del contenido. Una respuesta NSEC/NSEC3 válida prueba esa negación concreta, no todos los bitmaps. Un ZONEMD correcto, si fue regenerado y su firma valida, prueba su resumen de zona, no la cadena completa. Un resolvedor independiente que devuelve Secure prueba su ruta y caché. Una aplicación que responde prueba un trayecto de servicio. Ninguna observación aislada autoriza la retirada.

La evidencia suficiente se construye como una matriz temporal. Primero, se preserva una captura inmutable de la última zona buena y se hace inventario de DNSKEY, DS, inicio y expiración de RRSIG, SOA, NSEC/NSEC3 y ZONEMD. Después se observa por instancia autoritativa la conservación del estado antiguo y la llegada del nuevo, incluidos los componentes anycast medibles. Se documentan por separado solicitud, aceptación, publicación y vencimiento de caché del DS padre. En el hijo se separan publicación, preparación, activación, refirma completa, propagación y retirada.

Los recibos de transferencia y carga deben abarcar todos los secundarios. Las consultas comprueban respuestas positivas y negativas. Varios resolvedores operados independientemente, desde redes distintas, se prueban con caché caliente y fría y a lo largo del intervalo, no solo después de un vaciado artificial. Las verificaciones HTTP, TLS y de aplicaciones se repiten durante el solapamiento y la retirada. Son necesarias para medir continuidad de negocio, pero no reemplazan las pruebas DNSSEC.

No es posible censar cada caché del mundo. La palabra «garantía» en el cálculo de rollover designa una cota obtenida de TTL y propagación bajo hipótesis verificadas. Cuando la infraestructura es heterogénea o sus retrasos son desconocidos, la incertidumbre aumenta. El criterio honesto de recuperación no es una luz verde: es que todas las dependencias que podrían necesitar el estado antiguo hayan cruzado sus límites medidos y que observadores independientes confirmen el nuevo estado sin perder servicio.

Fuentes