The DNS Protocol - Part 1: Introduction

If you ever wondered where DNS came from, this is your chance to find out ! The quick summary on DNS's history will also help you understand why DNS servers are run mostly on Linux and Unix-type systems. We then get to see the layers of the OSI Model on which DNS works and, towards the end of the page, you will find out how the Domains (and DNS servers) are structured on the Internet to ensure uptime and effectiveness.

The History

DNS began in the early days when the Internet was only a small network created by the Department of Defence for research purposes. Host names (simple computer names) of computers were manually entered into a file (called HOSTS) which was located on a central server. Each site/computer that needed to resolve host names had to download this file. But as the number of hosts grew, so did the HOSTS file (Linux, Unix, Windows and NetWare still use such files) until it was far too large for computers to download and it was generating great amounts of traffic ! So they thought ... Stuff this .. let's find a better solution ... and in 1984 the Domain Name System was introduced.

The Protocol

The Domain Name System is a 'hierarchically distributed database', which is a fancy way of saying that its layers are arranged in a definite order and that its data is distributed across a wide range of machines (just like the roots of a tree branch out from the main root).

Most companies today have their own little DNS server to ensure the computers can find each other without problems. If you're using Windows 2000 and Active Directory, then you surely are using DNS for the name resolutions of your computers. Microsoft has created its own version of a "DNS" server, called a WINS server, which stands for Windows Internet Name Service, but this is old technology and uses protocols that are nowhere near as efficient as DNS, so it was natural for Microsoft to move away from WINS and towards DNS, after all, the whole Internet works on DNS :)

The DNS protocol works when your computer sends out a DNS query to a name server to resolve a domain. For example, you type "www.firewall.cx" in your web browser, this triggers a DNS request, which your computer sends to a DNS server in order to get the website's IP Address ! There is a detailed example on the pages to follow so I won't get into too much detail for the moment.

The DNS protocol normally uses the UDP protocol as a means of transport because of its small overhead in comparison to TCP; the less overhead a protocol has, the faster it is !

In the case where there are constant errors and the computer trying to request a DNS resolution can't get an error free answer, or any answer at all, it will switch to TCP to ensure the data arrives without errors.

This process, though, depends on the operating system you're using. Some operating systems might not allow DNS to use the TCP protocol, thus limiting it to UDP only. It is rare that you will get so many errors that you can't resolve any hostname or domain name to an IP Address.

The DNS protocol utilises Port 53 for its service. This means that a DNS server listens on Port 53 and expects any client wishing to use the service to use the same port. There are, however, cases where you might need to use a different port, something possible depending on the operating system and DNS server you are running.

In the following pages we'll be looking at the actual DNS packet format, where you are able to see exactly the contents of DNS query, so we won't analyse the packet structure here.

Next we'll take a close look at how the Internet domains and DNS servers are structured to make sure the model works flawlessly and efficiently!

The Internet Domain Name Server Hierarchy

This interesting section will help you understand how domain names on the Internet are structured and where DNS servers fit in to the picture. When you think about the millions of domain names registered today, you probably think that you have to be superhuman to manage such a structure of DNS servers !

Well that's not that case. The DNS structure has been designed in such a way that no DNS server needs to know about all possible domains, but only those immediately above and below it.

The picture below shows part of the internet DNS hierarchical structure:

Let's explain how it works:

Internic controls the "root" domain, which includes all the top level domains. These are marked in a green oval for clarity. Within the green oval you have the ROOT DNS servers, which know all about the authoritative DNS servers for the domains immediately below them e.g firewall.cx, cisco.com, microsoft.com etc. These ROOT DNS servers can tell you which DNS server takes care of firewall.cx, cisco.com, microsoft.com and the rest.

Each domain, including the ones we are talking about (cisco, firewall, microsoft), have what we call a "Primary DNS" and "Secondary DNS". The Primary DNS is the one that holds all the information about its domain. The Secondary acts as a backup in case the Primary DNS fails. The process in which a Primary DNS server sends its copy to the Secondary DNS server is called Zone Transfer and is covered in the DNS Database section.

Today there are hundreds of websites at which you are able to register your own domain and, once you've done that, you have the power to manage it yourself. In the example above, Cisco bought the "Cisco.com" domain and then created your resource records. Some examples of resource records for the Cisco domain in our example are: support , www and routers. These will be analysed in depth on the next pages.

So here comes the million dollar question: How do you create subdomains and www's (known as resouce records) ?

The answer is pretty simple:

You use a special DNS administration interface (usually web based - provided by the guys with whom you registered your domain) that allows you to create, change and delete the subdomains, www's or whatever resource record you can come up with. When you're making changes to the DNS settings of your domain, you're actually changing the contents of specific files that are located on that server.

These changes then slowly propagate to the authoritative DNS servers, which are responsible for your domain area and then the whole Internet will contact these DNS servers when they need to access any section of your domain.

For example, if you need to resolve ftp.firewall.cx, your computer will locate and contact the DNS Server responsible for the .CX domains, which will let you know the DNS server that's in charge of the Firewall.cx domain. The DNS server of Firewall.cx in turn will let your computer know the IP Address of ftp.firewall.cx because it holds all the information for the firewall.cx domain.

That completes our first DNS section. It's not that hard after all!

 Next - The DNS Protocol - Part 2: DNS Queries & Resolution Process