DNS autoritativo no Brasil em VPS: como escolher

Resposta direta

Uma VPS para servidor DNS autoritativo no Brasil faz sentido quando você precisa controlar zonas DNS, reduzir latência para usuários brasileiros, publicar IPv6, usar DNSSEC ou manter uma arquitetura própria com servidores primário e secundário. Para produção básica, comece com pelo menos 1 vCPU, 1 GB de RAM, 20 GB de SSD, IPv4 fixo, IPv6, firewall configurável e monitoramento externo. Em ambientes críticos, use no mínimo dois servidores autoritativos em regiões, provedores ou redes diferentes, com transferência de zona segura via TSIG e restrição de IP. O ponto central não é potência bruta. DNS autoritativo consome poucos recursos, mas depende muito de disponibilidade, rede estável, baixa latência, logs, backups da configuração e proteção contra abuso na porta 53.

Resumo rápido

• DNS autoritativo responde pelas zonas que você controla, como exemplo.com.br, e não deve ser confundido com DNS recursivo aberto.
• Para um servidor pequeno, 1 vCPU, 1 GB de RAM e 20 GB de SSD costumam ser suficientes, desde que a rede seja estável e o serviço esteja bem configurado.
• Baixa latência no Brasil ajuda em consultas feitas por resolvedores nacionais, especialmente quando o domínio atende público local.
• IPv6 é recomendável para novos ambientes, tanto por compatibilidade futura quanto por boas práticas de conectividade.
• Produção real pede pelo menos dois servidores autoritativos, preferencialmente em localidades, provedores ou redes diferentes.
• Firewall, rate limit, DNSSEC, TSIG, logs e monitoramento externo são tão importantes quanto CPU e RAM.
• LetsCloud, DigitalOcean, Vultr, Linode, AWS Lightsail e outros provedores podem entrar na análise, mas localização, IPv6, bandwidth e recursos variam por plano e precisam ser conferidos antes da contratação.

Quando faz sentido hospedar DNS autoritativo em VPS

Hospedar DNS autoritativo em VPS é uma boa escolha quando você quer controle fino sobre zonas, registros, TTLs, DNSSEC, automação e logs. Em vez de depender apenas do painel de um registrador ou de um DNS gerenciado, você opera o servidor que responde oficialmente por um domínio. Isso abre espaço para cenários mais técnicos, como integração com CI/CD, geração automática de registros, delegação de subzonas, ambientes multi-tenant para clientes e políticas próprias de auditoria.

DNS autoritativo não é resolvedor recursivo

O primeiro cuidado é separar conceitos. Um servidor DNS autoritativo responde por zonas específicas, por exemplo empresa.com.br, api.empresa.com.br ou uma zona reversa delegada pelo provedor. Ele não deve funcionar como resolvedor recursivo público para a internet. Um recursivo aberto é alvo fácil para abuso, amplificação de tráfego e bloqueios. Em BIND, por exemplo, uma configuração básica de autoritativo deve manter recursion no; e restringir consultas auxiliares. Em Knot DNS, o foco natural já é servir zonas autoritativas com alta eficiência.

Esse tipo de VPS costuma atender bem agências, SaaS pequenos, provedores regionais, times DevOps e empresas que precisam de controle técnico sem contratar uma plataforma DNS corporativa. Um caso comum é uma agência que hospeda 200 domínios de clientes e quer padronizar TTL de 300 segundos para mudanças rápidas, manter registros SPF, DKIM e DMARC consistentes, e auditar alterações por Git. Outro exemplo é um SaaS B2B que cria subdomínios por cliente e prefere automatizar a publicação via API própria.

VPS, Cloud Server e DNS gerenciado

VPS tradicional e Cloud Server não são exatamente a mesma coisa. Na VPS clássica, você recebe uma máquina virtual em um host físico, com recursos fixos e menos elasticidade. Em Cloud Server, o provedor normalmente oferece provisionamento mais rápido, painel de rede, snapshots, resize e infraestrutura distribuída, embora os detalhes mudem muito entre empresas. Para DNS autoritativo, os dois modelos podem funcionar. A diferença pesa mais em operação, recuperação e rede do que em processamento.

DNS gerenciado ainda pode ser a melhor opção quando você precisa de anycast global, mitigação DDoS especializada e SLA formal de DNS. Já a VPS ganha pontos quando você precisa de autonomia, scripts próprios e baixo custo operacional para zonas controladas. Se o público principal está no país, faz sentido ler também o guia de VPS para baixa latência no Brasil, porque a localização do datacenter pode reduzir alguns milissegundos por consulta quando os resolvedores ficam próximos da sua infraestrutura.

