Introducción al protocolo DNS.

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.

Introducción.

Este manual proporciona una base sólida sobre el protocolo DNS (Sistema de Nombres de Dominio), combinando teoría esencial con práctica aplicada. Aprenderá los conceptos fundamentales ―como FQDN, tipos de registros y consultas― y procederá a implementar un servidor DNS funcional utilizando BIND en distribuciones modernas, con soporte completo para AlmaLinux/Rocky Linux (systemd, dnf) y ALDOS (SysVinit, yum).

Para escenarios de redes locales o entornos de prueba donde la simplicidad es prioritaria, considere DNSMasq como una alternativa ligera.

Conceptos.

Comprender la teoría detrás del Sistema de Nombres de Dominio constituye el cimiento indispensable para cualquier tarea de configuración, resolución de problemas o administración avanzada de redes. Esta sección desglosa sus componentes, flujos y terminología clave.

Acerca del protocolo DNS (Domain Name System).

DNS (acrónimo de Domain Name System) es una base de datos distribuida y jerárquica, que almacena la información necesaria para los nombres de dominio. Sus usos principales son la asignación de nombres de dominio a direcciones IP y la localización de los servidores de correo electrónico correspondientes para cada dominio. El DNS nació de la necesidad de facilitar a las personas el acceso hacia los servidores disponibles a través de Internet, permitiendo utilizar un nombre ―algo más fácil de recordar― en lugar de una dirección IP numérica.

Los Servidores DNS utilizan TCP y UDP, en el puerto 53 para responder las consultas. La inmensa mayoría de las consultas consisten en una sola solicitud UDP desde un Cliente DNS, seguida por una sola respuesta UDP del servidor. Se realiza una conexión TCP cuando el tamaño de los datos de la respuesta excede los 512 bytes, tal como ocurre con tareas como la transferencia de zonas.

¿Qué es un NIC (Network Information Center)?

NIC (acrónimo de Network Information Center o Centro de Información sobre la Red) es una institución encargada de asignar los nombres de dominio en Internet, ya sean nombres de dominio genéricos o por países, permitiendo a personas o empresas publicar sitios web a través de un ISP, mediante un DNS. Técnicamente existe un NIC por cada país en el mundo y cada uno de éstos es responsable por todos los dominios con la terminación correspondiente a su país. Por ejemplo: NIC México es la entidad encargada de gestionar todos los dominios con terminación .mx.

La información publicada por los NIC es consultada con la herramienta whois.

¿Qué es un FQDN (Fully Qualified Domain Name)?

Un FQDN (Fully Qualified Domain Name o Nombre de Dominio Plenamente Calificado) es la dirección postal completa e inequívoca de un dispositivo en Internet o en una red privada. A diferencia de un nombre simple, el FQDN especifica la ubicación absoluta y única del dispositivo dentro de la jerarquía global del sistema de nombres de dominio (DNS).

Piense en el nombre de un equipo, «servidor1». En una red, podrían existir muchos equipos con ese nombre. Sin embargo, su FQDN —por ejemplo, «servidor1.dominio.com.»— lo define de manera única en todo el ámbito del dominio «dominio.com». La clave que lo convierte en un FQDN es el punto final (.), que indica la raíz absoluta de la jerarquía DNS.

Por qué el punto final es esencial:

Reglas técnicas: Un FQDN válido debe cumplir con las siguientes características:

Nota sobre internacionalización: Para soportar caracteres de idiomas globales (como la ñ o caracteres acentuados), existe el estándar IDN (Internationalized Domain Name). Este sistema codifica de manera segura estos caracteres dentro del formato estándar de FQDN, lo que permite direcciones web más inclusivas y accesibles.

Conclusión simple para recordar:

Un FQDN es el nombre completo, único y absoluto de un anfitrión en la red, y siempre incluye un punto al final.

Componentes de DNS.

El protocolo DNS opera a través de tres componentes: Clientes DNS, Servidores DNS y Zonas de Autoridad.

Clientes DNS.

Son todos aquellos programas que ejecuta un usuario y que generan peticiones de consulta para resolver nombres y direcciones IP. Básicamente preguntan por la dirección IP que corresponde a un nombre determinado. Prácticamente todas las aplicaciones que requieren definir un nombre de anfitrión entre sus argumentos se consideran clientes DNS.

Por ejemplo: un cliente SSH ―aún siendo cliente de otro protocolo― realiza una consulta de DNS para determinar la dirección IP de un servidor al cual se va a conectar.

Servidores DNS.

Son servicios que contestan las consultas realizadas por los Clientes DNS. Hay dos tipos de servidores de nombres:

¿Cuántos servidores DNS debe haber para resolver un dominio?

