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.

Configure 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 of BIND9

BIND9 (Berkeley Internet Name Domain version 9) is one of the most widely used and mature DNS (Domain Name System) server software packages in the world. It is developed and maintained by the Internet Systems Consortium (ISC). BIND9 serves as the backbone for much of the Internet’s DNS infrastructure, providing robust and reliable DNS services for both small and large-scale deployments.

BIND9 flexibility, robustness, and extensive feature set make it suitable for a wide range of DNS applications, from small internal networks to the largest public DNS services on the Internet.

Key Features of BIND9

DNS Protocol Support: Supports all major DNS features and protocols, including IPv4 and IPv6, DNSSEC (DNS Security Extensions), and TSIG (Transaction SIGnature).
DNSSEC (DNS Security Extensions): Provides advanced security features to protect DNS data integrity and authenticity, preventing attacks such as cache poisoning and spoofing.
Scalability and Performance: Suitable for small to very large DNS deployments, with capabilities to handle high query loads and large zones efficiently.
Flexibility and Customization:
- Highly configurable with extensive options for fine-tuning DNS behavior, zone management, and query processing.
- Supports various types of zones, including master (primary), slave (secondary), and stub zones.
Dynamic DNS: Supports Dynamic DNS (DDNS), allowing for real-time updates to DNS records without restarting the server.
Access Control and Security:
- Implements access control lists (ACLs) for restricting access to DNS services and managing who can query or update zones.
- Supports views to provide different answers to DNS queries based on the source of the query.
Logging and Monitoring:
- Extensive logging capabilities for tracking queries, updates, and server performance.
- Integration with monitoring tools to ensure high availability and quick troubleshooting.
Caching: Provides robust caching mechanisms to improve performance and reduce the load on authoritative DNS servers by caching DNS responses.
Zone Transfers: Supports secure zone transfers between DNS servers using AXFR (full zone transfer) and IXFR (incremental zone transfer).

Common Use Cases of BIND9

Authoritative DNS Server: Hosts DNS records for domains, providing authoritative responses to DNS queries.
Recursive DNS Server: Resolves DNS queries for clients by recursively querying other DNS servers.
Forwarding DNS Server: Forwards DNS queries to other DNS servers, often used in conjunction with caching.
Secondary (Slave) DNS Server: Maintains copies of zone data from a primary server, providing redundancy and load balancing.

Installation and Configuration of BIND9

Installation: BIND9 can be installed on various operating systems, including Linux, UNIX, and Windows. It is available through package managers on most Linux distributions or can be compiled from a source.
Configuration: The main configuration file is named.conf, where administrators define zones, access controls, logging options, and other settings. Zone files contain the actual DNS records for each domain.

Use BIND9 on OCI

There are several reasons why some customers might choose to use and manage their own DNS (such as BIND9) instead of using Oracle Cloud Infrastructure (OCI) managed DNS services:

