Introduction

The following article describes considerations and recommendations for setting up Domain Name Service (DNS) when deploying Oracle Database@Azure. The goal of this article is to provide recommended technical guidance to enhance customer experience for a stable cloud environment. The article assumes that the reader has a basic understanding of Oracle Database technologies and Azure Compute and networking. As parts of your preparation and architecture design process refer to the following article for more information, see DNS for on-premises and Azure - Cloud Adoption Framework

Scenario

You want to migrate your on-premises Oracle databases to Oracle Database@Azure. During the migration, you need to ensure proper name resolution both on-premises and in Azure. Oracle Data Guard will be used for the data migration. After migration, you aim to maintain reliable name resolution using your hybrid connection without a custom DNS zone with applications that Oracle Database@Azure will communicate with.

DNS Deployment options for Oracle Database@Azure

The option that can be set up to satisfy the mentioned scenario and requirements would be to extend DNS infrastructure from on-premises into Azure with an IaaS (Infrastructure as a Service) solution.

DNS prerequisites before you deploy Oracle Database@Azure in Azure

Review the different DNS deployment scenario workflows with Oracle Database@Azure

Oracle Database@Azure default DNS setup workflow

Oracle Database@Azure custom DNS setup workflow

Oracle Database@Azure external DNS setup workflow

• If you don't select to use a custom DNS domain, the Oracle Exadata uses the default domain, oraclevcn.com. The oraclvcn.com zone is auto provisioned in Azure as a private DNS zone linked to the Oracle Database@Azure virtual network. After Oracle Database@Azure is deployed, records from OCI begin to auto populate the oraclevcn.com private DNS zone in Azure.
• Private view and private zone must be created before deploying the Exadata Cluster if you plan to use a custom DNS zone such as contoso.com with Oracle Database@Azure. Read this article for details Private DNS Resolvers. The private resolver created in the OCI Private view is not authoritative. It is only applied for Oracle Database@Azure for name resolution external to the OCI VCN compartment.
• Forwarding to another DNS server should be set up beforehand in the OCI DNS console if your deployment scenario requires this. For details, see DNS in your Virtual Cloud Network.
• Private zone's name can't have more than four labels. For example, a.b.c.d (oradb.prod.contoso.com) is allowed while a.b.c.d.e (oradb.sales.prod.contoso.com) isn't. This constraint is only when using a custom DNS zone such as contoso.com to provision the database cluster. Review the following Oracle article DNS in your Virtual Cloud Network.
• When provisioning an Exadata VM Cluster using Private DNS feature, Exadata needs to create reverse DNS zones in the compartment of Exadata virtual machine (VM) Cluster. If the compartment defines tags or tag defaults, other policies related to managing tags are needed. For details, see:
• Required Permissions for Working with Defined Tags
• Required Permissions for Working with Tag Defaults

Custom DNS

Let us address the scenario, which is an Oracle database migration from on-premises to Azure. There are various tools and methods to migrate the Oracle database such as Oracle Data Guard as an example. Configuration details of Oracle Data Guard are outside the scope of this article.

Before configuring Oracle Data Guard for data replication from an on-premises database to Azure, it’s essential to ensure the on-premises database can resolve the FQDN of the Oracle Database@Azure instance. The Oracle Database@Azure cluster’s client network advertises three IPs, which are linked to a Single Client Access Name (SCAN) address. This SCAN address provides service access to clients connecting to Oracle Database@Azure and offers redundancy for the cluster. In the event of a node failure within the cluster, the SCAN FQDN maintains uninterrupted client connections during the failover process as the new primary node becomes active. This setup negates the necessity for manual DNS round-robin configurations, which were common in traditional on-premises Oracle database deployments.

Proper resolution of the SCAN FQDN is a prerequisite for establishing direct connectivity from the on-premises database to the Oracle Database@Azure instance in Azure. The name resolution from Oracle Database@Azure in Azure to resources in the datacenter would have to function. This connection could be facilitated through Azure ExpressRoute or a high-bandwidth VPN. Additionally, it’s crucial to confirm that Oracle Database@Azure can resolve the on-premises Oracle database using the custom DNS servers deployed in Azure. Once name resolution and network connectivity are assured, Oracle Data Guard can be configured to initiate data migration using the Oracle Database@Azure SCAN FQDN on TCP (Transmission Control Protocol) port 1521. The data migration can begin and once completed the eventual cutover to Azure from the legacy Oracle database.

The following diagram represents the implementation of a DNS solution with VMs (Virtual Machines) or appliances from the Azure marketplace with the network path that DNS name resolution would follow across your Azure Landing Zone (ALZ).

The VMs can be either Windows, Linux, FreeBSD, and active directory domain controllers with integrated DNS for name resolution. These systems in Azure would be integrated into the overall DNS infrastructure of your organization. The SCAN FQDN, on-premises databases, and on-premises legacy applications would be registered on DNS servers deployed across the enterprise.

Once the migration is complete applications like NFS shares, web servers, or an AKS (Azure Kubernetes Service) cluster in either Azure or the on-premises datacenter receives a client request initiating a DNS query. The DNS server returns the response of the SCAN FQDN associated with the Oracle Database@Azure cluster back to the application that initiated the query. This facilitates the connection to the database for either reading or writing operations.

You can query the SCAN FQDN from the oraclevcn.com DNS zone or apply your domain and naming convention in your DNS servers as a CNAME record. An example on how to create a CNAME in a Windows DNS server is in this article To add an alias (CNAME) resource record in a DNS zone.

If the application resides on Azure, it queries the DNS servers deployed in the custom DNS servers defined in the Azure virtual network. The on-premises applications would use the on-premises DNS servers defined in the datacenter.

Review the following recommendations to ensure this implementation supports both reliability and redundancy. 

• A DNS solution on IaaS deployed in Azure must have the Azure Wire Server 168.63.129.16 set as a conditional forwarder for proper name resolution with Azure Private DNS zones. Virtual network links needs to connect the Azure Private DNS zone with the virtual network that has the IaaS DNS resources. This includes zones such as oraclevcn.com and other private zones supporting other Azure services. Details about the Azure Wire Server are in this article What is IP 168.63.129.16What is IP 168.63.129.16. 
• Virtual network links need to be created for each Azure Private DNS zone and connected to the virtual network where the DNS server VMs or the DNS appliance resides for proper name resolution to work.
• Deploy at a minimum of two VMs in the same virtual network and same Azure region. Use a VMSS (Virtual Machine Scale Sets) Flex for redundancy and configure DNS settings on virtual networks to use the IPs of the custom DNS servers. Read recommendations for redundancy in this article Recommendations for designing redundancy

Please look for updates to this article and design patterns on Microsoft Learn and Microsoft Architecture Center.

Next Steps

Onboard Oracle Database@Azure

Network Planning for Oracle Database@Azure

Groups and Roles for Oracle Database@Azure

Overview of Provisioning