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.

Use Oracle Cloud Infrastructure DNS to Resolve Native Domains

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

In this tutorial, we will focus on handling OCI native domains such as oraclevcn.com and oraclecloud.com. In this section, we will move away from resolving custom domains like orastage.com using BIND9, and instead, explore OCI built-in DNS capabilities.

We will dive into the components of OCI Private DNS, and the key elements involved in query handling, which play crucial roles in managing DNS traffic within OCI private networks. You will notice that we have already used them in some parts of Tutorial 1 and Tutorial 2. These components are:

Private DNS Zone: Contains DNS data only accessible from within a VCN such as private IP addresses. A private DNS zone has similar capabilities to an internet DNS zone, but provides responses only for clients that can reach it through a VCN. Each zone belongs to a single view.
Private DNS View: A grouping of private zones, each view can be associated with a resolver to control how DNS queries are resolved. A single view can be utilized by multiple resolvers, enabling the sharing of private DNS data across different VCNs. Each zone can only be part of one view.

For example, you created two new VCNs: VCN-A and VCN-B. By default, resources within VCN-A can resolve each other without additional configuration, because their records are stored in the same private zone, which is in VCN-A private view. Same thing for VCN-B. However, if you want resources in VCN-A to resolve resources in VCN-B, then you have to associate the private view of VCN-B to VCN-A resolver. If you want resources in VCN-B to resolve resources in VCN-A, then you have to associate the private view of VCN-A to VCN-B resolver.
Private DNS Resolver: A VCN dedicated private DNS resolver provides responses to DNS queries in the following order: First it will check zones in the attached private views, then in its default view, then by checking the forwarding rules, and finally by using Internet DNS. It is basically the engine that looks for answers to your instance’s queries.

For example, the following image screenshot shows a VCN resolver page, the sequence followed when resolving a query from an instance in this VCN will go like this:
Forwarding Endpoints and Rules: Forwarding endpoints serve as connectors between your OCI VCN and external DNS resolvers or other DNS zones. Using forwarding rules, you can direct specific DNS queries to designated external servers or listeners in other VCN resolvers, enabling hybrid cloud DNS architectures or multi-zone resolution.
Listening Endpoints: These endpoints are used to receive DNS queries from external sources. They allow your OCI DNS infrastructure to listen for and respond to incoming DNS requests, enhancing your ability to manage DNS queries across various network configurations.

Together, these components provide powerful tools for managing and customizing DNS within your OCI environment.

By the end of this tutorial, you will have a solid understanding of how to use these OCI DNS components to efficiently manage and resolve queries within your cloud environment.

Objectives

The primary objective of this tutorial is to enable FE-VM client (fe-vm.feprivatesubnet.frontendvcn.oraclevcn.com) to query BE-VM (be-vm.beprivatesubnet.backendvcn.oraclevcn.com), and vice versa, with the listener LSN to answer all of these queries.

Final architecture

Note:

When you initially create a VCN and a Subnet, you can specify DNS labels for each then launch a compute instance, you may assign a hostname for it. At the end, the instance Fully Qualified Domain Name (FQDN) will look like this: <VM-HOSTNAME>.<SUBNET-DNS-Label>.<VCN-DNS-Label>.oraclevcn.com. Specifying these labels are optional, if you leave them empty they will be given random names taken from the resource name, just like FE-VM and BE-VM in this tutorial.

If we only needed OCI resources to resolve each other then a listener is not needed here, as this can be done by only using private views as mentioned in the Overview section. However, the reason behind choosing to use a listener here is to also handle DNS resolution from any other environment such as on-premises and other clouds, and adding all the private views to the resolver of this listener will be enough. This setup addresses a particular use case where you also might need other environments (on-premises or other cloud environments) to resolve OCI resources. However, this is not included in this tutorial.

All oraclevcn.com and oraclecloud.com queries should be forwarded to the same listener, regardless if the query comes from OCI, on-premises network, or other cloud provider network, as the resolver for LSN-VCN will handle all of these queries from private views.

In this tutorial, we are not going to test queries from on-premises or Microsoft Azure, but only from OCI instances. So, the following diagram is only for illustration purposes.

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 DNS in general.
Make sure to complete the first two tutorials:
1. Configure BIND9 Domain Name System in Oracle Cloud Infrastructure.
2. Implement High Availability on BIND9 Domain Name System in Oracle Cloud Infrastructure.
One VCN is required with one private subnet in it, and attach it to the existing DRG. For more information, see Task 1.3: Attach VCNs to the DRG.
- LSN-VCN: This will host the listener. Note that the listener does not have to be in a dedicated VCN, but we preferred to do so in this tutorial in order to segregate it from other resources.
Based on the Prerequisites, you should have already built the following architecture.

Task 1: Set up Network Components like Routing and Security

Task 1.1: Create a Virtual Cloud Network (LSN-VCN)

Make sure you have the LSN-VCN (10.3.0.0/16) already created, containing LSN-Private-Subnet (10.3.0.0/24).

Click the hamburger menu (≡) from the upper left corner.
1. Click Networking.
2. Click Virtual cloud networks.
We can see the VCN in place, currently it has only one private subnet, and the default route table and security list attached to it.

