5.7. Securing BIND

Translation(s)
: English — French

Introduction

Putting a DNS server on a network allows for the replacement of IP addresses of individual machines by a name. As a result, it’s even possible to associate multiple names to the same machine to update the different available services. For example, www.example.com and pop.example.com, could both point to the primary server where the mail server and the business intranet reside, and the domain could be example.com. It’s easy to remember that these two services are running on the same machine whose IP address is 192.168.0.1.

Definitions

• DNS
  : Domain Name System or Domain Name Server

• Primary Server
  :

• Secondary server
  :

• Server cache
  :

Network Layout

We get internet access through an xxxbox (192.168.1.1), two DNS servers provided by our ISP (80.10.249.2, 80.10.246.129). In fact, these two latter servers will ever be referred to in the configuration because the xxxbox will be in charge of resolving names if the packet destination isn’t known. Consequently, I consider the xxxbox like a primary server outside of our domain. The “sid” server (192.168.1.10) is connected to the xxxbox via its primary network card. It’s also connected to the LAN (192.168.0.0/24) by its secondary network interface(192.168.0.1). It’s on this that we are going to install the primary DNS server for our domain example.com
( rfc2606
) All the computers on the LAN are automatically assigned a single address by the DHCP service. The DHCP also provides the primary DNS server’s address for our domain, and updates the host names for the zone example.com so they can be associated with an ip address.

Installation

The package bind9 will be used for installation.

        
# apt-get install bind9  

and then if you want to also install the documentation (very useful):

        
# apt-get install bind9-doc  

Configuration

After installation, you might want to get familiar with some of the configuration files. They are in the directory /etc/bind/

TSIG Signature

The purpose of this signature is to authenticate transactions with BIND. Thus, the DHCP server cannot update the example.com domain if it loses this key. Copy and paste an existing key

        
# cd /etc/bind/
       
# cat rndc.key
       
key "rndc-key" {
       
 algorithm hmac-md5;
       
 secret "QJc08cnP1xkoF4a/eSZZbw==";
       
};
       

       
# cp rndc.key ns-example-com_rndc-key  

• algorithm HMAC-MD5
  — identifies 157 (required for a TSIG signature and only algorithm supported by BIND)

• length of 512 octets
  (multiple of 64 with a maximum length of 512 for the above algorithm)

• name
  : ns-example-com_rndc-key

        
dnssec-keygen -a HMAC-MD5 -b 512 -n USER ns-example-com_rndc-key
       
Kns-example-com_rndc-key.+157+53334  

The footprint associated with the key is 53334. We get two files, one with an extension key and the other with a private extension. This substitutes the key in the file ns-example-com_rndc-key with the one in one of these two files.

        
# cat Kns-example-com_rndc-key.+157+53334.private
       
Private-key-format: v1.2
       
Algorithm: 157 (HMAC_MD5)
       
Key: LZ5m+L/HAmtc9rs9OU2RGstsg+Ud0TMXOT+C4rK7+YNUo3vNxKx/197o2Z80t6gA34AEaAf3F+hEodV4K+SWvA==
       
Bits: AAA=
       

       
# cat ns-example-com_rndc-key
       
key "ns-example-com_rndc-key" {
       
 algorithm hmac-md5;
       
 secret "LZ5m+L/HAmtc9rs9OU2RGstsg+Ud0TMXOT+C4rK7+YNUo3vNxKx/197o2Z80t6gA34AEaAf3F+hEodV4K+SWvA==";
       
};  

The file ns-example-com_rndc-key should not be made world readable for security reasons. This should be inserted into the bind configuration by an include because the bind configuration itself is world-readable. Also, it’s a good idea to delete the key and private files generated before.

File /etc/bind/named.conf

This file is the main configuration file for the DNS file.

        
// Managing acls
       
acl internals { 127.0.0.0/8; 192.168.0.0/24; };
       

       
// Load options
       
include "/etc/bind/named.conf.options";
       

       
// TSIG key used for the dynamic update
       
include "/etc/bind/ns-example-com_rndc-key";
       

       
// Configure the communication channel for Administrative BIND9 with rndc
       
// By default, they key is in the rndc.key file and is used by rndc and bind9 
       
// on the localhost
       
controls {
       
 inet 127.0.0.1 port 953 allow { 127.0.0.1; };
       
};
       

       
// prime the server with knowledge of the root servers
       
zone "." {
       
 type hint;
       
 file "/etc/bind/db.root";
       
};
       

       
include "/etc/bind/named.conf.default-zones";
       
include "/etc/bind/named.conf.local";  

File /etc/bind/named.conf.default-zones

Note: as of Debian 7 «Wheezy» bind9 ships with a file containing default forward, reverse, and broadcast zones.

        
// be authoritative for the localhost forward and reverse zones, and for
       
// broadcast zones as per RFC 1912
       
zone "localhost" {
       
 type master;
       
 file "/etc/bind/db.local";
       
};
       
zone "127.in-addr.arpa" {
       
 type master;
       
 file "/etc/bind/db.127";
       
};
       
zone "0.in-addr.arpa" {
       
 type master;
       
 file "/etc/bind/db.0";
       
};
       
zone "255.in-addr.arpa" {
       
 type master;
       
 file "/etc/bind/db.255";
       
};  

File /etc/bind/named.conf.options

This file contains all the configuration options for the DNS server

        
options {
       
 directory "/var/cache/bind";
       

       
 // Exchange port between DNS servers
       
 query-source address * port *;
       

       
 // Transmit requests to 192.168.1.1 if
       
 // this server doesn't know how to resolve them
       
 forward only;
       
 forwarders { 192.168.1.1; };
       

       
 auth-nxdomain no; # conform to RFC1035
       

       
 // From 9.9.5 ARM, disables interfaces scanning to prevent unwanted stop listening
       
 interface-interval 0;
       
 // Listen on local interfaces only(IPV4)
       
 listen-on-v6 { none; };
       
 listen-on { 127.0.0.1; 192.168.0.1; };
       

       
 // Do not transfer the zone information to the secondary DNS
       
 allow-transfer { none; };
       

       
 // Accept requests for internal network only
       
 allow-query { internals; };
       

       
 // Allow recursive queries to the local hosts
       
 allow-recursion { internals; };
       

       
 // Do not make public version of BIND
       
 version none;
       
};  

The port associated with the query-source
option must not in any case be frozen because it jeopardizes the DNS transactions in the case of a resolver.

M. Rash wrote an interesting article about this and how to force the source port randomly via the iptables:
Mitigating DNS Cache Poisoning Attacks with iptables

To reduce the delay timeout for UDP connections, and thus highlight the randomization, which by default is 30s by tuple, simply update the parameter net.netfilter.nf_conntrack_udp_timeout

        
# sysctl -w net.netfilter.nf_conntrack_udp_timeout=10  

