DEBARK UNIVERSITY

COLOGE OF NATURAL AND COMPUTIONAL

SCIENCE

DEPARTMENT OF COMPUTR SCIENCE

NAME ID
Gtasew Abebaw--------------------------------- 0123
Tsega Endalbaba---------------------------------
Addisa Kasahun----------------------------------

[Type the author name]

Table of Contents Page
1. Domain Name Server (DNS).........................................................................................................3

1.1. Definition of DNS..................................................................................................................1

1.2. How Does DNS Works?........................................................................................................1

1.2.1. Terminology........................................................................................................................1

1.2.3. Example of How DNS Works..............................................................................................4

Reference.............................................................................................................................................15

[Type the author name]

 1.1. How Does DNS Works?
1.2.1. Terminology

Domain Names: A domain name is a human-readable name - like amazon.com - that we type
in a web browser URL field. The Internet Corporation for Assigned Names and Numbers
(ICANN) manages these domain names

Top Level Domain (TLD): TLD refers to the last part of a domain name. For example, the
.com in amazon.com is the Top Level Domain. The most common TLDs include .com, .net,
org, and .info. Country code TLDs represent specific geographic locations. For example: .in
represents India. Here are some more examplesCOM– Commercial businesses.
GOV– U.S. government agencies.
EDU – Educational institutions such as universities.
ORG – Organizations (mostly non-profit).
MIL – Military.
NET – Network organizations.
EU – European Union.
Second Level Domain
This is the part of a domain name which comes right before the TLD - amazon.com for
example.
Sub Domain: A subdomain can be created to identify unique content areas of a web site. For
example, the awes of was.amazon.com.
Domain Name Registrar: By managing domain name reservations, name registrars are
critical to how DNS works. ICANN currently grants permission to organizations to act as
domain name registrars for specific higher level domains.
Domain Name System record types

A Record (Address record): A Records map server IP addresses to domain names. For
example, 72.21.206.6 to amazon.com.

[Type the author name]

CNAME: Canonical Name record. A CNAME record establishes one domain as an alias to
another (thereby routing all traffic addressed to the alias to the target; the canonical address).
Alias Record: Like a CNAME record, Alias records can be used to map one address to
another. But Aliases can coexist with other records using the same name.

MX Record: Mail Exchange Record. These records will redirect a domain’s email to the
servers hosting the domain’s user accounts. Mail exchange records are used for determining
the priority of email servers for a domain.

When a user types a human-readable address into the browser, the operating system’s DNS
client will check for information in a local cache. If the requested address isn’t there, it will
look for a Domain Name System server in the local area network (LAN). When the local
DNS server receives the query, and the requested domain name is found, it will return the
result.

Figure 1. How DNS system works

An Authoritative Root Name Server maintains and provides a list of authoritative name
servers for each of the top-level domains (.com, .org, etc.).

If the name is not found, the local server will forward the query to a DNS cache server, often
provided by the Internet Service Provider (ISP). Since the DNS server’s cache contains a

[Type the author name]

temporary store of DNS records, it will quickly respond to requests. These DNS cache
servers are called not authoritative DNS servers as they provide request resolution based in a
cached value acquired from authoritative DNS servers.

An Authoritative Top Level Domain Name Server maintains and provides a list of
authoritative name servers for all domains (gmail.com, wikipedia.org, etc.). Its job is to query
name servers to find and return the authoritative name server for the requested domain.

Now that we’ve got a better idea of how DNS works, the next post will introduce you
Amazon’s Route53 and show you.

Figure 2. DNS working principle example two

DNS is at the core of the Internet we use today.

The latest report shows there were 342.4 million domain names in the third quarter of 2018
and we would have been lost without DNS to resolve them into IP address.

When you want to call someone using your cell phone, it is highly unlikely you punch in the
exact phone number. Instead, you load the contact list and search using the person’s name.
DNS does the same thing when you want to load a website.

Resolving a domain name or a hostname goes through several different phases.

[Type the author name]