Un gran número de problemas de operación de servidores DNS se atribuyen a las pobres opciones de servidores secundarios para las zonas de DNS. De acuerdo al RFC 2182, el DNS requiere que al menos tres servidores existan para todos los dominios delegados (o zonas).

Una de las principales razones para tener al menos tres servidores para cada zona, es permitir que la información de la zona misma esté disponible siempre y de forma confiable, hacia los Clientes DNS, a través de Internet cuando un servidor DNS de dicha zona falle, esté fuera de servicio y/o esté inalcanzable.

Contar con múltiples servidores también facilita la propagación de la zona y mejora la eficiencia del sistema en general al brindar opciones a los Clientes DNS si acaso encontraran dificultades para realizar una consulta en un Servidor DNS. En otras palabras: tener múltiples servidores para una zona permite contar con redundancia y respaldo del servicio.

Con múltiples servidores, por lo general uno actúa como Servidor Maestro o Primario y los demás como Servidores Esclavos o Secundarios. Correctamente configurados y una vez creados los datos para una zona, es innecesario copiarlos a cada Servidor Esclavo o Secundario, pues éste se encargará de transferir los datos de manera automática cada vez que sea necesario.

Tipos de consultas hacia un servidor DNS.

Los Servidores DNS responden dos tipos de consultas:

Zonas de Autoridad.

Éstas permiten al Servidor Maestro o Primario cargar la información de una zona. Cada Zona de Autoridad abarca al menos un dominio y ―posiblemente― sus sub-dominios, cuando estos últimos son imposibles de delegar a otras zonas de autoridad.

Las zonas de autoridad se crean en archivos de texto simple o registros de una base de datos. Deben incluir el tiempo total de vida (TTL) predeterminado, la información del servidor DNS principal y los registros que componen la zona. El contenido mínimo de éstos archivos debe ser el siguiente:

$TTL 3600
@       IN      SOA     ns1.ejemplo.lan.    admin.ejemplo.lan. (
                        2025122201  ; número de serie. Se recomienda sea en formato de fecha.
                        7200        ; tiempo de refresco del registro SOA.
                        900         ; tiempo a esperar entre un intento de consulta fallido y otro.
                        1209600     ; caducidad del registro SOA en otros servidores DNS.
                        3600        ; tiempo total de vida del registro SOA en otros servidores DNS.
                        )
@       IN      NS      ns1.ejemplo.lan.

A continuación se explican los registros usado arriba y el resto de los tipos de registro que se pueden utilizar.

Tipos de registros en la zonas de autoridad.

La información de cada Zona de Autoridad es almacenada de forma local en un archivo en el Servidor DNS. Este archivo puede incluir varios tipos de registros:

Tipo de Registro. Descripción.
A (Address) Registro de dirección que resuelve un nombre de un anfitrión hacia una dirección IPv4 de 32 bits.
AAAA Registro de dirección que resuelve un nombre de un anfitrión hacia una dirección IPv6 de 128 bits.
CNAME (Canonical Name) Registro de nombre canónico que hace que un nombre sea alias de otro. Los dominios con alias obtienen los sub-dominios y registros DNS del dominio original.
MX (Mail Exchanger) Registro de servidor de correo que sirve para definir una lista de servidores de correo para un dominio, así como la prioridad entre éstos.
PTR (Pointer) Registro de apuntador que resuelve direcciones IPv4 hacia los nombres anfitriones. Es decir, hace lo contrario al registro A. Se utiliza en zonas de Resolución Inversa.
NS (Name Server) Registro de servidor de nombres, que sirve para definir una lista de servidores de nombres con autoridad para un dominio.
SOA (Start of Authority) Registro de inicio de autoridad, encargado de especificar el Servidor DNS Maestro (o Primario) que proporcionará la información con autoridad acerca de un dominio de Internet, dirección de correo electrónico del administrador, número de serie del dominio y parámetros de tiempo para la zona.
SRV (Service) Registros de servicios, encargados de especificar información acerca de servicios disponibles a través del dominio. Protocolos como SIP (Session Initiation Protocol) y XMPP (Extensible Messaging and Presence Protocol) suelen requerir registros SRV en la zona para proporcionar información a los clientes.
TXT (Text) Registros de texto, encargados de permitir al administrador insertar texto arbitrariamente en un registro DNS. Este tipo de registro es muy utilizado por los servidores de listas negras DNSBL (DNS-based Blackhole List) para la filtración de Spam. Otro ejemplo de uso sería el caso de las VPN, donde suele requerirse un registro TXT, para definir una firma digital que será utilizada por los clientes.

Tipos de zonas de autoridad.

Las zonas que se pueden resolver son:

Zonas de Reenvío. Devuelven direcciones IP para las búsquedas hechas para nombres FQDN (Fully Qualified Domain Name).

