Note:

• This tutorial requires access to Oracle Cloud. To sign up for a free account, see Get started with Oracle Cloud Infrastructure Free Tier.
• It uses example values for Oracle Cloud Infrastructure credentials, tenancy, and compartments. When completing your lab, substitute these values with ones specific to your cloud environment.

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

Introduction

OraStage is a leading company in the energy sector, specializing in renewable energy solutions and innovative power technologies, the company announced a strategic decision to migrate its workloads to Oracle Cloud Infrastructure (OCI) to enhance performance, scalability, and security.

Taking into account the specific needs and conditions that OraStage has outlined, the company requires a hybrid Domain Name System (DNS). Solution in the cloud, and by hybrid here means to use their own Berkeley Internet Name Domain version 9 (BIND9) DNS system in addition to OCI DNS service, where the final architecture they are looking to build is shown in the following image.

OraStage DNS requirements:

• The company has several internal domains and subdomains, all of them should be resolved by their BIND9 DNS in OCI, where OraStage will manage all the related zones and records. One of these domains is orastage.com which we are going to use in this tutorial. So, any query to orastage.com must be forwarded to their BIND9.

• They still need to resolve OCI native domains (oraclevcn.com, oraclecloud.com and so on) in some cases, and this is going to be done by using OCI private DNS components: private views, forwarding endpoints and rules, and listening endpoints.

• All the queries must be inspected by a pfSense firewall instance.

• To avoid single point of failure, OraStage plan to use another DNS server and leverage OCI Load Balancer to distribute queries between primary and secondary DNS.

This tutorial series will guide you step by step to achieve the outlined requirements above, building the entire solution from scratch. You can easily navigate to each tutorial from the list below:

• Tutorial 1: Configure BIND9 DNS in OCI. Learn how to install and configure BIND9 on a compute instance, making it the local DNS server for two test environments in OCI. These environments will consist of “Frontend” and “Backend” servers, each hosted in a separate spoke network. The BIND9 server will handle all DNS queries directed to orastage.com.

• Tutorial 2: Implement High Availability on BIND9 DNS scenario in OCI. This tutorial focuses on adding a secondary BIND9 server and configuring a Network Load Balancer (NLB) to distribute DNS traffic between both servers. DNS queries to orastage.com will be directed to the NLB IP, which will balance the load between the primary and secondary BIND9 servers. If one server becomes unavailable, DNS resolution will continue without service interruption.

• Tutorial 3: Use OCI DNS to resolve native domains. Focusing only on a specific use case, where we utilize native DNS components in OCI, in case there is a need to resolve native domains such as oraclevcn.com and oraclecloud.com. BIND9 DNS is not used in this tutorial.

• Tutorial 4: Adding security to the DNS architecture using pfSense Firewall. Focusing on installing a pfSense Firewall in the hub VCN in OCI, and do the required network configuration to route all East-West traffic including DNS queries (done in the past tutorials) through the firewall to be inspected.

Overview

Today a reliable and efficient DNS infrastructure is crucial for ensuring seamless network operations. In the first tutorial: Configure BIND9 Domain Name System in Oracle Cloud Infrastructure, we already explained how BIND9, one of the most widely used DNS software, that provides robust features and flexibility to manage DNS services, can be deployed and used in OCI. While a single BIND9 server can handle DNS requests effectively, adding a second BIND9 server offers numerous advantages that enhance the overall performance and reliability of your network.

This tutorial will guide you through the process of setting up a secondary BIND9 server and a load balancer in OCI, highlighting the benefits of this configuration. By implementing this, you will achieve:

• Redundancy: Ensuring continuous availability of DNS services, even if the primary server fails.

• Load Balancing: Distributing DNS query load between servers, improving response times and reducing the risk of overload.

• Geographical Distribution: If needed, placing DNS servers in different locations can provide faster response times for global users.

• Enhanced Security: Mitigating risks by separating and securing DNS services across multiple servers.

OCI Network Load Balancer

An OCI Flexible Network Load Balancer (NLB) is a service that helps distribute incoming traffic across multiple backend resources. This is particularly useful for managing high traffic volumes and ensuring that applications remain available and responsive even if one or more servers fail.

The OCI Network Load Balancer operates at Layer 3 and Layer 4 of the Open Systems Interconnection (OSI) model, handling protocols like Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Control Message Protocol (ICMP). By balancing the load efficiently, it can enhance application performance, provide high availability, and improve the overall scalability of the system. The service also offers features such as health checks to monitor the status of backend servers, ensuring that traffic is only directed to healthy and operational instances.

