Moving docs tree to docs-xml to make room for generated docs in the release tarball.

(This used to be commit 9f672c26d63955f613088489c6efbdc08b5b2d14)

1 files changed, 346 insertions, 0 deletions

diff --git a/docs-xml/Samba3-HOWTO/TOSHARG-DNS-DHCP-Configuration.xml b/docs-xml/Samba3-HOWTO/TOSHARG-DNS-DHCP-Configuration.xml
new file mode 100644
index 0000000000..f64a677159
--- /dev/null
+++ b/docs-xml/Samba3-HOWTO/TOSHARG-DNS-DHCP-Configuration.xml
@@ -0,0 +1,346 @@
+<?xml version="1.0" encoding="iso-8859-1"?>
+<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
+<chapter id="DNSDHCP">
+<chapterinfo>
+	&author.jht;
+</chapterinfo>
+
+<title>DNS and DHCP Configuration Guide</title>
+
+<sect1>
+<title>Features and Benefits</title>
+
+<para>
+<indexterm><primary>Dynamic Host Configuration Protocol</primary><see>DHCP</see></indexterm>
+<indexterm><primary>Domain Name System</primary><see>DNS</see></indexterm>
+There are few subjects in the UNIX world that might raise as much contention as
+Domain Name System (DNS) and Dynamic Host Configuration Protocol (DHCP).
+Not all opinions held for or against particular implementations of DNS and DHCP
+are valid.
+</para>
+
+<para>
+We live in a modern age where many information technology users demand mobility
+and freedom. Microsoft Windows users in particular expect to be able to plug their
+notebook computer into a network port and have things <quote>just work.</quote>
+</para>
+
+<para>
+<indexterm><primary>ADS</primary></indexterm>
+UNIX administrators have a point. Many of the normative practices in the Microsoft
+Windows world at best border on bad practice from a security perspective.
+Microsoft Windows networking protocols allow workstations to arbitrarily register
+themselves on a network. Windows 2000 Active Directory registers entries in the DNS namespace
+that are equally perplexing to UNIX administrators. Welcome to the new world!
+</para>
+
+
+<para>
+<indexterm><primary>ISC</primary><secondary>DNS</secondary></indexterm>
+<indexterm><primary>ISC</primary><secondary>DHCP</secondary></indexterm>
+<indexterm><primary>Dynamic DNS</primary><see>DDNS</see></indexterm>
+The purpose of this chapter is to demonstrate the configuration of the Internet
+Software Consortium (ISC) DNS and DHCP servers to provide dynamic services that are
+compatible with their equivalents in the Microsoft Windows 2000 Server products.
+</para>
+
+<para>
+This chapter provides no more than a working example of configuration files for both DNS and DHCP servers. The
+examples used match configuration examples used elsewhere in this document.
+</para>
+
+<para>
+<indexterm><primary>DNS</primary></indexterm>
+<indexterm><primary>DHCP</primary></indexterm>
+<indexterm><primary>BIND9.NET</primary></indexterm>
+This chapter explicitly does not provide a tutorial, nor does it pretend to be a reference guide on DNS and
+DHCP, as this is well beyond the scope and intent of this document as a whole. Anyone who wants more detailed
+reference materials on DNS or DHCP should visit the ISC Web site at <ulink noescape="1"
+url="http://www.isc.org"> http://www.isc.org</ulink>.  Those wanting a written text might also be interested
+in the O'Reilly publications on DNS, see the <ulink
+url="http://www.oreilly.com/catalog/dns/index.htm">O'Reilly</ulink> web site, and the <ulink
+url="http://www.bind9.net/books-dhcp">BIND9.NET</ulink> web site for details.
+The books are:
+</para>
+
+<orderedlist>
+	<listitem><para>DNS and BIND, By Cricket Liu, Paul Albitz, ISBN: 1-56592-010-4</para></listitem>
+	<listitem><para>DNS &amp; Bind Cookbook, By Cricket Liu, ISBN: 0-596-00410-9</para></listitem>
+	<listitem><para>The DHCP Handbook (2nd Edition), By: Ralph Droms, Ted Lemon, ISBN 0-672-32327-3</para></listitem>
+</orderedlist>
+
+</sect1>
+
+<sect1>
+<title>Example Configuration</title>
+
+<para>
+<indexterm><primary>WINS</primary></indexterm>
+<indexterm><primary>DNS</primary></indexterm>
+The DNS is to the Internet what water is to life. Nearly all information resources (host names) are resolved
+to their Internet protocol (IP) addresses through DNS.  Windows networking tried hard to avoid the
+complexities of DNS, but alas, DNS won.  <indexterm><primary>WINS</primary></indexterm> The alternative to
+DNS, the Windows Internet Name Service (WINS) &smbmdash; an artifact of NetBIOS networking over the TCP/IP
+protocols &smbmdash; has demonstrated scalability problems as well as a flat, nonhierarchical namespace that
+became unmanageable as the size and complexity of information technology networks grew.
+</para>
+
+<para>
+<indexterm><primary>RFC 1001</primary></indexterm>
+<indexterm><primary>RFC 1002</primary></indexterm>
+WINS is a Microsoft implementation of the RFC1001/1002 NetBIOS Name Service (NBNS).
+It allows NetBIOS clients (like Microsoft Windows machines) to register an arbitrary
+machine name that the administrator or user has chosen together with the IP
+address that the machine has been given. Through the use of WINS, network client machines
+could resolve machine names to their IP address.
+</para>
+
+<para>
+The demand for an alternative to the limitations of NetBIOS networking finally drove
+Microsoft to use DNS and Active Directory. Microsoft's new implementation attempts
+to use DNS in a manner similar to the way that WINS is used for NetBIOS networking.
+Both WINS and Microsoft DNS rely on dynamic name registration.
+</para> 
+
+<para>
+Microsoft Windows clients can perform dynamic name registration to the DNS server
+on startup. Alternatively, where DHCP is used to assign workstation IP addresses,
+it is possible to register hostnames and their IP address by the DHCP server as
+soon as a client acknowledges an IP address lease. Finally, Microsoft DNS can resolve
+hostnames via Microsoft WINS.
+</para>
+
+<para>
+The following configurations demonstrate a simple, insecure dynamic DNS server and
+a simple DHCP server that matches the DNS configuration.
+</para>
+
+	<sect2>
+	<title>Dynamic DNS</title>
+
+	<para>
+	<indexterm><primary>DNS</primary><secondary>Dynamic</secondary></indexterm>
+	The example DNS configuration is for a private network in the IP address
+	space for network 192.168.1.0/24. The private class network address space
+	is set forth in RFC1918.
+	</para>
+
+
+	<para>
+	<indexterm><primary>BIND</primary></indexterm>
+	It is assumed that this network will be situated behind a secure firewall.
+	The files that follow work with ISC BIND version 9. BIND is the Berkeley
+	Internet Name Daemon.
+	</para>
+
+	<para>
+	The master configuration file <filename>/etc/named.conf</filename>
+	determines the location of all further configuration files used.
+	The location and name of this file is specified in the startup script
+	that is part of the operating system.
+<programlisting>
+# Quenya.Org configuration file
+
+acl mynet {
+	192.168.1.0/24;
+	127.0.0.1;
+};
+
+options {
+
+	directory "/var/named";
+	listen-on-v6 { any; };
+	notify no;
+	forward first;
+	forwarders {
+		192.168.1.1;
+		};
+	auth-nxdomain yes;
+	multiple-cnames yes;
+	listen-on {
+		mynet;
+		};
+};
+
+# The following three zone definitions do not need any modification.
+# The first one defines localhost while the second defines the
+# reverse lookup for localhost. The last zone "." is the
+# definition of the root name servers.
+
+zone "localhost" in {
+	type master;
+	file "localhost.zone";
+};
+
+zone "0.0.127.in-addr.arpa" in {
+	type master;
+	file "127.0.0.zone";
+};
+
+zone "." in {
+	type hint;
+	file "root.hint";
+};
+
+# You can insert further zone records for your own domains below.
+
+zone "quenya.org" {
+	type master;
+	file "/var/named/quenya.org.hosts";
+	allow-query {
+		mynet;
+		};
+	allow-transfer {
+		mynet;
+		};
+	allow-update {
+		mynet;
+		};
+	};
+
+zone "1.168.192.in-addr.arpa" {
+	type master;
+	file "/var/named/192.168.1.0.rev";
+	allow-query {
+		mynet;
+	};
+	allow-transfer {
+		mynet;
+	};
+	allow-update {
+		mynet;
+	};
+};
+</programlisting>
+	</para>
+
+	<para>
+	The following files are all located in the directory <filename>/var/named</filename>.
+	This is the <filename>/var/named/localhost.zone</filename> file:
+<programlisting>
+$TTL 1W
+@               IN SOA  @   root (
+				42              ; serial (d. adams)
+				2D              ; refresh
+				4H              ; retry
+				6W              ; expiry
+				1W )            ; minimum
+
+		IN NS           @
+		IN A            127.0.0.1
+	</programlisting>
+	</para>
+
+	<para>
+	The <filename>/var/named/127.0.0.zone</filename> file:
+<programlisting>
+$TTL 1W
+@               IN SOA          localhost.  root.localhost. (
+				42              ; serial (d. adams)
+				2D              ; refresh
+				4H              ; retry
+				6W              ; expiry
+				1W )            ; minimum
+
+				IN NS           localhost.
+1               IN PTR          localhost.
+</programlisting>
+	</para>
+
+	<para>
+		The <filename>/var/named/quenya.org.host</filename> file:
+<programlisting>
+$ORIGIN .
+$TTL 38400      ; 10 hours 40 minutes
+quenya.org      IN SOA  marvel.quenya.org. root.quenya.org. (
+				2003021832 ; serial
+				10800      ; refresh (3 hours)
+				3600       ; retry (1 hour)
+				604800     ; expire (1 week)
+				38400      ; minimum (10 hours 40 minutes)
+				)
+			NS      marvel.quenya.org.
+			MX      10 mail.quenya.org.
+$ORIGIN quenya.org.
+frodo                   A       192.168.1.1
+marvel                  A       192.168.1.2
+;
+mail                    CNAME   marvel
+www                     CNAME   marvel
+</programlisting>
+</para>
+
+<para>
+	The <filename>/var/named/192.168.1.0.rev</filename> file:
+<programlisting>
+$ORIGIN .
+$TTL 38400      ; 10 hours 40 minutes
+1.168.192.in-addr.arpa  IN SOA  marvel.quenya.org. root.quenya.org. (
+				2003021824 ; serial
+				10800      ; refresh (3 hours)
+				3600       ; retry (1 hour)
+				604800     ; expire (1 week)
+				38400      ; minimum (10 hours 40 minutes)
+				)
+			NS      marvel.quenya.org.
+$ORIGIN 1.168.192.in-addr.arpa.
+1                       PTR     frodo.quenya.org.
+2                       PTR     marvel.quenya.org.
+</programlisting>
+	</para>
+
+	<para>
+<indexterm><primary>BIND</primary></indexterm>
+<indexterm><primary>dynamic registration files</primary></indexterm>
+	The configuration files shown here were copied from a fully working system. All dynamically registered
+	entries have been removed. In addition to these files, BIND version 9 will
+	create for each of the dynamic registration files a file that has a 
+	<filename>.jnl</filename> extension. Do not edit or tamper with the configuration
+	files or with the <filename>.jnl</filename> files that are created.
+	</para>
+
+	</sect2>
+
+	<sect2 id="DHCP">
+	<title>DHCP Server</title>
+
+	<para>
+	The following file is used with the ISC DHCP Server version 3.
+	The file is located in <filename>/etc/dhcpd.conf</filename>:
+	</para>
+
+	<para>
+	<programlisting>
+ddns-updates on;
+ddns-domainname "quenya.org";
+option ntp-servers 192.168.1.2;
+ddns-update-style ad-hoc;
+allow unknown-clients;
+default-lease-time 86400;
+max-lease-time 172800;
+
+option domain-name "quenya.org";
+option domain-name-servers 192.168.1.2;
+option netbios-name-servers 192.168.1.2;
+option netbios-dd-server 192.168.1.2;
+option netbios-node-type 8;
+
+subnet 192.168.1.0 netmask 255.255.255.0 {
+	range dynamic-bootp 192.168.1.60 192.168.1.254;
+	option subnet-mask 255.255.255.0;
+	option routers 192.168.1.2;
+	allow unknown-clients;
+}
+</programlisting>
+	</para>
+
+	<para>
+	In this example, IP addresses between 192.168.1.1 and 192.168.1.59 are
+	reserved for fixed-address (commonly called <constant>hard-wired</constant>) IP addresses. The
+	addresses between 192.168.1.60 and 192.168.1.254 are allocated for dynamic use.
+	</para>
+
+	</sect2>
+
+</sect1>
+</chapter>