The Domain Name System (DNS) provides a way to map or translate an unfriendly numerical IP address into a people-friendly format. Although this translation isn’t mandatory, it does make the network much more useful and easy to work with for humans.

1. Domain Name System
Prepared by,
P.Shanmugapriya,
AP,
KEC

2. • Domain Name System:
• The Domain Name System (DNS) provides a way to map or translate an unfriendly
numerical IP address into a people-friendly format. Although this translation isn’t
mandatory, it does make the network much more useful and easy to work with for humans.
• The Hosts File:
• Not all sites run their own DNS servers … and not all sites need their own DNS servers!
• In sufficiently small sites with no Internet connectivity, it’s reasonable for each host to keep
its own copy of a table matching all of the hostnames on the local network with their
corresponding IP addresses.
• In most Linux and UNIX systems, this table is stored in the /etc/hosts file.
• The /etc/hosts file keeps its information in a simple tabular format in a plain-text file. The IP
address is in the first column, and all the related hostnames are in the second column. The
third column is typically used to store the short version of the hostname. Only white space
separates the fields. Any text from a pound (#) symbol until the end of the line represents
comments and thus is ignored.
• Here’s an example: # This is a comment line. Just like all the others with # symbol
• 127.0.0.1 localhost.localdomain localhost

3. • Domain and Host Naming Conventions:
• Fully qualified domain name (FQDN), like this one: www.kernel.org. Each string between the periods in
this FQDN is significant. Starting from the right and moving to the left are the top level domain
component, the second-level domain component, and the third-level domain component.
• The Root Domain
• The DNS structure is like that of an inverted tree (upside-down tree). At the top of the inverted
domain tree is the highest level of the DNS structure, aptly called the root domain and represented by
the simple dot (.).
• This is the dot that’s supposed to occur after every FQDN, but it is silently assumed
• to be present even though it is not explicitly written.
• Thus, for example, the proper FQDN for www.kernel.org is really www.kernel.org. (with the root dot
at the end).

4. • This portion of the domain namespace is managed by a bunch of special servers known as the root name
servers.
• At the time of this writing, a total of 13 names are used for distinguishing between the root name servers,
which are managed by 13 providers.
• Many more physical servers and clusters are supported via anycast addressing.
• The Top-Level Domain Names
• The top-level domains (TLDs) can be regarded as the first branches. At the time of this writing, there were more
than 810 (and growing) top-level domains.
• The TLDs can be broken down further:
• ■ Generic top-level domain (such as .org, .com, .net, .mil, .gov, .edu, .int, .biz, and so on).
• ■ Country-code top-level domains (such as .us, .uk, .ng, and .ca, corresponding to the country codes for the
United States, the United Kingdom, Nigeria, and Canada, respectively), as well as their internationalized
counterparts (such as . for India, .中国 for China, .рф for Russia, and so on).
• ■ The newly introduced branded top-level domains. These allow organizations to create any TLDs with up to 64
characters. They can include generic words and brand names (such as .coke, .pepsi, .example, .linux, .microsoft,
.caffenix, .who, .unicef, .companyname, .accountants, .beer, and so on).
• ■ Other special or infrastructure top-level domains (such as the .arpa domain).
• The top-level domain in our sample FQDN (serverA.example.org.) is “.org.”

5. • The Second-Level Domain Names
• The names at this level of the DNS make up the actual organizational boundary of the namespace.
Companies, Internet service providers (ISPs), educational communities, nonprofit groups, and
individuals typically acquire unique names within this level.
• Here are a few examples: redhat.com, ubuntu.com, fedoraproject.org, linuxserverexperts.com,
kernel.org, and caffenix.com.
• The second-level domain in our sample FQDN (serverA.example.org.) is “example.”
• The Third-Level Domain Names
• Individuals and organizations that have been assigned second-level domain names can pretty much
decide what to do with the third-level names. The convention, though, is to use the third-level
names to reflect hostnames or other functional uses. It is also common for organizations to begin
the subdomain definitions from here. An example of functional assignment of a third-level domain
name is the “www” in the FQDN www.yahoo.com. The “www” here can be the actual hostname of a
machine under the umbrella of the yahoo.com domain, or it can be an alias to a real hostname.
• The third-level domain name in our sample FQDN (serverA.example.org.) is “serverA.” Here, it
simply reflects the actual hostname of our server.

6. • By keeping DNS distributed in this manner, the task of keeping track of all the hosts connected to the
Internet is delegated to each site, which takes care of its own information. The central repository
listing of all the primary name servers, called the root server, is the only list of existing domains.

7. • Subdomains
• A subdomain exhibits all the properties of a domain, except that it has delegated a subsection of the
domain instead of all the hosts at a site. Using the example.org site as an example, the subdomain
for the support and help desk department of Example, Inc., is support.example.org.
• When the primary name server for the example.org domain receives a request for a hostname
whose FQDN ends in support.example.org, the primary name server forwards the request down to
the primary name server for support.example.org.
• Only the primary name server for support.example.org knows all the hosts existing beneath it—
hosts such as a system named “www” with the FQDN of www.support.example.org.

8. • To make this clearer, let’s follow the path of a DNS request:
• 1. A client wants to visit a web site called “www.support.example.org.”
• 2. The query starts with the top-level domain “org.” Within “org.” is “example.org.”
• 3. Let’s say one of the authoritative DNS servers for the “example.org” domain is named
“ns1.example.org.” or “ns1” for short. Since the host ns1 is authoritative for the example.org
domain, we have to query it for all hosts (and subdomains)
• under it. So we query it for information about the host we are interested in:
“www.support.example.org.”
• 4. Now ns1.example.org’s DNS configuration is such that for anything ending with
“support.example.org,” the server must contact another authoritative server called
“dns2.example.org.”
• 5. The request for “www.support.example.org” is then passed on to dns2.example .org, which
returns the IP address for www.support.example.org—say, 192.168.1.10.

9. • The in-addr.arpa Domain
• DNS allows resolution to work in both directions. Forward resolution converts names into IP
addresses, and reverse resolution converts IP addresses back into hostnames.
• The process of reverse resolution relies on the in-addr.arpa domain, where arpa is an acronym for
Address Routing and Parameters Area.
• As explained in the preceding section, domain names are resolved by looking at each component
from right to left, with the suffixing period indicating the root of the
• DNS tree. Following this logic, IP addresses must have a top-level domain as well.
• This domain is called in-addr.arpa for IPv4-type addresses. In IPv6, the domain is called ip6.arpa.
• Unlike FQDNs, IP addresses are resolved from left to right once they’re under the inaddr. arpa
domain. Each octet further narrows down the possible hostnames.

11. • Types of Servers
• DNS servers come in three flavors: primary, secondary, and caching. Another special class of name
servers consists of the so-called “root name servers.”.
• Primary servers are considered authoritative for a particular domain. An authoritative server is the
one on which the domain’s configuration files reside. When updates to the domain’s DNS tables
occur, they are done on this server. A primary name server for a domain is simply a DNS server that
knows about all hosts and subdomains existing under its domain.
• Secondary servers work as backups and as load distributors for the primary name servers. Primary
servers know of the existence of secondaries and send them periodic notifications/alerts of changes
to the name tables. The secondary then initiates a zone transfer to pull in the actual changes.
• When a site queries a secondary name server, the secondary responds with authority.
• However, because it’s possible for a secondary to be queried before its primary can alert it to the
latest changes, some people refer to secondaries as “not quite authoritative.”
• Realistically speaking, you can generally trust secondaries to have correct information.

12. • Root Name Servers
• The root name servers act as the first port of call for the topmost parts of the domain namespace.
These servers publish a file called the “root zone file” to other DNS servers and clients on the
Internet. The root zone file describes where the authoritative servers for the DNS top-level
domains (.com, .org, .ca, .ng, .hk, .uk, and so on) are located.
• A root name server is simply an instance of a primary name server—it delegates every request it
gets to another name server.
• Caching servers are just that: caching servers. They contain no configuration files for any particular
domain. Rather, when a client host requests a caching server to resolve a name, that server will
check its own local cache first. If it cannot find a match, it will find the primary server and ask it.
This response is then cached. Practically speaking, caching servers work quite well because of the
temporal nature of DNS requests. Their effectiveness is based on the premise that if you’ve asked
for the IP address to example .org in the past, you are likely to do so again in the near future.
Clients can tell the difference between a caching server and a primary or secondary server,
because when a caching server answers a request, it answers it “non-authoritatively.”

13. • Installing a DNS Server
• The BIND program can be found under the /Packages/ directory at the root of the Fedora DVD or ISO media.
Depending on your specific Fedora disto version, you can also download BIND to your local file system from
any of the Fedora mirrors listed here: https://mirrors.fedoraproject.org./.
• If you have a working connection to the Internet, installing BIND on Red Hat–based distros like RHEL, CentOS,
and Fedora can be as simple as running this command:
• [root@fedora-server ~]# dnf -y install bind
• If, on the other hand, you manually downloaded or copied the BIND binary into your current working
directory, you can install it using the rpm command:
• [root@fedora-server root]# rpm -Uvh bind-9*
• Once this command finishes, you are ready to begin configuring the DNS server.
• What Was Installed
• Many programs come with the main bind and bind-utils packages that were installed
• earlier using the distro package manager. We are interested in the following four tools:
• /usr/sbin/named The DNS server program itself.
• /usr/sbin/rndc The bind name server control utility.
• /usr/bin/host A program that performs a simple query on a name server.
• /usr/bin/dig A program that performs complex queries on a name server.

14. • Understanding the BIND Configuration File
• The named.conf file is the main configuration file for BIND. Based on this file’s specifications, BIND determines
how it should behave and what additional configuration files, if any, must be read. This section covers what
you need to know to set up a generalpurpose DNS server. You’ll find a complete guide to the new configuration
file format in the html directory of BIND’s documentation.
• The general format of the named.conf file is as follows:
• statement {options; // comments};
• The statement keyword tells BIND we’re about to describe a particular facet of its operation, and options are
the specific commands applying to that statement. The curly braces are required so that BIND knows which
options are related to which statements; a semicolon appears after every option and after the closing curly
brace.
• An example of this follows: options {directory "/var/named"; // put config files in /var/named };
• This BIND statement means that this is an option statement. And the particular option here is the directive
that specifies BIND’s working directory—that is, the directory on the local file system that will hold the name
server’s configuration data.

15. • The Specifics
• Comments
• Comments can be in one of the following formats:
• Format Indicates
• // C++-style comments
• /*...*/ C-style comments
• # Perl and UNIX shell script–style comments
• Statement Keywords

16. • Configuring a DNS Server
• Defining a Primary Zone in the named.conf File
• The most basic syntax for a zone entry is as follows:
• zone domain-name {type master;file path-name; };
• The path-name refers to the file containing the database information for the zone in question. For example,
to create a zone for the domain example.org, where the database file is located in
/var/named/example.org.db, you would create the following
• zone definition in the named.conf file: zone "example.org" { type master; file "example.org.db"; };
• Additional Options
• Primary domains can also use the following configuration choices from the options statement:
• check-names
• allow-update
• allow-query
• allow-transfer
• notify
• also-notify.

17. • Defining a Secondary Zone in the named.conf File
• The zone entry format for secondary servers is similar to that of master servers. For
forward resolution, here is the format:
• zone domain-name { type slave; masters IP-address-list; ; file path-name; };
• Here, domain-name is the exact same zone name as specified on the primary name
• server, IP-address-list is the list of IP addresses where the primary name server
• for that zone exists, and path-name is the full path location of where the server will
• keep copies of the primary’s zone files.
• Additional Options
• A secondary zone configuration can also use some of the configuration choices from
• the options statement:
• check-names
• allow-update
• allow-query
• allow-transfer
• max-transfer-time-in

18. • Defining a Caching Zone in the named.conf File
• A caching configuration is the easiest of all configurations. It’s also required for every DNS server
configuration, even if you are running a primary or secondary server.
• This is necessary for the server to search the DNS tree recursively to find other hosts on the
Internet.
• For a caching name server, we define three zone sections. Here’s the first entry:
• zone "." IN { type hint; file "root.hints"; };
• The first zone entry here is the definition of the root name servers. The line type hint; specifies that
this is a caching zone entry, and the line file "root.hints";
• The second zone entry is as follows:
• zone "localhost" IN { type master; file "localhost.db"; };
• The third zone entry defines the reverse lookup for the local host. This is the reverse entry
for resolving the local host address (127.0.0.1) back to the local hostname:
• zone "0.0.127.in-addr.arpa" IN { type master; file "127.0.0.rev"; };

19. • DNS Records Types
• SOA: Start of Authority
• The SOA record starts the description of a site’s DNS entries. The format of this entry is as follows:
• NS: Name Server
• The NS record is used for specifying which name servers maintain records for this zone. If any
secondary name servers exist that you intend to transfer zones to, they need to be specified here.
The format of this record is as follows:
• IN NS ns1.domain.name.
• IN NS ns2.domain.name.

20. • A and AAAA: Address Records
• This is probably the most common type of record found in the wild. The A record is
• used to provide a mapping from hostname to IP address. The format of an A address
• is simple:
• Host_name IN A IP-Address
• For example, an A record for the host serverB.example.org, whose IP address is
• 192.168.1.2, would look like this:
• serverB IN A 192.168.1.2
• The equivalent of the IPv4 A resource record in the IPv6 world is called the AAAA
• (quad-A) resource record. For example, a quad-A record for the host serverB whose
• IPv6 address is 2001:DB8::2 would look like this:
• serverB IN AAAA 2001:DB8::2

21. • PTR: Pointer Record
• The PTR record is for performing reverse name resolution, thereby allowing someone to specify an
IP address and determine the corresponding hostname. The format for this record is similar to the A
record, except with the values reversed:
• IP-Address IN PTR Host_name
• MX: Mail Exchanger
• The format of the MX record is as follows:
• domainname. IN MX weight Host_name
• CNAME: Canonical Name
• CNAME records allow you to create aliases for hostnames. A CNAME record can be regarded as an
alias. This is useful when you want to provide a highly available service with an easy-to-remember
name, but still give the host a real name.
• New_host_name IN CNAME old_host_name
• For our sample scenario, the CNAME entry will be
• zabtsuj-content IN A 192.168.1.111
• www IN CNAME zabtsuj-content

22. • RP and TXT: The Documentation Entries
• A TXT record is a free-form text entry into which you can place whatever information you deem fit.
Most often, you’ll want to put only contact information in these records.
• Each TXT record must be tied to a particular hostname. Here’s an example:
• serverA.example.org. IN TXT "Contact: Admin Guy"
• IN TXT "SysAdmin/Android"
• IN TXT "Voice: 999-999-9999“
• The DNS Toolbox
• host
• dig
• nslookup
• whois
• nsupdate
• The rndc Tool