Customization and Flexibility:
- Advanced Configurations: Custom DNS solutions like BIND9 offer extensive configurability, allowing customers to tailor their DNS settings to meet specific requirements that may not be supported by managed services.
- Specialized Features: Some organizations need advanced features such as specific query logging, detailed access control, or custom DNS records that managed services may not provide.
Cost Considerations:
- Cost Management: Self-managed DNS can be more cost-effective, especially for organizations with significant DNS traffic, as they can avoid variable costs associated with managed services.
- Predictable Expenses: Operating their own DNS servers can result in more predictable costs, as they only need to manage the infrastructure costs rather than pay for managed DNS usage.
Control and Security:
- Full Control: Organizations might prefer having complete control over their DNS infrastructure, including the ability to implement custom security policies, detailed logging, and fine-grained access controls.
- Data Privacy: For highly sensitive or regulated environments, keeping DNS traffic internal to their own network can be a security requirement to ensure data privacy and compliance with regulations.
Performance and Reliability:
- Performance Optimization: Self-managed DNS allows organizations to optimize performance by configuring caching, load balancing, and geolocation-specific DNS responses tailored to their needs.
- Reliability: By managing their own DNS servers, organizations can implement high-availability configurations and redundancy measures that align with their specific reliability requirements.
Integration with Existing Infrastructure:
- Legacy Systems: Organizations with legacy systems might have existing DNS infrastructure that is deeply integrated with their other systems and processes, making it easier to continue managing their own DNS.
- Custom Integrations: Self-managed DNS allows for seamless integration with other custom or third-party applications that require specific DNS configurations or interactions.
Regulatory and Compliance Requirements:
- Compliance Needs: Some industries have stringent regulatory requirements that necessitate control over all aspects of their IT infrastructure, including DNS, to comply with legal and compliance standards.
Learning and Expertise:
- Skill Development: Some organizations prefer to maintain in-house expertise and knowledge about DNS management, which can be valuable for troubleshooting and optimizing their overall IT infrastructure.
Vendor Lock-in Avoidance:
- Avoiding Lock-in: By managing their own DNS, organizations can avoid being locked into a specific vendor’s ecosystem, giving them more flexibility to switch providers or migrate workloads without significant reconfiguration.

While OCI managed DNS services offer ease of use, scalability, and reduced management overhead, these factors highlight why some organizations might opt to manage their own DNS infrastructure.

Goals for Setting Up BIND9 in OCI

Introduction to BIND9 and OCI
- Understand what BIND9 is and its role in DNS management.
- Gain an overview of Oracle Cloud Infrastructure (OCI) and its key components relevant to this setup.
Prerequisites and Initial Setup
- Identify and gather necessary prerequisites for the setup.
- Set up an OCI instance (Virtual Machine) for hosting the BIND9 server.
Configuring the OCI Environment
- Configure the basic network settings in OCI, and that is with route rules and gateways to establish an appropriate communication between all the related servers and clients, and security lists to allow DNS traffic.
Installing BIND9 on the OCI Instance
- Access the OCI instance via SSH.
- Install necessary packages and dependencies for BIND9.
Configuring BIND9
- Configure the main BIND9 configuration files (named.conf).
- Set up zone files for forward DNS lookups.
Starting and Managing the BIND9 Service
- Start the BIND9 service and configure it to start on boot.
- Verify that the BIND9 service is running properly.
Testing the DNS Server
- Use command-line tools (e.g., dig, host) to test the DNS resolution.
- Ensure that forward lookups are correctly configured and operational.
Securing the BIND9 Server
- Implement best practices for securing the BIND9 server, including access controls.
Conclusion and Additional Resources
- Summarize what is done.
- Provide additional resources and references for further learning.

Objectives

By the end of this tutorial, you will have a functional BIND9 DNS server running on Oracle Cloud Infrastructure (OCI). You will understand the basics of DNS and how BIND9 operates, enabling you to configure, manage, and secure a BIND9 server in a cloud environment. Additionally, you will be equipped with the knowledge to troubleshoot and maintain your BIND9 DNS setup in OCI. This tutorial will also help you increase your skills in operating various OCI components within networking and compute services.
The primary objective of this tutorial is to enable FE-VM (fe.orastage.com) to query BE-VM (be.orastage.com), and vice versa, with Primary-DNS (primary-dns.orastage.com) acting as the authoritative DNS server.

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, and Bastion.
Basic understanding of Ubuntu Linux and DNS in general.
Three Virtual Cloud Networks (VCNs) are required with one private subnet in each.
- DNS-VCN: This will host the primary DNS server. In addition to a secondary DNS and a network load balancer.
- Frontend-VCN: This will host one of the clients. In addition to an OCI DNS forwarder.
- Backend-VCN: This will host the other client. In addition to an OCI DNS forwarder.

Task 1: Set up Routing and Security Network Components

Task 1.1: Create VCNs

