A practical host-local fallback pattern when the recommended OCI Private DNS endpoint architecture cannot be adopted

Introduction

For hybrid and enterprise DNS integration, Oracle generally recommends using OCI Private DNS together with listening endpoints, forwarding endpoints, and resolver rules so that OCI VCN-native DNS resolution can interoperate cleanly with enterprise DNS services and on-premises resolvers. In that model, OCI remains the authoritative path for OCI-native and VCN-local DNS, while enterprise DNS systems can exchange queries with OCI through explicitly defined resolver endpoints and forwarding policies.

A useful reference for these recommended deployment patterns is the A-Team article “OCI Private DNS – Common Scenarios,” which outlines common OCI Private DNS integration models and explains the role of listening endpoints, forwarding endpoints, and resolver rules in hybrid DNS topologies. For customers designing enterprise DNS connectivity into OCI, that article is a recommended starting point.

However, not every environment can adopt that recommended architecture immediately. In some customer deployments, especially where DNS behavior is tightly coupled to host-level operating system configuration or where database systems already rely on customer-managed resolvers directly on the OS, implementing OCI Private DNS resolver endpoints and the corresponding forwarding architecture may not be feasible in the short term.

During Autonomous Recovery Service subnet setup, OCI creates multiple private DNS zones in the VCN. These private zones contain the DNS records, including names and private IP addresses, that are used by Autonomous Recovery Service in OCI.

The more important detail is that Recovery Service uses service names that are structurally identical across customer environments in the same region, while the private IP address returned for those names is specific to the VCN in which the protected database resides. As a result, when customers use Recovery Service to protect databases that reside in different VCNs, each VCN can contain exactly the same DNS names, even though those names resolve to different private IP addresses depending on the VCN context.

That means a centralized custom DNS resolver does not have sufficient OCI VCN context to determine the correct Recovery Service endpoint IP address. Even if the custom DNS service attempts to forward such requests, it cannot reliably determine the correct Recovery Service private IP address because that answer depends on OCI-private resolution within a specific VCN.

In practice, when a database host is configured to use only customer-managed DNS, Recovery Service name resolution can fail or resolve incorrectly. The result is that the database system may not be able to communicate properly with Autonomous Recovery Service.

This is where the approach described in this blog becomes relevant. For OCI Base Database Service (BaseDB) and OCI Exadata Database Service (ExaDB-D and ExaDB-XS) systems that provide operating system access, dnsmasq can be used locally on the database host to implement a split-DNS configuration. With this design, queries for Autonomous Recovery Service domains such as rs.br.<region-1>.oraclecloud.com and rs.br.<region-1>.oci.oraclecloud.com are resolved through the OCI VCN resolver, while all other queries continue to use the customer’s enterprise DNS servers.

In other words, this blog describes a practical fallback pattern for situations in which the recommended OCI Private DNS endpoint-based architecture cannot be implemented, but OCI-native DNS resolution must still be preserved for Recovery Service.

Prerequisites

• OCI BaseDB, ExaDB-D or ExaDB-XS with operating system access

• VCN with DNS hostnames enabled

• Access to the OCI resolver at 169.254.169.254

• IP addresses for the custom DNS servers

• Root or sudo access on the database host

• dnsmasq installed on the host

It is also important to identify the exact OCI service domain that must remain resolvable through OCI. In this example, the Recovery Service-related domain is:

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

Solution Description

Solution Overview

In this design, dnsmasq is used to implement split DNS directly on the database host. That is the central architectural idea of the solution.

Rather than forcing the host to choose between OCI DNS and custom DNS, dnsmasq allows both resolver paths to coexist. Queries are evaluated locally and forwarded according to domain-based policy. Recovery Service-related lookups are sent to the OCI VCN resolver, while all other lookups continue to use the customer’s enterprise DNS servers.

This is important because it turns dnsmasq into more than a simple forwarding service. It becomes a lightweight DNS policy layer on the host, allowing the system to preserve OCI-native resolution exactly where it is required, while maintaining custom DNS as the default path for the broader namespace.

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.

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

