Diseño de una solución de DNS híbrido con Azure

En esta arquitectura de referencia se muestra cómo diseñar una solución del Sistema de nombres de dominio (DNS) híbrido para resolver nombres de cargas de trabajo que se hospedan de forma local y en Microsoft Azure. Esta arquitectura funciona para los usuarios y otros sistemas que se conectan desde el entorno local y la red pública de Internet.

Architecture

Descargue un archivo Visio de esta arquitectura.

Flujo de trabajo

La arquitectura consta de los siguientes componentes:

• Red local. La red local representa un único centro de datos que está conectado a Azure a través de una conexión de Azure ExpressRoute o de red privada virtual (VPN). En este escenario, la red local está formada por los componentes siguientes:
  • Servidores DNS. Estos servidores representan dos servidores con el servicio DNS instalado que actúan como solucionador o reenviador. Dichos servidores DNS se usan para todos los equipos de la red local como servidores DNS. Se deben crear registros en estos servidores para todos los puntos de conexión de Azure y el entorno local.
  • Puerta de enlace. La puerta de enlace representa un dispositivo VPN o una conexión de ExpressRoute que se usa para conectarse a Azure.
• Suscripción al centro. La suscripción al centro representa una suscripción a Azure que se usa para hospedar recursos de conectividad, administración y redes que se comparten entre varias cargas de trabajo hospedadas en Azure. Estos recursos se pueden dividir en varias suscripciones, tal y como se describe en la arquitectura de escala empresarial.

  Nota

  La red virtual del centro se puede sustituir por un centro de red de área extensa (WAN) virtual, en cuyo caso los servidores DNS tendrían que estar hospedados en otra red virtual de Azure (VNET). En la arquitectura de escala empresarial, esa red virtual se mantiene en su propia suscripción, que se conoce como suscripción de identidad.

  • Subred de Azure Bastion. El servicio Azure Bastion de la red virtual de centro se usa para establecer una comunicación remota con máquinas virtuales (VM) en las redes virtuales de tipo hub-and-spoke desde la red pública de Internet con fines de mantenimiento.
  • Subred del punto de conexión privado. La subred del punto de conexión privado hospeda puntos de conexión privados para las cargas de trabajo hospedadas en Azure de redes virtuales que no están emparejadas con el centro. Con este tipo de red virtual desconectada, sus direcciones IP pueden entrar en conflicto con otras direcciones IP que se usan en Azure y en el entorno local.
  • Subred de puerta de enlace. La subred de puerta de enlace hospeda la puerta de enlace de VPN de Azure o ExpressRoute que se usa para proporcionar conectividad al centro de datos local.
  • Subred de servicios compartidos. La subred de servicios compartidos hospeda servicios que se comparten entre varias cargas de trabajo de Azure. En este caso, esta subred hospeda máquinas virtuales que ejecutan Windows o Linux y que también se usan como servidores DNS. Estos servidores DNS hospedan las mismas zonas DNS que los servidores locales.
• Suscripción conectada. La suscripción conectada representa una colección de cargas de trabajo que requieren una red virtual y conectividad con la red local.
  • Emparejamiento de VNET. Este componente es una conexión de emparejamiento con la red virtual de centro. Esta conexión permite la conectividad entre la red local y el radio a través de la red virtual de centro.
  • Subred predeterminada. La subred predeterminada contiene una carga de trabajo de ejemplo.
    • web-vmss. Este ejemplo de conjunto de escalado de máquinas virtuales hospeda una carga de trabajo en Azure a la que se puede acceder desde el entorno local, Azure y la red pública de Internet.
    • Equilibrador de carga. El equilibrador de carga proporciona acceso a una carga de trabajo que hospeda una serie de máquinas virtuales. La dirección IP de este equilibrador de carga de la subred predeterminada se debe usar para acceder a la carga de trabajo desde Azure y desde el centro de datos local.
  • Subred AppGateway. Es la subred necesaria para el servicio Azure Application Gateway.
    • AppGateway. Application Gateway proporciona acceso a la carga de trabajo de ejemplo de la subred predeterminada a los usuarios de la red pública de Internet.
    • wkld1-pip. Esta dirección es la dirección IP pública que se usa para acceder a la carga de trabajo de ejemplo desde la red pública de Internet.
