Mejores prácticas para DNS en la nube

Este documento proporciona las mejores prácticas para zonas privadas, reenvío de DNS y arquitecturas de referencia para DNS híbrido.

Es más fácil para los usuarios y las aplicaciones usar el Sistema de Nombres de Dominio (DNS) para acceder a aplicaciones y servicios, ya que usar un nombre es más fácil de recordar y más flexible que usar direcciones IP. En un entorno híbrido, compuesto por plataformas locales y una o más plataformas en la nube, a menudo es necesario acceder a los registros DNS de los recursos internos desde diferentes entornos. Tradicionalmente, los registros DNS locales se administran manualmente mediante un servidor DNS autorizado, como BIND en entornos UNIX/Linux o Active Directory en entornos Microsoft Windows.

Este documento describe las mejores prácticas para reenviar solicitudes de DNS privadas entre entornos para garantizar que los servicios puedan abordarse tanto desde entornos locales como dentro de ellos. Google Cloud.

Principios generales

Aprenda sobre los conceptos de DNS en Google Cloud

Cuando utilizas DNS en Google CloudEs importante comprender los diferentes sistemas y servicios disponibles en Google Cloud Para resolución de DNS y nombres de dominio:

  • El DNS interno es un servicio que crea automáticamente nombres DNS para máquinas virtuales y balanceadores de carga internos en Compute Engine .
  • Cloud DNS es un servicio que ofrece servicio de zonas DNS de baja latencia y alta disponibilidad. Puede actuar como servidor DNS autorizado para zonas públicas visibles en internet o para zonas privadas visibles solo dentro de su red.
  • El servicio administrado para Microsoft Active Directory es un servicio reforzado y de 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 que actúa como un solucionador de DNS abierto y recursivo.
  • Cloud Domains es un registrador de dominios para comprar, transferir y administrar dominios dentro Google Cloud. Cloud Domains le permite interactuar con el sistema de registro de dominios a través de una API.

Identificar partes interesadas, herramientas y procesos

Al considerar la creación de una estrategia de DNS en un entorno híbrido, es importante familiarizarse con su arquitectura actual y contactar a todas las partes interesadas. Haga lo siguiente:

  • Identifique y contacte al administrador de los servidores DNS corporativos de su organización. Solicítele información sobre las configuraciones necesarias para adaptar su configuración local a una arquitectura adecuada.Google Cloud. Para obtener información sobre los métodos de accesoGoogle Cloud Registros DNS, consulte Usar reenvío condicional para acceder a registros DNS desde las instalaciones locales .
  • Familiarícese con el software DNS actual e identifique los nombres de dominio que se utilizan de forma privada dentro de su organización.
  • Identifique contactos en el equipo de redes que puedan asegurarse de que el tráfico a los servidores DNS en la nube se enrute correctamente.
  • Familiarícese con su estrategia de conectividad híbrida y con los patrones y prácticas híbridos y multicloud.

Crear un estándar de nombres consistente

Cree un estándar de nombres coherente en toda su organización. Por ejemplo, supongamos que su organización utiliza example.com como nombre de dominio de segundo nivel y el dominio para los recursos públicos (por ejemplo, www.example.com ). El alojamiento de las zonas públicas es irrelevante para este documento, ya que el objetivo es migrar las zonas privadas.

