Creating an ACFS file system on OCI DB system

 

Creating an ACFS file system on OCI DB system

In an DB system on OCI if we want to add any file system then we can use the ACFS file system.

We can create an ACFS file system using below

1) Login to DB system with grid user

2)  Create a Volume by picking space from DATA disk group.

[grid@foa ~]$ asmcmd lsdg

State    Type    Rebal  Sector  Logical_Sector  Block       AU  Total_MB  Free_MB  Req_mir_free_MB  Usable_file_MB  Offline_disks  Voting_files  Name

MOUNTED  EXTERN  N         512             512   4096  4194304    262144     4372                0            4372              0             Y  DATA/

MOUNTED  EXTERN  N         512             512   4096  4194304    262144   257212                0          257212              0             N  RECO/

asmcmd volcreate -G data -s 20G oradata1

3) Validate the volume created

[grid@foa ~]$ asmcmd volinfo -G data oradata1

Diskgroup Name: DATA

 Volume Name: ORADATA1

 Volume Device: /dev/asm/oradata1-377

 State: ENABLED

 Size (MB): 20480

 Resize Unit (MB): 64

 Redundancy: UNPROT

 Stripe Columns: 8

 Stripe Width (K): 1024

 Usage: 

 Mountpath: 

4) We can check the volume physical details.

[grid@foa ~]$ fdisk -l /dev/asm/oradata1-377

Disk /dev/asm/oradata1-377: 21.5 GB, 21474836480 bytes, 41943040 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 4096 bytes

I/O size (minimum/optimal): 4096 bytes / 1048576 bytes

5) Format the new volume as ACFS

[grid@foa ~]$ /sbin/mkfs -t acfs /dev/asm/oradata1-377

mkfs.acfs: version                   = 19.0.0.0.0

mkfs.acfs: on-disk version           = 46.0

mkfs.acfs: volume                    = /dev/asm/oradata1-377

mkfs.acfs: volume size               = 21474836480  (  20.00 GB )

mkfs.acfs: Format complete.

6) Register the mount

Exit from grid user and connect as root.

mkdir /backup

 /sbin/acfsutil registry -a /dev/asm/oradata1-377 /backup -u oracle

7)  Verify

df -h

/dev/asm/oradata1-377            20G  414M   20G   3% /backup

https://www.funoracleapps.com/2022/11/creating-acfs-file-system-on-oci-db.html

How to Access Oracle Identity Cloud Service

 Access Oracle Identity Cloud Service through a service web console or the REST API.

Depending on how you signed up for Oracle Cloud, you’ll be directed to either the Oracle Cloud Infrastructure Console or the Oracle Cloud Infrastructure Classic Console.

Topics:

• Access Oracle Identity Cloud Service from the Oracle Cloud Infrastructure Console
• Access Oracle Identity Cloud Service from the Oracle Cloud Infrastructure Classic Console

Access Oracle Identity Cloud Service from the Oracle Cloud Infrastructure Console

On most Oracle Cloud accounts, you access the Oracle Identity Cloud Service console from the Oracle Cloud Infrastructure Console.

1. Sign in to Oracle Cloud.

   If you received a welcome email, use it to identify the URL, your user name, and your temporary password. After signing in, you will be prompted to change your password.

2. From the Oracle Cloud Infrastructure Console, click the navigation menu  in the top left corner, expand Identity, and then click Federation.
3. In the Federation page, click the Oracle Identity Cloud Service Console link.

   If multiple instances are listed, click the Oracle Identity Cloud Service Console link for the console instance you want to open.

CPE Configuration | OCI | Networking

CPE Configuration

This topic is for network engineers. It explains how to configure the on-premises device (the customer-premises equipment, or CPE) at your end of Site-to-Site VPN so traffic can flow between your on-premises network and virtual cloud network (VCN). See these related topics:

• Networking: For general information about the parts of a VCN
• Site-to-Site VPN: For various topics about IPSec VPNs
• Verified CPE Devices: For a list of CPE devices Oracle has verified

The following figure shows the basic layout of Site-to-Site VPN's IPSec connection.

Requirements and Prerequisites

There are several requirements and prerequisites to be aware of before moving forward.

Routing Considerations

For important details about routing for your Site-to-Site VPN see Routing for Site-to-Site VPN.

Oracle uses asymmetric routing across the multiple tunnels that make up the IPSec connection. Even if you configure one tunnel as primary and another as backup, traffic from your VCN to your on-premises network can use any tunnel that is "up" on your device. Configure your firewalls accordingly. Otherwise, ping tests or application traffic across the connection will not reliably work.

If you use BGP dynamic routing with your Site-to-Site VPN, you can configure routing so that Oracle prefers one tunnel over the other.

Note that the Cisco ASA policy-based configuration uses a single tunnel.

Creation of Cloud Network Components

You or someone in your organization must have already used the Oracle Console to create a VCN and an IPSec connection, which consists of multiple IPSec tunnels for redundancy. You must gather the following information about those components:

• VCN OCID: The VCN OCID is a unique Oracle Cloud Infrastructure identifier that has a UUID at the end. You can use this UUID or any other string that helps you identify this VCN in the device configuration and doesn't conflict with other object-group or access-list names.
• VCN CIDR
• VCN CIDR subnet mask

• For each IPSec tunnel:

  • The IP address of the Oracle IPSec tunnel endpoint (the VPN headend)
  • The shared secret

Information About Your CPE Device

You also need some basic information about the inside and outside interfaces of your on-premises device (your CPE). For a list of the required information for your particular CPE, see the links in this list: Verified CPE Devices.

By default, NAT-T is enabled on all Site-to-Site VPN IPSec tunnels. Oracle recommends leaving NAT-T enabled when configuring Site-to-Site VPN to OCI.

If your CPE is behind a NAT device, you can provide Oracle with your CPE's IKE identifier. For more information, see Overview of Site-to-Site VPN Components.

Route-Based Versus Policy-Based IPSec

The Oracle VPN headends use route-based tunnels, but can work with policy-based tunnels with some caveats. See Encryption domains for policy-based tunnels for full details.

Site-to-Site VPN Best Practices

• Configure all tunnels for every IPSec connection: Oracle deploys multiple IPSec headends for all your connections to provide high availability for your mission-critical workloads. Configuring all the available tunnels is a key part of the "Design for Failure" philosophy. (Exception: Cisco ASA policy-based configuration, which uses a single tunnel.)
• Have redundant CPEs in your on-premises locations: Each of your sites that connects with IPSec to Oracle Cloud Infrastructure should have redundant CPE devices. You add each CPE to the Oracle Cloud Infrastructure Console and create a separate IPSec connection between your dynamic routing gateway (DRG)  and each CPE. For each IPSec connection, Oracle provisions two tunnels on geographically redundant IPSec headends. Oracle may use any tunnel that is "up" to send traffic back to your on-premises network. For more information, see Routing for Site-to-Site VPN.

