2 # Insert these snippets into your named.conf or bind.conf to configure
6 # You should always include the actual forward zone configuration:
7 zone "${DNSDOMAIN}." IN {
9 file "${DNSDOMAIN}.zone";
12 * A rather long description here, as the "ms-self" option does
13 * not appear in any docs yet (it can only be found in the
16 * The short of it is that each host is allowed to update its
17 * own A and AAAA records, when the update request is properly
18 * signed by the host itself.
20 * The long description is (look at the
21 * dst_gssapi_identitymatchesrealmms() call in lib/dns/ssu.c and
22 * its definition in lib/dns/gssapictx.c for details):
24 * A GSS-TSIG update request will be signed by a given signer
25 * (e.g. machine-name$@${REALM}). The signer name is split into
26 * the machine component (e.g. "machine-name") and the realm
27 * component (e.g. "${REALM}"). The update is allowed if the
28 * following conditions are met:
30 * 1) The machine component of the signer name matches the first
31 * (host) component of the FQDN that is being updated.
33 * 2) The realm component of the signer name matches the realm
34 * in the grant statement below (${REALM}).
36 * 3) The domain component of the FQDN that is being updated
37 * matches the realm in the grant statement below.
39 * If the 3 conditions above are satisfied, the update succeeds.
41 grant ${REALM} ms-self * A AAAA;
45 # The reverse zone configuration is optional. The following example assumes a
46 # subnet of 192.168.123.0/24:
47 zone "123.168.192.in-addr.arpa" in {
49 file "123.168.192.in-addr.arpa.zone";
51 grant ${REALM_WC} wildcard *.123.168.192.in-addr.arpa. PTR;
54 # Note that the reverse zone file is not created during the provision process.
56 # The most recent BIND version (9.5.0a5 or later) supports secure GSS-TSIG
57 # updates. If you are running an earlier version of BIND, or if you do not wish
58 # to use secure GSS-TSIG updates, you may remove the update-policy sections in
59 # both examples above.
61 # If you are running a capable version of BIND and you wish to support secure
62 # GSS-TSIG updates, you must make the following configuration changes:
64 # - Insert the following lines into the options {} section of your named.conf
66 tkey-gssapi-credential "DNS/${DNSDOMAIN}";
67 tkey-domain "${REALM}";
69 # - Modify BIND init scripts to pass the location of the generated keytab file.
70 # Fedora 8 & later provide a variable named KEYTAB_FILE in /etc/sysconfig/named
72 KEYTAB_FILE="${DNS_KEYTAB_ABS}"
73 # Note that the Fedora scripts translate KEYTAB_FILE behind the scenes into a
74 # variable named KRB5_KTNAME, which is ultimately passed to the BIND daemon. If
75 # your distribution does not provide a variable like KEYTAB_FILE to pass a
76 # keytab file to the BIND daemon, a workaround is to place the following line in
77 # BIND's sysconfig file or in the init script for BIND:
78 export KRB5_KTNAME="${DNS_KEYTAB_ABS}"
80 # - Set appropriate ownership and permissions on the ${DNS_KEYTAB} file. Note
81 # that most distributions have BIND configured to run under a non-root user
82 # account. For example, Fedora 9 runs BIND as the user "named" once the daemon
83 # relinquishes its rights. Therefore, the file ${DNS_KEYTAB} must be readable
84 # by the user that BIND run as. If BIND is running as a non-root user, the
85 # "${DNS_KEYTAB}" file must have its permissions altered to allow the daemon to
86 # read it. Under Fedora 9, execute the following commands:
87 chgrp named ${DNS_KEYTAB_ABS}
88 chmod g+r ${DNS_KEYTAB_ABS}
90 # - Ensure the BIND zone file(s) that will be dynamically updated are in a
91 # directory where the BIND daemon can write. When BIND performs dynamic
92 # updates, it not only needs to update the zone file itself but it must also
93 # create a journal (.jnl) file to track the dynamic updates as they occur.
94 # Under Fedora 9, the /var/named directory can not be written to by the "named"
95 # user. However, the directory /var/named/dynamic directory does provide write
96 # access. Therefore the zone files were placed under the /var/named/dynamic
97 # directory. The file directives in both example zone statements at the
98 # beginning of this file were changed by prepending the directory "dynamic/".
100 # - If SELinux is enabled, ensure that all files have the appropriate SELinux
101 # file contexts. The ${DNS_KEYTAB} file must be accessible by the BIND daemon
102 # and should have a SELinux type of named_conf_t. This can be set with the
104 chcon -t named_conf_t ${DNS_KEYTAB_ABS}