Fundamentos de DNS que Todo Desenvolvedor Deveria Saber

Jan 26, 2026 · 4 min read

Fundamentos de DNS que Todo Desenvolvedor Deveria Saber

Você fez o deploy da sua aplicação, mas os usuários relatam que ela está inacessível. Seu primeiro instinto pode ser verificar o servidor, mas o verdadeiro culpado geralmente é o DNS. Entender os fundamentos de DNS não é opcional—é essencial para debugar problemas em produção e compreender como suas aplicações web realmente alcançam os usuários.

Este artigo aborda o fluxo de resolução DNS, tipos comuns de registros, comportamento de cache e desenvolvimentos modernos de DNS que afetam performance e segurança.

Principais Pontos

A resolução DNS envolve três camadas: stub resolvers, recursive resolvers e authoritative nameservers—falhas podem ocorrer em qualquer ponto
Valores de TTL determinam o tempo de propagação; diminua-os antes de migrações, não durante
Registros HTTPS (SVCB) fornecem dicas de conexão para conexões de navegador mais rápidas e seguras
DNSSEC autentica registros enquanto DoH/DoT/DoQ criptografa consultas—eles resolvem problemas diferentes
Use dig ou nslookup para debugar problemas de DNS consultando diferentes resolvers

Como Funciona a Resolução DNS

Quando um navegador precisa se conectar a api.example.com, ele não sabe magicamente o endereço IP. O processo de resolução envolve três camadas:

Stub resolver: O cliente DNS integrado do seu sistema operacional. Ele não resolve nomes por conta própria—encaminha consultas para um recursive resolver configurado e faz cache das respostas localmente.

Recursive resolver: Normalmente operado pelo seu provedor de internet ou um serviço público como Cloudflare (1.1.1.1) ou Google (8.8.8.8). Este servidor faz o trabalho pesado, consultando outros servidores em seu nome.

Authoritative nameservers: A fonte da verdade para os registros DNS de um domínio. O recursive resolver percorre a hierarquia DNS—servidores raiz, depois servidores TLD (.com, .io), depois os servidores autoritativos do domínio—para encontrar a resposta.

Para desenvolvedores, o insight chave é que falhas de DNS podem ocorrer em qualquer camada. Um stub resolver mal configurado, um recursive resolver inacessível ou registros autoritativos desatualizados podem quebrar sua aplicação.

Tipos Comuns de Registros DNS

Você encontrará esses registros regularmente:

A / AAAA: Mapeiam um hostname para um endereço IPv4 ou IPv6
CNAME: Cria um alias de um hostname para outro (não pode ser usado no zone apex—example.com em si requer um registro A ou AAAA)
MX: Especifica servidores de email para o domínio
TXT: Armazena texto arbitrário, comumente usado para verificação de domínio e autenticação de email (SPF, DKIM)
NS: Delega uma zona para nameservers específicos

Entender esses tipos ajuda ao configurar CDNs, serviços de email ou debugar por que um subdomínio não está resolvendo.

Cache DNS e TTL

Cache DNS e TTL (Time To Live) impactam diretamente sua estratégia de deploy. Cada registro DNS inclui um valor de TTL em segundos. Uma vez que um resolver faz cache de um registro, ele não consultará novamente até que o TTL expire.

Implicações práticas:

Um TTL de 3600 segundos (1 hora) significa que mudanças de DNS levam até uma hora para propagar
Antes de migrações, diminua os TTLs com antecedência—não durante a mudança
Navegadores e sistemas operacionais mantêm seus próprios caches, adicionando outra camada

O mito de que “propagação DNS leva 24-48 horas” é enganoso. O tempo de propagação depende do valor de TTL anterior. Se seu TTL antigo era 86400 segundos (24 horas), esse é seu tempo de espera no pior caso.

DNS Moderno: Registros HTTPS e Transporte Criptografado

O DNS evoluiu significativamente nos últimos anos. Dois desenvolvimentos são mais importantes para desenvolvedores web.