to get timeout of 10s.

File /etc/bind/named.conf.local

This file contains the local DNS server configuration, and this is where you declare the zones associated with this server’s domain(s).

        
// Manage the file logs
       
include "/etc/bind/named.conf.log";
       

       
// Domain Management example.com
       
// ------------------------------
       
// - The server is defined as the master on the domain.
       
// - There are no forwarders for this domain.
       
// - Entries in the domain can be added dynamically 
       
// with the key ns-example-com_rndc-key
       
zone "example.com" {
       
 type master;
       
 file "/var/lib/bind/db.example.com";
       
 //forwarders {};
       
 // If we do not comment the ''forwarders'' "empty" clients of the local subnet in my case don't have access to the upstream DNS ?
       
 //allow-update { key ns-example-com_rndc-key; };
       
 allow-update { key rndc-key; };
       
 //confusion between the file name to import (ns-example-com_rndc-key) and the key label (rndc-key) ?
       
};
       
zone "0.168.192.in-addr.arpa" {
       
 type master;
       
 file "/var/lib/bind/db.example.com.inv";
       
 //see comment below (zone "example.com")
       
 //forwarders {};
       
 //allow-update { key ns-example-com_rndc-key; };
       
 allow-update { key rndc-key; };
       
};
       

       
// Consider adding the 1918 zones here, if they are not used in your
       
// organization
       
include "/etc/bind/zones.rfc1918";  

NOTE: if you create a local non-FQDN and call it .local it clashes with some other packages (which?). Edit /etc/nsswitch.conf and move dns right after the files on the host line makes .local domains work.

File /etc/bind/named.conf.log

With Debian Jessie, you need to create this file in /etc/bind

        
logging {
       
 channel update_debug {
       
 file "/var/log/update_debug.log" versions 3 size 100k;
       
 severity debug;
       
 print-severity yes;
       
 print-time yes;
       
 };
       
 channel security_info {
       
 file "/var/log/security_info.log" versions 1 size 100k;
       
 severity info;
       
 print-severity yes;
       
 print-time yes;
       
 };
       
 channel bind_log {
       
 file "/var/log/bind.log" versions 3 size 1m;
       
 severity info;
       
 print-category yes;
       
 print-severity yes;
       
 print-time yes;
       
 };
       

       
 category default { bind_log; };
       
 category lame-servers { null; };
       
 category update { update_debug; };
       
 category update-security { update_debug; };
       
 category security { security_info; };
       
};  

Resource Records (RR)

DNS is made up of several registrations, RR or Resource Records, defining the various domain information. The first is dedicated to name resolution, in our case, it is the file db.example.com. The second will be used for reverse name resolution, it is the file db.example.com.inv.

Files in /var/lib/bind/

• RR for name resolution (db.example.com file)
  

        
$TTL 3600
       
@ IN SOA sid.example.com.  root.example.com.  (
       
 2007010401 ; Serial
       
 3600 ; Refresh [1h]
       
 600 ; Retry [10m]
       
 86400 ; Expire [1d]
       
 600 ) ; Negative Cache TTL [1h]
       
;
       
@ IN NS sid.example.com.
       
@ IN MX 10 sid.example.com.
       

       
sid IN A 192.168.0.1
       
etch IN A 192.168.0.2
       

       
pop IN CNAME sid
       
www IN CNAME sid
       
mail IN CNAME sid  

• RR for inverse name resolution (db.example.com.inv file)
  

        
@ IN SOA sid.example.com.  root.example.com.  (
       
 2007010401 ; Serial
       
 3600 ; Refresh [1h]
       
 600 ; Retry [10m]
       
 86400 ; Expire [1d]
       
 600 ) ; Negative Cache TTL [1h]
       
;
       
@ IN NS sid.example.com.
       

       
1 IN PTR sid.example.com.
       
2 IN PTR etch.example.com.    

Some Explanations

In the first example, we can see the directive $TTL (Time To Live), which expresses the duration (in seconds) validity, by default, of the information contained in the RRs. Once this time expires, it is necessary to recheck the data.

Then, we have each RR specified with its type. Some examples are:

• • 1. Serial
    : is the whole non-signed 32 bits. This is the serial number to increment with each change of file. It allows the secondary server to reload the information they have. The general purpose is to format it this way YYYYMMDDXX, either for the first amendment 01/04/2007 -> 2007040101, for the second 2007040102.

  • 2. Refresh
    : defines the data refresh period.

  • 3. Retry
    : if an error occurs during the last refresh, it will be repeated at the end of time Retry.

  • 4. Expires
    : the server is considered unavailable after the time expires.

  • 5. Negative cache TTL
    : set the lifetime of a NXDOMAIN response from us.

• NS
  : information on behalf of nameservers for the domain.

• MX.
  : information on the mail server. Many can be defined. Thus, it is possible to give them a priority, assigning a number. The lower the number, the higher the priority.

• A
  : associates a host name to an IPv4 address (32 bits)

• AAAA
  : associates a host name to an IPv6 address (128 bits)

• CNAME
  : identifies the canonical name of an alias (a name that points to another name)

• PTR
  : This is simply the inverse resolution (the opposite of type A).

For a complete list, please refer to the iana list

/etc/resolv. conf File

        
search example.com  

It’s no more complicated than that !

Debian Wheezy and earlier

This option is found in the bind service config file /etc/default/bind9

        
OPTIONS="-u bind"  

The bind start script /etc/init.d/bind9
reads this config file when the service is started.

To begin, start by stopping the bind service:

        
/etc/init.d/bind9 stop  

Then edit /etc/default/bind9:

        
OPTIONS="-u bind -t /var/bind9/chroot"  

        
OPTIONS="-u bind -4 -t /var/bind9/chroot"  

Now create the chroot directory structure:

        
mkdir -p /var/bind9/chroot/{etc,dev,var/cache/bind,var/run/named}  

Create the required device special files and set the correct permissions:

        
mknod /var/bind9/chroot/dev/null c 1 3
       
mknod /var/bind9/chroot/dev/random c 1 8
       
mknod /var/bind9/chroot/dev/urandom c 1 9
       
chmod 660 /var/bind9/chroot/dev/{null,random,urandom}  

Move the current config directory into the new chroot directory:

        
mv /etc/bind /var/bind9/chroot/etc  

Now create a symbolic link in /etc for compatibility:

        
ln -s /var/bind9/chroot/etc/bind /etc/bind  

If you want to use the local timezone in the chroot (e.g. for syslog):

        
cp /etc/localtime /var/bind9/chroot/etc/  

Change the ownership on the files you’ve just moved over and the rest of the newly created chroot directory structure:

        
chown bind:bind /var/bind9/chroot/etc/bind/rndc.key
       
chmod 775 /var/bind9/chroot/var/{cache/bind,run/named}
       