En el caso de dominios públicos, la responsabilidad de que exista una Zona de Autoridad para cada Zona de Reenvío, corresponde a la autoridad misma del dominio, es decir quien esté registrado como autoridad del dominio la base de datos WHOIS donde esté registrado el dominio. Quienes adquieren dominios a través de un NIC (por ejemplo: www.nic.mx), son quienes deben hacerse cargo de las Zonas de Reenvío ya sea a través de su propio Servidor DNS o bien a través de los Servidores DNS de su ISP.

Salvo que se trate de un dominio para uso en una red local, todo dominio debe ser primero tramitado con un NIC, como requisito para tener derecho legal a utilizarlo y poder propagarlo a través de Internet.

Zonas de Resolución Inversa. Devuelven nombres FQDN (Fully Qualified Domain Name) para las búsquedas hechas para direcciones IP.

En el caso de segmentos de red públicos, la responsabilidad de que exista una Zona de Autoridad para cada Zona de Resolución Inversa, corresponde a la autoridad misma del segmento, es decir, corresponde a quien esté registrado como autoridad del bloque de direcciones IP, información que puede ser obtenida al consultar una base de datos WHOIS.

Los grandes ISP y algunas empresas son quienes se hacen cargo de las Zonas de Resolución Inversa.

Herramientas de búsqueda y consulta.

Para el diagnóstico y la consulta de DNS en entornos profesionales y educativos modernos, se recomienda enfáticamente el uso de dig y host. Es importante señalar que herramientas heredadas como nslookup, si bien aún están presentes en algunos sistemas (particularmente en entornos Windows por razones históricas de compatibilidad), se consideran obsoletas para el análisis serio. Su interfaz y salida son menos consistentes y ofrecen un control significativamente menor en comparación con las alternativas modernas, por lo que distan de ser una buena práctica para la administración de sistemas.

Uso de host.

Host es una herramienta simple para hacer consultas en Servidores DNS. Es utilizado para obtener las direcciones IP de los nombres de anfitrión y viceversa.

De modo predeterminado, realiza las consultas en los Servidores DNS que estén definidos en el archivo /etc/resolv.conf del anfitrión local, pudiendo definirse de manera opcional cualquier otro Servidor DNS.

host www.alcancelibre.org

Lo anterior realiza una búsqueda en los Servidores DNS definidos en el archivo /etc/resolv.conf del sistema, devolviendo como resultado una dirección IP.

host www.alcancelibre.org 8.8.8.8

Lo anterior realiza una búsqueda en los Servidor DNS en la dirección IP 8.8.8.8, devolviendo una dirección IP como resultado.

Uso de dig.

Dig (domain information groper) es una herramienta flexible para realizar consultas en Servidores DNS. Realiza búsquedas y muestra las respuestas que son regresadas por los servidores que fueron consultados. Debido a su flexibilidad y claridad en la salida, es que la mayoría de los administradores utilizan dig para diagnosticar problemas de DNS.

De modo predeterminado, realiza las búsquedas en los Servidores DNS definidos en el archivo /etc/resolv.conf, pudiendo definirse de manera opcional cualquier otro Servidor DNS. La sintaxis básica sería:

dig @servidor dominio.tld TIPO

Donde servidor corresponde al nombre o dirección IP del Servidor DNS a consultar, dominio.tld corresponde al nombre del registro del recurso que se está buscando y TIPO corresponde al tipo de consulta requerido (ANY, A, MX, SOA, NS, etc.)

Ejemplo:

dig @8.8.8.8 alcancelibre.org MX

Lo anterior realiza una búsqueda en el Servidor DNS en la dirección IP 8.8.8.8 para los registros MX para el dominio alcancelibre.org.

dig alcancelibre.org NS

Lo anterior realiza una búsqueda en los Servidores DNS definidos en el archivo /etc/resolv.conf del sistema para los registros NS para el dominio alcancelibre.org.

dig @8.8.8.8 alcancelibre.org NS

Lo anterior realiza una búsqueda en los Servidor DNS en la dirección IP 8.8.8.8 para los registros NS para el dominio alcancelibre.org.

Uso de whois.

Es una herramienta de consulta a través de servidores WHOIS. La sintaxis básica es:

whois dominio.tld

Ejemplo:

whois alcancelibre.org

Lo anterior regresa la información correspondiente al dominio alcancelibre.org.

Procedimientos prácticos.

La teoría se consolida mediante la práctica. Esta sección transforma los conceptos anteriores en acciones concretas, guiándole paso a paso en la instalación, configuración básica y verificación de un servidor DNS con BIND, adaptado para las distribuciones objetivo del curso.

Equipamiento lógico necesario.

Para instalar el servidor BIND y las herramientas de diagnóstico, ejecute:

En AlmaLinux/Rocky Linux (con dnf):

dnf -y install bind bind-utils whois

En ALDOS (con yum):

