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.

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

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 descritas pelo OraStage, a empresa exige um sistema de nomes de domínio (DNS) híbrido. Solução na nuvem, e por híbrido aqui significa usar seu próprio sistema DNS Berkeley Internet Name Domain versão 9 (BIND9), além do serviço DNS da 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

Hoje, uma infraestrutura de DNS confiável e eficiente é crucial para garantir operações de rede contínuas. No primeiro tutorial: Configurar o Sistema de Nomes de Domínio BIND9 no Oracle Cloud Infrastructure, já explicamos como o BIND9, um dos softwares DNS mais usados, que fornece recursos robustos e flexibilidade para gerenciar serviços DNS, pode ser implantado e usado na OCI. Enquanto um único servidor BIND9 pode lidar com solicitações DNS de forma eficaz, adicionar um segundo servidor BIND9 oferece inúmeras vantagens que melhoram o desempenho geral e a confiabilidade da sua rede.

Este tutorial o guiará pelo processo de configuração de um servidor BIND9 secundário e de um balanceador de carga no OCI, destacando os benefícios dessa configuração. Ao implementar isso, você obterá:

Redundância: Garantindo a disponibilidade contínua de serviços de DNS, mesmo que o servidor primário falhe.
Balanceamento de Carga: Distribuindo a carga de consulta de DNS entre servidores, melhorando os tempos de resposta e reduzindo o risco de sobrecarga.
Distribuição Geográfica: Se necessário, a colocação de servidores DNS em diferentes locais pode fornecer tempos de resposta mais rápidos para usuários globais.
Segurança Aprimorada: Atenuação de riscos separando e protegendo serviços de DNS em vários servidores.

Serviço OCI Network Load Balancer

Um Balanceador de Carga de Rede Flexível (NLB) do OCI é um serviço que ajuda a distribuir o tráfego de entrada entre vários recursos de backend. Isso é particularmente útil para gerenciar grandes volumes de tráfego e garantir que os aplicativos permaneçam disponíveis e responsivos, mesmo que um ou mais servidores falhem.

O Balanceador de Carga de Rede do OCI opera na Camada 3 e na Camada 4 do modelo OSI (Open Systems Interconnection), manipulando protocolos como TCP (Transmission Control Protocol), UDP (User Datagram Protocol) e ICMP (Internet Control Message Protocol). Ao equilibrar a carga com eficiência, ela pode melhorar o desempenho do aplicativo, fornecer alta disponibilidade e melhorar a escalabilidade geral do sistema. O serviço também oferece recursos como verificações de integridade para monitorar o status dos servidores de backend, garantindo que o tráfego seja direcionado apenas para instâncias íntegras e operacionais.

Em resumo, um Balanceador de Carga de Rede da OCI desempenha um papel fundamental na manutenção da confiabilidade e escalabilidade das aplicações, distribuindo de forma inteligente o tráfego de rede entre vários recursos. Devido a todos os benefícios que mencionamos, adicionaremos um balanceador de carga de rede à nossa configuração para otimizar nossa solução de DNS.

Objetivos

Implemente o OCI Network Load Balancer e um servidor BIND9 secundário na OCI perfeitamente integrado à sua rede, garantindo uma infraestrutura de DNS robusta e resiliente.
O principal objetivo deste tutorial é permitir que o cliente FE-VM (fe.orastage.com) consulte BE-VM (be.orastage.com) e vice-versa, com o DNS-NLB distribuindo solicitações do cliente entre DNS Principal (primary-dns.orastage.com) e DNS Secundário (secondary-dns.orastage.com) para responder a todas as consultas.

Arquitetura Final

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.
Conhecimento básico do serviço OCI Logging.
Compreensão básica do Ubuntu Linux e DNS em geral.
Certifique-se de concluir o primeiro tutorial: Configurar o Sistema de Nomes de Domínio BIND9 no Oracle Cloud Infrastructure, no qual você já deveria ter criado a arquitetura a seguir.

Tarefa 1: Provisionar Instância de DNS Secundário e Configurar BIND9

