Domain Name System (DNS) Introduction

Introduction

DNS is a very well known protocol. It is used for resolving host names and domain names to IP addresses.
The fact is that when you type www.firewall.cx it is translated into an IP address via special queries that
take place from your PC, but I'll explain how that works later on.

Because there is a fair bit of material to cover for the DNS protocol, and I don't want to confuse you with
too much information on one page, I have broken it down into 5 sections, each covering a specific part of
the protocol.

People who want specific information on the DNS protocol can go straight to the section they need, the
rest of us who just want to learn it all can start reading in the order presented:

Section 1: The DNS Protocol. How and why the DNS protocol was born. Page contains a bit of historical
information and also compares DNS with the OSI Reference model, where you will see the layers on which
DNS works. Internet DNS hierarchy is also analysed here, giving you the chance to understand how
domains on the Internet are structured.

Section 2: The DNS Resolution Process. What really happens when a host requests a DNS resolution. Full
analysis of the whole resolution process using a real life example. Understand Name Servers and the role
they play in the DNS system.

Section 3: The DNS Query Message Format. This section, along with the next one gives you the DNS
packet format in all its glory. Learn how DNS queries are generated and formatted. See, learn and
understand the various fields within the packets as your taken through a full detailed analysis of the
packet structure using the cool 3D diagrams.

Section 4: The DNS Response Message Format. This is the continuation of the section above, dealing with
the DNS response that's received. You will learn how the response packet is generated, formatted and
sent to the resolver. Again, you're taken through a full detailed analysis of the packet structure using
the cool 3D diagrams.

Section 5: The DNS Server (BIND). Based on BIND for Linux, this section is broken into a futher 6 pages:

 Section 5.1: Introduction to the DNS Server. Learn how a DNS server is setup on a Linux machine.
Over 85% of DNS servers on the Internet run on Linux and Unix based systems while Microsoft and
Novell DNS servers follow the same structure. DNS Zonesand Domains are also covered on this
page, this is essential for understanding how DNS Servers work.

 Section 5.2: The db.DOMAIN file. Complete analysis of the zone data file for a Primary DNS server.
See what is contains and understand how its structured.

 Section 5.3: The db.ADDR file. Complete analysis of the zone data file for a Primary DNS server.
See what is contains and understand how its structured.

 Section 5.4: Other common files. Analysing the rest of the files which are common to all DNS
servers.

 Section 5.5: Slave DNS Server. Instructions on setting up a secondary DNS server.

 Section 5.6: DNS Caching. The key to an efficient DNS server. This is a must for any DNS
Administrator. Learn how DNS caching helps improve performance and reduce traffic. Includes
1
 analysis of specific parameters within the DNS packet, which helps make DNS caching a reality,
and find out how to avoid problems that come with Domain redelegation or website transfers.

As you can see, there's plenty of stuff to cover. But don't despair because is all cool stuff ! Grab
something to drink and let's dive into the DNS waters ! You will be amazed at the stuff you'll find :)

The DNS Protocol

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 asDNS, 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
aDNS 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.

2
  

The DNS protocol normally uses

theUDP 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:

3
.......

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 DNSserver 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

4
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.cxdomain.

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

DNS Resolution Process

Introduction

This section will help you understand how the DNS queries work on the Internet and your
home network. There are two ways to use the domain name system in order to resolve a
host or domain name to an IP Address and we're going to look at them here. There is also a
detailed example later on this page to help you understand it better.

Queries and Resolution

As mentioned in the introduction section, there are two ways for a client to use the domain
name system to get an answer.

One of these involves the client contacting the name servers (this is also called a non
Recursive query) one at a time until it finds the authority server that contains the
information it requires, while the other way is to ask the name server system to perform the
complete translation (this is also called a Recursive query), in which case the client will send
the query and get a response that contains the IP Address of the domain it's looking for.

It's really exciting to see how DNS queries work. While analysing with you the packets that
are sent and received from the DNS server, I'm going to show you how the client chooses
the method by which it wants its query to be resolved, so you will truly understand how
these cool features work ! The DNS Query/Response Message Format pages contain all this
packet analysis information, so let's continue and prepare for it !

Our Example DNS Resolution

We will now look at what happens when your workstation requests a domain to be resolved.
The example that follows will show you the whole procedure step by step, so make sure you
take your time to read it and understand it !

