Unbound

1. Contexto histórico e normativo

O Unbound foi desenvolvido pelo NLnet Labs (mesma organização por trás do NSD, servidor autoritativo de alta performance) e lançado em 2008 como um resolvedor recursivo moderno, focado em segurança (validação DNSSEC ativa por padrão) e performance (design multithreaded com cache hierárquico). Diferentemente do BIND, que combina funções autoritativas e recursivas no mesmo daemon, o Unbound é puramente recursivo — ele foi projetado exclusivamente para resolver nomes para clientes, sem hospedar zonas próprias.

Essa separação de papéis não é uma limitação, mas uma decisão arquitetural alinhada às melhores práticas de segurança: um servidor que faz recursão não deve ser o mesmo que responde autoritativamente por zonas, pois um comprometimento em uma função não deve expor a outra. O Unbound implementa as principais RFCs de segurança DNS, incluindo RFC 4033/4034/4035 (DNSSEC), RFC 7816 (QNAME Minimisation), RFC 7858 (DNS‑over‑TLS) e RFC 9156 (QNAME Minimisation revisada).

2. Arquitetura interna

O Unbound foi projetado desde o início para ser multithreaded, com um modelo de threads que minimiza contenção de locks. Sua arquitetura de cache é hierárquica:

• Message Cache (msg‑cache) — armazena respostas completas (pacotes DNS prontos). Se uma consulta idêntica chega, a resposta é servida diretamente daqui, sem nenhum processamento adicional.
• RRset Cache (rrset‑cache) — armazena conjuntos de registros (RRsets) individualmente. Quando uma consulta não está no msg‑cache, o Unbound tenta montar a resposta a partir dos RRsets em cache — isso é mais rápido que resolver do zero, mesmo que a consulta exata não tenha sido feita antes.
• Infrastructure Cache (infra‑cache) — armazena informações sobre a saúde dos servidores autoritativos (tempos de resposta, timeouts). Evita consultar servidores que estão lentos ou inacessíveis.
• Key Cache (key‑cache) — armazena chaves DNSSEC validadas, evitando revalidação a cada consulta.

Cada cache é dividido em slabs (fatias), cada uma protegida por seu próprio lock. Aumentar o número de slabs (potência de 2, idealmente igual ao número de threads) reduz a contenção em ambientes de alta carga — essencial para resolvedores de ISP com milhares de assinantes simultâneos.

3. Instalação (Debian/Ubuntu)

apt update
apt install unbound unbound-anchor

systemctl enable unbound
systemctl status unbound

4. Configuração básica

# /etc/unbound/unbound.conf.d/isp.conf
server:
    interface: 10.0.0.5
    interface: 127.0.0.1
    access-control: 10.0.0.0/16 allow
    access-control: 0.0.0.0/0 refuse       # nunca aberto à internet

    hide-version: yes
    hide-identity: yes
    qname-minimisation: yes                  # RFC 7816
    use-caps-for-id: yes                     # 0x20 encoding, mitiga poisoning

access-control restrito à sua rede é o item de segurança mais crítico — um Unbound aberto se torna open resolver, explorável em ataques de amplificação DNS contra terceiros.

5. Cache e performance

server:
    num-threads: 4                           # ideal = número de cores físicos
    msg-cache-slabs: 4
    rrset-cache-slabs: 4
    infra-cache-slabs: 4
    key-cache-slabs: 4
    rrset-cache-size: 256m
    msg-cache-size: 128m
    prefetch: yes                            # renova entradas populares antes de expirar
    prefetch-key: yes

O prefetch é particularmente importante em ISP: quando uma entrada está próxima de expirar e é muito consultada, o Unbound já a renova em background — o assinante nunca sente a latência de uma resolução completa para domínios populares.

6. Validação DNSSEC

# Baixar/atualizar a trust anchor raiz
unbound-anchor -a /var/lib/unbound/root.key

# unbound.conf.d/dnssec.conf
server:
    auto-trust-anchor-file: "/var/lib/unbound/root.key"

Com isso, o Unbound valida automaticamente qualquer zona DNSSEC no caminho de resolução — incluindo o .br, referência mundial em adoção (ver DNSSEC). Se a assinatura for inválida, retorna SERVFAIL.

7. DNS‑over‑TLS (privacidade do assinante)

