BIND

What is BIND

BIND (Berkely Internet Name Domain) is a popular software for translating domain names into
IP addresses and usually found on Linux servers.
Berkeley Internet Name Domain (BIND) is the most popular Domain Name System (DNS) server
in use today. It was developed in the 1980s at the University of Berkley and is currently in
version 9. BIND is an open source system free to download and use, offered under the Mozilla
Public License.
BIND can be used to run a caching DNS server or an authoritative name server, and provides
features like load balancing, notify, dynamic update, split DNS, DNSSEC, IPv6, and more.

ZONES AND DOMAINS

The programs that store information about the domain name space are called name servers, as
you probably already know. Name Servers generally have complete information about some
part of the domain name space (a zone), which they load from a file. The name server is then
said to have authority for that zone.
The term zone is not one that you come across every day while you're surfing on the Internet.
We tend to think that the domain concept is all there is when it comes to DNS, which makes life
easy for us, but when dealing with DNS servers that hold data for our domains (name servers),
then we need to introduce the zone term since it is essential so we can understand the setup of
a DNS server. The difference between a zone and a domain is important, but subtle. The best
way to understand the difference is by using a good example, which is coming up next.
The COM domain is divided into many zones, including the hp.

 
The trick to understanding how it works is to remember that a zone exists "inside" a domain.
Name servers load zone files, not domains. Zone files contain information about the portion of
a domain for which they are responsible. This could be the whole domain (sun.com, it.com) or
simply a portion of it (hp.com + pr.hp.com).
In our example, the hp.com domain has two sub-domains, support.hp.com and pr.hp.com. The
first one, support.hp.com is controlled by its own name servers as it has its own zone, called
the support.hp.com zone. The second one though, pr.hp.com is controlled by the same name
server that takes care of the hp.com zone.
The hp.com zone has very little information about the support.hp.com zone, it simply knows its
right below. If anyone requires more information on support.hp.com, it will be requested to
contact the authoritative name servers for that sub-domain, which are the name servers for
that zone.
So you see that even though support.hp.com is a sub-domain just like pr.hp.com, it is not setup
and controlled the same way as pr.hp.com.
On the other hand, the Sun.com domain has one zone (sun.com zone) that contains and
controls the whole domain. This zone is loaded by the authoritative name servers.

What is the use of BIND

BIND is an open source system free to download and use, offered under the Mozilla Public
License. BIND can be used to run a caching DNS server or an authoritative name server, and
provides features like load balancing, notify, dynamic update, split DNS, DNSSEC, IPv6, and
more.

Key Features of BIND

 Multiple Views
Optionally, different information can be presented to a client depending on the network a
request originates from. This is primarily used to deny sensitive DNS entries from clients
outside of the local network, while allowing queries from clients inside the local network.
To configure multiple views, add the view statement to the /etc/named.conf configuration file.
Use the match-clients option to match IP addresses or entire networks and give them special
options and zone data.

  Incremental Zone Transfers (IXFR)

Incremental Zone Transfers (IXFR) allow a secondary name server to only download the
updated portions of a zone modified on a primary name server. Compared to the standard
transfer process, this makes the notification and update process much more efficient.
Note that IXFR is only available when using dynamic updating to make changes to master zone
records. If manually editing zone files to make changes, Automatic Zone Transfer (AXFR) is used.

 Transaction SIGnatures (TSIG)

Transaction SIGnatures (TSIG) ensure that a shared secret key exists on both primary and
secondary nameserver before allowing a transfer. This strengthens the standard IP
address-based method of transfer authorization, since attackers would not only need to have
access to the IP address to transfer the zone, but they would also need to know the secret key.
Since version 9, BIND also supports TKEY, which is another shared secret key method of
authorizing zone transfers.

Important

When communicating over an insecure network, do not rely on IP address-based

authentication only.

  DNS Security Extensions (DNSSEC)