When someone wants to visit the Cisco website (www.cisco.com), they go to their web
browser and type "http://www.cisco.com" or just "www.cisco.com" and, after a few seconds,
the website is displayed. But what happens in the background after they type the address
and hit enter is pretty much unknown to most users. That's what we are going to find out
now !

The picture below shows us what would happen in the above example: (for simplicity we are
not illustrating both Primary and Secondary DNS servers, only the Primary)

5
Explanation :

1. You open your web browser and enter www.cisco.com in the address field. At that point,
the computer doesn't know the IP address for www.cisco.com, so it sends a DNS query to
your ISP's DNS server (It's querying the ISP's DNS because this has been set through the
dial-up properties; if you're on a permanent connection then it's set through your network
card's TCP/IP properties).

2. Your ISP's DNS server doesn't know the IP for www.cisco.com, so it will ask one of

theROOT DNS servers.

3. The ROOT DNS server checks its database and finds that the Primary DNS for
Cisco.com is198.133.219.25. It replies to your ISP's server with that answer.

4. Your ISP's DNS server now knows where to contact Cisco's DNS server and find out
ifwww.cisco.com exists and its IP. Your ISP's DNS server sends a recursive query
toCisco.com's DNS server and asks for an IP address for www.cisco.com.

5. Cisco's DNS server checks its database and finds an entry for "www.cisco.com". This entry
has an IP address of 198.133.219.25. In other words, the webserver is running on the same
physical server as the DNS ! If it wasn't running on the same server, then it would have a
different IP. (Just a note, you can actually make it look like it's on the same physical server,
but actually run the web server on a different box. This is achieved by using some neat tricks
6
like port forwarding)

6. Your ISP's DNS server now knows the IP address for www.cisco.com and sends the result
to your computer.

7. Your computer now knows who it needs to contact to get to the website. So it sends an
http request directly to Cisco's webserver and downloads the webpage.

I hope you didn't find it too hard to follow. Remember that this query is the most common
type. The other type of query (non recursive) follows the same procedure, the difference is
that the client does all the running around trying to find the authoritative DNS server for the
desired domain, I like to think of it as "self service" :)

DNS Query Message Format

Introduction

This section will deal with the analysis of the DNS packets. This will allow us to see the way
DNS messages are formatted and the options and variables they contain. To understand a
protocol, you must understand the information the protocol carries from one host to another.

Because the DNS message format can vary, depending on the query and the answer, I've
broken this analysis into two parts. Part 1 analyses the DNS format of a query, in other
words, it shows how the packet looks when we ask a DNS server to resolve a domain. Part
2analyses the DNS format of an answer, where the DNS server is responding to our query.

I find this method more informative and easy to understand rather than combining the
analysis of queries and answers.

DNS Analysis - Host Query

As mentioned in the previous sections of the DNS Protocol, a DNS query is generated when
the client needs to resolve a domain name into an IP Address. This could be the result of
entering "www.firewall.cx" in the url field of your web browser, or simply by launching a
program that uses the Internet and therefore generates DNS queries in order to successfully
communicate with the host or server it needs.

Now, I've also included a live example (using my packet analyser), so you can compare
theory with practice for a better understanding. After this we will have a look at the meaning
of each field in the packet, so let's check out what a packet containing a DNS query would
look like on our network:

This is the captured packet we are going to deal with. To generate this packet, I typed
"pingwww.firewall.cx" from my linux prompt. The command generated this packet, which
was put on my network with the destination being a name server in Australia. Notice the Port

7
Destination which is set to 53, on which the port DNS works, and the protocol used for the
DNS Query, which is UDP.

Ethernet II (Check Ethernet Frames for more info.) is the most common type of frame found
on LANs, in fact it probably is the only type you will find on 85% of all networks if you're only
running TCP/IP and Windows or Unix-like machines. This particular one contains a DNS
section, which could be either a Query or Response. We are assuming a Query, so it can fit
nicely in our example.

We are going to take the DNS Section above and analyse its contents, which are already
shown in the picture above (Right hand side, labeled "Capture") taken from my packet
analyser.

Here they are again in a cool 3D diagram:

From this whole packet, the DNS Query Section is the part we're interested in (analysed
shortly), the rest is more or less overhead and information to let the server know a bit more
information about our query.

The analysis of each 3D block (field) is shown in the left picture below so you can understand
the function of each field and the DNS Query Section captured by my wonderful packet
sniffer on the right:

8
For example, a query for www.cisco.com will require DNS Name field to be smaller than a
query for support.novell.com simply because the second domain is longer.

The DNS Name Field

To prove this I captured a few packets that show different lengths for the domain names I
just mentioned but, because the DNS section in a packet provides no length field, we need to
look one level above, which is the UDP header, in order to calculate the DNS section length.
By subtracting the UDP header length (always 8 bytes - check UDP page for more
information) from the bytes in the Length field, we are left with the length of the DNS
section:

9
The two examples clearly show that the Length Field in the UDP header varies depending on
the domain we are trying to resolve. The UDP header is 8 bytes in both examples and all
fields in the DNS Section, except for the DNS Name field, are always 2 bytes.

The Flags/Parameters Field

The Parameter Field (labeled Flags) is one of the most important fields in DNS because it is

responsible for letting the server or client know a lot of important information about the DNS
packet. For example, it contains information as to whether the DNS packet is a query or
response and, in the case of a query, if it should be a recursive or non-recursive type. This is
most important because as we've already seen, it determines how the query is handled by
the server.

Let's have a closer look at the flags and explain the meaning of each one. I've marked the bit
numbers with black on the left hand side of each flag parameter so you can see which ones
are used during a response. The picture on the right hand side explains the various bits. You
won't see all 16 bits used in a query as the rest are used during a response or might be
reserved:

10
 

As you can see, only bits 1, 2-5, 7, 8 and 12 are used in this query. The rest will be a
combination of reserved bits and bits that are used only in responses. When you read the
DNS response message format page, you will find a similar packet captured which is a
reponse to the above query and the rest of the bits used are analysed.

And that just about does it for the DNS Query message format page. Next up is the DNS
Response message format page which I'm sure you will find just as interesting!

DNS Response Message Format

Introduction

The previous page delt with the DNS Query message formats. We analysed them in great
detail and showed how various options are selected by the host using the Flags/Parameters
field.

On this page we will see and analyse the responses we get from the generated queries.
These responses, in the case of a recursive query, come directly from the DNS server to
which we sent the query and, in the case of a non-recursive query, will come from the last
DNS server the client contacts in order to get the required information.

Lastly, keep in mind that this page is the continuation of the previous page, so it's important
to understand the previous material ! If you have any doubts, read the previous section
again.

Now that we have all that out of the way ....let's grab a few DNS responses and get our
hands dirty :)

DNS Analysis - Server Response

Here is the response (highlighted) to the previous DNS query sent to an Australian DNS
server (139.130.4.4), where I asked for the resolution of www.firewall.cx:

11
Something worth paying attention to is the time this query took to come back to my Linux
file server. The time taken, from the moment the packet was sent from the Linux file server,
until it received the answer, was only 0.991 seconds !

During this short period of time the packet travelled from Greece to Australia, reached the
DNS server, which sent its queries to other DNS servers until it found the answer and then
generated a DNS response that was sent back to Greece where my home network is !

There are a lot of factors that contribute to this fairly fast reponse. The transport protocol
UDP, which does not require any 3-way handshake, the load of the DNS server to which I
sent the query, the load of DNS servers it then had to ask, the speed at which all these
servers and myself are connected to the Internet and the general load between the routers
that my packet had to travel in order to get to its various destinations !

As you can clearly see, there is a lot happening for just one DNS query and response. Try to
consider what happenes when you have 20,000,000 DNS queries happening at once on the
Internet and you have a good idea on how well this protocol and the underlying technology
have been designed !

Following is the Ethernet II packet that runs on the local network. The structure is the same,
but varies in size, regardless of whether it's a DNS Query or Response:

Now, to make the analysis of the DNS Section easier I have also included the DNS
Query (left hand side) and DNS Response (right hand side). This allows you to compare what
we sent and what we received :

12
 ........

By comparing the two packets, you can see that there are fields in the DNS Response packet
(marked with green arrows) that didn't exist in the Query. Let's see again what each field
means and anaylse them again as we did in the previous page.

The DNS Section in a response packet is considerably larger and more complex than that of
a query. For this reason we are going to analyse it in parts rather than all together. The
query had only one section that required in-depth analysis whereas the response has three
since the first one is the original query sent.

Here is the DNS Section of a DNS response in 3D:

