O que é o DNS recursivo: como funciona e porque é importante
O que é o DNS recursivo? Veja como um resolver responde a pesquisas, utiliza a memória cache e onde se enquadram as verificações de segurança, com exemplos claros.
Published 2 de novembro de 2026
Um resolver DNS recursivo é o servidor que aceita uma pesquisa de nome a partir do seu dispositivo e encontra o endereço IP correspondente em seu nome, consultando outros servidores DNS, armazenando depois a resposta para reutilização.
Suponha que alterou uma configuração no seu WiFi para visitantes WiFi, mas um visitante ainda consegue aceder a um site que pretendia bloquear. Antes de alterar a firewall novamente, verifique qual é o resolver utilizado pelo dispositivo do visitante e se a sua política se aplica a respostas em cache. Esses detalhes explicam frequentemente a diferença entre alterar uma regra e vê-la a funcionar.
Índice
- O Que um Resolvedor de DNS Recursivo Faz Pelo Seu Dispositivo
- Comparação Entre Servidores DNS Recursivos e Autoritativos
- Como Uma Consulta Recursiva Percorre a Hierarquia de DNS
- Caching, TTLs e Quanto Tempo Demora Uma Alteração
- Filtragem e Segurança no Resolvedor
- Interrupções, Respostas Obsoletas e Erros Comuns de Perceção
- Confirme Qual o Resolvedor Utilizado Pela Sua Rede Antes de Alterá-lo
O que um Recursive DNS Resolver faz pelo seu dispositivo
Um resolver DNS recursivo localiza respostas DNS para um dispositivo, de forma semelhante a um concierge de hotel que contacta vários departamentos em vez de enviar um hóspede de balcão em balcão. O hóspede faz uma pergunta e espera uma resposta, não instruções para continuar a pesquisa.
Suponha que um hóspede de um hotel abre o seu portátil e introduz o nome de um website. Se o portátil ainda não tiver uma resposta utilizável localmente, envia uma consulta para o seu serviço DNS configurado. Esse serviço pode ser fornecido pela rede do hotel, pelo fornecedor de Internet ou por um resolver configurado separadamente.
As funções por trás de uma pesquisa
- Cliente: O dispositivo ou aplicação que solicita uma resposta de DNS.
- Resolver recursivo: O serviço responsável por encontrar e devolver essa resposta.
- Servidor autoritativo: O servidor que publica os registos oficiais de DNS para o domínio solicitado.
A analogia do concierge facilita a separação dessas responsabilidades.
Para uma pesquisa de endereço bem-sucedida, o dispositivo recebe um endereço IP e um tempo de vida, normalmente abreviado para TTL (Time-to-Live). Esse valor indica aos sistemas de caching durante quanto tempo podem reutilizar a resposta. O navegador pode então utilizar o endereço para começar a contactar o destino.
Recursivo não significa uma repetição infinita. Descreve a responsabilidade que o resolver aceita: encontrar a resposta final para o cliente ou retornar um erro adequado se não o conseguir fazer.
O hóspede do hotel normalmente não sabe que nada disto está a acontecer. Não precisa de escolher servidores de raiz nem de entender quem aloja o DNS do website.
Uma verificação útil da compreensão é simples: o seu dispositivo pede um endereço, o resolver encontra-o e o seu navegador utiliza-o para iniciar uma ligação.
Comparação entre servidores DNS recursivos e autoritativos
Recursive resolver versus servidor autoritativo
| Critério | 'Resolver' recursivo | Servidor autoritativo |
|---|---|---|
| Função principal | Encontra respostas para clientes consultando outros servidores | Publica os registos oficiais para os domínios pelos quais é responsável |
| Origem das respostas | A sua cache ou servidores DNS 'upstream' | Os seus próprios registos de zona |
| Operador típico | Fornecedor de internet, serviço público de 'resolver', proprietário da rede | Proprietário do domínio ou fornecedor de alojamento |
| Contactado diretamente por dispositivos | Sim | Geralmente não; os 'resolvers' contactam-no |
| Armazena em cache respostas de outros domínios | Sim, sujeito ao TTL e às regras de cache locais | Não, não como parte do seu papel autoritativo |
A distinção fundamental é a recuperação versus autoridade. Um resolver recursivo recupera informação para outro recetor. Um servidor autoritativo publica informação para um domínio sob a sua responsabilidade.
Essa diferença é importante ao resolver problemas. Se todos receberem o endereço incorreto do website da sua organização, verifique os registos autoritativos. Se apenas os visitantes de uma determinada rede tiverem problemas, investigue o resolver dessa rede, a sua cache e a sua política.
Os operadores podem sobrepor-se sem fundir as funções
Um fornecedor de internet pode executar um DNS recursivo para os assinantes, enquanto um fornecedor de alojamento publica DNS autoritativo para os clientes. O proprietário de uma rede também pode operar um resolver interno para os dispositivos dos colaboradores.
A mesma organização, e por vezes o mesmo software de servidor, pode desempenhar ambas as funções. Um servidor pode responder de forma autoritativa para um domínio interno e, ao mesmo tempo, resolver nomes de internet não relacionados para os funcionários. A função pertence ao pedido que está a ser processado, e não apenas ao nome da empresa no serviço.
O encaminhamento adiciona outra distinção. Um servidor DNS local pode passar pedidos para um resolver a montante em vez de contactar a hierarquia diretamente. Compreender o encaminhamento de DNS ajuda-o a identificar qual o serviço que realiza a consulta externa.
Um servidor autoritativo não é normalmente o ponto de controlo de filtragem de conteúdos do visitante. Este publica os registos do domínio, em vez de aplicar as regras de rede do visitante.
Pergunta de diagnóstico: Este servidor está a responder a partir de registos pelos quais é responsável ou a encontrar registos em nome de um cliente?
Essa questão é mais útil do que presumir que todos os servidores rotulados como DNS realizam o mesmo trabalho.
Como uma consulta recursiva percorre a hierarquia do DNS
Considere uma pesquisa por www.example.com quando nem o dispositivo nem o seu resolver dispõem das informações necessárias para responder.
O dispositivo envia uma consulta recursiva, solicitando ao seu resolver um resultado final. O resolver faz normalmente consultas iterativas na hierarquia superior: os servidores de raiz e de domínio de topo fornecem encaminhamentos, enquanto o servidor autoritativo fornece o registo solicitado.
Este diagrama mostra o percurso geral antes das trocas individuais.
Acompanhe o pedido e a resposta
O dispositivo contacta o seu 'resolver' configurado. Envia o nome do site porque precisa de um endereço antes de poder contactar o destino.
O 'resolver' verifica a sua cache. Uma resposta em cache utilizável termina a pesquisa imediatamente. Não há razão para solicitar a servidores 'upstream' informações que o 'resolver' ainda pode reutilizar.
Em caso de falha na cache, consulta um servidor de raiz. O servidor de raiz direciona-o para os servidores responsáveis pelo domínio de topo relevante, neste caso, .com.
Consulta um servidor .com. Esse servidor identifica os servidores de nomes autoritativos para example.com, restringindo a pesquisa às autoridades designadas do domínio.
Consulta um servidor autoritativo. O servidor autoritativo devolve o registo de endereço solicitado e o seu TTL, expresso em segundos.
Armazena e devolve a resposta. O 'resolver' retém uma cópia reutilizável e envia o resultado para o dispositivo.
Pedidos posteriores podem utilizar essa cópia em cache. Enquanto a resposta permanecer utilizável, o 'resolver' não precisa de repetir o percurso 'upstream' para o mesmo nome e tipo de registo.
A hierarquia distribui a responsabilidade. Os servidores raiz identificam as autoridades dos domínios de topo, essas autoridades identificam os servidores de nomes de domínio e os administradores de domínios mantêm os registos de destino.
Uma resposta em cache continua a ser uma resposta legítima
A resposta do resolver é normalmente não autoritativa. Isso significa que está a retransmitir informações em vez de responder como autoridade do domínio, e não que a resposta seja pouco fiável.
Algumas implementações reencaminham o pedido para um serviço recursivo a montante, que realiza esse trabalho em seu nome. Além disso, um resolver com referências em cache pode ignorar partes do trajeto ilustrado.
As regras de cache local também são importantes. As notas do APNIC no RIPE 91 identificam temporizadores máximos de cache de resolver comumente observados de 6 horas, 12 horas, 24 horas e 7 dias, mostrando por que razão os administradores não devem assumir que todos os resolvers seguem limites de cache idênticos.
Para outra perspetiva do processo de pesquisa, este vídeo acompanha a resolução de DNS.
Caching, TTLs e o tempo necessário para uma alteração
Um domínio é bloqueado às 9:00 e um portátil na mesma rede continua a abri-lo às 9:40. O intervalo resulta da reutilização. Um TTL funciona como a validade de um bilhete de estacionamento: indica ao resolver durante quanto tempo pode continuar a fornecer uma resposta armazenada antes de ter de consultar novamente o servidor de origem.
Para um registo 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 observados para resolvedores incluem 6 horas, 12 horas, 24 horas e 7 dias, de acordo com as notas da APNIC sobre o RIPE 91. Estas definições regem a atualização dos registos. Elas decidem quanto tempo demora um bloqueio apenas quando a conceção da filtragem se baseia na atualização da resposta DNS em vez de verificar a política atual.
Definições de cache e o seu significado para um novo bloqueio
| Configuração de cache | Valor típico | Efeito num novo bloqueio ou alteração |
|---|---|---|
| TTL de zero segundos | Sem tempo de vida reutilizável | Sob o tratamento normal de TTL, o pedido seguinte ativa uma consulta a montante |
| TTL curto | Segundos a minutos | As alterações de registos tornam-se visíveis logo após cada atualização |
| Temporizador de cache máximo do resolvedor | 6 horas | Limita a retenção de registos cujo TTL seja mais longo |
| Temporizador de cache máximo do resolvedor | 12 horas | Trunca os TTLs de registos mais longos em meio 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 a retenção durante uma semana apenas se o TTL do registo também o permitir |
Separe as alterações de registo das alterações de política
Suponhamos que o endereço autoritativo de um site muda um minuto após um resolvedor guardar a resposta antiga na cache. Esse resolvedor pode continuar a devolver o endereço antigo até ao fim do tempo de vida efetivo, que é o menor valor entre o TTL do registo e o máximo do próprio resolvedor, ajustado a qualquer mínimo aplicado. Com um TTL de registo de 24 horas e um limite de 6 horas, os utilizadores acedem ao novo endereço em seis horas. Com um TTL de registo de 7 dias sob um limite de 7 dias, podem ter de esperar uma semana inteira.
Agora o endereço permanece o mesmo, mas uma equipa de segurança marca o domínio como malicioso. Um resolver que revalide a política atual antes de fornecer uma resposta em cache bloqueia o domínio na consulta seguinte. Um design que apenas reavalie quando a resposta é atualizada deixa o caminho aberto durante o resto do tempo de vida útil, o que pode significar um dia de exposição num limite máximo de 24 horas.
Regra prática: Pergunte quando é que o resolver atualiza a sua resposta DNS e quando reavalia a sua decisão de filtragem. Uma alteração chega aos utilizadores no momento mais tardio desses dois eventos.
Para alterações urgentes, teste um domínio consultado anteriormente, bem como um domínio não armazenado em cache. Monitorize os êxitos na cache (cache hits), o volume de consultas a montante e a entrega de atualizações de políticas como métricas separadas. Uma consulta nova e rápida não garante que os utilizadores não continuem a ter uma resposta em cache.
Filtragem e segurança no resolver
Um resolver pode aplicar regras às consultas que recebe antes de o dispositivo iniciar uma ligação. No entanto, a recursão por si só não fornece essas regras. A classificação de conteúdos, a inteligência sobre ameaças e as verificações de autenticidade do DNS são capacidades distintas.
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 os destinos a que os utilizadores podem aceder. Uma atração familiar pode restringir conteúdos para adultos no WiFi para visitantes WiFi mantendo, ao mesmo tempo, regras diferentes para uma rede administrativa.
Antes de um dispositivo abrir um site ou uma aplicação, pergunta ao DNS onde o encontrar e nós respondemos utilizando a política da rede em que o dispositivo se encontra. Isso torna a identidade da rede importante, e 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 controlos de ameaças podem recusar consultas para domínios conhecidos de phishing e malware. A nossa proteção contra ameaças também bloqueia chamadas de comando e controlo a partir de dispositivos infetados logo na consulta, impedindo que essas tentativas de ligação se iniciem através desse caminho de resolução.
Trata-se de uma contenção útil, mas não remove o malware do dispositivo. A proteção de endpoints e os controlos de firewall continuam a ter as suas próprias funções.
O DNSSEC verifica a autenticidade, não a segurança
A validação DNSSEC utiliza 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 indica que um resolvedor atento à segurança deve considerar a validade da assinatura ao selecionar o tempo de vida da cache, tendo em conta eventuais imprecisões do relógio.
Os administradores precisam, portanto, de uma hora de sistema precisa e de uma gestão de cache que preserve o estado da validação. Um resolver deve distinguir dados legitimamente não assinados de dados assinados que falhem a validação.
- Controlo precoce: A filtragem pode interromper uma pesquisa indesejada antes do início da ligação, mas apenas para pedidos que utilizem esse resolvedor.
- Regras consistentes: Os dispositivos que utilizam a mesma política de rede recebem um tratamento consistente, mas os caminhos de resolução alternativos exigem controlos separados.
- Verificação de autenticidade: O DNSSEC ajuda a detetar respostas assinadas forjadas, mas não encripta consultas nem determina se um domínio é malicioso.
Um domínio de phishing assinado corretamente continua a ser um domínio de phishing. A filtragem decide se o acesso deve ser permitido; o DNSSEC estabelece se as informações DNS assinadas são autênticas.
Interrupções, respostas desatualizadas e equívocos comuns
Um convidado abre um website enquanto o seu servidor DNS autoritativo está inacessível, mas a página continua a carregar. O resolver pode ter uma resposta em cache ainda válida, pelo que não precisa de contactar esse servidor autoritativo para este pedido.
Alguns resolvedores também podem servir respostas expiradas após o vencimento normal quando os servidores de fluxo ascendente (upstream) estiverem indisponíveis. Esta é uma estratégia de disponibilidade e não uma prova de que os registos DNS permanecem válidos indefinidamente. O guia explicativo de DNS da Cloudflare estabelece a distinção subjacente entre o resolvedor que obtém a informação e o servidor autoritativo que a fornece.
As respostas em cache explicam por que motivo uma indisponibilidade num servidor autoritativo nem sempre se transforma numa interrupção imediata da navegação.
A disponibilidade e a proteção exigem escolhas explícitas
Os resolvers também podem armazenar em cache resultados mal-sucedidos. O caching negativo retém informações tais como a não existência de um nome, evitando pesquisas repetidas para o mesmo nome em falta. Após um administrador criar esse nome, alguns clientes podem continuar a receber o resultado negativo armazenado em cache até que este expire.
A gestão de falhas levanta uma questão de política separada. Um design de filtragem fail-open permite a resolução sem as suas verificações normais de política quando essas verificações não estão disponíveis. Um design fail-closed recusa os pedidos que não pode aprovar, mantendo a restrição, mas interrompendo potencialmente o acesso legítimo.
As 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 o carregamento de uma página.
Suposições que causam erros operacionais
- Recursão significa automaticamente bloqueio: A recursão obtém respostas; os administradores adicionam o bloqueio através de uma camada de política.
- Um filtro DNS controla todas as ligações: Endereços de destino introduzidos diretamente e alguns caminhos de VPN podem evitar totalmente a pesquisa protegida.
- Alterar o DNS da rede move instantaneamente todos os clientes: As definições existentes, as concessões DHCP e as opções de resolvedor ao nível do navegador podem deixar os dispositivos noutro caminho.
Ao investigar uma indisponibilidade, distinga entre uma autoridade inacessível, um registo expirado, uma resposta negativa, uma falha de validação e uma rejeição por política. Podem parecer semelhantes para um convidado, mas exigem correções diferentes.
A recursão move respostas. A política e a resiliência determinam quais as respostas que a rede entregará sob condições em mudança.
Confirme qual o resolver que a sua rede utiliza antes de o alterar
Se está a perguntar o que é o DNS recursivo porque está prestes a alterar uma rede em produção, comece por mapear o caminho atual. Registe a configuração em funcionamento para poder restaurá-la se os testes expuserem alguma dependência de nomes internos ou de aplicações.
Verifique o caminho antes da implementação
- Localize o serviço DNS configurado no dispositivo. Utilizar as suas definições de rede ou uma ferramenta de pesquisa DNS. O endereço de um router pode representar um serviço de reencaminhamento, por isso trace também o seu destino 'upstream'.
- Inspecione as definições do DHCP e do controlador. Confirme qual o 'resolver' que a rede anuncia e se os clientes configurados manualmente o seguem.
- Defina a política necessária por escrito. Identifique categorias de conteúdo, controlos de malware, registo de pesquisas e diferenças entre o acesso de funcionários e de convidados.
- Escolha o comportamento de atualização aceitável. Especifique atrasos toleráveis de atualização de registos e de políticas, bem como a resposta pretendida para falhas do serviço.
- Faça um teste piloto numa rede limitada. Teste sites permitidos, destinos bloqueados, recursos internos e recuperação antes de alargar a alteração.
A implementação consiste numa alteração de definições de DNS por rede ou de DHCP no controlador, sem necessidade de instalar nada nos dispositivos clientes. Isto abrange os dispositivos que seguem a configuração de DNS da rede, em vez de garantir que todas as aplicações a utilizam.
Teste VPNs e DNS over HTTPS, que podem criar caminhos de resolução alternativos. A nossa equipa demonstra como a rede lida com VPNs e DNS encriptado antes de iniciar um teste de avaliação.
Um resolver recursivo com políticas de filtragem é a escolha certa quando a rede necessita de filtragem antes do início das ligações e o proprietário aceita o seu comportamento de cache e de falhas.
Purple Shield oferece DNS de proteção, filtragem de conteúdos, defesa contra ameaças e bloqueio de anúncios ao nível do DNS para WiFi para visitantes e redes públicas WiFi sem agentes no dispositivo. Visite Purple Shield para debater o caminho do resolver da sua rede, as políticas de que necessita e como testar a aplicação antes de implementar uma alteração de DNS.