Criar uma solução híbrida do Sistema de Nomes de Domínio com o Azure

Esta arquitetura de referência mostra como projetar uma Solução híbrida do DNS (Sistema de Nomes de Domínio) para resolver nomes de cargas de trabalho hospedadas localmente e no Microsoft Azure Essa arquitetura funciona para usuários e outros sistemas que estão se conectando do local e da Internet pública.

Arquitetura

Baixe um Arquivo Visio dessa arquitetura.

Workflow

Essa arquitetura consiste nos seguintes componentes:

• Rede local. A rede local representa um único datacenter conectado ao Azure por meio de uma conexão do Azure ExpressRoute ou de uma VPN (rede virtual privada). Nesse cenário, os seguintes componentes compõem a rede local:
  • Servidores DNS. Esses servidores representam dois servidores com serviço DNS instalado atuando como resolvedor/encaminhador. Esses servidores DNS são usados para todos os computadores na rede local como servidores DNS. Os registros devem ser criados nesses servidores para todos os pontos de extremidade no Azure e no local.
  • Gateway. O gateway representa um dispositivo VPN ou uma conexão do ExpressRoute usada para se conectar ao Azure.
• Assinatura do hub. A assinatura do hub representa uma assinatura do Azure usada para hospedar recursos de conectividade, gerenciamento e rede compartilhados entre várias cargas de trabalho hospedadas no Azure. Esses recursos podem ser divididos em várias assinaturas, conforme descrito na arquitetura de escala empresarial.

  Observação

  A rede virtual do hub pode ser substituída por um hub de WAN (rede de longa distância) virtual, caso em que os servidores DNS teriam que ser hospedados em outra VNet (rede virtual) do Azure. Na arquitetura de escala empresarial, essa VNet é mantida em sua própria assinatura, intitulada assinatura de identidade.

  • Sub-rede do Azure Bastion. O serviço Azure Bastion na rede virtual do hub é usado para comunicação remota para VMs (máquinas virtuais) no hub e VNets spoke da Internet pública para fins de manutenção.
  • Sub-rede do ponto de extremidade privado. A sub-rede do ponto de extremidade privado hospeda pontos de extremidade privados para cargas de trabalho hospedadas no Azure em VNets que não estão emparelhadas com o hub. Com esse tipo de VNet desconectada, seus endereços IP podem entrar em conflito com outros endereços IP usados no Azure e no local.
  • Gateway de sub-rede. A sub-rede do gateway hospeda o gateway VPN do Azure, ou ExpressRoute, usado para fornecer conectividade de volta ao datacenter local.
  • Sub-rede serviços compartilhados. A sub-rede de serviços compartilhados hospeda serviços que são compartilhados entre várias cargas de trabalho do Azure. Nesse cenário, essa sub-rede hospeda máquinas virtuais que rodam Windows ou Linux e que também são usadas como servidores DNS. Esses servidores DNS hospedam as mesmas zonas DNS que os servidores locais.
• Assinatura conectada. A assinatura conectada representa uma coleção de cargas de trabalho que exigem uma rede virtual e conectividade de volta à rede local.
  • Emparelhamento VNet. Esse componente é uma conexão de emparelhamento de volta para a VNet do hub. Essa conexão permite a conectividade da rede local para o spoke e de volta por meio da VNet do hub.
  • Sub-rede padrão. A sub-rede padrão contém uma carga de trabalho de exemplo.
    • web-vmss. Este conjunto de dimensionamento de máquinas virtuais de exemplo hospeda uma carga de trabalho no Azure que pode ser acessada localmente, do Azure e da Internet pública.
    • Balanceador de carga. O load balancer fornece acesso a uma carga de trabalho hospedada por uma série de VMs. O endereço IP desse load balancer na sub-rede padrão deve ser usado para acessar a carga de trabalho do Azure e do datacenter local.
  • Sub-rede do AppGateway. Essa sub-rede é a sub-rede necessária para o serviço Gateway de Aplicativo do Azure.
    • AppGateway. O Gateway de Aplicativo fornece acesso à carga de trabalho de exemplo na sub-rede padrão para usuários da Internet pública.
    • wkld1-pip. Esse endereço é o endereço IP público usado para acessar a carga de trabalho de exemplo da Internet pública.
