DNS
Como um nome de domínio vira um endereço IP, quem responde em cada etapa e por que uma mudança de DNS demora a valer para todos.
O protocolo é um só. As decisões estão em quem hospeda os seus registros, quanto tempo cada resposta pode ficar em cache, como o nome distribui o tráfego e como os serviços internos se encontram.
Onde hospedar o DNS do domínio
Os servidores autoritativos do seu domínio podem ficar em três lugares.
| Opção | Como funciona | Vantagens | Custos e limites |
|---|---|---|---|
| DNS da entidade de registro | Os registros ficam no painel de onde você comprou o domínio | Sem custo extra e sem configuração | Poucos recursos, sem API ou com API limitada, sem roteamento avançado |
| DNS gerenciado (Cloudflare, Route 53, Cloud DNS) | Você aponta o domínio para os servidores do provedor | Rede mundial com resposta rápida, API para automação, roteamento por peso, região e saúde | Custo por zona e por consulta em alguns provedores; dependência do provedor |
| Servidores próprios (BIND, PowerDNS, CoreDNS) | Você opera os servidores autoritativos | Controle total; útil para zonas internas | Você responde por disponibilidade, segurança e ataques de volume |
Para um domínio público, o DNS gerenciado é a escolha da grande maioria dos sistemas. Operar servidores autoritativos expostos à internet é um trabalho especializado, e uma queda deles tira do ar tudo o que depende do domínio.
Como escolher o TTL
O TTL é uma troca entre a velocidade de uma mudança e a carga e a latência das consultas.
| TTL baixo (30 a 300 s) | TTL alto (1 a 24 h) | |
|---|---|---|
| Uma mudança vale para todos em | Minutos | Horas ou um dia |
| Consultas ao servidor autoritativo | Muitas | Poucas |
| Latência percebida | Mais consultas sem cache | Quase sempre respondido do cache |
| Se o provedor de DNS cair | O efeito aparece em minutos | Os caches seguram o serviço por mais tempo |
| Indicado para | Endereços que mudam: balanceadores, failover, períodos de migração | Registros estáveis: MX, NS, TXT de verificação |
O procedimento padrão de uma migração combina os dois:
- Dias antes, reduza o TTL do registro para um valor baixo, como 300 segundos.
- Espere o TTL antigo vencer. Só depois disso todos os caches estarão usando o valor baixo.
- Faça a troca do endereço. Em poucos minutos todos apontam para o novo.
- Mantenha o servidor antigo no ar durante esse intervalo.
- Com tudo estável, suba o TTL de novo.
Alguns resolvedores ignoram TTLs muito baixos e impõem um mínimo próprio. Trate o TTL como um limite aproximado e mantenha o endereço antigo funcionando por mais tempo do que a conta indica.
A raiz do domínio: A, CNAME e ALIAS
Serviços de hospedagem, CDNs e balanceadores costumam entregar um nome como destino, e não um endereço IP fixo. Para www.loja.com.br, basta um CNAME. Para a raiz loja.com.br, o CNAME é proibido pelo protocolo.
| Solução | Como funciona | Quando usar |
|---|---|---|
Registro A com IP fixo | Você escreve o endereço do destino | O destino tem IP estável e garantido pelo provedor |
ALIAS, ANAME ou achatamento de CNAME | O provedor de DNS resolve o nome de destino por você e devolve registros A | O destino só oferece um nome. É um recurso do provedor, fora do padrão, e o nome varia entre eles |
Redirecionar a raiz para www | A raiz aponta para um serviço pequeno que responde com redirecionamento HTTP | O provedor de DNS não oferece ALIAS |
Direcionar o tráfego pelo DNS
Um nome pode devolver respostas diferentes conforme a política configurada no provedor.
| Política | O que faz | Uso típico |
|---|---|---|
| Simples | Sempre os mesmos endereços | Um servidor ou um balanceador |
| Vários registros | Devolve uma lista, e o cliente escolhe um | Distribuição básica, sem garantia de equilíbrio |
| Por peso | Divide as respostas em proporções, como 90% e 10% | Liberar uma versão nova para uma parte dos usuários |
| Por latência ou região | Responde com o servidor mais próximo de quem pergunta | Sistemas em mais de uma região |
| Failover | Responde com o endereço reserva quando a verificação de saúde do principal falha | Recuperação automática |
Descoberta de serviços dentro da rede
Entre serviços internos, o problema é o mesmo em outra escala: os endereços mudam a cada deploy.
| Abordagem | Como funciona | Vantagens | Limites |
|---|---|---|---|
| DNS interno (Docker, Kubernetes, zonas privadas da nuvem) | Cada serviço ganha um nome estável, como pagamentos.vendas.svc.cluster.local, que aponta para um endereço virtual ou para as instâncias | Funciona com qualquer linguagem e biblioteca, sem código extra | Sujeito a cache; um cliente com conexões antigas não percebe a mudança |
| Registro de serviços (Consul, Eureka) | As instâncias se registram, e os clientes consultam a lista atualizada | Reage rápido a mudanças e traz metadados e saúde | Exige biblioteca ou agente em cada serviço |
| Service mesh | Um proxy ao lado de cada serviço recebe a lista de destinos e roteia | O código só conhece um nome; novas tentativas e mTLS ficam fora da aplicação | Mais uma camada para operar |
No Kubernetes, o nome de um serviço aponta por padrão para um endereço virtual estável, e a troca das instâncias acontece atrás dele. Isso evita a maior parte dos problemas de cache, porque o endereço resolvido não muda.
Resumo da decisão
- Hospedagem: DNS gerenciado com API, com os registros versionados.
- TTL: baixo para o que muda, alto para o que é estável, e reduzido com antecedência antes de qualquer migração.
- Raiz do domínio:
ALIASou equivalente quando o destino é um nome. - Tráfego: DNS para escolher a região ou o balanceador; balanceador para distribuir os pedidos.
- Serviços internos: DNS interno, com atenção às conexões de longa duração nos clientes.
O próximo nível mostra como consultar o DNS pela linha de comando e pelo código, e como cada linguagem trata o cache.
Prompts para aprofundar
Ao abrir no ChatGPT ou no Claude, o prompt é enviado ao serviço escolhido pela URL e também fica copiado na sua área de transferência.
Escolher onde hospedar o DNS
Preciso decidir onde hospedar o DNS do meu domínio e quero entender os critérios da escolha. Comece fazendo estas perguntas, uma por vez, e espere as respostas: - Onde o domínio está registrado hoje e onde os registros são gerenciados? - A aplicação roda em uma região ou em várias? Em qual provedor? - A equipe usa infraestrutura como código? - Qual seria o impacto de uma hora de indisponibilidade do DNS? Com base nas respostas, compare para o meu caso o DNS da entidade de registro, um DNS gerenciado (como Cloudflare, Route 53 ou Cloud DNS) e servidores autoritativos próprios. Para cada opção, fale de disponibilidade, recursos de roteamento, automação por API, custo e risco operacional. Explique também como migrar de um provedor de DNS para outro sem indisponibilidade, incluindo o papel dos registros NS e dos TTLs deles. Termine com uma recomendação objetiva e os riscos que ela deixa em aberto.
Planejar uma migração sem indisponibilidade
Vou trocar o endereço para o qual um nome de domínio aponta (mudança de servidor, de provedor ou de balanceador) e quero um plano que não cause indisponibilidade. Pergunte primeiro: qual registro vai mudar, qual é o TTL atual, quando a troca precisa acontecer e se o servidor antigo pode continuar no ar por um tempo. Depois monte comigo um plano com linha do tempo, explicando o motivo de cada passo: 1. Quando e para quanto reduzir o TTL, e quanto tempo esperar antes da troca. 2. Como conferir com o dig que o TTL novo já está valendo nos principais resolvedores. 3. O momento da troca e como verificar o resultado no servidor autoritativo e nos resolvedores públicos. 4. Por quanto tempo manter o servidor antigo no ar, considerando resolvedores que ignoram TTLs baixos e aplicações com conexões de longa duração. 5. O plano de volta, caso algo dê errado. 6. Quando restaurar o TTL original. Aponte os erros mais comuns nesse tipo de migração e como cada um aparece para o usuário final.
DNS, balanceador ou os dois
Quero entender até onde o DNS serve para distribuir tráfego e onde começa o papel do balanceador de carga. Explique as políticas de roteamento por DNS: simples, vários registros, por peso, por latência ou região, e failover com verificação de saúde. Para cada uma, diga o problema que resolve e dê um exemplo de uso. Depois explique, com exemplos numéricos, por que o DNS distribui consultas e não pedidos, e as três consequências disso: distribuição desigual por causa do cache dos grandes resolvedores, demora para retirar um servidor com defeito e desconhecimento da carga de cada servidor. Em seguida, descreva três arquiteturas e pergunte, para cada uma, se eu usaria DNS, balanceador ou os dois, e como: 1. Uma API com quatro servidores em um único data center. 2. Um sistema em duas regiões, em que cada usuário deve ir para a mais próxima. 3. A liberação de uma versão nova para 5% dos usuários. Corrija as minhas respostas e apresente o desenho recomendado para cada caso.