diff options
Diffstat (limited to 'source4/setup/named.conf')
| -rw-r--r-- | source4/setup/named.conf | 135 |
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} |