chgrp bind /var/bind9/chroot/var/{cache/bind,run/named}  

Edit the PIDFILE variable in /etc/init.d/bind9 to the correct path:

        
PIDFILE=/var/bind9/chroot/var/run/named/named.pid  

Finally tell rsyslog to listen to the bind logs in the correct place:

        
echo "\$AddUnixListenSocket /var/bind9/chroot/dev/log" > /etc/rsyslog.d/bind-chroot.conf  

Restart rsyslog and start bind:

        
/etc/init.d/rsyslog restart; /etc/init.d/bind9 start  

Debian Jessie and later

Create the file /etc/systemd/system/bind9.service with options «-t /var/bind9/chroot»:

                                             
               
[Unit]
               

Description=BIND Domain Name Server

Documentation=man:named

                                         
              
After=network.target
                                                       

                                         
              
[Service]
              
                           
              
ExecStart=/usr/sbin/named -f -u bind -t /var/bind9/chroot
              
                                         
ExecReload=/usr/sbin/rndc reload
                                                       
ExecStop=/usr/sbin/rndc stop
                                                       

                                                       
[Install]
                                                       
WantedBy=multi-user.target  

However, at least by Debian 9 stretch, one could use the package maintainer’s version

of the systemd unit file, and add the chroot overrides in:

                                         
/etc/systemd/system/bind9.service.d/bind9.conf (or setting one's chroot dir accordingly), e.g.:                                         
              
              
                                         
                                                       
                                         
              
              
                                         
                                                       
                            


                                                                                  
[Service]
              
                           
UMask=027
 
 ExecStart=
 
 ExecStart=/usr/sbin/named -f -u bind -t /var/bind9/chroot 
  However, at least as of Debian 10 buster, it's probably better to remove such a  
 /etc/systemd/system/bind9.service.d/bind9.conf file (as the manner in which systemd
now starts bind9's named, has changed, and will typically conflict with override done as the above),
 
 and now is best to have the overrides in /etc/default/bind9, e.g.:  
 
 
  
 OPTIONS="-u bind -t /var/bind9/chroot" 
 and systemd will now incorporate the OPTIONS from /etc/default/bind9 and use those (as will
 at least also sysvinit).  
  
 Update the symlink to the unit file with:-  
  
        
systemctl reenable bind9  
 Also advised to run:  
  
        
systemctl daemon-reload  
 for systemd (default) systems, to pick up any changes to systemd configuration files.  
  
 Now create the chroot directory structure:  
  
        
mkdir -p /var/bind9/chroot/{etc,dev,run/named,var/cache/bind}  
 Create the required device special files and set the correct permissions:  
  
        
mknod /var/bind9/chroot/dev/null c 1 3
       
mknod /var/bind9/chroot/dev/random c 1 8
       
mknod /var/bind9/chroot/dev/urandom c 1 9
       
chmod 666 /var/bind9/chroot/dev/{null,random,urandom}  
 Move the current config directory into the new chroot directory:  
  
        
mv /etc/bind /var/bind9/chroot/etc  
 Now create a symbolic link in /etc for compatibility:  
  
        
ln -s /var/bind9/chroot/etc/bind /etc/bind  
 If you want to use the local timezone in the chroot (e.g.  for syslog):  
  
        
cp /etc/localtime /var/bind9/chroot/etc/  
 Change the ownership on the files you've just moved over and the rest of the newly created chroot directory structure:  
  
        
chown bind:bind /var/bind9/chroot/etc/bind/rndc.key
       
chown bind:bind /var/bind9/chroot/run/named
       
chmod 775 /var/bind9/chroot/{var/cache/bind,run/named}
       
chgrp bind /var/bind9/chroot/{var/cache/bind,run/named}  
        
/var/bind9/chroot/etc/bind/** r,
       
/var/bind9/chroot/var/** rw,
       
/var/bind9/chroot/dev/** rw,
       
/var/bind9/chroot/run/** rw,
       
/var/bind9/chroot/usr/** r,  
 Without that change, bind would terminate immediately on startup with error message "open: /etc/bind/named.conf: permission denied".  To make these  AppArmor 
 changes effective:  
  
        
systemctl reload apparmor  
 Finally tell rsyslog to listen to the bind logs in the correct place:  
  
 echo "\$AddUnixListenSocket /var/bind9/chroot/dev/log" > /etc/rsyslog.d/bind-chroot.conf 
  Restart rsyslog and start bind:  
  
 
 systemctl restart rsyslog
  
 systemctl restart bind9
  Also, alternative chroot approach to copying many files, etc., and more compatible 
             
for interacting utilities, etc.  outside of chroot.    One can relocate some directory(/ies),             
 
 create some directories/files as/where needed, and use bind mounts, e.g.: 
included in /etc/fstab:  
  
  
  
 
             
                          


             
 
 /dev/null /var/lib/named/dev/null none bind 0 0
 
 /dev/random /var/lib/named/dev/random none bind 0 0
  
 /run/named /var/lib/named/run/named none bind 0 0
                         
/usr/share/dns /var/lib/named/usr/share/dns none bind 0 0 
  and we then also have:
                         
 
  
  
 
$ ls -ld /etc/bind
  
 lrwxrwxrwx 1 root root 25 Mar 15 2014 /etc/bind -> ./var/lib/named/etc/bind
 
 $
 in fact it's possible to set up a configuration that not only works within chroot,  
 but also works without using chroot - only changing how bind9/named is invoked, and nothing else,  
 and between symbolic links and bind mounts, utilities outside the chroot will also interact 
 with bind fine, "as if" it were outside the chroot - as they find the needed bind components
            
logically in the same place, even though most are physically within the chroot stucture            
 
 (and some, via bind mounts, are outside of the chroot and equally accessible inside and 
 outside the chroot).  
  
 Client Manage
 option domain-name "example.com"  
  
 option domain-name-server sid.example.com  
  
 It must be added to the file (I think) the areas for which DHCP should automatically perform updates.  
  
 Syntax (everything after "=>" is my comments) :  
  
 primary 127.0.0.1; => the primary DNS server is on the same machine as the DHCP  
  
 key rndc-key; => it's necessary to provide the security key (via an  include 
 ) in the beginning of the DHCP server configuration file,  
  
 this must be the same key that secures the allow-update for the zone in the  named.conf.local 
 of Bind9.  
 - example.com.  : for the direct zone of this article,  
  
 - 0.168.192.in-addr.arpa.  : for the inverse zone of this article.  
  
  
  Dig Command 
 : this can directly search the DNS server of your choice and get a lot of information in addition to name resolution and contrast resolution.  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
 
  
  
 
  
 
 
  
 $ dig nomade-frjo.stones.lan
 
 ; <<>> DiG 9.4.2 <<>> nomade-frjo.stones.lan
  
 ;; global options: printcmd
;; Got answer:
  
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15760
  
 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
  
         
;; QUESTION SECTION:
         
 
 ;nomade-frjo.stones.lan.    IN A
 
 
 ;; ANSWER SECTION:
  
 nomade-frjo.stones.lan.  900 IN A 192.168.0.242
 
;; AUTHORITY SECTION:
  
 stones.lan.   604800 IN NS emerald.stones.lan.
  
 stones.lan.   604800 IN NS diamond.stones.lan.
  
                          
;; ADDITIONAL SECTION:
                          
         
diamond.stones.lan.   604800 IN A 192.168.0.1
         
                          
emerald.stones.lan.   604800 IN A 192.168.0.2
                                   

                                   
;; Query time: 20 msec
                                   
;; SERVER: 127.0.0.1#53(127.0.0.1)
                                   
;; WHEN: Fri Mar 28 20:53:09 2008
                                   
;; MSG SIZE rcvd: 131
         
                 
  
 $ dig -x 192.168.0.242
 
 ; <<>> DiG 9.4.2 <<>> -x 192.168.0.242
  
 ;; global options: printcmd
 
         
;; Got answer:
         
 
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37702
 
         
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
         
 
 
 ;; QUESTION SECTION:
 ;242.0.168.192.in-addr.arpa.    IN PTR
 
  
 ;; ANSWER SECTION:
 
242.0.168.192.in-addr.arpa.  900 IN PTR nomade-frjo.stones.lan.
  
 ;; AUTHORITY SECTION:
  
 0.168.192.in-addr.arpa.  604800 IN NS diamond.stones.lan.
0.168.192.in-addr.arpa.  604800 IN NS emerald.stones.lan.
 
  
 ;; ADDITIONAL SECTION:
 
 diamond.stones.lan.   604800 IN A 192.168.0.1
 emerald.stones.lan.   604800 IN A 192.168.0.2
  
  
 ;; Query time: 19 msec
  
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
  
 ;; WHEN: Fri Mar 28 20:53:31 2008
  
 ;; MSG SIZE rcvd: 155
  
  nslookup 
 : Kind of slow but still useful.  
  
  
  
  
  
  
  
  
  
  
  
        
$ nslookup etch
       
Server: 192.168.0.1
       
Address: 192.168.0.1#53
       
Name: etch.example.com
       
Address: 192.168.0.2
       

       
$ nslookup 192.168.0.2
       
Server: 192.168.0.1
       
Address: 192.168.0.1#53
       
2.0.168.192.in-addr.arpa name = etch.example.com.    
  
  named-checkconf 
 : Verifies the syntax of the configuration files for Bind9.  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
        
# named-checkconf -z
       
zone localhost/IN: loaded serial 1
       
zone 127.in-addr.arpa/IN: loaded serial 1
       
zone 0.in-addr.arpa/IN: loaded serial 1
       
zone 255.in-addr.arpa/IN: loaded serial 1
       
zone estar.lan/IN: loaded serial 20080315
       
zone 0.168.192.in-addr.arpa/IN: loaded serial 20080315
       
zone 10.in-addr.arpa/IN: loaded serial 1
       
zone 16.172.in-addr.arpa/IN: loaded serial 1
       
zone 17.172.in-addr.arpa/IN: loaded serial 1
       
zone 18.172.in-addr.arpa/IN: loaded serial 1
       
zone 19.172.in-addr.arpa/IN: loaded serial 1
       
zone 20.172.in-addr.arpa/IN: loaded serial 1
       
zone 21.172.in-addr.arpa/IN: loaded serial 1
       
zone 22.172.in-addr.arpa/IN: loaded serial 1
       
zone 23.172.in-addr.arpa/IN: loaded serial 1
       
zone 24.172.in-addr.arpa/IN: loaded serial 1
       
zone 25.172.in-addr.arpa/IN: loaded serial 1
       
zone 26.172.in-addr.arpa/IN: loaded serial 1
       
zone 27.172.in-addr.arpa/IN: loaded serial 1
       
zone 28.172.in-addr.arpa/IN: loaded serial 1
       
zone 29.172.in-addr.arpa/IN: loaded serial 1
       
zone 30.172.in-addr.arpa/IN: loaded serial 1
       
zone 31.172.in-addr.arpa/IN: loaded serial 1
       
zone 168.192.in-addr.arpa/IN: loaded serial 1  
  
   named-checkzone 
 : Verifies the validity of zone files before resetting the configuration. 
            
                                           
           
                                
                                
           
           
                     
           
                        
           
 
 # named-checkzone example.com /var/lib/bind/db.example.com
 
 zone example.com/IN: loaded serial 20080315
  
 OK 
  
  
 
           
           
 
 # named-checkzone 0.168.192.in-addr.arpa /var/lib/bind/db.example.com.inv
 
 zone 0.168.192.in-addr.arpa/IN: loaded serial 20080315
  
 OK 
  
 Links and Resources
  
                                rfc1035           
           
 - Implementation and specifications           
                                
           
 
   rfc1591 
 — Domain Name System Structure and Delegation 
           
                      
                                                            rfc2606          
          
 - Reserved Top Level DNS Names          
                   
          
                    
                    
          
          Services Whois :                                       
                    
                      

          
          DNSSEC          
          
          
          see:                    DNSSEC Howto for BIND 9.9+                    
                             
          
          
                   
          
          
                             

                    
			There are different issues that can be tackled in order to secure the Domain server daemon, which are similar to the ones considered when securing any given service: 
			                    


                             
                             
						configuring the daemon itself properly so it cannot be misused from the outside (see                    Section 5.7.1, “Bind configuration to avoid misuse”                    
).  This includes limiting possible queries from clients: zone transfers and recursive queries.
					  
  
    
    


  
   
  


  
        
5.7.1. Bind configuration to avoid misuse  
  


  
   
  


  
  
				Imagine that your server is connected to the Internet and to your internal (your internal IP is 192.168.1.2) network (a basic multi-homed server), you do not want to give any service to the Internet and you just want to enable DNS lookups from your internal hosts.  You could restrict it by including in  /etc/bind/named.conf  
: 
  
  


  
  options {
 allow-query { 192.168.1/24; } ;
 allow-transfer { none; } ; 
 allow-recursion { 192.168.1/24; } ;
 listen-on { 192.168.1.2; } ;
 forward { only; } ;
 forwarders { A. B. C. D; } ;
};
  
  options { .  various options here .
version "Not available."; };  
 Changing the version.bind record does not provide actual protection against attacks, but it might be considered a useful safeguard.
  acl internal {
 127.0.0.1/32; // localhost
 10.0.0.0/8; // internal
 aa.bb.cc.dd; // eth0 IP
};

acl friendly {
 ee.ff.gg.hh; // slave DNS
 aa.bb.cc.dd; // eth0 IP
 127.0.0.1/32; // localhost
 10.0.0.0/8; // internal
};

options {
 directory "/var/cache/bind";
 allow-query { internal; };
 allow-recursion { internal; };
 allow-transfer { none; };
};
// From here to the mysite.bogus zone 
// is basically unmodified from the debian default
logging {
 category lame-servers { null; };
 category cname { null; }; 
};

zone "." {
 type hint;
 file "/etc/bind/db.root";
};

zone "localhost" {
 type master;
 file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
 type master;
 file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
 type master;
 file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
 type master;
 file "/etc/bind/db.255";
};

// zones I added myself
zone "mysite.bogus" {
 type master;
 file "/etc/bind/named.mysite";
 allow-query { any; };
 allow-transfer { friendly; };
};
  
 Please (again) check the Bug Tracking System regarding Bind, specifically  http://bugs.debian.org/94760 
 .  Feel free to contribute to the bug report if you think you can add useful information.
  
 5.7.2. Changing BIND's user
  addgroup named
adduser --system --home /home/named --no-create-home --ingroup named \
 --disabled-password --disabled-login named
  
  adduser --system --ingroup named named
  
 Now you can either edit /etc/init.d/bind
 with your favorite editor and change the line beginning with
  start-stop-daemon --start
  
  start-stop-daemon --start --quiet --exec /usr/sbin/named -- -g named -u named
  
  OPTIONS="-u named -g named"
  
 Change the permissions of files that are used by Bind, including /etc/bind/rndc.key
 :
  -rw-r----- 1 root named 77 Jan 4 01:02 rndc.key
  
 and where bind creates its pidfile, using, for example, /var/run/named
 instead of /var/run
 :
  $ mkdir /var/run/named
$ chown named.named /var/run/named
$ vi /etc/named.conf
[ .  update the configuration file to use this new location .]
options { .
 pid-file "/var/run/named/named.pid";
};
[ .  ]
  
 Also, in order to avoid running anything as root, change the reload
 line in the init.d script by substituting:
  reload)
 /usr/sbin/ndc reload
  
  reload)
 $0 stop
 sleep 1
 $0 start
  
 Note: Depending on your Debian version you might have to change the restart
 line too.  This was fixed in Debian's bind version 1:8.3.1-2
 .
 All you need to do now is to restart bind via /etc/init.d/bind restart
 , and then check your syslog for two entries like this:
  Sep 4 15:11:08 nexus named[13439]: group = named
Sep 4 15:11:08 nexus named[13439]: user = named
  
  
 5.7.3. Chrooting the name server
 To achieve maximum BIND security, now build a chroot jail (see  Section 5.10, “General chroot and suid paranoia” 
 ) around your daemon.  There is an easy way to do this: the -t
 option (see the manual page or page 100 of  http://www.nominum.com/content/documents/bind9arm.pdf 
 ).  This will make Bind chroot itself into the given directory without you needing to set up a chroot jail and worry about dynamic libraries.  The only files that need to be in the chroot jail are:
  dev/null
etc/bind/ - should hold named.conf and all the server zones
sbin/named-xfer - if you do name transfers
var/run/named/ - should hold the PID and the name server cache (if
 any) this directory needs to be writable by named user
var/log/named - if you set up logging to a file, needs to be writable
 for the named user
dev/log - syslogd should be listening here if named is configured to
 log through it
  
 In order for your Bind daemon to work properly it needs permission in the named files.  This is an easy task since the configuration files are always at /etc/named/
 .  Take into account that it only needs read-only access to the zone files, unless it is a secondary or cache name server.  If this is your case you will have to give read-write permissions to the necessary zones (so that zone transfers from the primary server work).
  dev/log - syslogd should be listening here
dev/null
etc/bind/named.conf 
etc/localtime
etc/group - with only a single line: "named:x:GID:"
etc/ld.so.cache - generated with ldconfig 
lib/ld-2.3.6.so
lib/libc-2.3.6.so
lib/ld-linux.so.2 - symlinked to ld-2.3.6.so
lib/libc.so.6 - symlinked to libc-2.3.6.so
sbin/ldconfig - may be deleted after setting up the chroot
sbin/named-xfer - if you do name transfers
var/run/
  
 And modify also syslogd
 listen on $CHROOT/dev/log
 so the named server can write syslog entries into the local system log.
 If you want to avoid problems with dynamic libraries, you can compile bind statically.  You can use apt-get
 for this, with the source
 option.  It can even download the packages you need to properly compile it.  You would need to do something similar to:
  $ apt-get source bind
# apt-get build-dep bind
$ cd bind-8.2.5-2
 (edit src/port/linux/Makefile so CFLAGS includes the '-static'
 option)
$ dpkg-buildpackage -rfakeroot -uc -us
$ cd .
# dpkg -i bind-8.2.5-2*deb
  
   Translation(s) 
 :  Deutsch 
 -  English 
 -  Español 
 -  Français 
 -  Italiano 
 
  
  
  Basic Installation 
  Configuration 
  Mounting pseudo filesystems 
  Adding / removing packages 
  Usage 
  Copy and Paste 
 Basic Installation
 Building a "chroot" is very easy in Debian.  
  
 You will need:  
 Install the required packages  
        
# apt install debootstrap  
 Choose a location  
        
# mkdir -p /srv/chroot/debian  
 Build the chroot  
  
 Either select a close network mirror manually, use one of the dns based mirrors such as ftp. XX.debian.org where XX is your geographic country code, or use the deb.debian.org CDN which will do this for you automatically.    The deb.debian.org is easier to document and becoming the generally preferred method and is therefore recommended if you don't have your own fast preferred local mirror.    See  http://deb.debian.org/ 
 for documentation and details.  
  
  
        
# debootstrap bullseye /srv/chroot/debian http://deb.debian.org/debian  
 To enter:  
        
# chroot /srv/chroot/debian  
 From this point, the chroot is useful for tasks such as building debian packages in an isolated environment.  For a more advanced debian environment inside the chroot, see below.  
  
 Configuration
 In general, it is necessary to create/edit key configuration points.  
  
 Create a /usr/sbin/policy-rc.d file IN THE CHROOT so that dpkg won't start daemons unless desired.    This example prevents all daemons from being started in the chroot.  
  
        
chroot /srv/chroot/debian
       
cat > ./usr/sbin/policy-rc.d <<EOF
       
#!/bin/sh
       
exit 101
       
EOF
       
chmod a+x ./usr/sbin/policy-rc.d  
 The  ischroot 
 command is buggy and does not detect that it is running in a chroot (  685034 
 ).    Several packages depend upon  ischroot 
 for determining correct behavior in a chroot and will operate incorrectly during upgrades if it is not fixed.    The easiest way to fix it is to replace ischroot with the /bin/true command.  
  
        
dpkg-divert --divert /usr/bin/ischroot.debianutils --rename /usr/bin/ischroot
       
ln -s /bin/true /usr/bin/ischroot  
 Configuring a chroot is relatively static and very specific, it may be possible to dispense with the command "top-level" and directly edit files.  
  
 Users defined in the chroot  
        
/etc/passwd
       
/etc/group  
 Settings network settings in the chroot  
        
/etc/hosts
       
/etc/resolv.conf  
 Mounts filesystems from the underlying host (NOT in the chroot)  
        
/etc/fstab  
 To edit the bash prompt, add an identifier to /etc/debian_chroot.    It's contents get added to $PS1  
  
 Mounting pseudo filesystems
 /proc
 Check the chrooted system the presence of /proc if the chroot is not likely to be fully operational.  A priori, since version debootstrap Debian/Wheezy integrates natively mount /proc and /sys  
        
proc on /proc type proc (rw)
       
sysfs on /sys sysfs kind (rw)  
 /dev/pts
 In this case, the primary system, run the command:  
  
  
        
mount --bind /dev/pts /srv/chroot/stretch/dev/pts  
 Default Configurations
 Generally the file  /etc/fstab 
 might look like this:  
  
        
# grep chroot /etc/fstab
       
/dev /srv/chroot/stretch/dev auto bind 0 0
       
/dev/pts /srv/chroot/stretch/dev/pts auto bind 0 0
       
/proc /srv/chroot/stretch/proc auto bind 0 0  
 Therefore mount on the primary system would be:  
  
  
  
  
  
        
# mount | grep chroot
       
/dev on /srv/chroot/stretch/dev -type none (rw, bind)
       
/dev/pts on /srv/chroot/stretch/dev/pts kind none (rw, bind)
       
/proc on /srv/chroot/stretch/proc type none (rw, bind)  
 Adding / removing packages
 Eliminate unnecessary packages (all depends on the purpose of the chroot)  
        
apt-get install deborphan  
        
deborphan -a  
 And for example  
        
apt-get remove --purge telnet manpages pppconfig ipchains .    
  Complementary 
 list svgalibg1 whiptail  
  
 Add a little comfort  
        
apt-get install emacs23 local mc  
 Usage
 Common examples of chroot usage:  
  
 Update service production by tilting the old service (host machine) to the new (installed in the chroot)  
  
 Securing a service "chrooted" from the host machine (and vice versa)  
  
  
 Copy and Paste
 The above ready for  copy and paste 
 .  
  
 First the part where we set shell variables.  
  
  
  
  
  
  
        
export MCHRMIRROR=http://deb.debian.org/debian
       
export MCHRARCH=i386
       
export MCHRREL=buster
       
export MCHRDIR=/srv/chroot/${MCHRREL}-${MCHRARCH}
       
echo My chroot dir is ${MCHRDIR}  
 From here the further copy and paste stuff, preferable careful.  
  
        
mkdir -p ${MCHRDIR}
       
# next step takes much more time
       
debootstrap --variant=buildd --arch=${MCHRARCH} ${MCHRREL} ${MCHRDIR} ${MCHRMIRROR}
       

       
# prevent that dpkg starts deamons in the chroot environment
       
cat > ${MCHRDIR}/usr/sbin/policy-rc.d <<EOF
       
#!/bin/sh
       
exit 101
       
EOF
       
chmod a+x ${MCHRDIR}/usr/sbin/policy-rc.d
       

       
# in the chroot "hard code" ischroot to true
       
cp ${MCHRDIR}/bin/true ${MCHRDIR}/usr/bin/ischroot
       

       
#
       
cp /etc/hosts ${MCHRDIR}/etc/hosts
       
cp /etc/resolv.conf ${MCHRDIR}/etc/resolv.conf
       

       
# that was what needs be done only once
       

       
# mount stuff, you will need more often
       
mount --bind /dev ${MCHRDIR}/dev
       
mount --bind /dev/pts ${MCHRDIR}/dev/pts
       
mount --bind /proc ${MCHRDIR}/proc
       

       
# you may also need (e.g.  in Rescue mode of DebianInstaller)
       
mount --bind /sys ${MCHRDIR}/sys
       
mount --bind /run ${MCHRDIR}/run
       

       
# Okay  
 # Entering the chroot, leave it with  exit 
  
  
  
  
  
  
        
chroot ${MCHRDIR}
       
# enjoy your new environment
       
# apt install what you need
       
# do the thing you have in mind  
        
[ ! -z ${MCHRDIR} ] && echo my chroot dir is ${MCHRDIR}
       
[ ! -z ${MCHRDIR} ] && umount ${MCHRDIR}/proc
       
[ ! -z ${MCHRDIR} ] && umount ${MCHRDIR}/dev/pts
       
[ ! -z ${MCHRDIR} ] && umount ${MCHRDIR}/dev
       

       
# if you mounted these above
       
[ ! -z ${MCHRDIR} ] && umount ${MCHRDIR}/sys
       
[ ! -z ${MCHRDIR} ] && umount ${MCHRDIR}/run  
  TODO 
 - Clean up from French translation.  
  
 Background
  box IN A 192.168.1.10 
  
  
 Introduction
 Domain Name Service (DNS) is an Internet service that maps IP addresses and fully qualified domain names (FQDN) to one another.  In this way, DNS alleviates the need to remember IP addresses.  Computers that run DNS are called name servers.  Ubuntu ships with BIND (Berkley Internet Naming Daemon), the most widely deployed DNS server.  
  
 This guide is aimed at people looking to learn how to configure and maintain a DNS server, such as for a network (caching name server) or to serve DNS zones for a domain name.  
  
 Installation
 BIND9 is available in the Main repository.  No additional repository needs to be enabled for BIND9.  
  
 Before we begin, you should be familiar with  RootSudo 
 .  
  
 To install the server simply install the  bind9 
 package.    See  InstallingSoftware 
 for details on using package managers.  
  
 A very useful package for testing and troubleshooting DNS issues is the  dnsutils 
 package.    Also, the BIND9 Documentation can be found in the  bind9-doc 
 package.  
  
 BIND9 Configuration Scenarios
 BIND9 can provide many different DNS services.  
  
 Some of the most useful setups are:  
  
 Caching Server
 In this configuration BIND9 will find the answer to name queries and remember the answer for the next query.    This can be useful for a slow internet connection.  By caching DNS queries, you will reduce bandwidth and (more importantly) latency.  
  
 Primary Master Server
 BIND9 can be used to serve DNS records (groups of records are referred to as zones) for a registered domain name or an imaginary one (but only if used on a restricted network).  
  
 Secondary Master Server
 A secondary master DNS server is used to complement a primary master DNS server by serving a copy of the zone(s) configured on the primary server.  Secondary servers are recommended in larger setups.    If you intend to serve a registered domain name they ensure that your DNS zone is still available even if your primary server is not online.  
  
 Hybrids
 You can even configure BIND9 to be a Caching and Primary Master DNS server simultaneously, a Caching and a Secondary Master server or even a Caching, Primary Master and Secondary Master server.  All that is required is simply combining the different configuration examples.  
  
 Stealth Servers
 There are also two other common DNS server setups (used when working with zones for registered domain names), Stealth Primary and Stealth Secondary.  These are effectively the same as Primary and Secondary DNS servers, but with a slight organizational difference.  
  
 For example, you have 3 DNS servers; A, B and C.  
  
 A is the Primary, B and C are secondaries.  
  
 If you configure your registered domain to use A and B as your domain's DNS servers, then C is a Stealth Secondary.  It's still a secondary, but it's not going to be asked about the zone you are serving to the internet from A and B  
  
 If you configure your registered domain to use B and C as your domain's DNS servers, then A is a stealth primary.  Any additional records or edits to the zone are done on A, but computers on the internet will only ever ask B and C about the zone.  
  
 DNS Record Types
 There are lots of different DNS record types, but some of the most common types are covered below.  
  
 Address Records
 The most commonly used type of record.    This record maps an IP Address to a hostname.  
  
        
www IN A 1.2.3.4  
 Alias Records
 Used to create an alias from an existing A record.  You can create a CNAME record pointing to another CNAME record.  But it doubles the number of requests made to the nameserver, thus making it an inefficient way to do so.  
  
        
mail IN CNAME www
       
www IN A 1.2.3.4  
 Mail Exchange Records
 Used to define where email should be sent to and at what priority.  Must point to an A record, not a CNAME.  Multiple MX records can exist if multiple mail servers are responsible for that domain.  
  
        
 IN MX 10 mail.example.com.
       

       
 [.]
       

       
mail IN A 1.2.3.4  
 Name Server Records
 Used to define which servers serve copies of this zone.  It must point to an A record, not a CNAME.  
  
 This is where Primary and Secondary servers are defined.  Stealth servers are intentionally omitted.  
  
        
 IN NS ns.example.com.
       

       
 [.]
       

       
ns IN A 1.2.3.4  
 Configuring BIND9
 BIND9 Configuration files are stored in:  
  
        
/etc/bind/  
        
/etc/bind/named.conf
       
/etc/bind/named.conf.options
       
/etc/bind/named.conf.local  
 Caching Server configuration
 The default configuration is setup to act as a caching server.  
  
 All that is required is simply adding the IP numbers of your ISP's DNS servers.  
  
        
 [.]
       

       
 forwarders {
       
 1.2.3.4;
       
 5.6.7.8;
       
 };
       

       
 [.]  
 (where 1.2.3.4 and 5.6.7.8 are the IP numbers of your ISP's DNS servers)  
  
 Now restart the  bind 
 daemon:  
  
        
sudo /etc/init.d/bind9 restart  
 Testing
 If you installed the  dnsutils 
 package you can test your setup using the  dig 
 command:  
  
        
dig -x 127.0.0.1  
 If all goes well you should see output similar to:  
  
        
; <> DiG 9.4.1-P1 <> -x 127.0.0.1
       
;; global options: printcmd
       
;; Got answer:
       
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13427
       
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
       

       
[.]
       

       
;; Query time: 1 msec
       
;; SERVER: 172.18.100.80#53(172.18.100.80)
       
;; WHEN: Mon Nov 26 23:22:53 2007
       
;; MSG SIZE rcvd: 93  
 The  dig 
 command can also be used to query other domains for example:  
  
        
dig google.com  
 If you "dig" a domain name multiple times you should see a drastic improvement in the  Query time: 
 between the first and second query.    This is due to the server  caching 
 the query.  
  
 Primary Master Server configuration
 In this section BIND9 will be configured as the primary master for the domain  example.com 
 .    Simply replace  example.com 
 with your fully qualified domain name.  
  
 Zone File
 To add a DNS zone to BIND9, turning BIND9 into a Primary Master server, all you have to do is edit  named.conf.local 
 :  
  
        
 [.]
       

       
 zone "example.com" {
       
 type master;
       
 file "/etc/bind/db.example.com";
       
 };
       

       
 [.]  
 Now use an existing zone file as a template:  
  
        
sudo cp /etc/bind/db.local /etc/bind/db.example.com  
 Also, create an  A record 
 for  ns.example.com 
 the name server in this example:  
  
        
;
       
; BIND data file for local loopback interface
       
;
       
$TTL 604800
       
@ IN SOA ns.example.com.  root.example.com.  (
       
 1 ; Serial
       
 604800 ; Refresh
       
 86400 ; Retry
       
 2419200 ; Expire
       
 604800 ) ; Negative Cache TTL
       
;
       
@ IN NS ns.example.com.
       
ns IN A 192.168.1.10
       

       
;also list other computers
       
box IN A 192.168.1.21  
 You must increment the serial number every time you make changes to the zone file.    If you make multiple changes before restarting BIND9, simply increment the serial once.  
  
 Now, you can add DNS records to the bottom of the zone.  
  
  Tip 
 : Many people like to use the last date edited as the serial of a zone, such as   2005010100  
 which is yyyymmddss (where s is serial)  
  
 Once you've made a change to the zone file BIND9 will need to be restarted for the changes to take effect:  
  
        
sudo /etc/init.d/bind9 restart  
 Reverse Zone File
 Now that the zone file is setup and resolving names to IP Adresses a Reverse zone is also required.    A Reverse zone allows DNS to convert from an address to a name.  
  
        
zone "1.168.192.in-addr.arpa" {
       
 type master;
       
 notify no;
       
 file "/etc/bind/db.192";
       
};  
  Note: 
 replace  1.168.192 
 with the first three octets of whatever private network you are using.    Also, name the zone file  db.192 
 in the example appropriately.  
  
 Now create the  db.192 
 file:  
  
        
sudo cp /etc/bind/db.127 /etc/bind/db.192  
 Next edit  /etc/bind/db.192 
 changing the basically the same options as in  /etc/bind/db.example.com 
 :  
  
        
;
       
; BIND reverse data file for local loopback interface
       
;
       
$TTL 604800
       
@ IN SOA ns.example.com.  root.example.com.  (
       
 2 ; Serial
       
 604800 ; Refresh
       
 86400 ; Retry
       
 2419200 ; Expire
       
 604800 ) ; Negative Cache TTL
       
;
       
@ IN NS ns.
       
10 IN PTR ns.example.com.
       

       
; also list other computers
       
21 IN PTR box.example.com.    
 The serial number in the reverse zone needs to be incremented on each changes as well.    For each  A record 
 you configure in  /etc/bind/db.example.com 
 you need to create a  PTR record 
 in  /etc/bind/db.192 
 .  
  
 After creating the reverse zone file restart  bind9 
 :  
  
        
sudo /etc/init.d/bind9 restart  
 Testing
 You should now be able to ping  example.com 
 and have it resolve to the host configured above:  
  
        
ping example.com  
 You can also use the  named-checkzone 
 utility that is part of the  bind9 
 package:  
  
        
named-checkzone example.com /etc/bind/db.example.com  
        
named-checkzone 1.168.192.in-addr.arpa.  /etc/bind/db.192  
 This is a great way to make sure you haven't made any mistakes before restarting  bind9 
 .  
  
 You can use the  dig 
 utility to test the reverse zone as well as the new domain name:  
  
        
dig 1.168.192.in-addr.arpa.  A XFR  
 You should see output resolving  1.168.192.in-addr.arpa. 
 to your nameserver.  
  
 Secondary Master Server configuration
 Once a Primary Master has been configured a Secondary Master is needed in order to maintain the availability of the domain should the Primary become unavailable.  
  
 First, on the primary master server, the zone transfer needs to be allowed.    Add the  allow-transfer 
 option to the sample Forward and Reverse zone definition in  /etc/bind/named.conf.local 
 :  
  
        
 [.]
       

       
 zone "example.com" {
       
 type master;
       
 file "/etc/bind/db.example.com";
       
 allow-transfer { @ip_secondary; };
       
 };
       

       
 [.]
       

       
 zone "1.168.192.in-addr.arpa" {
       
 type master;
       
 notify no;
       
 file "/etc/bind/db.192";
       
 allow-transfer { @ip_secondary; };
       
 };
       

       
 [.]  
        
 [.]
       

       
 zone "example.com" {
       
 type slave;
       
 file "/var/cache/bind/db.example.com";
       
 masters { @ip_master; };
       
 };
       

       
 [.]
       

       
 zone "1.168.192.in-addr.arpa" {
       
 type slave;
       
 file "/var/cache/bind/db.192";
       
 masters { @ip_master; };
       
 };
       

       
 [.]  
 Restart the server, and in  /var/log/syslog 
 you should see something similar to:  
  
        
syslog.5.gz:May 14 23:33:53 smith named[5064]: zone example.com/IN: transferred serial 2006051401
       
syslog.5.gz:May 14 23:33:53 smith named[5064]: transfer of 'example.com/IN' from 10.0.0.202#53: end of transfer
       
syslog.5.gz:May 14 23:33:35 smith named[5064]: slave zone "1.168.192.in-addr.arpa" (IN) loaded (serial 2006051401)  
  Note: 
 A zone is only transfered if the  Serial Number 
 on the Primary is larger than the one on the Secondary.  
  
 Testing
 Testing the Secondary Master can be done using the same methods as the Primary.    Also, you could shutdown BIND9 on the Primary then try pinging  example.com 
 from a host configured to use the Secondary as well as the Primary for name resolution.    If all goes well the Secondary should resolve  example.com 
 .  
  
 Chrooting BIND9
 To chroot BIND9, simply create a chroot enviroment for it and add the additional configuration below  
  
 The Chroot Enviroment
        
$ sudo mkdir -p /chroot/named
       
$ cd /chroot/named
       
$ sudo mkdir -p dev etc/namedb/slave var/run  
 Set permissions for chroot environment  
  
        
$ sudo chown root:root /chroot
       
$ sudo chmod 700 /chroot
       
$ sudo chown bind:bind /chroot/named
       
$ sudo chmod 700 /chroot/named  
 Create or move the bind configuration file.  
  
        
$ sudo touch /chroot/named/etc/named.conf  
        
$ sudo cp /etc/bind/named.conf /chroot/named/etc  
        
$ sudo chown bind:bind /chroot/named/etc/namedb/slave  
        
zone "my.zone.com." {
       
 type slave;
       
 file "slaves/my.zone.com.dns";
       
 masters {
       
 10.1.1.10;
       
 };
       
};  
 Create the devices BIND9 requires  
  
        
$ sudo mknod /chroot/named/dev/null c 1 3
       
$ sudo mknod /chroot/named/dev/random c 1 8  
        
$ sudo chown bind:bind /chroot/named/var/run  
 BIND9's Configuration
 Edit the bind startup options found in /etc/default/bind9.    Change the line the reads:  
  
        
/etc/default/bind9:
       

       
OPTIONS="-u bind"  
 So that it reads  
  
        
/etc/default/bind9:
       

       

       
OPTIONS="-u bind -t /chroot/named -c /etc/named.conf"  
 The -t option changes the root directory from which bind operates to be /chroot/named.    The -c option tells Bind that the configuration file is located at /etc/named.conf.    Remember that this path is relative to the root set by -t.  
  
  
 The named.conf file must also recieve extra options in order to run correctly below is a minimal set of options:  
  
        
/chroot/named/etc/named.conf:
       

       
options {
       
 directory "/etc/namedb";
       
 pid-file "/var/run/named.pid";
       
 statistics-file "/var/run/named.stats";
       
};  
 Ubuntu's syslod Daemon Configuration
        
/etc/init.d/sysklogd:
       

       

       
 [.]
       

       
SYSLOGD="-u syslog -a /chroot/named/dev/log"
       

       
 [.]  
 (Author Note: Check this config)  
  
  
 Restart the syslog server and BIND9
        
$ sudo /etc/init.d/sysklogd restart
       
$ sudo /etc/init.d/bind9 restart  
 At this point you should check /var/log/messages for any errors that may have been thrown by bind.  
  
 Starting, Stopping, and Restarting BIND9
        
$ sudo /etc/init.d/bind9 start  
 To stop it, use :  
  
        
$ sudo /etc/init.d/bind9 stop  
 Finally, to restart it, run  
  
        
$ sudo /etc/init.d/bind9 restart  
 Status
 To check the status of your BIND9 installation:  
  
        
$ host localhost  
        
$ dig @localhost  
 (where localhost is the system you are setting BIND9 up on.  If not localhost, use the appropriate IP number.)  
  
 Logging
  BIND9 
 has a wide variety of logging configuration options available.    There are two main options to BIND9 logging the  channel 
 option configures where logs go, and the  category 
 option determines what to log.  
  
 If no  logging 
 option is configured for the default option is:  
  
        
logging {
       
 category default { default_syslog; default_debug; };
       
 category unmatched { null; };
       
};  
 Next we will configure BIND9 to send  debug 
 messages related to DNS queries to a separate file.  
  
 Channel Option
        
logging {
       
 channel query.log {
       
 file "/var/log/query.log";
       
 // Set the severity to dynamic to see all the debug messages.
       
 severity dynamic;
       
 };
       
};