Make sure you have the following VCNs are already created.
- DNS-VCN (10.0.0.0/16) containing DNS-Private-Subnet (10.0.0.0/24).
- Frontend-VCN (10.1.0.0/16) containing FE-Private-Subnet (10.1.0.0/24).
- Backend-VCN (10.2.0.0/16) containing BE-Private-Subnet (10.2.0.0/24).
Click the hamburger menu (≡) from the upper left corner.
1. Click Networking.
2. Click Virtual cloud networks.
We can see the VCNs in place, each VCN has only one private subnet, and the default route table and security list attached to it.

Task 1.2: Create a Dynamic Routing Gateway (DRG)

DRG is a virtual router that provides a path for private traffic from one VCN to another, or between a VCN and an on-premises network, or even a VCN with other cloud environment networks. So, it is a powerful and critical component for every OCI network environment. In this tutorial, we are going to use it to establish connectivity between multiple VCNs in the same region.

Click the hamburger menu (≡) from the upper left corner.
1. Click Networking.
2. Click Dynamic routing gateway.
Click Create dynamic routing gateway.
1. Enter a Name for DRG.
2. Click Create dynamic routing gateway.
DRG is created successfully.

Task 1.3: Attach VCNs to the DRG

In the DRG details page, create virtual cloud network attachments. To create, click Create virtual cloud network attachment.
- DNS-VCN attachment:
- Frontend-VCN attachment:
- Backend-VCN attachment:
All VCNs are attached successfully. By default, these attachments will use the autogenerated DRG route table which lets each attachment dynamically learn the routes to other VCNs.
All VCNs should be able to connect to each other. So, we have to facilitate communication between them using some route and security rules. In Task 1.4, Task 1.5, and Task 1.6, we will:
- Allow SSH access so we can log in to the instances.
- Allow DNS traffic where it is needed.
- Ping traffic to be allowed where it is needed.
- Provide egress Internet access where it is needed.
- Ensure every compute instance should be able to reach the other through DRG.

Task 1.4: Configure Routing and Security for DNS-VCN

This must be done on the subnet level. Navigate to the VCNs page and click DNS-VCN.
Click the private subnet.
Click Route Table which is an assigned route table.
Make sure to add the following rules.
- 0.0.0.0/0 - NAT Gateway: To have unidirectional access to the Internet, to install packages/patches if needed. In this tutorial, we need this access to install the BIND9 package on the Primary-DNS server.
- 10.1.0.0/16 - DRG: Route traffic destined to Frontend-VCN to the DRG.
- 10.2.0.0/16 - DRG: Route traffic destined to Backend-VCN to the DRG.
If a NAT gateway is not created, follow the steps to create one before adding the route rule in the above step.
1. Go to DNS-VCN details page and click NAT Gateways.
2. Click Create NAT Gateway.
Enter the following information.
1. Enter a Name for a NAT gateway.
2. Select Ephemeral Public IP Address.
3. Click Create NAT Gateway.
NAT gateway is successfully created.
As we have finished the routing part for DNS-VCN subnet, let us do the security now. Go to the Subnet Details page and click the assigned security list.
Make sure to allow ingress traffic.
- SSH traffic from anywhere (port 22).
- DNS traffic from Frontend-VCN and Backend-VCN (TCP/port 53 and UDP/port 53).
Make sure to allow all the egress traffic.

Task 1.5: Configure Routing and Security for Frontend-VCN