• Suscripción desconectada. La suscripción desconectada representa una colección de cargas de trabajo que no requieren conectividad con el centro de datos local y que usan el servicio Private Link.
  • PLSSubnet. La subred del servicio Private Link (PLSSubnet) contiene uno o varios recursos del servicio Private Link que proporcionan conectividad con las cargas de trabajo hospedadas en la suscripción conectada.
  • Subred predeterminada. La subred predeterminada contiene una carga de trabajo de ejemplo.
    • web-vmss. Este ejemplo del conjunto de escalado de máquinas virtuales hospeda una carga de trabajo en Azure a la que se puede acceder desde el entorno local, Azure y la red pública de Internet.
    • Equilibrador de carga. El equilibrador de carga proporciona acceso a una carga de trabajo que hospeda una serie de máquinas virtuales. Este equilibrador de carga se conecta al servicio Private Link para proporcionar acceso a los usuarios que proceden de Azure y el centro de recursos local.
  • Subred AppGateway. Esta subred es la necesaria para el servicio Application Gateway.
    • AppGateway. Application Gateway proporciona acceso a la carga de trabajo de ejemplo de la subred predeterminada a los usuarios de la red pública de Internet.
    • wkld2-pip. Esta dirección es la dirección IP pública que se usa para acceder a la carga de trabajo de ejemplo desde la red pública de Internet.
  • Subred de Azure Bastion. El servicio Azure Bastion de la red virtual desconectada se usa para establecer una comunicación remota con máquinas virtuales en las redes virtuales de tipo hub-and-spoke desde la red pública de Internet con fines de mantenimiento.

Componentes

• Virtual Network. Azure Virtual Network (VNet) es el bloque de creación fundamental de una red privada en Azure. VNet permite muchos tipos de recursos de Azure, como Azure Virtual Machines (máquinas virtuales), para comunicarse de forma segura entre usuarios, con Internet y con las redes locales.

• Azure Bastion. Azure Bastion es un servicio totalmente administrado que proporciona acceso más seguro y sin problemas por medio del Protocolo de escritorio remoto (RDP) y el protocolo Secure Shell (SSH) a las máquinas virtuales (VM) sin exponerlas mediante direcciones IP públicas.

• VPN Gateway. VPN Gateway envía el tráfico cifrado entre una red virtual de Azure y una ubicación local a través de Internet público. También puede usar VPN Gateway para enviar tráfico cifrado entre las redes virtuales de Azure a través de la red de Microsoft. Una puerta de enlace de VPN es un tipo de puerta de enlace de red virtual.

• Private Link. Azure Private Link proporciona conectividad privada desde una red virtual a la plataforma como servicio (PaaS) de Azure, propiedad del cliente o servicios de asociados de Microsoft. Simplifica la arquitectura de red y protege la conexión entre los puntos de conexión de Azure mediante la eliminación de la exposición de los datos a la red pública de Internet.

• Application Gateway. Azure Application Gateway es un equilibrador de carga de tráfico web que permite administrar el tráfico a las aplicaciones web. Los equilibradores de carga tradicionales operan en la capa de transporte (OSI capa 4: TCP y UDP) y enrutan el tráfico en función de la dirección IP y puerto de origen a una dirección IP y puerto de destino.

Recomendaciones

Las siguientes recomendaciones sirven para la mayoría de los escenarios. Sígalas a menos que tenga un requisito concreto que las invalide.

Extensión de AD DS a Azure (opcional)

Use zonas DNS integradas en AD DS para hospedar los registros DNS para el centro de recursos local y Azure. En este caso, hay dos conjuntos de servidores DNS de AD DS: uno local y otro en la red virtual de centro.