BIND supports a number of different methods to protect the updating and transfer of zones, on
both master and slave name servers:
● DNSSEC — Short for DNS SECurity, this feature allows for zones to be cryptographically
signed with a zone key.
In this way, the information about a specific zone can be verified as coming from a name server
that has signed it with a particular private key, as long as the recipient has that name server's
public key.

● TSIG — Short for Transaction SIGnatures, a shared secret key exists on the master
and slave server, verifying that a transfer from master to slave is authorized.

This feature strengthens the standard IP address-based method of transfer authorization. An

attacker would not only need to have access to the IP address to transfer the zone, but they
would also need to know the secret key.

DNS Protocol Enhancements

BIND supports Incremental Zone Transfers (IXFR), where slave name server will only download
the updated portions of a zone modified on a master name server. The standard transfer AXFR
process requires that the entire zone be transferred to each slave name server for even the
smallest change. For very popular domains with very lengthy zone files and many slave name
servers, IXFR makes the notification and update process much less resource intensive.
Note that IXFR is only available if you are also using dynamic updating to make changes to
master zone records. If you are manually editing zone files to make changes, AXFR will be used.
More information on dynamic updating is available in the BIND 9 Administrator Reference
Manual.

 
Limitations and Advantages of BIND

● No APIs: BIND does not expose APIs, so automation of configuration and deployment of

DNS is not possible

● No integration with CI/CD toolkits: DevOps teams cannot use BIND to deploy DNS as
part of CI/CD pipeline (Eg: using Jenkins) slowing down deployment velocity of
 applications. They have to depend on Network Engineers to configure DNS for their
environments.

The following are disadvantages common to BIND and other first-generation DNS servers
like Power DNS and Microsoft DNS:

● Lacks traffic management features - cannot route traffic to the most appropriate
server using parameters like user location, server load, server capabilities, etc.

Advantages of BIND

BIND enjoys several important advantages, which make it by far the most popular
DNS server on the Internet:
● Broad usage and strong community - BIND is a de facto standard for DNS
in Linux systems, and is actively supported by a large open source
community.
● Stable - BIND is used in millions of production DNS servers and is known for
stable and predictable operation.
● Good platform support - BIND supports Linux, NetBSD, FreeBSD,
OpenBSD, macOS and Windows.
● Comprehensive feature set - BIND is one of the only DNS servers that
covers all basic DNS functionality - see Wikipedia’s detailed comparison of
BIND with other DNS servers.

Platforms supported by BIND

BIND supports Linux, NetBSD, FreeBSD, OpenBSD, macOS and Windows.

Installation Procedures
Server Pre-requisites

Hardware Requirements

DNS hardware requirements have traditionally been quite modest. For many installations,
servers that have been retired from active duty have performed admirably as DNS servers.
However, the DNSSEC features of BIND 9 may be quite CPU-intensive, so organizations that
make heavy use of these features may wish to consider larger systems for these applications.
BIND 9 is fully multithreaded, allowing full utilization of multiprocessor systems for
installations that need it.

CPU Requirements

CPU requirements for BIND 9 range from i386-class machines, for serving static zones
without caching, to enterprise-class machines to process many dynamic updates and
DNSSEC-signed zones, serving many thousands of queries per second.

Memory Requirements

Server memory must be sufficient to hold both the cache and the zones loaded from disk.
The max-cache-size option can limit the amount of memory used by the cache, at the
expense of reducing cache hit rates and causing more DNS traffic. It is still good practice to
have enough memory to load all zone and cache data into memory; unfortunately, the best
way to determine this for a given installation is to watch the name server in operation. After
a few weeks, the server process should reach a relatively stable size where entries are
expiring from the cache as fast as they are being inserted.

Name Server-Intensive Environment Issues

For name server-intensive environments, there are two configurations that may be used.
The first is one where clients and any second-level internal name servers query a main name
server, which has enough memory to build a large cache; this approach minimizes the
bandwidth used by external name lookups. The second alternative is to set up second-level
internal name servers to make queries independently. In this configuration, none of the
individual machines need to have as much memory or CPU power as in the first alternative,
but this has the disadvantage of making many more external queries, as none of the name
servers share their cached data.

