Private DNS Implementation

The purpose of this blog is to review some use cases for Private DNS and how to configure it. This blog focuses specifically in establishing a peering relationship with other DNS resolvers. It does not focus on zones or views or record creation within DNS. For more information on these topics visit our public documentation.

As you know DNS is a feature used to translate hostnames to IP addresses. If you have resources deployed in different environments and if they don’t know how to reach each other based on its hostname it creates problems.

Within OCI each VCN has its own resolver which allows you to resolve names within your VCN and the Internet. If you want to resolve names on-prem, or another VCN you will have to deploy your own DNS solution or use host names which is not scalable.

With the implementation of Private DNS you can establish peering relationship with other DNS resolvers located on-prem or other VCNs following the reference architecture. Based on rules that you define the VCN resolver will forward a request to another resolver. In the same way it can listen for requests from other resolvers.

This blog covers the following use cases:

1. DNS Peering Between VCNs in OCI
2. DNS Peering With On-Prem

Introduction

Every VCN within your tenancy has a DNS resolver that you can access and configure. To modify your resolver go to the main menu, select Networking, Virtual Cloud Networks, and select the VCN you want to work on, and then click the DNS Resolver. The name is usually the same as your VCN.

Note: To work with private DNS a user needs sufficient authority to perform this work within the Oracle Console

 

Using the diagram below lets do a simple test to ping between two VMs using its IP address and their hostname to see how the DNS resolver will convert the hostname to its IP address

Hostnames

• vmoci.asubnet.test.oraclevcn.com
• vmoci-2.bsubnet.test.oraclevcn.com

First, ping by IP to make sure that connectivity is in place

VMOCI to VMOCI-2

[opc@vmoci ~]$ ping 10.0.10.19 PING 10.0.10.19 (10.0.10.19) 56(84) bytes of data. 64 bytes from 10.0.10.19: icmp_seq=1 ttl=64 time=0.396 ms 64 bytes from 10.0.10.19: icmp_seq=2 ttl=64 time=0.342 ms 64 bytes from 10.0.10.19: icmp_seq=3 ttl=64 time=0.341 ms 64 bytes from 10.0.10.19: icmp_seq=4 ttl=64 time=0.316 ms 64 bytes from 10.0.10.19: icmp_seq=5 ttl=64 time=0.371 ms ^C --- 10.0.10.19 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4087ms rtt min/avg/max/mdev = 0.316/0.353/0.396/0.030 ms [opc@vmoci ~]$

VMOCI-2 to VMOCI

[opc@vmoci-2 ~]$ ping 10.0.10.2 PING 10.0.10.2 (10.0.10.2) 56(84) bytes of data. 64 bytes from 10.0.10.2: icmp_seq=1 ttl=64 time=0.318 ms 64 bytes from 10.0.10.2: icmp_seq=2 ttl=64 time=0.458 ms 64 bytes from 10.0.10.2: icmp_seq=3 ttl=64 time=0.322 ms 64 bytes from 10.0.10.2: icmp_seq=4 ttl=64 time=0.318 ms 64 bytes from 10.0.10.2: icmp_seq=5 ttl=64 time=0.337 ms ^C --- 10.0.10.2 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4113ms rtt min/avg/max/mdev = 0.318/0.350/0.458/0.057 ms [opc@vmoci-2 ~]$

Now lets try ping by internal FQDN or hostname to test DNS

VMOCI to VMOCI-2

[opc@vmoci ~]$ ping vmoci-2.bsubnet.test.oraclevcn.com PING vmoci-2.bsubnet.test.oraclevcn.com (10.0.10.19) 56(84) bytes of data. 64 bytes from vmoci-2.bsubnet.test.oraclevcn.com (10.0.10.19): icmp_seq=1 ttl=64 time=0.334 ms 64 bytes from vmoci-2.bsubnet.test.oraclevcn.com (10.0.10.19): icmp_seq=2 ttl=64 time=0.331 ms 64 bytes from vmoci-2.bsubnet.test.oraclevcn.com (10.0.10.19): icmp_seq=3 ttl=64 time=0.289 ms 64 bytes from vmoci-2.bsubnet.test.oraclevcn.com (10.0.10.19): icmp_seq=4 ttl=64 time=0.284 ms 64 bytes from vmoci-2.bsubnet.test.oraclevcn.com (10.0.10.19): icmp_seq=5 ttl=64 time=0.283 ms ^C --- vmoci-2.bsubnet.test.oraclevcn.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4073ms rtt min/avg/max/mdev = 0.283/0.304/0.334/0.025 ms [opc@vmoci ~]$

