Segurança Tech

Guia Completo: DNS por dentro (resolução, cache, TTL, DoH/DoT e DNSSEC)

Leia também:

• O que é DNS?
• O que é NAT?
• Engenharia social: como os golpistas te manipulam

1) O que é DNS (sem romantizar): o tradutor que a internet usa o tempo todo

DNS significa Domain Name System. Ele existe por um motivo simples: pessoas lembram nomes, computadores usam números. Você lembra segurancatech.com.br. Seu dispositivo precisa do endereço IP do servidor que hospeda o site.

DNS é o sistema responsável por responder perguntas como:

• “Qual é o IP do domínio segurancatech.com.br?”
• “Esse domínio tem IPv6?”
• “Para onde vai o e-mail desse domínio?”
• “Existe um subdomínio chamado api ou www?”

Se DNS falha, o link pode estar perfeito e mesmo assim você vê sintomas como:

• Sites não abrem por nome, mas ping em IP funciona;
• Apps específicos quebram (YouTube ok, banco não; ou o contrário);
• Rede “parece conectada”, porém “sem internet” no celular;
• Erros do tipo DNS_PROBE_FINISHED_NXDOMAIN / SERVFAIL.

2) Peças do DNS: quem faz o quê?

Para dominar DNS, você precisa separar os papéis. O que confunde as pessoas é achar que “DNS é uma coisa só”. Na prática, existem vários atores:

Quando você entende isso, você consegue diagnosticar: o problema está no cliente? No resolutor do provedor? Na autoridade do domínio? No caminho? Em cache velho? Em DNSSEC?

3) O caminho completo da resolução (o “filme” real da internet)

Vamos montar o fluxo de verdade, do zero, quando você abre um domínio pela primeira vez (sem cache):

3.1) Seu dispositivo pergunta para o DNS configurado

Seu PC/celular pega o DNS automaticamente via DHCP (normalmente o roteador repassa o DNS do provedor, ou o próprio roteador faz forwarder). É aqui que erros de DHCP/DNS começam a aparecer.

3.2) O resolvedor recursivo faz o “trabalho pesado”

Se ele não tem resposta em cache, ele consulta:

• Servidores raiz → “onde está o .com?”
• Servidores TLD (.com) → “onde está o DNS autoritativo do domínio?”
• Servidor autoritativo → “qual o A/AAAA do domínio?”

Quando encontra a resposta, ele devolve para seu dispositivo e grava em cache por um tempo determinado por um valor chamado TTL.

3.3) O navegador abre a conexão com o IP encontrado

DNS termina aqui. O resto envolve TCP/TLS/HTTP. Por isso dá para ter “DNS ok” e mesmo assim o site estar fora. Mas quando DNS está ruim, normalmente nem chega nessa etapa.

4) TTL e cache: por que “mudou o IP e não atualiza” ou “para mim abre, para você não”

TTL (Time To Live) é o tempo (em segundos) que uma resposta pode ficar em cache. Exemplo: TTL 300 significa 5 minutos. TTL 3600 significa 1 hora.

Cache existe por boas razões:

• acelera a navegação;
• reduz consultas repetidas aos servidores autoritativos;
• melhora estabilidade em picos;
• barateia a operação de infraestrutura.

Mas cache também gera situações que confundem:

• “Migrei o site e alguns ainda veem o antigo” → caches com TTL alto ainda não expiraram.
• “No meu 4G funciona, no Wi-Fi não” → resolutores diferentes com caches diferentes.
• “No PC abre, no celular não” → cache local do sistema/navegador.

5) Tipos de registros DNS (o que cada um faz de verdade)

DNS não serve apenas para “domínio → IP”. Ele guarda vários tipos de informação. Os mais importantes:

• A: aponta domínio para um IPv4 (ex.: 104.21.x.x).
• AAAA: aponta domínio para um IPv6.
• CNAME: cria um “apelido” (um nome aponta para outro nome).
• MX: define servidores de e-mail do domínio.
• TXT: textos usados para verificação e políticas (SPF, DKIM, DMARC, validações).
• NS: servidores autoritativos do domínio.
• SRV: localiza serviços específicos (com porta e prioridade), usado em alguns sistemas.