O Registro DNS HTTPS (SVCB)

O registro HTTPS (um tipo específico de registro SVCB) fornece dicas de conexão antes mesmo do navegador contatar seu servidor. Ele pode anunciar:

Suporte a HTTP/3 e QUIC
Portas alternativas
Chaves de Encrypted Client Hello (ECH)

Isso permite que navegadores estabeleçam conexões mais rápidas e seguras. No entanto, o suporte a registros HTTPS ainda não é universal—nem todos os provedores DNS o suportam, e alguns resolvers não consultam por ele.

Nota: Registros HTTPS oferecem capacidades limitadas de apex-aliasing, mas não são uma solução completa de CNAME-at-apex.

DNS over HTTPS (DoH) e DNS Criptografado

Consultas DNS tradicionais trafegam em texto plano pela porta UDP 53. DNS over HTTPS (DoH), DNS over TLS (DoT) e DNS over QUIC (DoQ) criptografam essas consultas, prevenindo espionagem e manipulação.

DNS criptografado agora está amplamente implantado—Firefox e Chrome usam DoH por padrão em muitas configurações—mas não é universal. Redes corporativas e alguns provedores de internet ainda interceptam ou bloqueiam DNS criptografado.

DNSSEC vs Criptografia: Conheça a Diferença

Uma confusão comum: DNSSEC não é criptografia.

DNSSEC fornece autenticação. Ele assina criptograficamente registros DNS para que resolvers possam verificar que as respostas não foram adulteradas. Ele não oculta suas consultas.

DNS Criptografado (DoH/DoT/DoQ) fornece privacidade. Ele criptografa a camada de transporte para que observadores não possam ver quais domínios você está consultando.

Eles resolvem problemas diferentes e podem ser usados juntos.

Como Falhas de DNS Aparecem nas Suas Aplicações

Quando o DNS falha, você normalmente verá:

Erros NXDOMAIN (domínio não existe)
Timeouts de conexão (resolver inacessível)
Respostas SERVFAIL (problemas no servidor upstream)

Em navegadores, esses aparecem como “DNS_PROBE_FINISHED_NXDOMAIN” ou erros similares. Em Node.js ou outros runtimes, você receberá exceções ENOTFOUND ou equivalentes.

Use dig ou nslookup para debugar. Consulte diferentes resolvers para isolar se o problema é cache local, seu resolver ou os servidores autoritativos.

Conclusão

O DNS fica entre seus usuários e seus servidores. Entender o fluxo de resolução, comportamento de TTL e protocolos modernos como registros HTTPS e DoH ajuda você a fazer deploy de forma mais confiável e debugar mais rápido. Quando algo quebra, DNS deveria ser um dos seus primeiros suspeitos—não o último.

Perguntas Frequentes

Use o comando dig no seu terminal, como dig example.com A para verificar registros A ou dig example.com ANY para ver todos os registros. Você também pode especificar um resolver como dig @8.8.8.8 example.com para consultar o DNS do Google diretamente. No Windows, use nslookup example.com.

Mudanças de DNS parecem atrasadas porque resolvers fazem cache de registros baseados no valor de TTL. Se seu TTL anterior era 3600 segundos, resolvers não verificarão por atualizações até que essa hora passe. Para acelerar mudanças futuras, diminua seu TTL bem antes de fazer atualizações, depois restaure-o.

Um registro A mapeia um hostname diretamente para um endereço IP. Um CNAME cria um alias apontando um hostname para outro, que então resolve para um IP. CNAMEs são úteis para subdomínios apontando para serviços externos, mas não podem ser usados no zone apex onde seu domínio raiz requer um registro A ou AAAA.

DoH criptografa consultas DNS, prevenindo que observadores de rede vejam quais domínios você resolve. Para privacidade do usuário final, é benéfico. No entanto, para aplicações de servidor, DNS tradicional geralmente é suficiente já que sua infraestrutura já é conhecida. Considere DoH quando privacidade de intermediários de rede importar para seu caso de uso.

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.