source4/setup/named.conf

   1 #
   2 # Insert these snippets into your named.conf or bind.conf to configure
   3 # the BIND nameserver.
   4 #
   5
   6 # You should always include the actual forward zone configuration:
   7 zone "${DNSDOMAIN}." IN {
   8         type master;
   9         file "${DNSDOMAIN}.zone";
  10         update-policy {
  11                 /*
  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
  14                  * source code).
  15                  *
  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.
  19                  *
  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):
  23                  *
  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:
  29                  *
  30                  * 1) The machine component of the signer name matches the first
  31                  * (host) component of the FQDN that is being updated.
  32                  *
  33                  * 2) The realm component of the signer name matches the realm
  34                  * in the grant statement below (${REALM}).
  35                  *
  36                  * 3) The domain component of the FQDN that is being updated
  37                  * matches the realm in the grant statement below.
  38                  *
  39                  * If the 3 conditions above are satisfied, the update succeeds.
  40                  */
  41                 grant ${REALM} ms-self * A AAAA;
  42         };
  43 };
  44
  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 {
  48         type master;
  49         file "123.168.192.in-addr.arpa.zone";
  50         update-policy {
  51                 grant ${REALM_WC} wildcard *.123.168.192.in-addr.arpa. PTR;
  52         };
  53 };
  54 # Note that the reverse zone file is not created during the provision process.
  55
  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.
  60
  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:
  63
  64 # - Insert the following lines into the options {} section of your named.conf
  65 # file:
  66 tkey-gssapi-credential "DNS/${DNSDOMAIN}";
  67 tkey-domain "${REALM}";
  68
  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
  71 # for this purpose:
  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}"
  79
  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}
  89
  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/".
  99
 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
 103 # following command:
 104 chcon -t named_conf_t ${DNS_KEYTAB_ABS}