Para nombrar los recursos corporativos locales, puede elegir entre los siguientes patrones:

  • Puede tener diferentes nombres de dominio para servidores locales y paraGoogle Cloud Este patrón utiliza un dominio separado para sus diferentes entornos; por ejemplo, corp.example.com para sus servidores locales y gcp.example.com para todos los recursos en Google CloudSi utiliza otros entornos de nube pública, cada uno puede tener un subdominio independiente. Este es el patrón preferido, ya que permite reenviar solicitudes entre entornos.

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

  • Puedes tener el Google Cloud Dominio como subdominio del dominio que contiene los servidores locales. Con el dominio example.com , los servidores locales podrían 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 permanecen en las instalaciones.

  • Puede tener el dominio local como un subdominio del dominio que contieneGoogle Cloud registros. Usando el dominio example.com , Google CloudPodría usar corp.example.com y en las instalaciones locales, dc.corp.example.com . Este patrón es poco común, pero podría usarse en organizaciones digitales con una presencia local limitada.

  • Puedes utilizar el mismo dominio para Google Cloud y para instalaciones locales. En este caso, ambos Google Cloud Y los recursos locales que usan el dominio corp.example.com se utilizan. Evite este patrón, ya que dificulta considerablemente la gestión de registros en un entorno híbrido; solo es posible cuando se utiliza un único sistema DNS autoritativo.

El resto de esta página utiliza los siguientes nombres de dominio:

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

La Figura 1 ilustra una configuración de nombre de dominio que es consistente tanto en su red local como en su red local. Google Cloud.

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

Para nombrar recursos dentro de su red de nube privada virtual (VPC), puede seguir pautas como las de la guía de soluciones Mejores prácticas y arquitecturas de referencia para el diseño de VPC .

Elija dónde se realiza la resolución DNS

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

  • Utilice un enfoque híbrido con dos sistemas DNS autorizados.
  • Mantenga la resolución de DNS en las instalaciones.
  • Mueva toda la resolución de DNS a Cloud DNS.

Recomendamos el enfoque híbrido, por lo que este documento se centra en él. Sin embargo, para mayor exhaustividad, se describen brevemente los enfoques alternativos.

Utilice un enfoque híbrido con dos sistemas DNS autorizados

Recomendamos utilizar un enfoque híbrido con dos sistemas DNS autoritativos. En este enfoque:

  • Resolución DNS autorizada para su dominio privado Google Cloud El entorno lo realiza Cloud DNS.
  • La resolución de DNS autorizada para recursos locales está alojada por servidores DNS existentes en las instalaciones.

La figura 2 muestra esta disposición.

Figura 2. Una arquitectura de DNS híbrida que utiliza tanto DNS en la nube como servidores DNS locales para proporcionar una resolución DNS autorizada.
Figura 2. Una arquitectura de DNS híbrida que utiliza tanto DNS en la nube como servidores DNS locales proporciona una resolución de DNS autorizada.

El escenario que se muestra en la figura 2 es el caso de uso preferido. Los siguientes detalles se explican más adelante en esta página:

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

Mantenga la resolución de DNS en las instalaciones

Una alternativa es seguir usando su servidor DNS local actual para alojar con autoridad todos los nombres de dominio internos. En ese caso, puede usar un servidor de nombres alternativo para reenviar todas las solicitudes desdeGoogle Cloud a través del reenvío de DNS saliente.

Este enfoque tiene las siguientes ventajas:

  • Realiza menos cambios en los procesos de negocio.
  • Puede seguir utilizando sus herramientas existentes.
  • Puede utilizar listas de denegación para filtrar solicitudes de DNS individuales en las instalaciones.

Sin embargo, tiene las siguientes desventajas:

  • Solicitudes de DNS de Google Cloud tienen mayor latencia.
  • Su sistema depende de la conectividad a entornos locales para las operaciones de DNS.
  • Puede resultarle difícil integrar entornos altamente flexibles, como 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 Google Cloudnombres de instancia.

Trasladar toda la resolución de DNS a Cloud DNS

Otra opción es migrar a Cloud DNS como servicio autorizado para la resolución de todos los dominios. Luego, puede usar zonas privadas y el reenvío DNS entrante para migrar su resolución de nombres local actual a Cloud DNS.

Este enfoque tiene las siguientes ventajas:

  • No es necesario mantener un servicio DNS de alta disponibilidad en las instalaciones.
  • Su sistema puede usar Cloud DNS para aprovechar el registro y la supervisión centralizados.

