Tutorial: configurar servidor DHCP e DNS local com dnsmasq no Debian para ambiente de desenvolvimento

Redes & Segurança · Por Kevin Marcondes · Publicado em 23/10/2026 · Atualizado em 25/10/2026 · 9 min de leitura

Este tutorial — configurar servidor DHCP e DNS local com dnsmasq no Debian para ambiente de desenvolvimento — guia você passo a passo. Você vai criar uma zona local, encaminhar consultas externas, definir a faixa DHCP, reservar IPs por MAC e validar tudo com testes simples. Útil para times que precisam de nomes previsíveis e IPs estáveis no lab.

Pré-requisitos e plano de rede

Vamos provisionar um host Debian como servidor DNS (forwarder + cache) e DHCP para a rede de desenvolvimento. Nunca ative dois servidores DHCP no mesmo segmento. Desative o DHCP do roteador ou isole este serviço em uma VLAN. Escolha um domínio local sem conflito. Prefira subdomínios de home.arpa (ex.: dev.home.arpa) ou o sufixo .test. Evite .local.

Pré-requisitos:

- Debian recente (11/12), acesso root ou sudo.

- IP estático para o servidor na sub-rede de desenvolvimento.

- Janela de mudança para ativar o DHCP sem afetar outros hosts.

Defina seu plano de rede e guarde os valores abaixo.

• Debian recente com root/sudo
• IP do servidor fixo na sub-rede
• Janela de mudança para ativar DHCP

Passo 1 — Instalar dnsmasq e utilitários

Instale dnsmasq e ferramentas para depuração de DNS. dnsmasq fornece DNS cache/forwarder e servidor DHCP leve, ideal para labs. Após instalar, o serviço sobe com uma configuração básica. Faremos ajustes em arquivos dentro de /etc/dnsmasq.d/.

