Chapter 1

Introduction

1.1 Introduction

The Domain Name System (DNS) is a hierarchical naming system for computers,
services, or any resource participating in the Internet. It associates various information
with domain names assigned to such participants. Most importantly, it translates domain
names meaningful to humans into the numerical (binary) identifiers associated with
networking equipment for the purpose of locating and addressing these devices world-
wide. An often used analogy to explain the Domain Name System is that it serves as the
"phone book" for the Internet by translating human-friendly computer hostnames into IP
addresses. For example, www.example.com translates to 208.77.188.166.

The Domain Name System makes it possible to assign domain names to groups of
Internet users in a meaningful way, independent of each user's physical location. Because
of this, World-Wide Web (WWW) hyperlinks and Internet contact information can
remain consistent and constant even if the current Internet routing arrangements change
or the participant uses a mobile device. Internet domain names are easier to remember
than IP addresses such as 208.77.188.166 (IPv4) or 2001:db8:1f70::999:de8:7648:6e8
(IPv6). People take advantage of this when they recite meaningful URLs and e-mail
addresses without having to know how the machine will actually locate them.

The Domain Name System distributes the responsibility of assigning domain names and
mapping those names to IP addresses by designating authoritative name servers for each
domain. Authoritative name servers are assigned to be responsible for their particular
domains, and in turn can assign other authoritative name servers for their sub-domains.
This mechanism has made the DNS distributed, fault tolerant, and helped avoid the need
for a single central register to be continually consulted and updated.

In general, the Domain Name System also stores other types of information, such as the
list of mail servers that accept email for a given Internet domain. By providing a world-
wide, distributed keyword-based redirection service, the Domain Name System is an
essential component of the functionality of the Internet.

The Domain Name System also defines the technical underpinnings of the functionality
of this database service. For this purpose it defines the DNS protocol, a detailed
specification of the data structures and communication exchanges used in DNS, as part of
the Internet Protocol Suite (TCP/IP). The DNS protocol was developed and defined in the
early 1980s and published by the Internet Engineering Task Force.

1
1.2 History

The practice of using a name as a more human-legible abstraction of a machine's

numerical address on the network predates even TCP/IP. This practice dates back to the
ARPANET era. Back then, a different system was used. The DNS was invented in 1983,
shortly after TCP/IP was deployed. With the older system, each computer on the network
retrieved a file called HOSTS.TXT from a computer at SRI (now SRI International). The
HOSTS.TXT file mapped numerical addresses to names. A hosts file still exists on most
modern operating systems, either by default or through configuration, and allows users to
specify an IP address (eg. 208.77.188.166) to use for a hostname (eg. www.example.net)
without checking DNS. Systems based on a hosts file have inherent limitations, because
of the obvious requirement that every time a given computer's address changed, every
computer that seeks to communicate with it would need an update to its hosts file.

The growth of networking required a more scalable system that recorded a change in a
host's address in one place only. Other hosts would learn about the change dynamically
through a notification system, thus completing a globally accessible network of all hosts'
names and their associated IP Addresses.
The enormous growth rate of the Internet was by no means predictable.
Therefore it took several years until serious problems became apparent:

1. System administrators used to email changes to the NIC and periodically contact the
SRI-NIC to obtain the latest copy of HOSTS.TXT. Network traffic and processor load
became unacceptably high for the NIC.

2. Names assigned to hosts have to be unique. As the NIC had no authority over host
name assignments, name collisions became a problem.

3. With the growth of the Internet and the irregularity of database updates the consistency
of the name space was no longer guaranteed.

All of these problems arose because the original approach scaled poorly. In 1984 the
network community switched to the Domain Name System. Paul Mockapetris was
responsible for the design of the architecture of the new system. The original RFCs6
describing the Domain Name System are [Moc83a] and [Moc83b]. They have been
obsolete since the release of the current specifications [Moc87a] and [Moc87b] in
November 1987.
At the request of Jon Postel, Paul Mockapetris invented the Domain Name
system in 1983 and wrote the first implementation. The original specifications appear in
RFC 882 and RFC 883. In November 1987, the publication of RFC 1034 and RFC 1035
updated the DNS specification and made RFC 882 and RFC 883 obsolete. Several more-
recent RFCs have proposed various extensions to the core DNS protocols.
In 1984, four Berkeley students—Douglas Terry, Mark Painter, David
Riggle and Songnian Zhou—wrote the first UNIX implementation, which was
maintained by Campbell thereafter. In 1985, Kevin Dunlap of DEC significantly re-wrote

2
the DNS implementation and renamed it BIND—Berkeley Internet Name Domain. Mike
Karels, Phil Almquist and Paul Vixie have maintained BIND since then. BIND was
ported to the Windows NT platform in the early 1990s.

BIND was widely distributed, especially on Unix systems, and is the dominant DNS
software in use on the Internet. With the heavy use and resulting scrutiny of its open-
source code, as well as increasingly more sophisticated attack methods, many security
flaws were discovered in BIND. This contributed to the development of a number of
alternative name server and resolver programs. BIND itself was re-written from scratch
in version 9, which has a security record comparable to other modern Internet software.

1.3 Fundamentals of DNS

The DNS not only supports host name to network address resolution, known as forward
resolution, but it also supports network address to host name resolution, known as inverse
resolution. Due to its ability to map human memorable system names into computer
network numerical addresses, its distributed nature, and its robustness, the DNS has
evolved into a critical component of the Internet. Without it, the only way to reach other
computers on the Internet is to use the numerical network address. Using IP addresses to
connect to remote computer systems is not a very user-friendly representation of a
system’s location on the Internet and thus the DNS is heavily relied upon to retrieve an IP
address by just referencing a computer system's Fully Qualified Domain Name (FQDN).
A FQDN is basically a DNS host name and it represents where to resolve this host name
within the DNS hierarchy.

