BrbOS/Manual/DNS Boas Práticas

DNS Boas Práticas para Operadores de Resolver

Este documento descreve boas práticas para operação de servidores DNS recursivos em redes corporativas e provedores de internet.

As recomendações seguem diretrizes da iniciativa KINDNS, apoiada pela ICANN, que busca aumentar a segurança, privacidade e estabilidade do DNS na internet.

Essas práticas são recomendadas para:

• Provedores de Internet (ISP)
• Operadores de redes corporativas
• Ambientes acadêmicos
• Operadores de resolvers privados.

A adoção dessas recomendações reduz riscos operacionais, melhora a segurança e aumenta a confiabilidade do serviço DNS.

Boas Práticas já implementadas no BrbOS

O BrbOS foi desenvolvido seguindo recomendações modernas de operação de servidores DNS, incluindo diretrizes utilizadas por operadores de rede e organizações como a ICANN.

Diversas práticas descritas neste documento já estão presentes ou podem ser configuradas facilmente dentro do sistema.

Isso permite que provedores de internet e operadores de rede mantenham uma infraestrutura DNS segura, estável e alinhada com padrões internacionais.

Recurso	Descrição	Disponível no BrbOS
Controle de ACL	Permite restringir quais redes podem utilizar o resolver DNS.	Sim
DNSSEC Validation	Validação automática de assinaturas DNS para garantir autenticidade das respostas.	Sim
QNAME Minimization	Reduz vazamento de informações durante consultas DNS.	Sim
RPZ (Response Policy Zone)	Permite bloqueio ou redirecionamento de domínios maliciosos.	Sim
Importação de listas externas	Possibilidade de importar listas de bloqueio automaticamente.	Sim
Logs e auditoria	Registro de consultas DNS para diagnóstico e análise.	Sim
Alta performance	Resolver otimizado para ambientes de ISP e alto volume de consultas.	Sim

Proteção contra ameaças com BrbOS

Utilizando os recursos do BrbOS é possível implementar diversas camadas de proteção para os usuários da rede.

Entre elas:

• Bloqueio de domínios maliciosos
• Bloqueio de phishing
• Bloqueio de malware
• Aplicação de políticas por grupo de clientes
• Integração com listas externas.

Essas funcionalidades podem ser implementadas através do recurso de RPZ.

Exemplo de proteção ativa

Quando um domínio malicioso está presente em uma lista RPZ configurada no BrbOS, o acesso pode ser bloqueado automaticamente.

Exemplo de teste:

dig dominio-malicioso.com

Resposta possível:

status: NXDOMAIN

Ou redirecionamento para página de bloqueio:

dominio-malicioso.com CNAME bloqueio.provedor.local

Isso impede que usuários acessem domínios perigosos e aumenta a segurança da rede.

Vantagens para Provedores de Internet

Operar DNS com o BrbOS oferece diversas vantagens para ISPs:

• Implementação rápida de boas práticas DNS
• Proteção automática contra domínios maliciosos
• Facilidade de gerenciamento
• Monitoramento integrado
• Atualização automática de políticas.

Além disso, o sistema permite que operadores mantenham conformidade com recomendações internacionais de segurança DNS.

Infraestrutura recomendada com BrbOS

Exemplo de arquitetura recomendada para provedores:

Clientes
   |
BrbOS Resolver DNS
   |
Cache + Segurança + RPZ
   |
Internet

Essa arquitetura melhora:

• desempenho de navegação
• segurança da rede
• controle administrativo.

Conclusão

Ao seguir as boas práticas descritas neste documento e utilizar os recursos disponíveis no BrbOS, operadores podem oferecer um serviço DNS moderno, seguro e confiável para seus usuários.

O BrbOS foi projetado para simplificar a operação de redes e permitir que provedores implementem rapidamente padrões recomendados pela comunidade técnica internacional.

Objetivos das Boas Práticas

As boas práticas para resolvers DNS possuem alguns objetivos principais:

• Evitar abusos do serviço DNS
• Reduzir vazamentos de informação
• Garantir integridade das respostas DNS
• Melhorar disponibilidade da infraestrutura
• Proteger usuários contra ataques e manipulação de respostas.

Tipos de Servidores DNS

Tipo	Descrição
Resolver Privado	Disponível apenas para redes internas ou clientes autorizados.
Resolver de ISP	Utilizado por clientes de um provedor de internet.
Resolver Público	Disponível para qualquer usuário da internet.

Resolvers privados devem sempre limitar quem pode utilizar o serviço.

Controle de Acesso (ACL)

Um servidor DNS recursivo nunca deve aceitar consultas de toda a internet sem necessidade.

Isso evita:

• ataques de amplificação DNS
• consumo excessivo de recursos
• uso indevido do servidor.

Exemplo de comportamento esperado:

$ dig google.com @10.10.0.10