• Consider backup aggregate routes: If you have multiple sites connected via IPSec VPNs to Oracle Cloud Infrastructure, and those sites are connected to your on-premises backbone routers, consider configuring your IPSec connection routes with both the local site aggregate route as well as a default route.

  Note that the DRG routes learned from the IPSec connections are only used by traffic you route from your VCN to your DRG. The default route will only be used by traffic sent to your DRG whose destination IP address does not match the more specific routes of any of your tunnels.

Confirming the Status of the Connection

After you configure the IPSec connection, you can test the connection by launching an instance into the VCN and then pinging it from your on-premises network. For information about launching an instance, see Launching an Instance. To ping the instance, the VCN's security rules must allow ping traffic.

You can get the status of the IPSec tunnels in the API or Console. For instructions, see To view the status and configuration information for the IPSec tunnels.

Device Configurations

For links to the specific configuration information for each verified CPE 

https://docs.oracle.com/en-us/iaas/Content/Network/Tasks/configuringCPE.htm

Title Migrate EBS to OCI EBS Cloud Manager

https://www.oracle.com/webfolder/technetwork/tutorials/obe/cloud/compute-iaas/creating_backup_of_ebs_instance_on_oci/101_backup_oci.html

 https://apexapps.oracle.com/pls/apex/f?p=133:180:106932995936354::::wid:753

https://apexapps.oracle.com/pls/apex/r/dbpm/livelabs/view-workshop?wid=672&clear=RR,180&session=104626518666679

Deploying Oracle E-Business Suite Cloud Manager Version 20.1.1.X on Oracle Cloud Infrastructure (Doc ID 2434500.1)

Title Migrate EBS to OCI EBS Cloud Manager

• Create the Source Oracle E-Business Suite Environment
• Prepare the Source Oracle E-Business Suite Environment
• Install the Oracle E-Business Suite Cloud Backup Module
• Create a Backup with the Oracle E-Business Suite Cloud Backup Module
• Deploy an EBS Environment on Cloud Manager from a Backup

Title

Lift and Shift On-Premises EBS to OCI

• Prepare your tenancy for Oracle E-Business Suite
• Oracle E-Business Suite Cloud Manager Deployment and Configuration
• Provision Oracle E-Business Suite Environment
• Clone Oracle E-Business Suite Environment

EBS Asserter IDCS

IDCS EBS Asserter Cheat Sheet Introduction I worked with a number of customers to resolve issues with their E-Business Suite single sign-on setup using the IDCS asserter solution and saw a pattern in the misconfigurations causing these similar types of issues. In this blog, I want to share the basic EBS asserter flows to understand the runtime better and the commonly faced issues along with their resolutions. I hope this post will save you a lot of time and effort should you have any of these issues or will serve as a first-time guide to get this integration working. The starting point for anyone trying to set up EBS SSO using the asserter can be found here - https://www.oracle.com/webfolder/technetwork/tutorials/obe/cloud/idcs/ebs_asserter_obe/ebs-asserter.html Most customers are comfortable configuring the asserter and making the login/logout flows work as per the document, but when it comes to troubleshooting, a deeper understanding of the asserter flows helps. So, here are the 2 important flows : Login flow As you can see in the above figure, the EBS asserter makes a backend call to IDCS service and also to EBS DB to establish EBS session. So, make sure the asserter host can reach IDCS and EBS DB. Logout Flow This is a fairly simple flow. At the end of the logout flow, a user should land on the configured post logout URL. Important Steps During Setup Datasource connection At setup time many customers may struggle a bit with the datasource configuration step. Apart from the usual database connection parameters such as host, port and SID/Service name, following are the important things to verify when creating a datasource used by the asserter to connect to EBS DB The driver class - If you use a non-XA datasource, type oracle.apps.fnd.ext.jdbc.datasource.AppsDataSource If you are using an XA data source, type oracle.apps.fnd.ext.jdbc.datasource.AppsXADataSource and make sure that the driver jar file is copied to /lib and the admin server has been restarted. The user - EBS user with UMX|APPS_SCHEMA_CONNECT Role. For security reasons, do not use "APPS" DB user, this user has the highest privileges not required by the asserter. DBC file - A customer reported getting a NullPointerException when creating the data source. The issue turned out to be a missing DBC file on the asserter machine because the DBC file was created on the EBS system but was never copied over to the asserter machine. Asserter Bridge.properties The document does a good job of explaining all the parameters configured. Pay extra attention to - whitelist.urls - Lists the URL E-Business Suite Asserter can accept as the requestUrl parameter value. when a login session is initiated from a different page than the EBS home page, the asserter gets "requestUrl" parameter in the request and knows where to redirect upon successful authentication. The asserter keeps a list of the allowed URLs. If the white list does not contain the incoming "requestURL", the asserter will redirect the user to the configured homepage. post.logout.url - Mention the URL where a user should be redirected to upon EBS app logout. This must match the post redirect URL configured in IDCS for the asserter application. Context root and cookie path Customers may need to deploy the asserter WAR file multiple times on the same Weblogic server with different context roots ( e.g. devsso, testsso etc.) or a single WAR, but with a different context root than the default one. Make sure to match the cookie path with the new context root in Weblogic.xml before you deploy the asserter. true ASSERTERSESSIONID /ebs Common issues 1) The number one issue reported by the customers is with the WebADI templates. WebADI ( Web Applications Desktop Integrator ) provides the use of Microsoft Office applications such as Excel, Word, and Project to upload data to Oracle E-Business Suite. It initiates the login flow in an embedded browser. The authentication flow goes through as expected but the users don’t land on the expected page. So, when WebADI users click on the "upload document” button, they are taken to the EBS homepage rather than to the "user responsibilities" selection page. This happens when the asserter whitelist URLs are not configured correctly, either the WebADI specific URLs (like "/OA_HTML/BneApplicationService") are missing or there is a typo in the configuration. Another reason could be that an older version of the asserter is being used. Make sure you download the latest asserter from your IDCS tenancy and verify the whitelist URLs configured in bridge.properties. 2) User does not land on the expected URL post logout The user clicks on “logout” button in EBS application and lands on the IDCS login page instead of the one configured as a “post.logout.url” in the asserter configuration. The issue is that the asserter does not find the session cookie, but initiates IDCS logout anyway, without the necessary request data. IDCS session logout happens and the user is taken to the IDCS global session logout URL instead of the asserter application-specific post logout URL. Verify the asserter cookie path configured in "weblogic.xml" file within the asserter WAR. The cookie path must match the context root used for the asserter deployment. For example, if you used “/dev/asserter” as the context root, make sure the cookie path is set to “/dev/asserter” too. Summary Verify the asserter version and configurations mentioned in the tutorial and in this blog and your EBS SSO setup should be a cakewalk. https://www.ateam-oracle.com/post/idcs-ebs-asserter-cheat-sheet https://docs.rackspace.com/blog/set-up-oracle-access-manager-for-ebusiness-suite/

