O que é DNS recursivo: como funciona e por que é importante
O que é DNS recursivo? Veja como um resolvedor responde a consultas, usa cache e onde as verificações de segurança se encaixam, com exemplos claros.
Published 2 de novembro de 2026
Um resolvedor DNS recursivo é o servidor que recebe uma busca de nome do seu dispositivo, localiza o endereço IP correspondente em seu nome consultando outros servidores DNS e armazena a resposta para reutilização.
Suponha que você tenha alterado uma configuração no seu WiFi para visitantes WiFi, mas um visitante ainda consiga acessar um site que você pretendia bloquear. Antes de alterar o firewall novamente, verifique qual resolvedor o dispositivo dele usa e se a sua política se aplica a respostas em cache. Esses detalhes costumam explicar a lacuna entre a alteração de uma regra e a visualização do seu funcionamento.
Sumário
- O que um resolvedor DNS recursivo faz pelo seu dispositivo
- Comparativo entre servidores DNS recursivos e autoritativos
- Como uma consulta recursiva percorre a hierarquia do DNS
- Caching, TTLs e quanto tempo uma alteração leva
- Filtragem e segurança no resolvedor
- Interrupções, respostas desatualizadas e equívocos comuns
- Confirme qual resolvedor sua rede usa antes de alterá-lo
O que um resolvedor DNS recursivo faz pelo seu dispositivo
Um resolver DNS recursivo encontra respostas de DNS para um dispositivo, funcionando de forma semelhante ao concierge de um hotel que entra em contato com vários setores em vez de enviar o hóspede de guichê em guichê. O hóspede faz uma pergunta e espera uma resposta, não instruções para continuar a busca.
Suponha que o hóspede de um hotel abra seu notebook e digite o nome de um site. Se o notebook ainda não tiver uma resposta útil localmente, ele enviará uma consulta ao seu serviço DNS configurado. Esse serviço pode ser fornecido pela rede do hotel, pelo provedor de internet ou por um resolver configurado separadamente.
As funções por trás de uma consulta
- Cliente: O dispositivo ou aplicativo que solicita uma resposta de DNS.
- Resolvedor recursivo: O serviço responsável por encontrar e retornar essa resposta.
- Servidor autoritativo: O servidor que publica os registros de DNS oficiais para o domínio solicitado.
A analogia com o concierge torna essas responsabilidades mais fáceis de separar.
Para uma consulta de endereço bem-sucedida, o dispositivo recebe um endereço IP e um tempo de vida, geralmente abreviado como TTL. Esse valor informa aos sistemas de cache por quanto tempo eles podem reutilizar a resposta. O navegador pode então usar o endereço para começar a contatar o destino.
Recursivo não significa repetição sem fim. Esse termo descreve a responsabilidade que o resolvedor aceita: encontrar a resposta final para o cliente ou retornar um erro apropriado se não conseguir.
O hóspede do hotel geralmente não sabe que nada disso está acontecendo. Ele não precisa escolher servidores raiz nem entender quem hospeda o DNS do site.
Uma verificação útil de compreensão é simples: seu dispositivo solicita um endereço, o resolvedor o localiza e seu navegador o utiliza para iniciar uma conexão.
Comparação entre servidores DNS recursivos e autoritativos
Resolvedor recursivo versus servidor autoritativo
| Critério | Resolvedor recursivo | Servidor autoritativo |
|---|---|---|
| Função principal | Encontra respostas para clientes consultando outros servidores | Publica os registros oficiais para os domínios pelos quais é responsável |
| De onde vêm as respostas | De seu cache ou de servidores DNS upstream | De seus próprios registros de zona |
| Operador típico | Provedor de internet, serviço de resolvedor público, proprietário da rede | Proprietário do domínio ou provedor de hospedagem |
| Contatado diretamente por dispositivos | Sim | Geralmente não; os resolvedores entram em contato com ele |
| Armazena respostas em cache para outros domínios | Sim, sujeito ao TTL e às regras de cache local | Não, não como parte de sua função autoritativa |
A principal distinção é busca versus autoridade. Um resolver recursivo busca informações para outra entidade. Um servidor autoritativo publica informações para um domínio sob sua responsabilidade.
Essa diferença é importante ao solucionar problemas. Se todos receberem o endereço errado para o site da sua organização, verifique os registros autoritativos. Se apenas os visitantes de uma rede específica tiverem problemas, investigue o resolver dessa rede, seu cache e sua política.
Os operadores podem se sobrepor sem mesclar as funções
Um provedor de internet pode executar um DNS recursivo para os assinantes, enquanto um provedor de hospedagem publica o DNS autoritativo para os clientes. O proprietário de uma rede também pode operar um resolvedor interno para os dispositivos da equipe.
A mesma organização e, às vezes, o mesmo software de servidor podem realizar ambas as funções. Um servidor pode responder de forma autoritativa para um domínio interno enquanto resolve nomes de internet não relacionados para os funcionários. A função pertence à solicitação que está sendo tratada, e não apenas ao nome da empresa no serviço.
O encaminhamento adiciona outra distinção. Um servidor DNS local pode passar solicitações para um resolvedor upstream em vez de contatar a própria hierarquia. Entender o encaminhamento de DNS ajuda você a identificar qual serviço realiza a consulta externa.
Um servidor autoritativo não é normalmente o ponto de verificação de filtragem de conteúdo do visitante. Ele publica os registros do domínio, em vez de aplicar as regras de rede do visitante.
Pergunta diagnóstica: Este servidor está respondendo a partir de registros pelos quais é responsável ou está localizando registros em nome de um cliente?
Essa pergunta é mais útil do que presumir que todos os servidores rotulados como DNS fazem o mesmo trabalho.
Como uma consulta recursiva percorre a hierarquia do DNS
Considere uma busca por www.example.com quando nem o dispositivo nem o seu resolvedor possuem as informações necessárias para responder.
O dispositivo envia uma consulta recursiva, pedindo ao seu resolver um resultado final. O resolver normalmente faz consultas iterativas no nível upstream: servidores raiz e de domínio de nível superior fornecem encaminhamentos, enquanto o servidor autoritativo fornece o registro solicitado.
Este diagrama mostra a jornada geral antes das trocas individuais.
Acompanhe a solicitação e a resposta
O dispositivo entra em contato com o resolvedor configurado. Ele envia o nome do site porque precisa de um endereço antes de poder contatar o destino.
O resolvedor verifica seu cache. Uma resposta armazenada em cache e utilizável encerra a busca imediatamente. Não há razão para solicitar a servidores upstream informações que o resolvedor ainda pode reutilizar.
Em caso de falha no cache, ele faz a consulta a um servidor raiz. O servidor raiz o direciona para os servidores responsáveis pelo domínio de nível superior relevante, neste caso, .com.
Ele faz a consulta a um servidor .com. Esse servidor identifica os servidores de nome autoritativos para example.com, restringindo a pesquisa às autoridades designadas do domínio.
Ele consulta um servidor autoritativo. O servidor autoritativo retorna o registro de endereço solicitado e seu TTL, expresso em segundos.
Ele armazena e retorna a resposta. O resolvedor retém uma cópia reutilizável e envia o resultado para o dispositivo.
Solicitações posteriores podem usar essa cópia em cache. Enquanto a resposta permanecer utilizável, o resolvedor não precisa repetir o trajeto upstream para o mesmo nome e tipo de registro.
A hierarquia distribui a responsabilidade. Os servidores raiz identificam as autoridades do domínio de nível superior (TLD), essas autoridades identificam os servidores de nomes de domínio e os administradores do domínio mantêm os registros de destino.
Uma resposta em cache ainda é uma resposta legítima
A resposta do resolvedor é normalmente não autoritativa. Isso significa que ele está retransmitindo informações em vez de responder como autoridade do domínio, e não que a resposta seja não confiável.
Algumas implantações encaminham a solicitação para um serviço recursivo upstream, que realiza esse trabalho em seu nome. Além disso, um resolvedor com encaminhamentos em cache pode ignorar partes do trajeto ilustrado.
As regras de cache local também são importantes. As notas da APNIC do RIPE 91 identificam temporizadores de cache máximo de resolvedores comumente observados de 6 horas, 12 horas, 24 horas e 7 dias, mostrando por que os administradores não devem presumir que todos os resolvedores seguem limites de cache idênticos.
Para outra perspectiva do processo de consulta, este vídeo acompanha a resolução de DNS.
Armazenamento em cache, TTLs e quanto tempo leva uma alteração
Um domínio é bloqueado às 9:00, e um notebook na mesma rede ainda o abre às 9:40. Essa diferença vem da reutilização. Um TTL funciona como o tempo de expiração de um bilhete de estacionamento: ele diz ao resolver quanto tempo ele pode continuar fornecendo uma resposta armazenada antes de ter que voltar ao servidor upstream e perguntar novamente.
Para um registro em cache comum, a quantidade que importa é o tempo de vida restante. O temporizador máximo de cache de um resolvedor pode encurtar esse tempo de vida, enquanto um mínimo aplicado localmente pode prolongá-lo. Os máximos de resolvedor observados incluem 6 horas, 12 horas, 24 horas e 7 dias, de acordo com as notas da APNIC do RIPE 91. Essas configurações regem a atualização do registro. Elas decidem quanto tempo um bloqueio leva apenas quando o projeto de filtragem depende da atualização da resposta DNS em vez da verificação da política atual.
Configurações de cache e o que elas significam para um novo bloqueio
| Configuração de cache | Valor típico | Efeito em um novo bloqueio ou alteração |
|---|---|---|
| TTL de zero segundos | Sem tempo de vida reutilizável | Sob o tratamento normal de TTL, a próxima solicitação aciona uma consulta upstream |
| TTL curto | Segundos a minutos | As alterações de registro tornam-se visíveis logo após cada atualização |
| Temporizador de cache máximo do resolvedor | 6 horas | Limita a retenção de registros cujo TTL seja mais longo |
| Temporizador de cache máximo do resolvedor | 12 horas | Trunca TTLs de registro mais longos na metade de um dia |
| Temporizador de cache máximo do resolvedor | 24 horas | Permite que uma resposta persista durante a noite, até um dia inteiro |
| Temporizador de cache máximo do resolvedor | 7 dias | Permite retenção de uma semana apenas onde o TTL do registro também permitir |
Separe as alterações de registros das alterações de políticas
Suponha que o endereço autoritativo de um site mude um minuto após um resolvedor armazenar a resposta antiga no cache. Esse resolvedor pode continuar retornando o endereço antigo até que o tempo de vida efetivo termine, que é o menor valor entre o TTL do registro e o limite máximo do próprio resolvedor, ajustado para qualquer mínimo aplicado. Com um TTL de registro de 24 horas e um limite de 6 horas, os usuários alcançam o novo endereço em até seis horas. Com um TTL de registro de 7 dias sob um limite de 7 dias, eles podem esperar uma semana inteira.
Agora o endereço permanece o mesmo, mas uma equipe de segurança marca o domínio como malicioso. Um resolvedor que verifica novamente a política atual antes de fornecer uma resposta em cache bloqueia o domínio na próxima consulta. Um projeto que avalia novamente apenas quando a resposta é atualizada deixa o caminho aberto pelo restante do tempo de vida útil efetivo, o que pode significar um dia de exposição em um limite de 24 horas.
Regra prática: Pergunte quando o resolver atualiza sua resposta de DNS e quando ele reavalia sua decisão de filtragem. Uma alteração chega aos usuários no momento posterior entre esses dois acontecimentos.
Para alterações urgentes, teste tanto um domínio consultado anteriormente quanto um que não esteja em cache. Monitore acertos de cache, volume de consultas upstream e entrega de atualizações de políticas como métricas separadas. Uma consulta recente e rápida não diz nada sobre os usuários que ainda mantêm uma resposta em cache.
Filtragem e segurança no resolvedor
Um resolver pode aplicar regras às consultas que recebe antes de o dispositivo iniciar uma conexão. No entanto, a recursão por si só não fornece essas regras. Classificação de conteúdo, inteligência de ameaças e verificações de autenticidade de DNS são recursos separados.
A filtragem de conteúdo define regras de acesso
A filtragem de DNS baseada em categorias permite que o proprietário de uma rede decida quais destinos os usuários podem alcançar. Uma atração familiar pode restringir conteúdo adulto no WiFi para visitantes WiFi enquanto mantém regras diferentes para uma rede administrativa.
Antes que um dispositivo abra um site ou aplicativo, ele pergunta ao DNS onde encontrá-lo, e nós respondemos usando a política da rede na qual o dispositivo está conectado. Isso torna a identidade da rede importante, não apenas o domínio solicitado.
As funções principais são distintas, mesmo quando um único serviço as fornece.
A defesa contra ameaças avalia o destino
Os controles de ameaças podem recusar consultas para domínios conhecidos de phishing e malware. Nossa defesa contra ameaças também bloqueia retornos de chamada (callbacks) de comando e controle a partir de dispositivos infectados logo na consulta, impedindo que essas tentativas de conexão iniciem por esse caminho de resolução.
Essa é uma contenção útil, mas não remove o malware do dispositivo. A proteção de endpoint e os controles de firewall ainda têm suas próprias funções.
O DNSSEC verifica a autenticidade, não a segurança
A validação DNSSEC usa uma âncora de confiança configurada e uma cadeia de assinaturas criptográficas para autenticar dados DNS assinados. O RFC 4033 descreve a validação segura e afirma que um resolvedor ciente da segurança deve considerar a validade da assinatura ao selecionar o tempo de vida do cache, levando em conta imprecisões do relógio.
Portanto, os administradores precisam de um horário de sistema preciso e de um gerenciamento de cache que preserve o status de validação. O resolvedor deve distinguir dados legitimamente não assinados de dados assinados que falham na validação.
- Controle antecipado: A filtragem pode interromper uma busca indesejada antes que uma conexão seja iniciada, mas apenas para solicitações que usam esse resolvedor.
- Regras consistentes: Os dispositivos que usam a mesma política de rede recebem um tratamento consistente, mas os caminhos de resolução alternativos exigem controles separados.
- Verificação de autenticidade: O DNSSEC ajuda a detectar respostas assinadas forjadas, mas não criptografa consultas nem determina se um domínio é malicioso.
Um domínio de phishing assinado corretamente continua sendo um domínio de phishing. A filtragem decide se o acesso deve ser permitido; o DNSSEC estabelece se as informações de DNS assinadas são autênticas.
Interrupções, respostas desatualizadas e equívocos comuns
Um visitante abre um site enquanto seu servidor DNS autoritativo está inacessível, mas a página ainda é carregada. O resolver pode ter uma resposta em cache que não expirou, portanto, não precisa contatar esse servidor autoritativo para essa solicitação.
Alguns resolvedores também podem fornecer respostas desatualizadas após a expiração comum, quando os servidores upstream não estiverem disponíveis. Essa é uma estratégia de disponibilidade, não uma prova de que os registros DNS permanecem atualizados indefinidamente. O explicativo de DNS da Cloudflare fornece a distinção fundamental entre o resolvedor que recupera as informações e o servidor autoritativo que as fornece.
As respostas armazenadas em cache explicam por que uma interrupção autoritativa nem sempre se transforma em uma interrupção imediata na navegação.
Disponibilidade e proteção exigem escolhas explícitas
Os resolvers também podem armazenar em cache resultados malsucedidos. O cache negativo retém informações, como a não existência de um nome, evitando buscas repetidas pelo mesmo nome ausente. Depois que um administrador cria esse nome, alguns clientes ainda podem receber o resultado negativo armazenado em cache até que ele expire.
O tratamento de falhas levanta uma questão de política separada. Um projeto de filtragem fail-open permite a resolução sem suas verificações de política normais quando essas verificações não estão disponíveis. Um projeto fail-closed recusa solicitações que não pode aprovar, mantendo a restrição, mas potencialmente interrompendo o acesso legítimo.
Falhas de validação DNSSEC são outro caso distinto. Os operadores não devem tratar dados assinados inválidos como autenticados apenas para manter uma página carregando.
Suposições que causam erros operacionais
- Recursão significa bloqueio automaticamente: A recursão recupera respostas; os administradores adicionam o bloqueio por meio de uma camada de política.
- Um filtro DNS controla todas as conexões: Endereços de destino codificados e alguns caminhos de VPN podem evitar completamente a busca protegida.
- A alteração do DNS de rede move instantaneamente todos os clientes: Configurações existentes, concessões DHCP e escolhas de resolvedores no nível do navegador podem deixar os dispositivos em outro caminho.
Ao investigar uma interrupção, distinga entre uma autoridade inacessível, um registro expirado, uma resposta negativa, uma falha de validação e uma rejeição por política. Eles podem parecer semelhantes para um visitante, mas exigem soluções diferentes.
A recursão move as respostas. As políticas e a resiliência determinam quais respostas a rede entregará em condições variáveis.
Confirme qual resolvedor sua rede usa antes de alterá-lo
Se você está perguntando o que é DNS recursivo porque está prestes a alterar uma rede em operação, comece mapeando o caminho atual. Registre a configuração funcional para poder restaurá-la caso os testes exponham uma dependência de aplicação ou de nome interno.
Verifique o caminho antes da implantação
- Localize o serviço DNS configurado do dispositivo. Use suas configurações de rede ou uma ferramenta de consulta DNS. O endereço de um roteador pode representar um serviço de encaminhamento, portanto, rastreie também seu destino upstream.
- Inspecione as configurações do DHCP e do controlador. Confirme qual resolvedor a rede anuncia e se os clientes configurados manualmente o seguem.
- Registre a política necessária. Identifique categorias de conteúdo, controles de malware, log de consultas e diferenças entre o acesso de funcionários e de convidados.
- Escolha um comportamento de atualização aceitável. Especifique atrasos toleráveis de atualização de registros e de políticas, além da resposta pretendida para falhas no serviço.
- Faça um piloto em uma rede limitada. Teste sites permitidos, destinos bloqueados, recursos internos e recuperação antes de estender a alteração.
A implantação é uma configuração de DNS por rede ou uma alteração de DHCP no controlador, sem necessidade de instalar nada nos dispositivos clientes. Isso abrange os dispositivos que seguem a configuração de DNS da rede, em vez de garantir que todas as aplicações a utilizem.
Teste VPNs e DNS over HTTPS, que podem criar caminhos de resolução alternativos. Nossa equipe demonstra como a rede lida com VPNs e DNS criptografado antes de um período de teste.
Um resolvedor recursivo com política é a escolha certa quando a rede precisa de filtragem antes do início das conexões e o proprietário aceita o seu comportamento de cache e de falhas.
O Purple Shield oferece DNS protetivo, filtragem de conteúdo, defesa contra ameaças e bloqueio de anúncios na camada de DNS para WiFi para visitantes e WiFi público WiFi sem agentes de dispositivos. Visite Purple Shield para discutir o caminho do resolvedor da sua rede, as políticas de que você precisa e como testar a aplicação antes de implementar uma alteração de DNS.