• Assinatura desconectada. A assinatura desconectada representa uma coleção de cargas de trabalho que não exigem conectividade de volta ao datacenter local e que usam o serviço de link privado.
  • PLSSubnet. A sub-rede do serviço de link privado (PLSSubnet) contém um ou mais recursos de serviço de link privado que fornecem conectividade a cargas de trabalho hospedadas na assinatura conectada.
  • Sub-rede padrão. A sub-rede padrão contém uma carga de trabalho de exemplo.
    • web-vmss. Este conjunto de dimensionamento de máquinas virtuais de exemplo hospeda uma carga de trabalho no Azure que pode ser acessada localmente, do Azure e da Internet pública.
    • Balanceador de carga. O load balancer fornece acesso a uma carga de trabalho hospedada por uma série de VMs. Esse load balancer está conectado ao serviço de link privado para fornecer acesso aos usuários provenientes do Azure e do datacenter local.
  • Sub-rede do AppGateway. Essa sub-rede é a sub-rede necessária para o serviço Gateway de Aplicativo.
    • AppGateway. O Gateway de Aplicativo fornece acesso à carga de trabalho de exemplo na sub-rede padrão para usuários da Internet pública.
    • wkld2-pip. Esse endereço é o endereço IP público usado para acessar a carga de trabalho de exemplo da Internet pública.
  • Sub-rede do Azure Bastion. O serviço Azure Bastion na rede virtual desconectada é usado para comunicação remota para VMs (máquinas virtuais) no hub e VNets spoke da Internet pública para fins de manutenção.

Componentes

• Rede Virtual. A Rede Virtual do Azure (VNet) é o bloco de construção fundamental de sua rede privada no Azure. Ela permite vários tipos de recursos do Azure, como VMs (Máquinas Virtuais) do Azure, a fim de se comunicar de forma segura com a Internet, com as redes locais e com outras VMs.

• Azure Bastion. O Azure Bastion é um serviço totalmente gerenciado que fornece acesso contínuo e mais seguro usando o protocolo RDP ou SSH às VMs (máquinas virtuais) sem nenhuma exposição por meio de endereços IP públicos.

• Gateway de VPN. O Gateway de VPN envia tráfego criptografado entre uma rede virtual do Azure e uma localização local pela internet pública. Também é possível usar um Gateway de VPN para enviar tráfego criptografado entre as redes virtuais do Azure pela rede da Microsoft. Um gateway de VPN é um tipo específico de gateway de rede virtual.

• Link Privado. O Link Privado do Azure fornece conectividade privada de uma rede virtual para PaaS (plataforma como serviço), de propriedade do cliente ou de serviços de parceiros da Microsoft. Ele simplifica a arquitetura de rede e protege a conexão entre os pontos de extremidade no Azure ao eliminar a exposição de dados para a Internet pública.

• Gateway de Aplicativo. O Gateway de Aplicativo do Azure é um balanceador de carga do tráfego da Web que permite que você gerencie o tráfego para seus aplicativos Web. Os balanceadores de carga tradicionais operam na camada de transporte (camada OSI 4 – TCP e UDP) e encaminham o tráfego com base no endereço IP de origem e na porta para um endereço IP de destino e uma porta.

Recomendações

As seguintes recomendações aplicam-se à maioria dos cenários. Siga estas recomendações, a menos que você tenha um requisito específico que as substitua.

Estender o AD DS para o Azure (opcional)

Use zonas DNS integradas no AD DS para hospedar registros DNS para seu datacenter local e Azure. Nesse cenário, há dois conjuntos de servidores DNS do AD DS: um local e outro na VNet do hub.

