diff options
Diffstat (limited to 'debian/README.Debian')
| -rw-r--r-- | debian/README.Debian | 178 |
1 files changed, 178 insertions, 0 deletions
diff --git a/debian/README.Debian b/debian/README.Debian new file mode 100644 index 0000000..297c52a --- /dev/null +++ b/debian/README.Debian @@ -0,0 +1,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 +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. |