1.4 Design Goals

The effort of designing the Domain Name System was directed towards several goals,
which had the main influence on determining the current structure. The aim was to create
a system with the following objectives in mind:
• Data Consistency
• Efficiency
• Distributed Character
• Generality
• Independence

3
 Chapter 2
Structure

2.1 The Domain Name Space

Domain names, arranged in a tree, cut into zones, each served by a name server. The
domain name space consists of a tree of domain names. Each node or leaf in the tree has
zero or more resource records, which hold information associated with the domain name.
The tree sub-divides into zones beginning at the root zone. A DNS zone consists of a
collection of connected nodes authoritatively served by an authoritative name server.
Administrative responsibility over any zone may be divided, thereby
creating additional zones. Authority is said to be delegated for a portion of the old space,
usually in form of sub-domains, to another name server and administrative entity. The old
zone ceases to be authoritative for the new zone.
The DNS is a hierarchical tree structure whose root node is known as the root
domain. A label in a DNS name directly corresponds with a node in the DNS tree
structure. A label is an alphanumeric string that uniquely identifies that node from its
brothers. Labels are connected together with a dot notation, ".", and a DNS name
containing multiple labels represents its path along the tree to the root. Labels are written
from left to right. This is commonly referred to as the root zone. Due to the root label
being zero length, all FQDNs end in a dot [RFC 1034]
As a tree is traversed in an ascending manner i.e. from the leaf nodes to the root, the
nodes become increasingly less specific (i.e., the leftmost label is most specific and the
right most label is least specific). Typically in an FQDN, the left most label is the host
name, while the next label to the right is the local domain to which the host belongs. The
local domain can be a sub domain of another domain. The name of the parent domain is
then the next label to the right of the sub domain (i.e., local domain) name label, and so
on, till the root of the tree is reached.

Figure 2.1. Domain Name Space example

4
2.2 Parts of a domain name

2.2.1 Top level Domains

In every DNS name, the first word on the right represents the domain at the highest level
in the DNS tree, called a top level domains. These top-level domains essentially function
as registrars for the domains at the second level. The original DNS name space called for
seven top level domains. The edu, gov, int and mil domains are reserved for use by
certified organizations but the com, org and net domains are called global domains, these
domains dedicated to specific purposes, as follows:

com Commercial organizations

edu Educational institutions
gov Government institutions
int International organizations
mil U.S. military institutions
net Networking organizations
org Non-profit organizations

Figure 2.2.1 Top level Domains

2.2.2 Country-Code Domains

There are 239 country code domains, named for specific countries using the ISO
designations, such as fr for France and us for United States. Many of these 239 countries
allow free registration of second-level domains to anyone, without restrictions. Each of
these country code domains is managed by an organization in that country, which
establishes its own domain name registration policies.

2.2.3 Reverse domains

A special domain (in-addr.arpa) used for IP address-to-name mapping.

2.3 Sub domains

Many of the domains on the internet stop at two levels, meaning that the
second level domain contains only host systems. However, it is possible for the

5
administrators of a second level domain to create subdomains that form additional levels.
There is no limit on the number of levels can create within domain, except for those
imposed by practically and the 255 character maximum DNS name length. The use of
sub domains can make it easier to identify hosts on a large network, but many
organizations also use them to delegate domain maintenance chores.
To make this delegation possible, DNS servers can break up a
domains’s name space into administrative units called zones. A zone can be any
contiguous branch of a DNS tree, and can include domains on multiple levels. Thus, zone
can be defined as any part of domain. Each zone must be represented by DNS servers that
are the authority for that zone. A single DNS server can be authoriatative for multiple zon

Figure 2.3 Sub domains

2.4 DNS servers

Name server

The Domain Name System is maintained by a distributed database system, which uses
the client-server model. The nodes of this database are the name servers. Each domain or
subdomain has one or more authoritative DNS servers that publish information about that
domain and the name servers of any domains subordinate to it. The top of the hierarchy is
served by the root name servers: the servers to query when looking up (resolving) a top-
level domain name (TLD). The whole database is divided into zones that are distributed
among the name servers. The essential task of a name server is to answer queries using
data in its zone. To ensure a higher degree of reliability of the system, the definition of
the Domain Name System requires that at least two name servers contain authoritative
data for a given zone.

6
The main name server is called the primary name server, and the backup servers are
called secondary name servers. Secondary authoritative name servers update the data
base for their zone periodically with data polled from their primary servers. Primary
name servers load the database files provided by the zone administrator and maintain a
cache of data that was acquired through resource records. Servers want to adapt
dynamically to changes in the setup of the name space of other authorities. Therefore,
each resource record contains a time to live field which ensures that name servers do not
cache data without time bound. The actual algorithm name servers use depends on the
local operating system and data structures used to store resource records.

2.5 DNS Resolvers

The client-side of the DNS is called a DNS resolver. It is responsible for initiating and
sequencing the queries that ultimately lead to a full resolution (translation) of the
resource sought, e.g., translation of a domain name into an IP address. In addition,
resolver can resend a query if no reply after a given timeout period, and can process error
messages returned by the server, such as when it fails to resolve a given name.

2.6 DNS Requests

A TCP/IP client usually is configured with the addresses of two DNS servers to which it
can send queries. A client can send query to any DNS server, it does not have to use the
authoritative server for the domain in which it belongs nor does the server have to be on
local server. Using the DNS server that is closest to the client is best, because it
minimizes the time needed for messages to travel between two systems. There are two
types of DNS queries: recursive and iterative.

