O blog da AWS

Simplifique o gerenciamento de DNS em um ambiente de várias contas com o Amazon Route 53 Resolver

Por Mahmoud Matouk, Arquiteto de Soluções para Setor Público 

 

27 de setembro de 2021: na seção “Terceiro caso de uso”, atualizamos a etapa 3 afim de facilitar a compreensão.

15 de abril de 2021: na seção “Terceiro caso de uso”, atualizamos o diagrama e as etapas afim de facilitar a compreensão.

2 de abril de 2021: na seção “Etapa 1: configurar uma conta DNS centralizada”, atualizamos a etapa 4.

5 de junho de 2019: atualizamos todos os números da publicação afim de facilitar a compreensão e adicionamos dois parágrafos na seção “Considerações e limitações adicionais”.

Em uma publicação anterior, foi mostrada uma solução para implementar o DNS centralizado em um ambiente de várias contas, que simplificou o gerenciamento de DNS ao reduzir o número de servidores e forwarders necessários ao implementar a resolução de nomes de domínio entre contas AWS (cross-account) e on-premises. Com a disponibilidade do serviço Amazon Route 53 Resolver, agora você tem acesso a um forwarder condicional nativo que simplificará ainda mais a resolução de DNS híbrido.

Neste post, mostraremos uma solução modernizada para centralizar o gerenciamento de DNS em um ambiente de várias contas AWS, usando o Amazon Route 53 Resolver. Essa solução permite que você resolva domínios entre várias contas e cargas de trabalho executados na AWS e no ambiente on-premises, sem a necessidade de executar um controlador de domínio na AWS.

Visão geral da solução

Esta solução mostrará como resolver três casos de uso principais para resolução de domínio:

  • Resolver nomes de domínios on-premises com cargas de trabalho em execução em suas VPCs.
  • Resolver nomes de domínios privados em seu ambiente da AWS com suas cargas de trabalho executadas on-premises.
  • Resolver nomes de domínios privados entre cargas de trabalho executadas em diferentes contas da AWS.

O diagrama a seguir explica a arquitetura completa de alto nível.

Figure 1: Solution architecture diagramFigura 1: diagrama da arquitetura da solução

Nesta arquitetura temos:

  1. Esse é o servidor DNS padrão fornecido pela Amazon para uma VPC de DNS centralizado, que chamaremos de DNS-VPC. Este é o segundo endereço IP no intervalo CIDR da VPC (conforme ilustrado, é 172.27.0.2). Esse servidor DNS padrão será o principal resolvedor de nomes de domínio para todas as cargas de trabalho em execução nas contas participantes da AWS.
  2. Este mostra os endpoints do Route 53 Resolver. O endpoint de entrada receberá consultas encaminhadas de servidores DNS on-premises e de cargas de trabalho em execução nas contas participantes da AWS. O endpoint de saída será usado para encaminhar consultas de nomes de domínio da AWS para o DNS on-premises.
  3. Este mostra as regras de encaminhamento condicionais. Para essa arquitetura, precisaremos de duas regras; uma para encaminhar consultas de nomes de domínio da zona onprem.private para o servidor DNS on-premises por meio do endpoint de saída e uma segunda regra para encaminhar consultas de nomes de domínio do awscloud.private para o endpoint de entrada do resolvedor no DNS-VPC.
  4. Este indica que essas duas regras de encaminhamento são compartilhadas com todas as outras contas da AWS por meio do AWS Resource Access Manager e estão associadas a todas as VPCs nestas contas.
  5. Este mostra a Private Hosted Zone, criada em cada conta com um subdomínio exclusivo de awscloud.private.
  6. Este mostra o servidor DNS on-premises com forwarders condicionais configurados para encaminhar consultas para a zona awscloud.private para os endereços IP do endpoint de entrada do Resolver.

Observação: essa solução não requer VPC Peering ou conectividade entre as VPCs de origem/destino e a DNS-VPC.

Como funciona

Agora, vamos mostrar como o fluxo de resolução de nomes de domínio dessa arquitetura funciona, de acordo com os três casos de uso nos quais estamos focando.

Primeiro caso de uso

