diff options
Diffstat (limited to 'source4/setup')
| -rw-r--r-- | source4/setup/named.conf | 63 | ||||
| -rw-r--r-- | source4/setup/named.txt | 46 | ||||
| -rw-r--r-- | source4/setup/provision.zone | 7 |
3 files changed, 65 insertions, 51 deletions
diff --git a/source4/setup/named.conf b/source4/setup/named.conf index 4f98bbd914..0b087069c7 100644 --- a/source4/setup/named.conf +++ b/source4/setup/named.conf @@ -1,12 +1,15 @@ +# This file should be included in your main BIND configuration file # -# Insert these snippets into your named.conf or bind.conf to configure -# the BIND nameserver. -# +# For example with +# include "${PRIVATE_DIR}/named.conf"; -# You should always include the actual forward zone configuration: zone "${DNSDOMAIN}." IN { type master; - file "${DNSDOMAIN}.zone"; + file "${PRIVATE_DIR}/${DNSDOMAIN}.zone"; + /* + * Attention: Not all BIND versions support "ms-self". The instead use + * of allow-update { any; }; is another, but less secure possibility. + */ update-policy { /* * A rather long description here, as the "ms-self" option does @@ -44,6 +47,8 @@ zone "${DNSDOMAIN}." IN { # 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"; @@ -51,54 +56,12 @@ zone "123.168.192.in-addr.arpa" in { 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 +# The most recent BIND versions (9.5.0a5 or later) support 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} diff --git a/source4/setup/named.txt b/source4/setup/named.txt new file mode 100644 index 0000000000..c1e6b3a9ee --- /dev/null +++ b/source4/setup/named.txt @@ -0,0 +1,46 @@ +# Additional informations for DNS setup using BIND + +# 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} diff --git a/source4/setup/provision.zone b/source4/setup/provision.zone index 28c1c29762..17ae3bb47a 100644 --- a/source4/setup/provision.zone +++ b/source4/setup/provision.zone @@ -14,10 +14,12 @@ ${HOSTIP6_BASE_LINE} ; ${HOSTIP6_HOST_LINE} ${HOSTNAME} IN A ${HOSTIP} -${HOSTGUID}._msdcs IN CNAME ${HOSTNAME} +gc._msdcs IN CNAME ${HOSTNAME} +${HOSTGUID}._msdcs IN CNAME ${HOSTNAME} ; ; global catalog servers _gc._tcp IN SRV 0 100 3268 ${HOSTNAME} +_gc._tcp.${DEFAULTSITE}._sites IN SRV 0 100 3268 ${HOSTNAME} _ldap._tcp.gc._msdcs IN SRV 0 100 389 ${HOSTNAME} _ldap._tcp.${DEFAULTSITE}._sites.gc._msdcs IN SRV 0 100 389 ${HOSTNAME} ; @@ -25,12 +27,15 @@ _ldap._tcp.${DEFAULTSITE}._sites.gc._msdcs IN SRV 0 100 389 ${HOSTNAME} _ldap._tcp IN SRV 0 100 389 ${HOSTNAME} _ldap._tcp.dc._msdcs IN SRV 0 100 389 ${HOSTNAME} _ldap._tcp.pdc._msdcs IN SRV 0 100 389 ${HOSTNAME} +_ldap._tcp.${DOMAINGUID} IN SRV 0 100 389 ${HOSTNAME} _ldap._tcp.${DOMAINGUID}.domains._msdcs IN SRV 0 100 389 ${HOSTNAME} +_ldap._tcp.${DEFAULTSITE}._sites IN SRV 0 100 389 ${HOSTNAME} _ldap._tcp.${DEFAULTSITE}._sites.dc._msdcs IN SRV 0 100 389 ${HOSTNAME} ; ; krb5 servers _kerberos._tcp IN SRV 0 100 88 ${HOSTNAME} _kerberos._tcp.dc._msdcs IN SRV 0 100 88 ${HOSTNAME} +_kerberos._tcp.${DEFAULTSITE}._sites IN SRV 0 100 88 ${HOSTNAME} _kerberos._tcp.${DEFAULTSITE}._sites.dc._msdcs IN SRV 0 100 88 ${HOSTNAME} _kerberos._udp IN SRV 0 100 88 ${HOSTNAME} ; MIT kpasswd likes to lookup this name on password change |