-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathbind9_9.10.2-P2-0~ppa1trusty1_README.Debian
178 lines (134 loc) · 7.73 KB
/
bind9_9.10.2-P2-0~ppa1trusty1_README.Debian
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
DNSSEC validation turned on by default as of BIND 9.8.1
-------------------------------------------------------
As of version 9.8.1.dfsg-1, BIND ships with DNSSEC validation turned on
by default. As the keys get changed over time, this means that a fresh
install of BIND will require that the admin manually upgrade bind.keys
to account for the change, before BIND will be able to resolve hosts in
DNSSEC validated zones.
Upgrading from BIND 8.X:
-----------------------
If you are upgrading an authoritative server from BIND 8.X, please install
the bind9-doc package and read /usr/share/doc/bind9-doc/misc/migration.gz,
which contains a set of notes from the BIND maintainers on what changed
that is likely to need your attention during an upgrade.
Upgrading from earlier bind9 packages:
-------------------------------------
If you installed an early version of the Debian bind9 packages, prior to
version 1:9.2.0-2 to be more precise, you may have an /etc/bind/rndc.conf
configuration file still on your system. There's nothing wrong with that,
and if you've explicitly configured keys for using rndc you may well want to
leave things exactly as they are!
However, since 9.2.0 BIND 9.X has supported an rndc.key file that both named
and rndc will read to obtain a shared key for rndc use against a daemon on
the same host. The rndc-confgen program will easily create a suitable key
file. To take advantage of this mechanism, you may want to:
remove the /etc/bind/rndc.conf file
remove the rndc key specification in the /etc/bind/named.conf file
rndc-confgen -r /dev/urandom -a
Alternatively, you can 'purge' the bind9 packages and reinstall them and you
will end up with the new behavior since it is now the default.
This is more secure than using a static key that isn't generated on a per-host
basis, and is an easy alternative to more complex key schemes if you only need
to use rndc to talk to named on the same host.
Known Issues:
------------
I've had a report that lwresd, at least, fails to work with some recent 2.5
kernels. If you see something in your logs like
loading configuration from '/etc/bind/lwresd.conf'
none:0: open: /etc/bind/lwresd.conf: permission denied
Try rebuilding with --disable-linux-caps added to the configure call in the
rules file. I'm hoping this is a temporary problem in the 2.5 kernel series,
but we'll see.
Configuration Schema:
--------------------
The Debian BIND package ships with a config that will work for the majority
of leaf servers with no user input required.
The named configuration file named.conf is located in /etc/bind, so that all
static configuration files relating to bind are in one place. If you really
really don't want named.conf in /etc/bind, then the best way to handle it is
probably to replace /etc/bind/named.conf with a symlink to the location you
want to use. You could also use an option to named in the init.d script,
but that only works for named, not for things like ndc.
Zone data files for the root servers, and the forward and reverse localhost
zones are also provided in /etc/bind.
The working directory for named is now /var/cache/bind. Thus, any transient
files generated by named, such as database files for zones the daemon is
secondary for, will be written to the /var filesystem, where they belong.
To make this work, the named.conf provided uses explicitly fully-qualified
pathnames to reference the files in /etc/bind.
Unlike previous BIND packages for Debian, the named.conf and provided db.*
files are tagged as conffiles. Thus, if you just want a "caching mostly"
server configuration for a server that does not need to be authoritative for
anything else, you can run the provided configuration as-is. If you want to
hack on named.conf, or even the init.d fragment, you can feel free to. Future
package upgrades will treat your configuration changes sanely, as all Debian
packages should.
While you are free to craft whatever structure you wish for servers which need
to be authoritative for additional zones, what we suggest is that you put the
db files for any zones you are master for in /etc/bind (perhaps even in a
subdirectory structure depending on complexity), using full pathnames in the
named.conf file. Any zones you are secondary for should be configured in
named.conf with simple filenames (relative to /var/cache/bind), so the data
files will be stored in BIND's working directory (defaults to /var/cache/bind).
Zones subject to automatic updates (such as via DHCP and/or nsupdate) should be
stored in /var/lib/bind, and specified with full pathnames.
Running Chroot'ed:
-----------------
Several users have asked for Debian BIND to run in a "chroot jail". There are
various issues associated with making this the default configuration for the
package in Debian. In the meantime, reasonable instructions on how to do
this yourself are available on the web from:
http://www.tldp.org/HOWTO/Chroot-BIND-HOWTO.html
Running Non-Root:
-----------------
Recent versions of named can be invoked with options that specify a non-root
user and/or group for named. Read the named man page for more information.
Note that when running named as a user other than root, it will not be able
to find new interfaces that appear dynamically, such as during a PCMCIA card
insertion, or if you're running some flavors of IPSEC and/or IP over IP
tunnels. If you cannot live with those limitations, feel free to edit the
/etc/init.d/bind9 script to change the invocation of named.
The default is now to run as the user 'bind' (which is automatically created
in the group 'bind', if it doesn't exist), unless named.conf has been changed.
To change this, edit /etc/default/bind9
Please note that 'ndc restart' doesn't honor all the original command line
options to named, so we explicitly don't use it in the init.d script provided
with the package, and you should be careful about using it if you decide to
run named non-root.
PPP Control Script:
-----------------
Unfortunately, 'ndc reload' will not honor any command line options that were
fed to named on the initial invocation. If you can live with that, and
want to wiggle your DNS configuration when your PPP link goes up or down, the
following script fragment from Francesco Potorti` <[email protected]> may be helpful
to you:
I suggest adding this as bot /etc/ppp/ip-up.d/bind and
/etc/ppp/ip-down.d/bind:
================================================================
#!/bin/sh
if [ -x /usr/sbin/ndc -a -x /usr/sbin/named ]
then
/usr/sbin/ndc reload > /dev/null
fi
================================================================
This should cause no harm in any case, and should be helpful in these
cases:
- you configure bind as a forwarder. When ppp is down, it cannot access
the network. As soon as ppp is up, it is forced by the script to try
again, and it succeeds.
- someone writes a clever script that, coupled with the `usepeerdns'
command of pppd, makes a forwarding-only bind use the right servers by
rewriting the configuration file after ppp goes up. Then the script
above makes bind reload the configuration.
Now, someone should write that clever script :-)
By the way, this is a badly wanted feature, that should help setting up
a ppp connection automatically. Currently, setting up a ppp connection
is much easier on a windows system than on linux, and there is really no
reason why it should be so, given that all the tools are there.
Apparmor Profile
----------------
If your system uses apparmor, please note that the shipped enforcing profile
works with the default installation, and changes in your configuration may
require changes to the installed apparmor profile. Please see
https://wiki.ubuntu.com/DebuggingApparmor before filing a bug against this
software.