DNS: ITS WORKING & USE OF DIFFERENT

DNS RECORDS
CNT Case Study

MAY 26, 2021

 DEPARTMENT OF INFORAMTION TECHNOLOGY
Academic Year: 2020-21 Class: TE SEM-II

Subject: COMPUTER NETWORK TECHNOLOGY (314450)

TOPIC :- DNS : Its Working And Uses Of Different DNS Records

Roll No Student Name Marks Sign

17 Piyush Dhamne
24 Kavita Jadhav
37 Prachi Matsagar
56 Tejaswini Phad

PO’s mapped : PO1, PO2, PO7, PO9, PO10, PO12

PSO’s mapped : PSO2
Signature of Subject In charge :

Rubrics for Marks distribution

Sr. Evaluation Max. Level 1 Level 2
Level 3
No Criteria Mark
s
Topic Knowledge
Less Satisfactory Clear
1 & Depth of 5
understanding understanding understanding
understanding

Less
Satisfactory
effectiveness of Effectiveness and
2 Presentation 10 effectiveness of the
the topic usefulness of topic
topic description
description

Poor report Excellent report

Report writing Average report writing
writing and Two writing and
3 and Timely 5 and One week Late
week Late submission
Submission submission
submission Within deadline
 DNS : ITS WORKING AND USES OF DIFFERENT
DNS RECORDS

Abstract :-
This paper proposes a DNS architecture and its working. Similarly also explains about
various types of DNS records, it’s uses and many more. The Domain Name System (DNS) is
a hierarchical database distributed around the world whose primary function is to translate
human-readable domain names to numerical IP addresses for network lookup and
communication. In recent years, so many devices are got connected to Internet so it becomes
very important to learn how it works and what is the architecture working behind it. A vast
improvement to its predecessor, DNS is well suited to its task of maintaining a relatively
efficient, distributed set of name to-IP mappings. You can think of a set of DNS records like a
business listing on Yelp. That listing will give you a bunch of useful information about a
business such as their location, hours, services offered, etc. All domains are required to have
at least a few essential DNS records for a user to be able to access their website using a Domain
name, and there are several optional records that serve additional purposes. Without DNS
services, the internet would be impossible to navigate since it is not possible to know every IP
address of every website. So the study of DNS and DNS records became more important in
21st century.

1. Introduction :-
Although TCP/IP uses IP addresses to locate and connect to hosts (computers and other
TCP/IP network devices), users typically prefer to use friendly names. For example, users
prefer the friendly name ftp.reskit.com, instead of its IP address, 172.16.23.55. The Domain
Name System (DNS), defined in RFCs 1034 and 1035, is used on the Internet to provide a
standard naming convention for locating IP-based computers.
On the Internet, before the implementation of DNS, the use of names to locate resources
on TCP/IP networks was supported by a file called Hosts. Network administrators entered
names and IP addresses into Hosts, and computers used the file for name resolution. Both the
Hosts file and DNS use a namespace. A namespace is a grouping in which names can be used
to symbolically represent another type of information, such as an IP address, and in which
specific rules are established that determine how names can be created and used. Some
namespaces, such as DNS, are hierarchically structured and provide rules that allow for the
namespace to be divided into subsets of names for distributing and delegating parts of the
namespace. Other namespaces, such as the Hosts namespace cannot be divided and must be
distributed in their entirety.
Because of this, using the Hosts file posed a problem for network administrators. As
the number of computers and users on the Internet grew, the task of updating and distributing
the Hosts file became unmanageable. DNS replaces the Hosts file with a distributed database
that implements a hierarchical naming system. This naming system allows for growth on the
Internet and the creation of names that are unique throughout the Internet and private TCP/IP-
based intranets. Without DNS services, the internet would be impossible to navigate since it is
not possible to know every IP address of every website.
Telecoms, ISP’s and special service providers like Google, Yahoo, Baidu, Bing and
many more have massive, powerful DNS servers in order to provide their services. This system
is massive world wide databaseof all domain names and IP address associated with all those
Domain names . This allows users to type in domain name and be directed to the website while
translating the name into an IP address for the computer to understand.

The Domain Name System (DNS) is the phonebook of the Internet. Humans access information
online through domain names, like nytimes.com or espn.com. Web browsers interact through
Internet Protocol (IP) addresses. DNS translates domain names to IP Addresses so browsers
can load Internet resources.

Each device connected to the Internet has a unique IP address which other machines use to find
the device. DNS servers eliminate the need for humans to memorize IP addresses such as
192.168.1.1 (in IPv4), or more complex newer alphanumeric IP addresses such as
2400:cb00:2048:1::c629:d7a2 (in IPv6).

The DNS protocol was developed by Paul Mockapetris, first codified in IETF
documents RFC 882 and RFC 883 and later superseded by RFC’s 1034 and 1035. Clients of a
DNS server interact with it supplying queries of various types, with the server providing the
answers. Communication between a DNS client and server takes place at either the UDP or
TCP layers of the Internet protocol stack.

The distinguishing feature of DNS is its hierarchical and distributed nature. Because it
is hierarchical, a single DNS server may not and need not know the answer to a client query.
If it does not, it can query another DNS server at a higher level in the Internet domain name
space for further information. This process may be repeated up to the root server, with further
information then propagating back down to the original querying server.

The system’s distributed nature means that there is no central DNS server. Hundreds of
thousands of implementations of DNS are all running at once, and because they all use the
same protocols to communicate they all function correctly. Simple implementations of DNS
may perform solely as authoritative name servers, responsible only for managing the IP
addresses associated with a particular zone. To reduce the load on the root zone servers and to
improve performance of applications that rely on nearby DNS servers, more complex
implementations of DNS may cache query answers as well as fully implement the recursive
query protocol described previously.

The most popular implementation of DNS is the Berkeley Internet Name Domain
server, or BIND. Originally written in 1984, it has been ported to a number of systems and
compilers, and has been distributed as free software since its inception. According to the
Wikipedia entry on DNS, it is the dominant name service software on the Internet.

1.1 Goal :-

Goal of this thesis is to learn about the Domain Name System in details. The main
purpose is to study DNS architecture, its working. In this rapid world, where every devide is
connected Internet it is important learn about how human can access information online
through Domain names. Also to learn about DNS securities, DNS root zones, types of DNS
records, DNS server type And many more. Another goal is to know the importance of DNS
record types and its uses.