Recursive query: A recursive query is one where the DNS server will fully answer the
query. When server receives a recursive query, it is responsible for trying to resolve the
requested name and for transmitting a reply back to the requestor. Even if the server does
nit possess the required information itself, it must send its own queries to other server
until it obtains the required information back to the requestor.

Iterative query: A non-recursive query is one in which the DNS server may provide a
partial answer to the query. When server receives a iterative query, it can either respond
with information from its own database or refer the requestor to another DNS server .The
recipient of the query responds with the best answer it currently possess, but not
responsible for searching for the information ,as with a recursive query.

Resolving usually entails iterating through several name servers to find the needed
information. However, some resolvers function simplistically and can communicate only
with a single name server. These simple resolvers rely on a recursive query to a recursive
server to perform the work of finding information for them.

7
2.7 Address resolution mechanism

Name-to-Address Resolution

Though it supports the complex, world-wide hierarchy of computers on the Internet, the basic
function of DNS is actually very simple: providing name-to-address resolution for TCP/IP-
based networks. Name-to-address resolution, also referred to as "mapping," is the process of
finding the IP address of a computer in a database by using its host name as an index.
Name-to-address mapping occurs when a program running on your local machine needs to
contact a remote computer. The program most likely will know the host name of the remote
computer but may not know how to locate it, particularly if the remote machine is in another
company, miles from your site. To get the remote machine's address, the program requests
assistance from the DNS software running on your local machine, which is considered a DNS
client. Your machine sends a request to a DNS name server, which maintains the distributed
DNS database. For querying purposes, software interprets the name segment by segment, from
right to left, using an iterative search procedure. At each step along the way, the program
queries a corresponding DNS server to provide a pointer to the next server which it should
consult.

A DNS recursor consults three name servers to resolve the address www.wikipedia.org.As
originally envisaged, the process was as simple as:

• the local system is pre-configured with the known addresses of the root servers in a file
of root hints, which need to be updated periodically by the local administrator from a
reliable source to be kept up to date with the changes which occur over time.
• query one of the root servers to find the server authoritative for the next level down
• querying this second server for the address of a DNS server with detailed knowledge
of the second-level domain
• repeating the previous step to progress down the name, until the final step which
would, rather than generating the address of the next DNS server, return the final
address sought.

Figure 2.7 : name to address resolution

8
The mechanism in this simple form has a difficulty: it places a huge operating burden on
the root servers, with every search for an address starting by querying one of them. Being
as critical as they are to the overall function of the system, such heavy use would create
an insurmountable bottleneck for trillions of queries placed every day. In practice caching
is used to overcome this problem, and in actual fact root name servers deal with very
little of the total traffic.

2.8 Circular dependencies and glue records

Name servers in delegations appear listed by name, rather than by IP address. This means
that a resolving name server must issue another DNS request to find out the IP address of
the server to which it has been referred. Since this can introduce a circular dependency if
the nameserver referred to is under the domain that it is authoritative of, it is occasionally
necessary for the nameserver providing the delegation to also provide the IP address of
the next nameserver. This record is called a glue record

2.9 Resource Records and Zones

To resolve names, servers consult their zones (also called DNS database files or simply
db files). The zones contain resource records (RRs) that make up the resource
information associated with the DNS domain. For example, some resource records map
friendly names to IP addresses, and others map IP addresses to friendly names.
Certain resource records not only include information about servers in the DNS domain,
but also serve to define the domain by specifying which servers are authoritative for
which zones. There are several types of resource records used by DNS servers, the most
important of which are as follows:
Start of Authority (SOA) records
There are often multiple DNS servers that service a domain. Multiple DNS servers might
be used for load balancing, fault tolerance, or both. But, only one DNS server within a
domain is considered authoritative. A Start of Authority (SOA) record points to the
domain's authoritative DNS server. It also contains a sort of sequence number that is
updated every time a change is made to the records contained within the zone. This helps
non-authoritative DNS servers stay in sync with the authoritative DNS server.

Name Server (NS) records

A Name Server (NS) record identifies a DNS server functioning as an authority for the
zone. Each DNS server in the zone must be represented by a NS record.

Address(A)

Provides a name to address mapping that supplies an IP address for a specific DNS name.
This record type performs the primary function of the DNS, converting names to address.

9
Mail Exchanger (MX) records

An e-mail message finds its way to its destination via an MX record. It identifies a
system that will direct e-mail traffic sent to an address in the domain to the individual
recipient ,a mail gateway, or another mail server.

Canonical Name (CNAME)

Creates an alias that points to the canonical name of a host identified by a A record.
CNAME records are used to provide alternatives names by which systems can be
identified.

PTR

Provides an address to name mapping that supplies a DNS name for a specific address in
the in-addr.arpa domain. This is functional opposite of an A record.

2.10 Reverse name resolution

When the DNS is used to map an IP address back into a host name i.e. inverse resolution,
the DNS makes use of the same notion of labels from left to right i.e. most specific to
least specific when writing the IP address. This is in contrast to the typical representation
of an IP address whose dotted decimal notation from left to right is least specific to most
specific. To handle this, IP addresses in the DNS are typically represented in reverse
order. IP addresses fall under a special DNS top level domain (TLD), known as the in-
addr.arpa domain. By doing this, using IP addresses to find DNS host names are handled
just like DNS host name lookups to find IP addresses.

Figure 2.10 Reverse name resolution

10
 Chapter 3
Caching

3.1 Role of Caches

