diff options
author | dougb <dougb@FreeBSD.org> | 2002-07-01 01:28:00 +0000 |
---|---|---|
committer | dougb <dougb@FreeBSD.org> | 2002-07-01 01:28:00 +0000 |
commit | 5c99c444aa2f12ae983573e4950c7cb6ea722f02 (patch) | |
tree | 2224aadebf47dbe4d89d7ba79edc16f7d64b422e /contrib/bind/doc | |
parent | f4bd5053ab2eb505b16099244427d9e93442fe90 (diff) | |
download | FreeBSD-src-5c99c444aa2f12ae983573e4950c7cb6ea722f02.zip FreeBSD-src-5c99c444aa2f12ae983573e4950c7cb6ea722f02.tar.gz |
I don't think we ever installed these files, and they are more
than a little dated.
Diffstat (limited to 'contrib/bind/doc')
-rw-r--r-- | contrib/bind/doc/bog/00macs.me | 51 | ||||
-rw-r--r-- | contrib/bind/doc/bog/00title.me | 89 | ||||
-rw-r--r-- | contrib/bind/doc/bog/Makefile | 89 | ||||
-rw-r--r-- | contrib/bind/doc/bog/ack.me | 283 | ||||
-rw-r--r-- | contrib/bind/doc/bog/build.me | 102 | ||||
-rw-r--r-- | contrib/bind/doc/bog/files.me | 1150 | ||||
-rw-r--r-- | contrib/bind/doc/bog/intro.me | 75 | ||||
-rw-r--r-- | contrib/bind/doc/bog/manage.me | 156 | ||||
-rw-r--r-- | contrib/bind/doc/bog/named.boot.cache | 77 | ||||
-rw-r--r-- | contrib/bind/doc/bog/named.boot.primary | 78 | ||||
-rw-r--r-- | contrib/bind/doc/bog/named.boot.secondary | 77 | ||||
-rw-r--r-- | contrib/bind/doc/bog/named.local | 75 | ||||
-rw-r--r-- | contrib/bind/doc/bog/ns.me | 96 | ||||
-rw-r--r-- | contrib/bind/doc/bog/resolv.conf | 67 | ||||
-rw-r--r-- | contrib/bind/doc/bog/root.cache | 102 | ||||
-rw-r--r-- | contrib/bind/doc/bog/setup.me | 88 | ||||
-rw-r--r-- | contrib/bind/doc/bog/types.me | 163 | ||||
-rw-r--r-- | contrib/bind/doc/bog/ucbhosts | 118 | ||||
-rw-r--r-- | contrib/bind/doc/bog/ucbhosts.rev | 86 | ||||
-rw-r--r-- | contrib/bind/doc/notes/data | 51 | ||||
-rw-r--r-- | contrib/bind/doc/notes/db_names.c | 184 | ||||
-rw-r--r-- | contrib/bind/doc/notes/irp.txt | 521 |
22 files changed, 0 insertions, 3778 deletions
diff --git a/contrib/bind/doc/bog/00macs.me b/contrib/bind/doc/bog/00macs.me deleted file mode 100644 index 8ce02a2..0000000 --- a/contrib/bind/doc/bog/00macs.me +++ /dev/null @@ -1,51 +0,0 @@ -.\" Copyright (c) 1986, 1988 Regents of the University of California. -.\" All rights reserved. -.\" -.\" Redistribution and use in source and binary forms are permitted -.\" provided that this notice is preserved and that due credit is given -.\" to the University of California at Berkeley. The name of the University -.\" may not be used to endorse or promote products derived from this -.\" software without specific prior written permission. This software -.\" is provided ``as is'' without express or implied warranty. -.\" -.\" @(#)00macs.me 6.3 (Berkeley) 2/28/88 -.\" -.\" usage: troff -me myfile -.nr EX 0 -.de BX -.sp -.ba +4 -.lp -.nr EX +1 -.b -.ta (\\n(.lu-\\n(.iu)R -EXAMPLE \\n(EX: \(*D -.r -.lp -.. -.de EX -.br -.ba -.b -.tl '''\(gr' -.r -.lp -.. -.if \nl .ls 2 -.if t .nr bi 5m -.nr si 3n -.de $0 \" create a table of contents magically. -.(x -.ti (\\$3u-1u)*2m -\\$2. \\$1 -.)x -.. -.de $1 -.sp -.. -.de BU -.ip "\ \(bu" \w'\ \(bu\ 'u -.. -.de SM -\s-1\\$1\s0\\$2 -.. diff --git a/contrib/bind/doc/bog/00title.me b/contrib/bind/doc/bog/00title.me deleted file mode 100644 index 5048969..0000000 --- a/contrib/bind/doc/bog/00title.me +++ /dev/null @@ -1,89 +0,0 @@ -.\" Copyright (c) 1986, 1988 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" -.\" Portions Copyright (c) 1993 by Digital Equipment Corporation. -.\" -.\" Permission to use, copy, modify, and distribute this software for any -.\" purpose with or without fee is hereby granted, provided that the above -.\" copyright notice and this permission notice appear in all copies, and that -.\" the name of Digital Equipment Corporation not be used in advertising or -.\" publicity pertaining to distribution of the document or software without -.\" specific, written prior permission. -.\" -.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL -.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES -.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT -.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL -.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR -.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS -.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS -.\" SOFTWARE. -.+c -.(l C -.sz 14 -.b "Name Server Operations Guide" -.b "for \s-1BIND\s+1" -.sz -\fIRelease 4.9.3\fP -.eh 'SMM:10-%''Name Server Operations Guide for \s-1BIND\s+1' -.oh 'Name Server Operations Guide for \s-1BIND\s+1''\s-1SMM\s+1:10-%' -.sp -\fIReleases from 4.9\fP -Paul Vixie\** -.(f -\** This author was employed by Digital Equipment Corporation's -Network Systems Laboratory during the development and release of -\s-1BIND\s+1 4.9. Release 4.9.2 was sponsored by Vixie -Enterprises. Releases from 4.9.3 were sponsored by the Internet -Software Consortium. -.)f -<paul@vix.com> -.sp \n(psu -Internet Software Consortium -La Honda, CA -.sp 2 -\fIReleases through 4.8.3\fP -Kevin J. Dunlap\** -Michael J. Karels -.sp \n(psu -Computer Systems Research Group -Computer Science Division -Department of Electrical Engineering and Computer Sciences -University of California -Berkeley, CA 94720 -.)l -.sp 2 -.(f -\** This author was an employee of Digital Equipment Corporation's -\s-1ULTRIX\s+1 Engineering Advanced Development Group and was on loan to -CSRG when this work was done. \s-1ULTRIX\s+1 is a trademark of Digital -Equipment Corporation. -.)f diff --git a/contrib/bind/doc/bog/Makefile b/contrib/bind/doc/bog/Makefile deleted file mode 100644 index 09e1908..0000000 --- a/contrib/bind/doc/bog/Makefile +++ /dev/null @@ -1,89 +0,0 @@ -# ++Copyright++ 1986, 1988 -# - -# Copyright (c) 1986, 1988 -# The Regents of the University of California. All rights reserved. -# -# Redistribution and use in source and binary forms, with or without -# modification, are permitted provided that the following conditions -# are met: -# 1. Redistributions of source code must retain the above copyright -# notice, this list of conditions and the following disclaimer. -# 2. Redistributions in binary form must reproduce the above copyright -# notice, this list of conditions and the following disclaimer in the -# documentation and/or other materials provided with the distribution. -# 3. All advertising materials mentioning features or use of this software -# must display the following acknowledgement: -# This product includes software developed by the University of -# California, Berkeley and its contributors. -# 4. Neither the name of the University nor the names of its contributors -# may be used to endorse or promote products derived from this software -# without specific prior written permission. -# -# THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -# ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -# SUCH DAMAGE. -# - -# Portions Copyright (c) 1993 by Digital Equipment Corporation. -# -# Permission to use, copy, modify, and distribute this software for any -# purpose with or without fee is hereby granted, provided that the above -# copyright notice and this permission notice appear in all copies, and that -# the name of Digital Equipment Corporation not be used in advertising or -# publicity pertaining to distribution of the document or software without -# specific, written prior permission. -# -# THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL -# WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES -# OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT -# CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL -# DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR -# PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS -# ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS -# SOFTWARE. -# - -# --Copyright-- -# -# @(#)Makefile 6.3 (Berkeley) 2/28/88 -# -FILES= 00macs.me 00title.me intro.me ns.me types.me\ - files.me named.boot.primary\ - named.boot.secondary named.boot.cache resolv.conf\ - root.cache named.local ucbhosts.rev ucbhosts \ - setup.me manage.me build.me ack.me -ME= -me -NROFF= nroff -rb3 -PRINTER= -Pdp -TBL= dtbl $(PRINTER) -TROFF= ditroff $(PRINTER) -GROFF= groff -Tps -t $(ME) - -all: file.lst - -file.lst: $(FILES) - tbl $(FILES)| $(NROFF) $(ME) $(FLAGS) > file.lst - -file.psf: $(FILES) - $(GROFF) $(FILES) > file.psf - -troff: $(FILES) - $(TBL) $(FILES)| $(TROFF) $(ME) $(FLAGS) - -cat: $(FILES) - @cat $(FILES) - -clean: - rm -f *.psf *.lst *.BAK *.CKP *~ *.orig - -spell: $(FILES) - @for i in $(FILES); do \ - echo $$i; \ - spell $$i | sort | comm -23 - spell.ok > $$i.spell; \ - done diff --git a/contrib/bind/doc/bog/ack.me b/contrib/bind/doc/bog/ack.me deleted file mode 100644 index c9d7d85..0000000 --- a/contrib/bind/doc/bog/ack.me +++ /dev/null @@ -1,283 +0,0 @@ -.\" Copyright (c) 1986, 1988 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" -.\" Portions Copyright (c) 1993 by Digital Equipment Corporation. -.\" -.\" Permission to use, copy, modify, and distribute this software for any -.\" purpose with or without fee is hereby granted, provided that the above -.\" copyright notice and this permission notice appear in all copies, and that -.\" the name of Digital Equipment Corporation not be used in advertising or -.\" publicity pertaining to distribution of the document or software without -.\" specific, written prior permission. -.\" -.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL -.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES -.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT -.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL -.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR -.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS -.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS -.\" SOFTWARE. -.\" -.\" @(#)ack.me -.\" -.sx 0 -.bp -.ce -.b "ACKNOWLEDGEMENTS \(em 4.9.3" -.pp -The \fI<bind-workers@vix.com>\fP mailing list was once again of great help; -this release would not be nearly as ready for prime time if not for their -efforts. Special commendations are owed to Robert Elz, Don "Truck" Lewis, -Bob Halley, Mark Andrews, Berthold Paffrath, Ruediger Volk, and Peter Koch. -.pp -Digital Equipment Corporation, Hewlett Packard, Silicon Graphics, and SunSoft -all made hardware available for integration testing; this made the release -far more solid than it would otherwise have been. More hardware loans are -welcome \(em if you are a system vendor and you would like \s-2BIND\s+2 to -run ``out of the box'' on your platform and are willing to lend some rusty -old hardware for the purpose, please contact me (\fI<paul@vix.org>\fP) to -make the arrangements. -.pp -Special thanks to the Internet Software Consortium for funding this work. -Contact \fI<isc-info@isc.org>\fP if your organization would like to -participate in funding future releases of \s-2BIND\s+2 and other freely -redistributable software packages that are in wide use on the Internet. -.sp 2 -.ce -.b "ACKNOWLEDGEMENTS \(em through 4.9" -.pp -The alpha-test group was extremely helpful in furnishing improvements, -finding and repairing bugs, and being patient. I would like to express -special thanks to Brian Reid of Digital Equipment corporation for funding -this work. Robert Elz, Alan Barrett, Paul Albitz, Bryan Beecher, Andrew -Partan, Andy Cherenson, Tom Limoncelli, Berthold Paffrath, Fuat Baran, Anant -Kumar, Art Harkin, Win Treese, Don Lewis, Christophe Wolfhugel, and a cast -of dozens all helped out above and beyond the call of duty. Special thanks -to Phil Almquist, who got the project started and contributed a lot of the -code and fixed several of the worst bugs. -.sp 2 -.ce -.b "ACKNOWLEDGEMENTS \(em through 4.8.3" -.pp -Many thanks to the users at U. C. Berkeley for falling into many of the holes -involved with integrating BIND into the system so that others would be -spared the trauma. I would also like to extend gratitude to Jim McGinness -and Digital Equipment Corporation for permitting me to spend most of my time -on this project. -.pp -Ralph Campbell, Doug Kingston, Craig Partridge, Smoot Carl-Mitchell, Mike -Muuss and everyone else on the DARPA Internet who has contributed to the -development of BIND. To the members of the original BIND project, Douglas -Terry, Mark Painter, David Riggle and Songnian Zhou. -.pp -Anne Hughes, Jim Bloom and Kirk McKusick and the many others who have -reviewed this paper giving considerable advice. -.pp -This work was sponsored by the Defense Advanced Research Projects Agency -(DoD), Arpa Order No. 4871 monitored by the Naval Electronics Systems -Command under contract No. N00039-84-C-0089. The views and conclusions -contained in this document are those of the authors and should not be -interpreted as representing official policies, either expressed or implied, -of the Defense Research Projects Agency, of the US Government, or of Digital -Equipment Corporation. -.bp -.ba 0 -.in 0 -.sp 2 -.ce -.b REFERENCES -.sp -.nr ii 1i -.ip [Birrell] -Birrell, A. D., -Levin, R., -Needham, R. M., -and Schroeder, M.D., -.q "Grapevine: An Exercise in Distributed Computing." -In -.ul -Comm. A.C.M. 25, -4:260-274 -April 1982. -.ip [RFC819] -Su, Z. -Postel, J., -.q "The Domain Naming Convention for Internet User Applications." -.ul -Internet Request For Comment 819 -Network Information Center, -SRI International, -Menlo Park, California. -August 1982. -.ip [RFC974] -Partridge, C., -.q "Mail Routing and The Domain System." -.ul -Internet Request For Comment 974 -Network Information Center, -SRI International, -Menlo Park, California. -February 1986. -.ip [RFC1032] -Stahl, M., -.q "Domain Administrators Guide" -.ul -Internet Request For Comment 1032 -Network Information Center, -SRI International, -Menlo Park, California. -November 1987. -.ip [RFC1033] -Lottor, M., -.q "Domain Administrators Guide" -.ul -Internet Request For Comment 1033 -Network Information Center, -SRI International, -Menlo Park, California. -November 1987. -.ip [RFC1034] -Mockapetris, P., -.q "Domain Names - Concept and Facilities." -.ul -Internet Request For Comment 1034 -Network Information Center, -SRI International, -Menlo Park, California. -November 1987. -.ip [RFC1035] -Mockapetris, P., -.q "Domain Names - Implementation and Specification." -.ul -Internet Request For Comment 1035 -Network Information Center, -SRI International, -Menlo Park, California. -November 1987. -.ip [RFC1101] -Mockapetris, P., -.q "DNS Encoding of Network Names and Other Types." -.ul -Internet Request For Comment 1101 -Network Information Center, -SRI International, -Menlo Park, California. -April 1989. -.ip [RFC1123] -R. Braden, Editor, -.q "Requirements for Internet Hosts -- Application and Support" -.ul -Internet Request For Comment 1123 -Network Information Center, -SRI International, -Menlo Park, California. -October 1989. -.ip [RFC1183] -Everhart, C., -Mamakos, L., -Ullmann, R., -and -Mockapetris, P., -.q "New DNS RR Definitions" -.ul -Internet Request For Comment 1183 -Network Information Center, -SRI International, -Menlo Park, California. -October 1990. -.ip [RFC1327] -Hardcastle-Kille, S., -.q "Mapping between X.400(1988) / ISO 10021 and RFC 822" -.ul -Internet Request For Comment 1327 -Network Information Center, -SRI International, -Menlo Park, California. -May 1992. -.ip [RFC1664] -Allocchio, C., -Bonito, A., -Cole, B., -Giordano, S., -Hagens, R., -.q "Using the Internet DNS to Distribute RFC1327 Mail Address Mapping Tables" -.ul -Internet Request For Comment 1664 -Network Information Center, -SRI International, -Menlo Park, California. -August 1994. -.ip [RFC1713] -Romao, A., -.q "Tools for DNS debugging" -.ul -Internet Request For Comment 1713, also FYI27 -Network Information Center, -SRI International, -Menlo Park, California. -November 1994. -.ip [Terry] -Terry, D. B., -Painter, M., -Riggle, D. W., -and -Zhou, S., -.ul -The Berkeley Internet Name Domain Server. -Proceedings USENIX Summer Conference, -Salt Lake City, Utah. -June 1984, pages 23-31. -.ip [Zhou] -Zhou, S., -.ul -The Design and Implementation of the Berkeley Internet Name Domain (BIND) Servers. -UCB/CSD 84/177. -University of California, Berkeley, -Computer Science Division. -May 1984. -.ip [Mockapetris] -Mockapetris, P., -Dunlap, K, -.ul -Development of the Domain Name System -ACM Computer Communications Review 18, 4:123-133. -Proceedings ACM SIGCOMM '88 Symposium, -August 1988. -.ul -.ip [Liu] -Liu, C., -Albitz, P., -.ul -DNS and BIND -O'Reilly & Associates, Sebastopol, CA, -502 pages, ISBN 0-937175-82-X -1992 diff --git a/contrib/bind/doc/bog/build.me b/contrib/bind/doc/bog/build.me deleted file mode 100644 index d6dab9f..0000000 --- a/contrib/bind/doc/bog/build.me +++ /dev/null @@ -1,102 +0,0 @@ -.\" ++Copyright++ 1986, 1988 -.\" - -.\" Copyright (c) 1986, 1988 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" - -.\" Portions Copyright (c) 1993 by Digital Equipment Corporation. -.\" -.\" Permission to use, copy, modify, and distribute this software for any -.\" purpose with or without fee is hereby granted, provided that the above -.\" copyright notice and this permission notice appear in all copies, and that -.\" the name of Digital Equipment Corporation not be used in advertising or -.\" publicity pertaining to distribution of the document or software without -.\" specific, written prior permission. -.\" -.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL -.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES -.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT -.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL -.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR -.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS -.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS -.\" SOFTWARE. -.\" - -.\" --Copyright-- -.\" -.\" @(#)build.me 6.3 (Berkeley) 9/19/89 -.\" -.sh 1 "Building a System with a Name Server" -.pp -BIND is composed of two parts. One is the user interface called the -\fIresolver\fP -which consists of a group of routines that reside in the C library -\fI/lib/libc.a\fP. -Second is the actual server called \fInamed\fP. -This is a daemon that runs in the background and services queries on a -given network port. The standard port for UDP and TCP is specified in -\fI/etc/services\fP. -.sh 2 "Resolver Routines in libc" -.pp -When building your 4.3BSD system you may either -build the C library to use the name server resolver routines -or use the host table lookup routines to do host name and address resolution. -The default resolver for 4.3BSD uses the name server. Newer BSD systems -include both name server and host table functionality with preference given -to the name server if there is one or if there is a \fI/etc/resolv.conf\fP -file. -.pp -Building the C library to use the name server changes the way -\fIgethostbyname\fP\|(3N), \fIgethostbyaddr\fP\|(3N), and -\fIsethostent\fP\|(3N) do their functions. The name server renders -\fIgethostent\fP\|(3N) obsolete, since it has no concept of a next line in -the database. These library calls are built with the resolver routines -needed to query the name server. -.pp -The \fIresolver\fP contains functions that build query -packets and exchange them with name servers. -.pp -Before building the 4.3BSD C library, set the variable \fIHOSTLOOKUP\fP -equal to \fInamed\fP in \fI/usr/src/lib/libc/Makefile\fP. You -then make and install the C library and compiler and then compile the rest -of the 4.3BSD system. For more information see section 6.6 of ``Installing -and Operating 4.3BSD on the VAX\(dd''. -.(f -\(ddVAX is a Trademark of Digital Equipment Corporation -.)f -.pp -If your operating system isn't VAX\(dd 4.3BSD, it is probably the case that -your vendor has included \fIresolver\fP support in the supplied C Library. -You should consult your vendor's documentation to find out what has to be -done to enable \fIresolver\fP support. Note that your vendor's \fIresolver\fP -may be out of date with respect to the one shipped with \s-1BIND\s+1, and that -you might want to build \s-1BIND\s+1's resolver library and install it, and -its include files, into your system's compile/link path so that your own -network applications will be able to use the newer features. diff --git a/contrib/bind/doc/bog/files.me b/contrib/bind/doc/bog/files.me deleted file mode 100644 index ae755ff..0000000 --- a/contrib/bind/doc/bog/files.me +++ /dev/null @@ -1,1150 +0,0 @@ -.\" ++Copyright++ 1986, 1988, 1995 -.\" - -.\" Copyright (c) 1986, 1988, 1995 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" - -.\" Portions Copyright (c) 1993 by Digital Equipment Corporation. -.\" -.\" Permission to use, copy, modify, and distribute this software for any -.\" purpose with or without fee is hereby granted, provided that the above -.\" copyright notice and this permission notice appear in all copies, and that -.\" the name of Digital Equipment Corporation not be used in advertising or -.\" publicity pertaining to distribution of the document or software without -.\" specific, written prior permission. -.\" -.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL -.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES -.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT -.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL -.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR -.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS -.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS -.\" SOFTWARE. -.\" - -.\" --Copyright-- -.\" -.\" @(#)files.me 6.8 (Berkeley) 9/19/89 -.\" -.sh 1 "Files -.pp -The name server uses several files to load its data base. -This section covers the files and their formats needed for \fInamed\fP. -.sh 2 "Boot File" -.pp -This is the file that is first read when \fInamed\fP starts up. -This tells the server what type of server it is, -which -zones it has authority over and where to get its initial data. -The default location for this file is \fI/etc\|/named.boot\fP\|. -However this can be changed -by setting the \fIBOOTFILE\fP variable when you compile \fInamed\fP -or by specifying -the location on the command line when \fInamed\fP is started up. -.sh 3 "Domain" -.pp -A default domain may be specified for the name server -using a line such as -.(b l -.ta 0.5i +\w`secondary `u +\w`berkeley.edu `u +.5i +.5i -\fIdomain Berkeley\fP\fB\|.\|\fP\fIEdu\fP -.)b -.re -Older name servers use this information when they receive a query for a name -without a ``\fB.\fP'' that is not known. Newer designs assume that the -resolver library will append its own idea of a ``default domain'' to any -unqualified names. Though the name server can still be compiled with -support for the \fIdomain\fP directive in the boot file, the default is to -leave it out and we strenuously recommend against its use. If you use this -feature, clients outside your local domain which send you requests about -unqualified names will have the implicit qualification of your domain rather -than theirs. The proper place for this function is on the client, in their -\fB/etc/resolv.conf\fP (or equivalent) file. Use of the \fIdomain\fP -directive in your boot file is strongly discouraged. -.sh 3 "Directory" -.pp -The \fIdirectory\fP directive specifies the directory in which the name server -should run, allowing the other file names in the boot file to use relative path -names. There can be only one \fIdirectory\fP directive and it should be given -before any other directives that specify file names. -.(b l -.ta 0.5i +\w`secondary `u +\w`berkeley.edu `u +.5i +.5i -\fIdirectory /var/named\fP -.)b -.re -If you have more than a couple of named files to be maintained, you may wish -to place the named files in a directory such as /var/named and adjust the -directory command properly. The main purposes of this command are to make -sure named is in the proper directory when trying to include files by -relative path names with $INCLUDE and to allow named to run in a location -that is reasonable to dump core if it feels the urge. -.sh 3 "Primary Service" -.pp -The line in the boot file that designates the server as a primary master server -for a zone looks as follows: -.(b l -.ta 0.5i +\w`secondary `u +\w`berkeley.edu `u +.5i +.5i -\fIprimary Berkeley\fP\fB\|.\|\fP\fIEdu ucbhosts\fP -.)b -.re -The first field specifies that the server is a primary one for the zone -stated in the second field. -The third field is the name of the file from which the data is read. -.pp -The above assumes that the zone you are specifying is a class \fIIN\fP -zone. If you wish to designate a different class you can append -\fI/class\fP to the first field, where \fIclass\fP is either the -integer value or the standard mnemonic for the class. For example the line -for a primary server for a hesiod class zone looks as follows: -.(b l -.ta 0.5i +\w`secondary `u +\w`berkeley.edu `u +.5i +.5i -\fIprimary/HS Berkeley\fP\fB\|.\|\fP\fIEdu hesiod.data\fP -.)b -.re -Note that this support for specifying other than class \fIIN\fP zones is a -compile-time option which your vendor may not have enabled when they built -your operating system. -.sh 3 "Secondary Service" -.pp -The line for a secondary server is similar to the primary except -that it lists addresses of other servers (usually primary servers) -from which the zone data will be obtained. -.(b l -.ta 0.5i +\w`secondary `u +\w`berkeley.edu `u +\w`128.32.0.10 `u +\w`128.32.0.10 `u +.5i +.5i -\fIsecondary Berkeley\fP\fB\|.\|\fP\fIEdu 128\fP\fB.\fP\fI32\fP\fB.\fP\fI0\fP\fB.\fP\fI10 \fP\fI128\fP\fB.\fP\fI32\fP\fB.\fP\fI0\fP\fB.\fP\fI4\fP \fIucbhosts.bak\fP -.)b -.re -The first field specifies that the server is a secondary server for -the zone stated in the second field. -The two network addresses specify the name servers which have data for the -zone. Note that at least one of these will be a \fIprimary\fP, and, unless -you are using some protocol other than \s-1IP/DNS\s+1 for your zone transfer -mechanism, the others will all be other \fIsecondary\fP servers. Having your -secondary server pull data from other secondary servers is usually unwise, -since you can add delay to the propagation of zone updates if your network's -connectivity varies in pathological but common ways. The intended use for -multiple addresses on a \fIsecondary\fP declaration is when the \fIprimary\fP -server has multiple network interfaces and therefore multiple host addresses. -The secondary server gets its data across the network from one of the listed -servers. The server addresses are tried in the order listed. -If a filename is present after the list of primary servers, data for the zone -will be dumped into that file as a backup. -When the server is first started, the data is loaded from the backup file -if possible, and a primary server is then consulted to check that the zone -is still up-to-date. Note that listing your server as a \fIsecondary\fP -server does not necessarily make it one \(em the parent zone must -\fIdelegate\fP authority to your server as well as the primary and the -other secondaries, or you will be transferring a zone over for no reason; -no other server will have a reason to query you for that zone unless the -parent zone lists you as a server for the zone. -.pp -As with primary you may specify a secondary server for a class other than -\fIIN\fP by appending \fI/class\fP to the \fIsecondary\fP keyword, e.g., -\fIsecondary/HS\fP. -.sh 3 "Stub Service" -.pp -The line for a stub server is similar to a secondary. -(This feature is experimental as of 4.9.3.) -.(b l -.ta 0.5i +\w`stub `u +\w`berkeley.edu `u +\w`128.32.0.10 `u +\w`128.32.0.10 `u +.5i +.5i -\fIstub Berkeley\fP\fB\|.\|\fP\fIEdu 128\fP\fB.\fP\fI32\fP\fB.\fP\fI0\fP\fB.\fP\fI10 \fP\fI128\fP\fB.\fP\fI32\fP\fB.\fP\fI0\fP\fB.\fP\fI4\fP \fIucbhosts.bak\fP -.)b -.re -The first field specifies that the server is a stub server for the zone stated -in the second field. -.pp -Stub zones are intended to ensure that a primary for a zone always has the -correct \fINS\fP records for children of that zone. If the primary is not -a secondary for a child zone it should be configured with stub zones for -all its children. Stub zones provide a mechanism to allow \fINS\fP records -for a zone to be specified in only one place. -.(b l -.ta 0.5i +\w`primary `u +\w`dms.csiro.au `u +\w`130.155.98.1 `u +.5i +.5i -\fIprimary CSIRO\fP\fB\|.\|\fP\fIAU \fIcsiro.dat\fP -\fIstub dms.CSIRO\fP\fB\|.\|\fP\fIAU 130\fP\fB.\fP\fI155\fP\fB.\fP\fI16\fP\fB.\fP\fI1 \fIdms.stub\fP -\fIstub dap.CSIRO\fP\fB\|.\|\fP\fIAU 130\fP\fB.\fP\fI155\fP\fB.\fP\fI98\fP\fB.\fP\fI1 \fIdap.stub\fP -.)b -.re -.sh 3 "Cache Initialization" -.pp -All servers, including ``caching only'' servers, should have a line as -follows in the boot file to prime the name servers cache: -.(b l -\fIcache \fP\fB.\fP\fI root\fP\fB.\fP\fIcache\fP -.)b -Do not put anything into your \fIcache\fP files other than root server -information. -.pp -All cache files listed will be read in at named boot time and any values -still valid will be reinstated in the cache. -The root name server -information in the cache files will be used until a root query is -actually answered by one of the name servers in the cache file, after -which that answer will be used instead of the cache file until the answer -times out. -.pp -As with \fIprimary\fP and \fIsecondary\fP, you may specify a secondary -server for a class other than \fIIN\fP by appending \fI/class\fP to the -\fIcache\fP keyword, e.g., \fIclass/HS\fP. -.sh 3 "Forwarders" -.pp -Any server can make use of \fIforwarders\fP. A \fIforwarder\fP is another -server capable of processing recursive queries that is willing to try -resolving queries on behalf of other systems. The \fIforwarders\fP -command specifies forwarders by internet address as follows: -.(b l -\fIforwarders \fI128\fP\fB.\fP\fI32\fP\fB.\fP\fI0\fP\fB.\fP\fI10 \fP\fI128\fP\fB.\fP\fI32\fP\fB.\fP\fI0\fP\fB.\fP\fI4\fP -.)b -.re -There are two main reasons for wanting to do so. First, some systems may -not have full network access and may be prevented from sending any IP -packets into the rest of the Internet and therefore must rely on a forwarder -which does have access to the full net. The second reason is that the -forwarder sees a union of all queries as they pass through its server and -therefore it builds up a very rich cache of data compared to the cache in a -typical workstation name server. In effect, the \fIforwarder\fP becomes a -meta-cache that all hosts can benefit from, thereby reducing the total -number of queries from that site to the rest of the net. -.pp -The effect of ``forwarders'' is to prepend some fixed addresses to the list -of name servers to be tried for every query. Normally that list is made up -only of higher-authority servers discovered via \fINS\fP record lookups for -the relevant domain. If the forwarders do not answer, then unless the -\fIslave\fP directive was given, the appropriate servers for the domains -will be queried directly. - -.sh 3 "Slave Servers" -.pp -Slave mode is used if the use of forwarders is the only possible way -to resolve queries due to lack of full net access or if you wish to prevent -the name server from using other than the listed forwarders. -Slave mode is activated by placing the simple command -.(b l -\fIoptions forward-only\fP -.)b -in the bootfile. If this option is used, then you must specify forwarders. -When in slave mode, the server will forward each query to each of the -forwarders until an answer is found or the list of forwarders is exhausted. -The server will not try to contact any remote name server other than those -named in the \fIforwarders\fP list. -.pp -So while \fIforwarders\fP prepends addresses to the ``server list'' for each -query, \fIoptions forward-only\fP causes the ``server list'' to contain -\fIonly\fP those addresses listed in the \fIforwarders\fP declarations. -Careless use of the \fIoptions forward-only\fP directive can cause really -horrible forwarding loops, since -you could end up forwarding queries only to some set of hosts which are also -slaves, and one or several of them could be forwarding queries back to you. -.pp -Use of the \fIoptions forward-only\fP directive should be considered very -carefully. Note that this same behaviour can be achieved using the deprecated -directive, \fIslave\fP. - -.sh 3 "Nonrecursive Servers" -.pp -\s-1BIND\s+1's separation of authoritative (zone) and nonauthoritiative (cache) -data has always been somewhat weak, and pollution of the former via the latter -has been known to occur. One way to prevent this, as well as to save memory on -servers carrying a lot of authoritative data (e.g., root servers) is to make -such servers ``nonrecursive.'' This can be achieved via the directive -.(b l -\fIoptions no-recursion\fP -.)b -in the bootfile. A server with this option enabled will not attempt to fetch -data to help answer queries \(em if you ask it for data it does not have, it -will send you a referral to a more authoritative server or, if it is itself -authoritative for the zone of the query, it will send you an negative answer. -.pp -A nonrecursive server can be named in an \s-1NS\ RR\s+1 but it cannot be listed -in the \fIresolv.conf\fP file. - -.sh 3 "Query Logging" -.pp -If the file system containing your \fIsyslog\fP file has quite a bit of space, -you can consider using the -.(b l -\fIoptions query-log\fP -.)b -directive in your bootfile. This will cause your name server to log every -query it receives, which when combined with a Perl or \s-1AWK\s+1 script to -postprocess the logs, can be a useful management tool. - -.sh 3 "Inverse Query Pseudosupport" -.pp -\s-1BIND\s+1 by default does not support inverse queries, and this has been -known to cause problems for certain microcomputer operating systems and for -older versions of \s-1BIND\s+1's \fInslookup\fP tool. You may decide that -rather than answering with ``operation not implemented,'' \fInamed\fP should -detect the most common inverse queries and answer them with bogus information. -It is better to upgrade your clients to stop depending on inverse queries, but -if that is not possible, you should use the -.(b l -\fIoptions fake-iquery\fP -.)b -directive in your bootfile. \fINOTE:\fP the responses are in fact bogus, in -that they contain \s-1ISO\s+18859 square brackets (\fB[\fP and \fB]\fP), so -your clients will not be able to do anything useful with these responses. It -has been observed that no client ever did anything useful with real inverse -query responses, either. - -.sh 3 "Setting Name Server Limits" -.pp -Some name server operations can be quite resource intensive, and in order to -tune your system properly it is sometimes necessary to change \s-1BIND\s+1's -internal quotas. This is accomplished via -.(b l -\fIlimit <name> <value>\fP -.)b -directives in the bootfile. Limits, and their default values, are as follows: -.(b I -\fIlimit transfers-in 10\fP -.)b -This is the number of simultaneous \fInamed-xfer\fP processes \s-1BIND\s+1 is -willing to start. Higher numbers yield faster convergence to primary servers -if your secondary server has hundreds or thousands of zones to maintain, but -setting this number too high can cause thrashing due to starvation of resources -such as network bandwidth or swap space. \fINOTE:\fP this limit can also be -expressed via the deprecated directive \fImax-fetch NN\fP. -.(b I -\fIlimit transfers-per-ns 2\fP -.)b -This is the number of simultaneous \fInamed-xfer\fP processes \s-1BIND\s+1 is -willing to initiate \fIto any given name server\fP. In most cases, you should -not need to change it. If your secondary server is pulling hundreds or -thousands of zones from a single primary server, increasing -\fItransfers-per-ns\fP may speed convergence. It should be kept as -small as possible, to avoid causing thrashing and resource starvation -on the primary server. -.(b I -\fIlimit datasize <system-dependent>\fP -.)b -Most systems have a quota that limits the size of the so-called ``data -segment,'' which is where \s-1BIND\s+1 keeps all of its authority and cache -data. \s-1BIND\s+1 will behave suboptimally (perhaps even exiting) if it runs -up against this quota. If your system supports a system call to change this -quota for a given process, you can ask \s-1BIND\s+1 to use that system call -via the \fIlimit datasize NN\fP directive. The value given here may be scaled -by postfixing \fIk\fP for 1024X, \fIm\fP for (1024^2)X, and \fIg\fP for -(1024^3)X. In 1995, the root servers all use \fIlimit datasize 64m\fP. - -.sh 3 "Zone Transfer Restrictions" -.pp -It may be the case that your organization does not wish to give complete -lists of your hosts to anyone on the Internet who can reach your name servers. -While it is still possible for people to ``iterate'' through your address -range, looking for \fIPTR\fP records, and build a list of your hosts the -``slow'' way, it is still considered reasonable to restrict your export of -zones via the zone transfer protocol. To limit the list of neighbors who -can transfer zones from your server, use the \fIxfrnets\fP directive. -.pp -This directive has the same syntax as \fIforwarders\fP except that you can -list network numbers in addition to host addresses. For example, you could -add the directive -.(b l -\fIxfrnets 16.0.0.0\fP -.)b -.re -if you wanted to permit only hosts on Class A network number 16 to transfer -zones from your server. This is not nearly granular enough, and a future -version of \s-1BIND\s+1 will permit such access-control to be specified on a -per-host basis rather than the current per-net basis. Note that while -addresses without explicit masks are assumed by this directive to be networks, -you can specify a mask which is as granular as you wish, perhaps including -all bits of the address such that only a single host is given transfer -permission. For example, consider -.(b l -\fIxfrnets 16.1.0.2&255.255.255.255\fP -.)b -which would permit only host \fI16.1.0.2\fP to transfer zones from you. Note -that no spaces are allowed surrounding the ``\fI&\fP'' character that -introduces a netmask. -.pp -The \fIxfrnets\fP directive may also be given as \fItcplist\fP for -compatibility with interim releases of \s-1BIND\s+1 4.9. - -.sh 3 "Sorting Addresses" -.pp -If there are multiple addresses available for a name server which \s-1BIND\s+1 -wants to contact, \s-1BIND\s+1 will try the ones it believes are ``closest'' -first. ``Closeness'' is defined in terms of similarity-of-address; that is, -if one address is on the same \fIsubnet\fP as some interface of the local host, -then that address will be tried first. Failing that, an address which is on -the same \fInetwork\fP will be tried first. Failing that, they will be tried -in a more-or-less random order unless the \fIsortlist\fP directive was given -in the \fInamed.boot\fP file. \fIsortlist\fP has a syntax similar to -\fIforwarders\fP, \fIxfrnets\fP, and \fIbogusns\fP \(em you give it a list -of dotted-quad networks and it uses these to ``prefer'' some remote name server -addresses over others. If no explicit mask is provided with each element of -a \fIsortlist\fP, one will be inferred based on the high order address bits. -.pp -If you are on a Class C net which has a Class B net between you and the rest -of the Internet, you could try to improve the name server's luck in getting -answers by listing the Class B network's number in a \fIsortlist\fP -directive. This should have the effect of trying ``closer'' servers before -the more ``distant'' ones. Note that this behaviour is new as of \s-1BIND -4.9\s+1. -.pp -The other and older effect of the \fIsortlist\fP directive is to cause -\s-1BIND\s+1 to sort the \fIA\fP records in any response it generates, so as -to put those which appear on the \fIsortlist\fP earlier than those which do -not. This is not as helpful as you might think, since many clients will -reorder the \fIA\fP records either at random or using \s-1LIFO\s+1; also, -consider the fact that the server won't be able to guess the client's network -topology, and so will not be able to accurately order for ``closeness'' to -all possible clients. Doing the ordering in the resolver is clearly superior. -.pp -In actual practice, this directive is used only rarely since it hardwires -information which changes rapidly; a network which is ``close'' today may -be ``distant'' next month. Since \s-1BIND\s+1 builds up a cache of the -remote name servers' response times, it will quickly converge on -``reasonable'' behaviour, which isn't the same as ``optimal'' but it's -close enough. Future directions for \s-1BIND\s+1 include choosing -addresses based on local interface metrics (on hosts that have more than -one) and perhaps on routing table information. We do not intend to solve -the generalized ``multihomed host'' problem, but we should be able to do a -little better than we're doing now. Likewise, we hope to see a higher -level resolver library that sorts responses using topology information that -only exists on the client's host. - -.sh 3 "Bogus Name Servers" -.pp -It happens occasionally that some remote name server goes ``bad''. You can -tell your name server to refuse to listen to or ask questions of certain -other name servers by listing them in a \fIbogusns\fP directive in your -\fInamed.boot\fP file. Its syntax is the same as \fIforwarders\fP, -\fIxfrnets\fP, and \fIsortlist\fP \(em you just give it a list of dotted-quad -Internet addresses. Note that zones delegated to such servers will not be -reachable from clients of your servers; thus you should use this directive -sparingly or not at all. - -.sh 3 "Segmented Boot Files" -.pp -If you are secondary for a lot of zones, you may find it convenient to split -your \fInamed.boot\fP file into a static portion which hardly ever changes -(directives such as \fIdirectory\fP, \fIsortlist\fP, \fIxfrnets\fP and -\fIcache\fP could go here), and dynamic portions that change frequently -(all of your \fIprimary\fP directives might go in one file, and all of your -\fIsecondary\fP directives might go in another file \(em and either or both -of these might be fetched automatically from some neighbor so that they can -change your list of secondary zones without requiring your active -intervention). You can accomplish this via the \fIinclude\fP directive, -which takes just a single file name as its argument. No quotes are needed -around the file name. The file name will be evaluated after the name server -has changed its working directory to that specified in the \fIdirectory\fP -directive, so you can use relative pathnames if your system supports them. - -.sh 2 "Resolver Configuration" -.pp -The configuration file's name is \fI/etc/resolv.conf\fP. -This file designates the name servers on the network that should -be sent queries. -The resolver will try to contact a name server on the localhost if it cannot -find its configuration file. You should install the configuration file -on every host anyway, since this is the only recommended way to specify a -system-level default domain, and you can still list the local host's address -if it runs a name server. -It is considered reasonable to create this file even if you run a local -server, since its contents will be cached by each client of the resolver -library when the client makes its first call to a resolver routine. -.pp -The \fIresolv.conf\fP file contains directives, one per line, of the -following forms: -.(l I -; comment -# another comment -domain \fIlocal-domain\fP -search \fIsearch-list\fP -nameserver \fIserver-address\fP -sortlist \fIsort-list\fP -options \fIoption-list\fP -.)l -Exactly one of the \fIdomain\fP or \fIsearch\fP directives should be given, -exactly once. -If the \fIsearch\fP directive is given, the first item in the given -\fIsearch-list\fP will override any previously-specified \fIlocal-domain\fP. -The \fInameserver\fP directive may be given up to three times; additional -\fInameserver\fP directives will be ignored. Comments may be given by -starting a line with a ``\fB\|;\|\fP'' or ``\fB\|#\|\fP''; note that -comments were not permitted in versions of the resolver earlier than the one -included with \s-1BIND 4.9\s+1 \(em so if your vendor's resolver supports -comments, you know they are really on the ball. -.pp -The \fIlocal-domain\fP will be appended to any query-name that does not -contain a ``\fB\|.\|\fP''. \fIlocal-domain\fP can be overridden on a -per-process basis by setting the \s-1LOCALDOMAIN\s+1 environment variable. -Note that \fIlocal-domain\fP processing can be disabled by setting an -option in the resolver. -.pp -The \fIsearch-list\fP is a list of domains which are tried, in order, -as qualifying domains for query-names which do not contain a ``\fB\|.\|\fP''. -Note that \fIsearch-list\fP processing can be disabled by setting an -option in the resolver. Also note that the environment variable -``\s-1LOCALDOMAIN\s+1'' can override this \fIsearch-list\fP on a per-process -basis. -.pp -The \fIserver-address\fP\|'s are aggregated and then used as the default -destination of queries generated through the resolver. In other words, -this is the way you tell the resolver which name servers it should use. It -is possible for a given client application to override this list, and this -is often done inside the name server (which is itself a \fIresolver\fP -client) and in test programs such as \fInslookup\fP. -Note that if you wish to list the -local host in your resolver configuration file, you should probably use its -primary Internet address rather than a local-host alias such as 127.0.0.1 or -0.0.0.0. This is due to a bug in the handling of connected \s-1SOCK_DGRAM\s+1 -sockets in some versions of the \s+1BSD\s-1 networking code. If you must use -an address-alias, you should prefer 0.0.0.0 (or simply ``0'') over 127.0.0.1, -though be warned that depending on the vintage of your \s-1BSD\s+1-derived -networking code, both of them are capable of failing in their own ways. -If your host's IP -implementation does not create a short-circuit route between the default -interface and the loopback interface, then you might also want to add a -static route (eg. in \fB/etc/rc.local\fP) to do so: -.(b l -\fIroute add myhost.domain.name localhost 1\fP -.)b -.pp -The \fIsort-list\fP is a list of IP address, netmask pairs. Addresses -returned by gethostbyname are sorted to the order specified by this list. -Any addresses that do not match the address netmask pair will be returned -after those that do. The netmask is optional and the natural netmask will be -used if not specified. -.pp -The \fIoption-list\fP is a list of options which each override some internal -resolver variable. Supported options at this time are: -.ip \fBdebug\fP -sets the \s-1RES_DEBUG\s+1 bit in \fB_res.options\fP. -.ip \fBndots:\fP\fIn\fP -sets the lower threshold (measured in ``number of dots'') on names given to -\fIres_query\fP() such that names with more than this number of dots will be -tried as absolute names before any \fIlocal-domain\fP or \fIsearch-list\fP -processing is done. The default for this internal variable is ``1''. -.\" .pp -.\" Finally, if the environment variable \s-1HOSTALIASES\s+1 is set, it is -.\" taken to contain the name of a file which in turn contains resolver-level -.\" aliases. These aliases are applied only to names which do not contain any -.\" ``\fB\|.\|\fP'' characters, and they are applied to query-names before the -.\" query is generated. Note that the resolver options governing the operation -.\" of \fIlocal-domain\fP and \fIsearch-list\fP do not apply to -.\" \s-1HOSTALIASES\s+1. - -.sh 2 "Cache Initialization File" -.sh 3 root.cache -.pp -The name server needs to know the servers that are the authoritative name -servers for the root domain of the network. To do this we have to prime the -name server's cache with the addresses of these higher authorities. The -location of this file is specified in the boot file. This file uses the -Standard Resource Record Format (aka. Masterfile Format) covered further on -in this paper. - -.sh 2 "Domain Data Files" -.pp -There are two standard files for specifying the data for a -domain. These are \fIhosts\fP and \fIhost.rev\fP. -These files use the Standard Resource Record Format covered later -in this paper. Note that the file names are arbitrary; many network -administrators prefer to name their zone files after the domains they -contain, especially in the average case which is where a given server -is primary and/or secondary for many different zones. -.sh 3 hosts -.pp -This file contains all the data about the machines in this zone. -The location of this file is specified in the boot file. -.sh 3 hosts.rev -.pp -This file specifies the IN-ADDR\|.\|ARPA domain. -This is a special domain for allowing address to name mapping. -As internet host addresses do not fall within domain boundaries, -this special domain was formed to allow inverse mapping. -The IN-ADDR\|.\|ARPA domain has four -labels preceding it. These labels correspond to the 4 octets of -an Internet address. -All four octets must be specified even if an octet contains zero. -The Internet address 128.32.0.4 is located in the domain -4\|.\|0\|.\|32\|.\|128\|.\|IN-ADDR\|.\|ARPA. -This reversal of the address is awkward to read but allows -for the natural grouping of hosts in a network. -.sh 3 named.local -.pp -This file specifies the \fIPTR\fP record for the local loopback interface, -better known as \fIlocalhost\fP, whose network address is 127.0.0.1. The -location of this file is specified in the boot file. It is vitally -important to the proper operation of every name server that the 127.0.0.1 -address have a \fIPTR\fP record pointing back to the name -``\fBlocalhost.\fP''. The name of this \fIPTR\fP record is always -``\fB1.0.0.127.\s-1IN-ADDR.ARPA\s+1\fP''. This is necessary if you want -your users to be able to use hostname-authentication (\fIhosts.equiv\fP or -\fI~/.rhosts\fP) on the name ``\fBlocalhost\fP''. As implied by this -\fIPTR\fP record, there should be a ``\fBlocalhost.\fP\fImy.dom.ain\fP'' -\fIA\fP record (with address 127.0.0.1) in every domain that contains hosts. -``\fBlocalhost.\fP'' will lose its trailing dot when -\fB1.0.0.127.in-addr.arpa\fP is queried for; then, the DEFNAMES and/or -DNSRCH resolver options will cause ``\fBlocalhost\fP'' to be evaluated as a -host name in the local domain, and that means the top domains (or ideally, -every domain) in your resolver's search path had better have something by -that name. -.sh 2 "Standard Resource Record Format" -.pp -The records in the name server data files are called resource records. -The Standard Resource Record Format (RR) is specified in RFC1035. -The following is a general description of these records: -.TS -l l l l l. -\fI{name} {ttl} addr-class Record Type Record Specific data\fP -.TE -Resource records have a standard format shown above. -The first field is always the name of the domain record -and it must always start in column 1. -For all RR's other than the first in a file, the name may be left blank; -in that case it takes on the name of the previous RR. -The second field is an optional time to live field. -This specifies how long this data will be stored in the data base. -By leaving this field blank the default time to live is specified -in the \fIStart Of Authority\fP resource record (see below). -The third field is the address class; currently, only one class is supported: -\fIIN\fP for internet addresses and other internet information. Limited -support is included for the \fIHS\fP class, which is for MIT/Athena ``Hesiod'' -information. -The fourth field states the type of the resource record. -The fields after that are dependent on the type of the RR. -Case is preserved in names and data fields when loaded into the name server. -All comparisons and lookups in the name server data base are case insensitive. -.bl -.b -The following characters have special meanings: -.ip ``\fB.\fP'' -A free standing dot in the name field refers to the root domain. -.ip ``@'' -A free standing @ in the name field denotes the current origin. -.ip "``\eX''" -Where X is any character other than a digit (0-9), -quotes that character so that its special meaning does not apply. -For example, ``\e.'' can be used to place a dot character in a label. -.ip "``\eDDD''" -Where each D is a digit, is the octet corresponding to the -decimal number described by DDD. -The resulting octet is assumed to be text and -is not checked for special meaning. -.ip "``( )''" -Parentheses are used to group data that crosses a line. -In effect, line terminations are not recognized within parentheses. -(At present, this notation only works for SOA RR's and is not optional.) -.ip "``;''" -Semicolon starts a comment; the remainder of the line is ignored. Note -that a completely blank line is also considered a comment, and ignored. -.ip "``*''" -An asterisk signifies wildcarding. Note that this is just another data -character whose special meaning comes about only during internal name -server search operations. Wildcarding is only meaningful for some RR -types (notably \fIMX\fP), and then only in the name field \(em not in -the data fields. -.pp -Anywhere a name appears \(em either in the name field or in some data field -defined to contain names \(em the current origin will be appended if the -name does not end in a ``\fB\|.\|\fP''. -This is useful for appending the current domain name to the data, -such as machine names, but may cause problems where you do not want -this to happen. -A good rule of thumb is that, if the name is not in the domain for which -you are creating the data file, end the name with a ``\fB.\fP''. -.sh 3 $INCLUDE -.pp -An include line begins with $INCLUDE, starting in column 1, -and is followed by a file name, and, optionally, by a new -temporary $ORIGIN to be used while reading this file. -This feature is -particularly useful for separating different types of data into multiple files. -An example would be: -.(b l -$INCLUDE /usr/local/adm/named/data/mail-exchanges -.)b -The line would be interpreted as a request to load the file -\fI/usr/local/adm/named/data/mail-exchanges\fP. The $INCLUDE command does not cause -data to be loaded into a different zone or tree. This is simply a way to -allow data for a given primary zone to be organized in separate files. -Not even the ``temporary $ORIGIN'' feature described above is sufficient -to cause your data to branch out into some other zone \(em zone boundaries -can only be introduced in the boot file. -.pp -A $INCLUDE file must have a name on its first RR. That is, the first -character of the first non-comment line must not be a space. The current -default name in the parent file \fIdoes not\fP carry into the $INCLUDE -file. -.sh 3 $ORIGIN -.pp -The origin is a way of changing the origin in a data file. The line starts -in column 1, and is followed by a domain origin. This seems like it could -be useful for putting more then one zone into a data file, but that's not -how it works. The name server fundamentally requires a given zone to map -entirely to some specific file. You should therefore be very careful to use -$ORIGIN only once at the top of a file, or, within a file, to change to a -``lower'' domain in the zone \(em never to some other zone altogether. -.sh 3 "SOA - Start Of Authority" -.(b L -.TS -l l l l l l. -\fIname {ttl} addr-class SOA Origin Person in charge\fP -@ IN SOA ucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP kjd\fB.\fPucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP ( - 1995122103 ; Serial - 10800 ; Refresh - 1800 ; Retry - 3600000 ; Expire - 259200 ) ; Minimum -.TE -.)b -The \fIStart of Authority, SOA,\fP record designates the start of a zone. -The name is the name of the zone and is often given as ``@'' since this -is always the current $ORIGIN and the SOA RR is usually the first record -of the primary zone file. -Origin is the name of the host on which this data file resides (in other -words, the \fIprimary master\fP server for this zone.) -Person in charge is the e-mail address for the person responsible -for the name server, with ``@'' changed to a ``.''. -The serial number is the version number of this data file and must be a -positive integer. -This number must be incremented whenever a change is made to the data. -Older servers permitted the use of a phantom ``.'' in this and other -numbers in a zone file; the meaning of n.m was ``n000m'' rather than the -more intuitive ``n*1000+m'' (such that 1.234 translated to 1000234 rather -than to 1234). This feature has been deprecated due to its -obscurity, unpredictability, and lack of necessity. -Note that using a ``YYYYMMDDNN'' notation you can still make 100 changes -per day until the year 4294. You should choose a notation that works for -you. If you're a clever \fIperl\fP programmer you could even use \fIRCS\fP -version numbers to help generate your zone serial numbers. -The refresh indicates how often, in seconds, the secondary name servers -are to check with the primary name server to see if an update is needed. -The retry indicates how long, in seconds, a secondary server should wait -before retrying a failed zone transfer. -Expire is the upper limit, in seconds, that a secondary name server -is to use the data before it expires for lack of getting a refresh. -Minimum is the default number of seconds to be used for the Time To Live -field on resource records which do not specify one in the zone file. -It is also an enforced minimum on Time To Live if it is specified on -some resource record (RR) in the zone. -There must be exactly one \fISOA\fP record per zone. -.sh 3 "NS - Name Server" -.TS -l l l l l. -\fI{name} {ttl} addr-class NS Name servers name\fP - IN NS ucbarpa\fB\|.\|\fPBerkeley\fB\|.\|\fPEdu\fB.\fP -.TE -The \fIName Server\fP record, \fINS\fP, lists a name server responsible -for a given domain, creating a \fIdelegation point\fP and a \fIsubzone\fP. -The first name field specifies the zone that is serviced by -the name server specified by the second name. -Every zone needs at least two name servers. -.bp \" ----PLACEMENT HACK---- -.sh 3 "A - Address" -.TS -l l l l l. -\fI{name} {ttl} addr-class A address\fP -ucbarpa IN A 128\fB.\fP32\fB.\fP0\fB.\fP4 - IN A 10\fB.\fP0\fB.\fP0\fB.\fP78 -.TE -The \fIAddress\fP record, \fIA\fP, lists the address for a given machine. -The name field is the machine name and the address is the network address. -There should be one \fIA\fP record for each address of the machine. -.sh 3 "HINFO - Host Information" -.TS -l l l l l l. -\fI{name} {ttl} addr-class HINFO Hardware OS\fP - IN HINFO VAX-11/780 UNIX -.TE -\fIHost Information\fP resource record, \fIHINFO\fP, is for host specific -data. This lists the hardware and operating system that are running at the -listed host. If you want to include a space in the machine name you must -quote the name (using ``"'' characters.) There could be one \fIHINFO\fP -record for each host, though for security reasons most domains don't have -any \fIHINFO\fP records at all. No application depends on them. -.(b L -.sh 3 "WKS - Well Known Services" -.TS -l l l l l l l. -\fI{name} {ttl} addr-class WKS address protocol list of services\fP - IN WKS 128\fB.\fP32\fB.\fP0\fB.\fP10 UDP who route timed domain - IN WKS 128\fB.\fP32\fB.\fP0\fB.\fP10 TCP ( echo telnet - discard sunrpc sftp - uucp-path systat daytime - netstat qotd nntp - link chargen ftp - auth time whois mtp - pop rje finger smtp - supdup hostnames - domain - nameserver ) -.TE -The \fIWell Known Services\fP record, \fIWKS\fP, describes the well known -services supported by a particular protocol at a specified address. The -list of services and port numbers come from the list of services specified -in \fI/etc/services.\fP There should be only one \fIWKS\fP record per -protocol per address. Note that RFC1123 says of \fIWKS\fP records: -.)b -.(l L - 2.2 Using Domain Name Service - ... - An application SHOULD NOT rely on the ability to locate a WKS - record containing an accurate listing of all services at a - particular host address, since the WKS RR type is not often used - by Internet sites. To confirm that a service is present, simply - attempt to use it. - ... - 5.2.12 WKS Use in MX Processing: RFC-974, p. 5 - - RFC-974 [SMTP:3] recommended that the domain system be queried - for WKS ("Well-Known Service") records, to verify that each - proposed mail target does support SMTP. Later experience has - shown that WKS is not widely supported, so the WKS step in MX - processing SHOULD NOT be used. - ... - 6.1.3.6 Status of RR Types - ... - The TXT and WKS RR types have not been widely used by - Internet sites; as a result, an application cannot rely - on the existence of a TXT or WKS RR in most - domains. -.)l -.sh 3 "CNAME - Canonical Name" -.TS -l l l l l. -\fIalias {ttl} addr-class CNAME Canonical name\fP -ucbmonet IN CNAME monet -.TE -The \fICanonical Name\fP resource record, \fICNAME\fP, specifies an -alias or nickname for the official, or canonical, host name. -This record must be the only one associated with the alias name. -All other resource records must be -associated with the canonical name, not with the nickname. -Any resource records that include a domain name as their value -(e.g., NS or MX) \fImust\fP list the canonical name, not the nickname. -Similarly, a CNAME will be followed when searching for A RRs, but not -for MX RRs or NS RRs or most other types of RRs. CNAMEs are allowed -to point to other CNAMEs, but this is considered sloppy. -.pp -Nicknames are useful when a well known host changes its name. In that -case, it is usually a good idea to have a \fICNAME\fP record so that -people still using the old name will get to the right place. -.sh 3 "PTR - Domain Name Pointer" -.TS -l l l l l. -\fIname {ttl} addr-class PTR real name\fP -7.0 IN PTR monet\fB\|.\|\fPBerkeley\fB\|.\|\fPEdu\fB\|.\fP -.TE -A \fIDomain Name Pointer\fP record, \fIPTR\fP, allows special names to point -to some other location in the domain. The above example of a \fIPTR\fP -record is used in setting up reverse pointers for the special -\fIIN-ADDR\fP\fB\|.\|\fP\fIARPA\fP domain. This line is from the example -\fIhosts.rev\fP file. \fIPTR\fP records are needed by the -\fIgethostbyaddr\fP function. Note the trailing ``\fB\|.\|\fP'' which -prevents \s-1BIND\s+1 from appending the current \s-1$ORIGIN\s+1 to that -domain name. -.sh 3 "MX - Mail Exchange" -.TS -l l l l l l. -\fIname {ttl} addr-class MX preference value mail exchange\fP -Munnari\fB\|.\|\fPOZ\fB\|.\|\fPAU\fB\|.\fP IN MX 0 Seismo\fB\|.\|\fPCSS\fB\|.\|\fPGOV\fB\|.\fP -*\fB\|.\|\fPIL\fB\|.\fP IN MX 0 RELAY\fB\|.\|\fPCS\fB\|.\|\fPNET\fB\|.\fP -.TE -\fIMail eXchange\fP records, \fIMX\fP, are used to specify a list of hosts -which are configured to receive mail sent to this domain name. Every name -which receives mail should have an \fIMX\fP since if one is not found at the -time mail is being delivered, an \fIMX\fP will be ``imputed'' with a cost -of 0 and a destination of the host itself. If you want a host to receive -its own mail, you should create an \fIMX\fP for your host's name, pointing -at your host's name. It is better to have this be explicit than to let it -be imputed by remote mailers. -In the first example, above, -Seismo\fB\|.\|\fPCSS\fB\|.\|\fPGOV\fB\|.\fP is a mail gateway that knows how -to deliver mail to Munnari\fB\|.\|\fPOZ\fB\|.\|\fPAU\fB\|.\fP. These two -machines may have a private connection or use a different transport medium. -The preference value is the order that a mailer should follow when there is -more than one way to deliver mail to a single machine. Note that lower -numbers indicate higher precedence, and that mailers are supposed to randomize -same-valued \fIMX\fP hosts so as to distribute the load evenly if the costs -are equal. See RFC974 for more detailed information. -.pp -Wildcard names containing the character ``*'' may be used for mail routing -with \fIMX\fP records. There are likely to be servers on the network that -simply state that any mail to a domain is to be routed through a relay. -Second example, above, all mail to hosts in the domain IL is routed through -RELAY.CS.NET. This is done by creating a wildcard resource record, which -states that *.IL has an \fIMX\fP of RELAY.CS.NET. Wildcard \fIMX\fP records -are not very useful in practice, though, since once a mail message gets to -the gateway for a given domain it still has to be routed \fIwithin\fP that -domain and it is not currently possible to have an apparently-different set -of \fIMX\fP records inside and outside of a domain. If you won't be needing -any Mail Exchanges inside your domain, go ahead and use a wildcard. If you -want to use both wildcard ``top-level'' and specific ``interior'' \fIMX\fP -records, note that each specific record will have to ``end with'' a complete -recitation of the same data that is carried in the top-level record. This -is because the specific \fIMX\fP records will take precedence over the -top-level wildcard records, and must be able to perform the top-level's -if a given interior domain is to be able to receive mail from outside the -gateway. Wildcard \fIMX\fP records are very subtle and you should be careful -with them. -.sh 3 "TXT - Text" -.TS -l l l l l l. -\fIname {ttl} addr-class TXT string\fP -Munnari\fB\|.\|\fPOZ\fB\|.\|\fPAU\fB\|.\fP IN TXT "foo" -.TE -A \fITXT\fP record contains free-form textual data. The syntax of the text -depends on the domain where it is found; many systems use \fITXT\fP records -to encode local data in a stylized format. MIT Hesiod is one such system. -.sh 3 "RP - Responsible Person" -.TS -l l l l l l. -\fIowner {ttl} addr-class RP mbox-domain-name TXT-domain-name\fP -franklin IN RP ben.franklin.berkeley.edu. sysadmins.berkeley.edu. -.TE -.pp -The Responsible Person record, \fIRP\fP, identifies the name or group name of -the responsible person for a host. Often it is desirable to be able to -identify the responsible entity for a particular host. When that host -is down or malfunctioning, you would want to contact those parties -who might be able to repair the host. -.pp -The first field, \fImbox-domain-name\fP, is a domain name that specifies the -mailbox for the responsible person. Its format in a zone file uses -the \s-1DNS\s+1 convention for mailbox encoding, identical to that used for -the \fIPerson-in-charge\fP mailbox field in the SOA record. -In the example above, the \fImbox-domain-name\fP shows the encoding for -``\fB<ben@franklin.berkeley.edu>\fP''. -The root domain name (just ``\fB\|.\|\fP'') may be specified -to indicate that no mailbox is available. -.pp -The second field, \fITXT-domain-name\fP, is a domain name for which -\fITXT\fP records exist. A subsequent query can be performed to retrieve -the associated \fITXT\fP resource records at \fITXT-domain-name\fP. This -provides a level of indirection so that the entity can be referred to from -multiple places in the \s-1DNS\s+1. The root domain name (just -``\fB\|.\|\fP'') may be specified for \fITXT-domain-name\fI to indicate -that no associated \fITXT\fP RR exists. In the example above, -``\fBsysadmins.berkeley.edu.\fP'' is the name of a TXT record that might -contain some text with names and phone numbers. -.pp -The format of the \fIRP\fP record is class-insensitive. -Multiple \fIRP\fP records at a single name may be present in the database, -though they should have identical TTLs. -.pp -The \fIRP\fP record is still experimental; not all name servers implement -or recognize it. -.sh 3 "AFSDB - DCE or AFS Server" -.TS -l l l l l l. -\fIname {ttl} addr-class AFSDB subtype server host name\fP -toaster.com. IN AFSDB 1 jack.toaster.com. -toaster.com. IN AFSDB 1 jill.toaster.com. -toaster.com. IN AFSDB 2 tracker.toaster.com. -.TE -\fIAFSDB\fP records are used to specify the hosts that provide a style of -distributed service advertised under this domain name. A subtype value -(analogous to the ``preference'' value in the \fIMX\fP record) indicates -which style of distributed service is provided with the given name. -Subtype 1 indicates that the named host is an AFS (R) database server for -the AFS cell of the given domain name. Subtype 2 indicates that the -named host provides intra-cell name service for the DCE (R) cell named by -the given domain name. -In the example above, jack\fB\|.\|\fPtoaster\fB\|.\|\fPcom and -jill\fB\|.\|\fPtoaster\fB\|.\|\fPcom are declared to be AFS database -servers for the toaster\fB\|.\|\fPcom AFS cell, so that AFS clients -wishing service from toaster\fB\|.\|\fPcom are directed to those two hosts -for further information. The third record declares that -tracker\fB\|.\|\fPtoaster\fB\|.\|\fPcom houses a directory server for the -root of the DCE cell toaster\fB\|.\|\fPcom, so that DCE clients that wish -to refer to DCE services should consult with the host -tracker\fB\|.\|\fPtoaster\fB\|.\|\fPcom for further information. The -DCE sub-type of record is usually accompanied by a \fITXT\fP record for -other information specifying other details to be used in accessing the -DCE cell. RFC1183 contains more detailed information on the use of -this record type. -.pp -The \fIAFSDB\fP record is still experimental; not all name servers implement -or recognize it. - -.sh 3 "PX - Pointer to X.400/RFC822 mapping information" -.TS -l l l l l l l. -\fIname {ttl} addr-class PX prefer 822-dom X.400-dom\fP -*.ADMD-garr.X42D.it. IN PX 50 it. ADMD-garr.C-it. -*.infn.it. IN PX 50 infn.it. O.PRMD-infn.ADMD-garr.C-it. -*.it. IN PX 50 it. O-gate.PRMD-garr.ADMD-garr.C-it. -.TE -.pp -The \fIPX\fP records (\fIPointer to X.400/RFC822 mapping information\fP) -are used to specify address mapping rules between X.400 O/R addresses and -RFC822 style (domain-style) mail addresses. For a detailed description of the -mapping process please refer to RFC1327. -.pp -Mapping rules are of 3 different types: -.pp -1) mapping from X.400 to RFC822 (defined as "table 1 rules" in RFC1327) -.pp -2) mapping from RFC822 to X.400 (defined as "table 2 rules" in RFC1327) -.pp -3) encoding RFC822 into X.400 (defined as "gate table" in RFC1327) -.pp -All three types of mapping rules are specified using \fIPX\fP Resource -Records in DNS, although the \fIname\fP value is different: for case 1, the -\fIname\fP value is an X.400 domain in DNS syntax, whereas for cases 2 and -3 the \fIname\fP value is an RFC822 domain. Refer to RFC-1664 for details -on specifying an X.400 domain in DNS syntax and for the use of the -\fIX42D\fP keyword in it. Tools are available to convert from RFC1327 -tables format into DNS files syntax. \fIPreference\fP is analogous to the -\fIMX\fP RR Preference parameter: it is currently advised to use a fixed -value of 50 for it. \fI822-dom\fP gives the RFC822 part of the mapping -rules, and \fIX.400-dom\fP gives the X.400 part of the mapping rule (in DNS -syntax). It is currently advised always to use wildcarded \fIname\fP -values, as the RFC1327 tables specifications permit wildcard -specifications only. This is to keep compatibility with existing services -using static RFC1327 tables instead of DNS \fIPX\fP information. -.pp -Specifications of mapping rules from X.400 to RFC822 syntax requires the -creation of an appropriate X.400 domain tree into DNS, including thus specific -\fISOA\fP and \fINS\fP records for the domain itself. Specification of mapping -rules from RFC822 into X.400 can be embedded directly into the normal direct -\fIname\fP tree. -Again, refer to RFC1664 for details about organization of this structure. -.pp -Tools and library routines, based on the standard resolver ones, are available -to retrieve from DNS the appropriate mapping rules in RFC1327 or DNS syntax. -.pp -Once again, refer to RFC1664 to use the \fIPX\fP resource record, and be careful -in coordinating the mapping information you can specify in DNS with the same -information specified into the RFC1327 static tables. -.pp -The \fIPX\fP record is still experimental; not all servers implement or -recognize it. - -.sh 2 "Discussion about the TTL" -.pp -The Time To Live assigned to the records and to the zone via the -Minimum field in the SOA record is very important. High values will -lead to lower BIND network traffic and faster response time. Lower -values will tend to generate lots of requests but will allow faster -propagation of changes. -.pp -Only changes and deletions from the zone are affected by the TTLs. -Additions propagate according to the Refresh value in the SOA. -.pp -Experience has shown that sites use default TTLs for their zones varying -from around 0.5 day to around 7 days. You may wish to consider boosting -the default TTL shown in former versions of this guide from one day -(86400 seconds) to three days (259200 seconds). This will drastically -reduce the number of requests made to your name servers. -.pp -If you need fast propagation of changes and deletions, it might be wise -to reduce the Minimum field a few days before the change, then do the -modification itself and augment the TTL to its former value. -.pp -If you know that your zone is pretty stable (you mainly add new records -without deleting or changing old ones) then you may even wish to consider -a TTL higher than three days. -.pp -Note that in any case, it makes no sense to have records with a TTL -below the SOA Refresh delay, as Delay is the time required for secondaries -to get a copy of the newly modified zone. - -.sh 2 "About ``secure zones'' -.pp -Secure zones implement named security on a zone by zone basis. It is -designed to use a permission list of networks or hosts which may obtain -particular information from the zone. -.pp -In order to use zone security, \fInamed\fP must be compiled with SECURE_ZONES -defined and you must have at least one secure_zone TXT RR. Unless a -\fIsecure_zone\fP record exists for a given zone, no restrictions will be -applied to the data in that zone. The format of the secure_zone TXT RR is: -.lp -secure_zone\h'0.5i'addr-class\h'0.5i'TXT\h'0.5i'string -.pp -The addr-class may be either \fIHS\fP or \fIIN\fP. The syntax for the TXT -string is either ``network address:netmask'' or ``host IP address:H''. -.pp -``network address:netmask'' allows queries from an entire network. If the -netmask is omitted, named will use the default netmask for the network -address specified. -.pp -``host IP address:H'' allows queries from a host. The ``H'' after the ``:'' -is required to differentiate the host address from a network address. -Multiple secure_zone TXT RRs are allowed in the same zone file. -.pp -For example, you can set up a zone to only answer Hesiod requests from the -masked class B network 130.215.0.0 and from host 128.23.10.56 by adding the -following two TXT RR's: -.lp -secure_zone\h'0.5i'HS\h'0.5i'TXT\h'0.5i'``130.215.0.0:255.255.0.0'' -secure_zone\h'0.5i'HS\h'0.5i'TXT\h'0.5i'``128.23.10.56:H'' -.pp -This feature can be used to restrict access to a Hesiod password map or to -separate internal and external internet address resolution on a firewall -machine without needing to run a separate named for internal and external -address resolution. -.pp -Note that you will need to include your loopback interface (127.0.0.1) in -your secure_zone record, or your local clients won't be able to resolve -names. - -.sh 2 "About Hesiod, and HS-class Resource Records -.pp -Hesiod, developed by \s-1MIT\s+1 Project Athena, is an information service -built upon \s-1BIND\s+1. Its intent is similar to that of Sun's -\s-1NIS\s+1: to furnish information about users, groups, network-accessible -file systems, printcaps, and mail service throughout an installation. Aside -from its use of \s-1BIND\s+1 rather than separate server code another -important difference between Hesiod and \s-1NIS\s+1 is that Hesiod is not -intended to deal with passwords and authentication, but only with data that -are not security sensitive. Hesiod servers can be implemented by adding -resource records to \s-1BIND\s+1 servers; or they can be implemented as -separate servers separately administered. -.pp -To learn about and obtain Hesiod make an anonymous \s-1FTP\s+1 connection to -host \s-1ATHENA-DIST.MIT.EDU\s+1 and retrieve the compressed tar file -\fB/pub/ATHENA/hesiod.tar.Z\fP. You will not need the named and resolver -library portions of the distribution because their functionality has already -been integrated into \s-1BIND as of 4.9\s+1. To learn how Hesiod functions -as part of the Athena computing environment obtain the paper -\fB/pub/ATHENA/usenix/athena-changes.PS\fP from the above \s-1FTP\s+1 server -host. There is also a tar file of sample Hesiod resource files. -.pp -Whether one should use Hesiod class is open to question, since the same -services can probably be provided with class IN, type TXT and type -CNAME records. In either case, the code and documents for Hesiod will -suggest how to set up and use the service. -.pp -Note that while \s-1BIND\s+1 includes support for \fIHS\fP-class queries, -the zone transfer logic for non-\fIIN\fP-class zones is still experimental. - -.sh 2 "Sample Files" -.pp -The following section contains sample files for the name server. -This covers example boot files for the different types of servers -and example domain data base files. diff --git a/contrib/bind/doc/bog/intro.me b/contrib/bind/doc/bog/intro.me deleted file mode 100644 index 597fa44..0000000 --- a/contrib/bind/doc/bog/intro.me +++ /dev/null @@ -1,75 +0,0 @@ -.\" ++Copyright++ 1986, 1988 -.\" - -.\" Copyright (c) 1986, 1988 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" - -.\" Portions Copyright (c) 1993 by Digital Equipment Corporation. -.\" -.\" Permission to use, copy, modify, and distribute this software for any -.\" purpose with or without fee is hereby granted, provided that the above -.\" copyright notice and this permission notice appear in all copies, and that -.\" the name of Digital Equipment Corporation not be used in advertising or -.\" publicity pertaining to distribution of the document or software without -.\" specific, written prior permission. -.\" -.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL -.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES -.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT -.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL -.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR -.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS -.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS -.\" SOFTWARE. -.\" - -.\" --Copyright-- -.\" -.\" @(#)intro.me 6.2 (Berkeley) 2/28/88 -.\" -.sh 1 Introduction -.pp -The Berkeley Internet Name Domain (\s-1BIND\s+1) implements an Internet name -server for \s-2BSD\s+2-derived operating systems. The \s-1BIND\s+1 consists -of a server (or ``daemon'') called \fInamed\fP and a \fIresolver\fP library. -A name server is a network service that enables clients to name resources or -objects and share this information with other objects in the network. This -in effect is a distributed data base system for objects in a computer -network. The \s-1BIND\s+1 server runs in the background, servicing queries -on a well known network port. The standard port for UDP and TCP is specified -in \fI/etc/services\fP. The \fIresolver\fP is a set of routines residing -in a system library that provides the interface that programs can use to -access the domain name services. -.pp -BIND is fully integrated into BSD (4.3 and later releases) -network programs for use in storing and retrieving host names and address. -The system administrator can configure the system to use BIND as a -replacement to the older host table lookup of information in the network -hosts file \fI/etc/hosts\fP. The default configuration for BSD uses -BIND. diff --git a/contrib/bind/doc/bog/manage.me b/contrib/bind/doc/bog/manage.me deleted file mode 100644 index 6f17b80..0000000 --- a/contrib/bind/doc/bog/manage.me +++ /dev/null @@ -1,156 +0,0 @@ -.\" ++Copyright++ 1986, 1988, 1995 -.\" - -.\" Copyright (c) 1986, 1988, 1995 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" - -.\" Portions Copyright (c) 1993 by Digital Equipment Corporation. -.\" -.\" Permission to use, copy, modify, and distribute this software for any -.\" purpose with or without fee is hereby granted, provided that the above -.\" copyright notice and this permission notice appear in all copies, and that -.\" the name of Digital Equipment Corporation not be used in advertising or -.\" publicity pertaining to distribution of the document or software without -.\" specific, written prior permission. -.\" -.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL -.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES -.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT -.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL -.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR -.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS -.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS -.\" SOFTWARE. -.\" - -.\" --Copyright-- -.\" -.\" @(#)manage.me 6.6 (Berkeley) 9/19/89 -.\" $Id: manage.me,v 8.4 1995/12/22 10:20:24 vixie Exp $ -.\" -.sh 1 "Domain Management" -.pp -This section contains information for starting, controlling and debugging -\fInamed\fP. -.sh 2 /etc/rc.local -.pp -The hostname should be set to the full domain style name in -\fI/etc/rc.local\fP using \fIhostname\|(1)\fP. The following entry should -be added to \fI/etc/rc.local\fP to start up \fInamed\fP at system boot time: -.(b l -\fIif [ -f /usr/sbin/named ]; then - /usr/sbin/named\fP [options] \fI& echo -n ' named' >/dev/console\fP -\fIfi\fP -.)b -This usually directly follows the lines that start \fIsyslogd\fP. -\fBDo Not\fP attempt to run \fInamed\fP from \fIinetd\fP. -This will -continuously restart the name server and defeat the purpose of the cache. -.sh 2 /var/run/named.pid -.pp -When \fInamed\fP is successfully started up it writes its process id into -the file \fI/var/run/named.pid\fP. This is useful to programs that want to -send signals to \fInamed\fP. The name of this file may be changed by defining -\fIPIDFILE\fP to the new name when compiling \fInamed\fP. -.sh 2 /etc/hosts -.pp -The \fIgethostbyname\|()\fP library call can detect if \fInamed\fP is running. -If it is determined that \fInamed\fP is not running it will look in -\fI/etc/hosts\fP to resolve an address. -This option was added to allow \fIifconfig\|(8C)\fP to configure the machines -local interfaces and to enable a system manager to access the network -while the system is in single user mode. -It is advisable to put the local machines interface addresses and a couple of -machine names and address in -\fI/etc/hosts\fP so the system manager can rcp files from another machine -when the system is in single user mode. -The format of \fI/etc/hosts\fP has not changed. See \fIhosts\|(5)\fP -for more information. -Since the process of reading \fI/etc/hosts\fP is slow, -it is not advisable to use this option when the system is in multi user mode. - -.sh 2 Signals -.pp -There are several signals that can be sent to the \fInamed\fP process -to have it do tasks without restarting the process. -.sh 3 Reload -.pp -SIGHUP - -Causes \fInamed\fP to read \fInamed.boot\fP and reload the database. -This is useful when you have made a change to a ``primary'' data file -and you want \fInamed\fP\|'s internal database to reflect the change. -If you build \s-1BIND\s+1 with the \s-1FORCED_RELOAD\s+1 option, then -\s-1SIGHUP\s+1 also has the effect of scheduling all ``secondary'' zones -for serial-number checks, which could lead to zone transfers ahead of -the usual schedule. Normally serial-number compares are done only at -the intervals specified in the zone's \s-1SOA\s+1 record. -.sh 3 Debugging -.pp -When \fInamed\fP is running incorrectly, look first in -\fI/var/log/messages\fP and check for any messages logged by \fIsyslog\fP. -Next send it a signal to see what is happening. Unless you run it with the -``-d'' option, \fInamed\fP has very little to say on its standard output or -standard error. Everything \fInamed\fP has to say, it says to \fIsyslog\fP. -.pp -SIGINT - -Dumps the current data base and cache to -\fI/var/tmp/named_dump.db\fP -This should give you an indication to whether the data base was loaded -correctly. -The name of the dump file may be changed -by defining \fIDUMPFILE\fP to the new name when compiling \fInamed\fP. - -\fINote:\fP the following two signals only work when \fInamed\fP is built with -\fIDEBUG\fP defined. -.pp -SIGUSR1 - -Turns on debugging. Each following SIGUSR1 increments the debug level. -The output goes to \fI/var/tmp/named.run\fP -The name of this debug file may be changed -by defining \fIDEBUGFILE\fP to the new name before compiling \fInamed\fP. -.pp -SIGUSR2 - -Turns off debugging completely. - -For more detailed debugging, define DEBUG when compiling the resolver -routines into \fI/lib/libc.a\fP. -.pp -SIGWINCH - -Toggles tracing of all incoming queries if \fInamed\fP has been -compiled with \fIQRYLOG\fP defined. The trace is sent to syslog, and -is huge, but it is very useful for tracking down problems. - -To run with tracing of all queries specify the \fI-q\fP flag on the -command line. If you routinely log queries you will probably want to -analyze the results using the dnsstats stats script in the -contrib directory. -.pp -SIGIOT - -Dumps statistics data into \fI/var/tmp/named.stats\fP if the server -is built with \fISTATS\fP defined. Statistics are appended to the file. diff --git a/contrib/bind/doc/bog/named.boot.cache b/contrib/bind/doc/bog/named.boot.cache deleted file mode 100644 index 5e0e3d3..0000000 --- a/contrib/bind/doc/bog/named.boot.cache +++ /dev/null @@ -1,77 +0,0 @@ -.\" ++Copyright++ 1986, 1988 -.\" - -.\" Copyright (c) 1986, 1988 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" - -.\" Portions Copyright (c) 1993 by Digital Equipment Corporation. -.\" -.\" Permission to use, copy, modify, and distribute this software for any -.\" purpose with or without fee is hereby granted, provided that the above -.\" copyright notice and this permission notice appear in all copies, and that -.\" the name of Digital Equipment Corporation not be used in advertising or -.\" publicity pertaining to distribution of the document or software without -.\" specific, written prior permission. -.\" -.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL -.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES -.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT -.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL -.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR -.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS -.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS -.\" SOFTWARE. -.\" - -.\" --Copyright-- -.\" -.\" @(#)named.boot.cache 6.4 (Berkeley) 9/19/89 -.\" -.ne 13v -.sh 4 "Caching Only Server" -.(b L -.TS -l. -; -; Boot file for Caching Only Name Server -; -.TE -.TS -l l l -l -l l l. -; type domain source file or host -; -directory /usr/local/adm/named -cache \fB.\fP root\fB.\fPcache -primary 0\fB.\fP0\fB.\fP127\fB.\fPin-addr\fB.\fParpa named\fB.\fPlocal -.TE -.)b - - diff --git a/contrib/bind/doc/bog/named.boot.primary b/contrib/bind/doc/bog/named.boot.primary deleted file mode 100644 index 0f3c3ca..0000000 --- a/contrib/bind/doc/bog/named.boot.primary +++ /dev/null @@ -1,78 +0,0 @@ -.\" ++Copyright++ 1986, 1988 -.\" - -.\" Copyright (c) 1986, 1988 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" - -.\" Portions Copyright (c) 1993 by Digital Equipment Corporation. -.\" -.\" Permission to use, copy, modify, and distribute this software for any -.\" purpose with or without fee is hereby granted, provided that the above -.\" copyright notice and this permission notice appear in all copies, and that -.\" the name of Digital Equipment Corporation not be used in advertising or -.\" publicity pertaining to distribution of the document or software without -.\" specific, written prior permission. -.\" -.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL -.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES -.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT -.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL -.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR -.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS -.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS -.\" SOFTWARE. -.\" - -.\" --Copyright-- -.\" -.\" @(#)named.boot.primary 6.4 (Berkeley) 9/19/89 -.\" -.ne 15v -.sh 3 "Boot Files" -.sh 4 "Primary Server" -.(b L -.TS -l. -; -; Boot file for Primary Name Server -; -.TE -.TS -l l l -l -l l l. -; type domain source file or host -; -directory /usr/local/adm/named -primary Berkeley\fB.\fPEdu ucbhosts -primary 32\fB.\fP128\fB.\fPin-addr\fB.\fParpa ucbhosts\fB.\fPrev -primary 0\fB.\fP0\fB.\fP127\fB.\fPin-addr\fB.\fParpa named\fB.\fPlocal -cache \fB.\fP root\fB.\fPcache -.TE -.)b diff --git a/contrib/bind/doc/bog/named.boot.secondary b/contrib/bind/doc/bog/named.boot.secondary deleted file mode 100644 index 64a607d..0000000 --- a/contrib/bind/doc/bog/named.boot.secondary +++ /dev/null @@ -1,77 +0,0 @@ -.\" ++Copyright++ 1986, 1988 -.\" - -.\" Copyright (c) 1986, 1988 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" - -.\" Portions Copyright (c) 1993 by Digital Equipment Corporation. -.\" -.\" Permission to use, copy, modify, and distribute this software for any -.\" purpose with or without fee is hereby granted, provided that the above -.\" copyright notice and this permission notice appear in all copies, and that -.\" the name of Digital Equipment Corporation not be used in advertising or -.\" publicity pertaining to distribution of the document or software without -.\" specific, written prior permission. -.\" -.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL -.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES -.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT -.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL -.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR -.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS -.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS -.\" SOFTWARE. -.\" - -.\" --Copyright-- -.\" -.\" @(#)named.boot.secondary 6.4 (Berkeley) 9/19/89 -.\" -.ne 12v -.sh 4 "Secondary Server" -.(b L -.TS -l. -; -; Boot file for Secondary Name Server -; -.TE -.TS -l l l -l -l l l. -; type domain source file or host -; -directory /usr/local/adm/named -secondary Berkeley\fB.\fPEdu 128\fB.\fP32\fB.\fP0\fB.\fP4 128\fB.\fP32\fB.\fP0\fB.\fP10 ucbhosts.bak -secondary 32\fB.\fP128\fB.\fPin-addr\fB.\fParpa 128\fB.\fP32\fB.\fP0\fB.\fP4 128\fB.\fP32\fB.\fP0\fB.\fP10 ucbhosts.rev.bak -primary 0\fB.\fP0\fB.\fP127\fB.\fPin-addr\fB.\fParpa named\fB.\fPlocal -cache \fB.\fP root\fB.\fPcache -.TE -.)b diff --git a/contrib/bind/doc/bog/named.local b/contrib/bind/doc/bog/named.local deleted file mode 100644 index 209c5be..0000000 --- a/contrib/bind/doc/bog/named.local +++ /dev/null @@ -1,75 +0,0 @@ -.\" ++Copyright++ 1986, 1988 -.\" - -.\" Copyright (c) 1986, 1988 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" - -.\" Portions Copyright (c) 1993 by Digital Equipment Corporation. -.\" -.\" Permission to use, copy, modify, and distribute this software for any -.\" purpose with or without fee is hereby granted, provided that the above -.\" copyright notice and this permission notice appear in all copies, and that -.\" the name of Digital Equipment Corporation not be used in advertising or -.\" publicity pertaining to distribution of the document or software without -.\" specific, written prior permission. -.\" -.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL -.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES -.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT -.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL -.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR -.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS -.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS -.\" SOFTWARE. -.\" - -.\" --Copyright-- -.\" -.\" @(#)named.local 6.3 (Berkeley) 5/24/89 -.\" -.ne 13v -.sh 3 "named.local" -.(b L - -.TS -l l l l l s. -@ IN SOA ucbvax\fB.\fPBerkeley\fB.\fPEdu. kjd\fB.\fPucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP ( -.T& -l l l l l. - 1994072100 ; Serial - 10800 ; Refresh - 1800 ; Retry - 3600000 ; Expire - 259200 ) ; Minimum -.T& -l l l l l s. - IN NS ucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP ; pedantic -1 IN PTR localhost\fB.\fP -.TE -.)b diff --git a/contrib/bind/doc/bog/ns.me b/contrib/bind/doc/bog/ns.me deleted file mode 100644 index ec3ca3c..0000000 --- a/contrib/bind/doc/bog/ns.me +++ /dev/null @@ -1,96 +0,0 @@ -.\" ++Copyright++ 1986, 1988 -.\" - -.\" Copyright (c) 1986, 1988 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" - -.\" Portions Copyright (c) 1993 by Digital Equipment Corporation. -.\" -.\" Permission to use, copy, modify, and distribute this software for any -.\" purpose with or without fee is hereby granted, provided that the above -.\" copyright notice and this permission notice appear in all copies, and that -.\" the name of Digital Equipment Corporation not be used in advertising or -.\" publicity pertaining to distribution of the document or software without -.\" specific, written prior permission. -.\" -.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL -.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES -.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT -.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL -.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR -.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS -.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS -.\" SOFTWARE. -.\" - -.\" --Copyright-- -.\" -.\" @(#)ns.me 6.3 (Berkeley) 9/19/89 -.\" -.sh 1 "The Name Service" -.pp -The basic function of the name server is to provide information about network -objects by answering queries. The specifications for this name server are -defined in RFC1034, RFC1035 and RFC974. These documents can be found in -\fI/usr/src/etc/named/doc\fP in 4.3BSD or \fIftp\fPed from -\fBftp.rs.internic.net\fP. -It is also recommended that you read the related manual pages, -\fInamed\fP\|(8), -\fIresolver\fP\|(3), -and \fIresolver\fP\|(5). -.pp -The advantage of using a name server over the host table lookup for host -name resolution is to avoid the need for a single centralized clearinghouse -for all names. The authority for this information can be delegated to the -different organizations on the network responsible for it. -.pp -The host table lookup routines require that the master file for the entire -network be maintained at a central location by a few people. This works -fine for small networks where there are only a few machines and the -different organizations responsible for them cooperate. But this does not -work well for large networks where machines cross organizational boundaries. -.pp -With the name server, the network can be broken into a hierarchy of domains. -The name space is organized as a tree according to organizational or -administrative boundaries. -Each node, called a \fIdomain\fP, is given a label, and the name of the -domain is the concatenation of all the labels of the domains from -the root to the current domain, listed from right to left separated by dots. -A label need only be unique within its domain. -The whole space is partitioned into several areas called \fIzones\fP, -each starting at a domain and extending down to the leaf domains or to -domains where other zones start. -Zones usually represent administrative boundaries. -An example of a host address for a host at the University of California, -Berkeley would look as follows: -.(b -\fImonet\fP\|\fB.\fP\|\fIBerkeley\fP\|\fB.\fP\|\fIEDU\fP -.)b -The top level domain for educational organizations is EDU; -Berkeley is a subdomain of EDU and monet is the name of the host. diff --git a/contrib/bind/doc/bog/resolv.conf b/contrib/bind/doc/bog/resolv.conf deleted file mode 100644 index 1f15991..0000000 --- a/contrib/bind/doc/bog/resolv.conf +++ /dev/null @@ -1,67 +0,0 @@ -.\" ++Copyright++ 1986, 1988 -.\" - -.\" Copyright (c) 1986, 1988 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" - -.\" Portions Copyright (c) 1993 by Digital Equipment Corporation. -.\" -.\" Permission to use, copy, modify, and distribute this software for any -.\" purpose with or without fee is hereby granted, provided that the above -.\" copyright notice and this permission notice appear in all copies, and that -.\" the name of Digital Equipment Corporation not be used in advertising or -.\" publicity pertaining to distribution of the document or software without -.\" specific, written prior permission. -.\" -.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL -.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES -.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT -.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL -.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR -.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS -.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS -.\" SOFTWARE. -.\" - -.\" --Copyright-- -.\" -.\" @(#)resolv.conf 6.2 (Berkeley) 2/29/88 -.\" -.ne 6v -.\" .bp -.sh 3 "Remote Server / DNS Client" -.sh 4 "/etc/resolv.conf" -.(b L - -domain Berkeley\fB.\fPEdu -nameserver 128\fB.\fP32\fB.\fP0\fB.\fP4 -nameserver 128\fB.\fP32\fB.\fP0\fB.\fP10 -sortlist 130.155.160.0/255.255.240.0 130.155.0.0 - -.)b diff --git a/contrib/bind/doc/bog/root.cache b/contrib/bind/doc/bog/root.cache deleted file mode 100644 index 3bf5727..0000000 --- a/contrib/bind/doc/bog/root.cache +++ /dev/null @@ -1,102 +0,0 @@ -.\" ++Copyright++ 1986, 1988 -.\" - -.\" Copyright (c) 1986, 1988 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" - -.\" Portions Copyright (c) 1993 by Digital Equipment Corporation. -.\" -.\" Permission to use, copy, modify, and distribute this software for any -.\" purpose with or without fee is hereby granted, provided that the above -.\" copyright notice and this permission notice appear in all copies, and that -.\" the name of Digital Equipment Corporation not be used in advertising or -.\" publicity pertaining to distribution of the document or software without -.\" specific, written prior permission. -.\" -.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL -.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES -.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT -.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL -.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR -.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS -.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS -.\" SOFTWARE. -.\" - -.\" --Copyright-- -.\" -.\" @(#)root.cache 6.4 (Berkeley) 4/29/90 -.\" -.ne 38v -.sh 3 "root.cache" -.(b L - -; -; This file holds the information on root name servers needed to -; initialize cache of Internet domain name servers -; (e.g. reference this file in the "cache . <file>" -; configuration file of BIND domain name servers). -; -; This file is made available by InterNIC registration services -; under anonymous FTP as -; file /domain/named.root -; on server FTP.RS.INTERNIC.NET -; -OR- under Gopher at RS.INTERNIC.NET -; under menu InterNIC Registration Services (NSI) -; submenu InterNIC Registration Archives -; file named.root -; -; last update: Oct 5, 1994 -; related version of root zone: 1994100500 -; -.TS -l l l l l. -\fB.\fP 604800 IN NS NS\fB.\fPINTERNIC\fB.\fPNET\fB.\fP -NS\fB.\fPINTERNIC\fB.\fPNET\fB.\fP 604800 IN A 198\fB.\fP41\fB.\fP0\fB.\fP4 -\fB.\fP 604800 IN NS NS1\fB.\fPISI\fB.\fPEDU\fB.\fP -NS1\fB.\fPISI\fB.\fPEDU\fB.\fP 604800 IN A 128\fB.\fP9\fB.\fP0\fB.\fP107 -\fB.\fP 604800 IN NS C\fB.\fPPSI\fB.\fPNET\fB.\fP -C\fB.\fPPSI\fB.\fPNET\fB.\fP 604800 IN A 192\fB.\fP33\fB.\fP4\fB.\fP12 -\fB.\fP 604800 IN NS TERP\fB.\fPUMD\fB.\fPEDU\fB.\fP -TERP\fB.\fPUMD\fB.\fPEDU\fB.\fP 604800 IN A 128\fB.\fP8\fB.\fP10\fB.\fP90 -\fB.\fP 604800 IN NS NS\fB.\fPNASA\fB.\fPGOV\fB.\fP -NS\fB.\fPNASA\fB.\fPGOV\fB.\fP 604800 IN A 128\fB.\fP102\fB.\fP16\fB.\fP10 - 604800 IN A 192\fB.\fP52\fB.\fP195\fB.\fP10 -\fB.\fP 604800 IN NS NS\fB.\fPISC\fB.\fPORG\fB.\fP -NS\fB.\fPISC\fB.\fPORG\fB.\fP 604800 IN A 192\fB.\fP5\fB.\fP5\fB.\fP241 -\fB.\fP 604800 IN NS NS\fB.\fPNIC\fB.\fPDDN\fB.\fPMIL\fB.\fP -NS\fB.\fPNIC\fB.\fPDDN\fB.\fPMIL\fB.\fP 604800 IN A 192\fB.\fP112\fB.\fP36\fB.\fP4 -\fB.\fP 604800 IN NS AOS\fB.\fPARL\fB.\fPARMY\fB.\fPMIL\fB.\fP -AOS\fB.\fPARL\fB.\fPARMY\fB.\fPMIL\fB.\fP 604800 IN A 128\fB.\fP63\fB.\fP4\fB.\fP82 - 604800 IN A 192\fB.\fP5\fB.\fP25\fB.\fP82 -\fB.\fP 604800 IN NS NIC\fB.\fPNORDU\fB.\fPNET\fB.\fP -NIC\fB.\fPNORDU\fB.\fPNET\fB.\fP 604800 IN A 192\fB.\fP36\fB.\fP148\fB.\fP17 -.TE -; End of File -.)b diff --git a/contrib/bind/doc/bog/setup.me b/contrib/bind/doc/bog/setup.me deleted file mode 100644 index fff7657..0000000 --- a/contrib/bind/doc/bog/setup.me +++ /dev/null @@ -1,88 +0,0 @@ -.\" ++Copyright++ 1986, 1988 -.\" - -.\" Copyright (c) 1986, 1988 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" - -.\" Portions Copyright (c) 1993 by Digital Equipment Corporation. -.\" -.\" Permission to use, copy, modify, and distribute this software for any -.\" purpose with or without fee is hereby granted, provided that the above -.\" copyright notice and this permission notice appear in all copies, and that -.\" the name of Digital Equipment Corporation not be used in advertising or -.\" publicity pertaining to distribution of the document or software without -.\" specific, written prior permission. -.\" -.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL -.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES -.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT -.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL -.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR -.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS -.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS -.\" SOFTWARE. -.\" - -.\" --Copyright-- -.\" -.\" @(#)setup.me 6.4 (Berkeley) 9/19/89 -.\" -.sh 1 "Setting up Your Own Domain" -.pp -When setting up a domain that is going to be on a public network the site -administrator should contact the organization in charge of the network and -request the appropriate domain registration form. An organization that -belongs to multiple networks (such as the \fIInternet\fP and -\fIBITNET\fP) should register with only one network. -.sh 2 "Internet" -.pp -Sites on the Internet who need information on setting up a domain should -contact the registrar for their network, which is one of the following: -.TS -l l. -MILnet \s-1HOSTMASTER\s+1@\s-1NIC\s+1\fB\|.\|\fP\s-1DDN\s+1\fB\|.\|\fP\s-1MIL\s+1 -other \s-1HOSTMASTER\s+1@\s-1INTERNIC\s+1\fB\|.\|\fP\s-1NET\s+1 -.TE -You may also want to be placed on the \s-1BIND\s+1 mailing list, which is a -mail group for people on the Internet who run \s-1BIND\s+1. The group -discusses future design decisions, operational problems, and other related -topic. The address to request being placed on this mailing list is: -.(b l -\fIbind-request\|@\|uunet\fP\fB\|.\|\fP\fIuu\fP\fB\|.\|\fP\fInet\fP -.)b -.sh 2 "Subdomains of Existing Domains" -.pp -If you want a subdomain of some existing domain, you should find the contact -point for the parent domain rather than asking one of the above top-level -registrars. There should be a convention that \fBregistrar\fP@\fIdomain\fP -or \fBhostmaster\fP@\fIdomain\fP for any given domain will always be an alias -for that domain's registrar (somewhat analogous to \fBpostmaster\fP), but -there is no such convention. Try it as a last resort, but first you should -examine the \fISOA\fP record for the domain and send mail to the ``responsible -person'' shown therein. You can also try \fIwhois\fP. diff --git a/contrib/bind/doc/bog/types.me b/contrib/bind/doc/bog/types.me deleted file mode 100644 index 9d14111..0000000 --- a/contrib/bind/doc/bog/types.me +++ /dev/null @@ -1,163 +0,0 @@ -.\" ++Copyright++ 1986, 1988, 1995 -.\" - -.\" Copyright (c) 1986, 1988, 1995 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" - -.\" Portions Copyright (c) 1993 by Digital Equipment Corporation. -.\" -.\" Permission to use, copy, modify, and distribute this software for any -.\" purpose with or without fee is hereby granted, provided that the above -.\" copyright notice and this permission notice appear in all copies, and that -.\" the name of Digital Equipment Corporation not be used in advertising or -.\" publicity pertaining to distribution of the document or software without -.\" specific, written prior permission. -.\" -.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL -.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES -.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT -.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL -.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR -.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS -.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS -.\" SOFTWARE. -.\" - -.\" --Copyright-- -.\" -.\" @(#)types.me 6.3 (Berkeley) 9/19/89 -.\" -.sh 1 "Types of Zones" -.pp -A ``zone'' is a point of delegation in the DNS tree. It contains all names -from a certain point ``downward'' except those which are delegated to other -zones. A ``delegation point'' has one or more \fINS\fP records in the -``parent zone'', which should be matched by equivalent \fINS\fP records at -the root of the ``delegated zone'' (i.e., the ``@'' name in the zone file). -.pp -Understanding the difference between a ``zone'' and a ``domain'' is crucial -to the proper operation of a name server. As an example, consider the -\s-1DEC.COM\s+1 \fIdomain\fP, which includes names such as -\s-1POBOX1.PA.DEC.COM\s+1 and \s-1QUABBIN.CRL.DEC.COM\s+1 even though -the \s-1DEC.COM\s+1 \fIzone\fP includes only \fIdelegations\fP for the -\s-1PA.DEC.COM\s+1 and \s-1CRL.DEC.COM\s+1 zones. A zone can map exactly -to a single domain, but could also include only part of a domain (the rest -of which could be delegated to other name servers). Technically speaking, -every name in the DNS tree is a ``domain'', even if it is ``terminal'', that -is, has no ``subdomains''. Technically speaking, every subdomain is a domain -and every domain except the root is also a subdomain. The terminology is not -intuitive and you would do well to read RFC's 1033, 1034, and 1035 to gain a -complete understanding of this difficult and subtle topic. -.pp -Though \s-1BIND\s+1 is a \fIDomain\fP Name Server, it deals primarily in terms -of \fIzones\fP. The \fIprimary\fP and \fIsecondary\fP declarations in the -\fInamed.boot\fP file specify \fIzones\fP, not \fIdomains\fP. When you ask -someone if they are willing to be a secondary server for your ``domain'', you -are actually asking for secondary service for some collection of \fIzones\fP. -.pp -Each zone will have one ``primary'' server, which loads the zone contents -from some local file which is edited by humans or perhaps generated -mechanically from some other local file which is edited by humans. Then -there will be some number of ``secondary'' servers, which load the zone -contents using the \s-1IP/DNS\s+1 protocol (that is, the secondary servers will -contact the primary and fetch the zone using \s-1IP/TCP\s+1). This set of -servers (the primary and all of the secondaries) should be listed in the -\fINS\fP records in the parent zone, which will constitute a ``delegation''. -This set of servers must also be listed in the zone file itself, usually -under the ``@'' name which is a magic cookie that means the ``top level'' -or ``root'' of current zone. You can list servers in the zone's -top-level ``@'' \fINS\fP records that are not in the parent's \fINS\fP -delegation, but you cannot list servers in the parent's delegation that are -not present in the zone's ``@''. Any servers listed in the \fINS\fP records -must be configured as authoritative (either primary or secondary) for the -zone. If a server listed in a \fINS\fP record is not authoritative, it -will respond with a ``lame delegation'' when queried. -.sh 1 "Types of Servers" -.pp -Servers do not really have ``types''. A server can be a primary for some -zones and a secondary for others, or it can be only a primary, or only a -secondary, or it can serve no zones and just answer queries via its ``cache''. -Previous versions of this document referred to servers as ``master'' and -``slave'' but we now feel that those distinctions \(em and the assignment of -a ``type'' to a name server \(em are not useful. -.sh 2 "Caching Only Server" -.pp -All servers are caching servers. This means that the server caches the -information that it receives for use until the data expires. A \fICaching -Only Server\fP is a server that is not authoritative for any zone. This -server services queries and asks other servers, who have the authority, for -the information needed. All servers keep data in their cache until the data -expires, based on a \fITTL\fP (``Time To Live'') field which is maintained -for all resource records. -.sh 2 "Remote Server" -.pp -A Remote Server is an option given to people who would like to use -a name server from their workstation or on a machine that has a limited -amount of memory and CPU cycles. -With this option you can run all of the networking programs that use -the name server without the name server running on the local machine. -All of the queries are serviced by a name server that is running on another -machine on the network. -A host which has an -\fI/etc/resolv.conf\fP file listing only remote hosts, and which does not -run a name server of its own, is sometimes called a Remote Server (because -the actual server is remote?) but more -often it is called simply a DNS Client. -This kind of host is technically not a ``server'', -since it has no cache and does not answer queries. -.sh 2 "Slave Server" -.pp -A Slave Server is a server that always forwards queries it cannot -satisfy from its cache, to a fixed list of \fIforwarding\fP servers -instead of interacting -with the name servers for the root and other domains. -The queries to the \fIforwarding servers\fP are recursive queries. -There may be one or more forwarding servers, and they are tried in turn -until the list is exhausted. -A Slave and forwarder configuration is typically used when you do not -wish all the servers at a given site to interact with the rest -of the Internet servers. A typical scenario would involve a number of -workstations and a departmental timesharing machine with Internet -access. The workstations might be -administratively prohibited from having Internet access. -To give the workstations the appearance of access to the Internet -domain system, the workstations could be Slave servers to the timesharing -machine which would forward the queries and interact with other -name servers to resolve the query before returning the answer. -An added benefit of using the forwarding feature is that the central -machine develops a much more complete cache of information that -all the workstations can take advantage of. The use of Slave mode -and forwarding is discussed further under the description of -the \fInamed\fP bootfile commands. -.pp -There is no prohibition against declaring a server to be a \fIslave\fP -even though it has \fIprimary\fP and/or \fIsecondary\fP zones as well; -the effect will still be that anything in the local server's cache or -zones will be answered, and anything else will be forwarded using the -\fIforwarders\fP list. diff --git a/contrib/bind/doc/bog/ucbhosts b/contrib/bind/doc/bog/ucbhosts deleted file mode 100644 index 2cb2635..0000000 --- a/contrib/bind/doc/bog/ucbhosts +++ /dev/null @@ -1,118 +0,0 @@ -.\" ++Copyright++ 1986, 1988 -.\" - -.\" Copyright (c) 1986, 1988 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" - -.\" Portions Copyright (c) 1993 by Digital Equipment Corporation. -.\" -.\" Permission to use, copy, modify, and distribute this software for any -.\" purpose with or without fee is hereby granted, provided that the above -.\" copyright notice and this permission notice appear in all copies, and that -.\" the name of Digital Equipment Corporation not be used in advertising or -.\" publicity pertaining to distribution of the document or software without -.\" specific, written prior permission. -.\" -.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL -.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES -.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT -.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL -.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR -.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS -.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS -.\" SOFTWARE. -.\" - -.\" --Copyright-- -.\" -.\" @(#)ucbhosts 6.3 (Berkeley) 2/8/89 -.\" -.\" .ne 48v -.\" .bp -.sh 3 "Hosts" -.(b L -; -; @(#)ucb-hosts 1.2 (berkeley) 88/02/05 -; -.TS -l l l l l s. -@ IN SOA ucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP kjd\fB.\fPmonet\fB.\fPBerkeley\fB.\fPEdu\fB.\fP ( -.T& -l l l l l. - 1988020501 ; Serial - 10800 ; Refresh - 1800 ; Retry - 3600000 ; Expire - 259200 ) ; Minimum -.T& -l l l l s. - IN NS ucbarpa\fB.\fPBerkeley\fB.\fPEdu\fB.\fP - IN NS ucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP -localhost IN A 127\fB.\fP1 - ; note that 127.1 is the same as 127.0.0.1; see inet(3n) -ucbarpa IN A 128\fB.\fP32\fB.\fP4 - IN A 10\fB.\fP0\fB.\fP0\fB.\fP78 - IN HINFO VAX-11/780 UNIX -arpa IN CNAME ucbarpa -ernie IN A 128\fB.\fP32\fB.\fP6 - IN HINFO VAX-11/780 UNIX -ucbernie IN CNAME ernie -monet IN A 128\fB.\fP32\fB.\fP7 - IN A 128\fB.\fP32\fB.\fP130\fB.\fP6 - IN HINFO VAX-11/750 UNIX -ucbmonet IN CNAME monet -ucbvax IN A 10\fB.\fP2\fB.\fP0\fB.\fP78 - ; 128.32.10 means 128.32.0.10; see inet(3n) - IN A 128\fB.\fP32\fB.\fP10 - ; HINFO and WKS are widely unused, - ; but we'll show them as examples. - IN HINFO VAX-11/750 UNIX - IN WKS 128.32.0.10 TCP ( echo telnet - discard sunrpc sftp - uucp-path systat daytime - netstat qotd nntp - link chargen ftp - auth time whhois mtp - pop rje finger smtp - supdup hostnames - domain - nameserver ) -vax IN CNAME ucbvax -toybox IN A 128\fB.\fP32\fB.\fP131\fB.\fP119 - IN HINFO Pro350 RT11 -toybox IN MX 0 monet.Berkeley.Edu. -csrg IN MX 0 Ralph.CS - IN MX 0 Zhou.CS - IN MX 0 Painter.CS - IN MX 0 Riggle.CS - IN MX 0 Terry.CS - IN MX 0 Kevin.CS -.TE -.)b -.\" .bp diff --git a/contrib/bind/doc/bog/ucbhosts.rev b/contrib/bind/doc/bog/ucbhosts.rev deleted file mode 100644 index 16207af..0000000 --- a/contrib/bind/doc/bog/ucbhosts.rev +++ /dev/null @@ -1,86 +0,0 @@ -.\" ++Copyright++ 1986, 1988 -.\" - -.\" Copyright (c) 1986, 1988 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" - -.\" Portions Copyright (c) 1993 by Digital Equipment Corporation. -.\" -.\" Permission to use, copy, modify, and distribute this software for any -.\" purpose with or without fee is hereby granted, provided that the above -.\" copyright notice and this permission notice appear in all copies, and that -.\" the name of Digital Equipment Corporation not be used in advertising or -.\" publicity pertaining to distribution of the document or software without -.\" specific, written prior permission. -.\" -.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL -.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES -.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT -.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL -.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR -.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS -.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS -.\" SOFTWARE. -.\" - -.\" --Copyright-- -.\" -.\" @(#)ucbhosts.rev 6.3 (Berkeley) 9/19/89 -.\" -.ne 22v -.sh 3 "host.rev" -.(b L - -; -; @(#)ucb-hosts.rev 1.1 (Berkeley) 86/02/05 -; -.TS -l l l l l s. -@ IN SOA ucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP kjd\fB.\fPmonet\fB.\fPBerkeley\fB.\fPEdu\fB.\fP ( -.T& -l l l l l. - 1986020501 ; Serial - 10800 ; Refresh - 1800 ; Retry - 3600000 ; Expire - 259200 ) ; Minimum -.T& -l l l l s. - IN NS ucbarpa\fB.\fPBerkeley\fB.\fPEdu\fB.\fP - IN NS ucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP -0\fB.\fP0 IN PTR Berkeley-net\fB.\fPBerkeley\fB.\fPEDU\fB.\fP - IN A 255\fB.\fP255\fB.\fP255\fB.\fP0 -0\fB.\fP130 IN PTR csdiv-net\fB.\fPBerkeley\fB.\fPEDU\fB.\fP -4\fB.\fP0 IN PTR ucbarpa\fB.\fPBerkeley\fB.\fPEdu\fB.\fP -6\fB.\fP0 IN PTR ernie\fB.\fPBerkeley\fB.\fPEdu\fB.\fP -7\fB.\fP0 IN PTR monet\fB.\fPBerkeley\fB.\fPEdu\fB.\fP -10\fB.\fP0 IN PTR ucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP -6\fB.\fP130 IN PTR monet\fB.\fPBerkeley\fB.\fPEdu\fB.\fP -.TE -.)b diff --git a/contrib/bind/doc/notes/data b/contrib/bind/doc/notes/data deleted file mode 100644 index e522392..0000000 --- a/contrib/bind/doc/notes/data +++ /dev/null @@ -1,51 +0,0 @@ -/* - * We need a registy of name server addresses. For each, we retain an RTT - * and a list of name server names which have used this address. - */ -tree_t *by_nsaddr; -struct by_nsaddr { - u_int32_t rtt; /* measured. */ - char **names; /* NULL terminated array; strdup'd. */ -}; - -/* - * "struct server" is a name server, which can have many addresses. There - * is no central registry of servers, since each creator can have a different - * idea of what the addresses are. - */ -struct server { - char *name; /* made with strdup. */ - struct sockaddr_in *addrs; /* counted array. */ - int n_addrs; /* array size. */ -}; - -/* - * "struct zone" is a zone cut. - */ -tree_t *by_class; /* zone[class]. */ -struct zone { - enum {master, slave, cache, boot} - type; - - /* Servers learned from boot cache, a parent zone, or !auth answer. */ - struct server *servers_notauth; - - /* Servers learned from authoritative answer or local zone. */ - struct server *servers_auth; - - /* Root node of zone. */ - struct node *root; -}; - -struct node { - char *label; /* made with strdup. */ - tree_t *subs; /* subdomains (node[label]). */ - /* really this is "data" since for the zone cut tree we have no sets.*/ - tree_t *rrsets; /* rr sets (rrset[type]). */ -}; - -struct rrset { - rrtype type; - u_int32_t ttl; - u_char data[1]; /* struct size constrains this. */ -}; diff --git a/contrib/bind/doc/notes/db_names.c b/contrib/bind/doc/notes/db_names.c deleted file mode 100644 index 0b4e62c..0000000 --- a/contrib/bind/doc/notes/db_names.c +++ /dev/null @@ -1,184 +0,0 @@ -/* - * Copyright (c) 1996,1999 by Internet Software Consortium. - * - * Permission to use, copy, modify, and distribute this software for any - * purpose with or without fee is hereby granted, provided that the above - * copyright notice and this permission notice appear in all copies. - * - * THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM DISCLAIMS - * ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES - * OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL INTERNET SOFTWARE - * CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL - * DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR - * PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS - * ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS - * SOFTWARE. - */ - -#include <sys/types.h> -#include <sys/param.h> -#include <netinet/in.h> -#include <arpa/nameser.h> - -#include <ctype.h> -#include <errno.h> -#include <resolv.h> -#include <stdio.h> - -#include "named.h" -#include "tree.h" - -struct node { - struct node *parent; /* NULL for "."'s node. */ - tree *children; /* Nodes using us as parent. */ - /*void *userdata;*/ /* For future use. */ - char name[sizeof(void*)]; /* Open array. */ -}; - -static struct node rootNode; - -static int -nodeCompare(t1, t2) - const tree_t t1, t2; -{ - const char *n1 = ((struct node *)t1)->name + sizeof(u_char), - *n2 = ((struct node *)t2)->name + sizeof(u_char); - - return (strcasecmp(n1, n2)); -} - -/* void * - * db_findname(const char *name, int storeflag) - * find or store a presentation format domain name. - * returns: - * NULL if an error occurred (check errno) - * else, node's unique, opaque address. - */ -void * -db_findname(name, storeflag) - const char *name; - int storeflag; -{ - struct node *node, *tnode; - const char *tname; - size_t len; - int ch; - - /* The root domain has its own static node. */ - if (name[0] == '\0') - return (&rootNode); - - /* Locate the end of the first label. */ - for (tname = name; (ch = *tname) != '\0'; tname++) { - /* Is this the end of the first label? */ - if (ch == '.') - break; - /* Is it an escaped character? */ - if (ch == '\\') { - ch = *++tname; - if (ch == '\0') - break; - } - } - - /* Make sure the label's length will fit in our length byte. */ - len = tname - name; - if (len > 255) { - errno = ENAMETOOLONG; - return (NULL); - } - - /* If nothing but unescaped dots after this, elide them. */ - while (ch == '.') - ch = *tname++; - - /* - * Make a new node since the comparison function needs it - * and we may yet end up adding it to our parent's tree. - * - * Note that by recursing for tnode->parent, we might be - * creating our parents and grandparents and so on. - */ - tnode = (struct node *)malloc(sizeof(struct node) - sizeof(void *) - + sizeof(u_char) + len + sizeof(char)); - tnode->parent = db_findname(tname); - tnode->children = NULL; - *((u_char *)tnode->name) = (u_char)len; - memcpy(tnode->name + sizeof(u_char), name, len); - tnode->name[sizeof(u_char) + len] = '\0'; - - /* If our first label isn't in our parent's tree, put it there. */ - node = tree_srch(&tnode->parent->children, nodeCompare, (tree_t)tnode); - if (node == NULL) - if (storeflag) - if (tree_add(&tnode->parent->children, nodeCompare, - (tree_t)tnode, NULL)) - node = tnode, tnode = NULL; - else - errno = ENOMEM; - else - errno = ENOENT; - - /* Get rid of tnode if we didn't consume it. */ - if (tnode != NULL) - free(tnode); - - /* Return the (possibly new) node, or NULL, as appropriate. */ - return (node); -} - -/* int - * db_getname(void *node, char *name, size_t size) - * given a node's unique, opaque address, format its name. - * returns: - * -1 = error occurred, check errno - * 0 = success - */ -int -db_getname(vnode, name, size) - const void *vnode; - char *name; - size_t size; -{ - const struct node *node = vnode; - - while (node != NULL) { - size_t len = (size_t)node->name[0]; - - if (size < len + 1) - goto too_long; - memcpy(name, node->name + sizeof(u_char), len); - name += len; - *name++ = '.'; - size -= len + sizeof(char); - node = node->parent; - } - - if (size < sizeof(char)) { - too_long: - errno = ENAMETOOLONG; - return (-1); - } - *name = '\0'; - return (0); -} - -/* - * char * - * db_makename(void *node) - * given a node's unique, opaque address, format and return its name. - * returns: - * pointer to the name or NULL on errors (check errno). - * notes: - * returns pointer to a static buffer, be careful how you call it. - */ -char * -db_makename(vnode) - void *vnode; -{ - static char name[MAXDNAME*2]; - - if (db_getname(vnode, name, sizeof name) < 0) - return (NULL); - return (name); -} diff --git a/contrib/bind/doc/notes/irp.txt b/contrib/bind/doc/notes/irp.txt deleted file mode 100644 index f2b59e2..0000000 --- a/contrib/bind/doc/notes/irp.txt +++ /dev/null @@ -1,521 +0,0 @@ -IRP Commands - -This document describes version 1 of IRP. - -IRP is a text-based command/response protocol like NNTP or SMTP. - -1.0 Response types: textual and status. - -1.1 Textual responses - -Textual responses are sent after a status response which indicates the text -will follow. The text is a series of CR-LF terminated lines. On the last line a -single period ``.'' will appear. If a normal text line starts with a period -then this will be doubled before sending. - -There is no maximum line length for responses. Commands have a maximum line -length of 1024 characters. - -The lines that make up the transmitted data are divided into fields. The fields -are spearated by the colon character ``:'', except in one case (for host data) -where the at-sign ``@'' is used instead. Some fields, such as alias names for -hosts, can have multiple values, and these values are separated by commas. - -Most transmission of data requires no special character changes. The field -separators and subfield separators don't normally appear in the data. However -in one case they can (network names). So to avoid trouble, all ``special'' -characters found in any data fields are encoded in URL-encoding form. That is -they are replaced with the 3-character sequence ``%xx'', where xx is the -hexidecimal value of the ascii-code for the chatacter. i,e, ``:'' becomes -``%58'', ``,'' becomes ``%44'' and ``%'' becomes ``%37''. - -For version 1 of IRP the set of special characters for purposes of encoding, -is: - - `,', '%', ':', '@' - -In a couple cases (password structure and group structure), there may be -encrypted passwords as part of the data. If the client is a privileged user -that the server can verify (e.g. through the use of SunOS doors(2)), then the -encrypted password will be sent back to the client. If the client is not -privileged the password will be replaced with the string ``*''. - - -1.2 Status responses. - -Status responses follow a numbering pattern similar to NNTP. - - 1xx - Informative message - 2xx - Command ok - 3xx - Command ok so far, send the rest of it. - 4xx - Command was correct, but couldn't be performed for - some reason. - 5xx - Command unimplemented, or incorrect, or a serious - program error occurred. - - The next digit in the code indicates the function response category. - - x0x - Connection, setup, and miscellaneous messages - x1x - Host lookup - x2x - Network lookup - x3x - User lookup - x4x - Group lookup - x5x - Service lookup - x6x - Protocol lookup - x7x - Netgroup lookup - x8x - Misc. Information Lookup - x9x - Debugging output - - The final digit in the code indicates whether textual data follows - - xx0 - No textual data follows. - xx1 - Textual data follows. - -2.0 Connection Establishment - - When the client connects to the server, the server will issue a welcome - banner. If the server will accetp commands, then the banner will start with - a status code indicating this, followed by a version number of the protocol - it accepts. Other words may come on the line afterwards to indicate to - humans the state of the server, - - If the server wont accept commands then it will issue a banner indicating - that and will then drop the connection. - -2.1 Responses - - 200 1 Ready to go. ; note: The server handles version 1 of the protocol - 200 2 Ready ; note: The server handles version 2 of the protocol - 400 Sorry. Down to due to nightly backups. - -3.0 Commands - -3.1 The HOST commands - -3.1.1 GETHOSTBYNAME hostname -3.1.2 GETHOSTBYNAME2 hostname address-family -3.1.2 GETHOSTBYADDR address address-family -3.1.3 GETHOSTENT - - Returns a textual response containing the information for the given host(s) - (a struct hostent) encoded in an ascii format. gethostbyaddr and - gethostbyname look up a specific host. GETHOSTENT returns the contents - of the /etc/hosts file. The GETHOSTENT command is optional may not be - supported by the server. The address-family paramater is the value - "AF_INET" or "AF_INET6" - -{ XXX GETHOSTENT is optional as the gethostent(3) call isn't always available } - -3.1.4 Responses - - 210 No such host - 211 Host found - - If the hostname given as the command argument doesn't exist, then the 210 - response will be returned. If the host is successfully looked up, then the - 211 response is sent and a textual message is sent after. The textual - message contains the host information encoded in an ascii form. The fields - of the host data are separated by at-signs. Fields that have multiple values - (like the aliases field) have their sub values separated by commas. - - hostname@aliases@address-type@address-length@address-list@ - - - hostname is the FQDN of the host. - - - aliases is a comma separated list of FQDNs for the host aliases. - - - address-type is either the strings "AF_INET" or "AF_INET6" - - - address-length is the length of each address in bytes (after conversion - back to binary form). - - - address-list is a comma separated list of dotted IPv4 if IPv6 addresses. - -{ XXX if we're going to include TTLs where should they go? Perhaps the -address-list field should be "addr/ttl,addr/ttl,..." } - - For example: - - C: GETHOSTBYNAME gw.downtown.vix.com - - S: 210 No such host. - - C: GETHOSTBYNAME gw.home.vix.com - - S: 211 OK - gw.home.vix.com@ftp.vix.com,www.vix.com@AF_INET@4@192.5.5.1,192.5.5.1@ - . - - C: GETHOSTBYNAME2 gw.home.vix.com AF_INET6 - gw.home.vix.com@@AF_INET6@ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255@ - . - - C: GETHOSTBYADDR 192.5.5.1 - - S: 211 OK - gw.home.vix.com@ftp.vix.com,www.vix.com@AF_INET@4@192.5.5.1,192.5.5.1@ - . - - C: GETHOSTENT - - S: 211 OK - gw.home.vix.com@ftp.vix.com,www.vix.com@AF_INET@4@192.5.5.1,192.5.5.1@ - data.pa.vix.com@@AF_INET@4@204.152.184.37@ - . - - -3.2 The USER commands. - -3.2.1 GETPWNAM username -3.2.2 GETPWUID uid -3.2.3 GETPWENT - - Returns a textual response with the user information (a struct passwd) - enocoded in an ascii format. The optional GETPWENT command transmits the - entire /etc/password file - -{ XXX It's optional only cause it doesn't seem right to spit the password out -to whoever wants it, even with encrypted passwords not being sent } - -3.2.4 Reponses - - 230 No such user - 231 User found - - If the username or uid given as the command argument doesn't exist, then - the 230 response will be returned. If the user is successfully looked up, - then the 231 response is sent and a textual message is sent after. The - textual message contains the user information encoded in an ascii form. The - fields of the user data are separated by colons. The format is very similar - to the /etc/password format (see passwd(5)) - - username:password:uid:gid:class:change:expire:gecos:home_dir:shell: - - - username is the user's login name - - - password User's encrypted password (or the string "*" if the client is - unprivileged) - - - uid User's numeric id. - - - gid User's numeric login group id. - - - class User's general classification (a string) - - - change Password change time (integer seconds from epoch) - - - expire Account expiration time (integer seconds from epoch) - - - gecos General information about the user. - - - home_dir User's home directory. - - - shell User's login shell. - - For example. Client being a non-privileged user: - - C: GETPWNAM brister - - S: 231 User found - brister:*:1364:100:James Brister:/udir/brister:/bin/csh: - . - - C: GETPWUID 6 - games:*:7:13:Games Pseudo-user:/usr/games:nologin - . - - S: GETPWENT - root:*:0:0:System Administrator:/root:/bin/csh - postmast:*:4:4:Postmaster:/:/nologin - daemon:*:1:1:System Daemon:/:nologin - sys:*:2:2:Operating System:/tmp:nologin - bin:*:3:7:BSDI Software:/usr/bsdi:nologin - operator:*:5:5:System Operator:/usr/opr:/bin/csh - uucp:*:6:6:UNIX-to-UNIX Copy:/var/spool/uucppublic:/usr/libexec/uucico - . - - If a priviled user looks up a username: - - C: GETPWNAM www - - S: 231 User found - www:WZajcgFCaAd8s:51:84::0:0:WWW-server:/var/www:/bin/sh - . - -3.3 The NETWORK commands - -3.3.1 GETNETBYNAME network -3.3.2 GETNETBYADDR dotted-ip-address address-family -3.3.4 GETNETENT - - Returns a textual response with the network information (an IRS struct - nwent, *not* a struct netent) enocoded in an ascii format. The optionally - supported GETNETENT command transmits the entire /etc/networks file - -{ XXX should it be optional? } - -3.2.4 Reponses - - 220 No such network - 221 Netork found - - If the network given as the command argument doesn't exist, then the 220 - response will be returned. If the network is successfully looked up, then - the 221 response is sent and a textual message is sent after. The textual - message contains the network information encoded in an ascii form. The fields - of the network data are separated by colons. - - network-name:aliases:address-type:address-length:network-address: - - - network-name is the name of the network - - - aliases is a comma separated list of aliases for the network - - - address-type is ``AF_INET'' or ``AF_INET6''. - - - address-length is the number of bits the following network address uses. - - - address is the network address in a dotted ascii format. AF_INET address - are padded with 0 bits to the full 32 bits before conversion to ascii for - transmission. AF_INET6 addresses are padded to the full 128 bits with 0 - bits before conversion. - - For example: - - C: GETNETBYNAME vixie-net - - S: 221 Network found - vixie-net::AF_INET:24:192.5.5.0: - . - - C: GETNETBYADDR 10.0.0.1 - - S: 221 Network found - private-net:home-net,upstairs-net:AF_INET:8:10.0.0.0: - . - - C: GETNETENT - - S: 221 OK - vixie-net::AF_INET:24:192.5.5.0: - private-net:home-net,upstairs-net:AF_INET:8:10.0.0.0: - lookback-net::AF_INET:8:127.0.0.0 - . - -3.4 The GROUP commands - -3.4.1 GETGRNAM group -3.4.2 GETGRGID gid -3.4.3 GETGRENT - - Returns a textual response with the group information (a struct group) - enocoded in an ascii format. The optionally supported GETGRENT command - transmits the entire /etc/group file. - -3.4.4 Reponses - - 240 No such group - 241 Group found - - If the group given as the command argument doesn't exist, then the 240 - response will be returned. If the group is successfully looked up, then - the 241 response is sent and a textual message is sent after. The textual - message contains the group information encoded in an ascii form. The fields - of the group data are separated by colons. - - group-name:group-password:group-gid:group-members: - - - group-name is the name of the group. - - - group-password is the group's password. This will be correct if the - client has appropriate privileges (see discussion above on the USER - commands). Otherwise it will be the string ``*'' - - - group-gid is the numeric id for the group - - - group-members is a comma separated list of usernames for all the members - of the group. - - For example: - - C: GETGRNAM wheel - - S: 241 Group found - wheel:*:0:root,brister,nathalie,tester: - - C: GETGRGID 20 - - S: 241 Group found - staff:*:20:root,brister: - - C: GETGRENT - - S: 241 OK - wheel:*:0:root,brister,nathalie,tester: - daemon:*:1:daemon: - kmem:*:2:root: - sys:*:3:root: - tty:*:4:root: - operator:*:5:root: - uucp:*:6:brister: - bin:*:7:: - news:*:8:brister: - utmp:*:12:: - games:*:13:: - mail:*:14:: - staff:*:20:root,brister: - . - -3.5 The SERVICE commands - -3.5.1 GETSERVBYNAME name protocol -3.5.2 GETSERVBYPORT port protocol -3.5.3 GETSERVENT - - Returns a textual response with the service information (a struct servent) - enocoded in an ascii format. The optionally supported GETSERVENT command - transmits the entire /etc/services file. - -3.5.4 Reponses - - 250 No such service - 251 Group found - - If the group given as the command argument doesn't exist, then the 250 - response will be returned. If the service is successfully looked up, then - the 251 response is sent and a textual message is sent after. The textual - message contains the service information encoded in an ascii form. The fields - of the service data are separated by colons. - - service-name:aliases:port-number:protocol: - - - The service name is the offical name of the services. - - - aliases is a comma separated list of aliases for the service. - - - port-number is the decimal number of the port used for the service. - - - protocol is the name of the protocol the service operates under. Usually - either ``TCP'' or ``UCP'' - - For example: - - C: GETSERVBYNAME nntp tcp - - S: 251 Service found - nntp:readnews,untp:119:tcp: - . - - C: GETSERVBYPORT 514 udp - syslog::514:ucp: - . - - C: GETSERVENT - 251 OK - tcpmux::1:tcp: - echo::7:tcp: - echo::7:udp: - discard:sink,null:9:tcp: - discard:sink,null:9:udp: - systat:users:11:tcp: - systat:users:11:udp: - daytime::13:tcp: - daytime::13:udp: - netstat::15:tcp: - qotd:quote:17:tcp: - qotd:quote:17:udp: - . - -3.6 The PROTOCOL commands - -3.6.1 GETPROTOBYNAME protocol-name -3.6.2 GETPROTOBYNUMBER protocol-number -3.6.3 GETPROTOENT - - Returns a textual response with the protocol information (a struct protoent) - enocoded in an ascii format. The optionally supported GETPROTOENT command - transmits the entire /etc/protocols file. - -3.6.4 Reponses - - 260 No such protocol - 261 Protocol found - - If the protocol given as the command argument doesn't exist, then the 260 - response will be returned. If the service is successfully looked up, then - the 261 response is sent and a textual message is sent after. The textual - message contains the protocol information encoded in an ascii form. The fields - of the protocol data are separated by colons. - - protocol-name:aliases:protocol-number: - - - protocol-name is the offical name of the protocol - - - aliases is a comma separated list of aliases for the protocol - - - protocol-nunber is the number of the protocol in decimal. - - - For example: - - C: GETPROTOBYNAME ip - - S: 261 Protocol found - ip:IP:0: - . - - C: GETPROTOBYNUMBER 17 - - S: 261 Protocol found - udp:UDP:17: - . - - C: GETPROTOENT - - S: 261 OK - ip:IP:0: - icmp:ICMP:1: - igmp:IGMP:2: - ggp:GGP:3: - tcp:TCP:6: - egp:EGP:8: - pup:PUP:12: - udp:UDP:17: - hmp:HMP:20: - xns-idp:XNS-IDP:22: - rdp:RDP:27: - iso-tp4:ISO-TP4:29: - iso-ip:ISO-IP:80: - encap:ENCAP:98: - . - -3.7 The NETGROUP commands - -3.7.1 GETNETGRENT netgrouup - - Returns a textual response with the netgroup information enocoded in an - ascii format. - -3.6.4 Reponses - - 270 No such netgroup - 271 Netgroups found - - For the given netgroup a list of the netgroup entries will be - returned. Each netgroup entry is three fields separated by colons. A field - may be empty to indicate wildcarding. - - :hostname:username:domainname: - - For example: - - C: GETNETGRENT devlopers - - S: 271 OK - :gw.home.vix.com:brister:vix.com: - :bb.rc.vix.com:vixie:: - . - - - - |