Consulte o primeiro tutorial: Configurar Sistema de Nomes de Domínio BIND9 no Oracle Cloud Infrastructure, em que a Tarefa 2 e a Tarefa 3 mostram a criação e a configuração da instância do DNS Principal, as mesmas tarefas devem ser feitas para configurar o DNS Secundário; considere as seguintes informações:

O nome da instância será DNS Secundário.
Ele residirá na mesma sub-rede que o DNS Principal e um endereço IP 10.0.0.20 deverá ser designado a ele.
Por meio do processo de configuração, toda vez que DNS Principal 10.0.0.10 for mencionado, ele deverá ser substituído por DNS Secundário 10.0.0.20, um exemplo é o FQDN dessa instância que deve ser secondary-dns.orastage.com.
Use a mesma chave SSH.
O mesmo Bastion do OCI usado para acessar o DNS Principal também pode ser usado para acessar o DNS Secundário, mas usando uma nova sessão.
No arquivo /var/lib/bind/db.orastage.com para instâncias primárias e secundárias, certifique-se de que todos os registros a seguir estejam presentes para que ambos os servidores DNS possam resolver um ao outro, além das instâncias FE-VM e BE-VM.
```
primary-dns                 IN  A       10.0.0.10
secondary-dns               IN  A       10.0.0.20
fe                          IN  A       10.1.0.5
be                          IN  A       10.2.0.5
```

No final desta tarefa, a arquitetura deverá ter esta aparência:

Tarefa 2: Configurar um Balanceador de Carga de Rede do OCI

Tarefa 2.1: Adicionar Detalhes

Clique no menu de hambúrguer (≡) no canto superior esquerdo.
1. Clique em Rede.
2. Clique em Balanceador de carga de rede.
Clique em Criar balanceador de carga da rede.
1. Nome do balanceador de carga: Digite um nome.
2. Escolher tipo de visibilidade: Selecione Privado.
3. Escolher rede: Selecione DNS-VCN e sua sub-rede privada, onde colocaremos o balanceador de carga de rede.
4. Clique em Próximo.

Tarefa 2.2: Configurar um Listener

Um listener é um componente essencial em um balanceador de carga que é responsável por receber um tipo específico de tráfego com determinadas portas (por exemplo, TCP/port 80, UDP/port 21) e direcioná-lo para servidores de back-end. Neste tutorial, queremos que o listener escute na porta 53 (TCP) e (UDP), pois o DNS usa ambos.

Digite as seguintes informações.
1. Nome do listener: Informe um nome.
2. Especifique o tipo de tráfego que o listener trata: Selecione UDP/TCP.
3. Especifique a porta: informe o número da porta 53.
4. Clique em Próximo.

Tarefa 2.3: Escolher um Conjunto de Backend

Um conjunto de backend é um agrupamento lógico de servidores de backend para os quais o balanceador de carga de rede roteia o tráfego. Nossos servidores de backend aqui serão DNS Principal e DNS Secundário.

Digite as seguintes informações.
1. Nome do conjunto de backend: Informe um nome de conjunto de backend.
2. Clique em Adicionar back-ends.
3. Tipo de backend: Selecione Instâncias do serviço Compute.
4. Instâncias de computação do backend IPv4: Escolha os dois servidores DNS: DNS Principal e DNS Secundário.
5. Clique em Adicionar back-ends.
6. Você pode ver que os servidores de backend foram adicionados ao conjunto.
7. Especificar política de verificação de integridade: Uma política de verificação de integridade é usada para verificar a disponibilidade de servidores de backend fazendo solicitações ou tentando conexões. O balanceador de carga de rede executa essas verificações de integridade em intervalos regulares especificados, usando essa política para monitorar continuamente o status dos servidores de backend.
8. Clique em Próximo.

Tarefa 2.4: Revisar e Criar

Verifique todos os detalhes e clique em Criar balanceador de carga de rede.
O DNS-NLB é criado, anote o endereço IP privado, pois o usaremos na Tarefa 3.

Tarefa 2.5: Adicionar uma Regra de Segurança

Para evitar a falha da verificação de saúde e garantir uma comunicação suave sem qualquer interrupção do tráfego.

Adicione as regras a seguir na lista de segurança DNS-Private-Subnet. Isso permite o tráfego de DNS enviado do balanceador de carga de rede para seus backends.
A arquitetura deve ter a aparência mostrada na imagem a seguir.

