Prácticas recomendadas de Cloud DNS

En este documento se describen las prácticas recomendadas para las zonas privadas, el reenvío de DNS y las arquitecturas de referencia para DNS híbrido.

Tanto para los usuarios como para las aplicaciones, es más fácil usar el sistema de nombres de dominio (DNS) para acceder a aplicaciones y servicios, ya que es más fácil recordar un nombre y es más flexible que usar direcciones IP. En un entorno híbrido que consta de una plataforma local y una o varias plataformas en la nube, a menudo es necesario acceder a los registros DNS de los recursos internos en todos los entornos. Tradicionalmente, los registros DNS locales se administran manualmente mediante un servidor DNS autorizado, como BIND en entornos UNIX o Linux, o Active Directory en entornos Microsoft Windows.

En este documento se describen las prácticas recomendadas para reenviar solicitudes de DNS privado entre entornos y asegurarse de que se pueda acceder a los servicios tanto desde entornos on-premise como desde Google Cloud.

Principios generales

Consulta información sobre los conceptos de DNS en Google Cloud

Cuando usas DNS en Google Cloud, es importante que conozcas los diferentes sistemas y servicios disponibles en Google Cloud para la resolución de DNS y los nombres de dominio:

  • DNS interno es un servicio que crea automáticamente nombres de DNS para máquinas virtuales y balanceadores de carga internos en Compute Engine.
  • Cloud DNS es un servicio que ofrece baja latencia y alta disponibilidad para las zonas de DNS. Puede actuar como servidor DNS autoritativo para zonas públicas visibles en Internet o para zonas privadas visibles solo en tu red.
  • Servicio gestionado de Microsoft Active Directory es un servicio endurecido y de alta disponibilidad que ejecuta Microsoft Active Directory, incluido un controlador de dominio.
  • DNS público es un servicio de Google que no forma parte de Google Cloud y que actúa como un resolvedor de DNS recursivo y abierto.
  • Cloud Domains es un registrador de dominios que permite comprar, transferir y gestionar dominios en Google Cloud. Cloud Domains te permite interactuar con el sistema de registro de dominios a través de una API.

Identificar a las partes interesadas, las herramientas y los procesos

Cuando te plantees crear una estrategia de DNS en un entorno híbrido, es importante que te familiarices con tu arquitectura actual y que te pongas en contacto con todas las partes interesadas. Sigue estos pasos:

  • Identifica y ponte en contacto con el administrador de los servidores DNS corporativos de tu organización. Pídele información sobre las configuraciones necesarias para asignar tu configuración local a una arquitectura adecuada enGoogle Cloud. Para obtener información sobre los métodos para acceder a los registros DNS, consulta el artículo Usar el reenvío condicional para acceder a los registros DNS desde entornos on-premise.Google Cloud
  • Familiarízate con el software de DNS actual e identifica los nombres de dominio que se usan de forma privada en tu organización.
  • Identifica a los contactos del equipo de redes que puedan asegurarse de que el tráfico a los servidores de Cloud DNS se enruta correctamente.
  • Familiarízate con tu estrategia de conectividad híbrida y con los patrones y las prácticas de nube híbrida y multinube.

Crear un estándar de nomenclatura coherente

Crea un estándar de nomenclatura coherente en toda tu organización. Por ejemplo, supongamos que tu organización usa example.com como nombre de dominio de segundo nivel y el dominio de los recursos públicos (por ejemplo, www.example.com). El lugar donde se alojan las zonas públicas no es relevante para los fines de este documento, ya que el objetivo es migrar zonas privadas.

