X

Best Practices from Oracle Development's A‑Team

Using OCI Private DNS to Resolve Private Oracle Analytics Cloud Data Source FQDNs

Validated February 2, 2021 with OAC 5.9

Introduction

Oracle Analytics Cloud (OAC) may now be provisioned within a Virtual Cloud network (VCN) on Oracle Cloud Infrastructure (OCI) with a private IP address.

This post is a step-by-step guide for using OCI private DNS components to resolve the fully qualified domain names (FQDNs) of OAC's data sources.

This is one of the posts listed in OAC Private Endpoint and OAC Private Access Channel. The documentation is DNS in Your Virtual Cloud Network.

 

Validations

February 2, 2021 with OAC 5.9

December 2, 2020 with OAC 5.8

Topics

Before You Begin

Determining DNS Scenarios

Deploying Required Components

Deploying Gateways and Validating the DNS Configuration

 Before You Begin and Assumptions

All names and addresses used in this post are for examples only. In this post data sources are referred to as resources. These examples use an OAC instance requesting resolution of resourceFQDN definitions, but they also apply to any requesting service. Although not required, resources are in separate subnets to demonstrate security and routing rules.

Note: Resource definitions existing outside of OCI are shown in the diagrams and tables as existing in VCN 2.

 

Privileges

User accounts in OCI tenancies granted compartment privileges for managing DNS and Networking components.

OAC / RDG 

OAC and/or RDG are provisioned. Refer here for provisioning a private OAC. Refer here for provisioning a private RDG.

Note: If RDG is used, it is in the same subnet as OAC. OAC in the examples apply to both OAC and RDG

 

Initial State

OAC is provisioned with a private endpoint.

Private Sources

The set of private resource domains requiring resolution.

OCI Resolver Order

The OCI Resolver provides responses to DNS queries by checking each private view in order, then the default view for the VCN, then each private rule in order, and finally by using internet DNS. The first item in that sequence able to provide an answer does so, and later items are not checked.

This is important because a definition in a custom view may be used before other private views, rules, or the internet. Once a definition is found DNS stops searching.

 

About Resource Definitions

In this post resource definitions are DNS "A" records with associated IP addresses or "CNAME" records with associated alias FQDNs.

About Resource Domains

Domains form the naming hierarchy of DNS. Top level domains are those such as .com or .org. Below these are levels of sub-domains usually having registered owners e.g. oraclevcn.com. At the bottom of the hierarchy are the FQDNs. When a sub-domain level is reached where administrative responsibility is defined a DNS zone to contain resource definitions. In the DNS OCI VCN naming hierarchy, this level is reached at the subnet level e.g. phxhubsndb.phxhubvcn.oraclevcn.com This post uses the term domain to refer to a sub-domain level. When used as a forwarding rule or a data source definition a domain includes all FQDNs existing below the domain in the DNS hierarchy.

About Resource Zones and Views

Resource zones exist in a DNS name server. They are a collection of resource definitions that share a common domain. For example the analytics.ocp.oraclecloud.com zone may contain "A" records for abc.analytics.ocp.oraclecloud.com and xyz.analytics.ocp.oraclecloud.com. However, some resources such as Private OACs are in their own zone e.g. prefix.analytics.ocp.oraclecloud.com

Resource zones may be logically grouped into resource views. For example in OCI, the default view for a VCN's resolver is named with the VCN's name e.g. PHX-HUB-VCN  It contains zones associated with it's subnets e.g. phxhubsndb.phxhubvcn.oraclevcn.com and with it's private analytic instances e.g. prefix.analytics.ocp.oraclecloud.com

About Resource Definition Locations

A resource definition location is the location of the first DNS resolver that finds a resource's definition and successfully provides the resource's IP address. Examples locations are on-premise, other-cloud, OCI VCN, etc.

This is important as networking gateways may be required to facilitate traffic to the resource definition location.

 

 Determining Data Source DNS Scenarios

The set of defined resource definition locations determine the scenarios required. You may have one or more of the following scenarios depicted below.

CUSTOM RESOLUTION

This is the only scenario that doesn't not use an OCI resolver. It is used if you desire that all OAC resources be resolved by a non-OCI DNS server (typically in your data center but it could be in OCI). It is shown in OAC's VCN as a custom DHCP option.

Note: If not all sources are resolvable by your DNS server, use a combination of the other scenarios.

 

DEFAULT RESOLVER

Every VCN in OCI is created with a private DNS resolver named VCN and Internet Resolver. It is shown in the OAC VCN as the Default DHCP option. It is actually two resolvers in one; an Internet resolver and a VCN Resolver. This scenario is used when a resource definition is publicly resolvable via the internet or by the OAC VCN resolver's default view i.e. the resource exists in the same VCN as OAC.

DNS PRIVATE VIEW

This scenario may be used when a resource definition is contained in the OAC VCN resolver's associated private views.

A Private View is either Customer Managed (Unprotected) or Oracle-Managed (Protected). They contain private zones defined in a region within a tenancy. Each VCN has a default private view with zones containing resource definitions residing in the VCN. Additional private views in the same region and tenancy may be associated to the OAC VCN's resolver.