Requisitos técnicos para DNS autoritativo no Brasil

DNS autoritativo é leve em CPU, mas exigente em disponibilidade. Uma consulta UDP para registro A, AAAA, MX ou TXT consome pouco processamento. Mesmo assim, o servidor precisa responder rápido, manter a porta 53 aberta em UDP e TCP, lidar com picos e não cair por falta de memória durante reloads de zona, validação DNSSEC ou rotação de logs. O erro comum é escolher a VPS mais barata sem olhar rede, IPv6, política de tráfego, proteção básica e estabilidade do provedor.

CPU, RAM e disco

Para um ambiente pequeno com até algumas centenas de zonas e tráfego moderado, 1 vCPU, 1 GB de RAM e 20 GB de SSD são um ponto de partida razoável. BIND, Knot DNS e NSD podem rodar com folga nesse perfil se o sistema estiver enxuto, por exemplo Debian ou Ubuntu Server sem painel pesado. Se você pretende assinar zonas com DNSSEC, manter logs detalhados por mais tempo ou operar milhares de zonas, considere 2 vCPUs, 2 GB de RAM e 40 GB de SSD. O disco não precisa ser enorme, mas deve ser confiável. Arquivos de zona, journals, chaves DNSSEC, logs e backups locais ocupam pouco, porém não podem ficar em um volume sem rotina de cópia.

Um exemplo prático: um servidor autoritativo para 50 domínios institucionais, cada um com 20 registros, pode operar confortavelmente em 1 vCPU e 1 GB de RAM. Já uma agência com 1.500 zonas, DNSSEC ativado e deploy automatizado a cada hora tende a se beneficiar de 2 vCPUs e 2 GB de RAM, principalmente para reloads e validações. Se o software escolhido for PowerDNS com backend SQL, inclua o banco na conta. MariaDB ou PostgreSQL no mesmo host exigem mais memória e ajustes de cache.

Rede, latência e IPv6

A rede é o coração do DNS. Procure IPv4 dedicado, IPv6 nativo, porta 53 liberada para UDP e TCP, reverse DNS quando necessário, tráfego mensal compatível e baixa perda de pacotes. O TCP na porta 53 não é opcional. Ele aparece em respostas grandes, transferências de zona e cenários com DNSSEC. Bloquear TCP 53 cria falhas difíceis de diagnosticar, especialmente quando registros TXT grandes ou respostas assinadas entram em jogo.

IPv6 merece atenção especial. Muitos domínios já publicam AAAA para serviços principais, e servidores autoritativos também podem ter glue records IPv6 quando a delegação exige. Se esse ponto está no seu radar, veja o conteúdo sobre VPS com IPv6 no Brasil, porque disponibilidade de IPv6, blocos atribuídos e configuração de gateway variam bastante. Para um servidor autoritativo moderno, o ideal é publicar A e AAAA para os nameservers, testar conectividade com dig @ns1.exemplo.com.br exemplo.com.br SOA +tcp e monitorar resposta por IPv4 e IPv6 separadamente.

Arquitetura recomendada: primário, secundário e redundância

Rodar apenas um servidor autoritativo é aceitável para laboratório, mas frágil para produção. A prática recomendada é ter pelo menos dois nameservers, por exemplo ns1.exemplo.com.br e ns2.exemplo.com.br, em VPS diferentes. Melhor ainda se eles estiverem em localidades, provedores ou sistemas autônomos distintos. O objetivo é simples: uma manutenção, falha de rede, bloqueio de rota ou indisponibilidade regional não deve derrubar a resolução do domínio inteiro.

Separação geográfica e ASN

No Brasil, você pode usar um servidor em São Paulo e outro em outra região nacional, ou combinar Brasil com Miami, Santiago ou outra localidade próxima, dependendo do público e da disponibilidade do provedor. A escolha não precisa ser perfeita para todos os domínios. Para um e-commerce que atende majoritariamente clientes brasileiros, manter um autoritativo no Brasil reduz latência para resolvedores locais. Para uma empresa com usuários na América Latina, um secundário fora do país pode melhorar resiliência regional.

