Prácticas recomendadas para Cloud DNS

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

Es más fácil que las personas y las aplicaciones utilicen el sistema de nombres de dominio (DNS) para dirigir las aplicaciones y los servicios, ya que el uso de un nombre es más fácil de recordar 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 autoritativo, como BIND en entornos de UNIX/Linux o Active Directory en entornos de Microsoft Windows.

En este documento, se describen las prácticas recomendadas para reenviar solicitudes de DNS privadas entre entornos con el objetivo de garantizar que los servicios se puedan dirigir desde entornos locales y dentro de Google Cloud.

Principios generales

Obtén más información sobre los conceptos de DNS en Google Cloud

Cuando usas DNS en Google Cloud, es importante comprender los diferentes sistemas y servicios disponibles en Google Cloud para la resolución de DNS y los 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 del DNS de baja latencia y alta disponibilidad. Puede actuar como un servidor DNS autoritativo para las zonas públicas que son visibles en Internet o las privadas que son visibles solo dentro de tu red.
  • El Servicio Administrado para Microsoft Active Directory es un servicio endurecido y con alta disponibilidad que ejecuta Microsoft Active Directory, incluido 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.
  • Cloud Domains es un registrador de dominios para comprar, transferir y administrar dominios dentro de Google Cloud. Cloud Domains te permite interactuar con el sistema de registro de dominios a través de una API.

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 con la arquitectura actual y te comuniques con todas las partes interesadas. Haz lo siguiente:

  • Identifica al administrador de los servidores DNS corporativos de tu organización y comunícate con este. Pídele información sobre los parámetros de configuración necesarios para asignar tu configuración local a una arquitectura adecuada en Google Cloud. Para obtener más información sobre los métodos de acceso a los registros DNS deGoogle Cloud , consulta Usa el reenvío condicional para acceder a registros DNS desde un entorno local.
  • Familiarízate con el software de DNS actual y, luego, 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 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 coherente

Crea un estándar de nombres coherente en toda tu organización. 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 permiso es la migración de zonas privadas.

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

  • Puedes tener diferentes nombres de dominio para los servidores locales y para Google Cloud. En este patrón, se usa un dominio independiente para los distintos entornos, por ejemplo, corp.example.com para tus servidores locales y gcp.example.com para todos los recursos en 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 puedes reenviar solicitudes entre entornos.

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

  • Puedes 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.

  • Puedes tener el dominio local como un subdominio del dominio que contiene los registros deGoogle 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 digitales que solo tienen un espacio local pequeño.

  • Puedes usar el mismo dominio para Google Cloud y los entornos locales. En este caso, tanto Google Cloud como los entornos locales usan recursos que usan el dominio corp.example.com. Evita 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 de DNS autoritativo.

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 la figura 1, se ilustra una configuración de nombres de dominio coherente en tu red local y en Google Cloud.

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

Para asignar nombres a recursos dentro de tu red de nube privada virtual (VPC), puedes seguir lineamientos, como los que aparecen en la guía de soluciones 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. También puedes realizar las siguientes acciones:

  • Utilizar un enfoque híbrido con dos sistemas de DNS autoritativos
  • 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, sucede lo siguiente:

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

En la figura 2, se muestra esta disposición.

Figura 2. Una arquitectura de DNS híbrida que usa servidores DNS locales y de Cloud DNS para proporcionar resolución de DNS autoritativo.
Figura 2. Una arquitectura de DNS híbrida que usa tanto Cloud DNS como servidores DNS locales proporciona resolución de DNS autoritativo.

La situación que se muestra en la figura 2 es el caso de uso preferido. Los siguientes detalles se analizan más adelante en esta página:

  • Cómo configurar el reenvío entre entornos con 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 redes de 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 confiable todos los nombres de dominio internos En ese caso, puedes usar un servidor de nombres alternativo para reenviar todas las solicitudes desde Google Cloud con el reenvío de DNS de salida.

Este enfoque tiene las siguientes ventajas:

  • Realizas menos cambios en los procesos empresariales.
  • Puedes seguir usando las herramientas existentes.
  • Puedes usar las listas de bloqueo para filtrar solicitudes individuales de DNS locales.

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 con los entornos locales para las operaciones de DNS.
  • Es posible que te resulte difícil integrar entornos altamente flexibles, como los grupos de instancias con escalado automático.
  • Es posible que el sistema no sea compatible con productos como Dataproc, porque esos productos dependen de la resolución inversa de los nombres de instancias de Google Cloud.

Transfiere toda la resolución de DNS a Cloud DNS

