diff options
Diffstat (limited to 'docs/howto/DNS-DHCP-Configuration.xml')
| -rw-r--r-- | docs/howto/DNS-DHCP-Configuration.xml | 338 |
1 files changed, 338 insertions, 0 deletions
diff --git a/docs/howto/DNS-DHCP-Configuration.xml b/docs/howto/DNS-DHCP-Configuration.xml new file mode 100644 index 0000000000..cb6fa959a0 --- /dev/null +++ b/docs/howto/DNS-DHCP-Configuration.xml @@ -0,0 +1,338 @@ +<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> |