Activación de DNSSEC en BIND con DNS gestionado de forma manual

En Activación de DNSSEC en BIND con DNS dinámico explico cómo activar DNSSEC en BIND cuando estamos trabajando con un dominio bajo DNS dinámico. Para completar nuestra gestión necesitamos documentar también cómo utilizar DNSSEC para dominios gestionados de forma manual.

Advertencia

Mis primeros intentos DNSSEC con zonas de gestión manual fue con BIND 9.10.x. En principio debería funcionar, el soporte de esta funcionalidad viene de BIND 9.9, pero tuve problemas con la renovación de firmas y con las notificaciones a los servidores DNS secundarios.

Todo fue bien cuando instalé una versión 9.11 de BIND compilada a mano. Fue muy fácil bajo SmartOS:

# ./configure --disable-static --with-libtool \
              --enable-threads --with-libjson=yes \
              --with-openssl=/opt/local/ \
              --prefix=/opt/local/ --enable-ipv6 \
              --sysconfdir=/opt/local/etc \
              --localstatedir=/var
# make
# make install

El funcionamiento de BIND para DNSSEC cuando estamos trabajando con dominios gestionados de forma manual es diferente a lo que documento en Activación de DNSSEC en BIND con DNS dinámico para el caso de DNS dinámico:

  • La gestión manual se sigue realizando como siempre: editamos el fichero de texto a mano, incrementamos a mano el número de serie de la zona e indicamos a bind que recargue la zona con un rndc reload o similar.

  • Internamente BIND utiliza dos pequeñas bases de datos por zona manual bajo BIND:

    • En una de ellas se conserva una copia de la versión actual de la zona, derivada directamente del fichero de texto que editamos de forma manual. BIND utiliza esta base de datos para poder identificar los cambios que hemos hecho en la zona desde la última actualización. Conociendo esos cambios, BIND sabe cómo reconstruir el soporte DNSSEC de la zona sin tener que regenerar todas las firmas, registros NSEC y NSEC3, etc.
    • En la segunda base de datos BIND contiene la zona final, con todo su soporte DNSSEC, que es lo que utiliza para responder peticiones DNS sobre el dominio.

  • Al contrario que con el DNS dinámico, BIND no vuelca las bases de datos internas a texto plano de forma periódica, ya que la versión en texto plano (que es la versión "oficial" de la zona) se gestiona de forma manual por el usuario.

    Si las bases de datos se corrompen de alguna forma, podemos borrarlas sin problemas y se volverán a regenerar a partir del texto plano manual [1].

[1] (1, 2)

Hay que prestar atención al número de serie del SOA ya que, en una zona DNSSEC, este se incrementa internamente a medida que se van regenerando las firmas DNSSEC. Es decir, el SOA de una zona DNSSEC gestionada de forma manual no se corresponde con el SOA que hemos indicado en el fichero de texto de la zona, al menos no a medida que pasa el tiempo y las firmas digitales DNSSEC de la zona se van reconstruyendo.

Idealmente habría que consultar el SOA de la zona a los servidores DNS secundarios de la misma y actualizar el SOA del fichero de texto antes de recargar la zona en el BIND y que este regenere las bases de datos internas.

En caso contrario, los servidores DNS secundarios podrían no actualizar los cambios en la zona, por tener un número de serie superior en su SOA.

Debemos arrancar, pues, con un número de serie SOA superior al de los servidores DNS secundarios. Para ello podemos consultarles qué valor están usando. Por ejemplo, suponiendo que los servidores DNS secundarios estén actualizados, podemos hacer algo tipo:

$ dig SOA jcea.es @SERVIDOR_DNS_SECUNDARIO
...
;; ANSWER SECTION:
jcea.es.                28800   IN      SOA     dns.jcea.es. root.jcea.es. 2017110825 14400 7200 2592000 28800

Aquí vemos que el número de serie SOA que le consta a la red es 2017110825. Debemos configurar la zona manualmente con un número de serie SOA superior a ese. Si tenemos varios servidores DNS secundarios, hemos hecho cambios en la zona hace poco y no tenemos la certeza de que todos se hayan actualizado correctamente, habría que preguntarles a todos y quedarnos con el número de serie SOA más alto.

Configuración inicial