Para asignar nombres a los recursos corporativos locales, puede elegir entre los siguientes patrones:

  • Puedes tener nombres de dominio diferentes para los servidores locales y para Google Cloud. Este patrón usa un dominio independiente para los diferentes entornos (por ejemplo, corp.example.com para los servidores locales y gcp.example.com para todos los recursos de Google Cloud). Si usas otros entornos de nube pública, cada uno de ellos puede tener un subdominio independiente. Este es el patrón preferido, ya que puedes reenviar solicitudes entre entornos.

    También puedes usar nombres de dominio independientes, como example.com y example.cloud.

  • Puedes tener el dominio Google Cloud como subdominio del dominio que contiene servidores locales. Si se usa el dominio example.com, el entorno local podría usar corp.example.com y Google Cloud podría usar gcp.corp.example.com. Este es un patrón habitual cuando la mayoría de los recursos permanecen en las instalaciones.

  • Puedes tener el dominio local como subdominio del dominio que contiene registrosGoogle Cloud . Con el dominio example.com, Google Cloud podría usar corp.example.com y el entorno local podría usar dc.corp.example.com. Este es un patrón poco habitual, pero se puede usar en organizaciones digitales que solo tengan una pequeña presencia local.

  • Puedes usar el mismo dominio para Google Cloud y para las instalaciones locales. En este caso, tanto Google Cloud como el entorno local usan recursos que utilizan el dominio corp.example.com. Evita este patrón, ya que dificulta mucho la gestión de registros en un entorno híbrido. Solo es posible si utilizas un único sistema DNS autorizado.

En el resto de esta página se usan los siguientes nombres de dominio:

  • example.com como nombre de dominio de tus registros públicos, independientemente de dónde estén alojados.
  • corp.example.com como una zona alojada en tu servidor DNS local. Esta zona aloja registros de tus recursos locales.
  • gcp.example.com como zona gestionada privada de Cloud DNS que aloja registros de tus Google Cloud recursos.

En la figura 1 se muestra una configuración de nombre de dominio coherente en su red local y en Google Cloud.

Ilustración 1. Configuración coherente del nombre de dominio en toda la organización.
Imagen 1. La configuración del nombre de dominio es coherente en toda la organización.

Para asignar nombres a los recursos de tu red de nube privada virtual (VPC), puedes seguir directrices como las que se indican en la guía de soluciones Prácticas recomendadas y arquitecturas de referencia para el diseño de VPC.

Elegir dónde se realiza la resolución de DNS

En un entorno híbrido, la resolución de DNS se puede realizar en diferentes ubicaciones. Puedes hacer lo siguiente:

  • Usa un enfoque híbrido con dos sistemas DNS autoritativos.
  • Mantener la resolución de DNS en las instalaciones.
  • Mover toda la resolución de DNS a Cloud DNS.

Te recomendamos que uses el enfoque híbrido, por lo que este documento se centra en él. Sin embargo, para que sea completo, en este documento se describen brevemente los enfoques alternativos.

Usar un enfoque híbrido con dos sistemas de DNS autoritativos

Te recomendamos que uses un enfoque híbrido con dos sistemas DNS autoritativos. En este enfoque:

  • Cloud DNS se encarga de la resolución de DNS autorizada de tu entorno privado. Google Cloud
  • La resolución de DNS autorizada para los recursos locales se aloja en los servidores DNS locales.

En la figura 2 se muestra esta disposición.

Figura 2. Una arquitectura de DNS híbrida que usa servidores DNS de Cloud DNS y on-premise para proporcionar resolución de DNS autoritativa.
Imagen 2. Una arquitectura de DNS híbrida que usa tanto Cloud DNS como servidores DNS on-premise proporciona resolución de DNS autoritativa.

El caso práctico que se muestra en la figura 2 es el preferido. Más adelante en esta página se explican los siguientes detalles:

  • Cómo configurar el reenvío entre entornos mediante zonas privadas y reenvío de DNS.
  • Cómo configurar cortafuegos y enrutamiento.
  • Arquitecturas de referencia que muestran cómo usar una o varias redes de VPC.

Mantener la resolución de DNS en las instalaciones

Otra opción es seguir usando tu servidor DNS local para alojar de forma autorizada todos los nombres de dominio internos. En ese caso, puedes usar un servidor de nombres alternativo para reenviar todas las solicitudes deGoogle Cloud mediante el reenvío de DNS saliente.

Este enfoque tiene las siguientes ventajas:

  • Haces menos cambios en los procesos empresariales.
  • Puedes seguir usando las herramientas que ya tienes.
  • Puedes usar listas de denegación para filtrar solicitudes de DNS concretas en las instalaciones.

