Prácticas recomendadas de Cloud DNS

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

Tanto para los usuarios como para las aplicaciones, es más fácil usar el sistema de nombres de dominio (DNS) para acceder a aplicaciones y servicios, ya que es más sencillo recordar un nombre y es más flexible que usar direcciones IP. En un entorno híbrido que consta de una plataforma local y una o varias plataformas en la 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 manualmente mediante un servidor DNS autorizado, como BIND en entornos UNIX o Linux, o Active Directory en entornos Microsoft Windows.

En este documento se describen las prácticas recomendadas para reenviar solicitudes de DNS privado entre entornos y asegurarse de que se pueda acceder a los servicios tanto desde entornos on-premise como desde Google Cloud.

Principios generales

Consulta información sobre los conceptos de DNS en Google Cloud

Cuando usas DNS en Google Cloud, es importante que conozcas los diferentes sistemas y servicios disponibles en Google Cloud para la resolución de DNS y los nombres de dominio:

• DNS interno es un servicio que crea automáticamente nombres de DNS para máquinas virtuales y balanceadores de carga internos en Compute Engine.
• Cloud DNS es un servicio que ofrece baja latencia y alta disponibilidad para las zonas de DNS. Puede actuar como servidor DNS autoritativo para zonas públicas visibles en Internet o para zonas privadas visibles solo en tu red.
• Servicio gestionado para Microsoft Active Directory es un servicio endurecido y de alta disponibilidad que ejecuta Microsoft Active Directory, incluido un controlador de dominio.
• DNS público es un servicio de Google que no forma parte de Google Cloud y que actúa como un resolvedor de DNS recursivo y abierto.
• Cloud Domains es un registrador de dominios que permite comprar, transferir y gestionar dominios en Google Cloud. Cloud Domains te permite interactuar con el sistema de registro de dominios a través de una API.

Identificar a las partes interesadas, las herramientas y los procesos

Cuando te plantees crear una estrategia de DNS en un entorno híbrido, es importante que te familiarices con tu arquitectura actual y que te pongas en contacto con todas las partes interesadas. Sigue estos pasos:

• Identifica y ponte en contacto con el administrador de los servidores DNS corporativos de tu organización. Pídeles información sobre las configuraciones necesarias para asignar tu configuración local a una arquitectura adecuada enGoogle Cloud. Para obtener información sobre los métodos para acceder a los registros DNSGoogle Cloud , consulta Usar el reenvío condicional para acceder a los registros DNS desde entornos on‐premise.
• 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 a los contactos del equipo de redes que puedan asegurarse de que el tráfico a los servidores de Cloud DNS se enruta correctamente.
• Familiarízate con tu estrategia de conectividad híbrida y con los patrones y las prácticas de nube híbrida y multinube.

Crea un estándar de nomenclatura coherente

Crea un estándar de nomenclatura coherente en toda tu organización. Por ejemplo, supongamos que tu organización usa example.com como nombre de dominio de segundo nivel y el dominio de los recursos públicos (por ejemplo, www.example.com). El lugar donde se alojan las zonas públicas no es relevante para los fines de este documento, ya que el objetivo es migrar zonas privadas.

Para asignar nombres a los recursos corporativos locales, puede elegir entre los siguientes patrones:

• Puedes tener nombres de dominio diferentes para los servidores locales y para Google Cloud. Este patrón usa un dominio independiente para los distintos entornos (por ejemplo, corp.example.com para los 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, ya que puedes reenviar solicitudes entre entornos.

  También puedes usar nombres de dominio independientes, como example.com y example.cloud.

• Puedes tener el dominio Google Cloud como subdominio del dominio que contiene servidores locales. Si se usa el dominio example.com, en las instalaciones se podría usar corp.example.com y Google Cloud podría usar gcp.corp.example.com. Este es un patrón habitual cuando la mayoría de los recursos permanecen en las instalaciones.

• Puedes tener el dominio local como subdominio del dominio que contiene los registrosGoogle Cloud . Con el dominio example.com, Google Cloud podría usar corp.example.com y el entorno local podría usar dc.corp.example.com. Este es un patrón poco habitual, pero se puede usar en organizaciones digitales que solo tengan una pequeña presencia local.

• Puedes usar el mismo dominio para Google Cloud y para las instalaciones locales. En este caso, tanto Google Cloud como el entorno local usan recursos que utilizan el dominio corp.example.com. Evita este patrón, ya que dificulta mucho la gestión de registros en un entorno híbrido. Solo es posible cuando usas un único sistema DNS autorizado.

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

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

En la figura 1 se muestra una configuración de nombre de dominio que es coherente tanto en su red local como en Google Cloud.

Para asignar nombres a los recursos de tu red de nube privada virtual (VPC), puedes seguir directrices como las que se indican en la guía de soluciones Prácticas recomendadas y arquitecturas de referencia para el diseño de VPC.

Elegir dónde se realiza la resolución de DNS

En un entorno híbrido, la resolución de DNS se puede llevar a cabo en diferentes ubicaciones. Puedes hacer lo siguiente:

• Usa un enfoque híbrido con dos sistemas DNS autoritativos.
• Mantener la resolución de DNS en las instalaciones.
• Mueve toda la resolución de DNS a Cloud DNS.

Te recomendamos que uses el enfoque híbrido, por lo que este documento se centra en él. Sin embargo, para que este documento esté completo, se describen brevemente los enfoques alternativos.

Usar un enfoque híbrido con dos sistemas de DNS autoritativos

Te recomendamos que utilices un enfoque híbrido con dos sistemas DNS autoritativos. En este enfoque:

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

En la figura 2 se muestra esta disposición.

El caso práctico que se muestra en la figura 2 es el preferido. Más adelante en esta página se explican los siguientes detalles:

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

Mantener la resolución de DNS en las instalaciones

Otra opción es seguir usando tu servidor DNS local 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 deGoogle Cloud mediante el reenvío de DNS saliente.

Este enfoque tiene las siguientes ventajas:

• Haces menos cambios en los procesos empresariales.
• Puedes seguir usando las herramientas que ya tienes.
• Puedes usar listas de denegación para filtrar solicitudes de DNS individuales en las instalaciones.

Sin embargo, tiene las siguientes desventajas:

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

Mover toda la resolución de DNS a Cloud DNS

Otra opción es migrar a Cloud DNS como servicio autoritativo para todas las resoluciones de dominio. Después, puedes usar zonas privadas y el reenvío de DNS entrante para migrar tu resolución de nombres local a Cloud DNS.

Este enfoque tiene las siguientes ventajas:

• No tienes que mantener un servicio DNS de alta disponibilidad en las instalaciones.
• Tu sistema puede usar Cloud DNS para aprovechar las ventajas de la monitorización y el registro centralizados.

Sin embargo, tiene las siguientes desventajas:

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

Prácticas recomendadas para zonas privadas de Cloud DNS

Las zonas privadas alojan registros DNS que solo se pueden ver dentro de tu organización. En este documento no se tratan las zonas públicas de Cloud DNS. 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.

Usar la automatización para gestionar zonas privadas en el proyecto host de la VPC compartida

Si utilizas redes de VPC compartida en tu organización, debes alojar todas las zonas privadas en Cloud DNS en el 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. También puedes configurar la zona en un proyecto de servicio mediante el enlace 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 definan 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 definan sus propios registros DNS en subdominios específicos. La aplicación verifica que los registros cumplen las reglas de tu organización.

También puedes poner 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