Separar provedores também reduz risco operacional. Um desenho comum é usar uma VPS nacional como primária oculta, ou seja, sem receber consultas públicas, e dois secundários públicos em redes diferentes. Outra opção é manter ns1 em uma VPS no Brasil e ns2 em um Cloud Server internacional com boa conectividade. LetsCloud pode entrar na análise quando a prioridade for presença local e simplicidade de contratação, mas recursos como localidade, tipo de storage, IPv6, snapshots e backup precisam ser verificados no site oficial antes da publicação ou compra. O mesmo cuidado vale para DigitalOcean, Vultr, Linode, AWS Lightsail, Hetzner e Contabo, já que regiões e políticas mudam.

Transferência de zona segura

A transferência de zona deve ser restrita. Em BIND, use allow-transfer apontando apenas para os IPs dos secundários e proteja com TSIG. Um exemplo simplificado seria criar uma chave com tsig-keygen -a hmac-sha256 xfr-key, cadastrar a chave no primário e no secundário, e permitir AXFR apenas para o endereço autorizado. Não exponha a chave em repositório público, imagem de container ou documentação aberta.

O fluxo operacional pode ser assim: alterações entram em um repositório Git privado, um pipeline valida sintaxe com named-checkzone, aplica no primário, incrementa o serial do SOA e os secundários puxam a nova versão. Em ambientes menores, um script com rsync e reload controlado resolve. Em ambientes mais maduros, PowerDNS com API autenticada permite atualizar registros com controle de acesso. Em todos os casos, monitore o serial entre servidores. Se ns1 responde serial 2026080401 e ns2 continua em 2026080302, há atraso de replicação que precisa ser corrigido antes de virar incidente.

Segurança operacional: firewall, hardening e monitoramento

Um servidor DNS autoritativo fica exposto por natureza. Ele precisa receber consultas públicas na porta 53, normalmente em UDP e TCP. Isso não significa deixar o restante do sistema aberto. SSH, painel administrativo, API do PowerDNS, banco de dados e métricas devem ser restritos por IP, VPN, firewall ou rede privada. A base segura começa no sistema operacional atualizado, usuário sem login direto como root, autenticação SSH por chave, bloqueio de senha e regras claras de entrada.

Portas, rate limit e chaves

Uma política simples de firewall libera UDP 53 e TCP 53 para a internet, SSH apenas para IPs administrativos, e fecha todo o resto. Com ufw, por exemplo, você poderia usar ufw default deny incoming, ufw allow 53/udp, ufw allow 53/tcp e ufw allow from 200.0.113.10 to any port 22 proto tcp, ajustando o IP real da sua rede. Em produção, prefira regras explícitas no firewall do provedor e no host. Ter duas camadas reduz dano quando alguém altera uma delas por engano.

Rate limiting ajuda contra abuso, mas precisa ser configurado com cuidado. No BIND, Response Rate Limiting pode reduzir amplificação em consultas repetitivas. Em Knot DNS, há recursos de controle de resposta e tuning de rede. O objetivo não é bloquear clientes legítimos, e sim diminuir impacto de padrões claramente abusivos. Também revise permissões de arquivos: chaves DNSSEC, TSIG e credenciais de API devem pertencer ao usuário do serviço ou a root, com permissões como 0600 quando aplicável.

Para um checklist mais amplo de proteção de sistema, o guia de VPS com firewall e hardening de segurança complementa bem este tema. DNS é só uma parte da superfície. O host ainda precisa de atualização automática de pacotes críticos, logs preservados, proteção contra brute force no SSH e plano de recuperação caso uma configuração quebre.

Logs e observabilidade

Monitoramento externo é obrigatório. Não basta olhar se o processo está ativo via systemctl status named. Você precisa testar a resposta real a partir de fora da VPS. Ferramentas como Zabbix, Prometheus com exporters, Uptime Kuma, RIPE Atlas, DNSViz e checks simples com dig ajudam a detectar falhas. Um teste útil é consultar SOA, NS, A e AAAA por UDP e TCP, em IPv4 e IPv6, a cada minuto. Se o servidor responde localmente, mas falha de fora, o problema pode estar em firewall, rota, provedor ou delegação.

Guarde logs por tempo suficiente para investigar incidentes, mas sem lotar o disco. Em uma VPS de 20 GB, logs verbosos de consultas podem crescer rápido se você registrar tudo. Uma alternativa é logar erros, transferências de zona, alterações e eventos de segurança, deixando query log completo apenas para janelas de diagnóstico. Configure logrotate, alarme de uso de disco acima de 80% e backup diário dos arquivos de zona. DNS raramente consome CPU demais, mas um disco cheio pode derrubar reloads e impedir atualização de serial.