Sin embargo, tiene las siguientes desventajas:

  • Las solicitudes de DNS de Google Cloud tienen una latencia más alta.
  • Tu sistema depende de la conectividad con entornos on-premise para las operaciones de DNS.
  • Puede que te resulte difícil integrar entornos muy flexibles, como los grupos de instancias con escalado automático.
  • Es posible que el sistema no sea compatible con productos como Dataproc, ya que estos productos dependen de la resolución inversa de los nombres de instancia de Google Cloud.

Mover toda la resolución de DNS a Cloud DNS

Otra opción es migrar a Cloud DNS como servicio autorizado para todas las resoluciones de dominio. Después, puedes usar zonas privadas y el reenvío de DNS entrante para migrar tu resolución de nombres local a Cloud DNS.

Este enfoque tiene las siguientes ventajas:

  • No tienes que mantener un servicio DNS de alta disponibilidad en las instalaciones.
  • Tu sistema puede usar Cloud DNS para aprovechar las ventajas de la monitorización y el registro centralizados.

Sin embargo, tiene las siguientes desventajas:

  • Las solicitudes de DNS procedentes de entornos on-premise tienen una latencia más alta.
  • Tu sistema requiere una conexión fiable a tu red de VPC para la resolución de nombres.

Prácticas recomendadas para zonas privadas de Cloud DNS

Las zonas privadas alojan registros DNS que solo se pueden ver dentro de tu organización. En este documento no se tratan las zonas públicas de Cloud DNS. Las zonas públicas cubren los registros públicos de la organización, como los registros DNS del sitio web público, y no son tan relevantes en una configuración híbrida.

Usar la automatización para gestionar zonas privadas en el proyecto host de la VPC compartida

Si utilizas redes de VPC compartida en tu organización, debes alojar todas las zonas privadas en Cloud DNS en el proyecto del host. Todos los proyectos de servicio pueden acceder automáticamente a los registros de las zonas privadas asociadas a la red de VPC compartida. También puedes configurar la zona en un proyecto de servicio mediante la vinculación entre proyectos.

En la figura 3 se muestra cómo se alojan las zonas privadas en una red de VPC compartida.

Figura 3. Zonas privadas alojadas en una red de VPC compartida (haz clic para ampliar).
Imagen 3. En esta configuración se muestra cómo se adjuntan las zonas privadas a una VPC compartida.

Si quieres que los equipos definan sus propios registros DNS, te recomendamos que automatices la creación de registros DNS. Por ejemplo, puedes crear una aplicación web o una API interna en la que los usuarios definan sus propios registros DNS en subdominios específicos. La aplicación verifica que los registros cumplen las reglas de tu organización.

También puedes poner tu configuración de DNS en un repositorio de código, como Cloud Source Repositories, en forma de descriptores de Terraform o Cloud Deployment Manager, y aceptar solicitudes de extracción de los equipos.

En ambos casos, una cuenta de servicio con el rol Administrador de DNS de gestión de identidades y accesos en el proyecto host puede implementar automáticamente los cambios una vez que se hayan aprobado.

Definir roles de gestión de identidades y accesos según el principio de mínimos accesos

Aplica el principio de seguridad de mínimos accesos para dar el derecho a cambiar los registros DNS solo a los miembros de tu organización que necesiten realizar esta tarea. No uses roles básicos, ya que pueden dar acceso a recursos que el usuario no necesita. Cloud DNS ofrece roles y permisos que te permiten conceder acceso de lectura y escritura específico para DNS.

Si es importante separar la capacidad de crear zonas de DNS privadas de la capacidad de crear zonas públicas, usa el permiso dns.networks.bindPrivateDNSZone.

Prácticas recomendadas para zonas de reenvío de DNS y políticas de servidor

Cloud DNS ofrece zonas de reenvío de DNS y políticas de servidor DNS para permitir búsquedas de nombres de DNS entre tu entorno local y el entorno de Google Cloud . Tienes varias opciones para configurar el reenvío de DNS. En la siguiente sección se indican las prácticas recomendadas para configurar el DNS híbrido. Estas prácticas recomendadas se ilustran en el artículo Arquitecturas de referencia para DNS híbrido.

Usar zonas de reenvío para consultar servidores locales

