summaryrefslogtreecommitdiffstats
path: root/contrib
diff options
context:
space:
mode:
authordougb <dougb@FreeBSD.org>2002-07-01 01:28:00 +0000
committerdougb <dougb@FreeBSD.org>2002-07-01 01:28:00 +0000
commite682905748075e8e39a00f2badcb6def78314225 (patch)
treea9074d39e7eec8454358bdbabc63ab01ff152425 /contrib
parentfaf2eb4d9a089275aac17bc1af712b5958ec0a46 (diff)
downloadFreeBSD-src-e682905748075e8e39a00f2badcb6def78314225.zip
FreeBSD-src-e682905748075e8e39a00f2badcb6def78314225.tar.gz
This commit was generated by cvs2svn to compensate for changes in r99191,
which included commits to RCS files with non-trunk default branches.
Diffstat (limited to 'contrib')
-rw-r--r--contrib/bind/doc/bog/00macs.me51
-rw-r--r--contrib/bind/doc/bog/00title.me89
-rw-r--r--contrib/bind/doc/bog/Makefile89
-rw-r--r--contrib/bind/doc/bog/ack.me283
-rw-r--r--contrib/bind/doc/bog/build.me102
-rw-r--r--contrib/bind/doc/bog/files.me1150
-rw-r--r--contrib/bind/doc/bog/intro.me75
-rw-r--r--contrib/bind/doc/bog/manage.me156
-rw-r--r--contrib/bind/doc/bog/named.boot.cache77
-rw-r--r--contrib/bind/doc/bog/named.boot.primary78
-rw-r--r--contrib/bind/doc/bog/named.boot.secondary77
-rw-r--r--contrib/bind/doc/bog/named.local75
-rw-r--r--contrib/bind/doc/bog/ns.me96
-rw-r--r--contrib/bind/doc/bog/resolv.conf67
-rw-r--r--contrib/bind/doc/bog/root.cache102
-rw-r--r--contrib/bind/doc/bog/setup.me88
-rw-r--r--contrib/bind/doc/bog/types.me163
-rw-r--r--contrib/bind/doc/bog/ucbhosts118
-rw-r--r--contrib/bind/doc/bog/ucbhosts.rev86
-rw-r--r--contrib/bind/doc/notes/data51
-rw-r--r--contrib/bind/doc/notes/db_names.c184
-rw-r--r--contrib/bind/doc/notes/irp.txt521
22 files changed, 0 insertions, 3778 deletions
diff --git a/contrib/bind/doc/bog/00macs.me b/contrib/bind/doc/bog/00macs.me
deleted file mode 100644
index 8ce02a2..0000000
--- a/contrib/bind/doc/bog/00macs.me
+++ /dev/null
@@ -1,51 +0,0 @@
-.\" 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
deleted file mode 100644
index 5048969..0000000
--- a/contrib/bind/doc/bog/00title.me
+++ /dev/null
@@ -1,89 +0,0 @@
-.\" 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.
-.+c
-.(l C
-.sz 14
-.b "Name Server Operations Guide"
-.b "for \s-1BIND\s+1"
-.sz
-\fIRelease 4.9.3\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
deleted file mode 100644
index 09e1908..0000000
--- a/contrib/bind/doc/bog/Makefile
+++ /dev/null
@@ -1,89 +0,0 @@
-# ++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
-
-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
deleted file mode 100644
index c9d7d85..0000000
--- a/contrib/bind/doc/bog/ack.me
+++ /dev/null
@@ -1,283 +0,0 @@
-.\" 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.
-.\"
-.\" @(#)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
deleted file mode 100644
index d6dab9f..0000000
--- a/contrib/bind/doc/bog/build.me
+++ /dev/null
@@ -1,102 +0,0 @@
-.\" ++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
deleted file mode 100644
index ae755ff..0000000
--- a/contrib/bind/doc/bog/files.me
+++ /dev/null
@@ -1,1150 +0,0 @@
-.\" ++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
-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 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
deleted file mode 100644
index 597fa44..0000000
--- a/contrib/bind/doc/bog/intro.me
+++ /dev/null
@@ -1,75 +0,0 @@
-.\" ++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
deleted file mode 100644
index 6f17b80..0000000
--- a/contrib/bind/doc/bog/manage.me
+++ /dev/null
@@ -1,156 +0,0 @@
-.\" ++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
deleted file mode 100644
index 5e0e3d3..0000000
--- a/contrib/bind/doc/bog/named.boot.cache
+++ /dev/null
@@ -1,77 +0,0 @@
-.\" ++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
deleted file mode 100644
index 0f3c3ca..0000000
--- a/contrib/bind/doc/bog/named.boot.primary
+++ /dev/null
@@ -1,78 +0,0 @@
-.\" ++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
deleted file mode 100644
index 64a607d..0000000
--- a/contrib/bind/doc/bog/named.boot.secondary
+++ /dev/null
@@ -1,77 +0,0 @@
-.\" ++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
deleted file mode 100644
index 209c5be..0000000
--- a/contrib/bind/doc/bog/named.local
+++ /dev/null
@@ -1,75 +0,0 @@
-.\" ++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
deleted file mode 100644
index ec3ca3c..0000000
--- a/contrib/bind/doc/bog/ns.me
+++ /dev/null
@@ -1,96 +0,0 @@
-.\" ++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
deleted file mode 100644
index 1f15991..0000000
--- a/contrib/bind/doc/bog/resolv.conf
+++ /dev/null
@@ -1,67 +0,0 @@
-.\" ++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
deleted file mode 100644
index 3bf5727..0000000
--- a/contrib/bind/doc/bog/root.cache
+++ /dev/null
@@ -1,102 +0,0 @@
-.\" ++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
deleted file mode 100644
index fff7657..0000000
--- a/contrib/bind/doc/bog/setup.me
+++ /dev/null
@@ -1,88 +0,0 @@
-.\" ++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
deleted file mode 100644
index 9d14111..0000000
--- a/contrib/bind/doc/bog/types.me
+++ /dev/null
@@ -1,163 +0,0 @@
-.\" ++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
deleted file mode 100644
index 2cb2635..0000000
--- a/contrib/bind/doc/bog/ucbhosts
+++ /dev/null
@@ -1,118 +0,0 @@
-.\" ++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
deleted file mode 100644
index 16207af..0000000
--- a/contrib/bind/doc/bog/ucbhosts.rev
+++ /dev/null
@@ -1,86 +0,0 @@
-.\" ++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/notes/data b/contrib/bind/doc/notes/data
deleted file mode 100644
index e522392..0000000
--- a/contrib/bind/doc/notes/data
+++ /dev/null
@@ -1,51 +0,0 @@
-/*
- * We need a registy of name server addresses. For each, we retain an RTT
- * and a list of name server names which have used this address.
- */
-tree_t *by_nsaddr;
-struct by_nsaddr {
- u_int32_t rtt; /* measured. */
- char **names; /* NULL terminated array; strdup'd. */
-};
-
-/*
- * "struct server" is a name server, which can have many addresses. There
- * is no central registry of servers, since each creator can have a different
- * idea of what the addresses are.
- */
-struct server {
- char *name; /* made with strdup. */
- struct sockaddr_in *addrs; /* counted array. */
- int n_addrs; /* array size. */
-};
-
-/*
- * "struct zone" is a zone cut.
- */
-tree_t *by_class; /* zone[class]. */
-struct zone {
- enum {master, slave, cache, boot}
- type;
-
- /* Servers learned from boot cache, a parent zone, or !auth answer. */
- struct server *servers_notauth;
-
- /* Servers learned from authoritative answer or local zone. */
- struct server *servers_auth;
-
- /* Root node of zone. */
- struct node *root;
-};
-
-struct node {
- char *label; /* made with strdup. */
- tree_t *subs; /* subdomains (node[label]). */
- /* really this is "data" since for the zone cut tree we have no sets.*/
- tree_t *rrsets; /* rr sets (rrset[type]). */
-};
-
-struct rrset {
- rrtype type;
- u_int32_t ttl;
- u_char data[1]; /* struct size constrains this. */
-};
diff --git a/contrib/bind/doc/notes/db_names.c b/contrib/bind/doc/notes/db_names.c
deleted file mode 100644
index 0b4e62c..0000000
--- a/contrib/bind/doc/notes/db_names.c
+++ /dev/null
@@ -1,184 +0,0 @@
-/*
- * Copyright (c) 1996,1999 by Internet Software Consortium.
- *
- * 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.
- *
- * THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM DISCLAIMS
- * ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES
- * OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL INTERNET SOFTWARE
- * CONSORTIUM 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.
- */
-
-#include <sys/types.h>
-#include <sys/param.h>
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-
-#include <ctype.h>
-#include <errno.h>
-#include <resolv.h>
-#include <stdio.h>
-
-#include "named.h"
-#include "tree.h"
-
-struct node {
- struct node *parent; /* NULL for "."'s node. */
- tree *children; /* Nodes using us as parent. */
- /*void *userdata;*/ /* For future use. */
- char name[sizeof(void*)]; /* Open array. */
-};
-
-static struct node rootNode;
-
-static int
-nodeCompare(t1, t2)
- const tree_t t1, t2;
-{
- const char *n1 = ((struct node *)t1)->name + sizeof(u_char),
- *n2 = ((struct node *)t2)->name + sizeof(u_char);
-
- return (strcasecmp(n1, n2));
-}
-
-/* void *
- * db_findname(const char *name, int storeflag)
- * find or store a presentation format domain name.
- * returns:
- * NULL if an error occurred (check errno)
- * else, node's unique, opaque address.
- */
-void *
-db_findname(name, storeflag)
- const char *name;
- int storeflag;
-{
- struct node *node, *tnode;
- const char *tname;
- size_t len;
- int ch;
-
- /* The root domain has its own static node. */
- if (name[0] == '\0')
- return (&rootNode);
-
- /* Locate the end of the first label. */
- for (tname = name; (ch = *tname) != '\0'; tname++) {
- /* Is this the end of the first label? */
- if (ch == '.')
- break;
- /* Is it an escaped character? */
- if (ch == '\\') {
- ch = *++tname;
- if (ch == '\0')
- break;
- }
- }
-
- /* Make sure the label's length will fit in our length byte. */
- len = tname - name;
- if (len > 255) {
- errno = ENAMETOOLONG;
- return (NULL);
- }
-
- /* If nothing but unescaped dots after this, elide them. */
- while (ch == '.')
- ch = *tname++;
-
- /*
- * Make a new node since the comparison function needs it
- * and we may yet end up adding it to our parent's tree.
- *
- * Note that by recursing for tnode->parent, we might be
- * creating our parents and grandparents and so on.
- */
- tnode = (struct node *)malloc(sizeof(struct node) - sizeof(void *)
- + sizeof(u_char) + len + sizeof(char));
- tnode->parent = db_findname(tname);
- tnode->children = NULL;
- *((u_char *)tnode->name) = (u_char)len;
- memcpy(tnode->name + sizeof(u_char), name, len);
- tnode->name[sizeof(u_char) + len] = '\0';
-
- /* If our first label isn't in our parent's tree, put it there. */
- node = tree_srch(&tnode->parent->children, nodeCompare, (tree_t)tnode);
- if (node == NULL)
- if (storeflag)
- if (tree_add(&tnode->parent->children, nodeCompare,
- (tree_t)tnode, NULL))
- node = tnode, tnode = NULL;
- else
- errno = ENOMEM;
- else
- errno = ENOENT;
-
- /* Get rid of tnode if we didn't consume it. */
- if (tnode != NULL)
- free(tnode);
-
- /* Return the (possibly new) node, or NULL, as appropriate. */
- return (node);
-}
-
-/* int
- * db_getname(void *node, char *name, size_t size)
- * given a node's unique, opaque address, format its name.
- * returns:
- * -1 = error occurred, check errno
- * 0 = success
- */
-int
-db_getname(vnode, name, size)
- const void *vnode;
- char *name;
- size_t size;
-{
- const struct node *node = vnode;
-
- while (node != NULL) {
- size_t len = (size_t)node->name[0];
-
- if (size < len + 1)
- goto too_long;
- memcpy(name, node->name + sizeof(u_char), len);
- name += len;
- *name++ = '.';
- size -= len + sizeof(char);
- node = node->parent;
- }
-
- if (size < sizeof(char)) {
- too_long:
- errno = ENAMETOOLONG;
- return (-1);
- }
- *name = '\0';
- return (0);
-}
-
-/*
- * char *
- * db_makename(void *node)
- * given a node's unique, opaque address, format and return its name.
- * returns:
- * pointer to the name or NULL on errors (check errno).
- * notes:
- * returns pointer to a static buffer, be careful how you call it.
- */
-char *
-db_makename(vnode)
- void *vnode;
-{
- static char name[MAXDNAME*2];
-
- if (db_getname(vnode, name, sizeof name) < 0)
- return (NULL);
- return (name);
-}
diff --git a/contrib/bind/doc/notes/irp.txt b/contrib/bind/doc/notes/irp.txt
deleted file mode 100644
index f2b59e2..0000000
--- a/contrib/bind/doc/notes/irp.txt
+++ /dev/null
@@ -1,521 +0,0 @@
-IRP Commands
-
-This document describes version 1 of IRP.
-
-IRP is a text-based command/response protocol like NNTP or SMTP.
-
-1.0 Response types: textual and status.
-
-1.1 Textual responses
-
-Textual responses are sent after a status response which indicates the text
-will follow. The text is a series of CR-LF terminated lines. On the last line a
-single period ``.'' will appear. If a normal text line starts with a period
-then this will be doubled before sending.
-
-There is no maximum line length for responses. Commands have a maximum line
-length of 1024 characters.
-
-The lines that make up the transmitted data are divided into fields. The fields
-are spearated by the colon character ``:'', except in one case (for host data)
-where the at-sign ``@'' is used instead. Some fields, such as alias names for
-hosts, can have multiple values, and these values are separated by commas.
-
-Most transmission of data requires no special character changes. The field
-separators and subfield separators don't normally appear in the data. However
-in one case they can (network names). So to avoid trouble, all ``special''
-characters found in any data fields are encoded in URL-encoding form. That is
-they are replaced with the 3-character sequence ``%xx'', where xx is the
-hexidecimal value of the ascii-code for the chatacter. i,e, ``:'' becomes
-``%58'', ``,'' becomes ``%44'' and ``%'' becomes ``%37''.
-
-For version 1 of IRP the set of special characters for purposes of encoding,
-is:
-
- `,', '%', ':', '@'
-
-In a couple cases (password structure and group structure), there may be
-encrypted passwords as part of the data. If the client is a privileged user
-that the server can verify (e.g. through the use of SunOS doors(2)), then the
-encrypted password will be sent back to the client. If the client is not
-privileged the password will be replaced with the string ``*''.
-
-
-1.2 Status responses.
-
-Status responses follow a numbering pattern similar to NNTP.
-
- 1xx - Informative message
- 2xx - Command ok
- 3xx - Command ok so far, send the rest of it.
- 4xx - Command was correct, but couldn't be performed for
- some reason.
- 5xx - Command unimplemented, or incorrect, or a serious
- program error occurred.
-
- The next digit in the code indicates the function response category.
-
- x0x - Connection, setup, and miscellaneous messages
- x1x - Host lookup
- x2x - Network lookup
- x3x - User lookup
- x4x - Group lookup
- x5x - Service lookup
- x6x - Protocol lookup
- x7x - Netgroup lookup
- x8x - Misc. Information Lookup
- x9x - Debugging output
-
- The final digit in the code indicates whether textual data follows
-
- xx0 - No textual data follows.
- xx1 - Textual data follows.
-
-2.0 Connection Establishment
-
- When the client connects to the server, the server will issue a welcome
- banner. If the server will accetp commands, then the banner will start with
- a status code indicating this, followed by a version number of the protocol
- it accepts. Other words may come on the line afterwards to indicate to
- humans the state of the server,
-
- If the server wont accept commands then it will issue a banner indicating
- that and will then drop the connection.
-
-2.1 Responses
-
- 200 1 Ready to go. ; note: The server handles version 1 of the protocol
- 200 2 Ready ; note: The server handles version 2 of the protocol
- 400 Sorry. Down to due to nightly backups.
-
-3.0 Commands
-
-3.1 The HOST commands
-
-3.1.1 GETHOSTBYNAME hostname
-3.1.2 GETHOSTBYNAME2 hostname address-family
-3.1.2 GETHOSTBYADDR address address-family
-3.1.3 GETHOSTENT
-
- Returns a textual response containing the information for the given host(s)
- (a struct hostent) encoded in an ascii format. gethostbyaddr and
- gethostbyname look up a specific host. GETHOSTENT returns the contents
- of the /etc/hosts file. The GETHOSTENT command is optional may not be
- supported by the server. The address-family paramater is the value
- "AF_INET" or "AF_INET6"
-
-{ XXX GETHOSTENT is optional as the gethostent(3) call isn't always available }
-
-3.1.4 Responses
-
- 210 No such host
- 211 Host found
-
- If the hostname given as the command argument doesn't exist, then the 210
- response will be returned. If the host is successfully looked up, then the
- 211 response is sent and a textual message is sent after. The textual
- message contains the host information encoded in an ascii form. The fields
- of the host data are separated by at-signs. Fields that have multiple values
- (like the aliases field) have their sub values separated by commas.
-
- hostname@aliases@address-type@address-length@address-list@
-
- - hostname is the FQDN of the host.
-
- - aliases is a comma separated list of FQDNs for the host aliases.
-
- - address-type is either the strings "AF_INET" or "AF_INET6"
-
- - address-length is the length of each address in bytes (after conversion
- back to binary form).
-
- - address-list is a comma separated list of dotted IPv4 if IPv6 addresses.
-
-{ XXX if we're going to include TTLs where should they go? Perhaps the
-address-list field should be "addr/ttl,addr/ttl,..." }
-
- For example:
-
- C: GETHOSTBYNAME gw.downtown.vix.com
-
- S: 210 No such host.
-
- C: GETHOSTBYNAME gw.home.vix.com
-
- S: 211 OK
- gw.home.vix.com@ftp.vix.com,www.vix.com@AF_INET@4@192.5.5.1,192.5.5.1@
- .
-
- C: GETHOSTBYNAME2 gw.home.vix.com AF_INET6
- gw.home.vix.com@@AF_INET6@ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255@
- .
-
- C: GETHOSTBYADDR 192.5.5.1
-
- S: 211 OK
- gw.home.vix.com@ftp.vix.com,www.vix.com@AF_INET@4@192.5.5.1,192.5.5.1@
- .
-
- C: GETHOSTENT
-
- S: 211 OK
- gw.home.vix.com@ftp.vix.com,www.vix.com@AF_INET@4@192.5.5.1,192.5.5.1@
- data.pa.vix.com@@AF_INET@4@204.152.184.37@
- .
-
-
-3.2 The USER commands.
-
-3.2.1 GETPWNAM username
-3.2.2 GETPWUID uid
-3.2.3 GETPWENT
-
- Returns a textual response with the user information (a struct passwd)
- enocoded in an ascii format. The optional GETPWENT command transmits the
- entire /etc/password file
-
-{ XXX It's optional only cause it doesn't seem right to spit the password out
-to whoever wants it, even with encrypted passwords not being sent }
-
-3.2.4 Reponses
-
- 230 No such user
- 231 User found
-
- If the username or uid given as the command argument doesn't exist, then
- the 230 response will be returned. If the user is successfully looked up,
- then the 231 response is sent and a textual message is sent after. The
- textual message contains the user information encoded in an ascii form. The
- fields of the user data are separated by colons. The format is very similar
- to the /etc/password format (see passwd(5))
-
- username:password:uid:gid:class:change:expire:gecos:home_dir:shell:
-
- - username is the user's login name
-
- - password User's encrypted password (or the string "*" if the client is
- unprivileged)
-
- - uid User's numeric id.
-
- - gid User's numeric login group id.
-
- - class User's general classification (a string)
-
- - change Password change time (integer seconds from epoch)
-
- - expire Account expiration time (integer seconds from epoch)
-
- - gecos General information about the user.
-
- - home_dir User's home directory.
-
- - shell User's login shell.
-
- For example. Client being a non-privileged user:
-
- C: GETPWNAM brister
-
- S: 231 User found
- brister:*:1364:100:James Brister:/udir/brister:/bin/csh:
- .
-
- C: GETPWUID 6
- games:*:7:13:Games Pseudo-user:/usr/games:nologin
- .
-
- S: GETPWENT
- root:*:0:0:System Administrator:/root:/bin/csh
- postmast:*:4:4:Postmaster:/:/nologin
- daemon:*:1:1:System Daemon:/:nologin
- sys:*:2:2:Operating System:/tmp:nologin
- bin:*:3:7:BSDI Software:/usr/bsdi:nologin
- operator:*:5:5:System Operator:/usr/opr:/bin/csh
- uucp:*:6:6:UNIX-to-UNIX Copy:/var/spool/uucppublic:/usr/libexec/uucico
- .
-
- If a priviled user looks up a username:
-
- C: GETPWNAM www
-
- S: 231 User found
- www:WZajcgFCaAd8s:51:84::0:0:WWW-server:/var/www:/bin/sh
- .
-
-3.3 The NETWORK commands
-
-3.3.1 GETNETBYNAME network
-3.3.2 GETNETBYADDR dotted-ip-address address-family
-3.3.4 GETNETENT
-
- Returns a textual response with the network information (an IRS struct
- nwent, *not* a struct netent) enocoded in an ascii format. The optionally
- supported GETNETENT command transmits the entire /etc/networks file
-
-{ XXX should it be optional? }
-
-3.2.4 Reponses
-
- 220 No such network
- 221 Netork found
-
- If the network given as the command argument doesn't exist, then the 220
- response will be returned. If the network is successfully looked up, then
- the 221 response is sent and a textual message is sent after. The textual
- message contains the network information encoded in an ascii form. The fields
- of the network data are separated by colons.
-
- network-name:aliases:address-type:address-length:network-address:
-
- - network-name is the name of the network
-
- - aliases is a comma separated list of aliases for the network
-
- - address-type is ``AF_INET'' or ``AF_INET6''.
-
- - address-length is the number of bits the following network address uses.
-
- - address is the network address in a dotted ascii format. AF_INET address
- are padded with 0 bits to the full 32 bits before conversion to ascii for
- transmission. AF_INET6 addresses are padded to the full 128 bits with 0
- bits before conversion.
-
- For example:
-
- C: GETNETBYNAME vixie-net
-
- S: 221 Network found
- vixie-net::AF_INET:24:192.5.5.0:
- .
-
- C: GETNETBYADDR 10.0.0.1
-
- S: 221 Network found
- private-net:home-net,upstairs-net:AF_INET:8:10.0.0.0:
- .
-
- C: GETNETENT
-
- S: 221 OK
- vixie-net::AF_INET:24:192.5.5.0:
- private-net:home-net,upstairs-net:AF_INET:8:10.0.0.0:
- lookback-net::AF_INET:8:127.0.0.0
- .
-
-3.4 The GROUP commands
-
-3.4.1 GETGRNAM group
-3.4.2 GETGRGID gid
-3.4.3 GETGRENT
-
- Returns a textual response with the group information (a struct group)
- enocoded in an ascii format. The optionally supported GETGRENT command
- transmits the entire /etc/group file.
-
-3.4.4 Reponses
-
- 240 No such group
- 241 Group found
-
- If the group given as the command argument doesn't exist, then the 240
- response will be returned. If the group is successfully looked up, then
- the 241 response is sent and a textual message is sent after. The textual
- message contains the group information encoded in an ascii form. The fields
- of the group data are separated by colons.
-
- group-name:group-password:group-gid:group-members:
-
- - group-name is the name of the group.
-
- - group-password is the group's password. This will be correct if the
- client has appropriate privileges (see discussion above on the USER
- commands). Otherwise it will be the string ``*''
-
- - group-gid is the numeric id for the group
-
- - group-members is a comma separated list of usernames for all the members
- of the group.
-
- For example:
-
- C: GETGRNAM wheel
-
- S: 241 Group found
- wheel:*:0:root,brister,nathalie,tester:
-
- C: GETGRGID 20
-
- S: 241 Group found
- staff:*:20:root,brister:
-
- C: GETGRENT
-
- S: 241 OK
- wheel:*:0:root,brister,nathalie,tester:
- daemon:*:1:daemon:
- kmem:*:2:root:
- sys:*:3:root:
- tty:*:4:root:
- operator:*:5:root:
- uucp:*:6:brister:
- bin:*:7::
- news:*:8:brister:
- utmp:*:12::
- games:*:13::
- mail:*:14::
- staff:*:20:root,brister:
- .
-
-3.5 The SERVICE commands
-
-3.5.1 GETSERVBYNAME name protocol
-3.5.2 GETSERVBYPORT port protocol
-3.5.3 GETSERVENT
-
- Returns a textual response with the service information (a struct servent)
- enocoded in an ascii format. The optionally supported GETSERVENT command
- transmits the entire /etc/services file.
-
-3.5.4 Reponses
-
- 250 No such service
- 251 Group found
-
- If the group given as the command argument doesn't exist, then the 250
- response will be returned. If the service is successfully looked up, then
- the 251 response is sent and a textual message is sent after. The textual
- message contains the service information encoded in an ascii form. The fields
- of the service data are separated by colons.
-
- service-name:aliases:port-number:protocol:
-
- - The service name is the offical name of the services.
-
- - aliases is a comma separated list of aliases for the service.
-
- - port-number is the decimal number of the port used for the service.
-
- - protocol is the name of the protocol the service operates under. Usually
- either ``TCP'' or ``UCP''
-
- For example:
-
- C: GETSERVBYNAME nntp tcp
-
- S: 251 Service found
- nntp:readnews,untp:119:tcp:
- .
-
- C: GETSERVBYPORT 514 udp
- syslog::514:ucp:
- .
-
- C: GETSERVENT
- 251 OK
- tcpmux::1:tcp:
- echo::7:tcp:
- echo::7:udp:
- discard:sink,null:9:tcp:
- discard:sink,null:9:udp:
- systat:users:11:tcp:
- systat:users:11:udp:
- daytime::13:tcp:
- daytime::13:udp:
- netstat::15:tcp:
- qotd:quote:17:tcp:
- qotd:quote:17:udp:
- .
-
-3.6 The PROTOCOL commands
-
-3.6.1 GETPROTOBYNAME protocol-name
-3.6.2 GETPROTOBYNUMBER protocol-number
-3.6.3 GETPROTOENT
-
- Returns a textual response with the protocol information (a struct protoent)
- enocoded in an ascii format. The optionally supported GETPROTOENT command
- transmits the entire /etc/protocols file.
-
-3.6.4 Reponses
-
- 260 No such protocol
- 261 Protocol found
-
- If the protocol given as the command argument doesn't exist, then the 260
- response will be returned. If the service is successfully looked up, then
- the 261 response is sent and a textual message is sent after. The textual
- message contains the protocol information encoded in an ascii form. The fields
- of the protocol data are separated by colons.
-
- protocol-name:aliases:protocol-number:
-
- - protocol-name is the offical name of the protocol
-
- - aliases is a comma separated list of aliases for the protocol
-
- - protocol-nunber is the number of the protocol in decimal.
-
-
- For example:
-
- C: GETPROTOBYNAME ip
-
- S: 261 Protocol found
- ip:IP:0:
- .
-
- C: GETPROTOBYNUMBER 17
-
- S: 261 Protocol found
- udp:UDP:17:
- .
-
- C: GETPROTOENT
-
- S: 261 OK
- ip:IP:0:
- icmp:ICMP:1:
- igmp:IGMP:2:
- ggp:GGP:3:
- tcp:TCP:6:
- egp:EGP:8:
- pup:PUP:12:
- udp:UDP:17:
- hmp:HMP:20:
- xns-idp:XNS-IDP:22:
- rdp:RDP:27:
- iso-tp4:ISO-TP4:29:
- iso-ip:ISO-IP:80:
- encap:ENCAP:98:
- .
-
-3.7 The NETGROUP commands
-
-3.7.1 GETNETGRENT netgrouup
-
- Returns a textual response with the netgroup information enocoded in an
- ascii format.
-
-3.6.4 Reponses
-
- 270 No such netgroup
- 271 Netgroups found
-
- For the given netgroup a list of the netgroup entries will be
- returned. Each netgroup entry is three fields separated by colons. A field
- may be empty to indicate wildcarding.
-
- :hostname:username:domainname:
-
- For example:
-
- C: GETNETGRENT devlopers
-
- S: 271 OK
- :gw.home.vix.com:brister:vix.com:
- :bb.rc.vix.com:vixie::
- .
-
-
-
-
OpenPOWER on IntegriCloud