VMOCI-2 to VMOCI

[opc@vmoci-2 ~]$ ping vmoci.asubnet.test.oraclevcn.com PING vmoci.asubnet.test.oraclevcn.com (10.0.10.2) 56(84) bytes of data. 64 bytes from vmoci.asubnet.test.oraclevcn.com (10.0.10.2): icmp_seq=1 ttl=64 time=0.299 ms 64 bytes from vmoci.asubnet.test.oraclevcn.com (10.0.10.2): icmp_seq=2 ttl=64 time=0.297 ms 64 bytes from vmoci.asubnet.test.oraclevcn.com (10.0.10.2): icmp_seq=3 ttl=64 time=0.280 ms 64 bytes from vmoci.asubnet.test.oraclevcn.com (10.0.10.2): icmp_seq=4 ttl=64 time=0.279 ms 64 bytes from vmoci.asubnet.test.oraclevcn.com (10.0.10.2): icmp_seq=5 ttl=64 time=0.273 ms ^C --- vmoci.asubnet.test.oraclevcn.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4102ms rtt min/avg/max/mdev = 0.273/0.285/0.299/0.021 ms [opc@vmoci-2 ~]$

DNS Peering Between VCNs in OCI

Now what happen if you have multiple VCNs in your tenancy. How do you resolve hostnames? DNS resolver is local to each VCN, so the local resolver does not have any information about the resolver or hosts in any other VCN in the same region or in other region.

You can peer VCNs in the same region using a Local Peering Gateway (LPG) or using a virtual network device like a router or firewall and extend interfaces to the other VCNs. You can also peer with another VCN in a remote region using a Remote Peering Connection (RPC). Using the diagram below the next use case is to peer between the DNS resolvers on each VCN (TEST, SPOKE, and REMOTE) and perform some tests using hostnames.

The TEST VCN is basically a hub VCN and it is peered to the SPOKE VCN via an LPG and it is also peered to the REMOTE VCN via and RPC.

First make sure you have connectivity between the VCNs. Ping hosts using IP address. From the TEST VCN ping the VM in the SPOKE VCN as well as the VCN in the REMOTE VCN

To SPOKE VCN

[opc@vmoci ~]$ ping 10.0.100.2 PING 10.0.100.2 (10.0.100.2) 56(84) bytes of data. 64 bytes from 10.0.100.2: icmp_seq=1 ttl=64 time=0.196 ms 64 bytes from 10.0.100.2: icmp_seq=2 ttl=64 time=0.149 ms 64 bytes from 10.0.100.2: icmp_seq=3 ttl=64 time=0.142 ms 64 bytes from 10.0.100.2: icmp_seq=4 ttl=64 time=0.131 ms 64 bytes from 10.0.100.2: icmp_seq=5 ttl=64 time=0.127 ms ^C --- 10.0.100.2 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4080ms rtt min/avg/max/mdev = 0.127/0.149/0.196/0.024 ms

To REMOTE VCN

[opc@vmoci ~]$ ping 10.0.200.2 PING 10.0.200.2 (10.0.200.2) 56(84) bytes of data. 64 bytes from 10.0.200.2: icmp_seq=1 ttl=62 time=56.7 ms 64 bytes from 10.0.200.2: icmp_seq=2 ttl=62 time=56.7 ms 64 bytes from 10.0.200.2: icmp_seq=3 ttl=62 time=56.6 ms 64 bytes from 10.0.200.2: icmp_seq=4 ttl=62 time=56.6 ms 64 bytes from 10.0.200.2: icmp_seq=5 ttl=62 time=56.6 ms ^C --- 10.0.200.2 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 56.686/56.703/56.730/0.213 ms

As you can see it works above the ping results are working. Now if the same test is performed using the hostname it does not work as shown below

To SPOKE VCN

