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.

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.