The whole resolution process may seem convoluted and cumbersome compared to
simple seeks through a host table database. However, it is fast, speeded up considerably
by caching.
Name servers may need several DNS messages to find the answer to
a query. During successive resolution attempts name servers discover information about
the Domain Name Space. This information can be used for future resolutions. If a name
server caches the data, it builds up a data base that helps speed up the processing of
further querying. The next time a resolver queries the name server for data about a
domain name the name server knows something about, the process is shortened
considerably. Even if a name server does not have the answer to the query in its cache it
might have learned the identities of the authoritative name servers for the zone the
domain name is in, and it might be able to resolve them directly.
It is difficult to determine the optimal time to live value for data that is to be cached.
There is a trade-of between enhanced performance once data is cached and the possibility
that the cached data might be out of date by the time it is used.

3.2 Caching and time to live

Because of the huge volume of requests generated by a system like DNS, the designers
wished to provide a mechanism to reduce the load on individual DNS servers. To this
end, the DNS resolution process allows for caching (i.e. the local recording and
subsequent consultation of the results of a DNS query) for a given period of time after a
successful answer. How long a resolver caches a DNS response (i.e. how long a DNS
response remains valid) is determined by a value called the time to live (TTL). The TTL
is set by the administrator of the DNS server handing out the response. The period of
validity may vary from just seconds to days or even weeks.

3.3 Caching time

As a noteworthy consequence of this distributed and caching architecture, changes to

DNS do not always take effect immediately and globally. This is best explained with an
example: If an administrator has set a TTL of 6 hours for the host www.wikipedia.org,
and then changes the IP address to which www.wikipedia.org resolves at 12:01pm, the
administrator must consider that a person who cached a response with the old IP address
at 12:00noon will not consult the DNS server again until 6:00pm. The period between
12:01pm and 6:00pm in this example is called caching time, which is best defined as a
11
period of time that begins when you make a change to a DNS record and ends after the
maximum amount of time specified by the TTL expires.
The term "propagation", although very widely used in this context, does not describe the
effects of caching well. Specifically, it implies that when you make a DNS change, it
somehow spreads to all other DNS servers and that you do not have control over the
amount of time the record is cache.
Many people incorrectly refer to a mysterious 48 hour or 72 hour propagation time when
you make a DNS change. When one changes the NS records for one's domain or the IP
addresses for hostnames of authoritative DNS servers using one's domain (if any), there
can be a lengthy period of time before all DNS servers use the new information. This is
because those records are handled by the zone parent DNS servers (for example, the .com
DNS servers if your domain is example.com), which typically cache those records for 48
hours. However, those DNS changes will be immediately available for any DNS servers
that do not have them cached. And any DNS changes on your domain other than the NS
records and authoritative DNS server names can be nearly instantaneous.

3.4 In the real world

DNS resolving from program to OS-resolver to ISP-resolver to greater system. Users

generally do not communicate directly with a DNS resolver. Instead DNS-resolution
takes place transparently in client-applications such as web-browsers, mail-clients, and
other Internet applications. When an application makes a request which requires a DNS
lookup, such programs send a resolution request to the local DNS resolver in the local
operating system, which in turn handles the communications required.

The DNS resolver will almost invariably have a cache (see above) containing recent
lookups. If the cache can provide the answer to the request, the resolver will return the
value in the cache to the program that made the request. If the cache does not contain the
answer, the resolver will send the request to one or more designated DNS servers. In the
case of most home users, the Internet service provider to which the machine connects will
usually supply this DNS server: such a user will either have configured that server's
address manually or allowed DHCP to set it; however, where systems administrators
have configured systems to use their own DNS servers, their DNS resolvers point to
separately maintained nameservers of the organization. In any event, the name server thus
queried will follow the process outlined above, until it either successfully finds a result or
does not. It then returns its results to the DNS resolver; assuming it has found a result, the
resolver duly caches that result for future use, and hands the result back to the software
which initiated the request.

3.4.1 Broken resolvers

An additional level of complexity emerges when resolvers violate the rules of the DNS
protocol. A number of large ISPs have configured their DNS servers to violate rules such
as by disobeying TTLs, or by indicating that a domain name does not exist just because
one of its name servers does not respond.

12
As a final level of complexity, some applications such as web-browsers also have their
own DNS cache, in order to reduce the use of the DNS resolver library itself. This
practice can add extra difficulty when debugging DNS issues, as it obscures the freshness
of data, and/or what data comes from which cache. These caches typically use very short
caching times — on the order of one minute. Internet Explorer offers a notable exception:
recent versions cache DNS records for half an hour.

13
 Chapter 4
DNS resource records

4.1 DNS Resource record

A Resource Record (RR) is the basic data element in the domain name system. Each
record has a type (A, MX, etc.), a TTL, a class and some type-specific information. All
resource records of the same type define a Resource Record Set (RR set). The order that
resource records in a RR set are returned by the resolver to an application is undefined
DNSSEC, however, works on complete RR sets in a canonical order.
When sent over the Internet, all records use the common format specified in
RFC 1035 shown below:

RR (Resource record) fields

Length
Field Description
(octets)

Name of the node to which this record

NAME (variable)
pertains.

TYPE Type of RR. For example, MX is type 15. 2

CLASS Class code. 2

Signed time in seconds that RR stays

TTL 4
valid.

RDLENGTH Length of RDATA field. 2

RDATA Additional RR-specific data. (variable)

Table DNS resource record

The NAME is the fully qualified domain name of the node in the tree. On the wire, the
name may be shortened using label compression where ends of domain names mentioned
earlier in the packet can be substituted for the end of the current domain name.

14
The TYPE of the record indicates what the format of the data is, and gives a hint of its
intended use; for instance, the A record is used to translate from a domain name to an
IPv4 address, the NS record lists which name servers can answer lookups on a DNS zone,
and the MX record is used to translate from a name in the right-hand side of an e-mail
address to the name of a machine able to handle mail for that address.

