Route 53 DNS y Resolver

Una función Lambda dentro de tu VPC llama a payments.corp.internal y recibe NXDOMAIN. Ese mismo nombre resuelve en 30 milisegundos desde tu laptop por la VPN corporativa. La aplicación no cambió, el registro existe y el DNS "funciona" según cualquier prueba que se te ocurra.

El registro está bien. Lo que cambió es quién respondió. Un nombre dentro de una VPC lo pueden resolver 3 cosas distintas, y no se consultan entre ellas. Saber a dónde va una consulta es casi todo el diagnóstico de Route 53, y es lo que el examen realmente evalúa en esta área.

Hosted zones: el contenedor desde el que responde Route 53

Una hosted zone guarda los registros de un dominio y sus subdominios. Creas una hosted zone para example.com y obtienes un contenedor desde el que Route 53 responderá consultas, más los name servers que vuelven oficial esa respuesta.

Hay 2 tipos, y la diferencia es quién puede preguntar:

• Una public hosted zone responde consultas de internet. Route 53 asigna 4 name servers y apuntas a ellos desde tu registrador de dominios con registros NS. Esa delegación es lo que vuelve a Route 53 autoritativo para el dominio.
• Una private hosted zone responde solo a las VPCs que asocies con ella. No es alcanzable desde internet, y sus registros nunca aparecen en el DNS público.

Las private hosted zones también tienen registros NS, porque el protocolo DNS exige que toda zona los tenga, y siempre son los mismos 4 nombres reservados:

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

Esos nombres son visibles en internet, pero consultarlos directamente no devuelve nada sobre tu zona. El VPC Resolver tampoco los contacta: reconoce que una consulta cae dentro de un namespace privado por la asociación entre la VPC y la hosted zone, y llega a los datos privados directamente. Así que "los name servers son públicos" es cierto e inofensivo.

Registros, TTL y la consulta que nunca ves

Un registro mapea un nombre y un tipo a un valor: www.example.com de tipo A hacia 203.0.113.10. Cada registro lleva un TTL, la cantidad de segundos que un resolver DNS puede guardar la respuesta en caché antes de volver a preguntar.

El TTL es el campo con más peso operativo de un registro, y es fácil subestimarlo. Ponlo en 300 y un resolver que respondió a un cliente a las 10:00:00 va a seguir sirviendo esa misma respuesta hasta las 10:05:00 sin contactar a Route 53. De ahí salen 3 consecuencias que vas a volver a encontrar en este tema:

• Un failover o un cambio de registro no le llega a los clientes existentes hasta que expire su copia en caché.
• Los query logs cuentan de menos el tráfico real, a veces por órdenes de magnitud, porque las respuestas en caché nunca llegan a Route 53.
• Bajar el TTL antes de una migración planificada y subirlo después es la técnica estándar de corte.

Alias records: el atajo que solo existe en AWS

Quieres que example.com llegue a un Application Load Balancer. El load balancer tiene un nombre DNS, no una dirección IP estable, así que un registro A con una dirección fija queda mal el día que AWS reemplaza un nodo. La respuesta obvia es un CNAME, y el protocolo DNS lo prohíbe: no puedes crear un CNAME en el apex de la zona, el nodo más alto del namespace.

Un alias record es la extensión de Route 53 que cierra ese hueco. Para cualquier cliente se ve como un registro A o AAAA, pero su destino es un recurso de AWS que Route 53 resuelve en el momento de la consulta.

Destinos alias que conviene reconocer: load balancers de Elastic Load Balancing (Application, Network y Classic), distribuciones de CloudFront, buckets de S3 configurados como sitio web estático, APIs de API Gateway, interface endpoints de VPC, accelerators de Global Accelerator, entornos de Elastic Beanstalk, servicios de App Runner, nombres de dominio de AppSync, dominios de OpenSearch Service y otro registro del mismo tipo en la misma hosted zone.

Dos puntos prácticos. Los alias records siguen al recurso por su cuenta, así que si cambian las direcciones del load balancer, Route 53 empieza a responder con las nuevas sin que toques nada. Y los alias records pueden activar Evaluate Target Health, que es como una configuración de failover se entera de que un load balancer está caído sin que le crees un health check.

Private hosted zones y los 2 atributos de VPC de los que dependen