Otro enfoque es migrar a Cloud DNS como un servicio autoritativo para la resolución de todos los dominios. Puedes usar las zonas privadas y el reenvío de DNS de entrada para migrar tu resolución de nombres local existente a Cloud DNS.

Este enfoque tiene las siguientes ventajas:

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

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 en Cloud DNS no se incluyen en este documento. Las zonas públicas abarcan 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.

Usa la automatización para administrar zonas privadas en el proyecto host de 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 conectadas a la red de VPC compartida. De forma alternativa, puedes configurar la zona en un proyecto de servicio con 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).
Figura 3. En esta configuración, se muestra cómo se conectan las zonas privadas a una VPC compartida.

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 app 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, una cuenta de servicio con el rol de administrador de DNS de IAM en el proyecto host puede implementar de forma automática los cambios después de que se aprueben.

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

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

Si es importante separar la capacidad de crear zonas del 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 y políticas de servidor de DNS

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 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.

Usa 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 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 DNS internos de Compute Engine, y las direcciones IP externas se siguen resolviendo sin necesidad de 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 Arquitecturas de referencia para DNS híbrido.

Usa servidores de nombres alternativos solo si el tráfico de DNS debe supervisarse o filtrarse de forma local y si el registro DNS privado no puede cumplir con tus requisitos.

Usa las políticas de servidor DNS para permitir consultas desde un entorno local

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 con reenvío de DNS de entrada. El reenvío de DNS de entrada permite que tu sistema consulte todas las zonas privadas del proyecto, así como las direcciones IP internas de DNS y las zonas de intercambio de tráfico.

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

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

Para asegurarte de que el tráfico de DNS no se filtre en ningún lugar dentro de tu red de VPC o entorno local, haz lo siguiente:

  • Asegúrate de que tu firewall local apruebe las consultas de 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 de direcciones IP 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. En instancias de Cloud Router, agrega una ruta anunciada personalizada para el rango de direcciones IP 35.199.192.0/19 en tu red de VPC al entorno local.

Usa el reenvío condicional para acceder a registros DNS desde un entorno 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 desde un entorno local. En cada caso, el acceso a los registros se realiza con el reenvío de DNS de entrada:

  • Reenvío condicional. El uso del reenvío condicional significa que tu servidor DNS corporativo reenvía 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, también puedes delegar este subdominio al servidor de nombres deGoogle Cloud configurando las entradas NS dentro de tu zona. Cuando usas 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. Cloud DNS no admite transferencias de zona, por lo que no puedes usar transferencias de zona para sincronizar registros DNS con tus servidores DNS locales.

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

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

Figura 4. Se produce un problema cuando varias VPC reenvían tráfico fuera de sus redes.
Figura 4. Problema con varias redes de VPC que realizan el reenvío de salida.

Te recomendamos designar una sola red de VPC para consultar los servidores de nombres locales con el reenvío de salida. Luego, las redes de VPC adicionales pueden consultar los servidores de nombres locales con la orientación a la red de VPC designada con una zona de intercambio de tráfico 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 de VPC designada. Esta configuración se muestra en Arquitecturas de referencia para DNS híbrido.

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

El intercambio de tráfico entre redes de VPC no es lo mismo que el intercambio de tráfico de DNS. El intercambio de tráfico entre redes de VPC permite que las instancias de máquinas virtuales (VM) en varios proyectos se comuniquen entre sí, pero no cambia la resolución de nombres. Los recursos en cada red de VPC aún 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 red de VPC. Esto te permite reenviar solicitudes a diferentes entornos de Google Cloud , independientemente de si las redes de VPC están interconectadas.

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

El intercambio de tráfico de DNS reenvía de forma unidireccional las solicitudes de DNS y no requiere una relación bidireccional entre las redes de 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 de IAM dns.networks.targetWithPeeringZone 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 el rol de intercambio de tráfico 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 VMs que crea el servicio de DNS interno, puedes usar el intercambio de tráfico de DNS para reenviar las zonas projectname.internal a otros proyectos. Como se muestra en la figura 5, puedes agrupar todas las zonas .internal de un proyecto central para que sean accesibles desde tu red local.

Figura 5. El intercambio de tráfico de DNS se usa para organizar todas las zonas internas en un concentrador.
Figura 5. El intercambio de tráfico de DNS se usa para organizar todas las zonas .internal en un concentrador.

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 en donde se 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 .

