A Project Report On

“Implement a DNS server using client server architecture.”

NATIONAL INSTITUE OF TECHNOLOGY

PATNA
Department of Computer Science & Engineering

Submitted by:
Name Roll no.

Priyanshu Sinha 2571035

Avyudh Shukla 2571004
Ashish Vishwkarma 2571024

Course Code:
Course Title: Computer Networks
Branch: MCA (DS & In)
 TABLE OF CONTENTS

1. Introduction
1.1 What is DNS (Domain Name System)?
1.2 Origin and Development of DNS
1.3 DNS Name Space

1.4 Distribution of Name Space

1.5 DNS Name Resolution
1.6 Process of Resolving Domain Names
1.7 Significance of DNS
2. System Requirements
2.1 Hardware Requirements
2.2 Software Requirements
2.3 Network Configuration
3. Code
3.1 Server side
3.2 Client side
4. Output

5. Observation

6. Conclusion

7. Learning Outcomes

8. References
Objectives:
1. To develop a DNS server that performs:
o Conversion of domain names to IP addresses. o

Reverse lookup of IP addresses to domain names.

2. To implement communication between the client and server using socket
programming.
 1. INTRODUCTION:

1.1. What is Domain Name System (DNS)?

The Domain Name System (DNS) is a vital part of the Internet’s overall
structure, responsible for helping users connect to websites, applications, and
online resources. It functions much like a digital “phone directory” for the
internet. While humans prefer to use readable and memorable domain names
such as [Link], computers and networking devices rely on
numerical IP addresses like [Link] to identify and locate each other.
DNS serves as the system that automatically translates these simple domain
names into their corresponding IP addresses. This translation process ensures
that when a user enters a website name into a browser, the request is directed to
the correct server. Without DNS, users would be required to remember long
strings of numbers for every website they want to visit, making the internet
extremely difficult to use. Therefore, DNS plays a foundational role in making
online browsing fast, simple, and user-friendly.

1.2 Origin and Development of DNS

The origins of the Domain Name System (DNS) go back to the early days of the
internet, when it existed as a small research network known as ARPANET.
During that time, a single centrally maintained file called “[Link]” was used
to store the mappings between hostnames and their IP addresses. However, as
the network expanded and more computers were added, managing this file
became increasingly difficult and inefficient.
To solve this problem, Paul Mockapetris and Jon Postel introduced the
modern
DNS in 1983 through RFC 882 and RFC 883. Their work established a new
distributed, hierarchical naming system that could grow along with the rapidly
expanding internet. This breakthrough laid the foundation for the scalable,
reliable, and efficient DNS structure that supports today’s global internet.
 FIGURE A-Example of using the DNS server

1.3 DNS Name Space

The DNS is organized hierarchically, with a structured naming system to ensure
that domain names are unique and globally resolvable. To have a hierarchical
name space, a domain name space was designed. In this design the names are
defined in an inverted-tree structure with the root at the top. The tree can have
only 128 levels: level 0 (root) to level 127 (see Figure B).

Figure B: Domain Name Space

Label
Every node in the DNS hierarchy has a label, which is simply a text string that
can contain up to 63 characters. The root of the DNS tree has an empty label,
meaning it has no name. DNS also ensures that all child nodes under the same
parent must have unique labels. This rule prevents duplication and ensures that
every domain name in the entire DNS structure remains unique and easily
identifiable.

Domain Name
Each node in the tree has a domain name. A full domain name is a sequence of
labels separated by dots (.). The domain names are always read from the node
up to the root. The last label is the label of the root (null). This means that a full
domain name always ends in a null label, which means the last character is a dot
because the null string is nothing.
Figure C shows some domain names.

Figure C: Domain Names and levels

1.4 Distribution of Name Space

