Having been involved with many site and domain migrations I thought I had seen everything, but recently I ran into a case where the DNS settings were very much in force but not accessible at all.
Using the whois domaintools site, I could see that the site was hosted at Rackspace, however the domain was configured to point to DreamHost Name Servers rather than to the Name Servers at Rackspace. So I logged into DreamHost to see how it was configured, but the account was closed. And had been closed since 2017!
So while the DNS settings appeared to be working just fine, we could not access them. They were a ghost, present but invisible.
How was this possible? Let me first cover some definitions, and then I will tell you how we ended up with ghost DNS settings, and what we had to do to migrate them off DreamHost.
DNS, Domain Name System, is a critical part of what makes the Internet work. DNS is a service that maps a domain name to the IP address where your site actually resides.
When you type a domain name into your browser, your request goes to one of many DNS servers which looks up the IP address for your domain name. Once the IP address is known, your request for a web page is then routed to the web server located at that IP address.
DNS Servers operate across the world and collaboratively share with each other DNS settings.
A DNS host is where the DNS Zone records (also known as DNS settings) are located. A DNS Zone has at least the A record set which makes the connection between your domain and the IP address. Other records that may be set include CNAME, MX and TXT.
It may be helpful to put a DNS Host in the context of all the components you need to have a website online.
You need a web host which has all the files associated with your website, and a web server that runs on your web host to serve those files to any requests it receives from the Internet. And you also need a domain that has been registered.
At some point many of you figured out how to separate your domain registration from your web host. Having your domain registered in a separate place gives you a lot more flexibility when you want to move your website. No need to unlock and transfer your domain, just update the domain to point to a new set of Name Servers where the website now resides.
You may not have realized this, but by pointing to the Name Servers on your web host, you are telling the world’s DNS servers that your DNS settings are being handled by your hosting provider.
In other words, your hosting provider is not only your web host, it is also your DNS host.
And it should be obvious that if your domain is registered at your web host, it handles every aspect of your domain.
However, this is not the only possible configuration available to you, for ultimate flexibility you can actually have a different DNS host, separate from your registrar and your web host.
This was the case for my client USP&E Global, Site 5 was the registrar, Rackspace was the web host, and DreamHost sat in the middle as the DNS host.
I don’t mind admitting that I was a little stressed at the prospect of having to re-create these records for a website migration without being able to see the originals. With technology such as DNS details matter and if it doesn’t work, it’s very bad.
A DNS A record is the most important DNS setting. It maps your domain to the IP address where your website files are located. You can think of the A record as a listing in an old style phone book. You look up the name to find a phone number. The DNS A record is very similar.
Here’s an example of a DNS A record.
Exactly how you enter an A record will depend on your DNS host. Usually, if you are mapping a root domain (rather than a subdomain) you will either leave the name blank or fill in “@”. The host will fill in the domain name as seen above.
All DNS records have a TTL (time to live) setting. This is the amount of time (in seconds) before the DNS servers will check with the authoritative DNS server (the DNS host where you have defined your DNS settings) for changes.
A common practice is to shorten the TTL a few days before making a change. This means that the checks will happen more frequently, speeding up the propagation of any change. A common setting for changes is 300, which is 5 minutes. Be sure to update the TTL back to a longer timeframe once propagation has occurred.
A Canonical Name (CNAME) creates an alias from one domain to another. By far the most common use of CNAME is to alias the www subdomain to the root domain.
With DNS a subdomain can have its own A and other DNS records. This is handy if you have a subdomain you want to host separately from your main site. Because it is widely used, it’s overlooked sometimes that www is also a subdomain. Setting the CNAME is really important, as you want the non www and www versions of your site to go to the same website.
Once the CNAME is set for the www subdomain, you often don’t have to change it, as you are continuing to alias the www subdomain to the root domain.
To enter a CNAME for www: you enter www for the Name and either leave the record blank to default to the root domain, or fill in the root domain explicitly.
As an aside, having the www subdomain mapped to the same IP address as the root domain doesn’t help with the SEO Canonical Site URL for the website. You still need redirects to enforce the Canonical Site URL with a 301 redirect to either the www or non-www version of your URLs.
A Mail Exchange (MX) record is used to tell the Internet which mail servers are handling the email for the domain. When you create an email address at your web host the MX records are created automatically. But if you want to host your email elsewhere you will need to configure your MX records.
There is an example of MX records later on.
Here’s what I think happened. Our site, uspeglobal.com, used to be hosted at DreamHost but the website was moved to Rackspace. Normally with a website migration you would just update the Name Server configuration at the registrar (in our case Site 5) to point to the Rackspace NS where the website files had been moved.
What throws a wrench into that plan is the MX records.
In our case the MX records were configured to point to the Google G Suite Servers. These of course were part of the ghost DNS records I couldn’t see, but a definite fact due to uspeglobal.com G Suite email working just fine.
Web hosts, including Rackspace have DNS Zone editors, so moving the MX records could have been an option, but as you can see below, Rackspace had no DNS settings configured.
It’s not clear what exactly was done at DreamHost when the site was migrated to Rackspace. DreamHost offers a feature called DNS only, that if you set a domain to, will “remove hosting and your site’s A records”.
Or, more likely, the A record was simply updated to the Rackspace IP address, and the MX records were left undisturbed.
When the account was closed, whatever state the account was in has persisted to this day.
As part of this migration, one major concern I had was migrating the MX records.
Like a lot of business, email is critical to USP&E Global, even more than their website.
Google has done a great job of documenting how to setup MX records for G Suite for your domain. In fact Google even provides specific documentation for many popular hosts.
However I could not find any documentation on how to migrate those MX records to another host. This lack made it unclear how much of the initial setup instructions had to be redone for a migration.
For example, the instructions make a point of telling you to leave the Admin Console tab open and to login your host in another tab, so I wondered whether there was some kind of underlying sync that needed to occur. As I am often juggling multiple Google accounts (clients as well as my own), I’ve often run into trouble when trying to connect another tool with Google data from Google Analytics or Google Search Console, because the verification (which you get no warning about!) fails because I’m logged into the wrong Google account. Maybe this isn’t a big problem for most people, but it is for me, and I’ve learned to be hyper aware of what Google account I’m logged into when working with anything Google related.
Additionally, in Step 4 of the setup instructions, there is also an activation step that is needed in G Suite Admin Console after the MX records have been entered.
Of course when you don’t have access to your client’s G Suite Admin Console, that meant some coordination had to be organized. Google wasn’t much help either, when asked what was different about a MX record migration rather than an initial setup, the support rep said “these instructions are perfect”.
Well as it turns out, all you have to do is enter the 5 ASPMX.L.GOOGLE records as MX records. No sync, verification or activation is required. No need for access to the G Suite Admin Console.
So now you know.
Here’s an example of G Suite MX records at CloudFlare DNS:
We were planning to migrate the site off Rackspace and as a first step, I wanted to recreate the DNS settings elsewhere. Since, it didn’t make sense to move the A, CNAME, and MX records to Rackspace (and then have to move them again), I decided to create them at Site 5.
Which turned out to be a mistake.
To get access to the DNS Zone editor for the domain, I was instructed by Site 5 Support to create a CPanel which involved clicking a link that kicked off a script. One that was done I could navigate to a CPanel that had a Zone editor.
Several days later I came back only to see the below warnings when trying to access the CPanel.
They may be just warnings, but they effectively stopped me in my tracks.
Site 5 support blamed my ISP for the problem. When I finally convinced them it wasn’t my ISP they provided a direct link (and new credentials) for the CPanel.
At that point I could get to the DNS Zone Editor to set up the A, CNAME and MX records.
In retrospect I probably should have waited until I had all the DNS records entered before I switched the domain to point at Site 5’s Name Servers. But this shouldn’t have broken things for 48 hours.
And broken they were:
One of the benefits of living here in Silicon Valley is that normally I see DNS updates happen really fast, often less in than an hour.
In the past when switching web hosts I’ve had to make a minor change (adding a comma somewhere on the home page for example) to be able to tell when the switch has occurred. That wouldn’t help here, of course, but in any case, I didn’t anticipate that the site wouldn’t resolve for the next 48 hours.
While it can take 24 to 72 hours for the DNS change you’ve made to fully propagate to the world’s DNS servers, I began to become very concerned when at 48 hours after the change, the A record was not resolving anywhere in the world.
The above graphic is from DNSchecker.org. This is a site you can use to track the propagation of the DNS change you made. All those red X’s mean that, even after 48 hours, nowhere in the world was the needed connection between the domain (uspeglobal) and the IP address being made.
As it was Sunday afternoon (already early Monday morning in some parts of the world), I needed to do something before the work week started … and fast.
What I’ve since learned is that DNS hosting is a whole other thing with many specialized providers. If you have a site that needs 100% uptime, you think you might be a target for a DDOS (distributed denial of service) attack, and speed is a concern; you might want to look into an enterprise level DNS host provider. One of the best known is Cloudflare.
If you are in the market for a DNS host, you can start by looking at this list that ranks DNS hosts by performance:
At the time I knew about dnsmadeeasy and their free trial, so I set up an account and created my A, CNAME and MX records there.
The dnsmadeeasy interface is basic but is pretty easy.
Next I logged into the registrar and changed the Name Servers.
There are actually 6 dnsmadeeasy Name Servers, but there were only 5 slots available. Just specifying the first 5 dnsmadeeasy NS servers didn’t seem to cause any problems.
Within 20 minutes I was seeing the DNS server at Google resolve the Name Servers for the domain:
And the site was up! It took another 8 to 10 hours to resolve properly elsewhere (such as South Africa when my client is based), but that was in time for the start of their Monday work day and I was happy to hear that email was working fine.
Kathy Alice Brown is a SEO expert specializing in Technical SEO and Content. In her spare time she loves to get outside.