Usa la arquitectura de referencia que se asigne a tu diseño de red de VPC:

  • Arquitectura híbrida con una sola red de VPC compartida: Usa una sola red de VPC conectada desde o hacia entornos locales.

  • Arquitectura híbrida con varias redes de VPC independientes: Conecta varias redes de VPC a entornos locales a través de diferentes túneles VPN o adjuntos de VLAN, y comparte la misma infraestructura de DNS de manera local.

  • Arquitectura híbrida con una red de VPC central conectada a redes de VPC de radio: Usa el intercambio de tráfico entre redes 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 redes de VPC de Google Cloud con uno o varios túneles de Cloud VPN, o conexiones de interconexión dedicada o interconexión de socio. 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 de uso más común es una sola 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.
Figura 6. Una arquitectura híbrida usa una sola red de VPC compartida para conectarse a una red local.

Haz lo siguiente para configurar esta arquitectura:

  1. Configura tus servidores DNS locales como autoritativos para corp.example.com.
  2. Configura una zona privada autoritativo (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 con el objetivo de permitir el reenvío de DNS de entrada.
  4. Establece una zona de reenvío de DNS que reenvíe corp.example.com a los servidores DNS locales. La red de 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 de entrada 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 una ruta anunciada personalizada 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 deGoogle Cloud no están conectadas entre sí a través del intercambio de tráfico entre redes de VPC. Todas las redes de VPC usan túneles independientes de Cloud VPN o adjuntos de VLAN para conectarse a tus entornos locales.

Como se muestra en la figura 7, un caso de uso típico para 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.
Figura 7. Una arquitectura híbrida puede usar varias redes de VPC independientes.

Haz lo siguiente para configurar esta arquitectura:

  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 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 de 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 de entrada.
  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 prod.gcp.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 de entrada delegando la resolución de gcp.example.com. a las direcciones IP virtuales de reenvío de entrada de Cloud DNS en tus servidores de nombres locales.
  9. Asegúrate de que el firewall permita el tráfico de DNS en firewalls locales y deGoogle Cloud .
  10. En instancias de Cloud Router, agrega una ruta anunciada personalizada para el rango de direcciones IP 35.199.192.0/19 en la red de VPC compartida de producción al entorno local.

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

Otra opción es usar Cloud Interconnect o Cloud VPN para conectar la infraestructura local a una red de VPC central. Como se muestra en la figura 8, puedes usar el intercambio de tráfico entre redes de VPC para intercambiar tráfico en una red de VPC con varias redes de VPC de radio. 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.

En el siguiente diagrama, se muestra esta arquitectura.

Figura 8. Una arquitectura híbrida puede usar una red de VPC central conectada a redes de VPC de radio a través del intercambio de tráfico entre redes de VPC.
Figura 8. Una arquitectura híbrida puede usar una red de VPC central conectada a redes de VPC de radio.

Haz lo siguiente para configurar esta arquitectura:

  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. Establece una política de servidor DNS en el proyecto central para la red de VPC compartida de producción con el objetivo de permitir el reenvío de DNS de entrada.
  4. En la red de 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 desde la red de VPC central hasta cada red de VPC de radio para projectX.gcp.example.com.
  6. Establece una zona de intercambio de tráfico de DNS desde cada red de VPC de radio a la red de 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 de entrada en la red de VPC central.
  8. Asegúrate de que el firewall permita el tráfico de DNS en firewalls locales y deGoogle Cloud .
  9. En instancias de Cloud Router, agrega una ruta anunciada personalizada para el rango de direcciones IP 35.199.192.0/19 en la red de VPC del concentrador al entorno local.
  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.

DNS público de varios proveedores con Cloud DNS

Como componente fundamental de las redes de aplicaciones, un DNS confiable es clave para garantizar que tus aplicaciones o servicios estén disponibles para tus usuarios. Puedes mejorar la disponibilidad y la capacidad de recuperación de tus aplicaciones y servicios configurando varios proveedores de DNS. Cuando se configuran varios proveedores de DNS, tu aplicación o servicio pueden estar disponibles para los usuarios, incluso si hay una interrupción con uno de los proveedores de DNS. También puedes simplificar la implementación y la migración de aplicaciones híbridas que tienen dependencias en entornos locales y de 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 operar un entorno con varios proveedores de DNS. La solución de DNS de varios proveedores aprovecha Cloud DNS como uno de tus proveedores de DNS en una configuración activo-activo (recomendada) o activo-pasivo para garantizar una arquitectura de DNS con alta disponibilidad. Después de implementar la solución, octoDNS realiza una sincronización única y continua entre tus zonas de DNS actuales y las zonas de DNS administradas alojadas en Cloud DNS. Cuando se actualizan los registros DNS individuales, los cambios se propagan a las zonas del DNS correspondientes alojadas en Cloud DNS sin necesidad de realizar cambios en tus canalizaciones de CI/CD.

¿Qué sigue?