How to manage your domain and its DNS configuration in a website migration

Written by Ramón Saquete

How to manage DNS registration during a website migration:

• Make sure your website is working correctly on a new hosting.
• Test your website on the new hosting by opening your domain in an Internet browser.
• Make your domain resolve the new IP address once you’ve made sure your website works correctly.
• Modify, if necessary, primary and secondary DNS servers.
• Deactivate your website in the old hosting provider during the migration, in cases where the website’s visitor information is stored.
• Transfer your domain to a different provider if necessary.

We do recommend you keep reading this post if you want to know and understand this entire process in detail.

In the past we talked about how to choose your domain name, but do you know what a domain is and how it works? Do you know the best way to purchase it? And what should you keep in mind when migrating it to another hosting? What is the best way to do it? What is a DNS server? How is it managed? You’ll find the answer to all these questions in this post.

What is a domain?

Websites and services on the Internet are hosted in computers, and computers have IP addresses, which are like telephone numbers which identify them. Because it would be rather difficult to remember all these numbers to access a website, we use domains. They have names that are easy to remember, but internally they transform into IP addresses, in a transparent manner for all users. Thanks to this arrangement, we can conveniently type https://www.humanlevel.com/ to see this website, instead of a string of numbers.

What should you keep in mind when purchasing a domain?

Usually hosting providers sell packages of a domain and its hosting, all in one. But you’re not obligated to purchase both services with the same provider if you don’t want to. As a matter of fact, I recommend keeping these two services separate, in order to be able to change domain and hosting providers independently when necessary.

Try to choose a reliable company, and always look up reviews first. You don’t want to wake up one day and find you’ve lost your domain, and in some cases, by extension, your entire business.

When registering a domain, we can normally choose the time we want to keep it before the next renewal date. Evidently, the longer we want to own this domain, the more we’ll have to pay at once. This period of time usually oscillates between 1 and 10 years, and then it’ll become publicly visible, which means Google will rank it better if we renew it for longer. We’ll have to enter contact information of three people (it can be the same person): an administration contact (domain manager), a technical contact (a person to contact in case there are technical issues, who is usually someone from the hosting) and a billing contact (a person to contact in cases where the provider might run into issues related to billing). The most important information is the e-mail address of the administration contact, which is what we’re going to need if we ever want to transfer the domain to another provider. Unfortunately, it’s a fairly common occurrence for web developing firms to purchase a domain for a client and put it to their name, instead of the client’s. It’s actually an illegal practice, and if this happened to you and your domain, request that they put your contact details to transfer the domain to you, because if this company shuts down you may end up losing your domain. And besides, the owner of the domain must be given the ability to manage it.

Contact information is public and it can be seen by anyone, including addresses and telephone numbers. Some users prefer to keep these details private, in which case they have to purchase a service called private WHOIS, which, of course, has an added cost. If anyone is wondering what a WHOIS is, it’s a protocol used to consult a domain’s contact information from any computer or an online tool. For Google, it’s best that this information is kept public, because it will interpret it as information of a business which has nothing to hide.

Once the domain is registered, it will take some time for it to become active, usually no longer than 24 hours.

How to renew the domain?

Your domain registrar will probably renew it automatically for you. If the automatic renewal fails to happen, there’s usually a grace period of about 30 days, during which you can renew your domain at no additional cost, and your provider will even notify you to do it. Once this time has passed, there is a “punishment” period, during which you can renew your domain, but paying an extra. After that, your domain would be pending removal, and ultimately it would become available again, for any user willing to purchase it.

So, as you can see, it’s quite difficult to lose a domain. In fact, it can be even more difficult to discontinue the service.

How to transfer a domain from a provider?

Domain transfers are blocked by default. So the first thing we need to do is to unblock the domain from the administration panel and request the Auth Code, which is a code used for authorising the transfer. The way to obtain this code varies from one provider to another, and it doesn’t exist for .es domains, for example.