Comparação prática de perfis e recursos

Escolher VPS para DNS autoritativo fica mais simples quando você separa perfil de uso, risco e volume. Um blog pessoal com dois domínios não precisa da mesma arquitetura de um SaaS que cria milhares de subdomínios para clientes. Ao mesmo tempo, mesmo o cenário pequeno precisa de redundância se o domínio for relevante. A tabela abaixo não compara preço, porque valores, promoções e recursos mudam com frequência e exigem revisão humana antes de publicação. O foco é dimensionamento técnico.

Tabela de dimensionamento

Perfil de uso	Configuração sugerida	Arquitetura DNS	Recursos de rede	Observações operacionais
Laboratório ou domínio pessoal	1 vCPU, 512 MB a 1 GB RAM, 10 a 20 GB SSD	1 VPS para testes, sem missão crítica	IPv4 fixo, TCP e UDP 53 liberados	Não indicado como único DNS de domínio importante
Agência pequena ou projetos próprios	1 a 2 vCPUs, 1 a 2 GB RAM, 20 a 40 GB SSD	2 VPS, primário e secundário	IPv4, IPv6, monitoramento externo	Use TSIG, backup diário e validação de zona antes do reload
SaaS ou produção crítica	2 vCPUs ou mais, 2 a 4 GB RAM, 40 GB SSD ou mais	2 a 4 autoritativos, redes diferentes	IPv4, IPv6, baixa perda, checks por região	Considere DNSSEC, secundários externos e plano de incidente
Provedor ou ambiente multi-tenant	4 vCPUs, 4 GB RAM ou mais, storage confiável	Primário oculto, múltiplos secundários públicos	IPv6, automação, API protegida	PowerDNS ou Knot podem facilitar automação e alto volume

Como interpretar os números

Essas configurações não são limites rígidos. Um servidor com 1 vCPU pode responder milhares de consultas por segundo com software eficiente e zona pequena, mas isso não garante resiliência contra picos, falhas de rota ou ataques volumétricos. Performance de DNS depende de cache dos resolvedores, tamanho das respostas, DNSSEC, latência, kernel, rede e qualidade do provedor. Sem benchmark próprio, qualquer promessa de QPS deve ser tratada com cautela.

Na prática, o melhor investimento costuma ser redundância antes de expansão vertical. Em vez de colocar 8 GB de RAM em um único servidor DNS, faz mais sentido manter dois ou três nós menores em redes diferentes. Se o primário cair, os secundários continuam respondendo enquanto o TTL e a delegação estiverem corretos. Um TTL de 300 segundos é útil para registros que mudam com frequência, mas registros NS e glue precisam ser planejados com calma, porque alterações no registrador podem levar mais tempo para propagar entre caches.

Também pense no tráfego de zona. Transferências AXFR completas podem ser pesadas se você tem muitas zonas grandes, mas em ambientes normais o volume é pequeno. IXFR reduz dados transferidos quando suportado e configurado corretamente. Para TXT extensos, como SPF, DKIM e verificações de serviços, teste respostas com dig +short TXT dominio.com.br e dig dominio.com.br TXT +bufsize=1232. Isso ajuda a evitar fragmentação UDP problemática, especialmente com DNSSEC.

Exemplos de configuração com BIND, Knot e PowerDNS

A escolha do software influencia operação, não apenas consumo de recursos. BIND é tradicional, muito documentado e flexível. Knot DNS é conhecido por eficiência e foco autoritativo. NSD também é uma opção sólida para autoritativo puro. PowerDNS brilha quando você precisa de API, backend SQL e integração com sistemas internos. Em VPS pequenas, todos podem funcionar, desde que você mantenha o sistema enxuto e evite painéis pesados no mesmo host.

BIND em VPS pequena

Um exemplo básico com BIND em Debian seria instalar bind9, criar a zona em /etc/bind/zones/db.exemplo.com.br, validar com named-checkzone exemplo.com.br /etc/bind/zones/db.exemplo.com.br e recarregar com rndc reload. Na configuração global, mantenha recursão desligada para clientes externos. Um trecho conceitual seria recursion no;, allow-query { any; }; e allow-transfer { key xfr-key; 198.51.100.20; };, ajustando endereços e chaves. Nunca copie esse modelo sem revisar sintaxe, permissões e política de rede.

