Bidirectional private DNS between a VCN and on-premises
Adatum has a VCN 10.20.0.0/16 connected to on-premises 172.16.0.0/12 through a DRG and Site-to-Site VPN. VCN applications must resolve db.corp.example.com to 172.16.10.20. On-premises applications must resolve app.privatelb.oraclevcn.com to a private load balancer at 10.20.2.10. The VCN uses the default Internet DNS resolver; on-premises DNS servers are 172.16.0.53 and 172.16.0.54. Queries for corp.example.com from the VCN time out, and queries for oraclevcn.com from on-prem return NXDOMAIN. The security team will not allow DNS over the public internet. The VCN has a private subnet 10.20.9.0/24 with a route to the DRG, and on-premises routes 10.20.0.0/16 to the VPN. The team wants a private, bidirectional resolution design and a test plan.
1. Design the OCI DNS resolver endpoints and forwarding rules needed for both directions.
Read the worked answer
For VCN-to-on-premises resolution, create an outbound DNS resolver endpoint in the VCN, preferably in a private subnet with a route to the DRG. Add a forwarding rule for corp.example.com to the on-premises DNS servers 172.16.0.53 and 172.16.0.54. Associate that rule with the private DNS view that contains the VCN's private zone and resolver configuration, so VCN queries for that domain are forwarded privately over the DRG/VPN instead of the internet.
For on-premises-to-VCN resolution, create an inbound DNS resolver endpoint in the VCN. Give it an IP address in a private subnet that on-premises can reach, for example in 10.20.9.0/24. On the on-premises DNS servers, create a conditional forwarder for oraclevcn.com (and any relevant private zone names) pointing to the inbound endpoint IP. Do not use the public internet resolver for either direction. If the private LB name is in a custom private zone rather than the default VCN zone, forward that zone name instead.
2. What routing and security rules must be in place for the resolver endpoints to work?
Read the worked answer
Routing: the VCN private subnet hosting the outbound endpoint needs 172.16.0.0/12 -> DRG so queries can reach 172.16.0.53/54. The on-premises network needs a route for the inbound endpoint address, or the broader 10.20.0.0/16, back through the VPN/DRG. Return routes must be symmetric; asymmetric paths can break stateful VPN or firewall sessions.
Security: allow UDP and TCP 53 from the VCN resolver endpoint addresses to 172.16.0.53 and 172.16.0.54 for outbound resolution. Allow UDP and TCP 53 from the on-premises DNS server addresses to the inbound endpoint IP for inbound resolution. If the on-premises firewall performs DNS inspection, permit the specific query types. Confirm that no NSG or security list blocks the resolver endpoint subnet, and test with dig from both sides, including TCP fallback for large responses.
3. What test plan would prove bidirectional resolution without relying on the public internet?
Read the worked answer
From a VCN instance, run dig db.corp.example.com and confirm the answer is 172.16.10.20 with the VCN resolver as the server. Use dig +trace only if needed; otherwise inspect resolver query logs and VCN flow logs for UDP/TCP 53 to 172.16.0.53/54 over the DRG. Confirm the query does not go to an internet resolver.
From an on-premises host, run dig app.privatelb.oraclevcn.com @172.16.0.53 and confirm the answer is 10.20.2.10 with recursion handled by the conditional forwarder to the inbound endpoint. Also test TCP 53 and a deliberately invalid name to see NXDOMAIN rather than timeout. Finally, test from a second AD/subnet and after a resolver endpoint failover if multiple endpoints are deployed.