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 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 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 que crea 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 entrega 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.
  • El Servicio administrado para Microsoft Active Directory es un servicio endurecido y con alta disponibilidad que ejecuta Microsoft Active Directory 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.
  • 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 creas una estrategia para DNS en un entorno híbrido, es importante que te familiarices con tu 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 la configuración necesarias 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 de Google Cloud, consulta Usa el reenvío condicional para acceder a registros DNS locales.
  • 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:

  • Puedes tener nombres de dominio desvinculados 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, cada uno de ellos puede tener un subdominio independiente. Este es el patrón preferido, porque es fácil reenviar solicitudes entre entornos.

    También puedes usar nombres de dominio independientes, 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 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 digitales que solo tienen un espacio local pequeño.

  • Puedes usar el mismo dominio para Google Cloud y de forma local. En este caso, tanto Google Cloud como locales usan recursos que usan el dominio corp.example.com. Evita este patrón porque dificulta mucho 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 la figura 1, se muestra una configuración de nombre de dominio coherente en entre tu red local y Google Cloud.

Figura 1. Configuración de nombres de dominio coherentes 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. Puedes realizar 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 la Figura 2, se muestra esta disposición.

Figura 2. Una arquitectura de DNS híbrida que usa Cloud DNS y servidores DNS locales para proporcionar una resolución de DNS autorizada.
Figura 2. Una arquitectura de DNS híbrida que usa tanto Cloud DNS y los servidores DNS locales proporcionan acceso resolución de DNS.

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 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 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 autorizada todos los nombres de dominio internos. En ese caso, puedes usar un servidor de nombres alternativo para reenviar todas las solicitudes desde Google Cloud mediante el reenvío de DNS saliente.

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 ajuste de escala 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.

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. Puedes usar las zonas privadas y el reenvío de DNS entrante para migrar tu resolución de nombres local existente a Cloud DNS.

Este enfoque tiene las siguientes ventajas:

  • No necesitas mantener un servicio de DNS de alta disponibilidad de forma local.
  • 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 de 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 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. De forma alternativa, puedes configurar la zona en un proyecto de servicio con 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. Esta configuración muestra cómo se adjuntan 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 la función 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 funciones de IAM con el principio de mínimo privilegio

Usa el principio de seguridad de para otorgar el derecho a cambiar los registros DNS solo a de los miembros de tu organización que necesiten realizar esta tarea. Evita usar las funciones básicas roles porque podrían otorgar acceso a adicionales a 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 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 y las políticas de servidores

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

A fin de asegurarte de que puedes consultar registros DNS en tu entorno local, configura una zona de reenvío para el dominio que usas de forma local en 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 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 usa esta configuración se muestra en las 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 locales

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 entrante. El reenvío de DNS entrante 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 las Arquitecturas de referencia para DNS híbrido.

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

Asegúrate de que el tráfico DNS no se filtre en ningún lugar de tu red de VPC o el entorno local mediante los siguientes pasos:

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

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 reenvío de DNS entrante:

  • 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 de Google Cloud si configuras 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 saliente desde varias redes de VPC

No uses el reenvío saliente 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 como fuente. Por lo tanto, las respuestas y enrutados de forma correcta a menos que tengas entornos locales independientes.

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

Te recomendamos designar una sola red de VPC para consultar los servidores de nombres locales mediante el reenvío de salida. Luego, las redes de VPC adicionales pueden consultar los servidores de nombres locales mediante 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 de acuerdo con el orden de resolución de nombres de la red de VPC designada. Esta configuración se muestra en las 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

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 instancias de máquinas virtuales (VM) en varios proyectos se comuniquen entre sí, pero no cambia la resolución del nombre. Los recursos en cada red de 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 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 intercambio de tráfico 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 unidireccionalmente las solicitudes DNS y no requiere y 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 dns.networks.targetWithPeeringZone 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. Como se muestra en la figura 5, puedes agrupar todas las zonas .internal en 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 .internal en un concentrador.
Figura 5: El intercambio de tráfico de DNS se usa para organizar .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 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.

Usa la arquitectura de referencia que se mapee 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 que usa 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 mediante 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 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 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 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 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 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 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 múltiples redes de VPC de Google Cloud.
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 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 de 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 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 entrante delegando la resolución de gcp.example.com. a las direcciones IP virtuales de reenvío entrantes 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 de Google Cloud.
  10. En instancias de Cloud Router, agrega al entorno local una ruta anunciada personalizada para el rango de direcciones IP 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 usar Cloud Interconnect o Cloud VPN para conectarte la infraestructura local a una red de VPC de concentrador. 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 ruta personalizada en Cloud Router, permite el intercambio completo de rutas y conectividad entre redes de VPC locales y de todos los radios. 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 mediante el intercambio de tráfico entre redes de VPC.
Figura 8: Una arquitectura híbrida puede usar un concentrador red de VPC conectada a redes de VPC de radio.

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 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 a fin de permitir el reenvío de DNS entrante.
  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 entrante en la red de 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 una ruta anunciada personalizada para el rango de direcciones IP 35.199.192.0/19 en la red de VPC central 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 desde los entornos locales.

DNS público de varios proveedores con Cloud DNS

Como componente fundamental de las redes de aplicaciones, un DNS confiable es clave para lo que garantiza que las aplicaciones o los servicios estén disponibles para los usuarios. Puedes mejorar la disponibilidad y la resiliencia de tus aplicaciones y servicios si configuras varios proveedores de DNS. Cuando se configuran varios proveedores de DNS, tu aplicación o servicio puede estar disponible para los usuarios, incluso si hay una interrupción en uno de los proveedores de DNS. También puedes simplificar la implementación la migración de aplicaciones híbridas que tienen dependencias en entornos locales entornos 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. El DNS de varios proveedores aprovecha Cloud DNS como uno de tus proveedores de DNS en un activa-activa (recomendada) o activa-pasiva para garantizar arquitectura de DNS disponible. 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 registros DNS individuales, los cambios se propagan a las zonas de DNS correspondientes alojadas en Cloud DNS sin requerir ningún cambio en tus canalización de CI/CD.

¿Qué sigue?