Recomendamos extender el dominio de AD DS a Azure. También recomendamos configurar las redes virtuales de tipo hub-and-spoke a fin de usar los servidores DNS de AD DS en la red virtual de centro para todas las máquinas virtuales de Azure.

Configuración de DNS de cerebro dividido

Asegúrese de que el DNS de cerebro dividido se haya implementado para permitir que los sistemas de Azure, los usuarios locales y los usuarios de Internet tengan acceso a las cargas de trabajo en función del origen desde el que se conecten.

En el caso de las cargas de trabajo conectadas y desconectadas, recomendamos los siguientes componentes para la resolución de DNS:

• Zonas de Azure DNS para los usuarios de Internet.
• Servidores DNS para usuarios locales y sistemas de Azure.
• Zonas DNS privadas de Azure para la resolución entre redes virtuales de Azure.

Para comprender mejor esta recomendación de cerebro dividido, considere la posibilidad de utilizar la carga de trabajo 1, para la que usaremos el nombre de dominio completo (FQDN) wkld1.contoso.com.

En este caso, los usuarios de Internet deben resolver ese nombre en la dirección IP pública que Application Gateway expone a través de Wkld1-pip. Esta resolución se lleva a cabo mediante la creación de un registro de dirección (registro A) en Azure DNS para la suscripción conectada.

Los usuarios locales deben resolver el mismo nombre en la dirección IP interna del equilibrador de carga de la suscripción conectada. Esta resolución se lleva a cabo mediante la creación de un registro A en los servidores DNS de la suscripción del centro.

Los sistemas de Azure pueden resolver el mismo nombre en una dirección IP interna para el equilibrador de carga de la suscripción conectada mediante la creación de un registro A en el servidor DNS de la suscripción del centro o mediante el uso de zonas DNS privadas. Cuando use zonas DNS privadas, cree manualmente un registro A en la zona DNS privada o habilite el registro automático.

Uso de zonas DNS privadas para una instancia de Private Link

En nuestro caso, la carga de trabajo 2 se hospeda en una suscripción desconectada, y el acceso a esta carga de trabajo para los usuarios locales y los sistemas de Azure conectados es posible a través de un punto de conexión privado en la red virtual de centro. Sin embargo, hay una tercera posibilidad de conexión para esta carga de trabajo: Los sistemas de Azure que se encuentran en la misma red virtual que la carga de trabajo 2.

Para comprender mejor las recomendaciones de DNS para la carga de trabajo 2, usaremos el nombre de dominio completo wkld2.contoso.com y analizaremos las recomendaciones individuales.

En este caso, los usuarios de Internet deben resolver ese nombre en la dirección IP pública que Application Gateway expone a través de Wkld2-pip. Esta resolución se lleva a cabo mediante la creación de un registro A en Azure DNS para la suscripción conectada.

Los usuarios locales y los sistemas de Azure que están conectados a la red virtual de centro y las redes virtuales de radio deben resolver el mismo nombre en la dirección IP interna para el punto de conexión privado de la red virtual de centro. Esta resolución se lleva a cabo mediante la creación de un registro A en los servidores DNS de la suscripción del centro.

Los sistemas de Azure de la misma red virtual que la carga de trabajo 2 deben resolver el nombre en la dirección IP del equilibrador de carga de la suscripción desconectada. Esta resolución se lleva a cabo mediante una zona DNS privada en Azure DNS en esa suscripción.

Los sistemas de Azure de diferentes redes virtuales pueden seguir resolviendo la dirección IP de la carga de trabajo 2 si vincula esas redes virtuales con una zona DNS privada que hospeda el registro A para la carga de trabajo 2.

Habilitación del registro automático

Cuando configura un vínculo de red virtual con una zona DNS privada, puede configurar el registro automático para todas las máquinas virtuales.

Si usa el servidor DNS de AD DS, configure las máquinas virtuales Windows para que puedan usar actualizaciones dinámicas para equipos Windows con el fin de mantener sus registros DNS actualizados en los servidores DNS de AD DS. Recomendamos habilitar las actualizaciones dinámicas y configurar los servidores DNS para que solo se permitan actualizaciones seguras.