[opc@vmoci ~]$ ping vmoci-spoke.ssubnet.spoke.oraclevcn.com ping: vmoci-spoke.ssubnet.spoke.oraclevcn.com: Name or service not known   [opc@vmoci ~]$ nslookup vmoci-spoke.ssubnet.spoke.oraclevcn.com Server:     169.254.169.254 Address:    169.254.169.254#53   ** server can't find vmoci-spoke.ssubnet.spoke.oraclevcn.com: NXDOMAIN   [opc@vmoci ~]$

To REMOTE VCN

[opc@vmoci ~]$ ping vmoci-remote.rsubnet.remote.oraclevcn.com ping: vmoci-remote.rsubnet.remote.oraclevcn.com: Name or service not known   [opc@vmoci ~]$ nslookup vmoci-remote.rsubnet.remote.oraclevcn.com Server:     169.254.169.254 Address:    169.254.169.254#53   ** server can't find vmoci-remote.rsubnet.remote.oraclevcn.com: NXDOMAIN   [opc@vmoci ~]$

One way to get the test above to work is if you edit the host file and add the two entries below. It is a workaround, but it is not scalable.

vmoci-spoke.ssubnet.spoke.oraclevcn.com		        10.0.100.2
vmoci-remote.rsubnet.remote.oraclevcn.com		10.0.200.2

Another solution is to setup Private DNS between the VCNs so DNS is dynamic and there is no need to update any host file

To start the configuration

• Log into the Oracle console
• From the main menu, select Networking, select Virtual Cloud Network, select the your VCN
• Click the DNS Resolver

• On the next screen select Endpoints from the menu on the left
• Create a Listener endpoint, Click Create Endpoint
  • Give it a name
  • Select a subnet within your VCN
  • Select type – Listening
  • Click Create Endpoint

• Create a Forwarding endpoint, Click Create Endpoint
  • Give it a name
  • Select a subnet within your VCN
  • Select type – Forwarding
  • Click Create Endpoint
• Once the two endpoints are created you should have something like this

• Repeat the same process for the SPOKE and REMOTE VCN resolvers

SPOKE VCN

REMOTE VCN

Now that all the resolver have Listening and Forwarding endpoints the next step is to create some rules to forward DNS queries to the respective resolver.

Note: A resolver provides responses in this order:

1. by checking zones in your custom private views
2. then in its default view
3. then by checking rules
4. and finally by using internet DNS.

• Go back to the TEST VCN (main VCN)
• Click DNS Resolver
• Click Rules from the menu on the left - Here you will create rules to tell the DNS resolver where to forward the request for a particular domain
• Click Manage Rules
• Create a rule for each VCN. The rule condition could be by CIDR block, domain, or both. For this exercise I’m going to use domain. The first rule will be for domain spoke.oraclevcn.com on the SPOKE VCN and the second for remote.oraclevcn.com on the REMOTE VCN
  • Condition – Domains
  • Domain - spoke.oraclevcn.com
  • Source Endpoint – FWD
  • Destination IP address – This will be the Listening IP address of the SPOKE VCN DNS Resolver 10.0.100.3
• Add another rule for the remote.oraclevcn.com domain
• Your rules should look like this

• Next go to the SPOKE and REMOTE VCN (peered VCNs) and create similar rules for the TEST VCN domain as follow

Now that the rules to forward DNS requests are set between the 3 VCNs lets try to ping the VMs by hostname again as our previous test failed

To SPOKE VCN

[opc@vmoci ~]$ ping vmoci-spoke.ssubnet.spoke.oraclevcn.com ping: vmoci-spoke.ssubnet.spoke.oraclevcn.com: Name or service not known   [opc@vmoci ~]$ nslookup vmoci-spoke.ssubnet.spoke.oraclevcn.com Server:     169.254.169.254 Address:    169.254.169.254#53   ** server can't find vmoci-spoke.ssubnet.spoke.oraclevcn.com: NXDOMAIN   [opc@vmoci ~]$

To REMOTE VCN

[opc@vmoci ~]$ ping vmoci-remote.rsubnet.remote.oraclevcn.com ping: vmoci-remote.rsubnet.remote.oraclevcn.com: Name or service not known   [opc@vmoci ~]$ nslookup vmoci-remote.rsubnet.remote.oraclevcn.com Server:     169.254.169.254 Address:    169.254.169.254#53   ** server can't find vmoci-remote.rsubnet.remote.oraclevcn.com: NXDOMAIN   [opc@vmoci ~]$

