O que é DNS? A agenda telefônica da internet

Toda vez que você digita um endereço como schematize.com no navegador, acontece nos bastidores uma das operações mais frequentes e invisíveis da internet: traduzir esse nome em um endereço numérico que os computadores entendem. Esse trabalho é do DNS. Neste artigo você vai entender o que é o DNS, como ele funciona passo a passo, quais são os tipos de registro, como usar ferramentas como dig e nslookup para investigar problemas e quais são os erros mais comuns que derrubam aplicações em produção.

A agenda telefônica da internet

Computadores não se encontram por nomes, e sim por endereços IP — sequências numéricas como 192.0.2.10 (IPv4) ou 2001:db8::1 (IPv6). O problema é que ninguém quer decorar números assim. Nós preferimos nomes legíveis, como google.com ou github.com.

O DNS (Domain Name System) é o sistema que faz essa ponte. A analogia clássica é a de uma agenda telefônica: você sabe o nome da pessoa (o domínio) e o DNS te devolve o número (o IP). A diferença é que essa "agenda" é gigantesca, distribuída pelo mundo inteiro e atualizada o tempo todo.

Vale notar a diferença entre os dois protocolos de endereço. O IPv4 usa 32 bits, o que dá pouco menos de 4,3 bilhões de endereços — um número que já se esgotou diante do tamanho da internet moderna. O IPv6 usa 128 bits e oferece uma quantidade de endereços astronômica, suficiente para décadas de crescimento. O DNS lida com os dois de forma transparente: um mesmo nome pode ter registros para IPv4 e IPv6 ao mesmo tempo, e o cliente escolhe qual usar.

Sem o DNS, a web como conhecemos seria impraticável. Ele é a camada que permite que tudo o mais — desde uma simples requisição HTTP até o acesso a uma API — comece a partir de um nome amigável. Como desenvolvedor, você vai esbarrar no DNS com muito mais frequência do que imagina: ao configurar um domínio, ao apontar um subdomínio para um serviço, ao depurar um deploy que "não sobe" ou ao investigar por que e-mails da sua aplicação caem no spam.

A hierarquia de nomes

Um domínio é lido da direita para a esquerda, em uma hierarquia de níveis. Veja loja.exemplo.com.br:

Essa estrutura em árvore permite distribuir a responsabilidade. Ninguém precisa conhecer todos os domínios do mundo: cada nível sabe apenas para quem perguntar no nível abaixo. É essa delegação que torna o sistema escalável.

Há um detalhe que confunde muita gente: aquele ponto final (exemplo.com.) não é decoração. Em arquivos de zona e em consultas, ele indica um nome totalmente qualificado (FQDN, Fully Qualified Domain Name), que parte da raiz. Um nome sem o ponto final pode ser tratado como relativo e ter um sufixo de busca anexado automaticamente. Esquecer o ponto final no lugar errado é uma das causas clássicas de registros DNS que "não funcionam".

Outro conceito importante é o de zona. Uma zona é a porção da árvore DNS sob responsabilidade administrativa de uma entidade. Quando você registra exemplo.com, recebe controle sobre aquela zona e pode criar quantos registros e subdomínios quiser dentro dela, sem pedir permissão a ninguém. A delegação acontece quando você aponta um subdomínio (digamos, interno.exemplo.com) para outros servidores autoritativos, criando uma nova zona separada.

O passo a passo de uma resolução

Quando você acessa um site pela primeira vez, várias peças entram em ação. O processo, chamado de resolução de nomes, costuma seguir estas etapas:

Tudo isso costuma acontecer em poucos milissegundos. E, para que não se repita a cada acesso, entra em cena o cache.

Recursivo versus autoritativo

Essa distinção é fundamental e merece um destaque. Existem dois papéis muito diferentes no DNS:

Quando você usa 8.8.8.8 (Google) ou 1.1.1.1 (Cloudflare), está usando resolvers recursivos públicos. Eles atendem bilhões de consultas e mantêm caches enormes, o que torna a resolução muito rápida para nomes populares.

