Improve DNS and Group poicy configurations.

 - fixes bug #4813 (simplify DNS setup)
  - This reworks the named.conf to be a fully fledged include
  - This also moves the documentation into named.txt
 - improves bug #4900 (Group policy support in Samba)
   - by creating an empty GPT.INI
 - fixes bug #5582 (DNS: Enhanced zone file)
   - This is now closer to the zone file AD creates

committed by Andrew Bartlett
(This used to be commit 74d684f6b329d7dd573cdc55e16bb8e629474b02)

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