Configuración de DNSSEC

1. ¿Qué es DNSSEC?

El Sistema de Nombres de Dominio (DNS) es una parte fundamental de la infraestructura de Internet, traduciendo nombres de dominio legibles por humanos (como dominio.edu.ar) a direcciones IP numéricas. Sin embargo, el DNS original fue diseñado sin mecanismos de seguridad robustos, lo que lo hace vulnerable a diversos ataques, como la suplantación de identidad (spoofing) y el envenenamiento de caché (cache poisoning).

DNS Security Extensions (DNSSEC) es un conjunto de extensiones al DNS que añade capas de seguridad a este sistema. DNSSEC no cifra las consultas DNS (para eso existen (DoT y DoH ), sino que proporciona autenticación de origen de datos y protección de la integridad de los datos. Esto significa que un cliente DNSSEC puede verificar que la información que recibe de un servidor DNS es la misma que publicó el propietario del dominio y que no ha sido alterada en el camino.

¿Cómo funciona?

DNSSEC utiliza firmas digitales basadas en criptografía de clave pública para autenticar las respuestas DNS. Cada zona DNS firmada con DNSSEC incluye los siguientes tipos de registros:

  • Registros DNSKEY: Contienen las claves públicas de la zona. Hay dos tipos principales:

    • Key Signing Key (KSK): Se utiliza para firmar los registros DNSKEY. La clave pública de la KSK se publica en la zona padre a través de un registro DS.

    • Zone Signing Key (ZSK): Se utiliza para firmar todos los demás registros de recursos (A, AAAA, MX, NS, etc.) dentro de la zona.

  • Registros RRSIG: Contienen las firmas digitales de los conjuntos de registros de recursos (RRsets).

  • Registros NSEC/NSEC3: Proporcionan una prueba criptográfica de la inexistencia de un nombre de dominio o un tipo de registro, protegiendo contra ataques de enumeración de zonas.

  • Registros DS (Delegation Signer): Contienen un hash de la KSK de la zona hija y se publican en la zona padre, estableciendo una cadena de confianza desde la raíz del DNS hasta la zona firmada.

Funcionamiento DNSSEC

Beneficios clave

La implementación de DNSSEC ofrece varios beneficios críticos para la seguridad y la integridad de Internet:

  • Protección contra el envenenamiento de caché: Evita que los atacantes inyecten datos falsos en las cachés de los servidores DNS, redirigiendo a los usuarios a sitios maliciosos.

  • Autenticación de origen de datos: Los clientes pueden verificar que las respuestas DNS provienen de una fuente autorizada y no de un atacante.

  • Integridad de los datos: Asegura que los datos DNS no han sido modificados durante el tránsito.

  • Confianza en la cadena de delegación: Establece una cadena de confianza criptográfica desde la raíz del DNS hasta los dominios individuales, garantizando la autenticidad de las delegaciones.

Es importante destacar que DNSSEC es una medida de seguridad complementaria a DoT y DoH. Mientras que DoT/DoH protegen la privacidad y la confidencialidad de las consultas DNS, DNSSEC garantiza la autenticidad e integridad de las respuestas DNS. Juntos, proporcionan una solución DNS mucho más robusta y segura.

2. Preparación del entorno y requisitos previos

Antes de configurar DNSSEC en BIND, es fundamental asegurarse de que el entorno esté correctamente preparado. Esta sección detalla los requisitos del sistema operativo, la instalación de BIND y las consideraciones de red.

2.1 Requisitos del Sistema Operativo

Se recomienda una distribución de Linux moderna y estable. Particularmente peferimos Debian (versión 11 o posterior)

Asegúrese de que el sistema operativo esté actualizado con los últimos parches de seguridad y paquetes. Puede hacerlo ejecutando los siguientes comandos:

apt update
apt upgrade -y

2.2 Instalación y Configuración Básica de BIND

DNSSEC requiere una versión de BIND que soporte las extensiones de seguridad. Se recomienda BIND 9.16 o una versión más reciente para aprovechar las últimas características y mejoras de seguridad.

2.2.1 Instalación de BIND9

apt install bind9 bind9-utils -y

Verifique el estado del servicio BIND:

ystemctl status bind

Si no está activo, inícielo y habilítelo para que se ejecute al inicio:

systemctl start bind
sudo systemctl enable bind

2.2.2 Configuración básica

Asegúrese de que su servidor BIND esté configurado para ser autoritativo para la zona que desea firmar con DNSSEC. Esto implica tener un archivo de zona configurado en named.conf.local.

zone "dominio.edu.ar" IN {
    type master;
    file "/etc/bind/zonas/db.dominio.edu.ar";
    allow-update { none; };
    allow-transfer { 192.168.1.2; }; // IP de servidores esclavos, si los hay
};

A efectos de mantener la configuración ordenada se recomienda crear un directorio específico para los archivos de zona.

mkdir -p /etc/bind/zonas
chown root:bind /etc/bind/zonas
chmod 750 /etc/bind/zonas
  • Debe pertenecer a root (para evitar manipulaciones accidentales).

  • Legible por el grupo bind, ya que named se ejecuta con el usuario BIND.

Archivo de zona /etc/bind/zonas/db.dominio.edu.ar:

$TTL 3600
@ IN SOA ns1.dominio.edu.ar. admin.dominio.edu.ar. (
    2023010101 ; Serial
    3600       ; Refresh
    1800       ; Retry
    604800     ; Expire
    86400      ; Minimum TTL
)

@           IN NS  ns1.dominio.edu.ar.
@           IN NS  ns2.dominio.edu.ar.

ns1         IN A   192.168.1.100
ns2         IN A   192.168.1.101

@           IN A   192.168.1.100
www         IN A   192.168.1.100
mail        IN A   192.168.1.100

Cada archivo de zona:

chown root:bind /etc/bind/zonas/db.dominio.edu.ar
chmod 640 /etc/bind/zonas/db.dominio.edu.ar

Directorio de trabajo para BIND

Aquí se guardarán los archivos firmados y las claves:

chown -R bind:bind /var/cache/bind
chmod 750 /var/cache/bind

Comprobación de permisos

Una incorrecta asignación de permisos hará que BIND no arranque.

sudo -u bind cat /etc/bind/zonas/db.dominio.edu.ar
sudo -u bind touch /var/cache/bind/archivoprueba && rm /var/cache/bind/archivoprueba

Ambos deben tener éxito:

  • El primero debe poder leer la zona sin firmar.

  • El segundo debe poder escribir en ese directorio.

Verifique la sintaxis y reinicie BIND:

named-checkconf
named-checkzone dominio.edu.ar /etc/bind/db.dominio.edu.ar
systemctl restart named

2.3 Consideraciones de red y firewall

Asegúrese de que los puertos DNS (53/UDP y 53/TCP) estén abiertos en su firewall para permitir las consultas DNS. Si está utilizando ufw:

ufw allow 53/udp
ufw allow 53/tcp
ufw enable

También es crucial tener una dirección IP pública estática para su servidor DNS y un nombre de dominio registrado que apunte a esa dirección IP. Este dominio será el que firmaremos con DNSSEC.

Con el entorno preparado y BIND funcionando como servidor autoritativo para su zona, estamos listos para proceder con la generación de claves DNSSEC en la siguiente fase.

3. Configuración de la zona

Una vez que las claves KSK y ZSK han sido generadas, el siguiente paso es configurar BIND para que utilice estas claves y habilite DNSSEC para la zona deseada. Esto implica modificar el archivo de configuración de la zona en BIND y especificar las rutas a las claves.

3.1 Modificación del archivo named.conf.local

Abra el archivo de configuración donde se define su zona. En sistemas Debian/Ubuntu, este suele ser /etc/bind/named.conf.local.

nano /etc/bind/named.conf.local

Dentro de la definición de su zona (zone "dominio.edu.ar" IN { ... };), agregue las siguientes directivas:

zone "dominio.edu.ar" IN {
    type master;
    file "/etc/bind/db.dominio.edu.ar";
    allow-update { none; };
    allow-transfer { 192.168.1.2; }; // IP de servidores esclavos, si los hay

    // Habilitar DNSSEC automático para esta zona
    inline-signing yes;
    dnssec-policy default;
};

Explicación de las directivas:

  • inline-signing yes;: BIND firmará la zona automáticamente generando el archivo .signed

  • dnssec-policy default;: forma moderna (se prefiere en 9.18)

  • IMPORTANTE: No se debe usar el nombre del archivo .signed en la directiva file, porque eso va a fallar con inline-signing.

3.2 Configuración de la política DNSSEC

Aunque dnssec-policy "default"; es un buen punto de partida, es posible que desee definir una política DNSSEC explícita en named.conf.options para tener un control más preciso. Esto es especialmente útil si necesita especificar algoritmos, tiempos de vida de las firmas (TTL) o periodos de rotación de claves.

Abra /etc/bind/named.conf.options:

nano /etc/bind/named.conf.options

Dentro de la sección options { ... };, o en un bloque dnssec-policy { ... }; separado, puede definir una política. Aquí hay un ejemplo de una política personalizada que podría usar:

options {
    // ... otras configuraciones existentes ...

    // Habilitar DNSSEC globalmente y especificar la política
    dnssec-enable yes;
    dnssec-validation auto;

    // Definición de una política DNSSEC personalizada
    dnssec-policy "my_dnssec_policy" {
        keys {
            ksk key-size 4096 algorithm ECDSAP256SHA256 lifetime 1y;
            zsk key-size 2048 algorithm ECDSAP256SHA256 lifetime 3M;
        };
        signing-period 2w;
        refresh-period 1w;
        zone-resign-period 7d;
        nsec3param 1 0 10 100;
        // Otras opciones como 'max-zone-ttl', 'max-zone-ttl-with-nsec3', etc.
    };

    // ... otras configuraciones existentes ...
};

Si define una política personalizada, asegúrese de usarla en la configuración de su zona:

zone "dominio.edu.ar" IN {
    // ...
    dnssec-policy "my_dnssec_policy";
    // ...
};

Puntos clave de la política DNSSEC:

  • keys { ... };: Define las propiedades de las KSK y ZSK, incluyendo tamaño de clave, algoritmo y tiempo de vida.

  • signing-period: Con qué frecuencia se deben volver a firmar los registros de la zona.

  • refresh-period: Cuánto tiempo antes de que expire una firma se debe generar una nueva.

  • zone-resign-period: Con qué frecuencia se debe volver a firmar toda la zona.

  • nsec3param: Parámetros para NSEC3, que proporciona una mejor protección contra la enumeración de zonas.

3.3 Verificación y reinicio de BIND

Después de realizar los cambios en la configuración, verifique la sintaxis de la configuración de BIND y reinicie el servicio:

named-checkconf
systemctl restart named

Si named-checkconf no devuelve errores, la sintaxis es correcta. Si BIND no se inicia o falla después del reinicio, revise los registros del sistema para encontrar la causa del problema:

journalctl -u named -f

Con esta configuración, BIND está ahora preparado para firmar su zona con DNSSEC. En la siguiente fase, procederemos a realizar la firma de la zona.

4. Firma de la zona DNS

Una vez que las claves KSK y ZSK han sido generadas y BIND está configurado para utilizar DNSSEC en la zona, el siguiente paso es firmar la zona. BIND puede realizar la firma de la zona de forma automática, lo cual es el método preferido para la mayoría de las implementaciones, o manualmente utilizando la herramienta dnssec-signzone.

4.1 Firma Automática de la zona con BIND

Si ha configurado la directiva dnssec-policy en named.conf.options (o named.conf) y la ha aplicado a su zona en named.conf.local (como se describió en la Fase 3), BIND se encargará automáticamente de la firma de la zona. Esto incluye la generación de los registros RRSIG, NSEC/NSEC3 y la gestión de la rotación de claves.

Cuando BIND inicia o recarga una zona configurada con una política DNSSEC, buscará las claves en el key-directory (en caso que haya especificado uno) y firmará la zona. Los registros firmados se almacenarán en un nuevo archivo de zona con un nombre como db.dominio.edu.ar.signed o similar, dependiendo de la configuración.

En caso de haber archivos .signed existentes, es recomendable limpiarlos antes de habilitar inline-signing para evitar que BIND intente cargarlos como si fueran zonas “raw”.

Pasos para la firma automática:

  1. Asegúrese de que su archivo de zona original esté correcto. Antes de firmar, verifique que su archivo de zona (/etc/bind/db.dominio.edu.ar) no contenga errores de sintaxis y que todos los registros sean correctos.

    named-checkzone dominio.edu.ar /etc/bind/db.dominio.edu.ar
    

    Salida esperada:

    zone example.com/IN: loaded serial 2025100101
    OK
    
  2. Verifique la configuración de BIND. Asegúrese de que named.conf.options y named.conf.local estén configurados con dnssec-enable yes; y la dnssec-policy adecuada para su zona, así como el key-directory correcto.

    named-checkconf
    
  3. Reinicie BIND. Un reinicio o recarga del servicio BIND activará el proceso de firma de la zona.

    systemctl restart named
    
  4. Compruebe el estado.

    rndc zonestatus dominio.edu.ar
    

    Salida esperada:

    zone: dominio.edu.ar
    type: master
    files: /etc/bind/zonas/db.dominio.edu.ar (/var/cache/bind/dominio.edu.ar.signed)
    dnssec: inline signing configured
    keys: KSK, ZSK (active)
    
  5. Verifique los registros de BIND. Después del reinicio, revise los registros del sistema para confirmar que la zona ha sido firmada correctamente. Busque mensajes relacionados con DNSSEC y la firma de la zona.

    journalctl -u named -f
    

    Debería ver mensajes indicando que la zona ha sido firmada, por ejemplo: zone dominio.edu.ar/IN: sending notifies (serial 2023010101) zone dominio.edu.ar/IN: journal file is not used zone dominio.edu.ar/IN: loaded serial 2023010101 zone dominio.edu.ar/IN: has 2 DNSKEY records zone dominio.edu.ar/IN: NSEC3PARAM (re)generated zone dominio.edu.ar/IN: zone is now signed

4.2 Archivo de zona firmado

Después de unos segundos, BIND creará en /var/cache/bind:

  • dominio.edu.ar.signed → zona firmada (formato raw). Este archivo se gestiona internamente y BIND lo utiliza para responder a las consultas.

  • Archivos de claves → Kdominio.edu.ar.++.key y .private

No es necesario que modifique manualmente el archivo .signed.

4.3 Obtención del registro DS (Delegation Signer)

Para establecer la cadena de confianza, necesitará el registro DS de su KSK. Este registro se generará automáticamente por BIND después de la firma de la zona. Puede obtenerlo utilizando la herramienta dnssec-dsfromkey o buscando en los registros de BIND.

Usando dnssec-dsfromkey:

cd /var/cache/bind
dnssec-dsfromkey -f KSK Kdominio.edu.ar.+<algoritmo>+<ID_clave>.key

Reemplace Kdominio.edu.ar.+<algoritmo>+<ID_clave>.key con el nombre de archivo de la clave pública de su KSK. La salida será similar a esto:

dominio.edu.ar. IN DS <Key Tag> <Algorithm> <Digest Type> <Digest>

Salida esperada:

dominio.edu.ar. IN DS 12345 13 2 1234567890abcdef1234567890abcdef1234567890abcdef1234567890

Anote este registro DS, ya que lo necesitará en la siguiente fase para publicarlo en su registrador de dominios.

Con la zona firmada y el registro DS obtenido, la cadena de confianza DNSSEC está casi completa. El último paso crucial es publicar este registro DS en la zona padre a través de su registrador.

5. Publicación de registros DS en el registrador

La publicación del registro DS (Delegation Signer) es el paso más crítico para establecer la cadena de confianza de DNSSEC. Sin este registro en la zona padre, los validadores DNSSEC no podrán verificar la autenticidad de su zona. Este paso se realiza a través de su registrador de dominios.

5.1 Entendiendo el Registro DS

El registro DS contiene un hash criptográfico de la clave pública de su KSK (Key Signing Key). Cuando un resolver DNSSEC intenta validar su zona, primero consulta el registro DS en la zona padre (por ejemplo, el TLD .com para dominio.edu.ar). Si el hash en el registro DS coincide con el hash de la KSK que se encuentra en su zona, la cadena de confianza se establece y el resolver puede confiar en las firmas de su zona.

El formato del registro DS que obtuvo en la Fase 5 es similar a este:

dominio.edu.ar. IN DS <Key Tag> <Algorithm> <Digest Type> <Digest>

Donde:

  • <Key Tag>: Un identificador numérico para la KSK.

  • <Algorithm>: El algoritmo criptográfico utilizado por la KSK (por ejemplo, 13 para ECDSAP256SHA256).

  • <Digest Type>: El tipo de algoritmo hash utilizado para el resumen (por ejemplo, 2 para SHA256).

  • <Digest>: El valor hash real de la clave pública de la KSK.

5.2 Proceso de publicación en el registrador

El proceso exacto para publicar el registro DS varía según el registrador de dominios. Generalmente, deberá iniciar sesión en el panel de control de su registrador y buscar una sección relacionada con DNSSEC o gestión de nombres de servidor. A menudo, se le pedirá que introduzca los valores individuales del registro DS.

Pasos generales:

  1. Inicie sesión en el panel de control de su registrador de dominios.

  2. Navegue a la sección de gestión de DNS o DNSSEC para su dominio (dominio.edu.ar).

  3. Busque la opción para añadir un registro DS o habilitar DNSSEC.

  4. Introduzca los valores del registro DS que obtuvo en la Fase 5. Es posible que el registrador le pida los campos por separado:

    • Key Tag (Etiqueta de clave)

    • Algorithm (Algoritmo)

    • Digest Type (Tipo de resumen)

    • Digest (Resumen)

    Algunos registradores pueden permitirle pegar la línea completa del registro DS.

  5. Guarde los cambios.

Ejemplo de cómo se vería en un registrador (los campos pueden variar):

Campo

Valor

Key Tag

12345

Algorithm

13 (ECDSAP256SHA256)

Digest Type

2 (SHA256)

Digest

1234567890abcdef1234567890abcdef1234567890abcdef1234567890

5.3 Propagación del registro DS

Una vez que haya publicado el registro DS, puede tardar algún tiempo en propagarse a través del sistema DNS global. Este proceso puede llevar desde unos minutos hasta varias horas, dependiendo de los TTL (Time To Live) de los registros DNS de la zona padre y de la eficiencia de los servidores DNS.

Puede verificar la propagación de su registro DS utilizando herramientas en línea como DNSViz o Verificador de DNSSEC de ICANN. Simplemente introduzca su nombre de dominio y estas herramientas le mostrarán el estado de la cadena de confianza DNSSEC.

Una vez que el registro DS se haya propagado y sea visible públicamente, su zona estará completamente protegida por DNSSEC. En la siguiente fase, verificaremos la implementación de DNSSEC para asegurarnos de que todo funciona como se espera.

6. Verificación de la implementación

Una vez que ha configurado BIND para DNSSEC, ha firmado su zona y ha publicado el registro DS en su registrador, es crucial verificar que la implementación es correcta y que la cadena de confianza está establecida. Esta fase detalla cómo utilizar herramientas de línea de comandos y servicios en línea para confirmar el funcionamiento de DNSSEC.

6.1 Verificación con dig

La herramienta dig es fundamental para diagnosticar problemas de DNS. Para verificar DNSSEC, puede usar la opción +dnssec y +multi.

dig dominio.edu.ar +dnssec +multi

Qué buscar en la salida:

  • AD flag (Authenticated Data): Si ve ad en la sección HEADER (por ejemplo, ;; flags: qr rd ra ad;), significa que el resolver que consultó ha validado la respuesta DNSSEC y la considera auténtica. Si su propio servidor BIND está configurado como validador, debería ver esta bandera.

  • Registros RRSIG: Debería ver registros RRSIG para cada tipo de registro (SOA, NS, A, AAAA, etc.) en la sección ANSWER SECTION. Esto indica que los registros están firmados.

  • Registros DNSKEY: Debería ver registros DNSKEY en la sección ANSWER SECTION, que corresponden a sus KSK y ZSK.

  • Registros NSEC/NSEC3: Si ha configurado NSEC3, verá estos registros, que prueban la inexistencia de nombres de dominio.

Si no ve la bandera ad o los registros DNSSEC esperados, es posible que su resolver local no esté validando DNSSEC o que haya un problema en la configuración de su zona.

6.2 Verificación con delv

delv (DNSSEC Lookaside Validation) es una herramienta más avanzada que dig para la depuración de DNSSEC, ya que realiza la validación DNSSEC de forma explícita. Es parte del paquete bind9utils.

delv @localhost dominio.edu.ar

Qué buscar en la salida:

  • delv intentará construir una cadena de confianza desde la raíz hasta su dominio. Si la validación es exitosa, verá mensajes como ;; fully validated o ;; secure.

  • Si hay problemas, delv proporcionará detalles sobre dónde falla la cadena de confianza, lo que es invaluable para la depuración.

6.3 Uso de herramientas en línea

Existen varias herramientas en línea que pueden verificar el estado de DNSSEC de su dominio. Son muy útiles para obtener una vista externa y confirmar que la cadena de confianza es válida desde Internet.

  • DNSViz: Una herramienta visual que muestra la cadena de confianza DNSSEC para su dominio. Es excelente para identificar problemas en la delegación o en la firma de la zona. Simplemente ingrese su dominio y analice el gráfico.

    • URL: https://dnsviz.net/

  • Verificador de DNSSEC de ICANN: Otra herramienta útil que comprueba el estado de DNSSEC de su dominio y proporciona un informe detallado.

    • URL: https://dnssec-analyzer.verisignlabs.com/

6.4 Verificación de los registros DS en la zona padre

También puede verificar que su registrador ha publicado correctamente el registro DS en la zona padre. Esto se puede hacer consultando los servidores de nombres del TLD (Top-Level Domain) de su dominio.

dig dominio.edu.ar ds @a.gtld-servers.net +short

Reemplace a.gtld-servers.net con uno de los servidores de nombres raíz o TLD relevantes para su dominio. Debería ver el registro DS que publicó en su registrador.

6.5 Monitoreo continuo

Una vez que DNSSEC está implementado, es importante monitorear su estado, especialmente la rotación de claves y la validez de las firmas. BIND gestiona esto automáticamente con la dnssec-policy, pero es bueno revisar los registros periódicamente y utilizar herramientas de monitoreo para alertar sobre posibles problemas.

7 Actualización de la zona

Cuando agregue o modifiques registros en /etc/bind/zonas/db.dominio.edu.ar:

  • Incremente el serial en el SOA.

  • Verifique la zona:

named-checkzone dominio.edu.ar /etc/bind/zonas/db.dominio.edu.ar
  • Recargue:

sudo rndc reload dominio.edu.ar

BIND re-firmará automáticamente los nuevos registros y actualizará la versión .signed.