The RDATA is type-specific information, such as the actual IP address for A records, or
the mail host for MX records.. The RDATA field is the resource data field and is
uniquely.

RD Length is the RDATA field’s length.

The CLASS of a record is almost always set to "IN" or "Internet". It contains a code that
specifies the class of the RR. In theory, each class can be completely independent trees
with different delegation DNS zones and different names, but in practice they all
mirrored the Internet class.

TTL The TTL is the time, in seconds, that a name server can cache a RR. A zero time to
live means that a server is not to cache the RR.It specifies the amount of time that the RR
should be cached in the server to which it is being supplied.

RRs are grouped into resources records sets (RRSets). RRSets contain 0 or more RRs
[RFC 2136] that have the same DNS name, class, and type, but the data i.e. RDATA is
different. If the name, class, type, and data are the same for two or more records then
duplicate records exist for the same DNS name. Name servers should suppress duplicate
records [RFC 2181]. The Figure 3 shows an example of a RRSet.

example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com.
example.com. IN NS ns.plain.org.

Table: These three records are grouped into a RRSet

Internationalized domain names

While domain names technically have no restrictions on the characters they use and can
include non-ASCII characters, the same is not true for host names. Host names are the
names most people see and use for things like e-mail and web browsing. Host names are
restricted to a small subset of the ASCII character set known as LDH, the Letters A–Z in
upper and lower case, Digits 0–9, Hyphen, and the dot to separate LDH-label. This
prevented the representation of names and words of many languages natively. ICANN
has approved the Punycode-based IDNA system, which maps Unicode strings into the
valid DNS character set, as a workaround to this issue. Some registries have adopted
IDNA.

15
 Chapter 5
Threats to Domain Name and Security issues

5.1 Threats to the Domain Name

The original DNS specifications did not include security based on the fact that the
information that it contains, namely host names and IP addresses, is used as a means of
communicating data . As more and more IP based applications developed, the trend for
using IP addresses and host names as a basis for allowing or disallowing access i.e.
system based authentication grew. Unix saw the advent of Berkeley "r" commands and
their dependencies on host names for authentication. Then many other protocols evolved
with similar dependencies, such as Network File System (NFS), X windows, Hypertext
Transfer Protocol (HTTP)

Another contributing factor to the vulnerabilities in the DNS is that the DNS is designed
to be a public database in which the concept of restricting access to information within
the DNS name space is purposely not part of the protocol. Later versions of the BIND
implementation allow access controls for such things as zone transfers, but the concept of
restricting who can query the DNS for RRs is considered outside the scope of the
protocol. Because DNS is a UDP-based network service, it has several major inherent
security vulnerabilities. Most are instances of more general problems, but a few are
inherent to peculiarities of the DNS protocol itself. Unlike TCP, UDP does not have a
mechanism for verifying a packet source, which makes it very vulnerable to source-
packet spoofing and inception attacks. There are four major

The existence and widespread use of such protocols as the r-commands put demands on
the accuracy of information contained in the DNS. False information within the DNS can
lead to unexpected and potentially dangerous exposures. The majority of the weaknesses
within the DNS fall into one of the following categories: Cache poisoning, client
flooding, dynamic update vulnerability, information leakage, and compromise of the
DNS server’s authoritative database.

5.2 Security issues

DNS was not originally designed with security in mind, and thus has a number of security
issues.

One class of vulnerabilities is DNS cache poisoning, which tricks a DNS server into
believing it has received authentic information when, in reality, it has not.

DNS responses are traditionally not cryptographically signed, leading to many attack
possibilities; The Domain Name System Security Extensions (DNSSEC) modifies DNS
to add support for cryptographically signed responses. There are various extensions to
support securing zone transfer information as well.

16
Even with encryption, a DNS server could become compromised by a virus that would
cause IP addresses of that server to be redirected to a malicious address with a long TTL.
This could have far-reaching impact to potentially millions of Internet users if busy DNS
servers cache the bad IP data. This would require manual purging of all affected DNS
caches as required by the long TTL (up to 68 years).

Some domain names can spoof other, similar-looking domain names. For example,
"paypal.com" and "paypa1.com" are different names, yet users may be unable to tell the
difference when the user's typeface (font) does not clearly differentiate the letter l and
the numeral 1. This problem is much more serious in systems that support
internationalized domain names, since many characters that are different, from the point
of view of ISO 10646, appear identical on typical computer screens. This vulnerability
is often exploited in phishing.

Techniques such as Forward Confirmed reverse DNS can also be used to help validate
DNS results.

5.3. DNSSEC

In 1994, the IETF formed a working group to provide security extensions to the DNS
protocol in response to the security issues surrounding the DNS. These extensions are
commonly referred to as DNSSEC extensions. These security enhancements to the
protocol are designed to be interoperable with non-security aware implementations of
DNS. The IETF achieved this by using the RR construct in the DNS that was purposely
designed to be extensible. The WG defined a new set of RRs to hold the security
information that provides strong security to DNS zones wishing to implement DNSSEC.
These new RR types are used in conjunction with existing types of RRs. This allows
answers to queries for DNS security information belonging to a zone that is protected by
DNSSEC to be supported through non-security aware DNS servers.

In order to gain widespread acceptance, the IETF DNSSEC WG acknowledged that

DNSSEC must provide backwards compatibly and must have the ability to co-exist with
non-secure DNS implementations. This allows for sites to migrate to DNSSEC when
ready and allows less complexity when upgrading. This also means that client side
software that are not DNSSEC aware can still correctly process RRSets received from a
DNSSEC server.

