As I rambled about in my GoDaddy DNS management through OCI blog post, making changes to DNS scares people. A common refrain is “If it ain’t broke, don’t fix it,” and nobody wants to take responsibility for making changes because misconfiguration can cause downtime for your website. However, as with any technology or service, you should always look for ways to update, upgrade, and cut costs.
I’ve recently seen an influx of customers using Oracle Cloud Infrastructure (OCI) to do just that, specifically with the OCI DNS service. Leveraging its investment in Dyn, OCI provides some of the best and most cost-effective DNS and Edge capabilities in the market. In conversations with customers, the technical and financial aspects make total sense to them, but they become hesitant when they hear the word “migration.” So, I’m writing this post to explain how to test your zone’s behavior before going live, to ensure a seamless and error-free migration!
What is nameserver delegation?
There are two sides to DNS management. One is contacting a registrar to gain ownership of your domain; the other is managing your zone. The nameserver is what links these two together. When you buy a domain, you’re given a location to specify nameservers. When you create a zone in OCI DNS (and other DNS providers), you’re given a set of nameservers. Delegating your zone is the process of taking the nameservers provided by your DNS management service (such as OCI DNS) and putting them into your domain. Delegating your zone tells your domain to begin serving the records you set up with your DNS management service, and it makes your zone live on the public internet.
Testing DNS with dig
You can use BIND’s Domain Information Groper (dig) command line tool to test against the delegation where your domain is hosted. Because dig uses the OS resolver libraries, the Internet Systems Consortium (ISC) recommends using dig instead of nslookup. I’m using dig in this post, but I’m sure you can follow the same process with other tools. If you’re working with DNS, though, I encourage you to get familiar with dig. You can find more about testing DNS using dig in the OCI DNS documentation.
Migration recommendations
Although you can use the following method to test your zone’s behavior before migration, it’s a good practice to migrate a test zone first. Migrating a test zone gives you the best preview of the migration process and what your site will look like after nameserver delegation.
However, some companies might not have an extra domain to use as a test and might not want to spend the money to buy one just for testing (although I recommend that you do). In this scenario, how can you test your zone before going live with it? Read on to find the answer!
Prerequisites
All you need is a DNS zone. If you don’t have one, you can create one for free by signing up for an OCI trial. My zone is called testnsdirect.com, but feel free to call yours whatever you want.
Note the nameservers that come with the zone. I’ll be using them in the following scenarios.
Scenarios
I’m showing testing for these scenarios:
- Scenario 1: Standard DNS zone
- Scenario 2: DNS zone with active failover
- Scenario 3: DNS zone with geolocation steering
Although I’m showing only active failover and geolocation steering policy types, the process is the same using other OCI steering policy types.
Scenario 1: Standard DNS zone
My zone contains six records: the 5 default records and an A record that I added on the top-level domain pointing to one of my webservers.
Again, my zone is not live on the internet. If you navigate to testnsdirect.com, no site exists (at least at the time this post was published). So how can I ensure that the nameservers are serving those records? Thankfully, dig gives us a way to query a nameserver directly instead of our ISP’s resolver. That’s the trick for testing your zones before delegation.
The command has the following form:
dig @[nameserver address] [hostname]
Remember those nameservers? Now’s the time to use one of them. I’ll use dig to return all the records on the zone, querying the OCI DNS nameserver directly. Here’s my command (yours might vary):
dig @ns1.p68.dns.oraclecloud.net testnsdirect.com any
As the following results show, the records match what I set up in the Oracle Cloud Console.
Now I can be confident that the nameserver serves the correct records when I delegate the zone.
Scenario 2: DNS zone with active failover
I created an active failover steering policy on the testnsdirect.com zone with the following architecture. If you want instructions for this setup, read the blog post that I recently published about setting up active failover with OCI DNS.
Let’s see how the nameserver responds, using the same command from scenario 1.
The nameserver is serving 150.136.123.109, the Ashburn webserver that I set up as the primary. This is what I expected. Now, if I shut off the Ashburn webserver, it should fail over to the Phoenix webserver and serve 129.146.161.240.
As expected, the nameserver is serving the Phoenix webserver (129.146.161.240). Now I can be confident that the active failover policy behaves correctly when I delegate the zone.
Scenario 3: DNS zone with geolocation steering
This scenario is like scenario 2, but it uses a different steering policy. Geolocation steering policies distribute traffic to different endpoints based on the location of the user making the request. My policy steers requests originating in North America to the Ashburn server (150.136.123.109) and requests originating in Europe to the London server (132.226.211.20). It has the following architecture.
Let’s see what happens when I query it from each region. First, I’ll query the zone from my local machine, located in North America.
As expected, the nameserver is pointing to my Ashburn webserver. Let’s see what happens when I query the zone from an instance located in Europe.
Viola! The response has changed to the webserver in London. Now I can be confident that the geolocation steering policy behaves correctly when I delegate the zone.
Conclusion
This post walked through testing a DNS zone’s responses before nameserver delegation by using dig to query the zone’s nameservers directly. I did this for a standard DNS zone and then showed how to test steering policies with the same method. This method is useful because it lets you ensure that your zone is behaving as expected before delegation. Even though this kind of test can give you many insights, I still recommend migrating a test domain first to ensure that there are no surprises when you migrate your important domains.
Oracle Cloud Infrastructure provides enterprise features for developers to build modern cloud applications. If you want to try this lab out for free, I recommend the Oracle Cloud Free Tier with US$300 credits for a 30-day free trial. Free Tier also includes several “Always Free” services that are available for an unlimited time, even after your free credits expire.