Route 53 DNS e Resolver

Uma função Lambda dentro da sua VPC chama payments.corp.internal e recebe NXDOMAIN. O mesmo nome resolve em 30 milissegundos do seu notebook pela VPN corporativa. Nada mudou na aplicação, o registro existe, e o DNS está "funcionando" por qualquer teste que você consiga imaginar.

O registro está certo. O que mudou foi qual resolver respondeu. Um nome dentro de uma VPC pode ser resolvido por 3 coisas diferentes, e elas não se consultam. Descobrir para onde uma consulta vai é a maior parte do diagnóstico de Route 53, e é o que a prova cobra nesta área.

Hosted zones: o contêiner de onde o Route 53 responde

Uma hosted zone guarda os registros de um domínio e dos subdomínios dele. Crie uma hosted zone para example.com e você ganha um contêiner de onde o Route 53 vai responder consultas, mais os name servers que tornam essa resposta oficial.

Existem 2 tipos, e a diferença é quem pode perguntar:

• Uma public hosted zone responde consultas vindas da internet. O Route 53 atribui 4 name servers, e você aponta o registrador do domínio para eles com registros NS. Essa delegação é o que torna o Route 53 autoritativo para o domínio.
• Uma private hosted zone responde apenas consultas vindas de VPCs que você associar a ela. Ela não é alcançável da internet, e os registros dela nunca aparecem no DNS público.

Private hosted zones também recebem registros NS, porque o protocolo DNS exige que toda zona tenha, e eles são sempre os mesmos 4 nomes reservados:

ns-0.awsdns-00.com
ns-512.awsdns-00.net
ns-1024.awsdns-00.org
ns-1536.awsdns-00.co.uk

Esses nomes são visíveis na internet, mas consultá-los diretamente não devolve nada sobre a sua zona. O VPC Resolver também nunca fala com eles. Ele reconhece que a consulta cai dentro de um namespace privado pela associação entre VPC e hosted zone e alcança os dados privados direto. Então "os name servers são públicos" é verdade e é inofensivo.

Registros, TTL e a consulta que você nunca vê

Um registro mapeia um nome e um tipo para um valor: www.example.com tipo A para 203.0.113.10. Cada registro carrega um TTL, o número de segundos que um resolver DNS pode guardar a resposta em cache antes de perguntar de novo.

O TTL é o campo mais importante do ponto de vista operacional, e é fácil subestimar. Coloque 300 e um resolver que respondeu a um cliente às 10:00:00 vai continuar servindo aquela mesma resposta até as 10:05:00 sem falar com o Route 53. Isso tem 3 consequências que você vai reencontrar neste tópico:

• Um failover ou uma mudança de registro só vale para clientes existentes quando a cópia em cache deles expira.
• Query logs contam menos do que o tráfego real, às vezes por ordens de grandeza, porque respostas em cache nunca chegam ao Route 53.
• Baixar o TTL antes de uma migração planejada e subir depois é a técnica padrão de corte.

Registros alias: o atalho que só existe na AWS

Você quer que example.com alcance um Application Load Balancer. O load balancer tem um nome DNS, não um endereço IP estável, então um registro A com endereço fixo está errado no dia em que a AWS troca um nó. A resposta óbvia é um CNAME, e o protocolo DNS proíbe: você não pode criar um CNAME no ápice da zona, o nó mais alto do namespace.

Um registro alias é a extensão do Route 53 que fecha essa lacuna. Ele parece um registro A ou AAAA para qualquer cliente, mas o destino dele é um recurso da AWS que o Route 53 resolve na hora da consulta.

Destinos de alias que vale reconhecer: load balancers do Elastic Load Balancing (Application, Network e Classic), distribuições do CloudFront, buckets S3 configurados como site estático, APIs do API Gateway, interface endpoints de VPC, aceleradores do Global Accelerator, ambientes do Elastic Beanstalk, serviços do App Runner, domínios do AppSync, domínios do OpenSearch Service e outro registro do mesmo tipo na mesma hosted zone.

Dois pontos práticos. Registros alias acompanham o recurso sozinhos, então se os endereços do load balancer mudarem, o Route 53 passa a responder com os novos sem que você toque em nada. E registros alias podem ligar o Evaluate Target Health, que é como uma configuração de failover descobre que um load balancer caiu sem você criar um health check para ele.

Private hosted zones e os 2 atributos de VPC de que elas dependem

Crie uma private hosted zone, associe uma VPC e adicione registros. Instâncias daquela VPC passam a resolver aqueles nomes para endereços privados.

Isso falha em silêncio se a VPC não estiver configurada para tanto. Os 2 atributos abaixo precisam estar em true:

• enableDnsSupport
• enableDnsHostnames