Os 13 conjuntos de servidores raiz (de a.root-servers.net a m.root-servers.net) são o ponto de partida de toda resolução que não está em cache. Não são apenas 13 máquinas: cada um é replicado por anycast em centenas de instâncias pelo mundo, justamente para resistir a falhas e ataques.

O papel do cache e do TTL

Resolver um nome do zero toda vez seria lento e sobrecarregaria os servidores. Por isso, respostas DNS são armazenadas em cache em vários pontos: no seu navegador, no sistema operacional e no resolver recursivo.

Cada registro DNS carrega um TTL (Time To Live), o tempo em segundos que ele pode ficar guardado antes de ser consultado de novo. Um TTL de 3600 significa "confie nesta resposta por uma hora".

O TTL tem um efeito prático importante:

Por isso, quando você muda o servidor de um site, costuma ouvir que "o DNS está propagando": os caches espalhados pelo mundo ainda estão respeitando o TTL antigo.

A verdade sobre "propagação"

Existe um mito persistente de que o DNS "leva 24 a 48 horas para propagar". Na prática, não existe um processo de propagação ativo: os servidores autoritativos não empurram mudanças para o mundo. O que acontece é simplesmente que os caches existentes precisam expirar antes de buscar o novo valor. Se o TTL anterior era de 24 horas, um resolver que cacheou o valor antigo o manterá por até 24 horas. Se era de 5 minutos, em 5 minutos ele já busca de novo.

A consequência prática para migrações é uma receita de ouro:

O erro clássico é trocar o IP de produção com o TTL ainda alto: parte dos usuários continua batendo no servidor antigo por horas, gerando aquela sensação de "funciona para mim, mas não para o cliente".

Os principais tipos de registro

O DNS não guarda apenas endereços IP. Ele armazena vários tipos de registro, cada um com um papel:

Um arquivo de zona simplificado pode parecer com isto:

exemplo.com.      3600  IN  A      192.0.2.10
www.exemplo.com.  3600  IN  CNAME  exemplo.com.
exemplo.com.      3600  IN  MX  10  mail.exemplo.com.
exemplo.com.      3600  IN  TXT    "v=spf1 include:_spf.exemplo.com ~all"

Uma zona mais completa, com SOA, NS e os tipos adicionais, ficaria assim:

$ORIGIN exemplo.com.
$TTL 3600
exemplo.com.    IN  SOA  ns1.exemplo.com. admin.exemplo.com. (
                          2026062501 ; serial (data + contador)
                          7200       ; refresh
                          3600       ; retry
                          1209600    ; expire
                          300 )      ; minimum / negative TTL
exemplo.com.        IN  NS     ns1.exemplo.com.
exemplo.com.        IN  NS     ns2.exemplo.com.
exemplo.com.        IN  A      192.0.2.10
exemplo.com.        IN  AAAA   2001:db8::10
exemplo.com.        IN  CAA    0 issue "letsencrypt.org"
_sip._tcp.exemplo.com.  IN  SRV  10 5 5060 sip.exemplo.com.

Note o campo serial no SOA (2026062501). Sempre que você altera a zona, deve incrementar esse número — é assim que os servidores secundários sabem que há uma versão nova para copiar. Esquecer de incrementar o serial é um erro comum que faz mudanças "sumirem" em configurações com servidores primário e secundário.

TXT, SPF, DKIM e DMARC: a saúde do seu e-mail

Os registros TXT ganharam um papel central na entregabilidade de e-mail. Três deles trabalham juntos:

Se a sua aplicação envia e-mails transacionais (confirmação de cadastro, recuperação de senha) e eles caem no spam, o primeiro lugar para investigar é quase sempre esse trio de registros TXT.

Investigando o DNS com a linha de comando

Como desenvolvedor, você não precisa adivinhar o que o DNS está respondendo — pode perguntar diretamente. As três ferramentas mais úteis são dig, nslookup e host.

O dig é o mais detalhado e o favorito para depuração:

# Consulta o registro A de exemplo.com
dig exemplo.com A