It failed again as you can see above. Why?

By checking the security list on the VCNs I found that I’m not allowing DNS traffic between the VCNs, only ICMP was allowed. Based on your security policy make sure you allow traffic for the listener as well as the forwarding. I added the rules accordingly to the ingress as the egress is allowing all the traffic.

Note: Make sure you security list or network security groups allows traffic for DNS which uses TCP/UDP port 53

TEST VCN – Is allowing the traffic already

SPOKE VCN & REMOTE VCN

Now that the security list is allowing the traffic try the ping test by name again. Bingo, our pings are successful

To SPOKE VCN

[opc@vmoci ~]$ nslookup vmoci-spoke.ssubnet.spoke.oraclevcn.com Server:     169.254.169.254 Address:    169.254.169.254#53   Non-authoritative answer: Name:   vmoci-spoke.ssubnet.spoke.oraclevcn.com Address: 10.0.100.2   [opc@vmoci ~]$ ping vmoci-spoke.ssubnet.spoke.oraclevcn.com PING vmoci-spoke.ssubnet.spoke.oraclevcn.com (10.0.100.2) 56(84) bytes of data. 64 bytes from 10.0.100.2 (10.0.100.2): icmp_seq=1 ttl=64 time=0.209 ms 64 bytes from 10.0.100.2 (10.0.100.2): icmp_seq=2 ttl=64 time=0.129 ms 64 bytes from 10.0.100.2 (10.0.100.2): icmp_seq=3 ttl=64 time=0.129 ms 64 bytes from 10.0.100.2 (10.0.100.2): icmp_seq=4 ttl=64 time=0.114 ms 64 bytes from 10.0.100.2 (10.0.100.2): icmp_seq=5 ttl=64 time=0.179 ms ^C --- vmoci-spoke.ssubnet.spoke.oraclevcn.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4073ms rtt min/avg/max/mdev = 0.114/0.152/0.209/0.036 ms [opc@vmoci ~]$

To REMOTE VCN

[opc@vmoci ~]$ nslookup vmoci-remote.rsubnet.remote.oraclevcn.com Server:     169.254.169.254 Address:    169.254.169.254#53   Non-authoritative answer: Name:   vmoci-remote.rsubnet.remote.oraclevcn.com Address: 10.0.200.2   [opc@vmoci ~]$ ping vmoci-remote.rsubnet.remote.oraclevcn.com PING vmoci-remote.rsubnet.remote.oraclevcn.com (10.0.200.2) 56(84) bytes of data. 64 bytes from 10.0.200.2 (10.0.200.2): icmp_seq=1 ttl=62 time=56.7 ms 64 bytes from 10.0.200.2 (10.0.200.2): icmp_seq=2 ttl=62 time=56.7 ms 64 bytes from 10.0.200.2 (10.0.200.2): icmp_seq=3 ttl=62 time=56.7 ms 64 bytes from 10.0.200.2 (10.0.200.2): icmp_seq=4 ttl=62 time=56.7 ms 64 bytes from 10.0.200.2 (10.0.200.2): icmp_seq=5 ttl=62 time=56.7 ms ^C --- vmoci-remote.rsubnet.remote.oraclevcn.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 56.703/56.722/56.752/0.261 ms [opc@vmoci ~]$

Perform the same test from the SPOKE and REMOTE VCN to the TEST VCN

From SPOKE VCN to TEST VCN

[opc@vmoci-spoke ~]$ nslookup vmoci.asubnet.test.oraclevcn.com Server:     169.254.169.254 Address:    169.254.169.254#53   Non-authoritative answer: Name:   vmoci.asubnet.test.oraclevcn.com Address: 10.0.10.2   [opc@vmoci-spoke ~]$ ping vmoci.asubnet.test.oraclevcn.com PING vmoci.asubnet.test.oraclevcn.com (10.0.10.2) 56(84) bytes of data. 64 bytes from 10.0.10.2 (10.0.10.2): icmp_seq=1 ttl=64 time=0.141 ms 64 bytes from 10.0.10.2 (10.0.10.2): icmp_seq=2 ttl=64 time=0.119 ms 64 bytes from 10.0.10.2 (10.0.10.2): icmp_seq=3 ttl=64 time=0.124 ms 64 bytes from 10.0.10.2 (10.0.10.2): icmp_seq=4 ttl=64 time=0.122 ms 64 bytes from 10.0.10.2 (10.0.10.2): icmp_seq=5 ttl=64 time=0.169 ms ^C --- vmoci.asubnet.test.oraclevcn.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4107ms rtt min/avg/max/mdev = 0.119/0.135/0.169/0.018 ms [opc@vmoci-spoke ~]$

