Configuración de servidor de nombres de dominio (DNS) con BIND

Autor: Joel Barrios Dueñas
Correo electrónico: darkshram en gmail punto com
Sitio de Red: https://www.alcancelibre.org

Licencia Creative Commons
© 1999-2026 Joel Barrios Dueñas. Este manual se distribuye bajo la licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual 4.0 Internacional (CC BY-NC-SA 4.0). Usted es libre de compartir y adaptar el material bajo los siguientes términos: debe dar crédito al autor, no puede utilizarlo para fines comerciales y debe compartir las obras derivadas bajo la misma licencia. La licencia completa está disponible en https://creativecommons.org/licenses/by-nc-sa/4.0/legalcode.es.

Este manual proporciona una guía completa para la configuración y administración de servidores de nombres de dominio (DNS) utilizando BIND, el servidor DNS más extendido en el mundo del equipamiento lógico libre. Cubre desde conceptos básicos hasta configuraciones avanzadas de seguridad, incluyendo la protección contra ataques DDoS mediante vistas (views) y la configuración de transferencias seguras de zona con TSIG.

Introducción a los servidores DNS

El sistema de nombres de dominio (DNS por sus siglas en inglés) es un componente fundamental de Internet que traduce nombres de dominio legibles por humanos (como www.alcancelibre.org) en direcciones IP numéricas (como 192.168.100.2) que las computadoras utilizan para comunicarse. Un servidor DNS es responsable de responder a estas consultas de resolución de nombres.

Existen varios tipos de servidores DNS: primarios (maestros), secundarios (esclavos) y caché. BIND (Berkeley Internet Name Domain) es la implementación de referencia de DNS, ampliamente utilizada en servidores de todo el mundo. Este manual se enfoca en distribuciones Linux modernas como ALDOS, AlmaLinux, Rocky Linux y Red Hat Enterprise Linux, utilizando tanto yum como dnf para la gestión de paquetes según corresponda.

Instalación del servicio BIND

Para instalar el servidor BIND en distribuciones basadas en Red Hat, ejecute el siguiente mandato:

dnf install bind bind-utils

En distribuciones que aún utilizan yum, como ALDOS, el mandato es:

yum install bind bind-utils

El paquete bind-utils incluye herramientas esenciales para la administración y prueba del servidor DNS, como dig, nslookup y host.

Tras la instalación, es recomendable detener e inhabilitar temporalmente el servicio hasta completar la configuración inicial:

service named stop
chkconfig named off

Estructura de archivos de configuración

El archivo de configuración principal de BIND es /etc/named.conf. Este archivo define las opciones globales del servidor, las vistas de seguridad y las zonas de dominio que el servidor administra. La estructura de directorios principal para BIND es /var/named/, donde se almacenan los archivos de zona y datos de caché.

Para mantener una organización clara, se recomienda crear un subdirectorio /var/named/data/ para almacenar los archivos de zona específicos del dominio:

mkdir -p /var/named/data
chown named:named /var/named/data
restorecon -R /var/named

Configuración básica del archivo /etc/named.conf

La plantilla de configuración básica y segura para /etc/named.conf es la siguiente. Esta plantilla elimina directivas obsoletas, habilita la validación DNSSEC de manera automática y establece una estructura de vistas para separar el tráfico interno del externo:

options {
    directory "/var/named";
    dump-file "/var/named/data/cache_dump.db";
    statistics-file "/var/named/data/named_stats.txt";
    memstatistics-file "/var/named/data/named_mem_stats.txt";
    forwarders { 8.8.8.8; 8.8.4.4; };
    forward first;
    dnssec-validation auto;
};

include "/etc/rndc.key";

controls { inet 127.0.0.1 allow { 127.0.0.1; } keys { "rndc-key"; }; };

logging { channel default_debug { file "data/named.run"; severity dynamic; }; category lame-servers { null; }; };

view "internal" {
    match-clients { 127.0.0.0/8; 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; };
    recursion yes;
    include "/etc/named.rfc1912.zones";
    // ZONAS LOCALES AÑADIR AQUÍ (ej: zone "midominio.local" {...})
};

view "external" {
    match-clients { any; };
    recursion no;
    // ZONAS PÚBLICAS AÑADIR AQUÍ
};

