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 deploying the DNS components necessary to resolve a private OAC's fully qualified domain name (FQDN). This is one of the post listed in the OAC Private Endpoint Parent Post
December 11, 2020 with OAC 5.8
Before You Begin
Determining DNS Scenarios
Deploying Required Components
Validating DNS Translations
All names and addresses used in this post are for examples only. These examples use a requestor (an instance or user) resolving an OAC FQDN. The requestor may be in OCI or remote (on-premise or other cloud). Although not required, requestors are in separate subnets to demonstrate security and routing rules.
User accounts in OCI tenancies or on-premise granted privileges for managing DNS and Networking components.
OAC is provisioned with a private endpoint.
In this post the resource location is where the translated OAC's IP address is. It may either be the private endpoint of OAC or the location of a Web Application Firewall or a Load Balancer set in front of OAC.
In this post a resource definition is an OAC DNS "A" record associated with an IP address or a "CNAME" record associated with an alias. The resource definition exists in a DNS zone in or out of OCI.
Resource zones are usually a collection of resource definitions sharing 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. 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 it's private analytic instances e.g. prefix.analytics.ocp.oraclecloud.com
The assignment of a zone is usually done by the operating system and the DNS system facilitating the provisioning of a resource.
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 necessary networking gateways (NAT, Local Peering, Dynamic Routing) are provisioned and peered for connectivity from the requestor's network to OAC. Refer here for local and dynamic routing gateway documentation.
The requestor's location and the requestor's organizational policies 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 OCI Resolution. It uses a non-OCI DNS server with a zone containing an "A" record for OAC's FQDN.
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. This scenario is used when OAC is in the same VCN as the requestor and OAC has not been defined in a custom view associated with the VCN.
This scenario may be used when the OAC resource definition is contained in the requestor VCN resolver's associated private views.
A private view is either Customer Managed (Unprotected) or Oracle-Managed (Protected). It contains 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 requestor VCN's resolver.
An unprotected custom private view contains custom private DNS zones containing trusted DNS records that may not be resolvable directly by the VCN and Internet Resolver. OCI DNS Management Services enables these zones. They are used to define "vanity" domains, on-premise domains or alter the order of DNS query resolution.
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 DNS forwarder and listener.
A subnet and a forwarding endpoint are deployed in the requestor's VCN.
A subnet and a listening endpoint are deployed in the OAC's VCN.
A DNS rule is deployed in the requestor's VCN that detects the OAC domain and uses the requestor's forwarding endpoint to reach the OAC's listening endpoint.
OAC's listening endpoint resolves the OAC FQDN and returns the response.
The following table lists additional scenario components that may be required with links for reference.
|PRIVATE VIEW||Associate a custom private view or another VCN's default view||link||Private View|
|DHCP Option||Changes to Custom and defines the non-OCI DNS name server IP address||link||Custom Resolution|
|ACCESS RULE||Secures a subnet's ingress and egress traffic||link||Private Endpoint|
|ROUTE RULE||Routes a subnet's traffic out of the VCN||link||Private Endpoint|
|SUBNET||Hosts DNS endpoints||link||Private Endpoint|
|PRIVATE ENDPOINT||Forwards or Listens for DNS Queries||Resolver Rules||Private Endpoint|
|PRIVATE RULE||Directs a Forwarder to a Listening IP address||Resolver Endpoints||Private Endpoint|
The following tables lists additional component details with example values.
This is necessary only for a non-OCI DNS server.
If in OCI, ensure this option is set for the requestor's subnet
|DHCP OPTION||NAME SERVER IP||SUBNET|
No additional components required.
If in OCI, associate OAC's default private view to the VCN2 resolver.
In OCI associate a custom view in OAC's tenancy and region.
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 OAC listening endpoint|
|VCN2||VCN2-DNS-SN||10.20.10.32/27||Default||Default||For the forwarding endpoint|
Create a forwarding and listening endpoint in the appropriate subnet. Make a note of the listening endpoint's IP address.
|VCN2||VCN2-DNS-SN||Forwarder||VCN2-DNS-Forwarder||10.20.10.34||Forward DNS queries to the OAC VCN's listener.|
|VCN1||VCN1-DNS-SN||Listener||VCN1-DNS-Listener||10.10.10.34||Resolve DNS queries and return results.|
Create a DNS rule in the requestor's DNS that detects an OAC domain and submits it to the DNS's forwarding endpoint with instructions to forward the DNS query to the OAC VCN listener endpoint's IP address.
|RESOLVER||DOMAIN||FORWARDER||LISTENER IP ADDRESS|
Create a route table for these rules.
|ROUTE TABLE||VCN||DESTINATION CIDR||TARGET||NOTE|
|VCN2-DNS-RT||VCN2||10.10.10.0/23||Region2-Gateway||DNS queries to OAC VCN's listener|
|VCN1-DNS-RT||VCN1||10.20.10.0/23||Region1-Gateway||Responses to VCN2's forwarder|
Ensure the route table with the rule is associated to the appropriate subnet.
|VCN1-DNS-SL||VCN1||10.20.10.0/23||UDP||53||Ingress from the requestor VCN's forwarder|
|VCN2-DNS-SL||VCN2||10.10.10.0/23||UDP||53||Egress to OAC's listener|
Ensure the security list with the rule is associated to the appropriate subnet.
Validate the DNS scenarios using the OAC hostname.
From a user's browser or an instance in the requestor subnet e.g. VCN2-INST-SN, use either https:prefix.analytics.ocp.oraclecloud.com/ui , or nslookup prefix.analytics.ocp.oraclecloud.com
This post provided a step-by-step guide for deploying the DNS components necessary to resolve a private OAC's fully qualified domain name (FQDN).
For other posts relating to analytics and data integration visit http://www.ateam-oracle.com/dayne-carley