X

Best Practices from Oracle Development's A‑Team

Resolving a Private Oracle Analytics Cloud Fully Qualified Domain Name

Validated December 11, 2020 with OAC 5.8

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 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

Validations

December 11, 2020 with OAC 5.8

Topics

Before You Begin

Determining DNS Scenarios

Deploying Required Components

Validating DNS Translations

 Before You Begin and Assumptions

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.

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

 

Privileges

User accounts in OCI tenancies or on-premise granted 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: RDG may be used as a requestor in this guide.

 

Initial State

OAC is provisioned with a private endpoint.

About Resource Locations

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.

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

 

About Resource Definitions

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.

About Resource Zones and Views

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.

This is important because you or your DNS administrator may create custom views and zones to contain private OAC definitions. For example you may create a custom view and zone in OCI named analytics.ocp.oraclecloud.com that contains an "A" record for 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 from the requestor's DNS to the resource definition location.

 

Gateways

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.

 Determining the OAC DNS Scenarios

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.

CUSTOM RESOLUTION

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.

DEFAULT RESOLUTION

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.

DNS PRIVATE VIEW

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.

Customer Managed (Custom) View

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.

Note: Custom Views are evaluated before any other DNS components.

 

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 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.

 Deploying Required Components

The following table lists additional scenario components that may be required with links for reference.

COMPONENT USE REFERENCE Scenarios
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.

CUSTOM RESOLUTION

DHCP Resolver

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
Custom Resolver 10.20.10.34 VCN2-INST-SN

 

OCI RESOLUTION

 No additional components required.

PRIVATE VIEW

Protected Private View

If in OCI, associate OAC's default private view to the VCN2 resolver.

RESOLVER PRIVATE VIEW
VCN2 VCN1

 

Custom Private View

In OCI associate a custom view in OAC's tenancy and region.

RESOLVER PRIVATE VIEW
VCN2 analytics.ocp.oraclecloud.com

 

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 OAC listening endpoint
VCN2 VCN2-DNS-SN 10.20.10.32/27 Default Default For the forwarding 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
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.

 

DNS Rule

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
VCN2 prefix.analytics.ocp.oraclecloud.com VCN2-DNS-Forwarder 10.10.10.34

 

Route Rules

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

 

Route Table Associations

Ensure the route table with the rule is associated to the appropriate subnet.

NAME SUBNET
VCN1-DNS-RT VCN1-DNS-SN
VCN2-DNS-RT VCN2-DNS-SN

 

Access Rules

SECURITY LIST VCN CIDR PROTOCOL PORT NOTE
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

                               

Security List Associations

Ensure the security list with the rule is associated to the appropriate subnet.

NAME SUBNET
VCN1-DNS-SL VCN1-DNS-SN
VCN2-DNS-SL VCN2-DNS-SL

 

 

 Validating the OAC DNS Translation

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 

 Summary

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

 

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