OCI Listener timeout

 The default timeout values are:

• 300 seconds for TCP listeners.

• 60 seconds for HTTP listeners.

maximum timeout value is 7200 seconds.

Oracle Database Tablespace Encryption Behavior in Oracle Cloud (Doc ID 2359020.1)

is Document Purpose Scope Details ENCRYPT_NEW_TABLESPACES Parameter Database releases 11.2.0.4 and 12.1.0.2 Database release 12.2.0.1 (with April'17 PSU - 17.3.1 / July 7th) and all future versions. Database release 12.2.0.1 (pre-April '17 PSU) Summary: Database Releases Encryption in the cloud Hybrid DR Deployment Considerations Unencrypted On-Premises and Unencrypted Cloud Primary: Unencrypted On-Premises | Standby: Encrytped Cloud Primary: Encrypted Cloud | Standby: Unencrypted On-Premises General Considerations Table: On-Premises Unencrypted Primary | Cloud Encrypted Standby Table: Cloud Encrypted Primary | On-Premises Unencrypted Standby Additional Encryption Notes References APPLIES TO: Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) Gen 2 Exadata Cloud at Customer Oracle Cloud Infrastructure - Exadata Cloud Service Linux x86-64 on Oracle Public Cloud PURPOSE The purpose of this document is to describe the behavior of Transparent Data Encryption in an Oracle Cloud environment. Oracle Database Cloud Services, including Exadata Cloud Service and Cloud@Customer, require TDE Encryption be enabled for all tablespaces by policy. SCOPE This document describes how Oracle Database Tablespace Encryption works for the following use cases: New tablespaces created in a Database deployed in Cloud Tablespaces that have been migrated to Cloud from an on-premises Database Tablespaces in a standby database in Cloud with its corresponding primary database located on-premises (i.e. a Hybrid DR configuration) This document is related to Database Releases: 11.2.0.4, 12.1.0.2, 12.2.0.1, 18c and 19c (and beyond) Applies to Oracle Database Cloud Service (PaaS) including Exadata Cloud Service, Exadata Cloud at Customer. DETAILS ENCRYPT_NEW_TABLESPACES Parameter By default, all new tablespaces created in the cloud are encrypted for all database releases. However, you can change that behavior for 11.2 and 12.1 databases. The behavior of tablespace encryption in Cloud is controlled by the initialization parameter ENCRYPT_NEW_TABLESPACES. This parameter has the following attributes: ENCRYPT_NEW_TABLESPACES=CLOUD_ONLY is the default setting. Any new tablespaces created will be transparently encrypted with the AES128 algorithm unless a different algorithm is specified on the ENCRYPTION clause in the CREATE TABLESPACE statement. For on-premises databases, tablespaces will only be encrypted if the CREATE TABLESPACE ENCRYPTION clause is specified. This is the same behavior for all database releases.(11.2, 12.1, and 12.2) ENCRYPT_NEW_TABLESPACES=ALWAYS. Any new tablespace created on-premises or in the cloud will be transparently encrypted with the AES128 algorithm unless a different encryption algorithm is specified on the CREATE TABLESPACE ENCRYPTION clause. This is the same behavior for all releases (11.2, 12.1, and 12.2). ENCRYPT_NEW_TABLESPACES=DDL. This option allows users to create tablespaces with or without encryption following the CREATE TABLESPACE command, and also users can change the encryption algorithm. Database releases 11.2.0.4 and 12.1.0.2 For both these database releases, new tablespaces created in the cloud are encrypted using AES128 algorithm. By changing the ENCRYPT_NEW_TABLESPACES parameter value to "DDL", users can create unencrypted tablespaces using CREATE TABLESPACE command. Users can also change to other encryption algorithms. So, for database releases 11.2.0.4 and 12.1.0.2, for all the 3 use cases, users can deploy, create and open unencrypted tablespaces in the cloud.  Database release 12.2.0.1 (with April'17 PSU - 17.3.1 / July 7th) and all future versions. All new 12.2 deployments in the cloud are using this 12.2 image. (Fix for Bug 25410877) Use case: New tablespace creation in cloud: Any new tablespace created in the cloud is encrypted using AES128 algorithm. Unencrypted tablespace creation is not allowed. The operation errors out. However, customers can change the encryption algorithm. Use case: Migration to cloud: Users can back up an unencrypted 12.2 CDB database to cloud (object storage) and restore it to a cloud database. They can also use RMAN RESTORE AS ENCRYPT command to restore the database as an encrypted database. Unencrypted data can also be moved to the cloud using other migration techniques including Data Guard (with TDE conversion, upgrades etc.) and GoldenGate. Note that migration to Oracle cloud using backup & restore must be a CDB for 12.1 and above. Use case: Hybrid DR: In a Hybrid DR case, customers may have an unencrypted primary database on-premises and the corresponding standby database in cloud. Users can instantiate the unencrypted standby database from on-premises to cloud using RMAN DUPLICATE, or RESTORE from the object storage. When new unencrypted tablespaces are created on the on-premises primary database, the standby database creates corresponding unencrypted tablespace via redo. However, following any failover/switchover to the cloud standby, which now becomes the new primary, if any new tablespace is created on this new primary, that will be encrypted. This poses challenges while synching back with the on-premises unencrypted standby, or after a failback. For example, if the on-premises database is not licensed for ASO, they cannot access the encrypted tablespace. Thus, for a Hybrid DR use-case, users are strongly advised to license ASO for their on-premises deployments, which allows them to use tablespace encryption, or they should not create any new tablespaces in the cloud after a role transition event. Database release 12.2.0.1 (pre-April '17 PSU) Following is the behavior for any deployments prior to pre-April PSU, or an image without patch for Bug 25410877. Use case: New tablespace creation in cloud: The creation of unencrypted tablespace completes without an error. However, after the instance is restarted, opening of those encrypted tablespaces errors out. Use case: Migration to cloud: Users can migrate unencrypted database to the cloud, but they cannot open the database. Use case: Hybrid DR: Users can deploy a hybrid DR configuration with unencrypted tablespaces. However, when they try to open the database (e.g. after a role transition or open as a Read Only standby with Active Data Guard), the operation fails. Bug 25410877 was created to address the above behavior. Summary: Database Releases Encryption in the cloud Oracle Database 11.2.0.4 and 12.1.0.2: Unencrypted databases can be deployed in cloud using migration or hybrid DR techniques, and new unencrypted tablespaces can be created. Oracle Database 12.2.0.1, pre- April'17 PSU: Unencrypted databases can be deployed using migration or hybrid DR techniques, but these cannot be opened subsequently in the cloud. Any new tablespace created in the cloud can be created as unencrypted, but subsequent reopen of the database will error out. Oracle Database 12.2.0.1, post-April'17 PSU or higher: Unencrypted databases can be deployed in cloud using migration or hybrid DR techniques. Any new tablespace created in the cloud will be encrypted. A one-off patch for Bug 25410877 is available for Oracle Database 12.2.0.1. Patch 25875415: applied on Wed Apr 26 17:47:00 UTC 2017 Unique Patch ID: 21186339 Created on 24 Apr 2017, 01:10:30 hrs PST8PDT Bugs fixed: 25410877, 25662088 The table below summarizes current behavior for Unencrypted Tablespace Support: Database Releases New Unencrypted Tablespace Creation Allowed? Open Unencrypted Tablespace? Migrated Unencrypted Tablespaces can be Opened? Hybrid DR with Unencrypted Tablespaces can be Opened? 11.2 Yes Yes Yes Yes 12.1 Yes Yes Yes Yes 12.2 (Pre-April'17 PSU) Yes No No No 12.2 (Post-April '17 PSU) and higher No Yes Yes Yes Hybrid DR Deployment Considerations Oracle strongly recommends deploying encrypted databases in both on-premises and cloud. But for many reasons, customers may choose not to encrypt their on-premises database (primary or standby). This section provides additional details and cosiderations. Unencrypted On-Premises and Unencrypted Cloud Customers can choose to deploy unencrypted databases on both on-premises and cloud. It doesn't matter which site is primary and which is standby. In this model, With Database releases 11.2 and 12.1, no data is encrypted on both sites irrespective of whether the cloud is primary or standby. However, when deployed with Database 12.2 and above, when the cloud becomes the primary, any new tablespace created WILL BE ENCRYPTED. The corresponding on-premises standby requires the same wallet used in the cloud primary to decrypt the data. Hence customers have to get ASO license. If customers do not prefer to get ASO license, then they should not create any new tablespace in the cloud. Primary: Unencrypted On-Premises | Standby: Encrytped Cloud Customers can choose to deploy unencrypted on-premises primary and encrypted standby in the cloud. In this model, All new tablespaces created on-premises will be created as unencrypted tablespaces in the cloud standby. Requires manual offline encryption of new files in the cloud. New and changed blocks are NOT encrypted on-premises (Primary). Blocks applied via recovery to the encrypted data files on the cloud standby ARE encrypted. Redo logs and archived redo logs are not encrypted on both sites. Scenario: After a role change of database release 11.2 or 12.1, the unencrypted on-premises becomes the primary site. The database is upgraded to 12.2. In this condition, before the database key is re-keyed, it is strongly recommended to decrypt tablespaces using the existing key. Otherwise, the previous key that was used to encrypt blocks is lost and hence renders already encrypted blocks to be non-decryptable and shows up as corrupted blocks. Primary: Encrypted Cloud | Standby: Unencrypted On-Premises When the cloud becomes a primary after a role switch (or) when the cloud database is deployed as a primary site and on-premises as a standby, following are to be considered: New tablespaces created in the cloud ARE encrypted on both sites. With Database 12.2, tablespaces can be manually decrypted. New and changed blocks ARE encrypted in the cloud (Primary). All redo logs and archived logs ARE encrypted in all sites. Blocks applied to on-premises standby are decrypted and stored as unencrypted data (12.2). For 11.2 or 12.1, on-premises data is stored as encrypted data. Hence ASO licensing is required to decrypt and read the data into the buffer cache. Unencrypted on-premises tablespace could contain encrypted data. ASO is required for on-premises. General Considerations Oracle strongly recommends encrypting both on-premises and cloud. Oracle supports unencrypted on-premises and encrypted cloud with Data Guard. ASO is required to encrypt/decrypt data when using database after a role transition. This configuration may lead to have unencrypted data in the cloud and encrypted data on-premises. Table: On-Premises Unencrypted Primary | Cloud Encrypted Standby This may be a typical case when doing a database cloud migration using Data Guard. Operation On-Prem Primary 11.2 Cloud Standby 11.2 On-Prem Primary 12.1 Cloud Standby 12.1 On-Prem Primary 12.2 (and higher) Cloud Standby 12.2 (and higher) Remarks DG initial Setup for on-prem Primary & cloud Standby Unencrypted Encrypted Unencrypted Encrypted Unencrypted Encrypted Standby is manually encrypted after instantiation New Tablespace Creation on-prem primary Unencrypted Unencrypted Unencrypted Unencrypted Unencrypted Unencrypted Requires manual TDE conversion for Standby DB Redo generated in on-prem primary Unencrypted Unencrypted Unencrypted Unencrypted Unencrypted Unencrypted Archived logs Unencrypted Unencrypted Unencrypted Unencrypted Unencrypted Unencrypted New and changed blocks Unencrypted Encrypted* Unencrypted Encrypted* Unencrypted Encrypted* * Redo shipped from the on-prem primary to the cloud is not encrypted Recovery in the cloud standby N/A Encrypted* N/A Encrypted* N/A Encrypted* *Redo shipped from the on-prem primary to the cloud is not encrypted Table: Cloud Encrypted Primary | On-Premises Unencrypted Standby You may get into this state in a hybrid Data Guard or in a cloud migration scenario. Operation Cloud 11.2 Primary On-Premises 11.2 Standby Cloud 12.1 Primary On-Premises 12.1 Standby Cloud 12.2 Primary (and higher) On-Premises 12.2 Standby (and higher) Remarks New Tablespace Creation in cloud primary Encrypted Encrypted Encrypted Encrypted Encrypted Encrypted ASO required for on-prem to decrypt Redo generated in cloud primary Encrypted Encrypted Encrypted Encrypted Encrypted Encrypted ASO required for on-prem to decrypt Archived logs Encrypted Encrypted Encrypted Encrypted Encrypted Encrypted ASO required for on-prem to decrypt New and changed blocks for existing unencrypted Tablespace on standby Encrypted Encrypted* Encrypted Encrypted* Encrypted Unencrypted ASO required for on-prem to decrypt and encrypt. * For 11.2 & 12.1 blocks are encrypted if redo is encrypted Recovery in the on-prem standby N/A Encrypted N/A Encrypted N/A Unencrypted data depends on whether the datafile is encrypted ASO required for on-prem Additional Encryption Notes Oracle does not support encrypting SYSTEM/SYSAUX prior to database release 19.1. The main reason is, once the SYSTEM/SYSAUX is encrypted, wallet can never be closed. Similar restriction is applicable to UNDO/TEMP tablespaces. If customers really want to encrypt SYSTEM/SYSAUX before it is officially supported, they should use SSO wallet. Starting 11gR1 onwards, even though TEMP and UNDO tablespaces were created as UNENCRYPTED tablespaces, the blocks that are part of encrypted tablespaces are stored in TEMP/UNDO are automatically encrypted. For example, if an undo block is used to store undo generated for data for an encrypted tablespace, or if a query involves data from encrypted tablespaces requires a temp block, Oracle will automatically encrypt the corresponding undo and temp blocks.