In summary, an OCI Network Load Balancer plays a key role in maintaining the reliability and scalability of applications by intelligently distributing network traffic across multiple resources. Due to all of the benefits we mentioned we will add a network load balancer to our set up to optimize our DNS solution.

Objectives

• Deploy OCI Network Load Balancer and a secondary BIND9 server in OCI seamlessly integrated into your network, ensuring a robust and resilient DNS infrastructure.

• The primary objective of this tutorial is to enable FE-VM client (fe.orastage.com) to query BE-VM (be.orastage.com), and vice versa, with DNS-NLB distributing client requests between Primary-DNS (primary-dns.orastage.com) and Secondary-DNS (secondary-dns.orastage.com) to answer all the queries.

Final Architecture

Prerequisites

• Access to an OCI tenancy and permissions to manage the required network and compute services.

• Basic understanding of OCI network routing and security and their functionalities: Virtual Cloud Network (VCN), Route Table, Dynamic Routing Gateway (DRG), Security List, Bastion, and OCI Network Load Balancer.

• Basic understanding of OCI Logging service.

• Basic understanding of Ubuntu Linux and DNS in general.

• Make sure to complete the first tutorial: Configure BIND9 Domain Name System in Oracle Cloud Infrastructure, where you should have already built the following architecture.

  

Task 1: Provision Secondary-DNS Instance and Configure BIND9

Refer to the first tutorial: Configure BIND9 Domain Name System in Oracle Cloud Infrastructure, where Task 2 and Task 3 shows the creation and configuration of Primary-DNS instance, same tasks should be done to configure Secondary-DNS, consider the following information:

• The instance name will be Secondary-DNS.

• It will reside in the same subnet as the Primary-DNS, and an IP address of 10.0.0.20 must be assigned to it.

• Through the configuration process, every time Primary-DNS 10.0.0.10 is mentioned it should be replaced with Secondary-DNS 10.0.0.20, one example is the FQDN for this instance should be secondary-dns.orastage.com.

• Use the same SSH key.

• Same OCI Bastion used to access Primary-DNS can also be used to access the Secondary-DNS, but using a new session.

• In the /var/lib/bind/db.orastage.com file for both primary and secondary instances, make sure all the following records are present so both of DNS servers will be able to resolve each other in addition to FE-VM and BE-VM instances.

  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
  

At the end of this task, the architecture should look like this:

Task 2: Configure an OCI Network Load Balancer

Task 2.1: Add Details

• Click the hamburger menu (≡) from the upper left corner.

  

  1. Click Networking.
  2. Click Network load balancer.

  

• Click Create network load balancer.

  

  1. Load balancer name: Enter a name.
  2. Choose visibility type: Select Private.
  3. Choose networking: Select DNS-VCN and its private subnet, where we are going to place the network load balancer.
  4. Click Next.

  

  

Task 2.2: Configure a Listener

A listener is an essential component in a load balancer that is responsible for receiving specific type of traffic with certain ports (for example, TCP/port 80, UDP/port 21) and direct it to backend servers. In this tutorial, we want the listener to listen on port 53 (TCP) and (UDP), as DNS use both of them.

• Enter the following information.

  1. Listener name: Enter a name.
  2. Specify the type of traffic your listener handles: Select UDP/TCP.
  3. Specify the port: Enter the port number 53.
  4. Click Next.

  

Task 2.3: Choose a Backend Set

A backend set is a logical grouping of backend servers that the network load balancer routes traffic to. Our backend servers here will be Primary-DNS and Secondary-DNS.

• Enter the following information.

  1. Backend set name: Enter a backend set name.
  2. Click Add backends.
  3. Backend type: Select Compute instances.
  4. Backend IPv4 compute instances: Choose both of the DNS servers: Primary-DNS and Secondary-DNS.
  5. Click Add backends.
  6. You can see the backend servers are added to the set.
  7. Specify health check policy: A health check policy is used to verify the availability of backend servers by making requests or attempting connections. The network load balancer performs these health checks at specified regular intervals, using this policy to continuously monitor the status of the backend servers.
  8. Click Next.

  

  

  

  

Task 2.4: Review and Create

• Review all details and click Create network load balancer.

  

• DNS-NLB is created, take note of the private IP address as we will use it in Task 3.

  

Task 2.5: Add a Security Rule

To avoid the failure of the health check and to ensure smooth communication without any traffic disruption.

• Add the following rules in the DNS-Private-Subnet security list, this allows DNS traffic sent from the network load balancer to its backends.

  

• The architecture should look as shown in the following image.

  

Task 3: Configure OCI DNS Forwarding Rules

Task 3.1: Configure Frontend-VCN Forwarding Rule