Supported Operating Systems

ISC BIND 9 compiles and runs on many Unix-like operating systems and on Microsoft
Windows Server 2012 R2, 2016, and Windows 10. For an up-to-date list of supported
systems, see the PLATFORMS.md file in the top-level directory of the BIND 9 source
distribution.

Installation Procedures

To install BIND to run in a chroot environment, issue the following command as root:

[root@rhel6 ~]# yum install bind-chroot -y

Loaded plugins: rhnplugin
This system is not registered with RHN.
RHN support will be disabled.
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package bind-chroot.i686 32:9.7.0-5.P2.el6 set to be updated
--> Processing Dependency: bind = 32:9.7.0-5.P2.el6 for package:
32:bind-chroot-9.7.0-5.P2.el6.i686
--> Running transaction check
---> Package bind.i686 32:9.7.0-5.P2.el6 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

=============================================================================
=======================
Package Arch Version Repository
Size
=============================================================================
=======================
Installing:
bind-chroot i686 32:9.7.0-5.P2.el6
DVD-RHEL6-Repository 65 k
Installing for dependencies:
bind i686 32:9.7.0-5.P2.el6
DVD-RHEL6-Repository 3.5 M

Transaction Summary
=============================================================================
=======================
Install 2 Package(s)
Upgrade 0 Package(s)

Total download size: 3.5 M

Installed size: 6.4 M
Downloading Packages:
-----------------------------------------------------------------------------
-----------------------
Total 30 MB/s
| 3.5 MB 00:00
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Installing : 32:bind-9.7.0-5.P2.el6.i686
1/2
Installing : 32:bind-chroot-9.7.0-5.P2.el6.i686
2/2

Installed:
bind-chroot.i686 32:9.7.0-5.P2.el6

Dependency Installed:
bind.i686 32:9.7.0-5.P2.el6

Complete!

Installation

We begin with the installation of the bind and bind-utils package. These packages
constitutes dns server and its utilities responsible for querying name servers or DNS servers.

Execute the command:

# dnf install bind bind-utils

Once successfully installed, start the DNS server using the command below:
# systemctl start named

Next, enable it so that it can kick in even after a reboot

# systemctl enable named

Just to be sure that the service is running as expected, check its status
# systemctl status named

Great, the DNS server is running just perfectly. Now let’s jump into
configuring the Bind DNS server
Dependencies of BIND package

Recommended
libcap-2.25 with PAM

Optional
libidn2-2.0.5, libxml2-2.9.8, MIT Kerberos V5-1.16.1, and geoip

Optional database backends

Berkeley
DB-5.3.28, MariaDB-10.3.9 or MySQL, OpenLDAP-2.4.46, PostgreSQL-10.5,
and unixODBC-2.3.7

Optional (to run the test suite)

Net::DNS-1.17

Optional (to rebuild the documentation)

Doxygen-1.8.14, libxslt-1.1.32, and texlive-20180414 (or install-tl-unx)
 Configuration Procedure
how to do the configuration

Create a file /var/named/chroot/var/named/abc.local with the following configuration :

[root@rhel6 ~]# vi /var/named/chroot/var/named/abc.local

;
; Addresses and other host information.
;
@ IN SOA abc.local. abc.abc.local. (
2011030801 ; Serial
43200 ; Refresh
3600 ; Retry
3600000 ; Expire
2592000 ) ; Minimum

; Define the nameservers and the mail servers

IN NS ns.abc.local.
IN A 192.168.1.43
IN MX 10 mail.abc.local.

mail IN A 192.168.1.43
ns IN A 192.168.1.43

Commands used in configuration files Configuration

The BIND nameserver named server uses the /etc/named.conf file for configuration. All zone

files are placed in the /var/named/ directory.

