1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
|
#
# 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}";
# - 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}
|