Creación de zonas de dominio maestras

Una zona de dominio es una porción del espacio de nombres DNS que un servidor administra. Para crear una zona maestra, primero se define en /etc/named.conf y luego se crea el archivo de zona correspondiente en /var/named/data/.

Definición de zona directa (de nombre a IP)

Añada la siguiente declaración dentro de la vista internal de /etc/named.conf para una zona interna:

zone "ejemplo.local" IN {
    type master;
    file "data/ejemplo.local.zone";
    allow-update { none; };
    allow-transfer { 192.168.100.10; }; // IP del servidor secundario, si existe
};

Creación del archivo de zona directa

Cree el archivo /var/named/data/ejemplo.local.zone con el siguiente contenido. Asegúrese de actualizar el número de serie (serial) al formato AAAAMMDDXX cada vez que modifique el archivo:

$TTL 86400
@       IN SOA  ns1.ejemplo.local. admin.ejemplo.local. (
                2025122301      ; Serial (AAAAMMDDXX)
                28800           ; Refresh
                7200            ; Retry
                604800          ; Expire
                86400           ; Minimum TTL
                )

            IN NS   ns1.ejemplo.local.
            IN NS   ns2.ejemplo.local.
            IN MX   10 mail.ejemplo.local.

ns1         IN A    192.168.100.2
ns2         IN A    192.168.100.10
mail        IN A    192.168.100.20
www         IN A    192.168.100.30
gateway     IN A    192.168.100.254

Definición de zona inversa (de IP a nombre)

Para la resolución inversa del bloque 192.168.100.0/24, añada en /etc/named.conf:

zone "100.168.192.in-addr.arpa" IN {
    type master;
    file "data/100.168.192.in-addr.arpa.zone";
    allow-update { none; };
};

Creación del archivo de zona inversa

Cree el archivo /var/named/data/100.168.192.in-addr.arpa.zone:

$TTL 86400
@       IN SOA  ns1.ejemplo.local. admin.ejemplo.local. (
                2025122301      ; Serial
                28800           ; Refresh
                7200            ; Retry
                604800          ; Expire
                86400           ; Minimum TTL
                )

            IN NS   ns1.ejemplo.local.
            IN NS   ns2.ejemplo.local.

2           IN PTR  ns1.ejemplo.local.
10          IN PTR  ns2.ejemplo.local.
20          IN PTR  mail.ejemplo.local.
30          IN PTR  www.ejemplo.local.
254         IN PTR  gateway.ejemplo.local.

Verificación de sintaxis y permisos

Antes de iniciar el servicio, es crucial verificar la sintaxis de los archivos de configuración y zona, y asegurar los permisos correctos.

Para verificar la sintaxis de named.conf:

named-checkconf /etc/named.conf

Para verificar la sintaxis de un archivo de zona:

named-checkzone ejemplo.local /var/named/data/ejemplo.local.zone

Asegure los permisos adecuados para los archivos de zona:

chown named:named /var/named/data/*
chmod 640 /var/named/data/*
restorecon -R /var/named

Inicio del servicio y pruebas básicas

Inicie el servicio named y habilítelo para que arranque automáticamente con el sistema:

service named start
chkconfig named on

Verifique el estado del servicio:

service named status

Realice una consulta local utilizando dig para probar la resolución de nombres:

dig @localhost ns1.ejemplo.local

Para probar la resolución inversa:

dig @localhost -x 192.168.100.2

Seguridad con vistas (views) y protección contra DDoS

La configuración de vistas (views) en BIND permite ofrecer respuestas diferentes según la dirección IP del cliente que realiza la consulta. Ésto es fundamental para separar el acceso interno (con recursión habilitada) del acceso externo (sólo para zonas públicas y sin recursión), mitigando así el riesgo de que el servidor sea utilizado en ataques de amplificación DDoS.

Un ataque DDoS (Denegación de Servicio Distribuida) puede aprovechar servidores DNS abiertos (que permiten recursión a cualquiera) para amplificar el tráfico dirigido a una víctima. La herramienta DNS Report advierte sobre este riesgo con un mensaje similar a:

«ERROR: One or more of your nameservers reports that it is an open DNS server... The bad guys could use your DNS server as part of an attack»

La solución es implementar vistas que restrinjan la recursión únicamente a las redes de confianza (por ejemplo, las redes privadas RFC 1918). La plantilla de configuración presentada al inicio de este manual ya incluye esta estructura básica.

Ejemplo avanzado con zonas públicas y privadas

El siguiente ejemplo muestra una configuración donde:

options {
    directory "/var/named";
    dump-file "/var/named/data/cache_dump.db";
    statistics-file "/var/named/data/named_stats.txt";
    memstatistics-file "/var/named/data/named_mem_stats.txt";
    forwarders { 8.8.8.8; 8.8.4.4; };
    forward first;
    dnssec-validation auto;
};

include "/etc/rndc.key";
controls { inet 127.0.0.1 allow { 127.0.0.1; } keys { "rndc-key"; }; };

logging { channel default_debug { file "data/named.run"; severity dynamic; }; };

view "external" {
    match-clients { any; };
    recursion no;
    zone "midominio.com" {
        type master;
        file "data/midominio.com.zone";
        allow-update { none; };
        allow-transfer {
            192.168.100.2; // Dirección IP del propio servidor maestro. Permite operaciones de administración
            203.0.113.2;
            203.0.113.1;
        };
    };
};

view "internal" {
    match-clients { 127.0.0.0/8; 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; };
    recursion yes;
    include "/etc/named.rfc1912.zones";
    zone "midominio.com" {
        type master;
        file "data/midominio.com.zone";
        allow-update { none; };
    };
    zone "mired.local" {
        type master;
        file "data/mired.local.zone";
        allow-update { none; };
        allow-transfer {
            192.168.100.2;
            192.168.100.10;
        };
    };
};

⚠️ Nota sobre la sintaxis de direcciones en listas de control de acceso

Es crucial recordar que, en directivas como allow-transfer, allow-update, masters o match-clients, cuando se especifica un anfitrión individual, se debe utilizar únicamente su dirección IP, sin la máscara de red (/24, /32, etc.). La notación CIDR (p.ej., 192.168.100.239/24) está reservada para definir bloques o redes completas en contextos donde ésto es aceptado, como en la definición de una ACL para match-clients.

BIND rechazará una dirección con máscara en un contexto donde espera un host, mostrando un error de sintaxis al recargar la configuración. Para evitar este error común, especifique siempre las direcciones IP de hosts de manera individual:

// ❌ INCORRECTO - Causará error de sintaxis
allow-transfer { 192.168.100.239/24; 192.168.100.240/24; };

// ✅ CORRECTO - Direcciones IP individuales
allow-transfer { 192.168.100.239; 192.168.100.240; };

La excepción a esta regla es cuando se define una red completa para filtrar clientes, por ejemplo, dentro de la directiva match-clients de una vista, donde el uso de 192.168.100.0/24 sí es válido y necesario.

Restricción de consultas con allow-query para DNS local

Para servidores destinados exclusivamente a una red local, se puede restringir aún más el acceso utilizando la directiva allow-query a nivel de vista o de zona, en lugar de confiar sólo en match-clients. También se pueden definir listas de control de acceso (ACL) para mayor claridad.

acl "redes-permitidas" {
    127.0.0.0/8;
    10.0.0.0/8;
    172.16.0.0/12;
    192.168.100.0/24;
    // Puede añadir IPs específicas: 192.168.100.100;
};

view "internal" {
    match-clients { "redes-permitidas"; };
    recursion yes;
    allow-query { "redes-permitidas"; };
    include "/etc/named.rfc1912.zones";
    // Definición de zonas locales...
};

Configuración de servidores DNS secundarios (zonas esclavas)

Los servidores DNS secundarios proporcionan redundancia y balanceo de carga. Una zona esclava (slave) obtiene sus datos mediante transferencia de zona (AXFR/IXFR) desde un servidor maestro.

🧪 Escenario de ejemplo: Configuración maestro-esclavo para un dominio en producción

A continuación, se presenta un ejemplo práctico inspirado en plantillas de proveedores como EasyDNS. Este esquema es común cuando usted aloja el servidor maestro de DNS en su infraestructura (ns1.suempresa.test) y contrata a un proveedor externo para que actúe como servidor esclavo de redundancia (ns2.proveedor-dns.externo).

Configuración en el servidor maestro (/etc/named.conf):

zone "suempresa.test" {
    type master;
    file "data/suempresa.test.zone";
    allow-update { none; };
    allow-transfer {
        192.168.100.2;
        203.0.113.10;  // Dirección IP del servidor esclavo externo autorizado.
    };
    also-notify { 203.0.113.10; }; // Notifica automáticamente al esclavo cuando la zona se actualiza.
};

Puntos clave ilustrados en este ejemplo:

  1. allow-transfer incluye la IP propia: La dirección 192.168.100.2 permite realizar transferencias de zona (AXFR) y consultas de depuración desde el propio servidor maestro, una práctica común para validación interna.
  2. allow-transfer incluye la IP del esclavo: La dirección 203.0.113.10 autoriza explícitamente al servidor del proveedor externo a realizar transferencias de zona.
  3. also-notify: Esta directiva asegura que el servidor esclavo sea notificado inmediatamente tras cualquier cambio en la zona, acelerando la propagación de actualizaciones sin esperar al ciclo de refresco.

Este ejemplo concreto refuerza la filosofía de lista blanca y proporciona un modelo claro que los estudiantes pueden adaptar para integrar sus servidores con servicios externos de DNS secundario.

Configuración en el servidor primario (maestro)

En la definición de la zona dentro de named.conf, se especifican las IPs de los servidores secundarios autorizados para transferir la zona:

zone "midominio.com" {
    type master;
    file "data/midominio.com.zone";
    allow-update { none; };
    allow-transfer {
    127.0.0.1;      # Permite transferencias/consultas desde el propio servidor (localhost)
    localnets;      # Permite desde cualquier interfaz de red local del servidor (opcional, pero útil)
    192.168.100.11; # IP del servidor esclavo 1
    192.168.100.12; # IP del servidor esclavo 2
    # También podría añadirse: 192.168.100.2; # Su IP específica, aunque localnets suele cubrirla
};
    also-notify { 192.168.100.11; 192.168.100.12; }; // Notificar cambios
};

Configuración en el servidor secundario (esclavo)

En el servidor secundario, la zona se define como slave y se apunta al maestro:

zone "midominio.com" {
    type slave;
    file "data/midominio.com.zone";
    masters { 192.168.100.2; }; // IP del servidor primario
    allow-transfer { none; }; // Por defecto, prohibir transferencias desde este esclavo
};

Seguridad avanzada para transferencias de zona con TSIG

Utilizar direcciones IP para autorizar transferencias de zona supone un riesgo, ya que las IPs pueden ser falsificadas (spoofed). El método robusto consiste en usar firmas de transacción TSIG (Transaction SIGnature), que emplean una clave secreta compartida para autenticar las transferencias entre servidores.

Generación de la clave TSIG

En el servidor primario (o en una máquina segura), genere una clave HMAC-MD5 (u otro algoritmo soportado) con dnssec-keygen o tsig-keygen:

dnssec-keygen -a HMAC-MD5 -b 128 -n HOST transfer-key

Este mandato generará dos archivos: Ktransfer-key.+157+XXXXX.key y Ktransfer-key.+157+XXXXX.private. La clave secreta es la cadena después de Key: en el archivo .private (por ejemplo, tPy4Z6ZqLhYpJpBkQ+K1tA==).

Mueva y proteja los archivos de clave:

mv Ktransfer-key.* /var/named/data/
chown named:named /var/named/data/Ktransfer-key.*
chmod 400 /var/named/data/Ktransfer-key.*

Configuración en el servidor primario

Incluya la definición de la clave en /etc/named.conf (o en un archivo incluido) y refiérase a ella en la directiva allow-transfer:

key "transfer-key" {
    algorithm hmac-md5;
    secret "tPy4Z6ZqLhYpJpBkQ+K1tA==";
};

zone "midominio.com" {
    type master;
    file "data/midominio.com.zone";
    allow-update { none; };
    allow-transfer { key "transfer-key"; };
};

Configuración en el servidor secundario

El servidor secundario debe tener la misma clave definida y especificar que la usará para comunicarse con el primario:

key "transfer-key" {
    algorithm hmac-md5;
    secret "tPy4Z6ZqLhYpJpBkQ+K1tA==";
};

server 192.168.100.2 { // IP del primario
    keys { "transfer-key"; };
};

zone "midominio.com" {
    type slave;
    file "data/midominio.com.zone";
    masters { 192.168.100.2; };
};

Supervisión y depuración del servicio

La supervisión de los registros (logs) es esencial para detectar problemas y confirmar el correcto funcionamiento. El archivo principal de registro se define en named.conf y suele ser /var/named/data/named.run.

Para seguir los eventos del servicio en tiempo real:

tail -f /var/log/messages | grep named

Tras modificar una zona, incremente el número de serie en el archivo de zona y recargue el servicio:

service named reload

Para verificar que las zonas se han cargado correctamente, busque en los registros líneas como:

zone midominio.com/IN: loaded serial 2025122301

Para probar las transferencias de zona desde un secundario, puede forzar una con rndc:

rndc retransfer midominio.com

Integración con otros servicios de red

Un servidor DNS configurado de manera segura es la base para otros servicios de red. Los siguientes manuales de Alcance Libre complementan este conocimiento:

La importancia de la validación de configuración DNS

Un servidor DNS configurado de manera funcional es el primer paso; uno configurado conforme a los estándares y mejores prácticas es el sello de un administrador profesional. En el contexto actual, donde la reputación de un dominio influye directamente en la entrega del correo electrónico y el posicionamiento en servicios en línea, la configuración de DNS debe superar el criterio de «funciona» para aspirar a «está óptimamente configurado».

📊 Validación de configuración DNS y reputación del dominio

La configuración funcional de un servidor DNS es el primer paso; su configuración conforme a los estándares y mejores prácticas establece la diferencia entre un servicio básico y uno profesional. En el contexto actual, donde la reputación de un dominio influye directamente en la entrega de correo electrónico y la accesibilidad de los servicios, es imperativo que la configuración supere el criterio de «funciona» para aspirar a «está configurado de manera óptima».

El rol de las herramientas de validación externa

Servicios de diagnóstico como MXToolbox, DNSViz o los verificadores de integridad de registradores actúan como auditores objetivos. Su propósito es comprobar que todos los registros esenciales (SOA, NS, A, MX, SPF, DKIM, DMARC) existen, son coherentes, están propagados correctamente y carecen de errores comunes que puedan afectar la seguridad o disponibilidad.

🧪 El principio de la configuración validada

Un dominio que aprueba al 100% estas validaciones logra dos objetivos clave: primero, goza de una reputación técnica superior frente a servicios externos (como proveedores de correo o motores de búsqueda); y segundo, establece una línea base de operación confiable. Esta base sólida desplaza la responsabilidad operativa con claridad ante cualquier incidencia: si surge un problema de entrega de correo o acceso, el administrador puede descartar con certeza los errores de configuración local y focalizar la investigación de manera precisa en el extremo remoto —ya sea en listas negras, problemas del proveedor del destinatario o configuraciones inadecuadas del cliente—.

La experiencia en campo es concluyente: un administrador cuyo dominio pasa todas las validaciones puede demostrar con solvencia que la infraestructura bajo su custodia opera conforme a estándares. Esto dista de ser un tecnicismo; es una práctica profesional que evita pérdidas de tiempo en diagnósticos infundados y construye credibilidad técnica. El objetivo último es asegurar que el sistema propio esté tan bien configurado que su excelencia operativa sea incuestionable.

Beneficios concretos de una configuración validada

Se recomienda encarecidamente utilizar estas herramientas de validación de manera sistemática tras cualquier modificación en la configuración DNS. Esta práctica debe integrarse al flujo de trabajo de administración, sin tratarla como una comprobación final opcional. En un entorno donde la conectividad y la reputación son críticas, la excelencia en la configuración constituye la norma, jamás la excepción.

Conclusión

La correcta configuración de un servidor DNS con BIND involucra además de la resolución básica de nombres, sino también la implementación de medidas de seguridad robustas como las vistas para aislar el tráfico, la restricción de consultas recursivas y el uso de TSIG para transferencias de zona autenticadas. Estos principios protegen la infraestructura de red contra abusos y ataques, garantizando un servicio confiable y seguro para usuarios internos y externos. La utilización coherente del bloque de direcciones 192.168.100.0/24 a lo largo de los manuales facilita la integración práctica de estos servicios en un laboratorio o entorno de producción.