This must be done on the subnet level. Navigate to the VCNs page and click Frontend-VCN.
Click the private subnet.
Click Route Table which is an assigned route table.
Make sure to add the following rules.
- 0.0.0.0/0 - NAT Gateway: To have unidirectional access to the Internet, we need it here for the FE-VM** to be able to use OCI Bastion service, using service gateway instead can do the job too.
- 10.0.0.0/16 - DRG: Route traffic destined to DNS-VCN to the DRG.
- 10.2.0.0/16 - DRG: Route traffic destined to Backend-VCN to the DRG.
If a NAT gateway is not created, follow the steps from Task 1.4 to create one before adding the route rule in the above step.
As we have finished the routing part for Frontend-VCN, let us do the security now. Go to the Subnet Details page and click the assigned security list.
Make sure to allow ingress traffic.
- SSH traffic from anywhere (port 22).
- Ping traffic from Backend-VCN (ICMP, type 8), we will need this rule at the test phase.
Make sure to allow all the egress traffic.

Task 1.6: Configure Routing and Security for Backend-VCN

This must be done on the subnet level. Navigate to the VCNs page and click Backend-VCN.
Click the private subnet.
Click Route Table which is an assigned route table.
Make sure to add the following rules.
- 0.0.0.0/0 - NAT Gateway: To have unidirectional access to the Internet, we need it here for the BE-VM to be able to use OCI Bastion service, using service gateway instead can do the job too.
- 10.0.0.0/16 - DRG: Route traffic destined to DNS-VCN to the DRG.
- 10.1.0.0/16 - DRG: Route traffic destined to Frontend-VCN to the DRG.
If a NAT gateway is not created, follow the steps from Task 1.4 to create one before adding the route rule in the above step.
As we have finished the routing part for Backend-VCN, let’s do the security now. Go to the Subnet Details page and click the assigned security list.
Make sure to allow Ingress traffic.
- SSH traffic from anywhere (port 22).
- Ping traffic from Frontend-VCN (ICMP, type 8), we will need this rule at the test phase.
Make sure to allow all the egress traffic.
Basic network components are now ready (VCNs, Subnets, Route Tables, DRG and security Lists). Now, the architecture should look as shown in the following image.

Task 2: Provision an OCI Compute Instance

Provision a compute instance where BIND9 will be configured.

Task 2.1: Generate SSH Key Pair

This must be done before creating the instance. SSH keys will be used to authenticate to Linux compute instances. You can generate the keys either using PuTTYgen tool on a Windows machine, or ssh-keygen utility on any machine. In this tutorial, we are going to use ssh-keygen in OCI Cloud Shell.

Click Cloud Shell.
Run the ssh-keygen command to generate a key pair.
Navigate to the default .ssh directory using the cd .ssh command and copy the content of the public key file id_rsa.pub, we will use this in Task 2.2.

Task 2.2: Provision Primary-DNS Compute Instance

Click the hamburger menu (≡) from the upper left corner.
1. Click Compute.
2. Click Instances.
Click Create instance.
Enter a Name for the instance.
Select Ubuntu 20.04 as the Operating System of the instance.
In Primary network, enter the following information.
1. Select DNS-VCN.
2. Select a private subnet.
Assign the instance a private IP address 10.0.0.10.
Paste the public key generated in Task 2.1.
Scroll down to the end of the page and click Show advanced options.
Click Oracle Cloud Agent.
1. Select Bastion plugin, as we will use Bastion later on to access the instance.
2. Click Create.
The Primary-DNS compute instance is created successfully.
The architecture should look as shown in the following image.

In the later tasks, we will install and configure BIND9 in the Primary-DNS instance.

Task 3: Install and Configure BIND9

Task 3.1: Access Primary-DNS Compute Instance using Bastion

First of all, we need to establish access via SSH to the compute instance to install and configure BIND9. However, as we created the instance in a private subnet, so we cannot access it directly from anywhere as it does not have a public IP, and for that we will make use of another OCI service.

