We looked on setting up Oracle DNS on part 1, and how you could manage different DNS options with Private Views or DNS listeners & forwarders. In this post I’m gonna look on what options we might have with Custom DNS.
Custom DNS is typically used when there’s a requirement to use already existing DNS services. In this post we have existing Domain tfg.internal which will be used.
To simplify setup I have two VCN’s only, our Hub VCN and Spoke VCN. Hub VCN needs to use our custom DNS but SpokeA VCN has requirement to use Oracle DNS (VCN Resolver). This is due to reason it has RAC Database running on the subnet.
In reality, I have only compute instance there but that’s an actual limitation with OCI as of April, 2021. If you use RAC or ExaCS you are required to use Oracle VCN Resolver (for oraclevcn.com FQDN’s) for those subnets where you have these services running. Inside same VCN the other subnets can use custom DNS however.
Custom DNS Setup
For testing custom DNS I’ve setup compute instance on Hub VCN. It will serve domain requests for tfg.internal and has IP address of 10.0.0.6. Nothing fancy, but I’ve followed instructions from here: https://opensource.com/article/17/4/build-your-own-name-server.
In the zone file I have following A records inserted:
tfg-dns IN A 10.0.0.6
hub1 IN A 10.0.0.6
spoke1 IN A 10.0.1.6
So whoever uses my custom DNS server should be able to resolve my hub compute instance hub1.tfg.internal and my spoke compute instance spoke1.tfg.internal.
Just a tip: Once you start using DNS servers remember to open necessary firewalls on the server and in the security lists / NSGs.
Option 1 to setup VCNs
When you setup VCN’s and Subnets in OCI, you define DHCP options for Subnet. DHCP Options consists of DNS servers and Search Domain, once these are set you will see them on your compute/db instance /etc/resolv.conf file when you create/reboot server.
I was thinking if there’s a way not to use anything else apart from internal 169.254.169.254 resolver now that we have Private DNS available and came up with below solution.
On both VCN’s I’m using Internet & VCN Resolver (169.254.169.254). Search Domain for Hub VCN is tfg.internal since I want to use shortnames when resolving hosts from that domain.
Search Domain on Spoke VCN is spokea.oraclevcn.com. I’ve also associated SpokeA’s Private View to Hub VCN – this is so I can resolve also FQDN addresses for oraclevcn.com domain in that VCN.
On both VCN’s I’ve setup DNS forwarder against my custom DNS server 10.0.0.6 when domain is tfg.internal.
Testing out option 1
I’m now logged to my Custom DNS Server on Hub VCN and my resolv.conf is following:
search tfg.internal subhub1.vcnhub.oraclevcn.com vcnhub.oraclevcn.com
nameserver 169.254.169.254
I don’t have my custom DNS server defined here at all, if we look on DNS forwarding rule I have for this VCN, it shows all tfg.internal domain queries get forwarded to 10.0.0.6. Let’s try it!
[root@compute-hub-1 ~]# nslookup spoke1.tfg.internal
Server: 169.254.169.254
Address: 169.254.169.254#53
Non-authoritative answer:
Name: spoke1.tfg.internal
Address: 10.0.1.6
I can resolve tfg.internal domain on a host running in Spoke VCN by using my Custom DNS! Remember, I’ve attached Spoke VCN Private View so I can also resolve oraclevcn.com addresses in Hub VCN. Sometimes it might make sense if you have DB SCAN address and want to use it to access database without adding it to your custom DNS.
[root@compute-hub-1 ~]# nslookup compute-spokea-1.subspokea1.vcnspokea.oraclevcn.com
Server: 169.254.169.254
Address: 169.254.169.254#53
Non-authoritative answer:
Name: compute-spokea-1.subspokea1.vcnspokea.oraclevcn.com
Address: 10.0.1.6
It works too without issues. What about using custom DNS in our Spoke VCN which uses Oracle Resolver?
search vcnspokea.oraclevcn.com subspokea1.vcnspokea.oraclevcn.com
nameserver 169.254.169.254
My resolv.conf has above entries and if I resolve tfg.internal domain address it works smoothly.
[opc@compute-spokea-1 ~]$ nslookup hub1.tfg.internal
Server: 169.254.169.254
Address: 169.254.169.254#53
Non-authoritative answer:
Name: hub1.tfg.internal
Address: 10.0.0.6
Option 2 to setup VCNs
We can also utilize DHCP options differently and point Subnet to use my custom DNS server directly. On Spoke VCN nothing has changed but following changes are done for Hub VCN:
- Removed forwarding rule to 10.0.0.6
- Changed Subnet DHCP options with DNS servers being 10.0.0.6 & 169.254.169.254
- Rebooted Hub Compute instance
So why did I keep 169.254.169.254 as DNS server? I still want to resolve Spoke VCN FQDN’s by using associated Private View. If I wouldn’t need that, I would just not add 169.254.169.243 as DNS server. Many times that’s actually the case and you add database hostnames to your custom DNS and use connection with those names, sort of an overlay.
[root@compute-hub-1 ~]# nslookup spoke1.tfg.internal
Server: 10.0.0.6
Address: 10.0.0.6#53
Name: spoke1.tfg.internal
Address: 10.0.1.6
As you can see above, I can resolve tfg.internal domain again when it uses my custom DNS server.
[root@compute-hub-1 ~]# nslookup compute-spokea-1.subspokea1.vcnspokea.oraclevcn.com
;; Got SERVFAIL reply from 10.0.0.6, trying next server
Server: 169.254.169.254
Address: 169.254.169.254#53
Non-authoritative answer:
Name: compute-spokea-1.subspokea1.vcnspokea.oraclevcn.com
Address: 10.0.1.6
;; Got SERVFAIL reply from 10.0.0.6, trying next server
Trying out oraclevcn.com address from Spoke VCN I get SERVFAIL from 10.0.0.6 which then makes the query move on to next server on my resolv.conf, which in this case is 169.254.169.254.
Resolv.conf after modifications:
search tfg.internal subhub1.vcnhub.oraclevcn.com vcnhub.oraclevcn.com
nameserver 10.0.0.6
nameserver 169.254.169.254
Remember after making changes in DHCP options they will get automatically updated to your resolv.conf after reboot.
Summary
Due to some restrictions with RAC and ExaCS you might still need to have Hybrid DNS in place, I believe this might change in the future which would make some deployments easier. In this post you’ve seen two ways to setup DNS in OCI and what kind of configuration they require.
I hadn’t really thought on using 169.254.169.254 as single resolver before this post but noticed it as an option when I was trying out different setups. It obviously adds one additional hop since it first goes to 169.254.169.254 resolver which forwards the query to 10.0.0.6. Just something to keep in mind.