Automatización y mantenimiento de NSEC3PARAM en DNSSEC
La solución propuesta en Por qué es conveniente usar NSEC3 en vez de NSEC en un dominio DNSSEC define NSEC3PARAM ya sea en el fichero de zona o utilizando rndc signing -nsec3param.
Este enfoque tiene un problema serio: ocasionalmente el signed o el journal de BIND se corrompen y hay que borrarlos. No parece grave porque BIND vuelve a regenerar esos ficheros pero... la configuración NSEC3PARAM se pierde. Y si BIND pierde la configuración NSEC3PARAM deja de servir NSEC3 y la zona pasa a ser NSEC... y no te enteras.
Tras ocurrirme un par de veces decidí ver qué estaba haciendo mal.
La cuestión es que mi configuración DNSSEC de BIND estaba bastante anticuada y las versiones modernas de BIND permiten una configuración más fina. En concreto, la versión 9.16 de BIND añade dnssec-policy para reemplazar mi antiguo auto-dnssec. El cambio de configuración no es trivial y resulta algo arriesgado, así que aguanté mientras pude.
Advertencia
Cambiar tu configuración DNSSEC es arriesgado. Si te equivocas puedes encontrarte que tu dominio DNS deja de funcionar, a veces de forma errática y misteriosa. Además, el problema puede tardar en aparecer y solucionarlo puede llevar también bastante tiempo debido a los cachés DNS.
En resumen, a) haz copia de seguridad de todo, b) comprueba que todo funciona bien, incluyendo 24 horas después y c) lo más crítico es no perder tu claves KSK y ZSK, ¡protégelas con tu vida!
Pues resulta que usando dnssec-policy se puede automatizar la gestión de NSEC3PARAM, justo lo que necesito. La excusa perfecta para dejar de ser un remolón y migrar de una vez por todas (auto-dnssec desaparece en BIND 9.20).
En el fichero de configuración named.conf tengo una línea auto-dnssec maintain en cada zona con DNSSEC. Ahora las reemplazo por dnssec-policy jcea. Además, debo definir la política DNSSEC jcea:
dnssec-policy jcea {
dnskey-ttl 28800;
keys {
ksk key-directory lifetime unlimited algorithm ECDSAP256SHA256;
zsk key-directory lifetime unlimited algorithm ECDSAP256SHA256;
};
nsec3param iterations 0 optout no salt-length 0;
};
Aquí vemos que la política jcea define una configuración NSEC3PARAM [1], que era lo que pretendíamos.
| [1] | Parece sorprendente que no estemos usando salt y hagamos cero iteraciones adicionales, pero se ha comprobado que ambos parámetros no contribuyen sensiblemente a la seguridad y en cambio sí afectan al rendimiento. Mira las recomendaciones, por ejemplo, del rfc 9276. |
En un futuro podría ser interesante que la gestión de las claves ZSK fuese automática, cosa que permite la nueva configuración, pero de momento no lo veo urgente y mejor ir poco a poco.
Advertencia
Uno podría pensar que la configuración dnssec-policy por defecto es conservadora y, por ejemplo, no toca las claves KSK o ZSK si no se le indica explícitamente. Pues resulta que no. Si no se indica lo contrario, las claves se rotan cada 30 días, así que BIND considera que tus claves actuales están anticuadas y las borra y genera claves nuevas. Una catástrofe porque no podemos actualizar automáticamente (en mi caso) los registros DS en la zona DNS padre.
Menos mal que antes de tocar nada de esto hice un snapshot ZFS y pude volver atrás con un par de comandos casi instantáneos.
Aprende de mis errores y asegúrate de a) hacer una copia de todo tu entorno BIND antes de tocar nada, especialmente de las claves DNSSEC y b) pon una gestión explícita de las claves KSK y ZSK y no te fíes de la configuración por defecto, que resulta que es bastante agresiva.
Probemos los cambios tras activar la nueva configuración en BIND:
jcea@jcea:~$ dig NSEC3PARAM jcea.es [...] ;; ANSWER SECTION: jcea.es. 0 IN NSEC3PARAM 1 0 0 - [...] jcea@jcea:~$ dig +dnssec NOEXISTE.jcea.es [Aquí vemos pruebas NSEC3 de la no existencia de ese nombre]
Tienes muy bien explicado todo el tema de la nueva configuración de la política DNSSEC en BIND en DNSSEC Key and Signing Policy.