• Click the hamburger menu (≡) from the upper left corner.

  

  1. Click Networking.
  2. Click Virtual cloud networks.

  

• Click Frontend-VCN.

  

• Click DNS Resolver of the VCN.

  

• Scroll down

  1. Click Rules.
  2. Click Manage rules.
  3. Change the Destination IP address from the Primary-DNS IP address to the DNS-NLB IP address (10.0.0.110) created in Task 2.
  4. Click Save changes.
  5. Destination IP address is changed successfully. So now all queries from FE-VM will be forwarded to the DNS-NLB IP address, which will distribute them between primary and secondary DNS servers.

  

  

  

Task 3.2: Configure Backend-VCN Forwarding Rule

• Click the hamburger menu (≡) from the upper left corner.

  

  1. Click Networking.
  2. Click Virtual cloud networks.

  

• Click Backend-VCN.

  

• Click DNS Resolver of the VCN.

  

• Scroll down.

  1. Click Rules.
  2. Click Manage rules.
  3. Change the Destination IP address from the Primary-DNS IP address to the DNS-NLB IP address (10.0.0.110) created in Task 2.
  4. Click Save changes.
  5. Destination IP address is changed successfully. So now all queries from BE-VM will be forwarded to the DNS-NLB IP address, which will distribute them between primary and secondary DNS servers.

  

  

  

Task 4: Test and Validate

Prerequisite

• Enable Logs: To verify the flow of traffic, we will enable subnet flow logs, that allows us to monitor and track network traffic entering or leaving a specific subnet. These logs capture details about the network traffic, such as source and destination IP addresses, port numbers, and the amount of data being transmitted. To enable log, follow the steps:

  1. Go to the DNS-VCN private subnet, where Primary-DNS, Secondary-DNS, and DNS-NLB reside in.
  2. Click Logs.
  3. Select Enable Log.

  

  For more information about logs and how to utilize them in OCI, see

  • VCN Flow Logs.
  • Details for VCN Flow Logs - Learn how to read the contents of the log.
  • Follow the Packets in a Hub and Spoke VCN Routing Architecture inside OCI - A useful tutorial to know how to trace network packets in an OCI environment by using multiple methods, such as firewall packet capture, subnet logs, and TCPdump. Follow Task 6 and Task 13.
    • Task 6: Enable Logging (All Logs) on the Spoke A Private Subnet.
    • Task 13: Look at all the Logging Points and Packet Captures and Follow the Path - Logging Point B.

Now all the ingress and egress traffic for this subnet will be logged.

Test Scenario 1: Primary-DNS Responds to FE-VM Queries when Secondary-DNS is Down

In the event of a failure in the Secondary-DNS, we need to ensure that the Primary-DNS responds to queries coming from FE-VM, since the DNS-NLB is directing traffic to it.

• The following image illustrates the testing scenario we aim to achieve.

  

• Currently, all instances are up and running. Let us start by shutting down the Secondary-DNS instance. Click the hamburger menu (≡) from the upper left corner.

  

  1. Click Compute.
  2. Click Instances.

  

  1. Select the checkbox next to the instance.
  2. Click Actions.
  3. Click Stop.
  4. Click Stop.
  5. The instance is now in the Stopped state.

  

  

  

• Access FE-VM and conduct a test by running a query. To do this, we will use the OCI Bastion service. Click the hamburger menu (≡) from the upper left corner.

  

  1. Click Identity & Security.
  2. Click Bastion.

  

• Click FEBastion.

  

• Click Create session.

  

• Enter the following information.

  1. Session type: Select Managed SSH session.
  2. Session name: Enter a name for the session.
  3. Username: Enter the username. For Oracle Linux instance, the default username is opc.
  4. Compute instance: Select the FE-VM instance.
  5. Paste the same public key generated in Tutorial 1: Task 2.1: Generate SSH Key Pair.
  6. Click Create session.

  

  

• After the session is created, click the three dots and Copy SSH command.

  

  The command should look like this:

  ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-mi[e-mail]" -p 22 opc@10.1.0.5
  

• Open OCI Cloud Shell.

  1. Navigate to the .ssh directory using the cd .ssh command.
  2. Paste the SSH command. Make sure to replace <privateKey> with the private key filename id_rsa.
  3. Enter yes.

  

• Logged in successfully. Now, perform a test query from FE-VM to be.orastage.com using the host command. Verify that the query is successful and a response is received.

  

