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