Resolve DNS Records Seamlessly in OCI Multicloud Architectures
For workloads running in Oracle Cloud Infrastructure (OCI) multicloud architectures, services running in Azure can seamlessly resolve DNS records hosted in OCI.
Architecture
This architecture supports multicloud workloads running in Oracle Cloud Infrastructure (OCI) and Microsoft Azure in different topologies, including split-stack, workload mobility, app to app integration, SaaS to platform integration, and data analytic pipeline.
A hub VNet hosts the DNS forwarding rule set. By using Azure DNS Private Resolver, the spoke VNets, which are linked to the DNS forwarding rule set, resolve the OCI domains. This simplifies the DNS design in two ways:
- There is no need to manually update OCI records in Azure.
- A centralized DNS forwarding rule set can serve different Azure spoke VNets.
This architecture assumes that the connection between OCI and Azure has been established with Oracle Interconnect for Microsoft Azure.
The following diagram illustrates the architecture:
dns-resolve-oci-azure-oracle.zip
The architecture has the following Oracle components:
- Tenancy
A tenancy is a secure and isolated partition that Oracle sets up within Oracle Cloud when you sign up for Oracle Cloud Infrastructure. You can create, organize, and administer your resources in Oracle Cloud within your tenancy. A tenancy is synonymous with a company or organization. Usually, a company will have a single tenancy and reflect its organizational structure within that tenancy. A single tenancy is usually associated with a single subscription, and a single subscription usually only has one tenancy.
- Region
An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).
- Virtual cloud network (VCN) and subnets
A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.
- Route table
Virtual route tables contain rules to route traffic from subnets to destinations outside a VCN, typically through gateways.
- Security list
For each subnet, you can create security rules that specify the source, destination, and type of traffic that must be allowed in and out of the subnet.
- Network security group (NSG)
Network security group (NSG) acts as a virtual firewall for your cloud resources. With the zero-trust security model of Oracle Cloud Infrastructure, all traffic is denied, and you can control the network traffic inside a VCN. An NSG consists of a set of ingress and egress security rules that apply to only a specified set of VNICs in a single VCN.
- Dynamic routing gateway (DRG)
The DRG is a virtual router that provides a path for private network traffic between VCNs in the same region, between a VCN and a network outside the region, such as a VCN in another Oracle Cloud Infrastructure region, an on-premises network, or a network in another cloud provider.
- Private DNS resolvers
A private DNS resolver answers DNS queries for a VCN. A private resolver can be configured to use views and zones as well as conditional forwarding rules to define how to respond to DNS queries.
- Listening Endpoint
A listening endpoint receives queries from within the VCN or from other VCN resolvers, from the DNS of other cloud service providers (such as AWS, GCP, or Azure), or from the DNS of your on-premises network. Once created, no further configuration is needed for a listening endpoint.
- Oracle Interconnect for Microsoft Azure
Oracle Interconnect for Microsoft Azure creates a network link, which is a high performance, low-latency, low-jitter private tunnel connection for network traffic between OCI and Microsoft Azure. Oracle has partnered with Microsoft to offer this connection in a designated set of OCI regions located around the world.
When you sign up for Oracle Database Service for Microsoft Azure, the service configures the private connection to your database resources as part of the account linking process.
The architecture has the following Microsoft Azure components:
- Virtual network (VNet) and subnet
A VNet is a virtual network that you define in Microsoft Azure. A VNet can have multiple non-overlapping CIDR block subnets that you can add after you create the VNet. You can segment a VNet into subnets, which can be scoped to a region or to an availability zone. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VNet. Use a VNet to logically isolate your Azure resources at the network level.
- DNS Private resolver
Azure Private DNS provides a reliable and secure DNS service for your virtual networks. Azure Private DNS manages and resolves domain names in the virtual network without the need to configure a custom DNS solution.
- DNS forwarding rule set
A DNS forwarding rule set enables you to specify one or more custom DNS servers to answer queries for specific DNS namespaces. The individual rules in a rule set determine how these DNS names are resolved. Rule sets can also be linked to one or more virtual networks, enabling resources in the VNets to use the forwarding rules that you configure.
- Outbound endpoint
The resolver's outbound endpoint processes DNS queries based on a DNS forwarding rule set.
- Virtual Network Links
When you link a rule set to a virtual network, resources within that virtual network use the DNS forwarding rules enabled in the rule set. The linked virtual networks aren't required to peer with the virtual network where the outbound endpoint exists, but these networks can be configured as peers.
Recommendations
Your requirements might differ from the architecture described here.
- Security
Assign a network security group (NSG) to the OCI listening endpoint and configure the security group following a deny-all security posture, allowing only the Azure outbound IP and DNS port UDP:53.
- High availability
This architecture shows a simplified Azure design. In a production deployment, make sure your design follows Azure high availability best practices. In OCI, we recommend you use a regional subnet for the OCI DNS listening endpoint.
- Architecture
Create dedicated subnets in Azure and OCI for hosting the DNS outbound endpoint and the listening endpoint. For advanced OCI network designs, consider using a private OCI DNS resolver with customized private views.
Considerations
When implementing a multicloud DNS resolution architecture, note that the total cost of the DNS architecture depends on the cost of the following Azure resources:
- Azure DNS Private Resolver outbound endpoint
- Azure DNS Private Resolver rulesets
- DNS queries/month
Deploy
- Create a listening endpoint in the DNS resolver in the OCI VCN.
- Create a DNS private resolver in the Azure hub VNet and configure an outbound endpoint.
- Create a DNS forwarding rule set.
- Set the outbound endpoint created in previous step.
- Create virtual network links to the spoke VNets.
- Configure the rules from the table below. Note that these are commonly required rules and that additional rules may be needed for specific OCI services.
| Domain name* | Destination IP: Port | Use |
|---|---|---|
| <oci-region-identifier>.oraclevcn.com. | OCI Listening Endpoint IP. Port 53 | VCN DNS host names |
| <oci-region-identifier>.oraclecloudapps.com. | OCI Listening Endpoint IP. Port 53 | Oracle Tools (Apex, DB Actions) |
| <oci-region-identifier>.oraclecloud.com. | OCI Listening Endpoint IP. Port 53 | Database Connection |
*See Regions and Availability Domains for the latest information about regions and availability domains.