Como o DNS funciona de verdade, do domínio ao IP

Já falei aqui sobre configurar HTTPS num domínio próprio com GitHub Pages, sobre deliverability de e-mail e sobre deploy, e em todos esses posts o DNS aparece de passagem, como um passo necessário, sem nunca explicar o que realmente acontece quando você digita um endereço e aquilo vira um site carregando na tela.

O problema que o DNS resolve

Todo servidor na internet é identificado por um endereço IP, uma sequência de números como 192.0.2.10. Decorar isso pra cada site que você visita seria inviável, então o DNS (Domain Name System) existe como uma espécie de agenda de contatos gigante e distribuída, traduzindo um nome fácil de lembrar, como meusite.com, pro endereço IP real do servidor que hospeda aquele site.

A cadeia de resolução, passo a passo

Quando o navegador precisa descobrir o IP de meusite.com, ele não pergunta direto pro dono do domínio. Existe uma cadeia hierárquica de servidores sendo consultada, cada um sabendo só a parte que é responsabilidade dele:

1. Servidor raiz. O ponto de partida de qualquer consulta DNS. Ele não sabe o IP de meusite.com, mas sabe pra qual servidor perguntar sobre domínios terminados em .com.

2. Servidor do TLD (top-level domain). Responsável por toda a extensão .com, .br, .dev, e assim por diante. Ele não sabe o IP exato de meusite.com também, mas sabe qual servidor é responsável, especificamente, por esse domínio.

3. Servidor autoritativo. Esse sim conhece a resposta de verdade: o IP exato associado a meusite.com, configurado por quem administra aquele domínio (geralmente através do painel do provedor de hospedagem ou de um serviço de DNS dedicado, como Cloudflare).

navegador → servidor raiz → servidor .com → servidor autoritativo → IP real

Essa cadeia inteira acontece em milissegundos, e na prática a maior parte das consultas nem percorre todo esse caminho a cada vez, porque existe cache em várias camadas: no seu próprio sistema operacional, no provedor de internet, e nos servidores intermediários, guardando a resposta por um tempo pra não precisar repetir essa cadeia completa em toda requisição nova.

Os tipos de registro mais comuns

Dentro do servidor autoritativo, a configuração de um domínio é feita através de registros, cada um com um propósito específico:

Registro A aponta um domínio direto pra um endereço IP:

meusite.com.    A    192.0.2.10

Registro CNAME aponta um domínio (geralmente um subdomínio) pra outro nome de domínio, em vez de um IP direto, útil quando o IP do destino pode mudar sem você precisar atualizar nada:

www.meusite.com.    CNAME    meusite.com.

Registro MX define qual servidor é responsável por receber e-mail daquele domínio, e é essa configuração que torna possível um e-mail contato@meusite.com funcionar de verdade, mesmo que o site em si esteja hospedado em outro lugar:

meusite.com.    MX    10 mx.provedoremail.com.

Registro TXT guarda texto livre, usado com frequência pra verificação de propriedade do domínio ou pra configuração de segurança de e-mail, como aquele DKIM que já mencionei no post de envio de e-mail sem cair no spam:

meusite.com.    TXT    "v=spf1 include:_spf.provedoremail.com ~all"

Por que uma mudança de DNS demora a propagar

Um detalhe que confunde bastante gente é mudar um registro DNS e o efeito não aparecer na hora, pra todo mundo ao mesmo tempo. Isso acontece por causa do cache mencionado antes: cada registro tem um valor de TTL (time to live), que diz por quanto tempo aquela resposta pode ficar guardada em cache antes de ser consultada de novo.

meusite.com.    A    192.0.2.10    3600

Esse 3600 significa que qualquer servidor que já consultou esse registro pode continuar usando esse valor guardado por até uma hora, sem buscar de novo, mesmo que o valor real já tenha mudado nesse meio tempo. É por isso que, depois de trocar o IP de um domínio, algumas pessoas já veem o site novo e outras ainda veem o antigo por um tempo, dependendo de quando cada servidor intermediário fez a última consulta e por quanto tempo ele guarda isso em cache.

Uma prática comum antes de uma migração planejada é reduzir o TTL com antecedência, fazendo com que o cache expire mais rápido, e só depois disso fazer a mudança real de IP, encurtando a janela de inconsistência entre quem já vê o valor novo e quem ainda vê o antigo.

Fechando

DNS não é só "a parte que configura o domínio", é uma cadeia de consulta inteira, distribuída, que traduz um nome legível num IP real, com cache em cada camada pra não sobrecarregar o sistema inteiro com consulta repetida. Entender essa cadeia, e o papel do TTL nela, é o que explica por que uma mudança de DNS nunca é instantânea pra todo mundo ao mesmo tempo, e ajuda a planejar uma migração sem surpresa.