Data Networking/Fall 2014/Dearnetworks

From Wikiversity
Jump to navigation Jump to search

LINUX Project - TELE5330 - D.E.A.R

This page was created in order to explain the procedures for completing LINUX Project

1. The Folks

Robert Kley Lageano de Oliveira NUID:001797253

Eady Alnaqi NUID:001726045

Nidhi Kurup NUID:001776021

Arman Muratbayev NUID:001777022

2. Motivation

Learn how to design and implement a network for a start up company that needs a DHCP server and DNS server as well as a Web server for its applications. implementing the concepts learnt in class to real life scenarios and experiencing the challenges faced while setting up a network for a small scale start-up.

3. Understanding the Protocol


DNS stands for Domain Name Service and is basically a service that can resolve an IP address into a Domain name and vice versa. The DNS is a distributed database implemented in hierarchy of DNS servers, an application-layer protocol that allows hosts to query the distributed database. Moreover, DNS servers are often UNIX machines running the Berkeley Internet Name Domain or simply BIND software. It is also important to highlight that the DNS protocol runs over UDP and uses port 53.

In a DNS protocol, there are basically two types of message involved in the process. The DNS query and the DNS reply messages are involved in a DNS request. The semantics of a DNS message is as follows:

1. The first 12 bytes is the header section, which has a number of fields. The first field is a 16-bit number that identifies the query. This identifier is copied into the reply message to a query, allowing the client to match received replies with sent queries. There are a number of flags in the flag field. A 1-bit query/reply flag indicates wether the message is a query(0) or a reply(1). A 1-bit authoritative flag is set in a reply message when a DNS server is authoritative server for a queried name. A 1-bit recursion-desired flag is set when a client (host or DNS server) desires that the DNS server perform recursion qhen it doesn't have the record. A 1-bit recursion available field is set in a reply if the DNS server supports recursion. In the header, there are also four number-of fileds. These fields indicates the number of occurrences of the four types of data section that follow the header.

2. In the question section that are information about the query that is being made. This section includes a name field that contains the name that is being queried and a type of field that indicates the type of question being asked about the name.

3. In a reply from the DNS server, the answer section contains the resource records for the name that was queried.

4. The authoritative section contains records of other authoritative servers.

5. The additional section contains other helpful records. For example, information about canonical hostnames.

The various steps involved are:

Step 1: The client first send a DNS query message to its local server, this query message contains the hostname that needs to be translated.

Step 2: The local DNS server forwards the query message to the root server, if needed.

Step 3: The DNS server then analyzes the suffix and returns a list of IP addresses for TLD (Top Level Domain) servers that responsible for the domain.

Step 4: Finally the local DNS server resends the query message directly to the DNS server responsible for the hostname which responds with the IP address of it.


DHCP stands for Dynamic Host Configuration Protocol.

As the name suggests, DHCP is used to control the network configuration of a host through a remote server. DHCP functionality comes installed as a default feature in most of the contemporary operating systems. DHCP is an excellent alternative to the time-consuming manual configuration of network settings on a host or a network device. DHCP works on a client-server model. Being a protocol, it has it’s own set of messages that are exchanged between client and server.

1. DHCPDISCOVER It is a DHCP message that marks the beginning of a DHCP interaction between client and server. This message is sent by a client (host or device connected to a network) that is connected to a local subnet. It’s a broadcast message that uses as destination IP address while the source IP address is

2. DHCPOFFER It is DHCP message that is sent in response to DHCPDISCOVER by a DHCP server to DHCP client. This message contains the network configuration settings for the client that sent the DHCPDISCOVER message.

3. DHCPREQUEST This DHCP message is sent in response to DHCPOFFER indicating that the client has accepted the network configuration sent in DHCPOFFER message from the server.

4. DHCPACK This message is sent by the DHCP server in response to DHCPREQUEST recieved from the client. This message marks the end of the process that started with DHCPDISCOVER. The DHCPACK message is nothing but an acknowledgement by the DHCP server that authorizes the DHCP client to start using the network configuration it received from the DHCP server earlier.

