How to use OCI DNS listening endpoints, private DNS views, DRG remote peering, and region-aware routing to extend host-local split DNS for Recovery Service across OCI regions

Introduction

In the previous blog, we focused on a simpler pattern: a single database environment in OCI, typically associated with a single VCN. In that design, dnsmasq on the database host implemented split DNS so that Autonomous Recovery Service-related queries followed the OCI DNS path, while all other queries continued to use customer DNS.

This follow-up expands the scope to an inter-region design. The protected database environment is in a source OCI region, while the Recovery Service DNS context and backup connectivity target are in a different target OCI region. The same pattern can also apply when PROD, DEV, and UAT use separate VCNs or when a centralized backup architecture must span multiple subscribed OCI regions.

The main idea is simple: the database host still sends DNS queries to local dnsmasq, but dnsmasq must forward Recovery Service names to the OCI DNS listening endpoint that represents the correct target-region Recovery Service DNS context. After the name is resolved, the database host must also be able to reach the private IP address returned by DNS across the inter-region private network path.

That means this design has two equally important parts:

1. Name resolution: Recovery Service names must be resolved in the correct OCI Private DNS view and private zone.
2. Network reachability: The database host must have a valid private route from the source region to the target-region endpoint IP address returned by DNS.

Correct DNS alone is not enough. Correct routing alone is not enough. Recovery Service connectivity works only when both are aligned.

OCI DNS concepts used in this design

Before looking at the Recovery Service flow, it helps to define the OCI DNS pieces one at a time.

Figure 1: OCI DNS concepts and query flow through a DNS listening endpoint. The diagram introduces the key DNS components used in this design and shows how a DNS query enters OCI Private DNS, resolves through the VCN DNS resolver, private view, and private zone, and returns a response to the client.

VCN DNS resolver

Each VCN has a DNS resolver. It resolves names using the DNS context attached to that VCN, including private views and private zones associated with that resolver. In an inter-region design, the source database VCN and the target Recovery Service VCN have separate regional DNS contexts.

Private DNS view

A private DNS view controls which private DNS zones and records are visible in a given OCI DNS context. In this design, each target-region Recovery Service VCN can have its own private view.

Private DNS zone

A private DNS zone contains private records that are visible only through OCI Private DNS. Recovery Service-related records can be stored in private zones so that service names resolve to private IP addresses instead of public addresses.

DNS listening endpoint

A DNS listening endpoint receives DNS queries from another network location and passes them into OCI Private DNS for resolution. In this design, the listening endpoint is the target-region OCI DNS ingress point that dnsmasq forwards Recovery Service queries to.

DNS forwarding endpoint

A DNS forwarding endpoint is used when OCI needs to send DNS queries onward to another DNS server. That is a different use case. It is not the main path in this Recovery Service pattern, so the rest of this article focuses on the listening endpoint that receives source-region queries in the target region.

Split DNS

Split DNS means different DNS names are sent to different resolvers. On the database host, dnsmasq sends Recovery Service domains to OCI DNS and sends all other domains to customer DNS.

DNS context

DNS context is the combination of resolver, private view, private zones, and records used to answer a query. This matters because the same Recovery Service naming pattern can resolve to different private IP addresses depending on which regional VCN DNS context answers the query.

Network reachability

Network reachability is the ability of the protected database host to reach the private IP address returned by DNS. Route tables, DRG attachments, remote peering connections, VCN security lists, network security groups, and any firewall controls must allow the required inter-region traffic.

Why the correct VCN DNS context matters

In a multi-region deployment, each target environment can have its own Recovery Service-side DNS context. For example, PROD, DEV, and UAT may each have their own:

• Database subnet
• Backup subnet
• DNS listening endpoint
• VCN private view
• Private DNS zones
• Recovery Service-related A records

Figure 2: Example of a target-region Recovery Service VCN DNS context. The diagram shows one VCN with a database subnet, backup subnet, VCN DNS resolver, private view, private zone, and A records that return VCN-specific Recovery Service private IP addresses

The hostnames can look the same across environments, but the answers do not have to be the same. A Recovery Service hostname resolved through the PROD private view can return a different private IP address than the same hostname resolved through the DEV private view.

