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.
February 2, 2021 with OAC 5.9
December 2, 2020 with OAC 5.8
Before You Begin
Determining DNS Scenarios
Deploying Required Components
Deploying Gateways and Validating the DNS Configuration
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.
User accounts in OCI tenancies granted compartment privileges for managing DNS and Networking components.
OAC is provisioned with a private endpoint.
The set of private resource domains requiring resolution.
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.
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
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.
The set of defined resource definition locations determine the scenarios required. You may have one or more of the following scenarios depicted below.
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.
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.
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.
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.
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.
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.
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).
|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.
Ensure the OAC subnet (SN) is set to this option.
|OPTION||NAME SERVER IP||SUBNET|
|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|
No additional components required.
Associate the VCN2 default private view to the OAC VCN's resolver
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|
Create a forwarding and listening endpoint in the appropriate subnet. Make a note of the listening endpoint's IP address.
|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.|
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|
|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|
Follow the steps in this post to deploy the appropriate network gateways and routing rules and to validate the DNS configuration.
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