# Versão enxuta, mostrando só a resposta
dig +short exemplo.com

# Consulta um tipo específico (MX, TXT, NS, AAAA...)
dig exemplo.com MX
dig exemplo.com TXT

# Pergunta diretamente a um resolver específico (ignora seu cache local)
dig @1.1.1.1 exemplo.com

# Mostra todo o caminho da resolução, da raiz ao autoritativo
dig +trace exemplo.com

A saída do dig traz seções úteis. Na ANSWER SECTION você vê o registro e seu TTL restante no cache:

;; ANSWER SECTION:
exemplo.com.        286    IN    A    192.0.2.10

Aqui o 286 indica que faltam 286 segundos para esse cache expirar — um TTL configurado em 300 consultado há 14 segundos. Observar esse número cair a cada consulta é uma ótima forma de confirmar que você está vendo dados em cache, não a fonte autoritativa.

O nslookup existe em praticamente todos os sistemas, inclusive no Windows:

nslookup exemplo.com
nslookup -type=MX exemplo.com
nslookup exemplo.com 8.8.8.8

E o host é o mais sucinto para uma checagem rápida:

host exemplo.com
host -t TXT exemplo.com

Para confirmar uma migração, uma tática prática é consultar vários resolvers públicos em sequência (@1.1.1.1, @8.8.8.8, @9.9.9.9) e ver se todos já devolvem o novo IP. Se um ainda devolve o antigo, é o cache dele que ainda não expirou — não há nada de errado com a sua configuração.

DNS e desempenho: a conexão com a CDN

O DNS também é uma ferramenta de desempenho e roteamento. Provedores podem responder à mesma consulta com IPs diferentes dependendo de onde você está no mundo, direcionando você ao servidor mais próximo.

É exatamente assim que uma CDN entrega conteúdo rápido: o DNS aponta o usuário para o ponto de presença geograficamente mais perto. Ou seja, antes mesmo de o primeiro byte do site chegar, o DNS já influenciou de onde ele virá.

Essa técnica costuma combinar roteamento por GeoDNS e anycast, no qual um mesmo IP é anunciado em vários pontos do planeta e a rede entrega o tráfego ao mais próximo. O resultado é uma latência menor já na primeira conexão. Por isso muitos serviços de CDN pedem que você aponte seu domínio para eles via CNAME em vez de um A fixo: assim eles controlam dinamicamente para qual IP o usuário será direcionado.

A armadilha do CNAME no apex

Isso leva a um dos problemas mais frustrantes do dia a dia: o CNAME no apex (o domínio "nu", exemplo.com, sem www). As regras do DNS proíbem ter um CNAME coexistindo com outros registros no mesmo nome — e o apex obrigatoriamente já tem registros SOA e NS. Resultado: você não pode criar um CNAME direto em exemplo.com.

Isso conflita com CDNs e plataformas de hospedagem que pedem um CNAME. As soluções comuns são:

DNS e segurança

Por ser tão central, o DNS é alvo de ataques e ponto de atenção em segurança. Alguns aspectos merecem destaque.

Primeiro, o DNS por si só não criptografa as consultas tradicionais, o que permite espionagem ou manipulação no caminho. Tecnologias como DNS over HTTPS (DoH) e DNS over TLS (DoT) surgiram para proteger essas consultas, aproveitando o TLS, o mesmo mecanismo que torna o HTTPS seguro.

Segundo, o DNS é parte essencial da emissão e validação de certificados. Quando um navegador estabelece uma conexão segura, ele depende de que o nome resolvido corresponda ao certificado apresentado pelo servidor. O TLS 1.3, especificado em Rescorla (2018), define o protocolo moderno que protege essa conexão depois que o DNS faz a sua parte. É também por DNS — via registros TXT ou CNAME temporários, e via o registro CAA mencionado antes — que autoridades como a Let's Encrypt validam que você controla o domínio antes de emitir um certificado.

