Simplifique la administración de DNS en un entorno de múltiples cuentas con Amazon Route 53 Resolver

En una publicación anterior, mostré una solución para implementar el DNS centralizado en un entorno de cuentas múltiples, que simplificaba la administración del DNS al reducir la cantidad de servidores y reenviadores necesarios para implementar la resolución de nombres de dominio entre cuentas de AWS (cruce de cuentas) y AWS hacia las premisas.  Con el lanzamiento del servicio Amazon Route 53 Resolver, ahora tiene acceso a un reenviador condicional nativo que simplificará aún más la resolución del DNS híbrido.

En esta publicación, les mostraré una solución modernizada para centralizar la administración de DNS en un entorno de múltiples cuentas de AWS mediante Amazon Route 53 Resolver.  Esta solución les permite resolver dominios entre varias cuentas y cargas de trabajo que se ejecutan en AWS y en el entorno local, sin necesidad de ejecutar un controlador de dominio en AWS.

Descripción general de la solución

Esta solución les mostrará cómo resolver tres casos de uso principales para la resolución de dominios:

• Resolver los nombres de dominio en las premisas con cargas de trabajo que se ejecuten en sus VPC.
• Resolver los nombres de dominio privados en su ambiente de AWS con sus cargas de trabajo ejecutándose en las premisas.
• Resolver los nombres de dominio privados entre cargas de trabajo que se ejecutan en diferentes cuentas de AWS.

El siguiente diagrama explica toda la arquitectura a grandes rasgos.

En esta arquitectura tenemos:

1. Este es el servidor de DNS por defecto que ofrece Amazon para la VPC de DNS centralizado, que denominaremos DNS-VPC.  Esta es la segunda dirección IP en el rango CIDR de la VPC (como se muestra, es 172.27.0.2).  Este servidor de DNS por defecto será el principal encargado de resolver los nombres de dominio para todas las cargas de trabajo que se ejecuten en las cuentas de AWS participantes.
2. Aquí se muestran los puntos de enlace de Route 53 Resolver.  El endpoint entrante recibirá las consultas reenviadas de los servidores de DNS en premisas  y de las cargas de trabajo que se ejecuten en las cuentas de AWS participantes.  El punto de enlace de salida de Resolver se utilizará para reenviar las consultas de nombres de dominio desde AWS al servidor de DNS en premisas.
3. Esta muestra las reglas de reenvío condicional.  Para esta arquitectura, necesitamos dos reglas: una para reenviar las consultas de nombres de dominio desde la zonaonprem.private al servidor de DNS en premisas a través del punto de enlace de salida, y una segunda regla para reenviar las consultas de nombres de dominio desdeawscloud.private para el punto de enlace entrante de Resolver en la DNS-VPC.
4. Esto indica que estas dos reglas de reenvío son compartidas con todas las demás cuentas de AWS a través del AWS Resource Access Manager y están asociadas a todas las VPC en estas cuentas.
5. Aquí se muestra la zona alojada privada, creada en cada cuenta con un subdominio único de awscloud.private.
6. Esto muestra el servidor de DNS en premisas con reenviadores condicionales configurados para reenviar las consultas a la zona awscloud.private a las direcciones IP del punto de enlace entrante de Resolver.

Nota: Esta solución no requiere interconexión de VPC ni conectividad entre las VPC de origen/destino y DNS-VPC.

¿Cómo funciona?

Ahora, voy a mostrarles cómo funciona el flujo de resolución de nombres de dominio de la arquitectura, según los tres casos de uso en los que nos centramos.

Primer caso de uso

En primer lugar, analizaremos la resolución de nombres de dominio en premisas con cargas de trabajo que se ejecutan en AWS.  Si el servidor con el dominio privadohost1.acc1.awscloud.private intenta resolver la dirección host1.onprem.private, esto es lo que ocurre:

1. La consulta DNS se dirigirá al servidor DNS predeterminado de la VPC que aloja host1.acc1.awscloud.private.
2. Como la VPC está asociada a las reglas de reenvío compartidas de la cuenta de DNS central, esas reglas se evaluarán mediante el Amazon DNS por defecto que se proporciona en la VPC.
3. En este ejemplo, una de las reglas establece que las consultas deonprem.private deben reenviarse a un servidor de DNS en premisas.  Siguiendo esta regla, la consulta se reenviará a un servidor de DNS en premisas.
4. La regla de reenvío está asociada al punto de enlace de salida de Resolver, por lo que la consulta se reenviará a través de ese punto de enlace al servidor de DNS en premisas.

En este flujo, la consulta de DNS que se inició en una de las cuentas participantes se reenvió al servidor DNS centralizado, que a su vez la reenvió al DNS en premisas.

Segundo caso de uso

A continuación, veamos cómo las cargas de trabajo en premisas podrán resolver los nombres de dominio privados en su entorno de AWS:

En este caso, la consulta dehost1.acc1.awscloud.private se inicia desde un host en premisas.  Vea lo que sucede a continuación:

1. La consulta de nombre de dominio se reenvía al servidor DNS en premisas.
2. A continuación, la consulta se reenvía al punto de enlace entrante de Resolver, mediante una regla condicional de reenvío en el servidor DNS en premisas.
3. La consulta llega al servidor de DNS predeterminado para DNS-VPC.
4. Como la DNS-VPC está asociada a la zona alojada privadaacc1.awscloud.private, el servidor de  DNS predeterminado podrá resolver este nombre de dominio.

En este caso, la consulta de DNS se inició en premisas y se reenvió al DNS centralizado del lado de AWS a través del punto de enlace entrante.

Tercer caso de uso

Por último, es posible que deba resolver los nombres de dominio en varias cuentas de AWS.  Esto es posible de la siguiente manera:

Supongamos que host1 enhost1.acc1.awscloud.private intenta resolver el nombre de dominiohost2.acc2.awscloud.private.  Sucederá lo siguiente:

1. La consulta de nombre de dominio se envía al servidor DNS predeterminado de la máquina de origen donde se encuentra la VPC (host1).
2. Como la VPC está asociada a las reglas de reenvío compartidas, esas reglas se evaluarán.
3. Una regla establece que las consultas de la zonaawscloud.private deben reenviarse a los puntos de enlace entrantes (a través del punto de enlace de salida) de la DNS-VPC.
4. A continuación, el punto de enlace de salida reenvía la consulta de DNS a las IP de destino.  En este ejemplo, las IP de destino son las direcciones IP del punto de enlace entrante.
5. Como la DNS-VPC está asociada a la zona alojadaacc2.awscloud.private, el DNS predeterminado utilizará reglas definidas automáticamente para resolver este dominio.

Este caso de uso explica el escenario de resolución de nombres DNS entre cuentas de AWS, en el que la consulta de DNS se inició en una cuenta participante y se reenvió al DNS central para la resolución del nombre de dominio en otra cuenta de AWS.  Ahora, veamos lo que se necesita para crear esta solución en su ambiente.

Cómo implementar la solución

Le mostraremos cómo configurar esta solución en cuatro pasos:

1. Configure una cuenta DNS centralizada.
2. Configure cada cuenta de AWS participante.
3. Cree zonas alojadas privadas y asociaciones de Route 53.
4. Configure los reenviadores de DNS en premisas.

Paso 1: Configurar una cuenta DNS centralizada

En este paso, configurará los recursos en la cuenta DNS centralizada.  Inicialmente, esto incluye la DNS-VPC, los puntos de enlace de Resolver y las reglas de reenvío.