On some occasions, DNS resolving is a one-step process, while on the other it involves
contacting multiple DNS servers. The diagram below shows the necessary steps in this
process and does not take into account the browser cache.

1.2.3. Example of How DNS Works

Why is DNS Cached?

DNS caching or flushing is an effective way to reduce potential DNS queries towards DNS
name servers. This speeds up the domain name resolving procedure. Caching happens at
multiple locations. This includes your computer, sometimes routers, while all DNS servers
have their own databases with cached information.

Step 1 - Send a Request to Resolve a Domain Name

When you type www.phoenixnap.com into a browser, in order to load the webpage, your
computer asks for the IP address. Computers do not know in advance where they can find the
necessary information, so they try searching through the DNS cache and any available
external source.

Step 2 - Search for an IP Locally

Before going externally, your computer loads the local DNS cache database to see if you
already requested the IP for that domain name. Every computer has a temporary cache with
the most recent DNS requests and attempts to connect to online sources.

When the DNS cache has the IP data for the website that you are trying to connect to, the
page loads immediately.

Step 3 - Contact ISP and its Recursive DNS Server to Resolve a Domain Name

A computer’s local DNS cache database does not always contain the necessary data to
resolve a domain name. In that case, the request goes further to your Internet Service
Provider (ISP) and its DNS server.

Once it gets a request, the resolver looks in its records to provide the correct IP address.
When the necessary information is present in the ISP server’s cached records, the computer
gets back the IP and connects to the website.

Step 4 - Ask Outside DNS Servers to Provide an IP Address

ISP DNS resolvers are conservers to provide an IP Address

[Type the author name]

ISP DNS resolvers are configured to ask other DNS servers for correct IP address mapping
until they can provide data back to the requester. These are iterative DNS queries.

When a DNS client sends such a request, the first responding server does not provide the
needed IP address. Instead, it directs the request to another server that is lower in the DNS
hierarchy, and that one to another until the IP address is fully resolved. There are a few stops
in this process.

[Type the author name]

 INSTALATION

 At a terminal prompt, enter the following command to install dns:

 sudo apt install bind9
 A very useful package for testing and troubleshooting DNS issues is
the dnsutils package. Very often these tools will be installed already,
but to check and/or install  dnsutils enter the following:
 sudo apt install dnsutils

[Type the author name]

  There are many ways to configure BIND9. Some of the most
common configurations are a caching nameserver, primary master,
and as a secondary master.
 When configured as a caching nameserver BIND9 will find the
answer to name queries and remember the answer when the
domain is queried again.
 As a primary master server BIND9 reads the data for a zone from a
file on it's host and is authoritative for that zone.
 In a secondary master configuration BIND9 gets the zone data from
another nameserver authoritative for the zone.

 The DNS configuration files are stored in the  /etc/bind directory. The

primary configuration file is /etc/bind/named.conf.
 The include line specifies the filename which contains the DNS
options. The  directory  line in the  /etc/bind/named.conf.options  file
tells DNS where to look for files. All files BIND uses will be relative to
this directory.
 The file named /etc/bind/db.root  describes the root nameservers in
the world. The servers change over time, so
the /etc/bind/db.root  file must be maintained now and then. This is
usually done as updates to the  bind9 package. The zone  section
defines a master server, and it is stored in a file mentioned in
the file  option.
 It is possible to configure the same server to be a caching name
server, primary master, and secondary master. A server can be the
Start of Authority (SOA) for one zone, while providing secondary
service for another zone. All the while providing caching services for
hosts on the local LAN.

 The default configuration is setup to act as a caching server. All that

is required is simply adding the IP Addresses of your ISP's DNS
servers. Simply uncomment and edit the following
in /etc/bind/named.conf.options:
 forwarders {

[Type the author name]

  1.2.3.4;
 5.6.7.8;
 };
 Replace 1.2.3.4 and  5.6.7.8  with the IP Adresses of actual
nameservers.
 Now restart the DNS server, to enable the new configuration. From a
terminal prompt:
 sudo systemctl restart bind9.service
 See dig  for information on testing a caching DNS server.

 In this section  BIND9 will be configured as the Primary Master for