Tarefa 3: Configurar Regras de Encaminhamento de DNS do OCI

Tarefa 3.1: Configurar Regra de Encaminhamento da VCN de Frontend

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. Altere o Endereço IP de destino do endereço IP Primary-DNS para o endereço IP DNS-NLB (10.0.0.110) criado na Tarefa 2.
4. Clique em Salvar alterações.
5. O Endereço IP de destino foi alterado com sucesso. Portanto, agora todas as consultas de FE-VM serão encaminhadas para o endereço IP DNS-NLB, que as distribuirá entre servidores DNS primários e secundários.

Tarefa 3.2: Configurar Regra de Encaminhamento de Backend-VCN

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. Altere o Endereço IP de destino do endereço IP Primary-DNS para o endereço IP DNS-NLB (10.0.0.110) criado na Tarefa 2.
4. Clique em Salvar alterações.
5. O Endereço IP de destino foi alterado com sucesso. Portanto, agora todas as consultas de BE-VM serão encaminhadas para o endereço IP DNS-NLB, que as distribuirá entre servidores DNS primários e secundários.

Tarefa 4: Testar e Validar

Pré-Requisito

Ativar Logs: Para verificar o fluxo de tráfego, ativaremos logs de fluxo de sub-rede, que nos permite monitorar e rastrear o tráfego de rede entrando ou saindo de uma sub-rede específica. Esses logs capturam detalhes sobre o tráfego de rede, como endereços IP de origem e destino, números de porta e a quantidade de dados que estão sendo transmitidos. Para ativar o log, siga as etapas:
1. Vá para a sub-rede privada DNS-VCN, na qual DNS Principal, DNS Secundário e DNS-NLB residem.
2. Clique em Logs.
3. Selecione Ativar Log.
Para obter mais informações sobre logs e como utilizá-los no OCI, consulte
- Logs de Fluxo da VCN.
- Detalhes dos Logs de Fluxo da VCN - Saiba como ler o conteúdo do log.
- Siga os Pacotes em uma Arquitetura de Roteamento de VCN Hub e Spoke dentro da OCI - Um tutorial útil para saber como rastrear pacotes de rede em um ambiente OCI usando vários métodos, como captura de pacotes de firewall, logs de sub-rede e TCPdump. Siga as Tarefas 6 e 13.
  - Tarefa 6: Ativar Registro em Log (Todos os Logs) na Sub-rede Privada Falada.
  - Tarefa 13: Observe todos os Pontos de Registro e Capturas de Pacote e Siga o Caminho - Ponto de Registro B.

Agora todo o tráfego de entrada e saída dessa sub-rede será registrado.

Cenário de Teste 1: O DNS Primário Responde a Consultas FE-VM quando o DNS Secundário está Inativo

No caso de uma falha no DNS Secundário, precisamos garantir que o DNS Principal responda às consultas provenientes do FE-VM, pois o DNS-NLB está direcionando o tráfego para ele.

A imagem a seguir ilustra o cenário de teste que pretendemos alcançar.
Atualmente, todas as instâncias estão ativas e em execução. Vamos começar fazendo shutdown da instância do DNS Secundário. Clique no menu de hambúrguer (≡) no canto superior esquerdo.
1. Clique em Calcular.
2. Clique em Instâncias.
1. Marque a caixa de seleção ao lado da instância.
2. Clique em Ações.
3. Clique em Interromper.
4. Clique em Interromper.
5. A instância agora está no estado Interrompida.
Acesse FE-VM e conduza um teste executando uma consulta. Para fazer isso, usaremos o serviço OCI Bastion. Clique no menu de hambúrguer (≡) no canto superior esquerdo.
1. Clique em Identidade e Segurança.
2. Clique em Bastion.
Clique em FEBastion.
Clique em Criar sessão.
Digite as seguintes informações.
1. Tipo de sessão: Selecione Sessão SSH Gerenciada.
2. Nome da sessão: Informe um nome para a sessão.
3. Nome do Usuário: Informe o nome do usuário. Para a instância do Oracle Linux, o nome do usuário padrão é opc.
4. Instância de computação: Selecione a instância FE-VM.
5. Cole a mesma chave pública gerada no Tutorial 1: Tarefa 2.1: Gerar Par de Chaves SSH.
6. Clique em Criar sessão.

