Introduction to the Domain Name System

Welcome to this module titled Introduction to the Domain Name System (DNS).

After completing this module you should:

*Understand the fundamentals of DNS and the important role it plays in the Internet’s architecture; and

*Understand how to use dig, a tool for querying

Domain Name System servers.

This module has the following topics:

Introduction;

DNS Architecture;

The 3 Roles in DNS;

Using DNS;

Testing DNS;

Understanding dig; and

DNS exercises.

Intro

The Domain Name System (DNS)[1] is a hierarchical distributed naming system for computers, services, or
any resource connected to the Internet or a private network.

 The DNS translates easily memorized domain names to the numerical IP addresses needed for the
purpose of locating computer services and devices worldwide.

 Computers use IP addresses to identify each other. This system works well, so why do we need to
identify hosts by name? There are two main reasons:
Firstly, giving a host a name makes it much easier for people to remember. Remembering to type
www.example.com is much easier than remembering 192.0.2.1

Secondly, computers may be moved between networks and their IP address would change. Having to
tell everyone that a website has moved to a new IP address would be a major task.

Secondly, computers may be moved between networks and their IP address would change. Having to
tell everyone that a website has moved to a new IP address would be a major task.

The Domain Name System provides a worldwide, distributed and resilient querying service that is a key
infrastructure of the Internet

In the ARPANET (Advanced Research Projects Agency Network) which was the predecessor of today’s
Internet, there was no distributed host name database. Translation of domain names to IP Addresses
was accomplished via a centrally maintained file, distributed to all hosts on the Internet, but this
solution had many disadvantages

Advantages:

*It was quick to implement; and

*It required no interaction with a third par

From the need for a better solution, the Domain Name System, or DNS, was born. The DNS brought
many advantages, which will be explained in more depth later.

A domain name consists of one or more parts that are separated by dots, such as afnog.org.

A domain name that has at least one IP Address associated with it is called a hostname. There aren't
many restrictions governing the structure of what would constitute a valid hostname and there are
many ways to express a hostname eg afnog.org or w-s.afnog.org

The two main restrictions are:

*Maximum of 255 characters in total (Defined in RFC 1034 and RFC 1035); and

*Maximum of 63 characters in each part (Defined in RFC 1034 and RFC 1035).

Initially, domain names could not start with a digit (eg 1example.com) or a hyphen and could not end in
a hyphen as mandated in RFC 952 but this was later superseded by RFC 1123 which allowed them.

*It did not scale well;

*It was a huge file;

*There was no guarantee of unique names;

*Different hosts could be holding different versions of the file; and

*One person (or organisation) had to be in charge of updating it.

DNS Architecture

All names used in the DNS are globally unique, and are administered in zones [2]. A zone is a part of a
domain for which administrative responsibility has been delegated to a single manager. These zones can
be seen as each part of a domain, such as

*root (.) which is the top-level DNS zone in the hierarchical namespace of the Domain Name System;
*org (which is a Top Level Domain or TLD);

*afnog.org (afnog is a sub-domain of .org) is a zone because its administrative control has been
delegated to another server; and

*ws.afnog.org (ws. is a sub-domain of afnog.org) could be a zone by itself if control of it was to be

delegated to another administrative authority).

A server can give away, or delegate, control of one or more of these zones to another server, placing it
in the tree underneath the original. For example:

org - first server

afnog.org - second server

ws.afnog.org - third server

This hierarchical structure is very similar to that found in filesystems, as shown in the diagram below.

The Three Roles in DNS

Resolver
All hosts need a resolver. It’s a piece of software which formats (or ‘resolves’) a DNS request from an
application into a UDP packet, sends it to the caching name server, and then decodes the answer.

The resolver needs to be configured with the IP Address of a caching name server in order to function.
This must be explicitly configured, though in most cases DHCP supplies the host with the location of a
caching name server. It is a good idea to provide the resolver with more than one caching name server,
to protect against failures

To tell FreeBSD which Caching Name Server(s) to use the resolver needs to be configured. This is done
by adding entries to the file located at /etc/resolv.conf as in the example below:

nameserver 196.200.219.200

