- Separação de papéis no DNS: autoritativos só servem zonas (previsível) e o recursivo faz cache e resolve para os clientes (bursty e user-facing).
- Arquitetura 3+1 pronta para produção: 1 master 10.0.0.10, 2 slaves 10.0.0.11/12 e 1 cache/recursivo 10.0.0.20, com clientes apontando apenas para o recursivo.
- BIND9 autoritativo seguro: recursion no; obrigatório, allow-transfer por IP e also-notify para propagação rápida das zonas.
- Unbound como camada de performance: access-control por rede interna, hide-identity e hide-version, prefetch: yes e TTLs de cache para acelerar respostas.
- Validação e operação sem achismo: testes com dig +trace, saúde com rndc status e métricas com unbound-control stats, além de firewall na porta 53 TCP/UDP.
Centralizar DNS é sobre manter um serviço sempre disponível, previsível e rápido. Quando o DNS falha, quase tudo “quebra” de um jeito estranho e difícil de diagnosticar.
O erro clássico é misturar papéis. A promessa desta arquitetura é um DNS “chato”, simples de entender, fácil de operar e com superfície de ataque menor.
O conceito: por que separar autoritativo de recursivo?
DNS autoritativo responde com base em zonas que você controla. Ele é previsível, baseado em arquivo de zona, e funciona como uma camada de leitura para clientes.
DNS recursivo resolve nomes em nome do usuário, faz cache pesado e lida com picos de consulta. Essa carga tende a ser mais “bursty” e sensível a latência, porque cada milissegundo de resolução afeta a experiência.
Misturar autoritativo e recursivo no mesmo servidor aumenta a superfície de ataque, eleva a complexidade operacional e amplia o impacto de falhas. Em produção, separar responsabilidades é uma decisão de segurança e de performance.
Design da rede e stack de software
A arquitetura usa 3 autoritativos para alta disponibilidade e distribuição de carga, com 1 recursivo dedicado para concentrar cache e política de acesso. O ponto-chave é que clientes não falam com autoritativos diretamente.
Tabela de IPs e funções
| Servidor | IP | Papel | Função |
|---|---|---|---|
dns-auth-01 | 10.0.0.10 | Authoritative | Primary (master) |
dns-auth-02 | 10.0.0.11 | Authoritative | Secondary (slave) |
dns-auth-03 | 10.0.0.12 | Authoritative | Secondary (slave) |
dns-cache-01 | 10.0.0.20 | Recursive / Cache | Resolução interna (cache) |
Por que BIND para autoritativo e Unbound para cache?
A combinação BIND9 (ou NSD) para autoritativo e Unbound para recursivo/cache entrega comportamento maduro, separação clara de responsabilidades e bom suporte no Linux.
O Unbound se encaixa bem como camada recursiva por conta do cache e do prefetch. Já o autoritativo mantém as zonas e serve respostas determinísticas, sem “fazer recursão”.
Passo 1: configurando os autoritativos (BIND9)
Aqui você cria uma camada somente autoritativa. Zonas são editadas apenas no master, e os slaves sincronizam via transferência de zona.
Master (dns-auth-01) com transferências restritas e NOTIFY
Exemplo de definição de zona (BIND) no master:
zone "example.internal" {
type master;
file "/etc/bind/zones/example.internal.zone";
allow-transfer { 10.0.0.11; 10.0.0.12; };
also-notify { 10.0.0.11; 10.0.0.12; };
};Dois pontos importam aqui. Primeiro, allow-transfer restringe AXFR/IXFR por IP, reduzindo risco e exposição.
Segundo, also-notify acelera a propagação, evitando esperar apenas timers.
No autoritativo, recursão deve ficar desligada
No BIND autoritativo, a recursão é explicitamente desabilitada:
options {
recursion no;
allow-query { any; };
};O objetivo é deixar o autoritativo previsível e menos exposto. Ele responde pelo que sabe e não “vai para fora” tentar resolver nomes para clientes.
[Image of diagrama de fluxo de zona: master (10.0.0.10) notifica slaves (10.0.0.11/10.0.0.12), que puxam transferência de zona]
Slaves (dns-auth-02 e dns-auth-03) sincronizando automaticamente
Nos slaves, a zona é configurada como type slave, apontando para o master:
zone "example.internal" {
type slave;
masters { 10.0.0.10; };
file "/var/cache/bind/example.internal.zone";
};O ponto operacional é simples. Slaves não são editados manualmente, eles recebem e servem, funcionando como HA e distribuição de consultas.
Passo 2: configurando o recursivo (Unbound)
O dns-cache-01 é o único endpoint DNS para clientes. Ele centraliza cache, aplica controle de acesso e encaminha zonas internas para a camada autoritativa.
Configuração mínima e efetiva (segurança e cache)
Exemplo de configuração do Unbound:
server:
interface: 0.0.0.0
access-control: 10.0.0.0/24 allow
do-ip6: no
hide-identity: yes
hide-version: yes
prefetch: yes
cache-min-ttl: 300
cache-max-ttl: 86400Aqui você enxerga a filosofia do design. O acesso é controlado por rede interna, identidade e versão são ocultadas, e o cache é otimizado com prefetch e limites de TTL.
O segredo da integração: encaminhar zonas internas para os autoritativos
Para a zona interna, o Unbound encaminha consultas para os autoritativos, que são a fonte de verdade:
forward-zone:
name: "example.internal"
forward-addr: 10.0.0.10
forward-addr: 10.0.0.11
forward-addr: 10.0.0.12Esse é o mecanismo que materializa o “3+1”. Clientes consultam o cache, o cache encaminha o que é interno para autoritativos, e você mantém o isolamento de papéis.
[Image of diagrama split-horizon lógico: consultas para example.internal vão ao conjunto autoritativo, demais nomes seguem política recursiva]
Resolução externa: independência ou upstream
Há duas abordagens comuns na camada recursiva. Você pode usar root hints para mais independência, ou encaminhar para resolvers upstream confiáveis.
O ponto arquitetural é manter essa decisão no recursivo, sem expor autoritativos a tráfego “user-facing”.
Passo 3: configuração do cliente e validação
A regra é consistente: clientes nunca consultam autoritativos diretamente. Eles apontam só para o recursivo/cache, que é dns-cache-01.
Onde apontar o resolv.conf
Em /etc/resolv.conf, use apenas:
nameserver 10.0.0.20Se estiver usando systemd-resolved:
resolvectl dns eth0 10.0.0.20Firewall e porta 53 (TCP/UDP)
Em produção, a porta 53/UDP e 53/TCP precisa estar no seu desenho de rede. Restrinja no firewall para reduzir exposição e limitar quem pode falar com qual camada.
Como diretriz prática: clientes falam com dns-cache-01 na porta 53, e o dns-cache-01 fala com os autoritativos na porta 53. Transferência de zona também usa 53, com controle adicional via allow-transfer.
Comandos de teste e verificação
Para validar resolução e comportamento:
dig +tracerndc statusunbound-control stats
Na rotina, confirme três coisas. Se o nome interno resolve via dns-cache-01, se o encaminhamento para os autoritativos está correto, e se o cache está operando como esperado.
Alta disponibilidade e operação
Separação de papéis facilita HA por camadas. Autoritativo escala com master e slaves, recursivo escala com mais instâncias de cache.
Redundância do resolvedor
Para produção, faz sentido ter dois caches. Exemplo de fallback no cliente:
nameserver 10.0.0.20
nameserver 10.0.0.21Gestão de zonas com auditoria
Mantenha as zonas em Git, incremente o serial SOA automaticamente, e faça deploy via CI/CD ou Ansible. Mudanças em DNS devem ser auditáveis, não ad-hoc.
Segurança hardening mínimo
Medidas práticas:
- Sem recursão nos autoritativos.
- Firewall restringindo TCP/UDP 53.
- TSIG para transferências de zona (opcional, mas recomendado).
- Evitar divulgação de versão.
- Monitorar taxas de consulta.
DNS que não é monitorado tende a falhar em silêncio. A camada recursiva, por ser user-facing, merece atenção especial para métricas de cache hit, latência e saturação.
