Observação:

• Este tutorial requer acesso ao Oracle Cloud. Para se inscrever em uma conta gratuita, consulte Conceitos Básicos do Oracle Cloud Infrastructure Free Tier.
• Ele usa valores de exemplo para credenciais, tenancy e compartimentos do Oracle Cloud Infrastructure. Ao concluir seu laboratório, substitua esses valores por valores específicos do seu ambiente de nuvem.

Usar o Oracle Cloud Infrastructure DNS para Resolver Domínios Nativos

Introdução

A OraStage é uma empresa líder no setor de energia, especializada em soluções de energia renovável e tecnologias de energia inovadoras, a empresa anunciou uma decisão estratégica de migrar suas cargas de trabalho para a Oracle Cloud Infrastructure (OCI) para melhorar o desempenho, a escalabilidade e a segurança.

Tendo em conta as necessidades e condições específicas que o OraStage delineou, a empresa requer uma solução híbrida de Domain Name System (DNS) na nuvem, e por híbrida aqui significa: usar seu próprio sistema DNS Berkeley Internet Name Domain versão 9 (BIND9) além do serviço DNS do OCI, onde a arquitetura final que eles estão procurando construir é mostrada na imagem a seguir.

OraStage Requisitos de DNS:

• A empresa tem vários domínios e subdomínios internos, todos eles devem ser resolvidos pelo DNS BIND9 na OCI, em que OraStage gerenciará todas as zonas e registros relacionados. Um desses domínios é orastage.com, que usaremos neste tutorial. Portanto, qualquer consulta para orastage.com deve ser encaminhada para seu BIND9.

• Eles ainda precisam resolver domínios nativos do OCI (oraclevcn.com, oraclecloud.com etc.) em alguns casos, e isso será feito usando componentes DNS privados do OCI: views privadas, pontos finais e regras de encaminhamento e pontos finais de listening.

• Todas as consultas devem ser inspecionadas por uma instância de firewall pfSense.

• Para evitar um único ponto de falha, o OraStage planeja usar outro servidor DNS e aproveitar o OCI Load Balancer para distribuir consultas entre o DNS primário e secundário.

Esta série de tutoriais irá guiá-lo passo a passo para alcançar os requisitos descritos acima, construindo toda a solução do zero. Você pode navegar facilmente para cada tutorial na lista abaixo:

• Tutorial 1: Configurar DNS BIND9 no OCI. Saiba como instalar e configurar o BIND9 em uma instância de computação, tornando-o o servidor DNS local para dois ambientes de teste no OCI. Esses ambientes consistirão em servidores "Frontend" e "Backend", cada um hospedado em uma rede spoke separada. O servidor BIND9 tratará todas as consultas DNS direcionadas para orastage.com.

• Tutorial 2: Implementar Alta Disponibilidade no cenário de DNS BIND9 no OCI. Este tutorial se concentra na adição de um servidor BIND9 secundário e na configuração de um Balanceador de Carga de Rede (NLB) para distribuir o tráfego de DNS entre os dois servidores. As consultas de DNS para orastage.com serão direcionadas para o IP do NLB, que balanceará a carga entre os servidores BIND9 primários e secundários. Se um servidor ficar indisponível, a resolução de DNS continuará sem interrupção do serviço.

• Tutorial 3: Usar o DNS do OCI para resolver domínios nativos. Concentrando-se apenas em um caso de uso específico, em que utilizamos componentes DNS nativos na OCI, caso haja necessidade de resolver domínios nativos, como oraclevcn.com e oraclecloud.com. BIND9 O DNS não é usado neste tutorial.

• Tutorial 4: Adicionando segurança à arquitetura de DNS usando o Firewall pfSense. Concentrando-se na instalação de um Firewall pfSense na VCN hub no OCI e faça a configuração de rede necessária para rotear todo o tráfego Leste-Oeste, incluindo consultas de DNS (concluídas nos tutoriais anteriores) por meio do firewall a ser inspecionado.

Visão geral