Private DNS Implementation

The purpose of this blog is to review some use cases for Private DNS and how to configure it. This blog focuses specifically in establishing a peering relationship with other DNS resolvers. It does not focus on zones or views or record creation within DNS. For more information on these topics visit our public documentation.

As you know DNS is a feature used to translate hostnames to IP addresses. If you have resources deployed in different environments and if they don’t know how to reach each other based on its hostname it creates problems.

Within OCI each VCN has its own resolver which allows you to resolve names within your VCN and the Internet. If you want to resolve names on-prem, or another VCN you will have to deploy your own DNS solution or use host names which is not scalable.

With the implementation of Private DNS you can establish peering relationship with other DNS resolvers located on-prem or other VCNs following the reference architecture. Based on rules that you define the VCN resolver will forward a request to another resolver. In the same way it can listen for requests from other resolvers.

This blog covers the following use cases:

1. DNS Peering Between VCNs in OCI
2. DNS Peering With On-Prem

Introduction

Every VCN within your tenancy has a DNS resolver that you can access and configure. To modify your resolver go to the main menu, select Networking, Virtual Cloud Networks, and select the VCN you want to work on, and then click the DNS Resolver. The name is usually the same as your VCN.

Note: To work with private DNS a user needs sufficient authority to perform this work within the Oracle Console

 