Creas una private hosted zone, asocias una VPC y agregas registros. Las instancias de esa VPC ya resuelven esos nombres hacia direcciones privadas.

Falla en silencio si la VPC no está configurada para eso. Estos 2 atributos de la VPC tienen que estar en 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

Una private hosted zone se puede asociar con hasta 300 VPCs, incluso de otras cuentas (la asociación desde otra cuenta es un flujo de 2 pasos: autorizar y después asociar). Pasadas las 300, la herramienta prevista es Route 53 Profiles y no un aumento de cuota.

Los health checks se comportan distinto acá. En una private hosted zone solo puedes adjuntarlos a registros de tipo failover, multivalue answer, weighted, latency, geolocation y geoproximity. El IP-based routing no está soportado en una private hosted zone.

Split-view DNS y la trampa del NXDOMAIN

El split-view DNS (también llamado split-horizon) es el patrón donde el mismo nombre de dominio resuelve distinto adentro y afuera de tu red. Creas una public hosted zone y una private hosted zone con el mismo nombre, asocias la privada con tus VPCs y pones en cada una los registros que le corresponden a su audiencia. Quien llama internamente llega a 10.0.5.20; internet llega a tu distribución de CloudFront.

Acá está la parte que sorprende. Supón que tu private hosted zone es example.com y contiene registros para db.example.com y cache.example.com, pero nada para reports.example.com, que sí existe en el DNS público.

El VPC Resolver evalúa en este orden:

1. ¿Alguna private hosted zone asociada a esta VPC coincide con el nombre consultado? Coincidir significa un nombre idéntico, o un nombre que sea padre del consultado. example.com es padre de reports.example.com, así que sí.
2. Busca en esa zona un registro que coincida en nombre y tipo.
3. No hay coincidencia. Devuelve NXDOMAIN.

No cae de vuelta al DNS público. Una vez que una zona privada reclama el namespace, es dueña del namespace entero dentro de esa VPC. Este es el segundo incidente más común con private hosted zones después de los atributos faltantes, y el síntoma siempre es el mismo: un nombre funciona en todos lados menos dentro de la VPC.

Cuando 2 private hosted zones se superponen, gana la coincidencia más específica. Con zonas para example.com y accounting.example.com las 2 asociadas, una consulta por seattle.accounting.example.com la responde accounting.example.com, y solo esa zona.

El VPC Resolver en VPC+2

Toda VPC tiene un resolver en la base de su CIDR más dos. Una VPC que usa 10.20.0.0/16 tiene su resolver en 10.20.0.2. Esa dirección es una de las 5 que AWS reserva en cada subred, y es a donde las instancias mandan sus consultas DNS salvo que un DHCP options set diga otra cosa.

El VPC Resolver responde 3 categorías:

• Nombres internos de EC2 como ip-10-20-1-15.ec2.internal
• Registros de las private hosted zones asociadas a la VPC
• Nombres públicos, haciendo las búsquedas recursivas contra los name servers públicos por ti

Ese tercer punto importa: las instancias no le hablan al DNS público, la recursión la hace el VPC Resolver. También puede validar DNSSEC en esas respuestas recursivas si habilitas la validación.

Si corres tus propios servidores DNS en instancias EC2, tienen que reenviar a VPC+2 para alcanzar los datos de las private hosted zones. Apuntarlos al router de la VPC (.1) no funciona.

La documentación de AWS ahora llama a este componente Route 53 VPC Resolver; material más viejo y la guía del examen lo llaman Route 53 Resolver. Es lo mismo.

DNS híbrido: inbound y outbound endpoints

El VPC Resolver no sabe nada de corp.internal corriendo en tus servidores de Active Directory on-premises, y tu resolver on-premises no sabe nada de tus private hosted zones. Los endpoints de Resolver conectan los 2 lados, y sus nombres son el par de términos que más se invierte en todo este dominio.

Los 2 nombres están escritos desde el punto de vista de la VPC:

• Un outbound endpoint manda consultas hacia afuera de la VPC, a tu red. Lo emparejas con forwarding rules, una por nombre de dominio, que dicen "las consultas por corp.internal van a estas direcciones IP destino".
• Un inbound endpoint acepta consultas hacia adentro de la VPC, desde tu red. Le das sus direcciones IP a tu resolver on-premises como conditional forwarder.