A fundamental principle of the DNS is that it is a public service. It requires correct and
consistent responses to queries, but the data is considered public data. As such, the need
for authentication and integrity exists, but not for access control and confidentiality.
Thus, the objectives of DNSSEC are to provide authentication and integrity to the DNS.
Authentication and integrity of information held within DNS zones is provided through
the use of cryptographic signatures generated through the use of public key technology.
Security aware servers, resolvers, and applications can then take advantage of this
technology to assure that the information obtained from a security aware DNS server is
authentic and has not been altered.

17
Although the DNSSEC WG chose not to provide confidentiality to DNS transactions,
they did not eliminate the ability to provide support for confidentiality. Other applications
outside of the DNS may choose to use the public keys contained within the DNS to
provide confidentiality. Thus the DNS, in essence, can become a worldwide public key
distribution mechanism. Issues such as cryptographic export are not, and may never be
solved worldwide, however, the DNS provides mechanisms to have multiple keys, each
from a different cryptographic algorithm for a given DNS name, as a means to help
alleviate this problem.

18
 Chapter 6
Domain registration

6.1 Domain registration

The right to use a domain name is delegated by domain name registrars which are
accredited by the Internet Corporation for Assigned Names and Numbers (ICANN), the
organization charged with overseeing the name and number systems of the Internet. In
addition to ICANN, each top-level domain (TLD) is maintained and serviced technically
by a sponsoring organization, the TLD Registry. The registry is responsible for
maintaining the database of names registered within the TLDs they administer. The
registry receives registration information from each domain name registrar authorized to
assign names in the corresponding TLD and publishes the information using a special
service, the who is protocol.

Registrars usually charge an annual fee for the service of delegating a domain name to a
user and providing a default set of name servers. Often this transaction is termed a sale or
lease of the domain name and the registrant is called an "owner", but no such legal
relationship is actually associated with the transaction, only the exclusive right to use the
domain name. More correctly authorized users are known as "registrants" or as "domain
holders".

ICANN publishes a complete list of TLD registries and domain name registrars in the
world. One can obtain information about the registrant of a domain name by looking in
the WHOIS database held by many domain registries.

For most of the more than 240 country code top-level domains (cc TLDs), the domain
registries hold the authoritative WHOIS (Registrant, name servers, expiration dates, etc.).
For instance, DENIC, Germany NIC, holds the authoritative WHOIS to a .DE domain
name. Since about 2001, most gTLD registries (.ORG, .BIZ, .INFO) have adopted this
so-called "thick" registry approach, i.e. keeping the authoritative WHOIS in the central
registries instead of the registrars.
For .COM and .NET domain names, a "thin" registry is used: the domain registry
(e.g. VeriSign) holds a basic WHOIS (registrar and name servers, etc.). One can find the
detailed WHOIS (registrant, name servers, expiry dates, etc.) at the registrars.

Some domain name registries are also called Network Information Centres (NIC), also
function as registrars, and deal directly with end users. But most of the main ones, such
as for .COM, NET, ORG, INFO, etc, use a registry-registrar model. There are hundreds
of Domain Name Registrars that actually perform the domain name registration with the

19
end user. By using this method of distribution, the registry only has to manage the
relationship with the registrar, and the registrar maintains the relationship with the end
users, or 'registrants' -- in some cases through additional layers of resellers.
In the process of registering a domain name and maintaining authority over
the new name space created, registrars store and use several key pieces of information
connected with a domain:

Administrative contact: A registrant usually designates an administrative contact to

manage the domain name. The administrative contact usually has the highest level of
control over a domain. Management functions delegated to the administrative contacts
may include management of all business information, such as name of record, postal
address, and contact information of the official registrant of the domain and the
obligation to conform to the requirements of the domain registry in order to retain the
right to use a domain name. Furthermore the administrative contact installs additional
contact information for technical and billing functions.

Technical contact: The technical contact manages the name servers of a domain name.
The functions of a technical contact include assuring conformance of the configurations
of the domain name with the requirements of the domain registry, maintaining the
domain zone records, and providing continuous functionality of the name servers that
leads to the accessibility of the domain name.

Billing contact: The party responsible for receiving billing invoices from the domain
name registrar and paying applicable fees.

Name servers: Domains usually need at least two authoritative name servers that
perform name resolution for the domain. If they are not automatically provided by the
registrar, the domain holder must specify domain names and IP addresses for these
servers.

6.2 Dynamic Update

Dynamic update is a new standard, specified in RFC 2136, that provides a means of
dynamically updating zone data on a zone's primary server.
Originally, DNS was designed to support only static changes to a zone database. Because
of the design limitations of static DNS, the ability to add, remove, or modify resource
records could only be performed manually by a DNS system administrator.
For example, a DNS system administrator would edit records on a zone's primary server
and the revised zone database is then propagated to secondary servers during zone
transfer. This design is workable when the number of changes is small and updates occur
infrequently, but can otherwise become unmanageable.
With dynamic update, on the other hand, the primary server for the zone can also be
configured to support updates that are initiated by another computer or device that
supports dynamic update. For example, it can receive updates from workstations

20
registering A and PTR resource records, or from DHCP servers. Updates are sent using a
standard UPDATE message format and can include the addition or deletion of individual
resource records (RRs) or sets of resource records (RR sets). In order for a request for a
dynamic update to be performed, several prerequisite conditions can also be identified.
Where prerequisites are set, all such conditions must be met before an update is allowed.
Some examples of prerequisites that can be set are:
• A required RR or RR set already exists or is in use prior to an update.
• A required RR or RR set does not exist or is not in use prior to an update.
• A requester is permitted to initiate an update of a specified RR or RRset.
Each prerequisite must be satisfied in order for an update to occur. After all prerequisites
are met, the zone's primary server can then proceed with an update of its local zones.
Multiple updates can be processed concurrently only if one update does not depend on
the final result of another update.
6.3 Internet standards