Using the diagram below lets do a simple test to ping between two VMs using its IP address and their hostname to see how the DNS resolver will convert the hostname to its IP address

Hostnames

• vmoci.asubnet.test.oraclevcn.com
• vmoci-2.bsubnet.test.oraclevcn.com

First, ping by IP to make sure that connectivity is in place

VMOCI to VMOCI-2

[opc@vmoci ~]$ ping 10.0.10.19 PING 10.0.10.19 (10.0.10.19) 56(84) bytes of data. 64 bytes from 10.0.10.19: icmp_seq=1 ttl=64 time=0.396 ms 64 bytes from 10.0.10.19: icmp_seq=2 ttl=64 time=0.342 ms 64 bytes from 10.0.10.19: icmp_seq=3 ttl=64 time=0.341 ms 64 bytes from 10.0.10.19: icmp_seq=4 ttl=64 time=0.316 ms 64 bytes from 10.0.10.19: icmp_seq=5 ttl=64 time=0.371 ms ^C --- 10.0.10.19 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4087ms rtt min/avg/max/mdev = 0.316/0.353/0.396/0.030 ms [opc@vmoci ~]$

VMOCI-2 to VMOCI

[opc@vmoci-2 ~]$ ping 10.0.10.2 PING 10.0.10.2 (10.0.10.2) 56(84) bytes of data. 64 bytes from 10.0.10.2: icmp_seq=1 ttl=64 time=0.318 ms 64 bytes from 10.0.10.2: icmp_seq=2 ttl=64 time=0.458 ms 64 bytes from 10.0.10.2: icmp_seq=3 ttl=64 time=0.322 ms 64 bytes from 10.0.10.2: icmp_seq=4 ttl=64 time=0.318 ms 64 bytes from 10.0.10.2: icmp_seq=5 ttl=64 time=0.337 ms ^C --- 10.0.10.2 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4113ms rtt min/avg/max/mdev = 0.318/0.350/0.458/0.057 ms [opc@vmoci-2 ~]$

Now lets try ping by internal FQDN or hostname to test DNS

VMOCI to VMOCI-2

[opc@vmoci ~]$ ping vmoci-2.bsubnet.test.oraclevcn.com PING vmoci-2.bsubnet.test.oraclevcn.com (10.0.10.19) 56(84) bytes of data. 64 bytes from vmoci-2.bsubnet.test.oraclevcn.com (10.0.10.19): icmp_seq=1 ttl=64 time=0.334 ms 64 bytes from vmoci-2.bsubnet.test.oraclevcn.com (10.0.10.19): icmp_seq=2 ttl=64 time=0.331 ms 64 bytes from vmoci-2.bsubnet.test.oraclevcn.com (10.0.10.19): icmp_seq=3 ttl=64 time=0.289 ms 64 bytes from vmoci-2.bsubnet.test.oraclevcn.com (10.0.10.19): icmp_seq=4 ttl=64 time=0.284 ms 64 bytes from vmoci-2.bsubnet.test.oraclevcn.com (10.0.10.19): icmp_seq=5 ttl=64 time=0.283 ms ^C --- vmoci-2.bsubnet.test.oraclevcn.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4073ms rtt min/avg/max/mdev = 0.283/0.304/0.334/0.025 ms [opc@vmoci ~]$

VMOCI-2 to VMOCI

[opc@vmoci-2 ~]$ ping vmoci.asubnet.test.oraclevcn.com PING vmoci.asubnet.test.oraclevcn.com (10.0.10.2) 56(84) bytes of data. 64 bytes from vmoci.asubnet.test.oraclevcn.com (10.0.10.2): icmp_seq=1 ttl=64 time=0.299 ms 64 bytes from vmoci.asubnet.test.oraclevcn.com (10.0.10.2): icmp_seq=2 ttl=64 time=0.297 ms 64 bytes from vmoci.asubnet.test.oraclevcn.com (10.0.10.2): icmp_seq=3 ttl=64 time=0.280 ms 64 bytes from vmoci.asubnet.test.oraclevcn.com (10.0.10.2): icmp_seq=4 ttl=64 time=0.279 ms 64 bytes from vmoci.asubnet.test.oraclevcn.com (10.0.10.2): icmp_seq=5 ttl=64 time=0.273 ms ^C --- vmoci.asubnet.test.oraclevcn.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4102ms rtt min/avg/max/mdev = 0.273/0.285/0.299/0.021 ms [opc@vmoci-2 ~]$

