This is the second part of my OCI Private DNS posts. You can read the first part from here.

In this post I will extend my configuration to have two VCN’s which will be connected via Local Peering Gateways together. Other VCN will have Private Zone for thatfinnishguy.com and the other VCN for somethingelse.com.

Both VCN’s will have one compute instance running in their subnets and I will have A Record inserted for each.

Remember to check the BUT section afterwards to see how this can be done without forwarders or listeners.

Design of two VCN’s connected with LPG’s, both having their own Private DNS Zone and DNS forwarders and listeners.

Setup

To achieve my configuration above I’ve created following:

  • Two VCN’s vcn-thatfinnishguy (10.0.0.0/24) and vcn-somethingelse (192.168.0.0/24) with subnets on both
  • Two Private DNS Views each having their own zone (thatfinnishguy.com and somethingelse.com) and views associated to their respective VCN
  • On the VCN resolver I have one listener and one forwarder on each VCN
  • Both resolvers have rule assigned which forwards specific DOMAIN to other VCN’s listener

On part 1 we already went through on creating Private View, Zone and assigning A Record. Since this is done already and I’ve assigned views on their VCN’s let’s take a look on creating listener and forwarder.

When I go to my VCN resolver I have option to create endpoints and in order for my configuration to work I will need to create listener and forwarder. You need to assign endpoint always to a subnet and either give it an IP address or let Oracle assign it automatically.

In this example I’ve defined IP address myself just to have specific IP’s on both side of VCNs.

Creating listener endpoint and specifying IP address

After doing this I should have one listener and one forwarder on both sides. What is needed next are rules for both VCN’s. Since this is a fairly straightforward example I will create a domain specific rule to forward queries against thatfinnishguy.com from somethingelse.com and vice versa.

Forwarding queries to thatfinnishguy.com domain through somethingelse_forwarder to thatfinnishguy_listener
Rule created and visible on VCN vcn-somethingelse resolver
Rule created and visible on VCN vcn-thatfinnishguy resolver

Testing it out

That’s pretty much all that is required! Since I’m using LPG’s to connect VCN’s I need to remember to add route rules on my routetable.

You also need to allow traffic between VCN’s so listeners can be accessed as endpoints exist in your VCN and obey rules you have setup either through Security Lists or Network Security Groups.

Compute instance on vcn-somethingelse

[opc@se-1 ~]$ nslookup tfg-1.thatfinnishguy.com
Server:		169.254.169.254
Address:	169.254.169.254#53

Non-authoritative answer:
Name:	tfg-1.thatfinnishguy.com
Address: 10.0.0.2

Compute instance on vcn-thatfinnishguy

[opc@tfg-1 ~]$ nslookup se-1.somethingelse.com
Server:		169.254.169.254
Address:	169.254.169.254#53

Non-authoritative answer:
Name:	se-1.somethingelse.com
Address: 192.168.0.2

But there’s a BUT!

Now we’ve created DNS resolvers and listeners but what if we just add both Private views on the VCN resolver?

Attaching two Private Views on vcn-thatfinnishguy resolver

I removed the forwarding rule and tested it out and everything works smoothly! So if you are doing this inside OCI you can just add multiple views on VCN resolver and get your DNS queries resolved without setting up resolvers and listeners.

Summary

Setting up Private DNS between VCN’s isn’t too complicated once you’ve learned all the steps. Remember this isn’t just limited within OCI! You can setup forwarders to point your custom DNS which can be your internal DNS and the other way around you can point your DNS on the VCN Resolver listeners.

And nothing limits you to resolve DNS between cloud vendors as well. Lot of possibilities now compared to previous situation where you always had to setup your own DNS forwarders.

Associating multiple Views for one VCN resolver makes the setup inside OCI very trivial and doesn’t add so much overhead as it would with listeners and forwarders.

Leave a Reply

Your email address will not be published. Required fields are marked *