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` 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.