Para asegurarte de que puedes consultar registros DNS en tu entorno local, configura una zona de reenvío para el dominio que utilices de forma local para tus recursos corporativos (como corp.example.com). Es preferible usar este método en lugar de una política de DNS que habilite un servidor de nombres alternativo. Mantiene el acceso a los nombres de DNS internos de Compute Engine y las direcciones IP externas se siguen resolviendo sin un salto adicional a través de un servidor de nombres local.

El flujo de tráfico que usa esta configuración se muestra en las arquitecturas de referencia para DNS híbrido.

Usa servidores de nombres alternativos solo si todo el tráfico DNS debe monitorizarse o filtrarse en las instalaciones y si el registro de DNS privado no cumple tus requisitos.

Usar políticas de servidor DNS para permitir consultas desde entornos on-premise

Para permitir que los hosts locales consulten registros DNS alojados en zonas privadas de Cloud DNS (por ejemplo, gcp.example.com), crea una política de servidor DNS mediante el reenvío de DNS entrante. El reenvío de DNS entrante permite que tu sistema consulte todas las zonas privadas del proyecto, así como las direcciones IP de DNS internas y las zonas emparejadas.

El flujo de tráfico que usa esta configuración se muestra en las arquitecturas de referencia para DNS híbrido.

Abrir Google Cloud cortafuegos locales para permitir el tráfico DNS

Para comprobar que el tráfico DNS no se filtra en ningún lugar de tu red VPC ni de tu entorno local, haz lo siguiente:

  • Asegúrate de que tu cortafuegos local permita las consultas de Cloud DNS. Cloud DNS envía consultas desde el intervalo de direcciones IP 35.199.192.0/19. El DNS usa el puerto UDP 53 o el puerto TCP 53, en función del tamaño de la solicitud o la respuesta.

  • Asegúrate de que tu servidor DNS no bloquee las consultas. Si tu servidor DNS local solo acepta solicitudes de direcciones IP específicas, asegúrate de que se incluya el intervalo de direcciones IP 35.199.192.0/19.

  • Comprueba que el tráfico pueda fluir desde las instalaciones locales a tus direcciones IP de reenvío. En las instancias de Cloud Router, añade una ruta anunciada personalizada para el intervalo de direcciones IP 35.199.192.0/19 en tu red de VPC al entorno on-premise.

Usar el reenvío condicional para acceder a registros DNS desde un entorno on-premise

Con Cloud DNS, para acceder a los registros privados alojados en servidores DNS corporativos locales, solo puedes usar zonas de reenvío. Sin embargo, en función del software del servidor DNS que utilices, es posible que tengas varias opciones para acceder a los registros DNS de Google Cloud desde las instalaciones. En ambos casos, se accede a los registros mediante el reenvío de DNS entrante:

  • Desvío condicional. Si utilizas el reenvío condicional, tu servidor DNS corporativo reenviará las solicitudes de zonas o subdominios específicos a las direcciones IP de reenvío de Google Cloud. Te recomendamos este enfoque porque es el menos complejo y te permite monitorizar de forma centralizada todas las solicitudes de DNS en los servidores DNS de la empresa.

  • Delegación. Si tu zona privada en Google Cloud es un subdominio de la zona que usas en las instalaciones, también puedes delegar este subdominio en el servidor de nombres deGoogle Cloud configurando entradas NS en tu zona. Cuando utilices esta configuración, los clientes podrán comunicarse directamente con las direcciones IP de reenvío en Google Cloud , así que asegúrate de que el cortafuegos permita estas solicitudes.

  • Transferencias de zonas. Cloud DNS no admite transferencias de zonas, por lo que no puedes usarlas para sincronizar registros DNS con tus servidores DNS locales.

Usar el emparejamiento de DNS para evitar el reenvío saliente desde varias redes VPC

No utilices el reenvío saliente a tus servidores DNS locales desde varias redes VPC, ya que esto crea problemas con el tráfico de retorno. Google Cloud acepta respuestas de tus servidores DNS solo si se enrutan a la red VPC desde la que se originó la consulta. Sin embargo, las consultas de cualquier red de VPC tienen el mismo intervalo de direcciones IP 35.199.192.0/19 como origen. Por lo tanto, las respuestas no se pueden enrutar correctamente a menos que tengas entornos independientes en las instalaciones.