That behavior is expected. The private view and private zone determine which record is visible for that regional VCN context. For that reason, the protected database must forward Recovery Service DNS queries to the listening endpoint associated with the target-region Recovery Service environment it is intended to use.

Figure 3: Multiple target-region VCN DNS contexts. The diagram illustrates separate PROD, DEV, and UAT VCNs, each with its own private view, private DNS zones, and Recovery Service-related A records.

Inter-region connectivity assumptions

This article assumes an inter-region topology. The protected database environment is in one OCI region and the Recovery Service DNS and backup connectivity target are in another OCI region. The design relies on private connectivity between the participating regional VCNs.

A common pattern is to attach the source-region and target-region VCNs to DRGs and connect those DRGs by using remote peering connections (RPCs). Route tables, DRG route tables, route distributions, and security rules must be configured so that:

• The database host can send DNS traffic from the source region to the target-region OCI DNS listening endpoint.
• The DNS listening endpoint can receive and process the query.
• The database host can reach the target-region Recovery Service private endpoint returned by DNS.

Do not treat DNS success as proof that the service path is working. DNS may return the correct private IP address while routing or security rules still block the actual Recovery Service traffic.

For production designs, validate the exact topology against current OCI Recovery Service and OCI networking guidance, including supported regions, subscribed destination regions, latency expectations, DRG remote peering design, and Recovery Service subnet requirements. The intent of this article is to describe the DNS and network alignment pattern, not to override product-specific support boundaries.

Prerequisites

• OCI Base Database Service (BaseDB), Exadata Database Service on Dedicated Infrastructure (ExaDB-D), or Exadata Database Service on Exascale Infrastructure (ExaDB-XS), with operating system access
• dnsmasq installed locally on the database host
• /etc/resolv.conf configured to use 127.0.0.1
• Customer DNS resolvers available for non-Recovery Service lookups
• VCN DNS hostnames enabled
• OCI Private DNS configured in the target Recovery Service region
• DNS listening endpoints deployed in the required target-region backup subnets
• Inter-region routing configured so that the protected database environment can reach the target-region OCI DNS listening endpoints
• DRG-based connectivity between participating VCNs, including remote peering connections between regions where required
• Security rules, route tables, DRG route tables, and route distributions aligned for both DNS traffic and Recovery Service connectivity
• The exact Recovery Service domains, target-region DNS listening endpoint IP addresses, and private endpoint CIDRs identified before configuring dnsmasq

In this example, the Recovery Service-related domains belong to the target Recovery Service region:

rs.br.us-ashburn-1.oraclecloud.com
rs.br.us-ashburn-1.oci.oraclecloud.com

What changes from the first blog

The local split-DNS pattern remains the same. The important change is the OCI-side DNS target and the network path used to reach it.

In the simpler single-VCN pattern:

• The database host resolver points to 127.0.0.1.
• dnsmasq is the local DNS decision point.
• Recovery Service DNS can use the local OCI resolver path, such as 169.254.169.254 where applicable.
• Non-Recovery Service queries continue to use customer DNS.
• The main concern is preserving OCI-native resolution for Recovery Service names.

Figure 4: Single-VCN split-DNS baseline from the first design. dnsmasq runs locally on the database host, forwards Recovery Service domains to the OCI resolver, and forwards all other queries to customer DNS.

In the inter-region pattern:

• The database host resolver still points to 127.0.0.1.
• dnsmasq is still the local DNS decision point.
• Recovery Service DNS points to the OCI DNS listening endpoint IP for the correct target-region Recovery Service-side VCN.
• Non-Recovery Service queries continue to use customer DNS.
• The main concern is resolving through the correct target-region VCN private view and ensuring the returned private IP is reachable from the source region.

Figure 5: Inter-region split-DNS forwarding target. dnsmasq still runs locally on the database host, but Recovery Service domains are forwarded to the target-region OCI DNS listening endpoint instead of the local OCI resolver path

The practical dnsmasq change is that the server=/domain/IP entries for Recovery Service domains point to the target-region listening endpoint IP instead of the local OCI resolver path used in the simpler deployment.

Solution description

