Aren/NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

BIND 4.9.5-P1

Browse Source
This commit is contained in:
mrg 1997-04-13 09:06:10 +00:00
parent 4765dedbf5
commit 6d2a687f9c
180 changed files with 85953 additions and 3618 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2864
usr.sbin/named/CHANGES Normal file
View File

File diff suppressed because it is too large Load Diff

412
usr.sbin/named/OPTIONS Normal file
View File

@ -0,0 +1,412 @@
OPTIONS
Original: Paul Vixie, 28Mar92
Revised: $Id: OPTIONS,v 1.1.1.1 1997/04/13 09:06:11 mrg Exp $
Options available in this version of BIND are controlled by conf/options.h,
rather than by $(DEFS) in the Makefile. The options are:
DEBUG (origin: U C Berkeley)
enables the -d command line option, and allows SIGUSR1 to increment
and SIGUSR2 to clear the internal variable "debug", which in turn controls
hundreds of fprintf()'s out to /usr/tmp/named.run.
you probably want this. it makes the binary bigger but not slower (or
at least not much slower), but SIGUSR[12] are the only way you'll track down
misconfigured name servers that hose you down with billions of bogus requests.
you may need this, it is on by default.
ALLOW_T_UNSPEC (origin: MIT Project Athena)
enables the "unspec" RR type for ancient Athena software that does not
know about TXT RR's.
you probably do not care about this, it is off by default.
ALLOW_UPDATES (origin: Mike Schwartz, University of Washington)
enables "dynamic updates", described in "doc/DynamicUpdate". this lets
you update named's in-memory database on the fly if you have the right client.
there is absolutely no security around this; if you enable it, anyone who can
reach your server can update your database.
this code doesn't compile any more and will be removed shortly.
INVQ (origin: U C Berkeley, with #ifdef's by Paul Vixie)
enables "inverse queries", which in all of the internet only one
client ever uses: ancient nslookup. if you build named with INVQ defined,
you get the time-honored behaviour of supporting this whole class of queries
for no real purpose other than to waste a few hundred kilobytes of your
memory and about 3% of named's total CPU time. if you build with INVQ
undefined, old nslookups will not be able to reach your server in their
startup phase, and you will have to use the "server" command after it fails
over to some other server, or use "nslookup - 0" to get in from the shell.
if you need to support old nslookups try "options fake-iquery"
instead of enabling this option.
you probably do not want this.
DSTORAGE (origin: U C Berkeley, with #ifdef's by Paul Vixie)
enables a malloc-debugger that checks for overruns on both ends of
each allocated block of memory. used when debugging since C has no bounds
or type checking.
you probably do not want this, it is off by default.
DMALLOC (origin: Paul Vixie of Digital)
enables a malloc-debugger that traces all allocated blocks of memory
such that SIGIOT's output (see STATS option) includes a list of all mallocs
in the program, how many times each has been called, how many blocks of memory
allocated by that malloc are not yet free, and how many bytes they use up.
under each one will be a list of each free/realloc that has deallocated a block
of that malloc's memory, and how many times it has done so.
this is extremely helpful for finding memory leaks. as such, you
probably do not want this unless you are debugging named.
you probably do not need this, it is off by default.
XFRNETS (origin: Paul Vixie of Digital)
enables the "xfrnets" command in named.boot. this has the same
syntax as "forwarders" and "sortlist" -- that is, a list of dotted quads.
each one is a network (16.0.0.0 and 130.180.0.0 are examples) or a host.
if you put any xfrnets commands into your named.boot, then zone transfers
will only be honored if they come from inside one of the specified
networks. this is very useful if you want to keep people outside from
being able to trivially map your entire network, but it doesn't stop them
from iterating so it's more annoying than secure.
this feature was once called "tcplist" out of ignorance on my part,
but with advice from phil almquist i decided to rename it "xfrnets" and make
it only control zone transfers -- previously it controlled all TCP connections
which made certain TCP-only resolvers unable to use our servers. the "tcplist"
syntax still works; it is a synonym for "xfrnets".
it is also nice if you want to keep the outside world from making your
nameserver fork and swap trying to do unauthorized zone transfers. if you have
large zone files or use BIND for TXT records you will find this useful.
you probably want this, it is on by default.
PID_FIX (origin: Don Lewis of Harris)
tells named that if it starts up but can't keep going because another
nameserver is already running (and sitting on the server port), it should
put the /etc/named.pid (/var/run/named.pid) file back the way it found it.
you probably want this, it is on by default.
FWD_LOOP (origin: Don Lewis of Harris)
tells named that if you list any of your own IP addresses in a
"forwarders" command in your named.boot file, you should be scolded.
you probably want this, it is on by default.
NO_GLUE (origin: Don Lewis of Harris, and Andrew Partan of UUNET)
tells named-xfer that incoming zone transfers should be checked
for "glue" that comes from a zone outside the zone being transfered, and
comment this garbage out in the zone file so that when named reads in the
zone file after named-xfer exits, the garbage will not be entered into the
memory-resident database.
also tells named that when it is performing an outgoing zone
transfer, it should not send any of these "glue" records.
you definitely want this, it is on by default.
BOGUSNS (origin: Piet Beertema of EUNet)
enables the "bogusns" command in named.boot. this has the same
syntax as forwarders and sortlist. any NS RR's that come in whose addresses
are on the list of "bogusns" addresses will be ignored. this is the last
resort when someone is bogusly advertising themselves as a root server.
just in case, though you won't use it often.
you probably want this, it is on by default.
QRYLOG (origin: Bryan Beecher of UMich)
enables "query logging", such that SIGWINCH toggles tracing of all
incoming queries. the trace is sent to syslog, and is huge, but when you
need this you will need it bad and it does not slow named down or make it
larger.
If you define QRYLOG you may also start up named in query logging
mode by using the -q flag. If you do so you will probably want to analyze
the logs produced, the dnsstats and lamers scrips (in the contrib/umich
and contrib/lamers directories) will do it for you.
you probably want this, it is on by default.
LOGFAC (origin: various people)
If you start up named with the -q flag you will be logging
large amounts of data, and probably will not want them logged to the
default logging facility, which is LOG_DAEMON. You will want to
redefine LOGFAC, presumably to LOC_LOCALn (0 <= n <= 7). Remember to
modify /etc/syslog.conf appropriately.
This only works on a system with a modern syslogd.
as such, it is on by default.
YPKLUDGE (origin: Piet Beertema of EUNet)
certain versions of NIS/YP are capable of using the DNS for names
that cannot be found in the YP servers. of these, certain versions can't
tell the difference between a dotted quad and a domain name, and they send
queries to the DNS for dotted quads as if they were domain names. if your
named does not do anything special with these queries, they will end up
getting forwarded to other servers, effectively hosing all of you down with
endless useless network traffic. YPKLUDGE enables some checking in named
that lets it catch these bogus queries and send back immediate errors.
If you run "ypserv -i" you definitely want this, as a malconfigured
NIS server can cause DNS "flood" queries otherwise. Trust me.
this is off by default.
TRACEROOT (origin: pma@cnd.hp.com and Bryan Beecher of UMich)
enables some checking in named for bogus root nameservers. This
code has been in use at U-M for years, so it is pretty well tested, plus we
have never been burned by the "bogus root NS scares" that have plagued the
DNS off and on.
this feature people will very much want to use, it is on by default.
LOCALDOM (origin: Berkeley)
if set, the "domain" directive is recognized in the named.boot file.
this causes us to retry queries with the specified domain appended to the
name if the first lookup fails. this is a very bad idea since a given name
server will often be used by clients in more than one domain -- a name server
should _not_ make any presumptions as to the "home domain" of a requestor.
you almost certainly do not want this, it is off by default.
SLAVE_FORWARD (origin: pma@sdd.hp.com)
if set, "slave" servers behave in an arguably more-correct way. this
is an experimental addition to BIND 4.9 that causes slaves to time out queries
in 60/N seconds where N is the number of forwarders defined. previously a
query would time out almost immediately, which caused a lot of unnecessary
network traffic.
you probably want this, it is on by default.
FORCED_RELOAD (origin: pma@sdd.hp.com)
if set, then when a HUP signal is received, all secondary zones are
scheduled for serial-number comparison with the primaries. this has the effect
that if you HUP your server, it will refresh any zones which have changed,
even if those zones' refresh times have not been reached.
you probably want this, it is on by default.
WANT_PIDFILE (origin: berkeley, parameterized by arc@sgi)
if set, a file called named.pid will be created in /etc or /var/run
when the name server has started. this file can be used to send signals to
BIND, as in "kill -HUP `cat /etc/named.pid`".
unless you are only on an SGI (where killall(1M) makes the pid file
unnecessary);
you probably want this, it is on by default.
DOTTED_SERIAL (origin: berkeley; parameterized by vixie)
if set, allows a somewhat arcane n.m syntax in the serial number
field of an SOA. this is officially deprecated for 4.9; you should use
straight integer values and find an encoding that does not depend on
scaled-integer pseudodecimals. i suggest YYYYMMDDnn where YYYY is the
four-digit year, MM is the two-digit month, DD is the two-digit day-of-month,
and nn is a daily version number in case you change your serial number more
than once in a day. this encoding will overflow in the year 4294 gregorian.
you almost certainly do not want this, but if you have old zone files
lying around and you don't want to think your way through converting their
serial numbers, this deprecated behaviour is available.
graciously, it is on by default.
SENSIBLE_DOTS (origin: kagotani@cs.titech.ac.jp; parameterized by vixie)
if set, changes the semantics of an "n.m" serial number from
n*10^(3+int(0.9+log10(m))) + m
to
n*10000+m
if you are using DOTTED_SERIAL in spite of its deprecated status,
and you are interested in a more predictable and sensible interpretation of
dotted numbers, then you probably want this.
it is off by default.
VALIDATE (origin: USC/ISI)
enables a validation procedure to provide some security in an
otherwise insecure environment. Any RRs are accepted from a server only if
the server is authoritative over that domain. We consider a server
authoritative (for validation purposes) for even the sub-domains that it has
delegated to others. RRs are validated against the data we have in cache
already. Invalid records are neither cached nor returned.
it is off by default because it is hopeless, and the code will all
be ripped out of BIND in the near future.
NCACHE (origin: USC/ISI)
enables negative caching. We cache only authoritative NXDOMAIN or
authoritative NOERROR with zero RR count. Non-authoritative NXDOMAIN answers
now contain NS records in the authority section. Non-authoritative NOERROR
responses have no authority or additional records to differentiate them from
referrals. They are cached for NTTL secs (currently 10 minutes) and are timed
out when the ttl expires.
you probably want this, it is on by default.
RESOLVSORT (origin: marka@syd.dms.csiro.au)
enable sorting of addresses returned by gethostbyname. Sorting order
is specified by address/netmask pairs. This enables a host to override the
sortlist specified in the nameserver.
you probably want this, it is on by default.
STUBS (origin: marka@syd.dms.csiro.au)
enable transfer and loading of NS records only for a zone.
still experimental. it won't hurt to enable it, but it may not work perfectly
so using it could lead to some confusion.
you probably don't care, it is on by default.
SUNSECURITY (origin: rossc@ucc.su.oz.au)
enable checking of PTR records in gethostbyaddr() to detect
spoofing. Forced on SunOS 4 shared library as rlogin etc. depend on this.
you should probably not set this by hand.
SECURE_ZONES (origin: gshapiro@guest.wpi.edu)
enables support for secure zones. This restricts access to
information in the zone according to the information found in the
secure_zone TXT RR found in the zone. If none is found, the zone is
world-readable. For information on the format of the secure_zone TXT
RR, see the Name Server Operations Guide for BIND.
you probably want this, it is on by default.
ROUND_ROBIN (origin: Marshall Rose of TPC.INT)
if set, causes the databuf list in a namebuf to be rotated by one
slot after each access to it. this has the effect that if multiple RR's
of a given type are present, they will be given in "round robin" order
instead of always being given in the same order.
you probably want this, it is on by default.
ADDAUTH (origin: marka@syd.dms.csiro.au)
if set, cause NS and glue A records to be returned with authoritative
answers. this causes slightly larger replies but less DNS traffic overall.
unless you have Mac's with an older version of Mac/TCP;
you probably want this, it is on by default.
RFC1535 (origin: paul@vix.com)
if set, the resolver's default "search" list will be just the entire
"domain" name rather than the sliding window it had before 4.9.2. this will
make the default search list shorter, so folks who are saying "domain a.b.c"
and relying on the implicit "search a.b.c a.b c" will miss "a.b" and "c".
this option is on for compatibility with RFC 1535.
you should NOT turn it off, it is on by default.
GEN_AXFR (origin: mark@comp.vuw.ac.nz, tytso@ATHENA.MIT.EDU, gdmr@dcs.ed.ac.uk)
if set, allows specification of zones in classes other than "IN" in
the named.boot file. Allows an optional "/class" on the "primary" and
"secondary" directives. Also fixes zone transfers so only data in the class
requested is transfered.
you probably want this, it is on by default.
DATUMREFCNT (origin: mark andrews)
you want this. it will not be optional in future releases.
LAME_DELEGATION (origin: don lewis; reworked by bryan beecher and don lewis)
this will detect the condition where some other server has told you
that a given set of servers is authoritative for some domain, and at least
one of those "delegated" servers disagrees (i.e., answers non-authoritatively).
you probably want this, it is on by default.
LAME_LOGGING (origin: don lewis)
enable logging of lame delegations and set the log level
you may want this, it is on by default.
RETURNSOA (origin: mark andrews)
This allows negative caching to work. Without this, older
pre-4.9.3 nameservers will not accept -ve cached anwsers. We actually
store the SOA record from the authority section rather that what was
requested because it is the existence of the NXDOMAIN that matters not
the type of data. The zone of the SOA record is tagged to the end of
the SOA record to allow it to be reconstructed.
You probably DO NOT WANT THIS, it's experimental and dangerous.
it is off by default.
CLEANCACHE (origin: mark andrews)
Bind consumes memory without bound without this option. This
patch allows bind to periodically remove any stale entries in the
cache. Bind's memory usage should stabilize after approximately 1 day of
operation, as most TTL's are <= 1 day. Without this option stale entries
are only removed when they are looked up.
You probably want this, it is on by default.
PURGE_ZONE (origin: mark andrews)
Various junk below a zone tends to hang around and corrupt future
zone data if a zone grows deeper. PURGE_ZONE will remove all traces of or
data which could be part of zone before loading a new one.
You probably want this, it is on by default.
STATS (origin: Paul Vixie)
Named's internal statistics can take a fair amount of memory and
if you aren't interested in looking at these numbers you should disable
the feature. Future versions may require this.
You probably want this, it is on by default.
RENICE (origin: bp@deins.informatik.uni-dortmund.de)
if set, the process priority of the AXFR subprocesses is changed to
"normal". If you are planning to raise the priority of the main nameserver
process, you will use this.
You probably want this, it is on by default.
GETSER_LOGGING (origin: Paul Vixie)
if set, errors that occur during the fetch of serial numbers for zone
transfer consideration will be syslog()'d. this can lead to a lot of logging,
but is very helpful if you don't know why a zone isn't transfering.
You may not want this, but it is on by default.
SHORT_FNAMES (origin: pma@sdd.hp.com)
on systems whose file names can only be 14 characters long, the temp
files created by named-xfer need to be constructed somewhat differently. this
should probably become the default since it is harmless.
you probably don't care one way or the other, it is off by default.
XSTATS (origin: Benoit.Grange@inria.fr)
if set, the name server keeps more STATS about requests
received, and logs to syslog total counters from time to time. If you
aren't interested in looking at these numbers you should not enable
the feature. Requires STATS.
You may want this, but it is off by default.
BIND_NOTIFY (origin: paul@vix.com)
experimental at this time; an internet draft is circulating. this
option informs slaves ("secondary" servers in BIND's erroneous terminology)
instantly when the master (primary, or another slave) loads a new zone. it
works fine and seems to cause no problems with slaves that don't support it,
but it does not implement the current internet draft (it lacks some necessary
delays) and causes a lot of extra syslog traffic, especially at startup. if
you don't mind running code that will absolutely NOT be compatible with the
eventual standard when the RFC is released, go ahead and turn this on.
vendors should not enable this in versions shipped to customers.
You will want this when it becomes compliant, it is off by default.
LOC_RR (origin: ckd@kei.com)
incorporates support for the (RFC 1876) LOC RR type.
You may want this, it is on by default.
SORT_RESPONSE (legacy)
should responses be sorted in what the server considers an optimal
order for the client? this is on by default but it does very little good.
## ++Copyright++ 1989
## -
## Copyright (c) 1989
## 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--

480
usr.sbin/named/README Normal file
View File

@ -0,0 +1,480 @@
The official place to get BIND is <URL:ftp://ftp.vix.com/pub/bind/release>.
The official mailing lists are: bind-users@vix.com - users/admins
(use *-request@* for admin mail) bind-workers@vix.com - developers
The official Usenet newsgroups are: comp.protocols.tcp-ip.domains
BIND is currently sponsored by: The Internet Software Consortium
(send to <info@isc.org> for details.)
----- 4.9.3 BETA33 - December, 1995 - paul@vix.com
Take a look around in doc/misc/ and contrib/. Reread INSTALL. Have fun.
----- 4.9.3 BETA11, BETA12 release - December, 1994 - paul@vix.com
If you maintain a BSD or are otherwise running a 4.4BSD-based system and want
to integrate BIND into it, check out BSD/README.
Read the top of CHANGES for interesting stuff.
Don't forget to purge all your secondary zone files before upgrading to this
BIND if your existing one came from a vendor.
The NOTIFY feature is turned off by default, but it's really cool and you
should consider turning it on if you are willing to risk having it not work
after the RFC process is complete (if the protocol has to change at all.)
It already does not conform to the draft protocol so you should consider it
"experimental" even if it happens to work fine.
----- 4.9.3 BETA10 release - August, 1994 - paul@vix.com
I recommend reading this ENTIRE FILE before you attempt to build or use BIND.
However, you can get started quickly by scanning down this file for "QUICK" in
the right margin and just reading those sections. You can also look at the
INSTALL file. You should look at doc/info/* if you have trouble building.
There are at least two known bugs in this BIND:
1. if you have two authoritative zones (primary or secondary) where
one is a subzone of the other, e.g.,
primary pa.dec.com z/pa.dec.com
primary dec.com z/dec.com
and you remove or comment out the subzone (pa.dec.com in our example)
and SIGHUP named, the delegation and other RR's at "pa.dec.com" will
be missing from your cache. to avoid this, you should "named.restart"
rather than SIGHUP ("named.reload") when making changes of this kind.
2. the /HS qualifier doesn't work on "cache" directives. you will have
to put your hesiod root information into your main "root.cache" file.
Also, you may find that your utilities will not link with this -lresolv
unless you also install lib44bsd.a and link with -lresolv -l44bsd. This
is because older systems do not include inet_aton() and other functions.
----- 4.9.3 BETA6 release - June, 1994 - paul@vix.com
Several private beta test releases have come and gone, and we've fixed a
number of things. See CHANGES for details.
There is a new Sun Shared Library update mechanism in place, and it works
quite well. See shres/*.
Versions of NSLOOKUP up through BIND 4.8.3's used IQUERY to ask the local
server for information about the server's own name. I assume that this was
done in a "what the heck, nothing uses these, how can we contrive a need?"
sort of spirit. I removed this code as of BIND 4.9's NSLOOKUP and had it
use the standard gethostbyaddr() mechanisms (which depend on normal queries
of PTR data). Disabling INVQ and putting "options fake-iquery" in the boot
file will cause IQUERY to be answered bogusly but in a way that old nslookup
programs won't trip on. INVQ is disabled by default in conf/options.h.
----- 4.9.3 BETA2 release - June, 1994 - paul@vix.com
News flash! BIND development is now funded by the Internet Software Consortium.
Look at CHANGES to see what's new. Check out doc/misc to see some interesting
papers from Purdue (and Bell Labs, if we're lucky) on DNS security that
motivated many of the security-related changes present in this release.
Check out shres/Makefile for SunOS4 shared library support.
INVQ now defaults to "undef". See OPTIONS and conf/options.h.
ALLOW_UPDATES is no longer available, and will be removed next release.
You should look hard at the SENSIBLE_DOTS option and convert your serial
numbers either to "sensible" ones or ones without dots (YYYYMMDD## preferred).
SENSIBLE_DOTS will be the default in the next release.
NCACHE and VALIDATE are _working_ now.
Read the BOG! It's been updated since the previous release.
If you are a vendor and are including some or all of this code in your product,
please drop me a line to let me know. I field a lot of questions about BIND
and it is helpful for me to know which vendor releases contain which versions
of BIND. It's also helpful for me to have contacts within the engineering
groups of the various vendors, since when I find a heinous bug I can let you
know.
----- 4.9.2 FINAL (940221) release - February, 1994 - paul@vix.com
If you look at the last entry in TODO, you'll see that there are a lot
of things in the queue waiting to go in. However, I'm holding the line
so that 4.9.2-FINAL can be the same as what goes out with 4.4BSD-Lite.
I expect to open 4.9.3-ALPHA fairly soon, with patches comprising new
work; 4.9.2-FINAL will have patches released for it only to correct bugs.
The official way to get BIND 4.9.2 is: ftp gatekeeper.dec.com OUT OF DATE!!!
cd pub/misc/vixie OUT OF DATE!!!
binary OUT OF DATE!!!
get bind-940221.tar.gz OUT OF DATE!!!
or: get bind-940221.tar.Z OUT OF DATE!!!
The official mailing lists are: bind-users@vix.com - users/admins
(use *-request for admin mail) bind-workers@vix.com - developers
The official Usenet newsgroups are: comp.protocols.tcp-ip.domains
My official e-mail address is: paul@vix.com
----- 4.9.2 BETA5 (931205) release - December, 1993 - paul@vix.com
no comments; see CHANGES file.
----- 4.9.2 BETA4 (931104) release - November, 1993 - paul@vix.com
All reported portability problems have been fixed. All core dumps have
had changes made for them and we are ready to have them tested again. As
usual, I am running this in production on my own zones and I am rather
confident in it. Note, again, that this is a BETA release and you should
not put it up for anon-ftp or otherwise republish it in any way.
----- 4.9.2 ALPHA2 (930908) release - September, 1993 - paul@vix.com
4.9.2 has fixes for most of the bugs that smb@bellcore's white paper talked
about, and CERT is going to be knocking on vendor's doors to get it shipped
with as many operating systems as possible.
----- 4.9.2 ALPHA1 (930506) release - July, 1993 - Paul Vixie <paul@vix.com>
I don't work for DEC any more, so note the new e-mail address. The old
<bind-4.9@pa.dec.com> list has been moved to <bind-workers@vix.com>; if
you intend to help hack BIND and you want to be advised of alpha-testing
releases, send mail to <bind-workers-request@vix.com> and ask to be added
to the list.
Note that 4.9.1 was an interrim, nonpublished release intended to catch
the porting changes needed for 4.4BSD. It never really existed separately.
----- 4.9 release - April, 1993 - Paul Vixie <vixie@pa.dec.com>
For information on what's new in 4.9, see OPTIONS and CHANGES. Also note
that the man page for named(8) in man/named.8, and the entire Bind Operations
Guide in doc/BOG/*, has been updated for 4.9. Both make excellent reading.
Those of you who are thinking of adding features should first read TODO to
see if someone else has already indicated an intention to work on the same
thing. If your feature is significant you should ask <bind-workers@vix.com>
before you hack, if for no other reason than to tell other maintainers to
expect a patch soon.
Note that the resolver has a number of routines that may already be present
on your system. Efforts have been made to avoid generating code for them on
systems where they aren't needed; don't worry about them if they're
generated unneccessarily since the linker will sort things out.
This software is protected under the U C Regents' copyright. Changes made
by or released through Digital Equipment Corporation are subject to a
subsidiary copyright. The entire copyright is as follows:
++Copyright++ 1989
-
Copyright (c) 1989
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--
To build this: QUICK
(on SUNOS, use the BSD build environment or you will
get the wrong definition for O_NDELAY)
look at conf/options.h and edit to your tastes.
The OPTIONS file here in this directory will help you
figure out what to do.
You should also look at the Makefile to select the proper set
of definitions depending on whether you are using Ultrix,
SunOS, and other 4.[23] BSD-alikes or using BSD 4.4, BSD/386,
and other net2-alikes.
"make links" will build a shadow source tree full
of symbolic links. the default name of this tree
is "./native.b", but you can override it by setting
the DST variable on the "make" command line, as in:
make DST=vax.b SRC=..
if your DST is not a subdir of "here", you will need to
override the SRC variable's default (which is ".."),
as in:
make DST=/tmp/vax.b SRC=`pwd`
note that the DST directory must be nonexistent at
the time that you run "make links".
after "make links", you can cd to the new build
directory, check the settings in the Makefile, and
run "make depend". if you aren't using "make links"
(shame on you), just use "make depend" from "here".
"make depend" may fail on your system; if so, look in
the bin/ directory and find a mkdep that does in fact
work for you.
if you skip the "make depend" phase, or after you run it,
you can do "make all" (from the build directory if you
used "make links" or from "here" if you're just hacking
around). you will get the following new things out of it:
res/libresolv.a
compat/lib/lib44bsd.a (optional)
include/{netdb,resolv}.h
include/arpa/{inet,nameser}.h
compat/include/sys/{cdefs,bitypes}.h
tools/{nstest,nsquery,dig,host}
tools/nslookup/nslookup
named/named
named/named-xfer
if you have trouble with "make all", check conf/portability.h
for things that your system needs, or doesn't need, or whatever.
it is preferable to add #ifdef's to conf/portability.h than to
add them anywhere else.
from the build directory (or "here" if you didn't
use "make links"), you can try "make -n install"
which will tell you what will be installed. it might
actually be right; however, what you will probably have to
do is copy the above files into the places you want
run them from. the other files you will need are:
tools/nslookup/nslookup.help
named/named.restart
named/named.reload
resolver library notes: to install it, either put the .a
file into /usr/local/lib or /usr/lib (if you use -lresolv
on all the links of your networking software), or use "ar"
to put all res/*.o directly into your /lib/libc.a file.
either way you will want to copy the include files
(including those from compat/include/sys) over to
/usr/include (or /usr/local/include if you're willing to
use -I/usr/local/include on all your network-software
compiles). something like this:
cp res/libresolv.a /usr/lib; ranlib /usr/lib/libresolv.a
tar chf - include | (cd /usr/include; tar xvpf -)
cp compat/include/sys/*.h /usr/include/sys
installing the man pages is left as an exercise for the
reader. there are just too many different versions of
"man" floating around for me to be able to help you figure
out what to do for the one you happen to be using.
WARNING: If you were running a BIND 4.8.3 or earlier based
named you should remove all cache files prior to starting
named. It would generally be a good idea to remove all cache
files regardless when installing a new version. The creadability
code depends upon the cache files having been made with the
latest named-xfer for correct operation.
(special compilation-related warning about SunOS systems:)
From: Tom Limoncelli
To: vixie (Paul A Vixie)
Date: Mon, 11 Jan 93 11:30:39 EST
Sun compiler v2.0.1 hates bind4.9 code.
Sun has 3 compilers:
/usr/ucb/cc -- the default for SunOS 4.1.[123],
dropped in Solaris 2.0.
/usr/lang/cc -- the "unbundled" cc v1.0
(pretty good, but expensive), only
generates code for SunOS 4.1.x.
/usr/lang/cc.2.0.1 -- the latest "unbundled" cc,
for when they stop shipping the
bundled version altogether. This
generates code for SunOS 4.1.x and Solaris 2.x.
Sun's 2.0.1 C compiler (the one with the floating licenses) for SunOS
4.1.x outputs a HUGE number of warnings. They can be ignored.
--------------------- (4.8.3 README -- mostly obsolete now)
This directory contains all the info and sources
for the Berkeley Internet Name Domain server.
You should read and understand these directions before starting
to install the libraries and nameserver. Some of these steps
replace existing source and binary files; you should make backups
of all existing files before you begin this installation.
Two installation procedures are described. The first is for 4.3BSD
and other similar systems that are already configured to use earlier
versions of the nameserver, and which have the new version of <netdb.h>
(containing a h_addr_list field in the hostent structure). The second
procedure is for 4.2BSD and derived systems. This procedure requires
more decisions to be made, and may have to be varied due to system
or operation constraints.
The subdirectories and their contents are:
bin - shell scripts used by current Berkeley makefiles
man - manual pages & documentation
doc - copy of Bind Operations Guide, and other documents
include - include files to go in /usr/include
named - name server sources
res - source for C library resolver routines (and other libc additions)
(may be used as separate library, resolv.a)
conf/master - Sample data files
tools - some test programs
Here is how to install the name server on 4.3BSD:
0) cp bin/mkdep.append /usr/ucb/mkdep
cp bin/manroff /usr/man/manroff
1) cp include/arpa/nameser.h /usr/include/arpa
2) cp include/*.h /usr/include
3) cp man/*.1 /usr/man/manl
cp man/*.3 /usr/man/man3
cp man/*.5 /usr/man/man5
cp man/*.7 /usr/man/man7
cp man/*.8 /usr/man/man8
4) NOTE: Don't install the Makefiles on 4.3 Tahoe Release
cp res/{res*.c,herror.c} /usr/src/lib/libc/net
cp res/Makefile.libc.net /usr/src/lib/libc/net/Makefile
cp res/strcasecmp.c /usr/src/lib/libc/gen
cp res/strpbrk.c /usr/src/lib/libc/compat-sys5
cp res/named/{*.c,Makefile} /usr/src/lib/libc/net/named
5) add strcasecmp.[co] to the Makefile in /usr/src/lib/libc/gen
6) add strpbrk.[co] to the Makefile in /usr/src/lib/libc/compat-sys5
7) rebuild and install /lib/libc.a.
8) edit named/pathnames.h to correpond with your system's configuration
9) cd named; make depend; make all; make install
10) cd tools/nslookup; make nslookup; make install
11) create the master files (samples in conf/master/*)
12) edit /etc/rc.local to include:
if [ -f /etc/named ]; then
/etc/named; echo -n ' named' >/dev/console
fi
13) recompile network client and server programs that use gethostbyname, etc.
Here is how to install the name server on 4.2BSD or similar systems.
First, a few notes on the choices that must be made.
Rather than building libresolv.a, you may wish to integrate the resolver
routines into /lib/libc.a. This is recommended to make it easy to recompile
network programs once named is running. This procedure may require hand-
tayloring on some systems.
You will have to choose a version of mkdep from the bin directory
that will work on your system:
If you've modified make(1) to use .depend files as described
in the current sendmail distribution, use mkdep; otherwise,
if you have the 4.3BSD cc -M option, use mkdep.append; on ultrix,
use mkdep.ultrix (uses cc -Em); otherwise, use mkdep.old.compiler.
The mkdep script is used by "make depend" to regenerate Makefile dependency
lists.
You will need to chose a version of netdb.h. First, check /usr/include/netdb.h
on your system. If the hostent structure has a h_addr_list entry, you can
probably use your existing netdb.h or the one in include/netdb.h.
If the existing netdb.h in /usr/include does not have a h_addr_list field,
you will have to decide whether to update to the 4.3BSD format of the hostent
structure. This is the best approach, but cannot be used unless you plan
to upgrade entirely: if you use the new structure in /usr/include/resolv.h,
you must recompile everything that uses the hostent structure, including
the rest of the C library and all networking programs, without using
any pre-existing object files. If this isn't possible or desirable,
and /usr/include/netdb.h doesn't have an h_addr_list line, use
include/netdb.h.4.2 instead of netdb.h. The other version of netdb.h
(include/netdb.h.4.2.compat) may be used instead of include/netdb.h.4.2.
This version along with a change in res/named/gethostnamadr.c.compat
provide for using the new format of the hostent structure while having
binary compatibility with existing libraries.
On systems with Sun RPC, you will have to merge include/netdb.h or
include/netdb.h.4.2 with /usr/include/netdb.h; copy the rpc-related lines
into the appropriate copy of netdb.h. Alternatively, use an alternate
include path when compiling the resolver library and programs that use it.
0) cp bin/{whatever} /usr/ucb/mkdep (see above)
cp bin/manroff /usr/man/manroff
1) cp include/arpa/nameser.h /usr/include/arpa
Also, on ultrix 2.x, if you haven't fixed
the inet_addr definition in inet.h, do
cp include/arpa/inet.h /usr/include/arpa
2) cp include/resolv.h /usr/include
3) cp include/netdb.h /usr/include/netdb.h
OR
cp include/netdb.h.4.2 /usr/include/netdb.h
OR
edit /usr/include/netdb.h
4) cp man/*.1 /usr/man/manl
cp man/*.3 /usr/man/man3
cp man/*.5 /usr/man/man5
cp man/*.7 /usr/man/man7
cp man/*.8 /usr/man/man8
5) cd res; make depend;
make libresolv.a;
make install
OR
update the libc sources as in the 4.3BSD instructions above
and use res/Makefile as a guide for integration
and omit the RES=-lresolv in the next two steps
OR
compile the .o files in res according to Makefile,
then use place those object files in /lib/libc.a (keeping a backup!)
and omit the RES=-lresolv in the next two steps
6) edit named/pathnames.h to correpond with your system's configuration
7) cd named; make depend; make RES=-lresolv all; make install
(if your system defines signal-catching routines to return int
instead of void, use "make DEFINES=-DSIG_FN=int RES=-lresolv all")
8) edit tools/nslookup/pathnames.h to correpond with your system's
configuration
9) cd tools/nslookup; make RES=-lresolv nslookup install
10) create the master files (samples in conf/master/*)
11) edit /etc/rc.local to include:
if [ -f /etc/named ]; then
/etc/named; echo -n ' named' >/dev/console
fi
12) eventually, recompile network client and server programs that use
gethostbyname, etc.

187
usr.sbin/named/TODO Normal file
View File

@ -0,0 +1,187 @@
$Id: TODO,v 1.1.1.1 1997/04/13 09:06:10 mrg Exp $
Things to do. Each entry should contain the proposer, date proposed, and an
explaination of what's being proposed. New ones are added at the bottom.
Note that the author/coordinator of BIND does not neccessarily endorse all
of the proposals listed herein; if you did not get explicit "buy-in" then
your changes may not be accepted even if they appear in proposal form here
in this file.
[Mark.Andrews@dms.CSIRO.AU 14dec94]: rfc952/rfc1123 host name compliance:
-> Test domain names to ensure that the name conforms to the form
specified by RFC952 as modified by RFC1123.
-> WARN if the domain name does not meet the conditions set by
rfc952/rfc1123 for the following resource records.
class == C_IN && type == T_A
class == C_IN && type == T_MX
-> REJECT this records on the primary server.
-> CNAME which doesn't match pointing to the above is also
illegal but harder to check.
[paul@vix.com 30nov94]: cause NOTIFY to track the IETF process for it;
reorder ns_resp() again so that "Notify notimp" causes qdelete()
but the host source address checking and so on is still done.
[paul@vix.com 25apr93]: clean up #ifdef's and portability
feature #ifdef's should be limited to whole functions, which will be
called no matter what and would only be non-empty if the feature is
enabled. allow feature ifdef's in .h files, though.
portability #ifdef's should be limited to whole functions, too. add
a new portability.c module that implements anything which varies from
system to system.
add a second portability.h-like file that is included _before_ all the
system includes. portability.h as it stands is included _after_ all
system includes, which is convenient for most things but not all.
[sater@cs.vu.nl 26apr93]: sortlist improvement
Improve the code around the sortlist area to better cope with parallel
networks of different speeds. The -i hack I sent to you could function
as inspiration only.
[kre@munnari.oz.au 26apr93]: add an INN style control interface
to replace sending signals. With that expand debugging to
permit monitoring of actions taken on a single query
(query through control port, full traced as it occurs)
or all queries that reference some particular name or
zone, or which are forwarded, or asked, of some
particluar server. Allow reloads & dumps of a single
zone, rather than the whole universe. Allow selective
cache pruning (to edit away bad data that's been obtained
from somewhere)
[kre@munnari.oz.au 26apr93]: add a syntax to zone files (non rfc
standard, but I don't care) to permit RR's to age away
at some particular time, and others to become active at
some particular time (probably with a syntax something
like "<[date]" or "@[date]" preceding, or in the
former case, replacing, the TTL field of the record).
Approaching "date" in the "<[date]" case, the TTL's on
the record would be decreased, so no data cached anywhere
will remain valid after "date", after "date", this RR
would simply be inoperative (essentially identical to
a comment). In the "@[date]" case (or perhaps ">[date]"
for symmetry) the RR would be ignored until "date" at
which time the "@[date]" field would simply be ignored.
Both annotations could be used together (with
appropriate interpretations depending on which date is
earlier than the other). Annotations on RR's in a zone
would cause the SOA parameters to be automatically
adjusted in zone transfers (and SOA requests) so that
secondary servers would also hand out the same values
(dropping the TTL down low as a "<[date]" approaches,
and forcing a new zone transfer at "date").
[steve@uunet.uu.net 26apr93]: TXT RR improvements
- fix TXT records so that they can deal properly with multiple
strings (e.g., ``foo IN TXT "aaa" "bbb"''). This
results in a fair number of smallish changes throughout the
code and also throughout various tools (e.g., nslookup).
[kyle@uunet.uu.net 16may93]: need an option to die if primary zone file missing
as of 4.9, a server will not forward a query if it is itself on the
NS list for the relevant domain. this means that if a primary server
cannot load its zone file, it will not be able to answer queries in
that zone -- it won't even forward them. this is arguably correct,
since it prevents bad forwarding loops when two or more servers are
all unable to load the zone (primary or secondary, with secondary
failures being the more common). what is needed is real loop detection
such that reasonable non-looping queries can be forwarded. what we're
likely to actually get is an option that causes named to just syslog
and die if it can't load a primary zone file. note that at present,
named is running somewhat bare-assed since an expired zone in a
secondary (or missing zone file in a primary) will cause that named
to return SERVFAIL for all queries to that zone. if your screwed up
primary/secondary server is also the forwarding server for a collection
of hosts, those hosts will get SERVFAIL's back from queries to the
affected domains, and depending on the age of their resolvers, they
might not try other servers after they get the first SERVFAIL.
[ this entry was written by Paul Vixie after getting a problem report
from Kyle after uu.net disappeared in a brief but ugly way. --vix ]
[paul@vix.com 05jun94]: things i'm expecting to fix someday:
-> finish STATS (b+tree?), remove older A_RR-based tagging
-> (more?) svr4 changes from wisner@well, marc@cam, istewart@datlog
-> switch completely to posix-style signals
-> xfrnets directives should aggregate
-> syntactic sugar to use "mtime" of file as soa serial number
-> better support for "firewalls" (zohar@ibm, minnich@dupont)
-> attributes in TXT RR (cpw@lanl)
-> fix database consistency problems during zone reloads (Bob Heiney)
-> preliminary support for variable width subnet masks
-> failover isn't working very well for hesiod queries (gshapiro)
-> dig needs to be able to turn on RES_INSECURE{1,2} options
-> clean out old RR's that lay within a newly loaded zone file (heiney)
-> automatically refresh root.cache from the root servers periodically
-> Makefiles should use/pass CFLAGS rather than modifying CC
-> use Berkeley DB rather than malloc() for all database ops
-> include files should be generated from templates
-> use nvi-style port/* hierarchy, fewer portability #ifdef's
-> make __res static, add procedural interface to replace "extern"'ing
-> add hesiod/yp capable versions of get{pw,serv,???}by*()
-> add hesiod/yp to get{net,host}by*()
-> do something like solaris' /etc/nsswitch.conf (but in resolv.conf)
-> we should only need one copy of binary->text, text->binary, and
packet marshalling/unmarshalling. add general routines to -lresolv,
and rearrange the code to use them.
-> apps that want to do DNS queries should not have to learn res_query;
a higher level interface should be provided, that has its own cache
and/or shares with the server's DB-based one.
-> implement or integrate the next round of RFC's (coming soon).
[paul@vix.com 05jun95]: more things i'm expecting to fix someday:
-> add "ndc checkconf" (i.e., "named -v")
## ++Copyright++ 1993
## -
## Copyright (c) 1993
## 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--

23
usr.sbin/named/conf/options.h
View File

@ -1,9 +1,7 @@
/* $NetBSD: options.h,v 1.1 1996/02/02 15:26:11 mrg Exp $ */
/* options.h - specify the conditionally-compiled features
* vix 28mar92 [moved out of the Makefile because they were getting too big]
*
* $Id: options.h,v 8.7 1995/12/29 21:08:13 vixie Exp
* $Id: options.h,v 1.1.1.1 1997/04/13 09:06:59 mrg Exp $
*/
/*
@ -95,7 +93,7 @@
#define SLAVE_FORWARD /* use sensible timeouts on slave forwarders (pma) */
#define WANT_PIDFILE /* if you want the named.pid file (ucb/arc) */
#define DOTTED_SERIAL /* if you want to be able to specify dotted serial#s */
/*#define SENSIBLE_DOTS /* if you want dotted serial#s to make numeric sense */
#define SENSIBLE_DOTS /* if you want dotted serial#s to make numeric sense */
#define NCACHE /* negative caching (anant@isi.edu) */
/*#define VALIDATE /* validation procedure (anant@isi.edu) (BUGGY!) */
/*#define SHORT_FNAMES /* file names used in named-xfer need to be short */
@ -109,18 +107,17 @@
#define ADDAUTH /* return NS and glue w/ authorative answers (mpa) */
#define RFC1535 /* use RFC 1535 default for "search" list (vix) */
#define GEN_AXFR /* distinct zones within each class */
#define DATUMREFCNT /* use reference counts on datums (mpa) */
#define LAME_DELEGATION /* lame delegations (original-del,reworked-bb&del)*/
#define LAME_LOGGING LOG_WARNING /* log lame delegations, set log level */
#define LAME_LOGGING LOG_DEBUG /* log lame delegations, set log level */
#define GETSER_LOGGING LOG_INFO /* log errors/timeouts getting serial number */
/*#define RETURNSOA /* good code that the world isn't ready for yet */
#define RETURNSOA /* good code that the world might be ready for now */
#define CLEANCACHE /* useful and necessary in the face of NCACHE */
#define PURGE_ZONE /* remove all traces of a zone when reloading (mpa) */
/*#define STATS /* keep nameserver statistics; uses more memory */
#define STATS /* keep nameserver statistics; uses more memory */
#define RENICE /* named-xfer should run at normal priority */
/*#define XSTATS /* extended statistics, syslogged periodically (bg) */
/*#define BIND_NOTIFY /* experimental - do not enable in customer products */
#define LOC_RR /* support for (draft) LOC record parsing (ckd) */
#define LOC_RR /* support for LOC record parsing (ckd/vix) */
#define SORT_RESPONSE /* should we try to sort responses optimally? (vix) */
/*--------------------------------------------*
@ -152,14 +149,6 @@
# include "dmalloc.h"
#endif
/* systems with killall(1M) don't need this
*/
#ifdef __sgi
# ifdef WANT_PIDFILE
# undef WANT_PIDFILE
# endif
#endif
#ifdef LAME_LOGGING
# define LAME_DELEGATION
#endif

150
usr.sbin/named/conf/portability.h
View File

@ -1,14 +1,10 @@
/* $NetBSD: portability.h,v 1.1 1996/02/02 15:26:12 mrg Exp $ */
/* portability.h - include or define things that aren't present on all systems
* vixie@decwrl 26dec92 [new]
*
* $Id: portability.h,v 8.11 1995/12/22 10:20:19 vixie Exp
* $Id: portability.h,v 1.1.1.1 1997/04/13 09:06:57 mrg Exp $
*/
/*
* ++Copyright++
* -
* Copyright (c)
* The Regents of the University of California. All rights reserved.
*
@ -39,7 +35,9 @@
* 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
@ -57,21 +55,38 @@
* 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--
*/
/* XXX: this file has become a hopeless morass, and will be redone someday. */
/*
* Portions Copyright (c) 1996 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.
*/
#ifndef __BIND_PORTABILITY_H
#define __BIND_PORTABILITY_H
#include <string.h>
#include <signal.h>
#include <sys/types.h>
#include <sys/param.h>
#include <signal.h>
#include <string.h>
#ifndef TIME_H_INCLUDED
# include <sys/time.h>
# define TIME_H_INCLUDED
#endif
/* (ISC = INTERACTIVE Systems Corporation in the next #ifdef, btw.) */
#ifdef ISC
# ifndef _POSIX_SOURCE
# define _POSIX_SOURCE
@ -104,7 +119,15 @@
# define setitimer(a,b,c) __setitimer(a,b,c)
#endif
/* This is defined in the Makefile for ISC compiles. */
/* This is for AIX 4.1.x */
#ifdef _AIX41
# include <sys/select.h>
# include <sys/time.h>
# include <time.h>
# define vfork fork
#endif
/* This is defined in the Makefile for INTERACTIVE compiles. */
#if defined(ISC)
# define ftruncate(a,b) __ftruncate(a,b)
# define USE_MEMCPY
@ -114,17 +137,23 @@
/* SCO UNIX defines only this unique symbol, apparently. */
#if defined(M_UNIX)
/* XXX - why is this POSIX_SOURCE instead of _POSIX_SOURCE? */
# undef POSIX_SOURCE
# define POSIX_SIGNALS
# define HAVE_FCHMOD 0
# define writev(a,b,c) __writev(a,b,c)
# define ftruncate(a,b) __ftruncate(a,b)
# if !defined(_SCO_DS)
/* This section is for 3.2v4.2/ODT3.0 and maybe also for 3.2v4.1/3.2v4.0 */
/* XXX - why is this POSIX_SOURCE instead of _POSIX_SOURCE? */
# undef POSIX_SOURCE
# define HAVE_FCHMOD 0
# define NEED_WRITEV
# define writev(a,b,c) __writev(a,b,c)
# define ftruncate(a,b) __ftruncate(a,b)
# endif
#endif
#ifdef NeXT
# define NEED_PUTENV
# define NEED_SETENV
# define HAVE_STDLIB_H
# define NEED_STRDUP
# define inet_addr(a) __inet_addr(a)
#endif
@ -135,9 +164,10 @@
#if defined(SUNOS4)
# define BSD 43
# define NEED_STRTOUL
#endif
#if defined(__osf__) && defined(__alpha)
#if defined(__osf__) && defined(__alpha) && defined(BSD) && (BSD < 199103)
# undef BSD
# define BSD 199103
#endif
@ -150,14 +180,16 @@
# define USE_MEMCPY
#endif
#if defined(apollo)
# define HAVE_STDLIB_H
#endif
#if defined(SVR4) && !defined(SYSV)
# define SYSV
#endif
#if defined(_POSIX_SOURCE) || defined(__sgi) || defined(__ultrix) || \
defined(__hpux) || (defined(BSD) && (BSD >= 199103)) || \
(defined(sun) && defined(SYSV))
defined(__hpux) || (defined(BSD) && (BSD >= 199103)) || defined(sun)
# define USE_POSIX
#endif
@ -239,34 +271,43 @@ struct timezoneBSD {
# define _TIMEZONE timezone
#endif
#if defined(USE_POSIX)
#if defined(USE_POSIX) || defined(HAVE_STDLIB_H)
# include <stdlib.h>
# include <unistd.h>
# include <limits.h>
# if defined(__ultrix)
# define NEED_STRDUP
# endif
#else
# define NEED_STRTOUL
# if !defined(_SCO_DS)
# define NEED_STRDUP
# define NEED_STRTOUL
# endif
# define STDIN_FILENO 0
# define STDOUT_FILENO 1
# define STDERR_FILENO 2
# ifndef NeXT
extern char *getenv __P((char *));
# else
extern char *getenv __P((const char *));
# endif
extern int errno;
# if !defined(DMALLOC) && !defined(NeXT)
extern char *malloc(), *realloc(), *calloc();
# if defined(sun)
extern int free();
# else
extern void free();
# endif
# endif
#endif /*HAVE_STDLIB_H*/
#if defined(USE_POSIX)
# include <unistd.h>
# include <limits.h>
#else
# define STDIN_FILENO 0
# define STDOUT_FILENO 1
# define STDERR_FILENO 2
extern int errno;
extern int getdtablesize __P((void));
# ifdef SHORT_FNAMES
extern long pathconf __P((const char *path, int name));
@ -321,13 +362,15 @@ int strcasecmp __P((const char *, const char *));
extern void syslog();
# endif
extern char *ctime __P((const time_t *clock));
# if !defined(M_UNIX)
extern int close(), setitimer(), recv(), sendto(), sigsetmask(),
atoi(), getpid(), fork(), read(), ioctl(),
setsockopt(), socket(), bind();
# endif
#endif
#if !defined(bcopy) /* some machines have their own macros for this */
# if defined(USE_POSIX) || \
# if (defined(USE_POSIX) && !defined(SUNOS4)) || \
(defined(__STDC__) && !defined(sun) && !defined(sequent) \
&& !defined(M_UNIX))
/* use ANSI C3.159-1989 (``ANSI C'') functions if possible;
@ -366,13 +409,15 @@ extern int bcmp();
# endif
#endif
#if (!defined(BSD) || (BSD < 43))
#if (!defined(BSD) || (BSD < 43)) && !defined(__hpux)
# define NEED_MKSTEMP
# if !defined(__ultrix) && !defined(apollo)
# define NEED_STRCASECMP
# define NEED_MKTEMP
# if !defined(SVR4)
# define NEED_STRPBRK
# if !defined(_SCO_DS)
# define NEED_STRCASECMP
# define NEED_MKTEMP
# if !defined(SVR4)
# define NEED_STRPBRK
# endif
# endif
# endif
#endif
@ -409,8 +454,8 @@ extern int bcmp();
#if !defined(ntohl) && !defined(htonl) && defined(BSD) && (BSD <= 43)
/* if these aren't null macros in netinet/in.h, extern them here. */
extern u_short htons(), ntohs();
extern u_long htonl(), ntohl();
extern u_short htons __P((u_short)), ntohs __P((u_short));
extern u_long htonl __P((u_long)), ntohl __P((u_long));
#endif
#if defined(USE_POSIX) && !defined(sun) && !defined(__sgi) \
@ -553,6 +598,25 @@ extern u_long htonl(), ntohl();
# define HAVE_FCHMOD 1
#endif
/*
* Some systems need _res to be linked into text rather than bss.
*/
#if defined(__m88k__)
# define __BIND_RES_TEXT
#endif
/*
* We need to know the IPv6 address family number even on IPv4-only systems.
* Note that this is NOT a protocol constant, and that if the system has its
* own AF_INET6, different from ours below, all of BIND's libraries and
* executables will need to be recompiled after the system <sys/socket.h>
* has had this type added. The type number below is correct on most BSD-
* derived systems for which AF_INET6 is defined.
*/
#ifndef AF_INET6
#define AF_INET6 24
#endif
/*
* Prototype the functions we'll be supplying.
*/
@ -567,3 +631,9 @@ extern int gettimeofday __P((struct timeval *, struct _TIMEZONE *));
#if defined(SVR4) && defined(sun)
extern int gethostname __P((char *, size_t));
#endif
#ifdef NEED_STRDUP
extern char *strdup __P((const char *));
#endif
#endif /*__BIND_PORTABILITY_H*/

110
usr.sbin/named/dig/dig.c
View File

@ -1,7 +1,5 @@
/* $NetBSD: dig.c,v 1.1 1996/02/02 15:26:18 mrg Exp $ */
#ifndef lint
static char rcsid[] = "$Id: dig.c,v 8.6 1995/12/29 21:08:13 vixie Exp ";
static char rcsid[] = "$Id: dig.c,v 1.1.1.1 1997/04/13 09:07:00 mrg Exp $";
#endif
/*
@ -142,8 +140,8 @@ static char rcsid[] = "$Id: dig.c,v 8.6 1995/12/29 21:08:13 vixie Exp ";
*******************************************************************/
#define VERSION 21
#define VSTRING "2.1"
#define VERSION 22
#define VSTRING "2.2"
#include <sys/types.h>
#include <sys/param.h>
@ -192,6 +190,8 @@ static void Usage();
static int SetOption(), printZone(), printRR();
static struct timeval difftv();
static void prnttime();
static int xstrtonum();
static void res_re_init();
/* stuff for nslookup modules */
FILE *filePtr;
@ -212,11 +212,13 @@ char *pager = NULL;
** Take arguments appearing in simple string (from file or command line)
** place in char**.
*/
void
stackarg(y, l)
char *l;
char **y;
{
int done=0;
while (!done) {
switch (*l) {
case '\t':
@ -241,6 +243,7 @@ stackarg(y, l)
char myhostname[MAXHOSTNAMELEN];
int
main(argc, argv)
int argc;
char **argv;
@ -286,7 +289,6 @@ main(argc, argv)
int envset=0, envsave=0;
struct __res_state res_x, res_t;
char *pp;
time_t t;
res_init();
_res.pfcode = PRF_DEF;
@ -506,7 +508,7 @@ main(argc, argv)
} /* while argv remains */
if (_res.pfcode & 0x80000)
printf("; pfcode: %08x, options: %08x\n",
printf("; pfcode: %08lx, options: %08lx\n",
_res.pfcode, _res.options);
/*
@ -627,8 +629,8 @@ main(argc, argv)
myhostname,
inet_ntoa(_res.nsaddr_list[i]
.sin_addr));
t = exectime.tv_sec;
printf(";; WHEN: %s", ctime(&t));
printf(";; WHEN: %s",
ctime(&(exectime.tv_sec)));
}
if (!x)
break; /* success */
@ -682,8 +684,8 @@ main(argc, argv)
gettimeofday(&exectime,NULL);
printf(";; FROM: %s to SERVER: %s\n",
myhostname, srvmsg);
t = exectime.tv_sec;
printf(";; WHEN: %s", ctime(&t));
printf(";; WHEN: %s",
ctime(&(exectime.tv_sec)));
printf(";; MSG SIZE sent: %d rcvd: %d\n",
bytes_out, bytes_in);
}
@ -902,6 +904,7 @@ SetOption(string)
/*
* Force a reinitialization when the domain is changed.
*/
static void
res_re_init()
{
static char localdomain[] = "LOCALDOMAIN";
@ -926,7 +929,7 @@ res_re_init()
/*
* convert char string (decimal, octal, or hex) to integer
*/
int
static int
xstrtonum(p)
char *p;
{
@ -987,11 +990,13 @@ printZone(zone, sin)
int amtToRead;
int numRead;
int numAnswers = 0;
int numRecords = 0;
int result;
int soacnt = 0;
int sockFD;
int count, type, class, rlen, done, n;
u_short len;
u_char *cp, *nmp;
u_char *cp;
char dname[2][NAME_LEN];
char file[NAME_LEN];
static u_char *answer = NULL;
@ -1047,7 +1052,7 @@ printZone(zone, sin)
}
dname[0][0] = '\0';
while (1) {
for (done = 0; !done; NULL) {
u_int16_t tmp;
/*
@ -1101,27 +1106,44 @@ printZone(zone, sin)
error = ERR_PRINTING;
break;
}
numRecords += htons(((HEADER *)answer)->ancount);
numAnswers++;
/* Header. */
cp = answer + HFIXEDSZ;
if (ntohs(((HEADER *)answer)->qdcount) > 0)
cp += dn_skipname((u_char *)cp,
(u_char *)answer + len) + QFIXEDSZ;
nmp = cp;
cp += dn_skipname((u_char *)cp, (u_char *)answer + len);
if ((_getshort((u_char*)cp) == T_SOA)) {
(void) dn_expand(answer, answer + len, nmp,
dname[soacnt], sizeof dname[0]);
if (soacnt) {
if (strcmp(dname[0], dname[1]) == 0)
break;
} else
soacnt++;
/* Question. */
for (count = ntohs(((HEADER *)answer)->qdcount);
count > 0;
count--)
cp += dn_skipname(cp, answer + len) + QFIXEDSZ;
/* Answer. */
for (count = ntohs(((HEADER *)answer)->ancount);
count > 0;
count--) {
n = dn_expand(answer, answer + len, cp,
dname[soacnt], sizeof dname[0]);
if (n < 0) {
error = ERR_PRINTING;
done++;
break;
}
cp += n;
GETSHORT(type, cp);
GETSHORT(class, cp);
cp += INT32SZ; /* ttl */
GETSHORT(rlen, cp);
cp += rlen;
if (type == T_SOA && soacnt++ &&
!strcasecmp(dname[0], dname[1])) {
done++;
break;
}
}
}
fprintf(stdout, ";; Received %d record%s.\n",
numAnswers, (numAnswers != 1) ? "s" : "");
printf(";; Received %d answer%s (%d record%s).\n",
numAnswers, (numAnswers != 1) ? "s" : "",
numRecords, (numRecords != 1) ? "s" : "");
(void) close(sockFD);
sockFD = -1;
@ -1176,20 +1198,23 @@ printRR(file, msg, eom)
if (ntohs(headerPtr->ancount) == 0) {
return(NO_INFO);
} else {
if (ntohs(headerPtr->qdcount) > 0) {
nameLen = dn_skipname(cp, eom);
if (nameLen < 0)
return (ERROR);
cp += nameLen + QFIXEDSZ;
}
cp = (u_char*) p_rr(cp, msg, stdout);
}
for (n = ntohs(headerPtr->qdcount); n > 0; n--) {
nameLen = dn_skipname(cp, eom);
if (nameLen < 0)
return (ERROR);
cp += nameLen + QFIXEDSZ;
}
#ifdef PROTOCOLDEBUG
printf(";;; (message of %d octets has %d answers)\n",
eom - msg, ntohs(headerPtr->ancount));
#endif
for (n = ntohs(headerPtr->ancount); n > 0; n--)
cp = (u_char*) p_rr(cp, msg, stdout);
return(SUCCESS);
}
static
struct timeval
static struct timeval
difftv(a, b)
struct timeval a, b;
{
@ -1203,10 +1228,9 @@ difftv(a, b)
return(diff);
}
static
void
static void
prnttime(t)
struct timeval t;
{
printf("%u msec", t.tv_sec * 1000 + (t.tv_usec / 1000));
printf("%lu msec", (u_long)(t.tv_sec * 1000 + (t.tv_usec / 1000)));
}

111
usr.sbin/named/dnsquery/dnsquery.c
View File

@ -1,5 +1,3 @@
/* $NetBSD: dnsquery.c,v 1.1 1996/02/02 15:26:24 mrg Exp $ */
#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
@ -56,82 +54,32 @@ char *argv[];
case 'h' : strcpy(name, optarg);
break;
case 'c' : if (!strcasecmp(optarg, "IN"))
class = C_IN;
else if (!strcasecmp(optarg, "HS"))
class = C_HS;
else if (!strcasecmp(optarg, "CHAOS"))
class = C_CHAOS;
else if (!strcasecmp(optarg, "ANY"))
class = C_ANY;
else {
class = T_ANY;
fprintf(stderr, "optarg=%s\n", optarg);
}
break;
case 'c' : {
int success, proto_class;
case 't' : if (!strcasecmp(optarg, "A"))
type = T_A;
else if (!strcasecmp(optarg, "NS"))
type = T_NS;
else if (!strcasecmp(optarg, "MD"))
type = T_MD;
else if (!strcasecmp(optarg, "MF"))
type = T_MF;
else if (!strcasecmp(optarg, "CNAME"))
type = T_CNAME;
else if (!strcasecmp(optarg, "SOA"))
type = T_SOA;
else if (!strcasecmp(optarg, "MB"))
type = T_MB;
else if (!strcasecmp(optarg, "MG"))
type = T_MG;
else if (!strcasecmp(optarg, "MR"))
type = T_MR;
else if (!strcasecmp(optarg, "NULL"))
type = T_NULL;
else if (!strcasecmp(optarg, "WKS"))
type = T_WKS;
else if (!strcasecmp(optarg, "PTR"))
type = T_PTR;
else if (!strcasecmp(optarg, "HINFO"))
type = T_HINFO;
else if (!strcasecmp(optarg, "MINFO"))
type = T_MINFO;
else if (!strcasecmp(optarg, "MX"))
type = T_MX;
else if (!strcasecmp(optarg, "TXT"))
type = T_TXT;
else if (!strcasecmp(optarg, "RP"))
type = T_RP;
else if (!strcasecmp(optarg, "AFSDB"))
type = T_AFSDB;
else if (!strcasecmp(optarg, "ANY"))
type = T_ANY;
else if (!strcasecmp(optarg, "X25"))
type = T_X25;
else if (!strcasecmp(optarg, "ISDN"))
type = T_ISDN;
else if (!strcasecmp(optarg, "RT"))
type = T_RT;
else if (!strcasecmp(optarg, "NSAP"))
type = T_NSAP;
else if (!strcasecmp(optarg, "SIG"))
type = T_SIG;
else if (!strcasecmp(optarg, "KEY"))
type = T_KEY;
else if (!strcasecmp(optarg, "PX"))
type = T_PX;
else if (!strcasecmp(optarg, "GPOS"))
type = T_GPOS;
else if (!strcasecmp(optarg, "AAAA"))
type = T_AAAA;
else if (!strcasecmp(optarg, "LOC"))
type = T_LOC;
proto_class = sym_ston(__p_class_syms,
optarg, &success);
if (success)
class = proto_class;
else {
fprintf(stderr, "Bad type (%s)\n", optarg);
fprintf(stderr, "Bad class (%s)\n", optarg);
exit(-1);
}
}
break;
case 't' : {
int success, proto_type;
proto_type = sym_ston(__p_type_syms,
optarg, &success);
if (success)
type = proto_type;
else {
fprintf(stderr, "Bad type (%s)\n", optarg);
exit(-1);
}
}
break;
case 'd' : debug++;
@ -189,10 +137,17 @@ char *argv[];
* set these here so they aren't set for a possible call to
* gethostbyname above
*/
if (debug)
_res.options |= RES_DEBUG;
if (stream)
_res.options |= RES_USEVC;
if (debug || stream) {
if (!(_res.options & RES_INIT))
if (res_init() == -1) {
fprintf(stderr, "res_init() failed\n");
exit(-1);
}
if (debug)
_res.options |= RES_DEBUG;
if (stream)
_res.options |= RES_USEVC;
}
/* if the -n flag was used, add them to the resolver's list */
if (nameservers != 0) {

51
usr.sbin/named/doc/bog/00macs.me Normal file
View File

@ -0,0 +1,51 @@
.\" Copyright (c) 1986, 1988 Regents of the University of California.
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms are permitted
.\" provided that this notice is preserved and that due credit is given
.\" to the University of California at Berkeley. The name of the University
.\" may not be used to endorse or promote products derived from this
.\" software without specific prior written permission. This software
.\" is provided ``as is'' without express or implied warranty.
.\"
.\" @(#)00macs.me 6.3 (Berkeley) 2/28/88
.\"
.\" usage: troff -me myfile
.nr EX 0
.de BX
.sp
.ba +4
.lp
.nr EX +1
.b
.ta (\\n(.lu-\\n(.iu)R
EXAMPLE \\n(EX: \(*D
.r
.lp
..
.de EX
.br
.ba
.b
.tl '''\(gr'
.r
.lp
..
.if \nl .ls 2
.if t .nr bi 5m
.nr si 3n
.de $0 \" create a table of contents magically.
.(x
.ti (\\$3u-1u)*2m
\\$2. \\$1
.)x
..
.de $1
.sp
..
.de BU
.ip "\ \(bu" \w'\ \(bu\ 'u
..
.de SM
\s-1\\$1\s0\\$2
..

94
usr.sbin/named/doc/bog/00title.me Normal file
View File

@ -0,0 +1,94 @@
.\" ++Copyright++ 1986, 1988
.\" -
.\" Copyright (c) 1986, 1988
.\" The Regents of the University of California. All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\" -
.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
.\"
.\" Permission to use, copy, modify, and distribute this software for any
.\" purpose with or without fee is hereby granted, provided that the above
.\" copyright notice and this permission notice appear in all copies, and that
.\" the name of Digital Equipment Corporation not be used in advertising or
.\" publicity pertaining to distribution of the document or software without
.\" specific, written prior permission.
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT
.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
.\" SOFTWARE.
.\" -
.\" --Copyright--
.\"
.+c
.(l C
.sz 14
.b "Name Server Operations Guide"
.b "for \s-1BIND\s+1"
.sz
\fIRelease 4.9.5\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

93
usr.sbin/named/doc/bog/Makefile Normal file
View File

@ -0,0 +1,93 @@
# ++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)
# For Linux:
#PRINTER=
#TBL= tbl $(PRINTER)
TROFF= ditroff $(PRINTER)
GROFF= groff -Tps -t $(ME)
all: file.lst
file.lst: $(FILES)
tbl $(FILES)| $(NROFF) $(ME) $(FLAGS) > file.lst
file.psf: $(FILES)
$(GROFF) $(FILES) > file.psf
troff: $(FILES)
$(TBL) $(FILES)| $(TROFF) $(ME) $(FLAGS)
cat: $(FILES)
@cat $(FILES)
clean:
rm -f *.psf *.lst *.BAK *.CKP *~ *.orig
rm -f file
spell: $(FILES)
@for i in $(FILES); do \
echo $$i; \
spell $$i | sort | comm -23 - spell.ok > $$i.spell; \
done

287
usr.sbin/named/doc/bog/ack.me Normal file
View File

@ -0,0 +1,287 @@
.\" ++Copyright++ 1986, 1988
.\" -
.\" Copyright (c) 1986, 1988
.\" The Regents of the University of California. All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\" -
.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
.\"
.\" Permission to use, copy, modify, and distribute this software for any
.\" purpose with or without fee is hereby granted, provided that the above
.\" copyright notice and this permission notice appear in all copies, and that
.\" the name of Digital Equipment Corporation not be used in advertising or
.\" publicity pertaining to distribution of the document or software without
.\" specific, written prior permission.
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT
.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
.\" SOFTWARE.
.\" -
.\" --Copyright--
.\"
.\" @(#)ack.me
.\"
.sx 0
.bp
.ce
.b "ACKNOWLEDGEMENTS \(em 4.9.3"
.pp
The \fI<bind-workers@vix.com>\fP mailing list was once again of great help;
this release would not be nearly as ready for prime time if not for their
efforts. Special commendations are owed to Robert Elz, Don "Truck" Lewis,
Bob Halley, Mark Andrews, Berthold Paffrath, Ruediger Volk, and Peter Koch.
.pp
Digital Equipment Corporation, Hewlett Packard, Silicon Graphics, and SunSoft
all made hardware available for integration testing; this made the release
far more solid than it would otherwise have been. More hardware loans are
welcome \(em if you are a system vendor and you would like \s-2BIND\s+2 to
run ``out of the box'' on your platform and are willing to lend some rusty
old hardware for the purpose, please contact me (\fI<paul@vix.org>\fP) to
make the arrangements.
.pp
Special thanks to the Internet Software Consortium for funding this work.
Contact \fI<isc-info@isc.org>\fP if your organization would like to
participate in funding future releases of \s-2BIND\s+2 and other freely
redistributable software packages that are in wide use on the Internet.
.sp 2
.ce
.b "ACKNOWLEDGEMENTS \(em through 4.9"
.pp
The alpha-test group was extremely helpful in furnishing improvements,
finding and repairing bugs, and being patient. I would like to express
special thanks to Brian Reid of Digital Equipment corporation for funding
this work. Robert Elz, Alan Barrett, Paul Albitz, Bryan Beecher, Andrew
Partan, Andy Cherenson, Tom Limoncelli, Berthold Paffrath, Fuat Baran, Anant
Kumar, Art Harkin, Win Treese, Don Lewis, Christophe Wolfhugel, and a cast
of dozens all helped out above and beyond the call of duty. Special thanks
to Phil Almquist, who got the project started and contributed a lot of the
code and fixed several of the worst bugs.
.sp 2
.ce
.b "ACKNOWLEDGEMENTS \(em through 4.8.3"
.pp
Many thanks to the users at U. C. Berkeley for falling into many of the holes
involved with integrating BIND into the system so that others would be
spared the trauma. I would also like to extend gratitude to Jim McGinness
and Digital Equipment Corporation for permitting me to spend most of my time
on this project.
.pp
Ralph Campbell, Doug Kingston, Craig Partridge, Smoot Carl-Mitchell, Mike
Muuss and everyone else on the DARPA Internet who has contributed to the
development of BIND. To the members of the original BIND project, Douglas
Terry, Mark Painter, David Riggle and Songnian Zhou.
.pp
Anne Hughes, Jim Bloom and Kirk McKusick and the many others who have
reviewed this paper giving considerable advice.
.pp
This work was sponsored by the Defense Advanced Research Projects Agency
(DoD), Arpa Order No. 4871 monitored by the Naval Electronics Systems
Command under contract No. N00039-84-C-0089. The views and conclusions
contained in this document are those of the authors and should not be
interpreted as representing official policies, either expressed or implied,
of the Defense Research Projects Agency, of the US Government, or of Digital
Equipment Corporation.
.bp
.ba 0
.in 0
.sp 2
.ce
.b REFERENCES
.sp
.nr ii 1i
.ip [Birrell]
Birrell, A. D.,
Levin, R.,
Needham, R. M.,
and Schroeder, M.D.,
.q "Grapevine: An Exercise in Distributed Computing."
In
.ul
Comm. A.C.M. 25,
4:260-274
April 1982.
.ip [RFC819]
Su, Z.
Postel, J.,
.q "The Domain Naming Convention for Internet User Applications."
.ul
Internet Request For Comment 819
Network Information Center,
SRI International,
Menlo Park, California.
August 1982.
.ip [RFC974]
Partridge, C.,
.q "Mail Routing and The Domain System."
.ul
Internet Request For Comment 974
Network Information Center,
SRI International,
Menlo Park, California.
February 1986.
.ip [RFC1032]
Stahl, M.,
.q "Domain Administrators Guide"
.ul
Internet Request For Comment 1032
Network Information Center,
SRI International,
Menlo Park, California.
November 1987.
.ip [RFC1033]
Lottor, M.,
.q "Domain Administrators Guide"
.ul
Internet Request For Comment 1033
Network Information Center,
SRI International,
Menlo Park, California.
November 1987.
.ip [RFC1034]
Mockapetris, P.,
.q "Domain Names - Concept and Facilities."
.ul
Internet Request For Comment 1034
Network Information Center,
SRI International,
Menlo Park, California.
November 1987.
.ip [RFC1035]
Mockapetris, P.,
.q "Domain Names - Implementation and Specification."
.ul
Internet Request For Comment 1035
Network Information Center,
SRI International,
Menlo Park, California.
November 1987.
.ip [RFC1101]
Mockapetris, P.,
.q "DNS Encoding of Network Names and Other Types."
.ul
Internet Request For Comment 1101
Network Information Center,
SRI International,
Menlo Park, California.
April 1989.
.ip [RFC1123]
R. Braden, Editor,
.q "Requirements for Internet Hosts -- Application and Support"
.ul
Internet Request For Comment 1123
Network Information Center,
SRI International,
Menlo Park, California.
October 1989.
.ip [RFC1183]
Everhart, C.,
Mamakos, L.,
Ullmann, R.,
and
Mockapetris, P.,
.q "New DNS RR Definitions"
.ul
Internet Request For Comment 1183
Network Information Center,
SRI International,
Menlo Park, California.
October 1990.
.ip [RFC1327]
Hardcastle-Kille, S.,
.q "Mapping between X.400(1988) / ISO 10021 and RFC 822"
.ul
Internet Request For Comment 1327
Network Information Center,
SRI International,
Menlo Park, California.
May 1992.
.ip [RFC1664]
Allocchio, C.,
Bonito, A.,
Cole, B.,
Giordano, S.,
Hagens, R.,
.q "Using the Internet DNS to Distribute RFC1327 Mail Address Mapping Tables"
.ul
Internet Request For Comment 1664
Network Information Center,
SRI International,
Menlo Park, California.
August 1994.
.ip [RFC1713]
Romao, A.,
.q "Tools for DNS debugging"
.ul
Internet Request For Comment 1713, also FYI27
Network Information Center,
SRI International,
Menlo Park, California.
November 1994.
.ip [Terry]
Terry, D. B.,
Painter, M.,
Riggle, D. W.,
and
Zhou, S.,
.ul
The Berkeley Internet Name Domain Server.
Proceedings USENIX Summer Conference,
Salt Lake City, Utah.
June 1984, pages 23-31.
.ip [Zhou]
Zhou, S.,
.ul
The Design and Implementation of the Berkeley Internet Name Domain (BIND) Servers.
UCB/CSD 84/177.
University of California, Berkeley,
Computer Science Division.
May 1984.
.ip [Mockapetris]
Mockapetris, P.,
Dunlap, K,
.ul
Development of the Domain Name System
ACM Computer Communications Review 18, 4:123-133.
Proceedings ACM SIGCOMM '88 Symposium,
August 1988.
.ul
.ip [Liu]
Liu, C.,
Albitz, P.,
.ul
DNS and BIND
O'Reilly & Associates, Sebastopol, CA,
502 pages, ISBN 0-937175-82-X
1992

102
usr.sbin/named/doc/bog/build.me Normal file
View File

@ -0,0 +1,102 @@
.\" ++Copyright++ 1986, 1988
.\" -
.\" Copyright (c) 1986, 1988
.\" The Regents of the University of California. All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\" -
.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
.\"
.\" Permission to use, copy, modify, and distribute this software for any
.\" purpose with or without fee is hereby granted, provided that the above
.\" copyright notice and this permission notice appear in all copies, and that
.\" the name of Digital Equipment Corporation not be used in advertising or
.\" publicity pertaining to distribution of the document or software without
.\" specific, written prior permission.
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT
.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
.\" SOFTWARE.
.\" -
.\" --Copyright--
.\"
.\" @(#)build.me 6.3 (Berkeley) 9/19/89
.\"
.sh 1 "Building a System with a Name Server"
.pp
BIND is composed of two parts. One is the user interface called the
\fIresolver\fP
which consists of a group of routines that reside in the C library
\fI/lib/libc.a\fP.
Second is the actual server called \fInamed\fP.
This is a daemon that runs in the background and services queries on a
given network port. The standard port for UDP and TCP is specified in
\fI/etc/services\fP.
.sh 2 "Resolver Routines in libc"
.pp
When building your 4.3BSD system you may either
build the C library to use the name server resolver routines
or use the host table lookup routines to do host name and address resolution.
The default resolver for 4.3BSD uses the name server. Newer BSD systems
include both name server and host table functionality with preference given
to the name server if there is one or if there is a \fI/etc/resolv.conf\fP
file.
.pp
Building the C library to use the name server changes the way
\fIgethostbyname\fP\|(3N), \fIgethostbyaddr\fP\|(3N), and
\fIsethostent\fP\|(3N) do their functions. The name server renders
\fIgethostent\fP\|(3N) obsolete, since it has no concept of a next line in
the database. These library calls are built with the resolver routines
needed to query the name server.
.pp
The \fIresolver\fP contains functions that build query
packets and exchange them with name servers.
.pp
Before building the 4.3BSD C library, set the variable \fIHOSTLOOKUP\fP
equal to \fInamed\fP in \fI/usr/src/lib/libc/Makefile\fP. You
then make and install the C library and compiler and then compile the rest
of the 4.3BSD system. For more information see section 6.6 of ``Installing
and Operating 4.3BSD on the VAX\(dd''.
.(f
\(ddVAX is a Trademark of Digital Equipment Corporation
.)f
.pp
If your operating system isn't VAX\(dd 4.3BSD, it is probably the case that
your vendor has included \fIresolver\fP support in the supplied C Library.
You should consult your vendor's documentation to find out what has to be
done to enable \fIresolver\fP support. Note that your vendor's \fIresolver\fP
may be out of date with respect to the one shipped with \s-1BIND\s+1, and that
you might want to build \s-1BIND\s+1's resolver library and install it, and
its include files, into your system's compile/link path so that your own
network applications will be able to use the newer features.

3036
usr.sbin/named/doc/bog/file.lst Normal file
View File

File diff suppressed because it is too large Load Diff

2836
usr.sbin/named/doc/bog/file.psf Normal file
View File

File diff suppressed because it is too large Load Diff

1154
usr.sbin/named/doc/bog/files.me Normal file
View File

File diff suppressed because it is too large Load Diff

75
usr.sbin/named/doc/bog/intro.me Normal file
View File

@ -0,0 +1,75 @@
.\" ++Copyright++ 1986, 1988
.\" -
.\" Copyright (c) 1986, 1988
.\" The Regents of the University of California. All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\" -
.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
.\"
.\" Permission to use, copy, modify, and distribute this software for any
.\" purpose with or without fee is hereby granted, provided that the above
.\" copyright notice and this permission notice appear in all copies, and that
.\" the name of Digital Equipment Corporation not be used in advertising or
.\" publicity pertaining to distribution of the document or software without
.\" specific, written prior permission.
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT
.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
.\" SOFTWARE.
.\" -
.\" --Copyright--
.\"
.\" @(#)intro.me 6.2 (Berkeley) 2/28/88
.\"
.sh 1 Introduction
.pp
The Berkeley Internet Name Domain (\s-1BIND\s+1) implements an Internet name
server for \s-2BSD\s+2-derived operating systems. The \s-1BIND\s+1 consists
of a server (or ``daemon'') called \fInamed\fP and a \fIresolver\fP library.
A name server is a network service that enables clients to name resources or
objects and share this information with other objects in the network. This
in effect is a distributed data base system for objects in a computer
network. The \s-1BIND\s+1 server runs in the background, servicing queries
on a well known network port. The standard port for UDP and TCP is specified
in \fI/etc/services\fP. The \fIresolver\fP is a set of routines residing
in a system library that provides the interface that programs can use to
access the domain name services.
.pp
BIND is fully integrated into BSD (4.3 and later releases)
network programs for use in storing and retrieving host names and address.
The system administrator can configure the system to use BIND as a
replacement to the older host table lookup of information in the network
hosts file \fI/etc/hosts\fP. The default configuration for BSD uses
BIND.

156
usr.sbin/named/doc/bog/manage.me Normal file
View File

@ -0,0 +1,156 @@
.\" ++Copyright++ 1986, 1988, 1995
.\" -
.\" Copyright (c) 1986, 1988, 1995
.\" The Regents of the University of California. All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\" -
.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
.\"
.\" Permission to use, copy, modify, and distribute this software for any
.\" purpose with or without fee is hereby granted, provided that the above
.\" copyright notice and this permission notice appear in all copies, and that
.\" the name of Digital Equipment Corporation not be used in advertising or
.\" publicity pertaining to distribution of the document or software without
.\" specific, written prior permission.
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT
.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
.\" SOFTWARE.
.\" -
.\" --Copyright--
.\"
.\" @(#)manage.me 6.6 (Berkeley) 9/19/89
.\" $Id: manage.me,v 1.1.1.1 1997/04/13 09:07:57 mrg 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.

77
usr.sbin/named/doc/bog/named.boot.cache Normal file
View File

@ -0,0 +1,77 @@
.\" ++Copyright++ 1986, 1988
.\" -
.\" Copyright (c) 1986, 1988
.\" The Regents of the University of California. All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\" -
.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
.\"
.\" Permission to use, copy, modify, and distribute this software for any
.\" purpose with or without fee is hereby granted, provided that the above
.\" copyright notice and this permission notice appear in all copies, and that
.\" the name of Digital Equipment Corporation not be used in advertising or
.\" publicity pertaining to distribution of the document or software without
.\" specific, written prior permission.
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT
.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
.\" SOFTWARE.
.\" -
.\" --Copyright--
.\"
.\" @(#)named.boot.cache 6.4 (Berkeley) 9/19/89
.\"
.ne 13v
.sh 4 "Caching Only Server"
.(b L
.TS
l.
;
; Boot file for Caching Only Name Server
;
.TE
.TS
l l l
l
l l l.
; type domain source file or host
;
directory /usr/local/adm/named
cache \fB.\fP root\fB.\fPcache
primary 0\fB.\fP0\fB.\fP127\fB.\fPin-addr\fB.\fParpa named\fB.\fPlocal
.TE
.)b

78
usr.sbin/named/doc/bog/named.boot.primary Normal file
View File

@ -0,0 +1,78 @@
.\" ++Copyright++ 1986, 1988
.\" -
.\" Copyright (c) 1986, 1988
.\" The Regents of the University of California. All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\" -
.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
.\"
.\" Permission to use, copy, modify, and distribute this software for any
.\" purpose with or without fee is hereby granted, provided that the above
.\" copyright notice and this permission notice appear in all copies, and that
.\" the name of Digital Equipment Corporation not be used in advertising or
.\" publicity pertaining to distribution of the document or software without
.\" specific, written prior permission.
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT
.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
.\" SOFTWARE.
.\" -
.\" --Copyright--
.\"
.\" @(#)named.boot.primary 6.4 (Berkeley) 9/19/89
.\"
.ne 15v
.sh 3 "Boot Files"
.sh 4 "Primary Server"
.(b L
.TS
l.
;
; Boot file for Primary Name Server
;
.TE
.TS
l l l
l
l l l.
; type domain source file or host
;
directory /usr/local/adm/named
primary Berkeley\fB.\fPEdu ucbhosts
primary 32\fB.\fP128\fB.\fPin-addr\fB.\fParpa ucbhosts\fB.\fPrev
primary 0\fB.\fP0\fB.\fP127\fB.\fPin-addr\fB.\fParpa named\fB.\fPlocal
cache \fB.\fP root\fB.\fPcache
.TE
.)b

77
usr.sbin/named/doc/bog/named.boot.secondary Normal file
View File

@ -0,0 +1,77 @@
.\" ++Copyright++ 1986, 1988
.\" -
.\" Copyright (c) 1986, 1988
.\" The Regents of the University of California. All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\" -
.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
.\"
.\" Permission to use, copy, modify, and distribute this software for any
.\" purpose with or without fee is hereby granted, provided that the above
.\" copyright notice and this permission notice appear in all copies, and that
.\" the name of Digital Equipment Corporation not be used in advertising or
.\" publicity pertaining to distribution of the document or software without
.\" specific, written prior permission.
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT
.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
.\" SOFTWARE.
.\" -
.\" --Copyright--
.\"
.\" @(#)named.boot.secondary 6.4 (Berkeley) 9/19/89
.\"
.ne 12v
.sh 4 "Secondary Server"
.(b L
.TS
l.
;
; Boot file for Secondary Name Server
;
.TE
.TS
l l l
l
l l l.
; type domain source file or host
;
directory /usr/local/adm/named
secondary Berkeley\fB.\fPEdu 128\fB.\fP32\fB.\fP0\fB.\fP4 128\fB.\fP32\fB.\fP0\fB.\fP10 ucbhosts.bak
secondary 32\fB.\fP128\fB.\fPin-addr\fB.\fParpa 128\fB.\fP32\fB.\fP0\fB.\fP4 128\fB.\fP32\fB.\fP0\fB.\fP10 ucbhosts.rev.bak
primary 0\fB.\fP0\fB.\fP127\fB.\fPin-addr\fB.\fParpa named\fB.\fPlocal
cache \fB.\fP root\fB.\fPcache
.TE
.)b

75
usr.sbin/named/doc/bog/named.local Normal file
View File

@ -0,0 +1,75 @@
.\" ++Copyright++ 1986, 1988
.\" -
.\" Copyright (c) 1986, 1988
.\" The Regents of the University of California. All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\" -
.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
.\"
.\" Permission to use, copy, modify, and distribute this software for any
.\" purpose with or without fee is hereby granted, provided that the above
.\" copyright notice and this permission notice appear in all copies, and that
.\" the name of Digital Equipment Corporation not be used in advertising or
.\" publicity pertaining to distribution of the document or software without
.\" specific, written prior permission.
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT
.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
.\" SOFTWARE.
.\" -
.\" --Copyright--
.\"
.\" @(#)named.local 6.3 (Berkeley) 5/24/89
.\"
.ne 13v
.sh 3 "named.local"
.(b L
.TS
l l l l l s.
@ IN SOA ucbvax\fB.\fPBerkeley\fB.\fPEdu. kjd\fB.\fPucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP (
.T&
l l l l l.
1994072100 ; Serial
10800 ; Refresh
1800 ; Retry
3600000 ; Expire
259200 ) ; Minimum
.T&
l l l l l s.
IN NS ucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP ; pedantic
1 IN PTR localhost\fB.\fP
.TE
.)b

127
usr.sbin/named/doc/bog/ns.me Normal file
View File

@ -0,0 +1,127 @@
.\" Copyright (c) 1986, 1988
.\" The Regents of the University of California. All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\" -
.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
.\"
.\" Permission to use, copy, modify, and distribute this software for any
.\" purpose with or without fee is hereby granted, provided that the above
.\" copyright notice and this permission notice appear in all copies, and that
.\" the name of Digital Equipment Corporation not be used in advertising or
.\" publicity pertaining to distribution of the document or software without
.\" specific, written prior permission.
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT
.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
.\" SOFTWARE.
.\"
.\" @(#)ns.me 6.3 (Berkeley) 9/19/89
.\"
.sh 1 "The Name Service"
.pp
The basic function of the name server is to provide information about network
objects by answering queries. The specifications for this name server are
defined in RFC1034, RFC1035 and RFC974. These documents can be found in
\fI/usr/src/etc/named/doc\fP in 4.3BSD or \fIftp\fPed from
\fBftp.rs.internic.net\fP.
It is also recommended that you read the related manual pages,
\fInamed\fP\|(8),
\fIresolver\fP\|(3),
and \fIresolver\fP\|(5).
.pp
The advantage of using a name server over the host table lookup for host
name resolution is to avoid the need for a single centralized clearinghouse
for all names. The authority for this information can be delegated to the
different organizations on the network responsible for it.
.pp
The host table lookup routines require that the master file for the entire
network be maintained at a central location by a few people. This works
fine for small networks where there are only a few machines and the
different organizations responsible for them cooperate. But this does not
work well for large networks where machines cross organizational boundaries.
.pp
With the name server, the network can be broken into a hierarchy of domains.
The name space is organized as a tree according to organizational or
administrative boundaries.
Each node, called a \fIdomain\fP, is given a label, and the name of the
domain is the concatenation of all the labels of the domains from
the root to the current domain, listed from right to left separated by dots.
A label need only be unique within its domain.
The whole space is partitioned into several areas called \fIzones\fP,
each starting at a domain and extending down to the leaf domains or to
domains where other zones start.
Zones usually represent administrative boundaries.
An example of a host address for a host at the University of California,
Berkeley would look as follows:
.(b
\fImonet\fP\|\fB.\fP\|\fIBerkeley\fP\|\fB.\fP\|\fIEDU\fP
.)b
The top level domain for educational organizations is EDU;
Berkeley is a subdomain of EDU and monet is the name of the host.
.sh 1 Security
.pp
This section examines some of the know security implications of various
versions of BIND. Some of these have been used to attack the nameservers
in the past.
.sh 2 "Unnecessary Glue"
.pp
Unnecessary glue can lead to incorrect records being loaded into the
server. This can result in connections going to the wrong machines.
.pp
To prevent unnecessary glue being loaded, all the servers of zones being
servered by a server and the servers of the parent zones need to be
upgraded to BIND 4.9.3 or later.
.sh 2 "Insertion of data into a zone that is being servered"
.pp
BIND versions prior to BIND 4.9.2 are subject to the insertion of
resource records into zone that they are serving.
.sh 2 "Denial of Service: Hash Bug Exploit"
.pp
September 1996 saw the COM TLD subject to a denial of service attack by
injecting into the DNS a record with a final label of COM, eight spaces
and COM. This effected BIND 4.9.4 servers. Similar attacks are possible
on BIND 4.9.3 and BIND 4.9.3-P1.
.pp
It is recommend that you run a BIND 4.9.4-P1 or later server to avoid
this exploit.
.sh 2 "Denial of Service: TTL Inconsistency Attacks"
.pp
If you are still using multiple TTL values within a RRset you can be
subject to a denial of service attack. BIND 4.9.5 onwards uses multiple
ttl values within a RRset to reject obviously bad RRset.
.pp
It is recommend that you upgrade to BIND 4.9.5 or later as these server
prevent you loading multiple TTL values and doesn't merge answers received
across the network.

67
usr.sbin/named/doc/bog/resolv.conf Normal file
View File

@ -0,0 +1,67 @@
.\" ++Copyright++ 1986, 1988
.\" -
.\" Copyright (c) 1986, 1988
.\" The Regents of the University of California. All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\" -
.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
.\"
.\" Permission to use, copy, modify, and distribute this software for any
.\" purpose with or without fee is hereby granted, provided that the above
.\" copyright notice and this permission notice appear in all copies, and that
.\" the name of Digital Equipment Corporation not be used in advertising or
.\" publicity pertaining to distribution of the document or software without
.\" specific, written prior permission.
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT
.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
.\" SOFTWARE.
.\" -
.\" --Copyright--
.\"
.\" @(#)resolv.conf 6.2 (Berkeley) 2/29/88
.\"
.ne 6v
.\" .bp
.sh 3 "Remote Server / DNS Client"
.sh 4 "/etc/resolv.conf"
.(b L
domain Berkeley\fB.\fPEdu
nameserver 128\fB.\fP32\fB.\fP0\fB.\fP4
nameserver 128\fB.\fP32\fB.\fP0\fB.\fP10
sortlist 130.155.160.0/255.255.240.0 130.155.0.0
.)b

102
usr.sbin/named/doc/bog/root.cache Normal file
View File

@ -0,0 +1,102 @@
.\" ++Copyright++ 1986, 1988
.\" -
.\" Copyright (c) 1986, 1988
.\" The Regents of the University of California. All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\" -
.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
.\"
.\" Permission to use, copy, modify, and distribute this software for any
.\" purpose with or without fee is hereby granted, provided that the above
.\" copyright notice and this permission notice appear in all copies, and that
.\" the name of Digital Equipment Corporation not be used in advertising or
.\" publicity pertaining to distribution of the document or software without
.\" specific, written prior permission.
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT
.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
.\" SOFTWARE.
.\" -
.\" --Copyright--
.\"
.\" @(#)root.cache 6.4 (Berkeley) 4/29/90
.\"
.ne 38v
.sh 3 "root.cache"
.(b L
;
; This file holds the information on root name servers needed to
; initialize cache of Internet domain name servers
; (e.g. reference this file in the "cache . <file>"
; configuration file of BIND domain name servers).
;
; This file is made available by InterNIC registration services
; under anonymous FTP as
; file /domain/named.root
; on server FTP.RS.INTERNIC.NET
; -OR- under Gopher at RS.INTERNIC.NET
; under menu InterNIC Registration Services (NSI)
; submenu InterNIC Registration Archives
; file named.root
;
; last update: Oct 5, 1994
; related version of root zone: 1994100500
;
.TS
l l l l l.
\fB.\fP 604800 IN NS NS\fB.\fPINTERNIC\fB.\fPNET\fB.\fP
NS\fB.\fPINTERNIC\fB.\fPNET\fB.\fP 604800 IN A 198\fB.\fP41\fB.\fP0\fB.\fP4
\fB.\fP 604800 IN NS NS1\fB.\fPISI\fB.\fPEDU\fB.\fP
NS1\fB.\fPISI\fB.\fPEDU\fB.\fP 604800 IN A 128\fB.\fP9\fB.\fP0\fB.\fP107
\fB.\fP 604800 IN NS C\fB.\fPPSI\fB.\fPNET\fB.\fP
C\fB.\fPPSI\fB.\fPNET\fB.\fP 604800 IN A 192\fB.\fP33\fB.\fP4\fB.\fP12
\fB.\fP 604800 IN NS TERP\fB.\fPUMD\fB.\fPEDU\fB.\fP
TERP\fB.\fPUMD\fB.\fPEDU\fB.\fP 604800 IN A 128\fB.\fP8\fB.\fP10\fB.\fP90
\fB.\fP 604800 IN NS NS\fB.\fPNASA\fB.\fPGOV\fB.\fP
NS\fB.\fPNASA\fB.\fPGOV\fB.\fP 604800 IN A 128\fB.\fP102\fB.\fP16\fB.\fP10
604800 IN A 192\fB.\fP52\fB.\fP195\fB.\fP10
\fB.\fP 604800 IN NS NS\fB.\fPISC\fB.\fPORG\fB.\fP
NS\fB.\fPISC\fB.\fPORG\fB.\fP 604800 IN A 192\fB.\fP5\fB.\fP5\fB.\fP241
\fB.\fP 604800 IN NS NS\fB.\fPNIC\fB.\fPDDN\fB.\fPMIL\fB.\fP
NS\fB.\fPNIC\fB.\fPDDN\fB.\fPMIL\fB.\fP 604800 IN A 192\fB.\fP112\fB.\fP36\fB.\fP4
\fB.\fP 604800 IN NS AOS\fB.\fPARL\fB.\fPARMY\fB.\fPMIL\fB.\fP
AOS\fB.\fPARL\fB.\fPARMY\fB.\fPMIL\fB.\fP 604800 IN A 128\fB.\fP63\fB.\fP4\fB.\fP82
604800 IN A 192\fB.\fP5\fB.\fP25\fB.\fP82
\fB.\fP 604800 IN NS NIC\fB.\fPNORDU\fB.\fPNET\fB.\fP
NIC\fB.\fPNORDU\fB.\fPNET\fB.\fP 604800 IN A 192\fB.\fP36\fB.\fP148\fB.\fP17
.TE
; End of File
.)b

88
usr.sbin/named/doc/bog/setup.me Normal file
View File

@ -0,0 +1,88 @@
.\" ++Copyright++ 1986, 1988
.\" -
.\" Copyright (c) 1986, 1988
.\" The Regents of the University of California. All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\" -
.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
.\"
.\" Permission to use, copy, modify, and distribute this software for any
.\" purpose with or without fee is hereby granted, provided that the above
.\" copyright notice and this permission notice appear in all copies, and that
.\" the name of Digital Equipment Corporation not be used in advertising or
.\" publicity pertaining to distribution of the document or software without
.\" specific, written prior permission.
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT
.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
.\" SOFTWARE.
.\" -
.\" --Copyright--
.\"
.\" @(#)setup.me 6.4 (Berkeley) 9/19/89
.\"
.sh 1 "Setting up Your Own Domain"
.pp
When setting up a domain that is going to be on a public network the site
administrator should contact the organization in charge of the network and
request the appropriate domain registration form. An organization that
belongs to multiple networks (such as the \fIInternet\fP and
\fIBITNET\fP) should register with only one network.
.sh 2 "Internet"
.pp
Sites on the Internet who need information on setting up a domain should
contact the registrar for their network, which is one of the following:
.TS
l l.
MILnet \s-1HOSTMASTER\s+1@\s-1NIC\s+1\fB\|.\|\fP\s-1DDN\s+1\fB\|.\|\fP\s-1MIL\s+1
other \s-1HOSTMASTER\s+1@\s-1INTERNIC\s+1\fB\|.\|\fP\s-1NET\s+1
.TE
You may also want to be placed on the \s-1BIND\s+1 mailing list, which is a
mail group for people on the Internet who run \s-1BIND\s+1. The group
discusses future design decisions, operational problems, and other related
topic. The address to request being placed on this mailing list is:
.(b l
\fIbind-request\|@\|uunet\fP\fB\|.\|\fP\fIuu\fP\fB\|.\|\fP\fInet\fP
.)b
.sh 2 "Subdomains of Existing Domains"
.pp
If you want a subdomain of some existing domain, you should find the contact
point for the parent domain rather than asking one of the above top-level
registrars. There should be a convention that \fBregistrar\fP@\fIdomain\fP
or \fBhostmaster\fP@\fIdomain\fP for any given domain will always be an alias
for that domain's registrar (somewhat analogous to \fBpostmaster\fP), but
there is no such convention. Try it as a last resort, but first you should
examine the \fISOA\fP record for the domain and send mail to the ``responsible
person'' shown therein. You can also try \fIwhois\fP.

163
usr.sbin/named/doc/bog/types.me Normal file
View File

@ -0,0 +1,163 @@
.\" ++Copyright++ 1986, 1988, 1995
.\" -
.\" Copyright (c) 1986, 1988, 1995
.\" The Regents of the University of California. All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\" -
.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
.\"
.\" Permission to use, copy, modify, and distribute this software for any
.\" purpose with or without fee is hereby granted, provided that the above
.\" copyright notice and this permission notice appear in all copies, and that
.\" the name of Digital Equipment Corporation not be used in advertising or
.\" publicity pertaining to distribution of the document or software without
.\" specific, written prior permission.
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT
.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
.\" SOFTWARE.
.\" -
.\" --Copyright--
.\"
.\" @(#)types.me 6.3 (Berkeley) 9/19/89
.\"
.sh 1 "Types of Zones"
.pp
A ``zone'' is a point of delegation in the DNS tree. It contains all names
from a certain point ``downward'' except those which are delegated to other
zones. A ``delegation point'' has one or more \fINS\fP records in the
``parent zone'', which should be matched by equivalent \fINS\fP records at
the root of the ``delegated zone'' (i.e., the ``@'' name in the zone file).
.pp
Understanding the difference between a ``zone'' and a ``domain'' is crucial
to the proper operation of a name server. As an example, consider the
\s-1DEC.COM\s+1 \fIdomain\fP, which includes names such as
\s-1POBOX1.PA.DEC.COM\s+1 and \s-1QUABBIN.CRL.DEC.COM\s+1 even though
the \s-1DEC.COM\s+1 \fIzone\fP includes only \fIdelegations\fP for the
\s-1PA.DEC.COM\s+1 and \s-1CRL.DEC.COM\s+1 zones. A zone can map exactly
to a single domain, but could also include only part of a domain (the rest
of which could be delegated to other name servers). Technically speaking,
every name in the DNS tree is a ``domain'', even if it is ``terminal'', that
is, has no ``subdomains''. Technically speaking, every subdomain is a domain
and every domain except the root is also a subdomain. The terminology is not
intuitive and you would do well to read RFC's 1033, 1034, and 1035 to gain a
complete understanding of this difficult and subtle topic.
.pp
Though \s-1BIND\s+1 is a \fIDomain\fP Name Server, it deals primarily in terms
of \fIzones\fP. The \fIprimary\fP and \fIsecondary\fP declarations in the
\fInamed.boot\fP file specify \fIzones\fP, not \fIdomains\fP. When you ask
someone if they are willing to be a secondary server for your ``domain'', you
are actually asking for secondary service for some collection of \fIzones\fP.
.pp
Each zone will have one ``primary'' server, which loads the zone contents
from some local file which is edited by humans or perhaps generated
mechanically from some other local file which is edited by humans. Then
there will be some number of ``secondary'' servers, which load the zone
contents using the \s-1IP/DNS\s+1 protocol (that is, the secondary servers will
contact the primary and fetch the zone using \s-1IP/TCP\s+1). This set of
servers (the primary and all of the secondaries) should be listed in the
\fINS\fP records in the parent zone, which will constitute a ``delegation''.
This set of servers must also be listed in the zone file itself, usually
under the ``@'' name which is a magic cookie that means the ``top level''
or ``root'' of current zone. You can list servers in the zone's
top-level ``@'' \fINS\fP records that are not in the parent's \fINS\fP
delegation, but you cannot list servers in the parent's delegation that are
not present in the zone's ``@''. Any servers listed in the \fINS\fP records
must be configured as authoritative (either primary or secondary) for the
zone. If a server listed in a \fINS\fP record is not authoritative, it
will respond with a ``lame delegation'' when queried.
.sh 1 "Types of Servers"
.pp
Servers do not really have ``types''. A server can be a primary for some
zones and a secondary for others, or it can be only a primary, or only a
secondary, or it can serve no zones and just answer queries via its ``cache''.
Previous versions of this document referred to servers as ``master'' and
``slave'' but we now feel that those distinctions \(em and the assignment of
a ``type'' to a name server \(em are not useful.
.sh 2 "Caching Only Server"
.pp
All servers are caching servers. This means that the server caches the
information that it receives for use until the data expires. A \fICaching
Only Server\fP is a server that is not authoritative for any zone. This
server services queries and asks other servers, who have the authority, for
the information needed. All servers keep data in their cache until the data
expires, based on a \fITTL\fP (``Time To Live'') field which is maintained
for all resource records.
.sh 2 "Remote Server"
.pp
A Remote Server is an option given to people who would like to use
a name server from their workstation or on a machine that has a limited
amount of memory and CPU cycles.
With this option you can run all of the networking programs that use
the name server without the name server running on the local machine.
All of the queries are serviced by a name server that is running on another
machine on the network.
A host which has an
\fI/etc/resolv.conf\fP file listing only remote hosts, and which does not
run a name server of its own, is sometimes called a Remote Server (because
the actual server is remote?) but more
often it is called simply a DNS Client.
This kind of host is technically not a ``server'',
since it has no cache and does not answer queries.
.sh 2 "Slave Server"
.pp
A Slave Server is a server that always forwards queries it cannot
satisfy from its cache, to a fixed list of \fIforwarding\fP servers
instead of interacting
with the name servers for the root and other domains.
The queries to the \fIforwarding servers\fP are recursive queries.
There may be one or more forwarding servers, and they are tried in turn
until the list is exhausted.
A Slave and forwarder configuration is typically used when you do not
wish all the servers at a given site to interact with the rest
of the Internet servers. A typical scenario would involve a number of
workstations and a departmental timesharing machine with Internet
access. The workstations might be
administratively prohibited from having Internet access.
To give the workstations the appearance of access to the Internet
domain system, the workstations could be Slave servers to the timesharing
machine which would forward the queries and interact with other
name servers to resolve the query before returning the answer.
An added benefit of using the forwarding feature is that the central
machine develops a much more complete cache of information that
all the workstations can take advantage of. The use of Slave mode
and forwarding is discussed further under the description of
the \fInamed\fP bootfile commands.
.pp
There is no prohibition against declaring a server to be a \fIslave\fP
even though it has \fIprimary\fP and/or \fIsecondary\fP zones as well;
the effect will still be that anything in the local server's cache or
zones will be answered, and anything else will be forwarded using the
\fIforwarders\fP list.

118
usr.sbin/named/doc/bog/ucbhosts Normal file
View File

@ -0,0 +1,118 @@
.\" ++Copyright++ 1986, 1988
.\" -
.\" Copyright (c) 1986, 1988
.\" The Regents of the University of California. All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\" -
.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
.\"
.\" Permission to use, copy, modify, and distribute this software for any
.\" purpose with or without fee is hereby granted, provided that the above
.\" copyright notice and this permission notice appear in all copies, and that
.\" the name of Digital Equipment Corporation not be used in advertising or
.\" publicity pertaining to distribution of the document or software without
.\" specific, written prior permission.
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT
.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
.\" SOFTWARE.
.\" -
.\" --Copyright--
.\"
.\" @(#)ucbhosts 6.3 (Berkeley) 2/8/89
.\"
.\" .ne 48v
.\" .bp
.sh 3 "Hosts"
.(b L
;
; @(#)ucb-hosts 1.2 (berkeley) 88/02/05
;
.TS
l l l l l s.
@ IN SOA ucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP kjd\fB.\fPmonet\fB.\fPBerkeley\fB.\fPEdu\fB.\fP (
.T&
l l l l l.
1988020501 ; Serial
10800 ; Refresh
1800 ; Retry
3600000 ; Expire
259200 ) ; Minimum
.T&
l l l l s.
IN NS ucbarpa\fB.\fPBerkeley\fB.\fPEdu\fB.\fP
IN NS ucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP
localhost IN A 127\fB.\fP1
; note that 127.1 is the same as 127.0.0.1; see inet(3n)
ucbarpa IN A 128\fB.\fP32\fB.\fP4
IN A 10\fB.\fP0\fB.\fP0\fB.\fP78
IN HINFO VAX-11/780 UNIX
arpa IN CNAME ucbarpa
ernie IN A 128\fB.\fP32\fB.\fP6
IN HINFO VAX-11/780 UNIX
ucbernie IN CNAME ernie
monet IN A 128\fB.\fP32\fB.\fP7
IN A 128\fB.\fP32\fB.\fP130\fB.\fP6
IN HINFO VAX-11/750 UNIX
ucbmonet IN CNAME monet
ucbvax IN A 10\fB.\fP2\fB.\fP0\fB.\fP78
; 128.32.10 means 128.32.0.10; see inet(3n)
IN A 128\fB.\fP32\fB.\fP10
; HINFO and WKS are widely unused,
; but we'll show them as examples.
IN HINFO VAX-11/750 UNIX
IN WKS 128.32.0.10 TCP ( echo telnet
discard sunrpc sftp
uucp-path systat daytime
netstat qotd nntp
link chargen ftp
auth time whhois mtp
pop rje finger smtp
supdup hostnames
domain
nameserver )
vax IN CNAME ucbvax
toybox IN A 128\fB.\fP32\fB.\fP131\fB.\fP119
IN HINFO Pro350 RT11
toybox IN MX 0 monet.Berkeley.Edu.
csrg IN MX 0 Ralph.CS
IN MX 0 Zhou.CS
IN MX 0 Painter.CS
IN MX 0 Riggle.CS
IN MX 0 Terry.CS
IN MX 0 Kevin.CS
.TE
.)b
.\" .bp

86
usr.sbin/named/doc/bog/ucbhosts.rev Normal file
View File

@ -0,0 +1,86 @@
.\" ++Copyright++ 1986, 1988
.\" -
.\" Copyright (c) 1986, 1988
.\" The Regents of the University of California. All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\" -
.\" Portions Copyright (c) 1993 by Digital Equipment Corporation.
.\"
.\" Permission to use, copy, modify, and distribute this software for any
.\" purpose with or without fee is hereby granted, provided that the above
.\" copyright notice and this permission notice appear in all copies, and that
.\" the name of Digital Equipment Corporation not be used in advertising or
.\" publicity pertaining to distribution of the document or software without
.\" specific, written prior permission.
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT
.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
.\" SOFTWARE.
.\" -
.\" --Copyright--
.\"
.\" @(#)ucbhosts.rev 6.3 (Berkeley) 9/19/89
.\"
.ne 22v
.sh 3 "host.rev"
.(b L
;
; @(#)ucb-hosts.rev 1.1 (Berkeley) 86/02/05
;
.TS
l l l l l s.
@ IN SOA ucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP kjd\fB.\fPmonet\fB.\fPBerkeley\fB.\fPEdu\fB.\fP (
.T&
l l l l l.
1986020501 ; Serial
10800 ; Refresh
1800 ; Retry
3600000 ; Expire
259200 ) ; Minimum
.T&
l l l l s.
IN NS ucbarpa\fB.\fPBerkeley\fB.\fPEdu\fB.\fP
IN NS ucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP
0\fB.\fP0 IN PTR Berkeley-net\fB.\fPBerkeley\fB.\fPEDU\fB.\fP
IN A 255\fB.\fP255\fB.\fP255\fB.\fP0
0\fB.\fP130 IN PTR csdiv-net\fB.\fPBerkeley\fB.\fPEDU\fB.\fP
4\fB.\fP0 IN PTR ucbarpa\fB.\fPBerkeley\fB.\fPEdu\fB.\fP
6\fB.\fP0 IN PTR ernie\fB.\fPBerkeley\fB.\fPEdu\fB.\fP
7\fB.\fP0 IN PTR monet\fB.\fPBerkeley\fB.\fPEdu\fB.\fP
10\fB.\fP0 IN PTR ucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP
6\fB.\fP130 IN PTR monet\fB.\fPBerkeley\fB.\fPEdu\fB.\fP
.TE
.)b

109
usr.sbin/named/doc/i-d/draft-andrews-dns-ascii-02.txt Normal file
View File

@ -0,0 +1,109 @@
Mark Andrews
INTERNET DRAFT CSIRO
Expires: September 1996 May 1996
Updates RFC-1035
ASCII Encoding for Domain Names
draft-andrews-dns-ascii-02.txt
1. Status of This Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
Please check the 1id-abstracts.txt listing contained in the internet-
drafts Shadow Directories to learn the current status of any Internet
Draft.
2. Abstract
[RFC 1035 Section 5.1] describes how to encode domain names as
character strings. It however allows non printable characters to be
used. It also allows for encodings of text files which would not
survive intact ftp ASCII mode transfers, different end of line
conventions. This document addresses these problems by stating where
decimal escapes SHOULD be used.
While a applications MUST continue to read the full range as
expressed by [RFC 1035 5.1]. They SHOULD emit only this selected
subset.
3. Encoding
Octets within the follow ranges are encoded as backslash followed by
three decimal digits, 0x00 - 0x20, 0x7f - 0xff.
e.g.
0x00, \000
0x1f, \031
0xff, \255
Andrews [Page 1]
Internet Draft draft-andrews-dns-ascii-02.txt May 1996
Period (".") when NOT used as a domain separator is encoded as the
sequence backslash period, e.g. "\.". Un-escaped periods indicate
label separators.
Backslash ("\") is encoded as two consecutive backslashes, e.g. "\\".
Double quotes ('"') should always be represented as backslash quote
as a common nameserver implementation mis-parses strings containing
quotes, e.g. '\"'.
Semi-colon (";") should always be encoded as backslash semi-colon
otherwise it will be interpreted as a comment. e.g. "\;".
Space may be a literal space when the string is enclosed by double
quotes.
All other characters represent their literal ASCII encoding eighth
bit not set.
4. Security
This draft introduces no known security problems. It may however
remove some latent security problems in applications where the
encoding is NOT reversible leading to unexpected changes in domain
names.
4. References
[RFC-1035]
P. Mockapetris, ``DOMAIN NAMES - IMPLEMENTATION AND
SPECIFICATION'', RFC-1035, ISI, November 1987.
6. Author's Address
Mark Andrews
CSIRO
Division of Mathematics and Statistics
Locked Bag 17
North Ryde NSW 2113
AUSTRALIA
Mark.Andrews@dms.csiro.au [MA88]
Andrews [Page 2]

339
usr.sbin/named/doc/i-d/draft-andrews-dns-hostnames-02.txt Normal file
View File

@ -0,0 +1,339 @@
Mark Andrews
INTERNET DRAFT CSIRO
Expires: October 1996 April 1996
Clarification on the use of
Hostnames, Mail Boxes and Mail Domains in the DNS
draft-andrews-dns-hostnames-02.txt
1. Status of This Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
Please check the 1id-abstracts.txt listing contained in the internet-
drafts Shadow Directories to learn the current status of any Internet
Draft.
2. Abstract
At the protocol level, DNS domain names and records may contain
arbitrary binary data. However, many domain names and records are,
or refer to, hostnames, which are restricted by RFCs 952 and 1123 to
contain only certain characters. Similar restrictions apply to mail
domain names, RFC-821. This document identifies the types of domain
names and records which are hostnames / mail domain names, and
specifies the circumstances under which validation checks should be
performed within the class IN.
3. Scope
This document addresses restrictions that apply to records of class
IN. Similar restrictions may apply to other classes but no attempt
has been made to address them here.
"hostname" is an ASCII string as specified by [RFC-952] and modified
by [RFC-1123].
"mail domain name" is an ASCII string as specified by [RFC-821]. It
is syntactically identical to a hostname. While a broader definition
Andrews [Page 1]
Internet Draft draft-andrews-dns-hostnames-02.txt February 1996
is described in [RFC-822] only the subset described within [RFC-821]
will be allowed. [RFC-1123] does not explicitly change the syntax
for mail domain names, the changes to hostnames MUST flow through
indicating an implicit change. For the purposes of this document
hostname refers to either a hostname or a mail domain name.
"mailbox" is a ASCII string specified by [RFC-821] and mapped into
the DNS using the mapping specified by [RFC-1035] Section 8. The
first label represents the local part and the second and subsequent
labels MUST form a hostname / mail domain name. The local part is
restricted to printable ASCII (0x21 - 0x7e) plus single interior
SPACE (0x21), that is a SPACE MUST be surrounded by printable ASCII.
This definition is tighter than [RFC-821].
legal:
"abc def.foo.bar"
"ab cd ef.foo.bar"
illegal:
" abcdef.foo.bar"
"abcdef .foo.bar"
"abc def.foo.bar" (sequence of two spaces)
Field names are as described by [RFC-1035] unless otherwise noted.
The terms "SHOULD", "SHOULD NOT", "MUST" and "MUST NOT" are defined
in [RFC-1123] and specify the latitude developers may take.
4. Owner Name: Unconditional
The owner names of the following resource records MUST be hostnames:
A [RFC-1035]
WKS [RFC-1035]
MD [RFC-1035] (Obsolete)
MF [RFC-1035] (Obsolete)
MINFO [RFC-1035] MUST be a mailbox
MR [RFC-1035] MUST be a mailbox
MX [RFC-974]
AAAA [RFC-1886]
X25 [RFC-1183]
ISDN [RFC-1183]
RT [RFC-1183]
AFSDB [RFC-1183]
Records which do not conform MUST NOT be accepted or sent by
nameservers, and queries containing non-conforming names MUST NOT be
generated by library routines. Nameservers MUST return FORMERR to
these queries.
Andrews [Page 2]
Internet Draft draft-andrews-dns-hostnames-02.txt February 1996
If a query of type ANY is made, non-conforming records with the types
specified above MUST be discarded by library routines before the
results are returned to the application.
5. Owner Name: Conditional
The owner names of the following resource records MUST be hostnames
when the following conditions are met. Library routines must return
an error indication if passed a non-conforming name.
When looking up network numbers or subnet masks [RFC-1101] the lookup
name MUST be verified as conforming or an error indication MUST be
returned. That is, if the PTRDNAME field ends in IN-ADDR.ARPA [RFC-
1033] or IP6.INT [RFC-1886].
6. Hostnames in data fields: Unconditional
The following records contain entries in their data components that
MUST refer to hostnames. Nameservers MUST reject records which fail
to conform and MUST NOT forward non-conforming records. FORMERR MUST
be returned if non-conforming records are received.
SOA MNAME field MUST be a hostname.
SOA RNAME field. All but the first label MUST be a hostname.
MX EXCHANGE field MUST be a hostname.
NS NSDNAME field MUST be a hostname.
MB MADNAME field MUST be a hostname.
MD MADNAME field MUST be a hostname (Obsolete).
MF MADNAME field MUST be a hostname (Obsolete).
MG MGMNAME field MUST be a mailbox.
MINFO RMAILBX field MUST be a mailbox.
MINFO EMAILBX field MUST be a mailbox.
AFSDB <hostname> field [RFC-1183] MUST be a hostname.
RP <mbox-dname> field [RFC-1183] MUST be a mailbox.
Empty <mbox-dname> field, e.g. ".", need not be checked.
RT <intermediate-host> field [RFC-1183] MUST be a hostname.
If a query of type ANY is made, non-conforming records with the types
specified above MUST be discarded by library routines before the
results are returned to the application.
7. Hostnames in the data field: Conditional
The following resource record MAY contain hostnames in its data
fields. Library routines MUST ignore the resource record and indicate
an error to the calling routine.
PTR records in the IP6.INT [RFC-1886] and IN-ADDR.ARPA [RFC-1033]
Andrews [Page 3]
Internet Draft draft-andrews-dns-hostnames-02.txt February 1996
domains are used for mapping addresses into host and network names.
The data fields of PTR records in these two domains MUST be
hostnames. Records which do not conform MUST NOT be accepted or sent
by nameservers. FORMERR MUST be returned if received. In addition the
data fields of PTR records referred to by CNAMES within this space
MUST also conform [EIDNES]. Servers and libraries MUST ensure
conformance. REFUSED MUST be returned in this case.
When looking up address records, A or AAAA, the CNAME data field MUST
be checked for conformance and the query terminated if required.
REFUSED MUST be returned in this case.
8. Security Considerations
This document addresses security issues raised by the use of non-
conforming hostnames.
Some applications use hostnames as returned by the DNS without
checking their conformance. This has caused security problems in
those applications. This document addresses these problems by
requiring DNS resolvers and nameservers to enforce conformance, and
specifying exactly which parts of the DNS namespace are subject to
these restrictions.
This document is believed to introduce no additional security
problems to the current DNS protocol, except perhaps by lulling
application developers into a false sense of security by having DNS
servers and resolver libraries implement conformance checks that
applications should implement in any case. DNS servers and resolver
libraries may be out-of-date, or compromised by malicious users, and
no application should depend on them actually performing conformance
checks.
Requiring DNS servers and resolver libraries to perform the checks is
only an attempt to protect against faulty applications which fail to
perform these checks.
7. References
[RFC-821]
J. Postel, ``SIMPLE MAIL TRANSFER PROTOCOL'', USC/Information
Sciences Institute, August 1982.
[RFC-822]
D. Crocker, ``STANDARD FOR THE FORMAT ARPA INTERNET TEXT
MESSAGES'', University of Delaware, August 1982.
Andrews [Page 4]
Internet Draft draft-andrews-dns-hostnames-02.txt February 1996
[RFC-952]
K. Harrenstien, M. Stahl, E. Feinler, ``DoD Internet Host Table
Specification'', RFC-952, SRI, October 1985.
[RFC-974]
Craig Partridge, ``MAIL ROUTING AND THE DOMAIN SYSTEM'', RFC-974,
CSNET CIC BBN Laboratories Inc, January 1986
[RFC-1033]
M. Lottor, ``DOMAIN ADMINISTRATORS OPERATIONS GUIDE'', RFC-1033,
SRI International, November 1987
[RFC-1035]
P. Mockapetris, ``Domain Names - Implementation and
Specification'', RFC-1035, USC/Information Sciences Institute,
November 1987.
[RFC-1101]
P. Mockapetris, ``DNS Encoding of Network Names and Other Types'',
RFC-1101, ISI, April 1989
[RFC-1123]
Internet Engineering Task Force, R. Braden, Editor, ``Requirements
for Internet Hosts -- Application and Support'', RFC-1123, October
1989
[RFC-1183]
C. Everhart, L. Mamakos, R. Ullmann, P. Mockapetris, ``New DNS RR
Definitions'', RFC-1183, Transarc, University of Maryland, Prime
Computer, ISI, October 1990
[RFC-1886]
S. Thomson, C. Huitema, ``DNS Extensions to support IP version
6'', RFC-1886, Bellcore, INRIA, December 1995
[EIDNES]
WORK IN PROGRESS
Havard Eidnes, Geert Jan de Groot ``Classless in-addr.arpa
delegation'', draft-ietf-cidrd-classless-inaddr-00.txt, SINTEF
RUNIT, RIPE NCC, Jan 1996
8. Author's Address
Mark Andrews
CSIRO
Division of Mathematics and Statistics
Locked Bag 17
Andrews [Page 5]
Internet Draft draft-andrews-dns-hostnames-02.txt February 1996
North Ryde NSW 2113
AUSTRALIA
Mark.Andrews@dms.csiro.au [MA88]
Andrews [Page 6]

262
usr.sbin/named/doc/i-d/draft-andrews-dns-more-02.txt Normal file
View File

@ -0,0 +1,262 @@
Mark Andrews (CSIRO)
INTERNET-DRAFT Paul Vixie (ISC)
<draft-andrews-dns-more-02.txt> July 1996
Updates: RFC 1035
Large Responses to DNS Queries (DNS MORE)
Status of This Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other docu-
ments at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as ``work in
progress.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
DNS messages are limited to 64 kilobytes in size. At times it is
necessary to send a message that is greater that 64 kilobytes.
This is currently not possible. AXFR is the one exception. This
document describes how to send a sequence of messages, the total
length which may be greater than 64 kilobytes, by extending the
protocol.
In addition average message sizes are increasing and the 512
byte payload limit for UDP is now too small. This document
describes how servers can identify when they can send bigger
messages without necessarily resorting to TCP.
Expires January 1996 [Page 1]
INTERNET-DRAFT DNS MORE July 1996
1 - Protocol
This extension uses one of the RESERVED flags bits from DNS header
[RFC1035 4.1.1] to indicate when a server can send the extended
response. This flag bit shall be known as MORE.
The MORE flag's semantics depend upon the underlying transport protocol.
This document only defines the use of the MORE flag with the opcode
QUERY.
1.1 - TCP Usage
When using TCP a resolver sets the MORE flag to indicate that it is
capable of receiving a multi message response (which we call a ``message
sequence'').
To indicate that the message sequence is not complete the server shall
set the RCODE to CONTINUED (TBA) in all but the last message of the mes-
sage sequence.
The order of resource records in a multi message response MUST be the
same as if the response could have been sent is a single response. The
Questions first followed by, the Answer RRs, Authority RRs and Addi-
tional RRs.
Each message in a sequence will contain a header with the same ID value,
flags, opcode. Only the count fields and the rcode are permitted to
change. The counts shall represent the number of resource records in
this message. MORE MUST cleared in the response.
1.1.1 - TCP Example
The following example show how to send an answer with one question, 10
answer records, 14 authority records and 5 additional records. The
answer is split up across 3 messages.
MESSAGE 1: QCOUNT=1, ANCOUNT=10, AUCOUNT=0,
ADCOUNT=0, RCODE=CONTINUED
MESSAGE 2: QCOUNT=0, ANCOUNT=0, AUCOUNT=11,
ADCOUNT=0. RCODE=CONTINUED
MESSAGE 3: QCOUNT=0, ANCOUNT=0, AUCOUNT=3,
ADCOUNT=5, RCODE=NOERROR
Expires January 1996 [Page 2]
INTERNET-DRAFT DNS MORE July 1996
1.2 - UDP Usage
When using UDP, a resolver may set the MORE flag in a QUERY request to
indicate that its receive buffer is greater than 512 bytes in size,
rather than the 512 byte size given in [RFC1035 3.2.4]. The resolver is
expected to set this flag only if it knows that the host's reassembly
buffer is large enough to accommodate datagrams of the size indicated.
The new size is indicated by the RCODE is the query. The receive buffer
is 512 * (2 ^ RCODE) bytes in size.
RCODE SIZE
0 512
1 1024
2 2048
3 4096
4 8192
5 16384
6 32768
7 65536
8 131072
9 262144
10 524288
11 1048576
12 2097152
13 4194304
14 8388608
15 16777216
A server receiving a QUERY request with the MORE flag set is allowed to
transmit a response of up to the size indicated. If the response will
not fit in size indicated, then the rules given in [RFC1035 4.1.1,
4.2.1, 6.2] apply. If after taking section 1.2.1 into account the answer
section is still going to be truncated, the server should send a trun-
cated response in a 512 byte message. This is to remove the possibility
of IP reassembly errors causing the UDP response to be dropped.
The server MUST clear the MORE flag in the response.
The server SHOULD disable path MTU discovery on the UDP response packet
resulting in host fragmentation.
Expires January 1996 [Page 3]
INTERNET-DRAFT DNS MORE July 1996
1.2.1 - UDP Fragmentation
A server MAY take account of common MTU values [RFC1191 7.1] and if the
answer without additional and/or authority sections would fall below the
MTU and the message with the additional and/or authority sections would
be greater than the MTU value, it MAY wish to leave the whole section(s)
off rather than truncate within a section.
2 - Header Format
The header format is that described in [RFC1035 4.1.1] with the MORE
flag added:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA|MO| Z | RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Where MO is the MORE flag.
3 - Security Considerations
Though DNS is related to several security problems, no attempt is made
to fix them in this document.
This document is believed to introduce no additional security problems
to the current DNS protocol.
Expires January 1996 [Page 4]
INTERNET-DRAFT DNS MORE July 1996
References
[RFC1035]
P. Mockapetris, ``Domain Names - Implementation and Specifica-
tion,'' RFC 1035, USC/Information Sciences Institute, November
1987.
[RFC1191]
Mogul, J., and S. Deering, ``Path MTU Discovery'' RFC 1191,
DECWRL, Stanford University, November 1990.
Authors' Addresses
Mark Andrews
CSIRO - Division of Mathematics and Statistics
Locked Bag 17
North Ryde NSW 2113
AUSTRALIA
+61 2 325 3148
<Mark.Andrews@dms.csiro.au>
Paul Vixie
Internet Software Consortium
Star Route Box 159A
Woodside, CA 94062
USA
+1 415 747 0204
<paul@vix.com>
Expires January 1996 [Page 5]

670
usr.sbin/named/doc/i-d/draft-ietf-dnsind-2ndry-03.txt Normal file
View File

@ -0,0 +1,670 @@
Network Working Group Robert Elz
Internet Draft University of Melbourne
Expiration Date: February 1997
Randy Bush
RGnet, Inc.
Scott Bradner
Harvard University
Michael A. Patton
Bolt Beranek and Newman
August 1996
Selection and Operation of Secondary DNS Servers
draft-ietf-dnsind-2ndry-03.txt
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
The Domain Name System requires that multiple servers exist for every
delegated domain (zone). This document discusses the selection of
secondary servers for DNS zones. Both the physical and topological
location of each server are material considerations when selecting
secondary servers. The number of servers appropriate for a zone is
also discussed, and some general secondary server maintenance issues
considered.
kre, et al. [Page 1]
Internet Draft draft-ietf-dnsind-2ndry-03.txt August 1996
Contents
Status of this Memo ........................................ 1
Abstract ................................................... 1
1 Introduction ............................................... 2
2 Definitions ................................................ 2
3 Secondary Servers .......................................... 3
4 Unreachable servers ........................................ 5
5 How many secondaries? ...................................... 7
6 Finding Suitable Secondary Servers ......................... 8
7 Serial Number Maintenance .................................. 8
Security Considerations .................................... 10
References ................................................. 11
Acknowledgements ........................................... 11
Authors' Addresses ......................................... 11
1. Introduction
A number of problems in DNS operations today are attributable to poor
choices of secondary servers for DNS zones. The geographic placement
as well as the diversity of network connectivity exhibited by the set
of DNS servers for a zone can increase the reliability of that zone
as well as improve overall network performance and access
characteristics. Other considerations in server choice can
unexpectedly lower reliability or impose extra demands on the
network.
This document discusses many of the issues that should be considered
when selecting secondary servers for a zone. It offers guidance in
how to best choose servers to serve a given zone.
2. Definitions
For the purposes of this document, and only this document, the
following definitions apply:
DNS The Domain Name System [RFC1034, RFC1035].
Zone A part of the DNS tree, that is treated as a
unit.
Forward Zone A zone containing data mapping names to host
addresses, mail exchange targets, etc.
kre, et al. [Page 2]
Internet Draft draft-ietf-dnsind-2ndry-03.txt August 1996
Reverse Zone A zone containing data used to map addresses
to names.
Server An implementation of the DNS protocols able to
provide answers to queries. Answers may be
from information known by the server, or
information obtained from another server.
Authoritative Server A server that knows the content of a DNS zone
from local knowledge, and thus can answer
queries about that zone without needing to
query other servers.
Listed Server An Authoritative Server for which there is an
"NS" resource record (RR) in the zone.
Primary Server An authoritative server for which the zone
information is locally configured. Sometimes
known as a Master server.
Secondary Server An authoritative server that obtains
information about a zone from a Primary Server
via a zone transfer mechanism. Sometimes
known as a Slave Server.
Stealth Server An authoritative server, usually secondary,
which is not a Listed Server.
Resolver A client of the DNS which seeks information
contained in a zone using the DNS protocols.
3. Secondary Servers
A major reason for having multiple servers for each zone is to allow
information from the zone to be available widely and reliably to
clients throughout the Internet, that is, throughout the world, even
when one server is unavailable or unreachable.
Multiple servers also spread the name resolution load, and improve
the overall efficiency of the system by placing servers nearer to the
resolvers. Those purposes are not treated further here.
With multiple servers, usually one server will be the primary server,
and others will be secondary servers. Note that while some unusual
configurations use multiple primary servers, that can result in data
inconsistencies, and is not advisable.
kre, et al. [Page 3]
Internet Draft draft-ietf-dnsind-2ndry-03.txt August 1996
The distinction between primary and secondary servers is relevant
only to the servers for the zone concerned, to the rest of the DNS
there are simply multiple servers. All are treated equally at first
instance, even by the parent server that delegates the zone.
Resolvers often measure the performance of the various servers,
choose the "best", for some definition of best, and prefer that one
for most queries. That is automatic, and not considered here.
The primary server holds the master copy of the zone file. That is,
the server where the data is entered into the DNS from some source
outside the DNS. Secondary servers obtain data for the zone using
DNS protocol mechanisms to obtain the zone from the primary server.
3.1. Selecting Secondary Servers
When selecting secondary servers, attention should be given to the
various likely failure modes. Servers should be placed so that it is
likely that at least one server will be available to all significant
parts of the Internet, for any likely failure.
Consequently, placing all servers at the local site, while easy to
arrange, and easy to manage, is not a good policy. Should a single
link fail, or there be a site, or perhaps even building, or room,
power failure, such a configuration can lead to all servers being
disconnected from the Internet.
Secondary servers must be placed at both topologically and
geographically dispersed locations on the Internet, to minimise the
likelihood of a single failure disabling all of them.
That is, secondary servers should be at geographically distant
locations, so it is unlikely that events like power loss, etc, will
disrupt all of them simultaneously. They should also be connected to
the net via quite diverse paths. This means that the failure of any
one link, or of routing within some segment of the network (such as a
service provider) will not make all of the servers unreachable.
3.2. Unsuitable Configurations
While it is unfortunately quite common, servers for a zone should
certainly not all be placed on the same LAN segment in the same room
of the same building - or any of those. Such a configuration almost
defeats the requirement, and utility, of having multiple servers.
The only redundancy usually provided in that configuration is for the
case when one server is down, whereas there are many other possible
failure modes, such as power failures, including lengthy ones, to
consider.
kre, et al. [Page 4]
Internet Draft draft-ietf-dnsind-2ndry-03.txt August 1996
4. Unreachable servers
Another class of problems is caused by listing servers that cannot be
reached from large parts of the network. This could be listing the
name of a machine that is completely isolated behind a firewall, or
just a secondary address on a dual homed machine which is not
accessible from outside. The names of servers listed in NS records
should resolve to addresses which are reachable from the region to
which the NS records are being returned. Including addresses which
most of the network cannot reach does not add any reliability, and
causes several problems, which may, in the end, lower the reliability
of the zone.
First, the only way the resolvers can determine that these addresses
are, in fact, unreachable, is to try them. They then need to wait on
a lack of response timeout (or occasionally an ICMP error response)
to know that the address cannot be used. Further, even that is
generally indistinguishable from a simple packet loss, so the
sequence must be repeated, several times, to give any real evidence
of an unreachable server. All of this probing and timeout may take
sufficiently long that the original client program or user will
decide that no answer is available, leading to an apparent failure of
the zone. Additionally, the whole thing needs to be repeated from
time to time to distinguish a permanently unreachable server from a
temporarily unreachable one.
And finally, all these steps will potentially need to be done by
resolvers all over the network. This will increase the traffic, and
probably the load on the filters at whatever firewall is blocking
this access. All of this additional load does no more than
effectively lower the reliability of the service.
4.1. Servers behind intermittent connections
A similar problem occurs with DNS servers located in parts of the net
that are often disconnected from the Internet as a whole. For
example, those which connect via an intermittent connection that is
often down. Such servers should usually be treated as if they were
behind a firewall, and unreachable to the network at any time.
4.2. Other problem cases
Similar problems occur when a Network Address Translator (NAT)
[RFC1631] exists between a resolver and server. Despite what
[RFC1631] suggests, NATs in practice do not translate addresses
embedded in packets, only those in the headers. As [RFC1631]
suggests, this is somewhat of a problem for the DNS. This can
sometimes be overcome if the NAT is accompanied by, or replaced with,
kre, et al. [Page 5]
Internet Draft draft-ietf-dnsind-2ndry-03.txt August 1996
an Application Layer Gateway (ALG). Such a device would understand
the DNS protocol and translate all the addresses as appropriate as
packets pass through. Even with such a device, it is likely to be
better in any of these cases to adopt the solution described in the
following section.
4.3. A Solution
To avoid these problems, NS records for a zone returned in any
response should list only servers that the resolver requesting the
information, is likely to be able to reach. Some resolvers are
simultaneously servers performing lookups on behalf of other
resolvers. The NS records returned should be reachable not only by
the resolver that requested the information, but any other resolver
that may be forwarded the information. All the addresses of all the
servers returned must be reachable. As the addresses of each server
form a Resource Record Set [KRE1996b], all must be returned (or
none), thus it is not acceptable to elide addresses of servers that
are unreachable, or to return them with a low TTL (while returning
others with a higher TTL).
In particular, when some servers are behind a firewall, intermittent
connection, or NAT, which disallows, or has problems with, DNS
queries or responses, their names, or addresses, should not be
returned to clients outside the firewall. Similarly, servers outside
the firewall should not be made known to clients inside it, if the
clients would be unable to query those servers. Implementing this
usually requires dual DNS setups, one for internal use, the other for
external use. Such a setup often solves other problems with
environments like this.
When a server is at a firewall boundary, reachable from both sides,
but using different addresses, that server should be given two names,
each name associated with appropriate A records, such that each
appears to be reachable only on the appropriate side of the firewall.
This should then be treated just like two servers, one on each side
of the firewall. A server implemented in an ALG will usually be such
a case. Special care will need to be taken to allow such a server to
return the correct responses to clients on each side. That is,
return only information about hosts reachable from that side and the
correct IP address(es) for the host when viewed from that side.
Servers in this environment often need special provision to give them
access to the root servers. Often this is accomplished via "fake
root" configurations. In such a case the servers should be kept well
isolated from the rest of the DNS, lest their unusual configuration
pollute others.
kre, et al. [Page 6]
Internet Draft draft-ietf-dnsind-2ndry-03.txt August 1996
5. How many secondaries?
The DNS specification and domain name registration rules require at
least two servers for every zone. That is, usually, the primary and
one secondary. While two, carefully placed, are often sufficient,
occasions where two are insufficient are frequent enough that we
advise the use of more than two listed servers. Various problems can
cause a server to be unavailable for extended periods - during such a
period, a zone with only two listed servers is actually running with
just one. Since any server may occasionally be unavailable, for all
kinds of reasons, this zone is likely, at times, to have no
functional servers at all.
On the other hand, having large numbers of servers adds little
benefit, while adding costs. At the simplest, more servers cause
packets to be larger, so requiring more bandwidth. This may seem,
and realistically is, trivial. However there is a limit to the size
of a DNS packet, and causing that limit to be reached has more
serious performance implications. It is wise to stay well clear of
it. More servers also increase the likelihood that one server will
be misconfigured, or malfunction, without being detected.
It is recommended that three servers be provided for most
organisation level zones, with at least one which must be well
removed from the others. For zones where even higher reliability is
required, four, or even five, servers may be desirable. Two, or
occasionally three of five, would be at the local site, with the
others not geographically or topologically close to the site, or each
other.
Reverse zones, that is, sub-domains of .IN-ADDR.ARPA, tend to be less
crucial, and less servers, less distributed, will often suffice.
This is because address to name translations are typically needed
only when packets are being received from the address in question,
and only by resolvers at or near the destination of the packets.
This gives some assurances that servers located at or near the packet
source, for example, on the the same network, will be reachable from
the resolvers that need to perform the lookups. Thus some of the
failure modes that need to be considered when planning servers for
forward zones may be less relevant when reverse zones are being
planned.
kre, et al. [Page 7]
Internet Draft draft-ietf-dnsind-2ndry-03.txt August 1996
5.1. Stealth Servers
Servers which are authoritative for the zone, but not listed in NS
records (also known as "stealth" servers) are not included in the
count of servers.
It can often be useful for all servers at a site to be authoritative
(secondary), but only one or two be listed servers, the rest being
unlisted servers for all local zones, that is, to be stealth servers.
This allows those servers to provide answers to local queries
directly, without needing to consult another server. If it were
necessary to consult another server, it would usually be necessary
for the root servers to be consulted, in order to follow the
delegation tree - that the zone is local would not be known. This
would mean that some local queries may not be able to be answered if
external communications were disrupted.
Listing all such servers in NS records, if more than one or two,
would cause the rest of the Internet to spend unnecessary effort
attempting to contact all servers at the site when the whole site is
inaccessible due to link or routing failures.
6. Finding Suitable Secondary Servers
Operating a secondary server is usually an almost automatic task.
Once established, the server generally runs itself, based upon the
actions of the primary server. Because of this, large numbers of
organisations are willing to provide a secondary server, if
requested. The best approach is usually to find an organisation of
similar size, and agree to swap secondary zones - each organisation
agrees to provide a server to act as a secondary server for the other
organisation's zones. Note that there is no loss of confidential
data here, the data set exchanged would be available publically
whatever the servers are.
7. Serial Number Maintenance
Secondary servers use the serial number in the SOA record of the zone
to determine when it is necessary to update their local copy of the
zone. Serial numbers are basically just 32 bit unsigned integers
that wrap around from the biggest possible value to zero again. See
[KRE1996a] for a more rigorous definition of the serial number.
The serial number must be incremented every time a change, or group
of changes, is made to the zone on the primary server. This informs
secondary servers they need update their copies of the zone. Note
that it is not possible to decrement a serial number, increments are
kre, et al. [Page 8]
Internet Draft draft-ietf-dnsind-2ndry-03.txt August 1996
the only defined modification.
Occasionally due to editing errors, or other factors, it may be
necessary to cause a serial number to become smaller. Never simply
decrease the serial number. Secondary servers will ignore that
change, and further, will ignore any later increments until the
earlier large value is exceeded.
Instead, given that serial numbers wrap from large to small, in
absolute terms, increment the serial number, several times, until it
has reached the value desired. At each step, wait until all
secondary servers have updated to the new value before proceeding.
For example, assume that the serial number of a zone was 10, but has
accidentally been set to 1000, and it is desired to set it back to
11. Do not simply change the value from 1000 to 11. A secondary
server that has seen the 1000 value (and in practice, there is always
at least one) will ignore this change, and continue to use the
version of the zone with serial number 1000, until the primary
server's serial number exceeds that value. This may be a long time -
in fact, the secondary often expires its copy of the zone before the
zone is ever updated again.
Instead, for this example, set the primary's serial number to
2000000000, and wait for the secondary servers to update to that
zone. The value 2000000000 is chosen as a value a lot bigger than
the current value, but less that 2^31 bigger (2^31 is 2147483648).
This is then an increment of the serial number [KRE1996a].
Next, after all servers needing updating have the zone with that
serial number, the serial number can be set to 4000000000.
4000000000 is 2000000000 more than 2000000000 (fairly clearly), and
is thus another increment (the value added is less than 2^31).
Once this copy of the zone file exists at all servers, the serial
number can simply be set to 11. In serial number arithmetic, a
change from 4000000000 to 11 is an increment. Serial numbers wrap at
2^32 (4294967296), so 11 is identical to 4294967307
(4294967296 + 11). 4294967307 is just 294967307 greater than
4000000000, and 294967307 is well under 2^31, this is therefore an
increment.
When following this procedure, it is essential to verify that all
relevant servers have been updated at each step, never assume
anything. Failing to do this can result in a worse mess than existed
before the attempted correction. Also beware that it is the
relationship between the values of the various serial numbers that is
important, not the absolute values. The values used above are
kre, et al. [Page 9]
Internet Draft draft-ietf-dnsind-2ndry-03.txt August 1996
correct for that one example only.
It is possible in essentially all cases to correct the serial number
in two steps by being more aggressive in the choices of the serial
numbers. This however causes the numbers used to be less "nice", and
requires considerably more care.
Also, note that not all nameserver implementations correctly
implement serial number operations. With such servers as secondaries
there is typically no way to cause the serial number to become
smaller, other than contacting the administrator of the server and
requesting that all existing data for the zone be purged. Then that
the secondary be loaded again from the primary, as if for the first
time.
It remains safe to carry out the above procedure, as the
malfunctioning servers will need manual attention in any case. After
the sequence of serial number changes described above, conforming
secondary servers will have been reset. Then when the primary server
has the correct (desired) serial number, contact the remaining
secondary servers and request their understanding of the correct
serial number be manually corrected. Perhaps also suggest that they
upgrade their software to a standards conforming implementation.
A server which does not implement this algorithm is defective, and
may be detected as follows. At some stage, usually when the absolute
integral value of the serial number becomes smaller, a server with
this particular defect will ignore the change. Servers with this
type of defect can be detected by waiting for at least the time
specified in the SOA refresh field and then sending a query for the
SOA. Servers with this defect will still have the old serial number.
We are not aware of other means to detect this defect.
Security Considerations
This document does not consider security.
The mention of firewalls in section 4 is purely because they are a
fact of life (and an impediment to orderly communications). It is
not intended to imply that a firewall is in any way useful for
security purposes.
It is not believed that anything in this document adds to any
security issues that may exist with the DNS, nor does it do anything
to lessen them.
kre, et al. [Page 10]
Internet Draft draft-ietf-dnsind-2ndry-03.txt August 1996
References
[RFC1034] Domain Names - Concepts and Facilities,
P. Mockapetris, ISI, November 1987.
[RFC1035] Domain Names - Implementation and Specification,
P. Mockapetris, ISI, November 1987
[RFC1631] The IP Network Address Translator (NAT),
K. Egevang, Cray Communications, P. Francis, NTT, May 1994
[KRE1996a] Serial Number Arithmetic,
R. Elz, R. Bush,
Work in Progress (RFC pending), April 1996.
[KRE1996b] Clarifications to the DNS specification,
R. Elz, R. Bush,
Work In Progress (internet-draft), May 1996.
Acknowledgements
Brian Carpenter and Yakov Rekhter suggested mentioning NATs and ALGs
as a companion to the firewall text.
Authors' Addresses
Robert Elz
Computer Science
University of Melbourne
Parkville, Vic, 3052
Australia.
EMail: kre@munnari.OZ.AU
Randy Bush
RGnet, Inc.
10361 NE Sasquatch Lane
Bainbridge Island, Washington, 98110
United States.
EMail: randy@psg.com
kre, et al. [Page 11]
Internet Draft draft-ietf-dnsind-2ndry-03.txt August 1996
Scott Bradner
Harvard University
1350 Mass Ave
Cambridge, MA, 02138
United States.
EMail: sob@harvard.edu
Michael A. Patton
Bolt Beranek and Newman
10 Moulton Street
Cambridge, MA, 02138
United States.
EMail: MAP@BBN.COM
kre, et al. [Page 12]

334
usr.sbin/named/doc/i-d/draft-ietf-dnsind-clarify-01.txt Normal file
View File

@ -0,0 +1,334 @@
Network Working Group Robert Elz
Internet Draft University of Melbourne
Expiration Date: November 1996
Randy Bush
RGnet, Inc.
May 1996
Clarifications to the DNS Specification
draft-ietf-dnsind-clarify-01.txt
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
1. Abstract
This draft considers some areas that have been identified as problems
with the specification of the Domain Name System, and proposes
remedies for the defects identified. Two separate issues are
considered, IP packet header address usage from multi-homed servers,
and TTLs in sets of records with the same name, class, and type.
kre/randy [Page 1]
Internet Draft draft-ietf-dnsind-clarify-01.txt May 1996
2. Introduction
Several problem areas in the Domain Name System specification
[RFC1034, RFC1035] have been noted through the years [RFC1123]. This
draft addresses two additional problem areas. The two issues here
are independent. Those issues are the question of which source
address a multi-homed DNS server should use when replying to a query,
and the issue of differing TTLs for DNS records with the same label,
class and type.
Suggestions for clarifications to the DNS specification to avoid
these problems are made in this memo. The solutions proposed herein
are intended to stimulate discussion. It is possible that the sense
of either may be reversed before the next iteration of this draft,
but less likely now than it was before the previous version.
3. Server Reply Source Address Selection
Most, if not all, DNS clients, whether servers acting as clients for
the purposes of recursive query resolution, or resolvers, expect the
address from which a reply is received to be the same address as that
to which the query eliciting the reply was sent. This, along with
the identifier (ID) in the reply is used for disambiguating replies,
and filtering spurious responses. This may, or may not, have been
intended when the DNS was designed, but is now a fact of life.
Some multi-homed hosts running DNS servers fail to anticipate this
usage, and consequently send replies from the "wrong" source address,
causing the reply to be discarded by the client.
3.1. UDP Source Address Selection
To avoid these problems, servers when responding to queries using UDP
must cause the reply to be sent with the source address field in the
IP header set to the address that was in the destination address
field of the IP header of the packet containing the query causing the
response. If this would cause the response to be sent from an IP
address which is not permitted for this purpose, then the response
may be sent from any legal IP address allocated to the server. That
address should be chosen to maximise the possibility that the client
will be able to use it for further queries. Servers configured in
such a way that not all their addresses are equally reachable from
all potential clients need take particular care when responding to
queries sent to anycast, multicast, or similar, addresses.
kre/randy [Page 2]
Internet Draft draft-ietf-dnsind-clarify-01.txt May 1996
3.2. Port Number Selection
Replies to all queries must be directed to the port from which they
were sent. With queries received via TCP this is an inherent part of
the transport protocol, for queries received by UDP the server must
take note of the source port and use that as the destination port in
the response. Replies should always be sent from the port to which
they were directed. Except in extraordinary circumstances, this will
be the well known port assigned for DNS queries [RFC1700].
4. Resource Record Sets
Each DNS Resource Record (RR) each has a label, class, type, and
data. While it is meaningless for two records to ever have label,
class, type and data all equal (servers should suppress such
duplicates if encountered), it is possible for many record types to
exist with the same label class and type, but with different data.
Such a group of records is hereby defined to be a Resource Record Set
(RRSet).
4.1. Sending RRs from an RRSet
A query for a specific (or non-specific) label, class, and type, will
always return all records in the associated RRSet - whether that be
one or more RRs, or the response shall be marked as "truncated" if
the entire RRSet will not fit in the response.
4.2. TTLs of RRs in an RRSet
Resource Records also have a time to live (TTL). It is possible for
the RRs in an RRSet to have different TTLs, however no uses for this
have been found which cannot be better accomplished in other ways.
This can, however, cause partial replies (not marked "truncated")
from a caching server, where the TTLs for some but not all of the RRs
in the RRSet have expired.
Consequently the use of differing TTLs in an RRSet is hereby
deprecated, the TTLs of all RRs in an RRSet must be the same.
Should a client receive a response containing RRs from an RRSet with
differing TTLs, it should treat the RRs for all purposes as if all
TTLs in the RRSet had been set to the value of the lowest TTL in the
RRSet.
kre/randy [Page 3]
Internet Draft draft-ietf-dnsind-clarify-01.txt May 1996
4.3. Receiving RRSets
Servers never merge RRs from a response with RRs in their cache to
form an RRSet. If a response contains data which would form an RRSet
with data in a server's cache the server must either ignore the RRs
in the response, or use those to replace the existing RRSet in the
cache, as appropriate. Consequently the issue of TTLs varying
between the cache and a response does not cause concern, one will be
ignored.
4.3.1. Ranking data
When considering whether to accept an RRSet in a reply, or retain an
RRSet already in its cache instead, a server should consider the
relative likely trustworthiness of the various data. That is, an
authoritative answer from a reply should replace cached data that had
been obtained from additional information in an earlier reply, but
additional information from a reply will be ignored if the cache
contains data from an authoritative answer or a zone file.
The accuracy of data available is assumed from its source.
Trustworthiness shall be, in order from most to least:
+ Data from a primary zone file, other than glue data,
+ Data from a zone transfer, other than glue,
+ That from the answer section of an authoritative reply,
+ Glue from a primary zone, or glue from a zone transfer,
+ Data from the authority section of an authoritative answer,
+ Data from the answer section of a non-authoritative answer,
+ Additional information from an authoritative answer,
+ Data from the authority section of a non-authoritative answer,
+ Additional information from non-authoritative answers.
Where authenticated data has been received it shall be considered
more trustworthy than unauthenticated data of the same type.
"Glue" above includes any record in a zone file that is not properly
part of that zone, including nameserver records of delegated sub-
zones (NS records), address records that accompany those NS records
(A, AAAA, etc), and any other stray data that might appear.
4.4. Sending RRSets (reprise)
A Resource Record Set should only be included once in any DNS reply.
It may occur in any of the Answer, Authority, or Additional
Information sections, as required, however should not be repeated in
the same, or any other, section, except where explicitly required by
a specification. For example, an AXFR response requires the SOA
kre/randy [Page 4]
Internet Draft draft-ietf-dnsind-clarify-01.txt May 1996
record (always an RRSet containing a single RR) be both the first and
last record of the reply. Where duplicates are required this way,
the TTL transmitted in each case must be the same.
5. Security Considerations
This document does not consider security.
In particular, nothing in section 3 is any way related to, or useful
for, any security related purposes.
Section 4.3.1 is also not related to security. Security of DNS data
will be obtained by the Secure DNS [DNSSEC], which is orthogonal to
this memo.
It is not believed that anything in this document adds to any
security issues that may exist with the DNS, nor does it do anything
to lessen them.
6. References
[RFC1034] Domain Names - Concepts and Facilities, (STD 13)
P. Mockapetris, ISI, November 1987.
[RFC1035] Domain Names - Implementation and Specification (STD 13)
P. Mockapetris, ISI, November 1987
[RFC1123] Requirements for Internet hosts - application and support,
(STD 3) R. Braden, January 1989
[RFC1700] Assigned Numbers (STD 2)
J. Reynolds, J. Postel, October 1994.
[DNSSEC] Domain Name System Security Extensions,
D. E. Eastlake, 3rd, C. W. Kaufman,
Work in Progress (Internet Draft), January 1996.
7. Acknowledgements
This memo arose from discussions in the DNSIND working group of the
IETF in 1995 and 1996, the members of that working group are largely
responsible for the ideas captured herein.
kre/randy [Page 5]
Internet Draft draft-ietf-dnsind-clarify-01.txt May 1996
8. Authors' addresses
Robert Elz
Computer Science
University of Melbourne
Parkville, Victoria, 3052
Australia.
EMail: kre@munnari.OZ.AU
Randy Bush
RGnet, Inc.
9501 SW Westhaven
Portland, Oregon, 97225
United States.
EMail: randy@psg.com
kre/randy [Page 6]

476
usr.sbin/named/doc/i-d/draft-ietf-dnsind-defupd-00.txt Normal file
View File

@ -0,0 +1,476 @@
DNSIND Working Group Paul Vixie (ISC)
INTERNET-DRAFT May 1996
<draft-ietf-dnsind-defupd-00.txt>
Amends: RFC 1035, [UPDATE]
Deferred Dynamic Updates in the Domain Name System (DNS DEFUPD)
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
Not all applications that perform dynamic updates using the protocol
specified in [UPDATE] want their updates applied immediately. A case
in point is [DHCP], wherein the DHCP lease time should control the
lifetime of associated DNS data even if the DHCP client or server is
not available at the time the DHCP lease expires.
The essence of this proposal is that DNS Dynamic Updates should be
deferrable for some time delay period, after which they will be
executed normally. Furthermore, RRs added or updated by a deferred
update can have expiration times specified for them, as enforced by
the automatic Dynamic Updates. Automatic serial number changes (as
in [UPDATE]), dynamic zone slave notification (see [NOTIFY]) and
incremental zone transfer (see [IXFR]) will jointly see to it that
the zone changes are propagated with expedience.
Expires November 1996 [Page 1]
INTERNET-DRAFT DNS DEFUPD May 1996
1 - New Assigned Numbers
Opcode: DEFUPD (6?)
RRtype: TUU (34?)
RRtype: TUE (35?)
2 - Message Format
The format and encoding of a DEFUPD is identical to that of UPDATE as
defined in [UPDATE 2], except that the Opcode is DEFUPD rather than
UPDATE, and there are two new RR types that can be used in the
Additional Data section.
2.1 - Additional Data Section: TUU RR
In addition to the optional uses described in [UPDATE 2.6], a DEFUPD
request's Additional Data section can include a TUU (Time Until Update)
RR as follows:
Owner: same as ZNAME (see [UPDATE 2.3])
Class: same as ZCLASS (see [UPDATE 2.3])
Type: TUU (new RRtype for this protocol)
TTL: deferral time, relative, in seconds
RDLENGTH: 0
RDATA: empty
Of particular note is the TTL, which contains the relative time delay,
in seconds, starting from the time this DEFUPD is received by the
primary master, before operations contained in the Update Section (see
[UPDATE 2.5]) will actually be performed.
Expires November 1996 [Page 2]
INTERNET-DRAFT DNS DEFUPD May 1996
2.2 - Additional Data Section: TUE RR
In addition to the optional uses described in [UPDATE 2.6], a DEFUPD
request's Additional Data section can include a TUU (Time Until Expiry)
RR as follows:
Owner: same as ZNAME (see [UPDATE 2.3])
Class: same as ZCLASS (see [UPDATE 2.3])
Type: TUE (new RRtype for this protocol)
TTL: expiry time, relative, in seconds
RDLENGTH: 0
RDATA: empty
Of particular note is the TTL, which contains the expiration time delay,
in seconds, starting from the time this DEFUPD is received by the
primary master, of all RRs added or updated by operations in the Update
Section (see [UPDATE 2.5]).
3 - Server Behavior
A server, upon receiving a DEFUPD request, will first scan the request's
Additional Data section in search of TUU or TUE RRs. If no RRs of
either type TUU or TUE are found, then this request will be processed as
a normal UPDATE with no special behaviour. If any TUU or TUE RRs are
found, then processing continues as follows.
3.1 - Verify TUU RR
If any TUU RRs are found in the Additional Data section, this update
will be processed with Deferral as explained below. If more than one
TUU RR is found, signal FORMERR to requestor. The TUU RR's owner name
and class are compared to ZNAME and ZCLASS; if a mismatch occurs, signal
FORMERR to requestor. The TUU RR's RDLENGTH/RDATA is ignored by
implementations of this specification, but future specifications may
make use of this field.
3.2 - Verify TUE RR
If any TUE RRs are found in the Additional Data section, this update
will be processed with Expiry as explained below. If more than one TUE
RR is found, signal FORMERR to requestor. The TUE RR's owner name and
class are compared to ZNAME and ZCLASS; if a mismatch occurs, signal
FORMERR to requestor. The TUE RR's RDLENGTH/RDATA is ignored by
implementations of this specification, but future specifications may
make use of this field.
Expires November 1996 [Page 3]
INTERNET-DRAFT DNS DEFUPD May 1996
3.3 - Deferral
If a TUU RR was specified in the Additional Data section, this update
will be processed with Deferral. Deferral means that the update will
not be applied synchronously to the requestor's transaction cycle, but
instead will be applied asynchronously at some potentially later time.
The delay period is measured in seconds and expressed in the TUU's TTL.
3.3.1 - Store Deferred Update
Subject to per-server, per-zone, and per-RRset quotas, this UPDATE
message is stored, persistently, on the name server. If per-RRset
quotas are implemented, it is recommended that a DEFUPD ``count
against'' all RRsets mentioned in the Update Section. If an
implementation defined quota is exceeded by this deferred update, or if
persistent storage is unavailable, signal SERVFAIL to requestor (leaving
the zone in its former state). Note that even a deferred update whose
TUU's TTL is zero (0), specifying immediate application, should be
subject to quotas if the name server implements quotas.
3.3.2 - Send Early Response
Signal NOERROR to requestor.
3.3.3 - Apply Deferred Update
When a period of time equal to or greater than the TUU's TTL (measured
in seconds) has elapsed since a DEFUPD was first received at the primary
master, the DEFUPD message is applied to the zone as an UPDATE would be,
except that no error can be signalled to the requestor. Thus, all
errors not found and reported at the time the DEFUPD request was
received are silent, affecting only the continued processing of the
deferred update. Note that all sections are processed, including those
processed before the deferred update were stored. Thus, prerequisites
must hold before and after the deferral period.
Expires November 1996 [Page 4]
INTERNET-DRAFT DNS DEFUPD May 1996
3.4 - Expiry Processing
When a DEFUPD is applied, either during the requestor's transaction
cycle or following the optional Deferral period, the inclusion of a TUE
RR in the Additional Data section will cause this update to be processed
with Expiry.
Expiry as expressed in the TUE's TTL is the time, in seconds, before all
RRs added or modified by the Update Section will be automatically
deleted by the primary master server. This time is relative to the time
the DEFUPD message is processed, which might be after the delay period
specified by a TUU RR.
3.4.1 - Initial TTL Limits
The TTL of all added or updated RRs in the Update Section will be
maximized silently to one half of the Expiry time. This will cause
downstream caching name servers to purge RRsets containing this RR at
least once before expiry.
3.4.2 - TTL Half Life
Each time an RR's expiry reaches half of its previous value, that RR's
TTL will be reduced to half of its previous value, until the TTL reaches
a value less than or equal to sixty (60), i.e., one minute of real time,
at which time the TTL will not be automatically reduced further by the
primary master. It should be noted that RRs held in a server's memory
need not be swept for half life processing, as long as the TTL changes
appear when the RR next becomes externally visible, and as long as the
``zone has changed'' processing (see below) is done at the time of the
half life expiration.
Whenever the TTL is automatically reduced by this process, the zone will
be considered ``changed'' for the purpose of automatic SOA SERIAL
increment (see [UPDATE 3.6]) and real time zone slave notification (see
[NOTIFY]).
Expires November 1996 [Page 5]
INTERNET-DRAFT DNS DEFUPD May 1996
3.4.3 - Automatic Deletion
When the time since an RR was added or updated by a DEFUPD with Expiry
exceeds the TUE's TTL as specified in that update, all RRs added or
updated by that DEFUPD's Update Section will be automatically deleted by
the primary master. This deletion can be deferred until the deleted RRs
would next become visible, so long as the ``zone has changed''
processing (see below) is done at the time of expiration (i.e., when the
automatic deletion is first deferred.)
Whenever automatic deletion occurs, the zone will be considered
``changed'' for the purpose of automatic SOA SERIAL increment (see
[UPDATE 3.6]) and real time zone slave notification (see [NOTIFY]).
3.5 - Requirements for Persistence
Stored deferred updates should persist across name server restarts.
3.5.1 - Restarts and Deferral
In the event of a name server restart, all deferred updates whose TUU
has expired must take effect before any network requests are processed
using data from the affected zone, and before any Expiry processing
takes place on RRs in the affected zone.
3.5.2 - Restarts and Expiry
In the event of a name server restart, all expiries must be checked as
of the current time before any network responses are generated using
data from the affected zone.
If an RR's expiry time has been reached while the name server was not
running, that RR will be deleted. Otherwise, the RR's TTL will be set
to one half of the time remaining before expiration, and half life
processing as specified in Section 3.4.2 will be restarted.
If any RR is deleted or if an RR's TTL is changed during startup, then
the zone will be considered ``changed'' for the purpose of automatic SOA
SERIAL increment (see [UPDATE 3.6]) and real time zone slave
notification (see [NOTIFY]).
Expires November 1996 [Page 6]
INTERNET-DRAFT DNS DEFUPD May 1996
4 - Requestor Behaviour
A requestor will generate and transmit a DEFUPD request as specified in
[UPDATE 4], except that TUU and TUE RRs can be included in the
Additional Data section.
4.1. The TUU RR, if specified, must have an owner name and class equal
to the ZNAME and ZCLASS (see [UPDATE 2.3]). The TTL should be set to
the delay, measured in seconds, before this update should be processed
by the primary master. RDLENGTH should be set to 0, and RDATA should
therefore be empty.
4.2. The TUE RR, if specified, must have an owner name and class equal
to the ZNAME and ZCLASS (see [UPDATE 2.3]). The TTL should be set to
the delay, measured in seconds, before all RRs added or changed by the
Update Section will be automatically deleted by the primary master.
This delay is measured starting from the time the update is applied,
which could follow a deferral delay if a TUU RR was also included in
this update.
5 - Notes on Resource Consumption
A TUE RR will require the primary master will initiate an automatic
update approximately O(log2(TTL)) times over the life of an expiring RR.
Even for massively sized zones, this is not considered an inappropriate
load on the primary master server itself.
The network bandwidth consumed due to the use of TUE RRs is more
noticeable, although for massively sized zones, the bandwidth
requirements should flatten somewhat as many RRs will be automatically
updated during any given cycle of NOTIFY and AXFR/IXFR.
6 - Security Considerations
This protocol suffers the same abject and intentional lack of security
as [UPDATE], from which it inherits its basic semantics. In the absence
of DNS Secure Updates, this protocol should not be used outside of an
enterprise network, and only with great care within an enterprise
network.
Expires November 1996 [Page 7]
INTERNET-DRAFT DNS DEFUPD May 1996
7 - Discussion Items for DNSIND and Namedroppers
Should the server's response to a DEFUPD include an opaque cookie called
a ``deferred update ID'' which could be used in future DEFUPD requests
to cancel or replace a previous deferred update?
Should automatic updates caused by a TUE RR be required to be batched up
and processed at some minimum interval? For example, if we only checked
for half life and expiration once per minute, this might drastically
reduce the number of NOTIFY/AXFR/IXFR cycles caused by any given zone.
We would have to recommend that all zones in a given server not be
synchronized to the same timer, lest a server with many zones cause all
of its zones to change and require NOTIFY/AXFR/IXFR in the same second.
Astute readers will have noticed that this proposal is a precise
superset of [UPDATE], and by adding the optional behaviour and
definitions of TUU and TUE to [UPDATE], we could do away with the
separate Opcode for DEFUPD. This was only possible up until the time
[UPDATE] went to proposed standard, but hopefully the intent was clear.
8 - References
[RFC1035]
P. Mockapetris, ``Domain Names - Implementation and Specification,''
RFC 1035, USC/Information Sciences Institute, November 1987.
[IXFR]
M. Ohta, ``Incremental Zone Transfer,'' Internet Draft, February
1996, <draft-ietf-dnsind-ixfr-06.txt>.
[NOTIFY]
P. Vixie, ``A Mechanism for Prompt Notification of Zone Changes,''
Internet Draft, March 1996, <draft-ietf-dnsind-notify-07.txt>.
[UPDATE]
P. Vixie (Ed), et al, ``Dynamic Updates in the Domain Name System,''
Internet Draft, March 1996, <draft-ietf-dnsind-dynDNS-09.txt>.
[DHCP]
Y. Rechter, ``Interaction between DHCP and DNS,'' Internet Draft,
February 1996, <draft-ietf-dhc-dhcp-dns-00.txt>.
Expires November 1996 [Page 8]
INTERNET-DRAFT DNS DEFUPD May 1996
9 - Acknowledgements
Yakov Rechter assisted in the design of this protocol. Robert Elz
assisted in the requirements definition.
10 - Author's Addresses
Paul Vixie
Internet Software Consortium
Star Route Box 159A
Woodside, CA 94062
+1 415 747 0204
<paul@vix.com>
Expires November 1996 [Page 9]

1482
usr.sbin/named/doc/i-d/draft-ietf-dnsind-dynDNS-09.txt Normal file
View File

File diff suppressed because it is too large Load Diff

391
usr.sbin/named/doc/i-d/draft-ietf-dnsind-ixfr-07.txt Normal file
View File

@ -0,0 +1,391 @@
INTERNET DRAFT M. Ohta
draft-ietf-dnsind-ixfr-07.txt Tokyo Institute of Technology
June 1996
Incremental Zone Transfer in DNS
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This document proposes extensions to the DNS protocols to provide an
incremental zone transfer (IXFR) mechanism.
1. Introduction
For rapid propagation of changes to a DNS database [STD13], it is
necessary to reduce latency by actively notifying servers of the
change. This is accomplished by the NOTIFY extension of the DNS
[NOTIFY].
The current full zone transfer mechanism (AXFR) is not an efficient
means to propagate changes to a small part of a zone, as it transfers
the entire zone file.
Incremental transfer (IXFR) as proposed is a more efficient
mechanism, as it transfers only the changed portion(s) of a zone.
In this document, a secondary name server which requests IXFR is
called an IXFR client and a primary or secondary name server which
responds to the request is called an IXFR server.
2. Brief Description of the Protocol
M. Ohta Expires on December 6, 1996 [Page 1]
INTERNET DRAFT Incremental Zone Transfer in DNS June 1996
If an IXFR client, which likely has an older version of a zone,
thinks it needs new information about the zone (typically through SOA
refresh timeout or the NOTIFY mechanism), it sends an IXFR message
containing the SOA serial number of its, presumably outdated, copy of
the zone.
An IXFR server should keep record of the newest version of the zone
and the differences between that copy and several older versions.
When an IXFR request with an older version number is received, the
IXFR server needs to send only the differences required to make that
version current. Alternatively, the server may choose to transfer
the entire zone just as in a normal full zone transfer.
When a zone has been updated, it should be saved in stable storage
before the new version is used to respond to IXFR (or AXFR) queries.
Otherwise, if the server crashes, data which is no longer available
may have been distributed to secondary servers, which can cause
persistent database inconsistencies.
If an IXFR query with the same or newer version number than that of
the server is received, it is replied to with a single SOA record of
the server's current version, just as in AXFR.
Transport of a query may be by either UDP or TCP. If an IXFR query
is via UDP, the IXFR server may attempt to reply using UDP if the
entire response can be contained in a single DNS packet. If the UDP
reply does not fit, the query is responded to with a single SOA
record of the server's current version to inform the client that a
TCP query should be initiated.
Thus, a client should first make an IXFR query using UDP. If the
query type is not recognized by the server, an AXFR (preceded by a
UDP SOA query) should be tried, ensuring backward compatibility. If
the query response is a single packet with the entire new zone, or if
the server does not have a newer version than the client, everything
is done. Otherwise, a TCP IXFR query should be tried.
To ensure integrity, servers should use UDP checksums for all UDP
responses. A cautious client which receives a UDP packet with a
checksum value of zero should ignore the result and try a TCP IXFR
instead.
The query type value of IXFR assigned by IANA is 251.
3. Query Format
The IXFR query packet format is the same as that of a normal DNS
query, but with the query type being IXFR and the authority section
M. Ohta Expires on December 6, 1996 [Page 2]
INTERNET DRAFT Incremental Zone Transfer in DNS June 1996
containing the SOA record of client's version of the zone.
4. Response Format
If incremental zone transfer is not available, the entire zone is
returned. The first and the last RR of the response is the SOA
record of the zone. I.e. the behavior is the same as an AXFR
response except the query type is IXFR.
If incremental zone transfer is available, one or more difference
sequences is returned. The list of difference sequences is preceded
and followed by a copy of the server's current version of the SOA.
Each difference sequence represents one update to the zone (one SOA
serial change) consisting of deleted RRs and added RRs. The first RR
of the deleted RRs is the older SOA RR and the first RR of the added
RRs is the newer SOA RR.
Modification of an RR is performed first by removing the original RR
and then adding the modified one.
The sequences of differential information are ordered oldest first
newest last. Thus, the differential sequences are the history of
changes made since the version known by the IXFR client up to the
server's current version.
RRs in the incremental transfer messages may be partial. That is, if
a single RR of multiple RRs of the same RR type changes, only the
changed RR is transferred.
An IXFR client, should only replace an older version with a newer
version after all the differences have been successfully processed.
An incremental response is different from that of a non-incremental
response in that it begins with two SOA RRs, the server's current SOA
followed by the SOA of the client's version which is about to be
replaced.
5. Purging Strategy
An IXFR server can not be required to hold all previous versions
forever and may delete them anytime. In general, there is a trade-off
between the size of storage space and the possibility of using IXFR.
Information about older versions should be purged if the total length
of an IXFR response would be longer than that of an AXFR response.
Given that the purpose of IXFR is to reduce AXFR overhead, this
strategy is quite reasonable. The strategy assures that the amount
M. Ohta Expires on December 6, 1996 [Page 3]
INTERNET DRAFT Incremental Zone Transfer in DNS June 1996
of storage required is at most twice that of the current zone
information.
Information older than the SOA expire period may also be purged.
6. Optional Condensation of Multiple Versions
An IXFR server may optionally condense multiple difference sequences
into a single difference sequence, thus, dropping information on
intermediate versions.
This may be beneficial if a lot of versions, not all of which are
useful, are generated. For example, if multiple ftp servers share a
single DNS name and the IP address associated with the name is
changed once a minute to balance load between the ftp servers, it is
not so important to keep track of all the history of changes.
But, this feature may not be so useful if an IXFR client has access
to two IXFR servers: A and B, with inconsistent condensation results.
The current version of the IXFR client, received from server A, may
be unknown to server B. In such a case, server B can not provide
incremental data from the unknown version and a full zone transfer is
necessary.
Condensation is completely optional. Clients can't detect from the
response whether the server has condensed the reply or not.
For interoperability, IXFR servers, including those without the
condensation feature, should not flag an error even if it receives a
client's IXFR request with a unknown version number and should,
instead, attempt to perform a full zone transfer.
7. Example
Given the following three generations of data with the current serial
number of 3,
JAIN.AD.JP. IN SOA NS.JAIN.AD.JP. mohta.jain.ad.jp. (
1 600 600 3600000 604800)
IN NS NS.JAIN.AD.JP.
NS.JAIN.AD.JP. IN A 133.69.136.1
NEZU.JAIN.AD.JP. IN A 133.69.136.5
NEZU.JAIN.AD.JP. is removed and JAIN-BB.JAIN.AD.JP. is added.
jain.ad.jp. IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. (
2 600 600 3600000 604800)
IN NS NS.JAIN.AD.JP.
M. Ohta Expires on December 6, 1996 [Page 4]
INTERNET DRAFT Incremental Zone Transfer in DNS June 1996
NS.JAIN.AD.JP. IN A 133.69.136.1
JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4
IN A 192.41.197.2
One of the IP addresses of JAIN-BB.JAIN.AD.JP. is changed.
JAIN.AD.JP. IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. (
3 600 600 3600000 604800)
IN NS NS.JAIN.AD.JP.
NS.JAIN.AD.JP. IN A 133.69.136.1
JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3
IN A 192.41.197.2
The following IXFR query
+---------------------------------------------------+
Header | OPCODE=SQUERY |
+---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | <empty> |
+---------------------------------------------------+
Authority | JAIN.AD.JP. IN SOA serial=1 |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
could be replied to with the following full zone transfer message:
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | JAIN.AD.JP. IN SOA serial=3 |
| JAIN.AD.JP. IN NS NS.JAIN.AD.JP. |
| NS.JAIN.AD.JP. IN A 133.69.136.1 |
| JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 |
| JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 |
| JAIN.AD.JP. IN SOA serial=3 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
or with the following incremental message:
M. Ohta Expires on December 6, 1996 [Page 5]
INTERNET DRAFT Incremental Zone Transfer in DNS June 1996
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | JAIN.AD.JP. IN SOA serial=3 |
| JAIN.AD.JP. IN SOA serial=1 |
| NEZU.JAIN.AD.JP. IN A 133.69.136.5 |
| JAIN.AD.JP. IN SOA serial=2 |
| JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 |
| JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 |
| JAIN.AD.JP. IN SOA serial=2 |
| JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 |
| JAIN.AD.JP. IN SOA serial=3 |
| JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 |
| JAIN.AD.JP. IN SOA serial=3 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
or with the following condensed incremental message:
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | JAIN.AD.JP. IN SOA serial=3 |
| JAIN.AD.JP. IN SOA serial=1 |
| NEZU.JAIN.AD.JP. IN A 133.69.136.5 |
| JAIN.AD.JP. IN SOA serial=3 |
| JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 |
| JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 |
| JAIN.AD.JP. IN SOA serial=3 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
or, if UDP packet overflow occurs, with the following message:
M. Ohta Expires on December 6, 1996 [Page 6]
INTERNET DRAFT Incremental Zone Transfer in DNS June 1996
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | JAIN.AD.JP. IN SOA serial=3 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
8. Acknowledgements
The original idea of IXFR was conceived by Anant Kumar, Steve Hotz
and Jon Postel.
For the refinement of the protocol and documentation, many people
have contributed including, but not limited to, Anant Kumar, Robert
Austein, Paul Vixie, Randy Bush, Mark Andrews, Robert Elz and the
members of the IETF DNSIND working group.
9. References
[NOTIFY] Vixie, P., "DNS NOTIFY: a mechanism for prompt notification
of zone changes", work in progress as <draft-ietf-dnsind-notify-
05.txt>.
[STD13] Mockapetris, P., "Domain Name System" (RFC1034 and RFC1035),
November 1987.
10. Security Considerations
Though DNS is related to several security problems, no attempt is
made to fix them in this document.
This document is believed to introduce no additional security
problems to the current DNS protocol.
11. Author's Address
Masataka Ohta
Computer Center, Tokyo Institute of Technology
2-12-1, O-okayama, Meguro-ku, Tokyo 152, JAPAN
Phone: +81-3-5734-3299, Fax: +81-3-5734-3415
EMail: mohta@necom830.hpcl.titech.ac.jp
M. Ohta Expires on December 6, 1996 [Page 7]

423
usr.sbin/named/doc/i-d/draft-ietf-dnsind-notify-08.txt Normal file
View File

@ -0,0 +1,423 @@
DNSIND Working Group Paul Vixie (ISC)
INTERNET-DRAFT May, 1996
<draft-ietf-dnsind-notify-08.txt>
Updates: RFC 1035
A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This draft describes the NOTIFY opcode for DNS, by which a master
server advises a set of slave servers that the master's data has been
changed and that a query should be initiated to discover the new
data.
1 - Rationale and Scope
1.1. Slow propagation of new and changed data in a DNS zone can be due
to a zone's relatively long refresh times. Longer refresh times are
beneficial in that they reduce load on the master servers, but that
benefit comes at the cost of long intervals of incoherence among
authority servers whenever the zone is updated.
Expires November 1996 [Page 1]
INTERNET-DRAFT DNS NOTIFY May 1996
1.2. The DNS NOTIFY transaction allows master servers to inform slave
servers when the zone has changed -- an interrupt as opposed to poll
model -- which it is hoped will reduce propagation delay while not
unduly increasing the masters' load. This specification only allows
slaves to be notified of SOA RR changes, but the architechture of NOTIFY
is intended to be extensible to other RR types.
1.3. This document intentionally gives more definition to the roles of
``Master,'' ``Slave'' and ``Stealth'' servers, their enumeration in NS
RRs, and the SOA MNAME field. In that sense, this document can be
considered an addendum to [RFC1035].
2 - Definitions and Invariants
2.1. The following definitions are used in this document:
Slave an authoritative server which uses zone transfer to
retrieve the zone. All slave servers are named in
the NS RRs for the zone.
Master any authoritative server configured to be the source
of zone transfer for one or more slave servers.
Primary Master master server at the root of the zone transfer
dependency graph. The primary master is named in the
zone's SOA MNAME field and optionally by an NS RR.
There is by definition only one primary master server
per zone.
Stealth like a slave server except not listed in an NS RR for
the zone. A stealth server, unless explicitly
configured to do otherwise, will set the AA bit in
responses and be capable of acting as a master. A
stealth server will only be known by other servers if
they are given static configuration data indicating
its existence.
Notify Set set of servers to be notified of changes to some
zone. Default is all servers named in the NS RRset,
except for any server also named in the SOA MNAME.
Some implementations will permit the name server
administrator to override this set or add elements to
it (such as, for example, stealth servers).
Expires November 1996 [Page 2]
INTERNET-DRAFT DNS NOTIFY May 1996
2.2. The zone's servers must be organized into a dependency graph such
that there is a primary master, and all other servers must use AXFR or
IXFR either from the primary master or from some slave which is also a
master. No loops are permitted in the AXFR dependency graph.
3 - NOTIFY Message
3.1. When a master has updated one or more RRs in which slave servers
may be interested, the master may send the changed RR's name, class,
type, and optionally, new RDATA(s), to each known slave server using a
best efforts protocol based on the NOTIFY opcode.
3.2. NOTIFY uses the DNS Message Format, although it uses only a subset
of the available fields. Fields not otherwise described herein are to
be filled with binary zero (0), and implementations must ignore all
messages for which this is not the case.
3.3. NOTIFY is similar to QUERY in that it has a request message with
the header QR flag ``clear'' and a response message with QR ``set''.
The response message contains no useful information, but its reception
by the master is an indication that the slave has received the NOTIFY
and that the master can remove the slave from any retry queue for this
NOTIFY event.
3.4. The transport protocol used for a NOTIFY transaction will be UDP
unless the master has reason to believe that TCP is necessary; for
example, if a firewall has been installed between master and slave, and
only TCP has been allowed; or, if the changed RR is too large to fit in
a UDP/DNS datagram.
3.5. If TCP is used, both master and slave must continue to offer name
service during the transaction, even when the TCP transaction is not
making progress. The NOTIFY request is sent once, and a ``timeout'' is
said to have occurred if no NOTIFY response is received within a
reasonable interval.
3.6. If UDP is used, a master periodically sends a NOTIFY request to a
slave until either too many copies have been sent (a ``timeout''), an
ICMP message indicating that the port is unreachable, or until a NOTIFY
response is received from the slave with a matching query ID, QNAME, IP
source address, and UDP source port number.
Expires November 1996 [Page 3]
INTERNET-DRAFT DNS NOTIFY May 1996
Note:
The interval between transmissions, and the total number of
retransmissions, should be operational parameters specifiable by the
name server administrator, perhaps on a per-zone basis. Reasonable
defaults are a 60 second interval (or timeout if using TCP), and a
maximum of 5 retransmissions (for UDP). It is considered reasonable
to use additive or exponential backoff for the retry interval.
3.7. A NOTIFY request has QDCOUNT>0, ANCOUNT>=0, AUCOUNT>=0, ADCOUNT>=0.
If ANCOUNT>0, then the answer section represents an unsecure hint at the
new RRset for this <QNAME,QCLASS,QTYPE>. A slave receiving such a hint
is free to treat equivilence of this answer section with its local data
as a ``no further work needs to be done'' indication. If ANCOUNT=0, or
ANCOUNT>0 and the answer section differs from the slave's local data,
then the slave should query its known masters to retrieve the new data.
3.8. In no case shall the answer section of a NOTIFY request be used to
update a slave's local data, or to indicate that a zone transfer needs
to be undertaken, or to change the slave's zone refresh timers. Only a
``data present; data same'' condition can lead a slave to act
differently if ANCOUNT>0 than it would if ANCOUNT=0.
3.9. This version of the NOTIFY specification makes no use of the
authority or additional data sections, and so conforming implementations
should set AUCOUNT=0 and ADCOUNT=0 when transmitting requests. Since a
future revision of this specification may define a backwards compatible
use for either or both of these sections, current implementations must
ignore these sections, but not the entire message, if AUCOUNT>0 and/or
ADCOUNT>0.
3.10. If a slave receives a NOTIFY request from a host that is not a
known master for the zone containing the QNAME, it should ignore the
request and produce an error message in its operations log.
Note:
This implies that slaves of a multihomed master must either know
their master by the ``closest'' of the master's interface addresses,
or must know all of the master's interface addresses. Otherwise, a
valid NOTIFY request might come from an address that is not on the
slave's state list of masters for the zone, which would be an error.
Expires November 1996 [Page 4]
INTERNET-DRAFT DNS NOTIFY May 1996
3.11. The only defined NOTIFY event at this time is that the SOA RR has
changed. Upon completion of a NOTIFY transaction for QTYPE=SOA, the
slave should behave as though the zone given in the QNAME had reached
its REFRESH interval (see [RFC1035]), i.e., it should query its masters
for the SOA of the zone given in the NOTIFY QNAME, and check the answer
to see if the SOA SERIAL has been incremented since the last time the
zone was fetched. If so, a zone transfer (either AXFR or IXFR) should
be initiated.
Note:
Because a deep server dependency graph may have multiple paths from
the primary master to any given slave, it is possible that a slave
will receive a NOTIFY from one of its known masters even though the
rest of its known masters have not yet updated their copies of the
zone. Therefore, when issuing a QUERY for the zone's SOA, the query
should be directed at the known master who was the source of the
NOTIFY event, and not at any of the other known masters. This
represents a departure from [RFC1035], which specifies that upon
expiry of the SOA REFRESH interval, all known masters should be
queried in turn.
3.12. If a NOTIFY request is received by a slave who does not implement
the NOTIFY opcode, it will respond with a NOTIMP (unimplemented feature
error) message. A master server who receives such a NOTIMP should
consider the NOTIFY transaction complete for that slave.
4 - Details and Examples
4.1. Retaining query state information across host reboots is optional,
but it is reasonable to simply execute an SOA NOTIFY transaction on each
authority zone when a server first starts.
4.2. Each slave is likely to receive several copies of the same NOTIFY
request: One from the primary master, and one from each other slave as
that slave transfers the new zone and notifies its potential peers. The
NOTIFY protocol supports this multiplicity by requiring that NOTIFY be
sent by a slave/master only AFTER it has updated the SOA RR or has
determined that no update is necessary, which in practice means after a
successful zone transfer. Thus, barring delivery reordering, the last
NOTIFY any slave receives will be the one indicating the latest change.
Since a slave always requests SOAs and AXFR/IXFRs only from its known
masters, it will have an opportunity to retry its QUERY for the SOA
after each of its masters have completed each zone update.
Expires November 1996 [Page 5]
INTERNET-DRAFT DNS NOTIFY May 1996
4.3. If a master server seeks to avoid causing a large number of
simultaneous outbound zone transfers, it may delay for an arbitrary
length of time before sending a NOTIFY message to any given slave. It
is expected that the time will be chosen at random, so that each slave
will begin its transfer at a unique time. The delay shall not in any
case be longer than the SOA REFRESH time.
Note:
This delay should be a parameter that each primary master name server
can specify, perhaps on a per-zone basis. Random delays of between
30 and 60 seconds would seem adequate if the servers share a LAN and
the zones are of moderate size.
4.4. A slave which receives a valid NOTIFY should defer action on any
subsequent NOTIFY with the same <QNAME,QCLASS,QTYPE> until it has
completed the transaction begun by the first NOTIFY. This duplicate
rejection is necessary to avoid having multiple notifications lead to
pummeling the master server.
4.5 - Zone has Updated on Primary Master
Primary master sends a NOTIFY request to all servers named in Notify
Set. The NOTIFY request has the following characteristics:
query ID: (new)
op: NOTIFY (4)
resp: NOERROR
flags: AA
qcount: 1
qname: (zone name)
qclass: (zone class)
qtype: T_SOA
4.6 - Zone has Updated on a Slave that is also a Master
As above in 4.5, except that this server's Notify Set may be different
from the Primary Master's due to optional static specification of local
stealth servers.
Expires November 1996 [Page 6]
INTERNET-DRAFT DNS NOTIFY May 1996
4.7 - Slave Receives a NOTIFY Request from a Master
When a slave server receives a NOTIFY request from one of its locally
designated masters for the zone enclosing the given QNAME, with
QTYPE=SOA and QR=0, it should enter the state it would if the zone's
refresh timer had expired. It will also send a NOTIFY response back to
the NOTIFY request's source, with the following characteristics:
query ID: (same)
op: NOTIFY (4)
resp: NOERROR
flags: QR AA
qcount: 1
qname: (zone name)
qclass: (zone class)
qtype: T_SOA
This is intended to be identical to the NOTIFY request, except that the
QR bit is also set. The query ID of the response must be the same as
was received in the request.
4.8 - Master Receives a NOTIFY Response from Slave
When a master server receives a NOTIFY response, it deletes this query
from the retry queue, thus completing the ``notification process'' of
``this'' RRset change to ``that'' server.
5 - Security Considerations
We believe that the NOTIFY operation's only security considerations are:
1. That a NOTIFY request with a forged IP/UDP source address can cause a
slave to send spurious SOA queries to its masters, leading to a
benign denial of service attack if the forged requests are sent very
often.
2. That TCP spoofing could be used against a slave server given NOTIFY
as a means of synchronizing an SOA query and UDP/DNS spoofing as a
means of forcing a zone transfer.
Expires November 1996 [Page 7]
INTERNET-DRAFT DNS NOTIFY May 1996
6 - References
[RFC1035]
P. Mockapetris, "Domain Names - Implementation and Specification",
RFC 1035, USC/Information Sciences Institute, November 1987.
[IXFR]
M. Ohta, "Incremental Zone Transfer", Internet Draft, February 1996,
<draft-ietf-dnsind-ixfr-06.txt>.
7 - Author's Address
Paul Vixie
Internet Software Consortium
Star Route Box 159A
Woodside, CA 94062
+1 415 747 0204
<paul@vix.com>
Expires November 1996 [Page 8]

2609
usr.sbin/named/doc/i-d/draft-ietf-dnssec-secext-10.txt Normal file
View File

File diff suppressed because it is too large Load Diff

871
usr.sbin/named/doc/i-d/draft-ietf-dnssec-update-00.txt Normal file
View File

@ -0,0 +1,871 @@
INTERNET-DRAFT Donald E. Eastlake 3rd
CyberCash, Inc.
Expires: 27 August 1996 28 February 1996
Secure Domain Name System Dynamic Update
------ ------ ---- ------ ------- ------
Status of This Document
This draft, file name draft-ietf-dnssec-update-00.txt, is intended to
be become a Proposed Standard RFC. Distribution of this document is
unlimited. Comments should be sent to the DNS security mailing list
<dns-security@tis.com> or the author.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (East USA), ftp.isi.edu (West USA),
nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe),
munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa).
Eastlake [Page 1]
INTERNET-DRAFT Secure DNS Update 28 February 1996
Abstract
Domain Name System (DNS) protocol extensions have been defined to
authenticate the data in DNS and provide key distribution services
(draft-ietf-dnssec-secext-*.txt). DNS Dynamic Update operations have
also been defined (draft-ietf-dnsind-dynDNS-*.txt>, but without a
detailed description of strong security for the update operation.
This draft describes how to use DNS digital signatures covering
requests and data to secure updates and restrict them to those
authorized to perform them as indicated by the updater's possession
of cryptographic keys.
Acknowledgements
The contributions of the following person to this draft are
gratefully acknowledged:
Charlie Kaufman
Eastlake [Page 2]
INTERNET-DRAFT Secure DNS Update 28 February 1996
Table of Contents
Status of This Document....................................1
Abstract...................................................2
Acknowledgements...........................................2
Table of Contents..........................................3
1. Introduction............................................4
1.1 Overview of DNS Dynamic Update.........................4
1.2 Overview of DNS Security...............................4
2. Two Basic Strategies....................................6
3. Keys....................................................8
3.1 Update Keys............................................8
3.1.1 Update Key Name Scope................................8
3.1.2 Update Key Class Scope...............................8
3.1.3 Update Key Signatory Field...........................8
3.2 Zone Keys and Update Modes............................10
3.3 Wildcard Key Punch Through............................11
4. Update Signatures......................................12
4.1 Update Request Signatures.............................12
4.2 Update Data Signatures................................12
5. The in-key.int. Domain.................................13
6. Security Considerations................................15
References................................................15
Author's Address..........................................15
Expiration and File Name..................................15
Eastlake [Page 3]
INTERNET-DRAFT Secure DNS Update 28 February 1996
1. Introduction
Dynamic update operations have been defined for the Domain Name
System (DNS) in draft-ietf-dsnind-dynDNS-*.txt but without a detailed
description of strong security for those updates. Means of securing
the DNS and using it for key distribution have been defined in
draft-ietf-dnssec-sexect-*.txt.
This draft proposes techniques based on the defined DNS security
mechanisms to authenticate DNS updates. In addition, a secure in-
key.int. domain is defined with special security policies. This in-
key domain permits access to entities by their key if the entity has
been registered in that domain.
Familiarity with the DNS system [RFC 1034, 1035] is assumed.
Familiarity with the DNS security and dynamic update proposals will
be helpful.
1.1 Overview of DNS Dynamic Update
DNS dynamic update defines a new DNS opcode, new DNS request and
response structure if that opcode is used, and new error codes. An
update can specify complex combinations of deletion and insertion
(with or without pre-existence testing) of resource records (RRs)
with one or more owner names; however, all testing and changes for
any particular DNS update request are restricted to a single zone.
The server for a secure dynamic zone must increment the zone SOA
serial number when an update occurs or the next time the SOA is
retrieved if one or more updates have occurred since the previous SOA
retrieval and the updates themselves did not update the SOA.
1.2 Overview of DNS Security
DNS security authenticates data in the DNS by also storing digital
signatures in the DNS as resource records (RRs). A SIG RR provides a
digital signature on the set of all RRs with the same owner name and
class as the SIG and whose type is the type covered by the SIG. The
SIG RR cryptographically binds the covered RR set to the signer, time
signed, signature expiration date, etc. There is a key associated
with every secure zone and all data in the secure zone is signed
either by this zone key or by a dynamic update key tracing its
authority to the zone key.
DNS security also defines transaction SIGs and request SIGs.
Transaction SIGs appear at the end of a response. Transaction SIGs
Eastlake [Page 4]
INTERNET-DRAFT Secure DNS Update 28 February 1996
authenticate the response and bind it to the corresponding request
with the key of the host that the responding DNS server is running
on. Request SIGs appear at the end of a request and authenticate the
request. Request SIGs are the primary means of authenticating update
requests.
DNS security also permits the storage of public keys in the DNS via
KEY RRs. These KEY RRs are also, of course, authenticated by SIG
RRs. KEY RRs for zones are stored in their superzone and subzone
servers, if any, so that the secure DNS tree of zones can be
traversed by a security aware resolver.
Eastlake [Page 5]
INTERNET-DRAFT Secure DNS Update 28 February 1996
2. Two Basic Strategies
A dynamic secure zone is any secure DNS zone containing one or more
KEY RRs that can authorize dynamic updates, i.e., entity or user KEY
RRs with the signatory field non-zero and whose zone KEY RR signatory
field indicates that updates are implemented. There are two basic
modes of dynamic secure zone which relate to the update strategy,
mode A and mode B. A summary comparison table is given below and
then each mode is described.
SUMMARY OF DYNAMIC SECURE ZONE MODES
CRITERIA: | MODE A | MODE B
-------------------------+--------------------+-------------------
Zone Key | Off line | On line
-------------------------+--------------------+-------------------
Server Workload | Low | High
-------------------------+--------------------+-------------------
Static Data Security | Very High | Medium-High
-------------------------+--------------------+-------------------
Dynamic Data Security | Medium | Medium-High
-------------------------+--------------------+-------------------
Dynamic Key Rollover | No | Yes
-------------------------+--------------------+-------------------
Key Restrictions | Fine grain | Coarse grain
-------------------------+--------------------+-------------------
For mode A, the zone owner key and static zone master file are always
kept off-line for maximum security of the static zone contents. Any
dynamicly added or changed RRs are signed in the secure zone by their
authorizing dynamic update key and they are backed up, along with
this SIG RR, in a separate online dynamic master file. In this type
of zone, server computation is minimized since the server need only
check signatures on the update data, which has already been signed by
the updater, generally a much faster operation than signing data.
However, the AXFR SIG and NXT RRs which covers the zone under the
zone key will not cover dynamically added data. Thus, for type A
dynamic secure zones, zone transfer security is not provided for
dynamically added RRs, where they could be omitted, and
authentication is not provided for the server denial of the existence
of a dynamically added type. Key rollover for an entity that can
authorize dynamic updates is more cumbersome since the authority of
their key must be traceable to a zone key and so, in general, they
must securely communicate a new key to the zone authority for manual
transfer to the off line static master file. Because the dynamicly
added RRs retain their update KEY signed SIG, finer grained control
control of updates can be implemented via bits in the KEY RR
signatory field. NOTE: for this mode the zone SOA must be signed by a
dynamic update key and that private key must be kept on line so that
the SOA can be changed for updates.
Eastlake [Page 6]
INTERNET-DRAFT Secure DNS Update 28 February 1996
For mode B, the zone owner key and master file are kept on-line at
the zone primary server. When authenticated updates succeed, SIGs
under the zone key for the resulting data (including the possible NXT
type bit map changes) are calculated and these SIG (and possible NXT)
changes are entered into the zone and the unified on-line master
file. (The zone transfer AXFR SIG may be recalculated for each
update or on demand when a zone transfer is requested and it is out
of date.) This requires considerably more computational effort on
the part of the server as the public/private keys are generally
arranged so that signing (calculating a SIG) is more effort than
verifying a signature. The security on static data in the zone is
decreased because the ultimate state of the static date being served
and the ultimate zone authority private key are all on-line on the
net. This means that if the primary server is subverted, false data
could be authenticated to secondaries and other servers/resolvers.
On the other hand, this mode of operation means that data added
dynamically is more secure than in mode A. Dynamic data will be
covered by the AXFR SIG and thus fully protected during zone
transfers and will be included in NXT RRs so that it can be falsely
denied by a server only to the same extent that static data can
(i.e., if it is within a wild card scope). Maintaining the zone key
on-line also means that dynamic update keys which are signed by the
zone key can be dynamically updated since the zone key is available
to dynamically sign new values. Finally, because the zone key is used
to sign all the zone data, the information as to who originated the
current state of dynamic RR sets is lost making unavailable the
effects of some of the update control bits in the KEY RR signatory
field.
NOTE: The Mode A / Mode B distinction only effects the validation
and performance of update requests. It has no effect on retrievals.
[It might be possible to dream up additional modes but I think they
would be more complicated. A mode where things are temporarily
signed by the entity key but lated changed to being signed off line
by the zone key doesn't work well. You could also have a mode where
the zone key SIGs were added to and also covered the entity
signature. But the problem with any delayed addition of zone
signatures tends to be that you have to delay deletes of such
material until you can zone sign new NXT RRs, etc.]
Eastlake [Page 7]
INTERNET-DRAFT Secure DNS Update 28 February 1996
3. Keys
Dynamic update requests depend on update keys as described in section
3.1 below. In addition, the zone secure dynamic update mode and
availability of some options is indicated in the zone key. Finally,
a special rule is used in searching for KEYs to validate updates as
described in section 3.3.
3.1 Update Keys
All update requests to a secure zone must include signatures by one
or more key(s) that together can authorize that update. In order for
the Domain Name System (DNS) server receiving the request to confirm
this, the key or keys must be available to and authenticated by that
server as a specially flagged KEY Resource Record. The one exception
is in the in-key.int. domain as described in section 5.
The scope of authority of such keys is indicated by their KEY RR
owner name, class, and signatory field flags as described below. In
addition, such KEY RRs must be entity or user keys and not have the
authentication use prohibited bit on. All parts of the actual update
must be within the scope of at least one of the keys used for a
request SIG on the update request as described in section 4.
3.1.1 Update Key Name Scope
The owner name of any update authorizing KEY RR must (1) be the same
as the owner name of any RRs being added or deleted or (2) if the
owner name of the KEY is a wildcard, it must include within its
extended scope (see section 3.3) the name of any RRs being added or
deleted and those RRs must be in the same zone.
3.1.2 Update Key Class Scope
The class of any update authorizing KEY RR must be the same as the
class of any RR's being added or deleted.
3.1.3 Update Key Signatory Field
The four bit "signatory field" (see draft-ietf-dnssec-secext-*.txt)
of any update authorizing KEY RR must be non-zero. The bits have the
meanings described below for non-zone keys (see section 3.2 for zone
Eastlake [Page 8]
INTERNET-DRAFT Secure DNS Update 28 February 1996
type keys).
UPDATE KEY RR SIGNATORY FIELD BITS
0 1 2 3
+-----------+-----------+-----------+-----------+
| zone | strong | unique | general |
+-----------+-----------+-----------+-----------+
Bit 0, zone control - If nonzero, this key is authorized to attach,
detach, and move zones by creating and deleting NS, glue, and
zone KEY RR(s). If zero, the key can not authorize any update
that would effect such RRs. This bit is meaningful for both
type A and type B dynamic secure zones.
NOTE: do not confuse the "zone" signatory field bit with the
"zone" key type bit.
Bit 1, strong update - If nonzero, this key is authorized to add and
delete RRs even if there are other RRs with the same owner name
and class that are authenticated by a SIG signed with a
different dynamic update KEY. If zero, the key can only
authorize updates where any existing dynamic RRs of the same
owner and class are authenticated by a SIG using the same key.
This bit is meaningful only for type A dynamic zones and is
ignored in type B dynamic zones.
Keeping this bit zero on multiple KEY RRs with the same or
nested wild card owner names permits multiple entities to exist
that can create and delete names but can not effect RRs with
different owner names from any they created. In effect, this
creates two levels of dynamic update key, strong and weak, where
weak keys are limited in interfering with each other but a
strong key can interfere with any weak keys or other strong
keys.
Bit 2, unique name update - If nonzero, this key is authorized to add
and update RRs for only a single owner name. If there already
exist RRs with multiple names signed by this key, they may be
updated but no new name created until the number of existing
names is reduced to zero. This bit is meaningful only for mode
A dynamic zones and is ignored in mode B dynamic zones. This bit
is meaningful only if the owner name is a wildcard. (Any
dynamic update KEY with a non-wildcard name is, in effect, a
unique name update key.)
This bit can be used to restrict a KEY from flooding a zone with
new names. In conjunction with a local administratively imposed
limit on the number of dynamic RRs with a particular name, it
can completely restrict a KEY from flooding a zone with RRs.
Eastlake [Page 9]
INTERNET-DRAFT Secure DNS Update 28 February 1996
Bit 3, general update - The general update signatory field bit has no
special meaning. If the other three bits are all zero, it must
be one so that the field is non-zero in the update key. The
meaning of all values of the signatory field with the general
bit and one or more other signatory field bits on is reserved.
All the signatory bit update authorizations described above only
apply if the update is within the name and class scope as per
sections 3.1.1 and 3.1.2.
3.2 Zone Keys and Update Modes
Zone type keys are automatically authorized to sign anything in their
zone, of course, regardless of the value of their signatory field.
For zone keys, the signatory field bits have different means than
they they do for update keys, as shown below:
ZONE KEY RR SIGNATORY FIELD BITS
0 1 2 3
+-----------+-----------+-----------+-----------+
| mode | strong | unique | general |
+-----------+-----------+-----------+-----------+
Bit 0, mode - This bit indicates the update mode for this zone. Zero
indicates mode A while a one indicates mode B.
Bit 1, strong update - If nonzero, this indicates that the "strong"
key feature described in section 3.1.3 above is implemented and
enabled for this secure zone. If zero, the feature is not
available. Has no effect if the zone is a mode B secure update
zone.
Bit 2, unique name update - If nonzero, this indicates that the
"unique name" feature described in section 3.1.3 above is
implemented and enabled for this secure zone. If zero, this
feature is not available. Has no effect if the zone is a mode B
secure update zone.
Bit 3, general - This bit has no special meeting. If dynamic update
for a zone is supported and the other bits in the zone key
signatory field are zero, it must be a one. The meaning of zone
keys where the signatory field has the general bit and other
bits on is reserved.
If there are multiple KEY RRs for a zone and zone policy is in
transition, they might have different signatory fields. In that
Eastlake [Page 10]
INTERNET-DRAFT Secure DNS Update 28 February 1996
case, strong and unique name restrictions must be enforced as long as
there is a non-expired zone key being advertised that indicates node
A with the strong or unique name bit on respectively. Mode B updates
must be supported as long as there is a non-expired zone key that
indicates mode B. Mode A updates may be treated as mode B updates at
server option if non-expired zone keys indicate that both are
supported.
A server that will be executing update operations on a zone, that is
the primary master server, MUST not advertize a zone key that will
attract requests for a mode or features that it can not support.
3.3 Wildcard Key Punch Through
Just as a zone key is valid throughout the entire zone, update keys
with wildcard names are valid throughout their extended scope, within
the zone. That is, they remain remain valid for any name that would
match them, even existing specific names within their apparent scope.
If this were not so, then whenever a name within a wildcard scope was
created by dynamic update, it would be necessary to first create a
copy of the KEY RR with this name, because otherwise the existence of
the more specific name would hide the authorizing KEY RR and would
make later updates impossible. An updater could create such a KEY RR
but could not zone sign it. They would have to sign it with the same
key using the wildcard name as signer. Thus in creating, for example,
one hundred type A RRs authorized by a *.1.1.1.in-addr.arpa. KEY RR,
without key punch through 100 As, 100 KEYs, and 200 SIGs would have
to be created as opposed to merely 100 As and 100 SIGs with key punch
through.
Eastlake [Page 11]
INTERNET-DRAFT Secure DNS Update 28 February 1996
4. Update Signatures
Two kinds of signatures can appear in updates. Request signatures,
which are always required, cover the entire request and authenticate
the DNS header, including opcode, counts, etc., as well as the data.
Data signatures, on the other hand, appear only among the RRs to be
added and are only required for mode A operation.
4.1 Update Request Signatures
An update can effect multiple owner names in a zone. It may be that
these different names are covered by different dynamic update keys.
For every owner name and class effected, the updater must know a
private key valid for that name and class and must prove this by
appending request SIG RRs under each such key.
As specified in draft-ietf-dnssec-secext-*.txt, a request signature
is a SIG RR occurring at the end of a request with a type covered
field of zero. For an update, request signatures occur in the
Additional section. The final "Reserved" section of update requests
in draft-ietf-dnsind-dynDNS-06.txt is hereby redefined as the
Additional section and its corresponding count field is relabeled
ARCOUNT. Each request SIG signs the entire request, including DNS
header, but excluding any other request SIG(s).
4.2 Update Data Signatures
Mode A dynamic secure zones require that the update requester provide
SIG RRs that will authenticate the after update state of all RR sets
that are changed by the update and are non-empty after the update.
These SIG RRs appear in the request as RRs to be added and the
request must delete any previous data SIG RRs that are invalidated by
the request.
In Mode B dynamic secure zones, all zone data is authenticated by
zone key SIG RRs. In this case data signatures need not be included
with the update. A resolver can determine which mode an updatable
secure zone is using by examining the signatory field bits of the
zone KEY RR (see section 3.2).
Eastlake [Page 12]
INTERNET-DRAFT Secure DNS Update 28 February 1996
5. The in-key.int. Domain
A special domain is defined, the in-key.int. domain, to permit
inverse lookup by key. DNS servers for zones that include any
updatable part of this domain have a special update policy and all
servers and resolvers have a special authentication policy for this
domain. Servers authenticate updates for this domain based on the
requesters knowledge of the private key corresponding to a public key
whose hash is encoded into the RR owner name.
Normally the only RRs stored in this domain will be a KEY RR and an
authenticating SIG with the SIG signer field pointing to the normal
owner of the KEY. It is expected that an administrative restriction
may be placed on the number of RRs stored under any particular owner
name or charges imposed for additions to this domain.
[It would be possible to just have a PTR and a SIG here but then you
would always have to actually retrieved the KEY(s) at where the PTR
points to to validate anything. Or you could have both a KEY and a
PTR and two SIGs but that would be twice as bulky.]
The owner name associated with a key is
<key-hash>.<key-footprint>.algorithm.in-key.int.
key-hash is the hex representation of the SHA1 [SHA1] hash of the
"public key" portion of the corresponding KEY RR (the portion of
the RDATA after the algorithm octet) with label separating dots
added every fourth hex digit. [should I go for decimal here and
for footprint?] [I'm afraid of hash collisions with MD5 so I
went for the longer SHA...]
key-footprint is the hex representation of the key footprint field of
the KEY RR. [yet more bits to make collisions even less likely]
[could add a key-length label instead of or in addition to the key-
footprint...]
algorithm is the decimal number designating the public key algorithm
from the "algorithm" octet portion of the corresponding key.
Thus, at this time, algorithm will be either 1 or 254. Entries
for algorithm 253 are prohibited.
For example, the RRs in this domain for a purported key with actual
owner name example.tld could be as follows:
$ORIGIN xxxx.xxxx.xxxx.xxxx.xxxx.xxxx.xxxx.xxxx.xxxx.xxxx.xxxx.1.in-key.int.
IN KEY <flags> 0 1 (
45IkskceFGgiWCn/GxHhai6VAuHAoNUz4YoUMxFcby9k/yvedMfQgKzhH5er0Mu/vILz
Eastlake [Page 13]
INTERNET-DRAFT Secure DNS Update 28 February 1996
80jEeC8aTrO+KKmCaY1tVfSCSqQYn6//11U6Nld= ;key
)
IN SIG KEY 1 3 ( ;type-cov=PTR, alg=1, labels=3
19991202030405 ;signature expiration
19951211100908 ;time signed
2143658709 ;key footprint
example.tld. ;signer
MxFcby9k/yvedMfQgKzhH5er0Mu/vILz45IkskceFGgiWCn/GxHhai6VAuHAoNUz4YoU
1tVfSCSqQYn6//11U6Nld80jEeC8aTrO+KKmCaY= ;signature
)
Retrievals from leaves of this zone are authenticated by validating
the SIG against the KEY with the same owner name and checking that
this owner name correctly reflects the hash and key footprint of the
key. Thus, for this type of validation only, the signer name is
ignored and the SIG is NOT traced back to a known trusted key. In
addition, entries in this domain are "eternal" in that the SIG time
signed and signature expiration are ignored. Note that entries in
this special zone, even when authenticated, give only a hint that the
KEY stored there is or was valid for the signer name. A separate
retrieval from the signer name must be done for confirmation that
they key is currently valid.
Registration in the in-key.int. domain is voluntary. All servers
that include key storage leaves of the in-key.int. domain MUST
operate in mode A.
Eastlake [Page 14]
INTERNET-DRAFT Secure DNS Update 28 February 1996
6. Security Considerations
Any zone permitting dynamic updates is inherently less secure than a
static secure zone maintained off line as recommended in draft-ietf-
dnssec-secext-*.txt. If nothing else, secure dynamic update requires
on line change to and re-signing of the zone SOA resource record (RR)
to increase the SOA serial number. This means that compromise of the
primary server host could lead to arbitrary serial number changes.
Isolation of dynamic RRs to separate zones from from holding most
static RRs can limit the damage that could occur from breach of a
dynamic zone's security.
References
draft-ietf-dnssec-secext-*.txt
draft-ietf-dnsind-dynDNS-*.txt
[RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
November 1987
[RFC1035] - Domain Names - Implementation and Specifications
[SHA1]
Author's Address
Donald E. Eastlake, 3rd
CyberCash, Inc.
318 Acton Street
Carlisle, MA 01741 USA
Telephone: +1 508-287-4877
+1 508-371-7148 (fax)
+1 703-620-4200 (main office, Reston, Virginia, USA)
email: dee@cybercash.com
Expiration and File Name
This draft expires 27 August 1996.
Its file name is draft-ietf-dnssec-update-00.txt.
Eastlake [Page 15]

367
usr.sbin/named/doc/i-d/draft-manning-dnssvr-criteria-04.txt Normal file
View File

@ -0,0 +1,367 @@
Operational Requirements Area Bill Manning (ISI)
INTERNET-DRAFT Paul Vixie (ISC)
Expires December 1996 June 1996
Operational Criteria for Root Name Servers
<draft-manning-dnssvr-criteria-04.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This document specifies the operational requirements of root name
servers, including host hardware capacities, name server software
revisions, network connectivity, and physical environment.
Expires November 1996 [Page 1]
INTERNET-DRAFT DNSSVR CRITERIA May 1996
1 - Rationale and Scope
1.1. Historically, the name servers responsible for the root (``.'')
zone have also been responsible for all international top-level domains
(iTLD's, for example: COM, EDU, INT, ARPA). These name servers have
been operated by a cadre of highly capable volunteers, and their
administration has been loosely coordinated by the NIC (first SRI-NIC
and now InterNIC). Ultimate responsibility for the correct operation of
these servers and for the content of the DNS zones they served has
always rested with the IANA.
1.2. As described in [Postel96], many new TLD's may be created
shortly. Servers for all new and existing iTLD's will be subject to the
operational requirements given in [Postel96]. The set of servers for
the root (``.'') zone is likely to become disjoint from the set of
servers for any TLD or group of TLD's, including those maintained by
the InterNIC.
1.3. In spite of the similarities in operational requirements between
the servers for the iTLD's and the servers for the root (``.'') zone,
they are in fact different server sets with different administrators and
slightly different operational requirements. It is likely that many
contry code tld servers will have even more divergent operational
requirements. That said, the requirements set down in this document
could be successfully applied to any name server (whether root, top
level, or any other level), but may be more draconian than necessary
for servers other than those of the root (``.'') zone.
Disclaimer: The selection of name server locations and administrators,
and the procedures for addressing noncompliance with these
stated operational requirements, are outside the scope of this
document.
Definition: For the purpose of this document, the term ``zone master''
shall be used to designate the administrative owner of the
content of a zone. This person is expected to have final
responsibility for the selection and correct operation of
all of the zone's servers. For the root (``.'') zone, this
is the IANA.
Expires November 1996 [Page 2]
INTERNET-DRAFT DNSSVR CRITERIA May 1996
2 - Operational Requirements
2.1. Name server software. The zone master shall initially and
periodically choose a name server package to run on all of the zone's
servers. It is expected that the BIND server will be used, at least
initially, and that new versions or other servers will be specified from
time to time.
Rationale: This requirement is based on the wide and free
availability of BIND's source code, and the active
analysis and development it constantly receives from
several members of the IETF.
Name server software upgrades will be specified and scheduled by the
zone master, and must occur on all of a zone's servers within a
specified 96 hour window.
Rationale: In some cases it has proven necessary to ``cold start'' a
zone's servers in order to clear out oscillating bad
data. By forcing all software upgrades to happen at
about the same time, it will be possible to coordinate a
software change with a zone content change.
2.2. UDP checksums. UDP checksums must be generated when sending
datagrams, and verified when receiving them.
Rationale: Some vendors turn off UDP checksums for performance
reasons, citing the presence of MAC-level frame checks
(CRC, for example) as ``strong enough.'' This has been a
disaster in actual practice.
2.3. Dedicated host. A name server host should have no other function,
and no login accounts other than for system or network administrators.
No other network protocols should be served by a name server host (e.g.,
SMTP, NNTP, FTP, et al). If login is permitted from other than the
system console, then the login service must be by encrypted channel
(e.g., Kerberized and encrypted rlogin/telnet, the secure shell (SSH),
or an equivilent).
Rationale: Each additional service performed by a host makes it less
reliable and potentially less secure, as well as
complicating fault isolation procedures. While name
service does not consume very much in the way of system
resources, it is thought best that a host do a few things
well rather than many things poorly.
Expires November 1996 [Page 3]
INTERNET-DRAFT DNSSVR CRITERIA May 1996
2.4. Clock synchronization. A name server host should synchronize its
clock using the NTP protocol (currnet version) with authentication. At
least two NTP servers should be used. As an exception to section 2.3
above, a name server host can be an NTP server as well.
Rationale: For distributed fault isolation reasons, synchronized
time stamps in system event logs are quite helpful. NTP
is easily spoofed by UDP blast attacks, thus the
requirement for authentication between the name server
host and its NTP servers. A name server host is allowed
to be an NTP server because it has been observed that a
single host running both name service and stratum 1 NTP
is still quite reliable and secure.
2.5. Network interfaces. Name servers must send UDP responses with an
IP source address (and UDP source port number) equal to the IP
destination address (and UDP destination port number) of the request.
Also, a name server might have multiple real interfaces, but only one
will be advertised in the zone's NS RRset and associated glue A RRs.
The advertised address should be that of the ``best'' interface on the
host, in terms of network performance and reliability to the largest
number of destinations.
Rationale: While not required by [RFC1035], many extant DNS
implementations require the source address and port of a
reply to match the destination address and port to which
the request was sent. The number of advertised addresses
is limited to one (1) so that DNS delegation responses
containing this name server can be as short as possible.
2.6. Physical environment. A name server host must be located in a
secure space such as a locked computer room or a data center with
restricted access. The power supply should be redundant, using
batteries, generators or some other means to protect against utility
power failures. Network connectivity should be redundant, so that a
single wide area line failure cannot completely isolate the name server
host from the rest of the network.
2.7. Network security. The system and network administrators should
educate themselves about potential threats, and stay current on CERT
bulletins regarding network breakins. The system staff should
periodically audit the name server host's activity logs and be able to
detect breakins during or after the fact.
Expires November 1996 [Page 4]
INTERNET-DRAFT DNSSVR CRITERIA May 1996
2.8. Host performance. As of the time of this writing, a name server
must be able to answer 1,200 UDP transactions per second with less than
5 milliseconds of average latency. Because the network is still growing
at a high rate, the ability to grow to 2,000 transactions per second and
still support a 5 millisecond latency is highly desirable. Note that
this requirement affects both the host and the network infrastructure to
which that host is attached.
2.9. Response time. The administrators responsible for a name server
will respond to e-mail trouble reports within 24 hours. Personnel
issues such as vacations and illness will cause responsibilities to be
delegated and/or reassigned rather than ignored. After hours telephone
numbers must be made available to the zone master for nonpublished use
in emergencies. An escalation contact name, e-mail address, and
telephone number will also be made available to the zone master in the
event of nonresponse through the normal channel.
2.10. Zone transfer access control. The name server shall be configured
so that outbound zone transfers are permitted only to destinations on
the server's local networks, and to whichever networks the zone master
designates for remote debugging purposes.
Rationale: Zone transfers can present a significant load on a name
server, especially if several transfers are started
simultaneously against the same server. There is no
operational reason to allow anyone outside the name
server's and zone's administrators to transfer the entire
zone.
2.11. Zone transfer protocol. DNS AXFR shall be used in preference to
FTP or any other non-DNS transfer protocol. DNS NOTIFY (see [NOTIFY])
and DNS IXFR (see [IXFR]) shall be supported and enabled when available.
Rationale: Historically, the common implementations of DNS (a.k.a.,
BIND) did not support zone transfer of the root (``.'')
zone due to programming errors. Thus, FTP was used. In
the future, DNS implementations which do not support zone
transfer of all zones will not be considered suitable for
use as root name servers. The benefits of [IXFR] and
[NOTIFY] should be obvious.
Expires November 1996 [Page 5]
INTERNET-DRAFT DNSSVR CRITERIA May 1996
2.12. Recursion shall be disabled for queries.
Rationale: Recursion is a major source of cache pollution, and can
be a major drain on name server performance. An
organization's recursive DNS needs should be served by
some other host than its root name server(s). An
exception is made for missing glue since it's possible
that glue needed for some delegations will not be within
or beneath any zone for which the server is
authoritative. Such glue must be fetched via recursive
lookups to other servers.
2.13. Outages shall be reported. All outages, scheduled or not, shall
be reported to the zone master via e-mail. If an outage is unscheduled
or if an outage is scheduled less than 24 hours in advance, then an
additional notification of the zone master shall be made via telephone.
Extended or repeated outages may beget special handling by the zone
master.
2.14. Inverse name lookups. The PTR RR associated with a server's
primary interface address (that is, the address shown in in the zone's
delegation) shall have its target specified by the zone master.
Rationale: Since each organization has local control of their
network's PTR RRs, and since it is necessary for the
correct operation of some software that the forward and
reverse lookups have symmetrical results, it is left up
to the zone master to select the name for each authority
server's primary address.
3 - Possible Selection Criteria
3.1. Host population. A server's location on the network should be such
that it has a low IP hop count to a high number of end hosts.
Duplication of service should be avoided, such that any given set of end
hosts needs to have a low IP hop count to at most one authority server
for any given zone.
3.2. Infrastructure diversity. A server's location on the network
should be such that most failures capable of isolating it from a large
number of end hosts are diverse from the failures capable of similarly
isolating other authority servers for the same zone(s).
Expires November 1996 [Page 6]
INTERNET-DRAFT DNSSVR CRITERIA May 1996
4 - Security Considerations
See section 2.7.
5 - References
[RFC1035]
P. Mockapetris, ``Domain Names - Implementation and Specification,''
RFC 1035, USC/Information Sciences Institute, November 1987.
[Postel96]
J. Postel, "New Registries and the Delegation of International Top
Level Domains", <draft-postel-iana-itld-admin-00.txt>, May 3, 1996.
[IXFR]
M. Ohta, ``Incremental Zone Transfer,'' Internet Draft, February
1996, <draft-ietf-dnsind-ixfr-06.txt>.
[NOTIFY]
P. Vixie, ``A Mechanism for Prompt Notification of Zone Changes,''
Internet Draft, March 1996, <draft-ietf-dnsind-notify-07.txt>.
6 - Acknowledgements
Constructive comments have been received from: Jon Postel, Michael
Patton, Andrew Partan, Michael Dillon, Don Mitchell Steven Doyle, Owen
DeLong and other members of the internet community.
7 - Author's Address
Bill Manning
USC/ISI
4676 Admiralty Way
Marina del Rey, CA 90292
+1 310 822 1511
<bmanning@isi.edu>
Paul Vixie
Internet Software Consortium
Star Route Box 159A
Woodside, CA 94062
+1 415 747 0204
<paul@vix.com>
Expires November 1996 [Page 7]

37
usr.sbin/named/doc/info/49vs483 Normal file
View File

@ -0,0 +1,37 @@
Newsgroups: comp.protocols.tcp-ip.domains
From: marka@syd.dms.CSIRO.AU (Mark Andrews)
Subject: Re: BIND 4.9 bug?: Losing RRs at zone boundries
Message-ID: <C95n1r.G37@syd.dms.CSIRO.AU>
Sender: news@syd.dms.CSIRO.AU
Organization: CSIRO Division of Mathematics and Statistics, Australia
References: <1993Jun24.191743.23086@cs.cornell.edu>
Date: Fri, 25 Jun 1993 02:03:27 GMT
In article <1993Jun24.191743.23086@cs.cornell.edu> parmelee@cs.cornell.edu (Larry Parmelee) writes:
>We've just observed a problem today where our SECONDARY nameservers
>lost some critical MX and A records. The RRs in question were MX and A
>records for some of our subdomains, for example "CS.CORNELL.EDU" lost
>Anyone else seen this problem? Anyone have a fix?
>
>-Larry Parmelee
>parmelee@cs.cornell.edu
This is a side effect of the switch to 4.9. Older buggier nameservers
passed out MX and A records for the child zone. When the parent zone is
updated it no longer has theses bogus records transmitted and the
secondaries dutifully note that this has happend and cease to know about
then.
This can be fixed by
1. restart all the secondaries (the cached zones are ok) or
2. update the serial numbers of all the child zones.
As far as I can tell it only happens when a nameserver is secondaring
both the parent and child zone.
When a primary nameserver switches to 4.9 I recommend updating all
serial numbers for the zone that it is a primary, and for all zones that
are children of those it in primary for.
Mark.

49
usr.sbin/named/doc/info/AIX Normal file
View File

@ -0,0 +1,49 @@
Return-Path: fuat@ans.net
Received: by cognition.pa.dec.com; id AA04201; Tue, 19 Jan 93 11:46:18 -0800
Received: by inet-gw-1.pa.dec.com; id AA20795; Tue, 19 Jan 93 11:46:17 -0800
Received: by interlock.ans.net id AA18502
(InterLock SMTP Gateway 1.1 for vixie@pa.dec.com);
Tue, 19 Jan 1993 14:45:33 -0500
Received: by interlock.ans.net (Internal Mail Agent-2);
Tue, 19 Jan 1993 14:45:33 -0500
Received: by interlock.ans.net (Internal Mail Agent-1);
Tue, 19 Jan 1993 14:45:33 -0500
Date: Tue, 19 Jan 93 14:45:38 EST
From: Fuat Baran <fuat@ans.net>
To: vixie (Paul A Vixie)
Cc: fuat@ans.net
Phone: 914-789-5328, Fax: 914-789-5310
Subject: bind 4.9 beta instructions
Message-Id: <CMM.0.90.2.727472738.fuat@foo.ans.net>
Since it is almost time for the Beta announcement for BIND 4.9, I
thought I'd let you know how I compile BIND under AIX, in case you
want to add compilation instructions. (I'm assuming you'll resolve
the business of LIBC=/usr/lib/libc.a vs /lib/libc.a which cropped up
in the latest alpha.)
1) Make sure you have bsdcc configured (see also: /usr/lpp/bos/bsdport):
a) link /bin/xlc to /bin/bsdcc
b) add the following stanza to near the end of /etc/xlc.cfg
before the DEFLT stanza:
* BSD compatibility
bsdcc: use = DEFLT
crt = /lib/crt0.o
mcrt = /lib/mcrt0.o
gcrt = /lib/gcrt0.o
libraries = -lbsd, -lc
proflibs = -L/lib/profiled,-L/usr/lib/profiled
options = -H512,-T512,-qlanglvl=extended,-qnoro,-D_BSD,-D_NONSTD_TYPES,-D_NO_PROTO,-D_BSD_INCLUDES,-bnodelcsect,-U__STR__,-U__MATH__
2) In the top level bind directory:
make CC="bsdcc -DBSD=43" all
Note: If you prefer, you can either add a "-DBSD=43" to the bsdcc
stanza (in the options section), or create a similar stanza with it
(e.g. call it bsdcc43 and make the symlink to /bin/bsdcc43). Then you
can do a "make CC=bsdcc43" instead.
--Fuat

66
usr.sbin/named/doc/info/AIX.bsdcc Normal file
View File

@ -0,0 +1,66 @@
Received: by gw.home.vix.com id AA20833; Sun, 3 Jul 94 23:08:01 -0700
Received: by gate1.ks.se id AA06485
(5.67b/IDA-1.5 for <paul@vix.com>); Mon, 4 Jul 1994 08:11:40 +0200
Received: from patricia.ks.se(136.155.37.10) by gate1.ks.se via smap (V1.3mjr)
id sma006482; Mon Jul 4 08:11:07 1994
Received: from grodan.data.ks.se by patricia.ks.se with SMTP id AA07920
(5.67a/IDA-1.5 for <paul@vix.com>); Mon, 4 Jul 1994 08:15:49 +0200
Received: by grodan.data.ks.se (AIX 3.2/UCB 5.64/4.03)
id AA73470; Mon, 4 Jul 1994 08:05:02 +0100
Date: Mon, 4 Jul 1994 08:05:01 +0100 (NFT)
From: Urban Kaveus <uka@data.ks.se>
Sender: Urban Kaveus <uka@data.ks.se>
Reply-To: Urban Kaveus <uka@data.ks.se>
Subject: Re: 4.9.3-beta4 private release (includes beta3-beta4 patch)
To: Paul A Vixie <paul@vix.com>
Cc: Rikard Anderljung <ran@data.ks.se>
In-Reply-To: <9407020153.AA21510@gw.home.vix.com>
Message-Id: <Pine.3.89.9407040756.D20848-0100000@grodan.data.ks.se>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
On Fri, 1 Jul 1994, Paul A Vixie wrote:
> <sys/param.h> is supposed to include <sys/types.h>. i take it yours doesn't?
Hi again !
Thanks a lot ! You gave me the clue to the AIX C compiler flags !
The top level Makefile says "Supid AIX" and defines "bsdcc" as the compiler
to use. Now, there is no such thing as a bsdcc compiler on a vanilla AIX
system. You have to create a link named bsdcc pointing at your
original C compiler named xlc and create a "flavour entry" in your xlc.cfg
file :
* Berkeley style compiler. Added 931221 by Urban K.
bsdcc: use = DEFLT
crt = /lib/crt0.o
mcrt = /lib/mcrt0.o
gcrt = /lib/gcrt0.o
libraries = -lbsd, -lc
proflibs = -L/lib/profiled,-L/usr/lib/profiled
options = -H512,-T512, -qlanglvl=extended, -qnoro,
-D_BSD, -D_NONSTD_TYPES, -D_NO_PROTO,
-bnodelcsect, -U__STR__, -U__MATH__
Of course you are right, <sys/param.h> DO include <sys/types.h> if the
_BSD flag is set.
Our problem was that we broke the configuration entry in xlc.cfg into
several lines. That has been done in all other AIX configuration files so
why not in this one ?
But it did not work, we did not get the _BSD flag set and we did not
even get warned about the configuration mistake.
Your clue togheter with the inctree perl program lead us right. Thanks !
Now, the BETA 6 compiles like a charm with no changes at all.
Yours
Urban Kaveus <uka@data.ks.se>
dataavdelningen
Karolinska Hospital
S-171 76 Stockholm
Sweden

73
usr.sbin/named/doc/info/AIX.bsdcc.too Normal file
View File

@ -0,0 +1,73 @@
Delivery-Date: Thu, 29 Jun 1995 06:31:21 -0700
Return-Path: matthew@noc.ans.net
Received: by gw.home.vix.com id AA13055; Thu, 29 Jun 95 06:31:20 -0700
Received: by bugsy.aa.ans.net id AA46918
(5.65c/IDA-1.4.4 for paul@vix.com); Thu, 29 Jun 1995 09:31:18 -0400
Message-Id: <199506291331.AA46918@bugsy.aa.ans.net>
From: Matthew Braun <matthew@ans.net>
Date: Thu, 29 Jun 1995 09:31:18 -0400
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: Paul A Vixie <paul@vix.com>
Subject: Re: Matthew Braun: bind-4.9.3-BETA21 bug report
Cc: bind@uunet.uu.net
Paul A Vixie <paul@vix.com> on Thu, 29 Jun 1995 1:24 writes:
> this message will appear as doc/info/AIX.too in BIND 4.9.3-BETA22.
>
> ------- Forwarded Message
>
> From: matthew@ans.net (Matthew Braun)
> Subject: bind-4.9.3-BETA21 bug report
> Date: 28 Jun 1995 11:39:14 -0700
> X-To: bind@uunet.uu.net
>
> Hi-
>
> When trying to compile bind on an AIX 3.2.5 box I had a technically easy
> but annoyingly tedious problem that I needed to fix to make the code
> compile.
>
> First of all, the Makefile has bsdcc in it for AIX, which I don't have
> and didn't really need. Note the Makefile patch probably won't work
> correctly cause I didn't have a virgin copy of the original Makefile, so
> you'll have to look at that manually.
As pointed out by a few people, the problem I had with the headers went
away when I used bsdcc (which needed to be configured by changing a
config file). Although it would be nice if you didn't need to use bsdcc
and could just use cc on AIX.
I already sent the source changes, and here are the instructions for
configuring bsdcc.
make the link: ln /bin/xlc /bin/bsdcc.
add this to /etc/xlc.cfg (see info in /usr/lpp/bos/bsdport):
* BSD compatibility
bsdcc: use = DEFLT
crt = /lib/crt0.o
mcrt = /lib/mcrt0.o
gcrt = /lib/gcrt0.o
libraries = -lbsd, -lc
proflibs = -L/lib/profiled,-L/usr/lib/profiled
options = -H512,-T512,-qlanglvl=extended,-qnoro,-D_BSD,-D_NONSTD_TYPES,-D_NO_PROTO,-D_BSD_INCLUDES,-bnodelcsect,-U__STR__,-U__MATH__
Thanks to Linda Leibengood <ldl@ans.net> and Daryl Jones
<daryl@tcomeng.com>, both of who provided me with this information.
I never consulted the doc/info/AIX* files, or I would have found out
this information too. But I guess when I get a package I like to just
run configure or edit the Makefile and type 'make' and have it work. On
a vanilla AIX machine this is not the case. I guess I'm just spoiled.
Since the changes to the source code are minimal it would be nice to
have them put in. Or at the very least have the Makefile comments refer
to the doc/info/AIX* files for bsdcc info.
Anyway Paul, you decide what you want to do now knowing the both sides
of the story. I don't think including my long message with the patch is
that useful.
Matthew.

52
usr.sbin/named/doc/info/AIX.makefile Normal file
View File

@ -0,0 +1,52 @@
Received: by gw.home.vix.com id AA16867; Tue, 12 Jul 94 06:57:41 -0700
Received: (from ben@localhost) by mercure.inserm.fr (8.6.8/8.6.6) id PAA09612; Tue, 12 Jul 1994 15:57:09 +0200
Date: Tue, 12 Jul 1994 15:57:09 +0200
From: Benoit Grange <ben@tolbiac.inserm.fr>
Message-Id: <199407121357.PAA09612@mercure.inserm.fr>
To: paul@vix.com
Subject: Re: Make fails building bind on AIX
> what do you mean "separate" the all and clean targets?
In the Makefile, instead of :
----
all clean depend:: FRC
@for x in $(SUBDIRS); do \
(cd $$x; pwd; $(MAKE) $(MARGS) $@); \
done
clean:: FRC
-test -d doc/bog && (cd doc/bog; pwd; $(MAKE) $(MARGS) $@)
(cd conf; rm -f *~ *.CKP *.BAK *.orig)
rm -f *~ *.CKP *.BAK *.orig
...
----
I write :
----
all :: FRC
@for x in $(SUBDIRS); do \
(cd $$x; pwd; $(MAKE) $(MARGS) $@); \
done
clean:: FRC
@for x in $(SUBDIRS); do \
(cd $$x; pwd; $(MAKE) $(MARGS) $@); \
done
-test -d doc/bog && (cd doc/bog; pwd; $(MAKE) $(MARGS) $@)
(cd conf; rm -f *~ *.CKP *.BAK *.orig)
rm -f *~ *.CKP *.BAK *.orig
depend:: FRC
@for x in $(SUBDIRS); do \
(cd $$x; pwd; $(MAKE) $(MARGS) $@); \
done
--------------------
Anyway, all this is because of the buggy make supplied
with AIX.
Benoit Grange.

87
usr.sbin/named/doc/info/AIX.mkdep Normal file
View File

@ -0,0 +1,87 @@
Delivery-Date: Fri, 13 Jan 1995 15:25:29 -0800
Received: by gw.home.vix.com id AA12815; Fri, 13 Jan 95 15:25:01 -0800
Received: from handlebar.weeg.uiowa.edu by ns-mx.uiowa.edu (8.6.8.2/19940322)
on Fri, 13 Jan 1995 17:24:52 -0600 id RAA11266 with ESMTP
Received: from handlebar.weeg.uiowa.edu by handlebar.weeg.uiowa.edu (8.6.8.2/930730)
on Fri, 13 Jan 1995 17:24:43 -0600 id RAA13375 with SMTP
Message-Id: <199501132324.RAA13375@handlebar.weeg.uiowa.edu>
To: paul@vix.com (Paul A Vixie)
Reply-To: Jay Ford <jay-ford@uiowa.edu>
Subject: problem building BIND 4.9.3 BETA17 for AIX
Date: Fri, 13 Jan 95 17:24:40 CST
From: Jay Ford <jnford@handlebar.weeg.uiowa.edu>
You wrote:
> From: paul@vix.com (Paul A Vixie)
> Subject: BIND 4.9.3 BETA17 is available for public testing
> Date: 12 Jan 95 15:35:27
> Organization: Vixie Enterprises
>
> Please take a minute to make sure this thing still builds and runs on your
> offbrand backroom boxes. I want to rename it to "4.9.3-Rel" with no further
> patches, and I will, unless someone speaks up pretty quickly about a problem
> that is pretty serious.
I tried building this on an RS/6000 running AIX 3.2.5, and had some trouble.
First, the AIX compiler thinks -M means to generate a *.u file containing the
dependencies for each source file. I hacked mkdep to deal with this, but it
could probably be done in a nicer way. Anyway, the diffs are:
==============================================================================
*** mkdep Sun May 2 19:34:57 1993
--- mkdep.aix Fri Jan 13 16:39:23 1995
***************
*** 92,99 ****
trap 'rm -f $TMP ; exit 1' 1 2 3 13 15
! cc -M $* |
! sed "
s; \./; ;g
/\.c:$/d
$SED" |
--- 92,99 ----
trap 'rm -f $TMP ; exit 1' 1 2 3 13 15
! bsdcc -M -P $*
! cat *.u | sed "
s; \./; ;g
/\.c:$/d
$SED" |
***************
*** 116,121 ****
--- 116,122 ----
END {
print rec
}' > $TMP
+ rm *.[iu]
if [ $? != 0 ]; then
echo 'mkdep: compile failed.'
==============================================================================
Second, the order of the directives on line 485 in the top-level make file
caused some strange behavior. The order of "all clean depend" caused the AIX
make to do exactly that: make all, make clean, make depend. Needless to say,
the results are less that ideal: built then deleted binaries, but updated
dependencies! Changing the order to "clean depend all" had the desired effect.
I don't know what this order change would do to other systems, but it seems to
be required for AIX. Use this information as you see fit.
Other than those two AIX-specific problems I have had no trouble.
Also, I noticed that the default for INVQ has changed back to "off". Is this
still a problem for the 2 packages which used to do inverse queries?
Thanks.
------------------------------------------------------------------------
Jay Ford, Network Services Group, Information Networks
University of Iowa, Iowa City, IA 52242
email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-5505
"I have a 900 MHz brain." -Pete Brokaw, Nov 4, 1994

525
usr.sbin/named/doc/info/AIX.too Normal file
View File

@ -0,0 +1,525 @@
Path: vixie!pa.dec.com!bind-redist-request
From: matthew@ans.net (Matthew Braun)
Newsgroups: local.mail.dns.bind
Subject: bind-4.9.3-BETA21 bug report
Date: 28 Jun 1995 11:39:14 -0700
Organization: Vixie Enterprises
Lines: 497
Sender: daemon@vix.com
Distribution: local
Message-ID: <199506281639.AA182663@bugsy.aa.ans.net>
NNTP-Posting-Host: gw.home.vix.com
X-Received: by gw.home.vix.com id AA02727; Wed, 28 Jun 95 11:39:12 -0700
X-Received: from pobox1.pa.dec.com by inet-gw-2.pa.dec.com (5.65/24Feb95)
id AA27581; Wed, 28 Jun 95 10:15:51 -0700
X-Received: by pobox1.pa.dec.com; id AA06397; Wed, 28 Jun 95 10:15:43 -0700
X-Received: by pobox1.pa.dec.com; id AA06393; Wed, 28 Jun 95 10:15:42 -0700
X-Received: from relay3.UU.NET by inet-gw-1.pa.dec.com (5.65/24Feb95)
id AA25444; Wed, 28 Jun 95 10:06:01 -0700
X-Received: by relay3.UU.NET
id QQywcg10382; Wed, 28 Jun 1995 12:39:36 -0400
X-Received: from bugsy.aa.ans.net by relay3.UU.NET with SMTP
id QQywcg10353; Wed, 28 Jun 1995 12:39:32 -0400
X-Received: by bugsy.aa.ans.net id AA182663
(5.65c/IDA-1.4.4 for bind@uunet.uu.net); Wed, 28 Jun 1995 12:39:12 -0400
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
X-To: bind@uunet.uu.net
X-Cc: Bryan Beecher <bryan@noc.ans.net>
Hi-
When trying to compile bind on an AIX 3.2.5 box I had a technically easy
but annoyingly tedious problem that I needed to fix to make the code
compile.
First of all, the Makefile has bsdcc in it for AIX, which I don't have
and didn't really need. Note the Makefile patch probably won't work
correctly cause I didn't have a virgin copy of the original Makefile, so
you'll have to look at that manually.
The tedious problem that I had to fix was adding a '#include
<sys/types.h>' to lots of *.c files and a few '#include <sys/select.h'
to others. After adding these statements the code compiled very
cleanly.
Note, this is not the most ideal way of fixing this problem and I have
no idea if this will break other platforms (it shouldn't though).
Another idea might to be to add a #include "pre-portability.h" to the
begining of the #include's in each source file, where hacks for crapy
OS's like AIX can be put in.
What I don't understand is that the RUNSON file says "compiles and runs"
for AIX 3.2.5, but it didn't for me without changing a bunch of files.
Hope this will help someone else.
Cheers,
Matthew.
=====
diff -cr bind-4.9.3-BETA21/Makefile bind-4.9.3-BETA21.mod/Makefile
*** bind-4.9.3-BETA21/Makefile Thu Jun 22 09:22:39 1995
--- bind-4.9.3-BETA21.mod/Makefile Wed Jun 28 11:53:44 1995
***************
*** 267,279 ****
#(AIX3)
#CC = bsdcc $(CPPFLAGS)
! #CPPFLAGS = -DBSD=43
! #LIBS = -ll
! #DESTEXEC = /usr/sbin
! #INSTALL = /usr/ucb/install
! #CATEXT = $$$$N
! #LEX = lex
! #PS = ps -p
# (ConvexOS-10.x)
#CC = gcc $(CPPFLAGS) -g -O2 -fpcc-struct-return -fno-builtin -funsigned-char
--- 267,281 ----
#(AIX3)
#CC = bsdcc $(CPPFLAGS)
! CC = cc
! CDEBUG = -O
! CPPFLAGS = -DBSD=43
! LIBS = -ll -lbsd
! DESTEXEC = /usr/sbin
! INSTALL = /usr/ucb/install
! CATEXT = $$$$N
! LEX = lex
! PS = ps -p
# (ConvexOS-10.x)
#CC = gcc $(CPPFLAGS) -g -O2 -fpcc-struct-return -fno-builtin -funsigned-char
diff -cr bind-4.9.3-BETA21/named/Makefile bind-4.9.3-BETA21.mod/named/Makefile
*** bind-4.9.3-BETA21/named/Makefile Mon Jun 19 04:34:49 1995
--- bind-4.9.3-BETA21.mod/named/Makefile Mon Jun 26 12:03:59 1995
***************
*** 84,90 ****
PIDDIR = /var/run
CC= cc
SHELL= /bin/sh
! CDEBUG= -g
LIBS=
COMPLIB= ../compat/lib/lib44bsd.a
PATH_XFER = ${DESTEXEC}/${XFER_INDOT}named-xfer
--- 84,90 ----
PIDDIR = /var/run
CC= cc
SHELL= /bin/sh
! CDEBUG= -O
LIBS=
COMPLIB= ../compat/lib/lib44bsd.a
PATH_XFER = ${DESTEXEC}/${XFER_INDOT}named-xfer
diff -cr bind-4.9.3-BETA21/named/db_lookup.c bind-4.9.3-BETA21.mod/named/db_lookup.c
*** bind-4.9.3-BETA21/named/db_lookup.c Thu Dec 15 01:24:16 1994
--- bind-4.9.3-BETA21.mod/named/db_lookup.c Mon Jun 26 11:22:16 1995
***************
*** 62,67 ****
--- 62,68 ----
* Table lookup routines.
*/
+ #include <sys/types.h>
#include <syslog.h>
#include <sys/param.h>
#include <sys/socket.h>
diff -cr bind-4.9.3-BETA21/named/db_reload.c bind-4.9.3-BETA21.mod/named/db_reload.c
*** bind-4.9.3-BETA21/named/db_reload.c Thu Dec 15 01:24:16 1994
--- bind-4.9.3-BETA21.mod/named/db_reload.c Mon Jun 26 11:22:45 1995
***************
*** 58,63 ****
--- 58,64 ----
* --Copyright--
*/
+ #include <sys/types.h>
#include <sys/param.h>
#include <sys/socket.h>
#include <netinet/in.h>
diff -cr bind-4.9.3-BETA21/named/db_save.c bind-4.9.3-BETA21.mod/named/db_save.c
*** bind-4.9.3-BETA21/named/db_save.c Thu Dec 15 01:24:16 1994
--- bind-4.9.3-BETA21.mod/named/db_save.c Mon Jun 26 11:23:12 1995
***************
*** 62,67 ****
--- 62,68 ----
* Buffer allocation and deallocation routines.
*/
+ #include <sys/types.h>
#include <sys/param.h>
#include <sys/socket.h>
#include <netinet/in.h>
diff -cr bind-4.9.3-BETA21/named/ns_forw.c bind-4.9.3-BETA21.mod/named/ns_forw.c
*** bind-4.9.3-BETA21/named/ns_forw.c Mon Jun 19 16:55:44 1995
--- bind-4.9.3-BETA21.mod/named/ns_forw.c Mon Jun 26 11:24:20 1995
***************
*** 58,63 ****
--- 58,64 ----
* --Copyright--
*/
+ #include <sys/types.h>
#include <sys/param.h>
#include <sys/socket.h>
#include <netinet/in.h>
diff -cr bind-4.9.3-BETA21/named/ns_init.c bind-4.9.3-BETA21.mod/named/ns_init.c
*** bind-4.9.3-BETA21/named/ns_init.c Tue Jun 20 19:34:47 1995
--- bind-4.9.3-BETA21.mod/named/ns_init.c Mon Jun 26 11:24:36 1995
***************
*** 58,63 ****
--- 58,64 ----
* --Copyright--
*/
+ #include <sys/types.h>
#include <sys/param.h>
#include <sys/socket.h>
#include <sys/stat.h>
diff -cr bind-4.9.3-BETA21/named/ns_main.c bind-4.9.3-BETA21.mod/named/ns_main.c
*** bind-4.9.3-BETA21/named/ns_main.c Tue Jun 20 19:58:53 1995
--- bind-4.9.3-BETA21.mod/named/ns_main.c Mon Jun 26 11:26:48 1995
***************
*** 70,75 ****
--- 70,76 ----
* Internet Name server (see rfc883 & others).
*/
+ #include <sys/select.h>
#include <sys/param.h>
#include <sys/file.h>
#include <sys/stat.h>
diff -cr bind-4.9.3-BETA21/named/ns_ncache.c bind-4.9.3-BETA21.mod/named/ns_ncache.c
*** bind-4.9.3-BETA21/named/ns_ncache.c Thu Jul 21 04:17:43 1994
--- bind-4.9.3-BETA21.mod/named/ns_ncache.c Mon Jun 26 11:30:47 1995
***************
*** 6,11 ****
--- 6,12 ----
* implements negative caching
*/
+ #include <sys/types.h>
#include <sys/param.h>
#include <sys/socket.h>
#include <sys/file.h>
diff -cr bind-4.9.3-BETA21/named/ns_req.c bind-4.9.3-BETA21.mod/named/ns_req.c
*** bind-4.9.3-BETA21/named/ns_req.c Tue Jun 20 19:58:55 1995
--- bind-4.9.3-BETA21.mod/named/ns_req.c Mon Jun 26 11:28:48 1995
***************
*** 58,63 ****
--- 58,64 ----
* --Copyright--
*/
+ #include <sys/types.h>
#include <sys/param.h>
#include <sys/uio.h>
#include <sys/file.h>
diff -cr bind-4.9.3-BETA21/named/ns_resp.c bind-4.9.3-BETA21.mod/named/ns_resp.c
*** bind-4.9.3-BETA21/named/ns_resp.c Tue Jun 20 03:43:09 1995
--- bind-4.9.3-BETA21.mod/named/ns_resp.c Mon Jun 26 11:29:09 1995
***************
*** 58,63 ****
--- 58,64 ----
* --Copyright--
*/
+ #include <sys/types.h>
#include <sys/param.h>
#include <sys/socket.h>
#include <sys/file.h>
diff -cr bind-4.9.3-BETA21/named/ns_stats.c bind-4.9.3-BETA21.mod/named/ns_stats.c
*** bind-4.9.3-BETA21/named/ns_stats.c Mon Jun 19 04:34:58 1995
--- bind-4.9.3-BETA21.mod/named/ns_stats.c Mon Jun 26 11:29:38 1995
***************
*** 63,68 ****
--- 63,69 ----
/* dumps a bunch of values into a well-known file */
/**************************************************************************/
+ #include <sys/types.h>
#include <sys/param.h>
#include <netinet/in.h>
#include <arpa/nameser.h>
diff -cr bind-4.9.3-BETA21/named/ns_validate.c bind-4.9.3-BETA21.mod/named/ns_validate.c
*** bind-4.9.3-BETA21/named/ns_validate.c Mon Jun 19 02:48:07 1995
--- bind-4.9.3-BETA21.mod/named/ns_validate.c Mon Jun 26 11:29:51 1995
***************
*** 7,12 ****
--- 7,13 ----
* response to a query.
*/
+ #include <sys/types.h>
#include <sys/param.h>
#include <sys/socket.h>
#include <sys/file.h>
diff -cr bind-4.9.3-BETA21/res/gethnamaddr.c bind-4.9.3-BETA21.mod/res/gethnamaddr.c
*** bind-4.9.3-BETA21/res/gethnamaddr.c Tue Jun 20 19:58:57 1995
--- bind-4.9.3-BETA21.mod/res/gethnamaddr.c Mon Jun 26 11:18:58 1995
***************
*** 58,63 ****
--- 58,64 ----
static char rcsid[] = "$Id: AIX.too,v 1.1.1.1 1997/04/13 09:08:04 mrg Exp $";
#endif /* LIBC_SCCS and not lint */
+ #include <sys/types.h>
#include <sys/param.h>
#include <sys/socket.h>
#include <netinet/in.h>
diff -cr bind-4.9.3-BETA21/res/getnetent.c bind-4.9.3-BETA21.mod/res/getnetent.c
*** bind-4.9.3-BETA21/res/getnetent.c Mon Jun 19 04:35:01 1995
--- bind-4.9.3-BETA21.mod/res/getnetent.c Mon Jun 26 11:17:47 1995
***************
*** 46,51 ****
--- 46,52 ----
static char rcsid[] = "$Id: AIX.too,v 1.1.1.1 1997/04/13 09:08:04 mrg Exp $";
#endif /* LIBC_SCCS and not lint */
+ #include <sys/types.h>
#include <sys/param.h>
#include <sys/socket.h>
#include <netinet/in.h>
diff -cr bind-4.9.3-BETA21/res/getnetnamadr.c bind-4.9.3-BETA21.mod/res/getnetnamadr.c
*** bind-4.9.3-BETA21/res/getnetnamadr.c Tue Jun 20 03:43:10 1995
--- bind-4.9.3-BETA21.mod/res/getnetnamadr.c Mon Jun 26 11:18:05 1995
***************
*** 44,49 ****
--- 44,50 ----
static char rcsid[] = "$Id: AIX.too,v 1.1.1.1 1997/04/13 09:08:04 mrg Exp $";
#endif /* LIBC_SCCS and not lint */
+ #include <sys/types.h>
#include <sys/param.h>
#include <sys/socket.h>
#include <netinet/in.h>
diff -cr bind-4.9.3-BETA21/res/herror.c bind-4.9.3-BETA21.mod/res/herror.c
*** bind-4.9.3-BETA21/res/herror.c Mon Jun 19 04:35:02 1995
--- bind-4.9.3-BETA21.mod/res/herror.c Mon Jun 26 11:05:11 1995
***************
*** 58,63 ****
--- 58,64 ----
static char rcsid[] = "$Id: AIX.too,v 1.1.1.1 1997/04/13 09:08:04 mrg Exp $";
#endif /* LIBC_SCCS and not lint */
+ #include <sys/types.h>
#include <sys/param.h>
#include <sys/uio.h>
#include <netdb.h>
diff -cr bind-4.9.3-BETA21/res/inet_addr.c bind-4.9.3-BETA21.mod/res/inet_addr.c
*** bind-4.9.3-BETA21/res/inet_addr.c Mon Jun 19 16:55:50 1995
--- bind-4.9.3-BETA21.mod/res/inet_addr.c Mon Jun 26 11:19:53 1995
***************
*** 58,63 ****
--- 58,64 ----
static char rcsid[] = "$Id: AIX.too,v 1.1.1.1 1997/04/13 09:08:04 mrg Exp $";
#endif /* LIBC_SCCS and not lint */
+ #include <sys/types.h>
#include <sys/param.h>
#include <netinet/in.h>
#include <arpa/inet.h>
diff -cr bind-4.9.3-BETA21/res/nsap_addr.c bind-4.9.3-BETA21.mod/res/nsap_addr.c
*** bind-4.9.3-BETA21/res/nsap_addr.c Mon Jun 19 04:35:02 1995
--- bind-4.9.3-BETA21.mod/res/nsap_addr.c Mon Jun 26 11:19:40 1995
***************
*** 2,7 ****
--- 2,8 ----
static char rcsid[] = "$Id: AIX.too,v 1.1.1.1 1997/04/13 09:08:04 mrg Exp $";
#endif /* LIBC_SCCS and not lint */
+ #include <sys/types.h>
#include <sys/param.h>
#include <sys/socket.h>
#include <netinet/in.h>
diff -cr bind-4.9.3-BETA21/res/res_comp.c bind-4.9.3-BETA21.mod/res/res_comp.c
*** bind-4.9.3-BETA21/res/res_comp.c Mon Jun 19 04:35:02 1995
--- bind-4.9.3-BETA21.mod/res/res_comp.c Mon Jun 26 11:12:42 1995
***************
*** 58,63 ****
--- 58,64 ----
static char rcsid[] = "$Id: AIX.too,v 1.1.1.1 1997/04/13 09:08:04 mrg Exp $";
#endif /* LIBC_SCCS and not lint */
+ #include <sys/types.h>
#include <sys/param.h>
#include <netinet/in.h>
#include <arpa/nameser.h>
diff -cr bind-4.9.3-BETA21/res/res_debug.c bind-4.9.3-BETA21.mod/res/res_debug.c
*** bind-4.9.3-BETA21/res/res_debug.c Mon Jun 19 16:55:51 1995
--- bind-4.9.3-BETA21.mod/res/res_debug.c Mon Jun 26 11:07:47 1995
***************
*** 58,63 ****
--- 58,64 ----
static char rcsid[] = "$Id: AIX.too,v 1.1.1.1 1997/04/13 09:08:04 mrg Exp $";
#endif /* LIBC_SCCS and not lint */
+ #include <sys/types.h>
#include <sys/param.h>
#include <netinet/in.h>
#include <arpa/inet.h>
diff -cr bind-4.9.3-BETA21/res/res_init.c bind-4.9.3-BETA21.mod/res/res_init.c
*** bind-4.9.3-BETA21/res/res_init.c Mon Jun 19 04:35:03 1995
--- bind-4.9.3-BETA21.mod/res/res_init.c Mon Jun 26 11:13:07 1995
***************
*** 58,63 ****
--- 58,64 ----
static char rcsid[] = "$Id: AIX.too,v 1.1.1.1 1997/04/13 09:08:04 mrg Exp $";
#endif /* LIBC_SCCS and not lint */
+ #include <sys/types.h>
#include <sys/param.h>
#include <sys/socket.h>
#include <sys/time.h>
diff -cr bind-4.9.3-BETA21/res/res_mkquery.c bind-4.9.3-BETA21.mod/res/res_mkquery.c
*** bind-4.9.3-BETA21/res/res_mkquery.c Mon Jun 19 04:35:03 1995
--- bind-4.9.3-BETA21.mod/res/res_mkquery.c Mon Jun 26 11:13:30 1995
***************
*** 58,63 ****
--- 58,64 ----
static char rcsid[] = "$Id: AIX.too,v 1.1.1.1 1997/04/13 09:08:04 mrg Exp $";
#endif /* LIBC_SCCS and not lint */
+ #include <sys/types.h>
#include <sys/param.h>
#include <netinet/in.h>
#include <arpa/nameser.h>
diff -cr bind-4.9.3-BETA21/res/res_query.c bind-4.9.3-BETA21.mod/res/res_query.c
*** bind-4.9.3-BETA21/res/res_query.c Tue Jun 20 03:43:10 1995
--- bind-4.9.3-BETA21.mod/res/res_query.c Mon Jun 26 11:14:01 1995
***************
*** 58,63 ****
--- 58,64 ----
static char rcsid[] = "$Id: AIX.too,v 1.1.1.1 1997/04/13 09:08:04 mrg Exp $";
#endif /* LIBC_SCCS and not lint */
+ #include <sys/types.h>
#include <sys/param.h>
#include <netinet/in.h>
#include <arpa/inet.h>
diff -cr bind-4.9.3-BETA21/res/res_send.c bind-4.9.3-BETA21.mod/res/res_send.c
*** bind-4.9.3-BETA21/res/res_send.c Mon Jun 19 16:55:52 1995
--- bind-4.9.3-BETA21.mod/res/res_send.c Mon Jun 26 11:16:51 1995
***************
*** 69,74 ****
--- 69,75 ----
* Send query to name server and wait for reply.
*/
+ #include <sys/select.h>
#include <sys/param.h>
#include <sys/time.h>
#include <sys/socket.h>
diff -cr bind-4.9.3-BETA21/res/sethostent.c bind-4.9.3-BETA21.mod/res/sethostent.c
*** bind-4.9.3-BETA21/res/sethostent.c Mon Jun 19 04:35:04 1995
--- bind-4.9.3-BETA21.mod/res/sethostent.c Mon Jun 26 11:19:25 1995
***************
*** 36,41 ****
--- 36,42 ----
static char rcsid[] = "$Id: AIX.too,v 1.1.1.1 1997/04/13 09:08:04 mrg Exp $";
#endif /* LIBC_SCCS and not lint */
+ #include <sys/types.h>
#include <sys/param.h>
#include <netinet/in.h>
#include <arpa/nameser.h>
diff -cr bind-4.9.3-BETA21/tools/Makefile bind-4.9.3-BETA21.mod/tools/Makefile
*** bind-4.9.3-BETA21/tools/Makefile Tue Jun 20 19:58:58 1995
--- bind-4.9.3-BETA21.mod/tools/Makefile Mon Jun 26 12:04:21 1995
***************
*** 60,66 ****
CC= cc
SHELL= /bin/sh
! CDEBUG= -g
INCL = ../include
RES= ../res/libresolv.a
--- 60,66 ----
CC= cc
SHELL= /bin/sh
! CDEBUG= -O
INCL = ../include
RES= ../res/libresolv.a
diff -cr bind-4.9.3-BETA21/tools/nslookup/debug.c bind-4.9.3-BETA21.mod/tools/nslookup/debug.c
*** bind-4.9.3-BETA21/tools/nslookup/debug.c Thu Dec 15 01:24:31 1994
--- bind-4.9.3-BETA21.mod/tools/nslookup/debug.c Mon Jun 26 11:40:00 1995
***************
*** 70,75 ****
--- 70,76 ----
*******************************************************************************
*/
+ #include <sys/types.h>
#include <sys/param.h>
#include <netinet/in.h>
#include <arpa/nameser.h>
diff -cr bind-4.9.3-BETA21/tools/nslookup/getinfo.c bind-4.9.3-BETA21.mod/tools/nslookup/getinfo.c
*** bind-4.9.3-BETA21/tools/nslookup/getinfo.c Thu Dec 15 01:24:32 1994
--- bind-4.9.3-BETA21.mod/tools/nslookup/getinfo.c Mon Jun 26 11:39:40 1995
***************
*** 71,76 ****
--- 71,77 ----
******************************************************************************
*/
+ #include <sys/types.h>
#include <sys/param.h>
#include <sys/socket.h>
#include <netinet/in.h>
diff -cr bind-4.9.3-BETA21/tools/nslookup/list.c bind-4.9.3-BETA21.mod/tools/nslookup/list.c
*** bind-4.9.3-BETA21/tools/nslookup/list.c Mon Dec 19 03:35:16 1994
--- bind-4.9.3-BETA21.mod/tools/nslookup/list.c Mon Jun 26 11:42:47 1995
***************
*** 70,75 ****
--- 70,76 ----
*******************************************************************************
*/
+ #include <sys/types.h>
#include <sys/param.h>
#include <sys/socket.h>
#include <netinet/in.h>
diff -cr bind-4.9.3-BETA21/tools/nslookup/main.c bind-4.9.3-BETA21.mod/tools/nslookup/main.c
*** bind-4.9.3-BETA21/tools/nslookup/main.c Thu Dec 15 01:24:32 1994
--- bind-4.9.3-BETA21.mod/tools/nslookup/main.c Mon Jun 26 11:38:53 1995
***************
*** 79,84 ****
--- 79,85 ----
******************************************************************************
*/
+ #include <sys/types.h>
#include <sys/param.h>
#include <netdb.h>
#include <sys/socket.h>
diff -cr bind-4.9.3-BETA21/tools/nslookup/send.c bind-4.9.3-BETA21.mod/tools/nslookup/send.c
*** bind-4.9.3-BETA21/tools/nslookup/send.c Thu Dec 15 01:24:33 1994
--- bind-4.9.3-BETA21.mod/tools/nslookup/send.c Mon Jun 26 11:41:46 1995
***************
*** 75,80 ****
--- 75,81 ----
* Send query to name server and wait for reply.
*/
+ #include <sys/select.h>
#include <sys/param.h>
#include <sys/time.h>
#include <sys/socket.h>
diff -cr bind-4.9.3-BETA21/tools/nslookup/skip.c bind-4.9.3-BETA21.mod/tools/nslookup/skip.c
*** bind-4.9.3-BETA21/tools/nslookup/skip.c Thu Dec 15 01:24:33 1994
--- bind-4.9.3-BETA21.mod/tools/nslookup/skip.c Mon Jun 26 11:42:34 1995
***************
*** 75,80 ****
--- 75,81 ----
*******************************************************************************
*/
+ #include <sys/types.h>
#include <sys/param.h>
#include <netinet/in.h>
#include <arpa/nameser.h>

62
usr.sbin/named/doc/info/AIX3.2-yp Normal file
View File

@ -0,0 +1,62 @@
Return-Path: svpillay@berlioz.crs4.it
Received: by stuff.pa.dec.com; id AA23579; Wed, 26 May 93 10:51:09 -0700
Received: by inet-gw-1.pa.dec.com; id AA02488; Wed, 26 May 93 10:51:08 -0700
Received: by berlioz.crs4.it (AIX 3.2/UCB 5.64/4.03)
id AA95828; Wed, 26 May 1993 19:49:33 +0200
Message-Id: <9305261749.AA95828@berlioz.crs4.it>
Subject: BIND 4.9 and AIX3.2 ypserv conflict
To: bind@ucbarpa.berkeley.edu, comp.unix.aix@crs4gw.crs4.it
Date: Wed, 26 May 1993 19:49:33 +22311259 (DST)
From: Kanthan Pillay <svpillay@berlioz.crs4.it>
Cc: vixie
X-Mailer: ELM [version 2.4 PL11]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1752
Greetings
Configuration:
DNS server is Sparc 2 running SunOS 4.1.3, BIND 4.9
ypserver is IBM RS/6000-550 running AIX 3.2.3
Description of problem:
BIND 4.9 documentation recommends removal of "domain" directive in
/etc/named.boot, and disables support for this by default. However,
"ypserv" under AIX does not appear to automatically append the domain
name specified in /etc/resolv.conf to unqualified (i.e. local)
hostnames.
So, the following does work:
mozart# ypmatch schubert.crs4.it hosts
156.148.3.24 schubert.crs4.it
while the following does not:
mozart# ypmatch schubert hosts
ypmatch: 1831-150 Cannot match key schubert in map hosts.byname.
Reason: no such key in map.
Possible fixes:
1) Do not use AIX 3.2.x's ypserv. (This works correctly if a Sun is
the ypserver.)
or
2) Enable LOCALDOM in options.h, and add a domain directive to
named.boot.
Of course, if you have your local hosts in the NIS hosts map, you should
not have a problem. For ease of administration, we only use DNS and
"/usr/etc/yp/makedbm -b".
Kanthan Pillay
Unix Systems Administrator
C R S 4
Sardinia
* * * * *Centro di Ricerca, Sviluppo e Studi Superiori in Sardegna * * * * * *
* *
* Work: (39 70) 279-6264 Internet: svpillay@crs4.it *
* Home: (39 70) 89-2334 Bitnet: SVPILLAY@ICRS4VM *
* Fax: (39 70) 279-6220 uucp: princeton!crs4!svpillay *
* Snail: Via Nazario Sauro, 10 - 09123 Cagliari, Italy *
* *
* * * Centre for Advanced Studies, Research, and Development in Sardinia * * *

60
usr.sbin/named/doc/info/AIX4 Normal file
View File

@ -0,0 +1,60 @@
Received: by gw.home.vix.com id AA10810; Thu, 28 Dec 95 13:22:40 -0800
Received: by gw.home.vix.com id AA10806; Thu, 28 Dec 95 13:22:39 -0800
Received: by wisdom.home.vix.com id AA07401; Thu, 28 Dec 1995 13:22:39 -0800
Message-Id: <9512282122.AA07401@wisdom.home.vix.com>
To: bind-workers@vix.com
Subject: BIND on AIX 4 -- anybody got a problem with this?
Date: Thu, 28 Dec 1995 13:22:39 -0800
From: Paul A Vixie <paul@vix.com>
------- Forwarded Message
...
Here's what it took to build BIND on AIX Version 4.
Beta bind 4.9.3 Patch level 32
AIX 4.1.4 with most IBM patches applied
PowerPC C10 Hardware
Building on AIX Version 4
top level Makefile
line 328 add an addition library so that 'vfork' is available
<LIBS = -ll -lbsd
>LIBS = -ll -lbsd
These files need to include select.h
res/res_send.c
named/ns_main.c
tools/nslookup/send.c
#ifdef (_AIX)
#include <sys/select.h>
#endif
These aix include files need to include <sys/types.h> or a bigger sweep
through the bind source needs to done so ensure that types.h is included
before these.
include/netinet/in.h
include/sys/sockets.h
#include <sys/types.h>
Resolver library Makefile
I was surprised to find ld begin called directly in the makefile.
ld should be replaced with $(LD) and LD should
be defined in the top level Makefile. The gnu ld fails on res_debug.o
so $(LD) should point to the AIX version in /usr/bin/ld.
------- End of Forwarded Message

20
usr.sbin/named/doc/info/AUX Normal file
View File

@ -0,0 +1,20 @@
Date: Sun, 5 Mar 1995 21:50:45 -0600 (CST)
From: Phillip Porch <root@theporch.com>
To: Paul Vixie <paul@vix.com>
Subject: Re: Help! bind-4.9.3-BETA17 (fwd)
Message-Id: <Pine.AUX.3.91.950305214732.579A-100000@uro.theporch.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Paul, I had forgotten that a long time ago, I discovered that starting
named from the inittab under A/UX didn't work. I kept getting a message
that it was a "socket operation on a non-socket". Named works fine if
your start it from the /etc/rc file. Could you add a note for A/UX users
that they need to disable named starting from /etc/inittab and instead
start it from /etc/rc?
Thanks.
--
Phillip P. Porch <root@theporch.com> NIC:PP1573
http://www.theporch.com UTM - 16 514548E 3994397N

4
usr.sbin/named/doc/info/Cisco Normal file
View File

@ -0,0 +1,4 @@
|Also, are you interested in accepting T_NSAP and T_NSAP_PTR support
|patches? If so, I have placed them for anonymous FTP in
|
| ftp.cisco.com:/ftp/bind/4.9.2-beta5-nsap-diffs

26
usr.sbin/named/doc/info/History Normal file
View File

@ -0,0 +1,26 @@
This feature was once OPTIONal:
CRED (origin: Paul Vixie of Digital)
enables a system of "credibility checking" on all data in the memory-
resident database. every RR that comes in will be tagged with a credibility
index with zone files being highest, followed by authoritative answers, then
non-authoritative answers, then finally by additional data. when any RR is
being added to a node ("name") in the database, all RR's of that type with a
lower credibility index will be flushed. this tends to do away with additional
data, which is one of the greatest sources of database pollution in the DNS.
data that comes in with lower credibility than what we already have is ignored.
with CRED enabled, additional data is deprecated such that every
time an additional-data RR is used, its Time To Live (TTL) is multiplied by
0.95, effectively lowering it by 5% of its current value. this causes
additional data to be timed out rather quickly, and as soon as it times
out, a sysquery() will be sent to some authoritative server, which in turn
results in a real live answer which tends to lock out future additional
data on that <name,type> tuple.
due to source dependencies, CRED also controls a bug fix that keeps
all sysquery() responses from being entered into the "root cache". you can
see the effect of this by dumping your database to disk with SIGINT and
looking at the bottom of the file. try it with and without CRED, letting a
few million queries through first. without CRED, you'll see a bunch of
non-root junk in the section of the dump that is reserved for the "hints".
you probably want this.

104
usr.sbin/named/doc/info/Linux Normal file
View File

@ -0,0 +1,104 @@
Date: Mon, 22 May 1995 10:19:51 -0700 (PDT)
>From: John Kennedy <warlock@csuchico.edu>
Message-Id: <199505221719.KAA10941@menkure.net.CSUChico.EDU>
To: BIND workers <bind-workers@vix.com>
Subject: doc/info/linux* update
05/22/95 @ 10:17:12 AM (Monday)
Paul, this can supersede the current doc/info/Linux* files. It has
everything Matt and I noticed (Matt never did get in contact with me...)
but leaves out Charles Lopes's patches (which are horribly out of date
and unnecessary anyway).
--- john
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
05/22/95 @ 10:12:13 AM (Monday)
This is my continuing summary of BIND/linux porting issues. As usual,
linux is a moving target and this information will be outdated as soon as
it gets included into the source, so some adaptation may be required by the
time you use it.
BIND is known to compile well on linux with GCC since version 2.5.8 and
well through 2.6.4 (snapshot 950518), give or take a few warnings. It has
worked, for better or worse, on kernels 1.1.29 (and earlier) through the
current 1.2.8. The binutils used have gone from 2.5.2 through the current
ELF-enhanced 2.5.2l.15 (not released to the public yet, so you'll probably
see something newer when it comes out).
Most of the BIND-related complications have been because of the libraries
and the header files distributed with them. Therefor this will be indexed
primarily by libc version and the problems with them:
Jul `94, libc ~4.5.26, kernel ~1.1.29
Delete/rename/compress compat/include/sys/cdefs.h header file.
The linux <sys/cdefs.h> has been good enough for BIND for
all of the versions that I've ever tested it with.
The <sys/param.h> header needs to #include <sys/types.h>. It
does on a lot of other system types and BIND assumes that
it does on linux as well. There are a number of ways to
fix this: (A) modify the header file directly, (B) make
a local compat "param.h" file that has these lines:
#include <sys/types.h>
#include_next <sys/param.h>
(B) only fixes the problem for BIND, but it doesn't require
you to modify your system's include files.
Dec `94, libc 4.6.20, kernel ~1.1.70
The header file <sys/types.h> is officially included in
<sys/param.h>. You still need to nuke BIND's "cdefs.h".
May `95, libc ~4.7.2 & 5.0.9, kernel ~1.2.8
You still need to nuke BIND's "cdefs.h". I haven't tried to
compile it with the 4.7 libc since it's supposed to be
bug-fixes on top of the final a.out 4.6 series. The
5.0 series is the ELF release and I haven't found any
complications caused by the libraries.
If you have multiple architecures (e.g. used "make links"), you will need
to take care when disabling compat/include/sys/cdefs.h as compat/include is
a shared directory. You will need something like
for d in compat/include compat/include/sys
do rm $d && mkdir $d && ln -s SRC/$d/* $d/.
done
mv compat/include/sys/cdefs.h compat/include/sys/cdefs.h.dist
If you want to make a dynamic resolv library with ELF, you can use a
Makefile like the one below (modifying the VER sting to match the version
you happen to be compiling at the time). The source files are from the res
directory but should include everything that goes into libresolv.a, so make
sure everything gets included in later versions of BIND before you complain
to the list (or at least complain to me first). When I made my ELF system
I crippled the default resolver library and remade the system using a
dynamic resolv library. No problems yet. Beware mixing the standard
header files with BIND's, which may get you in more or less trouble
depending on your version of libc and BIND.
--- john
<warlock@csuchico.edu>
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
VER= 4.9.3.17
INC= -I../include -I../compat/include
DEF= -DUSE_OPTIONS_H
CFLAGS= -O -fPIC ${INC} ${DEF}
LIB= libresolv.so.${VER}
SRCS= herror.c res_debug.c \
res_comp.c res_init.c res_mkquery.c res_query.c res_send.c \
getnetbyaddr.c getnetbyname.c getnetent.c getnetnamadr.c \
gethnamaddr.c sethostent.c nsap_addr.c
OBJS= ${SRCS:.c=.o}
${LIB}: ${OBJS}
${CC} -shared -o $@ -Wl,-soname,$@ ${OBJS}
${OBJS}:
${CC} ${CPPFLAGS} ${CFLAGS} -c ../res/$*.c
-${LDS} ld -x -r $*.o
${LDS} mv a.out $*.o
clean:
rm ${OBJS} libresolv*
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

361
usr.sbin/named/doc/info/Linux-elf Normal file
View File

@ -0,0 +1,361 @@
-----------------------------------------
bind-4.9.4-P1.ELF.shared.patch.new.gz
-----------------------------------------
This is a corrected and revised release of the previous patch,
which should make bind-4.9.4-P1 to compile under Linux with
ELF/shared support.
Mea Culpa! In the previous patch I simply forgot not to include
my "/h/src/" directory structure. I am sorry.
This is one change (well, should be a big one...), but there are
others as well:
Thanks to Manuel J. Galan Moreno (root@mgmux.step.es) some
adjustments has been made to it:
- bind's specific header files moved to /usr/include/4.9.4/
so this does not produce incompatibilities with the standard
(original) header files.
- GCC now called with "-O2 -fno-strength-reduce" because of a
known bug in gcc-2.7.2.
- h_errno is no longer redifined
- there is an explicit link for libresolv (for the new binutils)
- man pages are installed _unformatted /usr/man
bind-4.9.4-P1 is compiled and tested with this patch on
Linux-2.0.12 with libc-5.2.18 and gcc-2.7.2. It is currently
running on my machine and seems to good so far.
Good luck!
Tamas Nyitrai
defiant@mail.datanet.hu
diff -urN bind-4.9.4-P1/Makefile bind-4.9.4-P1.ELF.shared.new/Makefile
--- bind-4.9.4-P1/Makefile Fri Aug 16 15:14:48 1996
+++ bind-4.9.4-P1.ELF.shared.new/Makefile Sun Aug 25 12:20:00 1996
@@ -56,13 +56,13 @@
## -
## --Copyright--
-VER = 4.9.4-P1
+VER = 4.9.4.2
SHELL = /bin/sh
MAKE = make
DESTDIR =
INCL = include
-RES = res/libresolv.a
+RES = res/libresolv.so.${VER}
COMPLIB = compat/lib/lib44bsd.a
# The default build parameters are given for 4.4 BSD. They should
@@ -108,18 +108,22 @@
#SHCC = cc
#PIC = -fpic
-#(Linux - on modern systems, all you need to do is rename or remove
-# compat/include/sys/cdefs.h. See doc/info/Linux for more information.)
-#CC = gcc $(CPPFLAGS)
-#CDEBUG = -g
-#CPPFLAGS = -DSYSV
-#LIBS = -lfl
-#DESTEXEC = /usr/sbin
-#DESTMAN = /usr/man
-#DESTHELP = /usr/lib
-#CATEXT = $$$$N
-#PS = ps -p
-#IOT = IOT
+#(Linux) Look at the end of this Makefile for further patches for Linux.
+CC = gcc -DSYSV
+CDEBUG=-O2 -fomit-frame-pointer -pipe -fno-strength-reduce
+LEX=flex -8 -I
+LIBS = -Wl,-rpath,${DESTDIR}${DESTLIB} -lfl
+PIDDIR = /var/run
+DESTEXEC = /usr/sbin
+DESTMAN = /usr/man
+MANDIR = man
+MANROFF = cat
+DESTHELP = /usr/lib
+CATEXT = $$$$N
+DESTINC = /usr/include/4.9.4
+INSTALL_COMPAT = install-compat
+PS = ps -p
+IOT = IOT
#(CRAY)
#CDEBUG = -g
@@ -781,3 +785,8 @@
2>&1 | grep '\.[ch]:[0-9]'
FRC:
+ # Enable the following lines for Linux.
+ if [ -f compat/include/sys/cdefs.h ]; then \
+ mv compat/include/sys/cdefs.h compat/include/sys/cdefs.h.old; \
+ fi
+
diff -urN bind-4.9.4-P1/compat/Makefile bind-4.9.4-P1.ELF.shared.new/compat/Makefile
--- bind-4.9.4-P1/compat/Makefile Tue Dec 5 23:31:10 1995
+++ bind-4.9.4-P1.ELF.shared.new/compat/Makefile Sun Aug 25 12:20:00 1996
@@ -55,7 +55,7 @@
SHELL= /bin/sh
DESTDIR=
-DESTINC= /usr/include
+DESTINC= /usr/include/4.9.4
INCL= ../include
COMPINCL= include
DESTLIB= /usr/lib
@@ -74,8 +74,7 @@
"CPPFLAGS=${CPPFLAGS}"
install:
- @-echo compat/ is not installed by default
- @-echo make install-compat if you really need this
+ @-echo compat/ is not installed in Linux
all depend clean::
@for x in ${SUBDIRS}; do \
diff -urN bind-4.9.4-P1/compat/include/Makefile bind-4.9.4-P1.ELF.shared.new/compat/include/Makefile
--- bind-4.9.4-P1/compat/include/Makefile Tue Dec 5 23:32:02 1995
+++ bind-4.9.4-P1.ELF.shared.new/compat/include/Makefile Sun Aug 25 12:20:01 1996
@@ -55,7 +55,7 @@
HFILES =
DESTDIR=
-DESTINC= /usr/include
+DESTINC= /usr/include/4.9.4
MARGS= DESTDIR="${DESTDIR}" DESTINC="${DESTINC}" INSTALL="${INSTALL}"
@@ -68,6 +68,7 @@
rm -f *~ *.BAK *.CKP *.orig
install::
+ -mkdir -p ${DESTDIR}${DESTINC}
-for x in "" ${HFILES}; do \
if [ -n "$$x" ]; then \
${INSTALL} -c -m 444 $$x ${DESTDIR}${DESTINC}/$$x; \
diff -urN bind-4.9.4-P1/compat/include/sys/Makefile bind-4.9.4-P1.ELF.shared.new/compat/include/sys/Makefile
--- bind-4.9.4-P1/compat/include/sys/Makefile Thu Dec 15 07:23:50 1994
+++ bind-4.9.4-P1.ELF.shared.new/compat/include/sys/Makefile Sun Aug 25 12:20:01 1996
@@ -53,10 +53,10 @@
# -
# --Copyright--
-HFILES = cdefs.h bitypes.h
+HFILES = bitypes.h
DESTDIR=
-DESTINC= /usr/include
+DESTINC= /usr/include/4.9.4
all depend:
@@ -64,6 +64,7 @@
rm -f *~ *.BAK *.CKP *.orig
install:
+ -mkdir -p ${DESTDIR}${DESTINC}/sys
for x in ${HFILES}; do \
${INSTALL} -c -m 444 $$x ${DESTDIR}${DESTINC}/sys/$$x; \
done
diff -urN bind-4.9.4-P1/compat/include/sys/bitypes.h bind-4.9.4-P1.ELF.shared.new/compat/include/sys/bitypes.h
--- bind-4.9.4-P1/compat/include/sys/bitypes.h Thu Dec 15 07:23:50 1994
+++ bind-4.9.4-P1.ELF.shared.new/compat/include/sys/bitypes.h Sun Aug 25 12:20:01 1996
@@ -67,6 +67,11 @@
#ifndef __BIT_TYPES_DEFINED__
#define __BIT_TYPES_DEFINED__
+#ifdef __linux__
+#include <linux/types.h>
+#endif
+
+
/*
* Basic integral types. Omit the typedef if
* not possible for a machine/compiler combination.
diff -urN bind-4.9.4-P1/compat/lib/Makefile bind-4.9.4-P1.ELF.shared.new/compat/lib/Makefile
--- bind-4.9.4-P1/compat/lib/Makefile Sun Jun 2 10:20:33 1996
+++ bind-4.9.4-P1.ELF.shared.new/compat/lib/Makefile Sun Aug 25 12:20:01 1996
@@ -75,8 +75,7 @@
SRCS= mktemp.c strcasecmp.c strerror.c strpbrk.c strtoul.c strdup.c \
putenv.c setenv.c setitimer.c writev.c ftruncate.c gettimeofday.c
-OBJS= mktemp.o strcasecmp.o strerror.o strpbrk.o strtoul.o strdup.o \
- putenv.o setenv.o setitimer.o writev.o ftruncate.o gettimeofday.o
+OBJS= foo.o
all: lib44bsd.a
diff -urN bind-4.9.4-P1/compat/lib/foo.c bind-4.9.4-P1.ELF.shared.new/compat/lib/foo.c
--- bind-4.9.4-P1/compat/lib/foo.c Thu Jan 1 01:00:00 1970
+++ bind-4.9.4-P1.ELF.shared.new/compat/lib/foo.c Sun Aug 25 12:20:01 1996
@@ -0,0 +1 @@
+foo(){}
diff -urN bind-4.9.4-P1/doc/bog/Makefile bind-4.9.4-P1.ELF.shared.new/doc/bog/Makefile
--- bind-4.9.4-P1/doc/bog/Makefile Mon Aug 21 00:22:28 1995
+++ bind-4.9.4-P1.ELF.shared.new/doc/bog/Makefile Sun Aug 25 12:20:01 1996
@@ -60,8 +60,8 @@
setup.me manage.me build.me ack.me
ME= -me
NROFF= nroff -rb3
-PRINTER= -Pdp
-TBL= dtbl $(PRINTER)
+PRINTER=
+TBL= tbl $(PRINTER)
TROFF= ditroff $(PRINTER)
GROFF= groff -Tps -t $(ME)
diff -urN bind-4.9.4-P1/include/Makefile bind-4.9.4-P1.ELF.shared.new/include/Makefile
--- bind-4.9.4-P1/include/Makefile Mon Aug 21 00:17:44 1995
+++ bind-4.9.4-P1.ELF.shared.new/include/Makefile Sun Aug 25 12:20:01 1996
@@ -55,7 +55,7 @@
HFILES = netdb.h resolv.h
DESTDIR=
-DESTINC= /usr/include
+DESTINC= /usr/include/4.9.4
MARGS= DESTDIR="${DESTDIR}" DESTINC="${DESTINC}" INSTALL="${INSTALL}" \
MAKE="${MAKE}"
@@ -69,6 +69,7 @@
rm -f *~ *.BAK *.CKP *.orig
install::
+ -mkdir -p ${DESTDIR}${DESTINC}
@set -x; for x in ${HFILES}; do \
${INSTALL} -c -m 444 $$x ${DESTDIR}${DESTINC}/$$x; \
done
diff -urN bind-4.9.4-P1/include/arpa/Makefile bind-4.9.4-P1.ELF.shared.new/include/arpa/Makefile
--- bind-4.9.4-P1/include/arpa/Makefile Thu Jan 12 23:59:24 1995
+++ bind-4.9.4-P1.ELF.shared.new/include/arpa/Makefile Sun Aug 25 12:20:01 1996
@@ -54,7 +54,7 @@
HFILES = inet.h nameser.h
DESTDIR =
-DESTINC = /usr/include
+DESTINC = /usr/include/4.9.4
all depend:
@@ -62,6 +62,7 @@
rm -f *~ *.BAK *.CKP *.orig
install:
+ -mkdir -p ${DESTDIR}${DESTINC}/arpa
set -x; for x in ${HFILES}; do \
${INSTALL} -c -m 444 $$x ${DESTDIR}${DESTINC}/arpa/$$x; \
done
diff -urN bind-4.9.4-P1/man/Makefile bind-4.9.4-P1.ELF.shared.new/man/Makefile
--- bind-4.9.4-P1/man/Makefile Tue Jun 20 22:27:20 1995
+++ bind-4.9.4-P1.ELF.shared.new/man/Makefile Sun Aug 25 12:20:01 1996
@@ -31,7 +31,7 @@
# entries on the fly, use
# MANDIR = man
#
-MANDIR = cat
+MANDIR = man
#
# Default extension for manual entries. To install the manual entries under
@@ -298,7 +298,7 @@
#
# Command used to produce manual entries
#
-MK_MANFILE = ( ${EXT_SED_CMD} | ${MANROFF} )
+MK_MANFILE = ( ${EXT_SED_CMD} )
#
# Extensions for the generated manual entries
diff -urN bind-4.9.4-P1/res/Makefile bind-4.9.4-P1.ELF.shared.new/res/Makefile
--- bind-4.9.4-P1/res/Makefile Fri Aug 16 15:14:51 1996
+++ bind-4.9.4-P1.ELF.shared.new/res/Makefile Sun Aug 25 12:20:01 1996
@@ -56,22 +56,23 @@
## -
## --Copyright--
+VER= 4.9.4.2
DESTDIR =
DESTLIB = /usr/lib
CC= cc
SHELL= /bin/sh
-CDEBUG= -g
+CDEBUG= -O2 -fno-strength-reduce
INCL = ../include
COMPINCL = ../compat/include
-AR= ar cru
-RANLIB= ranlib
+AR_SH= gcc -shared -o
+RANLIB= :
DEFS=
LOCDEFS= -DUSE_OPTIONS_H
INSTALL= install
AROBJS= ${ARPREF} ${OBJS} ${ARSUFF}
-CFLAGS= ${CDEBUG} -I${INCL} -I${COMPINCL} ${DEFS} ${LOCDEFS}
+CFLAGS= -fPIC ${CDEBUG} -I${INCL} -I${COMPINCL} ${DEFS} ${LOCDEFS}
SRCS= herror.c res_debug.c res_data.c \
res_comp.c res_init.c res_mkquery.c res_query.c res_send.c \
@@ -85,17 +86,18 @@
gethnamaddr.o sethostent.o nsap_addr.o hostnamelen.o \
inet_addr.o inet_ntop.o inet_pton.o
-all: libresolv.a
+all: libresolv.so.${VER}
-libresolv.a: ${OBJS}
- ${AR} libresolv.a ${AROBJS}
- $(RANLIB) libresolv.a
+libresolv.so.${VER}: ${OBJS}
+ ${AR_SH} libresolv.so.${VER} -Wl,-soname,libresolv.so.4 ${AROBJS}
-install: ${DESTDIR}${DESTLIB}/libresolv.a
-${DESTDIR}${DESTLIB}/libresolv.a: libresolv.a
- ${INSTALL} -c -o bin -g bin -m 644 libresolv.a ${DESTDIR}${DESTLIB}/
- ( cd ${DESTDIR}${DESTLIB} ; $(RANLIB) libresolv.a )
+install: ${DESTDIR}${DESTLIB}/libresolv.so.${VER}
+
+${DESTDIR}${DESTLIB}/libresolv.so.${VER}: libresolv.so.${VER}
+ ${INSTALL} -c -o bin -g bin -m 755 libresolv.so.${VER} ${DESTDIR}${DESTLIB}/
+ -(cd ${DESTDIR}${DESTLIB}; ln -sf libresolv.so.${VER} libresolv.so )
+ -ldconfig
.c.o:
${CC} ${CPPFLAGS} ${CFLAGS} -c $*.c
@@ -103,7 +105,7 @@
${LDS} mv a.out $*.o
clean: FRC
- rm -f errs a.out core libresolv.a tags .depend
+ rm -f errs a.out core libresolv.* tags
rm -f *.o *.BAK *.CKP *~ *.orig
depend: FRC
diff -urN bind-4.9.4-P1/tools/dig.c bind-4.9.4-P1.ELF.shared.new/tools/dig.c
--- bind-4.9.4-P1/tools/dig.c Tue May 21 09:32:40 1996
+++ bind-4.9.4-P1.ELF.shared.new/tools/dig.c Sun Aug 25 12:20:01 1996
@@ -630,7 +630,7 @@
inet_ntoa(_res.nsaddr_list[i]
.sin_addr));
printf(";; WHEN: %s",
- ctime(&(exectime.tv_sec)));
+ ctime((time_t *)(&(exectime.tv_sec))));
}
if (!x)
break; /* success */
@@ -685,7 +685,7 @@
printf(";; FROM: %s to SERVER: %s\n",
myhostname, srvmsg);
printf(";; WHEN: %s",
- ctime(&(exectime.tv_sec)));
+ ctime((time_t *)(&(exectime.tv_sec))));
printf(";; MSG SIZE sent: %d rcvd: %d\n",
bytes_out, bytes_in);
}

417
usr.sbin/named/doc/info/Linux-libc Normal file
View File

@ -0,0 +1,417 @@
>>> 4.9.5:1
Date: Mon, 28 Oct 1996 06:59:15 EST
To: Paul Vixie <paul@vix.com> (BIND), "H.J. Lu" <hjl@gnu.ai.mit.edu> (libc
***)
cc: Craig Metz <cmetz@inner.net> (netdev), bind-workers@vix.com (BIND)
From: Bradley Ward Allen <ulmo@Q.Net>
Subject: BIND shres/linux/README addition + Is&Qs
Paul,
Herein please find a patch that I'd like to make sure you somehow
incorporate into the latest BIND version before its final release.
It's all documentation, no code changes.
diff -Nru bind-4.9.5b6/Makefile bind-4.9.5b6.new/Makefile
--- bind-4.9.5b6/Makefile Tue Oct 8 00:50:58 1996
+++ bind-4.9.5b6.new/Makefile Mon Oct 28 05:29:16 1996
@@ -125,9 +125,10 @@
#CATEXT = $$$$N
#PS = ps -p
#IOT = IOT
-#uncomment next line to build a shared library version of libresolv
+# You probably don't want shared libresolv, read shres/linux/README to decide!
!
+# uncomment next line to build a shared library version of libresolv
#SHRES = shres/linux
-#uncomment next line to build tools and named with shared libresolv
+# uncomment next line to build tools and named with shared libresolv
#RES = $(SHRES)/libresolv.so
# ... and then (for shared) uncomment these lines too:
#SHCC = gcc $(CPPFLAGS) -fomit-frame-pointer -pipe
diff -Nru bind-4.9.5b6/shres/linux/README bind-4.9.5b6.new/shres/linux/README
--- bind-4.9.5b6/shres/linux/README Wed Dec 31 19:00:00 1969
+++ bind-4.9.5b6.new/shres/linux/README Mon Oct 28 06:04:21 1996
@@ -0,0 +1,37 @@
+This is BIND's shres/linux/README file, specific to Linux.
+
+According to someone who put a copyright on his email so I don't want
+to copy it verbatim (therefore I have to make the information original
+and I get to claim credit; don't you love how backwards copyright laws
+make things sometimes?) in Linux it's better to build an updated
+version of libc with the latest resolver rather than to use
+libresolv.so (shared libresolv), since if you do the latter you will
+have two versions of the resolver functions being used (one for apps
+not linked with -lresolv and one for those linked with -lresolv),
+which affects both memory usage (more) and application behavior (it
+was indicated that this is bad; I can see how it may be in an
+unpredictable way, which is enough to worry about!) In addition,
+there might be some (minor but relevant) compatibility porting that
+gets done when integrating the resolver into libc.
+
+One approach for the future that I brought up could be to have the
+libc.so ELF library require the libresolv.so library (something my
+source said would require some "stupid libdl tricks"), thus
+eliminating duplicates and making upgrading components easier (as well
+as easier to set up incompatible combinations with unforeseen bad
+interactions). Since I'm an armchair OS theorist, take this paragraph
+as conjecture. My priority was getting this README out quickly to
+warn people of some of the issues (see next paragraph), not in making
+it perfect (in this case).
+
+I just wanted to make this README before I opened a whole can of worms
+with everybody using different concepts of how to link resolver
+routines into their programs. So: for now (or until further notice)
+use libc unless you know what you're doing, especially package and OS
+distributors.
+
+Someone make this README better.
+For now, by Bradley Allen <Ulmo@Q.Net>
+"my source" in above is Craig Metz <cmetz@inner.net>, in a thread
+about a test suite of IPv6 applications for Linux he put together I
+was trying.
Is&Qs means Ideas and Questions.
All,
I've always been annoyed that libc's resolver is always ages behind
that of BIND's resolver, before Linus even took an OS class (although
back then I didn't know libc was called libc), and the fact that there
can be bad interactions between named and resolvers not upgraded, and
other problems with not upgrading the resolvers (bugs, etc.) Lately,
I've wanted to use a newer resolver with upcoming IPv6 features
integrated into it, mostly for testing, etc.
In the Linux ELF environment (where source is generally available
for all components), is it good or bad to have libc require libresolv
and then move all libc resolver support functionality into libresolv?
How hard would this be? Would this work transparently without having
to link (or for that matter, relink) programs with -lresolv? Would it
also work (the same) with programs linked with -lresolv? Would this
be of benefit in other OSs where the (libc) source is not available?
Would this require wrapper functions from libc to libresolv to
handle porting issues? Would such wrapper functions be possible?
Would they endanger those programs linked with -lresolv since those
programs will be using a different version of the functions than those
linked without -lresolv? If possible, how hard would it be to
eliminate the need for something like wrapper functions?
Also, according to Craig's comments on his work in progress (which
looks like a good approach to DNS), using his current getaddrinfo code
with BIND's inet_ntop will result in a core dump. Perhaps inet_ntop
could be made more robust (I don't have details; Craig?)
In addition, in response to my posting gangly shell scripts to do
conversions between base 85 (RFC1924) and the other IPv6 notations
(mostly out of intrigue, not of dire function), Craig asserted his
opinion that base 85 is evil. I have no big opinion, only very small
ones: it's pretty looking giberish ([e108:724e:f104:e104:8:800:400C:417A]
becomes [%o%rjMA$@*TrQv?=(jE<]), and easier to format in debugging and
logging outputs. :) Other than that, I tend to agree with Craig that
it's kinda hard to make standard now as well as of questionable value,
but thought I'd give it more air.
Bradley <u@q.net>
P.S. spam helped the proliferation of PGP more than anything else I've
seen. Now, it's become so familiar to use I use it for more mundane
things. Here though I keep it away from the patch.
-----BEGIN PGP SIGNED MESSAGE-----
md5sum of body above pgp signed text: 3d1e3de216241adcf93fa8650e2cbf02
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQEVAwUBMnSfYJxWhFYc6x9VAQFjlwgAllFApf7jamAtFpLFVUob3lt9meCp+/uq
V2FZNENGg1q+hXmX6N9452FpD1fAYMJ3zyTGy9Lei+Kr3G9vYRQ5KxuEBXRT/Yrj
XjojarPxaOb6V9PYlT5tUVUgcuSRgKb9d3Pwe8oE6dsMUGF5iepllGXyliQA00Tp
7ouoiFWYvMNVZKWYZKjYgvzBmx2VQFzq5tZwsoI8TYBxGIsqOySJ7Lk2qh6IKozx
lTRyP7hxXNcgLEff2/Uv+LKobOXfhj6Cz8kKQRXqMIo0wVdxEUIO1Wyi0xcTHqp8
EadZoZYCfNKOaE0piERTJiNTCre0aQQB6g1IdEA59JJScM2RYVVHqg==
=ML1B
-----END PGP SIGNATURE-----
>>> 4.9.5:2
Date: Tue, 05 Nov 1996 17:40:14 +0100
To: ulmo@q.net
cc: paul@vix.com, hjl@gnu.ai.mit.edu, cmetz@inner.net, bind-workers@vix.co
***m
From: Ulrich Drepper <drepper@myware.rz.uni-karlsruhe.de>
Subject: Re: BIND shres/linux/README addition + Is&Qs
From: Bradley Ward Allen <ulmo@Q.Net>
Subject: BIND shres/linux/README addition + Is&Qs
Date: Mon, 28 Oct 1996 06:59:15 -0500
> I've always been annoyed that libc's resolver is always ages behind
> that of BIND's resolver,
This is not true. At most a few days after a new resolver version is
out I upgrade GNU libc. And the GNU libc the upcoming libc for Linux.
> In the Linux ELF environment (where source is generally available
> for all components), is it good or bad to have libc require libresolv
> and then move all libc resolver support functionality into libresolv?
I don't know whether you missed a thread in the mailing
lists/newsgroups I recently participated. I explained why it is not
possible to use the resolver code directly.
As the code comes in BIND it is not usable (sorry, Paul). The code
suffers from it's heritage. There is no separation between the
different ways to access name information. In the original code using
the file database and using DNS is happily mixed. In the Linux libc's
code there is yet another service (NIS) available. This all is only a
hack.
For the GNU library I implemented a scheme similar to Solaris' NSS.
For this I needed clean separations. The file lookup, DNS, NIS, etc
are all in separate parts of the library (in fact, all are separate
shared objects). Beside this all functions in the GNU libc NSS
modules are reentrant.
Once I have a few more time available I want to make a proposal to
change the official BIND resolver library. The result could be used
with some additional glue code with the same interface as it is now
but systems which do not want to/can use the current code because it
is too restrictive will profit from the change.
> How hard would this be? Would this work transparently without having
> to link (or for that matter, relink) programs with -lresolv? Would it
> also work (the same) with programs linked with -lresolv? Would this
> be of benefit in other OSs where the (libc) source is not available?
This is not possible even for the Linux libc. You would loose the NIS
code.
-- Uli
--------------. drepper@cygnus.com ,-. Rubensstrasse 5
Ulrich Drepper \ ,--------------------' \ 76149 Karlsruhe/Germany
Cygnus Support `--' drepper@gnu.ai.mit.edu `------------------------
>>> 4.9.5:3
Date: Wed, 06 Nov 1996 04:28:04 EST
To: drepper@ipd.info.uni-karlsruhe.de (Ulrich Drepper)
cc: paul@vix.com, hjl@gnu.ai.mit.edu, cmetz@inner.net, bind-workers@vix.co
***m,
Matthias Urlichs <smurf@smurf.noris.de>,
ULMO@Q.Net
From: Bradley Ward Allen <ulmo@Q.Net>
Subject: Re: BIND shres/linux/README addition + Is&Qs
--==_Exmh_2051252028P
Content-Type: text/plain
Matthias Urlichs <smurf@smurf.noris.de>
> The alternative to shared libresolv is static libresolv which is even
> worse.
>
> We have three choices...
> - Link statically. Ugly.
> - Link with our -lresolv. Workable.
> - Assume that the standard libc and include files already are up-to-date.
>
> The third option, IMHO, is the most preferable. All we need is a version
> number, for verification.
Yes, now that I understand this situation better, I see that #2 and #3
should be the BIND choices. This should go to the BIND README and
Makefile as well. Plus it should be obvious what one is selecting
while in the Makefile, and why. Mentioning both glibc and the HJL
libc and where they stand would be important.
> The way the GNU libc (which works very well under Linux) does this is to
> delegate all the lookup functions to a sub-library which is
> dynamically-linked into the running program when needed, and which in turn
> uses -lresov. Problem solved (but it is NOT easy to make this work).
Not easy for who? For the glibc programmers who supposedly already
finished the hard part, or is there more hard stuff to do or hard for
the administrators?
> >[...]
> You can always port the GNU libc...
It's about time I find out where GNU libc is. I'll pull the one from
rice-chex (er, what's it called now? ftp.gnu.ai.mit.edu). Is it ready
for public consumption (e.g., I read comp.os.linux.announce and it
doesn't regular there)?
Ulrich Drepper <drepper@ipd.info.uni-karlsruhe.de>
>> I've always been annoyed that libc's resolver is always ages behind
>> that of BIND's resolver,
>
>This is not true. At most a few days after a new resolver version is
>out I upgrade GNU libc. And the GNU libc the upcoming libc for Linux.
Ahhh, on linux-kernel and in distributions the other libc is the one
being talked about. <confused look>
>For the GNU library I implemented a scheme similar to Solaris' NSS.
>For this I needed clean separations. The file lookup, DNS, NIS, etc
>are all in separate parts of the library (in fact, all are separate
>shared objects). Beside this all functions in the GNU libc NSS
>modules are reentrant.
That's great. (File + NIS as well as DNS is useful for those who need
it, and the intent is supporting the possible combinations out there
that might happen, therefore File + NIS + DNS is useful. While one
can argue that File is unnecessary since one can just run DNS + named
(even without Internet connectivity), there are currently security
issues solved by using only File or File First (which I just learned
about); when and how is DNS security being implemented? As a part of
IPv[46] security or seperately? Also, NIS is useful for those stuck
with it or if its security is better. I'm babling now ...)
>Once I have a few more time available I want to make a proposal to
>change the official BIND resolver library. The result could be used
>with some additional glue code with the same interface as it is now
>but systems which do not want to/can use the current code because it
>is too restrictive will profit from the change.
Also threaded DNS lookups ...
Alright, I'm sorry, I feel like I'm watching a whole lotta worms
squiggle around right now in front of me, but on the other hand
they're earth worms so I'm not afraid.
--==_Exmh_2051252028P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQEVAwUBMoBaHpxWhFYc6x9VAQFKywf7BNyd7JfKjg/a8FszJJ4I669pCCV1I41D
iArTy5AVys8FYOXQZhZj5V/jpbwRBgdZiyz2GW/T80xRgscZxbqJiDxLcsx6slPT
QPpTFrSP6OFJyfWdG7jRziMhDMkVhIEruZwuUIoEUbC6iZbvLkqwnaJf7pcNpwqy
gJ5AtnarWU7pYfWgZxqoikq6G+rAqVyoVb7me/T1jEJ+Oa67+06dFDFLaWyybAi4
15me6WIgzBZFM0iRxKnooc1VjcOiAI1hb0+/iLH3/YyzSexrXi3JgfW3ILpujfEm
Aw3qTy1nI0AmRexsKpKZQ4uiGUCXdQXBJAMwTsklWUhtkZfbGW10pw==
=aqKJ
-----END PGP MESSAGE-----
--==_Exmh_2051252028P--
>>> 4.9.5:4
Date: Wed, 06 Nov 1996 11:55:05 +0100
To: ulmo@Q.Net (Bradley Ward Allen)
cc: drepper@ipd.info.uni-karlsruhe.de, paul@vix.com, hjl@gnu.ai.mit.edu,
cmetz@inner.net, bind-workers@vix.com, smurf@smurf.noris.de,
ULMO@Q.Net
From: Matthias Urlichs <smurf@smurf.noris.de>
Subject: Re: BIND shres/linux/README addition + Is&Qs
Hi,
Bradley Ward Allen wrote:
>
>> The way the GNU libc (which works very well under Linux) does this is to
>> delegate all the lookup functions to a sub-library which is
>> dynamically-linked into the running program when needed, and which in turn
>> uses -lresov. Problem solved (but it is NOT easy to make this work).
>
>Not easy for who? For the glibc programmers who supposedly already
>finished the hard part, or is there more hard stuff to do or hard for
>the administrators?
>
The former. I should have said "it _was_ not easy", but I only see the
results...
>> You can always port the GNU libc...
>
>It's about time I find out where GNU libc is. I'll pull the one from
>rice-chex (er, what's it called now? ftp.gnu.ai.mit.edu). Is it ready
>for public consumption (e.g., I read comp.os.linux.announce and it
>doesn't regular there)?
>
alpha.gnu.ai.mit.edu:/gnu/glibc. People who actually work on ports of glibc
(other than to Linux and The Hurd) don't seem to exist at the moment. If
you want to help change this sad fact, DO IT!
>Ahhh, on linux-kernel and in distributions the other libc is the one
>being talked about. <confused look>
>
Right. Linux libc once was a glibc clone, but cooperation between the
people involved didn't work very well...
>Also threaded DNS lookups ...
>
(A) Find a sensible threading library. Surprise, linux-glibc already has
one. ;-)
(B) Replace all assignments to errno and h_errno with per-thread setter
functions (this is the only difference between the resolver library in
BIND and the one in glibc, as far as I can tell, ignoring for the moment
all code that's in one but not in the other).
(C) Now, if you want to do a DNS lookup in parallel, just spawn off a
thread and do it. Simplicity itself. ;-)
--
If some people didn't tell you,
you'd never know they'd been away on vacation.
--
Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg
Schleiermacherstraße 12 \ Linux+Internet / EMail: urlichs@noris.de
90491 Nürnberg (Germany) \ Consulting+Programming+Networking+etc'ing
PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE
Click <A HREF="http://info.noris.de/~smurf/finger">here</A>. 42
>>> 4.9.5:5
Date: Wed, 06 Nov 1996 12:18:13 +0100
To: smurf@smurf.noris.de
cc: ulmo@q.net, paul@vix.com, hjl@gnu.ai.mit.edu, cmetz@inner.net,
bind-workers@vix.com
From: Ulrich Drepper <drepper@myware.rz.uni-karlsruhe.de>
Subject: Re: BIND shres/linux/README addition + Is&Qs
From: Matthias Urlichs <smurf@smurf.noris.de>
Subject: Re: BIND shres/linux/README addition + Is&Qs
Date: Wed, 6 Nov 1996 11:55:05 +0100 (MET)
> (B) Replace all assignments to errno and h_errno with per-thread setter
> functions (this is the only difference between the resolver library in
> BIND and the one in glibc, as far as I can tell, ignoring for the moment
> all code that's in one but not in the other).
> (C) Now, if you want to do a DNS lookup in parallel, just spawn off a
> thread and do it. Simplicity itself. ;-)
It's not that easy. While many of the original resolver files are
still available in the libresolv.so object they are *not* used. All
the DNS lookup functions are written new (based on the original
version) and are now in the libnss_dns.so objects. Substantial
changes had to be done since the original resolver code uses static
variables.
The libresolv.so lib which comes which glibc is not really what it is
one other systems. It includes some helper functions which are not
used inthe libc itself and it includes the hostname lookup functions
but the names are changed.
-- Uli
--------------. drepper@cygnus.com ,-. Rubensstrasse 5
Ulrich Drepper \ ,--------------------' \ 76149 Karlsruhe/Germany
Cygnus Support `--' drepper@gnu.ai.mit.edu `------------------------

142
usr.sbin/named/doc/info/NCR Normal file
View File

@ -0,0 +1,142 @@
Delivery-Date: Mon, 10 Jul 1995 18:47:44 -0700
Return-Path: bind-workers-request@vix.com
Received: by gw.home.vix.com id AA25952; Mon, 10 Jul 95 18:45:32 -0700
Received: by gw.home.vix.com id AA25948; Mon, 10 Jul 95 18:45:31 -0700
Received: from cfctech.UUCP by heifetz.msen.com with UUCP
(Smail3.1.28.1 #12) id m0sVU1P-0009kIC; Mon, 10 Jul 95 21:21 EDT
Received: from serve.tech.mis.cfc.com by cfctech.cfc.com with smtp
(Smail3.1.27.1 #3) id m0sVTTC-0002oyC; Mon, 10 Jul 95 20:46 EDT
Received: (from kevin@localhost) by serve.tech.mis.cfc.com (8.7.Beta.4/8.6.9) with UUCP id UAA23780; Mon, 10 Jul 1995 20:49:30 -0400 (EDT)
Message-Id: <199507110049.UAA23780@serve.tech.mis.cfc.com>
Subject: BIND 4.9.3-BETA24 Support for NCR (ne AT&T-GIS) 3000, MP-RAS 2.03.01, vendor-supplied "cc"
To: bind-workers@vix.com
Date: Mon, 10 Jul 1995 20:49:30 -0400 (EDT)
From: "Kevin Darcy" <kevin@tech.mis.cfc.com>
X-Mailer: ELM [version 2.4 PL24alpha3]
Content-Type: text
The only really squirrelly things about the NCR 3000 OS, as compared to other
i386 SRV4 platforms, are:
a) the networking code can't tolerate the IP_OPTIONS stuff
(getsockopt() returns an error (EOPNOTSUPP), thereby triggering
closure of the fd). This diff hacks out the IP_OPTIONS code
b) -D_INET_H_ is necessary to suppress certain function declarations
in arpa/inet.h, which on the NCR 3000 (as of release 2.03.01) are
incompatible with the corresponding declarations in the
subsequently-#included /usr/include/netinet/in.h
c) unlike other SVR4's, NCR 3000's require a combination of
DESTSBIN = /usr/etc, DESTEXEC = /usr/etc, and XFER_INDOT = (null)
to be compatible with the vendor-supplied pathnames
Please include this diff, either as a replacement for the old doc/info/NCR, or
as "doc/info/NCR.too" (the doc/info/RUNSON patch band can of course simply be
incorporated into the general release, if desired): the old doc/info/NCR (from
Anders Tjader) reports serious fuzzes and offsets when patched, and does not
result in a compilable BIND on MP-RAS version 2.03.01.
- Kevin
*** ../bind-4.9.3-BETA24.dist/doc/info/RUNSON Sun Jun 25 02:45:07 1995
--- doc/info/RUNSON Mon Jul 10 20:15:50 1995
***************
*** 17,22 ****
--- 17,23 ----
HP-UX B09.00 hp300 gcc2.5.7 piete brooks production primary
HP-UX A09.04 hp800 cc todd martin production secondary
IRIX 5 mips mips cc paul vixie courtesy of SGI
+ NCR MP-R2.03.01 i386 cc kevin darcy "compiles and runs"
NEXTSTEP3.0 m68k gcc1.39 artur romao "compiles and runs"
NEXTSTEP3.2 m68k cc scott mcintyre "compiles and runs"
NEXTSTEP3.3 hppa cc allan nathanson "compiles and runs"
*** ../bind-4.9.3-BETA24.dist/Makefile Fri Jul 7 03:33:32 1995
--- Makefile Mon Jul 10 19:46:02 1995
***************
*** 477,498 ****
#set to empty. also, use 'make install' at your own risk.
#don't include sys/stream.h via netinet/in.h by defining _SYS_STREAM_H.
#CC = gcc $(CPPFLAGS)
! #CPPFLAGS = -DSVR4 -DBSD_COMP -DUSE_POSIX -D_SYS_STREAM_H
! #CDEBUG = -O
! #LEX = lex
#INDOT = in.
! #XFER_INDOT =
! #PIDDIR = /etc
! #INSTALL = /usr/ucb/install
! #LIBS = -ll -lsocket -lnsl
! #DESTSBIN = /usr/sbin
! #DESTEXEC = /usr/sbin
! #LDS = @:
! #RANLIB = @:
! #ARPREF = `lorder
! #ARSUFF = | tsort`
! #CATEXT = $$$$N
! #PS = ps -p
#(ISC4.0 using GCC)
#CC = gcc -DISC -posix
--- 477,498 ----
#set to empty. also, use 'make install' at your own risk.
#don't include sys/stream.h via netinet/in.h by defining _SYS_STREAM_H.
#CC = gcc $(CPPFLAGS)
! CPPFLAGS = -DSVR4 -DBSD_COMP -DUSE_POSIX -D_INET_H_ -D_SYS_STREAM_H
! CDEBUG = -O
! LEX = lex
#INDOT = in.
! XFER_INDOT =
! PIDDIR = /etc
! INSTALL = /usr/ucb/install
! LIBS = -ll -lsocket -lnsl
! DESTSBIN = /usr/etc
! DESTEXEC = /usr/etc
! LDS = @:
! RANLIB = @:
! ARPREF = `lorder
! ARSUFF = | tsort`
! CATEXT = $$$$N
! PS = ps -p
#(ISC4.0 using GCC)
#CC = gcc -DISC -posix
*** ../bind-4.9.3-BETA24.dist/named/ns_main.c Thu Jun 29 05:26:22 1995
--- named/ns_main.c Mon Jul 10 19:22:09 1995
***************
*** 742,775 ****
(void) my_close(rfd);
continue;
}
- #if defined(IP_OPTIONS)
- len = sizeof ip_opts;
- if (getsockopt(rfd, IPPROTO_IP, IP_OPTIONS,
- (char *)ip_opts, &len) < 0) {
- syslog(LOG_INFO,
- "getsockopt(rfd, IP_OPTIONS): %m");
- (void) my_close(rfd);
- continue;
- }
- if (len != 0) {
- nameserIncr(from_addr.sin_addr, nssRcvdOpts);
- if (!haveComplained((char*)
- from_addr.sin_addr.s_addr,
- "rcvd ip options")) {
- syslog(LOG_INFO,
- "rcvd IP_OPTIONS from [%s].%d (ignored)",
- inet_ntoa(from_addr.sin_addr),
- ntohs(from_addr.sin_port));
- }
- if (setsockopt(rfd, IPPROTO_IP, IP_OPTIONS,
- NULL, 0) < 0) {
- syslog(LOG_INFO,
- "setsockopt(!IP_OPTIONS): %m");
- (void) my_close(rfd);
- continue;
- }
- }
- #endif
if (setsockopt(rfd, SOL_SOCKET, SO_SNDBUF,
(char*)&sbufsize, sizeof(sbufsize)) < 0){
syslog(LOG_INFO,
--- 742,747 ----

26
usr.sbin/named/doc/info/RFS Normal file
View File

@ -0,0 +1,26 @@
Return-Path: vixie
Received: by gw.home.vix.com id AA18779; Tue, 7 Dec 93 16:51:00 -0800
Message-Id: <9312080051.AA18779@gw.home.vix.com>
To: Nicholas_Briggs.PARC@xerox.com
Cc: paul
Subject: Re: nsquery in BIND release
In-Reply-To: Your message of Mon, 06 Dec 93 17:43:46.
<93Dec6.174359pst.14497(2)@alpha.xerox.com>
Date: Tue, 07 Dec 93 16:50:59 PST
From: Paul A Vixie <vixie>
i'll release-note this fact. thanks.
> Date: Mon, 6 Dec 1993 17:43:46 PST
> From: Nicholas_Briggs.PARC@xerox.com
> Subject: nsquery in BIND release
> To: paul@vix.com
> Cc: Nicholas_Briggs.PARC@xerox.com
> Message-Id: <93Dec6.174359pst.14497(2)@alpha.xerox.com>
>
> Paul -- I didn't notice this before, but the "nsquery" tool in BIND conflicts
> with the SunOS (4.1.3) /usr/bin/nsquery, which is the RFS name server query
> tool.
>
> \nick

44
usr.sbin/named/doc/info/RUNSON Normal file
View File

@ -0,0 +1,44 @@
Op. Sys. CPU Compilers Reported Other
Name Rev Arch Used By Notes
======= ======= ======= =============== =============== ===============
A/UX 3.1.1 m68k gcc2.6.3 phillip porch "compiles and runs"
AIX 3.2.3e power bsdcc c. wolfhugel production secondary
AIX 3.2.5 rs6000 bsdcc craig metz "compiles and runs"
BSD 4.4 hp300 gcc2.5.8 mark davies compiles and runs
BSD/386 1.0 i386 gcc1.41,2.5.8 paul vixie production primary
BSD/386 1.1 i386 gcc1.41,2.5.8 paul vixie production secondary
CnvxOS 10.2 c38 gcc2.6.3 jukka ukkonen production secondary
DomainO 10.3.5 m68k cc 6.8 don lewis production secondary
DomainO 10.4.0 m68k cc todd martin production secondary
HP-UX 7.0 hp300 cc alan barrett needs "struct linger"
HP-UX 9.00 hp800 cc,gcc2.5.8 m. corrigan "compiles and works"
HP-UX A09.01 hp700 cc don lewis "compiles and runs"
HP-UX A09.01 hp700 gcc2.5.7 piete brooks production secondary
HP-UX B09.00 hp300 gcc2.5.7 piete brooks production primary
HP-UX A09.04 hp800 cc todd martin production secondary
IRIX 5 mips mips cc paul vixie courtesy of SGI
NEXTSTEP3.0 m68k gcc1.39 artur romao "compiles and runs"
NEXTSTEP3.2 m68k cc scott mcintyre "compiles and runs"
NEXTSTEP3.3 hppa cc allan nathanson "compiles and runs"
NEXTSTEP3.3 i486 cc allan nathanson "compiles and runs"
NEXTSTEP3.3 m68k cc allan nathanson "compiles and runs"
NetBSD 1.0 i386 gcc2.4.5 alan barrett production primary
OSF/1 V1.3 axp gcc2.5.7 piete brooks production secondary
OSF/1 V2.0 axp cc c. wolfhugel production secondary
OSF/1 V3.0 axp cc c. wolfhugel production secondary
RISC/os 4.52 mips mips cc r. perini production primary
SCO ODT3.0 i386 gcc2.5.8 m. meiszl "compiles and runs"
Solaris 2.2 sparc gcc2.5.8 artur romao production primary
Solaris 2.3 sparc gcc2.5.8 ian dickinson production secondary
Solaris 2.4 sparc gcc2.6.3 ian dickinson production secondary
Solbrne 4.1A.1 sparc gcc2.5.8 ian dickinson "compiles and runs"
SunOS 4.1 m68k gcc2.5.8 ian dickinson production secondary
SunOS 4.1.1 m68k gcc2.4.5 piete brooks "compiles and clients"
SunOS 4.1.1 sparc cc alan barrett "compiles and works"
SunOS 4.1.3 sparc gcc2.5.8 ian dickinson production primary
SunOS 4.1.3 sparc sun c 2.0.1 tom limoncelli "works w/ jumbo patch"
SunOS 4.1.3U1 sparc cc alan barrett production primary
SunOS 4.1.3U1 sparc gcc2.4.5 craig leres "compiles and works"
SunOS 4.1.3U1 sparc gcc2.6.2 don lewis production primary
ULTRIX 4.2A mips mips cc paul vixie production secondary
ULTRIX 4.3 vax vax pcc paul vixie void* isn't anonymous

110
usr.sbin/named/doc/info/SCO Normal file
View File

@ -0,0 +1,110 @@
Most of the work on SCO port of BIND 4.9.3 has been done by Michael A Meiszl.
The following represents my experience from building various BETA versions
on SCO 3.2v4.2.
The following procedure is known to build and install BIND 4.9.3 (as of
BETA11 patch 3) on SCO 3.2v4.2, using gcc 2.5.8.
0) Backup old named and zone files. cd to named distribution's
root directory.
1) make links
2) cd native.b
mkdir include/sys
cat >include/sys/param.h <<EOF
#include <sys/types.h>
#include "/usr/include/sys/param.h"
EOF
3) Edit Makefile, search for string SCO and uncomment SCO specific
lines. Based on my personal experience (building perl on SCO
system after the BIND's compat library and include files have
been installed), I *strongly* suggest to leave the INSTALL_COMPAT
line commented out.
4) make
5) su
6) kill -9 `cat /etc/named.pid`
7) If you are secondary server, I suggest to always remove all
secondary zone files.
8) make install
You need the scoinst (BSD style install emulation) script. There
are various such scripts on the net.
9) /etc/named
10) Be your CMOS battery with you.
You also probably need to update /usr/lib/libsocket.a with the new
resolver routines. This task is a bit difficult and I am currently
(7-Nov-94) trying to write shell script to automate this job.
Alternatively, you can stay with separate libresolv.a and change each
occurence of -lsocket in Makefiles to -lresolv -lsocket. Anyway, you
must relink your applications to take the advantage of new resolver
routines (if nothing else, sendmail is good candidate). Personally,
I am preferring libsocket.a update.
Eduard Vopicka, <eda@vse.cz>
On Dec 8, 2:38am, Paul A Vixie wrote:
} Subject: Re: b11p3 on SCO - problems and fixes
} thanks, this will all be in b11p4
}-- End of excerpt from Paul A Vixie
Thanks!
And another SCO specific one: SCO's kill executable requires *numeric*
specification of signal (!!!). This causes the ndc shell script to fail
miserably - things like `kill -HUP 12345' on SCO simply do nothing w/o
any error message. Maybe this results to kill(0,pid)???. So it would be
essential to have the following patch included in conf/Info.SCO.
Brgds,
Ed
*** named/ndc~ Thu Dec 8 11:29:10 1994
--- named/ndc Thu Dec 8 11:31:27 1994
***************
*** 26,37 ****
echo $ARG
case $ARG in
status) echo "$PS";;
! dumpdb) kill -INT $PID && echo Dumping Database;;
! reload) kill -HUP $PID && echo Reloading Database;;
! stats) kill -IOT $PID && echo Dumping Statistics;;
! trace) kill -USR1 $PID && echo Trace Level Incremented;;
! notrace) kill -USR2 $PID && echo Tracing Cleared;;
! querylog|qrylog) kill -WINCH $PID && echo Query Logging Toggled;;
start)
[ $RUNNING -eq 1 ] && {
echo "$0: start: named (pid $PID) already running"
--- 26,37 ----
echo $ARG
case $ARG in
status) echo "$PS";;
! dumpdb) kill -2 $PID && echo Dumping Database;;
! reload) kill -1 $PID && echo Reloading Database;;
! stats) kill -6 $PID && echo Dumping Statistics;;
! trace) kill -16 $PID && echo Trace Level Incremented;;
! notrace) kill -17 $PID && echo Tracing Cleared;;
! querylog|qrylog) kill -20 $PID && echo Query Logging Toggled;;
start)
[ $RUNNING -eq 1 ] && {
echo "$0: start: named (pid $PID) already running"
--
"Eduard Vopicka, Computing Centre, Prague University of Economics,
W. Churchill Square 4, CZ 130 67 Prague 3" <Eduard.Vopicka@vse.cz>
Also from Eduard Vopicka <Eduard.Vopicka@vse.cz>, Fri, 7 Jun 1996 15:01:39 +0200:
The build procedure for SCO OSE 5 is basically the same as for 3.2v4.2
(described at the top of this document), except for that the hack in
step 2) is a bit different for SCO OSE5:
cd native.b
[ -d include/sys ] || mkdir include/sys
cat >include/sys/param.h <<EOF
#ifndef _SYS_PARAM_H
# include <sys/types.h>
# include <sys/sys.param.h>
#endif
EOF
ln -sf /usr/include/sys/param.h include/sys/sys.param.h

84
usr.sbin/named/doc/info/SCO-2 Normal file
View File

@ -0,0 +1,84 @@
Received: by gw.home.vix.com id AA04543; Sat, 30 Dec 95 17:22:47 -0800
Received: by birdy.ico.net (5.65/940922.1-mjl)
id AA07605; Sat, 30 Dec 95 17:22:44 -0800
Return-Path: <martin@birdy.ico.net>
Message-Id: <9512310122.AA07605@birdy.ico.net>
From: martin@ico.net (Martin J. Levy - ICOnetworks)
X-Mailer: SCO System V Mail (version 3.2)
To: paul@vix.com
Subject: bind release 4.9.3 BETA 34
Date: Sat, 30 Dec 95 17:22:43 PST
Paul,
I'v been using bind on SCO Open Desktop 3.0 and you like to throw these
build/make issues your way.
1) I know the notes for SCO are in "..../doc/info/SCO", but I wanted to bring
to your attention the fact that the "param.h" hack noted there is, well,
a hack. I have include here the list of files that have been edited to
specificly include "types.h". This is not needed on any other OS, but
would not hurt to have in the code.
Ah.. Wait a second. If an OS does not protect the types.h file with a
unique "#ifdef/#endif" then this will not be a good edit to do.
You decide. Here in the list of files I edited. I added the include of
"sys/types.h" as the first include.
res/gethnamaddr.c
res/getnetent.c
res/getnetnamadr.c
res/herror.c
res/inet_addr.c
res/nsap_addr.c
res/res_comp.c
res/res_data.c
res/res_debug.c
res/res_init.c
res/res_mkquery.c
res/res_query.c
res/res_send.c
res/sethostent.c
named/db_lookup.c
named/db_reload.c
named/db_save.c
named/db_update.c
named/named-xfer.c
named/ns_forw.c
named/ns_init.c
named/ns_main.c
named/ns_ncache.c
named/ns_req.c
named/ns_resp.c
named/ns_stats.c
named/ns_validate.c
tools/nslookup/debug.c
tools/nslookup/getinfo.c
tools/nslookup/list.c
tools/nslookup/main.c
tools/nslookup/send.c
tools/nslookup/skip.c
2) I used the standard "cc" compiler from SCO and got the following errors...
cc -DSYSV -DSYSV3 -O -I../include -I../compat/include -D_PATH_XFER=\"/etc/named-xfer\" -D_PATH_PIDFILE=\"/etc/named.pid\" -c ns_forw.c
ns_forw.c
ns_forw.c(406) : warning C4203: '.' : expected left operand to be lvalue
ns_forw.c(422) : warning C4203: '.' : expected left operand to be lvalue
ns_forw.c(431) : warning C4203: '.' : expected left operand to be lvalue
The offending lines look like this....
if (data_inaddr(dp->d_data).s_addr == INADDR_ANY) {
I could recommend that you change this code to use a local variable, but
when I checked the assembly code, All looked ok.
Thats all for now. Thanks for the good work!.
Martin Levy
ICOnetworks

85
usr.sbin/named/doc/info/Solaris Normal file
View File

@ -0,0 +1,85 @@
Replied: Thu, 28 Dec 1995 21:00:45 -0800
Replied: "dupuy@smarts.com (Alexander Dupuy) "
Received: by gw.home.vix.com id AA26157; Tue, 26 Dec 95 14:42:31 -0800
Received: by gw.home.vix.com id AA26153; Tue, 26 Dec 95 14:42:29 -0800
Received: from just.smarts.com by mail.smarts.com (4.1/SMI-4.1)
id AA11178; Tue, 26 Dec 95 17:42:30 EST
Organization: System Management ARTS - "Minds Over Networks"
Received: by just.smarts.com (5.x/SMI-SVR4)
id AA29347; Tue, 26 Dec 1995 17:42:30 -0500
Date: Tue, 26 Dec 1995 17:42:30 -0500
From: dupuy@smarts.com (Alexander Dupuy)
Message-Id: <9512262242.AA29347@just.smarts.com>
To: bind-workers@vix.com
Subject: BIND and Solaris shared library
X-Sun-Charset: US-ASCII
Sun has released a patch for Solaris 2.4 which addresses a security hole in
their implementation of name/address resolution using DNS. Anyone who is
running Solaris 2.4 with DNS specified in their /etc/nsswitch.conf file should
apply this patch. This is true whether you are using the BIND 4.9.3 beta
supplied version of the resolver shared library or the stock Solaris version.
A note should be added to the shres/solaris ISSUES file telling users that
they should get and apply patch 102165-02 to their Solaris system if they want
to use DNS as a hostname resolution method.
The relevant portion of the README file from the patch is included below.
Note that this patch is only available for the SPARC architecture, although
the security hole applies to x86 architecture as well.
@alex
Patch-ID# 102165-02
Keywords: DNS spoofing security nss_dns.so.1
Synopsis: SunOS 5.4: nss_dns.so.1 fixes
Date: Dec/13/95
Solaris Release: 2.4
SunOS Release: 5.4
Unbundled Product:
Unbundled Release:
Topic: SunOS 5.4: nss_dns.so.1 fixes
BugId's fixed with this patch: 1174876 1207777
Changes incorporated in this version: 1207777
Relevant Architectures: sparc
Files included with this patch:
/usr/lib/nss_dns.so.1
Problem Description:
1207777 adding the 102167 patch adds a new security hole and increases traffic/delays
(from 102165-01)
1174876 DNS spoofing possible in 5.3 when using DNS via /usr/lib/nss_dns.so.1
This patch protects the Name Service Switch (DNS Domain Name Service) backend
from DNS spoofing. I.e. a hacker maps an IP address they own to a hostname
that someone trusts (ex. 10.1.0.35 owned by Hacker.COM, to Trusted-host.my.com)
allowing them to perhaps rlogin to another machine. The solution done in 4.x
and the resolver library is after doing a gethostbyaddr() to do a gethostbyname() and check that the IP address given is one that belongs to
the returned hostname.
If IP address passed into gethostbyaddr() does not match an IP address returned
from the gethostbyname() call a SPOOFING error message is syslog-ed and the gethostbyaddr() call returns failure (NOTFOUND). If the gethostbyname() call
FAILS, then the hostname is returned. This is because some people like to register IP addresses BUT not the hostnames in DNS (don't ask why, security through obscurity I guess).
(We will ignore the entire question of basing "security" on IP addresses)
--
inet: dupuy@smarts.com
Member of the League for Programming Freedom -- write to lpf@uunet.uu.net
GCS d?@ H s++: !g p? !au a w v US+++$ C++$ P+ 3 L E++ N+(!N) K- W M V- po- Y+
t+ !5 j R G? tv-- b++ !D B- e>* u+(**)@ h--- f+ r++ n+ y+*

4
usr.sbin/named/doc/info/SunOS Normal file
View File

@ -0,0 +1,4 @@
Installation on SunOS 4.1.x is covered in shres/sunos/{INSTALL,ISSUES,PROBLEMS}.
(Even if you're not changing the shared library, there are SunOS issues
such as UDP checksums that you should read about in shres/sunos/ISSUES.)

33
usr.sbin/named/doc/info/SunSecurity Normal file
View File

@ -0,0 +1,33 @@
Return-Path: bryan@notorious.rs.itd.umich.edu
Received: by gw.home.vix.com; id AA16267; Tue, 12 Oct 93 12:38:33 -0700
Received: from notorious.rs.itd.umich.edu by notorious.rs.itd.umich.edu (5.67/2.25)
with SMTP id AA08439; Tue, 12 Oct 93 15:38:31 -0400
Message-Id: <9310121938.AA08439@notorious.rs.itd.umich.edu>
To: ken@uunet.uu.net (Ken Dahl)
Cc: Paul A Vixie <paul>
From: Bryan Beecher <bryan@umich.edu>
Subject: bind 4.9.2 question
Date: Tue, 12 Oct 93 15:38:30 -0400
Sender: bryan@notorious.rs.itd.umich.edu
> I was rebuilding libc.so on our suns to include the bind 4.9.2
> code, and wanted to disable the SUNSECURITY. However, I noticed that in
> conf/options.h where it forces SUNSECURITY to be defined on suns, it
> claims that it is "mandatory on suns and rlogin etc. depend on this".
> We've disabled this is previous versions of the bind code without
> noticable problems. What are the implications of disabling SUNSECURITY
> on suns?
The C library shipped with SunOS 4.1.3 (and perhaps earlier and later
versions) has some added "security code" inside of gethostbyaddr(). This
code consists of doing a gethostbyname() on the result of a
gethostbyaddr(), and then checking to see if one of the addresses returned
by gethostbyname() matches the original argument to gethostbyaddr(). In
other words, it checks to see that a host has both a PTR record, and a
matching A record.
If you remove the Sun-supplied gethostbyaddr(), and replace it with the one
provided by BIND 4.9.2, and you want the same behavior, then I believe the
SUNSECURITY #ifdef is necessary. If you want a less "fussy"
gethostbyaddr(), then leaving it out is OK.
-- bryan

58
usr.sbin/named/doc/info/SunSecurity-too Normal file
View File

@ -0,0 +1,58 @@
Received: by gw.home.vix.com id AA13091; Fri, 5 Aug 94 12:57:18 -0700
Received: by gw.home.vix.com id AA13087; Fri, 5 Aug 94 12:57:16 -0700
Message-Id: <9408051957.AA13087@gw.home.vix.com>
Received: from duke.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa14838;
5 Aug 94 12:42 PDT
To: bind-workers@vix.com
Subject: SUNSECURITY
Date: Fri, 05 Aug 1994 12:42:40 -0700
From: Greg Wohletz <greg@duke.CS.UNLV.EDU>
[ Steve Bellovin's comment on this:
the advice in conf/Info.SunSecurity-too is wrong and dangerous. Sun
systems have at least one daemon (rpc.mountd) that can't be protected
by Wietse's code but rely on SUNSECURITY for protection.
--vix, 08dec94 ]
We don't use SUNSECURITY on our suns, we use a package called log_tcp,
which consists of a program called tcpd which is invoked by inetd and
does some checking (one of the things it checks (if you define
PARANOID) is the very thing that the SUNSECURITY code checks. It will
also log your connections if you want it to.
Anyway I was thinking that the SUNSECURITY code could potentially be
ripped out of the resolver library and just include the tcpd code in
the contrib section and direct the sun folks to use it.
Certainly this would be a less messy solution.
We've been using this code for a couple of years and have not had any
problems with it. I've included a blurb below if anyone is
interested.
--Greg
@(#) BLURB 1.4 91/10/02 23:02:02
This package provides a couple of tiny programs that log requests for
internet services (examples: TFTP, EXEC, FTP, RSH, TELNET, RLOGIN,
FINGER, SYSTAT). Optional features are: access control based on pattern
matching, and protection against rsh and rlogin attacks from hosts that
pretend to have someone elses host name.
The programs are nothing but small network daemon front ends. By
default, they just log the remote host name and then invoke the real
network daemon daemon, without requiring any changes to existing
software or configuration files.
Connections are reported through the syslog(3) facility. Each record
contains a time stamp, the remote host name and the name of the service
requested. The information can be useful to detect unwanted activities,
especially when logfile information from several hosts is merged.
Enhancements over the previous release are: support for datagram (UDP
and RPC) services, and execution of shell commands when a (remote host,
requested service) pair matches a pattern in the access control tables.
Wietse Venema (wietse@wzv.win.tue.nl),
Eindhoven University of Technology,
The Netherlands.

108
usr.sbin/named/doc/info/Ultrix Normal file
View File

@ -0,0 +1,108 @@
-------- Message 1 of 2
Return-Path: bind-workers-request
Received: by gw.home.vix.com id AA15469; Wed, 15 Dec 93 06:29:03 -0800
Received: by gw.home.vix.com id AA15463; Wed, 15 Dec 93 06:29:00 -0800
Received: from monkeyboy.WPI.EDU (gshapiro@monkeyboy.WPI.EDU [130.215.24.62]) by bigboote.WPI.EDU (8.6.5.Beta3/8.6) with ESMTP id JAA09389; Wed, 15 Dec 1993 09:28:50 -0500
Date: Wed, 15 Dec 93 09:08:10 +0000 (GMT)
From: "Nigel Metheringham" <nigelm@ohm.york.ac.uk>
To: Gregory Neil Shapiro <gshapiro@WPI.EDU>
Subject: Re: sendmail 8 and name resolution
Cc: Paul A Vixie <paul@vix.com>, bind-workers@vix.com, aej@WPI.EDU
} [on compilation of things linked with bind 4.9.2 libresolv]
} I tried to do this but ran into problems. When compiling sendmail
} using libresolv.a from the BIND 4.9.2, the compilation fails since
} things are multiply defined:
}
} [compilation]
} ld:
} /lib/libc.a(gethostent.o): sethostent: multiply defined
} /lib/libc.a(gethostent.o): endhostent: multiply defined
} /lib/libc.a(gethostent.o): gethostbyname: multiply defined
} /lib/libc.a(gethostent.o): gethostbyaddr: multiply defined
} *** Error code 1
}
This must be a bug in the MIPs compiler set - we see very much the
same problem on a MIPs system running 4.52. I put in a bug report
about this a couple of years back (slightly different version of the
OS, but same symptoms). Its relatively complex in that you cannot
reproduce it in a small file (well I can't!).
My hack to get round it was to make a new libresolv.a (actually for
me its libresolv2.a) with the following defines on the cc command
line
-Dgethostbyname=Gethostbyname
-Dgethostbyaddr=Gethostbyaddr
and compile sendmail (or other package with same problems) with the
same defines. Its messy but it works.
[To complicate matters some programs of similar complexity and
network functionality to sendmail do suffer from this problem when
compiling, and some don't!]
Nigel.
---
# Nigel Metheringham -- (NeXT) EMail: nigelm@ohm.york.ac.uk #
# System Administrator, Electronics Dept, University of York #
# York YO1 5DD. Phone: +44 904 432374, Fax: +44 904 432335 #
-------- Message 2 of 2
From: Gregory Neil Shapiro <gshapiro@WPI.EDU>
Received: from localhost (gshapiro@localhost) by monkeyboy.WPI.EDU (8.6.5.Beta3/8.6) id JAA05398; Wed, 15 Dec 1993 09:28:49 -0500
Date: Wed, 15 Dec 1993 09:28:49 -0500
Message-Id: <199312151428.JAA05398@monkeyboy.WPI.EDU>
To: Paul A Vixie <paul@vix.com>
Cc: aej@WPI.EDU, bind-workers@vix.com
Subject: Re: sendmail 8 and name resolution
In-Reply-To: <m0p9sDK-000E9cC@rioja.ohm.york.ac.uk>
References: <m0p9sDK-000E9cC@rioja.ohm.york.ac.uk>
We think we have figured out what local_hostname_length does by trying it
with different inputs. We can't be sure this is its only purpose. It
seems to return the length of a local (in domain) hostname (without domain)
if the hostname has the domain name appended. For example, our domain name
is WPI.EDU. If we called local_hostname_length("manyjars.wpi.edu"), it
returns 8. Other examples:
Host name Length returned
--------- ---------------
manyjars.wpi.edu 8
manyjars 0
nic.near.net 0
With this in mind, we wrote this function:
#include <sys/param.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <arpa/nameser.h>
#include <stdio.h>
#include <resolv.h>
#include <unistd.h>
#include <stdlib.h>
int local_hostname_length(hostname)
char *hostname;
{
int len_host, len_domain;
if (!*_res.defdname) res_init();
if (((len_host = strlen(hostname)) > (len_domain = strlen(_res.defdname))) &&
(strcasecmp(hostname + len_host - len_domain,_res.defdname) == 0) &&
hostname[len_host - len_domain - 1] == '.')
return(len_host - len_domain - 1);
else
return(0);
}
Maybe this can be included in 4.9.2's libresolv.a so it will work properly
under Ultrix without pulling in libc.a's gethostent.o. If anyone has more
information on Ultrix's local_hostname_length, please let me know so we can
come up with a more complete replacement.
-------- End 2 Messages

83
usr.sbin/named/doc/info/Ultrix-VAX Normal file
View File

@ -0,0 +1,83 @@
Received: by gw.home.vix.com id AA21040; Tue, 19 Jul 94 15:20:16 -0700
Received: from localhost (mailer@localhost) by gatekeeper.ray.com (8.6.4/8.6.5) id SAA15612 for <paul@vix.com>; Tue, 19 Jul 1994 18:17:16 -0400
Received: from sccux1.msd.ray.com by gatekeeper.ray.com; Tue Jul 19 18:18:31 1994
Received: (from wag@localhost) by sccux1.msd.ray.com (8.6.9/8.6.9) id SAA29713 for <paul@vix.com>; Tue, 19 Jul 1994 18:18:05 -0400
From: Bill Gianopoulos <wag@sccux1.msd.ray.com>
Message-Id: <199407192218.SAA29713@sccux1.msd.ray.com>
Subject: Info.Ultrix.VAX
To: <paul@vix.com> (Paul A Vixie)
Date: Tue, 19 Jul 1994 18:18:04 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2793
This is the stuff I promised you about linking on a ULTRIX VAX platform.
There is a problem in the Ultrix VAX version of the ld command which
causes problems when linking modules using the bind-4.9.3 resolver
library. The ld command is not working according to the documentation
on its man page which states "If the argument is a library, it is
searched only once at the point it is encountered in the argument list.
Only those routines defining an unresolved external reference are loaded."
In fact, if the library has been processed by ranlib, and a routine
is loaded to resolve an unsatisfied external reference, any other modules
which contain any entry point referenced by that module will be loaded
even if the reference has already been resolved by a previously loaded
module. This causes duplicate entry points to be loaded and results in
ld errors when you try to link.
The approach I use to get around this problem is to split the standard
Ultrix libc.a into 2 libraries, one called liboldres.a which contains
the resolver routines from the Ultrix release libc.a, and a libc.a which
contains everything except the resolver routines.
It is then possible to link using the released Ultrix resolver by specifying
"-loldres" on the ld (or cc) command, or using the new resolver by specifying
"-lresolv -l44bsd".
the shell script I use to create the 2 libraries follows:
#!/bin/sh
#
# Split the released Ultrix libc.a into 2 libraries. The resultant
# libc.a will not contain the resolver routines which are present
# in the new libresolv.a which will be built by the bind install.
# The resolver routines from the released Ultrix libc.a will be
# put in a new liboldres.a library. The original libc.a will be saved
# as libcold.a.
#
if [ -f /usr/lib/libcold.a ]
then
echo "/usr/lib/libcold.a already exists."
exit 1
fi
if [ -f /usr/lib/liboldres.a ]
then
echo "/usr/lib/liboldres.a already exists."
exit 1
fi
rm -r /tmp/libres$$
mkdir /tmp/libres$$
cd /tmp/libres$$
ar x /usr/lib/libc.a gethostent.o getnetent.o herror.o res_comp.o \
res_debug.o res_init.o res_mkquery.o res_query.o \
res_send.o
ar r /usr/lib/liboldres.a *.o
ranlib /usr/lib/liboldres.a
cd /tmp
rm -r libres$$
cp /usr/lib/libc.a /usr/lib/libcold.a
ar d /usr/lib/libc.a gethostent.o getnetent.o herror.o res_comp.o \
res_debug.o res_init.o res_mkquery.o res_query.o \
res_send.o
ranlib /usr/lib/libc.a
--
William A. Gianopoulos; Raytheon Missile Systems Division
wag@sccux1.msd.ray.com
-------------------------------------------------------------------------
My opinions are my own and do not in any way represent the opinions of my
employer.
-------------------------------------------------------------------------

78
usr.sbin/named/doc/info/Ultrix-hesiod Normal file
View File

@ -0,0 +1,78 @@
Return-Path: bind-workers-request
Received: by gw.home.vix.com id AA04567; Fri, 28 Jan 94 13:20:51 -0800
Received: by gw.home.vix.com id AA04555; Fri, 28 Jan 94 13:20:48 -0800
Received: from monkeyboy.WPI.EDU (gshapiro@monkeyboy.WPI.EDU [130.215.24.62]) by bigboote.WPI.EDU (8.6.6.Beta0/8.6) with ESMTP id QAA02114; Fri, 28 Jan 1994 16:20:44 -0500
From: Gregory Neil Shapiro <gshapiro@WPI.EDU>
Received: from localhost (gshapiro@localhost) by monkeyboy.WPI.EDU (8.6.6.Beta0/8.6) id QAA14847; Fri, 28 Jan 1994 16:20:42 -0500
Date: Fri, 28 Jan 1994 16:20:42 -0500
Message-Id: <199401282120.QAA14847@monkeyboy.WPI.EDU>
To: bind-workers@vix.com
Cc: aej@WPI.EDU
Subject: BIND 4.9.2 BETA05 resolver problem
We have a major problem with replacing Ultrix's resolver routines with
those in 4.9.2 Beta 5.
Here at WPI we used Hesiod to serve our passwords. 4.9.2's resolver
doesn't go to secondaries for the information if the first nameserver
listed in /etc/resolv.conf isn't responding (i.e. if it dies, the host is
down, or the nameserver is reloading) on any getpw*() call.
Here is my /etc/resolv.conf:
;
; BIND data file.
;
domain WPI.EDU
nameserver 130.215.24.62
nameserver 130.215.24.56
nameserver 130.215.56.45
nameserver 130.215.8.125
Here is a program to show the broken behavior:
#include <sys/param.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <arpa/nameser.h>
#include <stdio.h>
#include <resolv.h>
#include <unistd.h>
#include <stdlib.h>
#include <netdb.h>
main()
{
printf("res.options = %x\n", _res.options);
if (getpwnam("gshapiro"))
printf("Ok\n");
else
printf("No\n");
if (gethostbyname("wpi"))
printf("Ok\n");
else
printf("No\n");
}
If I compile with 4.9.2's resolver:
> cc -I/usr/local/include -I/usr0/CCCtools/BIND/4.9.2/include -I/usr0/CCCtools/BIND/4.9.2/compat/include try.c -o try -lresolv -l44bsd
And run it:
> ./try
res.options = 2c0
No
Ok
If I compile with Ultrix's resolver (built-in to libc.a):
> cc try.c -o try
> ./try
res.options = 2c0
Ok
Ok
4.9.2's resolver doesn't go on to secondaries on the getpw*() call.
However, gethostbyname() calls do properly go to secondaries, it's only the
Hesiod getpw*() calls that fail.

73
usr.sbin/named/doc/info/Ultrix-ncache Normal file
View File

@ -0,0 +1,73 @@
Path: vixie!Pa.dec.com!bind-redist-request
From: hubert@cac.washington.edu (Steve Hubert)
Newsgroups: local.mail.dns.bind
Subject: Negative caching problem
Date: 28 Jan 1994 11:10:29 -0800
Organization: A blearily-installed InterNetNews site
Lines: 45
Sender: daemon@vix.com
Distribution: local
Message-ID: <Pine.3.90.9401280920.18244C-0100000@shiva2.cac.washington.edu>
NNTP-Posting-Host: gw.home.vix.com
X-Received: by gw.home.vix.com id AA01707; Fri, 28 Jan 94 11:10:20 -0800
X-Received: by inet-gw-2.pa.dec.com (5.65/13Jan94)
id AA12608; Fri, 28 Jan 94 11:09:05 -0800
X-Received: from relay1.UU.NET by inet-gw-2.pa.dec.com (5.65/13Jan94)
id AA11016; Fri, 28 Jan 94 10:33:56 -0800
X-Received: by relay1.UU.NET (5.61/UUNET-internet-primary)
id AAwavg00600; Fri, 28 Jan 94 13:11:19 -0500
X-Received: from shiva2.cac.washington.edu by relay1 with SMTP
(5.61/UUNET-internet-primary) id AAwavg00573; Fri, 28 Jan 94 13:11:12 -0500
X-Received: by shiva2.cac.washington.edu
(5.65/UW-NDC Revision: 2.29 ) id AA18978; Fri, 28 Jan 94 10:09:31 -0800
X-To: BIND list <bind@uunet.uu.net>
X-Cc: Namedroppers list <namedroppers@nic.ddn.mil>
X-Mime-Version: 1.0
X-Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Status: seems like an ultrix bug to me
We've been experimenting a little with negative caching and have run into
a problem. The problem is with the Ultrix4.2a gethostbyname() resolver
algorithm. We wonder how widespread this problem is, since I believe this
is based on some old version of BIND.
We have a host carson.u.washington.edu. Suppose I am on a host called
host.cac.washington.edu. I have searching turned on in the resolver
options and a search list of "cac.washington.edu" "washington.edu". If I
try something like "telnet carson.u" here's what can happen. The first
question my resolver asks is for the A record for
carson.u.cac.washington.edu. If it isn't in the negative cache, the answer
may be fetched from an auth. server and an auth. NXDOMAIN returned. If
the answer is in the negative cache the same NXDOMAIN answer will be
returned but it will be non-authoritative. The non-authoritative NXDOMAIN
answer causes the Ultrix search algorithm to terminate the search and not
try the next element which would be carson.u.washington.edu. So "telnet
carson.u" fails with a no such host error. Typically, it works the first
time and then fails the second (when it has been cached). The offending
code is in res_query(). There they have something like:
switch (hp->rcode) {
case NXDOMAIN:
if (hp->aa)
h_errno = HOST_NOT_FOUND;
else
h_errno = TRY_AGAIN;
...
The TRY_AGAIN answer causes the search to terminate early in res_search().
The 4.9.2 version of this same piece of code is simply:
switch (hp->rcode) {
case NXDOMAIN:
h_errno = HOST_NOT_FOUND;
...
So, the question is, is this just an Ultrix bug in gethostent.c, or did
it originate with some old BIND and might it therefore be much more
widespread?
Thanks,
Steve Hubert <hubert@cac.washington.edu>
Networks and Distributed Computing, Univ. of Washington, Seattle

49
usr.sbin/named/doc/info/glue Normal file
View File

@ -0,0 +1,49 @@
Path: vixie!Pa.dec.com!bind-redist-request
From: bryan@notorious.rs.itd.umich.edu (Bryan Beecher)
Newsgroups: local.mail.dns.bind
Subject: When and why to use glue (was glue)
Date: 2 Mar 1994 07:37:27 -0800
Organization: University of Michigan
Lines: 32
Sender: daemon@vix.com
Distribution: local
Message-ID: <2l2b0j$463@lastactionhero.rs.itd.umich.edu>
X-To: info-bind@uunet.uu.net
X-Path: notorious.rs.itd.umich.edu!bryan
X-Newsgroups: info.bind
X-Lines: 32
X-References: <Pine.3.88.9403011334.A12750-0100000@eros.unm.edu>
X-Nntp-Posting-Host: notorious.rs.itd.umich.edu
hamjavar@unm.edu (Farid Hamjavar) asks:
>
>What's the rule [ for glue ] ?
A glue record is an A record for a name that appears on the right-hand side
of a NS record. So, if I have this:
itd.umich.edu. IN NS dns2.itd.umich.edu.
dns2.itd.umich.edu. IN A 141.211.164.3
then the second record is a glue record (for the NS record above it).
You need glue records when -- and only when -- you are delegating authority
to a nameserver that "lives" in the domain you are delegating. In other
words, in the example above, I need to add an A record for dns2.itd.umich.edu
since it "lives" in the domain it serves. This boot-strapping information
is necessary: How am I supposed to find out the IP address of the nameserver
for domain FOO if the nameserver for FOO "lives" in FOO?
If I have this NS record:
itd.umich.edu. IN NS dns.cs.wisc.edu.
I do NOT need a glue record, and, in fact, adding one is a very bad idea.
If I add one, and then the folks at U Wisconsin change the address, then I am
passing out incorrect data.
Also, unless you actually have a machine called something.IN-ADDR.ARPA, you
will never have any glue records present in any of your "reverse" files.
--
Bryan Beecher, U-M Information Technology Division (+1 313 747 4050)
Domain: Bryan.Beecher@umich.edu Path: ..!uunet!destroyer!bryan

57
usr.sbin/named/doc/info/glue.2 Normal file
View File

@ -0,0 +1,57 @@
Path: vixie!Pa.dec.com!bind-redist-request
From: hubert@cac.washington.edu (Steve Hubert)
Newsgroups: local.mail.dns.bind
Subject: Re: When and why to use glue (was glue)
Date: 2 Mar 1994 10:52:01 -0800
Organization: A blearily-installed InterNetNews site
Lines: 43
Sender: daemon@vix.com
Distribution: local
Message-ID: <Pine.3.90.9403021049.21252F-0100000@shiva2.cac.washington.edu>
X-To: info-bind@uunet.uu.net
X-In-Reply-To: <2l2b0j$463@lastactionhero.rs.itd.umich.edu>
X-Content-Type: TEXT/PLAIN; charset=US-ASCII
On 2 Mar 1994, Bryan Beecher wrote:
> hamjavar@unm.edu (Farid Hamjavar) asks:
> >
> >What's the rule [ for glue ] ?
>
> A glue record is an A record for a name that appears on the right-hand side
> of a NS record. So, if I have this:
>
> itd.umich.edu. IN NS dns2.itd.umich.edu.
> dns2.itd.umich.edu. IN A 141.211.164.3
>
> then the second record is a glue record (for the NS record above it).
>
> You need glue records when -- and only when -- you are delegating authority
> to a nameserver that "lives" in the domain you are delegating. In other
> words, in the example above, I need to add an A record for dns2.itd.umich.edu
> since it "lives" in the domain it serves. This boot-strapping information
> is necessary: How am I supposed to find out the IP address of the nameserver
> for domain FOO if the nameserver for FOO "lives" in FOO?
Bryan's analysis is right on the mark as always. I hope I'm not just
muddying the waters by mentioning this, but I've found the information
useful. There is also a sort of implicit glue record that can be useful
(or confusing). If the parent server (itd.umich.edu domain in example
above) is a secondary server for the child, then the A record will be
fetched from the child server when the zone transfer is done. The glue is
still there but it's a little different, it's in the ip address in the
named.boot line instead of explicitly in the data. In this case (common
for us) you can leave out the explicit glue A record and leave the
manually configured "glue" in just the one place in the named.boot file.
So, a slightly revised rule for when you need a glue record is:
You need glue records when -- and only when -- you are delegating
authority to a nameserver that "lives" in the domain you are delegating
*and* you aren't a secondary server for that domain.
(Hope this helps more than hurts.)
Steve Hubert <hubert@cac.washington.edu>
Networks and Distributed Computing, Univ. of Washington, Seattle

76
usr.sbin/named/doc/info/ibm-dyndns Normal file
View File

@ -0,0 +1,76 @@
Delivery-Date: Tue, 12 Sep 1995 19:35:04 -0700
Return-Path: edie@watson.ibm.com
Received: by gw.home.vix.com id AA26254; Tue, 12 Sep 95 19:35:03 -0700
Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 6121;
Tue, 12 Sep 95 22:34:27 EDT
Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.02 on VAGENT2"
id 2126; Tue, 12 Sep 1995 22:34:26 EDT
Received: from edisto.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx)
with TCP; Tue, 12 Sep 95 22:34:26 EDT
Received: by edisto.watson.ibm.com (AIX 3.2/UCB 5.64/900524)
id AA20787; Tue, 12 Sep 1995 22:31:40 -0400
Message-Id: <9509130231.AA20787@edisto.watson.ibm.com>
X-External-Networks: yes
To: paul@vix.com
Cc: bind-workers@vix.com
Subject: IBM's Dynamic DNS implementation
Date: Tue, 12 Sep 95 22:31:35 -0500
From: "Edie E. Gunter" <edie@watson.ibm.com>
Hi Paul,
I've just ftp'd the file ibmddns.tar.gz to ftp.vix.com and
put it in your /incoming directory. This is the dynamic
DNS implementation IBM said it would donate to the public
domain at the IETF in Stockholm in July.
The changes were made against the 4.9.3 BETA26 version of
BIND. The ibmddns.tar file has a patch list and another tar file
with several new files.
The implementation of dynamic updates is based
on the August 1995 draft-ieft-dnsind-dynDNS-03.txt file.
Also included is implementation of KEY and SIG RR's as per
the June 25, 1995 draft-ietf-dnssec-secext-04.txt file. This
implementation uses the BSAFE Cryptographic Toolkit for
RSA security. This toolkit is not included, but is
available for purchase from RSA Data Security, Inc.
(email: info@rsa.com) Additionally, the code can be
compiled without security (see conf/options.h), but this
probably isn't a good idea.
There are also appropriate #ifdefs and makefiles and other
minor changes necessary to make this code build on OS/2.
There is a file dyndns.setup that will lead you through
the steps necessary to set everything up and use a new
test tool we've provided to actually perform an update.
I should mention here a few caveats:
- The ZoneName update type was not implemented.
- On completion of an update, the master file for the
zone is rewritten.
- On an error, to return the database to the state it was in
prior to the start of processing this update, the master file
for this zone is re-read.
- The secondary can only forward updates to the primary using
UDP. (The TCP code was not implemented.)
- There is no code in the resolver to search the universe for
an authoritative server to handle an update. The resolver
API we implemented requires that the primary name be known
and specified in the API calls.
If you have any questions or problems with this code, please
don't hesitate to call (or email). We hope you (and the rest
of the BIND community) will be able to make some good use of this
work.
Edie Gunter

574
usr.sbin/named/doc/info/interactive Normal file
View File

@ -0,0 +1,574 @@
Delivery-Date: Tue, 22 Aug 1995 21:19:12 -0700
Return-Path: jjb@jagware.bcc.com
Received: by gw.home.vix.com id AA29584; Tue, 22 Aug 95 21:19:06 -0700
Received: by jagware.bcc.com (/\oo/\ Smail3.1.29.1 #29.3)
id <m0sl7Gu-00001yC@jagware.bcc.com>; Tue, 22 Aug 95 21:18 PDT
Message-Id: <m0sl7Gu-00001yC@jagware.bcc.com>
From: jjb@jagware.bcc.com (J.J.Bailey)
Subject: ISC UNIX patches for bind-4.9.3-BETA26
To: paul@vix.com
Date: Tue, 22 Aug 1995 21:18:36 -0700 (PDT)
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 12688
The following patches are required to get bind-4.9.3-BETA26 to compile
in ISC UNIX version 4.1.
1) Almost every patch is because sys/types.h needs to be included: the
defines in conf/portability.h are too late
2) ns_main.c needs the include files to be included in a different order, so
I used an include guard to include sys/stream.h earlier
3) M_UNIX and _SYSV3 need to be defined on the command line
4) The makefile in the nslookup directory needs the .c to .o rule modified
or the .o files are placed into the current directory, causing linking
to fail
5) There is no libbsd.a
-Jack
--
J.J.Bailey
Consultant
jjb@jagware.bcc.com
*** Makefile- Tue Aug 22 21:08:31 1995
--- Makefile Tue Aug 22 21:09:29 1995
***************
*** 540,551 ****
#PS = ps -p
#IOT = IOT
! #(ISC4.0 using GCC)
! #CC = gcc -DISC -posix
#CPPFLAGS =
#CDEBUG = -g
#LEX = flex -I
! #LIBS = -lbsd
#PIDDIR = /etc
#DESTBIN = /usr/bin
#DESTSBIN = /etc
--- 540,551 ----
#PS = ps -p
#IOT = IOT
! #(ISC4.1 using GCC)
! #CC = gcc -DISC -posix -DM_UNIX -D_SYSV3
#CPPFLAGS =
#CDEBUG = -g
#LEX = flex -I
! #LIBS = -linet -ll
#PIDDIR = /etc
#DESTBIN = /usr/bin
#DESTSBIN = /etc
*** conf/portability.h- Thu Jun 29 02:25:57 1995
--- conf/portability.h Tue Aug 22 21:00:05 1995
***************
*** 75,87 ****
# endif
# define SYSV
# define SVR3
! # define _SYSV3
# define NEED_STRTOUL
# define NEED_FTRUNCATE
# define USE_POSIX
# include <sys/bsdtypes.h>
# include <sys/sioctl.h>
! # include <sys/stream.h>
# include <net/errno.h>
#endif
--- 75,91 ----
# endif
# define SYSV
# define SVR3
! # if #defined(_SYSV3)
! # define _SYSV3
! # endif
# define NEED_STRTOUL
# define NEED_FTRUNCATE
# define USE_POSIX
# include <sys/bsdtypes.h>
# include <sys/sioctl.h>
! # if !defined(_H_STREAM)
! # include <sys/stream.h>
! # endif
# include <net/errno.h>
#endif
*** named/db_lookup.c- Thu Jun 29 02:26:19 1995
--- named/db_lookup.c Tue Aug 22 20:53:12 1995
***************
*** 64,69 ****
--- 64,72 ----
#include <syslog.h>
#include <sys/param.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #endif
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/nameser.h>
*** named/db_reload.c- Wed Dec 14 22:24:16 1994
--- named/db_reload.c Tue Aug 22 20:53:12 1995
***************
*** 59,64 ****
--- 59,67 ----
*/
#include <sys/param.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #endif
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/nameser.h>
*** named/db_save.c- Thu Jun 29 02:26:19 1995
--- named/db_save.c Tue Aug 22 20:53:12 1995
***************
*** 63,68 ****
--- 63,71 ----
*/
#include <sys/param.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #endif
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/nameser.h>
*** named/db_update.c- Thu Jun 29 02:26:19 1995
--- named/db_update.c Tue Aug 22 20:53:12 1995
***************
*** 62,67 ****
--- 62,70 ----
#include <syslog.h>
#include <sys/param.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #endif
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
*** named/named-xfer.c- Thu Jun 29 02:26:20 1995
--- named/named-xfer.c Tue Aug 22 20:53:13 1995
***************
*** 74,79 ****
--- 74,84 ----
#endif /* not lint */
#include <sys/param.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #include <sys/stream.h>
+ #define _H_STREAM /* include guard for portability.h */
+ #endif
#include <sys/file.h>
#include <sys/stat.h>
#include <sys/socket.h>
*** named/ns_forw.c- Mon Aug 21 22:01:45 1995
--- named/ns_forw.c Tue Aug 22 20:53:13 1995
***************
*** 59,64 ****
--- 59,67 ----
*/
#include <sys/param.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #endif
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
*** named/ns_init.c- Sun Aug 20 18:27:18 1995
--- named/ns_init.c Tue Aug 22 20:53:13 1995
***************
*** 59,64 ****
--- 59,67 ----
*/
#include <sys/param.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #endif
#include <sys/socket.h>
#include <sys/stat.h>
#include <netinet/in.h>
*** named/ns_main.c- Sun Aug 20 18:27:19 1995
--- named/ns_main.c Tue Aug 22 20:53:13 1995
***************
*** 71,76 ****
--- 71,81 ----
*/
#include <sys/param.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #include <sys/stream.h>
+ #define _H_STREAM /* include guard for portability.h */
+ #endif
#include <sys/file.h>
#include <sys/stat.h>
#if !defined(SYSV) && defined(XXX)
*** named/ns_ncache.c- Wed Jun 28 14:00:34 1995
--- named/ns_ncache.c Tue Aug 22 20:53:14 1995
***************
*** 7,12 ****
--- 7,15 ----
*/
#include <sys/param.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #endif
#include <sys/socket.h>
#include <sys/file.h>
#include <netinet/in.h>
*** named/ns_req.c- Mon Aug 21 22:01:46 1995
--- named/ns_req.c Tue Aug 22 20:53:14 1995
***************
*** 59,64 ****
--- 59,67 ----
*/
#include <sys/param.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #endif
#include <sys/uio.h>
#include <sys/file.h>
#include <sys/socket.h>
*** named/ns_resp.c- Sun Aug 20 18:27:21 1995
--- named/ns_resp.c Tue Aug 22 20:53:14 1995
***************
*** 59,64 ****
--- 59,67 ----
*/
#include <sys/param.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #endif
#include <sys/socket.h>
#include <sys/file.h>
#include <netinet/in.h>
*** named/ns_stats.c- Thu Jun 29 02:26:25 1995
--- named/ns_stats.c Tue Aug 22 20:53:15 1995
***************
*** 64,69 ****
--- 64,72 ----
/**************************************************************************/
#include <sys/param.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #endif
#include <netinet/in.h>
#include <arpa/nameser.h>
#include <arpa/inet.h>
*** named/ns_validate.c- Wed Jun 28 14:17:31 1995
--- named/ns_validate.c Tue Aug 22 20:53:15 1995
***************
*** 8,13 ****
--- 8,16 ----
*/
#include <sys/param.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #endif
#include <sys/socket.h>
#include <sys/file.h>
#include <netinet/in.h>
*** res/gethnamaddr.c- Mon Aug 21 22:01:48 1995
--- res/gethnamaddr.c Tue Aug 22 20:53:15 1995
***************
*** 59,64 ****
--- 59,67 ----
#endif /* LIBC_SCCS and not lint */
#include <sys/param.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #endif
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
*** res/getnetent.c- Mon Jun 19 01:35:01 1995
--- res/getnetent.c Tue Aug 22 20:53:15 1995
***************
*** 47,52 ****
--- 47,55 ----
#endif /* LIBC_SCCS and not lint */
#include <sys/param.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #endif
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
*** res/getnetnamadr.c- Thu Jun 29 02:26:28 1995
--- res/getnetnamadr.c Tue Aug 22 20:53:15 1995
***************
*** 45,50 ****
--- 45,54 ----
#endif /* LIBC_SCCS and not lint */
#include <sys/param.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #include <net/errno.h>
+ #endif
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
*** res/herror.c- Mon Jun 19 01:35:02 1995
--- res/herror.c Tue Aug 22 20:53:15 1995
***************
*** 59,64 ****
--- 59,67 ----
#endif /* LIBC_SCCS and not lint */
#include <sys/param.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #endif
#include <sys/uio.h>
#include <netdb.h>
#if defined(BSD) && (BSD >= 199103)
*** res/inet_addr.c- Sun Aug 20 18:27:23 1995
--- res/inet_addr.c Tue Aug 22 20:53:15 1995
***************
*** 59,64 ****
--- 59,67 ----
#endif /* LIBC_SCCS and not lint */
#include <sys/param.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #endif
#include <netinet/in.h>
#include <arpa/inet.h>
#include <ctype.h>
*** res/nsap_addr.c- Thu Jun 29 02:26:28 1995
--- res/nsap_addr.c Tue Aug 22 20:53:15 1995
***************
*** 3,8 ****
--- 3,11 ----
#endif /* LIBC_SCCS and not lint */
#include <sys/param.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #endif
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/nameser.h>
*** res/res_comp.c- Mon Jun 19 01:35:02 1995
--- res/res_comp.c Tue Aug 22 20:53:16 1995
***************
*** 59,64 ****
--- 59,67 ----
#endif /* LIBC_SCCS and not lint */
#include <sys/param.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #endif
#include <netinet/in.h>
#include <arpa/nameser.h>
*** res/res_debug.c- Mon Aug 21 00:22:22 1995
--- res/res_debug.c Tue Aug 22 20:53:16 1995
***************
*** 59,64 ****
--- 59,67 ----
#endif /* LIBC_SCCS and not lint */
#include <sys/param.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #endif
#include <netinet/in.h>
#include <arpa/inet.h>
#include <arpa/nameser.h>
*** res/res_init.c- Thu Jun 29 02:26:29 1995
--- res/res_init.c Tue Aug 22 20:53:16 1995
***************
*** 59,64 ****
--- 59,67 ----
#endif /* LIBC_SCCS and not lint */
#include <sys/param.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #endif
#include <sys/socket.h>
#include <sys/time.h>
#include <netinet/in.h>
*** res/res_mkquery.c- Thu Jun 29 02:26:30 1995
--- res/res_mkquery.c Tue Aug 22 20:53:16 1995
***************
*** 59,64 ****
--- 59,67 ----
#endif /* LIBC_SCCS and not lint */
#include <sys/param.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #endif
#include <netinet/in.h>
#include <arpa/nameser.h>
*** res/res_query.c- Thu Jun 29 02:26:30 1995
--- res/res_query.c Tue Aug 22 20:53:16 1995
***************
*** 59,64 ****
--- 59,67 ----
#endif /* LIBC_SCCS and not lint */
#include <sys/param.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #endif
#include <netinet/in.h>
#include <arpa/inet.h>
#include <arpa/nameser.h>
*** res/res_send.c- Sun Aug 20 18:27:24 1995
--- res/res_send.c Tue Aug 22 20:53:16 1995
***************
*** 71,76 ****
--- 71,79 ----
#include <sys/param.h>
#include <sys/time.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #endif
#include <sys/socket.h>
#include <sys/uio.h>
#include <netinet/in.h>
*** res/sethostent.c- Thu Jun 29 02:26:31 1995
--- res/sethostent.c Tue Aug 22 20:53:16 1995
***************
*** 37,42 ****
--- 37,45 ----
#endif /* LIBC_SCCS and not lint */
#include <sys/param.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #endif
#include <netinet/in.h>
#include <arpa/nameser.h>
#include <netdb.h>
*** tools/Makefile- Mon Aug 21 22:01:49 1995
--- tools/Makefile Tue Aug 22 20:53:17 1995
***************
*** 152,157 ****
--- 152,160 ----
cd nslookup; ${MAKE} ${MARGS} tags
ctags ${SRCS}
+ .c.o:
+ $(CC) -c $(CFLAGS) $*.c -o $*.o
+
FRC:
# DO NOT DELETE THIS LINE -- mkdep uses it.
*** tools/nslookup/debug.c- Thu Jun 29 02:26:35 1995
--- tools/nslookup/debug.c Tue Aug 22 20:53:17 1995
***************
*** 71,76 ****
--- 71,79 ----
*/
#include <sys/param.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #endif
#include <netinet/in.h>
#include <arpa/nameser.h>
#include <arpa/inet.h>
*** tools/nslookup/getinfo.c- Wed Dec 14 22:24:32 1994
--- tools/nslookup/getinfo.c Tue Aug 22 20:53:17 1995
***************
*** 72,77 ****
--- 72,80 ----
*/
#include <sys/param.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #endif
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/nameser.h>
*** tools/nslookup/list.c- Mon Dec 19 00:35:16 1994
--- tools/nslookup/list.c Tue Aug 22 20:53:17 1995
***************
*** 71,76 ****
--- 71,79 ----
*/
#include <sys/param.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #endif
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/nameser.h>
*** tools/nslookup/main.c- Wed Dec 14 22:24:32 1994
--- tools/nslookup/main.c Tue Aug 22 20:53:17 1995
***************
*** 81,86 ****
--- 81,89 ----
#include <sys/param.h>
#include <netdb.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #endif
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/nameser.h>
*** tools/nslookup/send.c- Wed Dec 14 22:24:33 1994
--- tools/nslookup/send.c Tue Aug 22 20:53:17 1995
***************
*** 77,82 ****
--- 77,85 ----
#include <sys/param.h>
#include <sys/time.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #endif
#include <sys/socket.h>
#include <sys/uio.h>
#include <netinet/in.h>
*** tools/nslookup/skip.c- Wed Dec 14 22:24:33 1994
--- tools/nslookup/skip.c Tue Aug 22 20:53:18 1995
***************
*** 76,81 ****
--- 76,84 ----
*/
#include <sys/param.h>
+ #if defined(ISC)
+ #include <sys/types.h>
+ #endif
#include <netinet/in.h>
#include <arpa/nameser.h>
#include <resolv.h>

138
usr.sbin/named/doc/info/interactive-2 Normal file
View File

@ -0,0 +1,138 @@
Replied: Sun, 31 Dec 1995 12:41:34 -0800
Replied: "kuriyama@unix.cpf.navy.mil (Kent Kuriyama) "
Received: by gw.home.vix.com id AA10367; Sun, 31 Dec 95 11:00:28 -0800
Received: by unix.cpf.navy.mil (5.65/1.35)
id AA28534; Sun, 31 Dec 95 09:01:34 -1000
From: kuriyama@unix.cpf.navy.mil (Kent Kuriyama)
Message-Id: <9512311901.AA28534@unix.cpf.navy.mil>
Subject: ISC 4.1 changes to bind beta 34
To: paul@vix.com
Date: Sun, 31 Dec 1995 09:01:33 -1000 (HST)
Cc: kuriyama@unix.cpf.navy.mil (Kent Kuriyama)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 3419
Paul,
Enclosed is a 'diff' file that contains the changes necessary to port
bind BETA34 under ISC 4.1 (using gcc 2.7.2). In the diff file below
the sub-directory 'beta34' contained the modified sources.
I have the software up and running - no problems so far. Thank you
for your efforts.
Kent Kuriyama
---------------
Common subdirectories: beta34.orig/BSD and beta34/BSD
diff --unif=2 beta34.orig/Makefile beta34/Makefile
--- beta34.orig/Makefile Fri Dec 29 11:08:15 1995
+++ beta34/Makefile Sun Dec 31 08:27:12 1995
@@ -582,23 +582,32 @@
#IOT = IOT
-#(ISC4.0 using GCC)
-#CC = gcc -DISC -posix
-#CPPFLAGS =
-#CDEBUG = -g
-#LEX = flex -I
-#LIBS = -lbsd
-#PIDDIR = /etc
-#DESTBIN = /usr/bin
-#DESTSBIN = /etc
-#DESTEXEC = /etc
-#DESTHELP = /etc
-#DESTMAN = /usr/catman/l_man
-#CATEXT = $$$$N
-#RANLIB = @:
-#LDS = @:
-#PS = ps -p
-#ARPREF = `lorder
-#ARSUFF = | tsort`
-#IOT = IOT
+#(ISC4.1 using GCC 2.7.2)
+#
+# Notes:
+#
+# 1) The 'gettimeofday' routine seems to be broken on ISC.
+# Using the one supplied in 'compat/lib'.
+# 2) Needed to modify some ISC supplied include files so that
+# they would automatically include other files.
+#
+CC = gcc -DISC -posix
+CPPFLAGS =
+CDEBUG = -g
+LEX = flex -I
+LIBS = -ll -linet
+PIDDIR = /etc
+DESTBIN = /usr/bin
+DESTLIB = /usr/local/lib
+DESTSBIN = /etc
+DESTEXEC = /etc
+DESTHELP = /etc
+DESTMAN = /usr/catman/l_man
+CATEXT = $$$$N
+RANLIB = @:
+LDS = @:
+PS = ps -p
+ARPREF =
+ARSUFF =
+IOT = IOT
# AUX 3.x (I used 3.1.1)
Common subdirectories: beta34.orig/bin and beta34/bin
Common subdirectories: beta34.orig/compat and beta34/compat
Common subdirectories: beta34.orig/conf and beta34/conf
Common subdirectories: beta34.orig/contrib and beta34/contrib
Common subdirectories: beta34.orig/doc and beta34/doc
Common subdirectories: beta34.orig/include and beta34/include
Common subdirectories: beta34.orig/man and beta34/man
Common subdirectories: beta34.orig/named and beta34/named
Common subdirectories: beta34.orig/res and beta34/res
Common subdirectories: beta34.orig/shres and beta34/shres
Common subdirectories: beta34.orig/tools and beta34/tools
diff -r --unif=2 beta34.orig/res/getnetnamadr.c beta34/res/getnetnamadr.c
--- beta34.orig/res/getnetnamadr.c Wed Jun 28 23:26:28 1995
+++ beta34/res/getnetnamadr.c Sat Dec 30 22:34:53 1995
@@ -45,4 +45,8 @@
#endif /* LIBC_SCCS and not lint */
+#ifdef ISC
+#include <net/errno.h>
+#endif
+
#include <sys/param.h>
#include <sys/socket.h>
diff -r --unif=2 beta34.orig/compat/lib/ftruncate.c beta34/compat/lib/ftruncate.c
--- beta34.orig/compat/lib/ftruncate.c Wed Dec 14 20:23:51 1994
+++ beta34/compat/lib/ftruncate.c Sat Dec 30 22:39:24 1995
@@ -11,5 +11,5 @@
#endif
-#if defined(M_UNIX)
+#if defined(M_UNIX) || defined(ISC)
#define OWN_FTRUNCATE
#include <stdio.h>
diff -r --unif=2 beta34.orig/conf/portability.h beta34/conf/portability.h
--- beta34.orig/conf/portability.h Fri Dec 22 00:20:20 1995
+++ beta34/conf/portability.h Sun Dec 31 07:58:01 1995
@@ -80,4 +80,5 @@
# define NEED_STRTOUL
# define NEED_FTRUNCATE
+# define NEED_GETTIMEOFDAY
# define USE_POSIX
# include <sys/bsdtypes.h>
diff -r --unif=2 beta34.orig/tools/dig.c beta34/tools/dig.c
--- beta34.orig/tools/dig.c Fri Dec 29 11:08:18 1995
+++ beta34/tools/dig.c Sat Dec 30 22:37:54 1995
@@ -144,4 +144,7 @@
#define VSTRING "2.1"
+#ifdef ISC
+#define _SYSV3
+#endif
#include <sys/types.h>
#include <sys/param.h>

59
usr.sbin/named/doc/info/local-hosts-file Normal file
View File

@ -0,0 +1,59 @@
Path: vixie!pa.dec.com!bind-redist-request
From: gdonl@gv.ssi1.com (Don Lewis)
Newsgroups: local.mail.dns.bind
Subject: Re: Shared Libraries
Date: 12 Apr 1995 17:11:49 -0700
Organization: Vixie Enterprises
Lines: 31
Sender: daemon@vix.com
Distribution: local
Message-ID: <199504122344.QAA29009@sunrise.gv.ssi1.com>
NNTP-Posting-Host: gw.home.vix.com
X-Received: by gw.home.vix.com id AA24343; Wed, 12 Apr 95 17:11:47 -0700
X-Received: from pobox1.pa.dec.com by inet-gw-1.pa.dec.com (5.65/24Feb95)
id AA13489; Wed, 12 Apr 95 17:06:00 -0700
X-Received: by pobox1.pa.dec.com; id AA01975; Wed, 12 Apr 95 17:05:50 -0700
X-Received: by pobox1.pa.dec.com; id AA01971; Wed, 12 Apr 95 17:05:49 -0700
X-Received: from relay3.UU.NET by inet-gw-1.pa.dec.com (5.65/24Feb95)
id AA13261; Wed, 12 Apr 95 17:00:31 -0700
X-Received: by relay3.UU.NET
id QQylfb12065; Wed, 12 Apr 1995 19:45:03 -0400
X-Received: from sunrise.gv.ssi1.com by relay3.UU.NET with SMTP
id QQylfb12054; Wed, 12 Apr 1995 19:45:01 -0400
X-Received: (from gdonl@localhost) by sunrise.gv.ssi1.com (8.6.11/8.6.11) id QAA29009; Wed, 12 Apr 1995 16:44:51 -0700
X-In-Reply-To: Yvon.Bori@pt.nce.sita.int (Yvon Bori (+33) 92.96.63.19)
"Shared Libraries" (Apr 12, 10:52am)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
X-To: Yvon.Bori@pt.nce.sita.int (Yvon Bori (+33) 92.96.63.19), bind@uunet.uu.net
On Apr 12, 10:52am, Yvon Bori (+33) 92.96.63.19 wrote:
} Subject: Shared Libraries
} Here is my new fight in Bind 4.9.3 B17 installation :
} All could have been clean, but at reboot time I get the message :
} Starting system logger
} Starting local daemons: auditdApr 12 11:19:40 ns2 syslogd: line 36: unknown host
}
} ns2 is the name of the machine.
} loghost is well defined in the /etc/hosts file but it looks like this file wasn't
} read.
} Is there a way to specify that the hosts file has to be read or does loghost must be
} specified in the DNS database? This error don't seems to be fixed in the Bind package?
With this resolver, there is no way to reference /etc/hosts. You can either
put loghost in the DNS database, or another possibility is to do what I've
done here. I changed the invokation of syslogd in /etc/rc.local to:
HOSTALIASES=/etc/hostaliases syslogd
and I created the file /etc/hostaliases and put the following in it:
loghost localhost.gv.ssi1.com
You'll have to modify this with your local domain. If you use localhost
instead of a central log host, you'll need the localhost entry in DNS.
--- Truck

28
usr.sbin/named/doc/info/nsmaint Normal file
View File

@ -0,0 +1,28 @@
Date: Mon, 26 Apr 1993 18:06:39 -0400
From: Andy Poling <andy@jhunix.hcf.jhu.edu>
Subject: Re: Long Running Dream (was Re: send me your to-do lists)
To: Mohamed Ellozy <ellozy@farber.harvard.edu>
Cc: bind@uunet.UU.NET, bind-4.9@inet-gw-2.pa.dec.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 26 Apr 1993, Andy Poling writes
>I'm afraid I removed it from my anonymous FTP archive a few months ago.
>It seemed out-of-date enough that it just might be dangerous if someone
>actually expected it to still be useful. :-)
>
>I didn't even keep the source around - it just didn't really seem useful
>anymore.
I have it! I took Dennis Ferguson's nsmaint code and added Andy's
check_boot code and bundled it up into a inhanced nsmaint. Together
with Theodore Ts'o ninit, these programs pretty much run the show
here. Our staff can reload the server by typing "nsmaint hup" which
does a check on the boot files before reloading. Some of my recoding
is dreadful :), but it works very well. I'm sure someone out there
could grab it, cover my sins, and make it better. I stuck in the ftp
area on indiana.edu as nsmaint.tar.Z which includes the ninit stuff too.
Regards,
Steve Mosier @ Indiana University

39
usr.sbin/named/doc/info/sVr4 Normal file
View File

@ -0,0 +1,39 @@
(Message inbox:59)
Date: Wed, 17 Mar 93 17:08:36 CST
From: sblair@upurbmw.dell.com
Subject: bind 4.9 porting to SVR4..
To: vixie
Cc: cwg@dell.com
[ I can't remember if it's 4.9, or 5.0 ]
If one defines the following in the top of the opt-level makefile, it does
indeed build, and work on SVR4 Intel boxes:
CC = cc-bsd -DBSD -DPOSIX
Also, one has to change the cd $x(for dir's) Makefiles' install to
be /usr/ucb/install as the SVR4 one don't have the options BSD
does.
It seems to deal real well with authorative as well as non-authorative
answers. Speed is much better than stock USL SVR4 nslookup, and nstest.
I made NO code changes after figuring out the compiler options. I setup
a rogue secondary on my machine here, upurbmw.dell.com and will keep
you and cwg advised as to what's up.
--
Steve Blair DELL NETWORK SERVICES sblair@dell.com hostmaster@dell.com
==============================================================================
If every american puts $ 29,999 as salary, and takes the remainder and
puts it into a 401K(or other deferment plan), then TAXES WON'T HELP !!!!!!!!!
Addendum:
The above notes are out of date and no longer work with this version of
BIND. Look for the SVR4.0.4 makefile entry and start working from that.
It should compile out of the box with those settings on just about every
i386 SVR4.0 and SVR4.2 (including Novell's Unixware)

99
usr.sbin/named/doc/info/sequent Normal file
View File

@ -0,0 +1,99 @@
Delivery-Date: Mon, 19 Jun 1995 18:58:27 -0700
Return-Path: bind-workers-request@vix.com
Received: by gw.home.vix.com id AA22025; Mon, 19 Jun 95 18:54:03 -0700
Received: by gw.home.vix.com id AA22021; Mon, 19 Jun 95 18:54:03 -0700
Received: from oracle.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7)
id SAA24186; Mon, 19 Jun 1995 18:54:02 -0700
Received: from borogove.us.oracle.com by oracle.us.oracle.com with SMTP (8.6.9/37.7)
id SAA24364; Mon, 19 Jun 1995 18:53:58 -0700
Received: by borogove.us.oracle.com (5.0/SMI-SVR4)
id AA12459; Mon, 19 Jun 1995 18:53:53 -0700
Date: Mon, 19 Jun 1995 18:53:53 -0700
From: jhanley@us.oracle.com (John Hanley)
Message-Id: <9506200153.AA12459@borogove.us.oracle.com>
To: bind-workers@vix.com
Phone: +1 415 506 2360
Subject: BIND on ptx V4.0.2 (svr4)
Content-Length: 3248
This is not so much a cry for help as a comment on what I've seen, in case
it is useful to anyone. Otherwise, just ignore it, as Sequent will eventually
support 4.9.3 so the libraries will agree on the the size of _res. I only
have ptx 2.x primary nameservers putting protocol violations out on the wire,
and ptx 4.x hasn't become widely enough deployed to be a support issue for me.
The length mismatch caused by adding new fields to _res produces the
following on ptx 4.x:
ld: libinet.so: fatal error: attempt to override defined size of symbol `_res`
from file ../res/libresolv.a(res_init.o) with size of tentative definition
To get around this, make sure that the shared library reference, "-linet",
precedes the resolver library. For example, compile a vanilla 4.9.3b17
with "-DSVR4" and use a link command like:
cc -g -o nslookup main.o getinfo.o debug.o send.o skip.o list.o subr.o commands.o -linet ../../res/libresolv.a ../../compat/lib/lib44bsd.a -ll -lsocket -lnsl -lseq
This links cleanly against /usr/lib/libinet.so and friends.
Unfortunately, we easily core dump:
% debug ./nslookup
New program nslookup (process p1) created
debug> run
Default Server: dcsun2.us.oracle.com
Address: 139.185.20.52
> dcsun1.us.oracle.com.
Server: dcsun2.us.oracle.com
Address: 139.185.20.52
Name: dcsun1.us.oracle.com
Address: 139.185.20.51
> dcsun1.us.oracle.com
Server: dcsun2.us.oracle.com
Address: 139.185.20.52
SIGNALED 11 (segv) in p1 [_doprnt()]
0xbffd6a78 (_doprnt+13368:) movb (%ecx),%al
debug>
debug> stack
Stack Trace for p1, Program nslookup
[8] _doprnt(0x8055b65,0x80469cc,0x8046994) [0xbffd6a78]
[7] sprintf(0x80469d2,0x8055b5c,0x100,0x8047460,0x100,0x61726f2e) [0xbffe7510]
[6] GetHostDomain(nsAddrPtr=0x805c54c,queryClass=1,queryType=1,name="dcsun1.us.oracle.com",domain=Read at address 0x61726f2e failed
,hostPtr=0x805b4f8,isServer=0) [getinfo.c@676]
[5] GetHostInfoByName(nsAddrPtr=0x805c54c,queryClass=1,queryType=1,name="dcsun1.us.oracle.com",hostPtr=0x805b4f8,isServer=0) [getinfo.c@610]
[4] DoLookup(host="dcsun1.us.oracle.com",servPtr=0x805c48c,serverName="dcsun2.us.oracle.com") [main.c@594]
[3] LookupHost(string="dcsun1.us.oracle.com",putToFile=0) [main.c@688]
[2] yylex() [commands.c@0x8050d7f]
[1] main(argc=0,argv=0x80475c0,0x80475c4) [main.c@349]
[0] _start() [0x8049315]
debug>
The problem, as has been noted on this list before, is that dnsrch[]
and defdname[] were inadvertently swapped. This is Bad Karma for
shared libs. Applying the following yields a robust ``nslookup''.
--- include/resolv.h~ Wed Dec 14 22:24:07 1994
+++ include/resolv.h Mon Jun 19 18:38:52 1995
@@ -111,8 +111,8 @@
nsaddr_list[MAXNS]; /* address of name server */
#define nsaddr nsaddr_list[0] /* for backward compatibility */
u_short id; /* current packet id */
- char *dnsrch[MAXDNSRCH+1]; /* components of domain to search */
char defdname[MAXDNAME]; /* default domain */
+ char *dnsrch[MAXDNSRCH+1]; /* components of domain to search */
u_long pfcode; /* RES_PRF_ flags - see below. */
unsigned ndots:4; /* threshold for initial abs. query */
unsigned nsort:4; /* number of elements in sort_list[] */
Cheers,
JH

289
usr.sbin/named/doc/info/sequent-too Normal file
View File

@ -0,0 +1,289 @@
Delivery-Date: Mon, 19 Jun 1995 18:24:21 -0700
Return-Path: bind-workers-request@vix.com
Received: by gw.home.vix.com id AA19673; Mon, 19 Jun 95 18:19:54 -0700
Received: by gw.home.vix.com id AA19669; Mon, 19 Jun 95 18:19:53 -0700
Received: from oracle.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7)
id SAA23597; Mon, 19 Jun 1995 18:19:53 -0700
Received: from borogove.us.oracle.com by oracle.us.oracle.com with SMTP (8.6.9/37.7)
id SAA23784; Mon, 19 Jun 1995 18:19:50 -0700
Received: by borogove.us.oracle.com (5.0/SMI-SVR4)
id AA12444; Mon, 19 Jun 1995 18:19:40 -0700
Date: Mon, 19 Jun 1995 18:19:40 -0700
From: jhanley@us.oracle.com (John Hanley)
Message-Id: <9506200119.AA12444@borogove.us.oracle.com>
To: bind-workers@vix.com
Phone: +1 415 506 2360
In-Reply-To: <9506180802.AA23945@gw.home.vix.com> (message from Paul A Vixie on Sun, 18 Jun 1995 01:02:27 -0700)
Subject: BIND vs. ptx
Content-Length: 8817
I'm going to risk dredging up SYSV debates.
Here are some patches that I have found useful.
Recently I had the <ahem> pleasure of porting beta17 to Dynix/ptx, in order
to cope with the unresolved Sequent mailbug 209395. Most SVR3 compilations
choke until you notice the following things:
(1) a new header file, "conf/u_types.h" should typedef u_int, since
no system headers define it, other than <rpc/types.h>
(2) <netinet/in_systm.h> should typedef u_{char,short,long}, since no other
system headers define them
(3) <sys/types.h> MUST precede <sys/uio.h> (for caddr_t)
(4) <sys/types.h> MUST precede <netinet/in.h> (for ulong)
I didn't want to use <rpc/types.h>. Perhaps it would be simpler to use it,
as it defines all four, u_{int,char,short,long}, but I feared conflicts with
the sytem headers that _do_ define some of those. In an initial attempt I
tried typedef'ing u_int in "portability.h", but found that a seperate header
file was necessary to accommodate multiple inclusion from various callers. Any
random pathname would work well, in case "conf" was a poor directory choice.
Note that under recent ptx revs, such as version V4.0.2 (SysV release 4.0),
the command
% egrep 'u_(char|short|int|long)' /usr/include/sys/types.h
returns 4 lines, while under older revs, such as version V2.1.5
(SysV release 3.2.0), the same ``egrep'' command returns nothing.
SVR4 hosts definitely should not define NEED_SVR3_U_TYPES.
This patch has no effect on the
ld: libinet.so: fatal error: attempt to override defined size of symbol `_res`
from file ../res/libresolv.a(res_init.o) with size of tentative definition
error that beta17 + ptx SVR4 runs into. Same diagnostic patched and unpatched.
I'll send a few details on that in a separate note.
Strictly speaking, /*comments*/ don't belong on #include lines.
Feel free to strip them out, and to move command line defines (``cc -D'')
into a header file. I didn't touch the unusual /usr/local destinations
in the Makefile.
So, the first six chunks of the patch relate to typedef'ing unsigned
quantities in an environment that arguably has a <sys/types.h> header
that is (permanently) broken. I believe the implementation is fairly
clean. If this addition falls victim to the old SYSV portability
controversy and is relegated to SVR3-specific instructions with a
patch file under "contrib", so be it. This first half of the patch
is fully conditionalized on NEED_SVR3_U_TYPES, so it has no effect
until you explicitly ask for it.
The remaining chunks, from "herror.c" through "skip.c", simply add a
call to <sys/types.h>, and I request that these #include's become part of the
BIND distribution. My plea is based on the belief that the <sys/types.h>
call is a significant porting aid in some environments, and that no
environment should be missing <sys/types.h> or be caused grief by its
inclusion. Certainly, Solaris {1,2}.x experiences no difference. The
second half of the patch is not conditionally included, but it should be safe.
If it proves to be unsafe, it could obviously be conditionalized.
For what it's worth, on a ptx host where ``uname -rv'' returns "3.2.0 V2.1.5",
the build script below will compile the tree cleanly.
Cheers,
JH
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
rm -rf 4.9.3
mkdir 4.9.3
cd 4.9.3
gunzip < ../bind-4.9.3-BETA17.tar.gz | tar xf -
patch -p < ../bind-patches
# Strip leading comment character ('#') from relevant Sequent defines
(echo '/Sequent/+2,/Sequent/+11 s/^.//'; echo 'x') | ex Makefile
make > make.out
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
--- conf/u_types.h Tue May 16 00:00:00 1995
+++ conf/u_types.h Tue May 16 18:38:06 1995
@@ -0,0 +1,14 @@
+/* Various unsigned types that SVR3 does not supply.
+ * (You might be able to find them in <rpc/types.h>, but with opportunity
+ * for conflicts.)
+ */
+
+#ifndef _CONF_U_TYPES_H
+#define _CONF_U_TYPES_H
+
+/* pull in SVR3 typedefs for u_{char,short,long} */
+#include <netinet/in_systm.h>
+
+typedef unsigned long u_int;
+
+#endif
--- Makefile~ Thu Jan 12 21:54:04 1995
+++ Makefile Tue May 16 18:28:11 1995
@@ -359,8 +359,9 @@
#PS = ps -p
#(Sequent Dynix/PTX)
+# tested with SysV release "3.2.0", version "V2.1.5"
#CC = cc $(CPPFLAGS) -Wc,-pw
-#CPPFLAGS = -Du_int="unsigned int" -DSYSV
+#CPPFLAGS = -DSYSV -DNEED_SVR3_U_TYPES
#RANLIB = :
#LIBS = -ll -lsocket -linet -lnsl -lseq
#PIDDIR = /etc
--- include/resolv.h~ Thu Dec 15 06:24:07 1994
+++ include/resolv.h Tue May 16 18:42:13 1995
@@ -69,6 +69,9 @@
#endif
#include <sys/cdefs.h>
#include <stdio.h>
+#ifdef NEED_SVR3_U_TYPES
+#include "../conf/u_types.h" /* pull in the typedef for u_int */
+#endif
/*
* revision information. this is the release date in YYYYMMDD format.
--- conf/portability.h~ Thu Jan 12 21:44:30 1995
+++ conf/portability.h Tue May 16 18:20:51 1995
@@ -63,6 +63,9 @@
#include <string.h>
#include <sys/types.h>
+#ifdef NEED_SVR3_U_TYPES
+#include "../conf/u_types.h" /* pull in SVR3 typedefs for u_{char,short,long} */
+#endif
#include <sys/param.h>
#ifndef TIME_H_INCLUDED
# include <sys/time.h>
--- include/arpa/inet.h Wed Dec 14 22:24:08 1994
+++ include/arpa/inet.h Mon Jun 19 12:18:17 1995
@@ -70,6 +70,9 @@
# include <sys/types.h>
#endif
#include <sys/cdefs.h>
+#ifdef NEED_SVR3_U_TYPES
+#include "../../conf/u_types.h" /* pull in SVR3 typedefs for u_{char,short,long} */
+#endif
__BEGIN_DECLS
unsigned long inet_addr __P((const char *));
--- include/arpa/nameser.h~ Thu Dec 15 06:24:09 1994
+++ include/arpa/nameser.h Tue May 16 19:02:39 1995
@@ -68,6 +68,9 @@
# include <sys/types.h>
#endif
#include <sys/cdefs.h>
+#ifdef NEED_SVR3_U_TYPES
+#include "../../conf/u_types.h" /* pull in SVR3 typedefs for u_{char,short,long} */
+#endif
#ifdef _AUX_SOURCE
#include <sys/types.h> /* ech for A/UX */
--- res/herror.c~ Thu Dec 15 06:24:24 1994
+++ res/herror.c Tue May 16 16:37:13 1995
@@ -59,6 +59,7 @@
#endif /* LIBC_SCCS and not lint */
#include <sys/param.h>
+#include <sys/types.h>
#include <sys/uio.h>
#include <netdb.h>
#if defined(BSD) && (BSD >= 199103)
--- res/res_comp.c~ Thu Dec 15 06:24:24 1994
+++ res/res_comp.c Tue May 16 17:28:59 1995
@@ -59,6 +59,7 @@
#endif /* LIBC_SCCS and not lint */
#include <sys/param.h>
+#include <sys/types.h>
#include <netinet/in.h>
#include <arpa/nameser.h>
--- res/res_debug.c~ Mon Dec 19 08:35:11 1994
+++ res/res_debug.c Tue May 16 16:59:54 1995
@@ -59,6 +59,7 @@
#endif /* LIBC_SCCS and not lint */
#include <sys/param.h>
+#include <sys/types.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <arpa/nameser.h>
--- res/res_mkquery.c~ Thu Dec 15 06:24:25 1994
+++ res/res_mkquery.c Tue May 16 18:46:59 1995
@@ -59,6 +59,7 @@
#endif /* LIBC_SCCS and not lint */
#include <sys/param.h>
+#include <sys/types.h>
#include <netinet/in.h>
#include <arpa/nameser.h>
--- res/res_query.c~ Wed Jan 11 08:58:07 1995
+++ res/res_query.c Tue May 16 17:54:10 1995
@@ -59,6 +59,7 @@
#endif /* LIBC_SCCS and not lint */
#include <sys/param.h>
+#include <sys/types.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <arpa/nameser.h>
--- res/sethostent.c~ Thu Dec 15 06:24:26 1994
+++ res/sethostent.c Tue May 16 17:55:34 1995
@@ -37,6 +37,7 @@
#endif /* LIBC_SCCS and not lint */
#include <sys/param.h>
+#include <sys/types.h>
#include <netinet/in.h>
#include <arpa/nameser.h>
#include <netdb.h>
--- compat/lib/inet_addr.c~ Thu Dec 15 06:23:51 1994
+++ compat/lib/inet_addr.c Tue May 16 18:30:54 1995
@@ -59,6 +59,7 @@
#endif /* LIBC_SCCS and not lint */
#include <sys/param.h>
+#include <sys/types.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <ctype.h>
--- named/ns_req.c~ Tue Dec 20 02:16:25 1994
+++ named/ns_req.c Tue May 16 18:24:04 1995
@@ -59,6 +59,7 @@
*/
#include <sys/param.h>
+#include <sys/types.h>
#include <sys/uio.h>
#include <sys/file.h>
#include <sys/socket.h>
--- named/ns_stats.c~ Wed Jan 11 08:58:05 1995
+++ named/ns_stats.c Tue May 16 18:25:58 1995
@@ -64,6 +64,7 @@
/**************************************************************************/
#include <sys/param.h>
+#include <sys/types.h>
#include <netinet/in.h>
#include <arpa/nameser.h>
#include <stdio.h>
--- tools/nslookup/debug.c~ Thu Dec 15 07:24:31 1994
+++ tools/nslookup/debug.c Tue May 16 18:27:12 1995
@@ -71,6 +71,7 @@
*/
#include <sys/param.h>
+#include <sys/types.h>
#include <netinet/in.h>
#include <arpa/nameser.h>
#include <arpa/inet.h>
--- tools/nslookup/skip.c~ Thu Dec 15 07:24:33 1994
+++ tools/nslookup/skip.c Tue May 16 18:28:47 1995
@@ -76,6 +76,7 @@
*/
#include <sys/param.h>
+#include <sys/types.h>
#include <netinet/in.h>
#include <arpa/nameser.h>
#include <resolv.h>

39
usr.sbin/named/doc/info/soa-trouble Normal file
View File

@ -0,0 +1,39 @@
Return-Path: bind-workers-request
Received: by gw.home.vix.com id AA13481; Tue, 15 Feb 94 14:40:33 -0800
Received: by gw.home.vix.com id AA13469; Tue, 15 Feb 94 14:40:25 -0800
Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50)
id AA21318; Wed, 16 Feb 1994 06:54:09 +1100 (from kre@munnari.OZ.AU)
To: Piete Brooks <Piete.Brooks@cl.cam.ac.uk>
Cc: bind-workers@vix.com, M Graham Dineley <mgd@kaa.ee.umist.ac.uk>
Subject: Re: Suggested HACK to allow recovery after SOA typo ...
In-Reply-To: Your message of "Tue, 15 Feb 1994 18:57:53 -0000."
<"swan.cl.cam.:051210:940215185815"@cl.cam.ac.uk>
Date: Wed, 16 Feb 1994 06:54:09 +1100
Message-Id: <5765.761342049@munnari.OZ.AU>
From: Robert Elz <kre@munnari.OZ.AU>
This is unnecessary with 4.9.2 (and beyond). It would take
two steps to do - one to set the serial number to 0, then
another to set the serial number back to its proper value.
In two steps its always possible to reset the serial number
to a sane value with 4.9.2, and if you really messed it up
it may be possible to do it in one. This uses the (finally RFC
compliant) wrapping serial numbers, you simply increment the
bad serial number by the lesser of 2^31 - 1 and the difference
between what you want it to be and the current value.
If that didn't give you the value you want, you increment one
more time by the difference between what you want it to be and
what it then is (which will be less than 2^31 - 1 except in the
one pathological case where the "fix" you wanted was to
decrement the serial number by one - which isn't worth doing,
but could be done in one extra step).
Of course this only works where yyour secondaries are running
4.9.2, but so would any other hack scheme invented.
It is true that this involves some mod 2^32 arithmetic, but
its not that difficult.
kre

60
usr.sbin/named/doc/info/solaris Normal file
View File

@ -0,0 +1,60 @@
Path: vixie!pa.dec.com!bind-redist-request
From: pauls@locust.cic.net (Paul Southworth)
Newsgroups: local.mail.dns.bind
Subject: Re: resolv.conf on Solaris 2.3
Date: 4 Oct 1994 08:45:51 -0700
Organization: CICNet, Inc.
Lines: 25
Sender: daemon@vix.com
Distribution: local
Message-ID: <36rq3h$58b@spruce.cic.net>
NNTP-Posting-Host: gw.home.vix.com
X-Received: by gw.home.vix.com id AA06704; Tue, 4 Oct 94 08:45:42 -0700
X-Received: from pobox1.pa.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94)
id AA12132; Tue, 4 Oct 94 08:22:30 -0700
X-Received: by pobox1.pa.dec.com; id AA08901; Tue, 4 Oct 94 08:22:02 -0700
X-Received: by pobox1.pa.dec.com; id AA08897; Tue, 4 Oct 94 08:22:01 -0700
X-Received: from relay1.UU.NET by inet-gw-2.pa.dec.com (5.65/10Aug94)
id AA23996; Tue, 4 Oct 94 08:14:35 -0700
X-Received: by relay1.UU.NET
id QQxked01471; Tue, 4 Oct 1994 10:51:01 -0400
X-Received: from hofmann.CS.Berkeley.EDU by relay1.UU.NET with SMTP
id QQxked01432; Tue, 4 Oct 1994 10:50:55 -0400
X-Received: from rodan.UU.NET (rodan.UU.NET [153.39.128.10]) by hofmann.CS.Berkeley.EDU (8.6.9/8.6.6.Beta11) with ESMTP id HAA27381 for <bind@arpa.berkeley.edu>; Tue, 4 Oct 1994 07:50:42 -0700
X-Received: from relay1.UU.NET by rodan.UU.NET with SMTP
id QQxked23527; Tue, 4 Oct 1994 10:50:31 -0400
X-Received: from spruce.cic.net by relay1.UU.NET with SMTP
id QQxked01268; Tue, 4 Oct 1994 10:50:28 -0400
X-Received: (from news@localhost) by spruce.cic.net (8.6.7/8.6.6) id KAA05389; Tue, 4 Oct 1994 10:50:27 -0400
X-To: info-bind@uunet.uu.net
X-Path: locust.cic.net!pauls
X-Newsgroups: info.bind
X-Lines: 25
X-References: <Cx5722.5yG@Belgium.EU.net>
X-Nntp-Posting-Host: locust.cic.net
In article <Cx5722.5yG@Belgium.EU.net>,
Simon Townsend <u99288@s854803.kb.be> wrote:
>*All* I want to do is set up resolv.conf on a Sun SparcStation LX to use our
>network DNS server.
>
>The Sun configuration seems to require me to set a flag in the NIS master to
>indicate that DNS should be used. We do not use NIS. I can not find any
>information on how I should set it up to work otherwise.
Your maxim for the day is:
"The virtue of an NIS implementation is a function of how easily you can
turn it off"
In the case of Solaris 2.x, I must say the NIS implementation is outstanding.
1. Edit /etc/nsswitch.conf. Make the "hosts:" line read "hosts: dns".
2. Create /etc/resolv.conf
You're done!
--
Paul Southworth
CICNet, Inc.
pauls@cic.net

50
usr.sbin/named/doc/info/solaris.too Normal file
View File

@ -0,0 +1,50 @@
Delivery-Date: Fri, 24 Feb 1995 09:15:19 -0800
Received: by gw.home.vix.com id AA05776; Fri, 24 Feb 95 09:15:11 -0800
Received: (from auclair@localhost) by jade.jouy.inra.fr (8.6.9/8.6.9) id RAA13441; Fri, 24 Feb 1995 17:45:43 +0100
Date: Fri, 24 Feb 1995 17:45:43 +0100
From: Philippe Auclair <auclair@jade.jouy.inra.fr>
Message-Id: <199502241645.RAA13441@jade.jouy.inra.fr>
To: Paul A Vixie <paul@vix.com>
Subject: Remarks on bind-4.9.3-BETA17 on Solaris 2.4
Hi,
Just a few remarks on some slght difficulties I have had with Solaris 2.4.
BIND-4.9.3 on Solaris 2.4
mkdep :
set PATH to use the right compiler
/opt/SUNWspro/bin/cc requires -xM argument, not -M
I would recommend :
PIDDIR = /etc as for SunOS instead of /var/run
DESTHELP = /usr/lib as for SunOS instead of /usr/share/misc
Sun's nslookup is in /usr/sbin, not /usr/bin.
The Makefile says : "under solaris2.x, use 'make install' at your own risk."
I would say : "under solaris2.x, DON'T use 'make install'."
Syntax of command "install" :
-c dir destination dir
-u user not -o user
You can't rename the file.
-> needs a specific install procedure.
Otherwise, it seems fine...
Yours,
Philippe Auclair
**************************************************************
* Institut National de la Recherche Agronomique *
* *
* Philippe Auclair Philippe.Auclair@jouy.inra.fr *
* Unite Informatique de Jouy tel +33 1-34-65-26-95 *
* Domaine de Vilvert fax +33 1-39-56-49-67 *
* 78352 Jouy-en-Josas Cedex *
**************************************************************

56
usr.sbin/named/doc/info/upgrade Normal file
View File

@ -0,0 +1,56 @@
Return-Path: bind-workers-request
Received: by gw.home.vix.com id AA12038; Tue, 11 Jan 94 14:51:12 -0800
Received: by gw.home.vix.com id AA12026; Tue, 11 Jan 94 14:50:57 -0800
Received: from drugs.syd.dms.CSIRO.AU
by dmssyd.syd.dms.CSIRO.AU (4.1/5.17)
id AA27838; Wed, 12 Jan 94 09:48:50 EST
(from marka@syd.dms.csiro.au (Mark Andrews))
Message-Id: <9401112248.AA27838@dmssyd.syd.dms.CSIRO.AU>
To: clauberg@rrz.uni-koeln.de (Axel Clauberg)
Cc: bind-workers@vix.com
Subject: Re: 4.9.2-931205 primary NS on HP-UX 9.01 loosing own A records
In-Reply-To: Your message of "Tue, 11 Jan 1994 09:04:19 BST."
<199401110804.AA10185@noc.rrz.Uni-Koeln.DE>
Date: Wed, 12 Jan 1994 09:48:38 +1100
From: Mark Andrews <marka@syd.dms.csiro.au>
> Hi all,
> I seem to have a strange problem with 4.9.2-931205+patch01 running on our
> primary nameserver. This is an HP 9000/720 under HP-UX 9.01.
> This machine is running primary for our 4 zones, secondary for around
> 170 other german zones.
> After running properly for around two days, named suddenly lost the two addre
> ss
> records for its own machine. The HINFO was still present. This happened
> for the second time within a week now.
>
> Before I start a long debugging named session: did anyone else running
> it on HP machines see this problem ? We've been running it for about a
> month on all our secondaries (AIX 3.2.5, SunOS 4.1.3, Solaris 2.3) without
> this strangeness.
>
> Best regards, Axel
>
>
From this message I would assume that the following events
occured.
This is the first installation of 4.9{.X} on this machine.
The old cache files were NOT removed prior to starting the new
nameserver.
What has happened here in the glue A records in the old cache
files were read into the internal cache with a higher clev than
the real A records. A zone transfer then occured for the zone
from which they were loaded and the A records were `lost'.
4.9.2 depends on the cache files having been made with a 4.9.2
named-xfer.
Mark.
--
Mark Andrews, CSIRO Div Maths & Stats
Locked Bag 17, North Ryde, NSW 2113, Australia.
PHONE: +61 2 325 3148 INTERNET: marka@syd.dms.csiro.au
UUCP: ....!uunet!syd.dms.csiro.au!marka

286
usr.sbin/named/doc/misc/DynamicUpdate Normal file
View File

@ -0,0 +1,286 @@
[ Deprecated, unsupported, nonfunctional, but not yet completely excised. ]
Description of Dynamic Update and T_UNSPEC Code
Added by Mike Schwartz
University of Washington Computer Science Department
11/86
schwartz@cs.washington.edu
I have incorporated 2 new features into BIND:
1. Code to allow (unauthenticated) dynamic updates: surrounded by
#ifdef ALLOW_UPDATES
2. Code to allow data of unspecified type: surrounded by
#ifdef ALLOW_T_UNSPEC
Note that you can have one or the other or both (or neither) of these
modifications running, by appropriately modifying the makefiles. Also,
the external interface isn't changed (other than being extended), i.e.,
a BIND server that allows dynamic updates and/or T_UNSPEC data can
still talk to a 'vanilla' server using the 'vanilla' operations.
The description that follows is broken into 3 parts: a functional
description of the dynamic update facility, a functional description of
the T_UNSPEC facility, and a discussion of the implementation of
dynamic updates. The implementation description is mostly intended for
those who want to make future enhancements (especially the addition of
a good authentication mechanism). If you make enhancements, I would be
interested in hearing about them.
1. Dynamic Update Facility
I added this code in conjunction with my research into naming in large
heterogeneous systems. For the purposes of this research, I ignored
security issues. In other words, no authentication/authorization
mechanism exists to control updates. Authentication will hopefully be
addressed at some future point (although probably not by me). In the
mean time, BIND Internet name servers (as opposed to "private" name
server networks operating with their own port numbers, as I use in my
research) should be compiled *without* -DALLOW_UPDATES, so that the
integrity of the Internet name database won't be compromised by this
code.
There are 5 different dynamic update interfaces:
UPDATEA - add a resource record
UPDATED - delete a specific resource record
UPDATEDA - delete all named resource records
UPDATEM - modify a specific resource record
UPDATEMA - modify all named resource records
These all work through the normal resolver interface, i.e., these
interfaces are opcodes, and the data in the buffers passed to
res_mkquery must conform to what is expected for the particular
operation (see the #ifdef ALLOW_UPDATES extensions to nstest.c for
example usage).
UPDATEM is logically equivalent to an UPDATED followed by an UPDATEA,
except that the updates occur atomically at the primary server (as
usual with Domain servers, secondaries may become temporarily
inconsistent). The difference between UPDATED and UPDATEDA is that the
latter allows you to delete all RRs associated with a name; similarly
for UPDATEM and UPDATEMA. The reason for the UPDATE{D,M}A interfaces
is two-fold:
1. Sometimes you want to delete/modify some data, but you know you'll
only have a single RR for that data; in such a case, it's more
convenient to delete/modify the RR by just giving the name;
otherwise, you would have to first look it up, and then
delete/modify it.
2. It is sometimes useful to be able to delete/modify multiple RRs
this way, since one can then perform the operation atomically.
Otherwise, one would have to delete/modify the RRs one-by-one.
One additional point to note about UPDATEMA is that it will return a
success status if there were *zero* or more RRs associated with the given
name (and the RR add succeeds), whereas UPDATEM, UPDATED, and UPDATEDA
will return a success status if there were *one* or more RRs associated
with the given name. The reason for the difference is to handle the
(probably common) case where what you want to do is set a particular
name to contain a single RR, irrespective of whether or not it was
already set.
2. T_UNSPEC Facility
Type T_UNSPEC allows you to store data whose layout BIND doesn't
understand. Data of this type is not marshalled (i.e., converted
between host and network representation, as is done, for example, with
Internet addresses) by BIND, so it is up to the client to make sure
things work out ok w.r.t. heterogeneous data representations. The way
I use this type is to have the client marshal data, store it, retrieve
it, and demarshal it. This way I can store arbitrary data in BIND
without having to add new code for each specific type.
T_UNSPEC data is dumped in an ASCII-encoded, checksummed format so
that, although it's not human-readable, it at least doesn't fill the
dump file with unprintable characters.
Type T_UNSPEC is important for my research environment, where
potentially lots of people want to store data in the name service, and
each person's data looks different. Instead of having BIND understand
the format of each of their data types, the clients define marshaling
routines and pass buffers of marshalled data to BIND; BIND never tries
to demarshal the data...it just holds on to it, and gives it back to
the client when the client requests it, and the client must then
demarshal it.
The Xerox Network System's name service (the Clearinghouse) works this
way. The reason 'vanilla' BIND understands the format of all the data
it holds is probably that BIND is tailored for a very specific
application, and wants to make sure the data it holds makes sense (and,
for some types, BIND needs to take additional action depending on the
data's semantics). For more general purpose name services (like the
Clearinghouse and my usage of BIND), this approach is less tractable.
See the #ifdef ALLOW_T_UNSPEC extensions to nstest.c for example usage of
this type.
3. Dynamic Update Implementation Description
This section is divided into 3 subsections: General Discussion,
Miscellaneous Points, and Known Defects.
3.1 General Discussion
The basic scheme is this: When an update message arrives, a call is
made to InitDynUpdate, which first looks up the SOA record for the zone
the update affects. If this is the primary server for that zone, we do
the update and then update the zone serial number (so that secondaries
will refresh later). If this is a secondary server, we forward the
update to the primary, and if that's successful, we update our copy
afterwards. If it's neither, we refuse the update. (One might think
to try to propagate the update to an authoritative server; I figured
that updates will probably be most likely within an administrative
domain anyway; this could be changed if someone has strong feelings
about it).
Note that this mechanism disallows updates when the primary is
down, preserving the Domain scheme's consistency requirements,
but making the primary a critical point for updates. This seemed
reasonable to me because
1. Alternative schemes must deal with potentially complex
situations involving merging of inconsistent secondary
updates
2. Updates are presumed to be rare relative to read accesses,
so this increased restrictiveness for updates over reads is
probably not critical
I have placed comments through out the code, so it shouldn't be
too hard to see what I did. The majority of the processing is in
doupdate() and InitDynUpdate(). Also, I added a field to the zone
struct, to keep track of when zones get updated, so that only changed
zones get checkpointed.
3.2 Miscellaneous Points
I use ns_maint to call zonedump() if the database changes, to
provide a checkpointing mechanism. I use the zone refresh times to
set up ns_maint interrupts if there are either secondaries or
primaries. Hence, if there is a secondary, this interrupt can cause
zoneref (as before), and if there is a primary, this interrupt can
cause doadump. I also checkpoint if needed before shutting down.
You can force a server to checkpoint any changed zones by sending the
maint signal (SIGALRM) to the process. Otherwise it just checkpoints
during maint. interrupts, or when being shutdown (with SIGTERM).
Sending it the dump signal causes the database to be dumped into the
(single) dump file, but doesn't checkpoint (i.e., update the boot
files). Note that the boot files will be overwritten with checkpoint
files, so if you want to preserve the comments, you should keep copies
of the original boot files separate from the versions that are actually
used.
I disallow T_SOA updates, for several reasons:
- T_SOA deletes at the primary wont be discovered by the secondaries
until they try to request them at maint time, which will cause
a failure
- the corresponding NS record would have to be deleted at the same
time (atomically) to avoid various problems
- T_SOA updates would have to be done in the right order, or else
the primary and secondaries will be out-of-sync for that zone.
My feeling is that changing the zone topology is a weighty enough thing
to do that it should involve changing the load file and reloading all
affected servers.
There are alot of places where bind exits due to catastrophic failures
(mainly malloc failures). I don't try to dump the database in these
places because it's probably inconsistent anyway. It's probably better
to depend on the most recent dump.
3.2 Known Defects
1. I put the following comment in nlookup (db_lookup.c):
Note: at this point, if np->n_data is NULL, we could be in one
of two situations: Either we have come across a name for which
all the RRs have been (dynamically) deleted, or else we have
come across a name which has no RRs associated with it because
it is just a place holder (e.g., EDU). In the former case, we
would like to delete the namebuf, since it is no longer of use,
but in the latter case we need to hold on to it, so future
lookups that depend on it don't fail. The only way I can see
of doing this is to always leave the namebufs around (although
then the memory usage continues to grow whenever names are
added, and can never shrink back down completely when all their
associated RRs are deleted).
Thus, there is a problem that the memory usage will keep growing for
the situation described. You might just choose to ignore this
problem (since I don't see any good way out), since things probably
wont grow fast anyway (how many names are created and then deleted
during a single server incarnation, after all?)
The problem is that one can't delete old namebufs because one would
want to do it from db_update, but db_update calls nlookup to do the
actual work, and can't do it there, since we need to maintain place
holders. One could make db_update not call nlookup, so we know it's
ok to delete the namebuf (since we know the call is part of a delete
call); but then there is code with alot of overlapping functionality
in the 2 routines.
This also causes another problem: If you create a name and then do
UPDATEDA, all it's RRs get deleted, but the name remains; then, if you
do a lookup on that name later, the name is found in the hash table,
but no RRs are found for it. It then forwards the query to itself (for
some reason), and then somehow decides there is no such domain, and then
returns (with the correct answer, but after going through extra work).
But the name remains, and each time it is looked up, we go through
these same steps. This should be fixed, but I don't have time right
now (and the right answer seems to come back anyway, so it's good
enough for now).
2. There are 2 problems that crop up when you store data (other than
T_SOA and T_NS records) in the root:
a. Can't get primary to doaxfr RRs other than SOA and NS to
secondary.
b. Upon checkpoint (zonedump), this data sometimes comes out after other
data in the root, so that (since the SOA and NS records have null
names), they will get interpreted as being records under the
other names upon the next boot up. For example, if you have a
T_A record called ABC, the checkpoint may look like:
$ORIGIN .
ABC IN A 128.95.1.3
99999999 IN NS UW-BORNEO.
IN SOA UW-BORNEO. SCHWARTZ.CS.WASHINGTON.EDU.
( 50 3600 300 3600000 3600 )
Then when booting up the next time, the SOA and NS records get
interpreted as being called "ABC" rather than the null root
name.
3. The secondary server caches the T_A RR for the primary, and hence when
it tries to ns_forw an update, it won't find the address of the primary
using nslookup unless that T_A RR is *also* stored in the main hashtable
(by putting it in a named.db file as well as the named.ca file).

1602
usr.sbin/named/doc/misc/FAQ.1of2 Normal file
View File

File diff suppressed because it is too large Load Diff

1298
usr.sbin/named/doc/misc/FAQ.2of2 Normal file
View File

File diff suppressed because it is too large Load Diff

72
usr.sbin/named/doc/misc/IPv6 Normal file
View File

@ -0,0 +1,72 @@
IPv6 notes for BIND 4.9.3 Patch 2 Candidate 5 (and later?)
Paul Vixie, May 20, 1996
doc/misc/IPv6
*** Introduction ***
The IPv6 support in this release is latent, in that its presence is not
documented. The support is not optional, since its presence ought not to
affect anyone who does not go looking for it. The support includes:
inet_ntop() new function.
inet_pton() new function.
RES_USE_INET6 causes gethostby*() to return either real IPv6
addresses (if available) or mapped (::FFFF:a.b.c.d)
addresses if only IPv4 address records are found.
gethostbyname() can search for T_AAAA in preference to T_A.
gethostbyaddr() can search in IP6.INT for PTR RR's.
named can load, transfer, cache, and dump T_AAAA RRs.
*** Some notes on the new functions ***
The inet_pton() and inet_ntop() functions differ from the current (as of
this writing) IPv6 BSD API draft. Discussions were held, primarily between
myself and Rich Stevens, on the ipng@sunroof.eng.sun.com mailing list, and
the BIND definitions of these functions are likely to go into the next draft.
(If not, and BIND has to change its definitions of these functions, then you
will know why I chose not to document them yet!)
These functions can return error values, and as such the process of porting
code that used inet_aton() to use inet_pton() is not just syntactic. Not all
nonzero values indicate success; consider "-1". Likewise, inet_ntoa() is not
just smaller than inet_ntop() -- it's a whole new approach. Inet_ntop() does
not return a static pointer, the caller has to supply a sized buffer. Also,
inet_ntop() can return NULL, so you should only printf() the result if you
have verified that your arguments will be seen as error free.
The inet_pton() function is much pickier about its input format than the old
inet_aton() function has been. You can't abbreviate 10.0.0.53 as 10.53 any
more. Hexadecimal isn't accepted. You have to supply four decimal numeric
strings, each of whose value is within the range from 0 to 255. No spaces
are allowed either before, after, or within an address. If you need the older
functionality with all the shortcuts and exceptions, continue using inet_aton()
for your IPv4 address parsing needs.
*** Some notes on RES_USE_INET6 ***
You can set this by modifying _res.options after calling res_init(), or you
can turn it on globally by setting "options inet6" in /etc/resolv.conf. This
latter option ought to be used carefully, since _all_ applications will then
receive IPv6 style h_addr_list's from their gethostby*() calls. Once you know
that every application on your system can cope with IPv6 addressing, it is safe
and reasonable to turn on the global option. Otherwise, don't do it.
*** Some notes on mapped IPv4 addresses ***
There are two IPv6 prefixes set aside for IPv4 address encapsulation. See
RFC 1884 for a detailed explaination. The ::a.b.c.d form is used for
tunnelling, which means wrapping an IPv4 header around IPv6 packets and using
the existing IPv4 routing infrastructure to reach what are actually IPv6
endpoints. The ::FFFF:a.b.c.d form can be used on dual-stack (IPv4 and IPv6)
hosts to signal a predominantly IPv6 stack that it should use ``native'' IPv4
to reach a given destination, even though the socket's address family is
AF_INET6.
BIND supports both of these address forms, to the extent that inet_pton() will
parse them, inet_ntop() will generate them, gethostby*() will map IPv4 into
IPv6 if the RES_USE_INET6 option is set, and gethostbyaddr() will search the
IN-ADDR.ARPA domain rather than the IP6.INT domain when it needs a PTR RR.
This last bit of behaviour is still under discussion and it's not clear that
tunnelled addresses should be mapped using IN-ADDR.ARPA. In other words, this
bit of behaviour may change in a subsequent BIND release. So now you know
another reason why none of this stuff is ``officially'' documented.

1081
usr.sbin/named/doc/misc/dns-setup Normal file
View File

File diff suppressed because it is too large Load Diff

701
usr.sbin/named/doc/misc/domain.ps Normal file
View File

@ -0,0 +1,701 @@
%!PS-Adobe-3.0
%%Creator: groff version 1.05
%%DocumentNeededResources: font Times-Bold
%%+ font Times-Italic
%%+ font Times-Roman
%%DocumentSuppliedResources: procset grops 1.05 0
%%Pages: 5
%%PageOrder: Ascend
%%Orientation: Portrait
%%EndComments
%%BeginProlog
%%BeginResource: procset grops 1.05 0
/setpacking where {
pop
currentpacking
true setpacking
} if
/grops 120 dict dup begin
% The ASCII code of the space character.
/SC 32 def
/A /show load def
/B { 0 SC 3 -1 roll widthshow } bind def
/C { 0 exch ashow } bind def
/D { 0 exch 0 SC 5 2 roll awidthshow } bind def
/E { 0 rmoveto show } bind def
/F { 0 rmoveto 0 SC 3 -1 roll widthshow } bind def
/G { 0 rmoveto 0 exch ashow } bind def
/H { 0 rmoveto 0 exch 0 SC 5 2 roll awidthshow } bind def
/I { 0 exch rmoveto show } bind def
/J { 0 exch rmoveto 0 SC 3 -1 roll widthshow } bind def
/K { 0 exch rmoveto 0 exch ashow } bind def
/L { 0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow } bind def
/M { rmoveto show } bind def
/N { rmoveto 0 SC 3 -1 roll widthshow } bind def
/O { rmoveto 0 exch ashow } bind def
/P { rmoveto 0 exch 0 SC 5 2 roll awidthshow } bind def
/Q { moveto show } bind def
/R { moveto 0 SC 3 -1 roll widthshow } bind def
/S { moveto 0 exch ashow } bind def
/T { moveto 0 exch 0 SC 5 2 roll awidthshow } bind def
% name size font SF -
/SF {
findfont exch
[ exch dup 0 exch 0 exch neg 0 0 ] makefont
dup setfont
[ exch /setfont cvx ] cvx bind def
} bind def
% name a c d font MF -
/MF {
findfont
[ 5 2 roll
0 3 1 roll % b
neg 0 0 ] makefont
dup setfont
[ exch /setfont cvx ] cvx bind def
} bind def
/level0 0 def
/RES 0 def
/PL 0 def
/LS 0 def
% BP -
/BP {
/level0 save def
1 setlinecap
1 setlinejoin
72 RES div dup scale
LS {
90 rotate
} {
0 PL translate
} ifelse
1 -1 scale
} bind def
/EP {
level0 restore
showpage
} bind def
% centerx centery radius startangle endangle DA -
/DA {
newpath arcn stroke
} bind def
% x y SN - x' y'
% round a position to nearest (pixel + (.25,.25))
/SN {
transform
.25 sub exch .25 sub exch
round .25 add exch round .25 add exch
itransform
} bind def
% endx endy startx starty DL -
% we round the endpoints of the line, so that parallel horizontal
% and vertical lines will appear even
/DL {
SN
moveto
SN
lineto stroke
} bind def
% centerx centery radius DC -
/DC {
newpath 0 360 arc closepath
} bind def
/TM matrix def
% width height centerx centery DE -
/DE {
TM currentmatrix pop
translate scale newpath 0 0 .5 0 360 arc closepath
TM setmatrix
} bind def
% these are for splines
/RC /rcurveto load def
/RL /rlineto load def
/ST /stroke load def
/MT /moveto load def
/CL /closepath load def
% fill the last path
% amount FL -
/FL {
currentgray exch setgray fill setgray
} bind def
% fill with the ``current color''
/BL /fill load def
/LW /setlinewidth load def
% new_font_name encoding_vector old_font_name RE -
/RE {
findfont
dup maxlength dict begin
{
1 index /FID ne { def } { pop pop } ifelse
} forall
/Encoding exch def
dup /FontName exch def
currentdict end definefont pop
} bind def
/DEFS 0 def
% hpos vpos EBEGIN -
/EBEGIN {
moveto
DEFS begin
} bind def
/EEND /end load def
/CNT 0 def
/level1 0 def
% llx lly newwid wid newht ht newllx newlly PBEGIN -
/PBEGIN {
/level1 save def
translate
div 3 1 roll div exch scale
neg exch neg exch translate
% set the graphics state to default values
0 setgray
0 setlinecap
1 setlinewidth
0 setlinejoin
10 setmiterlimit
[] 0 setdash
/setstrokeadjust where {
pop
false setstrokeadjust
} if
/setoverprint where {
pop
false setoverprint
} if
newpath
/CNT countdictstack def
userdict begin
/showpage {} def
} bind def
/PEND {
clear
countdictstack CNT sub { end } repeat
level1 restore
} bind def
end def
/setpacking where {
pop
setpacking
} if
%%EndResource
%%IncludeResource: font Times-Bold
%%IncludeResource: font Times-Italic
%%IncludeResource: font Times-Roman
grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72 def/PL
792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron/scaron/zcaron
/Ydieresis/trademark/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/space/exclam
/quotedbl/numbersign/dollar/percent/ampersand/quoteright/parenleft/parenright
/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven
/eight/nine/colon/semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J
/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex
/underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z
/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft
/guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl/endash
/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut/dotaccent/breve
/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash/quotedblbase/OE/Lslash
/.notdef/exclamdown/cent/sterling/currency/yen/brokenbar/section/dieresis
/copyright/ordfeminine/guilsinglleft/logicalnot/minus/registered/macron/degree
/plusminus/twosuperior/threesuperior/acute/mu/paragraph/periodcentered/cedilla
/onesuperior/ordmasculine/guilsinglright/onequarter/onehalf/threequarters
/questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE/Ccedilla
/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex/Idieresis/Eth
/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis/multiply/Oslash/Ugrave
/Uacute/Ucircumflex/Udieresis/Yacute/Thorn/germandbls/agrave/aacute/acircumflex
/atilde/adieresis/aring/ae/ccedilla/egrave/eacute/ecircumflex/edieresis/igrave
/iacute/icircumflex/idieresis/eth/ntilde/ograve/oacute/ocircumflex/otilde
/odieresis/divide/oslash/ugrave/uacute/ucircumflex/udieresis/yacute/thorn
/ydieresis]def/Times-Roman@0 ENC0/Times-Roman RE/Times-Italic@0 ENC0
/Times-Italic RE/Times-Bold@0 ENC0/Times-Bold RE
%%EndProlog
%%Page: 1 1
%%BeginPageSetup
BP
%%EndPageSetup
/F0 12/Times-Bold@0 SF -.5(What is a Domain?)239.58 82.031 R/F1 10
/Times-Italic@0 SF(Mark R. Horton)255.92 100.031 Q(ABSTRACT)264.385 154.031 Q
/F2 10/Times-Roman@0 SF 1.689(In the past, electronic mail has used many dif)
122 190.031 R 1.688(ferent kinds of syntax, naming a)-.18 F .036
(computer and a login name on that computer)122 202.031 R 5.036(.A)-.55 G .036
(new system, called `)318.134 202.031 R(`domains')-.74 E .037(', is)-.74 F
1.905(becoming widely used, based on a heirarchical naming scheme.)122 214.031
R 1.904(This paper is)6.904 F 1.256
(intended as a quick introduction to domains.)122 226.031 R 1.257
(For more details, you should read)6.257 F
(some of the documents referenced at the end.)122 238.031 Q F1 2.5(1. Intr)72
286.031 R(oduction)-.37 E F2 .139(What exactly are domains?)72 304.031 R
(Basically)5.139 E 2.639(,t)-.65 G .138
(hey are a way of looking at the world as a heirarchy \(tree structure\).)
230.625 304.031 R -1(Yo)72 316.031 S 1.079(u're already used to using two tree\
world models that work pretty well: the telephone system and the)1 F(post of)
72 328.031 Q 2.5(\214ce. Domains)-.18 F
(form a similar heirarchy for the electronic mail community)2.5 E(.)-.65 E .232
(The post of)72 346.031 R .232(\214ce divides the world up geographically)-.18
F 2.732<2c8c>-.65 G .232
(rst into countries, then each country divides itself up,)289.946 346.031 R
.598(those units subdivide, and so on.)72 358.031 R .598(One such country)5.598
F 3.098(,t)-.65 G .598(he USA, divides into states, which divide into coun-)
290.332 358.031 R .211(ties \(except for certain states, like Louisiana, which\
divide into things like parishes\), the counties subdivide)72 370.031 R 2.189
(into cities, towns, and townships, which typically divide into streets, the s\
treets divide into lots with)72 382.031 R .265(addresses, possibly containing \
room and apartment numbers, the then individual people at that address.)72
394.031 R(So)5.265 E(you have an address like)72 406.031 Q(Mark Horton)108
424.031 Q(Room 2C-249)108 436.031 Q(6200 E. Broad St.)108 448.031 Q
(Columbus, Ohio, USA)108 460.031 Q 1.167(\(I'm ignoring the name `)72 478.031 R
(`A)-.74 E 1.168(T&T Bell Laboratories')-1.11 F 3.668('a)-.74 G 1.168
(nd the zip code, which are redundant information.\))292.814 478.031 R
(Other countries may subdivide dif)72 490.031 Q(ferently)-.18 E 2.5(,f)-.65 G
(or example many small countries do not have states.)247.25 490.031 Q .554
(The telephone system is similar)72 508.031 R 5.554(.Y)-.55 G .553
(our full phone number might look like 1-614-860-1234 x234 This con-)214.6
508.031 R 1.24(tains, from left to right, your country code \(Surprise!)72
520.031 R 1.24(The USA has country code `)6.24 F(`1')-.74 E 1.24
('!\), area code 614)-.74 F 1.012
(\(Central Ohio\), 860 \(a pre\214x in the Reynoldsbur)72 532.031 R 3.512(gC)
-.18 G 1.012(.O.\), 1234 \(individual phone number\), and extension)287.398
532.031 R 2.69(234. Some)72 544.031 R .191(phone numbers do not have extension\
s, but the phone system in the USA has standardized on a)2.69 F 3.782(3d)72
556.031 S 1.281(igit area code, 3 digit pre\214x, and 4 digit phone number)
85.782 556.031 R 6.281(.O)-.55 G 1.281(ther countries don')332.354 556.031 R
3.781(tu)-.18 G 1.281(se this standard, for)421.837 556.031 R 1.424(example, i\
n the Netherlands a number might be +46 8 7821234 \(country code 46, city code\
8, number)72 568.031 R .294(7821234\), in Germany +49 231 7551234, in Sweden \
+31 80 551234, in Britain +44 227 61234 or +44 506)72 580.031 R(41)72 592.031 Q
3.237(1234. Note)-.37 F .737(that the country and city codes and telephone num\
bers are not all the same length, and the)3.237 F .812(punctuation is dif)72
604.031 R .812(ferent from our North American notation.)-.18 F -.4(Wi)5.812 G
.812(thin a country).4 F 3.312(,t)-.65 G .812(he length of the telephone)
396.882 604.031 R .25(number might depend on the city code.)72 616.031 R .251
(Even within the USA, the length of extensions is not standardized:)5.25 F .005
(some places use the last 4 digits of the telephone number for the extension, \
some use 2 or 3 or 4 digit exten-)72 628.031 R .649
(sions you must ask an operator for)72 640.031 R 5.649(.E)-.55 G .649
(ach country has established local conventions.)227.363 640.031 R .65
(But the numbers are)5.65 F .197(unambigous when dialed from left-to-right, so\
as long as there is a way to indicate when you are done dial-)72 652.031 R
(ing, there is no problem.)72 664.031 Q 3.092(Ak)72 682.031 S .592(ey dif)
87.312 682.031 R .593(ference in philosophy between the two systems is evident\
from the way addresses and telephone)-.18 F 1.497(numbers are written.)72
694.031 R -.4(Wi)6.497 G 1.497(th an address, the most speci\214c information \
comes \214rst, the least speci\214c last.).4 F .573(\(The `)72 706.031 R .573
(`root of the tree')-.74 F 3.073('i)-.74 G 3.073(sa)172.515 706.031 S 3.074(tt)
183.918 706.031 S .574(he right.\))192.552 706.031 R -.4(Wi)5.574 G .574
(th telephones, the least speci\214c information \(root\) is at the left.).4 F
.299(The telephone system was designed for machinery that looks at the \214rst\
few digits, does something with it,)72 718.031 R .773
(and passes the remainder through to the next level.)72 730.031 R .773
(Thus, in ef)5.773 F .774(fect, you are routing your call through the)-.18 F
.255(telephone network.)72 742.031 R .255(Of course, the exact sequence you di\
al depends on where you are dialing from - some-)5.255 F .259(times you must d\
ial 9 or 8 \214rst, to get an international dialtone you must dial 01)72
754.031 R .259(1, if you are calling locally)-.37 F EP
%%Page: 2 2
%%BeginPageSetup
BP
%%EndPageSetup
/F0 10/Times-Roman@0 SF .31(you can \(and sometimes must\) leave of)72 96 R
2.81(ft)-.18 G .31(he 1 and the area code.)239.24 96 R .31
(\(This makes life very interesting for peo-)5.31 F .463
(ple who must design a box to call their home of)72 108 R .463
(\214ce from any phone in the world.\))-.18 F .464(This type of address is)
5.464 F(called a `)72 120 Q(`relative address')-.74 E
(', since the actual address used depends on the location of the sender)-.74 E
(.)-.55 E .547(The postal system, on the other hand, allows you to write the s\
ame address no matter where the sender is.)72 138 R .851(The address above wil\
l get to me from anywhere in the world, even private company mail systems.)72
150 R -1(Ye)5.851 G(t,)1 E .195
(some optional abbreviations are possible - I can leave of)72 162 R 2.695(ft)
-.18 G .195(he USA if I'm mailing within the USA; if I'm in)307.61 162 R .552
(the same city as the address, I can usually just say `)72 174 R(`city')-.74 E
3.053('i)-.74 G 3.053(np)312.94 174 S .553(lace of the last line.)325.993 174 R
.553(This type of address is)5.553 F(called an `)72 186 Q(`absolute address')
-.74 E
(', since the unabbreviated form does not depend on the location of the sender)
-.74 E(.)-.55 E .674(The ARP)72 204 R .674
(ANET has evolved with a system of absolute addresses: `)-.92 F(`user@host')
-.74 E 3.173('w)-.74 G .673(orks from any machine.)407.001 204 R .269
(The UUCP network has evolved with a system of relative addresses: `)72 216 R
-2.13(`host!user ')-.74 F 2.769('w)-.74 G .269(orks from any machine)410.713
216 R .566(with a direct link to `)72 228 R(`host')-.74 E .565(', and you have\
to route your mail through the network to \214nd such a machine.)-.74 F .451
(In fact, the `)72 240 R(`user@host')-.74 E 2.951('s)-.74 G .452(yntax has bec\
ome so popular that many sites run mail software that accepts this)180.114 240
R .502(syntax, looks up `)72 252 R(`host')-.74 E 3.002('i)-.74 G 3.002(nat)
175.578 252 S .501(able, and sends it to the appropriate network for `)193.802
252 R(`host')-.74 E 3.001('. This)-.74 F .501(is a very nice)3.001 F .693
(user interface, but it only works well in a small network.)72 264 R .693
(Once the set of allowed hosts grows past about)5.693 F
(1000 hosts, you run into all sorts of administrative problems.)72 276 Q .357(\
One problem is that it becomes nearly impossible to keep a table of host names\
up to date.)72 294 R .356(New machines)5.356 F 1.123
(are being added somewhere in the world every day)72 306 R 3.623(,a)-.65 G
1.123(nd nobody tells you about them.)294.727 306 R 1.124(When you try to)6.124
F .951(send mail to a host that isn')72 318 R 3.451(ti)-.18 G 3.451(ny)196.537
318 S .951
(our table \(replying to mail you just got from a new host\), your mailing)
209.988 318 R 1.057(software might try to route it to a smarter machine, but w\
ithout knowing which network to send it to, it)72 330 R(can')72 342 Q 2.78(tg)
-.18 G .28(uess which smarter machine to forward to.)99.59 342 R .28
(Another problem is name space collision - there is noth-)5.28 F 1.293(ing to \
prevent a host on one network from choosing the same name as a host on another\
network.)72 354 R(For)6.293 E .944(example, DEC')72 366 R 3.444(sE)-.55 G .944
(NET has a `)148.048 366 R(`vortex')-.74 E 3.444('m)-.74 G .944
(achine, there is also one on UUCP)244.204 366 R 5.943(.B)-1.11 G .943
(oth had their names long)401.348 366 R .13
(before the two networks could talk to each other)72 378 R 2.63(,a)-.4 G .131
(nd neither had to ask the other network for permission to)275.5 378 R 1.268
(use the name.)72 390 R 1.268(The problem is compounded when you consider how \
many computer centers name their)6.268 F(machines `)72 402 Q(`A)-.74 E -.74('')
-1.11 G 2.5(,`).74 G(`B')137.81 402 Q(', `)-.74 E(`C')-.74 E(', and so on.)-.74
E 1.123(In recognition of this problem, ARP)72 420 R 3.623(Ah)-.92 G 1.123
(as established a new way to name computers based on domains.)236.978 420 R
1.423(The ARP)72 432 R 1.423(ANET is pioneering the domain convention, and man\
y other computer networks are falling in)-.92 F .575(line, since it is the \
\214rst naming convention that looks like it really stands a chance of working\
.)72 444 R .576(The MIL-)5.576 F .626(NET portion of ARP)72 456 R .626
(ANET has a domain, CSNET has one, and it appears that Digital, A)-.92 F(T&T)
-1.11 E 3.125(,a)-.74 G .625(nd UUCP)464.205 456 R .661
(will be using domains as well.)72 468 R .661
(Domains look a lot like postal addresses, with a simple syntax that \214ts on)
5.661 F .876(one line, is easy to type, and is easy for computers to handle.)72
480 R 2.276 -.7(To i)5.876 H .875(llustrate, an old routed UUCP address).7 F
7.093(might read `)72 492 R(`sdcsvax!ucbvax!allegra!cbosgd!mark')-.74 E 9.593
('. The)-.74 F 7.094(domain version of this might read)9.593 F -.74(``)72 504 S
(mark@d.osg.cb.att.uucp').74 E 4.443('. The)-.74 F 1.942
(machine is named d.osg.cb.att.uucp \(UUCP domain, A)4.443 F 1.942(T&T company)
-1.11 F(,)-.65 E 1.183
(Columbus site, Operating System Group project, fourth machine.\))72 516 R
1.183(Of course, this example is somewhat)6.183 F .877(verbose and contrived; \
it illustrates the heirarchy well, but most people would rather type something\
like)72 528 R -.74(``)72 540 S(cbosgd.att.uucp').74 E 2.791('o)-.74 G 2.791
(re)154.401 540 S .292(ven `)164.962 540 R(`cbosgd.uucp')-.74 E .292
(', and actual domains are usually set up so that you don')-.74 F 2.792(th)-.18
G .292(ave to)479.548 540 R(type very much.)72 552 Q -1(Yo)72 570 S 5.307(um)1
G 2.806(ay wonder why the single @ sign is present, that is, why the above add\
ress does not read)101.307 570 R -.74(``)72 582 S(mark.d.osg.cb.att.uucp').74 E
3.736('. In)-.74 F 1.236
(fact, it was originally proposed in this form, and some of the examples in)
3.736 F .961(RFC819 do not contain an @ sign.)72 594 R .961
(The @ sign is present because some ARP)5.961 F .961
(ANET sites felt the strong)-.92 F .317(need for a divider between the domain,\
which names one or more computers, and the left hand side, which)72 606 R 1.73
(is subject to whatever interpretation the domain chooses.)72 618 R 1.729
(For example, if the A)6.729 F 1.729(TT domain chooses to)-1.11 F .185
(address people by full name rather than by their login, an address like `)72
630 R(`Mark.Horton@A)-.74 E(TT)-1.11 E(.UUCP')-.74 E 2.685('m)-.74 G(akes)
486.23 630 Q .16(it clear that some machine in the A)72 642 R .159
(TT domain should interpret the string `)-1.11 F(`Mark.Horton')-.74 E .159
(', but if the address)-.74 F 2.657(were `)72 654 R(`Mark.Horton.A)-.74 E(TT)
-1.11 E(.UUCP')-.74 E 2.657
(', routing software might try to \214nd a machine named `)-.74 F(`Horton')-.74
E 5.158('o)-.74 G(r)500.67 654 Q -.74(``)72 666 S(Mark.Horton').74 E 2.613
('. \(By)-.74 F .113(the way)2.613 F 2.613(,c)-.65 G .113
(ase is ignored in domains, so that `)201.952 666 R(`A)-.74 E(TT)-1.11 E
(.UUCP')-.74 E 2.612('i)-.74 G 2.612(st)402.282 666 S .112(he same as `)411.564
666 R(`att.uucp')-.74 E('.)-.74 E 1.58 -.7(To t)72 678 T .181
(he left of the @ sign, however).7 F 2.681(,ad)-.4 G .181
(omain can interpret the text any way it wants; case can be ignored or)226.987
678 R(it can be signi\214cant.\))72 690 Q 1.202(It is important to note that)72
708 R/F1 10/Times-Bold@0 SF 1.202(domains ar)3.702 F 3.702(en)-.18 G 1.202
(ot r)248.666 708 R(outes)-.18 E F0 6.202(.S)C 1.202
(ome people look at the number of !')301.44 708 R 3.702(si)-.55 G 3.702(nt)
463.816 708 S 1.202(he \214rst)475.298 708 R .679(example and the number of .')
72 720 R 3.179(si)-.55 G 3.179(nt)202.444 720 S .68
(he second, and assume the latter is being routed from a machine called)213.403
720 R -.74(``)72 732 S(uucp').74 E 2.548('t)-.74 G 2.548(oa)108.608 732 S .048
(nother called `)120.596 732 R(`att')-.74 E 2.548('t)-.74 G 2.548(oa)202.29 732
S .048(nother called `)214.278 732 R(`cb')-.74 E 2.548('a)-.74 G .048
(nd so on.)297.072 732 R .048(While it is possible to set up mail routing)5.048
F .547(software to do this, and indeed in the worst case, even without a reaso\
nable set of tables, this method will)72 744 R EP
%%Page: 3 3
%%BeginPageSetup
BP
%%EndPageSetup
/F0 10/Times-Roman@0 SF .077(always work, the intent is that `)72 96 R
(`d.osg.cb.att.uucp')-.74 E 2.577('i)-.74 G 2.577(st)279.919 96 S .077
(he name of a machine, not a path to get there.)289.166 96 R .077(In par)5.077
F(-)-.2 E(ticular)72 108 Q 2.534(,d)-.4 G .035(omains are absolute addresses, \
while routes depend on the location of the sender)107.184 108 R 5.035(.S)-.55 G
.035(ome subroutine)442.025 108 R 1.067(is char)72 120 R 1.067(ged with \214gu\
ring out, given a domain based machine name, what to do with it.)-.18 F 1.066
(In a high quality)6.067 F .148(environment like the ARP)72 132 R 2.648(AI)-.92
G .148(nternet, it can query a table or a name server)189.442 132 R 2.648(,c)
-.4 G .148(ome up with a 32 bit host num-)377.682 132 R(ber)72 144 Q 2.555(,a)
-.4 G .055(nd connect you directly to that machine.)93.865 144 R .055
(In the UUCP environment, we don')5.055 F 2.555(th)-.18 G .055
(ave the concept of two)413.25 144 R .785
(processes on arbitrary machines talking directly)72 156 R 3.286(,s)-.65 G
3.286(ow)276.302 156 S 3.286(ef)291.808 156 S .786
(orward mail one hop at a time until it gets to the)302.864 156 R .096
(appropriate destination.)72 168 R .096(In this case, the subroutine decides i\
f the name represents the local machine, and if)5.096 F
(not, decides which of its neighbors to forward the message to.)72 180 Q/F1 10
/Times-Italic@0 SF 2.5(2. What)72 204 R(is a Domain?)2.5 E F0 .084
(So, after all this background, we still haven')72 222 R 2.584(ts)-.18 G .084
(aid what a domain is.)258.582 222 R .085(The answer \(I hope it')5.085 F 2.585
(sb)-.55 G .085(een worth the)449.4 222 R .439
(wait\) is that a domain is a subtree of the world tree.)72 234 R .439
(For example, `)5.439 F(`uucp')-.74 E 2.939('i)-.74 G 2.939(sat)380.937 234 S
.439(op level domain \(that is, a)397.925 234 R .127(subtree of the `)72 246 R
(`root')-.74 E .127
('.\) and represents all names and machines beneath it in the tree.)-.74 F -.74
(``)5.128 G(att.uucp').74 E 2.628('i)-.74 G 2.628(sas)463.194 246 S(ubdo-)
480.67 246 Q .04(main of `)72 258 R(`uucp')-.74 E .04
(', representing all names, machines, and subdomains beneath `)-.74 F(`att')
-.74 E 2.54('i)-.74 G 2.54(nt)407.74 258 S .04(he tree.)418.06 258 R .04
(Similarly for)5.04 F -.74(``)72 270 S(cb.att.uucp').74 E .812(', `)-.74 F
(`osg.cb.att.uucp')-.74 E .812(', and even `)-.74 F(`d.osg.cb.att.uucp')-.74 E
3.312('\()-.74 G .812(although `)337.65 270 R(`d.osg.cb.att.uucp')-.74 E 3.312
('i)-.74 G 3.313(sa`)461.664 270 S -1.95(`leaf ')479.21 270 R(')-.74 E
(domain, representing only the one machine\).)72 282 Q 2.664(Ad)72 300 S .164
(omain has certain properties.)86.884 300 R .164
(The key property is that it has a `)5.164 F(`registry')-.74 E 2.663('. That)
-.74 F .163(is, the domain has a list)2.663 F .429(of the names of all immedia\
te subdomains, plus information about how to get to each one.)72 312 R .43
(There is also a)5.43 F .601(contact person for the domain.)72 324 R .601
(This person is responsible for the domain, keeping the registry up-to-date,)
5.601 F .007(serving as a point of contact for outside queries, and setting po\
licy requirements for subdomains.)72 336 R .008(Each sub-)5.008 F .839(domain \
can decide who it will allow to have subdomains, and establish requirements th\
at all subdomains)72 348 R .062(must meet to be included in the registry)72 360
R 5.062(.F)-.65 G .062(or example, the `)243.506 360 R(`cb')-.74 E 2.562('d)
-.74 G .063(omain might require all subdomains to be)336.964 360 R
(physically located in the A)72 372 Q(T&T building in Columbus.)-1.11 E(ARP)72
390 Q 3.564(Ah)-.92 G 1.064
(as established certain requirements for top level domains.)106.314 390 R 1.064
(These requirements specify that there)6.064 F .371(must be a list of all subd\
omains and contact persons for them, a responsible person who is an authority \
for)72 402 R .685(the domain \(so that if some site does something bad, it can\
be made to stop\), a minimum size \(to prevent)72 414 R 1.051(small domains f\
rom being top level\), and a pair of nameservers \(for redundancy\) to provide\
a directory-)72 426 R .367(assistance facility)72 438 R 5.367(.D)-.65 G .367(\
omains can be more lax about the requirements they place on their subdomains, \
mak-)157.624 438 R .139
(ing it harder to be a top level domain than somewhere lower in the tree.)72
450 R .139(Of course, if you are a subdomain,)5.139 F
(your parent is responsible for you.)72 462 Q 1.005
(One requirement that is NOT present is for unique parents.)72 480 R 1.004
(That is, a machine \(or an entire subdomain\))6.005 F .724
(need not appear in only one place in the tree.)72 492 R .725(Thus, `)5.724 F
(`cb')-.74 E 3.225('m)-.74 G .725(ight appear both in the `)321.65 492 R(`att')
-.74 E 3.225('d)-.74 G .725(omain, and in)447.83 492 R 1.253(the `)72 504 R
(`ohio')-.74 E 3.753('d)-.74 G 3.753(omain. This)126.346 504 R 1.253(allows do\
mains to be structured more \215exibly than just the simple geography)3.753 F
.297(used by the postal service and the telephone company; or)72 516 R .298
(ganizations or topography can be used in parallel.)-.18 F(\(Actually)72 528 Q
2.761(,t)-.65 G .261(here are a few instances where this is done in the postal\
service [overseas military mail] and the)117.161 528 R .528(telephone system \
[pre\214xes can appear in more than one area code, e.g. near W)72 540 R .529
(ashington D.C., and Silicon)-.8 F -1.11(Va)72 552 S 4.068(lley].\) It)1.11 F
1.567(also allows domains to split or join up, while remaining upward compatib\
le with their old)4.068 F(addresses.)72 564 Q 1.958
(Do all domains represent speci\214c machines?)72 582 R 1.958(Not necessarily)
6.958 F 6.958(.I)-.65 G(t')342.794 582 Q 4.458(sp)-.55 G 1.958
(retty obvious that a full path like)361.702 582 R -.74(``)72 594 S
(d.cbosg.att.uucp').74 E 3.546('r)-.74 G 1.046(efers to exactly one machine.)
155.986 594 R 1.046(The OSG domain might decide that `)6.046 F
(`cbosg.att.uucp')-.74 E(')-.74 E .385
(represents a particular gateway machine.)72 606 R .385
(Or it might decide that it represents a set of machines, several of)5.385 F
1.763(which might be gateways.)72 618 R 1.763(The `)6.763 F(`att.uucp')-.74 E
4.263('d)-.74 G 1.762(omain might decide that several machines, `)261.338 618 R
(`ihnp4.uucp')-.74 E(',)-.74 E -.74(``)72 630 S(whgwj.uucp').74 E .482
(', and `)-.74 F(`hogtw)-.74 E(.uucp')-.65 E 2.982('a)-.74 G .482
(re all entry points into `)221.456 630 R(`att.uucp')-.74 E 2.983('. Or)-.74 F
.483(it might decide that it just rep-)2.983 F .045
(resents a spot in the name space, not a machine.)72 642 R .044
(For example, there is no machine corresponding to `)5.044 F(`arpa')-.74 E(')
-.74 E .336(or `)72 654 R(`uucp')-.74 E .336(', or to the root.)-.74 F .337
(Each domain decides for itself.)5.336 F .337
(The naming space and the algorithm for getting)5.337 F .977(mail from one mac\
hine to another are not closely linked - routing is up to the mail system to \
\214gure out,)72 666 R(with or without help from the structure of the names.)72
678 Q .286(The domain syntax does allow explicit routes, in case you want to e\
xercise a particular route or some gate-)72 696 R 9.168(way is balking.)72 708
R 9.167(The syntax is `)165.334 708 R(`@dom)-.74 E(1)281.576 713 Q(,@dom)
286.576 708 Q(2)316.066 713 Q(,...,@dom)321.066 708 Q(n)360.556 713 Q
(:user@domain')365.556 708 Q 9.167(', for example,)-.74 F(@ihnp4.UUCP)72 720 Q
(,@ucbvax.UUCP)-1.11 E(,:joe@NIC.ARP)-1.11 E .946
(A, forcing it to be routed through dom)-.92 F(1)425.602 725 Q 3.446(,d)430.602
720 S(om)441.548 720 Q(2)454.328 725 Q 3.446(,.)459.328 720 S .946(.., dom)
467.774 720 R(n)496.5 725 Q(,)501.5 720 Q .406
(and from domn sent to the \214nal address.)72 732 R .406
(This behaves exactly like the UUCP ! routing syntax, although it)5.406 F
(is somewhat more verbose.)72 744 Q EP
%%Page: 4 4
%%BeginPageSetup
BP
%%EndPageSetup
/F0 10/Times-Roman@0 SF 2.218(By the way)72 96 R 4.718(,y)-.65 G 2.219(ou've n\
o doubt noticed that some forms of electronic addresses read from left-to-righ\
t)133.554 96 R .545
(\(cbosgd!mark\), others read from right-to-left \(mark@Berkeley\).)72 108 R
.545(Which is better?)5.545 F .544(The real answer here is)5.544 F .891
(that it')72 120 R 3.391(sar)-.55 G .891(eligious issue, and it doesn')117.173
120 R 3.391(tm)-.18 G .891(ake much dif)245.338 120 R 3.391
(ference. left-to-right)-.18 F .891(is probably a bit easier for a)3.391 F
1.413(computer to deal with because it can understand something on the left an\
d ignore the remainder of the)72 132 R 2.507(address. \(While)72 144 R(it')
2.507 E 2.507(sa)-.55 G .008(lmost as easy for the program to read from right-\
to-left, the ease of going from left-to-)158.951 144 R(right was probably in t\
he backs of the minds of the designers who invented host:user and host!user)72
156 Q(.\))-.55 E .779(On the other hand, I claim that user@host is easier for \
humans to read, since people tend to start reading)72 174 R .811(from the left\
and quit as soon as they recognize the login name of the person.)72 186 R .812
(Also, a mail program that)5.812 F 1.53
(prints a table of headers may have to truncate the sender)72 198 R 2.629 -.55
('s a).37 H 1.529(ddress to make it \214t in a \214xed number of).55 F
(columns, and it')72 210 Q 2.5(sp)-.55 G(robably more useful to read `)147.56
210 Q(`mark@d.osg.a')-.74 E 2.5('t)-.74 G(han `)335.8 210 Q(`ucbvax!sdcsv')-.74
E('.)-.74 E .841(These are pretty minor issues, after all, humans can adapt to\
skip to the end of an address, and programs)72 228 R .393
(can truncate on the left.)72 240 R .392(But the real problem is that if the w\
orld contains BOTH left-to-right and right-to-)5.392 F .82
(left syntax, you have ambiguous addresses like x!y@z to consider)72 252 R 5.82
(.T)-.55 G .82(his single problem turns out to be a)357.43 252 R(killer)72 264
Q 2.5(,a)-.4 G
(nd is the best single reason to try to stamp out one in favor of the other)
102.15 264 Q(.)-.55 E/F1 10/Times-Italic@0 SF 2.5(3. So)72 288 R(why ar)2.5 E
2.5(ew)-.37 G 2.5(ed)137.74 288 S(oing this, anyway?)149.68 288 Q F0 .938
(The current world is full of lots of interesting kinds of mail syntax.)72 306
R .938(The old ARP)5.938 F 3.437(A`)-.92 G(`user@host')423.656 306 Q 3.437('i)
-.74 G 3.437(ss)481.663 306 S(till)492.88 306 Q 1.156(used on the ARP)72 318 R
1.156(ANET by many systems.)-.92 F 1.156
(Explicit routing can sometimes by done with an address like)6.156 F -.74(``)72
330 S(user@host2@host1').74 E 3.856('w)-.74 G 1.356
(hich sends the mail to host1 and lets host1 interpret `)173.336 330 R
(`user@host2')-.74 E 3.855('. Addresses)-.74 F .704
(with more than one @ were made illegal a few years ago, but many ARP)72 342 R
.704(ANET hosts depended on them,)-.92 F 1.899
(and the syntax is still being used.)72 354 R 1.899(UUCP uses `)6.899 F -2.13
(`h1!h2!h3!user ')-.74 F 1.898(', requiring the user to route the mail.)-.74 F
(Berknets use `)72 366 Q -2.13(`host:user ')-.74 F 2.5('a)-.74 G
(nd do not allow explicit routing.)181.14 366 Q 4.804 -.7(To g)72 384 T 3.404
(et mail from one host to another).7 F 5.904(,i)-.4 G 5.904(th)252.842 384 S
3.404(ad to be routed through gateways.)266.526 384 R 3.405(Thus, the address)
8.404 F -.74(``)72 396 S(csvax:mark@Berkeley').74 E 2.744('f)-.74 G .244
(rom the ARP)181.324 396 R .244(ANET would send the mail to Berkeley)-.92 F
2.743(,w)-.65 G .243(hich would forward it to)405.818 396 R 2.948
(the Berknet address csvax:mark.)72 408 R 4.348 -.7(To s)7.948 H 2.949
(end mail to the ARP).7 F 2.949(ANET from UUCP)-.92 F 5.449(,a)-1.11 G 5.449
(na)426.003 408 S 2.949(ddress such as)440.892 408 R -.74(``)72 420 S
(ihnp4!ucbvax!sam@foo-unix').74 E 7.46('w)-.74 G 4.96
(ould route it through ihnp4 to ucbvax, which would interpret)216.6 420 R -.74
(``)72 432 S(sam@foo-unix').74 E 4.422('a)-.74 G 4.422(sa)152.462 432 S 4.422
(nA)165.214 432 S(RP)181.856 432 Q 1.922(ANET address and pass it along.)-.92 F
1.923(When the Berknet-UUCP gateway and)6.922 F(Berknet-ARP)72 444 Q 16.197
(ANET gateway were on dif)-.92 F 16.196(ferent machines, addresses such as)-.18
F -.74(``)72 456 S(csvax:ihnp4!ihnss!warren@Berkeley').74 E 2.5('w)-.74 G
(ere common.)242.18 456 Q .986(As you can see, the combination of left-to-righ\
t UUCP syntax and right-to-left ARP)72 474 R .986(ANET syntax makes)-.92 F
1.681(things pretty complex.)72 486 R 1.681(Berknets are gone now)6.681 F 4.181
(,b)-.65 G 1.68(ut there are lots of gateways between UUCP and the)279.757 486
R(ARP)72 498 Q 1.301(ANET and ARP)-.92 F(ANET)-.92 E 1.301
(-like mail networks.)-.92 F 1.301
(Sending mail to an address for which you only know a)6.301 F 5.618
(path from the ARP)72 510 R 5.618
(ANET onto UUCP is even harder \255 suppose the address you have is)-.92 F
(ihnp4!ihnss!warren@Berkeley)72 522 Q 3.51(,a)-.65 G 1.011
(nd you are on host rlgvax which uses seismo as an ARP)204.87 522 R 1.011
(ANET gateway)-.92 F(.)-.65 E -1(Yo)72 534 S 3.535(um)1 G 1.035
(ust send to seismo!ihnp4!ihnss!warren@Berkeley)99.535 534 R 3.535(,w)-.65 G
1.035(hich is not only pretty hard to read, but when)314.705 534 R 1.43
(the recipient tries to reply)72 546 R 3.93(,i)-.65 G 3.93(tw)189.04 546 S 1.43
(ill have no idea where the break in the address between the two UUCP)202.97
546 R .608(pieces occurs.)72 558 R .608(An ARP)5.608 F .608
(ANET site routing across the UUCP world to somebody')-.92 F 3.108(sE)-.55 G
.607(thernet using domains)414.456 558 R 2.224
(locally will have to send an address something like `)72 570 R(`xxx@Berkeley)
-.74 E(.ARP)-.65 E -1.02 -1.11(A' ')-.92 H 2.225(to get it to UUCP)5.835 F
4.725(,t)-1.11 G(hen)489.56 570 Q -.74(``)72 582 S(ihnp4!decvax!island!yyy').74
E 4.039('t)-.74 G 4.039(og)190.639 582 S 1.539
(et it to the other ethernet, then `)204.678 582 R(`sam@csvax.ISLAND')-.74 E
4.038('t)-.74 G 4.038(og)444.116 582 S 1.538(et it across)458.154 582 R 31.285
(their ethernet.)72 594 R 31.286(The single address would therefore be)195.11
594 R(ihnp4!decvax!island!sam@csvax.ISLAND@Berkeley)72 606 Q(.ARP)-.65 E 2.801
(A, which is too much to ask any person or)-.92 F 5.863(mailer to understand.)
72 618 R(It')179.299 618 Q 8.363(se)-.55 G 5.863
(ven worse: gateways have to deal with ambiguous names like)204.882 618 R
(ihnp4!mark@Berkeley)72 630 Q 4.833(,w)-.65 G 2.333
(hich can be parsed either `)177.873 630 R(`\(ihnp4!mark\)@Berkeley')-.74 E
4.833('i)-.74 G 4.833(na)409.531 630 S 2.333(ccordance with the)423.804 630 R
(ARP)72 642 Q(ANET conventions, or `)-.92 E(`ihnp4!\(mark@Berkeley\)')-.74 E
2.5('a)-.74 G 2.5(st)301.26 642 S(he old UUCP would.)310.43 642 Q .415(Another\
very important reason for using domains is that your mailing address becomes \
absolute instead of)72 660 R 3.03(relative. It)72 672 R .53(becomes possible t\
o put your electronic address on your business card or in your signature \214l\
e)3.03 F .185(without worrying about writing six dif)72 684 R .185
(ferent forms and \214fteen hosts that know how to get to yours.)-.18 F .185
(It dras-)5.185 F .468(tically simpli\214es the job of the reply command in yo\
ur mail program, and automatic reply code in the net-)72 696 R(news software.)
72 708 Q EP
%%Page: 5 5
%%BeginPageSetup
BP
%%EndPageSetup
/F0 10/Times-Italic@0 SF 2.5(4. Further)72 96 R(Information)2.5 E/F1 10
/Times-Roman@0 SF .794(For further information, some of the basic ARP)72 114 R
.794(ANET reference documents are in order)-.92 F 5.794(.T)-.55 G .794
(hese can often)445.212 114 R .65
(be found posted to Usenet, or available nearby)72 126 R 5.65(.T)-.65 G .65
(hey are all available on the ARP)276.23 126 R .65(ANET on host NIC via)-.92 F
.371(FTP with login ANONYMOUS, if you have an ARP)72 138 R .371(ANET login.)
-.92 F .371(They can also be ordered from the Net-)5.371 F
(work Information Center)72 150 Q 2.5(,S)-.4 G
(RI International, Menlo Park, California, 94025.)182.14 150 Q 2.5(RFC819 The)
72 168 R(Domain Naming Convention for Internet User Applications)2.5 E 2.5
(RFC821 Simple)72 180 R(Mail T)2.5 E(ransfer Protocol)-.35 E 2.5
(RFC822 Standard)72 192 R(for the Format of ARP)2.5 E(ANET T)-.92 E
(ext Messages)-.7 E 2.5(RFC881 The)72 204 R(Domain Names Plan and Schedule)2.5
E(#)72 222 Q 2.5(#@)72 234 S 29.07(\(#\)domain.mm 2.1)88.71 234 R
(smail 12/14/86)2.5 E(#)72 246 Q EP
%%Trailer
end
%%EOF

3424
usr.sbin/named/doc/misc/purdue-paper.ps Normal file
View File

File diff suppressed because it is too large Load Diff

7129
usr.sbin/named/doc/misc/purdue-thesis.ps Normal file
View File

File diff suppressed because it is too large Load Diff

172
usr.sbin/named/doc/misc/style.txt Normal file
View File

@ -0,0 +1,172 @@
Path: vixie!vixie
From: vixie@vix.com (Paul A Vixie)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: Format of DNS files (style question)
Date: 28 Aug 94 03:17:08
Organization: Vixie Enterprises
Lines: 159
Distribution: inet
Message-ID: <VIXIE.94Aug28031708@office.home.vix.com>
References: <33onnr$i4u@zombie.ncsc.mil>
NNTP-Posting-Host: office.home.vix.com
In-reply-to: sjr@zombie.ncsc.mil's message of 27 Aug 1994 21:02:51 -0400
> (Style) Suggestions for how to layout DNS configuration files (both
> forward and reverse)?
I've gone back and forth on the question of whether the BOG should include a
section on this topic. I know what I myself prefer, but I'm wary of ramming
my own stylistic preferences down the throat of every BOG reader. But since
you ask :-)...
Create /var/named. If your system is too old to have a /var, either create
one or use /usr/local/adm/named instead. Put your named.boot in it, and make
/etc/named.boot a symlink to it. If your system doesn't have symlinks, you're
S-O-L (but you knew that). In named.boot, put a "directory" directive that
specifies your actual BIND working directory:
directory /var/named
All relative pathnames used in "primary", "secondary", and "cache" directives
will be evaluated relative to this directory. Create two subdirectories,
/var/named/pri and /var/named/sec. Whenever you add a "primary" directive
to your named.boot, use "pri/WHATEVER" as the path name. And then put the
primary zone file into "pri/WHATEVER". Likewise when you add "secondary"
directives, use "sec/WHATEVER" and BIND (really named-xfer) will create the
files in that subdirectory.
(Variations: (1) make a midlevel directory "zones" and put "pri" and "sec"
into it; (2) if you tend to pick up a lot of secondaries from a few hosts,
group them together in their own subdirectories -- something like
/var/named/zones/uucp if you're a UUCP Project name server.)
For your forward files, name them after the zone. dec.com becomes
"/var/named/zones/pri/dec.com". For your reverse files, name them after the
network number. 0.1.16.in-addr.arpa becomes "/var/named/zones/pri/16.1.0".
When creating or maintaining primary zone files, try to use the same SOA
values everywhere, except for the serial number which varies per zone. Put
a $ORIGIN directive at the top of the primary zone file, not because it's
needed (it's not since the default origin is the zone named in the "primary"
directive) but because it make it easier to remember what you're working on
when you have a lot of primary zones. Put some comments up there indicating
contact information for the real owner if you're proxying. Use RCS and put
the "$Id: style.txt,v 1.1.1.1 1997/04/13 09:08:00 mrg Exp $" in a ";" comment near the top of the zone file.
The SOA and other top level information should all be listed together. But
don't put IN on every line, it defaults nicely. For example:
==============
@ IN SOA gw.home.vix.com. postmaster.vix.com. (
1994082501 ; serial
3600 ; refresh (1 hour)
1800 ; retry (30 mins)
604800 ; expire (7 days)
3600 ) ; minimum (1 hour)
NS gw.home.vix.com.
NS ns.uu.net.
NS uucp-gw-1.pa.dec.com.
NS uucp-gw-2.pa.dec.com.
MX 10 gw.home.vix.com.
MX 20 uucp-gw-1.pa.dec.com.
MX 20 uucp-gw-1.pa.dec.com.
==============
I don't necessarily recommend those SOA values. Not every zone is as volatile
as the example shown. I do recommend that serial number format; it's in date
format with a 2-digit per-day revision number. This format will last us until
2147 A.D. at which point I expect a better solution will have been found :-).
(Note that it would last until 4294 A.D. except that there are some old BINDs
out there that use a signed quantity for representing serial number interally;
I suppose that as long as none of these are still running after 2047 A.D.,
that we can use the above serial number format until 4294 A.D., at which point
a better solution will HAVE to be found.)
You'll note that I use a tab stop for "IN" even though I never again specify
it. This leaves room for names longer than 7 bytes without messing up the
columns. You might also note that I've put the MX priority and destination
in the same tab stop; this is because both are part of the RRdata and both
are very different from MX which is an RRtype. Some folks seem to prefer to
group "MX" and the priority together in one tab stop. While this looks neat
it's very confusing to newcomers and for them it violates the law of least
astonishment.
If you have a multi-level zone (one which contains names that have dots in
them), you can use additional $ORIGIN statements but I recommend against it
since there is no "back" operator. That is, given the above example you can
add:
=============
$ORIGIN home
gw A 192.5.5.1
=============
The problem with this is that subsequent RR's had better be somewhere under
the "home.vix.com" name or else the $ORIGIN that introduces them will have
to use a fully qualified name. FQDN $ORIGIN's aren't bad and I won't be mad
if you use them. Unqualified ones as shown above are real trouble. I usually
stay away from them and just put the whole name in:
=============
gw.home A 192.5.5.1
=============
In your reverse zones, you're usually in some good luck because the owner name
is usually a single short token or sometimes two.
=============
$ORIGIN 5.5.192.in-addr.arpa.
@ IN SOA ...
NS ...
1 PTR gw.home.vix.com.
-------------
$ORIGIN 1.16.in-addr.arpa.
@ IN SOA ...
NS ...
2.0 PTR gatekeeper.dec.com.
=============
It is usually pretty hard to keep your forward and reverse zones in synch.
You can avoid that whole problem by just using "h2n" (see the ORA book, DNS
and BIND, and its sample toolkit, included in the BIND distribution or on
ftp.uu.net (use the QUOTE SITE EXEC INDEX command there to find this -- I
never can remember where it's at). "h2n" and many tools like it can just
read your old /etc/hosts file and churn it into DNS zone files. (May I
recommend contrib/decwrl/mkdb.pl from the BIND distribution?) However, if
you (like me) prefer to edit these things by hand, you need to follow the
simple convention of making all of your holes consistent. If you use
192.5.5.1 and 192.5.5.3 but not (yet) 192.5.5.2, then in your forward file
you will have something like
=============
...
gw.home A 192.5.5.1
;avail A 192.5.5.2
pc.home A 192.5.5.3
=============
and in your reverse file you will have something like
=============
...
1 PTR gw.home.vix.com.
;2 PTR avail
3 PTR pc.home.vix.com.
=============
This convention will allow you to keep your sanity and make fewer errors.
Any kind of automation (h2n, mkdb, or your own perl/tcl/awk/python tools)
will help you maintain a consistent universe even if it's also a complex
one. Editing by hand doesn't have to be deadly but you MUST take care.
Anyone who wants to know how to maintain nonleaf zones, i.e., zones which
have few or no hosts in them but have hundreds or thousands of delegations,
should attend Usenix LISA in San Diego and be there for the SENDS talk.
Contact office@usenix.org for conference information.
--
Paul Vixie
Redwood City, CA
decwrl!vixie!paul
<paul@vix.com>

2915
usr.sbin/named/doc/misc/vixie-security.ps Normal file
View File

File diff suppressed because it is too large Load Diff

781
usr.sbin/named/doc/rfc/rfc1032 Normal file
View File

@ -0,0 +1,781 @@
Network Working Group M. Stahl
Request for Comments: 1032 SRI International
November 1987
DOMAIN ADMINISTRATORS GUIDE
STATUS OF THIS MEMO
This memo describes procedures for registering a domain with the
Network Information Center (NIC) of Defense Data Network (DDN), and
offers guidelines on the establishment and administration of a domain
in accordance with the requirements specified in RFC-920. It is
intended for use by domain administrators. This memo should be used
in conjunction with RFC-920, which is an official policy statement of
the Internet Activities Board (IAB) and the Defense Advanced Research
Projects Agency (DARPA). Distribution of this memo is unlimited.
BACKGROUND
Domains are administrative entities that provide decentralized
management of host naming and addressing. The domain-naming system
is distributed and hierarchical.
The NIC is designated by the Defense Communications Agency (DCA) to
provide registry services for the domain-naming system on the DDN and
DARPA portions of the Internet.
As registrar of top-level and second-level domains, as well as
administrator of the root domain name servers on behalf of DARPA and
DDN, the NIC is responsible for maintaining the root server zone
files and their binary equivalents. In addition, the NIC is
responsible for administering the top-level domains of "ARPA," "COM,"
"EDU," "ORG," "GOV," and "MIL" on behalf of DCA and DARPA until it
becomes feasible for other appropriate organizations to assume those
responsibilities.
It is recommended that the guidelines described in this document be
used by domain administrators in the establishment and control of
second-level domains.
THE DOMAIN ADMINISTRATOR
The role of the domain administrator (DA) is that of coordinator,
manager, and technician. If his domain is established at the second
level or lower in the tree, the DA must register by interacting with
the management of the domain directly above his, making certain that
Stahl [Page 1]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
his domain satisfies all the requirements of the administration under
which his domain would be situated. To find out who has authority
over the name space he wishes to join, the DA can ask the NIC
Hostmaster. Information on contacts for the top-level and second-
level domains can also be found on line in the file NETINFO:DOMAIN-
CONTACTS.TXT, which is available from the NIC via anonymous FTP.
The DA should be technically competent; he should understand the
concepts and procedures for operating a domain server, as described
in RFC-1034, and make sure that the service provided is reliable and
uninterrupted. It is his responsibility or that of his delegate to
ensure that the data will be current at all times. As a manager, the
DA must be able to handle complaints about service provided by his
domain name server. He must be aware of the behavior of the hosts in
his domain, and take prompt action on reports of problems, such as
protocol violations or other serious misbehavior. The administrator
of a domain must be a responsible person who has the authority to
either enforce these actions himself or delegate them to someone
else.
Name assignments within a domain are controlled by the DA, who should
verify that names are unique within his domain and that they conform
to standard naming conventions. He furnishes access to names and
name-related information to users both inside and outside his domain.
He should work closely with the personnel he has designated as the
"technical and zone" contacts for his domain, for many administrative
decisions will be made on the basis of input from these people.
THE DOMAIN TECHNICAL AND ZONE CONTACT
A zone consists of those contiguous parts of the domain tree for
which a domain server has complete information and over which it has
authority. A domain server may be authoritative for more than one
zone. The domain technical/zone contact is the person who tends to
the technical aspects of maintaining the domain's name server and
resolver software, and database files. He keeps the name server
running, and interacts with technical people in other domains and
zones to solve problems that affect his zone.
POLICIES
Domain or host name choices and the allocation of domain name space
are considered to be local matters. In the event of conflicts, it is
the policy of the NIC not to get involved in local disputes or in the
local decision-making process. The NIC will not act as referee in
disputes over such matters as who has the "right" to register a
particular top-level or second-level domain for an organization. The
NIC considers this a private local matter that must be settled among
Stahl [Page 2]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
the parties involved prior to their commencing the registration
process with the NIC. Therefore, it is assumed that the responsible
person for a domain will have resolved any local conflicts among the
members of his domain before registering that domain with the NIC.
The NIC will give guidance, if requested, by answering specific
technical questions, but will not provide arbitration in disputes at
the local level. This policy is also in keeping with the distributed
hierarchical nature of the domain-naming system in that it helps to
distribute the tasks of solving problems and handling questions.
Naming conventions for hosts should follow the rules specified in
RFC-952. From a technical standpoint, domain names can be very long.
Each segment of a domain name may contain up to 64 characters, but
the NIC strongly advises DAs to choose names that are 12 characters
or fewer, because behind every domain system there is a human being
who must keep track of the names, addresses, contacts, and other data
in a database. The longer the name, the more likely the data
maintainer is to make a mistake. Users also will appreciate shorter
names. Most people agree that short names are easier to remember and
type; most domain names registered so far are 12 characters or fewer.
Domain name assignments are made on a first-come-first-served basis.
The NIC has chosen not to register individual hosts directly under
the top-level domains it administers. One advantage of the domain
naming system is that administration and data maintenance can be
delegated down a hierarchical tree. Registration of hosts at the
same level in the tree as a second-level domain would dilute the
usefulness of this feature. In addition, the administrator of a
domain is responsible for the actions of hosts within his domain. We
would not want to find ourselves in the awkward position of policing
the actions of individual hosts. Rather, the subdomains registered
under these top-level domains retain the responsibility for this
function.
Countries that wish to be registered as top-level domains are
required to name themselves after the two-letter country code listed
in the international standard ISO-3166. In some cases, however, the
two-letter ISO country code is identical to a state code used by the
U.S. Postal Service. Requests made by countries to use the three-
letter form of country code specified in the ISO-3166 standard will
be considered in such cases so as to prevent possible conflicts and
confusion.
Stahl [Page 3]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
HOW TO REGISTER
Obtain a domain questionnaire from the NIC hostmaster, or FTP the
file NETINFO:DOMAIN-TEMPLATE.TXT from host SRI-NIC.ARPA.
Fill out the questionnaire completely. Return it via electronic mail
to HOSTMASTER@SRI-NIC.ARPA.
The APPENDIX to this memo contains the application form for
registering a top-level or second-level domain with the NIC. It
supersedes the version of the questionnaire found in RFC-920. The
application should be submitted by the person administratively
responsible for the domain, and must be filled out completely before
the NIC will authorize establishment of a top-level or second-level
domain. The DA is responsible for keeping his domain's data current
with the NIC or with the registration agent with which his domain is
registered. For example, the CSNET and UUCP managements act as
domain filters, processing domain applications for their own
organizations. They pass pertinent information along periodically to
the NIC for incorporation into the domain database and root server
files. The online file NETINFO:ALTERNATE-DOMAIN-PROCEDURE.TXT
outlines this procedure. It is highly recommended that the DA review
this information periodically and provide any corrections or
additions. Corrections should be submitted via electronic mail.
WHICH DOMAIN NAME?
The designers of the domain-naming system initiated several general
categories of names as top-level domain names, so that each could
accommodate a variety of organizations. The current top-level
domains registered with the DDN Network Information Center are ARPA,
COM, EDU, GOV, MIL, NET, and ORG, plus a number of top-level country
domains. To join one of these, a DA needs to be aware of the purpose
for which it was intended.
"ARPA" is a temporary domain. It is by default appended to the
names of hosts that have not yet joined a domain. When the system
was begun in 1984, the names of all hosts in the Official DoD
Internet Host Table maintained by the NIC were changed by adding
of the label ".ARPA" in order to accelerate a transition to the
domain-naming system. Another reason for the blanket name changes
was to force hosts to become accustomed to using the new style
names and to modify their network software, if necessary. This
was done on a network-wide basis and was directed by DCA in DDN
Management Bulletin No. 22. Hosts that fall into this domain will
eventually move to other branches of the domain tree.
Stahl [Page 4]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
"COM" is meant to incorporate subdomains of companies and
businesses.
"EDU" was initiated to accommodate subdomains set up by
universities and other educational institutions.
"GOV" exists to act as parent domain for subdomains set up by
government agencies.
"MIL" was initiated to act as parent to subdomains that are
developed by military organizations.
"NET" was introduced as a parent domain for various network-type
organizations. Organizations that belong within this top-level
domain are generic or network-specific, such as network service
centers and consortia. "NET" also encompasses network
management-related organizations, such as information centers and
operations centers.
"ORG" exists as a parent to subdomains that do not clearly fall
within the other top-level domains. This may include technical-
support groups, professional societies, or similar organizations.
One of the guidelines in effect in the domain-naming system is that a
host should have only one name regardless of what networks it is
connected to. This implies, that, in general, domain names should
not include routing information or addresses. For example, a host
that has one network connection to the Internet and another to BITNET
should use the same name when talking to either network. For a
description of the syntax of domain names, please refer to Section 3
of RFC-1034.
VERIFICATION OF DATA
The verification process can be accomplished in several ways. One of
these is through the NIC WHOIS server. If he has access to WHOIS,
the DA can type the command "whois domain <domain name><return>".
The reply from WHOIS will supply the following: the name and address
of the organization "owning" the domain; the name of the domain; its
administrative, technical, and zone contacts; the host names and
network addresses of sites providing name service for the domain.
Stahl [Page 5]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
Example:
@whois domain rice.edu<Return>
Rice University (RICE-DOM)
Advanced Studies and Research
Houston, TX 77001
Domain Name: RICE.EDU
Administrative Contact:
Kennedy, Ken (KK28) Kennedy@LLL-CRG.ARPA (713) 527-4834
Technical Contact, Zone Contact:
Riffle, Vicky R. (VRR) rif@RICE.EDU
(713) 527-8101 ext 3844
Domain servers:
RICE.EDU 128.42.5.1
PENDRAGON.CS.PURDUE.EDU 128.10.2.5
Alternatively, the DA can send an electronic mail message to
SERVICE@SRI-NIC.ARPA. In the subject line of the message header, the
DA should type "whois domain <domain name>". The requested
information will be returned via electronic mail. This method is
convenient for sites that do not have access to the NIC WHOIS
service.
The initial application for domain authorization should be submitted
via electronic mail, if possible, to HOSTMASTER@SRI-NIC.ARPA. The
questionnaire described in the appendix may be used or a separate
application can be FTPed from host SRI-NIC.ARPA. The information
provided by the administrator will be reviewed by hostmaster
personnel for completeness. There will most likely be a few
exchanges of correspondence via electronic mail, the preferred method
of communication, prior to authorization of the domain.
HOW TO GET MORE INFORMATION
An informational table of the top-level domains and their root
servers is contained in the file NETINFO:DOMAINS.TXT online at SRI-
NIC.ARPA. This table can be obtained by FTPing the file.
Alternatively, the information can be acquired by opening a TCP or
UDP connection to the NIC Host Name Server, port 101 on SRI-NIC.ARPA,
and invoking the command "ALL-DOM".
Stahl [Page 6]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
The following online files, all available by FTP from SRI-NIC.ARPA,
contain pertinent domain information:
- NETINFO:DOMAINS.TXT, a table of all top-level domains and the
network addresses of the machines providing domain name
service for them. It is updated each time a new top-level
domain is approved.
- NETINFO:DOMAIN-INFO.TXT contains a concise list of all
top-level and second-level domain names registered with the
NIC and is updated monthly.
- NETINFO:DOMAIN-CONTACTS.TXT also contains a list of all the
top level and second-level domains, but includes the
administrative, technical and zone contacts for each as well.
- NETINFO:DOMAIN-TEMPLATE.TXT contains the questionnaire to be
completed before registering a top-level or second-level
domain.
For either general or specific information on the domain system, do
one or more of the following:
1. Send electronic mail to HOSTMASTER@SRI-NIC.ARPA
2. Call the toll-free NIC hotline at (800) 235-3155
3. Use FTP to get background RFCs and other files maintained
online at the NIC. Some pertinent RFCs are listed below in
the REFERENCES section of this memo.
Stahl [Page 7]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
REFERENCES
The references listed here provide important background information
on the domain-naming system. Path names of the online files
available via anonymous FTP from the SRI-NIC.ARPA host are noted in
brackets.
1. Defense Communications Agency DDN Defense Communications
System, DDN Management Bulletin No. 22, Domain Names
Transition, March 1984.
[ DDN-NEWS:DDN-MGT-BULLETIN-22.TXT ]
2. Defense Communications Agency DDN Defense Communications
System, DDN Management Bulletin No. 32, Phase I of the Domain
Name Implementation, January 1987.
[ DDN-NEWS:DDN-MGT-BULLETIN-32.TXT ]
3. Harrenstien, K., M. Stahl, and E. Feinler, "Hostname
Server", RFC-953, DDN Network Information Center, SRI
International, October 1985. [ RFC:RFC953.TXT ]
4. Harrenstien, K., M. Stahl, and E. Feinler, "Official DoD
Internet Host Table Specification", RFC-952, DDN Network
Information Center, SRI International, October 1985.
[ RFC:RFC952.TXT ]
5. ISO, "Codes for the Representation of Names of Countries",
ISO-3166, International Standards Organization, May 1981.
[ Not online ]
6. Lazear, W.D., "MILNET Name Domain Transition", RFC-1031,
Mitre Corporation, October 1987. [ RFC:RFC1031.TXT ]
7. Lottor, M.K., "Domain Administrators Operations Guide",
RFC-1033, DDN Network Information Center, SRI International,
July 1987. [ RFC:RFC1033.TXT ]
8. Mockapetris, P., "Domain Names - Concepts and Facilities",
RFC-1034, USC Information Sciences Institute, October 1987.
[ RFC:RFC1034.TXT ]
9. Mockapetris, P., "Domain Names - Implementation and
Specification", RFC-1035, USC Information Sciences Institute,
October 1987. [ RFC:RFC1035.TXT ]
10. Mockapetris, P., "The Domain Name System", Proceedings of the
IFIP 6.5 Working Conference on Computer Message Services,
Nottingham, England, May 1984. Also as ISI/RS-84-133, June
Stahl [Page 8]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
1984. [ Not online ]
11. Mockapetris, P., J. Postel, and P. Kirton, "Name Server
Design for Distributed Systems", Proceedings of the Seventh
International Conference on Computer Communication, October
30 to November 3 1984, Sidney, Australia. Also as
ISI/RS-84-132, June 1984. [ Not online ]
12. Partridge, C., "Mail Routing and the Domain System", RFC-974,
CSNET-CIC, BBN Laboratories, January 1986.
[ RFC:RFC974.TXT ]
13. Postel, J., "The Domain Names Plan and Schedule", RFC-881,
USC Information Sciences Institute, November 1983.
[ RFC:RFC881.TXT ]
14. Reynolds, J., and Postel, J., "Assigned Numbers", RFC-1010
USC Information Sciences Institute, May 1986.
[ RFC:RFC1010.TXT ]
15. Romano, S., and Stahl, M., "Internet Numbers", RFC-1020,
SRI, November 1987.
[ RFC:RFC1020.TXT ]
Stahl [Page 9]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
APPENDIX
The following questionnaire may be FTPed from SRI-NIC.ARPA as
NETINFO:DOMAIN-TEMPLATE.TXT.
---------------------------------------------------------------------
To establish a domain, the following information must be sent to the
NIC Domain Registrar (HOSTMASTER@SRI-NIC.ARPA):
NOTE: The key people must have electronic mailboxes and NIC
"handles," unique NIC database identifiers. If you have access to
"WHOIS", please check to see if you are registered and if so, make
sure the information is current. Include only your handle and any
changes (if any) that need to be made in your entry. If you do not
have access to "WHOIS", please provide all the information indicated
and a NIC handle will be assigned.
(1) The name of the top-level domain to join.
For example: COM
(2) The NIC handle of the administrative head of the organization.
Alternately, the person's name, title, mailing address, phone number,
organization, and network mailbox. This is the contact point for
administrative and policy questions about the domain. In the case of
a research project, this should be the principal investigator.
For example:
Administrator
Organization The NetWorthy Corporation
Name Penelope Q. Sassafrass
Title President
Mail Address The NetWorthy Corporation
4676 Andrews Way, Suite 100
Santa Clara, CA 94302-1212
Phone Number (415) 123-4567
Net Mailbox Sassafrass@ECHO.TNC.COM
NIC Handle PQS
(3) The NIC handle of the technical contact for the domain.
Alternately, the person's name, title, mailing address, phone number,
organization, and network mailbox. This is the contact point for
problems concerning the domain or zone, as well as for updating
information about the domain or zone.
Stahl [Page 10]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
For example:
Technical and Zone Contact
Organization The NetWorthy Corporation
Name Ansel A. Aardvark
Title Executive Director
Mail Address The NetWorthy Corporation
4676 Andrews Way, Suite 100
Santa Clara, CA. 94302-1212
Phone Number (415) 123-6789
Net Mailbox Aardvark@ECHO.TNC.COM
NIC Handle AAA2
(4) The name of the domain (up to 12 characters). This is the name
that will be used in tables and lists associating the domain with the
domain server addresses. [While, from a technical standpoint, domain
names can be quite long (programmers beware), shorter names are
easier for people to cope with.]
For example: TNC
(5) A description of the servers that provide the domain service for
translating names to addresses for hosts in this domain, and the date
they will be operational.
A good way to answer this question is to say "Our server is
supplied by person or company X and does whatever their standard
issue server does."
For example: Our server is a copy of the one operated by
the NIC; it will be installed and made operational on
1 November 1987.
(6) Domains must provide at least two independent servers for the
domain. Establishing the servers in physically separate locations
and on different PSNs is strongly recommended. A description of the
server machine and its backup, including
Stahl [Page 11]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
(a) Hardware and software (using keywords from the Assigned
Numbers RFC).
(b) Host domain name and network addresses (which host on which
network for each connected network).
(c) Any domain-style nicknames (please limit your domain-style
nickname request to one)
For example:
- Hardware and software
VAX-11/750 and UNIX, or
IBM-PC and MS-DOS, or
DEC-1090 and TOPS-20
- Host domain names and network addresses
BAR.FOO.COM 10.9.0.193 on ARPANET
- Domain-style nickname
BR.FOO.COM (same as BAR.FOO.COM 10.9.0.13 on ARPANET)
(7) Planned mapping of names of any other network hosts, other than
the server machines, into the new domain's naming space.
For example:
BAR-FOO2.ARPA (10.8.0.193) -> FOO2.BAR.COM
BAR-FOO3.ARPA (10.7.0.193) -> FOO3.BAR.COM
BAR-FOO4.ARPA (10.6.0.193) -> FOO4.BAR.COM
(8) An estimate of the number of hosts that will be in the domain.
(a) Initially
(b) Within one year
(c) Two years
(d) Five years.
For example:
(a) Initially = 50
(b) One year = 100
(c) Two years = 200
(d) Five years = 500
Stahl [Page 12]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
(9) The date you expect the fully qualified domain name to become
the official host name in HOSTS.TXT.
Please note: If changing to a fully qualified domain name (e.g.,
FOO.BAR.COM) causes a change in the official host name of an
ARPANET or MILNET host, DCA approval must be obtained beforehand.
Allow 10 working days for your requested changes to be processed.
ARPANET sites should contact ARPANETMGR@DDN1.ARPA. MILNET sites
should contact HOSTMASTER@SRI-NIC.ARPA, 800-235-3155, for
further instructions.
(10) Please describe your organization briefly.
For example: The NetWorthy Corporation is a consulting
organization of people working with UNIX and the C language in an
electronic networking environment. It sponsors two technical
conferences annually and distributes a bimonthly newsletter.
---------------------------------------------------------------------
This example of a completed application corresponds to the examples
found in the companion document RFC-1033, "Domain Administrators
Operations Guide."
(1) The name of the top-level domain to join.
COM
(2) The NIC handle of the administrative contact person.
NIC Handle JAKE
(3) The NIC handle of the domain's technical and zone
contact person.
NIC Handle DLE6
(4) The name of the domain.
SRI
(5) A description of the servers.
Our server is the TOPS20 server JEEVES supplied by ISI; it
will be installed and made operational on 1 July 1987.
Stahl [Page 13]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
(6) A description of the server machine and its backup:
(a) Hardware and software
DEC-1090T and TOPS20
DEC-2065 and TOPS20
(b) Host domain name and network address
KL.SRI.COM 10.1.0.2 on ARPANET, 128.18.10.6 on SRINET
STRIPE.SRI.COM 10.4.0.2 on ARPANET, 128.18.10.4 on SRINET
(c) Domain-style nickname
None
(7) Planned mapping of names of any other network hosts, other than
the server machines, into the new domain's naming space.
SRI-Blackjack.ARPA (128.18.2.1) -> Blackjack.SRI.COM
SRI-CSL.ARPA (192.12.33.2) -> CSL.SRI.COM
(8) An estimate of the number of hosts that will be directly within
this domain.
(a) Initially = 50
(b) One year = 100
(c) Two years = 200
(d) Five years = 500
(9) A date when you expect the fully qualified domain name to become
the official host name in HOSTS.TXT.
31 September 1987
(10) Brief description of organization.
SRI International is an independent, nonprofit, scientific
research organization. It performs basic and applied research
for government and commercial clients, and contributes to
worldwide economic, scientific, industrial, and social progress
through research and related services.
Stahl [Page 14]

1229
usr.sbin/named/doc/rfc/rfc1033 Normal file
View File

File diff suppressed because it is too large Load Diff

3077
usr.sbin/named/doc/rfc/rfc1034 Normal file
View File

File diff suppressed because it is too large Load Diff

3077
usr.sbin/named/doc/rfc/rfc1035 Normal file
View File

File diff suppressed because it is too large Load Diff

787
usr.sbin/named/doc/rfc/rfc1101 Normal file
View File

@ -0,0 +1,787 @@
Network Working Group P. Mockapetris
Request for Comments: 1101 ISI
Updates: RFCs 1034, 1035 April 1989
DNS Encoding of Network Names and Other Types
1. STATUS OF THIS MEMO
This RFC proposes two extensions to the Domain Name System:
- A specific method for entering and retrieving RRs which map
between network names and numbers.
- Ideas for a general method for describing mappings between
arbitrary identifiers and numbers.
The method for mapping between network names and addresses is a
proposed standard, the ideas for a general method are experimental.
This RFC assumes that the reader is familiar with the DNS [RFC 1034,
RFC 1035] and its use. The data shown is for pedagogical use and
does not necessarily reflect the real Internet.
Distribution of this memo is unlimited.
2. INTRODUCTION
The DNS is extensible and can be used for a virtually unlimited
number of data types, name spaces, etc. New type definitions are
occasionally necessary as are revisions or deletions of old types
(e.g., MX replacement of MD and MF [RFC 974]), and changes described
in [RFC 973]. This RFC describes changes due to the general need to
map between identifiers and values, and a specific need for network
name support.
Users wish to be able to use the DNS to map between network names and
numbers. This need is the only capability found in HOSTS.TXT which
is not available from the DNS. In designing a method to do this,
there were two major areas of concern:
- Several tradeoffs involving control of network names, the
syntax of network names, backward compatibility, etc.
- A desire to create a method which would be sufficiently
general to set a good precedent for future mappings,
for example, between TCP-port names and numbers,
Mockapetris [Page 1]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
autonomous system names and numbers, X.500 Relative
Distinguished Names (RDNs) and their servers, or whatever.
It was impossible to reconcile these two areas of concern for network
names because of the desire to unify network number support within
existing IP address to host name support. The existing support is
the IN-ADDR.ARPA section of the DNS name space. As a result this RFC
describes one structure for network names which builds on the
existing support for host names, and another family of structures for
future yellow pages (YP) functions such as conversions between TCP-
port numbers and mnemonics.
Both structures are described in following sections. Each structure
has a discussion of design issues and specific structure
recommendations.
We wish to avoid defining structures and methods which can work but
do not because of indifference or errors on the part of system
administrators when maintaining the database. The WKS RR is an
example. Thus, while we favor distribution as a general method, we
also recognize that centrally maintained tables (such as HOSTS.TXT)
are usually more consistent though less maintainable and timely.
Hence we recommend both specific methods for mapping network names,
addresses, and subnets, as well as an instance of the general method
for mapping between allocated network numbers and network names.
(Allocation is centrally performed by the SRI Network Information
Center, aka the NIC).
3. NETWORK NAME ISSUES AND DISCUSSION
The issues involved in the design were the definition of network name
syntax, the mappings to be provided, and possible support for similar
functions at the subnet level.
3.1. Network name syntax
The current syntax for network names, as defined by [RFC 952] is an
alphanumeric string of up to 24 characters, which begins with an
alpha, and may include "." and "-" except as first and last
characters. This is the format which was also used for host names
before the DNS. Upward compatibility with existing names might be a
goal of any new scheme.
However, the present syntax has been used to define a flat name
space, and hence would prohibit the same distributed name allocation
method used for host names. There is some sentiment for allowing the
NIC to continue to allocate and regulate network names, much as it
allocates numbers, but the majority opinion favors local control of
Mockapetris [Page 2]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
network names. Although it would be possible to provide a flat space
or a name space in which, for example, the last label of a domain
name captured the old-style network name, any such approach would add
complexity to the method and create different rules for network names
and host names.
For these reasons, we assume that the syntax of network names will be
the same as the expanded syntax for host names permitted in [HR].
The new syntax expands the set of names to allow leading digits, so
long as the resulting representations do not conflict with IP
addresses in decimal octet form. For example, 3Com.COM and 3M.COM
are now legal, although 26.0.0.73.COM is not. See [HR] for details.
The price is that network names will get as complicated as host
names. An administrator will be able to create network names in any
domain under his control, and also create network number to name
entries in IN-ADDR.ARPA domains under his control. Thus, the name
for the ARPANET might become NET.ARPA, ARPANET.ARPA or Arpa-
network.MIL., depending on the preferences of the owner.
3.2. Mappings
The desired mappings, ranked by priority with most important first,
are:
- Mapping a IP address or network number to a network name.
This mapping is for use in debugging tools and status displays
of various sorts. The conversion from IP address to network
number is well known for class A, B, and C IP addresses, and
involves a simple mask operation. The needs of other classes
are not yet defined and are ignored for the rest of this RFC.
- Mapping a network name to a network address.
This facility is of less obvious application, but a
symmetrical mapping seems desirable.
- Mapping an organization to its network names and numbers.
This facility is useful because it may not always be possible
to guess the local choice for network names, but the
organization name is often well known.
- Similar mappings for subnets, even when nested.
The primary application is to be able to identify all of the
subnets involved in a particular IP address. A secondary
Mockapetris [Page 3]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
requirement is to retrieve address mask information.
3.3. Network address section of the name space
The network name syntax discussed above can provide domain names
which will contain mappings from network names to various quantities,
but we also need a section of the name space, organized by network
and subnet number to hold the inverse mappings.
The choices include:
- The same network number slots already assigned and delegated
in the IN-ADDR.ARPA section of the name space.
For example, 10.IN-ADDR.ARPA for class A net 10,
2.128.IN-ADDR.ARPA for class B net 128.2, etc.
- Host-zero addresses in the IN-ADDR.ARPA tree. (A host field
of all zero in an IP address is prohibited because of
confusion related to broadcast addresses, et al.)
For example, 0.0.0.10.IN-ADDR.ARPA for class A net 10,
0.0.2.128.IN-ADDR.arpa for class B net 128.2, etc. Like the
first scheme, it uses in-place name space delegations to
distribute control.
The main advantage of this scheme over the first is that it
allows convenient names for subnets as well as networks. A
secondary advantage is that it uses names which are not in use
already, and hence it is possible to test whether an
organization has entered this information in its domain
database.
- Some new section of the name space.
While this option provides the most opportunities, it creates
a need to delegate a whole new name space. Since the IP
address space is so closely related to the network number
space, most believe that the overhead of creating such a new
space is overwhelming and would lead to the WKS syndrome. (As
of February, 1989, approximately 400 sections of the
IN-ADDR.ARPA tree are already delegated, usually at network
boundaries.)
Mockapetris [Page 4]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
4. SPECIFICS FOR NETWORK NAME MAPPINGS
The proposed solution uses information stored at:
- Names in the IN-ADDR.ARPA tree that correspond to host-zero IP
addresses. The same method is used for subnets in a nested
fashion. For example, 0.0.0.10.IN-ADDR.ARPA. for net 10.
Two types of information are stored here: PTR RRs which point
to the network name in their data sections, and A RRs, which
are present if the network (or subnet) is subnetted further.
If a type A RR is present, then it has the address mask as its
data. The general form is:
<reversed-host-zero-number>.IN-ADDR.ARPA. PTR <network-name>
<reversed-host-zero-number>.IN-ADDR.ARPA. A <subnet-mask>
For example:
0.0.0.10.IN-ADDR.ARPA. PTR ARPANET.ARPA.
or
0.0.2.128.IN-ADDR.ARPA. PTR cmu-net.cmu.edu.
A 255.255.255.0
In general, this information will be added to an existing
master file for some IN-ADDR.ARPA domain for each network
involved. Similar RRs can be used at host-zero subnet
entries.
- Names which are network names.
The data stored here is PTR RRs pointing at the host-zero
entries. The general form is:
<network-name> ptr <reversed-host-zero-number>.IN-ADDR.ARPA
For example:
ARPANET.ARPA. PTR 0.0.0.10.IN-ADDR.ARPA.
or
isi-net.isi.edu. PTR 0.0.9.128.IN-ADDR.ARPA.
In general, this information will be inserted in the master
file for the domain name of the organization; this is a
Mockapetris [Page 5]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
different file from that which holds the information below
IN-ADDR.ARPA. Similar PTR RRs can be used at subnet names.
- Names corresponding to organizations.
The data here is one or more PTR RRs pointing at the
IN-ADDR.ARPA names corresponding to host-zero entries for
networks.
For example:
ISI.EDU. PTR 0.0.9.128.IN-ADDR.ARPA.
MCC.COM. PTR 0.167.5.192.IN-ADDR.ARPA.
PTR 0.168.5.192.IN-ADDR.ARPA.
PTR 0.169.5.192.IN-ADDR.ARPA.
PTR 0.0.62.128.IN-ADDR.ARPA.
4.1. A simple example
The ARPANET is a Class A network without subnets. The RRs which
would be added, assuming the ARPANET.ARPA was selected as a network
name, would be:
ARPA. PTR 0.0.0.10.IN-ADDR.ARPA.
ARPANET.ARPA. PTR 0.0.0.10.IN-ADDR.ARPA.
0.0.0.10.IN-ADDR.ARPA. PTR ARPANET.ARPA.
The first RR states that the organization named ARPA owns net 10 (It
might also own more network numbers, and these would be represented
with an additional RR per net.) The second states that the network
name ARPANET.ARPA. maps to net 10. The last states that net 10 is
named ARPANET.ARPA.
Note that all of the usual host and corresponding IN-ADDR.ARPA
entries would still be required.
4.2. A complicated, subnetted example
The ISI network is 128.9, a class B number. Suppose the ISI network
was organized into two levels of subnet, with the first level using
an additional 8 bits of address, and the second level using 4 bits,
for address masks of x'FFFFFF00' and X'FFFFFFF0'.
Then the following RRs would be entered in ISI's master file for the
ISI.EDU zone:
Mockapetris [Page 6]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
; Define network entry
isi-net.isi.edu. PTR 0.0.9.128.IN-ADDR.ARPA.
; Define first level subnets
div1-subnet.isi.edu. PTR 0.1.9.128.IN-ADDR.ARPA.
div2-subnet.isi.edu. PTR 0.2.9.128.IN-ADDR.ARPA.
; Define second level subnets
inc-subsubnet.isi.edu. PTR 16.2.9.128.IN-ADDR.ARPA.
in the 9.128.IN-ADDR.ARPA zone:
; Define network number and address mask
0.0.9.128.IN-ADDR.ARPA. PTR isi-net.isi.edu.
A 255.255.255.0 ;aka X'FFFFFF00'
; Define one of the first level subnet numbers and masks
0.1.9.128.IN-ADDR.ARPA. PTR div1-subnet.isi.edu.
A 255.255.255.240 ;aka X'FFFFFFF0'
; Define another first level subnet number and mask
0.2.9.128.IN-ADDR.ARPA. PTR div2-subnet.isi.edu.
A 255.255.255.240 ;aka X'FFFFFFF0'
; Define second level subnet number
16.2.9.128.IN-ADDR.ARPA. PTR inc-subsubnet.isi.edu.
This assumes that the ISI network is named isi-net.isi.edu., first
level subnets are named div1-subnet.isi.edu. and div2-
subnet.isi.edu., and a second level subnet is called inc-
subsubnet.isi.edu. (In a real system as complicated as this there
would be more first and second level subnets defined, but we have
shown enough to illustrate the ideas.)
4.3. Procedure for using an IP address to get network name
Depending on whether the IP address is class A, B, or C, mask off the
high one, two, or three bytes, respectively. Reverse the octets,
suffix IN-ADDR.ARPA, and do a PTR query.
For example, suppose the IP address is 10.0.0.51.
1. Since this is a class A address, use a mask x'FF000000' and
get 10.0.0.0.
2. Construct the name 0.0.0.10.IN-ADDR.ARPA.
3. Do a PTR query. Get back
Mockapetris [Page 7]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
0.0.0.10.IN-ADDR.ARPA. PTR ARPANET.ARPA.
4. Conclude that the network name is "ARPANET.ARPA."
Suppose that the IP address is 128.9.2.17.
1. Since this is a class B address, use a mask of x'FFFF0000'
and get 128.9.0.0.
2. Construct the name 0.0.9.128.IN-ADDR.ARPA.
3. Do a PTR query. Get back
0.0.9.128.IN-ADDR.ARPA. PTR isi-net.isi.edu
4. Conclude that the network name is "isi-net.isi.edu."
4.4. Procedure for finding all subnets involved with an IP address
This is a simple extension of the IP address to network name method.
When the network entry is located, do a lookup for a possible A RR.
If the A RR is found, look up the next level of subnet using the
original IP address and the mask in the A RR. Repeat this procedure
until no A RR is found.
For example, repeating the use of 128.9.2.17.
1. As before construct a query for 0.0.9.128.IN-ADDR.ARPA.
Retrieve:
0.0.9.128.IN-ADDR.ARPA. PTR isi-net.isi.edu.
A 255.255.255.0
2. Since an A RR was found, repeat using mask from RR
(255.255.255.0), constructing a query for
0.2.9.128.IN-ADDR.ARPA. Retrieve:
0.2.9.128.IN-ADDR.ARPA. PTR div2-subnet.isi.edu.
A 255.255.255.240
3. Since another A RR was found, repeat using mask
255.255.255.240 (x'FFFFFFF0'). constructing a query for
16.2.9.128.IN-ADDR.ARPA. Retrieve:
16.2.9.128.IN-ADDR.ARPA. PTR inc-subsubnet.isi.edu.
4. Since no A RR is present at 16.2.9.128.IN-ADDR.ARPA., there
are no more subnet levels.
Mockapetris [Page 8]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
5. YP ISSUES AND DISCUSSION
The term "Yellow Pages" is used in almost as many ways as the term
"domain", so it is useful to define what is meant herein by YP. The
general problem to be solved is to create a method for creating
mappings from one kind of identifier to another, often with an
inverse capability. The traditional methods are to search or use a
precomputed index of some kind.
Searching is impractical when the search is too large, and
precomputed indexes are possible only when it is possible to specify
search criteria in advance, and pay for the resources necessary to
build the index. For example, it is impractical to search the entire
domain tree to find a particular address RR, so we build the IN-
ADDR.ARPA YP. Similarly, we could never build an Internet-wide index
of "hosts with a load average of less than 2" in less time than it
would take for the data to change, so indexes are a useless approach
for that problem.
Such a precomputed index is what we mean by YP, and we regard the
IN-ADDR.ARPA domain as the first instance of a YP in the DNS.
Although a single, centrally-managed YP for well-known values such as
TCP-port is desirable, we regard organization-specific YPs for, say,
locally defined TCP ports as a natural extension, as are combinations
of YPs using search lists to merge the two.
In examining Internet Numbers [RFC 997] and Assigned Numbers [RFC
1010], it is clear that there are several mappings which might be of
value. For example:
<assigned-network-name> <==> <IP-address>
<autonomous-system-id> <==> <number>
<protocol-id> <==> <number>
<port-id> <==> <number>
<ethernet-type> <==> <number>
<public-data-net> <==> <IP-address>
Following the IN-ADDR example, the YP takes the form of a domain tree
organized to optimize retrieval by search key and distribution via
normal DNS rules. The name used as a key must include:
1. A well known origin. For example, IN-ADDR.ARPA is the
current IP-address to host name YP.
2. A "from" data type. This identifies the input type of the
mapping. This is necessary because we may be mapping
something as anonymous as a number to any number of
mnemonics, etc.
Mockapetris [Page 9]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
3. A "to" data type. Since we assume several symmetrical
mnemonic <==> number mappings, this is also necessary.
This ordering reflects the natural scoping of control, and hence the
order of the components in a domain name. Thus domain names would be
of the form:
<from-value>.<to-data-type>.<from-data-type>.<YP-origin>
To make this work, we need to define well-know strings for each of
these metavariables, as well as encoding rules for converting a
<from-value> into a domain name. We might define:
<YP-origin> :=YP
<from-data-type>:=TCP-port | IN-ADDR | Number |
Assigned-network-number | Name
<to-data-type> :=<from-data-type>
Note that "YP" is NOT a valid country code under [ISO 3166] (although
we may want to worry about the future), and the existence of a
syntactically valid <to-data-type>.<from-data-type> pair does not
imply that a meaningful mapping exists, or is even possible.
The encoding rules might be:
TCP-port Six character alphanumeric
IN-ADDR Reversed 4-octet decimal string
Number decimal integer
Assigned-network-number
Reversed 4-octet decimal string
Name Domain name
6. SPECIFICS FOR YP MAPPINGS
6.1. TCP-PORT
$origin Number.TCP-port.YP.
23 PTR TELNET.TCP-port.Number.YP.
25 PTR SMTP.TCP-port.Number.YP.
$origin TCP-port.Number.YP.
TELNET PTR 23.Number.TCP-port.YP.
Mockapetris [Page 10]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
SMTP PTR 25.Number.TCP-port.YP.
Thus the mapping between 23 and TELNET is represented by a pair of
PTR RRs, one for each direction of the mapping.
6.2. Assigned networks
Network numbers are assigned by the NIC and reported in "Internet
Numbers" RFCs. To create a YP, the NIC would set up two domains:
Name.Assigned-network-number.YP and Assigned-network-number.YP
The first would contain entries of the form:
$origin Name.Assigned-network-number.YP.
0.0.0.4 PTR SATNET.Assigned-network-number.Name.YP.
0.0.0.10 PTR ARPANET.Assigned-network-number.Name.YP.
The second would contain entries of the form:
$origin Assigned-network-number.Name.YP.
SATNET. PTR 0.0.0.4.Name.Assigned-network-number.YP.
ARPANET. PTR 0.0.0.10.Name.Assigned-network-number.YP.
These YPs are not in conflict with the network name support described
in the first half of this RFC since they map between ASSIGNED network
names and numbers, not those allocated by the organizations
themselves. That is, they document the NIC's decisions about
allocating network numbers but do not automatically track any
renaming performed by the new owners.
As a practical matter, we might want to create both of these domains
to enable users on the Internet to experiment with centrally
maintained support as well as the distributed version, or might want
to implement only the allocated number to name mapping and request
organizations to convert their allocated network names to the network
names described in the distributed model.
6.3. Operational improvements
We could imagine that all conversion routines using these YPs might
be instructed to use "YP.<local-domain>" followed by "YP." as a
search list. Thus, if the organization ISI.EDU wished to define
locally meaningful TCP-PORT, it would define the domains:
<TCP-port.Number.YP.ISI.EDU> and <Number.TCP-port.YP.ISI.EDU>.
Mockapetris [Page 11]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
We could add another level of indirection in the YP lookup, defining
the <to-data-type>.<from-data-type>.<YP-origin> nodes to point to the
YP tree, rather than being the YP tree directly. This would enable
entries of the form:
IN-ADDR.Netname.YP. PTR IN-ADDR.ARPA.
to splice in YPs from other origins or existing spaces.
Another possibility would be to shorten the RDATA section of the RRs
which map back and forth by deleting the origin. This could be done
either by allowing the domain name in the RDATA portion to not
identify a real domain name, or by defining a new RR which used a
simple text string rather than a domain name.
Thus, we might replace
$origin Assigned-network-number.Name.YP.
SATNET. PTR 0.0.0.4.Name.Assigned-network-number.YP.
ARPANET. PTR 0.0.0.10.Name.Assigned-network-number.YP.
with
$origin Assigned-network-number.Name.YP.
SATNET. PTR 0.0.0.4.
ARPANET. PTR 0.0.0.10.
or
$origin Assigned-network-number.Name.YP.
SATNET. PTT "0.0.0.4"
ARPANET. PTT "0.0.0.10"
where PTT is a new type whose RDATA section is a text string.
7. ACKNOWLEDGMENTS
Drew Perkins, Mark Lottor, and Rob Austein contributed several of the
ideas in this RFC. Numerous contributions, criticisms, and
compromises were produced in the IETF Domain working group and the
NAMEDROPPERS mailing list.
Mockapetris [Page 12]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
8. REFERENCES
[HR] Braden, B., editor, "Requirements for Internet Hosts",
RFC in preparation.
[ISO 3166] ISO, "Codes for the Representation of Names of
Countries", 1981.
[RFC 882] Mockapetris, P., "Domain names - Concepts and
Facilities", RFC 882, USC/Information Sciences Institute,
November 1983.
Superseded by RFC 1034.
[RFC 883] Mockapetris, P.,"Domain names - Implementation and
Specification", RFC 883, USC/Information Sciences
Institute, November 1983.
Superceeded by RFC 1035.
[RFC 920] Postel, J. and J. Reynolds, "Domain Requirements", RFC
920, October 1984.
Explains the naming scheme for top level domains.
[RFC 952] Harrenstien, K., M. Stahl, and E. Feinler, "DoD Internet
Host Table Specification", RFC 952, SRI, October 1985.
Specifies the format of HOSTS.TXT, the host/address table
replaced by the DNS
[RFC 973] Mockapetris, P., "Domain System Changes and
Observations", RFC 973, USC/Information Sciences
Institute, January 1986.
Describes changes to RFCs 882 and 883 and reasons for
them.
[RFC 974] Partridge, C., "Mail routing and the domain system", RFC
974, CSNET CIC BBN Labs, January 1986.
Describes the transition from HOSTS.TXT based mail
addressing to the more powerful MX system used with the
domain system.
Mockapetris [Page 13]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
[RFC 997] Reynolds, J., and J. Postel, "Internet Numbers", RFC 997,
USC/Information Sciences Institute, March 1987
Contains network numbers, autonomous system numbers, etc.
[RFC 1010] Reynolds, J., and J. Postel, "Assigned Numbers", RFC
1010, USC/Information Sciences Institute, May 1987
Contains socket numbers and mnemonics for host names,
operating systems, etc.
[RFC 1034] Mockapetris, P., "Domain names - Concepts and
Facilities", RFC 1034, USC/Information Sciences
Institute, November 1987.
Introduction/overview of the DNS.
[RFC 1035] Mockapetris, P., "Domain names - Implementation and
Specification", RFC 1035, USC/Information Sciences
Institute, November 1987.
DNS implementation instructions.
Author's Address:
Paul Mockapetris
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: (213) 822-1511
Email: PVM@ISI.EDU
Mockapetris [Page 14]

6844
usr.sbin/named/doc/rfc/rfc1122 Normal file
View File

File diff suppressed because it is too large Load Diff

5782
usr.sbin/named/doc/rfc/rfc1123 Normal file
View File

File diff suppressed because it is too large Load Diff

Some files were not shown because too many files have changed in this diff Show More