O blog da AWS
AWS – Precisamos falar sobre a resolução de nome Híbrida com o Active Directory Domain Services
Por Caio Ribeiro César, Arquiteto de Soluções Especializadas em Tecnologia da Microsoft na nuvem AWS
Daniel Pires, Sr. Technical Account Manager na AWS
Quando os clientes revisam a arquitetura de ambientes AWS utilizando serviços Microsoft, é de suma importância definir o site do AD corretamente, juntamente com definições de sub-rede adequadas, para evitar que os clientes usem controladores de domínio distantes, pois isso causaria maior latência.
Precisamos falar sobre a resolução de nome Híbrida (Hybrid DNS) entre os serviços nativos da AWS e o Active Directory Domain Services (AD DS).
Vamos iniciar com os serviços utilizados.
1. Route 53 Resolver Endpoints & Conditional Forwarding Rules
O Route 53 fornece vários recursos de DNS, como: registro de domínio DNS público, capacidade de criar zonas DNS privadas, ferramentas DNS híbridas e resolução de nomes DNS. Com a resolução de nomes DNS, o Route 53 Resolver pode executar pesquisas recursivas em servidores de nomes públicos.
O recurso de Resolver Endpoint permite que consultas DNS originadas no ambiente on-premises e AD DS resolvam domínios hospedados na AWS. Para ambientes on-premises, a conectividade precisa ser estabelecida entre a infraestrutura DNS local e a AWS por meio de um Direct Connect (DX) ou uma Rede Privada Virtual (VPN). Os pontos de extremidade são configurados através da atribuição de endereço IP em cada sub-rede para a qual você deseja fornecer um resolvedor. Para que as consultas DNS de saída funcionem, elas são acionadas pela utilização de Conditional Forwarding Rule. Os domínios hospedados na sua infraestrutura DNS local podem ser configurados como regras de encaminhamento no Route 53 Resolver. As regras serão acionadas quando uma consulta for feita em um desses domínios e tentarão encaminhar solicitações de DNS para os servidores DNS configurados juntamente com as regras. Com esta funcionalidade, temos um conjunto de recursos que permitem a consulta bidirecional entre o ambiente on-premises ou o AD DS e a AWS através de conexões privadas.
2. Active Directory Domain Services (AD DS)
Aqui temos o bom e velho AD J. Podemos armazenar informações sobre objetos no ambiente, tornando essas informações fáceis de serem encontradas e usadas por administradores e usuários. O Active Directory Domain Services (AD DS) usa os serviços de resolução de nomes DNS (sistema de nomes de domínio) para possibilitar que os clientes localizem controladores de domínio e os controladores de domínio que hospedam o serviço de diretório para se comunicarem entre si. Em outras palavras, ao criar um novo servidor e efetuar um “domain join”, temos o Fully Qualified Domain Name criado no DNS, já integrado com o AD.
Com o aumento da utilização de serviços Microsoft na nuvem AWS, nossos clientes estão integrando estes serviços para melhor acomodar a arquitetura de resolução de nome na nuvem AWS em cenários Híbridos.
A maioria destes clientes já possui uma infraestrutura de DNS local. Quando os recursos na AWS são criados, a AWS fornece serviços DNS fornecidos pelo Amazon Route 53 como um serviço gerenciado.
Se você possuir o Managed AD ou o AD Connector, ao criar uma instância do Windows EC2, ela poderá ingressar automaticamente no Active Directory (Seamless Domain Join). Quando você escolhe essa configuração, a AWS define as configurações de DNS na interface de rede dentro da instância do EC2 para os endereços IP dos servidores DNS fornecidos pelo Managed AD ou AD Connector, consequentemente as instâncias são associadas ao domínio do AD.
Se iniciarmos uma instância do EC2 Linux ou Windows e não utilizarmos o recurso de seamless domain join, as configurações de DNS da instância serão fornecidas pelas configurações de DHCP da VPC (dhcp option set)*.
Por padrão, as configurações de DHCP fornecem o endereço de rede do Route 53, “+2”, ou seja, se a subnet for 10.0.1.0/24, o ponto de extremidade do R53 estará em 10.0.1.2.
Vamos então demonstrar a criação de uma infraestrutura DNS híbrida que permite integrar sua infraestrutura DNS local ao DNS do Amazon Route 53.
1. No ambiente on-premises (ou AD em EC2), temos:
a. Diretório “caiorc.corp” criado no AD Connector.
b. Domain Controller com DNS, endereço IP 10.0.8.205.
2. A primeira etapa é criar o R53 Outbound Endpoint, que irá permitir que o Route 53 resolver encaminhe consultas DNS para domínios DNS hospedados fora do R53. Quando criamos este Oubtound Endpoint, a AWS cria uma interface de rede elástica (ENI) nas Zonas de Disponibilidade (AZ) que especificarmos.
3. Fomos até a console do Route 53 e selecionamos a opção “Resolver > Outbound Endpoint” e então “Configure endpoints”.
4. Selecionamos a opção “Outbound only”.
5. Selecionamos o nome para o endpoint, juntamente com o security group que deve possuir acessos de-para o seu fleet de Domain Controllers. Posteriormente, adicionamos dois endereços IPs em Zonas de Disponibilidade diferentes para garantir alta disponibilidade.
6. Agora, iremos criar as Resolver Rules. Estas regras permitem duas ações: Forward ou System. Com a ação Forward, iremos configurar o Route 53 Resolver para encaminhar consultas DNS para domínios DNS específicos a resolvedores DNS externos (por exemplo, os DNS locais). Com o System Rule, o Route 53 consultará a hierarquia quanto à resolução de nomes (zonas DNS Privadas, DNS VPC e DNS Público).
7. Selecionamos um nome para a regra, juntamente com a opção “Forward” e então adcionamos o nome do nosso domínio local (caiorc.corp). As consultas DNS para esse nome de domínio são encaminhadas para o endereço IP especificado na seção Endereços IP de destino, na parte inferior da página (que serão os IPs dos nossos servidores AD DS).
8. Para permitir que a infraestrutura DNS local (on-premises por exemplo) consulte o Route 53 Resolver em busca de zonas DNS hospedadas no Route 53, precisamos criar Inbound Endpoints. Os Inbound Endpoints permitem que outros serviços consultem o Route 53 quanto à resolução de DNS. Quando criamos um Inbound Endpoint, a AWS cria uma interface de rede elástica (ENI) em cada zona de disponibilidade (AZ) especificada para receber as consultas DNS de entrada.
9. Na console do Route 53, selecionamos a opção de “Inbound Endpoint > Create Inbound Endpoint”. Adicionamos um nome, VPC e Security Group e posteriormente endereços IPs em Availability Zones diferentes.
10. Criamos o conditional forwarder no DNS local para resolver a pesquisa direta da zona da AWS (por exemplo, ec2.internal). Isso permite que os clientes DNS locais emitam consultas de encaminhamento de DNS para as instâncias da AWS por seus nomes DNS internos.
Importante: caso você possua um ambiente de Managed Active Directory, como estes servidores estão na sua VPC, podemos utilizar o “VPC +2 Resolver” para o conditional forwarder. Ou seja, na nossa VPC com o CIDR “10.0.0.0/16” teríamos um conditional de “sa-east-1.compute.internal” para o IP “10.0.0.2” e não os endereços IP do Route 53 Inbound Endpoint.
Agora iremos testar as configurações acima para o Outbound Endpoint.
1. Iremos acessar uma instância que não está domain joined (Linux) com o DHCP Option set padrão (Route 53).
2. Nesta EC2, confirmamos as configurações de DNS e então efetuamos um query para o domínio “corp”.
Finalmente, testamos as configurações acima para o Inbound Endpoint.
1. Em um computador do ambiente on-premises, efetuamos um nslookup para o endereço interno de uma instância EC2.
Um passo além: Multi-Accounts com Private Hosted Zones
Por mais que o ambiente acima nos ajude para os FQDNs do “.2 Resolver”, precisamos endereçar o cenário de organizações que cresceram o suficiente para possuir ambientes multi-accounts e criam Private Hosted Zones para ter mais controles de Resolução de Nomes no ambiente AWS.
Cenário: resolução de nome híbrida em ambientes multi-account com Active Directory. Este cenário pode ser encontrado no Blog Post do Sr. Solutions Architect Mahnmoud Matouk (leitura recomendada).
1. Inicialmente, criaremos uma Private Hosted Zone (PHZ) em “Route 53 > Hosted Zones > Create Hosted Zone”.
2. No Setup de criação desta PHZ, selecionamos a opção de “Private Hosted Zone” e associamos esta PHZ com uma VPC.
3. Criamos um record “A” com o IP de algum servidor desta VPC, para caráter de teste.
4. Em “Route 53 > Resolver > Inbound Endpoints”, criamos um Inbound Endpoint para esta VPC.
5. Como associamos o Inbound e a PHZ para esta VPC, um host desta VPC deve resolver o nome “linux.internal.aws” para o IP “192.168.1.23”:
6. Agora, habilitamos o ambiente on-premises para resolver os nomes desta PHZ. Seguiremos o mesmo modelo comentado anteriormente e iremos criar um Conditional Forwarder para os IPs de Inbound Endpoint. Após esta alteração, hosts que utilizam DNS Servers deste ambiente on-premises devem resolver o nome ‘linux.internal.aws” para o IP “192.168.1.23”.
7. Iremos criar um Outbound Endpoint Forwarding Rule para o nosso DNS do ambiente on-premises (AD).
8. O servidor linux da VPC “192.168.0.0/16” deve resolver o DNS “caiorc.corp” para o endereço IP “10.0.8.205”. Como podem ver, estes IPs estão em CIDRs diferentes – ou seja, temos conectividade de rede entre estas VPCs para que isto funcione.
9. Para que as sub-accounts consigam resolver os FQDNs da Private Zone (aws), iremos criar um novo Forwarding Rule apontando o “internal.aws” para os IPs do nosso Inbound Endpoint. Isso irá habilitar que estas contas consigam efetuar o Forwarding para estes IPs. Neste passo, não associamos esta rule com nenhuma VPC (ela servirá apenas para o forward de resoluções de nome).
10. O próximo passo é fazer a expansão desta configuração para multi-accounts. Iremos utilizar o Resource Access Manager (RAM) para compartilhar recursos entre contas. Para esta configuração, acessamos a Conta Principal em “Resource Access Manager > Configuration”.
11. Agora, compartilhamos as Rules de Outbound Endpoint para nossas contas secundárias. Para esta configuração, iremos para o “Resource Access Manager > Resource shares > Create resource share”.
12. Na opção de resources, selecionamos as regras de Forwarding criadas nos passos 7 e 9 e compartilhamos com as contas necessárias.
13. Na Shared Account, podemos listar as Resolver Rules:
14. Agora, associamos as regras para a VPC da conta secundária:
15. Iniciamos um servidor na VPC da conta secundária. Com a premissa de que temos o networking entre as VPC’s (peering , roteamento e security groups configurados corretamente), iremos efetuar o teste de DNS.
a) Resolução de nome da PHZ da conta primária “linux.internal.aws”.
b. Resolução de nome do nosso DNS (AD) do ambiente on-premises “caiorc.corp”.
16. Agora, qualquer record criado em uma Private Zone nesta conta secundária será resolvido pelo ambiente on-premises e também pela conta primária. No Route 53 da conta secundária (subdomain secundaria.internal.aws), criamos uma segunda PHZ com um record A para um IP de um servidor qualquer.
17. Agora, precisamos associar este Private Zone com o DNS da conta primária. Isto irá fazer com que o DNS da conta primária seja o “resolver” entre as AWS Accounts. Como os recursos existem em diferentes accounts, precisamos criar um pedido de autorização da conta que possui a private zone (secundária) para a conta primária. Desta vez, utilizaremos o AWS CLI.
a. Na conta secundária, criamos a autorização utilizando o Private ID da nossa zona (secundaria.internal.aws) e informações da região e o ID da VPC Primária.
aws route53 create-vpc-association-authorization --hosted-zone-id <hosted-zone-id> --vpc VPCRegion=<region> ,VPCId=<vpc-id>
b. Na conta primária, associamos o VPC com a Private Hosted Zone da conta secundária.
aws route53 associate-vpc-with-hosted-zone --hosted-zone-id <hosted-zone-id> --vpc VPCRegion=<region>,VPCId=<vpc-id>
Podemos confirmar a associação executando o comando “aws route53 list-vpc-association-authorizations” na conta secundária:
18. Finalmente, testamos a resolução de nomes do ambiente on-premises e da conta primária para a Private Hosted Zone da conta secundária.
a. EC2 Linux da VPC da conta primária.
b. Domain Joined computer ou DNS do ambiente on-premises.
Neste post, mencionamos algumas recomendações em ambientes AWS com DNS híbrido utilizando o Route 53 Resolver e o AD DS.
Notas de recomendação:
- Utilize controladores de domínio como servidores DNS, pois os controladores de domínio suportam recursos como atualizações dinâmicas dos clientes DNS do Windows. Outros tipos de servidores DNS (DNS sem a role de Domain Controller, também conhecidos como “não acoplados”), podem não suportar esses recursos.
- Tente manter a resolução de nomes DNS local na região da AWS para redução de latência.
- Compartilhe pontos de extremidade centralizados do Route 53 Resolver em todas as VPCs da sua organização. Crie conditional forwarders nos servidores DNS locais para todas as zonas DNS do Route 53 e zonas DNS no AWS Managed AD (ou AD DS em EC2, onprem) e aponte-os para os Endpoints do resolvedor do Route 53.
- Utilize o Amazon DNS Server (Route 53) como “encaminhador” (Conditional Forwarder) de todos os outros domínios DNS que não são autorizados em seus servidores DNS nos controladores de domínio AD. Essa configuração permite que seus controladores de domínio resolvam recursivamente os registros na zona privada do Amazon Route 53 e usem os encaminhadores condicionais do Route 53 Resolver.
- Use o Route 53 Resolver Endpoint para criar um hub de resolução de DNS e gerenciar o tráfego DNS criando conditional forwarders.
*Alguns administradores adicionam as informações de DHCP Option Set apontando para os servidores DNS do Active Directory. Por mais que isto funcione para a resolução de AD DS, perdemos a resolução de “ec2.internal”, nos forçando a criar um Conditional Forwarder no AD DS para esta resolução apontando para o Route 53. A instância do Amazon EC2 limita o número de pacotes que podem ser enviados ao servidor DNS fornecido pela Amazon a um máximo de 1024 pacotes por segundo por interface de rede. Este limite não pode ser aumentado. Se você se deparar com esse limite de desempenho, recomendamos a configuração deste post para o encaminhamento condicional para zonas privadas do Amazon Route 53 para usar o serviço de Resolver bem como root hints para a resolução de nomes da Internet.
Para mais informações sobre estes cenários, recomendamos a sessão do Gavin McCullagh, “AWS re:Invent 2019: Deep dive on DNS in the hybrid cloud (NET410)”.
Sobre os autores
Caio Ribeiro César atualmente trabalha como arquiteto de soluções especializadas em tecnologia da Microsoft na nuvem AWS. Ele iniciou sua carreira profissional como administrador de sistemas, que continuou por mais de 13 anos em áreas como Segurança da Informação, Identity Online e Plataformas de Email Corporativo. Recentemente, se tornou fã da computação em nuvem da AWS e auxilia os clientes a utilizar o poder da tecnologia da Microsoft na AWS.
Daniel Pires atualmente trabalha como Sr. Technical Account Manager na Amazon Web Services. Ele trabalhou com tecnologias Microsoft por mais de 15 anos (Active Directory, Identidade Híbrida, Microsoft Azure).