nameserver 196.200.219.200
nameserver 196.200.223.1

The file /etc/resolv.conf is common to all Unix and Linux Operating systems.

Caching Name Server

The caching name server checks its database for the data it has stored so far for the answer to the
request from the resolver and returns it, if it's in the cache.

If the answer is NOT in the cache, it will search for an authoritative name server which has the
information, caches/stores the answer, and replies to the resolver.
Authoritative Name Server
An Authoritative Name Server is configured by the domain owner (or zone administrator) to answer
queries from the caching name servers.

They find the answer from their own data without needing to reference another source

Using DNS

When a web-browser makes a query through the Domain Name System with a domain name (such as
www.ws.afnog.org), the caching name server will reply in one of 4 ways:

*Positive;

*Negative;

*Server fail; and

*Refused

If the reply is positive, it means that the caching name server has found one or more 'resource records'
(RR) that are associated with the domain name.

 There are many different types of RRs, depending on the type of information.

 You can query for a specific type, by adding it to the request as you will find out later, or just by asking
to receive any and all RRs associated with the domain name.

Some commonly seen RRs are:

a (address): map hostname to IPv4 address;

aaaa (quad a): map a hostname to IPv6 address;

ptr (pointer): map IP address to hostname;

mx (mail exchanger): where to deliver mail for user@domain;

cname (canonical name): map alternative hostname to real hostname;

txt (text): any descriptive text; and