OCI Bastion is a managed service that acts as an intermediary, allowing secure access to resources within a private network. It is particularly useful for administrative use that requires access to resources that are not exposed to the public internet, you can think of it as Jump Server as a service.
1. Click Identity & Security.
2. Click Bastion.
Click Create bastion.
Enter the following information.
1. Enter a Bastion name.
2. Select the VCN (DNS-VCN) and its subnet.
3. CIDR block allowlist is the allowed range of IPs that we should connect from to the Bastion, here we used 0.0.0.0/0 for this implementation, we can be more specific if we want by choosing the public IP address we are connecting from.
4. Click Create bastion.
Bastion is created. We have to create a session that lets us connect to a target resource (Primary-DNS) for a specific amount of time (Default is 3 hours).
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 Ubuntu Linux instance, the default username is ubuntu.
4. Compute instance: Select the Primary-DNS instance created in Task 2.2.
5. Paste the same public key we generated in Task 2.1.
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-1.amaaaaaaldij5aiaa6buxxxxxxxxxxxxxxxxxxrlnywmo3n2pty5wpf7fq@host.bastion.eu-milan-1.oci.oraclecloud.com" -p 22 ubuntu@10.0.0.10

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.
Logged in successfully.

Task 3.2: Install BIND9

After accessing the instance, we will install BIND9 and make sure it is up and running.

Run the following commands.

sudo apt update
sudo apt install bind9 bind9utils bind9-doc bind9-host

Run the sudo systemctl status named command to check BIND9 service status. It is active (running).
Run sudo systemctl enable named command to enable the service so it will start automatically after reboot.

Task 3.3: Change the Fully Qualified Domain Name (FQDN) of the Instance

To change the FQDN of the instance, access the hosts file with the sudo vi /etc/hosts command and add the following line.
```
10.0.0.10    primary-dns.orastage.com    primary-dns
```
To verify the change, run the hostname -f command to see the new FQDN.

Task 3.4: Configure the `named.conf.options` File

Add the configuration.

Add the following lines at the end of the /etc/bind/named.conf.options file and save the file.

recursion yes;
notify yes;
allow-query { any; };
allow-query-cache { any; };
allow-recursion { any; };
forwarders { 8.8.8.8; };
auth-nxdomain no; # conform to RFC1035
listen-on { localhost; any; };
allow-transfer { any; };

Restart the BIND9 service.
Check the service status.

Task 3. 5: Use `netstat` to display TCP/UDP Ports Status

net-tools is a package of command-line utilities that provide a collection of essential networking tools for Linux OS.

Run the sudo apt install net-tools command to install net-tools. This is needed to be able to use the netstat command.
Run the sudo netstat -antu command to check the ports/protocols that the instance is listening to. As you can see in the following image, for the IP 10.0.0.10, TCP/port 53 and UDP/port 53 should be opened.

Task 3.6: Configure the `named.conf.local` File

Add the following lines to the end of the /etc/bind/named.conf.local file.

zone "orastage.com" {
type master;
allow-transfer { any; };
file "/var/lib/bind/db.orastage.com";
};

Task 3.7: Configure the `db.orastage.com` File

The db.orastage.com file does not exist yet. To create, run the sudo vi /var/lib/bind/db.orastage.com command and add the following content to the file.

$TTL 1D
@                           IN SOA  primary-dns.orastage.com. admin.orastage.com. (
                              329        ; serial
                              604800     ; refresh (1 week)
                              86400      ; retry (1 day)
                              2419200    ; expire (4 weeks)
                              604800     ; minimum (1 week)
                              )

                           IN  NS      primary-dns.orastage.com.

primary-dns                 IN  A       10.0.0.10
fe                          IN  A       10.1.0.5
be                          IN  A       10.2.0.5

Task 3.8: Configure the `50-cloud-init.yaml` File

Access the /etc/netplan/50-cloud-init.yaml file and add the following lines.
```
nameservers:
addresses: [10.0.0.10]
search: [orastage.com]
```
Run the sudo netplan apply command so the changes can take effect.

Task 3.9: Disable iptables Firewall