Recomendamos estender seu domínio do AD DS para o Azure. Também recomendamos configurar as VNets hub e spoke para usar os servidores DNS do AD DS na VNet do hub para todas as VMs no Azure.

Configurar DNS de cérebro dividido

Verifique se o DNS de cérebro dividido está em vigor para permitir que os sistemas do Azure, os usuários locais e os usuários da Internet acessem cargas de trabalho com base em onde estejam se conectando.

Para cargas de trabalho conectadas e desconectadas, recomendamos os seguintes componentes para resolução de DNS:

• Zonas DNS do Azure para usuários da Internet.
• Servidores DNS para usuários locais e sistemas do Azure.
• Zonas DNS privadas do Azure para resolução entre VNets do Azure.

Para entender melhor essa recomendação de cérebro dividido, considere a aCarga de Trabalho 1, para a qual usaremos o wkld1.contoso.com como FQDN (nome de domínio totalmente qualificado).

Nesse cenário, os usuários da Internet devem resolver esse nome para o endereço IP público que o Gateway de Aplicativo expõe por meio do Wkld1-pip. Essa resolução é feita criando um registro de endereço (registro A) no DNS do Azure para a assinatura conectada.

Os usuários locais devem resolver o mesmo nome para o endereço IP interno do load balancer na assinatura conectada. Essa resolução é feita criando um registro A nos servidores DNS na assinatura do hub.

Os sistemas do Azure podem resolver o mesmo nome para um endereço IP interno para o load balancer na assinatura conectada criando um registro A no servidor DNS na assinatura do hub ou usando zonas DNS privadas. Ao usar zonas DNS privadas, crie manualmente um registro A na zona DNS privada ou ative o registro automático.

Usar zonas DNS privadas para um link privado

Em nosso cenário, a Carga de Trabalho 2 é hospedada em uma assinatura desconectada, e o acesso a essa carga de trabalho para usuários locais e sistemas conectados do Azure é possível por meio de um ponto de extremidade privado na VNet do hub. No entanto, há uma terceira possibilidade de conexão para essa carga de trabalho: sistemas do Azure na mesma VNet que a Carga de Trabalho 2.

Para entender melhor as recomendações de DNS para a Carga de Trabalho 2, usaremos o wkld2.contoso.com como FQDN e discutiremos as recomendações individuais.

Nesse cenário, os usuários da Internet devem resolver esse nome para o endereço IP público que o Gateway de Aplicativo expõe por meio do Wkld2-pip. Essa resolução é feita criando um registro A no DNS do Azure para a assinatura conectada.

Os usuários locais e os sistemas do Azure conectados à VNet hub e às VNets spoke devem resolver o mesmo nome para o endereço IP interno do ponto de extremidade privado na VNet Hub. Essa resolução é feita criando um registro A nos servidores DNS na assinatura do hub.

Os sistemas do Azure na mesma VNet que a Carga de Trabalho 2 devem resolver o nome para o endereço IP do load balancer na assinatura desconectada. Essa resolução é feita usando uma zona DNS privada no DNS do Azure nessa assinatura.

Os sistemas do Azure em VNets diferentes ainda podem resolver o endereço IP da Carga de Trabalho 2 se você vincular essas VNets à zona DNS privada que está hospedando o registro A para a Carga de Trabalho 2.

Habilitar o registro automático

Ao configurar um link de VNet com uma zona DNS privada, você pode, opcionalmente, configurar o registro automático para todas as máquinas virtuais.

Se você estiver usando o servidor DNS do AD DS, configure as VMs do Windows para usar atualizações dinâmicas para computadores Windows e manter seus próprios registros DNS atualizados nos servidores DNS do AD DS. Recomendamos habilitar as atualizações dinâmicas e configurar os servidores DNS para permitir apenas atualizações seguras.

