DNS in Action: A detailed and practical guide to DNS implementation, configuration, and administration

Recently, while driving to my work, I listened to radio as usual. Because of the establishment of
the new EU (European Union) domain, there was an interview with a representative of one of
the Internet Service Providers. For some time the interview went on, boringly similar to other
common radio interviews, but suddenly the presswoman started to improvise and she asked,
“But isn’t the DNS too vulnerable? Is it prepared for terrorist attacks?” The ISP representative
enthusiastically answered, “The whole Internet arose more than 30 years ago, initiated by the
American Department of Defense. From the very beginning, the Internet architecture took into
account that it should be able to keep the communication functional even if a part of the
infrastructure of the USA were destroyed, i.e., it must be able to do without a destroyed area.”

He went on enthusiastically, “We have 13 root name servers in total. Theoretically, only one is
enough to provide the complete DNS function.” At this point, we must stop for a moment our
radio interview to remind you that a role and principle of usage of root name servers are
described in the first chapter of this book. Now, let’s go back to our interview again. The
presswoman, not satisfied with the answer, asked, “All these root name servers are in the USA,
aren’t they? What will happen if someone or something cuts off the international connectivity, and
I am not be able to reach any root name server?” The specialist, caught by the presswoman’s
questions, replied, “This would be a catastrophe. In such a case, the whole Internet would be out
of order.”

That time I did not immediately came upon the solution that an area cut off this way is by nature
similar to an Intranet. In such a case, it would be enough to create national (or continental)
recovery plan and put into work a fake national (or continental) name server, exactly according
to the description in Chapter 9, describing closed company networks. The result would be that
the Internet would be limited only to our national (or continental) network; however, it would
be at least partially functional.

In fact at that time, the specialist’s answer made me angry. “So what?”, I thought, “Only DNS
would be out of order; i.e., names could not be translated to IP addresses. If we do not use
names but use IP addresses instead, we could still communicate. The whole network
infrastructure would be intact in that case!”

But working according to my way would be lengthy, and I thought about it over and over. After
some time I realized that the present Internet is not the same as it was in the early 1990s. At that
time the handful of academics involved with the Internet would have remembered those few IP
addresses. But in the present scenario, the number of IP addresses is in the millions, and the
number of people using the Internet is much higher still. Most of them are not IT experts and
know nothing about IP addresses and DNS. For such people, the Internet is either functional or
not—similar to, for example, an automatic washing machine. From this point of view, the
Internet without functional DNS would be really out of order (in fact it would still be functional,
but only IT experts would be able to use it).

The goal of this publiction is to illustrate to readers the principles on which the DNS is based.
This publication is generously filled with examples. Some are from a UNIX environment, some
from Microsoft. The concrete examples mostly illustrate some described problem. The
publication is not a text book of a DNS implementation for a concrete operating system, but it
always tries to find out the base of the problem. The reader is led to create similar examples
according to his or her concrete needs by him- or herself.

The goal of this book is to give the reader a deep understanding of DNS, independent of any
concrete DNS implementation. After studying this book, the reader should be able to study DNS
standards directly from the countless Requests for Comments (RFC). Links to particular RFCs are
listed in the text. In fact, it is quite demanding to study the unfriendly RFCs directly without any
preliminary training. For a beginner, only to find out the right RFC could be a problem.

Before studying this book, the reader should know the IP principles covered in the
Understanding TCP/IP book published by Packt Publishing (ISBN: 1-904811-71-X) because
this publication is a logical follow-on from that book.

The authors wish you good luck and hope that you get a lot of useful information by reading
this publication.

What This Book Covers

Chapter 1 begins to explain basic DNS principles. It introduces essential names, for example,
domain and zone, explaining the difference between them. It describes the iteration principle by
which the DNS translates names to IP addresses. It presents a configuration of a resolver both for
UNIX and for Windows. The end of the chapter explains name server principles and describes
various name server types.

Chapter 2 is fully focused on the most basic DNS procedure, the DNS query. Through this
procedure, the DNS translates names to IP addresses. In the very beginning, however, this chapter
describes in detail the Resource Record structure. At the end of this chapter, many practical
examples of DNS exchanges are listed.

Chapter 3 deals with other DNS procedures (DNS Extensions), i.e., DNS Update, DNS Notify,
incremental zone transfer, negative caching, IPv6 Extensions, IPsec, and TSIG.

Chapter 4 talks about the DNS implementation. It is derived from its historical evolution. From
the historical point of view, the oldest DNS implementation that is still sometimes used is BIND
version 4. This implementation is very simple so it is suitable to describe basic principles with it.
Next, the new generations of BIND are discussed followed by the Windows 2000 implementation.

Chapter 5 discusses the tools for debugging DNS such as nslookup, dnswalk, and dig, how to
control a name server using the rndc program, and the common errors that might occur while
configuring DNS.