All the information in the domain name space needs to be stored somewhere, but
keeping it on a single computer would be both inefficient and risky. It would be
inefficient because one system handling requests from users across the world
would quickly become overloaded. It would also be unreliable, since if that single
computer failed, the entire DNS data would become unreachable. Therefore,
storing everything in one place is neither practical nor safe.
Hierarchy of Name Servers
The solution to these issues is to spread the DNS information across multiple
computers known as DNS servers. This distribution is done by dividing the
entire namespace into several domains at the first level. In simple terms, the root
exists alone at the top, and each first-level node becomes a separate domain or
subtree.
Since some of these domains can still be very large, DNS allows them to be
broken down into smaller parts called subdomains. Each DNS server can then
be made responsible (authoritative) for either a big domain or a small one. This
creates a layered system of servers that matches the hierarchical structure of the
domain name space itself. In other words, we have a hierarchy of servers in the
same way that we have a hierarchy of names (see Figure D).

FIGURE D-Hierarchy of Name Server

Zone
Since the complete domain name hierarchy cannot be stored on a single server,
it is divided among many servers. What a server is responsible for or has
authority over is called a zone. We can define a zone as a contiguous part of the
entire tree.

Root Server
A root server is a DNS server whose zone covers the entire domain name tree.
Instead of storing detailed information about every domain, a root server mainly
delegates its authority to other DNS servers and keeps pointers or references to
them. Multiple root servers exist, and each one has access to the complete
domain name space. These servers are strategically distributed across the world
to ensure reliability and fast access.

Primary and Secondary Servers

DNS defines two types of servers: primary and secondary.
A primary server is the DNS server that holds the original zone file for which
it is authoritative. It is responsible for creating, managing, and updating this
zone file, and the file is stored directly on its local disk.
A secondary server, on the other hand, obtains a complete copy of the zone
information from another DNS server (either a primary or another secondary). It
stores this copied zone file on its own disk but does not create or modify it. Any
updates to the zone data must be made on the primary server, which then sends
the updated information to the secondary server.
1.5 DNS Name Resolution
Mapping a name to an address or an address to a name is called nameaddress
resolution.

Resolver
DNS is designed as a client/server application. A host that needs to map an
address to a name or a name to an address calls a DNS client called a resolver.
The resolver accesses the closest DNS server with a mapping request. If the
server has the information, it satisfies the resolver; otherwise, it either refers the
resolver to other servers or asks other servers to provide the information.
After the resolver receives the mapping, it interprets the response to see if it is a
real resolution or an error, and finally delivers the result to the process that
requested it.

Mapping Names to Addresses

Most of the time, the resolver gives a domain name to the server and asks for the
corresponding address. In this case, the server checks the generic domains or the
country domains to find the mapping.
If the domain name is from the generic domains section, the resolver receives a
domain name such as "[Link].". The query is sent by the resolver to
the local DNS server for resolution. If the local server cannot resolve the query,
it either refers the resolver to other servers or asks other servers directly.
If the domain name is from the country domains section, the resolver receives a
domain name such as "[Link].". The procedure is the same.
Mapping Addresses to Names
A client can send an IP address to a server to be mapped to a domain name. As
mentioned before, this is called a PTR query. To answer queries of this kind,
DNS uses the inverse domain. However, in the request, the IP address is
reversed and the two labels in-addr and arpa are appended to create a domain
acceptable by the inverse domain section. For example, if the resolver receives
the IP address [Link], the resolver first inverts the address and then adds
the two labels before sending. The domain name sent is
"[Link].[Link]." which is received by the local DNS and resolved.

Recursive Resolution
The client (resolver) can ask for a recursive answer from a name server. This
means that the resolver expects the server to supply the final answer. If the
server is the authority for the domain name, it checks its database and responds.
If the server is not the authority, it sends the request to another server (the parent
usually) and waits for the response. If the parent is the authority, it responds;
otherwise, it sends the query to yet another server. When the query is finally
resolved, the response travels back until it finally reaches the requesting client.
This is called recursive resolution and is shown in Figure E.