Depois que a sessão for criada, clique nos três pontos e em Copiar comando SSH.

O comando deve ter esta aparência:

ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-milan-1.amaaaaaaldij5aiaxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxzo2q7dka@host.bastion.eu-milan-1.oci.oraclecloud.com" -p 22 opc@10.1.0.5

Abra o OCI Cloud Shell.
1. Navegue até o diretório .ssh usando o comando cd .ssh.
2. Cole o comando SSH. Certifique-se de substituir <privateKey> pelo nome de arquivo da chave privada id_rsa.
3. Insira sim.
Log foi estabelecido com êxito. Agora, execute uma consulta de teste de FE-VM a be.orastage.com usando o comando host. Verifique se a consulta foi bem-sucedida e se uma resposta foi recebida.
Sabemos que há apenas um servidor de backend íntegro para tratar a solicitação, que é DNS Principal. Então, aqui vamos verificar o fluxo da consulta DNS e ver qual servidor respondeu a essa consulta usando logs de sub-rede do OCI.
1. Clique no log.
2. A solicitação foi do Ponto Final de Encaminhamento (10.1.0.6), que é colocado na mesma sub-rede que FE-VM para o endereço IP do NLB (10.0.0.110) na DNS-VCN.
3. Em seguida, no endereço IP do NLB (10.0.0.110), a solicitação é enviada para o DNS Principal (10.0.0.10).
O teste teve êxito. O DNS Principal conseguiu tratar consultas de DNS no caso de o DNS Secundário estar inativo.

Cenário de Teste 2: DNS Secundário Responde a Consultas FE-VM quando o DNS Primário está Inativo

No caso de uma falha no DNS Principal, precisamos garantir que o DNS Secundário responda às consultas provenientes do FE-VM, pois o DNS-NLB está direcionando o tráfego para ele.

A imagem a seguir ilustra o cenário de teste que pretendemos alcançar.
Vamos começar fazendo shutdown da instância Primary-DNS. Clique no menu de hambúrguer (≡) no canto superior esquerdo.
1. Clique em Calcular.
2. Clique em Instâncias.
1. Marque a caixa de seleção ao lado da instância.
2. Clique em Ações.
3. Clique em Interromper.
4. Clique em Interromper.
5. A instância agora está no estado Interrompida.
Inicie a instância do DNS Secundário.
1. Marque a caixa de seleção ao lado da instância.
2. Clique em Ações.
3. Clique em Iniciar.
4. Clique em Iniciar.
5. A instância agora está no estado Em Execução.
Em seguida, acessaremos FE-VM e realizaremos um teste executando uma consulta. Para fazer isso, usaremos o serviço OCI Bastion. Clique no menu de hambúrguer (≡) no canto superior esquerdo.
1. Clique em Identidade e Segurança.
2. Clique em Bastion.
Clique em FEBastion.
Clique em Criar sessão.
Digite as seguintes informações.
1. Tipo de sessão: Selecione Sessão SSH Gerenciada.
2. Nome da sessão: Informe um nome para a sessão.
3. Nome do Usuário: Informe o nome do usuário. Para a instância do Oracle Linux, o nome do usuário padrão é opc.
4. Instância de computação: Selecione a instância FE-VM.
5. Cole a mesma chave pública gerada no Tutorial 1: Tarefa 2.1: Gerar Par de Chaves SSH.
6. Clique em Criar sessão.

Depois que a sessão for criada, clique nos três pontos e em Copiar comando SSH.

O comando deve ter esta aparência:

ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-milan-1.amaaaaaaldij5axxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxzo2q7dka@host.bastion.eu-milan-1.oci.oraclecloud.com" -p 22 opc@10.1.0.5

