Prácticas recomendadas de DNS

En este documento, se proporcionan prácticas recomendadas para lo siguiente:

Introducción

Tanto para las personas como para las aplicaciones es más fácil dirigir las aplicaciones y los servicios con el Sistema de nombres de dominio (DNS), puesto que es más fácil recordar un nombre y más flexible que usar direcciones IP. En un entorno híbrido, que consta de plataformas locales y una o más plataformas de 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 de forma manual con un servidor DNS autorizado, como BIND en entornos de UNIX/Linux o Active Directory en entornos de Microsoft Windows. En este artículo, se describen las prácticas recomendadas para reenviar solicitudes DNS privadas entre entornos a fin de garantizar que los servicios se puedan dirigir desde entornos locales y dentro de Google Cloud.

Principios generales

Más información sobre los conceptos de DNS en Google Cloud

Cuando se utiliza DNS en Google Cloud, es importante comprender los diferentes sistemas y servicios disponibles en la plataforma para resolución de DNS y nombres de dominio:

  • El DNS interno es un servicio con el que se crean automáticamente nombres de DNS para máquinas virtuales y balanceadores de cargas internos en Compute Engine.
  • Cloud DNS es un servicio que proporciona una zona DNS de baja latencia y alta disponibilidad. Puede actuar como un servidor DNS autorizado para las zonas públicas que son visibles en Internet o las zonas privadas que son visibles solo dentro de tu red. Para conocer más detalles, consulta Descripción general de Cloud DNS.
  • El servicio administrado para Active Directory de Microsoft es un servicio endurecido y con alta disponibilidad que ejecuta Active Directory de Microsoft y que incluye un controlador de dominio.
  • El DNS público es un servicio de Google que no forma parte de Google Cloud y que actúa como un agente de resolución de DNS abierto y recursivo.
  • Google Domains es un registrador de dominios para comprar, transferir o administrar dominios. Este es un servicio de Google que no forma parte de Google Cloud.

Identifica las partes interesadas, las herramientas y los procesos

Cuando pienses en crear una estrategia para DNS en un entorno híbrido, es importante que te familiarices primero con la arquitectura actual y te comuniques con todas las partes interesadas. Haz lo siguiente:

  • Identifica y comunícate con el administrador de los servidores DNS corporativos de tu organización. Pídeles información sobre las configuraciones necesarias para asignar tu configuración local a una arquitectura adecuada en Google Cloud. Si deseas información más detallada, consulta Usa el reenvío condicional para acceder a registros DNS locales en los métodos de acceso a los registros DNS de 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 los contactos del equipo de redes que pueden asegurarse de que el tráfico a los servidores de Cloud DNS se enrute correctamente.
  • Familiarízate con tu estrategia de conectividad híbrida y con los patrones y prácticas de nube híbrida y de múltiples nubes.

Crea un estándar de nombres simple y coherente

Crea un estándar de nombres coherente en toda tu organización y que sea fácil de recordar. Por ejemplo, supongamos que tu organización utiliza example.com como su nombre de dominio de segundo nivel y el dominio para recursos públicos (por ejemplo, www.example.com). Para fines de este documento, el lugar donde se alojan las zonas públicas es irrelevante, puesto que su alcance es la migración de zonas privadas.

