Guía paso a paso para configurar DNS en servidores Linux
Guía paso a paso para configurar DNS en servidores Linux
En un servidor Linux que atiende peticiones web o correo electrónico, una resolución DNS lenta o mal configurada puede añadir cientos de milisegundos a cada conexión y generar colas de espera innecesarias en el kernel. He visto entornos de producción donde simplemente cambiar el orden de los servidores DNS redujo la latencia media de 180 ms a menos de 40 ms sin tocar ni una línea de código de la aplicación.
- Por qué la resolución DNS importa en servidores Linux y cómo funciona realmente
- Preparación del servidor antes de tocar la configuración DNS
- Configuración con systemd-resolved en distribuciones actuales
- Configuración manual y alternativas cuando systemd-resolved no es suficiente
- Ejemplos prácticos y configuraciones reales en producción
Por qué la resolución DNS importa en servidores Linux y cómo funciona realmente
La mayoría de los servicios que corren en Linux (nginx, Postfix, aplicaciones en contenedores) realizan consultas DNS cada vez que necesitan resolver un nombre de host. El proceso comienza cuando glibc o el resolvedor del sistema envía una petición UDP al puerto 53. Si no hay respuesta en unos milisegundos, el kernel reintenta con TCP. Esa secuencia se repite para cada subdominio y cada registro (A, AAAA, MX, TXT).
En distribuciones modernas como Ubuntu 22.04 o Debian 12, systemd-resolved se encarga de cachear respuestas y de manejar la rotación entre varios servidores DNS. Sin embargo, en entornos donde se ejecutan cientos de contenedores o se usa Kubernetes, esa caché por defecto puede quedarse corta y conviene ajustar los parámetros de tiempo de vida o añadir un resolvedor local más agresivo.
Componentes clave del resolvedor en Linux
- El archivo /etc/nsswitch.conf define el orden en que el sistema busca información: primero archivos locales, luego DNS, y opcionalmente mDNS o LDAP.
- systemd-resolved mantiene una caché en memoria y expone una interfaz D-Bus que permite consultar estadísticas con resolvectl statistics.
- Cuando se usa NetworkManager o systemd-networkd, las direcciones de DNS suelen inyectarse automáticamente desde DHCP, pero en servidores dedicados lo habitual es fijarlas de forma estática.
Preparación del servidor antes de tocar la configuración DNS
Antes de modificar cualquier archivo de resolución conviene verificar qué demonio de red está gestionando las interfaces. En Ubuntu Server el comando systemctl status systemd-networkd suele mostrar si está activo. En CentOS Stream o Rocky Linux 9 lo más común sigue siendo NetworkManager.
Una comprobación rápida consiste en ejecutar ip addr y ver qué interfaz tiene la dirección IP principal del servidor. Luego se puede inspeccionar el archivo de configuración de esa interfaz para confirmar que no hay directivas DNS heredadas del proveedor de cloud.
Comprobaciones iniciales recomendadas
- Ejecuta dig +short google.com desde la línea de comandos para medir el tiempo actual de resolución y confirmar que el sistema ya tiene conectividad básica.
- Revisa journalctl -u systemd-resolved --since "10 minutes ago" para detectar errores de conexión a los servidores DNS actuales.
- Comprueba que el firewall permite tráfico UDP y TCP al puerto 53 si vas a instalar un resolvedor local como Unbound o BIND.
Configuración con systemd-resolved en distribuciones actuales
systemd-resolved es la opción más sencilla y la que recomiendo en la mayoría de servidores Ubuntu, Debian y Fedora recientes. El servicio ya viene instalado y solo hay que configurarlo correctamente para que use los servidores que realmente queremos.
El primer paso consiste en crear o editar el archivo /etc/systemd/resolved.conf. Dentro de la sección [Resolve] se pueden definir hasta tres servidores DNS principales y varios de respaldo. También es posible activar la caché DNSSEC si el entorno lo requiere.
Pasos detallados para systemd-resolved
- Abre el archivo con sudo nano /etc/systemd/resolved.conf y añade las líneas DNS= y FallbackDNS= con las direcciones que prefieras, por ejemplo 1.1.1.1 y 8.8.8.8.
- Guarda el archivo y ejecuta sudo systemctl restart systemd-resolved para aplicar los cambios.
- Verifica que la configuración se ha aplicado correctamente con resolvectl status; deberías ver los nuevos servidores listados bajo la interfaz lo.
- Prueba la resolución con dig example.com @127.0.0.53 y comprueba que la respuesta llega desde el resolvedor local.
En algunos casos, especialmente cuando se usan contenedores Docker o Podman, es necesario añadir la línea DNSStubListener=no para que el puerto 53 quede libre y los contenedores puedan usar el resolvedor del host sin conflictos.
Configuración manual y alternativas cuando systemd-resolved no es suficiente
Hay escenarios donde systemd-resolved no ofrece el control necesario: servidores que deben resolver nombres internos de una red corporativa mediante un servidor BIND propio, o entornos con requisitos estrictos de privacidad que prefieren Unbound con DNS sobre TLS.
En estos casos la aproximación clásica sigue siendo editar /etc/resolv.conf directamente, aunque en sistemas con systemd esto requiere crear un enlace simbólico o usar resolvconf. Otra opción popular es instalar dnsmasq, que actúa como caché ligera y permite definir resoluciones estáticas por dominio.
Comparativa de herramientas de resolución DNS
| Herramienta | Facilidad de uso | Consumo de memoria | Mejor caso de uso |
|---|---|---|---|
| systemd-resolved | Alta | Bajo (≈8 MB) | Servidores web y aplicaciones estándar |
| Unbound | Media | Medio (≈25 MB) | Entornos que requieren DNSSEC y privacidad |
| BIND 9 | Baja | Alto (≈60 MB) | Servidores autoritativos internos |
| dnsmasq | Alta | Muy bajo (≈3 MB) | Redes pequeñas y contenedores |
Ejemplos prácticos y configuraciones reales en producción
Ejemplo 1: Servidor web con Cloudflare y fallback a Google
Un servidor Ubuntu 22.04 que sirve tráfico estático puede configurarse para usar los DNS de Cloudflare (1.1.1.1 y 1.0.0.1) como principales y mantener 8.8.8.8 como respaldo. Tras aplicar los cambios con systemd-resolved, las pruebas con curl -w "%{time_namelookup}\n" mostraron una reducción media de 35 ms en la fase de resolución de nombres de dominio.
Ejemplo 2: Servidor de correo con Unbound y DNS sobre TLS
En un servidor Rocky Linux 9 que ejecuta Postfix y Dovecot, se instaló Unbound para cifrar las consultas DNS. El archivo /etc/unbound/unbound.conf se modificó para incluir forward-zone con tls-cert-bundle y forward-tls-upstream: yes. Tras el reinicio, todas las consultas MX y SPF se realizaron a través de TLS sin impacto perceptible en el rendimiento del correo.
Ejemplo 3: Entorno con contenedores y dnsmasq
Un servidor Debian 12 que ejecuta varios contenedores LXC recibió la configuración de dnsmasq para resolver nombres internos del dominio .lan. Se añadió la línea address=/interno.lan/10.8.0.5 en /etc/dnsmasq.conf y se configuró el resolvedor del host para escuchar solo en la interfaz bridge. El consumo de memoria del proceso dnsmasq se mantuvo por debajo de 4 MB incluso con más de 120 contenedores activos.
En todos los casos anteriores se recomienda monitorizar los tiempos de resolución durante al menos 48 horas después del cambio. Herramientas como Prometheus con el exporter node-exporter permiten registrar la métrica node_dns_resolution_seconds y detectar regresiones rápidamente.
Una observación que suelo compartir con equipos que administran flotas de servidores es que la configuración DNS suele ser la parte más olvidada durante migraciones a la nube. Muchas veces se copia la configuración antigua de /etc/resolv.conf sin revisar que los servidores DNS del proveedor anterior ya no están disponibles, lo que genera timeouts silenciosos que solo aparecen bajo carga.
Si tu servidor forma parte de una infraestructura más grande, considera también la opción de desplegar un resolvedor local en cada zona de disponibilidad y que los servidores hablen con él mediante una dirección IP privada. Esto reduce la latencia y el tráfico hacia Internet, además de darte control total sobre la caché y las políticas de bloqueo.
La configuración de DNS en servidores Linux no es un tema que se resuelva de una vez por todas. Cada cambio en la infraestructura (nuevo proveedor de cloud, adopción de IPv6, migración a contenedores) obliga a revisar los parámetros de tiempo de espera, el tamaño de la caché y los servidores de respaldo.
Mantener un pequeño script de verificación que ejecute dig y mida tiempos de respuesta antes y después de cada despliegue ayuda a evitar sorpresas en producción.
En resumen, la Guía paso a paso para configurar DNS en servidores Linux que acabas de leer busca darte las herramientas necesarias para elegir la solución más adecuada según tu distribución y carga de trabajo, aplicarla de forma ordenada y verificar que realmente mejora el comportamiento del sistema.
Si quieres conocer otros artículos parecidos a Guía paso a paso para configurar DNS en servidores Linux puedes visitar la categoría Internet y Redes.
Entradas Relacionadas