Las máquinas virtuales Linux no admiten actualizaciones dinámicas seguras. En el caso de los equipos Linux locales, use el Protocolo de configuración dinámica de host (DHCP) para registrar los registros DNS en los servidores DNS de AD DS.

Para las máquinas virtuales Linux en Azure, utilice un proceso automatizado.

Consideraciones

Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.

Escalabilidad

• Considere la posibilidad de usar al menos dos servidores DNS por región de Azure o en centros de datos locales.
• Observe cómo se lleva a cabo este proceso en el caso anterior, con servidores DNS locales y en la red virtual del centro.

Disponibilidad

• Considere la posibilidad de colocar los servidores DNS. Tal y como se describe en la sección de consideraciones de escalabilidad, los servidores DNS se deben colocar cerca de los usuarios y sistemas que necesitan acceder a ellos.
  • Por región de Azure. Cada región de Azure tiene su propia red virtual de centro o centro de vWAN y es aquí es donde se deben implementar los servidores DNS.
  • Por centro de datos local. También debe tener un par de servidores DNS por centro de datos local para los usuarios y sistemas de esas ubicaciones.
  • En el caso de las cargas de trabajo aisladas (desconectadas), hospede una zona DNS privada y una pública para cada suscripción con el fin de administrar los registros DNS de cerebro dividido.

Facilidad de uso

• Tenga en cuenta la necesidad de registros DNS en relación con los servicios de la plataforma como servicio (PaaS).
• También debe tener en cuenta la resolución DNS para los servicios de PaaS que usan un punto de conexión privado. En este caso, use una zona DNS privada y la canalización DevOps para crear registros en los servidores DNS.

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para más información, consulte Introducción al pilar de seguridad.

• Si necesita usar DNSSEC, tenga en cuenta que Azure DNS actualmente no lo admite.
• Para la validación de DNSSEC, implemente un servidor DNS personalizado y habilite la validación de DNSEC.
• Azure DDoS Protection, combinado con los procedimientos recomendados de diseño de aplicaciones, proporciona características mejoradas de mitigación de DDoS para ofrecer una mejor defensa frente a los ataques DDoS. Debe habilitar Azure DDOS Protection en cualquier red virtual perimetral.

DevOps

• Automatice la configuración de esta arquitectura. Para ello, combine las plantillas de Azure Resource Manager a fin de configurar todos los recursos. Las zonas DNS privadas y públicas admiten la administración completa de la CLI de Azure, PowerShell, .NET y la API REST.
• Si usa una canalización de integración continua y desarrollo continuo (CI/CD) para implementar y mantener cargas de trabajo en Azure y en el entorno local, también puede configurar el registro automáticamente de registros DNS.

Optimización de costos

La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.

• Los costos de la zona de Azure DNS se basan en el número de zonas DNS hospedadas en Azure y el número de consultas de DNS recibidas.
• Puede usar la calculadora de precios de Azure para calcular los costos. Los modelos de precios de Azure DNS se explican aquí.
• El modelo de facturación de Azure ExpressRoute se basa en datos limitados, que cobra por gigabyte de transferencia de datos de salida, o en datos ilimitados, que cobra una cuota mensual que incluye toda la transferencia de datos.
• Si utiliza VPN, en lugar de ExpressRoute, el costo depende de la SKU de la puerta de enlace de red virtual y se cobra por hora.

Pasos siguientes

Más información sobre las tecnologías de los componentes:

• ¿Qué es Azure DNS?
• ¿Qué es Azure Virtual Network?
• ¿Qué es Azure ExpressRoute?
• ¿Qué es Azure Bastion?

Recursos relacionados

Explore las arquitecturas relacionadas:

• Recurso compartido de archivos de la nube empresarial de Azure
• Aplicación de n niveles con Apache Cassandra
• SaaS multiinquilino en Azure
• Extensión de una red local mediante ExpressRoute