O Que É o Encaminhamento de DNS? Como Funciona e Por Que É Importante
O que é o encaminhamento de DNS? Saiba como os reencaminhadores se diferenciam dos resolvedores recursivos, como funcionam o caching e a tolerância a falhas, e onde o encaminhamento se enquadra nas redes modernas.
Published 23 de outubro de 2026
O reencaminhamento de DNS é o processo no qual um resolver de DNS envia a consulta de um cliente para outro servidor DNS, o reencaminhador, em vez de resolver o nome diretamente através da hierarquia de DNS. O resolver local ainda pode responder a partir da sua cache e aplicar políticas locais, enquanto o resolver de upstream realiza a pesquisa completa quando necessário. Mas se esse servidor de upstream falhar, qual parte do DNS está inoperacional?
Essa distinção é importante ao configurar uma rede ou ao tentar explicar por que um website não carrega. Um resolver de reencaminhamento não se limita a passar pacotes: pode responder localmente a pedidos conhecidos, direcionar consultas selecionadas para diferentes servidores e moldar qual resolver vê o tráfego DNS do utilizador.
Índice
- O Que Significa Realmente o Encaminhamento de DNS
- Acompanhar uma Consulta do Cliente até à Resposta
- Como o Encaminhamento Difere da Recursão e do Serviço Autoritativo
- Encaminhamento Condicional, Split-Horizon e Prevenção de Loops
- Como o Caching e o TTL Moldam o Desempenho do Encaminhamento
- Escolher entre Encaminhamento, Recursão Root-Hints e DNS Encriptado
- Colocar o Encaminhamento a Funcionar na Sua Rede
O que Significa Efetivamente o Reencaminhamento de DNS
Pense no resolver local como a receção de uma secção de correio. Um cliente pede um site pelo nome e o resolver verifica se já sabe a resposta. Se tiver uma resposta válida na sua cache, devolve-a. Se não tiver, envia a consulta para um servidor DNS a montante, o forwarder, que trata da pesquisa e devolve uma resposta.
Essa disposição separa duas tarefas. O resolver local lida com os clientes da rede e pode aplicar regras locais. O resolver a montante assume o trabalho de resolver nomes a que o servidor local não consegue responder a partir da sua cache ou dados locais. O reencaminhamento é, portanto, uma função arquitetural, e não automaticamente um produto de segurança.
O DNS surgiu em novembro de 1983, quando as RFC 882 e RFC 883 introduziram um sistema de nomes hierárquico para substituir o modelo HOSTS.TXT, cada vez mais ingovernável. Antes do DNS, os administradores dependiam de mapeamentos de nome para endereço mantidos manualmente. Em novembro de 1987, as RFC 1034 e RFC 1035 substituíram as especificações originais e tornaram-se os padrões fundamentais para a arquitetura moderna do DNS, tal como regista a cronologia histórica do DNS.
Onde vai encontrar o reencaminhamento
Routers domésticos, redes empresariais, WiFi público, escolas e ambientes de nuvem podem utilizar o reencaminhamento. Uma organização pode usá-lo para enviar pesquisas gerais da internet para um serviço recursivo gerido, mantendo o controlo local sobre a cache, registos, nomes internos ou regras de bloqueio.
O modelo mental útil é simples: o resolver local é a receção controlada; o resolver a montante é o especialista que faz a pesquisa completa. Esse modelo também facilita a localização de um problema. Um cliente pode chegar à receção com sucesso mesmo que o resolver a montante esteja indisponível ou a devolver um erro.
Acompanhar uma Consulta do Cliente à Resposta
Uma pesquisa típica começa quando um dispositivo pede um nome ao seu resolver local. O resolver verifica primeiro a sua cache. Se a resposta armazenada ainda for válida, pode devolvê-la sem contactar um servidor a montante. Se não houver uma resposta útil em cache, o resolver reencaminha a consulta para um resolver recursivo a montante.
Na terminologia do DNS, o reencaminhamento envolve o envio de uma consulta por um resolvedor com o bit de recursão desejada (RD) ativado. Esse bit sinaliza que está a ser pedido ao resolvedor recetor que resolva a consulta, em vez de simplesmente retransmitir um pacote sem esse pedido. A definição do glossário da RFC 7719 distingue o reencaminhamento da simples retransmissão cega de pacotes.
Em caso de falha na cache (cache miss), o resolutor recursivo a montante realiza o trabalho de pesquisa. Pode utilizar a sua própria cache ou consultar a hierarquia de DNS para obter a resposta. A resposta regressa depois através do resolutor de reencaminhamento para o cliente.
Os dois caminhos possíveis
- Acerto de cache (Cache hit): O resolver local devolve uma resposta válida em cache. O servidor a montante não é envolvido nessa pesquisa.
- Falha de cache (Cache miss): O resolver local envia a consulta a montante, recebe a resposta e devolve-a ao cliente.
A transição também define uma divisão útil de responsabilidades. O resolver local pode aplicar controlos específicos da rede, manter registos, utilizar regras de split-DNS ou aplicar uma política de validação DNSSEC. O resolver a montante realiza a pesquisa recursiva quando o resolver local não consegue responder a partir da sua cache ou dados locais.
Pista para resolução de problemas: Se o resolver local responder aos clientes, mas as pesquisas falharem quando a sua cache não contiver a resposta, verifique o caminho de reencaminhamento e a resposta a montante antes de assumir que a falha é do serviço DNS autoritativo.
Como o Reencaminhamento Difere da Recursão e do Serviço Autoritativo
Reencaminhamento de DNS, recursão, proxy e serviço autoritativo descrevem funções diferentes. Um único sistema pode assumir mais do que uma função, mas os termos não são intermutáveis. Numa configuração típica de reencaminhamento, o servidor local atende os clientes e mantém uma cache ou políticas; um resolver recursivo a montante realiza a resolução para falhas na cache (cache misses).
| Função | Quem inicia | Realiza pesquisa completa | Detém dados autoritativos | Sintoma típico de falha |
|---|---|---|---|---|
| Forwarder (Encaminhador) | Um resolutor local envia-lhe uma consulta | Geralmente, quando atua como um resolutor recursivo a montante | Não necessariamente | Timeout ou erro do serviço a montante |
| Resolutor recursivo | Um cliente ou outro resolutor solicita a resolução | Sim, utilizando a cache ou consultando a hierarquia de DNS | Não necessariamente | Erros de resolução, timeouts ou falhas nas pesquisas |
| Proxy | Um cliente ou serviço envia-lhe tráfego | Inerentemente não; o proxy retransmite pedidos de acordo com a sua conceção | Não | O pedido de proxy falha ou não consegue alcançar o seu destino |
| Servidor autoritativo | Um resolutor consulta-o sobre um domínio que ele serve | Não, fornece dados para a sua zona | Sim, para as zonas que serve | Registos em falta, incorretos ou indisponíveis para essas zonas |
A principal distinção da tabela é quem realiza a pesquisa completa. Um resolver de reencaminhamento envia uma consulta não respondida para a frente; um resolver recursivo trata da resolução, potencialmente consultando servidores autoritativos. Um servidor autoritativo fornece registos para o domínio que gere, em vez de pesquisar na hierarquia em nome de um cliente.
Por que razão a distinção altera a resolução de problemas
Um resolver de reencaminhamento pode retornar um tempo limite de upstream, SERVFAIL, ou uma resposta em cache que já não é adequada, mesmo quando a infraestrutura de DNS autoritativo está a funcionar normalmente. Resolver problemas apenas no servidor autoritativo nessa situação pode levá-lo pelo caminho errado. Verifique qual o resolver que recebeu o pedido, se tinha uma resposta em cache e o que aconteceu no salto seguinte.
Existe também uma dependência de confiança. A RFC 7719 aborda a terminologia dos resolutores, incluindo a distinção entre reencaminhadores e resolutores recursivos. A investigação sobre ataques de envenenamento de cache distingue estas funções porque um reencaminhador depende da integridade do resolutor a montante que utiliza. Se os controlos de conteúdo fizerem parte do projeto, uma rede também pode utilizar filtragem de DNS para aplicar políticas às consultas antes de os dispositivos se ligarem aos destinos.
Reencaminhamento Condicional, Split Horizon e Prevenção de Loops
O reencaminhamento não precisa de enviar todas as consultas não respondidas para o mesmo servidor a montante. Com o reencaminhamento condicional, um resolver envia consultas de domínios selecionados para um servidor designado. Por exemplo, uma rede pode direcionar pedidos de nomes internos para um serviço DNS interno e enviar outros pedidos para um resolver recursivo gerido.
Uma ideia relacionada é o DNS split-horizon. Permite que uma rede retorne respostas diferentes para o mesmo nome, dependendo de onde vem o pedido. Alguém dentro de uma organização pode receber uma resposta interna, enquanto um requerente externo recebe uma resposta diferente. O resolver local torna-se um ponto de decisão para manter os nomes internos no caminho adequado.
A configuração tem de deixar claro qual resolver é proprietário de cada caminho de consulta. Uma regra que envie um nome interno para o servidor a montante incorreto pode produzir uma resposta externa, uma falha na resolução ou um resultado que difere entre partes da rede.
Prevenir loops de resolver
Um loop de reencaminhamento ocorre quando um resolver envia uma consulta para um segundo resolver que, eventualmente, a envia de volta. A consulta pode circular entre servidores, causando pedidos repetidos, tempos limite excedidos e exaustão de recursos. A solução consiste em mapear os caminhos de reencaminhamento e garantir que nenhuma cadeia de resolvers aponte de volta para um servidor anterior.
Alguns nomes também precisam de um limite explícito. A RFC 9539 aponta para namespaces como home.arpa que não devem ser reencaminhados além do seu âmbito local pretendido. Um resolvedor que funciona até ser adicionado um segundo reencaminhador pode ter ganho um loop; um nome local que comece a ser resolvido publicamente pode precisar de uma regra de zona local ou de reencaminhamento mais específica.
O vídeo abaixo fornece outra introdução visual aos conceitos de reencaminhamento de DNS.
Como a Caching e o TTL Moldam o Desempenho do Reencaminhamento
A cache de um reencaminhador funciona como a memória de um intermediário prestativo: assim que obtém uma resposta do upstream, pode responder à pergunta idêntica seguinte por si próprio. Esse único comportamento explica a maior parte do impacto do reencaminhamento no desempenho. Cada acesso com sucesso à cache elimina uma viagem de ida e volta ao resolver de upstream. Cada falha adiciona uma viagem antes de a pesquisa real começar.
O time to live (TTL) de cada registo define o limite dessa memória. O servidor autoritativo publica o TTL, e qualquer resolver ao longo do caminho pode reutilizar a resposta em cache apenas enquanto esta permanecer válida. TTLs curtos mantêm as respostas atualizadas, mas enviam mais consultas para o upstream. TTLs longos reduzem o tráfego de upstream, mas podem deixar os clientes com endereços desatualizados após uma alteração de infraestrutura.
A colocação em cache também se acumula ao longo do caminho. Uma consulta pode ser servida pela cache do cliente, pela cache do reencaminhador ou pela cache do resolver de upstream, e cada camada executa a sua própria contagem decrescente de TTL. Quando um utilizador reporta uma resposta desatualizada, a resolução depende de qual camada a está a reter, pelo que deve tratar cada cache como um suspeito separado durante a resolução de problemas, em vez de limpar o que estiver mais próximo.
Meça mais do que a latência média
O tempo médio de pesquisa pode ocultar problemas que afetam mais alguns utilizadores ou algumas consultas do que outros. Acompanhe a taxa de cache-hits, a latência mediana e de cauda (tail), a taxa de timeout a montante e o comportamento de cache negativa. Essas métricas ajudam a distinguir um serviço a montante lento de um encaminhador que continua a perder oportunidades de cache ou que gere mal as pesquisas com falhas.
O DNSSEC adiciona outra complexidade. Um resolver de validação obtém assinaturas e chaves além da própria resposta, pelo que falhas de cache em nomes assinados custam mais do que falhas em nomes não assinados. Respostas validadas em cache evitam esse trabalho repetido, o que torna a taxa de acerto ainda mais importante em caminhos de validação.
Nenhum valor único prevê o tempo de pesquisa numa determinada rede. O resultado depende do estado da cache em cada camada, da capacidade de resposta do upstream, do trabalho de validação, da configuração de transporte e das tentativas de repetição após um reencaminhador não responder. Um reencaminhador com bom comportamento também passa códigos de resposta, comportamento de truncamento, registos DNSSEC e sinalizadores sem alterações, para que os clientes vejam a resposta que o lado autoritativo enviou.
Escolher entre Reencaminhamento, Recursão Root-Hints e DNS Encriptado
O reencaminhamento e a recursão baseada em root-hints envolvem compromissos diferentes. Com o reencaminhamento, uma organização seleciona resolvedores upstream para tratar consultas não respondidas. Isso pode simplificar as operações locais e centralizar as políticas, mas torna a rede dependente dos serviços upstream escolhidos. Com a recursão por root-hints, o próprio resolvedor realiza a pesquisa iterativa, o que reduz a dependência de um único serviço recursivo upstream, mas coloca uma maior responsabilidade de resolução nesse resolvedor.
| Opção de conceção | Onde ocorre a resolução | Principal compromisso operacional |
|---|---|---|
| Reencaminhamento | No resolutor recursivo a montante selecionado | Administração centralizada, com uma dependência a montante |
| Recursão por root-hints | No resolutor recursivo local, que consulta através da hierarquia | Maior controlo local, com maior responsabilidade pela resolução direta |
| DNS encriptado direcionado pelo cliente | No resolutor que o cliente contacta através de uma ligação encriptada | A rede local pode não ver ou controlar a consulta do domínio |
O DNS encriptado torna a escolha menos direta. O DNS over TLS e o DNS over QUIC podem proteger o tráfego DNS em trânsito, mas a questão importante é onde a encriptação termina. Se um cliente encripta consultas diretamente para um resolvedor externo, um reencaminhador local pode não ver uma consulta de domínio utilizável. Se a encriptação terminar num resolvedor empresarial aprovado, esse resolvedor ainda pode aplicar políticas de rede e reencaminhar consultas para o upstream.
O WiFi público necessita de uma política deliberada
Os operadores de WiFi público também têm de ter em conta os Captive Portals. Os dispositivos podem precisar de resolução de nomes pré-autenticação e de verificações de conectividade antes de os utilizadores poderem iniciar sessão. O DNS encriptado pode complicar a deteção do portal ou atrasá-la, pelo que os operadores precisam de decidir quais os resolvers aprovados, como deve funcionar o fallback e se são necessárias exceções.
Um serviço de DNS de proteção pode situar-se no caminho de resolução selecionado e avaliar as pesquisas antes do início das ligações. O Purple Shield foi concebido para redes de WiFi de clientes e espaços físicos, com filtragem de conteúdos baseada em categorias, bloqueio de ameaças na camada de DNS e políticas que podem ser geridas por rede. Pode ser implementado como um serviço autónomo ou integrado com redes Purple Access. Para as equipas que estão a avaliar controlos de DNS em comparação com controlos mais amplos de tráfego web, uma visão geral sobre secure web gateway descreve uma camada diferente de aplicação de regras.
Colocar o Reencaminhamento a Funcionar na Sua Rede
O reencaminhamento concentra alguma da carga de trabalho do DNS nos serviços a montante selecionados por uma organização. As medições efetuadas utilizando os conjuntos de dados Day in the Life do DNS-OARC revelaram que aproximadamente 99% dos resolutores recursivos geraram volumes de consulta moderados, enquanto cerca de 1% teve um comportamento agressivo. Esse grupo menor foi responsável por cerca de 98% do tráfego DNS observado em 2018 e 93% em 2019; os investigadores estimaram que incluiu aproximadamente 8 300 resolutores em 2018 e mais de 14 000 em 2019 (estudo sobre o comportamento agressivo de resolutores). Um resolutor local pode enviar pedidos para serviços recursivos a montante que armazenam em cache e reutilizam respostas, mas isso concentra a dependência na sua disponibilidade e comportamento.
Antes de implementar ou alterar o reencaminhamento, confirme que:
- Os upstreams são independentes: Configure pelo menos dois reencaminhadores onde a arquitetura o permitir.
- As falhas têm uma resposta definida: Defina o comportamento de tempo limite e de nova tentativa, e saiba o que os clientes recebem se um upstream não responder.
- A monitorização cobre os sintomas: Acompanhe as respostas SERVFAIL, os tempos limite e a latência de resposta.
- As expectativas de privacidade são claras: Decida qual o resolvedor upstream que pode ver as consultas reencaminhadas.
Se a filtragem de DNS faz parte da política da sua rede de convidados, compare-a com a sua abordagem mais ampla de filtragem de conteúdos WiFi. Depois, audite para que resolver a sua rede faz o reencaminhamento e confirme se a sua política, disponibilidade e postura de privacidade correspondem ao pretendido.
O Purple Shield verifica as pesquisas de DNS antes de os dispositivos se ligarem e oferece filtragem de conteúdos e bloqueio de ameaças para redes WiFi de locais e visitantes. Se está a analisar como o reencaminhamento pode apoiar esses controlos, visite o Purple Shield para explorar as suas opções de implementação.