5.1) A vs CNAME: o erro clássico

Um erro comum é misturar A e CNAME na mesma raiz de host, ou criar CNAME onde não deve. Em muitos DNS managers, o host “@” (raiz) tem restrições. Em geral, seu provedor DNS explica o que é permitido.

5.2) AAAA (IPv6) e dual-stack: por que alguns usuários têm rota diferente

Se você tem AAAA, clientes com IPv6 podem preferir IPv6 (dependendo do sistema). Isso muda o caminho até o servidor. Às vezes IPv4 está ok e IPv6 está ruim (ou vice-versa). Resultado: “para mim abre, para você não”.

6) DNS do provedor vs DNS público: quando faz sentido trocar?

DNS do provedor geralmente é mais “próximo” da sua rede, o que pode ser bom para latência. Mas em alguns cenários, DNS público pode ser mais estável, rápido ou com recursos extras.

Quando faz sentido testar outro DNS:

• o DNS atual está instável (SERVFAIL intermitente);
• há lentidão perceptível na primeira abertura de sites;
• há cache “envenenado” ou inconsistências temporárias;
• você quer filtrar malware/ads (alguns serviços oferecem isso);
• você precisa contornar falhas locais (sem “gambiarra permanente”).

7) DoH e DoT: DNS criptografado (o que é e o que muda)

Tradicionalmente, DNS usa porta 53 (UDP/TCP) sem criptografia. Isso permite que redes e provedores vejam consultas (quais domínios você resolve). Para melhorar privacidade e integridade, surgiram:

• DoT (DNS over TLS): DNS dentro de TLS (porta 853).
• DoH (DNS over HTTPS): DNS dentro de HTTPS (porta 443).

Na prática:

• DoH “parece” tráfego web, o que dificulta inspeção/bloqueio simples;
• DoT é mais explícito e fácil de identificar como DNS criptografado;
• Ambos aumentam privacidade, mas podem complicar políticas corporativas.

Em casa, DoH pode ajudar a evitar interferência e melhorar privacidade. Em empresa, pode quebrar controles de DNS internos (split DNS). Então a decisão deve considerar o cenário.

8) DNSSEC: autenticidade de respostas (e por que às vezes quebra)

DNSSEC adiciona assinaturas criptográficas para garantir que a resposta DNS é autêntica (não foi alterada no caminho). Ele aumenta segurança contra certos ataques, mas exige configuração correta.

Problemas típicos com DNSSEC:

• assinatura expirada (rotinas de rotação falharam);
• cadeia quebrada (DS/keys inconsistentes);
• provedor DNS autoritativo com erro de publicação;
• resolutor que valida DNSSEC recusando respostas inválidas (SERVFAIL).

9) Cenários reais (os mais comuns no suporte técnico)

9.1) “Wi-Fi conecta, mas diz ‘Sem internet’”

Muitas vezes o teste de conectividade do sistema falha por DNS. O dispositivo até consegue pingar um IP, mas não resolve o domínio de teste.

Diagnóstico rápido:

• o dispositivo recebeu DNS via DHCP?
• esse DNS responde rápido?
• trocar DNS temporariamente resolve?

9.2) “Alguns sites abrem, outros não”

Isso pode ser:

• DNS com respostas erradas/incompletas;
• IPv6 quebrado (AAAA preferido, mas rota ruim);
• cache velho após migração;
• MTU/fragmentação (parece DNS, mas não é).

9.3) “Para mim abre, para você não” (clássico de TTL/cache)

Se um usuário usa DNS do provedor e outro usa DNS público, cada um pode estar vendo respostas diferentes temporariamente, devido a cache e TTL.

10) Diagnóstico profissional: como achar a causa sem “mexer em tudo”

Esse é o roteiro que separa suporte amador de suporte técnico de verdade.

10.1) Etapa 1 — Conectividade IP (antes de culpar DNS)

