Introduction

In one of our earlier articles we demonstrated how to configure a caching only DNS server. In this article we will be explaining the step by step process of configuring a DNS server using bind. Along with the DNS server configuration we will also be explaining some DNS related terms like domains, TLDs and sub domains before we get to the actual configuration.

What are domains or domain names?

When we connect to a website using its name, we type the FQDN (Fully Qualified Domain Name) or the domain name like this: linuxnix.com or www.google.com Each domain consists of domain components and the dot separates or delimits these components. In case of www.google.com, the text com is the top-level domain component and google is the second-level domain component and www is the third-level domain component

Top Level Domain Names (TLDs)
Top level domains (TLDs) are divided into categories based on geographical or functional aspects. In case of www.google.com, com is the top level domain. At present there are over than 800 top level domains on the web. The top level domains categories are:

  • Generic top-level domain like (.org, .com, .net, .gov, .edu and so on).
  • Country-code top-level domains like (.us, .ca and so on) corresponding to the country codes for the United States and Canada respectively.
  • New branded top-level domains like (.linux, .microsoft, .companyname and so on).
  • Infrastructure top-level domains like .arpa domain.

 

Subdomains
Consider the domain name google.com. This could also be referred to as the root domain. We can sub-divide the root domain into smaller divisions called sub-domains as per our requirement. The sub-domain name is prefixed with the domain name followed by a dot. For example, for the domain google.com, mail.google.com could be one of its sub-domains. Note that only the name servers for the sub-domain mail.google.com know all the hosts existing beneath it and the root name servers are not aware about it.

Steps for setting up a DNS server on Centos 7:
We will use the same server that we used to configure our caching only DNS server so it already has the required packages installed.

Step 1: Bind configuration
The configuration file for bind or the named service is /etc/named.conf. Within this file we define zone statements.
The zone statements enable us to define DNS zones. Every domain and sub-domain that you intend to use in your environment will have a zone statement defined in the /etc/named.conf. We will be configuring the domain example.vm and given below is the zone statement for this domain:

zone "example.vm." {
type master;
file "db.example";
allow-query { any; };
};

The type master indicates that this is a primary zone. We could also have slave or caching zones defined as well. The file that contains the zone information is located in /var/named directory. The directory location is defined in the /etc/named.conf files’ options section under directory section and given below is the snippet of the same:

directory "/var/named";

This is the default location and should not be modified. The absolute location of the zone file for our zone example.vm will be /var/named/db.example.

Step 2: The zone file configuration
Within the /var/named directory there is a file named named.empty which can be used as an empty template for configuring our own zone file. I’ve copied the file named.empty to db.example and made the required modifications in the file to allow our zone file to work. Given below is the file content:

[root@linuxnix named]# cat db.example
$TTL 3H
$ORIGIN example.vm.
example.vm. IN SOA linuxnix.example.vm. root.example.vm. (
1 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
example.vm. NS linuxnix.example.vm.
linuxnix A 192.168.23.129
[root@linuxnix named]#

DNS TTL Value
In /etc/named.conf on the top there is $TTL entry. This entry informs BIND about the time to live value for each individual record. So our zone will remain in the database servers’ cache for 3 hours since we’ve defined the TTL as three hours.

The zone database files consist of record types like SOA, NS, A, PTR, MX, CNAME and TXT. The database zone file shown above contains three records:

SOA, NS and A and we will explain these records now.

Start of Authority Record (SOA)

The first line starts with the domain example.vm. and ends with a period. Which is the same as the zone definition in /etc/named.conf file.

  • The word IN means Internet record.
  • The word SOA means Start of Authority record.
  • The hostname linuxnix.example.vm. is the domains’ name server
  • The name root.example.vm. is actually the email address of the domain administrator.
  • Notice that the @ symbol is replaced by a dot and the email id also ends with a dot.

Line 2 is the serial number which is used to tell the name server about the file update time, so whenever you make a change to the zone data, you have to increment this number.

Line 3 is the refresh rate in seconds which defines how frequently the secondary DNS servers should query the primary server to check for updates.

Line 4 is the retry rate in seconds. This is the time that the secondary DNS server takes for waiting after trying to connect to the primary DNS server and cannot reach it.

Line 5 is the expire directive. If the secondary server cannot connect to the primary server for an update, it should discard the value after the specified number of seconds.

Line 6 tells the caching servers can’t connect to the primary DNS server, they wait before expiring an entry, this line defines the wait time.

Name Server (NS) record:
This specifies the name server for the zone.

example.vm. NS linuxnix.example.vm.

For our domain example.vm, the name server is linuxnix.example.vm.

A record:
The A record maps a hostname to an IP address.

linuxnix A 192.168.23.129

Step 3: Test the DNS server
After adding the zone statement for our domain in the /etc/named.conf file and creating our zone database file we need to restart the named service in order to allow for the changes to take effect.

# systemctl restart named

Verify that the service is running

[root@linuxnix data]# systemctl status named
● named.service - Berkeley Internet Name Domain (DNS)
Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; vendor preset: disabled)
Active: active (running) since Fri 2018-09-28 15:03:46 IST; 5s ago
Process: 2782 ExecStop=/bin/sh -c /usr/sbin/rndc stop > /dev/null 2>&1 || /bin/kill -TERM $MAINPID (code=exited, status=0/SUCCESS)
Process: 2793 ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF} $OPTIONS (code=exited, status=0/SUCCESS)
Process: 2791 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z "$NAMEDCONF"; else echo "Checking of zone files is disabled"; fi (code=exited, status=0/SUCCESS)
Main PID: 2796 (named)
CGroup: /system.slice/named.service
└─2796 /usr/sbin/named -u named -c /etc/named.conf -4

Sep 28 15:03:46 linuxnix named[2796]: managed-keys-zone: loaded serial 8
Sep 28 15:03:46 linuxnix named[2796]: zone 0.in-addr.arpa/IN: loaded serial 0
Sep 28 15:03:46 linuxnix named[2796]: zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0
Sep 28 15:03:46 linuxnix named[2796]: zone example.vm/IN: loaded serial 1
Sep 28 15:03:46 linuxnix named[2796]: zone localhost.localdomain/IN: loaded serial 0
Sep 28 15:03:46 linuxnix named[2796]: zone localhost/IN: loaded serial 0
Sep 28 15:03:46 linuxnix named[2796]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0
Sep 28 15:03:46 linuxnix named[2796]: all zones loaded
Sep 28 15:03:46 linuxnix named[2796]: running
Sep 28 15:03:46 linuxnix systemd[1]: Started Berkeley Internet Name Domain (DNS).

Now we need to add our domain and name server information to the /etc/resolv.conf file as shown below:

[root@linuxnix named]# cat /etc/resolv.conf
search example.vm
nameserver 192.168.23.129
[root@linuxnix named]#

Now let’s test our DNS service by doing running nslookup and dig commands:

[root@linuxnix data]# nslookup linuxnix
Server: 192.168.23.129
Address: 192.168.23.129#53

Name: linuxnix.example.vm
Address: 192.168.23.129

[root@linuxnix data]#
[root@linuxnix data]# dig -x linuxnix

; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7_5.1 <<>> -x linuxnix
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 13584
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;linuxnix.in-addr.arpa. IN PTR

;; Query time: 9 msec
;; SERVER: 192.168.23.129#53(192.168.23.129)
;; WHEN: Fri Sep 28 15:04:07 IST 2018
;; MSG SIZE rcvd: 50

The above successful results from the nslookup and dig validate the correct functioning of our DNS server.

Conclusion

This concludes our explanation of how we could setup a bind DNS server on a Centos 7 system. We would like to mention that if you are practicing the setup in a lab environment on virtualbox or vmware player then in that case ensure that you select the network adapter type as host only.

Post Views: 1,806
The following two tabs change content below.

Sahil Suri

He started his career in IT in 2011 as a system administrator. He has since worked with HP-UX, Solaris and Linux operating systems along with exposure to high availability and virtualization solutions. He has a keen interest in shell, Python and Perl scripting and is learning the ropes on AWS cloud, DevOps tools, and methodologies. He enjoys sharing the knowledge he's gained over the years with the rest of the community.