Resposta esperada para cliente autorizado:

;; status: NOERROR

Consulta de um IP não autorizado deve resultar em recusa:

;; status: REFUSED

Teste com nslookup:

nslookup google.com 10.10.0.10

Se configurado corretamente apenas redes autorizadas receberão resposta.

Separação de Funções DNS

Servidores DNS recursivos não devem operar como servidores autoritativos para domínios públicos.

Separar essas funções melhora:

• segurança
• desempenho
• estabilidade.

Arquitetura recomendada:

Clientes
   |
Resolver Recursivo
   |
Internet
   |
Servidores Autoritativos

Validação DNSSEC

Resolvers devem validar assinaturas DNSSEC para garantir autenticidade das respostas.

O DNSSEC protege contra:

• cache poisoning
• manipulação de respostas DNS
• ataques man-in-the-middle.

Teste de validação DNSSEC com dig:

dig @10.10.0.10 dnssec-failed.org

Resultado esperado:

status: SERVFAIL

Teste de domínio válido:

dig @10.10.0.10 cloudflare.com +dnssec

Resposta deve conter:

ad

A flag AD indica que a assinatura foi validada.

Teste com host:

host -v cloudflare.com 10.10.0.10

QNAME Minimization

QNAME minimization reduz a quantidade de informações enviadas para servidores autoritativos durante uma resolução.

Sem essa técnica o resolver envia o nome completo do domínio.

Com QNAME minimization ele envia apenas o necessário.

Exemplo de consulta DNS:

www.exemplo.site.com

Fluxo tradicional:

resolver -> root -> "www.exemplo.site.com"

Fluxo com minimization:

resolver -> root -> "com"
resolver -> TLD -> "site.com"
resolver -> autoritativo -> "www.exemplo.site.com"

Benefícios:

• mais privacidade
• menos exposição de dados
• melhor arquitetura DNS.

Proteção contra Amplificação DNS

Servidores abertos podem ser usados em ataques DDoS.

Medidas recomendadas:

• limitar consultas por ACL
• limitar tamanho de resposta
• habilitar Rate Limit.

Teste simples:

dig ANY google.com @SEU_DNS

Servidores bem configurados normalmente reduzem ou bloqueiam esse tipo de consulta.

Monitoramento do DNS

Operadores devem monitorar continuamente seus servidores DNS.

Itens importantes:

• latência de resolução
• falhas DNS
• consumo de CPU
• uso de memória
• tráfego.

Exemplo de teste simples de latência:

dig google.com @10.10.0.10

Tempo de resposta:

Query time: 8 msec

Testando múltiplas consultas:

for i in {1..10}; do dig google.com @10.10.0.10 +stats; done

Testes Básicos de Funcionamento

Testando resolução DNS

Usando dig:

dig google.com

Usando host:

host google.com

Usando nslookup:

nslookup google.com

Testando servidor específico

dig google.com @10.10.0.10

host google.com 10.10.0.10

nslookup google.com 10.10.0.10

Testando autoridade de domínio

dig NS google.com

Testando cadeia de resolução

dig +trace google.com

Isso mostra toda a cadeia desde os root servers.

Privacidade das Consultas DNS

Operadores devem considerar o uso de DNS criptografado.

Tecnologias recomendadas:

• DNS over TLS (DoT)
• DNS over HTTPS (DoH)
• DNS over QUIC (DoQ).

Benefícios:

• evita interceptação
• protege usuários
• impede manipulação de tráfego.

Redundância e Alta Disponibilidade

Ambientes de produção devem possuir múltiplos resolvers.

Exemplo:

DNS1 10.10.0.10
DNS2 10.10.0.11
DNS3 10.10.0.12

Boas práticas:

• servidores em locais diferentes
• redes diferentes
• monitoramento independente.

Checklist de Segurança DNS

Verificação	Recomendação
Resolver aberto	Não permitido
ACL configurada	Obrigatório
DNSSEC habilitado	Obrigatório
QNAME Minimization	Recomendado
Monitoramento ativo	Obrigatório
Redundância	Obrigatório
Logs DNS	Recomendado

Exemplos de Diagnóstico

Resolver não responde

dig google.com @10.10.0.10

Possíveis causas:

• firewall bloqueando
• serviço parado
• ACL incorreta.

Resposta muito lenta

Teste:

dig google.com @10.10.0.10 +stats

Verifique:

• latência de rede
• upstream DNS
• carga do servidor.

Domínio não resolve

dig dominio.com +trace

Esse comando mostra onde a resolução falha.

Conclusão

A correta implementação dessas boas práticas garante um serviço DNS:

• seguro
• resiliente
• confiável
• preparado para crescimento.

Operadores devem revisar periodicamente suas configurações DNS e acompanhar novas recomendações da comunidade técnica e da ICANN.