the domain example.com. Simply replace  example.com with your
FQDN (Fully Qualified Domain Name).
 Forward Zone File
 To add a DNS zone to BIND9, turning BIND9 into a Primary Master
server, the first step is to edit  /etc/bind/named.conf.local:
 zone "example.com" {
 type master;
 file "/etc/bind/db.example.com";
 };

 (Note, if bind will be receiving automatic updates to the file as with

DDNS, then use  /var/lib/bind/db.example.com  rather
than /etc/bind/db.example.com both here and in the copy command
below.)
 Now use an existing zone file as a template to create
the /etc/bind/db.example.com file:
 sudo cp /etc/bind/db.local /etc/bind/db.example.com
 Edit the new zone
file /etc/bind/db.example.com change  localhost.  to the FQDN of
your server, leaving the additional "." at the end.
Change 127.0.0.1 to the nameserver's IP Address
and root.localhost  to a valid email address, but with a "." instead of
the usual "@" symbol, again leaving the "." at the end. Change the
comment to indicate the domain that this file is for.
 Create an A record for the base domain, example.com. Also, create
an A record for  ns.example.com, the name server in this example:
[Type the author name]
  ;
 ; BIND data file for example.com
 ;
 $TTL 604800
 @ IN SOA example.com. root.example.com. (
 2 ; Serial
 604800 ; Refresh
 86400 ; Retry
 2419200 ; Expire
 604800 ) ; Negative Cache TTL
 IN A 192.168.1.10
 ;
 @ IN NS ns.example.com.
 @ IN A 192.168.1.10
 @ IN AAAA ::1
 ns IN A 192.168.1.10

 You must increment the Serial Number  every time you make changes
to the zone file. If you make multiple changes before restarting
BIND9, simply increment the Serial once.
 Now, you can add DNS records to the bottom of the zone file.
See Common Record Types  for details.
 Many admins like to use the last date edited as the serial of a zone,
such as 2012010100  which is yyyymmddss (where  ss is the Serial
Number)
 Once you have made changes to the zone file  BIND9 needs to be
restarted for the changes to take effect:
 sudo systemctl restart bind9.service

 Now that the zone is setup and resolving names to IP Adresses

a Reverse zone is also required. A Reverse zone allows DNS to
resolve an address to a name.
 Edit /etc/bind/named.conf.local and add the following:

[Type the author name]

  zone "1.168.192.in-addr.arpa" {
 type master;
 file "/etc/bind/db.192";
 };

 Replace 1.168.192 with the first three octets of whatever network

you are using. Also, name the zone
file /etc/bind/db.192 appropriately. It should match the first octet
of your network.
 Now create the  /etc/bind/db.192  file:
 sudo cp /etc/bind/db.127 /etc/bind/db.192
 Next edit  /etc/bind/db.192  changing the basically the same
options as /etc/bind/db.example.com:
 ;
 ; BIND reverse data file for local 192.168.1.XXX net
 ;
 $TTL 604800
 @ IN SOA ns.example.com. root.example.com. (
 2 ; Serial
 604800 ; Refresh
 86400 ; Retry
 2419200 ; Expire
 604800 ) ; Negative Cache TTL
 ;
 @ IN NS ns.
 10 IN PTR ns.example.com.

 The Serial Number  in the Reverse zone needs to be incremented on

each change as well. For each  A record  you configure
in /etc/bind/db.example.com, that is for a different address, you
need to create a PTR record in  /etc/bind/db.192.
 After creating the reverse zone file restart BIND9:
 sudo systemctl restart bind9.service

[Type the author name]

  Once a  Primary Master  has been configured a  Secondary Master  is
needed in order to maintain the availability of the domain should
the Primary become unavailable.
 First, on the Primary Master server, the zone transfer needs to be
