DNS stands for two things: Domain Name Service and Domain Name Servers. One acronym defines the protocol, the other defines the machines that provide the service. The job that DNS performs is very simple: it takes the IP addresses that computers connected to the Internet use to communicate with each other and it maps them to hostnames.
Sounds pretty simple, doesn’t it? Well, it is. But just because it’s simple doesn’t make it any less important.
Human beings tend to have a difficult time remembering long strings of seemingly arbitrary numbers. The way that our brains work, it’s difficult to make information like that stick. And that is where DNS comes in. It allows us to substitute words or phrases for those strings of numbers. Words are a lot easier for people to remember than numbers, especially when they can be tied to a specific idea that is linked to the website.
But how does DNS work? What makes it operate? How did it start?
Like almost everything else originally associated with the Internet, DNS traces its origins to ARPANET. Alphabetic hostnames were introduced shortly after its inception as a means of allowing users greater functionality, since the numeric addresses proved difficult to remember.
Originally, every site connected to ARPANET maintained a file called ‘HOSTS.TXT’ which contained the mapping information for all of the numeric addresses used there. That information was shared through ARPANET. Unfortunately, there were many problems that arose from that setup. Errors were commonplace and it was inefficient to make changes considering they needed to be made on each and every copy of the HOSTS.TXT file.
In December of 1973, a proposal was introduce in RFC 606 called ‘ Host Names On-line’ that went through several revisions until eventually, in 1974, RFC 625 came out, giving the Stanford Network Information Centre (NIC) the official license to be the centralized location to host all of the hostname information.
The centralised system worked well for almost a decade. However, in the early 1980′s, the amount of dynamic data that was passing through the network made it difficult for a single source to be able to efficiently maintain and host all of the information. The host file was becoming too large and unwieldy. Many sites were downloading the entire file on a nightly basis. This was putting too large a strain on the Stanford NIC’s resources. Something needed to change.
By November of 1983, a plan was laid out in RFCs 881, 882, and 883, also known as ‘The Domain Names Plan and Schedule,’ ‘ Domain Names — Concepts And Facilities,’ and ‘ Domain Names — Implementation And Specification.’ These three RFCs defined what has developed into DNS as we know it today. Surprisingly, not a whole lot has changed since that time.
In a nutshell, DNS translates IP addresses into hostnames and back again. The hostnames are for the benefit of human end users. The IP addresses are the only essential thing, as far as the computers are concerned. In a longer form, we need to begin by looking at the different types of DNS servers.
The first type of server is called a ‘Root Name Server.’ Each Top Level Domain (such as .com, .edu, .us, etc) has one or more Root Name Servers which are responsible for determining where the individual records are held. These servers are fairly static and every machine on the internet has the capability of reaching any of them, as needed.
The servers that the Root Name Servers direct queries to are called ‘Authoritative Name Servers’. These are the servers which hold the actual information on an individual domain. This information is stored in a file called a ‘Zone File.’ Zone files are the updated versions of the original HOSTS.TXT file.
The final type of name server is called a ‘Resolving Name Server’. These are the servers that do the majority of the work when you are trying to get to a machine with a certain host name. Besides being responsible for looking up data, they also temporarily store the data for hostnames that they have searched out in a cache, which allows them to speed up the resolution for hostnames that are frequently visited.
The manner in which these servers work together is fairly straightforward. When you attempt to go to a website, you type in a hostname in your web browser. Let’s say, for convenience, that you are going to www.secura.cloud. In your computers’ settings is a list of resolving name servers which it queries to find out whatwww.secura.cloud’s IP address is.
The first thing that the resolving name servers will do is check their caches to see if the DNS information for www.secura.cloud is already there. If it isn’t, they will go and check with the .com root name server to see which authoritative name server holds the zone file for secura.cloud. Once they have that server’s IP address, they connect to it.
Once the resolving name server has queried the authoritative name server, it replies back to your computer with one of a number of different things. Ideally, it will report back with the correct IP address and allow your computer to connect to the web server and show you the web page that you were looking for. However, if the authoritative server is down, doesn’t have a record for the specific hostname that you are looking up, or if the root server doesn’t have a record that the domain name even exists, the resolving name server will report an error to your computer.
Now that you have a basic idea of where DNS came from, why it’s used, and how it works, it’s time to take a look at some of its specifics. There are many details about DNS which confuse people and are never addressed by lists of frequently asked questions. However, most of these questions are very easy to answer.
One of the most common points of confusion is the difference between a domain name and a hostname. The short answer is that a domain name is something like foo.org and a hostname is something like www.secura.cloud. But that only helps illustrate the confusion. To really understand it, we need to start at the hostname level and work backwards.
DNS works on a hierarchical structure. Most hostnames have three sections, each separated by a period. What most people don’t realise, though, is how these sections work. The first section is actually what most people would commonly read as the last: the top level domain. Whether it is .org, .com, or anything else, the top level domain is the first part of a hostname which is read by a name server.
The second section is the domain. In combination with the top level domain, this is what forms the domain name. Everything from secura.cloud to google.com is a domain name. This is the level at which zone files are held by authoritative name servers.
A hostname, therefore, is everything else. Any DNS record held in a zone file is a hostname. Typically, these are things like www.secura.cloud and mail.secura.cloud. These are the most common of the domain name subheadings.
It is also possible to create something called a sub-domain. A sub-domain is a hostname which has its own zone file. This is created by adding another record in a domain’s zone file. This isn’t done very often, but when a single hostname would have a great deal of information tied directly to it, it can make it much easier to organise things.
As you can see, there is a great deal about DNS which most people never care to find out about. It is, quite possibly, the most simple of the technologies associated with the Internet, but also possibly the most misunderstood because of its simplicity. Without it, though, the Internet would never have become what it is today.
Marks is a director at Secura hosting and one of our resident Network specialists.
Tweet me at:
@securacloud
