OCI private DNS at scale: private views, resolver endpoints and hybrid forwarding with on-prem

Every VCN has its own resolver. That works for one VCN. With a hub and many spokes plus an on-prem DNS, you need a deliberate design or names resolve in some places and not in others.

#The building blocks

#Pattern: one shared view, attached everywhere

Create a view in a network compartment, put shared zones in it, and attach that view to every VCN resolver. Every VCN then resolves the same names without forwarding.

VIEW=$(oci dns view create --compartment-id $NET_COMP --display-name view-shared-internal --scope PRIVATE --query 'data.id' --raw-output)

oci dns zone create --compartment-id $NET_COMP --name internal.example.com \
  --zone-type PRIMARY --scope PRIVATE --view-id $VIEW

RESOLVER=$(oci network vcn-dns-resolver-association get --vcn-id $SPOKE_VCN --query 'data."dns-resolver-id"' --raw-output)
oci dns resolver update --resolver-id $RESOLVER --scope PRIVATE \
  --attached-views '[{"viewId":"'"$VIEW"'"}]'

--attached-views replaces the list; include any views already attached. Order matters: the first view that has a matching zone answers. The VCN's own default view is consulted first.

Add a record:

oci dns record rrset update --zone-name-or-id internal.example.com --domain api.internal.example.com --rtype A \
  --scope PRIVATE --view-id $VIEW \
  --items '[{"domain":"api.internal.example.com","rtype":"A","rdata":"10.1.2.15","ttl":300}]' --force

#Hybrid: on-prem resolves OCI names

1. Create a listening endpoint in the hub VCN:

oci dns resolver-endpoint create --resolver-id $HUB_RESOLVER --name listen_hub \
  --is-listening true --is-forwarding false --subnet-id $HUB_DNS_SUBNET \
  --listening-address 10.0.2.10 --scope PRIVATE

2. On-prem DNS: conditional forwarder for internal.example.com and oraclevcn.com (the default VCN domain) to 10.0.2.10.
3. Security rules on the endpoint subnet allow UDP and TCP 53 from on-prem DNS servers.

#Hybrid: OCI resolves on-prem names

1. Create a forwarding endpoint in the hub VCN:

oci dns resolver-endpoint create --resolver-id $HUB_RESOLVER --name fwd_hub \
  --is-listening false --is-forwarding true --subnet-id $HUB_DNS_SUBNET \
  --forwarding-address 10.0.2.11 --scope PRIVATE

2. Add a rule on the hub resolver:

oci dns resolver update --resolver-id $HUB_RESOLVER --scope PRIVATE --rules '[
  {"action":"FORWARD","qnameCoverConditions":["corp.example.com"],
   "destinationAddresses":["192.168.10.53","192.168.10.54"],"sourceEndpointName":"fwd_hub"}
]'

3. Spokes: either repeat endpoints and rules per spoke, or (simpler) add a forwarding rule in each spoke resolver that sends corp.example.com to the hub listening endpoint, which then applies the hub's rules. The spoke needs its own forwarding endpoint as the source.

Warning

Avoid forwarding loops: never let on-prem forward a zone to OCI while OCI forwards the same zone back to on-prem. Keep a written table of which side is authoritative for each zone.

#Debugging from the right place

Always test from an instance inside the VCN in question; the VCN resolver is at 169.254.169.254.

dig +short api.internal.example.com @169.254.169.254
dig +short dc01.corp.example.com @169.254.169.254
dig +short api.internal.example.com @10.0.2.10        # from on-prem, via listening endpoint

#Prevent it next time

• Shared zones live in one network compartment, managed by Terraform.
• New VCNs get the shared view attached in the same module that creates the VCN.
• Monitor endpoint health and keep two on-prem DNS targets in each forward rule.