At the database host level, the resolver behavior remains straightforward. The operating system sends all DNS queries to 127.0.0.1, and the local dnsmasq process evaluates each request according to the requested domain.

• Queries for Recovery Service domains are forwarded to the OCI DNS listening endpoint for the correct target-region Recovery Service-side VCN.
• All other queries continue to use customer DNS.

The OCI DNS listening endpoint provides an entry point into the DNS context of the target-region VCN. Once a query reaches that listener, OCI Private DNS resolves it through the VCN DNS resolver, the associated private view, and the relevant private zones. Those zones contain records whose answers are specific to that VCN.

In practical terms, two requirements must be satisfied together:

• Correct DNS context: Queries must be resolved through the OCI Private DNS view that owns the relevant private zones and records.
• Correct network reachability: After DNS returns the private endpoint IP address, the protected database must have a valid route and security path across the inter-region private network to reach that endpoint.

The end-to-end flow is:

1. The database host sends a DNS query to 127.0.0.1.
2. dnsmasq evaluates the request.
3. If the query is Recovery Service-related, dnsmasq forwards it to the OCI DNS listening endpoint.
4. The query traverses the configured inter-region OCI network path, typically over DRG remote peering.
5. The DNS listening endpoint receives the request and passes it into the VCN DNS resolution path.
6. OCI Private DNS resolves the request using the VCN DNS resolver, private view, and private zones.
7. The correct private IP address is returned.
8. The protected database uses the configured inter-region private network path to reach that endpoint.

Local resolver configuration

The database host is configured to use the loopback address as its resolver. In /etc/resolv.conf, the nameserver entry is set to 127.0.0.1.

nameserver 127.0.0.1

This ensures that every DNS query generated by the operating system first reaches the local dnsmasq process.

dnsmasq configuration

In this example, both Recovery Service service domains are forwarded explicitly to the target-region OCI DNS listening endpoint. The following configuration implements the split-DNS behavior required for Recovery Service.

no-resolv
listen-address=127.0.0.1
bind-interfaces
# Recovery Service domains via target-region OCI DNS listening endpoint
server=/rs.br.us-ashburn-1.oraclecloud.com/10.1.1.23
server=/rs.br.us-ashburn-1.oci.oraclecloud.com/10.1.1.23
# Everything else via customer DNS
server=CUSTOMER_DNS_IP_1
server=CUSTOMER_DNS_IP_2
cache-size=0

In this example, 10.1.1.23 represents the IP address of the OCI DNS listening endpoint in the target Recovery Service-side VCN. Replace it with the actual listening endpoint IP address for the target region and environment that the database host should use.

Detailed deployment architecture

Figure 6: Detailed inter-region Recovery Service deployment architecture. The diagram shows source-region database hosts, target-region DNS listening endpoints, private DNS views and zones, DRG remote peering, and the aligned DNS and network paths required for Recovery Service connectivity.

The detailed architecture shows the same principle at deployment scale. Each participating regional VCN needs both the correct DNS path and the correct network path. If a database in the source region forwards Recovery Service DNS queries to the wrong listening endpoint, it may receive an address for the wrong region or environment. If it forwards to the correct listening endpoint but route tables, DRG route tables, RPCs, or security rules are incomplete, name resolution can succeed while Recovery Service traffic still fails.

For inter-region designs, test both DNS and data-path connectivity from the database host before relying on the configuration for backup operations. The DNS listener may be reachable while the returned Recovery Service endpoint is not, or the endpoint may be routed while the DNS listener is blocked.

Conclusion

The original dnsmasq split-DNS pattern remains an effective solution for OCI database hosts that need to preserve OCI-native resolution for Autonomous Recovery Service while continuing to use customer DNS for the rest of the namespace. In inter-region deployments, the design must also account for the target-region OCI DNS context and the private network path between regions.

When private DNS records are anchored in target-region VCNs and exposed through OCI DNS listening endpoints, the protected database must send Recovery Service queries to the listening endpoint for the correct regional VCN context. At the same time, the network architecture must ensure that the database host can reach the private endpoint returned by DNS across the inter-region private path.

The key takeaway is simple: for Autonomous Recovery Service across regions, correct DNS context, correct regional targeting, and correct network reachability must be designed together.