Neste tutorial, nos concentraremos no tratamento de domínios nativos da OCI, como oraclevcn.com e oraclecloud.com. Nesta seção, deixaremos de resolver domínios personalizados como orastage.com usando BIND9 e, em vez disso, exploraremos os recursos de DNS integrados da OCI.

Vamos mergulhar nos componentes do DNS Privado da OCI e nos principais elementos envolvidos no tratamento de consultas, que desempenham funções cruciais no gerenciamento do tráfego de DNS nas redes privadas da OCI. Você notará que já os usamos em algumas partes do Tutorial 1 e do Tutorial 2. Esses componentes são:

• Zona de DNS Privado: Contém dados de DNS que só podem ser acessados em uma VCN como endereços IP privados. Uma zona privada de DNS tem recursos semelhantes para uma zona de DNS da internet, mas só fornece respostas para clientes que podem acessá-la por meio de uma VCN. Cada zona pertence a uma única view.

• View DNS Privada: Um agrupamento de zonas privadas, cada view pode ser associada a um resolvedor para controlar como as consultas de DNS são resolvidas. Uma única view pode ser utilizada por vários resolvedores, permitindo o compartilhamento de dados DNS privados em diferentes VCNs. Cada zona só pode fazer parte de uma exibição.

  Por exemplo, você criou duas novas VCNs: VCN-A e VCN-B. Por padrão, os recursos dentro da VCN-A podem resolver uns aos outros sem configuração adicional, porque seus registros são armazenados na mesma zona privada, que está na view privada da VCN-A. A mesma coisa para a VCN-B. No entanto, se quiser que os recursos da VCN-A resolvam recursos na VCN-B, associe a view privada do resolvedor da VCN-B à VCN-A. Se quiser que os recursos da VCN-B resolvam recursos na VCN-A, associe a view privada da VCN-A ao resolvedor da VCN-B.

• Resolvedor de DNS Privado: Um resolvedor de DNS privado dedicado da VCN fornece respostas às consultas de DNS na seguinte ordem: Primeiro, ele verificará zonas nas views privadas anexadas, depois em sua view padrão, depois verificando as regras de encaminhamento e, finalmente, usando o DNS da Internet. É basicamente o mecanismo que procura respostas para as consultas da sua instância.

  Por exemplo, a captura de tela a seguir mostra uma página do resolvedor de VCN. A sequência seguida ao resolver uma consulta de uma instância nessa VCN será semelhante a esta:

  

• Encaminhando Pontos Finais e Regras: Os pontos finais de encaminhamento servem como conectores entre sua VCN do OCI e resolvedores de DNS externos ou outras zonas de DNS. Usando regras de encaminhamento, você pode direcionar consultas DNS específicas para servidores externos designados ou listeners em outros resolvedores de VCN, permitindo arquiteturas DNS de nuvem híbrida ou resolução de várias zonas.

• Pontos Finais de Escuta: Esses pontos finais são usados para receber consultas de DNS de origens externas. Eles permitem que sua infraestrutura de DNS do OCI escute e responda a solicitações de DNS recebidas, aprimorando sua capacidade de gerenciar consultas de DNS em várias configurações de rede.

Juntos, esses componentes fornecem ferramentas avançadas para gerenciar e personalizar o DNS em seu ambiente OCI.

No final deste tutorial, você terá uma sólida compreensão de como usar esses componentes DNS do OCI para gerenciar e resolver consultas com eficiência em seu ambiente de nuvem.

Objetivos

• O principal objetivo deste tutorial é permitir que o cliente FE-VM (fe-vm.feprivatesubnet.frontendvcn.oraclevcn.com) consulte BE-VM (be-vm.beprivatesubnet.backendvcn.oraclevcn.com) e vice-versa, com o listener LSN para responder a todas essas consultas.

Arquitetura final

Observação:

• Ao criar inicialmente uma VCN e uma Sub-rede, você pode especificar labels de DNS para cada um deles e iniciar uma instância de computação. Você pode designar um nome de host a ela. No final, o FQDN (Nome de Domínio Totalmente Qualificado) da instância terá esta aparência: <VM-HOSTNAME>.<SUBNET-DNS-Label>.<VCN-DNS-Label>.oraclevcn.com. A especificação desses labels é opcional. Se você deixá-los vazios, eles receberão nomes aleatórios obtidos do nome do recurso, assim como FE-VM e BE-VM neste tutorial.

• Se precisássemos apenas de recursos do OCI para resolver um ao outro, não seria necessário um listener aqui, pois isso pode ser feito usando apenas views privadas, conforme mencionado na seção Visão Geral. No entanto, a razão por trás da escolha de usar um listener aqui é também lidar com a resolução de DNS de qualquer outro ambiente, como on-premises e outras nuvens, e adicionar todas as views privadas ao resolvedor desse listener será suficiente. Essa configuração aborda um caso de uso específico em que você também pode precisar de outros ambientes (on-premises ou outros ambientes em nuvem) para resolver recursos do OCI. No entanto, isso não está incluído neste tutorial.

• Todas as consultas oraclevcn.com e oraclecloud.com devem ser encaminhadas para o mesmo listener, independentemente de a consulta vir do OCI, da rede local ou de outra rede do provedor de nuvem, pois o resolvedor da LSN-VCN tratará todas essas consultas de views privadas.

• Neste tutorial, não vamos testar consultas on-premises ou do Microsoft Azure, mas apenas de instâncias da OCI. Portanto, o diagrama a seguir é apenas para fins de ilustração.

Pré-requisitos

• Acesso a uma tenancy e permissões do OCI para gerenciar a rede e os serviços de computação necessários.

• Entendimento básico de roteamento e segurança de rede do OCI e suas funcionalidades: Rede Virtual na Nuvem (VCN), Tabela de Roteamento, Gateway de Roteamento Dinâmico (DRG), Lista de Segurança, Bastion e Balanceador de Carga de Rede do OCI.

• Compreensão básica do DNS em geral.

• Certifique-se de concluir os dois primeiros tutoriais:

  1. Configure o Sistema de Nomes de Domínio BIND9 no Oracle Cloud Infrastructure.

  2. Implemente a Alta Disponibilidade no Sistema de Nomes de Domínio BIND9 no Oracle Cloud Infrastructure.

• É necessária uma VCN com uma sub-rede privada nela e anexe-a ao DRG existente. Para obter mais informações, consulte Tarefa 1.3: Anexar VCNs ao DRG.

  • LSN-VCN: Isso hospedará o listener. Observe que o listener não precisa estar em uma VCN dedicada, mas preferimos fazê-lo neste tutorial para separá-lo de outros recursos.

• Com base nos Pré-requisitos, você já deveria ter criado a arquitetura a seguir.

  

Tarefa 1: Configurar Componentes de Rede, como Roteamento e Segurança

Tarefa 1.1: Criar uma Rede Virtual na Nuvem (LSN-VCN)

Certifique-se de que você tenha a LSN-VCN (10.3.0.0/16) já criada, contendo LSN-Private-Subnet (10.3.0.0/24).

• Clique no menu de hambúrguer (≡) no canto superior esquerdo.

  

  1. Clique em Rede.
  2. Clique em Redes virtuais na nuvem.

  

• Podemos ver a VCN no local, no momento ela tem apenas uma sub-rede privada e a tabela de roteamento padrão e a lista de segurança anexadas a ela.

  

Tarefa 1.2: Configurar Roteamento e Segurança para LSN-VCN

• Isso deve ser feito no nível da sub-rede. Navegue até a página VCNs e clique em LSN-VCN.

  

• Clique na sub-rede privada.

  

• Clique em Tabela de Roteamento, que é uma tabela de roteamento designada.

  

• Adicione as regras a seguir.

  • 10.0.0.0/16 - DRG: Rotear o tráfego destinado à DNS-VCN para o DRG.
  • 10.1.0.0/16 - DRG: Rotear o tráfego destinado à VCN Frontend para o DRG.
  • 10.2.0.0/16 - DRG: Rotear o tráfego destinado à VCN de Backend para o DRG.

  

