Quando a empresa cresce e passa a hospedar vários domínios e subdomínios internos, depender só do DNS do provedor de hospedagem começa a incomodar — qualquer mudança demora pra propagar e você não tem controle sobre cache, zonas reversas ou redundância. Nesse ponto faz sentido subir seu próprio servidor DNS. Este guia mostra como fazer isso com o BIND9 no Linux, incluindo alguns detalhes que só aparecem na prática, depois que a zona já está no ar.
Os quatro papéis que um servidor DNS pode assumir
Antes de instalar qualquer coisa, vale entender que “servidor DNS” não é uma coisa só:
- Resolver — recebe a pergunta do cliente e devolve a resposta, seja do próprio cache ou perguntando pra outro servidor.
- Cache DNS — guarda respostas recentes pra não precisar perguntar de novo, reduzindo latência.
- Servidor autoritativo — é a fonte oficial das respostas para um domínio específico (é o que você vai configurar aqui).
- Servidor recursivo — vai atrás da resposta em outros servidores até achar, mesmo que isso signifique várias consultas em cadeia.
Na maioria dos casos de empresa pequena/média, você vai configurar o BIND como autoritativo para seus próprios domínios e como forwarder (encaminhando) pra resolvers públicos como 1.1.1.1 ou 8.8.8.8 no resto — não faz sentido tentar ser recursivo puro pra internet inteira.
Instalando o BIND9
Em Ubuntu ou Debian:
sudo apt update sudo apt install bind9 bind9utils bind9-doc -y
O pacote bind9utils não é obrigatório, mas traz o named-checkzone e o named-checkconf, que vão te poupar dor de cabeça mais adiante. Depois de instalar, confirme que o serviço subiu:
systemctl status bind9
Se o firewall (ufw) estiver ativo, libere a porta 53 em TCP e UDP, senão as consultas externas nunca vão chegar no servidor:
sudo ufw allow 53/tcp sudo ufw allow 53/udp
Configurando a zona primária
Edite o arquivo de zonas locais:
sudo nano /etc/bind/named.conf.local
Adicione a declaração da zona:
zone "meusite.com" {
type master;
file "/etc/bind/db.meusite";
};
Crie o arquivo de zona:
sudo nano /etc/bind/db.meusite
$TTL 86400
@ IN SOA ns1.meusite.com. admin.meusite.com. (
2024031001 ; Serial
3600 ; Refresh
1800 ; Retry
604800 ; Expire
86400 ) ; Negative Cache TTL
@ IN NS ns1.meusite.com.
@ IN A 192.168.1.100
ns1 IN A 192.168.1.100
www IN A 192.168.1.101
O campo que mais gente erra é o Serial. Ele precisa ser incrementado toda vez que você edita a zona — se você esquecer de subir esse número, o servidor secundário não percebe que houve mudança e continua servindo a versão antiga. Uma convenção prática é usar a data no formato AAAAMMDDXX (ano-mês-dia-revisão do dia), como no exemplo acima.
Antes de reiniciar o serviço, valide a sintaxe — isso evita subir uma zona quebrada em produção:
named-checkzone meusite.com /etc/bind/db.meusite named-checkconf
Se os dois comandos voltarem “OK”, reinicie:
sudo systemctl restart bind9
Não esqueça a zona reversa
Isso é o que a maioria dos tutoriais pula, e depois vira dor de cabeça quando algum sistema de e-mail rejeita suas mensagens por falta de PTR. Crie a zona reversa correspondente à sua faixa de IP:
zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.192";
};
$TTL 86400
@ IN SOA ns1.meusite.com. admin.meusite.com. (
2024031001 ; Serial
3600 ; Refresh
1800 ; Retry
604800 ; Expire
86400 ) ; Negative Cache TTL
@ IN NS ns1.meusite.com.
100 IN PTR ns1.meusite.com.
101 IN PTR www.meusite.com.
Configurando o servidor secundário
Redundância importa — se o primário cair, o secundário continua respondendo. No servidor secundário:
zone "meusite.com" {
type slave;
masters { 192.168.1.100; };
file "/var/cache/bind/db.meusite";
};
sudo systemctl restart bind9
Repare que o secundário não tem arquivo de zona escrito à mão — ele puxa (transferência de zona, ou AXFR) automaticamente do primário. Se isso não acontecer, o problema quase sempre é o primário não estar liberando transferência pro IP do secundário (parâmetro allow-transfer na configuração da zona).
Usando forwarders para o resto da internet
Pra tudo que não é seu domínio, faz sentido encaminhar as consultas pra um resolver público confiável em vez de deixar o BIND tentar resolver recursivamente sozinho. Em /etc/bind/named.conf.options:
forwarders {
1.1.1.1;
8.8.8.8;
};
Isso reduz bastante a latência pros usuários da rede interna, já que a Cloudflare e o Google mantêm infraestrutura de resposta muito mais rápida que qualquer coisa que você vai montar sozinho.
Testando a configuração
dig @192.168.1.100 meusite.com
Repare na seção ANSWER SECTION da saída — se ela vier vazia, o problema está na zona ou no BIND não estar ouvindo na interface certa. A seção Query time também ajuda a diagnosticar lentidão.
Problemas comuns
“rndc: connect failed” ou o serviço não sobe depois de editar a zona
Quase sempre é erro de sintaxe — um ponto e vírgula esquecido ou um ponto final faltando depois de um nome de domínio na zona. Rode named-checkzone antes de reiniciar, sempre.
Consultas externas não resolvem, mas de dentro do servidor funciona
Geralmente é firewall bloqueando a porta 53, ou o BIND configurado pra ouvir só em 127.0.0.1 em vez do IP da interface de rede real. Confira a diretiva listen-on em named.conf.options.
O servidor secundário não atualiza depois de uma mudança na zona
Nove em cada dez vezes é porque o Serial não foi incrementado no primário. O secundário compara o número antes de puxar a zona nova — se o número for igual, ele assume que nada mudou.
Segurança e otimização
Vale ativar o DNSSEC pra proteger contra falsificação de respostas, restringir quem pode fazer consultas recursivas com allow-recursion (nunca deixe isso aberto pra internet inteira, é convite pra ataque de amplificação DNS), e ligar o log de consultas com logging { channel query_log { ... }; }; pra auditoria e diagnóstico.
Depois que o DNS estiver no ar, vale acompanhar a saúde do servidor de perto — veja como monitorar o desempenho de servidores em tempo real. E se você ainda está testando tudo isso num ambiente local antes de ir pra produção, o guia de como configurar servidores locais com XAMPP também pode ajudar.
