Você digita um endereço no navegador. Em menos de um segundo, o site aparece. Ou não aparece, e a mensagem “servidor DNS não está respondendo” toma conta da tela. Nos dois casos, quem decidiu o resultado foi o DNS.
DNS é a sigla de Domain Name System (Sistema de Nomes de Domínio). Na prática, é o sistema que traduz nomes de domínio (como google.com.br) em endereços IP (como 142.250.79.14) para que seu dispositivo saiba onde se conectar. Sem DNS, você precisaria decorar sequências numéricas para acessar qualquer coisa na internet. Com DNS, basta digitar o nome.
Até aí, simples. O problema é que a maioria dos guias para nessa definição. E quando o DNS falha no seu roteador, no Wi-Fi do seu estabelecimento ou no painel de hospedagem do seu site, saber que “ele traduz nomes em números” não resolve nada. Este guia vai além: mostra como a resolução funciona passo a passo, quais registros importam, como diagnosticar erros, quando vale trocar o servidor DNS e o que a segurança DNS protege de verdade.
Veja mais vídeos como esse em nosso canal do YouTube!
Como o DNS funciona na prática, passo a passo
A analogia clássica compara DNS a uma agenda de contatos: você busca pelo nome, o sistema encontra o número. Funciona para explicar a ideia geral, mas esconde a complexidade real.
O DNS é um sistema distribuído, organizado em hierarquia. Não existe um servidor central com todos os endereços da internet. Existem camadas que colaboram para encontrar a resposta certa.
Quando você digita um endereço no navegador, a sequência prática é esta:
- Cache do navegador. O navegador verifica se já resolveu esse nome recentemente. Se sim, usa o IP armazenado sem perguntar a ninguém.
- Cache do sistema operacional. Se o navegador não tem a resposta, o sistema operacional verifica seu próprio cache.
- Resolvedor recursivo. Se nenhum cache local tem a resposta, a consulta vai para o resolvedor recursivo (geralmente operado pelo seu provedor de internet). Ele faz o trabalho pesado.
- Servidor raiz. O resolvedor pergunta ao servidor raiz: “onde encontro informações sobre .com.br?” O servidor raiz não sabe o IP do site, mas sabe quem cuida do domínio de primeiro nível (.com, .br, .org).
- Servidor de TLD. O servidor de TLD (Top-Level Domain) responde: “o domínio exemplo.com.br está delegado para estes servidores autoritativos.”
- Servidor autoritativo. É quem tem a resposta final. Ele devolve o IP associado ao nome consultado.
- Resposta ao navegador. O resolvedor entrega o IP ao seu dispositivo, que finalmente abre a conexão com o servidor do site.
Tudo isso acontece em milissegundos. Quando o cache resolve, a cadeia inteira é pulada e a resposta chega ainda mais rápido. Quando não resolve, cada camada adiciona tempo.
Entender essa cadeia muda a forma como você diagnostica problemas. Cache desatualizado? O site antigo continua aparecendo. Resolvedor do provedor lento? Tudo demora pra começar a carregar. Servidor autoritativo fora do ar? Ninguém encontra o site, mesmo que ele esteja funcionando.
| Componente | O que faz | Falha típica |
|---|---|---|
| Cache local | Armazena respostas recentes para evitar consultas repetidas | Registro desatualizado continua sendo usado |
| Resolvedor recursivo | Consulta a hierarquia em nome do seu dispositivo | Lentidão, queda ou bloqueio de domínios |
| Servidor raiz | Indica qual servidor cuida do TLD (.com, .br, .org) | Problema de conectividade (raro: há mais de 1.500 instâncias no mundo) |
| Servidor de TLD | Indica os servidores autoritativos do domínio | Delegação quebrada ou NS inconsistente |
| Servidor autoritativo | Publica o IP e os demais registros do domínio | Zona mal configurada, expiração ou ataque |
Uma peça que aparece em todas as camadas: o TTL (Time to Live). É o tempo, em segundos, que cada resposta pode ser reutilizada pelo cache antes de precisar ser consultada de novo. TTL curto significa atualização rápida, mas mais consultas na hierarquia. TTL longo significa menos consultas, mas mudanças demoram a propagar. Essa escolha importa muito quando você muda de hospedagem ou de servidor de e-mail.
Com a mecânica clara, fica mais fácil entender os registros que compõem cada zona.
Registros DNS: os tipos que você encontra no dia a dia
Quando alguém diz “configurar o DNS”, na maioria das vezes está falando de editar registros em uma zona. Cada registro é uma instrução publicada pelo servidor autoritativo para informar onde encontrar um serviço.
Estes são os que aparecem com mais frequência:
| Tipo | Para que serve | Exemplo prático |
|---|---|---|
| A | Associa o nome a um endereço IPv4 | exemplo.com.br → 192.168.1.100 |
| AAAA | Associa o nome a um endereço IPv6 | exemplo.com.br → 2001:db8::1 |
| CNAME | Cria um alias (apelido) apontando para outro nome | www.exemplo.com.br → exemplo.com.br |
| MX | Define o servidor de e-mail do domínio | exemplo.com.br → mail.exemplo.com.br (prioridade 10) |
| TXT | Armazena textos arbitrários (SPF, DKIM, verificações) | “v=spf1 include:_spf.google.com ~all” |
| NS | Indica quais servidores são autoritativos para a zona | exemplo.com.br → ns1.hospedagem.com |
| SOA | Define parâmetros administrativos da zona (serial, refresh, TTL mínimo) | Primeiro registro obrigatório de toda zona |
| PTR | Faz a resolução reversa (IP → nome) | Usado em verificação de e-mail e diagnóstico |
| SRV | Localiza serviços específicos (porta e protocolo) | Usado em VoIP, LDAP, XMPP |
Uma armadilha comum: criar um CNAME no ápice do domínio (exemplo.com.br, sem o “www”). A especificação DNS proíbe que o CNAME coexista com outros registros no mesmo nó, e o ápice sempre tem SOA e NS. O resultado é comportamento imprevisível que pode derrubar e-mail e site ao mesmo tempo.
Propagação DNS: por que mudanças não são instantâneas
Quando você altera um registro (troca de hospedagem, por exemplo), a mudança precisa se espalhar por todos os caches que armazenaram a resposta anterior. Esse processo é a propagação.
O tempo depende do TTL que estava configurado antes da mudança. Se o TTL era de 86.400 segundos (24 horas), os caches ao redor do mundo podem continuar servindo o IP antigo por até 24 horas. Alguns guias falam em “até 48 horas”, mas isso acontece quando há caches intermediários que desrespeitam o TTL ou configurações atípicas.
Dica prática: antes de uma migração, reduza o TTL para 300 segundos (5 minutos) com pelo menos 24 horas de antecedência. Assim, quando a troca acontecer, os caches já estarão com o TTL curto e vão buscar a resposta nova rapidamente.
Até aqui, você sabe como o DNS funciona e quais registros importam. A próxima dúvida costuma ser: o servidor DNS que estou usando é o melhor?
DNS público: vale trocar para 8.8.8.8 ou 1.1.1.1?
Por padrão, seu dispositivo usa o resolvedor DNS do seu provedor de internet. Ele funciona, mas nem sempre é o mais rápido ou o mais confiável. É por isso que milhões de pessoas trocam para resolvedores públicos.
O Google Public DNS usa os endereços 8.8.8.8 e 8.8.4.4 e é um dos resolvedores mais populares do mundo. O Cloudflare usa 1.1.1.1 e 1.0.0.1. O Quad9 usa 9.9.9.9. Cada um tem proposta diferente.
| Resolvedor | Endereços IPv4 | Diferencial | Privacidade |
|---|---|---|---|
| Google Public DNS | 8.8.8.8 / 8.8.4.4 | Cache massivo, velocidade consistente | Registra dados temporariamente para diagnóstico |
| Cloudflare 1.1.1.1 | 1.1.1.1 / 1.0.0.1 | Foco em velocidade, suporte a DoH e DoT | Compromisso de não vender dados; logs apagados em 24h |
| Cloudflare for Families | 1.1.1.2 (malware) / 1.1.1.3 (malware + adulto) | Filtragem de conteúdo malicioso ou adulto | Mesma política do 1.1.1.1 |
| Quad9 | 9.9.9.9 / 149.112.112.112 | Bloqueio de domínios maliciosos com inteligência de ameaças | Declara não registrar IP do usuário |
| DNS do provedor | Varia | Nenhum extra (é o padrão automático) | Depende da política de cada provedor |
Quando faz sentido trocar
Trocar o DNS pode ajudar quando o resolvedor do provedor é lento, instável ou bloqueia sites legítimos. Se você percebe que a internet “demora para começar a carregar” mas depois a velocidade fica normal, o gargalo pode estar na resolução, não na banda.
Mas trocar o DNS não aumenta sua velocidade de download, não corrige cabo rompido e não conserta Wi-Fi com sinal fraco. DNS resolve nomes. Só isso. Se o problema é outro, trocar o DNS é trocar a placa de endereço de uma casa quando o cano de água está furado.
Privacidade: o resolvedor vê tudo que você acessa
Detalhe que passa despercebido: o resolvedor DNS que você usa recebe, em texto aberto, cada nome de site que você consulta. Seu provedor de internet, por padrão, pode registrar esse histórico completo.
Trocar para um resolvedor público transfere essa visibilidade para outro operador. DNS over HTTPS (DoH) e DNS over TLS (DoT) cifram o caminho entre seu dispositivo e o resolvedor, impedindo que o operador do Wi-Fi público ou seu provedor intermediário veja o que você está consultando. Mas o resolvedor escolhido (Google, Cloudflare, Quad9) ainda pode ver a consulta.
Não existe “DNS invisível”. Existe escolha de em quem confiar. Essa escolha importa especialmente em redes públicas, onde qualquer pessoa na mesma rede pode interceptar consultas DNS não cifradas.
Mas mesmo com o resolvedor certo configurado, erros acontecem. E o mais comum tem nome e sobrenome.
Como resolver “servidor DNS não está respondendo”
Essa é a mensagem de erro que mais traz gente ao Google buscando por DNS. Ela aparece quando seu dispositivo tenta consultar o resolvedor e não recebe resposta.
Antes de trocar qualquer configuração, siga esta ordem:
- Teste outro site. Se só um domínio não abre, o problema pode ser no servidor autoritativo daquele domínio, não no seu DNS.
- Teste outro dispositivo. Se outro celular ou computador funciona na mesma rede, o problema está no dispositivo, não no resolvedor.
- Reinicie o roteador. Muitos roteadores têm um cache DNS interno que pode travar ou ficar desatualizado.
- Limpe o cache DNS do dispositivo. No Windows, abra o Prompt de Comando e digite
ipconfig /flushdns. No macOS, usesudo dscacheutil -flushcache. - Teste um resolvedor público. Mude temporariamente para 8.8.8.8 ou 1.1.1.1. Se funcionar, o problema é no resolvedor original.
- Verifique firewall e antivírus. Alguns softwares bloqueiam tráfego na porta 53 (DNS) por engano.
Guias de troubleshooting recomendam esse roteiro básico como ponto de partida. Se nenhuma das etapas resolve, o problema pode estar mais acima: rota de rede interrompida, provedor com falha regional ou o servidor autoritativo do domínio fora do ar.
Ferramentas de diagnóstico
Dois comandos resolvem a maioria das investigações:
Para diagnósticos mais completos de segurança na rede, veja também: o que é adware e como proteger sua rede.
nslookup exemplo.com.br: mostra qual resolvedor está respondendo e qual IP foi retornado. Funciona em Windows, macOS e Linux.dig exemplo.com.br: mais detalhado, exibe TTL, tipo de registro, tempo de resposta e qual servidor autoritativo respondeu. Disponível nativamente no macOS e Linux.
Compare resultados usando resolvedores diferentes: nslookup exemplo.com.br 8.8.8.8 e nslookup exemplo.com.br 1.1.1.1. Se um responde e outro não, o problema está no resolvedor, não no domínio.
Saber diagnosticar é metade do caminho. A outra metade é entender o que a camada de segurança do DNS protege (e onde ela para).
Segurança DNS: o que DNSSEC e DoH protegem de verdade
O DNS foi criado em 1983 sem nenhuma camada de segurança. A resposta viajava em texto aberto, sem verificação de autenticidade. Qualquer intermediário podia alterar o IP retornado e mandar o usuário para um site falso. Esse ataque tem nome: envenenamento de cache (DNS cache poisoning).
Duas tecnologias surgiram para resolver problemas diferentes.
DNSSEC: a resposta é legítima?
DNSSEC adiciona assinaturas digitais aos registros da zona. Quando o resolvedor recebe uma resposta assinada, ele verifica a cadeia de confiança (da zona até a raiz). Se alguém adulterou o registro no caminho, a assinatura não bate e a resposta é descartada.
O que DNSSEC faz: garante autenticidade (quem publicou é quem diz ser) e integridade (o dado não foi alterado no caminho).
O que DNSSEC não faz: não cifra a consulta (todo mundo continua vendo qual site você acessou), não impede ataques DDoS e não protege contra o próprio servidor autoritativo ser comprometido.
A adoção ainda é parcial. Medições globais de 2025 indicavam 36% de validação DNSSEC e apenas 7% de delegação segura. No Brasil, o Registro.br contabilizava 1.814.363 domínios .br com DNSSEC em uma base de quase 5,8 milhões. Ou seja: menos de um terço.
DoH e DoT: quem vê minha consulta?
DNS over HTTPS (DoH) e DNS over TLS (DoT) resolvem outro problema: a privacidade do caminho. Eles cifram a consulta entre seu dispositivo e o resolvedor, impedindo que o operador do Wi-Fi, seu provedor de internet ou qualquer pessoa na mesma rede veja quais domínios você está consultando.
Dados da APNIC mostram que cerca de 26,6% das consultas DNS globais já usam criptografia: 17,4% por DoH e 9,2% por DoT. A tendência é de crescimento.
O que DoH/DoT fazem: protegem a privacidade contra observadores entre você e o resolvedor.
O que DoH/DoT não fazem: não validam a resposta (para isso, precisa de DNSSEC) e não impedem o resolvedor de ver e registrar a consulta.
A combinação ideal usa DNSSEC (autenticidade da zona) junto com DoH ou DoT (privacidade do transporte). São complementares, não substitutos.
Entender essas camadas na teoria é uma coisa. Ver o que acontece quando a infraestrutura DNS de grandes empresas falha dá a dimensão real do risco.
Quando o DNS falha em grande escala: três casos reais
A melhor forma de medir a importância do DNS é observar o que acontece quando ele para de funcionar.
Dyn, 2016: o ataque que derrubou Spotify, Amazon e HBO
Em outubro de 2016, a botnet Mirai (formada por câmeras, roteadores e dispositivos IoT comprometidos) lançou um ataque DDoS contra a Dyn, provedora de DNS gerenciado. O ataque durou 18 horas, deixou entre 25% e 75% das consultas sem resposta em determinados momentos e afetou mais de 1.200 domínios monitorados.
Nenhuma dessas empresas foi invadida. Seus servidores estavam funcionando normalmente. Mas como todas usavam a Dyn como único provedor DNS, os usuários não conseguiam descobrir o endereço IP dos serviços. Sem resolver o nome, o navegador não tinha para onde ir.
Lição direta: DNS precisa de redundância. Um único provedor é um único ponto de falha.
Meta, 2021: o DNS funcionava, mas ninguém chegava nele
Em outubro de 2021, uma manutenção de backbone da Meta removeu rotas BGP que conectavam seus data centers à internet. Os servidores DNS do Facebook continuavam operacionais, mas inalcançáveis, porque o caminho de rede até eles simplesmente deixou de existir.
Facebook, Instagram e WhatsApp ficaram fora do ar por horas. Não foi ataque. Foi uma mudança interna que quebrou a conectividade de rede, e o DNS sofreu como consequência.
Lição: DNS correto não basta. A rede que leva até os servidores autoritativos também precisa funcionar. São camadas diferentes.
Cloudflare, 2025: uma mudança de software derrubou vários serviços
Em novembro de 2025, a Cloudflare registrou uma falha causada por uma mudança de permissões em banco de dados. Um arquivo do Bot Management dobrou de tamanho, derrubou o proxy central e afetou CDN, Workers KV, Dashboard e outros serviços. A empresa confirmou que não foi ataque cibernético.
Lição: quando uma plataforma concentra DNS, proxy, segurança e CDN, uma falha em qualquer função pode ter efeito cascata. Diversificar fornecedores reduz o raio de impacto.
Esses três casos compartilham um princípio: depender de um único ponto para a resolução DNS é aceitar que uma falha naquele ponto derruba tudo. E isso vale para empresas de qualquer porte, incluindo o negócio que oferece Wi-Fi a clientes no balcão.
DNS e a rede do seu negócio: o ponto que gestores ignoram
Se você gerencia um estabelecimento comercial (restaurante, academia, hotel, clínica), provavelmente oferece Wi-Fi para clientes. E pode nunca ter pensado em DNS como parte da experiência que entrega.
Quando um cliente conecta no Wi-Fi e é redirecionado para uma tela de login (o captive portal), o DNS é o mecanismo que intercepta a consulta do navegador e direciona para a página de autenticação. Se o DNS interno falha, o portal não carrega. O cliente não faz login. Você não captura o dado.
Essa dependência silenciosa tem implicações diretas:
- DNS mal configurado no roteador do estabelecimento causa lentidão para todos os clientes conectados.
- Resolvedor externo instável transforma o Wi-Fi “gratuito” em fonte de reclamação.
- Captive portal que depende de resolução externa pode quebrar quando o provedor de internet falha, mesmo que o link local esteja funcionando.
Redes comerciais que usam Wi-Fi marketing com hotspot social transformam o momento da conexão em captura de lead: nome, telefone, e-mail, tudo via opt-in no captive portal. Se o DNS que sustenta essa cadeia falha, o canal de captura para. E com ele, a base de clientes que alimenta campanhas de retorno, recompra e fidelização.
A recomendação para redes de PDV: configure um resolvedor confiável e rápido no roteador (não dependa apenas do DNS do provedor), monitore a resolução periodicamente e tenha um secundário configurado. DNS não é “coisa de TI distante”. É a primeira camada da experiência digital que o cliente tem no seu espaço.
Se a sua operação usa Wi-Fi como canal de marketing e captura, faz sentido conversar com quem entende de infraestrutura para PDV.
Perguntas frequentes
O que é DNS em uma frase?
DNS (Domain Name System) é o sistema distribuído que traduz nomes de domínio em endereços IP, permitindo que navegadores e aplicativos encontrem servidores na internet sem que você precise memorizar sequências numéricas.
Trocar o DNS para 8.8.8.8 deixa a internet mais rápida?
Pode reduzir o tempo de resolução se o resolvedor do seu provedor for lento, mas não aumenta a velocidade de download nem corrige problemas de Wi-Fi ou cabo. O ganho é especificamente no tempo que o sistema leva para descobrir o IP do site, não na transferência de dados em si.
DNSSEC e DoH são a mesma coisa?
Não. DNSSEC valida autenticidade e integridade da resposta DNS (garante que o dado não foi adulterado). DoH cifra o caminho entre seu dispositivo e o resolvedor (impede que terceiros vejam qual site você consultou). Protegem contra ameaças diferentes e funcionam melhor quando usados juntos.
O que fazer quando aparece “servidor DNS não está respondendo”?
Teste outro site, teste outro dispositivo na mesma rede, reinicie o roteador, limpe o cache DNS (ipconfig /flushdns no Windows) e experimente temporariamente um resolvedor público como 8.8.8.8 ou 1.1.1.1. Se nada resolver, o problema pode estar no provedor de internet ou no servidor autoritativo do domínio.
Quanto tempo leva a propagação DNS?
Depende do TTL (Time to Live) configurado no registro antes da alteração. Com TTL de 24 horas, a propagação pode levar até 24 horas. Para migrações planejadas, reduza o TTL para 300 segundos (5 minutos) pelo menos um dia antes de fazer a mudança.
DNS pode ser usado para bloquear sites?
Sim. Resolvedores como Quad9 bloqueiam domínios associados a malware e phishing. O Cloudflare for Families filtra conteúdo adulto. Empresas usam soluções como Cisco Umbrella para bloquear categorias inteiras. O bloqueio via DNS é simples de implementar, mas pode ser contornado por quem troca o resolvedor manualmente.