Para asignar nombres a recursos corporativos de forma local, puedes elegir entre los siguientes patrones:

  • Tener nombres de dominio independientes para los servidores locales y para Google Cloud. En este patrón, se usa un dominio independiente para los distintos entornos como, por ejemplo, corp.example.com para tus servidores locales y gcp.example.com para todos los recursos de Google Cloud. Si usas otros entornos de nube pública, en cada uno de ellos puede haber un subdominio independiente. Este es el patrón preferido, porque es fácil reenviar solicitudes entre entornos.

    También puedes utilizar nombres de dominio completamente diferentes, como example.com y example.cloud.

  • Tener el dominio de Google Cloud como subdominio del dominio que contiene servidores locales. Si usas el dominio example.com, localmente podrías usar corp.example.com y Google Cloud podría usar gcp.corp.example.com. Este es un patrón común cuando la mayoría de los recursos son locales.

  • Tener el dominio local como un subdominio del dominio que contiene los registros de Google Cloud. Si usas el dominio example.com, Google Cloud podría usar corp.example.com y localmente podrías usar dc.corp.example.com. Este es un patrón poco común, pero podría usarse para organizaciones nativas digitales que solo tienen un espacio local pequeño.

  • Usar el mismo dominio para Google Cloud y para las bases de datos locales. En este caso, tanto Google Cloud como las bases de datos locales usan recursos con el dominio corp.example.com. Debes evitar este patrón, porque dificulta mucho más la administración de registros en un entorno híbrido. Solo es posible cuando se usa un único sistema DNS autorizado.

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

  • example.com como un nombre de dominio para tus registros públicos (independientemente de dónde estén alojados)
  • corp.example.com como una zona alojada por tu servidor DNS local. En esta zona, se alojan registros de tus recursos locales
  • gcp.example.com como una zona administrada privada de Cloud DNS que aloja registros para tus recursos de Google Cloud

En el siguiente diagrama, se muestra esta disposición:

Ejemplo de configuración de nombre de dominio (haz clic para ampliar)
Ejemplo de configuración de nombre de dominio (haz clic para ampliar)

Para asignar nombres a los recursos de tu red de VPC, puedes seguir lineamientos, como los que aparecen en Prácticas recomendadas y arquitecturas de referencia para el diseño de VPC.

Elige dónde realizar 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:

  • Utilizar un enfoque híbrido con dos sistemas DNS autorizados
  • Mantener la resolución de DNS local
  • Transferir toda la resolución de DNS a Cloud DNS

Recomendamos el enfoque híbrido, por lo que este documento se centra en ese enfoque. Sin embargo, también se describen brevemente los enfoques alternativos a fin de entregar una visión completa.

Usa un enfoque híbrido con dos sistemas de DNS autorizados

Recomendamos usar un enfoque híbrido con dos sistemas DNS autorizados. En este enfoque:

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

En el siguiente diagrama, se muestra esta disposición:

Arquitectura híbrida con dos sistemas DNS autorizados (haz clic para ampliar)
Arquitectura híbrida con dos sistemas DNS autorizados (haz clic para ampliar)

Esta situación es el caso práctico preferido y se trata en detalle en este documento. En el documento, se abarca lo siguiente:

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

Conserva la resolución de DNS en el entorno local

Un enfoque alternativo es seguir usando el servidor DNS local existente para alojar de forma autorizada todos los nombres de dominio internos. En ese caso, puedes reenviar todas las solicitudes desde Google Cloud mediante el reenvío de DNS saliente con un servidor de nombres alternativo. Este enfoque tiene las siguientes ventajas:

  • Realizas menos cambios en los procesos empresariales.
  • Puedes seguir usando las herramientas existentes.
  • Las solicitudes individuales de DNS se pueden filtrar de forma local mediante listas de denegación.

Sin embargo, presenta las siguientes desventajas:

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

Mueve toda la resolución de DNS a Cloud DNS

Otro enfoque es migrar a Cloud DNS como un servicio autorizado para la resolución de todos los dominios. Luego, puedes migrar tu resolución de nombres local existente a Cloud DNS mediante zonas privadas y reenvío de DNS entrante. Este enfoque tiene las siguientes ventajas:

  • No necesitas mantener un servicio local de DNS de alta disponibilidad.
  • Tu sistema puede aprovechar el registro y la supervisión centralizados mediante Cloud DNS.

Sin embargo, presenta las siguientes desventajas:

  • Las solicitudes de DNS locales tienen una latencia más alta.
  • Tu sistema requiere una conexión confiable a la red de VPC para la resolución de nombres.

Prácticas recomendadas para las zonas privadas de Cloud DNS

Las zonas privadas alojan registros DNS que solo se pueden ver en tu organización. Las zonas públicas de Cloud DNS no se incluyen en este documento. Estas zonas abarcan los registros públicos de la organización, por ejemplo, los registros DNS del sitio web público, y no son tan relevantes en una configuración híbrida.