nameserver 127.0.0.1

dnsmasq Configuration

In this example, both Recovery Service service domains are forwarded explicitly to the OCI VCN resolver. The following dnsmasq configuration implements the split-DNS behavior required for Recovery Service.

What each directive does

no-resolv — Prevents dnsmasq from inheriting upstream resolvers from /etc/resolv.conf. This is important because /etc/resolv.conf points to 127.0.0.1, and upstream behavior should be defined explicitly.

listen-address=127.0.0.1 — Ensures dnsmasq listens only on the loopback interface. The resolver remains local to the DB host and is not exposed as a shared subnet service.

bind-interfaces — Provides predictable binding behavior and avoids ambiguity when multiple interfaces are present.

server=/rs.br.us-ashburn-1.oraclecloud.com/169.254.169.254 and server=/rs.br.us-ashburn-1.oci.oraclecloud.com/169.254.169.254 — This is the key split-DNS statement. It tells dnsmasq to send Recovery Service lookups specifically to the OCI VCN resolver.

server=<CUSTOMER_DNS_IP_1> and server=<CUSTOMER_DNS_IP_2> — These define the default upstream resolvers for all non-Recovery Service DNS traffic.

cache-size=0 — Disables local DNS caching so behavior remains explicit and easier to validate during testing and troubleshooting.

DNS Resolution Flow

With this configuration in place, the database host follows a deterministic DNS path. The host sends all queries to 127.0.0.1. dnsmasq evaluates the domain being requested. If the query is for rs.br.us-ashburn-1.oraclecloud.com or rs.br.us-ashburn-1.oci.oraclecloud.com, it forwards the request to 169.254.169.254. If the query is for any other domain, it forwards the request to the custom DNS servers.

This is why it is more precise to describe the design as split DNS rather than simply DNS forwarding. The forwarding decision is intentionally split by domain so that each class of DNS request is answered by the resolver best suited to provide the correct response.

Why This Works for Recovery Service

The effectiveness of this design comes from respecting the DNS boundary between OCI-native resolution and enterprise resolution.

Recovery Service does not fail because DNS is unavailable. It fails when the wrong resolver path is used for a name that requires OCI VCN-local context. By placing dnsmasq locally on the host and steering Recovery Service lookups to the OCI resolver, the database preserves the resolution path that OCI expects for Recovery Service, while still retaining enterprise DNS for everything else.

This allows both requirements to coexist cleanly: OCI-specific resolution remains correct, and customer-managed DNS remains the standard path for the rest of the namespace.

Why Local dnsmasq Is Preferable Here

It may be tempting to place this logic on a separate VM or centralized DNS forwarder, but running dnsmasq directly on the DB host is operationally cleaner for this use case.

The local deployment model avoids introducing another compute dependency, another network hop, and another moving part into the recovery path. DNS behavior stays local, transparent, and host-specific, which makes validation and troubleshooting easier.

For BaseDB, ExaDB-D and ExaDB-XS systems where operating system access is available, this makes the design both practical and elegant.

Conclusion

When OCI database systems are configured to use customer-managed DNS, Autonomous Recovery Service introduces a subtle but important name-resolution challenge. Recovery Service endpoint names are shared across environments, but the corresponding private IP addresses are VCN-specific. Because of that, a centralized custom DNS resolver cannot reliably return the correct answer for Recovery Service.

The right design is not to abandon custom DNS, but to apply DNS resolution selectively.

By running dnsmasq locally on the database host and configuring /etc/resolv.conf to use 127.0.0.1, customers can implement a split-DNS configuration that preserves OCI-native Recovery Service resolution while continuing to use enterprise DNS for all other lookups.

This design is lightweight, deterministic, easy to validate, operationally simple, and well suited to OCI BaseDB, ExaDB-D and ExaDB-XS environments. Most importantly, it ensures that Recovery Service-related names are resolved in the correct DNS context: inside the VCN.