Resolvendo domínios privados entre contas usando o Route 53 Resolver

Olá pessoal, tudo bem?

Hoje vamos descobrir como podemos resolver nomes de domínios privados entre contas da AWS, utilizando o Route 53 Resolver.

Definindo o problema

Uma das recomendações da AWS é utilizarmos contas da diferentes para segregarmos acesso aos recursos, adicionando uma camada a mais de segurança. Essa separação pode ser feita de diversas formas, como contas para departamentos, ambientes, times, etc.

Outra recomendação é utilizarmos o AWS Organizations para vincular e organizar estas contas:

AWS Organizations

Porém, eventualmente precisaremos acessar recursos de uma conta à outra através de um VPC Peering, usando DNS. Até aí tudo bem, poderíamos configurar o route 53 local com o IP de destino. O problema é quando precisamos fazer algum acesso deste tipo à um recurso que ocasionalmente possa mudar o IP, como um ALB interno na conta destino.

Se o recurso também possuir um IP público, podemos configurar o peering para resolver o DNS público utilizando o IP privado. Isso é interessante pois trafegaremos as requisições dentro da rede da AWS, sem precisar sair para a internet.

Contudo, como no ALB interno citado acima, não teremos um IP público. Como resolvemos o DNS destes recursos então? Veremos isso na próxima sessão. 😀

Route 53 Resolver to the rescue!

Lançado em 2018, o Route 53 Resolver é uma solução para cloud híbrida e também para o problema definido acima.

Para isto precisaremos configurar o resolver em ambas as contas, uma como input e a outra como output. Abaixo veremos como a configuração é simples e rápida de ser feita. Para facilitar a nomenclatura, trataremos a conta que irá receber as requisições para resolver o DNS (input) como destino, e a que irá enviar estas requisições (output) como origem.

Configurando a conta destino para receber as consultas de DNS

No Route 53 devemos acessar o menu Endpoints de entrada.

Endpoints de entrada

Clicando em Criar endpoint de entrada, seremos levados a tela de configuração do endpoint. Aqui precisaremos informar os seguintes detalhes:

  • Nome do endpoint: Nome amigável para o endpoint;
  • VPC: A VPC que será usada para expor os IPs gerados pelo endpoint;
  • Grupo de segurança: Grupo de segurança que será usado para o endpoint. Irá controlar o acesso a resolução de endereços;
  • Endereços IP: O resolver solicita no mínimo duas subnets para que ele exponha os IPs de resolução de endereços.
Configuração do Endpoint de entrada

Feito isto, como no exemplo acima foram selecionadas duas subnets, o resolver irá criar duas ENIs na VPC selecionada, uma para cada subnet.

Endpoint de entrada criado
Detalhes do endpoint

Esta conta está pronta, agora vamos para a configuração da conta origem.

Configurando a conta origem para utilizar o resolver da conta destino

Na outra conta, precisamos configurar dois resources. O Endpoint de saída e a regra para a resolução do endereço.

Vamos começar pelo endpoint:

Endpoints de saída

A configuração do endpoint de saída é idêntica à configuração do endpoint de entrada. Então quando clicamos em Criar endpoint de saída veremos o seguinte:

Configuração do endpoint de saída

Após informarmos os dados necessários e clicarmos em enviar, teremos nosso endpoint de saída disponível.

Endpoint de saída disponível
Detalhes do endpoint de saída

Por fim, precisamos configurar a regra que irá ser aplicada na resolução do domínio.

Regras de resolução de domínios do resolver

Na regra, devemos informar:

  • Nome: Nome amigável da regra;
  • Tipo da regra: No caso definimos como Avançar (Forward);
  • Nome do domínio: O nome do domínio ao qual esta regra será utilizada. Então, sempre que alguém pedir para resolver o endereço privatezone.local, ele utilizará esta regra;
  • VPCs: As VPCs onde esta regra será aplicada;
  • Endpoint de saída: O endpoint de saída usado nesta regra;
  • Endereços IP de destino: Aqui iremos informar os endereços IPs gerados pelo Endpoint de entrada, criado na conta que receberá as consultas de DNS.
Criação da regra
Regra criada

Feito isto, tudo estará criado. Um último ponto importante é que precisamos ter a porta 53 liberada no grupo de segurança vinculado ao Endpoint de entrada.

Security Group – Endpoint de entrada

Testando a resolução de domínios entre as contas

Para testar, críamos uma zona privada na conta destino chamada privatezone.local (a mesma que foi configurada na rule criada acima).

Hosted Zone – conta destino

E na conta de origem, críamos uma lambda em Node.js para resolver o DNS acima (privatezone.local – 172.31.1.1). O código da lambda é bem simples, e pode ser observado abaixo:

const dns = require('dns');
const net = require('net');

exports.handler = (event, context) => {
    
    const d = 'privatezone.local';
    
    dns.resolve(d, (err, result) => {
        if (err) {
            console.error(`dns: ${d}; error: ${err}`);
        } else {
            console.log(`dns: ${d}; result: ${result}`);
        }
    })
 };

Lembrando que a lambda deve estar na mesma VPC onde o endpoint de saída foi criado, e que o peering entre as VPCs da conta de origem e destino deve estar corretamente configurado. Se testarmos a lambda teremos o resultado abaixo:

Execução da lambda – conta origem

Por hoje era isso, pessoal!

Abraços e boa semana a todos! 👍

Postado em AWS

Deixe uma resposta