allowed. Add the  allow-transfer  option to the example Forward
and Reverse zone definitions in /etc/bind/named.conf.local:
 zone "example.com" {
 type master;
 file "/etc/bind/db.example.com";
 allow-transfer { 192.168.1.11; };
 };
  
 zone "1.168.192.in-addr.arpa" {
 type master;
 file "/etc/bind/db.192";
 allow-transfer { 192.168.1.11; };

 Replace 192.168.1.11 with the IP Address of your Secondary

nameserver.
 Restart  BIND9 on the Primary Master:
 sudo systemctl restart bind9.service
 Next, on the Secondary Master, install the  bind9 package the same
way as on the Primary. Then edit
the /etc/bind/named.conf.local and add the following declarations
for the Forward and Reverse zones:
 zone "example.com" {
 type slave;
 file "db.example.com";
 masters { 192.168.1.10; };
 };

 zone "1.168.192.in-addr.arpa" {
 type slave;
 file "db.192";
 masters { 192.168.1.10; };
[Type the author name]
  };
 Replace 192.168.1.10 with the IP Address of your Primary
nameserver.
 Restart  BIND9 on the Secondary Master:

 sudo systemctl restart bind9.service

 In  /var/log/syslog you should see something similar to (some lines
have been split to fit the format of this document):
 client 192.168.1.10#39448: received notify for zone '1.168.192.in-
addr.arpa'
 zone 1.168.192.in-addr.arpa/IN: Transfer started.
 transfer of '100.18.172.in-addr.arpa/IN' from 192.168.1.10#53:
 connected using 192.168.1.11#37531
 zone 1.168.192.in-addr.arpa/IN: transferred serial 5
 transfer of '100.18.172.in-addr.arpa/IN' from 192.168.1.10#53:
 Transfer completed: 1 messages,
 6 records, 212 bytes, 0.002 secs (106000 bytes/sec)
 zone 1.168.192.in-addr.arpa/IN: sending notifies (serial 5)
  
 client 192.168.1.10#20329: received notify for zone 'example.com'
 zone example.com/IN: Transfer started.
 transfer of 'example.com/IN' from 192.168.1.10#53: connected using
192.168.1.11#38577
 zone example.com/IN: transferred serial 5
 transfer of 'example.com/IN' from 192.168.1.10#53: Transfer
completed: 1 messages,
 8 records, 225 bytes, 0.002 secs (112500 bytes/sec)

 Note: A zone is only transferred if the  Serial Number on the

Primary is larger than the one on the Secondary. If you want to
have your Primary Master DNS notifying Secondary DNS Servers of
zone changes, you can add  also-notify { ipaddress; }; in
to /etc/bind/named.conf.local as shown in the example below:
 zone "example.com" {

[Type the author name]

  type master;
 file "/etc/bind/db.example.com";
 allow-transfer { 192.168.1.11; };
 also-notify { 192.168.1.11; };
 };
  
 zone "1.168.192.in-addr.arpa" {
 type master;
 file "/etc/bind/db.192";
 allow-transfer { 192.168.1.11; };
 also-notify { 192.168.1.11; };
 };

 resolv.conf
 The first step in testing BIND9  is to add the nameserver's IP Address
to a hosts resolver. The Primary nameserver should be configured as
well as another host to double check things. Refer to  DNS Client
Configuration for details on adding nameserver addresses to
 your network clients, and afterwards check that the
file /etc/resolv.conf contains (for this example):
 nameserver 192.168.1.10
 nameserver 192.168.1.11

 A great way to test your zone files is by using the  named-

checkzone utility installed with the  bind9 package. This utility allows
you to make sure the configuration is correct before
restarting BIND9  and making the changes live.
 To test our example Forward zone file enter the following from a
command prompt:
 named-checkzone example.com /etc/bind/db.example.com
 If everything is configured correctly you should see output similar to:
 zone example.com/IN: loaded serial 6OK
 Similarly, to test the Reverse zone file enter the following:

[Type the author name]

  named-checkzone 1.168.192.in-addr.arpa /etc/bind/db.192
 The output should be similar to:

 zone 1.168.192.in-addr.arpa/IN: loaded serial 3OK

 The Serial Number  of your zone file will probably be different.

[Type the author name]

[Type the author name]
[Type the author name]
[Type the author name]
[Type the author name]