Figure E: Recursive Resolution

Iterative Resolution
If the client does not ask for a recursive answer, the mapping can be done
iteratively. If the server is an authority for the name, it sends the answer. If it is
not, it returns (to the client) the IP address of the server that it thinks can resolve
the query. The client is responsible for repeating the query to this second server.
If the newly addressed server can resolve the problem, it answers the query with
the IP address; otherwise, it returns the IP address of a new server to the client.
Now the client must repeat the query to the third server. This process is called
iterative resolution because the client repeats the same query to multiple servers.
In Figure F the client queries four servers before it gets an answer from the
[Link] server.

Figure F- Iterative Resolution

1.6 Process of Resolving Domain Names

Here is a clear and simple explanation of the Process of Resolving Domain
Names:

Process of Resolving Domain Names

The process of resolving domain names refers to how DNS translates a
humanreadable domain name (like [Link]) into an IP address that
computers can use to locate a website or service. The steps are as follows:
1. User Request
When a user types a domain name into the browser, the request is sent to
the DNS resolver (usually provided by the ISP).
 2. Check Local Cache
The resolver first checks its cache to see if it already knows the IP address
for the domain.
o If found, the process ends quickly.
o If not, it continues searching.
3. Query Root Server
The resolver contacts a root DNS server.
Root servers do not provide the final answer but direct the resolver to the
correct Top-Level Domain (TLD) server, such as .com, .org, .net, etc.
4. Query TLD Server
The resolver then sends a query to the TLD server (for example, the .com
server).
The TLD server replies with the address of the authoritative DNS server
for that specific domain.
5. Contact Authoritative DNS Server
The resolver finally queries the authoritative server, which has the actual
DNS records for the domain.
This server responds with the correct IP address of the requested website.
6. Return IP to Browser
The resolver returns the IP address to the user's browser.
7. Browser Connects to Website
With the IP address, the browser can now send a request directly to the
web server that hosts the site.
8. Caching for Future Use
The resolver also stores (caches) the IP address for a certain period
(TTL), so future access becomes faster.

1.7 Significance of DNS

DNS is a fundamental component of the internet for several reasons:
• Human-Readable Addresses: DNS allows users to access websites and
services using easy-to-remember domain names instead of having to
remember numerical IP addresses. This enhances userfriendliness and
accessibility.
Scalability: DNS is designed to handle the immense growth of the internet.
Its hierarchical structure and distributed nature ensure efficient and scalable
domain name resolution.
• Load Balancing: DNS can be used to distribute traffic across multiple
servers by associating a domain name with multiple IP addresses. This
 load balancing enhances the reliability and performance of websites and
services.
• Redundancy and Failover: DNS can be configured to provide
redundancy and failover capabilities. If one server or data center becomes
unavailable, DNS can direct traffic to alternative resources.
• Global Reach: DNS is a global system, enabling users from anywhere in
the world to access websites and services by their domain names. It plays
a crucial role in making the internet truly global.
• Security: DNS plays a role in security through techniques like DNSSEC
(DNS Security Extensions), which helps prevent DNS spoofing and
manin-the-middle attacks.
 [Link] REQUIREMENTS

2.1. Hardware Requirements

• Processor: Any modern processor (e.g., Intel Core i5 or equivalent) that
supports multi-threading.
• RAM: 2 GB or more • Storage: 100 MB or less
• Network:
o Ethernet or Wi-Fi for client-server communication.
o Support for TCP/IP protocol.

2.2. Software Requirements

• Operating System:
o Any operating system that supports C, such as:
▪ Windows 7/10/11
▪ Linux (Ubuntu, Debian, Fedora, etc.)
▪ macOS
• C Version:
o C99 or later (C11 recommended for better compatibility and
features)
1. C Compilers:
o GCC
(GNU Compiler Collec on) o Clang o
MSVC (Microsoft Visual C++ for Windows)

2.3. Network Configuration

