System Design/02 - Componentes2 min
Domain Name System
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
DNS traduz nome (exemplo.com) em endereço IP. É uma base de dados hierárquica e distribuída, e a primeira coisa que acontece em quase toda requisição.
A resolução, passo a passo
navegador → cache local → resolver do ISP
↓ (se não tiver em cache)
root server → "pergunte ao .com"
TLD server (.com)→ "pergunte ao ns1.exemplo.com"
authoritative → "é 93.184.216.34"
Tipos de registro
| Registro | Aponta para | Nota |
|---|---|---|
| A / AAAA | IPv4 / IPv6 | O básico |
| CNAME | Outro nome | Não funciona no apex do domínio |
| ALIAS / ANAME | Recurso, resolvido pelo provedor | Funciona no apex; extensão não-padrão |
| MX | Servidor de e-mail | Com prioridade |
| NS | Servidores autoritativos | Delegação |
| TXT | Texto livre | SPF, DKIM, verificação de domínio |
TTL — a variável que importa
O TTL diz por quanto tempo cada resolver pode cachear a resposta. É o botão que controla o trade-off entre carga e agilidade.
Trade-offs
TTL alto (24 h): menos consultas, resposta mais rápida, menor custo — e mudanças demoram até um dia para propagar. TTL baixo (60 s): mudança propaga rápido — e multiplica consultas e a dependência do DNS estar no ar.
Isso limita o DNS como mecanismo de failover: mesmo com TTL de 60 s, resolvers e navegadores frequentemente ignoram TTL curto e cacheiam mais. Failover via DNS leva minutos, não segundos. Quando o requisito é failover em segundos, a resposta é IP anycast ou balanceador, não DNS.
DNS também é um vetor de ataque e um SPOF: se a zona fica indisponível, o sistema inteiro some do mapa mesmo com todos os servidores saudáveis.
Exemplo prático
Uma migração de servidor com TTL de 24 h: você muda o registro A e, por até um dia, parte do tráfego continua indo para o IP antigo. O procedimento correto é baixar o TTL para 60 s com um dia de antecedência, fazer a migração, e restaurar o TTL depois.
Balanceamento por DNS (vários registros A para o mesmo nome) distribui de forma grosseira: o resolver escolhe, não há health check imediato, e a distribuição pode ficar desigual por causa de cache. Serve como camada complementar, nunca como o balanceador principal.
Relacionado
Parte de 02 - MOC Componentes · roadmap.sh/system-design