Si queremos pasar una zona DNS gestionada de forma manual a DNSSEC, haremos lo siguiente:

  1. El directorio donde se almacenan las claves y el directorio donde se almacenan los ficheros de zona 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 [2]:

      key-directory "PATH_CLAVES";
      [2]

      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 del dominio que nos interesa debemos añadir la siguientes directivas:

      inline-signing yes;
auto-dnssec maintain;

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

    $ rndc reload example.org

El resto de pasos para comprobar que la zona está gestionada con DNSSEC, unir la zona al árbol DNS global y comprobar que todo se ha hecho bien se realizan exactamente igual que con DNS dinámico y lo explico en Activación de DNSSEC en BIND con DNS dinámico.

Mantenimiento

El mantenimiento habitual de una zona DNSSEC es similar en el caso de DNS dinámico y gestión manual, y se explica en Activación de DNSSEC en BIND con DNS dinámico.

Las diferencias fundamentales son las siguientes:

  • A medida que BIND va actualizando las firmas DNSSEC cuando es necesario, incrementa el número de serie del SOA de la zona para que los servidores DNS secundarios se actualicen con los cambios. Por ejemplo, el número de serie del SOA que tengo puesto en mi fichero de configuración de zona, ahora mismo, es 2017110701. En cambio el número de serie publicado es 2017110825. Es decir, ha habido unas 124 actualizaciones DNSSEC transparentes para mí, pero que han incrementado el número de serie en el SOA.

    Si actualizamos manualmente el número de serie del SOA del dominio y la numeración interna de BIND es superior, el programa simplemente incrementará el número de serie SOA interno en uno.

    Es decir, supongamos que el número de serie SOA manual era 2017110701 y que en un día el número de serie SOA interno ya va por 2017110825. Si ahora actualizamos la zona de forma manual con el número de serie SOA 2017110801, en realidad BIND utilizará el número de serie SOA interno 2017110826. En cambio si hubieran pasado unos días y hubieramos puesto el número de serie 2017112001, BIND utilizaría dicho número de serie SOA como punto inicial y lo iría incrementando a medida que se fueran actualizando las firmas DNSSEC.

    Esto tiene dos efectos, uno bueno y uno malo. El bueno es que, en general, no tenemos que preocuparnos de la gestión de los números de serie SOA, los manejaremos como siempre sin preocuparnos del mantenimiento DNSSEC que está haciendo BIND por debajo. El efecto malo es que el número de serie SOA pierde su semántica convencional. Es decir, si alguien examina mi zona y ve un número de serie SOA de 2017110826 podría deducir que el último cambio en la misma fue el 8 de noviembre de 2017 y que, además, fue un día bastante animado (26 cambios). De hecho si el número de serie SOA se va incrementando podríamos tener algo del tipo 2017113600, y es de todos sabido que, hoy por hoy, no hay meses de 36 días. O con 2017140000 veríamos que algo raro pasa, porque no podemos estar en el día cero del mes catorce.

    El único caso en el que debemos preocuparnos de los números de serie SOA es si se corrompen o borramos las bases de datos internas de la zona, ya que BIND no sabría en qué número de serie va y los servidores DNS secundarios podrían no actualizarse correctamente. Los detalles se explican en la nota escrita más arriba [1].

  • Si por cualquier motivo debemos borrar los ficheros de bases de datos internos de BIND sobre la zona, tenemos que tener mucho cuidado con lo descrito en el punto anterior.

    BIND utilizará las claves KSK y ZSK apropiadas (que sean válidas, fechas correctas, etc) en el directorio de claves.

  • Para hacer frente a posibles borrados o corrupciones de la base de datos, recomiento también encarecidamente emplear parámetros NSEC3 explícitos en el fichero de zona manual en texto. De esta forma si hay que regenerar la base de datos, tendremos los mismos parámetros y, además, no acabaremos con una zona NSEC de forma accidental.

    Los pasos son muy simples: añadimos un registro NSEC3PARAM en nuestra zona. En mi caso, por ejemplo, es:

    0       IN      NSEC3PARAM 1 0 10 10509680947E2510CCFA3A79B8434721

    El valor de utilizar NSEC3 se detalla en Usar NSEC3 en vez de NSEC en un dominio DNSSEC con gestión de DNS dinámico.