Un endpoint es un conjunto de interfaces de red elásticas puestas en las subredes que elijas, así que consume direcciones privadas de tu VPC. De ahí salen 2 consecuencias:

• Las direcciones IP de un outbound endpoint son privadas, así que la consulta solo puede llegar a tu data center por Direct Connect, un Site-to-Site VPN o un NAT gateway. No existe un camino público.
• Cada dirección IP destino de una rule tiene que ser alcanzable desde las subredes del endpoint. Cuando Resolver reenvía una consulta elige un destino al azar, sin preferencia, y reintenta contra otro destino al azar si el primero no responde. Un destino inalcanzable en una lista de 3 produce entonces resolución lenta e intermitente, no una falla limpia.

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

Una rule no hace nada hasta que la asocias con una VPC. Las rules son recursos por región y se pueden compartir con otras cuentas por AWS RAM, que es el patrón estándar: una cuenta de red es dueña del outbound endpoint y de las rules, y cada cuenta de workload asocia las rules compartidas con sus VPCs.

Cuando una rule y una private hosted zone se contradicen

Tienes una private hosted zone para corp.internal y alguien agrega una forwarding rule para corp.internal en la misma VPC. ¿Cuál responde?

Gana la Resolver rule. Las consultas se reenvían a tu red, y los registros que están en la private hosted zone no se consultan nunca.

Vale la pena decirlo en voz alta porque la falla es invisible desde la consola de Route 53: la zona está, los registros están, la asociación está, y nada de eso se usa. Si necesitas los 2, acota la rule a un nombre más específico que el de la zona, o quita la asociación.

Query logging: 2 logs distintos

La skill 5.2.2 nombra el query logging directamente, y hay 2 features separadas con la misma palabra en el nombre. Elegir la equivocada desperdicia una investigación entera.

Una entrada del log público se ve así:

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

Versión, timestamp, ID de la hosted zone, nombre consultado, tipo consultado, código de respuesta, protocolo de capa 4, edge location, IP del resolver y EDNS client subnet.

Los 2 logs están moldeados por el caché, y los 2 cuentan de menos por la misma razón. El log público se pierde todo lo que un resolver aguas abajo sirvió desde su propia caché. El Resolver query logging registra solo consultas únicas: si una instancia pregunta 2 veces por accounting.example.com dentro del TTL de caché del VPC Resolver, la segunda búsqueda nunca aparece. Leer cualquiera de los 2 como un contador de solicitudes te va a llevar a conclusiones falsas.

Cuotas que vale la pena recordar

Tips de examen

• "Apuntar el apex a un load balancer, a una distribución de CloudFront o a un bucket de S3 como sitio web" siempre es un alias record. Un CNAME en el apex nunca es respuesta válida.
• Las consultas alias hacia recursos de AWS son gratis; las CNAME se cobran, y un CNAME que apunta a otro registro de Route 53 se cobra doble. Las preguntas de DNS con sabor a costo terminan en alias.
• Una private hosted zone que no resuelve nada significa enableDnsSupport y enableDnsHostnames. Revísalos antes que cualquier otra cosa.
• "Funciona en todos lados menos dentro de la VPC, y el nombre es subdominio de una private hosted zone" es la trampa del NXDOMAIN. No hay fallback al DNS público.
• Inbound y outbound se nombran desde la perspectiva de la VPC. Los clientes on-premises que resuelven nombres de AWS necesitan un endpoint inbound. Las instancias de AWS que resuelven nombres on-premises necesitan un endpoint outbound más una forwarding rule.
• Una Resolver rule le gana a una private hosted zone para el mismo nombre de dominio.
• El query logging público es solo us-east-1 y cubre public hosted zones. Atribuir una búsqueda a una instancia exige Resolver query logging.
• VPC+2 es la dirección del resolver. VPC+1 es el router. Los servidores DNS propios reenvían a la +2.

La regla que hay que llevarse: antes de depurar un registro, averigua qué resolver respondió. Una private hosted zone, una Resolver rule y el DNS público reclaman nombres, ganan en ese orden inverso (primero la rule, después la zona, después el público), y ninguno cae de vuelta al siguiente una vez que reclamó el namespace. Con eso resuelto, la próxima lección cambia la pregunta de quién responde a cuál de varias respuestas te toca, que es lo que deciden las routing policies.