Sin embargo, tiene las siguientes desventajas:

  • Las solicitudes de DNS locales tienen mayor latencia.
  • Su sistema requiere una conexión confiable a su red VPC para la resolución de nombres.

Mejores prácticas para las zonas privadas de Cloud DNS

Las zonas privadas alojan registros DNS visibles solo dentro de la organización. Las zonas públicas de Cloud DNS no se abordan en este documento. Estas zonas 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.

Utilice la automatización para administrar zonas privadas en el proyecto de host de VPC compartida

Si utiliza redes de VPC compartidas en su organización, debe alojar todas las zonas privadas en Cloud DNS dentro del proyecto host. Todos los proyectos de servicio pueden acceder automáticamente a los registros de las zonas privadas asociadas a la red de VPC compartida. Como alternativa, puede configurar la zona en un proyecto de servicio mediante el enlace entre proyectos .

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

Figura 3. Zonas privadas alojadas en una red VPC compartida (haga clic para ampliar).
Figura 3. Esta configuración muestra cómo se conectan las zonas privadas a una VPC compartida.

Si desea que los equipos configuren sus propios registros DNS, le recomendamos automatizar la creación de registros DNS. Por ejemplo, puede crear una aplicación web o una API interna donde los usuarios configuren sus propios registros DNS en subdominios específicos. La aplicación verifica que los registros cumplan con las reglas de su organización.

Como alternativa, puede colocar su 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 automáticamente los cambios después de que hayan sido aprobados.

Establecer roles de IAM utilizando el principio del mínimo privilegio

Utilice el principio de seguridad de mínimo privilegio para otorgar el derecho a modificar registros DNS solo a quienes en su organización necesiten realizar esta tarea. Evite usar roles básicos , ya que podrían otorgar acceso a recursos adicionales a los que el usuario necesita. Cloud DNS ofrece roles y permisos que permiten otorgar acceso de lectura y escritura específico para DNS.

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

Mejores prácticas 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 DNS entre sus servidores locales y locales. Google Cloud Entorno. Dispone de varias opciones para configurar el reenvío de DNS. La siguiente sección enumera las prácticas recomendadas para la configuración de DNS híbrido. Estas prácticas recomendadas se ilustran en las Arquitecturas de referencia para DNS híbrido .

Utilice zonas de reenvío para consultar servidores locales

Para garantizar que pueda consultar registros DNS en su entorno local, configure una zona de reenvío para el dominio que utiliza localmente para sus recursos corporativos (como corp.example.com ). Este enfoque es preferible a una política DNS que habilite un servidor de nombres alternativo . Conserva el acceso a los nombres DNS internos de Compute Engine y las direcciones IP externas se resuelven 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 Arquitecturas de referencia para DNS híbrido .

Utilice servidores de nombres alternativos solo si todo el tráfico DNS necesita ser monitoreado o filtrado localmente y si el registro DNS privado no puede satisfacer sus requisitos.

Utilice políticas de servidor DNS para permitir consultas desde las instalaciones locales

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

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

Abierto Google Cloud y firewalls locales para permitir el tráfico DNS

Asegúrese de que el tráfico DNS no se filtre en ningún lugar dentro de su red VPC o entorno local haciendo lo siguiente:

  • Asegúrese de que su firewall local pase las consultas de Cloud DNS. Cloud DNS envía consultas desde el rango de direcciones IP.35.199.192.0/19 . DNS utiliza el puerto UDP 53 o el puerto TCP 53, dependiendo del tamaño de la solicitud o respuesta.

  • Asegúrese de que su servidor DNS no bloquee las consultas. Si su servidor DNS local solo acepta solicitudes de direcciones IP específicas, asegúrese de que el rango de direcciones IP...35.199.192.0/19 Está incluido.

  • Asegúrese de que el tráfico pueda fluir desde las instalaciones locales a sus direcciones IP de reenvío. En las instancias de Cloud Router, agregue una ruta anunciada personalizada para el rango de direcciones IP.35.199.192.0/19 en su red VPC al entorno local.

