Activación de DNSSEC en BIND con DNS dinámico

Configuración inicial

Partimos de que ya tenemos la zona funcionando con DNS dinámico. Los pasos son:

1. El directorio donde se almacenan las claves y el directorio donde se almacenan los ficheros de zona para los dominios con gestión mediante DNS dinámico, deben tener permiso de escritura para el grupo bajo el que se ejecuta el proceso BIND. Típicamente ese grupo será bind o named.

   En los ejemplos vamos a considerar que el grupo correcto es bind.

2. Entramos en el directorio de claves y creamos una clave KSK y una clave ZSK para el dominio que nos interesa:

   $ dnssec-keygen -3 -a RSASHA256 -b 1024 example.org
   $ dnssec-keygen -3 -a RSASHA256 -b 2048 -f KSK example.org
   $ chgrp bind *
   $ chmod g+r *.private
   

3. En la configuración BIND:

   1. En la sección options debemos indicar en qué directorio se almacenan las claves [1]:

      key-directory "PATH_CLAVES";
      

      [1]	Puede ser preferible usar un directorio diferente por dominio, según nuestra necesidades. En ese caso, la directiva key-directory se pondrá en la sección correspondiente al dominio que nos interesa.

   2. En la sección de dominio que nos interesa debemos añadir la siguiente directiva:

      auto-dnssec maintain
      

4. Indicamos a BIND que revise la configuración de la zona:

   $ rndc reload example.org
   

5. Ahora BIND se encargará de tomar las claves KSK y ZSK que hemos creado y de firmar la zona apropiadamente de forma automática. Podemos confirmarlo de dos formas:

   1. Haciendo una consulta DNS. Por ejemplo:

      $ dig @127.0.0.1 SOA +dnssec example.org
      

      Si aparecen registros RRSIG todo va bien. Son las firmas DNSSEC.

   2. En vez de esperar a que BIND lo haga automáticamente tras cierto tiempo desde el último cambio, le pediremos explícitamente que vuelque la base de datos interna de la zona al fichero de texto usado como backup:

      $ rndc sync example.org
      

      Ahora examinamos el fichero de texto y confirmamos que aparecen registros DNSSEC como RRSIG o DNSKEY.

   A partir de ahora BIND toma el control DNSSEC de la zona. Se encargará de actualizar las firmas RRSIG cuando sea necesario, registros NSEC y NSEC3, rotación de claves, etc. Básicamente podemos olvidarnos del asunto.

6. Una vez que una zona tiene DNSSEC funcionando correctamente, debemos "conectarla" al árbol DNS. Es decir, debemos indicar a su padre en el árbol DNS que la zona soporta DNSSEC y cuál es la KSK.

   Esto se hace especificando registros DS en la zona padre. Los registros DS se calculan a partir de la clave KSK de la zona:

   $ dnssec-dsfromkey clave_KSK.key
   example.org. IN DS 9543 8 1 B5C86E7D2F43E8E130C498ED87CBC789B56E20D8
   example.org. IN DS 9543 8 2 25DCB70B0F844BAAC2DC82852997746144D195C96D942A9A79B1BCE18A3DF27C
   

   Este comando nos proporciona dos registros DS usando dos algoritmos diferentes.

   Estos registros DS son los que debemos poner en el DNS padre de nuestro dominio a modo de anclaje, ya sea poniéndolo nosotros mismos si somos quienes gestionamos ese dominio padre, ya sea enviando la petición de actualización a la entidad de registro o a la entidad administrativa que nos haya delegado el dominio en el que hemos activado DNSSEC.

   Una vez que el DNS padre está actualizado y el cambio se propaga por Internet, podemos verificar que estamos dando servicio DNSSEC correcto:

   1. Si nuestro resolver gestiona DNSSEC, podemos hacer algo así:

      $ dig example.org
      ...
      ;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
      ...
      

      Si la respuesta nos devuelve valores correctos y contiene el flag ad (Autenticated Data), entonces tenemos DNSSEC y se está gestionando correctamente.

   2. Podemos usar herramientas online como https://dnssec-debugger.verisignlabs.com/.

Mantenimiento

Como ya he explicado, las versiones recientes de BIND se encargan de todos los detalles técnicos de DNSSEC relativos a una zona gestionada mediante DNS dinámico. No obstante, existen dos tareas administrativas que deben realizarse de forma manual:

1. Actualización de la ZSK:

   La clave ZSK debería actualizarse de forma frecuente (por ejemplo, una vez al mes). Esto es especialmente importante en zonas "jugosas" para un atacante si la clave ZSK empleada es de menos de 2048 bits.

   Para actualizar la ZSK creamos una ZSK nueva y marcamos la ZSK vieja como expirada. La expiración ocurre en dos fases: en la primera fase ya no se firman registros con la ZSK vieja, pero la clave en sí se sigue incluyendo en la zona porque puede haber registros RRSIG firmados con la ZSK vieja en cachés de internet. En una segunda fase, retiramos definitivamente la ZSK vieja de la zona DNS.

   Es decir:

   $ dnssec-keygen -3 -a RSASHA256 -b 1024 example.org
   $ chgrp bind *
   $ chmod g+r *.private
   $ dnssec-settime -I+4h -D+30d clave_ZSK_VIEJA
   

   El primer comando crea una ZSK nueva. El último comando indica a BIND que la clave ZSK antigua debe dejar de firmar registros en cuatro horas y desaparecer del DNS en 30 días.

   El tiempo durante el cual la vieja ZSK debe seguir firmando registros debería ser un poco superior al TTL de los registros DNSKEY del dominio. Un cliente DNS no debería recibir un registro DNS con un RRSIG generado por la clave nueva sin que hayan caducado los registros DNSKEY que pudiera tener en su caché.

   Nota

   Los tiempos también se pueden poner con fechas absolutas, pero a mí me resulta más fácil trabajar con desplazamientos respecto al momento actual.

   BIND revisa el directorio de claves cada hora, por defecto, buscando nuevas claves y cambios de configuración relevantes. Nuestro cambio se activará automáticamente en el siguiente ciclo.

2. Actualización 20170624: Si usamos NSEC3, que es la opción recomendada en el caso general, hay que cambiar el valor de la sal del registro NSEC3PARAM de vez en cuando. Lo más sencillo es hacerlo cuando se actualiza la ZSK.

3. Actualización de la KSK:

   La actualización de la KSK se realiza exactamente igual que la de la ZSK. Es crítico tener en cuenta lo siguiente:

   1. Debemos mantener el anclaje DNSSEC correcto, así que debemos generar los registros DS correspondientes a la nueva KSK y activarlos en el dominio padre. No borramos aún los registros DS antiguos. Es decir, durante un tiempo el dominio padre indicará que existen dos KSK válidas para nuestro dominio.

      Los pasos para generar los registros DS se han explicado más arriba.

   2. El solapamiento entre el KSK antiguo y el nuevo debe ser mucho mayor que en el caso del ZSK. La idea, como antes, es que los clientes deben ver solapamiento de las dos claves. Es catastrófico que un cliente reciba un registro RRSIG generado por la KSK nueva cuando aún no sabe que existe.

      Por ejemplo, los DS de los dominios .COM tienen un tiempo de vida de 24 horas. Además, tampoco estamos seguros de en qué momento nuestro dominio padre añadirá los DS a su zona tras habérselo solicitado. Tenemos poco control sobre todo eso, así que yo recomiendo un solapamiento mínimo de una semana. Es decir, durante una semana se usarán las dos KSK para firmar las ZSK de la zona. Los clientes que verifiquen DNSSEC utilizarán la firma RRSIG cuya KSK conozcan, ignorando la otra.

   3. Una vez transcurrido el tiempo de solapamiento de forma holgada, podemos solicitar a nuestro dominio padre que elimine los registros DS antiguos, que ya no son relevantes.

   Romper los anclajes DNSSEC es catastrófico, así que cada paso de un cambio KSK debe ser cuidadoso y hay que revisar que todo está como tiene que estar.

   La recomendación habitual es cambiar la clave KSK una vez al año. En la práctica veo que muchos dominios actualizan su KSK muy de vez en cuando o, directamente, nunca.

Referencias

• Domain Name System Security Extensions.
• Domain Name System Security Extensions (DNSSEC) and BIND.
• BIND DNSSEC Guide.
• Chapter4. Advanced DNS Features: DNSSEC.
• Chapter4. Advanced DNS Features: DNSSEC, Dynamic Zones, and Automatic Signing.
• DNSSEC Quick Reference Guide.
• DNSSEC Analyzer.