Take #2. Import bind-4.9.4-P1 into the intended directory!

This has most of the non-essential stuff removed (ie: what is not built)

bmake glue to follow.

24 files changed, 6827 insertions, 0 deletions

diff --git a/contrib/bind/doc/bog/00macs.me b/contrib/bind/doc/bog/00macs.me
new file mode 100644
index 0000000..8ce02a2
--- /dev/null
+++ b/contrib/bind/doc/bog/00macs.me
@@ -0,0 +1,51 @@
+.\" Copyright (c) 1986, 1988 Regents of the University of California.
+.\" All rights reserved.
+.\"
+.\" Redistribution and use in source and binary forms are permitted
+.\" provided that this notice is preserved and that due credit is given
+.\" to the University of California at Berkeley. The name of the University
+.\" may not be used to endorse or promote products derived from this
+.\" software without specific prior written permission. This software
+.\" is provided ``as is'' without express or implied warranty.
+.\"
+.\"	@(#)00macs.me	6.3 (Berkeley) 2/28/88
+.\"
+.\" usage:	troff -me myfile
+.nr EX 0
+.de BX
+.sp
+.ba +4
+.lp
+.nr EX +1
+.b
+.ta (\\n(.lu-\\n(.iu)R
+EXAMPLE \\n(EX:	\(*D
+.r
+.lp
+..
+.de EX
+.br
+.ba
+.b
+.tl '''\(gr'
+.r
+.lp
+..
+.if \nl .ls 2
+.if t .nr bi 5m
+.nr si 3n
+.de $0		\" create a table of contents magically.
+.(x
+.ti (\\$3u-1u)*2m
+\\$2.  \\$1
+.)x
+..
+.de $1
+.sp
+..
+.de BU
+.ip "\ \(bu" \w'\ \(bu\ 'u
+..
+.de SM
+\s-1\\$1\s0\\$2
+..
diff --git a/contrib/bind/doc/bog/00title.me b/contrib/bind/doc/bog/00title.me
new file mode 100644
index 0000000..616202b
--- /dev/null
+++ b/contrib/bind/doc/bog/00title.me
@@ -0,0 +1,94 @@
+.\" ++Copyright++ 1986, 1988
+.\" -
+.\" Copyright (c) 1986, 1988
+.\"    The Regents of the University of California.  All rights reserved.
+.\" 
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\" 	This product includes software developed by the University of
+.\" 	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\" 
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\" -
+.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
+.\" 
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies, and that
+.\" the name of Digital Equipment Corporation not be used in advertising or
+.\" publicity pertaining to distribution of the document or software without
+.\" specific, written prior permission.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
+.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
+.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+.\" SOFTWARE.
+.\" -
+.\" --Copyright--
+.\"
+.+c
+.(l C
+.sz 14
+.b "Name Server Operations Guide"
+.b "for \s-1BIND\s+1"
+.sz
+\fIRelease 4.9.4\fP
+.eh 'SMM:10-%''Name Server Operations Guide for \s-1BIND\s+1'
+.oh 'Name Server Operations Guide for \s-1BIND\s+1''\s-1SMM\s+1:10-%'
+.sp
+\fIReleases from 4.9\fP
+Paul Vixie\**
+.(f
+\** This author was employed by Digital Equipment Corporation's
+Network Systems Laboratory during the development and release of
+\s-1BIND\s+1 4.9.  Release 4.9.2 was sponsored by Vixie
+Enterprises.  Releases from 4.9.3 were sponsored by the Internet
+Software Consortium.
+.)f
+<paul@vix.com>
+.sp \n(psu
+Internet Software Consortium
+La Honda, CA
+.sp 2
+\fIReleases through 4.8.3\fP
+Kevin J. Dunlap\**
+Michael J. Karels
+.sp \n(psu
+Computer Systems Research Group
+Computer Science Division
+Department of Electrical Engineering and Computer Sciences
+University of California
+Berkeley, CA  94720
+.)l
+.sp 2
+.(f
+\** This author was an employee of Digital Equipment Corporation's
+\s-1ULTRIX\s+1 Engineering Advanced Development Group and was on loan to
+CSRG when this work was done.  \s-1ULTRIX\s+1 is a trademark of Digital
+Equipment Corporation.
+.)f
diff --git a/contrib/bind/doc/bog/Makefile b/contrib/bind/doc/bog/Makefile
new file mode 100644
index 0000000..3cd50eb
--- /dev/null
+++ b/contrib/bind/doc/bog/Makefile
@@ -0,0 +1,90 @@
+# ++Copyright++ 1986, 1988
+# -
+# Copyright (c) 1986, 1988
+#    The Regents of the University of California.  All rights reserved.
+# 
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+# 1. Redistributions of source code must retain the above copyright
+#    notice, this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright
+#    notice, this list of conditions and the following disclaimer in the
+#    documentation and/or other materials provided with the distribution.
+# 3. All advertising materials mentioning features or use of this software
+#    must display the following acknowledgement:
+# 	This product includes software developed by the University of
+# 	California, Berkeley and its contributors.
+# 4. Neither the name of the University nor the names of its contributors
+#    may be used to endorse or promote products derived from this software
+#    without specific prior written permission.
+# 
+# THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+# SUCH DAMAGE.
+# -
+# Portions Copyright (c) 1993 by Digital Equipment Corporation.
+# 
+# Permission to use, copy, modify, and distribute this software for any
+# purpose with or without fee is hereby granted, provided that the above
+# copyright notice and this permission notice appear in all copies, and that
+# the name of Digital Equipment Corporation not be used in advertising or
+# publicity pertaining to distribution of the document or software without
+# specific, written prior permission.
+# 
+# THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
+# WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
+# OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
+# CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+# DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+# PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+# ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+# SOFTWARE.
+# -
+# --Copyright--
+#
+#	@(#)Makefile	6.3 (Berkeley) 2/28/88
+#
+FILES=	00macs.me 00title.me intro.me ns.me types.me\
+	files.me named.boot.primary\
+	named.boot.secondary named.boot.cache resolv.conf\
+	root.cache named.local ucbhosts.rev ucbhosts \
+	setup.me manage.me build.me ack.me
+ME=	-me
+NROFF=	nroff -rb3
+PRINTER= -Pdp
+TBL=	dtbl $(PRINTER)
+TROFF= ditroff $(PRINTER)
+GROFF= groff -Tps -t $(ME)
+
+all: file.lst
+
+file.lst: $(FILES)
+	tbl $(FILES)| $(NROFF) $(ME) $(FLAGS) > file.lst
+
+file.psf: $(FILES)
+	$(GROFF) $(FILES) > file.psf
+
+troff: $(FILES)
+	$(TBL) $(FILES)| $(TROFF) $(ME) $(FLAGS)
+
+cat: $(FILES)
+	@cat $(FILES)
+
+clean:
+	rm -f *.psf *.lst *.BAK *.CKP *~ *.orig
+	rm -f file
+
+spell: $(FILES)
+	@for i in $(FILES); do \
+		echo $$i; \
+		spell $$i | sort | comm -23 - spell.ok > $$i.spell; \
+	done
diff --git a/contrib/bind/doc/bog/ack.me b/contrib/bind/doc/bog/ack.me
new file mode 100644
index 0000000..5c02c14
--- /dev/null
+++ b/contrib/bind/doc/bog/ack.me
@@ -0,0 +1,287 @@
+.\" ++Copyright++ 1986, 1988
+.\" -
+.\" Copyright (c) 1986, 1988
+.\"    The Regents of the University of California.  All rights reserved.
+.\" 
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\" 	This product includes software developed by the University of
+.\" 	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\" 
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\" -
+.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
+.\" 
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies, and that
+.\" the name of Digital Equipment Corporation not be used in advertising or
+.\" publicity pertaining to distribution of the document or software without
+.\" specific, written prior permission.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
+.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
+.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+.\" SOFTWARE.
+.\" -
+.\" --Copyright--
+.\"
+.\"	@(#)ack.me
+.\"
+.sx 0
+.bp
+.ce
+.b "ACKNOWLEDGEMENTS \(em 4.9.3"
+.pp
+The \fI<bind-workers@vix.com>\fP mailing list was once again of great help;
+this release would not be nearly as ready for prime time if not for their
+efforts.  Special commendations are owed to Robert Elz, Don "Truck" Lewis,
+Bob Halley, Mark Andrews, Berthold Paffrath, Ruediger Volk, and Peter Koch.
+.pp
+Digital Equipment Corporation, Hewlett Packard, Silicon Graphics, and SunSoft
+all made hardware available for integration testing; this made the release
+far more solid than it would otherwise have been.  More hardware loans are
+welcome \(em if you are a system vendor and you would like \s-2BIND\s+2 to
+run ``out of the box'' on your platform and are willing to lend some rusty
+old hardware for the purpose, please contact me (\fI<paul@vix.org>\fP) to
+make the arrangements.
+.pp
+Special thanks to the Internet Software Consortium for funding this work.
+Contact \fI<isc-info@isc.org>\fP if your organization would like to
+participate in funding future releases of \s-2BIND\s+2 and other freely
+redistributable software packages that are in wide use on the Internet.
+.sp 2
+.ce
+.b "ACKNOWLEDGEMENTS \(em through 4.9"
+.pp
+The alpha-test group was extremely helpful in furnishing improvements,
+finding and repairing bugs, and being patient.  I would like to express
+special thanks to Brian Reid of Digital Equipment corporation for funding
+this work.  Robert Elz, Alan Barrett, Paul Albitz, Bryan Beecher, Andrew
+Partan, Andy Cherenson, Tom Limoncelli, Berthold Paffrath, Fuat Baran, Anant
+Kumar, Art Harkin, Win Treese, Don Lewis, Christophe Wolfhugel, and a cast
+of dozens all helped out above and beyond the call of duty.  Special thanks
+to Phil Almquist, who got the project started and contributed a lot of the
+code and fixed several of the worst bugs.
+.sp 2
+.ce
+.b "ACKNOWLEDGEMENTS \(em through 4.8.3"
+.pp
+Many thanks to the users at U. C. Berkeley for falling into many of the holes
+involved with integrating BIND into the system so that others would be
+spared the trauma.  I would also like to extend gratitude to Jim McGinness
+and Digital Equipment Corporation for permitting me to spend most of my time
+on this project.
+.pp
+Ralph Campbell, Doug Kingston, Craig Partridge, Smoot Carl-Mitchell, Mike
+Muuss and everyone else on the DARPA Internet who has contributed to the
+development of BIND.  To the members of the original BIND project, Douglas
+Terry, Mark Painter, David Riggle and Songnian Zhou.
+.pp
+Anne Hughes, Jim Bloom and Kirk McKusick and the many others who have
+reviewed this paper giving considerable advice.
+.pp
+This work was sponsored by the Defense Advanced Research Projects Agency
+(DoD), Arpa Order No. 4871 monitored by the Naval Electronics Systems
+Command under contract No. N00039-84-C-0089.  The views and conclusions
+contained in this document are those of the authors and should not be
+interpreted as representing official policies, either expressed or implied,
+of the Defense Research Projects Agency, of the US Government, or of Digital
+Equipment Corporation.
+.bp
+.ba 0
+.in 0
+.sp 2
+.ce
+.b REFERENCES
+.sp
+.nr ii 1i
+.ip [Birrell]
+Birrell, A. D.,
+Levin, R.,
+Needham, R. M.,
+and Schroeder, M.D.,
+.q "Grapevine: An Exercise in Distributed Computing."
+In
+.ul
+Comm. A.C.M. 25,
+4:260-274
+April 1982.
+.ip [RFC819]
+Su, Z.
+Postel, J.,
+.q "The Domain Naming Convention for Internet User Applications."
+.ul
+Internet Request For Comment 819
+Network Information Center,
+SRI International,
+Menlo Park, California.
+August 1982.
+.ip [RFC974]
+Partridge, C.,
+.q "Mail Routing and The Domain System."
+.ul
+Internet Request For Comment 974
+Network Information Center,
+SRI International,
+Menlo Park, California.
+February 1986.
+.ip [RFC1032]
+Stahl, M.,
+.q "Domain Administrators Guide"
+.ul
+Internet Request For Comment 1032
+Network Information Center,
+SRI International,
+Menlo Park, California.
+November 1987.
+.ip [RFC1033]
+Lottor, M.,
+.q "Domain Administrators Guide"
+.ul
+Internet Request For Comment 1033
+Network Information Center,
+SRI International,
+Menlo Park, California.
+November 1987.
+.ip [RFC1034]
+Mockapetris, P.,
+.q "Domain Names - Concept and Facilities."
+.ul
+Internet Request For Comment 1034
+Network Information Center,
+SRI International,
+Menlo Park, California.
+November 1987.
+.ip [RFC1035]
+Mockapetris, P.,
+.q "Domain Names - Implementation and Specification."
+.ul
+Internet Request For Comment 1035
+Network Information Center,
+SRI International,
+Menlo Park, California.
+November 1987.
+.ip [RFC1101]
+Mockapetris, P.,
+.q "DNS Encoding of Network Names and Other Types."
+.ul
+Internet Request For Comment 1101
+Network Information Center,
+SRI International,
+Menlo Park, California.
+April 1989.
+.ip [RFC1123]
+R. Braden, Editor,
+.q "Requirements for Internet Hosts -- Application and Support"
+.ul
+Internet Request For Comment 1123
+Network Information Center,
+SRI International,
+Menlo Park, California.
+October 1989.
+.ip [RFC1183]
+Everhart, C.,
+Mamakos, L.,
+Ullmann, R.,
+and
+Mockapetris, P.,
+.q "New DNS RR Definitions"
+.ul
+Internet Request For Comment 1183
+Network Information Center,
+SRI International,
+Menlo Park, California.
+October 1990.
+.ip [RFC1327]
+Hardcastle-Kille, S.,
+.q "Mapping between X.400(1988) / ISO 10021 and RFC 822"
+.ul
+Internet Request For Comment 1327
+Network Information Center,
+SRI International,
+Menlo Park, California.
+May 1992.
+.ip [RFC1664]
+Allocchio, C.,
+Bonito, A.,
+Cole, B.,
+Giordano, S.,
+Hagens, R.,
+.q "Using the Internet DNS to Distribute RFC1327 Mail Address Mapping Tables"
+.ul
+Internet Request For Comment 1664
+Network Information Center,
+SRI International,
+Menlo Park, California.
+August 1994.
+.ip [RFC1713]
+Romao, A.,
+.q "Tools for DNS debugging"
+.ul
+Internet Request For Comment 1713, also FYI27
+Network Information Center,
+SRI International,
+Menlo Park, California.
+November 1994.
+.ip [Terry]
+Terry, D. B.,
+Painter, M.,
+Riggle, D. W.,
+and
+Zhou, S.,
+.ul
+The Berkeley Internet Name Domain Server.
+Proceedings USENIX Summer Conference,
+Salt Lake City, Utah.
+June 1984, pages 23-31.
+.ip [Zhou]
+Zhou, S.,
+.ul
+The Design and Implementation of the Berkeley Internet Name Domain (BIND) Servers.
+UCB/CSD 84/177.
+University of California, Berkeley,
+Computer Science Division.
+May 1984.
+.ip [Mockapetris]
+Mockapetris, P.,
+Dunlap, K,
+.ul
+Development of the Domain Name System
+ACM Computer Communications Review 18, 4:123-133.
+Proceedings ACM SIGCOMM '88  Symposium,
+August 1988.
+.ul
+.ip [Liu]
+Liu, C.,
+Albitz, P.,
+.ul
+DNS and BIND
+O'Reilly & Associates, Sebastopol, CA, 
+502 pages, ISBN 0-937175-82-X
+1992
diff --git a/contrib/bind/doc/bog/build.me b/contrib/bind/doc/bog/build.me
new file mode 100644
index 0000000..d6dab9f
--- /dev/null
+++ b/contrib/bind/doc/bog/build.me
@@ -0,0 +1,102 @@
+.\" ++Copyright++ 1986, 1988
+.\" -
+.\" Copyright (c) 1986, 1988
+.\"    The Regents of the University of California.  All rights reserved.
+.\" 
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\" 	This product includes software developed by the University of
+.\" 	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\" 
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\" -
+.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
+.\" 
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies, and that
+.\" the name of Digital Equipment Corporation not be used in advertising or
+.\" publicity pertaining to distribution of the document or software without
+.\" specific, written prior permission.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
+.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
+.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+.\" SOFTWARE.
+.\" -
+.\" --Copyright--
+.\"
+.\"	@(#)build.me	6.3 (Berkeley) 9/19/89
+.\"
+.sh 1 "Building a System with a Name Server"
+.pp
+BIND is composed of two parts.  One is the user interface called the 
+\fIresolver\fP
+which consists of a group of routines that reside in the C library 
+\fI/lib/libc.a\fP.
+Second is the actual server called \fInamed\fP.
+This is a daemon that runs in the background and services queries on a 
+given network port. The standard port for UDP and TCP is specified in 
+\fI/etc/services\fP.
+.sh 2 "Resolver Routines in libc"
+.pp
+When building your 4.3BSD system you may either
+build the C library to use the name server resolver routines 
+or use the host table lookup routines to do host name and address resolution.
+The default resolver for 4.3BSD uses the name server.  Newer BSD systems
+include both name server and host table functionality with preference given
+to the name server if there is one or if there is a \fI/etc/resolv.conf\fP
+file.
+.pp
+Building the C library to use the name server changes the way
+\fIgethostbyname\fP\|(3N), \fIgethostbyaddr\fP\|(3N), and
+\fIsethostent\fP\|(3N) do their functions.  The name server renders
+\fIgethostent\fP\|(3N) obsolete, since it has no concept of a next line in
+the database.  These library calls are built with the resolver routines
+needed to query the name server.
+.pp
+The \fIresolver\fP contains functions that build query
+packets and exchange them with name servers.
+.pp
+Before building the 4.3BSD C library, set the variable \fIHOSTLOOKUP\fP
+equal to \fInamed\fP in \fI/usr/src/lib/libc/Makefile\fP.  You
+then make and install the C library and compiler and then compile the rest
+of the 4.3BSD system.  For more information see section 6.6 of ``Installing
+and Operating 4.3BSD on the VAX\(dd''.
+.(f
+\(ddVAX is a Trademark of Digital Equipment Corporation
+.)f
+.pp
+If your operating system isn't VAX\(dd 4.3BSD, it is probably the case that
+your vendor has included \fIresolver\fP support in the supplied C Library.
+You should consult your vendor's documentation to find out what has to be
+done to enable \fIresolver\fP support.  Note that your vendor's \fIresolver\fP
+may be out of date with respect to the one shipped with \s-1BIND\s+1, and that
+you might want to build \s-1BIND\s+1's resolver library and install it, and
+its include files, into your system's compile/link path so that your own
+network applications will be able to use the newer features.
diff --git a/contrib/bind/doc/bog/files.me b/contrib/bind/doc/bog/files.me
new file mode 100644
index 0000000..4a28da4
--- /dev/null
+++ b/contrib/bind/doc/bog/files.me
@@ -0,0 +1,1150 @@
+.\" ++Copyright++ 1986, 1988, 1995
+.\" -
+.\" Copyright (c) 1986, 1988, 1995
+.\"    The Regents of the University of California.  All rights reserved.
+.\" 
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\" 	This product includes software developed by the University of
+.\" 	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\" 
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\" -
+.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
+.\" 
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies, and that
+.\" the name of Digital Equipment Corporation not be used in advertising or
+.\" publicity pertaining to distribution of the document or software without
+.\" specific, written prior permission.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
+.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
+.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+.\" SOFTWARE.
+.\" -
+.\" --Copyright--
+.\"
+.\"	@(#)files.me	6.8 (Berkeley) 9/19/89
+.\"
+.sh 1 "Files
+.pp
+The name server uses several files to load its data base.
+This section covers the files and their formats needed for \fInamed\fP.
+.sh 2 "Boot File"
+.pp
+This is the file that is first read when \fInamed\fP starts up.
+This tells the server what type of server it is,
+which
+zones it has authority over and where to get its initial data.
+The default location for this file is \fI/etc\|/named.boot\fP\|.
+However this can be changed
+by setting the \fIBOOTFILE\fP variable when you compile \fInamed\fP 
+or by specifying
+the location on the command line when \fInamed\fP is started up.
+.sh 3 "Domain"
+.pp
+A default domain may be specified for the name server
+using a line such as
+.(b l
+.ta 0.5i +\w`secondary   `u +\w`berkeley.edu   `u +.5i +.5i
+\fIdomain 	Berkeley\fP\fB\|.\|\fP\fIEdu\fP
+.)b
+.re
+Older name servers use this information when they receive a query for a name
+without a ``\fB.\fP'' that is not known.  Newer designs assume that the
+resolver library will append its own idea of a ``default domain'' to any
+unqualified names.  Though the name server can still be compiled with
+support for the \fIdomain\fP directive in the boot file, the default is to
+leave it out and we strenuously recommend against its use.  If you use this
+feature, clients outside your local domain which send you requests about
+unqualified names will have the implicit qualification of your domain rather
+than theirs.  The proper place for this function is on the client, in their
+\fB/etc/resolv.conf\fP (or equivalent) file.  Use of the \fIdomain\fP
+directive in your boot file is strongly discouraged.
+.sh 3 "Directory"
+.pp
+The \fIdirectory\fP directive specifies the directory in which the name server
+should run, allowing the other file names in the boot file to use relative path
+names.  There can be only one \fIdirectory\fP directive and it should be given
+before any other directives that specify file names.
+.(b l
+.ta 0.5i +\w`secondary   `u +\w`berkeley.edu   `u +.5i +.5i
+\fIdirectory  	/var/named\fP
+.)b
+.re
+If you have more than a couple of named files to be maintained, you may wish
+to place the named files in a directory such as /var/named and adjust the
+directory command properly.  The main purposes of this command are to make
+sure named is in the proper directory when trying to include files by
+relative path names with $INCLUDE and to allow named to run in a location
+that is reasonable to dump core if it feels the urge.
+.sh 3 "Primary Service"
+.pp
+The line in the boot file that designates the server as a primary master server
+for a zone looks as follows:
+.(b l
+.ta 0.5i +\w`secondary   `u +\w`berkeley.edu   `u +.5i +.5i
+\fIprimary  	Berkeley\fP\fB\|.\|\fP\fIEdu	ucbhosts\fP
+.)b
+.re
+The first field specifies that the server is a primary one for the zone 
+stated in the second field.
+The third field is the name of the file from which the data is read.
+.pp
+The above assumes that the zone you are specifying is a class \fIIN\fP
+zone.  If you wish to designate a different class you can append
+\fI/class\fP to the first field, where \fIclass\fP is either the
+integer value or the standard mnemonic for the class.  For example the line 
+for a primary server for a hesiod class zone looks as follows:
+.(b l
+.ta 0.5i +\w`secondary   `u +\w`berkeley.edu   `u +.5i +.5i
+\fIprimary/HS         Berkeley\fP\fB\|.\|\fP\fIEdu    hesiod.data\fP
+.)b
+.re
+Note that this support for specifying other than class \fIIN\fP zones is a
+compile-time option which your vendor may not have enabled when they built
+your operating system.
+.sh 3 "Secondary Service"
+.pp
+The line for a secondary server is similar to the primary except
+that it lists addresses of other servers (usually primary servers)
+from which the zone data will be obtained.
+.(b l
+.ta 0.5i +\w`secondary   `u +\w`berkeley.edu   `u +\w`128.32.0.10  `u +\w`128.32.0.10  `u +.5i +.5i
+\fIsecondary	Berkeley\fP\fB\|.\|\fP\fIEdu	128\fP\fB.\fP\fI32\fP\fB.\fP\fI0\fP\fB.\fP\fI10	\fP\fI128\fP\fB.\fP\fI32\fP\fB.\fP\fI0\fP\fB.\fP\fI4\fP \fIucbhosts.bak\fP
+.)b
+.re
+The first field specifies that the server is a secondary server for
+the zone stated in the second field.
+The two network addresses specify the name servers which have data for the 
+zone.  Note that at least one of these will be a \fIprimary\fP, and, unless
+you are using some protocol other than \s-1IP/DNS\s+1 for your zone transfer
+mechanism, the others will all be other \fIsecondary\fP servers.  Having your
+secondary server pull data from other secondary servers is usually unwise,
+since you can add delay to the propagation of zone updates if your network's
+connectivity varies in pathological but common ways.  The intended use for
+multiple addresses on a \fIsecondary\fP declaration is when the \fIprimary\fP
+server has multiple network interfaces and therefore multiple host addresses.
+The secondary server gets its data across the network from one of the listed
+servers.  The server addresses are tried in the order listed.
+If a filename is present after the list of primary servers, data for the zone
+will be dumped into that file as a backup.
+When the server is first started, the data is loaded from the backup file
+if possible, and a primary server is then consulted to check that the zone
+is still up-to-date.  Note that listing your server as a \fIsecondary\fP
+server does not necessarily make it one \(em the parent zone must
+\fIdelegate\fP authority to your server as well as the primary and the
+other secondaries, or you will be transferring a zone over for no reason;
+no other server will have a reason to query you for that zone unless the
+parent zone lists you as a server for the zone.
+.pp
+As with primary you may specify a secondary server for a class other than
+\fIIN\fP by appending \fI/class\fP to the \fIsecondary\fP keyword, e.g.,
+\fIsecondary/HS\fP.
+.sh 3 "Stub Service"
+.pp
+The line for a stub server is similar to a secondary.
+(This feature is experimental as of 4.9.3.)
+.(b l
+.ta 0.5i +\w`stub   `u +\w`berkeley.edu   `u +\w`128.32.0.10  `u +\w`128.32.0.10  `u +.5i +.5i
+\fIstub	Berkeley\fP\fB\|.\|\fP\fIEdu	128\fP\fB.\fP\fI32\fP\fB.\fP\fI0\fP\fB.\fP\fI10	\fP\fI128\fP\fB.\fP\fI32\fP\fB.\fP\fI0\fP\fB.\fP\fI4\fP \fIucbhosts.bak\fP
+.)b
+.re
+The first field specifies that the server is a stub server for the zone stated
+in the second field.
+.pp
+Stub zones are intended to ensure that a primary for a zone always has the
+correct \fINS\fP records for children of that zone. If the primary is not
+a secondary for a child zone it should be configured with stub zones for
+all its children. Stub zones provide a mechanism to allow \fINS\fP records
+for a zone to be specified in only one place.
+.(b l
+.ta 0.5i +\w`primary   `u +\w`dms.csiro.au   `u +\w`130.155.98.1  `u +.5i +.5i
+\fIprimary	CSIRO\fP\fB\|.\|\fP\fIAU	\fIcsiro.dat\fP
+\fIstub	dms.CSIRO\fP\fB\|.\|\fP\fIAU	130\fP\fB.\fP\fI155\fP\fB.\fP\fI16\fP\fB.\fP\fI1	\fIdms.stub\fP
+\fIstub	dap.CSIRO\fP\fB\|.\|\fP\fIAU	130\fP\fB.\fP\fI155\fP\fB.\fP\fI98\fP\fB.\fP\fI1	\fIdap.stub\fP
+.)b
+.re
+.sh 3 "Cache Initialization"
+.pp
+All servers, including ``caching only'' servers, should have a line as
+follows in the boot file to prime the name servers cache:
+.(b l
+\fIcache		\fP\fB.\fP\fI	root\fP\fB.\fP\fIcache\fP
+.)b
+Do not put anything into your \fIcache\fP files other than root server
+information.
+.pp
+All cache files listed will be read in at named boot time and any values
+still valid will be reinstated in the cache.
+The root name server
+information in the cache files will be used until a root query is 
+actually answered by one of the name servers in the cache file, after
+which that answer will be used instead of the cache file until the answer
+times out.
+.pp
+As with \fIprimary\fP and \fIsecondary\fP, you may specify a secondary
+server for a class other than \fIIN\fP by appending \fI/class\fP to the
+\fIcache\fP keyword, e.g., \fIclass/HS\fP.
+.sh 3 "Forwarders"
+.pp
+Any server can make use of \fIforwarders\fP.  A \fIforwarder\fP is another
+server capable of processing recursive queries that is willing to try
+resolving queries on behalf of other systems.  The \fIforwarders\fP
+command specifies forwarders by internet address as follows:
+.(b l
+\fIforwarders		\fI128\fP\fB.\fP\fI32\fP\fB.\fP\fI0\fP\fB.\fP\fI10	\fP\fI128\fP\fB.\fP\fI32\fP\fB.\fP\fI0\fP\fB.\fP\fI4\fP
+.)b
+.re
+There are two main reasons for wanting to do so.  First, some systems may
+not have full network access and may be prevented from sending any IP
+packets into the rest of the Internet and therefore must rely on a forwarder
+which does have access to the full net.  The second reason is that the
+forwarder sees a union of all queries as they pass through its server and
+therefore it builds up a very rich cache of data compared to the cache in a
+typical workstation name server.  In effect, the \fIforwarder\fP becomes a
+meta-cache that all hosts can benefit from, thereby reducing the total
+number of queries from that site to the rest of the net.
+.pp
+The effect of ``forwarders'' is to prepend some fixed addresses to the list
+of name servers to be tried for every query.  Normally that list is made up
+only of higher-authority servers discovered via \fINS\fP record lookups for
+the relevant domain.  If the forwarders do not answer, then unless the
+\fIslave\fP directive was given, the appropriate servers for the domains
+will be queried directly.
+
+.sh 3 "Slave Servers"
+.pp
+Slave mode is used if the use of forwarders is the only possible way
+to resolve queries due to lack of full net access or if you wish to prevent
+the name server from using other than the listed forwarders.
+Slave mode is activated by placing the simple command
+.(b l
+\fIoptions forward-only\fP
+.)b
+in the bootfile.  If this option is used, then you must specify forwarders.
+When in slave mode, the server will forward each query to each of the the
+forwarders until an answer is found or the list of forwarders is exhausted.
+The server will not try to contact any remote name server other than those
+named in the \fIforwarders\fP list.
+.pp
+So while \fIforwarders\fP prepends addresses to the ``server list'' for each
+query, \fIoptions forward-only\fP causes the ``server list'' to contain
+\fIonly\fP those addresses listed in the \fIforwarders\fP declarations.
+Careless use of the \fIoptions forward-only\fP directive can cause really
+horrible forwarding loops, since
+you could end up forwarding queries only to some set of hosts which are also
+slaves, and one or several of them could be forwarding queries back to you.
+.pp
+Use of the \fIoptions forward-only\fP directive should be considered very
+carefully.  Note that this same behaviour can be achieved using the deprecated
+directive, \fIslave\fP.
+
+.sh 3 "Nonrecursive Servers"
+.pp
+\s-1BIND\s+1's separation of authoritative (zone) and nonauthoritiative (cache)
+data has always been somewhat weak, and pollution of the former via the latter
+has been known to occur.  One way to prevent this, as well as to save memory on
+servers carrying a lot of authoritative data (e.g., root servers) is to make
+such servers ``nonrecursive.''  This can be achieved via the directive
+.(b l
+\fIoptions no-recursion\fP
+.)b
+in the bootfile.  A server with this option enabled will not attempt to fetch
+data to help answer queries \(em if you ask it for data it does not have, it
+will send you a referral to a more authoritative server or, if it is itself
+authoritative for the zone of the query, it will send you an negative answer.
+.pp
+A nonrecursive server can be named in an \s-1NS\ RR\s+1 but it cannot be listed
+in the \fIresolv.conf\fP file.
+
+.sh 3 "Query Logging"
+.pp
+If the file system containing your \fIsyslog\fP file has quite a bit of space,
+you can consider using the
+.(b l
+\fIoptions query-log\fP
+.)b
+directive in your bootfile.  This will cause your name server to log every
+query it receives, which when combined with a Perl or \s-1AWK\s+1 script to
+postprocess the logs, can be a useful management tool.
+
+.sh 3 "Inverse Query Pseudosupport"
+.pp
+\s-1BIND\s+1 by default does not support inverse queries, and this has been
+known to cause problems for certain microcomputer operating systems and for
+older versions of \s-1BIND\s+1's \fInslookup\fP tool.  You may decide that
+rather than answering with ``operation not implemented,'' \fInamed\fP should
+detect the most common inverse queries and answer them with bogus information.
+It is better to upgrade your clients to stop depending on inverse queries, but
+if that is not possible, you should use the
+.(b l
+\fIoptions fake-iquery\fP
+.)b
+directive in your bootfile.  \fINOTE:\fP the responses are in fact bogus, in
+that they contain \s-1ISO\s+18859 square brackets (\fB[\fP and \fB]\fP), so
+your clients will not be able to do anything useful with these responses.  It
+has been observed that no client ever did anything useful with real inverse
+query responses, either.
+
+.sh 3 "Setting Name Server Limits"
+.pp
+Some name server operations can be quite resource intensive, and in order to
+tune your system properly it is sometimes necessary to change \s-1BIND\s+1's
+internal quotas.  This is accomplished via
+.(b l
+\fIlimit <name> <value>\fP
+.)b
+directives in the bootfile.  Limits, and their default values, are as follows:
+.(b I
+\fIlimit transfers-in 10\fP
+.)b
+This is the number of simultaneous \fInamed-xfer\fP processes \s-1BIND\s+1 is
+willing to start.  Higher numbers yield faster convergence to primary servers
+if your secondary server has hundreds or thousands of zones to maintain, but
+setting this number too high can cause thrashing due to starvation of resources
+such as network bandwidth or swap space.  \fINOTE:\fP this limit can also be
+expressed via the deprecated directive \fImax-fetch NN\fP.
+.(b I
+\fIlimit transfers-per-ns 2\fP
+.)b
+This is the number of simultaneous \fInamed-xfer\fP processes \s-1BIND\s+1 is
+willing to initiate \fIto any given name server\fP.  In most cases, you should
+not need to change it.  If your secondary server is pulling hundreds or
+thousands of zones from a single primary server, increasing
+\fItransfers-per-ns\fP may speed convergence.  It should be kept as
+small as possible, to avoid causing thrashing and resource starvation
+on the primary server.
+.(b I
+\fIlimit datasize <system-dependent>\fP
+.)b
+Most systems have a quota that limits the size of the so-called ``data
+segment,'' which is where \s-1BIND\s+1 keeps all of its authority and cache
+data.  \s-1BIND\s+1 will behave suboptimally (perhaps even exiting) if it runs
+up against this quota.  If your system supports a system call to change this
+quota for a given process, you can ask \s-1BIND\s+1 to use that system call
+via the \fIlimit datasize NN\fP directive.  The value given here may be scaled
+by postfixing \fIk\fP for 1024X, \fIm\fP for (1024^2)X, and \fIg\fP for
+(1024^3)X.  In 1995, the root servers all use \fIlimit datasize 64m\fP.
+
+.sh 3 "Zone Transfer Restrictions"
+.pp
+It may be the case that your organization does not wish to give complete
+lists of your hosts to anyone on the Internet who can reach your name servers.
+While it is still possible for people to ``iterate'' through your address
+range, looking for \fIPTR\fP records, and build a list of your hosts the
+``slow'' way, it is still considered reasonable to restrict your export of
+zones via the zone transfer protocol.  To limit the list of neighbors who
+can transfer zones from your server, use the \fIxfrnets\fP directive.
+.pp
+This directive has the same syntax as \fIforwarders\fP except that you can
+list network numbers in addition to host addresses.  For example, you could
+add the directive
+.(b l
+\fIxfrnets 16.0.0.0\fP
+.)b
+.re
+if you wanted to permit only hosts on Class A network number 16 to transfer
+zones from your server.  This is not nearly granular enough, and a future
+version of \s-1BIND\s+1 will permit such access-control to be specified on a
+per-host basis rather than the current per-net basis.  Note that while
+addresses without explicit masks are assumed by this directive to be networks,
+you can specify a mask which is as granular as you wish, perhaps including
+all bits of the address such that only a single host is given transfer
+permission.  For example, consider
+.(b l
+\fIxfrnets 16.1.0.2&255.255.255.255\fP
+.)b
+which would permit only host \fI16.1.0.2\fP to transfer zones from you.  Note
+that no spaces are allowed surrounding the ``\fI&\fP'' character that 
+introduces a netmask.
+.pp
+The \fIxfrnets\fP directive may also be given as \fItcplist\fP for
+compatibility with interim releases of \s-1BIND\s+1 4.9.
+
+.sh 3 "Sorting Addresses"
+.pp
+If there are multiple addresses available for a name server which \s-1BIND\s+1
+wants to contact, \s-1BIND\s+1 will try the ones it believes are ``closest''
+first.  ``Closeness'' is defined in terms of similarity-of-address; that is,
+if one address is on the same \fIsubnet\fP as some interface of the local host,
+then that address will be tried first.  Failing that, an address which is on
+the same \fInetwork\fP will be tried first.  Failing that, they will be tried
+in a more-or-less random order unless the \fIsortlist\fP directive was given
+in the \fInamed.boot\fP file.  \fIsortlist\fP has a syntax similar to
+\fIforwarders\fP, \fIxfrnets\fP, and \fIbogusns\fP \(em you give it a list
+of dotted-quad networks and it uses these to ``prefer'' some remote name server
+addresses over others.  If no explicit mask is provided with each element of
+a \fIsortlist\fP, one will be inferred based on the high order address bits.
+.pp
+If you are on a Class C net which has a Class B net between you and the rest
+of the Internet, you could try to improve the name server's luck in getting
+answers by listing the Class B network's number in a \fIsortlist\fP
+directive.  This should have the effect of trying ``closer'' servers before
+the more ``distant'' ones.  Note that this behaviour is new as of \s-1BIND
+4.9\s+1.
+.pp
+The other and older effect of the \fIsortlist\fP directive is to cause
+\s-1BIND\s+1 to sort the \fIA\fP records in any response it generates, so as
+to put those which appear on the \fIsortlist\fP earlier than those which do
+not.  This is not as helpful as you might think, since many clients will
+reorder the \fIA\fP records either at random or using \s-1LIFO\s+1; also,
+consider the fact that the server won't be able to guess the client's network
+topology, and so will not be able to accurately order for ``closeness'' to
+all possible clients.  Doing the ordering in the resolver is clearly superior.
+.pp
+In actual practice, this directive is used only rarely since it hardwires
+information which changes rapidly; a network which is ``close'' today may
+be ``distant'' next month.  Since \s-1BIND\s+1 builds up a cache of the
+remote name servers' response times, it will quickly converge on
+``reasonable'' behaviour, which isn't the same as ``optimal'' but it's
+close enough.  Future directions for \s-1BIND\s+1 include choosing
+addresses based on local interface metrics (on hosts that have more than
+one) and perhaps on routing table information.  We do not intend to solve
+the generalized ``multihomed host'' problem, but we should be able to do a
+little better than we're doing now.  Likewise, we hope to see a higher
+level resolver library that sorts responses using topology information that
+only exists on the client's host.
+
+.sh 3 "Bogus Name Servers"
+.pp
+It happens occasionally that some remote name server goes ``bad''.  You can
+tell your name server to refuse to listen to or ask questions of certain
+other name servers by listing them in a \fIbogusns\fP directive in your
+\fInamed.boot\fP file.  Its syntax is the same as \fIforwarders\fP,
+\fIxfrnets\fP, and \fIsortlist\fP \(em you just give it a list of dotted-quad
+Internet addresses.  Note that zones delegated to such servers will not be
+reachable from clients of your servers; thus you should use this directive
+sparingly or not at all.
+
+.sh 3 "Segmented Boot Files"
+.pp
+If you are secondary for a lot of zones, you may find it convenient to split
+your \fInamed.boot\fP file into a static portion which hardly ever changes
+(directives such as \fIdirectory\fP, \fIsortlist\fP, \fIxfrnets\fP and
+\fIcache\fP could go here), and dynamic portions that change frequently
+(all of your \fIprimary\fP directives might go in one file, and all of your
+\fIsecondary\fP directives might go in another file \(em and either or both
+of these might be fetched automatically from some neighbor so that they can
+change your list of secondary zones without requiring your active
+intervention).  You can accomplish this via the \fIinclude\fP directive,
+which takes just a single file name as its argument.  No quotes are needed
+around the file name.  The file name will be evaluated after the name server
+has changed its working directory to that specified in the \fIdirectory\fP
+directive, so you can use relative pathnames if your system supports them.
+
+.sh 2 "Resolver Configuration"
+.pp
+The configuration file's name is \fI/etc/resolv.conf\fP.
+This file designates the name servers on the network that should 
+be sent queries.
+The resolver will try to contact a name server on the localhost if it cannot
+find its configuration file.  You should install the configuration file
+on every host anyway, since this is the only recommended way to specify a
+system-level default domain, and you can still list the local host's address
+if it runs a name server.
+It is considered reasonable to create this file even if you run a local
+server, since its contents will be cached by each client of the resolver
+library when the client makes its first call to a resolver routine.
+.pp
+The \fIresolv.conf\fP file contains directives, one per line, of the
+following forms:
+.(l I
+; comment
+# another comment
+domain \fIlocal-domain\fP
+search \fIsearch-list\fP
+nameserver \fIserver-address\fP
+sortlist \fIsort-list\fP
+options \fIoption-list\fP
+.)l
+Exactly one of the \fIdomain\fP or \fIsearch\fP directives should be given,
+exactly once.
+If the \fIsearch\fP directive is given, the first item in the given
+\fIsearch-list\fP will override any previously-specified \fIlocal-domain\fP.
+The \fInameserver\fP directive may be given up to three times; additional
+\fInameserver\fP directives will be ignored.  Comments may be given by
+starting a line with a ``\fB\|;\|\fP'' or ``\fB\|#\|\fP''; note that
+comments were not permitted in versions of the resolver earlier than the one
+included with \s-1BIND 4.9\s+1 \(em so if your vendor's resolver supports
+comments, you know they are really on the ball.
+.pp
+The \fIlocal-domain\fP will be appended to any query-name that does not
+contain a ``\fB\|.\|\fP''.  \fIlocal-domain\fP can be overridden on a 
+per-process basis by setting the \s-1LOCALDOMAIN\s+1 environment variable.
+Note that \fIlocal-domain\fP processing can be disabled by setting an 
+option in the resolver.
+.pp
+The \fIsearch-list\fP is a list of domains which are tried, in order,
+as qualifying domains for query-names which do not contain a ``\fB\|.\|\fP''.
+Note that \fIsearch-list\fP processing can be disabled by setting an 
+option in the resolver.  Also note that the environment variable
+``\s-1LOCALDOMAIN\s+1'' can override this \fIsearch-list\fP on a per-process
+basis.
+.pp
+The \fIserver-address\fP\|'s are aggregated and then used as the default
+destination of queries generated through the resolver.  In other words,
+this is the way you tell the resolver which name servers it should use.  It
+is possible for a given client application to override this list, and this
+is often done inside the name server (which is itself a \fIresolver\fP
+client) and in test programs such as \fInslookup\fP.
+Note that if you wish to list the
+local host in your resolver configuration file, you should probably use its
+primary Internet address rather than a local-host alias such as 127.0.0.1 or
+0.0.0.0.  This is due to a bug in the handling of connected \s-1SOCK_DGRAM\s+1
+sockets in some versions of the \s+1BSD\s-1 networking code.  If you must use
+an address-alias, you should prefer 0.0.0.0 (or simply ``0'') over 127.0.0.1,
+though be warned that depending on the vintage of your \s-1BSD\s+1-derived
+networking code, both of them are capable of failing in their own ways.
+If your host's IP
+implementation does not create a short-circuit route between the default
+interface and the loopback interface, then you might also want to add a
+static route (eg. in \fB/etc/rc.local\fP) to do so:
+.(b l
+\fIroute add myhost.domain.name localhost 1\fP
+.)b
+.pp
+The \fIsort-list\fP is a list of IP address, netmask pairs. Addresses
+returned by gethostbyname are sorted to the order specified by this list.
+Any addresses that do not match the address netmask pair will be returned
+after those that do. The netmask is optional and the natural netmask will be
+used if not specified.
+.pp
+The \fIoption-list\fP is a list of options which each override some internal
+resolver variable.  Supported options at this time are:
+.ip \fBdebug\fP
+sets the \s-1RES_DEBUG\s+1 bit in \fB_res.options\fP.
+.ip \fBndots:\fP\fIn\fP
+sets the lower threshold (measured in ``number of dots'') on names given to
+\fIres_query\fP() such that names with more than this number of dots will be
+tried as absolute names before any \fIlocal-domain\fP or \fIsearch-list\fP
+processing is done.  The default for this internal variable is ``1''.
+.\" .pp
+.\" Finally, if the environment variable \s-1HOSTALIASES\s+1 is set, it is
+.\" taken to contain the name of a file which in turn contains resolver-level
+.\" aliases.  These aliases are applied only to names which do not contain any
+.\" ``\fB\|.\|\fP'' characters, and they are applied to query-names before the
+.\" query is generated.  Note that the resolver options governing the operation
+.\" of \fIlocal-domain\fP and \fIsearch-list\fP do not apply to
+.\" \s-1HOSTALIASES\s+1.
+
+.sh 2 "Cache Initialization File"
+.sh 3 root.cache
+.pp
+The name server needs to know the servers that are the authoritative name
+servers for the root domain of the network.  To do this we have to prime the
+name server's cache with the addresses of these higher authorities.  The
+location of this file is specified in the boot file.  This file uses the
+Standard Resource Record Format (aka. Masterfile Format) covered further on
+in this paper.
+
+.sh 2 "Domain Data Files"
+.pp
+There are two standard files for specifying the data for a 
+domain.  These are \fIhosts\fP and \fIhost.rev\fP.
+These files use the Standard Resource Record Format covered later
+in this paper.  Note that the file names are arbitrary; many network
+administrators prefer to name their zone files after the domains they
+contain, especially in the average case which is where a given server
+is primary and/or secondary for many different zones.
+.sh 3 hosts
+.pp
+This file contains all the data about the machines in this zone.
+The location of this file is specified in the boot file.
+.sh 3 hosts.rev
+.pp
+This file specifies the IN-ADDR\|.\|ARPA domain.
+This is a special domain for allowing address to name mapping.
+As internet host addresses do not fall within domain boundaries,
+this special domain was formed to allow inverse mapping.
+The IN-ADDR\|.\|ARPA domain has four
+labels preceding it. These labels correspond to the 4 octets of
+an Internet address. 
+All four octets must be specified even if an octet contains zero.
+The Internet address 128.32.0.4 is located in the domain
+4\|.\|0\|.\|32\|.\|128\|.\|IN-ADDR\|.\|ARPA.
+This reversal of the address is awkward to read but allows 
+for the natural grouping of hosts in a network.
+.sh 3 named.local
+.pp
+This file specifies the \fIPTR\fP record for the local loopback interface,
+better known as \fIlocalhost\fP, whose network address is 127.0.0.1.  The
+location of this file is specified in the boot file.  It is vitally
+important to the proper operation of every name server that the 127.0.0.1
+address have a \fIPTR\fP record pointing back to the name
+``\fBlocalhost.\fP''.  The name of this \fIPTR\fP record is always
+``\fB1.0.0.127.\s-1IN-ADDR.ARPA\s+1\fP''.  This is necessary if you want
+your users to be able to use hostname-authentication (\fIhosts.equiv\fP or
+\fI~/.rhosts\fP) on the name ``\fBlocalhost\fP''.  As implied by this
+\fIPTR\fP record, there should be a ``\fBlocalhost.\fP\fImy.dom.ain\fP''
+\fIA\fP record (with address 127.0.0.1) in every domain that contains hosts.
+``\fBlocalhost.\fP'' will lose its trailing dot when
+\fB1.0.0.127.in-addr.arpa\fP is queried for; then, the DEFNAMES and/or
+DNSRCH resolver options will cause ``\fBlocalhost\fP'' to be evaluated as a
+host name in the local domain, and that means the top domains (or ideally,
+every domain) in your resolver's search path had better have something by
+that name.
+.sh 2 "Standard Resource Record Format"
+.pp
+The records in the name server data files are called resource records.
+The Standard Resource Record Format (RR) is specified in RFC1035.
+The following is a general description of these records:
+.TS
+l l l l l.
+\fI{name}	{ttl}	addr-class	Record Type	Record Specific data\fP 
+.TE
+Resource records have a standard format shown above.
+The first field is always the name of the domain record
+and it must always start in column 1.
+For all RR's other than the first in a file, the name may be left blank;
+in that case it takes on the name of the previous RR.
+The second field is an optional time to live field.
+This specifies how long this data will be stored in the data base.
+By leaving this field blank the default time to live is specified
+in the \fIStart Of Authority\fP resource record (see below).
+The third field is the address class; currently, only one class is supported:
+\fIIN\fP for internet addresses and other internet information.  Limited 
+support is included for the \fIHS\fP class, which is for MIT/Athena ``Hesiod''
+information.
+The fourth field states the type of the resource record.
+The fields after that are dependent on the type of the RR.
+Case is preserved in names and data fields when loaded into the name server.
+All comparisons and lookups in the name server data base are case insensitive.
+.bl
+.b
+The following characters have special meanings:
+.ip ``\fB.\fP''
+A free standing dot in the name field refers to the root domain.
+.ip ``@''
+A free standing @ in the name field denotes the current origin.
+.ip "``\eX''"
+Where X is any character other than a digit (0-9),
+quotes that character so that its special meaning does not apply.
+For example, ``\e.'' can be used to place a dot character in a label.
+.ip "``\eDDD''"
+Where each D is a digit, is the octet corresponding to the
+decimal number described by DDD.  
+The resulting octet is assumed to be text and 
+is not checked for special meaning.
+.ip "``( )''"
+Parentheses are used to group data that crosses a line.  
+In effect, line terminations are not recognized within parentheses.
+(At present, this notation only works for SOA RR's and is not optional.)
+.ip "``;''"
+Semicolon starts a comment; the remainder of the line is ignored.  Note
+that a completely blank line is also considered a comment, and ignored.
+.ip "``*''"
+An asterisk signifies wildcarding.  Note that this is just another data
+character whose special meaning comes about only during internal name
+server search operations.  Wildcarding is only meaningful for some RR
+types (notably \fIMX\fP), and then only in the name field \(em not in
+the data fields.
+.pp
+Anywhere a name appears \(em either in the name field or in some data field
+defined to contain names \(em the current origin will be appended if the
+name does not end in a ``\fB\|.\|\fP''.
+This is useful for appending the current domain name to the data,
+such as machine names, but may cause problems where you do not want 
+this to happen.
+A good rule of thumb is that, if the name is not in the domain for which
+you are creating the data file, end the name with a ``\fB.\fP''.
+.sh 3 $INCLUDE
+.pp
+An include line begins with $INCLUDE, starting in column 1,
+and is followed by a file name, and, optionally, by a new
+temporary $ORIGIN to be used while reading this file.
+This feature is
+particularly useful for separating different types of data into multiple files.
+An example would be:
+.(b l
+$INCLUDE /usr/local/adm/named/data/mail-exchanges
+.)b
+The line would be interpreted as a request to load the file
+\fI/usr/local/adm/named/data/mail-exchanges\fP.  The $INCLUDE command does not cause
+data to be loaded into a different zone or tree. This is simply a way to
+allow data for a given primary zone to be organized in separate files.  
+Not even the ``temporary $ORIGIN'' feature described above is sufficient
+to cause your data to branch out into some other zone \(em zone boundaries
+can only be introduced in the boot file.
+.pp
+A $INCLUDE file must have a name on its first RR.  That is, the first 
+character of the first non-comment line must not be a space.  The current
+default name in the parent file \fIdoes not\fP carry into the $INCLUDE
+file.
+.sh 3 $ORIGIN
+.pp
+The origin is a way of changing the origin in a data file.  The line starts
+in column 1, and is followed by a domain origin.  This seems like it could
+be useful for putting more then one zone into a data file, but that's not
+how it works.  The name server fundamentally requires a given zone to map
+entirely to some specific file.  You should therefore be very careful to use
+$ORIGIN only once at the top of a file, or, within a file, to change to a
+``lower'' domain in the zone  \(em never to some other zone altogether.
+.sh 3 "SOA - Start Of Authority"
+.(b L
+.TS
+l l l l l l.
+\fIname	{ttl}	addr-class	SOA	Origin	Person in charge\fP
+@		IN	SOA	ucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP	kjd\fB.\fPucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP (
+			1995122103	; Serial
+			10800	; Refresh
+			1800	; Retry
+			3600000	; Expire
+			259200 )	; Minimum
+.TE
+.)b
+The \fIStart of Authority, SOA,\fP record designates the start of a zone.
+The name is the name of the zone and is often given as ``@'' since this
+is always the current $ORIGIN and the SOA RR is usually the first record
+of the primary zone file.
+Origin is the name of the host on which this data file resides (in other
+words, the \fIprimary master\fP server for this zone.)
+Person in charge is the e-mail address for the person responsible
+for the name server, with ``@'' changed to a ``.''.
+The serial number is the version number of this data file and must be a
+positive integer.
+This number must be incremented whenever a change is made to the data.
+Older servers permitted the use of a phantom ``.'' in this and other
+numbers in a zone file; the meaning of n.m was ``n000m'' rather than the
+more intuitive ``n*1000+m'' (such that 1.234 translated to 1000234 rather
+than to 1234).  This feature has been deprecated due to its
+obscurity, unpredictability, and lack of necessity.
+Note that using a ``YYYYMMDDNN'' notation you can still make 100 changes
+per day until the year 4294.  You should choose a notation that works for
+you.  If you're a clever \fIperl\fP programmer you could even use \fIRCS\fP
+version numbers to help generate your zone serial numbers.
+The refresh indicates how often, in seconds, the secondary name servers
+are to check with the primary name server to see if an update is needed.
+The retry indicates how long, in seconds, a secondary server should wait
+before retrying a failed zone transfer.
+Expire is the upper limit, in seconds, that a secondary name server
+is to use the data before it expires for lack of getting a refresh.
+Minimum is the default number of seconds to be used for the Time To Live
+field on resource records which do not specify one in the zone file.
+It is also an enforced minimum on Time To Live if it is specified on
+some resource record (RR) in the zone.
+There must be exactly one \fISOA\fP record per zone.
+.sh 3 "NS - Name Server"
+.TS
+l l l l l.
+\fI{name}	{ttl}	addr-class	NS	Name servers name\fP
+		IN	NS	ucbarpa\fB\|.\|\fPBerkeley\fB\|.\|\fPEdu\fB.\fP
+.TE
+The \fIName Server\fP record, \fINS\fP, lists a name server responsible 
+for a given domain, creating a \fIdelegation point\fP and a \fIsubzone\fP.
+The first name field specifies the zone that is serviced by 
+the name server specified by the second name.
+Every zone needs at least two name servers.
+.bp		\" ----PLACEMENT HACK----
+.sh 3 "A - Address"
+.TS
+l l l l l.
+\fI{name}	{ttl}	addr-class	A	address\fP
+ucbarpa		IN	A	128\fB.\fP32\fB.\fP0\fB.\fP4
+		IN	A	10\fB.\fP0\fB.\fP0\fB.\fP78
+.TE
+The \fIAddress\fP record, \fIA\fP, lists the address for a given machine. 
+The name field is the machine name and the address is the network address.
+There should be one \fIA\fP record for each address of the machine. 
+.sh 3 "HINFO - Host Information"
+.TS
+l l l l l l. 
+\fI{name}	{ttl}	addr-class	HINFO	Hardware	OS\fP
+		IN	HINFO	VAX-11/780	UNIX
+.TE
+\fIHost Information\fP resource record, \fIHINFO\fP, is for host specific
+data.  This lists the hardware and operating system that are running at the
+listed host.  If you want to include a space in the machine name you must
+quote the name (using ``"'' characters.)  There could be one \fIHINFO\fP
+record for each host, though for security reasons most domains don't have
+any \fIHINFO\fP records at all.  No application depends on them.
+.(b L
+.sh 3 "WKS - Well Known Services"
+.TS
+l l l l l l l.
+\fI{name}	{ttl}	addr-class	WKS	address	protocol	list of services\fP
+		IN	WKS	128\fB.\fP32\fB.\fP0\fB.\fP10	UDP	who route timed domain
+		IN	WKS	128\fB.\fP32\fB.\fP0\fB.\fP10	TCP	( echo telnet
+						discard sunrpc sftp
+						uucp-path systat daytime
+						netstat qotd nntp
+						link chargen ftp 
+						auth time whois mtp
+						pop rje finger smtp
+						supdup hostnames 
+						domain
+						nameserver )
+.TE
+The \fIWell Known Services\fP record, \fIWKS\fP, describes the well known
+services supported by a particular protocol at a specified address.  The
+list of services and port numbers come from the list of services specified
+in \fI/etc/services.\fP There should be only one \fIWKS\fP record per
+protocol per address.  Note that RFC1123 says of \fIWKS\fP records:
+.)b
+.(l L
+   2.2  Using Domain Name Service
+   ...
+      An application SHOULD NOT rely on the ability to locate a WKS
+      record containing an accurate listing of all services at a
+      particular host address, since the WKS RR type is not often used
+      by Internet sites.  To confirm that a service is present, simply
+      attempt to use it.
+   ...
+      5.2.12  WKS Use in MX Processing: RFC-974, p. 5
+
+         RFC-974 [SMTP:3] recommended that the domain system be queried
+         for WKS ("Well-Known Service") records, to verify that each
+         proposed mail target does support SMTP.  Later experience has
+         shown that WKS is not widely supported, so the WKS step in MX
+         processing SHOULD NOT be used.
+   ...
+         6.1.3.6  Status of RR Types
+   ...
+                 The TXT and WKS RR types have not been widely used by
+                 Internet sites; as a result, an application cannot rely
+                 on the the existence of a TXT or WKS RR in most
+                 domains.
+.)l
+.sh 3 "CNAME - Canonical Name"
+.TS
+l l l l l. 
+\fIalias	{ttl}	addr-class	CNAME	Canonical name\fP
+ucbmonet		IN	CNAME	monet
+.TE
+The \fICanonical Name\fP resource record, \fICNAME\fP, specifies an
+alias or nickname for the official, or canonical, host name.
+This record must be the only one associated with the alias name.
+All other resource records must be
+associated with the canonical name, not with the nickname.
+Any resource records that include a domain name as their value
+(e.g., NS or MX) \fImust\fP list the canonical name, not the nickname.
+Similarly, a CNAME will be followed when searching for A RRs, but not
+for MX RRs or NS RRs or most other types of RRs.  CNAMEs are allowed
+to point to other CNAMEs, but this is considered sloppy.
+.pp
+Nicknames are useful when a well known host changes its name.  In that
+case, it is usually a good idea to have a \fICNAME\fP record so that
+people still using the old name will get to the right place.
+.sh 3 "PTR - Domain Name Pointer"
+.TS
+l l l l l. 
+\fIname	{ttl}	addr-class	PTR	real name\fP
+7.0		IN	PTR	monet\fB\|.\|\fPBerkeley\fB\|.\|\fPEdu\fB\|.\fP
+.TE
+A \fIDomain Name Pointer\fP record, \fIPTR\fP, allows special names to point
+to some other location in the domain.  The above example of a \fIPTR\fP
+record is used in setting up reverse pointers for the special
+\fIIN-ADDR\fP\fB\|.\|\fP\fIARPA\fP domain. This line is from the example
+\fIhosts.rev\fP file.  \fIPTR\fP records are needed by the
+\fIgethostbyaddr\fP function.  Note the trailing ``\fB\|.\|\fP'' which
+prevents \s-1BIND\s+1 from appending the current \s-1$ORIGIN\s+1 to that
+domain name.
+.sh 3 "MX - Mail Exchange"
+.TS
+l l l l l l. 
+\fIname	{ttl}	addr-class	MX	preference value	mail exchange\fP
+Munnari\fB\|.\|\fPOZ\fB\|.\|\fPAU\fB\|.\fP		IN	MX	0	Seismo\fB\|.\|\fPCSS\fB\|.\|\fPGOV\fB\|.\fP
+*\fB\|.\|\fPIL\fB\|.\fP		IN	MX	0	RELAY\fB\|.\|\fPCS\fB\|.\|\fPNET\fB\|.\fP
+.TE
+\fIMail eXchange\fP records, \fIMX\fP, are used to specify a list of hosts
+which are configured to receive mail sent to this domain name.  Every name
+which receives mail should have an \fIMX\fP since if one is not found at the
+time mail is being delivered, an \fIMX\fP will be ``imputed'' with a cost
+of 0 and a destination of the host itself.  If you want a host to receive
+its own mail, you should create an \fIMX\fP for your host's name, pointing
+at your host's name.  It is better to have this be explicit than to let it
+be imputed by remote mailers.
+In the first example, above,
+Seismo\fB\|.\|\fPCSS\fB\|.\|\fPGOV\fB\|.\fP is a mail gateway that knows how
+to deliver mail to Munnari\fB\|.\|\fPOZ\fB\|.\|\fPAU\fB\|.\fP.  These two
+machines may have a private connection or use a different transport medium.
+The preference value is the order that a mailer should follow when there is
+more than one way to deliver mail to a single machine.  Note that lower
+numbers indicate higher precedence, and that mailers are supposed to randomize
+same-valued \fIMX\fP hosts so as to distribute the load evenly if the costs
+are equal.  See RFC974 for more detailed information.
+.pp
+Wildcard names containing the character ``*'' may be used for mail routing
+with \fIMX\fP records.  There are likely to be servers on the network that
+simply state that any mail to a domain is to be routed through a relay.
+Second example, above, all mail to hosts in the domain IL is routed through
+RELAY.CS.NET.  This is done by creating a wildcard resource record, which
+states that *.IL has an \fIMX\fP of RELAY.CS.NET.  Wildcard \fIMX\fP records
+are not very useful in practice, though, since once a mail message gets to
+the gateway for a given domain it still has to be routed \fIwithin\fP that
+domain and it is not currently possible to have an apparently-different set
+of \fIMX\fP records inside and outside of a domain.  If you won't be needing
+any Mail Exchanges inside your domain, go ahead and use a wildcard.  If you
+want to use both wildcard ``top-level'' and specific ``interior'' \fIMX\fP
+records, note that each specific record will have to ``end with'' a complete
+recitation of the same data that is carried in the top-level record.  This
+is because the specific \fIMX\fP records will take precedence over the 
+top-level wildcard records, and must be able to perform the top-level's
+if a given interior domain is to be able to receive mail from outside the
+gateway.  Wildcard \fIMX\fP records are very subtle and you should be careful
+with them.
+.sh 3 "TXT - Text"
+.TS
+l l l l l l. 
+\fIname	{ttl}	addr-class	TXT	string\fP
+Munnari\fB\|.\|\fPOZ\fB\|.\|\fPAU\fB\|.\fP		IN	TXT	"foo"
+.TE
+A \fITXT\fP record contains free-form textual data.  The syntax of the text
+depends on the domain where it is found; many systems use \fITXT\fP records
+to encode local data in a stylized format.  MIT Hesiod is one such system.
+.sh 3 "RP - Responsible Person"
+.TS
+l l l l l l.
+\fIowner	{ttl}	addr-class	RP	mbox-domain-name	TXT-domain-name\fP
+franklin		IN 	RP	ben.franklin.berkeley.edu.	sysadmins.berkeley.edu.
+.TE
+.pp
+The Responsible Person record, \fIRP\fP, identifies the name or group name of
+the responsible person for a host.  Often it is desirable to be able to
+identify the responsible entity for a particular host.  When that host
+is down or malfunctioning, you would want to contact those parties
+who might be able to repair the host.
+.pp
+The first field, \fImbox-domain-name\fP, is a domain name that specifies the
+mailbox for the responsible person.  Its format in a zone file uses
+the \s-1DNS\s+1 convention for mailbox encoding, identical to that used for
+the \fIPerson-in-charge\fP mailbox field in the SOA record.
+In the example above, the \fImbox-domain-name\fP shows the encoding for
+``\fB<ben@franklin.berkeley.edu>\fP''.
+The root domain name (just ``\fB\|.\|\fP'') may be specified
+to indicate that no mailbox is available.
+.pp
+The second field, \fITXT-domain-name\fP, is a domain name for which
+\fITXT\fP records exist.  A subsequent query can be performed to retrieve
+the associated \fITXT\fP resource records at \fITXT-domain-name\fP.  This
+provides a level of indirection so that the entity can be referred to from
+multiple places in the \s-1DNS\s+1.  The root domain name (just
+``\fB\|.\|\fP'') may be specified for \fITXT-domain-name\fI to indicate
+that no associated \fITXT\fP RR exists.  In the example above,
+``\fBsysadmins.berkeley.edu.\fP'' is the name of a TXT record that might
+contain some text with names and phone numbers.
+.pp
+The format of the \fIRP\fP record is class-insensitive.
+Multiple \fIRP\fP records at a single name may be present in the database,
+though they should have identical TTLs.
+.pp
+The \fIRP\fP record is still experimental; not all name servers implement
+or recognize it.
+.sh 3 "AFSDB - DCE or AFS Server"
+.TS
+l l l l l l. 
+\fIname	{ttl}	addr-class	AFSDB	subtype	server host name\fP
+toaster.com.		IN	AFSDB	1	jack.toaster.com.
+toaster.com.		IN	AFSDB	1	jill.toaster.com.
+toaster.com.		IN	AFSDB	2	tracker.toaster.com.
+.TE
+\fIAFSDB\fP records are used to specify the hosts that provide a style of
+distributed service advertised under this domain name.  A subtype value
+(analogous to the ``preference'' value in the \fIMX\fP record) indicates
+which style of distributed service is provided with the given name.
+Subtype 1 indicates that the named host is an AFS (R) database server for
+the AFS cell of the given domain name.  Subtype 2 indicates that the
+named host provides intra-cell name service for the DCE (R) cell named by
+the given domain name.
+In the example above, jack\fB\|.\|\fPtoaster\fB\|.\|\fPcom and
+jill\fB\|.\|\fPtoaster\fB\|.\|\fPcom are declared to be AFS database
+servers for the toaster\fB\|.\|\fPcom AFS cell, so that AFS clients
+wishing service from toaster\fB\|.\|\fPcom are directed to those two hosts
+for further information.  The third record declares that
+tracker\fB\|.\|\fPtoaster\fB\|.\|\fPcom houses a directory server for the
+root of the DCE cell toaster\fB\|.\|\fPcom, so that DCE clients that wish
+to refer to DCE services should consult with the host
+tracker\fB\|.\|\fPtoaster\fB\|.\|\fPcom for further information.  The
+DCE sub-type of record is usually accompanied by a \fITXT\fP record for
+other information specifying other details to be used in accessing the
+DCE cell.  RFC1183 contains more detailed information on the use of
+this record type.
+.pp
+The \fIAFSDB\fP record is still experimental; not all name servers implement
+or recognize it.
+
+.sh 3 "PX - Pointer to X.400/RFC822 mapping information"
+.TS
+l l l l l l l. 
+\fIname	{ttl}	addr-class	PX	prefer	822-dom	X.400-dom\fP
+*.ADMD-garr.X42D.it.		IN	PX	50	it.	ADMD-garr.C-it.
+*.infn.it.		IN	PX	50	infn.it.	O.PRMD-infn.ADMD-garr.C-it.
+*.it.		IN	PX	50	it.	O-gate.PRMD-garr.ADMD-garr.C-it.
+.TE
+.pp
+The \fIPX\fP records (\fIPointer to X.400/RFC822 mapping information\fP) 
+are used to specify address mapping rules between X.400 O/R addresses and 
+RFC822 style (domain-style) mail addresses. For a detailed description of the 
+mapping process please refer to RFC1327.
+.pp
+Mapping rules are of 3 different types:
+.pp
+1) mapping from X.400 to RFC822 (defined as "table 1 rules" in RFC1327)
+.pp
+2) mapping from RFC822 to X.400 (defined as "table 2 rules" in RFC1327)
+.pp
+3) encoding RFC822 into X.400   (defined as "gate table" in RFC1327)
+.pp
+All three types of mapping rules are specified using \fIPX\fP Resource
+Records in DNS, although the \fIname\fP value is different: for case 1, the
+\fIname\fP value is an X.400 domain in DNS syntax, whereas for cases 2 and
+3 the \fIname\fP value is an RFC822 domain. Refer to RFC-1664 for details
+on specifying an X.400 domain in DNS syntax and for the use of the
+\fIX42D\fP keyword in it. Tools are available to convert from RFC1327
+tables format into DNS files syntax.  \fIPreference\fP is analogous to the
+\fIMX\fP RR Preference parameter: it is currently advised to use a fixed
+value of 50 for it. \fI822-dom\fP gives the RFC822 part of the mapping
+rules, and \fIX.400-dom\fP gives the X.400 part of the mapping rule (in DNS
+syntax). It is currently advised always to use wildcarded \fIname\fP
+values, as the RFC1327 tables specifications permit wildcard
+specifications only. This is to keep compatibility with existing services
+using static RFC1327 tables instead of DNS \fIPX\fP information.
+.pp
+Specifications of mapping rules from X.400 to RFC822 syntax requires the
+creation of an appropriate X.400 domain tree into DNS, including thus specific
+\fISOA\fP and \fINS\fP records for the domain itself. Specification of mapping 
+rules from RFC822 into X.400 can be embedded directly into the normal direct 
+\fIname\fP tree.
+Again, refer to RFC1664 for details about organization of this structure.
+.pp
+Tools and library routines, based on the standard resolver ones, are available
+to retrieve from DNS the appropriate mapping rules in RFC1327 or DNS syntax.
+.pp
+Once again, refer to RFC1664 to use the \fIPX\fP resource record, and be careful
+in coordinating the mapping information you can specify in DNS with the same
+information specified into the RFC1327 static tables.
+.pp
+The \fIPX\fP record is still experimental; not all servers implement or
+recognize it.
+
+.sh 2 "Discussion about the TTL"
+.pp
+The Time To Live assigned to the records and to the zone via the
+Minimum field in the SOA record is very important. High values will
+lead to lower BIND network traffic and faster response time. Lower
+values will tend to generate lots of requests but will allow faster
+propagation of changes.
+.pp
+Only changes and deletions from the zone are affected by the TTLs.
+Additions propagate according to the Refresh value in the SOA.
+.pp
+Experience has shown that sites use default TTLs for their zones varying
+from around 0.5 day to around 7 days. You may wish to consider boosting
+the default TTL shown in former versions of this guide from one day
+(86400 seconds) to three days (259200 seconds). This will drastically
+reduce the number of requests made to your name servers.
+.pp
+If you need fast propagation of changes and deletions, it might be wise
+to reduce the Minimum field a few days before the change, then do the
+modification itself and augment the TTL to its former value.
+.pp
+If you know that your zone is pretty stable (you mainly add new records
+without deleting or changing old ones) then you may even wish to consider
+a TTL higher than three days.
+.pp
+Note that in any case, it makes no sense to have records with a TTL
+below the SOA Refresh delay, as Delay is the time required for secondaries
+to get a copy of the newly modified zone.
+
+.sh 2 "About ``secure zones''
+.pp
+Secure zones implement named security on a zone by zone basis.  It is
+designed to use a permission list of networks or hosts which may obtain
+particular information from the zone.
+.pp
+In order to use zone security, \fInamed\fP must be compiled with SECURE_ZONES
+defined and you must have at least one secure_zone TXT RR.  Unless a
+\fIsecure_zone\fP record exists for a given zone, no restrictions will be
+applied to the data in that zone.  The format of the secure_zone TXT RR is:
+.lp
+secure_zone\h'0.5i'addr-class\h'0.5i'TXT\h'0.5i'string
+.pp
+The addr-class may be either \fIHS\fP or \fIIN\fP.  The syntax for the TXT
+string is either ``network address:netmask'' or ``host IP address:H''.
+.pp
+``network address:netmask'' allows queries from an entire network.  If the
+netmask is omitted, named will use the default netmask for the network
+address specified.
+.pp
+``host IP address:H'' allows queries from a host.  The ``H'' after the ``:''
+is required to differentiate the host address from a network address.
+Multiple secure_zone TXT RRs are allowed in the same zone file.
+.pp
+For example, you can set up a zone to only answer Hesiod requests from the
+masked class B network 130.215.0.0 and from host 128.23.10.56 by adding the
+following two TXT RR's:
+.lp
+secure_zone\h'0.5i'HS\h'0.5i'TXT\h'0.5i'``130.215.0.0:255.255.0.0''
+secure_zone\h'0.5i'HS\h'0.5i'TXT\h'0.5i'``128.23.10.56:H''
+.pp
+This feature can be used to restrict access to a Hesiod password map or to
+separate internal and external internet address resolution on a firewall
+machine without needing to run a separate named for internal and external
+address resolution.
+.pp
+Note that you will need to include your loopback interface (127.0.0.1) in
+your secure_zone record, or your local clients won't be able to resolve
+names.
+
+.sh 2 "About Hesiod, and HS-class Resource Records
+.pp
+Hesiod, developed by \s-1MIT\s+1 Project Athena, is an information service
+built upon \s-1BIND\s+1.  Its intent is similar to that of Sun's
+\s-1NIS\s+1: to furnish information about users, groups, network-accessible
+file systems, printcaps, and mail service throughout an installation.  Aside
+from its use of \s-1BIND\s+1 rather than separate server code another
+important difference between Hesiod and \s-1NIS\s+1 is that Hesiod is not
+intended to deal with passwords and authentication, but only with data that
+are not security sensitive.  Hesiod servers can be implemented by adding
+resource records to \s-1BIND\s+1 servers; or they can be implemented as
+separate servers separately administered.
+.pp
+To learn about and obtain Hesiod make an anonymous \s-1FTP\s+1 connection to
+host \s-1ATHENA-DIST.MIT.EDU\s+1 and retrieve the compressed tar file
+\fB/pub/ATHENA/hesiod.tar.Z\fP.  You will not need the named and resolver
+library portions of the distribution because their functionality has already
+been integrated into \s-1BIND as of 4.9\s+1.  To learn how Hesiod functions
+as part of the Athena computing environment obtain the paper
+\fB/pub/ATHENA/usenix/athena-changes.PS\fP from the above \s-1FTP\s+1 server
+host.  There is also a tar file of sample Hesiod resource files.
+.pp
+Whether one should use Hesiod class is open to question, since the same
+services can probably be provided with class IN, type TXT and type
+CNAME records.  In either case, the code and documents for Hesiod will
+suggest how to set up and use the service.
+.pp
+Note that while \s-1BIND\s+1 includes support for \fIHS\fP-class queries,
+the zone transfer logic for non-\fIIN\fP-class zones is still experimental.
+
+.sh 2 "Sample Files"
+.pp
+The following section contains sample files for the name server.
+This covers example boot files for the different types of servers
+and example domain data base files.
diff --git a/contrib/bind/doc/bog/intro.me b/contrib/bind/doc/bog/intro.me
new file mode 100644
index 0000000..597fa44
--- /dev/null
+++ b/contrib/bind/doc/bog/intro.me
@@ -0,0 +1,75 @@
+.\" ++Copyright++ 1986, 1988
+.\" -
+.\" Copyright (c) 1986, 1988
+.\"    The Regents of the University of California.  All rights reserved.
+.\" 
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\" 	This product includes software developed by the University of
+.\" 	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\" 
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\" -
+.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
+.\" 
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies, and that
+.\" the name of Digital Equipment Corporation not be used in advertising or
+.\" publicity pertaining to distribution of the document or software without
+.\" specific, written prior permission.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
+.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
+.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+.\" SOFTWARE.
+.\" -
+.\" --Copyright--
+.\"
+.\"	@(#)intro.me	6.2 (Berkeley) 2/28/88
+.\"
+.sh 1 Introduction
+.pp
+The Berkeley Internet Name Domain (\s-1BIND\s+1) implements an Internet name
+server for \s-2BSD\s+2-derived operating systems.  The \s-1BIND\s+1 consists
+of a server (or ``daemon'') called \fInamed\fP and a \fIresolver\fP library.
+A name server is a network service that enables clients to name resources or
+objects and share this information with other objects in the network.  This
+in effect is a distributed data base system for objects in a computer
+network.  The \s-1BIND\s+1 server runs in the background, servicing queries
+on a well known network port.  The standard port for UDP and TCP is specified
+in \fI/etc/services\fP.  The \fIresolver\fP is a set of routines residing
+in a system library that provides the interface that programs can use to
+access the domain name services.
+.pp
+BIND is fully integrated into BSD (4.3 and later releases)
+network programs for use in storing and retrieving host names and address.
+The system administrator can configure the system to use BIND as a
+replacement to the older host table lookup of information in the network
+hosts file \fI/etc/hosts\fP.  The default configuration for BSD uses
+BIND.
diff --git a/contrib/bind/doc/bog/manage.me b/contrib/bind/doc/bog/manage.me
new file mode 100644
index 0000000..6f17b80
--- /dev/null
+++ b/contrib/bind/doc/bog/manage.me
@@ -0,0 +1,156 @@
+.\" ++Copyright++ 1986, 1988, 1995
+.\" -
+.\" Copyright (c) 1986, 1988, 1995
+.\"    The Regents of the University of California.  All rights reserved.
+.\" 
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\" 	This product includes software developed by the University of
+.\" 	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\" 
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\" -
+.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
+.\" 
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies, and that
+.\" the name of Digital Equipment Corporation not be used in advertising or
+.\" publicity pertaining to distribution of the document or software without
+.\" specific, written prior permission.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
+.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
+.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+.\" SOFTWARE.
+.\" -
+.\" --Copyright--
+.\"
+.\"	@(#)manage.me	6.6 (Berkeley) 9/19/89
+.\"	$Id: manage.me,v 8.4 1995/12/22 10:20:24 vixie Exp $
+.\"
+.sh 1 "Domain Management"
+.pp
+This section contains information for starting, controlling and debugging
+\fInamed\fP.
+.sh 2 /etc/rc.local
+.pp
+The hostname should be set to the full domain style name in
+\fI/etc/rc.local\fP using \fIhostname\|(1)\fP.  The following entry should
+be added to \fI/etc/rc.local\fP to start up \fInamed\fP at system boot time:
+.(b l 
+\fIif [ -f /usr/sbin/named ]; then
+    /usr/sbin/named\fP [options] \fI& echo -n ' named'  >/dev/console\fP
+\fIfi\fP
+.)b
+This usually directly follows the lines that start \fIsyslogd\fP.
+\fBDo Not\fP attempt to run \fInamed\fP from \fIinetd\fP.
+This will
+continuously restart the name server and defeat the purpose of the cache.
+.sh 2 /var/run/named.pid
+.pp
+When \fInamed\fP is successfully started up it writes its process id into
+the file \fI/var/run/named.pid\fP.  This is useful to programs that want to
+send signals to \fInamed\fP. The name of this file may be changed by defining
+\fIPIDFILE\fP to the new name when compiling \fInamed\fP.
+.sh 2 /etc/hosts
+.pp
+The \fIgethostbyname\|()\fP library call can detect if \fInamed\fP is running.
+If it is determined that \fInamed\fP is not running it will look in
+\fI/etc/hosts\fP to resolve an address.  
+This option was added to allow \fIifconfig\|(8C)\fP to configure the machines
+local interfaces and to enable a system manager to access the network 
+while the system is in single user mode.
+It is advisable to put the local machines interface addresses and a couple of 
+machine names and address in 
+\fI/etc/hosts\fP so the system manager can rcp files from another machine
+when the system is in single user mode.
+The format of \fI/etc/hosts\fP has not changed. See \fIhosts\|(5)\fP
+for more information.
+Since the process of reading \fI/etc/hosts\fP is slow, 
+it is not advisable to use this option when the system is in multi user mode.
+
+.sh 2 Signals
+.pp
+There are several signals that can be sent to the \fInamed\fP process 
+to have it do tasks without restarting the process.
+.sh 3 Reload
+.pp
+SIGHUP -
+Causes \fInamed\fP to read \fInamed.boot\fP and reload the database.
+This is useful when you have made a change to a ``primary'' data file 
+and you want \fInamed\fP\|'s internal database to reflect the change.
+If you build \s-1BIND\s+1 with the \s-1FORCED_RELOAD\s+1 option, then
+\s-1SIGHUP\s+1 also has the effect of scheduling all ``secondary'' zones
+for serial-number checks, which could lead to zone transfers ahead of
+the usual schedule.  Normally serial-number compares are done only at
+the intervals specified in the zone's \s-1SOA\s+1 record.
+.sh 3 Debugging
+.pp
+When \fInamed\fP is running incorrectly, look first in 
+\fI/var/log/messages\fP and check for any messages logged by \fIsyslog\fP.
+Next send it a signal to see what is happening.  Unless you run it with the
+``-d'' option, \fInamed\fP has very little to say on its standard output or
+standard error.  Everything \fInamed\fP has to say, it says to \fIsyslog\fP.
+.pp
+SIGINT -
+Dumps the current data base and cache to
+\fI/var/tmp/named_dump.db\fP
+This should give you an indication to whether the data base was loaded
+correctly.
+The name of the dump file may be changed
+by defining \fIDUMPFILE\fP to the new name when compiling \fInamed\fP.
+
+\fINote:\fP the following two signals only work when \fInamed\fP is built with
+\fIDEBUG\fP defined.
+.pp
+SIGUSR1 -
+Turns on debugging. Each following SIGUSR1 increments the debug level.
+The output goes to \fI/var/tmp/named.run\fP
+The name of this debug file may be changed
+by defining \fIDEBUGFILE\fP to the new name before compiling \fInamed\fP.
+.pp
+SIGUSR2 -
+Turns off debugging completely.
+
+For more detailed debugging, define DEBUG when compiling the resolver
+routines into \fI/lib/libc.a\fP.
+.pp
+SIGWINCH -
+Toggles tracing of all incoming queries if \fInamed\fP has been
+compiled with \fIQRYLOG\fP defined.  The trace is sent to syslog, and
+is huge, but it is very useful for tracking down problems.
+
+To run with tracing of all queries specify the \fI-q\fP flag on the
+command line.  If you routinely log queries you will probably want to
+analyze the results using the dnsstats stats script in the
+contrib directory.  
+.pp
+SIGIOT -
+Dumps statistics data into \fI/var/tmp/named.stats\fP if the server
+is built with \fISTATS\fP defined.  Statistics are appended to the file.
diff --git a/contrib/bind/doc/bog/named.boot.cache b/contrib/bind/doc/bog/named.boot.cache
new file mode 100644
index 0000000..5e0e3d3
--- /dev/null
+++ b/contrib/bind/doc/bog/named.boot.cache
@@ -0,0 +1,77 @@
+.\" ++Copyright++ 1986, 1988
+.\" -
+.\" Copyright (c) 1986, 1988
+.\"    The Regents of the University of California.  All rights reserved.
+.\" 
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\" 	This product includes software developed by the University of
+.\" 	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\" 
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\" -
+.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
+.\" 
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies, and that
+.\" the name of Digital Equipment Corporation not be used in advertising or
+.\" publicity pertaining to distribution of the document or software without
+.\" specific, written prior permission.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
+.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
+.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+.\" SOFTWARE.
+.\" -
+.\" --Copyright--
+.\"
+.\"	@(#)named.boot.cache	6.4 (Berkeley) 9/19/89
+.\"
+.ne 13v
+.sh 4 "Caching Only Server"
+.(b L 
+.TS
+l.
+;
+; Boot file for Caching Only Name Server
+;
+.TE
+.TS
+l l l
+l
+l l l.
+; type	domain	source file or host
+;
+directory	/usr/local/adm/named
+cache	\fB.\fP	root\fB.\fPcache
+primary	0\fB.\fP0\fB.\fP127\fB.\fPin-addr\fB.\fParpa	named\fB.\fPlocal
+.TE
+.)b
+
+
diff --git a/contrib/bind/doc/bog/named.boot.primary b/contrib/bind/doc/bog/named.boot.primary
new file mode 100644
index 0000000..0f3c3ca
--- /dev/null
+++ b/contrib/bind/doc/bog/named.boot.primary
@@ -0,0 +1,78 @@
+.\" ++Copyright++ 1986, 1988
+.\" -
+.\" Copyright (c) 1986, 1988
+.\"    The Regents of the University of California.  All rights reserved.
+.\" 
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\" 	This product includes software developed by the University of
+.\" 	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\" 
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\" -
+.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
+.\" 
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies, and that
+.\" the name of Digital Equipment Corporation not be used in advertising or
+.\" publicity pertaining to distribution of the document or software without
+.\" specific, written prior permission.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
+.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
+.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+.\" SOFTWARE.
+.\" -
+.\" --Copyright--
+.\"
+.\"	@(#)named.boot.primary	6.4 (Berkeley) 9/19/89
+.\"
+.ne 15v
+.sh 3 "Boot Files"
+.sh 4 "Primary Server"
+.(b L
+.TS
+l.
+;
+; Boot file for Primary Name Server
+;
+.TE
+.TS
+l l l
+l
+l l l.
+; type	domain	source file or host
+;
+directory	/usr/local/adm/named
+primary	Berkeley\fB.\fPEdu	ucbhosts
+primary	32\fB.\fP128\fB.\fPin-addr\fB.\fParpa	ucbhosts\fB.\fPrev
+primary	0\fB.\fP0\fB.\fP127\fB.\fPin-addr\fB.\fParpa	named\fB.\fPlocal
+cache	\fB.\fP	root\fB.\fPcache
+.TE
+.)b
diff --git a/contrib/bind/doc/bog/named.boot.secondary b/contrib/bind/doc/bog/named.boot.secondary
new file mode 100644
index 0000000..64a607d
--- /dev/null
+++ b/contrib/bind/doc/bog/named.boot.secondary
@@ -0,0 +1,77 @@
+.\" ++Copyright++ 1986, 1988
+.\" -
+.\" Copyright (c) 1986, 1988
+.\"    The Regents of the University of California.  All rights reserved.
+.\" 
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\" 	This product includes software developed by the University of
+.\" 	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\" 
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\" -
+.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
+.\" 
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies, and that
+.\" the name of Digital Equipment Corporation not be used in advertising or
+.\" publicity pertaining to distribution of the document or software without
+.\" specific, written prior permission.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
+.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
+.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+.\" SOFTWARE.
+.\" -
+.\" --Copyright--
+.\"
+.\"	@(#)named.boot.secondary	6.4 (Berkeley) 9/19/89
+.\"
+.ne 12v
+.sh 4 "Secondary Server"
+.(b L
+.TS
+l.
+;
+; Boot file for Secondary Name Server
+;
+.TE
+.TS
+l l l
+l
+l l l.
+; type	domain	source file or host
+;
+directory	/usr/local/adm/named
+secondary	Berkeley\fB.\fPEdu	128\fB.\fP32\fB.\fP0\fB.\fP4 128\fB.\fP32\fB.\fP0\fB.\fP10 ucbhosts.bak
+secondary	32\fB.\fP128\fB.\fPin-addr\fB.\fParpa	128\fB.\fP32\fB.\fP0\fB.\fP4 128\fB.\fP32\fB.\fP0\fB.\fP10 ucbhosts.rev.bak
+primary	0\fB.\fP0\fB.\fP127\fB.\fPin-addr\fB.\fParpa	named\fB.\fPlocal
+cache	\fB.\fP	root\fB.\fPcache
+.TE
+.)b
diff --git a/contrib/bind/doc/bog/named.local b/contrib/bind/doc/bog/named.local
new file mode 100644
index 0000000..209c5be
--- /dev/null
+++ b/contrib/bind/doc/bog/named.local
@@ -0,0 +1,75 @@
+.\" ++Copyright++ 1986, 1988
+.\" -
+.\" Copyright (c) 1986, 1988
+.\"    The Regents of the University of California.  All rights reserved.
+.\" 
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\" 	This product includes software developed by the University of
+.\" 	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\" 
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\" -
+.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
+.\" 
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies, and that
+.\" the name of Digital Equipment Corporation not be used in advertising or
+.\" publicity pertaining to distribution of the document or software without
+.\" specific, written prior permission.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
+.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
+.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+.\" SOFTWARE.
+.\" -
+.\" --Copyright--
+.\"
+.\"	@(#)named.local	6.3 (Berkeley) 5/24/89
+.\"
+.ne 13v
+.sh 3 "named.local"
+.(b L 
+
+.TS
+l l l l l s. 
+@	IN	SOA	ucbvax\fB.\fPBerkeley\fB.\fPEdu.	kjd\fB.\fPucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP (
+.T&
+l l l l l.
+			1994072100	; Serial
+			10800	; Refresh
+			1800	; Retry
+			3600000	; Expire
+			259200 )	; Minimum
+.T&
+l l l l l s.
+	IN	NS	ucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP	; pedantic
+1	IN	PTR	localhost\fB.\fP
+.TE
+.)b
diff --git a/contrib/bind/doc/bog/ns.me b/contrib/bind/doc/bog/ns.me
new file mode 100644
index 0000000..ec3ca3c
--- /dev/null
+++ b/contrib/bind/doc/bog/ns.me
@@ -0,0 +1,96 @@
+.\" ++Copyright++ 1986, 1988
+.\" -
+.\" Copyright (c) 1986, 1988
+.\"    The Regents of the University of California.  All rights reserved.
+.\" 
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\" 	This product includes software developed by the University of
+.\" 	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\" 
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\" -
+.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
+.\" 
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies, and that
+.\" the name of Digital Equipment Corporation not be used in advertising or
+.\" publicity pertaining to distribution of the document or software without
+.\" specific, written prior permission.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
+.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
+.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+.\" SOFTWARE.
+.\" -
+.\" --Copyright--
+.\"
+.\"	@(#)ns.me	6.3 (Berkeley) 9/19/89
+.\"
+.sh 1 "The Name Service"
+.pp
+The basic function of the name server is to provide information about network
+objects by answering queries.  The specifications for this name server are
+defined in RFC1034, RFC1035 and RFC974.  These documents can be found in
+\fI/usr/src/etc/named/doc\fP in 4.3BSD or \fIftp\fPed from 
+\fBftp.rs.internic.net\fP.
+It is also recommended that you read the related manual pages,
+\fInamed\fP\|(8),
+\fIresolver\fP\|(3),
+and \fIresolver\fP\|(5).
+.pp
+The advantage of using a name server over the host table lookup for host
+name resolution is to avoid the need for a single centralized clearinghouse
+for all names.  The authority for this information can be delegated to the
+different organizations on the network responsible for it.
+.pp
+The host table lookup routines require that the master file for the entire
+network be maintained at a central location by a few people.  This works
+fine for small networks where there are only a few machines and the
+different organizations responsible for them cooperate.  But this does not
+work well for large networks where machines cross organizational boundaries.
+.pp
+With the name server, the network can be broken into a hierarchy of domains. 
+The name space is organized as a tree according to organizational or
+administrative boundaries. 
+Each node, called a \fIdomain\fP, is given a label, and the name of the
+domain is the concatenation of all the labels of the domains from
+the root to the current domain, listed from right to left separated by dots.
+A label need only be unique within its domain.
+The whole space is partitioned into several areas called \fIzones\fP,
+each starting at a domain and extending down to the leaf domains or to
+domains where other zones start.  
+Zones usually represent administrative boundaries.
+An example of a host address for a host at the University of California,
+Berkeley would look as follows:
+.(b
+\fImonet\fP\|\fB.\fP\|\fIBerkeley\fP\|\fB.\fP\|\fIEDU\fP
+.)b
+The top level domain for educational organizations is EDU;
+Berkeley is a subdomain of EDU and monet is the name of the host.
diff --git a/contrib/bind/doc/bog/resolv.conf b/contrib/bind/doc/bog/resolv.conf
new file mode 100644
index 0000000..1f15991
--- /dev/null
+++ b/contrib/bind/doc/bog/resolv.conf
@@ -0,0 +1,67 @@
+.\" ++Copyright++ 1986, 1988
+.\" -
+.\" Copyright (c) 1986, 1988
+.\"    The Regents of the University of California.  All rights reserved.
+.\" 
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\" 	This product includes software developed by the University of
+.\" 	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\" 
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\" -
+.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
+.\" 
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies, and that
+.\" the name of Digital Equipment Corporation not be used in advertising or
+.\" publicity pertaining to distribution of the document or software without
+.\" specific, written prior permission.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
+.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
+.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+.\" SOFTWARE.
+.\" -
+.\" --Copyright--
+.\"
+.\"	@(#)resolv.conf	6.2 (Berkeley) 2/29/88
+.\"
+.ne 6v
+.\" .bp
+.sh 3 "Remote Server / DNS Client"
+.sh 4 "/etc/resolv.conf"
+.(b L
+
+domain Berkeley\fB.\fPEdu
+nameserver 128\fB.\fP32\fB.\fP0\fB.\fP4
+nameserver 128\fB.\fP32\fB.\fP0\fB.\fP10
+sortlist 130.155.160.0/255.255.240.0 130.155.0.0
+
+.)b
diff --git a/contrib/bind/doc/bog/root.cache b/contrib/bind/doc/bog/root.cache
new file mode 100644
index 0000000..3bf5727
--- /dev/null
+++ b/contrib/bind/doc/bog/root.cache
@@ -0,0 +1,102 @@
+.\" ++Copyright++ 1986, 1988
+.\" -
+.\" Copyright (c) 1986, 1988
+.\"    The Regents of the University of California.  All rights reserved.
+.\" 
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\" 	This product includes software developed by the University of
+.\" 	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\" 
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\" -
+.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
+.\" 
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies, and that
+.\" the name of Digital Equipment Corporation not be used in advertising or
+.\" publicity pertaining to distribution of the document or software without
+.\" specific, written prior permission.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
+.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
+.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+.\" SOFTWARE.
+.\" -
+.\" --Copyright--
+.\"
+.\"	@(#)root.cache	6.4 (Berkeley) 4/29/90
+.\"
+.ne 38v
+.sh 3 "root.cache"
+.(b L
+
+;
+;       This file holds the information on root name servers needed to
+;       initialize cache of Internet domain name servers 
+;       (e.g. reference this file in the "cache  .  <file>"
+;       configuration file of BIND domain name servers).
+;
+;       This file is made available by InterNIC registration services
+;       under anonymous FTP as
+;           file                /domain/named.root
+;           on server           FTP.RS.INTERNIC.NET
+;       -OR- under Gopher at    RS.INTERNIC.NET
+;           under menu          InterNIC Registration Services (NSI)
+;              submenu          InterNIC Registration Archives
+;           file                named.root
+;
+;       last update:    Oct 5, 1994
+;       related version of root zone:   1994100500
+;
+.TS
+l	l	l	l	l.	
+\fB.\fP	604800	IN	NS	NS\fB.\fPINTERNIC\fB.\fPNET\fB.\fP
+NS\fB.\fPINTERNIC\fB.\fPNET\fB.\fP	604800	IN	A	198\fB.\fP41\fB.\fP0\fB.\fP4
+\fB.\fP	604800	IN	NS	NS1\fB.\fPISI\fB.\fPEDU\fB.\fP	
+NS1\fB.\fPISI\fB.\fPEDU\fB.\fP	604800	IN	A	128\fB.\fP9\fB.\fP0\fB.\fP107
+\fB.\fP	604800	IN	NS	C\fB.\fPPSI\fB.\fPNET\fB.\fP
+C\fB.\fPPSI\fB.\fPNET\fB.\fP	604800	IN	A	192\fB.\fP33\fB.\fP4\fB.\fP12
+\fB.\fP	604800	IN	NS	TERP\fB.\fPUMD\fB.\fPEDU\fB.\fP
+TERP\fB.\fPUMD\fB.\fPEDU\fB.\fP	604800	IN	A	128\fB.\fP8\fB.\fP10\fB.\fP90
+\fB.\fP	604800	IN	NS	NS\fB.\fPNASA\fB.\fPGOV\fB.\fP
+NS\fB.\fPNASA\fB.\fPGOV\fB.\fP	604800	IN	A	128\fB.\fP102\fB.\fP16\fB.\fP10
+	604800	IN	A	192\fB.\fP52\fB.\fP195\fB.\fP10
+\fB.\fP	604800	IN	NS	NS\fB.\fPISC\fB.\fPORG\fB.\fP
+NS\fB.\fPISC\fB.\fPORG\fB.\fP	604800	IN	A	192\fB.\fP5\fB.\fP5\fB.\fP241
+\fB.\fP	604800	IN	NS	NS\fB.\fPNIC\fB.\fPDDN\fB.\fPMIL\fB.\fP
+NS\fB.\fPNIC\fB.\fPDDN\fB.\fPMIL\fB.\fP	604800	IN	A	192\fB.\fP112\fB.\fP36\fB.\fP4
+\fB.\fP	604800	IN	NS	AOS\fB.\fPARL\fB.\fPARMY\fB.\fPMIL\fB.\fP
+AOS\fB.\fPARL\fB.\fPARMY\fB.\fPMIL\fB.\fP	604800	IN	A	128\fB.\fP63\fB.\fP4\fB.\fP82
+	604800	IN	A	192\fB.\fP5\fB.\fP25\fB.\fP82
+\fB.\fP	604800	IN	NS	NIC\fB.\fPNORDU\fB.\fPNET\fB.\fP
+NIC\fB.\fPNORDU\fB.\fPNET\fB.\fP	604800	IN	A	192\fB.\fP36\fB.\fP148\fB.\fP17
+.TE
+; End of File
+.)b
diff --git a/contrib/bind/doc/bog/setup.me b/contrib/bind/doc/bog/setup.me
new file mode 100644
index 0000000..fff7657
--- /dev/null
+++ b/contrib/bind/doc/bog/setup.me
@@ -0,0 +1,88 @@
+.\" ++Copyright++ 1986, 1988
+.\" -
+.\" Copyright (c) 1986, 1988
+.\"    The Regents of the University of California.  All rights reserved.
+.\" 
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\" 	This product includes software developed by the University of
+.\" 	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\" 
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\" -
+.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
+.\" 
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies, and that
+.\" the name of Digital Equipment Corporation not be used in advertising or
+.\" publicity pertaining to distribution of the document or software without
+.\" specific, written prior permission.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
+.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
+.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+.\" SOFTWARE.
+.\" -
+.\" --Copyright--
+.\"
+.\"	@(#)setup.me	6.4 (Berkeley) 9/19/89
+.\"
+.sh 1 "Setting up Your Own Domain"
+.pp
+When setting up a domain that is going to be on a public network the site
+administrator should contact the organization in charge of the network and
+request the appropriate domain registration form.  An organization that
+belongs to multiple networks (such as the \fIInternet\fP and
+\fIBITNET\fP) should register with only one network.
+.sh 2 "Internet"
+.pp
+Sites on the Internet who need information on setting up a domain should
+contact the registrar for their network, which is one of the following:
+.TS
+l l.
+MILnet	\s-1HOSTMASTER\s+1@\s-1NIC\s+1\fB\|.\|\fP\s-1DDN\s+1\fB\|.\|\fP\s-1MIL\s+1
+other	\s-1HOSTMASTER\s+1@\s-1INTERNIC\s+1\fB\|.\|\fP\s-1NET\s+1
+.TE
+You may also want to be placed on the \s-1BIND\s+1 mailing list, which is a
+mail group for people on the Internet who run \s-1BIND\s+1.  The group
+discusses future design decisions, operational problems, and other related
+topic.  The address to request being placed on this mailing list is:
+.(b l
+\fIbind-request\|@\|uunet\fP\fB\|.\|\fP\fIuu\fP\fB\|.\|\fP\fInet\fP
+.)b
+.sh 2 "Subdomains of Existing Domains"
+.pp
+If you want a subdomain of some existing domain, you should find the contact
+point for the parent domain rather than asking one of the above top-level
+registrars.  There should be a convention that \fBregistrar\fP@\fIdomain\fP
+or \fBhostmaster\fP@\fIdomain\fP for any given domain will always be an alias
+for that domain's registrar (somewhat analogous to \fBpostmaster\fP), but
+there is no such convention.  Try it as a last resort, but first you should
+examine the \fISOA\fP record for the domain and send mail to the ``responsible
+person'' shown therein.  You can also try \fIwhois\fP.
diff --git a/contrib/bind/doc/bog/types.me b/contrib/bind/doc/bog/types.me
new file mode 100644
index 0000000..9d14111
--- /dev/null
+++ b/contrib/bind/doc/bog/types.me
@@ -0,0 +1,163 @@
+.\" ++Copyright++ 1986, 1988, 1995
+.\" -
+.\" Copyright (c) 1986, 1988, 1995
+.\"    The Regents of the University of California.  All rights reserved.
+.\" 
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\" 	This product includes software developed by the University of
+.\" 	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\" 
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\" -
+.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
+.\" 
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies, and that
+.\" the name of Digital Equipment Corporation not be used in advertising or
+.\" publicity pertaining to distribution of the document or software without
+.\" specific, written prior permission.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
+.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
+.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+.\" SOFTWARE.
+.\" -
+.\" --Copyright--
+.\"
+.\"	@(#)types.me	6.3 (Berkeley) 9/19/89
+.\"
+.sh 1 "Types of Zones"
+.pp
+A ``zone'' is a point of delegation in the DNS tree.  It contains all names
+from a certain point ``downward'' except those which are delegated to other
+zones.  A ``delegation point'' has one or more \fINS\fP records in the
+``parent zone'', which should be matched by equivalent \fINS\fP records at
+the root of the ``delegated zone'' (i.e., the ``@'' name in the zone file).
+.pp
+Understanding the difference between a ``zone'' and a ``domain'' is crucial
+to the proper operation of a name server.  As an example, consider the
+\s-1DEC.COM\s+1 \fIdomain\fP, which includes names such as
+\s-1POBOX1.PA.DEC.COM\s+1 and \s-1QUABBIN.CRL.DEC.COM\s+1 even though
+the \s-1DEC.COM\s+1 \fIzone\fP includes only \fIdelegations\fP for the
+\s-1PA.DEC.COM\s+1 and \s-1CRL.DEC.COM\s+1 zones.  A zone can map exactly
+to a single domain, but could also include only part of a domain (the rest
+of which could be delegated to other name servers).  Technically speaking,
+every name in the DNS tree is a ``domain'', even if it is ``terminal'', that
+is, has no ``subdomains''.  Technically speaking, every subdomain is a domain
+and every domain except the root is also a subdomain.  The terminology is not
+intuitive and you would do well to read RFC's 1033, 1034, and 1035 to gain a
+complete understanding of this difficult and subtle topic.
+.pp
+Though \s-1BIND\s+1 is a \fIDomain\fP Name Server, it deals primarily in terms
+of \fIzones\fP.  The \fIprimary\fP and \fIsecondary\fP declarations in the
+\fInamed.boot\fP file specify \fIzones\fP, not \fIdomains\fP.  When you ask
+someone if they are willing to be a secondary server for your ``domain'', you
+are actually asking for secondary service for some collection of \fIzones\fP.
+.pp
+Each zone will have one ``primary'' server, which loads the zone contents
+from some local file which is edited by humans or perhaps generated
+mechanically from some other local file which is edited by humans.  Then
+there will be some number of ``secondary'' servers, which load the zone
+contents using the \s-1IP/DNS\s+1 protocol (that is, the secondary servers will
+contact the primary and fetch the zone using \s-1IP/TCP\s+1).  This set of
+servers (the primary and all of the secondaries) should be listed in the
+\fINS\fP records in the parent zone, which will constitute a ``delegation''.
+This set of servers must also be listed in the zone file itself, usually
+under the ``@'' name which is a magic cookie that means the ``top level''
+or ``root'' of current zone.  You can list servers in the zone's
+top-level ``@'' \fINS\fP records that are not in the parent's \fINS\fP
+delegation, but you cannot list servers in the parent's delegation that are
+not present in the zone's ``@''.  Any servers listed in the \fINS\fP records
+must be configured as authoritative (either primary or secondary) for the
+zone.  If a server listed in a \fINS\fP record is not authoritative, it
+will respond with a ``lame delegation'' when queried.
+.sh 1 "Types of Servers"
+.pp
+Servers do not really have ``types''.  A server can be a primary for some
+zones and a secondary for others, or it can be only a primary, or only a
+secondary, or it can serve no zones and just answer queries via its ``cache''.
+Previous versions of this document referred to servers as ``master'' and
+``slave'' but we now feel that those distinctions \(em and the assignment of
+a ``type'' to a name server \(em are not useful.
+.sh 2 "Caching Only Server"
+.pp
+All servers are caching servers.  This means that the server caches the
+information that it receives for use until the data expires.  A \fICaching
+Only Server\fP is a server that is not authoritative for any zone.  This
+server services queries and asks other servers, who have the authority, for
+the information needed.  All servers keep data in their cache until the data
+expires, based on a \fITTL\fP (``Time To Live'') field which is maintained
+for all resource records.
+.sh 2 "Remote Server"
+.pp
+A Remote Server is an option given to people who would like to use 
+a name server from their workstation or on a machine that has a limited
+amount of memory and CPU cycles.
+With this option you can run all of the networking programs that use
+the name server without the name server running on the local machine.
+All of the queries are serviced by a name server that is running on another 
+machine on the network.
+A host which has an
+\fI/etc/resolv.conf\fP file listing only remote hosts, and which does not
+run a name server of its own, is sometimes called a Remote Server (because
+the actual server is remote?) but more
+often it is called simply a DNS Client.
+This kind of host is technically not a ``server'',
+since it has no cache and does not answer queries.
+.sh 2 "Slave Server"
+.pp
+A Slave Server is a server that always forwards queries it cannot
+satisfy from its cache, to a fixed list of \fIforwarding\fP servers
+instead of interacting
+with the name servers for the root and other domains.
+The queries to the \fIforwarding servers\fP are recursive queries.
+There may be one or more forwarding servers, and they are tried in turn
+until the list is exhausted.
+A Slave and forwarder configuration is typically used when you do not
+wish all the servers at a given site to interact with the rest
+of the Internet servers.  A typical scenario would involve a number of
+workstations and a departmental timesharing machine with Internet
+access.  The workstations might be
+administratively prohibited from having Internet access.
+To give the workstations the appearance of access to the Internet
+domain system, the workstations could be Slave servers to the timesharing
+machine which would forward the queries and interact with other
+name servers to resolve the query before returning the answer.
+An added benefit of using the forwarding feature is that the central
+machine develops a much more complete cache of information that
+all the workstations can take advantage of.  The use of Slave mode
+and forwarding is discussed further under the description of
+the \fInamed\fP bootfile commands.
+.pp
+There is no prohibition against declaring a server to be a \fIslave\fP
+even though it has \fIprimary\fP and/or \fIsecondary\fP zones as well;
+the effect will still be that anything in the local server's cache or
+zones will be answered, and anything else will be forwarded using the
+\fIforwarders\fP list.
diff --git a/contrib/bind/doc/bog/ucbhosts b/contrib/bind/doc/bog/ucbhosts
new file mode 100644
index 0000000..2cb2635
--- /dev/null
+++ b/contrib/bind/doc/bog/ucbhosts
@@ -0,0 +1,118 @@
+.\" ++Copyright++ 1986, 1988
+.\" -
+.\" Copyright (c) 1986, 1988
+.\"    The Regents of the University of California.  All rights reserved.
+.\" 
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\" 	This product includes software developed by the University of
+.\" 	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\" 
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\" -
+.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
+.\" 
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies, and that
+.\" the name of Digital Equipment Corporation not be used in advertising or
+.\" publicity pertaining to distribution of the document or software without
+.\" specific, written prior permission.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
+.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
+.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+.\" SOFTWARE.
+.\" -
+.\" --Copyright--
+.\"
+.\"	@(#)ucbhosts	6.3 (Berkeley) 2/8/89
+.\"
+.\" .ne 48v
+.\" .bp
+.sh 3 "Hosts"
+.(b L
+;
+;    @(#)ucb-hosts    1.2    (berkeley)    88/02/05
+;
+.TS
+l l l l l s. 
+@	IN	SOA	ucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP	kjd\fB.\fPmonet\fB.\fPBerkeley\fB.\fPEdu\fB.\fP (
+.T&
+l l l l l.
+			1988020501	; Serial
+			10800	; Refresh
+			1800	; Retry
+			3600000	; Expire
+			259200 )	; Minimum
+.T&
+l l l l s.
+	IN	NS	ucbarpa\fB.\fPBerkeley\fB.\fPEdu\fB.\fP
+	IN	NS	ucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP
+localhost	IN	A	127\fB.\fP1
+			; note that 127.1 is the same as 127.0.0.1; see inet(3n)
+ucbarpa	IN	A	128\fB.\fP32\fB.\fP4
+	IN	A	10\fB.\fP0\fB.\fP0\fB.\fP78
+	IN	HINFO	VAX-11/780 UNIX
+arpa	IN	CNAME	ucbarpa
+ernie	IN	A	128\fB.\fP32\fB.\fP6
+	IN	HINFO	VAX-11/780 UNIX
+ucbernie	IN	CNAME	ernie
+monet	IN	A	128\fB.\fP32\fB.\fP7
+	IN	A	128\fB.\fP32\fB.\fP130\fB.\fP6
+	IN	HINFO	VAX-11/750 UNIX
+ucbmonet	IN	CNAME	monet
+ucbvax	IN	A	10\fB.\fP2\fB.\fP0\fB.\fP78
+			; 128.32.10 means 128.32.0.10; see inet(3n)
+	IN	A	128\fB.\fP32\fB.\fP10
+			; HINFO and WKS are widely unused,
+			; but we'll show them as examples.
+	IN	HINFO	VAX-11/750 UNIX
+	IN	WKS	128.32.0.10 TCP ( echo telnet
+			discard sunrpc sftp
+			uucp-path systat daytime
+			netstat qotd nntp
+			link chargen ftp
+			auth time whhois mtp
+			pop rje finger smtp
+			supdup hostnames
+			domain
+			nameserver )
+vax	IN	CNAME	ucbvax
+toybox	IN	A	128\fB.\fP32\fB.\fP131\fB.\fP119
+	IN	HINFO	Pro350 RT11
+toybox	IN	MX	0  monet.Berkeley.Edu.
+csrg	IN	MX	0 Ralph.CS
+	IN	MX	0 Zhou.CS
+	IN	MX	0 Painter.CS
+	IN	MX	0 Riggle.CS
+	IN	MX	0 Terry.CS
+	IN	MX	0 Kevin.CS
+.TE
+.)b
+.\" .bp
diff --git a/contrib/bind/doc/bog/ucbhosts.rev b/contrib/bind/doc/bog/ucbhosts.rev
new file mode 100644
index 0000000..16207af
--- /dev/null
+++ b/contrib/bind/doc/bog/ucbhosts.rev
@@ -0,0 +1,86 @@
+.\" ++Copyright++ 1986, 1988
+.\" -
+.\" Copyright (c) 1986, 1988
+.\"    The Regents of the University of California.  All rights reserved.
+.\" 
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\" 	This product includes software developed by the University of
+.\" 	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\" 
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\" -
+.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
+.\" 
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies, and that
+.\" the name of Digital Equipment Corporation not be used in advertising or
+.\" publicity pertaining to distribution of the document or software without
+.\" specific, written prior permission.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
+.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
+.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+.\" SOFTWARE.
+.\" -
+.\" --Copyright--
+.\"
+.\"	@(#)ucbhosts.rev	6.3 (Berkeley) 9/19/89
+.\"
+.ne 22v
+.sh 3 "host.rev"
+.(b L
+
+;
+;    @(#)ucb-hosts.rev    1.1    (Berkeley)    86/02/05
+;
+.TS
+l l l l l s. 
+@	IN	SOA	ucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP	kjd\fB.\fPmonet\fB.\fPBerkeley\fB.\fPEdu\fB.\fP (
+.T&
+l l l l l.
+			1986020501	; Serial
+			10800	; Refresh
+			1800	; Retry
+			3600000	; Expire
+			259200 )	; Minimum
+.T&
+l l l l s.
+	IN	NS	ucbarpa\fB.\fPBerkeley\fB.\fPEdu\fB.\fP
+	IN	NS	ucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP
+0\fB.\fP0	IN	PTR	Berkeley-net\fB.\fPBerkeley\fB.\fPEDU\fB.\fP
+	IN	A	255\fB.\fP255\fB.\fP255\fB.\fP0
+0\fB.\fP130	IN	PTR	csdiv-net\fB.\fPBerkeley\fB.\fPEDU\fB.\fP
+4\fB.\fP0	IN	PTR	ucbarpa\fB.\fPBerkeley\fB.\fPEdu\fB.\fP
+6\fB.\fP0	IN	PTR	ernie\fB.\fPBerkeley\fB.\fPEdu\fB.\fP
+7\fB.\fP0	IN	PTR	monet\fB.\fPBerkeley\fB.\fPEdu\fB.\fP
+10\fB.\fP0	IN	PTR	ucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP
+6\fB.\fP130	IN	PTR	monet\fB.\fPBerkeley\fB.\fPEdu\fB.\fP
+.TE
+.)b
diff --git a/contrib/bind/doc/misc/FAQ.1of2 b/contrib/bind/doc/misc/FAQ.1of2
new file mode 100644
index 0000000..ab55bea
--- /dev/null
+++ b/contrib/bind/doc/misc/FAQ.1of2
@@ -0,0 +1,1339 @@
+Newsgroups: comp.protocols.tcp-ip.domains,comp.answers,news.answers
+Path: vixie!news1.digital.com!uunet!in1.uu.net!usc!rutgers!njitgw.njit.edu!hertz.njit.edu!cdp2582
+From: cdp@njit.edu (Chris Peckham)
+Subject: comp.protocols.tcp-ip.domains Frequently Asked Questions (FAQ) (Part 1 of 2)
+Message-ID: <cptd-faq-1-810621452@njit.edu>
+Followup-To: comp.protocols.tcp-ip.domains
+Originator: cdp2582@hertz.njit.edu
+Keywords: BIND,DOMAIN,DNS
+Sender: news@njit.edu
+Supersedes: <cptd-faq-1-807632375@njit.edu>
+Nntp-Posting-Host: hertz.njit.edu
+X-Posting-Frequency: posted on the 1st of each month
+Reply-To: domain-faq@njit.edu (comp.protocols.tcp-ip.domains FAQ comments)
+Organization: NJIT.EDU - New Jersey Institute of Technology, Newark, NJ, USA
+Date: Sat, 9 Sep 1995 04:37:47 GMT
+Approved: news-answers-request@MIT.EDU
+Expires: Sat 14 Oct 95 00:37:32 EDT
+Lines: 1319
+Xref: vixie comp.protocols.tcp-ip.domains:6018 comp.answers:13881 news.answers:49918
+
+Posted-By: auto-faq 3.1.1.2
+Archive-name: internet/tcp-ip/domains-faq/part1
+Revision: 1.6 1995/05/12 18:49:48
+
+
+This FAQ is edited and maintained by Chris Peckham, <cdp@njit.edu>. 
+The latest version may always be found for anonymous ftp from
+
+    ftp://rtfm.mit.edu/pub/usenet/news.answers/internet/tcp-ip/domains-faq
+    ftp://ftp.njit.edu/pub/dns/Comp.protocols.tcp-ip.domains.FAQ
+
+If you can contribute any answers for items in the TODO section, please do
+so by sending e-mail to domain-faq@njit.edu !  If you know of any items that 
+are not included and you feel that they should be,  send the relevant
+information to domain-faq@njit.edu.
+
+
+------------------------------
+
+Date: Fri May 12 14:41:47 EDT 1995
+Subject: Table of Contents
+
+Table of Contents
+=================
+Part 1
+------
+   0. TO DO
+   1. INTRODUCTION / MISCELLANEOUS
+      1.1  What is this newsgroup ?
+      1.2  More information
+      1.3  What is BIND and where is the latest version of BIND ?
+      1.4  How can I find the route between systems ?
+      1.5  Finding the hostname if you have the tcp-ip address
+      1.6  How to register a domain name
+      1.7  Change of Domain name
+      1.8  How memory and CPU does DNS use ?
+      1.9  Other things to consider when planning your servers  
+      1.10 Proper way to get NS and reverse IP records into DNS
+      1.11 How to get my address assign from NIC?
+      1.12 Is there a block of private IP addresses I can use?
+      1.13 Cache failed lookups
+      1.14 What does an NS record really do ?
+      1.15 DNS ports
+      1.16 Obtaining the latest cache file 
+   2. UTILITIES
+      2.1  Utilities to administer DNS zone files
+      2.2  DIG - Domain Internet Groper
+      2.3  DNS packet analyzer
+      2.4  host 
+      2.5  Programming with DNS
+      2.6  A source of information relating to DNS
+   3. DEFINITIONS
+      3.1  TCP/IP Host Naming Conventions
+      3.2  Slaves and servers with forwarders
+      3.3  When is a server authoritative?
+      3.4  Underscore in host-/domain names
+      3.5  Lame delegation
+      3.6  What does opt-class field do?
+      3.7  Top level domains
+      3.8  Classes of networks
+      3.9  What is CIDR ?
+      3.10 What is the rule for glue ?
+
+Part 2
+------
+   4. CONFIGURATION
+      4.1  Changing a Secondary server to a Primary
+      4.2  How do I subnet a Class B Address ?
+      4.3  Subnetted domain name service
+      4.4  Recommended format/style of DNS files
+      4.5  DNS on a system not connected to the Internet
+      4.6  Multiple Domain configuration
+      4.7  wildcard MX records
+      4.8  How to identify a wildcard MX record
+      4.9  Why are fully qualified domain names recommended ?
+      4.10 Distributing load using named
+      4.11 Order of returned records
+      4.12 resolv.conf 
+      4.13 Delegating authority 
+      4.14 DNS instead of NIS on a Sun OS 4.1.x system
+   5. PROBLEMS
+      5.1  No address for root server
+      5.2  Error - No Root Nameservers for Class XX
+      5.3  Bind 4.9.x and MX querying?
+      5.4  Some root nameservers don't know localhost
+      5.5  MX records and CNAMES and separate A records for MX targets
+      5.6  NS is a CNAME
+      5.7  Nameserver forgets own A record
+      5.8  General problems (core dumps !)
+      5.9  malloc and DECstations
+   6. ACKNOWLEDGEMENTS
+
+------------------------------
+
+Date: Wed May  3 12:55:13 EDT 1995
+Subject: Q0 - TO DO list 
+
+
+* How to do an initial installation
+* How to change service providers (what happens)
+* Explain the difference between BIND (an implementation) and DNS (spec)
+* Expand the slave/forward section of Q 3.2
+* Add a definition of a "private domain" in discussion (or cut it out) 
+* mention mail-to-news gateways for newsgroup, mailing lists, anonymous
+  ftp, etc in what is newsgroup section
+* The evils of wildcard MX records
+
+
+
+-------------------------------
+
+Date: Thu Dec  1 11:08:28 EST 1994
+Subject: Q1.1 - What is this newsgroup ?
+
+comp.protocols.tcp-ip.domains is the usenet newsgroup for discussion
+on issues relating to the Domain Name System (DNS).
+
+This newsgroup is not for issues directly relating to IP routing and
+addressing.  Issues of that nature should be directed towards
+comp.protocols.tcp-ip.
+
+
+-------------------------------
+
+
+Date: Fri May 12 13:54:01 EDT 1995
+Subject: Q1.2 - More information
+
+   You can find more information concerning DNS in the following places:
+ 
+   * The BOG (BIND Operations Guide) - in the BIND distribution
+   * The FAQ included with bind4.9.3 doc/misc/FAQ
+   * DNS and BIND by Albitz and Liu (an O'Reilly & Associates Nutshell 
+     handbook)
+   * A number of RFCs (920, 974, 1032, 1034, 1101, 1123, 1178, 1183, 1348,
+                       1535, 1536, 1537, 1591, 1706, 1712, 1713)
+   * The DNS Resource Directory (DNSRD) 
+         http://www.dns.net/dnsrd
+   * If you are having troubles relating to sendmail and DNS, you may wish to
+     refer to the USEnet newsgroup comp.mail.sendmail and/or the FAQ for that
+     newsgroup
+         ftp://rtfm.mit.edu/pub/usenet/news.answers/mail/sendmail-faq
+   * Information concerning some frequently asked questions relating to
+     the Internet (i.e., what is the InterNIC, what is an RFC, what is the
+     IETF, etc) may be found for anonymous ftp from
+         ftp://ds.internic.net/fyi/fyi4.txt
+     A version may also be obtained with the URL
+         gopher://ds.internic.net/00/fyi/fyi4.txt 
+
+
+-------------------------------
+
+Date: Fri Aug  4 10:18:58 EDT 1995
+Subject: Q1.3 - What is BIND and where is the latest version of BIND ?
+
+Q: What is BIND ?
+
+A: From the BOG Introduction -
+
+        The Berkeley Internet Name Domain (BIND)  implements
+   an  Internet  name  server  for the BSD operating system.
+   The BIND consists of  a  server  (or  ``daemon'')  and  a
+   resolver  library.   A  name  server is a network service
+   that enables clients to name  resources  or  objects  and
+   share this information with other objects in the network.
+   This in effect is a  distributed  data  base  system  for
+   objects  in a computer network.  BIND is fully integrated
+   into BSD (4.3 and later releases)  network  programs  for
+   use  in  storing  and  retrieving host names and address.
+   The system administrator can configure the system to  use
+   BIND  as  a replacement to the older host table lookup of
+   information in the network hosts  file  /etc/hosts.   The
+   default configuration for BSD uses BIND.
+
+Q: Where is the latest non-beta version of BIND ?
+ 
+A: The latest non-beta version of BIND is version 4.9.2.  This can be
+   found for anonymous ftp from
+ 
+         ftp://gatekeeper.dec.com/pub/misc/vixie/4.9.2-940221.tar.gz
+ 
+Q: Where is the latest version of 4.9.3 located ?
+
+A: You can reference this URL:
+ 
+        http://www.isc.org/isc/
+ 
+   At this time, the latest version of 4.9.3 may be found for anonymous ftp 
+   from
+ 
+        ftp://ftp.vix.com/pub/bind/testing/bind-4.9.3-BETA24.tar.gz
+
+   You will need GNU zip, Larry Wall's patch program (if there are any
+   patch files), and a C compiler to get BIND running from the above
+   mentioned source.
+
+   GNU zip is available for anonymous ftp from
+
+        ftp://prep.ai.mit.edu/pub/gnu/gzip-1.2.4.tar
+
+   patch is available for anonymous ftp from
+
+        ftp://prep.ai.mit.edu/pub/gnu/patch-2.1.tar.gz
+
+------------------------------
+
+Date: Mon Jan  2 13:27:27 EST 1995
+Subject: Q1.4 - How can I find the route between systems
+
+Q: How can I find the path taken by packets between two systems/domains ?
+ 
+A: Get the source of the 'traceroute' command, compile it and install
+   it on your system.  
+
+   One version of this program with additional functionality may be found
+   for anonymous ftp from
+
+       ftp://ftp.nikhef.nl/pub/network/traceroute.tar.Z
+
+   This package is mirrored at
+
+       ftp://ftp.njit.edu/pub/dns/nikhef/traceroute.tar.Z 
+
+   Another version may be found for anonymous ftp from
+
+       ftp://ftp.psc.edu/pub/net_tools/traceroute.tar
+
+ 
+------------------------------
+
+Date: Thu Dec  1 09:55:24 EST 1994
+Subject: Q1.5 - Finding the hostname if you have the tcp-ip address
+
+Q: Can someone tell me how can I find the name of the domain if I know the
+   tcp-ip address of the domain? Is there some kind of service for this?
+ 
+A: For an address a.b.c.d you can always do:
+ 
+% nslookup
+> set q=ptr
+> d.c.b.a.in-addr.arpa.
+
+   Most newer version of nslookup (since 4.8.3) will recognize an address, 
+   so you can just say:
+
+% nslookup a.b.c.d
+ 
+   DiG will work like this also:
+ 
+$ dig -x a.b.c.d
+
+   Host from the contrib/host from the bind distribution may also be used.
+
+-------------------------------
+ 
+Date: Fri Apr 28 13:16:32 EDT 1995
+Subject: Q1.6 - How to register a domain name
+
+Q: I would like to register a domain.  How do I do this ?   Can a name be
+   reserved, or must we already have an IP address and be hooked up to the
+   Internet before obtaining a domain name?
+ 
+A: You can talk to your Internet Service Provider (ISP).  They can submit 
+   the registration for you.  If you are not going to be directly
+   connected, they should be able to offer MX records for your domain
+   for mail delivery (so that mail sent to the new domain will be sent
+   to your "standard" account).   In the case where the registration is
+   done by the organization itself, it still makes the whole process
+   much easier if the ISP is approached for secondary servers _before_
+   the InterNIC is approached for registration.
+ 
+   For information about making the registration yourself, look to the
+   InterNIC !
+
+        ftp://internic.net/templates/ 
+        gopher://rs.internic.net/
+        http://www.internic.net/infoguide.html
+        http://www.ripe.net
+ 
+   You will need at least two domain name servers when you register your 
+   domain.  Many ISP's are willing to provide primary and/or secondary name 
+   service for their customers.
+
+   Many times, registration of a domain name can be initiated by sending 
+   e-mail to the zone contact. You can obtain the contact in the 
+   SOA record for the country, or in a whois server:
+
+         $ nslookup -type=SOA fr.
+         origin = ns1.nic.fr
+         mail addr = nic.nic.fr
+         ...
+ 
+   The mail address to contact in this case is 'nic@nic.fr' (you must 
+   substitute an '@' for the first dot in the mail addr field).
+ 
+   An alternate method to obtain the e-mail address of the national NIC
+   is the 'whois' server at InterNIC.   
+
+   You may be requested to make your request to another email address or
+   using a certain information template/application.
+
+
+-------------------------------
+
+Date: Sun Nov 27 23:32:41 EST 1994
+Subject: Q1.7 - Change of Domain name
+ 
+Q: We are preparing for a change of our domain name:
+        abc.foobar.com -> foobar.net
+ 
+   What are the tricks and caveats we should be aware of ?
+ 
+A: The forward zones are easy and there are a number of ways to do it.  
+   One way is the following:
+ 
+   Have a single db file for the 2 domains, and have a single machine
+   be the primary server for both abc.foobar.com and foobar.net.
+ 
+   To resolve the host foo in both domains, use a single zone file which
+   merely uses this for the host:
+ 
+foo             IN      A       1.2.3.4
+ 
+   Use a "@" wherever the domain would be used ie for the SOA:
+
+@               IN      SOA     (...
+ 
+   Then use this pair of lines in your named.boot:
+
+primary         abc.foobar.com  db.foobar
+primary         foobar.net      db.foobar
+ 
+   The reverse zones should either contain PTRs to both names,
+   or to whichever name you believe to be canonical currently.
+
+-------------------------------
+
+Date: Fri Apr 28 13:52:20 EDT 1995
+Subject: Q1.8 - How memory and CPU does DNS use ?
+ 
+Q: How much memory and CPU does DNS use ?
+
+A: It can use quite a bit !  The main thing that BIND needs is memory.  
+   It uses very little CPU or network bandwidth.   The main 
+   considerations to keep in mind when planning are:
+
+        1) How many zones do you have and how large are they ?
+        2) How many clients do you expect to serve and how active are they ?
+
+   As an example, here is a snapshot of memory usage from CSIRO Division 
+   of Mathematics and Statistics, Australia
+
+      Named takes several days to stabalize its memory usage.
+ 
+      Our main server stabalises at ~10Mb. It takes about 3 days to
+      reach this size from 6 M at startup. This is under Sun OS 4.1.3U1.
+
+   As another example, here is the configuration of ns.uu.net (from late 
+   1994):
+
+      ns.uu.net only does nameservice.  It is running a version of BIND
+      4.9.3 on a Sun Classic with 96 MB of RAM, 220 MB of swap (remember
+      that Sun OS will reserve swap for each fork, even if it is not needed)
+      running Sun OS 4.1.3_U1.
+
+      Joseph Malcolm, of Alternet, states that named generally hovers at 
+      5-10% of the CPU, except after a reload, when it eats it all.  He 
+      also states that if you are interested in the network connectivity 
+      around the system (ns.uu.net is located off of Falls-Church4), a 
+      PostScript map is available for anonymous ftp from
+
+         ftp://ftp.uu.net/uunet-info/alternet.map.ps
+
+
+-------------------------------
+
+Date: Mon Jan  2 14:24:51 EST 1995
+Subject: Q1.9 - Other things to consider when planning your servers  
+ 
+  When making the plans to set up your servers, you may want to also 
+  consider the following issues:
+ 
+        A) Server O/S limitations/capacities (which tend to be widely
+           divergent from vendor to vendor)
+        B) Client resolver behavior (even more widely divergent)
+        C) Expected query response time
+        D) Redundancy
+        E) Desired speed of change propagation
+        F) Network bandwidth availability
+        G) Number of zones/subdomain-levels desired
+        H) Richness of data stored (redundant MX records? HINFO records?)
+        I) Ease of administration desired
+        J) Network topology (impacts reverse-zone volume)
+ 
+  Assuming a best-possible case for the factors above, particularly (A), (B),
+  (C), (F), (G) & (H), it would be possible to run a 1000-node domain
+  using a single lowly 25 or 40 MHz 386 PC with a fairly modest amount of RAM 
+  by today's standards, e.g. 4 or 8 Meg.   However, this configuration would 
+  be slow, unreliable, and would provide no functionality beyond your basic 
+  address-to-name and name-to-address mappings.
+ 
+  Beyond that baseline case, depending on what factors listed above,
+  you may want look at other strategies, such splitting up the DNS
+  traffic among several machines strategically located, possibly larger ones,
+  and/or subdividing your domain itself. There are many options, tradeoffs, 
+  and DNS architectural paradigms from which to choose.
+
+
+------------------------------
+
+Date: Mon Jan  2 13:03:53 EST 1995
+Subject: Q1.10 - Proper way to get NS and reverse IP records into DNS
+
+ 
+Q: Reverse domain registration is separate from forward domain registration.
+   How do I get it updated ?
+ 
+A: Blocks of network addresses have been delegated by the InterNIC.  Check
+   if your network a.b.c.0 is in such a block by using nslookup:
+
+   nslookup -type=soa c.b.a.in-addr.arpa.
+   nslookup -type=soa b.a.in-addr.arpa.
+   nslookup -type=soa a.in-addr.arpa.
+
+   One of the above should give you the information you are looking for
+   (the others will return with an error something like `*** No start of
+   authority (SOA) records available for ...')
+   This will give you the email address of the person to whom you should
+   address your change request.
+ 
+   If none of these works, your network probably has not been delegated
+   by the InterNIC and you need to contact them directly.
+
+   CIDR has meant that the registration is delegated, but registration
+   of in-addr.arpa has always been separate from forward zones - and
+   for good reason - in that the forward and reverse zones may have
+   different policies, contents etc, may be served by a different set
+   of nameservers, and exist at different times (usually only at point
+   of creation).  There isn't a one-to-one mapping between the two, so
+   merging the registration would probably cause more problems than
+   people forgetting/not-knowing that they had to register in-addr.arpa
+   zones separately.  For example, there are organizations that have
+   hundreds of networks and two or more domains, with a sprinkling of
+   machines from each network in each of the domains.
+
+ 
+-------------------------------
+ 
+Date: Mon Jan  2 13:08:38 EST 1995
+Subject: Q1.11 - How to get my address assign from NIC ?
+
+ 
+Q: Can anyone tell me how can I get the address from NIC?  How many subnets
+   will NIC give to me?
+ 
+A: You should probably ask your Internet provider to give you an address.
+   These days, addresses are being distributed through the providers,
+   so that they can assign adjacent blocks of addresses to sites that
+   go through the same provider, to permit more efficient routing on
+   the backbones.
+ 
+   Unless you have thousands of hosts, you probably won't be able to get a
+   class B these days.  Instead, you can get a series of class C networks.
+   Large requests will be queried, so be ready to provide a network plan if
+   you ask for more than 16 class C networks.
+ 
+   If you can't do this through your Internet provider, you can look for a
+   subnet registration form on rs.internic.net.  See the answer in this FAQ
+   to the question "How to register a domain name" for a URL to these
+   forms.
+ 
+-------------------------------
+
+Date: Mon Jan  2 13:12:01 EST 1995
+Subject: Q1.12 -Is there a block of private IP addresses I can use?
+
+
+Q: Is there a block of private IP addresses I can use?
+ 
+A: This answer may be found in the FAQ for the newsgroup comp.dcom.sys.cisco
+   available for anonymous ftp from
+
+        ftp://rtfm.mit.edu/pub/usenet/comp.dcom.sys.cisco
+
+   There is a block of private IP addresses that you can use.  However 
+   whether you wish to do so is an issue of some debate.
+ 
+   There are two RFCs which discuss this issue, and present opposing
+   views:
+ 
+1597 Address Allocation for Private Internets. Y. Rekhter, B.
+     Moskowitz, D. Karrenberg & G. de Groot. March 1994. (Format:
+     TXT=17430 bytes)
+ 
+1627 Network 10 Considered Harmful (Some Practices Shouldn't be
+     Codified). E. Lear, E. Fair, D. Crocker & T. Kessler. June 1994.
+     (Format: TXT=18823 bytes)
+ 
+   Neither one of these RFCs is anything more than a set of informational
+   guidelines; they are *not* words to live by (remember that RFC stands
+   for Request For Comments). If you're seriously considering using
+   private IP addresses, please read them both.
+ 
+   In any event, RFC 1597 documents the allocation of the following
+   addresses for use by ``private internets'':
+ 
+        10.0.0.0        -   10.255.255.255
+        172.16.0.0      -   172.31.255.255
+        192.168.0.0     -   192.168.255.255
+ 
+   Most importantly, it is vital that nothing using these addresses
+   should ever connect to the global Internet, or have plans to do so.
+   Please read the above RFCs before considering implementing such
+   a policy.
+
+
+-------------------------------
+
+Date: Mon Jan  2 13:55:50 EST 1995
+Subject: Q1.13 - Cache failed lookups
+
+Q: Does BIND cache negative answers (failed DNS lookups) ?
+
+A: Yes, BIND 4.9.3 will cache negative answers.
+
+ 
+-------------------------------
+
+Date: Fri Feb 10 15:35:07 EST 1995
+Subject: Q1.14 - What does an NS record really do ?
+
+Q: What does a NS record really do ?
+
+A: The NS records in your zone data file pointing to the zone's name 
+   servers (as opposed to the servers of delegated subdomains) don't do 
+   much.  They're essentially unused, though they are returned in the 
+   authority section of reply packets from your name servers.
+
+-------------------------------
+
+Date: Fri Feb 10 15:40:10 EST 1995
+Subject: Q1.15 - DNS ports
+
+Q: Does anyone out there have any information/experience on exactly which 
+   TCP/UDP ports DNS uses to send and receive queries ?
+
+A: Use the following chart:
+
+   Prot Src   Dst   Use
+   udp  53    53    Queries between servers (eg, recursive queries)
+                    Replies to above
+   tcp  53    53    Queries with long replies between servers, zone 
+                    transfers Replies to above
+   udp  >1023 53    Client queries (sendmail, nslookup, etc ...)
+   udp  53    >1023 Replies to above
+   tcp  >1023 53    Client queries with long replies
+   tcp  53    >1023 Replies to above
+
+   Note: >1023 is for non-priv ports on Un*x clients. On other client 
+         types, the limit may be more or less.
+
+   Another point to keep in mind when designing filters for DNS is that a
+   DNS server uses port 53 both as the source and destination for it's
+   queries.  So, a client queries an initial server from an unreserved
+   port number to UDP port 53.  If the server needs to query another
+   server to get the required info, it sends a UDP query to that server
+   with both source and destination ports set to 53.  The response is then
+   sent with the same src=53 dest=53 to the first server which then
+   responds to the original client from port 53 to the original source
+   port number.
+ 
+   The point of all this is that putting in filters to only allow UDP
+   between a high port and port 53 will not work correctly, you must also
+   allow the port 53 to port 53 UDP to get through.
+ 
+   Also, ALL versions of BIND use TCP for queries in some cases.  The
+   original query is tried using UDP.  If the response is longer than
+   the allocated buffer, the resolver will retry the query using a TCP
+   connection.  If you block access to TCP port 53 as suggested above,
+   you may find that some things don't work.
+ 
+   Newer version of BIND allow you to configure a list of IP addresses
+   from which to allow zone transfers.  This mechanism can be used to
+   prevent people from outside downloading your entire namespace.
+
+
+-------------------------------
+
+
+Date: Fri Apr 28 14:19:10 EDT 1995
+Subject: Q1.16 - Obtaining the latest cache file
+
+Q: What is the cache file and where can I obtain the latest version ? 
+
+A: From the "Name Server Operations Guide"
+
+      6.3.  Cache Initialization
+ 
+         6.3.1.  root.cache
+ 
+                 The name server needs to know the servers that
+            are  the  authoritative  name  servers for the root
+            domain of the network.  To do this we have to prime
+            the name server's cache with the addresses of these
+            higher authorities.  The location of this  file  is
+            specified  in  the  boot  file. ...
+
+   A copy of the comments in the file available from the InterNIC follow:
+
+      ;       This file holds the information on root name servers needed to
+      ;       initialize cache of Internet domain name servers 
+      ;       (e.g. reference this file in the "cache  .  <file>"
+      ;       configuration file of BIND domain name servers).
+      ;
+      ;       This file is made available by InterNIC registration services
+      ;       under anonymous FTP as
+      ;           file                /domain/named.root
+      ;           on server           FTP.RS.INTERNIC.NET
+      ;       -OR- under Gopher at    RS.INTERNIC.NET
+      ;           under menu          InterNIC Registration Services (NSI)
+      ;              submenu          InterNIC Registration Archives
+      ;           file                named.root
+      ;
+      ;       last update:    Oct 5, 1994
+      ;       related version of root zone:   1994100500
+      ;
+
+   If you have a version of dig running, you may obtain the information with
+   the command
+
+      dig @ns.internic.net . ns
+ 
+
+-------------------------------
+
+
+Date: Mon Jan  2 13:13:49 EST 1995
+Subject: Q2.1 - Utilities to administer DNS zone files
+ 
+Q: I am wondering if there are utilities available to ease the 
+   administration of the zone files in the DNS.
+ 
+A: There are a few.  Two common ones are h2n and makezones.  Both are perl
+   scripts.  h2n is used to convert host tables into zone data files.  It 
+   is available for anonymous ftp from 
+
+   ftp://ftp.uu.net/published/oreilly/nutshell/dnsbind/dns.tar.Z.
+ 
+   makezones works from a single file that looks like a forward zone file,
+   with some additional syntax for special cases.  It is included in the 
+   current BIND distribution.  The newest version is always available for 
+   anonymous ftp from
+
+   ftp://ftp.cus.cam.ac.uk/pub/software/programs/DNS/makezones
+   
+   This package is mirrored at
+
+   ftp://ftp.njit.edu/pub/dns/cus.cam.ac/makezones
+
+   More information may be found using the DNS Resource Directory
+
+   http://www.dns.net/dnsrd
+
+
+-------------------------------
+
+Date: Thu Dec  1 11:09:11 EST 1994
+Subject: Q2.2 - DIG - Domain Internet Groper
+ 
+Q: Where can I find the latest version of DIG ?
+ 
+A: The latest and greatest, official, accept-no-substitutes version of DiG
+   is the one that comes with BIND.  Get the latest kit.
+
+-------------------------------
+
+Date: Mon May 15 12:57:42 EDT 1995
+Subject: Q2.3 -DNS packet analyser
+
+Q: I'm looking for a Ethernet packet analyser of public domain or standard
+   (like tcpdump, snoop, packetman) that is able to determine DNS data
+   field protocol
+ 
+A: There is a free ethernet analyser called Ethload available for PC's 
+   running DOS. The latest filename is ETHLD104.ZIP. It understands lots 
+   of protocols including TCP/UDP. It'll look inside there and display 
+   DNS/BOOTP/ICMP packets etc. (Ed. note: something nice for someone to
+   add to tcpdump ;^) ).  Depending on the ethernet controller it's given 
+   it'll perform slightly differently. It handles NDIS/Novell/Packet 
+   drivers.  It works best with Novell's promiscuous mode drivers.  
+   A A SimTel mirror site should have the program available for anonymous
+   ftp.  As an example,
+
+      ftp://oak.oakland.edu/SimTel/msdos/lan/ethld104.zip
+
+
+-------------------------------
+
+Date: Sun Dec  4 21:15:38 EST 1994
+Subject: Q2.4 - host
+
+A section from the host man page:
+
+     host looks for information about Internet hosts and domain
+     names.  It gets this information from a set of intercon-
+     nected servers that are spread across the world. The infor-
+     mation is stored in the form of "resource records" belonging
+     to hierarchically organized "zones".
+
+     By default, the program simply converts between host names
+     and Internet addresses. However, with the -t, -a and -v
+     options, it can be used to find all of the information about
+     domain names that is maintained by the domain nameserver
+     system.  The information printed consists of various fields
+     of the associated resource records that were retrieved.
+
+     The arguments can be either host names (domain names) or
+     numeric Internet addresses.
+
+'host' is compatible with both BIND 4.9 and BIND 4.8
+ 
+'host' may be found in contrib/host in the BIND distribution.  The latest
+version always available for anonymous ftp from
+
+    ftp://ftp.nikhef.nl/pub/network/host.tar.Z
+
+It may also be found for anonymous ftp from
+
+    ftp://ftp.uu.net/networking/ip/dns/host.tar.Z
+ 
+-------------------------------
+
+Date: Fri Feb 10 15:25:11 EST 1995
+Subject: Q2.5 - Programming with DNS
+
+Q:  How can I use DNS information in my program?
+ 
+A:  It depends on precisely what you want to do:
+ 
+    a) Consider whether you need to write a program at all.  It may well 
+       be easier to write a shell program (e.g. using awk or perl) to parse 
+       the output of dig, host or nslookup.
+ 
+    b) If all you need is names and addresses, there will probably be 
+       system routines 'gethostbyname' and 'gethostbyaddr' to provide this
+       information.
+ 
+    c) If you need more details, then there are system routines (res_query 
+       and res_search) to assist with making and sending DNS queries.  
+       However, these do not include a routine to parse the resulting answer 
+       (although routines to assist in this task are provided).  There is a 
+       separate library available that will take a DNS response and unpick 
+       it into its constituent parts, returning a C structure that can be 
+       used by the program.  The source for this library is available for
+       anonymous ftp from
+
+            ftp://hpux.csc.liv.ac.uk/hpux/Networking/Admin/resparse-*
+
+
+-------------------------------
+
+
+Date: Wed May  3 12:46:50 EDT 1995
+Subject: Q2.6 - A source of information relating to DNS
+
+Q: Where can I find utilities and tools to help me manage my zone files ?
+
+A: There are several tools available.  Please refer to the "tools" section
+   of the DNS resources directory:
+
+      http://www.dns.net/dnsrd/tools.html
+
+
+-------------------------------
+
+
+Date: Fri May 12 14:33:40 EDT 1995
+Subject: Q3.1 - TCP/IP Host Naming Conventions
+
+Q: Is a guide available relating to naming systems ?
+
+A: One guide/resource is RFC 1178, "Choosing a Name for Your Computer", 
+   which is available via anonymous FTP from 
+
+         ftp://ftp.internic.netrfc/rfc1178.txt
+ 
+   RFCs (Request For Comments) are specifications and guidelines for how
+   many aspects of TCP/IP and the Internet (should) work.  Most RFCs are
+   fairly technical documents, and some have semantics that are hotly
+   contested in the newsgroups.  But a few, like RFC 1178, are actually
+   good to read for someone who's just starting along a TCP/IP path.
+
+ 
+-------------------------------
+
+Date: Thu Dec  1 10:32:43 EST 1994
+Subject: Q3.2 - What are slaves and forwarders ?
+
+Q: What are slaves and forwarders ?
+
+A: "forwarders" is a list of NS records that are _prepended_ to a list
+   of NS records to query if the data is not available locally.  This
+   allows a rich cache of records to be built up at a centralized
+   location.  This is good for sites that have sporadic or very slow
+   connections to the Internet.  (demand dial-up, for example)  It's
+   also just a good idea for very large distributed sites to increase
+   the chance that you don't have to go off to the Internet to get an
+   IP address. (sometimes for addresses across the street!)
+ 
+   "slave" modifies this to say to replace the list of NS records
+   with the forwarders entry, instead of prepending to it.  This is
+   for firewalled environments, where the nameserver can't directly
+   get out to the Internet at all.
+
+   "slave" is meaningless (and invalid, in late-model BINDs) without
+   "forwarders".  "forwarders" is an entry in named.boot, and therefore
+   applies only to the nameserver (not to resolvers).
+
+-------------------------------
+
+Date: Mon Jan  2 13:15:13 EST 1995
+Subject: Q3.3 - When is a server authoritative?
+
+
+Q: What criteria does a server use to determine if it is authoritative
+   for a domain?  
+
+A: In the case of BIND:
+        1) The server contains current data in files for the zone in 
+           question (Data must be current for secondaries, as defined 
+           in the SOA)
+        2) The server is told that it is authoritative for the zone, by
+           a 'primary' or 'secondary' keyword in /etc/named.boot.
+        3) The server does an error-free load of the zone.
+
+Q: I have set up a DNS where there is an SOA record for
+   the domain, but the server still does not consider itself
+   authoritative.  (I used nslookup and set server=the correct machine.)
+   It seems to me that something is not matching up somewhere.  I suspect
+   that this is because the service provider has not given us control
+   over the IP numbers in our own domain, and so while the machine listed
+   has an A record for an address, there is no corresponding PTR record.
+
+A: That's possible too, but is unrelated to the first question.
+   You need to be delegated a zone before outside people will start
+   talking to your server.  However, a server can still be authoritative
+   for a zone even though it hasn't been delegated authority (it's just 
+   that only the people who use that as their server will see the data).
+    
+   A server may consider itself non-authoritative even though it's a
+   primary if there is a syntax error in the zone (see point 3 above).
+
+Q: I always believe that it was the NS record that defined authoritative
+   servers.
+
+A: Nope, delegation is a separate issue from authoritativeness.  
+   You can still be authoritative, but not delegated.  (you can also be 
+   delegated, but not authoritative -- that's a "lame delegation")
+
+Q: We have had problems in the past from servers that were
+   authoritative (primary or secondary) but no NS, so other thought they
+   were not.  Some resolvers get very confused when they get non-
+   authoritative data from the primary server.
+
+A: Yes, that's a lame delegation.  That's not caused by what you said,
+   but rather by a server which is _not_ authoritative for a zone, yet
+   someone else (the parent) is saying that a server is authoritative
+   (via the NS records).
+
+   The set of NS records in the parent zone must be a subset of the
+   authoritative servers to avoid lame delegations.
+
+
+-------------------------------
+
+Date: Fri Apr 28 13:26:37 EDT 1995
+Subject: Q3.4 - underscore in host-/domainnames
+
+
+Q: I had a quick look on whether underscores are allowed in host- or 
+   domainnames.
+
+        RFC 1033 allows them.
+        RFC 1035 doesn't.
+        RFC 1123 doesn't.
+        dnswalk complains about them.
+
+   Which RFC is the final authority these days?
+
+A: Actually RFC 1035 deals with names of machines or names of
+   mail domains. i.e "_" is not permitted in a hostname or on the
+   RHS of the "@" in local@domain.
+
+   Underscore is permitted where ever the domain is NOT one of
+   these types of addresses.
+
+   In general the DNS mostly contains hostnames and mail domainnames.
+   This will change as new resource record types for authenticating DNS 
+   queries start to appear.
+
+   The latest version of 'host' checks for illegal characters in A/MX
+   record names and the NS/MX target names.
+
+   After saying all of that, remember that RFC 1123 is a Required Internet 
+   Standard (per RFC 1720), and RFC 1033 isn't.  Even 1035 isn't a required 
+   standard.  Therefore, RFC 1123 wins, no contest.
+
+
+-------------------------------
+
+Date: Fri Dec  2 15:03:56 EST 1994
+Subject: Q3.5 - Lame delegation
+
+Q: What is lame delegation ?
+
+A: Two things are required for a lame delegation:
+        1) A nameserver X is delegated as authoritative for a zone.
+        2) Nameserver X is not performing nameservice for that zone.
+
+   Try to think of a lame delegation as a long-term condition, brought
+   about by a misconfiguration somewhere.  Bryan Beecher's 1992 LISA
+   paper on lame delegations is good to read on this.  The problem
+   really lies in misconfigured nameservers, not "lameness" brought
+   about by transient outages.  The latter is common on the Internet
+   and hard to avoid, while the former is correctable.
+
+   In order to be performing nameservice for a zone, it must have
+   (presumed correct) data for that zone, and it must be answering
+   authoritatively to resolver queries for that zone.  (The AA bit is
+   set in the flags section)
+
+   The "classic" lame delegation case is when nameserver X is delegated
+   as authoritative for domain Y, yet when you ask Y about X, it
+   returns non-authoritative data.
+
+   Here's an example that shows what happens most often (using dig,
+   dnswalk, and doc to find).
+
+   Let's say the domain bogus.com gets registered at the NIC and they
+   have listed 2 primary name servers, both from their *upstream*
+   provider:
+ 
+ bogus.com      IN      NS      ns.bogus.com
+ bogus.com      IN      NS      upstream.com
+ bogus.com      IN      NS      upstream1.com
+
+   So the root servers have this info.  But when the admins at
+   bogus.com actually set up their zone files they put something like:
+ 
+ bogus.com      IN      NS      upstream.com
+ bogus.com      IN      NS      upstream1.com
+
+   So your name server may have the nameserver info cached (which it
+   may have gotten from the root).  The root says "go ask ns.bogus.com"
+   since they are authoritative
+
+   This is usually from stuff being registered at the NIC (either
+   nic.ddn.mil or rs.internic.net), and then updated later, but the
+   folks who make the updates later never let the folks at the NIC know
+   about it.
+
+Q: How can I see if the server is "lame" ?
+
+A: Go to the authoritative servers one level up, and ask them who
+   they think is authoritative, and then go ask each one of those
+   delegees if they think that they themselves are authoritative.  If any
+   responds "no", then you know who the lame delegation is, and who is
+   delegating lamely to them.  You can then send off a message to the
+   administrators of the level above.
+
+   The 'lamers' script from Byran Beecher really takes care of all this
+   for you.  It parses the lame delegation notices from BIND's syslog
+   and summarizes them for you.  It may be found in the contrib section
+   of the latest BIND distribution.  The latest version is available
+   for anonymous ftp from
+
+       ftp://terminator.cc.umich.edu/dns/lame-delegations/
+
+   If you want to actively check for lame delegations, you can use 'doc'
+   and 'dnswalk'.   You can check things manually with 'dig'.
+
+-------------------------------
+
+Date: Thu Dec  1 11:10:39 EST 1994
+Subject: Q3.6 - What does opt-class field do?
+
+Q: Just something I was wondering about: What does the opt-class
+   field in an name database do (the one that always says IN)?
+   What would happen if I put something else there instead?
+
+A: This field is the address class.  From the BOG -
+
+      ...is the address class; currently, only one class
+      is supported: IN  for  internet  addresses  and  other
+      internet information.  Limited support is included for
+      the HS  class,  which  is  for  MIT/Athena  ``Hesiod''
+      information.
+
+-------------------------------
+
+Date: Fri Feb 10 14:49:54 EST 1995
+Subject: Q3.7 - Top level domains
+
+
+A section from RFC 1591:
+
+   2.  The Top Level Structure of the Domain Names
+
+   In the Domain Name System (DNS) naming of computers there is a
+   hierarchy of names.  The root of system is unnamed.  There are a set
+   of what are called "top-level domain names" (TLDs).  These are the
+   generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT), and the two
+   letter country codes from ISO-3166.  It is extremely unlikely that
+   any other TLDs will be created.
+
+[ Ed note:  the ISO-3166 country codes may be found for anonymous ftp from:
+
+     ftp://ftp.isi.edu/in-notes/iana/assignments/country-codes
+     ftp://ftp.ripe.net/iso3166-codes
+]
+
+   Under each TLD may be created a hierarchy of names.  Generally, under
+   the generic TLDs the structure is very flat.  That is, many
+   organizations are registered directly under the TLD, and any further
+   structure is up to the individual organizations.
+
+   In the country TLDs, there is a wide variation in the structure, in
+   some countries the structure is very flat, in others there is
+   substantial structural organization.  In some country domains the
+   second levels are generic categories (such as, AC, CO, GO, and RE),
+   in others they are based on political geography, and in still others,
+   organization names are listed directly under the country code.  The
+   organization for the US country domain is described in RFC 1480.
+
+   Each of the generic TLDs was created for a general category of
+   organizations.  The country code domains (for example, FR, NL, KR,
+   US) are each organized by an administrator for that country.  These
+   administrators may further delegate the management of portions of the
+   naming tree.  These administrators are performing a public service on
+   behalf of the Internet community.  Descriptions of the generic
+   domains and the US country domain follow.
+
+   Of these generic domains, five are international in nature, and two
+   are restricted to use by entities in the United States.
+
+   World Wide Generic Domains:
+
+   COM - This domain is intended for commercial entities, that is
+         companies.  This domain has grown very large and there is
+         concern about the administrative load and system performance if
+         the current growth pattern is continued.  Consideration is
+         being taken to subdivide the COM domain and only allow future
+         commercial registrations in the subdomains.
+
+   EDU - This domain was originally intended for all educational
+         institutions.  Many Universities, colleges, schools,
+         educational service organizations, and educational consortia
+         have registered here.  More recently a decision has been taken
+         to limit further registrations to 4 year colleges and
+         universities.  Schools and 2-year colleges will be registered
+         in the country domains (see US Domain, especially K12 and CC,
+         below).
+
+   NET - This domain is intended to hold only the computers of network
+         providers, that is the NIC and NOC computers, the
+         administrative computers, and the network node computers.  The
+         customers of the network provider would have domain names of
+         their own (not in the NET TLD).
+
+   ORG - This domain is intended as the miscellaneous TLD for
+         organizations that didn't fit anywhere else.  Some non-
+         government organizations may fit here.
+
+   INT - This domain is for organizations established by international
+         treaties, or international databases.
+
+   United States Only Generic Domains:
+
+   GOV - This domain was originally intended for any kind of government
+         office or agency.  More recently a decision was taken to
+         register only agencies of the US Federal government in this
+         domain.  State and local agencies are registered in the country
+         domains (see US Domain, below).
+
+   MIL - This domain is used by the US military.
+
+   Example country code Domain:
+
+   US - As an example of a country domain, the US domain provides for 
+	the registration of all kinds of entities in the United States
+	on the basis of political geography, that is, a hierarchy of
+	<entity-name>.<locality>.<state-code>.US.  For example,
+	"IBM.Armonk.NY.US".  In addition, branches of the US domain are
+	provided within each state for schools (K12), community
+	colleges (CC), technical schools (TEC), state government
+	agencies (STATE), councils of governments (COG),libraries
+	(LIB), museums (MUS), and several other generic types of
+	entities (see RFC 1480 for details).
+
+
+A section from RFC 1480:
+
+   2. NAMING STRUCTURE
+
+       The US Domain hierarchy is based on political geography.  The
+       basic name space under US is the state name space, then the
+       "locality" name space, (like a city, or county) then
+       organization or computer name and so on.
+    
+       For example:
+    
+              BERKELEY.CA.US
+              PORTLAND.WA.US
+    
+       There is of course no problem with running out of names.
+    
+       The things that are named are individual computers.
+    
+       If you register now in one city and then move, the database can
+       be updated with a new name in your new city, and a pointer can
+       be set up from your old name to your new name.  This type of
+       pointer is called a CNAME record.
+    
+       The use of unregistered names is not effective and causes problems
+       for other users.  Inventing your own name and using it without
+       registering is not a good idea.
+    
+       In addition to strictly geographically names, some special names
+       are used, such as FED, STATE, AGENCY, DISTRICT, K12, LIB, CC,
+       CITY, and COUNTY.  Several new name spaces have been created,
+       DNI, GEN, and TEC, and a minor change under the "locality" name
+       space was made to the existing CITY and COUNTY subdomains by
+       abbreviating them to CI and CO.  A detailed description
+       follows.
+    
+       Below US, Parallel to States:
+       -----------------------------
+    
+       "FED" - This branch may be used for agencies of the federal
+       government.  For example: <org-name>.<city>.FED.US
+    
+       "DNI" - DISTRIBUTED NATIONAL INSTITUTES - The "DNI" branch was
+       created directly under the top-level US.  This branch is to be used
+       for distributed national institutes; organizations that span state,
+       regional, and other organizational boundaries; that are national in
+       scope, and have distributed facilities.  For example:
+       <org-name>.DNI.US.
+    
+       Name Space Within States:
+       ------------------------
+    
+       "locality" - cities, counties, parishes, and townships.  Subdomains
+       under the "locality" would be like CI.<city>.<state>.US,
+       CO.<county>.<state>.US, or businesses. For example:
+       Petville.Marvista.CA.US.
+    
+       "CI" - This branch is used for city government agencies and is a
+       subdomain under the "locality" name (like Los Angeles). For example:
+       Fire-Dept.CI.Los-Angeles.CA.US.
+    
+       "CO" - This branch is used for county government agencies and is a
+       subdomain under the "locality" name (like Los Angeles).  For example:
+       Fire-Dept.CO.San-Diego.CA.US.
+    
+       "K12" - This branch may be used for public school districts.  A
+       special name "PVT" can be used in the place of a school district name
+       for private schools.  For example: <school-name>.K12.<state>.US and
+       <school-name>.PVT.K12.<state>.US.
+    
+       "CC" - COMMUNITY COLLEGES - This branch was established for all state
+       wide community colleges.  For example: <school-name>.CC.<state>.US.
+    
+       "TEC" - TECHNICAL AND VOCATIONAL SCHOOLS - The branch "TEC" was
+       established for technical and vocational schools and colleges. For
+       example: <school-name>.TEC.<state>.US.
+    
+       "LIB" - LIBRARIES (STATE, REGIONAL, CITY, COUNTY) - This branch may
+       be used for libraries only.  For example:  <lib-name>.LIB.<state>.US.
+    
+       "STATE" - This branch may be used for state government agencies.  For
+       example:  <org-name>.STATE.<state>.US.
+    
+       "GEN" - GENERAL INDEPENDENT ENTITY - This branch is for the things
+       that don't fit easily into any other structure listed -- things that
+       might fit in to something like ORG at the top-level.  It is best not
+       to use the same keywords (ORG, EDU, COM, etc.) that are used at the
+       top-level to avoid confusion.  GEN would be used for such things as,
+       state-wide organizations, clubs, or domain parks.  For example:
+       <org-name>.GEN.<state-code>.US.
+
+   The application form for the US domain may be found for anonymous ftp 
+   from:
+
+       ftp://internic.net/templates/us-domain-template.txt
+
+   The application form for the EDU, COM, NET, ORG, and  GOV domains may be 
+   found for anonymous ftp from:
+
+       ftp://internic.net/templates/domain-template.txt
+
+ 
+-------------------------------
+
+Date: Sun Nov 27 23:32:41 EST 1994
+Subject: Q3.8 - Classes of networks
+
+Q: I am just kind of curious to what exactly the differences in classes
+   of networks are (class A, B, C).  
+ 
+A: An Internet Protocol (IP) address is 32 bit in length, divided into 
+   two or three parts (the network address, the subnet address (if present),
+   and the host address.  The subnet addresses are only present if the
+   network has been divided into subnetworks.  The length of the network,
+   subnet, and host field are all variable. 
+
+   There are five different network classes.  The leftmost bits indicate 
+   the class of the network.
+
+      # bits in  # bits in
+       network     host
+Class   field     field   Internet Protocol address in binary  Ranges
+============================================================================
+  A       7         24    0NNNNNNN.HHHHHHHH.HHHHHHHH.HHHHHHHH    1-127.x.x.x
+  B      14         16    10NNNNNN.NNNNNNNN.HHHHHHHH.HHHHHHHH  128-191.x.x.x
+  C      22          8    110NNNNN.NNNNNNNN.NNNNNNNN.HHHHHHHH  192-223.x.x.x
+  D      NOTE 1           1110xxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx  224-239.x.x.x
+  E      NOTE 2           11110xxx.xxxxxxxx.xxxxxxxx.xxxxxxxx  240-247.x.x.x
+
+   where N represents part of the network address and H represents part of 
+   the host address.   When the subnet address is defined, the needed bits 
+   are assigned from the host address space.
+
+   NOTE 1: Reserved for multicast groups - RFC 1112
+   NOTE 2: Reserved for future use
+
+   127.0.0.1 is reserved for local loopback.
+ 
+   Under the current arrangements, many class A IP numbers will not be
+   assigned whereas class C usage will be at a premium.   
+ 
+-------------------------------
+
+
+Date: Fri Apr 28 13:31:24 EDT 1995
+Subject: Q3.9 - What is CIDR ?
+
+Q: What is CIDR ?
+
+A: CIDR is "Classless Inter-Domain Routing (CIDR).  From RFC1517:
+
+      ...Classless Inter-Domain Routing (CIDR) attempts to deal with 
+      these problems by defining a mechanism to slow the growth of 
+      routing tables and reduce the need to allocate new IP network 
+      numbers.  
+
+   Much more information may be obtained in RFCs 1467, 1517, 1518, 1520; 
+   with primary reference 1519
+
+
+-------------------------------
+
+
+Date: Fri Apr 28 13:31:24 EDT 1995
+Subject: Q3.10 - What is the rule for glue ?
+
+Q: What is the rule for glue ?
+
+A: A glue record is an A record for a name that appears on the right-hand 
+   side of a NS record.  So, if you have this:
+ 
+        sub.foobar.com.        IN      NS      dns.sub.foobar.com.
+        dns.sub.foobar.com.    IN      A       1.2.3.4
+
+   then the second record is a glue record (for the NS record above it).
+ 
+   You need glue records when -- and only when -- you are delegating
+   authority to a nameserver that "lives" in the domain you are delegating 
+   *and* you aren't a secondary server for that domain.
+
+   In other words, in the example above, you need to add an A record
+   for dns.sub.foobar.com since it "lives" in the domain it serves.
+   This boot strapping information is necessary:  How are you supposed
+   to find out the IP address of the nameserver for domain FOO if the
+   nameserver for FOO "lives" in FOO?
+ 
+   If you have this NS record:
+ 
+        sub.foobar.com.         IN      NS      dns.xyz123.com.
+
+   you do NOT need a glue record, and, in fact, adding one is a very
+   bad idea.  If you add one, and then the folks at xyz123.com change
+   the address, then you will be passing out incorrect data.
+ 
+   Also, unless you actually have a machine called something.IN-ADDR.ARPA, 
+   you will never have any glue records present in any of your "reverse" 
+   files.
+
+   There is also a sort of implicit glue record that can be useful (or 
+   confusing :^) ).  If the parent server (abc.foobar.com domain in example
+   above) is a secondary server for the child, then the A record will be
+   fetched from the child server when the zone transfer is done.  The glue
+   is still there but it's a little different, it's in the ip address in 
+   the named.boot line instead of explicitly in the data.  In this case 
+   you can leave out the explicit glue A record and leave the manually 
+   configured "glue" in just the one place in the named.boot file. 
+
+   RFC 1537 says it quite nicely:
+
+      2. Glue records
+ 
+         Quite often, people put unnecessary glue (A) records in their 
+         zone files. Even worse is that I've even seen *wrong* glue records 
+         for an external host in a primary zone file! Glue records need only 
+         be in a zone file if the server host is within the zone and there 
+         is no A record for that host elsewhere in the zone file.
+ 
+         Old BIND versions ("native" 4.8.3 and older versions) showed the
+         problem that wrong glue records could enter secondary servers in
+         a zone transfer.
diff --git a/contrib/bind/doc/misc/FAQ.2of2 b/contrib/bind/doc/misc/FAQ.2of2
new file mode 100644
index 0000000..ae453c9
--- /dev/null
+++ b/contrib/bind/doc/misc/FAQ.2of2
@@ -0,0 +1,1131 @@
+Newsgroups: comp.protocols.tcp-ip.domains,comp.answers,news.answers
+Path: vixie!news1.digital.com!uunet!in1.uu.net!usc!rutgers!njitgw.njit.edu!hertz.njit.edu!cdp2582
+From: cdp@njit.edu (Chris Peckham)
+Subject: comp.protocols.tcp-ip.domains Frequently Asked Questions (FAQ) (Part 2 of 2)
+Message-ID: <cptd-faq-2-810621452@njit.edu>
+Followup-To: comp.protocols.tcp-ip.domains
+Originator: cdp2582@hertz.njit.edu
+Keywords: BIND,DOMAIN,DNS
+Sender: news@njit.edu
+Supersedes: <cptd-faq-2-807632375@njit.edu>
+Nntp-Posting-Host: hertz.njit.edu
+X-Posting-Frequency: posted on the 1st of each month
+Reply-To: domain-faq@njit.edu (comp.protocols.tcp-ip.domains FAQ comments)
+Organization: NJIT.EDU - New Jersey Institute of Technology, Newark, NJ, USA
+References: <cptd-faq-1-810621452@njit.edu> 
+Date: Sat, 9 Sep 1995 04:38:21 GMT
+Approved: news-answers-request@MIT.EDU
+Expires: Sat 14 Oct 95 00:37:32 EDT
+Lines: 1110
+Xref: vixie comp.protocols.tcp-ip.domains:6019 comp.answers:13882 news.answers:49919
+
+Posted-By: auto-faq 3.1.1.2
+Archive-name: internet/tcp-ip/domains-faq/part2
+Revision: 1.5 1995/05/12 18:50:41
+
+
+This FAQ is edited and maintained by Chris Peckham, <cdp@njit.edu>. 
+The latest version may always be found for anonymous ftp from
+
+    ftp://rtfm.mit.edu/pub/usenet/news.answers/internet/tcp-ip/domains-faq
+    ftp://ftp.njit.edu/pub/dns/Comp.protocols.tcp-ip.domains.FAQ
+
+If you can contribute any answers for items in the TODO section, please do
+so by sending e-mail to domain-faq@njit.edu !  If you know of any items that 
+are not included and you feel that they should be,  send the relevant
+information to domain-faq@njit.edu.
+
+
+------------------------------
+
+Date: Fri May 12 14:41:47 EDT 1995
+Subject: Table of Contents
+
+Table of Contents
+=================
+Part 1
+------
+   0. TO DO
+   1. INTRODUCTION / MISCELLANEOUS
+      1.1  What is this newsgroup ?
+      1.2  More information
+      1.3  What is BIND and where is the latest version of BIND ?
+      1.4  How can I find the route between systems ?
+      1.5  Finding the hostname if you have the tcp-ip address
+      1.6  How to register a domain name
+      1.7  Change of Domain name
+      1.8  How memory and CPU does DNS use ?
+      1.9  Other things to consider when planning your servers  
+      1.10 Proper way to get NS and reverse IP records into DNS
+      1.11 How to get my address assign from NIC?
+      1.12 Is there a block of private IP addresses I can use?
+      1.13 Cache failed lookups
+      1.14 What does an NS record really do ?
+      1.15 DNS ports
+      1.16 Obtaining the latest cache file 
+   2. UTILITIES
+      2.1  Utilities to administer DNS zone files
+      2.2  DIG - Domain Internet Groper
+      2.3  DNS packet analyzer
+      2.4  host 
+      2.5  Programming with DNS
+      2.6  A source of information relating to DNS
+   3. DEFINITIONS
+      3.1  TCP/IP Host Naming Conventions
+      3.2  Slaves and servers with forwarders
+      3.3  When is a server authoritative?
+      3.4  Underscore in host-/domain names
+      3.5  Lame delegation
+      3.6  What does opt-class field do?
+      3.7  Top level domains
+      3.8  Classes of networks
+      3.9  What is CIDR ?
+      3.10 What is the rule for glue ?
+
+Part 2
+------
+   4. CONFIGURATION
+      4.1  Changing a Secondary server to a Primary
+      4.2  How do I subnet a Class B Address ?
+      4.3  Subnetted domain name service
+      4.4  Recommended format/style of DNS files
+      4.5  DNS on a system not connected to the Internet
+      4.6  Multiple Domain configuration
+      4.7  wildcard MX records
+      4.8  How to identify a wildcard MX record
+      4.9  Why are fully qualified domain names recommended ?
+      4.10 Distributing load using named
+      4.11 Order of returned records
+      4.12 resolv.conf 
+      4.13 Delegating authority 
+      4.14 DNS instead of NIS on a Sun OS 4.1.x system
+   5. PROBLEMS
+      5.1  No address for root server
+      5.2  Error - No Root Nameservers for Class XX
+      5.3  Bind 4.9.x and MX querying?
+      5.4  Some root nameservers don't know localhost
+      5.5  MX records and CNAMES and separate A records for MX targets
+      5.6  NS is a CNAME
+      5.7  Nameserver forgets own A record
+      5.8  General problems (core dumps !)
+      5.9  malloc and DECstations
+   6. ACKNOWLEDGEMENTS
+
+------------------------------
+
+Date: Fri Dec  2 15:31:06 EST 1994
+Subject: Q4.1 - Changing a Secondary server to a Primary
+
+Q: Do I need to do anything special when I change a server from a secondary 
+   to a primary ?
+ 
+A: For 4.8.3,  it's prudent to kill and restart following any changes to
+   named.boot.
+ 
+   In BIND 4.9.3, you only have to kill and restart named if you change
+   a primary zone to a secondary or v-v, or if you delete a zone and
+   remain authoritative for its parent.  Every other case should be
+   taken care of by a HUP.  (Ed. note: 4.9.3b9 may still require you to
+   kill and restart the server due to some bugs in the HUP code).
+
+   You will also need to update the server information on the root servers.
+   You can do this by filing a new domain registration form to inform 
+   InterNIC of the change.  They will then update the root server's SOA
+   records.  This process usually takes 10-12 business days after they
+   receive the request.
+
+-------------------------------
+
+Date: Fri Apr 28 13:34:52 EDT 1995
+Subject: Q4.2 - How do I subnet a Class B Address ?
+
+Q: I just received a Class B internet address and I am wondering where to
+   get an RFC or other information on how to properly to the TCP/IP
+   sub-netting.
+ 
+A: That you need to subnet at all is something of a misconception.  You
+   can also think of a class B network as giving you 65,534 individual
+   hosts, and such a network will work. You can also configure your
+   class B as 16,384 networks of 2 hosts each.  That's obviously not
+   very practical, but it needs to be made clear that you are not
+   constrained by the size of an octet (remember that many older
+   devices would not work in a network configured in this manner).
+ 
+   So, the question is: why do you need to subnet?   One reason is that
+   it is easier to manage a subnetted network, and in fact, you can
+   delegate the responsibility for address space management to local
+   administrators on the various subnets.  Also, IP based problems will
+   end up localized rather than affecting your entire network.
+   
+   If your network is a large backbone with numerous segments
+   individually branching off the backbone, that too suggests
+   subnetting.
+
+   Subnetting can also be used to improve routing conditions.
+
+   You may wish to partition your network to disallow certain protocols 
+   on certain segments of your net.  You can, for example, restrict IP or
+   IPX to certain segments only by adding a router routing high level 
+   protocols, and across the router you may have to subnet. 
+
+   Finally, as far as how many subnets you need depends on the answer to
+   the above question.  As far as subnet masks are concerned, the mask
+   can be anything from 255.0.0.0 to 255.255.255.252.  You'll probably be
+   looking at 9 or 10 bits for the subnet (last octet 128 or 192
+   respectively).  RFC1219 discusses the issue of subnetting very well 
+   and leaves the network administrator with a large amount of flexibility
+   for future growth.
+
+
+------------------------------
+ 
+Date: Sun Nov 27 23:32:41 EST 1994
+Subject: Q4.3 -Subnetted domain name service
+
+Q: After doing some reading (DNS and BIND, Albitz&Liu), I don't really
+   find any examples of handling subnetted class C networks as separate
+   DNS domains.
+ 
+A: This is possible, just messy.   You need to delegate down to the
+   fourth octet, so you will have one domain per IP address !  Here is
+   how you can subdelegate a in-addr.arpa address for non-byte aligned 
+   subnet masks:
+
+   Take as an example the net 192.1.1.x, and example subnet mask 
+   255.255.255.240.
+ 
+   We first define the domain for the class C net,
+ 
+$origin  1.1.192.in-addr.arpa
+@       SOA   (usual stuff)
+@       ns  some.nameserver
+        ns  some.other.nameserver
+; delegate a subdomain
+one     ns  one.nameserver
+        ns  some.nameserver
+; delegate another
+two     ns  two.nameserver
+        ns  some.nameserver
+; CNAME pointers to subdomain one
+0       CNAME 0.one
+1       CNAME 1.one
+;    through
+15      CNAME 15.one
+; CNAME pointers to subdomain two
+16      CNAME 16.two
+17      CNAME 17.two
+31      CNAME 31.two
+; CNAME as many as required.
+ 
+ 
+   Now, in the delegated nameserver, one.nameserver
+ 
+$origin one.1.1.192.in-addr.arpa
+@       SOA (usual stuff)
+        NS  one.nameserver
+        NS  some.nameserver   ;  secondary for us
+0       PTR  onenet.one.domain
+1       PTR  onehost.one.domain
+;   through
+15      PTR  lasthost.one.domain
+
+   And similar for the two.1.1.192.in-addr.arpa delegated domain.
+ 
+ 
+------------------------------
+
+Date: Sun Nov 27 23:32:41 EST 1994
+Subject: Q4.4 - Recommended format/style of DNS files
+
+Q:  Are there any suggestions for how to layout DNS configuration files
+    (both forward and reverse)?
+ 
+A: This answer is quoted from an article posted by Paul Vixie:
+ 
+   I've gone back and forth on the question of whether the BOG should
+   include a section on this topic.  I know what I myself prefer, but
+   I'm wary of ramming my own stylistic preferences down the throat of
+   every BOG reader.  But since you ask :-)...
+ 
+   Create /var/named.  If your system is too old to have a /var, either
+   create one or use /usr/local/adm/named instead.  Put your named.boot
+   in it, and make /etc/named.boot a symlink to it.  If your system
+   doesn't have symlinks, you're S-O-L (but you knew that).  In
+   named.boot, put a "directory" directive that specifies your actual
+   BIND working directory:
+ 
+        directory       /var/named
+ 
+   All relative pathnames used in "primary", "secondary", and "cache"
+   directives will be evaluated relative to this directory.  Create two
+   subdirectories, /var/named/pri and /var/named/sec.  Whenever you add
+   a "primary" directive to your named.boot, use "pri/WHATEVER" as the
+   path name.  And then put the primary zone file into "pri/WHATEVER".
+   Likewise when you add "secondary" directives, use "sec/WHATEVER" and
+   BIND (really named-xfer) will create the files in that
+   subdirectory.
+ 
+   (Variations: (1) make a midlevel directory "zones" and put "pri" and
+   "sec" into it; (2) if you tend to pick up a lot of secondaries from
+   a few hosts, group them together in their own subdirectories --
+   something like /var/named/zones/uucp if you're a UUCP Project name
+   server.)
+ 
+   For your forward files, name them after the zone.  dec.com becomes
+   "/var/named/zones/pri/dec.com".  For your reverse files, name them
+   after the network number.  0.1.16.in-addr.arpa becomes
+   "/var/named/zones/pri/16.1.0".
+
+   When creating or maintaining primary zone files, try to use the same
+   SOA values everywhere, except for the serial number which varies per
+   zone.  Put a $ORIGIN directive at the top of the primary zone file,
+   not because its needed (it's not since the default origin is the
+   zone named in the "primary" directive) but because it make it easier
+   to remember what you're working on when you have a lot of primary
+   zones.  Put some comments up there indicating contact information
+   for the real owner if you're proxying.  Use RCS and put the "Id"
+   in a ";" comment near the top of the zone file.
+ 
+   The SOA and other top level information should all be listed
+   together.  But don't put IN on every line, it defaults nicely.  For
+   example:
+ 
+==============
+@       IN      SOA     gw.home.vix.com. postmaster.vix.com. (
+                        1994082501      ; serial
+                        3600    ; refresh (1 hour)
+                        1800    ; retry (30 mins)
+                        604800  ; expire (7 days)
+                        3600 )  ; minimum (1 hour)
+ 
+                NS      gw.home.vix.com.
+                NS      ns.uu.net.
+                NS      uucp-gw-1.pa.dec.com.
+                NS      uucp-gw-2.pa.dec.com.
+ 
+                MX      10 gw.home.vix.com.
+                MX      20 uucp-gw-1.pa.dec.com.
+                MX      20 uucp-gw-1.pa.dec.com.
+==============
+ 
+   I don't necessarily recommend those SOA values.  Not every zone is
+   as volatile as the example shown.  I do recommend that serial number
+   format; it's in date format with a 2-digit per-day revision number.
+   This format will last us until 2147 A.D. at which point I expect a
+   better solution will have been found :-).  (Note that it would last
+   until 4294 A.D. except that there are some old BINDs out there that
+   use a signed quantity for representing serial number interally; I
+   suppose that as long as none of these are still running after 2047
+   A.D., that we can use the above serial number format until 4294
+   A.D., at which point a better solution will HAVE to be found.)
+ 
+   You'll note that I use a tab stop for "IN" even though I never again
+   specify it.  This leaves room for names longer than 7 bytes without
+   messing up the columns.  You might also note that I've put the MX
+   priority and destination in the same tab stop; this is because both
+   are part of the RRdata and both are very different from MX which is
+   an RRtype.  Some folks seem to prefer to group "MX" and the priority
+   together in one tab stop.  While this looks neat it's very confusing
+   to newcomers and for them it violates the law of least
+   astonishment.
+ 
+   If you have a multi-level zone (one which contains names that have
+   dots in them), you can use additional $ORIGIN statements but I
+   recommend against it since there is no "back" operator.  That is,
+   given the above example you can add:
+ 
+=============
+$ORIGIN home
+gw              A       192.5.5.1
+=============
+ 
+   The problem with this is that subsequent RR's had better be
+   somewhere under the "home.vix.com" name or else the $ORIGIN that
+   introduces them will have to use a fully qualified name.  FQDN
+   $ORIGIN's aren't bad and I won't be mad if you use them.
+   Unqualified ones as shown above are real trouble.  I usually stay
+   away from them and just put the whole name in:
+ 
+=============
+gw.home         A       192.5.5.1
+=============
+ 
+   In your reverse zones, you're usually in some good luck because the
+   owner name is usually a single short token or sometimes two.
+ 
+=============
+$ORIGIN 5.5.192.in-addr.arpa.
+@       IN      SOA     ...
+                NS      ...
+1               PTR     gw.home.vix.com.
+=========================================
+$ORIGIN 1.16.in-addr.arpa.
+@       IN      SOA     ...
+                NS      ...
+2.0             PTR     gatekeeper.dec.com.
+=============
+
+   It is usually pretty hard to keep your forward and reverse zones in
+   synch.  You can avoid that whole problem by just using "h2n" (see
+   the ORA book, DNS and BIND, and its sample toolkit, included in the
+   BIND distribution or on ftp.uu.net (use the QUOTE SITE EXEC INDEX
+   command there to find this -- I never can remember where it's at).
+   "h2n" and many tools like it can just read your old /etc/hosts file
+   and churn it into DNS zone files.  (May I recommend
+   contrib/decwrl/mkdb.pl from the BIND distribution?)  However, if you
+   (like me) prefer to edit these things by hand, you need to follow
+   the simple convention of making all of your holes consistent.  If
+   you use 192.5.5.1 and 192.5.5.3 but not (yet) 192.5.5.2, then in
+   your forward file you will have something like
+ 
+=============
+...
+gw.home         A       192.5.5.1
+;avail          A       192.5.5.2
+pc.home         A       192.5.5.3
+=============
+ 
+   and in your reverse file you will have something like
+ 
+=============
+...
+1               PTR     gw.home.vix.com.
+;2              PTR     avail
+3               PTR     pc.home.vix.com.
+=============
+ 
+   This convention will allow you to keep your sanity and make fewer
+   errors.  Any kind of automation (h2n, mkdb, or your own
+   perl/tcl/awk/python tools) will help you maintain a consistent
+   universe even if it's also a complex one.  Editing by hand doesn't
+   have to be deadly but you MUST take care.
+ 
+------------------------------
+ 
+Date: Sun Nov 27 23:32:41 EST 1994
+Subject: Q4.5 - DNS on a system not connected to the Internet
+
+ 
+Q: How do I use DNS on a system that is not connected to the Internet or
+   set BIND up with an internal root server ?
+ 
+A: You need to create your own root domain name server until you connect 
+   to the internet.  Your roots need to delegate to mydomain.com and any
+   in-addr.arpa subdomains you might have, and that's about it.  As
+   soon as you're connected, rip out the fake roots and use the real
+   ones.
+ 
+   It does not actually have to be another server pretending to be the root.
+   You can set up the name server so that it is primary for each domain
+   above you and leave them empty (i.e. you are foo.bar.com - claim to be
+   primary for bar.com and com)
+ 
+Q: What if you connect intermittently and want DNS to work when you are
+   connected, and "fail" when you are not ?
+ 
+A: You can point the resolver at the name server at the remote site and
+   if the connection (SLIP/PPP) isn't up, the resolver doesn't have a
+   route to the remote server and since there's only one name server in
+   resolv.conf, the resolver quickly backs off the using /etc/hosts.
+   No problem.  You could do the same with multiple name server and a
+   resolver that did configurable /etc/hosts fallback.
+ 
+------------------------------
+ 
+Date: Fri Dec  2 15:40:49 EST 1994
+Subject: Q4.6 -Multiple Domain configuration
+
+ 
+Q: I have seen sites that seem to have multiple domain names pointing to the
+   same destination. I would like to implement this and have found no
+   information explaining how to do it. What I would like to do is:
+ 
+      ftp ftp.biff.com connects user to -> ftp.biff.com
+      ftp ftp.fred.com connects user to -> ftp.biff.com
+      ftp ftp.bowser.com connects user to -> ftp.biff.com
+ 
+A: This is done through CNAME records:
+ 
+      ftp.bowser.com.         IN      CNAME ftp.biff.com.
+
+    You can also do the same thing with multiple A records.
+   
+ 
+------------------------------
+ 
+Date: Sun Nov 27 23:32:41 EST 1994
+Subject: Q4.7 - wildcard MX records
+
+Q: Does BIND not understand wildcard MX records such as the following?
+ 
+     *.foo.com       MX      0       mail.foo.com.
+ 
+A: Explicit RR's at one level of specificity will, by design, "block" a
+   wildcard at a lesser level of specificity. I suspect that you have
+   an RR (an A RR, perhaps?) for "bar.foo.com" which is blocking the
+   application of your "*.foo.com" wildcard. The initial MX query is
+   thus failing (NOERROR but an answer count of 0), and the backup
+   query finds the A RR for "bar.foo.com" and uses it to deliver the
+   mail directly (which is what you DIDN'T want it to do).  Adding an
+   explicit MX RR for the host is therefore the right way to handle
+   this situation.
+ 
+   See RFC 1034, Section 4.3.3 ("Wildcards") for more information on
+   this "blocking" behavior, along with an illustrative example. See
+   also RFC 974 for an explanation of standard mailer behavior in the
+   face of an "empty" response to one's MX query.
+ 
+   Basically, what it boils down to is, there is no point in trying to
+   use a wildcard MX for a host which is otherwise listed in the DNS.
+   It just doesn't work.
+ 
+------------------------------
+
+Date: Thu Dec  1 11:10:39 EST 1994
+Subject: Q4.8 - How to identify a wildcard MX record
+
+
+Q: How do you identify a wildcard MX record ?
+
+A: You don't really need to "identify" a wildcard MX RR.  The precedence 
+   for u@dom is:
+ 
+        exact match MX
+        exact match A
+        wildcard MX
+ 
+   One way to implement this is to query for ("dom",IN,MX) and if the
+   answer name that comes back is "*." something, you know it's a
+   wildcard, therefore you know there is no exact match MX, and you
+   therefore query for ("dom",IN,A) and if you get something, use it.
+   if you don't, use the previous wildcard response.
+ 
+   RFC 974 explains this pretty well.
+ 
+------------------------------
+
+Date: Sun Nov 27 23:32:41 EST 1994
+Subject: Q4.9 - Why are fully qualified domain names recommended ?
+
+ 
+Q: Why are fully qualified domain names recommended ?
+ 
+A: The documentation for BIND 4.9.2 says that the hostname should be set 
+   to the full domain style name (i.e host.our.domain rather than
+   host).  What advantages are there in this, and are there any adverse
+   consequences if we don't?
+ 
+A: Paul Vixie likes to do it :-)  He lists a few reasons -
+ 
+   * Sendmail can be configured to just use Dj$w rather than
+     Dj$w.mumble where "mumble" is something you have to edit in by
+     hand.  Granted, most people use "mumble" elsewhere in their config
+     files ("tack on local domain", etc) but why should it be a
+     requirement ?
+ 
+   * The real reason is that not doing it violates a very useful invariant:
+ 
+    gethostbyname(gethostname) == gethostbyaddr(primary_interface_address)
+ 
+     If you take an address and go "backwards" through the PTR's with
+     it, you'll get a FQDN, and if you push that back through the A
+     RR's, you get the same address.  Or you should.  Many multi-homed
+     hosts violate this uncaringly.
+
+     If you take a non-FQDN hostname and push it "forwards" through the
+     A RR's, you get an address which, if you push it through the
+     PTR's, comes back as a FQDN which is not the same as the hostname
+     you started with.  Consider the fact that, absent NIS/YP, there is
+     no "domainname" command analogous to the "hostname" command.
+     (NIS/YP's doesn't count, of course, since it's
+     sometimes-but-only-rarely the same as the Internet domain or
+     subdomain above a given host's name.)  The "domain" keyword in
+     resolv.conf doesn't specify the parent domain of the current host;
+     it specifies the default domain of queries initiated on the
+     current host, which can be a very different thing.  (As of RFC
+     1535 and BIND 4.9.2's compliance with it, most people use "search"
+     in resolv.conf, which overrides "domain", anyway.)
+ 
+     What this means is that there is NO authoritative way to
+     programmatically discover your host's FQDN unless it is set in the
+     hostname, or unless every application is willing to grovel the
+     "netstat -in" tables, find what it hopes is the primary address,
+     and do a PTR query on it.
+ 
+     FQDN /bin/hostnames are, intuitively or not, the simplest way to go.
+ 
+------------------------------
+
+Date: Wed Mar  1 11:04:43 EST 1995
+Subject: Q4.10 - Distributing load using named
+ 
+Q: If you attempt to distribute the load on a system using named, won't 
+   the first response be cached, and then later queries use the cached
+   value? (This would be for requests that come through the same
+   server.)
+ 
+A: Yes.  So it can be useful to use a lower TTL on records where this is
+   important.  You can use values like 300 or 500 seconds.
+
+   If your local caching server has ROUND_ROBIN, it does not matter
+   what the authoritative servers have -- every response from the cache
+   is rotated.
+
+   But if it doesn't, and the authoritative server site is depending on
+   this feature (or the old "shuffle-A") to do load balancing, then if
+   one doesn't use small TTLs, one could conceivably end up with a
+   really nasty situation, e.g., hundreds of workstations at a branch
+   campus pounding on the same front end at the authoritative server's
+   site during class registration.
+
+   Not nice.
+
+A: Paul Vixie has an example of the ROUND_ROBIN code in action.  Here is 
+   something that he wrote regarding his example:
+
+     >I want users to be distributed evenly among those 3 hosts.
+
+     Believe it or not :-), BIND offers an ugly way to do this.  I offer
+     for your collective amusement the following snippet from the
+     ugly.vix.com zone file:
+
+       hydra           cname        hydra1
+                       cname        hydra2
+                       cname        hydra3
+       hydra1          a            10.1.0.1
+                       a            10.1.0.2
+                       a            10.1.0.3
+       hydra2          a            10.2.0.1
+                       a            10.2.0.2
+                       a            10.2.0.3
+       hydra3          a            10.3.0.1
+                       a            10.3.0.2
+                       a            10.3.0.3
+       
+      Note that having multiple CNAME RR's at a given name is
+      meaningless according to the DNS RFCs but BIND doesn't mind (in
+      fact it doesn't even complain).  If you call
+      gethostbyname("hydra.ugly.vix.com") (try it!) you will get
+      results like the following.  Note that there are two round robin
+      rotations going on: one at ("hydra",CNAME) and one at each
+      ("hydra1",A) et al.  I used a layer of CNAME's above the layer of
+      A's to keep the response size down.  If you don't have nine
+      addresses you probably don't care and would just use a pile of
+      CNAME's pointing directly at real host names.
+
+      {hydra.ugly.vix.com}
+      name: hydra2.ugly.vix.com
+      aliases: hydra.ugly.vix.com
+      addresses: 10.2.0.2 10.2.0.3 10.2.0.1
+
+      {hydra.ugly.vix.com}
+      name: hydra3.ugly.vix.com
+      aliases: hydra.ugly.vix.com
+      addresses: 10.3.0.2 10.3.0.3 10.3.0.1
+
+      {hydra.ugly.vix.com}
+      name: hydra1.ugly.vix.com
+      aliases: hydra.ugly.vix.com
+      addresses: 10.1.0.2 10.1.0.3 10.1.0.1
+
+      {hydra.ugly.vix.com}
+      name: hydra2.ugly.vix.com
+      aliases: hydra.ugly.vix.com
+      addresses: 10.2.0.3 10.2.0.1 10.2.0.2
+
+      {hydra.ugly.vix.com}
+      name: hydra3.ugly.vix.com
+      aliases: hydra.ugly.vix.com
+      addresses: 10.3.0.3 10.3.0.1 10.3.0.2
+
+ 
+------------------------------
+ 
+Date: Sun Dec  4 22:12:32 EST 1994
+Subject: Q4.11 - Order of returned records
+
+Q: Is there any way to tell named to return records, specifically
+   address records, in the order in which they are listed in the
+   database?
+
+   It would appear that named consistently applies a sorting algorithm
+   to address records which seems to be virtually guaranteed to be
+   pessimal for our routers, which have many A records.
+
+A: Sorting, is the *resolver's* responsibility.  RFC 1123:
+
+         6.1.3.4  Multihomed Hosts
+
+            When the host name-to-address function encounters a host
+            with multiple addresses, it SHOULD rank or sort the
+            addresses using knowledge of the immediately connected
+            network number(s) and any other applicable performance or
+            history information.
+
+            DISCUSSION:
+                 The different addresses of a multihomed host generally
+                 imply different Internet paths, and some paths may be
+                 preferable to others in performance, reliability, or
+                 administrative restrictions.  There is no general way
+                 for the domain system to determine the best path.  A
+                 recommended approach is to base this decision on local
+                 configuration information set by the system
+                 administrator.
+
+   In BIND 4.9.x's resolver code, the "sortlist" directive in resolv.conf 
+   can be used to configure this.
+
+------------------------------
+
+Date: Fri Feb 10 15:46:17 EST 1995
+Subject: Q4.12 - resolv.conf
+
+
+Q: Why should I use "real" IP addresses in /etc/resolv.conf and not 0.0.0.0 
+   or 127.0.0.1.
+
+A: Paul Vixie writes on the issue of the contents of resolv.conf:
+
+   It's historical.  Some kernels can't unbind a UDP socket's source
+   address, and some resolver versions (notably not including BIND
+   4.9.2 or 4.9.3's) try to do this.  The result can be wide area
+   network traffic with 127.0.0.1 as the source address.  Rather than
+   giving out a long and detailed map of version/vendor combinations of
+   kernels/BINDs that have/don't this problem, I just tell folks not to
+   use 127.0.0.1 at all.
+ 
+   0.0.0.0 is just an alias for the first interface address assigned
+   after a system boot, and if that interface is a up-and-down point to
+   point link (PPP, SLIP, whatever), there's no guarantee that you'll
+   be able to reach yourself via 0.0.0.0 during the entire lifetime of
+   any system instance.  On most kernels you can finesse this by adding
+   static routes to 127.0.0.1 for each of your interface addresses, but
+   some kernels don't like that trick and rather than give a detailed
+   map of which ones work and which ones don't, I just globally
+   recommend against 0.0.0.0.
+ 
+   If you know enough to know that 127.0.0.1 or 0.0.0.0 is safe on your
+   kernel and resolver, then feel free to use them.  If you don't know
+   for sure that it is safe, don't use them.  I never use them (except
+   on my laptop, whose hostname is "localhost" and whose 0.0.0.0 is
+   127.0.0.1 since I ifconfig my lo0 before any other interface).  The
+   operational advantage to using a real IP address rather than an
+   wormhole like 0.0.0.0 or 127.0.0.1, is that you can then "rdist" or
+   otherwise share identical copies of your resolv.conf on all the
+   systems on any given subnet, not all of which will be servers.
+
+A: The problem was with older versions of the resolver (4.8.X).  If you
+   listed 127.0.0.1 as the first entry in resolv.conf, and for whatever
+   reason the local name server wasn't running and the resolver fell
+   back to the second name server listed, it would send queries to the
+   name server with the source IP address set to 127.0.0.1 (as it was
+   set when the resolver was trying to send to 127.0.0.1--you use the
+   loopback address to send to the loopback address).
+
+------------------------------
+
+Date: Mon Jan  2 13:50:13 EST 1995
+Subject: Q4.13 - Delegating authority 
+
+Q: How do I delegate authority for domains within my domain ?
+
+A: When you start having a very big domain that can be broken into logical 
+   and separate entities that can look after their own DNS information,
+   you will probably want to do this.  Maintain a central area for the
+   things that everyone needs to see and delegate the authority for the
+   other parts of the organization so that they can manage themselves.
+    
+   Another essential piece of information is that every domain that
+   exists must have it NS records associated with it.  These NS records
+   denote the name servers that are queried for information about that
+   zone.  For your zone to be recognized by the outside world, the
+   server responsible for the zone above you must have created a NS
+   record for your machine in your domain.  For example, putting the
+   computer club onto the network and giving them control over their
+   own part of the domain space we have the following.
+   
+   The machine authorative for gu.uwa.edu.au is mackerel and the machine
+   authorative for ucc.gu.uwa.edu.au is marlin.
+    
+   in mackerel's data for gu.uwa.edu.au we have the following
+    
+   @               IN      SOA ...
+                   IN      A       130.95.100.3
+                   IN      MX      mackerel.gu.uwa.edu.au.
+                   IN      MX      uniwa.uwa.edu.au.
+    
+   marlin          IN      A       130.95.100.4
+ 
+   ucc             IN      NS      marlin.gu.uwa.edu.au.
+                   IN      NS      mackerel.gu.uwa.edu.au.
+
+   Marlin is also given an IP in our domain as a convenience.  If they
+   blow up their name serving there is less that can go wrong because
+   people can still see that machine which is a start.  You could place
+   "marlin.ucc" in the first column and leave the machine totally
+   inside the ucc domain as well.
+ 
+   The second NS line is because mackerel will be acting as secondary name
+   server for the ucc.gu domain.  Do not include this line if you are not
+   authorative for the information included in the sub-domain.
+
+
+------------------------------
+
+Date: Wed Mar  1 11:45:00 EST 1995
+Subject: Q4.14 - DNS instead of NIS on a Sun OS 4.1.x system
+
+Q: I would appreciate any comments on whether running bind 4.9.x will 
+   enable sendmail, ftp, telnet and other TCP/IP services to bypass
+   NIS and connect directly to named.
+ 
+A: How to do this is documented quite well in the comp.sys.sun.admin FAQ in
+   questions one and two.  You can get them from:
+
+      ftp://thor.ece.uc.edu/pub/sun-faq/FAQs/sun-faq.general 
+      http://www.cis.ohio-state.edu/hypertext/faq/usenet/comp-sys-sun-faq
+
+   as well as from rtfm.mit.edu in the usual place, etc.
+ 
+
+------------------------------
+
+Date: Mon Jan  2 13:49:43 EST 1995
+Subject: Q5.1 - No address for root server
+
+ 
+Q: I've been getting the following messages lately from bind-4.9.2..
+        ns_req: no address for root server
+ 
+We are behind a firewall and have the following for our named.cache file -
+ 
+        ; list of servers
+        .               99999999    IN  NS  POBOX.FOOBAR.COM.
+                        99999999    IN  NS  FOOHOST.FOOBAR.COM.
+        foobar.com.     99999999    IN  NS  pobox.foobar.com.
+ 
+A:  You can't do that.  Your nameserver contacts POBOX.FOOBAR.COM, gets the
+    correct list of root servers from it, then tries again and fails
+    because of your firewall.
+ 
+    You will need a 'forwarder' definition, to ensure that all requests
+    are forwarded to a host which can penetrate the firewall.  And
+    it is unwise to put phony data into 'named.cache'.
+ 
+------------------------------
+
+Date: Sun Nov 27 23:32:41 EST 1994
+Subject: Q5.2 - Error - No Root Nameservers for Class XX
+
+Q: I've received errors before about "No root nameservers for class XX"
+   but they've been because of network connectivity problems.
+   I believe that Class 1 is Internet Class data.
+   And I think I heard someone say that Class 4 is Hesiod??
+   Does anyone know what the various Class numbers are?
+
+A:  From RFC 1700:
+
+       DOMAIN NAME SYSTEM PARAMETERS
+       The Internet Domain Naming System (DOMAIN) includes several
+       parameters.  These are documented in [RFC1034] and [RFC1035].  The
+       CLASS parameter is listed here.  The per CLASS parameters are 
+       defined in separate RFCs as indicated.
+
+       Domain System Parameters:
+
+       Decimal   Name                                          References
+       --------  ----                                          ----------
+              0  Reserved                                           [PM1]
+              1  Internet (IN)                              [RFC1034,PM1]
+              2  Unassigned                                         [PM1]
+              3  Chaos (CH)                                         [PM1]
+              4  Hesoid (HS)                                       [PM1]
+        5-65534  Unassigned                                         [PM1]
+          65535  Reserved                                           [PM1]
+
+DNS information for RFC 1700 was taken from
+
+        ftp://ftp.isi.edu/in-notes/iana/assignments/dns-parameters
+
+   Hesiod is class 4, and there are no official root nameservers for class 
+   4, so you can safely declare yourself one if you like.  You might want 
+   to put up a packet filter so that no one outside your network is capable 
+   of making Hesiod queries of your machines, if you define yourself to be 
+   a root nameserver for class 4.
+
+------------------------------
+ 
+Date: Sun Nov 27 23:32:41 EST 1994
+Subject: Q5.3 - Bind 4.9.x and MX querying?
+
+ 
+Q: If I query a 4.9.x DNS server for MX records, a list of the MX records 
+   as well as a list of the authorative nameservers is returned.  Why ?
+ 
+A: Bind 4.9.2 returns the list of nameserver that are authorative
+   for a domain in the response packet, along with their IP
+   addresses in the additional section.
+ 
+------------------------------
+
+Date: Sat Sep  9 00:36:01 EDT 1995
+Subject: Q5.4 - Some root nameservers don't know localhost
+
+Q: Do I need to define an A record for localhost ?
+
+   Where is the A record for 127.0.0.1 defined?  I see where
+   the PTR record is defined pointing to localhost, but can't find
+   where the A record is.  And is the A record supposed to be
+   localhost.MY_DOMAIN or just localhost ?
+
+A: Somewhere deep in the BOG (BIND Operations Guide) that came with
+   4.9.3 (section 5.4.3), it says that you define this yourself 
+   (if need be) in the same zone files as your "real" IP addresses 
+   for your domain.  Quoting the BOG:
+
+                                 ... As  implied by this PTR
+         record, there should be a  ``localhost.my.dom.ain''
+         A  record  (with address 127.0.0.1) in every domain
+         that contains hosts.  ``localhost.'' will lose  its
+         trailing dot when 1.0.0.127.in-addr.arpa is queried
+         for;...
+
+   The sample files in the BIND distribution show you what needs to be
+   done (see the BOG).
+
+   Some HP boxen (especially those running HP OpenView) will also need
+   "loopback" defined with this IP address.   You may set it as a CNAME 
+   record pointing to the "localhost." record.
+
+------------------------------
+ 
+Date: Sun Nov 27 23:32:41 EST 1994
+Subject: Q5.5 - MX records and CNAMES and separate A records for MX targets
+
+Q: The O'Reilly "DNS and Bind" book warns against using non-canonical
+   names in MX records, however, this warning is given in the context
+   of mail hubs that MX to each other for backup purposes.  I don't see
+   how this applies to mail spokes.  RFC 974 has a similar warning, but
+   I can not see where it specifically prohibits using an alias in an
+   MX record.
+ 
+A: Without the restrictions in the RFC, a MTA must request the A records 
+   for every MX listed to determine if it is in the MX list then reduce
+   the list. This introduces many more lookups than would other wise be
+   required. If you are behind a 1200 bps link YOU DON'T WANT TO DO
+   THIS. The addresses associated with CNAMES are not passed as
+   additional data so you will force additional traffic to result even
+   if you are running a caching server locally.
+ 
+   There is also the problem of how does the MTA find all of it's
+   IP addresses. This is not straight forward. You have to be able
+   to do this is you allow CNAMEs (or extra A's) as MX targets.
+ 
+   The letter of the law is that an MX record should point to an A record.
+       
+   There is no "real" reason to use CNAMEs for MX targets or separate
+   As for nameservers any more. CNAMEs for services other than mail
+   should be used because there is no specified method for locating the
+   desired server yet.
+ 
+   People don't care what the names of MX targets are.  They're
+   invisible to the process anyway.  If you have mail for "mary"
+   redirected to "sue" is totally irrelevant.  Having CNAMEs as the
+   targets of MX's just needlessly complicates things, and is more work
+   for the resolver.
+ 
+   Having separate A's for nameservers like "ns.your.domain" is
+   pointless too, since again nobody cares what the name of your
+   nameserver is, since that too is invisible to the process.  If you
+   move your nameserver from "mary.your.domain" to "sue.your.domain"
+   nobody need care except you and your parent domain administrator
+   (and the InterNIC).  Even less so for mail servers, since only you
+   are affected.
+
+Q: Given the example - 
+
+     hello in cname     realname
+     mailx in mx        0 hello
+
+   Now, while reading the operating manual of bind it clearly states
+   that this is *not* valid.  These two statements clearly contradict
+   each other.  Is there some later rfc than 974 that overrides what is
+   said in there with respect to MX and CNAMEs?  Anyone have the
+   reference handy?
+
+A: This isn't what the BOG says at all.  See below.  You can have a CNAME 
+   that points to some other RR type; in fact, all CNAMEs have to point
+   to other names (Canonical ones, hence the C in CNAME).  What you
+   can't have is an MX that points to a CNAME.  MX RR's that point to
+   names which have only CNAME RR's will not work in many cases, and
+   RFC 974 intimates that it's a bad idea:
+
+      Note that the algorithm to delete irrelevant RRs breaks if LOCAL has
+      a alias and the alias is listed in the MX records for REMOTE.  (E.g.
+      REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL).  This
+      can be avoided if aliases are never used in the data section of MX
+      RRs.
+
+   Here's the relevant BOG snippet:
+
+         aliases    {ttl}   addr-class   CNAME   Canonical name
+         ucbmonet           IN           CNAME   monet
+
+         The  Canonical  Name resource record, CNAME, speci-
+         fies an alias or  nickname  for  the  official,  or
+         canonical,  host  name.   This record should be the
+         only one associated with the alias name.  All other
+         resource  records  should  be associated  with the
+         canonical  name,  not  with  the   nickname.  Any
+         resource  records  that  include  a  domain name as
+         their value (e.g., NS or MX) must list the  canoni-
+         cal name, not the nickname.
+
+------------------------------
+ 
+Date: Wed Mar  1 11:14:10 EST 1995
+Subject: Q5.6 - NS is a CNAME
+
+Q: Can I do this ?  Is it legal ?
+
+   @                       SOA     (.........)
+                           NS      ns.host.this.domain.
+                           NS      second.host.another.domain.
+   ns                      CNAME   third
+   third           IN      A       xxx.xxx.xxx.xxx
+
+
+A: No.  Only one RR type is allowed to refer, in its data field, to a
+   CNAME, and that's CNAME itself.  So CNAMEs can refer to CNAMEs but 
+   NSs and MXs cannot.
+
+   BIND 4.9.3 (Beta11 and later) explicitly syslogs this case rather than 
+   simply failing as pre-4.9 servers did.  Here's a current example:
+
+    Dec  7 00:52:18 gw named[17561]: \
+                   "foobar.com IN NS" points to a CNAME (foobar.foobar.com)
+
+   Here is the reason why:
+
+      Nameservers are not required to include CNAME records in the
+      Additional Info section returned after a query.  It's partly an
+      implementation decision and partly a part of the spec.  The
+      algorithm described in RFC 1034 (pp24,25; info also in RFC 1035,
+      section 3.3.11, p 18) says 'Put whatever addresses are available
+      into the additional section, using glue RRs [if necessary]'.
+      Since NS records are speced to contain only primary names of
+      hosts, not CNAMEs, then there's no reason for algorithm to
+      mention them. If, on the other hand, it's decided to allow CNAMEs
+      in NS records (and indeed in other records) then there's no
+      reason that CNAME records might not be included along with A
+      records.  The Additional Info section is intended for any
+      information that might be useful but which isn't strictly the
+      answer to the DNS query processed.  It's an implementation
+      decision in as much as some servers used to follow CNAMEs in 
+      NS references.
+
+
+------------------------------
+
+Date: Fri Dec  2 16:17:31 EST 1994
+Subject: Q5.7 - Nameserver forgets own A record
+
+ 
+Q: Lately, I've been having trouble with named 4.9.2 and 4.9.3.  
+   Periodically, the nameserver will seem to "forget" its own A record,
+   although the other information stays intact.  One theory I had was
+   that somehow a site that the nameserver was secondary for was
+   "corrupting" the A record somehow.
+ 
+A: This is invariably due to not removing ALL of the cached zones
+   when you moved to 4.9.X. Remove ALL cached zones and restart
+   your nameservers.
+ 
+   You get "ignoreds" because the primaries for the relevant zones are
+   running old versions of BIND which pass out more glue than is
+   required. named-xfer trims off this extra glue.
+ 
+------------------------------
+
+Date: Sun Dec  4 22:21:22 EST 1994
+Subject: Q5.8 - General problems (core dumps !)
+
+Q: I am running bind 4.9.3b9p1 on a DEC alpha OSF/1 V3.0 and have had it 
+   core dump while in debug mode.  The last lines printed to named.run 
+   were [...]
+
+A: Paul Vixie says:
+
+   I'm always interested in hearing about cases where BIND dumps core.
+   However, I need a stack trace.   Compile with -g and not -O (unless
+   you are using gcc and know what you are doing) and then when it
+   dumps core, get into dbx or gdb using the executable and the core
+   file and use "bt" to get a stack trace.   Send it to me
+   <paul@vix.com> along with specific circumstances leading to or
+   surrounding the crash (test data, tail of the debug log, tail of the
+   syslog... whatever matters) and ideally you should save your core
+   dump for a day or so in case I have questions you can answer via
+   gdb/dbx.
+
+------------------------------
+
+Date: Mon Jan  2 14:19:22 EST 1995
+Subject: Q5.9 - malloc and DECstations
+
+We have replaced malloc on our DECstations with a malloc that is more 
+compact in memory usage, and this helped the operation of bind a lot.
+The source is now available for anonymous ftp from
+
+   ftp://ftp.cs.wisc.edu/pub/misc/malloc.tar.gz
+ 
+
+------------------------------
+
+Date: Fri Apr 28 13:56:32 EDT 1995
+Subject: Q6 - Acknowledgements
+
+Listed in e-mail address alphabetical order, the following people have 
+contributed to this FAQ:
+
+Benoit.Grange@inria.fr (Benoit.Grange)
+D.T.Shield@csc.liv.ac.uk (Dave Shield)
+adam@comptech.demon.co.uk (Adam Goodfellow)
+andras@is.co.za (Andras Salamon)
+barmar@nic.near.net (Barry Margolin)
+barr@pop.psu.edu (David Barr)
+bj@herbison.com (B.J. Herbison)
+bje@cbr.fidonet.org (Ben Elliston)
+brad@birch.ims.disa.mil (Brad Knowles)
+ckd@kei.com (Christopher Davis)
+cdp@hertz.njit.edu (Chris Peckham)
+cricket@hp.com (Cricket Liu)
+cudep@csv.warwick.ac.uk (Ian 'Vato' Dickinson [ID17])
+dparter@cs.wisc.edu (David Parter)
+e07@nikhef.nl (Eric Wassenaar)
+fwp@CC.MsState.Edu (Frank Peters)
+gah@cco.caltech.edu (Glen A. Herrmannsfeldt) 
+glenn@popco.com (Glenn Fleishman)
+harvey@indyvax.iupui.edu (James Harvey)
+hubert@cac.washington.edu (Steve Hubert)
+jmalcolm@uunet.uu.net (Joseph Malcolm)
+jhawk@panix.com (John Hawkinson)
+kevin@cfc.com (Kevin Darcy)
+lamont@abstractsoft.com (Sean T. Lamont)
+lavondes@tidtest.total.fr (Michel Lavondes)
+mark@ucsalf.ac.uk (Mark Powell)
+marka@syd.dms.CSIRO.AU (Mark Andrews)
+mathias@unicorn.swi.com.sg (Mathias Koerber)
+mjo@iao.ford.com (Mike O'Connor)
+nick@flapjack.ieunet.ie (Nick Hilliard)
+patrick@oes.amdahl.com (Patrick J. Horgan)
+ph10@cus.cam.ac.uk (Philip Hazel)
+rv@seins.Informatik.Uni-Dortmund.DE (Ruediger Volk)
+shields@tembel.org (Michael Shields)
+tanner@george.arc.nasa.gov (Rob Tanner)
+vixie@vix.com (Paul A Vixie)
+wag@swl.msd.ray.com (William Gianopoulos {84718})
+whg@inel.gov (Bill Gray)
+wolf@pasteur.fr (Christophe Wolfhugel)
+
+Thank you !
+
diff --git a/contrib/bind/doc/misc/IPv6 b/contrib/bind/doc/misc/IPv6
new file mode 100644
index 0000000..49fc3f5
--- /dev/null
+++ b/contrib/bind/doc/misc/IPv6
@@ -0,0 +1,72 @@
+IPv6 notes for BIND 4.9.3 Patch 2 Candidate 5 (and later?)
+Paul Vixie, May 20, 1996
+doc/misc/IPv6
+
+			*** Introduction ***
+
+The IPv6 support in this release is latent, in that its presence is not
+documented.  The support is not optional, since its presence ought not to
+affect anyone who does not go looking for it.  The support includes:
+
+	inet_ntop()	new function.
+	inet_pton()	new function.
+	RES_USE_INET6	causes gethostby*() to return either real IPv6
+			addresses (if available) or mapped (::FFFF:a.b.c.d)
+			addresses if only IPv4 address records are found.
+	gethostbyname()	can search for T_AAAA in preference to T_A.
+	gethostbyaddr()	can search in IP6.INT for PTR RR's.
+	named		can load, transfer, cache, and dump T_AAAA RRs.
+
+		*** Some notes on the new functions ***
+
+The inet_pton() and inet_ntop() functions differ from the current (as of
+this writing) IPv6 BSD API draft.  Discussions were held, primarily between
+myself and Rich Stevens, on the ipng@sunroof.eng.sun.com mailing list, and
+the BIND definitions of these functions are likely to go into the next draft.
+(If not, and BIND has to change its definitions of these functions, then you
+will know why I chose not to document them yet!)
+
+These functions can return error values, and as such the process of porting
+code that used inet_aton() to use inet_pton() is not just syntactic.  Not all
+nonzero values indicate success; consider "-1".  Likewise, inet_ntoa() is not
+just smaller than inet_ntop() -- it's a whole new approach.  Inet_ntop() does
+not return a static pointer, the caller has to supply a sized buffer.  Also,
+inet_ntop() can return NULL, so you should only printf() the result if you
+have verified that your arguments will be seen as error free.
+
+The inet_pton() function is much pickier about its input format than the old
+inet_aton() function has been.  You can't abbreviate 10.0.0.53 as 10.53 any
+more.  Hexadecimal isn't accepted.  You have to supply four decimal numeric
+strings, each of whose value is within the range from 0 to 255.  No spaces
+are allowed either before, after, or within an address.  If you need the older
+functionality with all the shortcuts and exceptions, continue using inet_aton()
+for your IPv4 address parsing needs.
+
+		   *** Some notes on RES_USE_INET6 ***
+
+You can set this by modifying _res.options after calling res_init(), or you
+can turn it on globally by setting "options inet6" in /etc/resolv.conf.  This
+latter option ought to be used carefully, since _all_ applications will then
+receive IPv6 style h_addr_list's from their gethostby*() calls.  Once you know
+that every application on your system can cope with IPv6 addressing, it is safe
+and reasonable to turn on the global option.  Otherwise, don't do it.
+
+		*** Some notes on mapped IPv4 addresses ***
+
+There are two IPv6 prefixes set aside for IPv4 address encapsulation.  See
+RFC 1884 for a detailed explaination.  The ::a.b.c.d form is used for
+tunnelling, which means wrapping an IPv4 header around IPv6 packets and using
+the existing IPv4 routing infrastructure to reach what are actually IPv6
+endpoints.  The ::FFFF:a.b.c.d form can be used on dual-stack (IPv4 and IPv6)
+hosts to signal a predominantly IPv6 stack that it should use ``native'' IPv4
+to reach a given destination, even though the socket's address family is
+AF_INET6.
+
+BIND supports both of these address forms, to the extent that inet_pton() will
+parse them, inet_ntop() will generate them, gethostby*() will map IPv4 into
+IPv6 if the RES_USE_INET6 option is set, and gethostbyaddr() will search the
+IN-ADDR.ARPA domain rather than the IP6.INT domain when it needs a PTR RR.
+This last bit of behaviour is still under discussion and it's not clear that
+tunnelled addresses should be mapped using IN-ADDR.ARPA.  In other words, this
+bit of behaviour may change in a subsequent BIND release.  So now you know
+another reason why none of this stuff is ``officially'' documented.
diff --git a/contrib/bind/doc/misc/dns-setup b/contrib/bind/doc/misc/dns-setup
new file mode 100644
index 0000000..19f0197
--- /dev/null
+++ b/contrib/bind/doc/misc/dns-setup
@@ -0,0 +1,1081 @@
+                Setting up a basic DNS server for a domain
+                            Revision 1.1.1
+
+                            Craig Richmond
+                         craig@ecel.uwa.edu.au
+                           15th August 1993
+
+
+About this document
+
+I have written this file because it seems that the same questions seem to
+pop up time and time again and when I had to install DNS from scratch the
+first time, we found very little to help us.
+
+This document covers setting up a Domain Name Server with authority over
+your domain and using a few of the more useful but less well known
+(hopefully this document will take care of that) features of nslookup to
+get information about the DNS and to work out why yours isn't working.
+
+If you are using a Sun Workstation and you want to make NIS interact with
+the DNS, then this is not the FAQ for you (but it may well be when you try
+to set up the DNS).  Mark J. McIntosh <Mark.McIntosh@engr.UVic.CA> points
+out that it is included in the comp.sys.sun.admin FAQ and for the benefit
+of those of you who can't get that (it is posted in comp.sys.sun.admin,
+comp.sys.sun.misc, comp.unix.solaris, comp.answers and news.answers) I have
+included the relevant parts at the bottom in appendix C.
+
+Contents:
+
+   Contents
+   An Overview of the DNS
+   Installing the DNS
+    *The Boot File
+    *The Cache File
+    *The Forward Mapping File
+    *The Reverse Mapping File
+   Delegating authority for domains within your domain
+   Troubleshooting your named
+    *Named doesn't work!  What is wrong?
+    *I changed my named database and my local machine has noticed,
+     but nobody else has the new information?
+    *My local machine knows about all the name server information,
+     but no other sites know about me?
+    *My forward domain names work, but the backward names do not?
+   How to get useful information from nslookup
+    *Getting number to name mappings.
+    *Finding where mail goes when a machine has no IP number.
+    *Getting a list of machines in a domain from nslookup.
+   Appendicies
+    *Appendix A  sample root.cache file
+    *Appendix B  Excerpt from RFC 1340 - Assigned Numbers - July 1992
+    *Appendix C  Installing DNS on a Sun when running NIS
+
+
+An Overview of the DNS:
+
+The Domain Name System is the software that lets you have name to number
+mappings on your computers.  The name decel.ecel.uwa.edu.au is the number
+130.95.4.2 and vice versa.  This is achieved through the DNS.  The DNS is a
+heirarchy.  There are a small number of root domain name servers that are
+responsible for tracking the top level domains and who is under them.  The
+root domain servers between them know about all the people who have name
+servers that are authoritive for domains under the root.
+
+Being authoritive means that if a server is asked about something in that
+domain, it can say with no ambiguity whether or not a given piece of
+information is true.  For example.  We have domains x.z and y.z.  There are
+by definition authoritive name servers for both of these domains and we
+shall assume that the name server in both of these cases is a machine
+called nic.x.z and nic.y.z but that really makes no difference.
+
+If someone asks nic.x.z whether there is a machine called a.x.z, then
+nic.x.z can authoritively say, yes or no because it is the authoritive name
+server for that domain.  If someone asks nic.x.z whether there is a machine
+called a.y.z then nic.x.z asks nic.y.z whether such a machine exists (and
+caches this for future requests).  It asks nic.y.z because nic.y.z is the
+authoritive name server for the domain y.z.  The information about
+authoritive name servers is stored in the DNS itself and as long as you
+have a pointer to a name server who is more knowledgable than yourself then
+you are set.
+
+When a change is made, it propogates slowly out through the internet to
+eventually reach all machines.  The following was supplied by Mark Andrews
+Mark.Andrews@syd.dms.csiro.au.
+
+        If both the primary and all secondaries are up and talking when
+        a zone update occurs and for the refresh period after the
+        update the old data will live for max(refresh + mininum)
+        average (refresh/2 +mininum) for the zone. New information will
+        be available from all servers after refresh.
+
+So with a refresh of 3 hours and a minimum of a day, you can expect
+everything to be working a day after it is changed.  If you have a longer
+minimum, it may take a couple of days before things return to normal.
+
+There is also a difference between a zone and a domain.  The domain is the
+entire set of machines that are contained within an organisational domain
+name.  For example, the domain uwa.edu.au contains all the machines at the
+University of Western Australia.  A Zone is the area of the DNS for which a
+server is responsible.  The University of Western Australia is a large
+organisation and trying to track all changes to machines at a central
+location would be difficult.  The authoritive name server for the zone
+uwa.edu.au delegates the authority for the zone ecel.uwa.edu.au to
+decel.ecel.uwa.edu.au.  Machine foo.ecel.uwa.edu.au is in the zone that
+decel is authoritive for.  Machine bar.uwa.edu.au is in the zone that
+uniwa.uwa.edu.au is authoritive for.
+
+Installing the DNS:
+
+First I'll assume you already have a copy of the Domain Name Server
+software.  It is probably called named or in.named depending on your
+flavour of unix.  I never had to get a copy, but if anyone thinks that
+information should be here then by all means tell me and I'll put it in.
+If you intend on using the package called Bind, then you should be sure
+that you get version 4.9, which is the most recent version at this point in
+time.
+
+The Boot File:
+
+First step is to create the file named.boot.  This describes to named
+(we'll dispense with the in.named.  Take them to be the same) where the
+information that it requires can be found.  This file is normally found in
+/etc/named.boot and I personally tend to leave it there because then I know
+where to find it.  If you don't want to leave it there but place it in a
+directory with the rest of your named files, then there is usually an
+option on named to specify the location of the boot file.
+
+Your typical boot file will look like this if you are an unimportant leaf
+node and there are other name servers at your site.
+
+directory	/etc/namedfiles
+
+cache		.	       				root.cache
+primary		ecel.uwa.edu.au				ecel.uwa.domain
+primary		0.0.127.in-addr.arpa			0.0.127.domain
+primary		4.95.130.in-addr.arpa			4.95.130.domain
+forwarders      130.95.128.1
+
+Here is an alternative layout used by Christophe Wolfhugel
+<Christophe.Wolfhugel@grasp.insa-lyon.fr>  He finds this easier because of
+the large number of domains he has.  The structure is essentially the same,
+but the file names use the domain name rather than the IP subnet to
+describe the contents.
+
+directory       /usr/local/etc/bind
+cache     .                      p/root
+;
+; Primary servers
+;
+primary   fr.net                        p/fr.net
+primary   frmug.fr.net                  p/frmug.fr.net
+primary   127.in-addr.arpa              p/127
+;
+; Secondary servers
+;
+secondary ensta.fr                 147.250.1.1     s/ensta.fr
+secondary gatelink.fr.net          134.214.100.1   s/gatelink.fr.net
+secondary insa-lyon.fr             134.214.100.1   s/insa-lyon.fr
+secondary loesje.org               145.18.226.21   s/loesje.org
+secondary nl.loesje.org            145.18.226.21   s/nl.loesje.org
+secondary pcl.ac.uk                161.74.160.5    s/pcl.ac.uk
+secondary univ-lyon1.fr            134.214.100.1   s/univ-lyon1.fr
+secondary wmin.ac.uk               161.74.160.5    s/wmin.ac.uk
+secondary westminster.ac.uk        161.74.160.5    s/westminster.ac.uk
+;
+;
+; Secondary for addresses
+;
+secondary 74.161.in-addr.arpa      161.74.160.5    s/161.74
+secondary 214.134.in-addr.arpa     134.214.100.1   s/134.214
+secondary 250.147.in-addr.arpa     147.250.1.1     s/147.250
+;
+; Classes C
+;
+secondary 56.44.192.in-addr.arpa   147.250.1.1     s/192.44.56
+secondary 57.44.192.in-addr.arpa   147.250.1.1     s/192.44.57
+
+The lines in the named.boot file have the following meanings.
+
+directory
+
+This is the path that named will place in front of all file names
+referenced from here on.  If no directory is specified, it looks for files
+relative to /etc.
+
+cache
+
+This is the information that named uses to get started.  Named must know
+the IP number of some other name servers at least to get started.
+Information in the cache is treated differently depending on your version
+of named.  Some versions of named use the information included in the cache
+permenantly and others retain but ignore the cache information once up and
+running.
+
+primary
+
+This is one of the domains for which this machine is authorative for.  You
+put the entire domain name in.  You need forwards and reverse lookups.  The
+first value is the domain to append to every name included in that file.
+(There are some exceptions, but they will be explained later)  The name at
+the end of the line is the name of the file (relative to /etc of the
+directory if you specified one).  The filename can have slashes in it to
+refer to subdirectories so if you have a lot of domains you may want to
+split it up.
+
+BE VERY CAREFUL TO PUT THE NUMBERS BACK TO FRONT FOR THE REVERSE LOOK UP
+FILE.  The example given above is for the subnet ecel.uwa.edu.au whose IP
+address is 130.95.4.*.  The reverse name must be 4.95.130.in-addr.arpa.
+It must be backwards and it must end with .in-addr.arpa.  If your reverse
+name lookups don't work, check this.  If they still don't work, check this
+again.
+
+forwarders
+
+This is a list of IP numbers for forward requests for sites about which we
+are unsure.  A good choice here is the name server which is authoritive for
+the zone above you.
+
+secondary (This line is not in the example, but is worth mentioning.)
+
+A secondary line indicates that you wish to be a secondary name server for
+this domain.  You do not need to do this usually.  All it does is help make
+the DNS more robust.  You should have at least one secondary server for
+your site, but you do not need to be a secondary server for anyone else.
+You can by all means, but you don't need to be.  If you want to be a
+secondary server for another domain, then place the line
+
+secondary         gu.uwa.edu.au   130.95.100.3 130.95.128.1
+
+in your named.boot.  This will make your named try the servers on both of
+the machines specified to see if it can obtain the information about those
+domains.  You can specify a number of IP addresses for the machines to
+query that probably depends on your machine.  Your copy of named will upon
+startup go and query all the information it can get about the domain in
+question and remember it and act as though it were authoritive for that
+domain.
+
+Next you will want to start creating the data files that contain the name
+definitions.
+
+The cache file:
+
+You can get a copy of the cache file from FTP.RS.INTERNIC.NET.  The current
+copy can be found in Appendix A.
+
+The Forward Mapping file:
+The file ecel.uwa.edu.au. will be used for the example with a couple of
+machines left in for the purpose of the exercise.  Here is a copy of what
+the file looks like with explanations following.
+
+; Authoritative data for ecel.uwa.edu.au
+;
+@		IN	SOA decel.ecel.uwa.edu.au. postmaster.ecel.uwa.edu.au. (
+				93071200	; Serial (yymmddxx)
+				10800		; Refresh 3 hours
+				3600		; Retry   1 hour
+				3600000 	; Expire  1000 hours
+				86400 )		; Minimum 24 hours
+		IN	A		130.95.4.2
+		IN	MX	100  	decel
+		IN	MX	150	uniwa.uwa.edu.au.
+		IN	MX	200	relay1.uu.net.
+		IN	MX	200	relay2.uu.net.
+
+localhost	IN	A		127.0.0.1
+
+decel		IN	A		130.95.4.2
+		IN	HINFO	SUN4/110	 UNIX
+		IN	MX	100	decel
+		IN	MX	150	uniwa.uwa.edu.au.
+		IN	MX	200	relay1.uu.net
+		IN	MX	200	relay2.uu.net
+
+gopher		IN	CNAME		decel.ecel.uwa.edu.au.
+
+accfin		IN	A		130.95.4.3
+		IN	HINFO	SUN4/110	 UNIX
+		IN	MX	100	decel
+		IN	MX	150	uniwa.uwa.edu.au.
+		IN	MX	200	relay1.uu.net
+		IN	MX	200	relay2.uu.net
+
+chris-mac	IN	A		130.95.4.5
+		IN	HINFO	MAC-II	MACOS
+
+The comment character is ';' so the first two lines are just comments
+indicating the contents of the file.
+
+All values from here on have IN in them.  This indicates that the value is
+an InterNet record.  There are a couple of other types, but all you need
+concern yourself with is internet ones.
+
+The SOA record is the Start Of Authority record.  It contains the
+information that other nameservers will learn about this domain and how to
+treat the information they are given about it.  The '@' as the first
+character in the line indicates that you wish to define things about the
+domain for which this file is responsible.  The domain name is found in the
+named.boot file in the corresponding line to this filename.  All
+information listed refers to the most recent machine/domain name so all
+records from the '@' until 'localhost' refer to the '@'.  The SOA record
+has 5 magic numbers.  First magic number is the serial number.  If you
+change the file, change the serial number.  If you don't, no other name
+servers will update their information.  The old information will sit around
+for a very long time.
+
+Refresh is the time between refreshing information about the SOA (correct
+me if I am wrong).  Retry is the frequency of retrying if an authorative
+server cannot be contacted.  Expire is how long a secondary name server
+will keep information about a zone without successfully updating it or
+confirming that the data is up to date.  This is to help the information
+withstand fairly lengthy downtimes of machines or connections in the
+network without having to recollect all the information.  Minimum is the
+default time to live value handed out by a nameserver for all records in
+a zone without an explicit TTL value. This is how long the data will live
+after being handed out.  The two pieces of information before the 5 magic
+numbers are the machine that is considered the origin of all of this
+information.  Generally the machine that is running your named is a good
+one for here.  The second is an email address for someone who can fix any
+problems that may occur with the DNS.  Good ones here are postmaster,
+hostmaster or root.  NOTE: You use dots and not '@' for the email address.
+
+eg  root.decel.ecel.uwa.edu.au is correct
+     and
+    root@decel.ecel.uwa.edu.au is incorrect.
+
+We now have an address to map ecel.uwa.edu.au to.  The address is
+130.95.4.2 which happens to be decel, our main machine.  If you try to find
+an IP number for the domain ecel.uwa.edu.au it will get you the machine
+decel.ecel.uwa.edu.au's IP number.  This is a nicety which means that
+people who have non-MX record mailers can still mail fred@ecel.uwa.edu.au
+and don't have to find the name of a machine name under the domain to mail.
+
+Now we have a couple of MX records for the domain itself.  The MX records
+specify where to send mail destined for the machine/domain that the MX
+record is for.  In this case we would prefer if all mail for
+fred@ecel.uwa.edu.au is sent to decel.ecel.uwa.edu.au.  If that does not
+work, we would like it to go to uniwa.uwa.edu.au because there are a number
+of machines that might have no idea how to get to us, but may be able to get
+to uniwa.  And failing that, try the site relay1.uu.net.  A small number
+indicates that this site should be tried first.  The larget the number the
+further down the list of sites to try the site is.  NOTE: Not all machines
+have mailers that pay attention to MX records.  Some only pay attention to
+IP numbers, which is really stupid.  All machines are required to have
+MX-capable Mail Transfer Agents (MTA) as there are many addresses that can
+only be reached via this means.
+
+There is an entry for localhost now.  Note that this is somewhat of a
+kludge and should probably be handled far more elegantly.  By placing
+localhost here, a machine comes into existance called
+localhost.ecel.uwa.edu.au.  If you finger it, or telnet to it, you get your
+own machine, because the name lookup returns 127.0.0.1 which is the special
+case for your own machine.  I have used a couple of different DNS packages.
+The old BSD one let you put things into the cache which would always work,
+but would not be exported to other nameservers.  In the newer Sun one, they
+are left in the cache and are mostly ignored once named is up and running.
+This isn't a bad solution, its just not a good one.
+
+Decel is the main machine in our domain.  It has the IP number 130.95.4.2
+and that is what this next line shows.  It also has a HINFO entry.  HINFO
+is Host Info which is meant to be some sort of an indication of what the
+machine is and what it runs.  The values are two white space seperated
+values.  First being the hardware and second being the software.  HINFO is
+not compulsory, its just nice to have sometimes.  We also have some MX
+records so that mail destined for decel has some other avenues before it
+bounces back to the sender if undeliverable.
+
+It is a good idea to give all machines capable of handling mail an MX
+record because this can be cached on remote machines and will help to
+reduce the load on the network.
+
+gopher.ecel.uwa.edu.au is the gopher server in our division.  Now because
+we are cheapskates and don't want to go and splurge on a seperate machine
+just for handling gopher requests we have made it a CNAME to our main
+machine.  While it may seem pointless it does have one main advantage.
+When we discover that our placing terrabytes of popular quicktime movies
+on our gopher server (no we haven't and we don't intend to) causes an
+unbearable load on our main machine, we can quickly move the CNAME to
+point at a new machine by changing the name mentioned in the CNAME.  Then
+the slime of the world can continue to get their essential movies with a
+minimal interuption to the network.  Other good CNAMEs to maintain are
+things like ftp, mailhost, netfind, archie, whois, and even dns (though the
+most obvious use for this fails).  It also makes it easier for people to
+find these services in your domain.
+
+We should probably start using WKS records for things like gopher and whois
+rather than making DNS names for them.  The tools are not in wide
+circulation for this to work though.  (Plus all those comments in many DNS
+implementation of "Not implemented" next to the WKS record)
+
+Finally we have a macintosh which belongs to my boss.  All it needs is an
+IP number, and we have included the HINFO so that you can see that it is in
+fact a macII running a Mac System.  To get the list of preferred values,
+you should get a copy of RFC 1340.  It lists lots of useful information
+such as /etc/services values, ethernet manufacturer hardware addresses,
+HINFO defualts and many others.  I will include the list as it stands at
+the moment, but if any RFC superceeds 1340, then it will have a more
+complete list.  See Appendix B for that list.
+
+NOTE:  If Chris had a very high profile and wanted his mac to appear like a
+fully connected unix machine as far as internet services were concerned, he
+could simply place an MX record such as 
+
+	IN	MX	100  decel
+
+after his machine and any mail sent to chris@chris-mac.ecel.uwa.edu.au
+would be automatically rerouted to decel.
+
+The Reverse Mapping File
+
+The reverse name lookup is handled in a most bizarre fashion.  Well it all
+makes sense, but it is not immediately obvious.
+
+All of the reverse name lookups are done by finding the PTR record
+associated with the name w.x.y.z.in-addr.arpa.  So to find the name
+associated with the IP number 1.2.3.4, we look for information stored in
+the DNS under the name 4.3.2.1.in-addr.arpa.  They are organised this way
+so that when you are allocated a B class subnet for example, you get all of
+the IP numbers in the domain 130.95.  Now to turn that into a reverse name
+lookup domain, you have to invert the numbers or your registered domains
+will be spread all over the place.  It is a mess and you need not understand
+the finer points of it all.  All you need to know is that you put the
+reverse name lookup files back to front.
+
+Here is the sample reverse name lookup files to go with our example.
+
+0.0.127.in-addr.arpa
+--
+;  Reverse mapping of domain names 0.0.127.in-addr.arpa
+;  Nobody pays attention to this, it is only so 127.0.0.1 -> localhost.
+@		IN	SOA decel.ecel.uwa.edu.au. postmaster.ecel.uwa.edu.au. (
+				91061801	; Serial (yymmddxx)
+				10800		; Refresh 3 hours
+				3600		; Retry   1 hour
+				3600000 	; Expire  1000 hours
+				86400 )		; Minimum 24 hours
+;
+1		IN	PTR	    localhost.ecel.uwa.edu.au.
+--
+
+4.95.130.in-addr.arpa
+--
+;	reverse mapping of domain names 4.95.130.in-addr.arpa
+;
+@		IN	SOA decel.ecel.uwa.edu.au. postmaster.ecel.uwa.edu.au. (
+				92050300	; Serial (yymmddxx format)
+				10800		; Refresh	3hHours
+				3600		; Retry		1 hour
+				3600000		; Expire	1000 hours
+				86400 )		; Minimum	24 hours
+2		IN	PTR	decel.ecel.uwa.edu.au.
+3		IN	PTR	accfin.ecel.uwa.edu.au.
+5		IN	PTR	chris-mac.ecel.uwa.edu.au.
+--
+
+It is important to remember that you must have a second start of authority
+record for the reverse name lookups.  Each reverse name lookup file must
+have its own SOA record.  The reverse name lookup on the 127 domain is
+debatable seeing as there is likely to be only one number in the file and
+it is blatantly obvious what it is going to map to.
+
+The SOA details are the same as in the forward mapping.
+
+Each of the numbers listed down the left hand side indicates that the line
+contains information for that number of the subnet.  Each of the subnets
+must be the more significant digits.  eg the 130.95.4 of an IP number
+130.95.4.2 is implicit for all numbers mentioned in the file.
+
+The PTR must point to a machine that can be found in the DNS.  If the name
+is not in the DNS, some versions of named just bomb out at this point.
+
+Reverse name lookups are not compulsory, but nice to have.  It means that
+when people log into machines, they get names indicating where they are
+logged in from.  It makes it easier for you to spot things that are wrong
+and it is far less cryptic than having lots of numbers everywhere.  Also if
+you do not have a name for your machine, some brain dead protocols such as
+talk will not allow you to connect.
+
+Since I had this I had one suggestion of an alternative way to do the
+localhost entry.  I think it is a matter of personal opinion so I'll
+include it here in case anyone things that this is a more appropriate
+method.
+
+The following is courtesy of jep@convex.nl (JEP de Bie)
+
+  The way I did it was:
+
+  1) add in /etc/named.boot:
+
+     primary   .                             localhost
+     primary   127.in-addr.ARPA.             IP127
+
+(Craig: It has been suggested by Mark Andrews that this is a bad practice
+ particularly if you have upgraded to Bind 4.9.  You also run the risk of
+ polluting the root name servers.  This comes down to a battle of idealogy
+ and practicality.  Think twice before declaring yourself authorative for
+ the root domain.)
+
+  So I not only declare myself (falsely? - probably, but nobody is going to
+  listen anyway most likely [CPR]:-) athorative in the 127.in-addr.ARPA domain
+  but also in the . (root) domain.
+
+  2) the file localhost has:
+
+     $ORIGIN .
+     localhost       IN      A       127.0.0.1
+
+  3) and the file IP127:
+
+     $ORIGIN 127.in-addr.ARPA.
+     1.0.0   IN      PTR     localhost.
+
+  4) and I have in my own domain file (convex.nl) the line:
+
+     $ORIGIN convex.nl.
+     localhost       IN      CNAME   localhost.
+
+  The advantage (elegancy?) is that a query (A) of localhost. gives the
+  reverse of the query of 1.0.0.127.in-addr.ARPA. And it also shows that
+  localhost.convex.nl is only a nickname to something more absolute.
+  (While the notion of localhost is of course relative :-)).
+
+  And I also think there is a subtle difference between the lines
+
+    primary   127.in-addr.ARPA.             IP127
+      and
+    primary   0.0.127.in-addr.ARPA.         4.95.130.domain
+                                        =============
+                                         JEP de Bie
+                                        jep@convex.nl
+                                        =============
+
+
+
+Delegating authority for domains within your domain:
+
+When you start having a very big domain that can be broken into logical and
+seperate entities that can look after their own DNS information, you will
+probably want to do this.  Maintain a central area for the things that
+everyone needs to see and delegate the authority for the other parts of the
+organisation so that they can manage themselves.
+
+Another essential piece of information is that every domain that exists
+must have it NS records associated with it.  These NS records denote the
+name servers that are queried for information about that zone.  For your
+zone to be recognised by the outside world, the server responsible for the
+zone above you must have created a NS record for your machine in your
+domain.  For example, putting the computer club onto the network and giving
+them control over their own part of the domain space we have the following.
+
+The machine authorative for gu.uwa.edu.au is mackerel and the machine
+authorative for ucc.gu.uwa.edu.au is marlin.
+
+in mackerel's data for gu.uwa.edu.au we have the following
+
+@		IN	SOA ...
+		IN	A	130.95.100.3
+		IN	MX	mackerel.gu.uwa.edu.au.
+		IN	MX	uniwa.uwa.edu.au.
+
+marlin		IN	A	130.95.100.4
+
+ucc		IN	NS	marlin.gu.uwa.edu.au.
+		IN	NS	mackerel.gu.uwa.edu.au.
+
+Marlin is also given an IP in our domain as a convenience.  If they blow up
+their name serving there is less that can go wrong because people can still
+see that machine which is a start.  You could place "marlin.ucc" in the
+first column and leave the machine totally inside the ucc domain as well.
+
+The second NS line is because mackerel will be acting as secondary name
+server for the ucc.gu domain.  Do not include this line if you are not
+authorative for the information included in the sub-domain.
+
+
+Troubleshooting your named:
+
+Named doesn't work!  What is wrong?
+
+Step 1:  Run nslookup and see what nameserver it tries to connect you to.
+If nslookup connects you to the wrong nameserver, create a /etc/resolv.conf
+file that points your machine at the correct nameserver.  If there is no
+resolv.conf file, the the resolver uses the nameserver on the local
+machine.
+
+Step 2:  Make sure that named is actually running.
+
+Step 3:  Restart named and see if you get any error messages on the
+console and in also check /usr/adm/messages.
+
+Step 4:  If named is running, nslookup connects to the appropriate
+nameserver and nslookup can answer simple questions, but other programs
+such as 'ping' do not work with names, then you need to install resolv+
+most likely.
+
+
+I changed my named database and my local machine has noticed, but nobody
+else has the new information?
+
+Change the serial number in the SOA for any domains that you modified and
+restart named.  Wait an hour and check again.  The information propogates
+out.  It won't change immediately.
+
+
+My local machine knows about all the name server information, but no other
+sites know about me?
+
+Find an upstream nameserver (one that has an SOA for something in your
+domain) and ask them to be a secondary name server for you.  eg if you are
+ecel.uwa.edu.au, ask someone who has an SOA for the domain uwa.edu.au.
+Get NS records (and glue) added to your parent zone for your zone. This is
+called delegating. It should be done formally like this or you will get
+inconsistant answers out of the DNS.  ALL NAMSERVERS FOR YOUR ZONE SHOULD
+BE LISTED IN THIS MANNER.
+
+
+My forward domain names work, but the backward names do not?
+
+Make sure the numbers are back to front and have the in-addr.arpa on the
+end.
+Make sure you reverse zone is registered. For Class C nets this can be done
+by mailing to hostmaster@internic.net. For class A & B nets make sure that
+you are registeres with the primary for your net and that the net itself
+is registered with hostmaster@internic.net.
+
+
+How to get useful information from nslookup:
+
+Nslookup is a very useful program but I'm sure there are less than 20
+people worldwide who know how to use it to its full usefulness.  I'm most
+certainly not one of them.  If you don't like using nslookup, there is at
+least one other program called dig, that has most/all(?) of the
+functionality of nslookup and is a hell of a lot easier to use.
+
+I won't go into dig much here except to say that it is a lot easier to get
+this information out of.  I won't bother because nslookup ships with almost
+all machines that come with network software.
+
+To run nslookup, you usually just type nslookup.  It will tell you the
+server it connects to.  You can specify a different server if you want.
+This is useful when you want to tell if your named information is
+consistent with other servers.
+
+Getting name to number mappings.
+
+Type the name of the machine.  Typing 'decel' is enough if the machine is
+local.
+
+(Once you have run nslookup successfully)
+> decel
+Server:  ecel.uwa.edu.au
+Address:  130.95.4.2
+
+Name:    decel.ecel.uwa.edu.au
+Address:  130.95.4.2
+
+>
+
+One curious quirk of some name resolvers is that if you type a
+machine name, they will try a number of permutations.  For example if my
+machine is in the domain ecel.uwa.edu.au and I try to find a machine
+called fred, the resolver will try the following.
+
+  fred.ecel.uwa.edu.au.
+  fred.uwa.edu.au.
+  fred.edu.au.
+  fred.au.
+  fred.
+
+This can be useful, but more often than not, you would simply prefer a good
+way to make aliases for machines that are commonly referenced.  If you are
+running resolv+, you should just be able to put common machines into the
+host file.
+
+DIG: dig <machine name>
+
+Getting number to name mappings.
+
+Nslookup defaults to finding you the Address of the name specified.  For
+reverse lookups you already have the address and you want to find the
+name that goes with it.  If you read and understood the bit above where it
+describes how to create the number to name mapping file, you would guess
+that you need to find the PTR record instead of the A record.  So you do
+the following.
+
+> set type=ptr
+> 2.4.95.130.in-addr.arpa
+Server:  decel.ecel.uwa.edu.au
+Address:  130.95.4.2
+
+2.4.95.130.in-addr.arpa host name = decel.ecel.uwa.edu.au
+>
+
+nslookup tells you that the ptr for the machine name
+2.4.95.130.in-addr.arpa points to the host decel.ecel.uwa.edu.au.
+
+DIG: dig -x <machine number>
+
+Finding where mail goes when a machine has no IP number.
+
+When a machine is not IP connected, it needs to specify to the world, where
+to send the mail so that it can dial up and collect it every now and then.
+This is accomplished by setting up an MX record for the site and not giving
+it an IP number.  To get the information out of nslookup as to where the
+mail goes, do the following.
+
+> set type=mx
+> dialix.oz.au
+Server:  decel.ecel.uwa.oz.au
+Address:  130.95.4.2
+
+Non-authoritative answer:
+dialix.oz.au    preference = 100, mail exchanger = uniwa.uwa.OZ.AU
+dialix.oz.au    preference = 200, mail exchanger = munnari.OZ.AU
+Authoritative answers can be found from:
+uniwa.uwa.OZ.AU inet address = 130.95.128.1
+munnari.OZ.AU   inet address = 128.250.1.21
+munnari.OZ.AU   inet address = 192.43.207.1
+mulga.cs.mu.OZ.AU       inet address = 128.250.35.21
+mulga.cs.mu.OZ.AU       inet address = 192.43.207.2
+dmssyd.syd.dms.CSIRO.AU inet address = 130.155.16.1
+ns.UU.NET       inet address = 137.39.1.3
+
+You tell nslookup that you want to search for mx records and then you give
+it the name of the machine.  It tells you the preference for the mail
+(small means more preferable), and who the mail should be sent to.  It also
+includes sites that are authorative (have this name in their named database
+files) for this MX record.  There are multiple sites as a backup.  As can
+be seen, our local public internet access company dialix would like all of
+their mail to be sent to uniwa, where they collect it from.  If uniwa is
+not up, send it to munnari and munnari will get it to uniwa eventually.
+
+NOTE: For historical reasons Australia used to be .oz which was changed to
+.oz.au to move to the ISO standard extensions upon the advent of IP.  We
+are now moving to a more normal heirarchy which is where the .edu.au comes
+from.  Pity, I liked having oz.
+
+DIG: dig <zone> mx
+
+Getting a list of machines in a domain from nslookup.
+
+Find a server that is authorative for the domain or just generally all
+knowing.  To find a good server, find all the soa records for a given
+domain.  To do this, you set type=soa and enter the domain just like in the
+two previous examples.
+
+Once you have a server type 
+
+> ls gu.uwa.edu.au.
+[uniwa.uwa.edu.au]
+Host or domain name            Internet address
+ gu                             server = mackerel.gu.uwa.edu.au
+ gu                             server = uniwa.uwa.edu.au
+ gu                             130.95.100.3
+ snuffle-upagus                 130.95.100.131
+ mullet                         130.95.100.2
+ mackerel                       130.95.100.3
+ marlin                         130.95.100.4
+ gugate                         130.95.100.1
+ gugate                         130.95.100.129
+ helpdesk                       130.95.100.180
+ lan                            130.95.100.0
+ big-bird                       130.95.100.130
+
+To get a list of all the machines in the domain.
+
+If you wanted to find a list of all of the MX records for the domain, you
+can put a -m flag in the ls command.
+
+> ls -m gu.uwa.edu.au.
+[uniwa.uwa.edu.au]
+Host or domain name            Metric Host
+ gu                             100  mackerel.gu.uwa.edu.au
+ gu                             200  uniwa.uwa.edu.au
+
+This only works for a limited selection of the different types.
+
+DIG: dig axfr <zone> @<server>
+
+
+
+Appendix A
+
+
+;
+;       This file holds the information on root name servers needed to
+;       initialize cache of Internet domain name servers
+;       (e.g. reference this file in the "cache  .  <file>"
+;       configuration file of BIND domain name servers).
+;
+;       This file is made available by InterNIC registration services
+;       under anonymous FTP as
+;           file                /domain/named.root
+;           on server           FTP.RS.INTERNIC.NET
+;       -OR- under Gopher at RS.INTERNIC.NET
+;           under menu          InterNIC Registration Services (NSI)
+;              submenu          InterNIC Registration Archives
+;           file                named.root
+;
+;       last update:    April 21, 1993
+;       related version of root zone:   930421
+;
+.                        99999999 IN  NS    NS.INTERNIC.NET.
+NS.INTERNIC.NET.         99999999     A     198.41.0.4
+.                        99999999     NS    KAVA.NISC.SRI.COM.
+KAVA.NISC.SRI.COM.       99999999     A     192.33.33.24
+.                        99999999     NS    C.NYSER.NET.
+C.NYSER.NET.             99999999     A     192.33.4.12
+.                        99999999     NS    TERP.UMD.EDU.
+TERP.UMD.EDU.            99999999     A     128.8.10.90
+.                        99999999     NS    NS.NASA.GOV.
+NS.NASA.GOV.             99999999     A     128.102.16.10
+                         99999999     A     192.52.195.10
+.                        99999999     NS    NS.NIC.DDN.MIL.
+NS.NIC.DDN.MIL.          99999999     A     192.112.36.4
+.                        99999999     NS    AOS.ARL.ARMY.MIL.
+AOS.ARL.ARMY.MIL.        99999999     A     128.63.4.82
+                         99999999     A     192.5.25.82
+.                        99999999     NS    NIC.NORDU.NET.
+NIC.NORDU.NET.           99999999     A     192.36.148.17
+; End of File
+
+
+Appendix B
+
+An Excerpt from
+RFC 1340		    Assigned Numbers		       July 1992
+
+
+			       MACHINE NAMES
+
+   These are the Official Machine Names	as they	appear in the Domain Name
+   System HINFO	records	and the	NIC Host Table.	 Their use is described	in
+   RFC-952 [53].
+
+   A machine name or CPU type may be up	to 40 characters taken from the
+   set of uppercase letters, digits, and the two punctuation characters
+   hyphen and slash.  It must start with a letter, and end with	a letter
+   or digit.
+
+      ALTO				    DEC-1080
+      ALTOS-6800			    DEC-1090
+      AMDAHL-V7				    DEC-1090B
+      APOLLO				    DEC-1090T
+      ATARI-104ST			    DEC-2020T
+      ATT-3B1				    DEC-2040
+      ATT-3B2				    DEC-2040T
+      ATT-3B20				    DEC-2050T
+      ATT-7300				    DEC-2060
+      BBN-C/60				    DEC-2060T
+      BURROUGHS-B/29			    DEC-2065
+      BURROUGHS-B/4800			    DEC-FALCON
+      BUTTERFLY				    DEC-KS10
+      C/30				    DEC-VAX-11730
+      C/70				    DORADO
+      CADLINC				    DPS8/70M
+      CADR				    ELXSI-6400
+      CDC-170				    EVEREX-386
+      CDC-170/750			    FOONLY-F2
+      CDC-173				    FOONLY-F3
+      CELERITY-1200			    FOONLY-F4
+      CLUB-386				    GOULD
+      COMPAQ-386/20			    GOULD-6050
+      COMTEN-3690			    GOULD-6080
+      CP8040				    GOULD-9050
+      CRAY-1				    GOULD-9080
+      CRAY-X/MP				    H-316
+      CRAY-2				    H-60/68
+      CTIWS-117				    H-68
+      DANDELION				    H-68/80
+      DEC-10				    H-89
+      DEC-1050				    HONEYWELL-DPS-6
+      DEC-1077				    HONEYWELL-DPS-8/70
+      HP3000				    ONYX-Z8000
+      HP3000/64				    PDP-11
+      IBM-158				    PDP-11/3
+      IBM-360/67			    PDP-11/23
+      IBM-370/3033			    PDP-11/24
+      IBM-3081				    PDP-11/34
+      IBM-3084QX			    PDP-11/40
+      IBM-3101				    PDP-11/44
+      IBM-4331				    PDP-11/45
+      IBM-4341				    PDP-11/50
+      IBM-4361				    PDP-11/70
+      IBM-4381				    PDP-11/73
+      IBM-4956				    PE-7/32
+      IBM-6152				    PE-3205
+      IBM-PC				    PERQ
+      IBM-PC/AT				    PLEXUS-P/60
+      IBM-PC/RT				    PLI
+      IBM-PC/XT				    PLURIBUS
+      IBM-SERIES/1			    PRIME-2350
+      IMAGEN				    PRIME-2450
+      IMAGEN-8/300			    PRIME-2755
+      IMSAI				    PRIME-9655
+      INTEGRATED-SOLUTIONS		    PRIME-9755
+      INTEGRATED-SOLUTIONS-68K		    PRIME-9955II
+      INTEGRATED-SOLUTIONS-CREATOR	    PRIME-2250
+      INTEGRATED-SOLUTIONS-CREATOR-8	    PRIME-2655
+      INTEL-386				    PRIME-9955
+      INTEL-IPSC			    PRIME-9950
+      IS-1				    PRIME-9650
+      IS-68010				    PRIME-9750
+      LMI				    PRIME-2250
+      LSI-11				    PRIME-750
+      LSI-11/2				    PRIME-850
+      LSI-11/23				    PRIME-550II
+      LSI-11/73				    PYRAMID-90
+      M68000				    PYRAMID-90MX
+      MAC-II				    PYRAMID-90X
+      MASSCOMP				    RIDGE
+      MC500				    RIDGE-32
+      MC68000				    RIDGE-32C
+      MICROPORT				    ROLM-1666
+      MICROVAX				    S1-MKIIA
+      MICROVAX-I			    SMI
+      MV/8000				    SEQUENT-BALANCE-8000
+      NAS3-5				    SIEMENS
+      NCR-COMTEN-3690			    SILICON-GRAPHICS
+      NEXT/N1000-316			    SILICON-GRAPHICS-IRIS
+      NOW				    SGI-IRIS-2400
+      SGI-IRIS-2500			    SUN-3/50
+      SGI-IRIS-3010			    SUN-3/60
+      SGI-IRIS-3020			    SUN-3/75
+      SGI-IRIS-3030			    SUN-3/80
+      SGI-IRIS-3110			    SUN-3/110
+      SGI-IRIS-3115			    SUN-3/140
+      SGI-IRIS-3120			    SUN-3/150
+      SGI-IRIS-3130			    SUN-3/160
+      SGI-IRIS-4D/20			    SUN-3/180
+      SGI-IRIS-4D/20G			    SUN-3/200
+      SGI-IRIS-4D/25			    SUN-3/260
+      SGI-IRIS-4D/25G			    SUN-3/280
+      SGI-IRIS-4D/25S			    SUN-3/470
+      SGI-IRIS-4D/50			    SUN-3/480
+      SGI-IRIS-4D/50G			    SUN-4/60
+      SGI-IRIS-4D/50GT			    SUN-4/110
+      SGI-IRIS-4D/60			    SUN-4/150
+      SGI-IRIS-4D/60G			    SUN-4/200
+      SGI-IRIS-4D/60T			    SUN-4/260
+      SGI-IRIS-4D/60GT			    SUN-4/280
+      SGI-IRIS-4D/70			    SUN-4/330
+      SGI-IRIS-4D/70G			    SUN-4/370
+      SGI-IRIS-4D/70GT			    SUN-4/390
+      SGI-IRIS-4D/80GT			    SUN-50
+      SGI-IRIS-4D/80S			    SUN-100
+      SGI-IRIS-4D/120GTX		    SUN-120
+      SGI-IRIS-4D/120S			    SUN-130
+      SGI-IRIS-4D/210GTX		    SUN-150
+      SGI-IRIS-4D/210S			    SUN-170
+      SGI-IRIS-4D/220GTX		    SUN-386i/250
+      SGI-IRIS-4D/220S			    SUN-68000
+      SGI-IRIS-4D/240GTX		    SYMBOLICS-3600
+      SGI-IRIS-4D/240S			    SYMBOLICS-3670
+      SGI-IRIS-4D/280GTX		    SYMMETRIC-375
+      SGI-IRIS-4D/280S			    SYMULT
+      SGI-IRIS-CS/12			    TANDEM-TXP
+      SGI-IRIS-4SERVER-8		    TANDY-6000
+      SPERRY-DCP/10			    TEK-6130
+      SUN				    TI-EXPLORER
+      SUN-2				    TP-4000
+      SUN-2/50				    TRS-80
+      SUN-2/100				    UNIVAC-1100
+      SUN-2/120				    UNIVAC-1100/60
+      SUN-2/130				    UNIVAC-1100/62
+      SUN-2/140				    UNIVAC-1100/63
+      SUN-2/150				    UNIVAC-1100/64
+      SUN-2/160				    UNIVAC-1100/70
+      SUN-2/170				    UNIVAC-1160
+      UNKNOWN
+      VAX-11/725
+      VAX-11/730
+      VAX-11/750
+      VAX-11/780
+      VAX-11/785
+      VAX-11/790
+      VAX-11/8600
+      VAX-8600
+      WANG-PC002
+      WANG-VS100
+      WANG-VS400
+      WYSE-386
+      XEROX-1108
+      XEROX-8010
+      ZENITH-148
+
+			       SYSTEM NAMES
+
+   These are the Official System Names as they appear in the Domain Name
+   System HINFO	records	and the	NIC Host Table.	 Their use is described
+   in RFC-952 [53].
+
+   A system name may be	up to 40 characters taken from the set of upper-
+   case	letters, digits, and the three punctuation characters hyphen,
+   period, and slash.  It must start with a letter, and	end with a
+   letter or digit.
+
+   AEGIS		     LISP		       SUN OS 3.5
+   APOLLO		     LISPM		       SUN OS 4.0
+   AIX/370		     LOCUS		       SWIFT
+   AIX-PS/2		     MACOS		       TAC
+   BS-2000		     MINOS		       TANDEM
+   CEDAR		     MOS		       TENEX
+   CGW			     MPE5		       TOPS10
+   CHORUS		     MSDOS		       TOPS20
+   CHRYSALIS		     MULTICS		       TOS
+   CMOS			     MUSIC		       TP3010
+   CMS			     MUSIC/SP		       TRSDOS
+   COS			     MVS		       ULTRIX
+   CPIX			     MVS/SP		       UNIX
+   CTOS			     NEXUS		       UNIX-BSD
+   CTSS			     NMS		       UNIX-V1AT
+   DCN			     NONSTOP		       UNIX-V
+   DDNOS		     NOS-2		       UNIX-V.1
+   DOMAIN		     NTOS		       UNIX-V.2
+   DOS			     OS/DDP		       UNIX-V.3
+   EDX			     OS/2		       UNIX-PC
+   ELF			     OS4		       UNKNOWN
+   EMBOS		     OS86		       UT2D
+   EMMOS		     OSX		       V
+   EPOS			     PCDOS		       VM
+   FOONEX		     PERQ/OS		       VM/370
+   FUZZ			     PLI		       VM/CMS
+   GCOS			     PSDOS/MIT		       VM/SP
+   GPOS			     PRIMOS		       VMS
+   HDOS			     RMX/RDOS		       VMS/EUNICE
+   IMAGEN		     ROS		       VRTX
+   INTERCOM		     RSX11M		       WAITS
+   IMPRESS		     RTE-A		       WANG
+   INTERLISP		     SATOPS		       WIN32
+   IOS			     SCO-XENIX/386	       X11R3
+   IRIX			     SCS		       XDE
+   ISI-68020		     SIMP		       XENIX
+   ITS			     SUN
+
+
+
+Appendix C     Installing DNS on a Sun when running NIS
+
+====================
+ 2)     How to get DNS to be used when running NIS ?
+
+        First setup the appropriate /etc/resolv.conf file.
+        Something like this should do the "trick".
+
+        ;
+        ; Data file for a client.
+        ;
+        domain          local domain
+        nameserver      address of primary domain nameserver
+        nameserver      address of secondary domain nameserver
+
+        where:  "local domain" is the domain part of the hostnames.
+                 For example, if your hostname is "thor.ece.uc.edu"
+                 your "local domain" is "ece.uc.edu".
+
+        You will need to put a copy of this resolv.conf on
+        all NIS(YP) servers including slaves.
+
+        Under SunOS 4.1 and greater, change the "B=" at the top
+        of the /var/yp/Makefile to "B=-b" and setup NIS in the
+        usual fashion.
+
+        You will need reboot or restart ypserv for these changes
+        to take affect.
+
+        Under 4.0.x, edit the Makefile or apply the following "diff":
+
+*** Makefile.orig       Wed Jan 10 13:22:11 1990
+--- Makefile    Wed Jan 10 13:22:01 1990
+***************
+*** 63 ****
+!                   | $(MAKEDBM) - $(YPDBDIR)/$(DOM)/hosts.byname; \
+--- 63 ----
+!                   | $(MAKEDBM) -b - $(YPDBDIR)/$(DOM)/hosts.byname; \
+***************
+*** 66 ****
+!                   | $(MAKEDBM) - $(YPDBDIR)/$(DOM)/hosts.byaddr; \
+--- 66 ----
+!                   | $(MAKEDBM) -b - $(YPDBDIR)/$(DOM)/hosts.byaddr; \
+====================
+
diff --git a/contrib/bind/doc/misc/style.txt b/contrib/bind/doc/misc/style.txt
new file mode 100644
index 0000000..a966066
--- /dev/null
+++ b/contrib/bind/doc/misc/style.txt
@@ -0,0 +1,172 @@
+Path: vixie!vixie
+From: vixie@vix.com (Paul A Vixie)
+Newsgroups: comp.protocols.tcp-ip.domains
+Subject: Re: Format of DNS files (style question)
+Date: 28 Aug 94 03:17:08
+Organization: Vixie Enterprises
+Lines: 159
+Distribution: inet
+Message-ID: <VIXIE.94Aug28031708@office.home.vix.com>
+References: <33onnr$i4u@zombie.ncsc.mil>
+NNTP-Posting-Host: office.home.vix.com
+In-reply-to: sjr@zombie.ncsc.mil's message of 27 Aug 1994 21:02:51 -0400
+
+> (Style) Suggestions for how to layout DNS configuration files (both
+> forward and reverse)?
+
+I've gone back and forth on the question of whether the BOG should include a
+section on this topic.  I know what I myself prefer, but I'm wary of ramming
+my own stylistic preferences down the throat of every BOG reader.  But since
+you ask :-)...
+
+Create /var/named.  If your system is too old to have a /var, either create
+one or use /usr/local/adm/named instead.  Put your named.boot in it, and make
+/etc/named.boot a symlink to it.  If your system doesn't have symlinks, you're
+S-O-L (but you knew that).  In named.boot, put a "directory" directive that
+specifies your actual BIND working directory:
+
+	directory	/var/named
+
+All relative pathnames used in "primary", "secondary", and "cache" directives
+will be evaluated relative to this directory.  Create two subdirectories,
+/var/named/pri and /var/named/sec.  Whenever you add a "primary" directive
+to your named.boot, use "pri/WHATEVER" as the path name.  And then put the
+primary zone file into "pri/WHATEVER".  Likewise when you add "secondary"
+directives, use "sec/WHATEVER" and BIND (really named-xfer) will create the
+files in that subdirectory.
+
+(Variations: (1) make a midlevel directory "zones" and put "pri" and "sec"
+into it; (2) if you tend to pick up a lot of secondaries from a few hosts,
+group them together in their own subdirectories -- something like
+/var/named/zones/uucp if you're a UUCP Project name server.)
+
+For your forward files, name them after the zone.  dec.com becomes
+"/var/named/zones/pri/dec.com".  For your reverse files, name them after the
+network number.  0.1.16.in-addr.arpa becomes "/var/named/zones/pri/16.1.0".
+
+When creating or maintaining primary zone files, try to use the same SOA
+values everywhere, except for the serial number which varies per zone.  Put
+a $ORIGIN directive at the top of the primary zone file, not because it's
+needed (it's not since the default origin is the zone named in the "primary"
+directive) but because it make it easier to remember what you're working on
+when you have a lot of primary zones.  Put some comments up there indicating
+contact information for the real owner if you're proxying.  Use RCS and put
+the "$Id: style.txt,v 8.1 1995/12/22 21:59:52 vixie Exp $" in a ";" comment near the top of the zone file.
+
+The SOA and other top level information should all be listed together.  But
+don't put IN on every line, it defaults nicely.  For example:
+
+==============
+@	IN	SOA	gw.home.vix.com. postmaster.vix.com. (
+			1994082501      ; serial
+                        3600    ; refresh (1 hour)
+                        1800    ; retry (30 mins)
+                        604800  ; expire (7 days)
+                        3600 )  ; minimum (1 hour)
+
+		NS	gw.home.vix.com.
+		NS	ns.uu.net.
+		NS	uucp-gw-1.pa.dec.com.
+		NS	uucp-gw-2.pa.dec.com.
+
+		MX	10 gw.home.vix.com.
+		MX	20 uucp-gw-1.pa.dec.com.
+		MX	20 uucp-gw-1.pa.dec.com.
+==============
+
+I don't necessarily recommend those SOA values.  Not every zone is as volatile
+as the example shown.  I do recommend that serial number format; it's in date
+format with a 2-digit per-day revision number.  This format will last us until
+2147 A.D. at which point I expect a better solution will have been found :-).
+(Note that it would last until 4294 A.D. except that there are some old BINDs
+out there that use a signed quantity for representing serial number interally;
+I suppose that as long as none of these are still running after 2047 A.D.,
+that we can use the above serial number format until 4294 A.D., at which point
+a better solution will HAVE to be found.)
+
+You'll note that I use a tab stop for "IN" even though I never again specify
+it.  This leaves room for names longer than 7 bytes without messing up the
+columns.  You might also note that I've put the MX priority and destination
+in the same tab stop; this is because both are part of the RRdata and both 
+are very different from MX which is an RRtype.  Some folks seem to prefer to
+group "MX" and the priority together in one tab stop.  While this looks neat
+it's very confusing to newcomers and for them it violates the law of least
+astonishment.
+
+If you have a multi-level zone (one which contains names that have dots in
+them), you can use additional $ORIGIN statements but I recommend against it
+since there is no "back" operator.  That is, given the above example you can
+add:
+
+=============
+$ORIGIN home
+gw		A	192.5.5.1
+=============
+
+The problem with this is that subsequent RR's had better be somewhere under
+the "home.vix.com" name or else the $ORIGIN that introduces them will have
+to use a fully qualified name.  FQDN $ORIGIN's aren't bad and I won't be mad
+if you use them.  Unqualified ones as shown above are real trouble.  I usually
+stay away from them and just put the whole name in:
+
+=============
+gw.home		A	192.5.5.1
+=============
+
+In your reverse zones, you're usually in some good luck because the owner name
+is usually a single short token or sometimes two.
+
+=============
+$ORIGIN 5.5.192.in-addr.arpa.
+@	IN	SOA	...
+		NS	...
+1		PTR	gw.home.vix.com.
+-------------
+$ORIGIN 1.16.in-addr.arpa.
+@	IN	SOA	...
+		NS	...
+2.0		PTR	gatekeeper.dec.com.
+=============
+
+It is usually pretty hard to keep your forward and reverse zones in synch.
+You can avoid that whole problem by just using "h2n" (see the ORA book, DNS
+and BIND, and its sample toolkit, included in the BIND distribution or on
+ftp.uu.net (use the QUOTE SITE EXEC INDEX command there to find this -- I
+never can remember where it's at).  "h2n" and many tools like it can just
+read your old /etc/hosts file and churn it into DNS zone files.  (May I
+recommend contrib/decwrl/mkdb.pl from the BIND distribution?)  However, if
+you (like me) prefer to edit these things by hand, you need to follow the
+simple convention of making all of your holes consistent.  If you use
+192.5.5.1 and 192.5.5.3 but not (yet) 192.5.5.2, then in your forward file
+you will have something like
+
+=============
+...
+gw.home		A	192.5.5.1
+;avail		A	192.5.5.2
+pc.home		A	192.5.5.3
+=============
+
+and in your reverse file you will have something like
+
+=============
+...
+1		PTR	gw.home.vix.com.
+;2		PTR	avail
+3		PTR	pc.home.vix.com.
+=============
+
+This convention will allow you to keep your sanity and make fewer errors.
+Any kind of automation (h2n, mkdb, or your own perl/tcl/awk/python tools)
+will help you maintain a consistent universe even if it's also a complex
+one.  Editing by hand doesn't have to be deadly but you MUST take care.
+
+Anyone who wants to know how to maintain nonleaf zones, i.e., zones which
+have few or no hosts in them but have hundreds or thousands of delegations,
+should attend Usenix LISA in San Diego and be there for the SENDS talk.
+Contact office@usenix.org for conference information.
+--
+Paul Vixie
+Redwood City, CA
+decwrl!vixie!paul
+<paul@vix.com>