Utilice el reenvío condicional para acceder a los registros DNS desde las instalaciones locales

Con Cloud DNS, para acceder a registros privados alojados en servidores DNS corporativos locales, solo puede usar zonas de reenvío . Sin embargo, según el software de servidor DNS que utilice, podría tener varias opciones para acceder a los registros DNS. Google Cloud Desde las instalaciones locales. En cada caso, el acceso a los registros se realiza mediante el reenvío DNS entrante :

  • Reenvío condicional . Usar el reenvío condicional significa que su servidor DNS corporativo reenvía las solicitudes de zonas o subdominios específicos a las direcciones IP de reenvío en Google CloudRecomendamos este enfoque porque es el menos complejo y le permite supervisar de forma centralizada todas las solicitudes DNS en los servidores DNS corporativos.

  • Delegación . Si tu zona privada está activada Google Cloud es un subdominio de la zona que utiliza localmente, también puede delegar este subdominio a laGoogle Cloud Servidor de nombres configurando entradas NS dentro de su zona. Al usar esta configuración, los clientes pueden comunicarse con las direcciones IP de reenvío enGoogle Cloud directamente, así que asegúrese de que el firewall pase estas solicitudes.

  • Transferencias de zona . Cloud DNS no admite transferencias de zona, por lo que no puede usarlas para sincronizar registros DNS con sus servidores DNS locales.

Utilice el emparejamiento DNS para evitar el reenvío saliente desde múltiples redes VPC

No utilice el reenvío saliente a sus servidores DNS locales desde múltiples redes VPC porque crea problemas con el tráfico de retorno. Google Cloud Acepta respuestas de sus servidores DNS solo si se enrutan a la red VPC desde la que se originó la consulta. Sin embargo, las consultas de cualquier red VPC tienen el mismo rango de direcciones IP.35.199.192.0/19 Como origen. Por lo tanto, las respuestas no se pueden enrutar correctamente a menos que se cuente con entornos locales separados.

Figura 4. Se produce un problema cuando varias VPC reenvían tráfico fuera de sus redes.
Figura 4. Problema al tener múltiples redes VPC realizando reenvío saliente.

Recomendamos designar una única red de VPC para consultar los servidores de nombres locales mediante el reenvío de salida. Posteriormente, otras redes de VPC podrán consultar los servidores de nombres locales mediante la red de VPC designada con una zona de emparejamiento 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 las Arquitecturas de referencia para DNS híbrido .

Comprenda la diferencia entre el emparejamiento de DNS y el emparejamiento de red VPC

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

Por el contrario, mediante el emparejamiento DNS, puede permitir que las solicitudes se reenvíen para zonas específicas a otra red VPC. Esto le permite reenviar solicitudes a diferentes... Google Cloud entornos, independientemente de si las redes VPC están interconectadas.

El emparejamiento de redes VPC y el emparejamiento DNS también se configuran de forma diferente. Para el emparejamiento de redes VPC, ambas redes VPC deben establecer una relación de emparejamiento con la otra. El emparejamiento es entonces automáticamente bidireccional.

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

Si utiliza nombres generados automáticamente, utilice el emparejamiento DNS para zonas internas

Si usa los nombres generados automáticamente para las máquinas virtuales que crea el servicio DNS interno, puede usar el emparejamiento DNS para reenviar las zonas projectname.internal a otros proyectos. Como se muestra en la figura 5, puede agrupar todas las zonas .internal en un proyecto de concentrador para que sean accesibles desde su red local.

Figura 5. El emparejamiento DNS se utiliza para organizar todas las zonas internas en un concentrador.
Figura 5. El peering DNS se utiliza para organizar todas las zonas .internal en un concentrador.

Si tiene problemas, siga la guía de solución de problemas

La guía de solución de problemas de DNS en la nube proporciona instrucciones para resolver errores comunes que puede encontrar al configurar DNS en la nube.

