Una de las acciones dentro de DNSSEC que no aparece muy documentada es cómo puedo cambiar mi firmador. Supongamos que llevo años firmando con una herramienta, usando algún HSM para guardar las llaves, pero quiero darlo de baja y pasarme a otra herramienta que tiene otro HSM propio.

Como sabemos, los HSM por diseño no permiten sacar las llaves privadas. Entonces ¿cómo hacemos el traspaso de un sistema de firmado a otro, sin quebrar DNSSEC?

La respuesta corta es: haciendo un rollover con DS-doble, manteniendo el mismo algoritmo.

La respuesta larga a continuación.

Requisitos importantes:

• los HSM no permiten exportar las llaves privadas (si lo permitieran, entonces no existe problema. Se importan en la nueva plataforma y listo).

• debo mantener el mismo algoritmo antes y después (luego, cuando el cambio ya esté hecho, puedo hacer un rollover de algoritmo en la nueva plataforma)

• mi sistema de firmado antiguo y nuevo deben permitir incorporar llaves externas en la zona (sólo la parte pública).

Manos a la obra.

En la situación original, supongamos que tenemos un sistema de firmado llamado “actual”, con un HSM que tiene 2 llaves: una KSK y una ZSK. Las partes privadas de las llaves están dentro del HSM, y las públicas están en el registro DNSKEY de la zona, firmados con la KSK. El DS en el padre apunta a esta KSK. Una zona firmada completamente norma, hasta ahora.

El primer paso es armar nuestra nueva plataforma, que llamaremos “nueva”. Como esta plataforma tiene su propio HSM, va a tener unas llaves distintas KSK y ZSK, que voy a crear en este momento. Esta zona “nueva” no va a estar publicada en el DNS aún, solo en mi laboratorio. El DS asociado a esta nueva KSK no estará en ninguna parte.

Una vez que he hecho pruebas de la nueva plataforma y todo se ve bien, comienza la acción.

El segundo paso es incorporar la nueva ZSK pública de la nueva plataforma dentro del DNSKEY set de la plataforma actual. Cada herramienta tiene su forma particular de hacerlo. Por ejemplo en Knot se puede hacer “keymgr import-pub”. En Bind existe “dnssec-importkey”. Lo importante es que a partir de este paso, el DNSKEY set público será:

`

zona.  DNSKEY  KSK-pública-actual
zona.  DNSKEY  ZSK-pública-actual
zona.  DNSKEY  ZSK-pública-nueva

`

y todo firmado con la KSK actual.

Esto se deja publicado un tiempo prudente (al menos dos TTL), antes de pasar al siguiente paso.

El tercer paso es hacer lo mismo en la nueva plataforma: importamos la ZSK pública actual en el DNSKEY set de la zona. Quedará así:

`

zona.  DNSKEY  KSK-pública-nueva
zona.  DNSKEY  ZSK-pública-nueva
zona.  DNSKEY  ZSK-pública-actual

`

firmado con la KSK nueva. En una zona que no está al aire aún.

Ahora es el momento de mandar el nuevo DS al padre. Dos cosas son muy importantes: el algoritmo de la nueva KSK es el mismo que el antiguo, porque así se pueden usar los dos DS indistintamente; y se debe mantener el DS actual. Es decir, debemos tener dos DS en el padre, cada uno apuntando a cada KSK. La nueva KSK aún no es publicada, pero es importante tener su DS antes que ocurra.

Acá también esperamos dos TTL por lo menos (TTL del DS en el padre!)

Finalmente llegamos al momento crucial: empezamos a publicar la nueva zona, con nuestras llaves KSK nueva, ZSK nueva, y la ZSK actual (que ahora pasaremos a llamar “vieja” a esta altura). Como existe un DS nuevo en el padre apuntando a nuestra nueva KSK, todo va a validar. Y si algún resolver tenía en su caché un registro antiguo, firmado con la ZSK antigua, igual va a seguir validando porque la tenemos en nuestro nuevo DNSKEY set. Todo sigue correcto!

Ahora queda lo último: limpiar todo.

Debemos de nuevo esperar un tiempo, por lo menos un par de TTLs.

Primero sacamos la ZSK antigua del DNSKEY set nuevo, publicamos y esperamos; y luego podemos pedirle al padre que saque el DS de nuestra KSK vieja, quedando solo con el DS nuevo.

Volvimos a la situación “normal”, pero en la nueva plataforma! Felicitaciones. Ha hecho un rollover de KSK con doble-DS, y DNSSEC nunca se quebró.