• We know that there is only one healthy backend server to handle the request, which is Primary-DNS. So here we are going to verify the flow of the DNS query and see which server responded to that query using OCI subnet logs.

  1. Click the log.
  2. The request went from the Forwarding Endpoint (10.1.0.6) which is placed in the same subnet as FE-VM to the NLB IP address (10.0.0.110) in the DNS-VCN.
  3. Then from the NLB IP address (10.0.0.110), the request is sent to Primary-DNS (10.0.0.10).

  

  

  Test is successful. Primary-DNS was able to handle DNS queries in case of Secondary-DNS was down.

Test Scenario 2: Secondary-DNS Responds to FE-VM Queries when Primary-DNS is Down

In the event of a failure in the Primary-DNS, we need to ensure that the Secondary-DNS responds to queries coming from FE-VM, since the DNS-NLB is directing traffic to it.

• The following image illustrates the testing scenario we aim to achieve.

  

• Let us start by shutting down the Primary-DNS instance. Click the hamburger menu (≡) from the upper left corner.

  

  1. Click Compute.
  2. Click Instances.

  

  1. Select the checkbox next to the instance.
  2. Click Actions.
  3. Click Stop.
  4. Click Stop.
  5. The instance is now in the Stopped state.

  

  

  

• Start the Secondary-DNS instance.

  1. Select the checkbox next to the instance.
  2. Click Actions.
  3. Click Start.
  4. Click Start.
  5. The instance is now in the Running state.

  

  

  

• Next, we will access FE-VM and conduct a test by running a query. To do this, we will use the OCI Bastion service. Click the hamburger menu (≡) from the upper left corner.

  

  1. Click Identity & Security.
  2. Click Bastion.

  

• Click FEBastion.

  

• Click Create session.

  

• Enter the following information.

  1. Session type: Select Managed SSH session.
  2. Session name: Enter a name for the session.
  3. Username: Enter the username. For Oracle Linux instance, the default username is opc.
  4. Compute instance: Select the FE-VM instance.
  5. Paste the same public key generated in Tutorial 1: Task 2.1: Generate SSH Key Pair.
  6. Click Create session.

  

  

• After the session is created, click the three dots and Copy SSH command.

  

  The command should look like this:

  ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-milan-[e-mail]" -p 22 opc@10.1.0.5
  

• Open OCI Cloud Shell.

  1. Navigate to the .ssh directory using the cd .ssh command.
  2. Paste the SSH command. Make sure to replace <privateKey> with the private key filename id_rsa.
  3. Enter yes.

  

• Logged in successfully. Now, perform a test query from FE-VM to be.orastage.com using the host command. Verify that the query is successful and a response is received.

  

• We know that there is only one healthy backend server to handle the request, which is Secondary-DNS. So here we are going to verify the flow of the DNS query and see which server responded to that query using OCI subnet logs.

  1. Click the log.
  2. The request went from the Forwarding Endpoint (10.1.0.6) which is placed in the same subnet as FE-VM to the NLB IP address (10.0.0.110) in the DNS-VCN.
  3. Then from the NLB (10.0.0.110) the request is sent to Secondary-DNS (10.0.0.20).

  

  

  Test is successful. Secondary-DNS is able to handle DNS queries in case the Primary-DNS is down.

Test Scenario 3: Primary-DNS Responds to BE-VM Queries when Secondary-DNS is Down

In the event of a failure in the Secondary-DNS, we need to ensure that the Primary-DNS responds to queries coming from BE-VM, since the DNS-NLB is directing traffic to it.

• The following image illustrates the testing scenario we aim to achieve.

  

• Currently, all instances are up and running. Let us start by shutting down the Secondary-DNS instance. Click the hamburger menu (≡) from the upper left corner.

  

  1. Click Compute.
  2. Click Instances.

  

  1. Select the checkbox next to the instance.
  2. Click Actions.
  3. Click Stop.
  4. Click Stop.
  5. The instance is now in the Stopped state.

  

  

  

• Next, we will access BE-VM and conduct a test by running a query. To do this, we will use the OCI Bastion service. Click the hamburger menu (≡) from the upper left corner.

  

  1. Click Identity & Security.
  2. Click Bastion.

  

• Click BEBastion.

  

• Click Create session.

  

• Enter the following information.

  1. Session type: Select Managed SSH session.
  2. Session name: Enter a name for the session.
  3. Username: Enter the username. For Oracle Linux instance, the default username is opc.
  4. Compute instance: Select the BE-VM instance.
  5. Paste the same public key generated in Tutorial 1: Task 2.1: Generate SSH Key Pair.
  6. Click Create session.

  

  

• After the session is created, click the three dots and Copy SSH command.

  

  The command should look like this:

  ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-milan-[e-mail]" -p 22 opc@10.2.0.5
  

