provision: Create instructions for enabling DNS GSS-TSIG updates.

Added code to the python provisioning to create the named.conf file that was
previously generated by the EJS provisioning.

Updated the named.conf template to provide the additional details necessary
to get things working.
(This used to be commit 0b7a6bfcba1b906dc4d461882b4c3fe3c91c44e0)

1 files changed, 108 insertions, 27 deletions

diff --git a/source4/setup/named.conf b/source4/setup/named.conf
index 025788093e..9cf0b48a7c 100644
--- a/source4/setup/named.conf
+++ b/source4/setup/named.conf
@@ -3,35 +3,116 @@
 # the BIND nameserver.
 #
 
-# If you have a very recent BIND, supporting GSS-TSIG, 
-# insert this into options {}  (otherwise omit, it is not required if we don't accept updates)
-tkey-gssapi-credential "DNS/${DNSDOMAIN}";
-tkey-domain "${REALM}";
-
-# You should always include the actual zone configuration reference:
+# You should always include the actual forward zone configuration:
 zone "${DNSDOMAIN}." IN {
-        type master;
-        file "${DNSDOMAIN}.zone";
+	type master;
+	file "${DNSDOMAIN}.zone";
 	update-policy {
-		/* use ANY only for Domain controllers for now */
-		/* for normal machines A AAAA PTR is probbaly all is needed */
-		grant ${HOSTNAME}.${DNSDOMAIN}@${REALM} name ${HOSTNAME}.${DNSDOMAIN} ANY;
+		/*
+		 * A rather long description here, as the "ms-self" option does
+		 * not appear in any docs yet (it can only be found in the
+		 * source code).
+		 *
+		 * The short of it is that each host is allowed to update its
+		 * own A and AAAA records, when the update request is properly
+		 * signed by the host itself.
+		 *
+		 * The long description is (look at the
+		 * dst_gssapi_identitymatchesrealmms() call in lib/dns/ssu.c and
+		 * its definition in lib/dns/gssapictx.c for details):
+		 *
+		 * A GSS-TSIG update request will be signed by a given signer
+		 * (e.g. machine-name$@${REALM}).  The signer name is split into
+		 * the machine component (e.g. "machine-name") and the realm
+		 * component (e.g. "${REALM}").  The update is allowed if the
+		 * following conditions are met:
+		 *
+		 * 1) The machine component of the signer name matches the first
+		 * (host) component of the FQDN that is being updated.
+		 *
+		 * 2) The realm component of the signer name matches the realm
+		 * in the grant statement below (${REALM}).
+		 *
+		 * 3) The domain component of the FQDN that is being updated
+		 * matches the realm in the grant statement below.
+		 *
+		 * If the 3 conditions above are satisfied, the update succeeds.
+		 */
+		grant ${REALM} ms-self * A AAAA;
 	};
 };
 
-# Also, you need to change your init scripts to set this environment variable
-# for named: KRB5_KTNAME so that it points to the keytab generated.
-# In RedHat derived systems such RHEL/CentOS/Fedora you can add the following
-# line to the /etc/sysconfig/named file:
-# export KRB5_KTNAME=${DNS_KEYTAB_ABS}
-#
-# Please note that most distributions have BIND configured to run under
-# a non-root user account.  For example, Fedora Core 6 (FC6) runs BIND as
-# the user "named" once the daemon relinquishes its rights.  Therefore,
-# the file "${DNS_KEYTAB}" must be readable by the user that BIND run as.
-# If BIND is running as a non-root user, the "${DNS_KEYTAB}" file must have its
-# permissions altered to allow the daemon to read it.  In the FC6
-# example, execute the commands:
-# 
-# chgrp named ${DNS_KEYTAB_ABS}
-# chmod g+r ${DNS_KEYTAB_ABS}
+# The reverse zone configuration is optional.  The following example assumes a
+# subnet of 192.168.123.0/24:
+zone "123.168.192.in-addr.arpa" in {
+	type master;
+	file "123.168.192.in-addr.arpa.zone";
+	update-policy {
+		grant ${REALM_WC} wildcard *.123.168.192.in-addr.arpa. PTR;
+	};
+};
+# Note that the reverse zone file is not created during the provision process.
+
+# The most recent BIND version (9.5.0a5 or later) supports secure GSS-TSIG
+# updates.  If you are running an earlier version of BIND, or if you do not wish
+# to use secure GSS-TSIG updates, you may remove the update-policy sections in
+# both examples above.
+
+# If you are running a capable version of BIND and you wish to support secure
+# GSS-TSIG updates, you must make the following configuration changes:
+
+# - Insert the following lines into the options {} section of your named.conf
+# file:
+tkey-gssapi-credential "DNS/${DNSDOMAIN}";
+tkey-domain "${REALM}";
+
+# - Add settings for the ${REALM} realm to the Kerberos configuration on the DNS
+# server.  The easiest way is to add the following blocks to the appropriate
+# sections in /etc/krb5.conf:
+[realms]
+	${REALM} = {
+		kdc = ${HOSTNAME}.${DNSDOMAIN}:88
+		admin_server = ${HOSTNAME}.${DNSDOMAIN}:749
+		default_domain = ${DNSDOMAIN}
+	}
+
+[domain_realm]
+	.${DNSDOMAIN} = ${REALM}
+	${DNSDOMAIN} = ${REALM}
+
+# - Modify BIND init scripts to pass the location of the generated keytab file.
+# Fedora 8 & later provide a variable named KEYTAB_FILE in /etc/sysconfig/named
+# for this purpose:
+KEYTAB_FILE="${DNS_KEYTAB_ABS}"
+# Note that the Fedora scripts translate KEYTAB_FILE behind the scenes into a
+# variable named KRB5_KTNAME, which is ultimately passed to the BIND daemon.  If
+# your distribution does not provide a variable like KEYTAB_FILE to pass a
+# keytab file to the BIND daemon, a workaround is to place the following line in
+# BIND's sysconfig file or in the init script for BIND:
+export KRB5_KTNAME="${DNS_KEYTAB_ABS}"
+
+# - Set appropriate ownership and permissions on the ${DNS_KEYTAB} file.  Note
+# that most distributions have BIND configured to run under a non-root user
+# account.  For example, Fedora 9 runs BIND as the user "named" once the daemon
+# relinquishes its rights.  Therefore, the file ${DNS_KEYTAB} must be readable
+# by the user that BIND run as.  If BIND is running as a non-root user, the
+# "${DNS_KEYTAB}" file must have its permissions altered to allow the daemon to
+# read it.  Under Fedora 9, execute the following commands:
+chgrp named ${DNS_KEYTAB_ABS}
+chmod g+r ${DNS_KEYTAB_ABS}
+
+# - Ensure the BIND zone file(s) that will be dynamically updated are in a
+# directory where the BIND daemon can write.  When BIND performs dynamic
+# updates, it not only needs to update the zone file itself but it must also
+# create a journal (.jnl) file to track the dynamic updates as they occur.
+# Under Fedora 9, the /var/named directory can not be written to by the "named"
+# user.  However, the directory /var/named/dynamic directory does provide write
+# access.  Therefore the zone files were placed under the /var/named/dynamic
+# directory.  The file directives in both example zone statements at the
+# beginning of this file were changed by prepending the directory "dynamic/".
+
+# - If SELinux is enabled, ensure that all files have the appropriate SELinux
+# file contexts.  The ${DNS_KEYTAB} file must be accessible by the BIND daemon
+# and should have a SELinux type of named_conf_t.  This can be set with the
+# following command:
+chcon -t named_conf_t ${DNS_KEYTAB_ABS}