BTECH Automations

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çãoPergunta que respondeQuem 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:

  1. O recursivo procura a resposta no cache. Se alguém já perguntou e o TTL não expirou, responde na hora.
  2. Sem cache, pergunta a um servidor raiz, que não sabe o IP, mas indica quem responde por .br.
  3. Pergunta aos servidores do .br, que indicam quem responde por exemplo.com.br (os servidores NS cadastrados no Registro.br).
  4. Pergunta ao autoritativo de exemplo.com.br, que finalmente devolve o IP de www.
  5. 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
# 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:

exemplo.net.br.zone
$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:

BlocoZona reversa
203.0.113.0/24113.0.203.in-addr.arpa
198.51.100.0/22Quatro zonas /24: 100 a 103.51.198.in-addr.arpa
2001:db8::/328.b.d.0.1.0.0.2.ip6.arpa

Dentro da zona, cada registro aponta a última parte do IP para um nome:

113.0.203.in-addr.arpa.zone
; 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.

bash
# 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:

bash
# 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
SintomaCausa provável
Domínio funciona em alguns provedores e em outros nãoAutoritativos com zonas diferentes (serial não atualizado) ou um dos NS fora do ar.
SERVFAIL em um domínio específicoErro de DNSSEC no domínio, ou autoritativos inacessíveis. O +trace mostra em que etapa falha.
dig -x sem respostaZona 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 livreRecursivo 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

Outros tutoriais