DNS Peering Between VCNs in OCI

Now what happen if you have multiple VCNs in your tenancy. How do you resolve hostnames? DNS resolver is local to each VCN, so the local resolver does not have any information about the resolver or hosts in any other VCN in the same region or in other region.

You can peer VCNs in the same region using a Local Peering Gateway (LPG) or using a virtual network device like a router or firewall and extend interfaces to the other VCNs. You can also peer with another VCN in a remote region using a Remote Peering Connection (RPC). Using the diagram below the next use case is to peer between the DNS resolvers on each VCN (TEST, SPOKE, and REMOTE) and perform some tests using hostnames.

The TEST VCN is basically a hub VCN and it is peered to the SPOKE VCN via an LPG and it is also peered to the REMOTE VCN via and RPC.

First make sure you have connectivity between the VCNs. Ping hosts using IP address. From the TEST VCN ping the VM in the SPOKE VCN as well as the VCN in the REMOTE VCN

To SPOKE VCN

[opc@vmoci ~]$ ping 10.0.100.2 PING 10.0.100.2 (10.0.100.2) 56(84) bytes of data. 64 bytes from 10.0.100.2: icmp_seq=1 ttl=64 time=0.196 ms 64 bytes from 10.0.100.2: icmp_seq=2 ttl=64 time=0.149 ms 64 bytes from 10.0.100.2: icmp_seq=3 ttl=64 time=0.142 ms 64 bytes from 10.0.100.2: icmp_seq=4 ttl=64 time=0.131 ms 64 bytes from 10.0.100.2: icmp_seq=5 ttl=64 time=0.127 ms ^C --- 10.0.100.2 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4080ms rtt min/avg/max/mdev = 0.127/0.149/0.196/0.024 ms

To REMOTE VCN

[opc@vmoci ~]$ ping 10.0.200.2 PING 10.0.200.2 (10.0.200.2) 56(84) bytes of data. 64 bytes from 10.0.200.2: icmp_seq=1 ttl=62 time=56.7 ms 64 bytes from 10.0.200.2: icmp_seq=2 ttl=62 time=56.7 ms 64 bytes from 10.0.200.2: icmp_seq=3 ttl=62 time=56.6 ms 64 bytes from 10.0.200.2: icmp_seq=4 ttl=62 time=56.6 ms 64 bytes from 10.0.200.2: icmp_seq=5 ttl=62 time=56.6 ms ^C --- 10.0.200.2 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 56.686/56.703/56.730/0.213 ms

As you can see it works above the ping results are working. Now if the same test is performed using the hostname it does not work as shown below

To SPOKE VCN

[opc@vmoci ~]$ ping vmoci-spoke.ssubnet.spoke.oraclevcn.com ping: vmoci-spoke.ssubnet.spoke.oraclevcn.com: Name or service not known   [opc@vmoci ~]$ nslookup vmoci-spoke.ssubnet.spoke.oraclevcn.com Server:     169.254.169.254 Address:    169.254.169.254#53   ** server can't find vmoci-spoke.ssubnet.spoke.oraclevcn.com: NXDOMAIN   [opc@vmoci ~]$

To REMOTE VCN

[opc@vmoci ~]$ ping vmoci-remote.rsubnet.remote.oraclevcn.com ping: vmoci-remote.rsubnet.remote.oraclevcn.com: Name or service not known   [opc@vmoci ~]$ nslookup vmoci-remote.rsubnet.remote.oraclevcn.com Server:     169.254.169.254 Address:    169.254.169.254#53   ** server can't find vmoci-remote.rsubnet.remote.oraclevcn.com: NXDOMAIN   [opc@vmoci ~]$

One way to get the test above to work is if you edit the host file and add the two entries below. It is a workaround, but it is not scalable.

vmoci-spoke.ssubnet.spoke.oraclevcn.com		        10.0.100.2
vmoci-remote.rsubnet.remote.oraclevcn.com		10.0.200.2

Another solution is to setup Private DNS between the VCNs so DNS is dynamic and there is no need to update any host file

To start the configuration

• Log into the Oracle console
• From the main menu, select Networking, select Virtual Cloud Network, select the your VCN
• Click the DNS Resolver

• On the next screen select Endpoints from the menu on the left
• Create a Listener endpoint, Click Create Endpoint
  • Give it a name
  • Select a subnet within your VCN
  • Select type – Listening
  • Click Create Endpoint

• Create a Forwarding endpoint, Click Create Endpoint
  • Give it a name
  • Select a subnet within your VCN
  • Select type – Forwarding
  • Click Create Endpoint
• Once the two endpoints are created you should have something like this

• Repeat the same process for the SPOKE and REMOTE VCN resolvers

SPOKE VCN

REMOTE VCN

Now that all the resolver have Listening and Forwarding endpoints the next step is to create some rules to forward DNS queries to the respective resolver.

Note: A resolver provides responses in this order:

1. by checking zones in your custom private views
2. then in its default view
3. then by checking rules
4. and finally by using internet DNS.

• Go back to the TEST VCN (main VCN)
• Click DNS Resolver
• Click Rules from the menu on the left - Here you will create rules to tell the DNS resolver where to forward the request for a particular domain
• Click Manage Rules
• Create a rule for each VCN. The rule condition could be by CIDR block, domain, or both. For this exercise I’m going to use domain. The first rule will be for domain spoke.oraclevcn.com on the SPOKE VCN and the second for remote.oraclevcn.com on the REMOTE VCN
  • Condition – Domains
  • Domain - spoke.oraclevcn.com
  • Source Endpoint – FWD
  • Destination IP address – This will be the Listening IP address of the SPOKE VCN DNS Resolver 10.0.100.3
• Add another rule for the remote.oraclevcn.com domain
• Your rules should look like this

• Next go to the SPOKE and REMOTE VCN (peered VCNs) and create similar rules for the TEST VCN domain as follow

Now that the rules to forward DNS requests are set between the 3 VCNs lets try to ping the VMs by hostname again as our previous test failed

To SPOKE VCN

[opc@vmoci ~]$ ping vmoci-spoke.ssubnet.spoke.oraclevcn.com ping: vmoci-spoke.ssubnet.spoke.oraclevcn.com: Name or service not known   [opc@vmoci ~]$ nslookup vmoci-spoke.ssubnet.spoke.oraclevcn.com Server:     169.254.169.254 Address:    169.254.169.254#53   ** server can't find vmoci-spoke.ssubnet.spoke.oraclevcn.com: NXDOMAIN   [opc@vmoci ~]$

