2 files changed, 1284 insertions, 4 deletions

diff --git a/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml b/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml
index 6cde4ef3a6..cd443d65b5 100644
--- a/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml
@@ -1,7 +1,7 @@
 <!--
      The FreeBSD Documentation Project
 
-     $FreeBSD: doc/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml,v 1.35 2001/02/09 16:02:02 dannyboy Exp $
+     $FreeBSD: doc/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml,v 1.36 2001/04/09 00:33:48 dd Exp $
 -->
 
 <chapter id="advanced-networking">
@@ -2703,9 +2703,649 @@ dhcp_flags=""</programlisting>
     </sect2>
   </sect1>
 
+<sect1 id="dns">
+<title>DNS</title>
+<para><emphasis>Written by Chern Lee <email>clee@serenivision.com</email>, April 12, 2001.
+      </emphasis>
+</para>
+
+<sect2>
+  <title>Overview</title>
+  <para>FreeBSD utilizes, by default, a version of BIND (Berkeley Internet Name
+    Domain), which is the most common implementation of the DNS protocol.  DNS
+    is the protocol through which names are mapped to ips, and vice
+    versa.  For example, a query for www.freebsd.org will send back a reply
+    for the IP address of The FreeBSD Project's webpage, whereas, a query for
+    ftp.freebsd.org will return the IP of the corresponding ftp
+    machine.  Likewise, the opposite can happen.  A query for an ip address
+    can resolve its hostname.
+  </para>
+
+  <para>DNS is coordinated across the Internet through a somewhat complex system
+    of authoritative root name servers, and other smaller-scale nameservers
+    who host and relay individual domain information.
+  </para>
+
+  <para>
+    This document refers to BIND 8.x, as it is the most current, stable 
+    version used in FreeBSD.
+  </para>
+
+  <para>
+    RFC1034 and RFC1035 dictates the DNS protocol.
+  </para>
+
+  <para>
+    Currently, BIND is maintained by the <ulink url="http://www.isc.org">
+    Internet Software Consortium (www.isc.org)</ulink>
+  </para>
+</sect2>
+
+<sect2>
+  <title>Terminology Used</title>
+
+  <para><emphasis>zone</emphasis> - Each individual domain, subdomain, 
+    or 'area' dictated by DNS is considered a zone.
+  </para>
+
+  <para>Examples of zones:
+  </para>
+  <itemizedlist>
+    <listitem>
+      <para>. is the root zone</para>
+    </listitem>
+    <listitem>
+     <para>org. is a zone under the root zone</para>
+    </listitem>
+    <listitem>
+      <para>foobardomain.org is a zone under the org. zone</para>
+    </listitem>
+    <listitem>
+      <para>foo.foobardomain.org. is a subdomain, a zone under the 
+        foobardomain.org. zone
+      </para>
+    </listitem>
+    <listitem>
+      <para>
+        1.2.3.in-addr.arpa is a zone referencing all ips which fall under 
+        the 3.2.1.* ip space.
+      </para>
+    </listitem>
+  </itemizedlist>
+
+  <para><emphasis>named, bind, name server</emphasis> - these are all common
+    names for the BIND name server package within FreeBSD.
+  </para>
+
+  <para><emphasis>resolver</emphasis> - a network process by which a system 
+    queries a nameserver for answers
+  </para>
+
+  <para><emphasis>root zone</emphasis> - literally, a '.', refers to the root,
+    or beginning zone.  All zones fall under this, as do all files in fall 
+    under the root directory.  It is the beginning of the Internet zone
+    hierarchy
+  </para>
+
+  <para><emphasis>origin</emphasis> - refers to the point of start for the
+    particular zone
+  </para>
+
+  <para><emphasis>forward dns</emphasis> - mapping of hostnames to ip addresses
+  </para>
+
+  <para><emphasis>reverse dns</emphasis> - the opposite, mapping of ip
+    addresses to hostnames
+  </para>
+</sect2>
+
+<sect2>
+  <title>Reasons to run a name server</title>
+  <itemizedlist>
+      <listitem>
+        <para>
+          You need your machine to host DNS information to the world
+        </para> 
+        <itemizedlist>
+          <listitem>
+            <para>An authoritative nameserver replies exclusively 
+              to requests.
+            </para>
+          </listitem>
+          <listitem>
+            <para>For example, you register foobardomain.org and wish to assign
+              hostnames to its proper ip addresses.
+            </para>
+          </listitem>
+          <listitem>
+            <para>A slave nameserver, which replies to queries for a 
+              domain when the primary is down or inaccessible.
+            </para>
+          </listitem>
+          <listitem>
+            <para>The above two can also be done with in-addr.arpa, ip to 
+              hostname entries
+            </para>
+          </listitem>
+        </itemizedlist>
+      </listitem>
+      <listitem>
+        <para>
+          You wish your machine to act as a local relay of DNS 
+          information
+        </para>
+        <itemizedlist>
+          <listitem>
+            <para>DNS traffic has been measured to be about 5% or more of 
+              the total Internet traffic.
+            </para>
+          </listitem>
+          <listitem>
+             <para>A local DNS server may have some added benefit by 
+               providing a local cache of DNS information.
+             </para>
+           </listitem>
+          <listitem>
+             <para>
+               For example, when one queries for www.freebsd.org, their 
+               resolver goes out to (usually) your ISP's name server, and 
+               retreives the query.
+             </para>
+          </listitem>
+          <listitem>
+            <para>
+              With a local, caching DNS server, the query only has to be 
+              made once to the outside world.  Every additional query will 
+              not have to go outside of the local network, since the 
+              information is cached.
+            </para>
+          </listitem>
+        </itemizedlist>
+      </listitem>
+  </itemizedlist>
+</sect2>
+
+<sect2>
+<title>How it works</title>
+  <para>
+  A DNS server in FreeBSD relies on the BIND daemon.  This daemon is
+  called 'named' for obvious reasons.
+  </para>
+
+  <para><command>named</command> - the bind daemon</para>
+  <para><command>ndc</command> - name daemon control program</para>
+
+  <para>
+  <filename>/etc/namedb</filename> - directory where all the bind information
+    resides
+  </para>
+  <para>
+  <filename>/etc/namedb/named.conf</filename> - daemon configuration file
+  </para>
+
+  <para>
+    zone files are usually contained within the <filename>/etc/namedb</filename>
+    directory, and contain the  information (query answers from your site)
+    served by your name server.
+  </para>
+</sect2>
+
+<sect2>
+  <title>Starting BIND</title>
+  <para>
+    Since bind is installed by default, configuring it all is relatively
+    simple.
+  </para>
+  <para>
+    To ensure the named daemon is started at boot, put the following
+    modifications in your <filename>/etc/rc.conf</filename>
+  </para>
+  <programlisting>named_enable="YES"</programlisting>
+  <para>To start the daemon manually (after configuring it)</para>
+  <screen>&prompt.root; <userinput>ndc start</userinput></screen>
+</sect2>
+
+<sect2>
+  <title>Configuration files</title>
+  <sect3>
+    <title>make-localhost</title>
+      <para>Be sure to
+      </para>
+      <screen>
+        &prompt.root; <userinput>cd /etc/namedb
+        &prompt.root; sh make-localhost</userinput>
+      </screen> 
+      <para>to properly create your local reverse dns zone file in
+        <filename>/etc/namedb/localhost.rev</filename>.
+      </para>
+  </sect3>
+
+  <sect3>
+      <title><filename>/etc/namedb/named.conf</filename></title>
+
+      <programlisting>
+// $FreeBSD: src/etc/namedb/named.conf,v 1.6.2.1 2000/07/15 07:49:29 kris Exp $
+//
+// Refer to the named(8) man page for details.  If you are ever going
+// to setup a primary server, make sure you've understood the hairy
+// details of how DNS is working.  Even with simple mistakes, you can
+// break connectivity for affected parties, or cause huge amount of
+// useless Internet traffic.
+
+options {
+        directory "/etc/namedb";
+
+// In addition to the "forwarders" clause, you can force your name
+// server to never initiate queries of its own, but always ask its
+// forwarders only, by enabling the following line:
+//
+//      forward only;
+
+// If you've got a DNS server around at your upstream provider, enter
+// its IP address here, and enable the line below.  This will make you
+// benefit from its cache, thus reduce overall DNS traffic in the
+Internet.
+/*
+        forwarders {
+                127.0.0.1;
+        };
+*/
+      </programlisting>
+
+      <para>
+        Just as the comment says, if you want to benefit from your uplink's 
+        cache, you can enable this section of the config file.
+
+        Normally, your nameserver will recursively query different nameservers 
+        until it finds the answer it is looking for.  Having this enabled will
+        have it automatically see if your uplink's (or whatever provided) ns 
+        has the requested query.
+      
+        If your uplink has a heavily trafficked, fast nameserver, enabling 
+        this properly could work to your advantage.
+
+        127.0.0.1 will *NOT* work here; change this to the ip of a nameserver 
+        at your uplink.
+      </para>
+
+      <programlisting>
+        /*
+         * If there is a firewall between you and nameservers you want
+         * to talk to, you might need to uncomment the query-source
+         * directive below.  Previous versions of BIND always asked
+         * questions using port 53, but BIND 8.1 uses an unprivileged
+         * port by default.
+         */
+        // query-source address * port 53;
+
+        /*
+         * If running in a sandbox, you may have to specify a different
+         * location for the dumpfile.
+         */
+        // dump-file "s/named_dump.db";
+};
+
+// Note: the following will be supported in a future release.
+/*
+host { any; } {
+        topology {
+                127.0.0.0/8;
+        };
+};
+*/
+
+// Setting up secondaries is way easier and the rough picture for this
+// is explained below.
+//
+// If you enable a local name server, don't forget to enter 127.0.0.1
+// into your /etc/resolv.conf so this server will be queried first.
+// Also, make sure to enable it in /etc/rc.conf.
+
+zone "." {
+        type hint;
+        file "named.root";
+};
+
+zone "0.0.127.IN-ADDR.ARPA" {
+        type master;
+        file "localhost.rev";
+};
+
+zone
+"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT" {
+        type master;
+        file "localhost.rev";
+};
+
+// NB: Do not use the IP addresses below, they are faked, and only
+// serve demonstration/documentation purposes!
+//
+// Example secondary config entries.  It can be convenient to become
+// a secondary at least for the zone where your own domain is in.  Ask
+// your network administrator for the IP address of the responsible
+// primary.
+//
+// Never forget to include the reverse lookup (IN-ADDR.ARPA) zone!
+// (This is the first bytes of the respective IP address, in reverse
+// order, with ".IN-ADDR.ARPA" appended.)
+//
+// Before starting to setup a primary zone, better make sure you fully
+// understand how DNS and BIND works, however.  There are sometimes
+// unobvious pitfalls.  Setting up a secondary is comparably simpler.
+//
+// NB: Don't blindly enable the examples below. :-)  Use actual names
+// and addresses instead.
+//
+// NOTE!!! FreeBSD runs bind in a sandbox (see named_flags in rc.conf).
+// The directory containing the secondary zones must be write accessible
+// to bind.  The following sequence is suggested:
+//
+//      mkdir /etc/namedb/s
+//      chown bind.bind /etc/namedb/s
+//      chmod 750 /etc/namedb/s
+
+/*
+zone "domain.com" {
+        type slave;
+        file "s/domain.com.bak";
+        masters {
+                192.168.1.1;
+        };
+};
+
+zone "0.168.192.in-addr.arpa" {
+        type slave;
+        file "s/0.168.192.in-addr.arpa.bak";
+        masters {
+                192.168.1.1;
+        };
+};
+*/
+      </programlisting>
+      <para>
+        These are example slave entries, read below to see more.
+      </para>
+      <para>
+        For each new domain added to your nameserver, you must add one of 
+        these entries to your <filename>named.conf</filename>
+      </para>
+      <para>
+       The simplest zone entry, can look like
+      </para>
+      <programlisting>
+zone "foobardomain.org" {
+	type master;
+	file "foorbardomain.org";
+};
+      </programlisting>
+
+      <para>For a master entry with the zone information within 
+        foobardomain.org, or
+      </para>
+
+      <programlisting>
+zone "foobardomain.org" {
+	type slave;
+	file "foobardomain.org";
+};
+      </programlisting>
+
+      <para>
+        for a slave.  Note that slave zones automatically query the listed
+        master (authoritative) name servers for the zone file.
+      </para>
+    </sect3>
+
+    <sect3>
+      <title>Zone files</title>  
+      <para>
+        An example master 'foobardomain.org' (existing within 
+        /etc/namedb/foobardomain.org) is as follows:
+      </para>
+
+      <programlisting>
+$TTL 3600
+
+foobardomain.org. IN SOA ns1.foobardomain.org. admin.foobardomain.org. (
+                        5               ; Serial
+                        10800           ; Refresh
+                        3600            ; Retry
+                        604800          ; Expire
+                        86400 )         ; Minimum TTL
+
+; DNS Servers
+@       IN NS           ns1.foobardomain.org.
+@       IN NS           ns2.foobardomain.org.
+
+; Machine Names
+localhost       IN A    127.0.0.1
+ns1             IN A    3.2.1.2
+ns2             IN A    3.2.1.3
+mail            IN A    3.2.1.10
+@               IN A    3.2.1.30
+
+; Aliases
+www             IN CNAME        @
+
+; MX Record
+@               IN MX   10      mail.foobardomain.org.
+      </programlisting>
+
+      <para>
+        Note that every hostname ending in a '.' is an exact hostname, whereas
+        everything without a trailing '.' is referenced to the origin.  For 
+        example, www is transalated into www + origin.  In our ficitious zone 
+        file, our origin is foobardomain.org, so www would be 
+        www.foobardomain.org.
+      </para>
+
+      <para>
+        The format of this file follows:
+      </para>
+      <programlisting>recordname      IN recordtype  value</programlisting>
+
+      <para>
+        The most commonly used DNS records:
+      </para>
+      <para><emphasis>SOA</emphasis> - start of zone authority</para>
+      <para><emphasis>NS</emphasis> - an authoritative nameserver</para>
+      <para><emphasis>A</emphasis> - A host address</para>
+      <para><emphasis>CNAME</emphasis> - the canonical name for an alias</para>
+      <para><emphasis>MX</emphasis> - mail exchange</para>
+      <para><emphasis>PTR</emphasis> - a domain name pointer (used in reverse 
+        dns)</para>
+      <programlisting>
+foobardomain.org. IN SOA ns1.foobardomain.org. admin.foobardomain.org. (
+                        5               ; Serial
+                        10800           ; Refresh after 3 hours
+                        3600            ; Retry after 1 hour
+                        604800          ; Expire after 1 week
+                        86400 )         ; Minimum TTL of 1 day
+      </programlisting>
+      <para>
+        <emphasis>foobardomain.org.</emphasis> - the domain name, also the 
+          origin for this zone file.
+      </para>
+      <para><emphasis>ns1.foobardomain.org.</emphasis> - the 
+        primary/authoritative nameserver for this zone
+      </para>
+      <para><emphasis>admin.foobardomain.org.</emphasis> - the responsible
+        person for this zone, e-mail address with @ replaced. 
+        (admin@foobardomain.org becomes admin.foobardomain.org)
+      </para>
+      <para>
+      <emphasis>5</emphasis> - the serial number of the file.  this must be
+        incremented each time the zone file is modified.  Nowadays, many 
+        admins prefer a yyyymmddrr format for the serial number.  2001041002
+        would mean last modified 04/10/2001, the latter 02 being the second
+        time the zone file has been modified this day.  The serial number is
+        important as it alerts slave nameservers for a zone when it is updated.
+      </para>
+
+      <programlisting>
+@       IN NS           ns1.foobardomain.org.
+      </programlisting>
+      <para>
+        This is an NS entry.  Every nameserver that is going to reply
+        authoritatively for the zone must have one of these entries.  The @ 
+        is seen here could have been 'foobardomain.org.' The @ transalates to 
+        the origin.
+      </para>
+
+      <programlisting>
+localhost       IN A    127.0.0.1
+ns1             IN A    3.2.1.2
+ns2             IN A    3.2.1.3
+mail            IN A    3.2.1.10
+@               IN A    3.2.1.30
+      </programlisting>
+      <para>
+        The A record indicates machine names.  As seen above, 
+        ns1.foobardomain.org would resolve to 3.2.1.2.  Again, the origin 
+        symbol, @, is used here, thus meaning foobardomain.org would resolve 
+        to 3.2.1.30.
+      </para>
+
+      <programlisting>
+www             IN CNAME        @
+      </programlisting>
+      <para>
+        The canonical name record is usually used for giving aliases to a 
+        machine.  In the example, www is aliased to the machine addressed to 
+        the origin, or foobardomain.org (3.2.1.30).  CNAMEs can be used to 
+        provide alias hostnames, or round robin one hostname among multiple
+        machines.
+      </para>
+
+      <programlisting>
+@               IN MX   10      mail.foobardomain.org.
+      </programlisting>
+
+      <para>
+        The MX record indictes which mail servers are responsible for handling 
+        incoming mail for the zone.  mail.foobardomain.org is the hostname of 
+        the mail server, and 10 being the priority of that mailserver.
+      </para>
+
+      <para>
+        One can have several mailservers, with priorities of 3, 2, 1.  A mail
+        server attempting to deliver to foobardomain.org would first try the
+        highest priority MX, then the second highest, etc, until the mail can
+        be properly delivered.
+      </para>
+
+      <para>
+        For in-addr.arpa zone files (reverse dns), the same format is used,
+        except with PTR entries instead of A or CNAME.
+      </para>
+
+      <programlisting>
+$TTL 3600
+
+1.2.3.in-addr.arpa. IN SOA ns1.foobardomain.org. admin.foobardomain.org. (
+                        5               ; Serial
+                        10800           ; Refresh
+                        3600            ; Retry
+                        604800          ; Expire
+                        3600 )          ; Minimum
+
+@       IN NS   ns1.foobardomain.org.
+@       IN NS   ns2.foobardomain.org.
+
+2       IN PTR  ns1.foobardomain.org.
+3       IN PTR  ns2.foobardomain.org.
+10      IN PTR  mail.foobardomain.org.
+30      IN PTR  foobardomain.org. 
+      </programlisting>
+      <para>
+       This file gives the proper ip to hostname mappings of our above
+       ficticious domain.
+      </para>
+  </sect3>
+</sect2>
+
+<sect2>
+  <title>Caching Name Server</title>
+  <para>
+    A caching nameserver is simply a nameserver that is not authoritative for
+    any zones.  It simply asks queries of its own, and remembers them for 
+    later use.  To set one up, just configure the name server as usual, omitting any inclusions of zones.
+  </para>
+</sect2>
+
+<sect2>
+  <title>How to use the nameserver</title>
+
+  <para>If setup properly, the nameserver should be accessible through the
+    network and locally.  <filename>/etc/resolv.conf</filename> must contain 
+    a nameserver entry with the local ip so it will query the local name 
+    server first.
+  </para>
+
+  <para>
+    To access it over the network, the machine must have the nameserver's ip 
+    set properly in its own nameserver configuration options.
+  </para>
+</sect2>
+
+<sect2>
+  <title>Security</title>
+
+  <para>Although BIND is the most common implementation of DNS, there is 
+    always the issue of security.  Possible and exploitable security holes 
+    are sometimes found.
+  </para>
+
+  <para>
+    It is a good idea to subscribe to <ulink url="http://www.cert.org">CERT</ulink>
+     and
+    <ulink url="http://www.freebsd.org/handbook/eresources.html#ERESOURCES-MAIL">freebsd-announce</ulink>
+    to stay up to date with the current Internet and FreeBSD security issues.
+  </para>
+
+  <para>
+    If a problem arises, keeping your sources up to date and having a fresh 
+    build of named can't hurt.
+  </para>
+</sect2>
+
+<sect2>
+  <title>Further Reading</title>
+  <para>
+  &man.ndc.8; &man.named.8; &man.named.conf.5;
+  </para>
+
+  <para>
+  Official ISC BIND Page
+  <ulink url="http://www.isc.org/products/BIND/">http://www.isc.org/products/BIND/</ulink>
+  </para>
+
+  <para>
+  BIND FAQ
+  <ulink url="http://www.nominum.com/resources/faqs/bind-faqs.html">
+  http://www.nominum.com/resources/faqs/bind-faqs.html</ulink>
+  </para>
+
+  <para>
+  <ulink url="http://www.oreilly.com/catalog/dns4/">O'Reilly DNS and BIND 4th Edition</ulink>
+  </para>
+
+  <para>
+  <ulink url="http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1034.txt">RFC1034 - Domain Names - 
+    Concepts and Facilities</ulink>
+  </para>
+
+  <para>
+  <ulink url="http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1035.txt">RFC1035 - Domain Names - 
+   Implementation and Specification</ulink>
+  </para>
+</sect2>
+
+</sect1>
+
 </chapter>
 