We are going to disable iptables temporarily only for this tutorial to avoid any kind of connectivity issues during the testing phase.
1. Run the sudo su command to switch to the root user.
2. To save a backup of the existing firewall rules, run the iptables-save > /root/firewall_rules.backup command.
3. Run the following command to wipe out all the rules and allow all traffic through the firewall.
```
iptables -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
```
4. After you finish Task 6, run the iptables-restore < /root/firewall_rules.backup command to restore firewall rules.
5. After wiping out the rules, we should make sure that this change will be persistent after reboot. So, run the apt install iptables-persistent command to install the package.
6. Run the iptables-save > /etc/iptables/rules.v4 command.
7. To see the iptables rules, run the iptables -L command, it should be empty.

Task 3.10: Restart BIND9

Run the following command to restart the service.
```
sudo systemctl restart named
```

Task 3.11: Test

Do multiple tests where we query the domain names we have added to the db.orastage.com file, and see if it is answering the query locally.
1. orastage.com domain: host -a orastage.com.
2. Primary-DNS domain: host -a primary-dns.orastage.com.
3. FE-VM domain: host -a fe.orastage.com.
4. BE-VM domain: host -a be.orastage.com.

Task 4: Configure OCI Forwarding Endpoints and Rules

Each OCI VCN has a default resolver that can be used to resolve hostnames in the same VCN, different VCNs, on-premises networks, or even publicly published hostnames on the Internet. In this task, we are going to use two components in the resolver to achieve our requirement of forwarding queries to the BIND9 instance Primary-DNS, which are:

Forwarding Endpoint: Allows the DNS resolver to query a remote DNS as defined in the forwarding rules.
Forwarding Rule: Used to control how DNS queries are handled when the query is not answered by the resolver’s private views. To which remote DNS server will the queries to orastage.com be forwarded to and using which forwarding endpoint?

Task 4.1: Configure Forwarding Endpoint and Rule for Frontend-VCN

Create a forwarding endpoint and rule in Frontend-VCN, to point orastage.com queries from FE-VM to the Primary-DNS instance.

Navigate to the Frontend-VCN and click DNS Resolver.
Click Create endpoint.
Enter the following information.
1. Name: Enter a name for the endpoint.
2. Subnet: Select the private subnet of the VCN.
3. Endpoint type: Select Forwarding.
4. Forwarding IP address: Enter 10.1.0.6.
5. Click Create endpoint.
The forwarding endpoint (FWD) is created successfully.
Click Rules and Manage rules.
Enter the following information.
1. Rule condition: Select Domains.
2. Domains: Enter orastage.com domain.
3. Source endpoint: Select the forwarding endpoint.
4. Destination IP address: Enter the IP of the BIND9 instance 10.0.0.10.
The forwarding rule is created successfully.

Task 4.2: Configure Forwarding Endpoint and Rule for Backend-VCN

Create a forwarding endpoint and rule in Backend-VCN, to point orastage.com queries from BE-VM to the Primary-DNS instance.

Navigate to the Backend-VCN and click DNS Resolver.

Click Create endpoint.
Enter the following information.
1. Name: Enter a name for the endpoint.
2. Subnet: Select the private subnet of the VCN.
3. Endpoint type: Select Forwarding.
4. Forwarding IP address: Enter 10.2.0.6.
5. Click Create endpoint.
The forwarding endpoint (FWD) is created successfully.
Click Rules and Manage rules.
Enter the following information.
1. Rule condition: Select Domains.
2. Domains: Enter orastage.com domain.
3. Source endpoint: Select the forwarding endpoint.
4. Destination IP address: Enter the IP of the BIND9 instance 10.0.0.10.
The forwarding rule is created successfully.
The architecture should look as shown in the following image.

Task 5: Provision Client Instances to Perform DNS Queries

Task 5.1: Create `FE-VM` Compute Instance