Abra o OCI Cloud Shell.
1. Navegue até o diretório .ssh usando o comando cd .ssh.
2. Cole o comando SSH. Certifique-se de substituir <privateKey> pelo nome de arquivo da chave privada id_rsa.
3. Insira sim.
Log foi estabelecido com êxito. Agora, execute uma consulta de teste de FE-VM a be.orastage.com usando o comando host. Verifique se a consulta foi bem-sucedida e se uma resposta foi recebida.
Sabemos que há apenas um servidor de backend íntegro para tratar a solicitação, que é DNS Secundário. Então, aqui vamos verificar o fluxo da consulta DNS e ver qual servidor respondeu a essa consulta usando logs de sub-rede do OCI.
1. Clique no log.
2. A solicitação foi do Ponto Final de Encaminhamento (10.1.0.6), que é colocado na mesma sub-rede que FE-VM para o endereço IP do NLB (10.0.0.110) na DNS-VCN.
3. Em seguida, no NLB (10.0.0.110), a solicitação é enviada para o DNS Secundário (10.0.0.20).
O teste teve êxito. O DNS Secundário pode tratar consultas de DNS caso o DNS Principal esteja inativo.

Cenário de Teste 3: O DNS Primário Responde a Consultas BE-VM quando o DNS Secundário está Inativo

No caso de uma falha no DNS Secundário, precisamos garantir que o DNS Principal responda às consultas provenientes do BE-VM, pois o DNS-NLB está direcionando o tráfego para ele.

A imagem a seguir ilustra o cenário de teste que pretendemos alcançar.
Atualmente, todas as instâncias estão ativas e em execução. Vamos começar fazendo shutdown da instância do DNS Secundário. Clique no menu de hambúrguer (≡) no canto superior esquerdo.
1. Clique em Calcular.
2. Clique em Instâncias.
1. Marque a caixa de seleção ao lado da instância.
2. Clique em Ações.
3. Clique em Interromper.
4. Clique em Interromper.
5. A instância agora está no estado Interrompida.
Em seguida, acessaremos o BE-VM e realizaremos um teste executando uma consulta. Para fazer isso, usaremos o serviço OCI Bastion. Clique no menu de hambúrguer (≡) no canto superior esquerdo.
1. Clique em Identidade e Segurança.
2. Clique em Bastion.
Clique em BEBastion.
Clique em Criar sessão.
Digite as seguintes informações.
1. Tipo de sessão: Selecione Sessão SSH Gerenciada.
2. Nome da sessão: Informe um nome para a sessão.
3. Nome do Usuário: Informe o nome do usuário. Para a instância do Oracle Linux, o nome do usuário padrão é opc.
4. Instância de computação: Selecione a instância BE-VM.
5. Cole a mesma chave pública gerada no Tutorial 1: Tarefa 2.1: Gerar Par de Chaves SSH.
6. Clique em Criar sessão.

Depois que a sessão for criada, clique nos três pontos e em Copiar comando SSH.

O comando deve ter esta aparência:

ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-milan-1.amaaaaaaldij5axxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxuk7pafla@host.bastion.eu-milan-1.oci.oraclecloud.com" -p 22 opc@10.2.0.5

Abra o OCI Cloud Shell.
1. Navegue até o diretório .ssh usando o comando cd .ssh.
2. Cole o comando SSH. Certifique-se de substituir <privateKey> pelo nome de arquivo da chave privada id_rsa.
3. Insira sim.
Log foi estabelecido com êxito. Agora, execute uma consulta de teste de BE-VM a fe.orastage.com usando o comando host. Verifique se a consulta foi bem-sucedida e se uma resposta foi recebida.
Sabemos que há apenas um servidor de backend íntegro para tratar a solicitação, que é DNS Principal. Então, aqui vamos verificar o fluxo da consulta DNS e ver qual servidor respondeu a essa consulta usando logs de sub-rede do OCI.
1. Clique no log.
2. A solicitação foi do Ponto Final de Encaminhamento (10.2.0.6), que é colocado na mesma sub-rede que BE-VM para o endereço IP NLB (10.0.0.110) na DNS-VCN.
3. Em seguida, no NLB (10.0.0.110), a solicitação é enviada para o DNS Principal (10.0.0.10).
O teste teve êxito. O DNS Principal conseguiu tratar consultas de DNS no caso de o DNS Secundário estar inativo.