-<!-- 
+<!--
      Local Variables:
      mode: sgml
      sgml-declaration: "../chapter.decl"
diff --git a/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml b/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml
index 6cde4ef3a6..cd443d65b5 100644
--- a/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml
@@ -1,7 +1,7 @@
 <!--
      The FreeBSD Documentation Project
 
-     $FreeBSD: doc/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml,v 1.35 2001/02/09 16:02:02 dannyboy Exp $
+     $FreeBSD: doc/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml,v 1.36 2001/04/09 00:33:48 dd Exp $
 -->
 
 <chapter id="advanced-networking">
@@ -2703,9 +2703,649 @@ dhcp_flags=""</programlisting>
     </sect2>
   </sect1>
 
+<sect1 id="dns">
+<title>DNS</title>
+<para><emphasis>Written by Chern Lee <email>clee@serenivision.com</email>, April 12, 2001.
+      </emphasis>
+</para>
+
+<sect2>
+  <title>Overview</title>
+  <para>FreeBSD utilizes, by default, a version of BIND (Berkeley Internet Name
+    Domain), which is the most common implementation of the DNS protocol.  DNS
+    is the protocol through which names are mapped to ips, and vice
+    versa.  For example, a query for www.freebsd.org will send back a reply
+    for the IP address of The FreeBSD Project's webpage, whereas, a query for
+    ftp.freebsd.org will return the IP of the corresponding ftp
+    machine.  Likewise, the opposite can happen.  A query for an ip address
+    can resolve its hostname.
+  </para>
+
+  <para>DNS is coordinated across the Internet through a somewhat complex system
+    of authoritative root name servers, and other smaller-scale nameservers
+    who host and relay individual domain information.
+  </para>
+
+  <para>
+    This document refers to BIND 8.x, as it is the most current, stable 
+    version used in FreeBSD.
+  </para>
+
+  <para>
+    RFC1034 and RFC1035 dictates the DNS protocol.
+  </para>
+
+  <para>
+    Currently, BIND is maintained by the <ulink url="http://www.isc.org">
+    Internet Software Consortium (www.isc.org)</ulink>
+  </para>
+</sect2>
+
+<sect2>
+  <title>Terminology Used</title>
+
+  <para><emphasis>zone</emphasis> - Each individual domain, subdomain, 
+    or 'area' dictated by DNS is considered a zone.
+  </para>
+
+  <para>Examples of zones:
+  </para>
+  <itemizedlist>
+    <listitem>
+      <para>. is the root zone</para>
+    </listitem>
+    <listitem>
+     <para>org. is a zone under the root zone</para>
+    </listitem>
+    <listitem>
+      <para>foobardomain.org is a zone under the org. zone</para>
+    </listitem>
+    <listitem>
+      <para>foo.foobardomain.org. is a subdomain, a zone under the 
+        foobardomain.org. zone
+      </para>
+    </listitem>
+    <listitem>
+      <para>
+        1.2.3.in-addr.arpa is a zone referencing all ips which fall under 
+        the 3.2.1.* ip space.
+      </para>
+    </listitem>
+  </itemizedlist>
+
+  <para><emphasis>named, bind, name server</emphasis> - these are all common
+    names for the BIND name server package within FreeBSD.
+  </para>
+
+  <para><emphasis>resolver</emphasis> - a network process by which a system 
+    queries a nameserver for answers
+  </para>
+
+  <para><emphasis>root zone</emphasis> - literally, a '.', refers to the root,
+    or beginning zone.  All zones fall under this, as do all files in fall 
+    under the root directory.  It is the beginning of the Internet zone
+    hierarchy
+  </para>
+
+  <para><emphasis>origin</emphasis> - refers to the point of start for the
+    particular zone
+  </para>
+
+  <para><emphasis>forward dns</emphasis> - mapping of hostnames to ip addresses
+  </para>
+
+  <para><emphasis>reverse dns</emphasis> - the opposite, mapping of ip
+    addresses to hostnames
+  </para>
+</sect2>
+
+<sect2>
+  <title>Reasons to run a name server</title>
+  <itemizedlist>
+      <listitem>
+        <para>
+          You need your machine to host DNS information to the world
+        </para> 
+        <itemizedlist>
+          <listitem>
+            <para>An authoritative nameserver replies exclusively 
+              to requests.
+            </para>
+          </listitem>
+          <listitem>
+            <para>For example, you register foobardomain.org and wish to assign
+              hostnames to its proper ip addresses.
+            </para>
+          </listitem>
+          <listitem>
+            <para>A slave nameserver, which replies to queries for a 
+              domain when the primary is down or inaccessible.
+            </para>
+          </listitem>
+          <listitem>
+            <para>The above two can also be done with in-addr.arpa, ip to 
+              hostname entries
+            </para>
+          </listitem>
+        </itemizedlist>
+      </listitem>
+      <listitem>
+        <para>
+          You wish your machine to act as a local relay of DNS 
+          information
+        </para>
+        <itemizedlist>
+          <listitem>
+            <para>DNS traffic has been measured to be about 5% or more of 
+              the total Internet traffic.
+            </para>
+          </listitem>
+          <listitem>
+             <para>A local DNS server may have some added benefit by 
+               providing a local cache of DNS information.
+             </para>
+           </listitem>
+          <listitem>
+             <para>
+               For example, when one queries for www.freebsd.org, their 
+               resolver goes out to (usually) your ISP's name server, and 
+               retreives the query.
+             </para>
+          </listitem>
+          <listitem>
+            <para>
+              With a local, caching DNS server, the query only has to be 
+              made once to the outside world.  Every additional query will 
+              not have to go outside of the local network, since the 
+              information is cached.
+            </para>
+          </listitem>
+        </itemizedlist>
+      </listitem>
+  </itemizedlist>
+</sect2>
+
+<sect2>
+<title>How it works</title>
+  <para>
+  A DNS server in FreeBSD relies on the BIND daemon.  This daemon is
+  called 'named' for obvious reasons.
+  </para>
+
+  <para><command>named</command> - the bind daemon</para>
+  <para><command>ndc</command> - name daemon control program</para>
+
+  <para>
+  <filename>/etc/namedb</filename> - directory where all the bind information
+    resides
+  </para>
+  <para>
+  <filename>/etc/namedb/named.conf</filename> - daemon configuration file
+  </para>
+
+  <para>
+    zone files are usually contained within the <filename>/etc/namedb</filename>
+    directory, and contain the  information (query answers from your site)
+    served by your name server.
+  </para>
+</sect2>
+
+<sect2>
+  <title>Starting BIND</title>
+  <para>
+    Since bind is installed by default, configuring it all is relatively
+    simple.
+  </para>
+  <para>
+    To ensure the named daemon is started at boot, put the following
+    modifications in your <filename>/etc/rc.conf</filename>
+  </para>
+  <programlisting>named_enable="YES"</programlisting>
+  <para>To start the daemon manually (after configuring it)</para>
+  <screen>&prompt.root; <userinput>ndc start</userinput></screen>
+</sect2>
+
+<sect2>
+  <title>Configuration files</title>
+  <sect3>
+    <title>make-localhost</title>
+      <para>Be sure to
+      </para>
+      <screen>
+        &prompt.root; <userinput>cd /etc/namedb
+        &prompt.root; sh make-localhost</userinput>
+      </screen> 
+      <para>to properly create your local reverse dns zone file in
+        <filename>/etc/namedb/localhost.rev</filename>.
+      </para>
+  </sect3>
+
+  <sect3>
+      <title><filename>/etc/namedb/named.conf</filename></title>
+
+      <programlisting>
+// $FreeBSD: src/etc/namedb/named.conf,v 1.6.2.1 2000/07/15 07:49:29 kris Exp $
+//
+// Refer to the named(8) man page for details.  If you are ever going
+// to setup a primary server, make sure you've understood the hairy
+// details of how DNS is working.  Even with simple mistakes, you can
+// break connectivity for affected parties, or cause huge amount of
+// useless Internet traffic.
+
+options {
+        directory "/etc/namedb";
+
+// In addition to the "forwarders" clause, you can force your name
+// server to never initiate queries of its own, but always ask its
+// forwarders only, by enabling the following line:
+//
+//      forward only;
+
+// If you've got a DNS server around at your upstream provider, enter
+// its IP address here, and enable the line below.  This will make you
+// benefit from its cache, thus reduce overall DNS traffic in the
+Internet.
+/*
+        forwarders {
+                127.0.0.1;
+        };
+*/
+      </programlisting>
+
+      <para>
+        Just as the comment says, if you want to benefit from your uplink's 
+        cache, you can enable this section of the config file.
+
+        Normally, your nameserver will recursively query different nameservers 
+        until it finds the answer it is looking for.  Having this enabled will
+        have it automatically see if your uplink's (or whatever provided) ns 
+        has the requested query.
+      
+        If your uplink has a heavily trafficked, fast nameserver, enabling 
+        this properly could work to your advantage.
+
+        127.0.0.1 will *NOT* work here; change this to the ip of a nameserver 
+        at your uplink.
+      </para>
+
+      <programlisting>
+        /*
+         * If there is a firewall between you and nameservers you want
+         * to talk to, you might need to uncomment the query-source
+         * directive below.  Previous versions of BIND always asked
+         * questions using port 53, but BIND 8.1 uses an unprivileged
+         * port by default.
+         */
+        // query-source address * port 53;
+
+        /*
+         * If running in a sandbox, you may have to specify a different
+         * location for the dumpfile.
+         */
+        // dump-file "s/named_dump.db";
+};
+
+// Note: the following will be supported in a future release.
+/*
+host { any; } {
+        topology {
+                127.0.0.0/8;
+        };
+};
+*/
+
+// Setting up secondaries is way easier and the rough picture for this
+// is explained below.
+//
+// If you enable a local name server, don't forget to enter 127.0.0.1
+// into your /etc/resolv.conf so this server will be queried first.
+// Also, make sure to enable it in /etc/rc.conf.
+
+zone "." {
+        type hint;
+        file "named.root";
+};
+
+zone "0.0.127.IN-ADDR.ARPA" {
+        type master;
+        file "localhost.rev";
+};
+
+zone
+"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT" {
+        type master;
+        file "localhost.rev";
+};
+
+// NB: Do not use the IP addresses below, they are faked, and only
+// serve demonstration/documentation purposes!
+//
+// Example secondary config entries.  It can be convenient to become
+// a secondary at least for the zone where your own domain is in.  Ask
+// your network administrator for the IP address of the responsible
+// primary.
+//
+// Never forget to include the reverse lookup (IN-ADDR.ARPA) zone!
+// (This is the first bytes of the respective IP address, in reverse
+// order, with ".IN-ADDR.ARPA" appended.)
+//
+// Before starting to setup a primary zone, better make sure you fully
+// understand how DNS and BIND works, however.  There are sometimes
+// unobvious pitfalls.  Setting up a secondary is comparably simpler.
+//
+// NB: Don't blindly enable the examples below. :-)  Use actual names
+// and addresses instead.
+//
+// NOTE!!! FreeBSD runs bind in a sandbox (see named_flags in rc.conf).
+// The directory containing the secondary zones must be write accessible
+// to bind.  The following sequence is suggested:
+//
+//      mkdir /etc/namedb/s
+//      chown bind.bind /etc/namedb/s
+//      chmod 750 /etc/namedb/s
+
+/*
+zone "domain.com" {
+        type slave;
+        file "s/domain.com.bak";
+        masters {
+                192.168.1.1;
+        };
+};
+
+zone "0.168.192.in-addr.arpa" {
+        type slave;
+        file "s/0.168.192.in-addr.arpa.bak";
+        masters {
+                192.168.1.1;
+        };
+};
+*/
+      </programlisting>
+      <para>
+        These are example slave entries, read below to see more.
+      </para>
+      <para>
+        For each new domain added to your nameserver, you must add one of 
+        these entries to your <filename>named.conf</filename>
+      </para>
+      <para>
+       The simplest zone entry, can look like
+      </para>
+      <programlisting>
+zone "foobardomain.org" {
+	type master;
+	file "foorbardomain.org";
+};
+      </programlisting>
+
+      <para>For a master entry with the zone information within 
+        foobardomain.org, or
+      </para>
+
+      <programlisting>
+zone "foobardomain.org" {
+	type slave;
+	file "foobardomain.org";
+};
+      </programlisting>
+
+      <para>
+        for a slave.  Note that slave zones automatically query the listed
+        master (authoritative) name servers for the zone file.
+      </para>
+    </sect3>
+
+    <sect3>
+      <title>Zone files</title>  
+      <para>
+        An example master 'foobardomain.org' (existing within 
+        /etc/namedb/foobardomain.org) is as follows:
+      </para>
+
+      <programlisting>
+$TTL 3600
+
+foobardomain.org. IN SOA ns1.foobardomain.org. admin.foobardomain.org. (
+                        5               ; Serial
+                        10800           ; Refresh
+                        3600            ; Retry
+                        604800          ; Expire
+                        86400 )         ; Minimum TTL
+
+; DNS Servers
+@       IN NS           ns1.foobardomain.org.
+@       IN NS           ns2.foobardomain.org.
+
+; Machine Names
+localhost       IN A    127.0.0.1
+ns1             IN A    3.2.1.2
+ns2             IN A    3.2.1.3
+mail            IN A    3.2.1.10
+@               IN A    3.2.1.30
+
+; Aliases
+www             IN CNAME        @
+
+; MX Record
+@               IN MX   10      mail.foobardomain.org.
+      </programlisting>
+
+      <para>
+        Note that every hostname ending in a '.' is an exact hostname, whereas
+        everything without a trailing '.' is referenced to the origin.  For 
+        example, www is transalated into www + origin.  In our ficitious zone 
+        file, our origin is foobardomain.org, so www would be 
+        www.foobardomain.org.
+      </para>
+
+      <para>
+        The format of this file follows:
+      </para>
+      <programlisting>recordname      IN recordtype  value</programlisting>
+
+      <para>
+        The most commonly used DNS records:
+      </para>
+      <para><emphasis>SOA</emphasis> - start of zone authority</para>
+      <para><emphasis>NS</emphasis> - an authoritative nameserver</para>
+      <para><emphasis>A</emphasis> - A host address</para>
+      <para><emphasis>CNAME</emphasis> - the canonical name for an alias</para>
+      <para><emphasis>MX</emphasis> - mail exchange</para>
+      <para><emphasis>PTR</emphasis> - a domain name pointer (used in reverse 
+        dns)</para>
+      <programlisting>
+foobardomain.org. IN SOA ns1.foobardomain.org. admin.foobardomain.org. (
+                        5               ; Serial
+                        10800           ; Refresh after 3 hours
+                        3600            ; Retry after 1 hour
+                        604800          ; Expire after 1 week
+                        86400 )         ; Minimum TTL of 1 day
+      </programlisting>
+      <para>
+        <emphasis>foobardomain.org.</emphasis> - the domain name, also the 
+          origin for this zone file.
+      </para>
+      <para><emphasis>ns1.foobardomain.org.</emphasis> - the 
+        primary/authoritative nameserver for this zone
+      </para>
+      <para><emphasis>admin.foobardomain.org.</emphasis> - the responsible
+        person for this zone, e-mail address with @ replaced. 
+        (admin@foobardomain.org becomes admin.foobardomain.org)
+      </para>
+      <para>
+      <emphasis>5</emphasis> - the serial number of the file.  this must be
+        incremented each time the zone file is modified.  Nowadays, many 
+        admins prefer a yyyymmddrr format for the serial number.  2001041002
+        would mean last modified 04/10/2001, the latter 02 being the second
+        time the zone file has been modified this day.  The serial number is
+        important as it alerts slave nameservers for a zone when it is updated.
+      </para>
+
+      <programlisting>
+@       IN NS           ns1.foobardomain.org.
+      </programlisting>
+      <para>
+        This is an NS entry.  Every nameserver that is going to reply
+        authoritatively for the zone must have one of these entries.  The @ 
+        is seen here could have been 'foobardomain.org.' The @ transalates to 
+        the origin.
+      </para>
+
+      <programlisting>
+localhost       IN A    127.0.0.1
+ns1             IN A    3.2.1.2
+ns2             IN A    3.2.1.3
+mail            IN A    3.2.1.10
+@               IN A    3.2.1.30
+      </programlisting>
+      <para>
+        The A record indicates machine names.  As seen above, 
+        ns1.foobardomain.org would resolve to 3.2.1.2.  Again, the origin 
+        symbol, @, is used here, thus meaning foobardomain.org would resolve 
+        to 3.2.1.30.
+      </para>
+
+      <programlisting>
+www             IN CNAME        @
+      </programlisting>
+      <para>
+        The canonical name record is usually used for giving aliases to a 
+        machine.  In the example, www is aliased to the machine addressed to 
+        the origin, or foobardomain.org (3.2.1.30).  CNAMEs can be used to 
+        provide alias hostnames, or round robin one hostname among multiple
+        machines.
+      </para>
+
+      <programlisting>
+@               IN MX   10      mail.foobardomain.org.
+      </programlisting>
+
+      <para>
+        The MX record indictes which mail servers are responsible for handling 
+        incoming mail for the zone.  mail.foobardomain.org is the hostname of 
+        the mail server, and 10 being the priority of that mailserver.
+      </para>
+
+      <para>
+        One can have several mailservers, with priorities of 3, 2, 1.  A mail
+        server attempting to deliver to foobardomain.org would first try the
+        highest priority MX, then the second highest, etc, until the mail can
+        be properly delivered.
+      </para>
+
+      <para>
+        For in-addr.arpa zone files (reverse dns), the same format is used,
+        except with PTR entries instead of A or CNAME.
+      </para>
+
+      <programlisting>
+$TTL 3600
+
+1.2.3.in-addr.arpa. IN SOA ns1.foobardomain.org. admin.foobardomain.org. (
+                        5               ; Serial
+                        10800           ; Refresh
+                        3600            ; Retry
+                        604800          ; Expire
+                        3600 )          ; Minimum
+
+@       IN NS   ns1.foobardomain.org.
+@       IN NS   ns2.foobardomain.org.
+
+2       IN PTR  ns1.foobardomain.org.
+3       IN PTR  ns2.foobardomain.org.
+10      IN PTR  mail.foobardomain.org.
+30      IN PTR  foobardomain.org. 
+      </programlisting>
+      <para>
+       This file gives the proper ip to hostname mappings of our above
+       ficticious domain.
+      </para>
+  </sect3>
+</sect2>
+
+<sect2>
+  <title>Caching Name Server</title>
+  <para>
+    A caching nameserver is simply a nameserver that is not authoritative for
+    any zones.  It simply asks queries of its own, and remembers them for 
+    later use.  To set one up, just configure the name server as usual, omitting any inclusions of zones.
+  </para>
+</sect2>
+
+<sect2>
+  <title>How to use the nameserver</title>
+
+  <para>If setup properly, the nameserver should be accessible through the
+    network and locally.  <filename>/etc/resolv.conf</filename> must contain 
+    a nameserver entry with the local ip so it will query the local name 
+    server first.
+  </para>
+
+  <para>
+    To access it over the network, the machine must have the nameserver's ip 
+    set properly in its own nameserver configuration options.
+  </para>
+</sect2>
+
+<sect2>
+  <title>Security</title>
+
+  <para>Although BIND is the most common implementation of DNS, there is 
+    always the issue of security.  Possible and exploitable security holes 
+    are sometimes found.
+  </para>
+
+  <para>
+    It is a good idea to subscribe to <ulink url="http://www.cert.org">CERT</ulink>
+     and
+    <ulink url="http://www.freebsd.org/handbook/eresources.html#ERESOURCES-MAIL">freebsd-announce</ulink>
+    to stay up to date with the current Internet and FreeBSD security issues.
+  </para>
+
+  <para>
+    If a problem arises, keeping your sources up to date and having a fresh 
+    build of named can't hurt.
+  </para>
+</sect2>
+
+<sect2>
+  <title>Further Reading</title>
+  <para>
+  &man.ndc.8; &man.named.8; &man.named.conf.5;
+  </para>
+
+  <para>
+  Official ISC BIND Page
+  <ulink url="http://www.isc.org/products/BIND/">http://www.isc.org/products/BIND/</ulink>
+  </para>
+
+  <para>
+  BIND FAQ
+  <ulink url="http://www.nominum.com/resources/faqs/bind-faqs.html">
+  http://www.nominum.com/resources/faqs/bind-faqs.html</ulink>
+  </para>
+
+  <para>
+  <ulink url="http://www.oreilly.com/catalog/dns4/">O'Reilly DNS and BIND 4th Edition</ulink>
+  </para>
+
+  <para>
+  <ulink url="http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1034.txt">RFC1034 - Domain Names - 
+    Concepts and Facilities</ulink>
+  </para>
+
+  <para>
+  <ulink url="http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1035.txt">RFC1035 - Domain Names - 
+   Implementation and Specification</ulink>
+  </para>
+</sect2>
+
+</sect1>
+
 </chapter>
 
-<!-- 
+<!--
      Local Variables:
      mode: sgml
      sgml-declaration: "../chapter.decl"