Figure 2: Use case for resolving on-premises domains from workloads running in AWSFigura 2: caso de uso para resolver nomes de domínios on-premises com cargas de trabalho em execução na AWS

  1. A consulta ao DNS será roteada para o servidor DNS padrão da VPC que hospeda host1.acc1.awscloud.private.
  2. Como a VPC está associada às regras de encaminhamento compartilhadas da conta DNS central, essas regras serão avaliadas pelo Amazon-DNS padrão fornecido na VPC.
  3. Neste exemplo, uma das regras indica que as consultas para onprem.private devem ser encaminhadas para um servidor DNS on-premises. Seguindo essa regra, a consulta será encaminhada para um servidor DNS on-premises.
  4. A regra de encaminhamento está associada ao endpoint de Outbound do Resolver, portanto, a consulta será encaminhada por meio desse endpoint para um servidor DNS on-premises.

Nesse fluxo, a consulta ao DNS que foi iniciada em uma das contas participantes foi encaminhada para o servidor DNS centralizado que, por sua vez, encaminhou isso para o DNS on-premises.

Segundo caso de uso

A seguir, veja como as cargas de trabalho on-premises poderão resolver nomes de domínios privados em seu ambiente da AWS:

Figure 3: Use case for how on-premises workloads will be able to resolve private domains in your AWS environmentFigura 3: caso de uso de como as cargas de trabalho on-premises poderão resolver nomes de domínios privados em seu ambiente da AWS

Nesse caso, a consulta para host1.acc1.awscloud.private é iniciada de um host on-premises. Veja o que acontece a seguir:

  1. A consulta de nomes de domínio é encaminhada para o servidor DNS on-premises.
  2. A consulta é então encaminhada para o endpoint de entrada do Resolver, por meio de uma regra de condicional forwarder no servidor DNS on-premises.
  3. A consulta alcança o servidor DNS padrão para DNS-VPC.
  4. Como a DNS-VPC está associada à Private Hosted Zone acc1.awscloud.private, o servidor DNS padrão poderá resolver esse nome de domínio.

Nesse caso, a consulta ao DNS foi iniciada no on-premises e encaminhada para o DNS centralizado do lado da AWS por meio do Inbound endpoint.

Terceiro caso de uso

Por fim, talvez seja necessário resolver nomes de domínios em várias contas da AWS. Veja como isso é possível:

Figure 4: Use case for how to resolve domains across multiple AWS accountsFigura 4: caso de uso de como resolver nomes de domínios em várias contas da AWS

  1. A consulta de nome de domínio é enviada ao servidor DNS padrão da máquina de origem de onde está a VPC (host1).
  2. Como a VPC está associada às regras de encaminhamento compartilhadas, essas regras serão avaliadas.
  3. Uma regra indica que as consultas para a zona awscloud.private devem ser encaminhadas para os Inbound endpoints (por meio do Outbound endpoint) na DNS-VPC.
  4. Em seguida, o Outbound endpoint encaminha a consulta ao DNS para os IPs de destino. Neste exemplo, os IPs de destino são os endereços IP do Inbound endpoint.
  5. Como a DNS-VPC está associada à Hosted Zone acc2.awscloud.private, o DNS padrão usará regras definidas automaticamente para resolver esse domínio.

Esse caso de uso explica o cenário de resolução de nomes DNS entre contas AWS-AWS, em que a consulta ao DNS foi iniciada em uma conta participante e encaminhada para o DNS central para resolução de nomes de domínios em outra conta da AWS. Agora, vamos ver o que é necessário para criar essa solução em seu ambiente.

Como implantar a solução

Mostraremos como configurar essa solução em quatro etapas:

  1. Configurar uma conta DNS centralizada.
  2. Configurar cada conta AWS participante.
  3. Criar Privated Hosted Zones e associações do Route 53.
  4. Configurar forwarders de DNS on-premises.

Etapa 1: configurar uma conta DNS centralizada

Nesta etapa, você configurará recursos na conta DNS centralizada. Inicialmente, isso inclui a DNS-VPC, os endpoints do Resolver e as regras de encaminhamento.

  1. Crie uma VPC para atuar como VPC de DNS, de acordo com seu cenário de negócios, usando a console da web ou um Quick Start da AWS. Você pode analisar cenários comuns no guia do usuário do Amazon VPC; um cenário muito comum é uma VPC com sub-redes públicas e privadas.
  2. Crie endpoints do Route 53 Resolver. Você precisa criar um Outbound endpoint para encaminhar consultas DNS para o DNS on-premises, e um Inbound endpoint para receber consultas de DNS encaminhadas de cargas de trabalho on-premises e outras contas da AWS.
  3. Crie duas regras de encaminhamento. A primeira regra será para encaminhar consultas DNS para a zona onprem.private dos endereços IP do servidor DNS on-premises; e a segunda regra é para encaminhar consultas ao DNS da zona awscloud.private para os endereços IP do Inbound endpoint do Resolvedor.
  4. Depois de criar as regras, associe a regra da zona onprem.private à DNS-VPC criada na etapa 1 (não é necessário associar a outra regra de encaminhamento à DNS-VPC). Isso permitirá que o Route 53 Resolver comece a encaminhar consultas de domínio adequadamente.
  5. Por fim, você precisa compartilhar as duas regras de encaminhamento com todas as contas participantes. Para fazer isso, você usará o AWS Resource Access Manager e poderá compartilhar as regras com o AWS Organization ou com contas específicas.