You can clearly see that everything after the light green 3D block labeled "DNS Query
Section" is new. We are going to focus on these 3 new blocks, which are part of the DNS
Response Section, as the rest has been covered in the previous page.

DNS Response Section

The analysis of this section won't be too difficult because the format that is followed in
each3D block of our DNS Response Section is identical. For this reason, I have not analysed
all 3 3D blocks, but only a few to help you get the idea.

The diagram below shows you the contents of the 3 3D blocks (sections) we are looking
at:Answers Section, Authoritative Name Servers Section and the Additional
Records Sections:

13
What we need to need understand is that each one of these three sections have identical
fields. Even though the information they contain might seem a bit different, the fields are
exactly the same and we will see this shortly.

In the picture above, I have only expanded the first part of the Answer section which is
underlined in green so you can compare the fields with the ones contained in the left hand
picture.

This next picture shows you the expanded version from the first part of
the Answers andAuthoritative sections. I have already marked and labeled the fields to prove
to you that they are all identical and vary only in the information they contain:
If you look carefully you will
notice that the Resource Data
field is presented first, where
according to the analysis of the
sections in the picture above (left
side), you would expect it last.

The truth is that it is last, but it's

presented first just because my
packet sniffer likes to make the
data more readable and less
confusing.

This is also the reason the first

line of each part in each section
is used to give you a quick
summary of the information
14
 

You also might wonder why there are 2 parts in each section ?

Could there be more or less parts, depending on the domain name or is there always 2 parts
in each section ?

The answer is simple and logical, there are as many parts as needed, depending always on
the domain setup. For example, if I had more than two name servers for the Firewall.cx
domain, you would see more than two parts in the Authoritative nameserver section and the
other sections.

Our example has only 2 parts per section whereas the one we see below has a lot more :

This DNS Response Section is based on a query generated for the IBM.COM domain:
As you can see, our query for
IBM.COM gave us a response
which has 4 parts per section !

Again, each part in every section

has identical fields, but different
data/values.

You might have noticed a pattern

here as well. In every DNS
Response you will find the same
number of parts per section.

For example, the picture on the

left shows us 4 parts for
the Answers,Authoritative and Addi
tional records sections and this is
no coincidence.

The reason this is no coincidence -

between the 3 sections
(Answers,Authoritative and Additio
nal records) is the Type field and I
will explain why.

15
 

The Type Field

The Type field determines the type or part of information we require about a domain. To give
you the simplest example, when we have a Type=A , we are given the IP Address of the
domain or host (look at Answers section above), whereas a Type=NS means we are given
theAuthoritative Name Servers that are responsible for the domain (look at Authoritative
Name Servers section above).

Looking at the picture below, which is from our first example (query for firewall.cx) we can
see exactly how the Type field is responsible for the data we receive about a domain:
As you can see, the Type field in
the first part of the Authoritative
Name Servers section is set
to NS,which means this part
contains information about the
Authoritative name servers of the
queried domain.

Going to the first part of

theAdditional records, we can see
that the Type field here is set to A,
which means the data contained in
this part is an IP Address for a
particular host.

So where is the logic to all this ?

Well, if I told you which servers

are authoritative for a domain
(Authoritative Name Server
Section), it would be useless if I
answered you without giving you
their IP Addresses (Additional
Records Section).

This is the reason in this example

we have been told about the Name
Servers for the firewall.cx domain
(Authoritative Name Server
Section), but also given their IP
Address (Additional Records
Section).

The same rule and logic explains why there are 2 parts for all three sections of this example.

Let's have a look at the different values the Type field can have, this will also give you an
insight into the information we can request and receive about any domain:

Type Meaning Contents

A Host Address 32-Bit IP Address of host or domain
16
 Canonical domain name for and alias e.g
CNAME Canonical Name (Alias)
www
HINFO CPU & OS Name of CPU and Operating System
MINFO Mailbox Info about a mailbox or mail list
16-bit preference and name of the host that
MX Mail Exchange acts as a mail exchange server for a domain
e.g mail.firewall.cx
NS Name Server Authoritative name server for the domain
Symbolic link for a domain. e.g
PTR Pointer
net.firewall.cx points to www.firewall.cx
Multiple fields that specify which parts of the
SOA Start Of Authority
naming hiererchy a server implements
TXT Arbitrary Text Uninterpreted string of ASCII text
The above values the Type field can take are contained within the DNS database, which is
covered next.

Our discussion on the DNS Response message format is now complete !

17