1. 1. Cree una VPC que actúe como DNS-VPC, según su situación empresarial, mediante la consola web o un AWS Quick Start.  Puede revisar los escenarios comunes en la guía del usuario de Amazon VPC; un escenario muy común es una VPC con subredes públicas y privadas.
   2. Cree puntos de enlace en Route 53 Resolver.  Debe crear un punto de enlace de salida para reenviar las consultas de DNS al DNS en premisas y un punto de enlace de entrada para recibir las consultas de DNS reenviadas de las cargas de trabajo en premisas y otras cuentas de AWS.
   3. Crea dos reglas de reenvío.  La primera regla consistirá en reenviar las consultas de DNS a la zona onprem.private y a las direcciones IP del servidor DNS en premisas; y la segunda regla consiste en reenviar las consultas al DNS y a la zona awscloud.private a las direcciones IP del punto de enlace Resolver entrante  .
   4. Tras crear las reglas, asocie la regla onprem.private zone a la DNS-VPC creada en el paso 1 (no necesita asociar la otra regla de reenvío a la DNS-VPC).  Esto permitirá que Route 53 Resolver comience a reenviar las consultas de dominio acordemente.
   5. Por último, debes compartir las dos reglas de recomendación con todas las cuentas participantes.  Para ello, utilizarás AWS Resource Access Manager y podrás compartir las reglas con la organización de AWS completa o con cuentas específicas. share the two forwarding rules with all participating accounts. To do that, you’ll use AWS Resource Access Manager and you can share the rules with your entire AWS Organization or with specific accounts.

Nota: Para poder reenviar las consultas de dominio a su servidor DNS en premisas, necesitas conectividad entre el centro de datos y la DNS-VPC, que se puede establecer mediante una VPN de sitio a sitio o AWS Direct Connect.

Paso 2: Configurar las cuentas participantes

Para cada cuenta participante, debes configurar las VPC para que usen reglas de enrutamiento compartidas y crear una zona alojada privada para cada cuenta.

• Acepta las reglas compartidas desde AWS Resource Access Manager.  Este paso no es necesario si las reglas se compartieron a su AWS Organization.  A continuación, asocie las reglas de reenvío a las VPC que alojan las cargas de trabajo en cada cuenta.  Una vez asociado, Resolver comenzará a reenviar las consultas de DNS de acuerdo con las reglas

En ese momento, deberías poder resolver los nombres de dominio en premisas de las cargas de trabajo que se ejecuten en cualquier VPC asociada a las reglas de reenvío compartidas.  Para crear dominios privados en AWS, debe crear zonas alojadas privadas.

Paso 3: Crear zonas alojadas privadas

En este paso, debes crear una zona alojada privada en cada cuenta con un subdominio deawscloud.private.  Utilice nombres únicos para cada zona alojada privada para evitar conflictos de dominio en su entorno (por ejemplo,acc1.awscloud.private odev.awscloud.private).

1. Cree una zona alojada en cada cuenta participante con un subdominio de awscloud.private y asóciela a las VPC que se ejecutan en esa cuenta.
2. Conecte la zona alojada privada a la DNS-VPC.  Esto permite que la DNS-VPC centralizada resuelva los dominios de zonas alojadas privadas y resuelva las consultas de  DNS entre las cuentas de AWS.

Dado que la zona alojada privada y la DNS-VPC están en cuentas diferentes, debe asociar la zona alojada privada a DNS-VPC.  Para ello, debes crear una autorización desde la cuenta que tiene la zona alojada privada y aceptar esa autorización en la cuenta propietaria de la DNS-VPC.  Puedes hacerlo mediante la CLI de AWS:

1. En cada cuenta participante, cree la autorización con el ID de zona alojada privada, la región y el ID de la VPC que desea asociar (DNS- VPC).

   
       aws route53 create-vpc-association-authorization --hosted-zone-id <hosted-zone-id>  --vpc VPCRegion=<region> ,VPCId=<vpc-id>

2. En la cuenta DNS centralizada, asocie la DNS-VPC a la zona alojada de cada cuenta participante.

   
       aws route53 associate-vpc-with-hosted-zone --hosted-zone-id <hosted-zone-id> --vpc VPCRegion=<region>,VPCId=<vpc-id>

Paso 4: Configurar los reenviadores de DNS en premisas

