Adding debian version 1:9.11.5.P4+dfsg-5.1+deb10u7.debian/1%9.11.5.P4+dfsg-5.1+deb10u7

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

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.