X

Best Practices from Oracle Development's A‑Team

Resolving OCI Fully Qualified Domain Names with DNS Forwarding

Last Validation: April 30, 2020 for OAC 105.5 AND ADW 19c

Introduction

If an application server or browser on-premise or in the Oracle cloud attempts to connect to an application server in a different Virtual Cloud Network (VCN) it may need to resolve the other application server's Fully Qualified Domain Name (FQDN). An FQDN is the concatenation of a server's host name and domain name.

This post describes resolving these names using Custom Resolver Domain Name Server (DNS) forwarding and built-in VCN DNS name resolution in Oracle's Cloud Infrastructure (OCI). Domain Name Servers provide many services, two of which are Forwarding and Name Resolution. These services ultimately resolve a FQDN to an IP address that is used by network routers to reach other application servers. They server to eliminate the need for humans to memorize or hard-code IP addresses such as 192.168.18.13, Specifically it uses two custom DNS forwarders and one built-in OCI VCN Resolver.

This post uses an example case where an Oracle Analytics Cloud (OAC) Remote Data Gateway (RDG) connects to a private Autonomous Database (ADB) residing in a different VCN. 

Note: RDG throws the following JDS 116 error when an ADB FQDN cannot be resolved:

Refer here for details on DNS in Your Virtual Cloud Network.

Validations

April 30, 2020 for Linux 7.8, Windows Server 2012 R2 and ADW 19c

Topics

Before You Begin

Configuring Custom Domain Name Servers

Deploying Additional VCN Subnets

Deploying DNS Instances

Deploying DNS Instance Software

Configuring Conditional DNS Forwarding

Configuring DNS Subnet Security and Routing

Reconfiguring the RDG Subnet

Configuring a Custom DNS Resolver

Configuring Additional RDG Subnet Routing

Validating ADB Host Name Resolution

 Before You Begin

Before we begin the following is assumed to be in place.

A private ADB deployed in a VCN, referred to later as the ADB VCN, and available for connections. Refer here for private ADB documentation.

Access to the ADB downloaded Client Credentials zip file. Refer  here for instructions.

An OAC instance configured to use RDG with an RDG agent enabled.

RDG deployed in a VCN, referred to later as the RDG VCN, and connected to OAC. If RDG is deployed on a Windows Server, and egress rule must be added to the firewall allowing UDP traffic out on port 53. Refer here for RDG deployment scenarios.

Note: both VCNs above must have been created with the default DNS resolution as shown below. This option assigns a DNS label to each VCN during creation. It is required for assignment of DNS hostnames to hosts in the subnets and required to use the VCN's default DNS feature (called the Internet and VCN Resolver).

Remote or Local Peering established between the RDG and ADB VCNs. Refer here for VCN peering documentation.

Below is a diagram depicting this initial state using local peering. The introductory diagram above depicts a remote peering scenario.

 Configuring Custom Domain Name Servers

In this section we deploy a custom DNS in each VCN, establish the security rules and routing between the two, and configure the RDG DNS to conditionally route traffic to the ADB DNS.

Deploying Additional VCN Subnets

An additional subnet is required in the RDG VCN. Another is optional in the ADB VCN but is used in this post to demonstrate the security lists and routing requirements. These subnets host the DNS instances.

Create a public regional subnet in both VCNs. Regional subnets span availability domains for higher availability. Enter a Name, choose or accept the Compartment and enter the CIDR Block and let everything else default. Refer here for subnet documentation. Public subnets are used in this post for ease of demonstration as the instances within them are accessed via an SSH client directly.

Deploying DNS Instances

You need to have an SSH key pair available to create and access an instance. Refer here for key pair documentation.

Create two new compute instances, one in each in both new subnets using the default Oracle Linux image. Refer here for Compute documentation. Ensure to leave the default box checked for assigning a public IP address.

Note: For higher availability deploy additional DNS instances in different availability domains.

Configuring DNS Subnet Security and Routing

Security rules are necessary to allow designated traffic types to and from designated sources into and out of designated ports in the subnet.

Routing rules are necessary to direct traffic from designated sources to an appropriate gateway.

Configuring DNS Subnet Security Lists

A security list contains both ingress and egress rules. Refer here for documentation. This post assumes a development situation where it is allowable to have these be as least restrictive as possible.

Ingress Rules

Ingress rules are required for SSH access and inter-DNS communication. These are pictured below.

Egress Rules

Egress rules are required for outbound traffic. The default rule allowing all traffic out is pictured below.

Configuring DNS Subnet Routing Tables

Routing rules direct traffic to various gateways. See here for documentation. This post uses both Internet (IG) and Local Peering (LPG) gateways. Example route rules are below. Each subnet needs a rule for the CIDR block of the other locally peered VCN.

Deploying DNS Instance Software

DNS software of your choice needs to be installed and configured in each new compute instance. Two popular open-source products are BIND and DNSmasq. This post uses DNSmasq. Refer here for more information on it. 

Configuring SSH access

Both instances are accessed via SSH. Using an SSH configuration file is the easiest method and is used here. The default location of the file is in the .ssh directory under the /home/opc home directory. It is named config. Follow the steps in here to set up the file. This post uses entries named RDG-DNS and ADB-DNS.

ssh RDG-DNS

ssh ADB-DNS

Installing DNSmasq

SSH into each DNS server and use the yum utility to install the software.

sudo yum install dnsmasq -y

Configuring DNSmasq

Use the following commands:

Change to the root user

sudo su -

Open port 53 in the Linux firewall for inter-DNS traffic

firewall-cmd --add-port=53/udp

Open it permanently to span reboots

firewall-cmd --permanent --add-port=53/udp

Create or Append to the DNSmasq Configuration File

