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

Esta arquitetura de referência ilustra como criar uma solução híbrida de DNS (Sistema de Nomes de Domínio) para resolver nomes para cargas de trabalho hospedadas no local e no Microsoft Azure. Essa arquitetura funciona para usuários e outros sistemas que estão se conectando a partir da Internet local e 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 VPN (Rota Expressa do Azure) ou 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 que estão 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 de Rota Expressa usada para se conectar ao Azure.
• Assinatura de hub. A assinatura de hub representa uma assinatura do Azure usada para hospedar recursos de conectividade, gerenciamento e rede que são 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 de hub pode ser substituída por um hub de rede de longa distância (WAN) virtual, caso em que os servidores DNS teriam que ser hospedados em uma rede virtual (VNet) diferente do Azure. Na arquitetura de escala empresarial, essa rede virtual é mantida em sua própria assinatura intitulada Identidade.

  • Sub-rede do Bastião do Azure. O serviço Bastião do Azure na rede virtual de hub é usado para comunicação remota para máquinas virtuais (VMs) no hub e VNets spoke da Internet pública para fins de manutenção.
  • Sub-rede de ponto de extremidade privado. A sub-rede de ponto de extremidade privado hospeda pontos de extremidade privados para cargas de trabalho hospedadas no Azure em redes virtuais que não são emparelhadas ao hub. Com esse tipo de rede virtual 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 de gateway hospeda a VPN do Azure, ou Rota Expressa, gateway que é 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 executam o Windows ou Linux 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 um conjunto 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 à rede virtual do hub. Essa conexão permite a conectividade da rede local para o spoke e vice-versa através 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áquina virtual 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 balanceador de carga fornece acesso a uma carga de trabalho que uma série de VMs hospeda. O endereço IP desse balanceador de carga na sub-rede padrão deve ser usado para acessar a carga de trabalho do Azure e do datacenter local.
  • Sub-rede AppGateway. Essa sub-rede é a sub-rede necessária para o serviço Gateway de Aplicativo do Azure.
    • AppGateway. O Application Gateway fornece acesso à carga de trabalho de exemplo na sub-rede padrão aos 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 um conjunto de cargas de trabalho que não exigem conectividade com o 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 Conectado.
  • 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áquina virtual 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 balanceador de carga fornece acesso a uma carga de trabalho que uma série de VMs hospeda. Esse balanceador de carga está conectado ao serviço de link privado para fornecer acesso aos usuários que vêm do Azure e do datacenter local.
  • Sub-rede AppGateway. Essa sub-rede é a sub-rede necessária para o serviço Gateway de Aplicativo.
    • AppGateway. O Application Gateway fornece acesso à carga de trabalho de exemplo na sub-rede padrão aos 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 Bastião do Azure. O serviço Bastião do Azure na rede virtual desconectada é usado para comunicação remota com VMs 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.

• Bastião do Azure. 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 o Azure. Nesse cenário, há dois conjuntos de servidores DNS do AD DS: um local e outro na rede virtual do hub.

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

Configurar DNS split-brain

Verifique se o DNS split-brain 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 no local de onde estão se conectando.

Para cargas de trabalho conectadas e desconectadas, recomendamos os seguintes componentes para resolução 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 carga de trabalho 1, para a qual usaremos o wkld1.contoso.com nome de domínio totalmente qualificado (FQDN).

Nesse cenário, os usuários da Internet devem resolver esse nome para o endereço IP público que o Application Gateway expõe por meio de 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 balanceador de carga 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 balanceador de carga na assinatura conectada criando um registro A no servidor DNS na assinatura de hub ou usando zonas DNS privadas. Quando estiver usando zonas DNS privadas, crie manualmente um registro A na zona DNS privada ou habilite 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 rede virtual de hub. No entanto, há uma terceira possibilidade de conexão para essa carga de trabalho: sistemas do Azure na mesma rede virtual que a carga de trabalho 2.

Para entender melhor as recomendações de DNS para a Carga de Trabalho 2, usaremos o FQDN wkld2.contoso.com 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 Application Gateway expõe por meio de 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 de hub e às VNets spoke devem resolver o mesmo nome para o endereço IP interno do ponto de extremidade privado na VNet de Hub. Essa resolução é feita criando um registro A nos servidores DNS na assinatura do hub.

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

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

Habilitar o registro automático

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

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

As VMs Linux não oferecem 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 Linux no Azure, use um processo automatizado.

Considerações

Essas 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, confira 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 de hub.

Disponibilidade

• Considere o posicionamento de servidores DNS. Conforme descrito na seção Considerações sobre 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 hub vWAN. É aqui que os servidores DNS devem ser implantados.
  • Por datacenter local. 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 split-brain.

Capacidade de gerenciamento

• Considere a necessidade de registros DNS para serviços de plataforma como serviço (PaaS).
• Você também deve considerar a resolução 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 do uso do DNSSEC, considere que o DNS do Azure atualmente não oferece suporte a ele.
• Para validação DNSSEC, implante um servidor DNS personalizado e habilite a validação 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 Gerenciador de Recursos do Azure para configuração de todos os recursos. As zonas DNS privadas e públicas oferecem suporte ao gerenciamento completo da CLI do Azure, PowerShell, .NET e API REST.
• Se você estiver usando um pipeline de integração contínua e desenvolvimento contínuo (CI/CD) 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 de 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 para o DNS do Azure são explicados aqui.
• O modelo de cobrança do Azure ExpressRoute é baseado em dados monitorados, que cobram por gigabyte pela transferência de dados de saída, ou em dados ilimitados, que cobram uma taxa mensal, incluindo toda a transferência de dados.
• Se você estiver usando VPN, em vez de Rota Expressa, o custo dependerá da 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 a Rota Expressa