forward-zone:
    name: "."
    forward-tls-upstream: yes
    forward-addr: 1.1.1.1@853
    forward-addr: 9.9.9.9@853

Muitos ISPs preferem recursão pura (sem forward), para não depender de terceiros. O DoT é uma escolha de arquitetura — adiciona privacidade, mas introduz dependência externa.

8. Uso real em ISP — CGNAT e resolvedor local

Cenário comum: Unbound rodando no mesmo segmento do CGNAT, servido via DHCP (opção 6) como resolvedor padrão. Benefícios: redução de latência (cache local), controle sobre logs de consulta (relevante para requisições judiciais) e possibilidade de aplicar políticas próprias (bloqueio de domínios maliciosos via local-zone, sem soluções de terceiros).

9. Dimensionamento

Um Unbound em hardware modesto (4 vCPUs, 8 GB RAM) consegue lidar com dezenas de milhares de consultas/segundo se o cache estiver bem dimensionado. Recomendações para ISP:

• Até 2.000 assinantes — 2 vCPUs, 4 GB RAM, cache 128m/64m.
• 2.000–10.000 assinantes — 4 vCPUs, 8 GB RAM, cache 256m/128m.
• Acima de 10.000 — considerar múltiplas instâncias com anycast ou balanceamento.
• Monitorar unbound‑control stats para ajustar o tamanho dos caches e evitar evicção excessiva.

10. Segurança adicional

• Access‑control restrito — item nº 1, sem exceção (seção 4).
• Hide version/identity — reduz informações para reconhecimento externo.
• Rate limiting — ratelimit: 1000 e ratelimit‑slabs: 4 limitam consultas/segundo por cliente.
• QNAME Minimisation — envia apenas a parte necessária do nome a cada servidor, reduzindo exposição.
• 0x20 encoding — mistura maiúsculas/minúsculas nas consultas para dificultar spoofing.
• Bloqueio de domínios maliciosos — via local‑zone: "dominio-malicioso.com" refuse, direto na configuração.
• RPZ (Response Policy Zones) — suporte nativo para bloquear/redirecionar domínios com base em listas externas.
• DNSSEC obrigatório — confiança na raiz (root.key) atualizada periodicamente.

11. Monitoramento e métricas

Script de health check para Zabbix/PRTG:

#!/bin/bash
# check_unbound.sh
dig @127.0.0.1 exemplo-isp.com.br A +short +time=2
if [ $? -eq 0 ]; then
  echo "OK: Unbound respondendo"
  exit 0
else
  echo "CRITICAL: Unbound não responde"
  exit 2
fi

Métricas úteis via unbound‑control stats: cache hit rate, consultas/segundo, tempo médio de recursão, uso de memória dos caches, número de consultas com DNSSEC validado. Monitore também a expiração da trust anchor (root.key).

12. Backup e recuperação

O Unbound é um resolvedor recursivo — não armazena zonas próprias. O backup é simples:

• Configuração — /etc/unbound/unbound.conf.d/ (incluindo chaves de API se usar unbound‑control).
• Trust anchor — /var/lib/unbound/root.key (pode ser recriado com unbound‑anchor, mas ter o backup agiliza a restauração).
• Cache — não precisa de backup; ele é reconstruído naturalmente após a reinicialização.

Use restic ou Borg com a regra 3‑2‑1‑1‑0. A restauração é trivial: reinstale o Unbound, restaure os arquivos de configuração e a trust anchor, reinicie o serviço.

13. Teste e verificação

# Validar sintaxe
unbound-checkconf

# Testar resolução
dig @10.0.0.5 exemplo-isp.com.br

# Confirmar validação DNSSEC (deve retornar SERVFAIL)
dig @10.0.0.5 dnssec-failed.org

# Estatísticas de cache/performance
unbound-control stats | grep -E "total.num|cache.hit"

14. Comparação com outros resolvedores

15. Troubleshooting

16. Glossário

17. Referências

• NLnet Labs — Documentação oficial Unbound (nlnetlabs.nl).
• RFC 4033/4034/4035 — DNSSEC (validação no resolvedor).
• RFC 7816 — DNS Query Name Minimisation.
• RFC 7858 — DNS over TLS (DoT).
• RFC 9156 — QNAME Minimisation revisada.
• Páginas relacionadas: DNSSEC, BIND9.

Conteúdo técnico independente. Nenhum trecho é cópia literal de fonte de terceiro.