How a Domain Becomes a Website

Gimme an A...

When a domain name is registered it is yours to do with what you wish.

However... how do those services go from a domain you've just registered to functioning applications?

Let's take one simple task. Making a domain name work as website on a web server you already own and control...

Before we dive in though, you have to ask yourself, "What is a domain name and why do we need them?"

Domain Names are easy ways to remember a website's home.

I know that if I want to buy something it's most likely going to be found on or (Or or for me) and I automatically know and remember their web address... their domain name.

But did you realise there is another way to access those sites without typing in their domain name?

Yup, I could enter their IP address directly into my browser's address bar.

Here is the IP addresses that the DNS system tells me are A record(s) for the hostname,


jason$ nslookup



Non-authoritative answer:













N.B. Your results may deliver different IP addresses. I'd suggest typing the command above, nslookup, on your command line... Linux, MacOS or Windows, the command will work


So why don't we just enter IP addresses into our web browser's address bar all the time? 

The answer is simple. It's nigh on impossible to remember them all!

Quite simply, domain names are MUCH easier to remember than one IP address let alone lots of IP addresses. 

So let's get back to our domain name... let's call that domain name, domain.dom, and explore what goes on behind the scenes...

When we register a domain name, the TLD that it is on, makes an entry in their master zone file saying that there are now NS records (Name Server) for the domain name, and that those Name servers are authoritative for the hostname.

In essence it goes something like this.

You enter domain.dom in the address bar of your browser and when you hit Enter a chain of events occurs.

The browser checks its internal cache to see if it has any data for the domain name already. In this instance, we know it hasn't as it's a brand new domain name so the process jumps to the next step.

Your browser asks your Operating System - "Hey OS, do you know the IP address for domain.dom?"

Your OS checks is cache for any data on the domain name. Again, it will have none, as we know it's a brand new domain, so  the process jumps again...

Your OS then asks the router on your network, "Hey Router, do you have any IP address information for domain.dom?"

Your router has none, so it goes off to your ISP (or potentially global public DNS servers such as Google or OpenDNS) and asks the question again...

"Hey ISP DNS Server, do you know the IP address for domain.dom?" 

The ISP DNS Server doesn't have any information for domain.dom, but does know about the TLD, .dom. Hmmmm, the DNS server thinks, hold on a second, let me ask the TLD, .dom if it knows about domain.dom...

So off the ISP DNS Server goes and says to the master DNS Server for .dom and says, "Hey .dom Name Server do you know anything about domain.dom?"

And lo and behold...... The TLD Name Server responds with something we can work with...., "Hell yeh. I know that the Name Servers responsible for domain.dom are webhostingcompany.tld and webhostingcompany2.tld. I'd suggest going off and asking them for more info"

So with this new information The ISP Name Server goes over to webhostingcompany.tld DNS server and asks again..... "Hey Web Hosting Company DNS Server, do you know anything about domain.dom?"

And we get our response.... the data we've been waiting for.... "Yup I do know that domain.dom has an A name record for IP address"

And then this new information gets passed all the way back down through all the applications and services that had asked for it.

and the Web Browser goes to the IP Address and asks... "Hi there Web Server, do you have the website domain.dom at this IP address?" and hopefully it does and returns some content to be rendered.

However.... that is for another section, where we'll learn about Web Servers and one in particular. Apache.

For now, we've learned that DNS is a system for passing along information down a chain and sharing IP Addresses for it (A records) DNS is a globally distributed public and decentralized hierarchical  Database of all this information and without it working in the co-operative way it does, we'd never have a functioning Internet.

But.... because it's so distributed, there are many areas it may fall over and break and as such redundancy has been built in. This is why you must always have at last 2 NameServers recorded for a domain name, just in case one machine falls over and breaks!

A Records aren't the only information contained in the DNS System though.

Go off and do some research, find out about MX Records, TXT records, CNames and all the other kinds of DNS records that can exist and what they are used for. Don' forget different IP protocols either remembering to include IPv6 versions of the IPv4 A record.

I'd also suggest trying to understand what a zone file is. If you can understand it in detail, then that's amazing, but at the very least please be aware of the principles of a Zone file as they're inherently part of the DNS System

If you are brave and want to go the extra mile (or 26, as this could easily become a marathon) then learning about different DNS servers and especially BIND, will serve you well. However, this is way above and beyond what is required, but the thing about entering a rabbit warren is you never know what path you'll end up taking.... much like DNS itself :)

As ever, the Wikipedia Entry is a great place to start your research:

How does DNS Work?