Cenário de Teste 4: DNS Secundário Responde a Consultas BE-VM quando o DNS Primário está Inativo

No caso de uma falha no DNS Principal, precisamos garantir que o DNS Secundário responda às consultas provenientes do BE-VM, pois o DNS-NLB está direcionando o tráfego para ele.

A imagem a seguir ilustra o cenário de teste que pretendemos alcançar.
Vamos começar fazendo shutdown da instância Primary-DNS. Clique no menu de hambúrguer (≡) no canto superior esquerdo.
1. Clique em Calcular.
2. Clique em Instâncias.
1. Marque a caixa de seleção ao lado da instância.
2. Clique em Ações.
3. Clique em Interromper.
4. Clique em Interromper.
5. A instância agora está no estado Interrompida.
Inicie a instância do DNS Secundário.
1. Marque a caixa de seleção ao lado da instância.
2. Clique em Ações.
3. Clique em Iniciar.
4. Clique em Iniciar.
5. A instância agora está no estado Em Execução.
Em seguida, acessaremos o BE-VM e realizaremos um teste executando uma consulta. Para fazer isso, usaremos o serviço OCI Bastion. Clique no menu de hambúrguer (≡) no canto superior esquerdo.
1. Clique em Identidade e Segurança.
2. Clique em Bastion.
Clique em BEBastion.
Clique em Criar sessão.
Digite as seguintes informações.
1. Tipo de sessão: Selecione Sessão SSH Gerenciada.
2. Nome da sessão: Informe um nome para a sessão.
3. Nome do Usuário: Informe o nome do usuário. Para a instância do Oracle Linux, o nome do usuário padrão é opc.
4. Instância de computação: Selecione a instância BE-VM.
5. Cole a mesma chave pública gerada no Tutorial 1: Tarefa 2.1: Gerar Par de Chaves SSH.
6. Clique em Criar sessão.

Depois que a sessão for criada, clique nos três pontos e em Copiar comando SSH.

O comando deve ter esta aparência:

ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-milan-1.amaaaaaaldij5aia73xcxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxa@host.bastion.eu-milan-1.oci.oraclecloud.com" -p 22 opc@10.2.0.5

Abra o OCI Cloud Shell.
1. Navegue até o diretório .ssh usando o comando cd .ssh.
2. Cole o comando SSH. Certifique-se de substituir <privateKey> pelo nome de arquivo da chave privada id_rsa.
3. Insira sim.
Log foi estabelecido com êxito. Agora, execute uma consulta de teste de BE-VM a fe.orastage.com usando o comando host. Verifique se a consulta foi bem-sucedida e se uma resposta foi recebida.
Sabemos que há apenas um servidor de backend íntegro para tratar a solicitação, que é DNS Secundário. Então, aqui vamos verificar o fluxo da consulta DNS e ver qual servidor respondeu a essa consulta usando logs de sub-rede do OCI.
1. Clique no log.
2. A solicitação foi do Ponto Final de Encaminhamento (10.2.0.6), que é colocado na mesma sub-rede que BE-VM para o endereço IP NLB (10.0.0.110) na DNS-VCN.
3. Em seguida, no NLB (10.0.0.110), a solicitação é enviada para o DNS Secundário (10.0.0.20).
O teste teve êxito. O DNS Secundário conseguiu tratar consultas de DNS no caso de o DNS Principal estar inativo.

Próximas Etapas

Neste tutorial, aprimoramos um DNS BIND9 cliente-servidor simples configurado na OCI integrando um Balanceador de Carga de Rede da OCI e um servidor DNS secundário para garantir a disponibilidade contínua do serviço em caso de falha do servidor principal.

Até agora, desenvolvemos uma arquitetura de DNS confiável e de alto desempenho especificamente para lidar com consultas de domínio orastage.com. No entanto, a empresa OraStage também precisa resolver nomes de domínio nativos do OCI, como oraclevcn.com e oraclecloud.com, e para isso são necessárias etapas adicionais. No próximo tutorial, Usar o OCI DNS para Resolver Domínios Nativos, demonstraremos como obter essa configuração.

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

Implement High Availability on BIND9 Domain Name System in Oracle Cloud Infrastructure

G14457-02