Figura 4. Se produce un problema cuando varias VPC reenvían tráfico fuera de sus redes.
Imagen 4. Problema al tener varias redes de VPC que realizan reenvío saliente.

Te recomendamos que designes una única red VPC para consultar servidores de nombres locales mediante el reenvío saliente. Después, las redes de VPC adicionales pueden consultar los servidores de nombres locales si se dirigen a la red de VPC designada con una zona de emparejamiento de DNS. Sus consultas se reenviarán a los servidores de nombres locales según el orden de resolución de nombres de la red VPC designada. Esta configuración se muestra en las arquitecturas de referencia para DNS híbrido.

Diferencias entre el emparejamiento de DNS y el de redes de VPC

El emparejamiento entre redes de VPC no es lo mismo que el emparejamiento de DNS. El emparejamiento de redes de VPC permite que las instancias de máquina virtual (VM) de varios proyectos se comuniquen entre sí, pero no cambia la resolución de nombres. Los recursos de cada red VPC siguen su propio orden de resolución.

Por el contrario, con el emparejamiento de DNS, puedes permitir que las solicitudes de zonas específicas se reenvíen a otra red de VPC. De esta forma, puedes reenviar solicitudes a diferentes Google Cloud entornos, independientemente de si las redes de VPC están interconectadas.

El emparejamiento de redes de VPC y el emparejamiento de DNS también se configuran de forma diferente. En el caso del emparejamiento entre redes de VPC, ambas redes de VPC deben configurar una relación de emparejamiento con la otra red de VPC. El emparejamiento se convierte automáticamente en bidireccional.

El emparejamiento de DNS reenvía las solicitudes de DNS de forma unidireccional y no requiere una relación bidireccional entre las redes de VPC. Una red VPC, denominada red consumidora de DNS, realiza búsquedas de una zona de emparejamiento de Cloud DNS en otra red VPC, denominada red productora de DNS. Los usuarios con el permiso de gestión de identidades y accesos dns.networks.targetWithPeeringZone en el proyecto de la red del productor pueden establecer el emparejamiento de DNS entre las redes del consumidor y del productor. Para configurar el emparejamiento de DNS desde una red VPC de consumidor, necesitas el rol de par de DNS para el proyecto host de la red VPC de productor.

Si usas nombres generados automáticamente, usa el peering de DNS para las zonas internas

Si usas los nombres generados automáticamente para las VMs que crea el servicio DNS interno, puedes usar el peering de DNS para reenviar las zonas projectname.internal a otros proyectos. Como se muestra en la figura 5, puedes agrupar todas las .internalzonas de un proyecto de centro de control para que se pueda acceder a ellas desde tu red local.

Figura 5. El peering de DNS se usa para organizar todas las zonas .internal en un centro.
Imagen 5. El peering de DNS se usa para organizar todas las zonas de .internal en un centro.

Si tienes problemas, sigue la guía para solucionarlos

La guía de solución de problemas de Cloud DNS proporciona instrucciones para resolver los errores habituales que pueden surgir al configurar Cloud DNS.

Arquitecturas de referencia para DNS híbrido

En esta sección se proporcionan algunas arquitecturas de referencia para situaciones comunes que usan zonas privadas de Cloud DNS en un entorno híbrido. En ambos casos, los recursos locales, los registros de recursos y las zonas se gestionan en el entorno. Google Cloud Todos los registros se pueden consultar tanto desde hosts locales como desde hosts de Google Cloud .

Usa la arquitectura de referencia que se corresponda con el diseño de tu red VPC:

  • Arquitectura híbrida con una sola red de VPC compartida: usa una sola red de VPC conectada a entornos locales o desde ellos.

  • Arquitectura híbrida con varias redes de VPC independientes: conecta varias redes de VPC con entornos on-premise mediante diferentes túneles VPN o vinculaciones de VLAN y comparte la misma infraestructura de DNS on-premise.

  • Arquitectura híbrida que usa una red de VPC de concentrador conectada a redes de VPC de radio: usa el emparejamiento entre redes de VPC para conectar una red de VPC de concentrador a varias redes de VPC de radio independientes.