Observação: para poder encaminhar consultas de domínio para seu servidor DNS on-premises, você precisa de conectividade entre seu datacenter e a DNS-VPC, que pode ser estabelecida usando VPN Site-To-Site ou AWS Direct Connect.

Etapa 2: configurar contas participantes

Para cada conta participante, você precisa configurar suas VPCs para usar as regras de encaminhamento compartilhadas, e criar uma Private Hosted Zone para cada conta.

  • Manager. Essa etapa não é necessária se as regras foram compartilhadas com seu AWS Organization. Depois, associe as regras de encaminhamento às VPCs que hospedam suas cargas de trabalho em cada conta. Uma vez associadas, o Resolver começará a encaminhar consultas DNS de acordo com as regras.

Nesse momento, você deve conseguir resolver nomes de domínios on-premises das cargas de trabalho em execução em qualquer VPC associada às regras de encaminhamento compartilhadas. Para criar domínios privados na AWS, você precisa criar Private Hosted Zones.

Etapa 3: criar Privated Hosted Zones

Nesta etapa, você precisa criar uma Private Hosted Zone em cada conta com um subdomínio de awscloud.private. Use nomes exclusivos para cada Privated Hosted Zone, afim de evitar conflitos de domínio em seu ambiente (por exemplo, acc1.awscloud.private ou dev.awscloud.private).

  1. Crie uma Hosted Zone em cada conta participante com um subdomínio de awscloud.private e o associe às VPCs em execução nessa conta.
  2. Associe a Private Hosted Zone à DNS-VPC. Isso permite que a DNS-VPC centralizada resolva domínios da Private Hosted Zone e atue como resolvedor de DNS entre contas da AWS.

Como a Private Hosted Zone e a DNS-VPC estão em contas diferentes, você precisa associar Private Hosted Zone à DNS-VPC. Para fazer isso, você precisa criar uma autorização da conta que possui a Private Hosted Zone e aceitar essa autorização na conta proprietária da DNS-VPC. Você pode fazer isso usando a AWS CLI:

  1. Em cada conta participante, crie a autorização usando o ID da Private Hosted Zone, a região e o ID da VPC que você deseja associar (DNS-VPC).

        aws route53 create-vpc-association-authorization --hosted-zone-id <hosted-zone-id>  --vpc VPCRegion=<region> ,VPCId=<vpc-id>
  2. Na conta DNS centralizada, associe a DNS-VPC à hosted zone em cada conta participante.

        aws route53 associate-vpc-with-hosted-zone --hosted-zone-id <hosted-zone-id> --vpc VPCRegion=<region>,VPCId=<vpc-id>

Etapa 4: configurar encaminhadores de DNS on-premises

Para poder resolver subdomínios dentro do domínio awscloud.private em cargas de trabalho executadas on-premises, você precisa configurar regras condicionais de forwarding, para encaminhar consultas de domínio para os dois endereços IP dos Inbound endpoints do resolvedor que foram criados na conta DNS centralizada. Observe que isso requer conectividade entre seu datacenter e a DNS-VPC, que pode ser estabelecida usando VPN site a site ou AWS Direct Connect.

Considerações e limitações adicionais

Graças à flexibilidade do Amazon Route 53 Resolver e às regras de encaminhamento condicional, você pode controlar quais consultas enviar ao DNS central e quais resolver localmente na mesma conta. Isso é particularmente importante quando você planeja usar alguns serviços da AWS, como o AWS PrivateLink ou o Amazon Elastic File System (EFS), pois os nomes de domínio associados a esses serviços precisam ser resolvidos localmente para a conta que os possui.

