BIND9

1. Contexto histórico e normativo

O BIND (Berkeley Internet Name Domain) foi criado em 1984 na Universidade da Califórnia, Berkeley, como parte do projeto BSD. É a implementação de DNS mais antiga ainda em uso ativo — a primeira a implementar o protocolo definido nas RFC 1034 (conceitos) e RFC 1035 (implementação), que até hoje formam a base do sistema de nomes da internet. Atualmente é mantido pelo ISC (Internet Systems Consortium), mesma organização responsável pelo DHCP de referência e pelo projeto DNSSEC.

O BIND acumula mais de 40 anos de desenvolvimento contínuo, o que lhe confere uma base de código madura e suporte a praticamente todos os RFCs de DNS já publicados. Por outro lado, essa longevidade também trouxe complexidade e um histórico de vulnerabilidades (como o famoso DNS cache poisoning descoberto por Dan Kaminsky em 2008). As versões modernas (9.16+) incorporaram melhorias significativas de performance com o novo networking stack baseado em libuv.

2. Arquitetura interna

O BIND9 é composto por um daemon principal (named) que pode atuar simultaneamente como servidor autoritativo (responde por zonas próprias) e resolvedor recursivo (consulta outros servidores em nome de clientes locais). Em produção, considera‑se boa prática separar essas funções em instâncias ou servidores diferentes.

Um dos recursos mais poderosos do BIND são as views — permitem servir respostas diferentes para clientes diferentes com base em sua origem (IP de consulta). Isso é essencial para Split DNS: responder com IPs internos para consultas originadas dentro do ISP, e com IPs públicos para consultas externas (seção 8).

3. Instalação (Debian/Ubuntu)

apt update
apt install bind9 bind9utils bind9-doc dnsutils

systemctl enable bind9
systemctl status bind9

4. Estrutura de arquivos

• /etc/bind/named.conf — arquivo raiz, apenas inclui os demais
• /etc/bind/named.conf.options — opções globais (recursão, forwarders, ACLs)
• /etc/bind/named.conf.local — declaração de zonas próprias
• /etc/bind/named.conf.default-zones — zonas padrão (localhost, root hints)
• /var/cache/bind/ — arquivos de zona (por convenção Debian)

5. Tipos de registros DNS essenciais

6. Zona master

// named.conf.local
zone "exemplo-isp.com.br" {
    type master;
    file "/var/cache/bind/db.exemplo-isp.com.br";
    allow-transfer { 203.0.113.10; };  // IP do slave — nunca "any"
    also-notify { 203.0.113.10; };
};

; /var/cache/bind/db.exemplo-isp.com.br
$TTL 3600
@   IN SOA ns1.exemplo-isp.com.br. admin.exemplo-isp.com.br. (
        2026080901  ; serial — YYYYMMDDNN — sempre incrementar
        3600        ; refresh
        900         ; retry
        1209600     ; expire
        3600 )      ; negative cache TTL
@       IN NS   ns1.exemplo-isp.com.br.
@       IN NS   ns2.exemplo-isp.com.br.
ns1     IN A    203.0.113.1
ns2     IN A    203.0.113.10
@       IN A    203.0.113.20
www     IN CNAME @
radius  IN A    10.0.0.5

Serial é a causa nº 1 de "mudei o registro e o slave não atualizou". O slave só transfere se o serial do master for maior que o local.

7. Zona slave (secundário)

// named.conf.local — servidor secundário
zone "exemplo-isp.com.br" {
    type slave;
    file "/var/cache/bind/db.exemplo-isp.com.br.slave";
    masters { 203.0.113.1; };
};

O slave baixa a zona automaticamente via AXFR/IXFR ao iniciar — não é preciso criar o arquivo manualmente.

8. Views — Split DNS

Views permitem ao BIND responder de forma diferente conforme a origem da consulta. O uso mais comum em ISPs é Split DNS: clientes internos resolvem radius.exemplo-isp.com.br para 10.0.0.5 (IP privado), enquanto consultas externas recebem o IP público.

acl "internos" { 10.0.0.0/8; 172.16.0.0/12; };

view "interno" {
    match-clients { "internos"; };
    recursion yes;
    zone "exemplo-isp.com.br" {
        type master;
        file "/var/cache/bind/db.exemplo-isp-interno";
    };
};

view "externo" {
    match-clients { any; };
    recursion no;
    zone "exemplo-isp.com.br" {
        type master;
        file "/var/cache/bind/db.exemplo-isp-externo";
    };
};