1.2 Structure of Thesis :-

Chapter 2 : Domain Name System: These chapter describes everything about DNS like
information about DNS, history, Domain name details , types of domain name. You will get
idea about domain.

2.1. What is dns

2.2. A brief history of dns
2.3. What is domain name
2.4. How is domain name different from a website and web hosting?
2.5. Different types of domain names

Chapter 3 : DNS hierarchy and working: In these chapter you will understand the detail
hierarchy used in DNS and how it works .woking of DNS is explained here in very easy way
to understand. Also different types of DNS queries, DNS services and DNS zones are explained
here.

3.1. Dns hierarchy

3.2. How dns works
3.3. Types of dns services
3.4. Dns queries
3.5. Dns zones

Chapter 4 : DNS Records and its types : These chapter gives detail knowledge about DNS
records like what is Dns records ,why they used and what are their uses. These chapter will
help you to understand which record you can use in a particular situation.

4.1 Types of record

2. Domain Name System (DNS) :-

2.1 What is DNS :-

The Domain Name System (DNS) is the phonebook of the Internet. Humans access
information online through domain names, like nytimes.com or espn.com. Web browsers
interact through Internet Protocol (IP) addresses. DNS translates domain names to IP
addesses so browsers can load Internet resources.

Each device connected to the Internet has a unique IP address which other machines
use to find the device. DNS servers eliminate the need for humans to memorize IP addresses
such as 192.168.1.1 (in IPv4), or more complex newer alphanumeric IP addresses such as
2400:cb00:2048:1::c629:d7a2 (in IPv6).

All computers on the Internet, from your smart phone or laptop to the servers that serve
content for massive retail websites, find and communicate with one another by using numbers.
These numbers are known as IP addresses. When you open a web browser and go to a website,
you don't have to remember and enter a long number. Instead, you can enter a domain name like
example.com and still end up in the right place.

A DNS service such as Amazon Route 53 is a globally distributed service that translates
human readable names like www.example.com into the numeric IP addresses like 192.0.2.1
that computers use to connect to each other. The Internet’s DNS system works much like a
phone book by managing the mapping between names and numbers. DNS servers translate
requests for names into IP addresses, controlling which server an end user will reach when they
type a domain name into their web browser. These requests are called queries.

At its most basic, DNS is a directory of names that match with numbers. The numbers,
in this case are IP addresses, which computers use to communicate with each other. Most
descriptions of DNS use the analogy of a phone book, which is fine for people over the age of
30 who know what a phone book is.

2.2 A Brief History of DNS :-

When the internet was very, very small, it was easier for people to correspond specific
IP addresses with specific computers, but that didn’t last for long as more devices and people
joined the growing network. It's still possible to type a specific IP address into a browser to
reach a website, but then, as now, people wanted an address made up of easy-to-remember
words, of the sort that we would recognize as a domain name (like networkworld.com) today.
In the 1970s and early '80s, those names and addresses were assigned by one person —
Elizabeth Feinler at Stanford – who maintained a master list of every Internet-connected
computer in a text file called HOSTS.TXT.
 This was obviously an untenable situation as the Internet grew, not least because Feinler
only handled requests before 6 p.m. California time, and took time off for Christmas. In 1983,
Paul Mockapetris, a researcher at USC, was tasked with coming up with a compromise among
multiple suggestions for dealing with the problem. He basically ignored them all and developed
his own system, which he dubbed DNS. While it's obviously changed quite a bit since then, at
a fundamental level it still works the same way it did nearly 40 years ago.

2.3 What Is Domain Name :-

Domain name is the address of your website that people type in the browser URL bar
to visit your website. In simple terms, if your website was a house, then your domain name will
be its address. A more detailed explanation:

The Internet is a giant network of computers connected to each other through a global
network of cables. Each computer on this network can communicate with other computers. To
identify them, each computer is assigned an IP address. It is a series of numbers that identify a
particular computer on the internet. A typical IP address looks like this: 66.249.66.1

Now an IP address like this is quite difficult to remember. Imagine if you had to use
such numbers to visit your favorite websites. Domain names were invented to solve this
problem. Now if you want to visit a website, then you don’t need to enter a long string of
numbers. Instead, you can visit it by typing an easy to remember domain name in your
browser’s address bar. For example, wpbeginner.com.

2.4 How is Domain Name Different from a Website and Web Hosting?

A website is made up of files like HTML pages, website builder software, images, and
more. If the domain name is the web address of your website, then web hosting is the home
where your website lives.
This is the actual computer where your website’s files are stored. Such computers are
called servers and they are offered as a service by hosting companies.
To create your website, you need both domain name and web hosting.
However, it’s important to remember that they are two separate services, and you can
buy them from two different companies.
Now you may be wondering, how would it work if you bought them from two separate
companies?
You just need to edit your domain name settings and enter the Name Server information
provided by your hosting company. Name Server information defines where to send user
requests for your domain name.
We recommend getting both your domain name and hosting from the same company.
This allows you to easily manage them under the same account.
For more details, see our guide on the difference between domain name and web
hosting.
2.5 Different Types of Domain Names :-

Domain names are available in many different extensions. The most popular one
is .com. There are many other options like .org, .net, .tv, .info, .io, and more. However we
always recommend Domain names are available in many different extensions. The most
popular one is .com. There are many other options like .org, .net, .tv, .info, .io, and more.
However we always recommend using .com domain extension.

Let’s take a more detailed look at different types of domain names available.

2.5.1 Top Level Domain – TLD :-

Top level domain or TLD are generic domain extensions that are listed at the highest
level in the domain name system. There are hundreds of TLDs, but the most popular ones are
.com, .org, and .net. Other TLDs are lesser known and we don’t recommend using them. For
example, .biz, .club, .info, .agency, and many more.

2.5.2 Country Code Top Level Domain – ccTLD :-

Country code top-level domain or ccTLD are country specific domain names which
end with country code extension like .uk for the United Kingdom, .de for Germany, .in for
India. They are used by websites that want to target audiences in a specific country.

2.5.3 Sponsored Top Level Domain – sTLD :-

Sponsored top-level domain or sTLD is a category of TLDs that has a sponsor

representing a specific community served by the domain extension.

For example, .edu for education-related organizations, .gov for the United States government,
.mil for the United States military, and more..

2.5.4 Second-Level Domains :-

Second-level domains are below the TLDs highlighted above in terms of hierarchy.
This doesn’t mean they’re any less authoritative, or valuable. Rather, this describes the second
piece of the domain name, such as the ‘hostgator’ in ‘www.hostgator.com.’

There are also country code second-level domains, which might look like the following:

.co.uk – Companies in the United Kingdom commonly use this.

.gov.uk – This is used by government agencies throughout the United Kingdom.

.gov.au – Government agencies across Australia use this.

2.5.5. Third Level Domains :-

Third level domains are below second-level domains in the domain name hierarchy.
They aren’t a full domain name in and of themselves, but merely a portion of a domain name.

For example, in the domain name “www.hostgator.com,” ‘www’ would be the third level
domain. Or, if you’re using a subdomain to build an additional section of your site, this would
be a third-level domain as well.
3. DNS Hierarchy and working :-

3.1 DNS Hierarchy :-

Namespace in DNS is organized in a hierarchical tree structure, with the root DNS
servers at the top of the tree. These root servers contain information about the DNS servers at
the next level down the hierarchy, which include the Top Level Domain (TLD) DNS servers
for .com, .net, .org, and many other top-level domains. Going down the hierarchy another level
we find DNS servers for individual corporations, networks, and organizations. It is these
systems that we concern ourselves with for the majority of this discussion, although the points
we mention are general observations about the architecture of the domain name system and
therefore apply at every level. At these servers we find information about individual hosts as
well as potentially lower-level DNS - 3 - servers that may perform the same delegated function
for sub-domains of these organizations (e.g., a host www may exist in the sub-domain
accounting.xyzcorp.com).

The process by which client programs search the DNS hierarchy for information about
a given host is referred to as resolving. In our example, DNS will be used by a client application
(a web browser) in the userspace.org domain to resolve the www.xyzcorp.com to an IP address
(e.g. 192.168.5.250), which it can then use to contact the server and retrieve the requested web
pages. We should note that the client system first checks a local cache to see if it already knows
the IP address associated with this name. In our case, it does not, so the system formulates a
DNS request to its configured (usually local) DNS server, asking for the IP address associated
with www.xyzcorp.com.

Since our local name server is not authoritative for the domain in question and does not
have this information already cached from a previous lookup, it will resolve the name
recursively. This is done by systematically querying various servers in the DNS hierarchy to
find the information requested by the client. In this case, our local server would end up talking
to the root server (located using root hints), which would point us to the TLD server for the
“.com” domain, which would in turn point us to a name server authoritative for the
xyzcorp.com domain.

Zone information for a particular domain is always stored on a primary name server for
that domain. A zone may also have additional name servers, called secondary name servers,
which maintain a mirror of this information for redundancy (and efficiency), which are also
authoritative. In this case it doesn’t really matter which of these name servers is selected, as
long as the server is authoritative for the zone data, and we shall say that the selected name
server here is ns.xyzcorp.com. Finally, ns.xyzcorp.com sends ns.userspace.org the information
we have requested about www and ns.userspace.org can then pass this on by sending a reply
to our client application. At this stage, our client application can access the website by its
numerical IP address, transparently to the user.
3.2 How DNS Works :-

The process of DNS resolution involves converting a hostname (such as

www.example.com) into a computer-friendly IP address (such as 192.168.1.1). An IP address
is given to each device on the Internet, and that address is necessary to find the appropriate
Internet device - like a street address is used to find a particular home. When a user wants to
load a webpage, a translation must occur between what a user types into their web browser
(example.com) and the machine-friendly address necessary to locate the example.com
webpage.
In order to understand the process behind the DNS resolution, it’s important to learn about the
different hardware components a DNS query must pass between. For the web browser, the
DNS lookup occurs “ behind the scenes” and requires no interaction from the user’s computer
apart from the initial request.

Step 1: Requesting Website Information

Let's visit a website by typing a domain name into a web browser. Our computer will
start resolving the hostname, such as www.liquidweb.com. Our computer will then look for the
IP address associated with the domain name in its local DNS cache. This cache stores this
information that our computer has recently saved. If it is present locally, then the website will
be displayed. If our computer does not have the information, it will perform a DNS query to
retrieve the correct information.

Step 2: Contact the Recursive DNS Servers

If the information is not in your computer’s local cache, then it will query another
server. Recursive DNS servers have their local cache, much like your computer. Many ISP’s
use the same recursive DNS servers, it's possible that common domain name is already in its
cache. If the domain is cached, the query will end here and the website displayed to the user.
Step 3: Query the Authoritative DNS Servers
If a recursive DNS server or servers do not have information stored in its cache memory,
it looks elsewhere. The query then continues up the chain of authoritative DNS servers. The
search will continue until it finds a nameserver for the domain. These authoritative name
servers are responsible for storing these records for their respective domain names.

Step 4: Access the DNS Record

To locate the IP address for liquidweb.com, we will query the authoritative name server
for the address record (A record). A Recursive DNS server accesses the A record for
liquidweb.com from the authoritative name servers. It then stores the record in its local cache.
If another query requests the A record for liquidweb.com, the recursive server will have the
answer. All DNS records have a time-to-live value, which shows when a record will expire.
After some time has passed, the recursive DNS server will ask for an updated copy of the
records.

Step 5: Final DNS Step

The Recursive DNS server has the information and returns the A record to your
computer. Our computer then stores the record in its local cache. It reads the IP address from
the DNS record and passed it to our browser. The web browser will connect to the web server
associated with the A records IP and display the website.
The entire lookup process, from start to finish, takes only milliseconds to complete. For a better
understanding, let’s break down the components that make up the lookup process.
3.3 Types Of DNS Services :-

Both concepts refer to servers (groups of servers) that are integral to the DNS
infrastructure, but each performs a different role and lives in different locations inside the
pipeline of a DNS query. One way to think about the difference is the recursive resolver is at
the beginning of the DNS query and the authoritative nameserver is at the end.

3.3.1 Recursive DNS Server :-