Chapter 6 deals with the creation of DNS domains (domain delegation) and with the procedure of
domain registration.

Chapter 7 also talks about domain delegation. In contrast to Chapter 6, here the domain
registration relates not to forward domains but to reverse domains.

Chapter 8 deals with international organizations, called Internet Registries, which are responsible
for assigning IP addresses and domain registration.

Chapter 9 describes the DNS architecture of closed intranets.

Chapter 10 talks about the DNS architecture from the point of view of firewalls.

Domain Name System

All applications that provide communication between computers on the Internet use IP addresses
to identify communicating hosts. However, IP addresses are difficult for human users to
remember. That is why we use the name of a network interface instead of an IP address. For each
IP address, there is a name of a network interface (computer)—or to be exact, a domain name.
This domain name can be used in all commands where it is possible to use an IP address. (One
exception, where only an IP address can be used, is the specification of an actual name server.) A
single IP address can have several domain names affiliated with it.

The relationship between the name of a computer and an IP address is defined in the Domain Name
System (DNS) database. The DNS database is distributed worldwide. The DNS database contains
individual records that are called Resource Records (RR). Individual parts of the DNS database
called zones are placed on particular name servers. DNS is a worldwide distributed database.

If you want to use an Internet browser to browse to www.google.com with the IP address
64.233.167.147 (Figure 1.1), you enter the website name www.google.com in the browser address field.

Just before the connection with the www.google.com web server is made, the www.google.com
DNS name is translated into an IP address and only then is the connection actually established.

It is practical to use an IP address instead of a domain name whenever we suspect that the DNS on
the computer is not working correctly. Although it seems unusual, in this case, we can write
something like:

	ping 64.233.167.147

http://64.233.167.147

or send email to

	dostalek@[64.233.167.147]

However, the reaction can be unexpected, especially for the email, HTTP, and HTTPS protocols.
Mail servers do not necessarily support transport to servers listed in brackets. HTTP will return to
us the primary home page, and the HTTPS protocol will complain that the server name does not
match the server name in the server’s certificate.

Domains and Subdomains

The entire Internet is divided into domains, i.e., name groups that logically belong together. The
domains specify whether the names belong to a particular company, country, and so forth. It is
possible to create subgroups within a domain that are called subdomains. For example, it is
possible to create department subdomains for a company domain. The domain name reflects
a host’s membership in a group and subgroup. Each group has a name affiliated with it. The
domain name of a host is composed from the individual group names. For example, the host
named bob.company.com consists of a host named bob inside a subdomain called company, which
is a subdomain of the domain com.

The domain name consists of strings separated by dots. The name is processed from left to right.
The highest competent authority is the root domain expressed by a dot (.) on the very right (this
dot is often left out). Top Level Domains (TLD) are defined in the root domain. We have two
kind of TLD, Generic Top Level Domain (gTLD) and Country Code Top Level Domain
(ccTLD). Well known gTLDs are edu, com, net, and mil which are used mostly in the USA.
According to ISO 3166, we also have two letter ccTLD for individual countries. For example, the
us domain is affiliated with USA. However ccTLD are used mostly outside the USA. A detailed
list of affiliated ccTLD and their details are listed in Appendix A.

The TLD domains are divided into subdomains for particular organizations, for example, cocacola.
com, mcdonalds.com, google.com. Generally, a company subdomain can be divided into lower
levels of subdomains, for example, the company Company Ltd. can have its subdomain as
company.com and lower levels like bill.company.com for its billing department, sec.company.com
for its security department, and head.company.com for its headquarters.

The names create a tree structure as shown in the figure:

The following list contains some other registered gTLDs:

• The .org domain is intended to serve the noncommercial community.
• The .aero domain is reserved for members of the air transport industry.
• The .biz domain is reserved for businesses.
• The .coop domain is reserved for cooperative associations.
• The .int domain is only used for registering organizations established by
  international treaties between governments.
• The .museum domain is reserved for museums.
• The .name domain is reserved for individuals.
• The .pro domain is being established; it will be restricted to credited professionals
  and related entities.

Name Syntax

Names are listed in a dot notation (for example, abc.head.company.com). Names have the
following general syntax:

	string.string.string ………string.

where the first string is a computer name, followed by the name of the lowest inserted domain,
then the name of a higher domain, and so on. For unambiguousness, a dot expressing the root
domain is also listed at the end.

The entire name can have a maximum of 255 characters. An individual string can have
a maximum of 63 characters. The string can consist of letters, numbers, and hyphens. A hyphen
cannot be at the beginning or at the end of a string. There are also extensions specifying a richer
repertoire of characters that can be used to create names. However, we usually avoid these
additional characters because they are not supported by all applications.

