DNS (Registros A, CNAME, Route 53)

O DNS é o sistema distribuído que traduz nomes de domínio em endereços IP, e é o primeiro ponto de contato de praticamente qualquer tráfego de produção. Sem ele, clientes precisariam memorizar endereços e, pior, toda mudança de infraestrutura quebraria o acesso de todos os usuários. Em produção, o DNS deixou de ser apenas um catálogo de nomes: serviços como o Route 53 usam o mesmo sistema para health checks, failover, distribuição geográfica e balanceamento ponderado, tornando o DNS um plano de controle de tráfego. A relevância arquitetural é direta: TTL curto permite mudanças ágeis, TTL longo reduz carga e latência, e a escolha entre essas opções define a velocidade de recuperação em incidentes. Um erro de DNS raramente derruba o sistema de forma ruidosa; ele degrada parcialmente, de forma silenciosa e difícil de diagnosticar, o que exige domínio conceitual sólido.

Conceito e resolução hierárquica

A resolução de nomes segue uma cadeia hierárquica de consultas, e entender essa cadeia explica por que propagação existe e por que ela não é um processo ativo.

A consulta tipicamente percorre: o resolver local do sistema operacional ou do roteador, o resolver recursivo do provedor ou serviço público, os servidores raiz, os servidores TLD do domínio e, por fim, o servidor autoritativo da zona, que devolve a resposta definitiva. Cada nível pode responder a partir de cache, e o tempo de permanência em cache é definido pelo TTL de cada registro.

O resolver recursivo é o ator central de produção: ele é quem consulta em nome do cliente, quem armazena cache e quem respeita ou ignora TTLs. Serviços como Google 8.8.8.8, Cloudflare 1.1.1.1 e os resolvers gerenciados da VPC operam milhares de consultas por segundo e agregam cache para milhões de clientes, o que significa que seu TTL é uma média percebida, não uma garantia.

A resposta autoritativa vem do serviço de DNS gerenciado, como o Route 53, que hospeda a zona e responde com autoridade pelos registros. É nele que se configuram políticas de roteamento, e é dele que os resolvers do mundo buscam a resposta.

Registros essenciais

O registro A mapeia o nome diretamente para um IPv4 e é o único registro que pode, na prática, viver no ápice da zona, porque a RFC proíbe CNAME conviver com o SOA e o NS do domínio raiz. O AAAA faz o mesmo papel para IPv6, e em produção madura os dois coexistem, com o cliente escolhendo conforme sua conectividade.

O CNAME é um alias de nome para nome: o resolver precisa fazer uma segunda resolução para obter o IP final, o que consome um TTL adicional e adiciona latência na primeira consulta. Ele é ideal para nomes que devem seguir automaticamente o destino, como www apontando para a distribuição do CloudFront, e elimina a manutenção manual de IPs.

O ponto cego do CNAME é o ápice da zona: example.com não pode ser CNAME, mas precisa apontar para um ALB ou CDN que só fornece hostname. A resposta é o registro ALIAS, extensão da AWS que resolve o nome no nível autoritativo, devolve o IP direto na resposta e não cobra consulta quando o destino é recurso AWS no mesmo ambiente. Internamente, o Route 53 expande o alias para os IPs atuais do destino a cada resposta.

Route 53 e políticas de roteamento

O Route 53 trata cada conjunto de registros como uma política de tráfego, e essa é a mudança de categoria: DNS como plano de controle de entrega.

