There are three parties involved in putting your website online.
Firstly I should explain that a given company in many cases will do more than one of these jobs, and in some cases will do all three of these jobs – in fact during the purchasing of one service vendors will often prompt you (sometimes quite strongly) to upgrade to one of their packages and receive their other services.
Three parties
The three involved parties are:
The domain registrar – they create and manage the domain record (e.g. coderweb.net) and it’s associated information. Each root domain such as .net and .in and .co.in and .co are all independent with different policies and rules in place; it’s the registrars job to follow all of these policies and to have relationships in place for the registration of the domains with the root domain management organisations.
The dns host – they run a server which responds to “dns queries”. Imagine them like the white pages of the internet, but instead of one massive book with all of the entries, there is instead a single book for .com and one for .org and one for every other top-level domain, but it doesn’t have the actual listings in it, but instead it’s just got references to other books, and those other books have the actual entries. In the hosting space, the dns host is the organisation who manages those “other” books.
The web host – they run the actual web server where the web pages and dynamic scripts are hosted.
An example
Okay it’s time for an example. Let’s take coderweb.in for this.
Our domain is listed as registered by Net4 although to make things confusing is the various resellers and aquisitions in the domain space, and the actual registrar is Netregistry because they purchased Net4. This is easily found out using a whois tool which is just a search tool for the domain database.
Now if you look carefully at the whois record, you’ll see some Name Server: lines. These indicate the domain delegation to the name server. In the case of Coderweb, we’re delegating to three servers, all hosted at Dreamhost, one of our favourite web hosts. However, we also use Cloudflare for cloudhosting in which case the DNS would be set to Cloudflare which would route the data from Dreamhost.
The third part of the chain is the A record on the domain. The record is stored at Linode as they are the “authority” of the domain. In this case the answer is 208.113.186.83 which is a not-very-helpful number called an ip address and it points directly to the web server which is hosting our website.
Why do changes take so long?
The further up the chain you go, the slower updates are.
At the bottom of the chain (the web host), you can change something in your CMS and it’ll be updated instantly.
At the next level up (the a record), the time taken for a change is self-managed and it’s usually set to something reasonable, such as between 5 mins and 24 hours. Also, as this time is self-managed, it can be shortened before a server move, and then lengthened again afterwards.
At the top level (the domain delegation), changes happen very slowly. There is no way to speed these up, so you’re stuck with 24 to 48 hours. If you remember the white pages analogy, these top-level books are huge so it’s a requirement that they’re slow to update.
In summary
It’s never quite as simple as it seems! Hopefully this article has helped to clarify things more – even when it all feels like techno-gobbledy-gook.