As VMs com Linux não dão suporte a atualizações dinâmicas seguras. Para computadores Linux locais, use o DHCP (Dynamic Host Configuration Protocol) para registrar registros DNS nos servidores DNS do AD DS.

Para VMs do Linux no Azure, use um processo automatizado.

Considerações

Estas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios de orientação que podem ser usados para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

Escalabilidade

• Por região do Azure ou datacenters locais, considere usar pelo menos dois servidores DNS cada.
• Observe como isso é feito no cenário anterior, com servidores DNS locais e na rede virtual do hub.

Disponibilidade

• Considere o posicionamento de servidores DNS. Conforme descrito na seção de considerações de escalabilidade, os servidores DNS devem ser colocados próximos aos usuários e sistemas que precisam acessá-los.
  • Por região do Azure. Cada região do Azure tem seu próprio hub VNet ou vWAN. É aqui que seus servidores DNS devem ser implantados.
  • Para datacenters locais. Você também deve ter um par de servidores DNS por datacenter local para usuários e sistemas nesses locais.
  • Para cargas de trabalho isoladas (desconectadas), hospede uma zona DNS privada e uma zona DNS pública para cada assinatura para gerenciar registros DNS de cérebro dividido.

Capacidade de gerenciamento

• Considere a necessidade de registros DNS para serviços de PaaS (plataforma como serviço).
• Você também deve considerar a resolução de DNS para serviços de PaaS que usam um ponto de extremidade privado. Use uma zona DNS privada para isso e use seu pipeline de DevOps para criar registros nos servidores DNS.

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para saber mais, confira Visão geral do pilar de segurança.

• Se você precisar usar o DNSSEC, considere que o DNS do Azure atualmente não dá suporte a ele.
• Para validação de DNSSEC, implante um servidor DNS personalizado e habilite a validação de DNSEC.
• A Proteção contra DDoS do Azure, combinada com as práticas recomendadas de design de aplicativos, fornece recursos aprimorados de mitigação de DDoS para fornecer mais defesa contra ataques de DDoS. Você deve habilitar a Proteção contra DDOS do Azure em qualquer rede virtual do perímetro.

DevOps

• Automatize a configuração dessa arquitetura combinando modelos do Azure Resource Manager para configuração de todos os recursos As zonas DNS privadas e públicas dão suporte ao gerenciamento completo da CLI do Azure, PowerShell, .NET e API REST.
• Se você estiver usando um pipeline de CI/CD (integração contínua e desenvolvimento contínuo) para implantar e manter cargas de trabalho no Azure e no local, também poderá configurar o registro automático de registros DNS.

Otimização de custo

A otimização de custos é a análise de maneiras de reduzir as despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, confira Visão geral do pilar de otimização de custo.

• Os custos da zona DNS do Azure são baseados no número de zonas DNS hospedadas no Azure e no número de consultas DNS recebidas.
• Use a Calculadora de Preços do Azure para estimar os custos. Os modelos de preços do DNS do Azure são explicados aqui.
• O modelo de cobrança do Azure ExpressRoute é baseado em dados limitados, que cobram por gigabyte pela transferência de dados de saída, ou dados ilimitados, que cobram uma taxa mensal, incluindo toda a transferência de dados.
• Se você estiver usando VPN, em vez do ExpressRoute, o custo dependerá do SKU do gateway de rede virtual e será cobrado por hora.

Próximas etapas

Saiba mais sobre as tecnologias dos componentes:

• O que é o DNS do Azure?
• O que é a Rede Virtual do Azure?
• O que é o Azure ExpressRoute?
• O que é o Azure Bastion?

Recursos relacionados

Explorar arquiteturas relacionadas:

• Compartilhamento de arquivo em nuvem do Azure Enterprise
• Aplicativo de N camadas com Apache Cassandra
• SaaS multilocatário no Azure
• Estender uma rede local usando o ExpressRoute