From REMOTE VCN to TEST VCN

[opc@vmoci-remote ~]$ nslookup vmoci.asubnet.test.oraclevcn.com Server:     169.254.169.254 Address:    169.254.169.254#53   Non-authoritative answer: Name:   vmoci.asubnet.test.oraclevcn.com Address: 10.0.10.2   [opc@vmoci-remote ~]$ ping vmoci.asubnet.test.oraclevcn.com PING vmoci.asubnet.test.oraclevcn.com (10.0.10.2) 56(84) bytes of data. 64 bytes from 10.0.10.2 (10.0.10.2): icmp_seq=1 ttl=62 time=56.6 ms 64 bytes from 10.0.10.2 (10.0.10.2): icmp_seq=2 ttl=62 time=56.6 ms 64 bytes from 10.0.10.2 (10.0.10.2): icmp_seq=3 ttl=62 time=56.6 ms 64 bytes from 10.0.10.2 (10.0.10.2): icmp_seq=4 ttl=62 time=56.6 ms 64 bytes from 10.0.10.2 (10.0.10.2): icmp_seq=5 ttl=62 time=56.7 ms ^C --- vmoci.asubnet.test.oraclevcn.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 56.674/56.687/56.717/0.016 ms [opc@vmoci-remote ~]$

DNS Peering With On-Prem

In this use case your environment in OCI has to interact with on-prem. How the on-prem DNS will resolve hosts in OCI and vice versa?

For this test the on-prem location is connected to OCI via VPN Connect per diagram below

On-prem DNS server also has a Listening and Forwarding endpoint that can be used to peer with the DNS resolver in OCI, the process is similar to what was implemented in the previous use case for VCNs within OCI.

Test connectivity to make sure the path is in place. From VMOCI in the TEST VCN ping the VMOP VM on-prem by IP, as seen below it works

[opc@vmoci ~]$ ping 10.0.0.35 PING 10.0.0.35 (10.0.0.35) 56(84) bytes of data. 64 bytes from 10.0.0.35: icmp_seq=1 ttl=61 time=58.2 ms 64 bytes from 10.0.0.35: icmp_seq=2 ttl=61 time=58.1 ms 64 bytes from 10.0.0.35: icmp_seq=3 ttl=61 time=58.1 ms 64 bytes from 10.0.0.35: icmp_seq=4 ttl=61 time=58.5 ms 64 bytes from 10.0.0.35: icmp_seq=5 ttl=61 time=58.2 ms ^C --- 10.0.0.35 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4005ms rtt min/avg/max/mdev = 58.114/58.275/58.572/0.345 ms

Perform the same test using the hostname instead of the IP addres, it fails

[opc@vmoci ~]$ ping vmop.trust.onprem.oraclevcn.com ping: vmop.trust.onprem.oraclevcn.com: Name or service not known [opc@vmoci ~]$ [opc@vmoci ~]$ nslookup vmop.trust.onprem.oraclevcn.com ;; connection timed out; no servers could be reached

Also check connectivity to the on-prem DNS listener

[opc@vmoci ~]$ ping 10.0.0.42 PING 10.0.0.42 (10.0.0.42) 56(84) bytes of data. 64 bytes from 10.0.0.42: icmp_seq=2 ttl=61 time=61.1 ms 64 bytes from 10.0.0.42: icmp_seq=3 ttl=61 time=60.9 ms 64 bytes from 10.0.0.42: icmp_seq=4 ttl=61 time=59.6 ms 64 bytes from 10.0.0.42: icmp_seq=5 ttl=61 time=60.3 ms 64 bytes from 10.0.0.42: icmp_seq=6 ttl=61 time=58.8 ms ^C --- 10.0.0.42 ping statistics --- 6 packets transmitted, 5 received, 16% packet loss, time 5013ms rtt min/avg/max/mdev = 58.874/60.185/61.127/0.831 ms [opc@vmoci ~]$

