Tutorial: configurar servidor DHCP y DNS local con dnsmasq en Debian para entorno de desarrollo

Redes & Segurança · Por Kevin Marcondes · Publicado el 23/10/2026 · Actualizado el 25/10/2026 · 10 min de lectura

Este tutorial — configurar servidor DHCP y DNS local con dnsmasq en Debian para entorno de desarrollo — te guía paso a paso. Vas a crear una zona local, reenviar consultas externas, definir el rango DHCP, reservar IPs por MAC y validar todo con pruebas sencillas. Útil para equipos que necesitan nombres predecibles y IPs estables en el lab.

Requisitos previos y plan de red

Provisionaremos un host Debian como servidor DNS (reenviador + caché) y DHCP para la red de desarrollo. Nunca actives dos servidores DHCP en el mismo segmento: desactiva el DHCP del router o aísla este servicio en una VLAN. Elige un dominio local sin conflicto. Prefiere subdominios de home.arpa (ej.: dev.home.arpa) o el sufijo .test. Evita .local.

Requisitos:

- Debian reciente (11/12), acceso root o sudo.

- IP estática para el servidor en la subred de desarrollo.

- Ventana de cambio para activar el DHCP sin afectar otros hosts.

Define tu plan de red y guarda los valores a continuación.

Debian reciente con root/sudo
IP del servidor fija en la subred
Ventana de cambio para activar DHCP

Ítem	Ejemplo	Observaciones
Red/subred	192.168.50.0/24	Subred del lab/dev
IP del servidor (dnsmasq)	192.168.50.2	Host que ejecutará DNS/DHCP
Gateway/router	192.168.50.1	Salida a Internet
Rango DHCP	192.168.50.100–192.168.50.150	Tamaño según número de clientes
Dominio local	dev.home.arpa	Evita .local; prefiere home.arpa/.test
DNS upstream	1.1.1.1 y 8.8.8.8	Resolutores públicos o del proveedor

Paso 1 — Instalar dnsmasq y utilidades

Instala dnsmasq y herramientas para depuración de DNS. dnsmasq proporciona caché/reenviador DNS y un servidor DHCP ligero, ideal para labs. Tras instalar, el servicio arranca con una configuración básica. Haremos ajustes en archivos dentro de /etc/dnsmasq.d/.

Si ya existe otro servicio escuchando en el puerto 53, deténlo antes de continuar (por ejemplo, un resolved local).

sudo apt update
sudo apt install -y dnsmasq dnsutils

# Verifique o status do serviço
systemctl status dnsmasq --no-pager

# (Opcional) Confira se a porta 53 está livre e usada pelo dnsmasq
ss -luntp | grep -E ':53 ' || true

Paso 2 — Confirmar IP estático y ruta por defecto

Asegúrate de que el servidor tenga IP estática en la subred del lab. La vía sencilla es reservar el MAC del servidor en el router y fijar el IP allí. Si la IP de este host cambia, los clientes pueden perder DNS y DHCP.

Confirma la IP actual y la ruta por defecto del servidor antes de configurar dnsmasq.

ip -4 addr show | grep -E 'inet .* brd' | awk '{print $2, $NF}'
ip route | grep default

Paso 3 — Configurar DNS local y reenvío

Crea un archivo de resolvers upstream para dnsmasq y un archivo de configuración específico para tu zona local. Usaremos dev.home.arpa como ejemplo. Ajusta las direcciones según tu plan de red. Incluimos algunos registros estáticos y un wildcard para facilitar subdominios temporales en desarrollo.

Al final, dnsmasq escuchará en la IP del servidor, responderá por la zona local, reenviará consultas externas a los resolvers definidos y mantendrá un caché.

# Defina DNS upstream usados pelo dnsmasq (não mexe no /etc/resolv.conf do sistema)
sudo tee /etc/dnsmasq.resolv.conf >/dev/null <<'EOF'
nameserver 1.1.1.1
nameserver 8.8.8.8
EOF

# Crie a configuração da zona local
sudo tee /etc/dnsmasq.d/dev.conf >/dev/null <<'EOF'
# Zona local
domain=dev.home.arpa
local=/dev.home.arpa/
expand-hosts

