CHAPTER 10  DNS SECURE CONFIGURATIONS 
280 
• named.conf: This file should be treated as confidential because it contains 
information about the style of your configuration that may assist an attacker; it 
frequently contains other interesting information, such as IP addresses, that may 
be used to launch spoofing and other attacks. The named.conf file should never 
contain key clauses as a matter of policy, including those used for rndc access. 
Instead, key clauses should be maintained in separate files in a separate directory 
and included in the named.conf file (using an include statement). If view clauses 
are being used, then as a minimum those containing private information for use 
by a stealth configuration (see Chapter 4) should also be contained within 
separate files and included in the named.conf file. If the organizational policy 
allows zone clauses or parts of the named.conf file to be controlled or edited by end 
users or more than one user, then these parts should be saved as separate files in 
separate directories. In this way, appropriate permissions can be applied and then 
the files can be included in the final named.conf file. It is worth noting here that 
trusted-keys clauses contain only public keys, which are not sensitive 
information, unlike key clauses, which contain shared secrets and are extremely 
sensitive. The requirement for trusted-keys clauses is to prevent write corruption 
rather than to prevent unauthorized reading, as is the case for key clauses. 
• Included files: Each file included in the named.conf file can have different 
permissions applied to it. The policy should be to categorize the type of file and 
the required access, and then separate the files into directories whereby directory-
level permissions can be applied, rather than fooling around with individual files. 
/var/named/keys and private views in a directory called /var/named/views. Any 
private zone clauses could be saved in, say, /var/named/zone-private. Generally 
editable zone clauses could be saved in the home directory of the user who is 
allowed to edit it. Each such directory can be assigned appropriate permissions. 
• Zone files: Zone files typically contain public information, so there seems little 
point in protecting them (other than from global write permission). However, if a 
view clause-based stealth system is being used, then the zone files on the private 
side of the configuration will contain sensitive data and thus will require separate 
treatment. Again, it is prudent to separate private zone files into a separate 
directory such as /var/named/master/private. Zone files that may be edited by 
users can be placed in the respective home directories with appropriate user 
permissions, or you can place them in a /var/named/master/ddns directory and 
allow dynamic updates. Finally, slave zones in, say, /var/named/slave require 
write permission for BIND. 
• PID file: This is normally written to /var/run/named.pid or 
/var/run/named/named.pid. Although it contains sensitive information (the 
Process Identifier of the named daemon), the information can only be used by root. 
If you’re faced with a root exploit, the PID files are among the last items to be 
scripts (start, stop, restart, and so on) that make use of it. 
• Log files: This book configures the logs to be written to the /var/log/named 
directory mostly for convenience rather than security. In general, the log does not 
contain sensitive information and does not require special handling. However, if a 
view clause is being used in a stealth configuration, the log—depending on 
options—may contain sensitive information relating to private IPs and should be 
protected. 
Add and delete pages from pdf - insert pages into PDF file in C#.net, ASP.NET, MVC, Ajax, WinForms, WPF
Guide C# Users to Insert (Empty) PDF Page or Pages from a Supported File Format
add page numbers to a pdf document; add pages to pdf in preview
Add and delete pages from pdf - VB.NET PDF Page Insert Library: insert pages into PDF file in vb.net, ASP.NET, MVC, Ajax, WinForms, WPF
Easy to Use VB.NET APIs to Add a New Blank Page to PDF Document
add page numbers to pdf online; add pdf pages to word document
CHAPTER 10 ■ DNS SECURE CONFIGURATIONS 
281
• rndc files: If using rndc, keep in mind that the rndc.conf file (see Chapter 9) and
especially any files containing keys, including the default rndc.key file, contain
extremely sensitive information and need to be protected. 
• Journal files: A zone file is normally a read-only file from BIND’s perspective. If
Dynamic Update (DDNS) is being used, then updates are written to a binary .jnl
file for each zone and only periodically written to the zone file. For public zone
files, such information is not sensitive; for private zone files, appropriate
permissions are required. Once DDNS is invoked for a zone, special procedures
are generally required to edit the zone files manually. Therefore, permissions can
be made tight. To reflect these permissions, zone files that will use DDNS could be
placed in a directory such as /var/named/master/ddns. 
Before building a permission strategy, let’s look at how BIND is run. BIND 9 can run in three
possible ways: 
Run BIND as root: This is a dangerous thing to do. It normally requires additional
work to override the options defined in most packaged BIND installations. This
method of running BIND 9 is not recommended and will not be discussed further. 
Run BIND under a unique (nonroot) UID (Linux, Unix, or BSD) or user account
(Windows): This method uses the -u command line argument of BIND (see
Chapter 12) and is the standard method used by most packaged installations on
Linux, BSD, and Windows (including the Ubuntu 10.04 Server installation
described in Chapter 6). The User ID (UID) is typically named for Linux/UNIX, bind
if you are running FreeBSD, and the user account is named for Windows. 
Run BIND in a sandbox or chroot jail: FreeBSD 8.x default installations use this
mode of operation which uses the -t command line argument of BIND (see
Chapter 12). Many Linux distributions provide a bind-chroot RPM that can be
applied after BIND has been installed to add the necessary directories and scripts
to apply the appropriate permissions. With Ubuntu 10.04 Server no explicit chroot
package exists and the process is entirely manual though schroot (apt-get
install schroot) could be used for this purpose. 
The last two methods are described in detail in the “Running BIND 9 as Nonroot” Section. Table 10–
2 shows the permissions that lock down the various files to their minimum requirements. Before
considering the required file permissions, it’s necessary to understand the various stages BIND adopts
during its initialization sequence. When BIND 9 is loaded, it runs as user root because it requires certain
privileges—notably the ability to allocate and bind to its normal-but-privileged port number of 53, and if
rndc is permitted, also to port 953. During this phase, BIND 9 reads all configuration (and include) files
as well as zone files (and $INCLUDE files) and logs any failures to syslogd. On completion of this process, it
then issues a suid() call (change user name) to the user name defined in the -u command line
argument. Only then does it proceed to write the PID file, log, and any other required files. This structure
lends itself perfectly to tailoring precise file permissions, because read-only files (from BIND’s
perspective) can be set to permissions based on their editing requirements. BIND 9, because it running
as root during its read phase, can read these files in all cases. Table 10–2 illustrates the kind of structure
and flexibility that may be created. This structure may look complex, but it shows the possibilities; also,
once established, it requires little maintenance. 
VB.NET PDF Page Delete Library: remove PDF pages in vb.net, ASP.
In order to run the sample code, the following steps would be necessary. Add necessary references: How to VB.NET: Delete Consecutive Pages from PDF.
adding page numbers to a pdf document; add a page to a pdf in reader
C# PDF Page Delete Library: remove PDF pages in C#.net, ASP.NET
XDoc.PDF enables you to delete PDF page(s) with customized options, including a single page, a series of pages, and random pages to be Add necessary references
adding page numbers to pdf files; add page numbers to pdf files
CHAPTER 10  DNS SECURE CONFIGURATIONS 
282 
Note The preceding sequence is slightly different when running in a chroot jail, which is described in the  “BIND 
9 in a Chroot Jail” section. 
Table 10–2 assumes that BIND 9 runs with a UID of named, editing of secure (but not secret) files is 
done under a nonroot user with a user name of dnsadmin and a group of root /wheel (to allow su 
commands if necessary), and editing of multiuser access files (for example, public zone files and zone 
clauses) is done under a group called dnsusers. The files containing secrets can only be read by BIND 
and edited by root. Files are placed in the directories named under each file type described earlier. The 
home directory of dnsadmin is assumed to be /var/named; for dnsusers, it’s /home/username or similar. In 
Table 10–2, the Permissions column shows the directory permission first, separated from the file 
permissions with a colon (“:”). A question mark (“?”) indicates that this value may be determined by 
other system requirements. The setting of limited permissions on Windows systems is described in 
Chapter 6. 
Table 10–2. Directory and File Permissions 
File/Group 
Typical Location 
user:group 
Permissions 
Notes 
named.conf 
/etc 
dnsadmin:root ? : 0660 
Read-only BIND file. 
dnsadmin can edit. 
Included public 
named.conf 
username home 
directory 
username: 
dnsusers 
0770 : 0660 
Read-only BIND files. 
Permissions allow 
dnsusers group to edit. 
Included key files /var/named/keys
named:named 0400 : 0400 
Read-only BIND file. 
Only root can edit or 
view. 
Included private 
views 
/var/named/views 
dnsadmin:root 0770 : 0660 
Read-only BIND file. 
dnsadmin can edit. 
Private zone 
files—no DDNS 
/var/named/masters
/ private 
dnsadmin:root 0770 : 0660 
Read-only BIND file. 
dnsadmin can edit. 
Private zone files 
with DDNS 
/var/named/masters
/ ddns 
named:root 
0770 :0660 
Read/write for BIND. 
dnsadmin can edit. 
Slave zone files 
/var/named/slaves 
named:root 
0770 : 0660 
Read/write for BIND. 
dnsadmin can edit if 
required. 
Public zone files 
username home 
directory 
username: 
dnsusers 
0770 : 0660 
Allows dnsusers group to 
edit. These files can’t be 
dynamically updated. 
C# PDF File & Page Process Library SDK for C#.net, ASP.NET, MVC
C# Page: Insert PDF pages; C# Page: Delete PDF pages; C# Read: PDF Text Extract; C# Read: PDF Image Extract; C# Write: Insert text into PDF; C# Write: Add Image
add remove pages from pdf; adding a page to a pdf in preview
C# PDF insert image Library: insert images into PDF in C#.net, ASP
C#.NET PDF SDK - Add Image to PDF Page in C#.NET. How to Insert & Add Image, Picture or Logo on PDF Page Using C#.NET. Add Image to PDF Page Using C#.NET.
add page numbers to pdf document in preview; adding page to pdf
CHAPTER 10 ■ DNS SECURE CONFIGURATIONS 
283
File/Group 
Typical Location 
user:group 
Permissions 
Notes 
named.pid 
/var/run/named 
named:named ? : 0664 
Allows access by BIND 
tools/ scripts and root
named.log 
/var/log/named 
named:root 
0770 : 0640 
Write access for BIND, 
dnsadmin can read. If not 
using views, wider 
permissions can be set 
depending on local 
policy. 
rndc.conf 
/var/named/rndc 
dnsadmin:root 0770 : 0660 
Allows access by 
dnsadmin group. 
rndc.key 
/var/named/rndc/ke
ys 
named:named 0400 : 0400 
Only root can edit. 
In Table 10–2, FreeBSD users should replace the group root with wheel and named with bind. If the 
local policy is to allow only BIND administrators to touch any BIND-related material, then some of the 
preceding configuration will be unnecessary.  
The named.conf file fragment that would reflect such a strategy could look something like the 
following: 
// named.conf fragment 
include "/var/named/keys/key.clauses"; // single file containing keys 
controls { 
inet 127.0.0.1 allow {localhost;} keys {"rndc-key"}; 
}; 
options { 
.... 
}; 
include "/var/named/views/private-view.clause"; // hidden private view 
view "public-view" { 
include "/home/firstuser/zone.clause"; 
zone "example.com" in { 
type master; 
file "var/named/masters/ddns/example.net"; 
// key clause referenced below will be in 
// /var/named/keys/keys.clause above 
allow-update {key "example.net";};  
}; 
}; 
VB.NET PDF Password Library: add, remove, edit PDF file password
passwordSetting.IsAssemble = True ' Add password to PDF file. These two demos will help you to delete password for an encrypted PDF file.
add page to pdf in preview; add page to pdf
C# PDF Sticky Note Library: add, delete, update PDF note in C#.net
C#.NET PDF SDK - Add Sticky Note to PDF Page in C#.NET. Able to add notes to PDF using C# source code in Visual Studio .NET framework.
add page to pdf online; adding page numbers in pdf
CHAPTER 10  DNS SECURE CONFIGURATIONS 
284 
Note  In Table 10–2 keys are shown in /var/named/keys. When more than one zone is present and especially 
when used with DNSSEC, an alternative method is to maintain zone specific keys using a structure such as 
/var/named/zone-name/keys; see Chapter 11 for more details. Directory and file permissions would stay the same 
in this case. 
Running BIND 9 As Nonroot 
Most packaged BIND systems, for instance RPMs, Ubuntu/Debian packages, and FreeBSD ports, install 
BIND to run with a unique (nonroot) UID—typically named on Linux and Windows and bind on FreeBSD. 
This section describes how to configure your system if BIND is not installed and configured to run with a 
unique UID and how to set permissions to lock down the files. Even if your BIND system has been 
installed to run under a unique UID, you may still want to look at and set appropriate file permissions, 
especially on the more sensitive files. If BIND is running on your system, its status can be interrogated by 
issuing the following command: 
# ps aux |grep named  
It returns something like the following: 
named  36120  0.0  0.9  5372 4376  ??  Is    1:02PM   0:00.11 named -u named 
This output shows that the daemon named is running under the UID named (the first named in the 
line), which is initiated by the -u
named is running as root indicated by the first root in the line and the absence of a -u argument: 
root  36120  0.0  0.9  5372 4376  ??  Is    1:02PM   0:00.11 named 
Action should be taken immediately to change this state, as described in the following section. 
Setting the Run Time UID of BIND 
To run BIND under its own UID, you need to create a user and group for the named daemon. By 
convention this is normally named (or bind under FreeBSD). This book uses named throughout, but you 
can change it to any appropriate value (for example, dns) if you wish. First, confirm that you do not 
already have an existing account by using the following command: 
# id named 
uid=2s5(named) guid=25(named) groups=25(named) 
The preceding response indicates the UID already exists. If the user account does not exist, the 
following response is returned: 
id: named: no such user 
Try again with id bind
follows: 
# groupadd -r named 
VB.NET PDF insert image library: insert images into PDF in vb.net
with this sample VB.NET code to add an image to textMgr.SelectChar(page, cursor) ' Delete a selected As String = Program.RootPath + "\\" output.pdf" doc.Save
add page numbers to pdf reader; add page numbers to pdf using preview
C# PDF Password Library: add, remove, edit PDF file password in C#
passwordSetting.IsAssemble = true; // Add password to PDF file. These C# demos will help you to delete password for an encrypted PDF file.
add page numbers to a pdf; add pages to pdf acrobat
CHAPTER 10 ■ DNS SECURE CONFIGURATIONS 
285
This command adds the group named with the first free system account group (the -r argument). The 
presence of the group can be confirmed with the command vigr, which displays and allows editing of 
the list of groups in the system (use :q! to exit vigr without making changes). 
Now add the system account named using the following command: 
If the -c argument (a comment) contains a space, it must be enclosed in quotes as shown. The -d 
/var/named is the default directory at login and is required but isn’t used because this is a system account 
without a login or password. The -s /sbin/nologin argument is the Linux/BSD default for a no-shell 
account, The -g named argument defines the initial group to be used by the account and references the 
named group you just created. useradd requires that the group named exists, so always define groups 
before users. The -r argument defines this to be a system account (typically with a UID < 500 for Linux 
and < 1000 for FreeBSD) with an account name of named. 
Setting Permissions for the UID 
You now set up and create the permissions for the various essential files. Assume that the user account 
dnsadmin has already been established as a normal login user account using your favorite tool and is a 
member of the root group to allow su commands to be issued if required.  
Note Some of the following permissions differ from those defined in Table 10–2 because they are applied to a 
directory and are typically intended to allow inspection of file properties. Specific files within the directory may be set to 
the values defined in Table 10–2
To create and set permissions for run time write files (log and PID), use the following commands: 
# cd /var/log 
# mkdir named 
# touch named/example.log 
# chown named:dnsadmin named/* 
# chmod 0660 named/* 
# cd /var/run 
# mkdir named 
# touch named/named.pid 
# chown named:named/* 
# chmod 0664 named/* 
The following commands all assume that the various directories have been created. If this is not the 
case, then a preceding mkdir dirname command should be issued, as shown in the preceding command 
sequence. Set permissions on any keys directory, as shown in the following commands: 
# cd /var/named 
# chown named:named keys/* 
# chmod 04000 keys/* 
Set permissions on any private zone files: 
# cd /var/named 
# chown -R dnsadmin:root master/private/* 
CHAPTER 10  DNS SECURE CONFIGURATIONS 
286 
# chmod -R 0660 master/private/* 
Set permissions on any DDNS zone files: 
# cd /var/named 
# chown -R named:root masters/ddns/* 
# chmod -R 0660 masters/ddns 
Set permissions on any private-view include files: 
cd /var/named 
chown -R dnsadmin:root views/* 
chmod -R 0660 views/* 
Secure any rndc key files: 
# cd /var/named 
# chown -R named:named rndc/* 
# chown -R 0660 rndc/* 
Secure the named.conf and rndc.conf files: 
# cd /etc 
# chown dnsadmin:root named.conf 
# chmod 0660 named.conf 
# chown dnsadmin:root rndc.conf 
# chmod 0660 rndc.conf 
Finally, to run BIND, use the following command: 
# /usr/sbin/named -u named 
Now verify that BIND is loaded and running using the following command: 
# ps aux |grep named 
If it isn’t loaded and running, inspect syslog using the following command: 
vi + /var/log/messages 
Alternatively, you can use a command such as tail /var/log/messages to display the last ten lines 
of the file if there isn’t much syslog traffic. Then, verify that BIND has loaded the various zones by 
inspecting the BIND log file: 
# cat /var/log/named/named.log 
zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700 
zone example.com/IN: loaded serial 2010121500 
zone localhost/IN: loaded serial 2002022401 
running 
zone example.com/IN: sending notifies (serial 2010121500) 
To ensure that BIND starts at boot time, you need to create a script that you have chosen to call 
named in the startup directory (for Linux, normally /etc/rc.d/init.d, or /etc/rc.d for FreeBSD). Such a 
script would look like the following code, which is a simplified version of the current scripts being used 
on Fedora Core. It provides start, stop, and restart services only: 
#!/bin/sh 
# named           This shell script takes care of starting and stopping 
#                 named under its own (non-root) UID. 
CHAPTER 10 ■ DNS SECURE CONFIGURATIONS 
287
# Source function library. 
. /etc/rc.d/init.d/functions 
# Source networking configuration. 
. /etc/sysconfig/network 
# Check that networking is up. 
[ ${NETWORKING} = "no" ] && exit 0 
[ -f /usr/sbin/named ] || exit 0 
# See how we were called. 
case "$1" in 
start) 
# Start daemons. 
echo -n "Starting named: " 
daemon /usr/sbin/named -u named 
echo 
;; 
stop) 
# Stop daemons. 
echo -n "Shutting down named: " 
killproc named 
echo 
;; 
restart) 
$0 stop 
$0 start 
exit $? 
;; 
*) 
echo "Usage: named {start|stop|restart}" 
exit 1 
esac 
exit 0 
This script must then be linked to the normal run level(s) used, such as run level 3 (non-X11) and 5 
(X11). The default run level is normally defined in /etc/inittab by a line that looks something like this: 
id:3:initdefault: 
For the preceding example, you would link the script to the appropriate rc.d run level initialization 
sequence, which for run level 3 would be as follows: 
# ln /etc/rc.d/init.d/named /etc/rc.d/rc3.d/S68named 
# ln /etc/rc.d/init.d/named /etc/rc.d/rc3.d/K68named 
# /etc/rc.d/init.d/named restart 
The equivalent startup process for FreeBSD users requires adding the following lines to the 
/etc/rc.conf file: 
CHAPTER 10  DNS SECURE CONFIGURATIONS 
288 
named_enable="YES"  # Run named, the DNS server (or NO). 
named_program="/usr/sbin/named"  # assumes a base installation. 
named_flags="-u bind"   # Flags for named 
To be absolutely certain that everything is working while it is still fresh in your mind, the server 
ideally should be rebooted and named confirmed to be running successfully with a command such as 
this: 
# ps aux|grep named 
named  36120  0.0  0.9  5372 4376  ??  Is    1:02PM   0:00.11 named -u named 
Although the preceding process may appear to involve a number of steps, it offers the flexibility of 
being able to control precisely and flexibly the editing permissions of the various files and file groups 
used in the operation of a BIND-based DNS system. Running BIND in a chroot jail (or sandbox) offers an 
alternate strategy and is described in the following section. 
BIND 9 in a Chroot Jail 
The terms chroot jail or chroot cage (now frequently referred to as a sandbox) are named from the system 
call chroot("/base/directory");
read or write outside the base directory. All referenced files and paths within the chrooted application 
/var/named/chroot and the 
application accesses a file called /etc/named.conf, then the full path is translated to be 
/var/named/chroot/etc/named.conf. When running BIND, the -t /base/directory command line 
argument indicates that BIND should run chrooted and defines the base directory to be used. In a chroot 
environment, both the -t and -u (BIND UID) arguments must be present to provide a secure 
environment.  
Most OS distributions provide a packaged method of running BIND in a chroot jail. The following 
sections define using such a package for both Linux (Fedora Core) and FreeBSD 8.x. Ubuntu Server 10.04 
does not provide a chroot package though BIND9 packages may be run in a schroot system. In the case 
of Ubuntu, and any other distribution which does not provide a standard package, chroot jails must be 
manually configured as described below. 
Fedora Core
  
Package 
DNS may be run in a chroot jail on Fedora Core in one of two ways: 
• 
caching name server installation by default. 
• Installing the bind-chroot RPM (for FC 13 this was bind-chroot-9.7.2-
1.P2.fc13.i686.rpm). 
In the preceding cases, the process is the same because the install process also runs the bind-chroot 
RPM. The chroot RPM does the following: 
• It creates the chroot base directory as /var/named/chroot. 
• The following directories are added under /var/named/chroot: etc, var/named, 
var/run/named, and /dev (containing only null and random). 
• Relevant files are copied from the corresponding directories. For instance, 
/etc/named.conf is copied to /var/named/chroot/etc/named.conf, and ownership 
of the chroot directories is set to root:named with permissions of 0640. 
CHAPTER 10 ■ DNS SECURE CONFIGURATIONS 
289
• The startup script (in /etc/rc.d/init.d/named) is modified to add the argument -t 
/var/named/chroot to invoke the chroot feature. 
The Fedora Core default configuration uses syslogd. If a log file is required, then an appropriate 
directory must be created. For instance, assume you’re creating a log file using the following fragment: 
logging{ 
channel normal_log { 
file "/var/log/named/normal.log" versions 3 size 2m; 
severity error; 
print-time yes; 
print-severity yes; 
print-category yes; 
}; 
.... 
In this case, a directory /var/named/chroot/var/log/named is required with write permission for the 
named UID. 
FreeBSD 8.x 
The installation of DNS on FreeBSD 8.x creates a chroot installation by default with a chroot base of 
/var/named. The installation performs the following tasks: 
• Creates the directory /var/named/etc/namedb and links it to /etc/namedb (by 
directory). Thus, going to the normal location for these files (etc/namedb) follows 
the link to the chroot location. 
• Additionally, the following directories are created under /var/named: var/dump, 
var/stats, var/run/named, and var/log (with a default file name of 
named.security.log). Ownership is bind:bind for the directories, and world read 
permissions are set on all files. 
• The file /etc/defaults/rc.conf contains the defaults, as shown in the following 
fragment: 
# named.  It may be possible to run named in a sandbox, man security for 
# details. 
named_enable="YES"  # Run named, the DNS server (or NO). 
named_flags="-u bind"   # Flags for named 
named_pidfile="/var/run/named/pid" # Must set this in named.conf as well 
named_chrootdir="/var/named" # Chroot directory (or "" not to auto-chroot it) 
named_chroot_autoupdate="YES" # Automatically install/update chrooted 
# components of named. See /etc/rc.d/named. 
named_symlink_enable="YES" # Symlink the chrooted pid file 
• 
As always, if changes are required to this file, they should be made to 
/etc/rc.conf, which overrides the equivalent value in /etc/defaults/rc.conf. 
Documents you may be interested
Documents you may be interested