The recursive resolver is the computer that responds to a recursive request from a client
and takes the time to track down the DNS record. It does this by making a series of requests
until it reaches the authoritative DNS nameserver for the requested record (or times out or
returns an error if no record is found). Luckily, recursive DNS resolvers do not always need to
make multiple requests in order to track down the records needed to respond to a
client; caching is a data persistence process that helps short-circuit the necessary requests by
serving the requested resource record earlier in the DNS lookup.

3.3.2 Authoritative DNS server :-

Put simply, an authoritative DNS server is a server that actually holds, and is
responsible for, DNS resource records. This is the server at the bottom of the DNS lookup chain
that will respond with the queried resource record, ultimately allowing the web browser making
the request to reach the IP address needed to access a website or other web resources. An
authoritative nameserver can satisfy queries from its own data without needing to query another
source, as it is the final source of truth for certain DNS records.
There is a key difference between many DNS services and the one that Cloudflare
provides. Different DNS recursive resolvers such as Google DNS, OpenDNS, and providers
like Comcast all maintain data center installations of DNS recursive resolvers. These resolvers
allow for quick and easy queries through optimized clusters of DNS-optimized computer
systems, but they are fundamentally different than the nameservers hosted by Cloudflare.
 Cloudflare maintains infrastructure-level nameservers that are integral to the
functioning of the Internet. One key example is the f-root server network which Cloudflare is
partially responsible for hosting. The F-root is one of the root level DNS nameserver
infrastructure components responsible for the billions of Internet requests per day. Our Anycast
network puts us in a unique position to handle large volumes of DNS traffic without service
interruption.

3.4 DNS Queries :-

In a typical DNS lookup three types of queries occur. By using a combination of these queries,
an optimized process for DNS resolution can result in a reduction of distance traveled. In an
ideal situation cached record data will be available, allowing a DNS name server to return a
non-recursive query.

3 types of DNS queries:

3.4.1 Recursive query –

In a recursive query, a DNS client requires that a DNS server (typically a DNS recursive
resolver) will respond to the client with either the requested resource record or an error message
if the resolver can't find the record.

3.4.2 Iterative query –

In this situation the DNS client will allow a DNS server to return the best answer it can. If the
queried DNS server does not have a match for the query name, it will return a referral to a DNS
server authoritative for a lower level of the domain namespace. The DNS client will then make
a query to the referral address. This process continues with additional DNS servers down the
query chain until either an error or timeout occurs.

3.4.3 Non-recursive query –

Typically this will occur when a DNS resolver client queries a DNS server for a record that it
has access to either because it's authoritative for the record or the record exists inside of its
cache. Typically, a DNS server will cache DNS records to prevent additional bandwidth
consumption and load on upstream servers.

3.5 DNS ZONES :-

The DNS is broken up into many different zones. These zones differentiate between
distinctly managed areas in the DNS namespace. A DNS zone is a portion of the DNS
namespace that is managed by a specific organization or administrator. A DNS zone is an
administrative space which allows for more granular control of DNS components, such as
authoritative nameservers. The domain name space is a hierarchical tree, with the DNS root
domain at the top. A DNS zone starts at a domain within the tree and can also extend down
into subdomains so that multiple subdomains can be managed by one entity.

A common mistake is to associate a DNS zone with a domain name or a single DNS server. In
fact, a DNS zone can contain multiple subdomains and multiple zones can exist on the same
server. DNS zones are not necessarily physically separated from one another, zones are strictly
used for delegating control.

For example, imagine a hypothetical zone for the cloudflare.com domain and three of its
subdomains: support.cloudflare.com, community.cloudflare.com, and blog.cloudflare.com.
Suppose the blog is a robust, independent site that needs separate administration, but the
support and community pages are more closely associated with cloudflare.com and can be
managed in the same zone as the primary domain. In this case, cloudflare.com as well as the
support and community sites would all be in one zone, while blog.cloudflare.com would exist
in its own zone.

All of the information for a zone is stored in what’s called a DNS zone file, which is the key to
understanding how a DNS zone operates.
4. DNS Records :-
DNS records (aka zone files) are instructions that live in authoritative DNS servers and
provide information about a domain including what IP address is associated with that domain
and how to handle requests for that domain. These records consist of a series of text files written
in what is known as DNS syntax. DNS syntax is just a string of characters used as commands
that tell the DNS server what to do. All DNS records also have a ‘TTL’, which stands for time-
to-live, and indicates how often a DNS server will refresh that record.

You can think of a set of DNS records like a business listing on Yelp. That listing will
give you a bunch of useful information about a business such as their location, hours, services
offered, etc. All domains are required to have at least a few essential DNS records for a user to
be able to access their website using a domain name, and there are several optional records that
serve additional purposes.

Here are the most common types of DNS record :-

• A record - The record that holds the IP address of a domain.

• CNAME record - Forwards one domain or subdomain to another domain, does NOT
provide an IP address.
• MX record - Directs mail to an email server.
• TXT record - Lets an admin store text notes in the record.
• NS record - Stores the name server for a DNS entry.
• SOA record - Stores admin information about a domain.
• SRV record - Specifies a port for specific services.
• PTR record - Provides a domain name in reverse-lookups.

4.1 A RECORD :-
The ‘A’ stands for ‘address’ and this is the most fundamental type of DNS record: it
indicates the IP address of a given domain. For example, if you pull the DNS records, the A
record currently returns an IP address of: 104.17.210.9. A records only hold IPv4 addresses. If
a website has an IPv6 address, it will instead use an ‘AAAA’ record.
Here is an example of an A record:
example.com record type: value: TTL
@ A 192.0.2.1 14400

The ‘@’ symbol in this example indicates that this is a record for the root domain, and the
‘14400’ value is the TTL (time to live), listed in seconds. The default TTL for A records is
14400 seconds. This means that if an A record gets updated, it takes 240 minutes (14400
seconds) to take effect.
The vast majority of websites only have one A record, but it is possible to have several. Some
higher profile websites will have several different A records as part of a technique called round
robin load balancing, which can distribute request traffic to one of several IP addresses, each
hosting identical content.

4.1.1 When are DNS A records used?

