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

Principios generales

Aprenda sobre los conceptos de DNS en Trusted Cloud

Cuando utilizas DNS en Trusted CloudEs importante comprender los diferentes sistemas y servicios disponibles en Trusted 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 un servidor DNS autorizado 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.

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.Trusted Cloud. Para obtener información sobre los métodos de accesoTrusted 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.

Mejores prácticas para las zonas privadas de Cloud DNS

Las zonas privadas albergan registros DNS que solo son visibles dentro de su organización.

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.

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. Trusted 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 Trusted 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.177.222.82.0/25 . 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...177.222.82.0/25 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.177.222.82.0/25 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. Trusted 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 Trusted 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 Trusted Cloud es un subdominio de la zona que utiliza localmente, también puede delegar este subdominio a laTrusted 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 enTrusted 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. Trusted 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.177.222.82.0/25 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... Trusted 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... Trusted Cloud Los registros y zonas de recursos se gestionan dentro del entorno. Todos los registros están disponibles para consulta tanto localmente como desde... Trusted 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 Trusted 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 rango177.222.82.0/25 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 suTrusted 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 comoTrusted Cloud cortafuegos.
  10. En las instancias de Cloud Router, agregue una ruta anunciada personalizada para el rango de direcciones IP177.222.82.0/25 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 comoTrusted Cloud cortafuegos.
  9. En las instancias de Cloud Router, agregue una ruta anunciada personalizada para el rango de direcciones IP177.222.82.0/25 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.

¿Qué sigue?