Usa la automatización para permitir que los equipos administren zonas privadas en el proyecto host de la VPC compartida

Si usas redes de VPC compartida en tu organización, debes alojar todas las zonas privadas en Cloud DNS dentro del proyecto host. Todos los proyectos de servicio pueden acceder automáticamente a los registros en zonas privadas vinculadas a la red de VPC compartida.

En el siguiente diagrama, se muestra cómo se alojan las zonas privadas en una red de VPC compartida:

Zonas privadas alojadas en una red de VPC compartida (haz clic para ampliar)
Zonas privadas alojadas en una red de VPC compartida (haz clic para ampliar)

Si quieres que los equipos configuren 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 establezcan sus propios registros DNS en subdominios específicos. La aplicación verifica que los registros cumplan con las reglas de tu organización. Como alternativa, puedes colocar 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, los cambios pueden implementarse automáticamente luego de su aprobación mediante una cuenta de servicio con la función de IAM administrador de DNS en el proyecto host.

Establece funciones de IAM con el principio de mínimo privilegio

Usar el principio de seguridad de mínimo privilegio otorga el derecho de cambiar los registros DNS solo a los miembros de tu organización que necesiten realizar esta tarea. Evita usar funciones básicas, puesto que podrían dar acceso a más recursos de los que el usuario necesita. Cloud DNS ofrece permisos y funciones que te permiten otorgar acceso de lectura y escritura que es específico exclusivamente de DNS.

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

Prácticas recomendadas para las zonas de reenvío de DNS

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

El reenvío de DNS no se puede utilizar entre diferentes entornos de Google Cloud, independientemente de la forma en que estén interconectados estos reenvíos. Para ese caso práctico, utiliza el intercambio de tráfico de DNS.

Usa zonas de reenvío para consultar servidores locales

A fin de asegurarte de que puedes consultar registros DNS en tu entorno local, configura una zona de reenvío en el dominio que usas de forma local para tus recursos corporativos (por ejemplo, corp.example.com). Se prefiere este enfoque en lugar de usar una política de DNS que habilita un servidor de nombres alternativo. Conserva el acceso a los nombres de DNS internos de Compute Engine y las direcciones IP públicas se siguen resolviendo sin necesidad de un salto adicional a través de un servidor de nombres local.

El flujo de tráfico que utiliza esta configuración se muestra en las arquitecturas de referencia.

Solo debes usar servidores de nombres alternativos si todo el tráfico de DNS debe supervisarse o filtrarse de manera local, y si los registros de DNS privados no cumplen tus requisitos.

Usa las políticas de servidor DNS para permitir consultas locales

Para permitir que, en los hosts locales, se consulten registros DNS alojados en zonas privadas de Cloud DNS (por ejemplo, gcp.example.com), crea una política de servidor DNS con 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 internas de DNS y las zonas de intercambio de tráfico. Aunque tengas una dirección IP de reenvío entrante diferente para cada subred, todas las consultas de DNS muestran respuestas idénticas y no hay ninguna diferencia de latencia. Tus aplicaciones pueden enviar una solicitud a cualquiera de esas direcciones.

El flujo de tráfico que utiliza esta configuración se muestra en las arquitecturas de referencia.

Abre Google Cloud y los firewalls locales para permitir el tráfico de DNS

Asegúrate de que el tráfico de DNS no se filtre en ningún lugar dentro de tu VPC o en el entorno local. Incluye lo siguiente:

  • Asegúrate de que el firewall local pase las consultas desde Cloud DNS. Cloud DNS envía consultas desde el rango de direcciones IP 35.199.192.0/19. DNS usa el puerto UDP 53 o TCP 53, según el tamaño de la solicitud o respuesta.

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

  • Asegúrate de que el tráfico pueda fluir desde el entorno local hasta tus direcciones IP de reenvío. Para el reenvío entrante, asegúrate de que el firewall local no bloquee el tráfico que fluye a las direcciones IP de reenvío desde tus servidores DNS locales o desde otros clientes. Es posible que debas crear una regla de firewall en tu firewall local para permitir el tráfico de todos los clientes en el puerto UDP 53 a la dirección IP de reenvío.