/etc/named.conf
The /etc/named.conf file is a collection of statements using nested options placed in
ellipses { }. A sample  /etc/named.conf file is organized similar to below.
<statement-1> ["<statement-1-name>"] [<statement-1-class>] {
<option-1>;
<option-2>;
<option-N>;
};

<statement-2> ["<statement-2-name>"] [<statement-2-class>] {

 <option-1>;
<option-2>;
<option-N>;
};

<statement-N> ["<statement-N-name>"] [<statement-N-class>] {

<option-1>;
<option-2>;
<option-N>;
};

The "<statement-name>" is only needed with acl, include, server, view, and zone statements.

The <statement-N-class> may only be specified with the zone statement.

Steps for configuring Forward Lookup Zone in-detail

1. Open the Bind configuration file into a text editor.

nano /etc/named.conf

2. Define a new domain. In our example, we’ll be creating a domain called serverlab.intra.

zone "serverlab.intra" IN {

type master;

file "serverlab.intra.db";

allow-query { any; };

};

3.The options set in the above configuration do the following

type –

Defines the role of this server for the zone. I’ve set it to Master, which means this server is
the authoritative owner of the zone. If this were the second server to host the zone, it would
be set to slave. A slave is allowed to host the zone’s database, but in only in read-only.

File-
 The name of the zone’s database file. Unless an absolute path is included, the file will need
to be in the directory set using the directory option at the top of the Bind configuration file.
By default, all files for CentOS are kept in /var/named.

allow-query-

This option defines which hosts or subnets are allowed to query this server for the zone. I’ve
set any which, as the name suggests, allows anyone to query this zone.

4.Save your changes and exit the text editor.

5.The next step is to create the database file. Follow the instruction in the next section
to learn how it’s done.

Steps for configuring Reverse Lookup Zone in-detail

A reverse DNS zone can be identified in the following two ways:

● By the zone name, in the

format reverse_ipv4_address.in-addr.arpa or reverse_ipv6_address.ip6.arpa.

The reverse IP address is created by reversing the order of the components of the IP
address. For example, if the IPv4 network is 192.0.2.0/24, the reverse zone name
is 2.0.192.in-addr.arpa. (with the trailing period).

● By the network address, in the format network_ip_address/subnet_mask_bit_count

To create the reverse zone by its IP network, set the network information to the
(forward-style) IP address, with the subnet mask bit count. The bit count must be a
multiple of eight for IPv4 addresses or a multiple of four for IPv6 addresses.

Adding a Reverse DNS Zone in the Web UI

1. Open the Network Services tab, and select the DNS subtab, followed by the DNS

Zones section.
Figure 33.30. DNS Zone Management

2. Click Add at the top of the list of all zones.

3.

Figure 33.31. Adding a Reverse DNS Zone

4. Fill in the zone name or the reverse zone IP network.

For example, to add a reverse DNS zone by the zone name:

Figure 33.32. Creating a Reverse Zone by Name

Alternatively, to add a reverse DNS zone by the reverse zone IP network:

Figure 33.33. Creating a Reverse Zone by IP Network

The validator for the Reverse zone IP network field warns you about an invalid network
address during typing. The warning will disappear once you enter the full
network address.

5. Click Add to confirm the new reverse zone.

Adding a Reverse DNS Zone from the Command Line

To create a reverse DNS zone from the command line, use the ipa dnszone-add command.
For example, to create the reverse zone by the zone name:

[user@server]$ ipa dnszone-add 2.0.192.in-addr.arpa.

Alternatively, to create the reverse zone by the IP network:

[user@server ~]$ ipa dnszone-add --name-from-ip=192.0.2.0/24

Verification commands for DNS

Run ipconfig /all at a command prompt, and verify the IP address, subnet

mask, and default gateway. Check whether the DNS server is authoritative for
the name that is being looked

DNS information can be verified using the below three commands in Linux.

1. host Command.
2. dig Command.
3. nslookup Command.