aws ec2 describe-vpc-attribute --vpc-id vpc-0a1b2c3d --attribute enableDnsSupport
aws ec2 describe-vpc-attribute --vpc-id vpc-0a1b2c3d --attribute enableDnsHostnames

aws ec2 modify-vpc-attribute --vpc-id vpc-0a1b2c3d --enable-dns-hostnames

Uma private hosted zone pode ser associada a até 300 VPCs, inclusive de outras contas (a associação vinda de outra conta é um fluxo de 2 passos: autorizar e depois associar). Passando de 300, a ferramenta pretendida é o Route 53 Profiles, e não um aumento de cota.

Health checks se comportam de outro jeito aqui. Em uma private hosted zone você só pode anexar health checks a registros de failover, multivalue answer, weighted, latency, geolocation e geoproximity. IP-based routing não é suportado em private hosted zone de jeito nenhum.

Split-view DNS e a armadilha do NXDOMAIN

Split-view DNS (também chamado de split-horizon) é o padrão em que o mesmo nome de domínio resolve diferente dentro e fora da sua rede. Você cria uma public hosted zone e uma private hosted zone com o mesmo nome, associa a privada às suas VPCs e preenche cada uma com os registros adequados ao público dela. Chamadores internos alcançam 10.0.5.20; a internet alcança a sua distribuição do CloudFront.

Aqui está a parte que surpreende. Suponha que a sua private hosted zone seja example.com e contenha registros para db.example.com e cache.example.com, mas nada para reports.example.com, que existe no DNS público.

O VPC Resolver avalia nesta ordem:

1. Alguma private hosted zone associada a esta VPC casa com o nome da consulta? Casar significa nome idêntico ou nome que seja pai da consulta. example.com é pai de reports.example.com, então sim.
2. Procurar naquela zona um registro que case com nome e tipo.
3. Nada encontrado. Devolver NXDOMAIN.

Ele não cai para o DNS público. Assim que uma zona privada reivindica o namespace, ela passa a ser dona do namespace inteiro dentro daquela VPC. Esse é o segundo incidente mais comum com private hosted zones, atrás só dos atributos de VPC faltando, e o sintoma é sempre o mesmo: um nome funciona em todo lugar menos dentro da VPC.

Quando 2 private hosted zones se sobrepõem, ganha a correspondência mais específica. Com zonas para example.com e accounting.example.com associadas, uma consulta por seattle.accounting.example.com é respondida por accounting.example.com, e só por ela.

O VPC Resolver no VPC+2

Toda VPC ganha um resolver na base do CIDR dela mais dois. Uma VPC usando 10.20.0.0/16 tem o resolver em 10.20.0.2. Esse endereço é um dos 5 que a AWS reserva em cada sub-rede, e é para lá que as instâncias mandam consultas DNS a menos que um DHCP options set diga outra coisa.

O VPC Resolver responde 3 categorias:

• Hostnames internos do EC2, como ip-10-20-1-15.ec2.internal
• Registros de private hosted zones associadas à VPC
• Nomes públicos, fazendo consultas recursivas contra name servers públicos no seu lugar

Essa terceira importa: as instâncias não falam com o DNS público, quem faz a recursão é o VPC Resolver. Ele também consegue validar DNSSEC nessas respostas recursivas se você habilitar a validação DNSSEC.

Se você roda os seus próprios servidores DNS em instâncias EC2, eles precisam encaminhar para o VPC+2 para alcançar os dados da private hosted zone. Apontar para o router da VPC (.1) não funciona.

A documentação da AWS hoje chama esse componente de Route 53 VPC Resolver; material mais antigo e o guia do exame chamam de Route 53 Resolver. É a mesma coisa.

DNS híbrido: endpoints inbound e outbound

O VPC Resolver não sabe nada sobre corp.internal rodando nos seus servidores Active Directory on-premises, e o seu resolver on-premises não sabe nada sobre as suas private hosted zones. Os endpoints do Resolver ligam os 2 lados, e os nomes deles são o par de termos mais invertido deste domínio.

Os 2 nomes são escritos do ponto de vista da VPC:

• Um outbound endpoint manda consultas para fora da VPC, rumo à sua rede. Você o combina com forwarding rules, uma por nome de domínio, que dizem "consultas por corp.internal vão para estes endereços IP".
• Um inbound endpoint aceita consultas para dentro da VPC, vindas da sua rede. Você passa os endereços IP dele ao resolver on-premises como conditional forwarder.

Um endpoint é um conjunto de elastic network interfaces colocadas em sub-redes que você escolhe, então ele consome endereços privados da sua VPC. Duas consequências saem daí:

• Os endereços IP de um outbound endpoint são privados, então a consulta só alcança o seu data center por Direct Connect, uma Site-to-Site VPN ou um NAT gateway. Não existe caminho público.
• Todo endereço IP de destino em uma rule precisa ser alcançável a partir das sub-redes do endpoint. Quando o Resolver encaminha uma consulta ele escolhe um IP de destino ao acaso, sem preferência, e tenta outro destino aleatório se o primeiro não responder. Um destino inalcançável em uma lista de 3 produz então resolução lenta intermitente, e não uma falha limpa.

aws route53resolver create-resolver-endpoint \
  --name outbound-to-datacenter \
  --direction OUTBOUND \
  --security-group-ids sg-0a1b2c3d4e5f6a7b8 \
  --ip-addresses SubnetId=subnet-0aaa,SubnetId=subnet-0bbb

aws route53resolver create-resolver-rule \
  --name forward-corp-internal \
  --rule-type FORWARD \
  --domain-name corp.internal \
  --resolver-endpoint-id rslvr-out-0123456789abcdef0 \
  --target-ips Ip=192.168.10.53,Port=53 Ip=192.168.20.53,Port=53

Uma rule não faz nada até você associar a uma VPC. Rules são recursos por região e podem ser compartilhadas com outras contas pelo AWS RAM, que é o padrão usual: uma conta de rede é dona do outbound endpoint e das rules, e cada conta de workload associa as rules compartilhadas às VPCs dela.

Quando uma rule e uma private hosted zone discordam

Você tem uma private hosted zone para corp.internal e alguém adiciona uma forwarding rule para corp.internal na mesma VPC. Qual responde?

A Resolver rule ganha. As consultas são encaminhadas para a sua rede, e os registros que estão na private hosted zone nunca são consultados.

Vale dizer isso em voz alta porque a falha é invisível no console do Route 53: a zona está lá, os registros estão lá, a associação está lá, e nada disso é usado. Se você precisa dos 2, limite a rule a um nome mais estreito que o da zona, ou remova a associação.

Query logging: 2 logs diferentes

A skill 5.2.2 cita query logging diretamente, e existem 2 recursos separados com a mesma palavra no nome. Escolher o errado joga fora uma investigação.

Uma entrada de log de consulta pública se parece com isto:

1.0 2026-08-11T08:16:02.130Z Z123412341234 example.com A NOERROR UDP DFW3 192.0.2.10 198.51.100.0/24

Versão, timestamp, ID da hosted zone, nome consultado, tipo consultado, código de resposta, protocolo de camada 4, edge location, IP do resolver, EDNS client subnet.

Os 2 logs são moldados pelo cache, e os 2 contam a menos pelo mesmo motivo. Os logs públicos perdem tudo o que um resolver mais abaixo serviu do próprio cache. Os logs do Resolver registram apenas consultas únicas: se uma instância perguntar por accounting.example.com 2 vezes dentro do TTL de cache do VPC Resolver, a segunda consulta nunca aparece. Ler qualquer um dos 2 como contador de requisições vai enganar você.

Cotas que vale guardar

Dicas para a prova

• "Apontar o ápice para um load balancer, uma distribuição do CloudFront ou um bucket S3 de site" é sempre registro alias. CNAME no ápice nunca é resposta válida.
• Consultas alias a recursos da AWS são gratuitas; consultas a CNAME são cobradas, e um CNAME apontando para outro registro do Route 53 é cobrado 2 vezes. Questões de DNS com sabor de custo quase sempre terminam em alias.
• Uma private hosted zone que não resolve nada significa enableDnsSupport e enableDnsHostnames. Cheque isso antes de qualquer outra coisa.
• "Funciona em todo lugar menos dentro da VPC, e o nome é subdomínio de uma private hosted zone" é a armadilha do NXDOMAIN. Não existe queda para o DNS público.
• Inbound e outbound são nomeados da perspectiva da VPC. Clientes on-premises resolvendo nomes da AWS precisam de um endpoint inbound. Instâncias na AWS resolvendo nomes on-premises precisam de um endpoint outbound mais uma forwarding rule.
• Uma Resolver rule ganha de uma private hosted zone para o mesmo nome de domínio.
• Query logging público é só us-east-1 e cobre public hosted zones. Atribuir uma consulta a uma instância exige query logging do Resolver.
• VPC+2 é o endereço do resolver. VPC+1 é o router. Servidores DNS próprios encaminham para o +2.

A regra para levar: antes de investigar um registro, descubra qual resolver respondeu. Uma private hosted zone, uma Resolver rule e o DNS público reivindicam nomes, ganham nessa ordem inversa (rule, depois zona, depois público) e nenhum deles cai para o seguinte depois de reivindicar o namespace. Com isso resolvido, a próxima lição troca a pergunta de quem responde por qual das várias respostas você recebe, que é o que as políticas de roteamento decidem.