# Interface/IP de escuta (ajuste o IP do servidor)
listen-address=192.168.50.2,127.0.0.1
bind-interfaces

# Regras de resolução
domain-needed
bogus-priv
no-resolv
resolv-file=/etc/dnsmasq.resolv.conf
cache-size=10000

# Registros locais úteis (exemplos)
# Registros tipo A
host-record=registry.dev.home.arpa,192.168.50.10
address=/app.dev.home.arpa/192.168.50.20

# Wildcard para facilitar prévias por subdomínio (ex.: *.svc.dev.home.arpa)
address=/.dev.home.arpa/192.168.50.30
EOF

Paso 4 — Habilitar DHCP básico y reservas

Activa el DHCP para el rango definido. Incluimos opciones por defecto de gateway, DNS y dominio de búsqueda. También es posible reservar IPs por MAC para hosts críticos, como base de datos o runner de CI.

Atención: al iniciar el DHCP, todos los clientes del segmento pueden recibir IP de este servidor. Ejecuta en ventana de cambio, con el DHCP antiguo desactivado o en una VLAN aislada.

# Acrescente as diretivas de DHCP ao mesmo arquivo
sudo tee -a /etc/dnsmasq.d/dev.conf >/dev/null <<'EOF'
# DHCP básico
# Faixa: 192.168.50.100–150, concessão de 12h
 dhcp-range=192.168.50.100,192.168.50.150,255.255.255.0,12h
# Gateway padrão
 dhcp-option=option:router,192.168.50.1
# Servidor(es) DNS oferecido(s) aos clientes (use o próprio servidor)
 dhcp-option=option:dns-server,192.168.50.2
# Domínio de busca
 dhcp-option=option:domain-search,dev.home.arpa

# (Opcional) Declare autoridade na sub-rede (use somente se este for o único DHCP)
# dhcp-authoritative

# (Opcional) Reservas por MAC (exemplos)
 dhcp-host=AA:BB:CC:DD:EE:01,192.168.50.10,ci-runner,12h
 dhcp-host=AA:BB:CC:DD:EE:02,192.168.50.20,db-dev,12h
EOF

Paso 5 — Abrir puertos e iniciar el servicio

Abre los puertos del firewall para DNS (TCP/UDP 53) y DHCP (UDP 67). A continuación, reinicia y habilita dnsmasq en el arranque. Revisa los logs para confirmar que está escuchando en la interfaz correcta y anunciando el rango DHCP.

Si usas UFW, consulta la guía cómo configurar firewall en Ubuntu con UFW para revisar reglas y políticas.

Puertos DNS: 53/TCP y 53/UDP
Puerto DHCP: 67/UDP
Habilitar dnsmasq en el arranque y revisar logs

# Abrir portas no UFW (se em uso)
sudo ufw allow 53/udp
sudo ufw allow 53/tcp
sudo ufw allow 67/udp

# Reiniciar e habilitar o serviço
echo "Reiniciando dnsmasq..."
sudo systemctl restart dnsmasq
sudo systemctl enable dnsmasq

# Logs e checagens
journalctl -u dnsmasq -n 50 --no-pager
ss -luntp | grep -E ':53 |:67 ' || true

Paso 6 — Pruebas prácticas de DNS y DHCP

Prueba el DNS local directamente en el servidor y desde un cliente. Luego, valida el DHCP renovando el lease de una máquina de la red de desarrollo. En clientes no Linux, usa la interfaz gráfica para desconectar y reconectar a la red.

Durante las pruebas, mantén un terminal con los logs de dnsmasq abierto para observar consultas DNS y concesiones de IP en tiempo real.

# Testar DNS no servidor (local)
dig +short registry.dev.home.arpa @127.0.0.1
dig +short app.dev.home.arpa @127.0.0.1

dig +time=1 +tries=1 debian.org @127.0.0.1  # Encaminhamento externo

# Em um cliente Linux da mesma sub-rede:
# 1) Configure para obter IP automaticamente (DHCP)
# 2) Renove o lease (pode desconectar/reconectar a interface)
sudo dhclient -r || true
sudo dhclient -v

# Confirme IP obtido e DNS aplicado
ip -4 a show
grep -E 'nameserver|search' /etc/resolv.conf || true