Para poder resolver los subdominios del dominio awscloud.private en las cargas de trabajo que se ejecutan en premisas, debes configurar reglas de reenvío condicional para reenviar las consultas de dominio a las dos direcciones IP de los puntos de enlace de Resolver entrantes que se crearon en la cuenta DNS central.  Ten en cuenta que esto requiere conectividad entre el centro de datos y la DNS-VPC, que se puede establecer mediante una VPN de sitio a sitio o AWS Direct Connect.

Consideraciones y limitaciones adicionales

Gracias a la flexibilidad de Amazon Route 53 Resolver y a las reglas de reenvío condicional, puedes controlar qué consultas enviar al DNS central y cuáles resolver localmente dentro de la misma cuenta.  Esto es especialmente importante si tienes previsto utilizar algunos servicios de AWS, como AWS PrivateLink o  Elastic File System (EFS), ya que los nombres de dominio asociados a estos servicios deben resolverse localmente dentro de la misma cuenta.

Le recomendamos que resuelva los dominios locales de la cuenta siempre que sea posible; por ejemplo, para los dominios privados en  las zonas alojadas privadas en la misma cuenta.  Para ello, puedes crear reglas de reenvío condicionales para la cuenta, utiliza «system» para el tipo de regla y asocia esas reglas a sus VPC.

Nota sobre los límites de Route 53 Resolver: Route 53 Resolver tiene un límite de 10 000 consultas por segundo por dirección IP en un punto de enlace.  Si tienes una carga de trabajo que requiere límites más altos, considera la posibilidad de reenviar esas consultas a un servidor DNS local correctamente configurado que se ejecute en una instancia de EC2.  Obtén más información sobre los límites de servicio aquí.

En esta sección, citaré dos casos de uso que requieren consideraciones adicionales.

1. Interfaz de endpoints (puntos de enlace) de VPC (AWS PrivateLink)
   Al crear un punto de enlace de la interfaz AWS PrivateLink, AWS genera nombres de host DNS específicos para cada enlace que se puede usar para comunicarse con el servicio.  En el caso de los servicios de AWS y los servicios de socios de AWS Marketplace, tienen la opción de habilitar el DNS privado para el endpoint.  Esta opción asocia una zona alojada privada a tu VPC.  La zona alojada contiene un conjunto de registros para el nombre DNS predeterminado del servicio (por ejemplo,ec2.us-east-1.amazonaws.com) que se resuelven con las direcciones IP privadas de las interfaces de red de los puntos de enlace  de la VPC.  Esto le permite realizar solicitudes al servicio utilizando su nombre de host DNS predeterminado en lugar de los nombres de host DNS específicos del punto de enlace.Si utilizas un DNS privado para tu punto de enlace, tendrás que resolver las consultas de DNS para el punto de enlace local de la cuenta y utilizar el DNS por defecto que proporciona AWS.  En ese caso, te recomiendo que resuelvas las consultas de dominio en amazonaws.com de forma local y que no las reenvíes al DNS central.
2. Configuración de EFS con un nombre DNS
   Puedes configurar un sistema de archivos de Amazon EFS en una instancia de Amazon EC2 utilizando nombres de DNS.  El nombre de DNS del sistema de archivos se resuelve automáticamente en la dirección IP del destino de la configuración en la zona de disponibilidad de la instancia de Amazon EC2 conectada.  Para poder hacerlo, la VPC debe usar el DNS por defecto proporcionado por Amazon para resolver los nombres de DNS de EFS.Si tiene previsto utilizar EFS en su ambiente, te  recomiendo que resuelvas los nombres de DNS de EFS de forma local y evites enviar estas consultas al DNS central, ya que los clientes, en este caso, no recibirían respuestas optimizadas para su zona de disponibilidad, lo que podría provocar latencias operativas más altas y una reducción de la durabilidad.

Resumen

En esta publicación, presentamos una solución simplificada para implementar la resolución de DNS central en un ambiente híbrido de múltiples cuentas.  Esta solución utiliza Amazon Route 53 Resolver, AWS Resource Access Manager y las funciones nativas de Route 53, y reduce la complejidad y el esfuerzo operativo al eliminar la necesidad de servidores de DNS o reenviadores personalizados en el ambiente de AWS.

Acerca del autor