To REMOTE VCN

[opc@vmoci ~]$ ping vmoci-remote.rsubnet.remote.oraclevcn.com ping: vmoci-remote.rsubnet.remote.oraclevcn.com: Name or service not known   [opc@vmoci ~]$ nslookup vmoci-remote.rsubnet.remote.oraclevcn.com Server:     169.254.169.254 Address:    169.254.169.254#53   ** server can't find vmoci-remote.rsubnet.remote.oraclevcn.com: NXDOMAIN   [opc@vmoci ~]$

It failed again as you can see above. Why?

By checking the security list on the VCNs I found that I’m not allowing DNS traffic between the VCNs, only ICMP was allowed. Based on your security policy make sure you allow traffic for the listener as well as the forwarding. I added the rules accordingly to the ingress as the egress is allowing all the traffic.

Note: Make sure you security list or network security groups allows traffic for DNS which uses TCP/UDP port 53

TEST VCN – Is allowing the traffic already

SPOKE VCN & REMOTE VCN

Now that the security list is allowing the traffic try the ping test by name again. Bingo, our pings are successful

To SPOKE VCN

[opc@vmoci ~]$ nslookup vmoci-spoke.ssubnet.spoke.oraclevcn.com Server:     169.254.169.254 Address:    169.254.169.254#53   Non-authoritative answer: Name:   vmoci-spoke.ssubnet.spoke.oraclevcn.com Address: 10.0.100.2   [opc@vmoci ~]$ ping vmoci-spoke.ssubnet.spoke.oraclevcn.com PING vmoci-spoke.ssubnet.spoke.oraclevcn.com (10.0.100.2) 56(84) bytes of data. 64 bytes from 10.0.100.2 (10.0.100.2): icmp_seq=1 ttl=64 time=0.209 ms 64 bytes from 10.0.100.2 (10.0.100.2): icmp_seq=2 ttl=64 time=0.129 ms 64 bytes from 10.0.100.2 (10.0.100.2): icmp_seq=3 ttl=64 time=0.129 ms 64 bytes from 10.0.100.2 (10.0.100.2): icmp_seq=4 ttl=64 time=0.114 ms 64 bytes from 10.0.100.2 (10.0.100.2): icmp_seq=5 ttl=64 time=0.179 ms ^C --- vmoci-spoke.ssubnet.spoke.oraclevcn.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4073ms rtt min/avg/max/mdev = 0.114/0.152/0.209/0.036 ms [opc@vmoci ~]$

To REMOTE VCN

[opc@vmoci ~]$ nslookup vmoci-remote.rsubnet.remote.oraclevcn.com Server:     169.254.169.254 Address:    169.254.169.254#53   Non-authoritative answer: Name:   vmoci-remote.rsubnet.remote.oraclevcn.com Address: 10.0.200.2   [opc@vmoci ~]$ ping vmoci-remote.rsubnet.remote.oraclevcn.com PING vmoci-remote.rsubnet.remote.oraclevcn.com (10.0.200.2) 56(84) bytes of data. 64 bytes from 10.0.200.2 (10.0.200.2): icmp_seq=1 ttl=62 time=56.7 ms 64 bytes from 10.0.200.2 (10.0.200.2): icmp_seq=2 ttl=62 time=56.7 ms 64 bytes from 10.0.200.2 (10.0.200.2): icmp_seq=3 ttl=62 time=56.7 ms 64 bytes from 10.0.200.2 (10.0.200.2): icmp_seq=4 ttl=62 time=56.7 ms 64 bytes from 10.0.200.2 (10.0.200.2): icmp_seq=5 ttl=62 time=56.7 ms ^C --- vmoci-remote.rsubnet.remote.oraclevcn.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 56.703/56.722/56.752/0.261 ms [opc@vmoci ~]$

Perform the same test from the SPOKE and REMOTE VCN to the TEST VCN

From SPOKE VCN to TEST VCN

[opc@vmoci-spoke ~]$ nslookup vmoci.asubnet.test.oraclevcn.com Server:     169.254.169.254 Address:    169.254.169.254#53   Non-authoritative answer: Name:   vmoci.asubnet.test.oraclevcn.com Address: 10.0.10.2   [opc@vmoci-spoke ~]$ ping vmoci.asubnet.test.oraclevcn.com PING vmoci.asubnet.test.oraclevcn.com (10.0.10.2) 56(84) bytes of data. 64 bytes from 10.0.10.2 (10.0.10.2): icmp_seq=1 ttl=64 time=0.141 ms 64 bytes from 10.0.10.2 (10.0.10.2): icmp_seq=2 ttl=64 time=0.119 ms 64 bytes from 10.0.10.2 (10.0.10.2): icmp_seq=3 ttl=64 time=0.124 ms 64 bytes from 10.0.10.2 (10.0.10.2): icmp_seq=4 ttl=64 time=0.122 ms 64 bytes from 10.0.10.2 (10.0.10.2): icmp_seq=5 ttl=64 time=0.169 ms ^C --- vmoci.asubnet.test.oraclevcn.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4107ms rtt min/avg/max/mdev = 0.119/0.135/0.169/0.018 ms [opc@vmoci-spoke ~]$

From REMOTE VCN to TEST VCN

[opc@vmoci-remote ~]$ nslookup vmoci.asubnet.test.oraclevcn.com Server:     169.254.169.254 Address:    169.254.169.254#53   Non-authoritative answer: Name:   vmoci.asubnet.test.oraclevcn.com Address: 10.0.10.2   [opc@vmoci-remote ~]$ ping vmoci.asubnet.test.oraclevcn.com PING vmoci.asubnet.test.oraclevcn.com (10.0.10.2) 56(84) bytes of data. 64 bytes from 10.0.10.2 (10.0.10.2): icmp_seq=1 ttl=62 time=56.6 ms 64 bytes from 10.0.10.2 (10.0.10.2): icmp_seq=2 ttl=62 time=56.6 ms 64 bytes from 10.0.10.2 (10.0.10.2): icmp_seq=3 ttl=62 time=56.6 ms 64 bytes from 10.0.10.2 (10.0.10.2): icmp_seq=4 ttl=62 time=56.6 ms 64 bytes from 10.0.10.2 (10.0.10.2): icmp_seq=5 ttl=62 time=56.7 ms ^C --- vmoci.asubnet.test.oraclevcn.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 56.674/56.687/56.717/0.016 ms [opc@vmoci-remote ~]$

DNS Peering With On-Prem

In this use case your environment in OCI has to interact with on-prem. How the on-prem DNS will resolve hosts in OCI and vice versa?

