#
# Insert these snippets into your named.conf or bind.conf to configure
# the BIND nameserver.
#

# You should always include the actual forward zone configuration:
zone "${DNSDOMAIN}." IN {
	type master;
	file "${DNSDOMAIN}.zone";
	update-policy {
		/*
		 * 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;
	};
};

# 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}";

# - 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}