Usa el reenvío condicional para acceder a registros DNS de forma local

Con Cloud DNS, para acceder a los registros privados alojados en servidores DNS corporativos locales, solo puedes usar zonas de reenvío. Sin embargo, según el software de servidor DNS que uses, es posible que tengas varias opciones para acceder a los registros DNS en Google Cloud de forma local. En cada caso, el acceso a los registros se realiza mediante el siguiente reenvío de DNS entrante:

  • Reenvío condicional: Si usas el reenvío condicional, con tu servidor DNS corporativo se reenviarán las solicitudes para zonas o subdominios específicos a las direcciones IP de reenvío en Google Cloud. Recomendamos este enfoque, porque es el menos complejo y te permite supervisar de forma centralizada todas las solicitudes de DNS en los servidores DNS corporativos.

  • Delegación: Si tu zona privada en Google Cloud es un subdominio de la zona que usas de forma local, establece entradas NS dentro de tu zona para delegar este subdominio al servidor de nombres de Google Cloud. Si utilizas esta configuración, los clientes pueden comunicarse directamente con las direcciones IP de reenvío en Google Cloud, por lo que debes asegurarte de que el firewall las apruebe.

  • Transferencias de zona: En Cloud DNS, no se admiten transferencias de zona, por lo que no puedes sincronizar registros DNS con tus servidores DNS locales mediante transferencias de zona.

Usa el intercambio de tráfico de DNS para evitar el reenvío saliente desde varias redes de VPC

No debes usar reenvío de salida hacia tus servidores DNS locales desde varias redes de VPC, porque esto crea problemas con el tráfico de retorno. GCP solo acepta las respuestas de tus servidores DNS si se enrutan a la VPC desde la que se originó la consulta. Sin embargo, las consultas de cualquier VPC tienen el mismo rango de IP 35.199.192.0/19 como fuente. Por lo tanto, las respuestas no se pueden enrutar de forma correcta, a menos que tengas entornos locales completamente separados.

En el siguiente diagrama, se ilustra el problema de tener varias VPC que realizan el reenvío de salida:

Problemas con varias VPC que realizan el reenvío de salida (haz clic para ampliar)
Problemas con varias VPC que realizan el reenvío de salida (haz clic para ampliar)

Te recomendamos designar una sola VPC para consultar los servidores de nombres locales mediante el reenvío de salida. Luego, las VPC adicionales pueden orientarse a la VPC designada con una zona de intercambio de tráfico de DNS a fin de consultar los servidores de nombres locales. Sus consultas se reenviarán a los servidores de nombres locales según el orden de resolución de nombres de VPC de la VPC designada. Esta configuración se muestra en la sección de arquitecturas de referencia.

Comprende la diferencia entre el intercambio de tráfico de DNS y el intercambio de tráfico entre redes de VPC

Intercambio de tráfico entre redes de VPC no es lo mismo que intercambio de tráfico de DNS. El intercambio de tráfico entre redes de VPC permite que las VM de varios proyectos se comuniquen entre sí, pero no cambia la resolución del nombre. Los recursos en cada VPC siguen su propio orden de resolución. En cambio, a través del intercambio de tráfico de DNS, puedes permitir que las solicitudes se reenvíen para zonas específicas a otra VPC. Esto te permite reenviar solicitudes a diferentes entornos de Google Cloud, independientemente de si las VPC están interconectadas.

El intercambio de tráfico entre redes de VPC y el intercambio de tráfico de DNS también se configuran de manera diferente. En el caso del intercambio de tráfico entre redes de VPC, ambas VPC deben establecer una relación de intercambio de tráfico con la otra VPC. Aquí el intercambio de tráfico es automáticamente bidireccional.