5. DHCPNAK This message is the exact opposite to DHCPACK described above. This message is sent by the DHCP server when it is not able to satisfy the DHCPREQUEST message from the client.

6. DHCPDECLINE This message is sent from the DHCP client to the server in case the client finds that the IP address assigned by DHCP server is already in use.

7. DHCPINFORM This message is sent from the DHCP client in case the IP address is statically configured on the client and only other network settings or configurations are desired to be dynamically acquired from DHCP server.

8. DHCPRELEASE This message is sent by the DHCP client in case it wants to terminate the lease of network address it has be provided by DHCP server.

The steps involved in the client receiving an IP address from the DHCP server are:

Step 1: When the client computer (or device) boots up or is connected to a network, a DHCPDISCOVER message is sent from the client to the server. As there is no network configuration information on the client so the message is sent with as source address and as destination address. If the DHCP server is on local subnet then it directly receives the message or in case it is on different subnet then a relay agent connected on client’s subnet is used to pass on the request to DHCP server. The transport protocol used for this message is UDP and the port number used is 67. The client enters the initializing stage during this step.

Step 2: When the DHCP server receives the DHCPDISCOVER request message then it replies with a DHCPOFFER message. As already explained, this message contains all the network configuration settings required by the client. For example, the yaddr field of the message will contain the IP address to be assigned to client. Similarly the the subnet mask and gateway information is filled in the options field. Also, the server fills in the client MAC address in the chaddr field. This message is sent as a broadcast ( message for the client to receive it directly or if DHCP server is in different subnet then this message is sent to the relay agent that takes care of whether the message is to be passed as unicast or broadcast. In this case also, UDP protocol is used at the transport layer with destination port as 68. The client enters selecting stage during this step

Step 3: The client forms a DHCPREQUEST message in reply to DHCPOFFER message and sends it to the server indicating it wants to accept the network configuration sent in the DHCPOFFER message. If there were multiple DHCP servers that received DHCPDISCOVER then client could receive multiple DHCPOFFER messages. But, the client replies to only one of the messages by populating the server identification field with the IP address of a particular DHCP server. All the messages from other DHCP servers are implicitly declined. The DHCPREQUEST message will still contain the source address as as the client is still not allowed to use the IP address passed to it through DHCPOFFER message. The client enters requesting stage during this step.

Step 4: Once the server receives DHCPREQUEST from the client, it sends the DHCPACK message indicating that now the client is allowed to use the IP address assigned to it. The client enters the bound state during this step.

4. The Requirements

  • Implementing DNS,DHCP and WebServer with Firewall for a StartUp company in Boston.
  • DNS :
     1) Get a Domain name for the Start Up                                 
     2) Configure name servers to handle queries for the domain                          
     3) Use BIND/Posadis/PowerDNS server
     4) Create 5 DNS records in the DNS Server
     5) Create reverse domains in for the addresses
  • DHCP :
     1) Assign a set of IP addresses for leasing to clients
     2) Exclude addresses which are generally used for hardware devices or static ip addresses
     3) Setting a lease time for which a client may use an ip address before it must re-lease the ip address or request for a new one
     4) Dynamic allocation of ip addresses
     5) Implementing PXE Boot and RARP
  • Webserver and Firewall :
     1) Use Command line tools and packages to install webserver and implement Firewall
     2) Host a web page on the webserver and make the page accessible to clients in the network using a web browser
     3) Make the server the most secured one in all possible ways

5.Steps to perform the setup / installation

1) DNS

Install BIND server:

       sudo apt-get update
       sudo apt-get install bind9 bind9utils bind9-doc

Edit BIND service to IPv4:

       gksudo gedit /etc/default/bind9

Options should be set to:

       OPTIONS="-4 -u bind"

Configure Options file:

       gksudo gedit /etc/bind/named.conf.options