Solución de problemas comunes

Conflicto de DHCP: si otro DHCP está activo en el segmento, los clientes pueden recibir IPs de servidores distintos. Desactiva el DHCP del router o aísla la red de desarrollo.

Puerto 53 ocupado: verifica qué proceso escucha en el 53. Deténlo o configura dnsmasq para que escuche solo en la IP del servidor (bind-interfaces + listen-address).

Sin navegación externa: revisa dhcp-option router y el resolv-file de dnsmasq. Confirma conectividad del servidor al gateway y a los DNS upstream.

Resolución local falla: comprueba el dominio correcto (dev.home.arpa), los nombres y IPs en los registros host-record/address. Limpia caches del cliente antes de volver a probar.

Fortalece el host: aplica hardening y monitorea los servicios. El checklist de seguridad para VPS Linux ayuda a revisar puntos críticos.

Desactiva DHCP conflictivo en el router o aísla la VLAN
Corrige procesos que usan el puerto 53
Revisa opciones de gateway/DNS en el DHCP
Limpia caches y verifica la zona local
Refuerza hardening y monitorea el host

Consejos avanzados para equipos de desarrollo

El DNS wildcard acelera previews y entornos efímeros. Combínalo con un proxy inverso para enrutar *.dev.home.arpa a los servicios internos. Consulta el comparativo Traefik vs Nginx como proxy inverso para elegir lo mejor para tu stack.

Acceso remoto seguro al lab: crea una VPN para la red de desarrollo. Así el equipo usa el mismo DNS interno fuera de la oficina. Sigue el paso a paso para configurar WireGuard road‑warrior en Debian.

Fortalece la base: aplica prácticas consistentes de hardening y firewall en el host de dnsmasq. Esto reduce sorpresas durante sprints e incidentes complicados.

Wildcard + proxy inverso para previews
VPN para acceso remoto seguro al lab
Hardening y firewall en el host de DNS/DHCP

Preguntas frecuentes

¿Puedo usar .local como dominio del lab?

Evita .local. Ese sufijo lo usa mDNS y puede provocar conflictos y lentitud. Prefiere dominios reservados como home.arpa (ej.: dev.home.arpa) o .test. Así la resolución local es predecible y no interfiere con el descubrimiento mDNS.

¿Cómo evitar conflicto con el DHCP de mi router?

Ejecuta el DHCP de dnsmasq solo en una red aislada (VLAN/lab) o desactiva el DHCP del router antes de activar dnsmasq. Tener dos DHCP en el mismo segmento causa concesiones inconsistentes e intermitencias de red en los clientes.

¿Puedo hacer reservas por hostname en vez de MAC?

En DHCP las reservas confiables usan la dirección MAC. En dnsmasq usa dhcp-host con el MAC del equipo y el IP deseado. Para nombres, combina la reserva con el hostname en el parámetro dhcp-host o crea registros DNS estáticos en la zona local.

¿Es posible entregar PXE/TFTP con dnsmasq para arranque de VMs?

Sí. dnsmasq soporta opciones de PXE/TFTP (por ejemplo, dhcp-boot y tftp-root). Activa el servidor TFTP integrado y apunta al archivo de boot. Hazlo solo en redes controladas, ya que clientes podrían cargar imágenes de arranque inadvertidamente.

¿Cómo limitar dnsmasq a una interfaz específica?

Usa bind-interfaces y listen-address en el archivo de configuración, apuntando a la IP del servidor en la subred deseada. Así dnsmasq no responderá en otras interfaces, reduciendo riesgos y evitando conflictos en entornos con múltiples redes.

¿Puedo aplicar políticas de DNS diferentes para equipos distintos?

Crea subredes o VLANs separadas, cada una con su dnsmasq y zona local, o usa instancias aisladas del servicio. Esta separación evita efectos colaterales y permite reglas específicas por equipo, como rangos DHCP y registros personalizados.

¿Estandarizar el DNS/DHCP de tu lab de desarrollo?

Si quieres acelerar pruebas con nombres predecibles, reservas por MAC y wildcard de subdominios, podemos analizar tu escenario y los siguientes pasos.

Hablar sobre el entorno de desarrollo