Introducción#
Las organizaciones con entornos híbridos se enfrentan a un reto recurrente: ¿cómo resuelven las oficinas, data centers y trabajadores remotos los registros DNS privados alojados en Route 53 Private Hosted Zones? La respuesta tradicional pasa por túneles VPN o Direct Connect, Resolver Endpoints en cada región, conditional forwarders y estrategias de failover manuales. Funciona, pero la carga operativa escala mal.
En marzo de 2026, AWS lanzó Route 53 Global Resolver — un resolver DNS gestionado, accesible desde internet, que proporciona resolución autenticada de dominios públicos y privados a través de direcciones IP anycast globales. Sin VPN. Sin Resolver Endpoints que gestionar por región. Sin failover manual.
En este artículo veremos qué problema resuelve Global Resolver, cómo funciona por dentro, y desplegaremos una demo hands-on que resuelve una Private Hosted Zone desde una máquina on-premises usando únicamente un comando dig sobre internet público.
El problema: el DNS híbrido es complejo#
El enfoque clásico#
Para resolver Route 53 Private Hosted Zones desde on-premises, la arquitectura tradicional tiene este aspecto:
Por cada región de AWS donde necesites resolución DNS, despliegas:
- Una conexión VPN o Direct Connect desde cada oficina a la VPC
- Un Inbound Resolver Endpoint (mínimo 2 ENIs) para aceptar queries desde on-premises
- Un conditional forwarder en el servidor DNS on-premises apuntando los dominios privados a las IPs del inbound endpoint
- Reglas de DNS Firewall para filtrar queries maliciosas (por VPC)
- Asociación cross-account de PHZs vía RAM para que la VPC del resolver pueda acceder a las hosted zones de las cuentas de workload
Para alta disponibilidad entre regiones, replicas toda esta infraestructura e implementas tu propia lógica de failover — típicamente haciendo health-checks a los Resolver Endpoints y actualizando los forwarders on-premises de forma manual o mediante automatización.
Puntos de dolor#
Esta arquitectura tiene problemas operativos bien conocidos:
- Complejidad a escala: Los conditional forwarders deben configurarse en cada oficina, las PHZs compartirse cross-account vía RAM, y las reglas de DNS Firewall duplicarse entre VPCs.
- Failover manual: Si una región deja de estar disponible, la resolución DNS se rompe hasta que rediriges el tráfico a los endpoints de otra región.
- Coste acumulativo: Cada ENI cuesta $0.125/hora. Un setup mínimo de dos regiones con inbound endpoints requiere 4 ENIs — unos $360/mes solo en endpoints, sin contar VPN o Direct Connect.
- Seguridad fragmentada: Las reglas de DNS Firewall están limitadas a VPCs individuales. Mantener políticas consistentes entre múltiples VPCs y regiones requiere una orquestación cuidadosa.
- Sin soporte para trabajadores remotos: Los usuarios fuera de la red corporativa necesitan una conexión VPN completa solo para resolver nombres DNS internos.
Route 53 Global Resolver: cómo funciona#
Arquitectura core#
Route 53 Global Resolver adopta un enfoque fundamentalmente diferente. En lugar de requerir conectividad privada para alcanzar Resolver Endpoints dentro de una VPC, expone un conjunto de direcciones IPv4 anycast globales en internet público que cualquier cliente autenticado puede consultar directamente.
Las propiedades arquitectónicas clave:
- Servicio global, presencia regional: Seleccionas al menos 2 regiones de AWS para el resolver. El routing anycast dirige automáticamente cada query a la región sana más cercana.
- Failover automático: Si una región deja de estar disponible, las queries se redirigen de forma transparente a la siguiente región más cercana. Los clientes no necesitan cambiar nada.
- API en us-east-2: Todas las operaciones de gestión (crear, actualizar, eliminar) van a través de la región de Ohio, independientemente de dónde opere el resolver. Es similar a cómo las distribuciones de CloudFront se gestionan desde us-east-1.
- Resolución split-horizon: El mismo resolver maneja tanto dominios públicos de internet (vía resolución recursiva) como dominios privados (vía Private Hosted Zones asociadas).
Componentes clave#
Veamos los componentes que conforman Global Resolver:
| Componente | Propósito |
|---|---|
| Global Resolver | La instancia principal. Define en qué regiones se despliega y el tipo de dirección IP (IPv4 o dual-stack). |
| DNS View | Una agrupación lógica de clientes con su propia autenticación, reglas de firewall y asociaciones de hosted zones. Piensa en ella como un contenedor de políticas. |
| Access Source | Una allowlist de IP/CIDR vinculada a una DNS view. Define quién puede consultar y qué protocolo usa (Do53, DoH o DoT). |
| Access Token | Autenticación basada en tokens para clientes DoH y DoT. Soporta expiración y revocación. |
| Firewall Rules | Filtrado DNS usando listas de dominios custom, AWS Managed Domain Lists, o detección avanzada de amenazas (DGA, DNS tunneling). |
| Hosted Zone Association | Vincula una Private Hosted Zone a una DNS view, permitiendo al resolver responder queries para esa zona. |
La autenticación es obligatoria#
A diferencia de un resolver DNS tradicional, Global Resolver requiere que cada cliente se autentique. Hay dos mecanismos:
- Access Sources (allowlists IP/CIDR): Compatible con todos los protocolos — Do53 (UDP puerto 53), DoT (puerto 853) y DoH (puerto 443). Registras los rangos de IPs públicas de tus oficinas o data centers.
- Access Tokens: Solo para DoH y DoT. Generas tokens con periodos de expiración configurables y los distribuyes a los clientes. Los tokens se pueden revocar en cualquier momento.
Esto significa que no puedes exponer accidentalmente tu DNS privado a internet — solo los clientes explícitamente autorizados reciben respuestas.
DNS Firewall integrado#
Global Resolver incluye capacidades de DNS Firewall equivalentes a lo que Route 53 Resolver DNS Firewall ofrece para VPCs, pero aplicadas globalmente a todos los clientes:
- AWS Managed Domain Lists: Listas de threat intelligence pre-construidas que cubren malware, phishing, botnets, spam y feeds de GuardDuty. También hay categorías de contenido (redes sociales, gambling).
- Listas de dominios custom: Tus propias listas de bloqueo/permiso, inline o importadas desde S3.
- Detección avanzada de amenazas: Análisis algorítmico que detecta DNS tunneling y Domain Generation Algorithms (DGA) en tiempo real, sin depender de listas de dominios conocidos.
- Acciones: Cada regla puede ALLOW, BLOCK (con NODATA, NXDOMAIN o override custom) o ALERT (log y dejar pasar).
DNS split-horizon#
Cuando llega una query, Global Resolver comprueba si el dominio coincide con alguna Private Hosted Zone asociada a la DNS view del cliente:
- Dominio privado → resuelve desde la PHZ asociada
- Dominio público → realiza resolución recursiva estándar contra nameservers públicos, con validación DNSSEC opcional
Esto elimina la necesidad de infraestructura de forwarding separada para manejar la división entre resolución privada y pública.
Demo: resolviendo dominios privados desde on-premises#
Vamos a desplegar un Global Resolver funcional y a verificar que podemos resolver una Private Hosted Zone desde una máquina on-premises a través de internet público — sin VPN, sin Direct Connect, sin Resolver Endpoints.
Qué vamos a construir#
El template de CloudFormation despliega:
- Una Private Hosted Zone (
demo.internal) con dos registros A - Un Global Resolver operando en eu-west-1 y eu-central-1
- Una DNS View con validación DNSSEC y EDNS Client Subnet habilitados
- Un Access Source permitiendo nuestra IP pública consultar vía Do53
- Una Firewall Rule bloqueando dominios de test de malware
- Una Hosted Zone Association vinculando la PHZ a la DNS view
Template de CloudFormation#
Puedes acceder al template completo aquí:
El template despliega todos los recursos en un único stack apuntando a us-east-2. Usa tres parámetros:
| Parámetro | Descripción | Default |
|---|---|---|
AllowedCidr | Tu IP pública en notación CIDR | (obligatorio) |
ResolverRegions | Las dos regiones para el resolver | eu-west-1,eu-central-1 |
PrivateZoneName | Dominio para la Private Hosted Zone | demo.internal |
Despliegue#
Primero, determina tu dirección IP pública. Es la IP que Global Resolver usará para autenticar tus queries:
MY_IP=$(curl -s https://ifconfig.me)
echo "My public IP: ${MY_IP}"
Ahora despliega el stack. Ten en cuenta que hay que apuntar a us-east-2 — es donde vive el plano de control de Global Resolver, independientemente de en qué regiones opere el resolver:
aws cloudformation deploy \
--template-file template.yaml \
--stack-name route53-global-resolver-demo \
--parameter-overrides AllowedCidr="${MY_IP}/32" \
--region us-east-2
El despliegue tarda aproximadamente 3-5 minutos. Una vez completado, obtén las direcciones IP anycast asignadas a tu resolver:
aws cloudformation describe-stacks \
--stack-name route53-global-resolver-demo \
--region us-east-2 \
--query 'Stacks[0].Outputs[?OutputKey==`AnycastIPv4Addresses`].OutputValue' \
--output text
Obtendrás dos direcciones IPv4 — son las IPs anycast globales que configurarías en tus clientes DNS on-premises. Ambas direcciones apuntan al mismo resolver; tener dos proporciona redundancia en el lado del cliente.
Verificación#
Con las IPs anycast de los outputs del stack, podemos probar la resolución desde nuestra máquina on-premises. Sin VPN, sin Direct Connect — solo queries DNS estándar sobre internet público.
Resolver un dominio privado:
$ dig @15.197.252.50 app.demo.internal +short
10.0.1.50
$ dig @15.197.252.50 db.demo.internal +short
10.0.2.30
Este es el resultado clave: nuestra máquina on-premises resuelve registros de una Route 53 Private Hosted Zone — a través de internet público, autenticada únicamente por nuestra dirección IP de origen. Sin túnel VPN, sin enlace Direct Connect, sin Resolver Endpoints.
Resolver un dominio público:
$ dig @15.197.252.50 google.com +short
172.217.20.238
La resolución DNS pública funciona de forma transparente a través del mismo resolver. Este es el comportamiento split-horizon en acción — los dominios privados se resuelven desde la PHZ asociada, todo lo demás pasa por resolución recursiva estándar.
Probar el bloqueo del firewall:
$ dig @15.197.252.50 malware-test.demo.invalid +short
(respuesta vacía - NODATA)
La regla de firewall intercepta la query y devuelve una respuesta vacía (NODATA), impidiendo la resolución de dominios en nuestra lista de bloqueo. En producción, usarías AWS Managed Domain Lists para bloquear dominios conocidos de malware, phishing y botnets sin mantener tus propias listas.
Verificar que ambas IPs anycast funcionan:
$ dig @99.83.237.198 app.demo.internal +short
10.0.1.50
Ambas direcciones anycast enrutan al resolver y devuelven resultados idénticos. Si una región deja de estar disponible, el tráfico hace failover automáticamente a la otra — los clientes no necesitan cambiar su configuración DNS.
Limpieza#
aws cloudformation delete-stack \
--stack-name route53-global-resolver-demo \
--region us-east-2
aws cloudformation wait stack-delete-complete \
--stack-name route53-global-resolver-demo \
--region us-east-2
VPC Resolver vs. Global Resolver: cuándo usar cada uno#
Con el lanzamiento de Global Resolver, AWS renombró el servicio existente a Route 53 VPC Resolver para clarificar la distinción. Son servicios complementarios — no competidores. Veamos cuándo tiene sentido usar cada uno.
| Aspecto | VPC Resolver | Global Resolver |
|---|---|---|
| Conectividad | VPN/Direct Connect requerido | Internet público (autenticado) |
| Configuración | Inbound Endpoints + conditional forwarders | DNS Views (global, por grupo de clientes) |
| Seguridad DNS | DNS Firewall por VPC | Firewall integrado (global) |
| Failover | Manual, multi-región | Automático (anycast) |
| Acceso a PHZs | Solo desde VPCs asociadas | Desde cualquier lugar (autenticado) |
| Protocolos | Do53 (DoH en endpoints) | Do53, DoH, DoT |
| Autenticación | Red privada (VPN/DX) | IP allowlist + access tokens |
| Logging | Por VPC, por región | Centralizado (formato OCSF) |
| Coste (2 regiones) | ~$360/mes (4 ENIs) + VPN/DX | ~$3,600/mes (todo incluido) |
Guía de decisión#
Usa VPC Resolver cuando:
- Tus workloads corren dentro de VPCs y necesitan resolver dominios tanto de AWS como de on-premises
- Ya tienes conectividad VPN o Direct Connect
- Necesitas reenviar queries a servidores DNS on-premises (resolución outbound)
- El coste es una prioridad y tu arquitectura DNS es sencilla
Usa Global Resolver cuando:
- Tienes clientes fuera de AWS (oficinas, data centers, trabajadores remotos) que necesitan resolver dominios privados
- Quieres eliminar dependencias de VPN para la resolución DNS
- Necesitas failover multi-región automático sin automatización custom
- Quieres políticas de seguridad DNS centralizadas en todas las ubicaciones de clientes
- Necesitas DNS cifrado (DoH/DoT) para clientes en redes no confiables
Usa ambos juntos:
La mayoría de arquitecturas enterprise usarán VPC Resolver para workloads cloud-native dentro de VPCs y Global Resolver para todo lo externo. Los dos servicios operan de forma independiente y se complementan.
Consideraciones y limitaciones#
Antes de adoptar Global Resolver, conviene tener en cuenta estos trade-offs:
Coste: Con ~$3,600/mes para un despliegue de dos regiones con DNS filtering, Global Resolver es una inversión significativa. Se justifica cuando reemplaza múltiples túneles VPN, Resolver Endpoints en varias regiones, y la carga operativa de gestionar el failover — pero haz las cuentas del TCO para tu entorno específico.
Región de la API de gestión: Todas las operaciones del plano de control van a través de us-east-2 (Ohio). Si esa región tiene problemas, no puedes crear ni modificar recursos del resolver. Sin embargo, el plano de datos (la resolución DNS real) sigue operando en tus regiones configuradas de forma independiente.
Infrastructure as Code: A abril de 2026, el provider de Terraform para AWS no tiene recursos nativos para Global Resolver. CloudFormation tiene soporte completo, CDK ofrece constructs L1, y el provider awscc de Terraform funciona vía Cloud Control API. Planifica tu estrategia de IaC en consecuencia.
Cambiar regiones requiere replacement: Modificar la propiedad Regions de un Global Resolver dispara un replacement completo (eliminar + recrear). Planifica la selección de regiones con cuidado en el momento del despliegue.
Quotas: Los límites por defecto incluyen 2 resolvers por cuenta, 5 DNS views por resolver y 1.000 access sources por resolver. Son ajustables a través de Service Quotas.
No reemplaza a VPC Resolver: Los workloads dentro de VPCs siguen usando VPC Resolver para su resolución DNS. Global Resolver está dirigido a clientes fuera del perímetro de la VPC.
Regiones opt-in: Si quieres desplegar el resolver en regiones opt-in (como eu-south-2 o ap-southeast-3), la cuenta debe tener esas regiones habilitadas previamente.
Conclusión#
Route 53 Global Resolver aborda un punto de dolor histórico en las arquitecturas DNS híbridas: resolver dominios privados desde fuera de AWS sin la complejidad de túneles VPN y Resolver Endpoints regionales. Al exponer IPs anycast autenticadas en internet público, convierte lo que antes era un problema de infraestructura multi-componente y multi-región en un único servicio gestionado con failover automático.
El DNS Firewall integrado, el soporte para protocolos cifrados (DoH/DoT) y el logging centralizado lo hacen especialmente atractivo para organizaciones con oficinas distribuidas y trabajadores remotos que necesitan tanto acceso a DNS privado como políticas de seguridad consistentes.
El principal trade-off es el coste. Con ~$3,600/mes para un despliegue básico de dos regiones, no encaja en todos los entornos. Pero para organizaciones que ya gastan en infraestructura VPN, múltiples Resolver Endpoints y el tiempo de ingeniería para mantener el failover DNS — la comparación del coste total de propiedad puede sorprender.
¿Te ha resultado útil este artículo? Suscríbete al boletín y sé el primero en enterarte cuando se publique uno nuevo.
Suscríbete