This command disables caching which is good for testing only.

echo "cache-size=0" >>/etc/dnsmasq.conf

Test the DNS Configuration File

Use the following command.

dnsmasq --test

Result: dnsmasq: syntax check OK.

Enable DNSmasq

systemctl enable dnsmasq

Restart DNSmasq

systemctl restart dnsmasq

Logoff as root

exit

Configuring Conditional DNS Forwarding

Now that both DNS servers are running, conditional DNS forwarding is configured on the RDG DNS server. As ADB is not attempting to access anything in another VCN, the default forwarding for the ADB DNS server is sufficient.

About Default Forwarding

Default forwarding forwards DNS queries to the built-in VCN / Internet resolver. This resolver is what is in the subnet's instance's /etc/resolv.conf file.  The default contents of this file are:

nameserver 169.254.169.254

The IP address noted above is for the DNS Resolver that resolves FQDNs within the VCN and external internet names such as www.oracle.com

Conditional Forwarding for the RDG DNS Server

To resolve the FQDN of a private ADB in the another VCN, RDG must send the ADB FQDN to the RDG DNS server. The RDG DNS Server conditionally forwards the name based on the ADB domain name (the last portion of the  FQDN), and the ADB VCN's DNS Forwarding Server's IP address.

The ADB FQDN is found in the tnsnames.ora file in downloaded ADB client credentials zip file. An example entry for this file is:

ashprvlpg_medium = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=gj5uuqv7.adb.us-ashburn-1.oraclecloud.com))(connect_data=(service_name=g4kz1wyoyzrtvap_ashprvlpg_medium.adwc.oraclecloud.com))(security=(ssl_server_cert_dn="CN=adwc.uscom-east-1.oraclecloud.com,OU=Oracle BMCS US,O=Oracle Corporation,L=Redwood City,ST=California,C=US")))

The domain portion used in this case is:

adb.us-ashburn-1.oraclecloud.com

To configure the conditional forwarding, a line is added to the RDG DNS server's configuration file.

SSH into the RDG DNS Server

ssh RDG-DNS

Change to the root user

sudo su -

Append the forwarding statement to the DNSmasq configuration file. 

echo "server=/adb.us-ashburn-1.oraclecloud.com./10.0.1.2" >>/etc/dnsmasq.conf

This statement directs the RDG DNS server to route any FQDN ending with the ADB domain name to the ADB domain's DNS server's private IP address. The private IP address of the ADB DNS server is found on the Compute page.

Test the DNS Configuration File

Use the following command.

dnsmasq --test

Result: dnsmasq: syntax check OK.

Restart the DNSmasq server.

systemctl restart dnsmasq

Logoff as root

exit

 Reconfiguring the RDG Subnet

The last thing to do before validating the solution is to reconfigure the RDG subnet to use a Custom DNS Resolver. A customers resolver is defined in a VCN's DHCP options and uses the RDG DNS server's private IP address.

Creating a Custom Resolver DHCP Option

Navigate to the DHCP Options page in the RDG VCN and click Create DHCP Options

Provide a Name, choose or accept the Compartment, check the Custom Resolver box, provide the private IP address of the RDG DNS server as the DNS Server, and click Create DHCP Options.

Using the RDG VCN Custom Resolver

Convert the subnet hosting the RDG application to use the custom resolver. Navigate to the RDG Application Subnet and click Edit.

Choose the new custom resolver from the DHCP OPTIONS dropdown and click Save Changes.

Restarting the RDG Application Server

Restart the RDG Application Server for the custom resolver to take effect. The restart places the Custom Resolver's IP address in the instance's  /etc/resolv.conf file. After the restart, the new contents reflect the IP address entered when the custom resolver was created: nameserver 192.168.1.2

Use the following commands to restart the RDG Application Server.

SSH into the RDG Application Server

ssh RDG-APP-SERVER

Change to the root user

sudo su -

Restart the Instance

reboot now

Restarting Remote Data Gateway

If RDG is not configured to start automatically when the server starts, it must be started. Use the following statements to check RDG's status and start it.

SSH into the RDG Application Server

ssh RDG-APP-SERVER

Change to the RDG home directory

Change to the directory specified during the RDG installation.

cd <RDG Installation Directory> e.g. 

cd /home/opc/Oracle/Middleware/Silent_Home

Check the Status

domain/bin/status.sh

Start RDG if necessary

domain/bin/startJetty.sh

 Validating the ADB Host Name Resolution

The following depicts the configured topology and the DNS query flow.

About the Flow Above

The flow steps in the above diagram are:

 OAC sends an HTTPS request to RDG with SQL for ADB

 RDG sends a DNS query with the ADB FQDN to the RDG DNS

a The RDG DNS server forward the query to the ADB DNS

b The ADB DNS forwards the query to the VCN Resolver

c The VCN Resolver returns the IP address to RDG

 RDG Sends the SQL to the ADB Private IP

Using the Domain Information Groper (DIG) Utility

In the command below, the utility sends a FQDN through the DNS forwarders and resolvers and if successful, receives the associated IP address (10.0.0.5)

dig gj5uuqv7.adb.us-ashburn-1.oraclecloud.com

Successful Result: 

Connecting OAC RDG to the Private ADB

Create or update a connection in OAC to the private ADB. Refer here for detailed steps.

You have now resolved the FQDN of an ADB from a different VCN.

 Summary

This post described resolving an ADB FQDN using Custom Resolver DNS forwarding and built-in VCN DNS name resolution in Oracle's Cloud Infrastructure (OCI).

Another excellent blog on a generic hybrid DNS solution is here.

For other posts relating to analytics and data integration visit http://www.ateam-oracle.com/dayne-carley

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha