path: root/docs/howto/DNS-DHCP-Configuration.xml

<chapter id="DNSDHCP">
<chapterinfo>
	&author.jht;
</chapterinfo>

<title>DNS and DHCP Configuration Guide</title>

<sect1>
<title>Features and Benefits</title>

<para>
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>
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 name space
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>
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>
The purpose of this chapter is to provide 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>
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 sites 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 these two subjects.
</para>

</sect1>

<sect1>
<title>Example Configuration</title>

<para>
The domain name system is to the Internet what water is to life. By it nearly all
information resources (host names) are resolved to their Internet protocol (IP) address.
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) an artifact of
NetBIOS networking over the TCP/IP protocols, has demonstrated scalability problems as
well as a flat non-hierarchical name space that became unmanageable as the size and
complexity of information technology networks grew.
</para>

<para>
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 start-up. Alternately, where DHCP is used to assign workstation IP addresses,
it is possible to register host names and their IP address by the DHCP server as
soon as a client acknowledges an IP address lease. Lastly, 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. The following configuration files are offered:
	</para>

	<para>
	The master configuration file for <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 start-up script
	that is part of the operating system.
	<smbfile name="named.conf">
<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>
</smbfile>
	</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:
	<smbfile name="localhost.zone">
<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>
</smbfile>
	</para>

	<para>
	The <filename>/var/named/127.0.0.zone</filename> file:
	<smbfile name="127.0.0.0.zone">
<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>
</smbfile>
	</para>

	<para>
		The <filename>/var/named/quenya.org.host</filename> file:
			<smbfile name="quenya.org.host">
<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>
</smbfile>
</para>

<para>
	The <filename>/var/named/192.168.1.0.rev</filename> file:
	<smbfile name="192.168.1.0.rev">
<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>
</smbfile>
	</para>

	<para>
	The above 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>
		<smbfile name="dhcpd.conf">
	<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>
</smbfile>
	</para>

	<para>
	In the above 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>