As connectivity is in place, the next step is to configure the TEST VCN resolver to send requests to the on-prem DNS.

• Go to the TEST VCN resolver
• Add a rule for on-prem for domain onprem.oraclevcn.com. After adding this rule the rules for the TEST VCN look like

Repeat the ping test by host name. Bingo it works

[opc@vmoci ~]$ nslookup vmop.trust.onprem.oraclevcn.com Server:     169.254.169.254 Address:    169.254.169.254#53   Non-authoritative answer: Name:   vmop.trust.onprem.oraclevcn.com Address: 10.0.0.35   [opc@vmoci ~]$ ping vmop.trust.onprem.oraclevcn.com PING vmop.trust.onprem.oraclevcn.com (10.0.0.35) 56(84) bytes of data. 64 bytes from 10.0.0.35 (10.0.0.35): icmp_seq=1 ttl=61 time=58.3 ms 64 bytes from 10.0.0.35 (10.0.0.35): icmp_seq=2 ttl=61 time=58.8 ms 64 bytes from 10.0.0.35 (10.0.0.35): icmp_seq=3 ttl=61 time=58.8 ms 64 bytes from 10.0.0.35 (10.0.0.35): icmp_seq=4 ttl=61 time=58.1 ms 64 bytes from 10.0.0.35 (10.0.0.35): icmp_seq=5 ttl=61 time=58.8 ms ^C --- vmop.trust.onprem.oraclevcn.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 58.171/58.618/58.862/0.418 ms [opc@vmoci ~]$

Now ping VMOCI VM from on-prem by hostname

[opc@vmop ~]$ ping vmoci.asubnet.test.oraclevcn.com PING vmoci.asubnet.test.oraclevcn.com (10.0.10.2) 56(84) bytes of data. 64 bytes from 10.0.10.2 (10.0.10.2): icmp_seq=1 ttl=62 time=58.9 ms 64 bytes from 10.0.10.2 (10.0.10.2): icmp_seq=2 ttl=62 time=58.3 ms 64 bytes from 10.0.10.2 (10.0.10.2): icmp_seq=3 ttl=62 time=58.7 ms 64 bytes from 10.0.10.2 (10.0.10.2): icmp_seq=4 ttl=62 time=59.1 ms 64 bytes from 10.0.10.2 (10.0.10.2): icmp_seq=5 ttl=62 time=58.3 ms ^C --- vmoci.asubnet.test.oraclevcn.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4005ms rtt min/avg/max/mdev = 58.313/58.685/59.105/0.348 ms [opc@vmop ~]$ [opc@vmop ~]$ nslookup vmoci.asubnet.test.oraclevcn.com Server:     169.254.169.254 Address:    169.254.169.254#53   Non-authoritative answer: Name:   vmoci.asubnet.test.oraclevcn.com Address: 10.0.10.2   [opc@vmop ~]$

Summary

As demonstrated in this blog with the use of Private DNS now you can easily implement a hybrid DNS solution to resolve hostnames across multiple VCNs in the same region or across regions as well with on-prem.

In this blog I basically tested Private DNS resolution between the TEST VCN and its directly connected VCNs and on-prem. If you have a similar environment and you would like DNS resolution between the REMOTE VCN and the SPOKE VCN or between on-prem and the SPOKE VCN then make sure connectivity, DNS rules, and security lists are in place to allow this traffic.

Note: DNS resolution between on-prem and the REMOTE VCN is not possible because by design on-prem can’t connect to a VCN connected via a Remote Peering Connection (RPC).

When implementing Private DNS, keep in mind the following points during configuration and design:

1. Connectivity should be in place between DNS resolvers
2. Each DNS resolver should have a Listening and Forwarding endpoint
3. Create the necessary rules to forward the request to the proper DNS resolver
4. Make sure any security list, network security group, or firewall in the path is opened to allow DNS traffic which uses UDP/TCP port 53

Note: During the implementation I noticed that my changes will not take effect immediately. This is usually caused by the TTL as the information is cached. Also noticed that after a change if I ping a host by hostname it will not resolve, then try it again after couple seconds and then it works. So there is a small lag when doing the initial configuration.

 

 https://www.ateam-oracle.com/private-dns-implementation