• Network Protocol: TCP/IP for communication between the client
and server.
• IP Configuration:
• The server should have a static IP address (e.g., [Link] for
localhost during testing).
• The client must be able to connect to the server's IP address and
port number (default: 5353).
 3. CODE

3.1 Server Side

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <arpa/inet.h>

#define PORT 5353

struct DNS {
char domain[50];
char ip[20];
};

struct DNS records[] = {

{"[Link]", "[Link]"},
{"[Link]", "[Link]"},
{"[Link]", "[Link]"},
{"[Link]", "[Link]"},
{"[Link]", "[Link]"},
{"[Link]", "[Link]"}
};

int main() {
int sockfd;
struct sockaddr_in server, client;
socklen_t len = sizeof(client);
char input[100], output[100];
// Create UDP socket
sockfd = socket(AF_INET, SOCK_DGRAM, 0);

server.sin_family = AF_INET;
server.sin_port = htons(PORT);
server.sin_addr.s_addr = INADDR_ANY;

// Bind socket
bind(sockfd, (struct sockaddr*)&server, sizeof(server));

printf("UDP DNS Server running on port %d...\n", PORT);

while (1) {
memset(input, 0, sizeof(input));
memset(output, 0, sizeof(output));

// Receive data from client

recvfrom(sockfd, input, sizeof(input), 0,
(struct sockaddr*)&client, &len);

input[strcspn(input, "\r\n")] = 0;

printf("Client Query: %s\n", input);

strcpy(output, "Not found");

// Check if input is IP (reverse lookup)

if (strchr(input, '.')) {
for (int i = 0; i < 6; i++) {
if (strcmp(input, records[i].ip) == 0) {
strcpy(output, records[i].domain);
 break;
}
}
}

// Domain to IP lookup
for (int i = 0; i < 6; i++) {
if (strcmp(input, records[i].domain) == 0) {
strcpy(output, records[i].ip);
break;
}
}

// Send response to client

sendto(sockfd, output, strlen(output), 0,
(struct sockaddr*)&client, len);
}

close(sockfd);
return 0;
}
3.2 Client Side

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <arpa/inet.h>

#define PORT 5353

int main() {
int sock;
struct sockaddr_in server;
socklen_t len = sizeof(server);
char query[100], response[100];
char server_ip[] = "[Link]";

printf("Enter domain or IP: ");

scanf("%s", query);

// Create UDP socket

sock = socket(AF_INET, SOCK_DGRAM, 0);

server.sin_family = AF_INET;
server.sin_port = htons(PORT);
inet_pton(AF_INET, server_ip, &server.sin_addr);

// Send query to server

sendto(sock, query, strlen(query), 0,
(struct sockaddr*)&server, len);
memset(response, 0, sizeof(response));

// Receive response from server

recvfrom(sock, response, sizeof(response), 0,
(struct sockaddr*)&server, &len);

printf("Result from DNS Server: %s\n", response);

close(sock);
return 0;
}
 4. Output

1. Starting the DNS server:

2. Starting the client:

3. Giving Input the Domain name at client side:

4. Server responding with query received message:

5. Response from server to client side:

6. Giving Input the IP at client side:

7. Response from server to client side:

8. Giving Input the Unknown Domain at client side

9. Response from server to client side:
 5. OBSERVATION

1. Functional Observations
• Forward Lookup:
 The server successfully resolved domain names into their corresponding IP
addresses for entries available in its database.
 Example:
o Input: [Link]
o Output: [Link]
• Reverse Lookup:
 The server resolved IP addresses back to domain names if records existed.
o Input: [Link]
o Output: [Link]
• Error Handling:
 Queries not found in the database returned:
o Input: [Link]
o Output: Not Found
• Connectionless Communication:
 Since UDP is connectionless, the client sends requests without establishing a
connection, and the server responds immediately without session tracking.
2. Performance Observations
• Speed:
 Faster than TCP due to no connection setup (no handshake), resulting in low