Recomendamos que você resolva domínios locais para a conta quando possível; por exemplo, para domínios privados nas Privated Hosted Zones na mesma conta. Para fazer isso, você pode criar regras condicionais de encaminhamento para a conta, usar “system” para o tipo de regra e associar essas regras às suas VPCs.

Observação sobre os limites do Route 53 Resolver: o Route 53 Resolver tem um limite de 10.000 consultas por segundo por endereço IP em um endpoint. Se você tiver uma carga de trabalho que exija limites mais altos, considere encaminhar essas consultas para um servidor DNS local configurado adequadamente em execução em uma instância do EC2. Leia mais sobre os limites de serviço aqui.

Nesta seção, citarei dois casos de uso que exigem considerações adicionais.

    1. Interface VPC Endpoints (AWS PrivateLink)

    Quando você cria um endpoint de interface do AWS PrivateLink, a AWS gera nomes de host DNS específicos do endpoint que você pode usar para se comunicar com o serviço. Para serviços da AWS e serviços de parceiros do AWS Marketplace, você tem a opção de habilitar o DNS privado para o endpoint. Essa opção associa uma Private Hosted Zone à sua VPC. A zona hospedada contém um conjunto de registros para o nome DNS padrão do serviço (por exemplo, ec2.us-east-1.amazonaws.com) que resolve para os endereços IP privados das interfaces de rede de endpoint em sua VPC. Isso permite que você faça solicitações ao serviço usando seu nome de host DNS padrão em vez dos nomes de host DNS específicos do endpoint.

    Se você usar o DNS privado para seu endpoint, precisará resolver consultas ao DNS para o endpoint local da conta e usar o DNS padrão fornecido pela AWS. Portanto, nesse caso, recomendo que você resolva as consultas de domínio no amazonaws.com localmente e que não encaminhe essas consultas para o DNS central.

    2. Configuração do EFS com um nome DNS

  2. Você pode configurar um sistema de arquivos do Amazon EFS em uma instância do Amazon EC2 usando nomes DNS. O nome DNS do sistema de arquivos é resolvido automaticamente para o endereço IP do destino da configuração na zona de disponibilidade da instância do Amazon EC2 conectada. Para poder fazer isso, a VPC deve usar o DNS padrão fornecido pela Amazon para resolver nomes de DNS do EFS.Se você planeja usar o EFS em seu ambiente, recomendo resolver os nomes DNS do EFS localmente e evite enviar essas consultas ao DNS central, pois os clientes, nesse caso, não receberiam respostas otimizadas para sua zona de disponibilidade, o que poderia resultar em latências de operação mais altas e menor durabilidade

Resumo

Neste post, apresentamos uma solução simplificada para implementar a resolução central de DNS em um ambiente híbrido e de várias contas. Essa solução usa o Amazon Route 53 Resolver, o AWS Resource Access Manager e os recursos nativos do Route 53, e reduz a complexidade e o esforço operacional eliminando a necessidade de servidores DNS personalizados ou encaminhadores no ambiente da AWS.

Se você tiver algum feedback sobre esta publicação, envie os comentários na seção Comentários abaixo. Se você tiver dúvidas sobre esta publicação no blog, inicie um novo tópico nos fóruns da AWS.

 

Este artigo foi traduzido do Blog da AWS em Inglês.

 

Sobre o autor

Mahmoud Matouk faz parte dos nossos Arquitetos de Soluções do setor público, ajudando clientes de ensino superior a criar soluções inovadoras, seguras e altamente disponíveis usando vários serviços da AWS. Ele também é Arquiteto Principal com a equipe do Amazon Cognito, e  auxilia vários clientes da AWS a criar soluções seguras e inovadoras para vários cenários de gerenciamento de identidade e acesso.

 

 

 

 

Revisores

Bruno Lopes é Senior Solutions Architect no time da AWS LATAM. Trabalha com soluções de TI há mais de 14 anos, tendo em seu portfólio inúmeras experiências em cargas de trabalho Microsoft, ambientes híbridos e capacitação técnica de clientes como Technical Trainer e Evangelista. Agora atua como um Arquiteto de Soluções, unindo todas as capacidades para desburocratizar a adoção das melhores tecnologias afim de ajudar os clientes em seus desafios diários.

 

 

 

 

Pedro Rosinholi é Arquiteto de Soluções na AWS com mais de 11 anos de experiência em soluções de Tecnologia. Ajuda empresas nativas digitais na construção de seus negócios na nuvem de maneira segura, escalável e resiliente. No tempo livre coloca uns discos de vinil para tocar.