The next step is to request the transfer to the new provider, which will require the Auth Code given to you.

Finally, you will receive an e-mail at the administration contact address, with a link to authorise the transfer. Once authorised, the domain shouldn’t take long to move.

What is a DNS server and how does it work?

The most complex and technical aspect of domain management is the DNS (Domain Name Server) management. This is the service in charge of translating domain names to IPs, a process called domain name resolution. If you’re not interested in understanding it in full, you can skip directly to How to configure your domain to resolve the IP address of the web server? But if your brain is eager for knowledge, keep reading.

To better understand the domain name resolution process, let’s see it with an example. Suppose we want to resolve or obtain the IP address of the domain www.humanlevel.com:

First, our computer will look within its DNS cache, and if it doesn’t find a response, it will launch a request to the DNS server we have configured for our IP (for example, 8.8.8.8). It will, in turn, check its own cache, and if it doesn’t obtain a response, it can launch another request to a different DNS for it to resolve it (recursive resolution), or, alternatively, it will carry out what is called iterative recursion. A graphical representation of the order of requests and responses (in red) would go as follows:

In the previous picture we can see the requests made by the iterative resolution, which I describe a little later.

In the following image we have the iterative resolution process for www.humanlevel.com and console.developers.google.com, where we can clearly see what is being requested at each level (I’ve added more levels than those appearing in the previous image to explain better how it works):

As you can see, in each level we request servers from the next level. To better understand these two schemes, let’s take a further look at the DNS server carrying out the iterative resolution:

Initialisation: we obtain the DNS servers from level 0 (root servers)

. -> All domains have a dot at the end, which represents the root of the domain. You don’t have to enter it manually in your browser, because it is added internally. For that reason, the first thing the DNS server does is ask: what are the DNS root servers? It immediately gets the auto response by looking a file called root zone file, which returns a list of the 13 DNS root servers.

NS b.root-servers.net.
NS c.root-servers.net.
NS d.root-servers.net.
NS e.root-servers.net.
NS f.root-servers.net.
NS g.root-servers.net.
NS h.root-servers.net.
NS i.root-servers.net.
NS j.root-servers.net.
NS k.root-servers.net.
NS l.root-servers.net.
NS m.root-servers.net.


As you can see, the responses are of type “NS” (Name Server), which indicate the name servers we need to make the request to in the next level. These servers are administered by public and private entities, most of them in the United States. Internally, some of them are not only one server, but a whole network of servers distributed all around the world. So if you were planning to bring about the end of the Internet by launching a simultaneous terrorist attack on the 13 DNS root servers, you know now that this isn’t exactly the most viable option.

Level 0: we obtain the level 1 DNS servers (TLD servers – Top Level Domain)

com. -> The next step is to go down to the next “.” of the domain and ask one of the root servers where the DNS server of the top-level domain “.com” is (as you’ve probably figured out by now, it’s the top level because it’s the first “.” after the root). There are many top-level domains.

This is the list of DNS servers the root server returns:
NS d.gtld-servers.net.
NS j.gtld-servers.net.
NS k.gtld-servers.net.
NS m.gtld-servers.net.
NS l.gtld-servers.net.
NS f.gtld-servers.net.
NS e.gtld-servers.net.
NS g.gtld-servers.net.
NS h.gtld-servers.net.
NS a.gtld-servers.net.
NS c.gtld-servers.net.
NS b.gtld-servers.net.
NS i.gtld-servers.net.


.com DNS servers belong to the VeriSign company, which is also the owner of the domain registry Network Solutions. These people are, ultimately, the beneficiaries for all .com and .net domain sales. And that’s where the money comes from to maintain these servers and the root servers (VeriSign owns two of them). You must know that, even though Network Solutions is the most important domain provider, this doesn’t mean they are the cheapest, or provide the best service. Quite the contrary, the resellers offer better prices.