latency responses.
• Reliability:
 UDP does not guarantee delivery, ordering, or duplication protection.
However, for this small DNS system, responses were mostly reliable in a
local environment.
• Scalability:
 Better scalability compared to TCP due to lightweight communication.
Suitable for handling multiple quick queries.
• Concurrent Requests:
 UDP allows handling multiple client requests more efficiently since it is
stateless and does not require maintaining connections.
3. Implementation Observations
• Ease of Implementation:
 Simpler than TCP because no connection establishment or teardown is
required.
• Modularity:
 Client and server remain independent and communicate using datagrams.
• Static DNS Records:
 Still limited by hardcoded dictionary; not suitable for dynamic or large-scale
DNS systems.
 6. CONCLUSION

The implemented DNS server using UDP demonstrates efficient and fast domain
resolution using a connectionless communication model. It provides basic forward
and reverse lookup functionalities while reducing overhead compared to TCP.
This implementation is suitable for lightweight and fast DNS queries, similar to
real-world DNS systems that primarily use UDP for performance reasons.
However, since UDP does not guarantee delivery or reliability, additional
mechanisms would be required in real-world systems for error handling,
retransmission, and security.
 7. LEARNING OUTCOMES

1. Understanding of DNS Basics

• Gained knowledge of how the Domain Name System (DNS) operates in
translating human-readable domain names into machine-readable IP addresses
and vice versa.
• Learned the difference between forward lookup (domain name to IP) and
reverse lookup (IP to domain name).

2. Practical Application of Client-Server Architecture

• Developed a solid understanding of the client-server communication model
using a connectionless protocol.
• Learned how clients send requests without establishing a connection and
servers respond independently.
• Understood how stateless communication works in network-based systems.

3. Socket Programming using UDP

• Acquired hands-on experience with socket programming in Python using
UDP:
o Creating UDP sockets using SOCK_DGRAM.
o Sending data using sendto() method.
o Receiving data using recvfrom() method.
o Implementing communication without connection establishment.

4. Understanding of UDP Communication

• Learned how UDP provides fast and lightweight communication without
handshake mechanisms.
• Understood the limitations of UDP such as lack of reliability, ordering, and
error [Link] UDP with TCP in terms of speed, efficiency, and
use cases (e.g., DNS, streaming).
 8. ROLES OF GROUP MEMBERS

Priyanshu Sinha: Documentation and Draft Report Writing

1. Gathered the theoretical knowledge of DNS and UDP communication.
2. Drafted the final report and explained the working of the UDP-based
program.
3. Ensured all documentation was up to date and accurately reflected project
changes.
4. Worked with team members to incorporate their feedback for clarity and
completeness.
5. Compiled references (Forouzan, Tanenbaum, Kurose & Ross) in correct
format.

Ashish Vishwkarma: Client-Side Code Development

1. Developed the DNS Client using UDP to send domain/IP queries to the
server.
2. Ensured the client correctly displays responses received from the server.
3. Tested client functionality for both forward and reverse lookup.
4. Implemented communication using sendto() and recvfrom() methods.
5. Designed all diagrams using Forouzan book as reference.

Avyudh Shukla: Server-Side Code Development

1. Designed and implemented the DNS Server using UDP (connectionless
communication).
2. Created and managed the domain–IP database for forward and reverse
lookup.
3. Handled client requests using datagrams without maintaining connections.
4. Processed queries and sent accurate responses using sendto() method.
5. Ensured proper error handling (e.g., “Not Found”) works correctly.
 9. REFERENCES

1. Forouzan, B. A. (2023). Computer Networks A top to Bottom Approach

(Indian Edition). McGraw-Hill. ISBN: 93-5532-490-1.
2. Tanenbaum, A. S., & Wetherall, D. (2010). Computer Networks (4th ed.).
Pearson. ISBN: 978-81-7758-165-2