yum -y install bind bind-utils whois

El paquete bind proporciona el servicio DNS (named). bind-utils incluye las herramientas dig y host, que son utilizadas para realizar distintos tipos de consultas de DNS. El paquete whois es la herramienta de consulta para información pública de dominios y direcciones IP.

Instalación y configuración básica de BIND.

1. Habilitar e iniciar el servicio.

En distribuciones con systemd (AlmaLinux, Rocky Linux):

systemctl enable --now named

En ALDOS (con SysVinit):

/sbin/chkconfig named on
/sbin/service named start

2. Configurar el muro cortafuegos (Firewalld).

Todos los servicios DNS utilizan los puertos 53/TCP y 53/UDP. Configure el muro cortafuegos para permitir el tráfico utilizando firewall-cmd, la herramienta moderna y predeterminada.

firewall-cmd --add-service=dns --permanent
firewall-cmd --reload

3. Verificar el funcionamiento básico.

Ejecute una consulta local para verificar que el servicio está operativo:

host localhost 127.0.0.1

La salida debe confirmar la resolución de localhost a 127.0.0.1.

Configurar una Zona de Autoridad local.

Para fines de práctica, configuraremos una zona de reenvío para el dominio ejemplo.lan. Es fundamental utilizar un dominio que no sea real (.lan, .local, .test) para evitar conflictos con Internet.

1. Editar el archivo de configuración principal de BIND.

El archivo principal es /etc/named.conf. Realice una copia de seguridad antes de editarlo.

cp /etc/named.conf /etc/named.conf.backup
vim /etc/named.conf

Localice las líneas que definen las opciones (options). Asegúrese de que la directiva listen-on incluya la dirección IP de su servidor (o any para pruebas) y que allow-query permita consultas desde su red local. Un ejemplo para una red 192.168.100.0/24:

options {
    listen-on port 53 { 127.0.0.1; 192.168.100.10; };
    listen-on-v6 port 53 { ::1; };
    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";
    allow-query     { localhost; 192.168.100.0/24; };
    ...
};

2. Definir la nueva zona.

Al final del archivo /etc/named.conf, añada la definición de la zona maestra para ejemplo.lan:

zone "ejemplo.lan" IN {
    type master;
    file "ejemplo.lan.zone";
    allow-update { none; };
};

3. Crear el archivo de zona.

Los archivos de zona se almacenan típicamente en /var/named/. Cree el archivo definido en el paso anterior.

vim /var/named/ejemplo.lan.zone

Añada el siguiente contenido, adaptando las direcciones IP y nombres a su entorno. Preste especial atención a los puntos finales (.) en los FQDN.

$TTL 3600
@       IN      SOA     ns1.ejemplo.lan.    admin.ejemplo.lan. (
                        2025122201  ; Número de serie (AAAAMMDDVV)
                        7200        ; Refresco
                        900         ; Reintento
                        1209600     ; Caducidad
                        3600        ; TTL negativo
                        )
; Registros de Servidores de Nombre (NS)
@       IN      NS      ns1.ejemplo.lan.

; Registros de Dirección (A)
@       IN      A       192.168.100.10
ns1     IN      A       192.168.100.10
www     IN      A       192.168.100.20
servidor IN     A       192.168.100.30
correo  IN      A       192.168.100.40

; Alias (CNAME)
web     IN      CNAME   www.ejemplo.lan.

; Intercambio de Correo (MX)
@       IN      MX 10   correo.ejemplo.lan.

Establezca los permisos de propiedad y grupo correctos para el archivo de zona:

chown root:named /var/named/ejemplo.lan.zone
chmod 640 /var/named/ejemplo.lan.zone

4. Validar la configuración y reiniciar BIND.

Antes de reiniciar, valide la sintaxis de los archivos de configuración:

named-checkconf /etc/named.conf
named-checkzone ejemplo.lan /var/named/ejemplo.lan.zone

Si ambos mandatos no reportan errores, reinicie el servicio:

Con systemd:

systemctl restart named

Con SysVinit (ALDOS):

/sbin/service named restart

Probar la nueva zona DNS.

Configure temporalmente un cliente en la misma red para usar la IP de su nuevo servidor DNS (ej: 192.168.100.10). Luego, realice consultas:

# Consultar la dirección A del servidor web
host www.ejemplo.lan 192.168.100.10

# Consultar el registro MX del dominio
host -t mx ejemplo.lan 192.168.100.10

# Consultar el servidor de nombres autoritativo
host -t ns ejemplo.lan 192.168.100.10

Si todo está configurado correctamente, estas consultas devolverán las respuestas definidas en su archivo de zona.

Resumen y mejores prácticas.

Siguiendo esta guía, estará preparado para desplegar y administrar un servidor DNS básico y funcional, sentando las bases para configuraciones más avanzadas.