0% found this document useful (0 votes)
10 views15 pages

Dns Final Report Complete

This document describes a project to model the Domain Name System (DNS) client-server model using the OPNET simulation platform. It includes background on DNS and OPNET modeling, descriptions of the client and server modules developed, and conclusions from the project.

Uploaded by

acer273404
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
10 views15 pages

Dns Final Report Complete

This document describes a project to model the Domain Name System (DNS) client-server model using the OPNET simulation platform. It includes background on DNS and OPNET modeling, descriptions of the client and server modules developed, and conclusions from the project.

Uploaded by

acer273404
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 15

Computer Networks Lab Winter 2002

Technion - Israel Institute of Technology


Electrical Engineering
Computer Networks Lab

DNS Client – Server Model on


OPNET.

Authors: Amit Dolev.


Amir Wiener.

Instructor: Nir Arad.

1
Project site: http://www.comnet.technion.ac.il/~cn10w02
Computer Networks Lab Winter 2002

Index

INDEX .................................................................................................................................................1

ABSTRACT ........................................................................................................................................4

1. INTRODUCTION ..........................................................................................................................5
1.1 PROJECT GOAL ............................................................................................................................5
1.2 DOMAIN NAME SYSTEM ..............................................................................................................5
1.3 OPNET PLATFORM......................................................................................................................5
1.6.1 Preparations ........................................................................................................................6
1.6.2 Operating the dns_app project ............................................................................................6
1.7 USING THE DNS CLIENT-SERVER MODEL ....................................................................................6
2. THEORETICAL BACKGROUND - THE DOMAIN NAME SYSTEM ..................................8
2.1 GENERAL .....................................................................................................................................8
2.2 DESCRIPTION ...............................................................................................................................8
2.3 DNS STRUCTURE ........................................................................................................................8
2.4 DNS DATABASE ITEMS ..............................................................................................................11
2.5 DNS PACKET FORMAT ...............................................................................................................11
2.6 DNS RESOLUTION ALGORITHMS ................................................................................................12
2.6.1 The recursive algorithm.....................................................................................................12
2.6.2 The iterative algorithm ......................................................................................................13
3. THEORETICAL BACKGROUND - OPNET MODELER BACKGROUND........................16
3.1 GENERAL ...................................................................................................................................16
3.2 SIMULATION STRUCTURE...........................................................................................................16
3.3 MODELING DOMAINS..................................................................................................................16
3.3.1 Network Domain................................................................................................................17
3.3.2 Node Domain.....................................................................................................................17
3.3.3 Process Domain.................................................................................................................18
3.4 DERIVED MODEL .......................................................................................................................21
4. THE SERVER DATABASE........................................................................................................22
4.1 CLASS RESOURCE_RECORD ......................................................................................................23
4.2 CLASS ZONE ..............................................................................................................................23
4.3 CLASS DB .................................................................................................................................24
5. THE CLIENT / SERVER MODULES .......................................................................................26
5.1 ETHERNET BASE MODEL ............................................................................................................26
5.2 GENERAL OVERVIEW OF OPNET DNS SENARIO .......................................................................27
5.3 DNS PACKET...............................................................................................................................28
5.4 CLIENT NODE MODEL.................................................................................................................32
5.4.1 General background ..........................................................................................................32
5.4.2 Application node – process hierarchy ...............................................................................33
5.4.3 Dns node – process hierarchy ...........................................................................................35
5.4.4 Tpal node – process hierarchy ..........................................................................................37
5.5 SERVER NODE MODEL ................................................................................................................39
5.5.1 General background ..........................................................................................................39
5.5.2 Application node – process hierarchy ...............................................................................40
5.5.3 Tpal node – process hierarchy ..........................................................................................43
5.5.4 UDP node – process hierarchy..........................................................................................43
6. SUMMARY AND CONCLUSIONS ...........................................................................................44
6.1 SUMMARY .................................................................................................................................44
6.2 COMPARISON OF GOALS WITH RESULTS .....................................................................................44
6.3 REMARKS ON PROJECT PROBLEMS .............................................................................................45

2
Project site: http://www.comnet.technion.ac.il/~cn10w02
Computer Networks Lab Winter 2002

6.4 FUTURE ENHANCEMENTS...........................................................................................................45


7. BIBLIOGRAPHY.........................................................................................................................46
7.1 RFC’S .......................................................................................................................................46
8. APPENDIXES ............................................................................................................................47
8.1 RESOURCE RECORDS .................................................................................................................47
8.2 HEADER FILES ...........................................................................................................................49

3
Project site: http://www.comnet.technion.ac.il/~cn10w02
Computer Networks Lab Winter 2002

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.

4
Project site: http://www.comnet.technion.ac.il/~cn10w02
Computer Networks Lab Winter 2002

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.

5
Project site: http://www.comnet.technion.ac.il/~cn10w02
Computer Networks Lab Winter 2002

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.

6
Project site: http://www.comnet.technion.ac.il/~cn10w02
Computer Networks Lab Winter 2002

• 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.

7
Project site: http://www.comnet.technion.ac.il/~cn10w02
Computer Networks Lab Winter 2002

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.

8
Project site: http://www.comnet.technion.ac.il/~cn10w02
Computer Networks Lab Winter 2002

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 "."

arpa gov com edu il uk

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 "."

il uk

ac co edu

technion biu

comnet

Figure 2.2 – DNS database structure

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).

9
Project site: http://www.comnet.technion.ac.il/~cn10w02
Computer Networks Lab Winter 2002

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.

ac.il domain The root "."