ns (name server
The easiest way to check if DNS is working is to type a domain name, such as www.google.com, into a
web browser and see if it loads.

 This is not a reliable test though, as the web browser could be caching the result.

 There is a tool specifically built for testing DNS called dig.

 Dig is a tool that makes DNS queries and displays the results. It is better suited to this task than other

common networking tools, such as nslookup and host, as it shows the raw data in full.

 Calling dig with just the domain name will default to query type address record or ‘A’ record

dig is installed by default in Ubuntu. In FreeBSD 9.2 and earlier versions, it is installed by default as
well. dig is a BIND utility and BIND (DNS software) needs to be installed for dig to work. In FreeBSD 10,
BIND is not installed by default and so dig is not available by default. Installing BIND in FreeBSD 10
would make dig available. Another utility called drill can be used in FreeBSD 10 and is available by
default. drill can be used exactly the same way as dig (eg $drill google.com) and you can also
install drill in Ubuntu. Both dig and drill are just tools to query DNS servers. We will use dig for this
course

$ dig afnog.org.

You can add the RR type you wish to the end of the query though:

$ dig afnog.org. mx

If you are testing a new cache, you may also command dig to use this and ignore the cache setup in the
resolver:

$ dig @192.168.0.100 afnog.org. mx

Hint:

Note that the domain name has a trailing dot every time;

$ dig afnog.org. mx

This is to ensure that no default domain is being added.

It is good practice to get into the habit of doing this when testing DNS.

There may come a time when you need to find the domain name or hostname [3] for a particular IP. For
example how would we know the hostname of the machine with the IP Address 196.216.2.34?
 

Fortunately, this is easy to do, simply follow these steps:

1.Make sure your IP address is in dotted-quad format

196.216.2.34

2.Reverse the order of the four parts:

34.2.216.196

3.Add .in-addr.arpa. to the end:

34.2.216.196.in-addr.arpa.

4.Request the ptr type of rr:

34.2.216.196.in-addr.arpa. ptr

Now you have built the parameter to pass to dig you would execute the command:

dig 34.2.216.196.in-addr.arpa. ptr

dig will respond with:

34.2.216.196.in-addr.arpa. 86400 IN PTR www.afnog.org

The same can also be achieved using dig –x (hyphen then x with no spaces) as follows:

$ dig –x 196.216.2.34

Hint:

PTR records can be thought of as the opposite of an A record where a host name is obtained from an IP
address.

Now you've got the basics of dig move onto the next screen for more dig output
STATUS

NOERROR: 0 or more RRs returned

NXDOMAIN: non-existent domain

SERVFAIL: cache could not locate answer

REFUSED: query not available on cache server

FLAGS:

qr: Query/Response (1 = Response)

aa: Authoritative answer (not from cache)

rd: Recursion Desired

ra: Recursion Available

ANSWER

The number of RRs in the response of dig

ANSWER SECTION

Displays the RRs requested. In this case there are two Resource Records as was indicated in the Answer
section above.

TTL3600

Each record has a Time To Live (TTL) which says how long the cache will keep it. This is the number of
seconds this answer can be kept and used.

Authority Section

Which name servers are authoritative for this domain.

Query Time

Simply the total time the query took to complete in milliseconds.

Server

Always check that the server that gave the response is the one you requested from as the request may
have gone to another server.

Querying DNS

Now you are going to use dig to practice querying the DNS on your FreeBSD Virtual Machine.

These are the exercises you will do:

*Query different types of RRs;

*Query using different caching name servers; and

*Reverse lookups to get the domain name or

*hostname from an IP addres

First check if your resolver is configured to use a caching DNS Server:

less /etc/resolv.conf

You should see something like the above.

 If that file is empty, you need to add a caching DNS Server that the resolver will use.
Now try using dig to query for the 'a' record of www.afnog.org:

dig www.afnog.org. a

Note down the TTL given in the response, you will need it later. Try querying for a different type of
record this time:

dig www.afnog.org. mx

Now try another query, type

dig www.afrinic.net. aaaa

Now try using a different caching name server. Google hosts an open DNS caching server at the IP
address 8.8.8.8, so you can use that

dig @8.8.8.8 www.afnog.org. a

Note down the TTL and compare it to the TTL you noted down from the first query.

Is it different? Run the command again and compare again.

 Why do you think there is a variation? Caching

There was a variation because the second time the command was run the answer was already cached.

Reverse DNS Lookups

*Remember to:

*Reverse the order;

*Add “.in-addr.arpa.” to the end; and

*Request a PTR record.

dig 6.2.216.196.in-addr.arpa. ptr

You should see that this IP points to www.afrinic.net.

Now try using dig’s built-in reverse lookup functionality.

 Using the “-x” flag is shorthand for the previous command:

dig -x 196.216.2.6

You should see roughly the same result as before.

This also works when querying a specific server:

dig @8.8.8.8 -x 196.216.2.6

You should see pretty much the same result again.

You have now completed these exercises using dig:

-Querying for different types of RR;

-Querying using different caching servers; and

-Reverse lookups.

DONAIME NAME SYSTEME

Objectives

*You should see pretty much the same result again.

*You have now completed these exercises using dig:

*Querying for different types of RR;

*Querying using different caching servers; and

*Reverse lookups.

How a Caching Name Server Works

A caching name server works like any other cache. [a] When it receives a query from the resolver, it
checks the data it has stored so far for the result.

If the same query has been dealt with already, then the result will be in the cache and can be easily sent
back.

If the query is new, or the Time To Live (TTL) for the requested Resource Record has expired, then the
result will not be in the cache

This means the caching name server has to consult other servers to find the result.

DNS is a distributed database, so parts of the DNS tree structure, (or zones) are held on different
servers. If a server holds a zone, then it is called authoritative for that particular zone.

The caching name server needs to locate the correct authoritative name server and get the result from
there.

It may have to ask other name servers first to locate the one it needs.

The caching name server needs to know which authoritative name server to ask. The best way of finding
this out is to follow the hierarchical tree structure, starting at the top.
 

If a name server receives a query for a delegated domain, for example, a .org server receiving a query
for afnog.org, it will return an NS record for the afnog.org Name Servers.

This is called a referral and provides the location of another name server lower down the tree.

To find a specific Resource Record, the caching name server begins at the root zone (denoted by a dot)
and then starts to query beginning from right to left of the domain. It starts with the TLD (Top Level
Domain) of the requested domain. For the address Resource Record (A Record) of the zone tiscali.co.uk,
it will begin at .uk.

When an authoritative name server receives a query for a sub-domain that has been delegated to
another server, (for example, a .uk authoritative name server receiving a query for tiscali.co.uk) it will
return a Name server record, or NS record for the .co.uk authoritative name server.

The answer from the .uk name server is called a referral, which refers a caching name server to an
authoritative name server that will have more information for the queried domain. Depending on the
number of sub-domains separated by dots (.) and whether each part of the subsequent sub-domain has
been delegated, referrals could occur for each sub-domain eg .co.uk authoritative name server will then
give a referral to tiscali.co.uk name servers. This process of receiving referrals is called recursion and is
performed by your caching name server until it receives the correct answer or reaches a non responsive
name server. This is why caching name servers are also called recursive name servers or Resolvers.

Firstly the resolver sends a query for a Resource Record to the caching name server. If the caching name
server does not have the answer in its cache it will begin recursion – querying for the answer from other
servers until it finds the answer or reaches a non responsive server.
The caching name server begins by querying the root authoritative name server. The root authoritative
name server returns a referral answer, referring the caching name server to another server of which
administrative control of the requested domain has been delegated to.

Using the information from the referral which will consist of an NS (Name server) record, the caching
name server requests the next authoritative name server in the tree for the specific Resource Record. If
this server is authoritative only for part of the domain, it will not have the answer for the requested
Resource Record and will also refer the caching name server to another authoritative name server

The caching name server will then use this second referral to query the authoritative name server it has
been directed to. This could be the server that is authoritative for the entire zone which will then
provide the answer for the Resource Record to the caching name server which then passes the response
to the resolver. This process will go on, and on, until the caching name server finds the desired Resource
Record or reaches a misconfigured or inactive server

DNS Server Software

To build your own caching name server, you can use DNS software such as BIND. BIND can be installed
by typing sudo pkg install bind910 on FreeBSD 10 onwards. This would install the configuration file
in /usr/local/etc/namedb but you can make a link to /etc/namedb for faster access. For the remainder
of this module, we will work with folder of /etc/namedb for BIND's files.

The caching name server needs to know where the authoritative name servers can be located in order
to begin the process of recursion. This is sometimes called seeding of the caching name server to allow it
to find the root! This information is stored in a seed file or hints file.

BIND software (and indeed all other caching DNS softwares available), have a seed file configured by
default once installed. For BIND installations on FreeBSD, the seed or hints file is located at
/etc/namedb/named.root and contains information of how to locate the 13 root servers of the Internet.

BIND’s default configuration /etc/namedb/named.conf file has a default configuration that includes the
location of this file as on the right

zone "." {

       type hint;

 file "named.root";

}
DNS Software:

BIND (Berkeley Internet Name Domain) from Internet Systems Consortium (ISC) is currently the most
widely used DNS Software on the Internet. It can work either as a caching DNS server or an authoritative
name server or perform both roles at the same time. The latter is discouraged.

Another DNS software you can use is Unbound from NLnet Labs, initially released in 2007. In FreeBSD
10, BIND is no longer available and is replaced by Unbound as the default caching DNS server. Other
popular open-source DNS softwares include, DJBDNS, NSD, KnotDNS and MaraDNS among others

In Ubuntu, BIND’s default folder containing configuration files is found at /etc/bind. The configuration

files differ slightly but it is not difficult to import and adapt the configuration from Ubuntu to FreeBSD
and vice versa since it’s a small matter of changing the location of some directories in the named.conf
file. Both BIND and Unbound work on Ubuntu and we will see how both work in this module

There are 13 root servers due to historical limitations on the UDP Protocol. Packets sent using UDP have
a maximum size of 512 bytes, and by giving a limit of 13 servers, all names and IP address details of
those servers can be transmitted in a single packet.

 
The DNS root server system is supervised by the Internet Assigned Numbers Authority which is a
department of

Internet Corporation for Assigned Names and Numbers (ICANN), but any changes to the root file
(containing names and IPs of the 13 root servers) must - as of 2014 - be approved by the US Department
of Commerce.

You can see the root servers in action using the dig command:

$ dig +trace www.afnog.org

When this command is used, you should receive output at the beginning similar to the example below

518400 IN NS i.root-servers.net

https://root-servers.org/

This list of root servers, to include in your /etc/namedb.named.root file, can be obtained from

http://www.internic.net/domain/named.cache

and if you are running a caching name server, it is advisable to check every 6 months or so for updates.

There are 13 root servers available and they are named a.root-servers.net through to m.root-

servers.net.

Furthermore there are several instances of the 13 root servers, as a measure to increase the reliability of
the service and reduce the load on the main 13 servers.

As of February 16th 2014, there were a total of 386 servers performing the functions of the 13 root
servers. This is made possible using technology called ANYCAST.[1]

This gives a very robust architecture, where several

servers share an IP address, and can be chosen based on how close they are. A caching name server
decides which root server is nearest based on response times
Creating a Robust and Reliable System

Distributed systems have many points of failure, so steps have to be taken to mitigate this.

Each domain, for example 'org', has two or more authoritative name servers to provide redundancy in
the event one or more of the name servers happens to fail or becomes unreachable. All the
authoritative name servers of a domain are equal and can be tried in any order until one gives an
answer. This also has the effect of sharing the load, which is particularly important for the root servers!

Another technique used to ease the load on the system is caching. You already know that caching name
servers store the results they receive from authoritative name servers, but all other information is also
cached.

This means NS(name server)[b] records from referrals are cached too. Caching reduces the load on
authoritative name servers.

This is especially important at the higher levels of the DNS hierarchy: root servers, Generic Top Level
Domain Servers (GTLD servers for.com and .net) and Country Code Top Level Domains (ccTLDs).

All intermediate information is cached as well as the final answer - so NS records from referrals are
cached too.
1.Let us assume that we want to lookup a record (smtp.example.com), having previously looked up
www.example.com. Firstly the resolver sends a query to the caching name server. The caching name
server must search for this particular Resource Record as it does not have information for
smtp.example.com as this record has not been queried for before

2. The caching name server however already knows the name servers responsible for example.com and
therefore will not bother going to the Root name servers to seek the name server responsible for
example.com. Therefore the referral process is skipped saving time and reducing the load on the Root
name servers.

3. Finally a query is sent to the authoritative name server responsible for example.com that does know
the answer for smtp.example.com. The caching name server remembers this from before (having this
information after looking for www.example.com) and so does not need to query anywhere else

Keeping the Cache Up-to-date

Caches only work for as long as the information they hold is correct. If they hold outdated information
they may give out the wrong answer.

 
Caching name servers need to know how long to keep data on resource records (RRs). If the result is
stored for too long the data provided could be out of date. If the result is stored for a very short period,
this would increase the load the authoritative servers higher in the hierarchy.

The owner of an authoritative server controls how long their data is held in cache. Each RR has a “time
to live”, or TTL, which dictates how long it can be held in cache, by giving the number of seconds of
validity.

;; ANSWER SECTION:

downloads.dns.gh.3600INCNAMEzoe.dns.gh.

Above is an RR, and shows a TTL of 3600. This is in seconds and means the cache will store this record
for 1 hour.

A SOA (Start of Authority) record,[c] dictates how long a negative answer can be cached

TIP:

It is good practice to set a fairly long TTL of 1 or 2 days ordinarily, and then reduce this to minutes a
couple of days before making a change to the data.

The TTL should then be increased back to its original after making the change.

The purpose of reducing the TTL before making a change to the resource records is so that the updates
you make to the records can reflect faster on the Internet than they normally would. So instead of
waiting for 2 days for the new resource records to be useable, the new records can be useable within
hours

https://tools.ietf.org/html/rfc1912

Potential DNS Issues

There are many problems that may occur when resolving names using DNS.

 These problems are all faults with the authoritative name servers, not caching name servers. Most of
these mistakes are easy to make but tricky to debug, especially when caching is involved

. DNS Issue 1
 

If a zone only has one Authoritative DNS server.

It would be a problem if that server is unreachable for any reason (power failure, network outage) as
that entire zone would not be available on the Internet. This is very bad because it would mean all
websites and email servers for a zone would not be identifiable, hence unreachable.

Solution

All zones should be setup with more than one authoritative server. In this case you would just move to
the next authoritative server if the first one timed out

DNS Issue 2

If all authoritative servers are unreachable, this is a

very substantial problem causing the query to fail. It is a

high priority to avoid this. 

Solution

Authoritative servers should be on different subnets, to mitigate the effects of a switch or router failure.
They should also have different power sources to improve redundancy in case of a power cut, and use
different Internet connections in case the connection fails. Authoritative servers should also be in
different geographic locations. One server can be in one part of the country, and the other in another
country altogether. http://tools.ietf.org/html/rfc2182

DNS Caching

As well as just testing DNS, dig can be used to debug and can give you the information
needed to fix problems.
 
To debug effectively, caching must be bypassed since all authoritative name servers for a
zone must be tried.
 
Recursion must also be bypassed to test every referral.
 
To do this you would type:
$ dig +norec @192.168.100.6 www.afnog.org. a

This tells dig:

-not to recursively search (dig +norec);

- to go straight to the name server at 192.168.100.6

(@ 192.169.100.6); and

-to look for the domain www.afnog.org with record

type 'a'. (www.afnog.org. a).

When running this command, you should first look at the

status that is output.
 
A successful query will return with a status of
NXDOMAIN, or NOERROR;
*NXDOMAIN, means that the query was
answered successfully, but there was no RRs for
that name; and
* NOERROR, means that the name queried for does exist
and it should be accompanied by one or more Resource
Record answers. However, if you requested for a
Resource Record type that does not exist, you will
receive zero answers. For example, if
www.example.com is an A record but you request for a
CNAME record that does not exist (eg $dig
www.example.comcname), you will receive a
 NOERROR status indicating that there is indeed
such a name but zero answers meaning there are no
Resource Records for the requested Resource Record
type.
Other statuses may indicate an error, as well as
receiving a "connection refused" message, or a timeout.
In summary, to debug the full process of resolving a domain you need to follow four steps:
 1. Use dig with the +norec option to query any root server for your chosen domain:
$ dig +norec @a.root-servers.net. www.afnog.org. a

2.Note all the NS records returned.

3.Use dig to query each NS record, in a similar way to how you did Step 1.

4.Repeat from Step 2 until all possible routes to the final answer have been checked.

Once you have got to the result to the query, you should check all the authoritative name
servers give a consistent result, as well as checking that they all have the “aa” flag in the
output.
 
This can be a very tedious process and can be prone to mistakes

DNS Caching and Debugging Exercises

In this next exercise section, you are going to make your FreeBSD Virtual Machine run its
own Caching DNS Server

You will use BIND, and then later use Unbound.

 
They are both freely available caching DNS software, and both work in FreeBSD.
You are going to perform the following tasks:

*Setting up a Caching Name Server;

*Testing the Caching Name Server;

*Using the Name Server on Your Host Machine; and

*Disable BIND and configure Unbound to be the

caching DNS server.

You will now setup a caching name server on your FreeBSD Virtual Machine.
 
You will need to configure BIND. BIND is a piece of open-source software that performs
DNS functions. It is installed by default in Ubuntu. For the Online Lab, it has been pre-
installed for you for FreeBSD 10. You can get instructions for how it was done from your
moderator.
 
We will work on the bash shell, and use sudo.
 
The first thing you need to do is navigate to the BIND directory
Setting up a Caching Name server

You will now setup a caching name server on your FreeBSD Virtual Machine.

You will need to configure BIND. BIND is a piece of open-source software that performs DNS functions. It
is installed by default in Ubuntu. For the Online Lab, it has been pre-installed for you for FreeBSD 10.
You can get instructions for how it was done from your moderator.

We will work on the bash shell, and use sudo.

The first thing you need to do is navigate to the BIND directory

$ cd /etc/namedb

Now, list the contents of the directory, and look for the main configuration file called named.conf.

Make a copy of this file in case something goes wrong!

$ sudo cp named.conf named.conf.backup

You should have been returned to the prompt, which means you have successfully copied
named.conf.
 
Next, you need to find out your IP address, so type:

$ ifconfig em0

When you have got to this line, you need to add your IP address to this option, like this
"listen-on {127.0.0.1; 192.168.100.6;};" (note that spaces, and semi-colons are important, so
check carefully). Also, please verify what your localhost IP address is if your are using the
online lab with $sudo ifconfig lo1.
listen-on {127.0.0.1; 192.168.100.6;};