Route 53: DNS e roteamento na AWS
Como o Route 53 resolve nomes DNS, configura registros e faz roteamento por política, como latência ou falha, para aplicações na AWS.
Revisada em · 35 min de leitura
O Amazon Route 53 é o serviço de DNS (Sistema de Nomes de Domínio) da AWS. Ele é projetado para ser uma solução de nuvem altamente escalável e confiável para gerenciar a forma como os usuários finais são direcionados para as suas aplicações.
Aqui estão os detalhes essenciais sobre o serviço:
1. O que ele faz?
O Route 53 desempenha três funções principais:
- Roteamento de Tráfego (DNS): Ele conecta as solicitações dos usuários (como digitar
www.suaempresa.com.brno navegador) aos recursos de infraestrutura que rodam a aplicação, sejam eles recursos da AWS (como instâncias [EC2], [buckets] [S3] ou Load Balancers) ou recursos externos. - Registro de Domínios: Ele permite que você registre e gerencie nomes de domínio diretamente pela plataforma da AWS.
- Verificação de Integridade (Health Checks): Embora o foco principal seja o roteamento, ele é essencial para garantir a alta disponibilidade e resiliência da sua rede, direcionando os visitantes apenas para recursos que estão saudáveis e operacionais.
2. Por que “Route 53”?
O nome é uma referência à porta TCP/UDP 53, que é a porta padrão utilizada mundialmente para o protocolo de DNS.
3. Diferenciais e Recursos Avançados
- Alta Disponibilidade: Por ser um serviço distribuído globalmente, ele oferece garantia de que os usuários conseguirão resolver o endereço do seu site, independentemente de onde estejam.
- Gerenciamento de Tráfego: Ele permite gerenciar o tráfego da internet de forma inteligente, o que é vital para manter o desempenho e a disponibilidade dos serviços online de empresas de todos os tamanhos.
- Recuperação de Desastres (Failover Routing): Com monitoramento constante de saúde (Health Checks), o Route 53 detecta quedas na infraestrutura primária e redireciona os usuários automaticamente para um ambiente de contingência secundário:
Políticas de Roteamento Principais
- Roteamento Simples (Simple Routing): Direciona o tráfego para um único recurso (ou múltiplos IPs de forma aleatória em round-robin).
- Roteamento por Failover: Direciona para um recurso primário saudável; caso o health check falhe, comuta imediatamente para o backup.
- Roteamento por Latência (Latency-based): Direciona o usuário para a região da AWS que oferece o menor tempo de resposta de rede para ele.
- Roteamento Geográfico (Geolocation): Direciona com base na localização do IP do visitante (ex.: usuários do Brasil vão para
sa-east-1, da Europa paraeu-central-1). - Roteamento Ponderado (Weighted): Distribui percentuais de tráfego (ex.: 90% versão estável v1, 10% versão de teste v2 para testes A/B ou blue/green).
As seções a seguir mostram como montar isso de verdade: uma zona hospedada, os registros que apontam para a aplicação, health checks e as duas políticas que mais se usam em produção, failover e peso.
4. Zona hospedada e registros
Tudo no Route 53 começa numa zona hospedada (hosted zone), que é o conjunto de registros de um domínio. Um registro associa um nome a um valor, por exemplo, api.exemplo.com.br ao IP 198.51.100.10. Quando alguém pergunta por esse nome, a zona responde com o valor e com um TTL, o tempo em segundos que qualquer cache pode guardar a resposta antes de perguntar de novo.
Os tipos que você vai usar com mais frequência são estes. O A aponta um nome para um endereço IPv4 e o AAAA faz o mesmo para IPv6. O CNAME diz que um nome é apelido de outro nome, e a resolução continua a partir do alvo. O TXT guarda texto, e é nele que ficam as verificações de SPF e DMARC que você vai ver na nota de SES. O MX diz qual servidor recebe e-mail do domínio.
O registro de alias é a peça que mais confunde quem vem de outro provedor de DNS. Ele é uma extensão do Route 53: aponta para um recurso da AWS (um ALB, uma distribuição CloudFront, um bucket S3 em modo site) ou para outro registro da mesma zona, e o Route 53 responde com o endereço atual desse recurso, sem que você saiba qual é. Se o IP do balanceador mudar, a resposta muda junto. Dois detalhes importam. O primeiro é que um alias pode existir no zone apex, que é o próprio domínio (exemplo.com.br, sem www), enquanto um CNAME não pode estar ali. O segundo é que a documentação diz que o Route 53 não cobra consultas de alias para recursos da AWS, ao contrário de um CNAME apontando para outro registro, que gera duas consultas cobradas.
O diagrama mostra o caminho de uma primeira consulta de www.exemplo.com.br. O navegador pergunta ao resolver recursivo do provedor, que não tem a resposta no cache e pergunta à zona do Route 53. A zona devolve o IP do balanceador, e o resolver guarda essa resposta pelo TTL. O último trecho é o tráfego HTTPS propriamente dito, que não passa mais pelo DNS. Numa segunda consulta dentro do TTL, o resolver responde do cache, e o Route 53 nem é consultado.
Delegação: quem aponta o domínio para a zona
Uma zona no Route 53 não serve para nada enquanto a internet não souber que ela existe. Antes de criar qualquer registro, vale entender a cadeia que leva alguém da digitação do nome até a zona, porque é aí que mora a maior parte das dúvidas de quem registra o primeiro domínio. Ela envolve três papéis que, no dia a dia, parecem um só.
O registrador é a empresa que vende o nome e o registra em nome do titular. É com ele que você paga, informa os dados do dono e cadastra os servidores DNS. O registro do TLD (a terminação do domínio, como .com ou .br) guarda a lista de todos os domínios daquela terminação e diz, para cada um, quais servidores respondem por ele. O servidor DNS autoritativo é quem guarda os registros de fato e responde por eles. No nosso caso, é a zona do Route 53.
Em .com, esses papéis ficam com empresas diferentes: o registro da terminação é mantido pela Verisign, e o nome você compra de um registrador qualquer. Em .br a situação é outra. O Registro.br, mantido pelo NIC.br, vende o domínio e também mantém a lista dos domínios .br. O mesmo painel recebe a compra e a configuração dos servidores, o que faz parecer que tudo acontece num lugar só. Essa mistura explica boa parte da confusão. Trocar um registro dentro da zona não muda nada na lista do TLD, e trocar os servidores no painel do registrador não muda nada na zona. Cada alteração vale só para a camada em que foi feita.
Delegação é o ato de dizer “para este domínio, pergunte a estes servidores”. Ela é gravada como registros NS (name server) no servidor do TLD, e é exatamente isso que o cadastro dos servidores no registrador faz. Sem essa gravação, a zona existe e tem os registros certos, mas ninguém chega até ela, porque toda consulta passa pela raiz e pelo TLD antes de alcançar a zona.
Há dois conjuntos de NS, e eles precisam coincidir. O primeiro fica no TLD, gravado pelo registrador, e é o que a internet segue de fora para dentro. O segundo fica dentro da própria zona: o Route 53 cria sozinho um registro NS no apex com os quatro servidores que atendem a zona. A documentação da AWS diz que os servidores cadastrados no registrador precisam ser os mesmos da zona pública. Se um deles estiver diferente, o que a internet vê de fora e o que a zona afirma sobre si mesma deixam de bater, e o diagnóstico fica difícil. A figura abaixo mostra quem grava cada coisa.
O titular conversa com o registrador, que grava a delegação no .br. A raiz só indica quem atende o .br, e não sabe nada sobre o domínio. A seta verde pontilhada é a delegação que deveria existir, apontando para a zona da AWS. A caixa rosa tracejada é o que o .br publicava para este domínio no momento da consulta, às 21h26 de 27/10/2026: os servidores padrão do Registro.br. O estado observado é detalhado no estudo de caso abaixo.
Agora a resolução completa. Quando alguém digita www.jeangrijp.com.br, o navegador não sabe onde está a zona. Ele pergunta a um resolver recursivo, em geral o do provedor de internet, que faz a busca em nome dele. O resolver começa pelos servidores raiz, que sabem quem atende cada TLD, e pergunta quem atende o .br. Depois pergunta ao servidor do .br quem atende o domínio, e recebe a delegação, ou seja, os NS gravados pelo registrador. Só então pergunta à zona do Route 53 pelo registro de www, que devolve o valor com o TTL. O resolver guarda a resposta pelo TTL e entrega o endereço ao navegador, que conecta direto no destino. Numa segunda consulta, dentro do TTL, o resolver responde do cache e a hierarquia nem é consultada. O diagrama de resolução mostrado antes começa na zona porque deixa de fora a raiz e o .br. A figura seguinte mostra o caminho inteiro.
Os números da figura seguem a ordem das consultas. A consulta 3 é a segunda vez que o navegador pede o mesmo nome, e a resposta sai do cache do resolver. As setas de ida e volta nas consultas 4, 5 e 6 mostram a pergunta e a resposta de cada servidor, e a seta 7 é a resposta final ao navegador. Para ver esse caminho na prática, o dig +trace mostra cada salto. Este trecho saiu de uma execução real em 27/10/2026, às 21h26, com a saída cortada:
br. 172800 IN NS a.dns.br.
jeangrijp.com.br. 3600 IN NS b.auto.dns.br.
jeangrijp.com.br. 3600 IN NS a.auto.dns.br.
jeangrijp.com.br. 900 IN SOA a.auto.dns.br. hostmaster.registro.br. 2026301010 1800 900 604800 900A primeira linha é a raiz indicando o .br. As duas seguintes são o servidor do .br dizendo quem atende o domínio naquele momento, que eram os servidores padrão do Registro.br. A última é a resposta do servidor que atende o domínio: como ainda não havia registro para www na zona, a resposta é um SOA, que diz “o nome não existe aqui”.
Trocar os servidores costuma demorar mais que trocar um registro, e o motivo é parecido com o da seção de propagação, mas acontece um nível acima. A delegação antiga fica guardada nos caches dos resolvers pelo TTL que tinha quando foi consultada. Na consulta que fiz, o .br entregava os NS deste domínio com TTL de 3600 segundos, uma hora, como mostrou a consulta direta ao servidor a.dns.br com dig +norec. A raiz entrega os NS do .br com TTL de 172800 segundos, dois dias. Um resolver que já conhece a delegação antiga continua indo nela até o TTL expirar, mesmo que a zona nova já esteja pronta. Há ainda o tempo que o próprio Registro.br leva para publicar a alteração. A página oficial que consegui abrir sobre isso é uma matéria do NIC.br de 2009, que fala em publicações a cada 30 minutos e em propagação de até 24 horas. Não encontrei documentação atual com esses prazos. Quando troquei os servidores do domínio, o painel mostrou que a delegação externa levaria cerca de 2 horas. Esse é o prazo observado, e não está confirmado em fonte oficial.
Essa propagação não é a mesma da seção de propagação. Lá, quem pesa é o TTL do registro, como o de um A para www. Aqui, quem pesa é o TTL dos NS do TLD, e a mudança só existe para o mundo depois que o registrador publica a delegação nova. Reduzir o TTL de um registro dentro da zona não acelera nada disso.
Estudo de caso: jeangrijp.com.br
Esta seção acompanha o caminho real de um domínio .br registrado em 27/10/2026, até o ponto em que ele está. Os comandos de leitura foram executados nessa data. Nada foi criado nem alterado na AWS para escrever a seção, e a conta de registro no Registro.br não foi consultada pelos comandos.
O domínio foi comprado no Registro.br e veio com os servidores padrão do próprio Registro.br, por isso a delegação começou apontando para eles. A zona pública foi criada com o nome do domínio. A chamada por CLI tem a mesma ideia do --caller-reference da seção de zona: repetir o comando com a mesma referência não cria outra zona. Ela já foi executada antes desta revisão, e a zona existe com essa referência.
aws route53 create-hosted-zone \
--name jeangrijp.com.br \
--caller-reference jeangrijp-1793146441Para ler os quatro servidores da zona, use o ID que aparece em HostedZone.Id na saída da criação:
aws route53 get-hosted-zone --id <ID-da-zona>A saída traz os quatro nomes em DelegationSet.NameServers: ns-703.awsdns-23.net, ns-488.awsdns-61.com, ns-1274.awsdns-31.org e ns-1912.awsdns-47.co.uk. São eles que vão para o registrador, sem ponto final no fim.
No painel do Registro.br, abri a área de servidores DNS do domínio (na documentação antiga do registro, a área aparece como Delegações de DNS) e troquei os servidores padrão pelos quatro da zona. Um dos nomes saiu errado: digitei s-1912.awsdns-47.co.uk, sem o n inicial, em vez de ns-1912.awsdns-47.co.uk. Essa falha passa batida a olho nu, e é a razão de a conferência ser feita nome por nome.
A conferência tem duas partes. A primeira pergunta diretamente a um dos servidores da zona, sem depender de cache:
dig +short NS jeangrijp.com.br @ns-703.awsdns-23.netA saída, capturada nesta data, lista os quatro nomes da zona: ns-1274.awsdns-31.org., ns-1912.awsdns-47.co.uk., ns-488.awsdns-61.com. e ns-703.awsdns-23.net.. A segunda parte pergunta o que a internet enxerga, ou seja, a delegação publicada pelo .br:
dig +short NS jeangrijp.com.brÀs 21h26 de 27/10/2026, essa segunda consulta ainda devolvia b.auto.dns.br. e a.auto.dns.br., os servidores padrão. A zona está correta, mas a delegação publicada ainda não mudou. Eu já tinha salvado os quatro servidores no painel, que mostrava os servidores em transição, então o que faltava era o Registro.br publicar a delegação nova. Quando a troca chega ao .br, a saída passa a ser a mesma lista de quatro nomes da zona. Até lá, o domínio não responde pela zona da AWS.
O certificado foi pedido no ACM na região us-east-1, que é a região que o CloudFront usa para certificados. Na validação por DNS, o ACM pede que você crie um CNAME na zona que prova o controle do domínio:
aws acm request-certificate \
--domain-name jeangrijp.com.br \
--subject-alternative-names www.jeangrijp.com.br \
--validation-method DNS \
--region us-east-1Para acompanhar o status, use aws acm describe-certificate --certificate-arn <ARN> --region us-east-1. Nesse momento o certificado aparecia como PENDING_VALIDATION. Os dois CNAMEs de validação, um para o apex e outro para www, já estão na zona, e aparecem na saída de aws route53 list-resource-record-sets. A explicação mais provável para a pendência é que a validação ainda não consegue ser consultada pela internet, porque a delegação não mudou. Não verifiquei o mecanismo interno do ACM, então trate isso como hipótese.
O último passo é o registro de alias que aponta o domínio para o CloudFront. Ele usa dois registros, um do tipo A e outro do tipo AAAA. O A leva o nome a um endereço IPv4 e o AAAA leva ao IPv6. A distribuição aceita IPv6, então um cliente que prefere IPv6 recebe o AAAA, e um cliente que só tem IPv4 recebe o A. Os dois são alias, e não CNAME, por dois motivos: o apex não aceita CNAME, e o alias acompanha os IPs do CloudFront, que podem mudar. A zona precisa de um par de registros para o apex e outro para o www. O exemplo abaixo mostra só o apex, e o www segue o mesmo formato:
{
"Comment": "Alias A e AAAA para a distribuição do CloudFront",
"Changes": [
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "exemplo.com.br.",
"Type": "A",
"AliasTarget": {
"HostedZoneId": "Z2FDTNDATAQYW2",
"DNSName": "d111111abcdef8.cloudfront.net.",
"EvaluateTargetHealth": false
}
}
},
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "exemplo.com.br.",
"Type": "AAAA",
"AliasTarget": {
"HostedZoneId": "Z2FDTNDATAQYW2",
"DNSName": "d111111abcdef8.cloudfront.net.",
"EvaluateTargetHealth": false
}
}
}
]
}aws route53 change-resource-record-sets \
--hosted-zone-id Z03753841U96HM754Y42B \
--change-batch file://alias-cloudfront.jsonO HostedZoneId Z2FDTNDATAQYW2 é o ID que usei para o alias do CloudFront neste caso. Não consultei a tabela oficial desse valor nesta revisão. O registro criado resolveu para IPs do CloudFront em um resolvedor público, o que confirma o alias na prática. Antes de copiar o valor para outro caso, confira a documentação.
A checagem que importa é feita com dig em um resolvedor público. O resolvedor do seu provedor pode guardar em cache a resposta anterior, e isso aconteceu aqui: o resolvedor local ainda devolvia “nome não existe” depois da criação dos registros, enquanto um resolvedor público já devolvia os IPs do CloudFront. Pelo dig sozinho dava para confundir um problema local com um problema real.
Em 28 de outubro de 2026, pela manhã, o estado era este. A delegação estava publicada, o certificado ACM estava ISSUED para o apex e o www, a distribuição tinha os dois aliases, e os registros A e AAAA tinham sido criados nos dois nomes. Testando o CloudFront diretamente, com o nome do domínio resolvido para um dos seus IPs, o apex respondia 200 e o www respondia 301 para o apex.
DNSSEC: a assinatura que vem depois
DNSSEC é um conjunto de assinaturas criptográficas aplicadas às respostas do DNS. Quem consulta consegue verificar que a resposta saiu da zona e não foi alterada pelo caminho. Ele é opcional para a maioria dos domínios. Pela documentação da AWS que consultei, o Route 53 assina zonas públicas, e a chave principal de assinatura (KSK) é uma chave assimétrica do AWS KMS que fica sob o seu controle, enquanto a chave de zona (ZSK) é gerenciada pelo Route 53. Ativar a assinatura também limita a um máximo de uma semana o TTL dos registros da zona.
Para a cadeia de confiança fechar, o nível de cima precisa publicar um registro DS, que é o resumo da chave de assinatura da zona. Esse registro é cadastrado no registrador, e no caso do .br no próprio painel do Registro.br. Não verifiquei na página de habilitação o passo exato do DS, nem o nome do campo que o painel do .br usa para ele, porque a página oficial do Registro.br sobre DNSSEC veio vazia na minha consulta. Neste domínio o DNSSEC não foi ativado: a zona não tem chave de assinatura e o domínio não tem registro DS. Ativar antes de a delegação estar estável acrescenta um risco, porque um DS errado deixa o domínio inacessível para quem valida as respostas.
Criando a zona e os registros
No console, a sequência é: abrir Hosted zones, escolher Create hosted zone, informar o nome do domínio e deixar o tipo como Public hosted zone. Ao criar, o Route 53 mostra os servidores de nome (NS) da zona. Esses servidores precisam ser cadastrados no registrador do domínio (quem vendeu o domínio), porque é ali que a internet descobre quem responde pela zona. Se o registrador ainda aponta para outros servidores, a zona existe e não responde nada para o público, e esse é o erro mais comum de quem se atrapalha na primeira vez.
Pela CLI, a criação da zona usa um --caller-reference, um texto que torna a chamada idempotente, ou seja, repetir o comando com a mesma referência não cria uma segunda zona:
aws route53 create-hosted-zone \
--name exemplo.com.br \
--caller-reference criacao-2026-10-27A saída traz HostedZone.Id (algo como /hostedzone/Z0123456789ABCDEFGHIJ), a lista de servidores de nome em DelegationSet e um ChangeInfo com o status da criação. Use o ID sem o prefixo /hostedzone/ nos comandos seguintes.
Os registros entram por change-resource-record-sets, que recebe um lote de mudanças em JSON. O parâmetro --hosted-zone-id diz em qual zona gravar, e --change-batch diz o que mudar. A ação UPSERT cria o registro se ele não existe e o substitui se existe, o que torna o comando seguro para repetir. Um registro A simples fica assim, salvo como registro-a.json:
{
"Comment": "Registro A para a API",
"Changes": [
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "api.exemplo.com.br",
"Type": "A",
"TTL": 300,
"ResourceRecords": [{"Value": "198.51.100.10"}]
}
}
]
}aws route53 change-resource-record-sets \
--hosted-zone-id Z0123456789ABCDEFGHIJ \
--change-batch file://registro-a.jsonEssa chamada devolve um ChangeInfo com Id e Status, que começa em PENDING. Esse Id serve para acompanhar a propagação com aws route53 get-change --id /change/C0123456789ABCDEF.
Um CNAME para uma distribuição do CloudFront segue o mesmo formato, trocando o tipo e o valor. Ele vale para subdomínios, nunca para o apex:
{
"Comment": "CNAME para o CloudFront",
"Changes": [
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "static.exemplo.com.br",
"Type": "CNAME",
"TTL": 300,
"ResourceRecords": [{"Value": "d111111abcdef8.cloudfront.net"}]
}
}
]
}Para o apex apontando para um Application Load Balancer, o registro é do tipo A com AliasTarget, e não tem TTL próprio:
{
"Comment": "Alias do apex para o ALB",
"Changes": [
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "exemplo.com.br",
"Type": "A",
"AliasTarget": {
"HostedZoneId": "ZXXXXXXXXXXXXX",
"DNSName": "dualstack.minha-alb-123.us-east-1.elb.amazonaws.com",
"EvaluateTargetHealth": true
}
}
}
]
}O HostedZoneId dentro de AliasTarget é o ID da zona gerenciada pela AWS para o balanceador naquela região, e não o ID da sua zona. Eu deixei um valor fictício de propósito: confira o valor correto na documentação do Elastic Load Balancing para a região do seu balanceador, porque não o verifiquei nesta revisão. EvaluateTargetHealth faz o alias responder só com alvos saudáveis, o que só funciona bem quando o balanceador tem alvos registrados.
Para conferir sem depender de cache, use test-dns-answer, que pergunta direto à zona:
aws route53 test-dns-answer \
--hosted-zone-id Z0123456789ABCDEFGHIJ \
--record-name api.exemplo.com.br \
--record-type AA saída traz ResponseCode (NOERROR quando deu certo), o RecordData com os valores e o Protocol. Esse teste mostra o que a zona responde, não o que o resto da internet já enxerga. Para isso você usa dig.
Propagação: por que a mudança “não pegou”
A frase “propagação de DNS” esconde duas coisas diferentes, e separá-las resolve quase todo caso. A primeira é a propagação dentro da AWS. O GetChange informa o estado com dois valores: PENDING, que significa que a mudança ainda não chegou a todos os servidores do Route 53 que atendem a zona, e INSYNC, que significa que chegou. A segunda é a propagação na internet, que depende do TTL dos registros antigos. Um resolver que guardou a resposta antiga continua respondendo com ela até o TTL expirar, mesmo que a zona já esteja INSYNC. Por isso, antes de uma migração, reduza o TTL com antecedência, por exemplo para 60 segundos, e só então troque o valor.
Para diagnosticar, consulte a zona diretamente e depois um resolver público:
dig +short NS exemplo.com.br
dig +short A api.exemplo.com.br @ns-123.awsdns-45.com
dig +short A api.exemplo.com.brO primeiro comando confere se o domínio delega para os servidores da zona. Se ele devolve servidores antigos, o problema está no registrador, e nenhuma mudança na zona resolve isso. O segundo pergunta direto a um servidor da zona: se ele já responde o valor novo, a zona está certa. O terceiro pergunta pelo resolver padrão da sua rede, que pode ainda estar com cache. Use um nome de servidor real da sua zona no lugar do exemplo, que é fictício.
Cache negativo: quando o “não existe” também fica guardado
Até aqui a seção tratou de respostas positivas, em que o nome existe e o resolver recebe um valor com um TTL. Falta o outro lado. Quando alguém pergunta por um nome que a zona não tem, o servidor autoritativo também responde, e essa resposta negativa pode ser guardada pelo resolver como qualquer outra. Esse comportamento se chama cache negativo, e ele explica uma parte grande das vezes em que um registro recém-criado parece não funcionar.
A RFC 2308, que trata desse caso, separa duas situações. O NXDOMAIN, que também aparece como “Name Error” no código de resposta, quer dizer que o nome não existe na zona. O NODATA quer dizer que o nome existe, mas não há nenhum registro do tipo pedido. Se www.jeangrijp.com.br não existe de jeito nenhum, a resposta é NXDOMAIN. Se o nome tem só um registro A e alguém pede AAAA, a resposta é NODATA. Para o resolver, os dois casos são negativas que podem ser guardadas. A diferença importa mais para quem está diagnosticando.
Por que isso existe? Sem cache negativo, toda consulta a um nome inexistente chegaria à zona. Isso acontece mais do que parece: um link com erro de digitação, uma aplicação com um nome de configuração trocado, um programa que tenta um subdomínio que nunca foi criado. Se o resolver guardasse só as respostas positivas, cada uma dessas tentativas faria a viagem completa até o servidor autoritativo. A negativa guardada faz o resolver responder do cache por um tempo, e poupa a zona de receber a mesma pergunta sem parar.
O campo que controla esse tempo fica no registro SOA da zona. O SOA (Start of Authority) descreve a zona: o servidor principal, um número de série e alguns tempos de atualização. Seu último campo se chama minimum. A RFC 2308 redefiniu esse campo para servir como TTL das respostas negativas (seção 4). Pela seção 3, o TTL que o resolver usa é o menor entre o campo minimum e o TTL do próprio registro SOA. Quando o servidor responde com um “não existe”, ele inclui o SOA da zona na seção de autoridade da resposta, e é esse registro que informa por quanto tempo a negativa pode ser guardada. O resolver conta esse tempo para baixo, e quando ele chega a zero, a negativa não pode mais ser usada e a consulta volta à zona (RFC 2308, seção 5).
Consultei o SOA da zona do jeangrijp.com.br diretamente no servidor autoritativo, ns-703.awsdns-23.net, e o resultado foi este:
jeangrijp.com.br. 900 IN SOA ns-703.awsdns-23.net. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400O último número é o minimum, 86400 segundos, ou 24 horas. Mas a segunda coluna, 900, é o TTL do próprio SOA, que são 15 minutos. Pela regra da RFC, vale o menor dos dois, então o teto efetivo desta zona é 900 segundos. As 24 horas só entrariam se o TTL do SOA fosse igual ou maior que elas. É por isso que o minimum funciona como teto e não como prazo fixo: ele só tem efeito quando é o menor dos dois valores. Quem lê só o último número da linha superestima em 96 vezes o tempo que um nome inexistente pode ficar guardado nesta zona.
O caso real aconteceu em 28 de outubro de 2026. Eu criei a zona e os registros, e antes que os registros A e AAAA do apex existissem, o resolver do meu provedor de internet guardou a resposta de que o nome não existia. Depois que os registros foram criados, o resolver público 1.1.1.1 já respondia com os IPs do CloudFront, mas o resolver local e o navegador (Brave, com o erro DNS_PROBE_POSSIBLE) continuavam com a falha guardada. Essa descrição é o que eu vi naquele dia, e não medi o estado da manhã em que a negativa foi guardada.
Quando repeti as consultas, às 7h37 de 28/10, o resolver do sistema, que usa os servidores do provedor, respondeu NOERROR sem nenhum registro para o apex. Isso é NODATA, e não NXDOMAIN, porque o apex existe na zona, com seus NS e seu SOA, mas ainda não tinha registro A. O mesmo resolver já resolvia www.jeangrijp.com.br para quatro IPs do CloudFront (13.224.30.47, 13.224.30.53, 13.224.30.108 e 13.224.30.129), e o dig -x do último aponta para um nome cloudfront.net. Os resolvedores 1.1.1.1 e 8.8.8.8 também devolviam IPs do CloudFront para o apex. Ou seja, no mesmo resolver, um nome estava com resposta positiva e outro com negativa guardada. O cache é por nome e tipo, e não por domínio inteiro.
A negativa do apex estava em contagem regressiva. Às 7h37:01 o SOA na seção de autoridade mostrava TTL 312, às 7h37:20 mostrava 293 e às 7h37:30, 283. Pela conta, a resposta foi guardada por volta das 7h27, com os 900 segundos do SOA, e venceria perto das 7h42. Essa parte é inferência minha sobre os números: não sei quando o resolver guardou a negativa nem se ele usou o mesmo TTL. Às 7h43:51 consultei de novo, e o resolver do sistema já devolvia os quatro IPs do CloudFront para o apex, em A e em AAAA. A negativa venceu dentro da janela que a conta indicava, o que é coerente com o TTL de 900 segundos do SOA. A hora em que ela foi guardada continua sendo inferida, porque não medi esse momento.
Para diagnosticar, a pergunta é em que camada está a resposta antiga. A ordem mais útil vai de fora para dentro. Primeiro, consulte a zona diretamente, que responde a verdade:
dig +short A jeangrijp.com.br @ns-703.awsdns-23.netDepois, consulte um resolver público e, por fim, o resolver do seu sistema:
dig +short A jeangrijp.com.br @1.1.1.1
dig +short A jeangrijp.com.brSe a zona e o resolver público respondem o valor certo, mas o resolver do sistema não, o problema está no cache de quem atende a sua rede. Um +short vazio pode ser NODATA ou NXDOMAIN, e para separar os dois é preciso ver o código de resposta, com dig A jeangrijp.com.br | grep status. O navegador tem um cache próprio, por cima do cache do sistema, e pode guardar a falha por conta própria. Quando o erro aparece só no navegador, limpar o cache do sistema não resolve. As três camadas são independentes: a do navegador e a do sistema operacional estão na sua máquina, e a do resolver do provedor, não.
Para limpar as camadas que estão na sua máquina, no macOS rode os comandos abaixo com privilégio de administrador:
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponderNo Chrome, abra chrome://net-internals/#dns e clique em “Clear host cache”. No Brave, o caminho deveria ser brave://net-internals/#dns, mas não testei no Brave. Esses passos não alteram o cache do resolver do provedor, que você não controla. Para ele, sobram duas saídas: esperar o TTL vencer ou, para confirmar que o problema era só local, usar outro resolver na configuração de rede. Eu não executei nenhum desses comandos com privilégio, e a validade dos comandos do macOS nesta versão do sistema não foi conferida na documentação da Apple.
Reduzir o TTL depois não ajuda quem já guardou a negativa. O TTL do SOA vale para as respostas emitidas a partir do momento em que é alterado. A entrada que o resolver já tem continua com a contagem que recebeu e só some quando chega a zero. A lógica é a mesma da seção de propagação, com uma diferença: lá o que ficou guardado era o registro antigo, e aqui é a ausência dele.
Três erros aparecem com frequência nessa situação, e todos vêm da mesma confusão. O primeiro é criar o registro e testar só com o resolver local logo em seguida, o que devolve a negativa antiga e faz parecer que a zona está errada. O segundo é mudar o registro várias vezes tentando acelerar, achando que a mudança apaga a negativa do resolver. Ela não apaga, e a espera continua a mesma. O terceiro é concluir que a AWS está com problema, quando a zona já responde certo e o que atrasou foi o cache. Antes de mexer em qualquer coisa, compare a zona com um resolver público e confira o código de resposta.
Health checks: quando a AWS considera um endpoint saudável
Um health check é uma verificação periódica feita por servidores da AWS espalhados pelo mundo. Ele não roda na sua aplicação, roda de fora, como um usuário faria. Há três tipos: o que monitora um endpoint por IP ou nome de domínio, o que combina o resultado de outros health checks (um “calculado”, que diz, por exemplo, que pelo menos dois de três servidores estão saudáveis) e o que observa um alarme do CloudWatch.
Para um endpoint, você escolhe o protocolo (HTTP, HTTPS ou TCP), o caminho que será requisitado e o intervalo entre as checagens, que pode ser de 10 ou 30 segundos. A documentação indica cobrança adicional para o intervalo rápido de 10 segundos. Cada checador espera conectar em até 4 segundos e receber um status 2xx ou 3xx em até 2 segundos depois. A decisão final não depende de um checador só: o endpoint é considerado saudável quando mais de 18% dos checadores o veem saudável, o que impede que um problema de rede de uma única região derrube um serviço que está bem.
O limiar de falhas consecutivas (o FailureThreshold) define quantas checagens seguidas precisam falhar para o estado mudar. Um valor maior evita trocar de região por causa de uma oscilação de um segundo, ao custo de demorar mais para reagir a uma queda de verdade. Crie o health check com um arquivo de configuração:
{
"Type": "HTTPS",
"FullyQualifiedDomainName": "api-primaria.exemplo.com.br",
"Port": 443,
"ResourcePath": "/saude",
"RequestInterval": 30,
"FailureThreshold": 3
}aws route53 create-health-check \
--caller-reference saude-api-primaria-2026-10-27 \
--health-check-config file://health-check.jsonA saída traz o HealthCheck.Id, que você usa na política de failover. Não verifiquei nesta revisão o valor padrão do FailureThreshold quando ele não é informado, então defina-o explicitamente, como acima.
Um cuidado prático: se o endpoint fica atrás de um firewall ou de um grupo de segurança que bloqueia tráfego vindo da internet, o health check falha mesmo com a aplicação funcionando. Antes de culpar a aplicação, confirme que a rota do checador chega ao endpoint. Se o endpoint é um ALB, prefira EvaluateTargetHealth no alias em vez de um health check separado, porque o balanceador já sabe quais alvos estão saudáveis.
Failover: ativo-passivo com registros PRIMARY e SECONDARY
O failover usa dois registros com o mesmo nome e o mesmo tipo, diferenciados pelo SetIdentifier e pelo campo Failover, que vale PRIMARY ou SECONDARY. Enquanto o primário está saudável, o Route 53 responde com ele. Quando o health check associado ao primário falha, a zona passa a responder com o secundário. O primário é anexado ao health check, e o secundário fica sem health check.
O diagrama mostra os dois estados no mesmo desenho. Repare que o health check não envia o tráfego de cliente: ele apenas observa a API primária e informa o Route 53, que decide qual registro responder. A seta grossa para a contingência só existe depois da falha, e a caixa do primário está marcada como erro para lembrar que a decisão nasce dele.
Os dois registros, em um só lote, ficam assim. Note o HealthCheckId apenas no primário:
{
"Changes": [
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "api.exemplo.com.br",
"Type": "A",
"SetIdentifier": "primaria",
"Failover": "PRIMARY",
"TTL": 60,
"HealthCheckId": "11111111-2222-3333-4444-555555555555",
"ResourceRecords": [{"Value": "198.51.100.10"}]
}
},
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "api.exemplo.com.br",
"Type": "A",
"SetIdentifier": "contingencia",
"Failover": "SECONDARY",
"TTL": 60,
"ResourceRecords": [{"Value": "203.0.113.20"}]
}
}
]
}O HealthCheckId é um valor fictício. Para um ALB, a documentação recomenda criar o registro como alias com EvaluateTargetHealth igual a Yes, sem health check separado. O TTL de 60 segundos aqui é uma escolha de exemplo: quanto menor o TTL, mais rápido os clientes trocam de destino depois de uma falha, ao custo de mais consultas à zona.
Roteamento ponderado: canário com 10% do tráfego
O roteamento ponderado faz o contrário do failover: em vez de escolher um destino, ele divide o tráfego entre vários registros de mesmo nome, na proporção dos pesos. É a forma mais simples de testar uma versão nova com uma fração pequena de usuários reais, e de aumentar a fatia aos poucos conforme os indicadores de erro se mantêm bons.
No desenho, a versão estável recebe 90 e a versão canário recebe 10. Os pesos são relativos: 9 e 1 produziriam a mesma proporção. Como o DNS não acompanha cada requisição, a divisão acontece por consulta de DNS, e um cliente que guardou a resposta no cache continua no mesmo destino até o TTL expirar. Por isso a divisão observada costuma parecer menos precisa do que os pesos indicam, sobretudo com poucos clientes.
{
"Changes": [
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "api.exemplo.com.br",
"Type": "A",
"SetIdentifier": "v1-estavel",
"Weight": 90,
"TTL": 60,
"ResourceRecords": [{"Value": "198.51.100.10"}]
}
},
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "api.exemplo.com.br",
"Type": "A",
"SetIdentifier": "v2-canario",
"Weight": 10,
"TTL": 60,
"ResourceRecords": [{"Value": "203.0.113.30"}]
}
}
]
}Para retirar o canário, troque o peso dele para zero em vez de apagar o registro. Um peso zero deixa de receber tráfego, e voltar atrás depois é uma alteração pequena, não uma recriação.
5. Erros comuns e como resolver
O erro mais citado por quem começa é tentar criar um CNAME no apex, como exemplo.com.br. A Route 53 rejeita o lote, e a solução é usar um alias apontando para o recurso, que é exatamente o caso da seção 4.
Logo depois vem a mudança que “não pegou”. O diagnóstico da seção de propagação resolve a maioria: se o NS não aponta para a zona, o registrador é o culpado, e se a zona responde o valor novo mas a internet não, o TTL antigo ainda está em cache. Não mude o registro várias vezes tentando acelerar, porque isso só mistura respostas antigas e novas por mais tempo.
Se o nome foi consultado antes de existir, a espera pode vir do cache negativo, que tem teto no TTL do SOA (900 segundos no caso do jeangrijp.com.br). Mudar o registro de novo não encurta essa espera. A seção sobre cache negativo mostra como separar o que a zona responde do que o resolver guardou.
Um health check que falha sem motivo aparente costuma ser problema de rede ou de caminho. Confira se o endpoint responde por HTTPS dentro de 4 segundos, se o certificado é válido (o health check de HTTPS não valida o certificado, então um certificado vencido não causa falha por si só) e se o firewall deixa passar o tráfego do checador.
Também é comum esquecer EvaluateTargetHealth num alias para ALB e perceber, na queda, que o registro continua respondendo com um balanceador sem alvos. Ative a opção ao criar o alias.
Por fim, um TTL alto demais numa migração prende os clientes ao endereço antigo pelo tempo do TTL. Se você vai trocar um IP amanhã, reduza o TTL hoje.
Em domínio registrado fora da AWS aparecem dois erros próprios. O primeiro é digitar errado um dos quatro NS no registrador, como s-1912... no lugar de ns-1912.... Compare o texto nome por nome com a saída de get-hosted-zone. O segundo é achar que o site já funciona porque a zona está criada e com os registros certos. Enquanto o TLD publicar os servidores padrão do registrador, a zona não é consultada por ninguém. Antes de testar o site, rode dig +short NS no domínio e confirme que a lista é a da zona.
6. Exercícios
- Crie uma zona de teste para um domínio que você controla, adicione um registro
Ae verifique comtest-dns-answere comdig. Depois explique, com suas palavras, por que as duas respostas podem divergir logo após uma mudança. - Monte um failover para um endpoint de sua escolha com um health check HTTPS em
/saude. Derrube o primário de propósito (ou aponte o health check para um caminho inexistente) e observe quando o registro secundário passa a responder. - Troque o peso de um roteamento ponderado de 90/10 para 50/50 e calcule quantas requisições, de um lote de mil, devem cair em cada destino se todos os clientes respeitarem o TTL desde o começo.
7. Glossário
- Zona hospedada (hosted zone): o conjunto de registros de um domínio gerenciado no Route 53.
- TTL (Time To Live): o tempo em segundos que um resolver pode guardar uma resposta de DNS antes de perguntar de novo.
- Zone apex: o próprio domínio, sem subdomínio, como
exemplo.com.br. - Cache negativo (negative caching): guarda por um tempo a resposta de que um nome ou um tipo de registro não existe, com teto definido pelo TTL do SOA. Vem da RFC 2308.
- NXDOMAIN: resposta que diz que o nome não existe na zona. NODATA: resposta que diz que o nome existe, mas não tem registro do tipo pedido.
- Alias: registro específico do Route 53 que aponta para um recurso da AWS ou para outro registro da zona, e responde com o valor atual dele.
- Health check: verificação periódica feita pelos checadores do Route 53 para decidir se um endpoint está saudável.
- INSYNC: estado de uma mudança que já chegou a todos os servidores do Route 53 que atendem a zona.
- Delegação: registro NS no servidor do TLD que diz quais servidores respondem por um domínio.
- Resolver recursivo: servidor, em geral do provedor, que faz a busca completa em nome do navegador e guarda as respostas em cache.
- Servidor autoritativo: servidor que responde pelos registros de uma zona, como a zona pública do Route 53.
- TLD (top-level domain): a terminação do domínio, como
.comou.br. - Registrador: empresa que vende o nome e o registra em nome do titular.
- DS (Delegation Signer): registro com o resumo da chave de assinatura da zona, cadastrado no nível de cima para fechar a cadeia do DNSSEC.
Fontes
Consultadas em 2026-10-27:
- Escolher entre registros alias e não alias
- Tipos de health check
- Como o Route 53 determina se um health check está saudável
- Valores para criar health checks
- Failover ativo-passivo
- GetChange (referência da API)
- Configuring DNS routing for a new domain, consultada em 2026-10-27.
- Configuring DNSSEC signing in Amazon Route 53, consultada em 2026-10-27.
- RFC 2308: Negative Caching of DNS Queries (DNS NCACHE), consultada em 2026-10-28 (seções 1, 2.1, 2.2, 3, 4 e 5).
- Routing traffic to an Amazon CloudFront distribution by using your domain name, consultada em 2026-10-27.
- Definindo o DNS para domínios registrados no Registro.br, matéria do NIC.br de 2009, usada só como referência histórica. Não é a regra atual do registro.
- Referência de comandos da AWS CLI 2.33.18 instalada localmente, conferida com
aws route53 <comando> helpeaws acm request-certificate help. - Saídas de
dig,aws route53,aws acmeaws cloudfrontcapturadas em 2026-10-27, todas de leitura.
Não verificado: o prazo atual de publicação e de transição de servidores no Registro.br, o prazo de cerca de 2 horas observado no painel, se o .br é opcional para DNSSEC hoje, o nome do campo DS na interface do Registro.br, o HostedZoneId Z2FDTNDATAQYW2 do CloudFront, usado sem consulta à tabela oficial nesta revisão, o valor de HostedZoneId do ALB por região, o valor padrão do FailureThreshold e os preços de consultas e de health checks, que mudam e devem ser conferidos na página de preços do Route 53. Sobre o cache negativo, não medi se os resolvedores do provedor e do navegador respeitam o TTL do SOA ou se têm um teto próprio: observei só a contagem regressiva do resolver do sistema. Também não sei quando a negativa do apex foi guardada nem qual código de resposta o provedor guardou em 28/10, e os comandos de limpeza do macOS e o caminho do Brave não foram executados nem testados nesta revisão.