The Domain name system is defined by Request for Comments published by the Internet
Engineering Task Force (Internet standards). The following is a list of some of the RFCs
that pertain to the core DNS protocol.
Table 6.3 DNS-related RFC Standards Supported by Windows 2000

Number Status Title

1034 Standard Domain Names - Concepts and Facilities
1035 Standard Domain Names - Implementation and Specification
1123 Standard Requirements for Internet Hosts - Application and Support
1886 Proposed DNS Extensions to Support IP Version 6
1995 Proposed Incremental Zone Transfer in DNS
1996 Proposed A Mechanism for Prompt DNS Notification of Zone
Changes
2136 Proposed Dynamic Updates in the Domain Name System (DNS
UPDATE)
2181 Standards Track Clarifications to the DNS Specification
2308 Standards Track Negative Caching of DNS Queries (DNS NCACHE)

Chapter 7
Applications

21
7.1 Other applications

The Domain Name System includes several other functions:

• Hostnames and IP addresses do not necessarily match on a one-to-one basis. Many

hostnames may correspond to a single IP address: combined with virtual hosting, this
allows a single machine to serve many web sites. Alternatively a single hostname
may correspond to many IP addresses: this can facilitate fault tolerance and load
distribution, and also allows a site to move physical location seamlessly.
• There are many uses of DNS besides translating names to IP addresses. For instance,
Mail transfer agents use DNS to find out where to deliver e-mail for a particular
address. The domain to mail exchanger mapping provided by MX records
accommodates another layer of fault tolerance and load distribution on top of the
name to IP address mapping.

• E-mail Blacklists: The DNS system is used for efficient storage and distribution of
IP addresses of blacklisted e-mail hosts. The usual method is putting the IP address of
the subject host into the sub-domain of a higher level domain name, and resolve that
name to different records to indicate a positive or a negative. An hypothetical
example using blacklist.com
 102.3.4.5 is blacklisted => Creates 5.4.3.102.blacklist.com and resolves to
127.0.0.1
 102.3.4.6 is not => 6.4.3.102.blacklist.com is not found, or default to
127.0.0.2
 E-mail servers can then query blacklist.com through the DNS mechanism to
find out if a specific host connecting to them are in the blacklist. Today many
of such blacklists, either free or subscription-based, are available mainly for
use by email administrators and anti-spam software.

• Software Updates: Many anti-virus and commercial software now use the DNS
system to store version numbers of the latest software updates so client computers do
not need to connect to the update servers every time. For these type of applications,
the cache time of the DNS records are usually shorter.
• Sender Policy Framework and Domain Keys, instead of creating their own record
types, were designed to take advantage of another DNS record type, the TXT record.
• To provide resilience in the event of computer failure, multiple DNS servers are
usually provided for coverage of each domain, and at the top level, thirteen very
powerful root servers exist, with additional "copies" of several of them distributed
worldwide via anycast.

7.2 Protocol details

DNS primarily uses UDP on port 53 to serve requests. Almost all DNS queries consist of
a single UDP request from the client followed by a single UDP reply from the server.

22
TCP comes into play only when the response data size exceeds 512 bytes, or for such
tasks as zone transfer. Some operating systems such as HP-UX are known to have
resolver implementations that use TCP for all queries, even when UDP would suffice.

7.3 Extensions to DNS

EDNS is an extension of the DNS protocol which allows the transport over UDP of DNS
replies exceeding 512 bytes, and adds support for expanding the space of request and
response codes. It is described in RFC 267.

Chapter 8

IPv6 and the Domain Name System

23
8.1 NS changes to support IP Version 6

Version 4 of the Internet Protocol (IPv4) is the basis of today's Internet, and the
foundation upon which the TCP/IP protocol suite is built. While IPv4 has served well for
over two decades, it has certain important drawbacks that would limit internetworks of
the future if it were to continue to be used. For this reason, the next generation of IP, the
Internet Protocol version 6 (IPv6), has been in development for many years. IPv6 will
eventually replace IPv4 and take TCP/IP into the future.

The change from IPv4 to IPv6 will have effects that “ripple” to other TCP/IP protocols,
including the Domain Name System. DNS is a higher-level protocol, that based on the
principle of layering, a change to IP should not affect it. However, this is another
example of how strict layering doesn't always apply. DNS works directly with IP
addresses, and one of the most significant modifications that IPv6 makes to IP is in the
area of addressing, so this means that using DNS on IPv6 requires some changes to how
the protocol works.

IPv6 and the Domain Name System

IPv6 addresses are represented in the Domain Name System by AAAA resource records
so-called quad-A records for forward lookups. Reverse lookup takes place under ip6.arpa
previously ip6.int, where name space is allocated by the ascii representation of nibble
units (digits) of the hexadecimal IP address. This scheme, which is an adaptation of the
IPv4 method under in-addr.arpa, is defined in RFC 3596.

AAAA record fields

NAME Domain name

24
TYPE AAAA (28)

CLASS Internet (1)

TTL Time to live in seconds

RDLENGTH Length of RDATA field

RDATA String form of the IPV6 address as described in RFC 3513

Table 8.1 AAAA Records

RFC 3484 specifies how applications should select an IPv6 or IPv4 address for use,
including addresses retrieved from DNS.

The DNS protocol is independent from its transport layer. Queries and replies may be
transmitted over IPv6 or IPv4 transports regardless of the address family of the data
requested.

