Previously on the CogitActive Saga:
My domain name was now pointing to my hosting provider. I just had to wait for the changes to propagate.
Doing something for the first time is always intimidating. Pointing my domain name to my website should not have been so complicated. Doing so, while keeping my e-mails at my registrar, however, proved challenging. Indeed, this configuration was not usual, and I had to figure out the procedure on my own (see Pointing my domain name to my website).
I just want to remind you that I am not a web developer nor a web-designer. Granted, I am a researcher and problem solver, but my subject matter has nothing to do with websites. I knew that launching myself into this podcasting adventure would require me to learn new skills (see The Who and the When). Still, I didn’t expect the task to be so demanding.
How to know if I applied the correct settings? There was no tutorial, no step-by-step guide – not much help indeed. There is only one way to know: wait and see!
How long should it take?
First, let me explain the concept of DNS propagation (DNS standing for Domain Name System). It is the time it requires for the change to your DNS records to take effect worldwide. As DNS is a distributed, hierarchical system, any change you make needs to be updated through the whole network, i.e. every DNS servers in the world.
As explained in the aforementioned post, the zone file of your domain name resides on the Authoritative Domain Name Server. Within the zone file, the Name Server (NS) Records (aka namesersers) indicate which servers are responsible for the zone file. A reason why the system is configured this way is that the [Top-Level Domain (TLD)] nameservers need to be able to access that information so they can check whether your nameservers have changed
1.
Another reason for defining nameservers within the zone file is that the zone file may be actually being served from a cached copy on another name server
2. In addition to the Authoritative Name Servers (the most up-to-date servers), there are indeed Secondary Name Servers, which hold a copy of the records from the Authoritative Name Servers. This helps to share DNS server load and to improve DNS zone availability.
How long?
In short, all the servers in the network have to update their records. It takes some time for them to catch up. How much time it takes is not an easy question to answer, though.
DNS will refresh according to the Time to Live (TTL). The convention seems to be at least 14400 seconds (4 hours) for A Records and up to 86400 seconds (24 hours) for NS Records, according to Peter Pollock2. Therefore, depending on the method used to point a domain name – changing A Records vs. updating NS Records – DNS propagation could take from few hours (4 hours) to a full day (24 hours). Yet, because other factors (than TTL) can influence DNS propagation, some articles are more conservative than others, referring to longer periods (up to 3 days). As for Gandi’s Online Documentation (Gandi being my registrar), it provides the following tip:
Please wait 12-24 hours for the DNS propagation to occur before testing.
Patience
Of course, I knew the changes would not take effect immediately. Yet, I was eager to see my website online, and even more importantly, I was anxious about the procedure itself. Will it work?
Patience is not only the ability to wait – it’s how we behave while we’re waiting.Joyce Meyer
I needed to know if my settings were correct. I was worrying too much to wait impassively, therefore I started checking if I could access my website.
4 hours after the DNS change, my domain is not resolving yet.
How to remain patient in such a situation! Moreover, there are so many articles stating that the domain name should resolve in few hours only. Even the Knowledge Base of my hosting provider indicates that most often [DNS change] happens in a matter of hours
.
6 hours after the DNS change, still nothing.
Why is it not working? I kept repeating: Be patient, wait at least 12 hours
. Although I knew that Gandi recommends waiting 12-24 hours, I could not make me see reason. Did I mess up something?
Caches
When you access a website using a domain name, the query result (i.e. the correct Internet Protocol (IP) address for that domain name) is stored in caches in order to improve performance. The next time you have the same request, the DNS information is directly pulled from the cache (instead of searching again for the IP address). This process speeds up the loading of the website and reduces the traffic load on DNS. In effect, DNS caching occurs at different levels:
- Operating System (OS)
- Internet Service Provider (ISP)
Obviously, I had first to learn how to clear the local DNS cache in my OS. Then, I run several times the ipconfig /flushdns command but not to avail.
Successfully flushed the DNS Resolver Cache.
In addition, the first time you visit a website, your browser makes copies of the website content in order to make it load faster next time you visit it. Therefore, I was also clearing up the caches of my browsers. Still, I could not see my website. Flushing was not helping.
In fact, refreshing my local cache was probably pointless, as I could still be misdirected by my ISP for a while. The latter may retain information for 48 hours or more
1.
Did I forget something?
After searching for any other logical reasons that could explain why DNS propagation can take such a long time, my anxiety gave way to dread.
24 hours after the DNS change, still no website.
That was beyond the period suggested by Gandi (see above), and yet, the DNS propagation was not completed. Worst, when I looked up for my WHOIS records using the Whois Lookup tool, the listed nameservers were clearly those of SiteGround. Something was obviously wrong, but what?
When I was searching how to point my domain name to my website using the nameservers method, I went through few articles describing an extra step that I did not applied. Specifically, immediately after updating the nameservers (in the registrar account), they were adding the domain name to their hosting account. Apparently, this step aims at creating an empty folder in the server (for your website). To do so, they were using the Addon Domains tool in cPanel (in their web hosting account).
However, after some investigation, I realized that this step was for setting up a second domain on an existing hosting account. Not only this configuration was not applying to my situation, but also I could not have use it as my StartUp plan allows one website only (see Getting my web host).
SiteGround offers unlimited addon domains for all hosting plans, except the StartUp plan.
Besides, I knew that my account was already set:
We have activated your account with the temporary subdomain cogitactive.com to work with.The SiteGround Team
Did I mess up something?
I kept searching what could have gone wrong.
36 hours after the DNS change, my domain is still nor resolving.
By now, I was confident I used the correct approach to point my domain name to my website while keeping the e-mail services of my registrar. SiteGround tutorial was indeed stating that if you want to transfer your website only and keep [e-mails] hosted remotely, once you change DNS, you need to point your MX Records to your current [e-mail] host
.
I was quite sure I did set my DNS correctly – this was a straightforward thing to do. However, I could have messed up something while changing the MX Records afterward. In particular, I added an extra TXT Record that was listed with Gandi MX Records (see Pointing my domain name to my website). First, I didn’t know whether I should add this Sender Policy Framework (SPF) Record or not. Second, I was not sure that I did it properly. Third, I didn’t remove the original SPF Record (the one from SiteGround) even though I deleted SiteGround MX Records. Could any of these two TXT Records be the culprit?
Logically, these issues, if any, should only affect my e-mails, not my website. Moreover, I was constantly checking if I could send and receive e-mails. Visibly, both my Gandi e-mail accounts were working just fine.
I was on the verge of not being rational anymore. However, I knew that the best way to mess something up is to try fixing a problem that doesn’t exist. Therefore, I refrained from manipulating my DNS further.
Be patient! Up to 78 hours!
Relief
Fortunately, I resisted the temptation to change any of my settings.
48 hours after the DNS change, I can access my website.
Why did it take so long? I can see two explanations (and it is presumably a combination of both).
First, I went through this process apparently too early. Specifically, I did change the nameservers of my registrar with those of SiteGround only few hours (less than 6 hours to be exact) after registering my domain name. Gandi informed me, when I registered my domain name, that it would take 24 to 72 hours
for my domain to be fully available. Yet, I didn’t wait!
Second, while DNS propagation can happen in few hours, it can take up to 72 hours. Why? A nice explanation is provided in this article. I invite you to read it as their example fit my case quite nicely. Indeed, at the time, I was trying to reach – from Germany – my USA hosted website. Not mentioning that my registrar was in France! My DNS was almost certainly resolved in USA way before I could access my site from Germany. Actually, I could have followed the propagation with this Global DNS Propagation Checker tool. That would have spared me some stress.
Patience is bitter, but its fruit is sweet.Jean-Jacques Rousseau
1 Peter Pollock (2013) Web Hosting For Dummies. Hoboken, New Jersey: John Wiley & Sons. ^
2 Justin Ellingwood (2014) An Introduction to DNS Terminology, Components, and Concepts. DigitalOcean.