Arquitecturas de referencia para DNS híbrido

Esta sección proporciona algunas arquitecturas de referencia para escenarios comunes que utilizan zonas privadas de Cloud DNS en un entorno híbrido. En cada caso, tanto los recursos locales como... Google Cloud Los registros y zonas de recursos se gestionan dentro del entorno. Todos los registros están disponibles para consulta tanto localmente como desde... Google Cloud anfitriones.

Utilice la arquitectura de referencia que corresponde al diseño de su red VPC:

  • Arquitectura híbrida que utiliza una única red VPC compartida: utiliza una única red VPC conectada hacia o desde entornos locales.

  • Arquitectura híbrida que utiliza múltiples redes VPC independientes: conecta múltiples redes VPC a entornos locales a través de diferentes túneles VPN o conexiones VLAN y comparte la misma infraestructura DNS local.

  • Arquitectura híbrida que utiliza una red VPC concentradora conectada a redes VPC radiales: utiliza el emparejamiento de redes VPC para tener una red VPC concentradora conectada a múltiples redes VPC radiales independientes.

En cada caso, el entorno local está conectado al Google CloudRedes VPC mediante uno o varios túneles VPN en la nube o conexiones de interconexión dedicada o de socios. El método de conexión utilizado para cada red VPC es irrelevante.

Arquitectura híbrida que utiliza una única red VPC compartida

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

Figura 6. Una arquitectura híbrida utiliza una única red VPC compartida para conectarse a una red local.
Figura 6. Una arquitectura híbrida utiliza una única red VPC compartida para conectarse a una red local.

Para configurar esta arquitectura:

  1. Configure sus servidores DNS locales como autorizados para corp.example.com .
  2. Configure una zona privada autorizada (por ejemplo, gcp.example.com ) en Cloud DNS en el proyecto host de la red VPC compartida y configure todos los registros para los recursos en esa zona.
  3. Establezca una política de servidor DNS en el proyecto host para la red VPC compartida para permitir el reenvío de DNS entrante.
  4. Establezca una zona de reenvío DNS que redireccione corp.example.com a los servidores DNS locales. La red VPC compartida debe estar autorizada para consultar la zona de reenvío.
  5. Configure el reenvío a gcp.example.com en sus servidores DNS locales, apuntando a una dirección IP de reenvío entrante en la red VPC compartida.
  6. Asegúrese de que el tráfico DNS esté permitido en su firewall local.
  7. En las instancias de Cloud Router, agregue una ruta anunciada personalizada para el rango35.199.192.0/19 al entorno local.

Arquitectura híbrida que utiliza múltiples redes VPC independientes

Otra opción para las arquitecturas híbridas es tener varias redes de VPC independientes. Estas redes de VPC en suGoogle Cloud Los entornos no están conectados entre sí mediante el emparejamiento de redes VPC. Todas las redes VPC utilizan túneles VPN en la nube o conexiones VLAN independientes para conectarse a sus 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 separados que no se comunican entre sí, pero comparten servidores DNS.

Figura 7. Una arquitectura híbrida puede utilizar múltiples redes VPC independientes.
Figura 7. Una arquitectura híbrida puede utilizar múltiples redes VPC independientes.

Para configurar esta arquitectura:

  1. Configure sus servidores DNS locales como autorizados para corp.example.com .
  2. Configure 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 configure todos los registros para los recursos en esa zona.
  3. Configure una zona privada (por ejemplo, dev.gcp.example.com ) en Cloud DNS en el proyecto host de la red VPC compartida de desarrollo y configure todos los registros para los recursos en esa zona.
  4. Establezca una política de servidor DNS en el proyecto host para la red VPC compartida de producción y permita el reenvío de DNS entrante.
  5. En la red VPC compartida de producción, configure una zona DNS para reenviar corp.example.com a los servidores DNS locales.
  6. Establezca una zona de intercambio de DNS desde la red VPC compartida de desarrollo a la red VPC compartida de producción para prod.gcp.example.com .
  7. Establezca una zona de emparejamiento de DNS desde la red de VPC compartida de producción a la red de VPC compartida de desarrollo para dev.gcp.example.com .
  8. Configure 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 sus servidores de nombres locales.
  9. Asegúrese de que el firewall permita el tráfico DNS tanto en las instalaciones locales comoGoogle Cloud cortafuegos.
  10. En las instancias de Cloud Router, agregue una ruta anunciada personalizada para el rango de direcciones IP35.199.192.0/19 en la red VPC compartida de producción al entorno local.

