GoDaddy DNS management through Oracle Cloud Infrastructure

February 19, 2021 | 9 minute read
Cody Brinkman
Cloud Architect
Text Size 100%:

How OCI manages GoDaddy DNS

Can OCI handle GoDaddy DNS management (or management from any domain registrar)? 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 registered, 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 DNS management as an example, but the steps apply to most registrars. The process is quick and painless with no downtime if done correctly.

Prerequisites for domain management

  • GoDaddy or otherwise registered 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.

Why manage your zones with OCI DNS management?

  • 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.

What is DNS in domain management?

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 Humans access information online through domain names, like 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.

How does DNS resolution work?

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.

A graphic depicting the process of a DNS resolver finding an IP address for a host name by connecting to other servers.

  1. First, your browser and operating system check their own cache for If they can’t find the IP address, they send the request the next level.

  2. The next level is the resolver server, which is your internet service provider (ISP). The resolver checks its own records for the IP of 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.

  3. 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, In our example, the root server directs the resolver to the TLD for the .com domain.

  4. The resolver now asks the TLD server for the IP address of 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.

  5. We’ve made it to the final destination of our DNS lookup request. The authoritative name server does know the IP address of and any existing subdomains.

  6. We did it! The resolver sends back the IP address of, 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.

TTL and why it matters

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 example. If we make a record with a TTL of 3,600 seconds, or 1 hour, pointing to, the servers store the information about that record for an hour. Even if we change the record to resolve to, anyone who uses that same resolver gets the record’s original information,, because no query is sent to the server until the TTL runs out. After the hour is up, the downstream servers update, and resolves to the new value of

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!

Steps for GoDaddy domain management with OCI DNS

  1. Navigate to your GoDaddy domain in their domain manager.

    A screenshot of the GoDaddy Domain Manager screen.

  2. Select Manage DNS.

    A screenshot of the Manage DNS section of the Domain Manager.

  3. In Advanced Features, click Export Zone File.

    A screenshot of the Advanced Features section with Export Zone File (Unix) highlighted.

  4. Log in to your OCI tenancy and navigate to Networking and DNS Management.

    A screenshot of the OCI Console with the menu expanded, Networking highlighted, and DNS Management outlined in red.

  5. Create a public zone. OCI DNS can also create several other types of zones, but they're not relevant to us right now.

    A screenshot of the DNS Management page in the OCI Console with the Zones section highlighted and the Create Zone button outlined in red.

  6. 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.

    A screenshot of the Create Public Zone window in the Console.

  7. 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.

    A screenshot of the example DNS zone for in the Console.

  8. 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.

    A screenshot of the Nameservers section of the GoDaddy Domain Management.

  9. Click Enter my own nameservers (advanced) and enter your OCI zone’s name servers.

    A screenshot of the Enter My Own Nameservers window.

  10. Our domain is now managed by OCI! Let’s make a new record to test this out.

    A screenshot of the Add Record section in the OCI Console.

  11. 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.

    A screenshot of the Records page with the Publish Changes button outlined in red.

    A screenshot of the resulting test page for Nginx on Fedora.

Next steps for DNS management

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 for DNS management, 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.

Cody Brinkman

Cloud Architect

Cody is a Cloud Architect for Oracle Cloud's Commercial accounts

Previous Post

Simplify Spark monitoring with OCI Data Flow application metrics

Carter Shanklin | 4 min read

Next Post

Integrating OCI Notifications with Syniverse

Igor Aragao de Souza | 4 min read