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 documento, 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, 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 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 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 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 diferentes 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 puedes 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 ilustra una configuración de nombre de dominio que es coherente en tu red local y en Google Cloud.

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.

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.

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 mínimo privilegio para otorgar 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 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 de 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 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

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 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 no se pueden enrutar correctamente, a menos que tengas entornos separados locales.

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

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.

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.

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

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 garantizar que tus aplicaciones o 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 y la migración de aplicaciones híbridas que tienen dependencias en entornos locales y en la nube con una configuración de DNS de varios proveedores.

Google Cloud ofrece una solución de código abierto basada en octoDNS para ayudarte a configurar y operar un entorno con varios proveedores de DNS. La solución de DNS con varios proveedores aprovecha Cloud DNS como uno de tus proveedores de DNS en una configuración activa-activa (recomendado) o activa-pasiva para garantizar una arquitectura de DNS de 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 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.

• Para configurar Cloud DNS en una configuración de DNS pública de varios proveedores, consulta multi-provider-dns-with-clouddns.

¿Qué sigue?

• Para encontrar soluciones a problemas comunes que podrías tener cuando usas Cloud DNS, consulta Solución de problemas.
• Para obtener orientación sobre cómo abordar e implementar una configuración híbrida que usa Google Cloud, consulta la guía de soluciones Prácticas y patrones de nube híbrida y múltiples nubes.
• Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.