summaryrefslogtreecommitdiffstats
path: root/debian/README.Debian
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--debian/README.Debian178
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.