Oracle Database at Azure provides the capability to run Oracle Database Services from OCI to run natively in Azure Datacenters with native integration to Azure Services. DNS configuration plays a crucial role in having Azure and OCI services interact.
At this time of writing this blog, following services are available in Oracle Database@Azure. For availability of services by region, refer to this documentation.
- Oracle Autonomous Database – Serverless
- Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D)
- Oracle Exascale Database Service
- Oracle Base Database Service.
- Oracle Golden Gate
In this blog we will go through design of DNS leveraging Network Anchors for Oracle Database@Azure services. This blog provides you the core usecase of DNS resolution between OCI and Azure.
Network Anchor
Network Anchor provides the networking bridge between Azure and OCI, integrating Azure networking constructs such as VNets, subnets, and DNS with OCI networking constructs including VCNs, subnets, and DNS. It enables seamless workload communication and consistent network management across the multicloud environment. Network Anchors also provide DNS integration capabilities, including DNS listening and forwarding endpoints, to support name resolution across Azure and OCI
Network Anchors provide capability to create both the forwarding and listening endpoints for the DNS during the provisioning. You can follow the detailed documentation on creating Network Anchors.
The screenshot provides a configuration example that will provision a VCN with Private DNS Listener and Forwarder endpoints, each endpoint will have an attached Network Security Group (NSG) enabling the connectivity to and from the endpoints, the private DNS zones used by the service.
If the “Replicate DNS Private zones during DB creation” is checked, the DNS zones will be synchronized to Azure and linked to the VNET where the Network Anchor was created.
DNS Resolution
The DNS resolution path in Oracle Database@Azure varies based on the database service type and how the Network Anchor is enabled
Option 1: Database Services with Direct Network Anchor based DNS Resolution
For database services that support direct Network Anchor integration, DNS resolution is handled within the same Azure delegated subnet used for service deployment.
The Oracle Base Database Service and Oracle GoldenGate Service are enabled with Network Anchors by default. During service provisioning, these services can establish the DNS handshake directly within the delegated subnet. As a result, a single delegated subnet serves a dual purpose:
- Hosts the Base Database and GoldenGate service resources
- Provides DNS resolution for connectivity between Azure-based applications and Oracle Database@Azure (Base DB and Golden Gate) services
This model simplifies network design by eliminating the need for separate DNS infrastructure while maintaining private, secure name resolution across Azure and OCI.
By leveraging Network Anchors in this configuration, Oracle Database@Azure services can perform DNS resolution and data communication over the same private network path, ensuring consistent routing and reduced operational complexity.
The following reference architecture illustrates DNS implementation for Oracle Base Database Service and Oracle GoldenGate Service using Network Anchors.
After the provisioning of Network Anchor, we will have two OCI DNS endpoints provisioned Both the Listening and Forwarding endpoints are displayed on both Azure and OCI console. On Azure portal, it will be displayed on overview page. On OCI console, it will be displayed on private resolver associated with VCN
End-to-End DNS and Connectivity Flow: Azure VM to Oracle Base Database
The following illustrates the end-to-end interaction between an application running on an Azure Virtual Machine and an Oracle Base Database deployed using Oracle Database@Azure:
- The Azure virtual machine initiates a DNS lookup to resolve the hostname of the Oracle Base Database.
- Azure forwards the DNS request to the OCI DNS listening endpoint exposed through the Network Anchor.
- The OCI VCN private resolver processes the request and returns the private IP address of the database service.
- Using the resolved IP address, the Azure virtual machine establishes a direct, private network connection to the Oracle Base Database over the Oracle-managed multicloud connectivity.
Option 2: Database Services leveraging Network Anchor as Centralized DNS Hub
This option is supported across all Oracle Database@Azure services, including Exadata Database Service on Dedicated Infrastructure, Exascale Database Service, Autonomous Database Service – Serverless, Base Database Service, and Oracle GoldenGate Service.
In this configuration, the Network Anchor is used as a centralized DNS hub for name resolution across Oracle Database@Azure services. Azure workloads that need to connect to any Oracle Database@Azure service send DNS queries to the DNS listening endpoint exposed by the Network Anchor.
The DNS request is processed by the OCI VCN private resolver, which resolves the hostname and returns the private IP address of the target service. The VCN gains access to the required DNS records using one of the following approaches:
- Private View Association: Attaching the private DNS view of all VCNs associated with delegated subnets within the region
- Local Peering: Establishing local peering between the VCN hosting Oracle Database@Azure services and the VCN hosting the DNS listening and forwarding endpoints
This centralized DNS model simplifies DNS governance and enables consistent resolution behavior across multiple Oracle Database@Azure services.
The following reference architecture illustrates DNS implementation for Oracle Database@Azure services using Network Anchors as a centralized DNS hub.
Conclusion
DNS is a critical but often overlooked component of multicloud architectures. With Oracle Database@Azure, Network Anchors provide a structured, secure, and enterprise-ready approach to DNS resolution that aligns seamlessly with the underlying network connectivity. Whether using direct DNS within a delegated subnet or a centralized DNS hub model, customers can choose the pattern that best fits their operational and governance requirements. In all cases, DNS resolution and data traffic follow the same private, Oracle-managed network paths between Azure and OCI ensuring low latency, strong isolation, and consistent performance. This design allows organizations to adopt Oracle Database@Azure with confidence, without rearchitecting existing DNS or networking foundations.