updated bind docs

13 files changed, 2946 insertions, 0 deletions

diff --git a/usr.sbin/named/doc/bog/named.boot.cache b/usr.sbin/named/doc/bog/named.boot.cache
new file mode 100644
index 00000000000..5e0e3d34812
--- /dev/null
+++ b/usr.sbin/named/doc/bog/named.boot.cache
@@ -0,0 +1,77 @@
+.\" ++Copyright++ 1986, 1988
+.\" -
+.\" Copyright (c) 1986, 1988
+.\"    The Regents of the University of California.  All rights reserved.
+.\" 
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\" 	This product includes software developed by the University of
+.\" 	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\" 
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\" -
+.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
+.\" 
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies, and that
+.\" the name of Digital Equipment Corporation not be used in advertising or
+.\" publicity pertaining to distribution of the document or software without
+.\" specific, written prior permission.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
+.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
+.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+.\" SOFTWARE.
+.\" -
+.\" --Copyright--
+.\"
+.\"	@(#)named.boot.cache	6.4 (Berkeley) 9/19/89
+.\"
+.ne 13v
+.sh 4 "Caching Only Server"
+.(b L 
+.TS
+l.
+;
+; Boot file for Caching Only Name Server
+;
+.TE
+.TS
+l l l
+l
+l l l.
+; type	domain	source file or host
+;
+directory	/usr/local/adm/named
+cache	\fB.\fP	root\fB.\fPcache
+primary	0\fB.\fP0\fB.\fP127\fB.\fPin-addr\fB.\fParpa	named\fB.\fPlocal
+.TE
+.)b
+
+
diff --git a/usr.sbin/named/doc/bog/named.boot.primary b/usr.sbin/named/doc/bog/named.boot.primary
new file mode 100644
index 00000000000..0f3c3ca9aa8
--- /dev/null
+++ b/usr.sbin/named/doc/bog/named.boot.primary
@@ -0,0 +1,78 @@
+.\" ++Copyright++ 1986, 1988
+.\" -
+.\" Copyright (c) 1986, 1988
+.\"    The Regents of the University of California.  All rights reserved.
+.\" 
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\" 	This product includes software developed by the University of
+.\" 	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\" 
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\" -
+.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
+.\" 
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies, and that
+.\" the name of Digital Equipment Corporation not be used in advertising or
+.\" publicity pertaining to distribution of the document or software without
+.\" specific, written prior permission.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
+.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
+.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+.\" SOFTWARE.
+.\" -
+.\" --Copyright--
+.\"
+.\"	@(#)named.boot.primary	6.4 (Berkeley) 9/19/89
+.\"
+.ne 15v
+.sh 3 "Boot Files"
+.sh 4 "Primary Server"
+.(b L
+.TS
+l.
+;
+; Boot file for Primary Name Server
+;
+.TE
+.TS
+l l l
+l
+l l l.
+; type	domain	source file or host
+;
+directory	/usr/local/adm/named
+primary	Berkeley\fB.\fPEdu	ucbhosts
+primary	32\fB.\fP128\fB.\fPin-addr\fB.\fParpa	ucbhosts\fB.\fPrev
+primary	0\fB.\fP0\fB.\fP127\fB.\fPin-addr\fB.\fParpa	named\fB.\fPlocal
+cache	\fB.\fP	root\fB.\fPcache
+.TE
+.)b
diff --git a/usr.sbin/named/doc/bog/named.boot.secondary b/usr.sbin/named/doc/bog/named.boot.secondary
new file mode 100644
index 00000000000..64a607d5801
--- /dev/null
+++ b/usr.sbin/named/doc/bog/named.boot.secondary
@@ -0,0 +1,77 @@
+.\" ++Copyright++ 1986, 1988
+.\" -
+.\" Copyright (c) 1986, 1988
+.\"    The Regents of the University of California.  All rights reserved.
+.\" 
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\" 	This product includes software developed by the University of
+.\" 	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\" 
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\" -
+.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
+.\" 
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies, and that
+.\" the name of Digital Equipment Corporation not be used in advertising or
+.\" publicity pertaining to distribution of the document or software without
+.\" specific, written prior permission.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
+.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
+.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+.\" SOFTWARE.
+.\" -
+.\" --Copyright--
+.\"
+.\"	@(#)named.boot.secondary	6.4 (Berkeley) 9/19/89
+.\"
+.ne 12v
+.sh 4 "Secondary Server"
+.(b L
+.TS
+l.
+;
+; Boot file for Secondary Name Server
+;
+.TE
+.TS
+l l l
+l
+l l l.
+; type	domain	source file or host
+;
+directory	/usr/local/adm/named
+secondary	Berkeley\fB.\fPEdu	128\fB.\fP32\fB.\fP0\fB.\fP4 128\fB.\fP32\fB.\fP0\fB.\fP10 ucbhosts.bak
+secondary	32\fB.\fP128\fB.\fPin-addr\fB.\fParpa	128\fB.\fP32\fB.\fP0\fB.\fP4 128\fB.\fP32\fB.\fP0\fB.\fP10 ucbhosts.rev.bak
+primary	0\fB.\fP0\fB.\fP127\fB.\fPin-addr\fB.\fParpa	named\fB.\fPlocal
+cache	\fB.\fP	root\fB.\fPcache
+.TE
+.)b
diff --git a/usr.sbin/named/doc/bog/named.local b/usr.sbin/named/doc/bog/named.local
new file mode 100644
index 00000000000..209c5be8bae
--- /dev/null
+++ b/usr.sbin/named/doc/bog/named.local
@@ -0,0 +1,75 @@
+.\" ++Copyright++ 1986, 1988
+.\" -
+.\" Copyright (c) 1986, 1988
+.\"    The Regents of the University of California.  All rights reserved.
+.\" 
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\" 	This product includes software developed by the University of
+.\" 	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\" 
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\" -
+.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
+.\" 
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies, and that
+.\" the name of Digital Equipment Corporation not be used in advertising or
+.\" publicity pertaining to distribution of the document or software without
+.\" specific, written prior permission.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
+.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
+.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+.\" SOFTWARE.
+.\" -
+.\" --Copyright--
+.\"
+.\"	@(#)named.local	6.3 (Berkeley) 5/24/89
+.\"
+.ne 13v
+.sh 3 "named.local"
+.(b L 
+
+.TS
+l l l l l s. 
+@	IN	SOA	ucbvax\fB.\fPBerkeley\fB.\fPEdu.	kjd\fB.\fPucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP (
+.T&
+l l l l l.
+			1994072100	; Serial
+			10800	; Refresh
+			1800	; Retry
+			3600000	; Expire
+			259200 )	; Minimum
+.T&
+l l l l l s.
+	IN	NS	ucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP	; pedantic
+1	IN	PTR	localhost\fB.\fP
+.TE
+.)b
diff --git a/usr.sbin/named/doc/bog/ns.me b/usr.sbin/named/doc/bog/ns.me
new file mode 100644
index 00000000000..b507e9420dd
--- /dev/null
+++ b/usr.sbin/named/doc/bog/ns.me
@@ -0,0 +1,127 @@
+.\" 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.
+.\"
+.\"	@(#)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.
+.sh 1 Security
+.pp
+This section examines some of the know security implications of various
+versions of BIND. Some of these have been used to attack the nameservers
+in the past.
+.sh 2 "Unnecessary Glue"
+.pp
+Unnecessary glue can lead to incorrect records being loaded into the
+server. This can result in connections going to the wrong machines.
+.pp
+To prevent unnecessary glue being loaded, all the servers of zones being
+servered by a server and the servers of the parent zones need to be
+upgraded to BIND 4.9.3 or later.
+.sh 2 "Insertion of data into a zone that is being servered"
+.pp
+BIND versions prior to BIND 4.9.2 are subject to the insertion of
+resource records into zone that they are serving.
+.sh 2 "Denial of Service: Hash Bug Exploit"
+.pp
+September 1996 saw the COM TLD subject to a denial of service attack by
+injecting into the DNS a record with a final label of COM, eight spaces
+and COM. This effected BIND 4.9.4 servers. Similar attacks are possible
+on BIND 4.9.3 and BIND 4.9.3-P1. 
+.pp
+It is recommend that you run a BIND 4.9.4-P1 or later server to avoid
+this exploit.
+.sh 2 "Denial of Service: TTL Inconsistency Attacks"
+.pp
+If you are still using multiple TTL values within a RRset you can be
+subject to a denial of service attack. BIND 4.9.5 onwards uses multiple
+ttl values within a RRset to reject obviously bad RRset.
+.pp
+It is recommend that you upgrade to BIND 4.9.5 or later as these server
+prevent you loading multiple TTL values and doesn't merge answers received
+across the network.
diff --git a/usr.sbin/named/doc/bog/resolv.conf b/usr.sbin/named/doc/bog/resolv.conf
new file mode 100644
index 00000000000..1f15991f8e6
--- /dev/null
+++ b/usr.sbin/named/doc/bog/resolv.conf
@@ -0,0 +1,67 @@
+.\" ++Copyright++ 1986, 1988
+.\" -
+.\" Copyright (c) 1986, 1988
+.\"    The Regents of the University of California.  All rights reserved.
+.\" 
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\" 	This product includes software developed by the University of
+.\" 	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\" 
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\" -
+.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
+.\" 
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies, and that
+.\" the name of Digital Equipment Corporation not be used in advertising or
+.\" publicity pertaining to distribution of the document or software without
+.\" specific, written prior permission.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
+.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
+.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+.\" SOFTWARE.
+.\" -
+.\" --Copyright--
+.\"
+.\"	@(#)resolv.conf	6.2 (Berkeley) 2/29/88
+.\"
+.ne 6v
+.\" .bp
+.sh 3 "Remote Server / DNS Client"
+.sh 4 "/etc/resolv.conf"
+.(b L
+
+domain Berkeley\fB.\fPEdu
+nameserver 128\fB.\fP32\fB.\fP0\fB.\fP4
+nameserver 128\fB.\fP32\fB.\fP0\fB.\fP10
+sortlist 130.155.160.0/255.255.240.0 130.155.0.0
+
+.)b
diff --git a/usr.sbin/named/doc/bog/root.cache b/usr.sbin/named/doc/bog/root.cache
new file mode 100644
index 00000000000..3bf572724f8
--- /dev/null
+++ b/usr.sbin/named/doc/bog/root.cache
@@ -0,0 +1,102 @@
+.\" ++Copyright++ 1986, 1988
+.\" -
+.\" Copyright (c) 1986, 1988
+.\"    The Regents of the University of California.  All rights reserved.
+.\" 
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\" 	This product includes software developed by the University of
+.\" 	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\" 
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\" -
+.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
+.\" 
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies, and that
+.\" the name of Digital Equipment Corporation not be used in advertising or
+.\" publicity pertaining to distribution of the document or software without
+.\" specific, written prior permission.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
+.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
+.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+.\" SOFTWARE.
+.\" -
+.\" --Copyright--
+.\"
+.\"	@(#)root.cache	6.4 (Berkeley) 4/29/90
+.\"
+.ne 38v
+.sh 3 "root.cache"
+.(b L
+
+;
+;       This file holds the information on root name servers needed to
+;       initialize cache of Internet domain name servers 
+;       (e.g. reference this file in the "cache  .  <file>"
+;       configuration file of BIND domain name servers).
+;
+;       This file is made available by InterNIC registration services
+;       under anonymous FTP as
+;           file                /domain/named.root
+;           on server           FTP.RS.INTERNIC.NET
+;       -OR- under Gopher at    RS.INTERNIC.NET
+;           under menu          InterNIC Registration Services (NSI)
+;              submenu          InterNIC Registration Archives
+;           file                named.root
+;
+;       last update:    Oct 5, 1994
+;       related version of root zone:   1994100500
+;
+.TS
+l	l	l	l	l.	
+\fB.\fP	604800	IN	NS	NS\fB.\fPINTERNIC\fB.\fPNET\fB.\fP
+NS\fB.\fPINTERNIC\fB.\fPNET\fB.\fP	604800	IN	A	198\fB.\fP41\fB.\fP0\fB.\fP4
+\fB.\fP	604800	IN	NS	NS1\fB.\fPISI\fB.\fPEDU\fB.\fP	
+NS1\fB.\fPISI\fB.\fPEDU\fB.\fP	604800	IN	A	128\fB.\fP9\fB.\fP0\fB.\fP107
+\fB.\fP	604800	IN	NS	C\fB.\fPPSI\fB.\fPNET\fB.\fP
+C\fB.\fPPSI\fB.\fPNET\fB.\fP	604800	IN	A	192\fB.\fP33\fB.\fP4\fB.\fP12
+\fB.\fP	604800	IN	NS	TERP\fB.\fPUMD\fB.\fPEDU\fB.\fP
+TERP\fB.\fPUMD\fB.\fPEDU\fB.\fP	604800	IN	A	128\fB.\fP8\fB.\fP10\fB.\fP90
+\fB.\fP	604800	IN	NS	NS\fB.\fPNASA\fB.\fPGOV\fB.\fP
+NS\fB.\fPNASA\fB.\fPGOV\fB.\fP	604800	IN	A	128\fB.\fP102\fB.\fP16\fB.\fP10
+	604800	IN	A	192\fB.\fP52\fB.\fP195\fB.\fP10
+\fB.\fP	604800	IN	NS	NS\fB.\fPISC\fB.\fPORG\fB.\fP
+NS\fB.\fPISC\fB.\fPORG\fB.\fP	604800	IN	A	192\fB.\fP5\fB.\fP5\fB.\fP241
+\fB.\fP	604800	IN	NS	NS\fB.\fPNIC\fB.\fPDDN\fB.\fPMIL\fB.\fP
+NS\fB.\fPNIC\fB.\fPDDN\fB.\fPMIL\fB.\fP	604800	IN	A	192\fB.\fP112\fB.\fP36\fB.\fP4
+\fB.\fP	604800	IN	NS	AOS\fB.\fPARL\fB.\fPARMY\fB.\fPMIL\fB.\fP
+AOS\fB.\fPARL\fB.\fPARMY\fB.\fPMIL\fB.\fP	604800	IN	A	128\fB.\fP63\fB.\fP4\fB.\fP82
+	604800	IN	A	192\fB.\fP5\fB.\fP25\fB.\fP82
+\fB.\fP	604800	IN	NS	NIC\fB.\fPNORDU\fB.\fPNET\fB.\fP
+NIC\fB.\fPNORDU\fB.\fPNET\fB.\fP	604800	IN	A	192\fB.\fP36\fB.\fP148\fB.\fP17
+.TE
+; End of File
+.)b
diff --git a/usr.sbin/named/doc/bog/setup.me b/usr.sbin/named/doc/bog/setup.me
new file mode 100644
index 00000000000..fff765748f9
--- /dev/null
+++ b/usr.sbin/named/doc/bog/setup.me
@@ -0,0 +1,88 @@
+.\" ++Copyright++ 1986, 1988
+.\" -
+.\" Copyright (c) 1986, 1988
+.\"    The Regents of the University of California.  All rights reserved.
+.\" 
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\" 	This product includes software developed by the University of
+.\" 	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\" 
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\" -
+.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
+.\" 
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies, and that
+.\" the name of Digital Equipment Corporation not be used in advertising or
+.\" publicity pertaining to distribution of the document or software without
+.\" specific, written prior permission.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
+.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
+.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+.\" SOFTWARE.
+.\" -
+.\" --Copyright--
+.\"
+.\"	@(#)setup.me	6.4 (Berkeley) 9/19/89
+.\"
+.sh 1 "Setting up Your Own Domain"
+.pp
+When setting up a domain that is going to be on a public network the site
+administrator should contact the organization in charge of the network and
+request the appropriate domain registration form.  An organization that
+belongs to multiple networks (such as the \fIInternet\fP and
+\fIBITNET\fP) should register with only one network.
+.sh 2 "Internet"
+.pp
+Sites on the Internet who need information on setting up a domain should
+contact the registrar for their network, which is one of the following:
+.TS
+l l.
+MILnet	\s-1HOSTMASTER\s+1@\s-1NIC\s+1\fB\|.\|\fP\s-1DDN\s+1\fB\|.\|\fP\s-1MIL\s+1
+other	\s-1HOSTMASTER\s+1@\s-1INTERNIC\s+1\fB\|.\|\fP\s-1NET\s+1
+.TE
+You may also want to be placed on the \s-1BIND\s+1 mailing list, which is a
+mail group for people on the Internet who run \s-1BIND\s+1.  The group
+discusses future design decisions, operational problems, and other related
+topic.  The address to request being placed on this mailing list is:
+.(b l
+\fIbind-request\|@\|uunet\fP\fB\|.\|\fP\fIuu\fP\fB\|.\|\fP\fInet\fP
+.)b
+.sh 2 "Subdomains of Existing Domains"
+.pp
+If you want a subdomain of some existing domain, you should find the contact
+point for the parent domain rather than asking one of the above top-level
+registrars.  There should be a convention that \fBregistrar\fP@\fIdomain\fP
+or \fBhostmaster\fP@\fIdomain\fP for any given domain will always be an alias
+for that domain's registrar (somewhat analogous to \fBpostmaster\fP), but
+there is no such convention.  Try it as a last resort, but first you should
+examine the \fISOA\fP record for the domain and send mail to the ``responsible
+person'' shown therein.  You can also try \fIwhois\fP.
diff --git a/usr.sbin/named/doc/bog/types.me b/usr.sbin/named/doc/bog/types.me
new file mode 100644
index 00000000000..9d14111214d
--- /dev/null
+++ b/usr.sbin/named/doc/bog/types.me
@@ -0,0 +1,163 @@
+.\" ++Copyright++ 1986, 1988, 1995
+.\" -
+.\" Copyright (c) 1986, 1988, 1995
+.\"    The Regents of the University of California.  All rights reserved.
+.\" 
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\" 	This product includes software developed by the University of
+.\" 	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\" 
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\" -
+.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
+.\" 
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies, and that
+.\" the name of Digital Equipment Corporation not be used in advertising or
+.\" publicity pertaining to distribution of the document or software without
+.\" specific, written prior permission.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
+.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
+.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+.\" SOFTWARE.
+.\" -
+.\" --Copyright--
+.\"
+.\"	@(#)types.me	6.3 (Berkeley) 9/19/89
+.\"
+.sh 1 "Types of Zones"
+.pp
+A ``zone'' is a point of delegation in the DNS tree.  It contains all names
+from a certain point ``downward'' except those which are delegated to other
+zones.  A ``delegation point'' has one or more \fINS\fP records in the
+``parent zone'', which should be matched by equivalent \fINS\fP records at
+the root of the ``delegated zone'' (i.e., the ``@'' name in the zone file).
+.pp
+Understanding the difference between a ``zone'' and a ``domain'' is crucial
+to the proper operation of a name server.  As an example, consider the
+\s-1DEC.COM\s+1 \fIdomain\fP, which includes names such as
+\s-1POBOX1.PA.DEC.COM\s+1 and \s-1QUABBIN.CRL.DEC.COM\s+1 even though
+the \s-1DEC.COM\s+1 \fIzone\fP includes only \fIdelegations\fP for the
+\s-1PA.DEC.COM\s+1 and \s-1CRL.DEC.COM\s+1 zones.  A zone can map exactly
+to a single domain, but could also include only part of a domain (the rest
+of which could be delegated to other name servers).  Technically speaking,
+every name in the DNS tree is a ``domain'', even if it is ``terminal'', that
+is, has no ``subdomains''.  Technically speaking, every subdomain is a domain
+and every domain except the root is also a subdomain.  The terminology is not
+intuitive and you would do well to read RFC's 1033, 1034, and 1035 to gain a
+complete understanding of this difficult and subtle topic.
+.pp
+Though \s-1BIND\s+1 is a \fIDomain\fP Name Server, it deals primarily in terms
+of \fIzones\fP.  The \fIprimary\fP and \fIsecondary\fP declarations in the
+\fInamed.boot\fP file specify \fIzones\fP, not \fIdomains\fP.  When you ask
+someone if they are willing to be a secondary server for your ``domain'', you
+are actually asking for secondary service for some collection of \fIzones\fP.
+.pp
+Each zone will have one ``primary'' server, which loads the zone contents
+from some local file which is edited by humans or perhaps generated
+mechanically from some other local file which is edited by humans.  Then
+there will be some number of ``secondary'' servers, which load the zone
+contents using the \s-1IP/DNS\s+1 protocol (that is, the secondary servers will
+contact the primary and fetch the zone using \s-1IP/TCP\s+1).  This set of
+servers (the primary and all of the secondaries) should be listed in the
+\fINS\fP records in the parent zone, which will constitute a ``delegation''.
+This set of servers must also be listed in the zone file itself, usually
+under the ``@'' name which is a magic cookie that means the ``top level''
+or ``root'' of current zone.  You can list servers in the zone's
+top-level ``@'' \fINS\fP records that are not in the parent's \fINS\fP
+delegation, but you cannot list servers in the parent's delegation that are
+not present in the zone's ``@''.  Any servers listed in the \fINS\fP records
+must be configured as authoritative (either primary or secondary) for the
+zone.  If a server listed in a \fINS\fP record is not authoritative, it
+will respond with a ``lame delegation'' when queried.
+.sh 1 "Types of Servers"
+.pp
+Servers do not really have ``types''.  A server can be a primary for some
+zones and a secondary for others, or it can be only a primary, or only a
+secondary, or it can serve no zones and just answer queries via its ``cache''.
+Previous versions of this document referred to servers as ``master'' and
+``slave'' but we now feel that those distinctions \(em and the assignment of
+a ``type'' to a name server \(em are not useful.
+.sh 2 "Caching Only Server"
+.pp
+All servers are caching servers.  This means that the server caches the
+information that it receives for use until the data expires.  A \fICaching
+Only Server\fP is a server that is not authoritative for any zone.  This
+server services queries and asks other servers, who have the authority, for
+the information needed.  All servers keep data in their cache until the data
+expires, based on a \fITTL\fP (``Time To Live'') field which is maintained
+for all resource records.
+.sh 2 "Remote Server"
+.pp
+A Remote Server is an option given to people who would like to use 
+a name server from their workstation or on a machine that has a limited
+amount of memory and CPU cycles.
+With this option you can run all of the networking programs that use
+the name server without the name server running on the local machine.
+All of the queries are serviced by a name server that is running on another 
+machine on the network.
+A host which has an
+\fI/etc/resolv.conf\fP file listing only remote hosts, and which does not
+run a name server of its own, is sometimes called a Remote Server (because
+the actual server is remote?) but more
+often it is called simply a DNS Client.
+This kind of host is technically not a ``server'',
+since it has no cache and does not answer queries.
+.sh 2 "Slave Server"
+.pp
+A Slave Server is a server that always forwards queries it cannot
+satisfy from its cache, to a fixed list of \fIforwarding\fP servers
+instead of interacting
+with the name servers for the root and other domains.
+The queries to the \fIforwarding servers\fP are recursive queries.
+There may be one or more forwarding servers, and they are tried in turn
+until the list is exhausted.
+A Slave and forwarder configuration is typically used when you do not
+wish all the servers at a given site to interact with the rest
+of the Internet servers.  A typical scenario would involve a number of
+workstations and a departmental timesharing machine with Internet
+access.  The workstations might be
+administratively prohibited from having Internet access.
+To give the workstations the appearance of access to the Internet
+domain system, the workstations could be Slave servers to the timesharing
+machine which would forward the queries and interact with other
+name servers to resolve the query before returning the answer.
+An added benefit of using the forwarding feature is that the central
+machine develops a much more complete cache of information that
+all the workstations can take advantage of.  The use of Slave mode
+and forwarding is discussed further under the description of
+the \fInamed\fP bootfile commands.
+.pp
+There is no prohibition against declaring a server to be a \fIslave\fP
+even though it has \fIprimary\fP and/or \fIsecondary\fP zones as well;
+the effect will still be that anything in the local server's cache or
+zones will be answered, and anything else will be forwarded using the
+\fIforwarders\fP list.
diff --git a/usr.sbin/named/doc/bog/ucbhosts b/usr.sbin/named/doc/bog/ucbhosts
new file mode 100644
index 00000000000..2cb26355eb8
--- /dev/null
+++ b/usr.sbin/named/doc/bog/ucbhosts
@@ -0,0 +1,118 @@
+.\" ++Copyright++ 1986, 1988
+.\" -
+.\" Copyright (c) 1986, 1988
+.\"    The Regents of the University of California.  All rights reserved.
+.\" 
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\" 	This product includes software developed by the University of
+.\" 	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\" 
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\" -
+.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
+.\" 
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies, and that
+.\" the name of Digital Equipment Corporation not be used in advertising or
+.\" publicity pertaining to distribution of the document or software without
+.\" specific, written prior permission.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
+.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
+.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+.\" SOFTWARE.
+.\" -
+.\" --Copyright--
+.\"
+.\"	@(#)ucbhosts	6.3 (Berkeley) 2/8/89
+.\"
+.\" .ne 48v
+.\" .bp
+.sh 3 "Hosts"
+.(b L
+;
+;    @(#)ucb-hosts    1.2    (berkeley)    88/02/05
+;
+.TS
+l l l l l s. 
+@	IN	SOA	ucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP	kjd\fB.\fPmonet\fB.\fPBerkeley\fB.\fPEdu\fB.\fP (
+.T&
+l l l l l.
+			1988020501	; Serial
+			10800	; Refresh
+			1800	; Retry
+			3600000	; Expire
+			259200 )	; Minimum
+.T&
+l l l l s.
+	IN	NS	ucbarpa\fB.\fPBerkeley\fB.\fPEdu\fB.\fP
+	IN	NS	ucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP
+localhost	IN	A	127\fB.\fP1
+			; note that 127.1 is the same as 127.0.0.1; see inet(3n)
+ucbarpa	IN	A	128\fB.\fP32\fB.\fP4
+	IN	A	10\fB.\fP0\fB.\fP0\fB.\fP78
+	IN	HINFO	VAX-11/780 UNIX
+arpa	IN	CNAME	ucbarpa
+ernie	IN	A	128\fB.\fP32\fB.\fP6
+	IN	HINFO	VAX-11/780 UNIX
+ucbernie	IN	CNAME	ernie
+monet	IN	A	128\fB.\fP32\fB.\fP7
+	IN	A	128\fB.\fP32\fB.\fP130\fB.\fP6
+	IN	HINFO	VAX-11/750 UNIX
+ucbmonet	IN	CNAME	monet
+ucbvax	IN	A	10\fB.\fP2\fB.\fP0\fB.\fP78
+			; 128.32.10 means 128.32.0.10; see inet(3n)
+	IN	A	128\fB.\fP32\fB.\fP10
+			; HINFO and WKS are widely unused,
+			; but we'll show them as examples.
+	IN	HINFO	VAX-11/750 UNIX
+	IN	WKS	128.32.0.10 TCP ( echo telnet
+			discard sunrpc sftp
+			uucp-path systat daytime
+			netstat qotd nntp
+			link chargen ftp
+			auth time whhois mtp
+			pop rje finger smtp
+			supdup hostnames
+			domain
+			nameserver )
+vax	IN	CNAME	ucbvax
+toybox	IN	A	128\fB.\fP32\fB.\fP131\fB.\fP119
+	IN	HINFO	Pro350 RT11
+toybox	IN	MX	0  monet.Berkeley.Edu.
+csrg	IN	MX	0 Ralph.CS
+	IN	MX	0 Zhou.CS
+	IN	MX	0 Painter.CS
+	IN	MX	0 Riggle.CS
+	IN	MX	0 Terry.CS
+	IN	MX	0 Kevin.CS
+.TE
+.)b
+.\" .bp
diff --git a/usr.sbin/named/doc/bog/ucbhosts.rev b/usr.sbin/named/doc/bog/ucbhosts.rev
new file mode 100644
index 00000000000..16207afefed
--- /dev/null
+++ b/usr.sbin/named/doc/bog/ucbhosts.rev
@@ -0,0 +1,86 @@
+.\" ++Copyright++ 1986, 1988
+.\" -
+.\" Copyright (c) 1986, 1988
+.\"    The Regents of the University of California.  All rights reserved.
+.\" 
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\" 	This product includes software developed by the University of
+.\" 	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\" 
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\" -
+.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
+.\" 
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies, and that
+.\" the name of Digital Equipment Corporation not be used in advertising or
+.\" publicity pertaining to distribution of the document or software without
+.\" specific, written prior permission.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
+.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
+.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+.\" SOFTWARE.
+.\" -
+.\" --Copyright--
+.\"
+.\"	@(#)ucbhosts.rev	6.3 (Berkeley) 9/19/89
+.\"
+.ne 22v
+.sh 3 "host.rev"
+.(b L
+
+;
+;    @(#)ucb-hosts.rev    1.1    (Berkeley)    86/02/05
+;
+.TS
+l l l l l s. 
+@	IN	SOA	ucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP	kjd\fB.\fPmonet\fB.\fPBerkeley\fB.\fPEdu\fB.\fP (
+.T&
+l l l l l.
+			1986020501	; Serial
+			10800	; Refresh
+			1800	; Retry
+			3600000	; Expire
+			259200 )	; Minimum
+.T&
+l l l l s.
+	IN	NS	ucbarpa\fB.\fPBerkeley\fB.\fPEdu\fB.\fP
+	IN	NS	ucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP
+0\fB.\fP0	IN	PTR	Berkeley-net\fB.\fPBerkeley\fB.\fPEDU\fB.\fP
+	IN	A	255\fB.\fP255\fB.\fP255\fB.\fP0
+0\fB.\fP130	IN	PTR	csdiv-net\fB.\fPBerkeley\fB.\fPEDU\fB.\fP
+4\fB.\fP0	IN	PTR	ucbarpa\fB.\fPBerkeley\fB.\fPEdu\fB.\fP
+6\fB.\fP0	IN	PTR	ernie\fB.\fPBerkeley\fB.\fPEdu\fB.\fP
+7\fB.\fP0	IN	PTR	monet\fB.\fPBerkeley\fB.\fPEdu\fB.\fP
+10\fB.\fP0	IN	PTR	ucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP
+6\fB.\fP130	IN	PTR	monet\fB.\fPBerkeley\fB.\fPEdu\fB.\fP
+.TE
+.)b
diff --git a/usr.sbin/named/doc/misc/DynamicUpdate b/usr.sbin/named/doc/misc/DynamicUpdate
new file mode 100644
index 00000000000..4cd43a12bb3
--- /dev/null
+++ b/usr.sbin/named/doc/misc/DynamicUpdate
@@ -0,0 +1,286 @@
+[ Deprecated, unsupported, nonfunctional, but not yet completely excised. ]
+
+ 
+ 
+		Description of Dynamic Update and T_UNSPEC Code
+ 
+ 
+ 
+ 
+                         Added by Mike Schwartz
+          University of Washington Computer Science Department
+                                  11/86
+                       schwartz@cs.washington.edu
+ 
+ 
+ 
+ 
+I have incorporated 2 new features into BIND:
+	1. Code to allow (unauthenticated) dynamic updates: surrounded by
+	   #ifdef ALLOW_UPDATES
+	2. Code to allow data of unspecified type: surrounded by
+	   #ifdef ALLOW_T_UNSPEC
+ 
+Note that you can have one or the other or both (or neither) of these
+modifications running, by appropriately modifying the makefiles.  Also,
+the external interface isn't changed (other than being extended), i.e.,
+a BIND server that allows dynamic updates and/or T_UNSPEC data can
+still talk to a 'vanilla' server using the 'vanilla' operations.
+ 
+The description that follows is broken into 3 parts: a functional
+description of the dynamic update facility, a functional description of
+the T_UNSPEC facility, and a discussion of the implementation of
+dynamic updates.  The implementation description is mostly intended for
+those who want to make future enhancements (especially the addition of
+a good authentication mechanism).  If you make enhancements, I would be
+interested in hearing about them.
+ 
+ 
+ 
+ 
+ 
+			1. Dynamic Update Facility
+ 
+I added this code in conjunction with my research into naming in large
+heterogeneous systems.  For the purposes of this research, I ignored
+security issues.  In other words, no authentication/authorization
+mechanism exists to control updates.  Authentication will hopefully be
+addressed at some future point (although probably not by me). In the
+mean time, BIND Internet name servers (as opposed to "private" name
+server networks operating with their own port numbers, as I use in my
+research) should be compiled *without* -DALLOW_UPDATES, so that the
+integrity of the Internet name database won't be compromised by this
+code.
+ 
+ 
+There are 5 different dynamic update interfaces:
+	UPDATEA  - add a resource record
+	UPDATED  - delete a specific resource record
+	UPDATEDA - delete all named resource records
+	UPDATEM  - modify a specific resource record
+	UPDATEMA - modify all named resource records
+ 
+These all work through the normal resolver interface, i.e., these
+interfaces are opcodes, and the data in the buffers passed to
+res_mkquery must conform to what is expected for the particular
+operation (see the #ifdef ALLOW_UPDATES extensions to nstest.c for
+example usage).
+ 
+UPDATEM is logically equivalent to an UPDATED followed by an UPDATEA,
+except that the updates occur atomically at the primary server (as
+usual with Domain servers, secondaries may become temporarily
+inconsistent).  The difference between UPDATED and UPDATEDA is that the
+latter allows you to delete all RRs associated with a name; similarly
+for UPDATEM and UPDATEMA.  The reason for the UPDATE{D,M}A interfaces
+is two-fold:
+ 
+	1. Sometimes you want to delete/modify some data, but you know you'll
+	   only have a single RR for that data; in such a case, it's more
+	   convenient to delete/modify the RR by just giving the name;
+	   otherwise, you would have to first look it up, and then
+	   delete/modify it.
+ 
+	2. It is sometimes useful to be able to delete/modify multiple RRs
+	   this way, since one can then perform the operation atomically.
+	   Otherwise, one would have to delete/modify the RRs one-by-one.
+ 
+One additional point to note about UPDATEMA is that it will return a
+success status if there were *zero* or more RRs associated with the given
+name (and the RR add succeeds), whereas UPDATEM, UPDATED, and UPDATEDA
+will return a success status if there were *one* or more RRs associated
+with the given name.  The reason for the difference is to handle the
+(probably common) case where what you want to do is set a particular
+name to contain a single RR, irrespective of whether or not it was
+already set.
+ 
+ 
+ 
+ 
+			2. T_UNSPEC Facility
+ 
+Type T_UNSPEC allows you to store data whose layout BIND doesn't
+understand.  Data of this type is not marshalled (i.e., converted
+between host and network representation, as is done, for example, with
+Internet addresses) by BIND, so it is up to the client to make sure
+things work out ok w.r.t. heterogeneous data representations.  The way
+I use this type is to have the client marshal data, store it, retrieve
+it, and demarshal it.  This way I can store arbitrary data in BIND
+without having to add new code for each specific type.
+ 
+T_UNSPEC data is dumped in an ASCII-encoded, checksummed format so
+that, although it's not human-readable, it at least doesn't fill the
+dump file with unprintable characters.
+ 
+Type T_UNSPEC is important for my research environment, where
+potentially lots of people want to store data in the name service, and
+each person's data looks different.  Instead of having BIND understand
+the format of each of their data types, the clients define marshaling
+routines and pass buffers of marshalled data to BIND; BIND never tries
+to demarshal the data...it just holds on to it, and gives it back to
+the client when the client requests it, and the client must then
+demarshal it.
+ 
+The Xerox Network System's name service (the Clearinghouse) works this
+way.  The reason 'vanilla' BIND understands the format of all the data
+it holds is probably that BIND is tailored for a very specific
+application, and wants to make sure the data it holds makes sense (and,
+for some types, BIND needs to take additional action depending on the
+data's semantics).  For more general purpose name services (like the
+Clearinghouse and my usage of BIND), this approach is less tractable.
+ 
+See the #ifdef ALLOW_T_UNSPEC extensions to nstest.c for example usage of
+this type.
+ 
+ 
+ 
+ 
+ 
+ 
+		3. Dynamic Update Implementation Description
+ 
+This section is divided into 3 subsections: General Discussion,
+Miscellaneous Points, and Known Defects.
+ 
+ 
+ 
+ 
+		3.1 General Discussion
+ 
+The basic scheme is this: When an update message arrives, a call is
+made to InitDynUpdate, which first looks up the SOA record for the zone
+the update affects.  If this is the primary server for that zone, we do
+the update and then update the zone serial number (so that secondaries
+will refresh later).  If this is a secondary server, we forward the
+update to the primary, and if that's successful, we update our copy
+afterwards.  If it's neither, we refuse the update.  (One might think
+to try to propagate the update to an authoritative server; I figured
+that updates will probably be most likely within an administrative
+domain anyway; this could be changed if someone has strong feelings
+about it).
+ 
+Note that this mechanism disallows updates when the primary is
+down, preserving the Domain scheme's consistency requirements,
+but making the primary a critical point for updates.  This seemed
+reasonable to me because
+	1. Alternative schemes must deal with potentially complex
+	   situations involving merging of inconsistent secondary
+	   updates
+	2. Updates are presumed to be rare relative to read accesses,
+	   so this increased restrictiveness for updates over reads is
+	   probably not critical
+ 
+I have placed comments through out the code, so it shouldn't be
+too hard to see what I did.  The majority of the processing is in
+doupdate() and InitDynUpdate().  Also, I added a field to the zone
+struct, to keep track of when zones get updated, so that only changed
+zones get checkpointed.
+ 
+ 
+ 
+ 
+ 
+		3.2 Miscellaneous Points
+ 
+I use ns_maint to call zonedump() if the database changes, to
+provide a checkpointing mechanism.  I use the zone refresh times to
+set up ns_maint interrupts if there are either secondaries or
+primaries.  Hence, if there is a secondary, this interrupt can cause
+zoneref (as before), and if there is a primary, this interrupt can
+cause doadump.  I also checkpoint if needed before shutting down.
+ 
+You can force a server to checkpoint any changed zones by sending the
+maint signal (SIGALRM) to the process.  Otherwise it just checkpoints
+during maint. interrupts, or when being shutdown (with SIGTERM).
+Sending it the dump signal causes the database to be dumped into the
+(single) dump file, but doesn't checkpoint (i.e., update the boot
+files).  Note that the boot files will be overwritten with checkpoint
+files, so if you want to preserve the comments, you should keep copies
+of the original boot files separate from the versions that are actually
+used.
+ 
+I disallow T_SOA updates, for several reasons:
+	- T_SOA deletes at the primary wont be discovered by the secondaries
+	  until they try to request them at maint time, which will cause
+	  a failure
+	- the corresponding NS record would have to be deleted at the same
+	  time (atomically) to avoid various problems
+	- T_SOA updates would have to be done in the right order, or else
+	  the primary and secondaries will be out-of-sync for that zone.
+My feeling is that changing the zone topology is a weighty enough thing
+to do that it should involve changing the load file and reloading all
+affected servers.
+ 
+There are alot of places where bind exits due to catastrophic failures
+(mainly malloc failures).  I don't try to dump the database in these
+places because it's probably inconsistent anyway.  It's probably better
+to depend on the most recent dump.
+ 
+ 
+ 
+ 
+ 
+		3.2 Known Defects
+ 
+1. I put the following comment in nlookup (db_lookup.c):
+ 
+	Note: at this point, if np->n_data is NULL, we could be in one
+	of two situations: Either we have come across a name for which
+	all the RRs have been (dynamically) deleted, or else we have
+	come across a name which has no RRs associated with it because
+	it is just a place holder (e.g., EDU).  In the former case, we
+	would like to delete the namebuf, since it is no longer of use,
+	but in the latter case we need to hold on to it, so future
+	lookups that depend on it don't fail.  The only way I can see
+	of doing this is to always leave the namebufs around (although
+	then the memory usage continues to grow whenever names are
+	added, and can never shrink back down completely when all their
+	associated RRs are deleted).
+ 
+   Thus, there is a problem that the memory usage will keep growing for
+   the situation described.  You might just choose to ignore this
+   problem (since I don't see any good way out), since things probably
+   wont grow fast anyway (how many names are created and then deleted
+   during a single server incarnation, after all?)
+ 
+   The problem is that one can't delete old namebufs because one would
+   want to do it from db_update, but db_update calls nlookup to do the
+   actual work, and can't do it there, since we need to maintain place
+   holders.  One could make db_update not call nlookup, so we know it's
+   ok to delete the namebuf (since we know the call is part of a delete
+   call); but then there is code with alot of overlapping functionality
+   in the 2 routines.
+ 
+   This also causes another problem:  If you create a name and then do
+   UPDATEDA, all it's RRs get deleted, but the name remains; then, if you
+   do a lookup on that name later, the name is found in the hash table,
+   but no RRs are found for it.  It then forwards the query to itself (for
+   some reason), and then somehow decides there is no such domain, and then
+   returns (with the correct answer, but after going through extra work).
+   But the name remains, and each time it is looked up, we go through
+   these same steps.  This should be fixed, but I don't have time right
+   now (and the right answer seems to come back anyway, so it's good
+   enough for now).
+ 
+2. There are 2 problems that crop up when you store data (other than
+   T_SOA and T_NS records) in the root:
+   a. Can't get primary to doaxfr RRs other than SOA and NS to
+      secondary.
+   b. Upon checkpoint (zonedump), this data sometimes comes out after other
+      data in the root, so that (since the SOA and NS records have null
+      names), they will get interpreted as being records under the
+      other names upon the next boot up.  For example, if you have a
+      T_A record called ABC, the checkpoint may look like:
+	 $ORIGIN .
+	 ABC     IN      A       128.95.1.3
+	 99999999        IN      NS      UW-BORNEO.
+	 IN      SOA     UW-BORNEO. SCHWARTZ.CS.WASHINGTON.EDU.
+	 ( 50 3600 300 3600000 3600 )
+      Then when booting up the next time, the SOA and NS records get
+      interpreted as being called "ABC" rather than the null root
+      name.
+ 
+3. The secondary server caches the T_A RR for the primary, and hence when
+   it tries to ns_forw an update, it won't find the address of the primary
+   using nslookup unless that T_A RR is *also* stored in the main hashtable
+   (by putting it in a named.db file as well as the named.ca file).
+ 
diff --git a/usr.sbin/named/doc/misc/FAQ.1of2 b/usr.sbin/named/doc/misc/FAQ.1of2
new file mode 100644
index 00000000000..a522758424c
--- /dev/null
+++ b/usr.sbin/named/doc/misc/FAQ.1of2
@@ -0,0 +1,1602 @@
+Newsgroups: comp.protocols.tcp-ip.domains,comp.answers,news.answers
+Path: vixie!news1.digital.com!su-news-hub1.bbnplanet.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!cam-news-hub1.bbnplanet.com!news.mathworks.com!news.kei.com!uhog.mit.edu!rutgers!njitgw.njit.edu!hertz.njit.edu!cdp2582
+From: cdp2582@hertz.njit.edu (Chris Peckham)
+Subject: comp.protocols.tcp-ip.domains Frequently Asked Questions (FAQ) (Part 1 of 2)
+Message-ID: <cptd-faq-1-849940949@njit.edu>
+Followup-To: comp.protocols.tcp-ip.domains
+Originator: cdp2582@hertz.njit.edu
+Keywords: BIND,DOMAIN,DNS
+Sender: news@njit.edu
+Supersedes: <cptd-faq-1-847336183@njit.edu>
+Nntp-Posting-Host: hertz.njit.edu
+X-Posting-Frequency: posted during the first week of each month
+Reply-To: domain-faq@njit.edu (comp.protocols.tcp-ip.domains FAQ comments)
+Organization: NJIT.EDU - New Jersey Institute of Technology, Newark, NJ, USA
+Date: Sat, 7 Dec 1996 06:42:36 GMT
+Approved: news-answers-request@MIT.EDU
+Expires: Sat 11 Jan 97 02:42:29 EDT
+Lines: 1582
+Xref: vixie comp.protocols.tcp-ip.domains:12904 comp.answers:22440 news.answers:85682
+
+Posted-By: auto-faq 3.1.1.2
+Archive-name: internet/tcp-ip/domains-faq/part1
+Revision: 1.14 1996/12/07 06:42:05
+
+
+Note that this posting has been split into two parts because of its size.
+
+$Id: FAQ.1of2,v 1.1 1998/05/22 02:45:42 millert Exp $
+
+A new version of this document appears monthly.  If this copy is more
+than a month old it may be out of date.
+
+This FAQ is edited and maintained by Chris Peckham, <cdp@pfmc.net>.  The
+most recently posted version may be found for anonymous ftp from
+
+rtfm.mit.edu : /pub/usenet/news.answers/internet/tcp-ip/domains-faq
+
+It is also available in HTML from
+http://www.users.pfmc.net/~cdp/cptd-faq/.
+
+If you can contribute any answers for items in the TODO section, please do
+so by sending e-mail to <domain-faq@pfmc.net> !  If you know of any items
+that  are not included and you feel that they should be,  send the
+relevant information to <domain-faq@pfmc.net>.
+
+===============================================================================
+
+Index
+
+ Section 1.  TO DO / UPDATES
+ Q1.1        Contributions needed 
+ Q1.2        UPDATES / Changes since last posting 
+
+ Section 2.  INTRODUCTION / MISCELLANEOUS
+ Q2.1        What is this newsgroup ?
+ Q2.2        More information
+ Q2.3        What is BIND  ?
+ Q2.4        What is the difference between BIND and DNS ?
+ Q2.5        Where is the latest version of BIND located ?
+ Q2.6        How can I find the path taken between two systems/domains ?
+ Q2.7        How do you find the hostname given the TCP-IP address ?
+ Q2.8        How do I register a domain ?
+ Q2.9        How can I change the IP address of our server ?
+ Q2.10       Issues when changing your domain name
+ Q2.11       How memory and CPU does DNS use ?
+ Q2.12       Other things to consider when planning your servers  
+ Q2.13       Proper way to get NS and reverse IP records into DNS
+ Q2.14       How do I get my address assigned from the NIC ?
+ Q2.15       Is there a block of private IP addresses I can use?
+ Q2.16       Does BIND cache negative answers (failed DNS lookups) ?
+ Q2.17       What does an NS record really do ?
+ Q2.18       DNS ports
+ Q2.19       What is the cache file 
+ Q2.20       Obtaining the latest cache file
+ Q2.21       Selecting a nameserver/root cache
+ Q2.22       InterNIC and domain names
+
+ Section 3.  UTILITIES 
+ Q3.1        Utilities to administer DNS zone files
+ Q3.2        DIG - Domain Internet Groper
+ Q3.3        DNS packet analyser
+ Q3.4        host
+ Q3.5        How can I use DNS information in my program?
+ Q3.6        A source of information relating to DNS
+
+ Section 4.  DEFINITIONS  
+ Q4.1        TCP/IP Host Naming Conventions
+ Q4.2        What are slaves and forwarders ?
+ Q4.3        When is a server authoritative?
+ Q4.4        My server does not consider itself authoritative !
+ Q4.5        NS records don't configure servers as authoritative ?
+ Q4.6        underscore in host-/domainnames
+ Q4.7        What is lame delegation ?
+ Q4.8        How can I see if the server is "lame" ?
+ Q4.9        What does opt-class field in a zone file do?
+ Q4.10       Top level domains
+ Q4.11       Classes of networks
+ Q4.12       What is CIDR ?
+ Q4.13       What is the rule for glue ?
+
+ Section 5.  CONFIGURATION
+ Q5.1        Changing a Secondary server to a Primary server ?
+ Q5.2        Moving a Primary server to another server
+ Q5.3        How do I subnet a Class B Address ?
+ Q5.4        Subnetted domain name service
+ Q5.5        Recommended format/style of DNS files
+ Q5.6        DNS on a system not connected to the Internet
+ Q5.7        Multiple Domain configuration
+ Q5.8        wildcard MX records
+ Q5.9        How do you identify a wildcard MX record ?
+ Q5.10       Why are fully qualified domain names recommended ?
+ Q5.11       Distributing load using named
+ Q5.12       Order of returned records
+ Q5.13       resolv.conf
+ Q5.14       How do I delegate authority for sub-domains ?
+ Q5.15       DNS instead of NIS on a Sun OS 4.1.x system
+ Q5.16       Patches to add functionality to BIND 
+ Q5.17       How to serve multiple domains from one server
+
+ Section 6.  PROBLEMS
+ Q6.1        No address for root server
+ Q6.2        Error - No Root Nameservers for Class XX
+ Q6.3        Bind 4.9.x and MX querying?
+ Q6.4        Do I need to define an A record for localhost ?
+ Q6.5        MX records, CNAMES and A records for MX targets
+ Q6.6        Can an NS record point to a CNAME ?
+ Q6.7        Nameserver forgets own A record
+ Q6.8        General problems (core dumps !)
+ Q6.9        malloc and DECstations
+ Q6.10       Can't resolve names without a "."
+ Q6.11       Err/TO errors being reported
+ Q6.12       Why does swapping kill BIND ?
+
+ Section 7.  ACKNOWLEDGEMENTS
+ Q7.1        How is this FAQ generated ?
+ Q7.2        What formats are available ?
+ Q7.3        Contributors
+
+===============================================================================
+
+Section 1.  TO DO / UPDATES
+
+ Q1.1        Contributions needed 
+ Q1.2        UPDATES / Changes since last posting 
+
+-----------------------------------------------------------------------------
+
+Question 1.1.  Contributions needed
+
+Date: Fri Dec  6 00:40:00 EST 1996
+
+* Expand the slave/forward section
+
+-----------------------------------------------------------------------------
+
+Question 1.2.  UPDATES / Changes since last posting
+
+Date: Fri Dec  6 00:40:00 EST 1996
+
+* The FAQ is now maintained in BFNN (Bizzare format with No Name).  This
+  allows me to create ASCII, HTML, and GNU info (postscript coming soon)
+  from one source file.
+* References to 4.9.4 changed to 4.9.5.
+* memory/CPU usage question - removed uunet map reference.  Not there...
+* Minor edits of information and questions for new format.
+* How do I delegate authority for sub-domains ? - edited answer
+
+===============================================================================
+
+Section 2.  INTRODUCTION / MISCELLANEOUS
+
+ Q2.1        What is this newsgroup ?
+ Q2.2        More information
+ Q2.3        What is BIND  ?
+ Q2.4        What is the difference between BIND and DNS ?
+ Q2.5        Where is the latest version of BIND located ?
+ Q2.6        How can I find the path taken between two systems/domains ?
+ Q2.7        How do you find the hostname given the TCP-IP address ?
+ Q2.8        How do I register a domain ?
+ Q2.9        How can I change the IP address of our server ?
+ Q2.10       Issues when changing your domain name
+ Q2.11       How memory and CPU does DNS use ?
+ Q2.12       Other things to consider when planning your servers  
+ Q2.13       Proper way to get NS and reverse IP records into DNS
+ Q2.14       How do I get my address assigned from the NIC ?
+ Q2.15       Is there a block of private IP addresses I can use?
+ Q2.16       Does BIND cache negative answers (failed DNS lookups) ?
+ Q2.17       What does an NS record really do ?
+ Q2.18       DNS ports
+ Q2.19       What is the cache file 
+ Q2.20       Obtaining the latest cache file
+ Q2.21       Selecting a nameserver/root cache
+ Q2.22       InterNIC and domain names
+
+-----------------------------------------------------------------------------
+
+Question 2.1.  What is this newsgroup ?
+
+Date: Thu Dec  1 11:08:28 EST 1994
+
+comp.protocols.tcp-ip.domains is the usenet newsgroup for discussion on
+issues relating to the Domain Name System (DNS).
+
+This newsgroup is not for issues directly relating to IP routing and
+addressing.  Issues of that nature should be directed towards
+comp.protocols.tcp-ip.
+
+-----------------------------------------------------------------------------
+
+Question 2.2.  More information
+
+Date: Fri Dec  6 00:41:03 EST 1996
+
+You can find more information concerning DNS in the following places:
+
+* The BOG (BIND Operations Guide) - in the BIND distribution
+* The FAQ included with BIND 4.9.5 in doc/misc/FAQ
+* DNS and BIND by Albitz and Liu (an O'Reilly & Associates Nutshell
+  handbook)
+* A number of RFCs (920, 974, 1032, 1034, 1101, 1123, 1178, 1183, 1348,
+  1535, 1536, 1537, 1591, 1706, 1712, 1713, 1912, 1918)
+* The DNS Resources Directory (DNSRD) http://www.dns.net/dnsrd/
+* If you are having troubles relating to sendmail and DNS, you may wish to
+  refer to the USEnet newsgroup comp.mail.sendmail and/or the FAQ for that
+  newsgroup which may be found for anonymous ftp at rtfm.mit.edu :
+  /pub/usenet/news.answers/mail/sendmail-faq
+* Information concerning some frequently asked questions relating to the
+  Internet (i.e., what is the InterNIC, what is an RFC, what is the IETF,
+  etc) may be found for anonymous ftp from ds.internic.net : /fyi/fyi4.txt
+  A version may also be obtained with the URL
+  gopher://ds.internic.net/00/fyi/fyi4.txt.
+* Information on performing an initial installation of BIND may be found
+  using the DNS Resources Directory at
+  http://www.dns.net/dnsrd/docs/basic.txt
+* Three other USEnet newsgroups:
+
+  * comp.protocols.dns.bind
+  * comp.protocols.dns.ops
+  * comp.protocols.dns.std
+
+-----------------------------------------------------------------------------
+
+Question 2.3.  What is BIND  ?
+
+Date: Tue Sep 10 23:15:58 EDT 1996
+
+From the BOG Introduction -
+
+The Berkeley Internet Name Domain (BIND)  implements an  Internet name
+server  for the BSD operating system.  The BIND consists of  a server (or
+``daemon'')  and  a resolver  library.   A  name server is a network
+service that enables clients to name  resources or  objects and share this
+information with other objects in the network.  This in effect is a
+distributed  data  base  system  for objects  in a computer network.  BIND
+is fully integrated into BSD (4.3 and later releases) network  programs
+for use  in  storing and  retrieving host names and address.  The system
+administrator can configure the system to  use BIND as  a replacement to
+the older host table lookup of information in the network hosts file
+/etc/hosts.   The default configuration for BSD uses BIND.
+
+-----------------------------------------------------------------------------
+
+Question 2.4.  What is the difference between BIND and DNS ?
+
+Date: Tue Sep 10 23:15:58 EDT 1996
+
+(text provided by Andras Salamon) DNS is the Domain Name System, a set of
+protocols for a distributed database that was originally designed to
+replace /etc/hosts files.  DNS is most commonly used by applications to
+translate domain names of hosts to IP addresses.  A client of the DNS is
+called a resolver; resolvers are typically located in the application
+layer of the networking software of each TCP/IP capable machine.  Users
+typically do not interact directly with the resolver.  Resolvers query the
+DNS by directing queries at name servers that contain parts of the
+distributed database that is accessed by using the DNS protocols.  In
+common usage, `the DNS' usually refers just to the data in the database.
+
+BIND (Berkeley Internet Name Domain) is an implementation of DNS, both
+server and client.  Development of BIND is funded by the Internet Software
+Consortium and is coordinated by Paul Vixie.  BIND has been ported to
+Windows NT and VMS, but is most often found on Unix.  BIND source code is
+freely available and very complex; most of the development on the DNS
+protocols is based on this code; and most Unix vendors ship BIND-derived
+DNS implementations.  As a result, the BIND name server is the most widely
+used name server on the Internet.  In common usage, `BIND' usually refers
+to the name server that is part of the BIND distribution, and sometimes to
+name servers in general (whether BIND-derived or not).
+
+-----------------------------------------------------------------------------
+
+Question 2.5.  Where is the latest version of BIND located ?
+
+Fri Dec  6 00:23:19 EST 1996
+
+This information may be found at http://www.vix.com/isc/bind.html
+
+At this time, BIND version of 4.9.5 may be found for anonymous ftp from
+
+ftp.vix.com : /pub/bind/release/4.9.5/bind-4.9.5-REL.tar.gz
+
+Other sites that officially mirror the BIND distribution are
+
+* bind.fit.qut.edu.au : /pub/bind
+* ftp.funet.fi : /pub/unix/tcpip/dns/bind
+* ftp.univ-lyon1.fr : /pub/mirrors/unix/bind
+* ftp.oleane.net : /pub/mirrors/unix/bind
+* ftp.ucr.ac.cr : /pub/Unix/dns/bind
+* ftp.luth.se : /pub/unix/dns/bind/beta
+
+You may need GNU zip, Larry Wall's patch program (if there are any patch
+files), and a C compiler to get BIND running from the above mentioned
+source.
+
+GNU zip is available for anonymous ftp from
+
+prep.ai.mit.edu : /pub/gnu/gzip-1.2.4.tar
+
+patch is available for anonymous ftp from
+
+prep.ai.mit.edu : /pub/gnu/patch-2.1.tar.gz
+
+A version of BIND for Windows NT is available for anonymous ftp from
+
+ftp.vix.com : /pub/bind/release/4.9.5/contrib/ntdns495relbin.zip
+
+and
+
+ftp.vix.com : /pub/bind/release/4.9.5/contrib/ntbind495rel.zip
+
+-----------------------------------------------------------------------------
+
+Question 2.6.  How can I find the path taken between two systems/domains ?
+
+Date: Fri Dec  6 00:10:31 EST 1996
+
+On a Unix system, use traceroute.  If it is not available to you, you may
+obtain the source source for 'traceroute', compile it and install it on
+your system.
+
+One version of this program with additional functionality may be found for
+anonymous ftp from
+
+ftp.nikhef.nl : /pub/network/traceroute.tar.Z
+
+Another version may be found for anonymous ftp from
+
+ftp.psc.edu : /pub/net_tools/traceroute.tar
+
+-----------------------------------------------------------------------------
+
+Question 2.7.  How do you find the hostname given the TCP-IP address ?
+
+Date: Thu Dec  1 09:55:24 EST 1994
+
+For an address a.b.c.d you can always do:
+
+         % nslookup
+         > set q=ptr
+         > d.c.b.a.in-addr.arpa.
+
+Most newer version of nslookup (since 4.8.3) will recognize an address, so
+you can just say:
+
+         % nslookup a.b.c.d
+
+DiG will work like this also:
+
+         % dig -x a.b.c.d
+
+host from the contrib/host from the bind distribution may also be used.
+
+-----------------------------------------------------------------------------
+
+Question 2.8.  How do I register a domain ?
+
+Date: Wed Sep  4 23:59:42 EDT 1996
+
+You can talk to your Internet Service Provider (ISP).  They can submit the
+registration for you.  If you are not going to be directly connected, they
+should be able to offer MX records for your domain for mail delivery (so
+that mail sent to the new domain will be sent to your "standard" account).
+In the case where the registration is done by the organization itself, it
+still makes the whole process much easier if the ISP is approached for
+secondary servers _before_ the InterNIC is approached for registration.
+
+For information about making the registration yourself, look to the
+InterNIC  (or other similar organization).
+
+* anonymout ftp from internic.net : /templates
+* gopher://rs.internic.net/
+* http://rs.internic.net/reg/reg-forms.html
+* http://www.ripe.net/
+
+You will need at least two domain name servers when you register your
+domain.  Many ISP's are willing to provide primary and/or secondary name
+service for their customers.
+
+Please note that the InterNIC is now charging a fee for domain names    in
+the "COM", "ORG", and "NET".  More information may be found from  the
+Internic at
+
+http://rs.internic.net/domain-info/fee-policy.html
+
+Many times, registration of a domain name can be initiated by sending
+e-mail to the zone contact. You can obtain the contact in the  SOA record
+for the country, or in a whois server:
+
+         $ nslookup -type=SOA fr.
+         origin = ns1.nic.fr
+         mail addr = nic.nic.fr
+         ...
+
+The mail address to contact in this case is 'nic@nic.fr' (you must
+substitute an '@' for the first dot in the mail addr field).
+
+An alternate method to obtain the e-mail address of the national NIC is
+the 'whois' server at InterNIC.
+
+You may be requested to make your request to another email address or
+using a certain information template/application.
+
+-----------------------------------------------------------------------------
+
+Question 2.9.  How can I change the IP address of our server ?
+
+Date: Sun May  5 22:46:28 EDT 1996
+
+(From Mark Andrews) Before the move.
+
+* Ensure you are running a modern nameserver. BIND 4.9.3-REL + Patch1 is a
+  good choice.
+* Inform all your secondaries that you are going to change.  Have them
+  install both the current and new addresses in their named.boot's.
+* Drop the ttl of the A's associated with the nameserver to something
+  small (5 min is usually good).
+* Drop the refesh and retry times of the zone containing the  forward
+  records for the server.
+* Configure the new reverse zone before the move and make sure it is
+  operational.
+* On the day of the move add the new A record(s) for the server.  Don't
+  forget to have these added to parent domains. You will look like you are
+  multihomed with one interface dead.
+
+Move the machine after gracefully terminating any other services it is
+offering. Then,
+
+* Fixup the A's, ttl, refresh and retry counters.  (If you are running an
+  all server EDIT out all references to the old addresses in the cache
+  files).
+* Inform all the secondaries the move is complete.
+* Inform the parents of all zones you are primary of the new NS/A pairs
+  for the relevent zones.
+* Inform all the administators of zones you are secondaring that the
+  machine  has moved.
+* For good measure update the serial no for all zones you are primary for.
+  This will flush out old A's.
+
+-----------------------------------------------------------------------------
+
+Question 2.10.  Issues when changing your domain name
+
+Date: Sun Nov 27 23:32:41 EST 1994
+
+If you are changing your domain name from abc.foobar.com to foobar.net,
+the forward zones are easy and there are a number of ways to do it.   One
+way is the following:
+
+Have a single db file for the 2 domains, and have a single machine be the
+primary server for both abc.foobar.com and foobar.net.
+
+To resolve the host foo in both domains, use a single zone file which
+merely uses this for the host:
+
+foo             IN      A       1.2.3.4
+
+Use a "@" wherever the domain would be used ie for the SOA:
+
+@               IN      SOA     (...
+
+Then use this pair of lines in your named.boot:
+
+primary         abc.foobar.com  db.foobar
+primary         foobar.net      db.foobar
+
+The reverse zones should either contain PTRs to both names, or to
+whichever name you believe to be canonical currently.
+
+-----------------------------------------------------------------------------
+
+Question 2.11.  How memory and CPU does DNS use ?
+
+Date: Fri Dec  6 01:07:56 EST 1996
+
+It can use quite a bit !  The main thing that BIND needs is memory.   It
+uses very little CPU or network bandwidth.   The main  considerations to
+keep in mind when planning are:
+
+* How many zones do you have and how large are they ?
+* How many clients do you expect to serve and how active are they ?
+
+As an example, here is a snapshot of memory usage from CSIRO Division  of
+Mathematics and Statistics, Australia
+
+      Named takes several days to stabalize its memory usage.
+ 
+      Our main server stabalises at ~10Mb. It takes about 3 days to
+      reach this size from 6 M at startup. This is under Sun OS 4.1.3U1.
+
+As another example, here is the configuration of ns.uu.net (from late
+1994):
+
+      ns.uu.net only does nameservice.  It is running a version of BIND
+      4.9.3 on a Sun Classic with 96 MB of RAM, 220 MB of swap (remember
+      that Sun OS will reserve swap for each fork, even if it is not needed)
+      running Sun OS 4.1.3_U1.
+
+      Joseph Malcolm, of Alternet, states that named generally hovers at 
+      5-10% of the CPU, except after a reload, when it eats it all. 
+
+-----------------------------------------------------------------------------
+
+Question 2.12.  Other things to consider when planning your servers
+
+Date: Mon Jan  2 14:24:51 EST 1995
+
+When making the plans to set up your servers, you may want to also
+consider the following issues:
+
+        A) Server O/S limitations/capacities (which tend to be widely
+           divergent from vendor to vendor)
+        B) Client resolver behavior (even more widely divergent)
+        C) Expected query response time
+        D) Redundancy
+        E) Desired speed of change propagation
+        F) Network bandwidth availability
+        G) Number of zones/subdomain-levels desired
+        H) Richness of data stored (redundant MX records? HINFO records?)
+        I) Ease of administration desired
+        J) Network topology (impacts reverse-zone volume)
+ 
+  Assuming a best-possible case for the factors above, particularly (A), (B),
+  (C), (F), (G) & (H), it would be possible to run a 1000-node domain
+  using a single lowly 25 or 40 MHz 386 PC with a fairly modest amount of RAM 
+  by today's standards, e.g. 4 or 8 Meg.   However, this configuration would 
+  be slow, unreliable, and would provide no functionality beyond your basic 
+  address-to-name and name-to-address mappings.
+ 
+  Beyond that baseline case, depending on what factors listed above,
+  you may want look at other strategies, such splitting up the DNS
+  traffic among several machines strategically located, possibly larger ones,
+  and/or subdividing your domain itself. There are many options, tradeoffs, 
+  and DNS architectural paradigms from which to choose.
+-----------------------------------------------------------------------------
+
+Question 2.13.  Proper way to get NS and reverse IP records into DNS
+
+Date: Mon Jan  2 13:03:53 EST 1995
+
+Reverse domain registration is separate from forward domain registration.
+Blocks of network addresses have been delegated by the InterNIC.  Check if
+your network a.b.c.0 is in such a block by using nslookup:
+
+   nslookup -type=soa c.b.a.in-addr.arpa.
+   nslookup -type=soa b.a.in-addr.arpa.
+   nslookup -type=soa a.in-addr.arpa.
+
+One of the above should give you the information you are looking for (the
+others will return with an error something like `*** No start of authority
+(SOA) records available for ...') This will give you the email address of
+the person to whom you should address your change request.
+
+If none of these works, your network probably has not been delegated by
+the InterNIC and you need to contact them directly.
+
+CIDR has meant that the registration is delegated, but registration of
+in-addr.arpa has always been separate from forward zones - and for good
+reason - in that the forward and reverse zones may have different
+policies, contents etc, may be served by a different set of nameservers,
+and exist at different times (usually only at point of creation).  There
+isn't a one-to-one mapping between the two, so merging the registration
+would probably cause more problems than people forgetting/not-knowing that
+they had to register in-addr.arpa zones separately.  For example, there
+are organizations that have hundreds of networks and two or more domains,
+with a sprinkling of machines from each network in each of the domains.
+
+-----------------------------------------------------------------------------
+
+Question 2.14.  How do I get my address assigned from the NIC ?
+
+Date: Fri Dec  6 01:11:34 EST 1996
+
+You should probably ask your Internet provider to give you an address.
+These days, addresses are being distributed through the providers, so that
+they can assign adjacent blocks of addresses to sites that go through the
+same provider, to permit more efficient routing on the backbones.
+
+Unless you have thousands of hosts, you probably won't be able to get a
+class B these days.  Instead, you can get a series of class C networks.
+Large requests will be queried, so be ready to provide a network plan if
+you ask for more than 16 class C networks.
+
+If you can't do this through your Internet provider, you can look for a
+subnet registration form on rs.internic.net.  See the answer in this FAQ
+to the question "How do I register a domain" for a URL to these forms.
+
+-----------------------------------------------------------------------------
+
+Question 2.15.  Is there a block of private IP addresses I can use?
+
+Date: Sun May  5 23:02:49 EDT 1996
+
+Yes there is.  Please refer to RFC 1918:
+
+   1918 Address Allocation for Private Internets. Y. Rekhter, B.
+        Moskowitz, D. Karrenberg, G. de Groot, & E. Lear. February 1996.
+        (Format: TXT=22270 bytes)
+ 
+RFC 1918 documents the allocation of the following addresses for use by
+``private internets'':
+
+        10.0.0.0        -   10.255.255.255
+        172.16.0.0      -   172.31.255.255
+        192.168.0.0     -   192.168.255.255
+
+-----------------------------------------------------------------------------
+
+Question 2.16.  Does BIND cache negative answers (failed DNS lookups) ?
+
+Date: Mon Jan  2 13:55:50 EST 1995
+
+Yes, BIND 4.9.3 and more recent versions will cache negative answers.
+
+-----------------------------------------------------------------------------
+
+Question 2.17.  What does an NS record really do ?
+
+Date: Wed Sep  4 22:52:18 EDT 1996
+
+The NS records in your zone data file pointing to the zone's name  servers
+(as opposed to the servers of delegated subdomains) don't do  much.
+They're essentially unused, though they are returned in the  authority
+section of reply packets from your name servers.
+
+However, the NS records in the zone file of the parent domain are used to
+find the right servers to query for the zone in question.  These records
+are more important than the records in the zone itself.
+
+-----------------------------------------------------------------------------
+
+Question 2.18.  DNS ports
+
+Date: Fri Feb 10 15:40:10 EST 1995
+
+The following table shows what TCP/UDP ports DNS uses to send and  receive
+queries:
+
+   Prot Src   Dst   Use
+   udp  53    53    Queries between servers (eg, recursive queries)
+                    Replies to above
+   tcp  53    53    Queries with long replies between servers, zone 
+                    transfers Replies to above
+   udp  >1023 53    Client queries (sendmail, nslookup, etc ...)
+   udp  53    >1023 Replies to above
+   tcp  >1023 53    Client queries with long replies
+   tcp  53    >1023 Replies to above
+
+   Note: >1023 is for non-priv ports on Un*x clients. On other client 
+         types, the limit may be more or less.
+
+Another point to keep in mind when designing filters for DNS is that a DNS
+server uses port 53 both as the source and destination for it's queries.
+So, a client queries an initial server from an unreserved port number to
+UDP port 53.  If the server needs to query another server to get the
+required info, it sends a UDP query to that server with both source and
+destination ports set to 53.  The response is then sent with the same
+src=53 dest=53 to the first server which then responds to the original
+client from port 53 to the original source port number.
+
+The point of all this is that putting in filters to only allow UDP between
+a high port and port 53 will not work correctly, you must also allow the
+port 53 to port 53 UDP to get through.
+
+Also, ALL versions of BIND use TCP for queries in some cases.  The
+original query is tried using UDP.  If the response is longer than the
+allocated buffer, the resolver will retry the query using a TCP
+connection.  If you block access to TCP port 53 as suggested above, you
+may find that some things don't work.
+
+Newer version of BIND allow you to configure a list of IP addresses from
+which to allow zone transfers.  This mechanism can be used to prevent
+people from outside downloading your entire namespace.
+
+-----------------------------------------------------------------------------
+
+Question 2.19.  What is the cache file
+
+Date: Fri Dec  6 01:15:22 EST 1996
+
+From the "Name Server Operations Guide"
+
+      6.3.  Cache Initialization
+ 
+         6.3.1.  root.cache
+ 
+                 The name server needs to know the servers that
+            are  the  authoritative  name  servers for the root
+            domain of the network.  To do this we have to prime
+            the name server's cache with the addresses of these
+            higher authorities.  The location of this  file  is
+            specified  in  the  boot  file. ...
+
+-----------------------------------------------------------------------------
+
+Question 2.20.  Obtaining the latest cache file
+
+Date: Fri Dec  6 01:15:22 EST 1996
+
+If you have a version of dig running, you may obtain the information with
+the command
+
+      dig @a.root-servers.net. . ns
+
+A perl script to handle some possible problems when using this method
+from behind a firewall and that can also be used to periodically obtain
+the latest cache file was posted to comp.protocols.tcp-ip.domains  during
+early October, 1996.  It was posted with the subject "Keeping  db.cache
+current". It is available at
+http://www.users.pfmc.net/~cdp/cptd-faq/current_db_cache.txt.
+
+The latest cache file may also be obtained from the InterNIC via ftp  or
+gopher:
+
+      ;       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
+
+-----------------------------------------------------------------------------
+
+Question 2.21.  Selecting a nameserver/root cache
+
+Date: Mon Aug  5 22:54:11 EDT 1996
+
+Exactly how is the a root server selected from the root cache? Does the
+resolver attempt to pick the closest host or is it random or is it via
+sortlist-type workings?  If the root server selected is not available (for
+whatever reason), will the the query fail instead of attempting another
+root server in the list ?
+
+Every recursive BIND name server (that is, one which is willing to go out
+and find something for you if you ask it something it doesn't know) will
+remember the measured round trip time to each server it sends queries to.
+If it has a choice of several servers for some domain (like "." for
+example) it will use the one whose measured RTT is lowest.
+
+Since the measured RTT of all NS RRs starts at zero (0), every one gets
+tried one time.  Once all have responded, all RTT's will be nonzero, and
+the "fastest server" will get all queries henceforth, until it slows down
+for some reason.
+
+To promote dispersion and good recordkeeping, BIND will penalize the RTT
+by a little bit each time a server is reused, and it will penalize the RTT
+a _lot_ if it ever has to retransmit a query.  For a server to stay "#1",
+it has to keep on answering quickly and consistently.
+
+Note that this is something BIND does that the DNS Specification does not
+mention at all.  So other servers, those not based on BIND, might behave
+very differently.
+
+-----------------------------------------------------------------------------
+
+Question 2.22.  InterNIC and domain names
+
+Date: Sun Jun  2 11:23:49 EDT 1996
+
+The current InterNIC policy on what to do if someone wants to use a domain
+name that is already in use may be found at
+
+rs.internic.net : /policy/internic/internic-domain-4.txt
+
+or
+
+http://rs.internic.net/domain-info/internic-domain-4.html.
+
+The following information was submitted by Carl Oppedahl
+<oppedahl@patents.com> :
+
+If the jealous party happens to have a trademark registration, it is quite
+likely that the domain name owner will lose the domain name, even if they
+aren't infringing the trademark.  This presents a substantial risk of loss
+of a domain name on only 30 days' notice.  Anyone who is the manager of an
+Internet-connected site should be aware of this risk and should plan for
+it.
+
+See "How do I protect myself from loss of my domain name?" at
+http://www.patents.com/weblaw.sht#domloss.
+
+For an example of an ISP's battle to keep its domain name, see
+http://www.patents.com/nsi.sht.
+
+A compendium of information on the subject may be found at
+http://www.law.georgetown.edu/lc/internic/domain1.html.
+
+===============================================================================
+
+Section 3.  UTILITIES
+
+ Q3.1        Utilities to administer DNS zone files
+ Q3.2        DIG - Domain Internet Groper
+ Q3.3        DNS packet analyser
+ Q3.4        host
+ Q3.5        How can I use DNS information in my program?
+ Q3.6        A source of information relating to DNS
+
+-----------------------------------------------------------------------------
+
+Question 3.1.  Utilities to administer DNS zone files
+
+Date: Wed Sep  4 22:53:53 EDT 1996
+
+There are a few utilities available to ease the administration of zone
+files in the DNS.
+
+Two common ones are h2n and makezones.  Both are perl scripts.  h2n is
+used to convert host tables into zone data files.  It is available for
+anonymous ftp from
+
+ftp.uu.net : /published/oreilly/nutshell/dnsbind/dns.tar.Z
+
+makezones works from a single file that looks like a forward zone file,
+with some additional syntax for special cases.  It is included in the
+current BIND distribution.  The newest version is always available for
+anonymous ftp from
+
+ftp.cus.cam.ac.uk : /pub/software/programs/DNS/makezones
+
+More information may be found using the DNS Resources Directory
+
+http://www.dns.net/dnsrd/.
+
+-----------------------------------------------------------------------------
+
+Question 3.2.  DIG - Domain Internet Groper
+
+Date: Thu Dec  1 11:09:11 EST 1994
+
+The latest and greatest, official, accept-no-substitutes version of the
+Domain Internet Groper (DiG) is the one that comes with BIND.   Get the
+latest kit.
+
+-----------------------------------------------------------------------------
+
+Question 3.3.  DNS packet analyser
+
+Date: Wed Sep  4 23:43:57 EDT 1996
+
+There is a free ethernet analyser called Ethload available for PC's
+running DOS. The latest filename is ETHLD104.ZIP. It understands lots  of
+protocols including TCP/UDP. It'll look inside there and display
+DNS/BOOTP/ICMP packets etc. (Ed. note: something nice for someone to add
+to tcpdump ;^) ).  Depending on the ethernet controller it's given  it'll
+perform slightly differently. It handles NDIS/Novell/Packet  drivers.  It
+works best with Novell's promiscuous mode drivers.   A SimTel mirror site
+should have the program available for anonymous ftp.   One is
+
+ftp.coast.net : /SimTel/msdos/lan/ethld104.zip
+
+-----------------------------------------------------------------------------
+
+Question 3.4.  host
+
+Date: Sun Dec  4 21:15:38 EST 1994
+
+A section from the host man page:
+
+     host looks for information about Internet hosts and domain
+     names.  It gets this information from a set of intercon-
+     nected servers that are spread across the world. The infor-
+     mation is stored in the form of "resource records" belonging
+     to hierarchically organized "zones".
+
+     By default, the program simply converts between host names
+     and Internet addresses. However, with the -t, -a and -v
+     options, it can be used to find all of the information about
+     domain names that is maintained by the domain nameserver
+     system.  The information printed consists of various fields
+     of the associated resource records that were retrieved.
+
+     The arguments can be either host names (domain names) or
+     numeric Internet addresses.
+
+'host' is compatible with both BIND 4.9 and BIND 4.8
+
+'host' may be found in contrib/host in the BIND distribution.  The latest
+version always available for anonymous ftp from
+
+ftp.nikhef.nl : /pub/network/host.tar.Z
+
+It may also be found for anonymous ftp from
+
+ftp.uu.net : /networking/ip/dns/host.tar.Z
+
+-----------------------------------------------------------------------------
+
+Question 3.5.  How can I use DNS information in my program?
+
+Date: Fri Feb 10 15:25:11 EST 1995
+
+It depends on precisely what you want to do:
+
+* Consider whether you need to write a program at all.  It may well be
+  easier to write a shell program (e.g. using awk or perl) to parse the
+  output of dig, host or nslookup.
+* If all you need is names and addresses, there will probably be system
+  routines 'gethostbyname' and 'gethostbyaddr' to provide this
+  information.
+* If you need more details, then there are system routines (res_query and
+  res_search) to assist with making and sending DNS queries.  However,
+  these do not include a routine to parse the resulting answer (although
+  routines to assist in this task are provided).  There is a separate
+  library available that will take a DNS response and unpick it into its
+  constituent parts, returning a C structure that can be used by the
+  program.  The source for this library is available for anonymous ftp at
+
+  hpux.csc.liv.ac.uk : /hpux/Networking/Admin/resparse-1.2
+
+-----------------------------------------------------------------------------
+
+Question 3.6.  A source of information relating to DNS
+
+Date: Tue Nov  5 23:42:21 EST 1996
+
+You may find utilities and tools to help you manage your zone files
+(including WWW front-ends) in the "tools" section of the DNS  resources
+directory:
+
+http://www.dns.net/dnsrd/tools.html
+
+There are also a number of IP management tools available.  Data
+Communications had an article on the subject in Sept/Oct of 1996.  The
+tools mentioned in the article and a few others may be found at the
+following sites:
+
+* IP Address management, http://www.accugraph.com
+* IP-Track, http://www.on.com
+* NetID, http://www.isotro.com
+* QIP, http://www.quadritek.com
+* UName-It, http://www.esm.com
+
+===============================================================================
+
+Section 4.  DEFINITIONS
+
+ Q4.1        TCP/IP Host Naming Conventions
+ Q4.2        What are slaves and forwarders ?
+ Q4.3        When is a server authoritative?
+ Q4.4        My server does not consider itself authoritative !
+ Q4.5        NS records don't configure servers as authoritative ?
+ Q4.6        underscore in host-/domainnames
+ Q4.7        What is lame delegation ?
+ Q4.8        How can I see if the server is "lame" ?
+ Q4.9        What does opt-class field in a zone file do?
+ Q4.10       Top level domains
+ Q4.11       Classes of networks
+ Q4.12       What is CIDR ?
+ Q4.13       What is the rule for glue ?
+
+-----------------------------------------------------------------------------
+
+Question 4.1.  TCP/IP Host Naming Conventions
+
+Date: Mon Aug  5 22:49:46 EDT 1996
+
+One guide that may be used when naming hosts is RFC 1178, "Choosing a Name
+for Your Computer", which is available via anonymous FTP from
+
+ftp.internic.net : /rfc/rfc1178.txt
+
+RFCs (Request For Comments) are specifications and guidelines for how many
+aspects of TCP/IP and the Internet (should) work.  Most RFCs are fairly
+technical documents, and some have semantics that are hotly contested in
+the newsgroups.  But a few, like RFC 1178, are actually good to read for
+someone who's just starting along a TCP/IP path.
+
+-----------------------------------------------------------------------------
+
+Question 4.2.  What are slaves and forwarders ?
+
+Date: Thu Dec  1 10:32:43 EST 1994
+
+"forwarders" is a list of NS records that are _prepended_ to a list of NS
+records to query if the data is not available locally.  This allows a rich
+cache of records to be built up at a centralized location.  This is good
+for sites that have sporadic or very slow connections to the Internet.
+(demand dial-up, for example)  It's also just a good idea for very large
+distributed sites to increase the chance that you don't have to go off to
+the Internet to get an IP address. (sometimes for addresses across the
+street!)
+
+"slave" modifies this to say to replace the list of NS records with the
+forwarders entry, instead of prepending to it.  This is for firewalled
+environments, where the nameserver can't directly get out to the Internet
+at all.
+
+"slave" is meaningless (and invalid, in late-model BINDs) without
+"forwarders".  "forwarders" is an entry in named.boot, and therefore
+applies only to the nameserver (not to resolvers).
+
+-----------------------------------------------------------------------------
+
+Question 4.3.  When is a server authoritative?
+
+Date: Mon Jan  2 13:15:13 EST 1995
+
+In the case of BIND:
+
+* The server contains current data in files for the zone in question (Data
+  must be current for secondaries, as defined in the SOA)
+* The server is told that it is authoritative for the zone, by a 'primary'
+  or 'secondary' keyword in /etc/named.boot.
+* The server does an error-free load of the zone.
+
+-----------------------------------------------------------------------------
+
+Question 4.4.  My server does not consider itself authoritative !
+
+Date: Mon Jan  2 13:15:13 EST 1995
+
+The question was:
+
+  What if I have set up a DNS where there is an SOA record for
+  the domain, but the server still does not consider itself
+  authoritative.  (when using nslookup and set server=the correct machine.)
+  It seems that something is not matching up somewhere.  I suspect
+  that this is because the service provider has not given us control
+  over the IP numbers in our own domain, and so while the machine listed
+  has an A record for an address, there is no corresponding PTR record.
+With the answer:
+
+  That's possible too, but is unrelated to the first question.
+  You need to be delegated a zone before outside people will start
+  talking to your server.  However, a server can still be authoritative
+  for a zone even though it hasn't been delegated authority (it's just 
+  that only the people who use that as their server will see the data).
+    
+  A server may consider itself non-authoritative even though it's a
+  primary if there is a syntax error in the zone (see the list in the 
+  previous question).
+-----------------------------------------------------------------------------
+
+Question 4.5.  NS records don't configure servers as authoritative ?
+
+Date: Fri Dec  6 16:13:34 EST 1996
+
+Nope, delegation is a separate issue from authoritativeness.  You can
+still be authoritative, but not delegated.  (you can also be  delegated,
+but not authoritative -- that's a "lame delegation")
+
+-----------------------------------------------------------------------------
+
+Question 4.6.  underscore in host-/domainnames
+
+Date: Mon Aug  5 22:39:02 EDT 1996
+
+The question is "Are underscores are allowed in host- or domainnames" ?
+        RFC 1033 allows them.
+        RFC 1035 doesn't.
+        RFC 1123 doesn't.
+        dnswalk complains about them.
+
+
+Which RFC is the final authority these days?
+
+Actually RFC 1035 deals with names of machines or names of mail domains.
+i.e "_" is not permitted in a hostname or on the RHS of the "@" in
+local@domain.
+
+Underscore is permitted where ever the domain is NOT one of these types
+of addresses.
+
+In general the DNS mostly contains hostnames and mail domainnames.  This
+will change as new resource record types for authenticating DNS  queries
+start to appear.
+
+The latest version of 'host' checks for illegal characters in A/MX record
+names and the NS/MX target names.
+
+After saying all of that, remember that RFC 1123 is a Required Internet
+Standard (per RFC 1720), and RFC 1033 isn't.  Even  RFC 1035 isn't a
+required standard.  Therefore, RFC 1123 wins, no contest.
+
+From RFC 1123, Section 2.1
+
+   2.1  Host Names and Numbers
+
+      The syntax of a legal Internet host name was specified in RFC-952
+      [DNS:4].  One aspect of host name syntax is hereby changed: the
+      restriction on the first character is relaxed to allow either a
+      letter or a digit.  Host software MUST support this more liberal
+      syntax.
+
+   And described by Dave Barr in RFC1912:
+
+      Allowable characters in a label for a host name are only ASCII
+      letters, digits, and the `-' character.  Labels may not be all
+      numbers, but may have a leading digit  (e.g., 3com.com).  Labels must
+      end and begin only with a letter or digit.  See [RFC 1035] and [RFC
+      1123].  (Labels were initially restricted in [RFC 1035] to start with
+      a letter, and some older hosts still reportedly have problems with
+      the relaxation in [RFC 1123].)  Note there are some Internet
+      hostnames which violate this rule (411.org, 1776.com).
+
+Finally, one more piece of information (From Paul Vixie):
+
+   RFC 1034 says only that domain names have characters in them, though it
+   says so with enough fancy and indirection that it's hard to tell exactly.
+
+   Generally, for second level domains (i.e., something you would get from
+   InterNIC or from the US Domain Registrar and probably other ISO 3166
+   country code TLDs), RFC 952 is thought to apply.  RFC 952 was about host
+   names rather than domain names, but the rules seemed good enough.
+
+        <domainname> ::= <hname>
+
+        <hname> ::= <name>*["."<name>]
+        <name>  ::= <let>[*[<let-or-digit-or-hyphen>]<let-or-digit>]
+ 
+There has been a recent update on this subject which may be found in
+
+ftp.internic.net : /internet-drafts/draft-andrews-dns-hostnames-03.txt.
+
+-----------------------------------------------------------------------------
+
+Question 4.7.  What is lame delegation ?
+
+Date: Mon Aug  5 22:45:02 EDT 1996
+
+Two things are required for a lame delegation:
+
+* A nameserver X is delegated as authoritative for a zone.
+* Nameserver X is not performing nameservice for that zone.
+
+Try to think of a lame delegation as a long-term condition, brought about
+by a misconfiguration somewhere.  Bryan Beecher's 1992 LISA paper on lame
+delegations is good to read on this.  The problem really lies in
+misconfigured nameservers, not "lameness" brought about by transient
+outages.  The latter is common on the Internet and hard to avoid, while
+the former is correctable.
+
+In order to be performing nameservice for a zone, it must have (presumed
+correct) data for that zone, and it must be answering authoritatively to
+resolver queries for that zone.  (The AA bit is set in the flags section)
+
+The "classic" lame delegation case is when nameserver X is delegated as
+authoritative for domain Y, yet when you ask Y about X, it returns
+non-authoritative data.
+
+Here's an example that shows what happens most often (using dig, dnswalk,
+and doc to find).
+
+Let's say the domain bogus.com gets registered at the NIC and they have
+listed 2 primary name servers, both from their *upstream* provider:
+
+ bogus.com      IN      NS      ns.bogus.com
+ bogus.com      IN      NS      upstream.com
+ bogus.com      IN      NS      upstream1.com
+
+So the root servers have this info.  But when the admins at bogus.com
+actually set up their zone files they put something like:
+
+ bogus.com      IN      NS      upstream.com
+ bogus.com      IN      NS      upstream1.com
+
+So your name server may have the nameserver info cached (which it may have
+gotten from the root).  The root says "go ask ns.bogus.com" since they are
+authoritative
+
+This is usually from stuff being registered at the NIC (either nic.ddn.mil
+or rs.internic.net), and then updated later, but the folks who make the
+updates later never let the folks at the NIC know about it.
+
+-----------------------------------------------------------------------------
+
+Question 4.8.  How can I see if the server is "lame" ?
+
+Date: Mon Aug  5 22:45:02 EDT 1996
+
+Go to the authoritative servers one level up, and ask them who they think
+is authoritative, and then go ask each one of those delegees if they think
+that they themselves are authoritative.  If any responds "no", then you
+know who the lame delegation is, and who is delegating lamely to them.
+You can then send off a message to the administrators of the level above.
+
+The 'lamers' script from Byran Beecher really takes care of all this for
+you.  It parses the lame delegation notices from BIND's syslog and
+summarizes them for you.  It may be found in the contrib section of the
+latest BIND distribution.  The latest version is available for anonymous
+ftp from
+
+terminator.cc.umich.edu : /dns/lame-delegations/
+
+   If you want to actively check for lame delegations, you can use 'doc'
+and 'dnswalk'.   You can check things manually with 'dig'.
+
+The InterNIC recently announced a new lame delegation that will be in
+effect on 01 October, 1996.  Here is a summary:
+
+* After receipt/processing of a name registration template, and at random
+  intervals thereafter, the InterNIC will perform a DNS query  via UDP
+  Port 53 on domain names for an SOA response for the name  being
+  registered.
+* If the query of the domain name returns a non-authoritative response
+  from all the listed name servers, the query will be repeated four times
+  over the next 30 days at random intervals approximately 7 days apart,
+  with notification to all listed whois and nameserver contacts of the
+  possible pending deletion.  If at least one server answers correctly,
+  but one or more are lame, FYI notifications will be sent to all contacts
+  and checking will be discontinued.  Additionally, e-mail notices will be
+  provided to the contact for the name servers holding the delegation to
+  alert them to the "lame" condition.  Notifications will state explicitly
+  the consequences of not correcting the "lame" condition and will be
+  assigned a descriptive subject as follows:
+
+     Subject: Lame Delegation Notice: DOMAIN_NAME
+
+  The notification will include a timestamp for when the query was
+  performed.
+* If, following 30 days, the name servers still provide no SOA response,
+  the name will be placed in a "hold" status and the DNS information will
+  no longer be propagated.  The administrative contact will be notified by
+  postal mail and all whois contacts will be notified by e-mail, with
+  instructions for taking corrective action.
+* Following 60 days in a "hold" status, the name will be deleted and made
+  available for reregistration.  Notification of the final deletion will
+  be sent to the name server and domain name contacts  listed in the NIC
+  database.
+
+-----------------------------------------------------------------------------
+
+Question 4.9.  What does opt-class field in a zone file do?
+
+Date: Thu Dec  1 11:10:39 EST 1994
+
+This field is the address class.  From the BOG -
+
+      ...is the address class; currently, only one class
+      is supported: IN  for  internet  addresses  and  other
+      internet information.  Limited support is included for
+      the HS  class,  which  is  for  MIT/Athena  ``Hesiod''
+      information.
+-----------------------------------------------------------------------------
+
+Question 4.10.  Top level domains
+
+Date: Fri Dec  6 15:13:35 EST 1996
+
+A section from RFC 1591:
+
+   2.  The Top Level Structure of the Domain Names
+
+   In the Domain Name System (DNS) naming of computers there is a
+   hierarchy of names.  The root of system is unnamed.  There are a set
+   of what are called "top-level domain names" (TLDs).  These are the
+   generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT), and the two
+   letter country codes from ISO-3166.  It is extremely unlikely that
+   any other TLDs will be created.
+
+-----
+
+[ Ed note:  the ISO-3166 country codes may be found for anonymous ftp
+from:
+
+* ftp.isi.edu : /in-notes/iana/assignments/country-codes
+* ftp.ripe.net : /iso3166-codes
+
+]
+
+[ Ed note: Since the Internic started charging for registration services,
+(and for other reasons) there are a number of groups that want to offer
+an alternative to registering a domain under a "standard" TLD.  More
+information on some of these options may be found at:
+
+*      http://www.alternic.net/
+*      http://www.eu.org/
+*      http://www.ml.org/mljoin.html
+
+You may participate in one of the discussions on iTLD proposals at
+
+* To sign up: http://www.newdom.com/lists
+* Old postings: http://www.newdom.com/archive
+
+]
+
+-----
+
+   ...
+   Under each TLD may be created a hierarchy of names.  Generally, under
+   the generic TLDs the structure is very flat.  That is, many
+   organizations are registered directly under the TLD, and any further
+   structure is up to the individual organizations.
+
+   In the country TLDs, there is a wide variation in the structure, in
+   some countries the structure is very flat, in others there is
+   substantial structural organization.  In some country domains the
+   second levels are generic categories (such as, AC, CO, GO, and RE),
+   in others they are based on political geography, and in still others,
+   organization names are listed directly under the country code.  The
+   organization for the US country domain is described in RFC 1480.
+
+   Each of the generic TLDs was created for a general category of
+   organizations.  The country code domains (for example, FR, NL, KR,
+   US) are each organized by an administrator for that country.  These
+   administrators may further delegate the management of portions of the
+   naming tree.  These administrators are performing a public service on
+   behalf of the Internet community.  Descriptions of the generic
+   domains and the US country domain follow.
+
+   Of these generic domains, five are international in nature, and two
+   are restricted to use by entities in the United States.
+
+   World Wide Generic Domains:
+
+   COM - This domain is intended for commercial entities, that is
+         companies.  This domain has grown very large and there is
+         concern about the administrative load and system performance if
+         the current growth pattern is continued.  Consideration is
+         being taken to subdivide the COM domain and only allow future
+         commercial registrations in the subdomains.
+
+   EDU - This domain was originally intended for all educational
+         institutions.  Many Universities, colleges, schools,
+         educational service organizations, and educational consortia
+         have registered here.  More recently a decision has been taken
+         to limit further registrations to 4 year colleges and
+         universities.  Schools and 2-year colleges will be registered
+         in the country domains (see US Domain, especially K12 and CC,
+         below).
+
+   NET - This domain is intended to hold only the computers of network
+         providers, that is the NIC and NOC computers, the
+         administrative computers, and the network node computers.  The
+         customers of the network provider would have domain names of
+         their own (not in the NET TLD).
+
+   ORG - This domain is intended as the miscellaneous TLD for
+         organizations that didn't fit anywhere else.  Some non-
+         government organizations may fit here.
+
+   INT - This domain is for organizations established by international
+         treaties, or international databases.
+
+   United States Only Generic Domains:
+
+   GOV - This domain was originally intended for any kind of government
+         office or agency.  More recently a decision was taken to
+         register only agencies of the US Federal government in this
+         domain.  State and local agencies are registered in the country
+         domains (see US Domain, below).
+
+   MIL - This domain is used by the US military.
+
+   Example country code Domain:
+
+   US - As an example of a country domain, the US domain provides for 
+	the registration of all kinds of entities in the United States
+	on the basis of political geography, that is, a hierarchy of
+	<entity-name>.<locality>.<state-code>.US.  For example,
+	"IBM.Armonk.NY.US".  In addition, branches of the US domain are
+	provided within each state for schools (K12), community
+	colleges (CC), technical schools (TEC), state government
+	agencies (STATE), councils of governments (COG),libraries
+	(LIB), museums (MUS), and several other generic types of
+	entities (see RFC 1480 for details).
+
+
+A section from RFC 1480:
+
+   2. NAMING STRUCTURE
+
+       The US Domain hierarchy is based on political geography.  The
+       basic name space under US is the state name space, then the
+       "locality" name space, (like a city, or county) then
+       organization or computer name and so on.
+    
+       For example:
+    
+              BERKELEY.CA.US
+              PORTLAND.WA.US
+    
+       There is of course no problem with running out of names.
+    
+       The things that are named are individual computers.
+    
+       If you register now in one city and then move, the database can
+       be updated with a new name in your new city, and a pointer can
+       be set up from your old name to your new name.  This type of
+       pointer is called a CNAME record.
+    
+       The use of unregistered names is not effective and causes problems
+       for other users.  Inventing your own name and using it without
+       registering is not a good idea.
+    
+       In addition to strictly geographically names, some special names
+       are used, such as FED, STATE, AGENCY, DISTRICT, K12, LIB, CC,
+       CITY, and COUNTY.  Several new name spaces have been created,
+       DNI, GEN, and TEC, and a minor change under the "locality" name
+       space was made to the existing CITY and COUNTY subdomains by
+       abbreviating them to CI and CO.  A detailed description
+       follows.
+    
+       Below US, Parallel to States:
+       -----------------------------
+    
+       "FED" - This branch may be used for agencies of the federal
+       government.  For example: <org-name>.<city>.FED.US
+    
+       "DNI" - DISTRIBUTED NATIONAL INSTITUTES - The "DNI" branch was
+       created directly under the top-level US.  This branch is to be used
+       for distributed national institutes; organizations that span state,
+       regional, and other organizational boundaries; that are national in
+       scope, and have distributed facilities.  For example:
+       <org-name>.DNI.US.
+    
+       Name Space Within States:
+       ------------------------
+    
+       "locality" - cities, counties, parishes, and townships.  Subdomains
+       under the "locality" would be like CI.<city>.<state>.US,
+       CO.<county>.<state>.US, or businesses. For example:
+       Petville.Marvista.CA.US.
+    
+       "CI" - This branch is used for city government agencies and is a
+       subdomain under the "locality" name (like Los Angeles). For example:
+       Fire-Dept.CI.Los-Angeles.CA.US.
+    
+       "CO" - This branch is used for county government agencies and is a
+       subdomain under the "locality" name (like Los Angeles).  For example:
+       Fire-Dept.CO.San-Diego.CA.US.
+    
+       "K12" - This branch may be used for public school districts.  A
+       special name "PVT" can be used in the place of a school district name
+       for private schools.  For example: <school-name>.K12.<state>.US and
+       <school-name>.PVT.K12.<state>.US.
+    
+       "CC" - COMMUNITY COLLEGES - This branch was established for all state
+       wide community colleges.  For example: <school-name>.CC.<state>.US.
+    
+       "TEC" - TECHNICAL AND VOCATIONAL SCHOOLS - The branch "TEC" was
+       established for technical and vocational schools and colleges. For
+       example: <school-name>.TEC.<state>.US.
+    
+       "LIB" - LIBRARIES (STATE, REGIONAL, CITY, COUNTY) - This branch may
+       be used for libraries only.  For example:  <lib-name>.LIB.<state>.US.
+    
+       "STATE" - This branch may be used for state government agencies.  For
+       example:  <org-name>.STATE.<state>.US.
+    
+       "GEN" - GENERAL INDEPENDENT ENTITY - This branch is for the things
+       that don't fit easily into any other structure listed -- things that
+       might fit in to something like ORG at the top-level.  It is best not
+       to use the same keywords (ORG, EDU, COM, etc.) that are used at the
+       top-level to avoid confusion.  GEN would be used for such things as,
+       state-wide organizations, clubs, or domain parks.  For example:
+       <org-name>.GEN.<state-code>.US.
+
+The application form for the US domain may be found:
+
+* for anonymous ftp from internic.net : /templates/us-domain-template.txt
+* http://www.isi.edu/us-domain/
+
+The application form for the EDU, COM, NET, ORG, and  GOV domains may be
+found for anonymous ftp from:
+
+internic.net : /templates/domain-template.txt
+
+-----------------------------------------------------------------------------
+
+Question 4.11.  Classes of networks
+
+Date: Wed Sep  4 22:59:27 EDT 1996
+
+The usage of 'classes of networks' (class A, B, C) are historical and have
+been replaced by CIDR blocks on the Internet.  That being said...
+
+An Internet Protocol (IP) address is 32 bit in length, divided into  two
+or three parts (the network address, the subnet address (if present), and
+the host address.  The subnet addresses are only present if the network
+has been divided into subnetworks.  The length of the network, subnet, and
+host field are all variable.
+
+There are five different network classes.  The leftmost bits indicate  the
+class of the network.
+
+       # of     # of
+      bits in  bits in
+      network   host
+Class  field    field   Internet Protocol address in binary  Ranges
+============================================================================
+  A      7       24      0NNNNNNN.HHHHHHHH.HHHHHHHH.HHHHHHHH    1-127.x.x.x
+  B     14       16      10NNNNNN.NNNNNNNN.HHHHHHHH.HHHHHHHH  128-191.x.x.x
+  C     22        8      110NNNNN.NNNNNNNN.NNNNNNNN.HHHHHHHH  192-223.x.x.x
+  D     NOTE 1           1110xxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx  224-239.x.x.x
+  E     NOTE 2           11110xxx.xxxxxxxx.xxxxxxxx.xxxxxxxx  240-247.x.x.x
+
+   where N represents part of the network address and H represents part of 
+   the host address.   When the subnet address is defined, the needed bits 
+   are assigned from the host address space.
+
+   NOTE 1: Reserved for multicast groups - RFC 1112
+   NOTE 2: Reserved for future use
+
+   127.0.0.1 is reserved for local loopback.
+
+-----------------------------------------------------------------------------
+
+Question 4.12.  What is CIDR ?
+
+Date: Tue Nov  5 23:47:29 EST 1996
+
+CIDR is "Classless Inter-Domain Routing (CIDR).  From RFC 1517:
+
+      ...Classless Inter-Domain Routing (CIDR) attempts to deal with
+      these problems by defining a mechanism to slow the growth of 
+      routing tables and reduce the need to allocate new IP network 
+      numbers.  
+
+Much more information may be obtained in RFCs 1467, 1517, 1518, 1520;
+with primary reference 1519.
+
+Also please see the CIDR FAQ at
+
+* http://www.ibm.net.il/~hank/cidr.html
+* http://www.rain.net/faqs/cidr.faq.html
+* http://www.lab.unisource.ch/services/internet/direct/cidr.html
+
+-----------------------------------------------------------------------------
+
+Question 4.13.  What is the rule for glue ?
+
+Date: Fri Apr 28 13:31:24 EDT 1995
+
+A glue record is an A record for a name that appears on the right-hand
+side of a NS record.  So, if you have this:
+
+ 
+        sub.foobar.com.        IN      NS      dns.sub.foobar.com.
+        dns.sub.foobar.com.    IN      A       1.2.3.4
+
+then the second record is a glue record (for the NS record above it).
+
+You need glue records when -- and only when -- you are delegating
+authority to a nameserver that "lives" in the domain you are delegating
+*and* you aren't a secondary server for that domain.
+
+In other words, in the example above, you need to add an A record for
+dns.sub.foobar.com since it "lives" in the domain it serves.  This boot
+strapping information is necessary:  How are you supposed to find out the
+IP address of the nameserver for domain FOO if the nameserver for FOO
+"lives" in FOO?
+
+If you have this NS record:
+
+        sub.foobar.com.         IN      NS      dns.xyz123.com.
+
+you do NOT need a glue record, and, in fact, adding one is a very bad
+idea.  If you add one, and then the folks at xyz123.com change the
+address, then you will be passing out incorrect data.
+
+Also, unless you actually have a machine called something.IN-ADDR.ARPA,
+you will never have any glue records present in any of your "reverse"
+files.
+
+There is also a sort of implicit glue record that can be useful (or
+confusing :^) ).  If the parent server (abc.foobar.com domain in example
+above) is a secondary server for the child, then the A record will be
+fetched from the child server when the zone transfer is done.  The glue is
+still there but it's a little different, it's in the ip address in  the
+named.boot line instead of explicitly in the data.  In this case  you can
+leave out the explicit glue A record and leave the manually  configured
+"glue" in just the one place in the named.boot file.
+
+RFC 1537 says it quite nicely:
+
+      2. Glue records
+ 
+         Quite often, people put unnecessary glue (A) records in their 
+         zone files. Even worse is that I've even seen *wrong* glue records 
+         for an external host in a primary zone file! Glue records need only 
+         be in a zone file if the server host is within the zone and there 
+         is no A record for that host elsewhere in the zone file.
+ 
+         Old BIND versions ("native" 4.8.3 and older versions) showed the
+         problem that wrong glue records could enter secondary servers in
+         a zone transfer.
+
+
+The remainder of the FAQ is in the next part (Part 2 of 2).
+