En cada caso, el entorno on-premise se conecta a las redes de VPC mediante uno o varios túneles de Cloud VPN, conexiones de Interconnect dedicado o de Partner Interconnect. Google Cloud No importa qué método de conexión se utilice para cada red de VPC.

Arquitectura híbrida con una sola red de VPC compartida

El caso práctico más habitual es una única red de VPC compartida conectada al entorno local, como se muestra en la figura 6.

Figura 6. Una arquitectura híbrida usa una sola red de VPC compartida para conectarse a una red local.
Imagen 6. Una arquitectura híbrida usa una sola red de VPC compartida para conectarse a una red local.

Para configurar esta arquitectura, sigue estos pasos:

  1. Configura tus servidores DNS locales como autoritativos para corp.example.com.
  2. Configura una zona privada autoritativa (por ejemplo, gcp.example.com) en Cloud DNS en el proyecto host de la red de VPC compartida y configura todos los registros de los recursos de esa zona.
  3. Define una política de servidor DNS en el proyecto host de la red de VPC compartida para permitir el reenvío de DNS entrante.
  4. Define una zona de reenvío de DNS que reenvíe corp.example.com a los servidores DNS locales. La red de VPC compartida debe tener autorización para consultar la zona de reenvío.
  5. Configura el reenvío a gcp.example.com en tus servidores DNS on-premise, apuntando a una dirección IP de reenviador entrante en la red de VPC compartida.
  6. Asegúrate de que el tráfico DNS esté permitido en tu cortafuegos local.
  7. En las instancias de Cloud Router, añade una ruta anunciada personalizada para el intervalo 35.199.192.0/19 al entorno local.

Arquitectura híbrida con varias redes de VPC independientes

Otra opción para las arquitecturas híbridas es tener varias redes de VPC independientes. Estas redes de VPC de tu entornoGoogle Cloud no están conectadas entre sí mediante el emparejamiento entre redes de VPC. Todas las redes de VPC usan túneles de Cloud VPN o vinculaciones de VLAN independientes para conectarse a tus entornos on-premise.

Como se muestra en la figura 7, un caso de uso habitual de esta arquitectura es cuando tienes entornos de producción y desarrollo independientes que no se comunican entre sí, pero comparten servidores DNS.

Figura 7. Una arquitectura híbrida puede usar varias redes de VPC independientes.
Imagen 7. Una arquitectura híbrida puede usar varias redes de VPC independientes.

Para configurar esta arquitectura, sigue estos pasos:

  1. Configura tus servidores DNS locales como autoritativos para corp.example.com.
  2. Configura una zona privada (por ejemplo, prod.gcp.example.com) en Cloud DNS en el proyecto host de la red VPC compartida de producción y configura todos los registros de los recursos de esa zona.
  3. Configura una zona privada (por ejemplo, dev.gcp.example.com) en Cloud DNS en el proyecto host de la red de VPC compartida de desarrollo y configura todos los registros de los recursos de esa zona.
  4. Define una política de servidor DNS en el proyecto del host de la red de VPC compartida de producción y permite el reenvío de DNS entrante.
  5. En la red de VPC compartida de producción, define una zona de DNS para reenviar corp.example.com a los servidores DNS locales.
  6. Define una zona de peering de DNS desde la red de VPC compartida de desarrollo hasta la red de VPC compartida de producción para prod.gcp.example.com.
  7. Define una zona de peering de DNS de la red de VPC compartida de producción a la red de VPC compartida de desarrollo para dev.gcp.example.com.
  8. Configura el reenvío entrante delegando la resolución de gcp.example.com. a las direcciones IP virtuales de reenvío entrante de Cloud DNS en tus servidores de nombres locales.
  9. Asegúrate de que el cortafuegos permita el tráfico DNS tanto en los cortafuegos locales como en los deGoogle Cloud .
  10. En las instancias de Cloud Router, añade una ruta anunciada personalizada para el intervalo de direcciones IP 35.199.192.0/19 en la red de VPC compartida de producción al entorno local.

Arquitectura híbrida que usa una red de VPC de concentrador conectada a redes de VPC de radio