El intercambio de tráfico de DNS reenvía unidireccionalmente las solicitudes de DNS y no requiere una relación bidireccional entre las VPC. Una red de VPC conocida como red de consumidor de DNS realiza búsquedas para una zona de intercambio de tráfico de Cloud DNS en otra red de VPC, denominada red de productor de DNS. Los usuarios con el permiso dns.networks.targetWithPeeringZone de IAM en el proyecto de la red de productor pueden establecer intercambio de tráfico de DNS entre las redes de consumidor y productor. Para configurar el intercambio de tráfico de DNS desde una red de VPC de consumidor, necesitas la función de par de DNS para el proyecto host de la red de VPC de productor.

Si usas nombres generados automáticamente, usa el intercambio de tráfico de DNS para zonas internas

Si usas los nombres generados automáticamente para las VM que crea el servicio de DNS interno, puedes usar el intercambio de tráfico de DNS a fin de reenviar las zonas projectname.internal a otros proyectos. Puedes agregar todas las zonas .internal de un proyecto central para que todas estén disponibles de forma local.

Esta configuración se muestra en el siguiente diagrama:

Intercambio de tráfico de DNS en una configuración de malla (haz clic para ampliar)
Intercambio de tráfico de DNS en una configuración de malla (haz clic para ampliar)

Si tienes problemas, sigue la guía de solución de problemas

La guía de solución de problemas de Cloud DNS proporciona instrucciones para resolver errores comunes que podrías encontrar cuando configuras 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 cada caso, los recursos locales y los registros y las zonas de recursos de Google Cloud se administran dentro del entorno. Todos los registros están disponibles para consultas desde hosts locales y de Google Cloud.

Debes usar la arquitectura de referencia que se asigna a tu diseño de VPC:

  • Arquitectura híbrida con una sola VPC compartida: usa una única red de VPC conectada hacia o desde el entorno local

  • Arquitectura híbrida con varias redes de VPC independientes: si conectas varias VPC al entorno local mediante diferentes túneles VPN o adjuntos de VLAN, pero compartes la misma infraestructura de DNS de manera local

  • Arquitectura híbrida con una red de VPC central conectada a redes de VPC de radio: si usas el intercambio de tráfico de red de VPC para tener una red de VPC central conectada a varias redes de VPC de radio independientes

En cada caso, el entorno local se conecta a las VPC de Google Cloud mediante uno o varios túneles de Cloud VPN o Cloud Interconnect: conexiones dedicadas o asociadas. No es relevante qué método de conexión se usa para cada red de VPC.

Arquitectura híbrida con una sola red de VPC compartida

El caso más común es una sola red de VPC compartida conectada al entorno local y se muestra en el siguiente diagrama:

Arquitectura híbrida con una sola red de VPC compartida (haz clic para ampliar)
Arquitectura híbrida con una sola red de VPC compartida (haz clic para ampliar)

Haz lo siguiente para configurar esta arquitectura:

  1. Configura tus servidores DNS locales como autorizados para corp.example.com.
  2. Configura una zona privada autorizada (por ejemplo, gcp.example.com) en Cloud DNS en el proyecto host de la red de VPC compartida y configura todos los registros para los recursos de esa zona.
  3. Establece una política de servidor DNS en el proyecto host para la red de VPC compartida a fin de permitir el reenvío de DNS entrante.
  4. Establece una zona de reenvío de DNS que reenvíe corp.example.com a los servidores DNS locales. La VPC compartida debe estar autorizada para consultar la zona de reenvío.
  5. Configura el reenvío a gcp.example.com en tus servidores DNS locales para apuntar a una dirección IP de reenvío entrante en la red de VPC compartida.
  6. Asegúrate de que tu firewall local permita el tráfico de DNS.
  7. En instancias de Cloud Router, agrega un anuncio de ruta personalizado para el rango 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 entorno de Google Cloud no están conectadas entre sí a través del intercambio de tráfico entre redes de VPC. Todas las redes de VPC están conectadas a tus entornos locales mediante túneles independientes de Cloud VPN o adjuntos de VLAN. Un caso práctico típico para esta arquitectura es cuando tienes entornos separados que no se comunican entre sí, pero comparten servidores DNS. Un caso práctico típico es tener entornos de producción y desarrollo independientes.