9. Verificação de sintaxe

# Validar configuração
named-checkconf

# Validar arquivo de zona
named-checkzone exemplo-isp.com.br /var/cache/bind/db.exemplo-isp.com.br

# Recarregar sem derrubar o serviço
rndc reload

# Testar resolução
dig @203.0.113.1 exemplo-isp.com.br A +short

10. Assinatura DNSSEC

Ver página completa de DNSSEC para a teoria. Aqui, o fluxo prático mínimo:

# Gerar KSK e ZSK (ECDSAP256SHA256 recomendado)
dnssec-keygen -a ECDSAP256SHA256 -f KSK exemplo-isp.com.br
dnssec-keygen -a ECDSAP256SHA256 exemplo-isp.com.br

# Assinar a zona
dnssec-signzone -o exemplo-isp.com.br -N INCREMENT -K /etc/bind/keys db.exemplo-isp.com.br

# Apontar zona master para o arquivo .signed
# Enviar registro DS ao registrador (registro.br)

11. Segurança e hardening

• Restringir transferência de zona — nunca allow-transfer { any; }, apenas IPs dos slaves.
• Desabilitar recursão no autoritativo — recursion no; em servidores públicos.
• Ocultar versão — version none; nas options.
• Rodar em ambiente restrito — o BIND já usa chroot e capabilities em distros modernas.
• DNSSEC — assinar zonas para prevenir envenenamento de cache.
• RPZ (Response Policy Zones) — bloquear domínios maliciosos no resolvedor.
• TSIG — autenticar transferências de zona com chave criptográfica, não só por IP.

12. Rate limiting anti‑amplificação

Servidores DNS abertos são alvo clássico de ataques de amplificação. O BIND9 oferece rate-limit nas opções globais:

rate-limit {
    responses-per-second 10;
    referrals-per-second 5;
    nodata-per-second 5;
    nxdomains-per-second 5;
    window 5;
    log-only no;
};

13. Monitoramento e métricas

O BIND expõe estatísticas via canal de controle (rndc stats). Script para Zabbix/PRTG:

#!/bin/bash
# check_bind.sh — verifica se o BIND responde a consultas
dig @localhost exemplo-isp.com.br SOA +short +time=2
if [ $? -eq 0 ]; then
  echo "OK: BIND respondendo"
  exit 0
else
  echo "CRITICAL: BIND não responde"
  exit 2
fi

Métricas úteis: consultas/segundo, taxa de sucesso/erro, latência de resposta, uso de cache. O BIND exporta via XML (estatísticas) ou SNMP.

14. Dimensionamento

Um BIND9 em hardware modesto (4 vCPUs, 8 GB RAM, SSD) consegue lidar com dezenas de milhares de consultas/segundo em modo autoritativo. Para recursivo, a carga é maior devido ao cache. Recomendações:

• Até 5.000 QPS — 2 vCPUs, 4 GB RAM, SSD.
• 5.000–50.000 QPS — 4+ vCPUs, 8 GB RAM, NVMe.
• Acima de 50.000 QPS — considerar anycast com múltiplos servidores.
• Monitorar rndc stats para ajustar max-cache-size e recursive-clients.

15. Backup e recuperação

O que deve ser backupeado em um servidor BIND9:

• Arquivos de zona (/var/cache/bind/db.*) — essenciais para restaurar o serviço.
• Configuração (/etc/bind/named.conf*) — ACLs, views, opções.
• Chaves DNSSEC (/etc/bind/keys/) — perdê‑las significa re‑assinar tudo e atualizar registros DS.
• Arquivos de journal (.jnl) — contêm alterações incrementais.

Use restic ou Borg com a regra 3‑2‑1‑1‑0. Teste a restauração periodicamente: recrie o BIND em um servidor de teste, carregue as zonas e execute dig para validar.

16. Comparativo com outros servidores DNS

17. Troubleshooting

18. Glossário

19. Referências

• RFC 1034 — Domain Names — Concepts and Facilities.
• RFC 1035 — Domain Names — Implementation and Specification.
• RFC 1912 — Common DNS Operational and Configuration Errors.
• RFC 4033/4034/4035 — DNSSEC (ver DNSSEC).
• ISC — Documentação oficial BIND9 (isc.org/bind).
• Páginas relacionadas: DNSSEC, PowerDNS, Unbound.

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