Task 1.2: Configure Routing and Security for LSN-VCN

This must be done on the subnet level. Navigate to the VCNs page and click LSN-VCN.
Click the private subnet.
Click Route Table, which is an assigned route table.
Add the following rules.
- 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.
- 10.2.0.0/16 - DRG: Route traffic destined to Backend-VCN to the DRG.
Let us do the security now. Go to the Subnet Details page and click the assigned security list.
Allow ingress traffic: DNS traffic (TCP/port 53 and UDP/port 53) from DNS-VCN, Frontend-VCN, and Backend-VCN.
Allow all the egress traffic.

Task 1.3: Configure Routing and Security for DNS-VCN

Navigate to the VCNs page and click DNS-VCN.
Click the private subnet.
Click Route Table, which is an assigned route table.
Add the following rules.
- 10.3.0.0/16 - DRG: Route traffic destined to LSN-VCN to the DRG.
The needed security rules are already added. For more information, see Tutorial 1: Task 1.4 - Configure Routing and Security for DNS-VCN.

Task 1.4: Configure Routing and Security for Frontend-VCN

Repeat steps done in Task 1.3 for Frontend-VCN.

Task 1.5: Configure Routing and Security for Backend-VCN

Repeat steps done in Task 1.3 for Backend-VCN.

Task 2: Configure OCI Private DNS Components

Task 2.1: Add Private Views to LSN-VCN Resolver

Navigate to LSN-VCN and click DNS Resolver.
1. Scroll down and click Associated private views.
2. Click Manage private views.
3. Select the private views of DNS-VCN, Frontend-VCN, and Backend-VCN.
4. Click Save changes.
5. Private views are added successfully.
Currently, LSN-VCN resolver has visibility on all the DNS records created in the other private zones. So, when the listener receives any query to FE-VM and BE-VM FQDNs, it will resolve directly using the associated private views.

Task 2.2: Configure Listening Endpoint in LSN-VCN Resolver

Go to the OCI Console.
1. In the same resolver, click Endpoints.
2. Click Create endpoint.
3. Name: Enter a name for the endpoint.
4. Subnet: Select the private subnet of the LSN-VCN.
5. Endpoint type: Select Listening.
6. Listening IP address: Enter 10.3.0.6.
7. Click Create endpoint.
8. The listening endpoint is created successfully.

Task 2.3: Configure Forwarding Rule in Frontend VCN Resolver

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. Add another rule with the following information as shown in the screenshot.
4. Click Save changes.
5. The forwarding rule is created successfully.

Task 2.4: Configure Forwarding Rule in Backend VCN Resolver

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. Add another rule with the following information as shown in the screenshot.
4. Click Save changes.
5. The forwarding rule is created successfully.
The architecture should look like this.

Task 3: Test and Validate

Test Scenario 1: FE-VM to query the listener for BE-VM native domain

The FE-VM client machine should be able to resolve be-vm.beprivatesubnet.backendvcn.oraclevcn.com. The following image illustrates the testing scenario we aim to achieve.
Go to the OCI Console, navigate to BE-VM instance and copy Internal FQDN to use it in the test.
Access FE-VM and perform a query test using the OCI Bastion service same as Tutorial 2: Test Scenario 1 - Primary-DNS Responds to FE-VM Queries when Secondary-DNS is Down. Once connected, run oraclevcn.com queries from FE-VM to be-vm.beprivatesubnet.backendvcn.oraclevcn.com and validate the configuration. You can use various methods to verify that the setup is working correctly.
1. Run host command.
2. Run ping command.
3. Run dig command.

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

Test Scenario 2: BE-VM to query the listener for FE-VM native domain

The BE-VM client machine should be able to resolve fe-vm.feprivatesubnet.frontendvcn.oraclevcn.com. The following image illustrates the testing scenario we aim to achieve.
Go to the OCI Console, navigate to FE-VM instance and copy Internal FQDN to use it in the test.
Access BE-VM and perform a query test using the OCI Bastion service. Once connected, run oraclevcn.com queries from BE-VM to fe-vm.feprivatesubnet.frontendvcn.oraclevcn.com and validate the configuration. You can use various methods to verify that the setup is working correctly.
1. Run the host command.
2. Run the ping command.
3. Run the dig command.

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

Next Steps

In this tutorial, we have used OCI Private Views, Forwarding Endpoints and Rules, and Listening Endpoints which offer flexible and robust DNS management within a virtual cloud network. Together, these components streamline DNS operations, ensuring efficient and scalable name resolution within OCI environments, especially for a hybrid DNS scenario that includes integrated multicloud and on-premises environments.

In the next and last tutorial of this series, Add Security to the DNS Architecture using pfSense Firewall, we will enhance the security of our DNS infrastructure by configuring the pfSense Firewall to inspect and control all DNS queries, this will include monitoring and filtering requests for both internal OCI domains (oraclevcn.com and oraclecloud.com) and custom domains managed in BIND9 such as orastage.com.

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

Use Oracle Cloud Infrastructure DNS to Resolve Native Domains

G16533-02