Best Practices from Oracle Development's A‑Team
-
/ A-Team Chronicles
April 29, 2020
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