A common use case I've seen recently is individuals who have their domain registered with GoDaddy but want to use Oracle Cloud Infrastructure (OCI) to manage their DNS zones. Why use OCI DNS? Read on!
I am writing this blog to ease the minds of people wanting to start using OCI to manage their DNS zones, but are scared to actually click the "change" button. Almost every time, and for good reason, I am met with, "Wait! Are you sure this will not completely mess up access to my application? You promise?". And hey, I get it. DNS management is scary. An error in DNS management can yield your application inaccessible. For many companies, this downtime means large financial loss.
I use GoDaddy as an example, but the steps apply to most registrars. The process is quick and painless with no downtime if done correctly.
An existing domain name. Oracle is not a registrar, so you need to buy your domain from a vendor.
OCI tenancy and user with proper permissions. You can find a policy example for DNS in the documentation.
A publicly exposed website. The IP address of this site is what our hostname resolves to. I deployed an Always Free Compute instance and installed a simple Nginx web server.
DNS responsiveness: Use industry-leading DNS query response time to optimize your application performance. DNS records are globally propagated in under a minute.
Supported records: Oracle supports 27 common DNS resource record types, including A, AAAA, CNAME, DNSKEY, MX, NS, SOA, and TXT.
Secondary DNS: To ensure that critical applications remain available, set up a secondary DNS as a redundant complement to your primary DNS.
DDoS protection: OCI DNS protects against common layer 3 and 4 attacks, such as SYN floods, UDP floods, ICMP floods, and NTP amplification attacks. Distributed denial of service protection is included with all OCI accounts with no configuration required. Monitoring is provided around the clock for malicious activity at no extra cost.
Global anycast network: Within an anycast network, the point of presence closest to the user making the request answers DNS requests, ensuring the fastest possible DNS performance.
The domain name system is the phone book of the internet. Web browsers interact with each other through IP addresses, which are 32-bit (IPv4) or 128-bit (IPv6) numbers. An example IPv4 IP address is 192.168.17.43. Humans access information online through domain names, like oracle.com. Every time you type into your web browser, a translation occurs between what you typed and the machine-friendly IP address. DNS resolution does this translation and converts host names into computer-friendly IP address.
Resolving a domain name has multiple phases. Sometimes, it can be a one-step process, while others, it involves contact with multiple servers. The following diagram explains what happens when you type a host name into your browser.
First, your browser and operating system check their own cache for oracle.com. If they can’t find the IP address, they send the request the next level.
The next level is the resolver server, which is your internet service provider (ISP). The resolver checks its own records for the IP of oracle.com. If the necessary information is present in the server’s cache, the resolver sends back the IP address of the host name. If it isn’t in the server’s cache, the request goes to the next level.
These ISP DNS resolvers are configured to ask other DNS servers for the correct IP address. The first and top-level servers in the DNS hierarchy are the root servers. Thirteen sets of root servers are strategically placed around the world. These 13 sets are operated by 12 different organizations to ensure correctness, availability, and security.
Root servers don’t map domain names to IP addresses. Instead, they hold information about top-level domain (TLD) servers. TLD is the end section of a domain name, such as .com, .org, and.gov. In our example, the root server directs the resolver to the TLD for the .com domain.
The resolver now asks the TLD server for the IP address of oracle.com. Again, the TLD server doesn’t know the IP address. These servers contain the data for second-level domains. The TLD therefore directs the resolver to the next and final level: the authoritative name servers.
We’ve made it to the final destination of our DNS lookup request. The authoritative name server does know the IP address of oracle.com and any existing subdomains.
We did it! The resolver sends back the IP address of oracle.com, and our web browser directs us to the site. The record for the host name is cached on our local machine, where it can be fetched in the first step for future requests.
While it seems like a lot of steps, the entire process takes milliseconds. Your eye can’t tell the difference between a request that traverses the entire DNS hierarchy or a request in a local cache.
In my experience, time to live (TTL) is the least understood aspect of DNS. TTL is an expiration date for on a DNS record. It tells the DNS server or resolver how long to cache a query before requesting a new one. The longer the TTL is, the longer the server holds the information in its cache. The shorter the TTL is, the shorter the server holds the information in its cache.
Let’s use our oracle.com example. If we make a record with a TTL of 3,600 seconds, or 1 hour, pointing oracle.com to 188.8.131.52, the servers store the information about that record for an hour. Even if we change the record to resolve to 184.108.40.206, anyone who uses that same resolver gets the record’s original information, 220.127.116.11, because no query is sent to the server until the TTL runs out. After the hour is up, the downstream servers update, and oracle.com resolves to the new value of 18.104.22.168.
For records that change often, best practice says to keep the TTL as short as possible. This way, when a change occurs, end users are given the most recent information. Since we’re changing our DNS management information, I suggest lowering the TTL of your records before migration. Therefore, the DNS hierarchy servers’ caches refresh to the new DNS information sooner. When the migration is complete, you can raise the TTLs to normal levels.
I hope you learned something new with that DNS resolution and TTL crash course. Now let’s get to what you clicked this blog for!
Navigate to your GoDaddy domain.
Select Manage DNS.
In Advanced Features, click Export Zone File.
Log in to your OCI tenancy and navigate to Networking and DNS Management.
Create a public zone. OCI DNS can also create several other types of zones, but they're not relevant to us right now.
Click Import and select the downloaded text file. I had to delete a ’parked’ record for import to work. I’m not sure if this is present in every GoDaddy domain.
Our zone is now created with all the records we had in GoDaddy! Give the records a quick look to confirm that everything imported correctly. We use the name servers in the next step.
In terms of our domain, we haven’t changed anything. We created a zone in OCI that’s not connected to our registered domain in GoDaddy. If you remember, the authoritative name server stores the domain’s IP address and sends it to your browser. We need to tell GoDaddy to stop using GoDaddy’s default authoritative name servers, and instead use OCI’s name servers. This process transfers the zone management from GoDaddy to OCI. If you head back to GoDaddy, we can change the name servers that our domain uses.
Click Enter my own nameservers (advanced) and enter your OCI zone’s name servers.
Our domain is now managed by OCI! Let’s make a new record to test this out.
Publish the change. It can take some time for the new record to publish on the web, because the name servers are still updating on the backend. However, all your existing zones work as normal.
In this post, we walked through how to transfer zone management from GoDaddy to OCI with no interruptions to our site. We first replicated our zones by exporting them from GoDaddy and importing into OCI DNS. The actual transfer of management happened when we told GoDaddy to start using OCI’s name servers instead of the default name servers that came with the domain. This example used GoDaddy, but the steps are applicable to other domain registrars.
Even though the steps seem straightforward, I recommend that you migrate a test zone first. This step ensures that you know exactly what you’re doing and how your site behaves when it comes time to migrate production zones.
A great way to test this process out yourself is with a 30-day free trial of Oracle Cloud Infrastructure, which includes US$300 in credit and our Always Free services.