For this test the on-prem location is connected to OCI via VPN Connect per diagram below

On-prem DNS server also has a Listening and Forwarding endpoint that can be used to peer with the DNS resolver in OCI, the process is similar to what was implemented in the previous use case for VCNs within OCI.

Test connectivity to make sure the path is in place. From VMOCI in the TEST VCN ping the VMOP VM on-prem by IP, as seen below it works

[opc@vmoci ~]$ ping 10.0.0.35 PING 10.0.0.35 (10.0.0.35) 56(84) bytes of data. 64 bytes from 10.0.0.35: icmp_seq=1 ttl=61 time=58.2 ms 64 bytes from 10.0.0.35: icmp_seq=2 ttl=61 time=58.1 ms 64 bytes from 10.0.0.35: icmp_seq=3 ttl=61 time=58.1 ms 64 bytes from 10.0.0.35: icmp_seq=4 ttl=61 time=58.5 ms 64 bytes from 10.0.0.35: icmp_seq=5 ttl=61 time=58.2 ms ^C --- 10.0.0.35 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4005ms rtt min/avg/max/mdev = 58.114/58.275/58.572/0.345 ms

Perform the same test using the hostname instead of the IP addres, it fails

[opc@vmoci ~]$ ping vmop.trust.onprem.oraclevcn.com ping: vmop.trust.onprem.oraclevcn.com: Name or service not known [opc@vmoci ~]$ [opc@vmoci ~]$ nslookup vmop.trust.onprem.oraclevcn.com ;; connection timed out; no servers could be reached

Also check connectivity to the on-prem DNS listener

[opc@vmoci ~]$ ping 10.0.0.42 PING 10.0.0.42 (10.0.0.42) 56(84) bytes of data. 64 bytes from 10.0.0.42: icmp_seq=2 ttl=61 time=61.1 ms 64 bytes from 10.0.0.42: icmp_seq=3 ttl=61 time=60.9 ms 64 bytes from 10.0.0.42: icmp_seq=4 ttl=61 time=59.6 ms 64 bytes from 10.0.0.42: icmp_seq=5 ttl=61 time=60.3 ms 64 bytes from 10.0.0.42: icmp_seq=6 ttl=61 time=58.8 ms ^C --- 10.0.0.42 ping statistics --- 6 packets transmitted, 5 received, 16% packet loss, time 5013ms rtt min/avg/max/mdev = 58.874/60.185/61.127/0.831 ms [opc@vmoci ~]$

As connectivity is in place, the next step is to configure the TEST VCN resolver to send requests to the on-prem DNS.

• Go to the TEST VCN resolver
• Add a rule for on-prem for domain onprem.oraclevcn.com. After adding this rule the rules for the TEST VCN look like

Repeat the ping test by host name. Bingo it works

[opc@vmoci ~]$ nslookup vmop.trust.onprem.oraclevcn.com Server:     169.254.169.254 Address:    169.254.169.254#53   Non-authoritative answer: Name:   vmop.trust.onprem.oraclevcn.com Address: 10.0.0.35   [opc@vmoci ~]$ ping vmop.trust.onprem.oraclevcn.com PING vmop.trust.onprem.oraclevcn.com (10.0.0.35) 56(84) bytes of data. 64 bytes from 10.0.0.35 (10.0.0.35): icmp_seq=1 ttl=61 time=58.3 ms 64 bytes from 10.0.0.35 (10.0.0.35): icmp_seq=2 ttl=61 time=58.8 ms 64 bytes from 10.0.0.35 (10.0.0.35): icmp_seq=3 ttl=61 time=58.8 ms 64 bytes from 10.0.0.35 (10.0.0.35): icmp_seq=4 ttl=61 time=58.1 ms 64 bytes from 10.0.0.35 (10.0.0.35): icmp_seq=5 ttl=61 time=58.8 ms ^C --- vmop.trust.onprem.oraclevcn.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 58.171/58.618/58.862/0.418 ms [opc@vmoci ~]$

Now ping VMOCI VM from on-prem by hostname

[opc@vmop ~]$ ping vmoci.asubnet.test.oraclevcn.com PING vmoci.asubnet.test.oraclevcn.com (10.0.10.2) 56(84) bytes of data. 64 bytes from 10.0.10.2 (10.0.10.2): icmp_seq=1 ttl=62 time=58.9 ms 64 bytes from 10.0.10.2 (10.0.10.2): icmp_seq=2 ttl=62 time=58.3 ms 64 bytes from 10.0.10.2 (10.0.10.2): icmp_seq=3 ttl=62 time=58.7 ms 64 bytes from 10.0.10.2 (10.0.10.2): icmp_seq=4 ttl=62 time=59.1 ms 64 bytes from 10.0.10.2 (10.0.10.2): icmp_seq=5 ttl=62 time=58.3 ms ^C --- vmoci.asubnet.test.oraclevcn.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4005ms rtt min/avg/max/mdev = 58.313/58.685/59.105/0.348 ms [opc@vmop ~]$ [opc@vmop ~]$ nslookup vmoci.asubnet.test.oraclevcn.com Server:     169.254.169.254 Address:    169.254.169.254#53   Non-authoritative answer: Name:   vmoci.asubnet.test.oraclevcn.com Address: 10.0.10.2   [opc@vmop ~]$

Summary

As demonstrated in this blog with the use of Private DNS now you can easily implement a hybrid DNS solution to resolve hostnames across multiple VCNs in the same region or across regions as well with on-prem.

In this blog I basically tested Private DNS resolution between the TEST VCN and its directly connected VCNs and on-prem. If you have a similar environment and you would like DNS resolution between the REMOTE VCN and the SPOKE VCN or between on-prem and the SPOKE VCN then make sure connectivity, DNS rules, and security lists are in place to allow this traffic.

Note: DNS resolution between on-prem and the REMOTE VCN is not possible because by design on-prem can’t connect to a VCN connected via a Remote Peering Connection (RPC).

When implementing Private DNS, keep in mind the following points during configuration and design:

1. Connectivity should be in place between DNS resolvers
2. Each DNS resolver should have a Listening and Forwarding endpoint
3. Create the necessary rules to forward the request to the proper DNS resolver
4. Make sure any security list, network security group, or firewall in the path is opened to allow DNS traffic which uses UDP/TCP port 53

Note: During the implementation I noticed that my changes will not take effect immediately. This is usually caused by the TTL as the information is cached. Also noticed that after a change if I ping a host by hostname it will not resolve, then try it again after couple seconds and then it works. So there is a small lag when doing the initial configuration.

 

 https://www.ateam-oracle.com/private-dns-implementation