Customer Managed (Custom) View

An unprotected custom private view contains custom private DNS zones containing trusted DNS records. OCI DNS Management Services enables these zones. They are frequently used to define "vanity" domains, change the resource definition of a resource via an alias and define on-premise domains where direct access to an on-premise DNS server is prohibited but access to the resource is allowed.

Although a domain name may have a registered owner, it's name may also be used for a custom private zone. For example you may create a custom view and zone in OCI named myonpremisedomain.com that contains an "A" record for mydb.myonpremisedomain.com
This post assumes the decision to use custom views for resources has been made and if used they contain custom zones with resource definitions. 

Oracle Managed Private View

A DNS Protected Private View is associated with a VCN and is a collection of DNS protected private zones associated with the VCN's subnets and services.

 

DNS PRIVATE ENDPOINT

The DNS Private Endpoint scenario uses a combination of DNS forwarders and listeners. A forwarding endpoint is deployed in a subnet in OAC's VCN. It forwards DNS queries to a listening endpoint in other peered VCNs, other clouds or your on-premises DNS. 

DNS rules in the OAC VCN resolver detect defined resource domains and uses the forwarding endpoint to reach listening endpoints.

A listening endpoint in or out of OCI receives DNS queries from the OAC VCN's forwarder, attempts to resolves them, and returns the responses.

 

 Deploying Required Components

The following table lists the scenario components that may be deployed with links for reference. Examples for access rules use the default DNS port number (53).

 

COMPONENT USE REFERENCE Scenarios
DHCP RESOLVER Changes to define the custom name server's IP address link All
PRIVATE VIEW Associates custom views or another VCN's default view link and link Private View
ACCESS RULE Secures a subnet's ingress and egress traffic link Custom Resolver, Private Endpoint
SUBNET Hosts DNS endpoints link Private Endpoint
PRIVATE ENDPOINT Forwards or Listens for DNS Queries Resolver Endpoints Private Endpoint
PRIVATE RULE Directs a Forwarder to a Listening IP address Resolver Rules Private Endpoint

 

The following tables provide component details for the scenarios with example values.

CUSTOM RESOLVER

DHCP Resolver

Ensure the OAC subnet (SN) is set to this option.

OPTION NAME SERVER IP SUBNET
Custom Resolver 10.228.30.2 VCN1-OAC-SN

 

Access Rules

SECURITY LIST VCN CIDR PROTOCOL PORT ATTACHED TO NOTE
VCN1-OAC-SL VCN1 10.20.10.0/23 UDP 53 VCN1-OAC-SN Egress to Custom Name Server
VCN2-DNS-SL VCN2 10.10.10.0/23 UDP 53 VCN2-DNS-SN Ingress from OAC VCN

 

OCI RESOLVER

                      No additional components required.

PRIVATE VIEW

Private View

Associate the VCN2 default private view to the OAC VCN's resolver

VCN PRIVATE VIEW
VCN1 VCN2

 

PRIVATE ENDPOINT

Subnet

Create a subnet in each VCN to host DNS endpoints

VCN NAME CIDR ROUTE TABLE SECURITY LIST NOTE
VCN1 VCN1-DNS-SN 10.10.10.32/27 Default Default For the forwarding endpoint
VCN2 VCN2-DNS-SN 10.20.10.32/27 Default Default For the listening endpoint

 

DNS Endpoint

Create a forwarding and listening endpoint in the appropriate subnet. Make a note of the listening endpoint's IP address.

VCN SUBNET MODE NAME IP ADDRESS NOTE
VCN1 VCN1-DNS-SN Forwarder VCN1-DNS-Forwarder 10.10.10.34 Forward DNS queries to remote listeners.
VCN2 VCN2-DNS-SN Listener VCN2-DNS-Listener 10.20.10.34 Resolve DNS queries and return results.

 

DNS Rule

Create a DNS rule in the OAC VCN's resolver that detects a resource's domain and submits the DNS query to the OAC VCN's forwarding endpoint with instructions to forward the query to the VCN2 listener endpoint's IP address.

VCN DOMAIN FORWARDER LISTENER IP ADDRESS
VCN1 prefix.domain.root VCN1-Forwarder 10.20.10.34

 

Access Rules

SECURITY LIST VCN CIDR PROTOCOL PORT ATTACHED TO NOTE
VCN1-DNS-SL VCN1 10.20.10.0/23 UDP 53 VCN1-DNS-SN Egress to VCN2's listener
VCN2-DNS-SL VCN2 10.10.10.0/23 UDP 53 VCN2-DNS-SN Ingress from the OAC VCN's forwarder

 

 Deploying Gateways and Validating the DNS Configuration

Follow the steps in this post to deploy the appropriate network gateways and routing rules and to validate the DNS configuration.

 Summary

This post provided a step-by-step guide for using OCI private DNS components to resolve the fully qualified domain names (FQDNs) of OAC's data sources.

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