• Vamos fazer a segurança agora. Vá para a página Detalhes da Sub-rede e clique na lista de segurança designada.

  

• Permitir tráfego de entrada: tráfego de DNS (TCP/porta 53 e UDP/porta 53) proveniente de DNS-VCN, Frontend-VCN e Backend-VCN.

  

• Permitir todo o tráfego de saída.

  

Tarefa 1.3: Configurar Roteamento e Segurança para DNS-VCN

• Navegue até a página VCNs e clique em DNS-VCN.

  

• Clique na sub-rede privada.

  

• Clique em Tabela de Roteamento, que é uma tabela de roteamento designada.

  

• Adicione as regras a seguir.

  • 10.3.0.0/16 - DRG: Rotear o tráfego destinado à LSN-VCN para o DRG.

  

• As regras de segurança necessárias já foram adicionadas. Para obter mais informações, consulte Tutorial 1: Tarefa 1.4 - Configurar Roteamento e Segurança para DNS-VCN.

Tarefa 1.4: Configurar o Roteamento e a Segurança para a VCN Frontend

• Repita as etapas feitas na Tarefa 1.3 para Frontend-VCN.

Tarefa 1.5: Configurar o Roteamento e a Segurança da VCN de Backend

• Repita as etapas feitas na Tarefa 1.3 para Backend-VCN.

Tarefa 2: Configurar Componentes de DNS Privados do OCI

Tarefa 2.1: Adicionar Views Privadas ao Resolvedor de LSN-VCN

• Navegue até LSN-VCN e clique em Resolvedor de DNS.

  

  1. Role para baixo e clique em Views privadas associadas.
  2. Clique em Gerenciar views privadas.
  3. Selecione as views privadas de DNS-VCN, Frontend-VCN e Backend-VCN.
  4. Clique em Salvar alterações.
  5. As views privadas foram adicionadas com sucesso.

  

  

  

  No momento, o resolvedor de LSN-VCN tem visibilidade em todos os registros de DNS criados nas outras zonas privadas. Portanto, quando o listener receber qualquer consulta aos FQDNs FE-VM e BE-VM, ele será resolvido diretamente usando as views privadas associadas.

Tarefa 2.2: Configurar Ponto Final de Listening no Resolvedor de LSN-VCN

• Vá até a Console do OCI.

  1. No mesmo resolvedor, clique em Pontos Finais.
  2. Clique em Criar ponto final.
  3. Nome: Informe um nome para o ponto final.
  4. Sub-rede: Selecione a sub-rede privada da LSN-VCN.
  5. Tipo de ponto final: Selecione Listening.
  6. Endereço IP de escuta: Digite 10.3.0.6.
  7. Clique em Criar ponto final.
  8. O ponto final de listening foi criado com sucesso.

  

  

  

Tarefa 2.3: Configurar Regra de Encaminhamento no Resolvedor de VCN do Front-end

• Clique no menu de hambúrguer (≡) no canto superior esquerdo.

  

  1. Clique em Rede.
  2. Clique em Redes virtuais na nuvem.

  

• Clique em Frontend-VCN.

• Clique em Resolvedor de DNS da VCN.

• Rolar para Baixo.

  1. Clique em Regras.
  2. Clique em Gerenciar regras.
  3. Adicione outra regra com as informações a seguir, conforme mostrado na captura de tela.
  4. Clique em Salvar alterações.
  5. A regra de encaminhamento foi criada com sucesso.

  

  

  

Tarefa 2.4: Configurar Regra de Encaminhamento no Resolvedor de VCN de Backend

• Clique no menu de hambúrguer (≡) no canto superior esquerdo.

  

  1. Clique em Rede.
  2. Clique em Redes virtuais na nuvem.

  

• Clique em Backend-VCN.

  

• Clique em Resolvedor de DNS da VCN.

  

• Rolar para Baixo.

  1. Clique em Regras.
  2. Clique em Gerenciar regras.
  3. Adicione outra regra com as informações a seguir, conforme mostrado na captura de tela.
  4. Clique em Salvar alterações.
  5. A regra de encaminhamento foi criada com sucesso.

  

  

  

