O que é encaminhamento de DNS? Como funciona e por que é importante
O que é encaminhamento de DNS? Saiba como os encaminhadores se diferenciam dos resolutores recursivos, como funcionam o caching e o failover e onde o encaminhamento se encaixa nas redes modernas.
Published 23 de outubro de 2026
O encaminhamento de DNS é o processo no qual um resolvedor de DNS envia a consulta de um cliente para outro servidor DNS, o encaminhador, em vez de resolver o nome diretamente por meio da hierarquia de DNS. O resolvedor local ainda pode responder a partir do seu cache e aplicar políticas locais, enquanto o resolvedor upstream realiza a busca completa quando necessário. Mas, se esse servidor upstream falhar, qual parte do DNS está com defeito?
Essa diferença é importante ao configurar uma rede ou tentar explicar por que um site não carrega. Um resolvedor de encaminhamento não apenas repassa pacotes: ele pode responder a solicitações conhecidas localmente, direcionar consultas selecionadas para diferentes servidores e definir qual resolvedor visualiza o tráfego de DNS do usuário.
Sumário
- O que o encaminhamento de DNS realmente significa
- Acompanhando uma consulta do cliente à resposta
- Como o encaminhamento difere da recursão e do serviço autoritativo
- Encaminhamento condicional, Split-Horizon e prevenção de loops
- Como o armazenamento em cache e o TTL moldam o desempenho do encaminhamento
- Escolhendo entre encaminhamento, recursão por Root-Hints e DNS criptografado
- Colocando o encaminhamento para funcionar em sua rede
O Que Realmente Significa o Encaminhamento de DNS
Pense no resolvedor local como a recepção de uma sala de correspondência. Um cliente solicita um site pelo nome, e o resolvedor verifica se já sabe a resposta. Se tiver uma resposta válida em seu cache, ele a retorna. Se não tiver, envia a consulta para um servidor DNS upstream, o encaminhador, que lida com a busca e retorna uma resposta.
Esse arranjo separa duas funções. O resolvedor local atende aos clientes da rede e pode aplicar regras locais. O resolvedor upstream assume o trabalho de resolver nomes que o servidor local não consegue responder a partir do seu cache ou dados locais. O encaminhamento é, portanto, uma função arquitetônica, e não automaticamente um produto de segurança.
O DNS surgiu em novembro de 1983, quando as especificações RFC 882 e RFC 883 introduziram um sistema de nomes hierárquico para substituir o modelo HOSTS.TXT, que se tornava 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 especificações RFC 1034 e RFC 1035 substituíram as originais e se tornaram os padrões fundamentais para a arquitetura moderna do DNS, conforme registra a cronologia da história do DNS.
Onde você encontrará o encaminhamento
Roteadores domésticos, redes corporativas, WiFi público, escolas e ambientes em nuvem podem usar o encaminhamento. Uma organização pode usá-lo para enviar buscas gerais de internet para um serviço recursivo gerenciado, mantendo o controle local sobre cache, logs, nomes internos ou regras de bloqueio.
O modelo mental útil é simples: o resolvedor local é a recepção controlada; o resolvedor upstream é o especialista que faz a busca completa. Esse modelo também facilita a localização de um problema. Um cliente pode alcançar a recepção com sucesso, mesmo se o resolvedor upstream estiver indisponível ou retornando um erro.
Acompanhando uma Consulta do Cliente até a Resposta
Uma busca típica começa quando um dispositivo solicita um nome ao seu resolvedor local. O resolvedor verifica seu cache primeiro. Se a resposta armazenada ainda for válida, ele poderá retorná-la sem contatar um servidor upstream. Se não houver uma resposta em cache utilizável, o resolvedor encaminha a consulta para um resolvedor recursivo upstream.
Na terminologia do DNS, o encaminhamento envolve um resolvedor enviando uma consulta com o bit recursion-desired (RD) ativado. Esse bit sinaliza que o resolvedor de destino está sendo solicitado a resolver a consulta, em vez de apenas retransmitir um pacote sem essa solicitação. A definição do glossário da RFC 7719 distingue o encaminhamento da simples retransmissão cega de pacotes.
Em caso de falha no cache (cache miss), o resolutor recursivo upstream realiza o trabalho de busca. Ele pode usar seu próprio cache ou consultar a hierarquia do DNS para obter a resposta. A resposta então retorna pelo resolutor de encaminhamento até o cliente.
Os dois caminhos possíveis
- Acerto no cache (Cache hit): O resolvedor local retorna uma resposta válida em cache. O servidor upstream não é envolvido nessa busca.
- Ausência no cache (Cache miss): O resolvedor local envia a consulta para o upstream, recebe a resposta e a retorna ao cliente.
A transferência também define uma divisão útil de responsabilidades. O resolvedor local pode aplicar controles específicos da rede, manter logs, usar regras de DNS dividido ou aplicar uma política de validação DNSSEC. O resolvedor upstream realiza a busca recursiva quando o resolvedor local não consegue responder a partir de seu cache ou dados locais.
Pista para solução de problemas: Se o resolvedor local responde aos clientes, mas as consultas falham quando o cache dele não contém a resposta, verifique o caminho de encaminhamento e a resposta upstream antes de supor que o serviço de DNS autoritativo está com defeito.
Como o Encaminhamento Difere da Recursão e do Serviço Autoritativo
Encaminhamento de DNS, recursão, proxy e serviço autoritativo descrevem papéis diferentes. Um único sistema pode assumir mais de uma função, mas os termos não são intercambiáveis. Em uma configuração típica de encaminhamento, o servidor local atende aos clientes e mantém um cache ou políticas; um resolvedor recursivo upstream realiza a resolução para falhas no cache.
| Função | Quem inicia | Realiza a busca completa | Possui dados autoritativos | Sintoma típico de falha |
|---|---|---|---|---|
| Encaminhador (Forwarder) | Um resolvedor local envia uma consulta para ele | Geralmente, quando atua como um resolvedor recursivo upstream | Não necessariamente | Tempo limite esgotado (timeout) ou erro do serviço upstream |
| Resolvedor recursivo | Um cliente ou outro resolvedor solicita a resolução | Sim, usando cache ou consultando por meio da hierarquia de DNS | Não necessariamente | Erros de resolução, tempos limites esgotados ou buscas com falha |
| Proxy | Um cliente ou serviço envia tráfego para ele | Não inerentemente; o proxy retransmite solicitações de acordo com seu projeto | Não | A solicitação via proxy falha ou não consegue atingir o destino |
| Servidor autoritativo | Um resolvedor o consulta sobre um domínio que ele atende | Não, ele fornece dados para sua zona | Sim, para as zonas que ele atende | Registros ausentes, incorretos ou indisponíveis para essas zonas |
A principal distinção da tabela é quem faz a busca completa. Um resolvedor de encaminhamento envia uma consulta não respondida adiante; um resolvedor recursivo lida com a resolução, potencialmente consultando servidores autoritativos. Um servidor autoritativo fornece registros para o domínio que gerencia, em vez de pesquisar a hierarquia em nome de um cliente.
Por que a distinção altera a solução de problemas
Um resolvedor de encaminhamento pode retornar um tempo limite do servidor upstream, SERVFAIL ou uma resposta em cache que não é mais apropriada, mesmo quando a infraestrutura de DNS autoritativa está funcionando normalmente. Fazer a solução de problemas apenas no servidor autoritativo nessa situação pode levá-lo pelo caminho errado. Verifique qual resolvedor recebeu a solicitação, se ele tinha uma resposta em cache e o que aconteceu no próximo salto (next hop).
Também existe uma dependência de confiança. A RFC 7719 discute a terminologia de resolutores, incluindo a distinção entre forwarders e resolutores recursivos. Pesquisas sobre ataques de envenenamento de cache (cache poisoning) distinguem essas funções porque um encaminhador depende da integridade do resolutor upstream que utiliza. Se os controles de conteúdo fizerem parte do projeto, uma rede também poderá usar a filtragem de DNS para aplicar políticas às consultas antes que os dispositivos se conectem aos destinos.
Encaminhamento Condicional, Split Horizon e Prevenção de Loops
O encaminhamento não precisa enviar todas as consultas não respondidas para o mesmo servidor upstream. Com o encaminhamento condicional, um resolvedor envia consultas para domínios selecionados a um servidor designado. Por exemplo, uma rede pode direcionar solicitações de nomes internos para um serviço DNS interno e enviar outras solicitações para um resolvedor recursivo gerenciado.
Um conceito relacionado é o DNS split-horizon. Ele permite que uma rede retorne respostas diferentes para o mesmo nome, dependendo de onde vem a solicitação. Alguém dentro de uma organização pode receber uma resposta interna, enquanto um solicitante externo recebe uma resposta diferente. O resolvedor local torna-se um ponto de decisão para manter os nomes internos no caminho adequado.
A configuração precisa deixar claro qual resolvedor é proprietário de cada caminho de consulta. Uma regra que envia um nome interno para o servidor upstream incorreto pode produzir uma resposta externa, uma falha na resolução ou um resultado diferente entre partes da rede.
Prevenindo loops de resolvedor
Um loop de encaminhamento ocorre quando um resolvedor envia uma consulta para um segundo resolvedor que, eventualmente, a envia de volta. A consulta pode circular entre os servidores, causando solicitações repetidas, tempos de limite esgotados (timeouts) e exaustão de recursos. A solução é mapear os caminhos de encaminhamento e garantir que nenhuma cadeia de resolvedores 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 encaminhados além de seu escopo local pretendido. Um resolvedor que funciona até a adição de um segundo retransmissor pode ter entrado em loop; um nome local que começa a ser resolvido publicamente pode precisar de uma regra de encaminhamento ou de zona local mais específica.
O vídeo abaixo oferece outra introdução visual aos conceitos de encaminhamento de DNS.
Como o Caching e o TTL Moldam o Desempenho do Encaminhamento
O cache de um encaminhador funciona como a memória de um intermediário prestativo: depois de buscar uma resposta no servidor upstream, ele pode responder sozinho à próxima pergunta idêntica. Esse único comportamento explica a maior parte do impacto do encaminhamento no desempenho. Cada resposta encontrada no cache (cache hit) elimina uma viagem de ida e volta (round trip) ao resolvedor upstream. Cada falha (cache miss) adiciona uma etapa antes mesmo de a busca real começar.
O time to live (TTL) de cada registro define o limite dessa memória. O servidor autoritativo publica o TTL, e qualquer resolvedor ao longo do caminho pode reutilizar a resposta em cache apenas enquanto ela permanecer válida. TTLs curtos mantêm as respostas atualizadas, mas enviam mais consultas para o servidor upstream. TTLs longos reduzem o tráfego upstream, mas podem fazer com que os clientes mantenham endereços desatualizados após uma alteração na infraestrutura.
O armazenamento em cache também se acumula ao longo do caminho. Uma consulta pode ser atendida pelo cache do cliente, pelo cache do encaminhador ou pelo cache do resolvedor upstream, e cada camada executa sua própria contagem regressiva de TTL. Quando um usuário relata uma resposta desatualizada, a solução depende de qual camada a está retendo. Portanto, trate cada cache como um suspeito separado durante a solução de problemas, em vez de simplesmente limpar o que estiver mais próximo.
Meça mais do que a latência média
O tempo médio de busca pode ocultar problemas que afetam alguns usuários ou algumas consultas mais do que outros. Acompanhe a taxa de acertos no cache (cache-hit ratio), a latência média e de cauda (tail latency), a taxa de timeout no upstream e o comportamento de cache negativo. Essas métricas ajudam a distinguir um serviço upstream lento de um encaminhador que perde oportunidades de cache continuamente ou lida de forma inadequada com buscas com falha.
O DNSSEC adiciona outra particularidade. Um resolvedor de validação busca assinaturas e chaves além da própria resposta, portanto, ausências no cache para nomes assinados custam mais do que para 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 número único prevê o tempo de busca em uma determinada rede. O resultado depende do estado do cache em cada camada, da capacidade de resposta do servidor upstream, do trabalho de validação, da configuração de transporte e das tentativas de redirecionamento após um encaminhador não responder. Um encaminhador com bom comportamento também repassa códigos de resposta, comportamento de truncamento, registros DNSSEC e sinalizadores (flags) sem alterações, para que os clientes vejam a resposta que o lado autoritativo enviou.
Escolhendo entre Encaminhamento, Recursão Root-Hints e DNS Criptografado
O encaminhamento e a recursão por root-hints envolvem escolhas com prós e contras diferentes. Com o encaminhamento, a organização seleciona resolvedores upstream para lidar com consultas não respondidas. Isso pode simplificar as operações locais e centralizar 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 busca iterativa, o que reduz a dependência de um único serviço recursivo upstream, mas atribui maior responsabilidade de resolução a esse resolvedor.
| Escolha de design | Onde a resolução acontece | Principal compensação operacional |
|---|---|---|
| Encaminhamento | No resolutor recursivo upstream selecionado | Administração centralizada, com uma dependência upstream |
| Recursão por root-hints | No resolutor recursivo local, que consulta através da hierarquia | Mais controle local, com mais responsabilidade pela resolução direta |
| DNS criptografado direcionado pelo cliente | No resolutor que o cliente contata por meio de uma conexão criptografada | A rede local pode não ver ou controlar a consulta de domínio |
O DNS criptografado torna essa escolha menos simples. O DNS over TLS e o DNS over QUIC podem proteger o tráfego de DNS em trânsito, mas a questão crucial é onde essa criptografia termina. Se um cliente criptografa consultas diretamente para um resolvedor externo, um retransmissor local pode não visualizar uma consulta de domínio útil. Se a criptografia for encerrada em um resolvedor corporativo aprovado, esse resolvedor ainda poderá aplicar políticas de rede e encaminhar as consultas para o upstream.
O WiFi público precisa de uma política deliberada
Os operadores de WiFi público também precisam considerar os Captive Portals. Os dispositivos podem precisar de resolução de nomes pré-autenticação e verificações de conectividade antes que os usuários possam fazer login. O DNS criptografado pode complicar ou atrasar a detecção do portal, portanto, os operadores precisam decidir quais resolvedores são aprovados, como o fallback deve funcionar e se alguma exceção é necessária.
Um serviço de DNS de proteção pode se posicionar no caminho de resolução selecionado e avaliar as pesquisas antes que as conexões comecem. O Purple Shield é projetado para redes de WiFi de visitantes e locais físicos, com filtragem de conteúdo baseada em categorias, bloqueio de ameaças na camada de DNS e políticas que podem ser gerenciadas por rede. Ele pode ser implantado como um serviço autônomo ou integrado às redes Purple Access. Para equipes que estão ponderando controles de DNS em comparação com controles mais amplos de tráfego web, uma visão geral de secure web gateway descreve uma camada diferente de aplicação.
Colocando o Encaminhamento para Funcionar em sua Rede
O encaminhamento concentra parte da carga de trabalho de DNS nos serviços upstream que uma organização seleciona. Medições usando os conjuntos de dados Day in the Life do DNS-OARC descobriram que aproximadamente 99% dos resolutores recursivos geraram volumes moderados de consultas, enquanto cerca de 1% se comportou de forma agressiva. Esse grupo menor foi responsável por até 98% do tráfego de DNS observado em 2018 e 93% em 2019; pesquisadores estimaram que ele incluiu cerca de 8.300 resolutores em 2018 e mais de 14.000 em 2019 (estudo sobre o comportamento agressivo de resolutores). Um resolutor local pode enviar solicitações para serviços recursivos upstream que armazenam em cache e reutilizam respostas, mas isso concentra a dependência em sua disponibilidade e comportamento.
Antes de implantar ou alterar o encaminhamento, verifique se:
- Os upstreams são independentes: configure pelo menos dois retransmissores sempre que a arquitetura permitir.
- As falhas possuem uma resposta definida: defina o tempo limite e o comportamento de tentativa e saiba o que os clientes recebem caso um upstream não responda.
- O monitoramento cobre os sintomas: acompanhe respostas SERVFAIL, tempos limite e latência de resposta.
- As expectativas de privacidade são claras: decida qual resolvedor upstream pode visualizar as consultas encaminhadas.
Se a filtragem de DNS faz parte da política da sua rede de convidados, compare-a com a sua abordagem abrangente de filtragem de conteúdo WiFi. Em seguida, audite para qual resolvedor sua rede faz o encaminhamento e confirme se sua política, disponibilidade e postura de privacidade correspondem ao pretendido.
O Purple Shield verifica as consultas de DNS antes que os dispositivos se conectem e oferece filtragem de conteúdo e bloqueio de ameaças para redes WiFi de visitantes e locais. Se você estiver analisando como o encaminhamento pode dar suporte a esses controles, visite o Purple Shield para explorar suas opções de implantação.