• Simple: todas as respostas válidas são devolvidas, geralmente em aleatorização, sem verificação de saúde; serve para distribuição básica ou múltiplos IPs de um serviço.
• Weighted: distribui tráfego em percentuais configurados, útil para canary em nível de infraestrutura, migração gradual entre regiões e testes A/B de backend.
• Latency: escolhe a região com menor latência percebida pelo cliente, aproximando tráfego da infraestrutura mais rápida naquele momento.
• Geolocation: roteia pela origem geográfica do cliente, atendendo exigências legais de residência de dados e conteúdos regionais.
• Geoproximity: como geolocation, mas com desvio gradual por bias, permitindo transferir carga entre regiões de forma fina.
• Failover: primário e secundário, onde o primário só é servido enquanto o health check indica saudável, e o secundário assume automaticamente.
• Multivalue answer: devolve até oito IPs saudáveis, e o cliente escolhe, combinando balanceamento leve com verificação de saúde.

O health check é o elemento que sustenta failover e multivalue: sondas distribuídas pelo mundo consultam o endpoint em intervalos configuráveis, por HTTP, HTTPS ou TCP, e marcam o destino como saudável ou não com base em limiar de falhas. É possível inspecionar string de resposta, exigir TLS válido e associar o check ao estado do alarme do CloudWatch, encadeando DNS com observabilidade.

TTL, mudanças e caching

O TTL é o contrato de vida da resposta em cache, e é a variável que governa a velocidade de mudança da infraestrutura.

TTL alto, na faixa de horas a dias, reduz consultas, corta custo e latência, e torna a infraestrutura previsível; o preço é que uma mudança de IP leva até o TTL antigo para alcançar todo o mundo, porque resolvers respeitam o valor que tinham em cache no momento da mudança. TTL baixo, de 60 a 300 segundos, permite migrar tráfego rápido e é o padrão correto antes de qualquer operação de migração, failover frequente ou blue-green em nível de DNS.

A prática consolidada em produção é dinâmica: operar com TTL confortável em regime estável e reduzi-lo de 24 a 48 horas antes de uma mudança planejada, executar a alteração e retornar ao TTL alto depois da estabilização. Mudanças emergenciais sempre encontrarão algum tráfego preso no cache antigo, e o plano de rollback precisa considerar esse atraso.

O caching negativo é outro fator esquecido: quando o autoritativo responde NXDOMAIN, o nome não existe, os resolvers podem armazenar essa negativa pelo tempo indicado no SOA da zona, tipicamente o mínimo entre o TTL do SOA e o campo de negTTL. Criar um subdomínio novo logo depois de tê-lo consultado por engano pode propagar inexistência por minutos, e diagnóstico de "novo registro não funciona" frequentemente passa por esse cache.

Bloco prático de zona

# Exemplo conceitual de zona no Route 53 via Terraform
resource "aws_route53_record" "apice" {
  zone_id = aws_route53_zone.principal.zone_id
  name    = "exemplo.com.br"
  type    = "A"

  # ALIAS resolve o limite do CNAME no ápice da zona
  alias {
    name                   = aws_lb.frontend.dns_name
    zone_id                = aws_lb.frontend.zone_id
    evaluate_target_health = true   # só devolve IP se o ALB estiver saudável
  }
}

resource "aws_route53_record" "www" {
  zone_id = aws_route53_zone.principal.zone_id
  name    = "www.exemplo.com.br"
  type    = "CNAME"
  ttl     = 300                    # 5 minutos: equilíbrio entre cache e agilidade
  records = ["www.exemplo.com.br.cdn.cloudflare.net"]
}

resource "aws_route53_health_check" "api" {
  fqdn              = "api.exemplo.com.br"
  port              = 443
  type              = "HTTPS"
  resource_path     = "/healthz"
  failure_threshold = 3           # 3 falhas seguidas marcam como não saudável
  request_interval  = 30
}

resource "aws_route53_record" "api_failover" {
  zone_id = aws_route53_zone.principal.zone_id
  name    = "api.exemplo.com.br"
  type    = "A"
  ttl     = 60                      # TTL curto para failover reagir rápido

  set_identifier = "primario"
  failover_routing_policy {
    type = "PRIMARY"
  }
  alias {
    name                   = aws_lb.api_us_east.dns_name
    zone_id                = aws_lb.api_us_east.zone_id
    evaluate_target_health = true
  }
}

