+# This file should be included in your main BIND configuration file
#
-# Insert these snippets into your named.conf or bind.conf to configure
-# the BIND nameserver.
-#
+# For example with
+# include "${NAMED_CONF}";
-# 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;
- };
+ file "${ZONE_FILE}";
+ /*
+ * the list of principals and what they can change is created
+ * dynamically by Samba, based on the membership of the domain controllers
+ * group. The provision just creates this file as an empty file.
+ */
+ include "${NAMED_CONF_UPDATE}";
+
+ /* we need to use check-names ignore so _msdcs A records can be created */
+ check-names ignore;
};
# 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";
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
+# The most recent BIND versions (9.5.0a5 or later) support 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}
git.samba.org / samba.git / blobdiff