ICANN (Internet Corporation for Assigned Numbers and Names) is a US non-profit organisation in charge of assigning IP addresses and controlling the DNS system management. This organisation prevents root servers from inventing their own top-level domain extensions, or that root server managing entities carry out illegal practices. To name such a case, back in 2003, VeriSign redirected all unregistered .com domains to one of its websites, and the ICANN had to take them to trial to make them remove this redirection.

Level 1: we obtain the second-level DNS servers (second-level domain server)

humanlevel.com. -> At this point we will ask one of the top-level domain servers .com –obtained in the previous step– on which DNS server is humanlevel.com located. This question should be answered with the DNS server configuration: primary, secondary, etc. that we’ve set in the administration panel of our domain’s DNS configuration.
NS ns1.dnsserver.com
NS ns2.dnsserver.com


These DNS servers always come for free when we purchase a domain or a hosting. We can thus use either the DNS server provided by the domain registrar, or by the hosting, interchangeably. Changing this information only takes a few minutes if our domain has a .com extension, and up to 5 hours if our domain’s extension is .es, because top-level .es domains update their servers every 5 hours. This is something we should be very much aware of in cases of hosting migrations.

Level 2: we obtain the final response or a third-level DNS server

www.humanlevel.com. -> now one of our domain’s DNS servers is requested the www subdomain (if a website doesn’t have a subdomain, it would directly request humanlevel.com). This server can respond with another NS entry for www.humanlevel.com, which would force it to ask another DNS server about it, or, on the contrary, it can return now the final response with a DNS entry of type “A”:

www.humanlevel.com A 82.223.131.156

Finally, we will have the IP address returned to the user who entered www.humanlevel.com in the address bar of their browser, which is 82.223.131.156 (an IPv4 is always comprised of 4 blocks divided by “.”, never higher than 255). If the server also works with IPv6, then it should return a DNS register entry of type “AAA”, the IP number of which is comprised of eight four-digit groups in hexadecimal numbers.

Given its level-based structure, it’s usually said that each DNS server has the authority over its corresponding domain zone. In our example, ns1.dnsserver.com is the DNS server with authority over the humanlevel.com zone, as well as all its lower-level subdomains.

How to configure a domain for it to resolve the IP address of the web server

To achieve the resolution of names from the previous section (www.humanlevel.com to 83.223.131.156) we’ve done two things:

1. Put the web server IP we want the domain to resolve as an “A” entry in the DNS registers ns1.dnsservers.com and ns2.dnsservers.com, which we will be able to configure through either the domain panel, the hosting panel or an external DNS service like Amazon Route 53, depending where these servers are. The important thing here is to avoid making mistakes and to configure the name servers we’re going to use. The IP of the web server should be obtained beforehand from our hosting provider, and if we’re using its DNS servers, it’s probably configured already, so we won’t have to modify anything.
2. Configured from the domain administration panel the primary and secondary DNS servers, ns1.dnsservers.com and ns2.dnsservers.com, so this information has been copied to .com DNS servers, which made ns1.dnsservers.com and ns2.dnsservers.com the servers with authority over humanlevel.com. To configure DNS servers we usually have to enter the domain, and sometimes, its IP address as well. We should’ve got this information beforehand from the hosting provider (if we’re using the hosting’s DNS servers) or from the domain provider (if we’re using its DNS servers). When registering a domain, it normally comes pre-configured with the DNS servers of the provider with whom it’s been registered. Here’s an example:

The above image belongs to the DNS configuration panel of Network Solutions domain provider. We can see two options for setting up primary and secondary DNS, either by entering what we need in the corresponding field, or by assigning them automatically with the button “Move All to Network Solutions”, which will automatically assign its own. This latter option is available on most domain provider administration panels. To apply the configuration stated in this example, we would have to type ns1.dnsservers.com into “Name Server 1” and ns2.dnsservers.com into “Name Server 2”, and then hit “Move DNS”.

