179 lines
7.7 KiB
Plaintext
179 lines
7.7 KiB
Plaintext
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
|
|
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` <pot@gnu.org> 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.
|