• Open OCI Cloud Shell.

  1. Navigate to the .ssh directory using the cd .ssh command.
  2. Paste the SSH command. Make sure to replace <privateKey> with the private key filename id_rsa.
  3. Enter yes.

  

• Logged in successfully. Now, perform a test query from BE-VM to fe.orastage.com using the host command. Verify that the query is successful and a response is received.

  

• We know that there is only one healthy backend server to handle the request, which is Primary-DNS. So here we are going to verify the flow of the DNS query and see which server responded to that query using OCI subnet logs.

  1. Click the log.
  2. The request went from the Forwarding Endpoint (10.2.0.6) which is placed in the same subnet as BE-VM to the NLB IP address (10.0.0.110) in the DNS-VCN.
  3. Then from the NLB (10.0.0.110), the request is sent to Primary-DNS (10.0.0.10).

  

  

  Test is successful. Primary-DNS was able to handle DNS queries in case of Secondary-DNS was down.

Test Scenario 4: Secondary-DNS Responds to BE-VM Queries when Primary-DNS is Down

In the event of a failure in the Primary-DNS, we need to ensure that the Secondary-DNS responds to queries coming from BE-VM, since the DNS-NLB is directing traffic to it.

• The following image illustrates the testing scenario we aim to achieve.

  

• Let us start by shutting down the Primary-DNS instance. Click the hamburger menu (≡) from the upper left corner.

  

  1. Click Compute.
  2. Click Instances.

  

  1. Select the checkbox next to the instance.
  2. Click Actions.
  3. Click Stop.
  4. Click Stop.
  5. The instance is now in the Stopped state.

  

  

  

• Start the Secondary-DNS instance.

  1. Select the checkbox next to the instance.
  2. Click Actions.
  3. Click Start.
  4. Click Start.
  5. The instance is now in the Running state.

  

  

  

• Next, we will access BE-VM and conduct a test by running a query. To do this, we will use the OCI Bastion service. Click the hamburger menu (≡) from the upper left corner.

  

  1. Click Identity & Security.
  2. Click Bastion.

  

• Click BEBastion.

  

• Click Create session.

  

• Enter the following information.

  1. Session type: Select Managed SSH session.
  2. Session name: Enter a name for the session.
  3. Username: Enter the username. For Oracle Linux instance, the default username is opc.
  4. Compute instance: Select the BE-VM instance.
  5. Paste the same public key generated in Tutorial 1: Task 2.1: Generate SSH Key Pair.
  6. Click Create session.

  

  

• After the session is created, click the three dots and Copy SSH command.

  

  The command should look like this:

  ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.e[e-mail]" -p 22 opc@10.2.0.5
  

• Open OCI Cloud Shell.

  1. Navigate to the .ssh directory using the cd .ssh command.
  2. Paste the SSH command. Make sure to replace <privateKey> with the private key filename id_rsa.
  3. Enter yes.

  

• Logged in successfully. Now, perform a test query from BE-VM to fe.orastage.com using the host command. Verify that the query is successful and a response is received.

  

• We know that there is only one healthy backend server to handle the request, which is Secondary-DNS. So here we are going to verify the flow of the DNS query and see which server responded to that query using OCI subnet logs.

  1. Click the log.
  2. The request went from the Forwarding Endpoint (10.2.0.6) which is placed in the same subnet as BE-VM to the NLB IP address (10.0.0.110) in the DNS-VCN.
  3. Then from the NLB (10.0.0.110) the request is sent to Secondary-DNS (10.0.0.20).

  

  

  Test is successful. Secondary-DNS was able to handle DNS queries in case of Primary-DNS was down.

Next Steps

In this tutorial, we enhanced a simple client-server BIND9 DNS set up in OCI by integrating an OCI Network Load Balancer and a secondary DNS server to ensure continuous service availability in the event of a primary server failure.

So far, we have developed a high-performance and reliable DNS architecture specifically for handling orastage.com domain queries. However, OraStage company has a requirement to also resolve OCI native domain names, such as oraclevcn.com and oraclecloud.com, and for that, additional steps are necessary. In the next tutorial, Use OCI DNS to Resolve Native Domains, we will demonstrate how to achieve this configuration.

Acknowledgments

• Author - Anas abdallah (Cloud Networking Specialist)

More Learning Resources

Explore other labs on docs.oracle.com/learn or access more free learning content on the Oracle Learning YouTube channel. Additionally, visit education.oracle.com/learning-explorer to become an Oracle Learning Explorer.

For product documentation, visit Oracle Help Center.

---

Title and Copyright Information

<

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

G14433-02

Copyright ©2025, Oracle and/or its affiliates.