Esta arquitectura se muestra en el siguiente diagrama:

Arquitectura híbrida con varias redes de VPC independientes (haz clic para ampliar)
Arquitectura híbrida con varias redes de VPC independientes (haz clic para ampliar)

Haz lo siguiente para configurar esta arquitectura:

  1. Configura tus servidores DNS locales como autorizados 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 de VPC compartida de producción y configura todos los registros de recursos en 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 para los recursos en esa zona.
  4. Establece una política de servidor DNS en el proyecto host para 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, establece una zona de DNS para reenviar corp.example.com a los servidores DNS locales.
  6. Establece una zona de intercambio de tráfico de DNS desde la red de VPC compartida de desarrollo hasta la red de VPC compartida de producción para example.com.
  7. Establece una zona de intercambio de tráfico de DNS desde la red de VPC compartida de producción hasta la red de VPC compartida de desarrollo para dev.gcp.example.com.
  8. Configura el reenvío en gcp.example.com en tus servidores DNS locales y apunta a una IP de reenvío entrante en la red de VPC compartida de producción.
  9. Asegúrate de que el firewall permita el tráfico de DNS en firewalls locales y de Google Cloud.
  10. En instancias de Cloud Router, agrega al entorno local un anuncio de ruta personalizado para el rango 35.199.192.0/19 en la red de VPC compartida de producción.

Arquitectura híbrida con una red de VPC central conectada a redes de VPC de radio

Otra opción es conectar la infraestructura local a una única red de VPC central mediante Cloud Interconnect o Cloud VPN. Puedes realizar un intercambio de tráfico de esta red de VPC con varias redes de VPC de radio mediante el intercambio de tráfico entre redes de VPC. Cada red de VPC de radio aloja sus propias zonas privadas en Cloud DNS. Las rutas personalizadas en el intercambio de tráfico entre redes de VPC y el anuncio de ruta personalizado en Cloud Router permiten el intercambio completo de rutas y la conectividad entre las redes de VPC locales y de radio. El intercambio de tráfico de DNS se ejecuta en paralelo con la conexión de intercambio de tráfico entre redes de VPC para permitir la resolución de nombres entre entornos.

Esta arquitectura se muestra en el siguiente diagrama:

Arquitectura híbrida con una red de VPC central conectada a redes de VPC de radio (haz clic para ampliar)
Arquitectura híbrida con una red de VPC central conectada a redes de VPC de radio (haz clic para ampliar)

Haz lo siguiente para configurar esta arquitectura:

  1. Configura tus servidores DNS locales como autorizados para corp.example.com.
  2. Configura una zona privada (por ejemplo, projectX.gcp.example.com) en Cloud DNS para cada VPC de radio y configura todos los registros de los recursos de esa zona.
  3. Establece una política de servidor DNS en el proyecto central para la red de VPC compartida de producción a fin de permitir el reenvío de DNS entrante.
  4. En la VPC central, crea una zona de DNS privada para corp.example.com y configura el reenvío de salida a los servidores DNS locales.
  5. Establece una zona de intercambio de tráfico de DNS de la VPC central a cada VPC de radio para projectX.gcp.example.com.
  6. Establece una zona de intercambio de tráfico de DNS de cada VPC de radio a la VPC central para example.com.
  7. Configura el reenvío en gcp.example.com en tus servidores DNS locales para que apunten a una dirección IP de reenvío entrante en la VPC central.
  8. Asegúrate de que el firewall permita el tráfico de DNS en firewalls locales y de Google Cloud.
  9. En instancias de Cloud Router, agrega al entorno local un anuncio de ruta personalizado para el rango 35.199.192.0/19 en la VPC central.
  10. (Opcional). Si también usas los nombres de DNS internos generados automáticamente, haz un intercambio de tráfico entre cada zona de proyecto de radio (por ejemplo, spoke-project-x.internal) y el proyecto central y reenvía todas las consultas de .internal de manera local.

Próximos pasos