Otra opción es usar Cloud Interconnect o Cloud VPN para conectar la infraestructura on-premise a una red de VPC de concentrador. Como se muestra en la figura 8, puedes usar el emparejamiento entre redes de VPC para emparejar una red de VPC con varias redes de VPC de radio. Cada red de VPC de spoke aloja sus propias zonas privadas en Cloud DNS. Las rutas personalizadas en el emparejamiento de redes de VPC, junto con el anuncio de rutas personalizadas en Cloud Router, permiten el intercambio completo de rutas y la conectividad entre las redes on-premise y todas las redes de VPC de tipo spoke. El emparejamiento de DNS se ejecuta en paralelo con las conexiones de emparejamiento de redes de VPC para permitir la resolución de nombres entre entornos.

En el siguiente diagrama se muestra esta arquitectura.

Figura 8. Una arquitectura híbrida puede usar una red de VPC de concentrador conectada a redes de VPC de radio mediante el emparejamiento entre redes de VPC.
Imagen 8. Una arquitectura híbrida puede usar una red de VPC de concentrador conectada a redes de VPC de radios.

Para configurar esta arquitectura, sigue estos pasos:

  1. Configura tus servidores DNS locales como autoritativos para corp.example.com.
  2. Configura una zona privada (por ejemplo, projectX.gcp.example.com) en Cloud DNS para cada red de VPC de radio y configura todos los registros de los recursos de esa zona.
  3. Define una política de servidor DNS en el proyecto de hub para la red de VPC compartida de producción con el fin de permitir el reenvío de DNS entrante.
  4. En la red de VPC de concentrador, crea una zona DNS privada para corp.example.com y configura el reenvío saliente a los servidores DNS on-premise.
  5. Define una zona de emparejamiento de DNS desde la red de VPC de concentrador a cada red de VPC de radio para projectX.gcp.example.com.
  6. Define una zona de emparejamiento de DNS desde cada red de VPC de radio a la red de VPC de concentrador para example.com.
  7. Configura el reenvío a gcp.example.com en tus servidores DNS locales para que apunten a una dirección IP de reenviador entrante en la red de VPC del hub.
  8. Asegúrate de que el cortafuegos permita el tráfico DNS tanto en los cortafuegos locales como en los deGoogle Cloud .
  9. En las instancias de Cloud Router, añade una ruta anunciada personalizada para el intervalo de direcciones IP 35.199.192.0/19 en la red de VPC de concentrador al entorno local.
  10. Opcional: Si también usas los nombres de DNS internos generados automáticamente, empareja cada zona del proyecto de radio (por ejemplo, spoke-project-x.internal) con el proyecto de centro y reenvía todas las consultas de .internal desde las instalaciones.

DNS público de varios proveedores con Cloud DNS

Como componente fundamental de las redes de aplicaciones, un DNS fiable es clave para asegurar que tus aplicaciones o servicios estén disponibles para los usuarios. Puedes mejorar la disponibilidad y la resiliencia de tus aplicaciones y servicios configurando varios proveedores de DNS. Si se configuran varios proveedores de DNS, tu aplicación o servicio puede estar disponible para tus usuarios aunque haya una interrupción en uno de los proveedores de DNS. También puedes simplificar la implementación y la migración de aplicaciones híbridas que tengan dependencias en entornos locales y en la nube con una configuración de DNS de varios proveedores.

Google Cloud ofrece una solución de código abierto basada en octoDNS para ayudarte a configurar y gestionar un entorno con varios proveedores de DNS. La solución de DNS de varios proveedores utiliza Cloud DNS como uno de tus proveedores de DNS en una configuración activa-activa (recomendada) o activa-pasiva para asegurar una arquitectura de DNS de alta disponibilidad. Una vez que hayas implementado la solución, octoDNS realizará una sincronización única y continua entre tus zonas DNS actuales y las zonas DNS gestionadas alojadas en Cloud DNS. Cuando se actualizan registros DNS individuales, los cambios se propagan a las zonas DNS correspondientes alojadas en Cloud DNS sin necesidad de modificar las canalizaciones de CI/CD.

Siguientes pasos