• O dispositivo tem IP válido (não 169.254)?
• Gateway está correto?
• Você consegue acessar um IP (ex.: abrir um site por IP, quando possível)?

10.2) Etapa 2 — Teste DNS direto

Você quer saber: o DNS está respondendo? E respondendo certo?

Windows (PowerShell):
nslookup segurancatech.com.br

Linux/macOS:
dig segurancatech.com.br
dig AAAA segurancatech.com.br

Se nslookup/dig demora ou falha com SERVFAIL/timeouts, você tem pista forte.

10.3) Etapa 3 — Compare resolutores

Teste com um DNS diferente para validar hipótese:

Exemplo (dig com servidor específico):
dig @1.1.1.1 segurancatech.com.br
dig @8.8.8.8 segurancatech.com.br

Se um funciona e outro não, o problema pode ser o resolutor (ou o caminho até ele), não o domínio.

10.4) Etapa 4 — Verifique IPv6 vs IPv4

Se AAAA responde e o cliente usa IPv6, mas a rota IPv6 está ruim, você verá falhas “misteriosas”. Teste separadamente. Se necessário, uma solução temporária é priorizar IPv4 até corrigir a rota IPv6 (isso é diagnóstico, não “gambiarra eterna”).

11) O que fazer imediatamente (primeiras 24 horas) quando parece “problema de DNS”

• 1) Não mexa em 10 coisas. Comece confirmando IP/gateway/DNS recebidos via DHCP.
• 2) Reinicie roteador (limpa cache/local resolver em muitos modelos) e reconecte o dispositivo.
• 3) Teste outro DNS no dispositivo (temporário) para validar se o resolutor atual está com falha.
• 4) Se for rede com repetidor/mesh, confirme que existe um DHCP só, e que ele distribui DNS correto.
• 5) Se for domínio seu, revise TTL, registros e propagação; não faça mudanças em cadeia sem controle.
• 6) Documente: horário, erro, resolutor usado, se falha em IPv4/IPv6. Isso acelera correção real.

12) Plano de ação (7 dias) para estabilizar e evitar recorrência

• Dia 1: mapear onde falha (Wi-Fi/cabo, só alguns dispositivos, só alguns horários).
• Dia 2: padronizar DHCP (um servidor) e garantir distribuição consistente de DNS.
• Dia 3: definir estratégia: DNS do provedor vs público, e se DoH/DoT será usado (consciente).
• Dia 4: revisar IPv6: se tiver AAAA e IPv6 ativo, garanta que a rota IPv6 está estável.
• Dia 5: otimizar cache/TTL para domínios próprios (reduzir TTL antes de migrações, evitar TTL absurdo).
• Dia 6: se usar DNSSEC, revisar cadeia e automação de rotação (evitar expiração).
• Dia 7: checklist final + documentação: quais DNS, onde configurado (roteador/dispositivo), e plano de rollback.

13) Boas práticas (DNS “redondo” para casa, empresa e projetos)

• Padronize: escolha um DNS primário e secundário confiáveis.
• Evite misturar aleatoriamente DNS no roteador e DNS manual em dispositivos sem motivo.
• Planeje migrações: reduza TTL com antecedência.
• Use cache com consciência: cache é bom, mas TTL precisa ser coerente.
• Se usar DoH/DoT, faça sabendo o impacto em redes com controles internos.
• Monitore: quedas rápidas e intermitentes geralmente apontam para link/latência, não “DNS ruim” puro.

14) Checklist final (DNS saudável e previsível)

• ✅ DHCP entrega DNS correto e consistente
• ✅ Existem pelo menos 2 resolutores configurados (primário/secundário)
• ✅ Testes com nslookup/dig retornam rápido e sem SERVFAIL
• ✅ TTL planejado (sem valores absurdos em domínios que mudam)
• ✅ IPv6 revisado (AAAA ok e rota ok)
• ✅ Se houver DNSSEC, cadeia válida e rotação funcionando
• ✅ Se usar DoH/DoT, impacto avaliado (principalmente em redes internas)

Perguntas Frequentes (FAQ)

Saiba mais em: Sobre o autor