Click the hamburger menu (≡) from the upper left corner.
1. Click Compute.
2. Click Instances.
Click Create instance.
Enter a Name for instance.
Select Oracle Linux 8 as the Operating System of the instance.
In Primary network, enter the following information.
1. Select Frontend-VCN.
2. Select the private subnet.
Assign the instance a private IP address 10.1.0.5.
Paste the public key generated in Task 2.1.
Scroll down to the end of the page and click Show advanced options.
Click Oracle Cloud Agent.
Select Bastion plugin, as we will use Bastion to access the instance and click Create.
The FE-VM compute instance is created successfully.

Task 5.2: Create `BE-VM` Compute Instance

Click Instance and Create instance.
Enter a Name for the instance.
Select Oracle Linux 8 as the Operating System of the instance.
In Primary network, enter the following information.
1. Select Backend-VCN.
2. Select the private subnet.
Assign the instance a private IP address 10.2.0.5.
Paste the public key generated in Task 2.1.
Scroll down to the end of the page and click Show advanced options.
Click Oracle Cloud Agent.
Select Bastion plugin, as we will use Bastion to access the instance and click Create.
The BE-VM compute instance is created successfully.
The architecture is completed.

Note: In the later tasks, we will test multiple scenarios and validate that the setup is working as expected.

Task 6: Test and Validate

Task 6.1: Access FE-VM Compute Instance using Bastion and Test

The FE-VM client machine should be able to resolve be.orastage.com.
1. Click Identity & Security.
2. Click Bastion.
Click Create bastion.
Enter the following information.
1. Bastion name: Enter a name for bastion.
2. Configure networking: Select the VCN (Frontend-VCN) and its subnet.
3. CIDR block allowlist is the allowed range of IPs that we should connect from to the Bastion, here we have used 0.0.0.0/0 for this implementation, we can be more specific if we want by choosing the public IP address we are connecting from.
4. Click Create bastion.
Bastion is created. We have to create a session to connect to a target resource (FE-VM) for a specific amount of time (Default is 3 hours).
Enter the following information.
1. Session type: Select Managed SSH session.
2. Session name: Enter a name.
3. Username: Enter the username. For Oracle Linux instance, the default user is opc.
4. Compute instance: Select the FE-VM instance created in Task 5.
5. Paste the same public key generated in Task 2.1.
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-1.amaaaaaaldij5aiaskfyan4yj7yx3bmm57rckmvvawikppba5mxxzo2q7dka@host.bastion.eu-milan-1.oci.oraclecloud.com" -p 22 opc@10.1.0.5
```
1. Open the cloud shell, and navigate to the .ssh directory using cd .ssh command.
2. Paste the SSH command and make sure to replace <privateKey> with the private key filename id_rsa.
3. Enter yes and click Enter.
Test orastage.com queries from FE-VM to be.orastage.com. You can validate the setup using different methods.
1. Run the host command.
2. Run the ping command.
3. Run the dig command.

As shown in the above test, we can retrieve the IP address of the BE-VM domain, and the ping is working using the hostname, which means the test is successful.

Task 6.2: Access BE-VM Compute Instance using Bastion and Test

The BE-VM client machine should be able to resolve fe.orastage.com.
1. Click Identity & Security.
2. Click Bastion.
Click Create bastion.
Enter the following information.
1. Bastion name: Enter a name for bastion.
2. Configure networking: Select the VCN (Backend-VCN) and its subnet.
3. CIDR block allowlist is the allowed range of IPs that we should connect from to the Bastion, here we have used 0.0.0.0/0 for this implementation, we can be more specific if we want by choosing the public IP address we are connecting from.
4. Click Create bastion.
Bastion is created. We have to create a session to connect to a target resource (BE-VM) for a specific amount of time (Default is 3 hours).
Enter the following information.
1. Session type: Select Managed SSH session.
2. Session name: Enter a name.
3. Username: Enter the username. For Oracle Linux instance the default user is opc.
4. Compute instance: Select the BE-VM instance created in STEP 06.
5. Paste the same public key generated in Task 2.1.
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-1.amaaaaaaldij5aia73xclnp6h6i2mjnpsuer2bnz4cblejfemnr6uk7pafla@host.bastion.eu-milan-1.oci.oraclecloud.com" -p 22 opc@10.2.0.5
```
1. Open the cloud shell, and navigate to the .ssh directory using the cd .ssh command.
2. Paste the SSH command and make sure to replace <privateKey> with the private key filename id_rsa.
3. Enter yes and click Enter.

