Name: khaled alshiekh

Student Number: 202011120

Abstract
Throughout the World Wide Web the DNS protocol fills a main role in
allowing people use the network and find their way around. Enabling
the transparent translation from human language to computer’s, the
DNS lets us know where we want to go in the net without knowing the
32-bit IP-address of our destination but by knowing a meaningful name
representing it.
In this project we designed DNS compliant client and server models.
The DNS server model is a Name Server and it is programmed to
resolve DNS queries using the two protocol based algorithms. Using
these basic objects the simulation was configured.
The models and simulation of the DNS protocol was designed using the
OPNET modeler platform, written in C++.
The project, through its independent models, allows for future
projects the use of the designed model for creating more simulations
or other enhancements. One such enhancement will be done in part B
of this project in which we will add real delays taken from
experimental measurements. The system allows for easy adding of
different delay times to be used by the simulation, in order to allow
for analysis of reality based timing.
1. Introduction

1.1 Project Goal

The DNS client-server model designed in this project was implemented

in order to have an accurate, precise, to the bit model for simulation of
DNS transactions.
The project allows running a simulation of DNS transaction-

1. Client generates a query, sends it to its server.

2. Server receives and analyzes the client's query.

3. Server resolves the query and sends the response back to

the client.

1.2 Domain Name System

The Domain Name System protocol is a basic protocol in the Internet,

and is in use by all Internet users throughout the world, and by many
networks besides the Internet.
The DNS protocol's main functionality is to allow the use of names
instead of numbers, the computers use, to distinguish between different
web sites (and other Internet based information).
1.3 OPNET platform

The model is based on the OPNET platform – a network simulation

environment that enables simulation of different protocols, and
different scenarios. The OPNET has a high abstraction level ranging
from graphical interface representation of a network and its nodes,
easy ways of creating network topologies, down to C++ code
implementation of protocols.
The OPNET has many models based on different protocols built-in and
included. The OPNET simulation platform allows adding user-defined
modules and objects to its own, built-in, modules so that adding
functionality of a new protocol is possible.
In the simulations we can collect different statistics regarding network
traffic.

1.4 General Description

The DNS client-server model includes three main components:

1. Client model – creates and sends DNS queries. This is a

new OPNET model we implemented derived from a built-in
base client model.
2. Server model – receives, analyzes, and resolves the query
and sends response. This is a new OPNET model we
implemented derived from a built-in base server model.
3. Database – the server's DNS "knowledge" resource. A C+
+ package which we implemented is used by the server model.

1.5 Development Environment

The DNS client-server model is implemented on:

OPNET modeler 8.0

1.6 Operating the program

1.6.1 Preparations
(In edit-preferances)
• Mod_dirs – dns op_model location (in first line in the directory
list).

• The resource-record file location & name – the file should be

located in the same directory as the OPNET modeler executable
file. It's name should be <model_name>.txt (e.g. yahoo_com.txt
where the server's name is edited to be yahoo_com).
1.6.2 Operating the dns_app project

• Start the OPNET modeler.

• Open the dns_app project.

• Run simulation.

1.7 Using the DNS client-server model

(for future use - new

scenarios) • Start the
OPNET modeler.

• Open a new project.

• Insert in it the DNS models:

dns_server Node Model – the server model.

 Dns_client Node Model – the client model.

• Configure the topology.

• Configure the server names (using Edit Attributes).

• Match the server names to the names appearing in the resource

record file under NS (name servers) records (OPNET cannot
operate with "." in names). The simple option is to change "." to
"_".
• Make sure resource-record files (named properly – according to
the server’s name) are in relevant directory (as explained earlier
in the section).
• Run simulation.
2. Theoretical background - the Domain Name System

This next chapter will give you better understanding of the DNS
protocol, its structure and algorithms.
This is the foundation on which the "DNS client-server model" project
leans upon.

2.1 General

Almost every one knows some Internet sites address, such as

www.cnn.com.

What would it be like if we needed to remember this instead-

192.10.155.23? The DNS – Domain Name System gives us the comfort
of “knowing” Internet addresses, by knowing an understandable and
easy to remember name, which on the system will be translated to an
actual 32 bit Internet address.
The DNS protocol provides the mechanism to make the translation
possible, dynamic, fast, and available on many locations.
This system is used for different web sites (e.g. http, ftp, and telnet) and
for other net-based application mainly – e-mail. The protocol is
implemented over UDP transport protocol.
2.2 Description

The Domain Name System is a distributed database. This allows local

control of the segments of the overall database, yet data in each segment
are available across the entire network through a client-server scheme.
Name Servers constitute the server half of the DNS's client-server
mechanism. Name Servers contain information about some segments of
the database and make it available to clients.

2.3 DNS Structure

The structure of the DNS database is very similar to the structure of the
UNIX file system. The database appears as an inverted tree, with the
root node at the top. Each node has a text label- an identifier relative to
its parent.
The domain names are divided starting at the root. The second level in
the tree is consisted of three groups: generic domains; country domains;
inverse domain.
In figure 2.1 we can see the top division of the domain tree.

The root "."

Inverse domain Generic domains Country domains

 Figure 2.1 – DNS top domains

The relative identifier, along with its chain of parent nodes' labels
separated by dots, creates a unique name.
For example – the name of the node "comnet" in the figure 2.2 is:

comnet.technion.ac.il (the root does not add an extra ".") as seen by the
arrows.

The root "."

Each node may also be the root of a new subtree – a domain.

Every domain has a unique name (according to its identifier and path to
the root).
In DNS each domain can be administrated by a different organization.
Each organization can then break its domain into a number of
subdomains and handout responsibilities for those subdomains to
others. For example the "ac.il" domain is administrated by a central
organization in Israel while the "technion.ac.il" domain is administrated
by the technion itself.
Domains can contain both hosts and subdomains. Each host on a
network has a domain name, which points to it.
The delegation of subdomains creates different zones. A zone is a part
of a domain, which is under the administration of a single authority – a
specific name server. A name server who is authoritative for a zone
must have all the information needed for its zone.
Using this structure we have a distributed complete database of all the
hosts throughout the network. Each authoritative name server holds all
required information ranging from lower zones’ name servers which
were delegated by it (lower subdomains which are not administered by
it) to application specific information on a host (e.g. information for
t2.technion.ac.il mail-server & for its telnet server etc.). Using the
protocol’s algorithms we can reach the needed information from
somewhere in this database.
In figure 2.3 there is an illustration of the domain and zone structure.

Domains & zones