DNS
DNS recursivo, autoritativo e reverso: diferenças, funções e como diagnosticar
Entenda a diferença entre DNS recursivo, autoritativo e reverso, como uma consulta é resolvida, por que separar as funções, delegação reversa de blocos IP e diagnóstico com dig.
Por Rodrigo Borges, BTECH Automations · · 11 min de leitura
Quase todo problema de "a internet está lenta" ou "o e-mail está caindo no spam" em um provedor passa pelo DNS. E boa parte das confusões vem de tratar como uma coisa só três funções diferentes: o DNS recursivo, que resolve nomes para os seus clientes, o DNS autoritativo, que responde pelos seus domínios, e o DNS reverso, que traduz os seus IPs de volta para nomes.
Neste tutorial você vai entender o papel de cada um, o caminho completo de uma consulta, por que as funções devem ficar em servidores separados, como funciona a delegação reversa de blocos IPv4 e IPv6 e quais testes com o dig mostram rapidamente onde está o problema.
As três funções em uma tabela
| Função | Pergunta que responde | Quem consulta |
|---|---|---|
| Recursivo | "Qual o IP de qualquer nome da internet?" | Só os seus clientes e servidores |
| Autoritativo | "Qual o IP dos nomes do meu domínio?" | Toda a internet |
| Reverso | "Qual o nome deste IP do meu bloco?" | Toda a internet |
Os softwares mais usados como recursivo são o Unbound, o BIND, o PowerDNS Recursor e o Knot Resolver. Como autoritativo, o BIND, o NSD, o Knot DNS e o PowerDNS Authoritative.
Repare que o reverso não é um terceiro tipo de servidor: é uma zona autoritativa com registros PTR, servida pelos mesmos softwares. Ele aparece separado porque a delegação e a manutenção funcionam de um jeito próprio.
O caminho de uma consulta
Quando o cliente acessa www.exemplo.com.br, o computador dele não sai perguntando pela internet. Ele pergunta a um único servidor, o recursivo configurado (normalmente o do provedor, entregue por DHCP ou PPPoE), e esse servidor faz todo o trabalho:
- O recursivo procura a resposta no cache. Se alguém já perguntou e o TTL não expirou, responde na hora.
- Sem cache, pergunta a um servidor raiz, que não sabe o IP, mas indica quem responde por
.br. - Pergunta aos servidores do .br, que indicam quem responde por
exemplo.com.br(os servidores NS cadastrados no Registro.br). - Pergunta ao autoritativo de
exemplo.com.br, que finalmente devolve o IP dewww. - O recursivo guarda a resposta no cache pelo tempo do TTL e entrega ao cliente.
Daí vêm duas conclusões práticas. A primeira: a velocidade que o cliente sente depende quase toda do recursivo, da distância até ele e da taxa de acerto do cache. A segunda: um erro no autoritativo afeta todo mundo que tenta acessar o seu domínio, de qualquer provedor do mundo.
DNS recursivo
O recursivo (ou resolvedor) é o servidor que os clientes usam para navegar. Em um provedor, é um dos serviços mais críticos da rede: se ele parar, para tudo, mesmo com o link funcionando.
O que importa nele:
- Responder só aos seus clientes. Um recursivo aberto para a internet (open resolver) é usado em ataques de amplificação: o atacante falsifica o IP da vítima, faz consultas pequenas e o seu servidor dispara respostas grandes contra ela. Além de participar do ataque, você consome o próprio link.
- Proximidade e redundância. Pelo menos dois servidores, de preferência em locais diferentes. Em redes maiores, recursivos em anycast, com o mesmo IP anunciado em vários POPs.
- Validação DNSSEC, para descartar respostas falsificadas de domínios assinados.
- Cache bem dimensionado. Memória suficiente faz a maior parte das respostas sair do cache, em menos de 1 ms.
A restrição de acesso é feita por ACL no próprio software. No Unbound, por exemplo, a lógica é negar tudo e liberar as faixas dos clientes:
# unbound.conf (trecho)
server:
access-control: 0.0.0.0/0 refuse
access-control: ::/0 refuse
access-control: 100.64.0.0/10 allow # CGNAT dos clientes
access-control: 203.0.113.0/24 allow # bloco público
access-control: 2001:db8::/32 allow
Esse trecho é só a ACL. Um recursivo de provedor em produção também precisa de ajuste de threads e cache para o volume de consultas, proteção contra abuso, monitoramento de latência e taxa de erro e, no Brasil, de uma forma de aplicar bloqueios determinados por ofício judicial.
DNS autoritativo
O autoritativo guarda as zonas: o arquivo (ou banco de dados) com os registros de um domínio. Ele não faz cache e não resolve nomes de terceiros. Só responde, com autoridade, pelo que é dele.
Os registros que toda zona tem:
- SOA: dados da zona, como o servidor primário, o número de série e os tempos de atualização e de cache negativo.
- NS: os servidores autoritativos da zona. Precisam ser os mesmos cadastrados no registro do domínio (no Registro.br, para
.br). - A, AAAA, CNAME, MX, TXT e os demais: o conteúdo em si.
A redundância é feita com servidores primário e secundários. As alterações são feitas no primário e os secundários copiam a zona por transferência (AXFR ou IXFR), avisados por NOTIFY. Em provedores é comum usar um primário oculto: o servidor onde as zonas são editadas não aparece nos registros NS e não recebe consultas da internet, só os secundários.
Um exemplo mínimo de zona, para visualizar a estrutura:
$TTL 3600
@ IN SOA ns1.exemplo.net.br. hostmaster.exemplo.net.br. (
2026101701 ; serial
7200 ; refresh
900 ; retry
1209600 ; expire
300 ) ; cache negativo
IN NS ns1.exemplo.net.br.
IN NS ns2.exemplo.net.br.
IN MX 10 mail.exemplo.net.br.
www IN A 203.0.113.10
www IN AAAA 2001:db8:10::10
O número de série precisa aumentar a cada alteração. Esquecer disso é um dos erros mais comuns: o primário tem a zona nova, mas os secundários continuam servindo a antiga.
DNS reverso
O reverso faz o caminho contrário: recebe um IP e devolve um nome, por meio de registros PTR. Ele é usado por servidores de e-mail (que rejeitam IPs sem reverso ou com reverso genérico), por traceroute, por logs e por sistemas que identificam a origem de conexões.
Os IPs viram nomes em zonas especiais, com a ordem invertida:
| Bloco | Zona reversa |
|---|---|
203.0.113.0/24 | 113.0.203.in-addr.arpa |
198.51.100.0/22 | Quatro zonas /24: 100 a 103.51.198.in-addr.arpa |
2001:db8::/32 | 8.b.d.0.1.0.0.2.ip6.arpa |
Dentro da zona, cada registro aponta a última parte do IP para um nome:
; zona 113.0.203.in-addr.arpa
10 IN PTR www.exemplo.net.br.
25 IN PTR mail.exemplo.net.br.
Delegação: quem responde pelo seu bloco
A zona reversa só funciona se quem alocou o bloco delegar a zona para os seus servidores autoritativos. Para blocos recebidos do NIC.br, isso é feito no painel do Registro.br, na área do bloco IP, informando os servidores DNS. Para blocos cedidos por um upstream, é ele quem precisa delegar.
Dois casos que complicam:
- Blocos menores que /24 cedidos a clientes. A zona reversa é por /24, então para delegar um /29 ao cliente é preciso usar a técnica do RFC 2317 (classless delegation), com CNAMEs apontando para uma zona do cliente.
- IPv6. Um /48 de cliente tem mais endereços que é possível cadastrar. O reverso IPv6 é feito por delegação de zonas aos clientes ou por geração dinâmica dos registros, nunca à mão.
Para servidores de e-mail, o reverso precisa bater com o direto: o PTR de 203.0.113.25 aponta para mail.exemplo.net.br, e mail.exemplo.net.br resolve de volta para 203.0.113.25. Isso se chama FCrDNS, e sem ele muitos provedores de e-mail recusam a mensagem.
Por que separar recursivo e autoritativo
Muitos provedores começam com um único BIND fazendo tudo: recursivo para os clientes, autoritativo para o domínio da empresa e reverso dos blocos. Funciona, mas cria problemas:
- Exposição. O autoritativo precisa responder à internet inteira. Se o mesmo processo faz recursão, qualquer falha de ACL transforma o servidor em open resolver.
- Envenenamento de cache. Um servidor que mistura cache e autoridade é um alvo mais interessante e mais difícil de proteger.
- Desempenho e falhas acopladas. Um ataque contra o seu domínio derruba a navegação dos seus clientes, e vice-versa.
- Manutenção. Atualizar ou reiniciar o servidor para mexer em uma zona interrompe a navegação de todos.
O desenho recomendado é ter recursivos dedicados (acessíveis só aos clientes) e autoritativos dedicados (acessíveis a todos, sem recursão), mesmo que rodem em máquinas virtuais pequenas.
Diagnóstico com dig
O dig mostra, em cada resposta, quem respondeu e com que autoridade. Nas flags do cabeçalho, aa indica resposta autoritativa e ra indica que o servidor oferece recursão.
# Resolução pelo recursivo configurado na máquina
dig www.exemplo.com.br
# O caminho completo, da raiz até o autoritativo
dig +trace www.exemplo.com.br
# Pergunta direto ao autoritativo, sem recursão: deve ter a flag aa
dig @ns1.exemplo.com.br www.exemplo.com.br +norecurse
# Confere se todos os autoritativos têm o mesmo serial
dig exemplo.com.br NS +short
dig @ns1.exemplo.com.br exemplo.com.br SOA +short
dig @ns2.exemplo.com.br exemplo.com.br SOA +short
# Reverso de um IP
dig -x 203.0.113.25 +short
# Quem responde pela zona reversa do bloco
dig 113.0.203.in-addr.arpa NS +short
E o teste que todo provedor deveria fazer de fora da própria rede, por exemplo de um servidor em outra operadora:
# Consulta ao seu recursivo a partir de um IP que não é cliente
dig @203.0.113.53 google.com
# Esperado: status REFUSED, ou nenhuma resposta
# Se vier a resposta com o IP, o seu recursivo está aberto para a internet
| Sintoma | Causa provável |
|---|---|
| Domínio funciona em alguns provedores e em outros não | Autoritativos com zonas diferentes (serial não atualizado) ou um dos NS fora do ar. |
SERVFAIL em um domínio específico | Erro de DNSSEC no domínio, ou autoritativos inacessíveis. O +trace mostra em que etapa falha. |
dig -x sem resposta | Zona reversa não delegada no Registro.br ou no upstream, ou o servidor delegado não tem a zona. |
| Alteração no DNS "não pegou" | Cache do recursivo até o fim do TTL antigo, ou serial da zona não incrementado. |
| Navegação lenta com o link livre | Recursivo sobrecarregado, distante ou com pouca memória de cache. |
Do tutorial à produção
Entender as três funções e saber diagnosticar resolve a maioria das dúvidas. Operar o DNS de um provedor com milhares de clientes é outra escala, e é aí que estão os problemas que este tutorial não cobre:
- Reverso de milhares de IPs. Blocos inteiros, CGNAT e IPv6 exigem PTRs gerados automaticamente a partir do cadastro de clientes ou do IPAM, e não editados à mão em arquivos de zona.
- Bloqueios por ofício judicial. Provedores precisam aplicar bloqueios de domínios determinados pela Justiça e pela Anatel, com registro e prazo, normalmente via RPZ nos recursivos.
- Recursivos em anycast. Mesmo IP em vários POPs, com retirada automática do anúncio BGP quando um servidor falha.
- DNSSEC nos domínios e no reverso. Assinatura, rotação de chaves e publicação do DS sem derrubar o domínio.
- Monitoramento. Latência, taxa de SERVFAIL, volume de consultas e alertas antes de o cliente perceber.
Perguntas frequentes
O DNS reverso é obrigatório?
Não para navegar, mas na prática sim para quem opera rede. Servidores de e-mail rejeitam ou marcam como spam mensagens de IPs sem PTR, ferramentas como traceroute ficam ilegíveis e muitos serviços usam o reverso para identificar a origem de conexões.
Posso usar o mesmo servidor como recursivo e autoritativo?
Funciona, mas não é recomendado. As funções têm requisitos opostos: o recursivo deve responder só aos seus clientes e o autoritativo deve responder a toda a internet. Misturar as duas aumenta o risco de envenenamento de cache e de uso do servidor em ataques de amplificação.
Qual a diferença entre DNS reverso IPv4 e IPv6?
O conceito é o mesmo, registros PTR em uma zona especial. No IPv4 a zona fica em in-addr.arpa, com os octetos invertidos. No IPv6 fica em ip6.arpa, com cada dígito hexadecimal (nibble) invertido e separado por ponto, o que torna inviável manter os registros à mão.
Quem delega o DNS reverso do meu bloco IP?
Quem alocou o bloco. Para blocos recebidos do NIC.br, a delegação é feita no painel do Registro.br, informando os servidores DNS autoritativos que vão responder pela zona reversa. Para blocos de um provedor upstream, é ele quem precisa delegar ou cadastrar os PTRs.
CONSULTORIA BTECH
Prefere que alguém faça isso por você?
A BTECH Automations é uma consultoria em automação, redes e cloud para provedores, operadoras e empresas de hospedagem. Implementamos DNS recursivo, autoritativo e reverso para provedores de ponta a ponta, documentamos e mantemos funcionando, com um pacote mensal de horas e relatório de cada atividade.
- ✓ Filtros BGP, IRR, RPKI e DNS automatizados
- ✓ Zabbix, Grafana, logs e alertas sob medida
- ✓ Cloud, virtualização, backups e portais do cliente