DNS

O que é

Computadores se encontram na rede por endereços IP, como 203.0.113.10. Pessoas e sistemas usam nomes, como api.loja.com.br. O DNS é o serviço que traduz o nome em endereço.

Ele funciona como uma base de dados distribuída pelo mundo inteiro, sem um servidor central que conheça todos os nomes. Cada pedaço da hierarquia sabe apenas quem é o responsável pelo pedaço seguinte. Quase toda conexão que o seu sistema abre começa por uma consulta DNS, e por isso uma falha de DNS costuma parecer uma falha de tudo ao mesmo tempo.

A hierarquia dos nomes

Um nome de domínio é lido da direita para a esquerda, do mais geral para o mais específico:

api.loja.com.br.
 │    │   │  │ └─ raiz (o ponto final, quase sempre omitido)
 │    │   │  └─── domínio de topo: br
 │    │   └────── com.br
 │    └────────── loja.com.br, o domínio que você registrou
 └─────────────── api, um nome que você criou dentro dele

Cada nível é administrado por uma organização diferente, que delega o nível abaixo:

Os servidores do último nível são os servidores autoritativos do seu domínio. Só eles têm a resposta original. Todo o resto do sistema guarda cópias temporárias.

O caminho de uma consulta

Quando o seu código pede o endereço de api.loja.com.br, a consulta passa por dois tipos de servidor.

O resolvedor recursivo é quem faz o trabalho de busca. Ele pertence ao provedor de internet, à nuvem onde o seu servidor roda ou a um serviço público como 1.1.1.1 e 8.8.8.8. O seu sistema operacional só conhece o endereço dele.

1. O programa pede o endereço ao sistema operacional.
2. O sistema operacional consulta o próprio cache e, sem resposta, pergunta ao resolvedor recursivo.
3. O resolvedor pergunta a um servidor raiz: "quem cuida de br?"
4. Pergunta ao servidor de br: "quem cuida de loja.com.br?"
5. Pergunta ao servidor autoritativo de loja.com.br: "qual o endereço de api?"
6. O resolvedor devolve a resposta e a guarda em cache.

As etapas 3 a 5 só acontecem quando o resolvedor não tem a resposta guardada. Na prática, a grande maioria das consultas é respondida do cache em poucos milissegundos.

Tipos de registro

Um servidor autoritativo guarda registros. Cada registro associa um nome a um valor de um tipo específico.

O CNAME tem uma restrição que causa confusão: um nome com CNAME não pode ter nenhum outro registro. Como a raiz do seu domínio (loja.com.br, sem prefixo) já tem obrigatoriamente registros NS, ela não aceita CNAME. O nível Soluções mostra como os provedores contornam isso.

TTL: por quanto tempo a resposta vale

Todo registro tem um TTL (tempo de vida), em segundos. Ele diz a quem recebeu a resposta por quanto tempo pode reutilizá-la sem perguntar de novo.

A resposta fica guardada em várias camadas ao mesmo tempo:

• no resolvedor recursivo, compartilhada por todos os clientes dele;
• no sistema operacional da máquina;
• às vezes dentro do próprio programa, como na máquina virtual do Java;
• no navegador.

As respostas negativas também são guardadas. Se alguém consultar um nome antes de você criá-lo, a resposta "não existe" fica em cache por um tempo definido na configuração do domínio. É por isso que um registro recém-criado às vezes não aparece para quem testou cedo demais.

Onde o DNS aparece no backend

O DNS não é assunto só de quem configura domínios. Ele está em quatro lugares do dia a dia:

• Deploy e migração: trocar o servidor de uma aplicação é, muitas vezes, trocar um registro DNS e esperar os caches vencerem.
• Comunicação entre serviços: em Docker e Kubernetes, um serviço encontra o outro por nome (http://pagamentos:8080), e esse nome é resolvido por um DNS interno.
• Distribuição de carga e failover: um nome pode devolver vários endereços, ou endereços diferentes conforme a região e a saúde dos servidores.
• Verificação de posse: certificados TLS e serviços de e-mail pedem que você crie um registro TXT para provar que controla o domínio.

Por que isso importa quando a IA escreve o código

Um assistente escreve fetch("https://api.parceiro.com/...") sem pensar no que acontece antes da conexão. Os problemas de DNS aparecem em produção e raramente no teste local:

• O programa resolve o nome uma vez, mantém a conexão aberta por dias e continua falando com um endereço que já foi desligado.
• O resolvedor fica lento e todas as chamadas externas ficam lentas juntas, sem nenhum erro claro no log.
• O tempo limite do pedido não cobre a etapa de resolução, e a chamada trava antes mesmo de conectar.
• A migração é planejada para as 22h com um TTL de 24 horas, e metade dos usuários continua no servidor antigo no dia seguinte.

Quem entende o ciclo de consulta e cache reconhece esses sintomas. O próximo nível compara as formas de hospedar o DNS, de escolher o TTL e de direcionar o tráfego.