OCI Transit Networking DNS part 1

First of all, big thanks for my colleagues Rob and Travis for giving me some good ideas on this post!

I usually recommend Transit Networking for most of the implementations as it provides security and scalability for your OCI infrastructure. Transit networking means one of your VCN acts as a Hub and the other VCNs as Spokes.

All the traffic from on-premises will come to DRG which is connected to Hub VCN and it routes traffic to Spokes. Transit networking is explained in detail here.

In this first post of multiple series on OCI DNS, I’ll take a look on what you can do with OCI DNS if you have some shared services running in the Hub which need to connect to other VCNs. In the later parts we’ll see what happens if shared services is running on it’s own VCN and how using custom DNS changes things.

For example, we can have some monitoring tools in Hub which need to connect to each Spoke. Previously you didn’t have easy way to setup cross VCN DNS but now with the recent Private DNS capabilities in OCI we have more tools available to achieve this.

It’s not so common to use only Oracle DNS (or Oracle resolvers) but I’m going to go it through so it gives good overview on how DNS forwarding works in OCI.

And as you can see from my below older posts, on part 2 I mention that you could easily do this by assigning private views from each VCN to another instead of setting up listeners and forwarders, reminder on that is also at the end of this post.

Older post on Private DNS consists of two parts, part 1 and part 2.

Remember always the order which is used when resolving the addresses, sometimes it might be important to tweak the order so you get most of your queries answered promptly.

A resolver provides responses by checking zones in your custom private views, then in its default view, then by checking rules, and finally by using internet DNS.

Hub & Spoke DNS when using Oracle Resolver with forwarders and listeners

For this example I’ve created following:

• Hub VCN with DNS listener and forwarder
• SpokeA, SpokeB, SpokeC VCNs with each having their respective DNS forwarder and listener
• Compute instances in Hub VCN and Spokes

As usual, a picture makes whole thing easier to understand:

In short what I need to do is setup listeners and forwarders to each VCN. The main setup will be in Hub VCN as that will need to resolve addresses in each VCN. I’ve also setup forwarders to each Spoke so if they need to resolve some shared services hostnames they will be able to do it.

Remember that Spoke to Spoke traffic does not work, we will not be able to resolve hostnames between SpokeA and SpokeB unless we do further configurations. On that I’ll show it in the end.

For resolving addresses remember to allow traffic from other VCN’s for UDP/TCP port 53 on the DNS listener you setup.

Listener & Forwarder setups

Once I have my VCNs created, what I do is navigate to VCN resolver which is assigned to Hub VCN.

For each VCN I will setup endpoints first. Setting up listener or forwarder is just defining name, type (listener or forwarder) and subnet where it’s created on. You could also define IP address by yourself which might help on some Terraform configurations where you want to specify IP for your resources.

Once I have endpoints in place on each VCN, I have also IP addresses for each. This enables me to setup rules which are needed in each VCN.

Hub VCN will have three rules like defined in the diagram above, each pointing to a listener in respective Spoke. Similarly each Spoke will have one rule each pointing to Hub VCN listener.

Rule what needs to be setup is Domain rule with VCN domain. Nothing else is required and we are ready to test our setup.

Verifying the setup works

I’ll just run simple test from my Hub compute instance towards to compute instances I have in Spokes.

[opc@compute-hub-1 ~]$ dig compute-spokeb-1.subspokeb1.vcnspokeb.oraclevcn.com

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.3 <<>> compute-spokeb-1.subspokeb1.vcnspokeb.oraclevcn.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61093
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;compute-spokeb-1.subspokeb1.vcnspokeb.oraclevcn.com. IN	A

;; ANSWER SECTION:
compute-spokeb-1.subspokeb1.vcnspokeb.oraclevcn.com. 246 IN A 10.0.2.5

;; Query time: 0 msec
;; SERVER: 169.254.169.254#53(169.254.169.254)
;; WHEN: Sun Mar 21 13:42:46 GMT 2021
;; MSG SIZE  rcvd: 96

You can see I use the internal 169.254.169.254 VCN resolver to resolve FQDN (fully qualified domain name) from the other VCN. Sweet! Similarly I can resolve addresses from Spoke towards Hub.

What about Spoke to Spoke DNS?

As of today (March 2021), if you want to resolve addresses between Spokes, you need to have LPG between Spokes and create rules between the Spokes when using listeners and forwarders. For example enabling DNS between Spokes my architecture would need more LPGs and rules. It would look like below.

From design perspective, be clear how VCN’s need to communicate so you don’t end up in DNS nightmare! Once again, this is just example when using Oracle VCN resolver, in most cases customers prefer to use their own DNS.

On next post I’ll be investigating options like separating Shared Services to own VCN as well as looking on adding Custom DNS in the mix. There are still some cases where Oracle Resolver is required – for example DBCS RAC and ExaCS limit your options.

Reminder on attaching private views

If you remember, on my old post I mention you can do this without forwarders and listeners, just attach private views from each Spoke VCN to your Hub VCN and the other way around:

This is a really simple way of doing this between VCN’s and you don’t need to create all those forwarders, listeners and rules. You’d still need those LPG’s for Spoke to Spoke traffic however.

Something to chew on how you design everything and if your DNS will be combination of all.