Terceiro, há o DNSSEC (DNS Security Extensions). Como o DNS comum não verifica a autenticidade das respostas, um atacante pode tentar injetar respostas falsas (ataque de cache poisoning) e desviar usuários para servidores maliciosos. O DNSSEC adiciona assinaturas criptográficas a cada nível da hierarquia, criando uma cadeia de confiança da raiz até a sua zona. Com ele, um resolver consegue verificar que a resposta realmente veio do servidor autoritativo legítimo e não foi adulterada. O DNSSEC não criptografa as consultas (isso é papel do DoH/DoT) — ele garante integridade e autenticidade, não confidencialidade.

Erros comuns que derrubam aplicações

Reunindo as armadilhas espalhadas pelo artigo, eis um checklist do que mais causa dor de cabeça:

Onde o DNS se encaixa no quadro maior

Vale lembrar que o DNS é apenas o primeiro passo. Depois que ele entrega o IP, o navegador abre uma conexão e começa a falar a língua da web — o protocolo HTTP, especificado originalmente em documentos como o de Fielding et al. (1999). O DNS resolve o "onde"; o HTTP cuida do "como" conversar.

A sequência completa de um acesso típico é: resolução DNS (descobrir o IP) → handshake TCP (estabelecer a conexão) → handshake TLS (negociar a criptografia) → requisição HTTP (pedir o conteúdo). O DNS é o gatilho de tudo: se ele falha ou está lento, nada do resto acontece. Por isso, quando uma página "não carrega", checar a resolução do nome com dig costuma ser o primeiro e mais revelador passo de diagnóstico.

Entender essa sequência — resolver o nome, abrir a conexão, trocar mensagens — é a base para compreender praticamente qualquer comportamento de rede que você vá depurar como desenvolvedor.

Perguntas frequentes

O DNS é o mesmo que o registro de domínio? Não. O registro é o ato de reservar um nome (exemplo.com) junto a um registrador. O DNS é o serviço que, depois disso, traduz esse nome em endereços. Você pode registrar o domínio em um lugar e hospedar o DNS em outro.

Quanto tempo realmente leva para uma mudança "valer"? Depende exclusivamente do TTL do registro antigo. Se ele estava em 5 minutos, vale em minutos; se estava em 24 horas, alguns caches só atualizam em até 24 horas. Não há um relógio mágico de 48 horas.

Por que o site abre para mim mas não para outra pessoa? Quase sempre é cache de DNS divergente: você já tem o valor novo, mas o resolver da outra pessoa ainda guarda o antigo. Confirme consultando diferentes resolvers públicos com dig @1.1.1.1 e dig @8.8.8.8.

Trocar o resolver para 1.1.1.1 ou 8.8.8.8 deixa a internet mais rápida? Pode ajudar marginalmente na latência da resolução e na privacidade, especialmente se o resolver do seu provedor for lento ou interceptar consultas. Mas não muda a largura de banda nem a velocidade do conteúdo em si.

Preciso mesmo de IPv6 (registro AAAA)? Cada vez mais, sim. Operadoras móveis e provedores já oferecem conectividade só-IPv6 em muitos cenários. Publicar um AAAA garante que esses usuários cheguem ao seu serviço sem depender de gambiarras de tradução.

Conclusão

O DNS é o tradutor silencioso que transforma nomes legíveis em endereços IP, organizando a internet em uma hierarquia distribuída e escalável. Com cache e TTL, ele equilibra velocidade e atualização; com seus diversos tipos de registro — de A e AAAA a MX, TXT, SRV, CAA e SOA —, sustenta sites, e-mails, serviços e segurança. Dominar ferramentas como dig e nslookup, conhecer as armadilhas (TTL alto, CNAME no apex, ponto final esquecido) e entender a diferença entre resolver recursivo e autoritativo transforma o DNS de uma caixa-preta misteriosa em uma camada que você depura com confiança. E, junto de CDNs, do DNSSEC e do TLS descrito por Rescorla (2018), ele garante que você chegue rápido e com segurança ao destino certo. Toda vez que você acessa um site, ele já trabalhou — e agora você sabe exatamente como.

Referências