il uk
technion.ac.il domain

ac co edu
technion.ac.il zone

technion biu

comnet

comnet.technion.ac.il zone

Figure 2.3 – DNS database –


Domains & zones

10
Project site: http://www.comnet.technion.ac.il/~cn10w02
Computer Networks Lab Winter 2002

2.4 DNS database items


The database includes different types of Resource Records (rr’s). A resource record
holds information regarding address translation, name servers or mail exchange
server. For each information type is a resource record type (e.g. resource record for
address, resource record for name server etc.). This information in the name server
is derived from a local text file in the name server. This file (as implied earlier) has
the complete information of the name server’s authoritative zone. Other resource
records regarding other zones may be held by the name server as cached resource
records for a limited time (to insure dynamic update). From the information in the
resource record the server can resolve a query (using address resource record:
name=IP address), or help continue the search by sending the query to a closer
name server (using name server resource record: xx.yy name server’s IP
address=X).
A detailed example of a resource record is shown in the appendix (appendix a).

2.5 DNS packet format


The protocol works with a unique packet format. The same format is used for both
the query and the response. In the query the fields that are designated for holding
the response information are empty. Figure 2.4 shows the format.

Query Response

Header Header
identical

Question section Question section

Answer section

Authoritative section

Additional section

Figure 2.4 - DNS packet format

11
Project site: http://www.comnet.technion.ac.il/~cn10w02
Computer Networks Lab Winter 2002

2.6 DNS resolution algorithms


There are two algorithms in the DNS protocol, both enable the client get the most
accurate and authoritative answer. The two options differ from each other in the
client’s designated name server behavior.
According to these algorithms the resolving process in the OPNET DNS server
model is implemented.
The two resolution options of mapping requests are recursive and iterative.
Recursive resolution:
The server acts as resolver querying another server and so on recursively, until it
receives final answer, and sends it to client.
Iterative resolution:
The server repeats the same query to multiple servers until receives answer, which
is sent back to the client.
In both examples (figures 2.5 & 2.6) the clients DNS server is walla.com.

2.6.1 The recursive algorithm


(shown in figure 2.5)
1.Resolver accesses it’s DNS server with a mapping request. (First time it’s the
client, the next times it’s another server).
2.1.Server has the authority.
2.1.1 Server has the IP (lowest authority-zone/ cached)- sends response.
2.1.2 Server doesn’t have IP – sends request to lower server in hierarchy.(server is
.ac.il and needs to resolve xxx.technion.ac.il) and waits for response- then sends it
back to resolver.
2.2 Server Doesn’t have authority.
2.2.1 Server has the IP (cached)- sends response.
2.2.2 Server doesn’t have IP – sends request to another server (usually parent or
cached closest authorized DNS server) and waits for response- then sends it back to
resolver.

12
Project site: http://www.comnet.technion.ac.il/~cn10w02
Computer Networks Lab Winter 2002

Root server

if cached if cached
10 9

4
3
if cached
8
com il
if cached
11 5

2 ac.il 7
if cached
12
6
walla.com
technion.ac.il
1
Query= comnet.technion.ac.il

Figure 2.5 – recursive resolution exapmle.

2.6.2 The iterative algorithm


(shown in figure 2.6)
1.Client accesses DNS server with a mapping request.
2.1.Server has the lowest authority (in it’s zone).
2.1.1 Server has the IP - sends response.
2.2 Server has authority (but request not in it’s zone)
2.2.1 Server has the IP (cached) - sends response.
2.1.2 Server doesn’t have IP – sends query to closest server it knows, that might
have address (lower in the hierarchy).(server is .ac.il and needs to resolve
xxx.technion.ac.il). It will receive requested IP or IP to closer name server. Server
will continue in this iterative step to a new given name server and so on until
receives the final IP and then send it back to client.
13
Project site: http://www.comnet.technion.ac.il/~cn10w02
Computer Networks Lab Winter 2002

2.3 Server Doesn’t have authority.


2.3.1 Server has the IP (cached)- sends response.
2.3.2 Server doesn’t have IP – sends query to closest server it knows, that might
have address (usually parent or cached closest authorized DNS server). It will
receive requested IP back or IP to closer name server. Server will continue in this
iterative step to new given name server and so on until receives final IP and then
send it back to client.

1.Name server accesses another name server with an iterative mapping request.
2.1 Server has Authority –
2.1.1 Server has IP (lowest authority-zone/cached) – sends response with requested
IP.2.1.2 Server doesn’t have IP – sends back IP to another name server lower in the
hierarchy that is closer to the requested address.
2.2 Server doesn’t have authority –
2.2.1 Server has IP (cached) - sends response with requested IP.
2.2.2 Server doesn’t have IP - sends back IP closest name server to requested
address (parent/cached name server).

ac.il
com (has ac.il NS IP)

Q:comnet.technion.ac.il

if cached
3 4
if cached
Q:comnet.technion.ac.il 5
2
technion.ac.il

if cached 7
8
6
1 Q:comnet.technion.ac.il
Q:Comnet.technion.ac.il
walla.com

figure 2.6 – iterative resolution example (Q=query)

14
Project site: http://www.comnet.technion.ac.il/~cn10w02
Computer Networks Lab Winter 2002

Comment: In both algorithms in case of an illegal mapping query:


1.Client accesses DNS server with a mapping request.
2. Server finds the request illegal –
The requested address doesn’t exist (cached) or bad format of address - sends
response that there is no such address.

15
Project site: http://www.comnet.technion.ac.il/~cn10w02

You might also like