Para DNSSEC, BIND pode automatizar assinatura com políticas modernas, mas isso aumenta responsabilidade. Você precisa proteger chaves, acompanhar expiração, publicar DS no registrador e testar com DNSViz. Um erro em DNSSEC pode deixar o domínio indisponível para resolvedores validadores, mesmo quando o servidor responde. Em produção, faça primeiro em uma zona de teste, use TTL baixo durante migração e documente o procedimento de rollback.

Knot DNS para zonas de alto volume

Knot DNS costuma ser atraente quando você quer um autoritativo eficiente, com configuração limpa e bom desempenho. Em uma VPS com 2 vCPUs e 2 GB de RAM, ele pode atender muitos cenários com baixa sobrecarga. A lógica operacional é parecida: definir zonas, configurar ACL para transferência, proteger chaves TSIG e monitorar serial. Um cuidado prático é testar reloads com volume real de zonas antes de migrar. Ambientes com milhares de arquivos pequenos podem sofrer mais com organização de disco, automação ruim e validação lenta do que com o daemon DNS em si.

Knot também combina bem com primário oculto e secundários públicos. O primário recebe alterações, assina quando necessário e notifica os secundários. Os secundários respondem ao mundo. Esse desenho reduz exposição do nó que recebe automações internas. Para times que trabalham com GitOps, o pipeline pode gerar arquivos de zona, rodar validação, aplicar no primário oculto e esperar confirmação de transferência. Se o serial não aparece nos secundários em poucos minutos, o deploy deve falhar e alertar o time.

PowerDNS com backend estruturado

PowerDNS é interessante quando registros vêm de um painel, sistema de clientes ou API. Com backend SQL, você consegue criar, alterar e auditar registros de forma estruturada. O custo é maior complexidade. A VPS passa a rodar serviço DNS, banco de dados e talvez uma API administrativa. Para produção pequena, 2 vCPUs e 2 GB de RAM são um ponto de partida mais confortável do que 1 GB. Em produção crítica, separe banco e DNS quando possível, ou use réplica e backup frequente.

Um caso realista é um provedor regional que precisa criar zonas para clientes automaticamente. O painel grava no banco, PowerDNS publica os registros e secundários externos recebem transferências. A API deve ficar atrás de firewall, autenticação forte e, se possível, VPN. Registros de auditoria precisam indicar quem alterou, quando alterou e qual era o valor anterior. Isso parece burocrático até alguém apagar um MX de cliente em horário comercial. Nessa hora, histórico e rollback salvam tempo.

Recomendações por perfil

Dev solo

Para um dev solo, o caminho mais seguro é começar pequeno e não complicar a arquitetura antes da hora. Use 1 vCPU, 1 GB de RAM e 20 GB de SSD para laboratório ou domínios pessoais, com BIND, NSD ou Knot DNS em uma distribuição LTS. Ative IPv6 se o provedor oferecer de forma estável, publique A e AAAA para o nameserver e teste tudo com dig por UDP e TCP. Se o domínio for importante para clientes ou receita, não rode apenas um servidor. Combine sua VPS com um secundário em outro provedor ou serviço DNS secundário. Documente comandos de reload, backup e restauração.

Agência ou time pequeno

Agências e times pequenos devem priorizar repetibilidade. O ideal é manter duas VPS, uma primária e uma secundária, com 1 a 2 vCPUs, 1 a 2 GB de RAM e 20 a 40 GB de SSD cada. Coloque zonas em Git privado, valide com named-checkzone ou ferramenta equivalente, use TSIG para transferência e monitore serial entre nós. TTL de 300 ou 600 segundos ajuda em migrações de sites, mas não substitui planejamento. Para clientes que dependem muito de e-mail, revise SPF, DKIM, DMARC e MX com cuidado. Erro em DNS nem sempre derruba o site, às vezes quebra entrega de e-mail por dias.

Produção crítica

Em produção crítica, trate DNS como infraestrutura essencial, não como detalhe do domínio. Use pelo menos dois autoritativos públicos em redes diferentes, de preferência três se o custo operacional permitir. Considere um primário oculto para automação e secundários expostos para consulta. Dimensione cada nó com 2 vCPUs, 2 a 4 GB de RAM e 40 GB de SSD, mais monitoramento externo por IPv4 e IPv6. Ative DNSSEC apenas com processo testado, rotação documentada e validação contínua. Se o risco de DDoS for alto ou o negócio exigir SLA formal, avalie DNS gerenciado com anycast como complemento ou substituto. VPS própria dá controle, mas também transfere a responsabilidade de operação para o seu time.