Arquitectura híbrida que utiliza una red VPC central conectada a redes VPC radiales

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

El siguiente diagrama muestra esta arquitectura.

Figura 8. Una arquitectura híbrida puede utilizar una red VPC central conectada a redes VPC radiales mediante el emparejamiento de redes VPC.
Figura 8. Una arquitectura híbrida puede utilizar una red VPC concentradora conectada a redes VPC radiales.

Para configurar esta arquitectura:

  1. Configure sus servidores DNS locales como autorizados para corp.example.com .
  2. Configure una zona privada (por ejemplo, projectX.gcp.example.com ) en Cloud DNS para cada red VPC radial y configure todos los registros para los recursos en esa zona.
  3. Establezca una política de servidor DNS en el proyecto central para la red VPC compartida de producción para permitir el reenvío de DNS entrante.
  4. En la red VPC del concentrador, cree una zona DNS privada para corp.example.com y configure el reenvío saliente a los servidores DNS locales.
  5. Establezca una zona de intercambio de DNS desde la red VPC central a cada red VPC radial para projectX.gcp.example.com .
  6. Establezca una zona de emparejamiento de DNS desde cada red VPC radial a la red VPC central, por ejemplo, example.com .
  7. Configure el reenvío a gcp.example.com en sus servidores DNS locales para apuntar a una dirección IP de reenvío entrante en la red VPC del concentrador.
  8. Asegúrese de que el firewall permita el tráfico DNS tanto en las instalaciones locales comoGoogle Cloud cortafuegos.
  9. En las instancias de Cloud Router, agregue una ruta anunciada personalizada para el rango de direcciones IP35.199.192.0/19 en la red VPC del concentrador al entorno local.
  10. (Opcional) Si también usa los nombres DNS internos generados automáticamente, empareje cada zona del proyecto radial (por ejemplo, spoke-project-x.internal ) con el proyecto central y reenvíe todas las consultas para .internal desde las instalaciones locales.

DNS público multiproveedor que utiliza Cloud DNS

Como componente fundamental de la red de aplicaciones, un DNS confiable es clave para garantizar la disponibilidad de sus aplicaciones o servicios para sus usuarios. Puede mejorar la disponibilidad y resiliencia de sus aplicaciones y servicios configurando múltiples proveedores de DNS. Al configurar varios proveedores de DNS, su aplicación o servicio puede estar disponible para sus usuarios incluso si se produce una interrupción en uno de ellos. También puede simplificar la implementación y la migración de aplicaciones híbridas que dependen de entornos locales y en la nube con una configuración de DNS multiproveedor.

Google Cloud Ofrece una solución de código abierto basada en octoDNS para ayudarle a configurar y operar un entorno con múltiples proveedores de DNS. Esta solución de DNS multiproveedor utiliza Cloud DNS como uno de sus proveedores de DNS en una configuración activo-activo (recomendado) o activo-pasivo para garantizar una arquitectura de DNS de alta disponibilidad. Tras implementar la solución, octoDNS realiza una sincronización única y continua entre sus zonas DNS actuales y las zonas DNS administradas alojadas en Cloud DNS. Al actualizar los registros DNS individuales, los cambios se propagan a las zonas DNS correspondientes alojadas en Cloud DNS sin necesidad de modificar sus procesos de CI/CD.

¿Qué sigue?