Zonas privadas e DNS interno

Ambientes de produção raramente dependem só de DNS público. Zonas hospedadas privadas resolvem nomes apenas dentro da VPC ou de redes conectadas, permitindo que api.interno.exemplo.com aponte para o ALB privado, enquanto o mesmo nome externo aponta para o ALB público. Esse padrão de split-horizon mantém a mesma superfície de nomes para dentro e fora, com destinos distintos, e simplifica configuração de aplicações que não precisam saber onde estão.

A integração com serviços gerenciados passa por zonas privadas associadas: endpoints de S3, DynamoDB, SQS e APIs privadas do API Gateway publicam entradas automáticas na zona, e o resolver outbound e inbound conecta a VPC ao datacenter legado via DNS condicional. O resultado é que o nome deixa de ser detalhe cosmético e passa a ser parte do contrato de rede entre equipes, versionado e revisado como código.

O erro típico é limitar DHCP e resolver interno ao alcance da sub-rede, esquecendo que escala horizontal de pods e funções efêmeras resolve DNS com frequência altíssima. Resolvers gerenciados suportam isso bem, mas servidores autoritativos pequenos em datacenter próprio se tornam gargalo silencioso, com timeouts de resolução que aparecem como latência intermitente na aplicação.

Diagnóstico com dig e nslookup

# Consulta direta ao registro A seguindo a cadeia de resolução
dig +noall +answer www.exemplo.com.br

# Consulta direta ao servidor autoritativo, ignorando todo cache intermediário
dig +noall +answer @ns-1024.awsdns-63.org www.exemplo.com.br

# Acompanhamento da cadeia completa com tempos por nível
dig +trace www.exemplo.com.br

# Verificação do TTL vigente em cache; repetir a consulta mostra o contador caindo
dig +noall +answer api.exemplo.com.br | awk '{print $2, $4, $5}'

# Teste de cache negativo: NXDOMAIN indica nome inexistente na zona
dig +noall +comments inexistente.exemplo.com.br | grep -E "status|SOA"

O dig é a ferramenta padrão de diagnóstico porque mostra exatamente o que o resolver devolveu, com qual TTL restante e a partir de qual servidor. Em incidentes de DNS, a sequência clássica é comparar a resposta do resolver do cliente com a resposta direta do autoritativo: se divergem, o problema é cache; se coincidem e estão erradas, o problema está na zona. A consulta com +trace revela em qual elo da cadeia a resolução quebra, distinguindo falha de delegação de falha de zona.

Erros comuns e boas práticas

• TTL de 1 dia em infraestrutura mutável: qualquer incidente exige espera de horas para propagação; mantenha TTL baixo em tudo que pode mudar.
• CNAME no lugar errado: usar CNAME onde o protocolo exige, como MX ou NS, quebra o serviço; CNAME nunca coexiste com outros registros no mesmo nome.
• Esquecer o cache negativo: recriar subdomínio após consulta falha propaga NXDOMAIN; espere o TTL negativo ou aumente o serial com planejamento.
• Health check que não reflete a aplicação: checar TCP aberto quando a aplicação responde 500 mascara falhas; cheque endpoint real com validação de conteúdo.
• Depender de um único resolver no cliente: aplicações devem resolver com cache próprio e retry, e não assumir que DNS sempre responde em milissegundos.
• Trocar CNAME por A sem automação: registrar IP manualmente de ALB quebra silenciosamente quando o balanceador troca endereços; use ALIAS ou atualização automatizada.

A boa prática estrutural é tratar DNS como código: zona declarada em IaC, mudanças por pull request, health checks ligados à observabilidade e runbook de failover testado. O DNS é simples na superfície e cheio de armadilhas operacionais; o domínio dos registros, do TTL e das políticas de roteamento é o que o torna uma ferramenta de arquitetura e não apenas uma configuração inicial.