DNS híbrido con Route 53 Resolver

Una VPC resuelve nombres desde el primer minuto, sin que configures nada. El reto llega cuando hay una oficina con su propio DNS, por ejemplo el de Active Directory, y decenas de cuentas de AWS. Los servidores de la oficina deben encontrar api.interno.ejemplo.com en AWS, y las instancias de AWS deben encontrar erp.corp.ejemplo.com en la oficina.

Cómo resuelve nombres una VPC

Cada VPC trae un resolvedor de DNS integrado en cada zona de disponibilidad: el Route 53 Resolver. En la documentación reciente se llama Route 53 VPC Resolver. Responde en la dirección base del CIDR primario de la VPC más dos (en 10.0.0.0/16 es 10.0.0.2), en 169.254.169.253 y en fd00:ec2::253 para IPv6. Ante cada consulta decide así:

• Busca la coincidencia más específica entre las reglas de reenvío y las zonas alojadas privadas asociadas a la VPC: dev.ejemplo.com le gana a ejemplo.com.
• Si una regla y una zona tienen exactamente el mismo dominio, gana la regla y la consulta se va a otro DNS.
• Si nada coincide, hace la resolución recursiva pública en internet.

Dos atributos de la VPC controlan todo esto. enableDnsSupport activa el Resolver y viene en true. enableDnsHostnames da nombres DNS públicos a instancias con IP pública y viene en false, salvo en la VPC por defecto. Para zonas privadas y para el DNS privado de los endpoints de interfaz necesitas los dos en true.

Zonas privadas y horizonte dividido

Una zona alojada privada solo responde dentro de las VPC asociadas, que pueden estar en varias regiones. También puedes asociar VPC de otras cuentas. Eso no se hace desde la consola: la cuenta dueña de la zona autoriza la VPC y la cuenta dueña de la VPC completa la asociación.

# 1. En la cuenta dueña de la zona privada: autoriza la VPC de la otra cuenta
aws route53 create-vpc-association-authorization \
  --hosted-zone-id Z0123456789EXAMPLE \
  --vpc VPCRegion=us-east-1,VPCId=vpc-0abc1234def567890

# 2. En la cuenta dueña de la VPC: asocia la VPC con la zona
aws route53 associate-vpc-with-hosted-zone \
  --hosted-zone-id Z0123456789EXAMPLE \
  --vpc VPCRegion=us-east-1,VPCId=vpc-0abc1234def567890

# 3. De vuelta en la cuenta de la zona: borra la autorización (ya no hace falta)
aws route53 delete-vpc-association-authorization \
  --hosted-zone-id Z0123456789EXAMPLE \
  --vpc VPCRegion=us-east-1,VPCId=vpc-0abc1234def567890

El horizonte dividido (split-horizon o split-view DNS) usa el mismo nombre en dos zonas: una pública para internet y una privada para tus VPC. Desde internet, portal.ejemplo.com lleva al balanceador público; desde la VPC, al balanceador interno. Mismo nombre, dos respuestas según quién pregunta.

Endpoints de entrada y de salida

Las centralitas son Resolver endpoints: interfaces de red dentro de tu VPC. Cada endpoint usa al menos dos direcciones IP, en zonas de disponibilidad distintas, y lleva un Security Group que debe permitir DNS (puerto 53 por UDP y TCP).

Así queda el DNS en ambos sentidos entre la oficina y AWS:

1. 1

   Revisa la conectividad

   La VPC donde vivirán los endpoints debe llegar a la oficina por VPN o Direct Connect, con rutas de ida y de vuelta, y los firewalls de la oficina deben permitir el puerto 53.
2. 2

   Crea el endpoint de entrada

   Dos IP en dos zonas de disponibilidad. Anota esas IP: son las que configurará el equipo de la oficina.
3. 3

   Configura el reenvío condicional en la oficina

   En el DNS de la oficina, reenvía interno.ejemplo.com (tus zonas privadas) a las IP del endpoint de entrada. Asocia esa VPC a las zonas privadas que la oficina debe ver.
4. 4

   Crea el endpoint de salida

   También con dos IP en dos zonas. Su Security Group debe permitir la salida al puerto 53 de los DNS de la oficina.
5. 5

   Crea la regla de reenvío

   Dominio corp.ejemplo.com → IP de los DNS de la oficina, a través del endpoint de salida. Asóciala a las VPC que deben resolver esos nombres.
6. 6

   Prueba en ambos sentidos

   Desde una instancia, consulta erp.corp.ejemplo.com. Desde un equipo de la oficina, consulta api.interno.ejemplo.com. Activa Resolver query logging para ver qué regla atendió cada consulta.

DNS centralizado en una cuenta de red

Con muchas cuentas no conviene repetir endpoints en cada VPC. El patrón habitual es una VPC de servicios compartidos en la cuenta de red, conectada a las demás por Transit Gateway. Allí viven los endpoints de entrada y de salida.

• Hacia la oficina: compartes las reglas de reenvío con AWS RAM (Resource Access Manager). Cada cuenta las asocia a sus VPC y las consultas salen por el endpoint de salida central. Las VPC de las cuentas no necesitan su propio endpoint.
• Desde la oficina: la oficina reenvía todo a los endpoints de entrada centrales. La VPC central debe estar asociada a cada zona privada que la oficina tenga que resolver, también a las de otras cuentas.
• Route 53 Profiles agrupa zonas privadas, reglas de Resolver y grupos de reglas de DNS Firewall en un solo paquete que compartes con RAM. Cada VPC admite un Profile; al actualizarlo, el cambio llega a todas las VPC asociadas.

Route 53 Resolver DNS Firewall filtra las consultas que salen de tus VPC. Usas listas de dominios, propias o administradas por AWS, con acciones de permitir, bloquear o solo alertar. Sirve para cortar dominios de malware y la exfiltración de datos por DNS, y se reparte a todas las cuentas con Firewall Manager o con un Profile. Lo vuelves a ver en Inspección de tráfico.

Repasa los tipos de zona y de registro en Route 53 y la conectividad con la oficina en Conectar redes. El reparto de cuentas está en Organizaciones de cuentas.