The file should look like this:

       options {
            directory "/var/cache/bind";
            recursion yes;                 # enables resursive queries
            allow-recursion { trusted; };  # allows recursive queries from "trusted" clients
            listen-on {; };   # ns1 private IP address - listen on private network only
            allow-transfer { none; };      # disable zone transfers by default
            forwarders {

Save and exit the file.

Configure the local file:

   gksudo gedit /etc/bind/named.conf.local

Add the forward zone to the file:

   zone "" {
       type master;
       file "/etc/bind/zones/"; # zone file path
       allow-transfer {; };         # ns2 private IP address - secondary

Add the reverse zone to the file:

   zone "" {
       type master;
       file "/etc/bind/zones/db.1.168.192";  #
       allow-transfer {; };  # ns2 private IP address - secondary

Now, we need to create the file zones.

First, we create a directory for the files:

   sudo mkdir /etc/bind/zones

Start with the file "db.local" transferring it to the new directory:

   cd /etc/bind/zones
   sudo cp ../db.local ./}

Edit forward zone:

   gksudo gedit /etc/bind/zones/

Edit the file to look like this:

   $TTL    604800
   @       IN      SOA (
                     3       ; Serial
                604800     ; Refresh
                 86400     ; Retry
               2419200     ; Expire
                604800 )   ; Negative Cache TTL
   ; name servers - NS records
        IN      NS
        IN      NS
   ; name servers - A records          IN      A          IN      A
   ; - A records        IN      A        IN      A              IN      A

Now create the reverse time zone:

   cd /etc/bind/zones
   sudo cp ../db.127 ./db.1.168.192

Now edit the reverse time zone file:

   sudo vi /etc/bind/zones/db.1.168.192

The edited reverse time zone file should look as follows:

   $TTL    604800
   @       IN      SOA (
                                 3         ; Serial
                            604800         ; Refresh
                             86400         ; Retry
                           2419200         ; Expire
                            604800 )       ; Negative Cache TTL
   ; name servers
         IN      NS
         IN      NS
   ; PTR Records
   5     IN      PTR    ;
   6     IN      PTR    ;
   100   IN      PTR  ;
   101   IN      PTR  ;
   23    IN      PTR        ;

Check BIND configuration syntax:

   sudo named-checkconf

Check the correctness of the zone files:

   sudo named-checkzone
   sudo named-checkzone /etc/bind/zones/db.1.168.192

Restart BIND:

   sudo service bind9 restart


DHCP server installation

   sudo apt-get install isc-dhcp-server -y

Assignment of interface on what the DHCP server (dhcpd) will serve requests:

   sudo nano /etc/default/isc-dhcp-server

Main configuration file dhcpd.conf file:

  sudo nano /etc/dhcp/dhcpd.conf

Set the domain name and domain-name servers:

  # option definitions common to all supported networks...
      option domain-name "";
      option domain-name-servers;

Make our DHCP authoritative inside the network:


Add of DNS zone and DNS reverse zone:

  # DNS zones
    zone {
      primary; #This server is the primary DNS server for this zone
    zone {

Define the subnet, range of ip addresses, domain and domain name servers:

  # A slightly different configuration for an internal subnet.
   subnet netmask {
      option domain-name-servers;
      option domain-name "";
      option routers;
      option broadcast-address;
      default-lease-time 600;
      max-lease-time 7200;

2.1) PXE network booting

PXE stands for "Pre-boot eXecution Environment". In order to use PXE you need to setup a boot-server which will allow client systems to :

Request an IP address (via DHCP) Download a kernel (via TFTP)

TFTP Setup

Installing TFTP

   apt-get install tftpd-hpa

Enable it by editing the file /etc/default/tftpd-hpa:

  #Defaults for tftpd-hpa
     OPTIONS="-l -s /var/lib/tftpboot"

Create the root directory:

   mkdir -p /var/lib/tftpboot
   /etc/init.d/tftpd-hpa start
   Starting HPA's tftpd: in.tftpd.

PXE Configuration

Create a file, which will contain the list of kernels which are available to boot:

    mkdir /var/lib/tftpboot/pxelinux.cfg
      DISPLAY boot.txt
      DEFAULT etch_i386_install
      LABEL etch_i386_install
             kernel debian/etch/i386/linux
             append vga=normal initrd=debian/etch/i386/initrd.gz  --
      LABEL etch_i386_linux
             kernel debian/etch/i386/linux
             append vga=normal initrd=debian/etch/i386/initrd.gz  --
      LABEL etch_i386_expert
             kernel debian/etch/i386/linux
             append priority=low vga=normal initrd=debian/etch/i386/initrd.gz  --
      LABEL etch_i386_rescue
             kernel debian/etch/i386/linux
             append vga=normal initrd=debian/etch/i386/initrd.gz  rescue/enable=true --
      PROMPT 1
      TIMEOUT 0

Create and edit Boot.txt:

     - Boot Menu -

Download the official installer kernel and associated files and save them in specified directories:

     cd /var/lib/tftpboot/
     mkdir -p /var/lib/tftpboot/debian/etch/i386
     cd /var/lib/tftpboot/debian/etch/i386

2.2) RARP

Install the package with:

 sudo apt-get install rarpd

Create an /etc/ethers file, listing your client:

   CC:CC:CC:CC:CC:CC     client

Add your client to the /etc/hosts file: client

Start RARP daemon:

  rarpd -A

3) WebServer / Firewall

Installing Web server and hosting a webpage in Linux

Execute the following command on the Linux terminal to install Apache web server:

  sudo apt-get install apache2

Edit the default HTML page to design web page as per our requirement:

  sudo gedit /var/www/html/index.html

Implenting Firewall in Linux by configuring iptables

Allow systems hosting DNS and DHCP to access web server:

  sudo iptables -A INPUT -m iprange --src-range -j ACCEPT

Allow clients to access web server through HTTP and SSH:

  sudo iptables -A INPUT -p tcp --dport 80 -m iprange --src-range -j ACCEPT 
  sudo iptables -A INPUT -p tcp --dport 22 -m iprange --src-range -j ACCEPT  

Command to list out all the rules configured in the iptables:

  sudo iptables -L

Save the iptables to a file:

  sudo iptables-save > /home/anku/rules.v4

Restore the iptables if a reboot occurs:

  sudo iptables-restore < /home/anku/rules.v4

6. Testing

1) Connect the systems hosting DNS, DHCP, Webserver and the Client together using a switch

2) Check for working of the DHCP server :

  • As soon as the client is connected to the network, the DHCP starts assigning ip addresses dynamically to the hosts in the network.
  • The client gets an ip address from the range of available addresses of the DHCP server for a designated lease time.
  • Check if the client is getting a valid ip address from the DHCP

3) Check for working of the DNS server

  • The DNS server has entries for translating/ reverse translating the webpage being hosted in the network.
  • As soon as the client tries to access the webpage using the web-browser, the client sends out a DNS query to the DNS server for translation of the webpage address
  • The DNS replies back with the IP address of the webserver hosting the web page.
  • Check if the client gets as far as getting the DNS query response for the translation request using Wireshark.

4) Check for working of the Web Server

  • After receiving the IP address of the webserver, the client tries to connect to the webserver using this information provided by the DNS server.
  • Check if the client is able to access the webpage through the web browser.

5) Check for the firewall implementation

  • The iptables are configured such that the client is able to access the web server using the TCP protocol at port number 80 (for HTTP) and at port number 22 (for SSH) and is blocked for any other type of access.
  • Check if the client is able to view the webpage using the web browser (this confirms access using HTTP). Try SSH to the web server to check for its working.
  • Hosts not in the network should not be able to access the web server

7. Future Prospects

  • Adding a secondary physical DNS server machine to the network (IP: to the network would increase its DNS resiliency.
  • Adding a trusted DNS list to the DNS servers to increase the level of security. Only specified hosts can inquire the DNS servers.
  • Setting up VPN on the web server side as well as the client’s side to secure the data transfer and avoid manipulation of packets in transit. Hosts outside the network could also be given access provided public IP addresses are used with DMZ/NAT configurations if necessary.
  • Configure NFS server to allow clients on the network to access files over the network much like local storage is accessed.

8. Citations