The most common usage of A records is IP address lookups: matching a domain name (like
'cloudflare.com') to an IPv4 address. This enables a user's device to connect with and load a
website, without the user memorizing and typing in the actual IP address. The user's web
browser automatically carries this out by sending a query to a DNS resolver.
DNS A records are also used for operating a Domain Name System-based Blackhole List
(DNSBL). DNSBLs can help mail servers identify and block email messages from known
spammer domains.

4.2 CNAME RECORD :-

The ‘canonical name’ (CNAME) record is used in lieu of an A record, when
a domain or subdomain is an alias of another domain. All CNAME records must point to a
domain, never to an IP address. Imagine a scavenger hunt where each clue points to another
clue, and the final clue points to the treasure. A domain with a CNAME record is like a clue
that can point you to another clue (another domain with a CNAME record) or to the treasure (a
domain with an A record).
For example, suppose blog.example.com has a CNAME record with a value of
‘example.com’ (without the ‘blog’). This means when a DNS server hits the DNS records for
blog.example.com, it actually triggers another DNS lookup to example.com, returning
example.com’s IP address via its A record. In this case we would say that example.com is the
canonical name (or true name) of blog.example.com.
Oftentimes, when sites have subdomains such as blog.example.com or
shop.example.com, those subdomains will have CNAME records that point to a root domain
(example.com). This way if the IP address of the host changes, only the DNS A record for the
root domain needs to be updated and all the CNAME records will follow along with whatever
changes are made to the root.
A frequent misconception is that a CNAME record must always resolve to the same
website as the domain it points to, but this is not the case. The CNAME record only points the
client to the same IP address as the root domain. Once the client hits that IP address, the web
server will still handle the URL accordingly. So for instance, blog.example.com might have a
CNAME that points to example.com, directing the client to example.com’s IP address. But
when the client actually connects to that IP address, the web server will look at the URL, see
that it is blog.example.com, and deliver the blog page rather than the home page.

Example of a CNAME record:

BLOG.EXAMPLE.COM RECORD TYPE : VALUE : TTL

@ CNAME Is an alias of 32600
example.com
In this example you can see that blog.example.com points to example.com, and assuming it is
based on our example A record we know that it will eventually resolve to the IP address
192.0.2.1.

4.2.1 Can a CNAME record point to another CNAME record?

Pointing a CNAME record to another CNAME record is inefficient because it requires multiple
DNS lookups before the domain can be loaded — which slows down the user experience —
but it is possible. For example, blog.example.com could have a CNAME record that pointed to
www.example.com's CNAME record, which then pointed to example.com's A record.

CNAME for blog.example.com:

blog.example.com record type: value: TTL

@ CNAME is an alias of www.example.com 32600

Which points to a CNAME for www.example.com:

www.example.com record type: value: TTL

@ CNAME is an alias of example.com 32600

This configuration adds an extra step to the DNS lookup process and should be avoided if
possible. Instead, the CNAME records for both blog.example.com and www.example.com
should point directly to example.com.

4.2.2 What restrictions are there on using CNAME records?

MX and NS records cannot point to a CNAME record; they have to point to an A record
(for IPv4) or an AAAA record (for IPv6). An MX record is a mail exchange record that directs
email to a mail server. An NS record is a 'name server' record and indicates which DNS server
is authoritative for that domain.
4.3 MX Record :-
A DNS 'mail exchange' (MX) record directs email to a mail server. The MX record
indicates how email messages should be routed in accordance with the Simple Mail Transfer
Protocol (SMTP, the standard protocol for all email). Like CNAME records, an MX record
must always point to another domain.

Example of an MX record:

example.com record type: priority: value: TTL

@ MX 10 mailhost1.example.com 45000
@ MX 20 mailhost2.example.com 45000

The 'priority' numbers before the domains for these MX records indicate preference; the lower
'priority' value is preferred. The server will always try mailhost1 first because 10 is lower than
20. In the result of a message send failure, the server will default to mailhost2.
The email service could also configure this MX record so that both servers have equal priority
and receive an equal amount of mail:

example.com record type: priority: value: TTL

@ MX 10 mailhost1.example.com 45000
@ MX 10 mailhost2.example.com 45000

This configuration enables the email provider to equally balance the load between the two
servers.

4.3.1 What is the process of querying an MX record?

Message transfer agent (MTA) software is responsible for querying MX records. When a user
sends an email, the MTA sends a DNS query to identify the mail servers for the email
recipients. The MTA establishes an SMTP connection with those mail servers, starting with
the prioritized domains (in the first example above, mailhost1).

4.3.2 What is a backup MX record?

A backup MX record is just an MX record for a mail server with a higher 'priority' value (which
means a lower priority), so that under normal circumstances mail will go to the more prioritized
servers. In the first example above, mailhost2 would be the 'backup' server because email traffic
will be handled by mailhost1 as long as it is up and running.
4.3.3 Can MX records point to a CNAME?

A CNAME record is used for referencing a domain's alias instead of its actual name. CNAME
records typically point to an A record (in IPv4) or AAAA record (in IPv6) for that domain.
However, MX records have to point directly to a server's A record or AAAA record. Pointing
to a CNAME is forbidden by the RFC documents that define how MX records function.

4.4 TXT Record :-

The DNS ‘text’ (TXT) record lets a domain administrator enter text into the Domain
Name System (DNS). The TXT record was originally intended as a place for human-readable
notes. However, now it is also possible to put some machine-readable data into TXT records.
One domain can have many TXT records.

Example of a TXT record:

Example.com Record type: Value: TTL

@ TXT This is an awesome 32600
domain! Definitely
not spammy

Today, two of the most important uses for DNS TXT records are email spam prevention and
domain ownership verification, although TXT records were not designed for these uses
originally.

4.4.1 What kind of data can go in a TXT record?

The original RFC only indicates that 'text strings' go in the 'value' field of a TXT record.
This could be any text that an administrator wants to associate with their domain. Most DNS
servers will put a limit on how big TXT records can be and how many records they can store,
so administrators cannot use TXT records for large amounts of data.

4.4.2 What is the official format for storing data in a TXT record?