Se já existir outro serviço escutando na porta 53, pare-o antes de prosseguir (por exemplo, um 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

Passo 2 — Confirmar IP estático e rota padrão

Garanta que o servidor tenha IP estático na sub-rede do lab. O caminho simples é reservar o MAC do servidor no roteador e fixar o IP lá. Se o IP deste host mudar, clientes podem perder DNS e DHCP.

Confirme o IP atual e a rota padrão do servidor antes de configurar o dnsmasq.

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

Passo 3 — Configurar DNS local e encaminhamento

Crie um arquivo de resolvers upstream para o dnsmasq e um arquivo de configuração específico da sua zona local. Usaremos dev.home.arpa como exemplo. Ajuste endereços conforme seu plano de rede. Incluímos alguns registros estáticos e um wildcard para facilitar subdomínios temporários em desenvolvimento.

Ao final, o dnsmasq vai escutar no IP do servidor, responder pela zona local, encaminhar consultas externas aos resolvers definidos e manter um cache.

# 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

Passo 4 — Habilitar DHCP básico e reservas

Ative o DHCP para a faixa definida. Incluímos opções padrão de gateway, DNS e domínio de busca. Também é possível reservar IPs por MAC para hosts críticos, como banco ou runner de CI.

Atenção: ao iniciar o DHCP, todos os clientes do segmento podem receber IP deste servidor. Execute em janela de mudança, com o antigo DHCP desativado ou em uma VLAN isolada.

# 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

Passo 5 — Abrir portas e iniciar o serviço

Abra as portas do firewall para DNS (TCP/UDP 53) e DHCP (UDP 67). Em seguida, reinicie e habilite o dnsmasq no boot. Verifique os logs para confirmar que está escutando na interface correta e anunciando a faixa DHCP.

Se usa UFW, veja o guia como configurar firewall no Ubuntu com UFW para revisar regras e políticas.

• Portas DNS: 53/TCP e 53/UDP
• Porta DHCP: 67/UDP
• Habilitar dnsmasq no boot e 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

Passo 6 — Testes práticos de DNS e DHCP

Teste o DNS local direto no servidor e em um cliente. Depois, valide o DHCP renovando o lease de uma máquina da rede de desenvolvimento. Em clientes não Linux, use a interface gráfica para desconectar e reconectar à rede.

Durante os testes, mantenha um terminal com os logs do dnsmasq aberto. Assim você observa consultas DNS e concessões de IP em tempo 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

Solução de problemas comuns

Conflito de DHCP: se outro DHCP estiver ativo no segmento, clientes podem receber IPs de servidores distintos. Desative o DHCP do roteador ou isole a rede de desenvolvimento.

Porta 53 ocupada: verifique qual processo escuta na 53. Pare-o ou mude a configuração para o dnsmasq escutar somente no IP do servidor (bind-interfaces + listen-address).

Sem navegação externa: revise dhcp-option router e o resolv-file do dnsmasq. Confirme conectividade do servidor ao gateway e aos DNS upstream.

Resolução local falha: cheque domínio correto (dev.home.arpa), nomes e IPs nos registros host-record/address. Limpe caches do cliente antes de retestar.

Fortaleça o host: aplique hardening e monitore serviços. O checklist de segurança para VPS Linux ajuda a revisar pontos críticos.

• Desative DHCP conflitante no roteador ou isole a VLAN
• Corrija processos que usam a porta 53
• Revise opções de gateway/DNS no DHCP
• Limpe caches e verifique a zona local
• Reforce hardening e monitore o host

Dicas avançadas para times de desenvolvimento

Wildcard DNS acelera prévias e ambientes efêmeros. Combine-o com um proxy reverso para rotear *.dev.home.arpa aos serviços internos. Veja o comparativo Traefik vs Nginx como reverse proxy para escolher o melhor para seu stack.

Acesso remoto seguro ao lab: crie uma VPN para a rede de desenvolvimento. Assim a equipe usa o mesmo DNS interno fora do escritório. Siga o passo a passo configurar WireGuard VPN road‑warrior no Debian.

Fortaleça a base: aplique práticas consistentes de hardening e firewall no host do dnsmasq. Isso reduz surpresas durante os sprints e incidentes difíceis.

• Wildcard + proxy reverso para prévias
• VPN para acesso remoto seguro ao lab
• Hardening e firewall no host do DNS/DHCP

Perguntas frequentes

Posso usar .local como domínio do lab?

Evite .local. Esse sufixo é usado por mDNS e pode causar conflitos e lentidão. Prefira domínios reservados como home.arpa (ex.: dev.home.arpa) ou .test. Assim, a resolução local fica previsível e sem interferir com descoberta mDNS.

Como evitar conflito com o DHCP do meu roteador?

Execute o DHCP do dnsmasq apenas em uma rede isolada (VLAN/lab) ou desative o DHCP do roteador antes de ativar o dnsmasq. Rodar dois DHCPs no mesmo segmento causa concessões inconsistentes e intermitências de rede nos clientes.

Consigo fazer reservas por hostname em vez de MAC?

No DHCP, reservas confiáveis usam MAC address. No dnsmasq, use dhcp-host com o MAC do equipamento e o IP desejado. Para nomes, combine a reserva com o hostname no parâmetro dhcp-host ou crie registros DNS estáticos na zona local.

É possível entregar PXE/TFTP com dnsmasq para boot de VMs?

Sim. dnsmasq suporta opções de PXE/TFTP (por exemplo, dhcp-boot e tftp-root). Ative o servidor TFTP integrado e aponte o arquivo de boot. Faça isso apenas em redes controladas, pois clientes podem carregar imagens de boot inadvertidamente.

Como limitar o dnsmasq a uma interface específica?

Use bind-interfaces e listen-address no arquivo de configuração, apontando para o IP do servidor na sub-rede desejada. Assim, o dnsmasq não responderá em outras interfaces, reduzindo riscos e evitando conflitos em ambientes com múltiplas redes.

Posso aplicar políticas de DNS diferentes para times distintos?

Crie sub-redes ou VLANs separadas, cada uma com seu dnsmasq e zona local, ou use instâncias isoladas do serviço. Essa separação evita efeitos colaterais e permite regras específicas por equipe, como ranges DHCP e registros customizados.

Veja também

• tutorial: configurar mTLS entre Traefik e serviços em Docker Compose usando smallstep CA e certificados automáticos — passo a passo
• Tutorial: integrar Sentry ao pipeline de deploy com GitHub Actions para upload automático de source maps e criação de issues (PHP e JavaScript) — passo a passo
• Configurar retenção e compactação de logs de containers Docker com journald + logrotate + rsyslog em VPS com pouco disco
• tutorial: configurar GitHub Actions para testes de integração com PostgreSQL em containers efêmeros e rollback automático de migrações — guia prático