Miguel em 16h38min de 3 de março de 2026

2026-03-03T16:38:17Z

Miguel: Criou página com '=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 int...'

2026-03-03T16:29:32Z

Criou página com '=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 int...'

Página nova

=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=

{| class="wikitable"
! 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:

<blockquote><pre>
$ dig google.com @10.10.0.10
</pre></blockquote>

Resposta esperada para cliente autorizado:

<blockquote><pre>
;; status: NOERROR
</pre></blockquote>

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

<blockquote><pre>
;; status: REFUSED
</pre></blockquote>

Teste com nslookup:

<blockquote><pre>
nslookup google.com 10.10.0.10
</pre></blockquote>

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:

<pre>
Clientes
|
Resolver Recursivo
|
Internet
|
Servidores Autoritativos
</pre>

=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:

<blockquote><pre>
dig @10.10.0.10 dnssec-failed.org
</pre></blockquote>

Resultado esperado:

<blockquote><pre>
status: SERVFAIL
</pre></blockquote>

Teste de domínio válido:

<blockquote><pre>
dig @10.10.0.10 cloudflare.com +dnssec
</pre></blockquote>

Resposta deve conter:

<blockquote><pre>
ad
</pre></blockquote>

A flag AD indica que a assinatura foi validada.

Teste com host:

<blockquote><pre>
host -v cloudflare.com 10.10.0.10
</pre></blockquote>

=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:

<pre>
www.exemplo.site.com
</pre>

Fluxo tradicional:

<pre>
resolver -> root -> "www.exemplo.site.com"
</pre>

Fluxo com minimization:

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

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:

<blockquote><pre>
dig ANY google.com @SEU_DNS
</pre></blockquote>

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:

<blockquote><pre>
dig google.com @10.10.0.10
</pre></blockquote>

Tempo de resposta:

<blockquote><pre>
Query time: 8 msec
</pre></blockquote>

Testando múltiplas consultas:

<blockquote><pre>
for i in {1..10}; do dig google.com @10.10.0.10 +stats; done
</pre></blockquote>

=Testes Básicos de Funcionamento=

==Testando resolução DNS==

Usando dig:

<blockquote><pre>
dig google.com
</pre></blockquote>

Usando host:

<blockquote><pre>
host google.com
</pre></blockquote>

Usando nslookup:

<blockquote><pre>
nslookup google.com
</pre></blockquote>

==Testando servidor específico==

<blockquote><pre>
dig google.com @10.10.0.10
</pre></blockquote>

<blockquote><pre>
host google.com 10.10.0.10
</pre></blockquote>

<blockquote><pre>
nslookup google.com 10.10.0.10
</pre></blockquote>

==Testando autoridade de domínio==

<blockquote><pre>
dig NS google.com
</pre></blockquote>

==Testando cadeia de resolução==

<blockquote><pre>
dig +trace google.com
</pre></blockquote>

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:

<pre>
DNS1 10.10.0.10
DNS2 10.10.0.11
DNS3 10.10.0.12
</pre>

Boas práticas:

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

=Checklist de Segurança DNS=

{| class="wikitable"
! 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==

<blockquote><pre>
dig google.com @10.10.0.10
</pre></blockquote>

Possíveis causas:

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

==Resposta muito lenta==

Teste:

<blockquote><pre>
dig google.com @10.10.0.10 +stats
</pre></blockquote>

Verifique:

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

==Domínio não resolve==

<blockquote><pre>
dig dominio.com +trace
</pre></blockquote>

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.

__NOEDITSECTION__

@@ Linha 13: / Linha 13: @@
 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=
@@ Linha 370: / Linha 488: @@
 Operadores devem revisar periodicamente suas configurações DNS e acompanhar novas recomendações da comunidade técnica e da ICANN.
 __NOEDITSECTION__

BrbOS/Manual/DNS Boas Práticas - Histórico de revisão

Miguel em 16h38min de 3 de março de 2026

Miguel: Criou página com '=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 int...'