Test orastage.com queries from BE-VM to fe.orastage.com. You can validate the setup using different methods.
1. Run the host command.
2. Run the ping command.
3. Run the dig command.

As shown in the above test, we can retrieve the IP address of the FE-VM domain, and the ping is working using the hostname, which means the test is successful.

Next Steps

In this tutorial, we built a small BIND9 DNS architecture with basic components; server and client setup in Oracle Cloud Infrastructure. Throughout this segment, you gained insights into OCI network routing and security, by dealing with different components such as Route Tables, DRG, Security Lists, Bastion, and more. You also learned how to install and configure a functional BIND9 DNS in an OCI environment.

In the next tutorial: Tutorial 2: Implement High Availability on BIND9 Domain Name System in Oracle Cloud Infrastructure, we will enhance this setup by incorporating the high availability layer into our architecture, which is crucial for reducing downtime and improving the user experience.

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

Configure BIND9 Domain Name System in Oracle Cloud Infrastructure

G12896-03

Configure BIND9 Domain Name System in Oracle Cloud Infrastructure

Introduction

Overview of BIND9

Goals for Setting Up BIND9 in OCI

Objectives

Prerequisites

Task 1: Set up Routing and Security Network Components

Task 1.1: Create VCNs

Task 1.2: Create a Dynamic Routing Gateway (DRG)

Task 1.3: Attach VCNs to the DRG

Task 1.4: Configure Routing and Security for DNS-VCN

Task 1.5: Configure Routing and Security for Frontend-VCN

Task 1.6: Configure Routing and Security for Backend-VCN

Task 2: Provision an OCI Compute Instance

Task 2.1: Generate SSH Key Pair

Task 2.2: Provision Primary-DNS Compute Instance

Task 3: Install and Configure BIND9

Task 3.1: Access Primary-DNS Compute Instance using Bastion

Task 3.2: Install BIND9

Task 3.3: Change the Fully Qualified Domain Name (FQDN) of the Instance

Task 3.4: Configure the named.conf.options File

Task 3. 5: Use netstat to display TCP/UDP Ports Status

Task 3.6: Configure the named.conf.local File

Task 3.7: Configure the db.orastage.com File

Task 3.8: Configure the 50-cloud-init.yaml File

Task 3.9: Disable iptables Firewall

Task 3.10: Restart BIND9

Task 3.11: Test

Task 4: Configure OCI Forwarding Endpoints and Rules

Task 4.1: Configure Forwarding Endpoint and Rule for Frontend-VCN

Task 4.2: Configure Forwarding Endpoint and Rule for Backend-VCN

Task 5: Provision Client Instances to Perform DNS Queries

Task 5.1: Create FE-VM Compute Instance

Task 5.2: Create BE-VM Compute Instance

Task 6: Test and Validate

Task 6.1: Access FE-VM Compute Instance using Bastion and Test

Task 6.2: Access BE-VM Compute Instance using Bastion and Test

Next Steps

Acknowledgments

More Learning Resources

Task 3.4: Configure the `named.conf.options` File

Task 3. 5: Use `netstat` to display TCP/UDP Ports Status

Task 3.6: Configure the `named.conf.local` File

Task 3.7: Configure the `db.orastage.com` File

Task 3.8: Configure the `50-cloud-init.yaml` File

Task 5.1: Create `FE-VM` Compute Instance

Task 5.2: Create `BE-VM` Compute Instance