As you can see, the configuration always depends on our own circumstances, and if we understand what we’re doing, we’ll know how to do it without getting it wrong. In the picture below I show how to proceed in each particular case, so that it’s plain to see:

Additionally, we would have to add another “A” entry for humanlevel.com, or, instead, we can use the CNAME registry to state that the www.humanlevel.com subdomain has the same IP address as humanlevel.com. This is how it’s done:
humanlevel.com A 4.4.4.4
www.humanlevel.com CNAME humanlevel.com


How to configure the DNS cache

The iterative resolution process requires a significant hubbub of network requests, and some DNS servers carry out cached recursive requests to optimise times. For example, when requesting www.humanlevel.com, the computer will first look up the IP in the DNS cache of your operating system. If it’s not there, it will carry out a recursive request to the DNS server you have configured, which will check its own cache. And if it doesn’t find it there either, it could once again ask for it recursively to another DNS server, until one of them responds to the request iteratively or recursively. The time each DNS register entry lasts in the cache depends on the set Time to Live (TTL) within the SOA registry (Start of Authority) of the DNS server with authority over the zone.

For example, let’s imagine we have a 24-hour TTL. This means that if we change the IP resolving the domain, during this period of time our domain will be able to resolve both the old and the new IP, because some DNS servers will have cached it, while others not. To solve this issue we can change the SOA registry settings, by setting the TTL to only 600 seconds (10 minutes). Once that’s out of the way, we’ll wait 24 hours for all the caches to be updated and set to the new TTL.

How to manage the DNS registry of your domain during a website migration

At last, let’s see which tasks you need to carry out in the DNS registry when you’re migrating a domain:

Check that your website works correctly on the new hosting. To do this, we will add the IP address of the new hosting, together with the domain, to the configuration file “hosts” on your computer (its location will depend on the operating system you use). This will make your computer resolve the domain with the IP you set in this file, instead of carrying out a DNS request.

Check that your website is working with the new hosting by entering the domain in the address bar of your browser, although it’s possible you’ll need to erase its DNS cache first (to do this in Chrome you’ll need to go to chrome://net-internals/#dns) and your operating system’s DNS cache as well. The “hosts” file is a vestige of how domain names were resolved before the DNS was invented, but it’s still in use because it comes in handy for faking requests.

Make your domain resolve the new IP, once you’ve made sure your website is working correctly. If the administration panel of your DNS server allows you to modify the Time to Live of your SOA registry (sometimes it’s not possible, but we can try requesting it to our hosting provider), and do it ahead of the migration. I.e., if your TTL was set to 24 hours, change it to 10 minutes and wait one whole day for the caches to get erased, to change the “A” entry for your website’s hosting. This method is not 100% reliable, because the TTL may get ignored by some DNS servers, but in most cases it will speed up the migration process.

Modify –if necessary– the primary and secondary DNS servers (making sure that you have the same configuration in the new DNS server), once the changes have been applied.

Deactivate your website in the old hosting during the migration if it stores your visitors’ information, namely purchases, sign-ups, etc., so that during these 10 minutes, users who cached the old IP address in their DNS server won’t make orders that will get lost in the data base of a hosting that is set to disappear shortly.

We can make the switch directly and to monitor how it spreads gradually, using an online tool such as https://www.whatsmydns.net/, if we’re not worried about cache propagation, or if we cannot modify the SOA registry.

Transfer your domain to another provider if necessary, but always making sure beforehand that the new provider has the primary and secondary DNS configuration that it should have.

And finally, in a migration you must also keep in mind SEO-related aspects, which we will talk about in other posts in the future, as in this article we only explore domain-related aspects.

Following our guide you will be able to change your domain’s hosting without losing mails, transfer your domain to another provider, or change your mail provider with little to none issues.

In summary, this is pretty much all we need to know to successfully change our domain. A comprehensive explanation would probably take a book or two, but I think this post covers all the essentials.