At the design-stage of the IPv6 DNS architecture, the AAAA scheme faced a rival
proposal. This alternate approach, designed to facilitate network renumbering, uses A6
records for the forward lookup and a number of other innovations such as bit-string labels
and DNAME records. It is defined in RFC 2874 and its references but has been
deprecated to experimental status.

8.2 IPv6 DNS Extensions

Since DNS is so architecturally distant from IP down there at layer three, the changes
required are not extensive. RFC 1886, entitled IPv6 DNS Extensions and published in
December 1995, was the IETF's first formalized attempt to describe the changes needed
in DNS to support IPv6. It defines three specific modifications to DNS for IPv6:

o New Resource Record Type—AAAA (IPv6 Address):

The regular DNS Address resource record is defined for a 32-bit

IPv4 address, so a new one was created to allow a domain name to be associated
with a 128-bit IPv6 address. The four “A”s (“AAAA”) are a mnemonic to
25
 indicate that the IPv6 address is four times the size of the IPv4 address. The
AAAA record is structured in very much the same way as the A record in both
binary and master file formats, it is just much larger. The DNS resource record
type value for AAAA is 28.

o New Reverse Resolution Hierarchy:

A new hierarchical structure similar to IN-ADDR.ARPA is

defined for IPv6 reverse lookups, but the IETF put it in a different top-level
domain. The new domain is IP6.INT, and is used in a way similar to how IN-
ADDR.ARPA works. However, since IPv6 addresses are expressed in
hexadecimal instead of dotted-decimal, IP6.INT has sixteen sub domains 0
through F, and each of those has sixteen sub domains 0 through F, and so on,
sixteen layers deep. This leads to a potentially frightfully large reverse resolution
database.

o Changes To Query Types And Resolution Procedure:

All query types that work with A records or result in A records

being included in the Additional section of a reply must be changed to also
handle AAAA records. Also, queries that would normally result in A records
being returned in the Additional section must return the corresponding AAAA
records only in the Answer section, not the Additional section

8.3 Disabling IPv6 because of incompatibilities

Various Internet forums carry reports of people disabling IPv6 because of perceived
slowdowns when connecting to hosts on the Internet.

In most cases, this "slow-down" results from DNS resolution failures due to faulty NAT
devices and other DNS resolvers which improperly handle the AAAA DNS query. These
DNS resolvers just drop the DNS request for AAAA records, instead of properly
returning the appropriate negative DNS response. Because the request is dropped, the
host sending the request has to wait for a timeout to trigger, thus causing a perceived
slow down when connecting to new hosts. Since there is no result of the request that
could be cached locally, even if a DNS cache is running, the problem will persist for
identical lookups in the future. If the domain name system is working properly, another
likely delay is caused by misrouting of IPv6 packets.

Conclusion
In 1987, The IETF ratified the DNS as an Internet standard to solve the issues of
scalability surrounding the hosts.txt file. Since then, the widespread use of the DNS and
its ability to resolve host names into IP addresses for both users and applications alike in

26
a timely and fairly reliable manner, makes it a critical component of the Internet. The
distributed management of the DNS and support for redundancy of DNS zones across
multiple servers promotes its robust characteristics. However, the original DNS protocol
specifications did not include security. Without security, the DNS is vulnerable to attacks
stemming from cache poisoning techniques, client flooding, dynamic update
vulnerabilities, information leakage, and compromise of a DNS server’s authoritative
files.

In order to add security to the DNS to address these threats, the IETF added security
extensions to the DNS, collectively known as DNSSEC. DNSSEC provides
authentication and integrity to the DNS. With the exception of information leakage, these
extensions address the majority of problems that make such attacks possible. Cache
poisoning and client flooding attacks are mitigated with the addition of data origin
authentication for RR Sets as signatures are computed on the RR Sets to provide proof of
authenticity. Dynamic update vulnerabilities are mitigated with the addition of
transaction and request authentication, providing the necessary assurance to DNS servers
that the update is authentic.

DNSSEC can not provide protection against threats from information

leakage. This is more of an issue of controlling access, which is beyond the scope of
coverage for DNSSEC. Adequate protection against information leakage is already
provided through such things as split DNS configuration.

DNSSEC demonstrates some promising capability to protect the Internet infrastructure

from DNS based attacks. DNSSEC has some fairly complicated issues surrounding its
development, configuration, and management.

DNS resides the Internet Protocol in the TCP/IP protocol suite architecture, it works
intimately with IP addresses. For this reason, changes are required to allow it to support
the new IPv6. These changes include the definition of a new IPv6 address resource record
(AAAA), a new reverse resolution domain hierarchy, and certain changes to how
messaging is performed.

References

27
 • Mockapetris. P., Domain Names - Concepts and Facilities, STD 13, RFC 1034,
November 1987.
• Mockapetris. P., Domain Names - Implementation and Specifications, STD 13,
RFC 1035, November 1987.

• IETF DNSSEC WG, DNS Security (dnssec) Charter, IETF, 1994.

• Vixie, P., Thomson, S. Rekhter, Y. and J. Bound, Dynamic Updates in the

Domain Name System (DNS UPDATE), RFC 2136, April 1997

• Douglas E.Comer,Computer and Internet,2nd edition

External links

• http://en.wikipedia.org/wiki/Domain_Name_System
• ftp://ftp.isi.edu/in-notes/rfc1034.txt
• ftp://ftp.isi.edu/in-notes/rfc1035.txt
• http://www.ietf.cnri.reston.va.us/proceedings/94dec/charters/dnssec-charter.html)
• ftp://ftp.isi.edu/in-notes/rfc2136.txt
• http://netbook.cs.purdue.edu
• http://www.mhhe.com/forouzan/dcn4sie

28