In 1993, the Internet Engineering Task Force (IETF) defined a format for storing attributes and
their corresponding values within the 'value' field of TXT records. The format was simply the
attribute and the value contained within quotation marks (") and separated by an equal sign (=),
such as:

"attribute=value"

RFC 1464, the 1993 document that defines this format, includes these examples:
 Sam.widgets.com Record type: Value :
@ TXT “favorite drink=orange
juice”

However, this definition was considered experimental, and in practice it is not often
adopted. Some DNS administrators follow their own formats within TXT records, if they make
use of TXT records at all. TXT records may also be formatted in a specific way for certain uses
described below — for instance, DMARC policies have to be formatted in a standardized way.

4.4.3 How do TXT records help prevent email spam?

Spammers often try to fake or forge the domains from which they send their email
messages. TXT records are a key component of several different email authentication methods
that help an email server determine if a message is from a trusted source.

Common email authentication methods include Domain Keys Identified Mail (DKIM),
Sender Policy Framework (SPF), and Domain-based Message Authentication, Reporting &
Conformance (DMARC). By configuring these records, domain operators can make it more
difficult for spammers to spoof their domains and can track attempts to do so.

1. SPF records: SPF TXT records list all the servers that are authorized to send email
messages from a domain.
2. DKIM records: DKIM works by digitally signing each email using a public-private
key pair. This helps verify that the email is actually from the domain it claims to be
from. The public key is hosted in a TXT record associated with the domain.
3. DMARC records: DMARC TXT records can be set up once DKIM and SPF are
configured. A DMARC TXT record should be stored under the title
_dmarc.example.com. with 'example.com' replaced with the actual domain name. The
'value' of the record is the domain's DMARC policy .

4.5 NS Server :-

NS stands for ‘nameserver,’ and the nameserver record indicates which DNS server is
authoritative for that domain (i.e. which server contains the actual DNS records). Basically, NS
records tell the Internet where to go to find out a domain's IP address. A domain often has
multiple NS records which can indicate primary and backup nameservers for that domain.
Without properly configured NS records, users will be unable to load a website or application.

Here is an example of an NS record:

example.com record type: value: TTL

@ NS ns1.exampleserver.com 21600
Note that NS records can never point to a canonical name (CNAME) record.

4.5.1 What is a nameserver?

A nameserver is a type of DNS server. It is the server that stores all DNS records for a
domain, including A records, MX records, or CNAME records.

Almost all domains rely on multiple nameservers to increase reliability: if one

nameserver goes down or is unavailable, DNS queries can go to another one. Typically there
is one primary nameserver and several secondary nameservers, which store exact copies of the
DNS records in the primary server. Updating the primary nameserver will trigger an update of
the secondary nameservers as well.

When multiple nameservers are used (as in most cases), NS records should list more
than one server. Learn more about DNS servers.

4.5.2 When should NS records be updated or changed?

Domain administrators should update their NS records when they need to change their
domain's nameservers. For instance, some cloud providers provide nameservers and require
their customers to point to them.

Admins may also wish to update their NS records if they want a subdomain to use
different nameservers. In the example above, the nameserver for example.com is
ns1.exampleserver.com. If the example.com admin wanted blog.example.com to resolve via a
ns2.exampleserver.com instead, they could set this up by updating the NS record.

When NS records are updated, it may take several hours for the changes to be replicated
throughout the DNS.

4.6 SOA record :-

The DNS ‘start of authority’ (SOA) record stores important information about a domain
or zone such as the email address of the administrator, when the domain was last updated, and
how long the server should wait between refreshes.

All DNS zones need an SOA record in order to conform to IETF standards. SOA records are
also important for zone transfers.
Example of an SOA record :

name example.com

record type SOA

MNAME ns.primaryserver.com

RNAME admin.example.com

SERIAL 1111111111

REFRESH 86400

RETRY 7200

EXPIRE 4000000

TTL 11200

The 'RNAME' value here represents the administrator's email address, which can be
confusing because it is missing the ‘@’ sign, but in an SOA record admin.example.com is the
equivalent of admin@example.com.

4.6.1 What is a zone serial number?

In the DNS, a 'zone' is an area of control over namespace. A zone can include a single
domain name, one domain and many subdomains, or many domain names. In some cases, 'zone'
is essentially equivalent with 'domain,' but this is not always true.

A zone serial number is a version number for the SOA record. In the example above,
the serial number is listed next to 'SERIAL.' When the serial number changes in a zone file,
this alerts secondary nameservers that they should update their copies of the zone file via a
zone transfer.

4.6.2 What are the other parts of an SOA record?

MNAME: This is the name of the primary nameserver for the zone. Secondary servers that
maintain duplicates of the zone's DNS records receive updates to the zone from this primary
server.

REFRESH: The length of time (in seconds) secondary servers should wait before asking
primary servers for the SOA record to see if it has been updated.

RETRY: The length of time a server should wait for asking an unresponsive primary
nameserver for an update again.
EXPIRE: If a secondary server does not get a response from the primary server for this amount
of time, it should stop responding to queries for the zone.

4.6.3 What is a zone transfer?

A DNS zone transfer is the process of sending DNS record data from a primary
nameserver to a secondary nameserver. The SOA record is transferred first. The serial number
tells the secondary server if its version needs to be updated. Zone transfers take place over the
TCP protocol.

4.7 SRV Record :-

The DNS ‘service’ (SRV) record specifies a host and port for specific services such as
voice over IP (VoIP), instant messaging, and so on. Most other DNS records only specify a
server or an IP address, but SRV records include a port at that IP address as well. Some Internet
protocols require the use of SRV records in order to function.

4.7.1 What is a port?

In networking, ports are virtual places that designate what processes network traffic
goes to within a computer. Ports allow computers to easily differentiate between different kinds
of traffic: VoIP streams go to a different port than email messages, for instance, even though
both reach a computer over the same Internet connection. Much like IP addresses, all ports are
assigned a number.

Certain Internet protocols, such as IMAP, SIP, and XMPP, need to connect to a specific
port in addition to connecting with a specific server. SRV records are how a port can be
specified within the DNS.

4.7.2 What goes in an SRV record?

An SRV record contains the following information. Here, we list example values for each field.

However, SRV records are actually formatted in this way:

_service._proto.name. TTL class type of record priority weight port target.

So our example SRV record would actually look like:

_xmpp._tcp.example.com. 86400 IN SRV 10 5 5223 server.example.com.

In the above example, ‘_xmpp’ indicates the type of service (the XMPP protocol), ‘_tcp’
indicates the TCP transport protocol, while ‘example.com’ is the host, or the domain name.
'Server.example.com' is the target server and ‘5223’ indicates the port within that server.

SRV records must point to an A record (in IPv4) or an AAAA record (in IPv6). The server
name they list cannot be a CNAME. So 'server.example.com' must lead directly to an A or
AAAA record under that name.

4.7.3 What is the difference between priority and weight in SRV records?

SRV records indicate the 'priority' and 'weight' of the various servers they list. The
'priority' value in an SRV record enables administrators to prioritize one server that supports
the given service over another. A server with a lower priority value will receive more traffic
than other servers. However, the 'weight' value is similar: a server with a higher weight will
receive more traffic than other servers with the same priority.

The main difference between them is that priority is looked at first. If there are three servers,
Server A, Server B, and Server C, and they have respective priorities of 10, 20, and 30, then
their 'weight' does not matter. The service will always query Server A first.

But suppose Servers A, B, and C all have a priority of 10 — how will a service choose between
them? This is where weight becomes a factor: if Server A has a 'weight' value of 5 and Servers
B and C have a 'weight' value of 3 and 2, Server A will receive the most traffic, Server B will
receive the second-most traffic, and Server C the third-most.

4.8 PTR Record :-

The Domain Name System, or DNS, correlates domain names with IP addresses. A
DNS pointer record (PTR for short) provides the domain name associated with an IP address.
A DNS PTR record is exactly the opposite of the 'A' record, which provides the IP address
associated with a domain name.

DNS PTR records are used in reverse DNS lookups. When a user attempts to reach a
domain name in their browser, a DNS lookup occurs, matching the domain name to the IP
address. A reverse DNS lookup is the opposite of this process: it is a query that starts with the
IP address and looks up the domain name.
4.8.1 How are DNS PTR records stored?

In IPv4:

While DNS A records are stored under the given domain name, DNS PTR records are
stored under the IP address — reversed, and with ".in-addr.arpa" added. For example, the PTR
record for the IP address 192.0.2.255 would be stored under "255.2.0.192.in-addr.arpa".

"in-addr.arpa" has to be added because PTR records are stored within the .arpa top-
level domain in the DNS. .arpa is a domain used mostly for managing network infrastructure,
and it was the first top-level domain name defined for the Internet. (The name "arpa" dates
back to the earliest days of the Internet: it takes its name from the Advanced Research Projects
Agency (ARPA), which created ARPANET, an important precursor to the Internet.)

in-addr.arpa is the namespace within .arpa for reverse DNS lookups in IPv4.

In Ipv6:

IPv6 addresses are constructed differently from IPv4 addresses, and IPv6 PTR records
exist in a different namespace within .arpa. IPv6 PTR records are stored under the IPv6 address,
reversed and converted into four-bit sections (as opposed to 8-bit sections, as in IPv4), plus
".ip6.arpa".

What are some of the main uses for PTR records?

PTR records are used in reverse DNS lookups; common uses for reverse DNS include:

Anti-spam: Some email anti-spam filters use reverse DNS to check the domain names of email
addresses and see if the associated IP addresses are likely to be used by legitimate email servers.

Troubleshooting email delivery issues: Because anti-spam filters perform these checks, email
delivery problems can result from a misconfigured or missing PTR record. If a domain has no
PTR record, or if the PTR record contains the wrong domain, email services may block all
emails from that domain.

Logging: System logs typically record only IP addresses; a reverse DNS lookup can convert
these into domain names for logs that are more human-readable.
What are some of the less commonly used DNS records?

1. AFSDB record - This record is used for clients of the Andrew File System (AFS)
developed by Carnegie Melon. The AFSDB record functions to find other AFS cells.
2. APL record - The ‘address prefix list’ is an experiment record that specifies lists of
address ranges.

3. CAA record - This is the ‘certification authority authorization’ record, it allows

domain owners state which certificate authorities can issue certificates for that
domain. If no CAA record exists, then anyone can issue a certificate for the domain.
These records are also inherited by subdomains.

4. DNSKEY record - The ‘DNS Key Record’ contains a public key used to
verify Domain Name System Security Extension (DNSSEC) signatures.

5. CDNSKEY record - This is a child copy of the DNSKEY record, meant to be

transferred to a parent.

6. CERT record - The ‘certificate record’ stores public key certificates.

7. DCHID record - The ‘DHCP Identifier’ stores info for the Dynamic Host
Configuration Protocol (DHCP), a standardized network protocol used on IP
networks.

8. DNAME record - The ‘delegation name’ record creates a domain alias, just like
CNAME, but this alias will redirect all subdomains as well. For instance if the owner
of ‘example.com’ bought the domain ‘website.net’ and gave it a DNAME record that
points to ‘example.com’, then that pointer would also extend to ‘blog.website.net’ and
any other subdomains.

9. HIP record - This record uses ‘Host identity protocol’, a way to separate the roles of
an IP address; this record is used most often in mobile computing.

10. IPSECKEY record - The ‘IPSEC key’ record works with the Internet Protocol
Security (IPSEC), an end-to-end security protocol framework and part of the Internet
Protocol Suite (TCP/IP).

11. LOC record - The ‘location’ record contains geographical information for a domain
in the form of longitude and latitude coordinates.

12. NAPTR record - The ‘name authority pointer’ record can be combined with an SRV
record to dynamically create URI’s to point to based on a regular expression.

13. NSEC record - The ‘next secure record’ is part of DNSSEC, and it’s used to prove
that a requested DNS resource record does not exist.
14. RRSIG record - The ‘resource record signature’ is a record to store digital signatures
used to authenticate records in accordance with DNSSEC.

15. RP record - This is the ‘responsible person’ record and it stores the email address of
the person responsible for the domain.

16. SSHFP record - This record stores the ‘SSH public key fingerprints’; SSH stands for
Secure Shell and it’s a cryptographic networking protocol for secure communication
over an unsecure network.
Summary And Future Work :-
The contribution we make in this paper is an initial empirical understanding of a broad
range of characteristics of modern DNS records. Specifically, we focus on facts of DNS
hierarchy and its working. Studies have tackled empirical assessment of DNS, we believe that
since the DNS is an evolving system and these studies were conducted many years ago that our
reappraisal is timely. To underscore this point, we note that our analysis covers aspects rarely
or never seen during previous studies. While this paper represents an updating of our
understanding, we also stress that it is only an initial step. Our data comes from a small network
and broader data would be useful. We have gathered data from larger networks, So In these
case study we gathered a lot of information related to DNS , DNS records, its hierarchy and
working.

Analysis :-
While studying for this case study we have analyzed that use of DNS is a vast and its
needed in our everyday life. Websites are become huge part of our life. As we cannot remember
all the IP addresses everytime. Domain Name System provides ease to web surfing and in our
process of getting information. Studying DNS system will open lot of opportunities for web
Developers .

Conclusion :-
These papers proposed the Domain Name System in detail. These papers contains detail
study of Domain name system. As in 21st century, where the world is connected by internet
and so many websites, its become more important to learn about how these system works. In
these papers you can learns about DNS in details like how DNS works, DNS hierarchy, various
DNS services, DNS records ,why records used , DNS queries, everything. Learning About

DNS will help Web developers, Businessmans, students. In conclusion, a DNS

implementation like the one discussed here would benefit the logistics industry and the
economy as a whole by making easier the integration of information across whole supply
chains. While detailed study of Domain Name System, This system is arguably one of the most
important aspect of Internet. DNS ensures the internet is not only user friendly but also works
smoothly, loading the content users ask for quickly and efficiently.
References :-
[1] H. Ichise, Y. Jin, and K. Iida, “Analysis of via-resolver DNS TXT queries and detection
possibility of botnet communications,” Proc. IEEE Pacific Rim Conference on
Communications, Computers and Signal Processing (PACRIM2015), pp.216–221, Aug. 2015.
DOI: 10.1109/PACRIM.2015.7334837

[2] H. Ichise, Y. Jin, and K. Iida, “Analysis of via-resolver DNS TXT queries and detection
possibility of botnet communications,” IEICE Commun. Express, vol.5, no.3, pp.74–78, March
2016. DOI: 10.1587/comex.2015XBL0186

[3] Y. Jin, H. Ichise, and K. Iida, “Design of detecting botnet communication by monitoring
direct outbound DNS queries,” Proc. IEEE Int’l Confrerence on Cyber Security and Cloud
Computing (CSCloud2015), pp.37–41, New York, NY, Nov. 2015. DOI:
10.1109/CSCloud.2015.53

[4] S. Khattak, N.R. Ramay, K.R. Khan, A.A. Syed, and S.A. Khayam, “A taxonomy of botnet
behavior, detection, and defense,” IEEE Commun. Surveys & Tuts., vol.12, no.2, pp.898–924,
Oct. 2013. DOI: 10.1109/SURV.2013.091213.00134

[5] H. Binsalleeh, “Botnets: Analysis, detection, and mitigation,” Network Security

Technologies: Design and Applications, ed. A. Amine, O.A. Mohamed, and B. Benatallah,
pp.204–223, IGI Global, Hershey, PA, Nov. 2013. DOI: 10.4018/978-1-4666-4789-3.ch012

[6] S. Soltani, S.A.H. Seno, M. Nezhadkamali, and R. Budiarto, “A survey on real world
botnets and detection mechanisms,” Int’l Journal of Information and Network Security, vol.3,
no.2, pp.116–127, April 2014.

[7] McAfee, “McAfee labs threats report,” http://www.mcafee.com/us/ resources/reports/rp-

quarterly-threats-mar-2016.pdf, March 2016.

[8] OpenDNS inc., “The role of DNS in botnet command and control,” online
http://info.opendns.com/rs/opendns/images/OpenDNS_SecurityWhitepaper-
DNSRoleInBotnets.pdf, 2012.

[9] P. Mockapetris, “Domain names: Concepts and facilities,” IETF RFC1034, Nov. 1987. [10]
P. Mockapetris, “Domain names: Implementation and specification,” IETF RFC1035, Nov.
1987.

[11] M. Feily, A. Shahrestani, and S. Ramadass, “A survey of botnet and botnet detection,”
Proc. IEEE Int’l Conference on Emerging Security Information, Systems and Technologies,
pp.268–273, Glyfada, Greek, June 2009. DOI: 10.1109/SECURWARE.2009.48
[12] S. Bromberger, “DNS as a covert channel within protected networks,” White paper of
Department of Energy, http://energy.gov/oe/downloads/dns-covert-channel-within-protecte d-
networks, Jan. 2011.

[13] N.M. Hands, B. Yang, and R.A. Hansen, “A study on botnets utilizing DNS,” Proc. ACM
Conference on Research in Information Technology (RIIT’15), pp.23–28, Chicago, IL, USA,
Sept.-Oct. 2015. DOI: 10.1145/2808062.2808070

[14] K. Xu, P. Butler, S. Saha, and D. Yao, “DNS for massivescale command and control,”
IEEE Trans. Dependable and Secure Computing, vol.10, no.3, pp.143–153, May/June 2013.
DOI: 10.1109/TDSC.2013.10

[15] M. Anagnostopoulos, G. Kambourakis, and S. Gritzalis, “New facets of mobile botnet:

Architecture and evaluation,” Int’l Journal of Information Security, 19 pages, Dec. 2015. DOI:
10.1007/s10207-015- 0310-0

[16] C.J. Dietrich, C. Rossow, F.C. Freiling, H. Bos, M. Steen, and N. Pohlmann, “On botnets
that use DNS for command and control,” Proc. IEEE European Conference on Computer
Network Defence (EC2ND’11), pp.9–16, Gothenburg, Sweden, Sept. 2011. DOI:
10.1109/EC2ND.2011.16

[17] C. Mullaney, “Morto worm sets a (DNS) record,” http://www.syma

ntec.com/connect/blogs/morto-worm-sets-dns-record, Aug. 2011. [18] D. Kaminsky, “The
black ops of DNS,” Presented in Black Hat USA 2004, Las Vegas, NV, July 2004.
http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-kaminsky/bh-us-04-
kaminsky.ppt

[18] www.cloudflare.com

[19] www.wpbeginner.com