Both lower and upper case letters can be used, but this is not so easy. From the point of view of
saving and processing in the DNS database, lower and upper case letters are not differentiated. In
other words, the name newyork.com will be saved in the same place in a DNS database as
NewYork.com or NEWYORK.com. Therefore, when translating a name to an IP address, it does not
matter whether the user enters upper or lower case letters. However, the name is saved in the
database in upper and lower case letters; so if NewYork.com was saved in the database, then during
a query, the database will return “NewYork.com.”. The final dot is part of the name.

In some cases, the part of the name on the right can be omitted. We can almost always leave out
the last part of the domain name in application programs. In databases describing domains the
situation is more complicated:

• It is almost always possible to omit the last dot.
• It is usually possible to omit the end of the name, which is identical to the name of
  the domain, on computers inside the domain. For example, inside the company.com
  domain it is possible to just write computer.abc instead of
  computer.abc.company.com. (However, you cannot write a dot at the end!) The
  domains that the computer belongs to are directly defined by the domain and search
  commands in the resolver configuration file. There can be several domains of this
  kind defined (see Section 1.9).

Reverse Domains

We have already said that communication between hosts is based on IP addresses, not domain
names. On the other hand, some applications need to find a name for an IP address—in other
words, find the reverse record. This process is the translation of an IP address into a domain name,
which is often called reverse translation.

As with domains, IP addresses also create a tree structure (see Figure 1.2). Domains created by IP
addresses are often called reverse domains. The pseudodomains inaddr-arpa for IPv4 and
IP6.arpa for IPv6 were created for the purpose of reverse translation. This domain name has
historical origins; it is an acronym for inverse addresses in the Arpanet.

Under the domain in-addr.arpa, there are domains with the same name as the first number from
the network IP address. For example, the in-addr.arpa domain has subdomains 0 to 255. Each of
these subdomains also contains lower subdomains 0 to 255. For example, network 195.47.37.0/24
belongs to subdomain 195.in-addr.arpa. This actual subdomain belongs to domain
47.195.in-addr.arpa, and so forth. Note that the domains here are created like network IP
addresses written backwards.

This whole mechanism works if the IP addresses of classes A, B, or C are affiliated. But what
should you do if you only have a subnetwork of class C affiliated? Can you even run your own
name server for reverse translation? The answer is yes. Even though the IP address only has four
bytes and a classic reverse domain has a maximum of three numbers (the fourth numbers are
already elements of the domain—IP addresses), the reverse domains for subnets of class C are
created with four numbers. For example, for subnetwork 194.149.150.16/28 we will use domain
16.150.149.194.in-addr.arpa. It is as if the IP address suddenly has five bytes! This was originally
a mistake in the implementation of DNS, but later this mistake proved to be very practical so it
was standardized as an RFC. We will discuss this in more detail in Chapter 7. You will learn more
about reverse domains for IPv6 in Section 3.5.3.

Domain 0.0.127.in-addr.arpa

The IP address 127.0.0.1 presents an interesting complication. Network 127 is reserved for
loopback, i.e., a software loop on each computer. While other IP addresses are unambiguous
within the Internet, the address 127.0.0.1 occurs on every computer. Each name server is not only
an authority for common domains, but also an authority (primary name server) to domain
0.0.127.in-addr.arpa. We will consider this as given and will not list it in the chart, but be
careful not to forget about it. For example, even a caching-only server is a primary server for this
domain. Windows 2000 pretends to be the only exception to this rule, but it would not hurt for
even Windows 2000 to establish a name server for zone 0.0.127.in-addr.arpa.

Zone

We often come across the questions: What is a zone? What is the relation between a domain and a
zone? Let us explain the relationship of these terms using the company.com domain.

As we have already said, a domain is a group of computers that share a common right side of their
domain name. For example, a domain is a group of computers whose names end with company.com.
However, the domain company.com is large. It is further divided into the subdomains bill.company.
com, sec.company.com, sales.company.com, xyz.company.com, etc. We can administer the entire
company.com domain on one name server, or we can create independent name servers for some
subdomains. (In Figure 1.3, we have created subordinate name servers for the subdomains
bill.company.com and head.company.com.) The original name server serves the domain
company.com and the subdomains sec.company.com, sales.company.com, and
xyz.company.com—in other words, the original name server administers the company.com zone.
The zone is a part of the domain namespace that is administered by a particular name server.

Special Zones

Besides classic zones, which contain data about parts of the domains or subdomains, special zones
are also used for DNS implementation. Specifically, the following zones are used:

• Zone stub: Zone stub is actually a subordinate zone that only contains information
  about what name servers administer in a particular subdomain (they contain the NS
  records for the zone). The zone stub therefore does not contain the entire zone.
• Zone cache/hint: A zone hint contains a list of root name servers (non-authoritative
  data read into memory during the start of the name server). Only BIND version 8 and
  later use the name hint for this type of zone. In previous versions, a name cache zone
  was used. Remember that the root name servers are an authority for a root domain
  marked as a dot (.).

Comments

comments