• A arquitetura deve ser assim.

  

Tarefa 3: Testar e Validar

Cenário de Teste 1: FE-VM para consultar o listener para o domínio nativo de BE-VM

• A máquina cliente FE-VM deve ser capaz de resolver be-vm.beprivatesubnet.backendvcn.oraclevcn.com. A imagem a seguir ilustra o cenário de teste que pretendemos alcançar.

  

• Vá para a Console do OCI, navegue até a instância BE-VM e copie o FQDN Interno para usá-lo no teste.

  

• Acesse FE-VM e execute um teste de consulta usando o serviço OCI Bastion, o mesmo que Tutorial 2: Cenário de Teste 1 - DNS Primário Responde a Consultas FE-VM quando o DNS Secundário está Inativo. Depois de conectado, execute consultas oraclevcn.com de FE-VM a be-vm.beprivatesubnet.backendvcn.oraclevcn.com e valide a configuração. Você pode usar vários métodos para verificar se a configuração está funcionando corretamente.

  1. Executar o comando host.
  2. Execute o comando ping.
  3. Execute o comando dig.

  

  

  

Conforme mostrado no cenário de teste, podemos recuperar o endereço IP do domínio nativo BE-VM e o ping está funcionando usando o FQDN, o que significa que o teste foi bem-sucedido.

Cenário de Teste 2: BE-VM para consultar o listener para o domínio nativo FE-VM

• A máquina cliente BE-VM deve ser capaz de resolver fe-vm.feprivatesubnet.frontendvcn.oraclevcn.com. A imagem a seguir ilustra o cenário de teste que pretendemos alcançar.

  

• Vá para a Console do OCI, navegue até a instância FE-VM e copie o FQDN Interno para usá-lo no teste.

  

• Acesse o BE-VM e execute um teste de consulta usando o serviço OCI Bastion. Depois de conectado, execute consultas oraclevcn.com de BE-VM a fe-vm.feprivatesubnet.frontendvcn.oraclevcn.com e valide a configuração. Você pode usar vários métodos para verificar se a configuração está funcionando corretamente.

  1. Executar o comando host.
  2. Execute o comando ping.
  3. Execute o comando dig.

  

  

  

Conforme mostrado no cenário de teste, podemos recuperar o endereço IP do domínio nativo BE-VM e o ping está funcionando usando o FQDN, o que significa que o teste foi bem-sucedido.

Próximas Etapas

Neste tutorial, usamos Views Privadas, Encaminhando Pontos Finais e Regras e Pontos Finais de Escuta da OCI, que oferecem gerenciamento de DNS flexível e robusto em uma rede virtual na nuvem. Juntos, esses componentes simplificam as operações de DNS, garantindo uma resolução de nome eficiente e escalável nos ambientes da OCI, especialmente para um cenário de DNS híbrido que inclui ambientes integrados multicloud e on-premises.

No próximo e último tutorial desta série, Adicionar Segurança à Arquitetura de DNS usando o Firewall pfSense, aprimoraremos a segurança de nossa infraestrutura de DNS configurando o Firewall pfSense para inspecionar e controlar todas as consultas de DNS. Isso incluirá solicitações de monitoramento e filtragem para domínios OCI internos (oraclevcn.com e oraclecloud.com) e domínios personalizados gerenciados em BIND9, como orastage.com.

Confirmações

• Autor - Anas abdallah (Especialista em Rede em Nuvem)

Mais Recursos de Aprendizagem

Explore outros laboratórios em docs.oracle.com/learn ou acesse mais conteúdo de aprendizado gratuito no canal Oracle Learning YouTube. Além disso, visite education.oracle.com/learning-explorer para se tornar um Oracle Learning Explorer.

Para obter a documentação do produto, visite o Oracle Help Center.

---

Título e Informações de Copyright

<

Use Oracle Cloud Infrastructure DNS to Resolve Native Domains

G16588-02

Copyright ©2025, Oracle and/or its affiliates.