updated bind docs

36 files changed, 50729 insertions, 0 deletions

diff --git a/usr.sbin/named/doc/misc/FAQ.2of2 b/usr.sbin/named/doc/misc/FAQ.2of2
new file mode 100644
index 00000000000..40e16494b5b
--- /dev/null
+++ b/usr.sbin/named/doc/misc/FAQ.2of2
@@ -0,0 +1,1298 @@
+Newsgroups: comp.protocols.tcp-ip.domains,comp.answers,news.answers
+Path: vixie!news1.digital.com!su-news-hub1.bbnplanet.com!news.bbnplanet.com!cam-news-hub1.bbnplanet.com!news.mathworks.com!news.kei.com!uhog.mit.edu!rutgers!njitgw.njit.edu!hertz.njit.edu!cdp2582
+From: cdp2582@hertz.njit.edu (Chris Peckham)
+Subject: comp.protocols.tcp-ip.domains Frequently Asked Questions (FAQ) (Part 2 of 2)
+Message-ID: <cptd-faq-2-849940949@njit.edu>
+Followup-To: comp.protocols.tcp-ip.domains
+Originator: cdp2582@hertz.njit.edu
+Keywords: BIND,DOMAIN,DNS
+Sender: news@njit.edu
+Supersedes: <cptd-faq-2-847336183@njit.edu>
+Nntp-Posting-Host: hertz.njit.edu
+X-Posting-Frequency: posted during the first week of each month
+Reply-To: domain-faq@njit.edu (comp.protocols.tcp-ip.domains FAQ comments)
+Organization: NJIT.EDU - New Jersey Institute of Technology, Newark, NJ, USA
+References: <cptd-faq-1-849940949@njit.edu> 
+Date: Sat, 7 Dec 1996 06:42:49 GMT
+Approved: news-answers-request@MIT.EDU
+Expires: Sat 11 Jan 97 02:42:29 EDT
+Lines: 1277
+Xref: vixie comp.protocols.tcp-ip.domains:12905 comp.answers:22441 news.answers:85683
+
+Posted-By: auto-faq 3.1.1.2
+Archive-name: internet/tcp-ip/domains-faq/part2
+Revision: 1.13 1996/12/07 06:42:15
+
+
+(Continued from Part 1, where you'll find the introduction and 
+table of contents.)
+
+
+===============================================================================
+
+Section 5.  CONFIGURATION
+
+ Q5.1        Changing a Secondary server to a Primary server ?
+ Q5.2        Moving a Primary server to another server
+ Q5.3        How do I subnet a Class B Address ?
+ Q5.4        Subnetted domain name service
+ Q5.5        Recommended format/style of DNS files
+ Q5.6        DNS on a system not connected to the Internet
+ Q5.7        Multiple Domain configuration
+ Q5.8        wildcard MX records
+ Q5.9        How do you identify a wildcard MX record ?
+ Q5.10       Why are fully qualified domain names recommended ?
+ Q5.11       Distributing load using named
+ Q5.12       Order of returned records
+ Q5.13       resolv.conf
+ Q5.14       How do I delegate authority for sub-domains ?
+ Q5.15       DNS instead of NIS on a Sun OS 4.1.x system
+ Q5.16       Patches to add functionality to BIND 
+ Q5.17       How to serve multiple domains from one server
+
+-----------------------------------------------------------------------------
+
+Question 5.1.  Changing a Secondary server to a Primary server ?
+
+Date: Fri Jul  5 23:54:35 EDT 1996
+
+For 4.8.3,  it's prudent to kill and restart following any changes to
+named.boot.
+
+In BIND 4.9.3, you only have to kill and restart named if you change a
+primary zone to a secondary or v-v, or if you delete a zone and remain
+authoritative for its parent.  Every other case should be taken care of by
+a HUP.  (Ed. note: 4.9.3b9 may still require you to kill and restart the
+server due to some bugs in the HUP code).
+
+You will also need to update the server information on the root servers.
+You can do this by filing a new domain registration form to inform
+InterNIC of the change.  They will then update the root server's SOA
+records.  This process usually takes 10-12 business days after they
+receive the request.
+
+-----------------------------------------------------------------------------
+
+Question 5.2.  Moving a Primary server to another server
+
+Date: Fri Jul  5 23:54:35 EDT 1996
+
+The usual solution is to move the primary to ns.newserver.com, and have
+ns.oldserver.com be configured as a secondary server until the change  to
+the root servers takes place after the request has been made to the
+InterNIC.
+
+If you are moving to a different ISP which will change your IP's, the
+recommened setting for the SOA that would minimize problems for your name
+servers using the old settings can be done as follows:
+
+Gradually lower the TTL value in your SOA (that's the last one of the five
+numbers) to always be equal to the time left until you change over.
+(assuming that none of your resource records have individual TTL's set, if
+so, do likewise witht them.)  So, the day before, lower  to 43200 seconds
+(12 hours).  Then lower every few hours to be the time  remaining until
+the change-over.  So, an hour before the change, you may  just want to
+lower it all the way to 60 seconds or so.  That way no one  can cache
+information past the change-over.
+
+After the change, start gradually incrementing the TTL value, because
+you'll probably be making changes to work out problems.  Once everything
+stabilizes, move the TTL up to whatever your normal values are.
+
+To minimize name servers from using the "old settings", you can do the
+same thing with the "refresh" interval in the SOA (the second number of
+the SOA).  That will tell the secondaries to refresh every X seconds.
+Lower that value as you approach the changeover date.  You probably don't
+want to go much below an hour or you'll start the primary thrashing as all
+the secondaries perpetually refresh.
+
+Also see the answer to the "How can I change the IP address of our server
+?" in the INTRODUCTION section.
+
+-----------------------------------------------------------------------------
+
+Question 5.3.  How do I subnet a Class B Address ?
+
+Date: Fri Apr 28 13:34:52 EDT 1995
+
+That you need to subnet at all is something of a misconception.  You can
+also think of a class B network as giving you 65,534 individual hosts, and
+such a network will work. You can also configure your class B as 16,384
+networks of 2 hosts each.  That's obviously not very practical, but it
+needs to be made clear that you are not constrained by the size of an
+octet (remember that many older devices would not work in a network
+configured in this manner).
+
+So, the question is: why do you need to subnet?   One reason is that it is
+easier to manage a subnetted network, and in fact, you can delegate the
+responsibility for address space management to local administrators on the
+various subnets.  Also, IP based problems will end up localized rather
+than affecting your entire network.
+
+If your network is a large backbone with numerous segments individually
+branching off the backbone, that too suggests subnetting.
+
+Subnetting can also be used to improve routing conditions.
+
+You may wish to partition your network to disallow certain protocols  on
+certain segments of your net.  You can, for example, restrict IP or IPX to
+certain segments only by adding a router routing high level  protocols,
+and across the router you may have to subnet.
+
+Finally, as far as how many subnets you need depends on the answer to the
+above question.  As far as subnet masks are concerned, the mask can be
+anything from 255.0.0.0 to 255.255.255.252.  You'll probably be looking at
+9 or 10 bits for the subnet (last octet 128 or 192 respectively).  RFC
+1219 discusses the issue of subnetting very well  and leaves the network
+administrator with a large amount of flexibility for future growth.
+
+-----------------------------------------------------------------------------
+
+Question 5.4.  Subnetted domain name service
+
+Date: Mon Aug  5 23:00:16 EDT 1996
+
+If you are looking for some examples of handling subnetted class C
+networks as separate DNS domains, see the Internet Draft
+
+draft-ietf-cidrd-classless-inaddr-02.txt
+
+for more information.   This file is available for anonymous ftp at
+
+ds.internic.net :
+/internet-drafts/draft-ietf-cidrd-classless-inaddr-02.txt
+
+or other IETF mirror sites (ftp.is.ca.za [Africa], nic.nordu.net [Europe],
+munnari.oz.au [Pacific Rim], ds.internic.net [US East Coast], or
+ftp.isi.edu [US West Coast]).
+
+Details follow- You need to delegate down to the fourth octet, so you will
+have one domain per IP address !  Here is how you can subdelegate a
+in-addr.arpa address for non-byte aligned subnet masks:
+
+Take as an example the net 192.1.1.x, and example subnet mask
+255.255.255.240.
+
+We first define the domain for the class C net,
+
+   $origin  1.1.192.in-addr.arpa
+   @       SOA   (usual stuff)
+   @       ns  some.nameserver
+           ns  some.other.nameserver
+   ; delegate a subdomain
+   one     ns  one.nameserver
+           ns  some.nameserver
+   ; delegate another
+   two     ns  two.nameserver
+           ns  some.nameserver
+   ; CNAME pointers to subdomain one
+   0       CNAME 0.one
+   1       CNAME 1.one
+   ;    through
+   15      CNAME 15.one
+   ; CNAME pointers to subdomain two
+   16      CNAME 16.two
+   17      CNAME 17.two
+   31      CNAME 31.two
+   ; CNAME as many as required.
+
+Now, in the delegated nameserver, one.nameserver
+
+   $origin one.1.1.192.in-addr.arpa
+   @       SOA (usual stuff)
+           NS  one.nameserver
+           NS  some.nameserver   ;  secondary for us
+   0       PTR  onenet.one.domain
+   1       PTR  onehost.one.domain
+   ;   through
+   15      PTR  lasthost.one.domain
+
+And similar for the two.1.1.192.in-addr.arpa delegated domain.
+
+There is additional documentation and a perl script that may be used for
+this purpose available for anonymous ftp from:
+
+ftp.vix.com : /pub/bind/contrib/gencidrzone
+
+-----------------------------------------------------------------------------
+
+Question 5.5.  Recommended format/style of DNS files
+
+Date: Sun Nov 27 23:32:41 EST 1994
+
+This answer is quoted from an article posted by Paul Vixie:
+
+   I've gone back and forth on the question of whether the BOG should
+   include a section on this topic.  I know what I myself prefer, but
+   I'm wary of ramming my own stylistic preferences down the throat of
+   every BOG reader.  But since you ask :-)...
+ 
+   Create /var/named.  If your system is too old to have a /var, either
+   create one or use /usr/local/adm/named instead.  Put your named.boot
+   in it, and make /etc/named.boot a symlink to it.  If your system
+   doesn't have symlinks, you're S-O-L (but you knew that).  In
+   named.boot, put a "directory" directive that specifies your actual
+   BIND working directory:
+ 
+        directory       /var/named
+ 
+   All relative pathnames used in "primary", "secondary", and "cache"
+   directives will be evaluated relative to this directory.  Create two
+   subdirectories, /var/named/pri and /var/named/sec.  Whenever you add
+   a "primary" directive to your named.boot, use "pri/WHATEVER" as the
+   path name.  And then put the primary zone file into "pri/WHATEVER".
+   Likewise when you add "secondary" directives, use "sec/WHATEVER" and
+   BIND (really named-xfer) will create the files in that
+   subdirectory.
+ 
+   (Variations: (1) make a midlevel directory "zones" and put "pri" and
+   "sec" into it; (2) if you tend to pick up a lot of secondaries from
+   a few hosts, group them together in their own subdirectories --
+   something like /var/named/zones/uucp if you're a UUCP Project name
+   server.)
+ 
+   For your forward files, name them after the zone.  dec.com becomes
+   "/var/named/zones/pri/dec.com".  For your reverse files, name them
+   after the network number.  0.1.16.in-addr.arpa becomes
+   "/var/named/zones/pri/16.1.0".
+
+   When creating or maintaining primary zone files, try to use the same
+   SOA values everywhere, except for the serial number which varies per
+   zone.  Put a $ORIGIN directive at the top of the primary zone file,
+   not because its needed (it's not since the default origin is the
+   zone named in the "primary" directive) but because it make it easier
+   to remember what you're working on when you have a lot of primary
+   zones.  Put some comments up there indicating contact information
+   for the real owner if you're proxying.  Use RCS and put the "Id"
+   in a ";" comment near the top of the zone file.
+ 
+   The SOA and other top level information should all be listed
+   together.  But don't put IN on every line, it defaults nicely.  For
+   example:
+ 
+==============
+@       IN      SOA     gw.home.vix.com. postmaster.vix.com. (
+                        1994082501      ; serial
+                        3600    ; refresh (1 hour)
+                        1800    ; retry (30 mins)
+                        604800  ; expire (7 days)
+                        3600 )  ; minimum (1 hour)
+ 
+                NS      gw.home.vix.com.
+                NS      ns.uu.net.
+                NS      uucp-gw-1.pa.dec.com.
+                NS      uucp-gw-2.pa.dec.com.
+ 
+                MX      10 gw.home.vix.com.
+                MX      20 uucp-gw-1.pa.dec.com.
+                MX      20 uucp-gw-1.pa.dec.com.
+==============
+ 
+   I don't necessarily recommend those SOA values.  Not every zone is
+   as volatile as the example shown.  I do recommend that serial number
+   format; it's in date format with a 2-digit per-day revision number.
+   This format will last us until 2147 A.D. at which point I expect a
+   better solution will have been found :-).  (Note that it would last
+   until 4294 A.D. except that there are some old BINDs out there that
+   use a signed quantity for representing serial number interally; I
+   suppose that as long as none of these are still running after 2047
+   A.D., that we can use the above serial number format until 4294
+   A.D., at which point a better solution will HAVE to be found.)
+ 
+   You'll note that I use a tab stop for "IN" even though I never again
+   specify it.  This leaves room for names longer than 7 bytes without
+   messing up the columns.  You might also note that I've put the MX
+   priority and destination in the same tab stop; this is because both
+   are part of the RRdata and both are very different from MX which is
+   an RRtype.  Some folks seem to prefer to group "MX" and the priority
+   together in one tab stop.  While this looks neat it's very confusing
+   to newcomers and for them it violates the law of least
+   astonishment.
+ 
+   If you have a multi-level zone (one which contains names that have
+   dots in them), you can use additional $ORIGIN statements but I
+   recommend against it since there is no "back" operator.  That is,
+   given the above example you can add:
+ 
+=============
+$ORIGIN home
+gw              A       192.5.5.1
+=============
+ 
+   The problem with this is that subsequent RR's had better be
+   somewhere under the "home.vix.com" name or else the $ORIGIN that
+   introduces them will have to use a fully qualified name.  FQDN
+   $ORIGIN's aren't bad and I won't be mad if you use them.
+   Unqualified ones as shown above are real trouble.  I usually stay
+   away from them and just put the whole name in:
+ 
+=============
+gw.home         A       192.5.5.1
+=============
+ 
+   In your reverse zones, you're usually in some good luck because the
+   owner name is usually a single short token or sometimes two.
+ 
+=============
+$ORIGIN 5.5.192.in-addr.arpa.
+@       IN      SOA     ...
+                NS      ...
+1               PTR     gw.home.vix.com.
+=========================================
+$ORIGIN 1.16.in-addr.arpa.
+@       IN      SOA     ...
+                NS      ...
+2.0             PTR     gatekeeper.dec.com.
+=============
+
+   It is usually pretty hard to keep your forward and reverse zones in
+   synch.  You can avoid that whole problem by just using "h2n" (see
+   the ORA book, DNS and BIND, and its sample toolkit, included in the
+   BIND distribution or on ftp.uu.net (use the QUOTE SITE EXEC INDEX
+   command there to find this -- I never can remember where it's at).
+   "h2n" and many tools like it can just read your old /etc/hosts file
+   and churn it into DNS zone files.  (May I recommend
+   contrib/decwrl/mkdb.pl from the BIND distribution?)  However, if you
+   (like me) prefer to edit these things by hand, you need to follow
+   the simple convention of making all of your holes consistent.  If
+   you use 192.5.5.1 and 192.5.5.3 but not (yet) 192.5.5.2, then in
+   your forward file you will have something like
+ 
+=============
+...
+gw.home         A       192.5.5.1
+;avail          A       192.5.5.2
+pc.home         A       192.5.5.3
+=============
+ 
+   and in your reverse file you will have something like
+ 
+=============
+...
+1               PTR     gw.home.vix.com.
+;2              PTR     avail
+3               PTR     pc.home.vix.com.
+=============
+ 
+   This convention will allow you to keep your sanity and make fewer
+   errors.  Any kind of automation (h2n, mkdb, or your own
+   perl/tcl/awk/python tools) will help you maintain a consistent
+   universe even if it's also a complex one.  Editing by hand doesn't
+   have to be deadly but you MUST take care.
+
+-----------------------------------------------------------------------------
+
+Question 5.6.  DNS on a system not connected to the Internet
+
+Date: Sun Nov 27 23:32:41 EST 1994
+
+You need to create your own root domain name server until you connect  to
+the internet.  Your roots need to delegate to mydomain.com and any
+in-addr.arpa subdomains you might have, and that's about it.  As soon as
+you're connected, rip out the fake roots and use the real ones.
+
+It does not actually have to be another server pretending to be the root.
+You can set up the name server so that it is primary for each domain above
+you and leave them empty (i.e. you are foo.bar.com - claim to be primary
+for bar.com and com)
+
+If you connect intermittently and want DNS to work when you are connected,
+and "fail" when you are not, you can point the resolver at the name server
+at the remote site and if the connection (SLIP/PPP) isn't up, the resolver
+doesn't have a route to the remote server and since there's only one name
+server in resolv.conf, the resolver quickly backs off the using
+/etc/hosts.  No problem.  You could do the same with multiple name server
+and a resolver that did configurable /etc/hosts fallback.
+
+-----------------------------------------------------------------------------
+
+Question 5.7.  Multiple Domain configuration
+
+Date: Fri Dec  2 15:40:49 EST 1994
+
+If you want to have multiple domain names pointing to the same
+destination, such as:
+
+      ftp ftp.biff.com connects user to -> ftp.biff.com
+      ftp ftp.fred.com connects user to -> ftp.biff.com
+      ftp ftp.bowser.com connects user to -> ftp.biff.com
+
+You may do this by using CNAMEs:
+
+      ftp.bowser.com.         IN      CNAME ftp.biff.com.
+
+You can also do the same thing with multiple A records.
+
+-----------------------------------------------------------------------------
+
+Question 5.8.  wildcard MX records
+
+Date: Sun Nov 27 23:32:41 EST 1994
+
+Does BIND not understand wildcard MX records such as the following?
+
+     *.foo.com       MX      0       mail.foo.com.
+
+No. It just doesn't work.
+
+Explicit RR's at one level of specificity will, by design, "block" a
+wildcard at a lesser level of specificity. I suspect that you have an RR
+(an A RR, perhaps?) for "bar.foo.com" which is blocking the application of
+your "*.foo.com" wildcard. The initial MX query is thus failing (NOERROR
+but an answer count of 0), and the backup query finds the A RR for
+"bar.foo.com" and uses it to deliver the mail directly (which is what you
+DIDN'T want it to do).  Adding an explicit MX RR for the host is therefore
+the right way to handle this situation.
+
+See RFC 1034, Section 4.3.3 ("Wildcards") for more information on this
+"blocking" behavior, along with an illustrative example. See also RFC 974
+for an explanation of standard mailer behavior in the face of an "empty"
+response to one's MX query.
+
+Basically, what it boils down to is, there is no point in trying to use a
+wildcard MX for a host which is otherwise listed in the DNS.
+
+It just doesn't work.
+
+-----------------------------------------------------------------------------
+
+Question 5.9.  How do you identify a wildcard MX record ?
+
+Date: Thu Dec  1 11:10:39 EST 1994
+
+You don't really need to "identify" a wildcard MX RR.  The precedence  for
+u@dom is:
+
+        exact match MX
+        exact match A
+        wildcard MX
+
+One way to implement this is to query for ("dom",IN,MX) and if the answer
+name that comes back is "*." something, you know it's a wildcard,
+therefore you know there is no exact match MX, and you therefore query for
+("dom",IN,A) and if you get something, use it.  if you don't, use the
+previous wildcard response.
+
+RFC 974 explains this pretty well.
+
+-----------------------------------------------------------------------------
+
+Question 5.10.  Why are fully qualified domain names recommended ?
+
+Date: Sun Nov 27 23:32:41 EST 1994
+
+The documentation for BIND 4.9.2 says that the hostname should be set  to
+the full domain style name (i.e host.our.domain rather than host).  What
+advantages are there in this, and are there any adverse consequences if we
+don't?
+
+Paul Vixie likes to do it :-)  He lists a few reasons -
+
+* Sendmail can be configured to just use Dj$w rather than Dj$w.mumble
+  where "mumble" is something you have to edit in by hand.  Granted, most
+  people use "mumble" elsewhere in their config files ("tack on local
+  domain", etc) but why should it be a requirement ?
+* The real reason is that not doing it violates a very useful invariant:
+    gethostbyname(gethostname) == gethostbyaddr(primary_interface_address)
+
+  If you take an address and go "backwards" through the PTR's with it,
+  you'll get a FQDN, and if you push that back through the A RR's, you get
+  the same address.  Or you should.  Many multi-homed hosts violate this
+  uncaringly.
+
+  If you take a non-FQDN hostname and push it "forwards" through the A
+  RR's, you get an address which, if you push it through the PTR's, comes
+  back as a FQDN which is not the same as the hostname you started with.
+  Consider the fact that, absent NIS/YP, there is no "domainname" command
+  analogous to the "hostname" command.  (NIS/YP's doesn't count, of
+  course, since it's sometimes-but-only-rarely the same as the Internet
+  domain or subdomain above a given host's name.)  The "domain" keyword in
+  resolv.conf doesn't specify the parent domain of the current host; it
+  specifies the default domain of queries initiated on the current host,
+  which can be a very different thing.  (As of RFC 1535 and BIND 4.9.2's
+  compliance with it, most people use "search" in resolv.conf, which
+  overrides "domain", anyway.)
+
+  What this means is that there is NO authoritative way to
+  programmatically discover your host's FQDN unless it is set in the
+  hostname, or unless every application is willing to grovel the "netstat
+  -in" tables, find what it hopes is the primary address, and do a PTR
+  query on it.
+
+  FQDN /bin/hostnames are, intuitively or not, the simplest way to go.
+
+-----------------------------------------------------------------------------
+
+Question 5.11.  Distributing load using named
+
+Date: Wed Mar  1 11:04:43 EST 1995
+
+When you attempt to distribute the load on a system using named, the first
+response be cached, and then later queries use the cached value (This
+would be for requests that come through the same server).  Therefore, it
+can be useful to use a lower TTL on records where this is important.  You
+can use values like 300 or 500 seconds.
+
+If your local caching server has ROUND_ROBIN, it does not matter what the
+authoritative servers have -- every response from the cache is rotated.
+
+But if it doesn't, and the authoritative server site is depending on this
+feature (or the old "shuffle-A") to do load balancing, then if one doesn't
+use small TTLs, one could conceivably end up with a really nasty
+situation, e.g., hundreds of workstations at a branch campus pounding on
+the same front end at the authoritative server's site during class
+registration.
+
+Not nice.
+
+Paul Vixie has an example of the ROUND_ROBIN code in action.  Here is
+something that he wrote regarding his example:
+
+     >I want users to be distributed evenly among those 3 hosts.
+
+     Believe it or not :-), BIND offers an ugly way to do this.  I offer
+     for your collective amusement the following snippet from the
+     ugly.vix.com zone file:
+
+       hydra           cname        hydra1
+                       cname        hydra2
+                       cname        hydra3
+       hydra1          a            10.1.0.1
+                       a            10.1.0.2
+                       a            10.1.0.3
+       hydra2          a            10.2.0.1
+                       a            10.2.0.2
+                       a            10.2.0.3
+       hydra3          a            10.3.0.1
+                       a            10.3.0.2
+                       a            10.3.0.3
+       
+      Note that having multiple CNAME RR's at a given name is
+      meaningless according to the DNS RFCs but BIND doesn't mind (in
+      fact it doesn't even complain).  If you call
+      gethostbyname("hydra.ugly.vix.com") (try it!) you will get
+      results like the following.  Note that there are two round robin
+      rotations going on: one at ("hydra",CNAME) and one at each
+      ("hydra1",A) et al.  I used a layer of CNAME's above the layer of
+      A's to keep the response size down.  If you don't have nine
+      addresses you probably don't care and would just use a pile of
+      CNAME's pointing directly at real host names.
+
+      {hydra.ugly.vix.com
+      name: hydra2.ugly.vix.com
+      aliases: hydra.ugly.vix.com
+      addresses: 10.2.0.2 10.2.0.3 10.2.0.1
+
+      {hydra.ugly.vix.com
+      name: hydra3.ugly.vix.com
+      aliases: hydra.ugly.vix.com
+      addresses: 10.3.0.2 10.3.0.3 10.3.0.1
+
+      {hydra.ugly.vix.com
+      name: hydra1.ugly.vix.com
+      aliases: hydra.ugly.vix.com
+      addresses: 10.1.0.2 10.1.0.3 10.1.0.1
+
+      {hydra.ugly.vix.com
+      name: hydra2.ugly.vix.com
+      aliases: hydra.ugly.vix.com
+      addresses: 10.2.0.3 10.2.0.1 10.2.0.2
+
+      {hydra.ugly.vix.com
+      name: hydra3.ugly.vix.com
+      aliases: hydra.ugly.vix.com
+      addresses: 10.3.0.3 10.3.0.1 10.3.0.2
+
+-----------------------------------------------------------------------------
+
+Question 5.12.  Order of returned records
+
+Sorting, is the *resolver's* responsibility.  RFC 1123:
+
+
+         6.1.3.4  Multihomed Hosts
+
+            When the host name-to-address function encounters a host
+            with multiple addresses, it SHOULD rank or sort the
+            addresses using knowledge of the immediately connected
+            network number(s) and any other applicable performance or
+            history information.
+
+            DISCUSSION:
+                 The different addresses of a multihomed host generally
+                 imply different Internet paths, and some paths may be
+                 preferable to others in performance, reliability, or
+                 administrative restrictions.  There is no general way
+                 for the domain system to determine the best path.  A
+                 recommended approach is to base this decision on local
+                 configuration information set by the system
+                 administrator.
+
+In BIND 4.9.x's resolver code, the "sortlist" directive in resolv.conf
+can be used to configure this.
+
+-----------------------------------------------------------------------------
+
+Question 5.13.  resolv.conf
+
+Date: Fri Feb 10 15:46:17 EST 1995
+
+The question was asked one time, "Why should I use 'real' IP addresses in
+/etc/resolv.conf and not 0.0.0.0 or 127.0.0.1" ?
+
+Paul Vixie writes on the issue of the contents of resolv.conf:
+
+   It's historical.  Some kernels can't unbind a UDP socket's source
+   address, and some resolver versions (notably not including BIND
+   4.9.2 or 4.9.3's) try to do this.  The result can be wide area
+   network traffic with 127.0.0.1 as the source address.  Rather than
+   giving out a long and detailed map of version/vendor combinations of
+   kernels/BINDs that have/don't this problem, I just tell folks not to
+   use 127.0.0.1 at all.
+ 
+   0.0.0.0 is just an alias for the first interface address assigned
+   after a system boot, and if that interface is a up-and-down point to
+   point link (PPP, SLIP, whatever), there's no guarantee that you'll
+   be able to reach yourself via 0.0.0.0 during the entire lifetime of
+   any system instance.  On most kernels you can finesse this by adding
+   static routes to 127.0.0.1 for each of your interface addresses, but
+   some kernels don't like that trick and rather than give a detailed
+   map of which ones work and which ones don't, I just globally
+   recommend against 0.0.0.0.
+ 
+   If you know enough to know that 127.0.0.1 or 0.0.0.0 is safe on your
+   kernel and resolver, then feel free to use them.  If you don't know
+   for sure that it is safe, don't use them.  I never use them (except
+   on my laptop, whose hostname is "localhost" and whose 0.0.0.0 is
+   127.0.0.1 since I ifconfig my lo0 before any other interface).  The
+   operational advantage to using a real IP address rather than an
+   wormhole like 0.0.0.0 or 127.0.0.1, is that you can then "rdist" or
+   otherwise share identical copies of your resolv.conf on all the
+   systems on any given subnet, not all of which will be servers.
+
+The problem was with older versions of the resolver (4.8.X).  If you
+listed 127.0.0.1 as the first entry in resolv.conf, and for whatever
+reason the local name server wasn't running and the resolver fell back to
+the second name server listed, it would send queries to the name server
+with the source IP address set to 127.0.0.1 (as it was set when the
+resolver was trying to send to 127.0.0.1--you use the loopback address to
+send to the loopback address).
+
+-----------------------------------------------------------------------------
+
+Question 5.14.  How do I delegate authority for sub-domains ?
+
+Date: Sat Dec  7 02:04:17 EST 1996
+
+When you start having a very big domain that can be broken into logical
+and separate entities that can look after their own DNS information, you
+will probably want to do this.  Maintain a central area for the things
+that everyone needs to see and delegate the authority for the other parts
+of the organization so that they can manage themselves.
+
+Another essential piece of information is that every domain that exists
+must have it NS records associated with it.  These NS records denote the
+name servers that are queried for information about that zone.  For your
+zone to be recognized by the outside world, the server responsible for the
+zone above you must have created a NS record for your your new servers
+(NOTE that the new servers DO NOT  have to be in the new domain).  For
+example, putting the computer club onto the network and giving them
+control over their own part  of the domain space we have the following.
+
+The machine authorative for gu.uwa.edu.au is mackerel and the machine
+authorative for ucc.gu.uwa.edu.au is marlin.
+
+in mackerel's data for gu.uwa.edu.au we have the following
+
+   @               IN      SOA ...
+                   IN      A       130.95.100.3
+                   IN      MX      mackerel.gu.uwa.edu.au.
+                   IN      MX      uniwa.uwa.edu.au.
+    
+   marlin          IN      A       130.95.100.4
+ 
+   ucc             IN      NS      marlin.gu.uwa.edu.au.
+                   IN      NS      mackerel.gu.uwa.edu.au.
+
+Marlin is also given an IP in our domain as a convenience.  If they blow
+up their name serving there is less that can go wrong because people can
+still see that machine which is a start.  You could place "marlin.ucc" in
+the first column and leave the machine totally inside the ucc domain as
+well.
+
+The second NS line is because mackerel will be acting as secondary name
+server for the ucc.gu domain.  Do not include this line if you are not
+authorative for the information included in the sub-domain.
+
+-----------------------------------------------------------------------------
+
+Question 5.15.  DNS instead of NIS on a Sun OS 4.1.x system
+
+Date: Sat Dec  7 01:14:17 EST 1996
+
+Comments relating to running bind 4.9.x on a Sun OS 4.1.x system and the
+effect on sendmail, ftp, telnet and other TCP/IP services bypassing NIS
+and directly using named is documented quite well in the
+comp.sys.sun.admin FAQ in questions one and two.  You can get them from:
+
+* ftp.ece.uc.edu : /pub/sun-faq/FAQs/sun-faq.general
+* http://www.cis.ohio-state.edu/hypertext/faq/usenet/comp-sys-sun-faq
+
+as well as from rtfm.mit.edu in the usual place, etc.
+
+-----------------------------------------------------------------------------
+
+Question 5.16.  Patches to add functionality to BIND
+
+Date: Tue Nov  5 23:53:47 EST 1996
+
+There are others, but these are listed here:
+
+* When using the round robin DNS and assigning 3 IPs to a host (for
+  example), a process to guarantee that all 3 IPs are reachable may be
+  found  at
+  http://www-leland.stanford.edu/~schemers/docs/lbnamed/lbnamed.html
+
+* Patches for 4.9.3-REL that will support the IPv6 AAAA record format may
+  be  found at ftp.inria.fr : /network/ipv6/
+
+* A patch for 4.9.3-REL that will allow you to turn off forwarding of
+  information from my server may be found at ftp.vix.com :
+  /pub/bind/release/4.9.3/contrib/noforward.tar.gz
+
+* How do I tell a server to listen to a particular interface to listen and
+  respond to DNS queries on ?
+
+  Mark Andrews has a patch that will tell a 4.9.4 server to listen to a
+  particular interface and respond to DNS queries.  It may be found at an
+  unofficial location: http://www.ultra.net/~jzp/andrews.patch.txt
+
+-----------------------------------------------------------------------------
+
+Question 5.17.  How to serve multiple domains from one server
+
+Date: Tue Nov  5 23:44:02 EST 1996
+
+Most name server implementations allow information about multiple domains
+to be kept on one server, and questions about those domains  to be
+answered by that one server.  For instance, there are many large  servers
+on the Internet that each serve information about more than  1000
+different domains.
+
+To be completely accurate, a server contains information about zones,
+which are parts of domains that are kept as a single unit.  [Ed note: for
+a definition of zones and domains, see Section 2: The Name Service in the
+"Name Server Operations Guide" included with the BIND 4.9.5 distribution.]
+
+In the configuration of the name server, the additional zones need to be
+specified.  An important consideration is whether a particular server is
+primary or secondary for any specific zone--a secondary server maintains
+only a copy of the zone, periodically refreshing its copy from another,
+specified, server.  In BIND, to set up a server as a secondary server for
+the x.y.z zone, to the configuration file /etc/named.boot add the line
+
+      secondary   x.y.z   10.0.0.1        db.x.y.z
+
+where 10.0.0.1 is the IP address of the server that the zone will be
+copied from, and db.x.y.z is a local filename that will contain the copy
+of the zone.
+
+If this is a question related to how to set up multiple IP numbers on one
+system, which you do not need to do to act as a domain server for
+multiple domains, see
+
+http://www.thesphere.com/%7Edlp/TwoServers/.
+
+===============================================================================
+
+Section 6.  PROBLEMS
+
+ Q6.1        No address for root server
+ Q6.2        Error - No Root Nameservers for Class XX
+ Q6.3        Bind 4.9.x and MX querying?
+ Q6.4        Do I need to define an A record for localhost ?
+ Q6.5        MX records, CNAMES and A records for MX targets
+ Q6.6        Can an NS record point to a CNAME ?
+ Q6.7        Nameserver forgets own A record
+ Q6.8        General problems (core dumps !)
+ Q6.9        malloc and DECstations
+ Q6.10       Can't resolve names without a "."
+ Q6.11       Err/TO errors being reported
+ Q6.12       Why does swapping kill BIND ?
+
+-----------------------------------------------------------------------------
+
+Question 6.1.  No address for root server
+
+Date: Mon Jan  2 13:49:43 EST 1995
+
+Q: I've been getting the following messages lately from bind-4.9.2..
+        ns_req: no address for root server
+ 
+We are behind a firewall and have the following for our named.cache file -
+ 
+        ; list of servers
+        .               99999999    IN  NS  POBOX.FOOBAR.COM.
+                        99999999    IN  NS  FOOHOST.FOOBAR.COM.
+        foobar.com.     99999999    IN  NS  pobox.foobar.com.
+You can't do that.  Your nameserver contacts POBOX.FOOBAR.COM, gets the
+correct list of root servers from it, then tries again and fails because
+of your firewall.
+
+You will need a 'forwarder' definition, to ensure that all requests are
+forwarded to a host which can penetrate the firewall.  And it is unwise to
+put phony data into 'named.cache'.
+
+-----------------------------------------------------------------------------
+
+Question 6.2.  Error - No Root Nameservers for Class XX
+
+Date: Sun Nov 27 23:32:41 EST 1994
+
+Q: I've received errors before about "No root nameservers for class XX"
+   but they've been because of network connectivity problems.
+   I believe that Class 1 is Internet Class data.
+   And I think I heard someone say that Class 4 is Hesiod??
+   Does anyone know what the various Class numbers are?
+From RFC 1700:
+
+       DOMAIN NAME SYSTEM PARAMETERS
+       The Internet Domain Naming System (DOMAIN) includes several
+       parameters.  These are documented in [RFC1034] and [RFC1035].  The
+       CLASS parameter is listed here.  The per CLASS parameters are 
+       defined in separate RFCs as indicated.
+
+       Domain System Parameters:
+
+       Decimal   Name                                          References
+       --------  ----                                          ----------
+              0  Reserved                                           [PM1]
+              1  Internet (IN)                              [RFC1034,PM1]
+              2  Unassigned                                         [PM1]
+              3  Chaos (CH)                                         [PM1]
+              4  Hesoid (HS)                                       [PM1]
+        5-65534  Unassigned                                         [PM1]
+          65535  Reserved                                           [PM1]
+
+DNS information for RFC 1700 was taken from
+ftp.isi.edu : /in-notes/iana/assignments/dns-parameters
+
+Hesiod is class 4, and there are no official root nameservers for class 4,
+so you can safely declare yourself one if you like.  You might want  to
+put up a packet filter so that no one outside your network is capable  of
+making Hesiod queries of your machines, if you define yourself to be  a
+root nameserver for class 4.
+
+-----------------------------------------------------------------------------
+
+Question 6.3.  Bind 4.9.x and MX querying?
+
+Date: Sun Nov 27 23:32:41 EST 1994
+
+If you query a 4.9.x DNS server for MX records, a list of the MX records
+as well as a list of the authorative nameservers is returned.  This
+happens because bind 4.9.2 returns the list of nameserver that are
+authorative for a domain in the response packet, along with their IP
+addresses in the additional section.
+
+-----------------------------------------------------------------------------
+
+Question 6.4.  Do I need to define an A record for localhost ?
+
+Date: Sat Sep  9 00:36:01 EDT 1995
+
+Somewhere deep in the BOG (BIND Operations Guide) that came with 4.9.3
+(section 5.4.3), it says that you define this yourself  (if need be) in
+the same zone files as your "real" IP addresses  for your domain.  Quoting
+the BOG:
+
+
+                                 ... As  implied by this PTR
+         record, there should be a  ``localhost.my.dom.ain''
+         A  record  (with address 127.0.0.1) in every domain
+         that contains hosts.  ``localhost.'' will lose  its
+         trailing dot when 1.0.0.127.in-addr.arpa is queried
+         for;...
+
+The sample files in the BIND distribution show you what needs to be done
+(see the BOG).
+
+Some HP boxen (especially those running HP OpenView) will also need
+"loopback" defined with this IP address.   You may set it as a CNAME
+record pointing to the "localhost." record.
+
+-----------------------------------------------------------------------------
+
+Question 6.5.  MX records, CNAMES and A records for MX targets
+
+Date: Sun Nov 27 23:32:41 EST 1994
+
+The O'Reilly "DNS and Bind" book warns against using non-canonical names
+in MX records, however, this warning is given in the context of mail hubs
+that MX to each other for backup purposes.  How does this apply to mail
+spokes.  RFC 974 has a similar warning, but where is it specifically
+prohibited to us an alias in an MX record ?
+
+Without the restrictions in the RFC, a MTA must request the A records  for
+every MX listed to determine if it is in the MX list then reduce the list.
+This introduces many more lookups than would other wise be required. If
+you are behind a 1200 bps link YOU DON'T WANT TO DO THIS. The addresses
+associated with CNAMES are not passed as additional data so you will force
+additional traffic to result even if you are running a caching server
+locally.
+
+There is also the problem of how does the MTA find all of it's IP
+addresses. This is not straight forward. You have to be able to do this is
+you allow CNAMEs (or extra A's) as MX targets.
+
+The letter of the law is that an MX record should point to an A record.
+
+There is no "real" reason to use CNAMEs for MX targets or separate As for
+nameservers any more. CNAMEs for services other than mail should be used
+because there is no specified method for locating the desired server yet.
+
+People don't care what the names of MX targets are.  They're invisible to
+the process anyway.  If you have mail for "mary" redirected to "sue" is
+totally irrelevant.  Having CNAMEs as the targets of MX's just needlessly
+complicates things, and is more work for the resolver.
+
+Having separate A's for nameservers like "ns.your.domain" is pointless
+too, since again nobody cares what the name of your nameserver is, since
+that too is invisible to the process.  If you move your nameserver from
+"mary.your.domain" to "sue.your.domain" nobody need care except you and
+your parent domain administrator (and the InterNIC).  Even less so for
+mail servers, since only you are affected.
+
+Q: Given the example - 
+
+     hello in cname     realname
+     mailx in mx        0 hello
+
+   Now, while reading the operating manual of bind it clearly states
+   that this is *not* valid.  These two statements clearly contradict
+   each other.  Is there some later rfc than 974 that overrides what is
+   said in there with respect to MX and CNAMEs?  Anyone have the
+   reference handy?
+
+A: This isn't what the BOG says at all.  See below.  You can have a CNAME 
+   that points to some other RR type; in fact, all CNAMEs have to point
+   to other names (Canonical ones, hence the C in CNAME).  What you
+   can't have is an MX that points to a CNAME.  MX RR's that point to
+   names which have only CNAME RR's will not work in many cases, and
+   RFC 974 intimates that it's a bad idea:
+
+      Note that the algorithm to delete irrelevant RRs breaks if LOCAL has
+      a alias and the alias is listed in the MX records for REMOTE.  (E.g.
+      REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL).  This
+      can be avoided if aliases are never used in the data section of MX
+      RRs.
+
+   Here's the relevant BOG snippet:
+
+         aliases    {ttl   addr-class   CNAME   Canonical name
+         ucbmonet           IN           CNAME   monet
+
+         The  Canonical  Name resource record, CNAME, speci-
+         fies an alias or  nickname  for  the  official,  or
+         canonical,  host  name.   This record should be the
+         only one associated with the alias name.  All other
+         resource  records  should  be associated  with the
+         canonical  name,  not  with  the   nickname.  Any
+         resource  records  that  include  a  domain name as
+         their value (e.g., NS or MX) must list the  canoni-
+         cal name, not the nickname.
+
+-----------------------------------------------------------------------------
+
+Question 6.6.  Can an NS record point to a CNAME ?
+
+Date: Wed Mar  1 11:14:10 EST 1995
+
+Can I do this ?  Is it legal ?
+
+
+   @                       SOA     (.........)
+                           NS      ns.host.this.domain.
+                           NS      second.host.another.domain.
+   ns                      CNAME   third
+   third           IN      A       xxx.xxx.xxx.xxx
+
+No.  Only one RR type is allowed to refer, in its data field, to a CNAME,
+and that's CNAME itself.  So CNAMEs can refer to CNAMEs but  NSs and MXs
+cannot.
+
+BIND 4.9.3 (Beta11 and later) explicitly syslogs this case rather than
+simply failing as pre-4.9 servers did.  Here's a current example:
+
+      Dec  7 00:52:18 gw named[17561]: "foobar.com IN NS" \
+             points to a CNAME (foobar.foobar.com)
+
+Here is the reason why:
+
+Nameservers are not required to include CNAME records in the Additional
+Info section returned after a query.  It's partly an implementation
+decision and partly a part of the spec.  The algorithm described in RFC
+1034 (pp24,25; info also in RFC 1035, section 3.3.11, p 18) says 'Put
+whatever addresses are available into the additional section, using glue
+RRs [if necessary]'.  Since NS records are speced to contain only primary
+names of hosts, not CNAMEs, then there's no reason for algorithm to
+mention them. If, on the other hand, it's decided to allow CNAMEs in NS
+records (and indeed in other records) then there's no reason that CNAME
+records might not be included along with A records.  The Additional Info
+section is intended for any information that might be useful but which
+isn't strictly the answer to the DNS query processed.  It's an
+implementation decision in as much as some servers used to follow CNAMEs
+in  NS references.
+
+-----------------------------------------------------------------------------
+
+Question 6.7.  Nameserver forgets own A record
+
+Date: Fri Dec  2 16:17:31 EST 1994
+
+Q: Lately, I've been having trouble with named 4.9.2 and 4.9.3.  
+   Periodically, the nameserver will seem to "forget" its own A record,
+   although the other information stays intact.  One theory I had was
+   that somehow a site that the nameserver was secondary for was
+   "corrupting" the A record somehow.
+ 
+A: This is invariably due to not removing ALL of the cached zones
+   when you moved to 4.9.X. Remove ALL cached zones and restart
+   your nameservers.
+ 
+   You get "ignoreds" because the primaries for the relevant zones are
+   running old versions of BIND which pass out more glue than is
+   required. named-xfer trims off this extra glue.
+
+-----------------------------------------------------------------------------
+
+Question 6.8.  General problems (core dumps !)
+
+Date: Sun Dec  4 22:21:22 EST 1994
+
+Paul Vixie says:
+
+   I'm always interested in hearing about cases where BIND dumps core.
+   However, I need a stack trace.   Compile with -g and not -O (unless
+   you are using gcc and know what you are doing) and then when it
+   dumps core, get into dbx or gdb using the executable and the core
+   file and use "bt" to get a stack trace.   Send it to me
+   <paul@vix.com> along with specific circumstances leading to or
+   surrounding the crash (test data, tail of the debug log, tail of the
+   syslog... whatever matters) and ideally you should save your core
+   dump for a day or so in case I have questions you can answer via
+   gdb/dbx.
+
+-----------------------------------------------------------------------------
+
+Question 6.9.  malloc and DECstations
+
+Date: Mon Jan  2 14:19:22 EST 1995
+
+We have replaced malloc on our DECstations with a malloc that is more
+compact in memory usage, and this helped the operation of bind a lot.  The
+source is now available for anonymous ftp from
+
+ftp.cs.wisc.edu : /pub/misc/malloc.tar.gz
+
+-----------------------------------------------------------------------------
+
+Question 6.10.  Can't resolve names without a "."
+
+(Answer written by Mark Andrews) You are not using a RFC 1535 aware
+resolver. Depending upon the age of your resolver you could try  adding a
+search directive to resolv.conf.
+
+	e.g.
+	domain <domain>
+	search <domain> [<domain2> ...]
+
+If that doesn't work you can configure you server to serve the parent and
+grandparent domains as this is the default search list.
+
+"domain langley.af.mil" has an implicit "search langley.af.mil af.mil mil"
+in the old resolvers, and you are timing out trying to resolve the
+address with one of these domains tacked on.
+
+When resolving internic.net the following will be tried in order.
+        internic.net.langley.af.mil
+        internic.net.af.mil
+        internic.net.mil
+        internic.net.
+
+RFC 1535 aware resolvers try qualified address first.
+
+        internic.net.
+        internic.net.langley.af.mil
+        internic.net.af.mil
+        internic.net.mil
+RFC 1535 documents the problems associated with the old search
+algorithim,  including security issues, and how to alleviate some of the
+problems.
+
+-----------------------------------------------------------------------------
+
+Question 6.11.  Err/TO errors being reported
+
+Date: Sun May  5 23:46:32 EDT 1996
+
+Why are errors like
+
+     Apr  2 20:41:58 nameserver named[25846]: Err/TO getting serial# for 
+     "foobar.domain1.com"
+     Apr  2 20:41:59 nameserver named[25846]: Err/TO getting serial# for 
+     "foobar.domain2.com"
+
+reported ?  These generally indicate that there is one of the following
+problems:
+
+* A network problem between you and the primary,
+* A bad IP address in named.boot,
+* The primary is Lame for the zone.
+
+An external check to see if you can retrieve the SOA is the best way to
+work out which it is.
+
+-----------------------------------------------------------------------------
+
+Question 6.12.  Why does swapping kill BIND ?
+
+Date: Thu Jul  4 23:20:20 EDT 1996
+
+The question was:
+
+   I've been diagnosing a problem with BIND 4.9.x (where x is usually 3BETA9 
+   or 3REL) for several months now.  I finally tracked it down to swap space
+   utilization on the unix boxes.
+
+   This happens under (at least) under Linux 1.2.9 & 1.2.13, SunOS 4.1.3U1, 
+   4.1.1, and Solaris 2.5.  The symptom is that if these machines get into 
+   swap at all bind quits resolving most, if not all queries.  Mind you that 
+   these machines are not "swapping hard", but rather we're talking about a 
+   several hundred K TEMPORARY deficiency.   I have noticed while digging 
+   through various archives that there is some referral to "bind thrashing
+   itself to death".   Is this what is happening ?
+
+And the answer is:
+
+   Yes it is. Bind can't tolerate having even a few pages swapped out.  
+   The time required to send responses climbs to several seconds/request,
+   and the request queue fills and overflows.
+
+   It's possible to shrink memory consumption a lot by undefining STATS
+   and XSTATS, and recompiling.  You could nuke DEBUG too, which will
+   cut the code size down some, but probably not the data size.  If that
+   doesn't do the job then it sounds like you'll need to move DNS onto a
+   separate box.
+
+   BIND tends to touch all of its resident pages all of the time with
+   normal activity... if you look at the RSS verses the total process
+   size, you will always see the RSS within, usually, 90% of the total
+   size of the process.  This means that *any* paging of named-owned
+   pages will stall named.  Thus, a machine running a heavily accessed
+   named process cannot afford to swap *at all*.
+
+   (Paul Vixie continues on this subject):
+   I plan to try to get BIND to exhibit slightly better locality of
+   reference in some future release.  Of course, I can only do this if
+   the query names also exhibit some kind of hot spots.  If someone
+   queries all your names often, BIND will have to touch all of its VM
+   pool that often.  (Right now, BIND touches everything pretty often
+   even if you're just hammering on some hot spots -- that's the part
+   I'd like to fix.  Malloc isn't cooperating.)
+
+===============================================================================
+
+Section 7.  ACKNOWLEDGEMENTS
+
+ Q7.1        How is this FAQ generated ?
+ Q7.2        What formats are available ?
+ Q7.3        Contributors
+
+-----------------------------------------------------------------------------
+
+Question 7.1.  How is this FAQ generated ?
+
+Date: Fri Dec  6 16:51:31 EST 1996
+
+This FAQ is maintained in BFNN (Bizzarre Format with No Name).  This
+allows me to create ASCII, HTML, and GNU info (postscript coming soon)
+from one source file.
+
+The perl script "bfnnconv.pl" that is available with the linux FAQ is used
+to generate the various output files from the BFNN source.
+
+-----------------------------------------------------------------------------
+
+Question 7.2.  What formats are available ?
+
+Date: Fri Dec  6 16:51:31 EST 1996
+
+You may obtain one of the following formats for this document:
+
+* ASCII: http://www.users.pfmc.net/~cdp/cptd-faq/cptd-faq.ascii
+* BFNN: http://www.users.pfmc.net/~cdp/cptd-faq/cptd-faq.bfnn
+* GNU info: http://www.users.pfmc.net/~cdp/cptd-faq/cptd-faq.info
+* HTML: http://www.users.pfmc.net/~cdp/cptd-faq/index.html
+
+-----------------------------------------------------------------------------
+
+Question 7.3.  Contributors
+
+Date: Sat Dec  7 01:29:29 EST 1996
+
+Many people have helped put this list together.  Listed in e-mail address
+alphabetical order, the following people have contributed to this FAQ:
+
+* <Benoit.Grange@inria.fr> (Benoit.Grange)
+* <D.T.Shield@csc.liv.ac.uk> (Dave Shield)
+* <Todd.Aven@BankersTrust.Com>
+* <adam@comptech.demon.co.uk> (Adam Goodfellow)
+* <andras@is.co.za> (Andras Salamon)
+* <barmar@nic.near.net> (Barry Margolin)
+* <barr@pop.psu.edu> (David Barr)
+* <bj@herbison.com> (B.J. Herbison)
+* <bje@cbr.fidonet.org> (Ben Elliston)
+* <brad@birch.ims.disa.mil> (Brad Knowles)
+* <ckd@kei.com> (Christopher Davis)
+* <cdp2582@hertz.njit.edu> (Chris Peckham)
+* <cricket@hp.com> (Cricket Liu)
+* <cudep@csv.warwick.ac.uk> (Ian 'Vato' Dickinson [ID17])
+* <dillon@best.com> (Matthew Dillon)
+* <dparter@cs.wisc.edu> (David Parter)
+* <e07@nikhef.nl> (Eric Wassenaar)
+* <fitz@think.com> (Tom Fitzgerald)
+* <fwp@CC.MsState.Edu> (Frank Peters)
+* <gah@cco.caltech.edu> (Glen A. Herrmannsfeldt)
+* <glenn@popco.com> (Glenn Fleishman)
+* <harvey@indyvax.iupui.edu> (James Harvey)
+* <hubert@cac.washington.edu> (Steve Hubert)
+* <ivanl@pacific.net.sg> (Ivan Leong)
+* <jhawk@panix.com> (John Hawkinson)
+* <jmalcolm@uunet.uu.net> (Joseph Malcolm)
+* <jprovo@augustus.ultra.net> (Joe Provo)
+* <kevin@cfc.com> (Kevin Darcy)
+* <lamont@abstractsoft.com> (Sean T. Lamont)
+* <lavondes@tidtest.total.fr> (Michel Lavondes)
+* <mark@ucsalf.ac.uk> (Mark Powell)
+* <marka@syd.dms.CSIRO.AU> (Mark Andrews)
+* <mathias@unicorn.swi.com.sg> (Mathias Koerber)
+* <mjo@iao.ford.com> (Mike O'Connor)
+* <nick@flapjack.ieunet.ie> (Nick Hilliard)
+* <oppedahl@popserver.panix.com> (Carl Oppedahl)
+* <patrick@oes.amdahl.com> (Patrick J. Horgan)
+* <paul@software.com> (Paul Wren)
+* <pb@fasterix.frmug.fr.net> (Pierre Beyssac)
+* <ph10@cus.cam.ac.uk> (Philip Hazel)
+* <phil@netpart.com> (Phil Trubey)
+* <rocky@panix.com> (R. Bernstein)
+* <rv@seins.Informatik.Uni-Dortmund.DE> (Ruediger Volk)
+* <shields@tembel.org> (Michael Shields)
+* <tanner@george.arc.nasa.gov> (Rob Tanner)
+* <vixie@vix.com> (Paul A Vixie)
+* <wag@swl.msd.ray.com> (William Gianopoulos {84718)
+* <whg@inel.gov> (Bill Gray)
+* <wolf@pasteur.fr> (Christophe Wolfhugel)
+
+Thank you !
+
diff --git a/usr.sbin/named/doc/misc/IPv6 b/usr.sbin/named/doc/misc/IPv6
new file mode 100644
index 00000000000..49fc3f5ec37
--- /dev/null
+++ b/usr.sbin/named/doc/misc/IPv6
@@ -0,0 +1,72 @@
+IPv6 notes for BIND 4.9.3 Patch 2 Candidate 5 (and later?)
+Paul Vixie, May 20, 1996
+doc/misc/IPv6
+
+			*** Introduction ***
+
+The IPv6 support in this release is latent, in that its presence is not
+documented.  The support is not optional, since its presence ought not to
+affect anyone who does not go looking for it.  The support includes:
+
+	inet_ntop()	new function.
+	inet_pton()	new function.
+	RES_USE_INET6	causes gethostby*() to return either real IPv6
+			addresses (if available) or mapped (::FFFF:a.b.c.d)
+			addresses if only IPv4 address records are found.
+	gethostbyname()	can search for T_AAAA in preference to T_A.
+	gethostbyaddr()	can search in IP6.INT for PTR RR's.
+	named		can load, transfer, cache, and dump T_AAAA RRs.
+
+		*** Some notes on the new functions ***
+
+The inet_pton() and inet_ntop() functions differ from the current (as of
+this writing) IPv6 BSD API draft.  Discussions were held, primarily between
+myself and Rich Stevens, on the ipng@sunroof.eng.sun.com mailing list, and
+the BIND definitions of these functions are likely to go into the next draft.
+(If not, and BIND has to change its definitions of these functions, then you
+will know why I chose not to document them yet!)
+
+These functions can return error values, and as such the process of porting
+code that used inet_aton() to use inet_pton() is not just syntactic.  Not all
+nonzero values indicate success; consider "-1".  Likewise, inet_ntoa() is not
+just smaller than inet_ntop() -- it's a whole new approach.  Inet_ntop() does
+not return a static pointer, the caller has to supply a sized buffer.  Also,
+inet_ntop() can return NULL, so you should only printf() the result if you
+have verified that your arguments will be seen as error free.
+
+The inet_pton() function is much pickier about its input format than the old
+inet_aton() function has been.  You can't abbreviate 10.0.0.53 as 10.53 any
+more.  Hexadecimal isn't accepted.  You have to supply four decimal numeric
+strings, each of whose value is within the range from 0 to 255.  No spaces
+are allowed either before, after, or within an address.  If you need the older
+functionality with all the shortcuts and exceptions, continue using inet_aton()
+for your IPv4 address parsing needs.
+
+		   *** Some notes on RES_USE_INET6 ***
+
+You can set this by modifying _res.options after calling res_init(), or you
+can turn it on globally by setting "options inet6" in /etc/resolv.conf.  This
+latter option ought to be used carefully, since _all_ applications will then
+receive IPv6 style h_addr_list's from their gethostby*() calls.  Once you know
+that every application on your system can cope with IPv6 addressing, it is safe
+and reasonable to turn on the global option.  Otherwise, don't do it.
+
+		*** Some notes on mapped IPv4 addresses ***
+
+There are two IPv6 prefixes set aside for IPv4 address encapsulation.  See
+RFC 1884 for a detailed explaination.  The ::a.b.c.d form is used for
+tunnelling, which means wrapping an IPv4 header around IPv6 packets and using
+the existing IPv4 routing infrastructure to reach what are actually IPv6
+endpoints.  The ::FFFF:a.b.c.d form can be used on dual-stack (IPv4 and IPv6)
+hosts to signal a predominantly IPv6 stack that it should use ``native'' IPv4
+to reach a given destination, even though the socket's address family is
+AF_INET6.
+
+BIND supports both of these address forms, to the extent that inet_pton() will
+parse them, inet_ntop() will generate them, gethostby*() will map IPv4 into
+IPv6 if the RES_USE_INET6 option is set, and gethostbyaddr() will search the
+IN-ADDR.ARPA domain rather than the IP6.INT domain when it needs a PTR RR.
+This last bit of behaviour is still under discussion and it's not clear that
+tunnelled addresses should be mapped using IN-ADDR.ARPA.  In other words, this
+bit of behaviour may change in a subsequent BIND release.  So now you know
+another reason why none of this stuff is ``officially'' documented.
diff --git a/usr.sbin/named/doc/misc/dns-setup b/usr.sbin/named/doc/misc/dns-setup
new file mode 100644
index 00000000000..19f0197f7e8
--- /dev/null
+++ b/usr.sbin/named/doc/misc/dns-setup
@@ -0,0 +1,1081 @@
+                Setting up a basic DNS server for a domain
+                            Revision 1.1.1
+
+                            Craig Richmond
+                         craig@ecel.uwa.edu.au
+                           15th August 1993
+
+
+About this document
+
+I have written this file because it seems that the same questions seem to
+pop up time and time again and when I had to install DNS from scratch the
+first time, we found very little to help us.
+
+This document covers setting up a Domain Name Server with authority over
+your domain and using a few of the more useful but less well known
+(hopefully this document will take care of that) features of nslookup to
+get information about the DNS and to work out why yours isn't working.
+
+If you are using a Sun Workstation and you want to make NIS interact with
+the DNS, then this is not the FAQ for you (but it may well be when you try
+to set up the DNS).  Mark J. McIntosh <Mark.McIntosh@engr.UVic.CA> points
+out that it is included in the comp.sys.sun.admin FAQ and for the benefit
+of those of you who can't get that (it is posted in comp.sys.sun.admin,
+comp.sys.sun.misc, comp.unix.solaris, comp.answers and news.answers) I have
+included the relevant parts at the bottom in appendix C.
+
+Contents:
+
+   Contents
+   An Overview of the DNS
+   Installing the DNS
+    *The Boot File
+    *The Cache File
+    *The Forward Mapping File
+    *The Reverse Mapping File
+   Delegating authority for domains within your domain
+   Troubleshooting your named
+    *Named doesn't work!  What is wrong?
+    *I changed my named database and my local machine has noticed,
+     but nobody else has the new information?
+    *My local machine knows about all the name server information,
+     but no other sites know about me?
+    *My forward domain names work, but the backward names do not?
+   How to get useful information from nslookup
+    *Getting number to name mappings.
+    *Finding where mail goes when a machine has no IP number.
+    *Getting a list of machines in a domain from nslookup.
+   Appendicies
+    *Appendix A  sample root.cache file
+    *Appendix B  Excerpt from RFC 1340 - Assigned Numbers - July 1992
+    *Appendix C  Installing DNS on a Sun when running NIS
+
+
+An Overview of the DNS:
+
+The Domain Name System is the software that lets you have name to number
+mappings on your computers.  The name decel.ecel.uwa.edu.au is the number
+130.95.4.2 and vice versa.  This is achieved through the DNS.  The DNS is a
+heirarchy.  There are a small number of root domain name servers that are
+responsible for tracking the top level domains and who is under them.  The
+root domain servers between them know about all the people who have name
+servers that are authoritive for domains under the root.
+
+Being authoritive means that if a server is asked about something in that
+domain, it can say with no ambiguity whether or not a given piece of
+information is true.  For example.  We have domains x.z and y.z.  There are
+by definition authoritive name servers for both of these domains and we
+shall assume that the name server in both of these cases is a machine
+called nic.x.z and nic.y.z but that really makes no difference.
+
+If someone asks nic.x.z whether there is a machine called a.x.z, then
+nic.x.z can authoritively say, yes or no because it is the authoritive name
+server for that domain.  If someone asks nic.x.z whether there is a machine
+called a.y.z then nic.x.z asks nic.y.z whether such a machine exists (and
+caches this for future requests).  It asks nic.y.z because nic.y.z is the
+authoritive name server for the domain y.z.  The information about
+authoritive name servers is stored in the DNS itself and as long as you
+have a pointer to a name server who is more knowledgable than yourself then
+you are set.
+
+When a change is made, it propogates slowly out through the internet to
+eventually reach all machines.  The following was supplied by Mark Andrews
+Mark.Andrews@syd.dms.csiro.au.
+
+        If both the primary and all secondaries are up and talking when
+        a zone update occurs and for the refresh period after the
+        update the old data will live for max(refresh + mininum)
+        average (refresh/2 +mininum) for the zone. New information will
+        be available from all servers after refresh.
+
+So with a refresh of 3 hours and a minimum of a day, you can expect
+everything to be working a day after it is changed.  If you have a longer
+minimum, it may take a couple of days before things return to normal.
+
+There is also a difference between a zone and a domain.  The domain is the
+entire set of machines that are contained within an organisational domain
+name.  For example, the domain uwa.edu.au contains all the machines at the
+University of Western Australia.  A Zone is the area of the DNS for which a
+server is responsible.  The University of Western Australia is a large
+organisation and trying to track all changes to machines at a central
+location would be difficult.  The authoritive name server for the zone
+uwa.edu.au delegates the authority for the zone ecel.uwa.edu.au to
+decel.ecel.uwa.edu.au.  Machine foo.ecel.uwa.edu.au is in the zone that
+decel is authoritive for.  Machine bar.uwa.edu.au is in the zone that
+uniwa.uwa.edu.au is authoritive for.
+
+Installing the DNS:
+
+First I'll assume you already have a copy of the Domain Name Server
+software.  It is probably called named or in.named depending on your
+flavour of unix.  I never had to get a copy, but if anyone thinks that
+information should be here then by all means tell me and I'll put it in.
+If you intend on using the package called Bind, then you should be sure
+that you get version 4.9, which is the most recent version at this point in
+time.
+
+The Boot File:
+
+First step is to create the file named.boot.  This describes to named
+(we'll dispense with the in.named.  Take them to be the same) where the
+information that it requires can be found.  This file is normally found in
+/etc/named.boot and I personally tend to leave it there because then I know
+where to find it.  If you don't want to leave it there but place it in a
+directory with the rest of your named files, then there is usually an
+option on named to specify the location of the boot file.
+
+Your typical boot file will look like this if you are an unimportant leaf
+node and there are other name servers at your site.
+
+directory	/etc/namedfiles
+
+cache		.	       				root.cache
+primary		ecel.uwa.edu.au				ecel.uwa.domain
+primary		0.0.127.in-addr.arpa			0.0.127.domain
+primary		4.95.130.in-addr.arpa			4.95.130.domain
+forwarders      130.95.128.1
+
+Here is an alternative layout used by Christophe Wolfhugel
+<Christophe.Wolfhugel@grasp.insa-lyon.fr>  He finds this easier because of
+the large number of domains he has.  The structure is essentially the same,
+but the file names use the domain name rather than the IP subnet to
+describe the contents.
+
+directory       /usr/local/etc/bind
+cache     .                      p/root
+;
+; Primary servers
+;
+primary   fr.net                        p/fr.net
+primary   frmug.fr.net                  p/frmug.fr.net
+primary   127.in-addr.arpa              p/127
+;
+; Secondary servers
+;
+secondary ensta.fr                 147.250.1.1     s/ensta.fr
+secondary gatelink.fr.net          134.214.100.1   s/gatelink.fr.net
+secondary insa-lyon.fr             134.214.100.1   s/insa-lyon.fr
+secondary loesje.org               145.18.226.21   s/loesje.org
+secondary nl.loesje.org            145.18.226.21   s/nl.loesje.org
+secondary pcl.ac.uk                161.74.160.5    s/pcl.ac.uk
+secondary univ-lyon1.fr            134.214.100.1   s/univ-lyon1.fr
+secondary wmin.ac.uk               161.74.160.5    s/wmin.ac.uk
+secondary westminster.ac.uk        161.74.160.5    s/westminster.ac.uk
+;
+;
+; Secondary for addresses
+;
+secondary 74.161.in-addr.arpa      161.74.160.5    s/161.74
+secondary 214.134.in-addr.arpa     134.214.100.1   s/134.214
+secondary 250.147.in-addr.arpa     147.250.1.1     s/147.250
+;
+; Classes C
+;
+secondary 56.44.192.in-addr.arpa   147.250.1.1     s/192.44.56
+secondary 57.44.192.in-addr.arpa   147.250.1.1     s/192.44.57
+
+The lines in the named.boot file have the following meanings.
+
+directory
+
+This is the path that named will place in front of all file names
+referenced from here on.  If no directory is specified, it looks for files
+relative to /etc.
+
+cache
+
+This is the information that named uses to get started.  Named must know
+the IP number of some other name servers at least to get started.
+Information in the cache is treated differently depending on your version
+of named.  Some versions of named use the information included in the cache
+permenantly and others retain but ignore the cache information once up and
+running.
+
+primary
+
+This is one of the domains for which this machine is authorative for.  You
+put the entire domain name in.  You need forwards and reverse lookups.  The
+first value is the domain to append to every name included in that file.
+(There are some exceptions, but they will be explained later)  The name at
+the end of the line is the name of the file (relative to /etc of the
+directory if you specified one).  The filename can have slashes in it to
+refer to subdirectories so if you have a lot of domains you may want to
+split it up.
+
+BE VERY CAREFUL TO PUT THE NUMBERS BACK TO FRONT FOR THE REVERSE LOOK UP
+FILE.  The example given above is for the subnet ecel.uwa.edu.au whose IP
+address is 130.95.4.*.  The reverse name must be 4.95.130.in-addr.arpa.
+It must be backwards and it must end with .in-addr.arpa.  If your reverse
+name lookups don't work, check this.  If they still don't work, check this
+again.
+
+forwarders
+
+This is a list of IP numbers for forward requests for sites about which we
+are unsure.  A good choice here is the name server which is authoritive for
+the zone above you.
+
+secondary (This line is not in the example, but is worth mentioning.)
+
+A secondary line indicates that you wish to be a secondary name server for
+this domain.  You do not need to do this usually.  All it does is help make
+the DNS more robust.  You should have at least one secondary server for
+your site, but you do not need to be a secondary server for anyone else.
+You can by all means, but you don't need to be.  If you want to be a
+secondary server for another domain, then place the line
+
+secondary         gu.uwa.edu.au   130.95.100.3 130.95.128.1
+
+in your named.boot.  This will make your named try the servers on both of
+the machines specified to see if it can obtain the information about those
+domains.  You can specify a number of IP addresses for the machines to
+query that probably depends on your machine.  Your copy of named will upon
+startup go and query all the information it can get about the domain in
+question and remember it and act as though it were authoritive for that
+domain.
+
+Next you will want to start creating the data files that contain the name
+definitions.
+
+The cache file:
+
+You can get a copy of the cache file from FTP.RS.INTERNIC.NET.  The current
+copy can be found in Appendix A.
+
+The Forward Mapping file:
+The file ecel.uwa.edu.au. will be used for the example with a couple of
+machines left in for the purpose of the exercise.  Here is a copy of what
+the file looks like with explanations following.
+
+; Authoritative data for ecel.uwa.edu.au
+;
+@		IN	SOA decel.ecel.uwa.edu.au. postmaster.ecel.uwa.edu.au. (
+				93071200	; Serial (yymmddxx)
+				10800		; Refresh 3 hours
+				3600		; Retry   1 hour
+				3600000 	; Expire  1000 hours
+				86400 )		; Minimum 24 hours
+		IN	A		130.95.4.2
+		IN	MX	100  	decel
+		IN	MX	150	uniwa.uwa.edu.au.
+		IN	MX	200	relay1.uu.net.
+		IN	MX	200	relay2.uu.net.
+
+localhost	IN	A		127.0.0.1
+
+decel		IN	A		130.95.4.2
+		IN	HINFO	SUN4/110	 UNIX
+		IN	MX	100	decel
+		IN	MX	150	uniwa.uwa.edu.au.
+		IN	MX	200	relay1.uu.net
+		IN	MX	200	relay2.uu.net
+
+gopher		IN	CNAME		decel.ecel.uwa.edu.au.
+
+accfin		IN	A		130.95.4.3
+		IN	HINFO	SUN4/110	 UNIX
+		IN	MX	100	decel
+		IN	MX	150	uniwa.uwa.edu.au.
+		IN	MX	200	relay1.uu.net
+		IN	MX	200	relay2.uu.net
+
+chris-mac	IN	A		130.95.4.5
+		IN	HINFO	MAC-II	MACOS
+
+The comment character is ';' so the first two lines are just comments
+indicating the contents of the file.
+
+All values from here on have IN in them.  This indicates that the value is
+an InterNet record.  There are a couple of other types, but all you need
+concern yourself with is internet ones.
+
+The SOA record is the Start Of Authority record.  It contains the
+information that other nameservers will learn about this domain and how to
+treat the information they are given about it.  The '@' as the first
+character in the line indicates that you wish to define things about the
+domain for which this file is responsible.  The domain name is found in the
+named.boot file in the corresponding line to this filename.  All
+information listed refers to the most recent machine/domain name so all
+records from the '@' until 'localhost' refer to the '@'.  The SOA record
+has 5 magic numbers.  First magic number is the serial number.  If you
+change the file, change the serial number.  If you don't, no other name
+servers will update their information.  The old information will sit around
+for a very long time.
+
+Refresh is the time between refreshing information about the SOA (correct
+me if I am wrong).  Retry is the frequency of retrying if an authorative
+server cannot be contacted.  Expire is how long a secondary name server
+will keep information about a zone without successfully updating it or
+confirming that the data is up to date.  This is to help the information
+withstand fairly lengthy downtimes of machines or connections in the
+network without having to recollect all the information.  Minimum is the
+default time to live value handed out by a nameserver for all records in
+a zone without an explicit TTL value. This is how long the data will live
+after being handed out.  The two pieces of information before the 5 magic
+numbers are the machine that is considered the origin of all of this
+information.  Generally the machine that is running your named is a good
+one for here.  The second is an email address for someone who can fix any
+problems that may occur with the DNS.  Good ones here are postmaster,
+hostmaster or root.  NOTE: You use dots and not '@' for the email address.
+
+eg  root.decel.ecel.uwa.edu.au is correct
+     and
+    root@decel.ecel.uwa.edu.au is incorrect.
+
+We now have an address to map ecel.uwa.edu.au to.  The address is
+130.95.4.2 which happens to be decel, our main machine.  If you try to find
+an IP number for the domain ecel.uwa.edu.au it will get you the machine
+decel.ecel.uwa.edu.au's IP number.  This is a nicety which means that
+people who have non-MX record mailers can still mail fred@ecel.uwa.edu.au
+and don't have to find the name of a machine name under the domain to mail.
+
+Now we have a couple of MX records for the domain itself.  The MX records
+specify where to send mail destined for the machine/domain that the MX
+record is for.  In this case we would prefer if all mail for
+fred@ecel.uwa.edu.au is sent to decel.ecel.uwa.edu.au.  If that does not
+work, we would like it to go to uniwa.uwa.edu.au because there are a number
+of machines that might have no idea how to get to us, but may be able to get
+to uniwa.  And failing that, try the site relay1.uu.net.  A small number
+indicates that this site should be tried first.  The larget the number the
+further down the list of sites to try the site is.  NOTE: Not all machines
+have mailers that pay attention to MX records.  Some only pay attention to
+IP numbers, which is really stupid.  All machines are required to have
+MX-capable Mail Transfer Agents (MTA) as there are many addresses that can
+only be reached via this means.
+
+There is an entry for localhost now.  Note that this is somewhat of a
+kludge and should probably be handled far more elegantly.  By placing
+localhost here, a machine comes into existance called
+localhost.ecel.uwa.edu.au.  If you finger it, or telnet to it, you get your
+own machine, because the name lookup returns 127.0.0.1 which is the special
+case for your own machine.  I have used a couple of different DNS packages.
+The old BSD one let you put things into the cache which would always work,
+but would not be exported to other nameservers.  In the newer Sun one, they
+are left in the cache and are mostly ignored once named is up and running.
+This isn't a bad solution, its just not a good one.
+
+Decel is the main machine in our domain.  It has the IP number 130.95.4.2
+and that is what this next line shows.  It also has a HINFO entry.  HINFO
+is Host Info which is meant to be some sort of an indication of what the
+machine is and what it runs.  The values are two white space seperated
+values.  First being the hardware and second being the software.  HINFO is
+not compulsory, its just nice to have sometimes.  We also have some MX
+records so that mail destined for decel has some other avenues before it
+bounces back to the sender if undeliverable.
+
+It is a good idea to give all machines capable of handling mail an MX
+record because this can be cached on remote machines and will help to
+reduce the load on the network.
+
+gopher.ecel.uwa.edu.au is the gopher server in our division.  Now because
+we are cheapskates and don't want to go and splurge on a seperate machine
+just for handling gopher requests we have made it a CNAME to our main
+machine.  While it may seem pointless it does have one main advantage.
+When we discover that our placing terrabytes of popular quicktime movies
+on our gopher server (no we haven't and we don't intend to) causes an
+unbearable load on our main machine, we can quickly move the CNAME to
+point at a new machine by changing the name mentioned in the CNAME.  Then
+the slime of the world can continue to get their essential movies with a
+minimal interuption to the network.  Other good CNAMEs to maintain are
+things like ftp, mailhost, netfind, archie, whois, and even dns (though the
+most obvious use for this fails).  It also makes it easier for people to
+find these services in your domain.
+
+We should probably start using WKS records for things like gopher and whois
+rather than making DNS names for them.  The tools are not in wide
+circulation for this to work though.  (Plus all those comments in many DNS
+implementation of "Not implemented" next to the WKS record)
+
+Finally we have a macintosh which belongs to my boss.  All it needs is an
+IP number, and we have included the HINFO so that you can see that it is in
+fact a macII running a Mac System.  To get the list of preferred values,
+you should get a copy of RFC 1340.  It lists lots of useful information
+such as /etc/services values, ethernet manufacturer hardware addresses,
+HINFO defualts and many others.  I will include the list as it stands at
+the moment, but if any RFC superceeds 1340, then it will have a more
+complete list.  See Appendix B for that list.
+
+NOTE:  If Chris had a very high profile and wanted his mac to appear like a
+fully connected unix machine as far as internet services were concerned, he
+could simply place an MX record such as 
+
+	IN	MX	100  decel
+
+after his machine and any mail sent to chris@chris-mac.ecel.uwa.edu.au
+would be automatically rerouted to decel.
+
+The Reverse Mapping File
+
+The reverse name lookup is handled in a most bizarre fashion.  Well it all
+makes sense, but it is not immediately obvious.
+
+All of the reverse name lookups are done by finding the PTR record
+associated with the name w.x.y.z.in-addr.arpa.  So to find the name
+associated with the IP number 1.2.3.4, we look for information stored in
+the DNS under the name 4.3.2.1.in-addr.arpa.  They are organised this way
+so that when you are allocated a B class subnet for example, you get all of
+the IP numbers in the domain 130.95.  Now to turn that into a reverse name
+lookup domain, you have to invert the numbers or your registered domains
+will be spread all over the place.  It is a mess and you need not understand
+the finer points of it all.  All you need to know is that you put the
+reverse name lookup files back to front.
+
+Here is the sample reverse name lookup files to go with our example.
+
+0.0.127.in-addr.arpa
+--
+;  Reverse mapping of domain names 0.0.127.in-addr.arpa
+;  Nobody pays attention to this, it is only so 127.0.0.1 -> localhost.
+@		IN	SOA decel.ecel.uwa.edu.au. postmaster.ecel.uwa.edu.au. (
+				91061801	; Serial (yymmddxx)
+				10800		; Refresh 3 hours
+				3600		; Retry   1 hour
+				3600000 	; Expire  1000 hours
+				86400 )		; Minimum 24 hours
+;
+1		IN	PTR	    localhost.ecel.uwa.edu.au.
+--
+
+4.95.130.in-addr.arpa
+--
+;	reverse mapping of domain names 4.95.130.in-addr.arpa
+;
+@		IN	SOA decel.ecel.uwa.edu.au. postmaster.ecel.uwa.edu.au. (
+				92050300	; Serial (yymmddxx format)
+				10800		; Refresh	3hHours
+				3600		; Retry		1 hour
+				3600000		; Expire	1000 hours
+				86400 )		; Minimum	24 hours
+2		IN	PTR	decel.ecel.uwa.edu.au.
+3		IN	PTR	accfin.ecel.uwa.edu.au.
+5		IN	PTR	chris-mac.ecel.uwa.edu.au.
+--
+
+It is important to remember that you must have a second start of authority
+record for the reverse name lookups.  Each reverse name lookup file must
+have its own SOA record.  The reverse name lookup on the 127 domain is
+debatable seeing as there is likely to be only one number in the file and
+it is blatantly obvious what it is going to map to.
+
+The SOA details are the same as in the forward mapping.
+
+Each of the numbers listed down the left hand side indicates that the line
+contains information for that number of the subnet.  Each of the subnets
+must be the more significant digits.  eg the 130.95.4 of an IP number
+130.95.4.2 is implicit for all numbers mentioned in the file.
+
+The PTR must point to a machine that can be found in the DNS.  If the name
+is not in the DNS, some versions of named just bomb out at this point.
+
+Reverse name lookups are not compulsory, but nice to have.  It means that
+when people log into machines, they get names indicating where they are
+logged in from.  It makes it easier for you to spot things that are wrong
+and it is far less cryptic than having lots of numbers everywhere.  Also if
+you do not have a name for your machine, some brain dead protocols such as
+talk will not allow you to connect.
+
+Since I had this I had one suggestion of an alternative way to do the
+localhost entry.  I think it is a matter of personal opinion so I'll
+include it here in case anyone things that this is a more appropriate
+method.
+
+The following is courtesy of jep@convex.nl (JEP de Bie)
+
+  The way I did it was:
+
+  1) add in /etc/named.boot:
+
+     primary   .                             localhost
+     primary   127.in-addr.ARPA.             IP127
+
+(Craig: It has been suggested by Mark Andrews that this is a bad practice
+ particularly if you have upgraded to Bind 4.9.  You also run the risk of
+ polluting the root name servers.  This comes down to a battle of idealogy
+ and practicality.  Think twice before declaring yourself authorative for
+ the root domain.)
+
+  So I not only declare myself (falsely? - probably, but nobody is going to
+  listen anyway most likely [CPR]:-) athorative in the 127.in-addr.ARPA domain
+  but also in the . (root) domain.
+
+  2) the file localhost has:
+
+     $ORIGIN .
+     localhost       IN      A       127.0.0.1
+
+  3) and the file IP127:
+
+     $ORIGIN 127.in-addr.ARPA.
+     1.0.0   IN      PTR     localhost.
+
+  4) and I have in my own domain file (convex.nl) the line:
+
+     $ORIGIN convex.nl.
+     localhost       IN      CNAME   localhost.
+
+  The advantage (elegancy?) is that a query (A) of localhost. gives the
+  reverse of the query of 1.0.0.127.in-addr.ARPA. And it also shows that
+  localhost.convex.nl is only a nickname to something more absolute.
+  (While the notion of localhost is of course relative :-)).
+
+  And I also think there is a subtle difference between the lines
+
+    primary   127.in-addr.ARPA.             IP127
+      and
+    primary   0.0.127.in-addr.ARPA.         4.95.130.domain
+                                        =============
+                                         JEP de Bie
+                                        jep@convex.nl
+                                        =============
+
+
+
+Delegating authority for domains within your domain:
+
+When you start having a very big domain that can be broken into logical and
+seperate entities that can look after their own DNS information, you will
+probably want to do this.  Maintain a central area for the things that
+everyone needs to see and delegate the authority for the other parts of the
+organisation so that they can manage themselves.
+
+Another essential piece of information is that every domain that exists
+must have it NS records associated with it.  These NS records denote the
+name servers that are queried for information about that zone.  For your
+zone to be recognised by the outside world, the server responsible for the
+zone above you must have created a NS record for your machine in your
+domain.  For example, putting the computer club onto the network and giving
+them control over their own part of the domain space we have the following.
+
+The machine authorative for gu.uwa.edu.au is mackerel and the machine
+authorative for ucc.gu.uwa.edu.au is marlin.
+
+in mackerel's data for gu.uwa.edu.au we have the following
+
+@		IN	SOA ...
+		IN	A	130.95.100.3
+		IN	MX	mackerel.gu.uwa.edu.au.
+		IN	MX	uniwa.uwa.edu.au.
+
+marlin		IN	A	130.95.100.4
+
+ucc		IN	NS	marlin.gu.uwa.edu.au.
+		IN	NS	mackerel.gu.uwa.edu.au.
+
+Marlin is also given an IP in our domain as a convenience.  If they blow up
+their name serving there is less that can go wrong because people can still
+see that machine which is a start.  You could place "marlin.ucc" in the
+first column and leave the machine totally inside the ucc domain as well.
+
+The second NS line is because mackerel will be acting as secondary name
+server for the ucc.gu domain.  Do not include this line if you are not
+authorative for the information included in the sub-domain.
+
+
+Troubleshooting your named:
+
+Named doesn't work!  What is wrong?
+
+Step 1:  Run nslookup and see what nameserver it tries to connect you to.
+If nslookup connects you to the wrong nameserver, create a /etc/resolv.conf
+file that points your machine at the correct nameserver.  If there is no
+resolv.conf file, the the resolver uses the nameserver on the local
+machine.
+
+Step 2:  Make sure that named is actually running.
+
+Step 3:  Restart named and see if you get any error messages on the
+console and in also check /usr/adm/messages.
+
+Step 4:  If named is running, nslookup connects to the appropriate
+nameserver and nslookup can answer simple questions, but other programs
+such as 'ping' do not work with names, then you need to install resolv+
+most likely.
+
+
+I changed my named database and my local machine has noticed, but nobody
+else has the new information?
+
+Change the serial number in the SOA for any domains that you modified and
+restart named.  Wait an hour and check again.  The information propogates
+out.  It won't change immediately.
+
+
+My local machine knows about all the name server information, but no other
+sites know about me?
+
+Find an upstream nameserver (one that has an SOA for something in your
+domain) and ask them to be a secondary name server for you.  eg if you are
+ecel.uwa.edu.au, ask someone who has an SOA for the domain uwa.edu.au.
+Get NS records (and glue) added to your parent zone for your zone. This is
+called delegating. It should be done formally like this or you will get
+inconsistant answers out of the DNS.  ALL NAMSERVERS FOR YOUR ZONE SHOULD
+BE LISTED IN THIS MANNER.
+
+
+My forward domain names work, but the backward names do not?
+
+Make sure the numbers are back to front and have the in-addr.arpa on the
+end.
+Make sure you reverse zone is registered. For Class C nets this can be done
+by mailing to hostmaster@internic.net. For class A & B nets make sure that
+you are registeres with the primary for your net and that the net itself
+is registered with hostmaster@internic.net.
+
+
+How to get useful information from nslookup:
+
+Nslookup is a very useful program but I'm sure there are less than 20
+people worldwide who know how to use it to its full usefulness.  I'm most
+certainly not one of them.  If you don't like using nslookup, there is at
+least one other program called dig, that has most/all(?) of the
+functionality of nslookup and is a hell of a lot easier to use.
+
+I won't go into dig much here except to say that it is a lot easier to get
+this information out of.  I won't bother because nslookup ships with almost
+all machines that come with network software.
+
+To run nslookup, you usually just type nslookup.  It will tell you the
+server it connects to.  You can specify a different server if you want.
+This is useful when you want to tell if your named information is
+consistent with other servers.
+
+Getting name to number mappings.
+
+Type the name of the machine.  Typing 'decel' is enough if the machine is
+local.
+
+(Once you have run nslookup successfully)
+> decel
+Server:  ecel.uwa.edu.au
+Address:  130.95.4.2
+
+Name:    decel.ecel.uwa.edu.au
+Address:  130.95.4.2
+
+>
+
+One curious quirk of some name resolvers is that if you type a
+machine name, they will try a number of permutations.  For example if my
+machine is in the domain ecel.uwa.edu.au and I try to find a machine
+called fred, the resolver will try the following.
+
+  fred.ecel.uwa.edu.au.
+  fred.uwa.edu.au.
+  fred.edu.au.
+  fred.au.
+  fred.
+
+This can be useful, but more often than not, you would simply prefer a good
+way to make aliases for machines that are commonly referenced.  If you are
+running resolv+, you should just be able to put common machines into the
+host file.
+
+DIG: dig <machine name>
+
+Getting number to name mappings.
+
+Nslookup defaults to finding you the Address of the name specified.  For
+reverse lookups you already have the address and you want to find the
+name that goes with it.  If you read and understood the bit above where it
+describes how to create the number to name mapping file, you would guess
+that you need to find the PTR record instead of the A record.  So you do
+the following.
+
+> set type=ptr
+> 2.4.95.130.in-addr.arpa
+Server:  decel.ecel.uwa.edu.au
+Address:  130.95.4.2
+
+2.4.95.130.in-addr.arpa host name = decel.ecel.uwa.edu.au
+>
+
+nslookup tells you that the ptr for the machine name
+2.4.95.130.in-addr.arpa points to the host decel.ecel.uwa.edu.au.
+
+DIG: dig -x <machine number>
+
+Finding where mail goes when a machine has no IP number.
+
+When a machine is not IP connected, it needs to specify to the world, where
+to send the mail so that it can dial up and collect it every now and then.
+This is accomplished by setting up an MX record for the site and not giving
+it an IP number.  To get the information out of nslookup as to where the
+mail goes, do the following.
+
+> set type=mx
+> dialix.oz.au
+Server:  decel.ecel.uwa.oz.au
+Address:  130.95.4.2
+
+Non-authoritative answer:
+dialix.oz.au    preference = 100, mail exchanger = uniwa.uwa.OZ.AU
+dialix.oz.au    preference = 200, mail exchanger = munnari.OZ.AU
+Authoritative answers can be found from:
+uniwa.uwa.OZ.AU inet address = 130.95.128.1
+munnari.OZ.AU   inet address = 128.250.1.21
+munnari.OZ.AU   inet address = 192.43.207.1
+mulga.cs.mu.OZ.AU       inet address = 128.250.35.21
+mulga.cs.mu.OZ.AU       inet address = 192.43.207.2
+dmssyd.syd.dms.CSIRO.AU inet address = 130.155.16.1
+ns.UU.NET       inet address = 137.39.1.3
+
+You tell nslookup that you want to search for mx records and then you give
+it the name of the machine.  It tells you the preference for the mail
+(small means more preferable), and who the mail should be sent to.  It also
+includes sites that are authorative (have this name in their named database
+files) for this MX record.  There are multiple sites as a backup.  As can
+be seen, our local public internet access company dialix would like all of
+their mail to be sent to uniwa, where they collect it from.  If uniwa is
+not up, send it to munnari and munnari will get it to uniwa eventually.
+
+NOTE: For historical reasons Australia used to be .oz which was changed to
+.oz.au to move to the ISO standard extensions upon the advent of IP.  We
+are now moving to a more normal heirarchy which is where the .edu.au comes
+from.  Pity, I liked having oz.
+
+DIG: dig <zone> mx
+
+Getting a list of machines in a domain from nslookup.
+
+Find a server that is authorative for the domain or just generally all
+knowing.  To find a good server, find all the soa records for a given
+domain.  To do this, you set type=soa and enter the domain just like in the
+two previous examples.
+
+Once you have a server type 
+
+> ls gu.uwa.edu.au.
+[uniwa.uwa.edu.au]
+Host or domain name            Internet address
+ gu                             server = mackerel.gu.uwa.edu.au
+ gu                             server = uniwa.uwa.edu.au
+ gu                             130.95.100.3
+ snuffle-upagus                 130.95.100.131
+ mullet                         130.95.100.2
+ mackerel                       130.95.100.3
+ marlin                         130.95.100.4
+ gugate                         130.95.100.1
+ gugate                         130.95.100.129
+ helpdesk                       130.95.100.180
+ lan                            130.95.100.0
+ big-bird                       130.95.100.130
+
+To get a list of all the machines in the domain.
+
+If you wanted to find a list of all of the MX records for the domain, you
+can put a -m flag in the ls command.
+
+> ls -m gu.uwa.edu.au.
+[uniwa.uwa.edu.au]
+Host or domain name            Metric Host
+ gu                             100  mackerel.gu.uwa.edu.au
+ gu                             200  uniwa.uwa.edu.au
+
+This only works for a limited selection of the different types.
+
+DIG: dig axfr <zone> @<server>
+
+
+
+Appendix A
+
+
+;
+;       This file holds the information on root name servers needed to
+;       initialize cache of Internet domain name servers
+;       (e.g. reference this file in the "cache  .  <file>"
+;       configuration file of BIND domain name servers).
+;
+;       This file is made available by InterNIC registration services
+;       under anonymous FTP as
+;           file                /domain/named.root
+;           on server           FTP.RS.INTERNIC.NET
+;       -OR- under Gopher at RS.INTERNIC.NET
+;           under menu          InterNIC Registration Services (NSI)
+;              submenu          InterNIC Registration Archives
+;           file                named.root
+;
+;       last update:    April 21, 1993
+;       related version of root zone:   930421
+;
+.                        99999999 IN  NS    NS.INTERNIC.NET.
+NS.INTERNIC.NET.         99999999     A     198.41.0.4
+.                        99999999     NS    KAVA.NISC.SRI.COM.
+KAVA.NISC.SRI.COM.       99999999     A     192.33.33.24
+.                        99999999     NS    C.NYSER.NET.
+C.NYSER.NET.             99999999     A     192.33.4.12
+.                        99999999     NS    TERP.UMD.EDU.
+TERP.UMD.EDU.            99999999     A     128.8.10.90
+.                        99999999     NS    NS.NASA.GOV.
+NS.NASA.GOV.             99999999     A     128.102.16.10
+                         99999999     A     192.52.195.10
+.                        99999999     NS    NS.NIC.DDN.MIL.
+NS.NIC.DDN.MIL.          99999999     A     192.112.36.4
+.                        99999999     NS    AOS.ARL.ARMY.MIL.
+AOS.ARL.ARMY.MIL.        99999999     A     128.63.4.82
+                         99999999     A     192.5.25.82
+.                        99999999     NS    NIC.NORDU.NET.
+NIC.NORDU.NET.           99999999     A     192.36.148.17
+; End of File
+
+
+Appendix B
+
+An Excerpt from
+RFC 1340		    Assigned Numbers		       July 1992
+
+
+			       MACHINE NAMES
+
+   These are the Official Machine Names	as they	appear in the Domain Name
+   System HINFO	records	and the	NIC Host Table.	 Their use is described	in
+   RFC-952 [53].
+
+   A machine name or CPU type may be up	to 40 characters taken from the
+   set of uppercase letters, digits, and the two punctuation characters
+   hyphen and slash.  It must start with a letter, and end with	a letter
+   or digit.
+
+      ALTO				    DEC-1080
+      ALTOS-6800			    DEC-1090
+      AMDAHL-V7				    DEC-1090B
+      APOLLO				    DEC-1090T
+      ATARI-104ST			    DEC-2020T
+      ATT-3B1				    DEC-2040
+      ATT-3B2				    DEC-2040T
+      ATT-3B20				    DEC-2050T
+      ATT-7300				    DEC-2060
+      BBN-C/60				    DEC-2060T
+      BURROUGHS-B/29			    DEC-2065
+      BURROUGHS-B/4800			    DEC-FALCON
+      BUTTERFLY				    DEC-KS10
+      C/30				    DEC-VAX-11730
+      C/70				    DORADO
+      CADLINC				    DPS8/70M
+      CADR				    ELXSI-6400
+      CDC-170				    EVEREX-386
+      CDC-170/750			    FOONLY-F2
+      CDC-173				    FOONLY-F3
+      CELERITY-1200			    FOONLY-F4
+      CLUB-386				    GOULD
+      COMPAQ-386/20			    GOULD-6050
+      COMTEN-3690			    GOULD-6080
+      CP8040				    GOULD-9050
+      CRAY-1				    GOULD-9080
+      CRAY-X/MP				    H-316
+      CRAY-2				    H-60/68
+      CTIWS-117				    H-68
+      DANDELION				    H-68/80
+      DEC-10				    H-89
+      DEC-1050				    HONEYWELL-DPS-6
+      DEC-1077				    HONEYWELL-DPS-8/70
+      HP3000				    ONYX-Z8000
+      HP3000/64				    PDP-11
+      IBM-158				    PDP-11/3
+      IBM-360/67			    PDP-11/23
+      IBM-370/3033			    PDP-11/24
+      IBM-3081				    PDP-11/34
+      IBM-3084QX			    PDP-11/40
+      IBM-3101				    PDP-11/44
+      IBM-4331				    PDP-11/45
+      IBM-4341				    PDP-11/50
+      IBM-4361				    PDP-11/70
+      IBM-4381				    PDP-11/73
+      IBM-4956				    PE-7/32
+      IBM-6152				    PE-3205
+      IBM-PC				    PERQ
+      IBM-PC/AT				    PLEXUS-P/60
+      IBM-PC/RT				    PLI
+      IBM-PC/XT				    PLURIBUS
+      IBM-SERIES/1			    PRIME-2350
+      IMAGEN				    PRIME-2450
+      IMAGEN-8/300			    PRIME-2755
+      IMSAI				    PRIME-9655
+      INTEGRATED-SOLUTIONS		    PRIME-9755
+      INTEGRATED-SOLUTIONS-68K		    PRIME-9955II
+      INTEGRATED-SOLUTIONS-CREATOR	    PRIME-2250
+      INTEGRATED-SOLUTIONS-CREATOR-8	    PRIME-2655
+      INTEL-386				    PRIME-9955
+      INTEL-IPSC			    PRIME-9950
+      IS-1				    PRIME-9650
+      IS-68010				    PRIME-9750
+      LMI				    PRIME-2250
+      LSI-11				    PRIME-750
+      LSI-11/2				    PRIME-850
+      LSI-11/23				    PRIME-550II
+      LSI-11/73				    PYRAMID-90
+      M68000				    PYRAMID-90MX
+      MAC-II				    PYRAMID-90X
+      MASSCOMP				    RIDGE
+      MC500				    RIDGE-32
+      MC68000				    RIDGE-32C
+      MICROPORT				    ROLM-1666
+      MICROVAX				    S1-MKIIA
+      MICROVAX-I			    SMI
+      MV/8000				    SEQUENT-BALANCE-8000
+      NAS3-5				    SIEMENS
+      NCR-COMTEN-3690			    SILICON-GRAPHICS
+      NEXT/N1000-316			    SILICON-GRAPHICS-IRIS
+      NOW				    SGI-IRIS-2400
+      SGI-IRIS-2500			    SUN-3/50
+      SGI-IRIS-3010			    SUN-3/60
+      SGI-IRIS-3020			    SUN-3/75
+      SGI-IRIS-3030			    SUN-3/80
+      SGI-IRIS-3110			    SUN-3/110
+      SGI-IRIS-3115			    SUN-3/140
+      SGI-IRIS-3120			    SUN-3/150
+      SGI-IRIS-3130			    SUN-3/160
+      SGI-IRIS-4D/20			    SUN-3/180
+      SGI-IRIS-4D/20G			    SUN-3/200
+      SGI-IRIS-4D/25			    SUN-3/260
+      SGI-IRIS-4D/25G			    SUN-3/280
+      SGI-IRIS-4D/25S			    SUN-3/470
+      SGI-IRIS-4D/50			    SUN-3/480
+      SGI-IRIS-4D/50G			    SUN-4/60
+      SGI-IRIS-4D/50GT			    SUN-4/110
+      SGI-IRIS-4D/60			    SUN-4/150
+      SGI-IRIS-4D/60G			    SUN-4/200
+      SGI-IRIS-4D/60T			    SUN-4/260
+      SGI-IRIS-4D/60GT			    SUN-4/280
+      SGI-IRIS-4D/70			    SUN-4/330
+      SGI-IRIS-4D/70G			    SUN-4/370
+      SGI-IRIS-4D/70GT			    SUN-4/390
+      SGI-IRIS-4D/80GT			    SUN-50
+      SGI-IRIS-4D/80S			    SUN-100
+      SGI-IRIS-4D/120GTX		    SUN-120
+      SGI-IRIS-4D/120S			    SUN-130
+      SGI-IRIS-4D/210GTX		    SUN-150
+      SGI-IRIS-4D/210S			    SUN-170
+      SGI-IRIS-4D/220GTX		    SUN-386i/250
+      SGI-IRIS-4D/220S			    SUN-68000
+      SGI-IRIS-4D/240GTX		    SYMBOLICS-3600
+      SGI-IRIS-4D/240S			    SYMBOLICS-3670
+      SGI-IRIS-4D/280GTX		    SYMMETRIC-375
+      SGI-IRIS-4D/280S			    SYMULT
+      SGI-IRIS-CS/12			    TANDEM-TXP
+      SGI-IRIS-4SERVER-8		    TANDY-6000
+      SPERRY-DCP/10			    TEK-6130
+      SUN				    TI-EXPLORER
+      SUN-2				    TP-4000
+      SUN-2/50				    TRS-80
+      SUN-2/100				    UNIVAC-1100
+      SUN-2/120				    UNIVAC-1100/60
+      SUN-2/130				    UNIVAC-1100/62
+      SUN-2/140				    UNIVAC-1100/63
+      SUN-2/150				    UNIVAC-1100/64
+      SUN-2/160				    UNIVAC-1100/70
+      SUN-2/170				    UNIVAC-1160
+      UNKNOWN
+      VAX-11/725
+      VAX-11/730
+      VAX-11/750
+      VAX-11/780
+      VAX-11/785
+      VAX-11/790
+      VAX-11/8600
+      VAX-8600
+      WANG-PC002
+      WANG-VS100
+      WANG-VS400
+      WYSE-386
+      XEROX-1108
+      XEROX-8010
+      ZENITH-148
+
+			       SYSTEM NAMES
+
+   These are the Official System Names as they appear in the Domain Name
+   System HINFO	records	and the	NIC Host Table.	 Their use is described
+   in RFC-952 [53].
+
+   A system name may be	up to 40 characters taken from the set of upper-
+   case	letters, digits, and the three punctuation characters hyphen,
+   period, and slash.  It must start with a letter, and	end with a
+   letter or digit.
+
+   AEGIS		     LISP		       SUN OS 3.5
+   APOLLO		     LISPM		       SUN OS 4.0
+   AIX/370		     LOCUS		       SWIFT
+   AIX-PS/2		     MACOS		       TAC
+   BS-2000		     MINOS		       TANDEM
+   CEDAR		     MOS		       TENEX
+   CGW			     MPE5		       TOPS10
+   CHORUS		     MSDOS		       TOPS20
+   CHRYSALIS		     MULTICS		       TOS
+   CMOS			     MUSIC		       TP3010
+   CMS			     MUSIC/SP		       TRSDOS
+   COS			     MVS		       ULTRIX
+   CPIX			     MVS/SP		       UNIX
+   CTOS			     NEXUS		       UNIX-BSD
+   CTSS			     NMS		       UNIX-V1AT
+   DCN			     NONSTOP		       UNIX-V
+   DDNOS		     NOS-2		       UNIX-V.1
+   DOMAIN		     NTOS		       UNIX-V.2
+   DOS			     OS/DDP		       UNIX-V.3
+   EDX			     OS/2		       UNIX-PC
+   ELF			     OS4		       UNKNOWN
+   EMBOS		     OS86		       UT2D
+   EMMOS		     OSX		       V
+   EPOS			     PCDOS		       VM
+   FOONEX		     PERQ/OS		       VM/370
+   FUZZ			     PLI		       VM/CMS
+   GCOS			     PSDOS/MIT		       VM/SP
+   GPOS			     PRIMOS		       VMS
+   HDOS			     RMX/RDOS		       VMS/EUNICE
+   IMAGEN		     ROS		       VRTX
+   INTERCOM		     RSX11M		       WAITS
+   IMPRESS		     RTE-A		       WANG
+   INTERLISP		     SATOPS		       WIN32
+   IOS			     SCO-XENIX/386	       X11R3
+   IRIX			     SCS		       XDE
+   ISI-68020		     SIMP		       XENIX
+   ITS			     SUN
+
+
+
+Appendix C     Installing DNS on a Sun when running NIS
+
+====================
+ 2)     How to get DNS to be used when running NIS ?
+
+        First setup the appropriate /etc/resolv.conf file.
+        Something like this should do the "trick".
+
+        ;
+        ; Data file for a client.
+        ;
+        domain          local domain
+        nameserver      address of primary domain nameserver
+        nameserver      address of secondary domain nameserver
+
+        where:  "local domain" is the domain part of the hostnames.
+                 For example, if your hostname is "thor.ece.uc.edu"
+                 your "local domain" is "ece.uc.edu".
+
+        You will need to put a copy of this resolv.conf on
+        all NIS(YP) servers including slaves.
+
+        Under SunOS 4.1 and greater, change the "B=" at the top
+        of the /var/yp/Makefile to "B=-b" and setup NIS in the
+        usual fashion.
+
+        You will need reboot or restart ypserv for these changes
+        to take affect.
+
+        Under 4.0.x, edit the Makefile or apply the following "diff":
+
+*** Makefile.orig       Wed Jan 10 13:22:11 1990
+--- Makefile    Wed Jan 10 13:22:01 1990
+***************
+*** 63 ****
+!                   | $(MAKEDBM) - $(YPDBDIR)/$(DOM)/hosts.byname; \
+--- 63 ----
+!                   | $(MAKEDBM) -b - $(YPDBDIR)/$(DOM)/hosts.byname; \
+***************
+*** 66 ****
+!                   | $(MAKEDBM) - $(YPDBDIR)/$(DOM)/hosts.byaddr; \
+--- 66 ----
+!                   | $(MAKEDBM) -b - $(YPDBDIR)/$(DOM)/hosts.byaddr; \
+====================
+
diff --git a/usr.sbin/named/doc/misc/domain.ps b/usr.sbin/named/doc/misc/domain.ps
new file mode 100644
index 00000000000..61064a7cf82
--- /dev/null
+++ b/usr.sbin/named/doc/misc/domain.ps
@@ -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
diff --git a/usr.sbin/named/doc/misc/purdue-paper.ps b/usr.sbin/named/doc/misc/purdue-paper.ps
new file mode 100644
index 00000000000..d8e7db37bc9
--- /dev/null
+++ b/usr.sbin/named/doc/misc/purdue-paper.ps
@@ -0,0 +1,3424 @@
+%!PS-Adobe-2.0
+%%Creator: dvips 5.485 Copyright 1986-92 Radical Eye Software
+%%Title: main.dvi
+%%Pages: 21 1
+%%BoundingBox: 0 0 612 792
+%%EndComments
+%DVIPSCommandLine: /usr/local/tex/dvips main.dvi
+%%BeginProcSet: tex.pro
+/TeXDict 250 dict def TeXDict begin /N{def}def /B{bind def}N /S{exch}N /X{S N}
+B /TR{translate}N /isls false N /vsize 11 72 mul N /@rigin{isls{[0 -1 1 0 0 0]
+concat}if 72 Resolution div 72 VResolution div neg scale isls{Resolution hsize
+-72 div mul 0 TR}if Resolution VResolution vsize -72 div 1 add mul TR matrix
+currentmatrix dup dup 4 get round 4 exch put dup dup 5 get round 5 exch put
+setmatrix}N /@landscape{/isls true N}B /@manualfeed{statusdict /manualfeed
+true put}B /@copies{/#copies X}B /FMat[1 0 0 -1 0 0]N /FBB[0 0 0 0]N /nn 0 N
+/IE 0 N /ctr 0 N /df-tail{/nn 8 dict N nn begin /FontType 3 N /FontMatrix
+fntrx N /FontBBox FBB N string /base X array /BitMaps X /BuildChar{
+CharBuilder}N /Encoding IE N end dup{/foo setfont}2 array copy cvx N load 0 nn
+put /ctr 0 N[}B /df{/sf 1 N /fntrx FMat N df-tail}B /dfs{div /sf X /fntrx[sf 0
+0 sf neg 0 0]N df-tail}B /E{pop nn dup definefont setfont}B /ch-width{ch-data
+dup length 5 sub get}B /ch-height{ch-data dup length 4 sub get}B /ch-xoff{128
+ch-data dup length 3 sub get sub}B /ch-yoff{ch-data dup length 2 sub get 127
+sub}B /ch-dx{ch-data dup length 1 sub get}B /ch-image{ch-data dup type
+/stringtype ne{ctr get /ctr ctr 1 add N}if}B /id 0 N /rw 0 N /rc 0 N /gp 0 N
+/cp 0 N /G 0 N /sf 0 N /CharBuilder{save 3 1 roll S dup /base get 2 index get
+S /BitMaps get S get /ch-data X pop /ctr 0 N ch-dx 0 ch-xoff ch-yoff ch-height
+sub ch-xoff ch-width add ch-yoff setcachedevice ch-width ch-height true[1 0 0
+-1 -.1 ch-xoff sub ch-yoff .1 add]{ch-image}imagemask restore}B /D{/cc X dup
+type /stringtype ne{]}if nn /base get cc ctr put nn /BitMaps get S ctr S sf 1
+ne{dup dup length 1 sub dup 2 index S get sf div put}if put /ctr ctr 1 add N}
+B /I{cc 1 add D}B /bop{userdict /bop-hook known{bop-hook}if /SI save N @rigin
+0 0 moveto pop}N /eop{SI restore showpage userdict /eop-hook known{eop-hook}
+if}N /@start{userdict /start-hook known{start-hook}if /VResolution X
+/Resolution X 1000 div /DVImag X /IE 256 array N 0 1 255{IE S 1 string dup 0 3
+index put cvn put}for 65781.76 div /vsize X 65781.76 div /hsize X}N /p{show}N
+/RMat[1 0 0 -1 0 0]N /BDot 260 string N /rulex 0 N /ruley 0 N /v{/ruley X
+/rulex X V}B /V statusdict begin /product where{pop product dup length 7 ge{0
+7 getinterval(Display)eq}{pop false}ifelse}{false}ifelse end{{gsave TR -.1 -.1
+TR 1 1 scale rulex ruley false RMat{BDot}imagemask grestore}}{{gsave TR -.1
+-.1 TR rulex ruley scale 1 1 false RMat{BDot}imagemask grestore}}ifelse B /a{
+moveto}B /delta 0 N /tail{dup /delta X 0 rmoveto}B /M{S p delta add tail}B /b{
+S p tail}B /c{-4 M}B /d{-3 M}B /e{-2 M}B /f{-1 M}B /g{0 M}B /h{1 M}B /i{2 M}B
+/j{3 M}B /k{4 M}B /w{0 rmoveto}B /l{p -4 w}B /m{p -3 w}B /n{p -2 w}B /o{p -1 w
+}B /q{p 1 w}B /r{p 2 w}B /s{p 3 w}B /t{p 4 w}B /x{0 S rmoveto}B /y{3 2 roll p
+a}B /bos{/SS save N}B /eos{SS restore}B end
+%%EndProcSet
+%%BeginProcSet: special.pro
+TeXDict begin /SDict 200 dict N SDict begin /@SpecialDefaults{/hs 612 N /vs
+792 N /ho 0 N /vo 0 N /hsc 1 N /vsc 1 N /ang 0 N /CLIP 0 N /rwiSeen false N
+/rhiSeen false N /letter{}N /note{}N /a4{}N /legal{}N}B /@scaleunit 100 N
+/@hscale{@scaleunit div /hsc X}B /@vscale{@scaleunit div /vsc X}B /@hsize{/hs
+X /CLIP 1 N}B /@vsize{/vs X /CLIP 1 N}B /@clip{/CLIP 2 N}B /@hoffset{/ho X}B
+/@voffset{/vo X}B /@angle{/ang X}B /@rwi{10 div /rwi X /rwiSeen true N}B /@rhi
+{10 div /rhi X /rhiSeen true N}B /@llx{/llx X}B /@lly{/lly X}B /@urx{/urx X}B
+/@ury{/ury X}B /magscale true def end /@MacSetUp{userdict /md known{userdict
+/md get type /dicttype eq{userdict begin md length 10 add md maxlength ge{/md
+md dup length 20 add dict copy def}if end md begin /letter{}N /note{}N /legal{
+}N /od{txpose 1 0 mtx defaultmatrix dtransform S atan/pa X newpath clippath
+mark{transform{itransform moveto}}{transform{itransform lineto}}{6 -2 roll
+transform 6 -2 roll transform 6 -2 roll transform{itransform 6 2 roll
+itransform 6 2 roll itransform 6 2 roll curveto}}{{closepath}}pathforall
+newpath counttomark array astore /gc xdf pop ct 39 0 put 10 fz 0 fs 2
+F/|______Courier fnt invertflag{PaintBlack}if}N /txpose{pxs pys scale ppr
+aload pop por{noflips{pop S neg S TR pop 1 -1 scale}if xflip yflip and{pop S
+neg S TR 180 rotate 1 -1 scale ppr 3 get ppr 1 get neg sub neg ppr 2 get ppr 0
+get neg sub neg TR}if xflip yflip not and{pop S neg S TR pop 180 rotate ppr 3
+get ppr 1 get neg sub neg 0 TR}if yflip xflip not and{ppr 1 get neg ppr 0 get
+neg TR}if}{noflips{TR pop pop 270 rotate 1 -1 scale}if xflip yflip and{TR pop
+pop 90 rotate 1 -1 scale ppr 3 get ppr 1 get neg sub neg ppr 2 get ppr 0 get
+neg sub neg TR}if xflip yflip not and{TR pop pop 90 rotate ppr 3 get ppr 1 get
+neg sub neg 0 TR}if yflip xflip not and{TR pop pop 270 rotate ppr 2 get ppr 0
+get neg sub neg 0 S TR}if}ifelse scaleby96{ppr aload pop 4 -1 roll add 2 div 3
+1 roll add 2 div 2 copy TR .96 dup scale neg S neg S TR}if}N /cp{pop pop
+showpage pm restore}N end}if}if}N /normalscale{Resolution 72 div VResolution
+72 div neg scale magscale{DVImag dup scale}if 0 setgray}N /psfts{S 65781.76
+div N}N /startTexFig{/psf$SavedState save N userdict maxlength dict begin
+/magscale false def normalscale currentpoint TR /psf$ury psfts /psf$urx psfts
+/psf$lly psfts /psf$llx psfts /psf$y psfts /psf$x psfts currentpoint /psf$cy X
+/psf$cx X /psf$sx psf$x psf$urx psf$llx sub div N /psf$sy psf$y psf$ury
+psf$lly sub div N psf$sx psf$sy scale psf$cx psf$sx div psf$llx sub psf$cy
+psf$sy div psf$ury sub TR /showpage{}N /erasepage{}N /copypage{}N /p 3 def
+@MacSetUp}N /doclip{psf$llx psf$lly psf$urx psf$ury currentpoint 6 2 roll
+newpath 4 copy 4 2 roll moveto 6 -1 roll S lineto S lineto S lineto closepath
+clip newpath moveto}N /endTexFig{end psf$SavedState restore}N /@beginspecial{
+SDict begin /SpecialSave save N gsave normalscale currentpoint TR
+@SpecialDefaults count /ocount X /dcount countdictstack N}N /@setspecial{CLIP
+1 eq{newpath 0 0 moveto hs 0 rlineto 0 vs rlineto hs neg 0 rlineto closepath
+clip}if ho vo TR hsc vsc scale ang rotate rwiSeen{rwi urx llx sub div rhiSeen{
+rhi ury lly sub div}{dup}ifelse scale llx neg lly neg TR}{rhiSeen{rhi ury lly
+sub div dup scale llx neg lly neg TR}if}ifelse CLIP 2 eq{newpath llx lly
+moveto urx lly lineto urx ury lineto llx ury lineto closepath clip}if
+/showpage{}N /erasepage{}N /copypage{}N newpath}N /@endspecial{count ocount
+sub{pop}repeat countdictstack dcount sub{end}repeat grestore SpecialSave
+restore end}N /@defspecial{SDict begin}N /@fedspecial{end}B /li{lineto}B /rl{
+rlineto}B /rc{rcurveto}B /np{/SaveX currentpoint /SaveY X N 1 setlinecap
+newpath}N /st{stroke SaveX SaveY moveto}N /fil{fill SaveX SaveY moveto}N
+/ellipse{/endangle X /startangle X /yrad X /xrad X /savematrix matrix
+currentmatrix N TR xrad yrad scale 0 0 1 startangle endangle arc savematrix
+setmatrix}N end
+%%EndProcSet
+TeXDict begin 40258431 52099146 1000 300 300 @start /Fa 1 49
+df<060F0F0E1E1E1C3C383830707060E0C04008117F910A>48 D E /Fb
+6 119 df<780018001800300030003000370078C0604060606060C0C0C0C0C0C0418063003C00
+0B117E900E>98 D<040C0000000000705898983030606464683006127E910B>105
+D<1C70278C2604260606060C0C0C0C0C0C0C181E3019C01800180030003000FC000F10808A10>
+112 D<73C09C209860980018003000300030003000600060000B0B7E8A0E>114
+D<381048308C309830183030603060306430E431E80E380E0B7E8A12>117
+D<386048608C2098201820304030403040308011000E000B0B7E8A10>I
+E /Fc 12 119 df<07FE03F800E001C000E0010000E0020000E0080001C0100001C0200001C080
+0001C1000003830000038F00000393800003A380000781C0000701C0000700E0000700E0000E00
+70000E0070000E0038000E0038001C003C00FF80FF001D177F961E>75 D<071018F03070607060
+60C060C060C06080C080C480C4C1C446C838700E0E7E8D13>97 D<7C0018001800180018003000
+300030003000678068C070406060C060C060C060C06080C080C08180C10046003C000B177E960F
+>I<07C00C20107020706000C000C000C00080008000C010C02060C03F000C0E7E8D0F>I<07C01C
+20301060106020FFC0C000C000C000C000C010402060C01F000C0E7E8D10>101
+D<0300038003000000000000000000000000001C002400460046008C000C001800180018003100
+3100320032001C0009177F960C>105 D<3E0C0C0C0C181818183030303060606060C0C8C8C8D0
+7007177E960B>108 D<1C3C22462382230346030603060306030C060C060C0C0C081A3019E018
+001800300030003000FC001014808D12>112 D<38F04518463846308C000C000C000C00180018
+0018001800300030000D0E7F8D10>114 D<030003000600060006000600FFC00C000C000C0018
+00180018001800300030803080310031001E000A147F930D>116 D<1C02002606004606004606
+00860C000C0C000C0C000C0C001818001818801818801838800C5900078E00110E7F8D14>I<1C
+04260E4606460686040C040C040C0418081808181018100C6007800F0E7F8D11>I
+E /Fd 3 116 df<007FFC01FF0007800078000780006000078000C0000F000180000F00020000
+0F000400000F000800001E001000001E004000001E008000001E010000003C020000003C040000
+003C1E0000003C3E000000785F000000788F0000007A0F0000007C07800000F807800000F007C0
+0000F003C00000F003C00001E001E00001E001E00001E001E00001E000F00003C000F00003C000
+F80003C000780003C000780007C000FC00FFFC07FF8028227EA129>75 D<3C07E01F0046183061
+8047201880C087401D00E087801E00E087801C00E087001C00E00E003801C00E003801C00E0038
+01C00E003801C01C007003801C007003801C007007001C007007043800E007083800E00E083800
+E00E083800E006107001C006203000C003C026157E942B>109 D<007E00008100030080020180
+06038006030006000007000007F80003FE0001FF00003F00000780000380700380F00300F00300
+E002004004003018000FE00011157E9417>115 D E /Fe 47 124 df<387CFEFFFF7F3B030307
+06060C1C18702008117C8610>44 D<387CFEFEFE7C3807077C8610>46 D<00180000780001F800
+FFF800FFF80001F80001F80001F80001F80001F80001F80001F80001F80001F80001F80001F800
+01F80001F80001F80001F80001F80001F80001F80001F80001F80001F80001F80001F80001F800
+01F8007FFFE07FFFE013207C9F1C>49 D<03FC000FFF003C1FC07007E07C07F0FE03F0FE03F8FE
+03F8FE01F87C01F83803F80003F80003F00003F00007E00007C0000F80001F00003E0000380000
+700000E01801C0180380180700180E00380FFFF01FFFF03FFFF07FFFF0FFFFF0FFFFF015207D9F
+1C>I<00FE0007FFC00F07E01E03F03F03F03F81F83F81F83F81F81F03F81F03F00003F00003E0
+0007C0001F8001FE0001FF000007C00001F00001F80000FC0000FC3C00FE7E00FEFF00FEFF00FE
+FF00FEFF00FC7E01FC7801F81E07F00FFFC001FE0017207E9F1C>I<0000E00001E00003E00003
+E00007E0000FE0001FE0001FE00037E00077E000E7E001C7E00187E00307E00707E00E07E00C07
+E01807E03807E07007E0E007E0FFFFFEFFFFFE0007E00007E00007E00007E00007E00007E00007
+E000FFFE00FFFE17207E9F1C>I<1000201E01E01FFFC01FFF801FFF001FFE001FF8001BC00018
+000018000018000018000019FC001FFF001E0FC01807E01803E00003F00003F00003F80003F838
+03F87C03F8FE03F8FE03F8FC03F0FC03F07007E03007C01C1F800FFF0003F80015207D9F1C>I<
+001F8000FFE003F07007C0F00F01F81F01F83E01F83E01F87E00F07C00007C0000FC0800FC7FC0
+FCFFE0FD80F0FF00F8FE007CFE007CFC007EFC007EFC007EFC007E7C007E7C007E7C007E3C007C
+3E007C1E00F80F00F00783E003FFC000FF0017207E9F1C>I<6000007800007FFFFE7FFFFE7FFF
+FC7FFFF87FFFF87FFFF0E00060E000C0C00180C00300C00300000600000C00001C000018000038
+0000780000780000F00000F00000F00001F00001F00001F00003F00003F00003F00003F00003F0
+0003F00003F00001E00017227DA11C>I<000070000000007000000000F800000000F800000000
+F800000001FC00000001FC00000003FE00000003FE00000003FE00000006FF000000067F000000
+0E7F8000000C3F8000000C3F800000183FC00000181FC00000381FE00000300FE00000300FE000
+00600FF000006007F00000E007F80000FFFFF80000FFFFF800018001FC00018001FC00038001FE
+00030000FE00030000FE000600007F000600007F00FFE00FFFF8FFE00FFFF825227EA12A>65
+D<FFFFFF8000FFFFFFE00007F001F80007F000FC0007F0007E0007F0007E0007F0007F0007F000
+7F0007F0007F0007F0007F0007F0007F0007F0007E0007F000FE0007F000FC0007F003F80007FF
+FFF00007FFFFF00007F001FC0007F0007E0007F0003F0007F0003F8007F0001F8007F0001FC007
+F0001FC007F0001FC007F0001FC007F0001FC007F0001FC007F0003F8007F0003F8007F0007F00
+07F001FE00FFFFFFF800FFFFFFC00022227EA128>I<0003FE0080001FFF818000FF01E38001F8
+003F8003E0001F8007C0000F800F800007801F800007803F000003803F000003807F000001807E
+000001807E00000180FE00000000FE00000000FE00000000FE00000000FE00000000FE00000000
+FE00000000FE000000007E000000007E000001807F000001803F000001803F000003801F800003
+000F8000030007C000060003F0000C0001F800380000FF00F000001FFFC0000003FE000021227D
+A128>I<FFFFFF8000FFFFFFF00007F003FC0007F0007E0007F0003F0007F0001F8007F0000FC0
+07F00007E007F00007E007F00007F007F00003F007F00003F007F00003F007F00003F807F00003
+F807F00003F807F00003F807F00003F807F00003F807F00003F807F00003F807F00003F807F000
+03F007F00003F007F00003F007F00007E007F00007E007F0000FC007F0001F8007F0003F0007F0
+007E0007F003FC00FFFFFFF000FFFFFF800025227EA12B>I<FFFFFFF8FFFFFFF807F001F807F0
+007807F0003807F0001807F0001C07F0001C07F0000C07F0000C07F0180C07F0180C07F0180007
+F0180007F0380007F0780007FFF80007FFF80007F0780007F0380007F0180007F0180007F01800
+07F0180007F0000007F0000007F0000007F0000007F0000007F0000007F0000007F00000FFFFE0
+00FFFFE0001E227EA123>70 D<0003FE0040001FFFC0C0007F00F1C001F8003FC003F0000FC007
+C00007C00FC00003C01F800003C03F000001C03F000001C07F000000C07E000000C07E000000C0
+FE00000000FE00000000FE00000000FE00000000FE00000000FE00000000FE00000000FE000FFF
+FC7E000FFFFC7F00001FC07F00001FC03F00001FC03F00001FC01F80001FC00FC0001FC007E000
+1FC003F0001FC001FC003FC0007F80E7C0001FFFC3C00003FF00C026227DA12C>I<FFFF83FFFE
+FFFF83FFFE07F0001FC007F0001FC007F0001FC007F0001FC007F0001FC007F0001FC007F0001F
+C007F0001FC007F0001FC007F0001FC007F0001FC007F0001FC007F0001FC007FFFFFFC007FFFF
+FFC007F0001FC007F0001FC007F0001FC007F0001FC007F0001FC007F0001FC007F0001FC007F0
+001FC007F0001FC007F0001FC007F0001FC007F0001FC007F0001FC007F0001FC007F0001FC0FF
+FF83FFFEFFFF83FFFE27227EA12C>I<FFFFE0FFFFE003F80003F80003F80003F80003F80003F8
+0003F80003F80003F80003F80003F80003F80003F80003F80003F80003F80003F80003F80003F8
+0003F80003F80003F80003F80003F80003F80003F80003F80003F80003F80003F800FFFFE0FFFF
+E013227FA115>I<FFFF803FFCFFFF803FFC07F000038007F000070007F0000E0007F000180007
+F000300007F000E00007F001C00007F003800007F007000007F00E000007F018000007F0380000
+07F0FC000007F1FE000007F3FE000007F77F000007FE7F800007F83F800007F01FC00007F01FE0
+0007F00FE00007F007F00007F007F80007F003F80007F001FC0007F001FE0007F000FF0007F000
+7F0007F0007F8007F0003FC0FFFF83FFFCFFFF83FFFC26227EA12C>75 D<FFF8001FFEFFFC001F
+FE07FC0000C007FE0000C006FF0000C0067F8000C0063FC000C0061FE000C0060FE000C0060FF0
+00C00607F800C00603FC00C00601FE00C00600FE00C00600FF00C006007F80C006003FC0C00600
+1FE0C006000FF0C0060007F0C0060007F8C0060003FCC0060001FEC0060000FFC00600007FC006
+00007FC00600003FC00600001FC00600000FC006000007C006000003C006000003C0FFF00001C0
+FFF00000C027227EA12C>78 D<0007FC0000003FFF800000FC07E00003F001F80007E000FC000F
+C0007E001F80003F001F80003F003F00001F803F00001F807F00001FC07E00000FC07E00000FC0
+FE00000FE0FE00000FE0FE00000FE0FE00000FE0FE00000FE0FE00000FE0FE00000FE0FE00000F
+E0FE00000FE07E00000FC07F00001FC07F00001FC03F00001F803F80003F801F80003F000FC000
+7E0007E000FC0003F001F80000FC07E000003FFF80000007FC000023227DA12A>I<FFFFFF00FF
+FFFFE007F007F007F001FC07F000FC07F0007E07F0007E07F0007F07F0007F07F0007F07F0007F
+07F0007F07F0007E07F0007E07F000FC07F001FC07F007F007FFFFE007FFFF0007F0000007F000
+0007F0000007F0000007F0000007F0000007F0000007F0000007F0000007F0000007F0000007F0
+000007F00000FFFF8000FFFF800020227EA126>I<01FC0407FF8C1F03FC3C007C7C003C78001C
+78001CF8000CF8000CFC000CFC0000FF0000FFE0007FFF007FFFC03FFFF01FFFF80FFFFC03FFFE
+003FFE0003FF00007F00003F00003FC0001FC0001FC0001FE0001EE0001EF0003CFC003CFF00F8
+C7FFE080FF8018227DA11F>83 D<7FFFFFFF807FFFFFFF807E03F80F807803F807807003F80380
+6003F80180E003F801C0E003F801C0C003F800C0C003F800C0C003F800C0C003F800C00003F800
+000003F800000003F800000003F800000003F800000003F800000003F800000003F800000003F8
+00000003F800000003F800000003F800000003F800000003F800000003F800000003F800000003
+F800000003F800000003F800000003F8000003FFFFF80003FFFFF80022227EA127>I<FFFF803F
+FCFFFF803FFC07F000018007F000018007F000018007F000018007F000018007F000018007F000
+018007F000018007F000018007F000018007F000018007F000018007F000018007F000018007F0
+00018007F000018007F000018007F000018007F000018007F000018007F000018007F000018007
+F000018007F000018003F000030003F800030001F800060000FC000E00007E001C00003F80F800
+000FFFE0000001FF000026227EA12B>I<07FC001FFF803F07C03F03E03F01E03F01F01E01F000
+01F00001F0003FF003FDF01FC1F03F01F07E01F0FC01F0FC01F0FC01F0FC01F07E02F07E0CF81F
+F87F07E03F18167E951B>97 D<00FF8007FFE00F83F01F03F03E03F07E03F07C01E07C0000FC00
+00FC0000FC0000FC0000FC0000FC00007C00007E00007E00003E00301F00600FC0E007FF8000FE
+0014167E9519>99 D<0001FE000001FE0000003E0000003E0000003E0000003E0000003E000000
+3E0000003E0000003E0000003E0000003E0000003E0001FC3E0007FFBE000F81FE001F007E003E
+003E007E003E007C003E00FC003E00FC003E00FC003E00FC003E00FC003E00FC003E00FC003E00
+FC003E007C003E007C003E003E007E001E00FE000F83BE0007FF3FC001FC3FC01A237EA21F>I<
+00FE0007FF800F87C01E01E03E01F07C00F07C00F8FC00F8FC00F8FFFFF8FFFFF8FC0000FC0000
+FC00007C00007C00007E00003E00181F00300FC07003FFC000FF0015167E951A>I<003F8000FF
+C001E3E003C7E007C7E00F87E00F83C00F80000F80000F80000F80000F80000F8000FFFC00FFFC
+000F80000F80000F80000F80000F80000F80000F80000F80000F80000F80000F80000F80000F80
+000F80000F80000F80000F80000F80007FF8007FF80013237FA211>I<03FC1E0FFF7F1F0F8F3E
+07CF3C03C07C03E07C03E07C03E07C03E07C03E03C03C03E07C01F0F801FFF0013FC0030000030
+00003800003FFF801FFFF00FFFF81FFFFC3800FC70003EF0001EF0001EF0001EF0001E78003C7C
+007C3F01F80FFFE001FF0018217E951C>I<FF000000FF0000001F0000001F0000001F0000001F
+0000001F0000001F0000001F0000001F0000001F0000001F0000001F0000001F07E0001F1FF800
+1F307C001F403C001F803E001F803E001F003E001F003E001F003E001F003E001F003E001F003E
+001F003E001F003E001F003E001F003E001F003E001F003E001F003E001F003E00FFE1FFC0FFE1
+FFC01A237EA21F>I<1C003F007F007F007F003F001C000000000000000000000000000000FF00
+FF001F001F001F001F001F001F001F001F001F001F001F001F001F001F001F001F001F001F00FF
+E0FFE00B247EA310>I<FF000000FF0000001F0000001F0000001F0000001F0000001F0000001F
+0000001F0000001F0000001F0000001F0000001F0000001F00FF801F00FF801F0038001F006000
+1F01C0001F0380001F0700001F0E00001F1C00001F7E00001FFF00001FCF00001F0F80001F07C0
+001F03E0001F01E0001F01F0001F00F8001F007C001F003C00FFE0FFC0FFE0FFC01A237EA21E>
+107 D<FF00FF001F001F001F001F001F001F001F001F001F001F001F001F001F001F001F001F00
+1F001F001F001F001F001F001F001F001F001F001F001F001F001F001F00FFE0FFE00B237EA210
+>I<FF07F007F000FF1FFC1FFC001F303E303E001F403E403E001F801F801F001F801F801F001F
+001F001F001F001F001F001F001F001F001F001F001F001F001F001F001F001F001F001F001F00
+1F001F001F001F001F001F001F001F001F001F001F001F001F001F001F001F001F001F001F001F
+001F001F00FFE0FFE0FFE0FFE0FFE0FFE02B167E9530>I<FF07E000FF1FF8001F307C001F403C
+001F803E001F803E001F003E001F003E001F003E001F003E001F003E001F003E001F003E001F00
+3E001F003E001F003E001F003E001F003E001F003E001F003E00FFE1FFC0FFE1FFC01A167E951F
+>I<00FE0007FFC00F83E01E00F03E00F87C007C7C007C7C007CFC007EFC007EFC007EFC007EFC
+007EFC007EFC007E7C007C7C007C3E00F81F01F00F83E007FFC000FE0017167E951C>I<FF0FE0
+00FF3FF8001FF07C001F803E001F001F001F001F801F001F801F000FC01F000FC01F000FC01F00
+0FC01F000FC01F000FC01F000FC01F000FC01F001F801F001F801F803F001FC03E001FE0FC001F
+3FF8001F0FC0001F0000001F0000001F0000001F0000001F0000001F0000001F0000001F000000
+FFE00000FFE000001A207E951F>I<FE1F00FE3FC01E67E01EC7E01E87E01E87E01F83C01F0000
+1F00001F00001F00001F00001F00001F00001F00001F00001F00001F00001F00001F0000FFF000
+FFF00013167E9517>114 D<0FF3003FFF00781F00600700E00300E00300F00300FC00007FE000
+7FF8003FFE000FFF0001FF00000F80C00780C00380E00380E00380F00700FC0E00EFFC00C7F000
+11167E9516>I<0180000180000180000180000380000380000780000780000F80003F8000FFFF
+00FFFF000F80000F80000F80000F80000F80000F80000F80000F80000F80000F80000F80000F81
+800F81800F81800F81800F81800F830007C30003FE0000F80011207F9F16>I<FF01FE00FF01FE
+001F003E001F003E001F003E001F003E001F003E001F003E001F003E001F003E001F003E001F00
+3E001F003E001F003E001F003E001F003E001F003E001F007E001F00FE000F81BE0007FF3FC001
+FC3FC01A167E951F>I<FFE01FE0FFE01FE00F8006000F8006000FC00E0007C00C0007E01C0003
+E0180003E0180001F0300001F0300000F8600000F86000007CC000007CC000007FC000003F8000
+003F8000001F0000001F0000000E0000000E00001B167F951E>I<FFE7FF07F8FFE7FF07F81F00
+7800C00F807801800F807C01800F807C018007C07E030007C0DE030007E0DE070003E0DF060003
+E18F060001F18F0C0001F38F8C0001FB079C0000FB07D80000FE03D800007E03F000007E03F000
+007C01F000003C01E000003800E000001800C00025167F9528>I<FFE07FC0FFE07FC00F801C00
+07C0380003E0700003F0600001F8C00000F98000007F8000003F0000001F0000001F8000003FC0
+000037C0000063E00000C1F00001C0F8000380FC0007007E000E003E00FF80FFE0FF80FFE01B16
+7F951E>I<FFE01FE0FFE01FE00F8006000F8006000FC00E0007C00C0007E01C0003E0180003E0
+180001F0300001F0300000F8600000F86000007CC000007CC000007FC000003F8000003F800000
+1F0000001F0000000E0000000E0000000C0000000C00000018000078180000FC380000FC300000
+FC60000069C000007F8000001F0000001B207F951E>I<FFFFFFE0FFFFFFE01B02808E1C>123
+D E /Ff 30 121 df<7FFFC0FFFFE0FFFFE07FFFC013047D901A>45 D<3078FCFC783006067685
+1A>I<00C001C001C003C007C00FC07FC0FDC071C001C001C001C001C001C001C001C001C001C0
+01C001C001C001C001C001C001C001C001C07FFF7FFF7FFF101E7B9D1A>49
+D<03F0000FFC001FFF003C0F807803C07001C0E000E0F000E0F000E06000E00000E00000E00001
+C00001C0000380000780000F00000E00003C00007C0000F00001E00003C0000780000F00001E00
+E03C00E07FFFE0FFFFE07FFFE0131E7D9D1A>I<01FC0007FF001FFF801E03C03C01C03C00E03C
+00E00000E00000E00001C00003C000078001FF0001FF0001FFC00003E00000F000007000007800
+0038000038600038F00038F00078E000707000F07E03E03FFFC00FFF0001FC00151E7E9D1A>I<
+000F80001F80003B80003B8000738000F38000E38001C38003C3800383800783800F03800E0380
+1E03803C0380380380780380F00380FFFFFEFFFFFEFFFFFE000380000380000380000380000380
+000380003FF8007FFC003FF8171E7F9D1A>I<003E0001FF8003FFC007C1E00F00E01E0F703C3F
+F0387FF07070F870E07870E078E1C038E1C038E1C038E1C038E1C038E1C038E1C038E1C03870E0
+7070E0707070E0387FE03C3FC01E0F000F003807C0F803FFF001FFE0003F00151E7E9D1A>64
+D<003800007C00007C00006C0000EE0000EE0000EE0000C60000C60001C70001C70001C70001C7
+000383800383800383800383800701C00701C007FFC007FFC00FFFE00E00E00E00E00E00E00E00
+E01C00707F01FCFF83FE7F01FC171E7F9D1A>I<1FF0003FFC007FFE00780F0030070000038000
+0380007F8007FF801FFF803F8380780380700380E00380E00380E00380700780780F803FFFFC1F
+FDFC07F0FC16157D941A>97 D<FE0000FE0000FE00000E00000E00000E00000E00000E00000E00
+000E3E000EFF800FFFE00FC1F00F80700F00380E00380E001C0E001C0E001C0E001C0E001C0E00
+1C0E001C0F00380F00780F80F00FC1E00FFFC00EFF80063E00161E7F9D1A>I<00FF8003FFC00F
+FFE01F01E03C00C0780000700000700000E00000E00000E00000E00000E0000070000070000078
+00703C00701F01F00FFFE003FFC000FE0014157D941A>I<001FC0001FC0001FC00001C00001C0
+0001C00001C00001C00001C001F1C007FDC00FFFC01E0FC03C07C07803C07001C0E001C0E001C0
+E001C0E001C0E001C0E001C0E001C07003C07003C03807C03E0FC01FFFFC07FDFC01F1FC161E7E
+9D1A>I<01F80007FF000FFF801E07C03C01C07800E07000E0E00070E00070FFFFF0FFFFF0FFFF
+F0E000007000007000007800703C00701F01F00FFFE003FFC000FE0014157D941A>I<0007E000
+1FF0003FF800787800F03000E00000E00000E00000E0007FFFF0FFFFF0FFFFF000E00000E00000
+E00000E00000E00000E00000E00000E00000E00000E00000E00000E00000E00000E00000E0003F
+FF807FFFC03FFF80151E7F9D1A>I<01F87C07FFFE0FFFFE1E078C1C03803801C03801C03801C0
+3801C03801C01C03801E07801FFF001FFE0039F8003800003800001C00001FFF801FFFE03FFFF8
+78007C70001CE0000EE0000EE0000EE0000E70001C78003C3E00F81FFFF007FFC001FF0017217F
+941A>I<FE0000FE0000FE00000E00000E00000E00000E00000E00000E00000E3E000EFF800FFF
+C00FC1C00F80E00F00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00
+E00E00E00E00E0FFE3FEFFE7FEFFE3FE171E7F9D1A>I<00C00001E00001E00000C00000000000
+00000000000000000000000000007FE0007FE0007FE00000E00000E00000E00000E00000E00000
+E00000E00000E00000E00000E00000E00000E00000E00000E00000E0007FFF80FFFFC07FFF8012
+1F7C9E1A>I<FE0000FE0000FE00000E00000E00000E00000E00000E00000E00000E0FFC0E1FFE
+0E0FFC0E03C00E07800E0F000E1E000E3C000E78000EFC000FFC000FDE000F8F000E07800E0380
+0E01C00E01E00E00F0FFE3FEFFE3FFFFE3FE181E7F9D1A>107 D<FFE000FFE000FFE00000E000
+00E00000E00000E00000E00000E00000E00000E00000E00000E00000E00000E00000E00000E000
+00E00000E00000E00000E00000E00000E00000E00000E00000E00000E000FFFFE0FFFFE0FFFFE0
+131E7D9D1A>I<7CE0E000FFFBF8007FFFF8001F1F1C001E1E1C001E1E1C001C1C1C001C1C1C00
+1C1C1C001C1C1C001C1C1C001C1C1C001C1C1C001C1C1C001C1C1C001C1C1C001C1C1C001C1C1C
+007F1F1F00FF9F9F807F1F1F00191580941A>I<FE3E00FEFF80FFFFC00FC1C00F80E00F00E00E
+00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E0FFE3FEFF
+E7FEFFE3FE17157F941A>I<01F00007FC001FFF003E0F803C07807803C07001C0E000E0E000E0
+E000E0E000E0E000E0E000E0F001E07001C07803C03C07803E0F801FFF0007FC0001F00013157D
+941A>I<FE3E00FEFF80FFFFE00FC1F00F80700F00380E00380E001C0E001C0E001C0E001C0E00
+1C0E001C0E001C0F00380F00780F80F00FC1E00FFFC00EFF800E3E000E00000E00000E00000E00
+000E00000E00000E00000E0000FFE000FFE000FFE00016207F941A>I<7F83F0FF8FF87FBFFC03
+FC3C03F01803E00003C00003C00003800003800003800003800003800003800003800003800003
+80000380007FFF00FFFF007FFF0016157E941A>114 D<07FB801FFF807FFF80780780E00380E0
+0380E003807800007FC0003FFC0007FE00003F800007806001C0E001C0E001C0F003C0FC0780FF
+FF00EFFE00E3F80012157C941A>I<00C00001C00001C00001C00001C00001C00001C0007FFFE0
+FFFFE0FFFFE001C00001C00001C00001C00001C00001C00001C00001C00001C00001C00001C070
+01C07001C07001C07000E0E000FFE0007FC0001F00141C7F9B1A>I<FE0FE0FE0FE0FE0FE00E00
+E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E01
+E00F03E007FFFE03FFFE00FCFE17157F941A>I<7F83FCFFC7FE7F83FC0E00E00E00E00E00E007
+01C00701C00701C003838003838003838001C70001C70001C70000EE0000EE0000EE00007C0000
+7C0000380017157F941A>I<FF83FEFFC7FEFF83FE3800383800381C00701C00701C00701C3870
+1C7C701C7C700E6CE00E6CE00EEEE00EEEE00EEEE00EC6E006C6C007C7C007C7C003838017157F
+941A>I<7FC7F87FCFFC7FC7F80703C003838003C70001EF0000FE00007C00007800003800007C
+0000EE0001EE0001C7000383800783C00F01C07FC7FCFFC7FE7FC7FC17157F941A>I
+E /Fg 46 122 df<1C003E007F00FF80FF80FF807F003E001C0009097B8813>46
+D<000E00001E00007E0007FE00FFFE00FFFE00F8FE0000FE0000FE0000FE0000FE0000FE0000FE
+0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE
+0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE007FFFFE7FFFFE7FFF
+FE17277BA622>49 D<00FF800003FFF0000FFFFC001F03FE003800FF007C007F80FE003FC0FF00
+3FC0FF003FE0FF001FE0FF001FE07E001FE03C003FE000003FE000003FC000003FC000007F8000
+007F000000FE000000FC000001F8000003F0000003E00000078000000F0000001E0000003C00E0
+007000E000E000E001C001C0038001C0070001C00FFFFFC01FFFFFC03FFFFFC07FFFFFC0FFFFFF
+80FFFFFF80FFFFFF801B277DA622>I<007F800003FFF00007FFFC000F81FE001F00FF003F80FF
+003F807F803F807F803F807F801F807F800F007F800000FF000000FF000000FE000001FC000001
+F8000007F00000FFC00000FFF0000001FC0000007E0000007F0000007F8000003FC000003FC000
+003FE000003FE03C003FE07E003FE0FF003FE0FF003FE0FF003FC0FF007FC07E007F807C007F00
+3F01FE001FFFFC0007FFF00000FF80001B277DA622>I<00000E0000001E0000003E0000007E00
+0000FE000000FE000001FE000003FE0000077E00000E7E00000E7E00001C7E0000387E0000707E
+0000E07E0000E07E0001C07E0003807E0007007E000E007E000E007E001C007E0038007E007000
+7E00E0007E00FFFFFFF8FFFFFFF8FFFFFFF80000FE000000FE000000FE000000FE000000FE0000
+00FE000000FE000000FE00007FFFF8007FFFF8007FFFF81D277EA622>I<0C0003000F803F000F
+FFFE000FFFFC000FFFF8000FFFF0000FFFE0000FFFC0000FFE00000E0000000E0000000E000000
+0E0000000E0000000E0000000E7FC0000FFFF8000F80FC000E003E000C003F0000001F8000001F
+C000001FC000001FE000001FE018001FE07C001FE0FE001FE0FE001FE0FE001FE0FE001FC0FC00
+1FC078003F8078003F803C007F001F01FE000FFFF80003FFF00000FF80001B277DA622>I<0007
+F000003FFC0000FFFE0001FC0F0003F01F8007E03F800FC03F801FC03F801F803F803F801F003F
+8000007F0000007F0000007F000000FF000000FF0FC000FF3FF800FF707C00FFC03E00FFC03F00
+FF801F80FF801FC0FF001FC0FF001FE0FF001FE0FF001FE07F001FE07F001FE07F001FE07F001F
+E03F001FE03F001FC01F801FC01F803F800FC03F0007E07E0003FFFC0000FFF000003FC0001B27
+7DA622>I<380000003E0000003FFFFFF03FFFFFF03FFFFFF07FFFFFE07FFFFFC07FFFFF807FFF
+FF0070000E0070000E0070001C00E0003800E0007000E000E0000000E0000001C0000003800000
+07800000078000000F0000000F0000001F0000001F0000003F0000003E0000003E0000007E0000
+007E0000007E0000007E000000FE000000FE000000FE000000FE000000FE000000FE000000FE00
+0000FE0000007C0000003800001C297CA822>I<000003800000000007C00000000007C0000000
+000FE0000000000FE0000000000FE0000000001FF0000000001FF0000000003FF8000000003FF8
+000000003FF80000000073FC0000000073FC00000000F3FE00000000E1FE00000000E1FE000000
+01C0FF00000001C0FF00000003C0FF80000003807F80000007807FC0000007003FC0000007003F
+C000000E003FE000000E001FE000001E001FF000001C000FF000001FFFFFF000003FFFFFF80000
+3FFFFFF80000780007FC0000700003FC0000700003FC0000E00001FE0000E00001FE0001E00001
+FF0001C00000FF0001C00000FF00FFFE001FFFFEFFFE001FFFFEFFFE001FFFFE2F297EA834>65
+D<FFFFFFF80000FFFFFFFF8000FFFFFFFFC00003F8001FF00003F8000FF80003F80007FC0003F8
+0003FC0003F80003FC0003F80003FE0003F80001FE0003F80001FE0003F80001FE0003F80003FE
+0003F80003FC0003F80003FC0003F80007F80003F8000FF00003F8001FE00003F800FFC00003FF
+FFFE000003FFFFFFE00003F80007F00003F80003FC0003F80001FE0003F80001FE0003F80000FF
+0003F80000FF0003F80000FF8003F80000FF8003F80000FF8003F80000FF8003F80000FF8003F8
+0000FF8003F80000FF0003F80001FF0003F80003FE0003F80007FC0003F8001FF800FFFFFFFFF0
+00FFFFFFFFC000FFFFFFFE000029297DA831>I<00003FF001800003FFFE0380000FFFFF878000
+3FF007DF8000FF8001FF8001FE00007F8003FC00003F8007F000001F800FF000000F801FE00000
+07801FE0000007803FC0000007803FC0000003807FC0000003807F80000003807F8000000000FF
+8000000000FF8000000000FF8000000000FF8000000000FF8000000000FF8000000000FF800000
+0000FF8000000000FF80000000007F80000000007F80000000007FC0000003803FC0000003803F
+C0000003801FE0000003801FE0000007000FF00000070007F000000E0003FC00001E0001FE0000
+3C0000FF8000F800003FF007E000000FFFFFC0000003FFFF000000003FF8000029297CA832>I<
+FFFFFFF80000FFFFFFFF8000FFFFFFFFE00003FC001FF80003FC0007FC0003FC0001FE0003FC00
+00FF0003FC00007F8003FC00003FC003FC00001FC003FC00001FE003FC00001FE003FC00000FF0
+03FC00000FF003FC00000FF003FC00000FF003FC00000FF803FC00000FF803FC00000FF803FC00
+000FF803FC00000FF803FC00000FF803FC00000FF803FC00000FF803FC00000FF803FC00000FF8
+03FC00000FF003FC00000FF003FC00000FF003FC00001FE003FC00001FE003FC00001FC003FC00
+003FC003FC00007F8003FC00007F0003FC0001FE0003FC0003FC0003FC001FF800FFFFFFFFE000
+FFFFFFFF8000FFFFFFFC00002D297DA835>I<FFFFFFFFE0FFFFFFFFE0FFFFFFFFE003FC001FE0
+03FC0007F003FC0001F003FC0001F003FC0000F003FC00007003FC00007003FC00007003FC01C0
+7803FC01C03803FC01C03803FC01C03803FC03C00003FC03C00003FC0FC00003FFFFC00003FFFF
+C00003FFFFC00003FC0FC00003FC03C00003FC03C00003FC01C00E03FC01C00E03FC01C00E03FC
+01C01C03FC00001C03FC00001C03FC00001C03FC00003C03FC00003803FC00007803FC0000F803
+FC0001F803FC0003F803FC001FF8FFFFFFFFF0FFFFFFFFF0FFFFFFFFF027297DA82D>I<FFFFF0
+1FFFFEFFFFF01FFFFEFFFFF01FFFFE03FC00007F8003FC00007F8003FC00007F8003FC00007F80
+03FC00007F8003FC00007F8003FC00007F8003FC00007F8003FC00007F8003FC00007F8003FC00
+007F8003FC00007F8003FC00007F8003FC00007F8003FC00007F8003FFFFFFFF8003FFFFFFFF80
+03FFFFFFFF8003FC00007F8003FC00007F8003FC00007F8003FC00007F8003FC00007F8003FC00
+007F8003FC00007F8003FC00007F8003FC00007F8003FC00007F8003FC00007F8003FC00007F80
+03FC00007F8003FC00007F8003FC00007F8003FC00007F8003FC00007F80FFFFF01FFFFEFFFFF0
+1FFFFEFFFFF01FFFFE2F297DA836>72 D<FFFFFCFFFFFCFFFFFC01FE0001FE0001FE0001FE0001
+FE0001FE0001FE0001FE0001FE0001FE0001FE0001FE0001FE0001FE0001FE0001FE0001FE0001
+FE0001FE0001FE0001FE0001FE0001FE0001FE0001FE0001FE0001FE0001FE0001FE0001FE0001
+FE0001FE0001FE0001FE0001FE00FFFFFCFFFFFCFFFFFC16297EA81A>I<FFFE0000001FFFC0FF
+FE0000001FFFC0FFFF0000003FFFC003FF0000003FF00003FF0000003FF00003BF80000077F000
+03BF80000077F000039FC00000E7F000039FC00000E7F000038FE00001C7F000038FE00001C7F0
+000387F0000387F0000387F0000387F0000387F0000387F0000383F8000707F0000383F8000707
+F0000381FC000E07F0000381FC000E07F0000380FE001C07F0000380FE001C07F0000380FF0038
+07F00003807F003807F00003807F003807F00003803F807007F00003803F807007F00003801FC0
+E007F00003801FC0E007F00003800FE1C007F00003800FE1C007F00003800FE1C007F000038007
+F38007F000038007F38007F000038003FF0007F000038003FF0007F000038001FE0007F0000380
+01FE0007F000038000FC0007F000038000FC0007F000FFFE00FC01FFFFC0FFFE007801FFFFC0FF
+FE007801FFFFC03A297DA841>77 D<FFFC0000FFFEFFFE0000FFFEFFFF0000FFFE03FF80000380
+03FF8000038003BFC0000380039FE0000380039FF0000380038FF80003800387F80003800383FC
+0003800381FE0003800381FF0003800380FF80038003807FC0038003803FC0038003801FE00380
+03800FF0038003800FF80380038007FC0380038003FC0380038001FE0380038000FF0380038000
+FF83800380007FC3800380003FE3800380001FE3800380000FF38003800007FB8003800007FF80
+03800003FF8003800001FF8003800000FF80038000007F80038000007F80038000003F80038000
+001F80038000000F80FFFE00000780FFFE00000380FFFE000003802F297DA836>I<FFFFFFF800
+FFFFFFFF00FFFFFFFFC003FC003FE003FC000FF003FC0007F803FC0007FC03FC0003FC03FC0003
+FE03FC0003FE03FC0003FE03FC0003FE03FC0003FE03FC0003FE03FC0003FE03FC0003FC03FC00
+07FC03FC0007F803FC000FF003FC003FE003FFFFFF8003FFFFFE0003FC00000003FC00000003FC
+00000003FC00000003FC00000003FC00000003FC00000003FC00000003FC00000003FC00000003
+FC00000003FC00000003FC00000003FC00000003FC00000003FC000000FFFFF00000FFFFF00000
+FFFFF0000027297DA82F>80 D<FFFFFFE00000FFFFFFFE0000FFFFFFFF800003FC007FE00003FC
+000FF00003FC0007F80003FC0007FC0003FC0003FC0003FC0003FE0003FC0003FE0003FC0003FE
+0003FC0003FE0003FC0003FE0003FC0003FE0003FC0003FC0003FC0007F80003FC0007F80003FC
+001FE00003FC007FC00003FFFFFE000003FFFFF0000003FC00FC000003FC007F000003FC003F80
+0003FC003F800003FC001FC00003FC001FE00003FC001FE00003FC001FE00003FC001FE00003FC
+001FE00003FC001FF00003FC001FF00003FC001FF00003FC001FF00703FC001FF80703FC000FF8
+0703FC0007F80EFFFFF003FE1CFFFFF001FFF8FFFFF0003FF030297DA834>82
+D<007F806003FFF0E007FFF9E00F807FE01F001FE03E0007E07C0003E07C0001E0FC0001E0FC00
+01E0FC0000E0FE0000E0FE0000E0FF000000FFC000007FFE00007FFFE0003FFFFC001FFFFE000F
+FFFF8007FFFFC003FFFFE000FFFFE00007FFF000007FF000000FF8000007F8000003F8600001F8
+E00001F8E00001F8E00001F8F00001F0F00001F0F80003F0FC0003E0FF0007C0FFE01F80F3FFFF
+00E0FFFE00C01FF0001D297CA826>I<7FFFFFFFFFC07FFFFFFFFFC07FFFFFFFFFC07F803FC03F
+C07E003FC007C078003FC003C078003FC003C070003FC001C0F0003FC001E0F0003FC001E0E000
+3FC000E0E0003FC000E0E0003FC000E0E0003FC000E0E0003FC000E000003FC0000000003FC000
+0000003FC0000000003FC0000000003FC0000000003FC0000000003FC0000000003FC000000000
+3FC0000000003FC0000000003FC0000000003FC0000000003FC0000000003FC0000000003FC000
+0000003FC0000000003FC0000000003FC0000000003FC0000000003FC0000000003FC000000000
+3FC00000007FFFFFE000007FFFFFE000007FFFFFE0002B287EA730>I<FFFFF001FFFCFFFFF001
+FFFCFFFFF001FFFC03FC0000070003FC0000070003FC0000070003FC0000070003FC0000070003
+FC0000070003FC0000070003FC0000070003FC0000070003FC0000070003FC0000070003FC0000
+070003FC0000070003FC0000070003FC0000070003FC0000070003FC0000070003FC0000070003
+FC0000070003FC0000070003FC0000070003FC0000070003FC0000070003FC0000070003FC0000
+070003FC0000070003FC0000070003FC0000070001FC00000E0001FE00000E0000FE00001C0000
+7E00001C00007F00003800003FC000F000000FF007E0000007FFFFC0000001FFFF000000001FF8
+00002E297DA835>I<FFFFE07FFFF007FFF0FFFFE07FFFF007FFF0FFFFE07FFFF007FFF003FC00
+01FE00001C0003FC0001FE00001C0001FE0001FF0000380001FE0000FF0000380001FF0000FF00
+00780000FF0000FF8000700000FF0000FF8000700000FF8000FF8000F000007F8001FFC000E000
+007F8001FFC000E000003FC003FFE001C000003FC0039FE001C000003FE0039FE003C000001FE0
+070FF0038000001FE0070FF0038000001FF00F0FF0078000000FF00E07F8070000000FF00E07F8
+0700000007F81E07FC0E00000007F81C03FC0E00000007FC1C03FC1E00000003FC3801FE1C0000
+0003FC3801FE1C00000001FE7801FF3800000001FE7000FF3800000001FE7000FF3800000000FF
+F000FFF000000000FFE0007FF000000000FFE0007FF0000000007FC0003FE0000000007FC0003F
+E0000000003FC0003FC0000000003F80001FC0000000003F80001FC0000000001F80001F800000
+00001F00000F80000000001F00000F80000000000E00000700000044297FA847>87
+D<01FF800007FFF0000F81F8001FC07E001FC07E001FC03F000F803F8007003F8000003F800000
+3F8000003F80000FFF8000FFFF8007FC3F800FE03F803F803F803F003F807F003F80FE003F80FE
+003F80FE003F80FE003F807E007F807F00DF803F839FFC0FFF0FFC01FC03FC1E1B7E9A21>97
+D<FFE0000000FFE0000000FFE00000000FE00000000FE00000000FE00000000FE00000000FE000
+00000FE00000000FE00000000FE00000000FE00000000FE00000000FE00000000FE00000000FE1
+FE00000FE7FF80000FFE07E0000FF801F0000FF000F8000FE000FC000FE000FE000FE0007F000F
+E0007F000FE0007F000FE0007F800FE0007F800FE0007F800FE0007F800FE0007F800FE0007F80
+0FE0007F800FE0007F000FE0007F000FE0007F000FE000FE000FE000FC000FF001F8000FF803F0
+000F9E07E0000F07FF80000E01FC0000212A7EA926>I<001FF80000FFFE0003F01F0007E03F80
+0FC03F801F803F803F801F007F800E007F0000007F000000FF000000FF000000FF000000FF0000
+00FF000000FF000000FF0000007F0000007F0000007F8000003F8001C01F8001C00FC0038007E0
+070003F01E0000FFFC00001FE0001A1B7E9A1F>I<00003FF80000003FF80000003FF800000003
+F800000003F800000003F800000003F800000003F800000003F800000003F800000003F8000000
+03F800000003F800000003F800000003F800001FE3F80000FFFBF80003F03FF80007E00FF8000F
+C007F8001F8003F8003F8003F8007F0003F8007F0003F8007F0003F800FF0003F800FF0003F800
+FF0003F800FF0003F800FF0003F800FF0003F800FF0003F8007F0003F8007F0003F8007F0003F8
+003F8003F8001F8003F8000F8007F80007C00FF80003F03BFF8000FFF3FF80003FC3FF80212A7E
+A926>I<003FE00001FFF80003F07E0007C01F000F801F801F800F803F800FC07F000FC07F0007
+C07F0007E0FF0007E0FF0007E0FFFFFFE0FFFFFFE0FF000000FF000000FF0000007F0000007F00
+00007F0000003F8000E01F8000E00FC001C007E0038003F81F0000FFFE00001FF0001B1B7E9A20
+>I<0007F0003FFC00FE3E01F87F03F87F03F07F07F07F07F03E07F00007F00007F00007F00007
+F00007F00007F000FFFFC0FFFFC0FFFFC007F00007F00007F00007F00007F00007F00007F00007
+F00007F00007F00007F00007F00007F00007F00007F00007F00007F00007F00007F00007F00007
+F0007FFF807FFF807FFF80182A7EA915>I<00FF81F003FFE7F80FC1FE7C1F80FC7C1F007C383F
+007E107F007F007F007F007F007F007F007F007F007F007F007F003F007E001F007C001F80FC00
+0FC1F8001FFFE00018FF800038000000380000003C0000003E0000003FFFF8001FFFFF001FFFFF
+800FFFFFC007FFFFE01FFFFFF03E0007F07C0001F8F80000F8F80000F8F80000F8F80000F87C00
+01F03C0001E01F0007C00FC01F8003FFFE00007FF0001E287E9A22>I<FFE0000000FFE0000000
+FFE00000000FE00000000FE00000000FE00000000FE00000000FE00000000FE00000000FE00000
+000FE00000000FE00000000FE00000000FE00000000FE00000000FE07F00000FE1FFC0000FE787
+E0000FEE03F0000FF803F0000FF803F8000FF003F8000FF003F8000FE003F8000FE003F8000FE0
+03F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000F
+E003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F800FFFE3FFF80FFFE3FFF80
+FFFE3FFF80212A7DA926>I<07000FC01FE03FE03FE03FE01FE00FC00700000000000000000000
+0000000000FFE0FFE0FFE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE0
+0FE00FE00FE00FE00FE00FE00FE0FFFEFFFEFFFE0F2B7DAA14>I<000700000F80001FC0003FE0
+003FE0003FE0001FC0000F8000070000000000000000000000000000000000000000000001FFE0
+01FFE001FFE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0
+000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0
+000FE0000FE0000FE0000FE07C0FE0FE0FE0FE0FC0FE1F80FE1F007C3E003FFC000FF000133784
+AA15>I<FFE00000FFE00000FFE000000FE000000FE000000FE000000FE000000FE000000FE000
+000FE000000FE000000FE000000FE000000FE000000FE000000FE01FFC0FE01FFC0FE01FFC0FE0
+07800FE00F000FE01E000FE03C000FE078000FE0E0000FE3C0000FE7C0000FEFE0000FFFE0000F
+FFF0000FF3F8000FE3F8000FC1FC000FC0FE000FC07F000FC07F000FC03F800FC01FC00FC00FC0
+0FC00FE0FFFC3FFEFFFC3FFEFFFC3FFE1F2A7EA924>I<FFE0FFE0FFE00FE00FE00FE00FE00FE0
+0FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00F
+E00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE0FFFEFFFEFFFE0F2A7DA914>I<FFC07F
+800FF000FFC1FFE03FFC00FFC383F0707E000FC603F8C07F000FCC01F9803F000FD801FF003F80
+0FF001FE003F800FF001FE003F800FE001FC003F800FE001FC003F800FE001FC003F800FE001FC
+003F800FE001FC003F800FE001FC003F800FE001FC003F800FE001FC003F800FE001FC003F800F
+E001FC003F800FE001FC003F800FE001FC003F800FE001FC003F800FE001FC003F800FE001FC00
+3F800FE001FC003F80FFFE1FFFC3FFF8FFFE1FFFC3FFF8FFFE1FFFC3FFF8351B7D9A3A>I<FFC0
+7F0000FFC1FFC000FFC787E0000FCE03F0000FD803F0000FD803F8000FF003F8000FF003F8000F
+E003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F800
+0FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F8
+00FFFE3FFF80FFFE3FFF80FFFE3FFF80211B7D9A26>I<003FE00001FFFC0003F07E000FC01F80
+1F800FC03F800FE03F0007E07F0007F07F0007F07F0007F0FF0007F8FF0007F8FF0007F8FF0007
+F8FF0007F8FF0007F8FF0007F8FF0007F87F0007F07F0007F03F800FE03F800FE01F800FC00FC0
+1F8007F07F0001FFFC00003FE0001D1B7E9A22>I<FFE1FE0000FFE7FF8000FFFE07E0000FF803
+F0000FF001F8000FE000FC000FE000FE000FE000FF000FE0007F000FE0007F000FE0007F800FE0
+007F800FE0007F800FE0007F800FE0007F800FE0007F800FE0007F800FE0007F000FE000FF000F
+E000FF000FE000FE000FE001FC000FF001F8000FF803F0000FFE0FE0000FE7FF80000FE1FC0000
+0FE00000000FE00000000FE00000000FE00000000FE00000000FE00000000FE00000000FE00000
+000FE0000000FFFE000000FFFE000000FFFE00000021277E9A26>I<FFC1F0FFC7FCFFCE3E0FD8
+7F0FD87F0FF07F0FF03E0FF01C0FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0
+000FE0000FE0000FE0000FE0000FE0000FE0000FE000FFFF00FFFF00FFFF00181B7E9A1C>114
+D<03FE300FFFF01E03F03800F0700070F00070F00070F80070FC0000FFE0007FFE007FFF803FFF
+E01FFFF007FFF800FFF80003FC0000FC60007CE0003CF0003CF00038F80038FC0070FF01E0F7FF
+C0C1FF00161B7E9A1B>I<00700000700000700000700000F00000F00000F00001F00003F00003
+F00007F0001FFFF0FFFFF0FFFFF007F00007F00007F00007F00007F00007F00007F00007F00007
+F00007F00007F00007F00007F00007F03807F03807F03807F03807F03807F03803F03803F87001
+F86000FFC0001F8015267FA51B>I<FFE03FF800FFE03FF800FFE03FF8000FE003F8000FE003F8
+000FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003
+F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE0
+03F8000FE007F80007E007F80007E00FF80003F03BFF8001FFF3FF80003FC3FF80211B7D9A26>
+I<FFFE03FF80FFFE03FF80FFFE03FF8007F000700007F000700007F800F00003F800E00003FC01
+E00001FC01C00001FC01C00000FE03800000FE038000007F070000007F070000007F8F0000003F
+8E0000003FDE0000001FDC0000001FDC0000000FF80000000FF80000000FF800000007F0000000
+07F000000003E000000003E000000001C00000211B7F9A24>I<FFFC0FFF00FFFC0FFF00FFFC0F
+FF0007F003C00003F807800001FC07800000FE0F000000FF1E0000007F3C0000003FF80000001F
+F00000000FF00000000FF000000007F000000007F80000000FFC0000001FFE0000001EFE000000
+3C7F000000783F800000F01FC00001E01FE00001C00FE00003C007F000FFF01FFF80FFF01FFF80
+FFF01FFF80211B7F9A24>120 D<FFFE03FF80FFFE03FF80FFFE03FF8007F000700007F0007000
+07F800F00003F800E00003FC01E00001FC01C00001FC01C00000FE03800000FE038000007F0700
+00007F070000007F8F0000003F8E0000003FDE0000001FDC0000001FDC0000000FF80000000FF8
+0000000FF800000007F000000007F000000003E000000003E000000001C000000001C000000003
+800000000380000038078000007C07000000FE0F000000FE0E000000FE1E000000FE3C0000007C
+780000003FE00000000FC000000021277F9A24>I E /Fh 36 124 df<0000FC0000038300000E
+0080001C03800038078000700780007003000070000000E0000000E0000000E0000000E0000000
+E0000000E000003FFFFE0001C00E0001C00E0001C00E0001C00E0001C00E0003801C0003801C00
+03801C0003801C0003801C0003801C000700380007003800070038000700380007003800070038
+000E0070000F007800FFC3FF0019237FA21B>12 D<0000FE03F00003818E0C000E00B802001C01
+F00E003803E01E007003C01E007001C00C007001C00000E003800000E003800000E003800000E0
+03800000E003800000E00380003FFFFFFFF801C007003801C007003801C007003801C007003801
+C007003803800E007003800E007003800E007003800E007003800E007003800E007007001C00E0
+07001C00E007001C00E007001C00E007001C00E007001C00E00E003801C00F003C01E0FFE3FF9F
+FC27237FA229>14 D<1C3E7E7E3A02020404080810204080070F7D840E>44
+D<FFE0FFE00B027D8B10>I<3078F8787005057C840E>I<0000040000000006000000000E000000
+001E000000001E000000003E000000003F000000004F000000004F000000008F000000008F0000
+00010F000000010780000002078000000207800000040780000004078000000807C000000803C0
+00001003C000001003C000002003C000003FFFE000004001E000004001E000008001E000008001
+E000010001E000010000F000020000F000060000F000040000F0000C0000F0003E0001F800FF80
+0FFF8021237EA225>65 D<03FFE0FFF8003E000F80003C000F00003C000F00003C000F00003C00
+0F00003C000F000078001E000078001E000078001E000078001E000078001E000078001E0000F0
+003C0000F0003C0000F0003C0000FFFFFC0000F0003C0000F0003C0001E000780001E000780001
+E000780001E000780001E000780001E000780003C000F00003C000F00003C000F00003C000F000
+03C000F00003C000F000078001E00007C001F000FFFC3FFF0025227EA125>72
+D<03FFF0003E00003C00003C00003C00003C00003C000078000078000078000078000078000078
+0000F00000F00000F00000F00000F00000F00001E00001E00001E00001E00001E00001E00003C0
+0003C00003C00003C00003C00003C00007800007C000FFFC0014227EA112>I<03FFFFC0003E00
+F0003C0078003C003C003C003E003C001E003C003E0078003E0078003E0078003E0078003E0078
+003C0078007C00F0007800F000F000F001E000F0078000FFFE0000F0000001E0000001E0000001
+E0000001E0000001E0000001E0000003C0000003C0000003C0000003C0000003C0000003C00000
+0780000007C00000FFFC00001F227EA121>80 D<03FFFF0000003E01E000003C007800003C003C
+00003C003C00003C003E00003C003E000078003E000078003E000078003E000078003E00007800
+7C00007800780000F000F00000F001E00000F007800000FFFC000000F00C000000F007000001E0
+07000001E003800001E003800001E003C00001E003C00001E003C00003C007C00003C007C00003
+C007C00003C007C00003C007C04003C007C080078007C08007C003E100FFFC01E3000000007C00
+22237EA124>82 D<000FC0800030318000C00B0001800700038007000300030007000300070003
+000E0002000E0002000F0002000F0000000F0000000F80000007E0000007FE000003FFC00001FF
+E000007FF000000FF8000000F8000000780000003C0000003C0000003C0020003C004000380040
+00380040003800600030006000700060006000F000C000E8018000C607000081FC000019247DA2
+1B>I<03FC000606000F03000F03800601800001C0000380000380007F8003E3800F03801C0380
+380700780700F00708F00708F00F08F00F08F017107867A01F83C015157D9418>97
+D<0780003F80000700000700000700000700000700000700000E00000E00000E00000E00000E00
+000E00001C3F001CC1801D00C01E00601C00701C00703800783800783800783800783800783800
+787000F07000F07000E07001E07001C0700380E80700C61C0081F00015237BA21B>I<00FF0003
+81C00603C00C03C01C0180380000780000700000F00000F00000F00000F00000F00000E00000F0
+0000F000807001007001003806001C180007E00012157C9416>I<00001E0000FE00001C00001C
+00001C00001C00001C00001C00003800003800003800003800003800003800FC700383700700F0
+0C00F01C00703800707800E07000E0F000E0F000E0F000E0F000E0E001C0E001C0E001C0E001C0
+7003C07003C0380F801C33C007C3F817237CA21B>I<00FE000383800701C00C00E01C00E03800
+E07800E07000E0FFFFE0F00000F00000F00000F00000E00000E00000F000407000803000801803
+000E0C0003F00013157D9416>I<0003E0000E30001C700038F000307000700000700000700000
+E00000E00000E00000E00000E00000E0003FFE0001C00001C00001C00001C00001C00003800003
+80000380000380000380000380000700000700000700000700000700000700000E00000F0000FF
+F00014237FA20F>I<00000780001F88800070D18000E0E18001C0700003C0700003C070000780
+F0000780F0000780F0000780E0000381E0000181C00002C30000027E0000040000000400000004
+0000000600000007FF800007FFE00007FFF0001C007800300018006000180060001800C0001800
+C0001800C0003000600060003000C0001C07800003FC00001921809518>I<00780003F8000070
+0000700000700000700000700000700000E00000E00000E00000E00000E00000E00001C3F001CC
+1801D00C01E00E01E00E01C00E03C01C03801C03801C03801C03801C03801C0700380700380700
+380700380700380700380E00700F0078FFE7FF18237FA21B>I<007000F001F000F000E0000000
+0000000000000000000000000001C00FC001C001C001C001C00380038003800380038003800700
+070007000700070007000E000F00FFE00C227FA10E>I<007803F8007000700070007000700070
+00E000E000E000E000E000E001C001C001C001C001C001C0038003800380038003800380070007
+0007000700070007000E000F00FFE00D237FA20E>108 D<01C1F807E01FC60C183001D80E6038
+01E007801C01E007801C01C007001C03C00F003803800E003803800E003803800E003803800E00
+3803800E003807001C007007001C007007001C007007001C007007001C007007001C00700E0038
+00E00F003C00F0FFE3FF8FFE27157F942A>I<01C3F01FCC1801D00C01E00E01E00E01C00E03C0
+1C03801C03801C03801C03801C03801C0700380700380700380700380700380700380E00700F00
+78FFE7FF18157F941B>I<007E000383800600C00C00E01C0070380070780078700078F00078F0
+0078F00078F00078E000F0E000F0E000E0F001E07001C07003803807001C1C0007F00015157D94
+18>I<00E1F8000FE60C0000E8060000F0070000E0038000E0038001C003C001C003C001C003C0
+01C003C001C003C001C003C003800780038007800380070003800F0003801E0003801C00074038
+000730E000070F80000700000007000000070000000E0000000E0000000E0000000E0000000E00
+00001E000000FFC000001A1F80941B>I<00FC100382100701300E00F01C00F03800F07800E078
+00E0F000E0F000E0F000E0F000E0F001C0F001C0F001C0F001C07003C07005C0380B801C338007
+C380000380000380000380000700000700000700000700000700000F00007FE0141F7C941A>I<
+01C7C01FC8E001D1E001E1E001E0C001C00003C000038000038000038000038000038000070000
+0700000700000700000700000700000E00000F0000FFF00013157F9413>I<01F906070C031803
+1801180118021C001FE00FF807FC007E000E4006400640066006600CE008D83087C010157E9413
+>I<008000800080018001000300030007000F001F00FFF80E000E000E000E000E001C001C001C
+001C001C001C0038103810381038103810382038201C4007800D1F7C9E13>I<0E0070FE07F00E
+00F00E00700E00700E00701C00E01C00E01C00E01C00E01C00E01C00E03801C03801C03801C038
+01C03803C03805C0380B801C13C007E3F815157C941B>I<FFC0FE1E00780E00300E00200E0040
+0E004007008007008007010007030007820003840003840003880003C80001D00001D00001E000
+01C00000C00000800017157C941A>I<FFC7FC7F801E01E03E001C00C018001C01C010000E01E0
+10000E02E020000E02E020000E04E040000E046040000E08608000070870800007107100000710
+71000007207200000720320000074034000003C03C000003803800000380380000030030000003
+0010000021157C9423>I<1FF83FC003E01E0001C0180000E0100000E020000070400000788000
+00390000001E0000001C0000000E0000001F0000003700000063800000C380000181C0000101E0
+000200E0000E00F0003E00F800FF03FF001A157F941A>I<0FFC0FE001E0078000E0030000E002
+0000E0040000E00400007008000070080000701000007030000078200000384000003840000038
+8000003C8000001D0000001D0000001E0000001C0000000C000000080000000800000010000000
+1000000020000000400000F0400000F0800000F1000000C20000003C0000001B1F80941A>I<07
+FFF80780380600700C00E00801C0080380080700100E00001C0000380000700000E00001C02003
+C0200380200700600E00401C00C03801C0700380FFFF8015157F9416>I<FFFFFE17017E8C18>I
+E /Fi 54 122 df<00000FE0000030180000E01C0001C03C0001803C0003803800038000000380
+000007000000070000000700000007000000070000000E000000FFFFE0000E00E0000E00E0000E
+01C0001C01C0001C01C0001C01C0001C0380001C03800038038000380380003807000038070000
+3807000070070800700E1000700E1000700E1000700E2000E0062000E003C000E0000000E00000
+00C0000001C0000001C0000071800000F1800000F3000000620000003C0000001E2D82A21B>12
+D<0007800000001C6003800030100780006010078000E010038000C010010001C07001000380F0
+02000380F002000380600400070000080007000010000700006000073C00A00007E20310000781
+041000070108080007011008000F022008001F842008001C782C08003C003E080038003E080078
+001C0800780000080078000008007000001000F000001000700000200070000020007800004000
+380000800038000100001C000200000E000C00000380700000007F80000021257BA325>38
+D<FFF0FFF0FFE00C037C8B11>45 D<70F8F8F0E005057A840F>I<000000080000001800000030
+0000003000000060000000C0000000C0000001800000018000000300000006000000060000000C
+0000000C0000001800000030000000300000006000000060000000C00000018000000180000003
+0000000300000006000000060000000C0000001800000018000000300000003000000060000000
+C0000000C0000001800000018000000300000006000000060000000C0000000C00000018000000
+30000000300000006000000060000000C0000000C0000000800000001D317FA419>I<000F8000
+30C000E06001C0700380700300700700700F00700E00701E00701E00701C00F03C00F03C00F03C
+00F07801E07801E07801E07801E0F003C0F003C0F003C0F00380E00780E00780E00700E00F00E0
+0E00E01C00E01C00E0380060700030E0001F000014227AA019>I<0001000300030006001E002E
+03CE001C001C001C001C0038003800380038007000700070007000E000E000E000E001C001C001
+C001C003800380038003800780FFFC10217AA019>I<000FC000106000603800801800801C0100
+1C02201E02101E04101E04101E04101E08203C08203C0840380840780880F00700E00001C00003
+0000060000180000200000C0000100000200000400100800301000202000605F80C063FFC040FF
+80807F00801E0017227CA019>I<000FC000307000C01801001C02001C04000C04401C08201C08
+201C08201C08403808C0380700700000600001C000070000FC000007000003800003800001C000
+01C00001C00003C06003C0F003C0F00380E00780800700800E00801C0040380020F0001F800016
+227BA019>I<0000180000380000380000700000700000700000E00000E00000E00000C00001C0
+000180000380000300000300000600000600000C00000C000018000010000031800061C0004380
+0083800183800303800207000407000807003FC700403E00800FF0000E00000E00001C00001C00
+001C00001C00003800003800003800003000152B7EA019>I<00400400703800FFF000FFE000BF
+80008000010000010000010000010000020000020000023E0002C3000501800601C00401C00001
+E00001E00001E00001E00001E00001E07003C0F003C0F003C0E00780800700800F00800E00401C
+0040380030E0000F800016227BA019>I<07000F800F800F000E00000000000000000000000000
+000000000000000000007000F800F800F000E00009157A940F>58 D<0000030000000300000007
+000000070000000F0000000F0000001F0000002F0000002F0000004F0000004F80000087800000
+878000010780000207800002078000040780000407800008078000080780001007800030078000
+200780007FFF80004007C0008007C0008003C0010003C0030003C0020003C0040003C0040003C0
+0C0003C03C0007C0FF003FFC1E237DA224>65 D<00FFFFE0000F0038000F001C000F001E001E00
+0E001E000F001E000F001E000F003C000E003C001E003C001E003C003C00780078007800F00078
+01E00078078000FFFF8000F001E000F000F000F0007801E0007801E0003801E0003C01E0003C03
+C0007803C0007803C0007803C000F0078000F0078001E0078003C0078007000F801E00FFFFF000
+20227DA122>I<00007F00800003808100000E00630000380027000070001F0000E0000E0001C0
+000E000380000E000700000E000F000004000E000004001E000004003C000004003C0000080078
+0000000078000000007800000000F000000000F000000000F000000000F000000000F000000000
+E000000000E000002000E000002000E000004000E000004000F000008000700000800070000100
+00380002000018000400001C0008000006003000000381C0000000FE000000212479A223>I<00
+FFFFF000000F003C00000F000E00000F000700001E000380001E000380001E0001C0001E0001C0
+003C0001C0003C0001E0003C0001E0003C0001E000780001E000780001E000780001E000780001
+E000F00003C000F00003C000F00003C000F00003C001E000078001E000078001E000070001E000
+0F0003C0000E0003C0001C0003C0003C0003C00038000780007000078000E000078001C0000780
+0700000F801C0000FFFFF0000023227DA125>I<00FFFFFF80000F000780000F000180000F0001
+80001E000180001E000180001E000100001E000100003C000100003C000100003C010100003C01
+000000780200000078020000007806000000780E000000FFFC000000F00C000000F00C000000F0
+0C000001E008000001E008000001E008040001E000080003C000080003C000080003C000100003
+C000100007800020000780006000078000C000078001C0000F8007C000FFFFFF800021227DA121
+>I<00FFFFFF000F000F000F0003000F0003001E0003001E0003001E0002001E0002003C000200
+3C0002003C0102003C010000780200007802000078060000780E0000FFFC0000F00C0000F00C00
+00F00C0001E0080001E0080001E0080001E0000003C0000003C0000003C0000003C00000078000
+000780000007800000078000000F800000FFFC000020227DA120>I<00FFF87FFC000F00078000
+0F000780000F000780001E000F00001E000F00001E000F00001E000F00003C001E00003C001E00
+003C001E00003C001E000078003C000078003C000078003C000078003C0000FFFFF80000F00078
+0000F000780000F000780001E000F00001E000F00001E000F00001E000F00003C001E00003C001
+E00003C001E00003C001E000078003C000078003C000078003C000078003C0000F8007C000FFF8
+7FFC0026227DA124>72 D<00FFF8000F00000F00000F00001E00001E00001E00001E00003C0000
+3C00003C00003C0000780000780000780000780000F00000F00000F00000F00001E00001E00001
+E00001E00003C00003C00003C00003C0000780000780000780000780000F8000FFF80015227DA1
+13>I<00FFF807FC000F0001E0000F0001C0000F000100001E000200001E000400001E00100000
+1E002000003C004000003C008000003C010000003C040000007808000000781800000078380000
+00787C000000F0BC000000F23C000000F41E000000F81E000001F01F000001E00F000001E00F00
+0001E00F800003C007800003C007800003C003C00003C003C000078003C000078001E000078001
+E000078001E0000F8001F000FFF80FFE0026227DA125>75 D<00FFFC00000F8000000F0000000F
+0000001E0000001E0000001E0000001E0000003C0000003C0000003C0000003C00000078000000
+780000007800000078000000F0000000F0000000F0000000F0000001E0000001E0000001E00020
+01E0002003C0004003C0004003C0008003C0008007800180078001000780030007800F000F803E
+00FFFFFE001B227DA11F>I<00FF800007FC000F80000F80000F80001780000F80001780001780
+002F000013C0002F000013C0004F000013C0008F000023C0009E000023C0011E000023C0011E00
+0023C0021E000043C0043C000043C0043C000043C0083C000041E0083C000081E01078000081E0
+2078000081E02078000081E04078000101E040F0000101E080F0000101E100F0000101E100F000
+0200F201E0000200F201E0000200F401E0000200F801E0000400F803C0000400F003C0000400F0
+03C0000C00E003C0001E00C007C000FFC0C07FFC002E227DA12C>I<00FF000FFC000F8001E000
+0F800180000FC000800013C001000013C001000011E001000011E001000021E002000020F00200
+0020F002000020F0020000407804000040780400004078040000403C040000803C080000803E08
+0000801E080000801E080001001F100001000F100001000F10000100079000020007A000020007
+A000020003E000020003E000040003C000040001C000040001C0000C0001C0001E00008000FFC0
+00800026227DA124>I<0000FE0000078380000C00E0003800700070003800E0003801C0001C03
+80001C0700001C0F00001E1E00001E1C00001E3C00001E3C00001E7800001E7800001E7800001E
+F000003CF000003CF000003CF0000078F0000078E0000078E00000F0E00000F0E00001E0E00001
+C0F00003C0F00007807000070078000E0038001C001C0038000E00E0000703800001FC00001F24
+79A225>I<00FFFFE0000F0038000F001E000F000E001E0007001E0007001E0007001E0007003C
+000F003C000F003C000F003C001E0078001E0078003C00780078007800E000F003C000FFFE0000
+F0000000F0000001E0000001E0000001E0000001E0000003C0000003C0000003C0000003C00000
+078000000780000007800000078000000F800000FFF8000020227DA121>I<00FFFFC0000F0070
+000F003C000F001C001E000E001E000E001E000F001E000F003C001E003C001E003C001E003C00
+3C0078003800780070007801E00078078000FFFC0000F00E0000F0070000F0038001E003C001E0
+03C001E003C001E003C003C0078003C0078003C0078003C0078007800F0007800F0107800F0107
+8007020F800702FFF8038C000000F020237DA124>82 D<0001F020000E0C40001802C0003001C0
+006001C000E0018000C0018001C0018001C0018003C0010003C0010003C0000003C0000003E000
+0001F8000001FF000000FFE000007FF000001FF8000003FC0000007C0000003C0000001E000000
+1E0000001E0020001C0020001C0020001C00200018006000380060003000700060007000C000C8
+018000C607000081FC00001B247DA21B>I<1FFFFFF81E03C0381803C0183003C0182007801820
+0780184007801040078010400F0010800F0010800F0010000F0000001E0000001E0000001E0000
+001E0000003C0000003C0000003C0000003C00000078000000780000007800000078000000F000
+0000F0000000F0000000F0000001E0000001E0000001E0000001E0000003E00000FFFF00001D22
+77A123>I<3FFE03FF03C0007803C0006003C00020078000400780004007800040078000400F00
+00800F0000800F0000800F0000801E0001001E0001001E0001001E0001003C0002003C0002003C
+0002003C0002007800040078000400780004007800040070000800F0000800F000100070001000
+70002000700040003000400038018000180200000E0C000003F00000202377A124>I<007FF81F
+F8000FC007C000078003000007C002000003C004000003C008000003E010000001E030000001E0
+20000001F040000000F080000000F100000000FA000000007C000000007C000000007C00000000
+3C000000003C000000007E000000009E000000011E000000031F000000060F000000040F000000
+080F80000010078000002007C000004007C00000C003C000018003E000010001E000070001E000
+1F0003F000FFC01FFE0025227EA124>88 D<00F8C00185C00705C00E03800E03801C03803C0380
+380700780700780700780700F00E00F00E00F00E00F00E10F01C20701C20703C20305C40308C40
+0F078014157B9419>97 D<03C03F8003800380038007000700070007000E000E000E000E001C00
+1CF81D0C1E0E3C0638073807380F700F700F700F700FE01EE01EE01EE03CE038E038607060E031
+C01F0010237BA216>I<007E0001C1000301800703800E07801C07803C00003800007800007800
+00780000F00000F00000F00000F00000F00100700100700200300C001830000FC00011157B9416
+>I<00003C0003F80000380000380000380000700000700000700000700000E00000E00000E000
+00E00001C000F9C00185C00705C00E03800E03801C03803C0380380700780700780700780700F0
+0E00F00E00F00E00F00E10F01C20701C20703C20305C40308C400F078016237BA219>I<00F803
+840E021C023C0238027804F018FFE0F000F000E000E000E000E000E002E0026004701830600F80
+0F157A9416>I<00003E0000470000CF00018F0001860003800003800003800007000007000007
+00000700000700000E0000FFF0000E00000E00000E00001C00001C00001C00001C00001C000038
+0000380000380000380000380000700000700000700000700000700000E00000E00000E00000E0
+0000C00001C00001C000718000F18000F300006200003C0000182D82A20F>I<001F180030B800
+E0B801C07001C0700380700780700700E00F00E00F00E00F00E01E01C01E01C01E01C01E01C01E
+03800E03800E0780060B8006170001E700000700000700000E00000E00000E00701C00F01800F0
+300060E0003F8000151F7E9416>I<00F0000FE00000E00000E00000E00001C00001C00001C000
+01C000038000038000038000038000070000071F0007218007C0C00F00E00F00E00E00E00E00E0
+1C01C01C01C01C01C01C01C0380380380380380380380704700708700E08700E10700610E00620
+6003C016237DA219>I<00C001E001C001C0000000000000000000000000000000001C00230043
+0043008700870087000E000E001C001C001C00380038003840708070807080710032001C000B21
+7BA00F>I<00F0000FE00000E00000E00000E00001C00001C00001C00001C00003800003800003
+80000380000700000701E0070210070C700E10F00E10F00E20600E40001D80001E00001FC0001C
+7000383800383800381C00381C20703840703840703840701880E01880600F0014237DA216>
+107 D<01E01FC001C001C001C0038003800380038007000700070007000E000E000E000E001C00
+1C001C001C0038003800380038007000700070007100E200E200E200E200640038000B237CA20C
+>I<1C0F80F8002610C10C00476066060087807807008780780700870070070087007007000E00
+E00E000E00E00E000E00E00E000E00E00E001C01C01C001C01C01C001C01C01C001C01C0382038
+0380384038038070403803807080380380308070070031003003001E0023157B9428>I<1C0F00
+2631C04740C08780E08780E08700E08700E00E01C00E01C00E01C00E01C01C03801C03801C0380
+1C0704380708380E08380E103806107006203003C016157B941B>I<007E0001C3000381800701
+C00E01C01C01E03C01E03801E07801E07801E07801E0F003C0F003C0F00380F00780700700700E
+00700C0030180018700007C00013157B9419>I<01C1F002621804741C08780C08700E08700E08
+701E00E01E00E01E00E01E00E01E01C03C01C03C01C03C01C07803807003807003C0E003C1C007
+2380071E000700000700000E00000E00000E00000E00001C00001C00001C0000FFC000171F7F94
+19>I<00F8400184C00705C00E03800E03801C03803C0380380700780700780700780700F00E00
+F00E00F00E00F00E00F01C00701C00703C00305C0030B8000F3800003800003800007000007000
+00700000700000E00000E00000E0000FFE00121F7B9416>I<1C1F002620804741C08783C08703
+C08701808700000E00000E00000E00000E00001C00001C00001C00001C00003800003800003800
+0038000070000030000012157B9415>I<00FC000183000200800401800C03800C03000C00000F
+00000FF00007FC0003FE00003E00000F00000700700700F00600F00600E004004008002030001F
+C00011157D9414>I<00C001C001C001C001C003800380038003800700FFF8070007000E000E00
+0E000E001C001C001C001C003800380038003810702070207040708031001E000D1F7C9E10>I<
+1E00602300E04380E04381C08381C08701C08701C00703800E03800E03800E03801C07001C0700
+1C07001C07081C0E10180E101C0E101C1E200C262007C3C015157B941A>I<1E03802307C04387
+C04383C08381C08700C08700C00700800E00800E00800E00801C01001C01001C01001C02001C02
+001C04001C08001C08000C300003C00012157B9416>I<1E0060E02300E1F04380E1F04381C0F0
+8381C0708701C0308701C030070380200E0380200E0380200E0380201C0700401C0700401C0700
+401C0700801C0700801C0701001C0F01000C0F020006138C0003E0F0001C157B9420>I<1E0030
+2300704380704380E08380E08700E08700E00701C00E01C00E01C00E01C01C03801C03801C0380
+1C03801C07001C07001C07001C0F000C3E0003CE00000E00000E00001C00601C00F03800F03000
+E0600080C0004380003E0000141F7B9418>121 D E /Fj 3 53 df<0F8030E040708030C038E0
+384038003800700070006000C00180030006000C08080810183FF07FF0FFF00D157E9412>50
+D<0FE030306018701C701C001C00180038006007E000300018000C000E000EE00EE00EC00C4018
+30300FE00F157F9412>I<00300030007000F001F001700270047008701870107020704070C070
+FFFE0070007000700070007003FE0F157F9412>I E /Fk 19 122 df<0007F010001C0C300070
+026000C001E0038000E0070000E00E0000600E0000601C0000403C000040380000407800000078
+00000078000000F0000000F0000000F0000000F0000000F0000000F0000080F000010070000100
+7000010038000200380004001C0004000C001800060020000380C000007F00001C1E7C9C1E>67
+D<0FFFFC0000F80F0000F0038000F003C000F001C000F001C000F001C001E003C001E003C001E0
+03C001E0038001E0070001E00E0003C03C0003FFE00003C0000003C0000003C0000003C0000007
+80000007800000078000000780000007800000078000000F0000000F800000FFF000001A1C7E9B
+1C>80 D<0FFFF80000F80E0000F0078000F003C000F001C000F001E000F001E001E003C001E003
+C001E0038001E0070001E00E0001E03C0003FFE00003C0700003C0380003C03C0003C01C0003C0
+1E0007803C0007803C0007803C0007803C0007803C0007803C080F003C100F801C10FFF01C2000
+0007C01D1D7E9B1F>82 D<1FFFFFF03C07C0F03007803020078020600780204007802040078020
+400F0020800F0020000F0000000F0000000F0000000F0000001E0000001E0000001E0000001E00
+00001E0000001E0000003C0000003C0000003C0000003C0000003C0000003C000000780000007C
+00001FFFE0001C1C7C9B1E>84 D<07F0001C18001E0C001C0E00180E00000E00000E0001FE000F
+0E001C1C00301C00701C00E01C40E01C40E03C40E05C80709D803F0E0012127D9115>97
+D<01F8071C0C1E181C38183000700070007000E000E000E000600060047008301018200FC00F12
+7D9112>99 D<01F8070C0C061C073803300370037FFF7000E000E000E00060006002300430081C
+3007C010127E9112>101 D<000F800039C00061C000E3C001C18001C00001C00001C000038000
+0380000380003FF8000380000380000700000700000700000700000700000700000E00000E0000
+0E00000E00000E00000E00001C00001E0000FFC000121D7F9C0D>I<07E00001E00001C00001C0
+0001C00001C00001C00001C000038000038000038000038F8003B0C003C0E00780E00780E00700
+E00700E00700E00700E00E01C00E01C00E01C00E01C00E01C00E01C01C03801E03C0FF9FF0141D
+7F9C17>104 D<00C001C001C0018000000000000000000000000000001F800780038007000700
+07000700070007000E000E000E000E000E000E001C001E00FF800A1D7F9C0C>I<07E001E001C0
+01C001C001C001C001C00380038003800380038003800700070007000700070007000E000E000E
+000E000E000E001C001E00FF800B1D7F9C0C>108 D<1F8FC0FC00079061060003E07607000780
+780700078078070007007007000700700700070070070007007007000E00E00E000E00E00E000E
+00E00E000E00E00E000E00E00E000E00E00E001C01C01C001E01E01E00FF8FF8FF8021127F9124
+>I<1F8F8007B0C003C0E00780E00780E00700E00700E00700E00700E00E01C00E01C00E01C00E
+01C00E01C00E01C01C03801E03C0FF9FF014127F9117>I<00FC000307000E01801C01C03800C0
+3000C07000E07000E07000E0E001C0E001C0E001C0600180600380700700380E001C180007E000
+13127E9115>I<1F9C07EE03CF078E078C07000700070007000E000E000E000E000E000E001C00
+1E00FFC010127F9110>114 D<03F20C0E18061004300438043E001FE00FF007F8003C401C400C
+400C6018E010D0608FC00F127F9110>I<020002000200060006000C001C003C00FFE01C001C00
+380038003800380038003800700070407040704070407080708031001E000B1A7C9910>I<FC1F
+803C07801C0380380700380700380700380700380700380700700E00700E00700E00700E00701E
+00701E00703C00305E001F9F8011127C9117>I<0FF0FE03C03801C03001C02001C06001C04001
+E08000E08000E10000E10000E200007200007400007C0000780000700000300000200000200000
+4000004000708000F10000F10000E60000780000171A809116>121 D E
+/Fl 42 124 df<6060F0F0F8F86868080808080808101010102020404080800D0C7F9C15>34
+D<FFE0FFE00B0280890E>45 D<00010003000600060006000C000C000C00180018001800300030
+00300060006000C000C000C0018001800180030003000300060006000C000C000C001800180018
+00300030003000600060006000C000C00010297E9E15>47 D<030007003F00C700070007000700
+07000700070007000700070007000700070007000700070007000700070007000700070007000F
+80FFF80D1C7C9B15>49 D<07C01830201C400C400EF00FF80FF807F8077007000F000E000E001C
+001C00380070006000C00180030006010C01180110023FFE7FFEFFFE101C7E9B15>I<07E01830
+201C201C781E780E781E381E001C001C00180030006007E00030001C001C000E000F000F700FF8
+0FF80FF80FF00E401C201C183007E0101D7E9B15>I<03C00C301818300C700C600EE006E006E0
+07E007E007E007E0076007700F300F18170C2707C700060006000E300C780C78187010203030C0
+0F80101D7E9B15>57 D<000600000006000000060000000F0000000F0000000F00000017800000
+178000001780000023C0000023C0000023C0000041E0000041E0000041E0000080F0000080F000
+0180F8000100780001FFF80003007C0002003C0002003C0006003E0004001E0004001E000C001F
+001E001F00FF80FFF01C1D7F9C1F>65 D<001F808000E0618001801980070007800E0003801C00
+03801C00018038000180780000807800008070000080F0000000F0000000F0000000F0000000F0
+000000F0000000F0000000F0000000700000807800008078000080380000801C0001001C000100
+0E000200070004000180080000E03000001FC000191E7E9C1E>67 D<FFF00F000F000F000F000F
+000F000F000F000F000F000F000F000F000F000F000F000F000F000F000F000F000F000F000F00
+0F000F00FFF00C1C7F9B0F>73 D<FF007FC00F800E000F8004000BC0040009E0040009E0040008
+F0040008F8040008780400083C0400083C0400081E0400080F0400080F0400080784000807C400
+0803C4000801E4000801E4000800F40008007C0008007C0008003C0008003C0008001C0008000C
+001C000C00FF8004001A1C7E9B1F>78 D<FFFF800F00E00F00780F003C0F001C0F001E0F001E0F
+001E0F001E0F001E0F001C0F003C0F00780F00E00FFF800F00000F00000F00000F00000F00000F
+00000F00000F00000F00000F00000F00000F0000FFF000171C7E9B1C>80
+D<FFFF00000F01E0000F0078000F003C000F001C000F001E000F001E000F001E000F001E000F00
+1C000F003C000F0078000F01E0000FFF00000F03C0000F00E0000F00F0000F0078000F0078000F
+0078000F0078000F0078000F0078000F0078100F0078100F0038100F003C20FFF01C20000007C0
+1C1D7E9B1F>82 D<7FFFFFC0700F01C0600F00C0400F0040400F0040C00F0020800F0020800F00
+20800F0020000F0000000F0000000F0000000F0000000F0000000F0000000F0000000F0000000F
+0000000F0000000F0000000F0000000F0000000F0000000F0000000F0000000F0000001F800003
+FFFC001B1C7F9B1E>84 D<FFF07FC00F000E000F0004000F0004000F0004000F0004000F000400
+0F0004000F0004000F0004000F0004000F0004000F0004000F0004000F0004000F0004000F0004
+000F0004000F0004000F0004000F0004000F0004000700080007800800038010000180100000C0
+20000070C000001F00001A1D7E9B1F>I<7FF0FFC00FC03E000780180003C0180003E0100001E0
+200001F0600000F0400000788000007D8000003D0000001E0000001F0000000F0000000F800000
+0F80000013C0000023E0000021E0000041F00000C0F8000080780001007C0003003C0002001E00
+06001F001F003F80FFC0FFF01C1C7F9B1F>88 D<FEFEC0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0
+C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0FEFE07297C9E0C>91 D<080810102020404040
+40808080808080B0B0F8F8787830300D0C7A9C15>I<FEFE060606060606060606060606060606
+06060606060606060606060606060606060606060606FEFE0729809E0C>I<1FC0003070007838
+00781C00301C00001C00001C0001FC000F1C00381C00701C00601C00E01C40E01C40E01C40603C
+40304E801F870012127E9115>97 D<FC00001C00001C00001C00001C00001C00001C00001C0000
+1C00001C00001C00001C7C001D86001E03001C01801C01C01C00C01C00E01C00E01C00E01C00E0
+1C00E01C00E01C00C01C01C01C01801E030019060010F800131D7F9C17>I<07E00C3018783078
+70306000E000E000E000E000E000E00060007004300418080C3007C00E127E9112>I<003F0000
+070000070000070000070000070000070000070000070000070000070003E7000C1700180F0030
+0700700700600700E00700E00700E00700E00700E00700E00700600700700700300700180F000C
+370007C7E0131D7E9C17>I<03E00C301818300C700E6006E006FFFEE000E000E000E000600070
+02300218040C1803E00F127F9112>I<00F8018C071E061E0E0C0E000E000E000E000E000E00FF
+E00E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E007FE00F1D809C
+0D>I<00038003C4C00C38C01C3880181800381C00381C00381C00381C001818001C38000C3000
+13C0001000003000001800001FF8001FFF001FFF803003806001C0C000C0C000C0C000C0600180
+3003001C0E0007F800121C7F9215>I<FC00001C00001C00001C00001C00001C00001C00001C00
+001C00001C00001C00001C7C001C87001D03001E03801C03801C03801C03801C03801C03801C03
+801C03801C03801C03801C03801C03801C03801C0380FF9FF0141D7F9C17>I<18003C003C0018
+000000000000000000000000000000FC001C001C001C001C001C001C001C001C001C001C001C00
+1C001C001C001C001C00FF80091D7F9C0C>I<FC00001C00001C00001C00001C00001C00001C00
+001C00001C00001C00001C00001C3FC01C0F001C0C001C08001C10001C20001C40001CE0001DE0
+001E70001C78001C38001C3C001C1C001C0E001C0F001C0F80FF9FE0131D7F9C16>107
+D<FC001C001C001C001C001C001C001C001C001C001C001C001C001C001C001C001C001C001C00
+1C001C001C001C001C001C001C001C001C00FF80091D7F9C0C>I<FC7E07E0001C838838001D01
+9018001E01E01C001C01C01C001C01C01C001C01C01C001C01C01C001C01C01C001C01C01C001C
+01C01C001C01C01C001C01C01C001C01C01C001C01C01C001C01C01C001C01C01C00FF8FF8FF80
+21127F9124>I<FC7C001C87001D03001E03801C03801C03801C03801C03801C03801C03801C03
+801C03801C03801C03801C03801C03801C0380FF9FF014127F9117>I<03F0000E1C0018060030
+0300700380600180E001C0E001C0E001C0E001C0E001C0E001C06001807003803003001806000E
+1C0003F00012127F9115>I<FC7C001D86001E03001C01801C01C01C00C01C00E01C00E01C00E0
+1C00E01C00E01C00E01C01C01C01C01C01801E03001D06001CF8001C00001C00001C00001C0000
+1C00001C00001C0000FF8000131A7F9117>I<FCE01D301E781E781C301C001C001C001C001C00
+1C001C001C001C001C001C001C00FFC00D127F9110>114 D<1F9030704030C010C010E010F800
+7F803FE00FF000F880388018C018C018E010D0608FC00D127F9110>I<04000400040004000C00
+0C001C003C00FFE01C001C001C001C001C001C001C001C001C001C101C101C101C101C100C100E
+2003C00C1A7F9910>I<FC1F801C03801C03801C03801C03801C03801C03801C03801C03801C03
+801C03801C03801C03801C03801C07800C07800E1B8003E3F014127F9117>I<FF07E03C03801C
+01001C01000E02000E020007040007040007040003880003880003D80001D00001D00000E00000
+E00000E00000400013127F9116>I<FF3FCFE03C0F03801C0701801C0701001C0B01000E0B8200
+0E0B82000E1182000711C4000711C4000720C40003A0E80003A0E80003C0680001C0700001C070
+0001803000008020001B127F911E>I<FF07E03C03801C01001C01000E02000E02000704000704
+0007040003880003880003D80001D00001D00000E00000E00000E0000040000040000080000080
+00F08000F10000F300006600003C0000131A7F9116>121 D<FFFFF01401808B15>123
+D E /Fm 4 53 df<0C001C00EC000C000C000C000C000C000C000C000C000C000C000C000C000C
+000C000C00FFC00A137D9211>49 D<1F0060C06060F070F030603000700070006000C001C00180
+020004000810101020207FE0FFE00C137E9211>I<0FC030707038703870380038003000E00FC0
+007000380018001C601CF01CF018E03860701FC00E137F9211>I<006000E000E0016002600660
+0C600860106020606060C060FFFC0060006000600060006003FC0E137F9211>I
+E /Fn 47 124 df<001F83E000F06E3001C078780380F8780300F0300700700007007000070070
+0007007000070070000700700007007000FFFFFF80070070000700700007007000070070000700
+700007007000070070000700700007007000070070000700700007007000070070000700700007
+0070000700700007007000070070007FE3FF001D20809F1B>11 D<003F0000E0C001C0C00381E0
+0701E00701E0070000070000070000070000070000070000FFFFE00700E00700E00700E00700E0
+0700E00700E00700E00700E00700E00700E00700E00700E00700E00700E00700E00700E00700E0
+0700E07FC3FE1720809F19>I<001F81F80000F04F040001C07C06000380F80F000300F00F0007
+00F00F00070070000007007000000700700000070070000007007000000700700000FFFFFFFF00
+070070070007007007000700700700070070070007007007000700700700070070070007007007
+000700700700070070070007007007000700700700070070070007007007000700700700070070
+0700070070070007007007007FE3FE3FF02420809F26>14 D<7038F87CFC7EFC7E743A04020402
+04020804080410081008201040200F0E7E9F17>34 D<0020004000800100020006000C000C0018
+0018003000300030007000600060006000E000E000E000E000E000E000E000E000E000E000E000
+E0006000600060007000300030003000180018000C000C000600020001000080004000200B2E7D
+A112>40 D<800040002000100008000C00060006000300030001800180018001C000C000C000C0
+00E000E000E000E000E000E000E000E000E000E000E000E000C000C000C001C001800180018003
+000300060006000C00080010002000400080000B2E7DA112>I<70F8FCFC740404040808101020
+40060E7C840D>44 D<FFC0FFC00A027F8A0F>I<70F8F8F87005057C840D>I<70F8F8F870000000
+0000000000000070F8F8F87005147C930D>58 D<000100000003800000038000000380000007C0
+000007C0000007C0000009E0000009E0000009E0000010F0000010F0000010F000002078000020
+78000020780000403C0000403C0000403C0000801E0000801E0000FFFE0001000F0001000F0001
+000F00020007800200078002000780040003C00E0003C01F0007E0FFC03FFE1F207F9F22>65
+D<FFFFE0000F80380007801E0007801F0007800F0007800F8007800F8007800F8007800F800780
+0F8007800F0007801F0007801E0007803C0007FFF00007803C0007801E0007800F0007800F8007
+800780078007C0078007C0078007C0078007C0078007C00780078007800F8007800F0007801F00
+0F803C00FFFFF0001A1F7E9E20>I<FFFFE0000F803C0007801E000780070007800380078003C0
+078001E0078001E0078001F0078000F0078000F0078000F8078000F8078000F8078000F8078000
+F8078000F8078000F8078000F8078000F8078000F0078000F0078000F0078001E0078001E00780
+03C0078003800780070007800E000F803C00FFFFE0001D1F7E9E23>68 D<FFFFFF000F800F0007
+800300078003000780010007800180078000800780008007800080078080800780800007808000
+078080000781800007FF8000078180000780800007808000078080000780800007800020078000
+2007800020078000400780004007800040078000C0078000C0078001800F800F80FFFFFF801B1F
+7E9E1F>I<FFFC0FC0078007800780078007800780078007800780078007800780078007800780
+0780078007800780078007800780078007800780078007800FC0FFFC0E1F7F9E10>73
+D<FF803FF807C007C007C0038005E0010005E0010004F001000478010004780100043C0100043C
+0100041E0100040F0100040F010004078100040781000403C1000401E1000401E1000400F10004
+00F1000400790004003D0004003D0004001F0004001F0004000F0004000700040007000E000300
+1F000300FFE001001D1F7E9E22>78 D<07E0800C1980100780300380600180600180E00180E000
+80E00080E00080F00000F000007800007F00003FF0001FFC000FFE0003FF00001F800007800003
+C00003C00001C08001C08001C08001C08001C0C00180C00380E00300F00600CE0C0081F8001221
+7D9F19>83 D<7FFFFFE0780F01E0600F0060400F0020400F0020C00F0030800F0010800F001080
+0F0010800F0010000F0000000F0000000F0000000F0000000F0000000F0000000F0000000F0000
+000F0000000F0000000F0000000F0000000F0000000F0000000F0000000F0000000F0000000F00
+00000F0000001F800007FFFE001C1F7E9E21>I<FFF07FF81FF01F800FC007C00F00078003800F
+00078001000F0007C00100078007C00200078007C00200078007C0020003C009E0040003C009E0
+040003C009E0040003E010F00C0001E010F0080001E010F0080001F02078080000F02078100000
+F02078100000F0403C10000078403C20000078403C20000078C03E2000003C801E4000003C801E
+4000003C801E4000001F000F8000001F000F8000001F000F8000001E00078000000E0007000000
+0E00070000000C000300000004000200002C207F9E2F>87 D<0804100820102010402040208040
+80408040B85CFC7EFC7E7C3E381C0F0E7B9F17>92 D<1FE000303000781800781C00300E00000E
+00000E00000E0000FE00078E001E0E00380E00780E00F00E10F00E10F00E10F01E10781E103867
+200F83C014147E9317>97 D<0E0000FE00000E00000E00000E00000E00000E00000E00000E0000
+0E00000E00000E00000E3E000EC3800F01C00F00E00E00E00E00700E00700E00780E00780E0078
+0E00780E00780E00780E00700E00700E00E00F00E00D01C00CC300083E0015207F9F19>I<03F8
+0E0C1C1E381E380C70007000F000F000F000F000F000F00070007000380138011C020E0C03F010
+147E9314>I<000380003F80000380000380000380000380000380000380000380000380000380
+00038003E380061B801C0780380380380380700380700380F00380F00380F00380F00380F00380
+F003807003807003803803803807801C07800E1B8003E3F815207E9F19>I<03F0000E1C001C0E
+00380700380700700700700380F00380F00380FFFF80F00000F00000F000007000007000003800
+801800800C010007060001F80011147F9314>I<007C00C6018F038F0706070007000700070007
+0007000700FFF00700070007000700070007000700070007000700070007000700070007000700
+070007007FF01020809F0E>I<0000E003E3300E3C301C1C30380E00780F00780F00780F00780F
+00780F00380E001C1C001E380033E0002000002000003000003000003FFE001FFF800FFFC03001
+E0600070C00030C00030C00030C000306000603000C01C038003FC00141F7F9417>I<0E0000FE
+00000E00000E00000E00000E00000E00000E00000E00000E00000E00000E00000E3E000E43000E
+81800F01C00F01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E
+01C00E01C00E01C00E01C0FFE7FC16207F9F19>I<1C001E003E001E001C000000000000000000
+000000000E007E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E
+000E00FFC00A1F809E0C>I<00E001F001F001F000E0000000000000000000000000007007F000
+F00070007000700070007000700070007000700070007000700070007000700070007000700070
+007000706070F060F0C061803F000C28829E0E>I<0E0000FE00000E00000E00000E00000E0000
+0E00000E00000E00000E00000E00000E00000E0FF00E03C00E03000E02000E04000E08000E1000
+0E30000E70000EF8000F38000E1C000E1E000E0E000E07000E07800E03800E03C00E03E0FFCFF8
+15207F9F18>I<0E00FE000E000E000E000E000E000E000E000E000E000E000E000E000E000E00
+0E000E000E000E000E000E000E000E000E000E000E000E000E000E000E00FFE00B20809F0C>I<
+0E1F01F000FE618618000E81C81C000F00F00E000F00F00E000E00E00E000E00E00E000E00E00E
+000E00E00E000E00E00E000E00E00E000E00E00E000E00E00E000E00E00E000E00E00E000E00E0
+0E000E00E00E000E00E00E000E00E00E00FFE7FE7FE023147F9326>I<0E3E00FE43000E81800F
+01C00F01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E
+01C00E01C00E01C0FFE7FC16147F9319>I<01F800070E001C03803801C03801C07000E07000E0
+F000F0F000F0F000F0F000F0F000F0F000F07000E07000E03801C03801C01C0380070E0001F800
+14147F9317>I<0E3E00FEC3800F01C00F00E00E00E00E00F00E00700E00780E00780E00780E00
+780E00780E00780E00700E00F00E00E00F01E00F01C00EC3000E3E000E00000E00000E00000E00
+000E00000E00000E00000E0000FFE000151D7F9319>I<03E0800619801C05803C078038038078
+0380700380F00380F00380F00380F00380F00380F003807003807803803803803807801C0B800E
+138003E380000380000380000380000380000380000380000380000380003FF8151D7E9318>I<
+0E78FE8C0F1E0F1E0F0C0E000E000E000E000E000E000E000E000E000E000E000E000E000E00FF
+E00F147F9312>I<1F9030704030C010C010C010E00078007F803FE00FF00070803880188018C0
+18C018E030D0608F800D147E9312>I<020002000200060006000E000E003E00FFF80E000E000E
+000E000E000E000E000E000E000E000E000E080E080E080E080E080610031001E00D1C7F9B12>
+I<0E01C0FE1FC00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01
+C00E01C00E01C00E01C00E03C00603C0030DC001F1FC16147F9319>I<FF83F81E01E01C00C00E
+00800E00800E008007010007010003820003820003820001C40001C40001EC0000E80000E80000
+700000700000700000200015147F9318>I<FF9FE1FC3C0780701C0300601C0380200E0380400E
+0380400E03C0400707C0800704C0800704E080038861000388710003C8730001D0320001D03A00
+00F03C0000E01C0000E01C0000601800004008001E147F9321>I<7FC3FC0F01E00701C0070180
+03810001C20000E40000EC00007800003800003C00007C00004E000087000107000303800201C0
+0601E01E01E0FF07FE1714809318>I<FF83F81E01E01C00C00E00800E00800E00800701000701
+0003820003820003820001C40001C40001EC0000E80000E8000070000070000070000020000020
+00004000004000004000F08000F08000F100006200003C0000151D7F9318>I<3FFF380E200E20
+1C40384078407000E001E001C00380078007010E011E011C0338027006700EFFFE10147F9314>
+I<FFFFFC1601808C17>I E /Fo 7 117 df<0000E000000000E000000001F000000001F0000000
+01F000000003F800000003F800000006FC00000006FC0000000EFE0000000C7E0000000C7E0000
+00183F000000183F000000303F800000301F800000701FC00000600FC00000600FC00000C007E0
+0000FFFFE00001FFFFF000018003F000018003F000030001F800030001F800060001FC00060000
+FC000E0000FE00FFE00FFFE0FFE00FFFE0231F7E9E28>65 D<07FC001FFF003F0F803F07C03F03
+E03F03E00C03E00003E0007FE007FBE01F03E03C03E07C03E0F803E0F803E0F803E0FC05E07E0D
+E03FF8FE0FE07E17147F9319>97 D<FF0000FF00001F00001F00001F00001F00001F00001F0000
+1F00001F00001F00001F00001F1FC01F7FF01FE0F81F807C1F007E1F003E1F003E1F003F1F003F
+1F003F1F003F1F003F1F003F1F003E1F003E1F007C1F807C1EC1F81C7FE0181F8018207E9F1D>
+I<01FE0007FF801F0FC03E0FC03E0FC07C0FC07C0300FC0000FC0000FC0000FC0000FC0000FC00
+007C00007E00003E00603F00C01F81C007FF0001FC0013147E9317>I<FE3E00FE7F801ECFC01E
+8FC01E8FC01F8FC01F03001F00001F00001F00001F00001F00001F00001F00001F00001F00001F
+00001F0000FFF000FFF00012147E9316>114 D<0FE63FFE701E600EE006E006F800FFC07FF83F
+FC1FFE03FE001FC007C007E007F006F81EFFFCC7F010147E9315>I<0180018001800380038003
+8007800F803F80FFFCFFFC0F800F800F800F800F800F800F800F800F800F800F860F860F860F86
+0F8607CC03F801F00F1D7F9C14>I E /Fp 14 118 df<F8F8F8F8F8383070706060E0050C7A84
+11>44 D<F8F8F8F8F805057A8411>46 D<0000FF00000007FFC000001FFFE000007FFFF00000FF
+01F80001FC00FC0003F0007E0007E0003E000FC01FBE001F807FFF001F00FFFF003E01FFFF003E
+03F0FF007C07E07F807C07C03F807C0F801F80FC0F801F80F81F000F80F81F000F80F81F000F80
+F81F000F80F81F000F80F81F000F80F81F000F80F81F000F80FC0F801F007C0F801F007C07C03E
+007C07E07E003E03F0FC003E01FFF8001F00FFF0001F807FE0000FC01F800007E000000003F000
+000001FC000F8000FF007F00007FFFFE00001FFFF8000007FFE0000000FF0000212A7DA928>64
+D<01FE000FFF803FFFC03FFFE03C03F03001F00001F80000F80000F80000F80000F80000F8007F
+F807FFF81FFFF83FE0F87F00F8FC00F8F800F8F800F8F800F8FC01F87E07F87FFFF83FFFF81FFC
+F80FE0F8151B7E9A1D>97 D<F80000F80000F80000F80000F80000F80000F80000F80000F80000
+F80000F80000F80000F80000F80000F80000F83F00F9FFC0FBFFE0FFFFF0FF07F0FC01F8F800FC
+F8007CF8007CF8007EF8003EF8003EF8003EF8003EF8003EF8003EF8003EF8007CF8007CF8007C
+FC00F8FC01F8FF07F0FFFFE0FBFFC0F9FF80F87E00172A7BA91F>I<007FC001FFF007FFFC0FFF
+FC1FC07C1F00083E00007C00007C00007C0000F80000F80000F80000F80000F80000F80000F800
+007C00007C00007E00003E00001F000C1FC07C0FFFFC07FFFC01FFF0007F80161B7E9A1B>I<00
+003E00003E00003E00003E00003E00003E00003E00003E00003E00003E00003E00003E00003E00
+003E00003E00FC3E03FF3E07FFFE0FFFFE1FC1FE3F007E3E003E7C003E7C003EFC003EF8003EF8
+003EF8003EF8003EF8003EF8003EF8003EFC003E7C003E7C003E3E007E3F00FE1FC1FE0FFFFE07
+FFBE03FF3E00FC3E172A7EA91F>I<007E0003FF8007FFC00FFFE01F83F03F00F03E00787C0078
+7C003878003CFFFFFCFFFFFCFFFFFCFFFFFCF80000F80000F800007800007C00007C00003E0000
+3F000C1FC07C0FFFFC07FFFC01FFF0007F80161B7E9A1B>I<001FC0007FC000FFC001FFC003F0
+0003E00007C00007C00007C00007C00007C00007C00007C00007C00007C000FFFE00FFFE00FFFE
+0007C00007C00007C00007C00007C00007C00007C00007C00007C00007C00007C00007C00007C0
+0007C00007C00007C00007C00007C00007C00007C00007C00007C00007C00007C000122A7FA912
+>I<F80000F80000F80000F80000F80000F80000F80000F80000F80000F80000F80000F80000F8
+0000F80000F80000F83F00F8FF80FBFFC0FFFFE0FF07E0FE03F0FC01F0FC01F0FC01F0F801F0F8
+01F0F801F0F801F0F801F0F801F0F801F0F801F0F801F0F801F0F801F0F801F0F801F0F801F0F8
+01F0F801F0F801F0F801F0142A7BA91F>104 D<F83F00F9FFC0FBFFE0FFFFF0FF07F0FC01F8F8
+00FCF800FCF8007CF8007EF8003EF8003EF8003EF8003EF8003EF8003EF8003EF8007CF8007CF8
+00FCFC00F8FC03F8FF07F0FFFFE0FBFFC0F9FF80F87E00F80000F80000F80000F80000F80000F8
+0000F80000F80000F80000F80000F80000F8000017277B9A1F>112 D<F838F8F8F9F8FBF8FFC0
+FF00FE00FE00FC00FC00F800F800F800F800F800F800F800F800F800F800F800F800F800F800F8
+00F800F8000D1B7B9A14>114 D<03FC001FFF803FFFC07FFFC07C07C0F80080F80000F80000F8
+0000FC00007F80007FF8003FFE001FFF0007FF8000FFC0000FE00007E00003E00003E04003E0E0
+07E0FC0FC0FFFFC07FFF801FFE0003F800131B7E9A17>I<F801F0F801F0F801F0F801F0F801F0
+F801F0F801F0F801F0F801F0F801F0F801F0F801F0F801F0F801F0F801F0F801F0F801F0F801F0
+F801F0F801F0F803F0F803F0FC0FF0FFFFF07FFDF03FF9F01FC1F0141B7B9A1F>117
+D E /Fq 2 104 df<0000F80003C0000F00001E00003C00007800007800007800007800007800
+007800007800007800007800007800007800007800007800007800007800007800007800007800
+00780000780000F00000F00001E000078000FE0000FE000007800001E00000F00000F000007800
+007800007800007800007800007800007800007800007800007800007800007800007800007800
+007800007800007800007800007800007800003C00001E00000F000003C00000F8153C7CAC1E>
+102 D<F800000F000003C00001E00000F000007800007800007800007800007800007800007800
+007800007800007800007800007800007800007800007800007800007800007800007800007800
+003C00003C00001E000007000001F80001F8000700001E00003C00003C00007800007800007800
+007800007800007800007800007800007800007800007800007800007800007800007800007800
+00780000780000780000780000F00001E00003C0000F0000F80000153C7CAC1E>I
+E /Fr 38 122 df<78FCFCFEFE7A02020202040404081010204007127B8511>44
+D<FFFEFFFEFFFE0F037F8E14>I<007F000001C1C0000780F0000F0078000E0038001C001C003C
+001E003C001E003C001E0078000F0078000F0078000F0078000F00F8000F80F8000F80F8000F80
+F8000F80F8000F80F8000F80F8000F80F8000F80F8000F80F8000F80F8000F80F8000F80F8000F
+80F8000F80F8000F8078000F0078000F0078000F0078000F003C001E003C001E003C001E001C00
+1C000E0038000F0078000780F00001C1C000007F000019297EA71E>48 D<00100000700001F000
+0FF000FEF000F0F00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F000
+00F00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F000
+00F00000F00000F00000F00000F00000F00000F00000F00001F8007FFFE07FFFE013287BA71E>
+I<007F000003FFC0000701F0000C00F80010007C001C007C003E007E003E003E003E003E001E00
+3E000C007E0000007C0000007C00000078000000F0000000E0000001C0000007000000FF000000
+01E0000000F0000000780000003C0000003E0000001F0000001F0000001F8000001F8030001F80
+78001F80FC001F80FC001F80FC001F00F8001F0040003F0040003E0030007C001800F8000F01F0
+0003FFC000007F000019297EA71E>51 D<00006000000060000000E0000001E0000001E0000003
+E0000003E0000005E0000009E0000009E0000011E0000021E0000021E0000041E0000081E00000
+81E0000101E0000201E0000201E0000401E0000801E0000801E0001001E0003001E0002001E000
+4001E000C001E000FFFFFF80FFFFFF800001E0000001E0000001E0000001E0000001E0000001E0
+000001E0000001E0000003F000007FFF80007FFF8019287EA71E>I<20000000380000003FFFFF
+803FFFFF803FFFFF007FFFFF006000020040000400400004004000080080001000800020000000
+20000000400000008000000080000001000000030000000200000006000000060000000C000000
+0C0000001C0000001C0000001C0000003800000038000000380000007800000078000000780000
+0078000000F8000000F8000000F8000000F8000000F8000000F8000000F8000000F80000007000
+00192A7DA81E>55 D<007F000001FFC0000381F000060078000C003C001C001C0018000E003800
+0E0038000E0038000E003C000E003C000E003E001C001F8018001FC038000FF0600007F8C00003
+FF800001FF0000007FC00000FFE000030FF8000603FC001C01FE0038007E0030003F0070000F00
+70000780E0000780E0000380E0000380E0000380E0000380F0000300700007007800060038000C
+001E0038000F80F00003FFE000007F000019297EA71E>I<007F000001FFC00007C1E0000F0070
+001E0038001C003C003C001C0078001E0078001E00F8000F00F8000F00F8000F00F8000F00F800
+0F80F8000F80F8000F80F8000F8078000F8078001F803C001F803C001F801C002F800E004F8007
+00CF8003810F80007E0F8000000F0000000F0000000F0000001E0000001E0000001E0000003C00
+1C003C003E0078003E0070003C00E0001801C0001C0780000FFE000003F8000019297EA71E>I<
+00001800000000180000000018000000003C000000003C000000003C000000007E000000007E00
+000000FF000000009F000000009F000000011F800000010F800000010F8000000207C000000207
+C000000207C000000403E000000403E000000403E000000801F000000801F000001801F8000010
+00F800001000F800002000FC000020007C00003FFFFC00007FFFFE000040003E000040003E0000
+80001F000080001F000080001F000100000F800100000F800100000F8002000007C007000007C0
+1F80000FE0FFF000FFFFFFF000FFFF282A7EA92D>65 D<0000FF00100007FFE030001FC0783000
+3E000C7000F80006F001F00003F003E00001F007C00000F00F800000700F800000701F00000030
+3F000000303E000000303E000000107E000000107E000000107C00000000FC00000000FC000000
+00FC00000000FC00000000FC00000000FC00000000FC00000000FC00000000FC000000007C0000
+00007E000000007E000000103E000000103E000000103F000000101F000000200F800000200F80
+00006007C000004003E000008001F000018000F8000300003E000E00001FC038000007FFE00000
+00FF8000242B7DA92B>67 D<FFFFFFC000FFFFFFF80007E000FC0003E0003F0003E0000F8003E0
+0007C003E00003E003E00001F003E00000F003E00000F803E000007C03E000007C03E000007C03
+E000003E03E000003E03E000003E03E000003F03E000003F03E000003F03E000003F03E000003F
+03E000003F03E000003F03E000003F03E000003F03E000003F03E000003E03E000003E03E00000
+7E03E000007C03E000007C03E00000F803E00000F803E00001F003E00003E003E00007C003E000
+0F8003E0001F0007E000FE00FFFFFFF800FFFFFFC00028297EA82E>I<FFFF80FFFF8007F00003
+E00003E00003E00003E00003E00003E00003E00003E00003E00003E00003E00003E00003E00003
+E00003E00003E00003E00003E00003E00003E00003E00003E00003E00003E00003E00003E00003
+E00003E00003E00003E00003E00003E00003E00003E00003E00007F000FFFF80FFFF8011297EA8
+16>73 D<FFFFE000FFFFE00007F0000003E0000003E0000003E0000003E0000003E0000003E000
+0003E0000003E0000003E0000003E0000003E0000003E0000003E0000003E0000003E0000003E0
+000003E0000003E0000003E0000003E0000003E0000003E0000003E0000103E0000103E0000103
+E0000103E0000203E0000203E0000203E0000203E0000603E0000603E0000E03E0001E03E0007C
+07E001FCFFFFFFFCFFFFFFFC20297EA825>76 D<FFE0001FFFFFF0001FFF03F80001F002F80000
+E0027C000040027E000040023E000040021F000040021F800040020F8000400207C000400207E0
+00400203E000400201F000400201F800400200F8004002007C004002007E004002003E00400200
+1F004002001F804002000F8040020007C040020003E040020003E040020001F040020000F84002
+0000F8400200007C400200003E400200003E400200001F400200000FC00200000FC002000007C0
+02000003C002000003C007000001C00F800000C0FFF80000C0FFF800004028297EA82D>78
+D<0001FF0000000F01E000003C0078000078003C0000E0000E0001E0000F0003C0000780078000
+03C00F800003E01F000001F01F000001F03E000000F83E000000F87E000000FC7E000000FC7C00
+00007C7C0000007CFC0000007EFC0000007EFC0000007EFC0000007EFC0000007EFC0000007EFC
+0000007EFC0000007EFC0000007E7C0000007C7E000000FC7E000000FC7E000000FC3E000000F8
+3F000001F81F000001F01F000001F00F800003E007800003C007C00007C003E0000F8000F0001E
+000078003C00003C007800000F01E0000001FF0000272B7DA92E>I<FFFFFF8000FFFFFFF00007
+E000FC0003E0003E0003E0001F0003E0000F8003E0000FC003E00007C003E00007E003E00007E0
+03E00007E003E00007E003E00007E003E00007E003E00007C003E0000FC003E0000F8003E0001F
+0003E0003E0003E001F80003FFFFE00003E000000003E000000003E000000003E000000003E000
+000003E000000003E000000003E000000003E000000003E000000003E000000003E000000003E0
+00000003E000000003E000000003E000000003E000000007F0000000FFFF800000FFFF80000023
+297EA829>I<00FE010003FF83000F81E3001E0037003C001F0038000F007800070070000700F0
+000300F0000300F0000300F0000100F8000100F8000100FC0000007C0000007F0000003FE00000
+1FFF00000FFFE00007FFF80003FFFC00007FFE000007FF0000007F0000001F8000000F80000007
+C0000007C0800003C0800003C0800003C0800003C0C00003C0C0000380C0000380E0000780F000
+0700F8000E00EE001C00C3C07800C1FFF000803FC0001A2B7DA921>83 D<7FFFFFFFF87FFFFFFF
+F87C007C00F870007C003860007C001840007C000840007C0008C0007C000CC0007C000C80007C
+000480007C000480007C000480007C000480007C000400007C000000007C000000007C00000000
+7C000000007C000000007C000000007C000000007C000000007C000000007C000000007C000000
+007C000000007C000000007C000000007C000000007C000000007C000000007C000000007C0000
+00007C000000007C000000007C000000007C000000007C00000000FE000000FFFFFE0000FFFFFE
+0026297EA82B>I<FFFF801FFFFFFF801FFF07F00001F003E00000E003E000004003E000004003
+E000004003E000004003E000004003E000004003E000004003E000004003E000004003E0000040
+03E000004003E000004003E000004003E000004003E000004003E000004003E000004003E00000
+4003E000004003E000004003E000004003E000004003E000004003E000004003E000004003E000
+004003E000004001E000008001F000008001F000008000F000010000780003000078000200003C
+000C00001F0018000007C070000001FFE00000007F0000282A7EA82D>I<FFFE03FFF803FFC0FF
+FE03FFF803FFC00FE0003F80007E0007C0001F0000180003E0001F0000180003E0000F80001000
+03E0000F8000100001F0000F8000200001F0000FC000200001F0000FC000200000F8000FC00040
+0000F80013E000400000F80013E000400000FC0013E000C000007C0033F0008000007C0021F000
+8000007E0021F0008000003E0021F8010000003E0040F8010000003E0040F8010000001F0040F8
+020000001F00807C020000001F00807C020000000F80807C040000000F81003E040000000F8100
+3E0400000007C1003E0800000007C2001F0800000007C2001F0800000003E2001F1000000003E4
+000F9000000003E4000F9000000001F4000FA000000001F80007E000000001F80007E000000000
+F80007C000000000F00003C000000000F00003C000000000700003800000000060000180000000
+0060000180000000006000018000003A2A7FA83D>87 D<01FC00000E0780001001C0003C00E000
+3E00F0003E0078001C00780008007800000078000000780000007800007FF80003E078000F8078
+001F0078003E0078007C00780078007820F8007820F8007820F8007820F800F8207C00F8203C01
+3C401F063FC007F80F001B1A7E991E>97 D<07800000FF800000FF8000000F8000000780000007
+800000078000000780000007800000078000000780000007800000078000000780000007800000
+078000000783F000078C1C0007B0070007A0038007C003C0078001E0078001E0078000F0078000
+F0078000F8078000F8078000F8078000F8078000F8078000F8078000F8078000F0078000F00780
+01F0078001E0078001C007C003C00740078007200E0006181C000407E0001D2A7FA921>I<007F
+8001C0700780080F003C1E007C3C007C3C00387C0010780000F80000F80000F80000F80000F800
+00F80000F80000F800007800007C00003C00043C00041E00080F001007802001C0C0007F00161A
+7E991B>I<00000F000001FF000001FF0000001F0000000F0000000F0000000F0000000F000000
+0F0000000F0000000F0000000F0000000F0000000F0000000F0000000F00003F0F0001C0CF0003
+802F000F001F001E001F001C000F003C000F007C000F0078000F0078000F00F8000F00F8000F00
+F8000F00F8000F00F8000F00F8000F00F8000F0078000F0078000F003C000F003C000F001E001F
+000E002F0007004F8001C18FF8007E0FF81D2A7EA921>I<007E0003C3800700E00E00F01C0070
+3C00783C003878003C78003CF8003CF8003CFFFFFCF80000F80000F80000F80000F80000780000
+7C00003C00043C00041E00080E001007002001C0C0007F00161A7E991B>I<001F000070C000E1
+E001C3E003C3E00381C00780800780000780000780000780000780000780000780000780000780
+00FFFE00FFFE000780000780000780000780000780000780000780000780000780000780000780
+0007800007800007800007800007800007800007800007800007800007800007C000FFFE00FFFE
+00132A7FA912>I<07000F801F801F800F80070000000000000000000000000000000000000007
+807F807F800F800780078007800780078007800780078007800780078007800780078007800780
+0780078007800780FFF8FFF80D297FA811>105 D<0781F800FC00FF860E030700FF98070C0380
+0FA0079003C007A003D001E007C003E001E007C003E001E0078003C001E0078003C001E0078003
+C001E0078003C001E0078003C001E0078003C001E0078003C001E0078003C001E0078003C001E0
+078003C001E0078003C001E0078003C001E0078003C001E0078003C001E0078003C001E0078003
+C001E0078003C001E0FFFC7FFE3FFFFFFC7FFE3FFF301A7F9933>109 D<0783F800FF8C1C00FF
+900E000FA0070007A0078007C0078007C007800780078007800780078007800780078007800780
+078007800780078007800780078007800780078007800780078007800780078007800780078007
+800780078007800780FFFCFFFCFFFCFFFC1E1A7F9921>I<007F000001C1C000070070000E0038
+001C001C003C001E003C001E0078000F0078000F00F8000F80F8000F80F8000F80F8000F80F800
+0F80F8000F80F8000F80F8000F8078000F0078000F003C001E003C001E001E003C000E00380007
+00700001C1C000007F0000191A7E991E>I<0783F000FF8C1C00FFB00F0007A0078007C003C007
+8003E0078001E0078001F0078001F0078000F8078000F8078000F8078000F8078000F8078000F8
+078000F8078000F0078001F0078001F0078001E0078003C007C003C007C0078007A00E0007983C
+000787E00007800000078000000780000007800000078000000780000007800000078000000780
+000007800000FFFC0000FFFC00001D267F9921>I<0787C0FF98E0FF91F00FA1F007C1F007C0E0
+07C000078000078000078000078000078000078000078000078000078000078000078000078000
+07800007800007800007800007C000FFFE00FFFE00141A7F9917>114 D<07F8401C06C03001C0
+6000C06000C0E00040E00040F00040F800007E00007FF0003FFE000FFF0003FF80003FC00007C0
+8001E08001E0C000E0C000E0C000E0E000C0F001C0F80180C4070083F800131A7E9918>I<0080
+000080000080000080000180000180000180000380000380000780000F80001FFF80FFFF800780
+000780000780000780000780000780000780000780000780000780000780000780000780000780
+4007804007804007804007804007804007804003C08001C08000E100003E0012257FA417>I<07
+800780FF80FF80FF80FF800F800F80078007800780078007800780078007800780078007800780
+078007800780078007800780078007800780078007800780078007800780078007800780078007
+8007800F8007800F800380178001C027C000E047FC003F87FC1E1A7F9921>I<FFF00FF8FFF00F
+F80F8003C0078003800780010003C0020003C0020003E0020001E0040001E0040000F0080000F0
+080000F818000078100000781000003C2000003C2000003E6000001E4000001E4000000F800000
+0F8000000700000007000000070000000200001D1A7F9920>I<FFF00FF8FFF00FF80F8003C007
+8003800780010003C0020003C0020003E0020001E0040001E0040000F0080000F0080000F81800
+0078100000781000003C2000003C2000003E6000001E4000001E4000000F8000000F8000000700
+00000700000007000000020000000200000004000000040000000400000008000070080000F810
+0000F8100000F8200000F0400000608000001F0000001D267F9920>121
+D E /Fs 24 124 df<00000FF03F000000780CE0800001E00FC3C00003801F87C00007003F07C0
+000F003F03C0001E001E0100001E001E0000001E001E0000003C003C0000003C003C0000003C00
+3C0000003C003C0000003C003C0000003C003C00000078007800000FFFFFFFF0000FFFFFFFF000
+00780078000000780078000000780078000000F000F0000000F000F0000000F000F0000000F000
+F0000000F000F0000000F000F0000001E001E0000001E001E0000001E001E0000001E001E00000
+01E001E0000001E001E0000003C003C0000003C003C0000003C003C0000003C003C0000003C003
+C0000003C003C0000007C007C000007FF87FFE0000FFF87FFE00002A2A7FA923>11
+D<387C7EFC7C3807067B8511>46 D<00000FF00100007FFE030001FC07070007E0018E001F8000
+5E003E00003E007C00003E00F800001E01F000001E03E000000C07C000000C07C000000C0F8000
+000C1F8000000C1F0000000C3F000000083F000000007E000000007E000000007E000000007E00
+000000FC00000000FC00000000FC00000000FC00000000FC00000000FC00000000FC00000000FC
+000000207C000000207C000000207C000000403E000000403E000000801E000000801F00000100
+0F8000020007C000040003E000180001F0003000007E01E000003FFF80000007FC0000282B7AA9
+2B>67 D<01FFFFFFFF03FFFFFFFF000FC0007F000F80000F000F800007000F800007000F800003
+000F800003001F000003001F000003001F000001001F000001001F000801001F000801003E0010
+00003E001000003E001000003E003000003E00F000003FFFF000007FFFE000007C00E000007C00
+6000007C006000007C002000007C00200200F800400400F800400400F800000400F800000800F8
+00000800F800001801F000001001F000003001F000003001F000007001F00000E001F00003E003
+F0000FE0FFFFFFFFC0FFFFFFFFC028297EA829>69 D<01FFFF03FFFE03FFFF07FFFE000FC0001F
+80000F80001F00000F80001F00000F80001F00000F80001F00000F80001F00001F00003E00001F
+00003E00001F00003E00001F00003E00001F00003E00001F00003E00003E00007C00003E00007C
+00003E00007C00003E00007C00003E00007C00003FFFFFFC00007FFFFFF800007C0000F800007C
+0000F800007C0000F800007C0000F800007C0000F80000F80001F00000F80001F00000F80001F0
+0000F80001F00000F80001F00000F80001F00001F00003E00001F00003E00001F00003E00001F0
+0003E00001F00003E00001F00003E00003F00007E000FFFF81FFFF00FFFF81FFFF002F297EA82D
+>72 D<01FFFF800003FFFF8000000FC00000000F800000000F800000000F800000000F80000000
+0F800000001F000000001F000000001F000000001F000000001F000000001F000000003E000000
+003E000000003E000000003E000000003E000000003E000000007C000000007C000000007C0000
+00007C000000007C000000007C00002000F800004000F800004000F800004000F800008000F800
+008000F800018001F000018001F000030001F000030001F000070001F0000E0001F0003E0003F0
+01FE00FFFFFFFC00FFFFFFFC0023297EA825>76 D<0001FC020007FF06001E038E003800DC0070
+007C00E0003C01E0001C03C0001C03C0001C0380000807800008078000080780000807C0000807
+C0000007E0000003F0000003FE000001FFE00001FFFE0000FFFF00003FFF80000FFFC00000FFE0
+00000FE0000003F0000001F0000001F0000001F0200000F0200000F0200000F0200000E0600001
+E0600001E0700001C0700003C0780007807C000700E6001E00E3C07C00C1FFF000803FC0001F2B
+7DA921>83 D<003FC00001C0F0000200380007803C0007C01E000F801E0007801E0002001E0000
+001E0000001E0000001E00001FFC0001F83C0007C03C000F803C001E003C003E003C007C007820
+F8007820F8007820F8007820F800F820F80178407C0278403E0C3F8007F01E001B1A7D991E>97
+D<01E000003FE000003FE0000003C0000003C0000003C0000003C0000003C0000003C000000780
+000007800000078000000780000007800000078000000F0000000F07E0000F1838000F600E000F
+800F000F0007001F0007801E0007C01E0003C01E0003C01E0003C01E0003C03C0007C03C0007C0
+3C0007C03C0007C03C0007803C000F8078000F8078000F0078001E0078001C0078003800740070
+00E200E000C103800080FE00001A2A7AA921>I<001FF000700C01E00203801E07001F0F003E1E
+001E3E00083C00007C00007C0000780000F80000F80000F80000F80000F80000F80000F8000078
+00087800083C00101C00200E004007038001FC00181A7C991B>I<0000007800000FF800000FF8
+000000F0000000F0000000F0000000F0000000F0000000F0000001E0000001E0000001E0000001
+E0000001E0000001E0000003C0000FC3C0007833C001E00BC003800BC0070007C00F0007801E00
+07803E0007803C0007807C0007807C00078078000F00F8000F00F8000F00F8000F00F8000F00F8
+000F00F8001E00F8001E0078001E0078001E0038003E001C005E000E01BE0007063FE001F83FE0
+1D2A7CA921>I<001F8000F0E001C03003803807003C0E001C1E001C3E001E3C001E7C001E7C00
+1EFFFFFCF80000F80000F80000F80000F80000F80000F800007800087800083800101C00200E00
+C007030001FC00171A7C991B>I<0000003C0007E0C2003C390E00701E0E00E01E0401E01E0003
+E01F0003C01F0007C01F0007C01F0007C01F0007C01E0007C03E0007C03C0003C0780001C07000
+02E1E000063F000004000000040000000C0000000C0000000E00000007FFF00003FFFC0003FFFE
+000E001F0018000780380003807000038070000380E0000380E0000380E0000380E00007007000
+0E0030001C001C0038000F01E00001FF00001F287F9A1E>103 D<000F000001FF000001FF0000
+001E0000001E0000001E0000001E0000001E0000001E0000003C0000003C0000003C0000003C00
+00003C0000003C00000078000000783F800078C1C0007900E0007A00F0007C00F000F800F000F8
+00F000F000F000F000F000F000F000F000F001E001E001E001E001E001E001E001E001E001E001
+E001E003C003C003C003C003C003C003C003C003C003C003C003C007C007C07FFC7FFCFFFCFFFC
+1E2A7FA921>I<001C003E003E007E003E001C0000000000000000000000000000000000000078
+07F807F800F800F800F000F000F000F000F000F001E001E001E001E001E001E003C003C003C003
+C003C003C007C07FF8FFF80F297FA811>I<00781FC00FE00FF860E030700FF98070C03800FA00
+79003C00FC007A003C00F4007A003C00F8007C003C00F00078003C00F00078003C00F00078003C
+00F00078003C01E000F0007801E000F0007801E000F0007801E000F0007801E000F0007801E000
+F0007803C001E000F003C001E000F003C001E000F003C001E000F003C001E000F003C001E000F0
+07C003E001F07FFC3FFE1FFFFFFC7FFE3FFF301A7F9933>109 D<00783F800FF8C1C00FF900E0
+00FA00F000FC00F000F800F000F800F000F000F000F000F000F000F000F000F001E001E001E001
+E001E001E001E001E001E001E001E001E003C003C003C003C003C003C003C003C003C003C003C0
+03C007C007C07FFC7FFCFFFCFFFC1E1A7F9921>I<001FC0000070700001C01C0003800E000700
+0E000E000F001E0007803C0007803C0007807C0007807C00078078000F80F8000F80F8000F80F8
+000F80F8000F80F8001F00F8001F00F8001E0078003C0078003C00380078001C00F0000E01C000
+0707800001FC0000191A7C991E>I<001E0FC00003FE30700003FEC03C00003F001E00001E001E
+00003E000F00003C000F80003C000F80003C000F80003C000F80003C000F800078000F80007800
+0F800078000F800078000F800078000F000078001F0000F0001F0000F0003E0000F0003C0000F0
+00780000F000F00000F800E00001E403C00001E207000001E1FC000001E000000001E000000001
+E000000003C000000003C000000003C000000003C000000003C000000003C000000007C0000000
+7FFC000000FFFC0000002126819921>I<00787C0FF98E0FFA1F00FA1F00FC1E00F81E00F80000
+F80000F00000F00000F00001E00001E00001E00001E00001E00001E00003C00003C00003C00003
+C00003C00003C00007C0007FFE00FFFE00181A7F9917>114 D<003F8401C06C03001C06000C0E
+000C0C00081C00081E00081F00001FC0000FFE0007FF8003FFC000FFE0000FF00001F02000F060
+00706000706000706000707000607000C0E80180C6070081FC00161A7E9918>I<002000002000
+00200000600000400000C00000C00001C00001C00003C0000780001FFF80FFFF80078000078000
+0780000F00000F00000F00000F00000F00000F00001E00001E00001E00001E00001E01001E0100
+3C02003C02003C02003C02003C04001C04001C08000E100003E00011257BA417>I<07800780FF
+80FF80FF80FF800F800F800F800F800F000F000F000F000F000F000F000F000F000F000F000F00
+1E001E001E001E001E001E001E001E001E001E001E001E003C003C003C003C003C003C003C007C
+003C007C003C00BC001C017C000E067FC003F87FC01A1A7B9921>I<FFFFFFF81D017D901E>123
+D E /Ft 80 125 df<001F83E000706E3000C07C780180F8780380F07807007000070070000700
+7000070070000700700007007000070070000700700007007000FFFFFFC0070070000700700007
+007000070070000700700007007000070070000700700007007000070070000700700007007000
+070070000700700007007000070070000700700007007000070078007FE3FF801D2380A21C>11
+D<001FC0000070200000C010000180380003807800070078000700300007000000070000000700
+000007000000070000000700000007000000FFFFF8000700780007003800070038000700380007
+003800070038000700380007003800070038000700380007003800070038000700380007003800
+07003800070038000700380007003800070038007FE1FF80192380A21B>I<001FD80000703800
+00C078000180780003807800070038000700380007003800070038000700380007003800070038
+000700380007003800FFFFF8000700380007003800070038000700380007003800070038000700
+380007003800070038000700380007003800070038000700380007003800070038000700380007
+00380007003800070038007FF3FF80192380A21B>I<000FC07F00007031C08000E00B00400180
+1E00E003803E01E007003C01E007001C00C007001C000007001C000007001C000007001C000007
+001C000007001C000007001C0000FFFFFFFFE007001C01E007001C00E007001C00E007001C00E0
+07001C00E007001C00E007001C00E007001C00E007001C00E007001C00E007001C00E007001C00
+E007001C00E007001C00E007001C00E007001C00E007001C00E007001C00E007001C00E07FF1FF
+CFFE272380A229>I<000FE07F60007011C0E000E01B01E001803E01E003803E01E007001C00E0
+07001C00E007001C00E007001C00E007001C00E007001C00E007001C00E007001C00E007001C00
+E0FFFFFFFFE007001C00E007001C00E007001C00E007001C00E007001C00E007001C00E007001C
+00E007001C00E007001C00E007001C00E007001C00E007001C00E007001C00E007001C00E00700
+1C00E007001C00E007001C00E007001C00E007001C00E07FF1FFCFFE272380A229>I<003C0000
+00006200000000C200000001810000000181000000038100000003810000000381000000038100
+0000038200000003820000000384000000038800000001C800000001D000000001E003FF8001C0
+007C0000E000380001E000300001F0002000027000400004700040000838008000183C00800030
+1C010000701E020000700E020000F007040000F007880000F003880000F001D00100F000E00100
+78007003003800B802003C031C04000E0C0E0C0003F003F00021257EA326>38
+D<70F8FCFC7404040404080810102040060F7CA20E>I<00200040008001000300060004000C00
+0C00180018003000300030007000600060006000E000E000E000E000E000E000E000E000E000E0
+00E000E000E000E0006000600060007000300030003000180018000C000C000400060003000100
+0080004000200B327CA413>I<800040002000100018000C000400060006000300030001800180
+018001C000C000C000C000E000E000E000E000E000E000E000E000E000E000E000E000E000E000
+C000C000C001C0018001800180030003000600060004000C00180010002000400080000B327DA4
+13>I<70F8FCFC7404040404080810102040060F7C840E>44 D<FFE0FFE00B027F8B10>I<70F8F8
+F87005057C840E>I<000080000180000180000300000300000300000600000600000600000C00
+000C00000C0000180000180000180000300000300000300000600000600000600000C00000C000
+00C0000180000180000180000180000300000300000300000600000600000600000C00000C0000
+0C0000180000180000180000300000300000300000600000600000600000C00000C00000C00000
+11317DA418>I<01F000071C000C06001803003803803803807001C07001C07001C07001C0F001
+E0F001E0F001E0F001E0F001E0F001E0F001E0F001E0F001E0F001E0F001E0F001E0F001E0F001
+E07001C07001C07001C07803C03803803803801C07000C0600071C0001F00013227EA018>I<00
+8003800F80F3800380038003800380038003800380038003800380038003800380038003800380
+0380038003800380038003800380038003800380038007C0FFFE0F217CA018>I<03F0000C1C00
+1007002007804003C04003C08003E0F003E0F801E0F801E0F801E02003E00003E00003C00003C0
+000780000700000E00001C0000180000300000600000C000018000010000020020040020080020
+1800603000403FFFC07FFFC0FFFFC013217EA018>I<03F8000C1E001007002007804007C07807
+C07803C07807C03807C0000780000780000700000F00000E0000380003F000001C00000F000007
+800007800003C00003C00003E02003E07003E0F803E0F803E0F003C04003C0400780200780100F
+000C1C0003F00013227EA018>I<000200000600000E00000E00001E00001E00002E00004E0000
+4E00008E00008E00010E00020E00020E00040E00040E00080E00100E00100E00200E00200E0040
+0E00800E00FFFFF8000E00000E00000E00000E00000E00000E00000E00001F0001FFF015217FA0
+18>I<1000801E07001FFF001FFE001FF80013E000100000100000100000100000100000100000
+10F800130E001407001803801003800001C00001C00001E00001E00001E00001E07001E0F001E0
+F001E0E001C08001C04003C04003802007001006000C1C0003F00013227EA018>I<007E0001C1
+000300800601C00E03C01C03C0180180380000380000780000700000700000F0F800F30C00F406
+00F40300F80380F801C0F001C0F001E0F001E0F001E0F001E0F001E07001E07001E07001E03801
+C03801C01803801C03000C0600070C0001F00013227EA018>I<4000006000007FFFE07FFFC07F
+FFC0400080C0010080010080020080020000040000080000080000100000300000200000600000
+600000600000E00000C00000C00001C00001C00001C00001C00003C00003C00003C00003C00003
+C00003C00003C00003C00001800013237DA118>I<01F800060E000803001001802001802000C0
+6000C06000C06000C07000C07801803E01003F02001FC4000FF80003F80003FC00067F00083F80
+100F803007C06001C06000E0C000E0C00060C00060C00060C000606000406000C0300080180300
+0E0E0003F00013227EA018>I<01F000060C000C0600180700380380700380700380F001C0F001
+C0F001C0F001E0F001E0F001E0F001E0F001E07001E07003E03803E01805E00C05E00619E003E1
+E00001C00001C00001C0000380000380300300780700780600700C002018001030000FC0001322
+7EA018>I<70F8F8F870000000000000000000000070F8F8F87005157C940E>I<70F8F8F8700000
+00000000000000000070F8F8F87808080808101010204040051F7C940E>I<07E01838201C400E
+800FF00FF00FF00F000F000E001C00380030006000C000C0008000800180010001000100010001
+00010000000000000000000000038007C007C007C0038010237DA217>63
+D<0001800000018000000180000003C0000003C0000003C0000005E0000005E000000DF0000008
+F0000008F0000010F800001078000010780000203C0000203C0000203C0000401E0000401E0000
+401E0000800F0000800F0000FFFF000100078001000780030007C0020003C0020003C0040003E0
+040001E0040001E00C0000F00C0000F03E0001F8FF800FFF20237EA225>65
+D<FFFFF8000F800E0007800780078003C0078003E0078001E0078001F0078001F0078001F00780
+01F0078001F0078001E0078003E0078007C007800F8007803E0007FFFE0007800780078003C007
+8001E0078001F0078000F0078000F8078000F8078000F8078000F8078000F8078000F8078001F0
+078001F0078003E0078007C00F800F00FFFFFC001D227EA123>I<0007E0100038183000E00630
+01C00170038000F0070000F00E0000701E0000701C0000303C0000303C0000307C000010780000
+1078000010F8000000F8000000F8000000F8000000F8000000F8000000F8000000F80000007800
+0000780000107C0000103C0000103C0000101C0000201E0000200E000040070000400380008001
+C0010000E0020000381C000007E0001C247DA223>I<FFFFF0000F801E0007800700078003C007
+8001C0078000E0078000F007800078078000780780007C0780003C0780003C0780003C0780003E
+0780003E0780003E0780003E0780003E0780003E0780003E0780003E0780003E0780003C078000
+3C0780007C0780007807800078078000F0078000E0078001E0078003C0078007000F801E00FFFF
+F8001F227EA125>I<FFFFFFC00F8007C0078001C0078000C00780004007800040078000600780
+0020078000200780002007802020078020000780200007802000078060000780E00007FFE00007
+80E000078060000780200007802000078020000780200807800008078000080780001007800010
+07800010078000300780003007800070078000E00F8003E0FFFFFFE01D227EA121>I<FFFFFFC0
+0F8007C0078001C0078000C0078000400780004007800060078000200780002007800020078020
+20078020000780200007802000078060000780E00007FFE0000780E00007806000078020000780
+200007802000078020000780000007800000078000000780000007800000078000000780000007
+800000078000000FC00000FFFE00001B227EA120>I<0007F008003C0C1800E0021801C001B803
+8000F8070000780F0000381E0000381E0000183C0000183C0000187C0000087800000878000008
+F8000000F8000000F8000000F8000000F8000000F8000000F8000000F8001FFF780000F8780000
+787C0000783C0000783C0000781E0000781E0000780F00007807000078038000B801C000B800E0
+0318003C0C080007F00020247DA226>I<FFFC3FFF0FC003F0078001E0078001E0078001E00780
+01E0078001E0078001E0078001E0078001E0078001E0078001E0078001E0078001E0078001E007
+8001E007FFFFE0078001E0078001E0078001E0078001E0078001E0078001E0078001E0078001E0
+078001E0078001E0078001E0078001E0078001E0078001E0078001E00FC003F0FFFC3FFF20227E
+A125>I<FFFC0FC007800780078007800780078007800780078007800780078007800780078007
+80078007800780078007800780078007800780078007800780078007800FC0FFFC0E227EA112>
+I<03FFF0001F00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F
+00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F
+00700F00F80F00F80F00F80E00F01E00401C0020380018700007C00014237EA119>I<FFFC03FF
+000FC000F800078000600007800040000780008000078001000007800200000780040000078008
+0000078010000007802000000780400000078080000007818000000783C000000787E000000789
+E000000788F000000790F0000007A078000007C03C000007803C000007801E000007800F000007
+800F00000780078000078007C000078003C000078001E000078001E000078000F000078000F800
+0FC000FC00FFFC07FF8021227EA126>I<FFFE00000FC000000780000007800000078000000780
+000007800000078000000780000007800000078000000780000007800000078000000780000007
+800000078000000780000007800000078000000780000007800000078000800780008007800080
+07800080078001800780018007800100078003000780030007800F000F803F00FFFFFF0019227E
+A11E>I<FFC00003FF0FC00003F007C00003E005E00005E005E00005E004F00009E004F00009E0
+04F00009E004780011E004780011E004780011E0043C0021E0043C0021E0043C0021E0041E0041
+E0041E0041E0040F0081E0040F0081E0040F0081E004078101E004078101E004078101E00403C2
+01E00403C201E00401E401E00401E401E00401E401E00400F801E00400F801E00400F801E00400
+7001E00E007001E01F007003F0FFE0203FFF28227EA12D>I<FF8007FF07C000F807C0007005E0
+002004F0002004F0002004780020047C0020043C0020041E0020041F0020040F00200407802004
+0780200403C0200401E0200401E0200400F0200400F8200400782004003C2004003E2004001E20
+04000F2004000F20040007A0040003E0040003E0040001E0040001E0040000E00E0000601F0000
+60FFE0002020227EA125>I<000FE00000783C0000E00E0003C00780078003C00F0001E00E0000
+E01E0000F03C0000783C0000787C00007C7C00007C7800003C7800003CF800003EF800003EF800
+003EF800003EF800003EF800003EF800003EF800003EF800003E7800003C7C00007C7C00007C3C
+0000783E0000F81E0000F00F0001E00F0001E0078003C003C0078000E00E0000783C00000FE000
+1F247DA226>I<FFFFF0000F803C0007800F0007800780078007C0078003C0078003E0078003E0
+078003E0078003E0078003E0078003E0078003C0078007C00780078007800F0007803C0007FFF0
+000780000007800000078000000780000007800000078000000780000007800000078000000780
+0000078000000780000007800000078000000FC00000FFFC00001B227EA121>I<000FE0000078
+3C0000E00E0003C00780078003C00F0001E00E0000E01E0000F03E0000F83C0000787C00007C7C
+00007C7800003C7800003CF800003EF800003EF800003EF800003EF800003EF800003EF800003E
+F800003EF800003E7800003C7C00007C7C00007C3C0000783C0000781E0380F00E0420E00F0801
+E0078813C003C8178000E80E00007C3C02000FEC0200000C0200000C0200000E0600000F0E0000
+07FC000007FC000007F8000003F8000001E01F2D7DA226>I<FFFFE000000F803C000007800E00
+000780078000078007C000078003C000078003E000078003E000078003E000078003E000078003
+E000078003C000078007C000078007800007800E000007803C000007FFE0000007807000000780
+38000007801C000007801E000007800E000007800F000007800F000007800F000007800F000007
+800F800007800F800007800F800007800F808007800FC080078007C0800FC003C100FFFC01E200
+0000007C0021237EA124>I<03F0200C0C601802603001E07000E0600060E00060E00060E00020
+E00020E00020F00000F000007800007F00003FF0001FFE000FFF0003FF80003FC00007E00001E0
+0000F00000F0000070800070800070800070800070C00060C00060E000C0F000C0C80180C60700
+81FC0014247DA21B>I<7FFFFFF87807807860078018400780084007800840078008C007800C80
+078004800780048007800480078004000780000007800000078000000780000007800000078000
+000780000007800000078000000780000007800000078000000780000007800000078000000780
+000007800000078000000780000007800000078000000FC00003FFFF001E227EA123>I<FFFC07
+FF0FC000F807800070078000200780002007800020078000200780002007800020078000200780
+002007800020078000200780002007800020078000200780002007800020078000200780002007
+80002007800020078000200780002007800020078000200380004003C0004003C0004001C00080
+00E000800060010000300600001C08000003F00020237EA125>I<FFF0007FC01F80001F000F00
+000C000780000C000780000800078000080003C000100003C000100003E000300001E000200001
+E000200000F000400000F000400000F000400000780080000078008000007C018000003C010000
+003C010000001E020000001E020000001F020000000F040000000F040000000F8C000000078800
+0000078800000003D000000003D000000003F000000001E000000001E000000000C000000000C0
+00000000C0000022237FA125>I<FFF03FFC03FE1F8007E000F80F0003C000700F0003C000200F
+0003C00020078001E00040078001E00040078001E0004003C002F0008003C002F0008003C002F0
+008001E00478010001E00478010001E00478010000F0083C020000F0083C020000F0083C020000
+F8183E06000078101E04000078101E0400007C101E0400003C200F0800003C200F0800003C200F
+0800001E40079000001E40079000001E40079000000F8003E000000F8003E000000F8003E00000
+070001C00000070001C00000070001C0000003000180000002000080002F237FA132>I<7FF807
+FF0007E001F80003C000E00003E000C00001E000800000F001000000F80300000078020000007C
+040000003E0C0000001E080000001F100000000FB000000007A000000007C000000003E0000000
+01E000000001F000000003F80000000278000000047C0000000C3E000000081E000000101F0000
+00300F80000020078000004007C00000C003E000008001E000010001F000030000F000070000F8
+001F8001FC00FFE007FFC022227FA125>I<FEFEC0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0
+C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0FEFE07317BA40E>91
+D<FEFE060606060606060606060606060606060606060606060606060606060606060606060606
+060606060606060606FEFE07317FA40E>93 D<0FE0001838003C0C003C0E001807000007000007
+0000070000FF0007C7001E07003C0700780700700700F00708F00708F00708F00F087817083C23
+900FC1E015157E9418>97 D<0E0000FE00001E00000E00000E00000E00000E00000E00000E0000
+0E00000E00000E00000E00000E00000E1F000E61C00E80600F00300E00380E003C0E001C0E001E
+0E001E0E001E0E001E0E001E0E001E0E001E0E001C0E003C0E00380F00700C80600C41C0083F00
+17237FA21B>I<01FE000703000C07801C0780380300780000700000F00000F00000F00000F000
+00F00000F00000F000007000007800403800401C00800C010007060001F80012157E9416>I<00
+00E0000FE00001E00000E00000E00000E00000E00000E00000E00000E00000E00000E00000E000
+00E001F8E00704E00C02E01C01E03800E07800E07000E0F000E0F000E0F000E0F000E0F000E0F0
+00E0F000E07000E07800E03800E01801E00C02E0070CF001F0FE17237EA21B>I<01FC00070700
+0C03801C01C03801C07801E07000E0F000E0FFFFE0F00000F00000F00000F00000F00000700000
+7800203800201C00400E008007030000FC0013157F9416>I<003C00C6018F038F030F07000700
+0700070007000700070007000700FFF80700070007000700070007000700070007000700070007
+0007000700070007000700070007807FF8102380A20F>I<00007001F198071E180E0E181C0700
+1C07003C07803C07803C07803C07801C07001C07000E0E000F1C0019F000100000100000180000
+1800001FFE000FFFC00FFFE03800F0600030400018C00018C00018C000186000306000303800E0
+0E038003FE0015217F9518>I<0E0000FE00001E00000E00000E00000E00000E00000E00000E00
+000E00000E00000E00000E00000E00000E1F800E60C00E80E00F00700F00700E00700E00700E00
+700E00700E00700E00700E00700E00700E00700E00700E00700E00700E00700E00700E0070FFE7
+FF18237FA21B>I<1C001E003E001E001C00000000000000000000000000000000000E00FE001E
+000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E00FFC00A22
+7FA10E>I<01C003E003E003E001C00000000000000000000000000000000001E00FE001E000E0
+00E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000
+E000E000E060E0F0C0F18061803E000B2C82A10F>I<0E0000FE00001E00000E00000E00000E00
+000E00000E00000E00000E00000E00000E00000E00000E00000E03FC0E01F00E01C00E01800E02
+000E04000E08000E10000E38000EF8000F1C000E1E000E0E000E07000E07800E03C00E01C00E01
+E00E00F00E00F8FFE3FE17237FA21A>I<0E00FE001E000E000E000E000E000E000E000E000E00
+0E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E
+000E000E000E00FFE00B237FA20E>I<0E1FC07F00FE60E183801E807201C00F003C00E00F003C
+00E00E003800E00E003800E00E003800E00E003800E00E003800E00E003800E00E003800E00E00
+3800E00E003800E00E003800E00E003800E00E003800E00E003800E00E003800E00E003800E0FF
+E3FF8FFE27157F942A>I<0E1F80FE60C01E80E00F00700F00700E00700E00700E00700E00700E
+00700E00700E00700E00700E00700E00700E00700E00700E00700E00700E0070FFE7FF18157F94
+1B>I<01FC000707000C01801800C03800E0700070700070F00078F00078F00078F00078F00078
+F00078F000787000707800F03800E01C01C00E038007070001FC0015157F9418>I<0E1F00FE61
+C00E80600F00700E00380E003C0E001C0E001E0E001E0E001E0E001E0E001E0E001E0E001E0E00
+3C0E003C0E00380F00700E80E00E41C00E3F000E00000E00000E00000E00000E00000E00000E00
+000E00000E0000FFE000171F7F941B>I<01F8200704600E02601C01603801E07800E07800E0F0
+00E0F000E0F000E0F000E0F000E0F000E0F000E07000E07800E03801E01C01E00C02E0070CE001
+F0E00000E00000E00000E00000E00000E00000E00000E00000E00000E0000FFE171F7E941A>I<
+0E3CFE461E8F0F0F0F060F000E000E000E000E000E000E000E000E000E000E000E000E000E000F
+00FFF010157F9413>I<0F8830786018C018C008C008E008F0007F803FE00FF001F8003C801C80
+0C800CC00CC008E018D0308FC00E157E9413>I<02000200020002000600060006000E001E003E
+00FFF80E000E000E000E000E000E000E000E000E000E000E000E040E040E040E040E040E040708
+030801F00E1F7F9E13>I<0E0070FE07F01E00F00E00700E00700E00700E00700E00700E00700E
+00700E00700E00700E00700E00700E00700E00700E00F00E00F006017003827800FC7F18157F94
+1B>I<FFC1FE1E00780E00300E00200E002007004007004003808003808003808001C10001C100
+00E20000E20000E20000740000740000380000380000380000100017157F941A>I<FF8FF8FF1E
+01E03C1C01C0180E01C0180E01E0100E01E0100702602007027020070270200384304003843840
+0384384001C8188001C81C8001C81C8000F00D0000F00F0000F00F000060060000600600006006
+0020157F9423>I<FF83FE1F01F00E00C007008003810003830001C20000E40000780000780000
+3800003C00004E00008E000187000103800201C00401E00C00E03E01F0FF03FE17157F941A>I<
+FFC1FE1E00780E00300E00200E002007004007004003808003808003808001C10001C10000E200
+00E20000E200007400007400003800003800003800001000001000002000002000002000004000
+F04000F08000F180004300003C0000171F7F941A>I<3FFFC0380380300780200700600E00401C
+00403C0040380000700000E00001E00001C0000380400700400F00400E00C01C00803800807801
+80700780FFFF8012157F9416>I<FFFFFE1701808C18>I<FFFFFFFFFFFF3001808C31>I
+E /Fu 35 124 df<0001E0000003E000000FE000007FE0001FFFE000FFFFE000FFBFE000E03FE0
+00003FE000003FE000003FE000003FE000003FE000003FE000003FE000003FE000003FE000003F
+E000003FE000003FE000003FE000003FE000003FE000003FE000003FE000003FE000003FE00000
+3FE000003FE000003FE000003FE000003FE000003FE000003FE000003FE000003FE000003FE000
+003FE000003FE000003FE000003FE000003FE000003FE0007FFFFFF07FFFFFF07FFFFFF01C2E7A
+AD29>49 D<003FF00001FFFE0007FFFF800FC07FE01E001FF03C000FF87F0007FC7F8007FEFFC0
+07FEFFC003FEFFC003FFFFC003FF7F8003FF7F8003FF3F0003FF000003FF000003FE000003FE00
+0007FC000007FC00000FF800000FF000001FE000001FC000003F8000007F000000FE000001F800
+0001F0000003E00000078007000F0007001E0007003C000F0078000E00F0000E01C0001E03FFFF
+FE07FFFFFE0FFFFFFE1FFFFFFE3FFFFFFE7FFFFFFCFFFFFFFCFFFFFFFCFFFFFFFC202E7CAD29>
+I<000FFC0000007FFF800001F01FE00003C00FF000070007F8000FE007FC000FF007FC001FF007
+FE001FF807FE001FF807FE001FF807FE001FF807FE000FF007FC0007E007FC00018007FC000000
+0FF80000000FF00000001FE00000001FC00000007F8000001FFE0000001FFC0000001FFF800000
+001FF000000007F800000003FC00000003FE00000003FF00000001FF80000001FF800E0001FFC0
+3F8001FFC07FC001FFC07FC001FFC0FFE001FFC0FFE001FFC0FFE001FF80FFE001FF80FFC003FF
+007F8003FF003F0003FE001F0007FC000FE01FF80007FFFFE00001FFFF8000001FFC0000222E7D
+AD29>I<0000007800000000F800000001F800000003F800000007F800000007F80000000FF800
+00001FF80000003FF80000007FF800000077F8000000F7F8000001E7F8000003C7F800000787F8
+00000707F800000F07F800001E07F800003C07F800007807F800007007F80000F007F80001E007
+F80003C007F800078007F8000F0007F8000F0007F8001E0007F8003C0007F800780007F800F000
+07F800FFFFFFFFF0FFFFFFFFF0FFFFFFFFF000000FF80000000FF80000000FF80000000FF80000
+000FF80000000FF80000000FF80000000FF80000000FF800000FFFFFF0000FFFFFF0000FFFFFF0
+242E7EAD29>I<0000007C0000000000007C000000000000FE000000000000FE000000000000FE
+000000000001FF000000000001FF000000000003FF800000000003FF800000000007FFC0000000
+0007FFC00000000007FFC0000000000FFFE0000000000F7FE0000000001F7FF0000000001E3FF0
+000000001E3FF0000000003E3FF8000000003C1FF8000000007C1FFC00000000780FFC00000000
+780FFC00000000F80FFE00000000F007FE00000001F007FF00000001E003FF00000001E003FF00
+000003E003FF80000003C001FF80000007C001FFC00000078000FFC00000078000FFC000000FFF
+FFFFE000000FFFFFFFE000001FFFFFFFF000001E00003FF000001E00003FF000003C00003FF800
+003C00001FF800007C00001FFC00007800000FFC00007800000FFC0000F0000007FE0000F00000
+07FE0001F0000007FF0003F8000003FF00FFFFC001FFFFFEFFFFC001FFFFFEFFFFC001FFFFFE37
+317DB03E>65 D<FFFFFFFFF80000FFFFFFFFFF0000FFFFFFFFFFE00000FF80003FF00000FF8000
+0FF80000FF800007FC0000FF800007FE0000FF800003FF0000FF800003FF0000FF800001FF8000
+FF800001FF8000FF800001FF8000FF800001FF8000FF800001FF8000FF800001FF8000FF800003
+FF0000FF800003FF0000FF800007FF0000FF800007FE0000FF80000FFC0000FF80001FF80000FF
+8000FFE00000FFFFFFFF800000FFFFFFFF000000FFFFFFFFE00000FF80001FF80000FF800007FC
+0000FF800003FF0000FF800001FF0000FF800001FF8000FF800000FFC000FF800000FFC000FF80
+0000FFE000FF800000FFE000FF800000FFE000FF800000FFE000FF800000FFE000FF800000FFE0
+00FF800000FFE000FF800000FFC000FF800001FFC000FF800001FF8000FF800003FF8000FF8000
+07FF0000FF80000FFE0000FF80003FFC00FFFFFFFFFFF000FFFFFFFFFFC000FFFFFFFFFE000033
+317EB03B>I<000003FF80018000003FFFF003800001FFFFFC0F800007FF007F1F80001FF8000F
+BF80003FE00003FF8000FF800000FF8001FF0000007F8003FE0000003F8007FC0000003F8007FC
+0000001F800FF80000001F801FF80000000F801FF00000000F803FF000000007803FF000000007
+807FF000000007807FE000000007807FE000000000007FE00000000000FFE00000000000FFE000
+00000000FFE00000000000FFE00000000000FFE00000000000FFE00000000000FFE00000000000
+FFE00000000000FFE000000000007FE000000000007FE000000000007FE000000000007FF00000
+0003803FF000000003803FF000000003801FF000000003801FF800000007800FF8000000070007
+FC000000070007FC0000000E0003FE0000001E0001FF0000003C0000FF8000007800003FE00000
+F000001FF80003E0000007FF003F80000001FFFFFE000000003FFFF80000000003FF8000003131
+7BB03C>I<FFFFFFC0FFFFFFC0FFFFFFC000FFC00000FFC00000FFC00000FFC00000FFC00000FF
+C00000FFC00000FFC00000FFC00000FFC00000FFC00000FFC00000FFC00000FFC00000FFC00000
+FFC00000FFC00000FFC00000FFC00000FFC00000FFC00000FFC00000FFC00000FFC00000FFC000
+00FFC00000FFC00000FFC00000FFC00000FFC00000FFC00000FFC00000FFC00000FFC00000FFC0
+0000FFC00000FFC00000FFC00000FFC00000FFC00000FFC00000FFC00000FFC000FFFFFFC0FFFF
+FFC0FFFFFFC01A317EB01F>73 D<FFFF8000000001FFFF80FFFFC000000003FFFF80FFFFE00000
+0007FFFF8000FFE000000007FF800000EFF00000000EFF800000EFF00000000EFF800000EFF000
+00000EFF800000E7F80000001CFF800000E7F80000001CFF800000E3FC00000038FF800000E3FC
+00000038FF800000E1FE00000070FF800000E1FE00000070FF800000E0FF000000E0FF800000E0
+FF000000E0FF800000E07F800001C0FF800000E07F800001C0FF800000E03FC0000380FF800000
+E03FC0000380FF800000E03FC0000380FF800000E01FE0000700FF800000E01FE0000700FF8000
+00E00FF0000E00FF800000E00FF0000E00FF800000E007F8001C00FF800000E007F8001C00FF80
+0000E003FC003800FF800000E003FC003800FF800000E001FE007000FF800000E001FE007000FF
+800000E000FF00E000FF800000E000FF00E000FF800000E000FF00E000FF800000E0007F81C000
+FF800000E0007F81C000FF800000E0003FC38000FF800000E0003FC38000FF800000E0001FE700
+00FF800000E0001FE70000FF800000E0000FFE0000FF800000E0000FFE0000FF800000E00007FC
+0000FF800000E00007FC0000FF800000E00007FC0000FF800000E00003F80000FF800001F00003
+F80000FF8000FFFFE001F000FFFFFF80FFFFE001F000FFFFFF80FFFFE000E000FFFFFF8049317E
+B04E>77 D<FFFFC000007FFFF0FFFFE000007FFFF0FFFFF000007FFFF000FFF8000000F80000FF
+FC000000700000FFFE000000700000EFFF000000700000E7FF800000700000E3FF800000700000
+E1FFC00000700000E0FFE00000700000E07FF00000700000E07FF80000700000E03FFC00007000
+00E01FFE0000700000E00FFF0000700000E007FF8000700000E003FF8000700000E001FFC00070
+0000E000FFE000700000E0007FF000700000E0007FF800700000E0003FFC00700000E0001FFE00
+700000E0000FFF00700000E00007FF80700000E00003FF80700000E00001FFC0700000E00000FF
+E0700000E000007FF0700000E000007FF8700000E000003FFC700000E000001FFE700000E00000
+0FFF700000E0000007FFF00000E0000003FFF00000E0000001FFF00000E0000000FFF00000E000
+00007FF00000E00000007FF00000E00000003FF00000E00000001FF00000E00000000FF00000E0
+00000007F00000E000000003F00001F000000001F000FFFFE0000000F000FFFFE00000007000FF
+FFE000000070003C317EB041>I<00000FFE0000000000FFFFE000000007FFFFFC0000001FFC07
+FF0000003FE000FF800000FF80003FE00001FF00001FF00003FE00000FF80007FC000007FC0007
+FC000007FC000FF8000003FE001FF8000003FF001FF0000001FF003FF0000001FF803FF0000001
+FF803FF0000001FF807FE0000000FFC07FE0000000FFC07FE0000000FFC0FFE0000000FFE0FFE0
+000000FFE0FFE0000000FFE0FFE0000000FFE0FFE0000000FFE0FFE0000000FFE0FFE0000000FF
+E0FFE0000000FFE0FFE0000000FFE0FFE0000000FFE0FFE0000000FFE07FE0000000FFC07FE000
+0000FFC07FF0000001FFC07FF0000001FFC03FF0000001FF803FF0000001FF801FF8000003FF00
+1FF8000003FF000FFC000007FE000FFC000007FE0007FE00000FFC0003FF00001FF80001FF8000
+3FF00000FFC0007FE000003FE000FF8000001FFC07FF00000007FFFFFC00000000FFFFE0000000
+000FFE00000033317BB03E>I<FFFFFFFFE000FFFFFFFFFE00FFFFFFFFFF8000FFC001FFE000FF
+C0003FF000FFC0001FF800FFC0000FFC00FFC0000FFC00FFC00007FE00FFC00007FE00FFC00007
+FF00FFC00007FF00FFC00007FF00FFC00007FF00FFC00007FF00FFC00007FF00FFC00007FF00FF
+C00007FE00FFC00007FE00FFC0000FFC00FFC0000FFC00FFC0001FF800FFC0003FF000FFC001FF
+E000FFFFFFFF8000FFFFFFFE0000FFFFFFE00000FFC000000000FFC000000000FFC000000000FF
+C000000000FFC000000000FFC000000000FFC000000000FFC000000000FFC000000000FFC00000
+0000FFC000000000FFC000000000FFC000000000FFC000000000FFC000000000FFC000000000FF
+C000000000FFC000000000FFC0000000FFFFFFC00000FFFFFFC00000FFFFFFC0000030317EB038
+>I<FFFFFFFFC0000000FFFFFFFFFC000000FFFFFFFFFF80000000FFC001FFE0000000FFC0003F
+F0000000FFC0000FFC000000FFC00007FC000000FFC00007FE000000FFC00003FF000000FFC000
+03FF000000FFC00003FF800000FFC00003FF800000FFC00003FF800000FFC00003FF800000FFC0
+0003FF800000FFC00003FF800000FFC00003FF000000FFC00003FF000000FFC00007FE000000FF
+C00007FC000000FFC0000FFC000000FFC0003FF0000000FFC001FFE0000000FFFFFFFF80000000
+FFFFFFFC00000000FFFFFFFE00000000FFC003FF00000000FFC000FFC0000000FFC0007FE00000
+00FFC0003FE0000000FFC0003FF0000000FFC0001FF0000000FFC0001FF8000000FFC0001FF800
+0000FFC0001FF8000000FFC0001FF8000000FFC0001FF8000000FFC0001FFC000000FFC0001FFC
+000000FFC0001FFC000000FFC0001FFC004000FFC0001FFC00E000FFC0001FFE00E000FFC0000F
+FE00E000FFC0000FFF01C000FFC00007FF83C0FFFFFFC003FFFF80FFFFFFC000FFFF00FFFFFFC0
+000FFC003B317EB03E>82 D<001FF0018000FFFF038003FFFFC78007F00FFF800F8001FF801F00
+007F803F00001F803E00000F807E00000F807E00000780FE00000780FE00000780FE00000380FF
+00000380FF00000380FF80000000FFE00000007FFC0000007FFFE000007FFFFE00003FFFFFC000
+1FFFFFF0001FFFFFF8000FFFFFFC0003FFFFFE0001FFFFFF00007FFFFF80001FFFFF800000FFFF
+C0000007FFC0000000FFE00000003FE00000003FE00000001FE06000001FE0E000000FE0E00000
+0FE0E000000FE0E000000FC0F000000FC0F000000FC0F800001F80FC00001F80FF00003F00FFC0
+007E00FFFC01FC00F1FFFFF800E03FFFE000C007FF000023317BB02E>I<3FFFFFFFFFFF003FFF
+FFFFFFFF003FFFFFFFFFFF003FE00FFC01FF007F000FFC003F807E000FFC001F807C000FFC000F
+8078000FFC00078078000FFC00078070000FFC00038070000FFC00038070000FFC00038070000F
+FC000380E0000FFC0001C0E0000FFC0001C0E0000FFC0001C0E0000FFC0001C000000FFC000000
+00000FFC00000000000FFC00000000000FFC00000000000FFC00000000000FFC00000000000FFC
+00000000000FFC00000000000FFC00000000000FFC00000000000FFC00000000000FFC00000000
+000FFC00000000000FFC00000000000FFC00000000000FFC00000000000FFC00000000000FFC00
+000000000FFC00000000000FFC00000000000FFC00000000000FFC00000000000FFC0000000000
+0FFC00000000000FFC00000000000FFC00000000000FFC00000000000FFC000000007FFFFFFF80
+00007FFFFFFF8000007FFFFFFF800032307DAF39>I<007FF8000003FFFF000007FFFFC0000FE0
+1FE0001FF007F0001FF003F8001FF003FC001FF001FE000FE001FE0007C001FE00010001FE0000
+0001FE00000001FE000001FFFE00003FFFFE0001FFF1FE0007FE01FE000FF001FE001FC001FE00
+3F8001FE007F8001FE00FF0001FE00FF0001FE00FF0001FE00FF0001FE00FF0003FE007F8003FE
+007FC00EFE003FF03CFF000FFFF87FF807FFF03FF800FF800FF825207E9F28>97
+D<01F8000000FFF8000000FFF8000000FFF80000000FF800000007F800000007F800000007F800
+000007F800000007F800000007F800000007F800000007F800000007F800000007F800000007F8
+00000007F800000007F800000007F80FF00007F87FFE0007F9FFFF8007FFE03FC007FF000FE007
+FE0007F007F80003F807F80003FC07F80003FC07F80001FE07F80001FE07F80001FE07F80001FF
+07F80001FF07F80001FF07F80001FF07F80001FF07F80001FF07F80001FF07F80001FF07F80001
+FE07F80001FE07F80001FE07F80003FC07F80003FC07FC0007F807FE0007F007F7001FE007E3E0
+7FC007C1FFFF0007807FFE0007001FE00028327EB12E>I<0007FF00007FFFE000FFFFF003FC03
+F807F007FC0FE007FC1FE007FC3FC007FC3FC003F87FC001F07F8000407F800000FF800000FF80
+0000FF800000FF800000FF800000FF800000FF800000FF8000007F8000007FC000007FC000003F
+C0000E3FE0000E1FE0001C0FF0001C07F8007803FF01F000FFFFE0007FFF800007FC001F207D9F
+25>I<00000007E0000003FFE0000003FFE0000003FFE00000003FE00000001FE00000001FE000
+00001FE00000001FE00000001FE00000001FE00000001FE00000001FE00000001FE00000001FE0
+0000001FE00000001FE00000001FE0000FF81FE0007FFF1FE001FFFFDFE003FE03FFE007F800FF
+E00FE0003FE01FE0001FE03FC0001FE03FC0001FE07F80001FE07F80001FE07F80001FE0FF8000
+1FE0FF80001FE0FF80001FE0FF80001FE0FF80001FE0FF80001FE0FF80001FE0FF80001FE07F80
+001FE07F80001FE07F80001FE03FC0001FE03FC0001FE01FC0003FE00FE0007FE007F001FFE003
+FC07DFF001FFFF9FFF007FFE1FFF000FF01FFF28327DB12E>I<0007FC0000003FFF800000FFFF
+E00003FC07F00007F801F8000FE000FC001FE0007E003FC0007E003FC0003F007FC0003F007F80
+003F007F80003F80FF80003F80FF80003F80FFFFFFFF80FFFFFFFF80FFFFFFFF80FF80000000FF
+80000000FF800000007F800000007F800000003FC00000003FC00003801FC00003801FE0000780
+0FF0000F0007F8001E0003FE00FC0000FFFFF800003FFFE0000003FF000021207E9F26>I<0000
+FF000007FFC0001FFFE0003FC7F0007F0FF800FE0FF801FE0FF801FC0FF803FC07F003FC03E003
+FC01C003FC000003FC000003FC000003FC000003FC000003FC000003FC0000FFFFF800FFFFF800
+FFFFF80003FC000003FC000003FC000003FC000003FC000003FC000003FC000003FC000003FC00
+0003FC000003FC000003FC000003FC000003FC000003FC000003FC000003FC000003FC000003FC
+000003FC000003FC000003FC000003FC000003FC000003FC000003FC00007FFFF0007FFFF0007F
+FFF0001D327EB119>I<001FF007E000FFFE3FF001FFFF7FF807F83FF1F80FE00FE1F80FE00FE0
+F01FC007F0601FC007F0003FC007F8003FC007F8003FC007F8003FC007F8003FC007F8001FC007
+F0001FC007F0000FE00FE0000FE00FE00007F83FC00007FFFF000006FFFE00000E1FF000000E00
+0000001E000000001E000000001F000000001F800000001FFFFFC0000FFFFFF8000FFFFFFE0007
+FFFFFF0003FFFFFF8007FFFFFFC01FFFFFFFE03F00007FE07E00000FF0FC000007F0FC000003F0
+FC000003F0FC000003F0FC000003F07E000007E03F00000FC01FC0003F800FF801FF0007FFFFFE
+0000FFFFF000001FFF8000252F7E9F29>I<01F800000000FFF800000000FFF800000000FFF800
+0000000FF80000000007F80000000007F80000000007F80000000007F80000000007F800000000
+07F80000000007F80000000007F80000000007F80000000007F80000000007F80000000007F800
+00000007F80000000007F807F8000007F83FFF000007F87FFF800007F8F03FC00007F9C01FE000
+07FB000FE00007FE000FF00007FE000FF00007FC000FF00007FC000FF00007F8000FF00007F800
+0FF00007F8000FF00007F8000FF00007F8000FF00007F8000FF00007F8000FF00007F8000FF000
+07F8000FF00007F8000FF00007F8000FF00007F8000FF00007F8000FF00007F8000FF00007F800
+0FF00007F8000FF00007F8000FF00007F8000FF00007F8000FF000FFFFC1FFFF80FFFFC1FFFF80
+FFFFC1FFFF8029327DB12E>I<03C0000FF0000FF0001FF8001FF8001FFC001FF8001FF8000FF0
+000FF00003C00000000000000000000000000000000000000000000000000001F800FFF800FFF8
+00FFF8000FF80007F80007F80007F80007F80007F80007F80007F80007F80007F80007F80007F8
+0007F80007F80007F80007F80007F80007F80007F80007F80007F80007F80007F80007F80007F8
+00FFFF80FFFF80FFFF8011337DB217>I<01F8000000FFF8000000FFF8000000FFF80000000FF8
+00000007F800000007F800000007F800000007F800000007F800000007F800000007F800000007
+F800000007F800000007F800000007F800000007F800000007F800000007F8007FFC07F8007FFC
+07F8007FFC07F8001FC007F8001F0007F8003E0007F800780007F801F00007F803E00007F80780
+0007F81F000007F83E000007F87C000007F9FE000007FBFF000007FFFF800007FF7FC00007FE3F
+E00007F81FE00007F01FF00007F00FF80007F007FC0007F003FE0007F001FF0007F000FF0007F0
+00FF8007F0007FC007F0003FE007F0003FF0FFFF80FFFFFFFF80FFFFFFFF80FFFF28327EB12C>
+107 D<01F800FFF800FFF800FFF8000FF80007F80007F80007F80007F80007F80007F80007F800
+07F80007F80007F80007F80007F80007F80007F80007F80007F80007F80007F80007F80007F800
+07F80007F80007F80007F80007F80007F80007F80007F80007F80007F80007F80007F80007F800
+07F80007F80007F80007F80007F80007F80007F80007F80007F800FFFFC0FFFFC0FFFFC012327D
+B117>I<03F007F8000FF000FFF03FFF007FFE00FFF07FFF80FFFF00FFF0F03FC1E07F800FF1C0
+1FE3803FC007F3000FE6001FC007F6000FFC001FE007FE000FFC001FE007FC000FF8001FE007FC
+000FF8001FE007F8000FF0001FE007F8000FF0001FE007F8000FF0001FE007F8000FF0001FE007
+F8000FF0001FE007F8000FF0001FE007F8000FF0001FE007F8000FF0001FE007F8000FF0001FE0
+07F8000FF0001FE007F8000FF0001FE007F8000FF0001FE007F8000FF0001FE007F8000FF0001F
+E007F8000FF0001FE007F8000FF0001FE007F8000FF0001FE007F8000FF0001FE007F8000FF000
+1FE0FFFFC1FFFF83FFFFFFFFC1FFFF83FFFFFFFFC1FFFF83FFFF40207D9F45>I<03F007F80000
+FFF03FFF0000FFF07FFF8000FFF0F03FC0000FF1C01FE00007F3000FE00007F6000FF00007FE00
+0FF00007FC000FF00007FC000FF00007F8000FF00007F8000FF00007F8000FF00007F8000FF000
+07F8000FF00007F8000FF00007F8000FF00007F8000FF00007F8000FF00007F8000FF00007F800
+0FF00007F8000FF00007F8000FF00007F8000FF00007F8000FF00007F8000FF00007F8000FF000
+07F8000FF00007F8000FF000FFFFC1FFFF80FFFFC1FFFF80FFFFC1FFFF8029207D9F2E>I<0007
+FE0000003FFFC00000FFFFF00003FC03FC0007F000FE000FE0007F001FC0003F803FC0003FC03F
+C0003FC07F80001FE07F80001FE07F80001FE0FF80001FF0FF80001FF0FF80001FF0FF80001FF0
+FF80001FF0FF80001FF0FF80001FF0FF80001FF07F80001FE07F80001FE07F80001FE03FC0003F
+C03FC0003FC01FE0007F800FE0007F0007F801FE0003FE07FC0001FFFFF800003FFFC0000007FE
+000024207E9F29>I<03F03F00FFF07FC0FFF1FFE0FFF3C7F00FF38FF807F70FF807F60FF807FE
+0FF807FC07F007FC03E007FC008007F8000007F8000007F8000007F8000007F8000007F8000007
+F8000007F8000007F8000007F8000007F8000007F8000007F8000007F8000007F8000007F80000
+07F8000007F80000FFFFE000FFFFE000FFFFE0001D207E9F22>114 D<00FF870007FFEF001FFF
+FF003F007F003C001F0078000F00F8000700F8000700F8000700FC000700FF000000FFF800007F
+FFC0003FFFF0003FFFFC000FFFFE0007FFFF0001FFFF80001FFF800000FFC000001FC060000FC0
+E00007C0E00007C0F00007C0F8000780F8000F80FE000F00FF803E00FFFFFC00F3FFF800C07FC0
+001A207D9F21>I<00380000380000380000380000380000780000780000780000F80000F80001
+F80003F80007F8001FF800FFFFFEFFFFFEFFFFFE07F80007F80007F80007F80007F80007F80007
+F80007F80007F80007F80007F80007F80007F80007F80007F80007F80007F80707F80707F80707
+F80707F80707F80707F80703F80E03FC0E01FE1C00FFF8007FF0000FE0182E7EAD20>I<01F800
+03F000FFF801FFF000FFF801FFF000FFF801FFF0000FF8001FF00007F8000FF00007F8000FF000
+07F8000FF00007F8000FF00007F8000FF00007F8000FF00007F8000FF00007F8000FF00007F800
+0FF00007F8000FF00007F8000FF00007F8000FF00007F8000FF00007F8000FF00007F8000FF000
+07F8000FF00007F8000FF00007F8000FF00007F8000FF00007F8001FF00007F8001FF00003F800
+3FF00003F8006FF00001FE03CFF80000FFFF8FFF80007FFF0FFF80000FFC0FFF8029207D9F2E>
+I<FFFF0FFFF01FFEFFFF0FFFF01FFEFFFF0FFFF01FFE0FF0007E0001F00FF8007F0001E007F800
+7F0001C007F8003F8003C003FC003F80038003FC007FC0038003FE007FC0078001FE00FFC00700
+01FF00EFE00F0000FF00EFE00E0000FF01C7F00E00007F81C7F01C00007F83C7F01C00007FC383
+F83C00003FC383F83800003FC701FC3800001FE701FC7000001FEF01FC7000001FFE00FEF00000
+0FFE00FEE000000FFC007FE0000007FC007FC0000007FC007FC0000007F8003FC0000003F8003F
+80000003F0001F80000001F0001F00000001E0000F00000000E0000E000037207E9F3C>119
+D<FFFFFFFFFFFFFFFFFFFFFFFFFFFFFF2803809429>123 D E end
+%%EndProlog
+%%BeginSetup
+TeXDict begin
+
+%%EndSetup
+%%Page: 1 1
+0 bop 367 90 a Fu(Coun)n(tering)26 b(Abuse)h(of)h(Name{Based)691
+182 y(Authen)n(tication)1260 156 y Ft(1)397 349 y Fs(Christoph)20
+b(L.)g(Sc)n(h)n(uba)h(and)f(Eugene)f(H.)h(Spa\013ord)728 475
+y Fr(CO)n(AST)h(Lab)r(oratory)541 550 y(Departmen)n(t)e(of)h(Computer)f
+(Sciences)750 625 y(Purdue)h(Univ)n(ersit)n(y)587 700 y(W)-5
+b(est)19 b(Lafa)n(y)n(ette,)h(IN)f(47907-1398)624 774 y Fq(f)p
+Fp(schuba,spaf)p Fq(g)p Fp(@cs.purdue.)o(edu)889 959 y Fo(Abstract)279
+1044 y Fn(Authen)o(tication)f(for)f(access)h(con)o(trol)f(pro)q(cedures)h(is)
+g(usually)g(based)g(on)f(the)h(iden-)211 1100 y(tit)o(y)f(of)h(participating)
+h(en)o(tities.)28 b(In)18 b(some)g(comm)o(unications)g(systems,)g(iden)o
+(tities)h(are)211 1157 y(partially)13 b(or)e(wholly)h(resolv)o(ed)h(using)f
+(hostnames)f(or)g(mac)o(hine)i(addresses)f(in)g(the)g(under-)211
+1213 y(lying)17 b(proto)q(col)f(suite.)23 b(Access)17 b(con)o(trol)e(lists)i
+(and)f(rev)o(o)q(cation)g(lists)h(are)f(often)g(de\014ned)211
+1269 y(on)g(the)h(basis)f(of)g(hostnames,)g(whereb)o(y)g(the)h(comm)o
+(unication)g(subsystem)f(at)g(run)o(time)211 1326 y(utilizes)h(mac)o(hine)f
+(addresses.)279 1382 y(After)d(comm)o(unications)i(b)q(et)o(w)o(een)f(t)o(w)o
+(o)e(mac)o(hines)j(are)e(established,)j(hosts)d(iden)o(tify)211
+1439 y(eac)o(h)19 b(other)g(b)o(y)h(their)f(proto)q(col)h(addresses.)32
+b(T)l(o)19 b(map)g(this)h(address)f(to)g(a)g(high{lev)o(el)211
+1495 y(name,)f(whic)o(h)h(can)f(then)h(b)q(e)f(compared)g(with)h(access)f
+(con)o(trol)f(or)h(rev)o(o)q(cation)g(lists)h(to)211 1552 y(gran)o(t)f(or)g
+(den)o(y)i(access,)f(a)g(resolution)h(pro)q(cess)f(is)g(initiated.)33
+b(The)19 b(abstraction)g(from)211 1608 y(proto)q(col)d(addresses)h(to)e
+(high{lev)o(el)j(hostnames)e(is)h(necessary)f(to)g(hide)i(details)f(of)f
+(het-)211 1665 y(erogeneous)d(comm)o(unication)h(subsystems,)e(and)i(of)e
+(dynamic)i(net)o(w)o(ork)e(con\014gurations)211 1721 y(from)18
+b(the)g(application)i(la)o(y)o(er)f(where)g(a)f(uniform,)h(high{lev)o(el)i
+(naming)e(sc)o(heme)f(is)h(de-)211 1778 y(sired.)279 1834 y(If)f
+(cryptographic)f(capabilities)j(are)e(used)g(that)e(iden)o(tify)j(sub)s
+(ject{ob)s(ject)e(in)o(terac-)211 1890 y(tions,)j(authen)o(tication)h
+(usually)g(do)q(es)f(not)f(dep)q(end)i(on)f(host)f(iden)o(ti\014cation.)35
+b(Where)211 1947 y(host)17 b(iden)o(ti\014cation)j(is)e(part)f(of)g(the)h
+(authen)o(tication,)g(a)g(crucial)h(link)g(in)f(the)g(c)o(hain)g(of)211
+2003 y(authen)o(tication)h(is)g(the)f(asso)q(ciation)h(b)q(et)o(w)o(een)g
+(hostnames)f(and)g(their)h(resp)q(ectiv)o(e)h(ad-)211 2060
+y(dresses.)g(The)15 b(v)m(alidit)o(y)i(of)e(the)g(authen)o(tication)h(can)f
+(b)q(e)h(trusted)f(only)h(as)f(m)o(uc)o(h)g(as)g(the)211 2116
+y(binding)i(pro)q(cess)f(itself.)279 2173 y(In)i(the)f(In)o(ternet)h(this)g
+(name)f(resolution)h(is)g(pro)o(vided)g(b)o(y)f(a)g(widely{implemen)o(ted)211
+2229 y(distributed)f(database)e(system:)19 b(the)c(Domain)f(Name)h(System)f
+(\(DNS\).)g(Dynamic)h(con-)211 2286 y(\014guration)g(b)q(eha)o(vior,)h
+(system)f(e\016ciency)l(,)i(and)e(v)o(olume)h(of)f(binding)i(requests)e
+(demand)211 2342 y(late)i(binding)i(b)q(et)o(w)o(een)f(hostnames)f(and)g
+(addresses,)g(and)h(cac)o(hing)g(of)e(the)i(mappings.)211 2399
+y(Therefore,)c(bindings)i(are)d(established)j(\\just)e(in)h(time")f(on)g(a)g
+(need)h(basis)f(and)g(are)g(k)o(ept)211 2455 y(v)m(alid)j(for)d(a)h(limited)i
+(p)q(erio)q(d)g(of)e(time.)p 89 2536 720 2 v 145 2567 a Fm(1)164
+2582 y Fl(submitted)e(to)h(the)g(t)o(w)o(en)o(t)o(y-second)h(ann)o(ual)e
+Fk(T)m(elecomm)o(unicatio)o(ns)f(P)o(olicy)h(Researc)o(h)i(Conference)p
+eop
+%%Page: 2 2
+1 bop 279 82 a Fn(This)15 b(pap)q(er)g(describ)q(es)g(problems)g(of)f
+(name{based)h(authen)o(tication)f(requiring)i(late)211 139
+y(binding)21 b(suc)o(h)e(as)f(that)h(pro)o(vided)g(b)o(y)g(the)g(DNS)g(for)f
+(hostname{to{address)g(asso)q(cia-)211 195 y(tions.)23 b(Because)16
+b(forw)o(ard)f(mappings)i(\(where)f(the)g(address)g(is)h(a)f(relation)g(of)g
+(the)g(host-)211 252 y(name\))c(and)h(rev)o(erse)f(mappings)i(are)e(main)o
+(tained)h(in)h(unrelated)f(parts)f(of)g(the)h(database,)211
+308 y(three)k(lev)o(els)h(of)f(mo)q(di\014cation)h(are)f(p)q(ossible:)25
+b(mo)q(di\014ed)18 b(forw)o(ard)e(mapping,)i(mo)q(di\014ed)211
+364 y(bac)o(kw)o(ard)10 b(mapping,)i(or)e(b)q(oth.)18 b(The)11
+b(mo)q(di\014cation)h(of)e(asso)q(ciations)h(enables)h(the)f(sp)q(o)q(of-)211
+421 y(ing)16 b(of)e(hostnames)h(in)h(sessions)g(that)e(dep)q(end)j(on)e(the)h
+(DNS.)279 477 y(W)l(e)j(state)f(the)g(problem)h(in)h(an)e(abstract)g(w)o(a)o
+(y)f(and)i(in)h(the)e(concrete)h(case)g(of)f(the)211 534 y(DNS.)c(W)l(e)g
+(analyze)h(the)f(conditions)i(that)d(facilitate)j(the)e(exploitation)h(of)f
+(the)g(problem)211 590 y(and)h(explain)i(the)e(w)o(eaknesses)g(that)g(are)g
+(presen)o(t)g(in)h(the)f(DNS.)279 647 y(W)l(e)h(then)h(explore)f(some)g(p)q
+(ossible)i(solutions)f(to)e(the)h(problem.)23 b(All)18 b(our)e(prop)q(osed)
+211 703 y(solutions)k(are)e(ev)m(aluated)j(b)o(y)e(a)f(n)o(um)o(b)q(er)i(of)f
+(criteria)g(to)g(compare)g(e\013ects)f(of)h(the)g(so-)211 760
+y(lutions.)36 b(Eac)o(h)19 b(of)h(the)g(solutions)h(will)h(either)f(consist)f
+(of)g(mec)o(hanisms)g(that)g(enable)211 816 y(arbitrarily)g(c)o(hosen)g(p)q
+(olicies,)j(or)c(it)h(will)h(require)f(the)g(implemen)o(tation)h(of)e(a)h
+(certain)211 873 y(p)q(olicy)l(.)k(W)l(e)16 b(emphasize)i(the)e(solutions)h
+(to)e(impro)o(v)o(e)h(existing)h(name)f(serv)o(ers)g(b)o(y)g(mo)q(d-)211
+929 y(ifying)i(them)g(in)g(a)f(w)o(a)o(y)g(that)f(they)i(rely)g(on)f(less)h
+(trust,)f(and)h(to)f(em)o(b)q(ed)h(crytographic)211 985 y(metho)q(ds)d(in)o
+(to)g(the)h(name)f(resolution)h(pro)q(cess.)89 1152 y Fu(1)83
+b(In)n(tro)r(duction)89 1261 y Ft(The)19 b(In)o(ternet)f(is)h(a)h(widespread)
+f(conglomeration)g(of)g(h)o(undreds)h(of)f(thousands)i(of)f(in)o(tercon-)89
+1322 y(nected)e(heterogeneous)h(net)o(w)o(orks)f(and)h(hosts.)29
+b(The)18 b(design)h(of)g(the)f(In)o(ternet)f(is)i(based)g(on)g(a)89
+1382 y(proto)q(col)e(hierarc)o(h)o(y)l(.)j(There)c(exist)f(m)o(ultiple)e
+(implem)o(en)o(tati)o(ons)h(of)j(these)f(proto)q(cols.)162
+1442 y(Computers)21 b(comm)o(uni)o(cate)e(with)i(eac)o(h)f(other)i(on)g(the)f
+(basis)h(of)f(di\013eren)o(t)g(t)o(yp)q(es)g(of)g(ad-)89 1502
+y(dresses;)27 b(on)d(the)f(ph)o(ysical)f(la)o(y)o(er)g(using)i(lo)o(w{lev)o
+(el)d(ph)o(ysical)i(addresses)h(according)f(to)h(the)89 1562
+y(hardw)o(are)15 b(devices)f(used,)h(on)g(the)f(data)i(link)e(to)h(presen)o
+(tation)g(la)o(y)o(er)e(on)i(a)h(\014rst{lev)o(el)d(abstrac-)89
+1623 y(tion)20 b(using)h(host)g(addresses)g(suc)o(h)f(as)h(IP)f(addresses)
+1101 1604 y Fj(2)1121 1623 y Ft(,)h(and)g(on)g(the)f(application)g(la)o(y)o
+(er)f(on)i(a)89 1683 y(second{lev)o(el)15 b(abstraction)i(using)f(high{lev)o
+(el,)e(pronounceable)j(hostnames.)162 1743 y(The)22 b(task)g(of)g(naming)f
+(hosts)h(and)h(net)o(w)o(ork)e(domains)g(is)g(addressed)h(b)o(y)g(creating)f
+(a)h(hi-)89 1803 y(erarc)o(hical)15 b(relation)i(b)q(et)o(w)o(een)e(domains,)
+h(with)h(hosts)h(as)f(the)f(furthest)h(descendan)o(ts)g(from)e(an)89
+1863 y(arti\014cial)d(ro)q(ot)i(domain.)19 b(By)12 b(app)q(ending)i(the)e
+(domain)g(lab)q(els)h(one)g(after)f(the)h(other)g(to)g(the)f(host)89
+1923 y(lab)q(els)i(on)i(the)e(path)h(up)g(to)g(the)f(ro)q(ot)i(in)e(the)g
+(hierarc)o(hical)f(tree,)h(a)h(unique,)f(memoriz)o(able,)d(and)89
+1984 y(usually)18 b(pronounceable)h(iden)o(ti\014er)e(is)i(created:)26
+b(the)18 b(hostname.)28 b(One)19 b(of)g(the)f(managemen)o(t)89
+2044 y(tasks)f(in)f(the)g(In)o(ternet)f(is)h(the)g(mapping)f(of)i(lo)o(w)o
+(er{lev)o(el)c(addresses)k(to)g(these)f(hostnames.)162 2104
+y(The)g(mapping,)f(or)h(binding,)g(of)g(IP)f(addresses)i(to)f(hostnames)g(b)q
+(ecame)e(a)j(ma)s(jor)e(problem)89 2164 y(in)f(the)f(rapidly)h(gro)o(wing)g
+(In)o(ternet.)19 b(Note)14 b(that)g(this)g(pap)q(er)h(do)q(es)f(not)h(deal)e
+(with)h(the)g(mapping)89 2224 y(b)q(et)o(w)o(een)f(addresses)h(on)h(the)e(ph)
+o(ysical)g(la)o(y)o(er)g(and)h(transp)q(ort)i(la)o(y)o(er,)c(whic)o(h)h(is)h
+(solv)o(ed)f(b)o(y)h(ARP)1870 2206 y Fj(3)89 2285 y Ft(in)20
+b(the)g(TCP/IP)h(In)o(ternet)e(Proto)q(col)i(Suite,)g(but)f(with)g(the)g
+(mapping)g(b)q(et)o(w)o(een)f(hostnames)89 2345 y(and)e(IP)f(addresses.)p
+89 2417 720 2 v 145 2448 a Fm(2)164 2463 y Fl(\\32-bit)c(addresses)k
+(assigned)f(to)e(hosts)i(that)f(w)o(an)o(t)f(to)h(participate)g(in)f(a)h
+(TCP/IP)g(in)o(ternet")h([Com91)m(])145 2497 y Fm(3)164 2513
+y Fl(\\Address)f(Resolution)e(Proto)q(col)g({)h(used)g(to)g(dynamically)c
+(bind)k(a)f(high{lev)o(el)g(IP)h(address)g(to)g(a)f(lo)o(w{lev)o(el)89
+2562 y(ph)o(ysical)h(hardw)o(are)i(address")g([Com91)m(])977
+2715 y Ft(2)p eop
+%%Page: 3 3
+2 bop 162 82 a Ft(This)18 b(higher{lev)o(el)d(binding)j(e\013ort)f(w)o(en)o
+(t)g(through)i(di\013eren)o(t)d(stages)j(of)e(dev)o(elopmen)o(t)e(up)89
+142 y(to)f(the)f(curren)o(tly)e(used)j(Domain)e(Name)g(System)f(\(DNS\).)i
+(The)g(DNS)h(is)f(a)g(distributed)g(naming)89 203 y(resolution)g(system)f
+(used)h(b)o(y)g(most)g(net)o(w)o(ork)f(services)g(a)o(v)m(ailable)h
+(throughout)h(the)f(In)o(ternet.)19 b(It)89 263 y(w)o(orks)d(transparen)o
+(tly)g(for)g(the)f(user)h(who)h(sends)f(email,)d(accesses)j(another)h(host)f
+(via)g Fi(telnet)i Ft(or)89 323 y Fi(rlo)n(gin)p Ft(,)d(or)g(transfers)h
+(some)e(\014les)h(via)g Fi(ftp)g Ft(b)q(et)o(w)o(een)f(hosts.)22
+b(The)15 b(DNS)g(pro)o(vides)f(name)g(binding)89 383 y(in)19
+b(b)q(oth)i(directions:)27 b(giv)o(en)19 b(a)h(hostname,)g(it)f(returns)h
+(the)g(appropriate)g(IP)g(addresses,)g(and)89 443 y(vice)15
+b(v)o(ersa.)162 504 y(Before)c(hosts)i(gran)o(t)f(net)o(w)o(ork)g(services)e
+(to)j(users,)f(an)g(authen)o(tication)g(pro)q(cess)g(tak)o(es)g(place,)89
+564 y(where)19 b(the)g(users')g(access)g(righ)o(ts,)g(and)g(the)g(iden)o(tit)
+o(y)e(of)j(connecting)f(hosts)h(get)f(scrutinized,)89 624 y(according)f(to)g
+(pro)o(vider)f(p)q(olicies.)24 b(There)18 b(are)f(man)o(y)f(notions)j(on)f
+(ho)o(w)g(access)f(righ)o(ts)h(can)g(b)q(e)89 684 y(sp)q(eci\014ed.)i
+(Examinations)13 b(can)i(b)q(e)f(based)h(on)g(iden)o(ti\014cation)e(b)o(y)g
+(hostname,)h(login)g(name,)f(and)89 744 y(login)20 b(passw)o(ord.)34
+b(In)20 b(some)f(cases)h(it)f(su\016ces)h(to)g(pro)o(vide)g(the)f(righ)o(t)h
+(names,)g(and)g(access)g(is)89 804 y(gran)o(ted)c(without)h(sp)q(ecifying)f
+(an)o(y)g(passw)o(ord)h(at)g(all.)162 865 y(Some)j(Berk)o(eley)f
+Fh(r{commands)h Ft(\(see)h([Ste90,)h(c)o(hapter)f(14]\))g(o\013er)h(net)o(w)o
+(ork)f(services)f(for)89 925 y(whic)o(h)j(it)h(is)g(su\016cien)o(t)f(to)h(v)o
+(erify)e(user)j(name)d(and)j(hostname)f(to)g(gain)h(complete)d(access.)89
+985 y(As)f(the)g(remote)e(user)i(name)f(is)g(sp)q(eci\014ed)h(b)o(y)f(the)h
+(connecting)g(site,)g(the)g(authen)o(tication)f(is)89 1045
+y(additionally)c(based)h(up)q(on)g(the)f(name)f(of)i(the)f(connecting)g(mac)o
+(hine.)j(A)d(mac)o(hine)e(that)j(o\013ers)89 1105 y(services)d(can)h(acquire)
+f(information)g(ab)q(out)j(the)d Fi(so)n(cket)i Ft(that)g(is)f(used)g(b)o(y)f
+(the)h(connecting)g(site.)89 1166 y(A)20 b(so)q(c)o(k)o(et)f(is)h(an)g
+(abstraction)h(for)f(a)g(net)o(w)o(ork)g(service)e(access)i(p)q(oin)o(t)g
+(\(NSAP\):)f(in)h(UNIX)1827 1148 y Fj(4)1865 1166 y Ft(a)89
+1226 y(tuple)c(consisting)h(of)g(IP)g(address,)g(p)q(ort,)g(and)g(proto)q
+(col)h(used)f(b)o(y)f(the)g(remote)f(site.)22 b(T)l(o)c(v)o(erify)89
+1286 y(the)e(hostname,)f(it)h(is)g(the)g(task)h(of)f(the)g(DNS)g(to)h(map)e
+(the)h(IP)g(address)h(to)g(the)f(hostname.)162 1346 y(Because)23
+b(the)g(DNS)h(is)f(distributed)g(among)g(man)o(y)f(thousands)j(of)f(hosts,)i
+(it)d(can)h(b)q(e)g(a)89 1406 y(critical)13 b(mistak)o(e)f(to)j(blindly)e
+(trust)i(the)g(resolv)o(ed)e(binding.)21 b(This)14 b(pap)q(er)i(in)o(v)o
+(estigates)d(p)q(olicies)89 1467 y(and)j(mec)o(hanism)o(s)d(to)i(solv)o(e)g
+(the)g(problem)e(of)j(trust)f(in)g(the)g(Domain)f(Name)f(System.)20
+b(Some)14 b(of)89 1527 y(these)j(p)q(olicies)f(and)i(mec)o(hanisms)d(migh)o
+(t)g(b)q(e)j(abstractable)f(to)h(distributed)f(naming)f(services)89
+1587 y(in)g(general.)162 1647 y(Although)d(this)f(problem)f(has)i(b)q(een)g
+(kno)o(wn)g(for)f(some)g(y)o(ears)g(no)o(w,)h(not)g(man)o(y)e(publications)89
+1707 y(deal)18 b(with)g(it.)26 b([Bel90)o(])17 b(and)i([Sc)o(h93])e(are)h
+(the)g(principal)f(accoun)o(ts)h(that)h(w)o(e)e(can)h(men)o(tion)e(as)89
+1768 y(related)g(w)o(ork.)22 b([Bel90)o(])17 b(demonstrates)f(the)g(sub)o(v)o
+(ersion)g(of)h(system)e(securit)o(y)h(using)h(the)f(DNS)89
+1828 y(and)k(discusses)g(p)q(ossible)f(defenses)h(against)g(the)f(attac)o(k)h
+(and)g(limitations)d(on)j(their)f(applica-)89 1888 y(bilit)o(y)l(.)24
+b(The)18 b(pap)q(er)h(follo)o(ws)f(suggestions)h(from)e(P)o(aul)h(V.)f(Mo)q
+(c)o(k)m(ap)q(etris,)h(the)f(designer)h(of)g(the)89 1948 y(DNS.)g(In)g([Sc)o
+(h93])g(the)g(details)g(of)h(the)f(exploitation)g(of)h(the)f(w)o(eakness)h
+(are)f(w)o(ork)o(ed)g(out)h(and)89 2008 y(sev)o(eral)c(approac)o(hes)h(to)g
+(solv)o(e)f(the)h(w)o(eakness)f(in)h(the)f(DNS)h(are)g(discussed)f(with)h
+(emphasis)e(on)89 2068 y(hardening)20 b(the)g(name)f(serv)o(er)g(impleme)o(n)
+o(tations)f(and)i(the)g(usage)h(of)g(strong)g(cryptographic)89
+2129 y(metho)q(ds)16 b(for)g(authen)o(tication.)p 89 2201 720
+2 v 145 2232 a Fm(4)164 2247 y Fl(UNIX)e(is)g(a)f(trademark)g(of)h(No)o(v)o
+(ell)977 2715 y Ft(3)p eop
+%%Page: 4 4
+3 bop 89 90 a Fu(2)83 b(The)27 b(Problem)89 215 y Fg(2.1)70
+b(Statemen)n(t)21 b(of)i(the)f(Problem)89 307 y Ft(Authen)o(ticit)o(y)16
+b(is)k(based)f(on)h(the)f(iden)o(tit)o(y)e(of)j(some)e(en)o(tit)o(y)l(.)29
+b(This)19 b(en)o(tit)o(y)e(has)j(to)g(pro)o(v)o(e)f(that)89
+367 y(it)g(is)g(gen)o(uine.)30 b(In)19 b(man)o(y)e(net)o(w)o(ork)i
+(applications)g(the)h(iden)o(tit)o(y)d(of)i(participating)g(en)o(tities)f(is)
+89 427 y(simply)e(determined)g(b)o(y)i(their)f(names)h(or)g(addresses.)28
+b(High{lev)o(el)16 b(applications)j(use)f(mainly)89 487 y(names)f(for)g
+(authen)o(tication)h(purp)q(oses,)g(b)q(ecause)g(address)g(lists)f(are)h(m)o
+(uc)o(h)d(harder)j(to)g(create,)89 548 y(understand,)f(and)f(main)o(tain)f
+(than)i(name)e(lists.)162 608 y(Assuming)f(an)j(en)o(tit)o(y)c(w)o(an)o(ts)j
+(to)g(sp)q(o)q(of)h(the)f(iden)o(tit)o(y)d(of)j(some)e(other)i(en)o(tit)o(y)l
+(,)d(it)j(is)f(in)g(some)89 668 y(cases)h(enough)g(to)g(c)o(hange)g(the)f
+(mapping)g(b)q(et)o(w)o(een)g(its)g(lo)o(w{lev)o(el)f(address)i(and)g(its)g
+(high{lev)o(el)89 728 y(name.)k(That)d(means)e(that)h(an)h(attac)o(k)o(er)e
+(can)h(fak)o(e)g(the)f(name)g(of)i(someone)e(b)o(y)g(mo)q(difying)g(the)89
+788 y(asso)q(ciation)j(of)g(his)f(address)h(from)e(his)h(o)o(wn)h(name)e(to)h
+(the)g(name)f(he)h(w)o(an)o(ts)h(to)f(imp)q(ersonate.)89 849
+y(Once)f(an)h(attac)o(k)o(er)f(has)h(done)g(that,)f(an)i(authen)o(ticator)e
+(can)h(no)g(longer)f(distinguish)h(b)q(et)o(w)o(een)89 909
+y(the)e(true)g(and)h(the)g(fak)o(ed)f(en)o(tit)o(y)l(.)k(This)c(describ)q(es)
+g(the)h(fundamen)o(tal)e(problem)f(on)j(whic)o(h)f(this)89
+969 y(pap)q(er)e(is)g(based:)20 b Fh(If)12 b(the)g(binding)h(pro)q(cess)g(b)q
+(et)o(w)o(een)f(names)f(and)j(addresses)f(cannot)g(b)q(e)g(trusted)89
+1029 y(fully)l(,)i(no)h(one)h(can)f(rely)f(on)i(an)g(authen)o(tication)f(pro)
+q(cess)h(on)f(a)h(high{lev)o(el.)89 1174 y Fg(2.2)70 b(The)22
+b(Problem)g(in)g(the)g(DNS)89 1266 y Ft(T)l(o)h(understand)h(the)e(metho)q(d)
+g(ho)o(w)i(to)f(deceiv)o(e)d(the)j(DNS)g(w)o(e)f(\014rst)h(giv)o(e)f(an)h
+(example)e(for)89 1326 y(a)i(v)m(alid)g(name)f(resolution)h(in)g(the)f(DNS.)h
+(The)g(resolution)g(is)g(based)g(on)h(the)e(clien)o(t{serv)o(er)89
+1386 y(paradigm.)e(An)o(y)14 b(pro)q(cess)h(that)h(accepts)e(a)h(connection)g
+(from)e(another)j(host)f(receiv)o(es)e(from)g(its)89 1447 y(lo)o(w)o(er)h
+(proto)q(col)h(la)o(y)o(er)e(the)i(connecting)f(host's)h(IP)g(address.)21
+b(The)15 b(pro)q(cess)g(then)g(calls)f(its)g(lo)q(cal)89 1507
+y(resolv)o(er)j(with)h(this)g(IP)g(address)h(as)g(an)g(argumen)o(t)e(and)i
+(requests)e(the)h(according)h(hostname.)89 1567 y(The)14 b(resolv)o(er)e
+(forms)h(a)h(query)f(for)h(the)f(giv)o(en)g(IP)h(address)g(and)g(w)o(aits)g
+(to)g(retriev)o(e)e(the)h(resp)q(onse)89 1627 y(con)o(taining)18
+b(the)h(answ)o(er)f(to)h(its)g(query)f(from)f(the)h(default)h(name)e(serv)o
+(er.)27 b(This)19 b(name)e(serv)o(er)89 1687 y(could)g(b)q(e)g(running)g(on)g
+(the)f(same)g(host)i(with)e(the)h(resolv)o(er)f(soft)o(w)o(are,)g(on)h(a)h
+(host)f(in)g(the)f(lo)q(cal)89 1747 y(domain)e(of)i(the)e(resolv)o(er,)g(or)i
+(on)f(a)h(host)f(outside)g(the)g(lo)q(cal)g(domain.)20 b(The)15
+b(selection)f(of)i(whic)o(h)89 1808 y(name)e(serv)o(er)h(to)h(con)o(tact)g
+(dep)q(ends)g(on)g(the)f(name)g(or)h(address)g(to)g(b)q(e)g(resolv)o(ed.)k
+(The)c(decision)89 1868 y(pro)q(cess)h(ab)q(out)g(this)g(c)o(hoice)d(is)j(sp)
+q(eci\014ed)e(in)h([Mo)q(c87)q(,)f(sections)i(4.3.2,)f(5.3.3].)162
+1928 y(Queries)g(to)h(name)f(serv)o(ers)g(from)f(a)j(resolv)o(er)d(come)g(in)
+i(t)o(w)o(o)f(\015a)o(v)o(ors:)23 b Fh(recursiv)o(e)15 b Ft(and)i
+Fh(itera-)89 1988 y(tiv)o(e)p Ft(.)i(In)14 b(recursiv)o(e)f(resolution,)i(a)f
+(resolv)o(er)g(sends)h(a)g(recursiv)o(e)d(query)i(to)h(a)g(name)e(serv)o(er.)
+20 b(The)89 2048 y(queried)12 b(name)h(serv)o(er)f(then)i(has)g(the)g
+(obligation)g(to)f(resp)q(ond)i(with)e(the)h(answ)o(er)g(to)g(that)g(query)89
+2109 y(or)h(an)f(error)h(co)q(de.)20 b(If)14 b(a)h(name)e(serv)o(er)g(cannot)
+i(resolv)o(e)e(the)h(query)f(lo)q(cally)l(,)h(it)f(calls)h(its)g(resolv)o(er)
+89 2169 y(and)h(queries)e(recursiv)o(ely)f(another)j(name)e(serv)o(er.)20
+b(This)15 b(is)f(rep)q(eated)g(un)o(til)f(one)i(queried)e(name)89
+2229 y(serv)o(er)20 b(supplies)g(the)h(answ)o(er)g(or)g(an)g(error)g(co)q(de)
+g(that)g(then)f(tra)o(v)o(els)g(the)h(rev)o(erse)e(path.)35
+b(In)89 2289 y(iterativ)o(e)13 b(resolution,)j(the)f(con)o(tacted)g(name)f
+(serv)o(er)g(returns)i(an)f(answ)o(er)h(to)g(the)f(query)f(to)i(the)89
+2349 y(requesting)i(resolv)o(er.)27 b(This)19 b(is)g(a)g(referral)e(to)i
+(another)h(name)d(serv)o(er)h(that)h(is)f(more)g(lik)o(ely)e(to)89
+2410 y(kno)o(w)h(the)g(answ)o(er,)g(or)g(an)h(error)f(co)q(de)g(to)h(signal)f
+(the)g(o)q(ccurrence)f(of)i(an)f(exception)f(or)h(error.)89
+2470 y(The)f(rep)q(eated)g(resolution)h(attempts)e(are)h(p)q(erformed)f(b)o
+(y)h(the)g(lo)q(cal)g(resolv)o(er.)162 2530 y(Man)o(y)g(securit)o(y)g
+(problems)f(of)i(the)f(TCP/IP)i(proto)q(col)f(suite)f(build)h(on)g(the)f
+(abilit)o(y)f(of)i(the)89 2590 y(attac)o(k)o(er)i(to)h(sp)q(o)q(of)i(the)e
+(IP)f(address)i(of)f(a)h(trusted)f(mac)o(hine,)e(as)i(describ)q(ed)g(in)f
+([Bel89)o(].)32 b(As)977 2715 y(4)p eop
+%%Page: 5 5
+4 bop 201 1145 a @beginspecial 0 @llx 0 @lly 378 @urx 252 @ury
+3780 @rwi @setspecial
+%%BeginDocument: setup.eps
+/$F2psDict 200 dict def 
+$F2psDict begin
+$F2psDict /mtrx matrix put
+/l {lineto} bind def
+/m {moveto} bind def
+/s {stroke} bind def
+/n {newpath} bind def
+/gs {gsave} bind def
+/gr {grestore} bind def
+/clp {closepath} bind def
+/graycol {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
+4 -2 roll mul setrgbcolor} bind def
+/col-1 {} def
+/col0 {0 0 0 setrgbcolor} bind def
+/col1 {0 0 1 setrgbcolor} bind def
+/col2 {0 1 0 setrgbcolor} bind def
+/col3 {0 1 1 setrgbcolor} bind def
+/col4 {1 0 0 setrgbcolor} bind def
+/col5 {1 0 1 setrgbcolor} bind def
+/col6 {1 1 0 setrgbcolor} bind def
+/col7 {1 1 1 setrgbcolor} bind def
+	end
+/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
+/$F2psEnd {$F2psEnteredState restore end} def
+
+$F2psBegin
+0 setlinecap 0 setlinejoin
+-9.0 270.0 translate 0.900 -0.900 scale
+1.000 setlinewidth
+n 99 19 m 99 39 l gs col-1 s gr
+n 99 279 m 99 299 l gs col-1 s gr
+n 339 19 m 339 39 l gs col-1 s gr
+n 339 279 m 339 299 l gs col-1 s gr
+0.500 setlinewidth
+n 159 59 m 279 59 l gs col-1 s gr
+n 271.000 57.000 m 279.000 59.000 l 271.000 61.000 l gs 2 setlinejoin col-1 s gr
+1.000 setlinewidth
+	[6.000000] 0 setdash
+n 379 19 m 419 19 l gs col-1 s gr
+	[] 0 setdash
+	[6.000000] 0 setdash
+n 59 19 m 14 19 l gs col-1 s gr
+	[] 0 setdash
+	[6.000000] 0 setdash
+n 379 299 m 419 299 l gs col-1 s gr
+	[] 0 setdash
+	[6.000000] 0 setdash
+n 59 299 m 14 299 l gs col-1 s gr
+	[] 0 setdash
+n 59 19 m 139 19 l gs col-1 s gr
+n 299 19 m 379 19 l gs col-1 s gr
+n 59 299 m 139 299 l gs col-1 s gr
+n 299 299 m 379 299 l gs col-1 s gr
+	[6.000000] 0 setdash
+n 259 299 m 299 299 l gs col-1 s gr
+	[] 0 setdash
+	[6.000000] 0 setdash
+n 139 299 m 179 299 l gs col-1 s gr
+	[] 0 setdash
+	[6.000000] 0 setdash
+n 259 19 m 299 19 l gs col-1 s gr
+	[] 0 setdash
+	[6.000000] 0 setdash
+n 139 19 m 179 19 l gs col-1 s gr
+	[] 0 setdash
+0.500 setlinewidth
+n 46 39 m 39 39 39 72 7 arcto 4 {pop} repeat 39 79 152 79 7 arcto 4 {pop} repeat 159 79 159 46 7 arcto 4 {pop} repeat 159 39 46 39 7 arcto 4 {pop} repeat clp gs 0.95 setgray fill gr
+gs col-1 s gr
+n 286 39 m 279 39 279 72 7 arcto 4 {pop} repeat 279 79 392 79 7 arcto 4 {pop} repeat 399 79 399 46 7 arcto 4 {pop} repeat 399 39 286 39 7 arcto 4 {pop} repeat clp gs 0.95 setgray fill gr
+gs col-1 s gr
+n 46 239 m 39 239 39 272 7 arcto 4 {pop} repeat 39 279 152 279 7 arcto 4 {pop} repeat 159 279 159 246 7 arcto 4 {pop} repeat 159 239 46 239 7 arcto 4 {pop} repeat clp gs 0.95 setgray fill gr
+gs col-1 s gr
+n 286 239 m 279 239 279 272 7 arcto 4 {pop} repeat 279 279 392 279 7 arcto 4 {pop} repeat 399 279 399 246 7 arcto 4 {pop} repeat 399 239 286 239 7 arcto 4 {pop} repeat clp gs 0.95 setgray fill gr
+gs col-1 s gr
+n 77.000 87.000 m 79.000 79.000 l 81.000 87.000 l gs 2 setlinejoin col-1 s gr
+n 79 79 m 79 239 l gs col-1 s gr
+n 81.000 231.000 m 79.000 239.000 l 77.000 231.000 l gs 2 setlinejoin col-1 s gr
+	1 setlinecap [1 3.000000] 3.000000 setdash
+n 9 189 m 429 189 l gs col-1 s gr
+	[] 0 setdash 0 setlinecap
+n 319 239 m
+	323.644 205.212 323.644 190.212 319 179 curveto
+	316.081 171.953 306.047 161.919 299 159 curveto
+	259.136 142.488 178.864 175.512 139 159 curveto
+	131.953 156.081 121.919 146.047 119 139 curveto
+	114.356 127.788 114.356 112.788 119 79 curveto
+gs col-1 s gr
+n 115.929 86.653 m 119.000 79.000 l 119.892 87.198 l gs 2 setlinejoin col-1 s gr
+/Courier-Bold findfont 12.00 scalefont setfont
+314 74 m 
+gs 1 -1 scale (boromir) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+74 74 m 
+gs 1 -1 scale (aragorn) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+349 209 m 
+gs 1 -1 scale (attack.dom) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+349 179 m 
+gs 1 -1 scale (defend.dom) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+44 54 m 
+gs 1 -1 scale (user:) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+74 54 m 
+gs 1 -1 scale (alice) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+314 54 m 
+gs 1 -1 scale (bob) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+144 149 m 
+gs 1 -1 scale (Hi! I am) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+189 149 m 
+gs 1 -1 scale (bob@boromir.defend.dom) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+284 54 m 
+gs 1 -1 scale (user:) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+284 74 m 
+gs 1 -1 scale (host:) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+44 74 m 
+gs 1 -1 scale (ns:) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+84 214 m 
+gs 1 -1 scale (exchange of DNS packets) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+149 99 m 
+gs 1 -1 scale (alice@aragorn) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+244 99 m 
+gs 1 -1 scale (trusts) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+279 99 m 
+gs 1 -1 scale (bob@boromir) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+69 264 m 
+gs 1 -1 scale (caradhras) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+314 264 m 
+gs 1 -1 scale (dwimmerlaik) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+284 264 m 
+gs 1 -1 scale (host:) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+44 264 m 
+gs 1 -1 scale (ns:) col-1 show gr
+$F2psEnd
+%%EndDocument
+ @endspecial 556 1300 a Ft(Figure)16 b(1:)21 b(Example)15 b(top)q(ology)i(of)
+g(mac)o(hines)89 1435 y(hosts)j(trust)f(eac)o(h)g(other,)g(usually)f(on)i
+(the)f(basis)g(of)g(hostnames,)g(an)h(attac)o(k)o(er)e(can)h(tak)o(e)f(the)89
+1495 y(easier)i(approac)o(h)h(and)g(sp)q(o)q(of)h(a)f(host's)g(name)e
+(instead)h(of)h(its)f(IP)g(address.)35 b(The)20 b(pro)q(cess)h(is)89
+1555 y(depicted)15 b(in)h(\014gure)g(1.)162 1615 y(Assume)11
+b(that)i(user)f Ff(alice@arag)o(orn)o(.de)o(fen)o(d.)o(dom)d
+Ft(trusts)k(user)f Ff(bob@boromi)o(r.d)o(ef)o(end)o(.)89 1675
+y(dom)18 b Ft(via)g(the)h Fh(.rhosts)g Ft(mec)o(hanism)o(.)26
+b(If)18 b(a)h(host)h(named)e Ff(boromir.d)o(ef)o(end)o(.do)o(m)e
+Ft(accesses)i(an-)89 1735 y(other)j(host)g(named)e Ff(aragorn.de)o(fen)o(d.d)
+o(om)p Ft(,)f(host)j Ff(aragorn)d Ft(accepts)i(the)g(connection)g(and)89
+1796 y(retriev)o(es)i(address)j(information)d(ab)q(out)j(the)f(connecting)g
+(host)g Ff(boromir)p Ft(.)42 b(Host)24 b Ff(aragorn)89 1856
+y Ft(reads)c(host)g Ff(boromir)p Ft('s)d(IP)j(address)g(and)h(con)o(v)o(erts)
+d(it)i(in)o(to)f(a)h(regular)g(hostname.)31 b(T)l(o)20 b(bind)89
+1916 y(the)f(righ)o(t)h(name)e(to)i(the)f(IP)h(address,)h(host)f
+Ff(aragorn)d Ft(starts)j(a)g(DNS)g(query)f(in)g(the)g(rev)o(erse)89
+1976 y(lo)q(okup)c(tree,)f(the)h(database)h(p)q(ortion)g(that)f(con)o(tains)g
+(the)g(IP)f(address)i(to)f(hostname)g(mapping)89 2036 y(information.)162
+2097 y(F)l(or)23 b(a)g(pair)g(of)g(mac)o(hines)d Ff(caradhras.a)o(tta)o(ck.)o
+(do)o(m)g Ft(and)j Ff(dwimmerlai)o(k.a)o(tta)o(ck)o(.do)o(m)89
+2157 y Ft(under)17 b(the)g(p)q(o)o(w)o(er)h(of)g(an)f(attac)o(k)o(er,)g(with)
+g Ff(caradhras)d Ft(running)k(a)f(primary)f(name)g(serv)o(er)h(for)89
+2217 y(a)e(certain)f(zone,)g(and)i Ff(dwimmerla)o(ik)11 b Ft(trying)k(to)g
+(fak)o(e)f Ff(boromir)p Ft('s)e(iden)o(tit)o(y)l(,)g(it)j(is)f(easy)h(to)g
+(mak)o(e)89 2277 y Ff(aragorn)f Ft(b)q(eliev)o(e)h Ff(dwimmerlai)o(k)f
+Ft(w)o(as)j Ff(boromir)p Ft(.)k Ff(dwimmerla)o(ik)13 b Ft(connects)k(to)g
+Ff(aragorn)d Ft(and)89 2337 y(claims)e(to)i(b)q(e)g Ff(boromir)p
+Ft(,)d Ff(aragorn)g Ft(retriev)o(es)h Ff(dwimmerlai)o(k)p Ft('s)f(IP)i
+(address)i Ff(111.22.33)o(.4)10 b Ft(and)89 2398 y(queries)i(the)i(name)e
+Ff(4.33.22.11)o(1.i)o(n-)o(add)o(r.a)o(rpa)e Ft(from)i(the)h(DNS.)g(One)g
+(single)g(en)o(try)g(in)g(the)89 2458 y(authoritativ)o(e)18
+b(data)h(for)g(the)g(rev)o(erse)e(lo)q(okup)i(tree)f(for)h
+Ff(caradhras)p Ft(')o(s)d(zone)j(sp)q(eci\014es)f(the)g(IP)89
+2518 y(address{to{name)h(mapping)e(b)q(et)o(w)o(een)g Ff(4.33.22.111)o(.in)o
+(-ad)o(dr)o(.ar)o(pa)e Ft(and)j Ff(dwimmerlaik)o Ft(.)89 2578
+y(If)d(the)h(attac)o(k)o(er)e(replaces)h(this)h(line)f(b)o(y)g(a)h(mapping)f
+(b)q(et)o(w)o(een)g Ff(4.33.22.1)o(11.)o(in-)o(add)o(r.)o(arp)o(a)977
+2715 y Ft(5)p eop
+%%Page: 6 6
+5 bop 89 82 a Ft(and)17 b Ff(boromir)p Ft(,)c Ff(aragorn)p
+Ft('s)h(resolution)i(attempt)f(will)g(\014nally)h(gran)o(t)h
+Ff(dwimmerlai)o(k)c Ft(access)k(to)89 142 y Ff(aragorn)p Ft(.)162
+203 y(This)e(sho)o(ws)g(the)g(simplicit)n(y)d(of)j(an)g(attac)o(k)f(that)h
+(is)g(based)g(up)q(on)g(trust)g(placed)f(in)h(the)f(data)89
+263 y(pro)o(vided)h(b)o(y)h(DNS.)f(It)g(is)h(based)g(on)h(a)f(w)o(eakness)g
+(in)g(the)f(DNS,)h(not)g(an)g(easily)f(\014xable)h(bug)g(in)89
+323 y(the)g(implem)o(en)o(tati)o(on)e(of)j(a)f(particular)g(net)o(w)o(ork)g
+(service.)162 383 y(One)c(widely)f(accepted)g(w)o(a)o(y)g(of)i(dealing)e
+(with)h(this)g(problem)e(is)i(adding)h(an)f(additional)g(DNS)89
+443 y(query)i(of)i(the)f(determined)e(hostname)i(to)g(the)g(serv)o(er)f(co)q
+(de)i(and)g(comparing)e(the)h(returned)g(IP)89 504 y(addresses)22
+b(against)h(the)e(original)h(IP)f(address)h(for)g(a)g(matc)o(h.)36
+b(This)22 b(only)f(adds)i(marginally)89 564 y(to)f(the)f(qualit)o(y)f(of)h
+(securit)o(y;)h(it)f(do)q(es)h(not)g(pro)o(vide)e(complete)g(securit)o(y)l(.)
+34 b(An)21 b(attac)o(k)o(er)g(can)89 624 y(piggybac)o(k)16
+b(additional)h(resource)f(records)g(to)h(the)f(answ)o(er)h(pac)o(k)o(et)e(to)
+i(the)g(\014rst)f(query)l(.)21 b(Doing)89 684 y(so,)26 b(the)f(attac)o(k)o
+(er)e(p)q(oisons)j(the)e(victim')o(s)e(cac)o(he)h(with)i(false)f
+(information,)g(suc)o(h)g(that)h(the)89 744 y(forw)o(ard)17
+b(lo)q(okup)g(w)o(ould)f(not)h(disclose)e(the)h(attac)o(k.)89
+889 y Fg(2.3)70 b(W)-6 b(eaknesses)89 981 y Ft(In)21 b(this)f(paragraph)j(w)o
+(e)e(describ)q(e)f(the)h(conditions)g(that)g(facilitate)f(a)h(break{in.)35
+b(The)21 b(DNS)89 1041 y(is)e(w)o(eak)h(in)f(sev)o(eral)g(places.)31
+b(W)l(e)19 b(examine)e(the)j(problems)e(of)i(name{based)f(authen)o(tication)
+89 1101 y(pro)q(cesses,)26 b(trusting)e(information)f(that)i(comes)d(from)h
+(an)i(un)o(trust)o(w)o(orth)o(y)e(authorit)o(y)l(,)i(and)89
+1162 y(accepting)14 b(additional,)h(p)q(ossibly)g(incorrect)f(information)g
+(that)i(w)o(as)f(not)h(requested,)d(but)j(that)89 1222 y(seems)f(to)h(pro)o
+(vide)g(adv)m(an)o(tages)h(for)g(run)o(time)d(p)q(erformance.)89
+1352 y Fe(2.3.1)55 b(Assumptions)18 b(to)g(F)-5 b(acilitate)18
+b(Break{ins)89 1444 y Ft(In)g(our)g(setup)g(w)o(e)g(assume)f(that)i(the)f
+(attac)o(k)o(er)f(has)h(complete)e(con)o(trol)i(o)o(v)o(er)f(mac)o(hine)f
+Ff(cara-)89 1504 y(dhras.atta)o(ck.)o(do)o(m)e Ft(running)j(a)h(legitimate)c
+(primary)h(name)h(serv)o(er)g(for)h(a)h(DNS)f(zone.)23 b(This)89
+1564 y(strong)18 b(assumption)f(do)q(es)h(not)f(alw)o(a)o(ys)g(need)g(to)h(b)
+q(e)f(satis\014ed.)24 b(It)17 b(is)g(simply)e(the)h(easiest)h(w)o(a)o(y)89
+1625 y(for)h(an)h(attac)o(k)o(er)e(if)h(he)g(con)o(trols)g(a)h(primary)d
+(name)h(serv)o(er,)h(b)q(ecause)g(of)g(its)g(capabilities)f(and)89
+1685 y(the)f(fact)g(that)h(other)f(mac)o(hines)e(b)q(eliev)o(e)h(name)g(serv)
+o(ers.)162 1745 y(Dep)q(ending)g(on)h(the)f(top)q(ology)h(of)f(a)h(real)e
+(net)o(w)o(ork)h(it)f(is)h(su\016cien)o(t)f(if)g(an)i(attac)o(k)o(er)e(con)o
+(trols)89 1805 y(one)i(of)g(the)f(authoritativ)o(e)g(name)f(serv)o(ers)h(for)
+h(the)f(particular)g(zone:)21 b(the)15 b(one)h(that)g(is)f(queried)89
+1865 y(\014rst)k(b)o(y)f(the)h(remote)e(resolv)o(er.)27 b(It)18
+b(is)h(not)g(m)o(uc)o(h)d(more)i(di\016cult)f(for)i(an)g(attac)o(k)o(er)f(to)
+h(satisfy)89 1926 y(this)d(second)h(assumption)e(than)i(the)f(\014rst)h(one.)
+162 1986 y(The)k(con)o(trol)g(m)o(ust)f(include)f(the)i(abilit)o(y)f(to)h(up)
+q(date)h(the)e(asso)q(ciated)i(in)o(v)o(erse)e(mapping)89 2046
+y(tree.)g(The)13 b(attac)o(k)o(er)g(migh)o(t)f(ha)o(v)o(e)h(successfully)g
+(sub)o(v)o(erted)f(suc)o(h)i(a)g(mac)o(hine)e(or)i(simply)d(b)q(e)j(the)89
+2106 y(legitimate)i(o)o(wner)i(of)h(it.)27 b(In)19 b(the)f(follo)o(wing)g
+(discussion)h(w)o(e)f(will)f(assume)h(that)h(the)f(attac)o(k)o(er)89
+2166 y(has)f(suc)o(h)f(access)g(to)h(a)f(primary)f(name)g(serv)o(er.)89
+2296 y Fe(2.3.2)55 b(Authen)n(tication)18 b(via)g(Hostnames)89
+2389 y Ft(W)l(e)c(explained)f(in)h(the)g(in)o(tro)q(duction)g(that)g(users)h
+(need)e(to)i(b)q(e)f(authorized)g(b)o(y)g(net)o(w)o(ork)f(service)89
+2449 y(pro)o(viders)20 b(b)q(efore)g(they)g(can)h(use)f(the)g(service.)33
+b(This)20 b(authen)o(tication)g(is)g(usually)h(based)f(on)89
+2509 y(the)d(v)o(eri\014cation)e(of)j(the)e(user's)h(login)g(name)e(along)j
+(with)f(the)g(asso)q(ciated)h(passw)o(ord)g(and)f(the)89 2569
+y(hostname)j(of)g(the)g(mac)o(hine)e(on)j(whic)o(h)e(the)h(user)g(starts)h
+(his)g(requests.)32 b(Net)o(w)o(orks)20 b(\(as)g(w)o(ell)977
+2715 y(6)p eop
+%%Page: 7 7
+6 bop 89 82 a Ft(as)20 b(systems)e(in)h(general\))g(ma)o(y)f(b)q(e)i
+(classi\014ed)f(in)o(to)g(di\013eren)o(t)f(partitions:)28 b(Closed)19
+b(Net)o(w)o(orks,)89 142 y(Op)q(en)d(Net)o(w)o(orks,)f(and)i(T)l(rusted)g
+(Net)o(w)o(orks)e([PL91)q(].)162 203 y(Closed)22 b(Net)o(w)o(orks)f(can)h(b)q
+(e)f(accessed)h(only)f(within)g(certain)g(b)q(oundaries.)39
+b(Sessions)22 b(are)89 263 y(con)o(trolled)h(and)h(secured)f(in)h(accordance)
+f(with)h(the)g(rules)f(implied)e(b)o(y)i(an)h(organization's)89
+323 y(p)q(olicy)l(.)19 b(In)10 b(a)h(Closed)g(Net)o(w)o(ork,)g(the)f(lo)q
+(cations)i(of)f(all)f(resources)h(are)g(w)o(ell)e(kno)o(wn)j(and)f(sp)q
+(eci\014ed.)162 383 y(Op)q(en)k(Net)o(w)o(orks)g(are)g(regions)h(separated)f
+(b)o(y)g(b)q(oundaries)h(from)e(their)h(surroundings,)h(but)89
+443 y(the)h(transfer)h(of)g(information)f(across)h(these)g(b)q(oundaries)g
+(is)g(allo)o(w)o(ed.)24 b(They)18 b(are)f(augmen)o(ted)89 504
+y(b)o(y)e(publicly)f(accessible)g(parts)i(or)g(connections)f(to)h(net)o(w)o
+(orks)f(o)o(wned)g(b)o(y)g(other)g(companies)g(or)89 564 y(organizations.)21
+b(These)14 b(t)o(w)o(o)f(extensions)h(mak)o(e)d(this)j(t)o(yp)q(e)f(of)h(net)
+o(w)o(ork)f(vulnerable)f(to)i(external)89 624 y(threats.)162
+684 y(T)l(rusted)k(Net)o(w)o(orks)f(in)o(tro)q(duce)g(the)g(concept)g(that)h
+(net)o(w)o(ork)f(access)g(is)h(con)o(trolled)e(at)i(the)89
+744 y(en)o(try)j(no)q(de.)41 b(In)22 b(the)g(case)g(of)h(large)g(in)o
+(ternational)e(net)o(w)o(orks,)i(main)o(tainabilit)o(y)d(and)j(con-)89
+804 y(trollabilit)o(y)16 b(are)j(imp)q(ortan)o(t)e(issues.)28
+b(Adopting)18 b(the)g(T)l(rusted)h(Net)o(w)o(ork)e(concept)h(allo)o(ws)g(the)
+89 865 y(decomp)q(osition)12 b(of)i(a)g(large)f(net)o(w)o(ork,)g(gro)o(wing)h
+(to)o(w)o(ards)g(an)f(unmanageable)g(complexit)o(y)l(,)d(in)o(to)89
+925 y(relativ)o(ely)i(small)g(national)j(or)g(regional)f(net)o(w)o(orks,)g
+(eac)o(h)f(supp)q(orted)j(b)o(y)d(lo)q(cal)h(sta\013,)i(and)e(eac)o(h)89
+985 y(pro)o(vided)h(with)h(its)g(o)o(wn)h(net)o(w)o(ork)f(access)g(con)o
+(trol.)21 b(The)16 b(adv)m(an)o(tages)h(are)f(increased)g(con)o(trol-)89
+1045 y(labilit)o(y)l(,)d(main)o(tainabilit)o(y)l(,)g(manageabilit)o(y)l(,)g
+(and)k(simpli\014cation)d(of)i(c)o(hange)g(managemen)o(t.)i(A)89
+1105 y(T)l(rusted)12 b(Net)o(w)o(ork)f(can)h(b)q(e)g(regarded)g(globally)f
+(as)i(a)f(single)f(Closed)h(Net)o(w)o(ork,)f(but)h(from)f(a)h(lo)q(cal)89
+1166 y(p)q(oin)o(t)k(of)g(view,)f(the)g(in)o(terconnected)f(net)o(w)o(orks)i
+(stand)g(widely)f(op)q(en)h(with)g(all)f(the)h(applicable)89
+1226 y(securit)o(y)f(threats.)162 1286 y(The)g(In)o(ternet)e(is)h(a)h(system)
+e(of)i(T)l(rusted)g(Net)o(w)o(orks)f(within)g(Op)q(en)h(Net)o(w)o(orks.)k
+(This)c(allo)o(ws)89 1346 y(the)d(danger)g(that)h(once)f(someone)f(has)i
+(falsely)e(gained)h(access)g(to)h(one)f(mac)o(hine,)e(it)i(is)f(m)o(uc)o(h)f
+(sim-)89 1406 y(pler)k(to)h(sub)o(v)o(ert)f(others.)21 b(The)14
+b(term)f Fh(net{sur\014ng)j Ft(describ)q(es)e(the)h(journey)f(through)i(a)f
+(n)o(um)o(b)q(er)89 1467 y(of)20 b(sub)o(v)o(erted)e(systems)g(with)h(the)g
+(goal)h(of)g(sub)o(v)o(erting)f(others.)31 b(Within)18 b(T)l(rusted)i(Net)o
+(w)o(orks)89 1527 y(users)h(are)g(authen)o(ticated)f(solely)g(b)o(y)g(their)g
+(login)h(name)f(and)h(connecting)g(hostname.)34 b(The)89 1587
+y(login)21 b(name)f(is)h(sp)q(eci\014ed)g(b)o(y)f(the)h(connecting)g(site,)g
+(and)h(therefore)e(can)i(b)q(e)f(falsi\014ed,)g(suc)o(h)89
+1647 y(that)g(the)f(only)g(reliable)f(information)g(left)h(for)h(the)f
+(addressed)h(mac)o(hine)d(is)i(the)g(connecting)89 1707 y(mac)o(hine's)13
+b(IP)j(address.)21 b(The)16 b(addressed)g(mac)o(hine)e(then)h(maps)g(the)h
+(IP)f(address)i(in)o(to)e(a)h(host-)89 1768 y(name)i(using)h(the)g(DNS.)g(If)
+f(an)i(attac)o(k)o(er)e(manages)h(to)g(sub)o(v)o(ert)f(this)h(name)f(binding)
+h(call,)f(he)89 1828 y(can)e(falsify)f(the)h(name)f(of)h(a)g(mac)o(hine)e
+(within)h(the)h(T)l(rusted)g(Net)o(w)o(ork)f(and)i(therefore)e(succeed)89
+1888 y(in)h(his)g(attac)o(k.)89 2018 y Fe(2.3.3)55 b(T)-5 b(rusting)19
+b(a)g(Not)f(T)-5 b(rust)n(w)n(orth)n(y)20 b(Source)89 2110
+y Ft(Using)f(the)h(DNS)f(to)h(map)f(the)g(IP)g(address)i(pro)o(vided)e(b)o(y)
+g(lo)o(w)o(er{lev)o(el)e(proto)q(col)j(la)o(y)o(ers)e(in)o(to)89
+2170 y(the)i(applicable)g(hostname,)h(the)g(addressed)g(host)g(blindly)f
+(trusts)h(the)f(information)g(that)h(is)89 2231 y(pro)o(vided)f(b)o(y)h(the)f
+(DNS.)h(Information)e(that)j(comes)d(from)h(sources)h(outside)g(of)g(the)g
+(trusted)89 2291 y(area)g(is)f(trusted.)34 b(That)21 b(is)f(a)h(sev)o(ere)e
+(violation)h(of)g(the)g(partitioning)h(concept.)33 b(Only)20
+b(truly)89 2351 y(authoritativ)o(e)c(information)f(should)i(b)q(e)f(trusted.)
+977 2715 y(7)p eop
+%%Page: 8 8
+7 bop 89 82 a Fe(2.3.4)55 b(Believing)16 b(Additional,)i(Not)g(Authoritativ)n
+(e)g(Information)89 175 y Ft(E\016ciency)e(is)i(one)g(of)h(the)e(stated)i
+(goals)g(of)f(the)g(DNS.)f(The)h(DNS)g(proto)q(col)h(pac)o(k)o(ets)e(con)o
+(tain)89 235 y(an)h(additional)g(answ)o(er)g(section.)24 b(Using)18
+b(this,)f(name)f(serv)o(ers)h(can)h(pro)o(vide)f(resource)g(records)89
+295 y(con)o(taining)22 b(information)f(that)i(could)f(b)q(e)h(useful)f(in)g
+(future)g(requests,)h(but)f(that)h(w)o(ere)f(not)89 355 y(explicitly)15
+b(requested.)24 b(There)17 b(are)g(situations)h(where)g(these)f(additional)g
+(records)h(aid)f(system)89 415 y(e\016ciency)l(.)40 b(If)22
+b(the)h(answ)o(er)h(to)f(a)h(query)e(is)h(a)h(referral)e(to)h(another)h(name)
+e(serv)o(er,)h(then)g(it)89 475 y(is)g(b)q(ene\014cial)f(to)h(add)h(that)f
+(name)f(serv)o(er's)f(IP)i(addresses)h(to)f(the)g(resp)q(onse.)42
+b(That)23 b(sa)o(v)o(es)89 536 y(the)g(lo)q(okup)h(of)f(the)g(name)f(serv)o
+(er's)g(asso)q(ciated)j(IP)e(addresses,)i(once)e(its)g(name)f(is)h(found.)89
+596 y(Additional)15 b(resource)h(records)h(are)f(cac)o(hed)g(for)g(future)g
+(use.)162 656 y(As)j(w)o(e)g(rely)g(on)h(the)f(correctness)g(of)h(these)f
+(additional)g(records)h(once)f(w)o(e)g(use)g(them,)f(w)o(e)89
+716 y(trust)k(information)f(that)i(comes)d(from)h(a)i(source)f(p)q(ossibly)g
+(outside)g(of)g(the)g(trusted)g(scop)q(e.)89 776 y(That)17
+b(is)f(another)h(violation)f(of)g(the)g(partitioning)g(concept.)89
+943 y Fu(3)83 b(P)n(olicies)26 b(and)i(Mec)n(hanisms)d(as)i(Solutions)89
+1052 y Ft(W)l(e)16 b(iden)o(tify)f(p)q(olicies)h(and)h(mec)o(hanisms)d(that)j
+(serv)o(e)f(as)h(solutions)g(or)g(that)h(simply)c(augmen)o(t)89
+1113 y(the)j(lev)o(el)f(of)i(securit)o(y)e(of)i(the)g(authen)o(tication)f
+(pro)q(cess.)26 b(Because)17 b(man)o(y)g(factors)h(con)o(tribute)89
+1173 y(to)j(the)f(securit)o(y)f(breac)o(h)h(encoun)o(tered)g(in)g(this)g(pap)
+q(er)h(and)g(all)f(of)h(them)e(are)i(necessary)f(for)89 1233
+y(the)d(w)o(eakness)g(to)h(exist,)e(it)g(is)h(su\016cien)o(t)f(to)i
+(eliminate)c(at)k(least)f(one)g(of)h(them.)k(That)c(sounds)89
+1293 y(easy)e(to)g(accomplish,)e(but)i(is)g(a)h(di\016cult)d(task)j(in)e
+(practice,)g(b)q(ecause)h(eliminating)e(an)o(y)i(one)g(of)89
+1353 y(the)j(factors)i(brings)f(with)f(it)g(a)h(disadv)m(an)o(tageous)i
+(trade{o\013)f(with)e(functionalit)o(y)l(,)g(e\016ciency)l(,)89
+1414 y(or)e(con)o(v)o(enience.)162 1474 y(W)l(e)k(describ)q(e)g(ev)m
+(aluation)h(criteria)e(and)i(presen)o(t)f(for)h(eac)o(h)f(of)g(our)h
+(solutions)g(necessary)89 1534 y(additional)h(bac)o(kground,)h(follo)o(w)o
+(ed)e(b)o(y)h(a)g(description)f(of)h(the)g(idea)f(of)h(the)g(solution.)41
+b(W)l(e)89 1594 y(mak)o(e)13 b(the)i(distinction)f(b)q(et)o(w)o(een)g(mec)o
+(hanisms)e(that)j(enable)g(the)g(implem)o(e)o(n)o(tation)e(of)i(p)q(olicies)
+89 1654 y(and)23 b(solutions)h(that)f(consist)g(solely)f(of)h(the)f(implem)o
+(en)o(tation)e(of)j(a)g(certain)f(p)q(olicy)l(.)40 b(Eac)o(h)89
+1714 y(solution)17 b(is)f(examined)e(and)j(discussed)f(using)g(applicable)g
+(ev)m(aluation)g(criteria.)162 1775 y(It)21 b(is)f(imp)q(ortan)o(t)g(not)h
+(to)h(view)e(these)g(solutions)h(as)h(stand{alone.)36 b(In)21
+b(di\013eren)o(t)f(com)o(bi-)89 1835 y(nations)i(they)e(ac)o(hiev)o(e)g(sev)o
+(eral)g(degrees)h(of)g(securit)o(y)l(.)34 b(It)21 b(is)g(a)g(go)q(o)q(d)j
+(idea)c(to)i(implem)o(en)n(t)d(a)89 1895 y(com)o(bination)c(of)i(the)f
+(presen)o(ted)f(solutions,)i(to)g(obtain)g(a)g(greater)f(lev)o(el)e(of)j
+(con\014dence)f(in)g(the)89 1955 y(securit)o(y)f(of)h(the)g(DNS.)89
+2100 y Fg(3.1)70 b(Ev)l(aluation)23 b(Criteria)89 2192 y Ft(In)13
+b(solving)g(the)f(problem)g(w)o(e)g(are)h(striving)g(for)g
+Fh(compatibilit)o(y)d(with)j(the)g(original)f(design)h(goals)p
+Ft(.)89 2252 y(In)i(the)g(case)g(of)g(the)g(DNS)g(these)g(goals)h(are)f
+Fh(data)h(consistency)f Ft(\(to)g(pro)o(vide)g(a)g(consisten)o(t)g(view)89
+2312 y(of)g(the)f(name)g(space)g(to)h(b)q(e)g(used)f(to)h(refer)f(to)h
+(resources\),)f Fh(e\016ciency)f Ft(\(to)i(handle)f(the)g(immense)89
+2373 y(v)o(olume)9 b(of)j(data)h(and)f(resolution)f(requests\),)h(a)g
+Fh(distributed)f(c)o(haracter)g Ft(of)h(the)f(implem)o(en)o(tati)o(on)89
+2433 y(\(to)i(pro)o(vide)f(fault)h(tolerance)g(and)g(distributed)g(authorit)o
+(y)f(and)i(main)o(tenance\),)d Fh(generalit)o(y)h Ft(\(to)89
+2493 y(pro)o(vide)g(a)h(general)f(usefulness)g(that)h(satis\014es)g
+(pragmatic)f(reasons)h(lik)o(e)e(implem)o(en)o(tati)o(on)f(costs)89
+2553 y(and)15 b(administrativ)o(e)c(e\013ort\),)k(and)f Fh(indep)q(endence)f
+Ft(\(to)i(pro)o(vide)e(a)i(p)q(ortable)f(system)f(that)h(do)q(es)977
+2715 y(8)p eop
+%%Page: 9 9
+8 bop 89 82 a Ft(not)22 b(dep)q(end)f(on)g(underlying)g(hardw)o(are)g(or)h
+(comm)o(uni)o(cation)d(tec)o(hnology)l(.\))35 b(Eac)o(h)21
+b(of)g(these)89 142 y(goals)f(represen)o(ts)e(a)h(criterion)e(in)i(itself.)27
+b(Indeed,)18 b(the)h(ultimate)d(goal)k(is)e(to)h(guaran)o(tee)g(data)89
+203 y(consistency)l(,)13 b(but)h(not)h(only)e(in)h(the)g(data)g(base)h(but)f
+(also)g(during)g(the)g(mapping)f(pro)q(cess.)21 b(That)89 263
+y(means)11 b(that)i(w)o(e)f(w)o(an)o(t)g(to)h(prev)o(en)o(t)d(the)i(p)q
+(ossibilit)o(y)g(of)g(malicious)e(soft)o(w)o(are)j(in)o(tro)q(ducing)f(wrong)
+89 323 y(asso)q(ciations)20 b(without)e(the)g(data)h(base)g(ev)o(er)d(seeing)
+i(c)o(hanges.)27 b(The)19 b(correctness)e(of)i(this)f(run)89
+383 y(time)c(b)q(eha)o(vior)i(is)g(m)o(uc)o(h)e(harder)j(to)f(ensure)g(than)h
+(the)f(in)o(tegrit)o(y)f(of)h(the)g(data)h(base.)162 443 y(W)l(e)j(consider)f
+(the)g Fh(qualit)o(y)g(of)h(a)g(solution)g Ft(to)g(b)q(e)f(a)h(measuremen)o
+(t)d(of)j(the)f(radius)h(of)g(ap-)89 504 y(plicabilit)o(y)g(of)j(the)g
+(solution.)41 b(The)22 b Fh(feasibilit)o(y)f(of)i(an)g(implem)o(en)o(tation)d
+Ft(of)j(a)g(solution)g(de-)89 564 y(termines)17 b(ho)o(w)i(m)o(uc)o(h)e
+(e\013ort)j(is)f(needed)f(to)i(apply)f(the)g(solution)g(to)h(an)f(unmo)q
+(di\014ed)g(v)o(ersion)89 624 y(of)g(a)f(state{of{the{art)i(name)d(serv)o
+(er.)27 b(The)18 b Fh(complexit)o(y)d(of)k(its)f(implem)o(en)n(tation)e
+Ft(denotes)j(if)89 684 y(mo)q(di\014cations)h(in)g(di\013eren)o(t)f(areas)i
+(are)g(in)o(v)o(olv)o(ed)d(and)j(ho)o(w)f(complicated)e(their)i(in)o
+(teraction)89 744 y(is.)h(Solutions)16 b(migh)o(t)d(not)j(b)q(e)g(suitable)f
+(in)g(ev)o(ery)f(organizational)i(en)o(vironmen)o(t.)i(W)l(e)d(call)g(this)89
+804 y(criterion)i Fh(applicabilit)o(y)f(in)h(an)i(organization)p
+Ft(.)27 b(The)18 b Fh(transparency)g(of)g(the)g(solution)g
+Ft(in)o(v)o(olv)o(es)89 865 y(the)e(soft)o(w)o(are)g(in)o(terface)f(and)i
+(the)f(user)g(in)o(terface)f(to)h(the)g(system.)k(A)15 b(solution)i(that)g
+(do)q(es)g(not)89 925 y(require)e(c)o(hanges)i(to)g(the)g(DNS)f(proto)q(col)i
+(is)e(preferable)g(o)o(v)o(er)f(one)i(that)g(do)q(es.)23 b(User)16
+b(appro)o(v)m(al)89 985 y(of)h(an)o(y)h(mo)q(di\014cation)e(that)i(is)f(not)g
+(transparen)o(t)h(is)f(a)h(crucial)e(p)q(oin)o(t.)24 b(W)l(e)17
+b(com)o(bine)e(these)i(as-)89 1045 y(p)q(ects)g(in)g(the)g(term)e
+Fh(acceptabilit)o(y)g(b)o(y)i(the)g(user)p Ft(.)24 b(An)17
+b(imp)q(ortan)o(t)f(p)q(oin)o(t)h(in)g(the)g(in)o(tro)q(duction)89
+1105 y(of)22 b(c)o(hanges)g(to)g(systems)e(is)i(the)f Fh(transition)h(pro)q
+(cess)g Ft(from)f(the)g(original)h(state)g(\(b)q(efore)f(the)89
+1166 y(solution)c(is)f(applied\))f(to)i(the)f(new)g(state.)89
+1310 y Fg(3.2)70 b(The)22 b(Berk)n(eley)f(P)n(atc)n(h)89 1402
+y Ft(W)l(e)d(brie\015y)f(explained)h(the)g(Berk)o(eley)d(soft)o(w)o(are)k
+(patc)o(h)f(in)g(section)g(1)g(without)h(calling)e(it)h(the)89
+1462 y(Berk)o(eley)10 b(patc)o(h.)20 b(This)13 b(\014rst)g(attempted)f
+(defense,)g(dev)o(elop)q(ed)g(at)h(the)g(Univ)o(ersit)o(y)d(of)j(Berk)o(eley)
+l(,)89 1523 y(CA)h(,)f(consists)h(of)g(mo)q(di\014cations)g(of)g(the)f
+(r-command)f(daemons.)20 b(The)14 b(idea)g(is)g(to)g(v)m(alidate)f(the)89
+1583 y(in)o(v)o(erse)j(mapping)g(tree)h(b)o(y)f(lo)q(oking)i(at)g(the)f
+(corresp)q(onding)h(no)q(de)g(on)g(the)f(forw)o(ard)h(mapping)89
+1643 y(tree.)i(S.)c(Bello)o(vin)e(describ)q(es)i(the)g(metho)q(d)g(used)g(b)o
+(y)g(the)g(patc)o(h)g(in)g([Bel92)o(])g(as)h(follo)o(ws:)284
+1756 y(T)l(o)e(detect)e(this,)h(w)o(e)g(p)q(erform)f(a)h(cross{c)o(hec)o(k;)g
+(using)g(the)g(returned)g(name,)e(w)o(e)211 1816 y(do)17 b(a)h(forw)o(ard)f
+(c)o(hec)o(k)e(to)j(learn)e(the)h(legal)f(address)i(for)f(that)g(host.)24
+b(If)17 b(that)g(name)211 1876 y(is)f(not)g(listed,)f(or)h(if)g(the)f
+(addresses)i(do)g(not)f(matc)o(h,)e(alarms,)h(gongs,)i(and)g(to)q(csins)211
+1936 y(are)f(sounded.)162 2049 y(The)c(\014x)g(is)h(easily)e(installed)g(and)
+i(not)g(v)o(ery)e(complex.)18 b(Its)12 b(compatibilit)o(y)d(with)j(the)g
+(existing)89 2109 y(DNS)17 b(proto)q(col)h(is)e(another)i(adv)m(an)o(tage.)24
+b(The)17 b(transition)g(pro)q(cess)h(to)f(mo)o(v)o(e)e(to)i(services)f(that)
+89 2169 y(con)o(tain)i(the)g(patc)o(h)g(is)g(not)h(di\016cult,)e(but)h
+(requires)g(some)f(w)o(ork.)27 b(Although)19 b(w)o(e)e(regard)i(this)89
+2230 y(patc)o(h)h(as)h(an)g(obligatory)f(mo)q(di\014cation)g(to)h(daemons)e
+(lik)o(e)g Fi(rlo)n(gind)h Ft(and)h Fi(rshd)p Ft(,)f(it)g(is)g(limited)89
+2290 y(in)d(its)g(scop)q(e.)25 b(The)17 b(cac)o(he)g(of)g(a)h(running)g(name)
+e(serv)o(er)g(can)h(still)g(b)q(e)g(p)q(oisoned)h(b)o(y)f(supplying)89
+2350 y(additional)j(unrequested)f(records)g(as)h(the)g(exp)q(erimen)o(ts)d
+(describ)q(ed)i(in)g([Sc)o(h93,)h(section)f(3.5])89 2410 y(pro)o(v)o(e.)162
+2470 y(The)f(Berk)o(eley)d(patc)o(h)j(utilizes)e(a)i(principle)e(that)i(can)g
+(b)q(e)g(applied)f(outside)h(of)g(the)g(UNIX)89 2530 y(domain.)h(The)13
+b(idea)g(is)f(to)h(p)q(erform)f(a)h(cross-c)o(hec)o(k)f(of)h(the)g(\014rst)g
+(mapping)f(in)g(the)h(rev)o(erse)e(order.)89 2591 y(In)k(a)h(consisten)o(t)f
+(state,)h(forw)o(ard)g(and)g(bac)o(kw)o(ard)f(mapping)g(data)h(are)g(managed)
+f(b)o(y)g(the)g(same)977 2715 y(9)p eop
+%%Page: 10 10
+9 bop 89 82 a Ft(authorit)o(y)l(.)32 b(Th)o(us)20 b(tamp)q(ering)f(with)h
+(only)g(one)g(of)g(the)g(t)o(w)o(o)g(directions)f(of)h(mapping)g(can)g(b)q(e)
+89 142 y(detected.)162 203 y(The)d(patc)o(h)f(is)g(a)h(solution)g(if)f(trust)
+h(can)f(b)q(e)h(extended)f(only)g(within)g(the)g(scop)q(e)h(of)g(author-)89
+263 y(itativ)o(e)e(data,)j(and)f(if)f(the)h(attac)o(k)o(er)f(do)q(es)i(not)f
+(use)g(the)f(more)g(sophisticated)h(attac)o(k)f(metho)q(d.)89
+323 y(If)g(the)h(attac)o(k)o(er)f(supplies)h(the)g(additional)g(address)h
+(record)e(with)h(the)g(answ)o(er)g(to)h(the)e(rev)o(erse)89
+383 y(lo)q(okup,)h(it)f(means)f(that)i(he)g(con)o(trols)f(b)q(oth)h(lo)q
+(okup)h(directions,)d(and)i(that)g(trust)g(is)f(extended)89
+443 y(to)h(p)q(ossibly)f(un)o(trust)o(w)o(orth)o(y)g(sources.)89
+588 y Fg(3.3)70 b(Examining)22 b(Berk)n(eley)f Fs(r{Commands)89
+680 y Ft(In)16 b(this)f(paragraph)j(w)o(e)e(discuss)g(the)g(UNIX{sp)q
+(eci\014c)e(w)o(a)o(y)h(of)h(impleme)o(n)o(ting)d(a)j(T)l(rusted)h(Net-)89
+740 y(w)o(ork.)j(The)14 b(Berk)o(eley)c(r{commands)i(extensiv)o(ely)f(use)i
+(the)g Fi(.rhosts)g Ft(and)h Fi(/etc/hosts.e)n(quiv)g Ft(\014les)89
+800 y(to)j(increase)g(con)o(v)o(enien)o(t)d(net)o(w)o(ork)j(access.)23
+b(In)17 b(paragraph)i(2.3.2,)e(w)o(e)f(discussed)h(the)g(T)l(rusted)89
+861 y(Net)o(w)o(ork)e(concept.)22 b(R{commands)15 b(suc)o(h)h(as)h(remote)e
+(login)h(and)h(remote)e(shell)g(o\013er)i(the)g(p)q(os-)89
+921 y(sibilit)o(y)12 b(to)i(extend)f(trust)i(to)f(other)g(mac)o(hines.)k
+(Users)c(and)h(system)d(administrators)h(can)i(build)89 981
+y(individual)j(net)o(w)o(orks)g(of)i(trust.)30 b(This)19 b(pro)o(v)o(es)f
+(dangerous)j(in)e(some)f(cases.)29 b([GS91)q(,)19 b(c)o(hapter)89
+1041 y(11])e(discusses)f(securit)o(y)f(problems)g(with)h(the)g(UNIX)e(trust)j
+(mec)o(hanism)o(.)162 1101 y(The)e(existence)e(of)j(these)e(structures)h(of)h
+(trust)f(is)g(necessary)f(for)i(the)e(break{in)h(to)h(happ)q(en.)89
+1162 y(Ob)o(viously)l(,)23 b(the)g(break{in)h(is)f(prev)o(en)o(ted)e(if)i(w)o
+(e)g(prohibit)g(the)g(usage)h(of)f(trusted)g(hosts)i(or)89
+1222 y(trusted)e(users)h(completely)l(.)39 b(It)23 b(is)g(tec)o(hnically)e(p)
+q(ossible)i(to)h(disallo)o(w)f(the)g(usage)h(of)g Fh(trust)89
+1282 y Ft(in)19 b(Berk)o(eley)e(r{commands.)30 b(The)19 b(c)o(hoice)g(can)g
+(b)q(e)h(made)e(b)o(y)h(the)h(system)e(administrator)h(at)89
+1342 y(compile)10 b(time.)18 b(Ho)o(w)o(ev)o(er,)11 b(b)q(eing)i(able)f(to)h
+(access)g(other)g(mac)o(hines)d(without)j(passw)o(ords)i(mak)o(es)89
+1402 y(the)j(w)o(ork)h(in)f(a)h(net)o(w)o(orking)f(en)o(vironmen)o(t)e
+(easier.)28 b(Once)18 b(used)h(to)g(the)g(comfort,)e(not)i(man)o(y)89
+1463 y(users)h(agree)g(to)g(sacri\014ce)f(their)g(con)o(v)o(enience)f(for)i
+(the)f(prev)o(en)o(tion)g(of)h Fi(hyp)n(othetic)n(al)f Ft(securit)o(y)89
+1523 y(concerns.)32 b(The)20 b(trade{o\013)h(hereb)o(y)e(w)o(ould)h(con)o
+(tain)f(the)h(loss)g(of)g(con)o(v)o(enien)o(t,)e(and)j(in)e(man)o(y)89
+1583 y(cases,)13 b(necessary)g(to)q(ols)h(for)f(trouble)g(free)f(connection)h
+(to)g(hosts)h(that)g(are)f(accessed)f(frequen)o(tly)l(.)162
+1643 y(A)23 b(less)f(safe)h(solution)h(w)o(ould)e(b)q(e)i(to)f(limit)d(trust)
+j(to)g(lo)q(cally)g(administered)d(zones,)25 b(i.e.)89 1703
+y(authoritativ)o(e)20 b(zones,)h(where)g(the)f(Berk)o(eley)e(patc)o(h)j(w)o
+(orks)g(reliably)l(.)33 b(As)20 b(w)o(e)g(disco)o(v)o(ered)f(in)89
+1764 y(paragraph)h(3.2,)f(limiting)d(trust)j(to)g(certain)f(zones)h(\014xes)f
+(the)h(\015a)o(w.)28 b(An)19 b(organization)g(could)89 1824
+y(issue)g(the)g(p)q(olicy)g(that)h(only)f(lo)q(cal)g(trust)h(is)f(allo)o(w)o
+(ed.)30 b(In)19 b(some)g(organizations)h(this)f(can)h(b)q(e)89
+1884 y(considered)d(a)h(reasonable)g(approac)o(h)h(if)e(hardly)g(an)o(y)h
+(remote)e(accesses)h(that)i(are)e(directed)g(to)89 1944 y(hosts)j(in)g(the)f
+(lo)q(cal)h(zone)f(are)h(originated)f(outside)h(of)g(the)f(lo)q(cal)h(zone.)
+31 b(Additional)19 b(mec)o(ha-)89 2004 y(nisms)f(w)o(ould)g(b)q(e)h
+(necessary)g(to)g(enforce)f(the)h(p)q(olicy)l(,)f(suc)o(h)g(as)i(p)q(erio)q
+(dical)e(c)o(hec)o(ks)g(of)h Fi(.rhosts)89 2065 y Ft(or)g(a)g(mo)q(di\014ed)e
+(r{command)g(implem)o(en)n(tation)f(where)i(users)h(cannot)g(directly)e(mo)q
+(dify)g(their)89 2125 y(database)22 b(of)f(trusted)f(mac)o(hines,)g(but)g(ha)
+o(v)o(e)g(to)h(use)g(a)g(sp)q(ecial)f(program.)34 b(The)21
+b(trust)f(asso-)89 2185 y(ciations)f(m)o(ust)f(then)h(b)q(e)h(k)o(ept)e(in)h
+(a)h(protected)f(data)h(area)g(of)g(the)f(op)q(erating)h(system.)29
+b(This)89 2245 y(program)13 b(could)g(\014lter)g(out{of{zone)h(en)o(tries)e
+(at)i(the)f(time)e(the)i(user)g(w)o(an)o(ted)g(to)h(en)o(ter)e(them.)18
+b(It)89 2305 y(w)o(ould)d(also)h(con)o(tain)f(the)f(p)q(ossibilit)o(y)h(of)g
+(managing)g(setup)g(c)o(hanges)g(cen)o(trally)l(.)k(This)d(solution)89
+2365 y(actually)g(prop)q(oses)h(an)g(automatized)e(pro)q(cedure)h(to)h
+(implem)o(en)o(t)c(an)k(organization's)f(p)q(olicy)l(.)162
+2426 y(If)d(the)g(nature)h(of)f(connections)g(allo)o(ws)h(a)f(p)q(olicy)g
+(suc)o(h)g(as)h(describ)q(ed)f(ab)q(o)o(v)o(e,)g(impleme)o(n)o(ti)o(ng)89
+2486 y(it)k(is)g(a)h(ma)s(jor)e(e\013ort.)25 b(Some)16 b(system)g(scripts)h
+(ha)o(v)o(e)f(to)i(b)q(e)f(written)g(to)h(ensure)f(prop)q(er)h(usage,)89
+2546 y(op)q(erating)i(system)e(co)q(de)h(and)h(r{command)d(co)q(de)j(m)o(ust)
+e(b)q(e)h(mo)q(di\014ed,)f(and)i(a)g(new)f(user)g(in-)965 2715
+y(10)p eop
+%%Page: 11 11
+10 bop 89 82 a Ft(terface)17 b(has)h(to)h(b)q(e)f(dev)o(elop)q(ed.)24
+b(Users)18 b(ha)o(v)o(e)f(to)h(b)q(e)g(trained)f(on)h(ho)o(w)h(to)f(apply)f
+(the)h(c)o(hanged)89 142 y(facilit)o(y)13 b(and)i(ha)o(v)o(e)f(to)h(b)q(e)g
+(made)f(familiar)f(with)i(the)f(new)h(p)q(olicy)f(and)i(the)e(new)h(user)g
+(in)o(terface.)89 203 y(Adv)m(an)o(tages)k(of)h(this)f(new)g(approac)o(h)g
+(are)h(compatibilit)o(y)15 b(with)k(the)g(existing)f(DNS)h(proto)q(col)89
+263 y(and)e(additional)f(b)q(ene\014ts)h(in)f(further)f(securit)o(y)g
+(related)h(issues.)162 323 y(Although)i(w)o(e)g(concen)o(trate)f(on)i(the)f
+(Berk)o(eley)d(r{commands)i(in)h(this)g(paragraph,)i(w)o(e)d(do)89
+383 y(not)j(forget)f(that)h(there)f(are)g(other)g(w)o(a)o(ys)g(to)h(exploit)e
+(the)h(\015a)o(w.)31 b(F)l(or)19 b(example,)f(in)o(tercepting)89
+443 y(electronic)12 b(mail)h(is)g(a)i(target)f(of)h(attac)o(k)o(ers;)e(esp)q
+(ecially)g(electronic)f(mail)h(that)h(is)g(exc)o(hanged)f(b)o(y)89
+504 y(securit)o(y)i(agencies)i(and)h(securit)o(y)d(related)h(organizations.)
+25 b(Electronic)15 b(mail)h(dep)q(ends)h(on)g(the)89 564 y(DNS.)162
+624 y(The)c(Massac)o(h)o(usetts)h(Institute)e(of)i(T)l(ec)o(hnology)l(,)f
+(together)g(with)g(IBM)f(and)i(Digital)f(Equip-)89 684 y(men)o(t)18
+b(Corp)q(oration)k(dev)o(elop)q(ed)c(in)i(1983)h(Kerb)q(eros,)g(an)g(authen)o
+(tication)e(system)f(that)j(uses)89 744 y(Data)14 b(Encryption)f(Standard)i
+(\(see)e([NBS77)o(]\))g(cryptograph)o(y)g(to)h(transmit)e(sensitiv)o(e)g
+(informa-)89 804 y(tion)18 b(on)h(a)g(net)o(w)o(ork,)f(suc)o(h)g(as)h
+(clear-text)f(passw)o(ords.)29 b(Although)19 b(Kerb)q(eros)g(is)f(an)h
+(excellen)o(t)89 865 y(solution)e(to)g(sev)o(eral)e(di\016cult)h(problems,)f
+(it)h(has)h(shortcomings)f(that)i(limit)13 b(its)k(usefulness)f(in)89
+925 y(resp)q(ect)g(to)h(our)f(problem.)k(A)c(discussion)g(of)h(its)f
+(shortcomings)g(can)g(b)q(e)g(found)h(in)f([GS91)q(].)162 985
+y(Ov)o(erall,)c(a)h(v)o(ery)f(w)o(eak)h(p)q(oin)o(t)g(in)g(Berk)o(eley)d
+(deriv)o(ed)i(UNIX)f(systems)h(is)h(the)g(usage)h(of)f(trust.)89
+1045 y(This)18 b(pap)q(er)g(exploits)f(only)g(one)h(of)g(sev)o(eral)f(kno)o
+(wn)h(\015a)o(ws)g(based)g(up)q(on)h(trust.)26 b(Using)17 b(trust{)89
+1105 y(based)h(mec)o(hanism)o(s)c(requires)i(thinking)h(ab)q(out)h(a)g(c)o
+(hange)f(in)g(individual)e(p)q(olicies)i(in)f(dealing)89 1166
+y(with)g(gran)o(ting)h(trust)f(to)h(others.)k(W)l(e)16 b(can)h(conclude,)e(b)
+o(y)h(citing)f(S.)h(Bello)o(vin)e(\([Bel90)o(]\):)284 1267
+y(If)f(a)h(host)g(trusts)g(another)f(host)h(not)g(named)f(in)g(a)g(lo)q(cal)h
+(zone,)f(its)g(name)f(serv)o(er)211 1328 y(cannot)17 b(protect)f(it.)89
+1472 y Fg(3.4)70 b(Restricti)o(ng)21 b(Public)g(Information)i(Access)89
+1564 y Ft(What)13 b(mak)o(es)e(the)h(break{in)g(p)q(ossible)h(in)f(the)g
+(\014rst)h(place)f(is)g(gathering)h(necessary)f(information)89
+1624 y(ab)q(out)19 b(hostnames)e(of)h(trusting)g(mac)o(hines)d(and)k(user)e
+(names)g(on)h(di\013eren)o(t)e(systems)h(trusting)89 1685 y(eac)o(h)f(other.)
+162 1745 y(W)l(e)11 b(are)h(not)g(discussing)f(random)h(patterns)f(of)h
+(trust)g(that)g(migh)o(t)e(exist)g(b)q(et)o(w)o(een)h(hosts,)i(but)89
+1805 y(common)d(patterns)j(using)g(a)g(systematic)e(approac)o(h.)21
+b(In)12 b(a)h(cluster)f(of)h(time{sharing)e(mac)o(hines,)89
+1865 y(eac)o(h)18 b(mac)o(hine)f(is)i(lik)o(ely)d(to)j(extend)f(trust)h(to)g
+(all)g(its)f(p)q(eers.)29 b(This)19 b(pattern)g(is)g(not)g(common)89
+1925 y(to)24 b(the)f(general)g(user)h(p)q(opulation,)i(but)d(it)g(is)h
+(applicable)e(to)i(systems)e(programming)g(and)89 1986 y(op)q(erational)c
+(sta\013.)25 b(Another)17 b(t)o(ypical)f(pattern)i(is)f(the)g(o)q(ccurrence)f
+(of)i(\014le)f(serv)o(ers)f(that)i(trust)89 2046 y(their)10
+b(clien)o(ts,)g(who)i(serv)o(e)e(as)h(a)h(source)f(of)g(extra)g(CPU)g
+(cycles.)18 b(Dataless)12 b(clien)o(ts)d(will)h(frequen)o(tly)89
+2106 y(trust)i(administrativ)o(e)e(mac)o(hines)g(to)j(p)q(ermit)d(soft)o(w)o
+(are)i(main)o(tenance.)18 b(Some)11 b(systems)g(still)g(use)89
+2166 y(the)i(same)g Fi(/etc/hosts.e)n(quiv)i Ft(\014les)e(on)h(man)o(y)e
+(hosts)i(just)g(to)g(simplify)c(systems)j(administration.)162
+2226 y(Generally)23 b(accessable)h(programs)g(can)g(aid)h(in)e(disco)o(v)o
+(ering)g(the)h(desired)f(information:)89 2287 y(there)12 b(are)i(net)o(w)o
+(ork)e(monitoring)g(and)i(information)e(to)q(ols)i(\(suc)o(h)f(as)g
+Fi(snmptnetstat)p Ft(,)i Fi(tr)n(ac)n(er)n(oute)p Ft(,)89 2347
+y(or)j(the)g(DNS)g(itself)s(\),)g(user)g(information)f(services)g(\(suc)o(h)g
+(as)i Fi(\014nger)p Ft(\),)g(and)g(UNIX)d(services)h(in)89
+2407 y(general)i(\(suc)o(h)g(as)h Fi(ftp)p Ft(,)g Fi(smtp)p
+Ft(,)f(or)h Fi(rp)n(cinfo)p Ft(.\))30 b(Other)19 b(sources)h(of)f
+(information)g(migh)o(t)e(include)89 2467 y(published)k(material)e
+(describing)i(net)o(w)o(ork)g(top)q(ology)i(that)e(is)h(a)o(v)m(ailable)e
+(for)i(example)d(from)89 2527 y(some)c(academic)g(departmen)o(ts.)162
+2588 y(The)23 b(men)o(tioned)f(collection)f(of)j(to)q(ols)g(sho)o(ws)g(that)g
+(it)f(is)g(a)g(di\016cult)f(task)i(to)g(limit)c(in-)965 2715
+y(11)p eop
+%%Page: 12 12
+11 bop 89 82 a Ft(formation)22 b(access)h(without)h(sacri\014cing)f(the)f
+(legitimate)f(utilization)h(of)h(net)o(w)o(ork)g(services.)89
+142 y(Prev)o(en)o(ting)15 b(someone)h(from)f(gathering)i(information)f(is)g
+(nearly)g(imp)q(ossible.)k(T)l(o)q(o)e(man)o(y)d(ser-)89 203
+y(vices)j(rely)g(on)i(address)g(information,)e(and)i(w)o(e)e(conjecture)h
+(that)g(most)g(users)g(w)o(ould)g(not)h(b)q(e)89 263 y(happ)o(y)f(if)f(they)g
+(w)o(ere)g(depriv)o(ed)f(of)i(useful)f(to)q(ols)h(suc)o(h)g(as)g(electronic)e
+(mail)g(or)i(news)f(readers.)89 323 y(The)i(idea)f(of)h(op)q(en)h(systems)d
+(requires)h(op)q(en)i(access)e(to)i(information)d(services)h(and)h(address)89
+383 y(information.)29 b(Therefore,)19 b(most)f(system)g(administrators)h(ha)o
+(v)o(e)f(decided)g(that)i(the)f(b)q(ene\014ts)89 443 y(of)e(these)e
+(utilities)g(out)o(w)o(eigh)h(the)g(risks.)89 588 y Fg(3.5)70
+b(Adjusting)22 b(DNS)h(Up)r(date)g(In)n(terv)l(als)89 680 y
+Ft(Some)c(sites)h(ha)o(v)o(e)g(connections)g(c)o(hie\015y)f(with)h(mac)o
+(hines)e(outside)j(of)f(their)g(zones)g(that)h(sta)o(y)89 740
+y(stable)14 b(in)f(the)h(sense)f(that)h(hostname)g(to)g(IP)f(address)i
+(mapping)e(will)f(sta)o(y)i(the)g(same)e(for)i(a)h(long)89
+800 y(time.)24 b(The)18 b(idea)f(is)h(to)g(en)o(ter)f(long)h(time{to{liv)o(e)
+d(v)m(alues)j(in)o(to)f(the)h(resource)f(records,)h(v)m(alues)89
+861 y(that)13 b(exceed)f(the)h(curren)o(tly)e(impleme)o(n)o(ted)f(threshold)j
+(of)g(1)h(w)o(eek.)19 b(Limits)11 b(could)i(b)q(e)h(increased)89
+921 y(up)g(to)g(6,)h(12)f(mon)o(ths,)f(or)i(ev)o(en)e(longer,)h(dep)q(ending)
+g(on)g(the)g(situation.)20 b(If)14 b(this)g(data)g(is)g(en)o(tered)89
+981 y(with)20 b(great)h(care)g(to)g(ensure)f(correctness)g(of)h(the)g
+(mappings,)g(the)f(DNS)g(based)i(break{in)e(is)89 1041 y(prev)o(en)o(ted.)162
+1101 y(This)i(approac)o(h)g(is)f(limited)d(b)o(y)j(its)g(scop)q(e)h(of)f
+(applicabilit)o(y)l(,)f(but)i(it)f(is)g(a)h(solution)f(with)89
+1162 y(man)o(y)d(adv)m(an)o(tages.)32 b(It)18 b(go)q(es)j(with)e(the)g
+(curren)o(t)f(DNS)i(proto)q(col)g(and)g(can)f(b)q(e)h(implem)o(e)o(n)o(ted)89
+1222 y(without)f(m)o(uc)o(h)e(e\013ort)j(b)o(y)e(simply)f(c)o(hanging)j(the)e
+(constan)o(t)i(in)f(the)f(name)g(serv)o(er)g(co)q(de)i(that)89
+1282 y(determines)14 b(the)i(maxim)o(um)c(time{to{liv)o(e)i(for)j(cac)o(he)e
+(en)o(tries)h(and)h(recompiling)d(the)i(system.)89 1342 y(As)j(all)f
+(necessary)h(en)o(tries)f(are)h(k)o(ept)f(in)h(the)g(lo)q(cal)g(cac)o(he,)f
+(the)h(system)e(pro)o(vides)i(v)o(ery)f(quic)o(k)89 1402 y(replies)d(to)i
+(queries.)k(It)16 b(hardly)h(ev)o(er)e(uses)i(the)f(net)o(w)o(ork)g(and)h
+(therefore)f(sa)o(v)o(es)g(bandwidth)h(on)89 1463 y(the)f(medium)d(for)j
+(other)h(tasks.)162 1523 y(This)k(approac)o(h)h(has)f(the)g(problem)e(of)i(v)
+m(alidating)g(mappings)f(b)q(efore)h(they)f(are)h(cac)o(hed.)89
+1583 y(Ho)o(w)e(can)h(it)e(b)q(e)i(ensured)f(that)h(the)f(mappings)g(are)g
+(correct)g(in)f(the)i(\014rst)f(place?)30 b(Certainly)l(,)89
+1643 y(a)18 b(false)f(en)o(try)f(w)o(ould)i(sta)o(y)f(for)h(a)f(long)h(time,)
+d(and)j(the)f(attac)o(k)o(er's)g(address)h(w)o(ould)f(b)q(e)h(\014nally)89
+1703 y(noted.)23 b(But)17 b(do)q(es)h(that)f(really)f(help,)g(once)h(misc)o
+(hief)d(is)i(done?)25 b(It)16 b(migh)o(t)f(aid)i(in)g(prosecution)89
+1764 y(e\013orts,)f(but)h(only)f(little)e(in)i(prev)o(en)o(tion.)162
+1824 y(Extending)i(TTL)i(v)m(alues)e(to)h(a)g(long)g(p)q(erio)q(d)g(of)g
+(time)d(is)i(a)h(safe)g(and)g(feasible)f(metho)q(d)f(in)89
+1884 y(en)o(vironmen)o(ts)12 b(where)i(the)g(additional)g(condition)g(of)h
+(static)f(mappings)g(with)g(long)h(lifetimes)c(is)89 1944 y(giv)o(en.)22
+b(Ho)o(w)o(ev)o(er,)15 b(in)i(this)g(scenario)g(the)f(DNS)h(seems)f(not)h(to)
+h(b)q(e)f(the)f(righ)o(t)h(approac)o(h,)g(but)h(a)89 2004 y(lo)q(cally)d(w)o
+(ell{administered)f(static)i(mapping)f(mec)o(hanism.)162 2065
+y(One)21 b(of)g(the)g(original)g(reasons)h(to)g(in)o(tro)q(duce)e(the)h(DNS)g
+(w)o(as)h(to)f(manage)g(the)g(dynamic)89 2125 y(b)q(eha)o(vior)c(of)h(c)o
+(hanges)g(in)f(the)g(data)h(base.)25 b(This)18 b(approac)o(h)g(\014xes)f
+(mappings)g(for)h(a)f(long)h(time)89 2185 y(and)e(uses)g(a)g(p)q(o)o(w)o
+(erful)e(distributed)h(database)i(system)d(for)i(an)g(infrequen)o(tly)d(o)q
+(ccuring)i(up)q(date)89 2245 y(pro)q(cess.)33 b(Although)20
+b(w)o(e)f(are)h(not)g(talking)g(ab)q(out)h(a)f(static)g(mapping)f(in)h(this)f
+(paragraph,)k(a)89 2305 y(w)o(ell{main)o(tained)12 b Fi(HOSTS.TXT)k
+Ft(\014le)f(or)g(a)g(h)o(ybrid)g(approac)o(h)g(w)o(ould)g(ha)o(v)o(e)g(the)f
+(functionalit)o(y)89 2365 y(required)h(with)h(less)g(o)o(v)o(erhead.)162
+2426 y(It)23 b(could)h(b)q(e)f(suggested)i(to)f(abandon)h(the)e(DNS)h(and)g
+(either)f(return)g(to)h(the)f(previous)89 2486 y(system)c(with)i(a)g(static)g
+(host)g(table,)h(or)f(mo)o(v)o(e)e(on)i(to)g(another)h(system)d(that)i(has)h
+(y)o(et)e(to)h(b)q(e)89 2546 y(dev)o(elop)q(ed.)f(W)l(e)14
+b(are)g(not)h(going)h(to)f(discuss)f(p)q(ossible)h(future)f(dev)o(elopmen)o
+(t)e(of)i(the)h(DNS)f(here,)965 2715 y(12)p eop
+%%Page: 13 13
+12 bop 89 82 a Ft(but)16 b(returning)g(to)h(the)f(previous)g(system.)162
+142 y(In)c(this)f(approac)o(h,)i(mappings)f(can)g(c)o(hange)f(frequen)o(tly)l
+(,)g(but)h(c)o(hanges)g(ha)o(v)o(e)f(to)h(b)q(e)g(rep)q(orted)89
+203 y(to)21 b(a)g(cen)o(tral)f(authorit)o(y)g(that)h(manages)f(the)h(whole)f
+(DNS)h(space)g(in)f(con)o(trast)h(to)g(the)f(DNS)89 263 y(approac)o(h)k(of)f
+(managing)f(zones)h(through)h(delegated)e(lo)q(cal)h(authorities.)41
+b(This)23 b(w)o(ould)g(not)89 323 y(solv)o(e)17 b(the)g(problem,)e(b)q
+(ecause)j(the)f(problem)f(is)h(not)h(the)f(DNS,)g(but)h(inadequate)f(metho)q
+(ds)g(of)89 383 y(host)i(authen)o(tication.)28 b(IP)18 b(addresses)h(of)g
+(trusted)g(mac)o(hines)d(could)j(still)e(b)q(e)i(imitated.)26
+b(This)89 443 y(is)16 b(a)h(somewhat)f(harder)g(task,)g(but)h(the)f(tec)o
+(hniques)f(ha)o(v)o(e)g(b)q(een)h(kno)o(wn)h(for)g(quite)e(some)g(time)89
+504 y(\(see)h([Mor85]\).)162 564 y(W)l(ould)e(it)f(b)q(e)g(safer)h(to)f
+(transmit)g(up)q(dates)h(to)g(a)f(cen)o(tral)g(site?)20 b(Electronic)12
+b(mail,)g(telephone)89 624 y(calls,)h(or)h(con)o(v)o(en)o(tional)e(pap)q(er)h
+(are)h(not)g(necessarily)e(a)i(reliable)d(w)o(a)o(y)j(to)f(transmit)f
+(mapping)h(in-)89 684 y(formation)h(up)q(dates.)22 b(The)14
+b(long)h(time)e(dela)o(y)h(un)o(til)f(cen)o(trally)g(made)h(c)o(hanges)h(are)
+g(propagated)89 744 y(through)g(the)g(net)o(w)o(ork)e(w)o(ould)i(condemn)e
+(the)h(database)i(to)f(b)q(e)f(in)g(an)h(inheren)o(tly)e(inconsisten)o(t)89
+804 y(state.)22 b(The)17 b(system)e(w)o(ould)h(again)h(con)o(tain)g(all)e
+(the)i(disadv)m(an)o(tages)g(whic)o(h)f(w)o(ere)g(the)g(reasons)89
+865 y(for)g(dev)o(eloping)g(the)g(curren)o(t)f(DNS.)162 925
+y(But)d(b)q(esides)g(these)g(ob)o(vious,)h(tec)o(hnical,)e(and)i(w)o(ell{kno)
+o(wn)e(reasons,)j(there)e(is)g(a)g(signi\014can)o(t)89 985
+y(argumen)o(t)h(wh)o(y)g(no)h(one)g(can)g(p)q(ossibly)g(b)q(e)g(in)f(fa)o(v)o
+(or)g(of)h(reinstalling)f(the)g(previous)h(system:)k(the)89
+1045 y(sheer)h(size)f(of)h(the)g(In)o(ternet.)29 b Fi(HOSTS.TXT)20
+b Ft(w)o(as)g(abandoned)g(b)q(ecause)f(200,000)i(hosts)f(w)o(as)89
+1105 y(to)q(o)13 b(m)o(uc)o(h)d(to)i(b)q(e)h(managed.)19 b(Are)11
+b(curren)o(tly)g(o)o(v)o(er)g(2.2)h(million)e(\(see)h([Lot94)q(]\))h(easier)g
+(to)g(handle?)89 1166 y(Certainly)j(not.)162 1226 y(Abandoning)f(the)f(DNS)h
+(w)o(ould)f(drag)h(the)f(name)f(resolution)h(task)h(in)f(the)g(In)o(ternet)f
+(out)i(of)g(a)89 1286 y(functioning)f(state)h(with)f(a)h(not)g(easily)e
+(exploitable)g(securit)o(y)g(breac)o(h,)h(in)o(to)g(an)h(unmanageable,)89
+1346 y(not)k(w)o(orking)g(state)g(of)g(prehistoric)e(system)h(design.)25
+b(W)l(e)18 b(think)f(that)h(w)o(ould)f(do)i(more)d(harm)89
+1406 y(than)h(ignoring)f(the)g(problem.)89 1551 y Fg(3.6)70
+b(Hardening)23 b(Name)e(Serv)n(ers)89 1643 y Fe(3.6.1)55 b(Keeping)18
+b(Additional)g(Information)89 1736 y Ft(A)i(\014rst)g(idea)g(is)g(to)g
+(extensiv)o(ely)e(log)i(remote)e(login)j(attempts)e(with)h(all)f(asso)q
+(ciated)i(address)89 1796 y(and)g(name)d(information.)32 b(Or)19
+b(ev)o(en)g(more:)28 b(to)20 b(tag)h(cac)o(he)e(en)o(tries)g(with)g(their)h
+(origin.)32 b(The)89 1856 y(latter)19 b(is)g(an)i(easily)d(ac)o(hiev)o(ed)g
+(mo)q(di\014cation)h(that)h(costs)g(additional)g(memory)c(space)k(in)f(the)89
+1916 y(cac)o(he.)h(This)c(metho)q(d)f(mak)o(es)g(it)g(easier)g(to)h(trac)o(k)
+g(false)f(database)i(en)o(tries)e(for)h(the)g(purp)q(ose)h(of)89
+1976 y(debugging)g(wrong)g(zone)f(data)i(or)e(in)o(v)o(estigating)f(a)i(DNS)f
+(based)h(break{in.)89 2106 y Fe(3.6.2)55 b(Prev)n(en)n(tion)18
+b(of)h(Cac)n(he)h(P)n(oisoning)89 2199 y Ft(Prev)o(en)o(ting)14
+b(the)h(cac)o(he)f(from)h(con)o(tamination)f(is)h(not)h(feasible)e(from)g
+(within)h(the)g(name)f(serv)o(er)89 2259 y(co)q(de,)24 b(as)f(there)f(is)h
+(no)g(w)o(a)o(y)f(of)h(a)g(priori)f(determining)f(if)h(an)o(y)g(giv)o(en)g
+(additional)h(record)f(is)89 2319 y(trust)o(w)o(orth)o(y)14
+b(or)h(not.)21 b(W)l(e)14 b(could)g(start)h(treating)f(sp)q(ecial)g(cases)h
+(of)f(when)h(to)g(allo)o(w)f(or)g(disallo)o(w)89 2379 y(additional)i
+(information.)162 2439 y(The)h(default)g(safe)g(b)q(eha)o(vior)h(w)o(ould)f
+(b)q(e)g(to)h(disallo)o(w)e(the)h(cac)o(hing)g(of)g(unrequested)g(infor-)89
+2500 y(mation,)i(and)i(to)f(allo)o(w)g(it)f(only)h(in)f(cases)h(where)g(the)f
+(information)g(is)h(necessary)l(,)g(and)g(then)89 2560 y(only)c(for)h(the)f
+(curren)o(t)f(resolution.)965 2715 y(13)p eop
+%%Page: 14 14
+13 bop 89 82 a Fe(3.6.3)55 b(Con)n(text)19 b(Cac)n(he)89 175
+y Ft(There)11 b(are)h(other,)h(more)d(sophisticated)i(approac)o(hes)g(p)q
+(ossible:)20 b(if)11 b(some)g(additional)h(or)g(author-)89
+235 y(itativ)o(e)g(records)h(are)g(returned)g(together)g(with)g(a)h(resource)
+f(record,)g(they)f(could)h(b)q(e)h(in)o(terpreted)89 295 y(only)k(in)f(the)h
+(con)o(text)f(of)h(that)g(resource)g(record.)26 b(The)18 b(di\013erence)f(b)q
+(et)o(w)o(een)g(the)g(default)h(safe)89 355 y(b)q(eha)o(vior)13
+b(approac)o(h)h(and)g(this)f(one)g(is)g(that)h(in)f(the)g(former,)e(resource)
+i(records)h(are)f(only)g(cac)o(hed)89 415 y(when)k(they)f(w)o(ere)g
+(requested)g(or)h(necessary)g(additional)g(information,)e(whereas)i(in)g(the)
+f(latter)89 475 y(approac)o(h)g(the)f(new)g(en)o(tries)f(get)i(cac)o(hed,)e
+(but)h(can)h(b)q(e)f(retriev)o(ed)f(from)g(the)h(cac)o(he)f(only)h(in)g(the)
+89 536 y(same)k(con)o(text)h(in)g(whic)o(h)g(they)g(w)o(ere)g(en)o(tered.)33
+b(F)l(or)21 b(example,)e(an)i Ff(address)d Ft(record)i(in)g(the)89
+596 y(additional)f(section)g(of)g(a)g(resp)q(onse)h(to)g(a)f
+Ff(mail)24 b(exchange)16 b Ft(record)j(request)g(should)g(only)g(b)q(e)89
+656 y(used)c(for)h(deliv)o(ering)d(mail.)19 b(The)c(information)f(w)o(ould)h
+(not)g(b)q(e)g(acceptable)g(for)g(a)h(remote)d(login)89 716
+y(to)h(another)h(host,)g(or)g(generally)e(usable)h(for)g(other)h(services.)k
+(A)14 b(glue)g Ff(address)d Ft(record)j(coming)89 776 y(along)k(with)e(a)i
+Ff(name)24 b(server)15 b Ft(record)h(w)o(ould)h(only)g(b)q(e)g(used)g(for)g
+(follo)o(w{up)g(queries,)f(b)q(ecause)89 837 y(that)k(is)g(the)f(con)o(text)g
+(in)h(whic)o(h)f(it)g(w)o(as)h(supplied.)31 b Ff(Address)18
+b Ft(records)h(along)i(with)f Ff(pointer)89 897 y Ft(records)c(should)h(nev)o
+(er)d(b)q(e)j(cac)o(hed,)d(b)q(ecause)j(there)e(is)h(no)g(legal)g(con)o(text)
+f(in)h(whic)o(h)f(they)h(ha)o(v)o(e)89 957 y(to)h(b)q(e)f(returned)g(in)g(a)g
+(single)g(resp)q(onse.)162 1017 y(This)24 b(whole)f(approac)o(h)h(leads)f(to)
+h(the)f(question)g(of)h(whether)f(w)o(e)f(still)h(need)g(the)g(addi-)89
+1077 y(tional)18 b(section)f(at)i(all.)25 b(If)18 b(only)g(certain)f(com)o
+(binations)f(of)j(resource)e(records)h(are)g(allo)o(w)o(ed)f(as)89
+1138 y(a)22 b(resp)q(onse)g(to)g(a)g(query)l(,)f(wh)o(y)g(not)h(consequen)o
+(tly)e(eliminate)f(the)i(idea)g(of)h(additional,)h(un-)89 1198
+y(requested)17 b(information)g(completely)l(,)e(and)k(adapt)g(the)f(proto)q
+(col)h(to)g(accommo)q(date)d(the)i(new)89 1258 y(ideas,)e(namely)e(a)j
+(certain)e(limited)f(n)o(um)o(b)q(er)g(of)j(t)o(yp)q(es)f(of)g(asso)q
+(ciations?)162 1318 y(First)i(of)h(all,)g(that)g(w)o(ould)g(require)e(a)i
+(proto)q(col)h(c)o(hange,)f(whic)o(h)f(is)g(something)g(w)o(e)g(try)h(to)89
+1378 y(a)o(v)o(oid.)41 b(Some)21 b(of)i(the)g(original)g(design)g(goals)h(of)
+f(the)f(DNS)h(also)h(imply)c(that)k(elimi)o(nating)89 1439
+y(the)18 b(additional)h(section)f(w)o(ould)g(not)h(b)q(e)g(a)g(go)q(o)q(d)h
+(approac)o(h.)29 b(The)18 b(system)f(w)o(ould)i(lose)f(some)89
+1499 y(of)i(its)f(generalit)o(y)l(,)f(b)q(ecause)h(the)h(additional)f
+(section)g(migh)o(t)e(b)q(ecome)h(v)o(ery)g(useful)h(in)g(future)89
+1559 y(applications)e(of)g(the)f(DNS)h(without)g(con)o(taining)g(an)o(y)f
+(securit)o(y)g(threats.)23 b(The)17 b(system)e(w)o(ould)89
+1619 y(certainly)10 b(lose)i(e\016ciency)l(.)17 b(Here)10 b(w)o(e)h(see)h
+(again)g(an)g(imp)q(ortan)o(t)f(trade-o\013)h(that)g(w)o(e)f(ha)o(v)o(e)g
+(already)89 1679 y(men)o(tioned)e(in)i(previous)g(sections:)19
+b(an)12 b(increase)e(in)h(systems)f(securit)o(y)g(and)i(a)g(decline)d(in)i
+(system)89 1740 y(p)q(erformance)k(vs.)21 b(go)q(o)q(d)e(system)14
+b(p)q(erformance)h(and)i(a)g(p)q(ossible)f(lac)o(k)g(of)g(securit)o(y)l(.)162
+1800 y(It)k(is)f(therefore)h(justi\014able)f(to)h(tak)o(e)g(the)f(approac)o
+(h)i(of)f(hardening)g(the)g(name)f(serv)o(er)f(b)o(y)89 1860
+y(treating)j(more)f(sp)q(ecial)h(cases,)h(and)g(b)o(y)f(increasing)g(the)g
+(complexit)o(y)d(of)k(the)f(in)o(ternal)f(data)89 1920 y(bases,)k(instead)e
+(of)g(hardening)h(it)e(b)o(y)h(implem)o(en)o(t)o(ing)e(the)h(same)h(ideas)g
+(accepting)f(proto)q(col)89 1980 y(c)o(hanges.)89 2110 y Fe(3.6.4)55
+b(Authorit)n(y)19 b(Cac)n(he)89 2203 y Ft(A)c(further)g(approac)o(h)h(w)o
+(ould)g(b)q(e)f(to)h(cac)o(he)e(data)j(only)e(if)g(the)g(source)g(of)h(a)g
+(record)f(is)g(kno)o(wn)h(to)89 2263 y(b)q(e)i(authoritativ)o(e)f(for)h(that)
+g(zone.)25 b(W)l(e)18 b(giv)o(e)e(an)i(example)e(for)i(that:)24
+b(If)17 b(a)h(name)f(serv)o(er)f Ff(ara-)89 2323 y(gorn.defen)o(d.d)o(om)8
+b Ft(receiv)o(es)i(a)i Ff(pointer)e Ft(record)h(from)g(some)g(host)i
+Ff(caradhras)o(.at)o(tac)o(k.d)o(om)o Ft(,)89 2383 y(and)j(the)f(DNS)g
+(message)g(also)h(con)o(tains)f(an)h Ff(address)d Ft(record)i(in)g(its)g
+(additional)g(section,)g(then)89 2443 y(the)h(name)g(serv)o(er)f
+Ff(aragorn)f Ft(w)o(ould)j(b)q(eliev)o(e)d(and)j(cac)o(he)f(this)g
+(information)g(only)g(if)g(it)g(already)89 2503 y(kno)o(ws)e(that)g(the)f
+(source)h(name)e(serv)o(er)h Ff(caradhras)d Ft(is)k(authoritativ)o(e)f(for)g
+(the)h(according)g(zone.)89 2564 y(A)g(name)e(serv)o(er)h(follo)o(wing)h
+(this)g(strategy)g(w)o(ould)g(create)g(its)g(o)o(wn)g(tree)f(of)i
+(authoritativ)o(e)e(name)965 2715 y(14)p eop
+%%Page: 15 15
+14 bop 89 82 a Ft(serv)o(ers.)39 b(This)23 b(tree)f(w)o(ould)g(ha)o(v)o(e)g
+(to)h(lose)f(subtrees)h(according)f(to)h(the)f(expiration)g(of)h(the)89
+142 y(lifetime)13 b(of)j(some)g(no)q(de)g(\(name)f(serv)o(er\).)162
+203 y(This)20 b(approac)o(h)g(ho)o(w)o(ev)o(er)e(has)i(a)g(serious)g(\015a)o
+(w)g(in)f(it.)30 b(Serv)o(ers)19 b(determine)e(if)i(DNS)g(mes-)89
+263 y(sages)g(are)f(gen)o(uine)f(b)o(y)h(c)o(hec)o(king)e(a)i(certain)f
+(\015ag)i(in)f(the)g(header)f(of)i(the)e(DNS)h(message:)24
+b(the)89 323 y Ff(authoritat)o(ive)e(answer)11 b Ft(bit.)20
+b(This)14 b(\015ag)g(is)f(only)g(v)m(alid)h(in)f(resp)q(onses)h(and)g(sp)q
+(eci\014es)f(that)h(the)89 383 y(resp)q(onding)20 b(name)f(serv)o(er)f(is)i
+(an)g(authorit)o(y)f(for)h(the)f(domain)g(name)f(in)h(question.)31
+b(Nothing)89 443 y(prev)o(en)o(ts)11 b(an)o(y)i(attac)o(k)o(er)e(who)j
+(supplies)e(sp)q(eci\014cally)f(man)o(ufactured)g(pac)o(k)o(ets)h(in)g(the)h
+(\014rst)g(place)89 504 y(from)i(setting)h(this)g(bit)g(regardless)h(of)f
+(its)g(v)m(alidit)o(y)l(.)89 633 y Fe(3.6.5)55 b(Conditional)19
+b(Cac)n(he)g(Use)89 726 y Ft(The)d(Berk)o(eley)d(patc)o(h)j(\(see)g
+(paragraph)i(3.2\))e(can)g(fail)f(in)h(the)g(case)g(that)g(the)g(cac)o(he)f
+(is)h(already)89 786 y(p)q(oisoned.)29 b(An)19 b(idea)f(to)h(strengthen)g
+(the)g(Berk)o(eley)d(patc)o(h)i(is)h(to)g(pro)o(vide)e(the)i(p)q(ossibilit)o
+(y)f(to)89 846 y(resolv)o(e)e(queries)h(without)h(using)g(the)f(cac)o(he.)25
+b(That)18 b(could)g(b)q(e)f(used)h(b)o(y)f(the)h(Berk)o(eley)d(patc)o(h.)89
+906 y(The)f(system)e(call)h(executing)f(the)h(forw)o(ard)i(lo)q(okup)f(w)o
+(ould)g(for)f(example)f(set)h(a)h(\015ag)h(to)f(indicate)89
+967 y(that)h(the)g(cac)o(he)g(con)o(ten)o(ts)f(should)i(not)f(b)q(e)h(used)f
+(for)g(the)g(follo)o(wing)g(resolution.)21 b(This)15 b(metho)q(d)89
+1027 y(again)20 b(decreases)f(the)g(e\016ciency)e(of)j(the)f(system,)f(but)h
+(it)g(prev)o(en)o(ts)f(the)h(exploitation)g(of)g(the)89 1087
+y(w)o(eakness.)h(One)12 b(could)h(also)g(think)g(of)g(a)g(system)e(call)h(to)
+h(\015ush)g(the)g(cac)o(he)f(follo)o(w)o(ed)g(b)o(y)g(a)h(reload)89
+1147 y(of)j(the)g(database,)h(similar)d(to)i(the)g(signal)g(SIGHUP)f(that)i
+(a)f(system)f(administrator)g(can)h(send)89 1207 y(to)h(the)f(BIND)f(implem)o
+(en)n(tation)f(of)j(the)f(name)f(serv)o(er)g(to)h(ac)o(hiev)o(e)f(the)h
+(same.)89 1337 y Fe(3.6.6)55 b(Discussion)89 1430 y Ft(A)18
+b(v)o(ery)f(thorough)j(analysis)f(of)g(the)f(proto)q(col)h(is)g(needed)f(to)h
+(determine)c(the)k(cases)f(in)h(whic)o(h)89 1490 y(additional)g(resource)f
+(records)g(are)h(legal)f(and)h(cannot)g(do)g(an)o(y)g(harm,)e(or)i(ha)o(v)o
+(e)f(to)h(b)q(e)g(stored)89 1550 y(in)d(di\013eren)o(t)f(con)o(texts.)162
+1610 y(One)20 b(of)h(the)g(design)f(goals)i(of)f(the)f(DNS)g(is)h(hereb)o(y)e
+(in)h(danger:)31 b(generalit)o(y)l(.)h(The)21 b(DNS)89 1670
+y(should)14 b(not)h(con)o(tain)e(an)o(y)h(unnecessary)g(restrictions)f
+(regarding)h(its)g(purp)q(ose)g(or)g(applications.)89 1731
+y(If)g(the)f(impleme)o(n)o(tor)e(of)k(the)f(DNS)g(w)o(ere)f(to)i(decide)d
+(whic)o(h)i(com)o(binations)f(of)h(resource)g(records)89 1791
+y(w)o(ould)i(b)q(e)h(allo)o(w)o(ed,)d(the)i(DNS)h(migh)o(t)d(b)q(e)i
+(constrained)h(in)f(a)g(w)o(a)o(y)g(that)h(it)e(is)h(no)h(longer)f(useful)89
+1851 y(for)h(certain)e(applications.)22 b(A)16 b(decline)f(in)h(system)f(p)q
+(erformance)g(w)o(ould)i(result)f(from)f(the)h(fact)89 1911
+y(that)g(name)f(serv)o(ers)g(w)o(ould)i(b)q(eliev)o(e)d(and)i(therefore)g
+(cac)o(he)f(less)g(data)i(|)f(data)h(that)g(migh)o(t)d(b)q(e)89
+1971 y(needed)i(later.)162 2031 y(Hardening)h(name)e(serv)o(ers)i(consists)g
+(of)g(sev)o(eral)f(p)q(ossible)h(mo)q(di\014cations,)f(some)g(of)h(whic)o(h)
+89 2092 y(seem)i(promising,)i(ev)o(en)f(though)i(their)e(application)h
+(decreases)f(the)h(system's)e(p)q(erformance)89 2152 y(and)e(increases)f(its)
+g(complexit)o(y)-5 b(.)89 2296 y Fg(3.7)70 b(Cryptographic)23
+b(Metho)r(ds)g(for)h(Authen)n(tication)89 2389 y Ft(In)19 b(this)g(paragraph)
+i(w)o(e)e(describ)q(e)g(the)g(arc)o(hitecture)e(of)j(an)g(authen)o(tication)f
+(system)f(em)o(b)q(ed-)89 2449 y(ded)f(in)o(to)f(the)h(DNS.)f(Note)g(that)i
+(the)e(algorithms)g(and)i(metho)q(ds)e(describ)q(ed)g(in)h(the)f(follo)o
+(wing)89 2509 y(paragraphs)g(yield)d(as)i(m)o(uc)o(h)d(securit)o(y)h(as)i(p)q
+(ossible.)21 b(Ho)o(w)o(ev)o(er)12 b(they)i(are)g(not)h(p)q(erfect.)20
+b(Most)15 b(of)89 2569 y(the)j(algorithms)f(rely)g(at)i(some)e(p)q(oin)o(t)h
+(on)h(conjectures)e(in)h(n)o(um)o(b)q(er)e(theory)i(that)h(are)f(neither)965
+2715 y(15)p eop
+%%Page: 16 16
+15 bop 89 82 a Ft(pro)o(v)o(en)16 b(nor)h(con)o(tradicted,)e(or)i(on)h(the)e
+(fact)g(that)h(brute)g(force)f(attac)o(ks)h(are)f(computationally)89
+142 y(infeasible.)k(F)l(or)c(a)h(discussion)f(of)h(this)f(see)g([Den82].)162
+203 y(W)l(e)j(ha)o(v)o(e)f(to)i(meet)d(the)h(requiremen)o(ts)e(of)k(data)g
+(in)o(tegrit)o(y)d(of)i(the)g(message)f(and)i(of)f(orig-)89
+263 y(inator)g(authen)o(tication.)27 b(In)18 b(the)g(follo)o(wing)g(w)o(e)g
+(will)f(elab)q(orate)i(on)g(these)f(t)o(w)o(o)g(requiremen)o(ts)89
+323 y(and)g(presen)o(t)e(tec)o(hniques)f(for)j(their)e(p)q(ossible)h(implem)o
+(en)o(tation.)j(The)d(algorithms)g(and)g(cryp-)89 383 y(tosystems)c(that)i(w)
+o(e)f(c)o(hose)g(are)g(t)o(ypical)f(represen)o(tativ)o(es)f(of)j(the)f(class)
+g(of)h(algorithms)e(that)i(are)89 443 y(applicable.)20 b(They)c(are)h(b)o(y)e
+(far)i(not)g(the)f(only)g(p)q(ossible)g(c)o(hoice.)89 573 y
+Fe(3.7.1)55 b(Data)19 b(In)n(tegrit)n(y)89 666 y Ft(Data)f(in)o(tegrit)o(y)d
+(in)i(a)h(comm)o(uni)o(cation)c(system)i(prev)o(en)o(ts)g(against)i(activ)o
+(e)e(wiretapping,)h(that)89 726 y(means)10 b(a)i(recipien)o(t)d(is)i(pro)o
+(vided)f(with)h(the)g(assurance)h(that)g(the)f(con)o(ten)o(t)f(of)h(a)h
+(receiv)o(ed)d(message)89 786 y(is)16 b(iden)o(tical)e(to)j(the)f(con)o(ten)o
+(t)g(of)g(the)g(message)g(sen)o(t)f(b)o(y)h(its)g(originator.)162
+846 y(W)l(e)h(w)o(an)o(t)g(to)g(ensure)g(the)g(in)o(tegrit)o(y)e(of)i
+(transmitted)f(DNS)h(messages)f(along)i(with)f(a)g(time)89
+906 y(stamp)i(to)h(protect)f(against)h(repla)o(y)f(attac)o(ks.)31
+b(W)l(e)19 b(concen)o(trate)f(on)i(a)g(certain)f(tec)o(hnique)f(to)89
+967 y(detect)d(unauthorized)i(message)e(alteration)h(that)h(is)f(e\016cien)o
+(t)e(and)j(considerably)f(secure.)162 1027 y(In)k(case)g(of)g(alteration)g
+(detection,)f(reco)o(v)o(ery)f(actions)j(could)e(b)q(e)h(to)h(ignore)f(the)f
+(receiv)o(ed)89 1087 y(DNS)k(message)g(and)h(issue)f(an)h(additional)g(query)
+l(.)42 b(Our)23 b(approac)o(h)i(is)e(based)h(on)g(message)89
+1147 y(digest)19 b(algorithms.)28 b(Message)19 b(digests,)h(or)f(synon)o
+(ymously)e(\014ngerprin)o(ts)i(or)g(signatures,)h(are)89 1207
+y(the)d(result)g(of)h(the)f(application)g(of)g(a)h(one-w)o(a)o(y)g(hash)g
+(functions)f(that)h(computes)e(a)i(c)o(hec)o(ksum)89 1267 y(of)f(its)f(input)
+g(data.)162 1328 y(MD5)k(and)f(the)g(Snefru)g(algorithm)g(are)g(examples)e
+(for)i(message)g(digest)g(algorithms)f(\(see)89 1388 y([Riv92)o(,)c
+(Mer89].\))20 b(Message)14 b(digest)f(algorithms)g(are)h(easy)g(to)g
+(compute,)e(are)i(only)f(a)h(few)g(b)o(ytes)89 1448 y(p)q(er)h(message,)f
+(are)h(computationally)e(hard)j(to)f(in)o(v)o(ert,)e(and)j(usually)e(require)
+g(a)h(certain)g(size)f(of)89 1508 y(input)i(data.)162 1568
+y(An)g(originator)h(w)o(ould)g(calculate)e(the)h(message)g(digest)g(of)h(a)g
+(DNS)f(message)f(immediatel)o(y)89 1629 y(b)q(efore)f(it)g(is)g(sen)o(t)g
+(out.)21 b(The)15 b(recipien)o(t)d(w)o(ould)i(recalculate)f(the)h(message)g
+(digest)g(and)h(compare)89 1689 y(the)h(resulting)g(v)m(alue)g(with)g(the)g
+(one)g(calculated)g(b)o(y)f(the)h(originator.)22 b(In)16 b(case)g(of)h(a)g
+(mismatc)n(h,)89 1749 y(the)k(receiv)o(er)e(w)o(ould)j(conclude)e(that)i(he)f
+(receiv)o(ed)f(a)h(mo)q(di\014ed)g(DNS)g(message.)36 b(He)21
+b(w)o(ould)89 1809 y(discard)16 b(it.)162 1869 y(But)i(ho)o(w)h(do)q(es)f
+(the)g(message)g(digest)g(calculated)f(b)o(y)h(the)g(originator)h(reac)o(h)e
+(the)h(receiv)o(er)89 1930 y(without)h(mo)q(di\014cation?)29
+b(The)19 b(message)f(digest)g(algorithms)g(are)h(publicly)e(kno)o(wn)i(and)h
+(an)o(y-)89 1990 y(one)k(tamp)q(ering)e(with)i(a)g(message)e(could)i(easily)e
+(mo)q(dify)h(the)g(asso)q(ciated)h(message)f(digest)89 2050
+y(accordingly)l(.)i(T)l(o)18 b(sho)o(w)g(ho)o(w)g(this)g(can)g(b)q(e)f(prev)o
+(en)o(ted)f(w)o(e)i(discuss)f(a)i(metho)q(d)d(for)i(originator)89
+2110 y(authen)o(tication)f(in)g(the)g(follo)o(wing)g(paragraph.)27
+b(Message)18 b(digests)f(together)h(with)f(originator)89 2170
+y(authen)o(tication)12 b(giv)o(e)f(a)h(v)o(ery)f(strong)i(guaran)o(tee)f(for)
+g(the)g(detectabilit)o(y)d(of)k(activ)o(e)d(wiretapping.)89
+2300 y Fe(3.7.2)55 b(Originator)18 b(Authen)n(tication)162
+2393 y Ft(Originator)c(authen)o(tication)f(p)q(ermits)f(the)i(recipien)o(t)d
+(of)j(a)g(message)f(to)h(reliably)f(determine)89 2453 y(if)j(the)g
+(originator)h(of)f(a)h(message)e(is)h(who)h(he)f(claims)f(to)h(b)q(e.)162
+2513 y(W)l(e)d(explain)f(brie\015y)g(a)h(pro)q(cedure)g(that)h(guaran)o(tees)
+f(the)g(originator's)h(authen)o(ticit)o(y)l(.)k(In)12 b(an)89
+2573 y(asymmetric)c(cryptosystem)i(a)i(pair)f(of)h(distinct)f(but)h
+(mathematical)o(ly)c(related)j(k)o(eys)g(is)g(used)h(for)965
+2715 y(16)p eop
+%%Page: 17 17
+16 bop 241 899 a @beginspecial 0 @llx 0 @lly 359 @urx 206 @ury
+3590 @rwi @setspecial
+%%BeginDocument: dig_sig_val.eps
+/$F2psDict 200 dict def 
+$F2psDict begin
+$F2psDict /mtrx matrix put
+/l {lineto} bind def
+/m {moveto} bind def
+/s {stroke} bind def
+/n {newpath} bind def
+/gs {gsave} bind def
+/gr {grestore} bind def
+/clp {closepath} bind def
+/graycol {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
+4 -2 roll mul setrgbcolor} bind def
+/col-1 {} def
+/col0 {0 0 0 setrgbcolor} bind def
+/col1 {0 0 1 setrgbcolor} bind def
+/col2 {0 1 0 setrgbcolor} bind def
+/col3 {0 1 1 setrgbcolor} bind def
+/col4 {1 0 0 setrgbcolor} bind def
+/col5 {1 0 1 setrgbcolor} bind def
+/col6 {1 1 0 setrgbcolor} bind def
+/col7 {1 1 1 setrgbcolor} bind def
+	end
+/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
+/$F2psEnd {$F2psEnteredState restore end} def
+
+$F2psBegin
+0 setlinecap 0 setlinejoin
+-4.0 211.0 translate 0.900 -0.900 scale
+1.000 setlinewidth
+n 319 39 m 319 59 l gs col-1 s gr
+n 321.000 51.000 m 319.000 59.000 l 317.000 51.000 l gs 2 setlinejoin col-1 s gr
+n 319 79 m 319 99 l gs col-1 s gr
+n 321.000 91.000 m 319.000 99.000 l 317.000 91.000 l gs 2 setlinejoin col-1 s gr
+n 319 179 m 319 159 l gs col-1 s gr
+n 317.000 167.000 m 319.000 159.000 l 321.000 167.000 l gs 2 setlinejoin col-1 s gr
+n 319 219 m 319 199 l gs col-1 s gr
+n 317.000 207.000 m 319.000 199.000 l 321.000 207.000 l gs 2 setlinejoin col-1 s gr
+n 79 39 m 79 59 l gs col-1 s gr
+n 81.000 51.000 m 79.000 59.000 l 77.000 51.000 l gs 2 setlinejoin col-1 s gr
+n 79 79 m 79 99 l gs col-1 s gr
+n 81.000 91.000 m 79.000 99.000 l 77.000 91.000 l gs 2 setlinejoin col-1 s gr
+n 79 119 m 79 179 l gs col-1 s gr
+n 81.000 171.000 m 79.000 179.000 l 77.000 171.000 l gs 2 setlinejoin col-1 s gr
+n 79 199 m 79 219 l gs col-1 s gr
+n 81.000 211.000 m 79.000 219.000 l 77.000 211.000 l gs 2 setlinejoin col-1 s gr
+n 279 19 m 359 19 l gs col-1 s gr
+n 39 19 m 119 19 l gs col-1 s gr
+0.500 setlinewidth
+n 21 179 m 14 179 14 192 7 arcto 4 {pop} repeat 14 199 137 199 7 arcto 4 {pop} repeat 144 199 144 186 7 arcto 4 {pop} repeat 144 179 21 179 7 arcto 4 {pop} repeat clp gs col-1 s gr
+n 108 154 m 98 179 l gs col-1 s gr
+n 102.828 172.315 m 98.000 179.000 l 99.114 170.829 l gs 2 setlinejoin col-1 s gr
+n 274 154 m 284 179 l gs col-1 s gr
+n 282.886 170.829 m 284.000 179.000 l 279.172 172.315 l gs 2 setlinejoin col-1 s gr
+n 261 179 m 254 179 254 192 7 arcto 4 {pop} repeat 254 199 377 199 7 arcto 4 {pop} repeat 384 199 384 186 7 arcto 4 {pop} repeat 384 179 261 179 7 arcto 4 {pop} repeat clp gs col-1 s gr
+	[4.000000] 0 setdash
+n 164 229 m 234 229 l gs col-1 s gr
+	[] 0 setdash
+n 226.000 227.000 m 234.000 229.000 l 226.000 231.000 l gs 2 setlinejoin col-1 s gr
+	[4.000000] 0 setdash
+n 164 29 m 234 29 l gs col-1 s gr
+	[] 0 setdash
+n 226.000 27.000 m 234.000 29.000 l 226.000 31.000 l gs 2 setlinejoin col-1 s gr
+n 11 59 m 4 59 4 72 7 arcto 4 {pop} repeat 4 79 147 79 7 arcto 4 {pop} repeat 154 79 154 66 7 arcto 4 {pop} repeat 154 59 11 59 7 arcto 4 {pop} repeat clp gs col-1 s gr
+n 251 59 m 244 59 244 72 7 arcto 4 {pop} repeat 244 79 387 79 7 arcto 4 {pop} repeat 394 79 394 66 7 arcto 4 {pop} repeat 394 59 251 59 7 arcto 4 {pop} repeat clp gs col-1 s gr
+/Times-Bold findfont 12.00 scalefont setfont
+59 14 m 
+gs 1 -1 scale (Sender:) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+294 14 m 
+gs 1 -1 scale (Receiver:) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+294 154 m 
+gs 1 -1 scale (hash value) col-1 show gr
+/Times-Bold findfont 24.00 scalefont setfont
+309 139 m 
+gs 1 -1 scale (=?) col-1 show gr
+/Times-BoldItalic findfont 12.00 scalefont setfont
+359 154 m 
+gs 1 -1 scale (s'') col-1 show gr
+/Times-BoldItalic findfont 12.00 scalefont setfont
+119 159 m 
+gs 1 -1 scale (K) col-1 show gr
+/Times-BoldItalic findfont 12.00 scalefont setfont
+129 164 m 
+gs 1 -1 scale (priv) col-1 show gr
+/Times-BoldItalic findfont 12.00 scalefont setfont
+239 159 m 
+gs 1 -1 scale (K) col-1 show gr
+/Times-BoldItalic findfont 12.00 scalefont setfont
+249 164 m 
+gs 1 -1 scale (pub) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+19 194 m 
+gs 1 -1 scale (asymmetric encryption) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+259 194 m 
+gs 1 -1 scale (asymmetric decryption) col-1 show gr
+/Times-BoldItalic findfont 12.00 scalefont setfont
+194 219 m 
+gs 1 -1 scale (s') col-1 show gr
+/Times-BoldItalic findfont 12.00 scalefont setfont
+194 19 m 
+gs 1 -1 scale (m) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+54 34 m 
+gs 1 -1 scale (message) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+274 34 m 
+gs 1 -1 scale (received message) col-1 show gr
+/Times-BoldItalic findfont 12.00 scalefont setfont
+109 34 m 
+gs 1 -1 scale (m) col-1 show gr
+/Times-BoldItalic findfont 12.00 scalefont setfont
+394 234 m 
+gs 1 -1 scale (s') col-1 show gr
+/Times-BoldItalic findfont 12.00 scalefont setfont
+379 34 m 
+gs 1 -1 scale (m) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+4 234 m 
+gs 1 -1 scale (encrypted message digest) col-1 show gr
+/Times-BoldItalic findfont 12.00 scalefont setfont
+149 234 m 
+gs 1 -1 scale (s') col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+249 234 m 
+gs 1 -1 scale (received encrypted digest) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+39 114 m 
+gs 1 -1 scale (message digest) col-1 show gr
+/Times-BoldItalic findfont 12.00 scalefont setfont
+129 114 m 
+gs 1 -1 scale (s) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+279 114 m 
+gs 1 -1 scale (message digest) col-1 show gr
+/Times-BoldItalic findfont 12.00 scalefont setfont
+369 114 m 
+gs 1 -1 scale (s) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+14 74 m 
+gs 1 -1 scale (message digest algorithm) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+254 74 m 
+gs 1 -1 scale (message digest algorithm) col-1 show gr
+$F2psEnd
+%%EndDocument
+ @endspecial 424 1055 a Ft(Figure)16 b(2:)21 b(Digital)16 b(signature)h
+(generation)f(and)h(v)m(alidation)89 1189 y(encryption)11 b(and)i
+(decryption.)19 b(One)11 b(k)o(ey)g(is)h(priv)m(ate)f(and)i(k)o(ept)e(secret)
+g(b)o(y)g(the)h(sender,)g(the)g(other)89 1249 y(one)k(is)h(publicly)d(kno)o
+(wn.)22 b(Data)17 b(encrypted)e(with)h(a)h(sender's)f(priv)m(ate)g(k)o(ey)f
+(can)i(b)q(e)f(decrypted)89 1309 y(using)j(his)g(public)g(k)o(ey)l(,)f(and)h
+(vice)f(v)o(ersa.)30 b(These)19 b(k)o(eys)f(are)h(usually)g(large)g(in)o
+(teger)f(n)o(um)o(b)q(ers,)89 1369 y(sev)o(eral)h(h)o(undred)h(decimal)d
+(digits)j(long)h(with)e(sp)q(ecial,)h(mathematical)d(prop)q(erties.)33
+b Fh(P)o(ohlig-)89 1430 y(Hellman)14 b Ft(and)j Fh(RSA)e Ft(are)i(examples)d
+(of)i(asymmetric)d(cryptosystems)i(\(see)h([PH78,)g(RSA78]\).)162
+1490 y(Figure)i(2)g(depicts)f(digital)h(signature)g(generation)g(and)h(v)m
+(alidation;)f(a)h(more)d(detailed)h(ex-)89 1550 y(planation)j(can)g(b)q(e)g
+(found)g(in)f([Sc)o(h94,)h(section)f(17.6].)32 b(The)20 b(sender)f(digitally)
+g(signs)h(data)g Fd(m)89 1610 y Ft(b)o(y)g(encrypting)g(the)h(hash)g(v)m
+(alue)f Fd(s)h Ft(of)g(the)g(data)g(using)g(his)g(priv)m(ate)f(k)o(ey)g(comp)
+q(onen)o(t)f Fd(K)1821 1617 y Fc(pr)q(iv)89 1670 y Ft(and)e(sends)h(\(E)368
+1677 y Fc(K)398 1682 y Fb(pr)q(iv)460 1670 y Ft(\()p Fd(s)p
+Ft(\),)p Fd(m)p Ft(\).)k(The)17 b(receiv)o(er)e(v)m(alidates)h(the)h(data)h
+(in)e(a)h(three)f(step)h(pro)q(cess.)24 b(He)89 1731 y(computes)14
+b(the)h(hash)h(v)m(alue)f Fd(s)g Ft(of)h(the)f(data)h Fd(m)p
+Ft(,)f(decrypts)g(the)g(hash)h Fd(s)1399 1713 y Fa(0)1426 1731
+y Ft(that)f(arriv)o(ed)g(using)g(the)89 1791 y(signer's)h(public)f(k)o(ey)g
+Fd(K)538 1798 y Fc(pub)610 1791 y Ft(and)i(compares)f(the)g(results)g(D)1196
+1798 y Fc(K)1226 1804 y Fb(pub)1278 1791 y Ft(\()p Fd(s)1320
+1773 y Fa(0)1331 1791 y Ft(\))h(and)f Fd(s)p Ft(.)162 1851
+y(Wh)o(y)21 b(do)g(w)o(e)f(calculate)g(a)i(message)e(digest)g(at)i(all)e(and)
+i(not)f(simply)e(encrypt)h(and)h(then)89 1911 y(transmit)h(the)i(whole)f
+(message?)43 b(The)23 b(main)f(p)q(oin)o(t)i(here)f(is)g(the)g(di\013erence)g
+(b)q(et)o(w)o(een)f(the)89 1971 y(run)o(time)16 b(costs)i(of)g(creating)g(a)g
+(message)f(digest)h(and)h(encrypting)e(a)h(message,)f(dep)q(ending)h(on)89
+2032 y(the)e(length)g(of)h(the)f(original)g(message.)162 2092
+y(Run)o(time)h(costs)i(for)g(public)f(k)o(ey)g(encryption)g(are)h(rather)g
+(high.)30 b(Man)o(y)18 b(CPU)h(cycles)f(are)89 2152 y(needed.)37
+b(Therefore)21 b(w)o(e)g(w)o(an)o(t)h(to)f(reduce)g(the)h(size)e(of)i(the)g
+(data)g(p)q(ortion)h(that)f(has)g(to)g(b)q(e)89 2212 y(encrypted:)e(in)c(our)
+h(case)f(the)g(output)h(of)f(the)g(message)g(digest)g(algorithm.)162
+2272 y(Run)o(time)c(costs)j(for)f(the)g(hash)h(functions)g(are)f(rather)g
+(small)f(compared)g(to)i(those)f(of)h(public)89 2333 y(k)o(ey)c(encryption.)
+19 b(It)12 b(is)g(therefore)f(imp)q(ortan)o(t)g(to)i(note)f(that)g(it)g(is)g
+(more)f(e\016cien)o(t)f(to)i(pad)h(a)f(short)89 2393 y(DNS)i(message,)g
+(calculate)g(its)g(\014ngerprin)o(t,)g(and)h(then)g(encrypt)f(the)g
+(\014ngerprin)o(t,)g(than)h(simply)89 2453 y(to)e(encrypt)g(the)g(whole)g
+(DNS)g(message.)19 b(Message)14 b(digest)f(lengths)g(are)g(generally)f
+(shorter)h(than)89 2513 y(t)o(ypical)i(DNS)h(messages.)965
+2715 y(17)p eop
+%%Page: 18 18
+17 bop 89 82 a Fe(3.7.3)55 b(P)n(assing)20 b(Creden)n(tials)e(to)g(Pro)n(v)n
+(e)h(Authorit)n(y)89 175 y Ft(The)14 b(crucial)g(p)q(oin)o(t)g(in)g(the)g
+(previously)g(describ)q(ed)f(proto)q(col)j(is)e(the)g(imp)q(ortance)f(of)i
+(the)f(public)89 235 y(k)o(ey)e(of)i(the)f(sender.)20 b(If)13
+b(an)h(attac)o(k)o(er)e(can)i(con)o(vince)e(the)h(receiv)o(er)e(to)i(use)h(k)
+o(ey)e Fd(K)1581 217 y Fa(0)1577 247 y Fc(public)1684 235 y
+Ft(instead)i(of)89 295 y Fd(K)130 302 y Fc(public)224 295 y
+Ft(,)j(whereb)o(y)f(the)h(attac)o(k)o(er)g(p)q(ossesses)h(the)f(related)g
+Fd(K)1226 277 y Fa(0)1222 307 y Fc(pr)q(iv)q(ate)1337 295 y
+Ft(,)g(the)g(attac)o(k)o(er)g(can)g(sub)o(v)o(ert)89 355 y(the)k(proto)q(col)
+i(suc)o(h)e(that)h(the)f(receiv)o(er)f(will)g(b)q(e)i(fo)q(oled)g(in)o(to)f
+(accepting)g(the)h(in)o(tegrit)o(y)d(and)89 415 y(origin)i(of)h(the)f
+(message.)36 b(This)21 b(demonstrates)g(that)g(it)g(is)g(imp)q(ortan)o(t)g
+(to)g(devise)g(a)g(sc)o(heme)89 475 y(that)c(protects)g(against)h(this)f
+(threat.)23 b(W)l(e)17 b(solv)o(e)f(this)h(problem)e(b)o(y)i(the)f(impleme)o
+(n)o(tation)e(of)k(a)89 536 y(distributed)e(sc)o(heme)d(for)k(the)f(v)m
+(alidation)g(of)h(public)e(k)o(ey)g(comp)q(onen)o(t)g(certi\014cates.)162
+596 y(The)e(name)f(serv)o(er)g(sending)h(the)g(DNS)g(message)f(has)i(to)g
+(pro)o(vide)e(creden)o(tials)g(signed)h(b)o(y)f(its)89 656
+y(paren)o(t)18 b(domain,)f(to)h(con)o(vince)f(the)g(recipien)o(t)f(of)i(its)g
+(authorit)o(y)g(o)o(v)o(er)f(the)g(domain)g(for)i(whic)o(h)89
+716 y(it)d(just)g(resolv)o(ed)f(a)i(mapping.)162 776 y(The)d(use)g(of)h(suc)o
+(h)f(a)g(certi\014cate)f(transforms)h(the)g(problem)f(of)h(establishing)g
+(the)g(credibilit)o(y)89 837 y(of)23 b(one)g(en)o(tit)o(y)e(in)o(to)h(the)h
+(problem)e(of)i(establishing)f(the)h(credibilit)o(y)c(of)k(the)g(en)o(tit)o
+(y)e(issuing)89 897 y(the)f(certi\014cate.)32 b(This)21 b(problem)e(is)h(v)o
+(ery)f(closely)g(related)h(to)h(the)f(problem)f(of)h(distributing)89
+957 y(public)14 b(k)o(ey)f(certi\014cates.)20 b(The)14 b(CCITT)i(recomme)o
+(ndation)c(X.509)j(sho)o(ws)h(a)f(w)o(a)o(y)f(to)h(solv)o(e)f(this)89
+1017 y(problem.)19 b(In)c(X.509,)g(a)h(certi\014cate)e(binds)h(a)g(public)g
+(k)o(ey)e(to)j(a)g(directory)e(name)g(and)h(iden)o(ti\014es)89
+1077 y(a)i(part)o(y)f(that)g(v)o(ouc)o(hes)g(for)g(the)g(binding.)162
+1138 y(W)l(e)g(can)g(adopt)h(this)f(mec)o(hanism)o(,)d(suc)o(h)j(that)g(a)g
+(certi\014cate)f(binds)h(all)g(name)e(serv)o(ers)i(that)89
+1198 y(are)i(authoritativ)o(e)f(for)h(a)h(certain)e(zone)h(to)g(this)g(zone)g
+(of)g(authorit)o(y)f(and)i(iden)o(ti\014es)d(the)i(zone)89
+1258 y(that)13 b(v)o(ouc)o(hes)f(for)h(the)f(binding.)20 b(X.509)13
+b(imp)q(oses)f(no)h(constrain)o(ts)g(on)g(the)f(seman)o(tic)f(or)i(syn)o
+(tac-)89 1318 y(tic)h(relationship)h(b)q(et)o(w)o(een)g(a)g(certi\014cate)f
+(issuer)h(and)h(a)g(sub)s(ject.)k(Ho)o(w)o(ev)o(er,)13 b(in)i(our)h(approac)o
+(h,)89 1378 y(the)g(certi\014cation)g(system)g(tak)o(es)g(the)h(form)e(of)i
+(a)h(single)e(ro)q(oted)h(tree.)23 b(Eac)o(h)16 b(no)q(de)i(represen)o(ts)89
+1439 y(a)f(zone.)22 b(Sev)o(eral)15 b(name)g(serv)o(ers)h(serv)o(e)f(as)i
+(certi\014cation)f(authorities)g(for)h(eac)o(h)f(zone,)g(b)q(ecause)89
+1499 y(all)f(serv)o(ers)g(that)h(w)o(ere)f(in)o(tro)q(duced)g(to)h(increase)f
+(the)h(reliabilit)o(y)c(of)k(the)g(database)h(system)d(are)89
+1559 y(capable)i(of)h(v)m(alid)f(and)g(authoritativ)o(e)g(referrals.)162
+1619 y(A)h(certi\014cate)f(for)i(a)g(zone)f(consists)h(of)g(all)f(IP)g
+(addresses)h(of)g(authoritativ)o(e)f(name)f(serv)o(ers)89 1679
+y(for)g(that)f(zone,)g(signed)h(with)f(the)g(priv)m(ate)g(k)o(ey)f(of)i(the)f
+(name)f(serv)o(ers)g(for)i(the)f(paren)o(t)g(domain.)89 1740
+y(An)o(y)f(resolv)o(er)g(that)i(receiv)o(es)d(a)j(DNS)f(message)g(receiv)o
+(es)e(as)j(part)g(of)f(it)g(this)g(certi\014cate.)20 b(After)89
+1800 y(obtaining)14 b(the)f(public)g(k)o(ey)f(for)i(the)f(paren)o(t)g(zone)g
+(of)h(the)f(queried)g(zone,)g(the)g(resolv)o(er)g(can)g(then)89
+1860 y(v)o(erify)i(the)h(v)m(alidit)o(y)f(of)h(the)h(referral.)j(But)c(to)h
+(v)o(erify)e(the)h(authorit)o(y)g(of)h(the)f(paren)o(t)g(zone,)g(the)89
+1920 y(resolv)o(er)f(has)i(to)g(ask)f(this)g(zone)h(for)f(creden)o(tials.)162
+1980 y(This)j(v)m(alidation)g(pro)q(cess)h(for)f(certi\014cates)f(is)h(done)g
+(recursiv)o(ely)e(up)i(the)g(zone)g(hierarc)o(h)o(y)89 2040
+y(tree)e(that)h(coincides)f(with)h(the)f(certi\014cation)g(hierarc)o(h)o(y)l
+(,)f(starting)j(at)f(the)f(name)g(serv)o(er)g(that)89 2101
+y(pro)o(vides)h(the)g(queried)g(mapping.)27 b(The)19 b(recursion)f(will)g
+(stop)h(at)g(some)f(p)q(oin)o(t,)h(either)e(at)i(the)89 2161
+y(ro)q(ot,)f(or)f(at)h(some)e(in)o(termediate)e(no)q(de)k(that)f(w)o(as)h
+(certi\014ed)e(b)q(efore.)24 b(The)17 b(certi\014cates)f(that)i(a)89
+2221 y(name)d(serv)o(er)g(holds)h(are)g(sub)s(ject)g(to)g(timeouts,)e(just)i
+(lik)o(e)f(the)g(resource)h(records)g(that)h(sp)q(ecify)89
+2281 y(bindings)c(of)f(this)h(name)e(serv)o(er.)19 b(The)12
+b(certi\014cate)f(for)i(the)f(ro)q(ot)i(m)o(ust)d(b)q(e)h(transmitted)f(b)o
+(y)h(some)89 2341 y(trusted,)i(out-of-band)i(mec)o(hanism)o(.)i(F)l(or)c
+(example,)e(the)h(ro)q(ot)i(certi\014cate)e(could)g(b)q(e)h(published)89
+2402 y(in)i(an)h(in)o(ternational)e(newspap)q(er.)162 2462
+y(Ev)o(en)k(if)f(an)i(attac)o(k)o(er)e(manages)h(to)g(get)g(a)h(v)m(alid)f
+(certi\014cate)e(of)j(a)f(name)f(serv)o(er)g(it)h(w)o(an)o(ts)89
+2522 y(to)d(imp)q(ersonate,)e(and)i(has)g(the)f(capabilit)o(y)f(to)i(also)g
+(sp)q(o)q(of)h(this)e(name)f(serv)o(er's)g(IP)i(address,)f(it)89
+2582 y(is)j(still)g(not)h(p)q(ossible)f(for)h(the)f(attac)o(k)o(er)g(to)h
+(imp)q(ersonate)e(another)i(host.)29 b(As)18 b(w)o(e)g(sa)o(w)h(in)f(the)965
+2715 y(18)p eop
+%%Page: 19 19
+18 bop 89 82 a Ft(previous)14 b(paragraph)i(3.7.2,)e(a)h(DNS)f(message)f(is)h
+(encrypted)f(with)i(the)e(name)g(serv)o(er's)g(priv)m(ate)89
+142 y(k)o(ey)k(b)q(efore)i(it)f(is)g(sen)o(t)g(out.)29 b(The)18
+b(creden)o(tials)g(are)g(part)h(of)g(the)f(message)g(and)h(are)g(therefore)89
+203 y(also)11 b(encrypted.)19 b(An)10 b(attac)o(k)o(er)g(cannot)i(construct)f
+(the)f(correctly)g(encrypted)g(message)g(without)89 263 y(breaking)16
+b(the)g(asymmetric)d(cryptosystem)i(used.)89 393 y Fe(3.7.4)55
+b(Discussion)89 485 y Ft(The)16 b(v)m(alidation)g(of)h(in)o(tegrit)o(y)d(and)
+j(originator)g(of)f(the)g(message,)f(and)i(its)e(underlying)h(pattern)89
+545 y(of)i(certi\014cations)g(stating)g(trust,)g(are)g(the)g(features)g(that)
+g(mak)o(e)f(this)g(approac)o(h)i(secure.)26 b(The)89 605 y(follo)o(wing)21
+b(discussion)g(sho)o(ws)i(its)e(disadv)m(an)o(tages.)37 b(Some)20
+b(of)i(them)e(are)h(serious)h(enough)g(to)89 666 y(restrain)16
+b(from)f(an)i(implem)o(en)o(tati)o(on)d(of)j(this)f(approac)o(h)h(at)f(the)g
+(curren)o(t)g(time.)162 726 y(The)24 b(whole)g(pro)q(cedure)f(is)h(time)d
+(and)k(space)f(consuming.)43 b(Man)o(y)23 b(rather)h(long)g(public)89
+786 y(k)o(eys)16 b(ha)o(v)o(e)g(to)h(b)q(e)g(stored)g(\(at)g(least)g(200)h
+(decimal)c(digits)j(long)g(eac)o(h)g(to)g(mak)o(e)e(the)h(public)g(k)o(ey)89
+846 y(encryption)21 b(reasonably)h(strong.\))37 b(Obtaining)22
+b(memory)c(for)k(them,)f(as)h(w)o(ell)e(as)i(additional)89
+906 y(cac)o(he)17 b(memory)e(for)i(larger)h(resource)f(records,)h(is)f(not)i
+(a)f(problem)e(in)h(curren)o(t)g(arc)o(hitectures.)89 967 y(The)j(k)o(eys)f
+(m)o(ust)f(b)q(e)i(obtained)g(b)q(efore)g(they)g(can)g(b)q(e)g(used.)32
+b(S.)19 b(Ken)o(t)g(describ)q(es)h(in)f([Ken93])89 1027 y(certi\014cate)c
+(based)i(k)o(ey)e(managemen)o(t)f(for)i(usage)h(in)f(Priv)m(acy)g(Enhanced)g
+(Mail)g(\(PEM\).)162 1087 y(W)l(e)f(will)f(not)h(go)h(in)o(to)f(more)e
+(detail)i(regarding)g(the)g(k)o(ey)f(distribution)g(pro)q(cess.)22
+b(The)15 b(regis-)89 1147 y(tration)e(pro)q(cess)g(that)f(has)i(to)e(o)q
+(ccur)h(out{of{band)h(is)f(rather)f(cum)o(b)q(ersome.)17 b(The)12
+b(calculations)89 1207 y(to)18 b(encrypt)g(and)g(decrypt)f(message)h(digests)
+g(ma)o(y)e(tak)o(e)h(to)q(o)j(long)e(to)g(supp)q(ort)h(the)f(e\016ciency)89
+1267 y(goal)f(of)g(the)g(DNS.)f(The)h(additional)g(data)g(that)g(has)h(to)f
+(b)q(e)g(transmitted)e(w)o(ould)i(not)g(degrade)89 1328 y(p)q(erformance)c
+(to)q(o)j(badly)l(,)e(esp)q(ecially)f(if)g(faster)i(transmission)f(media)e(b)
+q(ecomes)i(broadly)g(a)o(v)m(ail-)89 1388 y(able,)22 b(but)g(the)f
+(calculation)g(o)o(v)o(erhead)g(for)h(encryption)f(and)h(decryption)f(cannot)
+h(easily)f(b)q(e)89 1448 y(amortized.)f(Ho)o(w)o(ev)o(er,)14
+b(the)i Fh(RSA)g Ft(cryptosystem)e(is)i(a)o(v)m(ailable)g(in)g(hardw)o(are)h
+(and)g(a)f(dramatic)89 1508 y(p)q(erformance)g(increase)h(can)h(b)q(e)g
+(observ)o(ed,)f(compared)f(with)i(a)g(soft)o(w)o(are)f(implem)o(en)o(tation)e
+(of)89 1568 y(the)h(same)f(algorithms.)162 1629 y(The)21 b(implem)o(en)o
+(tation)d(of)k(suc)o(h)f(a)g(solution)h(is)e(a)i(ma)s(jor)e(e\013ort.)36
+b(The)22 b(whole)f(k)o(ey)f(man-)89 1689 y(agemen)o(t)i(problem)g(is)h
+(complex)f(and)i(it)f(also)h(requires)e(additional)i(administrativ)o(e)d
+(e\013ort.)89 1749 y(Resolv)o(er)14 b(routines)h(and)h(name)e(serv)o(er)g
+(routines)h(ha)o(v)o(e)f(to)i(b)q(e)f(mo)q(di\014ed,)f(along)i(with)f(the)g
+(DNS)89 1809 y(proto)q(col.)21 b(The)14 b(impleme)o(n)o(tation)e(is)i
+(feasible,)f(though)i(v)o(ery)e(complex.)18 b(Another)c(dra)o(wbac)o(k)g(is)
+89 1869 y(the)h(transition)g(phase)g(that)h(is)f(necessary)f(b)q(ecause)i(of)
+f(proto)q(col)h(c)o(hanges.)21 b(Decreased)14 b(p)q(erfor-)89
+1930 y(mance)e(b)q(ecause)i(of)h(calculations)e(necessary)h(to)g(sign,)g
+(encrypt)f(and)i(decrypt)e(messages)g(w)o(ould)89 1990 y(b)q(e)j(noticeable)g
+(b)o(y)f(users)i(and)g(real-time)d(applications.)162 2050 y(Curren)o(tly)l(,)
+i(the)h(metho)q(d)g(seems)f(to)i(b)q(e)f(infeasible,)f(b)q(ecause)i(of)f(its)
+g(large)h(computational)89 2110 y(o)o(v)o(erhead.)i(F)l(urther)c(dra)o(wbac)o
+(ks)g(are)h(the)f(necessary)f(proto)q(col)i(c)o(hanges)g(and)f(the)g
+(complexit)o(y)89 2170 y(of)11 b(prop)q(er)h(k)o(ey)e(and)h(certi\014cate)f
+(managemen)o(t.)17 b(Ho)o(w)o(ev)o(er)9 b(with)i(further)g(adv)m(ances)g(in)g
+(pro)q(cessor)89 2231 y(sp)q(eed)24 b(and)g(some)f(reasonable)h(relaxation)g
+(on)g(requiremen)o(ts)d(for)j(strong)h(encryption)e(\(i.e.)89
+2291 y(shorter)d(k)o(eys)f(increase)g(p)q(erformance)g(of)h
+Fh(RSA)g Ft(dramatically\))e(this)i(approac)o(h)g(can)g(b)q(ecome)89
+2351 y(v)o(ery)15 b(attractiv)o(e)g(in)h(the)g(near)g(future.)965
+2715 y(19)p eop
+%%Page: 20 20
+19 bop 89 90 a Fu(4)83 b(Conclusions)25 b(and)j(Outlo)r(ok)89
+200 y Ft(Where)19 b(host)h(iden)o(ti\014cation)f(is)g(part)h(of)g(the)f
+(authen)o(tication)g(b)q(et)o(w)o(een)g(comm)o(uni)o(cating)e(en-)89
+260 y(tities)h(the)g(v)m(alidit)o(y)g(of)h(the)g(authen)o(tication)f(pro)q
+(cess)i(can)f(only)f(b)q(e)i(trusted)e(as)i(m)o(uc)o(h)d(as)i(the)89
+320 y(resolution)c(pro)q(cess)h(that)f(supplies)g(the)g(bindings)g(b)q(et)o
+(w)o(een)g(high{lev)o(el)e(hostnames)i(and)h(lo)o(w{)89 381
+y(lev)o(el)e(host)j(addresses.)162 441 y(This)f(is)g(a)h(signi\014can)o(t)f
+(problem,)e(b)q(ecause)j(it)e(exp)q(oses)i(probably)g(h)o(undreds)f(of)g
+(thousands)89 501 y(of)h(hosts)g(that)f(are)h(curren)o(tly)d(connected)i(to)h
+(the)f(In)o(ternet)f(to)h(the)g(threat)g(of)h(break-ins.)162
+561 y(W)l(e)g(discussed)g(solutions)g(to)h(the)f(problem)e(with)i(the)g
+(concrete)f(instance)h(of)g(the)g(Domain)89 621 y(Name)g(System.)26
+b(W)l(e)18 b(stressed)h(hardening)g(curren)o(t)f(implem)o(e)o(n)o(tations)e
+(of)j(the)f(name)g(serv)o(ers)89 682 y(and)k(put)f(emphasis)g(on)g(the)g(dev)
+o(elopmen)o(t)e(of)i(a)h(future)f(sc)o(heme)e(that)i(uses)h(cryptographic)89
+742 y(metho)q(ds)16 b(to)g(giv)o(e)g(a)g(strong)i(guaran)o(tee)e(for)h
+(detection)e(of)h(sp)q(o)q(ofed)i(bindings.)89 908 y Fu(Ac)n(kno)n(wledgemen)
+n(ts)89 1018 y Ft(W)l(e)g(w)o(ould)g(lik)o(e)e(to)j(thank)f(CO)o(AST)g(sp)q
+(onsors)i(BNR,)d(T)l(riden)o(t)g(Data)i(Systems,)e(and)h(the)g(US)89
+1078 y(Air)e(F)l(orce,)h(and)g(the)g(F)l(ulbrigh)o(t)f(Commission)f(for)j
+(supp)q(ort)g(that)g(aided,)e(in)h(part,)g(this)g(w)o(ork.)89
+1138 y(Thanks)d(to)f(Stev)o(en)f(Bello)o(vin)f(whose)j(v)m(aluable)f(commen)n
+(ts)e(are)i(most)f(appreciated,)h(Dan)h(T)l(rin-)89 1198 y(kle)d(who)h(sho)o
+(w)o(ed)g(us)g(ho)o(w)g(to)g(master)e(some)h(of)h(the)f(subtle)g
+(di\016culties)f(of)i(the)f(DNS,)g(and)h(J.R.R.)89 1258 y(T)l(olkien)j(whose)
+i(fan)o(tasy)g(pro)o(vided)e(the)h(hostnames.)89 1425 y Fu(References)119
+1534 y Ft([Bel89])23 b(Stev)o(en)11 b(M.)g(Bello)o(vin.)g Fi(Se)n(curity)j
+(Pr)n(oblems)f(in)h(the)f(TCP/IP)g(Pr)n(oto)n(c)n(ol)f(Suite)p
+Ft(.)j(A)l(T&T)289 1594 y(Bell)g(Lab)q(oratories,)j(Murra)o(y)d(Hill,)f(New)i
+(Jersey)l(,)f(April)g(1989.)119 1696 y([Bel90])23 b(Stev)o(en)e(M.)h(Bello)o
+(vin.)35 b Fi(Using)24 b(the)f(Domain)g(Name)g(System)g(for)f(System)h(Br)n
+(e)n(ak-)289 1756 y(ins)p Ft(.)d(A)l(T&T)15 b(Bell)e(Lab)q(oratories,)k
+(Murra)o(y)e(Hill,)e(New)h(Jersey)l(,)g(1990.)21 b(\(unpublished)289
+1817 y(tec)o(hnical)15 b(rep)q(ort\).)119 1918 y([Bel92])23
+b(Stev)o(en)18 b(M.)f(Bello)o(vin.)25 b(There)18 b(Be)g(Dragons.)29
+b(In)18 b Fi(UNIX)i(Se)n(curity)f(Symp)n(osium)g(III)289 1978
+y(Pr)n(o)n(c)n(e)n(e)n(dings)p Ft(,)c(pages)i(1{16,)h(Baltimore,)13
+b(MD,)j(1992.)89 2080 y([Com91])23 b(Douglas)13 b(E.)d(Comer.)i
+Fi(Internetworking)i(with)f(TCP/IP)p Ft(.)f(Pren)o(tice-Hall,)e(Englew)o(o)q
+(o)q(d)289 2140 y(Cli\013s,)16 b(New)g(Jersey)l(,)f(second)i(edition,)e
+(1991.)103 2242 y([Den82])24 b(Doroth)o(y)g(E.)f(Denning.)41
+b Fi(Crypto)n(gr)n(aphy)21 b(and)j(Data)f(Se)n(curity)p Ft(.)42
+b(Addison-W)l(esley)289 2302 y(Publishing)17 b(Compan)o(y)l(,)e(Inc.,)f
+(1982.)124 2404 y([GS91])24 b(Simson)14 b(Gar\014nk)o(el)g(and)g(Gene)g
+(Spa\013ord.)20 b Fi(Pr)n(actic)n(al)15 b(UNIX)h(Se)n(curity)p
+Ft(.)j(O'Reilley)11 b(&)289 2464 y(Asso)q(ciates,)17 b(Inc.)e(Sebastop)q(ol,)
+i(CA.,)e(1991.)965 2715 y(20)p eop
+%%Page: 21 21
+20 bop 103 82 a Ft([Ken93])23 b(Stephen)29 b(T.)f(Ken)o(t.)57
+b Fi(RF)o(C-1422)28 b(Privacy)h(Enhanc)n(ement)h(for)f(Internet)h(Ele)n(c-)
+289 142 y(tr)n(onic)16 b(Mail:)21 b(Part)15 b(II:)f(Certi\014c)n(ate-Base)n
+(d)j(Key)e(Management)p Ft(.)k(Net)o(w)o(ork)13 b(W)l(orking)289
+203 y(Group,)k(F)l(ebruary)f(1993.)115 304 y([Lot94])25 b(Mark)18
+b(Lottor.)25 b(In)o(ternet)17 b(Domain)f(Surv)o(ey)h(Jan)h(94.)25
+b(SRI)17 b(In)o(ternational,)g(Jan)o(uary)289 364 y(1994.)104
+466 y([Mer89])23 b(Ralph)17 b(C.)f(Merkle.)j(Snefru.)i(Xero)o(x)16
+b(Corp)q(oration,)h(P)o(alo)g(Alto,)e(CA,)g(1989.)97 568 y([Mo)q(c87])24
+b(P)o(aul)g(Mo)q(c)o(k)m(ap)q(etris.)42 b Fi(RF)o(C-1034)23
+b(Domain)h(Names)g(-)h(Conc)n(epts)f(and)g(F)l(acilities)p
+Ft(.)289 628 y(Net)o(w)o(ork)16 b(W)l(orking)g(Group,)h(No)o(v)o(em)o(b)q(er)
+c(1987.)101 730 y([Mor85])24 b(R.)18 b(T.)g(Morris.)27 b(A)17
+b(W)l(eakness)h(in)g(the)g(4.2BSD)g(UNIX)f(TCP/IP)i(Soft)o(w)o(are.)26
+b(Com-)289 790 y(puting)15 b(Science)e(T)l(ec)o(hnical)h(Rep)q(ort)h(No.)f
+(117,)i(A)l(T&T)e(Bell)f(Lab)q(oratories,)j(Murra)o(y)289 850
+y(Hill,)f(New)g(Jersey)l(,)g(F)l(ebruary)h(1985.)91 952 y([NBS77])23
+b(NBS.)d(Data)c(Encryption)g(Standard.)21 b(National)15 b(Bureau)g(of)h
+(Standards,)h(W)l(ashing-)289 1012 y(ton)g(D.C.,)f(Jan.)g(1977.)23
+b(FIPS)16 b(PUB)f(46.)119 1114 y([PH78])24 b(S.)19 b(P)o(ohlig)f(and)i(M.)e
+(Hellman.)26 b(An)18 b(Impro)o(v)o(ed)e(Algorithm)h(for)i(Computing)f(Loga-)
+289 1174 y(rithms)d(o)o(v)o(er)h Fe(GF)p Ft(\(p\))g(and)h(its)g
+(Cryptographic)g(Signi\014cance.)j Fi(IEEE)e(T)l(r)n(ansactions)289
+1234 y(on)g(Information)f(The)n(ory)p Ft(,)e(IT-24\(1\):106{10,)k(Jan)o(uary)
+e(1978.)126 1336 y([PL91])24 b(R.)14 b(P)o(aans)g(and)g(H.)f(de)g(Lange.)18
+b(Auditing)13 b(the)g(SNA/SNI)g(En)o(vironmen)o(t.)h Fi(Computer)289
+1396 y(&)k(Se)n(curity)p Ft(,)e(10\(3\):251{61,)j(Ma)o(y)d(1991.)114
+1498 y([Riv92])23 b(Ronald)14 b(L.)g(Riv)o(est.)h Fi(RF)o(C-1321)f(The)h(MD5)
+g(Message-Digest)h(A)o(lgorithm)p Ft(.)h(Net)o(w)o(ork)289
+1558 y(W)l(orking)g(Group,)g(April)e(1992.)90 1660 y([RSA78])23
+b(R.)d(Riv)o(est,)g(A.)g(Shamir,)f(and)i(L.)g(Adleman.)31 b(A)20
+b(Metho)q(d)h(for)g(Obtaining)f(Digital)289 1720 y(Signatures)g(and)f(Public)
+e(Key)h(Cryptosystems.)28 b Fi(Communic)n(ations)19 b(of)h(the)g(A)o(CM)p
+Ft(,)289 1780 y(21\(2\):120{6,)f(F)l(ebruary)d(1978.)115 1882
+y([Sc)o(h93])23 b(Christoph)17 b(L.)e(Sc)o(h)o(uba.)20 b(Addressing)c(W)l
+(eaknesses)f(in)g(the)h(Domain)f(Name)f(System)289 1942 y(Proto)q(col.)32
+b(Master's)19 b(thesis,)g(Purdue)h(Univ)o(ersit)o(y)l(,)d(W)l(est)i(Lafa)o(y)
+o(ette,)h(IN,)e(August)289 2002 y(1993.)115 2104 y([Sc)o(h94])23
+b(Bruce)16 b(Sc)o(hneier.)j Fi(Applie)n(d)f(Crypto)n(gr)n(aphy)p
+Ft(.)h(John)e(Wiley)d(&)j(Sons,)f(Inc.,)f(1994.)121 2205 y([Ste90])24
+b(Ric)o(hard)c(W.)f(Stev)o(ens.)31 b Fi(UNIX)21 b(Network)h(Pr)n(o)n(gr)n
+(amming)p Ft(.)30 b(Pren)o(tice-Hall,)18 b(Engle-)289 2266
+y(w)o(o)q(o)q(d)g(Cli\013s,)e(New)g(Jersey)l(,)f(1990.)120
+2367 y([T)l(ol65])24 b(John)g(R.)e(R.)g(T)l(olkien.)39 b Fi(The)23
+b(L)n(or)n(d)f(of)h(the)g(R)o(ings)p Ft(.)40 b(Hough)o(ton)24
+b(Mi\017in,)e(Boston,)289 2428 y(second)17 b(edition,)e(1965.)965
+2715 y(21)p eop
+%%Trailer
+end
+userdict /end-hook known{end-hook}if
+%%EOF
diff --git a/usr.sbin/named/doc/misc/purdue-thesis.ps b/usr.sbin/named/doc/misc/purdue-thesis.ps
new file mode 100644
index 00000000000..b3268efa6d2
--- /dev/null
+++ b/usr.sbin/named/doc/misc/purdue-thesis.ps
@@ -0,0 +1,7129 @@
+%!PS-Adobe-2.0
+%%Creator: dvips 5.485 Copyright 1986-92 Radical Eye Software
+%%Title: 94-028.dvi
+%%Pages: 97 1
+%%BoundingBox: 0 0 612 792
+%%EndComments
+%DVIPSCommandLine: /usr/local/tex/dvips 94-028.dvi
+%%BeginProcSet: tex.pro
+/TeXDict 250 dict def TeXDict begin /N{def}def /B{bind def}N /S{exch}N /X{S N}
+B /TR{translate}N /isls false N /vsize 11 72 mul N /@rigin{isls{[0 -1 1 0 0 0]
+concat}if 72 Resolution div 72 VResolution div neg scale isls{Resolution hsize
+-72 div mul 0 TR}if Resolution VResolution vsize -72 div 1 add mul TR matrix
+currentmatrix dup dup 4 get round 4 exch put dup dup 5 get round 5 exch put
+setmatrix}N /@landscape{/isls true N}B /@manualfeed{statusdict /manualfeed
+true put}B /@copies{/#copies X}B /FMat[1 0 0 -1 0 0]N /FBB[0 0 0 0]N /nn 0 N
+/IE 0 N /ctr 0 N /df-tail{/nn 8 dict N nn begin /FontType 3 N /FontMatrix
+fntrx N /FontBBox FBB N string /base X array /BitMaps X /BuildChar{
+CharBuilder}N /Encoding IE N end dup{/foo setfont}2 array copy cvx N load 0 nn
+put /ctr 0 N[}B /df{/sf 1 N /fntrx FMat N df-tail}B /dfs{div /sf X /fntrx[sf 0
+0 sf neg 0 0]N df-tail}B /E{pop nn dup definefont setfont}B /ch-width{ch-data
+dup length 5 sub get}B /ch-height{ch-data dup length 4 sub get}B /ch-xoff{128
+ch-data dup length 3 sub get sub}B /ch-yoff{ch-data dup length 2 sub get 127
+sub}B /ch-dx{ch-data dup length 1 sub get}B /ch-image{ch-data dup type
+/stringtype ne{ctr get /ctr ctr 1 add N}if}B /id 0 N /rw 0 N /rc 0 N /gp 0 N
+/cp 0 N /G 0 N /sf 0 N /CharBuilder{save 3 1 roll S dup /base get 2 index get
+S /BitMaps get S get /ch-data X pop /ctr 0 N ch-dx 0 ch-xoff ch-yoff ch-height
+sub ch-xoff ch-width add ch-yoff setcachedevice ch-width ch-height true[1 0 0
+-1 -.1 ch-xoff sub ch-yoff .1 add]{ch-image}imagemask restore}B /D{/cc X dup
+type /stringtype ne{]}if nn /base get cc ctr put nn /BitMaps get S ctr S sf 1
+ne{dup dup length 1 sub dup 2 index S get sf div put}if put /ctr ctr 1 add N}
+B /I{cc 1 add D}B /bop{userdict /bop-hook known{bop-hook}if /SI save N @rigin
+0 0 moveto pop}N /eop{SI restore showpage userdict /eop-hook known{eop-hook}
+if}N /@start{userdict /start-hook known{start-hook}if /VResolution X
+/Resolution X 1000 div /DVImag X /IE 256 array N 0 1 255{IE S 1 string dup 0 3
+index put cvn put}for 65781.76 div /vsize X 65781.76 div /hsize X}N /p{show}N
+/RMat[1 0 0 -1 0 0]N /BDot 260 string N /rulex 0 N /ruley 0 N /v{/ruley X
+/rulex X V}B /V statusdict begin /product where{pop product dup length 7 ge{0
+7 getinterval(Display)eq}{pop false}ifelse}{false}ifelse end{{gsave TR -.1 -.1
+TR 1 1 scale rulex ruley false RMat{BDot}imagemask grestore}}{{gsave TR -.1
+-.1 TR rulex ruley scale 1 1 false RMat{BDot}imagemask grestore}}ifelse B /a{
+moveto}B /delta 0 N /tail{dup /delta X 0 rmoveto}B /M{S p delta add tail}B /b{
+S p tail}B /c{-4 M}B /d{-3 M}B /e{-2 M}B /f{-1 M}B /g{0 M}B /h{1 M}B /i{2 M}B
+/j{3 M}B /k{4 M}B /w{0 rmoveto}B /l{p -4 w}B /m{p -3 w}B /n{p -2 w}B /o{p -1 w
+}B /q{p 1 w}B /r{p 2 w}B /s{p 3 w}B /t{p 4 w}B /x{0 S rmoveto}B /y{3 2 roll p
+a}B /bos{/SS save N}B /eos{SS restore}B end
+%%EndProcSet
+%%BeginProcSet: special.pro
+TeXDict begin /SDict 200 dict N SDict begin /@SpecialDefaults{/hs 612 N /vs
+792 N /ho 0 N /vo 0 N /hsc 1 N /vsc 1 N /ang 0 N /CLIP 0 N /rwiSeen false N
+/rhiSeen false N /letter{}N /note{}N /a4{}N /legal{}N}B /@scaleunit 100 N
+/@hscale{@scaleunit div /hsc X}B /@vscale{@scaleunit div /vsc X}B /@hsize{/hs
+X /CLIP 1 N}B /@vsize{/vs X /CLIP 1 N}B /@clip{/CLIP 2 N}B /@hoffset{/ho X}B
+/@voffset{/vo X}B /@angle{/ang X}B /@rwi{10 div /rwi X /rwiSeen true N}B /@rhi
+{10 div /rhi X /rhiSeen true N}B /@llx{/llx X}B /@lly{/lly X}B /@urx{/urx X}B
+/@ury{/ury X}B /magscale true def end /@MacSetUp{userdict /md known{userdict
+/md get type /dicttype eq{userdict begin md length 10 add md maxlength ge{/md
+md dup length 20 add dict copy def}if end md begin /letter{}N /note{}N /legal{
+}N /od{txpose 1 0 mtx defaultmatrix dtransform S atan/pa X newpath clippath
+mark{transform{itransform moveto}}{transform{itransform lineto}}{6 -2 roll
+transform 6 -2 roll transform 6 -2 roll transform{itransform 6 2 roll
+itransform 6 2 roll itransform 6 2 roll curveto}}{{closepath}}pathforall
+newpath counttomark array astore /gc xdf pop ct 39 0 put 10 fz 0 fs 2
+F/|______Courier fnt invertflag{PaintBlack}if}N /txpose{pxs pys scale ppr
+aload pop por{noflips{pop S neg S TR pop 1 -1 scale}if xflip yflip and{pop S
+neg S TR 180 rotate 1 -1 scale ppr 3 get ppr 1 get neg sub neg ppr 2 get ppr 0
+get neg sub neg TR}if xflip yflip not and{pop S neg S TR pop 180 rotate ppr 3
+get ppr 1 get neg sub neg 0 TR}if yflip xflip not and{ppr 1 get neg ppr 0 get
+neg TR}if}{noflips{TR pop pop 270 rotate 1 -1 scale}if xflip yflip and{TR pop
+pop 90 rotate 1 -1 scale ppr 3 get ppr 1 get neg sub neg ppr 2 get ppr 0 get
+neg sub neg TR}if xflip yflip not and{TR pop pop 90 rotate ppr 3 get ppr 1 get
+neg sub neg 0 TR}if yflip xflip not and{TR pop pop 270 rotate ppr 2 get ppr 0
+get neg sub neg 0 S TR}if}ifelse scaleby96{ppr aload pop 4 -1 roll add 2 div 3
+1 roll add 2 div 2 copy TR .96 dup scale neg S neg S TR}if}N /cp{pop pop
+showpage pm restore}N end}if}if}N /normalscale{Resolution 72 div VResolution
+72 div neg scale magscale{DVImag dup scale}if 0 setgray}N /psfts{S 65781.76
+div N}N /startTexFig{/psf$SavedState save N userdict maxlength dict begin
+/magscale false def normalscale currentpoint TR /psf$ury psfts /psf$urx psfts
+/psf$lly psfts /psf$llx psfts /psf$y psfts /psf$x psfts currentpoint /psf$cy X
+/psf$cx X /psf$sx psf$x psf$urx psf$llx sub div N /psf$sy psf$y psf$ury
+psf$lly sub div N psf$sx psf$sy scale psf$cx psf$sx div psf$llx sub psf$cy
+psf$sy div psf$ury sub TR /showpage{}N /erasepage{}N /copypage{}N /p 3 def
+@MacSetUp}N /doclip{psf$llx psf$lly psf$urx psf$ury currentpoint 6 2 roll
+newpath 4 copy 4 2 roll moveto 6 -1 roll S lineto S lineto S lineto closepath
+clip newpath moveto}N /endTexFig{end psf$SavedState restore}N /@beginspecial{
+SDict begin /SpecialSave save N gsave normalscale currentpoint TR
+@SpecialDefaults count /ocount X /dcount countdictstack N}N /@setspecial{CLIP
+1 eq{newpath 0 0 moveto hs 0 rlineto 0 vs rlineto hs neg 0 rlineto closepath
+clip}if ho vo TR hsc vsc scale ang rotate rwiSeen{rwi urx llx sub div rhiSeen{
+rhi ury lly sub div}{dup}ifelse scale llx neg lly neg TR}{rhiSeen{rhi ury lly
+sub div dup scale llx neg lly neg TR}if}ifelse CLIP 2 eq{newpath llx lly
+moveto urx lly lineto urx ury lineto llx ury lineto closepath clip}if
+/showpage{}N /erasepage{}N /copypage{}N newpath}N /@endspecial{count ocount
+sub{pop}repeat countdictstack dcount sub{end}repeat grestore SpecialSave
+restore end}N /@defspecial{SDict begin}N /@fedspecial{end}B /li{lineto}B /rl{
+rlineto}B /rc{rcurveto}B /np{/SaveX currentpoint /SaveY X N 1 setlinecap
+newpath}N /st{stroke SaveX SaveY moveto}N /fil{fill SaveX SaveY moveto}N
+/ellipse{/endangle X /startangle X /yrad X /xrad X /savematrix matrix
+currentmatrix N TR xrad yrad scale 0 0 1 startangle endangle arc savematrix
+setmatrix}N end
+%%EndProcSet
+TeXDict begin 40258431 52099146 1000 300 300 @start /Fa 61
+124 df<00000FE0000030180000E01C0001C03C0001803C000380380003800000038000000700
+0000070000000700000007000000070000000E000000FFFFE0000E00E0000E00E0000E01C0001C
+01C0001C01C0001C01C0001C0380001C0380003803800038038000380700003807000038070000
+70070800700E1000700E1000700E1000700E2000E0062000E003C000E0000000E0000000C00000
+01C0000001C0000071800000F1800000F3000000620000003C0000001E2D82A21B>12
+D<0007800000001C6003800030100780006010078000E010038000C010010001C07001000380F0
+02000380F002000380600400070000080007000010000700006000073C00A00007E20310000781
+041000070108080007011008000F022008001F842008001C782C08003C003E080038003E080078
+001C0800780000080078000008007000001000F000001000700000200070000020007800004000
+380000800038000100001C000200000E000C00000380700000007F80000021257BA325>38
+D<0C1E3F3F1D02020204040810204080080F75A20F>I<0E1E1E1E1E0202040408081020408007
+0F7D840F>44 D<FFF0FFF0FFE00C037C8B11>I<70F8F8F0E005057A840F>I<0000000800000018
+000000300000003000000060000000C0000000C000000180000001800000030000000600000006
+0000000C0000000C0000001800000030000000300000006000000060000000C000000180000001
+800000030000000300000006000000060000000C00000018000000180000003000000030000000
+60000000C0000000C0000001800000018000000300000006000000060000000C0000000C000000
+1800000030000000300000006000000060000000C0000000C0000000800000001D317FA419>I<
+000F800030C000E06001C0700380700300700700700F00700E00701E00701E00701C00F03C00F0
+3C00F03C00F07801E07801E07801E07801E0F003C0F003C0F003C0F00380E00780E00780E00700
+E00F00E00E00E01C00E01C00E0380060700030E0001F000014227AA019>I<0001000300030006
+001E002E03CE001C001C001C001C0038003800380038007000700070007000E000E000E000E001
+C001C001C001C003800380038003800780FFFC10217AA019>I<000FC000106000603800801800
+801C01001C02201E02101E04101E04101E04101E08203C08203C0840380840780880F00700E000
+01C000030000060000180000200000C0000100000200000400100800301000202000605F80C063
+FFC040FF80807F00801E0017227CA019>I<000FC000307000C01801001C02001C04000C04401C
+08201C08201C08201C08403808C0380700700000600001C000070000FC00000700000380000380
+0001C00001C00001C00003C06003C0F003C0F00380E00780800700800E00801C0040380020F000
+1F800016227BA019>I<0000180000380000380000700000700000700000E00000E00000E00000
+C00001C0000180000380000300000300000600000600000C00000C000018000010000031800061
+C00043800083800183800303800207000407000807003FC700403E00800FF0000E00000E00001C
+00001C00001C00001C00003800003800003800003000152B7EA019>I<00400400703800FFF000
+FFE000BF80008000010000010000010000010000020000020000023E0002C3000501800601C004
+01C00001E00001E00001E00001E00001E00001E07003C0F003C0F003C0E00780800700800F0080
+0E00401C0040380030E0000F800016227BA019>I<000FC000306000401000801801000803000C
+03000C06001807001807001007003007C06007E0C003F18001FE0000FC0000FE00033F00061F80
+0C07C01803C03001C06001C06000C0C000C0C000C0C00080C00180C00100C00200C00600600800
+3030000FC00016227BA019>56 D<000FC000386000703000E03001C0380380380780380700380F
+00380F00380F00381E00781E00781E00781E00F81E00F01C00F00E01F00E02F00605E00309E001
+F1E00003C00003C0000380000700000700600E00F00C00F01800E0300080600041C0003F000015
+227BA019>I<07000F800F800F000E000000000000000000000000000000000000000000000070
+00F800F800F000E00009157A940F>I<0000030000000300000007000000070000000F0000000F
+0000001F0000002F0000002F0000004F0000004F80000087800000878000010780000207800002
+078000040780000407800008078000080780001007800030078000200780007FFF80004007C000
+8007C0008003C0010003C0030003C0020003C0040003C0040003C00C0003C03C0007C0FF003FFC
+1E237DA224>65 D<00FFFFE0000F0038000F001C000F001E001E000E001E000F001E000F001E00
+0F003C000E003C001E003C001E003C003C00780078007800F0007801E00078078000FFFF8000F0
+01E000F000F000F0007801E0007801E0003801E0003C01E0003C03C0007803C0007803C0007803
+C000F0078000F0078001E0078003C0078007000F801E00FFFFF00020227DA122>I<00007F0080
+0003808100000E00630000380027000070001F0000E0000E0001C0000E000380000E000700000E
+000F000004000E000004001E000004003C000004003C0000080078000000007800000000780000
+0000F000000000F000000000F000000000F000000000F000000000E000000000E000002000E000
+002000E000004000E000004000F00000800070000080007000010000380002000018000400001C
+0008000006003000000381C0000000FE000000212479A223>I<00FFFFF000000F003C00000F00
+0E00000F000700001E000380001E000380001E0001C0001E0001C0003C0001C0003C0001E0003C
+0001E0003C0001E000780001E000780001E000780001E000780001E000F00003C000F00003C000
+F00003C000F00003C001E000078001E000078001E000070001E0000F0003C0000E0003C0001C00
+03C0003C0003C00038000780007000078000E000078001C00007800700000F801C0000FFFFF000
+0023227DA125>I<00FFFFFF80000F000780000F000180000F000180001E000180001E00018000
+1E000100001E000100003C000100003C000100003C010100003C01000000780200000078020000
+007806000000780E000000FFFC000000F00C000000F00C000000F00C000001E008000001E00800
+0001E008040001E000080003C000080003C000080003C000100003C00010000780002000078000
+6000078000C000078001C0000F8007C000FFFFFF800021227DA121>I<00FFFFFF000F000F000F
+0003000F0003001E0003001E0003001E0002001E0002003C0002003C0002003C0102003C010000
+780200007802000078060000780E0000FFFC0000F00C0000F00C0000F00C0001E0080001E00800
+01E0080001E0000003C0000003C0000003C0000003C00000078000000780000007800000078000
+000F800000FFFC000020227DA120>I<00007F00800003808100000E0063000038002700007000
+1F0000E0000E0001C0000E000380000E000700000E000F000004000E000004001E000004003C00
+0004003C00000800780000000078000000007800000000F000000000F000000000F000000000F0
+00000000F0003FFC00E00001E000E00001E000E00001E000E00003C000E00003C000F00003C000
+700003C0007000078000380007800018000F80001C0013800006002300000381C1000000FE0000
+00212479A226>I<00FFF87FFC000F000780000F000780000F000780001E000F00001E000F0000
+1E000F00001E000F00003C001E00003C001E00003C001E00003C001E000078003C000078003C00
+0078003C000078003C0000FFFFF80000F000780000F000780000F000780001E000F00001E000F0
+0001E000F00001E000F00003C001E00003C001E00003C001E00003C001E000078003C000078003
+C000078003C000078003C0000F8007C000FFF87FFC0026227DA124>I<00FFF8000F00000F0000
+0F00001E00001E00001E00001E00003C00003C00003C00003C0000780000780000780000780000
+F00000F00000F00000F00001E00001E00001E00001E00003C00003C00003C00003C00007800007
+80000780000780000F8000FFF80015227DA113>I<00FFF807FC000F0001E0000F0001C0000F00
+0100001E000200001E000400001E001000001E002000003C004000003C008000003C010000003C
+04000000780800000078180000007838000000787C000000F0BC000000F23C000000F41E000000
+F81E000001F01F000001E00F000001E00F000001E00F800003C007800003C007800003C003C000
+03C003C000078003C000078001E000078001E000078001E0000F8001F000FFF80FFE0026227DA1
+25>75 D<00FF800007FC000F80000F80000F80001780000F80001780001780002F000013C0002F
+000013C0004F000013C0008F000023C0009E000023C0011E000023C0011E000023C0021E000043
+C0043C000043C0043C000043C0083C000041E0083C000081E01078000081E02078000081E02078
+000081E04078000101E040F0000101E080F0000101E100F0000101E100F0000200F201E0000200
+F201E0000200F401E0000200F801E0000400F803C0000400F003C0000400F003C0000C00E003C0
+001E00C007C000FFC0C07FFC002E227DA12C>77 D<00FF000FFC000F8001E0000F800180000FC0
+00800013C001000013C001000011E001000011E001000021E002000020F002000020F002000020
+F0020000407804000040780400004078040000403C040000803C080000803E080000801E080000
+801E080001001F100001000F100001000F10000100079000020007A000020007A000020003E000
+020003E000040003C000040001C000040001C0000C0001C0001E00008000FFC000800026227DA1
+24>I<0000FE0000078380000C00E0003800700070003800E0003801C0001C0380001C0700001C
+0F00001E1E00001E1C00001E3C00001E3C00001E7800001E7800001E7800001EF000003CF00000
+3CF000003CF0000078F0000078E0000078E00000F0E00000F0E00001E0E00001C0F00003C0F000
+07807000070078000E0038001C001C0038000E00E0000703800001FC00001F2479A225>I<00FF
+FFE0000F0038000F001E000F000E001E0007001E0007001E0007001E0007003C000F003C000F00
+3C000F003C001E0078001E0078003C00780078007800E000F003C000FFFE0000F0000000F00000
+01E0000001E0000001E0000001E0000003C0000003C0000003C0000003C0000007800000078000
+0007800000078000000F800000FFF8000020227DA121>I<00FFFFC0000F0070000F003C000F00
+1C001E000E001E000E001E000F001E000F003C001E003C001E003C001E003C003C007800380078
+0070007801E00078078000FFFC0000F00E0000F0070000F0038001E003C001E003C001E003C001
+E003C003C0078003C0078003C0078003C0078007800F0007800F0107800F01078007020F800702
+FFF8038C000000F020237DA124>82 D<0001F020000E0C40001802C0003001C0006001C000E001
+8000C0018001C0018001C0018003C0010003C0010003C0000003C0000003E0000001F8000001FF
+000000FFE000007FF000001FF8000003FC0000007C0000003C0000001E0000001E0000001E0020
+001C0020001C0020001C00200018006000380060003000700060007000C000C8018000C6070000
+81FC00001B247DA21B>I<1FFFFFF81E03C0381803C0183003C018200780182007801840078010
+40078010400F0010800F0010800F0010000F0000001E0000001E0000001E0000001E0000003C00
+00003C0000003C0000003C00000078000000780000007800000078000000F0000000F0000000F0
+000000F0000001E0000001E0000001E0000001E0000003E00000FFFF00001D2277A123>I<3FFE
+03FF03C0007803C0006003C00020078000400780004007800040078000400F0000800F0000800F
+0000800F0000801E0001001E0001001E0001001E0001003C0002003C0002003C0002003C000200
+7800040078000400780004007800040070000800F0000800F00010007000100070002000700040
+003000400038018000180200000E0C000003F00000202377A124>I<FFF03FF80FF81F0007C003
+C01E00078001801E00078001001E00078002001E000F8002001E000F8004001F00178004001F00
+178008000F00278008000F00278010000F00478010000F00C78020000F00878020000F01078040
+000F010780C0000F02078080000F02078100000F04078100000F0407C200000F0807C200000F08
+03C400000F1003C400000F1003C800000F2003C800000F2003D000000F4003D000000FC003E000
+000F8003E000000F0003C000000F00038000000E00038000000E00030000000C00030000000C00
+020000002D2376A131>87 D<007FF81FF8000FC007C000078003000007C002000003C004000003
+C008000003E010000001E030000001E020000001F040000000F080000000F100000000FA000000
+007C000000007C000000007C000000003C000000003C000000007E000000009E000000011E0000
+00031F000000060F000000040F000000080F80000010078000002007C000004007C00000C003C0
+00018003E000010001E000070001E0001F0003F000FFC01FFE0025227EA124>I<00F8C00185C0
+0705C00E03800E03801C03803C0380380700780700780700780700F00E00F00E00F00E00F00E10
+F01C20701C20703C20305C40308C400F078014157B9419>97 D<03C03F80038003800380070007
+00070007000E000E000E000E001C001CF81D0C1E0E3C0638073807380F700F700F700F700FE01E
+E01EE01EE03CE038E038607060E031C01F0010237BA216>I<007E0001C1000301800703800E07
+801C07803C0000380000780000780000780000F00000F00000F00000F00000F001007001007002
+00300C001830000FC00011157B9416>I<00003C0003F800003800003800003800007000007000
+00700000700000E00000E00000E00000E00001C000F9C00185C00705C00E03800E03801C03803C
+0380380700780700780700780700F00E00F00E00F00E00F00E10F01C20701C20703C20305C4030
+8C400F078016237BA219>I<00F803840E021C023C0238027804F018FFE0F000F000E000E000E0
+00E000E002E0026004701830600F800F157A9416>I<00003E0000470000CF00018F0001860003
+80000380000380000700000700000700000700000700000E0000FFF0000E00000E00000E00001C
+00001C00001C00001C00001C000038000038000038000038000038000070000070000070000070
+0000700000E00000E00000E00000E00000C00001C00001C000718000F18000F300006200003C00
+00182D82A20F>I<001F180030B800E0B801C07001C0700380700780700700E00F00E00F00E00F
+00E01E01C01E01C01E01C01E01C01E03800E03800E0780060B8006170001E70000070000070000
+0E00000E00000E00701C00F01800F0300060E0003F8000151F7E9416>I<00F0000FE00000E000
+00E00000E00001C00001C00001C00001C000038000038000038000038000070000071F00072180
+07C0C00F00E00F00E00E00E00E00E01C01C01C01C01C01C01C01C0380380380380380380380704
+700708700E08700E10700610E006206003C016237DA219>I<00C001E001C001C0000000000000
+000000000000000000001C002300430043008700870087000E000E001C001C001C003800380038
+40708070807080710032001C000B217BA00F>I<00F0000FE00000E00000E00000E00001C00001
+C00001C00001C0000380000380000380000380000700000701E0070210070C700E10F00E10F00E
+20600E40001D80001E00001FC0001C7000383800383800381C00381C2070384070384070384070
+1880E01880600F0014237DA216>107 D<01E01FC001C001C001C0038003800380038007000700
+070007000E000E000E000E001C001C001C001C0038003800380038007000700070007100E200E2
+00E200E200640038000B237CA20C>I<1C0F80F8002610C10C0047606606008780780700878078
+0700870070070087007007000E00E00E000E00E00E000E00E00E000E00E00E001C01C01C001C01
+C01C001C01C01C001C01C038203803803840380380704038038070803803803080700700310030
+03001E0023157B9428>I<1C0F002631C04740C08780E08780E08700E08700E00E01C00E01C00E
+01C00E01C01C03801C03801C03801C0704380708380E08380E103806107006203003C016157B94
+1B>I<007E0001C3000381800701C00E01C01C01E03C01E03801E07801E07801E07801E0F003C0
+F003C0F00380F00780700700700E00700C0030180018700007C00013157B9419>I<01C1F00262
+1804741C08780C08700E08700E08701E00E01E00E01E00E01E00E01E01C03C01C03C01C03C01C0
+7803807003807003C0E003C1C0072380071E000700000700000E00000E00000E00000E00001C00
+001C00001C0000FFC000171F7F9419>I<00F8400184C00705C00E03800E03801C03803C038038
+0700780700780700780700F00E00F00E00F00E00F00E00F01C00701C00703C00305C0030B8000F
+380000380000380000700000700000700000700000E00000E00000E0000FFE00121F7B9416>I<
+1C1F002620804741C08783C08703C08701808700000E00000E00000E00000E00001C00001C0000
+1C00001C000038000038000038000038000070000030000012157B9415>I<00FC000183000200
+800401800C03800C03000C00000F00000FF00007FC0003FE00003E00000F00000700700700F006
+00F00600E004004008002030001FC00011157D9414>I<00C001C001C001C001C0038003800380
+03800700FFF8070007000E000E000E000E001C001C001C001C0038003800380038107020702070
+40708031001E000D1F7C9E10>I<1E00602300E04380E04381C08381C08701C08701C00703800E
+03800E03800E03801C07001C07001C07001C07081C0E10180E101C0E101C1E200C262007C3C015
+157B941A>I<1E03802307C04387C04383C08381C08700C08700C00700800E00800E00800E0080
+1C01001C01001C01001C02001C02001C04001C08001C08000C300003C00012157B9416>I<1E00
+60E02300E1F04380E1F04381C0F08381C0708701C0308701C030070380200E0380200E0380200E
+0380201C0700401C0700401C0700401C0700801C0700801C0701001C0F01000C0F020006138C00
+03E0F0001C157B9420>I<1E00302300704380704380E08380E08700E08700E00701C00E01C00E
+01C00E01C01C03801C03801C03801C03801C07001C07001C07001C0F000C3E0003CE00000E0000
+0E00001C00601C00F03800F03000E0600080C0004380003E0000141F7B9418>121
+D<01E02003F06007F8C0041F800801000802000004000008000010000020000040000080000100
+000200000400800801001003003F060061FC0040F80080700013157D9414>I<FFFFFC16017C8C
+19>I E /Fb 15 119 df<40E04003037D8209>58 D<01F90607080310021002100018000F8003
+F0003800080008400840084010E0609F8010117D9013>83 D<072018E0306060606060C0C0C0C0
+C0C841C862D03C700D0B7E8A11>97 D<780018001800300030003000370078C0604060606060C0
+C0C0C0C0C0418063003C000B117E900E>I<007800180018003000300030073018E03060606060
+60C0C0C0C0C0C841C862D03C700D117E9010>100 D<07801840304060407F80C000C000C00040
+2020C01F000B0B7E8A0F>I<040C0000000000705898983030606464683006127E910B>105
+D<71F1F09A1A189C1C18981818181818303030303030303032303062606064606038170B7E8A1B
+>109 D<71F09A189C18981818183030303030323062606460380F0B7E8A13>I<07C01820303060
+106018C030C030C020406021801F000D0B7E8A0F>I<1C70278C2604260606060C0C0C0C0C0C0C
+181E3019C01800180030003000FC000F10808A10>I<73C09C2098609800180030003000300030
+00600060000B0B7E8A0E>114 D<0F001080218020003E001F0001808080C00083007C00090B7D
+8A0F>I<381048308C309830183030603060306430E431E80E380E0B7E8A12>117
+D<386048608C2098201820304030403040308011000E000B0B7E8A10>I
+E /Fc 1 49 df<060F0F0E1E1E1C3C383830707060E0C04008117F910A>48
+D E /Fd 17 120 df<60F0F06004047D830A>58 D<0008001800300030003000600060006000C0
+00C000C0018001800180030003000600060006000C000C000C0018001800180030003000300060
+0060006000C000C0000D217E9812>61 D<07FE03F800E001C000E0010000E0020000E0080001C0
+100001C0200001C0800001C1000003830000038F00000393800003A380000781C0000701C00007
+00E0000700E0000E0070000E0070000E0038000E0038001C003C00FF80FF001D177F961E>75
+D<003E1000C1A00100E00200600600600C00400C00400E00000F000007E00007FC0001FE00003F
+00000780000380000380200180400300400300600600600400D8180087E00014177E9615>83
+D<7C0018001800180018003000300030003000678068C070406060C060C060C060C06080C080C0
+8180C10046003C000B177E960F>98 D<003E000C000C000C000C0018001800180018073018F030
+7060706060C060C060C06080C080C480C4C1C446C838700F177E9612>100
+D<07C01C20301060106020FFC0C000C000C000C000C010402060C01F000C0E7E8D10>I<1F0006
+000600060006000C000C000C000C0018F01B181C08180838183018301830306030603160616062
+C022C03C10177E9614>104 D<0300038003000000000000000000000000001C00240046004600
+8C000C0018001800180031003100320032001C0009177F960C>I<383C0044C600470200460200
+8E06000C06000C06000C0C00180C00180C40181840181880300880300F00120E7F8D15>110
+D<07C00C20101020186018C018C018C01880308030C060C0C061803E000D0E7E8D11>I<1C3C22
+462382230346030603060306030C060C060C0C0C081A3019E018001800300030003000FC001014
+808D12>I<38F04518463846308C000C000C000C001800180018001800300030000D0E7F8D10>
+114 D<030003000600060006000600FFC00C000C000C0018001800180018003000308030803100
+31001E000A147F930D>116 D<1C0200260600460600460600860C000C0C000C0C000C0C001818
+001818801818801838800C5900078E00110E7F8D14>I<1C04260E4606460686040C040C040C04
+18081808181018100C6007800F0E7F8D11>I<1C020426060E460606460606860C040C0C040C0C
+040C0C041818081818081818100818100C2C2003C7C0170E7F8D19>I E
+/Fe 3 67 df<1F00618040C08060C0600060006000C00180030006000C00102020207FC0FFC00B
+107F8F0F>50 D<00C00000C00000C000016000016000023000023000023000041800041800080C
+000FFC00080C00100600100600300700FC1FC012117F9016>65 D<FFF8180C1806180318031803
+1806181C1FFC180618031803180318031806180EFFF810117F9015>I E
+/Ff 17 122 df<0038007800F001E003C007800F000E001C001C0038003800700070007000E000
+E000E000E000E000E000E000E000E000E000700070007000380038001C001C000E000F00078003
+C001E000F8007800380D2878A21A>40 D<6000F00078003C001E000F000780038001C001C000E0
+00E0007000700070003800380038003800380038003800380038003800700070007000E000E001
+C001C0038007800F001E003C007800F00060000D287CA21A>I<FFFE00FFFF80FFFFC01C03E01C
+00E01C00F01C00701C00701C00701C00701C00E01C01E01C07C01FFF801FFF801FFFC01C01E01C
+00F01C00701C00381C00381C00381C00381C00381C00781C00F01C01F0FFFFE0FFFFC0FFFF0015
+1E7E9D1A>66 D<1FF0003FFC007FFE00780F00300700000380000380007F8007FF801FFF803F83
+80780380700380E00380E00380E00380700780780F803FFFFC1FFDFC07F0FC16157D941A>97
+D<FE0000FE0000FE00000E00000E00000E00000E00000E00000E00000E3E000EFF800FFFE00FC1
+F00F80700F00380E00380E001C0E001C0E001C0E001C0E001C0E001C0E001C0F00380F00780F80
+F00FC1E00FFFC00EFF80063E00161E7F9D1A>I<001FC0001FC0001FC00001C00001C00001C000
+01C00001C00001C001F1C007FDC00FFFC01E0FC03C07C07803C07001C0E001C0E001C0E001C0E0
+01C0E001C0E001C0E001C07003C07003C03807C03E0FC01FFFFC07FDFC01F1FC161E7E9D1A>
+100 D<01F80007FF000FFF801E07C03C01C07800E07000E0E00070E00070FFFFF0FFFFF0FFFFF0
+E000007000007000007800703C00701F01F00FFFE003FFC000FE0014157D941A>I<01F87C07FF
+FE0FFFFE1E078C1C03803801C03801C03801C03801C03801C01C03801E07801FFF001FFE0039F8
+003800003800001C00001FFF801FFFE03FFFF878007C70001CE0000EE0000EE0000EE0000E7000
+1C78003C3E00F81FFFF007FFC001FF0017217F941A>103 D<FE0000FE0000FE00000E00000E00
+000E00000E00000E00000E00000E3E000EFF800FFFC00FC1C00F80E00F00E00E00E00E00E00E00
+E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E0FFE3FEFFE7FEFFE3FE171E
+7F9D1A>I<7CE0E000FFFBF8007FFFF8001F1F1C001E1E1C001E1E1C001C1C1C001C1C1C001C1C
+1C001C1C1C001C1C1C001C1C1C001C1C1C001C1C1C001C1C1C001C1C1C001C1C1C001C1C1C007F
+1F1F00FF9F9F807F1F1F00191580941A>109 D<FE3E00FEFF80FFFFC00FC1C00F80E00F00E00E
+00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E0FFE3FEFF
+E7FEFFE3FE17157F941A>I<01F00007FC001FFF003E0F803C07807803C07001C0E000E0E000E0
+E000E0E000E0E000E0E000E0F001E07001C07803C03C07803E0F801FFF0007FC0001F00013157D
+941A>I<FE3E00FEFF80FFFFE00FC1F00F80700F00380E00380E001C0E001C0E001C0E001C0E00
+1C0E001C0E001C0F00380F00780F80F00FC1E00FFFC00EFF800E3E000E00000E00000E00000E00
+000E00000E00000E00000E0000FFE000FFE000FFE00016207F941A>I<7F83F0FF8FF87FBFFC03
+FC3C03F01803E00003C00003C00003800003800003800003800003800003800003800003800003
+80000380007FFF00FFFF007FFF0016157E941A>114 D<07FB801FFF807FFF80780780E00380E0
+0380E003807800007FC0003FFC0007FE00003F800007806001C0E001C0E001C0F003C0FC0780FF
+FF00EFFE00E3F80012157C941A>I<00C00001C00001C00001C00001C00001C00001C0007FFFE0
+FFFFE0FFFFE001C00001C00001C00001C00001C00001C00001C00001C00001C00001C00001C070
+01C07001C07001C07000E0E000FFE0007FC0001F00141C7F9B1A>I<7FC3FCFFC7FE7FC3FC0E00
+E00E00E00700E00701C00781C00381C003838003C38001C38001C70000E70000E70000E6000066
+00006E00003C00003C00003C0000380000380000380000700000700030700078E00071E0007FC0
+003F80001E000017207F941A>121 D E /Fg 10 115 df<FFE0FFE00B027D8B10>45
+D<0000040000000006000000000E000000001E000000001E000000003E000000003F000000004F
+000000004F000000008F000000008F000000010F00000001078000000207800000020780000004
+0780000004078000000807C000000803C000001003C000001003C000002003C000003FFFE00000
+4001E000004001E000008001E000008001E000010001E000010000F000020000F000060000F000
+040000F0000C0000F0003E0001F800FF800FFF8021237EA225>65 D<00FF000381C00603C00C03
+C01C0180380000780000700000F00000F00000F00000F00000F00000E00000F00000F000807001
+007001003806001C180007E00012157C9416>99 D<00FE000383800701C00C00E01C00E03800E0
+7800E07000E0FFFFE0F00000F00000F00000F00000E00000E00000F00040700080300080180300
+0E0C0003F00013157D9416>101 D<00000780001F88800070D18000E0E18001C0700003C07000
+03C070000780F0000780F0000780F0000780E0000381E0000181C00002C30000027E0000040000
+0004000000040000000600000007FF800007FFE00007FFF0001C00780030001800600018006000
+1800C0001800C0001800C0003000600060003000C0001C07800003FC00001921809518>103
+D<007000F001F000F000E00000000000000000000000000000000001C00FC001C001C001C001C0
+0380038003800380038003800700070007000700070007000E000F00FFE00C227FA10E>105
+D<007803F800700070007000700070007000E000E000E000E000E000E001C001C001C001C001C0
+01C00380038003800380038003800700070007000700070007000E000F00FFE00D237FA20E>
+108 D<01C3F01FCC1801D00C01E00E01E00E01C00E03C01C03801C03801C03801C03801C03801C
+0700380700380700380700380700380700380E00700F0078FFE7FF18157F941B>110
+D<007E000383800600C00C00E01C0070380070780078700078F00078F00078F00078F00078E000
+F0E000F0E000E0F001E07001C07003803807001C1C0007F00015157D9418>I<01C7C01FC8E001
+D1E001E1E001E0C001C00003C00003800003800003800003800003800007000007000007000007
+00000700000700000E00000F0000FFF00013157F9413>114 D E /Fh 16
+127 df<F0F0F0F004047B830E>46 D<0000800001800001800003000003000003000006000006
+00000600000C00000C00000C000018000018000018000030000030000030000060000060000060
+0000C00000C00000C0000180000180000180000180000300000300000300000600000600000600
+000C00000C00000C0000180000180000180000300000300000300000600000600000600000C000
+00C00000C0000011317DA418>I<001F0000001F0000003F8000003F8000003B8000007BC00000
+73C0000071C00000F1E00000F1E00000E0E00001E0F00001E0F00001C0F00003C0780003C07800
+0380780007803C0007803C0007003C000F001E000F001E000FFFFE001FFFFF001FFFFF001C000F
+003C0007803C00078038000780780003C0780003C0700003C0F00001E0F00001E0E00001E01B23
+7EA220>65 D<01FC0007FF000FFF801F03803C0180780000780000700000F00000F00000F00000
+F00000F00000F000007800007800007800003C00401F03C00FFFC007FF8001FC0012167E9516>
+99 D<0003C00003C00003C00003C00003C00003C00003C00003C00003C00003C00003C00003C0
+0003C003E3C00FFBC01FFFC03F0FC03C07C07803C07803C0F003C0F003C0F003C0F003C0F003C0
+F003C0F003C0F003C07803C07803C03C07C03E0FC01FFFC00FFBC003E3C012237EA219>I<03F0
+0007FC001FFE003E0F003C0780780380780380F001C0FFFFC0FFFFC0FFFFC0F00000F00000F000
+007000007800007800003C00801F07800FFF8007FF0001F80012167E9516>I<01F07807FFF80F
+FFF81F1F001E0F003C07803C07803C07803C07803C07801E0F001F1F000FFE001FFC0019F00038
+00003800003C00001FFE001FFFC01FFFE03FFFF07801F07800F8F00078F00078F00078F0007878
+00F03E03E01FFFC00FFF8001FC0015217F9518>103 D<F000F000F000F000F000F000F000F000
+F000F000F000F000F000F1F8F3FCF7FEFE1EF80FF80FF00FF00FF00FF00FF00FF00FF00FF00FF0
+0FF00FF00FF00FF00FF00FF00FF00F10237CA219>I<F0F0F0F0000000000000000000F0F0F0F0
+F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F004237DA20B>I<F0F0F0F0F0F0F0F0F0F0F0F0F0F0
+F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F004237DA20B>108 D<F1F8F3FCF7FEFE1EF8
+0FF80FF00FF00FF00FF00FF00FF00FF00FF00FF00FF00FF00FF00FF00FF00FF00FF00F10167C95
+19>110 D<01FC0007FF000FFF801F07C03C01E07800F07800F0700070F00078F00078F00078F0
+0078F00078F000787800F07800F07C01F03E03E01F07C00FFF8007FF0001FC0015167F9518>I<
+F0E0F3E0F7E0FF00FE00FC00F800F800F000F000F000F000F000F000F000F000F000F000F000F0
+00F000F0000B167C9511>114 D<07F01FFC3FFE3C0E7806780078007C003F003FF01FF80FFC01
+FE001F000F000F000FC00FF81EFFFE3FFC0FF010167F9513>I<0F000F000F000F000F000F00FF
+F8FFF8FFF80F000F000F000F000F000F000F000F000F000F000F000F000F000F000F080F1C07FC
+07F803E00E1C7F9B12>I<1C0E3F0E7F8EE3FCE1F8E0700F067CA118>126
+D E /Fi 1 124 df<FFFFFFE0FFFFFFE01B02808E1C>123 D E /Fj 4 107
+df<03F0000FFC001FFE003FFF007FFF807FFF80FFFFC0FFFFC0FFFFC0FFFFC0FFFFC0FFFFC0FF
+FFC0FFFFC07FFF807FFF803FFF001FFE000FFC0003F00012147D9519>15
+D<000000006000000000003000000000003000000000001800000000001800000000000C000000
+00000600000000000380FFFFFFFFFFE0FFFFFFFFFFC0000000000380000000000600000000000C
+000000000018000000000018000000000030000000000030000000000060002B127D9432>33
+D<001FFF007FFF01E0000380000600000C0000180000300000300000600000600000600000C000
+00C00000FFFFFFFFFFFFC00000C000006000006000006000003000003000001800000C00000600
+0003800001E000007FFF001FFF181E7C9A21>50 D<C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0
+C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C002317AA40E>106
+D E /Fk 68 124 df<007E0001C1800301800703C00E03C00E01800E00000E00000E00000E0000
+0E0000FFFFC00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C0
+0E01C00E01C00E01C00E01C00E01C07F87F8151D809C17>12 D<6060F0F0F8F868680808080808
+08101010102020404080800D0C7F9C15>34 D<00E0000001900000030800000308000007080000
+0708000007080000070800000710000007100000072000000740000003C03FE003800F00038006
+000380040005C0040009C0080010E0100030E010006070200060702000E0384000E03C4000E01C
+8000E00F0020E0070020700780403009C0401830E18007C03E001B1F7E9D20>38
+D<004000800100020006000C000C0018001800300030007000600060006000E000E000E000E000
+E000E000E000E000E000E000E000E000600060006000700030003000180018000C000C00060002
+000100008000400A2A7D9E10>40 D<800040002000100018000C000C0006000600030003000380
+01800180018001C001C001C001C001C001C001C001C001C001C001C001C0018001800180038003
+000300060006000C000C00180010002000400080000A2A7E9E10>I<01800180018001804182F1
+8F399C0FF003C003C00FF0399CF18F4182018001800180018010127E9E15>I<60F0F070101010
+1020204080040C7C830C>44 D<FFE0FFE00B0280890E>I<60F0F06004047C830C>I<0001000300
+0600060006000C000C000C0018001800180030003000300060006000C000C000C0018001800180
+030003000300060006000C000C000C00180018001800300030003000600060006000C000C00010
+297E9E15>I<03C00C301818300C300C700E60066006E007E007E007E007E007E007E007E007E0
+07E007E007E007E00760066006700E300C300C18180C3007E0101D7E9B15>I<030007003F00C7
+000700070007000700070007000700070007000700070007000700070007000700070007000700
+0700070007000F80FFF80D1C7C9B15>I<07C01830201C400C400EF00FF80FF807F8077007000F
+000E000E001C001C00380070006000C00180030006010C01180110023FFE7FFEFFFE101C7E9B15
+>I<07E01830201C201C781E780E781E381E001C001C00180030006007E00030001C001C000E00
+0F000F700FF80FF80FF80FF00E401C201C183007E0101D7E9B15>I<000C00000C00001C00003C
+00003C00005C0000DC00009C00011C00031C00021C00041C000C1C00081C00101C00301C00201C
+00401C00C01C00FFFFC0001C00001C00001C00001C00001C00001C00001C0001FFC0121C7F9B15
+>I<300C3FF83FF03FC020002000200020002000200023E024302818301C200E000E000F000F00
+0F600FF00FF00FF00F800E401E401C2038187007C0101D7E9B15>I<00F0030C06040C0E181E30
+1E300C700070006000E3E0E430E818F00CF00EE006E007E007E007E007E007600760077006300E
+300C18180C3003E0101D7E9B15>I<4000007FFF807FFF007FFF00400200800400800400800800
+00100000100000200000600000400000C00000C00001C000018000018000038000038000038000
+038000078000078000078000078000078000078000030000111D7E9B15>I<03E00C301008200C
+20066006600660067006780C3E083FB01FE007F007F818FC307E601E600FC007C003C003C003C0
+0360026004300C1C1007E0101D7E9B15>I<03C00C301818300C700C600EE006E006E007E007E0
+07E007E0076007700F300F18170C2707C700060006000E300C780C78187010203030C00F80101D
+7E9B15>I<7FFFFFC0FFFFFFE00000000000000000000000000000000000000000000000000000
+000000000000FFFFFFE07FFFFFC01B0C7E8F20>61 D<000600000006000000060000000F000000
+0F0000000F00000017800000178000001780000023C0000023C0000023C0000041E0000041E000
+0041E0000080F0000080F0000180F8000100780001FFF80003007C0002003C0002003C0006003E
+0004001E0004001E000C001F001E001F00FF80FFF01C1D7F9C1F>65 D<FFFFC00F00F00F00380F
+003C0F001C0F001E0F001E0F001E0F001E0F001C0F003C0F00780F01F00FFFE00F00780F003C0F
+001E0F000E0F000F0F000F0F000F0F000F0F000F0F001E0F001E0F003C0F0078FFFFE0181C7E9B
+1D>I<001F808000E0618001801980070007800E0003801C0003801C0001803800018078000080
+7800008070000080F0000000F0000000F0000000F0000000F0000000F0000000F0000000F00000
+00700000807800008078000080380000801C0001001C0001000E000200070004000180080000E0
+3000001FC000191E7E9C1E>I<FFFFC0000F00F0000F003C000F000E000F0007000F0007000F00
+03800F0003C00F0001C00F0001C00F0001E00F0001E00F0001E00F0001E00F0001E00F0001E00F
+0001E00F0001E00F0001C00F0001C00F0003C00F0003800F0007800F0007000F000E000F001C00
+0F007000FFFFC0001B1C7E9B20>I<FFFFFC0F003C0F000C0F00040F00040F00060F00020F0002
+0F02020F02000F02000F02000F06000FFE000F06000F02000F02000F02000F02010F00010F0002
+0F00020F00020F00060F00060F000C0F003CFFFFFC181C7E9B1C>I<FFFFF80F00780F00180F00
+080F00080F000C0F00040F00040F02040F02000F02000F02000F06000FFE000F06000F02000F02
+000F02000F02000F00000F00000F00000F00000F00000F00000F00000F8000FFF800161C7E9B1B
+>I<FFF00F000F000F000F000F000F000F000F000F000F000F000F000F000F000F000F000F000F
+000F000F000F000F000F000F000F000F00FFF00C1C7F9B0F>73 D<FFF8000F80000F00000F0000
+0F00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F0000
+0F00000F00080F00080F00080F00180F00180F00100F00300F00700F01F0FFFFF0151C7E9B1A>
+76 D<FF8000FF800F8000F8000F8000F8000BC00178000BC00178000BC001780009E002780009
+E002780008F004780008F004780008F0047800087808780008780878000878087800083C107800
+083C107800083C107800081E207800081E207800081E207800080F407800080F40780008078078
+000807807800080780780008030078001C03007800FF8307FF80211C7E9B26>I<FF007FC00F80
+0E000F8004000BC0040009E0040009E0040008F0040008F8040008780400083C0400083C040008
+1E0400080F0400080F0400080784000807C4000803C4000801E4000801E4000800F40008007C00
+08007C0008003C0008003C0008001C0008000C001C000C00FF8004001A1C7E9B1F>I<003F8000
+00E0E0000380380007001C000E000E001C0007003C00078038000380780003C0780003C0700001
+C0F00001E0F00001E0F00001E0F00001E0F00001E0F00001E0F00001E0F00001E0700001C07800
+03C0780003C0380003803C0007801C0007000E000E0007001C000380380000E0E000003F80001B
+1E7E9C20>I<FFFF800F00E00F00780F003C0F001C0F001E0F001E0F001E0F001E0F001E0F001C
+0F003C0F00780F00E00FFF800F00000F00000F00000F00000F00000F00000F00000F00000F0000
+0F00000F00000F0000FFF000171C7E9B1C>I<FFFF00000F01E0000F0078000F003C000F001C00
+0F001E000F001E000F001E000F001E000F001C000F003C000F0078000F01E0000FFF00000F03C0
+000F00E0000F00F0000F0078000F0078000F0078000F0078000F0078000F0078000F0078100F00
+78100F0038100F003C20FFF01C20000007C01C1D7E9B1F>82 D<07E0801C198030058070038060
+0180E00180E00080E00080E00080F00000F800007C00007FC0003FF8001FFE0007FF0000FF8000
+0F800007C00003C00001C08001C08001C08001C0C00180C00180E00300D00200CC0C0083F80012
+1E7E9C17>I<7FFFFFC0700F01C0600F00C0400F0040400F0040C00F0020800F0020800F002080
+0F0020000F0000000F0000000F0000000F0000000F0000000F0000000F0000000F0000000F0000
+000F0000000F0000000F0000000F0000000F0000000F0000000F0000000F0000001F800003FFFC
+001B1C7F9B1E>I<FFF07FC00F000E000F0004000F0004000F0004000F0004000F0004000F0004
+000F0004000F0004000F0004000F0004000F0004000F0004000F0004000F0004000F0004000F00
+04000F0004000F0004000F0004000F0004000700080007800800038010000180100000C0200000
+70C000001F00001A1D7E9B1F>I<FFE0FFE0FF1F001F003C1E001E00180F001F00100F001F0010
+0F001F001007801F00200780278020078027802003C027804003C043C04003C043C04003E043C0
+4001E081E08001E081E08001E081E08000F100F10000F100F10000F100F100007900FA00007A00
+7A00007A007A00003E007C00003C003C00003C003C00003C003C00001800180000180018000018
+001800281D7F9B2B>87 D<7FF0FFC00FC03E000780180003C0180003E0100001E0200001F06000
+00F0400000788000007D8000003D0000001E0000001F0000000F0000000F8000000F80000013C0
+000023E0000021E0000041F00000C0F8000080780001007C0003003C0002001E0006001F001F00
+3F80FFC0FFF01C1C7F9B1F>I<FEFEC0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0
+C0C0C0C0C0C0C0C0C0C0C0C0C0FEFE07297C9E0C>91 D<08081010202040404040808080808080
+B0B0F8F8787830300D0C7A9C15>I<FEFE06060606060606060606060606060606060606060606
+060606060606060606060606060606FEFE0729809E0C>I<1FC000307000783800781C00301C00
+001C00001C0001FC000F1C00381C00701C00601C00E01C40E01C40E01C40603C40304E801F8700
+12127E9115>97 D<FC00001C00001C00001C00001C00001C00001C00001C00001C00001C00001C
+00001C7C001D86001E03001C01801C01C01C00C01C00E01C00E01C00E01C00E01C00E01C00E01C
+00C01C01C01C01801E030019060010F800131D7F9C17>I<07E00C301878307870306000E000E0
+00E000E000E000E00060007004300418080C3007C00E127E9112>I<003F000007000007000007
+0000070000070000070000070000070000070000070003E7000C1700180F003007007007006007
+00E00700E00700E00700E00700E00700E00700600700700700300700180F000C370007C7E0131D
+7E9C17>I<03E00C301818300C700E6006E006FFFEE000E000E000E00060007002300218040C18
+03E00F127F9112>I<00F8018C071E061E0E0C0E000E000E000E000E000E00FFE00E000E000E00
+0E000E000E000E000E000E000E000E000E000E000E000E000E007FE00F1D809C0D>I<00038003
+C4C00C38C01C3880181800381C00381C00381C00381C001818001C38000C300013C00010000030
+00001800001FF8001FFF001FFF803003806001C0C000C0C000C0C000C06001803003001C0E0007
+F800121C7F9215>I<FC00001C00001C00001C00001C00001C00001C00001C00001C00001C0000
+1C00001C7C001C87001D03001E03801C03801C03801C03801C03801C03801C03801C03801C0380
+1C03801C03801C03801C03801C0380FF9FF0141D7F9C17>I<18003C003C001800000000000000
+0000000000000000FC001C001C001C001C001C001C001C001C001C001C001C001C001C001C001C
+001C00FF80091D7F9C0C>I<00C001E001E000C000000000000000000000000000000FE000E000
+E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E060E0
+F0C0F1C061803E000B25839C0D>I<FC00001C00001C00001C00001C00001C00001C00001C0000
+1C00001C00001C00001C3FC01C0F001C0C001C08001C10001C20001C40001CE0001DE0001E7000
+1C78001C38001C3C001C1C001C0E001C0F001C0F80FF9FE0131D7F9C16>I<FC001C001C001C00
+1C001C001C001C001C001C001C001C001C001C001C001C001C001C001C001C001C001C001C001C
+001C001C001C001C00FF80091D7F9C0C>I<FC7E07E0001C838838001D019018001E01E01C001C
+01C01C001C01C01C001C01C01C001C01C01C001C01C01C001C01C01C001C01C01C001C01C01C00
+1C01C01C001C01C01C001C01C01C001C01C01C001C01C01C00FF8FF8FF8021127F9124>I<FC7C
+001C87001D03001E03801C03801C03801C03801C03801C03801C03801C03801C03801C03801C03
+801C03801C03801C0380FF9FF014127F9117>I<03F0000E1C00180600300300700380600180E0
+01C0E001C0E001C0E001C0E001C0E001C06001807003803003001806000E1C0003F00012127F91
+15>I<FC7C001D86001E03001C01801C01C01C00C01C00E01C00E01C00E01C00E01C00E01C00E0
+1C01C01C01C01C01801E03001D06001CF8001C00001C00001C00001C00001C00001C00001C0000
+FF8000131A7F9117>I<03C1000C3300180B00300F00700700700700E00700E00700E00700E007
+00E00700E00700600700700700300F00180F000C370007C7000007000007000007000007000007
+00000700000700003FE0131A7E9116>I<FCE01D301E781E781C301C001C001C001C001C001C00
+1C001C001C001C001C001C00FFC00D127F9110>I<1F9030704030C010C010E010F8007F803FE0
+0FF000F880388018C018C018E010D0608FC00D127F9110>I<04000400040004000C000C001C00
+3C00FFE01C001C001C001C001C001C001C001C001C001C101C101C101C101C100C100E2003C00C
+1A7F9910>I<FC1F801C03801C03801C03801C03801C03801C03801C03801C03801C03801C0380
+1C03801C03801C03801C07800C07800E1B8003E3F014127F9117>I<FF07E03C03801C01001C01
+000E02000E020007040007040007040003880003880003D80001D00001D00000E00000E00000E0
+0000400013127F9116>I<FF3FCFE03C0F03801C0701801C0701001C0B01000E0B82000E0B8200
+0E1182000711C4000711C4000720C40003A0E80003A0E80003C0680001C0700001C07000018030
+00008020001B127F911E>I<7F8FF00F03800F030007020003840001C80001D80000F000007000
+00780000F800009C00010E00020E000607000403801E07C0FF0FF81512809116>I<FF07E03C03
+801C01001C01000E02000E020007040007040007040003880003880003D80001D00001D00000E0
+0000E00000E000004000004000008000008000F08000F10000F300006600003C0000131A7F9116
+>I<FFFFF01401808B15>123 D E /Fl 7 56 df<0C001C00EC000C000C000C000C000C000C000C
+000C000C000C000C000C000C000C000C00FFC00A137D9211>49 D<1F0060C06060F070F0306030
+00700070006000C001C00180020004000810101020207FE0FFE00C137E9211>I<0FC030707038
+703870380038003000E00FC0007000380018001C601CF01CF018E03860701FC00E137F9211>I<
+006000E000E00160026006600C600860106020606060C060FFFC0060006000600060006003FC0E
+137F9211>I<60607FC07F8044004000400040004F0070C040E0006000700070E070E070E06040
+E021C01F000C137E9211>I<07C00C201070207060006000C000CF00D0C0E060C020C030C030C0
+3040306020206010C00F000C137E9211>I<40007FFC7FF8401080108020004000800100010003
+000200060006000E000E000E000E000E0004000E147E9311>I E /Fm 19
+117 df<03000700FF000700070007000700070007000700070007000700070007000700070007
+00070007007FF00C157E9412>49 D<0F8030E040708030C038E0384038003800700070006000C0
+0180030006000C08080810183FF07FF0FFF00D157E9412>I<0FE030306018701C701C001C0018
+0038006007E000300018000C000E000EE00EE00EC00C401830300FE00F157F9412>I<00300030
+007000F001F001700270047008701870107020704070C070FFFE0070007000700070007003FE0F
+157F9412>I<20303FE03FC0240020002000200020002F8030E020700030003800384038E038E0
+388030406020C01F000D157E9412>I<01F00608080C181C301C70006000E000E3E0EC30F018F0
+0CE00EE00EE00E600E600E300C3018183007C00F157F9412>I<40007FFE7FFC7FF8C008801080
+200040008000800100010003000200060006000E000E000E000E000E0004000F167E9512>I<00
+1000003800003800003800005C00005C00005C00008E00008E00008E0001070001070003078002
+038002038007FFC00401C00401C00800E00800E01800E03800F0FE03FE17177F961A>65
+D<FFFE001C03801C00E01C00601C00701C00701C00701C00701C00E01C01C01FFF801FFFC01C00
+E01C00701C00301C00381C00381C00381C00381C00701C00E01C01C0FFFF0015177F9619>I<FF
+83FE1C00701C00701C00701C00701C00701C00701C00701C00701C00701C00701FFFF01C00701C
+00701C00701C00701C00701C00701C00701C00701C00701C0070FF83FE17177F961A>72
+D<1FC0386038301038003803F81E3830387038E039E039E07970FF1F1E100E7F8D12>97
+D<007E00000E00000E00000E00000E00000E00000E00000E00000E0007CE001C3E00300E00700E
+00600E00E00E00E00E00E00E00E00E00600E00700E00301E00182E0007CFC012177F9614>100
+D<FC00001C00001C00001C00001C00001C00001C00001C00001C00001C7C001D8E001E07001C07
+001C07001C07001C07001C07001C07001C07001C07001C07001C0700FF9FE01317809614>104
+D<183C3C1800000000007C1C1C1C1C1C1C1C1C1C1C1C1CFF081780960A>I<FC7C1F001D8E6380
+1E0781C01C0701C01C0701C01C0701C01C0701C01C0701C01C0701C01C0701C01C0701C01C0701
+C01C0701C0FF9FE7F81D0E808D1E>109 D<FC7C001D8E001E07001C07001C07001C07001C0700
+1C07001C07001C07001C07001C07001C0700FF9FE0130E808D14>I<07C018303018600C600CE0
+0EE00EE00EE00EE00E701C3018183007C00F0E7F8D12>I<1F4060C0C040C040E000FF007F801F
+C001E080608060C060E0C09F000B0E7F8D0E>115 D<080008000800180018003800FF80380038
+003800380038003800380038403840384038401C800F000A147F930E>I
+E /Fn 14 116 df<70F8F8F87005057C840E>58 D<70F8FCFC7404040404080810102040060F7C
+840E>I<0000001800000078000001E00000078000001E00000078000003E000000F8000003C00
+0000F0000003C000000F0000003C000000F0000000F00000003C0000000F00000003C0000000F0
+0000003C0000000F80000003E0000000780000001E0000000780000001E000000078000000181D
+1C7C9926>I<C0000000F00000003C0000000F00000003C0000000F00000003E0000000F800000
+01E0000000780000001E0000000780000001E00000007800000078000001E00000078000001E00
+000078000001E000000F8000003E000000F0000003C000000F0000003C000000F0000000C00000
+001D1C7C9926>62 D<007FFFF8000007801E0000078007000007800380000F0001C0000F0001C0
+000F0000E0000F0000E0001E0000E0001E0000F0001E0000F0001E0000F0003C0000F0003C0000
+F0003C0000F0003C0000F000780001E000780001E000780001E000780001E000F00003C000F000
+03C000F000038000F000078001E000070001E0000E0001E0001E0001E0001C0003C000380003C0
+00700003C000E00003C003800007C00E0000FFFFF8000024227EA128>68
+D<007FFFFFC000078003C000078000C000078000C0000F0000C0000F0000C0000F000080000F00
+0080001E000080001E000080001E008080001E008000003C010000003C010000003C030000003C
+070000007FFE000000780600000078060000007806000000F004000000F004000000F004010000
+F000020001E000020001E000020001E000040001E0000C0003C000080003C000180003C0003000
+03C000700007C003F000FFFFFFE00022227EA124>I<007FFC01FF000780007800078000600007
+8000C0000F000180000F000200000F000400000F000800001E001000001E004000001E00800000
+1E010000003C020000003C040000003C1E0000003C3E000000785F000000788F0000007A0F0000
+007C07800000F807800000F007C00000F003C00000F003C00001E001E00001E001E00001E001E0
+0001E000F00003C000F00003C000F80003C000780003C000780007C000FC00FFFC07FF8028227E
+A129>75 D<007FFE000007C0000007800000078000000F0000000F0000000F0000000F0000001E
+0000001E0000001E0000001E0000003C0000003C0000003C0000003C0000007800000078000000
+7800000078000000F0000000F0000000F0001000F0001001E0002001E0002001E0004001E00040
+03C000C003C0008003C0018003C0078007C01F00FFFFFF001C227EA121>I<007FC00001FF0007
+C00003E00007C00005E00007C00005E00009E0000BC00009E0000BC00009E00013C00009E00023
+C00011E00027800011E00047800011E00047800011E00087800021E0010F000020F0010F000020
+F0020F000020F0040F000040F0041E000040F0081E000040F0081E000040F0101E000080F0203C
+00008078203C00008078403C00008078803C000100788078000100790078000100790078000100
+7A00780002007C00F00002007C00F00002003800F00006003800F0000F003001F000FFE0203FFF
+0030227EA12F>I<00786001C4E00302E00601C00E01C01C01C03C01C038038078038078038078
+0380F00700F00700F00700F00708F00E10700E10701E1030262018C6200F01C015157E941A>97
+D<003F0000E0800380C00701C00E03C01C03C03C00003C0000780000780000780000F00000F000
+00F00000F000007000407000403001803802001C1C0007E00012157E9415>99
+D<00F0000FE00000E00000E00000E00001C00001C00001C00001C0000380000380000380000380
+00070000071F0007218007C0C00F00E00F00E00E00E00E00E01C01C01C01C01C01C01C01C03803
+80380380380700380704700708700E08700E08700610E006206003C016237DA21C>104
+D<3C07E01F00461830618047201880C087401D00E087801E00E087801C00E087001C00E00E0038
+01C00E003801C00E003801C00E003801C01C007003801C007003801C007007001C007007043800
+E007083800E00E083800E00E083800E006107001C006203000C003C026157E942B>109
+D<007E0000810003008002018006038006030006000007000007F80003FE0001FF00003F000007
+80000380700380F00300F00300E002004004003018000FE00011157E9417>115
+D E /Fo 89 128 df<001F83E000706E3000C07C780180F8780380F07807007000070070000700
+7000070070000700700007007000070070000700700007007000FFFFFFC0070070000700700007
+007000070070000700700007007000070070000700700007007000070070000700700007007000
+070070000700700007007000070070000700700007007000070078007FE3FF801D2380A21C>11
+D<001FC0000070200000C010000180380003807800070078000700300007000000070000000700
+000007000000070000000700000007000000FFFFF8000700780007003800070038000700380007
+003800070038000700380007003800070038000700380007003800070038000700380007003800
+07003800070038000700380007003800070038007FE1FF80192380A21B>I<001FD80000703800
+00C078000180780003807800070038000700380007003800070038000700380007003800070038
+000700380007003800FFFFF8000700380007003800070038000700380007003800070038000700
+380007003800070038000700380007003800070038000700380007003800070038000700380007
+00380007003800070038007FF3FF80192380A21B>I<000FC07F00007031C08000E00B00400180
+1E00E003803E01E007003C01E007001C00C007001C000007001C000007001C000007001C000007
+001C000007001C000007001C0000FFFFFFFFE007001C01E007001C00E007001C00E007001C00E0
+07001C00E007001C00E007001C00E007001C00E007001C00E007001C00E007001C00E007001C00
+E007001C00E007001C00E007001C00E007001C00E007001C00E007001C00E007001C00E07FF1FF
+CFFE272380A229>I<00004000008000008000010000010001F200060E001C0700380780300980
+7009C06010C0E030E0E020E0E060E0E040E0E0C0E0E080E0E180E06100C07201C03201803C0380
+1C07000E0C0009F000100000100000200000200000400000131F7E9918>28
+D<70F8F8F8F8F8F8F8707070707070707070707070202020202020000000000070F8F8F8700524
+7CA30E>33 D<7038F87CFC7EFC7E743A04020402040204020804080410081008201040200F0F7E
+A218>I<003C000000006200000000C20000000181000000018100000003810000000381000000
+03810000000381000000038200000003820000000384000000038800000001C800000001D00000
+0001E003FF8001C0007C0000E000380001E000300001F000200002700040000470004000083800
+8000183C008000301C010000701E020000700E020000F007040000F007880000F003880000F001
+D00100F000E0010078007003003800B802003C031C04000E0C0E0C0003F003F00021257EA326>
+38 D<70F8FCFC7404040404080810102040060F7CA20E>I<00200040008001000300060004000C
+000C00180018003000300030007000600060006000E000E000E000E000E000E000E000E000E000
+E000E000E000E000E0006000600060007000300030003000180018000C000C0004000600030001
+000080004000200B327CA413>I<800040002000100018000C0004000600060003000300018001
+80018001C000C000C000C000E000E000E000E000E000E000E000E000E000E000E000E000E000E0
+00C000C000C001C0018001800180030003000600060004000C00180010002000400080000B327D
+A413>I<70F8FCFC7404040404080810102040060F7C840E>44 D<FFE0FFE00B027F8B10>I<70F8
+F8F87005057C840E>I<000080000180000180000300000300000300000600000600000600000C
+00000C00000C0000180000180000180000300000300000300000600000600000600000C00000C0
+0000C0000180000180000180000180000300000300000300000600000600000600000C00000C00
+000C0000180000180000180000300000300000300000600000600000600000C00000C00000C000
+0011317DA418>I<01F000071C000C06001803003803803803807001C07001C07001C07001C0F0
+01E0F001E0F001E0F001E0F001E0F001E0F001E0F001E0F001E0F001E0F001E0F001E0F001E0F0
+01E07001C07001C07001C07803C03803803803801C07000C0600071C0001F00013227EA018>I<
+008003800F80F38003800380038003800380038003800380038003800380038003800380038003
+800380038003800380038003800380038003800380038007C0FFFE0F217CA018>I<03F0000C1C
+001007002007804003C04003C08003E0F003E0F801E0F801E0F801E02003E00003E00003C00003
+C0000780000700000E00001C0000180000300000600000C0000180000100000200200400200800
+201800603000403FFFC07FFFC0FFFFC013217EA018>I<03F8000C1E001007002007804007C078
+07C07803C07807C03807C0000780000780000700000F00000E0000380003F000001C00000F0000
+07800007800003C00003C00003E02003E07003E0F803E0F803E0F003C04003C040078020078010
+0F000C1C0003F00013227EA018>I<000200000600000E00000E00001E00001E00002E00004E00
+004E00008E00008E00010E00020E00020E00040E00040E00080E00100E00100E00200E00200E00
+400E00800E00FFFFF8000E00000E00000E00000E00000E00000E00000E00001F0001FFF015217F
+A018>I<1000801E07001FFF001FFE001FF80013E0001000001000001000001000001000001000
+0010F800130E001407001803801003800001C00001C00001E00001E00001E00001E07001E0F001
+E0F001E0E001C08001C04003C04003802007001006000C1C0003F00013227EA018>I<007E0001
+C1000300800601C00E03C01C03C0180180380000380000780000700000700000F0F800F30C00F4
+0600F40300F80380F801C0F001C0F001E0F001E0F001E0F001E0F001E07001E07001E07001E038
+01C03801C01803801C03000C0600070C0001F00013227EA018>I<4000006000007FFFE07FFFC0
+7FFFC0400080C00100800100800200800200000400000800000800001000003000002000006000
+00600000600000E00000C00000C00001C00001C00001C00001C00003C00003C00003C00003C000
+03C00003C00003C00003C00001800013237DA118>I<01F800060E000803001001802001802000
+C06000C06000C06000C07000C07801803E01003F02001FC4000FF80003F80003FC00067F00083F
+80100F803007C06001C06000E0C000E0C00060C00060C00060C000606000406000C03000801803
+000E0E0003F00013227EA018>I<01F000060C000C0600180700380380700380700380F001C0F0
+01C0F001C0F001E0F001E0F001E0F001E0F001E07001E07003E03803E01805E00C05E00619E003
+E1E00001C00001C00001C0000380000380300300780700780600700C002018001030000FC00013
+227EA018>I<70F8F8F870000000000000000000000070F8F8F87005157C940E>I<70F8F8F87000
+0000000000000000000070F8F8F87808080808101010204040051F7C940E>I<70F8F8F8700000
+000000202020202020707070707070707070707070F8F8F8F8F8F8F87005247C980E>I<FFFFFF
+FEFFFFFFFE0000000000000000000000000000000000000000000000000000000000000000FFFF
+FFFEFFFFFFFE1F0C7D9126>I<07E01838201C400E800FF00FF00FF00F000F000E001C00380030
+006000C000C000800080018001000100010001000100010000000000000000000000038007C007
+C007C0038010237DA217>63 D<000FE00000701C00008002000300018004000040080000200800
+00201007C01020183008203008084060040440C0078441C0038481C00382838003828380038283
+8003828380038283800382838003828380038281C0038241C0038240C007824060078420300B84
+201831881007C0F00800000008000000040000000300000E00800078007007C0000FFC001F237D
+A226>I<0001800000018000000180000003C0000003C0000003C0000005E0000005E000000DF0
+000008F0000008F0000010F800001078000010780000203C0000203C0000203C0000401E000040
+1E0000401E0000800F0000800F0000FFFF000100078001000780030007C0020003C0020003C004
+0003E0040001E0040001E00C0000F00C0000F03E0001F8FF800FFF20237EA225>I<FFFFF8000F
+800E0007800780078003C0078003E0078001E0078001F0078001F0078001F0078001F0078001F0
+078001E0078003E0078007C007800F8007803E0007FFFE0007800780078003C0078001E0078001
+F0078000F0078000F8078000F8078000F8078000F8078000F8078000F8078001F0078001F00780
+03E0078007C00F800F00FFFFFC001D227EA123>I<0007E0100038183000E0063001C001700380
+00F0070000F00E0000701E0000701C0000303C0000303C0000307C0000107800001078000010F8
+000000F8000000F8000000F8000000F8000000F8000000F8000000F80000007800000078000010
+7C0000103C0000103C0000101C0000201E0000200E000040070000400380008001C0010000E002
+0000381C000007E0001C247DA223>I<FFFFF0000F801E0007800700078003C0078001C0078000
+E0078000F007800078078000780780007C0780003C0780003C0780003C0780003E0780003E0780
+003E0780003E0780003E0780003E0780003E0780003E0780003E0780003C0780003C0780007C07
+80007807800078078000F0078000E0078001E0078003C0078007000F801E00FFFFF8001F227EA1
+25>I<FFFFFFC00F8007C0078001C0078000C00780004007800040078000600780002007800020
+0780002007802020078020000780200007802000078060000780E00007FFE0000780E000078060
+000780200007802000078020000780200807800008078000080780001007800010078000100780
+00300780003007800070078000E00F8003E0FFFFFFE01D227EA121>I<FFFFFFC00F8007C00780
+01C0078000C0078000400780004007800060078000200780002007800020078020200780200007
+80200007802000078060000780E00007FFE0000780E00007806000078020000780200007802000
+078020000780000007800000078000000780000007800000078000000780000007800000078000
+000FC00000FFFE00001B227EA120>I<0007F008003C0C1800E0021801C001B8038000F8070000
+780F0000381E0000381E0000183C0000183C0000187C0000087800000878000008F8000000F800
+0000F8000000F8000000F8000000F8000000F8000000F8001FFF780000F8780000787C0000783C
+0000783C0000781E0000781E0000780F00007807000078038000B801C000B800E00318003C0C08
+0007F00020247DA226>I<FFFC3FFF0FC003F0078001E0078001E0078001E0078001E0078001E0
+078001E0078001E0078001E0078001E0078001E0078001E0078001E0078001E0078001E007FFFF
+E0078001E0078001E0078001E0078001E0078001E0078001E0078001E0078001E0078001E00780
+01E0078001E0078001E0078001E0078001E0078001E00FC003F0FFFC3FFF20227EA125>I<FFFC
+0FC007800780078007800780078007800780078007800780078007800780078007800780078007
+80078007800780078007800780078007800780078007800FC0FFFC0E227EA112>I<03FFF0001F
+00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F
+00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F00700F00F80F
+00F80F00F80E00F01E00401C0020380018700007C00014237EA119>I<FFFC03FF000FC000F800
+078000600007800040000780008000078001000007800200000780040000078008000007801000
+0007802000000780400000078080000007818000000783C000000787E000000789E000000788F0
+00000790F0000007A078000007C03C000007803C000007801E000007800F000007800F00000780
+078000078007C000078003C000078001E000078001E000078000F000078000F8000FC000FC00FF
+FC07FF8021227EA126>I<FFFE00000FC000000780000007800000078000000780000007800000
+078000000780000007800000078000000780000007800000078000000780000007800000078000
+000780000007800000078000000780000007800000078000800780008007800080078000800780
+01800780018007800100078003000780030007800F000F803F00FFFFFF0019227EA11E>I<FFC0
+0003FF0FC00003F007C00003E005E00005E005E00005E004F00009E004F00009E004F00009E004
+780011E004780011E004780011E0043C0021E0043C0021E0043C0021E0041E0041E0041E0041E0
+040F0081E0040F0081E0040F0081E004078101E004078101E004078101E00403C201E00403C201
+E00401E401E00401E401E00401E401E00400F801E00400F801E00400F801E004007001E00E0070
+01E01F007003F0FFE0203FFF28227EA12D>I<FF8007FF07C000F807C0007005E0002004F00020
+04F0002004780020047C0020043C0020041E0020041F0020040F002004078020040780200403C0
+200401E0200401E0200400F0200400F8200400782004003C2004003E2004001E2004000F200400
+0F20040007A0040003E0040003E0040001E0040001E0040000E00E0000601F000060FFE0002020
+227EA125>I<000FE00000783C0000E00E0003C00780078003C00F0001E00E0000E01E0000F03C
+0000783C0000787C00007C7C00007C7800003C7800003CF800003EF800003EF800003EF800003E
+F800003EF800003EF800003EF800003EF800003E7800003C7C00007C7C00007C3C0000783E0000
+F81E0000F00F0001E00F0001E0078003C003C0078000E00E0000783C00000FE0001F247DA226>
+I<FFFFF0000F803C0007800F0007800780078007C0078003C0078003E0078003E0078003E00780
+03E0078003E0078003E0078003C0078007C00780078007800F0007803C0007FFF0000780000007
+800000078000000780000007800000078000000780000007800000078000000780000007800000
+0780000007800000078000000FC00000FFFC00001B227EA121>I<000FE00000783C0000E00E00
+03C00780078003C00F0001E00E0000E01E0000F03E0000F83C0000787C00007C7C00007C780000
+3C7800003CF800003EF800003EF800003EF800003EF800003EF800003EF800003EF800003EF800
+003E7800003C7C00007C7C00007C3C0000783C0000781E0380F00E0420E00F0801E0078813C003
+C8178000E80E00007C3C02000FEC0200000C0200000C0200000E0600000F0E000007FC000007FC
+000007F8000003F8000001E01F2D7DA226>I<FFFFE000000F803C000007800E00000780078000
+078007C000078003C000078003E000078003E000078003E000078003E000078003E000078003C0
+00078007C000078007800007800E000007803C000007FFE000000780700000078038000007801C
+000007801E000007800E000007800F000007800F000007800F000007800F000007800F80000780
+0F800007800F800007800F808007800FC080078007C0800FC003C100FFFC01E2000000007C0021
+237EA124>I<03F0200C0C601802603001E07000E0600060E00060E00060E00020E00020E00020
+F00000F000007800007F00003FF0001FFE000FFF0003FF80003FC00007E00001E00000F00000F0
+000070800070800070800070800070C00060C00060E000C0F000C0C80180C6070081FC0014247D
+A21B>I<7FFFFFF87807807860078018400780084007800840078008C007800C80078004800780
+048007800480078004000780000007800000078000000780000007800000078000000780000007
+800000078000000780000007800000078000000780000007800000078000000780000007800000
+078000000780000007800000078000000FC00003FFFF001E227EA123>I<FFFC07FF0FC000F807
+800070078000200780002007800020078000200780002007800020078000200780002007800020
+078000200780002007800020078000200780002007800020078000200780002007800020078000
+20078000200780002007800020078000200380004003C0004003C0004001C0008000E000800060
+010000300600001C08000003F00020237EA125>I<FFF0007FC01F80001F000F00000C00078000
+0C000780000800078000080003C000100003C000100003E000300001E000200001E000200000F0
+00400000F000400000F000400000780080000078008000007C018000003C010000003C01000000
+1E020000001E020000001F020000000F040000000F040000000F8C000000078800000007880000
+0003D000000003D000000003F000000001E000000001E000000000C000000000C000000000C000
+0022237FA125>I<FFF03FFC03FE1F8007E000F80F0003C000700F0003C000200F0003C0002007
+8001E00040078001E00040078001E0004003C002F0008003C002F0008003C002F0008001E00478
+010001E00478010001E00478010000F0083C020000F0083C020000F0083C020000F8183E060000
+78101E04000078101E0400007C101E0400003C200F0800003C200F0800003C200F0800001E4007
+9000001E40079000001E40079000000F8003E000000F8003E000000F8003E00000070001C00000
+070001C00000070001C0000003000180000002000080002F237FA132>I<7FF807FF0007E001F8
+0003C000E00003E000C00001E000800000F001000000F80300000078020000007C040000003E0C
+0000001E080000001F100000000FB000000007A000000007C000000003E000000001E000000001
+F000000003F80000000278000000047C0000000C3E000000081E000000101F000000300F800000
+20078000004007C00000C003E000008001E000010001F000030000F000070000F8001F8001FC00
+FFE007FFC022227FA125>I<FFF0007FC01F80001F000F80000C00078000080007C000180003E0
+00100001E000200001F000200000F000400000F800C000007C008000003C010000003E01000000
+1E020000001F040000000F84000000078800000007D800000003D000000003E000000001E00000
+0001E000000001E000000001E000000001E000000001E000000001E000000001E000000001E000
+000001E000000001E000000001E000000003E00000003FFF000022227FA125>I<7FFFFE7E003E
+78003C7000786000784000F0C000F0C001E08003C08003C0800780000780000F00001F00001E00
+003C00003C0000780000780000F00001F00001E00103C00103C0010780010780030F00031E0002
+1E00023C00063C000E78001EF8007EFFFFFE18227DA11E>I<FEFEC0C0C0C0C0C0C0C0C0C0C0C0
+C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0FEFE07317BA4
+0E>I<0804100820102010402040208040804080408040B85CFC7EFC7E7C3E381C0F0F7AA218>I<
+FEFE06060606060606060606060606060606060606060606060606060606060606060606060606
+0606060606060606FEFE07317FA40E>I<0FE0001838003C0C003C0E0018070000070000070000
+070000FF0007C7001E07003C0700780700700700F00708F00708F00708F00F087817083C23900F
+C1E015157E9418>97 D<0E0000FE00001E00000E00000E00000E00000E00000E00000E00000E00
+000E00000E00000E00000E00000E1F000E61C00E80600F00300E00380E003C0E001C0E001E0E00
+1E0E001E0E001E0E001E0E001E0E001E0E001C0E003C0E00380F00700C80600C41C0083F001723
+7FA21B>I<01FE000703000C07801C0780380300780000700000F00000F00000F00000F00000F0
+0000F00000F000007000007800403800401C00800C010007060001F80012157E9416>I<0000E0
+000FE00001E00000E00000E00000E00000E00000E00000E00000E00000E00000E00000E00000E0
+01F8E00704E00C02E01C01E03800E07800E07000E0F000E0F000E0F000E0F000E0F000E0F000E0
+F000E07000E07800E03800E01801E00C02E0070CF001F0FE17237EA21B>I<01FC000707000C03
+801C01C03801C07801E07000E0F000E0FFFFE0F00000F00000F00000F00000F000007000007800
+203800201C00400E008007030000FC0013157F9416>I<003C00C6018F038F030F070007000700
+070007000700070007000700FFF807000700070007000700070007000700070007000700070007
+000700070007000700070007807FF8102380A20F>I<00007001F198071E180E0E181C07001C07
+003C07803C07803C07803C07801C07001C07000E0E000F1C0019F0001000001000001800001800
+001FFE000FFFC00FFFE03800F0600030400018C00018C00018C000186000306000303800E00E03
+8003FE0015217F9518>I<0E0000FE00001E00000E00000E00000E00000E00000E00000E00000E
+00000E00000E00000E00000E00000E1F800E60C00E80E00F00700F00700E00700E00700E00700E
+00700E00700E00700E00700E00700E00700E00700E00700E00700E00700E00700E0070FFE7FF18
+237FA21B>I<1C001E003E001E001C00000000000000000000000000000000000E00FE001E000E
+000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E00FFC00A227FA1
+0E>I<01C003E003E003E001C00000000000000000000000000000000001E00FE001E000E000E0
+00E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000
+E000E060E0F0C0F18061803E000B2C82A10F>I<0E0000FE00001E00000E00000E00000E00000E
+00000E00000E00000E00000E00000E00000E00000E00000E03FC0E01F00E01C00E01800E02000E
+04000E08000E10000E38000EF8000F1C000E1E000E0E000E07000E07800E03C00E01C00E01E00E
+00F00E00F8FFE3FE17237FA21A>I<0E00FE001E000E000E000E000E000E000E000E000E000E00
+0E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E
+000E000E00FFE00B237FA20E>I<0E1FC07F00FE60E183801E807201C00F003C00E00F003C00E0
+0E003800E00E003800E00E003800E00E003800E00E003800E00E003800E00E003800E00E003800
+E00E003800E00E003800E00E003800E00E003800E00E003800E00E003800E00E003800E0FFE3FF
+8FFE27157F942A>I<0E1F80FE60C01E80E00F00700F00700E00700E00700E00700E00700E0070
+0E00700E00700E00700E00700E00700E00700E00700E00700E00700E0070FFE7FF18157F941B>
+I<01FC000707000C01801800C03800E0700070700070F00078F00078F00078F00078F00078F000
+78F000787000707800F03800E01C01C00E038007070001FC0015157F9418>I<0E1F00FE61C00E
+80600F00700E00380E003C0E001C0E001E0E001E0E001E0E001E0E001E0E001E0E001E0E003C0E
+003C0E00380F00700E80E00E41C00E3F000E00000E00000E00000E00000E00000E00000E00000E
+00000E0000FFE000171F7F941B>I<01F8200704600E02601C01603801E07800E07800E0F000E0
+F000E0F000E0F000E0F000E0F000E0F000E07000E07800E03801E01C01E00C02E0070CE001F0E0
+0000E00000E00000E00000E00000E00000E00000E00000E00000E0000FFE171F7E941A>I<0E3C
+FE461E8F0F0F0F060F000E000E000E000E000E000E000E000E000E000E000E000E000E000F00FF
+F010157F9413>I<0F8830786018C018C008C008E008F0007F803FE00FF001F8003C801C800C80
+0CC00CC008E018D0308FC00E157E9413>I<02000200020002000600060006000E001E003E00FF
+F80E000E000E000E000E000E000E000E000E000E000E000E040E040E040E040E040E0407080308
+01F00E1F7F9E13>I<0E0070FE07F01E00F00E00700E00700E00700E00700E00700E00700E0070
+0E00700E00700E00700E00700E00700E00700E00F00E00F006017003827800FC7F18157F941B>
+I<FFC1FE1E00780E00300E00200E002007004007004003808003808003808001C10001C10000E2
+0000E20000E20000740000740000380000380000380000100017157F941A>I<FF8FF8FF1E01E0
+3C1C01C0180E01C0180E01E0100E01E01007026020070270200702702003843040038438400384
+384001C8188001C81C8001C81C8000F00D0000F00F0000F00F0000600600006006000060060020
+157F9423>I<FF83FE1F01F00E00C007008003810003830001C20000E400007800007800003800
+003C00004E00008E000187000103800201C00401E00C00E03E01F0FF03FE17157F941A>I<FFC1
+FE1E00780E00300E00200E002007004007004003808003808003808001C10001C10000E20000E2
+0000E200007400007400003800003800003800001000001000002000002000002000004000F040
+00F08000F180004300003C0000171F7F941A>I<3FFFC0380380300780200700600E00401C0040
+3C0040380000700000E00001E00001C0000380400700400F00400E00C01C008038008078018070
+0780FFFF8012157F9416>I<FFFFFE1701808C18>I<FFFFFFFFFFFF3001808C31>I<7070F8F8F8
+F8F8F870700D057BA118>127 D E /Fp 14 118 df<F8F8F8F8F8383070706060E0050C7A8411>
+44 D<F8F8F8F8F805057A8411>46 D<0000FF00000007FFC000001FFFE000007FFFF00000FF01
+F80001FC00FC0003F0007E0007E0003E000FC01FBE001F807FFF001F00FFFF003E01FFFF003E03
+F0FF007C07E07F807C07C03F807C0F801F80FC0F801F80F81F000F80F81F000F80F81F000F80F8
+1F000F80F81F000F80F81F000F80F81F000F80F81F000F80FC0F801F007C0F801F007C07C03E00
+7C07E07E003E03F0FC003E01FFF8001F00FFF0001F807FE0000FC01F800007E000000003F00000
+0001FC000F8000FF007F00007FFFFE00001FFFF8000007FFE0000000FF0000212A7DA928>64
+D<01FE000FFF803FFFC03FFFE03C03F03001F00001F80000F80000F80000F80000F80000F8007F
+F807FFF81FFFF83FE0F87F00F8FC00F8F800F8F800F8F800F8FC01F87E07F87FFFF83FFFF81FFC
+F80FE0F8151B7E9A1D>97 D<F80000F80000F80000F80000F80000F80000F80000F80000F80000
+F80000F80000F80000F80000F80000F80000F83F00F9FFC0FBFFE0FFFFF0FF07F0FC01F8F800FC
+F8007CF8007CF8007EF8003EF8003EF8003EF8003EF8003EF8003EF8003EF8007CF8007CF8007C
+FC00F8FC01F8FF07F0FFFFE0FBFFC0F9FF80F87E00172A7BA91F>I<007FC001FFF007FFFC0FFF
+FC1FC07C1F00083E00007C00007C00007C0000F80000F80000F80000F80000F80000F80000F800
+007C00007C00007E00003E00001F000C1FC07C0FFFFC07FFFC01FFF0007F80161B7E9A1B>I<00
+003E00003E00003E00003E00003E00003E00003E00003E00003E00003E00003E00003E00003E00
+003E00003E00FC3E03FF3E07FFFE0FFFFE1FC1FE3F007E3E003E7C003E7C003EFC003EF8003EF8
+003EF8003EF8003EF8003EF8003EF8003EFC003E7C003E7C003E3E007E3F00FE1FC1FE0FFFFE07
+FFBE03FF3E00FC3E172A7EA91F>I<007E0003FF8007FFC00FFFE01F83F03F00F03E00787C0078
+7C003878003CFFFFFCFFFFFCFFFFFCFFFFFCF80000F80000F800007800007C00007C00003E0000
+3F000C1FC07C0FFFFC07FFFC01FFF0007F80161B7E9A1B>I<001FC0007FC000FFC001FFC003F0
+0003E00007C00007C00007C00007C00007C00007C00007C00007C00007C000FFFE00FFFE00FFFE
+0007C00007C00007C00007C00007C00007C00007C00007C00007C00007C00007C00007C00007C0
+0007C00007C00007C00007C00007C00007C00007C00007C00007C00007C00007C000122A7FA912
+>I<F80000F80000F80000F80000F80000F80000F80000F80000F80000F80000F80000F80000F8
+0000F80000F80000F83F00F8FF80FBFFC0FFFFE0FF07E0FE03F0FC01F0FC01F0FC01F0F801F0F8
+01F0F801F0F801F0F801F0F801F0F801F0F801F0F801F0F801F0F801F0F801F0F801F0F801F0F8
+01F0F801F0F801F0F801F0142A7BA91F>104 D<F83F00F9FFC0FBFFE0FFFFF0FF07F0FC01F8F8
+00FCF800FCF8007CF8007EF8003EF8003EF8003EF8003EF8003EF8003EF8003EF8007CF8007CF8
+00FCFC00F8FC03F8FF07F0FFFFE0FBFFC0F9FF80F87E00F80000F80000F80000F80000F80000F8
+0000F80000F80000F80000F80000F80000F8000017277B9A1F>112 D<F838F8F8F9F8FBF8FFC0
+FF00FE00FE00FC00FC00F800F800F800F800F800F800F800F800F800F800F800F800F800F800F8
+00F800F8000D1B7B9A14>114 D<03FC001FFF803FFFC07FFFC07C07C0F80080F80000F80000F8
+0000FC00007F80007FF8003FFE001FFF0007FF8000FFC0000FE00007E00003E00003E04003E0E0
+07E0FC0FC0FFFFC07FFF801FFE0003F800131B7E9A17>I<F801F0F801F0F801F0F801F0F801F0
+F801F0F801F0F801F0F801F0F801F0F801F0F801F0F801F0F801F0F801F0F801F0F801F0F801F0
+F801F0F801F0F803F0F803F0FC0FF0FFFFF07FFDF03FF9F01FC1F0141B7B9A1F>117
+D E /Fq 3 104 df<00380000380000380000380000380000380060380CF8103E7C107C1F11F0
+0793C001D700007C00007C0001D7000793C01F11F07C107CF8103E60380C003800003800003800
+003800003800003800171A7D9B1E>3 D<0000F80003C0000F00001E00003C0000780000780000
+780000780000780000780000780000780000780000780000780000780000780000780000780000
+780000780000780000780000780000F00000F00001E000078000FE0000FE000007800001E00000
+F00000F00000780000780000780000780000780000780000780000780000780000780000780000
+7800007800007800007800007800007800007800007800007800003C00001E00000F000003C000
+00F8153C7CAC1E>102 D<F800000F000003C00001E00000F00000780000780000780000780000
+780000780000780000780000780000780000780000780000780000780000780000780000780000
+7800007800007800003C00003C00001E000007000001F80001F8000700001E00003C00003C0000
+780000780000780000780000780000780000780000780000780000780000780000780000780000
+780000780000780000780000780000780000780000F00001E00003C0000F0000F80000153C7CAC
+1E>I E /Fr 38 122 df<78FCFCFEFE7A02020202040404081010204007127B8511>44
+D<FFFEFFFEFFFE0F037F8E14>I<007F000001C1C0000780F0000F0078000E0038001C001C003C
+001E003C001E003C001E0078000F0078000F0078000F0078000F00F8000F80F8000F80F8000F80
+F8000F80F8000F80F8000F80F8000F80F8000F80F8000F80F8000F80F8000F80F8000F80F8000F
+80F8000F80F8000F8078000F0078000F0078000F0078000F003C001E003C001E003C001E001C00
+1C000E0038000F0078000780F00001C1C000007F000019297EA71E>48 D<00100000700001F000
+0FF000FEF000F0F00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F000
+00F00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F000
+00F00000F00000F00000F00000F00000F00000F00000F00001F8007FFFE07FFFE013287BA71E>
+I<007F000003FFC0000701F0000C00F80010007C001C007C003E007E003E003E003E003E001E00
+3E000C007E0000007C0000007C00000078000000F0000000E0000001C0000007000000FF000000
+01E0000000F0000000780000003C0000003E0000001F0000001F0000001F8000001F8030001F80
+78001F80FC001F80FC001F80FC001F00F8001F0040003F0040003E0030007C001800F8000F01F0
+0003FFC000007F000019297EA71E>51 D<00006000000060000000E0000001E0000001E0000003
+E0000003E0000005E0000009E0000009E0000011E0000021E0000021E0000041E0000081E00000
+81E0000101E0000201E0000201E0000401E0000801E0000801E0001001E0003001E0002001E000
+4001E000C001E000FFFFFF80FFFFFF800001E0000001E0000001E0000001E0000001E0000001E0
+000001E0000001E0000003F000007FFF80007FFF8019287EA71E>I<20000000380000003FFFFF
+803FFFFF803FFFFF007FFFFF006000020040000400400004004000080080001000800020000000
+20000000400000008000000080000001000000030000000200000006000000060000000C000000
+0C0000001C0000001C0000001C0000003800000038000000380000007800000078000000780000
+0078000000F8000000F8000000F8000000F8000000F8000000F8000000F8000000F80000007000
+00192A7DA81E>55 D<007F000001FFC0000381F000060078000C003C001C001C0018000E003800
+0E0038000E0038000E003C000E003C000E003E001C001F8018001FC038000FF0600007F8C00003
+FF800001FF0000007FC00000FFE000030FF8000603FC001C01FE0038007E0030003F0070000F00
+70000780E0000780E0000380E0000380E0000380E0000380F0000300700007007800060038000C
+001E0038000F80F00003FFE000007F000019297EA71E>I<007F000001FFC00007C1E0000F0070
+001E0038001C003C003C001C0078001E0078001E00F8000F00F8000F00F8000F00F8000F00F800
+0F80F8000F80F8000F80F8000F8078000F8078001F803C001F803C001F801C002F800E004F8007
+00CF8003810F80007E0F8000000F0000000F0000000F0000001E0000001E0000001E0000003C00
+1C003C003E0078003E0070003C00E0001801C0001C0780000FFE000003F8000019297EA71E>I<
+00001800000000180000000018000000003C000000003C000000003C000000007E000000007E00
+000000FF000000009F000000009F000000011F800000010F800000010F8000000207C000000207
+C000000207C000000403E000000403E000000403E000000801F000000801F000001801F8000010
+00F800001000F800002000FC000020007C00003FFFFC00007FFFFE000040003E000040003E0000
+80001F000080001F000080001F000100000F800100000F800100000F8002000007C007000007C0
+1F80000FE0FFF000FFFFFFF000FFFF282A7EA92D>65 D<0000FF00100007FFE030001FC0783000
+3E000C7000F80006F001F00003F003E00001F007C00000F00F800000700F800000701F00000030
+3F000000303E000000303E000000107E000000107E000000107C00000000FC00000000FC000000
+00FC00000000FC00000000FC00000000FC00000000FC00000000FC00000000FC000000007C0000
+00007E000000007E000000103E000000103E000000103F000000101F000000200F800000200F80
+00006007C000004003E000008001F000018000F8000300003E000E00001FC038000007FFE00000
+00FF8000242B7DA92B>67 D<FFFFFFC000FFFFFFF80007E000FC0003E0003F0003E0000F8003E0
+0007C003E00003E003E00001F003E00000F003E00000F803E000007C03E000007C03E000007C03
+E000003E03E000003E03E000003E03E000003F03E000003F03E000003F03E000003F03E000003F
+03E000003F03E000003F03E000003F03E000003F03E000003F03E000003E03E000003E03E00000
+7E03E000007C03E000007C03E00000F803E00000F803E00001F003E00003E003E00007C003E000
+0F8003E0001F0007E000FE00FFFFFFF800FFFFFFC00028297EA82E>I<FFFF80FFFF8007F00003
+E00003E00003E00003E00003E00003E00003E00003E00003E00003E00003E00003E00003E00003
+E00003E00003E00003E00003E00003E00003E00003E00003E00003E00003E00003E00003E00003
+E00003E00003E00003E00003E00003E00003E00003E00003E00007F000FFFF80FFFF8011297EA8
+16>73 D<FFFFE000FFFFE00007F0000003E0000003E0000003E0000003E0000003E0000003E000
+0003E0000003E0000003E0000003E0000003E0000003E0000003E0000003E0000003E0000003E0
+000003E0000003E0000003E0000003E0000003E0000003E0000003E0000103E0000103E0000103
+E0000103E0000203E0000203E0000203E0000203E0000603E0000603E0000E03E0001E03E0007C
+07E001FCFFFFFFFCFFFFFFFC20297EA825>76 D<FFE0001FFFFFF0001FFF03F80001F002F80000
+E0027C000040027E000040023E000040021F000040021F800040020F8000400207C000400207E0
+00400203E000400201F000400201F800400200F8004002007C004002007E004002003E00400200
+1F004002001F804002000F8040020007C040020003E040020003E040020001F040020000F84002
+0000F8400200007C400200003E400200003E400200001F400200000FC00200000FC002000007C0
+02000003C002000003C007000001C00F800000C0FFF80000C0FFF800004028297EA82D>78
+D<0001FF0000000F01E000003C0078000078003C0000E0000E0001E0000F0003C0000780078000
+03C00F800003E01F000001F01F000001F03E000000F83E000000F87E000000FC7E000000FC7C00
+00007C7C0000007CFC0000007EFC0000007EFC0000007EFC0000007EFC0000007EFC0000007EFC
+0000007EFC0000007EFC0000007E7C0000007C7E000000FC7E000000FC7E000000FC3E000000F8
+3F000001F81F000001F01F000001F00F800003E007800003C007C00007C003E0000F8000F0001E
+000078003C00003C007800000F01E0000001FF0000272B7DA92E>I<FFFFFF8000FFFFFFF00007
+E000FC0003E0003E0003E0001F0003E0000F8003E0000FC003E00007C003E00007E003E00007E0
+03E00007E003E00007E003E00007E003E00007E003E00007C003E0000FC003E0000F8003E0001F
+0003E0003E0003E001F80003FFFFE00003E000000003E000000003E000000003E000000003E000
+000003E000000003E000000003E000000003E000000003E000000003E000000003E000000003E0
+00000003E000000003E000000003E000000003E000000007F0000000FFFF800000FFFF80000023
+297EA829>I<00FE010003FF83000F81E3001E0037003C001F0038000F007800070070000700F0
+000300F0000300F0000300F0000100F8000100F8000100FC0000007C0000007F0000003FE00000
+1FFF00000FFFE00007FFF80003FFFC00007FFE000007FF0000007F0000001F8000000F80000007
+C0000007C0800003C0800003C0800003C0800003C0C00003C0C0000380C0000380E0000780F000
+0700F8000E00EE001C00C3C07800C1FFF000803FC0001A2B7DA921>83 D<7FFFFFFFF87FFFFFFF
+F87C007C00F870007C003860007C001840007C000840007C0008C0007C000CC0007C000C80007C
+000480007C000480007C000480007C000480007C000400007C000000007C000000007C00000000
+7C000000007C000000007C000000007C000000007C000000007C000000007C000000007C000000
+007C000000007C000000007C000000007C000000007C000000007C000000007C000000007C0000
+00007C000000007C000000007C000000007C000000007C00000000FE000000FFFFFE0000FFFFFE
+0026297EA82B>I<FFFF801FFFFFFF801FFF07F00001F003E00000E003E000004003E000004003
+E000004003E000004003E000004003E000004003E000004003E000004003E000004003E0000040
+03E000004003E000004003E000004003E000004003E000004003E000004003E000004003E00000
+4003E000004003E000004003E000004003E000004003E000004003E000004003E000004003E000
+004003E000004001E000008001F000008001F000008000F000010000780003000078000200003C
+000C00001F0018000007C070000001FFE00000007F0000282A7EA82D>I<FFFE03FFF803FFC0FF
+FE03FFF803FFC00FE0003F80007E0007C0001F0000180003E0001F0000180003E0000F80001000
+03E0000F8000100001F0000F8000200001F0000FC000200001F0000FC000200000F8000FC00040
+0000F80013E000400000F80013E000400000FC0013E000C000007C0033F0008000007C0021F000
+8000007E0021F0008000003E0021F8010000003E0040F8010000003E0040F8010000001F0040F8
+020000001F00807C020000001F00807C020000000F80807C040000000F81003E040000000F8100
+3E0400000007C1003E0800000007C2001F0800000007C2001F0800000003E2001F1000000003E4
+000F9000000003E4000F9000000001F4000FA000000001F80007E000000001F80007E000000000
+F80007C000000000F00003C000000000F00003C000000000700003800000000060000180000000
+0060000180000000006000018000003A2A7FA83D>87 D<01FC00000E0780001001C0003C00E000
+3E00F0003E0078001C00780008007800000078000000780000007800007FF80003E078000F8078
+001F0078003E0078007C00780078007820F8007820F8007820F8007820F800F8207C00F8203C01
+3C401F063FC007F80F001B1A7E991E>97 D<07800000FF800000FF8000000F8000000780000007
+800000078000000780000007800000078000000780000007800000078000000780000007800000
+078000000783F000078C1C0007B0070007A0038007C003C0078001E0078001E0078000F0078000
+F0078000F8078000F8078000F8078000F8078000F8078000F8078000F8078000F0078000F00780
+01F0078001E0078001C007C003C00740078007200E0006181C000407E0001D2A7FA921>I<007F
+8001C0700780080F003C1E007C3C007C3C00387C0010780000F80000F80000F80000F80000F800
+00F80000F80000F800007800007C00003C00043C00041E00080F001007802001C0C0007F00161A
+7E991B>I<00000F000001FF000001FF0000001F0000000F0000000F0000000F0000000F000000
+0F0000000F0000000F0000000F0000000F0000000F0000000F0000000F00003F0F0001C0CF0003
+802F000F001F001E001F001C000F003C000F007C000F0078000F0078000F00F8000F00F8000F00
+F8000F00F8000F00F8000F00F8000F00F8000F0078000F0078000F003C000F003C000F001E001F
+000E002F0007004F8001C18FF8007E0FF81D2A7EA921>I<007E0003C3800700E00E00F01C0070
+3C00783C003878003C78003CF8003CF8003CFFFFFCF80000F80000F80000F80000F80000780000
+7C00003C00043C00041E00080E001007002001C0C0007F00161A7E991B>I<001F000070C000E1
+E001C3E003C3E00381C00780800780000780000780000780000780000780000780000780000780
+00FFFE00FFFE000780000780000780000780000780000780000780000780000780000780000780
+0007800007800007800007800007800007800007800007800007800007800007C000FFFE00FFFE
+00132A7FA912>I<07000F801F801F800F80070000000000000000000000000000000000000007
+807F807F800F800780078007800780078007800780078007800780078007800780078007800780
+0780078007800780FFF8FFF80D297FA811>105 D<0781F800FC00FF860E030700FF98070C0380
+0FA0079003C007A003D001E007C003E001E007C003E001E0078003C001E0078003C001E0078003
+C001E0078003C001E0078003C001E0078003C001E0078003C001E0078003C001E0078003C001E0
+078003C001E0078003C001E0078003C001E0078003C001E0078003C001E0078003C001E0078003
+C001E0078003C001E0FFFC7FFE3FFFFFFC7FFE3FFF301A7F9933>109 D<0783F800FF8C1C00FF
+900E000FA0070007A0078007C0078007C007800780078007800780078007800780078007800780
+078007800780078007800780078007800780078007800780078007800780078007800780078007
+800780078007800780FFFCFFFCFFFCFFFC1E1A7F9921>I<007F000001C1C000070070000E0038
+001C001C003C001E003C001E0078000F0078000F00F8000F80F8000F80F8000F80F8000F80F800
+0F80F8000F80F8000F80F8000F8078000F0078000F003C001E003C001E001E003C000E00380007
+00700001C1C000007F0000191A7E991E>I<0783F000FF8C1C00FFB00F0007A0078007C003C007
+8003E0078001E0078001F0078001F0078000F8078000F8078000F8078000F8078000F8078000F8
+078000F8078000F0078001F0078001F0078001E0078003C007C003C007C0078007A00E0007983C
+000787E00007800000078000000780000007800000078000000780000007800000078000000780
+000007800000FFFC0000FFFC00001D267F9921>I<0787C0FF98E0FF91F00FA1F007C1F007C0E0
+07C000078000078000078000078000078000078000078000078000078000078000078000078000
+07800007800007800007800007C000FFFE00FFFE00141A7F9917>114 D<07F8401C06C03001C0
+6000C06000C0E00040E00040F00040F800007E00007FF0003FFE000FFF0003FF80003FC00007C0
+8001E08001E0C000E0C000E0C000E0E000C0F001C0F80180C4070083F800131A7E9918>I<0080
+000080000080000080000180000180000180000380000380000780000F80001FFF80FFFF800780
+000780000780000780000780000780000780000780000780000780000780000780000780000780
+4007804007804007804007804007804007804003C08001C08000E100003E0012257FA417>I<07
+800780FF80FF80FF80FF800F800F80078007800780078007800780078007800780078007800780
+078007800780078007800780078007800780078007800780078007800780078007800780078007
+8007800F8007800F800380178001C027C000E047FC003F87FC1E1A7F9921>I<FFF00FF8FFF00F
+F80F8003C0078003800780010003C0020003C0020003E0020001E0040001E0040000F0080000F0
+080000F818000078100000781000003C2000003C2000003E6000001E4000001E4000000F800000
+0F8000000700000007000000070000000200001D1A7F9920>I<FFF00FF8FFF00FF80F8003C007
+8003800780010003C0020003C0020003E0020001E0040001E0040000F0080000F0080000F81800
+0078100000781000003C2000003C2000003E6000001E4000001E4000000F8000000F8000000700
+00000700000007000000020000000200000004000000040000000400000008000070080000F810
+0000F8100000F8200000F0400000608000001F0000001D267F9920>121
+D E /Fs 22 118 df<00000FF03F000000780CE0800001E00FC3C00003801F87C00007003F07C0
+000F003F03C0001E001E0100001E001E0000001E001E0000003C003C0000003C003C0000003C00
+3C0000003C003C0000003C003C0000003C003C00000078007800000FFFFFFFF0000FFFFFFFF000
+00780078000000780078000000780078000000F000F0000000F000F0000000F000F0000000F000
+F0000000F000F0000000F000F0000001E001E0000001E001E0000001E001E0000001E001E00000
+01E001E0000001E001E0000003C003C0000003C003C0000003C003C0000003C003C0000003C003
+C0000003C003C0000007C007C000007FF87FFE0000FFF87FFE00002A2A7FA923>11
+D<387C7EFC7C3807067B8511>46 D<00000FF00100007FFE030001FC07070007E0018E001F8000
+5E003E00003E007C00003E00F800001E01F000001E03E000000C07C000000C07C000000C0F8000
+000C1F8000000C1F0000000C3F000000083F000000007E000000007E000000007E000000007E00
+000000FC00000000FC00000000FC00000000FC00000000FC00000000FC00000000FC00000000FC
+000000207C000000207C000000207C000000403E000000403E000000801E000000801F00000100
+0F8000020007C000040003E000180001F0003000007E01E000003FFF80000007FC0000282B7AA9
+2B>67 D<01FFFFFFFF03FFFFFFFF000FC0007F000F80000F000F800007000F800007000F800003
+000F800003001F000003001F000003001F000001001F000001001F000801001F000801003E0010
+00003E001000003E001000003E003000003E00F000003FFFF000007FFFE000007C00E000007C00
+6000007C006000007C002000007C00200200F800400400F800400400F800000400F800000800F8
+00000800F800001801F000001001F000003001F000003001F000007001F00000E001F00003E003
+F0000FE0FFFFFFFFC0FFFFFFFFC028297EA829>69 D<01FFFF03FFFE03FFFF07FFFE000FC0001F
+80000F80001F00000F80001F00000F80001F00000F80001F00000F80001F00001F00003E00001F
+00003E00001F00003E00001F00003E00001F00003E00001F00003E00003E00007C00003E00007C
+00003E00007C00003E00007C00003E00007C00003FFFFFFC00007FFFFFF800007C0000F800007C
+0000F800007C0000F800007C0000F800007C0000F80000F80001F00000F80001F00000F80001F0
+0000F80001F00000F80001F00000F80001F00001F00003E00001F00003E00001F00003E00001F0
+0003E00001F00003E00001F00003E00003F00007E000FFFF81FFFF00FFFF81FFFF002F297EA82D
+>72 D<01FFFF800003FFFF8000000FC00000000F800000000F800000000F800000000F80000000
+0F800000001F000000001F000000001F000000001F000000001F000000001F000000003E000000
+003E000000003E000000003E000000003E000000003E000000007C000000007C000000007C0000
+00007C000000007C000000007C00002000F800004000F800004000F800004000F800008000F800
+008000F800018001F000018001F000030001F000030001F000070001F0000E0001F0003E0003F0
+01FE00FFFFFFFC00FFFFFFFC0023297EA825>76 D<0001FC020007FF06001E038E003800DC0070
+007C00E0003C01E0001C03C0001C03C0001C0380000807800008078000080780000807C0000807
+C0000007E0000003F0000003FE000001FFE00001FFFE0000FFFF00003FFF80000FFFC00000FFE0
+00000FE0000003F0000001F0000001F0000001F0200000F0200000F0200000F0200000E0600001
+E0600001E0700001C0700003C0780007807C000700E6001E00E3C07C00C1FFF000803FC0001F2B
+7DA921>83 D<003FC00001C0F0000200380007803C0007C01E000F801E0007801E0002001E0000
+001E0000001E0000001E00001FFC0001F83C0007C03C000F803C001E003C003E003C007C007820
+F8007820F8007820F8007820F800F820F80178407C0278403E0C3F8007F01E001B1A7D991E>97
+D<01E000003FE000003FE0000003C0000003C0000003C0000003C0000003C0000003C000000780
+000007800000078000000780000007800000078000000F0000000F07E0000F1838000F600E000F
+800F000F0007001F0007801E0007C01E0003C01E0003C01E0003C01E0003C03C0007C03C0007C0
+3C0007C03C0007C03C0007803C000F8078000F8078000F0078001E0078001C0078003800740070
+00E200E000C103800080FE00001A2A7AA921>I<001FF000700C01E00203801E07001F0F003E1E
+001E3E00083C00007C00007C0000780000F80000F80000F80000F80000F80000F80000F8000078
+00087800083C00101C00200E004007038001FC00181A7C991B>I<0000007800000FF800000FF8
+000000F0000000F0000000F0000000F0000000F0000000F0000001E0000001E0000001E0000001
+E0000001E0000001E0000003C0000FC3C0007833C001E00BC003800BC0070007C00F0007801E00
+07803E0007803C0007807C0007807C00078078000F00F8000F00F8000F00F8000F00F8000F00F8
+000F00F8001E00F8001E0078001E0078001E0038003E001C005E000E01BE0007063FE001F83FE0
+1D2A7CA921>I<001F8000F0E001C03003803807003C0E001C1E001C3E001E3C001E7C001E7C00
+1EFFFFFCF80000F80000F80000F80000F80000F80000F800007800087800083800101C00200E00
+C007030001FC00171A7C991B>I<0000003C0007E0C2003C390E00701E0E00E01E0401E01E0003
+E01F0003C01F0007C01F0007C01F0007C01F0007C01E0007C03E0007C03C0003C0780001C07000
+02E1E000063F000004000000040000000C0000000C0000000E00000007FFF00003FFFC0003FFFE
+000E001F0018000780380003807000038070000380E0000380E0000380E0000380E00007007000
+0E0030001C001C0038000F01E00001FF00001F287F9A1E>103 D<000F000001FF000001FF0000
+001E0000001E0000001E0000001E0000001E0000001E0000003C0000003C0000003C0000003C00
+00003C0000003C00000078000000783F800078C1C0007900E0007A00F0007C00F000F800F000F8
+00F000F000F000F000F000F000F000F000F001E001E001E001E001E001E001E001E001E001E001
+E001E003C003C003C003C003C003C003C003C003C003C003C003C007C007C07FFC7FFCFFFCFFFC
+1E2A7FA921>I<001C003E003E007E003E001C0000000000000000000000000000000000000078
+07F807F800F800F800F000F000F000F000F000F001E001E001E001E001E001E003C003C003C003
+C003C003C007C07FF8FFF80F297FA811>I<00783F800FF8C1C00FF900E000FA00F000FC00F000
+F800F000F800F000F000F000F000F000F000F000F000F001E001E001E001E001E001E001E001E0
+01E001E001E001E003C003C003C003C003C003C003C003C003C003C003C003C007C007C07FFC7F
+FCFFFCFFFC1E1A7F9921>110 D<001FC0000070700001C01C0003800E0007000E000E000F001E
+0007803C0007803C0007807C0007807C00078078000F80F8000F80F8000F80F8000F80F8000F80
+F8001F00F8001F00F8001E0078003C0078003C00380078001C00F0000E01C0000707800001FC00
+00191A7C991E>I<001E0FC00003FE30700003FEC03C00003F001E00001E001E00003E000F0000
+3C000F80003C000F80003C000F80003C000F80003C000F800078000F800078000F800078000F80
+0078000F800078000F000078001F0000F0001F0000F0003E0000F0003C0000F000780000F000F0
+0000F800E00001E403C00001E207000001E1FC000001E000000001E000000001E000000003C000
+000003C000000003C000000003C000000003C000000003C000000007C00000007FFC000000FFFC
+0000002126819921>I<00787C0FF98E0FFA1F00FA1F00FC1E00F81E00F80000F80000F00000F0
+0000F00001E00001E00001E00001E00001E00001E00003C00003C00003C00003C00003C00003C0
+0007C0007FFE00FFFE00181A7F9917>114 D<003F8401C06C03001C06000C0E000C0C00081C00
+081E00081F00001FC0000FFE0007FF8003FFC000FFE0000FF00001F02000F06000706000706000
+706000707000607000C0E80180C6070081FC00161A7E9918>I<00200000200000200000600000
+400000C00000C00001C00001C00003C0000780001FFF80FFFF800780000780000780000F00000F
+00000F00000F00000F00000F00001E00001E00001E00001E00001E01001E01003C02003C02003C
+02003C02003C04001C04001C08000E100003E00011257BA417>I<07800780FF80FF80FF80FF80
+0F800F800F800F800F000F000F000F000F000F000F000F000F000F000F000F001E001E001E001E
+001E001E001E001E001E001E001E001E003C003C003C003C003C003C003C007C003C007C003C00
+BC001C017C000E067FC003F87FC01A1A7B9921>I E /Ft 22 122 df<0000007C000000000000
+7C000000000000FE000000000000FE000000000000FE000000000001FF000000000001FF000000
+000003FF800000000003FF800000000007FFC00000000007FFC00000000007FFC0000000000FFF
+E0000000000F7FE0000000001F7FF0000000001E3FF0000000001E3FF0000000003E3FF8000000
+003C1FF8000000007C1FFC00000000780FFC00000000780FFC00000000F80FFE00000000F007FE
+00000001F007FF00000001E003FF00000001E003FF00000003E003FF80000003C001FF80000007
+C001FFC00000078000FFC00000078000FFC000000FFFFFFFE000000FFFFFFFE000001FFFFFFFF0
+00001E00003FF000001E00003FF000003C00003FF800003C00001FF800007C00001FFC00007800
+000FFC00007800000FFC0000F0000007FE0000F0000007FE0001F0000007FF0003F8000003FF00
+FFFFC001FFFFFEFFFFC001FFFFFEFFFFC001FFFFFE37317DB03E>65 D<FFFFFFFFF00000FFFFFF
+FFFF0000FFFFFFFFFFC00000FFC000FFF00000FFC0000FFC0000FFC00007FE0000FFC00001FF00
+00FFC00000FF8000FFC000007FC000FFC000003FE000FFC000003FE000FFC000001FF000FFC000
+001FF000FFC000001FF800FFC000000FF800FFC000000FFC00FFC000000FFC00FFC000000FFC00
+FFC000000FFC00FFC000000FFE00FFC000000FFE00FFC000000FFE00FFC000000FFE00FFC00000
+0FFE00FFC000000FFE00FFC000000FFE00FFC000000FFE00FFC000000FFE00FFC000000FFE00FF
+C000000FFE00FFC000000FFC00FFC000000FFC00FFC000000FFC00FFC000000FFC00FFC000000F
+F800FFC000001FF800FFC000001FF800FFC000001FF000FFC000003FE000FFC000003FE000FFC0
+00007FC000FFC00000FF8000FFC00001FF0000FFC00003FE0000FFC0000FFC0000FFC0007FF000
+FFFFFFFFFFE000FFFFFFFFFF0000FFFFFFFFF0000037317EB03F>68 D<FFFFC000007FFFF0FFFF
+E000007FFFF0FFFFF000007FFFF000FFF8000000F80000FFFC000000700000FFFE000000700000
+EFFF000000700000E7FF800000700000E3FF800000700000E1FFC00000700000E0FFE000007000
+00E07FF00000700000E07FF80000700000E03FFC0000700000E01FFE0000700000E00FFF000070
+0000E007FF8000700000E003FF8000700000E001FFC000700000E000FFE000700000E0007FF000
+700000E0007FF800700000E0003FFC00700000E0001FFE00700000E0000FFF00700000E00007FF
+80700000E00003FF80700000E00001FFC0700000E00000FFE0700000E000007FF0700000E00000
+7FF8700000E000003FFC700000E000001FFE700000E000000FFF700000E0000007FFF00000E000
+0003FFF00000E0000001FFF00000E0000000FFF00000E00000007FF00000E00000007FF00000E0
+0000003FF00000E00000001FF00000E00000000FF00000E000000007F00000E000000003F00001
+F000000001F000FFFFE0000000F000FFFFE00000007000FFFFE000000070003C317EB041>78
+D<FFFFFFFFE000FFFFFFFFFE00FFFFFFFFFF8000FFC001FFE000FFC0003FF000FFC0001FF800FF
+C0000FFC00FFC0000FFC00FFC00007FE00FFC00007FE00FFC00007FF00FFC00007FF00FFC00007
+FF00FFC00007FF00FFC00007FF00FFC00007FF00FFC00007FF00FFC00007FE00FFC00007FE00FF
+C0000FFC00FFC0000FFC00FFC0001FF800FFC0003FF000FFC001FFE000FFFFFFFF8000FFFFFFFE
+0000FFFFFFE00000FFC000000000FFC000000000FFC000000000FFC000000000FFC000000000FF
+C000000000FFC000000000FFC000000000FFC000000000FFC000000000FFC000000000FFC00000
+0000FFC000000000FFC000000000FFC000000000FFC000000000FFC000000000FFC000000000FF
+C0000000FFFFFFC00000FFFFFFC00000FFFFFFC0000030317EB038>80 D<001FF0018000FFFF03
+8003FFFFC78007F00FFF800F8001FF801F00007F803F00001F803E00000F807E00000F807E0000
+0780FE00000780FE00000780FE00000380FF00000380FF00000380FF80000000FFE00000007FFC
+0000007FFFE000007FFFFE00003FFFFFC0001FFFFFF0001FFFFFF8000FFFFFFC0003FFFFFE0001
+FFFFFF00007FFFFF80001FFFFF800000FFFFC0000007FFC0000000FFE00000003FE00000003FE0
+0000001FE06000001FE0E000000FE0E000000FE0E000000FE0E000000FC0F000000FC0F000000F
+C0F800001F80FC00001F80FF00003F00FFC0007E00FFFC01FC00F1FFFFF800E03FFFE000C007FF
+000023317BB02E>83 D<FFFFFE07FFFFF801FFFFFFFFFE07FFFFF801FFFFFFFFFE07FFFFF801FF
+FF03FF00000FFC000007E003FF80000FFC000003C001FF80000FFE0000038001FF800007FE0000
+038001FFC00007FE0000078000FFC00007FF0000070000FFE00003FF00000700007FE00003FF80
+000E00007FE00003FF80000E00007FF00003FF80001E00003FF00007FFC0001C00003FF80007FF
+C0001C00001FF80007FFE0003800001FF8000E7FE0003800001FFC000E7FE0007800000FFC001E
+7FF0007000000FFC001C3FF00070000007FE001C3FF000E0000007FE00381FF800E0000007FF00
+381FF801E0000003FF00781FFC01C0000003FF00700FFC01C0000003FF80700FFC03C0000001FF
+80F00FFE0380000001FFC0E007FE0380000000FFC0E007FF0700000000FFC1C003FF0700000000
+FFE1C003FF0F000000007FE3C003FF8E000000007FE38001FF8E000000003FF38001FF9C000000
+003FF70000FFDC000000003FFF0000FFFC000000001FFF0000FFF8000000001FFE00007FF80000
+00000FFE00007FF0000000000FFC00003FF0000000000FFC00003FF00000000007FC00003FE000
+00000007F800001FE00000000007F800001FE00000000003F800001FC00000000003F000000FC0
+0000000001F000000F800000000001E0000007800000000000E000000700000050317EB055>87
+D<007FF8000003FFFF000007FFFFC0000FE01FE0001FF007F0001FF003F8001FF003FC001FF001
+FE000FE001FE0007C001FE00010001FE00000001FE00000001FE000001FFFE00003FFFFE0001FF
+F1FE0007FE01FE000FF001FE001FC001FE003F8001FE007F8001FE00FF0001FE00FF0001FE00FF
+0001FE00FF0001FE00FF0003FE007F8003FE007FC00EFE003FF03CFF000FFFF87FF807FFF03FF8
+00FF800FF825207E9F28>97 D<0007FF00007FFFE000FFFFF003FC03F807F007FC0FE007FC1FE0
+07FC3FC007FC3FC003F87FC001F07F8000407F800000FF800000FF800000FF800000FF800000FF
+800000FF800000FF800000FF8000007F8000007FC000007FC000003FC0000E3FE0000E1FE0001C
+0FF0001C07F8007803FF01F000FFFFE0007FFF800007FC001F207D9F25>99
+D<00000007E0000003FFE0000003FFE0000003FFE00000003FE00000001FE00000001FE0000000
+1FE00000001FE00000001FE00000001FE00000001FE00000001FE00000001FE00000001FE00000
+001FE00000001FE00000001FE0000FF81FE0007FFF1FE001FFFFDFE003FE03FFE007F800FFE00F
+E0003FE01FE0001FE03FC0001FE03FC0001FE07F80001FE07F80001FE07F80001FE0FF80001FE0
+FF80001FE0FF80001FE0FF80001FE0FF80001FE0FF80001FE0FF80001FE0FF80001FE07F80001F
+E07F80001FE07F80001FE03FC0001FE03FC0001FE01FC0003FE00FE0007FE007F001FFE003FC07
+DFF001FFFF9FFF007FFE1FFF000FF01FFF28327DB12E>I<0007FC0000003FFF800000FFFFE000
+03FC07F00007F801F8000FE000FC001FE0007E003FC0007E003FC0003F007FC0003F007F80003F
+007F80003F80FF80003F80FF80003F80FFFFFFFF80FFFFFFFF80FFFFFFFF80FF80000000FF8000
+0000FF800000007F800000007F800000003FC00000003FC00003801FC00003801FE00007800FF0
+000F0007F8001E0003FE00FC0000FFFFF800003FFFE0000003FF000021207E9F26>I<001FF007
+E000FFFE3FF001FFFF7FF807F83FF1F80FE00FE1F80FE00FE0F01FC007F0601FC007F0003FC007
+F8003FC007F8003FC007F8003FC007F8003FC007F8001FC007F0001FC007F0000FE00FE0000FE0
+0FE00007F83FC00007FFFF000006FFFE00000E1FF000000E000000001E000000001E000000001F
+000000001F800000001FFFFFC0000FFFFFF8000FFFFFFE0007FFFFFF0003FFFFFF8007FFFFFFC0
+1FFFFFFFE03F00007FE07E00000FF0FC000007F0FC000003F0FC000003F0FC000003F0FC000003
+F07E000007E03F00000FC01FC0003F800FF801FF0007FFFFFE0000FFFFF000001FFF8000252F7E
+9F29>103 D<01F800000000FFF800000000FFF800000000FFF8000000000FF80000000007F800
+00000007F80000000007F80000000007F80000000007F80000000007F80000000007F800000000
+07F80000000007F80000000007F80000000007F80000000007F80000000007F80000000007F807
+F8000007F83FFF000007F87FFF800007F8F03FC00007F9C01FE00007FB000FE00007FE000FF000
+07FE000FF00007FC000FF00007FC000FF00007F8000FF00007F8000FF00007F8000FF00007F800
+0FF00007F8000FF00007F8000FF00007F8000FF00007F8000FF00007F8000FF00007F8000FF000
+07F8000FF00007F8000FF00007F8000FF00007F8000FF00007F8000FF00007F8000FF00007F800
+0FF00007F8000FF00007F8000FF000FFFFC1FFFF80FFFFC1FFFF80FFFFC1FFFF8029327DB12E>
+I<03C0000FF0000FF0001FF8001FF8001FFC001FF8001FF8000FF0000FF00003C0000000000000
+0000000000000000000000000000000000000001F800FFF800FFF800FFF8000FF80007F80007F8
+0007F80007F80007F80007F80007F80007F80007F80007F80007F80007F80007F80007F80007F8
+0007F80007F80007F80007F80007F80007F80007F80007F80007F800FFFF80FFFF80FFFF801133
+7DB217>I<01F8000000FFF8000000FFF8000000FFF80000000FF800000007F800000007F80000
+0007F800000007F800000007F800000007F800000007F800000007F800000007F800000007F800
+000007F800000007F800000007F800000007F8007FFC07F8007FFC07F8007FFC07F8001FC007F8
+001F0007F8003E0007F800780007F801F00007F803E00007F807800007F81F000007F83E000007
+F87C000007F9FE000007FBFF000007FFFF800007FF7FC00007FE3FE00007F81FE00007F01FF000
+07F00FF80007F007FC0007F003FE0007F001FF0007F000FF0007F000FF8007F0007FC007F0003F
+E007F0003FF0FFFF80FFFFFFFF80FFFFFFFF80FFFF28327EB12C>107 D<01F800FFF800FFF800
+FFF8000FF80007F80007F80007F80007F80007F80007F80007F80007F80007F80007F80007F800
+07F80007F80007F80007F80007F80007F80007F80007F80007F80007F80007F80007F80007F800
+07F80007F80007F80007F80007F80007F80007F80007F80007F80007F80007F80007F80007F800
+07F80007F80007F80007F80007F800FFFFC0FFFFC0FFFFC012327DB117>I<03F007F8000FF000
+FFF03FFF007FFE00FFF07FFF80FFFF00FFF0F03FC1E07F800FF1C01FE3803FC007F3000FE6001F
+C007F6000FFC001FE007FE000FFC001FE007FC000FF8001FE007FC000FF8001FE007F8000FF000
+1FE007F8000FF0001FE007F8000FF0001FE007F8000FF0001FE007F8000FF0001FE007F8000FF0
+001FE007F8000FF0001FE007F8000FF0001FE007F8000FF0001FE007F8000FF0001FE007F8000F
+F0001FE007F8000FF0001FE007F8000FF0001FE007F8000FF0001FE007F8000FF0001FE007F800
+0FF0001FE007F8000FF0001FE007F8000FF0001FE007F8000FF0001FE0FFFFC1FFFF83FFFFFFFF
+C1FFFF83FFFFFFFFC1FFFF83FFFF40207D9F45>I<03F007F80000FFF03FFF0000FFF07FFF8000
+FFF0F03FC0000FF1C01FE00007F3000FE00007F6000FF00007FE000FF00007FC000FF00007FC00
+0FF00007F8000FF00007F8000FF00007F8000FF00007F8000FF00007F8000FF00007F8000FF000
+07F8000FF00007F8000FF00007F8000FF00007F8000FF00007F8000FF00007F8000FF00007F800
+0FF00007F8000FF00007F8000FF00007F8000FF00007F8000FF00007F8000FF00007F8000FF000
+FFFFC1FFFF80FFFFC1FFFF80FFFFC1FFFF8029207D9F2E>I<0007FE0000003FFFC00000FFFFF0
+0003FC03FC0007F000FE000FE0007F001FC0003F803FC0003FC03FC0003FC07F80001FE07F8000
+1FE07F80001FE0FF80001FF0FF80001FF0FF80001FF0FF80001FF0FF80001FF0FF80001FF0FF80
+001FF0FF80001FF07F80001FE07F80001FE07F80001FE03FC0003FC03FC0003FC01FE0007F800F
+E0007F0007F801FE0003FE07FC0001FFFFF800003FFFC0000007FE000024207E9F29>I<03F03F
+00FFF07FC0FFF1FFE0FFF3C7F00FF38FF807F70FF807F60FF807FE0FF807FC07F007FC03E007FC
+008007F8000007F8000007F8000007F8000007F8000007F8000007F8000007F8000007F8000007
+F8000007F8000007F8000007F8000007F8000007F8000007F8000007F8000007F80000FFFFE000
+FFFFE000FFFFE0001D207E9F22>114 D<00FF870007FFEF001FFFFF003F007F003C001F007800
+0F00F8000700F8000700F8000700FC000700FF000000FFF800007FFFC0003FFFF0003FFFFC000F
+FFFE0007FFFF0001FFFF80001FFF800000FFC000001FC060000FC0E00007C0E00007C0F00007C0
+F8000780F8000F80FE000F00FF803E00FFFFFC00F3FFF800C07FC0001A207D9F21>I<00380000
+380000380000380000380000780000780000780000F80000F80001F80003F80007F8001FF800FF
+FFFEFFFFFEFFFFFE07F80007F80007F80007F80007F80007F80007F80007F80007F80007F80007
+F80007F80007F80007F80007F80007F80007F80707F80707F80707F80707F80707F80707F80703
+F80E03FC0E01FE1C00FFF8007FF0000FE0182E7EAD20>I<FFFF801FFEFFFF801FFEFFFF801FFE
+07F80003E007F80001C007FC0003C003FC00038003FE00078001FE00070001FF000F0000FF000E
+0000FF801E00007F801C00007FC03C00003FC03800003FE03800001FE07000001FE07000000FF0
+E000000FF0E000000FF9E0000007F9C0000007FFC0000003FF80000003FF80000001FF00000001
+FF00000000FE00000000FE000000007C000000007C000000003800000000380000000070000000
+007000000000F000003C00E000007E01E00000FF01C00000FF03800000FF07800000FF0F000000
+7A3E0000007FFC0000003FF80000000FC0000000272E7E9F2C>121 D E
+end
+%%EndProlog
+%%BeginSetup
+TeXDict begin
+
+%%EndSetup
+%%Page: 1 1
+0 bop 232 75 a Ft(Addressing)26 b(W)-7 b(eaknesses)26 b(in)h(the)g(Domain)h
+(Name)751 212 y(System)e(Proto)r(col)457 416 y Fs(Christoph)21
+b(L.)f(Sc)n(h)n(uba)g(and)h(Eugene)e(H.)g(Spa\013ord)788 580
+y Fr(CO)n(AST)i(Lab)r(oratory)601 692 y(Departmen)n(t)e(of)h(Computer)g
+(Sciences)810 804 y(Purdue)h(Univ)n(ersit)n(y)647 916 y(W)-5
+b(est)20 b(Lafa)n(y)n(ette,)g(IN)f(47907-1398)685 1028 y Fq(f)p
+Fp(schuba,spaf)p Fq(g)p Fp(@cs.pu)o(rdue.e)o(du)p eop
+%%Page: 2 2
+1 bop 1922 -100 a Fo(ii)912 344 y(ABSTRA)o(CT)149 555 y(Sc)o(h)o(uba,)19
+b(Christoph.)28 b(M.S.,)18 b(Purdue)g(Univ)o(ersit)o(y)l(,)e(August)j(1993.)
+29 b(Addressing)18 b(W)l(eaknesses)149 615 y(in)e(the)g(Domain)g(Name)e
+(System)h(Proto)q(col.)22 b(Ma)s(jor)16 b(Professor:)23 b(Eugene)16
+b(H.)f(Spa\013ord.)223 766 y(The)i(Domain)g(Name)e(System)h(\(DNS\))h(is)g(a)
+h(widely)e(implem)o(en)o(t)o(ed)f(distributed)h(database)149
+856 y(system)e(used)h(throughout)i(the)e(In)o(ternet,)e(pro)o(viding)i(name)f
+(resolution)h(b)q(et)o(w)o(een)f(host)h(names)149 946 y(and)i(In)o(ternet)e
+(Proto)q(col)i(addresses.)223 1037 y(This)e(thesis)g(describ)q(es)f(problems)
+g(with)h(the)g(DNS)g(and)g(one)h(of)f(its)g(implem)o(en)n(tations)e(that)149
+1127 y(allo)o(w)21 b(the)g(abuse)g(of)g(name)f(based)i(authen)o(tication.)34
+b(This)22 b(leads)e(to)i(situations)f(where)g(the)149 1217
+y(name)16 b(resolution)g(pro)q(cess)h(cannot)f(b)q(e)h(trusted,)f(and)h
+(securit)o(y)d(ma)o(y)h(b)q(e)h(compromised.)223 1307 y(This)h(thesis)f
+(outlines)g(the)h(curren)o(t)f(design)h(and)g(implem)o(en)o(tati)o(on)e(of)i
+(the)f(DNS.)h(It)f(states)149 1398 y(the)f(main)f(problem)f(b)q(oth)j(on)g(a)
+f(high)h(lev)o(el)c(and)k(as)g(applied)e(to)i(the)e(DNS)h(in)g(a)h(more)d
+(concrete)149 1488 y(fashion.)24 b(W)l(e)17 b(examine)d(the)j(w)o(eaknesses)g
+(in)f(the)h(DNS)g(and)g(exploit)f(a)h(metho)q(d)f(to)h(abuse)h(the)149
+1578 y(DNS)f(for)f(system)f(break{ins.)223 1669 y(W)l(e)21
+b(demonstrate)g(these)g(w)o(eaknesses)h(b)o(y)f(describing)h(the)f(necessary)
+h(mo)q(di\014cations)f(in)149 1759 y(authoritativ)o(e)16 b(DNS)g(data)h(and)g
+(Domain)e(Name)g(System)f(co)q(de.)21 b(W)l(e)16 b(list)g(exp)q(eriences)e
+(gained)149 1849 y(during)j(exp)q(erimen)o(ts)d(with)j(sev)o(eral)e(setups)i
+(of)g(name)f(serv)o(ers)f(and)j(trusting)f(hosts)g(in)f(a)i(lo)q(cal)149
+1939 y(area)f(net)o(w)o(ork.)223 2030 y(T)l(o)q(o)j(w)o(eak)f(assumptions)h
+(during)f(the)h(authen)o(tication)e(pro)q(cesses)i(cause)g(man)o(y)e(securit)
+o(y)149 2120 y(breac)o(hes.)28 b(W)l(e)18 b(state)h(the)f(securit)o(y)g
+(considerations)g(in)h(the)f(o\016cial)g(design)g(do)q(cumen)o(ts)g(and)149
+2210 y(analyze)12 b(the)g(algorithms)g(used)g(in)g(the)g(DNS)g(proto)q(col)h
+(lo)q(oking)g(for)g(w)o(eak)f(assumptions.)20 b(Using)149 2301
+y(a)g(wide)f(v)m(ariet)o(y)g(of)g(criteria,)g(w)o(e)g(discuss)h(sev)o(eral)e
+(approac)o(hes)i(to)g(solv)o(e)f(the)g(main)f(problem)149 2391
+y(in)g(the)g(Domain)f(Name)f(System)g(proto)q(col.)27 b(Tw)o(o)19
+b(of)f(these)f(solutions,)i(hardening)f(the)g(name)149 2481
+y(serv)o(er)g(and)i(using)f(cryptographic)g(metho)q(ds)f(for)h(strong)h
+(authen)o(tication,)f(receiv)o(e)d(more)i(at-)149 2571 y(ten)o(tion)e(than)h
+(the)f(other)g(solutions.)p eop
+%%Page: 2 3
+2 bop 794 1170 a Fo(DISCARD)16 b(THIS)f(P)l(A)o(GE)p eop
+%%Page: 3 4
+3 bop 1893 -100 a Fo(iii)777 342 y(T)l(ABLE)16 b(OF)g(CONTENTS)1847
+516 y(P)o(age)149 687 y(ABSTRA)o(CT)45 b Fn(:)24 b(:)g(:)h(:)f(:)h(:)f(:)h(:)
+f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h
+(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)93 b Fo(ii)149 845 y(LIST)17
+b(OF)f(T)l(ABLES)30 b Fn(:)24 b(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f
+(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f
+(:)g(:)81 b Fo(vi)149 1002 y(LIST)17 b(OF)f(FIGURES)40 b Fn(:)25
+b(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g
+(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)68 b Fo(vii)149
+1160 y(1.)36 b(INTR)o(ODUCTION)j Fn(:)24 b(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)
+f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f
+(:)g(:)96 b Fo(1)149 1318 y(2.)36 b(THE)16 b(DOMAIN)f(NAME)g(SYSTEM)27
+b Fn(:)e(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h
+(:)f(:)h(:)f(:)g(:)96 b Fo(5)223 1427 y(2.1)50 b(In)o(tro)q(duction)21
+b Fn(:)k(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h
+(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)96 b
+Fo(5)335 1487 y(2.1.1)56 b(The)16 b(TCP/IP)h(Proto)q(col)g(Suite)31
+b Fn(:)25 b(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f
+(:)g(:)96 b Fo(6)335 1547 y(2.1.2)56 b(In)o(ternet)15 b(Services)44
+b Fn(:)24 b(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f
+(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)96 b Fo(6)335 1608 y(2.1.3)56
+b(P)o(ac)o(k)o(et)15 b(Routing)34 b Fn(:)25 b(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f
+(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)96
+b Fo(7)335 1668 y(2.1.4)56 b(Name)14 b(Resolution)37 b Fn(:)24
+b(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h
+(:)f(:)h(:)f(:)g(:)96 b Fo(7)223 1728 y(2.2)50 b(Historical)15
+b(Dev)o(elopmen)o(t)j Fn(:)25 b(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h
+(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)96 b
+Fo(8)223 1788 y(2.3)50 b(Design)16 b(Goals)49 b Fn(:)24 b(:)h(:)f(:)h(:)f(:)h
+(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f
+(:)h(:)f(:)h(:)f(:)g(:)96 b Fo(9)335 1848 y(2.3.1)56 b(Data)17
+b(Consistency)27 b Fn(:)d(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h
+(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(10)335 1908
+y(2.3.2)56 b(E\016ciency)41 b Fn(:)24 b(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f
+(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72
+b Fo(10)335 1969 y(2.3.3)56 b(Distributed)16 b(Character)46
+b Fn(:)24 b(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h
+(:)f(:)h(:)f(:)g(:)72 b Fo(11)335 2029 y(2.3.4)56 b(Generalit)o(y)24
+b Fn(:)g(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h
+(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(11)335 2089
+y(2.3.5)56 b(Indep)q(endence)34 b Fn(:)24 b(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h
+(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72
+b Fo(11)223 2149 y(2.4)50 b(DNS)16 b(En)o(tities)44 b Fn(:)24
+b(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h
+(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(12)335 2209
+y(2.4.1)56 b(Domain)15 b(Name)g(Space)33 b Fn(:)25 b(:)f(:)h(:)f(:)h(:)f(:)h
+(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72
+b Fo(12)335 2270 y(2.4.2)56 b(DNS)16 b(Messages)e Fn(:)24 b(:)h(:)f(:)g(:)h
+(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h
+(:)f(:)g(:)72 b Fo(14)335 2330 y(2.4.3)56 b(Resource)16 b(Records)26
+b Fn(:)e(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h
+(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(17)335 2390 y(2.4.4)56 b(Name)14
+b(Serv)o(ers)33 b Fn(:)24 b(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h
+(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b
+Fo(18)335 2450 y(2.4.5)56 b(Resolv)o(ers)48 b Fn(:)24 b(:)h(:)f(:)h(:)f(:)g
+(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f
+(:)h(:)f(:)g(:)72 b Fo(19)223 2510 y(2.5)50 b(F)l(orw)o(ard)16
+b(and)h(In)o(v)o(erse)e(Mapping)h(T)l(ree)38 b Fn(:)25 b(:)f(:)h(:)f(:)h(:)f
+(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(20)223
+2571 y(2.6)50 b(Recursion)16 b(and)g(Iteration)d Fn(:)25 b(:)f(:)g(:)h(:)f(:)
+h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g
+(:)72 b Fo(22)223 2631 y(2.7)50 b(Filling)15 b(in)g(the)h(Blanks)42
+b Fn(:)24 b(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f
+(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(22)p eop
+%%Page: 4 5
+4 bop 1899 -100 a Fo(iv)1836 64 y(P)o(age)335 178 y(2.7.1)56
+b(Role)16 b(of)g(Cac)o(hes)48 b Fn(:)25 b(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h
+(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72
+b Fo(23)335 239 y(2.7.2)56 b(Role)16 b(of)g(Authorities)32
+b Fn(:)24 b(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h
+(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(23)335 299 y(2.7.3)56 b(Occurrence)15
+b(of)h(Errors)35 b Fn(:)25 b(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f
+(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(24)223 359 y(2.8)50
+b(Example:)19 b(Name)c(Resolution)47 b Fn(:)25 b(:)f(:)h(:)f(:)h(:)f(:)h(:)f
+(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72
+b Fo(24)223 419 y(2.9)50 b(The)16 b(Domain)g(Name)e(System)h(Proto)q(col)g
+Fn(:)25 b(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g
+(:)72 b Fo(26)335 479 y(2.9.1)56 b(Data)17 b(Structures)22
+b Fn(:)j(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f
+(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(26)335 540 y(2.9.2)56
+b(Name)14 b(Serv)o(er)h(Algorithm)47 b Fn(:)25 b(:)f(:)h(:)f(:)h(:)f(:)h(:)f
+(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(27)335
+600 y(2.9.3)56 b(Resolv)o(er)15 b(Algorithm)24 b Fn(:)g(:)h(:)f(:)h(:)f(:)h
+(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72
+b Fo(30)223 660 y(2.10)26 b(In)o(teraction)15 b(of)i(Name)d(Serv)o(er)h(and)i
+(Resolv)o(er)35 b Fn(:)24 b(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h
+(:)f(:)g(:)72 b Fo(31)335 720 y(2.10.1)32 b(Data)17 b(Flo)o(w)23
+b Fn(:)h(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h
+(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(32)335 780
+y(2.10.2)32 b(Shared)16 b(Information)25 b Fn(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h
+(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72
+b Fo(33)149 889 y(3.)36 b(DESCRIPTION)16 b(AND)f(DEMONSTRA)l(TION)g(OF)h
+(WEAKNESSES)j Fn(:)25 b(:)f(:)h(:)f(:)g(:)72 b Fo(35)223 998
+y(3.1)50 b(Statemen)o(t)14 b(of)j(the)f(Problem)41 b Fn(:)24
+b(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f
+(:)h(:)f(:)g(:)72 b Fo(35)223 1059 y(3.2)50 b(The)16 b(Problem)f(in)h(the)g
+(DNS)k Fn(:)k(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f
+(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(36)223 1119 y(3.3)50
+b(W)l(eaknesses)42 b Fn(:)25 b(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)
+f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)
+72 b Fo(38)335 1179 y(3.3.1)56 b(Assumptions)15 b(to)i(F)l(acilitate)e
+(Break{ins)d Fn(:)25 b(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)
+72 b Fo(38)335 1239 y(3.3.2)56 b(Authen)o(tication)15 b(via)h(Host)g(Names)34
+b Fn(:)25 b(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72
+b Fo(39)335 1299 y(3.3.3)56 b(T)l(rusting)17 b(a)f(Not)g(T)l(rust)o(w)o(orth)
+o(y)g(Source)34 b Fn(:)25 b(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f
+(:)g(:)72 b Fo(40)335 1359 y(3.3.4)56 b(Believing)14 b(Additional,)h(Not)h
+(Authoritativ)o(e)f(Information)49 b Fn(:)24 b(:)h(:)f(:)g(:)72
+b Fo(40)223 1420 y(3.4)50 b(Exploiting)16 b(the)g(Fla)o(ws)36
+b Fn(:)24 b(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f
+(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(41)335 1480
+y(3.4.1)56 b(Regular)16 b(Access)40 b Fn(:)25 b(:)f(:)g(:)h(:)f(:)h(:)f(:)h
+(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72
+b Fo(41)335 1540 y(3.4.2)56 b(The)16 b(\\Database)i(Mo)q(di\014cation")f
+(Approac)o(h)48 b Fn(:)25 b(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72
+b Fo(42)335 1600 y(3.4.3)56 b(The)16 b(\\Cac)o(he)g(P)o(oisoning")i(Approac)o
+(h)26 b Fn(:)e(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72
+b Fo(42)335 1660 y(3.4.4)56 b(The)16 b(\\Ask)g(Me!")21 b(Approac)o(h)40
+b Fn(:)24 b(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h
+(:)f(:)g(:)72 b Fo(43)223 1721 y(3.5)50 b(Implem)o(en)n(tation)14
+b(and)j(Exp)q(erimen)o(ts)33 b Fn(:)24 b(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f
+(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(45)335 1781
+y(3.5.1)56 b(Domain)15 b(and)i(Zone)g(Setup)35 b Fn(:)25 b(:)f(:)h(:)f(:)h(:)
+f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72
+b Fo(45)335 1841 y(3.5.2)56 b(Name)14 b(Serv)o(er)h(and)i(Resolv)o(er)e
+(Setup)47 b Fn(:)24 b(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g
+(:)72 b Fo(45)335 1901 y(3.5.3)56 b(T)l(rusting)17 b(Hosts)48
+b Fn(:)25 b(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h
+(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(46)335 1961 y(3.5.4)56
+b(Authen)o(tication)15 b(in)h(Berk)o(eley)d(\\r{Commands")18
+b Fn(:)24 b(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(47)335
+2022 y(3.5.5)56 b(Rev)o(erse)15 b(Lo)q(okup)i(T)l(ree)f(Manipulation)34
+b Fn(:)25 b(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72
+b Fo(48)335 2082 y(3.5.6)56 b(Cac)o(he)16 b(Corruption)22 b
+Fn(:)i(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)
+f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(48)223 2142 y(3.6)50 b(Exp)q(eriences)15
+b(Gained)21 b Fn(:)k(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f
+(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(50)335
+2202 y(3.6.1)56 b(Acquiring)15 b(Information)39 b Fn(:)24 b(:)h(:)f(:)h(:)f
+(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72
+b Fo(51)335 2262 y(3.6.2)56 b(Complexit)o(y)13 b(of)k(Mo)q(di\014cations)28
+b Fn(:)d(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g
+(:)72 b Fo(52)335 2323 y(3.6.3)56 b(Detecting)15 b(a)i(DNS)f(based)h
+(Break{in)42 b Fn(:)24 b(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f
+(:)g(:)72 b Fo(53)149 2432 y(4.)36 b(SECURITY)15 b(ANAL)l(YSIS)g(AND)h
+(SOLUTIONS)29 b Fn(:)c(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)
+f(:)g(:)72 b Fo(55)223 2540 y(4.1)50 b(Securit)o(y)14 b(Considerations)k(in)d
+(the)h(RF)o(C)g(1035)29 b Fn(:)24 b(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h
+(:)f(:)h(:)f(:)g(:)72 b Fo(55)223 2601 y(4.2)50 b(Analysis)15
+b(of)i(the)f(Name)e(Serv)o(er)i(Algorithm)21 b Fn(:)k(:)f(:)h(:)f(:)g(:)h(:)f
+(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(57)p eop
+%%Page: 5 6
+5 bop 1913 -100 a Fo(v)1836 64 y(P)o(age)223 178 y(4.3)50 b(Analysis)15
+b(of)i(the)f(Resolv)o(er)f(Algorithm)37 b Fn(:)25 b(:)f(:)h(:)f(:)h(:)f(:)g
+(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(58)223
+239 y(4.4)50 b(Ev)m(aluation)17 b(Criteria)30 b Fn(:)25 b(:)f(:)h(:)f(:)g(:)h
+(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h
+(:)f(:)g(:)72 b Fo(60)223 299 y(4.5)50 b(The)16 b(Berk)o(eley)e(P)o(atc)o(h)
+20 b Fn(:)25 b(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)
+h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(61)223
+359 y(4.6)50 b(Examining)15 b(Berk)o(eley)e(\\r{Commands")g
+Fn(:)25 b(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g
+(:)72 b Fo(62)223 419 y(4.7)50 b(Restricting)15 b(Public)g(Information)h
+(Access)f Fn(:)24 b(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h
+(:)f(:)g(:)72 b Fo(64)223 479 y(4.8)50 b(Adjusting)16 b(DNS)g(Up)q(date)h(In)
+o(terv)m(als)11 b Fn(:)25 b(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f
+(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(66)223 540 y(4.9)50
+b(Abandoning)17 b(the)f(Domain)f(Name)g(System)28 b Fn(:)d(:)f(:)h(:)f(:)g(:)
+h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(67)223
+600 y(4.10)26 b(Hardening)16 b(Name)e(Serv)o(ers)29 b Fn(:)24
+b(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h
+(:)f(:)h(:)f(:)g(:)72 b Fo(68)335 660 y(4.10.1)32 b(Problems)15
+b(Not)h(Exploiting)g(Cac)o(he)g(P)o(oisoning)41 b Fn(:)24 b(:)h(:)f(:)h(:)f
+(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(68)335 720 y(4.10.2)32 b(Problems)15
+b(Exploiting)h(Cac)o(he)g(P)o(oisoning)22 b Fn(:)i(:)g(:)h(:)f(:)h(:)f(:)h(:)
+f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(69)335 780 y(4.10.3)32 b(Keeping)16
+b(Additional)f(Information)24 b Fn(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)
+f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(70)335 841 y(4.10.4)32 b(Prev)o(en)o(tion)15
+b(of)h(Cac)o(he)g(P)o(oisoning)k Fn(:)k(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f
+(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(70)335 901 y(4.10.5)32
+b(Con)o(text)16 b(Cac)o(he)47 b Fn(:)25 b(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h
+(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72
+b Fo(71)335 961 y(4.10.6)32 b(Authorit)o(y)15 b(Cac)o(he)47
+b Fn(:)24 b(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f
+(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(72)335 1021 y(4.10.7)32
+b(Conditional)16 b(Cac)o(he)g(Use)29 b Fn(:)24 b(:)h(:)f(:)h(:)f(:)h(:)f(:)h
+(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b
+Fo(72)335 1081 y(4.10.8)32 b(Discussion)26 b Fn(:)e(:)h(:)f(:)h(:)f(:)g(:)h
+(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h
+(:)f(:)g(:)72 b Fo(73)223 1142 y(4.11)26 b(Cryptographic)17
+b(Metho)q(ds)f(for)h(Strong)g(Authen)o(tication)i Fn(:)24 b(:)h(:)f(:)h(:)f
+(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(73)335 1202 y(4.11.1)32 b(Data)17
+b(In)o(tegrit)o(y)h Fn(:)24 b(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h
+(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b
+Fo(74)335 1262 y(4.11.2)32 b(Originator)16 b(Authen)o(tication)35
+b Fn(:)24 b(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h
+(:)f(:)g(:)72 b Fo(75)335 1322 y(4.11.3)32 b(P)o(assing)17
+b(Creden)o(tials)e(to)i(Pro)o(v)o(e)e(Authorit)o(y)23 b Fn(:)h(:)h(:)f(:)h(:)
+f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(77)335 1382 y(4.11.4)32
+b(Example)21 b Fn(:)k(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f
+(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72
+b Fo(78)335 1443 y(4.11.5)32 b(Discussion)26 b Fn(:)e(:)h(:)f(:)h(:)f(:)g(:)h
+(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h
+(:)f(:)g(:)72 b Fo(81)149 1551 y(5.)36 b(CONCLUSIONS)15 b(AND)h(OUTLOOK)30
+b Fn(:)24 b(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h
+(:)f(:)h(:)f(:)g(:)72 b Fo(83)149 1709 y(BIBLIOGRAPHY)44 b
+Fn(:)24 b(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f
+(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72
+b Fo(85)p eop
+%%Page: 6 7
+6 bop 1894 -100 a Fo(vi)847 342 y(LIST)16 b(OF)g(T)l(ABLES)149
+516 y(T)l(able)1580 b(P)o(age)149 687 y(2.1)60 b(Subset)17
+b(of)f(QTYPEs)21 b Fn(:)k(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h
+(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72
+b Fo(19)149 796 y(2.2)60 b(Example)15 b(steps)h(in)g(name)f(resolution)h
+Fn(:)24 b(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f
+(:)h(:)f(:)g(:)72 b Fo(26)149 905 y(3.1)60 b(Regular)17 b(access)41
+b Fn(:)25 b(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f
+(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72
+b Fo(41)149 1014 y(3.2)60 b(The)17 b(\\Database)h(Mo)q(di\014cation")f
+(approac)o(h)50 b Fn(:)24 b(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h
+(:)f(:)h(:)f(:)g(:)72 b Fo(42)149 1123 y(3.3)60 b(The)17 b(\\Cac)o(he)f(P)o
+(oisoning")h(approac)o(h)28 b Fn(:)c(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h
+(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(43)149 1232
+y(4.1)60 b(Example:)20 b(certi\014cate)15 b(v)m(alidation)41
+b Fn(:)25 b(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f
+(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(79)149 1341 y(4.2)60 b(Example:)20
+b(legend)c(of)g(abbreviations)22 b Fn(:)i(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g
+(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(79)p
+eop
+%%Page: 7 8
+7 bop 1880 -100 a Fo(vii)833 342 y(LIST)17 b(OF)f(FIGURES)149
+516 y(Figure)1560 b(P)o(age)149 687 y(2.1)60 b(Domain)16 b(purdue.edu)45
+b Fn(:)24 b(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g
+(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(12)149
+796 y(2.2)60 b(Domain)16 b(vs.)21 b(zone)32 b Fn(:)24 b(:)h(:)f(:)h(:)f(:)h
+(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f
+(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(13)149 905 y(2.3)60 b(DNS)17
+b(message)24 b Fn(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h
+(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72
+b Fo(14)149 1014 y(2.4)60 b(The)17 b(in-addr.arpa)g(domain)45
+b Fn(:)25 b(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h
+(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(21)149 1123 y(2.5)60
+b(Degree)16 b(of)h(sp)q(eci\014cation)26 b Fn(:)f(:)f(:)h(:)f(:)g(:)h(:)f(:)h
+(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g
+(:)72 b Fo(21)149 1232 y(2.6)60 b(Example)15 b(name)g(resolution)41
+b Fn(:)25 b(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h
+(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(25)149 1341 y(2.7)60
+b(Name)15 b(serv)o(er)g(algorithm)j Fn(:)25 b(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f
+(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72
+b Fo(28)149 1450 y(2.8)60 b(Resolv)o(er)15 b(algorithm)26 b
+Fn(:)f(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)
+h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(30)149
+1559 y(2.9)60 b(Data)18 b(\015o)o(w)e(b)q(et)o(w)o(een)g(DNS)g(en)o(tities)e
+Fn(:)25 b(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h
+(:)f(:)h(:)f(:)g(:)72 b Fo(32)149 1668 y(3.1)60 b(Exp)q(erimen)o(tal)14
+b(setup)51 b Fn(:)24 b(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)
+h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72
+b Fo(36)149 1777 y(3.2)60 b(Algorithm)15 b(of)h(the)g(Berk)o(eley)e(patc)o(h)
+46 b Fn(:)24 b(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)
+h(:)f(:)h(:)f(:)g(:)72 b Fo(49)149 1886 y(3.3)60 b(Additional)16
+b(false)g(resource)g(record)22 b Fn(:)j(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f
+(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(50)149
+1995 y(3.4)60 b(Mo)q(di\014cations)17 b(in)f(name)f(serv)o(er)g(co)q(de)47
+b Fn(:)25 b(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f
+(:)h(:)f(:)g(:)72 b Fo(51)149 2104 y(4.1)60 b(Application)16
+b(of)g(a)h(message)e(digest)h(algorithm)33 b Fn(:)25 b(:)f(:)h(:)f(:)g(:)h(:)
+f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(74)149 2213
+y(4.2)60 b(Digital)16 b(signature)h(generation)f(and)h(v)m(alidation)51
+b Fn(:)24 b(:)h(:)f(:)g(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72
+b Fo(76)149 2321 y(4.3)60 b(Example:)20 b(certi\014cate)15
+b(v)m(alidation)41 b Fn(:)25 b(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)h(:)
+f(:)h(:)f(:)h(:)f(:)h(:)f(:)h(:)f(:)g(:)72 b Fo(80)p eop
+%%Page: 8 9
+8 bop 1883 -100 a Fo(viii)776 342 y(A)o(CKNO)o(WLEDGMENTS)223
+516 y(W)l(e)15 b(w)o(ould)h(lik)o(e)e(to)j(thank)f(the)f(German-American)e(F)
+l(ulbrigh)o(t)i(Commission)f(for)i(a)h(sc)o(hol-)149 606 y(arship)25
+b(that)f(made)f(this)h(w)o(ork)g(p)q(ossible.)45 b(Thanks)25
+b(to)f(Stev)o(en)f(Bello)o(vin)f(whose)j(v)m(aluable)149 696
+y(commen)o(ts)12 b(are)j(most)e(appreciated)i(and)g(Dan)g(T)l(rinkle)e(who)j
+(sho)o(w)o(ed)e(us)h(ho)o(w)g(to)g(master)e(some)149 787 y(of)k(the)f(subtle)
+g(di\016culties)e(of)j(the)f(DNS.)p eop
+%%Page: 1 10
+9 bop 1925 -100 a Fo(1)815 342 y(1.)33 b(INTR)o(ODUCTION)223
+516 y(The)19 b(In)o(ternet)f(is)h(a)h(widespread)f(conglomeration)f(of)i(h)o
+(undreds)f(of)h(thousands)h(of)e(in)o(ter-)149 606 y(connected)d
+(heterogeneous)h(net)o(w)o(orks)f(and)h(hosts.)22 b(The)17
+b(design)f(of)h(the)f(In)o(ternet)f(is)h(based)h(on)149 696
+y(a)g(proto)q(col)g(hierarc)o(h)o(y)l(.)j(There)c(exist)f(m)o(ultiple)e
+(implem)o(en)o(tations)h(of)i(these)g(proto)q(cols.)223 787
+y(Computers)k(comm)o(unicate)e(with)j(eac)o(h)g(other)g(on)h(the)f(basis)h
+(of)g(di\013eren)o(t)e(t)o(yp)q(es)h(of)h(ad-)149 877 y(dresses;)e(on)e(the)g
+(ph)o(ysical)g(la)o(y)o(er)f(using)h(lo)o(w{lev)o(el)f(ph)o(ysical)g
+(addresses)i(lik)o(e)e(Ethernet)1820 859 y Fm(1)1857 877 y
+Fo(card)149 967 y(addresses,)25 b(on)f(the)e(data)i(link)e(to)h(presen)o
+(tation)g(la)o(y)o(er)e(using)i(host)h(addresses)f(suc)o(h)g(as)h(IP)149
+1057 y(addresses)347 1039 y Fm(2)368 1057 y Fo(,)15 b(and)h(on)g(the)f
+(application)g(la)o(y)o(er)f(using)i(high{lev)o(el,)d(pronounceable)j(host)g
+(names.)223 1148 y(One)j(of)h(the)g(managemen)o(t)e(tasks)i(in)g(the)f(In)o
+(ternet)g(is)h(the)f(mapping)h(of)g(lo)o(w)o(er)f(lev)o(el)f(ad-)149
+1238 y(dresses)e(to)h(host)f(names.)k(A)c(\014rst)g(naiv)o(e)f(approac)o(h)i
+(is)e(to)i(collect)d(all)i(name{to{address)g(map-)149 1328
+y(pings)g(in)g(a)g(single)f(\014le.)20 b(That)d(w)o(as)f(also)g(the)f
+(\014rst)h(approac)o(h)h(tak)o(en)e(in)g(the)h(In)o(ternet.)j(The)d(\014le)
+149 1419 y(\\HOSTS.TXT")f(con)o(tained)f(the)h(name{to{address)g(mapping)f
+(for)h(ev)o(ery)e(host)i(connected)f(to)149 1509 y(the)i(ARP)l(ANET.)223
+1599 y(The)i(task)h(of)g(naming)f(hosts)h(and)g(net)o(w)o(ork)f(domains)g(is)
+h(addressed)g(b)o(y)f(creating)g(a)h(hier-)149 1689 y(arc)o(hical)h(relation)
+g(b)q(et)o(w)o(een)f(domains,)h(with)h(hosts)g(as)g(the)f(furthest)g
+(descendan)o(ts)h(from)e(an)149 1780 y(arti\014cial)h(ro)q(ot)h(domain.)32
+b(By)20 b(app)q(ending)h(the)f(domain)f(lab)q(els)h(one)h(after)f(the)g
+(other)g(to)h(the)149 1870 y(host)15 b(lab)q(els)f(on)g(the)g(path)g(up)g(to)
+g(the)g(ro)q(ot)h(in)e(the)h(hierarc)o(hical)e(tree,)h(a)h(unique,)g(memoriz)
+o(able,)149 1960 y(and)j(usually)f(pronounceable)h(iden)o(ti\014er)d(is)i
+(created:)21 b(the)16 b(host)h(name.)223 2051 y(The)d(mapping,)g(or)h
+(binding,)f(of)h(IP)g(addresses)g(to)g(host)g(names)f(b)q(ecame)f(a)i(ma)s
+(jor)f(problem)149 2141 y(in)h(the)h(rapidly)e(gro)o(wing)i(In)o(ternet.)k
+(This)15 b(thesis)g(do)q(es)i(not)e(deal)g(with)h(the)f(mapping)f(b)q(et)o(w)
+o(een)149 2231 y(addresses)19 b(on)e(the)h(ph)o(ysical)e(la)o(y)o(er)g(and)i
+(transp)q(ort)h(la)o(y)o(er,)d(whic)o(h)h(is)g(solv)o(ed)g(b)o(y)g(ARP)1787
+2213 y Fm(3)1824 2231 y Fo(in)g(the)149 2322 y(UNIX)278 2303
+y Fm(4)313 2322 y Fo(proto)q(col)g(suite,)e(but)h(with)h(the)f(mapping)f(b)q
+(et)o(w)o(een)g(host)i(names)f(and)h(IP)f(addresses.)p 149
+2365 720 2 v 206 2396 a Fl(1)224 2411 y Fk(Ethernet)g(is)e(a)f(registered)j
+(trademark)d(of)g(Xero)o(x)h(Corp)q(oration)206 2446 y Fl(2)224
+2461 y Fk(\\32-bit)f(addresses)j(assigned)e(to)g(hosts)g(that)g(w)o(an)o(t)g
+(to)f(participate)h(in)g(a)f(TCP/IP)i(in)o(ternet")f([Com91)m(])206
+2495 y Fl(3)224 2511 y Fk(\\Address)h(Resolution)e(Proto)q(col)h({)f(used)i
+(to)e(dynamically)e(bind)i(a)h(high)f(lev)o(el)g(IP)h(address)h(to)f(a)f(lo)o
+(w)g(lev)o(el)149 2560 y(ph)o(ysical)h(hardw)o(are)g(address")h([Com91)m(])
+206 2595 y Fl(4)224 2610 y Fk(UNIX)f(is)g(a)g(trademark)f(of)g(A)m(T&T)h
+(Bell)g(Lab)q(oratories)p eop
+%%Page: 2 11
+10 bop 1925 -100 a Fo(2)223 75 y(This)13 b(higher)f(lev)o(el)f(binding)i
+(e\013ort)h(w)o(en)o(t)e(through)i(di\013eren)o(t)e(stages)i(of)f(dev)o
+(elopmen)o(t)d(up)j(to)149 165 y(the)g(curren)o(tly)e(used)i(Domain)f(Name)f
+(System.)19 b(The)12 b(Domain)g(Name)f(System,)h(with)g(its)h(Berk)o(e-)149
+255 y(ley)19 b(UNIX)f(implem)o(en)o(tati)o(on)g(called)g(BIND)997
+237 y Fm(5)1016 255 y Fo(,)h(is)h(a)g(distributed)f(naming)f(resolution)i
+(system)149 346 y(used)d(b)o(y)f(most)g(net)o(w)o(ork)g(services)g(a)o(v)m
+(ailable)g(throughout)i(the)f(In)o(ternet.)k(It)16 b(w)o(orks)h(transpar-)149
+436 y(en)o(tly)j(for)h(the)f(user)h(who)g(sends)g(email,)e(accesses)i
+(another)g(host)g(via)g(\\telnet")f(or)h(\\rlogin,")149 526
+y(or)d(transfers)g(some)e(\014les)h(via)g(\\ftp")h(from)e(another)i(site)e
+(to)i(his)f(o)o(wn)h(mac)o(hine.)k(The)17 b(Domain)149 616
+y(Name)12 b(System)f(pro)o(vides)i(name)e(binding)i(in)g(b)q(oth)h
+(directions:)19 b(giv)o(en)12 b(a)h(host)h(name,)e(it)g(returns)149
+707 y(the)k(appropriate)h(IP)f(addresses,)h(and)g(vice)d(v)o(ersa.)223
+797 y(Before)d(hosts)h(gran)o(t)h(net)o(w)o(ork)e(services)g(to)h(users,)h
+(an)f(authen)o(tication)f(pro)q(cess)i(tak)o(es)f(place,)149
+887 y(where)19 b(the)g(users')g(access)g(righ)o(ts,)g(and)h(the)f(iden)o(tit)
+o(y)e(of)i(connecting)g(hosts)h(get)f(scrutinized,)149 978
+y(according)c(to)g(pro)o(vider)e(p)q(olicies.)20 b(These)14
+b(examinations)f(are)h(usually)g(based)h(up)q(on)g(iden)o(ti\014ca-)149
+1068 y(tion)h(b)o(y)e(login)h(name,)f(passw)o(ord)i(and)g(host)g(name.)j(In)c
+(some)f(cases)i(it)e(is)h(su\016cien)o(t)f(to)h(pro)o(vide)149
+1158 y(the)h(righ)o(t)g(names,)f(and)i(access)f(is)g(gran)o(ted)h(without)f
+(sp)q(ecifying)g(an)o(y)g(passw)o(ord)h(at)g(all.)223 1248
+y(Some)h(Berk)o(eley)e(\\r{commands")i(o\013er)i(net)o(w)o(ork)e(services)g
+(for)h(whic)o(h)g(it)g(is)f(su\016cien)o(t)g(to)149 1339 y(v)o(erify)d(user)i
+(name)f(and)h(host)g(name)f(to)h(gran)o(t)g(complete)d(access.)23
+b(As)16 b(the)h(remote)e(user)i(name)149 1429 y(is)g(sp)q(eci\014ed)f(b)o(y)f
+(the)i(connecting)f(site,)f(the)h(authen)o(tication)g(is)g(based)h(up)q(on)h
+(the)e(name)f(of)i(the)149 1519 y(connecting)j(mac)o(hine.)30
+b(A)19 b(mac)o(hine)f(that)i(o\013ers)h(services)d(can)i(acquire)f
+(information)g(ab)q(out)149 1610 y(the)g(so)q(c)o(k)o(et)g(that)h(is)f(used)g
+(b)o(y)g(the)g(connecting)g(site.)29 b(A)19 b(so)q(c)o(k)o(et)f(is)h(a)h
+(tuple)f(consisting)g(of)h(IP)149 1700 y(address,)g(p)q(ort,)g(and)g(proto)q
+(col)g(used)f(b)o(y)g(the)f(remote)g(site.)29 b(T)l(o)19 b(v)o(erify)f(the)g
+(host)i(name,)e(it)h(is)149 1790 y(the)e(task)g(of)h(the)e(Domain)g(Name)g
+(System)f(to)i(map)f(the)h(IP)f(address)i(on)f(the)g(host)h(name.)k(W)l(e)149
+1880 y(examine)14 b(this)j(case)f(more)f(closely)g(later)h(in)g(this)g
+(thesis.)223 1971 y(Because)c(the)h(Domain)f(Name)g(System)f(is)i
+(distributed)g(among)g(man)o(y)f(thousands)i(of)g(hosts,)149
+2061 y(it)d(can)g(b)q(e)h(a)f(critical)f(mistak)o(e)f(to)i(blindly)f(trust)h
+(the)g(resolv)o(ed)f(binding.)20 b(This)11 b(thesis)g(sho)o(ws)h(that)149
+2151 y(under)f(some)f(assumptions)h(it)f(is)h(no)g(ma)s(jor)f(e\013ort)h(to)h
+(falsify)e(the)g(host)i(name)d(and)j(authorization)149 2242
+y(for)17 b(a)g(system.)223 2332 y(Although)j(this)f(problem)f(has)j(b)q(een)f
+(kno)o(wn)f(for)i(some)d(y)o(ears)i(no)o(w,)g(not)g(man)o(y)f(publica-)149
+2422 y(tions)i(deal)e(with)h(it.)32 b([Bel90b)o(])20 b(is)g(the)f(main)g(pap)
+q(er)i(w)o(e)e(can)h(men)o(tion)f(as)h(related)f(w)o(ork.)33
+b(It)149 2512 y(demonstrates)16 b(the)g(sub)o(v)o(ersion)f(of)h(system)f
+(securit)o(y)g(using)h(the)g(Domain)f(Name)f(System)h(and)p
+149 2556 720 2 v 206 2587 a Fl(5)224 2602 y Fk(Berk)o(eley)g(In)o(ternet)g
+(Name)e(Domain)p eop
+%%Page: 3 12
+11 bop 1925 -100 a Fo(3)149 75 y(discusses)19 b(p)q(ossible)g(defenses)g
+(against)h(the)f(attac)o(k)f(and)i(limitations)d(on)i(their)f(applicabilit)o
+(y)l(.)149 165 y(An)h(earlier)e(pap)q(er)i(b)o(y)f(Stev)o(en)f(Bello)o(vin)f
+(\([Bel89)o(]\))i(has)i(already)e(men)o(tioned)e(the)i(p)q(ossibilit)o(y)149
+255 y(of)f(abuse)g(of)g(the)g(Domain)e(Name)g(System.)21 b(That)c(pap)q(er)g
+(follo)o(ws)g(suggestions)g(from)f(P)o(aul)g(V.)149 346 y(Mo)q(c)o(k)m(ap)q
+(etris,)g(the)g(designer)g(of)h(the)f(Domain)f(Name)g(System.)223
+436 y(The)f(main)g(b)q(o)q(dy)h(of)g(this)g(thesis)f(consists)h(of)g(three)f
+(c)o(hapters)g(follo)o(w)o(ed)g(b)o(y)g(a)h(\014nal)g(c)o(hapter)149
+526 y(dra)o(wing)i(conclusions)f(and)h(giving)f(suggestions)i(for)e(future)g
+(w)o(ork.)223 616 y(The)e(\014rst)h(of)g(these)g(three)f(c)o(hapters,)g
+(Chapter)h(2,)g(describ)q(es)f(the)h(p)q(osition)g(and)g(role)g(of)g(the)149
+707 y(Domain)h(Name)f(System)g(in)h(its)h(frame,)e(the)h(In)o(ternet.)21
+b(It)16 b(giv)o(es)g(a)h(short)g(historical)f(sk)o(etc)o(h)f(of)149
+797 y(the)h(In)o(ternet)e(and)i(describ)q(es)f(the)g(Domain)g(Name)f(System)g
+(on)i(a)f(high)h(lev)o(el.)j(In)c(that)h(section)149 887 y(w)o(e)g(go)i(in)o
+(to)e(as)h(m)o(uc)o(h)d(detail)i(as)h(necessary)f(to)h(build)f(up)h(the)f
+(necessary)g(bac)o(kground)h(for)g(the)149 978 y(succeeding)g(c)o(hapters.)26
+b(W)l(e)18 b(in)o(tro)q(duce)f(the)g(tec)o(hnical)f(terms)h(and)h(explain)f
+(the)h(mec)o(hanism)o(s)149 1068 y(cen)o(tral)d(to)g(the)g(understanding)h
+(of)g(the)f(Domain)f(Name)g(System)g(and)h(the)h(exploitation)e(of)i(its)149
+1158 y(w)o(eaknesses.)21 b(W)l(e)14 b(giv)o(e)f(an)i(example)d(of)j(a)f(name)
+f(resolution)i(and)f(the)g(description)g(of)h(the)f(data)149
+1248 y(structures)j(and)f(algorithms)g(used)g(b)o(y)g(name)f(serv)o(ers)g
+(and)i(resolv)o(ers.)223 1339 y(Chapter)h(3)h(states)g(precisely)e(the)h
+(main)f(problem)g(w)o(e)h(are)g(addressing.)29 b(W)l(e)18 b(explain)g(the)149
+1429 y(main)d(problem)g(in)h(sev)o(eral)f(stages,)h(giving)g(more)f(details)g
+(from)g(section)h(to)g(section.)21 b(First)16 b(w)o(e)149 1519
+y(describ)q(e)d(the)h(problem)e(at)i(a)g(high)g(lev)o(el.)k(Then)c(w)o(e)f
+(sho)o(w)i(the)e(existence)f(of)i(the)f(problem)g(with)149
+1610 y(the)i(Domain)f(Name)f(System.)19 b(W)l(e)c(express)g(the)f
+(assumptions)h(and)g(examine)e(the)i(w)o(eaknesses)149 1700
+y(in)c(the)g(Domain)f(Name)g(System)f(that)j(lead)e(to)i(the)f(p)q(ossibilit)
+o(y)f(of)h(gaining)g(unauthorized)h(access)149 1790 y(to)20
+b(a)g(certain)e(t)o(yp)q(e)h(of)h(remote)e(host.)31 b(In)19
+b(Chapter)g(3)h(w)o(e)f(demonstrate)f(the)h(exploitation)g(of)149
+1880 y(the)i(securit)o(y)f(\015a)o(ws)i(b)o(y)f(giving)g(details)f(of)i(an)f
+(arti\014cial)g(setup)g(that)h(leads)f(step)o(wise)f(to)i(an)149
+1971 y(unauthorized)e(login)g(on)h(another)f(host.)33 b(W)l(e)20
+b(close)f(the)h(c)o(hapter)f(with)h(exp)q(eriences)e(gained)149
+2061 y(during)f(our)g(exp)q(erimen)o(ts.)223 2151 y(Concluding)f(the)f(main)g
+(b)q(o)q(dy)i(of)f(this)g(thesis,)g(Chapter)g(4)g(analyzes)g(the)g(curren)o
+(t)f(securit)o(y)149 2242 y(features)20 b(in)f(the)g(Domain)g(Name)e(System)h
+(and)i(presen)o(ts)f(solutions)h(to)g(the)f(giv)o(en)f(problem.)149
+2332 y(The)d(\014rst)f(part)h(con)o(tains)g(the)f(securit)o(y)f
+(considerations)h(in)g(the)h(RF)o(C)f(and)h(a)f(securit)o(y)f(analysis)149
+2422 y(of)k(the)e(name)g(serv)o(er)f(and)j(resolv)o(er)d(algorithms.)21
+b(Some)14 b(of)i(the)g(solutions)g(in)g(the)f(second)h(part)149
+2512 y(are)i(already)e(impleme)o(n)o(ted)e(and)k(running)f(in)g(patc)o(hed)f
+(v)o(ersions)h(of)g(system)f(soft)o(w)o(are,)h(or)g(are)149
+2603 y(follo)o(w)o(ed)g(b)o(y)f(organizational)i(p)q(olicies;)f(others)g(are)
+g(still)g(in)f(an)i(early)f(stage)g(of)h(dev)o(elopmen)o(t.)p
+eop
+%%Page: 4 13
+12 bop 1925 -100 a Fo(4)149 75 y(Eac)o(h)22 b(of)f(the)g(solutions)h(presen)o
+(ted)e(is)h(discussed)g(in)g(this)g(c)o(hapter)g(and)g(ev)m(aluated)g(using)h
+(a)149 165 y(wide)16 b(v)m(ariet)o(y)f(of)i(criteria.)223 255
+y(The)h(approac)o(h,)i(and)f(its)f(discussion,)h(of)g(com)o(bining)e(partial)
+i(solutions)g(to)g(a)g(dense)f(net-)149 346 y(w)o(ork,)g(are)g(part)g(of)g
+(the)g(concluding)f(c)o(hapter.)26 b(Ev)o(en)17 b(if)g(these)h(in)o(terw)o(o)
+o(v)o(en)d(solutions)k(do)f(not)149 436 y(guaran)o(tee)f(the)f(securit)o(y)f
+(of)h(a)h(system,)d(at)j(least)f(they)g(increase)f(the)h(con\014dence)g(in)g
+(it.)p eop
+%%Page: 5 14
+13 bop 1925 -100 a Fo(5)655 342 y(2.)32 b(THE)16 b(DOMAIN)f(NAME)g(SYSTEM)223
+516 y(This)j(c)o(hapter)h(describ)q(es)f(the)h(p)q(osition)g(and)g(role)g(of)
+g(the)f(Domain)g(Name)f(System)g(in)i(its)149 606 y(frame,)14
+b(the)g(In)o(ternet.)19 b(W)l(e)c(start)g(o\013)g(b)o(y)f(talking)g(ab)q(out)
+i(the)f(In)o(ternet,)e(the)h(TCP/IP)i(proto)q(col)149 696 y(suite,)i(In)o
+(ternet)e(services,)g(routing,)i(and)h(\014nally)e(the)g(need)g(for)h(name)f
+(resolution.)25 b(It)18 b(follo)o(ws)149 787 y(an)23 b(outline)e(of)i(the)f
+(historical)f(dev)o(elopmen)o(t)e(of)j(the)g(Domain)f(Name)g(System)f(that)j
+(led)e(to)149 877 y(the)h(curren)o(t)e(system.)36 b(W)l(e)21
+b(describ)q(e)g(the)g(design)h(goals)g(of)g(the)f(curren)o(t)g(system)f(for)i
+(name)149 967 y(resolution)14 b(in)g(the)g(In)o(ternet)f(and)h(its)g(in)o
+(teracting)f(en)o(tities.)19 b(W)l(e)14 b(also)g(talk)g(ab)q(out)h(forw)o
+(ard)g(and)149 1057 y(rev)o(erse)d(mapping)g(trees,)g(and)i(recursiv)o(e)d
+(and)i(iterativ)o(e)e(resolving)h(tec)o(hniques.)19 b(The)13
+b(follo)o(wing)149 1148 y(section)18 b(con)o(tains)g(some)f(additional)g
+(remarks)g(ab)q(out)i(topics)f(that)g(w)o(ere)f(already)h(men)o(tioned)149
+1238 y(but)f(deserv)o(e)e(a)h(more)f(detailed)h(treatmen)o(t.)223
+1328 y(Before)25 b(describing)g(the)h(concrete)g(data)h(structures)f(and)g
+(algorithms)g(used)g(b)o(y)g(name)149 1419 y(serv)o(ers)16
+b(and)h(resolv)o(ers)f(w)o(e)g(giv)o(e)g(an)h(example)d(of)j(a)g(name)e
+(resolution.)22 b(This)17 b(example)d(should)149 1509 y(pro)o(vide)d(a)h(go)q
+(o)q(d)i(understanding)e(of)g(the)g(algorithms)e(and)j(the)e(in)o(teraction)g
+(of)h(all)f(participating)149 1599 y(en)o(tities)k(in)h(the)g(distributed)g
+(Domain)f(Name)g(System.)223 1689 y(Wherev)o(er)h(it)h(is)h(necessary)f(to)h
+(pro)o(vide)f(more)g(sp)q(eci\014c)g(descriptions)g(of)h(concepts)g(or)g(the)
+149 1780 y(impleme)o(n)o(tation)9 b(of)k(the)f(Domain)f(Name)f(System,)h(w)o
+(e)h(co)o(v)o(er)f(the)g(resp)q(ectiv)o(e)g(topics)h(in)f(greater)149
+1870 y(detail.)149 2035 y(2.1)50 b(In)o(tro)q(duction)223 2175
+y(T)l(o)17 b(understand)g(the)f(role)h(that)g(the)f(DNS)h(pla)o(ys,)e(w)o(e)i
+(start)g(b)o(y)f(in)o(tro)q(ducing)g(the)h(In)o(ternet)149
+2265 y(in)f(general)g(\(see)g([Com91,)g(Preface)f(and)i(c)o(hapter)f(1]\).)
+223 2356 y(Data)g(comm)o(unic)o(ation)d(has)j(b)q(ecome)d(a)j(fundamen)o(tal)
+e(part)h(of)h(computing.)j(Hosts)d(gather)149 2446 y(information)k(w)o
+(orldwide)g(and)i(their)e(users)h(w)o(an)o(t)f(to)h(exc)o(hange)g(data)g(and)
+g(use)g(remote)e(ser-)149 2536 y(vices)d(for)h(di\013eren)o(t)f(purp)q(oses.)
+24 b(Common)16 b(in)o(terests,)f(shared)j(b)o(y)e(p)q(eople)h(that)g(liv)o(e)
+e(and)i(w)o(ork)149 2626 y(thousands)j(of)f(miles)d(a)o(w)o(a)o(y)i(from)g
+(eac)o(h)f(other,)i(created)f(the)g(need)g(for)h(e\016cien)o(t)d(and)j
+(reliable)p eop
+%%Page: 6 15
+14 bop 1925 -100 a Fo(6)149 75 y(data)22 b(comm)o(unic)o(ation.)32
+b(What)22 b(started)f(b)q(efore)f(1960)j(with)d(the)h(dev)o(elopmen)o(t)c(of)
+k(informa-)149 165 y(tion)16 b(theory)l(,)f(the)h(sampling)e(theorem,)g(and)i
+(the)f(\014eld)h(of)f(signal)h(pro)q(cessing,)g(b)q(ecame)e(around)149
+255 y(the)19 b(mid)d(1960s)k(the)e(question)g(of)h(ho)o(w)g(to)g(transmit)e
+(data)i(pac)o(k)o(ets)e(in)h(lo)q(cal)h(area)f(net)o(w)o(orks.)149
+346 y(The)i(In)o(ternet)f(con)o(tains)h(and)g(pro)o(vides)f(ev)o(en)g(more:)
+27 b(in)o(ternet)o(w)o(ork)18 b(tec)o(hnologies,)i(proto)q(col)149
+436 y(la)o(y)o(ering)c(mo)q(dels,)f(and)j(datagram)f(and)g(stream)f(transp)q
+(ort)i(services)e(b)q(et)o(w)o(een)g(hosts)i(on)f(p)q(os-)149
+526 y(sibly)e(di\013eren)o(t)g(net)o(w)o(orks,)g(that)h(together)g
+(constitute)f(an)h(in)o(terconnected)e(arc)o(hitecture)g(that)149
+616 y(functions)j(as)g(a)f(single)g(uni\014ed)g(comm)o(unic)o(ation)e
+(system.)149 776 y(2.1.1)49 b(The)17 b(TCP/IP)g(Proto)q(col)g(Suite)223
+899 y(The)i(need)g(and)h(imp)q(ortance)f(of)h(in)o(ternet)e(tec)o(hnology)h
+(w)o(as)h(recognized)f(b)o(y)g(go)o(v)o(ernmen)o(t)149 989
+y(agencies,)k(whic)o(h)e(resulted)f(in)i(its)f(dev)o(elopmen)o(t)e(b)o(y)i(D)
+o(ARP)l(A)1367 971 y Fm(1)1385 989 y Fo(.)h(The)f(D)o(ARP)l(A)g(tec)o
+(hnology)149 1079 y(includes)14 b(net)o(w)o(ork)g(standards)i(that)f(sp)q
+(ecify)f(details)g(and)h(con)o(v)o(en)o(tions)e(of)i(computer)e(comm)o(u-)149
+1170 y(nication,)18 b(net)o(w)o(ork)g(in)o(terconnection,)f(and)h(tra\016c)g
+(routing.)28 b(\\TCP/IP)1536 1152 y Fm(2)1557 1170 y Fo(,")18
+b(an)h(abbreviation)149 1260 y(of)g(the)g(o\016cial)e(name)h(\\TCP/IP)i(In)o
+(ternet)d(Proto)q(col)i(Suite,")g(can)g(b)q(e)f(used)h(to)g(set)g(up)f(com-)
+149 1350 y(m)o(unication)h(b)q(et)o(w)o(een)h(an)o(y)h(set)f(of)h(in)o
+(terconnected)e(hosts)j(or)f(net)o(w)o(orks.)34 b(It)20 b(is)h(notew)o(orth)o
+(y)149 1441 y(that)h(TCP/IP)g(is)f(one)g(of)g(man)o(y)f(p)q(ossible)h(tec)o
+(hnologies)g(that)g(could)g(b)q(e)g(used)h(to)f(comp)q(ose)149
+1531 y(in)o(terconnected)15 b(net)o(w)o(orks;)g(one)i(that)f(has)h
+(demonstrated)f(its)g(viabilit)o(y)e(on)j(a)f(large)h(scale.)149
+1691 y(2.1.2)49 b(In)o(ternet)15 b(Services)223 1813 y(Users)j(are)h(usually)
+f(not)h(in)o(terested)e(in)i(the)f(underlying)g(tec)o(hnologies)g(of)h(the)g
+(In)o(ternet)e({)149 1904 y(their)j(in)o(terest)f(is)h(the)f(utilization)g
+(of)i(net)o(w)o(ork)e(services.)32 b(The)20 b(la)o(y)o(ered)e(design)i(of)h
+(TCP/IP)149 1994 y(pro)o(vides)c(the)h(necessary)f(means)f(for)i
+(transparency)g(in)f(comm)o(unication)e(and)j(hiding)f(details)149
+2084 y(from)j(the)g(high)g(lev)o(el)e(applications.)33 b(Services)19
+b(can)h(b)q(e)h(partitioned)f(in)o(to)g(application)g(lev)o(el)149
+2174 y(in)o(ternet)f(services)g(and)h(net)o(w)o(ork)f(lev)o(el)f(in)o(ternet)
+h(services.)30 b(Examples)19 b(of)h(application)g(lev)o(el)149
+2265 y(services)13 b(are)h(electronic)e(mail,)g(\014le)h(transfer,)h(and)g
+(remote)e(login.)20 b(The)14 b(net)o(w)o(ork)f(lev)o(el)f(services)149
+2355 y(\\connectionless)19 b(pac)o(k)o(et)f(deliv)o(ery)f(service")h(and)h
+(\\reliable)f(stream)g(transp)q(ort)i(service")e(are)149 2445
+y(used)c(b)o(y)f(the)h(net)o(w)o(ork)f(application)g(programmer)f(and)i
+(remain)e(hidden)h(from)f(the)i(application)p 149 2489 720
+2 v 206 2520 a Fl(1)224 2535 y Fk(Defense)h(Adv)n(anced)g(Researc)o(h)g(Pro)r
+(jects)g(Agency)206 2569 y Fl(2)224 2585 y Fk(named)24 b(after)h(its)g(ma)r
+(jor)e(standards)j(TCP)f(\(T)m(ransmission)e(Con)o(trol)h(Proto)q(col\))h
+(and)g(IP)g(\(In)o(ternet)149 2634 y(Proto)q(col\))p eop
+%%Page: 7 16
+15 bop 1925 -100 a Fo(7)149 75 y(end)17 b(user.)23 b(These)17
+b(t)o(w)o(o)f(services)g(are)h(based)g(on)g(the)g(transmission)f(of)h(data)h
+(pac)o(k)o(ets,)d(units)i(of)149 165 y(data)i(sen)o(t)e(across)i(a)f(pac)o(k)
+o(et)e(switc)o(hing)h(net)o(w)o(ork.)25 b(The)18 b(collection)e(of)i(pac)o(k)
+o(ets)f(that)h(b)q(elongs)149 255 y(to)f(one)f(connection)g(comp)q(oses)g
+(the)g(data)h(comm)o(unication.)149 415 y(2.1.3)49 b(P)o(ac)o(k)o(et)15
+b(Routing)223 538 y(P)o(ac)o(k)o(ets)e(that)h(are)g(sen)o(t)g(from)f(one)h
+(host)h(to)g(another)f(usually)g(ha)o(v)o(e)g(to)g(tra)o(v)o(erse)f(more)g
+(than)149 628 y(one)i(ph)o(ysical)e(link)h(b)q(et)o(w)o(een)f(these)h(hosts.)
+22 b(In)14 b(a)h(complex)d(net)o(w)o(ork)i(with)g(man)o(y)f(thousands)j(of)
+149 718 y(mac)o(hines)f(it)g(is)i(not)f(a)h(trivial)e(task)h(to)h(direct)e(a)
+i(pac)o(k)o(et)e(from)g(its)h(source)g(to)h(its)f(destination.)223
+809 y(In)k(an)g(in)o(ternet)527 791 y Fm(3)566 809 y Fo(there)g(are)g(sp)q
+(ecially)f(dedicated)h(mac)o(hines)e(that)j(attac)o(h)f(t)o(w)o(o)g(or)h
+(more)149 899 y(net)o(w)o(orks)h(and)h(transmit)e(pac)o(k)o(ets)g(from)g(one)
+h(to)g(the)g(other.)38 b(These)22 b(mac)o(hines)e(are)j(called)149
+989 y(\\gatew)o(a)o(ys.")f(While)13 b(tra)o(v)o(ersing)h(the)f(net)o(w)o(ork)
+h(from)f(source)h(to)h(destination)f(host,)h(a)f(message)149
+1079 y(is)i(lik)o(ely)c(to)k(pass)g(through)h(one)e(or)h(more)e(gatew)o(a)o
+(ys.)21 b(If)15 b(the)g(top)q(ology)i(of)f(the)f(net)o(w)o(ork)f(allo)o(ws)
+149 1170 y(sev)o(eral)j(paths)i(for)f(the)g(message)f(to)i(reac)o(h)e(its)h
+(destination,)g(these)g(gatew)o(a)o(ys)g(ha)o(v)o(e)f(to)h(mak)o(e)149
+1260 y(decisions)e(ab)q(out)i(whic)o(h)d(route)i(to)f(c)o(ho)q(ose)h(for)g
+(the)f(pac)o(k)o(et.)223 1350 y(In)d(a)h(TCP/IP)h(in)o(ternet)d(the)i(basic)f
+(unit)h(of)g(data)g(transmission)f(is)h(the)f(IP)h(datagram.)20
+b(The)149 1441 y(pro)q(cess)c(of)g(c)o(ho)q(osing)g(a)g(path)g(o)o(v)o(er)e
+(whic)o(h)h(to)g(send)h(a)g(datagram)f(from)f(source)i(to)f(destination)149
+1531 y(is)h(referred)g(to)g(as)h(routing;)f(an)o(y)h(computer)d(making)h(suc)
+o(h)h(a)h(decision)f(is)g(called)f(a)h(router.)223 1621 y(Gatew)o(a)o(ys)f
+(in)g(the)h(function)f(of)h(routers)g(comp)q(ose)f(a)g(co)q(op)q(erativ)o(e,)
+g(in)o(terconnected)f(struc-)149 1711 y(ture.)21 b(Datagrams)c(originated)e
+(at)h(the)g(source)g(are)f(passed)i(from)e(router)g(to)i(router)e(un)o(til)g
+(they)149 1802 y(reac)o(h)h(a)h(gatew)o(a)o(y)f(that)h(can)f(deliv)o(er)e
+(the)i(datagram)h(directly)d(to)j(its)f(destination.)149 1962
+y(2.1.4)49 b(Name)15 b(Resolution)223 2084 y(Early)e(systems)f(supp)q(orted)i
+(p)q(oin)o(t{to{p)q(oin)o(t)h(connections)e(b)q(et)o(w)o(een)f(computers)g
+(and)i(used)149 2174 y(lo)o(w)g(lev)o(el)d(hardw)o(are)j(addresses)g(to)g(sp)
+q(ecify)e(mac)o(hines.)19 b(In)o(ternet)o(w)o(orking)11 b(in)o(tro)q(duced)i
+(univ)o(er-)149 2265 y(sal)18 b(addressing)g(as)h(w)o(ell)d(as)i(proto)q(col)
+g(soft)o(w)o(are)g(to)g(map)f(univ)o(ersal)f(addresses)i(in)o(to)g(lo)o
+(w-lev)o(el)149 2355 y(hardw)o(are)g(addresses.)24 b(There)17
+b(is)g(also)h(the)f(notion)g(of)h(a)f(host)h(name)e(|)h(a)h(high)f(lev)o(el)e
+(address)p 149 2399 720 2 v 206 2429 a Fl(3)224 2444 y Fk(\\Ph)o(ysically)m
+(,)h(a)i(collection)f(of)f(pac)o(k)o(et)i(switc)o(hing)f(net)o(w)o(orks)h(in)
+o(terconnected)i(b)o(y)d(gatew)o(a)o(ys)g(along)g(with)149
+2494 y(proto)q(cols)h(that)f(allo)o(w)f(them)g(to)h(function)g(logically)e
+(as)i(a)g(single,)g(large,)g(virtual)f(net)o(w)o(ork.)29 b(When)17
+b(written)149 2544 y(in)g(upp)q(er)i(case,)g(In)o(ternet)g(refers)g(sp)q
+(eci\014cally)e(to)h(the)g(connected)h(In)o(ternet)g(and)e(the)h(TCP/IP)g
+(proto)q(cols)g(it)149 2594 y(uses."[Com91)n(])p eop
+%%Page: 8 17
+16 bop 1925 -100 a Fo(8)149 75 y(|)17 b(a)g(pronounceable)f(iden)o(ti\014er)f
+(for)i(hosts.)23 b(The)16 b(univ)o(ersal)g(addresses)h(can)f(b)q(e)h(mapp)q
+(ed)f(in)o(to)149 165 y(host)h(names.)223 255 y(Mapping)e(pro)q(cesses)g(can)
+h(also)f(b)q(e)g(called)f(\\name)g(binding")i(or)f(\\name)f(resolution.")21
+b(This)149 346 y(thesis)16 b(is)f(based)h(on)h(the)e(name)f(resolution)i(pro)
+q(cess)g(b)q(et)o(w)o(een)f(high)h(lev)o(el)d(addresses,)j(the)g(host)149
+436 y(names,)f(and)i(univ)o(ersally)e(assigned)i(lo)o(w)o(er)e(lev)o(el)f(IP)
+i(addresses.)223 526 y(Name)c(resolution)j(is)f(a)h(general)f(concept.)20
+b(The)15 b(curren)o(t)e(proto)q(col)j(in)e(the)g(TCP/IP)h(proto-)149
+616 y(col)h(suite)g(dealing)g(with)h(this)f(concept)g(and)h(solving)f(the)g
+(problems)f(that)i(arise)f(from)g(it)g(is)g(the)149 707 y(Domain)g(Name)f
+(System.)149 872 y(2.2)50 b(Historical)15 b(Dev)o(elopmen)o(t)223
+1012 y(Around)21 b(1970,)j(the)e(ARP)l(ANET)e(and)i(the)g(TYMNET)f(w)o(ere)f
+(in)o(tro)q(duced.)37 b(They)21 b(w)o(ere)149 1102 y(the)h(\014rst)g
+(large{scale,)g(general{purp)q(ose)h(data)f(net)o(w)o(orks)g(that)g
+(connected)f(geographically)149 1192 y(distributed)16 b(computer)f(systems.)
+223 1283 y(As)e(the)h(comm)o(unit)o(y)c(con)o(tained)k(only)g(a)g(few)g(h)o
+(undred)g(hosts,)h(name)e(resolution)h(w)o(as)g(man-)149 1373
+y(aged)g(using)g(a)g(single)f(text)f(\014le:)20 b(HOSTS.TXT.)12
+b(This)h(\014le)g(con)o(tained)g(name{to{address)h(map-)149
+1463 y(ping)e(for)g(ev)o(ery)e(connected)h(host.)21 b(The)11
+b(administration,)g(main)o(tenance,)f(and)j(distribution)e(w)o(as)149
+1553 y(done)17 b(b)o(y)f(the)g(SRI)499 1535 y Fm(4)518 1553
+y Fo({)h(NIC)649 1535 y Fm(5)668 1553 y Fo(.)223 1644 y(Whenev)o(er)12
+b(some)i(application)g(had)g(to)h(resolv)o(e)e(a)i(host)f(name)f(and)i(get)g
+(the)e(corresp)q(onding)149 1734 y(IP)j(address,)h(or)g(vice)e(v)o(ersa,)g
+(the)h(resolv)o(er)f(function)h(called)f(simply)f(lo)q(ok)o(ed)j(up)f(the)g
+(name)f(\(or)149 1824 y(IP)d(address\))h(in)f(a)g(lo)q(cal)g(cop)o(y)g(of)g
+(the)g(master)f(HOSTS.TXT)h(\014le)f(and)i(returned)f(the)f(asso)q(ciated)149
+1915 y(v)m(alue.)223 2005 y(The)i(enormous)f(gro)o(wth)i(rate)e(of)i(the)e
+(In)o(ternet)g(w)o(as)h(b)o(y)g(no)g(means)f(predictable.)19
+b(Therefore)149 2095 y(it)d(to)q(ok)h(sev)o(eral)e(y)o(ears)h(un)o(til)g
+(serious)g(problems)f(b)q(ecame)g(apparen)o(t:)222 2227 y Fj(\017)24
+b Fo(System)13 b(administrators)h(used)g(to)h(e{mail)e(c)o(hanges)h(to)h(the)
+f(NIC)g(and)h(p)q(erio)q(dically)e(con-)271 2317 y(tact)h(the)f(SRI-NIC)f(to)
+i(obtain)g(the)f(latest)g(cop)o(y)g(of)g(HOSTS.TXT.)g(Net)o(w)o(ork)f
+(tra\016c)h(and)271 2407 y(pro)q(cessor)18 b(load)e(b)q(ecame)f(unacceptably)
+h(high)g(for)h(the)f(NIC.)p 149 2451 720 2 v 206 2482 a Fl(4)224
+2497 y Fk(Stanford)e(Researc)o(h)h(Institute)g(in)e(Menlo)h(P)o(ark,)f
+(California)206 2532 y Fl(5)224 2547 y Fk(Net)o(w)o(ork)h(Information)e(Cen)o
+(ter)p eop
+%%Page: 9 18
+17 bop 1925 -100 a Fo(9)222 75 y Fj(\017)24 b Fo(Names)15 b(assigned)i(to)g
+(hosts)g(ha)o(v)o(e)e(to)i(b)q(e)f(unique.)k(As)c(the)g(NIC)g(had)h(no)f
+(authorit)o(y)g(o)o(v)o(er)271 165 y(host)h(name)e(assignmen)o(ts,)g(name)g
+(collisions)h(b)q(ecame)f(a)h(problem.)222 297 y Fj(\017)24
+b Fo(With)19 b(the)g(gro)o(wth)h(of)f(the)g(In)o(ternet)f(and)i(the)e
+(irregularit)o(y)g(of)h(database)i(up)q(dates)f(the)271 387
+y(consistency)c(of)h(the)f(name)f(space)h(w)o(as)h(no)f(longer)h(guaran)o
+(teed.)149 519 y(All)e(of)i(these)f(problems)f(arose)i(b)q(ecause)f(the)g
+(original)g(approac)o(h)h(scaled)f(p)q(o)q(orly)l(.)223 609
+y(In)22 b(1984)h(the)f(net)o(w)o(ork)g(comm)o(unit)n(y)d(switc)o(hed)j(to)g
+(the)g(Domain)g(Name)e(System.)38 b(P)o(aul)149 699 y(Mo)q(c)o(k)m(ap)q
+(etris)22 b(w)o(as)g(resp)q(onsible)g(for)f(the)h(design)f(of)h(the)g(arc)o
+(hitecture)e(of)h(the)h(new)f(system.)149 790 y(The)14 b(original)f(RF)o(Cs)
+541 772 y Fm(6)573 790 y Fo(describing)g(the)g(Domain)f(Name)g(System)f(are)j
+([Mo)q(c83a])f(and)h([Mo)q(c83b].)149 880 y(They)j(ha)o(v)o(e)f(b)q(een)g
+(obsolete)h(since)f(the)g(release)g(of)h(the)f(curren)o(t)g(sp)q
+(eci\014cations)h([Mo)q(c87a)q(])f(and)149 970 y([Mo)q(c87b)q(])g(in)g(No)o
+(v)o(em)o(b)q(er)d(1987)18 b(\([LR93])e(and)h([BG92]\).)149
+1136 y(2.3)50 b(Design)16 b(Goals)223 1275 y(The)k(e\013ort)h(of)f(designing)
+h(the)f(Domain)f(Name)g(System)g(w)o(as)i(directed)e(to)o(w)o(ards)i(sev)o
+(eral)149 1366 y(goals,)e(whic)o(h)e(had)i(the)e(main)g(in\015uence)f(on)j
+(determining)c(the)j(curren)o(t)f(structure.)25 b(The)18 b(aim)149
+1456 y(w)o(as)f(to)g(create)e(a)i(system)e(with)h(the)g(follo)o(wing)g(ob)s
+(jectiv)o(es)e(in)i(mind:)222 1588 y Fj(\017)24 b Fo(Data)18
+b(Consistency)222 1719 y Fj(\017)24 b Fo(E\016ciency)222 1851
+y Fj(\017)g Fo(Distributed)16 b(Character)222 1983 y Fj(\017)24
+b Fo(Generalit)o(y)222 2115 y Fj(\017)g Fo(Indep)q(endence)149
+2247 y(P)l(.)12 b(Mo)q(c)o(k)m(ap)q(etris)g(states)h(in)e([Mo)q(c87a)q(])h
+(the)g(design)g(ob)s(jectiv)o(es)e(that)j(led)e(to)h(the)g(curren)o(t)f
+(system:)p 149 2293 720 2 v 206 2324 a Fl(6)224 2339 y Fk(RF)o(Cs)j(are)g(a)g
+(series)h(of)e(tec)o(hnical)h(rep)q(orts)i(called)d(Requests)i(for)f(Commen)o
+(ts)p eop
+%%Page: 10 19
+18 bop 1901 -100 a Fo(10)149 75 y(2.3.1)49 b(Data)18 b(Consistency)223
+197 y(The)g(primary)f(goal)i(w)o(as)f(to)h(pro)o(vide)e(a)i(consisten)o(t)f
+(name)f(space)h(to)h(b)q(e)g(used)f(to)h(refer)e(to)149 287
+y(resources.)j(In)12 b(particular,)g(the)f(name)g(space)h(should)g(not)g(dep)
+q(end)g(on)g(an)o(y)g(net)o(w)o(ork)f(iden)o(ti\014ers,)149
+378 y(and)17 b(therefore)f(b)q(e)g(totally)g(indep)q(enden)o(t)f(of)i
+(routing)g(information)e(or)i(net)o(w)o(ork)e(top)q(ology)l(.)149
+538 y(2.3.2)49 b(E\016ciency)223 660 y(The)15 b(gro)o(wth)g(of)g(the)g(In)o
+(ternet)f(in)g(n)o(um)o(b)q(er)f(of)i(mac)o(hines)e(and)j(subnet)o(w)o(orks)f
+(called)f(for)h(the)149 750 y(in)o(tro)q(duction)i(of)h(a)f(naming)f
+(resolution)h(system)f(that)h(could)g(handle)g(not)g(only)g(the)g(imme)o(nse)
+149 841 y(v)o(olume)h(of)j(mac)o(hines)d(and)j(resolution)f(requests,)h(but)f
+(could)g(also)h(resp)q(ond)g(e\016cien)o(tly)l(.)31 b(T)l(o)149
+931 y(obtain)14 b(these)e(desired)g(e\013ects,)g(the)h(system)e(w)o(as)i
+(built)f(in)g(a)h(hierarc)o(hical,)f(distributed)g(manner)149
+1021 y(using)17 b(the)f(tec)o(hnology)g(of)g(cac)o(hing.)223
+1112 y(In)j(an)i(in)o(ternet,)e(access)h(to)h(mac)o(hines)d(in)i(lo)q(cal)g
+(net)o(w)o(orks)f(is)h(more)f(lik)o(ely)e(than)k(remote)149
+1202 y(access)14 b(via)g(man)o(y)f(links.)19 b(Therefore,)14
+b(far)g(more)f(name)f(resolution)i(requests)g(are)g(made)f(lo)q(cally)l(.)149
+1292 y(The)18 b(kno)o(wledge)e(ab)q(out)i(the)f(requested)g(bindings)g(in)f
+(the)h(lo)q(cal)g(net)o(w)o(ork)g(is)g(a)o(v)m(ailable)f(in)h(the)149
+1382 y(form)h(of)i(the)f(lo)q(cal)g(database.)30 b(These)19
+b(facts)h(suggests)g(the)f(use)g(of)g(the)g(hierarc)o(hical)e(organi-)149
+1473 y(zational)j(format)e(in)h(whic)o(h)g(lo)q(cal)g(resolution)g(requests)g
+(are)g(resolv)o(ed)g(e\016cien)o(tly)d(b)o(y)j(a)h(lo)q(cal)149
+1563 y(en)o(tit)o(y)l(,)d(and)i(infrequen)o(t)e(resolution)h(requests)g(ab)q
+(out)h(remote)e(mappings)h(are)g(dealt)g(with)g(b)o(y)149 1653
+y(an)e(in)o(teraction)d(of)i(lo)q(cal)g(and)g(remote)e(en)o(tities.)19
+b(The)c(clear)f(and)h(clean)f(structure)h(that)g(results)149
+1744 y(in)h(seeing)g(the)g(name)f(space)i(as)g(a)f(tree)g(also)h(fa)o(v)o
+(ors)f(this)g(approac)o(h.)223 1834 y(The)c(creation)g(of)h(host)g(names)f(b)
+o(y)f(app)q(ending)j(no)q(de)f(lab)q(els)f(from)f(the)i(lea)o(v)o(es)e(to)h
+(the)h(ro)q(ot)g(of)149 1924 y(this)h(tree)e(serv)o(ed)h(the)g(need)g(for)h
+(pronounceable,)g(easily)e(remem)n(b)q(erable)f(names)h(for)i(mac)o(hines.)
+149 2014 y(The)23 b(distributed)f(arrangemen)o(t)g(of)h(the)f(system)g(con)o
+(tributes)g(to)h(cutting)f(the)h(h)o(uge)g(name)149 2105 y(space)c(in)o(to)g
+(pieces)e(that)i(can)g(b)q(e)g(managed)f(e\016cien)o(tly)l(.)26
+b(Cac)o(hing)19 b(information)e(lo)q(cally)h(that)149 2195
+y(w)o(as)e(receiv)o(ed)e(from)g(remote)g(sites)h(is)g(another)i(mec)o(hanism)
+12 b(to)k(obtain)g(e\016ciency)l(.)i(Because)d(of)149 2285
+y(the)20 b(dynamics)e(of)i(the)f(system,)f(the)i(cac)o(hed)e(information)h
+(is)g(quali\014ed)g(with)g(an)h(additional)149 2376 y(time)15
+b(to)h(liv)o(e)f(\(TTL\))i(parameter)e(to)h(ensure)g(the)g(goal)h(of)g(data)g
+(consistency)l(.)p eop
+%%Page: 11 20
+19 bop 1901 -100 a Fo(11)149 75 y(2.3.3)49 b(Distributed)16
+b(Character)223 197 y(The)f(c)o(hoice)e(of)j(implem)o(en)n(ting)c(this)j
+(large)g(scale)g(clien)o(t{serv)o(er)d(paradigm)j(in)f(a)i(geograph-)149
+287 y(ically)f(distributed)h(set)g(of)h(mac)o(hines)d(w)o(as)j(supp)q(orted)h
+(b)o(y)e(the)g(need)g(for)g(increased)g(reliabilit)o(y)149
+378 y(through)f(the)f(existence)e(of)i(redundan)o(t)g(data)h(bases)f(in)g
+(secondary)g(name)f(serv)o(ers.)19 b(In)14 b(the)f(case)149
+468 y(of)20 b(an)o(y)f(kind)g(of)h(failure)e(in)h(one)h(of)f(the)h(name)e
+(serv)o(ers)g(for)i(a)g(zone,)f(the)g(redundan)o(t)h(bac)o(kup)149
+558 y(serv)o(ers)c(will)f(still)g(b)q(e)i(able)f(to)g(pro)o(vide)g(the)g
+(mapping)g(service.)k(Therefore)15 b(the)i(o)q(ccurrence)e(of)149
+649 y(a)i(failure)e(at)i(a)g(single)e(site)h(cannot)h(lead)f(to)h(the)f
+(denial)f(of)i(the)f(resolution)g(service.)223 739 y(Lo)q(cal)e(authorities)g
+(could)g(administer)e(their)h(o)o(wn)h(domains)g(and)g(zones,)g(k)o(eeping)f
+(the)h(data)149 829 y(base)j(consisten)o(t,)e(pro)o(viding)g(autonomous)h
+(con)o(trol)g(of)g(name)e(assignmen)o(t,)h(and)h(taking)g(a)o(w)o(a)o(y)149
+919 y(the)11 b(load)g(from)f(cen)o(tral)g(authorities.)20 b(Authorit)o(y)9
+b(passes)j(do)o(wn)g(the)e(edges)h(of)h(the)e(tree,)h(whereas)149
+1010 y(information)19 b(\015o)o(ws)i(across)g(the)e(hierarc)o(hies)g(from)g
+(one)h(host)h(to)f(another.)33 b(The)20 b(conceptual)149 1100
+y(arrangemen)o(t)f(of)h(domain)f(name)g(serv)o(ers)g(in)h(a)g(tree)f(resem)o
+(bling)e(the)j(name)f(structure)g(is)h(in)149 1190 y(fact)d(a)f(more)f
+(realistic)g(arrangemen)o(t,)g(namely)f(a)j(shallo)o(w)f(tree.)149
+1350 y(2.3.4)49 b(Generalit)o(y)223 1473 y(Pragmatic)15 b(reasons)i(called)e
+(for)i(generalit)o(y)l(.)i(Impleme)o(n)o(tation)13 b(costs)k(and)g(the)f
+(amoun)o(t)f(of)149 1563 y(administrativ)o(e)9 b(e\013ort)i(in)g(supp)q
+(orting)h(the)f(system)f(dictated)g(a)i(general)f(usefulness.)19
+b(Therefore)149 1653 y(the)j(system)e(do)q(es)i(not)g(con)o(tain)g(an)o(y)f
+(unnecessary)h(restrictions)f(regarding)h(its)g(purp)q(ose)g(or)149
+1744 y(applications.)30 b(This)19 b(goal)g(can)h(b)q(e)f(reform)o(ulated)e
+(as)i(the)g(desire)f(to)h(allo)o(w)g(augmen)o(tation)f(of)149
+1834 y(the)e(data)i(basis)e(b)o(y)g(new)g(data)h(structures.)149
+1994 y(2.3.5)49 b(Indep)q(endence)223 2116 y(The)16 b(system)g(w)o(as)h
+(designed)g(to)g(b)q(e)g(indep)q(enden)o(t)f(of)h(underlying)f(hardw)o(are,)h
+(b)q(e)g(it)g(of)g(the)149 2207 y(lo)q(cal)24 b(mac)o(hine)d(or)j(the)f(net)o
+(w)o(ork)g(in)o(terface.)42 b(F)l(urthermore,)23 b(the)g(transactions)h
+(should)g(b)q(e)149 2297 y(indep)q(enden)o(t)17 b(of)g(the)g(comm)o(uni)o
+(cation)d(system)i(that)h(carries)g(them.)k(Therefore,)c(all)f(p)q(ossible)
+149 2387 y(kinds)23 b(of)f(pac)o(k)o(et)g(switc)o(hing)g(are)g(suitable,)h
+(suc)o(h)f(as)i(store{and{forw)o(ard)g(switc)o(hing)e(using)149
+2478 y(datagrams,)17 b(virtual)e(circuits,)g(or)h(p)q(ossibly)h(h)o(ybrid)e
+(approac)o(hes.)p eop
+%%Page: 12 21
+20 bop 1901 -100 a Fo(12)149 75 y(2.4)50 b(DNS)16 b(En)o(tities)223
+214 y(The)11 b(Domain)h(Name)e(System)g(consists)i(of)g(sev)o(eral)f(en)o
+(tities:)17 b(resolv)o(ers,)12 b(name)e(serv)o(ers,)i(and)149
+305 y(resource)i(records)g(\(RR\).)g(W)l(e)g(\014rst)g(describ)q(e)g(the)f
+(domain)h(name)f(space)h(and)h(resource)e(records)149 395 y(that)k(are)e
+(sections)h(in)f(DNS)h(messages.)21 b(They)15 b(serv)o(e)g(for)h(the)f(exc)o
+(hange)g(of)h(data)h(b)q(et)o(w)o(een)e(the)149 485 y(in)o(teracting)k(name)g
+(serv)o(ers)g(and)i(resolv)o(ers.)32 b(W)l(e)19 b(then)h(describ)q(e)f(purp)q
+(oses)j(and)e(features)g(of)149 575 y(name)c(serv)o(ers)f(and)i(resolv)o
+(ers.)149 735 y(2.4.1)49 b(Domain)16 b(Name)f(Space)223 858
+y(The)d(Domain)f(Name)g(Space)h(is)f(the)h(sp)q(eci\014cation)g(of)h(a)f
+(tree{structured)g(name)f(space.)19 b(The)149 948 y(ro)q(ot)i(of)f(the)f
+(tree)f(is)i(the)f(ro)q(ot)h(domain)f(follo)o(w)o(ed)f(b)o(y)h(its)g(c)o
+(hildren,)f(the)h(top{lev)o(el)f(domains,)149 1039 y(whic)o(h)i(can)h(con)o
+(tain)g(sev)o(eral)e(lev)o(els)g(of)i(sub)q(domains.)35 b(Figure)20
+b(2.1)h(sho)o(ws)g(the)g(structure)f(of)149 1129 y(suc)o(h)d(a)g(tree.)k
+(Host)c(names)e(consist)i(of)g(a)f(concatenation)h(of)g(the)f(lab)q(els)h(of)
+g(eac)o(h)f(no)q(de)h(on)g(the)149 1219 y(path)f(from)d(the)i(leaf)f(that)h
+(represen)o(ts)f(the)h(actual)f(host)i(up)f(to)g(the)f(ro)q(ot.)22
+b(Adjacen)o(t)14 b(lab)q(els)g(are)149 1309 y(separated)i(b)o(y)e(a)i(dot.)21
+b(Domains)15 b(are)g(simply)e(subtrees)i(of)g(the)g(Domain)f(Name)f(Space.)21
+b(In)15 b(our)149 1400 y(example)f(\\purdue.edu")j(is)f(a)h(domain)e(name.)
+524 2188 y @beginspecial 0 @llx 0 @lly 239 @urx 134 @ury 2390
+@rwi @setspecial
+%%BeginDocument: pictures/dom_purd.ps
+/$F2psDict 200 dict def 
+$F2psDict begin
+$F2psDict /mtrx matrix put
+/l {lineto} bind def
+/m {moveto} bind def
+/s {stroke} bind def
+/n {newpath} bind def
+/gs {gsave} bind def
+/gr {grestore} bind def
+/clp {closepath} bind def
+/graycol {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
+4 -2 roll mul setrgbcolor} bind def
+/col-1 {} def
+/col0 {0 0 0 setrgbcolor} bind def
+/col1 {0 0 1 setrgbcolor} bind def
+/col2 {0 1 0 setrgbcolor} bind def
+/col3 {0 1 1 setrgbcolor} bind def
+/col4 {1 0 0 setrgbcolor} bind def
+/col5 {1 0 1 setrgbcolor} bind def
+/col6 {1 1 0 setrgbcolor} bind def
+/col7 {1 1 1 setrgbcolor} bind def
+ /DrawEllipse {
+	/endangle exch def
+	/startangle exch def
+	/yrad exch def
+	/xrad exch def
+	/y exch def
+	/x exch def
+	/savematrix mtrx currentmatrix def
+	x y translate xrad yrad scale 0 0 1 startangle endangle arc
+	savematrix setmatrix
+	} def
+
+	end
+/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
+/$F2psEnd {$F2psEnteredState restore end} def
+
+$F2psBegin
+0 setlinecap 0 setlinejoin
+-4.0 139.0 translate 0.900 -0.900 scale
+0.500 setlinewidth
+n 74 114 70 40 0 360 DrawEllipse gs 0.95 setgray fill gr
+gs col-1 s gr
+n 189 14 m 189 44 l gs col-1 s gr
+n 189 14 m 269 44 l gs col-1 s gr
+n 189 14 m 109 44 l gs col-1 s gr
+n 109 59 m 79 84 l gs col-1 s gr
+n 79 99 m 109 124 l gs col-1 s gr
+n 79 99 m 69 124 l gs col-1 s gr
+n 79 99 m 29 124 l gs col-1 s gr
+/Times-Bold findfont 12.00 scalefont setfont
+99 54 m 
+gs 1 -1 scale (edu) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+179 54 m 
+gs 1 -1 scale (com) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+259 54 m 
+gs 1 -1 scale (org) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+184 14 m 
+gs 1 -1 scale (" ") col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+59 94 m 
+gs 1 -1 scale (purdue) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+19 134 m 
+gs 1 -1 scale (cs) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+59 134 m 
+gs 1 -1 scale (cc) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+99 134 m 
+gs 1 -1 scale (ecn) col-1 show gr
+$F2psEnd
+%%EndDocument
+ @endspecial 714 2433 a(Figure)h(2.1)33 b(Domain)15 b(purdue.edu)p
+eop
+%%Page: 13 22
+21 bop 1901 -100 a Fo(13)223 75 y(A)14 b(part)h(of)g(the)f(Domain)g(Name)f
+(Space)i(that)g(is)f(con)o(trolled)g(completely)e(b)o(y)i(a)h(name)f(serv)o
+(er)149 165 y(is)23 b(called)f(a)i(zone.)42 b(The)23 b(delicate)e
+(di\013erence)h(b)q(et)o(w)o(een)h(a)g(domain)f(and)i(a)g(zone)f(is)g(that)g
+(a)149 255 y(zone)16 b(con)o(tains)g(all)g(the)g(domain)f(names)g(and)i(data)
+g(that)f(a)h(domain)e(con)o(tains,)g(except)g(for)i(the)149
+346 y(domain)h(names)f(and)i(data)g(that)f(are)g(delegated)g(elsewhere)f
+(\(see)h(Figure)f(2.2\).)28 b(Viewing)17 b(the)149 436 y(domains)f(\(no)q
+(des\))g(and)g(hosts)h(\(lea)o(v)o(es\))d(as)j(the)e(conceptual)g(arrangemen)
+o(t)g(yields)f(a)j(tree)e(with)149 526 y(greater)i(heigh)o(t)f(than)i
+(viewing)e(the)g(zones)h(as)g(no)q(des.)24 b(The)16 b(latter)h(is)f(a)h(more)
+f(realistic)f(la)o(y)o(out)149 616 y(of)i(the)f(tree)g(in)f(terms)g(of)i
+(e\016ciency)l(.)223 707 y(An)e(example)e(for)i(the)g(di\013erence)f(b)q(et)o
+(w)o(een)h(domain)f(and)i(zone)f(is)g(the)g(follo)o(wing)g(scenario.)149
+797 y(A)i(lo)q(cal)h(authorit)o(y)f(manages)h(the)f(domain)f(\\alpha.dom".)25
+b(\\alpha.dom")18 b(has)g(three)f(sub)q(do-)149 887 y(mains)e(\\phi,")g(\\c)o
+(hi,")g(and)h(\\psi")h(that)e(con)o(tain)h(sev)o(eral)e(hosts,)i(but)g(no)g
+(further)f(sub)q(domains.)149 978 y(If)g(the)g(authorit)o(y)g(for)g(sub)q
+(domain)g(\\psi")h(is)f(transferred)g(to)h(\\psi.alpha.dom,")e(t)o(w)o(o)h
+(zones)g(are)149 1068 y(the)j(result.)27 b(The)18 b(authorit)o(y)g(for)h
+(\\alpha.dom")f(could)g(additionally)f(transfer)i(the)f(authorit)o(y)149
+1158 y(for)k(\\c)o(hi")g(to)g(the)g(same)e(authorit)o(y)i(that)g(administers)
+e(\\psi".)39 b(This)22 b(example)d(sho)o(ws)k(that)149 1248
+y(zones)17 b(do)g(not)f(ha)o(v)o(e)g(to)g(b)q(e)h(connected)e(b)o(y)h(edges)g
+(in)g(the)g(tree)g(structured)g(domain)f(tree.)524 2037 y @beginspecial
+0 @llx 0 @lly 248 @urx 126 @ury 2480 @rwi @setspecial
+%%BeginDocument: pictures/dom_zone.ps
+/$F2psDict 200 dict def 
+$F2psDict begin
+$F2psDict /mtrx matrix put
+/l {lineto} bind def
+/m {moveto} bind def
+/s {stroke} bind def
+/n {newpath} bind def
+/gs {gsave} bind def
+/gr {grestore} bind def
+/clp {closepath} bind def
+/graycol {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
+4 -2 roll mul setrgbcolor} bind def
+/col-1 {} def
+/col0 {0 0 0 setrgbcolor} bind def
+/col1 {0 0 1 setrgbcolor} bind def
+/col2 {0 1 0 setrgbcolor} bind def
+/col3 {0 1 1 setrgbcolor} bind def
+/col4 {1 0 0 setrgbcolor} bind def
+/col5 {1 0 1 setrgbcolor} bind def
+/col6 {1 1 0 setrgbcolor} bind def
+/col7 {1 1 1 setrgbcolor} bind def
+ /DrawEllipse {
+	/endangle exch def
+	/startangle exch def
+	/yrad exch def
+	/xrad exch def
+	/y exch def
+	/x exch def
+	/savematrix mtrx currentmatrix def
+	x y translate xrad yrad scale 0 0 1 startangle endangle arc
+	savematrix setmatrix
+	} def
+
+ /DrawSplineSection {
+	/y3 exch def
+	/x3 exch def
+	/y2 exch def
+	/x2 exch def
+	/y1 exch def
+	/x1 exch def
+	/xa x1 x2 x1 sub 0.666667 mul add def
+	/ya y1 y2 y1 sub 0.666667 mul add def
+	/xb x3 x2 x3 sub 0.666667 mul add def
+	/yb y3 y2 y3 sub 0.666667 mul add def
+	x1 y1 lineto
+	xa ya xb yb x3 y3 curveto
+	} def
+
+	end
+/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
+/$F2psEnd {$F2psEnteredState restore end} def
+
+$F2psBegin
+0 setlinecap 0 setlinejoin
+-4.0 139.0 translate 0.900 -0.900 scale
+0.500 setlinewidth
+n 139 94 135 60 0 360 DrawEllipse gs col-1 s gr
+n 219 14 m 219 34 l gs col-1 s gr
+n 219 14 m 259 34 l gs col-1 s gr
+	1 setlinecap [1 3.000000] 3.000000 setdash
+n 259 34 m 279 44 l gs col-1 s gr
+	[] 0 setdash 0 setlinecap
+	1 setlinecap [1 3.000000] 3.000000 setdash
+n 219 34 m 219 44 l gs col-1 s gr
+	[] 0 setdash 0 setlinecap
+n 219 14 m 139 54 l gs col-1 s gr
+n 139 54 m 79 94 l gs col-1 s gr
+n 139 54 m 139 94 l gs col-1 s gr
+n 139 54 m 199 94 l gs col-1 s gr
+n 199 94 m 179 134 l gs col-1 s gr
+n 199 94 m 199 134 l gs col-1 s gr
+n 199 94 m 219 134 l gs col-1 s gr
+n 139 94 m 119 134 l gs col-1 s gr
+n 139 94 m 139 134 l gs col-1 s gr
+n 139 94 m 159 134 l gs col-1 s gr
+n 79 94 m 59 134 l gs col-1 s gr
+n 79 94 m 79 134 l gs col-1 s gr
+n 79 94 m 99 134 l gs col-1 s gr
+	[4.000000] 0 setdash
+n 49.000 104.000 m 49.000 89.000 l
+	49.000 89.000 49.000 74.000 84.000 62.500 DrawSplineSection
+	84.000 62.500 119.000 51.000 139.000 51.000 DrawSplineSection
+	139.000 51.000 159.000 51.000 194.000 62.500 DrawSplineSection
+	194.000 62.500 229.000 74.000 229.000 89.000 DrawSplineSection
+	229.000 89.000 229.000 104.000 226.500 119.000 DrawSplineSection
+	226.500 119.000 224.000 134.000 211.500 139.000 DrawSplineSection
+	211.500 139.000 199.000 144.000 186.500 139.000 DrawSplineSection
+	186.500 139.000 174.000 134.000 161.500 109.000 DrawSplineSection
+	161.500 109.000 149.000 84.000 139.000 84.000 DrawSplineSection
+	139.000 84.000 129.000 84.000 116.500 109.000 DrawSplineSection
+	116.500 109.000 104.000 134.000 91.500 139.000 DrawSplineSection
+	91.500 139.000 79.000 144.000 66.500 139.000 DrawSplineSection
+	66.500 139.000 54.000 134.000 51.500 119.000 DrawSplineSection
+	49.000 104.000 l gs col-1 s gr
+	[] 0 setdash
+/Times-Bold findfont 12.00 scalefont setfont
+219 69 m 
+gs 1 -1 scale (domain) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+59 89 m 
+gs 1 -1 scale (zone) col-1 show gr
+$F2psEnd
+%%EndDocument
+ @endspecial 746 2281 a(Figure)h(2.2)32 b(Domain)16 b(vs.)21
+b(zone)p eop
+%%Page: 14 23
+22 bop 1901 -100 a Fo(14)149 75 y(2.4.2)49 b(DNS)17 b(Messages)223
+197 y(DNS)e(messages)h(are)f(the)h(data)g(units)g(that)g(are)g(transmitted)f
+(b)q(et)o(w)o(een)f(name)h(serv)o(ers)g(and)149 287 y(resolv)o(ers.)22
+b(A)16 b(DNS)g(message)g(consists)h(of)g(the)f(header)h(and)g(up)g(to)f(four)
+h(sections)g(\(see)f(Figure)149 378 y(2.3\).)22 b(The)16 b(header)g(con)o
+(tains)h(the)f(follo)o(wing)g(\014elds:)337 2219 y @beginspecial
+0 @llx 0 @lly 333 @urx 387 @ury 3330 @rwi @setspecial
+%%BeginDocument: pictures/dns_mesg.ps
+/$F2psDict 200 dict def 
+$F2psDict begin
+$F2psDict /mtrx matrix put
+/l {lineto} bind def
+/m {moveto} bind def
+/s {stroke} bind def
+/n {newpath} bind def
+/gs {gsave} bind def
+/gr {grestore} bind def
+/clp {closepath} bind def
+/graycol {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
+4 -2 roll mul setrgbcolor} bind def
+/col-1 {} def
+/col0 {0 0 0 setrgbcolor} bind def
+/col1 {0 0 1 setrgbcolor} bind def
+/col2 {0 1 0 setrgbcolor} bind def
+/col3 {0 1 1 setrgbcolor} bind def
+/col4 {1 0 0 setrgbcolor} bind def
+/col5 {1 0 1 setrgbcolor} bind def
+/col6 {1 1 0 setrgbcolor} bind def
+/col7 {1 1 1 setrgbcolor} bind def
+	end
+/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
+/$F2psEnd {$F2psEnteredState restore end} def
+
+$F2psBegin
+0 setlinecap 0 setlinejoin
+-4.0 391.0 translate 0.900 -0.900 scale
+0.500 setlinewidth
+n 149 169 m 149 149 l  369 149 l  369 169 l gs col-1 s gr
+n 149 189 m 369 189 l gs col-1 s gr
+	1 setlinecap [1 4.000000] 4.000000 setdash
+n 369 169 m 369 189 l gs col-1 s gr
+	[] 0 setdash 0 setlinecap
+	1 setlinecap [1 4.000000] 4.000000 setdash
+n 149 169 m 149 189 l gs col-1 s gr
+	[] 0 setdash 0 setlinecap
+/Courier-Bold findfont 12.00 scalefont setfont
+154 164 m 
+gs 1 -1 scale (QNAME) col-1 show gr
+n 9 189 m 9 169 l  89 169 l  89 189 l gs col-1 s gr
+n 9 269 m 89 269 l gs col-1 s gr
+n 9 249 m 89 249 l gs col-1 s gr
+n 9 229 m 89 229 l gs col-1 s gr
+n 9 209 m 89 209 l gs col-1 s gr
+n 9 189 m 89 189 l gs col-1 s gr
+	1 setlinecap [1 3.000000] 3.000000 setdash
+n 89 189 m 89 269 l gs col-1 s gr
+	[] 0 setdash 0 setlinecap
+	1 setlinecap [1 3.000000] 3.000000 setdash
+n 9 189 m 9 269 l gs col-1 s gr
+	[] 0 setdash 0 setlinecap
+/Courier-Bold findfont 12.00 scalefont setfont
+14 184 m 
+gs 1 -1 scale (HEADER) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+14 204 m 
+gs 1 -1 scale (QUESTION) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+14 224 m 
+gs 1 -1 scale (ANSWER) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+14 244 m 
+gs 1 -1 scale (AUTHORITY) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+14 264 m 
+gs 1 -1 scale (ADDITIONAL) col-1 show gr
+n 369 129 m 369 9 l  149 9 l  149 129 l  clp gs col-1 s gr
+n 149 29 m 369 29 l gs col-1 s gr
+n 149 49 m 369 49 l gs col-1 s gr
+n 149 69 m 369 69 l gs col-1 s gr
+n 149 89 m 369 89 l gs col-1 s gr
+n 149 109 m 369 109 l gs col-1 s gr
+n 149 189 m 149 229 l  369 229 l  369 189 l gs col-1 s gr
+n 149 209 m 369 209 l gs col-1 s gr
+n 149 269 m 149 249 l  369 249 l  369 269 l gs col-1 s gr
+n 149 289 m 369 289 l gs col-1 s gr
+	1 setlinecap [1 4.000000] 4.000000 setdash
+n 369 269 m 369 289 l gs col-1 s gr
+	[] 0 setdash 0 setlinecap
+	1 setlinecap [1 4.000000] 4.000000 setdash
+n 149 269 m 149 289 l gs col-1 s gr
+	[] 0 setdash 0 setlinecap
+	1 setlinecap [1 4.000000] 4.000000 setdash
+n 369 409 m 369 429 l gs col-1 s gr
+	[] 0 setdash 0 setlinecap
+	1 setlinecap [1 4.000000] 4.000000 setdash
+n 149 409 m 149 429 l gs col-1 s gr
+	[] 0 setdash 0 setlinecap
+n 149 289 m 149 409 l gs col-1 s gr
+n 369 289 m 369 409 l gs col-1 s gr
+n 149 429 m 369 429 l gs col-1 s gr
+n 149 389 m 369 389 l gs col-1 s gr
+n 149 369 m 369 369 l gs col-1 s gr
+n 149 329 m 369 329 l gs col-1 s gr
+n 149 309 m 369 309 l gs col-1 s gr
+n 151 4 m 144 4 144 127 7 arcto 4 {pop} repeat 144 134 367 134 7 arcto 4 {pop} repeat 374 134 374 11 7 arcto 4 {pop} repeat 374 4 151 4 7 arcto 4 {pop} repeat clp gs col-1 s gr
+n 151 144 m 144 144 144 227 7 arcto 4 {pop} repeat 144 234 367 234 7 arcto 4 {pop} repeat 374 234 374 151 7 arcto 4 {pop} repeat 374 144 151 144 7 arcto 4 {pop} repeat clp gs col-1 s gr
+n 151 244 m 144 244 144 427 7 arcto 4 {pop} repeat 144 434 367 434 7 arcto 4 {pop} repeat 374 434 374 251 7 arcto 4 {pop} repeat 374 244 151 244 7 arcto 4 {pop} repeat clp gs col-1 s gr
+n 11 164 m 4 164 4 267 7 arcto 4 {pop} repeat 4 274 87 274 7 arcto 4 {pop} repeat 94 274 94 171 7 arcto 4 {pop} repeat 94 164 11 164 7 arcto 4 {pop} repeat clp gs col-1 s gr
+1.000 setlinewidth
+n 94 179 m 144 29 l gs col-1 s gr
+n 135.146 42.914 m 144.000 29.000 l 142.735 45.444 l gs 2 setlinejoin col-1 s gr
+n 94 199 m 144 169 l gs col-1 s gr
+n 128.222 173.802 m 144.000 169.000 l 132.338 180.662 l gs 2 setlinejoin col-1 s gr
+0.500 setlinewidth
+n 94 209 m 99 214 l  99 234 l  104 239 l  99 244 l  99 264 l 
+ 94 269 l gs col-1 s gr
+1.000 setlinewidth
+n 104 239 m 144 269 l gs col-1 s gr
+n 133.600 256.200 m 144.000 269.000 l 128.800 262.600 l gs 2 setlinejoin col-1 s gr
+/Courier-Bold findfont 12.00 scalefont setfont
+154 24 m 
+gs 1 -1 scale (ID) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+154 44 m 
+gs 1 -1 scale (QR/OPCODE/AA/TC/RD/RA/Z/RCODE) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+154 64 m 
+gs 1 -1 scale (QDCOUNT) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+154 84 m 
+gs 1 -1 scale (ANCOUNT) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+154 104 m 
+gs 1 -1 scale (NSCOUNT) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+154 124 m 
+gs 1 -1 scale (ARCOUNT) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+154 204 m 
+gs 1 -1 scale (QTYPE) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+154 224 m 
+gs 1 -1 scale (QCLASS) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+154 264 m 
+gs 1 -1 scale (NAME) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+154 304 m 
+gs 1 -1 scale (TYPE) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+154 324 m 
+gs 1 -1 scale (CLASS) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+154 344 m 
+gs 1 -1 scale (TTL) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+154 384 m 
+gs 1 -1 scale (RDLENGTH) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+154 404 m 
+gs 1 -1 scale (RDATA) col-1 show gr
+$F2psEnd
+%%EndDocument
+ @endspecial 781 2464 a(Figure)g(2.3)33 b(DNS)16 b(message)p
+eop
+%%Page: 15 24
+23 bop 1901 -100 a Fo(15)222 75 y Fj(\017)24 b Fo(a)17 b(16)g(bit)f(iden)o
+(ti\014er)f(is)h(assigned)g(b)o(y)g(the)g(program)g(that)h(generates)f(an)o
+(y)g(kind)g(of)h(query)222 207 y Fj(\017)24 b Fo(the)18 b(\\QR")g(bit)g(sp)q
+(eci\014es)f(whether)h(the)f(message)g(is)h(a)g(query)f(\(v)m(alue)g(0\))h
+(or)h(a)f(resp)q(onse)271 297 y(\(v)m(alue)e(1\))222 429 y
+Fj(\017)24 b Fo(the)12 b(\\OPCODE")i(is)d(a)i(four)f(bit)g(\014eld)f(that)i
+(sp)q(eci\014es)e(the)h(kind)g(of)g(query)f(in)h(the)g(message.)271
+519 y(It)k(can)h(con)o(tain)f(the)g(follo)o(wing)g(v)m(alues:)326
+651 y Fi({)25 b Fo(0)16 b(for)h(a)f(standard)i(query)d(\(QUER)l(Y\))326
+762 y Fi({)25 b Fo(1)16 b(for)h(an)g(in)o(v)o(erse)d(query)i(\(IQUER)l(Y\))
+326 873 y Fi({)25 b Fo(2)16 b(for)h(a)f(serv)o(er)g(status)h(request)e(\(ST)l
+(A)l(TUS\))326 984 y Fi({)25 b Fo(3)16 b(-)h(15)g(reserv)o(ed)e(for)h(future)
+g(use)222 1116 y Fj(\017)24 b Fo(the)16 b(next)g(bit)f(\\AA")h(is)g(only)g(v)
+m(alid)f(in)h(a)g(resp)q(onse)h(and)g(sp)q(eci\014es)e(that)i(the)e(resp)q
+(onding)271 1206 y(name)g(serv)o(er)h(is)g(an)g(authorit)o(y)g(for)h(the)f
+(domain)f(name)g(in)h(the)g(question)g(section)222 1338 y Fj(\017)24
+b Fo(the)16 b(\\TC")i(bit)e(sp)q(eci\014es)g(if)f(a)i(message)e(w)o(as)i
+(truncated)222 1469 y Fj(\017)24 b Fo(the)16 b(\\RD")i(bit)d(sp)q(eci\014es)h
+(if)g(recursion)g(is)g(desired)g(b)o(y)f(a)i(query)222 1601
+y Fj(\017)24 b Fo(the)16 b(\\RA")h(bit)f(sp)q(eci\014es)g(if)f(recursion)h
+(is)g(a)o(v)m(ailable)222 1733 y Fj(\017)24 b Fo(the)16 b(follo)o(wing)g
+(three)g(bits)g(in)g(the)g(\\Z")h(\014eld)e(are)i(reserv)o(ed)e(for)h(future)
+g(use)222 1865 y Fj(\017)24 b Fo(the)c(last)f(four)h(bits)g(determine)d(the)i
+(resp)q(onse)i(co)q(de)e(\\R)o(CODE".)h(P)o(ossible)g(v)m(alues)f(for)271
+1955 y(the)d(resp)q(onse)h(co)q(de)g(are:)326 2087 y Fi({)25
+b Fo(0)16 b(for)h(\\No)f(Error)h(Condition")326 2198 y Fi({)25
+b Fo(1)16 b(to)h(indicate)e(a)i(\\F)l(ormat)f(Error")326 2309
+y Fi({)25 b Fo(2)16 b(to)h(indicate)e(a)i(\\Serv)o(er)e(F)l(ailure")326
+2420 y Fi({)25 b Fo(3)16 b(to)h(indicate)e(a)i(\\Name)e(Error")326
+2531 y Fi({)25 b Fo(4)16 b(to)h(indicate)e(that)i(the)f(requested)f(feature)h
+(is)g(\\Not)h(Implem)o(en)n(ted")p eop
+%%Page: 16 25
+24 bop 1901 -100 a Fo(16)326 75 y Fi({)25 b Fo(5)f(to)g(indicate)f(that)i
+(the)e(name)g(serv)o(er)g(\\Refused")h(to)g(p)q(erform)f(the)h(sp)q
+(eci\014ed)379 165 y(op)q(eration)326 276 y Fi({)h Fo(6)16
+b(-)h(15)g(are)f(reserv)o(ed)f(for)i(future)f(use)222 408 y
+Fj(\017)24 b Fo(The)17 b(follo)o(wing)f(four)g(unsigned)h(16)g(bit)f(in)o
+(teger)f(v)m(alues)i(sp)q(ecify)e(the)h(n)o(um)o(b)q(er)f(of)i(en)o(tries)271
+498 y(in)f(the)g(follo)o(wing)g(question,)g(answ)o(er,)g(authorit)o(y)l(,)f
+(and)i(additional)g(sections.)223 642 y(The)i(con)o(ten)o(ts)g(of)g(these)g
+(four)h(sections)f(serv)o(e)f(di\013eren)o(t)g(purp)q(oses.)32
+b(The)19 b(order)g(of)h(these)149 733 y(section)f(is)g(alw)o(a)o(ys)g(the)g
+(same.)30 b(Some)18 b(of)h(the)g(sections)g(can)h(b)q(e)f(empt)o(y)e(in)i(a)g
+(DNS)h(message.)149 823 y(The)d(format)e(of)i(the)f(answ)o(er,)g(authorit)o
+(y)g(and)h(additional)f(section)g(is)g(the)g(same.)223 913
+y(The)e(question)g(section)g(carries)g(query)g(name,)f(query)h(t)o(yp)q(e)g
+(and)h(query)f(class.)21 b(V)l(alid)13 b(query)149 1004 y(t)o(yp)q(es)g(are)g
+(all)f(the)g(co)q(des)h(for)g(resource)f(record)h(t)o(yp)q(es,)g(whic)o(h)f
+(w)o(e)g(will)f(explain)h(in)g(the)h(follo)o(wing)149 1094
+y(Section)h(2.4.3,)h(and)g(some)f(more)f(general)h(ones)h(for)g(zone)g
+(transfer,)f(mail)f(handling)i(tasks,)g(and)149 1184 y(wild{carding.)223
+1274 y(The)h(follo)o(wing)g(class)g(mnemonics)d(and)k(v)m(alues)g(are)f
+(curren)o(tly)e(de\014ned:)222 1406 y Fj(\017)24 b Fo(1)17
+b(for)g(\\IN")f({)g(In)o(ternet)222 1538 y Fj(\017)24 b Fo(2)17
+b(for)g(\\CS")g({)g(CSNET)222 1670 y Fj(\017)24 b Fo(3)17 b(for)g(\\CH")f({)h
+(CHA)o(OS)222 1802 y Fj(\017)24 b Fo(4)17 b(for)g(\\HS")f({)h(Hesio)q(d)222
+1933 y Fj(\017)24 b Fo(255)18 b(for)e(wild{carding)223 2065
+y(The)k(answ)o(er)h(section)f(carries)g(resource)g(records)h(that)g(directly)
+d(answ)o(er)j(the)f(query)l(,)h(the)149 2155 y(authorit)o(y)g(section)f
+(carries)g(resource)g(records)h(that)f(describ)q(e)g(other)h(authoritativ)o
+(e)f(serv)o(ers,)149 2246 y(and)g(the)e(additional)h(section)g(carries)f
+(resource)g(records)h(that)g(are)g(not)g(explicitly)d(requested)149
+2336 y(but)h(migh)o(t)d(b)q(e)j(helpful)e(in)h(using)h(the)f(resource)g
+(records)g(in)g(the)g(other)g(sections.)223 2426 y(The)k(authoritativ)o(e)h
+(section)f(con)o(tains)h(name)f(serv)o(er)f(data)j(in)e(the)h(follo)o(wing)f
+(case:)31 b(if)20 b(a)149 2517 y(name)14 b(serv)o(er)g(tries)g(to)h(resolv)o
+(e)f(a)h(name)e(and)j(he)e(kno)o(ws)h(of)g(an)h(authoritativ)o(e)e(name)f
+(serv)o(er)h(for)149 2607 y(the)h(domain)g(in)g(whic)o(h)f(the)h(name)f(lies)
+g(that)i(has)g(to)f(b)q(e)g(resolv)o(ed,)f(he)h(puts)h(the)f(name)f(serv)o
+(er's)p eop
+%%Page: 17 26
+25 bop 1901 -100 a Fo(17)149 75 y(name)13 b(in)o(to)h(the)f(authorit)o(y)h
+(section)g(of)g(the)f(reply)l(.)20 b(This)14 b(is)g(the)f(approac)o(h)i(in)e
+(the)h(DNS)g(to)g(refer)149 165 y(clien)o(ts)h(to)i(others)f(serv)o(ers)g(in)
+g(the)g(not)g(recursiv)o(e)f(mo)q(de.)223 255 y(The)g(additional)g(section)g
+(pla)o(ys)g(an)g(imp)q(ortan)o(t)g(role)f(in)h(the)g(same)f(case.)21
+b(If)15 b(a)h(name)e(serv)o(er)149 346 y(refers)19 b(a)h(resolv)o(er)e(to)i
+(another)g(name)e(serv)o(er,)g(he)h(b)q(etter)g(also)h(pro)o(vides)f(the)g
+(address)h(of)g(the)149 436 y(other)f(name)e(serv)o(er,)h(b)q(ecause)h(that)g
+(is)f(the)g(next)h(information)e(the)h(resolv)o(er)g(needs)g(in)g(order)149
+526 y(to)f(pro)q(ceed)e(with)h(his)f(queries.)20 b(Another)c(reason)g(to)g
+(ha)o(v)o(e)f(the)h(additional)f(section)h(is)f(to)h(ha)o(v)o(e)149
+616 y(space)j(for)f(extra,)g(not)g(requested)f(information.)26
+b(If)17 b(a)i(resolv)o(er)e(receiv)o(es)f(additional)i(records,)149
+707 y(and)25 b(cac)o(hes)e(them,)h(he)g(migh)o(t)e(b)q(e)i(able)g(to)g(use)g
+(them)e(later.)44 b(That)25 b(w)o(ould)f(result)f(in)h(an)149
+797 y(increased)14 b(p)q(erformance)f(of)h(the)g(system,)e(b)q(ecause)i(the)g
+(resolution)g(of)g(data)h(that)f(is)g(already)g(in)149 887
+y(the)k(lo)q(cal)g(cac)o(he)g(is)g(considerably)f(more)g(e\016cien)o(t)f
+(than)j(a)f(remote)f(resolution)h(that)h(requires)149 978 y(net)o(w)o(ork)d
+(tra\016c.)223 1068 y(These)g(three)f(t)o(yp)q(es)h(of)h(DNS)f(message)g
+(sections)g(share)g(the)g(same)g(format.)k(They)c(ha)o(v)o(e:)222
+1182 y Fj(\017)24 b Fo(a)17 b(name)222 1306 y Fj(\017)24 b
+Fo(a)17 b(t)o(yp)q(e)f(as)h(in)f(a)g(query)222 1430 y Fj(\017)24
+b Fo(a)17 b(class)f(as)h(in)f(a)h(query)222 1555 y Fj(\017)24
+b Fo(a)17 b(32)g(bit)f(time)e(to)j(liv)o(e)d(\014eld)i(giv)o(en)f(in)h
+(seconds)h(\(TTL\))222 1679 y Fj(\017)24 b Fo(an)15 b(unsigned)g(16)g(bit)f
+(in)o(teger)g(that)h(sp)q(eci\014es)f(the)g(length)g(of)h(the)g(RD)o(A)l(T)l
+(A)e(\014eld)h(in)g(b)o(ytes)222 1803 y Fj(\017)24 b Fo(a)17
+b(v)m(ariable)f(length)g(string)g(of)h(b)o(ytes)f(that)g(describ)q(es)g(the)g
+(resource.)149 1967 y(2.4.3)49 b(Resource)16 b(Records)223
+2089 y(Data)g(that)h(is)e(asso)q(ciated)i(with)f(the)g(no)q(des)g(and)h(lea)o
+(v)o(es)d(of)i(this)g(tree)f(is)h(exc)o(hanged)f(in)h(the)149
+2180 y(RD)o(A)l(T)l(A)f(p)q(ortion)i(of)g(the)e(last)h(three)g(sections)g(in)
+f(a)i(DNS)e(message.)21 b(These)16 b(resource)f(records)149
+2270 y(are)i(tagged)g(according)g(to)f(the)g(t)o(yp)q(e)g(of)h(data)g(they)f
+(con)o(tain.)21 b(W)l(e)16 b(men)o(tion)f(only)h(those)h(t)o(yp)q(es)149
+2360 y(that)h(pro)o(vide)f(necessary)g(information)g(for)h(understanding)g
+(this)f(thesis.)25 b(A)17 b(complete)e(list)i(of)149 2451 y(t)o(yp)q(es)f
+(and)h(classes)g(can)f(b)q(e)g(found)h(in)f(RF)o(C)g(1035)i(\([Mo)q(c87b]\).)
+222 2560 y Fj(\017)24 b Fo(an)16 b(\\A")f(record)g(con)o(tains)f(a)i(host)f
+(address;)h(a)f(32-bit)h(In)o(ternet)d(address)j(when)f(the)f(class)271
+2650 y(is)i(\\IN")p eop
+%%Page: 18 27
+26 bop 1901 -100 a Fo(18)222 75 y Fj(\017)24 b Fo(an)18 b(\\NS")f(record)f
+(sp)q(eci\014es)g(a)h(host)h(whic)o(h)e(should)h(b)q(e)g(authoritativ)o(e)f
+(for)h(the)f(sp)q(eci\014ed)271 165 y(class)h(and)g(domain)222
+294 y Fj(\017)24 b Fo(an)18 b(\\SO)o(A")g(record)f(is)h(the)f(\014rst)h(en)o
+(try)e(in)i(eac)o(h)f(of)h(the)f(database)i(\014les)e(and)h(sp)q(eci\014es)f
+(a)271 385 y(serv)o(er)f(to)g(b)q(e)h(the)f(authoritativ)o(e)f(source)i(of)f
+(information)f(within)h(the)g(domain)222 514 y Fj(\017)24 b
+Fo(a)e(\\PTR")h(record)f(pro)o(vides)f(a)h(p)q(oin)o(ter)f(to)i(another)f(lo)
+q(cation)g(in)f(the)h(domain)f(name)271 604 y(space)222 734
+y Fj(\017)j Fo(an)d(\\HINF)o(O")d(record)i(iden)o(ti\014es)e(the)h(CPU)h(t)o
+(yp)q(e)f(and)h(op)q(erating)h(system)d(t)o(yp)q(e)h(used)271
+824 y(b)o(y)d(a)h(host)222 954 y Fj(\017)24 b Fo(a)14 b(\\CNAME")g(record)f
+(sp)q(eci\014es)h(the)f(canonical)g(or)h(primary)e(name)h(for)h(the)f(o)o
+(wner)h({)g(the)271 1044 y(o)o(wner)j(is)f(an)g(alias)222 1173
+y Fj(\017)24 b Fo(a)17 b(\\MX")g(record)g(sp)q(eci\014es)f(a)h(host)g
+(willing)f(to)h(act)g(as)g(a)g(mail)e(exc)o(hange)h(for)h(the)f(o)o(wner)271
+1264 y(name)f(and)i(a)g(preference)e(giv)o(en)g(among)h(other)g(resource)g
+(records)h(at)f(the)g(same)g(o)o(wner)222 1393 y Fj(\017)24
+b Fo(an)18 b(\\X25")h(record)e(con)o(tains)h(a)f(c)o(haracter)g(string)h
+(whic)o(h)f(iden)o(ti\014es)f(a)i(public)e(switc)o(hed)271
+1483 y(data)h(net)o(w)o(ork)f(address)222 1613 y Fj(\017)24
+b Fo(an)14 b(\\ISDN")g(record)f(con)o(tains)g(a)h(c)o(haracter)e(string)i
+(whic)o(h)e(iden)o(ti\014es)g(an)i(ISDN)1756 1595 y Fm(7)1788
+1613 y Fo(n)o(um)o(b)q(er)271 1703 y(of)j(the)f(o)o(wner)g(and)h(the)f(DDI)g
+(\(Direct)g(Dial)g(In\),)f(if)h(an)o(y)149 1899 y(2.4.4)49
+b(Name)15 b(Serv)o(ers)223 2021 y(The)k(whole)h(database)h(is)f(divided)f(in)
+o(to)g(zones)h(that)g(are)g(distributed)f(among)h(the)g(name)149
+2111 y(serv)o(ers.)34 b(The)20 b(essen)o(tial)g(task)g(of)h(a)g(name)e(serv)o
+(er)h(is)g(to)h(answ)o(er)g(queries)e(using)i(data)h(in)e(its)149
+2202 y(zone.)38 b(T)l(o)23 b(ensure)e(a)h(higher)g(degree)f(of)i(reliabilit)o
+(y)c(of)j(the)f(system,)h(the)f(de\014nition)h(of)g(the)149
+2292 y(Domain)17 b(Name)f(System)g(requires)g(that)i(at)g(least)f(t)o(w)o(o)h
+(name)e(serv)o(ers)h(con)o(tain)g(authoritativ)o(e)149 2382
+y(data)23 b(for)f(a)g(giv)o(en)f(zone.)37 b(Some)20 b(sites)i(run)g(more)e
+(than)i(t)o(w)o(o)g(name)e(serv)o(ers:)31 b(one)22 b(of)g(them)149
+2473 y(usually)d(outside)h(of)f(the)h(a\013ected)f(net)o(w)o(ork)g(to)g
+(guaran)o(tee)h(name)e(service)g(if)h(the)g(net)o(w)o(ork)g(is)149
+2563 y(unreac)o(hable)12 b(for)f(some)g(reason.)21 b(The)11
+b(main)g(name)f(serv)o(er)h(is)g(called)g(the)g(primary)f(name)h(serv)o(er,)p
+149 2604 720 2 v 206 2635 a Fl(7)224 2650 y Fk(In)o(tegrated)k(Services)g
+(Digital)d(Net)o(w)o(ork)p eop
+%%Page: 19 28
+27 bop 1901 -100 a Fo(19)731 101 y(T)l(able)16 b(2.1)33 b(Subset)16
+b(of)h(QTYPEs)452 232 y(QTYPE)p 662 259 2 91 v 60 w(v)m(alue)p
+821 259 V 49 w(meaning)p 427 261 1246 2 v 452 324 a(A)p 662
+351 2 91 v 199 w(1)p 821 351 V 135 w(a)g(host)g(address)452
+414 y(NS)p 662 441 V 172 w(2)p 821 441 V 135 w(an)g(authoritativ)o(e)f(name)f
+(serv)o(er)452 505 y(SO)o(A)p 662 532 V 135 w(6)p 821 532 V
+135 w(start)i(of)f(authorit)o(y)452 595 y(PTR)p 662 622 V 132
+w(12)p 821 622 V 111 w(a)h(domain)e(name)g(p)q(oin)o(ter)452
+685 y(HINF)o(O)p 662 712 V 75 w(13)p 821 712 V 111 w(host)i(information)e
+(CPU)i(and)f(OS)452 775 y(CNAME)p 662 802 V 49 w(14)p 821 802
+V 111 w(canonical)g(name)f(\(alias\))452 866 y(MX)p 662 893
+V 154 w(15)p 821 893 V 111 w(mail)g(exc)o(hange)452 956 y(X25)p
+662 983 V 151 w(19)p 821 983 V 111 w(public)g(switc)o(hed)h(data)h(net)o(w)o
+(ork)f(address)452 1046 y(ISDN)p 662 1073 V 117 w(20)p 821
+1073 V 111 w(in)o(tegrated)g(services)f(digital)h(net)o(w)o(ork)149
+1302 y(and)j(the)g(bac)o(kup)f(serv)o(ers)g(are)g(called)f(secondary)i(name)e
+(serv)o(ers.)27 b(Secondary)19 b(authoritativ)o(e)149 1392
+y(name)d(serv)o(ers)g(up)q(date)i(the)f(data)h(base)f(for)g(their)f(zone)h(p)
+q(erio)q(dically)f(with)h(data)h(p)q(olled)f(from)149 1482
+y(their)g(primary)e(serv)o(ers.)22 b(Primary)16 b(name)f(serv)o(ers)h(load)i
+(the)e(database)j(\014les)d(pro)o(vided)g(b)o(y)h(the)149 1573
+y(zone)f(administrator)e(and)i(main)o(tain)e(a)i(cac)o(he)f(of)g(data)i(that)
+f(w)o(as)g(acquired)e(through)j(resource)149 1663 y(records.)39
+b(Serv)o(ers)22 b(w)o(an)o(t)g(to)g(adapt)i(dynamically)19
+b(to)k(c)o(hanges)f(in)g(the)g(setup)g(of)h(the)f(name)149
+1753 y(space)f(of)g(other)g(authorities.)35 b(Therefore,)21
+b(eac)o(h)f(resource)h(record)f(con)o(tains)h(a)g(time)e(to)i(liv)o(e)149
+1843 y(\014eld)16 b(whic)o(h)g(ensures)g(that)h(name)e(serv)o(ers)g(do)i(not)
+g(cac)o(he)e(data)i(without)g(time)d(b)q(ound.)223 1934 y(The)22
+b(actual)g(algorithm)f(name)g(serv)o(ers)g(use)h(dep)q(ends)h(on)f(the)g(lo)q
+(cal)g(op)q(erating)h(system)149 2024 y(and)c(data)g(structures)f(used)g(to)g
+(store)g(resource)g(records.)26 b(A)18 b(basic)g(outline)f(can)h(b)q(e)g
+(found)h(in)149 2114 y([Mo)q(c87a)q(,)d(section)g(4.3.2])g(and)h(in)f
+(section)g(2.9.2)g(of)h(this)f(thesis.)149 2274 y(2.4.5)49
+b(Resolv)o(ers)223 2397 y(The)16 b(in)o(terface)f(b)q(et)o(w)o(een)h(the)g
+(Domain)g(Name)f(System)g(and)j(user)e(programs)h(is)f(the)h(name)149
+2487 y(resolv)o(er.)29 b(In)19 b(the)g(simplest)e(case,)i(a)g(resolv)o(er)f
+(receiv)o(es)f(a)j(request)e(from)g(a)i(user)f(program)g(in)149
+2577 y(the)c(form)f(of)h(a)h(system)d(call)h(or)i(subroutine)f(call)f(and)i
+(returns)f(the)f(desired)h(information.)k(The)p eop
+%%Page: 20 29
+28 bop 1901 -100 a Fo(20)149 75 y(resolv)o(er)12 b(is)g(lo)q(cated)h(on)g
+(the)g(same)e(mac)o(hine)g(as)i(the)f(user)h(program,)g(but)f(con)o(tacts)h
+(one)g(or)g(more)149 165 y(name)19 b(serv)o(ers)h(on)h(\(usually\))e(remote)g
+(mac)o(hines)f(if)i(the)g(requested)f(data)j(is)e(not)g(obtainable)149
+255 y(from)c(the)g(lo)q(cal)g(cac)o(he.)223 346 y(The)j(t)o(ypical)g(resolv)o
+(er{clien)o(t)e(in)o(terface)h(has)i(a)g(triple)f(functionalit)o(y:)27
+b(host)20 b(name)f(to)h(IP)149 436 y(address)j(translation,)g(IP)e(address)h
+(to)g(host)g(name)f(translation,)i(and)f(a)g(lo)q(okup)g(of)g(general)149
+526 y(information)f(sp)q(ecifying)h(query)f(name,)h(t)o(yp)q(e,)g(and)h
+(class.)39 b(The)22 b(follo)o(wing)f(results)h(can)g(b)q(e)149
+616 y(obtained)e(after)e(the)h(resolv)o(er)e(p)q(erformed)h(the)h(indicated)f
+(function:)26 b(the)18 b(data)i(requested,)e(a)149 707 y(name)e(error)g(in)g
+(case)g(the)g(referenced)f(name)g(do)q(es)i(not)f(exist,)f(or)i(a)g(data)g
+(not)f(found)h(error.)223 797 y(T)l(o)i(obtain)f(higher)h(e\016ciency)l(,)d
+(it)i(is)g(reasonable)h(to)f(ha)o(v)o(e)g(all)g(resolv)o(ers)f(on)i(one)g
+(mac)o(hine)149 887 y(share)i(their)f(cac)o(he.)32 b(An)20
+b(algorithm)g(outline)f(for)i(the)f(resolv)o(er)f(can)i(b)q(e)f(found)h(in)f
+([Mo)q(c87a)q(,)149 978 y(section)c(5.3.3])g(and)h(in)f(section)g(2.9.3)g(of)
+h(this)f(thesis.)149 1143 y(2.5)50 b(F)l(orw)o(ard)16 b(and)h(In)o(v)o(erse)e
+(Mapping)h(T)l(ree)223 1283 y(The)d(Domain)f(Name)f(Space)i(consists)h(of)f
+(a)h(hierarc)o(h)o(y)d(of)j(domain)e(names.)19 b(As)13 b(the)g(decimal)149
+1373 y(n)o(um)o(b)q(ers)j(in)h(the)g(dotted)h(quad)f(notation)h(for)g(IP)f
+(addresses)h(can)f(b)q(e)h(view)o(ed)e(as)i(names,)e(it)h(is)149
+1463 y(only)j(one)f(step)h(to)g(construct)f(a)h(tree)f(that)h(consists)g(of)g
+(these)f(n)o(um)o(b)q(ers)f(as)i(domain)f(names.)149 1553 y(This)g(in)o(v)o
+(erse)e(mapping)g(tree)h(is)g(moun)o(ted)f(on)i(the)f(domain)g(in-addr.arpa.)
+28 b(The)19 b(IP)f(address)149 1644 y(128.46.152.78)24 b(for)d(zo)q
+(o.ecn.purdue.edu)e(has)j(the)e(corresp)q(onding)i(name)d(78.152.46.128.in-)
+149 1734 y(addr.arpa)f(whic)o(h)d(maps)h(bac)o(k)g(to)g(zo)q
+(o.ecn.purdue.edu)f(\(see)h(Figure)g(2.4\).)223 1824 y(The)j(reason)h(for)f
+(the)g(n)o(um)o(b)q(ers)f(of)h(the)g(IP)g(address)h(app)q(earing)g(in)f(rev)o
+(erse)f(order)h(in)g(the)149 1915 y(rev)o(erse)d(mapping)g(tree)g(is)g(the)h
+(follo)o(wing:)22 b(Domain)16 b(names)f(read)i(from)f(left)g(to)h(righ)o(t)f
+(get)h(less)149 2005 y(sp)q(eci\014c,)12 b(whereas)h(IP)f(addresses)h(get)f
+(more)f(sp)q(eci\014c)h(from)f(left)g(to)i(righ)o(t)f(\(see)f(Figure)h
+(2.5\).)20 b(The)149 2095 y(task)f(of)g(delegating)g(authorit)o(y)f(for)h
+(in-addr.arpa)h(domains)e(to)h(zone)f(administrators)g(w)o(ould)149
+2185 y(b)q(e)f(imp)q(ossible)d(if)i(the)g(en)o(tries)f(app)q(eared)i(in)f
+(the)g(original)g(order.)223 2276 y(In)h(case)g(someone)g(w)o(an)o(ted)g(to)h
+(index)e(an)i(arbitrary)g(piece)e(of)h(data)i(in)e(the)g(domain)f(space)149
+2366 y(\(something)j(aside)h(from)f(IP)h(addresses)g(or)g(host)h(names\),)e
+(an)i(additional)f(sub)q(domain)g(suc)o(h)149 2456 y(as)g(the)f(in-addr.arpa)
+h(domain)f(is)f(necessary)l(.)30 b(A)19 b(so)h(called)e(in)o(v)o(erse)f(lo)q
+(okup)j(\(an)g(exhaustiv)o(e)149 2547 y(searc)o(h)c(of)g(the)f(whole)h
+(domain)f(name)f(space\),)i(is)f(also)h(p)q(ossible,)g(but)g(not)g(feasible)e
+(for)i(regular)149 2637 y(usage.)21 b(An)o(y)13 b(one)g(name)f(serv)o(er)g
+(only)h(kno)o(ws)g(ab)q(out)h(part)g(of)f(the)g(o)o(v)o(erall)f(domain)g
+(name)g(space.)p eop
+%%Page: 21 30
+29 bop 1901 -100 a Fo(21)524 979 y @beginspecial 0 @llx 0 @lly
+261 @urx 212 @ury 2610 @rwi @setspecial
+%%BeginDocument: pictures/rev_tree.ps
+/$F2psDict 200 dict def 
+$F2psDict begin
+$F2psDict /mtrx matrix put
+/l {lineto} bind def
+/m {moveto} bind def
+/s {stroke} bind def
+/n {newpath} bind def
+/gs {gsave} bind def
+/gr {grestore} bind def
+/clp {closepath} bind def
+/graycol {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
+4 -2 roll mul setrgbcolor} bind def
+/col-1 {} def
+/col0 {0 0 0 setrgbcolor} bind def
+/col1 {0 0 1 setrgbcolor} bind def
+/col2 {0 1 0 setrgbcolor} bind def
+/col3 {0 1 1 setrgbcolor} bind def
+/col4 {1 0 0 setrgbcolor} bind def
+/col5 {1 0 1 setrgbcolor} bind def
+/col6 {1 1 0 setrgbcolor} bind def
+/col7 {1 1 1 setrgbcolor} bind def
+	end
+/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
+/$F2psEnd {$F2psEnteredState restore end} def
+
+$F2psBegin
+0 setlinecap 0 setlinejoin
+-4.0 216.0 translate 0.900 -0.900 scale
+0.500 setlinewidth
+n 194 64 m 254 84 l gs col-1 s gr
+n 194 64 m 244 84 l gs col-1 s gr
+n 194 64 m 234 84 l gs col-1 s gr
+n 194 64 m 224 84 l gs col-1 s gr
+n 194 64 m 214 84 l gs col-1 s gr
+n 194 64 m 204 84 l gs col-1 s gr
+n 194 64 m 134 84 l gs col-1 s gr
+n 194 64 m 144 84 l gs col-1 s gr
+n 194 64 m 154 84 l gs col-1 s gr
+n 194 64 m 164 84 l gs col-1 s gr
+n 194 64 m 174 84 l gs col-1 s gr
+n 194 64 m 184 84 l gs col-1 s gr
+n 194 64 m 194 84 l gs col-1 s gr
+n 194 104 m 254 124 l gs col-1 s gr
+n 194 104 m 244 124 l gs col-1 s gr
+n 194 104 m 234 124 l gs col-1 s gr
+n 194 104 m 224 124 l gs col-1 s gr
+n 194 104 m 214 124 l gs col-1 s gr
+n 194 104 m 204 124 l gs col-1 s gr
+n 194 104 m 134 124 l gs col-1 s gr
+n 194 104 m 144 124 l gs col-1 s gr
+n 194 104 m 154 124 l gs col-1 s gr
+n 194 104 m 164 124 l gs col-1 s gr
+n 194 104 m 174 124 l gs col-1 s gr
+n 194 104 m 184 124 l gs col-1 s gr
+n 194 104 m 194 124 l gs col-1 s gr
+1.000 setlinewidth
+n 194 104 m 114 144 l gs col-1 s gr
+0.500 setlinewidth
+n 114 144 m 174 164 l gs col-1 s gr
+n 114 144 m 164 164 l gs col-1 s gr
+n 114 144 m 154 164 l gs col-1 s gr
+n 114 144 m 144 164 l gs col-1 s gr
+n 114 144 m 134 164 l gs col-1 s gr
+n 114 144 m 124 164 l gs col-1 s gr
+n 114 144 m 54 164 l gs col-1 s gr
+n 114 144 m 64 164 l gs col-1 s gr
+n 114 144 m 74 164 l gs col-1 s gr
+n 114 144 m 84 164 l gs col-1 s gr
+n 114 144 m 94 164 l gs col-1 s gr
+n 114 144 m 104 164 l gs col-1 s gr
+n 114 144 m 114 164 l gs col-1 s gr
+1.000 setlinewidth
+n 114 144 m 154 184 l gs col-1 s gr
+0.500 setlinewidth
+n 154 184 m 214 204 l gs col-1 s gr
+n 154 184 m 204 204 l gs col-1 s gr
+n 154 184 m 194 204 l gs col-1 s gr
+n 154 184 m 184 204 l gs col-1 s gr
+n 154 184 m 174 204 l gs col-1 s gr
+n 154 184 m 164 204 l gs col-1 s gr
+n 154 184 m 94 204 l gs col-1 s gr
+n 154 184 m 104 204 l gs col-1 s gr
+n 154 184 m 114 204 l gs col-1 s gr
+n 154 184 m 124 204 l gs col-1 s gr
+n 154 184 m 134 204 l gs col-1 s gr
+n 154 184 m 144 204 l gs col-1 s gr
+n 154 184 m 154 204 l gs col-1 s gr
+1.000 setlinewidth
+n 154 184 m 114 224 l gs col-1 s gr
+n 194 64 m 194 104 l gs col-1 s gr
+0.500 setlinewidth
+	1 setlinecap [1 3.000000] 3.000000 setdash
+n 294 44 m 294 54 l gs col-1 s gr
+	[] 0 setdash 0 setlinecap
+n 94 4 m 194 64 l gs col-1 s gr
+n 94 4 m 94 44 l gs col-1 s gr
+n 94 4 m 39 39 l gs col-1 s gr
+	1 setlinecap [1 3.000000] 3.000000 setdash
+n 39 39 m 4 59 l gs col-1 s gr
+	[] 0 setdash 0 setlinecap
+	1 setlinecap [1 3.000000] 3.000000 setdash
+n 94 44 m 94 59 l gs col-1 s gr
+	[] 0 setdash 0 setlinecap
+/Times-Bold findfont 12.00 scalefont setfont
+199 99 m 
+gs 1 -1 scale (128) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+154 179 m 
+gs 1 -1 scale (152) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+134 219 m 
+gs 1 -1 scale (78) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+139 144 m 
+gs 1 -1 scale (46) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+64 239 m 
+gs 1 -1 scale (zoo.ecn.purdue.edu) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+69 54 m 
+gs 1 -1 scale (edu) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+189 54 m 
+gs 1 -1 scale (in-addr.arpa) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+29 54 m 
+gs 1 -1 scale (ca) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+139 19 m 
+gs 1 -1 scale (IP address 128.46.152.78) col-1 show gr
+$F2psEnd
+%%EndDocument
+ @endspecial 657 1224 a(Figure)16 b(2.4)32 b(The)17 b(in-addr.arpa)g(domain)
+787 1645 y @beginspecial 0 @llx 0 @lly 126 @urx 65 @ury 1260
+@rwi @setspecial
+%%BeginDocument: pictures/nameaddr.ps
+/$F2psDict 200 dict def 
+$F2psDict begin
+$F2psDict /mtrx matrix put
+/l {lineto} bind def
+/m {moveto} bind def
+/s {stroke} bind def
+/n {newpath} bind def
+/gs {gsave} bind def
+/gr {grestore} bind def
+/clp {closepath} bind def
+/graycol {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
+4 -2 roll mul setrgbcolor} bind def
+/col-1 {} def
+/col0 {0 0 0 setrgbcolor} bind def
+/col1 {0 0 1 setrgbcolor} bind def
+/col2 {0 1 0 setrgbcolor} bind def
+/col3 {0 1 1 setrgbcolor} bind def
+/col4 {1 0 0 setrgbcolor} bind def
+/col5 {1 0 1 setrgbcolor} bind def
+/col6 {1 1 0 setrgbcolor} bind def
+/col7 {1 1 1 setrgbcolor} bind def
+	end
+/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
+/$F2psEnd {$F2psEnteredState restore end} def
+
+$F2psBegin
+0 setlinecap 0 setlinejoin
+0.0 72.0 translate 0.900 -0.900 scale
+0.500 setlinewidth
+n 139 24 m -1 24 l gs col-1 s gr
+n 7.000 26.000 m -1.000 24.000 l 7.000 22.000 l gs 2 setlinejoin col-1 s gr
+n -1 64 m 139 64 l gs col-1 s gr
+n 131.000 62.000 m 139.000 64.000 l 131.000 66.000 l gs 2 setlinejoin col-1 s gr
+/Times-Bold findfont 16.00 scalefont setfont
+-1 44 m 
+gs 1 -1 scale  360.0 rotate (uther.cs.purdue.edu) col-1 show gr
+/Times-Bold findfont 16.00 scalefont setfont
+29 59 m 
+gs 1 -1 scale  360.0 rotate (128.10.4.20) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+-1 19 m 
+gs 1 -1 scale  360.0 rotate (more specific) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+74 79 m 
+gs 1 -1 scale  360.0 rotate (more specific) col-1 show gr
+$F2psEnd
+%%EndDocument
+ @endspecial 686 1890 a(Figure)e(2.5)33 b(Degree)16 b(of)h(sp)q
+(eci\014cation)149 2074 y(Therefore,)d(an)g(in)o(v)o(erse)f(query)g(is)h(nev)
+o(er)e(guaran)o(teed)j(to)f(return)g(an)g(answ)o(er.)21 b(If)13
+b(a)i(name)e(serv)o(er)149 2165 y(receiv)o(es)i(an)i(in)o(v)o(erse)e(query)g
+(for)i(an)g(IP)g(address)g(it)f(kno)o(ws)h(nothing)g(ab)q(out,)g(it)f(cannot)
+i(return)149 2255 y(an)f(answ)o(er;)f(but)h(it)f(also)h(do)q(es)g(not)g(kno)o
+(w)f(if)g(the)g(IP)g(address)h(do)q(es)g(not)g(exist,)e(b)q(ecause)i(it)f
+(has)149 2345 y(only)f(its)g(part)h(of)g(the)f(DNS)g(database)h(to)g(w)o(ork)
+f(with.)21 b(Additionally)l(,)13 b(the)i(implem)o(en)o(tati)o(on)e(of)149
+2435 y(in)o(v)o(erse)i(queries)g(is)h(optional)h(according)f(to)h(the)f(DNS)g
+(sp)q(eci\014cation.)p eop
+%%Page: 22 31
+30 bop 1901 -100 a Fo(22)149 75 y(2.6)50 b(Recursion)15 b(and)i(Iteration)223
+214 y(When)i(there)g(is)h(the)f(need)g(for)h(resolving)f(a)h(name)f(in)g(the)
+g(Domain)g(Name)f(System,)h(the)149 305 y(follo)o(wing)i(steps)f(are)h(tak)o
+(en.)33 b(Who)q(ev)o(er)20 b(w)o(an)o(ts)h(to)g(resolv)o(e)e(a)i(name)e(in)o
+(v)o(ok)o(es)g(a)i(lo)q(cal)f(clien)o(t)149 395 y(program,)13
+b(the)g(resolv)o(er.)19 b(The)12 b(resolv)o(er)g(form)o(ulates)f(a)i(query)f
+(according)h(to)g(the)f(DNS)h(proto)q(col)149 485 y(and)k(con)o(tacts)g(its)f
+(lo)q(cal)g(name)f(serv)o(er.)223 575 y(These)h(queries)f(can)h(come)f(in)h
+(t)o(w)o(o)g(di\013eren)o(t)f(\015a)o(v)o(ors:)22 b(\\recursiv)o(e")15
+b(and)i(\\iterativ)o(e".)223 666 y(In)g(recursiv)o(e)f(resolution,)h(a)h
+(resolv)o(er)e(sends)i(a)g(recursiv)o(e)e(query)g(to)i(a)g(name)f(serv)o(er.)
+23 b(The)149 756 y(queried)13 b(name)f(serv)o(er)h(then)g(has)i(the)e
+(obligation)h(to)g(resp)q(ond)h(with)e(the)g(answ)o(er)h(to)g(that)g(query)
+149 846 y(or)20 b(with)g(an)g(error)f(co)q(de.)31 b(The)20
+b(name)e(serv)o(er)g(cannot)i(refer)f(the)g(resolv)o(er)g(to)h(another)g
+(name)149 937 y(serv)o(er.)28 b(In)18 b(case)g(the)h(queried)e(name)g(serv)o
+(er)h(is)g(not)h(authoritativ)o(e)f(for)h(the)f(requested)g(data,)149
+1027 y(it)k(has)g(to)g(resolv)o(e)f(the)g(query)g(again;)k(recursiv)o(e)19
+b(or)j(iterativ)o(e.)36 b(Curren)o(t)21 b(implem)o(en)o(tations)149
+1117 y(resolv)o(e)16 b(the)g(query)f(iterativ)o(e)f(and)j(do)g(not)g(pass)g
+(the)f(w)o(ork)g(to)h(another)g(serv)o(er.)223 1207 y(Iterativ)o(e)9
+b(resolution)j(do)q(es)g(not)g(require)f(nearly)g(as)h(m)o(uc)o(h)d(w)o(ork)j
+(on)g(the)f(part)h(of)g(the)g(queried)149 1298 y(name)k(serv)o(er.)23
+b(In)17 b(iterativ)o(e)e(resolution)i(a)g(name)f(serv)o(er)g(simply)f
+(returns)i(the)g(b)q(est)h(answ)o(er)f(it)149 1388 y(is)h(capable)g(of)h
+(giving.)26 b(No)18 b(additional)g(querying)f(of)i(other)f(name)f(serv)o(ers)
+g(is)h(required.)25 b(The)149 1478 y(queried)14 b(name)f(serv)o(er)g(only)h
+(consults)g(its)g(lo)q(cal)h(data)g(lo)q(oking)g(for)f(the)g(data)h
+(requested.)20 b(If)14 b(the)149 1569 y(data)k(is)e(not)h(there,)f(it)g(mak)o
+(es)f(its)h(b)q(est)h(attempt)e(to)i(giv)o(e)f(the)g(querier)f(data)j(that)f
+(will)e(help)h(it)149 1659 y(con)o(tin)o(ue)i(the)g(resolution)g(pro)q(cess.)
+28 b(This)19 b(data)g(usually)f(con)o(tains)h(names)e(and)i(addresses)g(of)
+149 1749 y(name)d(serv)o(ers)f(that)i(are)f(\\closer")g(to)h(the)f(data)h
+(its)f(seeking.)223 1839 y(After)10 b(p)q(ossibly)j(man)o(y)d(referrals,)h
+(the)h(lo)q(cal)g(name)e(serv)o(er)h(queries)g(the)g(authoritativ)o(e)h(name)
+149 1930 y(serv)o(er,)j(whic)o(h)h(returns)g(an)h(answ)o(er)f(or)h(an)g
+(error)f(co)q(de.)149 2095 y(2.7)50 b(Filling)14 b(in)i(the)g(Blanks)223
+2235 y(This)h(section)g(con)o(tains)h(features)f(that)h(w)o(ere)e(brie\015y)h
+(touc)o(hed)g(in)g(the)g(previous)g(sections,)149 2325 y(but)e(that)g(need)f
+(further)g(explanations:)21 b(the)14 b(cen)o(tral)f(role)h(of)h(cac)o(hes)f
+(for)h(system)e(p)q(erformance)149 2415 y(enhancemen)o(t,)h(the)i(role)f(of)h
+(administrativ)o(e)e(authorities,)h(and)i(the)f(t)o(yp)q(es)f(of)i(errors)f
+(that)g(can)149 2506 y(o)q(ccur)h(during)f(name)f(serv)o(er)h(op)q(eration.)p
+eop
+%%Page: 23 32
+31 bop 1901 -100 a Fo(23)149 75 y(2.7.1)49 b(Role)16 b(of)h(Cac)o(hes)223
+197 y(The)d(whole)h(resolution)f(pro)q(cess)h(ma)o(y)e(seem)g(con)o(v)o
+(oluted)h(and)h(cum)o(b)q(ersome)d(compared)h(to)149 287 y(simple)h(seeks)h
+(through)h(a)g(host)g(table)f(database.)22 b(Ho)o(w)o(ev)o(er,)14
+b(it)h(is)g(fast,)h(sp)q(eeded)f(up)g(consider-)149 378 y(ably)h(b)o(y)g(cac)
+o(hing.)223 468 y(As)11 b(our)h(example)d(in)i(Section)g(2.8)h(sho)o(ws,)h
+(name)d(serv)o(ers)h(ma)o(y)f(need)h(sev)o(eral)g(DNS)g(messages)149
+558 y(to)21 b(\014nd)f(the)f(answ)o(er)i(to)f(a)g(query)l(.)31
+b(During)21 b(successiv)o(e)d(resolution)i(attempts)f(name)f(serv)o(ers)149
+649 y(disco)o(v)o(er)f(information)g(ab)q(out)i(the)e(Domain)g(Name)f(Space.)
+26 b(This)18 b(information)f(can)g(b)q(e)h(used)149 739 y(for)e(future)f
+(resolutions.)21 b(If)15 b(a)g(name)f(serv)o(er)g(cac)o(hes)h(the)g(data,)h
+(it)e(builds)h(up)h(a)f(data)h(base)g(that)149 829 y(helps)i(sp)q(eed)g(up)g
+(the)f(pro)q(cessing)i(of)f(further)g(querying.)25 b(The)18
+b(next)f(time)f(a)i(resolv)o(er)e(queries)149 919 y(the)21
+b(name)e(serv)o(er)h(for)h(data)g(ab)q(out)h(a)f(domain)f(name)f(the)h(name)g
+(serv)o(er)f(kno)o(ws)i(something)149 1010 y(ab)q(out,)16 b(the)d(pro)q(cess)
+i(is)f(shortened)g(considerably)l(.)20 b(Ev)o(en)13 b(if)g(a)i(name)e(serv)o
+(er)f(do)q(es)j(not)g(ha)o(v)o(e)e(the)149 1100 y(answ)o(er)f(to)f(the)g
+(query)f(in)h(its)f(cac)o(he)h(it)f(migh)o(t)g(ha)o(v)o(e)g(learned)g(the)h
+(iden)o(tities)e(of)i(the)g(authoritativ)o(e)149 1190 y(name)i(serv)o(ers)f
+(for)i(the)f(zone)g(the)g(domain)g(name)f(is)h(in,)h(and)g(it)f(migh)o(t)e(b)
+q(e)j(able)f(to)h(resolv)o(e)e(them)149 1281 y(directly)l(.)223
+1371 y(It)19 b(is)h(di\016cult)f(to)h(determine)d(the)j(optimal)f(time)e(to)k
+(liv)o(e)d(v)m(alue)i(for)g(data)h(that)f(is)g(to)g(b)q(e)149
+1461 y(cac)o(hed.)i(There)16 b(is)h(a)g(trade-o\013)h(b)q(et)o(w)o(een)e
+(enhanced)g(p)q(erformance)f(once)i(data)g(is)g(cac)o(hed)f(and)149
+1551 y(the)g(p)q(ossibilit)o(y)g(that)g(the)g(cac)o(hed)g(data)h(migh)o(t)e
+(b)q(e)h(out)h(of)f(date)h(b)o(y)e(the)h(time)e(it)i(is)g(used.)149
+1711 y(2.7.2)49 b(Role)16 b(of)h(Authorities)223 1834 y(Manageabilit)o(y)f
+(of)h(the)g(administration)f(of)h(the)g(Domain)g(Name)e(Space)i(is)g(an)g
+(imp)q(ortan)o(t)149 1924 y(issue)g(b)q(ecause)g(of)g(the)g(large)f(n)o(um)o
+(b)q(er)f(of)i(hosts)h(in)e(the)h(In)o(ternet.)k(The)c(k)o(ey)f(concept)g(to)
+h(solv)o(e)149 2014 y(this)23 b(problem)f(is)h(the)g(delegation)f(of)i
+(authorit)o(y)f(along)h(the)e(edges)i(of)f(the)g(Domain)f(Name)149
+2105 y(Space)d(tree.)27 b(Lo)q(cal)19 b(authorities)g(administer)d(their)i(o)
+o(wn)h(zones.)28 b(They)18 b(k)o(eep)f(the)i(data)g(base)149
+2195 y(consisten)o(t)12 b(and)g(ha)o(v)o(e)f(autonomous)h(con)o(trol)g(of)g
+(name)e(assignmen)o(ts.)19 b(This)12 b(delegation)g(sc)o(heme)149
+2285 y(tak)o(es)k(a)o(w)o(a)o(y)g(the)g(load)h(from)e(cen)o(tral)g
+(authorities.)223 2376 y(It)e(is)h(imp)q(ortan)o(t)f(to)h(understand)h(that)g
+(the)e(organizational)i(to)q(ol)g(of)f(delegation)g(of)g(author-)149
+2466 y(it)o(y)f(includes)g(the)g(resp)q(onsibilit)o(y)f(for)i(the)f
+(delegated)g(en)o(tit)o(y)l(.)19 b(There)13 b(is)h(no)g(delegation)f(without)
+149 2556 y(resp)q(onsibilit)o(y)l(.)p eop
+%%Page: 24 33
+32 bop 1901 -100 a Fo(24)149 75 y(2.7.3)49 b(Occurrence)15
+b(of)i(Errors)223 197 y(Sev)o(eral)12 b(error)i(situations)g(can)g(o)q(ccur)g
+(during)h(name)d(serv)o(er)h(and)h(resolv)o(er)f(op)q(eration.)21
+b(The)149 287 y(header)13 b(section)g(of)g(ev)o(ery)f(DNS)h(message)f(con)o
+(tains)h(the)g(\014eld)g(\\R)o(CODE,")g(a)h(4)f(bit)g(\014eld)f(that)i(is)149
+378 y(part)h(of)f(a)h(resp)q(onse)g(\(see)f(section)f(2.4.2\).)21
+b(The)14 b(con)o(ten)o(ts)g(of)g(the)g(\\R)o(CODE")h(\014eld)f(determines)149
+468 y(whic)o(h)i(error)g(has)h(o)q(ccurred)f(while)g(pro)q(cessing)h(the)f
+(query:)222 600 y Fj(\017)24 b Fo(if)16 b(a)h(name)e(serv)o(er)g(is)h(unable)
+g(to)h(in)o(terpret)e(a)h(query)l(,)f(it)h(\015ags)h(a)g(\\F)l(ormat)f
+(Error")222 732 y Fj(\017)24 b Fo(if)19 b(a)g(name)f(serv)o(er)g(is)h(unable)
+g(to)h(pro)q(cess)f(a)h(query)e(b)q(ecause)i(of)f(a)h(problem)d(with)i(that)
+271 822 y(serv)o(er,)c(it)h(\015ags)h(a)g(\\Serv)o(er)e(F)l(ailure")222
+954 y Fj(\017)24 b Fo(if)16 b(an)g(authoritativ)o(e)f(name)f(serv)o(er)h(for)
+h(a)g(zone)g(determines)d(that)j(the)f(referenced)g(name)271
+1044 y(do)q(es)i(not)g(exist,)e(a)i(\\Name)e(Error")i(is)f(\015agged.)222
+1176 y Fj(\017)24 b Fo(if)f(a)h(serv)o(er)e(do)q(es)i(not)g(supp)q(ort)g(the)
+f(requested)f(kind)h(of)h(query)l(,)f(it)g(returns)g(a)h(\\Not)271
+1266 y(Impleme)o(n)o(ted")13 b(error)222 1398 y Fj(\017)24
+b Fo(if)17 b(a)h(name)e(serv)o(er)g(do)q(es)i(not)f(w)o(an)o(t)h(to)f(pro)o
+(vide)f(the)h(information)g(a)g(resolv)o(er)f(ask)o(ed)h(for)271
+1488 y(in)j(a)h(query)l(,)f(it)g(returns)g(the)g(\\Refused")h(co)q(de.)33
+b(This)20 b(is)g(one)h(example)d(of)j(the)f(serv)o(er)271 1578
+y(refusing)d(to)f(p)q(erform)f(a)i(sp)q(eci\014ed)f(op)q(eration)h(for)f(p)q
+(olicy)g(reasons)149 1744 y(2.8)50 b(Example:)19 b(Name)c(Resolution)223
+1883 y(This)h(section)h(con)o(tains)f(a)h(simple)e(example)f(for)j(a)g(name)e
+(resolution)i(using)g(a)g(mec)o(hanism)149 1974 y(based)e(on)f(the)f(clien)o
+(t{serv)o(er)e(paradigm.)20 b(A)13 b(generic)g(resolution)g(example)f(is)h
+(sho)o(wn)i(in)e(Figure)149 2064 y(2.6)k(with)f(a)h(short)g(explanation)f(of)
+g(the)g(steps)h(in)f(table)g(2.2.)223 2154 y(A)10 b(resolv)o(er)g(forms)g(a)h
+(query)g(of)g(some)f(kind)g(and)i(w)o(an)o(ts)f(to)g(retriev)o(e)e(the)i
+(resp)q(onse)h(con)o(taining)149 2245 y(the)i(answ)o(er)g(to)g(its)f(query)g
+(from)f(the)i(name)e(serv)o(er)h(A.)f(This)i(name)e(serv)o(er)h(A)g(could)g
+(b)q(e)h(running)149 2335 y(on)21 b(the)f(same)f(host)i(with)e(the)h(resolv)o
+(er)f(soft)o(w)o(are,)i(on)f(a)h(host)f(in)g(the)g(lo)q(cal)g(net)o(w)o(ork)f
+(of)i(the)149 2425 y(resolv)o(er,)h(on)g(a)g(host)g(somewhere)e(in)h(the)h
+(net,)g(or)g(on)g(one)f(of)h(the)f(hosts)i(serving)e(the)g(ro)q(ot)149
+2515 y(domains.)42 b(Assuming)22 b(that)i(A)f(do)q(es)h(not)g(kno)o(w)f(the)g
+(requested)g(information,)h(it)e(tries)h(to)149 2606 y(retriev)o(e)16
+b(it)i(from)e(other)i(name)f(serv)o(ers.)25 b(The)18 b(selection)f(of)h(whic)
+o(h)f(name)f(serv)o(ers)h(to)i(con)o(tact)p eop
+%%Page: 25 34
+33 bop 1901 -100 a Fo(25)374 1345 y @beginspecial 0 @llx 0
+@lly 309 @urx 294 @ury 3090 @rwi @setspecial
+%%BeginDocument: pictures/res_expl.ps
+/$F2psDict 200 dict def 
+$F2psDict begin
+$F2psDict /mtrx matrix put
+/l {lineto} bind def
+/m {moveto} bind def
+/s {stroke} bind def
+/n {newpath} bind def
+/gs {gsave} bind def
+/gr {grestore} bind def
+/clp {closepath} bind def
+/graycol {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
+4 -2 roll mul setrgbcolor} bind def
+/col-1 {} def
+/col0 {0 0 0 setrgbcolor} bind def
+/col1 {0 0 1 setrgbcolor} bind def
+/col2 {0 1 0 setrgbcolor} bind def
+/col3 {0 1 1 setrgbcolor} bind def
+/col4 {1 0 0 setrgbcolor} bind def
+/col5 {1 0 1 setrgbcolor} bind def
+/col6 {1 1 0 setrgbcolor} bind def
+/col7 {1 1 1 setrgbcolor} bind def
+ /DrawEllipse {
+	/endangle exch def
+	/startangle exch def
+	/yrad exch def
+	/xrad exch def
+	/y exch def
+	/x exch def
+	/savematrix mtrx currentmatrix def
+	x y translate xrad yrad scale 0 0 1 startangle endangle arc
+	savematrix setmatrix
+	} def
+
+	end
+/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
+/$F2psEnd {$F2psEnteredState restore end} def
+
+$F2psBegin
+0 setlinecap 0 setlinejoin
+-7.0 301.0 translate 0.900 -0.900 scale
+1.000 setlinewidth
+n 253.000 163.000 m 249.000 179.000 l 245.000 163.000 l gs 2 setlinejoin col-1 s gr
+	[6.000000] 0 setdash
+n 179.000 179.000 70.000 180.000 0.000 arc
+gs col-1 s gr
+	[] 0 setdash
+n 39 179 32 32 0 360 DrawEllipse gs col-1 s gr
+n 179 39 32 32 0 360 DrawEllipse gs col-1 s gr
+n 179 179 32 32 0 360 DrawEllipse gs col-1 s gr
+n 319 179 32 32 0 360 DrawEllipse gs col-1 s gr
+n 149 184 m 69 184 l gs col-1 s gr
+n 85.000 188.000 m 69.000 184.000 l 85.000 180.000 l gs 2 setlinejoin col-1 s gr
+n 69 174 m 149 174 l gs col-1 s gr
+n 133.000 170.000 m 149.000 174.000 l 133.000 178.000 l gs 2 setlinejoin col-1 s gr
+n 209 174 m 289 174 l gs col-1 s gr
+n 273.000 170.000 m 289.000 174.000 l 273.000 178.000 l gs 2 setlinejoin col-1 s gr
+n 289 184 m 209 184 l gs col-1 s gr
+n 225.000 188.000 m 209.000 184.000 l 225.000 180.000 l gs 2 setlinejoin col-1 s gr
+n 174 284 m 174 209 l gs col-1 s gr
+n 170.000 225.000 m 174.000 209.000 l 178.000 225.000 l gs 2 setlinejoin col-1 s gr
+n 184 209 m 184 284 l gs col-1 s gr
+n 188.000 268.000 m 184.000 284.000 l 180.000 268.000 l gs 2 setlinejoin col-1 s gr
+n 174 149 m 174 69 l gs col-1 s gr
+n 170.000 85.000 m 174.000 69.000 l 178.000 85.000 l gs 2 setlinejoin col-1 s gr
+n 184 69 m 184 149 l gs col-1 s gr
+n 188.000 133.000 m 184.000 149.000 l 180.000 133.000 l gs 2 setlinejoin col-1 s gr
+n 146 284 m 139 284 139 327 7 arcto 4 {pop} repeat 139 334 212 334 7 arcto 4 {pop} repeat 219 334 219 291 7 arcto 4 {pop} repeat 219 284 146 284 7 arcto 4 {pop} repeat clp gs col-1 s gr
+/Times-Bold findfont 12.00 scalefont setfont
+174 169 m 
+gs 1 -1 scale (A) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+174 29 m 
+gs 1 -1 scale (C) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+314 169 m 
+gs 1 -1 scale (D) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+34 169 m 
+gs 1 -1 scale (B) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+24 199 m 
+gs 1 -1 scale (server) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+24 184 m 
+gs 1 -1 scale (name) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+164 199 m 
+gs 1 -1 scale (server) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+164 184 m 
+gs 1 -1 scale (name) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+304 199 m 
+gs 1 -1 scale (server) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+304 184 m 
+gs 1 -1 scale (name) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+164 59 m 
+gs 1 -1 scale (server) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+164 44 m 
+gs 1 -1 scale (name) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+154 314 m 
+gs 1 -1 scale (resolver) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+139 249 m 
+gs 1 -1 scale (query) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+189 249 m 
+gs 1 -1 scale (answer) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+89 169 m 
+gs 1 -1 scale (referral) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+144 104 m 
+gs 1 -1 scale (query) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+214 169 m 
+gs 1 -1 scale (query) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+189 104 m 
+gs 1 -1 scale (referral) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+99 199 m 
+gs 1 -1 scale (query) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+229 199 m 
+gs 1 -1 scale (answer) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+79 199 m 
+gs 1 -1 scale (2) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+134 169 m 
+gs 1 -1 scale (3) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+159 84 m 
+gs 1 -1 scale (4) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+274 169 m 
+gs 1 -1 scale (6) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+194 279 m 
+gs 1 -1 scale (8) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+194 144 m 
+gs 1 -1 scale (5) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+219 199 m 
+gs 1 -1 scale (7) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+159 224 m 
+gs 1 -1 scale (1) col-1 show gr
+$F2psEnd
+%%EndDocument
+ @endspecial 654 1590 a(Figure)16 b(2.6)33 b(Example)15 b(name)g(resolution)
+149 1774 y(dep)q(ends)i(on)g(the)f(name)g(to)g(b)q(e)h(resolv)o(ed.)k(The)16
+b(decision)g(pro)q(cess)h(ab)q(out)h(this)e(c)o(hoice)f(is)h(giv)o(en)149
+1864 y(in)f(sections)f(2.9.2)h(and)g(2.9.3)g(where)g(w)o(e)f(explain)f(the)i
+(algorithms)f(used)g(b)o(y)h(name)e(serv)o(ers)h(and)149 1954
+y(resolv)o(ers.)223 2045 y(The)f(con)o(tacted)g(name)g(serv)o(ers)g(return)g
+(an)h(answ)o(er)g(to)g(the)f(query)g(to)h(the)g(requesting)f(name)149
+2135 y(serv)o(er,)f(or)i(they)e(return)h(a)g(referral)f(to)h(another)h(name)e
+(serv)o(er)f(that)j(is)e(more)g(lik)o(ely)e(to)k(kno)o(w)f(the)149
+2225 y(answ)o(er.)27 b(W)l(e)17 b(neither)g(consider)h(the)f(o)q(ccurrence)g
+(of)i(exceptions)e(or)h(errors)g(in)f(this)h(example,)149 2316
+y(nor)g(cac)o(hing)f(issues.)26 b(P)o(ossible)17 b(return)g(co)q(des)h(in)f
+(resp)q(onses)i(are)e(giv)o(en)g(in)g(section)g(2.4.2)h(and)149
+2406 y(are)f(further)f(explained)f(in)h(section)g(2.7.3.)223
+2496 y(As)e(so)q(on)j(as)e(one)g(of)g(the)g(con)o(tacted)f(name)g(serv)o(ers)
+g(returns)h(an)g(answ)o(er)h(to)f(A,)f(A)g(resp)q(onds)149
+2586 y(to)j(the)f(original)g(query)g(of)g(the)g(resolv)o(er)f(with)h(the)g
+(retriev)o(ed)f(answ)o(er.)p eop
+%%Page: 26 35
+34 bop 1901 -100 a Fo(26)574 101 y(T)l(able)17 b(2.2)32 b(Example)15
+b(steps)h(in)g(name)f(resolution)452 232 y(Step)p 571 259 2
+91 v 49 w(Action)p 427 261 1246 2 v 452 324 a(1)p 571 351 2
+91 v 120 w(Name)g(serv)o(er)g(A)h(receiv)o(es)e(a)j(query)e(from)g(the)h
+(resolv)o(er)452 414 y(2)p 571 441 V 120 w(A)g(queries)f(B)452
+505 y(3)p 571 532 V 120 w(B)h(refers)g(A)g(to)g(other)h(name)e(serv)o(ers,)g
+(incl.)20 b(C)452 595 y(4)p 571 622 V 120 w(A)c(queries)f(C)452
+685 y(5)p 571 712 V 120 w(C)i(refers)f(A)f(to)i(other)f(name)f(serv)o(ers,)g
+(incl.)20 b(D)452 775 y(6)p 571 802 V 120 w(A)c(queries)f(D)452
+866 y(7)p 571 893 V 120 w(D)i(answ)o(ers)452 956 y(8)p 571
+983 V 120 w(D)g(returns)f(the)g(answ)o(er)h(to)f(the)g(resolv)o(er)149
+1211 y(2.9)50 b(The)16 b(Domain)f(Name)g(System)g(Proto)q(col)223
+1351 y(The)f(o\016cial)f(design)h(do)q(cumen)o(ts)f([Mo)q(c87a)q(])h(and)h
+([Mo)q(c87b])f(state)g(and)h(describ)q(e)f(concepts)149 1441
+y(and)23 b(facilities,)d(implem)o(en)o(tati)o(on)g(and)i(sp)q(eci\014cation.)
+36 b(In)22 b(the)f(follo)o(wing)g(sections,)h(w)o(e)g(will)149
+1532 y(discuss)c(topics)g(related)f(to)h(the)g(data)h(structures)e(and)i
+(data)f(organization,)h(and)g(presen)o(t)e(the)149 1622 y(name)c(serv)o(er)g
+(and)i(the)f(resolv)o(er)f(algorithm)g(on)h(a)h(fairly)e(high)h(lev)o(el.)19
+b(W)l(e)14 b(get)g(in)o(to)f(more)g(detail)149 1712 y(where)j(it)g(is)g
+(necessary)g(to)h(examine)d(the)i(w)o(eak)g(p)q(oin)o(ts)g(of)h(the)f(proto)q
+(col.)223 1802 y(The)11 b(data)g(structures)g(and)h(the)e(algorithms)h(are)g
+(the)f(basis)i(for)f(the)g(analysis)g(of)g(the)g(proto)q(col)149
+1893 y(later)16 b(in)g(this)g(thesis.)149 2053 y(2.9.1)49 b(Data)18
+b(Structures)223 2175 y(Tw)o(o)f(principal)e(kinds)h(of)h(data)g(app)q(ear)h
+(in)e(the)g(Domain)g(Name)f(System:)20 b(zone)d(data)g(and)149
+2265 y(cac)o(he)f(data.)223 2356 y(A)11 b(zone)i(con)o(tains)f(a)h(complete)d
+(database)j(for)g(a)f(particular)g(pruned)h(subtree)f(of)g(the)g(domain)149
+2446 y(name)19 b(space.)32 b(This)20 b(data)h(can)f(b)q(e)g(authoritativ)o(e)
+f(if)g(it)h(is)f(the)h(original)g(database)h(managed)149 2536
+y(for)16 b(this)g(particular)f(zone)h(b)o(y)f(a)h(primary)e(or)i(secondary)g
+(name)f(serv)o(er.)20 b(Otherwise)15 b(it)g(is)g(non{)149 2627
+y(authoritativ)o(e)i(data.)24 b(Secondary)17 b(serv)o(ers)f(main)o(tain)f
+(zone)i(data)h(as)f(copies)g(from)f(the)h(master)p eop
+%%Page: 27 36
+35 bop 1901 -100 a Fo(27)149 75 y(\014les.)21 b(Name)13 b(serv)o(ers)g(c)o
+(hec)o(k)g(p)q(erio)q(dically)h(for)h(c)o(hanges)g(\(for)g(a)g(c)o(hanged)f
+(serial)g(n)o(um)o(b)q(er)f(in)i(the)149 165 y(SO)o(A)h(records\))g(and)h(up)
+q(date)f(their)g(data)h(b)o(y)e(reading)i(the)f(master)f(\014les,)g(or)h(via)
+g(zone)g(transfer)149 255 y(op)q(erations.)223 346 y(As)f(w)o(e)g(will)f
+(describ)q(e)h(in)g(Section)g(2.3.2,)h(the)f(tec)o(hnology)g(of)h(cac)o(hing)
+f(is)g(a)h(k)o(ey)f(concept)g(in)149 436 y(the)k(Domain)f(Name)f(System.)27
+b(The)19 b(cac)o(hed)f(data)i(usually)e(represen)o(ts)g(only)h(an)g
+(incomplete)149 526 y(view)d(of)h(zone)g(information.)k(It)16
+b(impro)o(v)o(es)e(the)j(p)q(erformance)e(of)i(the)g(retriev)m(al)e(pro)q
+(cess)i(when)149 616 y(non{lo)q(cal)e(data)f(is)f(rep)q(eatedly)g(accessed.)
+20 b(Zone)13 b(data)i(is)e(ev)o(en)o(tually)e(discarded)i(b)o(y)g(a)h
+(timeout)149 707 y(mec)o(hanism.)223 797 y(The)h(implem)o(en)n(tation)e(of)j
+(the)f(Domain)f(Name)g(System)g(is)h(not)g(limited)e(to)i(a)h(certain)f(data)
+149 887 y(structure,)i(but)g(is)f(free)g(to)h(c)o(ho)q(ose)h(an)o(y)e(in)o
+(ternal)g(data)i(structure.)k(Ho)o(w)o(ev)o(er,)15 b(it)h(is)h(suggested)149
+978 y(b)o(y)e(the)g(standard)i(that)f(a)f(separate)h(instance)f(of)h(the)f
+(data)h(structure)f(b)q(e)g(used)h(for)f(eac)o(h)g(zone,)149
+1068 y(a)20 b(data)g(structure)e(for)h(the)g(catalog,)h(and)f(one)h(for)f
+(the)f(cac)o(hed)h(data.)30 b(It)18 b(is)h(imp)q(ortan)o(t)f(that)149
+1158 y(resolv)o(er)g(and)h(name)f(serv)o(er)f(can)i(concurren)o(tly)f(access)
+g(the)h(same)e(cac)o(he)h(when)h(they)f(are)h(on)149 1248 y(the)d(same)g(mac)
+o(hine.)j(In)d(Section)f(2.10.1)i(w)o(e)f(go)h(in)o(to)f(more)f(detail)g(on)i
+(this)f(p)q(oin)o(t.)149 1408 y(2.9.2)49 b(Name)15 b(Serv)o(er)g(Algorithm)
+223 1531 y(The)k(impleme)o(n)o(tation)e(of)j(the)g(name)e(serv)o(er)h
+(algorithm,)g(whic)o(h)g(is)h(giv)o(en)e(in)i(Figure)f(2.7)149
+1621 y(dep)q(ends)g(on)g(the)f(lo)q(cal)g(op)q(erating)h(system)e(and)i(data)
+g(structures)f(used)g(to)h(store)f(RRs.)27 b(The)149 1711 y(algorithms)14
+b(of)i(the)e(name)g(serv)o(er)g(and)h(the)g(resolv)o(er)e(assume)h(an)i
+(organization)f(of)h(the)e(data)i(as)149 1802 y(describ)q(ed)g(in)g(the)g
+(previous)g(section:)21 b(sev)o(eral)15 b(tree)h(structures,)f(one)i(for)f
+(eac)o(h)g(zone.)223 1892 y(In)c(the)h(follo)o(wing)g(presen)o(tation)f(of)i
+(the)f(algorithm)e(w)o(e)i(sta)o(y)g(close)g(to)g(the)g(outline)f(sp)q
+(eci\014ed)149 1982 y(in)k([Mo)q(c87a)q(].)209 2127 y(1.)24
+b(Set)13 b(or)h(clear)e(the)h(RA)g(bit)g(in)g(the)g(resp)q(onse)h(dep)q
+(ending)f(on)h(whether)f(the)g(name)f(serv)o(er)g(is)271 2217
+y(willing)f(to)g(pro)o(vide)g(recursiv)o(e)e(service.)18 b(If)11
+b(recursiv)o(e)f(service)g(is)h(a)o(v)m(ailable)f(and)i(requested)271
+2307 y(via)k(the)g(RD)h(bit)f(in)f(the)h(query)l(,)f(branc)o(h)i(to)f(step)h
+(5,)f(otherwise)g(step)g(2.)209 2439 y(2.)24 b(Searc)o(h)e(the)g(a)o(v)m
+(ailable)f(zones)i(for)f(the)g(zone)g(whic)o(h)g(is)f(the)h(nearest)h
+(ancestor)f(to)h(the)271 2529 y(queried)15 b(name.)20 b(If)c(suc)o(h)g(a)h
+(zone)f(is)g(found,)g(branc)o(h)h(to)f(step)h(3,)f(otherwise)g(step)g(4.)p
+eop
+%%Page: 28 37
+36 bop 1901 -100 a Fo(28)187 2020 y @beginspecial 0 @llx 0
+@lly 378 @urx 436 @ury 3780 @rwi @setspecial
+%%BeginDocument: pictures/ns_alg.ps
+/$F2psDict 200 dict def 
+$F2psDict begin
+$F2psDict /mtrx matrix put
+/l {lineto} bind def
+/m {moveto} bind def
+/s {stroke} bind def
+/n {newpath} bind def
+/gs {gsave} bind def
+/gr {grestore} bind def
+/clp {closepath} bind def
+/graycol {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
+4 -2 roll mul setrgbcolor} bind def
+/col-1 {} def
+/col0 {0 0 0 setrgbcolor} bind def
+/col1 {0 0 1 setrgbcolor} bind def
+/col2 {0 1 0 setrgbcolor} bind def
+/col3 {0 1 1 setrgbcolor} bind def
+/col4 {1 0 0 setrgbcolor} bind def
+/col5 {1 0 1 setrgbcolor} bind def
+/col6 {1 1 0 setrgbcolor} bind def
+/col7 {1 1 1 setrgbcolor} bind def
+	end
+/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
+/$F2psEnd {$F2psEnteredState restore end} def
+
+$F2psBegin
+0 setlinecap 0 setlinejoin
+-18.0 454.0 translate 0.900 -0.900 scale
+0.500 setlinewidth
+n 194 149 m 209 149 l gs col-1 s gr
+n 201.000 147.000 m 209.000 149.000 l 201.000 151.000 l gs 2 setlinejoin col-1 s gr
+1.000 setlinewidth
+n 19 39 m 379 39 l gs col-1 s gr
+n 19 79 m 379 79 l gs col-1 s gr
+n 19 119 m 379 119 l gs col-1 s gr
+n 39 359 m 39 139 l  379 139 l gs col-1 s gr
+n 39 199 m 379 199 l gs col-1 s gr
+n 39 259 m 379 259 l gs col-1 s gr
+n 19 359 m 379 359 l gs col-1 s gr
+n 19 419 m 379 419 l gs col-1 s gr
+n 19 459 m 379 459 l gs col-1 s gr
+n 19 504 m 19 19 l  379 19 l  379 504 l  19 504 l gs col-1 s gr
+n 19 499 m 379 499 l gs col-1 s gr
+0.500 setlinewidth
+n 369 169 m 399 169 l  399 44 l  379 44 l gs col-1 s gr
+n 387.000 46.000 m 379.000 44.000 l 387.000 42.000 l gs 2 setlinejoin col-1 s gr
+n 289 69 m 419 69 l  419 424 l  379 424 l gs col-1 s gr
+n 387.000 426.000 m 379.000 424.000 l 387.000 422.000 l gs 2 setlinejoin col-1 s gr
+n 24 34 m 24 44 l gs col-1 s gr
+n 26.000 36.000 m 24.000 44.000 l 22.000 36.000 l gs 2 setlinejoin col-1 s gr
+n 24 74 m 24 84 l gs col-1 s gr
+n 26.000 76.000 m 24.000 84.000 l 22.000 76.000 l gs 2 setlinejoin col-1 s gr
+n 24 114 m 24 124 l gs col-1 s gr
+n 26.000 116.000 m 24.000 124.000 l 22.000 116.000 l gs 2 setlinejoin col-1 s gr
+n 24 354 m 24 364 l gs col-1 s gr
+n 26.000 356.000 m 24.000 364.000 l 22.000 356.000 l gs 2 setlinejoin col-1 s gr
+n 24 454 m 24 464 l gs col-1 s gr
+n 26.000 456.000 m 24.000 464.000 l 22.000 456.000 l gs 2 setlinejoin col-1 s gr
+n 179 109 m 439 109 l  439 364 l  379 364 l gs col-1 s gr
+n 387.000 366.000 m 379.000 364.000 l 387.000 362.000 l gs 2 setlinejoin col-1 s gr
+n 349 189 m 399 189 l  399 464 l  379 464 l gs col-1 s gr
+n 387.000 466.000 m 379.000 464.000 l 387.000 462.000 l gs 2 setlinejoin col-1 s gr
+n 264 249 m 439 249 l gs col-1 s gr
+n 431.000 247.000 m 439.000 249.000 l 431.000 251.000 l gs 2 setlinejoin col-1 s gr
+n 209 349 m 399 349 l gs col-1 s gr
+n 391.000 347.000 m 399.000 349.000 l 391.000 351.000 l gs 2 setlinejoin col-1 s gr
+n 309 409 m 399 409 l gs col-1 s gr
+n 391.000 407.000 m 399.000 409.000 l 391.000 411.000 l gs 2 setlinejoin col-1 s gr
+n 259 209 m 274 209 l gs col-1 s gr
+n 266.000 207.000 m 274.000 209.000 l 266.000 211.000 l gs 2 setlinejoin col-1 s gr
+/Times-Roman findfont 12.00 scalefont setfont
+24 54 m 
+gs 1 -1 scale (1.\)) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+39 54 m 
+gs 1 -1 scale (set or clear recursion available flag) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+39 74 m 
+gs 1 -1 scale (If recursive service available and requested, then ) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+24 94 m 
+gs 1 -1 scale (2.\)) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+39 114 m 
+gs 1 -1 scale (If no such zone found, then) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+24 134 m 
+gs 1 -1 scale (3.\)) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+39 134 m 
+gs 1 -1 scale (match down, label by label, in the zone. Termination of process:) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+54 154 m 
+gs 1 -1 scale (whole QNAME is matched) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+214 154 m 
+gs 1 -1 scale (node is found.) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+54 174 m 
+gs 1 -1 scale (If data in node is CNAME \(!= QTYPE\), expand QNAME and) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+54 214 m 
+gs 1 -1 scale (match takes us out of authoritative data ) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+279 214 m 
+gs 1 -1 scale (referral) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+54 234 m 
+gs 1 -1 scale (copy RR of NS-record in authority section, and put available ) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+54 274 m 
+gs 1 -1 scale (match is impossible. look for wildcard "*". If no "*" exists) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+64 294 m 
+gs 1 -1 scale (then: If name is original QNAME, set authoritative name error) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+79 314 m 
+gs 1 -1 scale (in the response and exit, otherwise just exit.) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+64 334 m 
+gs 1 -1 scale (else: match RRs at that node against QTYPE, copy matches) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+79 354 m 
+gs 1 -1 scale (into answer section and) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+24 374 m 
+gs 1 -1 scale (4.\)) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+39 374 m 
+gs 1 -1 scale (match down in the cache. If CNAME is found, copy all RRs into) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+39 394 m 
+gs 1 -1 scale (answer section.  If there was no delegation from auth. data, put) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+39 414 m 
+gs 1 -1 scale (best one from the cache into the authoritative section.) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+24 434 m 
+gs 1 -1 scale (5.\)) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+39 434 m 
+gs 1 -1 scale (use local resolver, or copy of the algorithm to answer query.) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+39 454 m 
+gs 1 -1 scale (Store the results \(incl. interm. CNAMEs\) in the answer section.) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+24 474 m 
+gs 1 -1 scale (6.\)) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+39 474 m 
+gs 1 -1 scale (use local data only, attempt to add other RRs which may be useful) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+39 494 m 
+gs 1 -1 scale (to the additional section of the query. Exit.) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+369 164 m 
+gs 1 -1 scale (1) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+294 64 m 
+gs 1 -1 scale (5) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+184 104 m 
+gs 1 -1 scale (4) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+269 244 m 
+gs 1 -1 scale (4) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+354 184 m 
+gs 1 -1 scale (6) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+314 404 m 
+gs 1 -1 scale (6) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+39 154 m 
+gs 1 -1 scale ( a\)) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+39 214 m 
+gs 1 -1 scale ( b\)) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+39 274 m 
+gs 1 -1 scale ( c\)) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+24 34 m 
+gs 1 -1 scale (0.\)) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+39 34 m 
+gs 1 -1 scale (incoming query) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+39 94 m 
+gs 1 -1 scale (search available zones for zone that is nearest answer to QNAME) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+54 194 m 
+gs 1 -1 scale (copy all RRs that match QTYPE into answer section and) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+214 344 m 
+gs 1 -1 scale (6) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+54 254 m 
+gs 1 -1 scale (addresses in the additional section, and) col-1 show gr
+$F2psEnd
+%%EndDocument
+ @endspecial 682 2265 a(Figure)16 b(2.7)32 b(Name)15 b(serv)o(er)g(algorithm)
+209 2449 y(3.)24 b(Start)16 b(matc)o(hing)d(the)h(name)g(in)h(the)f(zone,)h
+(lab)q(el)f(b)o(y)g(lab)q(el.)21 b(The)15 b(matc)o(hing)e(pro)q(cess)i(can)
+271 2539 y(terminate)g(sev)o(eral)g(w)o(a)o(ys:)p eop
+%%Page: 29 38
+37 bop 1901 -100 a Fo(29)292 75 y(\(a\))25 b(If)15 b(the)h(whole)h(queried)e
+(name)g(is)h(matc)o(hed,)e(w)o(e)i(ha)o(v)o(e)f(found)i(the)f(no)q(de.)379
+186 y(If)21 b(the)h(data)g(at)h(the)e(no)q(de)i(is)e(a)i(canonical)e(name,)h
+(and)g(the)g(queried)f(t)o(yp)q(e)g(w)o(as)379 277 y(not)f(CNAME,)f(cop)o(y)h
+(the)g(canonical)g(name)f(resource)h(records)g(in)o(to)g(the)g(answ)o(er)379
+367 y(section)14 b(of)h(the)g(resp)q(onse,)g(c)o(hange)g(the)f(queried)g
+(name)f(to)i(the)g(canonical)f(name)g(in)379 457 y(the)i(CNAME)f(RR)h(and)h
+(go)g(bac)o(k)f(to)h(step)f(1.)379 569 y(Otherwise)e(cop)o(y)g(all)g
+(resource)g(records)g(whic)o(h)g(matc)o(h)f(the)h(queried)g(t)o(yp)q(e)g(in)o
+(to)g(the)379 659 y(answ)o(er)i(section)g(and)h(go)g(to)g(step)f(6.)289
+770 y(\(b\))25 b(If)15 b(a)g(matc)o(h)f(w)o(ould)i(tak)o(e)e(us)i(out)g(of)g
+(the)f(authoritativ)o(e)g(data,)g(w)o(e)g(ha)o(v)o(e)g(a)h(referral.)379
+861 y(This)d(happ)q(ens)h(when)e(w)o(e)h(encoun)o(ter)f(a)h(no)q(de)h(with)e
+(name)g(serv)o(er)g(resource)g(records)379 951 y(marking)j(cuts)h(along)h
+(the)f(b)q(ottom)g(of)h(a)f(zone.)379 1063 y(Cop)o(y)h(the)f(name)g(serv)o
+(er)g(resource)g(records)h(for)g(the)g(subzone)g(in)o(to)f(the)h(authorit)o
+(y)379 1153 y(section)h(of)i(the)f(reply)l(.)29 b(Put)19 b(whatev)o(er)g
+(addresses)h(are)f(a)o(v)m(ailable)f(in)o(to)h(the)g(addi-)379
+1243 y(tional)13 b(section,)h(using)g(glue)f(resource)g(records)h(if)f(the)g
+(addresses)h(are)g(not)g(a)o(v)m(ailable)379 1334 y(from)h(authoritativ)o(e)g
+(data)j(or)e(the)g(cac)o(he.)21 b(Go)c(to)f(step)g(4.)295 1445
+y(\(c\))24 b(If)15 b(at)i(some)e(lab)q(el,)h(a)g(matc)o(h)f(is)h(imp)q
+(ossible,)e(lo)q(ok)j(to)g(see)e(if)h(a)h(\\)p Fq(\003)p Fo(")g(lab)q(el)f
+(exists.)379 1556 y(If)e(the)h(\\)p Fq(\003)p Fo(")h(lab)q(el)f(do)q(es)h
+(not)f(exist,)g(c)o(hec)o(k)e(whether)i(the)g(name)f(w)o(e)g(are)i(lo)q
+(oking)f(for)379 1647 y(is)i(the)h(original)g(name)e(in)i(the)g(query)l(,)e
+(or)j(a)f(name)f(w)o(e)g(ha)o(v)o(e)g(follo)o(w)o(ed)g(b)q(ecause)h(of)379
+1737 y(a)e(CNAME.)g(If)g(the)g(name)f(is)h(original,)g(set)g(an)h
+(authoritativ)o(e)f(name)f(error)i(in)f(the)379 1827 y(resp)q(onse)h(and)g
+(exit.)j(Otherwise)15 b(just)i(exit.)379 1939 y(If)i(the)h(\\)p
+Fq(\003)p Fo(")g(lab)q(el)g(do)q(es)h(exist,)e(matc)o(h)g(resource)g(records)
+h(at)h(that)f(no)q(de)g(against)379 2029 y(the)f(queried)g(t)o(yp)q(e.)31
+b(If)20 b(an)o(y)f(matc)o(h,)g(cop)o(y)g(them)f(in)o(to)i(the)f(answ)o(er)h
+(section,)g(but)379 2119 y(set)d(the)g(o)o(wner)g(of)h(the)f(resource)g
+(record)g(to)h(b)q(e)f(the)g(queried)f(name,)g(and)i(not)g(the)379
+2210 y(no)q(de)f(with)f(the)g(\\)p Fq(\003)p Fo(")h(lab)q(el.)j(Go)d(to)g
+(step)f(6.)209 2342 y(4.)24 b(Start)e(matc)o(hing)f(do)o(wn)h(in)f(the)h(cac)
+o(he.)36 b(If)22 b(the)f(name)g(is)g(found)h(in)g(the)f(cac)o(he,)h(cop)o(y)
+271 2432 y(all)d(resource)f(records)h(attac)o(hed)g(to)g(it)g(that)g(matc)o
+(h)e(the)i(query)f(t)o(yp)q(e)g(in)o(to)h(the)f(answ)o(er)271
+2522 y(section.)30 b(If)19 b(there)g(w)o(as)h(no)f(delegation)g(from)g
+(authoritativ)o(e)f(data,)j(lo)q(ok)f(for)f(the)g(b)q(est)271
+2612 y(one)d(from)e(the)g(cac)o(he,)g(and)i(put)f(it)g(in)o(to)g(the)g
+(authoritativ)o(e)f(section.)20 b(Branc)o(h)15 b(to)g(step)h(6.)p
+eop
+%%Page: 30 39
+38 bop 1901 -100 a Fo(30)209 75 y(5.)24 b(Use)16 b(the)g(lo)q(cal)f(resolv)o
+(er)g(or)h(a)h(cop)o(y)e(of)i(its)e(algorithm)g(to)h(answ)o(er)h(the)e(query)
+l(.)21 b(Store)16 b(the)271 165 y(results,)21 b(including)e(an)o(y)h(in)o
+(termediate)d(canonical)j(names,)g(in)g(the)g(answ)o(er)g(section)g(of)271
+255 y(the)c(resp)q(onse.)209 387 y(6.)24 b(Use)15 b(lo)q(cal)f(data)i(only)l
+(,)e(attempt)f(to)i(add)g(other)g(resource)f(records)h(whic)o(h)f(ma)o(y)f(b)
+q(e)i(useful)271 477 y(to)i(the)f(additional)g(section)g(of)h(the)f(query)l
+(.)k(Exit.)149 637 y(2.9.3)49 b(Resolv)o(er)16 b(Algorithm)187
+1974 y @beginspecial 0 @llx 0 @lly 378 @urx 238 @ury 3780 @rwi
+@setspecial
+%%BeginDocument: pictures/res_alg.ps
+/$F2psDict 200 dict def 
+$F2psDict begin
+$F2psDict /mtrx matrix put
+/l {lineto} bind def
+/m {moveto} bind def
+/s {stroke} bind def
+/n {newpath} bind def
+/gs {gsave} bind def
+/gr {grestore} bind def
+/clp {closepath} bind def
+/graycol {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
+4 -2 roll mul setrgbcolor} bind def
+/col-1 {} def
+/col0 {0 0 0 setrgbcolor} bind def
+/col1 {0 0 1 setrgbcolor} bind def
+/col2 {0 1 0 setrgbcolor} bind def
+/col3 {0 1 1 setrgbcolor} bind def
+/col4 {1 0 0 setrgbcolor} bind def
+/col5 {1 0 1 setrgbcolor} bind def
+/col6 {1 1 0 setrgbcolor} bind def
+/col7 {1 1 1 setrgbcolor} bind def
+	end
+/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
+/$F2psEnd {$F2psEnteredState restore end} def
+
+$F2psBegin
+0 setlinecap 0 setlinejoin
+-18.0 256.0 translate 0.900 -0.900 scale
+1.000 setlinewidth
+n 19 279 m 379 279 l gs col-1 s gr
+n 39 199 m 379 199 l gs col-1 s gr
+n 39 239 m 379 239 l gs col-1 s gr
+n 39 159 m 379 159 l gs col-1 s gr
+n 39 119 m 379 119 l gs col-1 s gr
+n 19 99 m 379 99 l gs col-1 s gr
+n 19 79 m 379 79 l gs col-1 s gr
+n 19 59 m 379 59 l gs col-1 s gr
+n 19 39 m 379 39 l gs col-1 s gr
+n 19 19 m 19 284 l  379 284 l  379 19 l  19 19 l gs col-1 s gr
+n 39 119 m 39 279 l gs col-1 s gr
+0.500 setlinewidth
+n 189 149 m 399 149 l  399 64 l  379 64 l gs col-1 s gr
+n 387.000 66.000 m 379.000 64.000 l 387.000 62.000 l gs 2 setlinejoin col-1 s gr
+n 329 229 m 419 229 l  419 44 l  379 44 l gs col-1 s gr
+n 387.000 46.000 m 379.000 44.000 l 387.000 42.000 l gs 2 setlinejoin col-1 s gr
+n 229 269 m 439 269 l  439 84 l  379 84 l gs col-1 s gr
+n 387.000 86.000 m 379.000 84.000 l 387.000 82.000 l gs 2 setlinejoin col-1 s gr
+n 24 34 m 24 44 l gs col-1 s gr
+n 26.000 36.000 m 24.000 44.000 l 22.000 36.000 l gs 2 setlinejoin col-1 s gr
+n 24 54 m 24 64 l gs col-1 s gr
+n 26.000 56.000 m 24.000 64.000 l 22.000 56.000 l gs 2 setlinejoin col-1 s gr
+n 24 74 m 24 84 l gs col-1 s gr
+n 26.000 76.000 m 24.000 84.000 l 22.000 76.000 l gs 2 setlinejoin col-1 s gr
+n 24 94 m 24 104 l gs col-1 s gr
+n 26.000 96.000 m 24.000 104.000 l 22.000 96.000 l gs 2 setlinejoin col-1 s gr
+/Times-Roman findfont 12.00 scalefont setfont
+24 34 m 
+gs 1 -1 scale (0.\)) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+24 54 m 
+gs 1 -1 scale (1.\)) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+39 54 m 
+gs 1 -1 scale (If the answer is in the local information, return it to the client) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+24 74 m 
+gs 1 -1 scale (2.\)) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+24 94 m 
+gs 1 -1 scale (3.\)) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+39 94 m 
+gs 1 -1 scale (Send them queries until one returns a response.) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+24 114 m 
+gs 1 -1 scale (4.\)) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+39 114 m 
+gs 1 -1 scale (Analyze the response:) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+54 134 m 
+gs 1 -1 scale (if the response contains an answer or a name error, cache it) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+54 154 m 
+gs 1 -1 scale (and return it to the client.) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+54 174 m 
+gs 1 -1 scale (if the response contains a better delegation to other servers,) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+54 194 m 
+gs 1 -1 scale (cache the delegation, and) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+54 214 m 
+gs 1 -1 scale (if the response shows a CNAME and that is not the answer ) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+54 234 m 
+gs 1 -1 scale (itself, cache it, change SNAME to canonical name and ) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+54 254 m 
+gs 1 -1 scale (if the response shows a servers failure or bizarre results,) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+54 274 m 
+gs 1 -1 scale (delete the server from SLIST and) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+334 224 m 
+gs 1 -1 scale (1) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+194 144 m 
+gs 1 -1 scale (2) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+234 264 m 
+gs 1 -1 scale (3) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+39 134 m 
+gs 1 -1 scale ( a\)) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+39 174 m 
+gs 1 -1 scale ( b\)) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+39 214 m 
+gs 1 -1 scale ( c\)) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+39 254 m 
+gs 1 -1 scale ( d\)) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+39 34 m 
+gs 1 -1 scale (incoming query) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+39 74 m 
+gs 1 -1 scale (Find the best servers to ask) col-1 show gr
+$F2psEnd
+%%EndDocument
+ @endspecial 724 2219 a(Figure)g(2.8)33 b(Resolv)o(er)15 b(algorithm)223
+2434 y(The)k(resolv)o(er)g(acts)h(as)g(the)f(in)o(terface)g(b)q(et)o(w)o(een)
+f(a)i(user)g(program)f(and)i(the)e(name)g(serv)o(er)149 2524
+y(describ)q(ed)j(in)g(Figure)g(2.9)h(and)g(p)q(erforms)f(three)f(main)g
+(actions)i(to)g(map)e(the)i(query)e(to)i(an)149 2614 y(answ)o(er.)f(The)17
+b(algorithm)e(\(see)h(Figure)g(2.8)h(and)g(the)f(follo)o(wing)g(list)g(for)h
+(details\))f(tries)f(to)i(\014nd)p eop
+%%Page: 31 40
+39 bop 1901 -100 a Fo(31)149 75 y(the)17 b(information)e(lo)q(cally)h
+(\014rst.)23 b(If)16 b(that)h(do)q(es)g(not)g(succeed,)f(it)g(sends)h(the)f
+(query)g(to)h(the)f(b)q(est)149 165 y(serv)o(er)d(to)h(ask.)20
+b(As)14 b(so)q(on)h(as)f(a)g(reply)e(returns,)i(it)f(c)o(hec)o(ks)f(for)h
+(answ)o(er,)h(name)f(error,)g(delegation,)149 255 y(canonical)j(name)e
+(expansion,)h(or)h(failure)e(of)i(the)f(serv)o(er)f(and)i(reacts)f(prop)q
+(erly)l(.)20 b(The)c(follo)o(wing)149 346 y(steps)h(describ)q(e)f(the)g
+(algorithm)f(in)h(more)f(detail.)20 b(They)c(are)g(deriv)o(ed)f(from)g([Mo)q
+(c87a)q(]:)209 486 y(1.)24 b(See)15 b(if)g(the)g(answ)o(er)h(to)f(the)h
+(query)e(is)h(in)g(the)g(lo)q(cal)h(information,)e(and)i(if)e(so,)i(return)f
+(it)g(to)271 576 y(the)h(clien)o(t.)209 707 y(2.)24 b(Find)16
+b(the)g(b)q(est)h(serv)o(ers)e(to)i(ask.)209 838 y(3.)24 b(Send)17
+b(them)d(queries)h(un)o(til)h(one)g(returns)g(a)h(resp)q(onse.)209
+969 y(4.)24 b(Analyze)15 b(the)h(resp)q(onse:)292 1111 y(\(a\))25
+b(if)18 b(the)h(resp)q(onse)g(answ)o(ers)h(the)e(question)h(or)g(con)o(tains)
+g(a)h(name)d(error,)j(cac)o(he)e(the)379 1202 y(data)f(as)g(w)o(ell)e(as)h
+(return)g(it)g(to)h(the)f(clien)o(t.)289 1312 y(\(b\))25 b(if)d(the)h(resp)q
+(onse)g(con)o(tains)g(a)h(b)q(etter)e(delegation)h(to)g(other)g(serv)o(ers,)h
+(cac)o(he)e(the)379 1402 y(delegation)16 b(information,)e(and)j(go)g(to)g
+(step)f(2.)295 1512 y(\(c\))24 b(if)16 b(the)h(resp)q(onse)h(sho)o(ws)g(a)f
+(CNAME)f(whic)o(h)h(is)f(not)i(the)f(answ)o(er)g(itself,)f(cac)o(he)g(the)379
+1602 y(CNAME,)e(c)o(hange)i(the)f(queried)f(name)h(to)h(the)f(canonical)g
+(name)g(in)g(the)g(CNAME)379 1693 y(RR)h(and)h(go)g(to)f(step)g(1.)289
+1803 y(\(d\))25 b(if)16 b(the)h(resp)q(onse)g(sho)o(ws)h(a)g(serv)o(er)d
+(failure)h(or)i(other)f(bizarre)f(con)o(ten)o(ts,)g(delete)g(the)379
+1893 y(serv)o(er)f(from)g(the)h(serv)o(er)f(list)h(and)h(go)g(bac)o(k)e(to)i
+(step)f(3.)149 2059 y(2.10)50 b(In)o(teraction)15 b(of)i(Name)d(Serv)o(er)h
+(and)i(Resolv)o(er)223 2198 y(Name)e(serv)o(er)g(and)j(resolv)o(er)d(in)o
+(teract)h(mainly)f(b)o(y)h(passing)i(data)g(bac)o(k)e(and)i(forth.)23
+b(There)149 2289 y(is)16 b(at)g(most)e(indirect)g(con)o(trol)i(\015o)o(w)f
+(at)h(step)g(\014v)o(e)e(in)i(the)f(name)f(serv)o(er)g(algorithm)h(\(see)g
+(Section)149 2379 y(2.9.2\).)28 b(In)18 b(the)g(case)h(that)g(a)f(resolv)o
+(er)g(requests)f(recursiv)o(e)g(name)g(resolution)i(and)g(the)f(name)149
+2469 y(serv)o(er)h(pro)o(vides)g(this)g(service,)f(the)h(name)f(serv)o(er)h
+(passes)h(the)f(query)g(to)h(the)f(lo)q(cal)g(resolv)o(er.)149
+2560 y(This)f(can)f(b)q(e)g(seen)f(as)i(pure)f(data)h(\015o)o(w,)f(but)g(b)q
+(ecause)g(the)g(execution)f(of)h(the)g(whole)f(query)h(is)149
+2650 y(passed)g(to)g(the)f(resolv)o(er,)f(w)o(e)h(in)o(terpret)e(it)i(as)h
+(con)o(trol)f(\015o)o(w.)p eop
+%%Page: 32 41
+40 bop 1901 -100 a Fo(32)149 75 y(2.10.1)50 b(Data)17 b(Flo)o(w)149
+2152 y @beginspecial 0 @llx 0 @lly 432 @urx 416 @ury 4320 @rwi
+@setspecial
+%%BeginDocument: pictures/dns_flow.ps
+/$F2psDict 200 dict def 
+$F2psDict begin
+$F2psDict /mtrx matrix put
+/l {lineto} bind def
+/m {moveto} bind def
+/s {stroke} bind def
+/n {newpath} bind def
+/gs {gsave} bind def
+/gr {grestore} bind def
+/clp {closepath} bind def
+/graycol {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
+4 -2 roll mul setrgbcolor} bind def
+/col-1 {} def
+/col0 {0 0 0 setrgbcolor} bind def
+/col1 {0 0 1 setrgbcolor} bind def
+/col2 {0 1 0 setrgbcolor} bind def
+/col3 {0 1 1 setrgbcolor} bind def
+/col4 {1 0 0 setrgbcolor} bind def
+/col5 {1 0 1 setrgbcolor} bind def
+/col6 {1 1 0 setrgbcolor} bind def
+/col7 {1 1 1 setrgbcolor} bind def
+	end
+/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
+/$F2psEnd {$F2psEnteredState restore end} def
+
+$F2psBegin
+0 setlinecap 0 setlinejoin
+0.0 432.0 translate 0.900 -0.900 scale
+1.000 setlinewidth
+	[6.000000] 0 setdash
+n 68.375 129.000 70.625 -97.628 97.628 arc
+gs col-1 s gr
+	[] 0 setdash
+0.500 setlinewidth
+n 196 99 m 189 99 189 152 7 arcto 4 {pop} repeat 189 159 282 159 7 arcto 4 {pop} repeat 289 159 289 106 7 arcto 4 {pop} repeat 289 99 196 99 7 arcto 4 {pop} repeat clp gs col-1 s gr
+n 99 119 m 189 119 l gs col-1 s gr
+n 181.000 117.000 m 189.000 119.000 l 181.000 121.000 l gs 2 setlinejoin col-1 s gr
+n 289 119 m 379 119 l gs col-1 s gr
+n 371.000 117.000 m 379.000 119.000 l 371.000 121.000 l gs 2 setlinejoin col-1 s gr
+n 379 139 m 289 139 l gs col-1 s gr
+n 297.000 141.000 m 289.000 139.000 l 297.000 137.000 l gs 2 setlinejoin col-1 s gr
+n 189 139 m 99 139 l gs col-1 s gr
+n 107.000 141.000 m 99.000 139.000 l 107.000 137.000 l gs 2 setlinejoin col-1 s gr
+n 196 199 m 189 199 189 252 7 arcto 4 {pop} repeat 189 259 282 259 7 arcto 4 {pop} repeat 289 259 289 206 7 arcto 4 {pop} repeat 289 199 196 199 7 arcto 4 {pop} repeat clp gs col-1 s gr
+n 386 299 m 379 299 379 352 7 arcto 4 {pop} repeat 379 359 472 359 7 arcto 4 {pop} repeat 479 359 479 306 7 arcto 4 {pop} repeat 479 299 386 299 7 arcto 4 {pop} repeat clp gs col-1 s gr
+n 6 299 m -1 299 -1 352 7 arcto 4 {pop} repeat -1 359 92 359 7 arcto 4 {pop} repeat 99 359 99 306 7 arcto 4 {pop} repeat 99 299 6 299 7 arcto 4 {pop} repeat clp gs col-1 s gr
+n 269 199 m 269 159 l gs col-1 s gr
+n 267.000 167.000 m 269.000 159.000 l 271.000 167.000 l gs 2 setlinejoin col-1 s gr
+n 269 259 m 269 299 l gs col-1 s gr
+n 271.000 291.000 m 269.000 299.000 l 267.000 291.000 l gs 2 setlinejoin col-1 s gr
+n 209 299 m 209 259 l gs col-1 s gr
+n 207.000 267.000 m 209.000 259.000 l 211.000 267.000 l gs 2 setlinejoin col-1 s gr
+n 209 159 m 209 199 l gs col-1 s gr
+n 211.000 191.000 m 209.000 199.000 l 207.000 191.000 l gs 2 setlinejoin col-1 s gr
+n 289 319 m 379 319 l gs col-1 s gr
+n 371.000 317.000 m 379.000 319.000 l 371.000 321.000 l gs 2 setlinejoin col-1 s gr
+n 379 339 m 289 339 l gs col-1 s gr
+n 297.000 341.000 m 289.000 339.000 l 297.000 337.000 l gs 2 setlinejoin col-1 s gr
+n 269 359 m 269 419 l  379 419 l gs col-1 s gr
+n 371.000 417.000 m 379.000 419.000 l 371.000 421.000 l gs 2 setlinejoin col-1 s gr
+n 379 439 m 209 439 l  209 359 l gs col-1 s gr
+n 207.000 367.000 m 209.000 359.000 l 211.000 367.000 l gs 2 setlinejoin col-1 s gr
+n 99 329 m 189 329 l gs col-1 s gr
+n 181.000 327.000 m 189.000 329.000 l 181.000 331.000 l gs 2 setlinejoin col-1 s gr
+n 11 304 m 4 304 4 347 7 arcto 4 {pop} repeat 4 354 87 354 7 arcto 4 {pop} repeat 94 354 94 311 7 arcto 4 {pop} repeat 94 304 11 304 7 arcto 4 {pop} repeat clp gs col-1 s gr
+n 201 204 m 194 204 194 247 7 arcto 4 {pop} repeat 194 254 277 254 7 arcto 4 {pop} repeat 284 254 284 211 7 arcto 4 {pop} repeat 284 204 201 204 7 arcto 4 {pop} repeat clp gs col-1 s gr
+n 6 99 m -1 99 -1 152 7 arcto 4 {pop} repeat -1 159 92 159 7 arcto 4 {pop} repeat 99 159 99 106 7 arcto 4 {pop} repeat 99 99 6 99 7 arcto 4 {pop} repeat clp gs col-1 s gr
+1.000 setlinewidth
+	[6.000000] 0 setdash
+n 334 19 m 334 479 l gs col-1 s gr
+	[] 0 setdash
+0.500 setlinewidth
+n 386 99 m 379 99 379 152 7 arcto 4 {pop} repeat 379 159 472 159 7 arcto 4 {pop} repeat 479 159 479 106 7 arcto 4 {pop} repeat 479 99 386 99 7 arcto 4 {pop} repeat clp gs 0.95 setgray fill gr
+gs col-1 s gr
+n 386 404 m 379 404 379 457 7 arcto 4 {pop} repeat 379 464 472 464 7 arcto 4 {pop} repeat 479 464 479 411 7 arcto 4 {pop} repeat 479 404 386 404 7 arcto 4 {pop} repeat clp gs 0.95 setgray fill gr
+gs col-1 s gr
+n 196 299 m 189 299 189 352 7 arcto 4 {pop} repeat 189 359 282 359 7 arcto 4 {pop} repeat 289 359 289 306 7 arcto 4 {pop} repeat 289 299 196 299 7 arcto 4 {pop} repeat clp gs 0.95 setgray fill gr
+gs col-1 s gr
+1.000 setlinewidth
+n 34 44 m 159 44 l gs col-1 s gr
+n 374 44 m 464 44 l gs col-1 s gr
+	[6.000000] 0 setdash
+n -1 59 m 59 59 l gs col-1 s gr
+	[] 0 setdash
+	[6.000000] 0 setdash
+n -1 199 m 59 199 l gs col-1 s gr
+	[] 0 setdash
+	[6.000000] 0 setdash
+n -1 229 m 334 229 l gs col-1 s gr
+	[] 0 setdash
+/Times-Bold findfont 24.00 scalefont setfont
+39 39 m 
+gs 1 -1 scale (Local Host) col-1 show gr
+/Times-Bold findfont 24.00 scalefont setfont
+194 139 m 
+gs 1 -1 scale (resolver) col-1 show gr
+/Times-Bold findfont 24.00 scalefont setfont
+9 324 m 
+gs 1 -1 scale (master) col-1 show gr
+/Times-Bold findfont 24.00 scalefont setfont
+194 249 m 
+gs 1 -1 scale (database) col-1 show gr
+/Times-Bold findfont 24.00 scalefont setfont
+204 349 m 
+gs 1 -1 scale (server) col-1 show gr
+/Times-Bold findfont 24.00 scalefont setfont
+389 324 m 
+gs 1 -1 scale (foreign) col-1 show gr
+/Times-Bold findfont 24.00 scalefont setfont
+384 349 m 
+gs 1 -1 scale (resolver) col-1 show gr
+/Times-Bold findfont 24.00 scalefont setfont
+399 139 m 
+gs 1 -1 scale (name) col-1 show gr
+/Times-Bold findfont 24.00 scalefont setfont
+399 444 m 
+gs 1 -1 scale (name) col-1 show gr
+/Times-Bold findfont 24.00 scalefont setfont
+379 39 m 
+gs 1 -1 scale (Foreign) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+104 154 m 
+gs 1 -1 scale (user responses) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+274 184 m 
+gs 1 -1 scale (references) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+124 184 m 
+gs 1 -1 scale (cache additions) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+114 114 m 
+gs 1 -1 scale (user queries) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+209 454 m 
+gs 1 -1 scale (maintenance responses) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+274 284 m 
+gs 1 -1 scale (references) col-1 show gr
+/Times-Bold findfont 24.00 scalefont setfont
+394 459 m 
+gs 1 -1 scale (server) col-1 show gr
+/Times-Bold findfont 24.00 scalefont setfont
+394 154 m 
+gs 1 -1 scale (server) col-1 show gr
+/Times-Bold findfont 24.00 scalefont setfont
+389 119 m 
+gs 1 -1 scale (foreign) col-1 show gr
+/Times-Bold findfont 24.00 scalefont setfont
+389 424 m 
+gs 1 -1 scale (foreign) col-1 show gr
+/Times-Bold findfont 24.00 scalefont setfont
+209 324 m 
+gs 1 -1 scale (name) col-1 show gr
+/Times-Bold findfont 24.00 scalefont setfont
+204 224 m 
+gs 1 -1 scale (shared) col-1 show gr
+/Times-Bold findfont 24.00 scalefont setfont
+24 144 m 
+gs 1 -1 scale (prg.) col-1 show gr
+/Times-Bold findfont 24.00 scalefont setfont
+24 124 m 
+gs 1 -1 scale (user) col-1 show gr
+/Times-Bold findfont 24.00 scalefont setfont
+24 349 m 
+gs 1 -1 scale (files) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+309 154 m 
+gs 1 -1 scale (responses) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+314 114 m 
+gs 1 -1 scale (queries) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+309 314 m 
+gs 1 -1 scale (responses) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+314 354 m 
+gs 1 -1 scale (queries) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+294 414 m 
+gs 1 -1 scale (maintenance) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+309 434 m 
+gs 1 -1 scale (queries) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+154 284 m 
+gs 1 -1 scale (refreshes) col-1 show gr
+$F2psEnd
+%%EndDocument
+ @endspecial 584 2396 a(Figure)f(2.9)33 b(Data)17 b(\015o)o(w)g(b)q(et)o(w)o
+(een)e(DNS)h(en)o(tities)p eop
+%%Page: 33 42
+41 bop 1901 -100 a Fo(33)223 75 y(The)21 b(data)i(\015o)o(w)f(b)q(et)o(w)o
+(een)f(Domain)g(Name)f(System)h(en)o(tities)f(is)h(not)i(limited)c(to)j
+(simple)149 165 y(queries)f(and)h(resp)q(onses,)i(illustrated)c(in)i(Figure)f
+(2.9.)37 b(W)l(e)22 b(distinguish)f(among)h(four)g(parts)149
+255 y(that)d(in)o(teract)e(with)h(eac)o(h)f(other:)25 b(the)18
+b(user)g(program,)g(the)g(resolv)o(er,)f(the)h(name)f(serv)o(er,)g(and)149
+346 y(an)g(unkno)o(wn)g(subnet)f(that)h(can)f(con)o(tain)g(foreign)h(name)e
+(serv)o(ers)g(and)i(resolv)o(ers.)223 436 y(User)12 b(program)h(and)h(resolv)
+o(er)e(exc)o(hange)g(user)i(queries)e(and)h(user)h(resp)q(onses.)21
+b(In)13 b(the)f(BIND)149 526 y(impleme)o(n)o(tation)17 b(of)k(the)f(Domain)f
+(Name)f(System,)h(this)h(exc)o(hange)g(is)g(done)g(b)o(y)f(calling)h(the)149
+616 y(system)h(calls)g(\\gethostb)o(y)o(addr\(\)")i(and)f(\\gethostb)o
+(yname\(\)".)37 b(As)22 b(can)f(b)q(e)h(seen)g(here,)g(the)149
+707 y(usage)14 b(of)f(the)g(Domain)f(Name)f(System)h(is)g(completely)e
+(transparen)o(t)j(to)h(the)e(user)h(who)h(requests)149 797
+y(name)f(resolution.)20 b(The)14 b(same)f(system)f(call)h(in)o(terface)f(can)
+i(b)q(e)g(used)g(when)g(the)f(Domain)g(Name)149 887 y(System)i(is)h(replaced)
+g(b)o(y)f(another)i(mapping)f(mec)o(hanism)d(\(for)j(example)e(static)i
+(mapping\).)223 978 y(Lo)q(cal)d(resolv)o(ers)f(comm)o(unic)o(ate)e(with)j
+(foreign)f(name)g(serv)o(ers)g(via)g(the)g(exc)o(hange)h(of)f(queries)149
+1068 y(and)22 b(resp)q(onses,)g(as)g(do)q(es)f(a)h(lo)q(cal)e(name)g(serv)o
+(er)g(with)g(foreign)h(name)f(serv)o(ers)g(or)h(resolv)o(ers.)149
+1158 y(Queries)i(are)g(alw)o(a)o(ys)g(sen)o(t)g(to)g(a)h(name)e(serv)o(er)g
+(and)h(resp)q(onses)h(go)g(the)f(rev)o(erse)f(direction.)149
+1248 y(When)d(name)f(serv)o(ers)g(comm)o(uni)o(cate,)e(they)i(exc)o(hange)g
+(zone)h(data)h(or)f(main)o(tenance)d(queries)149 1339 y(and)h(resp)q(onses.)k
+(Under)15 b(the)h(assumption)f(that)h(the)f(lo)q(cal)g(name)g(serv)o(er)f(is)
+h(a)h(primary)e(serv)o(er,)149 1429 y(it)i(gets)h(its)f(primary)e(zone)i
+(data)i(from)d(the)h(master)f(\014les.)223 1519 y(Both)j(name)f(serv)o(er)g
+(and)h(resolv)o(er)f(usually)h(main)o(tain)f(a)h(cac)o(he.)26
+b(It)18 b(is)g(not)g(un)o(usual)h(for)f(a)149 1610 y(name)e(serv)o(er)f(and)i
+(a)f(resolv)o(er)f(that)i(run)f(on)h(a)g(single)f(host)g(to)h(share)g(this)f
+(database.)149 1770 y(2.10.2)50 b(Shared)16 b(Information)223
+1892 y(A)d(shared)i(cac)o(he)e(can)i(b)q(e)f(accessed)g(b)o(y)g(resolv)o(er)f
+(and)i(name)e(serv)o(er.)19 b(Resolv)o(ers)13 b(pro)o(vide)h(as)149
+1982 y(cac)o(he)k(additions)h(whatev)o(er)f(they)h(learn)f(from)g(the)g(resp)
+q(onses)i(to)f(their)f(queries.)27 b(They)19 b(also)149 2073
+y(consult)d(the)f(cac)o(he)g(and)h(retriev)o(e)d(data)k(from)d(it.)21
+b(Name)14 b(serv)o(ers)g(also)i(reference)e(the)h(cac)o(he)g(to)149
+2163 y(answ)o(er)i(queries)e(and)i(pro)o(vide)e(refreshes)h(from)f(lo)q(cal)h
+(authoritativ)o(e)g(data.)223 2253 y(A)g(database)j(that)f(is)f(shared)h
+(concurren)o(tly)d(b)o(y)i(man)o(y)f(pro)q(cesses)i(m)o(ust)e(b)q(e)h
+(protected)g(b)o(y)149 2343 y(sync)o(hronization)c(mec)o(hanism)o(s.)18
+b(The)12 b(additional)h(complexit)o(y)c(in)k(dealing)f(with)g(the)h(problems)
+149 2434 y(a)g(shared)f(database)h(brings)f(with)f(it)g(is)h(amortized)e(b)o
+(y)h(the)g(gain)i(in)e(p)q(erformance)f(and)j(e\016ciency)149
+2524 y(of)21 b(the)f(system)f(in)h(total.)34 b(It)19 b(is)i(ob)o(vious)f
+(that)h(successful)e(lo)q(okups)j(in)e(the)g(lo)q(cal)g(cac)o(he)f(are)149
+2614 y(preferred)13 b(o)o(v)o(er)g(sending)h(queries)f(to)i(remote)d(mac)o
+(hines)g(with)h(no)i(b)q(ounds)g(on)g(ho)o(w)f(long)g(it)g(will)p
+eop
+%%Page: 34 43
+42 bop 1901 -100 a Fo(34)149 75 y(tak)o(e)16 b(them)e(to)i(reply)l(.)k(Main)o
+(taining)c(a)g(larger)g(cac)o(he)f(shared)h(b)q(et)o(w)o(een)f(t)o(w)o(o)h
+(en)o(tities)e(increases)149 165 y(the)i(probabilit)o(y)g(of)g(\014nding)h(a)
+g(matc)o(h)d(in)i(the)g(cac)o(he.)p eop
+%%Page: 35 44
+43 bop 1901 -100 a Fo(35)323 342 y(3.)33 b(DESCRIPTION)16 b(AND)g(DEMONSTRA)l
+(TION)e(OF)i(WEAKNESSES)223 516 y(This)22 b(c)o(hapter)f(concen)o(trates)g
+(on)i(the)f(description)f(and)h(demonstration)g(of)g(the)f(cen)o(tral)149
+606 y(problem)15 b(of)i(this)f(thesis.)223 696 y(W)l(e)22 b(\014rst)h(giv)o
+(e)f(an)h(abstract)g(statemen)o(t)e(of)i(the)f(problem.)39
+b(W)l(e)23 b(state)g(it)f(again)h(in)g(the)149 787 y(follo)o(wing)h(section,)
+i(but)e(in)g(a)h(more)e(concrete)g(fashion)i(directly)e(related)g(to)i(the)f
+(Domain)149 877 y(Name)14 b(System.)20 b(W)l(e)15 b(talk)g(ab)q(out)i(the)e
+(general)g(features)h(in)f(the)g(Domain)g(Name)f(System)g(that)149
+967 y(facilitate)h(the)h(exploitation)g(of)g(the)g(problem.)223
+1057 y(The)i(follo)o(wing)h(section)f(giv)o(es)g(details)g(of)h(regular)f
+(remote)f(mac)o(hine)g(access)h(and)i(sev)o(eral)149 1148 y(approac)o(hes)k
+(of)f(ho)o(w)h(to)f(exploit)f(the)h(problem)e(to)j(gain)f(unauthorized)g
+(access.)42 b(W)l(e)23 b(then)149 1238 y(talk)f(ab)q(out)h(our)f(implem)o(en)
+o(tation)d(test)j(en)o(vironmen)o(t)d(and)j(describ)q(e)f(the)h(exp)q(erimen)
+o(ts)d(w)o(e)149 1328 y(p)q(erformed)14 b(to)h(supp)q(ort)i(the)d(claim)f
+(that)i(this)g(securit)o(y)e(\015a)o(w)j(is)e(exploitable.)20
+b(The)15 b(concluding)149 1419 y(section)h(of)h(this)f(c)o(hapter)g(presen)o
+(ts)g(the)g(exp)q(eriences)e(w)o(e)i(gained)h(from)e(our)h(exp)q(erimen)o
+(ts.)223 1509 y(Figure)i(3.1)g(sho)o(ws)i(the)e(setup)g(of)h(mac)o(hines)d
+(and)j(their)f(names.)27 b(It)18 b(serv)o(es)f(as)i(a)g(running)149
+1599 y(example)11 b(in)i(this)g(c)o(hapter.)20 b(A)12 b(detailed)g
+(description)h(of)g(this)g(setup)g(is)g(giv)o(en)f(in)h(Section)f(3.5.1.)149
+1765 y(3.1)50 b(Statemen)o(t)14 b(of)i(the)g(Problem)223 1904
+y(Authen)o(ticit)o(y)11 b(is)j(based)h(on)g(the)f(iden)o(tit)o(y)f(of)h(some)
+g(en)o(tit)o(y)l(.)k(This)d(en)o(tit)o(y)e(has)i(to)f(pro)o(v)o(e)g(that)149
+1994 y(it)19 b(is)g(gen)o(uine.)30 b(In)19 b(man)o(y)f(net)o(w)o(ork)h
+(applications)g(the)g(iden)o(tit)o(y)e(of)j(participating)f(en)o(tities)f(is)
+149 2085 y(simply)f(determined)f(b)o(y)j(their)f(names)f(or)j(addresses.)29
+b(High)18 b(lev)o(el)f(applications)i(use)f(mainly)149 2175
+y(names)f(for)h(authen)o(tication)f(purp)q(oses,)i(b)q(ecause)e(address)i
+(lists)e(are)g(m)o(uc)o(h)f(harder)i(to)g(create,)149 2265
+y(understand,)f(and)g(main)o(tain)d(than)j(name)e(lists.)223
+2356 y(Assuming)f(an)i(en)o(tit)o(y)e(w)o(an)o(ts)i(to)f(sp)q(o)q(of)j(the)d
+(iden)o(tit)o(y)e(of)j(some)f(other)g(en)o(tit)o(y)l(,)f(it)h(is)g(in)g(some)
+149 2446 y(cases)j(enough)f(to)g(c)o(hange)g(the)g(mapping)f(b)q(et)o(w)o
+(een)g(its)h(lo)o(w)f(lev)o(el)f(address)j(and)f(its)g(high)g(lev)o(el)149
+2536 y(name.)j(That)d(means)e(that)i(an)f(attac)o(k)o(er)f(can)i(fak)o(e)e
+(the)h(name)f(of)h(someone)f(b)o(y)h(mo)q(difying)f(the)149
+2626 y(asso)q(ciation)j(of)e(his)h(address)g(from)e(his)h(o)o(wn)g(name)g(to)
+g(the)g(name)f(he)h(w)o(an)o(ts)h(to)f(imp)q(ersonate.)p eop
+%%Page: 36 45
+44 bop 1901 -100 a Fo(36)224 1204 y @beginspecial 0 @llx 0
+@lly 378 @urx 265 @ury 3780 @rwi @setspecial
+%%BeginDocument: pictures/d_z_setup.ps
+/$F2psDict 200 dict def 
+$F2psDict begin
+$F2psDict /mtrx matrix put
+/l {lineto} bind def
+/m {moveto} bind def
+/s {stroke} bind def
+/n {newpath} bind def
+/gs {gsave} bind def
+/gr {grestore} bind def
+/clp {closepath} bind def
+/graycol {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
+4 -2 roll mul setrgbcolor} bind def
+/col-1 {} def
+/col0 {0 0 0 setrgbcolor} bind def
+/col1 {0 0 1 setrgbcolor} bind def
+/col2 {0 1 0 setrgbcolor} bind def
+/col3 {0 1 1 setrgbcolor} bind def
+/col4 {1 0 0 setrgbcolor} bind def
+/col5 {1 0 1 setrgbcolor} bind def
+/col6 {1 1 0 setrgbcolor} bind def
+/col7 {1 1 1 setrgbcolor} bind def
+	end
+/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
+/$F2psEnd {$F2psEnteredState restore end} def
+
+$F2psBegin
+0 setlinecap 0 setlinejoin
+-9.0 270.0 translate 0.900 -0.900 scale
+1.000 setlinewidth
+	[6.000000] 0 setdash
+n 379 19 m 419 19 l gs col-1 s gr
+	[] 0 setdash
+	[6.000000] 0 setdash
+n 379 299 m 419 299 l gs col-1 s gr
+	[] 0 setdash
+n 99 19 m 99 39 l gs col-1 s gr
+n 99 279 m 99 299 l gs col-1 s gr
+n 339 19 m 339 39 l gs col-1 s gr
+n 339 279 m 339 299 l gs col-1 s gr
+0.500 setlinewidth
+n 159 59 m 279 59 l gs col-1 s gr
+n 271.000 57.000 m 279.000 59.000 l 271.000 61.000 l gs 2 setlinejoin col-1 s gr
+n 77.000 107.000 m 79.000 99.000 l 81.000 107.000 l gs 2 setlinejoin col-1 s gr
+n 79 99 m 79 219 l gs col-1 s gr
+n 81.000 211.000 m 79.000 219.000 l 77.000 211.000 l gs 2 setlinejoin col-1 s gr
+n 46 39 m 39 39 39 92 7 arcto 4 {pop} repeat 39 99 152 99 7 arcto 4 {pop} repeat 159 99 159 46 7 arcto 4 {pop} repeat 159 39 46 39 7 arcto 4 {pop} repeat clp gs 0.95 setgray fill gr
+gs col-1 s gr
+n 286 39 m 279 39 279 92 7 arcto 4 {pop} repeat 279 99 392 99 7 arcto 4 {pop} repeat 399 99 399 46 7 arcto 4 {pop} repeat 399 39 286 39 7 arcto 4 {pop} repeat clp gs 0.95 setgray fill gr
+gs col-1 s gr
+n 286 219 m 279 219 279 272 7 arcto 4 {pop} repeat 279 279 392 279 7 arcto 4 {pop} repeat 399 279 399 226 7 arcto 4 {pop} repeat 399 219 286 219 7 arcto 4 {pop} repeat clp gs 0.95 setgray fill gr
+gs col-1 s gr
+n 46 219 m 39 219 39 272 7 arcto 4 {pop} repeat 39 279 152 279 7 arcto 4 {pop} repeat 159 279 159 226 7 arcto 4 {pop} repeat 159 219 46 219 7 arcto 4 {pop} repeat clp gs 0.95 setgray fill gr
+gs col-1 s gr
+1.000 setlinewidth
+n 379 19 m 39 19 l gs col-1 s gr
+n 19 39 m 19 279 l gs col-1 s gr
+n 39 299 m 379 299 l gs col-1 s gr
+0.500 setlinewidth
+	[3.000000] 0 setdash
+n 9 189 m 429 189 l gs col-1 s gr
+	[] 0 setdash
+1.000 setlinewidth
+n 19 279 m
+	20.353 287.853 21.603 291.603 24 294 curveto
+	26.397 296.397 30.147 297.647 39 299 curveto
+gs col-1 s gr
+n 39 19 m
+	30.147 20.353 26.397 21.603 24 24 curveto
+	21.603 26.397 20.353 30.147 19 39 curveto
+gs col-1 s gr
+	1 setlinecap [1 6.000000] 6.000000 setdash
+n 319 219 m
+	322.096 196.474 322.096 186.474 319 179 curveto
+	316.081 171.953 306.047 161.919 299 159 curveto
+	259.136 142.488 178.864 175.512 139 159 curveto
+	131.953 156.081 121.919 146.047 119 139 curveto
+	115.904 131.526 115.904 121.526 119 99 curveto
+gs col-1 s gr
+	[] 0 setdash 0 setlinecap
+n 112.859 114.306 m 119.000 99.000 l 120.784 115.396 l gs 2 setlinejoin col-1 s gr
+/Times-Roman findfont 24.00 scalefont setfont
+79 74 m 
+gs 1 -1 scale (NS) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+109 79 m 
+gs 1 -1 scale (A) col-1 show gr
+/Times-Roman findfont 24.00 scalefont setfont
+329 74 m 
+gs 1 -1 scale (H) col-1 show gr
+/Times-Roman findfont 24.00 scalefont setfont
+329 254 m 
+gs 1 -1 scale (H) col-1 show gr
+/Times-Roman findfont 24.00 scalefont setfont
+79 254 m 
+gs 1 -1 scale (NS) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+349 79 m 
+gs 1 -1 scale (A) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+109 259 m 
+gs 1 -1 scale (B) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+349 259 m 
+gs 1 -1 scale (B) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+139 14 m 
+gs 1 -1 scale (Ethernet) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+339 179 m 
+gs 1 -1 scale (attacked side) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+339 209 m 
+gs 1 -1 scale (attacking side) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+44 94 m 
+gs 1 -1 scale (name server) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+284 94 m 
+gs 1 -1 scale (host) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+44 274 m 
+gs 1 -1 scale (name server) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+284 274 m 
+gs 1 -1 scale (host) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+84 184 m 
+gs 1 -1 scale (exchange of DNS packets) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+144 149 m 
+gs 1 -1 scale (Hi! I am Bob from H) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+179 54 m 
+gs 1 -1 scale (Alice trusts Bob) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+44 54 m 
+gs 1 -1 scale (user: Alice) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+284 54 m 
+gs 1 -1 scale (user: Bob) col-1 show gr
+/Times-Roman findfont 8.00 scalefont setfont
+244 154 m 
+gs 1 -1 scale (A) col-1 show gr
+$F2psEnd
+%%EndDocument
+ @endspecial 717 1449 a(Figure)15 b(3.1)33 b(Exp)q(erimen)o(tal)14
+b(setup)223 1633 y(Once)k(an)i(attac)o(k)o(er)e(has)i(done)g(that,)g(an)f
+(authen)o(ticator)h(can)f(no)h(longer)f(distinguish)g(b)q(e-)149
+1723 y(t)o(w)o(een)d(the)g(true)g(and)g(the)g(fak)o(ed)g(en)o(tit)o(y)l(.)223
+1813 y(This)23 b(describ)q(es)f(the)h(fundamen)o(tal)e(problem)h(on)h(whic)o
+(h)f(this)h(thesis)g(is)g(based.)41 b(If)23 b(the)149 1904
+y(binding)f(pro)q(cess)f(b)q(et)o(w)o(een)g(names)f(and)i(addresses)g(cannot)
+g(b)q(e)f(trusted)g(fully)l(,)g(no)h(one)f(can)149 1994 y(rely)16
+b(on)g(an)h(authen)o(tication)f(pro)q(cess)h(on)g(a)f(high)h(lev)o(el.)149
+2159 y(3.2)50 b(The)16 b(Problem)f(in)g(the)h(DNS)223 2299
+y(Man)o(y)i(securit)o(y)f(problems)h(of)h(the)g(TCP/IP)g(proto)q(col)h(suite)
+e(rely)g(on)i(the)e(abilit)o(y)g(of)h(the)149 2389 y(attac)o(k)o(er)g(to)i
+(sp)q(o)q(of)g(the)f(IP)g(address)g(of)h(a)f(trusted)g(mac)o(hine,)e(as)j
+(describ)q(ed)e(in)h([Bel89)o(].)32 b(As)149 2479 y(hosts)19
+b(trust)f(eac)o(h)f(other,)h(usually)f(on)i(the)e(basis)h(of)g(host)h(names,)
+e(an)h(attac)o(k)o(er)f(can)h(tak)o(e)f(the)149 2570 y(easier)f(approac)o(h)h
+(and)g(sp)q(o)q(of)h(a)f(host's)f(name)f(instead)i(of)f(its)g(IP)g(address.)p
+eop
+%%Page: 37 46
+45 bop 1901 -100 a Fo(37)223 75 y(If)22 b(a)i(host)g(named)e(H)640
+82 y Fm(A)691 75 y Fo(accesses)h(another)g(host)h(named)e(NS)1409
+82 y Fm(A)1437 75 y Fo(,)j(host)f(NS)1652 82 y Fm(A)1704 75
+y Fo(accepts)f(the)149 165 y(connection)e(and)g(retriev)o(es)e(address)j
+(information)e(ab)q(out)i(the)e(connecting)h(host)g(H)1773
+172 y Fm(A)1801 165 y Fo(.)35 b(Host)149 255 y(NS)213 262 y
+Fm(A)260 255 y Fo(reads)19 b(host)h(H)536 262 y Fm(A)564 255
+y Fo('s)e(IP)h(address)g(and)g(con)o(v)o(erts)f(it)g(in)o(to)h(a)g(regular)g
+(host)g(name.)27 b(T)l(o)20 b(bind)149 346 y(the)d(righ)o(t)g(name)e(to)j
+(the)e(IP)h(address,)g(host)h(NS)1055 353 y Fm(A)1100 346 y
+Fo(starts)g(a)f(Domain)f(Name)f(System)h(query)g(in)149 436
+y(the)g(rev)o(erse)f(lo)q(okup)i(tree.)223 526 y(F)l(or)j(a)g(pair)h(of)f
+(mac)o(hines)e(NS)800 533 y Fm(B)847 526 y Fo(and)j(H)983 533
+y Fm(B)1030 526 y Fo(under)f(the)g(p)q(o)o(w)o(er)g(of)g(an)h(attac)o(k)o
+(er,)f(with)g(NS)1922 533 y Fm(B)149 616 y Fo(running)14 b(a)f(primary)e
+(name)h(serv)o(er)g(for)h(a)g(certain)f(zone,)h(and)h(H)1330
+623 y Fm(B)1369 616 y Fo(trying)f(to)g(fak)o(e)f(H)1702 623
+y Fm(A)1730 616 y Fo('s)h(iden)o(tit)o(y)l(,)149 707 y(it)20
+b(is)f(easy)h(to)g(mak)o(e)d(NS)622 714 y Fm(A)670 707 y Fo(b)q(eliev)o(e)h
+(H)872 714 y Fm(B)918 707 y Fo(w)o(as)i(H)1052 714 y Fm(A)1080
+707 y Fo(.)32 b(H)1163 714 y Fm(B)1209 707 y Fo(connects)20
+b(to)g(NS)1537 714 y Fm(A)1585 707 y Fo(and)h(claims)c(to)j(b)q(e)149
+797 y(H)186 804 y Fm(A)215 797 y Fo(,)d(NS)310 804 y Fm(A)356
+797 y Fo(retriev)o(es)f(H)590 804 y Fm(B)616 797 y Fo('s)i(IP)f(address)i
+(111.22.33.4)g(and)g(queries)d(the)i(name)e(4.33.22.111.in-)149
+887 y(addr.arpa)24 b(from)e(the)g(Domain)g(Name)f(System.)39
+b(One)22 b(single)h(en)o(try)e(in)i(the)f(authoritativ)o(e)149
+978 y(data)i(for)g(the)e(rev)o(erse)g(lo)q(okup)i(tree)e(for)h(NS)1025
+985 y Fm(B)1052 978 y Fo('s)g(zone)g(sp)q(eci\014es)f(the)h(IP)g
+(address{to{name)149 1068 y(mapping)17 b(b)q(et)o(w)o(een)f
+(4.33.22.111.in-addr.arpa)k(and)e(H)1203 1075 y Fm(B)1229 1068
+y Fo(.)25 b(If)16 b(the)h(attac)o(k)o(er)g(replaces)f(this)i(line)149
+1158 y(b)o(y)j(a)h(mapping)f(b)q(et)o(w)o(een)f(4.33.22.111.in-addr.arpa)k
+(and)e(H)1338 1165 y Fm(A)1366 1158 y Fo(,)g(NS)1466 1165 y
+Fm(A)1494 1158 y Fo('s)f(resolution)h(attempt)149 1248 y(will)16
+b(\014nally)f(gran)o(t)i(H)555 1255 y Fm(B)598 1248 y Fo(access)f(to)h(NS)865
+1255 y Fm(A)894 1248 y Fo(.)223 1339 y(This)d(sho)o(ws)i(the)e(simplicit)o(y)
+d(of)k(an)g(attac)o(k)g(that)g(is)f(based)h(up)q(on)h(trust)f(placed)f(in)g
+(the)h(data)149 1429 y(pro)o(vided)h(b)o(y)f(DNS.)g(It)h(is)g(based)g(on)g(a)
+h(w)o(eakness)e(in)h(the)g(DNS,)f(not)h(an)h(easily)e(\014xable)g(bug)i(in)
+149 1519 y(the)f(impleme)o(n)o(tation)e(of)i(a)h(particular)f(net)o(w)o(ork)f
+(service.)223 1610 y(One)k(widely)g(accepted)h(w)o(a)o(y)f(of)i(dealing)e
+(with)h(this)g(problem)f(is)g(the)h(Berk)o(eley)d(soft)o(w)o(are)149
+1700 y(patc)o(h)e(describ)q(ed)g(in)g(section)f(4.5.)22 b(Ho)o(w)o(ev)o(er,)
+13 b(adding)i(an)h(additional)f(Domain)g(Name)e(System)149
+1790 y(query)19 b(of)g(the)g(determined)e(host)j(name)e(to)h(the)g(serv)o(er)
+f(co)q(de)i(and)g(comparing)e(the)h(returned)149 1880 y(IP)f(addresses)g
+(against)g(the)f(original)h(IP)f(address)h(for)g(a)g(matc)o(h)e(only)h(adds)h
+(to)g(the)f(qualit)o(y)f(of)149 1971 y(securit)o(y;)e(it)g(do)q(es)h(not)g
+(pro)o(vide)e(complete)g(securit)o(y)l(.)19 b(An)14 b(attac)o(k)o(er)g(can)g
+(piggybac)o(k)g(additional)149 2061 y(resource)e(records)g(to)g(the)g(answ)o
+(er)g(pac)o(k)o(et)f(to)i(the)e(\014rst)i(query)l(.)19 b(Doing)12
+b(so,)h(the)f(attac)o(k)o(er)f(p)q(oisons)149 2151 y(the)21
+b(victim')o(s)d(cac)o(he)i(with)g(false)g(information,)g(suc)o(h)g(that)h
+(the)f(forw)o(ard)h(lo)q(okup)h(w)o(ould)e(not)149 2242 y(disclose)g(the)g
+(attac)o(k.)33 b(In)20 b(Section)f(3.5.6)i(w)o(e)f(go)h(in)o(to)e(more)g
+(detail)h(on)h(this)f(issue)g(when)g(w)o(e)149 2332 y(describ)q(e)c(our)h
+(concrete)e(approac)o(h)i(of)g(cac)o(he)e(corruption.)p eop
+%%Page: 38 47
+46 bop 1901 -100 a Fo(38)149 75 y(3.3)50 b(W)l(eaknesses)223
+214 y(In)15 b(this)h(section)g(w)o(e)f(describ)q(e)h(the)f(conditions)h(that)
+h(m)o(ust)d(hold)j(to)f(facilitate)f(a)h(break{in.)149 305
+y(The)k(Domain)f(Name)f(System)f(is)j(w)o(eak)f(in)g(sev)o(eral)g(places.)30
+b(W)l(e)19 b(examine)f(the)h(problems)f(of)149 395 y(name{based)h(authen)o
+(tication)g(pro)q(cesses,)h(trusting)f(information)f(that)i(comes)d(from)h
+(an)i(un-)149 485 y(trust)o(w)o(orth)o(y)e(authorit)o(y)l(,)f(and)h
+(accepting)f(additional,)g(p)q(ossibly)h(incorrect)f(information)f(that)149
+575 y(w)o(as)h(not)g(requested,)e(but)h(that)h(seems)e(to)h(pro)o(vide)g(adv)
+m(an)o(tages)h(for)g(run)o(time)d(p)q(erformance.)149 735 y(3.3.1)49
+b(Assumptions)16 b(to)g(F)l(acilitate)f(Break{ins)223 858 y(In)g(our)g(setup)
+h(w)o(e)f(assume)f(that)i(the)f(attac)o(k)o(er)f(has)i(complete)d(con)o(trol)
+i(o)o(v)o(er)g(mac)o(hine)e(NS)1922 865 y Fm(B)149 948 y Fo(running)19
+b(a)g(legitimate)c(primary)i(name)g(serv)o(er)g(for)i(a)g(DNS)f(zone.)27
+b(This)18 b(strong)i(assumption)149 1039 y(do)q(es)g(not)f(alw)o(a)o(ys)g
+(need)f(to)h(b)q(e)g(satis\014ed.)30 b(It)18 b(is)h(simply)d(the)j(easiest)f
+(w)o(a)o(y)h(for)g(an)g(attac)o(k)o(er)f(if)149 1129 y(he)e(con)o(trols)f(a)h
+(primary)e(name)g(serv)o(er,)g(b)q(ecause)i(of)g(its)f(capabilities)g(and)h
+(the)f(fact)g(that)h(other)149 1219 y(mac)o(hines)f(b)q(eliev)o(e)f(name)h
+(serv)o(ers.)223 1309 y(Dep)q(ending)g(on)g(the)g(top)q(ology)i(of)e(a)g
+(real)g(net)o(w)o(ork)f(it)h(is)g(su\016cien)o(t)e(if)i(an)g(attac)o(k)o(er)g
+(con)o(trols)149 1400 y(one)i(of)f(the)g(authoritativ)o(e)f(name)g(serv)o
+(ers)g(for)h(the)g(particular)f(zone;)h(the)f(one)i(that)f(is)g(queried)149
+1490 y(\014rst)e(b)o(y)f(the)g(remote)e(resolv)o(er.)19 b(It)13
+b(is)g(not)h(m)o(uc)o(h)d(easier)i(for)g(an)h(attac)o(k)o(er)e(to)i(satisfy)f
+(this)g(second)149 1580 y(assumption)j(than)h(the)f(\014rst)h(one.)223
+1671 y(The)c(con)o(trol)f(m)o(ust)g(include)g(the)h(asso)q(ciated)h(in)o(v)o
+(erse)d(mapping)h(tree.)20 b(The)13 b(attac)o(k)o(er)f(migh)o(t)149
+1761 y(ha)o(v)o(e)j(successfully)g(sub)o(v)o(erted)g(suc)o(h)g(a)h(mac)o
+(hine)e(or)i(simply)e(b)q(e)h(a)i(renegade)e(system)g(adminis-)149
+1851 y(trator.)22 b(Both)17 b(ha)o(v)o(e)e(happ)q(ened)i(in)f(the)g(past)h
+(\(i.e.)j([Sto89,)c(Mad92)q(]\).)223 1941 y(W)l(e)f(can)h(relax)f(this)h
+(assumption)g(further.)k(If)c(an)g(attac)o(king)g(mac)o(hine)d(manages)j(to)g
+(some-)149 2032 y(ho)o(w)k(obtain)g(the)g(ID)f(n)o(um)o(b)q(er)f(of)i(a)g
+(curren)o(t)f(DNS)g(query)g(to)h(a)g(legitimate)d(name)h(serv)o(er,)h(it)149
+2122 y(could)h(run)g(some)e(co)q(de)i(\(e.g.)31 b(a)20 b(to)q(ol)g(that)g
+(constructs)g(the)f(resp)q(onse)h(pac)o(k)o(et)f(and)h(uses)g(the)149
+2212 y(source)e(route)f(option)g(to)h(send)f(it)g(to)g(the)g(originator)h(of)
+f(a)h(query\))e(to)h(answ)o(er)h(the)f(query)f(and)149 2303
+y(supply)j(additional)g(records)g(to)h(p)q(oison)g(the)f(cac)o(he.)28
+b(The)19 b(ID)g(n)o(um)o(b)q(er)e(prediction)h(could)h(b)q(e)149
+2393 y(based)h(on)f(previously)g(receiv)o(ed)d(queries)i(and)i(kno)o(wledge)e
+(on)i(ho)o(w)f(a)h(resolv)o(er)e(mo)q(di\014es)g(the)149 2483
+y(iden)o(ti\014er.)i(An)15 b(attac)o(k)h(based)g(on)h(TCP)f(sequence)f(n)o
+(um)o(b)q(er)f(prediction)h(to)i(construct)f(a)g(TCP)149 2573
+y(pac)o(k)o(et)h(sequence)f(that)h(allo)o(ws)h(an)f(attac)o(k)o(er)g(to)g(sp)
+q(o)q(of)i(a)f(trusted)f(host's)h(iden)o(tit)o(y)d(on)j(a)g(lo)q(cal)p
+eop
+%%Page: 39 48
+47 bop 1901 -100 a Fo(39)149 75 y(net)o(w)o(ork)17 b(w)o(as)h(describ)q(ed)e
+(in)h([Mor85)q(].)23 b(This)18 b(example)d(sho)o(ws)j(the)f(feasibilit)o(y)e
+(of)i(ID)g(n)o(um)o(b)q(er)149 165 y(prediction.)223 255 y(In)e(the)g(follo)o
+(wing)h(discussion)g(w)o(e)f(will)f(assume)h(that)i(the)e(attac)o(k)o(er)g
+(has)h(indeed)f(sup)q(eruser)149 346 y(access)22 b(to)f(a)h(primary)e(name)g
+(serv)o(er.)35 b(With)21 b(that)h(assumption)f(in)g(place)g(w)o(e)g(decrease)
+g(the)149 436 y(complexit)o(y)13 b(of)k(the)f(follo)o(wing)g(discussions.)149
+596 y(3.3.2)49 b(Authen)o(tication)15 b(via)h(Host)h(Names)223
+718 y(W)l(e)c(explained)g(in)g(the)h(in)o(tro)q(duction)f(that)h(users)g(ha)o
+(v)o(e)f(to)h(b)q(e)g(authorized)g(b)o(y)f(net)o(w)o(ork)g(ser-)149
+809 y(vice)k(pro)o(viders)h(b)q(efore)g(they)g(can)g(use)g(the)g(service.)26
+b(This)18 b(authen)o(tication)g(is)g(usually)g(based)149 899
+y(on)h(the)f(v)o(eri\014cation)f(of)h(the)g(user's)g(login)g(name)f(along)i
+(with)f(the)g(asso)q(ciated)h(passw)o(ord)h(and)149 989 y(the)e(host)h(name)e
+(of)i(the)f(mac)o(hine)e(on)i(whic)o(h)g(the)g(user)g(starts)h(his)f
+(requests.)27 b(Net)o(w)o(orks)17 b(ma)o(y)149 1079 y(b)q(e)d(classi\014ed)f
+(in)o(to)g(di\013eren)o(t)f(partitions)905 1061 y Fm(1)925
+1079 y Fo(:)20 b(Closed)14 b(Net)o(w)o(orks,)e(Op)q(en)i(Net)o(w)o(orks,)e
+(and)i(T)l(rusted)149 1170 y(Net)o(w)o(orks)k([PL91)q(].)26
+b(Closed)19 b(Net)o(w)o(orks)e(can)h(b)q(e)h(accessed)f(only)g(within)f
+(certain)h(b)q(oundaries.)149 1260 y(Sessions)f(are)g(con)o(trolled)e(and)i
+(secured)f(in)g(accordance)g(with)g(the)g(rules)g(implied)d(b)o(y)j(an)h
+(orga-)149 1350 y(nization's)i(business)h(goals.)31 b(In)19
+b(a)h(Closed)g(Net)o(w)o(ork,)e(the)h(lo)q(cation)h(of)g(all)e(resources)i
+(is)f(w)o(ell)149 1441 y(kno)o(wn)e(and)g(sp)q(eci\014ed.)223
+1531 y(Op)q(en)e(Net)o(w)o(orks)f(are)h(regions)h(separated)g(b)o(y)e(b)q
+(oundaries)j(from)d(their)g(surroundings,)i(but)149 1621 y(the)f(transfer)g
+(of)f(information)g(across)i(these)e(b)q(oundaries)h(is)g(admitted.)k(They)14
+b(are)h(augmen)o(ted)149 1711 y(b)o(y)g(publicly)f(accessible)g(parts)i(or)g
+(connections)f(to)h(net)o(w)o(orks)f(o)o(wned)h(b)o(y)e(other)i(companies)e
+(or)149 1802 y(organizations.)22 b(These)13 b(t)o(w)o(o)h(extensions)f(mak)o
+(e)f(this)h(t)o(yp)q(e)g(of)h(net)o(w)o(ork)f(vulnerable)f(to)i(external)149
+1892 y(threats.)223 1982 y(T)l(rusted)j(Net)o(w)o(orks)g(in)o(tro)q(duce)g
+(the)g(concept)h(that)f(net)o(w)o(ork)g(access)h(is)f(con)o(trolled)g(at)h
+(the)149 2073 y(en)o(try)k(no)q(de.)40 b(In)22 b(the)h(case)f(of)h(large)f
+(in)o(ternational)g(net)o(w)o(orks,)h(main)o(tainabilit)o(y)c(and)k(con-)149
+2163 y(trollabilit)o(y)17 b(are)h(imp)q(ortan)o(t)g(issues.)27
+b(Adopting)19 b(the)f(T)l(rusted)g(Net)o(w)o(ork)f(concept)h(allo)o(ws)h(the)
+149 2253 y(decomp)q(osition)13 b(of)g(a)h(large)f(net)o(w)o(ork,)g(gro)o
+(wing)h(to)o(w)o(ards)g(an)g(unmanageable)f(complexit)o(y)-5
+b(,)11 b(in)o(to)149 2343 y(relativ)o(ely)h(small)h(national)h(or)h(regional)
+f(net)o(w)o(orks,)g(eac)o(h)g(supp)q(orted)h(b)o(y)f(lo)q(cal)g(sta\013,)h
+(and)g(eac)o(h)149 2434 y(pro)o(vided)h(with)g(its)g(o)o(wn)g(net)o(w)o(ork)g
+(access)g(con)o(trol.)21 b(The)16 b(adv)m(an)o(tages)i(are)e(increased)g(con)
+o(trol-)149 2524 y(labilit)o(y)l(,)e(main)o(tainabilit)o(y)l(,)e
+(manageabilit)o(y)l(,)i(and)i(simpli\014cation)e(of)i(c)o(hange)g(managemen)o
+(t.)j(A)p 149 2568 720 2 v 206 2598 a Fl(1)224 2613 y Fk(A)14
+b(v)o(ery)g(similar)e(classi\014cation)h(is)h(applicable)f(to)h(systems)g(in)
+f(general.)p eop
+%%Page: 40 49
+48 bop 1901 -100 a Fo(40)149 75 y(T)l(rusted)12 b(Net)o(w)o(ork)f(can)h(b)q
+(e)g(regarded)g(globally)g(as)g(a)g(single)g(Closed)g(Net)o(w)o(ork,)f(but)h
+(from)e(a)j(lo)q(cal)149 165 y(p)q(oin)o(t)j(of)g(view,)f(the)h(in)o
+(terconnected)e(net)o(w)o(orks)h(stand)i(widely)d(op)q(en)j(with)f(all)f(the)
+g(applicable)149 255 y(securit)o(y)g(threats.)223 346 y(The)f(In)o(ternet)f
+(is)i(a)g(system)e(of)i(T)l(rusted)g(Net)o(w)o(orks)e(within)h(Op)q(en)h(Net)
+o(w)o(orks.)20 b(This)14 b(allo)o(ws)149 436 y(the)20 b(danger)f(that)h(once)
+f(someone)g(has)h(falsely)e(gained)i(access)f(to)h(one)f(mac)o(hine,)f(it)h
+(is)g(m)o(uc)o(h)149 526 y(simpler)12 b(to)i(sub)o(v)o(ert)e(others.)21
+b(Within)13 b(T)l(rusted)h(Net)o(w)o(orks)f(users)h(are)f(authen)o(ticated)g
+(solely)g(b)o(y)149 616 y(their)j(login)h(name)e(and)i(connecting)f(host)h
+(name.)k(The)c(login)f(name)g(is)g(sp)q(eci\014ed)g(b)o(y)g(the)g(con-)149
+707 y(necting)h(site,)e(and)j(therefore)e(can)g(b)q(e)h(falsi\014ed,)f(suc)o
+(h)h(that)g(the)f(only)h(\\reliable")f(information)149 797
+y(left)c(for)h(the)g(addressed)g(mac)o(hine)d(is)j(the)f(connecting)g(mac)o
+(hine's)f(IP)h(address)22 b(that)13 b(is)f(pro)o(vided)149
+887 y(b)o(y)17 b(an)h(op)q(erating)g(system)e(call.)24 b(The)17
+b(addressed)h(mac)o(hine)d(then)i(maps)g(the)g(IP)g(address)h(in)o(to)149
+978 y(a)e(host)g(name)e(using)i(the)f(Domain)f(Name)g(System.)19
+b(If)c(an)g(attac)o(k)o(er)g(manages)g(to)g(sub)o(v)o(ert)g(this)149
+1068 y(name)g(binding)h(call,)f(he)h(can)g(falsify)g(the)f(name)g(of)i(a)f
+(mac)o(hine)e(within)i(the)f(T)l(rusted)i(Net)o(w)o(ork)149
+1158 y(and)g(therefore)f(succeed)f(in)h(his)g(attac)o(k.)149
+1318 y(3.3.3)49 b(T)l(rusting)17 b(a)g(Not)f(T)l(rust)o(w)o(orth)o(y)g
+(Source)223 1441 y(Using)i(the)g(Domain)g(Name)f(System)g(to)i(map)e(the)i
+(IP)f(address)h(pro)o(vided)f(b)o(y)g(lo)o(w)o(er)g(lev)o(el)149
+1531 y(proto)q(col)i(la)o(y)o(ers)d(in)o(to)h(the)g(applicable)f(host)i
+(name,)f(the)g(addressed)h(host)g(blindly)e(trusts)i(the)149
+1621 y(information)e(that)h(is)f(pro)o(vided)g(b)o(y)g(the)g(Domain)g(Name)e
+(System.)23 b(Information)17 b(that)h(comes)149 1711 y(from)f(sources)g
+(outside)h(of)f(the)g(trusted)g(area)h(is)f(trusted.)25 b(That)18
+b(is)f(a)g(sev)o(ere)f(violation)h(of)h(the)149 1802 y(partitioning)f
+(concept.)k(Only)15 b(truly)h(authoritativ)o(e)f(information)h(should)g(b)q
+(e)h(trusted.)149 1962 y(3.3.4)49 b(Believing)15 b(Additional,)g(Not)h
+(Authoritativ)o(e)f(Information)223 2084 y(E\016ciency)i(is)i(one)h(of)f(the)
+g(stated)h(goals)g(of)g(the)f(Domain)g(Name)e(System,)h(as)i(w)o(e)f(sa)o(w)h
+(in)149 2174 y(Section)13 b(2.3.2.)20 b(The)13 b(DNS)g(pac)o(k)o(et)f(con)o
+(tains)h(an)h(additional)f(answ)o(er)g(section)g(\(see)f(Figure)h(2.3\),)149
+2265 y(where)19 b(name)f(serv)o(ers)g(can)h(pro)o(vide)f(resource)h(records)g
+(con)o(taining)f(information)g(that)i(could)149 2355 y(come)c(in)h(handy)h
+(in)f(future)g(requests,)g(but)h(that)g(w)o(ere)e(not)i(explicitly)d
+(requested.)23 b(There)17 b(are)149 2445 y(situations)f(where)g(these)f
+(additional)g(records)h(yield)e(in)h(system)f(e\016ciency)l(,)f(for)j
+(example)e(after)149 2536 y(the)h(lo)q(okup)h(of)g(\\NS")f(records)g(when)h
+(\\A")f(records)g(sp)q(ecifying)g(the)g(addresses)g(of)h(the)f(queried)149
+2626 y(name)k(serv)o(ers)f(are)i(found)g(in)f(the)g(additional)h(answ)o(er)f
+(section.)31 b(That)20 b(sa)o(v)o(es)f(the)g(lo)q(okup)h(of)p
+eop
+%%Page: 41 50
+49 bop 1901 -100 a Fo(41)149 75 y(the)18 b(IP)g(addresses,)g(once)f(the)h
+(name)f(of)h(the)f(applicable)g(name)g(serv)o(er)f(is)i(found.)26
+b(Additional)149 165 y(resource)16 b(records)h(are)f(cac)o(hed)f(for)i
+(future)f(use.)223 255 y(As)j(w)o(e)g(rely)f(on)i(the)f(correctness)g(of)h
+(these)f(additional)h(records)f(once)g(w)o(e)g(use)h(them,)e(w)o(e)149
+346 y(trust)23 b(information)e(that)h(comes)f(from)g(a)h(source)g(p)q
+(ossibly)g(outside)g(of)h(the)e(trusted)h(scop)q(e.)149 436
+y(That)17 b(is)f(another)h(violation)f(of)h(the)f(partitioning)g(concept.)149
+601 y(3.4)50 b(Exploiting)15 b(the)h(Fla)o(ws)223 741 y(The)21
+b(follo)o(wing)h(sections)f(are)h(the)g(most)f(concrete)g(description)g(of)h
+(ho)o(w)g(to)g(exploit)f(the)149 831 y(securit)o(y)f(\015a)o(w)g(in)h(the)f
+(Domain)g(Name)f(System.)32 b(In)20 b(this)h(c)o(hapter)f(w)o(e)g(concen)o
+(trate)g(on)h(the)149 921 y(\\rlogin")16 b(command)e(of)h(Berk)o(eley)e
+(UNIX.)g(W)l(e)i(do)g(not)h(explain)f(the)g(whole)g(\\rlogin")h(proto)q(col)
+149 1012 y(in)g(detail,)f(but)i(only)f(state)g(the)g(parts)h(and)g(commands)e
+(that)h(are)g(related)g(to)h(our)f(in)o(terest.)149 1172 y(3.4.1)49
+b(Regular)17 b(Access)780 1414 y(T)l(able)f(3.1)33 b(Regular)16
+b(access)451 1491 y(host)h(NS)621 1498 y Fm(A)665 1491 y Fo(\()p
+Fh(rlogind)p Fo(\))p 1223 1518 2 91 v 408 w(Bob@H)1409 1498
+y Fm(A)p 426 1520 1247 2 v 1223 1610 2 91 v 1248 1583 a Fg(rlogin)f
+Fo(NS)1450 1590 y Fm(A)1495 1583 y Fg(-l)g(Alice)451 1673 y
+Ff(getpeernam)o(e\(\))c Fj(!)k Fo(IP)917 1680 y Fm(H)943 1686
+y Fe(A)p 1223 1701 V 451 1764 a Ff(gethostbya)o(ddr)o(\()p
+Fo(I)o(P)861 1771 y Fm(H)887 1777 y Fe(A)913 1764 y Ff(\))g
+Fj(!)g Fo(H)1058 1771 y Fm(A)p 1223 1791 V 451 1854 a Fo(\014nd)g(en)o(try)g
+(H)713 1861 y Fm(A)767 1854 y Ff(Bob)f Fo(in)h Fh(~Alice/.rhosts)p
+1223 1881 V 451 1944 a Fo(gran)o(t)h(access)p 1223 1971 V 223
+2230 a(T)l(able)g(3.1)h(giv)o(es)f(the)h(pro)q(cedure)g(follo)o(w)o(ed)e
+(during)i(a)g(regular)g(remote)e(login.)26 b(Time)16 b(pro-)149
+2321 y(ceeds)j(from)e(top)i(to)g(b)q(ottom)g(of)g(the)f(table.)28
+b(User)19 b(Bob)f(on)i(mac)o(hine)c(H)1536 2328 y Fm(A)1583
+2321 y Fo(w)o(an)o(ts)j(to)g(log)g(in)o(to)149 2411 y(mac)o(hine)g(NS)409
+2418 y Fm(A)437 2411 y Fo(.)36 b(The)21 b(underlying)f(proto)q(cols)i(create)
+f(a)g(connection)g(b)q(et)o(w)o(een)f(the)h(\\rlogin")149 2501
+y(program)d(and)h(the)e(\\rlogind")i(daemon.)26 b(During)18
+b(the)f(authen)o(tication)h(pro)q(cess)g(the)g(daemon)149 2592
+y(retriev)o(es)f(the)g(IP)h(address)h(of)f(the)g(connecting)g(mac)o(hine:)k
+(IP)1330 2599 y Fm(H)1356 2605 y Fe(A)1383 2592 y Fo(.)27 b(It)17
+b(then)h(uses)g(the)g(Domain)p eop
+%%Page: 42 51
+50 bop 1901 -100 a Fo(42)149 75 y(Name)12 b(System)f(to)j(map)e(this)h
+(address)g(to)h(a)f(host)h(name.)19 b(The)13 b(call)f(of)i(\\gethostb)o(y)o
+(addr\(IP)1853 82 y Fm(H)1879 88 y Fe(A)1906 75 y Fo(\)")149
+165 y(do)q(es)j(that)g(and)g(returns)f(H)665 172 y Fm(A)693
+165 y Fo(.)223 255 y(The)21 b(daemon)f(then)h(c)o(hec)o(ks)f(whether)h(the)f
+(user)i(from)e(the)h(mac)o(hine)d(with)j(name)f(H)1867 262
+y Fm(A)1917 255 y Fo(is)149 346 y(allo)o(w)o(ed)k(access)g(b)o(y)g(scanning)h
+(the)f(en)o(tries)f(in)i(the)f(\\.rhosts")h(\014le)f(of)h(user)f(Alice.)44
+b(If)24 b(the)149 436 y(appropriate)19 b(en)o(try)d(is)i(found,)g(access)f
+(is)g(gran)o(ted.)26 b(If)17 b(the)g(system)f(administrator)h(of)h(system)149
+526 y(NS)213 533 y Fm(A)258 526 y Fo(has)f(installed)f(the)g
+(\\/etc/hosts.equiv")g(\014le)g(and)h(en)o(tered)e(the)i(name)e(of)h(host)i
+(H)1797 533 y Fm(A)1825 526 y Fo(,)e(then)149 616 y(access)h(is)f(gran)o(ted)
+g(ev)o(en)f(without)i(a)f(user)h(main)o(tained)d(en)o(try)h(in)h(\014le)g
+(\\.rhosts.")149 778 y(3.4.2)49 b(The)17 b(\\Database)h(Mo)q(di\014cation")f
+(Approac)o(h)514 1014 y(T)l(able)g(3.2)32 b(The)17 b(\\Database)h(Mo)q
+(di\014cation")f(approac)o(h)451 1091 y(host)g(NS)621 1098
+y Fm(A)665 1091 y Fo(\()p Fh(rlogind)p Fo(\))p 1223 1118 2
+91 v 408 w(Bob@H)1409 1098 y Fm(B)p 426 1120 1247 2 v 1223
+1210 2 91 v 1248 1183 a Fg(rlogin)f Fo(NS)1450 1190 y Fm(A)1495
+1183 y Fg(-l)g(Alice)451 1273 y Ff(getpeernam)o(e\(\))c Fj(!)k
+Fo(IP)917 1280 y Fm(H)943 1286 y Fe(B)p 1223 1301 V 451 1364
+a Ff(gethostbya)o(ddr)o(\()p Fo(I)o(P)861 1371 y Fm(H)887 1377
+y Fe(B)912 1364 y Ff(\))g Fj(!)g Fo(H)1057 1371 y Fm(A)p 1223
+1391 V 451 1454 a Fo(\014nd)g(en)o(try)g(H)713 1461 y Fm(A)767
+1454 y Ff(Bob)f Fo(in)h Fh(~Alice/.rhosts)p 1223 1481 V 451
+1544 a Fo(gran)o(t)h(access)p 1223 1571 V 223 1824 a(This)f(is)h(the)f
+(\014rst)h(example)d(of)j(ho)o(w)g(an)h(attac)o(k)o(er)d(can)i(sp)q(o)q(of)h
+(someone)e(else's)g(host)h(name.)149 1914 y(Host)22 b(H)307
+1921 y Fm(B)355 1914 y Fo(b)q(eha)o(v)o(es)e(as)i(if)f(it)g(w)o(ere)f(host)i
+(H)975 1921 y Fm(A)1003 1914 y Fo(.)36 b(The)21 b(access)h(pattern)f(is)g(v)o
+(ery)f(similar)f(to)j(the)149 2005 y(previous,)g(regular)f(one,)h(except)e
+(that)h(the)g(call)f(of)h(\\getp)q(eername\(\)")g(no)o(w)g(returns)g(the)g
+(IP)149 2095 y(address)i(of)f(host)h(H)539 2102 y Fm(B)566
+2095 y Fo(.)38 b(If)21 b(the)h(DNS)g(database)h(is)f(mo)q(di\014ed)e(b)o(y)i
+(the)f(attac)o(k)o(er,)h(the)g(call)f(of)149 2185 y(\\gethostb)o(y)o
+(addr\(\)")g(do)q(es)f(not)f(return)g(the)g(name)f(H)1169 2192
+y Fm(B)1215 2185 y Fo(as)h(it)g(w)o(ould)g(with)g(a)h(database)g(in)f(an)149
+2276 y(unimpaired)c(state,)h(but)g(the)g(name)f(H)880 2283
+y Fm(A)908 2276 y Fo(.)22 b(Bob@H)1105 2283 y Fm(B)1148 2276
+y Fo(\014nally)15 b(gets)i(access)f(to)h(NS)1663 2283 y Fm(A)1692
+2276 y Fo(.)149 2437 y(3.4.3)49 b(The)17 b(\\Cac)o(he)f(P)o(oisoning")h
+(Approac)o(h)223 2560 y(In)j(this)h(approac)o(h)g(the)g(\\rlogind")g(daemon)f
+(tries)h(to)g(enhance)f(securit)o(y)f(b)o(y)i(calling)f(the)149
+2650 y(function)g(\\gethostb)o(yname\(\)")f(to)g(v)o(erify)f(the)h(mapping)g
+(from)f(IP)1431 2657 y Fm(H)1457 2663 y Fe(B)1502 2650 y Fo(to)h(H)1601
+2657 y Fm(A)1630 2650 y Fo(.)30 b(The)19 b(attac)o(k)o(er)p
+eop
+%%Page: 43 52
+51 bop 1901 -100 a Fo(43)580 101 y(T)l(able)16 b(3.3)33 b(The)16
+b(\\Cac)o(he)h(P)o(oisoning")g(approac)o(h)451 178 y(host)g(NS)621
+185 y Fm(A)665 178 y Fo(\()p Fh(rlogind)p Fo(\))p 1223 205
+2 91 v 408 w(Bob@H)1409 185 y Fm(B)p 426 207 1247 2 v 1223
+297 2 91 v 1248 270 a Fg(rlogin)f Fo(NS)1450 277 y Fm(A)1495
+270 y Fg(-l)g(Alice)451 360 y Ff(getpeernam)o(e\(\))c Fj(!)k
+Fo(IP)917 367 y Fm(H)943 373 y Fe(B)p 1223 387 V 451 451 a
+Ff(gethostbya)o(ddr)o(\()p Fo(I)o(P)861 458 y Fm(H)887 464
+y Fe(B)912 451 y Ff(\))g Fj(!)g Fo(H)1057 458 y Fm(A)p 1223
+478 V 516 541 a Fo(and)h(H)648 548 y Fm(A)692 541 y Fj(!)f
+Fo(IP)809 548 y Fm(H)835 554 y Fe(B)877 541 y Fo(mapping)p
+1223 568 V 451 631 a Ff(gethostbyn)o(ame)o(\()p Fo(H)849 638
+y Fm(A)875 631 y Ff(\))g Fj(!)g Fo(IP)1034 638 y Fm(H)1060
+644 y Fe(B)p 1223 658 V 451 721 a Fo(\014nd)g(en)o(try)g(H)713
+728 y Fm(A)767 721 y Ff(Bob)f Fo(in)h Fh(~Alice/.rhosts)p 1223
+749 V 451 812 a Fo(gran)o(t)h(access)p 1223 839 V 149 1067
+a(ho)o(w)o(ev)o(er)i(has)i(a)g(w)o(a)o(y)f(of)h(sub)o(v)o(erting)e(this)h
+(additional)h(securit)o(y)d(feature.)33 b(He)20 b(can)g(send)h(the)149
+1157 y(additional)d(mapping)e(of)i(H)676 1164 y Fm(A)721 1157
+y Fo(to)f(IP)832 1164 y Fm(H)858 1170 y Fe(B)901 1157 y Fo(along)h(with)f
+(the)g(answ)o(er)g(to)h(the)f(query)f(for)i(IP)1799 1164 y
+Fm(H)1825 1170 y Fe(B)1851 1157 y Fo(.)24 b(By)149 1248 y(the)17
+b(time)d(the)i(daemon)g(calls)g(\\gethostb)o(yname\(\),")f(it)h(already)h
+(has)g(the)f(necessary)g(mapping)149 1338 y(information)g(in)g(its)g(cac)o
+(he.)22 b(The)16 b(daemon)g(b)q(eliev)o(es)f(the)h(cac)o(hed)g(data)h(and)g
+(again)g(gran)o(ts)h(the)149 1428 y(attac)o(k)o(er)e(access.)149
+1588 y(3.4.4)49 b(The)17 b(\\Ask)f(Me!")21 b(Approac)o(h)223
+1711 y(In)16 b(the)g(previous)g(sections)h(w)o(e)f(exploited)f(the)h(securit)
+o(y)f(w)o(eakness)h(of)h(the)f(Domain)g(Name)149 1801 y(System)f(according)i
+(to)f(S.)g(Bello)o(vin's)e(suggestions.)223 1891 y(W)l(e)i(though)o(t)h(of)g
+(another)h(w)o(a)o(y)e(to)h(exploit)f(the)g(w)o(eakness.)23
+b(If)16 b(some)g(en)o(tit)o(y)f(sen)o(t)h(a)h(source)149 1982
+y(routed)e(datagram,)f(con)o(taining)g(a)h(DNS)f(message)f(with)h(false)g
+(additional)g(resource)g(records)g(to)149 2072 y(a)i(name)e(serv)o(er,)g(w)o
+(ould)h(that)h(name)e(serv)o(er)g(accept)h(the)g(data?)22 b(The)15
+b(idea)g(here)g(is)g(to)h(p)q(oison)g(a)149 2162 y(name)h(serv)o(er's)f(cac)o
+(he)g(with)i(all)f(necessary)g(information)f(\(for)i(rev)o(erse)e(and)i(forw)
+o(ard)g(lo)q(okup\))149 2252 y(b)q(efore)f(the)f(\\rlogin")h(attac)o(k)f(is)g
+(launc)o(hed.)223 2343 y(W)l(e)21 b(will)f(explain)g(in)h(Section)g(4.1)h(wh)
+o(y)f(this)g(cannot)h(w)o(ork)f(using)h(source)f(routed)h(DNS)149
+2433 y(messages)14 b(directly)l(.)19 b(This)c(depriv)o(es)e(us)i(of)g(the)f
+(c)o(hance)g(of)h(eliminating)d(the)i(basic)h(assumption)149
+2523 y(of)g(the)f(attac)o(k)o(er)f(ha)o(ving)h(sup)q(eruser)h(priorit)o(y)e
+(on)i(a)f(primary)f(name)g(serv)o(er)g(in)h(order)g(to)h(launc)o(h)149
+2614 y(an)i(attac)o(k.)p eop
+%%Page: 44 53
+52 bop 1901 -100 a Fo(44)223 75 y(Nev)o(ertheless,)13 b(the)j(idea)g(can)h(b)
+q(e)f(exploited)f(in)h(another)h(w)o(a)o(y)l(,)e(on)i(a)g(higher)f(lev)o(el,)
+d(and)k(far)149 165 y(more)c(elegan)o(tly)f(than)i(creating)g(and)g(sending)g
+(datagrams)g(man)o(ually)l(.)k(Imagine)12 b(the)i(follo)o(wing)149
+255 y(scenario:)223 346 y(The)j(attac)o(k)o(er)f(on)i(name)e(serv)o(er)g(NS)
+918 353 y Fm(B)963 346 y Fo(whishes)h(to)g(giv)o(e)g(NS)1368
+353 y Fm(A)1414 346 y Fo(wrong)h(information)e(ab)q(out)149
+436 y(the)g(mappings)222 568 y Fj(\017)24 b Fo(IP)322 575 y
+Fm(H)348 581 y Fe(B)390 568 y Fj(!)16 b Fo(H)493 575 y Fm(B)520
+568 y Fo(.sub.domain.dom)149 699 y(and)222 831 y Fj(\017)24
+b Fo(H)308 838 y Fm(B)335 831 y Fo(.sub.domain.dom)14 b Fj(!)i
+Fo(IP)831 838 y Fm(H)857 844 y Fe(B)883 831 y Fo(.)149 963
+y(NS)213 970 y Fm(B)256 963 y Fo(w)o(an)o(ts)h(NS)459 970 y
+Fm(A)503 963 y Fo(to)g(b)q(eliev)o(e)d(the)i(mappings)222 1095
+y Fj(\017)24 b Fo(IP)322 1102 y Fm(H)348 1108 y Fe(B)390 1095
+y Fj(!)16 b Fo(H)493 1102 y Fm(A)521 1095 y Fo(.domain.dom)149
+1227 y(and)222 1358 y Fj(\017)24 b Fo(H)308 1365 y Fm(A)336
+1358 y Fo(.domain.dom)14 b Fj(!)i Fo(IP)746 1365 y Fm(H)772
+1371 y Fe(B)798 1358 y Fo(.)223 1490 y(As)21 b(NS)363 1497
+y Fm(B)412 1490 y Fo(cannot)g(simply)f(send)h(the)g(false)g(information)f(to)
+i(NS)1455 1497 y Fm(A)1513 1490 y Fo(it)f(could)g(ask)h(NS)1856
+1497 y Fm(A)1906 1490 y Fo(to)149 1581 y(resolv)o(e)14 b(a)h(mapping)f(that)h
+(only)f(NS)819 1588 y Fm(B)861 1581 y Fo(can)h(resolv)o(e.)k(NS)1191
+1588 y Fm(B)1232 1581 y Fo(w)o(ould)c(then)g(app)q(end)g(the)f(additional)149
+1671 y(incorrect)j(information)g(to)i(the)f(resp)q(onse)h(to)f(NS)1092
+1678 y Fm(A)1120 1671 y Fo('s)g(query)l(.)26 b(Doing)18 b(so,)h(NS)1611
+1678 y Fm(A)1639 1671 y Fo('s)f(cac)o(he)f(w)o(ould)149 1761
+y(b)q(e)h(p)q(oisoned)h(with)e(the)g(necessary)h(information)e(to)i(allo)o(w)
+f(H)1326 1768 y Fm(B)1371 1761 y Fo(to)h(imp)q(ersonate)e(H)1745
+1768 y Fm(A)1791 1761 y Fo(and)i(log)149 1851 y(in)o(to)e(NS)312
+1858 y Fm(A)341 1851 y Fo(.)223 1942 y(W)l(e)i(call)g(this)h(the)g(\\Ask)g
+(Me!")29 b(approac)o(h,)20 b(b)q(ecause)f(name)f(serv)o(er)g(NS)1596
+1949 y Fm(B)1642 1942 y Fo(implici)o(tly)d(tells)149 2032 y(name)21
+b(serv)o(er)f(NS)495 2039 y Fm(A)545 2032 y Fo(to)i(send)g(a)g(query)f(to)h
+(NS)1043 2039 y Fm(B)1070 2032 y Fo(.)37 b(NS)1185 2039 y Fm(B)1234
+2032 y Fo(therefore)21 b(tells)f(NS)1616 2039 y Fm(A)1666 2032
+y Fo(to)i(ask)g(him)e(a)149 2122 y(question.)223 2213 y(W)l(e)15
+b(did)h(not)h(implem)o(e)o(n)o(t)c(this)j(attac)o(k.)21 b(Using)16
+b(the)f(standard)j(to)q(ol)e(\\nslo)q(okup,")i(NS)1833 2220
+y Fm(B)1876 2213 y Fo(can)149 2303 y(force)i(NS)335 2310 y
+Fm(A)383 2303 y Fo(to)h(create)e(a)i(query)l(,)f(and)g(using)h(the)f(name)f
+(serv)o(er)g(mo)q(di\014cations)g(describ)q(ed)h(in)149 2393
+y(3.5.6,)c(NS)343 2400 y Fm(B)386 2393 y Fo(can)g(app)q(end)h(the)f(t)o(w)o
+(o)g(false)g(resource)f(records)h(to)h(the)f(additional)g(section)f(of)i(the)
+149 2483 y(resp)q(onse)g(to)g(the)f(query)l(.)p eop
+%%Page: 45 54
+53 bop 1901 -100 a Fo(45)149 75 y(3.5)50 b(Implem)o(e)o(n)o(tation)14
+b(and)j(Exp)q(erimen)o(ts)223 214 y(This)24 b(section)g(describ)q(es)f(our)i
+(main)e(exp)q(erimen)o(t)e(step)j(b)o(y)f(step.)45 b(W)l(e)24
+b(start)h(with)f(the)149 305 y(description)12 b(of)g(the)f(setup)h(of)g(our)g
+(test)g(zones)g(and)g(the)f(mac)o(hines)f(used.)20 b(W)l(e)12
+b(con)o(tin)o(ue)e(with)i(the)149 395 y(name)k(serv)o(er)f(and)i(resolv)o(er)
+e(setups.)21 b(The)16 b(UNIX)f(concept)h(of)g(trusted)h(hosts)g(is)f
+(fundamen)o(tal)149 485 y(in)j(exploiting)f(this)h(\015a)o(w.)30
+b(W)l(e)19 b(explain)f(this)h(particular)g(instance)f(of)i(the)e(T)l(rusted)i
+(Net)o(w)o(ork)149 575 y(concept)h(follo)o(w)o(ed)g(b)o(y)g(the)g(authen)o
+(tication)g(pro)q(cess)h(using)g(the)f(Berk)o(eley)e(\\r{commands.")149
+666 y(Then)j(w)o(e)e(describ)q(e)h(the)g(manipulation)f(in)g(the)h
+(authoritativ)o(e)g(data)h(of)f(the)g(name)f(serv)o(er's)149
+756 y(rev)o(erse)14 b(lo)q(okup)i(tree.)k(W)l(e)15 b(also)h(describ)q(e)e
+(the)h(\014nal)g(step,)g(the)g(cac)o(he)g(corruption,)g(in)g(the)f(case)149
+846 y(that)j(the)f(Berk)o(eley)e(patc)o(h)i(is)g(already)g(installed.)149
+1006 y(3.5.1)49 b(Domain)16 b(and)h(Zone)f(Setup)223 1129 y(The)i(setup)h(of)
+g(our)h(exp)q(erimen)o(tal)15 b(\014eld)k(consisted)f(of)h(t)o(w)o(o)g(zones)
+g(\(see)f(Figure)h(3.1\).)29 b(All)149 1219 y(mac)o(hines,)21
+b(the)h(attac)o(k)o(ed)f(mac)o(hine)f(NS)933 1226 y Fm(A)961
+1219 y Fo(,)j(the)f(imitated)d(mac)o(hine)h(H)1522 1226 y Fm(A)1550
+1219 y Fo(,)j(and)g(the)e(attac)o(k)o(er)149 1309 y(mac)o(hines)13
+b(NS)422 1316 y Fm(B)463 1309 y Fo(and)i(H)593 1316 y Fm(B)620
+1309 y Fo(,)f(w)o(ere)g(part)h(of)g(the)f(domain)g(sub.domain.dom.)19
+b(Ho)o(w)o(ev)o(er,)12 b(NS)1828 1316 y Fm(A)1871 1309 y Fo(and)149
+1400 y(H)186 1407 y Fm(A)231 1400 y Fo(con)o(tacted)k(another)g(name)g(serv)o
+(er)f(\(NS)984 1407 y Fm(A)1013 1400 y Fo(\))h(than)h(NS)1226
+1407 y Fm(B)1269 1400 y Fo(and)g(H)1401 1407 y Fm(B)1444 1400
+y Fo(\(NS)1526 1407 y Fm(B)1553 1400 y Fo(\).)223 1490 y(In)g(realit)o(y)g
+(the)h(attac)o(k)o(er)f(and)i(attac)o(k)o(ed)e(hosts)i(w)o(ould)f(not)h
+(reside)e(in)h(the)g(same)f(domain,)149 1580 y(but)25 b(b)q(ecause)f(w)o(e)f
+(are)h(solely)f(observing)h(the)g(Domain)f(Name)f(System)h(proto)q(col)h(b)q
+(et)o(w)o(een)149 1671 y(name)15 b(serv)o(ers,)g(it)g(did)g(not)i(mak)o(e)d
+(a)i(di\013erence)e(as)j(long)f(as)g(the)g(authoritativ)o(e)f(data)i(that)f
+(had)149 1761 y(to)j(b)q(e)f(corrupted)h(remained)d(in)i(the)g(attac)o(king)g
+(name)f(serv)o(er's)g(zone,)h(outside)g(the)g(attac)o(k)o(ed)149
+1851 y(mac)o(hine's)c(zone.)149 2011 y(3.5.2)49 b(Name)15 b(Serv)o(er)g(and)i
+(Resolv)o(er)e(Setup)223 2134 y(Name)i(serv)o(er)h(NS)573 2141
+y Fm(A)621 2134 y Fo(w)o(as)h(set)g(up)h(to)f(con)o(tain)g(primary)f
+(information)g(ab)q(out)i(the)f(domain)149 2224 y(domain.dom,)k(whereas)h
+(name)e(serv)o(er)g(NS)992 2231 y Fm(B)1043 2224 y Fo(con)o(tained)h(primary)
+f(information)g(ab)q(out)j(the)149 2314 y(domain)e(sub.domain.dom.)41
+b(The)24 b(resolv)o(ers)f(of)g(NS)1177 2321 y Fm(A)1229 2314
+y Fo(and)h(NS)1395 2321 y Fm(B)1446 2314 y Fo(w)o(ere)e(set)i(up)g(to)g(con)o
+(tact)149 2404 y(the)19 b(name)f(serv)o(ers)h(running)g(on)h(the)f(lo)q(cal)g
+(hosts)h(exclusiv)o(ely)l(.)27 b(This)19 b(k)o(ept)g(the)g(information)149
+2495 y(requests)d(on)h(con)o(trollable,)e(w)o(ell{kno)o(wn)g(paths.)p
+eop
+%%Page: 46 55
+54 bop 1901 -100 a Fo(46)149 75 y(3.5.3)49 b(T)l(rusting)17
+b(Hosts)223 197 y(In)f(Berk)o(eley)e(UNIX)h(and)i(deriv)m(ativ)o(es,)d
+(system)i(administrators)g(and)h(users)g(ha)o(v)o(e)e(the)i(op-)149
+287 y(tion)i(to)g(trust)g(other)f(systems,)f(or)i(to)g(trust)g(certain)f
+(user)g(accoun)o(ts)h(on)g(remote)e(systems)g(b)o(y)149 378
+y(pro)o(viding)11 b(a)h(\\remote)e(authen)o(tication")i(database.)21
+b(W)l(e)11 b(in)o(tro)q(duced)g(\\trust")h(in)g(section)f(3.3.2.)149
+468 y(The)20 b(\\/etc/hosts.equiv")g(\014le)f(applies)g(to)h(the)g(en)o(tire)
+e(system,)g(while)h(individual)f(users)i(can)149 558 y(main)o(tain)15
+b(their)h(o)o(wn)g(\\.rhosts")i(\014les)d(in)h(their)g(home)f(directories.)
+223 649 y(The)h(\014le)g(\\/etc/hosts.equiv")g(is)g(main)o(tainable)e(only)j
+(b)o(y)e(the)h(sup)q(eruser.)22 b(It)16 b(can)h(con)o(tain)149
+739 y(host)j(names)f(from)f(whic)o(h)g(users)i(can)f(remotely)e(access)i(lo)q
+(cal)g(accoun)o(ts)g(without)h(ha)o(ving)f(to)149 829 y(pro)o(vide)h(a)g
+(passw)o(ord)i(for)e(authen)o(tication.)32 b(The)20 b(user)h(has)f(to)h(ha)o
+(v)o(e)e(the)h(same)f(login)h(id)g(on)149 919 y(b)q(oth)g(mac)o(hines.)27
+b(Access)18 b(is)g(gran)o(ted)h(on)g(basis)h(of)f(the)f(login)h(name)e(and)j
+(the)e(host)i(name)d(of)149 1010 y(the)f(connecting)g(mac)o(hine.)223
+1100 y(Eac)o(h)h(user)g(can)h(create)e(a)i(\014le)f(named)f(\\.rhosts")i(in)f
+(his)g(home)g(directory)l(.)23 b(In)17 b(this)g(\014le)g(he)149
+1190 y(can)g(sp)q(ecify)f(trusted)g(users)h(on)g(other)g(mac)o(hines.)j(It)c
+(is)g(also)i(p)q(ossible)e(to)h(force)f(remote)f(users)149
+1281 y(to)k(alw)o(a)o(ys)f(supply)g(a)h(passw)o(ord)g(when)g(using)f(the)g
+(\\r{commands,")g(b)o(y)g(pre\014xing)g(en)o(tries)f(in)149
+1371 y(\\.rhosts")h(b)o(y)e(a)g(dash.)271 1515 y(These)d(\014les)g(b)o(ypass)
+g(the)f(standard)i(passw)o(ord-based)h(user)e(authen)o(tication)g(mec)o(h-)
+271 1605 y(anism.)25 b(T)l(o)19 b(main)o(tain)d(system)g(securit)o(y)l(,)h
+(care)g(m)o(ust)g(b)q(e)g(tak)o(en)h(in)f(creating)h(and)271
+1696 y(main)o(taining)d(these)h(\014les.)21 b([Sun91,)16 b(HOSTS.EQUIV\(5\)])
+223 1840 y(These)22 b(features)g(ha)o(v)o(e)f(caused)i(man)o(y)d(securit)o(y)
+h(breac)o(hes)h(in)g(the)g(past,)i(but)e(still)f(most)149 1930
+y(system)13 b(administrators)h(do)g(not)h(disable)e(them.)19
+b(T)l(rust)c(in)e(net)o(w)o(orks)h(is)g(a)g(transitiv)o(e)f(relation,)149
+2021 y(in)19 b(the)g(sense)g(that)h(if)f(A)f(trusts)i(B,)e(and)i(B)f(trusts)g
+(C,)g(then)g(A)g(trusts)h(C.)f(This)g(relationship)149 2111
+y(can)j(do)h(great)f(harm.)37 b(Once)21 b(an)i(in)o(truder)d(has)j
+(successfully)d(sub)o(v)o(erted)h(one)h(mac)o(hine,)f(he)149
+2201 y(can)15 b(hop)g(to)g(other)g(mac)o(hines,)e(exploiting)g(trust.)21
+b(Examining)13 b(the)i(trade{o\013)h(b)q(et)o(w)o(een)d(con)o(v)o(e-)149
+2291 y(nience)i(and)i(p)q(ossibly)f(unauthorized)g(access,)f(most)h(system)e
+(administrators)h(decide)g(in)h(fa)o(v)o(or)149 2382 y(of)h(con)o(v)o
+(enience.)223 2472 y(In)g(our)h(setup,)g(host)h(NS)690 2479
+y Fm(A)737 2472 y Fo(trusts)f(host)h(H)1022 2479 y Fm(A)1067
+2472 y Fo(via)f(the)f(\014le)h(\\/etc/hosts.equiv")g(con)o(taining)149
+2562 y(host)f(H)292 2569 y Fm(A)320 2562 y Fo('s)g(host)f(name.)p
+eop
+%%Page: 47 56
+55 bop 1901 -100 a Fo(47)149 75 y(3.5.4)49 b(Authen)o(tication)15
+b(in)h(Berk)o(eley)e(\\r{Commands")223 197 y(The)20 b(main)g(t)o(w)o(o)h
+(\\r{command")f(applications)g(w)o(e)h(deal)f(with)h(are)g(\\rlogin")g(and)h
+(\\rsh,")149 287 y(b)q(oth)i(of)f(whic)o(h)f(consist)g(of)h(a)g(clien)o(t)e
+(and)i(a)g(serv)o(er)f(side.)39 b([Ste90,)24 b(Chapter)f(14])g(giv)o(es)f(an)
+149 378 y(o)o(v)o(erview)c(of)h(remote)f(command)f(execution)h(under)h(UNIX)f
+(and)i([Ste90,)f(Chapter)h(15])f(giv)o(es)149 468 y(man)o(y)c(details)h(ab)q
+(out)h(the)f(remote)f(login)h(pro)q(cedure.)223 558 y(Examining)f(the)h
+(source)h(co)q(de)f(for)h(the)f(clien)o(t)f(\\rlogin")i(and)h(the)e(serv)o
+(er)f(\\rlogind")j(yields)149 649 y(the)e(follo)o(wing)g(securit)o(y)f(c)o
+(hec)o(k)g(pro)q(cedure:)209 793 y(1.)24 b(Chec)o(k)16 b(if)f(the)h(clien)o
+(t)f(uses)h(a)h(reserv)o(ed)e(TCP)i(p)q(ort.)22 b(Ab)q(ort)16
+b(if)g(not.)209 925 y(2.)24 b(Chec)o(k)13 b(for)g(a)h(passw)o(ord)g(\014le)f
+(en)o(try)f(on)i(the)f(serv)o(er)f(for)i(the)f(sp)q(eci\014ed)f(serv)o
+(er{user{name.)271 1015 y(Ab)q(ort)17 b(if)f(not.)209 1147
+y(3.)24 b(If)16 b(not)h(ro)q(ot)g(login:)k(Chec)o(k)16 b(the)g
+(\\/etc/hosts.equiv")g(\014le)g(for)g(the)g(clien)o(t's)e(system.)209
+1279 y(4.)24 b(If)15 b(not)h(ro)q(ot)h(login:)k(Chec)o(k)14
+b(the)h(\\.rhosts")i(\014le)e(in)g(the)g(home)f(directory)h(of)h(serv)o
+(er{user{)271 1369 y(name)f(for)i(the)f(clien)o(t's)e(system.)209
+1501 y(5.)24 b(If)16 b(ro)q(ot)h(login:)22 b(Chec)o(k)15 b(the)h(\\/.rhosts")
+i(\014le)d(for)i(the)f(clien)o(t's)e(system.)209 1632 y(6.)24
+b(Prompt)16 b(user)g(for)h(his)f(passw)o(ord)h(if)f(none)h(of)f(the)g(tests)g
+(3-5)i(passed.)223 1777 y(It)23 b(ma)o(y)f(seem)g(that)i(a)g(system)f(is)g(m)
+o(uc)o(h)f(safer)i(if)f(only)g(\\.rhosts")i(\014les)e(exist)g(with)h(no)149
+1867 y(\\/etc/hosts.equiv")d(\014le,)e(b)q(ecause)h(\\.rhosts")i(\014les)d
+(create)g(the)h(additional)g(constrain)o(t)g(that)149 1957
+y(user)g(login)f(names)f(ha)o(v)o(e)h(to)g(matc)o(h:)26 b(the)19
+b(user)g(name)g(on)g(the)g(attac)o(king)g(host)h(and)g(the)f(one)149
+2048 y(on)k(the)e(attac)o(k)o(ed)g(host.)38 b(That)22 b(is)g(not)g(the)f
+(case.)37 b(In)22 b(Section)f(3.6.1)h(w)o(e)f(will)f(discuss)i(ho)o(w)149
+2138 y(to)16 b(acquire)f(information)g(ab)q(out)h(whic)o(h)f(host)i(name)d
+(and)i(whic)o(h)f(user)h(name)e(to)i(imp)q(ersonate.)149 2228
+y(Once)d(w)o(e)g(ha)o(v)o(e)f(that)i(information,)e(it)h(mak)o(es)e(no)j
+(di\013erence)e(at)i(all.)19 b(In)13 b(the)g(\\rlogin")h(proto)q(col,)149
+2318 y(the)f(clien)o(t)f(connects)g(to)i(p)q(ort)g(IPPOR)l(T)p
+906 2318 15 2 v 17 w(LOGINSER)-5 b(VER)1278 2300 y Fm(2)1310
+2318 y Fo(of)14 b(the)f(remote)e(host)j(and)g(sends)f(a)149
+2409 y(pac)o(k)o(et)f(consisting)g(of)h Fn(<)p Fo(lo)q(cal{user{name)p
+Fn(>)p Fo(,)f Fn(<)p Fo(remote{user{name)p Fn(>)p Fo(,)e(and)j
+Fn(<)p Fo(command)p Fn(>)d Fo(to)149 2499 y(the)j(serv)o(er.)20
+b(Because)12 b(the)h(clien)o(t)e(is)i(under)h(full)e(con)o(trol)h(of)g(the)g
+(attac)o(k)o(er,)g(it)g(is)g(not)g(di\016cult)f(for)p 149 2543
+720 2 v 206 2573 a Fl(2)224 2588 y Fk(in)i(\\netinet/in.h")f(curren)o(tly)i
+(sp)q(eci\014ed)g(as)f(TCP)g(p)q(ort)g(513)p eop
+%%Page: 48 57
+56 bop 1901 -100 a Fo(48)149 75 y(the)12 b(attac)o(k)o(er)e(to)i(mo)q(dify)f
+(the)g(\\rlogin")h(co)q(de,)h(suc)o(h)e(that)h(lo)q(cal{user{name)f(and)h
+(remote{user{)149 165 y(name)17 b(con)o(tain)h(the)g(appropriate)h(v)m
+(alues.)26 b(The)18 b(attac)o(k)o(er)f(can)i(then)f(recompile)d(the)j
+(\\rlogin")149 255 y(co)q(de)f(and)g(use)f(the)g(mo)q(di\014ed)f(v)o(ersion)h
+(instead)g(of)h(the)f(original)g(one.)149 415 y(3.5.5)49 b(Rev)o(erse)15
+b(Lo)q(okup)j(T)l(ree)e(Manipulation)223 538 y(Because)f(the)h(attac)o(k)o
+(er)f(con)o(trols)h(the)g(primary)e(domain)h(sub.domain.dom,)f(he)h(can)i(mo)
+q(d-)149 628 y(ify)i(the)f(data)i(of)f(the)g(rev)o(erse)e(lo)q(okup)j(tree)e
+(of)i(his)e(domain.)29 b(In)18 b(the)h(\\rlogin")h(proto)q(col,)g(the)149
+718 y(serv)o(er)d(retriev)o(es)f(the)i(IP)g(address)h(of)f(the)g(connecting)f
+(site)h(with)g(the)f(system)g(call)g(\\getp)q(eer-)149 809
+y(name\(\)".)25 b(The)18 b(serv)o(er)f(then)g(maps)g(the)h(IP)f(address)i(in)
+o(to)e(the)h(host)g(name)f(with)g(the)h(system)149 899 y(call)f(\\gethostb)o
+(y)o(addr\(\)".)27 b(In)18 b(Section)f(2.5)h(w)o(e)f(explained)g(that)h(the)g
+(IP)f(address)i(111.22.33.4)149 989 y(gets)g(con)o(v)o(erted)f(in)o(to)g(the)
+g(name)g(4.33.22.111.in-addr.arpa,)j(whic)o(h)d(is)g(then)h(queried)e(in)i
+(the)149 1079 y(rev)o(erse)e(lo)q(okup)i(tree)e(via)g(the)h(Domain)f(Name)g
+(System)f(proto)q(col.)27 b(In)18 b(an)g(unimpaired)e(state)149
+1170 y(of)j(the)g(database,)h(the)e(lo)q(okup)h(returns)g(the)f(name)f(of)i
+(the)g(attac)o(k)o(er)e(H)1523 1177 y Fm(B)1550 1170 y Fo(.)28
+b(But)18 b(if)g(one)h(single)149 1260 y(record)d(in)g(the)g(rev)o(erse)f(lo)q
+(okup)i(tree)f(is)g(c)o(hanged)g(from)284 1350 y(4.33.22.111.in-addr.arpa)153
+b(IN)c(PTR)i(H)1443 1357 y Fm(B)1470 1350 y Fo(.sub.domain.dom)149
+1441 y(to)284 1531 y(4.33.22.111.in-addr.arpa)i(IN)c(PTR)i(H)1443
+1538 y Fm(A)1471 1531 y Fo(.sub.domain.dom)149 1621 y(the)16
+b(query)g(yields)f(the)h(name)f(of)i(H)813 1628 y Fm(A)857
+1621 y Fo(after)f(the)g(zones)g(are)h(reloaded)f(in)o(to)g(the)g(name)f(serv)
+o(er.)149 1781 y(3.5.6)49 b(Cac)o(he)16 b(Corruption)223 1904
+y(Section)21 b(3.1)i(already)f(men)o(tioned)f(the)h(Berk)o(eley)d(soft)o(w)o
+(are)k(patc)o(h)f(that)h(adds)g(a)g(higher)149 1994 y(degree)d(of)g(securit)o
+(y)f(to)h(the)g(remote)e(login)j(pro)q(cedure.)32 b(The)20
+b(patc)o(h)g(w)o(orks)g(as)h(follo)o(ws:)29 b(the)149 2084
+y(system)22 b(call)g(\\gethostb)o(y)o(addr\(\)")i(in)f(\\rlogind")g(and)h
+(\\rshd")g(is)f(implem)o(e)o(n)o(ted)d(b)o(y)i(a)i(DNS)149
+2174 y(request)16 b(for)h(a)g(PTR)g(record.)23 b(The)16 b(serv)o(er)g(that)h
+(supplies)f(the)g(PTR)h(record)g(is)f(under)h(con)o(trol)149
+2265 y(of)f(the)g(attac)o(k)o(er)f(and)h(can)g(return)g(a)g(falsi\014ed)f
+(record.)21 b(The)16 b(system)e(call)h(\\gethostb)o(yname\(\)")149
+2355 y(requests)i(A)g(records)g(from)f(the)h(name,)e(serv)o(er)h(whic)o(h)g
+(is)h(not)h(con)o(trolled)e(b)o(y)g(the)h(attac)o(k)o(er.)23
+b(If)149 2445 y(the)e(comparison)e(of)i(the)f(retriev)o(ed)e(IP)j(addresses)g
+(and)g(the)f(original)g(IP)g(address)h(fails,)g(the)149 2536
+y(patc)o(h)d(has)h(succeeded)d(in)i(detecting)f(an)h(attempted)e(imp)q
+(ersonation.)26 b(Figure)17 b(3.2)h(sho)o(ws)h(an)149 2626
+y(o)o(v)o(erview)c(of)i(the)f(algorithm)f(used)h(in)g(the)g(patc)o(h.)p
+eop
+%%Page: 49 58
+57 bop 1901 -100 a Fo(49)449 754 y @beginspecial 0 @llx 0 @lly
+288 @urx 148 @ury 2880 @rwi @setspecial
+%%BeginDocument: pictures/patch_alg.ps
+/$F2psDict 200 dict def 
+$F2psDict begin
+$F2psDict /mtrx matrix put
+/l {lineto} bind def
+/m {moveto} bind def
+/s {stroke} bind def
+/n {newpath} bind def
+/gs {gsave} bind def
+/gr {grestore} bind def
+/clp {closepath} bind def
+/graycol {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
+4 -2 roll mul setrgbcolor} bind def
+/col-1 {} def
+/col0 {0 0 0 setrgbcolor} bind def
+/col1 {0 0 1 setrgbcolor} bind def
+/col2 {0 1 0 setrgbcolor} bind def
+/col3 {0 1 1 setrgbcolor} bind def
+/col4 {1 0 0 setrgbcolor} bind def
+/col5 {1 0 1 setrgbcolor} bind def
+/col6 {1 1 0 setrgbcolor} bind def
+/col7 {1 1 1 setrgbcolor} bind def
+	end
+/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
+/$F2psEnd {$F2psEnteredState restore end} def
+
+$F2psBegin
+0 setlinecap 0 setlinejoin
+0.0 148.0 translate 0.900 -0.900 scale
+0.500 setlinewidth
+n -1 19 m -1 19 l  319 19 l gs col-1 s gr
+n -1 39 m 319 39 l gs col-1 s gr
+n 19 59 m 319 59 l gs col-1 s gr
+n 19 59 m 169 89 l  319 59 l gs col-1 s gr
+n 19 89 m 319 89 l gs col-1 s gr
+n -1 109 m 319 109 l gs col-1 s gr
+n 169 89 m 169 109 l gs col-1 s gr
+n 19 59 m 19 109 l gs col-1 s gr
+n -1 109 m 159 139 l  319 109 l gs col-1 s gr
+n -1 139 m 319 139 l gs col-1 s gr
+n -1 -1 m -1 164 l  319 164 l  319 -1 l  -1 -1 l gs col-1 s gr
+n -1 159 m 319 159 l gs col-1 s gr
+n 159 139 m 159 159 l gs col-1 s gr
+/Times-Roman findfont 12.00 scalefont setfont
+4 14 m 
+gs 1 -1 scale (call gethostbyaddr\(\) with IP addr, get host name) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+4 34 m 
+gs 1 -1 scale (call gethostbyname\(\) with host name, get list of IP addresses) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+4 54 m 
+gs 1 -1 scale (for each A of these IP addresses do) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+129 74 m 
+gs 1 -1 scale (if \(IP addr == A\)) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+24 104 m 
+gs 1 -1 scale (then host ok. and break) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+84 124 m 
+gs 1 -1 scale (if \(no A has matched IP addr\)) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+4 154 m 
+gs 1 -1 scale (syslog impersonation attempt) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+29 79 m 
+gs 1 -1 scale (Y) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+299 79 m 
+gs 1 -1 scale (N) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+9 129 m 
+gs 1 -1 scale (Y) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+299 129 m 
+gs 1 -1 scale (N) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+234 154 m 
+gs 1 -1 scale (. /.) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+239 104 m 
+gs 1 -1 scale (. /.) col-1 show gr
+$F2psEnd
+%%EndDocument
+ @endspecial 580 999 a(Figure)16 b(3.2)33 b(Algorithm)14 b(of)j(the)f(Berk)o
+(eley)d(patc)o(h)223 1183 y(In)h(the)h(case)f(that)i(the)e(attac)o(k)o(ed)g
+(site)g(has)i(the)e(patc)o(h)h(in)f(place,)g(the)h(attac)o(k)o(er)f(has)h(to)
+g(use)g(a)149 1273 y(more)d(sophisticated)h(approac)o(h)g(to)g(succeed)f
+(with)h(his)f(in)o(trusion)h(attempt.)19 b(The)12 b(second)h(query)149
+1363 y(go)q(es)21 b(to)f(the)g(lo)q(cal)f(mac)o(hine's)e(name)i(serv)o(er)f
+(\014rst.)32 b(This)20 b(name)e(serv)o(er)h(has)h(a)g(cac)o(he)f(whic)o(h)149
+1454 y(can)h(b)q(e)f(p)q(oisoned)h(b)o(y)e(the)h(attac)o(k)o(er)f(b)o(y)g
+(adding)i(a)f(false)g(\\A")g(record)g(to)h(the)e(DNS)h(message)149
+1544 y(con)o(taining)14 b(the)f(PTR)h(record.)20 b(This)14
+b(additional)g(\\A")g(record)f(mak)o(es)f(the)h(remote)f(site)h(b)q(eliev)o
+(e)149 1634 y(the)j(rev)o(erse)f(lo)q(okup)i(w)o(as)g(correct.)223
+1724 y(In)j(our)h(setup,)g(w)o(e)f(mo)q(di\014ed)g(the)g(name)f(serv)o(er)h
+(co)q(de)g(of)h(the)g(attac)o(king)f(mac)o(hine.)32 b(W)l(e)149
+1815 y(added)22 b(statemen)o(ts)d(to)i(determine)e(when)i(the)f(rev)o(erse)g
+(lo)q(okup)h(query)f(for)h(the)g(mapping)f(of)149 1905 y
+(4.33.22.111.in-addr.arpa)26 b(w)o(as)e(issued.)43 b(T)l(o)24
+b(the)f(resp)q(onse)i(to)e(that)h(query)f(w)o(e)g(added)h(an)149
+1995 y(additional)c(record)f(pro)o(viding)g(a)g(fak)o(ed)g(forw)o(ard)h
+(mapping)e(from)g(111.22.33.4)j(to)f(H)1788 2002 y Fm(A)1835
+1995 y Fo({)g(not)149 2086 y(H)186 2093 y Fm(B)213 2086 y Fo(.)38
+b(Figure)21 b(3.3)h(sho)o(ws)h(the)e(con)o(ten)o(ts)h(of)g(the)f(additional)h
+(record.)38 b(It)21 b(w)o(as)h(imp)q(ortan)o(t)f(to)149 2176
+y(piggybac)o(k)12 b(the)g(unrequested)g(record)g(on)h(an)f(otherwise)g(v)m
+(alid)g(pac)o(k)o(et,)f(b)q(ecause)i(a)g(name)e(serv)o(er)149
+2266 y(examines)i(receiv)o(ed)g(pac)o(k)o(ets)h(for)h(their)f(id)g(n)o(um)o
+(b)q(er)f(and)j(other)e(criteria)g(b)q(efore)h(it)f(accepts)h(the)149
+2356 y(pac)o(k)o(ets)h(at)i(all)e(\(w)o(e)g(will)g(examine)e(these)j
+(criteria)e(in)i(Section)f(4.1.)23 b(F)l(or)17 b(no)o(w)h(it)e(is)h(enough)g
+(to)149 2447 y(kno)o(w)d(that)h(although)g(a)f(name)f(serv)o(er)f(do)q(es)j
+(not)f(blindly)f(accept)g(an)o(ything,)h(it)g(is)f(nev)o(ertheless)149
+2537 y(easy)j(to)g(fo)q(ol\).)21 b(T)l(o)c(camou\015age)e(the)g(attac)o(k,)g
+(w)o(e)g(supplied)g(a)h(short)g(time)e(to)i(liv)o(e)d(v)m(alue)j(in)f(the)149
+2627 y(resource)f(record.)21 b(Ho)o(w)o(ev)o(er,)12 b(the)i(BIND)f(co)q(de)h
+(con)o(tains)g(a)h(hard{co)q(ded)g(constan)o(t)f(that)h(limits)p
+eop
+%%Page: 50 59
+58 bop 1901 -100 a Fo(50)562 1054 y @beginspecial 0 @llx 0
+@lly 239 @urx 229 @ury 2390 @rwi @setspecial
+%%BeginDocument: pictures/add_rec_high.ps
+/$F2psDict 200 dict def 
+$F2psDict begin
+$F2psDict /mtrx matrix put
+/l {lineto} bind def
+/m {moveto} bind def
+/s {stroke} bind def
+/n {newpath} bind def
+/gs {gsave} bind def
+/gr {grestore} bind def
+/clp {closepath} bind def
+/graycol {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
+4 -2 roll mul setrgbcolor} bind def
+/col-1 {} def
+/col0 {0 0 0 setrgbcolor} bind def
+/col1 {0 0 1 setrgbcolor} bind def
+/col2 {0 1 0 setrgbcolor} bind def
+/col3 {0 1 1 setrgbcolor} bind def
+/col4 {1 0 0 setrgbcolor} bind def
+/col5 {1 0 1 setrgbcolor} bind def
+/col6 {1 1 0 setrgbcolor} bind def
+/col7 {1 1 1 setrgbcolor} bind def
+	end
+/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
+/$F2psEnd {$F2psEnteredState restore end} def
+
+$F2psBegin
+0 setlinecap 0 setlinejoin
+-4.0 234.0 translate 0.900 -0.900 scale
+1.000 setlinewidth
+	1 setlinecap [1 4.500000] 4.500000 setdash
+n 89 104 m 124 104 l gs col-1 s gr
+	[] 0 setdash 0 setlinecap
+	1 setlinecap [1 4.500000] 4.500000 setdash
+n 89 84 m 124 84 l gs col-1 s gr
+	[] 0 setdash 0 setlinecap
+	1 setlinecap [1 4.500000] 4.500000 setdash
+n 89 64 m 124 64 l gs col-1 s gr
+	[] 0 setdash 0 setlinecap
+	1 setlinecap [1 4.500000] 4.500000 setdash
+n 89 44 m 124 44 l gs col-1 s gr
+	[] 0 setdash 0 setlinecap
+	1 setlinecap [1 4.500000] 4.500000 setdash
+n 89 124 m 124 124 l gs col-1 s gr
+	[] 0 setdash 0 setlinecap
+n 84 114 m 204 114 l gs col-1 s gr
+n 84 74 m 204 74 l gs col-1 s gr
+n 84 54 m 204 54 l gs col-1 s gr
+n 84 94 m 204 94 l gs col-1 s gr
+	[6.000000] 0 setdash
+n 84 134 m 204 134 l gs col-1 s gr
+	[] 0 setdash
+0.500 setlinewidth
+	[4.000000] 0 setdash
+n 84 174 m 204 174 l gs col-1 s gr
+	[] 0 setdash
+	[4.000000] 0 setdash
+n 84 194 m 204 194 l gs col-1 s gr
+	[] 0 setdash
+	[4.000000] 0 setdash
+n 84 214 m 204 214 l gs col-1 s gr
+	[] 0 setdash
+	[4.000000] 0 setdash
+n 84 234 m 204 234 l gs col-1 s gr
+	[] 0 setdash
+1.000 setlinewidth
+n 91 34 m 84 34 84 247 7 arcto 4 {pop} repeat 84 254 197 254 7 arcto 4 {pop} repeat 204 254 204 41 7 arcto 4 {pop} repeat 204 34 91 34 7 arcto 4 {pop} repeat clp gs col-1 s gr
+n 86 29 m 79 29 79 252 7 arcto 4 {pop} repeat 79 259 202 259 7 arcto 4 {pop} repeat 209 259 209 36 7 arcto 4 {pop} repeat 209 29 86 29 7 arcto 4 {pop} repeat clp gs col-1 s gr
+0.500 setlinewidth
+	[4.000000] 0 setdash
+n 84 154 m 204 154 l gs col-1 s gr
+	[] 0 setdash
+/Courier-Bold findfont 12.00 scalefont setfont
+4 89 m 
+gs 1 -1 scale (ANSWER) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+4 49 m 
+gs 1 -1 scale (HEADER) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+4 69 m 
+gs 1 -1 scale (QUESTION) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+4 109 m 
+gs 1 -1 scale (AUTHORITY) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+4 129 m 
+gs 1 -1 scale (ADDITIONAL) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+4 14 m 
+gs 1 -1 scale (Sections) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+84 14 m 
+gs 1 -1 scale (Packet contents) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+204 14 m 
+gs 1 -1 scale (Fields) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+89 189 m 
+gs 1 -1 scale (IN = Internet) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+89 209 m 
+gs 1 -1 scale (5 seconds) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+89 229 m 
+gs 1 -1 scale (4 Bytes) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+89 249 m 
+gs 1 -1 scale (111.22.33.4) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+214 149 m 
+gs 1 -1 scale (NAME) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+214 169 m 
+gs 1 -1 scale (TYPE) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+214 189 m 
+gs 1 -1 scale (CLASS) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+214 209 m 
+gs 1 -1 scale (TTL) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+214 229 m 
+gs 1 -1 scale (RDLENGTH) col-1 show gr
+/Courier-Bold findfont 12.00 scalefont setfont
+214 249 m 
+gs 1 -1 scale (RDATA) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+89 149 m 
+gs 1 -1 scale (H  sub.domain.edu) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+89 169 m 
+gs 1 -1 scale (A = address record) col-1 show gr
+/Times-Roman findfont 8.00 scalefont setfont
+99 154 m 
+gs 1 -1 scale (A) col-1 show gr
+$F2psEnd
+%%EndDocument
+ @endspecial 588 1299 a(Figure)15 b(3.3)33 b(Additional)16
+b(false)g(resource)g(record)149 1483 y(the)21 b(minim)n(um)c(time)i(to)j(liv)
+o(e)d(v)m(alue)i(to)g(\\min)p 1041 1483 15 2 v 16 w(cac)o(he)p
+1173 1483 V 17 w(ttl")1263 1465 y Fm(3)1283 1483 y Fo(.)36
+b(In)20 b(case)h(the)g(remote)f(site)g(NS)1921 1490 y Fm(A)149
+1573 y Fo(con)o(tacts)e(the)g(attac)o(king)f(name)g(serv)o(er)g(NS)981
+1580 y Fm(B)1026 1573 y Fo(again)i(within)e(these)h(\014v)o(e)e(min)o(utes,)g
+(NS)1791 1580 y Fm(B)1836 1573 y Fo(could)149 1663 y(o)o(v)o(erwrite)f(the)h
+(fak)o(ed)g(records)g(b)o(y)g(supplying)g(new)g(ones)h(with)f(the)g(correct)g
+(information.)223 1754 y(W)l(e)g(included)g(the)h(feature)g(that)g(the)g
+(name)f(serv)o(er)g(can)h(understand)h(an)f(additional)g(user)149
+1844 y(issued)f(signal.)22 b(Using)15 b(this)h(toggle)g(signal,)g(the)g
+(attac)o(k)o(er)f(can)h(switc)o(h)f(on)i(the)e(malicious)f(co)q(de)149
+1934 y(b)q(efore)h(the)g(attac)o(k)g(starts,)g(and)h(switc)o(h)e(o\013)i(the)
+f(distribution)f(of)h(the)g(malicious)e(records)i(righ)o(t)149
+2024 y(after)22 b(access)f(w)o(as)g(gran)o(ted)h(b)o(y)f(the)g(attac)o(k)o
+(ed)f(site.)36 b(This)21 b(ensures)g(a)h(directed)e(attac)o(k)h(and)149
+2115 y(minim)o(um)12 b(p)q(ossible)k(un)o(w)o(an)o(ted)g(auditing.)149
+2280 y(3.6)50 b(Exp)q(eriences)15 b(Gained)223 2420 y(This)k(section)h
+(states)g(the)g(pieces)e(of)i(information)f(necessary)h(to)g(launc)o(h)f(an)h
+(attac)o(k)g(and)149 2510 y(describ)q(es)c(the)g(exp)q(eriences)f(gained)h
+(while)g(w)o(orking)g(with)g(the)g(test)g(en)o(vironmen)o(t.)p
+149 2554 720 2 v 206 2584 a Fl(3)224 2599 y Fk(in)e(BIND)g(v)o(ersion)g
+(4.8.3)e(\(5*60\))h(seconds)i(=)f(\014v)o(e)h(min)o(utes)p
+eop
+%%Page: 51 60
+59 bop 1901 -100 a Fo(51)262 1129 y @beginspecial 0 @llx 0
+@lly 378 @urx 256 @ury 3780 @rwi @setspecial
+%%BeginDocument: pictures/ns_req_mod.ps
+/$F2psDict 200 dict def 
+$F2psDict begin
+$F2psDict /mtrx matrix put
+/l {lineto} bind def
+/m {moveto} bind def
+/s {stroke} bind def
+/n {newpath} bind def
+/gs {gsave} bind def
+/gr {grestore} bind def
+/clp {closepath} bind def
+/graycol {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
+4 -2 roll mul setrgbcolor} bind def
+/col-1 {} def
+/col0 {0 0 0 setrgbcolor} bind def
+/col1 {0 0 1 setrgbcolor} bind def
+/col2 {0 1 0 setrgbcolor} bind def
+/col3 {0 1 1 setrgbcolor} bind def
+/col4 {1 0 0 setrgbcolor} bind def
+/col5 {1 0 1 setrgbcolor} bind def
+/col6 {1 1 0 setrgbcolor} bind def
+/col7 {1 1 1 setrgbcolor} bind def
+	end
+/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
+/$F2psEnd {$F2psEnteredState restore end} def
+
+$F2psBegin
+0 setlinecap 0 setlinejoin
+0.0 256.0 translate 0.900 -0.900 scale
+0.500 setlinewidth
+n 19 79 m 219 109 l  419 79 l gs col-1 s gr
+n -1 59 m 419 59 l gs col-1 s gr
+n -1 39 m 419 39 l gs col-1 s gr
+n -1 19 m 419 19 l gs col-1 s gr
+n 419 109 m 19 109 l gs col-1 s gr
+n 419 79 m 19 79 l gs col-1 s gr
+n 19 79 m 19 149 l gs col-1 s gr
+n 419 129 m 19 129 l gs col-1 s gr
+n -1 169 m 209 199 l  419 169 l gs col-1 s gr
+n -1 149 m 419 149 l gs col-1 s gr
+n -1 199 m 419 199 l gs col-1 s gr
+n -1 239 m 419 239 l gs col-1 s gr
+n -1 259 m 419 259 l gs col-1 s gr
+n -1 279 m 419 279 l gs col-1 s gr
+n -1 169 m 419 169 l gs col-1 s gr
+n 419 284 m 419 -1 l  -1 -1 l  -1 284 l  clp gs col-1 s gr
+n 209 199 m 209 239 l gs col-1 s gr
+n -1 219 m 209 219 l gs col-1 s gr
+n 219 109 m 219 129 l gs col-1 s gr
+/Times-Roman findfont 12.00 scalefont setfont
+4 74 m 
+gs 1 -1 scale (case QUERY:) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+129 94 m 
+gs 1 -1 scale (if query is 4.33.22.111.in-addr.arpa) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+24 144 m 
+gs 1 -1 scale (...) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+4 164 m 
+gs 1 -1 scale (...) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+4 214 m 
+gs 1 -1 scale (add bogus record to additional section) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+4 234 m 
+gs 1 -1 scale (increase HEADER.ARCOUNT) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+4 254 m 
+gs 1 -1 scale (send packet to socket) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+4 34 m 
+gs 1 -1 scale ({ ...) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+4 274 m 
+gs 1 -1 scale (... }) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+4 14 m 
+gs 1 -1 scale (... ns_req\(...\)) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+29 99 m 
+gs 1 -1 scale (Y) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+399 99 m 
+gs 1 -1 scale (N) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+9 189 m 
+gs 1 -1 scale (Y) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+399 189 m 
+gs 1 -1 scale (N) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+224 124 m 
+gs 1 -1 scale (. /.) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+214 234 m 
+gs 1 -1 scale (. /.) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+4 54 m 
+gs 1 -1 scale (declare flag Eureka = false) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+24 124 m 
+gs 1 -1 scale (set flag Eureka = true) col-1 show gr
+/Times-Roman findfont 12.00 scalefont setfont
+164 184 m 
+gs 1 -1 scale (if \(Eureka == true\)) col-1 show gr
+$F2psEnd
+%%EndDocument
+ @endspecial 561 1374 a(Figure)16 b(3.4)33 b(Mo)q(di\014cations)16
+b(in)g(name)f(serv)o(er)h(co)q(de)149 1558 y(3.6.1)49 b(Acquiring)15
+b(Information)223 1680 y(An)20 b(attac)o(k)o(er)g(needs)h(to)g(ha)o(v)o(e)f
+(three)g(pieces)g(of)h(information)f(b)q(efore)h(he)g(can)g(launc)o(h)f(an)
+149 1770 y(attac)o(k:)222 1902 y Fj(\017)k Fo(target)17 b(host)g(name)e(NS)
+715 1909 y Fm(A)222 2034 y Fj(\017)24 b Fo(user)17 b(name\(s\))e(on)i(hosts)g
+(NS)818 2041 y Fm(A)863 2034 y Fo(and)g(H)995 2041 y Fm(A)1039
+2034 y Fo(to)g(imp)q(ersonate)222 2166 y Fj(\017)24 b Fo(host)17
+b(name)e(H)544 2173 y Fm(A)589 2166 y Fo(trusted)h(b)o(y)g(target)g(host)223
+2298 y(In)d(some)f(en)o(vironmen)o(ts,)f(the)i(lo)q(cal)g(and)h(remote)e
+(login)h(names)g(for)g(one)h(user)f(are)h(iden)o(tical.)149
+2388 y(A)h(user)g(has)g(the)g(p)q(ossibilit)o(y)f(to)h(sp)q(ecify)f(other)h
+(user)g(names)f(as)i(trusted)f(users)g(of)g(his)g(accoun)o(t.)149
+2478 y(In)h(that)h(case,)f(the)g(login)g(names)f(are)i(most)e(lik)o(ely)f
+(di\013eren)o(t.)p eop
+%%Page: 52 61
+60 bop 1901 -100 a Fo(52)223 75 y(In)12 b(our)h(setup,)g(w)o(e)f(w)o(ere)f
+(not)i(in)f(need)h(of)f(acquiring)g(host)h(name)f(pairs)h(and)g(the)f
+(appropriate)149 165 y(login)17 b(names.)23 b(Section)16 b(4.7)h(pro)o(vides)
+f(metho)q(ds)h(to)g(obtain)g(this)g(information,)f(follo)o(w)o(ed)g(b)o(y)g
+(a)149 255 y(discussion.)149 415 y(3.6.2)49 b(Complexit)o(y)14
+b(of)j(Mo)q(di\014cations)223 538 y(Most)d(of)g(the)g(w)o(ork)f(that)i(w)o
+(as)f(done)g(during)g(the)g(exp)q(erimen)o(ts)d(w)o(en)o(t)i(in)o(to)h(the)g
+(setup)g(of)g(the)149 628 y(zones)h(for)g(the)f(name)g(serv)o(ers,)g(the)g
+(source)h(co)q(de)f(mo)q(di\014cations)h(of)g(the)f(remote)f(login)h(and)i
+(the)149 718 y(name)i(serv)o(er,)g(and)h(some)f(shell)g(scripts)h(to)g
+(automatize)f(the)g(break{in.)29 b(The)19 b(mo)q(di\014cations)149
+809 y(to)i(facilitate)e(a)i(break{in)f(are)h(minim)o(al)c(in)j(the)g(simpler)
+f(case)h(that)h(the)f(Berk)o(eley)d(patc)o(h)k(is)149 899 y(not)f(installed.)
+29 b(Only)18 b(one)i(record)f(in)f(the)h(database)i(for)e(the)g(rev)o(erse)e
+(lo)q(okup)j(tree)f(m)o(ust)e(b)q(e)149 989 y(c)o(hanged.)223
+1079 y(If,)d(ho)o(w)o(ev)o(er,)f(the)h(patc)o(h)h(is)f(installed,)g(the)g
+(name)f(serv)o(er)h(co)q(de)h(m)o(ust)e(b)q(e)i(c)o(hanged)f(to)h(en)o(ter)
+149 1170 y(the)k(false)g(resource)f(record)h(in)o(to)g(the)f(additional)h
+(answ)o(er)g(section.)29 b(These)19 b(c)o(hanges)g(are)g(not)149
+1260 y(di\016cult,)12 b(but)h(they)f(require)f(a)i(go)q(o)q(d)i
+(understanding)e(of)g(the)g(Domain)f(Name)f(System)g(proto)q(col)149
+1350 y(and)17 b(the)f(name)f(serv)o(er)h(source)g(co)q(de.)223
+1441 y(F)l(urthermore,)h(there)i(are)g(some)f(c)o(hanges)h(to)g(the)g
+(\\rlogin")h(program.)29 b(In)19 b(the)g(case)g(that)149 1531
+y(user)g(Alice)e(on)i(host)g(NS)622 1538 y Fm(A)669 1531 y
+Fo(trusts)g(user)g(Bob)g(on)g(host)g(H)1236 1538 y Fm(A)1264
+1531 y Fo(,)g(the)f(attac)o(king)g(host)h(w)o(ould)g(need)149
+1621 y(a)e(legitimate)d(user)i(Bob)g(that)h(logs)g(in)o(to)f(NS)989
+1628 y Fm(A)1018 1621 y Fo(.)21 b(But)16 b(that)h(w)o(ould)f(require)f
+(adding)i(a)f(new)g(user)149 1711 y(id)i(to)g(the)g(attac)o(king)g(system)e
+(ev)o(ery)g(time)g(the)i(attac)o(k)o(er)f(w)o(an)o(ts)h(to)g(imp)q(ersonate)f
+(a)h(di\013eren)o(t)149 1802 y(user)i(name,)e(regardless)h(of)h(the)f(view)o
+(able)f(c)o(hanges)h(in)g(the)g(passw)o(ord)h(\014le.)30 b(A)19
+b(m)o(uc)o(h)e(neater)149 1892 y(approac)o(h)23 b(requires)e(few)h(c)o
+(hanges)g(in)f(the)h(\\rlogin")g(co)q(de.)39 b(F)l(or)22 b(the)f(target)h
+(host)h(it)e(is)h(not)149 1982 y(imp)q(ortan)o(t)c(that)g(the)g(remote)e
+(user)j(Bob)f(exists;)g(it)f(is)h(su\016cien)o(t)f(to)i(pass)g(Bob's)f(login)
+g(name)149 2073 y(in)f(the)g(\014rst)g(pac)o(k)o(et)f(\(see)g(section)h
+(3.5.4\))g(from)f(the)g(\\rlogin")i(clien)o(t)d(to)i(the)g(\\rlogind")h(serv)
+o(er)149 2163 y(to)f(mak)o(e)d(the)i(target)h(host)g(b)q(eliev)o(e)d(Bob)i
+(is)h(\\real".)223 2253 y(Ov)o(erall,)c(the)j(attac)o(k)f(requires)g(only)g
+(a)h(few)g(c)o(hanges)g(and)g(can)g(b)q(e)g(ac)o(hiev)o(ed)e(easily)l(.)20
+b(What)149 2343 y(mak)o(es)11 b(the)h(break{in)f(di\016cult)g(is)h(obtaining)
+g(the)g(necessary)g(information)f(ab)q(out)i(remote)d(users)149
+2434 y(and)20 b(mac)o(hine)e(names,)g(ha)o(ving)i(sup)q(eruser)f(privileges)f
+(on)i(a)g(system)e(with)h(a)h(primary)e(name)149 2524 y(serv)o(er,)13
+b(and)i(ha)o(ving)f(the)g(pro\014ciency)f(of)i(making)d(the)i(c)o(hanges)h
+(in)e(the)h(name)f(serv)o(er)g(database)149 2614 y(and)k(co)q(de.)p
+eop
+%%Page: 53 62
+61 bop 1901 -100 a Fo(53)149 75 y(3.6.3)49 b(Detecting)16 b(a)h(DNS)f(based)h
+(Break{in)223 197 y(During)j(an)g(attac)o(k,)f(an)h(attac)o(k)o(er)f(usually)
+g(w)o(an)o(ts)h(to)g(op)q(erate)g(as)g(furtiv)o(ely)e(as)i(p)q(ossible.)149
+287 y(After)14 b(an)h(attac)o(k,)g(an)g(attac)o(k)o(er)e(w)o(an)o(ts)i(to)g
+(lea)o(v)o(e)e(b)q(ehind)i(as)g(few)g(clues)e(as)j(p)q(ossible)f(that)g
+(could)149 378 y(p)q(oin)o(t)i(to)f(him)f(or)i(his)f(actions.)223
+468 y(W)l(e)j(distinguish)h(b)q(et)o(w)o(een)f(where)h(the)f(attac)o(k)o
+(er's)g(presence)g(or)h(his)g(actions)g(can)g(b)q(e)g(de-)149
+558 y(tected)c(or)g(observ)o(ed:)21 b(On)16 b(the)g(attac)o(k)o(ed)g(mac)o
+(hine)e(and)j(on)g(the)f(attac)o(k)o(er's)f(mac)o(hine.)223
+649 y(In)e(the)h(follo)o(wing)g(w)o(e)f(assume)h(that)g(the)g(attac)o(k)o(er)
+f(has)i(not)f(\(y)o(et\))f(done)h(an)o(y)g(ob)o(vious)g(harm)149
+739 y(to)f(the)f(attac)o(k)o(ed)f(system.)19 b(In)12 b(our)g(examination)f(w)
+o(e)h(only)g(treat)g(the)g(detection)f(of)i(the)f(break-in)149
+829 y(directly)l(,)h(not)i(of)g(its)f(consequences,)g(once)g(an)h(attac)o(k)o
+(er)f(has)h(gained)g(access.)21 b(The)14 b(false)h(record)149
+919 y(in)k(the)g(cac)o(he)g(has)g(a)h(minim)n(um)15 b(lifetime)h(of)j(curren)
+o(tly)f(\014v)o(e)g(min)o(utes)f(and)j(can)f(b)q(e)h(detected)149
+1010 y(only)15 b(in)f(that)i(short)f(p)q(erio)q(d)g(of)g(time.)k(The)c(false)
+f(mapping)g(could)h(b)q(e)f(detected)g(b)o(y)g(examining)149
+1100 y(a)j(cac)o(he)f(dump)f(of)i(the)f(name)f(serv)o(er,)g(or)i(in)f(case)h
+(a)g(user)f(tried)g(to)h(resolv)o(e)e(one)h(of)h(the)f(names)149
+1190 y(in)o(v)o(olv)o(ed)e(in)i(the)g(tamp)q(ering.)223 1281
+y(The)11 b(simple)e(fact)i(that)h(the)f(attac)o(k)o(er)f(is)h(logged)h(in)f
+(could)g(b)q(e)g(observ)o(ed.)20 b(In)10 b(an)i(en)o(vironmen)o(t)149
+1371 y(where)19 b(man)o(y)f(users)h(access)g(a)g(system)e(at)j(the)f(same)e
+(time,)g(this)i(seems)f(unlik)o(ely)l(.)27 b(Ho)o(w)o(ev)o(er,)149
+1461 y(if)19 b(the)g(compromised)d(mac)o(hine)h(is)i(w)o(atc)o(hed)f(closely)
+g(b)o(y)h(a)g(system)f(administrator)g(or)i(users,)149 1551
+y(the)e(c)o(hance)g(of)h(detecting)e(the)h(login)g(is)g(higher.)27
+b(If)18 b(the)g(attac)o(k)o(er)f(logs)i(in)f(as)h(sup)q(eruser,)g(the)149
+1642 y(c)o(hances)i(of)h(detection)f(are)g(ev)o(en)f(higher,)i(b)q(ecause)g
+(logins)f(of)h(privileged)e(users)i(are)f(logged)149 1732 y(separately)l(.)
+223 1822 y(It)c(is)h(also)h(p)q(ossible)f(to)h(mo)q(dify)e(the)h
+(\\rlogin"{co)q(de)h(to)f(log)h(all)f(remote)e(logins)i(to)h(gather)149
+1913 y(more)c(information)h(ab)q(out)h(connections)f(in)o(v)o(olving)f(the)h
+(o)o(wn)h(host.)223 2003 y(On)e(the)h(attac)o(k)o(er's)f(mac)o(hine,)e(w)o(e)
+i(ha)o(v)o(e)g(to)h(distinguish)g(b)q(et)o(w)o(een)f(the)g(p)q(ossible)h
+(iden)o(tities)149 2093 y(of)21 b(an)g(attac)o(k)o(er.)33 b(If)20
+b(he)h(is)f(a)h(rogue)g(system)e(administrator)h(and)h(has)g(no)g(higher)g
+(authorit)o(y)149 2183 y(ab)q(o)o(v)o(e)c(him)d(in)j(his)f(organization,)h
+(there)e(is)i(hardly)f(an)o(y)g(c)o(hance)g(that)h(an)o(y)o(one)f(on)h(his)f
+(system)149 2274 y(could)h(detect)e(his)h(malicious)e(deeds.)223
+2364 y(If)i(he)g(has)i(sub)o(v)o(erted)d(the)i(system)e(and)i(has)g(gained)g
+(the)g(necessary)f(sup)q(eruser)h(privileges)149 2454 y(on)e(the)f(attac)o
+(king)g(mac)o(hine,)e(the)i(c)o(hances)f(of)i(detecting)e(him)f(are)i(b)q
+(etter,)g(though)h(still)e(prett)o(y)149 2545 y(small.)27 b(Because)18
+b(the)h(attac)o(k)o(er)e(has)j(sub)o(v)o(erted)d(the)i(attac)o(king)f(mac)o
+(hine)f(in)h(the)h(\014rst)g(place,)p eop
+%%Page: 54 63
+62 bop 1901 -100 a Fo(54)149 75 y(ev)o(erything)17 b(w)o(e)g(said)h(ab)q(out)
+h(the)f(p)q(ossibilities)f(of)h(detecting)f(an)o(ything)h(on)g(an)g(attac)o
+(k)o(ed)f(ma-)149 165 y(c)o(hine)f(is)g(applicable)g(here)h(as)g(w)o(ell.)k
+(W)l(e)c(could)f(also)i(observ)o(e)e(the)g(mo)q(di\014ed)g(executable)f
+(\014les,)149 255 y(that)j(are)g(necessary)f(for)g(the)h(\\rlogin")g(and)g
+(the)f(mo)q(di\014ed)f(name)g(serv)o(er)g(op)q(eration.)26
+b(But)17 b(all)149 346 y(c)o(hanges)j(in)f(binaries)f(can)i(b)q(e)f(made)f
+(using)i(lo)q(cal)f(copies)f(of)i(the)f(source)g(co)q(de)g(that)h(is)f(read-)
+149 436 y(ily)g(a)o(v)m(ailable.)31 b(Some)19 b(sites)g(run)h(monitors)f
+(that)h(detect)f(on)h(a)g(daily)f(basis)i(if)e(binaries)g(w)o(ere)149
+526 y(c)o(hanged)c(or)g(touc)o(hed.)20 b(Using)14 b(lo)q(cal)h(copies)f(a)o
+(v)o(oids)g(detection)g(b)o(y)g(this)g(t)o(yp)q(e)g(of)h(monitor.)k(The)149
+616 y(executables)c(can)h(ev)o(en)f(b)q(e)h(started)g(from)f(lo)q(cal)h
+(directories,)f(w)o(ell{hidden)f(from)h(others.)21 b(The)149
+707 y(name)15 b(serv)o(er)g(that)i(is)f(already)g(running)g(has)h(to)f(b)q(e)
+g(replaced)f(b)o(y)h(the)g(lo)q(cal)g(cop)o(y)l(,)f(but)h(that)h(is)149
+797 y(a)g(job)g(that)f(tak)o(es)g(less)g(than)h(a)g(second.)223
+887 y(T)l(amp)q(ering)h(with)g(the)h(log)g(\014les)f(also)h(aids)g(the)g
+(attac)o(k)o(er)f(in)g(sta)o(ying)h(undetected.)28 b(With)149
+978 y(the)16 b(mo)q(di\014ed)e(\\rlogin")i(v)o(ersion,)f(there)g(are)h(no)g
+(additional)f(passw)o(ord)i(\014le)e(en)o(tries)f(necessary)l(,)149
+1068 y(whic)o(h)i(otherwise)g(could)g(b)q(e)g(observ)o(ed.)223
+1158 y(Ov)o(erall,)k(the)g(attac)o(k)o(er)g(has)i(v)o(ery)e(go)q(o)q(d)j(c)o
+(hances)d(of)h(hiding)g(his)g(activities)e(completely)l(.)149
+1248 y(Most)h(of)g(these)g(metho)q(ds)f(of)h(getting)f(a)h(glimpse)e(of)i
+(his)f(doing)h(seem)e(farfetc)o(hed)h(to)h(us)g(and)149 1339
+y(their)14 b(o)q(dds)i(of)f(success)g(are)f(quite)g(small.)19
+b(The)c(highest)f(c)o(hances)g(of)h(detecting)f(the)g(tamp)q(ering)149
+1429 y(is)d(b)o(y)g(catc)o(hing)f(the)h(false)g(record)g(during)g(its)g
+(short)h(lifetime)7 b(or)12 b(b)o(y)e(simply)f(\014nding)j(the)e(attac)o(k)o
+(er)149 1519 y(logged)17 b(in.)p eop
+%%Page: 55 64
+63 bop 1901 -100 a Fo(55)540 342 y(4.)33 b(SECURITY)16 b(ANAL)l(YSIS)e(AND)i
+(SOLUTIONS)223 516 y(Most)e(of)g(the)g(prop)q(osed)i(\\solutions")f(in)f
+(this)g(c)o(hapter)f(are)h(not)h(complete)d(solutions)i(to)h(the)149
+606 y(problem.)27 b(Some)18 b(of)h(them)e(are)h(v)m(alid)g(under)h
+(additional)g(assumptions)f(that)h(cannot)h(alw)o(a)o(ys)149
+696 y(b)q(e)d(met;)d(others)j(are)f(applicable)f(to)i(parts)g(of)f(the)g
+(problem.)223 787 y(Because)e(man)o(y)g(factors)i(con)o(tribute)e(to)i(the)f
+(securit)o(y)f(breac)o(h)g(encoun)o(tered)h(in)g(this)g(thesis)149
+877 y(and)k(all)e(of)g(them)f(are)i(necessary)l(,)f(it)g(is)g(su\016cien)o(t)
+g(to)g(eliminate)e(one)j(of)g(them.)23 b(That)18 b(sounds)149
+967 y(easy)j(to)f(accomplish,)f(but)h(is)g(a)h(di\016cult)d(task)j(in)f
+(practice,)f(b)q(ecause)i(eliminating)c(an)o(y)j(one)149 1057
+y(of)f(the)e(factors)h(brings)g(a)h(trade{o\013)g(with)e(functionalit)o(y)l
+(,)g(e\016ciency)l(,)e(or)j(simply)e(con)o(v)o(enience)149
+1148 y(with)h(it.)223 1238 y(W)l(e)h(presen)o(t)h(for)g(eac)o(h)f(of)i(our)f
+(solutions)g(the)g(necessary)g(bac)o(kground,)h(if)e(it)g(w)o(as)i(not)f(al-)
+149 1328 y(ready)j(giv)o(en)f(in)g(one)h(of)g(the)g(previous)f(c)o(hapters,)i
+(follo)o(w)o(ed)e(b)o(y)g(a)h(description)f(of)h(the)g(idea)149
+1419 y(of)d(the)g(solution.)29 b(The)19 b(solution)g(is)f(then)h(examined)e
+(and)i(discussed)g(using)g(criteria)e(suc)o(h)i(as)149 1509
+y(feasibilit)o(y)c(of)j(its)e(implem)o(en)o(tation,)e(qualit)o(y)i(of)h(the)g
+(solution,)g(complexit)o(y)c(of)18 b(the)e(idea,)h(and)149
+1599 y(compatibilit)o(y)d(with)i(the)g(original)g(design)g(goals.)223
+1689 y(It)10 b(is)h(imp)q(ortan)o(t)f(to)h(view)f(these)h(solutions)g(as)h
+(not)f(stand)h(alone.)19 b(In)11 b(di\013eren)o(t)f(com)o(binations)149
+1780 y(they)i(ac)o(hiev)o(e)f(sev)o(eral)g(degrees)h(of)h(securit)o(y)l(.)19
+b(The)12 b(concluding)g(c)o(hapter)g(of)h(this)f(thesis)g(con)o(tains)149
+1870 y(a)k(high)f(lev)o(el)d(discussion)j(ab)q(out)i(com)o(binations)c(of)i
+(our)h(solutions,)f(to)g(obtain,)g(if)g(not)g(absolute)149
+1960 y(securit)o(y)l(,)c(at)h(least)f(a)h(high)g(lev)o(el)e(of)i
+(con\014dence)f(in)g(the)g(securit)o(y)f(of)i(the)g(Domain)f(Name)f(System.)
+149 2126 y(4.1)50 b(Securit)o(y)14 b(Considerations)j(in)f(the)g(RF)o(C)g
+(1035)223 2265 y(In)h(the)g(design)g(of)h(the)f(Domain)g(Name)e(System,)h
+(securit)o(y)g(considerations)i(w)o(ere)e(not)i(for-)149 2356
+y(gotten,)i(and)f(the)f(RF)o(Cs)h(sho)o(w)g(that)g(the)g(in)o(tegrit)o(y)e
+(of)i(the)f(cac)o(he)g(w)o(as)h(an)g(imp)q(ortan)o(t)f(issue.)149
+2446 y(The)g(eagerness)h(to)f(impro)o(v)o(e)d(p)q(erformance)i(led)g(to)h
+(the)g(nast)o(y)g(logic)g(b)q(om)o(b)f(of)h(adding)h(unau-)149
+2536 y(thorized)d(records)g(to)g(the)g(additional)g(section)g(and)g(|)g(in)g
+(absence)g(of)g(strong)h(authen)o(tication)149 2626 y(|)f(b)q(elieving)f
+(their)h(correctness.)p eop
+%%Page: 56 65
+64 bop 1901 -100 a Fo(56)223 75 y(Before)22 b(resp)q(onses)j(are)e(further)g
+(pro)q(cessed,)i(a)f(n)o(um)o(b)q(er)e(of)h(prepro)q(cessing)h(steps)g(tak)o
+(es)149 165 y(place.)34 b(These)21 b(include)e(a)j(c)o(hec)o(k)c(for)j(the)g
+(plausibilit)o(y)d(of)j(the)g(header)g(\(id)f(n)o(um)o(b)q(er)f(c)o(hec)o
+(k\),)149 255 y(the)i(correctness)g(of)g(the)g(resource)g(records')g(format,)
+g(and)h(time)d(to)i(liv)o(e)f(v)m(alues.)35 b(If)21 b(a)h(time)149
+346 y(to)e(liv)o(e)e(v)m(alue)i(exceeds)e(one)i(w)o(eek,)f(the)g(sp)q
+(eci\014cation)h(allo)o(ws)f(the)h(implem)o(en)n(tor)d(to)j(discard)149
+436 y(this)g(record,)g(or)g(limit)c(its)k(lifetime)c(to)k(one)f(w)o(eek.)31
+b(The)19 b(id)g(in)h(the)f(header)h(of)f(the)h(resp)q(onse)149
+526 y(m)o(ust)h(matc)o(h)f(the)h(id)g(of)h(the)f(query)l(.)37
+b(A)21 b(name)f(serv)o(er)h(exp)q(ects)g(the)g(reply)g(from)f(the)h(same)149
+616 y(IP)e(address)h(where)e(he)h(sen)o(t)g(the)f(query)l(.)29
+b(This)19 b(can)g(cause)g(some)f(confusion)h(if)f(replies)g(come)149
+707 y(from)13 b(m)o(ultihome)o(d)e(hosts)j(that)g(use)g(other)g(p)q(orts)g
+(for)g(sending)g(the)f(resp)q(onse,)i(b)q(ecause)f(of)g(lo)q(cal)149
+797 y(routing)j(information.)j(This)d(w)o(as)f(a)h(common)d(bug)j(in)f(name)f
+(serv)o(ers.)223 887 y(The)j(standard)i(states)f(sev)o(eral)f(situations)h
+(in)f(whic)o(h)g(data)h(should)h(not)f(b)q(e)f(cac)o(hed.)28
+b(If)18 b(a)149 978 y(pac)o(k)o(et)e(is)g(truncated)h(\(TC)g(\015ag)g(in)f
+(the)g(header)h(is)f(set\),)g(its)h(resource)f(records)g(should)h(not)g(b)q
+(e)149 1068 y(cac)o(hed,)i(although)h(they)f(can)g(b)q(e)g(used)g(for)h(the)e
+(curren)o(t)h(mapping.)28 b(The)20 b(reason)f(for)h(this)f(is)149
+1158 y(that)e(a)g(cac)o(he)f(should)g(not)h(con)o(tain)f(incomplete)e
+(information.)21 b(The)16 b(information)f(in)h(a)h(cac)o(he)149
+1248 y(migh)o(t)12 b(b)q(e)i(out)h(of)f(date)g(whic)o(h)f(will)f(ev)o(en)o
+(tually)g(b)q(e)i(corrected;)f(but)h(the)f(cac)o(he)g(sta)o(ys)h(alw)o(a)o
+(ys)g(in)149 1339 y(a)19 b(consisten)o(t)f(state,)h(b)q(ecause)f(incomplete)e
+(mappings)i(are)g(nev)o(er)f(en)o(tered.)27 b(A)17 b(cac)o(he)h(should)149
+1429 y(nev)o(er)c(prefer)f(cac)o(he)h(data)h(o)o(v)o(er)f(authoritativ)o(e)g
+(data.)21 b(Resp)q(onses)16 b(to)e(in)o(v)o(erse)f(queries)g(are)i(also)149
+1519 y(tab)q(o)q(o)21 b(b)q(ecause)d(of)h(their)f(incomplete)d(information)j
+(c)o(haracter.)26 b(Name)17 b(serv)o(ers)h(or)g(resolv)o(ers)149
+1610 y(ha)o(v)o(e)g(to)h(do)f(all)g(correctness)g(c)o(hec)o(ks)f(b)q(efore)h
+(they)g(can)g(cac)o(he)g(data.)28 b(Resp)q(onses)19 b(of)g(dubious)149
+1700 y(reliabilit)o(y)f(ha)o(v)o(e)i(to)i(b)q(e)f(examined)d(carefully)l(.)33
+b(It)21 b(is)f(ho)o(w)o(ev)o(er)g(not)h(easy)g(to)g(decide)f(criteria)149
+1790 y(suc)o(h)c(as)h(\\dubious)h(origin,")e(or)g(\\reliable)f(source.")223
+1880 y(Before)i(cac)o(hing)g(a)i(newly)e(receiv)o(ed)e(record,)j(the)g(name)f
+(serv)o(er)g(should)h(c)o(hec)o(k)e(for)i(an)h(ex-)149 1971
+y(isting)h(record)f(in)g(the)g(cac)o(he.)29 b(Dep)q(ending)20
+b(on)g(the)f(circumstances,)e(either)i(the)g(data)h(in)f(the)149
+2061 y(resp)q(onse,)k(or)e(the)f(cac)o(he)g(is)h(preferred,)f(but)h(the)g(t)o
+(w)o(o)f(should)h(nev)o(er)f(b)q(e)h(com)o(bined.)32 b(If)21
+b(the)149 2151 y(data)c(in)f(the)g(resp)q(onse)h(is)f(mark)o(ed)e(as)j
+(authoritativ)o(e)f(data)h(in)f(the)g(answ)o(er)g(section,)f(it)h(should)149
+2242 y(alw)o(a)o(ys)h(b)q(e)f(preferred.)p eop
+%%Page: 57 66
+65 bop 1901 -100 a Fo(57)149 75 y(4.2)50 b(Analysis)15 b(of)i(the)f(Name)e
+(Serv)o(er)h(Algorithm)223 214 y(In)k(this)g(section)h(w)o(e)f(review)f(the)i
+(name)e(serv)o(er)h(algorithm)f(stated)i(in)g(section)f(2.9.2)h(and)149
+305 y(analyze)d(it)f(step)h(b)o(y)f(step.)24 b(W)l(e)16 b(are)h(esp)q
+(ecially)e(lo)q(oking)j(for)f(w)o(eak)f(assumptions)h(that)h(do)f(not)149
+395 y(alw)o(a)o(ys)g(hold.)k(These)16 b(assumptions)g(could)g(b)q(e)h
+(exploited)e(b)o(y)g(attac)o(k)o(ers.)209 539 y(1.)24 b(In)14
+b(step)h(one)f(the)g(algorithm)f(determines)f(if)i(a)g(recursiv)o(e)f(name)g
+(resolution)h(is)g(requested)271 629 y(and)k(a)o(v)m(ailable.)j(If)c(so,)g
+(it)f(branc)o(hes)g(to)i(step)e(\014v)o(e,)g(where)g(a)h(cop)o(y)f(of)h(the)g
+(resolv)o(er)e(algo-)271 720 y(rithm)e(or)h(the)g(lo)q(cal)g(resolv)o(er)f
+(is)h(in)o(v)o(ok)o(ed.)19 b(When)14 b(the)g(resolv)o(er)f(returns)i(an)f
+(answ)o(er,)h(the)271 810 y(name)f(serv)o(er)g(algorithm)g(b)q(eliev)o(es)f
+(this)h(answ)o(er)h(to)g(b)q(e)g(correct)g(and)g(copies)f(it)h(as)g(is)g(in)o
+(to)271 900 y(the)g(according)g(answ)o(er)g(sections)f(of)h(the)g(o)o(wn)g
+(reply)l(.)20 b(This)15 b(answ)o(er)g(could)f(con)o(tain)h(false)271
+991 y(records)i(not)g(only)g(in)f(the)g(additional)h(section,)f(but)h(also)g
+(in)f(the)g(answ)o(er)h(or)g(authorita-)271 1081 y(tiv)o(e)h(section.)31
+b(This)19 b(is)h(a)f(w)o(eak)h(assumption)f(b)q(ecause)g(the)h(resp)q(onse)g
+(of)f(an)h(arbitrary)271 1171 y(name)15 b(serv)o(er)h(cannot)g(alw)o(a)o(ys)h
+(b)q(e)f(trusted.)209 1303 y(2.)24 b(In)12 b(step)g(t)o(w)o(o)g(the)g(name)f
+(serv)o(er)g(searc)o(hes)h(the)g(a)o(v)m(ailable)f(zones)h(for)h(the)e
+(nearest)h(ancestor.)271 1393 y(It)k(assumes)f(that)h(its)f(zone)h(data)g(is)
+g(accurate.)k(This)c(should)g(usually)g(b)q(e)f(the)h(case.)21
+b(But)271 1484 y(there)14 b(is)g(a)h(p)q(ossibilit)o(y)e(that)h(its)g(data)h
+(base)g(is)f(not)h(consisten)o(t.)20 b(This)14 b(inconsistency)f(can)271
+1574 y(lead)20 b(to)g(malfunction)d(as)k(it)e(has)h(in)f(the)g(past,)i(and)f
+(in)f(the)h(w)o(orst)g(case)f(to)h(a)g(securit)o(y)271 1664
+y(threat.)209 1796 y(3.)k(In)17 b(step)h(three)e(the)h(serv)o(er)g(tries)f
+(to)i(matc)o(h)e(the)h(query)f(in)h(its)g(o)o(wn)h(authoritativ)o(e)f(data)
+271 1886 y(base.)22 b(In)16 b(principle)e(the)i(same)g(problem)e(as)j(in)f
+(the)g(previous)g(step)g(exists.)209 2018 y(4.)24 b(Step)18
+b(four)g(is)f(resp)q(onsible)h(for)f(\014nding)h(data)h(in)e(the)g(cac)o(he)g
+(once)h(the)f(matc)o(hing)f(phase)271 2108 y(in)k(step)g(three)g(is)f(not)i
+(successful.)32 b(If)20 b(the)f(QNAME)h(is)f(found)i(in)f(one)g(of)g(the)g
+(cac)o(hed)271 2199 y(records,)c(all)e(resource)i(records)f(matc)o(hing)f
+(the)h(QTYPE)h(of)f(the)h(query)e(are)i(copied)f(in)o(to)271
+2289 y(the)21 b(answ)o(er)g(section.)35 b(If)20 b(there)g(is)h(no)g
+(delegation)g(found)h(in)e(its)h(authoritativ)o(e)f(data,)271
+2379 y(the)f(algorithm)g(puts)g(the)g(b)q(est)h(referral)f(found)g(in)g(the)h
+(cac)o(he)e(in)o(to)h(the)g(authoritativ)o(e)271 2469 y(section.)30
+b(In)19 b(these)g(cases,)h(the)f(algorithm)g(b)q(eliev)o(es)e(the)i(data)h
+(that)g(it)f(retriev)o(es)f(from)271 2560 y(the)e(cac)o(he)g(to)g(b)q(e)h
+(unimpaired.)i(As)d(w)o(e)g(sho)o(w)o(ed,)g(this)g(do)q(es)h(not)g
+(necessarily)e(hold.)p eop
+%%Page: 58 67
+66 bop 1901 -100 a Fo(58)209 75 y(5.)24 b(Step)17 b(\014v)o(e)e(is)i(the)f
+(call)f(to)i(another)g(resolv)o(er.)k(The)c(problem)d(here)i(is)h(that)f(the)
+h(resp)q(onse)271 165 y(is)f(blindly)f(b)q(eliev)o(ed,)f(cac)o(hed)i(and)h
+(used.)209 297 y(6.)24 b(Step)d(six)e(do)q(es)j(not)e(con)o(tain)h(a)f(\015a)
+o(w)h(itself,)f(but)g(it)g(demonstrates)g(ho)o(w)h(easy)f(it)g(is)g(to)271
+387 y(add)h(records)f(to)h(the)f(reply)l(,)f(and)i(that)g(a)f(name)f(serv)o
+(er)g(accepts)h(that)g(without)h(man)o(y)271 477 y(constrain)o(ts.)149
+643 y(4.3)50 b(Analysis)15 b(of)i(the)f(Resolv)o(er)f(Algorithm)223
+782 y(In)e(this)g(section)g(w)o(e)f(review)h(the)g(resolv)o(er)f(algorithm)g
+(stated)i(in)f(section)f(2.9.3)i(and)g(analyze)149 873 y(it)k(step)g(b)o(y)g
+(step.)26 b(W)l(e)18 b(are)g(esp)q(ecially)f(lo)q(oking)h(for)g(w)o(eak)g
+(assumptions)g(that)h(do)f(not)h(alw)o(a)o(ys)149 963 y(hold.)j(These)16
+b(assumptions)g(could)g(b)q(e)h(exploited)e(b)o(y)g(attac)o(k)o(ers.)209
+1107 y(1.)24 b(Step)17 b(one)f(in)g(the)h(resolv)o(er's)e(algorithm)g(sho)o
+(ws)j(one)e(of)h(the)f(securit)o(y)f(\015a)o(ws)i(in)f(the)h(pro-)271
+1197 y(to)q(col.)33 b(The)20 b(resolv)o(er)f(searc)o(hes)h(the)f(cac)o(he)g
+(for)i(the)e(desired)h(data.)33 b(If)19 b(the)h(data)h(is)f(in)271
+1288 y(the)g(cac)o(he,)f(the)g(resolv)o(er)f(\\assumes")i(it)f(to)h(b)q(e)f
+(go)q(o)q(d)j(enough)e(for)g(regular)f(use.)31 b(This)271 1378
+y(assumption)15 b(can)g(lead)f(to)i(the)e(use)h(of)g(false)g(records)g(and)g
+(aid)g(an)g(attac)o(k)o(er)f(in)h(his)g(unau-)271 1468 y(thorized)h(attempt)f
+(to)i(access)f(another)h(mac)o(hine.)271 1579 y(Some)k(resolv)o(ers)g
+(o\013er)i(the)f(option)g(at)h(the)f(user)g(in)o(terface)e(to)j(force)e(the)h
+(resolv)o(er)f(to)271 1670 y(ignore)e(cac)o(hed)f(data)h(and)h(alw)o(a)o(ys)e
+(consult)h(an)g(authoritativ)o(e)f(serv)o(er.)27 b(Although)19
+b(this)271 1760 y(approac)o(h)c(w)o(ould)e(solv)o(e)g(the)g(problem,)f(it)h
+(is)h(not)g(recomme)o(nded)d(as)j(the)f(default,)g(as)i(this)271
+1850 y(is)h(v)o(ery)f(ine\016cien)o(t.)209 1982 y(2.)24 b(In)19
+b(step)g(t)o(w)o(o)h(the)e(resolv)o(er)h(lo)q(oks)g(for)h(a)f(name)f(serv)o
+(er)h(to)g(ask)h(for)f(the)g(required)f(data.)271 2072 y(The)13
+b(general)e(strategy)i(is)f(to)g(lo)q(ok)h(for)f(lo)q(cally)g(a)o(v)m
+(ailable)f(name)g(serv)o(er)g(resource)h(records,)271 2163
+y(starting)k(at)g(SNAME,)f(to)o(w)o(ards)h(the)f(ro)q(ot.)22
+b(The)16 b(resolv)o(er)e(has)i(man)o(y)e(c)o(hoices)h(here)g(and)271
+2253 y(dep)q(ending)k(on)g(whic)o(h)e(c)o(hoice)g(it)h(mak)o(es)f(it)h(can)g
+(con)o(tact)g(sound)h(name)f(serv)o(ers)f(or)i(the)271 2343
+y(attac)o(k)o(er's)14 b(name)g(serv)o(er.)20 b(Ho)o(w)o(ev)o(er,)13
+b(if)i(w)o(e)f(assume,)h(that)g(the)g(attac)o(k)o(er)f(has)i(set)f(up)h(his)
+271 2433 y(zones)c(suc)o(h)g(that)g(his)f(name)g(serv)o(er)g(is)g(the)h(only)
+f(one)h(with)g(the)f(necessary)g(information)g(to)271 2524
+y(answ)o(er)16 b(the)f(attac)o(k)o(ed)g(mac)o(hine's)e(query)l(,)h(the)i
+(resolv)o(er)e(has)i(certainly)e(no)i(other)g(c)o(hoice)271
+2614 y(than)h(\014nally)f(con)o(tacting)g(him.)p eop
+%%Page: 59 68
+67 bop 1901 -100 a Fo(59)209 75 y(3.)24 b(Step)d(three)g(sends)g(out)h
+(queries)e(un)o(til)g(a)h(resp)q(onse)h(is)f(receiv)o(ed.)33
+b(The)21 b(strategy)g(is)g(to)271 165 y(cycle)c(around)h(all)g(of)g(the)g
+(addresses)g(for)g(all)g(of)g(the)f(serv)o(ers)g(with)h(a)g(timeout)e(b)q(et)
+o(w)o(een)271 255 y(eac)o(h)g(transmission.)209 387 y(4.)24
+b(In)17 b(step)h(four)f(the)g(resolv)o(er)f(accepts)i(answ)o(er)f(pac)o(k)o
+(ets)f(from)h(name)f(serv)o(ers)g(it)h(has)h(con-)271 477 y(tacted.)33
+b(These)20 b(pac)o(k)o(ets)f(can)h(con)o(tain)g(records)g(in)f(the)h
+(additional)g(section.)33 b(The)20 b(re-)271 568 y(solv)o(er)15
+b(p)q(erforms)g(some)g(prepro)q(cessing)h(on)g(these)g(pac)o(k)o(ets)e(and)j
+(the)e(con)o(tained)g(records)271 658 y(\(see)h(4.1)g(for)g(detailed)f
+(description\),)f(but)i(v)o(ery)f(lik)o(ely)e(accepts)i(them)g(and)h(cac)o
+(hes)f(their)271 748 y(con)o(ten)o(ts.)41 b(Cac)o(hing)23 b(unrequested)f
+(data)i(pro)o(vided)e(b)o(y)g(some)g(unkno)o(wn)h(source)g(can)271
+839 y(lead)18 b(to)g(a)f(ma)s(jor)g(problem)f(but)i(is)f(also)h(necessary)f
+(to)h(obtain)g(a)g(go)q(o)q(d)i(o)o(v)o(erall)c(system)271
+929 y(p)q(erformance.)223 1073 y(If)g(the)h(resolv)o(er)f(has)i(direct)e
+(access)h(to)h(a)f(name)f(serv)o(er's)g(zone,)h(it)g(should)g(c)o(hec)o(k)f
+(to)h(see)g(if)149 1163 y(the)e(desired)e(data)i(is)f(presen)o(t)g(in)g
+(authoritativ)o(e)g(form,)f(and)i(if)f(so,)g(use)h(the)f(authoritativ)o(e)g
+(data)149 1254 y(in)i(preference)f(to)i(the)f(cac)o(he.)223
+1344 y(One)k(could)h(ask)g(where)g(exactly)e(the)i(problem)e(lies:)30
+b(in)21 b(b)q(elieving)e(the)i(cac)o(hed)f(data)i(in)149 1434
+y(step)e(one,)g(or)g(earlier)f(in)g(blindly)f(cac)o(hing)h(additional)h
+(information)f(throughout)i(step)f(four.)149 1524 y(Ob)o(viously)l(,)12
+b(the)h(data)h(should)f(b)q(e)g(correct)g(b)q(efore)g(it)f(is)h(en)o(tered)e
+(in)o(to)i(the)g(cac)o(he.)19 b(That)13 b(ensures)149 1615
+y(the)20 b(in)o(tegrit)o(y)d(of)j(the)f(in)o(ternal)f(data)i(structures,)g
+(whic)o(h)f(is)g(an)g(imp)q(ortan)o(t)g(precondition)g(in)149
+1705 y(most)d(systems.)223 1795 y(But)h(this)g(answ)o(er)h(only)f(shifts)h
+(the)f(question)h(to)f(the)h(origin)f(of)h(these)f(records.)26
+b(Where)17 b(is)149 1886 y(the)g(righ)o(t)g(p)q(oin)o(t)g(to)g(ensure)g(the)g
+(in)o(tegrit)o(y)e(of)j(transmitted)d(resource)i(records?)24
+b(In)17 b(the)g(name)149 1976 y(serv)o(er)h(that)h(writes)g(the)f(records)h
+(in)o(to)f(the)h(additional)g(section?)29 b(That)19 b(can)g(b)q(e)g(violated)
+f(b)o(y)149 2066 y(an)e(attac)o(k)o(er,)e(as)i(w)o(e)f(ha)o(v)o(e)f(pro)o(v)o
+(ed)g(in)h(our)h(exp)q(erimen)o(ts.)i(Or)d(in)g(the)g(name)f(serv)o(er)g(or)i
+(resolv)o(er)149 2156 y(that)i(accepts)e(the)h(resource)g(records,)f(b)q
+(efore)h(they)f(are)h(added)h(to)f(the)f(cac)o(he?)23 b(The)17
+b(problem)149 2247 y(here)e(is)g(that)g(the)g(receiving)e(en)o(tit)o(y)h(has)
+i(no)f(w)o(a)o(y)g(of)g(deciding)f(what)i(is)f(reasonable)h(to)f(b)q(eliev)o
+(e,)149 2337 y(and)i(what)g(can)g(lead)f(to)g(trouble.)223
+2427 y(Neither)d(of)i(the)f(approac)o(hes)h(is)g(feasible)f({)h(the)f(cen)o
+(tral)g(dilemm)o(a)e(in)i(the)g(curren)o(t)g(Domain)149 2518
+y(Name)h(System)g(design.)p eop
+%%Page: 60 69
+68 bop 1901 -100 a Fo(60)149 75 y(4.4)50 b(Ev)m(aluation)16
+b(Criteria)223 214 y(The)j(follo)o(wing)g(sections)h(presen)o(t)f(solutions)h
+(that)f(address)i(the)e(stated)h(problem.)29 b(Most)149 305
+y(of)17 b(the)f(solutions)h(are)f(based)h(on)g(the)f(Domain)g(Name)e(System)h
+(and)i(are)f(not)h(solutions)g(to)g(the)149 395 y(abstract)g(problem.)223
+485 y(As)g(w)o(e)h(ha)o(v)o(e)f(already)h(men)o(tioned,)e(the)i(presen)o(ted)
+f(approac)o(hes)i(are)f(not)g(complete)e(solu-)149 575 y(tions)g(to)g(the)g
+(problem.)j(Most)d(of)g(them)e(w)o(ork)h(only)h(under)f(certain)g(additional)
+h(assumptions,)149 666 y(but)j(then)g(reliably)l(.)27 b(A)19
+b(go)q(o)q(d)i(approac)o(h)e(is)g(probably)g(to)g(not)g(limit)d(a)j(system)f
+(to)h(the)g(appli-)149 756 y(cation)f(of)h(one)f(solution,)g(but)g(to)g
+(impleme)o(n)o(t)d(a)j(reasonable)h(v)m(ariet)o(y)e(of)h(them.)24
+b(This)18 b(v)m(ariet)o(y)149 846 y(should)k(co)o(v)o(er)d(as)j(man)o(y)d
+(cases)i(as)g(p)q(ossible,)h(with)e(few)h(o)o(v)o(erlaps.)34
+b(Some)20 b(of)h(the)f(presen)o(ted)149 937 y(solutions)d(are)f(already)g(in)
+f(use)h(in)g(some)f(systems,)f(while)h(others)h(are)g(in)g(their)f(early)g
+(stages)i(of)149 1027 y(design)g(or)f(dev)o(elopmen)o(t.)223
+1117 y(Our)e(presen)o(tation)h(of)g(eac)o(h)f(solution)h(con)o(tains)g(a)g
+(description)f(and)h(a)g(discussion.)21 b(W)l(e)14 b(use)149
+1207 y(sev)o(eral)i(criteria)f(that)h(are)h(imp)q(ortan)o(t)e(in)h(an)h(ev)m
+(aluation)f(of)g(solutions)h(to)g(our)g(problem:)222 1352 y
+Fj(\017)24 b Fo(The)16 b(\\qualit)o(y")f(of)i(the)e(solution)h(is)g(a)g
+(measuremen)o(t)d(of)j(the)f(radius)h(of)g(applicabilit)o(y)e(of)271
+1442 y(the)g(solution.)21 b(This)13 b(v)m(alue)h(cannot)g(easily)f(b)q(e)h
+(sp)q(eci\014ed,)f(b)q(ecause)h(the)g(set)f(of)h(applicable)271
+1532 y(cases)g(is)e(not)i(precisely)d(giv)o(en.)19 b(W)l(e)13
+b(men)o(tion)e(the)i(cases)g(that)h(are)f(co)o(v)o(ered)e(b)o(y)i(a)g
+(solution)271 1623 y(and)k(try)f(to)h(deriv)o(e)d(from)i(that)g(a)h(judgemen)
+o(t)d(ab)q(out)k(the)e(qualit)o(y)f(of)h(the)g(solution.)222
+1754 y Fj(\017)24 b Fo(The)12 b(\\feasibilit)o(y)e(of)i(the)f(implem)o(en)o
+(t)o(ation")f(of)i(a)g(solution)g(determines)d(ho)o(w)j(m)o(uc)o(h)d
+(e\013ort)271 1845 y(is)19 b(needed)f(to)i(apply)e(the)h(solution)g(to)h(an)f
+(unmo)q(di\014ed)f(v)o(ersion)g(of)i(a)f(state)g(of)g(the)g(art)271
+1935 y(name)c(serv)o(er.)222 2067 y Fj(\017)24 b Fo(The)19
+b(\\complexit)o(y)d(of)j(its)g(implem)o(e)o(n)o(tation")e(measures)g(if)i(mo)
+q(di\014cations)f(in)g(di\013eren)o(t)271 2157 y(areas)c(are)f(in)o(v)o(olv)o
+(ed)d(and)k(ho)o(w)f(complicated)d(their)i(in)o(teraction)g(is.)20
+b(A)12 b(solution)h(can)g(ha)o(v)o(e)271 2247 y(a)h(v)o(ery)f(lo)o(w)g
+(degree)g(of)h(complexit)o(y)-5 b(,)11 b(but)j(require)e(considerable)h
+(implem)o(en)o(tati)o(on)e(e\013ort.)271 2338 y(A)16 b(complex)e(implem)o(en)
+o(tation)f(do)q(es)k(not)g(has)g(to)g(result)f(in)f(a)i(large)f(amoun)o(t)g
+(of)g(co)q(ding.)222 2469 y Fj(\017)24 b Fo(In)18 b(solving)f(the)g(problem)f
+(w)o(e)h(are)h(striving)f(for)h(\\compatibilit)o(y)c(with)k(the)f(original)g
+(de-)271 2560 y(sign.")22 b(A)16 b(solution)g(that)h(do)q(es)g(not)f(require)
+f(c)o(hanges)i(to)f(the)g(DNS)g(proto)q(col)h(is)f(usually)271
+2650 y(preferred)g(o)o(v)o(er)f(one)h(that)h(do)q(es)g({)g(ev)o(en)e(if)h
+(this)g(conformit)o(y)e(has)j(other)f(disadv)m(an)o(tages.)p
+eop
+%%Page: 61 70
+69 bop 1901 -100 a Fo(61)222 75 y Fj(\017)24 b Fo(The)d(Domain)f(Name)f
+(System)g(is)i(a)g(system)e(that)i(resolv)o(es)f(mappings)g(on{line.)34
+b(The)271 165 y(e\016ciency)14 b(of)j(the)e(system)g(and)i(its)f(p)q
+(erformance)f(are)h(imp)q(ortan)o(t)f(factors)i(of)f(in\015uence.)271
+255 y(The)g(compliance)d(of)j(the)f(solution's)h(\\e\016ciency")e(with)h
+(that)h(of)g(the)f(system)f(is)i(equally)271 346 y(imp)q(ortan)o(t.)222
+477 y Fj(\017)24 b Fo(Some)f(of)g(the)g(solutions)h(in)o(v)o(olv)o(e)d(users)
+j(in)f(general.)42 b(F)l(or)23 b(example)e(if)i(the)g(solution)271
+568 y(requires)12 b(a)i(c)o(hange)f(in)f(the)h(user)g(in)o(terface,)f(or)h
+(in)g(an)g(organization's)h(p)q(olicy)e(of)h(handling)271 658
+y(trust.)21 b(The)15 b(user)f(has)h(to)g(learn)f(to)h(handle)f(the)g(c)o
+(hanges,)g(and)h(his)g(appro)o(v)m(al)g(is)f(a)h(crucial)271
+748 y(p)q(oin)o(t.)22 b(W)l(e)16 b(com)o(bine)e(these)i(asp)q(ects)h(in)e
+(the)h(term)f(\\acceptabilit)o(y)g(b)o(y)g(the)h(user.")222
+880 y Fj(\017)24 b Fo(Solutions)15 b(migh)o(t)e(not)i(b)q(e)g(applicable)f
+(in)g(ev)o(ery)f(organizational)i(en)o(vironmen)o(t.)j(W)l(e)c(call)271
+970 y(this)i(criterion)g(\\applicabilit)o(y)e(in)i(an)h(organization.")222
+1102 y Fj(\017)24 b Fo(An)15 b(imp)q(ortan)o(t)e(p)q(oin)o(t)i(in)f(the)h(in)
+o(tro)q(duction)f(of)h(c)o(hanges)g(to)g(systems)e(is)h(the)h(\\transition)
+271 1192 y(pro)q(cess")f(from)e(the)h(original)f(state)h(\(b)q(efore)g(the)g
+(solution)g(is)g(applied\))f(to)h(the)g(new)g(state.)271 1283
+y(In)18 b(case)g(of)g(minor)e(c)o(hanges)i(this)f(transition)h(p)q(erio)q(d)h
+(can)f(b)q(e)f(v)o(ery)g(short)h({)g(sometimes)271 1373 y(hardly)h
+(noticeable.)27 b(If)18 b(c)o(hanges)h(of)f(considerable)g(degree)g(are)h(in)
+o(v)o(olv)o(ed,)d(this)j(pro)q(cess)271 1463 y(pla)o(ys)d(a)h(ma)s(jor)e
+(role)h(in)g(the)g(c)o(hange)g(managemen)o(t.)222 1595 y Fj(\017)24
+b Fo(The)16 b(\\transparency)g(of)g(the)f(solution")h(in)o(v)o(olv)o(es)d
+(the)j(user)f(in)o(terface)f(and)i(the)f(soft)o(w)o(are)271
+1685 y(in)o(terface)e(to)i(the)f(system.)19 b(This)c(p)q(oin)o(t)f(examines)f
+(another)i(notion)g(than)f(the)h(\\compat-)271 1776 y(ibilit)o(y)h(with)i
+(the)g(original)f(design,")i(whic)o(h)e(only)h(in)o(v)o(olv)o(es)e(the)i
+(proto)q(col)g(issue)g(|)g(not)271 1866 y(the)e(user.)149 2031
+y(4.5)50 b(The)16 b(Berk)o(eley)d(P)o(atc)o(h)223 2171 y(W)l(e)i(already)h
+(men)o(tioned)d(the)j(Berk)o(eley)d(soft)o(w)o(are)j(patc)o(h)f(in)h(some)e
+(sections)i(of)g(this)g(thesis)149 2261 y(and)h(explained)e(it)h(in)g(detail)
+g(in)f(Section)h(3.5.6.)223 2351 y(This)11 b(\014rst)h(attempted)e(defense,)i
+(dev)o(elop)q(ed)f(at)h(the)f(Univ)o(ersit)o(y)e(of)j(Berk)o(eley)l(,)d(CA)j
+(,)f(consists)149 2442 y(of)16 b(mo)q(di\014cations)e(of)h(the)g(\\rlogind")h
+(and)g(\\rshd")g(co)q(de.)21 b(The)15 b(idea)g(is)f(to)i(v)m(alidate)e(the)h
+(in)o(v)o(erse)149 2532 y(mapping)h(tree)g(b)o(y)f(lo)q(oking)i(at)g(the)f
+(corresp)q(onding)h(no)q(de)g(on)g(the)f(forw)o(ard)h(mapping)e(tree.)21
+b(S.)149 2622 y(Bello)o(vin)e(describ)q(es)h(the)g(metho)q(d)g(used)h(b)o(y)f
+(the)g(patc)o(h)h(in)f([Bel92)o(])g(as)h(follo)o(ws:)30 b(\\T)l(o)21
+b(detect)p eop
+%%Page: 62 71
+70 bop 1901 -100 a Fo(62)149 75 y(this,)19 b(w)o(e)f(p)q(erform)g(a)h
+(cross{c)o(hec)o(k;)f(using)h(the)f(returned)g(name,)g(w)o(e)g(do)h(a)g(forw)
+o(ard)g(c)o(hec)o(k)e(to)149 165 y(learn)e(the)g(legal)g(address)h(for)f
+(that)h(host.)21 b(If)15 b(that)h(name)e(is)h(not)g(listed,)f(or)i(if)e(the)h
+(addresses)h(do)149 255 y(not)h(matc)o(h,)d(alarms,)h(gongs,)j(and)f(to)q
+(csins)f(are)h(sounded.")223 346 y(Refer)e(to)i(the)f(description)f(of)i(the)
+f(algorithm)f(in)h(Section)g(3.5.6)g(and)h(Figure)f(3.2.)223
+436 y(The)c(\014x)g(is)g(easily)f(installed)h(and)h(not)f(v)o(ery)f(complex.)
+18 b(Its)12 b(compatibilit)o(y)d(with)j(the)g(existing)149
+526 y(Domain)i(Name)e(System)h(proto)q(col)h(is)g(another)h(adv)m(an)o(tage.)
+21 b(The)14 b(transition)h(pro)q(cess)f(to)h(mo)o(v)o(e)149
+616 y(to)k(a)g(name)e(serv)o(er)g(that)i(con)o(tains)f(the)h(patc)o(h)f(is)g
+(not)h(di\016cult)e(or)h(complex.)26 b(A)18 b(few)g(lines)f(of)149
+707 y(co)q(de)i(ha)o(v)o(e)f(to)h(b)q(e)g(inserted)e(in)o(to)i(the)f(name)f
+(serv)o(er)h(co)q(de,)h(and)g(the)f(name)g(serv)o(er)f(has)i(to)g(b)q(e)149
+797 y(recompiled)14 b(and)j(started.)223 887 y(Although)22
+b(w)o(e)g(regard)h(this)f(patc)o(h)g(as)h(an)g(obligatory)g(mo)q
+(di\014cation)e(to)i(\\rlogind")g(and)149 978 y(\\rshd,")15
+b(it)e(is)g(limited)d(in)j(its)g(scop)q(e.)21 b(It)13 b(can)g(easily)g(b)q(e)
+g(coun)o(tered)g(using)g(the)h(metho)q(ds)e(demon-)149 1068
+y(strated)j(throughout)h(Section)e(3.5.6.)21 b(Because)14 b(a)h(name)e(serv)o
+(er)h(alw)o(a)o(ys)g(prefers)g(authoritativ)o(e)149 1158 y(data)i(o)o(v)o(er)
+d(non{authoritativ)o(e)i(records,)g(it)f(is)g(imp)q(ossible)f(to)i(p)q(oison)
+g(the)g(cac)o(he)e(of)i(a)g(primary)149 1248 y(or)h(secondary)f(serv)o(er)g
+(for)g(a)h(zone.)k(Th)o(us,)c(an)f(additional)g(false)g(A)g(record)g(cannot)h
+(b)q(e)f(inserted)149 1339 y(in)o(to)h(the)g(cac)o(he,)f(and)i(the)f(cross{c)
+o(hec)o(k)f(will)h(detect)f(the)h(tamp)q(ering.)223 1429 y(Ov)o(erall,)22
+b(the)h(patc)o(h)f(is)h(a)g(true)g(solution)g(if)f(trust)h(can)g(b)q(e)g
+(extended)f(only)g(within)h(the)149 1519 y(scop)q(e)c(of)f(authoritativ)o(e)f
+(data,)h(and)h(if)e(the)g(attac)o(k)o(er)g(do)q(es)i(not)f(use)g(the)f(more)g
+(sophisticated)149 1610 y(attac)o(king)h(metho)q(d.)26 b(In)18
+b(case)g(the)f(attac)o(k)o(er)g(supplies)h(the)g(additional)g(\\A")g(record)g
+(with)g(the)149 1700 y(answ)o(er)13 b(to)g(the)f(rev)o(erse)g(lo)q(okup,)h
+(and)g(trust)g(is)f(extended)g(to)h(p)q(ossibly)g(un)o(trust)o(w)o(orth)o(y)f
+(sources,)149 1790 y(this)17 b(metho)q(d)e(will)g(fail.)149
+1956 y(4.6)50 b(Examining)14 b(Berk)o(eley)g(\\r{Commands")223
+2095 y(The)19 b(Berk)o(eley)e(r{commands)i(extensiv)o(ely)e(use)i(the)h
+(\\.rhosts")h(and)f(\\/etc/hosts.equiv")149 2185 y(\014les)14
+b(to)g(increase)f(con)o(v)o(enien)o(t)f(net)o(w)o(ork)i(access.)20
+b(In)14 b(Section)f(3.5.3,)h(w)o(e)g(discussed)g(the)f(T)l(rusted)149
+2276 y(Net)o(w)o(ork)j(concept.)21 b(R{commands)15 b(suc)o(h)h(as)h(remote)e
+(login)i(and)g(remote)d(shell)i(o\013er)h(the)f(p)q(os-)149
+2366 y(sibilit)o(y)c(to)j(extend)e(trust)h(to)g(other)g(mac)o(hines.)19
+b(Users)14 b(and)g(system)f(administrators)g(can)h(build)149
+2456 y(individual)j(net)o(w)o(orks)h(of)h(trust.)27 b(What)18
+b(lo)q(oks)h(lik)o(e)e(a)h(go)q(o)q(d)i(idea)e(at)h(the)f(\014rst)g(glance)g
+(pro)o(v)o(es)149 2547 y(v)o(ery)d(dangerous)j(in)e(some)f(cases.)p
+eop
+%%Page: 63 72
+71 bop 1901 -100 a Fo(63)223 75 y(The)15 b(existence)e(of)i(these)g
+(structures)g(of)g(trust)g(is)g(necessary)g(for)g(the)g(break{in)g(to)g(happ)
+q(en.)149 165 y(Ob)o(viously)l(,)e(the)h(break{in)g(is)g(prev)o(en)o(ted)f
+(if)g(w)o(e)h(prohibit)g(the)f(usage)i(of)g(trusted)f(hosts)h(or)f(users)149
+255 y(completely)l(.)37 b(It)22 b(is)g(tec)o(hnically)e(p)q(ossible)i(to)h
+(disallo)o(w)f(the)g(usage)h(of)g(\\trust")g(in)f(Berk)o(eley)149
+346 y(commands.)29 b(The)19 b(c)o(hoice)f(can)h(b)q(e)h(made)e(b)o(y)g(the)h
+(system)f(administrator)h(at)g(compile)e(time.)149 436 y(Ho)o(w)o(ev)o(er,)f
+(b)q(eing)h(able)g(to)h(access)f(other)g(mac)o(hines)f(without)h(passw)o
+(ords)i(mak)o(es)d(the)h(w)o(ork)g(in)149 526 y(a)j(net)o(w)o(orking)f(en)o
+(vironmen)o(t)e(easier.)31 b(Once)19 b(used)g(to)h(the)g(comfort,)e(not)i
+(man)o(y)f(users)g(agree)149 616 y(to)f(sacri\014ce)f(their)g(con)o(v)o
+(enience)e(for)j(the)f(prev)o(en)o(tion)f(of)i(\\h)o(yp)q(othetical")f
+(securit)o(y)f(concerns.)149 707 y(The)21 b(trade{o\013)g(hereb)o(y)f(w)o
+(ould)g(con)o(tain)g(the)g(loss)h(of)f(v)o(ery)f(con)o(v)o(enien)o(t)g(and)h
+(in)g(man)o(y)f(cases)149 797 y(necessary)d(to)q(ols)i(for)e(trouble)g(free)g
+(connection)f(to)i(hosts)g(that)g(are)f(accessed)g(frequen)o(tly)l(.)223
+887 y(A)i(less)h(\\safe")i(solution)e(w)o(ould)g(b)q(e)h(to)f(limit)e(trust)i
+(to)h(lo)q(cally)e(administered)g(zones,)h(i.e.)149 978 y(authoritativ)o(e)i
+(zones,)g(where)f(the)h(Berk)o(eley)d(patc)o(h)i(w)o(orks)h(reliably)l(.)33
+b(As)20 b(w)o(e)h(disco)o(v)o(ered)e(in)149 1068 y(Section)k(4.5,)h(limiting)
+d(trust)i(to)g(certain)g(zones)g(\014xes)g(the)f(\015a)o(w.)42
+b(An)23 b(organization)h(could)149 1158 y(issue)c(the)f(p)q(olicy)g(that)g
+(only)h(lo)q(cal)f(trust)h(is)f(allo)o(w)o(ed.)30 b(In)19 b(some)f
+(organizations)i(this)g(can)f(b)q(e)149 1248 y(considered)13
+b(a)h(reasonable)h(approac)o(h)f(if)f(hardly)g(an)o(y)h(remote)e(accesses)h
+(are)h(originated)f(outside)149 1339 y(of)i(the)g(\\o)o(wn")h(zone)e(to)h
+(the)g(\\o)o(wn")h(zone.)k(Additional)14 b(to)q(ols)i(w)o(ould)f(b)q(e)g
+(necessary)f(to)h(enforce)149 1429 y(the)d(p)q(olicy)l(,)f(suc)o(h)h(as)g(a)g
+(script)f(that)i(p)q(erio)q(dically)d(c)o(hec)o(ks)g(en)o(tries)h(in)g
+(\\.rhosts")i(\014les.)20 b(If)11 b(p)q(erio)q(dic)149 1519
+y(c)o(hec)o(ks)i(are)h(still)f(to)q(o)i(w)o(eak,)e(the)h(r{command)e(implem)o
+(en)o(tati)o(ons)g(could)i(b)q(e)g(c)o(hanged)g(in)f(a)i(w)o(a)o(y)149
+1610 y(that)h(users)f(cannot)g(directly)f(mo)q(dify)f(their)h(database)i(of)g
+(trusted)e(mac)o(hines)f(\(\\.rhosts"\),)j(but)149 1700 y(ha)o(v)o(e)h(to)h
+(use)f(a)h(sp)q(ecial)f(program)g(to)h(manage)f(trust{en)o(tries.)24
+b(The)18 b(data)g(m)o(ust)e(b)q(e)h(k)o(ept)g(in)g(a)149 1790
+y(protected)i(data)h(area)f(of)g(the)g(op)q(erating)g(system)f(managed)g(b)o
+(y)h(the)f(k)o(ernel.)28 b(This)19 b(program)149 1880 y(could)e(\014lter)g
+(out{of{zone)h(en)o(tries)e(at)h(the)g(time)e(the)i(user)g(w)o(an)o(ted)f(to)
+i(en)o(ter)e(them.)22 b(It)16 b(w)o(ould)149 1971 y(also)c(con)o(tain)f(the)f
+(p)q(ossibilit)o(y)g(of)h(managing)g(setup)g(c)o(hanges)g(cen)o(trally)l(.)18
+b(This)11 b(solution)g(actually)149 2061 y(prop)q(oses)18 b(an)f(automatized)
+e(pro)q(cedure)h(to)h(implem)o(en)n(t)d(an)i(organization's)h(p)q(olicy)l(.)
+223 2151 y(If)g(the)g(nature)g(of)h(connections)f(allo)o(ws)h(a)g(p)q(olicy)e
+(suc)o(h)i(as)g(describ)q(ed)e(ab)q(o)o(v)o(e,)i(implem)o(e)o(n)o(t-)149
+2242 y(ing)k(it)e(is)h(a)h(ma)s(jor)e(e\013ort.)36 b(Some)20
+b(system)g(scripts)h(ha)o(v)o(e)f(to)i(b)q(e)f(written)f(to)i(ensure)f(prop)q
+(er)149 2332 y(usage,)j(op)q(erating)f(system)d(co)q(de)i(and)g(r{command)e
+(co)q(de)i(m)o(ust)e(b)q(e)i(mo)q(di\014ed,)g(and)g(a)g(new)149
+2422 y(user)17 b(in)o(terface)f(has)h(to)g(b)q(e)g(dev)o(elop)q(ed.)22
+b(Users)17 b(shall)f(b)q(e)h(trained)g(ho)o(w)g(to)g(apply)g(the)f(c)o
+(hanged)149 2512 y(facilit)o(y)e(and)i(ha)o(v)o(e)f(to)i(b)q(e)e(made)g
+(familiar)f(with)h(the)h(new)f(p)q(olicy)h(and)g(the)f(new)h(user)g(in)o
+(terface)149 2603 y(\(whic)o(h)h(could)g(easily)f(impro)o(v)o(e)e(the)j
+(existing)g(one\).)24 b(Adv)m(an)o(tages)17 b(of)g(this)g(new)h(approac)o(h)f
+(are)p eop
+%%Page: 64 73
+72 bop 1901 -100 a Fo(64)149 75 y(the)21 b(compatibilit)o(y)d(with)k(the)e
+(existing)h(Domain)f(Name)g(System)g(proto)q(col)i(and)f(additional)149
+165 y(b)q(ene\014ts)c(in)f(further)g(securit)o(y)f(related)g(issues.)223
+255 y(Ov)o(erall,)f(a)j(v)o(ery)f(w)o(eak)g(p)q(oin)o(t)h(in)f(the)h(Berk)o
+(eley)c(deriv)o(ed)j(UNIX)e(systems)i(is)g(the)h(usage)g(of)149
+346 y(trust.)27 b(This)18 b(thesis)f(exploits)h(only)f(one)h(of)h(sev)o(eral)
+d(kno)o(wn)i(\015a)o(ws)h(based)f(up)q(on)h(trust.)27 b(Using)149
+436 y(trust{based)c(mec)o(hanism)o(s)c(requires)h(thinking)h(ab)q(out)h(a)g
+(c)o(hange)f(in)g(individual)f(p)q(olicies)g(in)149 526 y(dealing)e(with)g
+(gran)o(ting)g(trust)h(to)f(others.)27 b(W)l(e)17 b(can)h(conclude,)g(b)o(y)f
+(citing)g(S.)h(Bello)o(vin:)k(\\If)c(a)149 616 y(host)i(trusts)g(another)f
+(host)h(not)f(named)f(in)h(a)g(lo)q(cal)g(zone,)g(its)f(name)g(serv)o(er)g
+(cannot)i(protect)149 707 y(it.")i(\([Bel90b)o(]\))223 797
+y(Although)e(w)o(e)f(concen)o(trate)h(on)g(the)g(Berk)o(eley)d(\\r{commands")
+j(in)f(this)h(section,)g(w)o(e)g(do)149 887 y(not)d(forget)f(that)h(there)e
+(are)h(other)g(w)o(a)o(ys)g(in)g(exploiting)f(the)h(\015a)o(w.)21
+b(F)l(or)16 b(example)e(in)o(tercepting)149 978 y(electronic)f(mail)f(is)i(a)
+g(target)h(of)f(attac)o(k)o(ers;)g(esp)q(ecially)e(electronic)h(mail)f(that)i
+(is)g(exc)o(hanged)g(b)o(y)149 1068 y(securit)o(y)h(agencies)h(and)h(securit)
+o(y)e(related)g(organizations.)149 1233 y(4.7)50 b(Restricting)15
+b(Public)g(Information)g(Access)223 1373 y(What)j(mak)o(es)d(the)i(break{in)h
+(p)q(ossible)f(in)g(the)h(\014rst)f(place)g(is)g(gathering)h(necessary)f
+(infor-)149 1463 y(mation)g(ab)q(out)i(host)g(names)d(of)i(trusting)g(mac)o
+(hines)e(and)i(user)g(names)f(on)h(di\013eren)o(t)f(systems)149
+1553 y(trusting)h(eac)o(h)f(other.)26 b(This)18 b(section)f(discusses)g(ho)o
+(w)h(to)g(obtain)g(the)g(names)e(and)j(whether)e(it)149 1644
+y(is)f(feasible)g(or)g(reasonable)h(to)g(restrict)e(access)h(to)h(this)f
+(information.)223 1734 y(W)l(e)i(are)h(not)g(discussing)f(random)h(patterns)g
+(of)g(trust)g(that)g(migh)o(t)d(exist)i(b)q(et)o(w)o(een)g(hosts,)149
+1824 y(but)h(t)o(w)o(o)f(common)e(patterns)j(using)f(a)h(systematic)d
+(approac)o(h.)28 b(The)18 b(follo)o(wing)g(discussion)h(is)149
+1915 y(based)f(on)g(section)f(3)g(in)g([Bel90b)o(].)24 b(In)17
+b(a)h(cluster)e(of)i(time{sharing)e(mac)o(hines,)f(eac)o(h)i(mac)o(hine)149
+2005 y(is)22 b(lik)o(ely)d(to)j(extend)f(trust)g(to)h(all)f(its)h(p)q(eers.)
+37 b(This)21 b(pattern)h(is)f(not)h(common)e(to)i(the)f(gen-)149
+2095 y(eral)g(user)f(p)q(opulation,)j(but)d(it)h(is)f(applicable)g(to)h
+(systems)e(programming)g(and)j(op)q(erational)149 2185 y(sta\013.)g(Another)
+16 b(t)o(ypical)e(pattern)h(is)g(the)h(o)q(ccurrence)e(of)i(\014le)f(serv)o
+(ers)f(that)i(trust)g(their)e(clien)o(ts,)149 2276 y(who)20
+b(serv)o(e)e(as)i(a)g(source)f(of)g(extra)g(CPU)g(cycles.)29
+b(\\Dataless")20 b(clien)o(ts)e(will)g(frequen)o(tly)f(trust)149
+2366 y(administrativ)o(e)d(mac)o(hines)g(to)j(p)q(ermit)e(soft)o(w)o(are)h
+(main)o(tenance.)223 2456 y(There)h(are)h(sev)o(eral)f(net)o(w)o(orking)h
+(utilities)e(that)i(are)g(generally)f(a)o(v)m(ailable)h(to)g(all)g(users)g
+(on)149 2547 y(a)f(system)e(to)h(sp)o(y)g(out)h(the)f(w)o(an)o(ted)g
+(information.)p eop
+%%Page: 65 74
+73 bop 1901 -100 a Fo(65)223 75 y(A)22 b(com)o(bined)f(usage)i(of)g
+(\\snmpnetstat")g(and)g(\\\014nger")h(can)f(do)g(the)g(job.)41
+b(One)22 b(migh)o(t)149 165 y(ob)s(ject)e(that)g(\\snmpnetstat")g(is)g(not)g
+(alw)o(a)o(ys)g(a)o(v)m(ailable)f(and)i(that)f(some)f(sites)h(also)g
+(restrict)149 255 y(the)c(usage)g(of)g(the)f(\014nger)h(daemon)f(on)h(their)f
+(mac)o(hines.)k(But)c(there)g(are)h(more)e(common)g(to)q(ols)149
+346 y(that)j(can)g(b)q(e)f(abused.)223 436 y(Examination)e(of)h(mail)e(or)j
+(news)f(headers)g(giv)o(es)f(us)i(information)e(ab)q(out)i(where)f(mail)e
+(orig-)149 526 y(inated)23 b(and)h(whic)o(h)e(path)i(it)f(to)q(ok.)42
+b(The)23 b(\\Receiv)o(ed:")34 b(\014elds)23 b(con)o(tain)f(a)i(complete)d
+(trace)149 616 y(of)g(the)f(route.)34 b(Sometimes)18 b(this)i(route)g(con)o
+(tains)h(w)o(orkstation)g(-)g(serv)o(er)e(names)g(that)i(trust)149
+707 y(eac)o(h)g(other.)37 b(A)21 b(similar)f(tric)o(k)g(is)h(p)q(ossible)h
+(using)f(\\traceroute")h(once)g(w)o(e)f(kno)o(w)g(a)h(remote)149
+797 y(w)o(orkstation)17 b(name.)223 887 y(W)l(e)g(can)h(also)g(gain)g(m)o(uc)
+o(h)d(insigh)o(t)i(using)h(the)f(Domain)g(Name)f(System)g(itself.)24
+b(The)17 b(SO)o(A)149 978 y(records)j(con)o(tain)f(a)g(mac)o(hine)e(name)h
+(and)i(a)g(host)f(address)h(of)g(a)f(privileged)f(user.)30
+b(With)19 b(the)149 1068 y(host)c(name)e(w)o(e)h(can)g(retriev)o(e)e(the)i
+(IP)g(address)h(and)f(then)g(with)g(a)h(zone)f(transfer)g(obtain)g(names)149
+1158 y(of)21 b(other)f(mac)o(hines)e(in)i(the)g(net)o(w)o(ork)g(lo)q(cal)g
+(to)h(that)f(mac)o(hine.)31 b(Ev)o(en)20 b(if)f(the)h(zone)g(transfer)149
+1248 y(is)h(disabled,)g(w)o(e)f(could)h(issue)g(254)g(rev)o(erse)f(lo)q
+(okups)h(to)h(collect)d(the)h(names)g(w)o(e)g(seek.)34 b(The)149
+1339 y(HINF)o(O)15 b(records)h(giv)o(e)f(additional)i(information.)223
+1429 y(F)l(urther)c(\\help")h(is)g(pro)o(vided)f(b)o(y)h(\\ftp")g(\(some)f
+(serv)o(ers)g(o\013er)i(the)e(service,)g(only)g(few)h(w)o(ork-)149
+1519 y(stations)23 b(do\),)f(\\sm)o(tp")f(\(mac)o(hines)e(that)j(run)g(mail)d
+(serv)o(ers\),)i(and)h(Sun's)g(\\rp)q(cinfo")g(\(what)149 1610
+y(services)f(are)g(running?\))38 b(Published)21 b(material)e(is)i(a)o(v)m
+(ailable)g(from)f(some)h(univ)o(ersities)e(that)149 1700 y(describ)q(es)d
+(the)g(setup)h(of)f(their)g(net)o(w)o(orks)g(on)g(a)h(high)f(lev)o(el.)223
+1790 y(Some)j(systems)h(still)f(use)i(the)g(same)e(\\/etc/hosts.equiv")i
+(\014les)g(on)g(man)o(y)e(hosts)j(just)f(to)149 1880 y(simplify)14
+b(systems)h(administration.)223 1971 y(The)23 b(men)o(tioned)e(collection)h
+(of)h(to)q(ols)i(sho)o(ws)f(that)f(it)g(is)g(a)h(di\016cult)e(task)h(to)h
+(limit)d(in-)149 2061 y(formation)i(access)g(without)g(sacri\014cing)g(the)g
+(legitimate)d(utilization)i(of)i(net)o(w)o(ork)e(services.)149
+2151 y(Prev)o(en)o(ting)d(someone)g(from)f(gathering)i(the)g(necessary)f
+(information)g(is)g(nearly)h(imp)q(ossible.)149 2242 y(T)l(o)q(o)c(man)o(y)e
+(services)f(rely)h(on)h(address)g(information,)f(and)h(most)f(p)q(eople)h(w)o
+(ould)f(complain)g(ter-)149 2332 y(ribly)f(if)h(they)g(w)o(ere)f(depriv)o(ed)
+g(of)h(useful)g(to)q(ols)h(suc)o(h)f(as)g(\014nger,)h(email,)d(and)i(news.)21
+b(The)14 b(idea)g(of)149 2422 y(op)q(en)20 b(systems)d(requires)h(op)q(en)h
+(access)f(to)h(information)f(services)f(and)j(address)f(information.)149
+2512 y(Therefore,)13 b(most)f(system)f(administrators)g(ha)o(v)o(e)h(decided)
+g(that)g(the)h(b)q(ene\014ts)f(of)h(these)f(utilities)149 2603
+y(out)o(w)o(eigh)k(the)g(risks.)p eop
+%%Page: 66 75
+74 bop 1901 -100 a Fo(66)223 75 y(Ov)o(erall,)11 b(w)o(e)i(think)f(that)h(sh)
+o(utting)g(do)o(wn)h(w)o(ell{kno)o(wn)e(and)h(widely)f(used)h(services)f(is)h
+(not)g(a)149 165 y(go)q(o)q(d)k(idea.)k(The)14 b(lac)o(k)g(of)h(these)f
+(services)g(w)o(ould)h(h)o(urt)f(functionalit)o(y)f(and)j(the)e(purp)q(ose)i
+(of)f(the)149 255 y(In)o(ternet)h(to)i(a)f(considerable)f(degree.)24
+b(There)16 b(are)h(to)q(o)h(man)o(y)e(w)o(a)o(ys)h(to)g(gather)h(the)f
+(necessary)149 346 y(information;)e(it)h(w)o(ould)g(b)q(e)h(a)f(hop)q(eless)h
+(job)f(to)h(protect)f(the)g(In)o(ternet)f(against)i(abuse.)149
+511 y(4.8)50 b(Adjusting)16 b(DNS)g(Up)q(date)g(In)o(terv)m(als)223
+651 y(Some)d(sites)h(ha)o(v)o(e)f(connections)h(c)o(hie\015y)f(with)h(mac)o
+(hines)e(outside)i(of)h(their)e(zones)i(that)f(sta)o(y)149
+741 y(stable)20 b(in)f(the)g(sense)g(that)h(host)g(name)e(to)i(IP)f(address)h
+(mapping)f(will)f(sta)o(y)h(the)g(same)f(for)i(a)149 831 y(long)15
+b(time.)k(The)14 b(idea)g(is)g(to)g(en)o(ter)g(long)g(TTL)i(v)m(alues)e(in)o
+(to)g(the)g(resource)g(records,)g(v)m(alues)g(that)149 921
+y(exceed)h(the)h(curren)o(tly)f(implem)o(en)n(ted)e(threshold)j(of)h(1)g(w)o
+(eek.)j(Limits)14 b(could)i(b)q(e)h(increased)e(up)149 1012
+y(to)k(6,)g(12)g(mon)o(ths,)e(or)i(ev)o(en)e(longer,)i(dep)q(ending)f(on)h
+(the)f(situation.)27 b(If)18 b(this)g(data)i(is)e(en)o(tered)149
+1102 y(with)j(great)g(care)f(to)h(ensure)g(correctness)f(of)h(the)f
+(mappings,)h(the)f(DNS)h(based)g(break{in)g(is)149 1192 y(prev)o(en)o(ted.)
+223 1283 y(This)g(approac)o(h)h(is)f(limited)e(b)o(y)h(its)i(scop)q(e)f(of)h
+(applicabilit)o(y)l(,)e(but)h(it)g(is)g(a)h(solution)g(with)149
+1373 y(man)o(y)17 b(adv)m(an)o(tages.)27 b(It)18 b(go)q(es)g(with)g(the)g
+(curren)o(t)f(Domain)g(Name)f(System)g(proto)q(col)j(and)f(can)149
+1463 y(b)q(e)c(implem)o(en)n(ted)c(without)k(m)o(uc)o(h)d(e\013ort,)i(b)o(y)g
+(simply)e(c)o(hanging)j(the)f(constan)o(t)g(max)p 1732 1463
+15 2 v 17 w(cac)o(he)p 1865 1463 V 16 w(ttl)1930 1445 y Fm(1)149
+1553 y Fo(in)h(the)g(name)e(serv)o(er)h(co)q(de)h(and)g(recompiling)e(the)h
+(system.)19 b(As)14 b(all)f(necessary)h(en)o(tries)e(are)i(k)o(ept)149
+1644 y(in)19 b(the)f(lo)q(cal)g(cac)o(he,)g(the)h(system)e(pro)o(vides)h(v)o
+(ery)f(quic)o(k)g(replies)g(to)i(queries.)27 b(It)18 b(hardly)h(ev)o(er)149
+1734 y(uses)e(the)f(net)o(w)o(ork)g(and)g(therefore)g(sa)o(v)o(es)g
+(bandwidth)h(on)f(the)g(medium)d(for)k(other)f(tasks.)223 1824
+y(This)11 b(approac)o(h)i(has)f(the)f(problem)f(of)i(v)m(alidating)g(the)f
+(host)h(name)e(to)i(IP)g(address)g(mappings)149 1915 y(b)q(efore)17
+b(they)g(are)g(cac)o(hed.)23 b(Ho)o(w)16 b(can)i(it)e(b)q(e)h(ensured)g(that)
+h(the)e(mappings)h(are)g(correct)f(in)h(the)149 2005 y(\014rst)k(place?)34
+b(Certainly)l(,)20 b(a)h(false)f(en)o(try)f(w)o(ould)i(sta)o(y)f(for)h(a)g
+(long)g(time,)d(and)j(the)g(attac)o(k)o(er's)149 2095 y(address)e(w)o(ould)e
+(b)q(e)g(\014nally)g(noted.)25 b(But)17 b(do)q(es)h(that)g(really)e(help,)h
+(once)g(misc)o(hief)d(is)k(done?)25 b(It)149 2185 y(migh)o(t)15
+b(aid)h(in)g(prosecution)h(e\013orts,)f(but)h(only)f(little)e(in)i(prev)o(en)
+o(tion.)223 2276 y(One)d(of)h(the)g(original)f(reasons)i(to)f(in)o(tro)q
+(duce)g(the)f(Domain)g(Name)f(System)g(w)o(as)j(to)f(manage)149
+2366 y(the)21 b(dynamic)f(b)q(eha)o(vior)h(of)h(c)o(hanges)f(in)g(the)g(data)
+h(base.)37 b(This)21 b(approac)o(h)h(\014xes)f(mappings)149
+2456 y(for)d(a)h(long)f(time)d(and)k(uses)f(a)g(p)q(o)o(w)o(erful)f
+(distributed)g(database)i(system)d(for)i(an)h(infrequen)o(tly)149
+2547 y(happ)q(ening)h(up)q(date)g(pro)q(cess.)29 b(Although)19
+b(w)o(e)g(are)g(not)g(talking)g(ab)q(out)h(a)f(static)g(mapping)f(in)p
+149 2590 720 2 v 206 2621 a Fl(1)224 2636 y Fk(in)c(BIND)g(v)o(ersion)g
+(4.8.3)e(\(7*24*60*60\))g(seconds)j(=)f(one)g(w)o(eek)p eop
+%%Page: 67 76
+75 bop 1901 -100 a Fo(67)149 75 y(this)14 b(section,)f(a)h(w)o(ell{main)o
+(tained)d(HOSTS.TXT)i(\014le)g(w)o(ould)g(do)i(the)e(job)h(with)f(less)h(o)o
+(v)o(erhead.)149 165 y(W)l(e)24 b(will)f(presen)o(t)g(the)h(discussion)g(ab)q
+(out)h(abandoning)h(the)d(Domain)g(Name)g(System)f(and)149
+255 y(returning)17 b(to)f(the)g(previous)g(system)f(in)h(Section)g(4.9.)223
+346 y(Ov)o(erall,)10 b(the)h(approac)o(h)g(of)h(extending)e(TTL)i(v)m(alues)f
+(to)h(a)f(long)g(p)q(erio)q(d)h(of)f(time)e(is)i(a)h(safe)f(and)149
+436 y(feasible)19 b(metho)q(d)g(in)g(en)o(vironmen)o(ts)e(where)i(the)g
+(additional)h(condition)f(of)h(static)f(mappings)149 526 y(with)12
+b(long)g(lifetimes)d(is)j(giv)o(en.)19 b(Ho)o(w)o(ev)o(er,)10
+b(in)i(this)f(case)h(not)h(the)e(Domain)h(Name)e(System)g(seems)149
+616 y(to)k(b)q(e)f(the)g(righ)o(t)f(approac)o(h,)i(but)f(a)h(lo)q(cally)e(w)o
+(ell{administered)e(static)i(mapping)h(mec)o(hanism)o(.)149
+782 y(4.9)50 b(Abandoning)17 b(the)f(Domain)f(Name)g(System)223
+921 y(It)c(could)g(b)q(e)h(suggested)g(to)g(abandon)h(the)e(DNS)h(and)g
+(either)e(return)h(to)h(the)g(previous)f(system)149 1012 y(with)k(a)h(static)
+f(host)h(table,)e(or)i(mo)o(v)o(e)d(on)j(to)f(another)h(system,)d(that)j(has)
+g(y)o(et)e(to)i(b)q(e)f(dev)o(elop)q(ed.)149 1102 y(W)l(e)21
+b(are)g(not)h(going)g(to)f(talk)g(ab)q(out)h(p)q(ossible)f(future)g(dev)o
+(elopmen)o(t)d(of)j(the)g(Domain)f(Name)149 1192 y(System)d(here,)g(but)h(ab)
+q(out)i(returning)e(to)g(the)g(previous)g(system.)25 b(Abandoning)18
+b(the)g(Domain)149 1283 y(Name)d(System)g(is)h(not)g(an)h(extreme)c(scenario)
+k(of)f(what)h(w)o(e)f(describ)q(ed)g(in)f(Section)h(4.8,)g(as)h(our)149
+1373 y(solution)g(there)f(only)g(assumed)f(slo)o(w)i(dynamic)d(b)q(eha)o
+(vior.)223 1463 y(This)j(section)h(suggests)h(an)f(again)g(cen)o(tralized)e
+(managemen)o(t)f(of)j(the)g(mapping)e(data.)27 b(In)149 1553
+y(this)18 b(approac)o(h,)h(mappings)f(can)g(c)o(hange)g(frequen)o(tly)l(,)e
+(but)j(c)o(hanges)f(ha)o(v)o(e)f(to)i(b)q(e)f(rep)q(orted)g(to)149
+1644 y(a)h(cen)o(tral)e(authorit)o(y)h(that)g(manages)g(the)g(whole)g(Domain)
+g(Name)e(Space)i(in)g(con)o(trast)g(to)h(the)149 1734 y(Domain)f(Name)e
+(System)g(approac)o(h)j(of)f(managing)f(zones)h(through)h(delegated)f(lo)q
+(cal)f(author-)149 1824 y(ities.)30 b(This)20 b(w)o(ould)g(not)g(solv)o(e)e
+(the)i(problem,)e(b)q(ecause)i(the)f(problem)f(is)h(not)h(the)f(DNS,)g(but)
+149 1915 y(inadequate)d(metho)q(ds)g(of)h(host)g(authen)o(tication.)223
+2005 y(IP)22 b(addresses)i(of)f(trusted)g(mac)o(hines)e(could)h(still)g(b)q
+(e)h(imitated.)39 b(This)23 b(is)g(a)g(somewhat)149 2095 y(harder)15
+b(task,)g(but)g(the)f(kno)o(w-ho)o(w)h(has)g(b)q(een)g(published)f(for)h
+(quite)e(some)h(time)e(\(see)i([Mor85]\).)223 2185 y(W)l(ould)h(it)f(b)q(e)h
+(safer)g(to)g(transmit)f(up)q(dates)h(to)g(a)h(cen)o(tral)d(site?)21
+b(Email,)13 b(telephone)h(calls,)g(or)149 2276 y(con)o(v)o(en)o(tional)d(pap)
+q(er)i(are)f(not)g(necessarily)f(a)i(reliable)d(w)o(a)o(y)i(to)g(transmit)f
+(mapping)h(information)149 2366 y(up)q(dates.)28 b(The)18 b(long)g(time)e
+(dela)o(y)h(un)o(til)g(cen)o(trally)g(made)g(c)o(hanges)h(are)g(propagated)h
+(through)149 2456 y(the)g(net)o(w)o(ork)f(w)o(ould)h(condemn)e(the)i
+(database)g(to)h(b)q(e)e(in)h(an)g(inheren)o(tly)e(inconsisten)o(t)h(state.)
+149 2547 y(The)c(system)f(w)o(ould)h(again)h(con)o(tain)f(all)f(the)h(disadv)
+m(an)o(tages)h(describ)q(ed)f(in)f(Section)h(2.2,)g(whic)o(h)149
+2637 y(w)o(ere)i(the)g(reasons)h(for)g(dev)o(eloping)e(the)h(curren)o(t)f
+(Domain)h(Name)e(System.)p eop
+%%Page: 68 77
+76 bop 1901 -100 a Fo(68)223 75 y(But)11 b(b)q(esides)i(these)f(ob)o(vious,)g
+(tec)o(hnical,)f(and)i(w)o(ell{kno)o(wn)f(reasons,)h(there)f(is)g(a)h
+(signi\014can)o(t)149 165 y(argumen)o(t)g(wh)o(y)g(no)i(one)e(can)h(p)q
+(ossibly)g(b)q(e)g(in)f(fa)o(v)o(or)h(of)g(reinstalling)e(the)i(previous)f
+(system:)19 b(the)149 255 y(sheer)g(size)f(of)i(the)f(In)o(ternet.)28
+b(HOSTS.TXT)19 b(w)o(as)g(abandoned)i(b)q(ecause)e(200,000)i(hosts)f(w)o(as)
+149 346 y(to)q(o)k(m)o(uc)o(h)c(to)i(b)q(e)h(managed.)38 b(Are)22
+b(curren)o(tly)e(ab)q(out)k(1.5)e(million)e(\(see)i([Lot93)q(]\))f(easier)h
+(to)149 436 y(handle?)g(Certainly)15 b(not.)223 526 y(Ov)o(erall,)i
+(abandoning)k(the)d(Domain)g(Name)f(System)h(w)o(ould)h(drag)g(the)g(name)f
+(resolution)149 616 y(task)h(in)e(the)h(In)o(ternet)e(out)j(of)f(a)g
+(functioning)g(state)g(with)g(a)g(not)g(easily)f(exploitable)g(securit)o(y)
+149 707 y(breac)o(h,)j(in)o(to)f(an)h(unmanageable,)g(not)g(w)o(orking)g
+(state)f(of)h(prehistoric)f(system)f(design.)32 b(W)l(e)149
+797 y(think)16 b(that)h(w)o(ould)f(do)h(more)e(harm)g(than)i(doing)g(nothing)
+g(at)f(all.)149 962 y(4.10)50 b(Hardening)16 b(Name)f(Serv)o(ers)223
+1102 y(This)h(section)h(con)o(tains)f(a)i(n)o(um)o(b)q(er)c(of)j(problems)f
+(that)h(w)o(e)f(classify)g(in)o(to)g(t)o(w)o(o)h(groups)h(and)149
+1192 y(a)f(collection)e(of)i(p)q(ossible)g(mo)q(di\014cations)f(to)h(the)f
+(name)f(serv)o(er)h(to)h(pro)o(vide)e(\(at)i(least)g(partial\))149
+1283 y(solutions)g(to)g(these)f(problems.)223 1373 y(W)l(e)i(though)o(t)i(ab)
+q(out)g(organizing)g(this)f(section)f(in)h(a)g(w)o(a)o(y)g(that)h(solutions)f
+(are)g(stated)h(di-)149 1463 y(rectly)g(in)h(eac)o(h)g(section)g(describing)f
+(a)i(problem.)35 b(But)20 b(then)i(w)o(e)e(disco)o(v)o(ered)g(that)i(most)e
+(of)149 1553 y(the)g(prop)q(osed)i(solutions)f(in)f(hardening)g(the)h(name)e
+(serv)o(er)g(are)h(applicable)g(to)g(a)h(v)m(ariet)o(y)e(of)149
+1644 y(problems.)27 b(In)18 b(the)g(same)f(time,)f(it)i(is)g(necessary)g(to)h
+(not)g(only)f(concen)o(trate)f(on)i(ho)o(w)g(to)g(deal)149
+1734 y(with)i(certain)f(problems,)h(but)g(with)f(all)h(of)g(them)e(sim)o
+(ultaneously)l(.)33 b(W)l(e)20 b(therefore)h(decided)149 1824
+y(that)c(a)f(more)e(general)i(approac)o(h)g(is)f(to)i(state)e(a)i(list)e(of)h
+(problems)e(next)h(to)h(a)g(list)f(of)h(solutions.)149 1915
+y(This)h(w)o(a)o(y)f(w)o(e)g(can)g(relate)f(problems)g(to)i(solutions)g(and)g
+(vice)d(v)o(ersa.)223 2005 y(The)19 b(follo)o(wing)f(t)o(w)o(o)h(sections)g
+(are)g(descriptions)f(of)i(the)e(problems,)g(group)q(ed)i(dep)q(ending)149
+2095 y(on)d(whether)f(a)h(giv)o(en)e(problem)g(exploits)g(cac)o(he)h(p)q
+(oisoning,)h(or)f(not.)149 2255 y(4.10.1)50 b(Problems)15 b(Not)h(Exploiting)
+g(Cac)o(he)g(P)o(oisoning)223 2378 y(In)j(Section)f(3.4.2)i(w)o(e)f(sa)o(w)h
+(a)f(\014rst)h(example)d(of)i(ho)o(w)h(to)g(exploit)e(the)h(w)o(eaknesses)g
+(of)h(the)149 2468 y(DNS.)e(Simple)e(c)o(hanges)j(in)e(the)h(database)i(en)o
+(tries)d(of)i(a)f(mac)o(hine)e(that)j(is)f(trusted,)g(can)h(lead)149
+2558 y(to)h(a)g(break{in.)29 b(As)19 b(w)o(e)g(sho)o(w)o(ed)g(in)g(this)g
+(thesis,)g(it)g(is)g(not)h(di\016cult)e(to)h(coun)o(ter)g(the)g(attac)o(k)149
+2648 y(based)e(on)g(database)g(mo)q(di\014cation.)p eop
+%%Page: 69 78
+77 bop 1901 -100 a Fo(69)223 75 y(There)18 b(are)h(t)o(w)o(o)f(more)g
+(problems,)f(that)i(are)g(related)f(in)g(their)g(nature.)29
+b(In)18 b(the)h(\014rst)g(one,)149 165 y(an)c(attac)o(k)o(er)f(in)o(tercepts)
+f(a)h(query)g(to)h(another)g(name)e(serv)o(er)g(and)i(pro)o(vides)f(the)g
+(reply)f(himself.)149 255 y(If)23 b(the)g(reply)f(con)o(tains)h(a)h(referral)
+e(to)h(some)f(host)i(that)g(is)e(under)h(the)g(attac)o(k)o(er's)f(con)o
+(trol,)149 346 y(the)f(originator)h(of)g(the)f(query)f(will)h(\014nally)f
+(ask)i(that)g(name)e(serv)o(er)g(and)i(b)q(eliev)o(e)d(whatev)o(er)149
+436 y(is)h(returned.)30 b(If)19 b(the)g(time)f(to)i(liv)o(e)d(v)m(alues)j
+(for)f(records)h(supplied)f(in)g(that)h(answ)o(er)g(are)f(zero,)149
+526 y(the)i(originator)g(will)f(not)h(cac)o(he)f(the)h(information,)f(but)h
+(use)g(it)f(for)h(the)g(curren)o(t)f(resolution)149 616 y(pro)q(cess.)30
+b(The)19 b(name)e(serv)o(er)h(that)h(w)o(as)h(originally)e(addressed,)h(or)h
+(its)e(net)o(w)o(ork)g(connection,)149 707 y(can)g(b)q(e)f(manipulated)f(b)o
+(y)h(the)g(attac)o(k)o(er)f(in)h(a)g(w)o(a)o(y)g(that)h(they)e(either)h(not)g
+(receiv)o(e)e(an)o(y)i(query)149 797 y(at)g(all,)e(or)i(that)g(their)e(resp)q
+(onse)i(gets)g(lost)f(\(see)g([Mor85])g(for)h(an)f(example\).)223
+887 y(A)k(similar)e(attac)o(k)j(is)f(based)h(on)g(the)g(fact)f(that)h(the)g
+(standard)h(for)f(the)f(DNS)h(implici)o(tly)149 978 y(determines)14
+b(that)i(the)f(\014rst)h(answ)o(er)f(a)h(resolv)o(er)f(receiv)o(es)e(to)j(a)g
+(query)f(is)g(returned)g(to)h(the)f(user)149 1068 y(program.)21
+b(The)15 b(standard)h(states)g(in)e([Mo)q(c87a)q(])h(:)20 b(\\Get)c(the)e
+(answ)o(er)h(as)h(quic)o(kly)d(as)i(p)q(ossible".)149 1158
+y(If)21 b(a)g(query)g(is)f(answ)o(ered)i(b)o(y)e(more)g(than)h(one)h(host)f
+(\(and)h(one)f(of)g(the)g(hosts)h(supplying)f(an)149 1248 y(answ)o(er)j(can)f
+(b)q(e)g(the)g(attac)o(k)o(er)f(who)i(has)g(in)o(tercepted)d(the)i(query)l(,)
+h(lik)o(e)d(in)i(the)f(previously)149 1339 y(describ)q(ed)c(problem\))e(the)h
+(fastest)h(answ)o(er)g(wins.)25 b(This)18 b(answ)o(er)g(can)g(again)g(refer)f
+(to)h(another)149 1429 y(name)e(serv)o(er)f(under)h(the)g(con)o(trol)g(of)g
+(the)g(attac)o(k)o(er.)149 1589 y(4.10.2)50 b(Problems)15 b(Exploiting)h(Cac)
+o(he)g(P)o(oisoning)223 1711 y(In)j(the)g(Sections)h(3.4.3)g(and)g(3.4.4)g(w)
+o(e)f(describ)q(ed)g(t)o(w)o(o)h(problems)e(that)i(exploit)f(the)h(fact)149
+1802 y(that)d(the)f(cac)o(he)f(of)i(a)f(name)f(serv)o(er)g(can)h(b)q(e)h(p)q
+(oisoned.)22 b(W)l(e)16 b(describ)q(e)f(t)o(w)o(o)h(more)f(problems)g(in)149
+1892 y(this)i(section.)223 1982 y(Imagine)10 b(again)j(the)f(scenario)h(w)o
+(e)f(describ)q(ed)f(in)h(the)g(previous)h(section,)f(where)g(the)g(origina-)
+149 2073 y(tor)j(of)f(a)g(query)f(receiv)o(es)f(more)g(than)i(one)g(resp)q
+(onse)h(and)f(one)g(of)g(the)g(resp)q(onses)h(con)o(tains)f(false)149
+2163 y(information)19 b(supplied)g(b)o(y)h(an)g(attac)o(k)o(er.)31
+b(The)20 b(standard)h(states)f(in)g([Mo)q(c87b,)g(7.4])g(\\When)149
+2253 y(sev)o(eral)c(RRs)h(of)g(the)f(same)g(t)o(yp)q(e)g(are)h(a)o(v)m
+(ailable)f(for)h(a)g(particular)f(o)o(wner)h(name,)e(the)i(resolv)o(er)149
+2343 y(should)h(either)e(cac)o(he)g(them)f(all)h(or)h(none)h(at)f(all.")23
+b(The)17 b(fact)g(that)g(the)f(resp)q(onses)i(come)e(from)149
+2434 y(di\013eren)o(t)i(IP)f(addresses,)i(do)q(es)g(not)f(matter)f(to)h(the)g
+(originator.)27 b(In)17 b([Mo)q(c87b)q(])g(the)h(standard)149
+2524 y(deals)e(with)f(the)h(fact)f(that)h(name)f(serv)o(ers)f(are)i
+(sometimes)d(m)o(ulti{home)o(d)g(hosts)j(and)h(resp)q(ond)149
+2614 y(to)k(queries)e(using)i(another)f(net)o(w)o(ork)g(in)o(terface)e(than)j
+(where)f(the)g(query)f(arriv)o(ed.)32 b(W)l(e)20 b(cite:)p
+eop
+%%Page: 70 79
+78 bop 1901 -100 a Fo(70)149 75 y(\\That)23 b(is,)f(a)g(resolv)o(er)f(cannot)
+h(rely)f(that)h(a)g(resp)q(onse)g(will)e(come)g(from)h(the)g(same)g(address)
+149 165 y(whic)o(h)16 b(it)g(sen)o(t)g(the)g(corresp)q(onding)h(query)e
+(to."\([Mo)q(c87b)q(]\))223 255 y(Under)h(certain)g(additional)g(assumptions)
+h(it)f(is)h(p)q(ossible)g(to)g(p)q(oison)h(some)d(name)h(serv)o(er's)149
+346 y(cac)o(he)24 b(b)o(y)f(simply)f(sending)i(it)f(a)i(query)e(that)h(con)o
+(tains)g(the)g(corrupt)g(information)f(in)h(the)149 436 y(additional)17
+b(section.)k(This)16 b(should)h(w)o(ork)f(in)g(the)g(follo)o(wing)g(setup:)
+222 568 y Fj(\017)24 b Fo(an)16 b(A)o(ttac)o(k)o(er)d(on)j(host)g(NS)772
+575 y Fm(B)814 568 y Fo(sends)g(a)g(query)e(along)i(with)g(the)f(false)g
+(additional)g(RR)g(to)h(a)271 658 y(name)f(serv)o(er)h(B)f(it)h(w)o(an)o(ts)h
+(to)f(compromise,)d(requesting)j(recursiv)o(e)f(resolution)222
+790 y Fj(\017)24 b Fo(the)14 b(name)g(serv)o(er)f(on)i(host)g(NS)854
+797 y Fm(A)897 790 y Fo(do)q(es)g(not)g(cac)o(he)f(incoming)e(information)i
+(according)g(to)271 880 y(the)i(RF)o(C,)g(but)g(it)g(shares)h(its)f(cac)o(he)
+f(with)h(the)g(lo)q(cal)h(resolv)o(er)e(on)h(the)g(same)g(mac)o(hine)222
+1012 y Fj(\017)24 b Fo(if)12 b(the)g(name)f(serv)o(er)g(on)i(host)g(NS)885
+1019 y Fm(A)925 1012 y Fo(in)o(v)o(ok)o(es)e(its)h(lo)q(cal)g(resolv)o(er)f
+(that)i(will)e(\014nally)h(get)g(bac)o(k)271 1102 y(an)k(answ)o(er)g(from)e
+(somewhere,)g(this)h(resolv)o(er)f(on)i(host)g(NS)1381 1109
+y Fm(A)1425 1102 y Fo(will)e(cac)o(he)h(whatev)o(er)g(data)271
+1192 y(is)g(pro)o(vided)f(according)h(to)g(the)f(rules)g({)i(including)d(the)
+i(additional)g(record)f(pro)o(vided)g(b)o(y)271 1283 y(the)i(attac)o(k)o(er.)
+223 1414 y(The)g(name)f(serv)o(er)g(on)i(host)g(NS)831 1421
+y Fm(A)876 1414 y Fo(inherits)f(the)g(w)o(eakness)g(of)g(its)g(o)o(wn)h
+(resolv)o(er.)149 1574 y(4.10.3)50 b(Keeping)16 b(Additional)f(Information)
+223 1697 y(A)f(\014rst)i(idea)f(is)g(to)g(log)h(\\rlogin")f(attempts)g(with)g
+(IP)g(address)g(and)h(lo)q(cal)f(and)h(remote)d(user)149 1787
+y(names.)28 b(Or)19 b(ev)o(en)e(more:)25 b(to)19 b(tag)g(cac)o(he)f(en)o
+(tries)g(with)g(their)g(origin.)29 b(The)18 b(latter)g(is)h(another)149
+1878 y(easily)f(ac)o(hiev)o(ed)f(mo)q(di\014cation)g(that)i(costs)g
+(additional)f(memory)e(space)i(in)g(the)h(cac)o(he.)26 b(This)149
+1968 y(metho)q(d)18 b(mak)o(es)f(it)h(easier)f(to)i(trac)o(k,)f(for)g
+(example,)f(a)h(false)g(\\A")h(record)f(for)h(the)f(purp)q(ose)h(of)149
+2058 y(debugging)e(wrong)h(zone)e(data)h(or)g(in)o(v)o(estigating)e(a)h(DNS)h
+(based)f(break{in.)149 2218 y(4.10.4)50 b(Prev)o(en)o(tion)15
+b(of)h(Cac)o(he)g(P)o(oisoning)223 2341 y(Prev)o(en)o(ting)d(the)h(cac)o(he)g
+(from)g(con)o(tamination)f(is)h(probably)h(not)g(feasible)f(from)g(within)g
+(the)149 2431 y(name)j(serv)o(er)g(co)q(de,)h(as)g(there)g(is)f(no)i(w)o(a)o
+(y)e(of)h(a)g(priori)g(determining)d(if)j(an)o(y)f(giv)o(en)g(additional)149
+2521 y(record)h(is)f(trust)o(w)o(orth)o(y)h(or)f(not.)26 b(W)l(e)18
+b(could)f(start)h(treating)g(sp)q(ecial)f(cases)h(of)g(when)g(to)g(allo)o(w)
+149 2611 y(or)f(disallo)o(w)f(additional)g(information.)p eop
+%%Page: 71 80
+79 bop 1901 -100 a Fo(71)223 75 y(The)17 b(default)g(safe)g(b)q(eha)o(vior)g
+(w)o(ould)g(b)q(e)g(to)h(disallo)o(w)f(the)g(cac)o(hing)f(of)i(unrequested)e
+(infor-)149 165 y(mation,)k(and)g(to)g(allo)o(w)g(it)f(only)h(in)g(cases)g
+(where)f(the)h(information)f(is)g(necessary)l(,)h(and)h(then)149
+255 y(only)16 b(for)h(the)f(curren)o(t)f(resolution.)149 415
+y(4.10.5)50 b(Con)o(text)16 b(Cac)o(he)223 538 y(But)i(there)g(are)h(other,)h
+(more)d(sophisticated)i(approac)o(hes)g(p)q(ossible:)27 b(If)19
+b(some)e(additional)149 628 y(or)f(authoritativ)o(e)f(records)g(are)h
+(returned)e(together)i(with)f(a)h(resource)f(record,)g(they)g(should)g(b)q(e)
+149 718 y(in)o(terpreted)j(only)g(in)g(the)h(con)o(text)f(of)h(that)g
+(resource)f(record.)29 b(The)18 b(di\013erence)g(b)q(et)o(w)o(een)g(the)149
+809 y(default)13 b(safe)f(b)q(eha)o(vior)g(approac)o(h)i(and)f(this)f(one)g
+(is)h(that)f(in)g(the)h(\014rst)f(one)h(resource)f(records)g(are)149
+899 y(only)17 b(cac)o(hed,)e(when)h(they)g(w)o(ere)g(requested)f(or)i
+(necessary)f(additional)g(information,)f(whereas)149 989 y(in)21
+b(the)g(second)g(approac)o(h)g(the)g(new)g(en)o(tries)f(get)h(cac)o(hed,)g
+(but)g(can)g(b)q(e)g(retriev)o(ed)e(from)h(the)149 1079 y(cac)o(he)g(only)h
+(in)f(the)g(same)g(con)o(text)f(in)i(whic)o(h)e(they)i(w)o(ere)e(en)o(tered.)
+33 b(F)l(or)21 b(example,)e(an)i(\\A")149 1170 y(record)15
+b(in)g(the)g(additional)h(section)f(of)g(a)h(resp)q(onse)g(to)f(an)h(\\MX")f
+(record)g(request)g(should)h(only)149 1260 y(b)q(e)g(used)f(for)h(deliv)o
+(ering)d(mail.)19 b(The)c(information)f(w)o(ould)h(not)h(b)q(e)f(acceptable)g
+(for)g(an)h(\\rlogin")149 1350 y(to)h(another)g(host,)f(or)h(generally)e
+(usable)i(for)f(other)g(services.)223 1441 y(A)21 b(glue)h(\\A")g(record)g
+(coming)f(along)i(with)e(an)i(\\NS")f(record)g(w)o(ould)g(only)g(b)q(e)g
+(used)g(for)149 1531 y(domain)16 b(hopping,)g(b)q(ecause)h(that)g(is)f(the)g
+(con)o(text)f(in)h(whic)o(h)f(it)h(w)o(as)h(supplied.)223 1621
+y(\\A")h(records)f(along)i(with)e(\\PTR")i(records)f(should)g(nev)o(er)e(b)q
+(e)i(cac)o(hed,)f(b)q(ecause)h(there)f(is)149 1711 y(no)g(legal)f(con)o(text)
+f(in)h(whic)o(h)g(they)g(ha)o(v)o(e)f(to)i(b)q(e)f(returned)g(in)g(a)g
+(single)g(resp)q(onse.)223 1802 y(This)23 b(whole)g(approac)o(h)h(leads)g(to)
+f(the)g(question)g(of)h(whether)f(w)o(e)g(still)f(need)h(the)g(addi-)149
+1892 y(tional)18 b(section)g(at)g(all.)26 b(If)17 b(only)h(certain)f(com)o
+(binations)g(of)h(resource)g(records)g(are)g(allo)o(w)o(ed)f(as)149
+1982 y(a)j(resp)q(onse)h(to)e(a)h(query)l(,)f(wh)o(y)h(not)g(consequen)o(tly)
+e(eliminate)e(the)k(idea)f(of)h(additional)f(unre-)149 2073
+y(quested)j(information)f(completely)l(,)f(and)j(adapt)g(the)f(proto)q(col)h
+(to)f(accommo)q(date)f(the)g(new)149 2163 y(ideas,)16 b(namely)f(a)h(certain)
+g(limited)d(n)o(um)o(b)q(er)i(of)h(t)o(yp)q(es)g(of)h(asso)q(ciations?)223
+2253 y(First)h(of)h(all,)f(that)h(w)o(ould)g(require)f(a)h(proto)q(col)g(c)o
+(hange,)g(whic)o(h)f(is)h(something)e(w)o(e)i(try)f(to)149
+2343 y(a)o(v)o(oid.)j(Some)13 b(of)i(the)f(original)h(design)g(goals)g(of)g
+(the)g(Domain)f(Name)f(System)g(also)i(imply)d(that)149 2434
+y(eliminating)i(the)h(additional)h(section)g(w)o(ould)g(not)g(b)q(e)g(a)g(go)
+q(o)q(d)i(approac)o(h.)k(The)16 b(system)e(w)o(ould)149 2524
+y(lose)k(some)f(of)i(its)f(generalit)o(y)l(,)e(b)q(ecause)i(the)g(additional)
+g(section)g(migh)o(t)e(b)q(ecome)h(v)o(ery)g(useful)149 2614
+y(in)h(future)g(applications)g(of)g(the)f(Domain)h(Name)e(System)g(without)i
+(con)o(taining)g(an)o(y)g(securit)o(y)p eop
+%%Page: 72 81
+80 bop 1901 -100 a Fo(72)149 75 y(threats.)24 b(The)17 b(system)f(w)o(ould)h
+(certainly)e(lose)i(e\016ciency)l(.)k(Here)16 b(w)o(e)h(see)f(again)i(an)f
+(imp)q(ortan)o(t)149 165 y(trade-o\013)k(that)f(w)o(e)g(ha)o(v)o(e)e(already)
+i(men)o(tioned)d(in)j(sev)o(eral)e(earlier)h(sections:)28 b(an)20
+b(increase)f(in)149 255 y(systems)e(securit)o(y)f(and)i(a)g(decline)e(in)h
+(system)f(p)q(erformance)h(vs.)25 b(go)q(o)q(d)19 b(system)e(p)q(erformance)
+149 346 y(and)g(a)g(p)q(ossible)f(lac)o(k)g(of)g(securit)o(y)l(.)223
+436 y(It)j(is)h(therefore)f(justi\014able)g(to)i(tak)o(e)e(the)h(approac)o(h)
+g(of)h(hardening)f(the)f(name)g(serv)o(er)g(b)o(y)149 526 y(treating)j(more)e
+(sp)q(ecial)h(cases,)h(and)g(b)o(y)f(increasing)g(the)g(complexit)o(y)d(of)j
+(the)g(in)o(ternal)g(data)149 616 y(bases,)j(instead)e(of)h(hardening)f(it)g
+(b)o(y)f(impleme)o(n)o(ti)o(ng)f(the)i(same)f(ideas)h(accepting)g(proto)q
+(col)149 707 y(c)o(hanges.)149 867 y(4.10.6)50 b(Authorit)o(y)15
+b(Cac)o(he)223 989 y(A)f(further)g(approac)o(h)h(w)o(ould)g(b)q(e)f(to)h(cac)
+o(he)f(data)h(only)f(if)g(the)g(source)h(of)g(a)g(record)f(is)g(kno)o(wn)149
+1079 y(to)h(b)q(e)g(authoritativ)o(e)f(for)h(that)g(zone.)21
+b(W)l(e)14 b(giv)o(e)g(an)h(example)d(for)j(that:)21 b(If)14
+b(a)h(name)f(serv)o(er)f(NS)1921 1086 y Fm(A)149 1170 y Fo(receiv)o(es)18
+b(a)h(\\PTR")i(record)e(from)f(some)h(host)h(NS)1117 1177 y
+Fm(B)1144 1170 y Fo(,)f(and)h(the)f(DNS)h(message)e(also)i(con)o(tains)149
+1260 y(an)k(\\A")f(record)g(in)f(its)h(additional)g(section,)h(then)e(the)h
+(name)f(serv)o(er)g(NS)1604 1267 y Fm(A)1656 1260 y Fo(w)o(ould)g(b)q(eliev)o
+(e)149 1350 y(and)17 b(cac)o(he)e(this)h(information)e(only)i(if)f(it)h
+(already)f(kno)o(ws)i(that)f(the)f(source)h(name)f(serv)o(er)g(NS)1922
+1357 y Fm(B)149 1441 y Fo(is)i(authoritativ)o(e)g(for)g(the)g(according)g
+(zone.)23 b(A)17 b(name)f(serv)o(er)g(follo)o(wing)g(this)h(strategy)g(w)o
+(ould)149 1531 y(create)11 b(its)h(o)o(wn)g(tree)f(of)h(authoritativ)o(e)f
+(name)g(serv)o(ers.)18 b(This)12 b(tree)f(w)o(ould)h(ha)o(v)o(e)f(to)h(lose)f
+(subtrees)149 1621 y(according)17 b(to)g(the)f(expiration)f(of)i(the)f
+(lifetime)d(of)j(some)f(no)q(de)i(\(name)e(serv)o(er\).)149
+1781 y(4.10.7)50 b(Conditional)16 b(Cac)o(he)g(Use)223 1904
+y(The)f(Berk)o(eley)d(patc)o(h)k(\(see)e(Section)h(4.5\))h(can)f(fail)g(in)g
+(the)g(case)g(that)h(the)f(cac)o(he)g(is)g(already)149 1994
+y(p)q(oisoned.)30 b(An)18 b(idea)h(to)g(strengthen)g(the)f(Berk)o(eley)e
+(patc)o(h)j(is)f(to)h(pro)o(vide)f(the)g(p)q(ossibilit)o(y)g(to)149
+2084 y(resolv)o(e)f(queries)g(without)g(using)h(the)g(cac)o(he.)24
+b(That)19 b(could)e(b)q(e)h(used)g(b)o(y)f(the)g(Berk)o(eley)e(patc)o(h.)149
+2174 y(The)f(system)e(call)h(executing)g(the)g(forw)o(ard)h(lo)q(okup)g(w)o
+(ould)g(for)g(example)d(set)j(a)g(\015ag)g(to)g(indicate)149
+2265 y(that)i(the)f(cac)o(he)f(con)o(ten)o(ts)h(should)g(not)h(b)q(e)f(used)g
+(for)h(the)e(follo)o(wing)h(resolution.)21 b(This)15 b(metho)q(d)149
+2355 y(again)e(hits)e(the)g(e\016ciency)f(of)h(the)h(system,)e(but)i(it)f
+(prev)o(en)o(ts)f(the)h(exploitation)g(of)h(the)f(w)o(eakness.)149
+2445 y(One)18 b(could)h(also)f(think)g(of)h(a)g(system)d(call)i(to)g(\015ush)
+h(the)f(cac)o(he)g(follo)o(w)o(ed)f(b)o(y)h(a)h(reload)f(of)h(the)149
+2536 y(database,)e(similar)d(to)i(the)f(signal)h(SIGHUP)f(that)h(a)g(system)e
+(administrator)h(can)h(send)g(to)g(the)149 2626 y(BIND)g(implem)o(e)o(n)o
+(tation)e(of)i(the)g(name)f(serv)o(er)h(to)g(ac)o(hiev)o(e)f(the)h(same.)p
+eop
+%%Page: 73 82
+81 bop 1901 -100 a Fo(73)149 75 y(4.10.8)50 b(Discussion)223
+197 y(A)12 b(v)o(ery)h(thorough)h(analysis)g(of)f(the)g(proto)q(col)i(is)e
+(needed)f(to)i(determine)d(the)i(cases)g(in)g(whic)o(h)149
+287 y(additional)19 b(resource)f(records)h(are)f(legal)g(and)i(cannot)f(do)g
+(an)o(y)f(harm,)g(or)h(ha)o(v)o(e)f(to)g(b)q(e)h(stored)149
+378 y(in)d(di\013eren)o(t)g(con)o(texts.)223 468 y(Hardening)h(the)h(system)e
+(w)o(ould)i(require)f(careful)g(design,)h(implem)o(en)o(tation,)d(and)k
+(testing)149 558 y(and)k(w)o(ould)e(lead)g(to)h(a)g(higher)f(complexit)o(y)d
+(of)k(the)f(co)q(de)h(and)g(the)f(system.)36 b(Our)21 b(analysis)149
+649 y(has)e(to)f(stress)g(the)g(higher)f(complexit)o(y)l(,)e(b)q(ecause)j
+(design,)g(implem)o(e)o(n)o(tation)d(and)k(testing)e(are)149
+739 y(a)e(pro)q(cess)g(that)g(will)e(b)q(e)i(done)g(at)g(some)e(p)q(oin)o(t,)
+h(but)h(the)f(complexit)o(y)d(of)k(a)g(system)e(is)h(a)h(feature)149
+829 y(that)k(sta)o(ys)g(with)f(it.)26 b(Higher)18 b(complexit)o(y)d(usually)j
+(go)q(es)h(along)g(with)f(greater)h(insecurit)o(y)l(.)25 b(It)149
+919 y(is)16 b(therefore)g(imp)q(ortan)o(t)f(to)i(k)o(eep)e(the)h(complexit)o
+(y)d(in)j(a)h(manageable)e(scop)q(e.)223 1010 y(A)20 b(decline)g(in)h(system)
+f(p)q(erformance)g(w)o(ould)h(result)g(from)f(the)h(fact)g(that)h(name)e
+(serv)o(ers)149 1100 y(w)o(ould)d(b)q(eliev)o(e)d(and)j(therefore)e(cac)o(he)
+h(less)g(data)h(|)f(data)h(that)g(migh)o(t)d(b)q(e)j(needed)e(later.)223
+1190 y(Ov)o(erall,)i(hardening)j(name)e(serv)o(ers)g(consists)h(of)h(sev)o
+(eral)e(p)q(ossible)h(mo)q(di\014cations,)f(some)149 1281 y(of)h(whic)o(h)f
+(seem)f(promising,)h(ev)o(en)f(though)j(their)d(application)i(decreases)f
+(the)g(system's)f(p)q(er-)149 1371 y(formance)e(and)i(increases)f(its)g
+(complexit)o(y)l(,)c(whic)o(h)k(migh)o(t)f(lead)h(to)g(further)g(insecurit)o
+(y)l(.)149 1536 y(4.11)50 b(Cryptographic)17 b(Metho)q(ds)g(for)f(Strong)h
+(Authen)o(tication)223 1676 y(In)j(this)h(section)g(w)o(e)g(describ)q(e)f(an)
+i(arc)o(hitecture)d(for)j(an)f(authen)o(ticated)g(Domain)f(Name)149
+1766 y(System.)g(The)c(outline)f(for)i(the)f(approac)o(h)g(describ)q(ed)g(b)q
+(elo)o(w)g(is)g(only)g(one)g(of)g(sev)o(eral)f(p)q(ossible)149
+1856 y(scenarios.)26 b(There)17 b(are)g(systems)g(that)g(pro)o(vide)g(access)
+g(authen)o(tication)h(in)f(distributed)f(en)o(vi-)149 1947
+y(ronmen)o(ts.)23 b(Some)16 b(examples)f(of)j(systems)e(that)i(use)f(tic)o(k)
+o(ets)e(or)j(securit)o(y)d(certi\014cates)h(are)i(the)149 2037
+y(Kerb)q(eros)e(authen)o(tication)f(service)g(\([SNS88]\))g(and)h(pro)s(ject)
+f(SESAME)g(\([P)o(ar91)q(]\).)20 b(They)15 b(are)149 2127 y(not)i(directly)e
+(applicable)g(to)i(our)f(problem.)223 2218 y(Our)e(approac)o(h)i(con)o(tains)
+f(three)f(ma)s(jor)g(features)h(that)g(are)g(necessary)g(to)g(ensure)f(the)h
+(kind)149 2308 y(of)i(securit)o(y)e(w)o(e)h(are)g(trying)g(to)g(obtain:)209
+2452 y(1.)24 b(data)17 b(in)o(tegrit)o(y)e(of)h(a)h(message)209
+2584 y(2.)24 b(originator)17 b(authen)o(tication)p eop
+%%Page: 74 83
+82 bop 1901 -100 a Fo(74)209 75 y(3.)24 b(originator's)h(pro)q(of)f(of)g(b)q
+(eing)g(an)h(authoritativ)o(e)e(source)h(b)o(y)f(presen)o(ting)g(creden)o
+(tials)271 165 y(signed)17 b(b)o(y)e(the)h(paren)o(t)h(domain)223
+309 y(In)g(the)g(follo)o(wing)f(w)o(e)h(will)f(elab)q(orate)i(on)g(these)f
+(three)f(features)i(and)f(presen)o(t)g(tec)o(hniques)149 400
+y(and)g(ideas)f(for)h(their)f(p)q(ossible)g(implem)o(en)o(tati)o(on.)149
+560 y(4.11.1)50 b(Data)17 b(In)o(tegrit)o(y)262 1071 y @beginspecial
+0 @llx 0 @lly 369 @urx 54 @ury 3690 @rwi @setspecial
+%%BeginDocument: pictures/mesg_digest.ps
+/$F2psDict 200 dict def 
+$F2psDict begin
+$F2psDict /mtrx matrix put
+/l {lineto} bind def
+/m {moveto} bind def
+/s {stroke} bind def
+/n {newpath} bind def
+/gs {gsave} bind def
+/gr {grestore} bind def
+/clp {closepath} bind def
+/graycol {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
+4 -2 roll mul setrgbcolor} bind def
+/col-1 {} def
+/col0 {0 0 0 setrgbcolor} bind def
+/col1 {0 0 1 setrgbcolor} bind def
+/col2 {0 1 0 setrgbcolor} bind def
+/col3 {0 1 1 setrgbcolor} bind def
+/col4 {1 0 0 setrgbcolor} bind def
+/col5 {1 0 1 setrgbcolor} bind def
+/col6 {1 1 0 setrgbcolor} bind def
+/col7 {1 1 1 setrgbcolor} bind def
+	end
+/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
+/$F2psEnd {$F2psEnteredState restore end} def
+
+$F2psBegin
+0 setlinecap 0 setlinejoin
+-4.0 63.0 translate 0.900 -0.900 scale
+1.000 setlinewidth
+n 16 29 m 9 29 9 42 7 arcto 4 {pop} repeat 9 49 87 49 7 arcto 4 {pop} repeat 94 49 94 36 7 arcto 4 {pop} repeat 94 29 16 29 7 arcto 4 {pop} repeat clp gs col-1 s gr
+n 11 24 m 4 24 4 47 7 arcto 4 {pop} repeat 4 54 92 54 7 arcto 4 {pop} repeat 99 54 99 31 7 arcto 4 {pop} repeat 99 24 11 24 7 arcto 4 {pop} repeat clp gs col-1 s gr
+/Times-Bold findfont 12.00 scalefont setfont
+14 44 m 
+gs 1 -1 scale (DNS message) col-1 show gr
+n 279 69 m 279 9 l  134 9 l  134 69 l  clp gs col-1 s gr
+n 321 29 m 314 29 314 42 7 arcto 4 {pop} repeat 314 49 407 49 7 arcto 4 {pop} repeat 414 49 414 36 7 arcto 4 {pop} repeat 414 29 321 29 7 arcto 4 {pop} repeat clp gs col-1 s gr
+n 99 39 m 134 39 l gs col-1 s gr
+n 118.000 35.000 m 134.000 39.000 l 118.000 43.000 l gs 2 setlinejoin col-1 s gr
+n 279 39 m 314 39 l gs col-1 s gr
+n 298.000 35.000 m 314.000 39.000 l 298.000 43.000 l gs 2 setlinejoin col-1 s gr
+/Times-Bold findfont 12.00 scalefont setfont
+139 44 m 
+gs 1 -1 scale (message digest algorithm) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+159 24 m 
+gs 1 -1 scale (MD2, MD4, MD5) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+189 64 m 
+gs 1 -1 scale (Snefru) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+324 44 m 
+gs 1 -1 scale (message digest) col-1 show gr
+0.500 setlinewidth
+n 139 49 m 274 49 l gs col-1 s gr
+$F2psEnd
+%%EndDocument
+ @endspecial 478 1316 a(Figure)e(4.1)33 b(Application)15 b(of)i(a)g(message)e
+(digest)h(algorithm)223 1531 y(In)o(tegrit)o(y)10 b(service)g(means)h(that)h
+(a)g(recipien)o(t)d(is)j(pro)o(vided)f(with)g(assurance)i(that)f(the)f(con)o
+(ten)o(t)149 1621 y(of)19 b(a)f(receiv)o(ed)e(message)h(is)h(iden)o(tical)e
+(to)j(the)e(con)o(ten)o(t)h(of)g(a)g(message)g(\(including)f(its)h(header\))
+149 1711 y(sen)o(t)e(b)o(y)g(its)g(originator)h(\(see)f([Ken93a]\).)223
+1802 y(In)f(our)h(case,)f(w)o(e)g(w)o(an)o(t)g(to)h(ensure)f(the)h(in)o
+(tegrit)o(y)d(of)j(transmitted)e(DNS)h(messages.)21 b(There)149
+1892 y(are)15 b(sev)o(eral)f(approac)o(hes)h(to)g(protect)f(a)h(message)f
+(against)i(unauthorized)f(c)o(hange:)20 b(prev)o(en)o(tion)149
+1982 y(tec)o(hniques,)e(a)o(v)o(oidance)h(tec)o(hniques,)e(and)j(detection)e
+(and)i(reco)o(v)o(ery)d(tec)o(hniques.)28 b(All)18 b(these)149
+2072 y(tec)o(hniques)h(ha)o(v)o(e)h(inheren)o(t)f(adv)m(an)o(tages)j(and)f
+(disadv)m(an)o(tages.)35 b(W)l(e)20 b(will)g(not)g(discuss)h(them)149
+2163 y(here,)f(but)f(concen)o(trate)g(on)h(a)g(certain)f(tec)o(hnique)f(to)i
+(detect)e(unauthorized)i(message)f(alter-)149 2253 y(ation.)36
+b(W)l(e)21 b(stress)g(this)g(approac)o(h,)h(b)q(ecause)f(it)g(is)f(e\016cien)
+o(t)f(and)j(considerably)e(secure.)35 b(In)149 2343 y(case)14
+b(of)g(alteration)g(detection,)e(reco)o(v)o(ery)g(actions)i(could)g(b)q(e)f
+(to)h(ignore)g(the)f(DNS)h(message)f(and)149 2434 y(issue)20
+b(an)h(additional)f(query)l(.)31 b(Our)20 b(approac)o(h)h(is)f(based)g(up)q
+(on)i(message)d(digest)h(algorithms.)149 2524 y(They)15 b(are)g(one-w)o(a)o
+(y)g(hash)g(functions)g(that)g(compute)e(a)j(c)o(hec)o(ksum)11
+b(of)16 b(some)d(data)j(\(in)e(our)h(case)149 2614 y(the)h(DNS)h(message)e(|)
+h(see)g(Figure)g(4.1\).)21 b(They)16 b(ha)o(v)o(e)g(the)g(follo)o(wing)g
+(features:)p eop
+%%Page: 75 84
+83 bop 1901 -100 a Fo(75)222 75 y Fj(\017)24 b Fo(they)17 b(are)g(easy)h(to)f
+(compute)f(\(examples)g(are)h(the)g(MD2,)g(MD4,)h(and)g(MD5)f(algorithms)271
+165 y(in)f([Kal92,)g(Riv92a)q(,)f(Riv92b])h(and)h(the)f(Snefru)g(algorithm)f
+(in)h([Mer89]\))222 289 y Fj(\017)24 b Fo(the)16 b(signature)h(\(message)e
+(digest)i(or)f(\014ngerprin)o(t\))g(is)g(only)g(a)h(few)f(b)o(ytes)f(p)q(er)i
+(message)222 412 y Fj(\017)24 b Fo(they)16 b(are)g(computationally)f(hard)i
+(to)g(in)o(v)o(ert)222 536 y Fj(\017)24 b Fo(they)16 b(usually)g(require)f(a)
+i(certain)e(size)h(of)g(input)g(data)149 648 y(An)23 b(originator)h(w)o(ould)
+f(calculate)f(the)h(message)f(digest)h(of)g(a)h(DNS)f(message)f(imme)o
+(diately)149 738 y(b)q(efore)15 b(it)f(is)g(sen)o(t)g(out.)21
+b(The)14 b(recipien)o(t)e(w)o(ould)j(recalculate)e(the)h(message)f(digest)i
+(and)g(compare)149 828 y(the)h(resulting)g(v)m(alue)g(with)g(the)g(one)h
+(calculated)e(b)o(y)h(the)g(originator.)22 b(In)16 b(case)g(of)g(a)h(mismatc)
+o(h,)149 919 y(the)e(originator)g(w)o(ould)g(conclude)f(that)h(he)f(did)h
+(not)g(receiv)o(e)d(an)j(unaltered)g(DNS)f(message.)20 b(He)149
+1009 y(w)o(ould)d(disp)q(ose)g(of)f(it.)223 1099 y(Ho)o(w)c(do)q(es)i(the)f
+(message)f(digest)h(calculated)f(b)o(y)h(the)f(originator)i(get)f(to)g(the)g
+(receiv)o(er)e(unim-)149 1190 y(paired?)35 b(The)21 b(message)f(digest)h
+(algorithms)f(are)h(publicly)e(kno)o(wn)i(and)g(an)o(y)o(one)f(tamp)q(ering)
+149 1280 y(with)h(a)g(message)f(could)h(easily)f(mo)q(dify)f(the)h(asso)q
+(ciated)i(message)e(digest)h(accordingly)l(.)34 b(T)l(o)149
+1370 y(sho)o(w)21 b(ho)o(w)f(this)g(can)g(b)q(e)g(prev)o(en)o(ted)e(w)o(e)h
+(discuss)h(a)g(metho)q(d)f(for)h(originator)h(authen)o(tication)149
+1460 y(in)h(the)g(follo)o(wing)g(section.)38 b(A)21 b(message)h(digest)g
+(together)g(with)g(an)g(authorization)h(service)149 1551 y(guaran)o(tee)17
+b(the)f(in)o(tegrit)o(y)e(of)j(transmitted)e(data.)149 1715
+y(4.11.2)50 b(Originator)16 b(Authen)o(tication)223 1837 y(Originator)k
+(authen)o(tication)g(service)g(p)q(ermits)f(the)h(recipien)o(t)e(of)j(a)g
+(message)f(to)h(reliably)149 1928 y(determine)14 b(the)i(iden)o(tit)o(y)e(of)
+j(the)f(originator)h(of)f(a)h(message.)223 2018 y(W)l(e)22
+b(demonstrate)h(a)g(pro)q(cedure)g(that)g(guaran)o(tees)h(the)f(originator's)
+g(authen)o(ticit)o(y)l(.)40 b(In)149 2108 y(an)20 b(asymmetri)o(c)c(\(i.e.)27
+b(public)18 b(k)o(ey\))g(cryptoalgorithm)f(a)i(pair)g(of)g(distinct,)f(but)h
+(mathemati-)149 2198 y(cally)g(related,)h(k)o(eys)e(are)i(used)g(for)g
+(encryption)f(and)h(decryption.)31 b(One)19 b(k)o(ey)g(is)g(priv)m(ate)h(and)
+149 2289 y(k)o(ept)f(secret)f(b)o(y)g(the)h(sender,)g(the)g(other)g(one)g(is)
+f(publicly)g(kno)o(wn.)29 b(Data)20 b(encrypted)e(with)h(a)149
+2379 y(sender's)i(priv)m(ate)f(k)o(ey)g(can)h(b)q(e)g(decrypted)f(using)i
+(his)e(public)g(k)o(ey)l(,)h(and)g(vice)f(v)o(ersa.)35 b(These)149
+2469 y(k)o(eys)15 b(are)g(usually)g(large)g(in)o(teger)f(n)o(um)o(b)q(ers,)g
+(sev)o(eral)g(h)o(undred)h(decimal)e(digits)i(long)h(with)f(sp)q(e-)149
+2560 y(cial,)j(mathematical)d(prop)q(erties.)28 b(\(ex.)f([Den82]\).)g
+(\\RSA")19 b(is)f(an)h(example)d(of)i(a)h(public)f(k)o(ey)149
+2650 y(encryption)e(algorithm)f(\([RSA78]\).)p eop
+%%Page: 76 85
+84 bop 1901 -100 a Fo(76)299 970 y @beginspecial 0 @llx 0 @lly
+350 @urx 206 @ury 3500 @rwi @setspecial
+%%BeginDocument: pictures/dig_sig_val.ps
+/$F2psDict 200 dict def 
+$F2psDict begin
+$F2psDict /mtrx matrix put
+/l {lineto} bind def
+/m {moveto} bind def
+/s {stroke} bind def
+/n {newpath} bind def
+/gs {gsave} bind def
+/gr {grestore} bind def
+/clp {closepath} bind def
+/graycol {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
+4 -2 roll mul setrgbcolor} bind def
+/col-1 {} def
+/col0 {0 0 0 setrgbcolor} bind def
+/col1 {0 0 1 setrgbcolor} bind def
+/col2 {0 1 0 setrgbcolor} bind def
+/col3 {0 1 1 setrgbcolor} bind def
+/col4 {1 0 0 setrgbcolor} bind def
+/col5 {1 0 1 setrgbcolor} bind def
+/col6 {1 1 0 setrgbcolor} bind def
+/col7 {1 1 1 setrgbcolor} bind def
+	end
+/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
+/$F2psEnd {$F2psEnteredState restore end} def
+
+$F2psBegin
+0 setlinecap 0 setlinejoin
+-4.0 211.0 translate 0.900 -0.900 scale
+1.000 setlinewidth
+	1 setlinecap [1 3.000000] 3.000000 setdash
+n 159 229 m 239 229 l gs col-1 s gr
+	[] 0 setdash 0 setlinecap
+n 231.000 227.000 m 239.000 229.000 l 231.000 231.000 l gs 2 setlinejoin col-1 s gr
+	1 setlinecap [1 3.000000] 3.000000 setdash
+n 159 29 m 239 29 l gs col-1 s gr
+	[] 0 setdash 0 setlinecap
+n 231.000 27.000 m 239.000 29.000 l 231.000 31.000 l gs 2 setlinejoin col-1 s gr
+n 319 39 m 319 59 l gs col-1 s gr
+n 321.000 51.000 m 319.000 59.000 l 317.000 51.000 l gs 2 setlinejoin col-1 s gr
+n 319 79 m 319 99 l gs col-1 s gr
+n 321.000 91.000 m 319.000 99.000 l 317.000 91.000 l gs 2 setlinejoin col-1 s gr
+n 319 179 m 319 159 l gs col-1 s gr
+n 317.000 167.000 m 319.000 159.000 l 321.000 167.000 l gs 2 setlinejoin col-1 s gr
+n 319 219 m 319 199 l gs col-1 s gr
+n 317.000 207.000 m 319.000 199.000 l 321.000 207.000 l gs 2 setlinejoin col-1 s gr
+n 79 39 m 79 59 l gs col-1 s gr
+n 81.000 51.000 m 79.000 59.000 l 77.000 51.000 l gs 2 setlinejoin col-1 s gr
+n 79 79 m 79 99 l gs col-1 s gr
+n 81.000 91.000 m 79.000 99.000 l 77.000 91.000 l gs 2 setlinejoin col-1 s gr
+n 79 119 m 79 179 l gs col-1 s gr
+n 81.000 171.000 m 79.000 179.000 l 77.000 171.000 l gs 2 setlinejoin col-1 s gr
+n 79 199 m 79 219 l gs col-1 s gr
+n 81.000 211.000 m 79.000 219.000 l 77.000 211.000 l gs 2 setlinejoin col-1 s gr
+n 279 19 m 359 19 l gs col-1 s gr
+n 39 19 m 119 19 l gs col-1 s gr
+0.500 setlinewidth
+n 274 159 m 284 184 l gs col-1 s gr
+n 282.886 175.829 m 284.000 184.000 l 279.172 177.315 l gs 2 setlinejoin col-1 s gr
+n 108 159 m 98 184 l gs col-1 s gr
+n 102.828 177.315 m 98.000 184.000 l 99.114 175.829 l gs 2 setlinejoin col-1 s gr
+/Times-Bold findfont 12.00 scalefont setfont
+59 14 m 
+gs 1 -1 scale (Sender:) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+19 34 m 
+gs 1 -1 scale (\(data before signature\)) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+39 74 m 
+gs 1 -1 scale (hash algorithm) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+54 114 m 
+gs 1 -1 scale (hash value) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+4 194 m 
+gs 1 -1 scale (asymmetric cryptoalgorithm) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+39 234 m 
+gs 1 -1 scale (digital signature) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+294 14 m 
+gs 1 -1 scale (Receiver:) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+279 34 m 
+gs 1 -1 scale (\(received data\)) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+279 74 m 
+gs 1 -1 scale (hash algorithm) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+294 114 m 
+gs 1 -1 scale (hash value) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+294 154 m 
+gs 1 -1 scale (hash value) col-1 show gr
+/Times-Bold findfont 24.00 scalefont setfont
+309 139 m 
+gs 1 -1 scale (=?) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+244 194 m 
+gs 1 -1 scale (asymmetric cryptoalgorithm) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+254 234 m 
+gs 1 -1 scale (received digital signature) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+119 154 m 
+gs 1 -1 scale (sender's ) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+114 169 m 
+gs 1 -1 scale (private key) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+224 154 m 
+gs 1 -1 scale (sender's ) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+219 169 m 
+gs 1 -1 scale (public key) col-1 show gr
+$F2psEnd
+%%EndDocument
+ @endspecial 467 1215 a(Figure)15 b(4.2)33 b(Digital)16 b(signature)h
+(generation)f(and)h(v)m(alidation)223 1399 y(The)f(follo)o(wing)g(pro)q
+(cedure)h(and)g(Figure)f(4.2)g(outline)g(ho)o(w)h(w)o(e)f(w)o(ould)g(use)h
+(the)f(public)g(k)o(ey)149 1489 y(cryptoalgorithm)f(to)i(ensure)f(originator)
+h(authen)o(tication.)223 1579 y(The)f(pro)q(cedure)g(could)g(w)o(ork)g(as)h
+(follo)o(ws:)222 1711 y Fj(\017)24 b Fo(The)17 b(sending)f(name)f(serv)o(er)g
+(creates)h(the)g(digital)g(signature)h(of)f(the)g(DNS)g(message)g
+Fn(m)p Fo(:)271 1802 y Fn(s)e Fo(=)g Fn(hash)p Fo(\()p Fn(m)p
+Fo(\))222 1933 y Fj(\017)24 b Fo(The)13 b(sending)h(name)e(serv)o(er)g(signs)
+h(the)g(message)f(digest)h(\(the)g(digital)g(signature\))g
+Fn(s)g Fo(using)271 2024 y(its)j(priv)m(ate)g(k)o(ey)f Fn(K)636
+2006 y Fd(S)r(ender)632 2036 y(pr)q(iv)767 2024 y Fo(:)22 b
+Fn(s)826 2006 y Fc(0)851 2024 y Fo(=)14 b Fn(E)939 2035 y Fd(K)971
+2024 y Fb(S)q(ender)969 2047 y(pr)q(iv)1075 2024 y Fo(\()p
+Fn(s)p Fo(\))222 2155 y Fj(\017)24 b Fo(The)17 b(sending)f(name)f(serv)o(er)g
+(transmits)h(\()p Fn(m;)8 b(s)1144 2137 y Fc(0)1155 2155 y
+Fo(\))222 2287 y Fj(\017)24 b Fo(The)f(resolv)o(er)e(decrypts)h
+Fn(s)789 2269 y Fc(0)822 2287 y Fo(b)o(y)g(applying)g(the)g(name)g(serv)o
+(er's)f(public)g(k)o(ey)g Fn(K)1799 2269 y Fd(S)r(ender)1795
+2300 y(pub)1936 2287 y Fo(:)271 2378 y Fn(s)294 2359 y Fc(00)329
+2378 y Fo(=)14 b Fn(D)421 2389 y Fd(K)453 2378 y Fb(S)q(ender)451
+2402 y(pub)558 2378 y Fo(\()p Fn(s)600 2359 y Fc(0)611 2378
+y Fo(\))222 2509 y Fj(\017)24 b Fo(The)17 b(resolv)o(er)e(recomputes)f(the)i
+(message)g(digest)g Fn(s)e Fo(=)g Fn(hash)p Fo(\()p Fn(m)p
+Fo(\))p eop
+%%Page: 77 86
+85 bop 1901 -100 a Fo(77)222 75 y Fj(\017)24 b Fo(If)19 b(\()p
+Fn(s)g Fo(=)g Fn(s)464 57 y Fc(00)486 75 y Fo(\))g(then)g(the)g(resolv)o(er)f
+(has)i(v)m(alidated)f(the)h(in)o(tegrit)o(y)d(and)j(the)f(originator)h(of)271
+165 y(the)c(DNS)h(message)223 290 y(Wh)o(y)j(do)h(w)o(e)g(calculate)f(a)h
+(message)f(digest)h(at)g(all)g(and)g(not)g(simply)e(encrypt)h(and)i(then)149
+380 y(transmit)h(the)g(whole)g(message?)43 b(The)24 b(main)e(p)q(oin)o(t)h
+(here)g(is)h(the)f(di\013erence)f(b)q(et)o(w)o(een)h(the)149
+470 y(run)o(time)16 b(costs)i(of)h(creating)e(a)i(message)e(digest)h(and)g
+(encrypting)f(a)i(message,)e(dep)q(ending)h(on)149 560 y(the)e(length)g(of)h
+(the)f(original)g(message.)223 651 y(Run)o(time)g(costs)k(for)f(public)f(k)o
+(ey)g(encryption)g(are)h(rather)g(high.)29 b(Man)o(y)19 b(CPU)g(cycles)e(are)
+149 741 y(needed.)j(Therefore)11 b(w)o(e)h(w)o(an)o(t)g(to)h(\014x)f(the)f
+(size)h(of)g(the)g(data)h(p)q(ortion)g(that)f(has)h(to)g(b)q(e)f(encrypted:)
+149 831 y(in)k(our)h(case)f(the)g(\014ngerprin)o(t,)g(the)g(output)h(of)f
+(the)g(message)g(digest)g(algorithm.)223 922 y(Run)o(time)11
+b(costs)k(for)g(the)f(hash)h(functions)f(are)g(rather)h(small)d(compared)i
+(to)g(those)h(of)f(public)149 1012 y(k)o(ey)k(encryption.)29
+b(It)19 b(is)f(therefore)h(imp)q(ortan)o(t)f(to)h(note,)h(that)f(it)g(is)f
+(more)g(e\016cien)o(t)f(to)i(pad)h(a)149 1102 y(short)f(DNS)e(message,)f
+(calculate)h(its)g(\014ngerprin)o(t,)g(and)h(then)f(encrypt)g(the)g
+(\014ngerprin)o(t,)g(than)149 1193 y(simply)22 b(to)i(encrypt)f(the)g(whole)h
+(DNS)f(message.)43 b(Message)24 b(digest)f(lengths)h(are)g(t)o(ypically)149
+1283 y(shorter)17 b(than)g(the)f(t)o(ypical)f(DNS)h(message.)149
+1444 y(4.11.3)50 b(P)o(assing)17 b(Creden)o(tials)e(to)i(Pro)o(v)o(e)e
+(Authorit)o(y)223 1566 y(The)e(name)f(serv)o(er)g(sending)h(the)g(DNS)g
+(message)f(has)i(to)f(pro)o(vide)f(creden)o(tials)g(signed)h(b)o(y)g(its)149
+1657 y(paren)o(t)18 b(domain,)f(to)i(con)o(vince)d(the)i(recipien)o(t)e(of)i
+(its)f(authorit)o(y)h(o)o(v)o(er)f(the)h(domain)f(for)h(whic)o(h)149
+1747 y(it)e(just)h(resolv)o(ed)e(a)i(mapping.)223 1837 y(The)d(use)g(of)g
+(suc)o(h)g(a)h(certi\014cate)e(transforms)h(the)f(problem)g(of)h
+(establishing)g(the)g(credibilit)o(y)149 1928 y(of)23 b(one)g(en)o(tit)o(y)e
+(in)o(to)i(the)f(problem)f(of)i(establishing)g(the)f(credibilit)o(y)e(of)j
+(the)f(en)o(tit)o(y)f(issuing)149 2018 y(the)g(certi\014cate.)32
+b(This)20 b(problem)f(is)h(v)o(ery)g(closely)f(related)g(to)i(the)f(problem)f
+(of)i(distributing)149 2108 y(public)14 b(k)o(ey)g(certi\014cates.)19
+b(The)c(CCITT)g(recommendation)d(X.509)j(sho)o(ws)g(a)g(w)o(a)o(y)g(to)g
+(solv)o(e)f(this)149 2198 y(problem.)20 b(In)15 b(X.509,)g(a)g(certi\014cate)
+f(binds)h(a)h(public)e(k)o(ey)g(to)h(a)h(directory)e(name)g(and)i(iden)o
+(ti\014es)149 2289 y(a)h(part)o(y)f(that)h(v)o(ouc)o(hes)e(for)i(the)f
+(binding.)223 2379 y(W)l(e)f(can)h(adopt)h(this)f(mec)o(hanism,)c(suc)o(h)k
+(that)h(a)f(certi\014cate)f(binds)h(all)f(name)g(serv)o(ers)g(that)149
+2469 y(are)j(authoritativ)o(e)g(for)g(a)g(certain)f(zone)h(to)g(this)g(zone)g
+(of)g(authorit)o(y)g(and)g(iden)o(ti\014es)f(the)h(zone)149
+2560 y(that)c(v)o(ouc)o(hes)d(for)i(the)g(binding.)20 b(X.509)12
+b(imp)q(oses)g(no)h(constrain)o(ts)g(on)g(the)g(seman)o(tic)d(or)j(syn)o
+(tac-)149 2650 y(tic)i(relationship)g(b)q(et)o(w)o(een)f(a)i(certi\014cate)e
+(issuer)h(and)g(a)h(sub)s(ject.)k(Ho)o(w)o(ev)o(er,)14 b(in)g(our)i(approac)o
+(h,)p eop
+%%Page: 78 87
+86 bop 1901 -100 a Fo(78)149 75 y(the)17 b(certi\014cation)f(system)f(tak)o
+(es)i(the)f(form)g(of)h(a)g(single)f(ro)q(oted)i(tree.)k(Eac)o(h)17
+b(no)q(de)g(represen)o(ts)149 165 y(a)g(zone.)22 b(Sev)o(eral)15
+b(name)h(serv)o(ers)f(serv)o(e)h(as)h(certi\014cation)e(authorities)i(for)f
+(eac)o(h)g(zone,)g(b)q(ecause)149 255 y(all)g(serv)o(ers)e(that)j(w)o(ere)d
+(in)o(tro)q(duced)i(to)g(increase)f(the)g(reliabilit)o(y)e(of)j(the)f
+(database)i(system)d(are)149 346 y(capable)j(of)f(v)m(alid)g(referrals.)223
+436 y(A)e(certi\014cate)g(for)h(a)g(zone)g(\(for)g(example)e
+(sub.domain.dom\))g(consists)i(of)h(all)e(IP)h(addresses)149
+526 y(of)i(authoritativ)o(e)g(name)e(serv)o(ers)h(for)h(that)g(zone,)f
+(signed)h(with)g(the)f(priv)m(ate)h(k)o(ey)e(of)i(the)g(name)149
+616 y(serv)o(ers)e(for)h(the)g(paren)o(t)g(domain)f(\(domain.dom\).)j(An)o(y)
+d(resolv)o(er)g(that)h(receiv)o(es)e(a)i(DNS)g(mes-)149 707
+y(sage)24 b(receiv)o(es)c(as)j(part)g(of)g(it)f(this)h(certi\014cate.)39
+b(After)21 b(obtaining)i(the)g(public)e(k)o(ey)h(for)h(the)149
+797 y(paren)o(t)16 b(zone)f(of)h(the)f(queried)g(zone,)g(the)g(resolv)o(er)g
+(can)g(then)h(v)o(erify)d(the)j(v)m(alidit)o(y)e(of)i(the)f(refer-)149
+887 y(ral.)24 b(But)17 b(to)g(v)o(erify)f(the)g(authorit)o(y)h(of)h(the)f
+(paren)o(t)f(zone,)h(the)g(resolv)o(er)f(has)i(to)f(ask)h(this)f(zone)149
+978 y(for)g(creden)o(tials.)223 1068 y(This)f(v)m(alidation)g(pro)q(cess)i
+(for)e(certi\014cates)f(is)i(done)f(recursiv)o(ely)e(up)j(the)f(tree,)f
+(starting)i(at)149 1158 y(the)f(name)f(serv)o(er)g(that)i(pro)o(vides)e(the)h
+(queried)f(mapping.)20 b(The)d(recursion)e(will)g(stop)i(at)f(some)149
+1248 y(p)q(oin)o(t,)f(either)f(at)h(the)g(ro)q(ot,)g(or)h(at)f(some)e(in)o
+(termediate)f(no)q(de)k(that)f(w)o(as)g(certi\014ed)f(b)q(efore.)20
+b(The)149 1339 y(certi\014cates)f(that)h(a)f(name)g(serv)o(er)f(holds)i(are)f
+(sub)s(ject)g(to)h(timeouts,)e(just)i(lik)o(e)e(the)h(resource)149
+1429 y(records)g(that)g(sp)q(ecify)f(bindings)h(of)g(this)f(name)g(serv)o
+(er.)27 b(The)19 b(certi\014cate)e(for)i(the)f(ro)q(ot)i(m)o(ust)149
+1519 y(b)q(e)25 b(transmitted)d(b)o(y)i(some)f(trusted,)j(out-of-band)g(mec)o
+(hanism)o(.)42 b(F)l(or)24 b(example,)g(the)f(ro)q(ot)149 1610
+y(certi\014cate)15 b(could)h(b)q(e)h(published)f(in)f(a)i(national)g(newspap)
+q(er.)223 1700 y(Ev)o(en)h(if)h(an)g(attac)o(k)o(er)f(manages)h(to)h(get)f(a)
+g(v)m(alid)g(certi\014cate)f(of)h(a)h(name)e(serv)o(er)g(it)g(w)o(an)o(ts)149
+1790 y(to)e(imp)q(ersonate,)e(and)i(has)g(the)g(capabilit)o(y)e(to)h(also)h
+(sp)q(o)q(of)h(this)f(name)e(serv)o(er's)g(IP)h(address,)h(it)149
+1880 y(is)j(still)e(not)i(p)q(ossible)g(for)f(the)h(attac)o(k)o(er)e(to)i
+(imp)q(ersonate)f(another)h(host.)28 b(As)19 b(w)o(e)f(sa)o(w)h(in)f(the)149
+1971 y(previous)g(Section)e(4.11.2,)i(a)g(DNS)f(message)g(is)g(encrypted)f
+(with)h(the)h(name)e(serv)o(er's)g(priv)m(ate)149 2061 y(k)o(ey)c(b)q(efore)g
+(it)g(is)g(sen)o(t)g(out.)21 b(The)12 b(creden)o(tials)f(are)h(part)h(of)g
+(the)f(message)g(and)h(are)f(therefore)g(also)149 2151 y(encrypted.)29
+b(An)18 b(attac)o(k)o(er)g(cannot)i(construct)f(the)g(correctly)e(enciphered)
+h(message)g(without)149 2242 y(breaking)f(the)f(public)f(k)o(ey)g(system)g
+(used.)149 2402 y(4.11.4)50 b(Example)223 2524 y(W)l(e)19 b(presen)o(t)h(an)g
+(example)e(to)i(sho)o(w)h(ho)o(w)f(certi\014cates)f(are)h(used)g(in)f(our)i
+(approac)o(h.)33 b(W)l(e)149 2614 y(assume)18 b(that)g(all)g(hosts)h(already)
+f(ha)o(v)o(e)g(the)g(public)f(k)o(eys)g(of)h(the)g(mac)o(hines)f(that)h
+(participate)p eop
+%%Page: 79 88
+87 bop 1901 -100 a Fo(79)149 75 y(in)22 b(this)f(example.)35
+b(Host)22 b(\\host.aim.")37 b(w)o(an)o(ts)22 b(to)g(resolv)o(e)e(the)h
+(name{to{address)i(binding)149 165 y(for)e(the)f(name)g(\\host.domain.dom.".)
+32 b(The)21 b(example)d(is)i(not)h(complete)d(in)i(the)h(sense)f(that)149
+255 y(all)d(p)q(ossibilities)g(are)g(not)h(co)o(v)o(ered,)d(or)j(else)e
+(reasons)j(are)e(giv)o(en)f(wh)o(y)h(a)h(name)e(serv)o(er)g(returns)149
+346 y(a)k(certain)e(referral)g(and)i(not)f(another)h(one.)30
+b(But)18 b(it)h(describ)q(es)g(the)f(o)o(v)o(erall)g(in)o(teraction)g(and)149
+436 y(stresses)f(the)f(use)g(of)h(certi\014cates.)223 526 y(T)l(able)e(4.1)g
+(con)o(tains)g(a)h(summary)c(of)k(the)f(zones)g(in)g(Figure)f(4.3,)h(and)h(T)
+l(able)f(4.2)h(in)o(terprets)149 616 y(the)g(abbreviations)h(used)f
+(through<out)h(the)f(description)g(of)h(the)f(resolution)g(pro)q(cess.)607
+824 y(T)l(able)g(4.1)33 b(Example:)19 b(certi\014cate)c(v)m(alidation)513
+955 y(Zone)h(Name)p 800 982 2 91 v 68 w(Domain)g(Name\(s\))p
+1213 982 V 48 w(Name)f(Serv)o(er\(s\))p 488 984 1124 2 v 488
+994 V 513 1057 a(.)p 800 1084 2 91 v 298 w(.)p 1213 1084 V
+400 w(ns)p 800 1174 V 825 1147 a(dom)p 1213 1174 V 321 w(ns)p
+488 1176 1124 2 v 513 1239 a(domain.dom)p 800 1266 2 91 v 47
+w(domain.dom)p 1213 1266 V 149 w(ns1.domain.dom)p 800 1357
+V 1213 1357 V 1239 1330 a(ns2.domain.dom)p 488 1358 1124 2
+v 513 1421 a(aim)p 800 1449 2 91 v 232 w(aim)p 1213 1449 V
+334 w(ns.aim)p 488 1450 1124 2 v 577 1824 a(T)l(able)i(4.2)32
+b(Example:)20 b(legend)c(of)g(abbreviations)489 1955 y(Name)p
+692 1982 2 91 v 104 w(Meaning)p 464 1984 1172 2 v 489 2047
+a Fn(M)5 b(D)q Fo(\()p Fn(m)p Fo(\))p 692 2074 2 91 v 55 w(message)16
+b(digest)g(\(\014ngerprin)o(t\))f(of)i(message)f Fn(m)489 2137
+y(K)534 2119 y Fd(ow)q(ner)530 2151 y(pub=pr)q(iv)p 692 2164
+V 718 2137 a Fo(k)o(ey)f(of)i(o)o(wner)f({)h(public/priv)m(ate)489
+2228 y Fn(E)525 2235 y Fd(K)559 2228 y Fo(\()p Fn(s)p Fo(\))p
+692 2255 V 98 w Fn(s)f Fo(encrypted)g(with)g(k)o(ey)f Fn(K)489
+2318 y(D)529 2325 y Fd(K)563 2318 y Fo(\()p Fn(s)p Fo(\))p
+692 2345 V 94 w Fn(s)h Fo(decrypted)g(with)g(k)o(ey)f Fn(K)222
+2650 y Fj(\017)24 b Fo(\\host.aim")11 b(queries)f(\\ns.aim")g(for)h
+(name{to{address)g(resolution)g(of)g(\\host.domain.dom".)p
+eop
+%%Page: 80 89
+88 bop 1901 -100 a Fo(80)262 979 y @beginspecial 0 @llx 0 @lly
+360 @urx 202 @ury 3600 @rwi @setspecial
+%%BeginDocument: pictures/expl_setup.ps
+/$F2psDict 200 dict def 
+$F2psDict begin
+$F2psDict /mtrx matrix put
+/l {lineto} bind def
+/m {moveto} bind def
+/s {stroke} bind def
+/n {newpath} bind def
+/gs {gsave} bind def
+/gr {grestore} bind def
+/clp {closepath} bind def
+/graycol {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
+4 -2 roll mul setrgbcolor} bind def
+/col-1 {} def
+/col0 {0 0 0 setrgbcolor} bind def
+/col1 {0 0 1 setrgbcolor} bind def
+/col2 {0 1 0 setrgbcolor} bind def
+/col3 {0 1 1 setrgbcolor} bind def
+/col4 {1 0 0 setrgbcolor} bind def
+/col5 {1 0 1 setrgbcolor} bind def
+/col6 {1 1 0 setrgbcolor} bind def
+/col7 {1 1 1 setrgbcolor} bind def
+ /DrawEllipse {
+	/endangle exch def
+	/startangle exch def
+	/yrad exch def
+	/xrad exch def
+	/y exch def
+	/x exch def
+	/savematrix mtrx currentmatrix def
+	x y translate xrad yrad scale 0 0 1 startangle endangle arc
+	savematrix setmatrix
+	} def
+
+	end
+/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
+/$F2psEnd {$F2psEnteredState restore end} def
+
+$F2psBegin
+0 setlinecap 0 setlinejoin
+-9.0 211.0 translate 0.900 -0.900 scale
+1.000 setlinewidth
+n 219 44 2 2 0 360 DrawEllipse gs 0.00 setgray fill gr
+gs col-1 s gr
+n 337 102 2 2 0 360 DrawEllipse gs 0.00 setgray fill gr
+gs col-1 s gr
+n 99 104 2 2 0 360 DrawEllipse gs 0.00 setgray fill gr
+gs col-1 s gr
+n 79 164 2 2 0 360 DrawEllipse gs 0.00 setgray fill gr
+gs col-1 s gr
+n 279 164 2 2 0 360 DrawEllipse gs 0.00 setgray fill gr
+gs col-1 s gr
+n 259 104 2 2 0 360 DrawEllipse gs 0.00 setgray fill gr
+gs col-1 s gr
+n 159 164 2 2 0 360 DrawEllipse gs 0.00 setgray fill gr
+gs col-1 s gr
+n 339 104 70 50 0 360 DrawEllipse gs col-1 s gr
+n 159 74 90 65 0 360 DrawEllipse gs col-1 s gr
+n 79 184 70 50 0 360 DrawEllipse gs col-1 s gr
+n 219 44 m 339 104 l gs col-1 s gr
+n 219 44 m 99 104 l gs col-1 s gr
+n 99 104 m 79 164 l gs col-1 s gr
+n 219 44 m 219 64 l gs col-1 s gr
+n 339 104 m 349 124 l gs col-1 s gr
+n 339 104 m 329 124 l gs col-1 s gr
+n 79 164 m 99 184 l gs col-1 s gr
+n 79 164 m 79 184 l gs col-1 s gr
+n 79 164 m 59 184 l gs col-1 s gr
+	1 setlinecap [1 4.500000] 4.500000 setdash
+n 339 104 m 359 124 l gs col-1 s gr
+	[] 0 setdash 0 setlinecap
+	1 setlinecap [1 4.500000] 4.500000 setdash
+n 219 44 m 259 104 l gs col-1 s gr
+	[] 0 setdash 0 setlinecap
+	1 setlinecap [1 4.500000] 4.500000 setdash
+n 99 104 m 159 164 l gs col-1 s gr
+	[] 0 setdash 0 setlinecap
+	1 setlinecap [1 4.500000] 4.500000 setdash
+n 339 104 m 279 164 l gs col-1 s gr
+	[] 0 setdash 0 setlinecap
+n 334 134 m 334 124 l  324 124 l  324 134 l  clp gs col-1 s gr
+n 369 134 m 369 124 l  359 124 l  359 134 l  clp gs col-1 s gr
+n 104 194 m 104 184 l  94 184 l  94 194 l  clp gs col-1 s gr
+n 224 74 m 214 74 l  214 64 l  224 64 l  clp gs 0.00 setgray fill gr
+gs col-1 s gr
+n 354 134 m 344 134 l  344 124 l  354 124 l  clp gs 0.00 setgray fill gr
+gs col-1 s gr
+n 64 194 m 54 194 l  54 184 l  64 184 l  clp gs 0.00 setgray fill gr
+gs col-1 s gr
+n 84 194 m 74 194 l  74 184 l  84 184 l  clp gs 0.00 setgray fill gr
+gs col-1 s gr
+0.500 setlinewidth
+n 279 19 m 219 44 l gs col-1 s gr
+n 227.154 42.769 m 219.000 44.000 l 225.615 39.077 l gs 2 setlinejoin col-1 s gr
+/Times-Bold findfont 12.00 scalefont setfont
+204 39 m 
+gs 1 -1 scale (".") col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+79 99 m 
+gs 1 -1 scale ("dom") col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+344 99 m 
+gs 1 -1 scale ("aim") col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+29 159 m 
+gs 1 -1 scale ("domain") col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+49 209 m 
+gs 1 -1 scale (ns1) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+74 209 m 
+gs 1 -1 scale (ns2) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+104 209 m 
+gs 1 -1 scale (host) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+309 149 m 
+gs 1 -1 scale (host) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+344 149 m 
+gs 1 -1 scale (ns) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+209 89 m 
+gs 1 -1 scale (ns) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+39 24 m 
+gs 1 -1 scale (zone ".") col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+284 24 m 
+gs 1 -1 scale (root) col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+149 219 m 
+gs 1 -1 scale (zone "domain.dom") col-1 show gr
+/Times-Bold findfont 12.00 scalefont setfont
+304 49 m 
+gs 1 -1 scale (zone "aim") col-1 show gr
+$F2psEnd
+%%EndDocument
+ @endspecial 597 1224 a(Figure)16 b(4.3)33 b(Example:)19 b(certi\014cate)c(v)
+m(alidation)222 1408 y Fj(\017)24 b Fo(\\ns.aim")16 b(replies)f(with)h(a)h
+(referral)e(to)i(\\ns2.domain.dom")222 1540 y Fj(\017)24 b
+Fo(\\host.aim")16 b(queries)f(\\ns2.domain.dom")h(for)g(name{to{address)h
+(resolution)271 1630 y(of)g(\\host.domain.dom".)222 1762 y
+Fj(\017)24 b Fo(\\ns2.domain.dom")16 b(replies)f(with)h(\()p
+Fn(m)p Fo(,)p Fn(c)p Fo(,)p Fn(s)p Fo(\),)e(where)271 1852
+y Fn(m)38 b Fo(=)21 b(mapping)16 b(information)f(\\host.domain.dom")g
+Fj(!)h Fo(IP)1424 1859 y Fm(host)p Fd(:)p Fm(domain)o Fd(:)p
+Fm(do)o(m)271 1942 y Fn(c)60 b Fo(=)21 b(creden)o(tials)15
+b(from)g(\\ns2.domain.dom"'s)g(paren)o(t)h(zone's)g(name)f(serv)o(er)g(\\ns")
+352 2032 y(=)21 b Fn(E)447 2039 y Fd(K)479 2028 y Fb(ns)477
+2052 y(pr)q(iv)556 2032 y Fo(\(list)16 b(of)g(all)g(IP)g(addresses)h(of)g
+(authoritativ)o(e)e(name)g(serv)o(ers)411 2123 y(for)i(zone)f
+(\\domain.dom"\))271 2213 y Fn(s)58 b Fo(=)21 b(encrypted)15
+b(message)h(digest)g(of)h Fn(m)f Fo(concatenated)g(with)g Fn(c)352
+2303 y Fo(=)21 b Fn(E)447 2315 y Fd(K)479 2303 y Fb(ns)p Fe(2)p
+Fb(:domain:dom)477 2327 y(pr)q(iv)715 2303 y Fo(\()p Fn(M)5
+b(D)q Fo(\()p Fn(m)p Fj(j)p Fn(c)p Fo(\)\))222 2435 y Fj(\017)24
+b Fo(\\host.aim")16 b(receiv)o(es)e(\()p Fn(m)p Fo(,)p Fn(c)p
+Fo(,)p Fn(s)p Fo(\),)h(and)i(then)p eop
+%%Page: 81 90
+89 bop 1901 -100 a Fo(81)326 75 y Fi({)25 b Fo(v)m(alidates)18
+b Fn(s)p Fo(,)g(b)o(y)f(calculating)h Fn(s)979 57 y Fc(0)1007
+75 y Fo(=)f Fn(M)5 b(D)q Fo(\()p Fn(c)p Fj(j)p Fn(s)p Fo(\))19
+b(and)g Fn(s)1390 57 y Fc(00)1428 75 y Fo(=)e Fn(D)1523 86
+y Fd(K)1555 75 y Fb(ns)p Fe(2)p Fb(:domain:dom)1553 99 y(pub)1792
+75 y Fo(\()p Fn(s)p Fo(\))h(and)379 165 y(comparing)d(them.)379
+255 y(If)g(they)h(are)g(equal)g Fj(!)g Fo(ok!)326 366 y Fi({)25
+b Fo(v)m(alidates)16 b Fn(c)p Fo(,)g(b)o(y)f(calculating)h
+Fn(L)e Fo(=)g Fn(D)1085 373 y Fd(K)1117 362 y Fb(ns)1115 386
+y(pub)1167 366 y Fo(\()p Fn(c)p Fo(\))i(and)h(c)o(hec)o(king)379
+457 y(if)e(IP)474 464 y Fm(ns2)p Fd(:)p Fm(domain)p Fd(:)p
+Fm(d)o(om)741 457 y Fj(2)f Fn(L)p Fo(.)379 547 y(If)h(so)i
+Fj(!)f Fo(ok!)326 658 y Fi({)25 b Fo(c)o(hec)o(ks)14 b(if)i(\\ns")h(is)f
+(already)h(v)m(alidated)f(\(previously)l(,)e(or)j(ro)q(ot)g(name)e(serv)o
+(er\).)379 748 y(If)g(\\ns")i(w)o(ere)e(not)i(a)f(ro)q(ot)h(name)e(serv)o
+(er,)f(\\host.aim")i(w)o(ould)g(request)f(creden)o(tials)379
+839 y(from)g(\\ns"'s)i(paren)o(t)f(zone)g(and)h(v)m(alidate)f(them)f(the)h
+(same)f(w)o(a)o(y)149 999 y(4.11.5)50 b(Discussion)223 1121
+y(The)16 b(v)m(alidation)f(of)i(in)o(tegrit)o(y)d(and)i(originator)h(of)f
+(the)g(message,)e(and)j(its)f(underlying)f(pat-)149 1211 y(tern)20
+b(of)g(certi\014cations)f(stating)h(trust)g(are)g(the)f(features)h(that)g
+(mak)o(e)e(this)h(approac)o(h)i(secure.)149 1302 y(The)e(follo)o(wing)f
+(discussion)g(sho)o(ws)h(its)f(disadv)m(an)o(tages.)28 b(Some)17
+b(of)i(them)d(are)i(serious)h(enough)149 1392 y(to)e(blo)q(c)o(k)f(an)h
+(implem)o(e)o(n)o(tation)d(of)i(this)g(approac)o(h)h(at)g(the)f(curren)o(t)f
+(time.)223 1482 y(The)g(whole)g(pro)q(cedure)h(is)f(v)o(ery)f(time)f(and)j
+(space)g(consuming.)k(Man)o(y)15 b(rather)h(long)f(public)149
+1572 y(k)o(eys)k(ha)o(v)o(e)f(to)h(b)q(e)h(stored)f(\(ab)q(out)i(200)f
+(decimal)d(digits)i(long)g(eac)o(h)g(to)g(mak)o(e)f(the)g(public)h(k)o(ey)149
+1663 y(encryption)i(reasonably)h(strong\).)38 b(Obtaining)21
+b(memory)e(for)j(them,)e(as)i(w)o(ell)e(as)i(additional)149
+1753 y(cac)o(he)17 b(memory)e(for)j(larger)g(resource)f(records,)g(is)h(not)g
+(a)g(problem)e(in)i(curren)o(t)e(arc)o(hitectures.)149 1843
+y(The)f(k)o(eys)f(ha)o(v)o(e)g(to)h(b)q(e)g(obtained)g(b)q(efore)g(they)g
+(can)g(b)q(e)f(used.)21 b(S.)15 b(Ken)o(t)f(describ)q(es)g(in)h([Ken93b])149
+1934 y(certi\014cate)e(based)i(k)o(ey)d(managemen)o(t;)g(X.509)j(is)e(the)h
+(equiv)m(alen)o(t)f(in)g(the)h(OSI)1604 1915 y Fm(2)1623 1934
+y Fo(-w)o(orld.)21 b(W)l(e)14 b(will)149 2024 y(not)19 b(go)g(in)o(to)f
+(detail)g(regarding)h(the)f(k)o(ey)f(distribution)h(pro)q(cess.)28
+b(The)18 b(registering)g(pro)q(cess)h(is)149 2114 y(rather)h(cum)o(b)q
+(ersome.)29 b(The)20 b(calculations)f(to)i(encrypt)e(and)h(decrypt)f(message)
+g(digests)h(ma)o(y)149 2204 y(tak)o(e)h(to)q(o)h(long)g(to)g(supp)q(ort)g
+(the)f(goal)h(of)f(the)g(Domain)g(Name)f(System)f(of)j(e\016ciency)l(.)33
+b(The)149 2295 y(additional)14 b(data)h(that)f(has)h(to)f(b)q(e)g
+(transmitted)f(w)o(ould)h(not)g(degrade)g(p)q(erformance)f(to)q(o)i(badly)l
+(,)149 2385 y(esp)q(ecially)f(if)g(faster)h(transmission)f(media)f(b)q
+(ecomes)h(broadly)h(a)o(v)m(ailable,)f(but)h(the)f(calculation)149
+2475 y(o)o(v)o(erhead)i(for)h(encryption)e(and)i(decryption)e(cannot)i
+(easily)f(b)q(e)g(amortized.)p 149 2519 720 2 v 206 2550 a
+Fl(2)224 2565 y Fk(\\Op)q(en)h(Systems)e(In)o(terconnection)j({)d(A)h
+(reference)j(to)c(proto)q(cols,)h(sp)q(eci\014cally)g(ISO)h(standards,)f(for)
+g(the)149 2614 y(in)o(terconnection)f(of)f(co)q(op)q(erativ)o(e)g(computer)g
+(systems."[Com91)m(])p eop
+%%Page: 82 91
+90 bop 1901 -100 a Fo(82)223 75 y(The)21 b(implem)o(en)n(tation)e(of)i(suc)o
+(h)g(a)h(solution)f(is)g(a)g(ma)s(jor)g(e\013ort.)36 b(The)21
+b(whole)g(k)o(ey)f(man-)149 165 y(agemen)o(t)i(problem)g(is)i(complex)d(and)j
+(it)f(also)h(requires)f(additional)g(administrativ)o(e)e(e\013ort.)149
+255 y(Resolv)o(er)14 b(routines)i(and)f(name)f(serv)o(er)g(routines)i(ha)o(v)
+o(e)e(to)h(b)q(e)h(mo)q(di\014ed,)e(along)i(with)f(the)g(DNS)149
+346 y(proto)q(col.)30 b(The)18 b(implem)o(en)o(tation)e(is)i(feasible,)g
+(though)i(v)o(ery)d(complex.)26 b(Another)19 b(dra)o(wbac)o(k)149
+436 y(is)d(the)g(transition)h(phase)g(that)f(is)g(necessary)g(b)q(ecause)h
+(of)f(proto)q(col)h(c)o(hanges.)223 526 y(Ov)o(erall,)10 b(the)i(metho)q(d)f
+(seems)f(to)i(b)q(e)g(hardly)g(feasible,)f(b)q(ecause)h(of)g(its)g(large)f
+(computational)149 616 y(o)o(v)o(erhead.)21 b(F)l(urther)16
+b(dra)o(wbac)o(ks)g(are)g(the)g(necessary)g(proto)q(col)h(c)o(hanges)f(and)h
+(the)f(complexit)o(y)149 707 y(of)h(prop)q(er)g(k)o(ey)e(and)i(certi\014cate)
+e(managemen)o(t.)p eop
+%%Page: 83 92
+91 bop 1901 -100 a Fo(83)637 342 y(5.)32 b(CONCLUSIONS)16 b(AND)f(OUTLOOK)223
+516 y(The)20 b(Domain)g(Name)e(System)h(is)h(the)g(w)o(orld's)g(most)g
+(distributed)f(database,)k(managing)149 606 y(name)15 b(resolution)h(for)g
+(ab)q(out)h(1.5)f(million)e(hosts.)22 b(In)15 b(this)h(thesis)f(w)o(e)h
+(outlined)f(and)i(explained)149 696 y(the)f(curren)o(t)g(implem)o(en)n
+(tation)e(of)j(the)f(Domain)f(Name)g(System.)223 787 y(W)l(e)i(stated)i(the)f
+(main)f(problem)f(w)o(e)i(are)g(dealing)g(with)g(in)f(this)h(thesis:)25
+b(name)17 b(based)i(au-)149 877 y(then)o(tication,)f(where)f(the)h(name)f
+(resolution)h(pro)q(cess)h(cannot)f(b)q(e)h(trusted.)26 b(W)l(e)18
+b(examined)e(a)149 967 y(metho)q(d)k(to)g(abuse)g(the)g(Domain)f(Name)f
+(System)g(for)i(system)f(break{ins)h(and)g(sho)o(w)o(ed)g(that)149
+1057 y(this)g(metho)q(d)e(exploits)g(sev)o(eral)g(w)o(eaknesses.)30
+b(All)18 b(these)h(w)o(eaknesses)g(are)g(necessary)g(b)q(efore)149
+1148 y(the)d(break{in)g(is)g(p)q(ossible.)21 b(W)l(e)16 b(demonstrated)f(the)
+h(feasibilit)o(y)e(of)j(the)e(break{in)h(b)o(y)g(describ-)149
+1238 y(ing)j(our)g(implem)o(en)n(tation)d(in)i(an)h(exp)q(erimen)o(tal)d(net)
+o(w)o(ork,)h(set)i(up)f(to)h(satisfy)g(the)f(necessary)149
+1328 y(assumptions)f(that)f(matc)o(h)f(the)h(real)g(w)o(orld)g(situation)g
+(in)g(the)g(crucial)g(p)q(oin)o(ts.)223 1419 y(W)l(e)21 b(pro)o(vided)f(the)h
+(securit)o(y)f(considerations)h(found)h(in)f(the)g(o\016cial)f(design)i(do)q
+(cumen)o(ts)149 1509 y(and)e(analyzed)f(name)e(serv)o(er)h(and)i(resolv)o(er)
+e(algorithms)g(with)h(resp)q(ect)g(to)g(securit)o(y)e(\015a)o(ws)j(or)149
+1599 y(w)o(eak)c(assumptions.)21 b(Most)15 b(of)h(the)f(solutions)h(presen)o
+(ted)f(are)h(not)g(complete)d(solutions)j(to)g(the)149 1689
+y(problem)11 b(in)h(the)g(sense)g(that)g(they)g(cannot)g(prev)o(en)o(t)f(the)
+h(break{in)g(unconditionally)l(.)19 b(Ho)o(w)o(ev)o(er,)149
+1780 y(a)c(com)o(bination)e(of)i(some)e(of)i(the)f(prop)q(osed)i(solutions)f
+(increases)f(the)g(securit)o(y)f(of)i(the)f(Domain)149 1870
+y(Name)j(System)f(and)i(giv)o(es)f(a)i(high)f(con\014dence)f(in)h(securit)o
+(y)l(,)e(although)j(complete)c(securit)o(y)i(is)149 1960 y(not)g(ac)o(hiev)o
+(ed.)223 2051 y(W)l(e)i(consider)h(the)g(Berk)o(eley)d(patc)o(h)j(to)h(b)q(e)
+f(mandatory)l(.)32 b(The)20 b(curren)o(t)f(impleme)o(n)o(tation)149
+2141 y(of)h(the)e(T)l(rusted)h(Net)o(w)o(ork)f(concept)g(in)g(UNIX)f(is)i
+(far)g(from)f(b)q(eing)h(optimal)e(from)h(a)h(securit)o(y)149
+2231 y(p)q(oin)o(t)e(of)h(view.)k(W)l(e)17 b(prop)q(ose)h(ma)s(jor)e(impro)o
+(v)o(em)o(en)n(ts)e(in)j(its)g(design,)f(whic)o(h)h(w)o(ould)g(also)g(tak)o
+(e)149 2322 y(care)f(of)h(other)f(shortcomings)g(in)g(the)g(securit)o(y)f(of)
+h(systems.)223 2412 y(F)l(uture)e(w)o(ork)h(could)g(implem)o(en)n(t)d(some)i
+(of)h(the)g(solutions)g(w)o(e)g(ga)o(v)o(e)f(in)h(the)g(previous)f(c)o(hap-)
+149 2502 y(ter.)29 b(Exp)q(erience)17 b(with)i(the)g(implem)o(e)o(n)o(tation)
+d(of)j(p)q(olicy)g(based)g(solutions)g(w)o(ould)g(giv)o(e)f(deep)149
+2592 y(insigh)o(t)e(in)o(to)g(the)g(applicabilit)o(y)e(of)j(these)f(approac)o
+(hes.)p eop
+%%Page: 84 93
+92 bop 1901 -100 a Fo(84)223 75 y(An)18 b(implem)o(en)n(tation)e(of)j(the)f
+(solution)h(presen)o(ted)f(in)g(Section)g(4.11)h(\(Digital)f(Signatures)149
+165 y(and)f(Public)d(Key)h(Encryption\))h(w)o(ould)f(pro)o(vide)g(a)h(test)f
+(en)o(vironmen)o(t)e(to)j(determine)d(run)o(time)149 255 y(costs)20
+b(of)g(that)g(approac)o(h.)32 b(These)20 b(results)f(in)g(connection)g(with)h
+(results)f(of)h(the)f(exp)q(eriences)149 346 y(gained)d(with)g(the)f(PEM)h
+(system)e(could)h(lead)h(to)g(surprising)f(conclusions.)21
+b(Despite)16 b(the)f(man)o(y)149 436 y(disadv)m(an)o(tages)i(w)o(e)d(found,)i
+(w)o(e)f(still)f(consider)g(this)h(solution)h(w)o(orth)f(some)f(more)g
+(though)o(t)i(and)149 526 y(examination.)p eop
+%%Page: 84 94
+93 bop 855 1170 a Fo(BIBLIOGRAPHY)p eop
+%%Page: 85 95
+94 bop 1901 -100 a Fo(85)855 342 y(BIBLIOGRAPHY)202 598 y([AL92])24
+b(P)o(aul)14 b(Albitz)e(and)i(Cric)o(k)o(et)e(Liu.)21 b Fa(DNS)16
+b(and)f(BIND)p Fo(.)20 b(O'Reilley)11 b(&)j(Asso)q(ciates,)h(Inc.)369
+658 y(Sebastop)q(ol,)i(CA.,)e(1992.)199 760 y([Bel89])23 b(Stev)o(en)h(M.)h
+(Bello)o(vin.)45 b Fa(Se)n(curity)26 b(Pr)n(oblems)g(in)g(the)g(TCP/IP)f(Pr)n
+(oto)n(c)n(ol)g(Suite)p Fo(.)369 820 y(A)l(T&T)16 b(Bell)f(Lab)q(oratories,)i
+(Murra)o(y)f(Hill,)e(New)i(Jersey)l(,)f(April)g(1989.)174 922
+y([Bel90a])24 b(Stev)o(en)c(M.)h(Bello)o(vin.)35 b(Pseudo-Net)o(w)o(ork)22
+b(Driv)o(ers)e(and)j(Virtual)d(Net)o(w)o(orks.)37 b(In)369
+982 y Fa(Pr)n(o)n(c.)27 b(Winter)h(USENIX)h(Confer)n(enc)n(e)p
+Fo(,)i(pages)d(229{244,)33 b(W)l(ashington,)e(D.C.,)369 1042
+y(1990.)172 1144 y([Bel90b])23 b(Stev)o(en)c(M.)h(Bello)o(vin.)31
+b Fa(Using)22 b(the)f(Domain)g(Name)h(System)f(for)g(System)g(Br)n(e)n(ak-)
+369 1204 y(ins)p Fo(.)f(A)l(T&T)12 b(Bell)e(Lab)q(oratories,)k(Murra)o(y)e
+(Hill,)e(New)i(Jersey)l(,)g(1990.)21 b(\(unpublished)369 1264
+y(tec)o(hnical)14 b(rep)q(ort\).)199 1366 y([Bel92])23 b(Stev)o(en)16
+b(M.)g(Bello)o(vin.)21 b(There)16 b(Be)h(Dragons.)25 b(In)16
+b Fa(UNIX)j(Se)n(curity)f(Symp)n(osium)f(III)369 1426 y(Pr)n(o)n(c)n(e)n(e)n
+(dings)p Fo(,)e(pages)i(1{16,)g(Baltimore,)c(MD,)j(1992.)196
+1528 y([BG92])24 b(Dimitri)c(Bertsek)m(as)j(and)g(Rob)q(ert)h(Gallager.)41
+b Fa(Data)23 b(Networks)p Fo(.)42 b(Pren)o(tice-Hall,)369 1588
+y(Englew)o(o)q(o)q(d)18 b(Cli\013s,)d(New)h(Jersey)l(,)f(second)i(edition,)e
+(1992.)196 1690 y([CD88])25 b(George)19 b(F.)g(Coulouris)h(and)g(Jean)f
+(Dollimore.)28 b Fa(Distribute)n(d)20 b(Systems)p Fo(.)30 b(Addison-)369
+1750 y(W)l(esley)15 b(Publishing)h(Compan)o(y)l(,)f(Inc.,)g(1988.)168
+1852 y([Com91])24 b(Douglas)d(E.)e(Comer.)29 b Fa(Internetworking)23
+b(with)e(TCP/IP)p Fo(.)30 b(Pren)o(tice-Hall,)17 b(Engle-)369
+1912 y(w)o(o)q(o)q(d)h(Cli\013s,)d(New)h(Jersey)l(,)f(second)i(edition,)e
+(1991.)183 2014 y([Den82])24 b(Doroth)o(y)e(E.)f(Denning.)36
+b Fa(Crypto)n(gr)n(aphy)19 b(and)j(Data)g(Se)n(curity)p Fo(.)36
+b(Addison-W)l(esley)369 2074 y(Publishing)16 b(Compan)o(y)l(,)f(Inc.,)g
+(1982.)193 2176 y([DK84])25 b(Kevin)19 b(J.)g(Dunlap)i(and)f(Mic)o(hael)e(J.)
+i(Karels.)31 b Fa(Name)22 b(Server)f(Op)n(er)n(ations)f(Guide)369
+2236 y(for)d(BIND,)g(R)n(ele)n(ase)h(4.8)p Fo(.)j(Univ)o(ersit)o(y)13
+b(of)k(California,)f(Berk)o(eley)l(,)d(CA,)i(Ma)o(y)h(1984.)156
+2337 y([DOK92])24 b(P)o(eter)11 b(B.)g(Danzig,)i(Katia)f(Obraczk)m(a,)g(and)h
+(Anan)o(t)e(Kumar.)19 b(An)11 b(Analysis)h(of)g(Wide-)369 2398
+y(Area)k(Name)f(Serv)o(er)g(T)l(ra\016c.)21 b Fa(Computer)d(Communic)n
+(ations)g(R)n(eview)p Fo(,)e(22\(4\):281{)369 2458 y(92,)g(Octob)q(er)h
+(1992.)203 2560 y([GS91])25 b(Simson)16 b(Gar\014nk)o(el)h(and)i(Gene)e
+(Spa\013ord.)26 b Fa(Pr)n(actic)n(al)19 b(UNIX)g(Se)n(curity)p
+Fo(.)25 b(O'Reilley)369 2620 y(&)16 b(Asso)q(ciates,)g(Inc.)f(Sebastop)q(ol,)
+i(CA.,)f(1991.)p eop
+%%Page: 86 96
+95 bop 1901 -100 a Fo(86)178 75 y([Hun92])24 b(Craig)e(Hun)o(t.)37
+b Fa(TCP/IP)22 b(Network)i(A)n(dministr)n(ation)p Fo(.)37 b(O'Reilley)19
+b(&)j(Asso)q(ciates,)369 135 y(Inc.)15 b(Sebastop)q(ol,)i(CA.,)e(1992.)193
+237 y([Kal92])24 b(Burton)19 b(S.)g(Kaliski.)28 b Fa(RF)o(C-1319)19
+b(The)h(MD2)g(Message-Digest)h(A)o(lgorithm)p Fo(.)30 b(Net-)369
+297 y(w)o(ork)16 b(W)l(orking)h(Group,)f(April)f(1992.)158
+399 y([Ken93a])24 b(Stephen)d(T.)f(Ken)o(t.)34 b(In)o(ternet)20
+b(Priv)m(acy)g(Enhanced)i(Mail.)34 b Fa(Communic)n(ations)22
+b(of)369 459 y(the)c(A)o(CM)p Fo(,)d(36\(8\):48{59,)k(Ma)o(y)c(1993.)155
+560 y([Ken93b])24 b(Stephen)15 b(T.)g(Ken)o(t.)20 b Fa(RF)o(C-1422)15
+b(Privacy)i(Enhanc)n(ement)h(for)e(Internet)i(Ele)n(ctr)n(onic)369
+621 y(Mail:)42 b(Part)27 b(II:)g(Certi\014c)n(ate-Base)n(d)i(Key)f
+(Management)p Fo(.)55 b(Net)o(w)o(ork)26 b(W)l(orking)369 681
+y(Group,)17 b(F)l(ebruary)e(1993.)195 782 y([KR88])24 b(Brian)19
+b(W.)g(Kernighan)h(and)g(Dennis)g(M.)f(Ritc)o(hie.)29 b Fa(Pr)n(o)n(gr)n
+(ammier)n(en)18 b(in)j(C)p Fo(.)31 b(Carl)369 843 y(Hanser)16
+b(V)l(erlag)g(M)q(\177)-26 b(unc)o(hen)16 b(Wien,)f(second)i(edition,)e
+(1988.)195 944 y([Lot93])25 b(Mark)20 b(Lottor.)34 b(In)o(ternet)19
+b(Domain)g(Surv)o(ey)g(Apr)h(93.)34 b(SRI)20 b(In)o(ternational,)g(April)369
+1005 y(1993.)202 1106 y([LR93])25 b(Daniel)k(C.)g(Lync)o(h)h(and)g(Marshall)f
+(T.)h(Rose.)61 b Fa(Internet)31 b(System)f(Handb)n(o)n(ok)p
+Fo(.)369 1166 y(Addison-W)l(esley)15 b(Publishing)h(Compan)o(y)l(,)f(Inc.,)g
+(1993.)172 1268 y([Mad92])25 b(J\034rgen)d(Bo)f(Madsen.)36
+b(The)21 b(greatest)g(crac)o(k)o(er-case)f(in)h(Denmark:)30
+b(The)21 b(detect-)369 1328 y(ing,)16 b(tracing)h(and)g(arresting)g(of)g(t)o
+(w)o(o)f(in)o(ternational)g(crac)o(k)o(ers.)21 b(In)16 b Fa(UNIX)i(Se)n
+(curity)369 1389 y(Symp)n(osium)e(III)h(Pr)n(o)n(c)n(e)n(e)n(dings)p
+Fo(,)e(pages)i(17{40,)h(Baltimore,)13 b(MD,)j(1992.)183 1490
+y([Mer89])24 b(Ralph)16 b(C.)g(Merkle.)k(Snefru.)h(Xero)o(x)15
+b(Corp)q(oration,)j(P)o(alo)e(Alto,)f(CA,)h(1989.)152 1592
+y([Mo)q(c83a])25 b(P)o(aul)f(Mo)q(c)o(k)m(ap)q(etris.)44 b
+Fa(RF)o(C-882)24 b(Domain)g(Names)h(-)g(Conc)n(epts)g(and)g(F)l(acilities)p
+Fo(.)369 1652 y(Net)o(w)o(ork)15 b(W)l(orking)h(Group,)h(No)o(v)o(em)o(b)q
+(er)c(1983.)149 1754 y([Mo)q(c83b])25 b(P)o(aul)17 b(Mo)q(c)o(k)m(ap)q
+(etris.)25 b Fa(RF)o(C-883)18 b(Domain)g(Names)h(-)g(Implementation)h(and)f
+(Sp)n(e)n(ci-)369 1814 y(\014c)n(ation)p Fo(.)j(Net)o(w)o(ork)15
+b(W)l(orking)h(Group,)h(No)o(v)o(em)o(b)q(er)c(1983.)152 1916
+y([Mo)q(c87a])25 b(P)o(aul)c(Mo)q(c)o(k)m(ap)q(etris.)37 b
+Fa(RF)o(C-1034)21 b(Domain)h(Names)g(-)h(Conc)n(epts)f(and)h(F)l(acilities)p
+Fo(.)369 1976 y(Net)o(w)o(ork)15 b(W)l(orking)h(Group,)h(No)o(v)o(em)o(b)q
+(er)c(1987.)149 2078 y([Mo)q(c87b])25 b(P)o(aul)16 b(Mo)q(c)o(k)m(ap)q
+(etris.)22 b Fa(RF)o(C-1035)17 b(Domain)g(Names)h(-)g(Implementation)h(and)f
+(Sp)n(e)n(c-)369 2138 y(i\014c)n(ation)p Fo(.)k(Net)o(w)o(ork)15
+b(W)l(orking)h(Group,)h(No)o(v)o(em)o(b)q(er)c(1987.)177 2240
+y([Mo)q(c89])24 b(P)o(aul)18 b(Mo)q(c)o(k)m(ap)q(etris.)27
+b Fa(RF)o(C-1123)18 b(R)n(e)n(quir)n(ements)h(for)g(Internet)h(Hosts)g({)f
+(Applic)n(a-)369 2300 y(tion)f(and)f(Supp)n(ort)p Fo(.)k(Net)o(w)o(ork)15
+b(W)l(orking)i(Group,)f(1989.)181 2401 y([Mor85])24 b(R.)16
+b(T.)h(Morris.)23 b(A)16 b(W)l(eakness)h(in)g(the)f(4.2BSD)h(UNIX)e(TCP/IP)j
+(Soft)o(w)o(are.)23 b(Com-)369 2462 y(puting)13 b(Science)d(T)l(ec)o(hnical)h
+(Rep)q(ort)i(No.)f(117,)i(A)l(T&T)f(Bell)d(Lab)q(oratories,)15
+b(Murra)o(y)369 2522 y(Hill,)f(New)i(Jersey)l(,)f(F)l(ebruary)h(1985.)p
+eop
+%%Page: 87 97
+96 bop 1901 -100 a Fo(87)193 75 y([P)o(ar91])25 b(T.)18 b(A.)g(P)o(ark)o(er.)
+28 b(A)19 b(Secure)f(System)f(for)i(Applications)f(in)g(a)h(Multi-v)o(endor)f
+(En)o(vi-)369 135 y(ronmen)o(t)f(\(The)i(SESAME)f(pro)s(ject\).)28
+b(In)18 b(14)1230 117 y Fd(th)1286 135 y Fa(NCSC)i(Confer)n(enc)n(e)g(Pr)n(o)
+n(c)n(e)n(e)n(dings)p Fo(,)369 195 y(1991.)j(V)l(ol.)15 b(I)q(I.)205
+297 y([PL91])25 b(R.)19 b(P)o(aans)h(and)g(H.)f(de)g(Lange.)31
+b(Auditing)19 b(the)g(SNA/SNI)f(En)o(vironmen)o(t.)28 b Fa(Com-)369
+357 y(puter)18 b(&)f(Se)n(curity)p Fo(,)f(10\(3\):251{61,)j(Ma)o(y)d(1991.)
+169 459 y([Riv92a])24 b(Ronald)c(L.)g(Riv)o(est.)31 b Fa(RF)o(C-1320)19
+b(The)i(MD4)f(Message-Digest)j(A)o(lgorithm)p Fo(.)32 b(Net-)369
+519 y(w)o(ork)16 b(W)l(orking)h(Group,)f(April)f(1992.)166
+621 y([Riv92b])24 b(Ronald)c(L.)g(Riv)o(est.)31 b Fa(RF)o(C-1321)19
+b(The)i(MD5)f(Message-Digest)j(A)o(lgorithm)p Fo(.)32 b(Net-)369
+681 y(w)o(ork)16 b(W)l(orking)h(Group,)f(April)f(1992.)169
+782 y([RSA78])24 b(R.)18 b(Riv)o(est,)g(A.)g(Shamir,)g(and)i(L.)f(Adleman.)28
+b(A)18 b(Metho)q(d)h(for)h(Obtaining)f(Digital)369 843 y(Signatures)e(and)g
+(Public)f(Key)g(Cryptosystems.)21 b Fa(Communic)n(ations)d(of)g(the)g(A)o(CM)
+p Fo(,)369 903 y(21\(2\):120{6,)g(F)l(ebruary)e(1978.)178 1005
+y([SNS88])24 b(J.G.)18 b(Steiner,)f(C.)h(Neuman,)f(and)h(J.I.)f(Sc)o(hiller.)
+25 b(Kerb)q(eros:)h(An)18 b(Authen)o(tication)369 1065 y(Service)c(for)h(Op)q
+(en)h(Net)o(w)o(ork)e(Systems.)19 b(In)c Fa(Pr)n(o)n(c)n(e)n(e)n(dings,)h
+(Winter)g(USENIX)p Fo(,)g(Dal-)369 1125 y(las,)g(T)l(exas,)g(1988.)190
+1227 y([Spa88])25 b(Eugene)14 b(H.)f(Spa\013ord.)21 b(The)14
+b(In)o(ternet)e(W)l(orm)h(Program:)20 b(An)13 b(Analysis.)20
+b(T)l(ec)o(hnical)369 1287 y(Rep)q(ort)d(CSD-TR-823,)h(Purdue)e(Univ)o(ersit)
+o(y)l(,)d(W)l(est)j(Lafa)o(y)o(ette,)g(IN,)f(1988.)201 1389
+y([Ste90])24 b(Ric)o(hard)17 b(W.)h(Stev)o(ens.)26 b Fa(UNIX)19
+b(Network)h(Pr)n(o)n(gr)n(amming)p Fo(.)25 b(Pren)o(tice-Hall,)16
+b(Engle-)369 1449 y(w)o(o)q(o)q(d)i(Cli\013s,)d(New)h(Jersey)l(,)f(1990.)198
+1550 y([Sto89])25 b(Cli\013ord)19 b(P)l(.)f(Stoll.)28 b Fa(The)20
+b(Cucko)n(o's)f(Egg:)28 b(T)l(r)n(acing)20 b(a)f(Spy)h(Thr)n(ough)f(the)h
+(Maze)g(of)369 1611 y(Computer)d(Espionage)p Fo(.)22 b(Doubleda)o(y)l(,)16
+b(1989.)187 1712 y([Sun91])25 b(Sun)16 b(Microsystems.)k Fa(manual)e(p)n
+(ages)p Fo(,)e(4.1)g(edition,)f(Jan)o(uary)i(1991.)186 1814
+y([T)l(an92])25 b(Andrew)16 b(S.)g(T)l(anen)o(baum.)22 b Fa(Mo)n(dern)17
+b(Op)n(er)n(ating)h(Systems)p Fo(.)k(Pren)o(tice-Hall,)14 b(Engle-)369
+1874 y(w)o(o)q(o)q(d)k(Cli\013s,)d(New)h(Jersey)l(,)f(1992.)182
+1976 y([Tho84])25 b(Ken)c(Thompson.)37 b(Re\015ections)20 b(on)i(T)l(rusting)
+g(T)l(rust.)37 b Fa(Communic)n(ations)22 b(of)g(the)369 2036
+y(A)o(CM)p Fo(,)15 b(27\(8\):761{3,)k(August)d(1984.)p eop
+%%Trailer
+end
+userdict /end-hook known{end-hook}if
+%%EOF
diff --git a/usr.sbin/named/doc/misc/style.txt b/usr.sbin/named/doc/misc/style.txt
new file mode 100644
index 00000000000..444dd64563f
--- /dev/null
+++ b/usr.sbin/named/doc/misc/style.txt
@@ -0,0 +1,172 @@
+Path: vixie!vixie
+From: vixie@vix.com (Paul A Vixie)
+Newsgroups: comp.protocols.tcp-ip.domains
+Subject: Re: Format of DNS files (style question)
+Date: 28 Aug 94 03:17:08
+Organization: Vixie Enterprises
+Lines: 159
+Distribution: inet
+Message-ID: <VIXIE.94Aug28031708@office.home.vix.com>
+References: <33onnr$i4u@zombie.ncsc.mil>
+NNTP-Posting-Host: office.home.vix.com
+In-reply-to: sjr@zombie.ncsc.mil's message of 27 Aug 1994 21:02:51 -0400
+
+> (Style) Suggestions for how to layout DNS configuration files (both
+> forward and reverse)?
+
+I've gone back and forth on the question of whether the BOG should include a
+section on this topic.  I know what I myself prefer, but I'm wary of ramming
+my own stylistic preferences down the throat of every BOG reader.  But since
+you ask :-)...
+
+Create /var/named.  If your system is too old to have a /var, either create
+one or use /usr/local/adm/named instead.  Put your named.boot in it, and make
+/etc/named.boot a symlink to it.  If your system doesn't have symlinks, you're
+S-O-L (but you knew that).  In named.boot, put a "directory" directive that
+specifies your actual BIND working directory:
+
+	directory	/var/named
+
+All relative pathnames used in "primary", "secondary", and "cache" directives
+will be evaluated relative to this directory.  Create two subdirectories,
+/var/named/pri and /var/named/sec.  Whenever you add a "primary" directive
+to your named.boot, use "pri/WHATEVER" as the path name.  And then put the
+primary zone file into "pri/WHATEVER".  Likewise when you add "secondary"
+directives, use "sec/WHATEVER" and BIND (really named-xfer) will create the
+files in that subdirectory.
+
+(Variations: (1) make a midlevel directory "zones" and put "pri" and "sec"
+into it; (2) if you tend to pick up a lot of secondaries from a few hosts,
+group them together in their own subdirectories -- something like
+/var/named/zones/uucp if you're a UUCP Project name server.)
+
+For your forward files, name them after the zone.  dec.com becomes
+"/var/named/zones/pri/dec.com".  For your reverse files, name them after the
+network number.  0.1.16.in-addr.arpa becomes "/var/named/zones/pri/16.1.0".
+
+When creating or maintaining primary zone files, try to use the same SOA
+values everywhere, except for the serial number which varies per zone.  Put
+a $ORIGIN directive at the top of the primary zone file, not because it's
+needed (it's not since the default origin is the zone named in the "primary"
+directive) but because it make it easier to remember what you're working on
+when you have a lot of primary zones.  Put some comments up there indicating
+contact information for the real owner if you're proxying.  Use RCS and put
+the "$Id: style.txt,v 1.1 1998/05/22 02:51:08 millert 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>
diff --git a/usr.sbin/named/doc/misc/vixie-security.ps b/usr.sbin/named/doc/misc/vixie-security.ps
new file mode 100644
index 00000000000..2cb8676bcb9
--- /dev/null
+++ b/usr.sbin/named/doc/misc/vixie-security.ps
@@ -0,0 +1,2915 @@
+%!PS-Adobe-3.0
+%%Creator: Basser Lout Version 3.01 (October 1994)
+%%CreationDate: Tue May  2 22:39:43 1995
+%%DocumentData: Binary
+%%DocumentNeededResources: (atend)
+%%DocumentSuppliedResources: (atend)
+%%Pages: (atend)
+%%BoundingBox: 0 0 612 792
+%%EndComments
+
+%%BeginProlog
+%%BeginResource: procset LoutStartUp
+/m { 3 1 roll moveto show } bind def
+/s { exch currentpoint exch pop moveto show } bind def
+/k { exch neg 0 rmoveto show } bind def
+/in { 1440 mul } def
+/cm { 567 mul } def
+/pt { 20 mul } def
+/em { 120 mul } def
+/sp { louts mul } def
+/vs { loutv mul } def
+/ft { loutf mul } def
+/dg {           } def
+
+/LoutGraphic {
+  /louts exch def
+  /loutv exch def
+  /loutf exch def
+  /ymark exch def
+  /xmark exch def
+  /ysize exch def
+  /xsize exch def
+} def
+
+/LoutFont
+{ findfont exch scalefont setfont
+} bind def
+
+/LoutRecode {
+  { findfont dup length dict begin
+    {1 index /FID ne {def} {pop pop} ifelse} forall
+    /Encoding exch def
+    currentdict end definefont pop
+  }
+  stopped {}
+} bind def
+
+/BeginEPSF {
+  /LoutEPSFState save def
+  /dict_count countdictstack def
+  /op_count count 1 sub def
+  userdict begin
+  /showpage { } def
+  0 setgray 0 setlinecap
+  1 setlinewidth 0 setlinejoin
+  10 setmiterlimit [] 0 setdash newpath
+  /languagelevel where
+  { pop languagelevel
+    1 ne
+    { false setstrokeadjust false setoverprint
+    } if
+  } if
+} bind def
+
+/EndEPSF {
+  count op_count sub { pop } repeat
+  countdictstack dict_count sub { end } repeat
+  LoutEPSFState restore
+} bind def
+%%EndResource
+
+%%BeginResource encoding vec1
+/vec1 [
+/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
+/.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 /asciicircum /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 /asciitilde /.notdef
+/.notdef /.notdef /.notdef /.notdef /.notdef /quotedblleft /quotedblright /fi
+/fl /endash /emdash /bullet /dagger /daggerdbl /florin /fraction
+/dotlessi /grave /acute /circumflex /tilde /macron /breve /dotaccent
+/dieresis /.notdef /ring /cedilla /.notdef /hungarumlaut /ogonek /caron
+/space /exclamdown /cent /sterling /currency /yen /brokenbar /section
+/dieresis /copyright /ordfeminine /guillemotleft /logicalnot /hyphen /registered /macron
+/degree /plusminus /twosuperior /threesuperior /acute /mu /paragraph /periodcentered
+/cedilla /onesuperior /ordmasculine /guillemotright /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
+%%EndResource
+
+%%BeginResource: procset LoutTabPrependGraphic
+% @PrependGraphic file /usr/local/share/lout/include/tab_prepend
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%                                                  %
+%  PostScript @SysPrependGraphic file for @Tab     %
+%                                                  %
+%  To assist in avoiding name clashes, the names   %
+%  of all these symbols begin with "ltab".         %
+%                                                  %
+%  Jeffrey H. Kingston                             %
+%  24 September 1991                               %
+%  22 December 1992                                %
+%                                                  %
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+% linewidth ltabhs -
+% horizontal single line
+/ltabhs
+{  0 0 moveto xsize 0 lineto
+   setlinewidth 0 setlinecap stroke
+} def
+
+% linewidth ltabhsp -
+% horizontal single line with projecting ends
+/ltabhsp
+{  0 0 moveto xsize 0 lineto
+   setlinewidth 2 setlinecap stroke
+} def
+
+% linewidth ltabhd -
+% horizontal double line
+/ltabhd
+{  dup dup
+   0 0 moveto xsize 0 lineto
+   0 exch 3 mul moveto xsize exch 3 mul lineto
+   setlinewidth 0 setlinecap stroke
+} def
+
+% linewidth ltabhdb -
+% horizontal double line below mark
+/ltabhdb
+{  dup dup
+   0 0 moveto xsize 0 lineto
+   0 exch -3 mul moveto xsize exch -3 mul lineto
+   setlinewidth 0 setlinecap stroke
+} def
+
+% linewidth ltabhdnw -
+% horizontal double line with northwest corner
+/ltabhdnw
+{  dup dup dup dup
+   0 0 moveto xsize 0 lineto
+   xsize exch 3 mul moveto
+   -3 mul exch 3 mul lineto
+   -3 mul 0 lineto
+   setlinewidth 0 setlinejoin 2 setlinecap stroke
+} def
+
+% linewidth ltabhdne -
+% horizontal double line with northeast corner
+/ltabhdne
+{  dup dup dup dup
+   0 0 moveto xsize 0 lineto
+   0 exch 3 mul moveto
+   3 mul xsize add exch 3 mul lineto
+   3 mul xsize add 0 lineto
+   setlinewidth 0 setlinejoin 2 setlinecap stroke
+} def
+
+% linewidth ltabhdsw -
+% horizontal double line with southwest corner
+/ltabhdsw
+{  dup dup dup dup
+   0 0 moveto xsize 0 lineto
+   xsize exch -3 mul moveto
+   -3 mul exch -3 mul lineto
+   -3 mul 0 lineto
+   setlinewidth 0 setlinejoin 2 setlinecap stroke
+} def
+
+% linewidth ltabhdse -
+% horizontal double line with southeast corner
+/ltabhdse
+{  dup dup dup dup
+   0 0 moveto xsize 0 lineto
+   0 exch -3 mul moveto
+   3 mul xsize add exch -3 mul lineto
+   3 mul xsize add 0 lineto
+   setlinewidth 0 setlinejoin 2 setlinecap stroke
+} def
+
+% linewidth ltabvs -
+% vertical single line
+/ltabvs
+{  0 0 moveto 0 ysize lineto
+   setlinewidth 0 setlinecap stroke
+} def
+
+% linewidth ltabvd -
+% vertical double line
+/ltabvd
+{  dup dup
+   0 0 moveto 0 ysize lineto
+   -3 mul 0 moveto -3 mul ysize lineto
+   setlinewidth 0 setlinecap stroke
+} def
+
+% linewidth ltabvdr -
+% vertical double line to right of mark
+/ltabvdr
+{  dup dup
+   0 0 moveto 0 ysize lineto
+   3 mul 0 moveto 3 mul ysize lineto
+   setlinewidth 0 setlinecap stroke
+} def
+%%EndResource
+
+%%BeginResource: procset LoutFigPrependGraphic
+% @PrependGraphic file /usr/local/share/lout/include/fig_prepend
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%                                                                    %
+%  PostScript @SysPrependGraphic file for @Fig  Jeffrey H. Kingston  %
+%  Version 2.0 (includes CIRCUM label)                 January 1992  %
+%                                                                    %
+%  To assist in avoiding name clashes, the names of all symbols      %
+%  defined here begin with "lfig".  However, this is not feasible    %
+%  with user-defined labels and some labels used by users.           %
+%                                                                    %
+%  <point>      is two numbers, a point.                             %
+%  <length>     is one number, a length                              %
+%  <angle>      is one number, an angle in degrees                   %
+%  <dashlength> is one number, the preferred length of a dash        %
+%                                                                    %
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+errordict begin
+   /handleerror
+   {
+      {  /Times-Roman findfont 8 pt scalefont setfont
+	 0 setgray 4 pt 4 pt moveto
+	 $error /errorname get
+	 dup lfigdict exch known
+	 { lfigdict exch get }
+	 { 30 string cvs } ifelse
+	 show
+	 (  Command: ) show
+	 $error /command get 30 string cvs show
+      } stopped {} if
+      showpage stop
+   } def
+end
+
+% concat strings: <string> <string> lfigconcat <string>
+% must be defined outside lfigdict since used in lfigpromotelabels
+/lfigconcat
+{ 2 copy length exch length add string
+  dup 0 4 index putinterval
+  dup 3 index length 3 index putinterval
+  3 1 roll pop pop
+} def
+
+% <string> lfigdebugprint -
+% must be defined outside lfigdict since used in arbitrary places
+% /lfigdebugprint
+% { print
+%   (;  operand stack:\n) print
+%   count copy
+%   count 2 idiv
+%   { ==
+%     (\n) print
+%   } repeat
+%   (\n) print
+% } def
+
+/lfigdict 120 dict def
+lfigdict begin
+
+% error messages
+/dictfull (dictfull error:  too many labels?) def
+/dictstackoverflow (dictstackoverflow error:  labels nested too deeply?) def
+/execstackoverflow (execstackoverflow error:  figure nested too deeply?) def
+/limitcheck (limitcheck error:  figure nested too deeply or too large?) def
+/syntaxerror (syntaxerror error:  syntax error in text of figure?) def
+/typecheck (typecheck error:  syntax error in text of figure?) def
+/undefined (undefined error:  unknown or misspelt label?) def
+/VMError (VMError error:  run out of memory?) def
+
+% push pi onto stack:  - lfigpi <num>
+/lfigpi 3.14159 def
+
+% arc directions
+/clockwise     false def
+/anticlockwise true  def
+
+% maximum of two numbers:  <num> <num> lfigmax <num>
+/lfigmax { 2 copy gt { pop } { exch pop } ifelse } def
+
+% minimum of two numbers:  <num> <num> lfigmin <num>
+/lfigmin { 2 copy lt { pop } { exch pop } ifelse } def
+
+% add two points:  <point> <point> lfigpadd <point>
+/lfigpadd { exch 3 1 roll add 3 1 roll add exch } def
+
+% subtract first point from second:  <point> <point> lfigpsub <point>
+/lfigpsub { 3 2 roll sub 3 1 roll exch sub exch } def
+
+% max two points:  <point> <point> lfigpmax <point>
+/lfigpmax { exch 3 1 roll lfigmax 3 1 roll lfigmax exch } def
+
+% min two points:  <point> <point> lfigpmin <point>
+/lfigpmin { exch 3 1 roll lfigmin 3 1 roll lfigmin exch } def
+
+% scalar multiplication: <point> <num> lfigpmul <point>
+/lfigpmul { dup 3 1 roll mul 3 1 roll mul exch } def
+
+% point at angle and distance:  <point> <length> <angle> lfigatangle <point>
+/lfigatangle { 2 copy cos mul 3 1 roll sin mul lfigpadd } def
+
+% angle from one point to another:  <point> <point> lfigangle <angle>
+/lfigangle { lfigpsub 2 copy 0 eq exch 0 eq and {pop} {exch atan} ifelse } def
+
+% distance between two points:  <point> <point> lfigdistance <length>
+/lfigdistance { lfigpsub dup mul exch dup mul add sqrt } def
+
+% difference in x coords: <point> <point> lfigxdistance <length>
+/lfigxdistance { pop 3 1 roll pop sub } def
+
+%difference in y coords: <point> <point> lfigydistance <length>
+/lfigydistance { 3 1 roll pop sub exch pop } def
+
+% stroke a solid line:  <length> <dashlength> lfigsolid -
+/lfigsolid
+{  pop pop [] 0 setdash stroke
+} def
+
+% stroke a lfigdashed line:   <length> <dashlength> lfigdashed -
+/lfigdashed
+{  2 copy div 2 le 1 index 0 le or
+   {  exch pop 1 pt lfigmax [ exch dup ] 0 setdash }
+   {  dup [ exch 4 2 roll 2 copy div
+      1 sub 2 div ceiling dup 4 1 roll
+      1 add mul sub exch div ] 0 setdash
+   } ifelse stroke
+} def
+
+% stroke a lfigcdashed line:  <length> <dashlength> lfigcdashed -
+/lfigcdashed
+{  2 copy le 1 index 0 le or
+   { exch pop 1 pt lfigmax [ exch dup ] dup 0 get 2 div setdash }
+   { dup [ 4 2 roll exch 2 copy exch div
+     2 div ceiling div 1 index sub
+     ] exch 2 div setdash
+   } ifelse stroke
+} def
+
+% stroke a dotted line:  <length> <dashlength> lfigdotted -
+/lfigdotted
+{  2 copy le 1 index 0 le or
+   { exch pop 1 pt lfigmax [ exch 0 exch ] 0 setdash }
+   { 1 index exch div ceiling div
+     [ 0 3 2 roll ] 0 setdash
+   } ifelse stroke
+} def
+
+% stroke a noline line:  <length> <dashlength> lfignoline -
+/lfignoline
+{ pop pop
+} def
+
+% painting (i.e. filling): - lfigwhite - (etc.)
+/lfignopaint		{			       } def
+/lfignochange		{ 			  fill } def
+/lfigdarkblue		{ 0.0 0.0 0.5 setrgbcolor fill } def
+/lfigblue		{ 0.0 0.0 1.0 setrgbcolor fill } def
+/lfiglightblue		{ 0.5 0.5 1.0 setrgbcolor fill } def
+/lfigdarkgreen		{ 0.0 0.5 0.0 setrgbcolor fill } def
+/lfiggreen		{ 0.0 1.0 0.0 setrgbcolor fill } def
+/lfiglightgreen		{ 0.5 1.0 0.5 setrgbcolor fill } def
+/lfigdarkred		{ 0.5 0.0 0.0 setrgbcolor fill } def
+/lfigred		{ 1.0 0.0 0.0 setrgbcolor fill } def
+/lfiglightred		{ 1.0 0.5 0.5 setrgbcolor fill } def
+/lfigdarkcyan		{ 0.0 0.5 0.5 setrgbcolor fill } def
+/lfigcyan		{ 0.0 1.0 1.0 setrgbcolor fill } def
+/lfiglightcyan		{ 0.5 1.0 1.0 setrgbcolor fill } def
+/lfigdarkmagenta	{ 0.5 0.0 0.5 setrgbcolor fill } def
+/lfigmagenta		{ 1.0 0.0 1.0 setrgbcolor fill } def
+/lfiglightmagenta	{ 1.0 0.5 1.0 setrgbcolor fill } def
+/lfigdarkyellow		{ 0.5 0.5 0.0 setrgbcolor fill } def
+/lfigyellow		{ 1.0 1.0 0.0 setrgbcolor fill } def
+/lfiglightyellow	{ 1.0 1.0 0.5 setrgbcolor fill } def
+/lfigdarkgray		{ 0.2 0.2 0.2 setrgbcolor fill } def
+/lfiggray		{ 0.5 0.5 0.5 setrgbcolor fill } def
+/lfiglightgray		{ 0.8 0.8 0.8 setrgbcolor fill } def
+/lfigdarkgrey		{ 0.2 0.2 0.2 setrgbcolor fill } def
+/lfiggrey		{ 0.5 0.5 0.5 setrgbcolor fill } def
+/lfiglightgrey		{ 0.8 0.8 0.8 setrgbcolor fill } def
+/lfigblack		{ 0.0 0.0 0.0 setrgbcolor fill } def
+/lfigwhite		{ 1.0 1.0 1.0 setrgbcolor fill } def
+
+% line caps (and joins, not currently used)
+/lfigbutt       0 def
+/lfiground      1 def
+/lfigprojecting 2 def
+/lfigmiter      0 def
+/lfigbevel      2 def
+
+% shape and labels of the @Box symbol
+/lfigbox
+{
+   0     0     /SW  lfigpointdef
+   xsize 0     /SE  lfigpointdef
+   xsize ysize /NE  lfigpointdef
+   0     ysize /NW  lfigpointdef
+   SE 0.5 lfigpmul /S   lfigpointdef
+   NW 0.5 lfigpmul /W   lfigpointdef
+   W SE lfigpadd   /E   lfigpointdef
+   S NW lfigpadd   /N   lfigpointdef
+   NE 0.5 lfigpmul /CTR lfigpointdef
+   [ CTR NE lfigpsub /lfigboxcircum cvx ] lfigcircumdef
+   SW SE NE NW SW
+} def
+
+% shape and labels of the @Square symbol
+/lfigsquare
+{
+   xsize ysize 0.5 lfigpmul /CTR lfigpointdef
+   CTR xsize xsize ysize ysize lfigpmax 0.5 lfigpmul lfigpadd /NE lfigpointdef
+   CTR 0 0 CTR NE lfigdistance 135 lfigatangle lfigpadd /NW lfigpointdef
+   CTR 0 0 CTR NE lfigdistance 225 lfigatangle lfigpadd /SW lfigpointdef
+   CTR 0 0 CTR NE lfigdistance 315 lfigatangle lfigpadd /SE lfigpointdef
+   SW 0.5 lfigpmul SE 0.5 lfigpmul lfigpadd /S lfigpointdef
+   NW 0.5 lfigpmul NE 0.5 lfigpmul lfigpadd /N lfigpointdef
+   SW 0.5 lfigpmul NW 0.5 lfigpmul lfigpadd /W lfigpointdef
+   SE 0.5 lfigpmul NE 0.5 lfigpmul lfigpadd /E lfigpointdef
+   [ CTR NE lfigpsub /lfigboxcircum cvx ] lfigcircumdef
+   SW SE NE NW SW
+} def
+
+% shape and labels of the @Diamond symbol
+/lfigdiamond
+{
+   xsize 0 0.5 lfigpmul /S   lfigpointdef
+   0 ysize 0.5 lfigpmul /W   lfigpointdef
+   S W         lfigpadd /CTR lfigpointdef
+   CTR W       lfigpadd /N   lfigpointdef
+   CTR S       lfigpadd /E   lfigpointdef
+   [ xsize ysize 0.5 lfigpmul /lfigdiamondcircum cvx ] lfigcircumdef
+   S E N W S
+} def
+
+% shape and labels of the @Ellipse symbol
+/lfigellipse
+{
+   xsize 0 0.5 lfigpmul /S   lfigpointdef
+   0 ysize 0.5 lfigpmul /W   lfigpointdef
+   S W         lfigpadd /CTR lfigpointdef
+   CTR W       lfigpadd /N   lfigpointdef
+   CTR S       lfigpadd /E   lfigpointdef
+   CTR xsize 0 0.3536 lfigpmul lfigpadd 0 ysize 0.3536 lfigpmul lfigpadd /NE lfigpointdef
+   0 ysize 0.3536 lfigpmul CTR xsize 0 0.3536 lfigpmul lfigpadd lfigpsub /SE lfigpointdef
+   xsize 0 0.3536 lfigpmul CTR lfigpsub 0 ysize 0.3536 lfigpmul lfigpadd /NW lfigpointdef
+   0 ysize 0.3536 lfigpmul xsize 0 0.3536 lfigpmul CTR lfigpsub lfigpsub /SW lfigpointdef
+   [ xsize ysize 0.5 lfigpmul /lfigellipsecircum cvx ] lfigcircumdef
+   S [ CTR ] E [ CTR ] N [ CTR ] W [ CTR ] S
+} def
+
+% shape and labels of the @Circle symbol
+/lfigcircle
+{
+   xsize ysize 0.5 lfigpmul /CTR lfigpointdef
+   CTR xsize 0 ysize 0 lfigpmax 0.5 lfigpmul lfigpadd /E lfigpointdef
+   CTR 0 0 CTR E lfigdistance 45 lfigatangle lfigpadd /NE lfigpointdef
+   CTR 0 0 CTR E lfigdistance 90 lfigatangle lfigpadd /N lfigpointdef
+   CTR 0 0 CTR E lfigdistance 135 lfigatangle lfigpadd /NW lfigpointdef
+   CTR 0 0 CTR E lfigdistance 180 lfigatangle lfigpadd /W lfigpointdef
+   CTR 0 0 CTR E lfigdistance 225 lfigatangle lfigpadd /SW lfigpointdef
+   CTR 0 0 CTR E lfigdistance 270 lfigatangle lfigpadd /S lfigpointdef
+   CTR 0 0 CTR E lfigdistance 315 lfigatangle lfigpadd /SE lfigpointdef
+   [ S E lfigpsub /lfigellipsecircum cvx ] lfigcircumdef
+   S [ CTR ] E [ CTR ] N [ CTR ] W [ CTR ] S
+} def
+
+% shape and labels of the @HLine and @HArrow symbols
+/lfighline
+{
+   0 ymark lfigprevious /FROM lfigpointdef
+   xsize ymark lfigprevious /TO lfigpointdef
+} def
+
+% shape and labels of the @VLine and @VArrow symbols
+/lfigvline
+{
+   xmark ysize lfigprevious /FROM lfigpointdef
+   xmark 0 lfigprevious /TO lfigpointdef
+} def
+
+% points of a polygon around base with given no of sides, vert init angle:
+% <sides> <angle> figpolygon <point> ... <point>
+/lfigpolygon
+{  xsize ysize 0.5 lfigpmul /CTR lfigpointdef
+   90 sub CTR 2 copy lfigmax 5 3 roll
+   [ 4 copy pop /lfigpolycircum cvx ] lfigcircumdef
+   exch dup 360 exch div exch
+   1 1  3 2 roll
+   {  4 string cvs (P) exch lfigconcat cvn
+      6 copy pop pop lfigatangle 2 copy 10 2 roll
+      3 2 roll lfigpointdef
+      dup 3 1 roll add exch
+   }  for
+   pop lfigatangle
+} def
+
+% next array element:  <array> <index> lfiggetnext <array> <index> <any> true
+%                                               or <array> <index> false
+/lfiggetnext
+{  2 copy exch length ge
+   { false }
+   { 2 copy get exch 1 add exch true } ifelse
+} def
+
+% check whether thing is number:  <any> lfigisnumbertype <any> <bool>
+/lfigisnumbertype
+{  dup type dup
+   /integertype eq exch /realtype eq or
+} def
+
+% check whether thing is an array:  <any> lfigisarraytype <any> <bool>
+/lfigisarraytype { dup type /arraytype eq } def
+
+% get next item:  <array> <index> lfiggetnextitem <array> <index> 0
+%                                              or <array> <index> <array> 1
+%                                              or <array> <index> <point> 2
+/lfiggetnextitem
+{   lfiggetnext
+    {	lfigisarraytype
+	{   1
+	}
+	{   lfigisnumbertype
+	    {	3 1 roll
+		lfiggetnext
+		{   lfigisnumbertype
+		    {	4 3 roll exch  2
+		    }
+		    {	pop 3 2 roll pop  0
+		    } ifelse
+		}
+		{   3 2 roll pop  0
+		} ifelse
+	    }
+	    {	pop 0
+	    } ifelse
+	} ifelse
+    }
+    {	0
+    } ifelse
+} def
+
+% set arc path:  bool x1 y1  x2 y2  x0 y0  lfigsetarc  <angle> <angle> <dist>
+% the path goes from x1 y1 to x2 y2 about centre x0 y0,
+% anticlockwise if bool is true else clockwise.
+% The orientations of backwards pointing and forwards pointing
+% arrowheads are returned in the two angles, and
+% the length of the arc is returned in <dist>.
+/lfigsetarc
+{
+  20 dict begin
+     matrix currentmatrix 8 1 roll
+     2 copy translate 2 copy 8 2 roll
+     4 2 roll lfigpsub 6 2 roll lfigpsub
+     dup /y1 exch def dup mul /y1s exch def
+     dup /x1 exch def dup mul /x1s exch def
+     dup /y2 exch def dup mul /y2s exch def
+     dup /x2 exch def dup mul /x2s exch def
+
+     y1s y2s eq
+     {	-1
+     }
+     {	y1s x2s mul y2s x1s mul sub y1s y2s sub div
+     } ifelse
+     /da exch def
+
+     x1s x2s eq
+     {	-1
+     }
+     {	x1s y2s mul x2s y1s mul sub x1s x2s sub div
+     } ifelse
+     /db exch def
+
+     da 0 gt db 0 gt and
+     {	/LMax da sqrt db sqrt lfigmax def
+	/scalex da sqrt LMax div def
+	/scaley db sqrt LMax div def
+	scalex scaley scale
+	0 0 LMax
+	0 0 x1 scalex mul y1 scaley mul lfigangle
+	0 0 x2 scalex mul y2 scaley mul lfigangle
+	2 copy eq { 360 add } if
+	2 copy 8 2 roll
+	5 index { arc } { arcn } ifelse
+	2 index 1 index
+	{ 90 sub } { 90 add } ifelse
+	dup sin scaley mul exch cos scalex mul atan
+	2 index 2 index
+	{ 90 add } { 90 sub } ifelse
+	dup sin scaley mul exch cos scalex mul atan
+	5 2 roll  % res1 res2 ang1 ang2 anticlockwise
+	{ exch sub } { sub } ifelse
+	dup 0 le { 360 add } if  lfigpi mul LMax mul 180 div
+     }
+     {	0 0 x1 y1 lfigdistance 0 0 x2 y2 lfigdistance eq
+	0 0 x1 y1 lfigdistance 0 gt and
+	{	0 0
+		0 0 x1 y1 lfigdistance
+		0 0 x1 y1 lfigangle
+		0 0 x2 y2 lfigangle
+		2 copy eq { 360 add } if
+		2 copy 8 2 roll
+		5 index { arc } { arcn } ifelse
+		2 index 1 index
+		{ 90 sub } { 90 add } ifelse
+		2 index 2 index
+		{ 90 add } { 90 sub } ifelse
+		5 2 roll % res1 res2 ang1 ang2 clockwise
+		{ exch sub } { sub } ifelse
+		dup 0 le { 360 add } if lfigpi mul 0 0 x1 y1 lfigdistance mul 180 div
+	}
+	{	x2 y2 lineto pop
+		x2 y2 x1 y1 lfigangle
+		x1 y1 x2 y2 lfigangle
+		x1 y1 x2 y2 lfigdistance
+	} ifelse
+     } ifelse
+     4 -1 roll setmatrix
+   end
+} def
+
+% lfigsetcurve: set up a Bezier curve from x0 y0 to x3 y3
+% and return arrowhead angles and length of curve (actually 0)
+% x0 y0 x1 y1 x2 y2 x3 y3 lfigsetcurve <angle> <angle> <length>
+/lfigsetcurve
+{ 8 copy curveto pop pop
+  lfigangle
+  5 1 roll
+  4 2 roll lfigangle
+  exch
+  0
+} def
+
+% lfigpaintpath: paint a path of the given shape
+% /paint [ shape ] lfigpaintpath -
+/lfigpaintpath
+{
+  10 dict begin
+    0 newpath
+    /prevseen false def
+    /curveseen false def
+    { lfiggetnextitem
+      dup 0 eq { pop exit }
+      { 1 eq
+        { /curveseen true def
+	  /curve exch def
+	  curve length 0 eq { /curveseen false def } if
+        }
+        { /ycurr exch def
+	  /xcurr exch def
+	  prevseen
+	  { curveseen
+	    { curve length 4 eq
+	      { xprev yprev
+		curve 0 get curve 1 get
+		curve 2 get curve 3 get
+		xcurr ycurr
+		lfigsetcurve pop pop pop
+	      }
+	      { xprev yprev xcurr ycurr
+	        curve length 1 ge { curve 0 get } { 0 } ifelse
+	        curve length 2 ge { curve 1 get } { 0 } ifelse
+	        curve length 3 ge { curve 2 get } { true } ifelse
+	        7 1 roll
+	        lfigsetarc pop pop pop
+	      } ifelse
+	    }
+	    { xcurr ycurr lineto
+	    } ifelse
+	  }
+	  { xcurr ycurr moveto
+	  } ifelse
+	  /xprev xcurr def
+	  /yprev ycurr def
+	  /prevseen true def
+	  /curveseen false def
+        } ifelse
+      } ifelse
+    } loop pop pop cvx exec
+  end
+} def
+
+% stroke a path of the given shape in the given linestyle and dash length.
+% Return the origin and angle of the backward and forward arrow heads.
+% dashlength /linestyle [shape] lfigdopath  [<point> <angle>] [<point> <angle>] 
+/lfigdopath
+{
+  10 dict begin
+    0
+    /prevseen  false def
+    /curveseen false def
+    /backarrow []    def
+    /fwdarrow  []    def
+    {
+	lfiggetnextitem
+	dup 0 eq { pop exit }
+	{
+	    1 eq
+	    {	/curveseen true def
+		/curve exch def
+		curve length 0 eq { /prevseen false def } if
+	    }
+	    {	/ycurr exch def
+		/xcurr exch def
+		prevseen
+		{   newpath xprev yprev moveto
+		    curveseen
+		    {	curve length 4 eq
+			{   xprev yprev
+			    curve 0 get curve 1 get
+			    curve 2 get curve 3 get
+			    xcurr ycurr lfigsetcurve
+			}
+			{   xprev yprev xcurr ycurr
+			    curve length 1 ge { curve 0 get } { 0 } ifelse
+			    curve length 2 ge { curve 1 get } { 0 } ifelse
+			    curve length 3 ge { curve 2 get } { true } ifelse
+			    7 1 roll
+			    lfigsetarc
+			} ifelse
+		    }
+		    {	xcurr ycurr lineto
+			xcurr ycurr xprev yprev lfigangle dup 180 sub
+			xprev yprev xcurr ycurr lfigdistance
+		    } ifelse
+		    6 index 6 index cvx exec
+		    [ xprev yprev 5 -1 roll ]
+		    backarrow length 0 eq
+		    { /backarrow exch def }
+		    { pop } ifelse
+		    [ xcurr ycurr 4 -1 roll ] /fwdarrow exch def
+		} if
+		/xprev xcurr def
+		/yprev ycurr def
+		/prevseen true def
+		/curveseen false def
+	    } ifelse
+	} ifelse
+    } loop
+    pop pop pop pop
+    backarrow length 0 eq { [ 0 0 0 ] } { backarrow } ifelse
+    fwdarrow  length 0 eq { [ 0 0 0 ] } { fwdarrow  } ifelse
+  end
+} def
+
+% lfigdoarrow: draw an arrow head of given form
+% dashlength /lstyle /pstyle hfrac height width [ <point> <angle> ] lfigdoarrow -
+/lfigdoarrow
+{  matrix currentmatrix 8 1 roll
+   dup 0 get 1 index 1 get translate
+   2 get rotate
+   [ 2 index neg 2 index 0 0
+     3 index 3 index neg
+     1 index 10 index mul 0
+     7 index 7 index ]
+   4 1 roll pop pop pop
+   dup 3 1 roll
+   gsave lfigpaintpath grestore lfigdopath pop pop
+   setmatrix
+} def
+
+% arrow head styles
+/lfigopen     0.0 def
+/lfighalfopen 0.5 def
+/lfigclosed   1.0 def
+
+% stroke no arrows, forward, back, and both
+/lfignoarrow { pop pop pop pop pop pop pop pop                        } def
+/lfigforward { 7 -1 roll lfigdoarrow pop                              } def
+/lfigback    { 8 -2 roll pop lfigdoarrow                              } def
+/lfigboth    { 8 -1 roll 7 copy lfigdoarrow pop 7 -1 roll lfigdoarrow } def
+
+% lfigprevious: return previous point on path
+/lfigprevious
+{ lfigisnumbertype
+  { 2 copy }
+  { lfigisarraytype
+    { 2 index 2 index }
+    { 0 0 }
+    ifelse
+  } ifelse
+} def
+
+% label a point in 2nd top dictionary:  <point> /name lfigpointdef -
+/lfigpointdef
+{
+  % (Entering lfigpointdef) lfigdebugprint
+  [ 4 2 roll transform
+    /itransform cvx ] cvx
+    currentdict end
+    3 1 roll
+    % currentdict length currentdict maxlength lt
+    % { def }
+    % { exec moveto (too many labels) show stop }
+    % ifelse
+    def
+    begin
+  % (Leaving lfigpointdef) lfigdebugprint
+} def
+
+% promote labels from second top to third top dictionary
+% <string> lfigpromotelabels -
+/lfigpromotelabels
+{
+  % (Entering lfigpromotelabels) lfigdebugprint
+  currentdict end exch currentdict end
+  { exch 20 string cvs 2 index
+    (@) lfigconcat exch lfigconcat cvn exch def
+  } forall pop begin
+  % (Leaving lfigpromotelabels) lfigdebugprint
+} def
+
+% show labels (except CIRCUM): - lfigshowlabels -
+/lfigshowlabels
+{
+  % (Entering lfigshowlabels) lfigdebugprint
+  currentdict end
+    currentdict
+    { 1 index 20 string cvs (CIRCUM) search % if CIRCUM in key
+      { pop pop pop pop pop }
+      { pop cvx exec 2 copy
+        newpath 1.5 pt 0 360 arc
+        0 setgray fill
+        /Times-Roman findfont 8 pt scalefont setfont
+        moveto 0.2 cm 0.1 cm rmoveto 20 string cvs show
+      }
+      ifelse
+    } forall
+  begin
+  % (Leaving lfigshowlabels) lfigdebugprint
+} def
+
+% fix an angle to between 0 and 360 degrees:  <angle> lfigfixangle <angle>
+/lfigfixangle
+{
+  % (Entering lfigfixangle) lfigdebugprint
+  { dup 0 ge { exit } if
+    360 add
+  } loop
+  { dup 360 lt { exit } if
+    360 sub
+  } loop
+  % (Leaving lfigfixangle) lfigdebugprint
+} def
+
+% find point on circumference of box:  alpha a b lfigboxcircum x y
+/lfigboxcircum
+{
+  % (Entering lfigboxcircum) lfigdebugprint
+  4 dict begin
+    /b exch def
+    /a exch def
+    lfigfixangle /alpha exch def
+    0 0 a b lfigangle /theta exch def
+
+    % if alpha <= theta, return (a, a*tan(alpha))
+    alpha theta le
+    { a  a alpha sin mul alpha cos div }
+    {
+      % else if alpha <= 180 - theta, return (b*cot(alpha), b)
+      alpha 180 theta sub le
+      { b alpha cos mul alpha sin div  b }
+      {
+        % else if alpha <= 180 + theta, return (-a, -a*tan(alpha))
+        alpha 180 theta add le
+        { a neg  a neg alpha sin mul alpha cos div }
+        {
+	  % else if alpha <= 360 - theta, return (-b*cot(alpha), -b)
+	  alpha 360 theta sub le
+          { b neg alpha cos mul alpha sin div  b neg }
+	  {
+	    % else 360 - theta <= alpha, return (a, a*tan(alpha))
+	    a  a alpha sin mul alpha cos div
+	  } ifelse
+        } ifelse
+      } ifelse
+    } ifelse
+  end
+  % (Leaving lfigboxcircum) lfigdebugprint
+} def
+
+% find point on circumference of diamond:  alpha a b lfigdiamondcircum x y
+/lfigdiamondcircum
+{
+  % (Entering lfigdiamondcircum) lfigdebugprint
+  4 dict begin
+    /b exch def
+    /a exch def
+    lfigfixangle /alpha exch def
+    b alpha cos abs mul  a alpha sin abs mul  add  /denom exch def
+    a b mul alpha cos mul denom div
+    a b mul alpha sin mul denom div
+  end
+  % (Leaving lfigdiamondcircum) lfigdebugprint
+} def
+
+% find point on circumference of ellipse:  alpha a b lfigellipsecircum x y
+/lfigellipsecircum
+{
+  % (Entering lfigellipsecircum) lfigdebugprint
+  4 dict begin
+    /b exch def
+    /a exch def
+    lfigfixangle /alpha exch def
+    b alpha cos mul dup mul  a alpha sin mul dup mul  add sqrt /denom exch def
+    a b mul alpha cos mul denom div
+    a b mul alpha sin mul denom div
+  end
+  % (Leaving lfigellipsecircum) lfigdebugprint
+} def
+
+% find point of intersection of two lines each defined by two points
+% x1 y1 x2 y2  x3 y3 x4 y4  lfiglineintersect x y
+/lfiglineintersect
+{
+  % (Entering lfiglineintersect) lfigdebugprint
+  13 dict begin
+    /y4 exch def
+    /x4 exch def
+    /y3 exch def
+    /x3 exch def
+    /y2 exch def
+    /x2 exch def
+    /y1 exch def
+    /x1 exch def
+    x2 x1 sub /x21 exch def
+    x4 x3 sub /x43 exch def
+    y2 y1 sub /y21 exch def
+    y4 y3 sub /y43 exch def
+    y21 x43 mul y43 x21 mul sub /det exch def
+  
+    % calculate x 
+    y21 x43 mul x1 mul
+    y43 x21 mul x3 mul sub
+    y3 y1 sub x21 mul x43 mul add
+    det div
+
+    % calculate y
+    x21 y43 mul y1 mul
+    x43 y21 mul y3 mul sub
+    x3 x1 sub y21 mul y43 mul add
+    det neg div
+
+  end
+  % (Leaving lfiglineintersect) lfigdebugprint
+} def
+
+% find point on circumference of polygon
+% alpha radius num theta lfigpolycircum x y
+/lfigpolycircum
+{
+  % (Entering lfigpolycircum) lfigdebugprint
+  13 dict begin
+    /theta exch def
+    /num exch def
+    /radius exch def
+    /alpha exch def
+
+    % calculate delta, the angle from theta to alpha
+    alpha theta sub lfigfixangle
+
+    % calculate the angle which is the multiple of 360/num closest to delta
+    360 num div div truncate 360 num div mul theta add /anglea exch def
+
+    % calculate the next multiple of 360/num after anglea
+    anglea 360 num div add /angleb exch def
+
+    % intersect the line through these two points with the alpha line
+    anglea cos anglea sin  angleb cos angleb sin
+    0 0  alpha cos 2 mul alpha sin 2 mul
+    lfiglineintersect radius lfigpmul
+
+  end
+  % (Leaving lfigpolycircum) lfigdebugprint
+} def
+
+% add CIRCUM operator with this body:  <array> lfigcircumdef -
+/lfigcircumdef
+{   % (Entering lfigcircumdef) lfigdebugprint
+    /CIRCUM exch cvx
+    currentdict end
+    3 1 roll
+    % currentdict length currentdict maxlength lt
+    % { def }
+    % { exec moveto (too many labels) show stop }
+    % ifelse
+    def
+    begin
+    % (Leaving lfigcircumdef) lfigdebugprint
+} def
+
+end
+%%EndResource
+
+%%EndProlog
+
+%%BeginSetup
+%%IncludeResource: font Times-Italic
+/Times-Italicfnt83 vec1 /Times-Italic LoutRecode
+/fnt83 { /Times-Italicfnt83 LoutFont } def
+%%IncludeResource: font Times-Bold
+/Times-Boldfnt84 vec1 /Times-Bold LoutRecode
+/fnt84 { /Times-Boldfnt84 LoutFont } def
+%%IncludeResource: font Times-Roman
+/Times-Romanfnt82 vec1 /Times-Roman LoutRecode
+/fnt82 { /Times-Romanfnt82 LoutFont } def
+%%EndSetup
+
+%%Page: ? 1
+%%BeginPageSetup
+%%PageResources: font Times-Italic
+%%+ font Times-Bold
+%%+ font Times-Roman
+/pgsave save def
+0.0500 dup scale 10 setlinewidth
+%%EndPageSetup
+
+gsave
+0 15840 translate
+0.0000 rotate
+
+grestore
+gsave
+0 15840 translate
+0.0000 rotate
+200 fnt83 0.0 0.0 0.0 setrgbcolor 3005 -1576(Originally)m 3884(published)s 4709(in)s
+4914(the)s 5207(pr)s 9(oceedings)k 6221(of)s 6426(the)s
+6719(5th)s 7024(Usenix)s 7626(Security)s 8327(Symposium)s 224 fnt84
+4401 -3032(DNS)m 280 fnt84 4917 -3034(and)m 224 fnt84 5437 -3032(BIND)m
+280 fnt84 6065 -3034(Security)m 7127(Issues)s 240 fnt82 5620 -3494(P)m 3(aul)k
+6102(V)s 14(ixie)k 5279 -3734(<paul@vix.com>)m 240 fnt83 4695 -4067(Internet)m
+5511(Softwar)s 8(e)k 6414(Consortium)s 200 fnt82 5619 -4494(2)m
+5769(May)s 13(,)k 6221(1995)s 200 fnt84 5750 -5395(Abstract)m
+200 fnt82 2160 -5773(Ef)m 5(forts)k 2757(are)s 3049(underw)s 2(ay)k
+3883(to)s 4088(add)s 4426(security)s 5105(to)s 5310(the)s
+160 fnt82 5603 -5771(DNS)m 200 fnt82 5971 -5773(protocol.)m 6785(W)s 16(e)k
+7095(ha)s 4(v)k 3(e)k 7514(observ)s 3(ed)k
+8280(that)s 8628(if)s 160 fnt82 8799 -5771(BIND)m 200 fnt82
+9238 -5773(w)m 2(ould)k 9785(just)s 2160 -6013(do)m 2400(what)s
+2827(the)s 160 fnt82 3110 -6011(DNS)m 200 fnt82 3468 -6013(speci\207cations)m
+4590(say)s 4895(it)s 5045(should)s 5617(do,)s 5907(stop)s
+6279(crashing,)s 7043(and)s 7371(start)s 7752(checking)s 8511(its)s
+8738(inputs,)s 9315(then)s 9698(most)s 2160 -6253(of)m 2382(the)s
+2681(e)s 3(xisting)k 3364(security)s 4049(holes)s 4525(in)s
+160 fnt82 4736 -6251(DNS)m 200 fnt83 5110 -6252(as)m 5343(pr)s 3(acticed)k
+200 fnt82 6147 -6253(w)m 2(ould)k 6700(go)s 6956(a)s 3(w)k 2(ay)k 13(.)k
+7514(T)s 16(o)k 7776(be)s 8020(sure,)s 8457(attack)s 2(ers)k
+9216(w)s 2(ould)k 9769(still)s 2160 -6493(ha)m 4(v)k 3(e)k
+2588(a)s 2735(pretty)s 3258(easy)s 3670(time)s 4082(co-opting)s
+160 fnt82 4905 -6491(DNS)m 200 fnt82 5282 -6493(in)m 5496(their)s
+5919(break-in)s 6641(attempts.)s 7473(Our)s 7842(aim)s 8199(has)s
+8523(been)s 8958(to)s 9172(get)s 160 fnt82 9474 -6491(BIND)m
+200 fnt82 9922 -6493(to)m 2160 -6733(the)m 2459(point)s 2925(where)s
+3467(its)s 3710(only)s 4121(vulnerabilities)s 5314(are)s 5612(due)s
+5956(to)s 6167(the)s 160 fnt82 6466 -6731(DNS)m 200 fnt82
+6840 -6733(protocol,)m 7610(and)s 7954(not)s 8265(to)s 8476(the)s
+8775(implementation.)s 2160 -6973(This)m 2564(paper)s 3056(describes)s 3845(our)s
+4161(progress)s 4885(to)s 5090(date.)s 240 fnt84 1440 -7606(1.)m
+1740(Intr)s 4(oduction)k 200 fnt82 1440 -7985(Man)m 3(y)k
+1949(were)s 2382(the)s 2672(reasons)s 3315(for)s 3594(starting)s
+4237(w)s 2(ork)k 4692(on)s 160 fnt82 4939 -7983(BIND)m
+200 fnt82 5375 -7985(ag)m 1(ain)k 5852(a)s 1440 -8225(fe)m 5(w)k
+1784(years)s 2254(back.)s 2731(The)s 160 fnt82 3092 -8223(BIND)m
+200 fnt82 3532 -8225(serv)m 3(er)k 4065(and)s 4404(resolv)s 3(er)k
+5092(are)s 5385(critical)s 1440 -8465(to)m 1630(the)s 1908(daily)s
+2341(acti)s 5(vities)k 3087(of)s 3288(millions)s 3975(of)s
+4176(Internet)s 4829(users,)s 5322(yet)s 5600(the)s 3(y)k
+1440 -8705(ha)m 4(v)k 3(e)k 1861(each)s 2277(been)s
+2705(infested)s 3386(with)s 3792(b)s 4(ugs)k 4217(from)s
+4656(their)s 5072(\207rst)s 5433(day)s 5773(of)s 1440 -8945(use.)m
+1853(W)s 16(e)k 2161(ha)s 4(v)k 3(e)k
+2578(made)s 3057(some)s 3525(good)s 3973(progress)s 4695(on)s
+4943(plugging)s 5701(the)s 1440 -9185(memory)m 2169(leaks)s 2642(and)s
+2995(core)s 3402(dumps)s 3999(that)s 160 fnt82 4362 -9183(BIND)m
+200 fnt82 4816 -9185(is)m 5013(f)s 2(amous)k 5662(for)s 8(,)k
+1440 -9425(and)m 1784(along)s 2283(the)s 2582(w)s 2(ay)k
+2968(we)s 3256(ha)s 4(v)k 3(e)k 3681(found)s
+4203(a)s 4347(lot)s 4613(of)s 4835(w)s 2(ays)k
+5298(to)s 5509(mak)s 2(e)k 160 fnt82 1440 -9663(BIND)m
+200 fnt82 1879 -9665(more)m 2338(secure.)s 1840 -9976(Man)m 3(y)k
+2355(of)s 2574(the)s 2870(classic)s 3451(security)s 4133(breaches)s
+4881(in)s 5089(the)s 5385(history)s 1440 -10216(of)m 1674(computers)s
+2571(and)s 2927(computer)s 3747(netw)s 2(orking)k 4721(ha)s 4(v)k 3(e)k
+5158(had)s 5514(to)s 5737(do)s 1440 -10456(not)m 1770(with)s
+2199(fundamental)s 3269(algorythm)s 4163(or)s 4404(protocol)s 5143(\210a)s 3(ws,)k
+5685(b)s 4(ut)k 1440 -10696(with)m 1834(implementation)s 3123(errors.)s
+3726(Sometimes)s 4650(those)s 5110(errors)s 5613(tak)s 2(e)k
+1440 -10936(the)m 1721(form)s 2146(of)s 2350(ignorant)s 3052(or)s
+3256(\205security)s 4011(una)s 3(w)k 2(are\206)k 4806(programming,)s
+1440 -11176(such)m 1855(as)s 2070(collecting)s 2904(potentially)s 3805(unbounded)s
+4743(streams)s 5399(of)s 5615(data)s 1440 -11416(from)m 1910(the)s
+2236(netw)s 2(ork)k 2970(using)s 3485(functions)s 4309(which)s
+4879(do)s 5162(not)s 5500(kno)s 5(w)k 1440 -11656(the)m
+1784(length)s 2383(of)s 2650(their)s 3115(destination)s 4089(b)s 4(uf)k 5(fers,)k
+4794(or)s 5061(the)s 5405(use)s 5771(of)s 1440 -11896(predictable)m
+2391(magic)s 2945(cookies)s 3621(since)s 4097(the)s 4408(programmer')s 11(s)k
+5592(goal)s 1440 -12136(is)m 1618(to)s 1819(pre)s 5(v)k 3(ent)k
+2454(accidental)s 3305(data)s 3682(errors)s 4191(rather)s 4700(than)s
+5089(intentional)s 1440 -12376(ones.)m 1950(Other)s 2448(times,)s 2973(a)s
+3106(code)s 3527(branch)s 4114(rarely)s 4622(or)s 4833(ne)s 5(v)k 3(er)k
+5312(tak)s 2(en)k 5786(in)s 1440 -12616(normal)m 2053(use)s
+2367(is)s 2548(found)s 3063(to)s 3267(ha)s 4(v)k 3(e)k
+3685(\205security)s 4451(f)s 2(atal\206)k 4938(b)s 4(ugs)k
+5360(or)s 5575(e)s 5(v)k 3(en)k 1440 -12856(deliberate)m
+2273(back)s 2699(doors)s 3192(or)s 3408(loopholes.)s 1840 -13167(While)m
+2407(we)s 2720(do)s 3001(not)s 3337(intend)s 3916(to)s
+4152(demean)s 4852(the)s 5176(ef)s 5(forts)k 5770(of)s
+1440 -13407(those)m 1956(in)s 8(v)k 4(olv)k 3(ed)k
+2735(in)s 2986(upgrading)s 3891(the)s 4230(Internet)s 4944(protocols)s
+5781(to)s 1440 -13647(mak)m 2(e)k 1945(security)s 2650(a)s
+2814(more)s 3299(realistic)s 4002(goal,)s 4471(we)s 4779(ha)s 4(v)k 3(e)k
+5224(observ)s 3(ed)k 1440 -13887(that)m 1813(if)s 160 fnt82
+2009 -13885(BIND)m 200 fnt82 2473 -13887(w)m 2(ould)k 3045(just)s
+3407(do)s 3682(what)s 4144(the)s 160 fnt82 4462 -13885(DNS)m
+200 fnt82 4855 -13887(speci\207cations)m 1440 -14127(say)m 1788(it)s 1981(should)s
+2596(do,)s 2929(stop)s 3344(crashing,)s 4151(and)s 4522(start)s
+4946(checking)s 5748(its)s 6300 -7577(inputs,)m 6887(then)s 7280(most)s
+7717(of)s 7933(the)s 8226(e)s 3(xisting)k 8903(security)s
+9582(holes)s 10052(in)s 160 fnt82 10257 -7575(DNS)m 200 fnt83
+10625 -7576(as)m 6300 -7816(pr)m 3(acticed)k 200 fnt82 7120 -7817(w)m 2(ould)k
+7689(go)s 7961(a)s 3(w)k 2(ay)k 13(.)k
+8535(T)s 16(o)k 8813(be)s 9073(sure,)s 9526(attack)s 2(ers)k
+10301(w)s 2(ould)k 6300 -8057(still)m 6705(ha)s 4(v)k 3(e)k
+7182(a)s 7378(pretty)s 7950(easy)s 8411(time)s 8872(co-opting)s
+160 fnt82 9744 -8055(DNS)m 200 fnt82 10170 -8057(in)m 10433(their)s
+6300 -8297(break-in)m 7026(attempts.)s 7862(Our)s 8235(aim)s 8596(has)s
+8924(been)s 9363(to)s 9581(get)s 160 fnt82 9887 -8295(BIND)m
+200 fnt82 10339 -8297(to)m 10557(the)s 6300 -8537(point)m 6785(where)s
+7346(its)s 7608(only)s 8038(vulnerabilities)s 9250(are)s 9567(due)s
+9930(to)s 10160(the)s 160 fnt82 10478 -8535(DNS)m 200 fnt82
+6300 -8777(protocol,)m 7064(and)s 7402(not)s 7707(to)s 7912(the)s
+8205(implementation.)s 240 fnt84 6300 -9465(2.)m 6600(Wh)s 3(y)k
+7150(Is)s 192 fnt84 7396 -9463(DNS)m 240 fnt84 7838 -9465(Security)m
+8747(Important?)s 200 fnt82 6300 -9890(Let')m 11(s)k 6778(say)s
+7124(that)s 7503(a)s 7672(security)s 8382(conscious)s 9248(user)s
+9660(al)s 2(w)k 2(ays)k 10289(uses)s 10712(a)s
+160 fnt82 6300 -10128(DES)m 200 fnt82 6650 -10130(challenge/response)m 8213(de)s 5(vice)k
+8777(when)s 9259(connecting)s 10183(to)s 10388(hosts)s 6300 -10370(outside)m
+6940(the)s 7248(local)s 7699(netw)s 2(ork,)k 8465(b)s 4(ut)k
+8781(when)s 9278(connecting)s 10217(locally)s 13(,)k 6300 -10610(she)m
+6635(\207gures)s 7247(that)s 7615(it)s 7795(is)s 7997(safe)s
+8386(to)s 8611(send)s 9046(her)s 9370(passw)s 2(ord)k
+10190(in)s 10415(clear)s 6300 -10850(te)m 3(xt)k 6660(since)s
+7133(she)s 7463(kno)s 5(ws)k 128 fnt82 7979 -10761(1)m
+200 fnt82 8108 -10850(that)m 8471(outsiders)s 9254(cannot)s 9850(snif)s 5(f)k
+10274(on)s 10539(her)s 6300 -11090(pri)m 5(v)k 5(ate)k
+6906(netw)s 2(ork.)k 7721(Further)s 8371(assume)s 9020(that)s
+9382(hers)s 9777(is)s 9973(one)s 10325(of)s 10555(the)s
+6300 -11330(man)m 3(y)k 6796(installations)s 7812(which)s 8355(does)s
+8776(not)s 9087(restrict)s 9693(outbound)s 160 fnt82 10504 -11328(TCP)m
+200 fnt82 6300 -11570(connections,)m 7383(on)s 7665(the)s 7990(assumption)s
+8979(that)s 9359(\207re)s 5(w)k 2(alls)k 10118(are)s
+10442(only)s 6300 -11810(necessary)m 7121(to)s 7325(k)s 2(eep)k
+7748(people)s 200 fnt83 8328 -11809(out)m 128 fnt82 8583 -11721(2)m
+200 fnt82 8647 -11810(.)m 8796(If)s 8977(her)s 9280(name)s
+9760(serv)s 3(er)k 10291(is)s 10472(able)s 6300 -12050(to)m
+6509(recei)s 5(v)k 3(e)k 160 fnt82 7128 -12048(UDP)m
+200 fnt82 7500 -12050(pack)m 2(ets)k 8148(on)s 8402(port)s
+8777(53)s 9031(from)s 9472(outside)s 10101(her)s 10409(local)s
+6300 -12290(netw)m 2(ork,)k 7091(then)s 7524(this)s 7901(security)s
+8620(conscious)s 9495(user)s 9916(is)s 10138(in)s 10383(for)s
+10705(a)s 6300 -12530(potentially)m 7201(rough)s 7717(ride.)s 6700 -12841(Before)m
+7318(we)s 7627(be)s 3(gin,)k 8194(we')s 10(d)k
+8659(lik)s 2(e)k 9032(to)s 9264(emphasize)s 10180(that)s
+10555(the)s 6300 -13081(e)m 3(xamples)k 7145(are)s 7484(not)s
+7836(dra)s 3(wn)k 8428(from)s 8912(theoretical)s 9847(studies,)s
+10546(b)s 4(ut)k 6300 -13321(rather)m 6813(the)s 200 fnt84
+7106 -13322(tcpdump)m 200 fnt82 7920 -13321(command)m 8756(running)s 9427(on)s
+9677(real)s 10024(netw)s 2(orks.)k gsave
+6300 -13861 translate
+200 fnt82 0.0 0.0 0.0 setrgbcolor 1134 0 0 0 200 240 50 LoutGraphic
+gsave
+0 0 moveto xsize 0 lineto stroke
+grestore
+
+grestore
+102 fnt82 0.0 0.0 0.0 setrgbcolor
+6300 -14042(1)m 160 fnt82 6351 -14113(W)m 12(e')k 1(ll)k
+6741(assume)s 7251(that)s 7530(she)s 7783(is)s 7929(correct.)s
+102 fnt82 6300 -14295(2)m 160 fnt82 6351 -14366(An)m 6586(assumption)s
+7353(with)s 7676(which)s 8106(we)s 8332(do)s 8532(not)s
+8776(agree.)s 
+grestore
+
+pgsave restore
+showpage
+
+%%Page: ? 2
+%%BeginPageSetup
+%%PageResources: font Times-Roman
+%%+ font Times-Bold
+%%+ font Times-Italic
+/pgsave save def
+0.0500 dup scale 10 setlinewidth
+%%EndPageSetup
+gsave
+0 15840 translate
+0.0000 rotate
+
+grestore
+gsave
+0 15840 translate
+0.0000 rotate
+200 fnt82 0.0 0.0 0.0 setrgbcolor 1440 -1576(F)m 3(olks)k 1944(o)s 3(v)k 3(er)k
+2356(on)s 2620(the)s 2927(Dark)s 3389(Side)s 3807(ha)s 4(v)k 3(e)k
+4240(tools)s 4691(to)s 4910(e)s 3(xploit)k 5524(these)s
+1440 -1816(weaknesses,)m 2469(and)s 2809(the)s 3(y)k 3201(are)s
+3495(real,)s 3894(right)s 4322(here,)s 4766(right)s 5194(no)s 5(w)k 13(.)k
+5672(W)s 16(e)k 1440 -2056(learned)m 2067(of)s 2275(these)s
+2725(weaknesses)s 3694(by)s 3936(studying)s 4665(some)s 5127(successful)s
+1440 -2296(attacks,)m 2092(not)s 2398(just)s 2736(by)s 2987(a)s
+3126(careful)s 3728(e)s 3(xamination)k 4760(of)s 4977(the)s
+5271(protocol)s 1440 -2536(and)m 1778(the)s 160 fnt82 2071 -2534(BIND)m
+200 fnt82 2510 -2536(source)m 3079(code.)s 200 fnt84 1440 -3036(2.1)m
+1690(.)s 1840(Misdir)s 3(ected)k 2902(Destination)s 200 fnt82
+1440 -3414(A)m 1660(user)s 2067(asks)s 2485(her)s 2815(telnet)s
+3332(client)s 3849(to)s 4080(connect)s 4775(to)s 200 fnt84
+5006 -3415(host1)m 200 fnt82 5460 -3414(.)m 5636(Her)s 1440 -3654(client)m
+1972(asks)s 2405(the)s 2739(name)s 3261(serv)s 3(er)k
+3834(for)s 4157(the)s 4491(address)s 5178(of)s 200 fnt84
+5435 -3655(host1)m 200 fnt82 5889 -3654(,)m 1440 -3894(recei)m 5(v)k 3(es)k
+2201(a)s 2408(corrupt)s 3102(answer)s 8(,)k 3826(and)s
+4233(then)s 4695(initiates)s 5442(a)s 160 fnt82 5649 -3892(TCP)m
+200 fnt82 1440 -4134(connection)m 2415(to)s 2671(the)s 3015(telnet)s
+3557(serv)s 3(er)k 4140(at)s 4384(that)s 4783(address.)s
+5580(This)s 1440 -4374(address)m 2098(does)s 2525(not)s 2842(correspond)s
+3789(to)s 4006(her)s 4322(intended)s 5070(host,)s 5514(b)s 4(ut)k
+5827(it)s 1440 -4614(displays)m 2140(the)s 2431(usual)s 2899(greeting,)s
+3649(and)s 3985(she)s 4298(types)s 4766(her)s 5068(usual)s
+5536(login)s 1440 -4854(and)m 1789(passw)s 2(ord.)k 2700(The)s
+3071(connection)s 4006(drops,)s 4560(she)s 4886(tries)s 5288(it)s
+5459(ag)s 1(ain,)k 1440 -5094(all)m 1677(is)s 1848(well,)s
+2279(she)s 2583(chalks)s 3130(it)s 3279(up)s 3518(to)s
+3712(a)s 3839(gremlin)s 4497(in)s 4691(the)s 4973(netw)s 2(ork)k
+5663(and)s 1440 -5334(for)m 3(gets)k 2032(all)s 2273(about)s
+2759(it.)s 3012(But)s 3343(there)s 200 fnt83 3783 -5333(is)m
+200 fnt82 3958 -5334(a)m 4089(gremlin)s 4751(in)s 4949(her)s
+5246(netw)s 2(ork,)k 1440 -5574(and)m 1778(that)s 2126(gremlin)s
+2795(just)s 3132(harv)s 3(ested)k 3941(her)s 4245(passw)s 2(ord.)k
+200 fnt84 1440 -6115(2.2)m 1690(.)s 1840(Misdir)s 3(ected)k
+2902(Sour)s 3(ce)k 200 fnt82 1440 -6494(If)m 1630(that)s
+1986(same)s 2452(user)s 2841(depends)s 3552(on)s 3810(name)s
+4299(based)s 4810(authentication)s 1440 -6734(when)m 1941(inside)s 2485(what)s
+2941(she)s 3275(considers)s 4095(to)s 4319(be)s 4576(the)s
+4888(safe)s 5276(con\207nes)s 1440 -6974(of)m 1697(her)s 2042(internal)s
+2740(netw)s 2(ork,)k 3532(she')s 11(s)k 4020(in)s
+4266(for)s 4589(another)s 5277(hellride.)s 1440 -7214(An)m 3(yone)k
+2131(on)s 2393(an)s 3(y)k 2740(interior)s 3387(host)s
+3781(can)s 4119(almost)s 4711(tri)s 5(vially)k 5397(bypass)s
+1440 -7454(name)m 1944(based)s 2470(authentication,)s 3720(causing)s 4401(this)s
+4761(user')s 11(s)k 5297(hosts)s 5779(to)s 1440 -7694(belie)m 5(v)k 3(e)k
+2051(that)s 2394(\205the)s 3(y\206)k 2955(are)s 3242(\205her\206)s
+3717(and)s 4050(therefore)s 4812(allo)s 5(wing)k 5549(them)s
+1440 -7934(to)m 1643(log)s 1946(in)s 2149(with)s 2551(her)s
+2853(access)s 3407(rights)s 3908(and)s 4244(pri)s 5(viledges.)k
+5221(An)s 3(y)k 5610(host)s 1440 -8174(which)m 1998(is)s
+2201(allo)s 5(wed)k 2897(to)s 3123(accept)s 3701(incoming)s
+4525(connections)s 5547(from)s 1440 -8414(outside)m 2087(the)s 2402(local)s
+2860(netw)s 2(ork)k 3583(could)s 4098(be)s 4358(fooled)s
+4939(in)s 5166(this)s 5525(same)s 1440 -8654(w)m 2(ay)k 13(,)k
+1857(b)s 4(ut)k 2158(by)s 2408(an)s 2646(outside)s
+3271(host.)s 240 fnt84 1440 -9342(3.)m 1740(Ho)s 2(w)k
+2277(Did)s 2709(That)s 3261(Happen?)s 200 fnt82 1440 -9767(Clearly)m 13(,)k
+2150(the)s 2481(abo)s 3(v)k 3(e)k 3039(acti)s 5(vities)k
+3838(were)s 4312(not)s 4655(design)s 5263(goals)s 5771(of)s
+1440 -10007(the)m 160 fnt82 1749 -10005(DNS)m 200 fnt82 2133 -10007(protocol)m
+2863(or)s 3095(of)s 3327(the)s 160 fnt82 3636 -10005(BIND)m
+200 fnt82 4091 -10007(implementation)m 5406(of)s 5638(that)s 1440 -10247(protocol.)m
+2254(Let')s 11(s)k 2701(look)s 3106(at)s 3299(ho)s 5(w)k
+3688(the)s 3(y)k 4078(could)s 4571(occur)s 11(.)k
+200 fnt84 1440 -10788(3.1)m 1690(.)s 1840(Misdir)s 3(ected)k
+2902(Destination)s 200 fnt82 1440 -11166(It)m 1627(could)s 2136(be)s
+2390(as)s 2621(simple)s 3217(as)s 3448(a)s 3602(for)s 3(ged)k
+4185(response)s 4947(sent)s 5333(directly)s 1440 -11406(to)m 1673(her)s
+2005(resolv)s 3(er)k 11(.)k 2759(Ev)s 3(en)k
+3244(after)s 3685(25)s 3963(years)s 4460(of)s 4704(e)s 3(xperience,)k
+5690(the)s 1440 -11646(Internet)m 2136(still)s 2511(has)s 2854(no)s
+3132(production)s 4074(routers)s 4704(which)s 5269(disallo)s 5(w)k
+1440 -11886(pack)m 2(ets)k 2084(with)s 2488(impossible)s 3400(source)s
+3969(addresses.)s 4880(So)s 5141(if)s 5312(you)s 5662(can)s
+1440 -12126(route)m 1919(pack)s 2(ets)k 2583(to)s 2808(someone,)s
+3636(you)s 4006(can)s 4352(mak)s 2(e)k 4851(those)s
+5341(pack)s 2(ets)k 1440 -12366(look)m 1857(as)s 2084(though)s
+2701(the)s 3(y)k 3103(came)s 3584(from)s 4033(a)s
+4183(close)s 4653(and)s 5003(trusted)s 5606(host)s 1440 -12606(\211)m
+1600(e)s 5(v)k 3(en)k 2028(if)s 2209(the)s 3(y)k
+2609(originated)s 3476(outside)s 4111(that)s 4469(host')s 11(s)k
+4993(netw)s 2(ork.)k 5804(If)s 1440 -12846(an)m 1678(attack)s 2(er)k
+2354(can)s 2680(predict)s 3282(the)s 3575(time)s 3978(that)s
+4326(a)s 4464(query)s 4968(will)s 5327(be)s 5565(sent,)s
+1440 -13086(he)m 1699(need)s 2146(only)s 2572(\210ood)s 3054(the)s
+3368(resolv)s 3(er)k 4076(with)s 4501(bogus)s 5049(replies)s
+5649(and)s 1440 -13326(hope)m 1890(that)s 2250(his)s 2544(bogons)s
+3183(arri)s 5(v)k 3(e)k 3700(earlier)s 4268(than)s
+4673(the)s 4978(real)s 5337(answer)s 11(.)k 1440 -13566(Predicting)m
+2351(the)s 160 fnt82 2687 -13564(UDP)m 200 fnt82 3098 -13566(port)m
+3512(used)s 3970(by)s 4263(the)s 4599(resolv)s 3(er)k
+5329(for)s 5654(an)s 3(y)k 1440 -13806(gi)m 5(v)k 3(en)k
+1947(query)s 2473(might)s 3010(require)s 3645(that)s 4015(a)s
+4175(no)s 3(vice)k 4775(attack)s 2(er)k 5473(spend)s
+1440 -14046(se)m 5(v)k 3(eral)k 2038(minutes)s 2712(thinking)s
+3421(about)s 3908(it,)s 4112(b)s 4(ut)k 4407(man)s 3(y)k
+4891(attack)s 2(ers)k 5638(will)s 1440 -14286(consider)m 2164(that)s
+2512(time)s 2915(well)s 3307(spent.)s 6700 -1576(This)m 7114(w)s 2(ould)k
+7671(not)s 7986(ha)s 4(v)k 3(e)k 8415(w)s 2(ork)k 2(ed)k
+9069(in)s 9284(our)s 9610(e)s 3(xample,)k 10391(since)s
+6300 -1816(we')m 10(re)k 6820(assuming)s 7650(a)s 7816(one-w)s 2(ay)k
+8578(\207re)s 5(w)k 2(all.)k 9356(Her)s 9732(resolv)s 3(er)k
+10447(isn')s 3(t)k 6300 -2056(reachable)m 7158(by)s 7455(pack)s 2(ets)k
+8146(from)s 8630(outside)s 9302(her)s 9653(net)s 9993(\211)s
+10190(b)s 4(ut)k 10538(her)s 6300 -2296(name)m 6812(serv)s 3(er)k
+7375(is.)s 7688(If)s 7901(that)s 8280(name)s 8792(serv)s 3(er)k
+9355(can)s 9712(be)s 9981(corrupted,)s 6300 -2536(e)m 5(v)k 3(en)k
+6804(for)s 7172(an)s 7496(instant,)s 8212(then)s 8691(an)s
+9015(attack)s 2(er)k 9777(can)s 10189(redirect)s 6300 -2776(telnet)m
+6825(sessions)s 7560(\(containing)s 8551(passw)s 2(ords\),)k 9578(electronic)s
+10445(mail)s 6300 -3016(\(containing)m 7349(proprietary)s 8375(information\),)s 9573(or)s
+9881(e)s 5(v)k 3(en)k 10391(other)s 160 fnt82
+6300 -3254(DNS)m 200 fnt82 6674 -3256(queries)m 7304(\(thus)s 7758(using)s
+8246(one)s 8590(name)s 9077(serv)s 3(er)k 9615(to)s
+9826(help)s 10225(corrupt)s 6300 -3496(others.\))m 6990(Ev)s 3(ery)k
+7501(one)s 7827(of)s 8031(those)s 8489(things)s 9014(has)s
+9317(been)s 9731(seen)s 10122(in)s 10315(action)s 6300 -3736(\211)m
+6450(we')s 10(re)k 6942(not)s 200 fnt83 7247 -3735(just)m
+200 fnt82 7584 -3736(being)m 8077(paranoid.)s 200 fnt84 6300 -4277(3.2)m
+6550(.)s 6700(Misdir)s 3(ected)k 7762(Sour)s 3(ce)k
+200 fnt82 6300 -4656(On)m 6594(late)s 6930(mod)s 7285(el)s
+160 fnt82 7478 -4654(BSD)m 200 fnt82 7787 -4656(-de)m 8041(ri)s 5(v)k 3(ed)k
+8492(sys)s 8746(tems,)s 9221(name)s 9702(based)s 10205(au)s
+10393(then)s 10736(-)s 6300 -4896(ti)m 6410(ca)s 6586(tion)s
+6975(usu)s 7252(al)s 7395(ly)s 7629(tak)s 2(es)k
+8114(the)s 8436(form)s 8902(of)s 9147(\207les)s 9557(con)s
+9845(tain)s 10143(ing)s 10477(lists)s 6300 -5136(of)m 6551(host)s
+6968(names)s 7561(or)s 7812(ad)s 8000(dress)s 8408(es,)s
+8708(pos)s 8985(si)s 9117(bly)s 9457(in)s 9612(clud)s
+9955(ing)s 10295(a)s 10468(user)s 6300 -5376(name)m 6769(to)s
+6962(be)s 7188(matched)s 7900(ag)s 1(ainst)k 8500(the)s
+8781(re)s 8935(mote)s 9371(\(\205incoming\206\))s 10470(user)s 6300 -5616(name)m
+128 fnt82 6731 -5527(1)m 200 fnt82 6795 -5616(.)m 6896(A)s
+7091(con)s 7379(v)s 3(en)k 7664(tion)s 8025(is)s
+8208(up)s 8408(held)s 8802(where)s 9288(by)s 9539(cer)s
+9781(tain)s 160 fnt82 10130 -5614(TCP)m 200 fnt82 10472 -5616(port)m
+6300 -5856(num)m 6655(bers)s 128 fnt82 6986 -5767(2)m 200 fnt82
+7099 -5856(are)m 7390(able)s 7770(to)s 7974(be)s 8211(bound)s
+8760(only)s 9164(by)s 9413(pro)s 9679(cess)s 10009(es)s
+10223(e)s 3(x)k 10408(e)s 10496(cut)s 10739(-)s
+6300 -6096(ing)m 6608(with)s 7015(so-)s 7258(called)s 7785(\205super)s
+8357(user\206)s 8829(pri)s 5(v)k 9145(iledges)s 128 fnt82
+9708 -6007(3)m 200 fnt82 9772 -6096(.)m 9925(This)s 10332(rather)s
+6300 -6336(brit)m 6576(tle)s 6849(chain)s 7355(of)s 7596(causal)s
+8092(i)s 8147(ty)s 8377(per)s 8631(mits)s 9048(the)s
+160 fnt82 9366 -6334(BSD)m 200 fnt84 9750 -6337(ruser)m 3(ok\(\))k
+200 fnt82 10617 -6336(li)m 10727(-)s 6300 -6576(brary)m 6780(call)s
+7126(to)s 7341(as)s 7506(sume)s 7986(that)s 8344(the)s
+8647(re)s 8801(mote)s 9259(user)s 9650(name)s 10141(gi)s 5(v)k
+10391(en)s 10639(in)s 6300 -6816(the)m 6603(data)s 6994(stream)s
+7583(is)s 7775(\205authentic\206)s 8740(from)s 9187(the)s 9490(point)s
+9960(of)s 10186(vie)s 5(w)k 10628(of)s 6300 -7056(the)m
+6598(re)s 6752(mote)s 7205(host)s 7592(and)s 7935(its)s
+8177(ad)s 8365(min)s 8675(is)s 8807(tra)s 9016(tors.)s
+9469(Users)s 9976(are)s 10273(not)s 10583(al)s 10726(-)s
+6300 -7296(lo)m 5(wed)k 6834(to)s 7041(claim,)s 7584(when)s
+8068(the)s 3(y)k 8460(use)s 8777(the)s 200 fnt84
+9072 -7297(rsh)m 200 fnt82 9400 -7296(or)m 200 fnt84 9618 -7297(rdist)m
+200 fnt82 10067 -7296(or)m 200 fnt84 10285 -7297(rlogin)m 200 fnt82
+6300 -7536(com)m 6643(mands,)s 7265(that)s 7615(the)s 3(y)k
+8007(are)s 8301(some)s 8721(body)s 9173(the)s 3(y')k 10(re)k
+9775(not)s 10082(\211)s 10234(at)s 10429(least)s 6300 -7776(on)m
+6550(well)s 6942(run,)s 7308(trust)s 7661(w)s 2(or)k
+7969(th)s 1(y)k 8273(mul)s 8583(tius)s 8870(er)s
+9074(hosts.)s 160 fnt82 6700 -8085(BSD)m 200 fnt82 7009 -8087(')m 11(s)k
+7264(security)s 8016(took)s 8494(a)s 8705(giant)s 9226(step)s
+9669(forw)s 2(ard)k 10420(back)s 6300 -8327(in)m 6567(1989)s
+7079(or)s 7357(so,)s 7696(when)s 8240(the)s 8595(callers)s
+9224(of)s 200 fnt84 9502 -8328(ruser)m 3(ok\(\))k 200 fnt82
+10406 -8327(were)m 6300 -8567(encouraged)m 7316(to)s 7569(do)s 7867(more)s
+8374(than)s 8815(blindly)s 9478(assume)s 10161(that)s 10557(the)s
+6300 -8807(result)m 6891(of)s 200 fnt84 7207 -8808(gethostbyaddr\(getpeer)m 3(name\()k
+200 fnt82 9659 -8807(remote)m 200 fnt84 10211 -8808(\)\))m 200 fnt82
+10493 -8807(w)m 2(as)k 6300 -9047(accurate.)m 7095(It)s 7250(used)s
+7649(to)s 7838(be)s 8060(that)s 8392(whate)s 5(v)k 3(er)k
+160 fnt82 9147 -9045(DNS)m 200 fnt82 9499 -9047(g)m 1(a)k 4(v)k 3(e)k
+9901(as)s 10100(the)s 10377(name)s 6300 -9287(corresponding)m 7535(to)s
+7785(the)s 8123(source)s 8737(address)s 9428(of)s 9689(a)s
+9872(connection,)s 6300 -9527(w)m 2(as)k 6717(used)s 7192(directly)s
+7909(as)s 8184(the)s 8537(search)s 9154(k)s 2(e)k 3(y)k
+9547(when)s 10089(scanning)s 200 fnt84 6300 -9768(~/.rhosts)m 200 fnt82
+7150 -9767(and)m 7560(its)s 7869(bretheren.)s 8842(After)s 9383(someone)s
+10213(noticed)s 6300 -10007(that)m 6684(the)s 7013(name)s 7530(serv)s 3(er)k
+8098(being)s 8627(ask)s 2(ed)k 9164(for)s 9482(this)s
+9855(information)s 6300 -10247(w)m 2(as)k 6675(the)s 6986(one)s
+7342(belonging)s 8208(to)s 8431(the)s 8742(connection')s 11(s)k
+9816(initiator)s 8(,)k 10555(the)s 6300 -10487(con)m 8(v)k 3(ention)k
+7210(changed:)s 7964(No)s 5(w)k 13(,)k 8419(after)s
+8817(calling)s 200 fnt84 9393 -10488(gethostbyaddr\(\))m 200 fnt82 10754 -10487(,)m
+6300 -10727(the)m 6626(result)s 7150(is)s 7365(passed)s 7978(back)s
+8437(through)s 200 fnt84 9141 -10728(gethostbyname\(\))m 200 fnt82 10640 -10727(to)m
+6300 -10967(see)m 6642(if)s 6852(the)s 7184(addresses)s 8034(and)s
+8411(names)s 9008(all)s 9295(match.)s 9970(The)s 10369(name)s
+6300 -11207(serv)m 3(er)k 6843(for)s 200 fnt84 7136 -11208(gethostbyname\(\))m
+200 fnt82 8613 -11207(will)m 8983(be,)s 9282(barring)s 9918(corruption,)s
+6300 -11447(authoritati)m 5(v)k 3(e)k 7346(for)s 7627(an)s 3(y)k
+7961(gi)s 5(v)k 3(en)k 8445(host)s 8826(name)s
+9306(in)s 200 fnt84 9510 -11448(~/.rhosts)m 200 fnt82 10287 -11447(\(et)m
+10545(al.\))s 6300 -11687(Someone)m 7104(who)s 7510(can)s 7848(mak)s 2(e)k
+8339(their)s 8765(address)s 9423(appear)s 10015(to)s 10232(map)s
+10637(to)s 6300 -11927(one)m 6655(of)s 6888(your)s 7321(hosts)s
+7797(will)s 8173(ha)s 4(v)k 3(e)k 8609(to)s
+8831(tak)s 2(e)k 9227(some)s 9714(e)s 3(xtra)k
+10175(steps)s 10639(to)s 6300 -12167(also)m 6670(mak)s 2(e)k
+7149(your)s 7565(host)s 7947(appear)s 8527(to)s 8732(ha)s 4(v)k 3(e)k
+9151(one)s 9489(of)s 9705(his)s 9987(addresses.)s 6700 -12478(\(SunOS)m
+7403(put)s 7729(this)s 8087(check)s 8622(into)s 200 fnt84
+9003 -12479(gethostbyaddr\(\))m 200 fnt82 10435 -12478(\211)m 10606(an)s 6300 -12718(error)m
+6728(that)s 7068(will)s 7419(li)s 5(v)k 3(e)k
+7751(in)s 7948(inf)s 2(amy)k 13(,)k 8589(since)s
+9039(not)s 9336(e)s 5(v)k 3(ery)k 9812(caller)s
+10294(of)s 10502(that)s 6300 -12958(function)m 7033(w)s 2(ants)k
+7564(to)s 7788(get)s 8100(an)s 8357(\205error\206)s 8988(return)s
+9532(status)s 10053(when)s 10554(the)s gsave
+6300 -13574 translate
+200 fnt82 0.0 0.0 0.0 setrgbcolor 1134 0 0 0 200 240 50 LoutGraphic
+gsave
+0 0 moveto xsize 0 lineto stroke
+grestore
+
+grestore
+102 fnt82 0.0 0.0 0.0 setrgbcolor
+6300 -13755(1)m 160 fnt82 6351 -13826(E.g.,)m 160 fnt84 6688(hosts.equi)s 1(v)k
+160 fnt82 7443(,)s 160 fnt84 7523(hosts.lpd)s 160 fnt82
+8128(,)s 160 fnt84 8208(~/.rhosts)s 102 fnt82 6300 -14041(2)m
+160 fnt82 6351 -14112(Those)m 6781(from)s 7131(512)s 7411(to)s
+7575(1023.)s 102 fnt82 6300 -14295(3)m 160 fnt82 6351 -14366(This)m
+6674(con)s 6(v)k 2(ention)k 7416(is)s 7562(of)s
+7735(course)s 8192(meaningless)s 9021(on)s 9221(single-user)s 9961(hosts.)s
+
+grestore
+
+pgsave restore
+showpage
+
+%%Page: ? 3
+%%BeginPageSetup
+%%PageResources: font Times-Roman
+%%+ font Times-Bold
+%%+ font Times-Italic
+/pgsave save def
+0.0500 dup scale 10 setlinewidth
+%%EndPageSetup
+gsave
+0 15840 translate
+0.0000 rotate
+
+grestore
+gsave
+0 15840 translate
+0.0000 rotate
+200 fnt82 0.0 0.0 0.0 setrgbcolor 1440 -1576(forw)m 2(ard)k 2150(and)s
+2520(re)s 5(v)k 3(erse)k 3167(lookups)s 3881(yield)s
+4361(asymmetric)s 5370(results.)s 1440 -1816(The)m 1853(proper)s 2476(place)s
+2998(for)s 3333(this)s 3723(mapping)s 4524(logic)s 5025(is)s
+5260(in)s 5518(those)s 1440 -2056(applications)m 2459(and)s 2805(library)s
+3393(calls)s 3814(who)s 4216(intend)s 4772(to)s 4985(use)s
+5308(the)s 5609(data)s 1440 -2296(for)m 1720(some)s 2188(kind)s
+2591(of)s 2805(authentication)s 3980(\211)s 4128(it)s 4286(is)s
+4466(not)s 4769(a)s 4905(naming)s 5551(issue)s 1440 -2536(per)m
+1744(se,)s 2009(and)s 2347(does)s 2762(not)s 3067(belong)s
+3660(in)s 3865(the)s 4158(resolv)s 3(er)k 11(.\))k
+1840 -2847(As)m 2114(ef)s 5(fecti)k 5(v)k 3(e)k
+2848(as)s 3066(that)s 3417(e)s 3(xtra)k 200 fnt84
+3864 -2848(gethostbyname\(\))m 200 fnt82 5333 -2847(call)m 5672(has)s 1440 -3087(been,)m
+1908(its)s 2137(goal)s 2522(w)s 2(as)k 2871(to)s
+3068(k)s 2(eep)k 3484(attack)s 2(ers)k 4229(from)s
+4658(just)s 4987(editing)s 5582(their)s 160 fnt82 1440 -3325(IN-ADDR.ARP)m 14(A)k
+200 fnt82 2603 -3327(zones)m 3097(and)s 3426(zooming)s 4165(on)s
+4406(in.)s 4702(No)s 4987(thought)s 5638(w)s 2(as)k
+1440 -3567(gi)m 5(v)k 3(en)k 1949(to)s 2178(whether)s
+2893(the)s 3210(name)s 3715(serv)s 3(ers)k 4348(could)s
+4865(be)s 5127(corrupted.)s 1440 -3807(So)m 1724(while)s 2239(an)s
+2500(attack)s 2(er)k 3199(has)s 3537(a)s 3698(little)s
+4134(more)s 4616(w)s 2(ork)k 5097(to)s 5325(do)s
+5598(no)s 5(w)k 1440 -4047(than)m 1853(in)s 2078(the)s
+2391(Old)s 2760(Days,)s 3289(it)s 3469(is)s 3671(still)s
+4038(tri)s 5(vially)k 4732(easy)s 5155(to)s 5380(pollute)s
+1440 -4287(the)m 1733(caches)s 2312(of)s 2528(the)s 2821(set)s
+3091(of)s 3307(serv)s 3(ers)k 3916(who)s 4310(will)s
+4669(be)s 4907(ask)s 2(ed)k 5408(for)s 5690(the)s
+200 fnt84 1440 -4528(gethostbyaddr\(\))m 200 fnt82 2885 -4527(and)m 200 fnt84
+3257 -4528(gethostbyname\(\))m 200 fnt82 4757 -4527(answers,)m 5531(or)s 5781(to)s
+1440 -4767(\210ood)m 1905(the)s 2202(resolv)s 3(ers)k 2970(with)s
+3378(bogus)s 3909(responses)s 4736(at)s 4933(the)s 5230(time)s
+5637(that)s 1440 -5007(the)m 3(y)k 1830(are)s 2122(predicted)s
+2912(to)s 3117(be)s 3355(w)s 2(aiting)k 4000(for)s
+4282(the)s 4575(answers.)s 1840 -5318(If)m 2035(an)s 2286(attack)s 2(er)k
+2975(can)s 3314(reach)s 3807(the)s 4113(victim')s 11(s)k
+4816(host,)s 5261(the)s 3(y)k 5664(can)s 1440 -5558(probably)m
+2223(mak)s 2(e)k 2726(their)s 3164(host)s 3570(name)s
+4075(seem)s 4557(to)s 4786(be)s 5048(almost)s 5652(an)s 3(y)k
+1440 -5798(arbitrary)m 2210(string)s 2749(when)s 3267(vie)s 5(wed)k
+3923(by)s 4209(the)s 4538(victim')s 11(s)k 200 fnt84
+5264 -5799(rlogind)m 200 fnt82 5884 -5798(.)m 1440 -6038(And,)m 1869(if)s
+2025(the)s 3(y)k 2400(can)s 2711(also)s 3066(break)s
+3543(\205super)s 4097(user\206)s 4551(on)s 4786(the)s 5064(source)s
+5618(host)s 1440 -6278(\(or)m 1727(if)s 1903(that)s 2256(host)s
+2643(is)s 2830(their)s 3249(o)s 5(wn)k 3643(of\207ce)s
+4151(w)s 2(orkstation\),)k 5260(the)s 3(y)k 5655(can)s
+1440 -6518(mak)m 2(e)k 1930(the)s 2234(victim)s 2803(see)s
+3117(an)s 3(y)k 3463(arbitrary)s 4208(remote)s 4821(user)s
+5213(name.)s 5805(If)s 1440 -6758(this)m 1777(attack)s 2(er)k
+2453(kno)s 5(ws)k 3019(an)s 3(y)k 3354(of)s
+3570(the)s 3863(contents)s 4576(of)s 4792(your)s 200 fnt84
+5208 -6759(~/.rhosts)m 200 fnt82 1440 -6998(\207les)m 1817(or)s 2029(your)s
+2441(~B)s 2682(hosts.equi)s 5(v)k 3625(\207le)s 3925(\211)s
+4071(and)s 4405(these)s 4859(are)s 5147(eminently)s 1440 -7238(guessable)m
+2263(\211)s 2413(then)s 2806(the)s 3(y)k 3196(are)s
+200 fnt83 3488 -7237(in)m 200 fnt82 3643 -7238(.)m 240 fnt84
+1440 -7926(4.)m 1740(Pr)s 4(otocol)k 2659(V)s 8(iew)k
+3229(of)s 3488(W)s 15(eaknesses)k 200 fnt82 1440 -8306(One)m
+1869(w)s 2(ay)k 2296(of)s 2559(looking)s 3266(at)s
+3506(these)s 4011(weaknesses)s 5035(is)s 5264(from)s 5748(an)s
+1440 -8546(operational)m 2461(point)s 2997(of)s 3289(vie)s 5(w)k 13(,)k
+3834(which)s 4447(gi)s 5(v)k 3(en)k 5008(the)s
+5377(current)s 1440 -8786(state)m 1883(of)s 2129(the)s 2452(art,)s
+2791(tells)s 3201(us:)s 200 fnt83 3513 -8785(name)m 4025(based)s
+4570(authentication)s 5801(is)s 1440 -9025(inher)m 7(ently)k 2303(insecur)s 7(e)k
+200 fnt82 2969 -9026(.)m 3133(Sessions)s 3882(\(whether)s 160 fnt82
+4653 -9024(TELNET)m 200 fnt82 5253 -9026(,)m 160 fnt82 5367 -9024(NFS)m
+200 fnt82 5658 -9026(,)m 5772(or)s 1440 -9266(whate)m 5(v)k 3(er\))k
+2279(should)s 2863(require)s 3478(something)s 4360(stronger)s 5064(than)s
+5459(trying)s 1440 -9506(to)m 1645(determine)s 2490(a)s 2628(host')s 11(s)k
+3142(name)s 3623(and)s 3961(and)s 4299(then)s 4692(looking)s
+5352(for)s 5634(that)s 1440 -9746(name)m 1923(in)s 2130(some)s
+2602(statically)s 3370(con\207gured)s 4275(list.)s 4619(\()s 4685([)s
+4751(RFC1510)s 5528(])s 5646(and)s 1440 -9986([)m 1506(RFC1760)s
+2283(])s 2399(are)s 2691(each)s 3105(cause)s 3596(for)s
+3878(optimism.\))s 1840 -10297(From)m 2307(the)s 2585(bottom,)s 3235(though,)s
+3875(these)s 4318(weaknesses)s 5280(all)s 5513(come)s 1440 -10537(with)m
+1875(particular)s 2717(sets)s 3095(of)s 3342(details)s 3941(and)s
+4310(can)s 4667(be)s 4936(described)s 5779(in)s 1440 -10777(terms)m
+1960(of)s 160 fnt82 2205 -10775(DNS)m 200 fnt82 2602 -10777(protocol)m
+3345(elements.)s 4230(As)s 4530(implementors)s 5703(we)s 1440 -11017(are)m
+1728(more)s 2183(interested)s 3001(in)s 3202(this)s 3535(vie)s 5(w)k
+3963(than)s 4352(in)s 4553(the)s 4842(more)s 5297(political)s
+1440 -11257(questions)m 2225(of)s 2424(Global)s 2999(Internet)s 3650(Authentication.)s
+4966(So)s 5210(let')s 11(s)k 5573(ha)s 4(v)k 3(e)k
+1440 -11497(a)m 1595(look)s 2017(at)s 2227(the)s 2537(pack)s 2(ets,)k
+3248(shall)s 3690(we?)s 4127(After)s 4613(that)s 4978(we')s 2(ll)k
+5451(tak)s 2(e)k 5847(a)s 1440 -11737(look)m 1845(at)s
+2038(the)s 2331(w)s 2(ays)k 2788(the)s 3(y)k
+3178(can)s 3504(be)s 3742(perv)s 3(erted.)k 1840 -12048(W)m 16(e)k
+2161(do)s 2422(not)s 2738(in)s 2893(tend)s 3297(to)s
+3513(present)s 4148(an)s 4397(e)s 3(x)k 4582(haus)s
+4947(ti)s 5(v)k 3(e)k 5298(de)s 5486(scrip)s
+5872(-)s 1440 -12288(tion)m 1794(of)s 160 fnt82 2004 -12286(DNS)m
+200 fnt82 2366 -12288(\211)m 2510([)s 2576(RFC1034)s 3353(])s
+3463(and)s 3795([)s 3861(RFC1035)s 4638(])s 4748(al)s
+4891(ready)s 5377(\207ll)s 5642(that)s 1440 -12528(need.)m 1963(Our)s
+2320(goal)s 2710(in)s 2912(this)s 3246(sec)s 3499(tion)s
+3856(is)s 4035(to)s 4237(present)s 4858(enough)s 5493(in)s
+5648(for)s 5880(-)s 1440 -12768(ma)m 1683(tion)s 2030(about)s
+160 fnt82 2510 -12766(DNS)m 200 fnt82 2865 -12768(that)m 3200(some)s
+3620(one)s 3945(un)s 4145(f)s 2(a)k 4297(mil)s
+4562(iar)s 4808(with)s 5199(its)s 5423(de)s 5611(tails)s
+1440 -13008(can)m 1795(still)s 2171(un)s 2371(der)s 2625(stand)s
+3124(the)s 3446(se)s 3611(cu)s 3799(ri)s 3920(ty)s
+4154(rami\207cations)s 5271(of)s 5516(some)s 1440 -13248(of)m 160 fnt82
+1691 -13246(DNS)m 200 fnt82 2009 -13248(')m 11(s)k 2226(de)s
+2414(sign)s 2831(choic)s 3262(es.)s 3612(If)s 3829(this)s
+4201(re)s 4355(port)s 4761(dis)s 4993(agrees)s 5585(with)s
+1440 -13488([)m 1506(RFC1034)s 2283(])s 2405(or)s 2627([)s
+2693(RFC1035)s 3470(])s 3592(in)s 3803(an)s 3(y)k
+4144(de)s 4332(tail,)s 4691(it)s 4857(is)s 5045(most)s
+5488(lik)s 2(e)k 5784(ly)s 1440 -13728(that)m 1788(the)s
+2081(re)s 2235(port)s 2606(is)s 2788(wrong.)s 200 fnt84
+6300 -1577(4.1)m 6550(.)s 160 fnt84 6700 -1574(DNS)m 200 fnt84
+7068 -1577(Datagram)m 7982(F)s 5(ormats)k 160 fnt82 6300 -1992(DNS)m
+200 fnt82 6664 -1994(queries)m 7284(and)s 7618(responses)s 8437(use)s
+8748(a)s 8882(common)s 9626(format,)s 10252(though)s 6300 -2234(not)m
+6651(all)s 6945(protocol)s 7705(elements)s 8507(are)s 8845(used)s
+9306(all)s 9600(the)s 9939(time.)s 10488(The)s 6300 -2474(simplest)m
+7047(case,)s 7523(described)s 8370(here,)s 8847(uses)s 160 fnt82
+9274 -2472(IP/UDP)m 200 fnt82 9862 -2474(where)m 10433(each)s 6300 -2714(datagram)m
+7085(contains)s 7793(one)s 160 fnt82 8126 -2712(DNS)m 200 fnt82
+8489 -2714(query)m 8988(or)s 9199(response.)s 160 fnt82 10040 -2712(DNS)m
+200 fnt82 10358 -2714(')m 11(s)k 10535(use)s 6300 -2954(of)m
+160 fnt82 6520 -2952(IP/TCP)m 200 fnt82 7050 -2954(is)m 7236(be)s 3(yond)k
+7875(the)s 8172(scope)s 8679(of)s 8899(this)s 9240(report)s
+9769(other)s 10232(than)s 10629(as)s 6300 -3194(it)m 6460(af)s 5(fects)k
+7033(zone)s 7459(transfers,)s 8242(which)s 8779(we)s 9061(will)s
+9420(discuss)s 10044(shortly)s 13(.)k 200 fnt84 6300 -3506(Header)m
+7064(Section)s 200 fnt82 7683 -3505(:)m 7872(Describes)s 8789(the)s
+9166(other)s 9709(sections,)s 10533(has)s 6700 -3745(\210ags)m 7207(including)s
+160 fnt82 8091 -3743(RD)m 200 fnt82 8443 -3745(\(recursion)m 9380(desired\))s
+10151(and)s 160 fnt82 10570 -3743(AA)m 200 fnt82 6700 -3985(\(authoritati)m 5(v)k 3(e)k
+7831(answer\),)s 8578(and)s 8934(most)s 9389(important)s 10231(for)s
+10531(our)s 6700 -4225(discussion,)m 7629(has)s 7944(a)s 8082(16)s
+8332(bit)s 8592(\205query)s 160 fnt82 9184 -4223(ID)m 200 fnt82
+9352 -4225(.)m 14(\206)k 200 fnt84 6300 -4537(Query)m 6884(Section)s
+200 fnt82 7503 -4536(:)m 7600(Contains)s 8350(the)s 8635(name,)s
+9158(class,)s 9635(and)s 9965(type)s 10350(of)s 10558(the)s
+6700 -4776(resource)m 7406(record)s 7947(set)s 8200(\(\205RRset\206\))s 9027(being)s
+9503(queried)s 10133(for)s 11(.)k 160 fnt82 10487 -4774(DNS)m
+200 fnt82 6700 -5016(permits)m 7353(multiple)s 8073(queries)s 8704(in)s
+8916(this)s 9260(section)s 9880(b)s 4(ut)k 10188(this)s
+10532(has)s 6700 -5256(ne)m 5(v)k 3(er)k 7184(been)s
+7610(tried)s 8024(and)s 8362(is)s 8544(not)s 8849(well)s
+9241(speci\207ed.)s 200 fnt84 6300 -5568(Answer)m 7041(Section)s 200 fnt82
+7660 -5567(:)m 7804(Al)s 2(w)k 2(ays)k 8497(empty)s
+9084(in)s 9328(queries.)s 10091(Contains)s 6700 -5807(the)m 7003(RRset)s
+7549(matching)s 8350(the)s 8653(query)s 13(,)k 9204(or)s
+9430(is)s 9622(empty)s 10180(if)s 10361(name)s 6700 -6047(doesn')m 3(t)k
+7349(e)s 3(xist,)k 7837(if)s 8024(no)s 8290(data)s
+8687(matched)s 9427(the)s 9736(query)s 13(,)k 10293(or)s
+10525(if)s 10712(a)s 6700 -6287(nonrecursi)m 5(v)k 3(e)k
+7770(query)s 8274(results)s 8842(in)s 9047(a)s 9185(referral.)s
+200 fnt84 6300 -6599(A)m 10(uthority)k 7210(Section)s 200 fnt82
+7829 -6598(:)m 7963(Al)s 2(w)k 2(ays)k 8646(empty)s
+9223(in)s 9457(queries.)s 10210(Can)s 10610(be)s 6700 -6838(empty)m
+7282(in)s 7521(responses.)s 8478(If)s 8694(nonempty)s 13(,)k
+9613(it)s 9807(contains)s 10554(the)s 160 fnt82 6700 -7076(NS)m
+200 fnt82 6992 -7078(and)m 160 fnt82 7369 -7076(SO)m 5(A)k
+7771(RR)s 200 fnt82 7983 -7078(s)m 8149(for)s 8470(the)s
+8802(enclosing)s 9654(zone.)s 10219(This)s 10662(is)s 6700 -7318(sometimes)m
+7600(called)s 8124(\205referral)s 8845(data.)s 14(\206)k 200 fnt84
+6300 -7630(Additional)m 7245(Data)s 7692(Section)s 200 fnt82 8311 -7629(:)m
+8403(Al)s 2(w)k 2(ays)k 9044(empty)s 9579(in)s
+9771(queries.)s 10482(Can)s 6700 -7869(be)m 6958(empty)s 7526(in)s
+7751(responses.)s 8694(If)s 8896(the)s 9209(answer)s 9842(or)s
+10078(authority)s 6700 -8109(section)m 7326(contains)s 8052(an)s 3(y)k
+160 fnt82 8400 -8107(RR)m 200 fnt82 8612 -8109(s)m 8752(whose)s
+9324(data)s 9718(\207elds)s 10212(contain)s 6700 -8349(RRnames,)m 7609(the)s
+7937(RRsets)s 8585(for)s 8902(those)s 9407(RRnames)s 10266(appear)s
+6700 -8589(here.)m 200 fnt84 6300 -9089(4.2)m 6550(.)s 6700(Ser)s 2(v)k 2(ers)k
+7386(and)s 7758(Resolv)s 2(ers)k 200 fnt82 6300 -9468(The)m
+6687(client)s 7205(in)s 160 fnt82 7437 -9466(DNS)m 200 fnt82
+7832 -9468(is)m 8041(called)s 8592(a)s 8757(\205resolv)s 3(er)k 11(.)k 14(\206)k
+9722(The)s 10109(serv)s 3(er)k 10668(is)s 6300 -9708(called,)m
+6865(appropriately)s 7967(enough,)s 8646(a)s 8775(\205name)s 9335(serv)s 3(er)k 11(.)k 14(\206)k
+10021(Resolv)s 3(ers)k 6300 -9948(ha)m 4(v)k 3(e)k
+6714(some)s 7179(static)s 7642(con\207guration)s 8750(information,)s 9785(consisting)s
+10637(of)s 6300 -10188(a)m 6427(domain)s 7064(\205search)s 7698(list\206)s
+8067(and)s 8394(a)s 8521(list)s 8802(of)s 9007(name)s
+9477(serv)s 3(er)k 9998(addresses.)s 6300 -10428(Theoretically)m 13(,)k
+7471(a)s 7633(resolv)s 3(er)k 8344(can)s 8694(also)s
+9088(be)s 9350(con\207gured)s 10277(with)s 10705(a)s 6300 -10668(static)m
+6759(map)s 7143(of)s 7350(domains)s 8066(to)s 8262(name)s
+8734(serv)s 3(er)k 9257(addresses,)s 10109(allo)s 5(wing)k
+6300 -10908(queries)m 6969(to)s 7219(be)s 7502(forw)s 2(arded)k
+8413(directly)s 9115(to)s 9365(appropriate)s 10366(name)s 6300 -11148(serv)m 3(ers)k
+6941(for)s 7255(some)s 7757(set)s 8059(of)s 8307(locally)s
+8930(kno)s 5(wn)k 9551(domains.)s 160 fnt82 10408 -11146(BIND)m
+200 fnt82 6300 -11388(does)m 6725(not)s 7040(implement)s 7951(this)s
+8298(last)s 8633(part)s 9002(yet.)s 9355(The)s 9725(resolv)s 3(er')k 11(s)k
+10554(list)s 6300 -11628(of)m 6526(name)s 7017(serv)s 3(er)k
+7559(addresses)s 8380(had)s 8728(better)s 9240(include)s 9886(at)s
+10089(least)s 10512(one)s 6300 -11868(recursi)m 5(v)k 3(e)k
+7069(name)s 7549(serv)s 3(er)k 8(,)k 8122(or)s
+8337(the)s 160 fnt82 8629 -11866(DNS)m 200 fnt82 8996 -11868(name)m
+9476(space)s 9966(is)s 10147(going)s 10651(to)s 6300 -12108(look)m
+6705(pretty)s 7219(small.)s 200 fnt84 6300 -12649(4.3)m 6550(.)s
+6700(Recursion)s 200 fnt82 6300 -13027(T)m 16(o)k 6557(\205recurse\206)s
+7357(on)s 7608(a)s 7747(query)s 8252(means)s 8811(that)s
+9160(when)s 9643(a)s 9782(query)s 10287(comes)s 6300 -13267(in)m
+6507(for)s 6791(an)s 7031(RRset)s 7569(not)s 7876(kno)s 5(wn)k
+8467(to)s 8674(the)s 8969(serv)s 3(er)k 9503(recei)s 5(ving)k
+10290(it,)s 10502(that)s 6300 -13507(serv)m 3(er)k 6829(will)s
+7185(forw)s 2(ard)k 7860(it)s 8017(to)s 8219(some)s
+8686(name)s 9164(serv)s 3(er)k 9693(more)s 10149(lik)s 2(ely)k
+10647(to)s 6300 -13747(kno)m 5(w)k 6802(the)s 7108(answer)s 11(.)k
+7823(In)s 8052(some)s 8535(cases,)s 9066(the)s 9372(forw)s 2(arding)k
+10318(serv)s 3(er)k 6300 -13987(will)m 6678(kno)s 5(w)k
+7186(the)s 7498(name)s 7998(serv)s 3(er)k 8549(list)s
+8860(for)s 9161(the)s 9473(e)s 3(xact)k 9958(domain)s
+10625(or)s 6300 -14227(parent)m 6862(domain)s 7525(of)s 7756(the)s
+8064(query)s 13(.)k 8670(More)s 9166(often,)s 9690(a)s
+9843(grandparent)s 
+grestore
+
+pgsave restore
+showpage
+
+%%Page: ? 4
+%%BeginPageSetup
+%%PageResources: font Times-Roman
+%%+ font Times-Bold
+%%+ font Times-Italic
+/pgsave save def
+0.0500 dup scale 10 setlinewidth
+%%EndPageSetup
+gsave
+0 15840 translate
+0.0000 rotate
+
+grestore
+gsave
+0 15840 translate
+0.0000 rotate
+200 fnt82 0.0 0.0 0.0 setrgbcolor 1440 -1576(domain')m 11(s)k 2254(serv)s 3(ers)k
+2897(are)s 3223(kno)s 5(wn,)k 3896(or)s 4146(no)s
+4430(serv)s 3(ers)k 5073(are)s 5399(kno)s 5(wn)k
+1440 -1816(and)m 1777(the)s 2069(query)s 2572(is)s 2753(sent)s
+3122(all)s 3369(the)s 3661(w)s 2(ay)k 4040(to)s
+4244(the)s 4536(root)s 4906(name)s 5386(serv)s 3(ers)k
+1440 -2056(\(which)m 2041(are)s 2331(co-operated)s 3318(by)s 3566(the)s
+3857(InterNIC)s 4623(and)s 4959(a)s 5095(w)s 2(orldwide)k
+1440 -2296(cadre)m 1910(of)s 2116(v)s 4(olunteers.\))k 3097(There)s
+3601(is)s 3773(a)s 3901(\210ag)s 4240(in)s 4435(the)s
+4718(query)s 5212(called)s 160 fnt82 5726 -2294(RD)m 200 fnt82
+1440 -2536(which,)m 2037(if)s 2218(set,)s 2548(speci\207es)s 3292(that)s
+3650(recursion)s 4450(is)s 4642(desired;)s 5331(if)s 5512(clear)s 8(,)k
+1440 -2776(a)m 1592(name)s 2087(serv)s 3(er)k 2633(will)s
+3006(answer)s 3633(queries)s 4271(for)s 4567(unkno)s 5(wn)k
+5370(RRsets)s 1440 -3016(with)m 1838(an)s 2070(appropriate)s 3020(error)s
+3450(\(\205name)s 4079(unkno)s 5(wn\206)k 4950(or)s 5160(\205no)s
+5492(data,)s 14(\206)k 1440 -3256(depending.\))m 1840 -3567(Sending)m 2561(nonrecursi)s 5(v)k 3(e)k
+3648(queries)s 4289(is)s 4488(a)s 4643(\207ne)s 5009(w)s 2(ay)k
+5406(to)s 5628(\207nd)s 1440 -3807(out)m 1748(what)s 2188(a)s
+2329(name)s 2813(serv)s 3(er)k 3348(already)s 3986(kno)s 5(ws,)k
+4605(since,)s 5116(otherwise,)s 1440 -4047(you)m 1790(will)s 2149(get)s
+2442(an)s 2680(answer)s 3293(e)s 5(v)k 3(en)k
+3711(if)s 3882(the)s 4175(name)s 4656(serv)s 3(er)k
+5188(had)s 5526(to)s 5731(go)s 1440 -4287(searching)m 2252(for)s
+2534(it)s 2694(at)s 2887(the)s 3180(time)s 3583(of)s
+3799(your)s 4215(query)s 13(.)k 200 fnt84 1440 -4828(4.4)m
+1690(.)s 1840(Referrals)s 200 fnt82 1440 -5207(If)m 1615(a)s
+1746(name)s 2220(serv)s 3(er)k 2745(recei)s 5(v)k 3(es)k
+3430(a)s 3561(query)s 4058(for)s 4333(a)s 4464(<)s
+200 fnt83 4576 -5206(name)m 200 fnt82 5008 -5207(,)m 200 fnt83
+5058 -5206(class)m 200 fnt82 5455 -5207(,)m 200 fnt83 5505 -5206(type)m
+200 fnt82 5836 -5207(>)m 1440 -5447(tuple)m 1937(that)s 2334(it)s
+2543(kno)s 5(ws)k 3158(it)s 3367(has)s 3731(dele)s 3(g)k 1(ated,)k
+4638(it)s 4847(answers)s 5586(with)s 1440 -5687(what')m 11(s)k
+2052(called)s 2619(a)s 2800(\205referral.)s 14(\206)k 3688(A)s
+3925(referral)s 4601(response)s 5390(has)s 5748(an)s 1440 -5927(empty)m
+1995(answer)s 2615(section)s 3235(b)s 4(ut)k 3543(a)s
+3688(nonempty)s 4543(authority)s 5319(section;)s 1440 -6167(the)m 1755(intent)s
+2280(of)s 2518(this)s 2877(message)s 3622(is)s 3826(to)s
+4053(tell)s 4378(another)s 5047(serv)s 3(er)k 5601(\205the)s
+1440 -6407(name)m 1934(you)s 2297(ask)s 2(ed)k 2811(for)s
+3106(e)s 3(xists,)k 3668(b)s 4(ut)k 3982(I)s
+4111(don')s 3(t)k 4592(ha)s 4(v)k 3(e)k
+5024(the)s 5330(answer)s 8(,)k 1440 -6647(go)m 1726(try)s
+2033(these)s 2527(other)s 3022(serv)s 3(ers.)k 14(\206)k
+3791(Bogus)s 4387(referrals)s 5133(are)s 5461(a)s 5635(\207ne)s
+1440 -6887(w)m 2(ay)k 1832(to)s 2049(pollute)s 2664(a)s
+2814(cache)s 3328(indirectly)s 4152(\211)s 4314(if)s 4497(you)s
+4859(can)s 5197(snoop)s 5736(on)s 1440 -7127(a)m 1609(forw)s 2(arded)k
+2506(query)s 3041(and)s 3410(then)s 3834(inject)s 4356(a)s
+4525(referral)s 5189(response,)s 1440 -7367(you)m 1809(can)s 2154(mak)s 2(e)k
+2652(the)s 2964(forw)s 2(arding)k 3916(serv)s 3(er)k
+4467(ef)s 5(fecti)k 5(v)k 3(ely)k 5372(belie)s 5(v)k 3(e)k
+1440 -7607(that)m 200 fnt83 1795 -7606(you)m 200 fnt82 2140 -7607(are)m
+2439(the)s 2739(dele)s 3(g)k 1(ated)k 3554(serv)s 3(er)k
+4093(for)s 4382(an)s 4627(entire)s 5136(subtree)s 5767(of)s
+1440 -7847(the)m 160 fnt82 1742 -7845(DNS)m 200 fnt82 2119 -7847(name)m
+2609(space.)s 3209(This)s 3622(is)s 3813(actually)s 4501(the)s
+4803(easiest)s 5390(w)s 2(ay)k 5779(to)s 1440 -8087(pollute)m
+2057(a)s 2209(cache)s 2725(since)s 3197(there')s 11(s)k
+3790(no)s 4054(guessing)s 4815(in)s 8(v)k 4(olv)k 3(ed:)k
+5617(Y)s 22(ou)k 1440 -8327(kno)m 5(w)k 1938(the)s
+2240(source)s 2818(address,)s 3523(source)s 160 fnt82 4101 -8325(UDP)m
+200 fnt82 4478 -8327(port,)m 4908(and)s 5255(query)s 160 fnt82
+5768 -8325(ID)m 200 fnt82 1440 -8567(by)m 1680(inspection.)s 2638(Y)s 22(ou)k
+3000(e)s 5(v)k 3(en)k 3408(kno)s 5(w)k
+3887(the)s 4170(query)s 4664(name.)s 5235(The)s 5585(only)s
+1440 -8807(trick)m 1854(is)s 2036(in)s 2241(breaking)s 2988(into)s
+3348(a)s 3486(host)s 3868(on)s 4118(a)s 4256(netw)s 2(ork)k
+4957(backbone)s 5771(so)s 1440 -9047(that)m 1795(you)s 2152(can)s
+2485(actually)s 3171(see)s 3481(the)s 3781(queries)s 4412(being)s
+4912(forw)s 2(arded)k 5785(to)s 1440 -9287(the)m 1733(root)s
+2104(serv)s 3(ers.)k 2763(This)s 3167(has)s 3482(been)s
+3908(done)s 128 fnt82 4296 -9198(1)m 200 fnt82 4360 -9287(,)m
+4460(b)s 4(ut)k 4761(not)s 5066(often.)s 200 fnt84
+1440 -9813(4.5)m 1690(.)s 1840(A)s 10(uthority:)k 2787(Masters)s
+3521(and)s 3893(Sla)s 5(v)k 2(es)k 200 fnt82
+1440 -10230(T)m 16(o)k 1720(be)s 1982(\205authoritati)s 5(v)k 3(e\206)k
+3229(means)s 3811(that)s 4183(a)s 4345(name)s 4850(serv)s 3(er)k
+5406(has)s 5745(an)s 1440 -10470(entire)m 1955(\205zone\206)s 2570(loaded,)s
+3214(either)s 3729(via)s 4035(a)s 4186(\205master)s 4866(\207le\206)s
+5271(that)s 5632(w)s 2(as)k 1440 -10710(created)m 2069(by)s
+2325(the)s 2624(name)s 3111(serv)s 3(er)k 3649(administrator)s 8(,)k
+4807(or)s 5029(via)s 5328(a)s 5472(\205zone)s 1440 -10950(transfer)m 8(,)k 14(\206)k
+2196(which)s 2717(is)s 2883(a)s 160 fnt82 3005 -10948(TCP)m
+200 fnt82 3330 -10950(session)m 3938(with)s 4326(another)s 4957(name)s
+5422(serv)s 3(er)k 11(.)k 1440 -11190(The)m 1806(former)s
+2403(kind)s 2814(of)s 3036(serv)s 3(er)k 3574(is)s
+3762(called)s 4292(the)s 4591(\205master\206)s 5352(and)s 5696(the)s
+1440 -11430(latter)m 1890(is)s 2065(a)s 2196(\205sla)s 4(v)k 3(e.)k 14(\206)k
+2852(Sla)s 4(v)k 3(es)k 3407(generally)s 4190(do)s
+4433(their)s 4840(zone)s 5259(transfers)s 1440 -11670(from)m 1891(the)s
+2198(master)s 8(,)k 2833(b)s 4(ut)k 3148(sometimes)s
+4062(\207re)s 5(w)k 2(alls)k 4803(are)s 5109(interposed)s
+1440 -11910(and)m 1797(it)s 1976(becomes)s 2741(necessary)s 3582(to)s
+3806(ha)s 4(v)k 3(e)k 4244(sla)s 4(v)k 3(es)k
+4791(pull)s 5170(their)s 5603(data)s 1440 -12150(from)m 1884(other)s
+2350(sla)s 4(v)k 3(es,)k 2935(which)s 3479(are)s
+3778(themselv)s 3(es)k 4715(stationed)s 5490(at)s 5690(the)s
+1440 -12390(border)m 8(,)k 2052(perhaps)s 2721(e)s 5(v)k 3(en)k
+3139(on)s 3389(the)s 3682(\207re)s 5(w)k 2(all)k
+4332(itself.)s 1840 -12701(Masters)m 2570(and)s 2960(sla)s 4(v)k 3(es)k
+3540(will)s 3951(set)s 4273(the)s 160 fnt82 4618 -12699(AA)m
+200 fnt82 4950 -12701(\210ag)m 5351(on)s 5653(an)s 3(y)k
+1440 -12941(response)m 2234(whose)s 2841(answer)s 3502(section)s 4163(contains)s
+4924(only)s 5377(RRsets)s 1440 -13181(from)m 1884(authoriti)s 5(v)k 3(e)k
+2795(zones.)s 3405(The)s 160 fnt82 3772 -13179(AA)m 200 fnt82
+4059 -13181(\210ag)m 4415(will)s 4781(be)s 5026(clear)s 5468(if)s
+5646(an)s 3(y)k 1440 -13421(RRset)m 1985(in)s 2199(the)s
+2501(answer)s 3123(section)s 3745(came)s 4223(from)s 4669(the)s
+4971(the)s 5273(\205cache,)s 14(\206)k gsave
+1440 -14114 translate
+200 fnt82 0.0 0.0 0.0 setrgbcolor 1134 0 0 0 200 240 50 LoutGraphic
+gsave
+0 0 moveto xsize 0 lineto stroke
+grestore
+
+grestore
+102 fnt82 0.0 0.0 0.0 setrgbcolor
+1440 -14295(1)m 160 fnt82 1491 -14366(No,)m 1766(we')s 8(re)k
+2161(not)s 2405(going)s 2809(to)s 2973(name)s 3359(names.)s
+200 fnt82 6300 -1576(which)m 6837(is)s 7019(what)s 7456(we)s
+7738(call)s 8074(the)s 8367(portion)s 8993(of)s 9209(the)s
+160 fnt82 9502 -1574(DNS)m 200 fnt82 9870 -1576(name)m 10351(space)s
+6300 -1816(that)m 6669(is)s 6872(outside)s 7518(all)s 7787(of)s
+8024(a)s 8183(serv)s 3(er')k 11(s)k 8868(zones)s
+9392(of)s 9629(authority)s 13(.)k 10506(If)s 10709(a)s
+6300 -2056(serv)m 3(er)k 6846(has)s 7175(no)s 7439(zones)s
+7956(of)s 8186(authority)s 13(,)k 9006(then)s 9413(all)s
+9675(of)s 9905(its)s 10156(answers)s 6300 -2296(will)m 6668(be)s
+6915(nonauthoritati)s 5(v)k 3(e)k 8271(since)s 8738(all)s
+8995(it)s 9164(has)s 9488(is)s 9679(a)s 9826(cache.)s
+10437(This)s 6300 -2536(kind)m 6725(of)s 6961(serv)s 3(er)k
+7513(is)s 7715(sometimes)s 8635(called)s 9179(a)s 9337(\205caching)s
+10114(only\206)s 10627(or)s 6300 -2776(\205forw)m 2(arding\206)k 7409(serv)s 3(er)k 11(.)k
+200 fnt84 6300 -3317(4.6)m 6550(.)s 6700(F)s 5(orwarding)k
+7764(-vs-)s 8123(Recursion)s 200 fnt82 6300 -3734(When)m 6834(a)s
+6980(name)s 7469(serv)s 3(er)k 8009(recei)s 5(v)k 3(es)k
+8709(a)s 8855(query)s 9367(for)s 9657(data)s 10046(it)s
+10214(doesn')s 3(t)k 6300 -3974(ha)m 4(v)k 3(e,)k
+6792(it)s 6975(can)s 7324(either)s 7849(send)s 8287(back)s
+8736(an)s 8997(error)s 9456(response)s 10225(\(if)s 10485(it)s
+10668(is)s 6300 -4214(authoritati)m 5(v)k 3(e)k 7379(for)s
+7693(the)s 8018(name')s 11(s)k 8663(zone,)s 9171(it)s
+9363(kno)s 5(ws)k 9961(that)s 10341(either)s 6300 -4454(the)m
+6637(name)s 7162(or)s 7422(data)s 7847(doesn')s 3(t)k
+8524(e)s 3(xist\),)k 9106(send)s 9565(back)s 10035(a)s
+10217(referral)s 6300 -4694(\(if)m 6563(running)s 7260(in)s 7491(\205nonrecursi)s 5(v)k 3(e)k
+8675(mode\206)s 9282(as)s 9523(the)s 9842(root)s 10239(serv)s 3(ers)k
+6300 -4934(all)m 6566(do,)s 6884(or)s 7118(if)s 7307(the)s
+160 fnt82 7618 -4932(RD)m 200 fnt82 7907 -4934(\210ag)m 8274(is)s
+8474(clear)s 8927(in)s 9150(the)s 9461(query\),)s 10099(or)s
+10333(it)s 10511(can)s 6300 -5174(forw)m 2(ard)k 6970(the)s
+7255(query)s 13(.)k 7838(This)s 8234(last)s 8551(possibility)s
+9422(is)s 9596(of)s 9804(interest)s 10430(to)s 10627(us)s
+6300 -5414(in)m 6508(our)s 6827(security)s 7509(study)s 13(,)k
+8031(because)s 8713(of)s 8932(what)s 9372(will)s 9734(happen)s
+10363(when)s 6300 -5654(some)m 6781(response)s 7538(\207nally)s 8108(comes)s
+8677(back.)s 9214(F)s 3(orw)k 2(arding)k 10200(is)s
+10393(not)s 10709(a)s 6300 -5894(three-party)m 7239(transaction)s 8178(\211)s
+8345(a)s 8500(forw)s 2(arded)k 9383(query)s 9904(results)s
+10489(in)s 10711(a)s 6300 -6134(response)m 7068(to)s 7295(the)s
+7610(forw)s 2(arder)k 8464(who)s 8880(must)s 9339(then)s
+9754(complete)s 10555(the)s 6300 -6374(original)m 6984(transaction)s 7921(by)s
+8186(forw)s 2(arding)k 9134(the)s 9442(response)s 10203(back)s
+10644(to)s 6300 -6614(the)m 6593(originator)s 11(.)k 160 fnt82
+6700 -6923(BIND)m 200 fnt82 7139 -6925(tak)m 2(es)k 7595(its)s
+7832(forw)s 2(arding)k 8765(duties)s 9290(one)s 9628(step)s
+9998(further)s 8(,)k 10631(as)s 6300 -7165(an)m 6555(optimization)s
+7628(attempt:)s 8346(It)s 8534(caches)s 9130(all)s 9395(the)s
+9705(RRsets)s 10335(in)s 10557(the)s 6300 -7405(forw)m 2(arded)k
+7190(response.)s 8060(This)s 8488(promiscuity)s 9513(is)s 9719(the)s
+10036(source)s 10629(of)s 6300 -7645(most)m 6738(of)s 160 fnt82
+6955 -7643(BIND)m 200 fnt82 7344 -7645(')m 11(s)k 7527(bad)s
+7866(reputation)s 8724(in)s 8930(both)s 9336(the)s 9630(operations)s
+10510(and)s 6300 -7885(the)m 6609(security)s 7304(\207elds.)s 7901(Other)s
+8420(serv)s 3(ers)k 9045(are)s 9353(free)s 9727(to)s
+9948(put)s 10269(almost)s 6300 -8125(an)m 3(ything)k 7062(into)s
+7439(the)s 7749(response,)s 8562(e)s 5(v)k 3(en)k
+8997(if)s 9185(it)s 9362(has)s 9694(nothing)s 10371(to)s
+10593(do)s 6300 -8365(with)m 6687(the)s 6963(query)s 13(.)k
+7537(As)s 7791(sho)s 5(wn)k 8340(in)s 8528([)s
+8594(Bel95a)s 9158(])s 9224(,)s 9307(this)s 9627(has)s
+9925(disasterous)s 6300 -8605(ef)m 5(fects)k 6873(on)s 7123(security)s 13(.)k
+6700 -8916(It)m 6886(is)s 7083(w)s 2(orth)k 7611(noting)s
+8186(that)s 8549(the)s 8857(\207rst)s 9231(query)s 9750(handled)s
+10446(by)s 10711(a)s 6300 -9156(forw)m 2(arding)k 7255(or)s
+7493(recursi)s 5(v)k 3(e)k 8285(name)s 8788(serv)s 3(er)k
+9342(for)s 9646(a)s 9806(gi)s 5(v)k 3(en)k
+10313(RRset)s 6300 -9396(is)m 6511(lik)s 2(ely)k 7041(to)s
+7275(result,)s 7845(ultimately)s 13(,)k 8767(in)s 9001(it)s
+9190(forw)s 2(arding)k 10152(back)s 10607(an)s 6300 -9636(answer)m
+6958(obtained)s 7739(from)s 8221(an)s 8504(authoritati)s 5(v)k 3(e)k
+9596(name)s 10122(serv)s 3(er)k 10699(\211)s 6300 -9876(thus)m
+6687(the)s 160 fnt82 6985 -9874(AA)m 200 fnt82 7270 -9876(\210ag)m
+7624(will)s 7988(be)s 8231(set)s 8506(in)s 8716(the)s
+9014(response,)s 9815(e)s 5(v)k 3(en)k 10238(though)s
+6300 -10116(the)m 6635(forw)s 2(arder)k 7509(is)s 7733(not)s
+8080(itself)s 8568(authoritati)s 5(v)k 3(e)k 9657(for)s
+9981(the)s 10316(name.)s 6300 -10356(Subsequent)m 7264(queries)s 7883(to)s
+8083(the)s 8371(same)s 8824(name)s 9300(serv)s 3(er)k
+9827(for)s 10104(the)s 10392(same)s 6300 -10596(RRset)m 6850(will)s
+7223(probably)s 7996(be)s 8248(satis\207ed)s 8963(from)s 9414(the)s
+9721(cache,)s 10287(and)s 10639(in)s 6300 -10836(that)m 6652(case)s
+7047(the)s 160 fnt82 7344 -10834(AA)m 200 fnt82 7628 -10836(\210ag)m
+7981(will)s 8344(not)s 8653(be)s 8895(set)s 9169(in)s
+9378(the)s 9675(response.)s 10475(Y)s 22(ou)k 6300 -11076(can)m
+6625(see)s 6927(this)s 7263(in)s 7467(action)s 8002(using)s
+8483(the)s 160 fnt82 8775 -11074(ISI)m 200 fnt84 9018 -11077(dig)m
+200 fnt82 9333 -11076(tool)m 9692(from)s 10128(the)s 160 fnt82
+10420 -11074(BIND)m 200 fnt82 6300 -11316(kit.)m 200 fnt84 6300 -11816(4.7)m
+6550(.)s 6700(F)s 5(orwarding)k 7764(-vs-)s 8123(T)s 3(imeouts)k
+200 fnt82 6300 -12233(When)m 160 fnt82 6893 -12231(BIND)m 200 fnt82
+7282 -12233(')m 11(s)k 7531(resolv)s 3(er)k 8285(needs)s
+8855(to)s 9127(forw)s 2(ard)k 9872(a)s 10077(query)s 13(,)k
+10685(it)s 6300 -12473(chooses)m 6991(the)s 7295(ne)s 3(xt)k
+7696(name)s 8188(serv)s 3(er)k 8731(address)s 9388(from)s
+9836(its)s 10084(statically)s 6300 -12713(con\207gured)m 7229(list,)s 7597(sends)s
+8115(the)s 8434(query)s 13(,)k 9001(w)s 2(aits)k
+9494(a)s 9658(short)s 10132(time)s 10561(for)s 6300 -12953(an)m
+6549(answer)s 8(,)k 7215(chooses)s 7906(the)s 8210(ne)s 3(xt)k
+8611(name)s 9103(serv)s 3(er)k 9646(address,)s 10353(sends)s
+6300 -13193(and)m 6636(w)s 2(aits,)k 7151(and)s 7487(so)s
+7712(on.)s 160 fnt82 8060 -13191(BIND)m 200 fnt82 8449 -13193(')m 11(s)k
+8629(timeouts)s 9362(are)s 9652(f)s 2(airly)k 10128(short;)s
+10679(It)s 6300 -13433(will)m 6666(often)s 7132(send)s 7554(a)s
+7699(query)s 8210(to)s 8422(name)s 8910(serv)s 3(er)k
+9449(#1,)s 9756(then)s 10156(to)s 10368(name)s 6300 -13673(serv)m 3(er)k
+6867(#2,)s 7202(then)s 7630(the)s 7958(response)s 8739(will)s
+9133(come)s 9649(in)s 9889(from)s 10361(name)s 6300 -13913(serv)m 3(er)k
+6834(#1,)s 7136(and)s 7476(the)s 7771(resolv)s 3(er)k
+8460(will)s 8821(close)s 9281(its)s 9520(sock)s 2(et)k
+10078(such)s 10495(that)s 6300 -14153(when)m 6805(name)s 7309(serv)s 3(er)k
+7864(#2')s 11(s)k 8269(response)s 9038(comes)s 9619(in)s
+9847(a)s 10008(second)s 10634(or)s 6300 -14393(so)m 6532(later)s
+6939(the)s 7237(k)s 2(ernel)k 7787(sends)s 8284(back)s
+8715(an)s 160 fnt82 8958 -14391(ICMP)m 200 fnt82 9402 -14393(Port)m
+9789(Unreachable)s 
+grestore
+
+pgsave restore
+showpage
+
+%%Page: ? 5
+%%BeginPageSetup
+%%PageResources: font Times-Roman
+%%+ font Times-Bold
+%%+ font Times-Italic
+/pgsave save def
+0.0500 dup scale 10 setlinewidth
+%%EndPageSetup
+gsave
+0 15840 translate
+0.0000 rotate
+
+grestore
+gsave
+0 15840 translate
+0.0000 rotate
+200 fnt82 0.0 0.0 0.0 setrgbcolor 1440 -1576(message.)m 2257(W)s 16(e)k
+2561(wish)s 2981(there)s 3422(were)s 3852(a)s 3984(w)s 2(ay)k
+4358(to)s 4557(ask)s 4866(the)s 5153(k)s 2(ernel)k
+5692(not)s 1440 -1816(to)m 1650(send)s 2070(these,)s 2583(other)s
+3047(than)s 3445(k)s 2(eeping)k 4129(the)s 4427(sock)s 2(et)k
+4988(open)s 5431(longer)s 1440 -2056(\(which)m 2060(w)s 2(ould)k
+2624(lead)s 3022(to)s 3244(resource)s 3984(starv)s 5(ation)k
+4830(among)s 5440(k)s 2(ernel)k 1440 -2296(protocol)m 2151(control)s
+2762(blocks.\))s 3445(Lengthening)s 4500(the)s 4790(timeout)s 5445(w)s 2(ould)k
+1440 -2536(lead)m 1812(to)s 2008(longer)s 2558(application-visible)s 4079(delays)s
+4628(when)s 5101(a)s 5230(statically)s 1440 -2776(con\207gured)m 2343(name)s
+2824(serv)s 3(er)k 3356(goes)s 3771(of)s 5(f)k
+4048(the)s 4341(air)s 8(,)k 4642(b)s 4(ut)k
+4943(life)s 5257(is)s 5439(full)s 5765(of)s 1440 -3016(hard)m
+1844(choices.)s 200 fnt84 1440 -3516(4.8)m 1690(.)s 1840(Query)s
+160 fnt84 2432 -3513(ID)m 200 fnt84 2609 -3516(s)m 2736(and)s
+160 fnt84 3108 -3513(UDP)m 200 fnt84 3485 -3516(P)m 4(orts)k
+200 fnt82 1440 -3933(Each)m 1898(query)s 2412(sent)s 2792(out)s
+3107(by)s 3367(a)s 3515(resolv)s 3(er)k 4212(will)s
+4581(come)s 5072(from)s 5519(some)s 160 fnt82 1440 -4171(UDP)m
+200 fnt82 1819 -4173(port)m 2201(on)s 2462(some)s 2943(address)s
+3600(of)s 3827(the)s 4131(resolv)s 3(er')k 11(s)k
+4961(host,)s 5404(and)s 5753(its)s 1440 -4413(header)m 2017(will)s
+2373(contain)s 3006(a)s 3141(unique)s 3731(\(in)s 3999(the)s
+4289(conte)s 3(xt)k 4919(of)s 5132(the)s 5422(source)s
+1440 -4653(address)m 2068(and)s 2388(port)s 2741(number\))s 3448(query)s
+160 fnt82 3934 -4651(ID)m 200 fnt82 4102 -4653(.)m 160 fnt82
+4234 -4651(UDP)m 200 fnt82 4584 -4653(port)m 4937(numbers)s 5655(and)s
+160 fnt82 1440 -4891(DNS)m 200 fnt82 1806 -4893(query)m 160 fnt82
+2308 -4891(ID)m 200 fnt82 2476 -4893(s)m 2601(are)s 2891(both)s
+3294(unsigned)s 4062(16)s 4310(bit)s 4568(quantities,)s 5439(gi)s 5(ving)k
+1440 -5133(a)m 1572(range)s 2058(from)s 2489(0)s 2633(to)s
+2832(65535)s 3376(for)s 3652(each.)s 4160(Port)s 4536(numbers)s
+5266(could)s 5753(be)s 1440 -5373(conserv)m 3(ed)k 2295(and)s
+2634(reused)s 3204(by)s 3455(the)s 3749(resolv)s 3(er)k 8(,)k
+4479(b)s 4(ut)k 160 fnt82 4781 -5371(BIND)m 200 fnt82
+5221 -5373(currently)m 1440 -5613(opens)m 1971(a)s 2125(ne)s 5(w)k
+2518(sock)s 2(et)k 3090(for)s 3388(each)s 3818(query)s 13(,)k
+4375(and)s 4729(k)s 2(ernels)k 5367(tend)s 5776(to)s
+1440 -5853(use)m 1765(an)s 160 fnt82 2013 -5851(LR)m 6(U)k
+200 fnt82 2385 -5853(mechanism)m 3351(when)s 3843(assigning)s 4655(port)s
+5036(numbers)s 5782(to)s 1440 -6093(ne)m 5(w)k 1862(sock)s 2(ets.)k
+2590(The)s 2995(tuple)s 3488(<)s 200 fnt83 3600 -6092(addr)m 7(ess)k
+200 fnt82 4212 -6093(,)m 200 fnt83 4262 -6092(port)m 200 fnt82
+4594 -6093(,)m 200 fnt83 4644 -6092(query)m 160 fnt83 5097 -6090(ID)m
+200 fnt82 5265 -6093(>)m 5472(forms)s 1440 -6333(a)m 1594(unique)s
+2203(identi\207er)s 2987(that)s 3351(serv)s 3(ers)k 3976(can)s
+4318(use)s 4649(to)s 4870(k)s 2(eep)k 5310(track)s
+5773(of)s 1440 -6573(queries)m 2109(in)s 2359(progress.)s 3228(Resolv)s 3(ers)k
+4104(should)s 4731(v)s 3(erify)k 5298(that)s 5691(the)s
+1440 -6813(query)m 160 fnt82 1944 -6811(ID)m 200 fnt82 2162 -6813(of)m
+2378(the)s 2671(response)s 3417(matches)s 4118(that)s 4466(of)s
+4682(their)s 5096(query)s 13(.)k 200 fnt84 1440 -7354(4.9)m
+1690(.)s 1840(Delegations,)s 2924(Zones,)s 3533(Domains,)s 4386(and)s
+4758(Subdomains)s 200 fnt82 1440 -7771(Strictly)m 2125(speaking,)s 2983(e)s 5(v)k 3(ery)k
+160 fnt82 3517 -7769(DNS)m 200 fnt82 3935 -7771(name)m 4466(is)s
+4698(a)s 4886(domain.)s 5684(All)s 1440 -8011(domains)m 2204(e)s 3(xcept)k
+2809(the)s 3141(root)s 3551(are)s 3882(also)s 4291(\205subdomains.)s 14(\206)k
+5594(An)s 3(y)k 1440 -8251(time)m 1832(a)s 1959(subdomain)s
+2873(is)s 3044(dele)s 3(g)k 1(ated)k 3841(to)s
+4035(some)s 4494(other)s 4942(master)s 5510(name)s 1440 -8491(serv)m 3(er)k 8(,)k
+2027(a)s 2178(\205zone)s 2705(cut\206)s 3099(is)s 3294(said)s
+3677(to)s 3895(e)s 3(xist.)k 4430(A)s 4637(zone)s
+5076(consists)s 5768(of)s 1440 -8731(all)m 1704(names)s 2278(from)s
+2731(a)s 2885(zone)s 3327(cut)s 3636(do)s 5(wnw)k 2(ard)k
+4537(to)s 4758(either)s 5276(terminal)s 1440 -8971(names)m 1983(\(sometimes)s
+2934(called)s 3443(\205leaf)s 3863(domains\206\))s 4727(or)s 4928(other)s 8(,)k
+5414(deeper)s 1440 -9211(zone)m 1866(cuts.)s 1840 -9522(The)m 2259(most)s
+2755(common)s 3562(case)s 4012(of)s 4287(a)s 4484(zone)s
+4969(be)s 3(gins)k 5595(at)s 5847(a)s 1440 -9762(subdomain)m
+2387(and)s 2747(has)s 3084(no)s 3356(zone)s 3804(cuts)s
+4196(beneath)s 4887(it.)s 5169(The)s 5551(most)s 1440 -10002(f)m 2(amous)k
+2120(zone)s 2592(is)s 2820(the)s 3159(root)s 3576(\(\205)s
+200 fnt84 3730 -10003(.)m 200 fnt82 3780 -10002(\206\))m 4030(which)s
+4613(has)s 4974(no)s 5270(terminal)s 1440 -10242(names,)m 2048(just)s
+2385(dele)s 3(g)k 1(ations.)k 1840 -10553(There)m 2391(are)s
+2720(tw)s 2(o)k 3104(vie)s 5(ws)k 3650(of)s
+3903(a)s 4078(dele)s 3(g)k 1(ation:)k 5045(The)s
+5442(parent)s 1440 -10793(zone,)m 1942(which)s 2505(has)s 2846(some)s
+160 fnt82 3342 -10791(NS)m 3585(RR)s 200 fnt82 3797 -10793(s)m
+3950(at)s 4169(the)s 4488(cut,)s 4857(and)s 5221(the)s
+5540(child)s 1440 -11033(zone,)m 1932(which)s 2485(has)s 2816(a)s
+2970(superset)s 3687(of)s 3919(those)s 160 fnt82 4405 -11031(NS)m
+4648(RR)s 200 fnt82 4860 -11033(s)m 5003(and)s 5357(also)s
+5743(an)s 160 fnt82 1440 -11271(SO)m 5(A)k 1793(RR)s
+200 fnt82 2005 -11273(.)m 2170(When)s 2711(we)s 3008(say)s
+3338(\205superset\206)s 4230(we)s 4527(mean)s 5023(that)s 5386(a)s
+5539(child)s 1440 -11513(will)m 1827(ha)s 4(v)k 3(e)k
+2274(at)s 2495(least)s 2936(the)s 160 fnt82 3257 -11511(NS)m
+3500(RR)s 200 fnt82 3712 -11513(s)m 3867(kno)s 5(wn)k
+4484(by)s 4762(its)s 5027(parent,)s 5652(and)s 1440 -11753(perhaps)m
+2118(some)s 2597(additional)s 160 fnt82 3452 -11751(NS)m 3695(RR)s
+200 fnt82 3907 -11753(s)m 4043(that)s 4400(the)s 4702(parent)s
+5258(does)s 5682(not)s 1440 -11993(kno)m 5(w)k 1929(about.)s
+200 fnt84 1440 -12493(4.)m 1590(10)s 1790(.)s 1940(Lame)s
+2477(Delegations)s 200 fnt82 1440 -12910(If)m 1705(a)s 1926(dele)s 3(g)k 1(ation)k
+160 fnt82 2884 -12908(NS)m 3127(RR)s 200 fnt82 3472 -12910(names)m
+4113(a)s 4334(host)s 4799(which)s 5419(is)s 5684(not)s
+1440 -13150(authoritati)m 5(v)k 3(e)k 2512(for)s 2819(the)s
+3137(zone,)s 3638(then)s 4056(that)s 4429(host)s 4836(when)s
+5343(queried)s 1440 -13390(nonrecursi)m 5(v)k 3(ely)k 2665(for)s
+2947(names)s 3505(in)s 3710(that)s 4058(zone)s 4484(will)s
+4843(answer)s 5456(with)s 5860(a)s 1440 -13630(dele)m 3(g)k 1(ation)k
+2302(to)s 2494(a)s 2619(higher)s 3165(\(that)s 3566(is,)s
+3785(closer)s 4296(to)s 4488(the)s 4768(root\))s 5192(authority)s 13(.)k
+1440 -13870(This)m 1847(is)s 2032(an)s 2273(error)s 2712(condition)s
+3518(as)s 3736(percei)s 5(v)k 3(ed)k 4554(by)s
+4807(the)s 5103(serv)s 3(er)k 5638(that)s 1440 -14110(forw)m 2(arded)k
+2341(a)s 2514(nonrecursi)s 5(v)k 3(e)k 3619(query)s
+4158(\211)s 4343(if)s 4549(a)s 4722(name)s 5238(serv)s 3(er)k
+5805(is)s 1440 -14350(listed)m 1931(in)s 2147(an)s 160 fnt82
+2396 -14348(NS)m 2639(RR)s 200 fnt82 2851 -14350(,)m 2962(it)s
+3133(is)s 3326(supposed)s 4129(to)s 4345(ha)s 4(v)k 3(e)k
+4775(the)s 5079(zone.)s 5616(It)s 5798(is)s 6300 -1576(reasonable)m
+7193(to)s 7391(declare)s 8007(f)s 2(ailure)k 8566(at)s
+8752(this)s 9082(point,)s 9585(though)s 10183(perhaps)s 6300 -1816(a)m
+6438(bit)s 6698(se)s 5(v)k 3(ere.)k 160 fnt82
+6700 -2125(BIND)m 200 fnt82 7089 -2127(s)m 7207(from)s 7635(v)s 3(ersion)k
+8259(4.9)s 8550(ha)s 4(v)k 3(e)k 200 fnt84
+8960 -2128(syslog)m 200 fnt82 9469 -2127('ed)m 9764(the)s 10048(condition)s
+6300 -2367(and)m 6624(gone)s 7048(on)s 7284(to)s 7475(try)s
+7732(the)s 8011(other)s 8456(dele)s 3(g)k 1(ated)k
+9250(serv)s 3(ers.)k 9945(The)s 200 fnt84 10291 -2368(syslog)m
+200 fnt82 6300 -2607(v)m 4(olume)k 6949(generated)s 7777(by)s
+8032(this)s 8374(condition)s 9182(is)s 9369(the)s 9667(cause)s
+10163(of)s 10384(more)s 6300 -2847(than)m 6683(half)s 7032(the)s
+7315(questions)s 8107(we)s 8379(see)s 8672(about)s 160 fnt82
+9155 -2845(BIND)m 200 fnt82 9584 -2847(from)m 10011(ne)s 5(w)k
+10378(name)s 6300 -3087(serv)m 3(er)k 6835(administrators.)s 8125(The)s
+8488(only)s 8896(w)s 2(ay)k 9279(to)s 9487(\207x)s
+9751(the)s 10047(condition)s 6300 -3327(is)m 6507(to)s 6737(get)s
+7055(someone)s 7838(to)s 8068(edit)s 8441(the)s 8759(dele)s 3(g)k 1(ation)k
+9659(to)s 9889(remo)s 3(v)k 3(e)k 10555(the)s
+6300 -3567(nonauthoritati)m 5(v)k 3(e)k 7714(name)s 8262(serv)s 3(er)k 8(,)k
+8903(or)s 9186(to)s 9458(get)s 9818(someone)s 10643(to)s
+6300 -3807(mak)m 2(e)k 6837(the)s 7188(name)s 7727(serv)s 3(er)k
+8317(authoritati)s 5(v)k 3(e.)k 9522(Either)s 10116(w)s 2(ay)k
+10554(it')s 11(s)k 6300 -4047(not)m 6637(something)s 7549(the)s
+7874(detecting)s 8685(serv)s 3(er')k 11(s)k 9381(administrator)s
+10523(can)s 6300 -4287(do)m 6569(an)s 3(ything)k 7333(about)s
+7845(directly;)s 8576(we)s 8877(hope)s 9334(that)s 9701(the)s
+10013(continued)s 200 fnt84 6300 -4528(syslog)m 200 fnt82 6891 -4527(v)m 4(olume)k
+7567(will)s 7958(lead)s 8371(to)s 8608(more)s 9099(hate)s
+9512(mail)s 9947(being)s 10472(sent)s 6300 -4767(to)m 6541(the)s
+6870(administrators)s 8093(of)s 8345(brok)s 2(en)k 8983(zones,)s
+9572(thus)s 9990(ultimately)s 6300 -5007(leading)m 6941(to)s 7151(a)s
+7294(decline)s 7923(in)s 8133(the)s 8431(number)s 9095(of)s
+9316(brok)s 2(en)k 9923(zones.)s 10531(W)s 16(e)k
+6300 -5247(ha)m 4(v)k 3(e)k 6719(been)s 7145(accused)s
+7824(of)s 8040(optimism)s 8842(in)s 9047(this)s 9384(matter)s 11(.)k
+200 fnt84 6300 -5788(4.)m 6450(11)s 6650(.)s 6800(Glue)s
+200 fnt82 6300 -6167(When)m 6836(transmitting)s 7857(a)s 8005(zone)s
+8441(via)s 8744(a)s 160 fnt82 8892 -6165(TCP)m 200 fnt82
+9243 -6167(\205zone)m 9767(transfer)s 8(,)k 14(\206)k 10549(the)s
+6300 -6407(general)m 6942(rule)s 7308(is)s 7497(to)s 7709(send)s
+8131(only)s 8543(the)s 8843(RRsets)s 9463(whose)s 10029(names)s
+10594(lie)s 6300 -6647(within)m 6852(the)s 7138(zone)s 7557(being)s
+8043(transferred,)s 8996(which)s 9526(is)s 9701(to)s 9899(say)s
+10207(starting)s 6300 -6887(from)m 6791(the)s 7138(initial)s 7705(zone)s
+8185(cut,)s 8582(and)s 8974(proceeding)s 9963(do)s 5(wnw)k 2(ard)k
+6300 -7127(\(a)m 3(w)k 2(ay)k 6838(from)s 7282(the)s
+7582(root\))s 8026(to)s 8238(include)s 8881(all)s 9136(names)s
+9701(which)s 10245(are)s 10544(not)s 6300 -7367(further)m 6919(dele)s 3(g)k 1(ated.)k
+7805(There)s 8347(is)s 8557(an)s 8823(e)s 3(xception)k
+9672(to)s 9905(this,)s 10320(called)s 6300 -7607(\205glue.)m 14(\206)k
+6967(An)s 3(y)k 7370(address)s 8028(records)s 8675(\()s
+160 fnt82 8741 -7605(A)m 8896(RR)s 200 fnt82 9108 -7607(s\))m
+9313(which)s 9862(are)s 10166(referred)s 6300 -7847(to)m 6521(by)s
+6787(an)s 160 fnt82 7041 -7845(NS)m 7284(RR)s 200 fnt82
+7562 -7847(inside)m 8103(the)s 8412(zone)s 8854(\(at)s 9129(the)s
+9438(initial)s 9967(cut)s 10276(or)s 10508(an)s 3(y)k
+6300 -8087(do)m 5(wnw)k 2(ard)k 7171(cuts\))s 7593(must)s
+8016(be)s 8240(included,)s 9012(e)s 5(v)k 3(en)k
+9416(if)s 9573(the)s 3(y)k 9949(lie)s 10183(beneath)s
+6300 -8327(one)m 6638(of)s 6854(the)s 7147(do)s 5(wnw)k 2(ard)k
+8032(zone)s 8458(cuts.)s 6700 -8638(If)m 6943(this)s 7341(information)s
+8392(is)s 8635(not)s 9001(included)s 9798(in)s 10064(the)s
+10418(zone)s 6300 -8878(transfer)m 8(,)k 7002(then)s 7399(referral)s
+8036(responses)s 8863(w)s 2(on')k 3(t)k 9377(be)s
+9619(able)s 10004(to)s 10213(include)s 6300 -9118(those)m 6785(addresses)s
+7611(in)s 7831(their)s 8260(additional)s 9121(data)s 9517(sections.)s
+10322(In)s 10553(the)s 6300 -9358(absence)m 6978(of)s 7193(that)s
+7540(additional)s 8385(data,)s 8815(the)s 9107(name)s 9587(serv)s 3(ers)k
+10195(will)s 10553(not)s 6300 -9598(be)m 6543(reachable)s 7359(e)s 3(xcept)k
+7930(by)s 8185(serv)s 3(ers)k 8799(who)s 9198(ha)s 4(v)k 3(e)k
+9622(the)s 9920(zone)s 10351(\211)s 10506(and)s 6300 -9838(that')m 11(s)k
+6792(not)s 7109(v)s 3(ery)k 7522(useful.)s 8170(It)s
+8353(is)s 8547(important)s 9383(that)s 9743(a)s 9893(serv)s 3(er)k
+10437(only)s 6300 -10078(send)m 6705(\(or)s 6977(accept\))s 7590(rele)s 5(v)k 5(ant)k
+8260(glue)s 8643(during)s 9204(zone)s 9620(transfers,)s 10393(since)s
+6300 -10318(otherwise)m 7147(this)s 7508(becomes)s 8278(an)s 8540(easy)s
+8967(w)s 2(ay)k 9371(for)s 9677(your)s 10117(cache)s
+10643(to)s 6300 -10558(become)m 6969(polluted.)s 240 fnt84 6300 -11246(5.)m
+6600(What)s 7232(W)s 15(e)k 7623(Ha)s 6(v)k 2(e)k
+8207(Fixed)s 160 fnt82 6300 -11623(BIND)m 200 fnt82 6689 -11625(s)m
+6822(from)s 7265(v)s 3(ersion)k 7904(4.9)s 8210(ha)s 4(v)k 3(e)k
+8635(plugged)s 9334(a)s 9478(lot)s 9744(of)s 9966(holes)s
+10442(with)s 6300 -11865(respect)m 6912(to)s 7117(earlier)s 7673(v)s 3(ersions.)k
+8483(An)s 8777(incomplete)s 9711(list)s 10003(follo)s 5(ws:)k
+200 fnt84 6300 -12406(5.1)m 6550(.)s 6700(Cache)s 7281(T)s 18(agging)k
+160 fnt82 6300 -12821(BIND)m 200 fnt82 6758 -12823(no)m 5(w)k
+7166(maintains)s 8008(for)s 8309(each)s 8742(cached)s 160 fnt82
+9363 -12821(RR)m 200 fnt82 9644 -12823(a)m 9801(\205credibility\206)s 6300 -13063(le)m 5(v)k 3(el)k
+6758(sho)s 5(wing)k 7509(whether)s 8230(the)s 8553(data)s
+8964(came)s 9463(from)s 9930(a)s 10098(zone,)s 10604(an)s
+6300 -13303(authoritati)m 5(v)k 3(e)k 7366(answer)s 8(,)k
+8040(an)s 8297(authority)s 9085(section,)s 9767(or)s 10002(additional)s
+6300 -13543(data)m 6681(section.)s 7394(When)s 7920(a)s 8058(more)s
+8517(credible)s 9207(RRset)s 9743(comes)s 10301(in,)s 10556(the)s
+6300 -13783(old)m 6631(one)s 6995(is)s 7203(completely)s 8163(wiped)s
+8726(out.)s 9157(Older)s 160 fnt82 9686 -13781(BIND)m 200 fnt82
+10075 -13783(s)m 10228(blindly)s 6300 -14023(aggre)m 3(g)k 1(ated)k
+7228(data)s 7618(from)s 8064(all)s 8321(sources,)s 9026(paying)s
+9628(no)s 9887(attention)s 10642(to)s 6300 -14263(the)m 6593(maxim)s
+7196(that)s 7544(some)s 8014(sources)s 8660(are)s 8952(better)s
+9454(than)s 9847(others.)s 
+grestore
+
+pgsave restore
+showpage
+
+%%Page: ? 6
+%%BeginPageSetup
+%%PageResources: font Times-Roman
+%%+ font Times-Bold
+%%+ font Symbol
+%%+ font Times-Italic
+/pgsave save def
+%%IncludeResource: font Symbol
+/fnt78 { /Symbol LoutFont } def
+0.0500 dup scale 10 setlinewidth
+%%EndPageSetup
+gsave
+0 15840 translate
+0.0000 rotate
+
+grestore
+gsave
+0 15840 translate
+0.0000 rotate
+200 fnt82 0.0 0.0 0.0 setrgbcolor 1840 -1576(Each)m 160 fnt82 2278 -1574(RR)m
+200 fnt82 2530 -1576(also)m 2890(has)s 3195(the)s 3478(address)s
+4114(of)s 4320(the)s 4603(name)s 5074(serv)s 3(er)k
+5596(who)s 1440 -1816(sent)m 1803(it)s 1956(to)s 2154(us.)s
+2424(This)s 2821(can)s 3140(be)s 3371(seen)s 3767(in)s
+3965(cache)s 4460(dump)s 4958(when)s 5433(you')s 10(re)k
+1440 -2056(looking)m 2121(at)s 2335(some)s 2826(bad)s 3185(data)s
+3587(and)s 3946(w)s 2(ondering)k 4868(ho)s 5(w)k
+5278(it)s 5459(got)s 5785(to)s 1440 -2296(you.)m 200 fnt84
+1440 -2837(5.2)m 1690(.)s 1840(Additional)s 2798(Data)s 3258(Pr)s 3(omiscuity)k
+200 fnt82 1440 -3254(W)m 16(e)k 1763(accelerate)s 2618(the)s
+160 fnt82 2924 -3252(TTL)m 200 fnt82 3278 -3254(decline)m 3915(for)s
+4210(data)s 4604(which)s 5154(arri)s 5(v)k 3(ed)k
+5772(as)s 1440 -3494(additional)m 2293(data.)s 2781(W)s 16(e)k
+3098(are)s 3397(considering)s 4383(not)s 4695(caching)s 5371(it)s
+5538(at)s 5738(all)s 1440 -3734(other)m 1894(than)s 2282(as)s
+2492(necessary)s 3309(for)s 3586(forw)s 2(arding)k 4514(the)s
+4802(response)s 5543(\211)s 5688(see)s 1440 -3974(belo)m 5(w)k 13(.)k
+200 fnt84 1440 -4474(5.3)m 1690(.)s 1840(Irr)s 3(ele)k 3(v)k 2(ant)k
+2743(Answers)s 200 fnt82 1440 -4852(W)m 16(e)k 1758(check)s
+2280(the)s 2581(response)s 3335(to)s 3548(ensure)s 4125(that)s
+4481(all)s 4737(RRsets)s 5358(in)s 5571(each)s 1440 -5092(section)m
+2091(ha)s 4(v)k 3(e)k 2548(names)s 3144(and)s
+3520(types)s 4028(that)s 4414(mak)s 2(e)k 4931(sense)s
+5449(in)s 5692(the)s 1440 -5332(conte)m 3(xt)k 2130(of)s
+2403(the)s 2753(query)s 3314(and)s 3709(answer)s 4379(sections.)s
+5176(Including)s 1440 -5572(spurious)m 2200(additional)s 3081(data)s 3497(w)s 2(on')k 3(t)k
+4042(automatically)s 5209(pollute)s 5847(a)s 1440 -5812(cache)m 1973(an)s 3(y)k
+2339(more;)s 2884(As)s 3186(of)s 160 fnt82 3433 -5810(BIND)m
+200 fnt82 3903 -5812(4.9.3)m 4384(it)s 4575(is)s 4788(necessary)s
+5641(that)s 1440 -6052(the)m 1750(answer)s 2380(section)s 3010(contain)s
+3663(a)s 160 fnt82 3818 -6050(CN)m 5(AME)k 4428(RR)s
+200 fnt82 4707 -6052(to)m 4929(introduce)s 5748(an)s 1440 -6292(arbitrary)m
+2158(name,)s 2673(after)s 3070(which)s 3591(it')s 11(s)k
+3867(b)s 4(usiness)k 4571(as)s 4770(usual)s 5224(for)s
+5490(cache)s 1440 -6532(polluters.)m 2294(This)s 2706(is)s 2896(the)s
+3197(best)s 3575(we)s 3865(can)s 4199(do)s 4457(without)s
+5124(a)s 5270(protocol)s 1440 -6772(change.)m 200 fnt84 1440 -7313(5.4)m
+1690(.)s 1840(Nonmatching)s 3042(Answers)s 200 fnt82 1440 -7730(Belie)m 5(v)k 3(e)k
+2132(it)s 2335(or)s 2594(not,)s 2992(older)s 160 fnt82
+3494 -7728(BIND)m 200 fnt82 3883 -7730(s)m 4053(did)s 4401(not)s
+4749(check)s 5306(that)s 5697(the)s 1440 -7970(answer)m 2099(name)s
+2626(matched)s 3396(the)s 3735(query)s 4285(name.)s 4912(No)s 5(w)k 13(,)k
+5428(within)s 1440 -8210(the)m 1760(limits)s 2289(of)s 160 fnt82
+2532 -8208(CN)m 5(AME)k 200 fnt82 3102 -8210(s)m 3256(and)s
+3621(wildcard)s 4394(answers,)s 160 fnt82 5161 -8208(BIND)m 200 fnt82
+5627 -8210(will)m 1440 -8450(insist)m 1935(that)s 2309(a)s 2473(response)s
+3245(answers)s 3961(the)s 4280(right)s 4732(question.)s 5583(This)s
+1440 -8690(error)m 1907(w)s 2(as)k 2295(particularly)s 3292(pernicious)s
+4202(with)s 4637(respect)s 5280(to)s 5516(some)s 1440 -8930(of)m
+1686(the)s 2009(name)s 200 fnt78 2520 -8935(\253)m 200 fnt82
+2808 -8930(address)m 3484(symmetry)s 4360(checking,)s 5209(since)s 5697(the)s
+1440 -9170(answer')m 11(s)k 2170(RRname)s 2902(sets)s 3234(the)s
+3512(name)s 3978(in)s 4168(the)s 4446(resolv)s 3(er')k 11(s)k
+5250(response)s 1440 -9410(structure,)m 2249(which)s 2800(meant)s 3350(that)s
+3712(callers)s 4293(of)s 200 fnt84 4523 -9411(gethostbyname\(\))m 200 fnt82
+1440 -9650(could)m 1991(end)s 2387(up)s 2695(comparing)s 3655(a)s
+3851(foreign)s 4534(name)s 5073(to)s 5336(another)s 1440 -9890(foreign)m
+2065(name.)s 200 fnt84 1440 -10431(5.5)m 1690(.)s 1840(Logging)s
+200 fnt82 1440 -10848(Man)m 3(y)k 1961(of)s 2186(the)s
+2488(detectable)s 3352(conditions)s 4241(indicating)s 5096(a)s 5243(probable)s
+1440 -11088(break-in)m 2164(attempt)s 2821(were)s 3268(in)s 3484(the)s
+3788(past)s 4169(either)s 4682(not)s 4998(detected,)s 5771(or)s
+1440 -11328(treated)m 2019(as)s 2223(protocol)s 2926(errors)s 3428(\(which)s
+4020(is)s 4191(to)s 4385(say)s 13(,)k 4726(silently)s
+5350(w)s 2(ork)k 2(ed)k 1440 -11568(around\).)m 160 fnt82
+2195 -11566(BIND)m 200 fnt82 2619 -11568(no)m 5(w)k 2993(f)s 2(airly)k
+3456(shrieks)s 4054(whene)s 5(v)k 3(er)k 4855(it)s
+5000(has)s 5300(e)s 5(v)k 3(en)k 5703(the)s
+1440 -11808(slightest)m 2147(cause)s 2633(for)s 2910(alarm,)s 3457(which)s
+3989(is)s 4166(a)s 4299(mix)s 3(ed)k 4839(blessing)s
+5536(since)s 1440 -12048(the)m 1748(v)s 4(olume)k 2407(of)s
+2638(its)s 2890(complaints)s 3828(is)s 4025(so)s 4267(high)s
+4687(that)s 5050(most)s 5502(name)s 1440 -12288(serv)m 3(er)k
+1972(administrators)s 3159(pay)s 3497(no)s 3747(attention.)s 1840 -12599(The)m
+200 fnt84 2235 -12600(syslog)m 200 fnt82 2829 -12599(data)m 3245(is)s
+3462(of)s 3713(greatest)s 4415(interest)s 5084(during)s 5690(the)s
+1440 -12839(post)m 1834(mortem)s 2515(analysis)s 3217(of)s 3445(a)s
+3595(break-in)s 4320(attempt.)s 5078(The)s 5450(log)s 5767(of)s
+1440 -13079(unsolicited)m 2394(responses,)s 3298(for)s 3611(e)s 3(xample,)k
+4413(can)s 4770(sho)s 5(w)k 5267(attempts)s 1440 -13319(at)m
+1659(cache)s 2187(pollution)s 2983(during)s 3580(the)s 3899(early)s
+4372(stages)s 4933(\211)s 5109(before)s 5693(the)s 1440 -13559(attack)m 2(ers)k
+2217(switched)s 2998(to)s 3227(whate)s 5(v)k 3(er)k
+4022(technology)s 4982(actually)s 5685(got)s 1440 -13799(them)m 1905(in,)s
+2177(or)s 2410(set)s 2697(of)s 5(f)k 2991(your)s
+3424(alarms,)s 4070(or)s 4303(whate)s 5(v)k 3(er)k 11(.)k
+5180(Be)s 5468(a)s 3(w)k 2(are)k 1440 -14039(while)m
+1979(e)s 3(xamining)k 2914(these)s 3419(logs)s 3848(that)s
+4243(some)s 4760(systems)s 5486(\(most)s 1440 -14279(notably)m 2118(SunOS\))s
+2830(cannot)s 3441(cause)s 3962(pack)s 2(ets)k 4636(to)s
+4871(come)s 5382(from)s 5849(a)s 6300 -1576(particular)m 7114(address)s
+7763(if)s 7937(the)s 3(y)k 8330(ha)s 4(v)k 3(e)k
+8752(more)s 9214(than)s 9610(one)s 9951(interf)s 2(ace)k
+10696(\211)s 6300 -1816(so)m 6540(if)s 6724(you')s 10(re)k
+7297(on)s 7560(the)s 7866(wrong)s 8439(side)s 8822(of)s
+9051(a)s 9202(multihomed)s 10228(SunOS)s 6300 -2056(name)m 6845(serv)s 3(er)k 8(,)k
+200 fnt83 7483 -2055(all)m 200 fnt82 7807 -2056(of)m 8087(its)s
+8388(responses)s 9275(will)s 9698(appear)s 10342(to)s 10611(be)s
+6300 -2296(\205unsolicited.)m 14(\206)k 200 fnt84 6300 -2796(5.6)m 6550(.)s
+6700(Glue)s 160 fnt82 6300 -3173(BIND)m 200 fnt82 6689 -3175(s)m
+6854(from)s 7329(v)s 3(ersion)k 8000(4.9)s 8338(restrict)s
+8976(glue)s 9407(to)s 9650(just)s 10025(the)s 160 fnt82
+10356 -3173(A)m 10511(RR)s 200 fnt82 10723 -3175(s)m 6300 -3415(under)m
+6841(the)s 7171(dele)s 3(g)k 1(ation)k 8083(point,)s
+8630(whereas)s 9368(pre)s 5(vious)k 10136(v)s 3(ersions)k
+6300 -3655(included)m 7057(all)s 7326(the)s 160 fnt82 7640 -3653(A)m
+7795(RR)s 200 fnt82 8007 -3655(s)m 8155(referred)s 8854(to)s
+9080(by)s 9351(a)s 9510(zone')s 11(s)k 160 fnt82
+10089 -3653(NS)m 10332(RR)s 200 fnt82 10544 -3655(s)m 10692(\211)s
+6300 -3895(e)m 5(v)k 3(en)k 6735(those)s 7222(abo)s 3(v)k 3(e)k
+7759(the)s 8069(zone.)s 8612(By)s 8912(\205restrict\206)s 9705(we)s
+10004(mean)s 10502(that)s 160 fnt82 6300 -4133(BIND)m 200 fnt82
+6751 -4135(will)m 7122(be)s 7372(conserv)s 5(ati)k 5(v)k 3(e)k
+8426(both)s 8843(in)s 9060(what)s 9509(it)s 9681(generates)s
+200 fnt83 10493 -4134(and)m 6300 -4374(what)m 6726(it)s 6874(accepts)s
+200 fnt82 7470 -4375(.)m 7558(This)s 7950(may)s 8331(\210y)s
+8580(in)s 8773(the)s 9054(f)s 2(ace)k 9420(of)s
+9624(the)s 9905(Rob)s 4(ustness)k 6300 -4615(Principle)m 128 fnt82
+7018 -4526(1)m 200 fnt82 7139 -4615(of)m 7362([)s 7428(RFC1123)s
+8205(])s 8271(,)s 8378(b)s 4(ut)k 8686(the)s
+8986(old)s 9298(beha)s 4(viour)k 10148(w)s 2(as)k
+10512(just)s 6300 -4855(simply)m 200 fnt83 6892 -4854(wr)m 9(ong)k
+200 fnt82 7393 -4855(.)m 240 fnt84 6300 -5543(6.)m 6600(What)s
+7232(W)s 15(e)k 7623(Cannot)s 8441(Fix)s 200 fnt82
+6300 -5923(W)m 16(e)k 6660(are)s 7002(counting)s 7800(on)s
+8100(the)s 160 fnt82 8443 -5921(IETF)m 8878(DNSSEC)s 200 fnt82
+9587 -5923(ef)m 5(fort)k 10123(to)s 10378(bring)s 6300 -6163(us)m
+6585(a)s 160 fnt82 6781 -6161(DNS)m 200 fnt82 7207 -6163(protocol)m
+7979(re)s 5(vision)k 8723(that)s 9129(authoritati)s 5(v)k 3(ely)k
+10389(signs)s 6300 -6403(responses.)m 7235(W)s 8(ith)k 7687(that)s
+8047(in)s 8264(place)s 8745(we)s 9039(will)s 9410(all)s
+9670(stop)s 10064(w)s 2(orrying)k 6300 -6643(about)m 6789(attack)s 2(ers)k
+7538(who)s 7928(spoof)s 8417(their)s 8827(source)s 9392(addresses,)s
+10249(predict)s 6300 -6883(our)m 160 fnt82 6620 -6881(UDP)m 200 fnt82
+6992 -6883(port)m 7367(numbers)s 8107(and)s 8449(query)s 160 fnt82
+8957 -6881(ID)m 200 fnt82 9179 -6883(numbers,)m 9969(and)s 10311(so)s
+10542(on.)s 6300 -7123(Response)m 7107(data)s 7482(will)s 7835(be)s
+8067(objecti)s 5(v)k 3(ely)k 8987(v)s 3(eri\207able,)k
+9829(independent)s 6300 -7363(of)m 6526(whether)s 7227(it)s 7397(is)s
+7589(e)s 5(v)k 3(en)k 8017(a)s 8165(response)s
+8921(to)s 9136(some)s 9616(query)s 10130(we)s 10422(ha)s 4(v)k 3(e)k
+6300 -7603(sent.)m 6771(Until)s 160 fnt82 7231 -7601(DNSSEC)m 200 fnt82
+7891 -7603(is)m 8074(\207nished)s 8756(and)s 9095(in)s 9301(wide)s
+9739(use,)s 10105(there)s 10553(are)s 6300 -7843(some)m 6770(things)s
+7307(we')s 10(re)k 7799(just)s 8136(going)s 8641(to)s
+8846(ha)s 4(v)k 3(e)k 9265(to)s 9470(li)s 5(v)k 3(e)k
+9810(with.)s 200 fnt84 6300 -8384(6.1)m 6550(.)s 6700(Query)s
+160 fnt84 7292 -8381(ID)m 200 fnt84 7519 -8384(Pr)m 3(ediction)k
+200 fnt82 6300 -8801(W)m 8(ith)k 6760(only)s 7185(16)s
+7455(bits)s 7812(w)s 2(orth)k 8345(of)s 8581(query)s
+160 fnt82 9105 -8799(ID)m 200 fnt82 9343 -8801(and)m 9701(16)s
+9971(bits)s 10328(w)s 2(orth)k 6300 -9041(of)m 160 fnt82
+6543 -9039(UDP)m 200 fnt82 6938 -9041(port)m 7336(number)s 8(,)k
+8064(it')s 11(s)k 8383(hard)s 8814(not)s 9146(to)s
+9378(be)s 9643(predictable.)s 10653(A)s 6300 -9281(determined)m 7232(attack)s 2(er)k
+7895(can)s 8208(try)s 8466(all)s 8701(the)s 8981(numbers)s
+9704(in)s 9896(a)s 10021(v)s 3(ery)k 10409(short)s
+6300 -9521(time)m 6689(and)s 7013(can)s 7325(use)s 7626(patterns)s
+8291(deri)s 5(v)k 3(ed)k 8916(from)s 9339(e)s 3(xamination)k
+10356(of)s 10558(the)s 6300 -9761(freely)m 6800(a)s 4(v)k 5(ailable)k
+160 fnt82 7545 -9759(BIND)m 200 fnt82 7971 -9761(source)m 8527(code.)s
+9040(Ev)s 3(en)k 9484(if)s 9642(we)s 9911(had)s
+10236(a)s 10361(white)s 6300 -10001(noise)m 6777(generator)s 7585(to)s
+7797(help)s 8197(randomize)s 9094(our)s 9417(numbers,)s 10210(it')s 11(s)k
+10509(just)s 6300 -10241(too)m 6605(easy)s 7008(to)s 7213(try)s
+7484(them)s 7932(all.)s 200 fnt84 6300 -10782(6.1)m 6550(.)s
+160 fnt84 6700 -10779(CN)m 3(AME)k 200 fnt84 7349 -10782(Indir)m 3(ection)k
+200 fnt82 6300 -11160(As)m 6608(mentioned)s 7536(pre)s 5(viously)k 13(,)k
+8496(a)s 160 fnt82 8671 -11158(CN)m 5(AME)k 200 fnt82
+9328 -11160(response)m 10111(allo)s 5(ws)k 10712(a)s 6300 -11400(remote)m
+6890(name)s 7359(serv)s 3(er)k 7879(to)s 8072(introduce)s
+8862(a)s 8988(ne)s 5(w)k 9353(name)s 9822(for)s
+10092(an)s 10318(RRset)s 6300 -11640(of)m 6526(arbitrary)s 7270(type.)s
+7773(F)s 3(orw)k 2(arders)k 8734(recei)s 5(ving)k
+9529(such)s 9954(a)s 10102(response)s 6300 -11880(should)m 6889(not)s
+7201(cache)s 7710(those)s 8187(RRsets)s 8807(\(as)s 160 fnt82
+9095 -11878(BIND)m 200 fnt82 9541 -11880(currently)m 10316(does\),)s 6300 -12120(b)m 4(ut)k
+6607(e)s 5(v)k 3(en)k 7031(with)s 7441(that)s
+7795(precaution)s 8691(it)s 8857(will)s 9222(be)s 9466(possible)s
+10174(to)s 10385(use)s 10706(a)s 160 fnt82 6300 -12358(CN)m 5(AME)k
+200 fnt82 6939 -12360(response)m 7704(to)s 7928(bypass)s 8539(the)s
+8851(name/address)s 10002(symmetry)s 6300 -12600(checking.)m gsave
+6300 -14114 translate
+200 fnt82 0.0 0.0 0.0 setrgbcolor 1134 0 0 0 200 240 50 LoutGraphic
+gsave
+0 0 moveto xsize 0 lineto stroke
+grestore
+
+grestore
+102 fnt82 0.0 0.0 0.0 setrgbcolor
+6300 -14295(1)m 160 fnt82 6351 -14366(\205Be)m 6639(liberal)s 7086(in)s
+7250(what)s 7600(you)s 7880(accept,)s 8368(and)s 8639(conserv)s 4(ati)k 4(v)k 2(e)k
+9476(in)s 9640(what)s 9990(you)s 10270(send.)s 11(\206)k
+
+grestore
+
+pgsave restore
+showpage
+
+%%Page: ? 7
+%%BeginPageSetup
+%%PageResources: font Times-Bold
+%%+ font Times-Roman
+%%+ font Times-Italic
+%%+ font Symbol
+/pgsave save def
+%%IncludeResource: font Symbol
+/fnt78 { /Symbol LoutFont } def
+0.0500 dup scale 10 setlinewidth
+%%EndPageSetup
+gsave
+0 15840 translate
+0.0000 rotate
+
+grestore
+gsave
+0 15840 translate
+0.0000 rotate
+240 fnt84 0.0 0.0 0.0 setrgbcolor 1440 -1605(7.)m 1740(What)s 2372(W)s 15(e)k
+2763(W)s 18(ould)k 3497(Lik)s 2(e)k 4020(T)s 22(o)k
+4338(Fix)s 200 fnt82 1440 -1984(Ev)m 3(ery)k 2017(change)s
+2685(to)s 160 fnt82 2944 -1982(BIND)m 200 fnt82 3437 -1984(has)m
+3806(the)s 4153(potential)s 4953(to)s 5212(push)s 5693(the)s
+1440 -2224(Internet)m 2160(into)s 2572(the)s 2917(\207nal)s 3373(abyss.)s
+4017(W)s 16(e)k 4379(are)s 4723(therefore)s 5542(quite)s
+1440 -2464(conserv)m 5(ati)k 5(v)k 3(e)k 2484(about)s
+2979(an)s 3(ything)k 3726(that)s 4076(looks)s 4560(lik)s 2(e)k
+4908(it)s 5070(could)s 5565(ha)s 4(v)k 3(e)k
+1440 -2704(f)m 2(ar)k 1738(reaching)s 2503(consequences,)s 3727(which)s
+4294(is)s 4506(to)s 4741(say)s 13(,)k 5123(just)s
+5490(about)s 1440 -2944(an)m 3(ything)k 128 fnt82 2135 -2855(1)m
+200 fnt82 2199 -2944(.)m 200 fnt84 1440 -3485(7.1)m 1690(.)s
+1840(Query)s 2432(Restarts)s 200 fnt82 1440 -3902(Some)m 1967(of)s
+2206(the)s 2522(information)s 3535(needed)s 4172(to)s 4400(properly)s
+5148(v)s 5(alidate)k 5845(a)s 160 fnt82 1440 -4140(DNS)m
+200 fnt82 1834 -4142(response)m 2606(is)s 2814(e)s 3(xpensi)k 5(v)k 3(e)k
+3675(\(in)s 3972(terms)s 4489(of)s 4731(bandwidth)s 5649(and)s
+1440 -4382(delay\))m 2010(to)s 2238(obtain,)s 2859(and)s 3220(for)s
+3525(that)s 3896(reason)s 4488(it)s 4671(is)s 4876(inappropriate)s
+1440 -4622(for)m 1714(e)s 5(v)k 3(ery)k 2190(resolv)s 3(er)k
+2869(to)s 3066(e)s 3(xhausti)k 5(v)k 3(ely)k
+4103(v)s 5(alidate)k 4769(e)s 5(v)k 3(ery)k
+5245(response)s 1440 -4862(it)m 1631(recei)s 5(v)k 3(es.)k
+2454(Recursi)s 5(v)k 3(e)k 3322(or)s 3569(forw)s 2(arding)k
+4533(name)s 5045(serv)s 3(ers,)k 5735(on)s 1440 -5102(the)m
+1767(other)s 2260(hand,)s 2782(ha)s 4(v)k 3(e)k
+3235(\(or)s 3551(should)s 4167(be)s 4439(able)s 4854(to)s
+5093(obtain\))s 5741(all)s 1440 -5342(the)m 1750(information)s 2757(the)s
+160 fnt82 3067 -5340(DNS)m 200 fnt82 3452 -5342(has)m 3784(to)s
+4006(of)s 5(fer)k 8(,)k 4496(and)s 4851(it)s
+5028(w)s 2(ould)k 5592(be)s 5847(a)s 1440 -5582(good)m
+1891(thing)s 2352(if)s 2524(the)s 2818(name)s 3300(serv)s 3(er)k
+3833(v)s 5(alidated)k 4608(responses)s 5432(before)s 1440 -5822(forw)m 2(arding)k
+2363(them)s 2801(to)s 2996(the)s 3279(client.)s 160 fnt82
+3860 -5820(BIND)m 200 fnt82 4289 -5822(does)m 4694(not)s 4989(currently)s
+5747(do)s 1440 -6062(this,)m 1812(since)s 2255(it)s 2400(is)s
+2567(not)s 2857(possible)s 3544(to)s 3734(edit)s 4067(responses)s
+200 fnt83 4875 -6061(in)m 5065(situ)s 200 fnt82 5387 -6062(and)m
+5710(we)s 1440 -6302(are)m 1751(uncomfortable)s 2981(with)s 3404(the)s
+3716(idea)s 4116(of)s 160 fnt82 4351 -6300(BIND)m 200 fnt82
+4809 -6302(autonomously)m 1440 -6542(deciding)m 2184(that)s 2540(certain)s 3138(responses)s
+3969(should)s 4559(not)s 4872(be)s 5118(forw)s 2(arded)k
+1440 -6782(at)m 1633(all.)s 1840 -7093(Our)m 2184(current)s 2781(plan)s
+3158(for)s 3424(circumv)s 3(enting)k 4605(this)s 4926(problem)s
+5624(is)s 5790(to)s 1440 -7333(restart)m 1981(all)s 2225(queries.)s
+2895(T)s 16(o)k 3147(\205restart\206)s 3864(means)s 4418(that)s
+4762(upon)s 5208(recei)s 5(ving)k 1440 -7573(an)m 1701(answer)s
+2337(from)s 2797(a)s 2958(forw)s 2(arded)k 3847(query)s 13(,)k
+4411(a)s 4572(name)s 5076(serv)s 3(er)k 5631(will)s
+1440 -7813(v)m 5(alidate)k 2120(the)s 2419(response)s 3171(and)s
+3515(insert)s 4012(\205kno)s 5(wn)k 4695(good\206)s 5239(data)s
+5626(into)s 1440 -8053(its)m 1702(cache,)s 2279(and)s 2642(then)s
+3060(pretend)s 3732(that)s 4105(the)s 4423(original)s 5117(query)s
+5646(had)s 1440 -8293(\205just)m 1863(no)s 5(w\206)k 2338(been)s
+2762(recei)s 5(v)k 3(ed.)k 3575(All)s 3877(the)s
+4168(original)s 4835(RRsets)s 5446(w)s 2(ould)k 1440 -8533(be)m
+1700(look)s 2(ed)k 2313(up)s 2585(ag)s 1(ain,)k
+3137(and)s 3497(if)s 3690(an)s 3(y)k 4047(are)s
+4361(still)s 4730(missing)s 5421(\(either)s 1440 -8773(because)m 2136(no)s
+2403(response)s 3166(has)s 3498(yet)s 3808(included)s 4561(them,)s
+5076(or)s 5309(because)s 1440 -9013(the)m 1758(responses)s 2606(that)s
+2979(included)s 3740(them)s 4213(were)s 4674(in)s 8(v)k 5(alid)k
+5289(in)s 5519(some)s 1440 -9253(w)m 2(ay\),)k 1966(ne)s 5(w)k
+2373(queries)s 3027(w)s 2(ould)k 3604(be)s 3872(generated)s
+4725(to)s 4960(bring)s 5461(in)s 5696(the)s 1440 -9493(missing)m
+2131(data.)s 2634(Query)s 3204(restarts)s 3848(are)s 4162(the)s
+200 fnt83 4477 -9492(only)m 200 fnt82 4892 -9493(w)m 2(ay)k
+5294(to)s 5521(solv)s 3(e)k 1440 -9733(certain)m 2059(other)s
+2547(problems)s 3367(currently)s 4164(being)s 4686(encountered)s 5738(by)s
+160 fnt82 1440 -9971(BIND)m 128 fnt82 1829 -9884(2)m 200 fnt82
+1943 -9973(\211)m 2093(the)s 2386(security)s 3065(bene\207ts)s 3734(will)s
+4093(be)s 4331(a)s 4469(happ)s 2(y)k 5005(side)s
+5375(ef)s 5(fect.)k 1840 -10284(One)m 2284(interesting)s 3235(question)s
+4022(we')s 10(re)k 4576(pondering)s 5497(about)s 1440 -10524(query)m
+1957(restarts)s 2592(is)s 2787(whether)s 3491(to)s 3709(preserv)s 3(e)k
+4442(the)s 160 fnt82 4748 -10522(AA)m 200 fnt82 5041 -10524(\210ag,)m
+5453(which)s 1440 -10764(as)m 1697(discussed)s 2551(earlier)s 3149(will)s
+3550(tend)s 3985(to)s 4232(be)s 4512(set)s 4824(on)s
+5116(forw)s 2(arded)k 1440 -11004(responses)m 2271(if)s 2450(those)s
+2928(responses)s 3759(come)s 4248(from)s 4693(an)s 4939(authoritati)s 5(v)k 3(e)k
+1440 -11244(serv)m 3(er)k 8(,)k 1998(b)s 4(ut)k
+2283(will)s 2626(tend)s 3003(to)s 3192(be)s 3414(clear)s
+3833(on)s 4067(responses)s 4874(satis\207ed)s 5559(from)s 1440 -11484(the)m
+1766(forw)s 2(arder')k 11(s)k 2763(cache.)s 3398(W)s 16(e)k
+3741(could)s 4267(maintain)s 5046(the)s 5372(current)s 1440 -11724(semantics)m
+2298(with)s 2727(the)s 3045(hierarchical)s 4057(cache)s 4584(described)s
+5421(belo)s 5(w)k 13(,)k 1440 -11964(b)m 4(ut)k
+1741(it')s 11(s)k 2033(not)s 2338(clear)s 2773(that)s
+3121(the)s 160 fnt82 3414 -11962(AA)m 200 fnt82 3694 -11964(\210ag)m
+4043(on)s 4293(forw)s 2(arded)k 5159(responses)s 1440 -12204(really)m
+1937(matters)s 2566(that)s 2909(much.)s 160 fnt82 3497 -12202(DNS)m
+200 fnt82 3815 -12204(v2)m 4060(will)s 4414(probably)s 5168(ha)s 4(v)k 3(e)k
+5582(a)s 160 fnt82 5715 -12202(AD)m 200 fnt82 1440 -12444(\210ag)m
+1795(\211)s 1951(authority)s 2726(desired)s 3356(\211)s 3512(to)s
+3723(force)s 4187(forw)s 2(arding)k 5126(in)s 5337(spite)s
+5768(of)s 1440 -12684(an)m 3(y)k 1786(cache.)s 2399(The)s
+2770(proposed)s 160 fnt82 3562 -12682(AD)m 200 fnt82 3853 -12684(\210ag)m
+4213(will)s 4583(probably)s 5353(ha)s 4(v)k 3(e)k
+5783(to)s 1440 -12924(bypass)m 2032(the)s 2325(query)s 2829(restart)s
+3374(logic)s 3822(described)s 4634(here.)s gsave
+1440 -13828 translate
+200 fnt82 0.0 0.0 0.0 setrgbcolor 1134 0 0 0 200 240 50 LoutGraphic
+gsave
+0 0 moveto xsize 0 lineto stroke
+grestore
+
+grestore
+102 fnt82 0.0 0.0 0.0 setrgbcolor
+1440 -14009(1)m 160 fnt82 1491 -14080(A)m 1646(Usenet)s 2129(article)s
+2567(once)s 2909(opined,)s 3424(\205)s 128 fnt82 3495 -14078(BIND)m
+160 fnt82 3846 -14080(is)m 3992(lik)s 1(e)k 4270(a)s
+4381(train)s 4713(wreck)s 5143(inside.)s 11(\206)k 102 fnt82
+1440 -14295(2)m 160 fnt82 1491 -14366(Out)m 1770(of)s 1943(zone)s
+128 fnt82 2285 -14364(CN)m 4(AME)k 160 fnt82 2741 -14366(s,)m
+2883(for)s 3109(e)s 2(xample.)k 200 fnt84 6300 -1578(7.2)m
+6550(.)s 6700(Hierar)s 3(chical)k 7818(Cache)s 200 fnt82
+6300 -1957(W)m 16(e)k 6613(w)s 2(ould)k 7163(lik)s 2(e)k
+7512(to)s 7720(se)s 3(gment)k 8433(the)s 8729(cache)s
+9234(such)s 9652(that)s 10003(additional)s 6300 -2197(data)m 6686(can)s
+7017(be)s 7260(cached)s 7867(for)s 8154(the)s 8452(duration)s
+9171(of)s 9392(a)s 9535(query')s 11(s)k 10176(restarts,)s
+6300 -2437(b)m 4(ut)k 6586(not)s 6876(used)s 7276(to)s
+7466(satisfy)s 8019(other)s 8463(queries)s 9072(\(either)s 9625(as)s
+9825(answer)s 10423(data,)s 6300 -2677(authority)m 7053(data,)s 7468(or)s
+7668(additional)s 8498(data\).)s 9029(Ideally)s 13(,)k 9652(the)s
+9929(only)s 10318(things)s 6300 -2917(we)m 6586(w)s 2(ould)k
+7137(e)s 5(v)k 3(er)k 7525(cache)s 8031(w)s 2(ould)k
+8582(be)s 8824(the)s 9121(answer)s 9738(and)s 10080(authority)s
+6300 -3157(sections,)m 7051(and)s 7400(only)s 7816(those)s 8297(from)s
+8745(authoritati)s 5(v)k 3(e)k 9803(answers)s 10504(\()s
+160 fnt82 10570 -3155(AA)m 200 fnt82 6300 -3397(\210ag)m 6676(set\).)s
+160 fnt82 7139 -3395(BIND)m 200 fnt82 7528 -3397(')m 11(s)k
+7737(current)s 8377(cache)s 8906(design)s 9503(is)s 9712(not)s
+10044(ready)s 10563(for)s 6300 -3637(this)m 6654(kind)s 7076(of)s
+7309(o)s 3(v)k 3(erloading)k 8322(\211)s 8489(we')s 10(v)k 3(e)k
+9029(pushed)s 9661(it)s 9838(about)s 10348(as)s 10580(f)s 2(ar)k
+6300 -3877(as)m 6519(it)s 6683(will)s 7046(go)s 7300(just)s
+7641(by)s 7895(adding)s 8492(the)s 8789(credibility)s 9660(tags)s
+10034(described)s 6300 -4117(earlier)m 11(.)k 6957(What')s 11(s)k
+7582(needed)s 8208(is)s 8402(a)s 8552(multile)s 5(v)k 3(el)k
+9412(translucent)s 10346(cache)s 6300 -4357(such)m 6762(that)s 7157(each)s
+7618(lookup)s 8270(can)s 8643(specify)s 9314(a)s 9499(stack)s
+10004(of)s 10267(caches)s 6300 -4597(to)m 6528(be)s 6789(searched,)s
+7607(and)s 7968(each)s 8405(cache)s 8930(can)s 9279(be)s
+9540(managed)s 10332(by)s 10605(an)s 6300 -4837(appropriate)m 7256(pur)s 3(ge)k
+7757(polic)s 3(y)k 13(.)k 200 fnt84 6300 -5378(7.3)m
+6550(.)s 6700(Empty)s 7326(Nonterminal)s 8460(Names)s 200 fnt82
+6300 -5795(One)m 6691(of)s 6916(the)s 7218(g)s 1(aping)k
+7819(holes)s 8298(in)s 160 fnt82 8512 -5793(BIND)m 200 fnt82
+8901 -5795(')m 11(s)k 9092(ne)s 5(w)k 9478(nonpromiscuous)s
+6300 -6035(polic)m 3(y)k 6845(to)s 5(w)k 2(ards)k
+7518(cache)s 8020(data)s 8401(is)s 8583(that)s 8931(the)s
+9224(credibility)s 10091(and)s 10429(zone)s 6300 -6275(tags)m 6673(are)s
+6968(held)s 7364(in)s 7572(the)s 160 fnt82 7868 -6273(RR)m
+200 fnt82 8080 -6275(,)m 8183(not)s 8491(in)s 8699(the)s
+8995(name.)s 9579(It)s 9753(is)s 9938(possible)s 10643(to)s
+6300 -6515(determine,)m 7194(kno)s 5(wing)k 7937(only)s 8341(a)s
+8478(name,)s 9008(whether)s 9698(that)s 10045(name)s 10525(lies)s
+6300 -6755(within)m 6858(an)s 3(y)k 7192(of)s 7407(a)s
+7544(serv)s 3(er')k 11(s)k 8207(zones)s 8709(of)s
+8924(authority)s 13(.)k 160 fnt82 9779 -6753(BIND)m 200 fnt82
+10217 -6755(doesn')m 3(t)k 6300 -6995(do)m 6550(that)s 6898(right)s
+7324(no)s 5(w)k 13(,)k 7750(it)s 7910(currently)s
+8678(checks)s 9269(the)s 160 fnt82 9562 -6993(RR)m 200 fnt82
+9774 -6995(s)m 9901(looking)s 10561(for)s 6300 -7235(an)m 3(y)k
+6628(that)s 6969(ha)s 4(v)k 3(e)k 7381(a)s
+7512(zone)s 7931(tag,)s 8267(and)s 8598(if)s 8762(none)s
+9193(are)s 9478(found)s 9987(it)s 10140(assumes)s 6300 -7475(that)m
+6669(it)s 6850(is)s 7053(in)s 7279(the)s 7593(cache.)s
+8216(This)s 8641(is)s 8844(bad)s 9203(ne)s 5(ws)k
+9678(in)s 9904(the)s 10218(case)s 10630(of)s 6300 -7715(empty)m
+6854(nonterminal)s 7872(names)s 8436(\211)s 8592(those)s 9068(names)s
+9632(which)s 10175(ha)s 4(v)k 3(e)k 10600(no)s
+160 fnt82 6300 -7953(RR)m 200 fnt82 6512 -7955(s)m 6635(and)s
+6969(are)s 7257(only)s 7658(present)s 8278(to)s 8479(k)s 2(eep)k
+8899(tw)s 2(o)k 9242(dots)s 9620(from)s 10053(smashing)s
+6300 -8195(into)m 6660(each)s 7074(other)s 11(.)k 6700 -8506(The)m
+160 fnt84 7084 -8504(ARP)m 11(A)k 200 fnt82 7589 -8506(domain)m
+8261(w)s 2(as)k 8642(once)s 9092(empty)s 9664(other)s
+10147(than)s 10564(for)s 6300 -8746(its)m 160 fnt84 6569 -8744(IN-ADDR.ARP)m 11(A)k
+200 fnt82 7812 -8746(subdomain,)m 8819(and)s 9189(e)s 5(v)k 3(entually)k
+10092(someone)s 6300 -8986(accidentally)m 7317(fed)s 7628(a)s 7773(root)s
+8151(serv)s 3(er)k 8690(some)s 160 fnt82 9167 -8984(NS)m
+9410(RR)s 200 fnt82 9622 -8986(s)m 9756(at)s 9956(that)s
+10311(name.)s 6300 -9226(That)m 6746(root)s 7148(serv)s 3(er)k
+7711(told)s 8102(the)s 8426(other)s 8916(root)s 9318(serv)s 3(ers,)k
+10008(and)s 10377(those)s 6300 -9466(root)m 6683(serv)s 3(ers)k
+7304(told)s 7676(e)s 5(v)k 3(ery)k 8172(name)s
+8665(serv)s 3(er)k 9209(on)s 9471(the)s 9776(Internet,)s
+10506(and)s 6300 -9706(pretty)m 6816(soon)s 7245(nobody)s 7897(an)s 3(ywhere)k
+8720(could)s 9215(do)s 9467(address)s 200 fnt78 10115 -9711(\256)m
+200 fnt82 10364 -9706(name)m 6300 -9946(translations.)m 7364(W)s 16(e)k
+7672(quickly)s 8318(added)s 8842(some)s 160 fnt82 9310 -9944(NS)m
+9553(RR)s 200 fnt82 9765 -9946(s)m 9890(at)s 10081(the)s
+160 fnt84 10372 -9944(ARP)m 11(A)k 200 fnt82 6300 -10186(domain)m
+6948(and)s 7286(cold)s 7679(started)s 8258(the)s 8551(uni)s 5(v)k 3(erse.)k
+6700 -10497(It)m 6891(w)s 2(ould)k 7458(be)s 7716(better)s
+8238(if)s 160 fnt82 8429 -10495(BIND)m 200 fnt82 8888 -10497(did)m
+9213(not)s 9538(need)s 9984(data)s 10385(to)s 10610(be)s
+6300 -10737(present)m 6943(at)s 7155(a)s 7312(name)s 7812(in)s
+8036(order)s 8525(to)s 8749(kno)s 5(w)k 9257(that)s
+9624(that)s 9991(name)s 10491(w)s 2(as)k 6300 -10977(inside)m
+6826(a)s 6965(local)s 7402(zone)s 7829(of)s 8046(authority)s 13(.)k
+8903(Astute)s 9473(readers)s 10097(will)s 10457(note)s 6300 -11217(that)m
+6659(it')s 11(s)k 6962(really)s 7475(quite)s 7934(easy)s
+8348(to)s 8564(add)s 8913(ne)s 5(w)k 9301(names)s
+9870(to)s 10086(someone)s 6300 -11457(else')m 11(s)k 6815(authority)s
+7609(zones)s 8137(\211)s 8312(just)s 8674(k)s 2(eep)k
+9123(in)s 9353(mind)s 9838(during)s 10434(your)s 6300 -11697(e)m 3(xperiments)k
+7327(that)s 7683(these)s 8149(ne)s 5(w)k 8534(names)s
+9100(w)s 2(on')k 3(t)k 9618(appear)s 10206(in)s
+10419(zone)s 6300 -11937(transfers,)m 7113(so)s 7370(you)s 7750(will)s
+8139(ha)s 4(v)k 3(e)k 8588(to)s 8823(infect)s
+9355(each)s 9799(authoritati)s 5(v)k 3(e)k 6300 -12177(name)m
+6781(serv)s 3(er)k 7313(manually)s 13(.)k 200 fnt84
+6300 -12718(7.4)m 6550(.)s 6700(Uni\207ed)s 7370(Zone)s 7852(Cut)s
+8223(V)s 7(iew)k 200 fnt82 6300 -13097(Right)m 6815(no)s 5(w)k
+7226(the)s 7541(answer)s 8176(you')s 2(ll)k 8722(get)s
+9037(for)s 9341(an)s 160 fnt82 9601 -13095(NS)m 200 fnt82
+9876 -13097(query)m 10402(for)s 10706(a)s 6300 -13337(domain)m 6948(will)s
+7307(depend)s 7933(on)s 8183(who)s 8577(you)s 8927(ask.)s
+9342(If)s 9524(you)s 9874(ask)s 10189(a)s 10327(serv)s 3(er)k
+6300 -13577(of)m 6501(the)s 6779(parent)s 7311(zone,)s 7772(you)s
+8107(will)s 8451(get)s 8729(the)s 9007(dele)s 3(g)k 1(ation)k
+9867(information)s 6300 -13817(from)m 6762(\205abo)s 3(v)k 3(e\206)k
+7483(the)s 7801(zone)s 8252(cut.)s 8670(If)s 8877(you)s
+9252(ask)s 9592(the)s 9910(a)s 10073(serv)s 3(er)k
+10630(of)s 6300 -14057(the)m 6599(zone)s 7031(itself,)s 7533(you)s
+7889(will)s 8254(get)s 8553(the)s 8852(actual)s 9382(authority)s
+10157(data)s 10544(\(an)s 160 fnt82 6300 -14295(NS)m 200 fnt82
+6586 -14297(RRset)m 7155(and)s 7526(an)s 160 fnt82 7797 -14295(SO)m 5(A)k
+200 fnt82 8110 -14297(.\))m 8309(W)s 16(e)k 8652(belie)s 5(v)k 3(e)k
+9301(it)s 9494(w)s 2(ould)k 10074(be)s 10345(better)s
+
+grestore
+
+pgsave restore
+showpage
+
+%%Page: ? 8
+%%BeginPageSetup
+%%PageResources: font Times-Roman
+%%+ font Times-Bold
+%%+ font Times-Italic
+%%+ font Helvetica-Bold
+/pgsave save def
+%%IncludeResource: font Helvetica-Bold
+/Helvetica-Boldfnt37 vec1 /Helvetica-Bold LoutRecode
+/fnt37 { /Helvetica-Boldfnt37 LoutFont } def
+0.0500 dup scale 10 setlinewidth
+%%EndPageSetup
+gsave
+0 15840 translate
+0.0000 rotate
+
+grestore
+gsave
+0 15840 translate
+0.0000 rotate
+200 fnt82 0.0 0.0 0.0 setrgbcolor 1440 -1576(in)m 1656(most)s 2104(cases)s
+2583(to)s 2799(ha)s 4(v)k 3(e)k 3229(the)s
+3533(serv)s 3(er)k 4076(for)s 4369(the)s 4673(parent)s
+5231(zone)s 5668(use)s 1440 -1816(its)m 1704(dele)s 3(g)k 1(ation)k
+2606(data)s 3014(only)s 3446(as)s 3688(hints,)s 4202(and)s
+4567(that)s 4942(it)s 5129(should)s 5738(go)s 1440 -2056(out)m
+1787(and)s 2167(ask)s 2524(the)s 2859(serv)s 3(ers)k
+3510(named)s 4133(therein)s 4777(for)s 5101(their)s 5557(vie)s 5(w)k
+1440 -2296(of)m 1694(the)s 2025(real)s 2410(dele)s 3(g)k 1(ation)k
+3323(data.)s 3842(This)s 4284(w)s 2(ould)k 4869(pre)s 5(v)k 3(ent)k
+5546(most)s 1440 -2536(of)m 1696(the)s 2029(current)s 2682(instances)s
+3500(of)s 3756(lame)s 4232(dele)s 3(g)k 1(ation,)k
+5197(since)s 5695(the)s 1440 -2776(lameness)m 2226(w)s 2(ould)k
+2781(be)s 3027(detected)s 3747(by)s 4005(the)s 4306(serv)s 3(er)k
+4846(for)s 5136(the)s 5437(parent)s 1440 -3016(zone)m 1867(where)s
+2404(it)s 2565(can)s 2892(most)s 3330(lik)s 2(ely)k
+3832(be)s 4071(\207x)s 3(ed)k 4518(by)s 4769(the)s
+5063(local)s 5500(name)s 1440 -3256(serv)m 3(er)k 1985(administrator)s 11(.)k
+3197(The)s 3570(lame)s 4019(data)s 4413(can)s 4752(be)s
+5003(elided)s 5552(from)s 1440 -3496(dele)m 3(g)k 1(ation)k
+2406(responses,)s 3370(thus)s 3843(pre)s 5(v)k 3(enting)k
+4828(other)s 5378(serv)s 3(ers)k 1440 -3736(from)m 1907(follo)s 5(wing)k
+2757(it)s 2947(and)s 3315(ha)s 4(ving)k 3934(each)s
+4378(other)s 4867(serv)s 3(er)k 200 fnt84 5429 -3737(syslog)m
+200 fnt82 1440 -3976(the)m 1756(lameness)s 2557(information)s 3570(to)s
+3798(their)s 4235(local,)s 4744(helpless,)s 5507(name)s 1440 -4216(serv)m 3(er)k
+1954(administrator)s 11(.)k 3135(Naturally)s 3918(we)s 4182(w)s 2(ould)k
+4711(e)s 3(xtend)k 5271(the)s 5546(logic)s 1440 -4456(so)m
+1703(that)s 2087(the)s 2416(zone)s 2878(serv)s 3(ers)k
+3523(v)s 5(alidate)k 4233(their)s 4683(o)s 5(wn)k
+5108(dele)s 3(g)k 1(ation)k 1440 -4696(information)m 2466(and)s
+2840(lik)s 2(e)k 5(wise)k 3581(elide)s 4053(lame)s
+4525(information)s 5551(from)s 1440 -4936(their)m 1854(responses.)s 1840 -5247(This)m
+2253(uni\207cation)s 3164(w)s 2(ould)k 3720(put)s 4034(a)s
+4181(stop)s 4572(to)s 4786(the)s 5088(unpleasant)s 1440 -5487(question,)m
+2269(\205ho)s 5(w)k 2800(can)s 3180(both)s 3639(the)s
+3986(parent)s 4587(and)s 4979(child)s 5481(zones)s 1440 -5727(answer)m
+2108(authoritati)s 5(v)k 3(ely)k 3365(if)s 3591(the)s 3(y)k
+4036(are)s 4383(allo)s 5(wed)k 5113(to)s 5373(answer)s
+1440 -5967(dif)m 5(ferently?\206)k 2598(W)s 16(e)k 2956(may)s
+3397(implement)s 4346(a)s 4532(stopg)s 1(ap)k 5249(whereby)s
+1440 -6207(parents)m 2084(stop)s 2486(setting)s 3086(the)s 160 fnt82
+3399 -6205(AA)m 200 fnt82 3699 -6207(\210ag)m 4068(on)s 4338(referral)s
+4991(responses)s 5834(\211)s 1440 -6447(since)m 1902(the)s 2199(child)s
+2651(is)s 2837(really)s 3343(the)s 3640(authority)s 13(.)k
+4450(Unfortunately)s 13(,)k 5658(last)s 1440 -6687(time)m 1846(we)s
+2131(changed)s 2848(the)s 3144(w)s 2(ay)k 3527(we)s
+3812(handed)s 4441(out)s 4749(referrals,)s 5512(some)s 1440 -6927(major)m
+1988(clients)s 2590(could)s 3117(not)s 3456(handle)s 4071(it)s
+4265(and)s 4637(we)s 4953(had)s 5325(to)s 5564(back)s
+1440 -7167(out)m 1767(to)s 1994(older)s 8(,)k 2517(brok)s 2(en)k
+3141(beha)s 4(viour)k 11(.)k 4045(K)s 5(eeping)k
+4787(track)s 5256(of)s 5494(client)s 1440 -7407(sensiti)m 5(vities)k
+2422(has)s 2737(become)s 3406(a)s 3544(\207rst)s 3903(order)s
+4373(task)s 4743(for)s 5025(us.)s 1840 -7718(What)m 2318(we')s 10(re)k
+2807(wrestling)s 3594(with)s 3995(on)s 4242(the)s 4532(uni\207cation)s
+5431(theory)s 1440 -7958(is)m 1667(whether)s 2403(the)s 2741(root)s
+3157(serv)s 3(ers)k 3811(should)s 4438(try)s 4754(to)s
+5004(v)s 3(erify)k 5571(their)s 1440 -8198(dele)m 3(g)k 1(ation)k
+2360(data.)s 2886(W)s 8(ith)k 3371(millions)s 4118(of)s
+4379(zones)s 4927(dele)s 3(g)k 1(ated,)k 5830(it)s
+1440 -8438(could)m 1948(tak)s 2(e)k 2342(quite)s 2805(a)s
+2958(while)s 3465(for)s 3762(each)s 4191(root)s 4577(serv)s 3(er)k
+5124(to)s 5344(get)s 5652(this)s 1440 -8678(done)m 1869(at)s
+2053(startup)s 2635(time,)s 3079(so)s 3297(if)s 3459(we)s
+3732(do)s 3973(it,)s 4174(it')s 2(ll)k 4499(ha)s 4(v)k 3(e)k
+4909(to)s 5105(come)s 5577(after)s 1440 -8918(we)m 1722(mak)s 2(e)k
+2201(the)s 2494(cache)s 2996(persistent.)s 240 fnt84 1440 -9606(8.)m
+192 fnt84 1740 -9604(DNSSEC)m 240 fnt84 2554 -9606(\211)m 2734(The)s
+192 fnt84 3193 -9604(IETF)m 3700(DNS)s 240 fnt84 4142 -9606(Security)m
+192 fnt84 5051 -9604(WG)m 200 fnt82 1440 -10031(As)m 1743(we')s 10(v)k 3(e)k
+2298(mentioned)s 3221(se)s 5(v)k 3(eral)k 3857(times)s
+4369(in)s 4606(this)s 4975(paper)s 8(,)k 5541(there)s
+1440 -10271(is)m 1626(presently)s 2409(w)s 2(ork)k 2871(underw)s 2(ay)k
+3709(to)s 3918(add)s 4260(security)s 4943(to)s 160 fnt82
+5152 -10269(DNS)m 200 fnt82 5470 -10271(.)m 5624(The)s 1440 -10511(current)m
+2069(model)s 2633(is)s 2831(something)s 3727(lik)s 2(e)k
+4089(a)s 4243(\205web)s 4729(of)s 4961(trust,)s 14(\206)k
+5504(using)s 1440 -10751(public)m 2003(k)s 2(e)k 3(y)k
+2351(technology)s 13(.)k 3389(A)s 3598(ne)s 5(w)k
+160 fnt82 3990 -10749(KEY)m 4357(RR)s 200 fnt82 4634 -10751(holds)m
+5131(the)s 5439(public)s 1440 -10991(k)m 2(e)k 3(y)k
+1812(and)s 2189(is)s 2410(added)s 2975(to)s 3219(the)s
+3551(dele)s 3(g)k 1(ation)k 4465(data.)s 4985(This)s
+5428(k)s 2(e)k 3(y)k 5800(is)s 1440 -11231(suf\207cient)m
+2246(to)s 2467(v)s 5(alidate)k 3157(signed)s 3743(answers)s
+4449(b)s 4(ut)k 4766(not)s 5087(to)s 5308(actually)s
+1440 -11471(sign)m 1832(them.)s 2390(Signing)s 3071(is)s 3263(done)s
+3711(by)s 3971(the)s 4274(authoritati)s 5(v)k 3(e)k
+5331(serv)s 3(ers,)k 1440 -11711(and)m 1778(the)s 160 fnt82
+2071 -11709(SIG)m 2367(RR)s 200 fnt82 2629 -11711(is)m 2811(used)s
+3226(to)s 3431(carry)s 3889(the)s 4182(signature)s 4961(of)s
+5177(an)s 3(y)k 5512(gi)s 5(v)k 3(en)k
+1440 -11951(RRset.)m 1840 -12262(Once)m 160 fnt82 2360 -12260(DNSSEC)m 200 fnt82
+3069 -12262(is)m 3301(widely)s 3943(implemented,)s 5132(it)s 5342(will)s
+5751(be)s 1440 -12502(possible)m 2228(to)s 2519(determine)s 3450(from)s
+3973(e)s 3(xamination)k 5090(of)s 5392(a)s 160 fnt82
+5616 -12500(DNS)m 200 fnt82 1440 -12742(response)m 2184(whether)s 2873(its)s
+3108(contents)s 3819(are)s 4109(authentic.)s 4986(This)s 5388(sounds)s
+1440 -12982(simple)m 2019(b)s 4(ut)k 2319(it)s 2478(has)s
+2792(deep)s 3217(reaching)s 3951(consequences)s 5094(in)s 5298(both)s
+5702(the)s 1440 -13222(protocol)m 2140(and)s 2464(the)s 2743(implementation)s
+4028(\211)s 4164(which)s 4687(is)s 4855(wh)s 1(y)k
+5234(it')s 11(s)k 5512(tak)s 2(en)k 1440 -13462(more)m
+1895(than)s 2284(a)s 2418(year)s 2806(to)s 3007(choose)s
+3606(a)s 3740(security)s 4415(model)s 4959(and)s 5293(design)s
+5859(a)s 1440 -13702(solution.)m 2234(W)s 16(e)k 2546(e)s 3(xpect)k
+3114(it)s 3276(to)s 3483(be)s 3723(another)s 4372(year)s
+4766(before)s 160 fnt82 5326 -13700(DNSSEC)m 200 fnt82 1440 -13942(is)m
+1612(in)s 1807(wide)s 2234(use)s 2539(on)s 2779(the)s
+3062(leading)s 3688(edge,)s 4154(and)s 4482(at)s 4665(least)s
+5068(a)s 5196(year)s 5578(after)s 1440 -14182(that)m 1788(before)s
+2346(its)s 2583(use)s 2898(is)s 3080(commonplace)s 4247(on)s
+4497(the)s 4790(Internet.)s 240 fnt84 6300 -1605(9.)m 6600(Which)s
+192 fnt84 7338 -1603(BIND)m 240 fnt84 7876 -1605(V)m 24(ersion)k
+8709(Plugs)s 9327(Which)s 10065(Hole?)s 200 fnt82 6300 -2030(Al)m 2(w)k 2(ays)k
+6951(assume)s 7583(that)s 7928(you)s 8275(need)s 8698(the)s
+8988(latest)s 160 fnt82 9453 -2028(BIND)m 200 fnt82 9889 -2030(you)m
+10236(can)s 10559(lay)s 6300 -2270(your)m 6728(hands)s 7255(on.)s
+7567(Our)s 160 fnt82 7939 -2268(RCS)m 200 fnt82 8301 -2270(libraries)m
+9013(ha)s 4(v)k 3(e)k 9444(the)s 9749(whole)s
+10298(sordid)s 6300 -2510(story)m 13(,)k 6785(and)s 7123(from)s
+7560(them)s 8008(we)s 8290(could)s 8783(deri)s 5(v)k 3(e)k
+9322(a)s 9460(table)s 9896(of)s 10112(V)s 22(ersions)k
+6300 -2750(-vs-)m 6668(V)s 15(ulnerabilities.)k 7993(Y)s 22(ou)k
+8374(can)s 8709(bet)s 9011(that)s 9368(the)s 9670(upper)s
+10183(class)s 10627(of)s 6300 -2990(attack)m 2(ers)k 7063(can)s
+7399(do)s 7659(this)s 8006(as)s 8231(well.)s 8733(Deri)s 5(ving)k
+9496(that)s 9854(table)s 10300(w)s 2(ould)k 6300 -3230(be)m
+6553(a)s 6706(lot)s 6981(of)s 7212(w)s 2(ork)k
+7685(and)s 8038(publishing)s 8945(it)s 9120(might)s 9650(do)s
+9915(more)s 10389(harm)s 6300 -3470(\(gi)m 5(ving)k 6907(folks)s
+7341(the)s 7620(f)s 2(alse)k 8028(idea)s 8395(that)s
+8729(the)s 3(y)k 9105(don')s 3(t)k 9559(need)s
+9971(to)s 10162(upgrade)s 6300 -3710(their)m 160 fnt82 6730 -3708(BIND)m
+200 fnt82 7119 -3710(\))m 7251(than)s 7660(good)s 8126(\(letting)s
+8766(folks)s 9230(see)s 9549(ho)s 5(w)k 9954(bad)s
+10308(things)s 6300 -3950(really)m 6812(are.\))s 7280(When)s 7816(we)s
+8108(took)s 8523(o)s 3(v)k 3(er)k 160 fnt82
+8931 -3948(BIND)m 200 fnt82 9320 -3950(,)m 9430(the)s 9733(latest)s
+10211(v)s 3(ersion)k 6300 -4190(w)m 2(as)k 160 fnt82
+6655 -4188(UCB)m 200 fnt82 7030 -4190(4.8.3.)m 7578(Our)s 7936(\207rst)s
+8293(release)s 8891(w)s 2(as)k 160 fnt82 9246 -4188(DECWRL)m
+200 fnt82 9966 -4190(4.9,)m 10314(which)s 6300 -4430(contained)m 7177(quite)s
+7678(a)s 7869(fe)s 5(w)k 8265(security)s 8997(related)s
+9640(changes.)s 10484(Our)s 6300 -4670(current)m 6916(release)s 7519(as)s
+7737(of)s 7956(this)s 8296(writing)s 8924(is)s 160 fnt82
+9109 -4668(ISC)m 200 fnt82 9409 -4670(4.9.3)m 128 fnt82 9809 -4581(1)m
+200 fnt82 9873 -4670(,)m 9976(and)s 10317(it)s 10480(also)s
+6300 -4910(contains)m 7013(quite)s 7461(a)s 7599(fe)s 5(w)k
+7942(security)s 8621(related)s 9211(changes.)s 200 fnt84 6300 -5571(Refer)m 3(ences)k
+200 fnt82 6300 -5950([)m 6366(Bel95a)s 6930(])s 7300(Ste)s 5(v)k 3(en)k
+7953(M.)s 8299(Bello)s 3(vin)k 8982(.)s 9201(Us)s
+9422(ing)s 9796(the)s 10158(Do)s 10402(main)s 7300 -6190(Name)m
+7889(Sys)s 8177(tem)s 8589(for)s 8935(Syetem)s 9646(Break-)s
+10187(ins)s 10419(.)s 10633(In)s 200 fnt83 7300 -6429(Pr)m 9(o)k
+7590(ceed)s 7954(ings)s 8449(of)s 8767(the)s 9173(F)s 9(ifth)k
+9714(Usenix)s 160 fnt83 10429 -6427(UNIX)m 200 fnt83 7300 -6669(Se)m
+7488(cu)s 7676(ri)s 7808(ty)s 8094(Sy)s 8282(po)s
+8482(sium,)s 9051(Salt)s 9504(Lak)s 2(e)k 10032(City)s 11(,)k
+160 fnt83 10545 -6667(UT)m 200 fnt82 10748 -6670(.)m 7300 -6910(A)m 22(T&T Bell Laboratories)k
+9257(,)s 9357(1995)s 9757(.)s 6300 -7314([)m 6366(RFC1034)s
+7143(])s 7300(P)s 3(aul)k 7797(V)s 25(.)k
+8112(Mockapetris)s 9252(\(ISI\))s 9627(.)s 9873(RFC)s 10396(1034)s
+7300 -7554(\211)m 7496(Domain)s 8234(Concepts)s 9071(and)s 9455(F)s 3(acilities)k
+10179(,)s 10325(IETF)s 10746(,)s 7300 -7794(1987)m 7700(.)s
+6300 -8175([)m 6366(RFC1035)s 7143(])s 7300(P)s 3(aul)k
+7756(V)s 25(.)k 8030(Mockapetris)s 9129(\(ISI\))s 9504(.)s
+9709(RFC)s 10191(1035)s 10696(\211)s 7300 -8415(Domain)m 8015(Implementation)s
+9348(and)s 9709(Speci\207cation)s 10748(,)s 7300 -8655(IETF)m 7721(,)s
+7821(1987)s 8221(.)s 6300 -9059([)m 6366(RFC1123)s 7143(])s
+7300(R.)s 7569(Braden,)s 8280(Ed)s 8502(i)s 8557(tor)s
+8778(.)s 8964(RFC)s 9427(1123)s 9913(\211)s 10099(Re)s
+10320(quire)s 10729(-)s 7300 -9299(ments)m 7840(for)s 8137(In)s
+8303(ter)s 8512(net)s 8820(Hosts)s 9338(\211)s 9503(Ap)s
+9747(pli)s 9957(ca)s 10133(tion)s 10508(and)s 7300 -9539(Sup)m
+7611(port)s 7932(,)s 8032(IETF)s 8453(,)s 8553(1989)s
+8953(.)s 6300 -9959([)m 6366(RFC1510)s 7143(])s 7300(John)s
+7795(T)s 14(.)k 8071(K)s 7(ohl,)k 8631(et)s
+8892(al)s 9035(.)s 9253(RFC)s 9748(1510)s 10266(\211)s
+10484(The)s 7300 -10199(K)m 5(erberos)k 8124(Netw)s 2(ork)k
+8919(Authentication)s 10202(Service)s 7300 -10439(\(V5\))m 7676(,)s 7776(IETF)s
+8197(,)s 8297(1993)s 8697(.)s 6300 -10850([)m 6366(RFC1760)s
+7143(])s 7300(N.)s 7651(Haller)s 8147(.)s 8404(RFC)s
+8938(1760)s 9495(\211)s 9752(The)s 10219(S/KEY)s 7300 -11090(One-T)m 7(ime)k
+8161(P)s 3(assw)k 2(ord)k 8969(System)s 9555(,)s
+9655(IETF)s 10076(,)s 10176(1995)s 10576(.)s gsave
+6300 -14117 translate
+200 fnt82 0.0 0.0 0.0 setrgbcolor 1134 0 0 0 200 240 50 LoutGraphic
+gsave
+0 0 moveto xsize 0 lineto stroke
+grestore
+
+grestore
+102 fnt82
+0.0 0.0 0.0 setrgbcolor 6300 -14298(1)m 160 fnt82 6351 -14369(see)m 140 fnt37
+6595 -14370(http://www)m 5(.isc.or)k 2(g/isc/)k 160 fnt82 8056 -14369(.)m
+
+grestore
+
+pgsave restore
+showpage
+
+%%Trailer
+%%DocumentNeededResources: font Helvetica-Bold
+%%+ font Symbol
+%%+ font Times-Roman
+%%+ font Times-Italic
+%%+ font Times-Bold
+%%DocumentSuppliedResources: procset LoutStartUp
+%%+  procset LoutTabPrependGraphic
+%%+  procset LoutFigPrependGraphic
+%%+ encoding vec1
+%%Pages: 8
+%%EOF
diff --git a/usr.sbin/named/doc/rfc/rfc1032 b/usr.sbin/named/doc/rfc/rfc1032
new file mode 100644
index 00000000000..0e82721cee7
--- /dev/null
+++ b/usr.sbin/named/doc/rfc/rfc1032
@@ -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]
+
diff --git a/usr.sbin/named/doc/rfc/rfc1033 b/usr.sbin/named/doc/rfc/rfc1033
new file mode 100644
index 00000000000..37029fd9ae0
--- /dev/null
+++ b/usr.sbin/named/doc/rfc/rfc1033
@@ -0,0 +1,1229 @@
+Network Working Group                                         M. Lottor
+Request For Comments:  1033                           SRI International
+                                                          November 1987
+
+
+                 DOMAIN ADMINISTRATORS OPERATIONS GUIDE
+
+
+
+STATUS OF THIS MEMO
+
+   This RFC provides guidelines for domain administrators in operating a
+   domain server and maintaining their portion of the hierarchical
+   database.  Familiarity with the domain system is assumed.
+   Distribution of this memo is unlimited.
+
+ACKNOWLEDGMENTS
+
+   This memo is a formatted collection of notes and excerpts from the
+   references listed at the end of this document.  Of particular mention
+   are Paul Mockapetris and Kevin Dunlap.
+
+INTRODUCTION
+
+   A domain server requires a few files to get started.  It will
+   normally have some number of boot/startup files (also known as the
+   "safety belt" files).  One section will contain a list of possible
+   root servers that the server will use to find the up-to-date list of
+   root servers.  Another section will list the zone files to be loaded
+   into the server for your local domain information.  A zone file
+   typically contains all the data for a particular domain.  This guide
+   describes the data formats that can be used in zone files and
+   suggested parameters to use for certain fields.  If you are
+   attempting to do anything advanced or tricky, consult the appropriate
+   domain RFC's for more details.
+
+   Note:  Each implementation of domain software may require different
+   files.  Zone files are standardized but some servers may require
+   other startup files.  See the appropriate documentation that comes
+   with your software.  See the appendix for some specific examples.
+
+ZONES
+
+   A zone defines the contents of a contiguous section of the domain
+   space, usually bounded by administrative boundaries.  There will
+   typically be a separate data file for each zone.  The data contained
+   in a zone file is composed of entries called Resource Records (RRs).
+
+
+
+
+Lottor                                                          [Page 1]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   You may only put data in your domain server that you are
+   authoritative for.  You must not add entries for domains other than
+   your own (except for the special case of "glue records").
+
+   A domain server will probably read a file on start-up that lists the
+   zones it should load into its database.  The format of this file is
+   not standardized and is different for most domain server
+   implementations.  For each zone it will normally contain the domain
+   name of the zone and the file name that contains the data to load for
+   the zone.
+
+ROOT SERVERS
+
+   A resolver will need to find the root servers when it first starts.
+   When the resolver boots, it will typically read a list of possible
+   root servers from a file.
+
+   The resolver will cycle through the list trying to contact each one.
+   When it finds a root server, it will ask it for the current list of
+   root servers.  It will then discard the list of root servers it read
+   from the data file and replace it with the current list it received.
+
+   Root servers will not change very often.  You can get the names of
+   current root servers from the NIC.
+
+   FTP the file NETINFO:ROOT-SERVERS.TXT or send a mail request to
+   NIC@SRI-NIC.ARPA.
+
+   As of this date (June 1987) they are:
+
+           SRI-NIC.ARPA       10.0.0.51    26.0.0.73
+           C.ISI.EDU          10.0.0.52
+           BRL-AOS.ARPA       192.5.25.82  192.5.22.82   128.20.1.2
+           A.ISI.EDU          26.3.0.103
+
+RESOURCE RECORDS
+
+   Records in the zone data files are called resource records (RRs).
+   They are specified in RFC-883 and RFC-973.  An RR has a standard
+   format as shown:
+
+           <name>   [<ttl>]   [<class>]   <type>   <data>
+
+   The record is divided into fields which are separated by white space.
+
+      <name>
+
+         The name field defines what domain name applies to the given
+
+
+
+Lottor                                                          [Page 2]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+         RR.  In some cases the name field can be left blank and it will
+         default to the name field of the previous RR.
+
+      <ttl>
+
+         TTL stands for Time To Live.  It specifies how long a domain
+         resolver should cache the RR before it throws it out and asks a
+         domain server again.  See the section on TTL's.  If you leave
+         the TTL field blank it will default to the minimum time
+         specified in the SOA record (described later).
+
+      <class>
+
+         The class field specifies the protocol group.  If left blank it
+         will default to the last class specified.
+
+      <type>
+
+         The type field specifies what type of data is in the RR.  See
+         the section on types.
+
+      <data>
+
+         The data field is defined differently for each type and class
+         of data.  Popular RR data formats are described later.
+
+   The domain system does not guarantee to preserve the order of
+   resource records.  Listing RRs (such as multiple address records) in
+   a certain order does not guarantee they will be used in that order.
+
+   Case is preserved in names and data fields when loaded into the name
+   server.  All comparisons and lookups in the name server are case
+   insensitive.
+
+   Parenthesis ("(",")") are used to group data that crosses a line
+   boundary.
+
+   A semicolon (";") starts a comment; the remainder of the line is
+   ignored.
+
+   The asterisk ("*") is used for wildcarding.
+
+   The at-sign ("@") denotes the current default domain name.
+
+
+
+
+
+
+
+
+Lottor                                                          [Page 3]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+NAMES
+
+   A domain name is a sequence of labels separated by dots.
+
+   Domain names in the zone files can be one of two types, either
+   absolute or relative.  An absolute name is the fully qualified domain
+   name and is terminated with a period.  A relative name does not
+   terminate with a period, and the current default domain is appended
+   to it.  The default domain is usually the name of the domain that was
+   specified in the boot file that loads each zone.
+
+   The domain system allows a label to contain any 8-bit character.
+   Although the domain system has no restrictions, other protocols such
+   as SMTP do have name restrictions.  Because of other protocol
+   restrictions, only the following characters are recommended for use
+   in a host name (besides the dot separator):
+
+           "A-Z", "a-z", "0-9", dash and underscore
+
+TTL's  (Time To Live)
+
+   It is important that TTLs are set to appropriate values.  The TTL is
+   the time (in seconds) that a resolver will use the data it got from
+   your server before it asks your server again.  If you set the value
+   too low, your server will get loaded down with lots of repeat
+   requests.  If you set it too high, then information you change will
+   not get distributed in a reasonable amount of time.  If you leave the
+   TTL field blank, it will default to what is specified in the SOA
+   record for the zone.
+
+   Most host information does not change much over long time periods.  A
+   good way to set up your TTLs would be to set them at a high value,
+   and then lower the value if you know a change will be coming soon.
+   You might set most TTLs to anywhere between a day (86400) and a week
+   (604800).  Then, if you know some data will be changing in the near
+   future, set the TTL for that RR down to a lower value (an hour to a
+   day) until the change takes place, and then put it back up to its
+   previous value.
+
+   Also, all RRs with the same name, class, and type should have the
+   same TTL value.
+
+CLASSES
+
+   The domain system was designed to be protocol independent.  The class
+   field is used to identify the protocol group that each RR is in.
+
+   The class of interest to people using TCP/IP software is the class
+
+
+
+Lottor                                                          [Page 4]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   "Internet".  Its standard designation is "IN".
+
+   A zone file should only contain RRs of the same class.
+
+TYPES
+
+   There are many defined RR types.  For a complete list, see the domain
+   specification RFCs.  Here is a list of current commonly used types.
+   The data for each type is described in the data section.
+
+                Designation                Description
+              ==========================================
+               SOA                 Start Of Authority
+               NS                  Name Server
+
+               A                   Internet Address
+               CNAME               Canonical Name (nickname pointer)
+               HINFO               Host Information
+               WKS                 Well Known Services
+
+               MX                  Mail Exchanger
+
+               PTR                 Pointer
+
+SOA  (Start Of Authority)
+
+           <name>  [<ttl>]  [<class>]  SOA  <origin>  <person>  (
+                           <serial>
+                           <refresh>
+                           <retry>
+                           <expire>
+                           <minimum> )
+
+   The Start Of Authority record designates the start of a zone.  The
+   zone ends at the next SOA record.
+
+   <name> is the name of the zone.
+
+   <origin> is the name of the host on which the master zone file
+   resides.
+
+   <person> is a mailbox for the person responsible for the zone.  It is
+   formatted like a mailing address but the at-sign that normally
+   separates the user from the host name is replaced with a dot.
+
+   <serial> is the version number of the zone file.  It should be
+   incremented anytime a change is made to data in the zone.
+
+
+
+
+Lottor                                                          [Page 5]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   <refresh> is how long, in seconds, a secondary name server is to
+   check with the primary name server to see if an update is needed.  A
+   good value here would be one hour (3600).
+
+   <retry> is how long, in seconds, a secondary name server is to retry
+   after a failure to check for a refresh.  A good value here would be
+   10 minutes (600).
+
+   <expire> is the upper limit, in seconds, that a secondary name server
+   is to use the data before it expires for lack of getting a refresh.
+   You want this to be rather large, and a nice value is 3600000, about
+   42 days.
+
+   <minimum> is the minimum number of seconds to be used for TTL values
+   in RRs.  A minimum of at least a day is a good value here (86400).
+
+   There should only be one SOA record per zone.  A sample SOA record
+   would look something like:
+
+           @   IN   SOA   SRI-NIC.ARPA.   HOSTMASTER.SRI-NIC.ARPA. (
+                           45         ;serial
+                           3600       ;refresh
+                           600        ;retry
+                           3600000    ;expire
+                           86400 )    ;minimum
+
+
+NS  (Name Server)
+
+           <domain>   [<ttl>] [<class>]   NS   <server>
+
+   The NS record lists the name of a machine that provides domain
+   service for a particular domain.  The name associated with the RR is
+   the domain name and the data portion is the name of a host that
+   provides the service.  If machines SRI-NIC.ARPA and C.ISI.EDU provide
+   name lookup service for the domain COM then the following entries
+   would be used:
+
+           COM.    NS      SRI-NIC.ARPA.
+                   NS      C.ISI.EDU.
+
+   Note that the machines providing name service do not have to live in
+   the named domain.  There should be one NS record for each server for
+   a domain.  Also note that the name "COM" defaults for the second NS
+   record.
+
+   NS records for a domain exist in both the zone that delegates the
+   domain, and in the domain itself.
+
+
+
+Lottor                                                          [Page 6]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+GLUE RECORDS
+
+   If the name server host for a particular domain is itself inside the
+   domain, then a 'glue' record will be needed.  A glue record is an A
+   (address) RR that specifies the address of the server.  Glue records
+   are only needed in the server delegating the domain, not in the
+   domain itself.  If for example the name server for domain SRI.COM was
+   KL.SRI.COM, then the NS record would look like this, but you will
+   also need to have the following A record.
+
+           SRI.COM.	NS	KL.SRI.COM.
+           KL.SRI.COM.  A	10.1.0.2
+
+
+A  (Address)
+
+           <host>   [<ttl>] [<class>]   A   <address>
+
+   The data for an A record is an internet address in dotted decimal
+   form.  A sample A record might look like:
+
+           SRI-NIC.ARPA.           A       10.0.0.51
+
+   There should be one A record for each address of a host.
+
+CNAME ( Canonical Name)
+
+           <nickname>   [<ttl>] [<class>]   CNAME   <host>
+
+   The CNAME record is used for nicknames.  The name associated with the
+   RR is the nickname.  The data portion is the official name.  For
+   example, a machine named SRI-NIC.ARPA may want to have the nickname
+   NIC.ARPA.  In that case, the following RR would be used:
+
+           NIC.ARPA.       CNAME   SRI-NIC.ARPA.
+
+   There must not be any other RRs associated with a nickname of the
+   same class.
+
+   Nicknames are also useful when a host changes it's name.  In that
+   case, it is usually a good idea to have a CNAME pointer so that
+   people still using the old name will get to the right place.
+
+
+
+
+
+
+
+
+
+Lottor                                                          [Page 7]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+HINFO (Host Info)
+
+           <host>   [<ttl>] [<class>]   HINFO   <hardware>   <software>
+
+   The HINFO record gives information about a particular host.  The data
+   is two strings separated by whitespace.  The first string is a
+   hardware description and the second is software.  The hardware is
+   usually a manufacturer name followed by a dash and model designation.
+   The software string is usually the name of the operating system.
+
+   Official HINFO types can be found in the latest Assigned Numbers RFC,
+   the latest of which is RFC-1010.  The Hardware type is called the
+   Machine name and the Software type is called the System name.
+
+   Some sample HINFO records:
+
+           SRI-NIC.ARPA.           HINFO   DEC-2060 TOPS20
+           UCBARPA.Berkeley.EDU.   HINFO   VAX-11/780 UNIX
+
+
+WKS (Well Known Services)
+
+           <host> [<ttl>] [<class>] WKS <address> <protocol> <services>
+
+   The WKS record is used to list Well Known Services a host provides.
+   WKS's are defined to be services on port numbers below 256.  The WKS
+   record lists what services are available at a certain address using a
+   certain protocol.  The common protocols are TCP or UDP.  A sample WKS
+   record for a host offering the same services on all address would
+   look like:
+
+   Official protocol names can be found in the latest Assigned Numbers
+   RFC, the latest of which is RFC-1010.
+
+           SRI-NIC.ARPA.   WKS  10.0.0.51  TCP  TELNET FTP SMTP
+                           WKS  10.0.0.51  UDP  TIME
+                           WKS  26.0.0.73  TCP  TELNET FTP SMTP
+                           WKS  26.0.0.73  UDP  TIME
+
+MX (Mail Exchanger)  (See RFC-974 for more details.)
+
+           <name>   [<ttl>] [<class>]   MX   <preference>   <host>
+
+   MX records specify where mail for a domain name should be delivered.
+   There may be multiple MX records for a particular name.  The
+   preference value specifies the order a mailer should try multiple MX
+   records when delivering mail.  Zero is the highest preference.
+   Multiple records for the same name may have the same preference.
+
+
+
+Lottor                                                          [Page 8]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   A host BAR.FOO.COM may want its mail to be delivered to the host
+   PO.FOO.COM and would then use the MX record:
+
+           BAR.FOO.COM.    MX      10      PO.FOO.COM.
+
+   A host BAZ.FOO.COM may want its mail to be delivered to one of three
+   different machines, in the following order:
+
+           BAZ.FOO.COM.    MX      10      PO1.FOO.COM.
+                           MX      20      PO2.FOO.COM.
+                           MX      30      PO3.FOO.COM.
+
+   An entire domain of hosts not connected to the Internet may want
+   their mail to go through a mail gateway that knows how to deliver
+   mail to them.  If they would like mail addressed to any host in the
+   domain FOO.COM to go through the mail gateway they might use:
+
+           FOO.COM.        MX       10     RELAY.CS.NET.
+           *.FOO.COM.      MX       20     RELAY.CS.NET.
+
+   Note that you can specify a wildcard in the MX record to match on
+   anything in FOO.COM, but that it won't match a plain FOO.COM.
+
+IN-ADDR.ARPA
+
+   The structure of names in the domain system is set up in a
+   hierarchical way such that the address of a name can be found by
+   tracing down the domain tree contacting a server for each label of
+   the name.  Because of this 'indexing' based on name, there is no easy
+   way to translate a host address back into its host name.
+
+   In order to do the reverse translation easily, a domain was created
+   that uses hosts' addresses as part of a name that then points to the
+   data for that host.  In this way, there is now an 'index' to hosts'
+   RRs based on their address.  This address mapping domain is called
+   IN-ADDR.ARPA.  Within that domain are subdomains for each network,
+   based on network number.  Also, for consistency and natural
+   groupings, the 4 octets of a host number are reversed.
+
+   For example, the ARPANET is net 10.  That means there is a domain
+   called 10.IN-ADDR.ARPA.  Within this domain there is a PTR RR at
+   51.0.0.10.IN-ADDR that points to the RRs for the host SRI-NIC.ARPA
+   (who's address is 10.0.0.51).  Since the NIC is also on the MILNET
+   (Net 26, address 26.0.0.73), there is also a PTR RR at 73.0.0.26.IN-
+   ADDR.ARPA that points to the same RR's for SRI-NIC.ARPA.  The format
+   of these special pointers is defined below along with the examples
+   for the NIC.
+
+
+
+
+Lottor                                                          [Page 9]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+PTR
+
+           <special-name>   [<ttl>] [<class>]   PTR   <name>
+
+   The PTR record is used to let special names point to some other
+   location in the domain tree.  They are mainly used in the IN-
+   ADDR.ARPA records for translation of addresses to names.  PTR's
+   should use official names and not aliases.
+
+   For example, host SRI-NIC.ARPA with addresses 10.0.0.51 and 26.0.0.73
+   would have the following records in the respective zone files for net
+   10 and net 26:
+
+           51.0.0.10.IN-ADDR.ARPA.  PTR   SRI-NIC.ARPA.
+           73.0.0.26.IN-ADDR.ARPA.  PTR   SRI-NIC.ARPA.
+
+GATEWAY PTR's
+
+   The IN-ADDR tree is also used to locate gateways on a particular
+   network.  Gateways have the same kind of PTR RRs as hosts (as above)
+   but in addition they have other PTRs used to locate them by network
+   number alone.  These records have only 1, 2, or 3 octets as part of
+   the name depending on whether they are class A, B, or C networks,
+   respectively.
+
+   Lets take the SRI-CSL gateway for example.  It connects 3 different
+   networks, one class A, one class B and one class C.  It will have the
+   standard RR's for a host in the CSL.SRI.COM zone:
+
+           GW.CSL.SRI.COM.    A    10.2.0.2
+                              A    128.18.1.1
+                              A    192.12.33.2
+
+   Also, in 3 different zones (one for each network), it will have one
+   of the following number to name translation pointers:
+
+           2.0.2.10.IN-ADDR.ARPA.      PTR   GW.CSL.SRI.COM.
+           1.1.18.128.IN-ADDR.ARPA.    PTR   GW.CSL.SRI.COM.
+           1.33.12.192.IN-ADDR.ARPA.   PTR   GW.CSL.SRI.COM.
+
+   In addition, in each of the same 3 zones will be one of the following
+   gateway location pointers:
+
+           10.IN-ADDR.ARPA.            PTR   GW.CSL.SRI.COM.
+           18.128.IN-ADDR.ARPA.        PTR   GW.CSL.SRI.COM.
+           33.12.192.IN-ADDR.ARPA.     PTR   GW.CSL.SRI.COM.
+
+
+
+
+
+Lottor                                                         [Page 10]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+INSTRUCTIONS
+
+   Adding a subdomain.
+
+      To add a new subdomain to your domain:
+
+         Setup the other domain server and/or the new zone file.
+
+         Add an NS record for each server of the new domain to the zone
+         file of the parent domain.
+
+         Add any necessary glue RRs.
+
+   Adding a host.
+
+      To add a new host to your zone files:
+
+         Edit the appropriate zone file for the domain the host is in.
+
+         Add an entry for each address of the host.
+
+         Optionally add CNAME, HINFO, WKS, and MX records.
+
+         Add the reverse IN-ADDR entry for each host address in the
+         appropriate zone files for each network the host in on.
+
+   Deleting a host.
+
+      To delete a host from the zone files:
+
+         Remove all the hosts' resource records from the zone file of
+         the domain the host is in.
+
+         Remove all the hosts' PTR records from the IN-ADDR zone files
+         for each network the host was on.
+
+   Adding gateways.
+
+         Follow instructions for adding a host.
+
+         Add the gateway location PTR records for each network the
+         gateway is on.
+
+   Deleting gateways.
+
+         Follow instructions for deleting a host.
+
+         Also delete the gateway location PTR records for each network
+
+
+
+Lottor                                                         [Page 11]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+         the gateway was on.
+
+COMPLAINTS
+
+   These are the suggested steps you should take if you are having
+   problems that you believe are caused by someone else's name server:
+
+
+   1.  Complain privately to the responsible person for the domain.  You
+   can find their mailing address in the SOA record for the domain.
+
+   2.  Complain publicly to the responsible person for the domain.
+
+   3.  Ask the NIC for the administrative person responsible for the
+   domain.  Complain.  You can also find domain contacts on the NIC in
+   the file NETINFO:DOMAIN-CONTACTS.TXT
+
+   4.  Complain to the parent domain authorities.
+
+   5.  Ask the parent authorities to excommunicate the domain.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 12]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+EXAMPLE DOMAIN SERVER DATABASE FILES
+
+   The following examples show how zone files are set up for a typical
+   organization.  SRI will be used as the example organization.  SRI has
+   decided to divided their domain SRI.COM into a few subdomains, one
+   for each group that wants one.  The subdomains are CSL and ISTC.
+
+   Note the following interesting items:
+
+      There are both hosts and domains under SRI.COM.
+
+      CSL.SRI.COM is both a domain name and a host name.
+
+      All the domains are serviced by the same pair of domain servers.
+
+      All hosts at SRI are on net 128.18 except hosts in the CSL domain
+      which are on net 192.12.33.  Note that a domain does not have to
+      correspond to a physical network.
+
+      The examples do not necessarily correspond to actual data in use
+      by the SRI domain.
+
+                       SRI Domain Organization
+
+                               +-------+
+                               |  COM  |
+                               +-------+
+                                   |
+                               +-------+
+                               |  SRI  |
+                               +-------+
+                                   |
+                        +----------++-----------+
+                        |           |           |
+                    +-------+    +------+   +-------+
+                    |  CSL  |    | ISTC |   | Hosts |
+                    +-------+    +------+   +-------+
+                        |           |
+                    +-------+    +-------+
+                    | Hosts |    | Hosts |
+                    +-------+    +-------+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 13]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   [File "CONFIG.CMD".  Since bootstrap files are not standardized, this
+   file is presented using a pseudo configuration file syntax.]
+
+   load root server list             from file ROOT.SERVERS
+   load zone SRI.COM.                from file SRI.ZONE
+   load zone CSL.SRI.COM.            from file CSL.ZONE
+   load zone ISTC.SRI.COM.           from file ISTC.ZONE
+   load zone 18.128.IN-ADDR.ARPA.    from file SRINET.ZONE
+   load zone 33.12.192.IN-ADDR.ARPA. from file SRI-CSL-NET.ZONE
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 14]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   [File "ROOT.SERVERS".  Again, the format of this file is not
+   standardized.]
+
+   ;list of possible root servers
+   SRI-NIC.ARPA       10.0.0.51    26.0.0.73
+   C.ISI.EDU          10.0.0.52
+   BRL-AOS.ARPA       192.5.25.82  192.5.22.82   128.20.1.2
+   A.ISI.EDU          26.3.0.103
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 15]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   [File "SRI.ZONE"]
+
+   SRI.COM.        IN      SOA     KL.SRI.COM. DLE.STRIPE.SRI.COM. (
+                                   870407  ;serial
+                                   1800    ;refresh every 30 minutes
+                                   600     ;retry every 10 minutes
+                                   604800  ;expire after a week
+                                   86400   ;default of an hour
+                                   )
+
+   SRI.COM.        NS      KL.SRI.COM.
+                   NS      STRIPE.SRI.COM.
+                   MX      10      KL.SRI.COM.
+
+   ;SRI.COM hosts
+
+   KL              A       10.1.0.2
+                   A       128.18.10.6
+                   MX      10      KL.SRI.COM.
+
+   STRIPE          A       10.4.0.2
+   STRIPE          A       128.18.10.4
+                   MX      10      STRIPE.SRI.COM.
+
+   NIC             CNAME   SRI-NIC.ARPA.
+
+   Blackjack       A       128.18.2.1
+                   HINFO   VAX-11/780      UNIX
+                   WKS     128.18.2.1      TCP TELNET FTP
+
+   CSL             A       192.12.33.2
+                   HINFO   FOONLY-F4       TOPS20
+                   WKS     192.12.33.2     TCP TELNET FTP SMTP FINGER
+                   MX      10      CSL.SRI.COM.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 16]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   [File "CSL.ZONE"]
+
+   CSL.SRI.COM.    IN      SOA     KL.SRI.COM. DLE.STRIPE.SRI.COM. (
+                                   870330  ;serial
+                                   1800    ;refresh every 30 minutes
+                                   600     ;retry every 10 minutes
+                                   604800  ;expire after a week
+                                   86400   ;default of a day
+                                   )
+
+   CSL.SRI.COM.    NS              KL.SRI.COM.
+                   NS              STRIPE.SRI.COM.
+                   A               192.12.33.2
+
+   ;CSL.SRI.COM hosts
+
+   A               CNAME   CSL.SRI.COM.
+   B               A       192.12.33.3
+                   HINFO   FOONLY-F4       TOPS20
+                   WKS     192.12.33.3     TCP TELNET FTP SMTP
+   GW              A       10.2.0.2
+                   A       192.12.33.1
+                   A       128.18.1.1
+                   HINFO   PDP-11/23       MOS
+   SMELLY          A       192.12.33.4
+                   HINFO   IMAGEN          IMAGEN
+   SQUIRREL        A       192.12.33.5
+                   HINFO   XEROX-1100      INTERLISP
+   VENUS           A       192.12.33.7
+                   HINFO   SYMBOLICS-3600  LISPM
+   HELIUM          A       192.12.33.30
+                   HINFO   SUN-3/160       UNIX
+   ARGON           A       192.12.33.31
+                   HINFO   SUN-3/75        UNIX
+   RADON           A       192.12.33.32
+                   HINFO   SUN-3/75        UNIX
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 17]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   [File "ISTC.ZONE"]
+
+   ISTC.SRI.COM.   IN  SOA     KL.SRI.COM. roemers.JOYCE.ISTC.SRI.COM. (
+                               870406      ;serial
+                               1800        ;refresh every 30 minutes
+                               600         ;retry every 10 minutes
+                               604800      ;expire after a week
+                               86400       ;default of a day
+                               )
+
+   ISTC.SRI.COM.   NS              KL.SRI.COM.
+                   NS              STRIPE.SRI.COM.
+                   MX              10      SPAM.ISTC.SRI.COM.
+
+   ; ISTC hosts
+
+   joyce           A       128.18.4.2
+                   HINFO   VAX-11/750 UNIX
+   bozo            A       128.18.0.6
+                   HINFO   SUN UNIX
+   sundae          A       128.18.0.11
+                   HINFO   SUN UNIX
+   tsca            A       128.18.0.201
+                   A       10.3.0.2
+                   HINFO   VAX-11/750 UNIX
+                   MX      10  TSCA.ISTC.SRI.COM.
+   tsc             CNAME   tsca
+   prmh            A       128.18.0.203
+                   A       10.2.0.51
+                   HINFO   PDP-11/44 UNIX
+   spam            A       128.18.4.3
+                   A       10.2.0.107
+                   HINFO   VAX-11/780 UNIX
+                   MX      10  SPAM.ISTC.SRI.COM.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 18]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   [File "SRINET.ZONE"]
+
+   18.128.IN-ADDR.ARPA.    IN  SOA  KL.SRI.COM  DLE.STRIPE.SRI.COM. (
+                               870406  ;serial
+                               1800    ;refresh every 30 minutes
+                               600     ;retry every 10 minutes
+                               604800  ;expire after a week
+                               86400   ;default of a day
+                               )
+
+   18.128.IN-ADDR.ARPA.    NS      KL.SRI.COM.
+                           NS      STRIPE.SRI.COM.
+                           PTR     GW.CSL.SRI.COM.
+
+   ; SRINET [128.18.0.0] Address Translations
+
+   ; SRI.COM Hosts
+   1.2.18.128.IN-ADDR.ARPA.        PTR     Blackjack.SRI.COM.
+
+   ; ISTC.SRI.COM Hosts
+   2.4.18.128.IN-ADDR.ARPA.        PTR     joyce.ISTC.SRI.COM.
+   6.0.18.128.IN-ADDR.ARPA.        PTR     bozo.ISTC.SRI.COM.
+   11.0.18.128.IN-ADDR.ARPA.       PTR     sundae.ISTC.SRI.COM.
+   201.0.18.128.IN-ADDR.ARPA.      PTR     tsca.ISTC.SRI.COM.
+   203.0.18.128.IN-ADDR.ARPA.      PTR     prmh.ISTC.SRI.COM.
+   3.4.18.128.IN-ADDR.ARPA.        PTR     spam.ISTC.SRI.COM.
+
+   ; CSL.SRI.COM Hosts
+   1.1.18.128.IN-ADDR.ARPA.        PTR     GW.CSL.SRI.COM.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 19]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   [File "SRI-CSL-NET.ZONE"]
+
+   33.12.192.IN-ADDR.ARPA. IN  SOA KL.SRI.COM  DLE.STRIPE.SRI.COM. (
+                               870404  ;serial
+                               1800    ;refresh every 30 minutes
+                               600     ;retry every 10 minutes
+                               604800  ;expire after a week
+                               86400   ;default of a day
+                               )
+
+   33.12.192.IN-ADDR.ARPA. NS      KL.SRI.COM.
+                           NS      STRIPE.SRI.COM.
+                           PTR     GW.CSL.SRI.COM.
+
+   ; SRI-CSL-NET [192.12.33.0] Address Translations
+
+   ; SRI.COM Hosts
+   2.33.12.192.IN-ADDR.ARPA.       PTR     CSL.SRI.COM.
+
+   ; CSL.SRI.COM Hosts
+   1.33.12.192.IN-ADDR.ARPA.       PTR     GW.CSL.SRI.COM.
+   3.33.12.192.IN-ADDR.ARPA.       PTR     B.CSL.SRI.COM.
+   4.33.12.192.IN-ADDR.ARPA.       PTR     SMELLY.CSL.SRI.COM.
+   5.33.12.192.IN-ADDR.ARPA.       PTR     SQUIRREL.CSL.SRI.COM.
+   7.33.12.192.IN-ADDR.ARPA.       PTR     VENUS.CSL.SRI.COM.
+   30.33.12.192.IN-ADDR.ARPA.      PTR     HELIUM.CSL.SRI.COM.
+   31.33.12.192.IN-ADDR.ARPA.      PTR     ARGON.CSL.SRI.COM.
+   32.33.12.192.IN-ADDR.ARPA.      PTR     RADON.CSL.SRI.COM.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 20]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+APPENDIX
+
+   BIND (Berkeley Internet Name Domain server) distributed with 4.3 BSD
+   UNIX
+
+   This section describes two BIND implementation specific files; the
+   boot file and the cache file.  BIND has other options, files, and
+   specifications that are not described here.  See the Name Server
+   Operations Guide for BIND for details.
+
+   The boot file for BIND is usually called "named.boot".  This
+   corresponds to file "CONFIG.CMD" in the example section.
+
+           --------------------------------------------------------
+           cache         .                         named.ca
+           primary       SRI.COM                   SRI.ZONE
+           primary       CSL.SRI.COM               CSL.ZONE
+           primary       ISTC.SRI.COM              ISTC.ZONE
+           primary       18.128.IN-ADDR.ARPA       SRINET.ZONE
+           primary       33.12.192.IN-ADDR.ARPA    SRI-CSL-NET.ZONE
+           --------------------------------------------------------
+
+   The cache file for BIND is usually called "named.ca".  This
+   corresponds to file "ROOT.SERVERS" in the example section.
+
+           -------------------------------------------------
+           ;list of possible root servers
+           .       1          IN   NS   SRI-NIC.ARPA.
+                                   NS   C.ISI.EDU.
+                                   NS   BRL-AOS.ARPA.
+                                   NS   C.ISI.EDU.
+           ;and their addresses
+           SRI-NIC.ARPA.           A    10.0.0.51
+                                   A    26.0.0.73
+           C.ISI.EDU.              A    10.0.0.52
+           BRL-AOS.ARPA.           A    192.5.25.82
+                                   A    192.5.22.82
+                                   A    128.20.1.2
+           A.ISI.EDU.              A    26.3.0.103
+           -------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 21]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+REFERENCES
+
+   [1]  Dunlap, K., "Name Server Operations Guide for BIND", CSRG,
+        Department of Electrical Engineering and Computer Sciences,
+        University of California, Berkeley, California.
+
+   [2]  Partridge, C., "Mail Routing and the Domain System", RFC-974,
+        CSNET CIC BBN Laboratories, January 1986.
+
+   [3]  Mockapetris, P., "Domains Names - Concepts and Facilities",
+        RFC-1034, USC/Information Sciences Institute, November 1987.
+
+   [4]  Mockapetris, P., "Domain Names - Implementations Specification",
+        RFC-1035, USC/Information Sciences Institute, November 1987.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 22]
+
diff --git a/usr.sbin/named/doc/rfc/rfc1034 b/usr.sbin/named/doc/rfc/rfc1034
new file mode 100644
index 00000000000..55cdb21fe65
--- /dev/null
+++ b/usr.sbin/named/doc/rfc/rfc1034
@@ -0,0 +1,3077 @@
+Network Working Group                                     P. Mockapetris
+Request for Comments: 1034                                           ISI
+Obsoletes: RFCs 882, 883, 973                              November 1987
+
+
+                 DOMAIN NAMES - CONCEPTS AND FACILITIES
+
+
+
+1. STATUS OF THIS MEMO
+
+This RFC is an introduction to the Domain Name System (DNS), and omits
+many details which can be found in a companion RFC, "Domain Names -
+Implementation and Specification" [RFC-1035].  That RFC assumes that the
+reader is familiar with the concepts discussed in this memo.
+
+A subset of DNS functions and data types constitute an official
+protocol.  The official protocol includes standard queries and their
+responses and most of the Internet class data formats (e.g., host
+addresses).
+
+However, the domain system is intentionally extensible.  Researchers are
+continuously proposing, implementing and experimenting with new data
+types, query types, classes, functions, etc.  Thus while the components
+of the official protocol are expected to stay essentially unchanged and
+operate as a production service, experimental behavior should always be
+expected in extensions beyond the official protocol.  Experimental or
+obsolete features are clearly marked in these RFCs, and such information
+should be used with caution.
+
+The reader is especially cautioned not to depend on the values which
+appear in examples to be current or complete, since their purpose is
+primarily pedagogical.  Distribution of this memo is unlimited.
+
+2. INTRODUCTION
+
+This RFC introduces domain style names, their use for Internet mail and
+host address support, and the protocols and servers used to implement
+domain name facilities.
+
+2.1. The history of domain names
+
+The impetus for the development of the domain system was growth in the
+Internet:
+
+   - Host name to address mappings were maintained by the Network
+     Information Center (NIC) in a single file (HOSTS.TXT) which
+     was FTPed by all hosts [RFC-952, RFC-953].  The total network
+
+
+
+Mockapetris                                                     [Page 1]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+     bandwidth consumed in distributing a new version by this
+     scheme is proportional to the square of the number of hosts in
+     the network, and even when multiple levels of FTP are used,
+     the outgoing FTP load on the NIC host is considerable.
+     Explosive growth in the number of hosts didn't bode well for
+     the future.
+
+   - The network population was also changing in character.  The
+     timeshared hosts that made up the original ARPANET were being
+     replaced with local networks of workstations.  Local
+     organizations were administering their own names and
+     addresses, but had to wait for the NIC to change HOSTS.TXT to
+     make changes visible to the Internet at large.  Organizations
+     also wanted some local structure on the name space.
+
+   - The applications on the Internet were getting more
+     sophisticated and creating a need for general purpose name
+     service.
+
+
+The result was several ideas about name spaces and their management
+[IEN-116, RFC-799, RFC-819, RFC-830].  The proposals varied, but a
+common thread was the idea of a hierarchical name space, with the
+hierarchy roughly corresponding to organizational structure, and names
+using "."  as the character to mark the boundary between hierarchy
+levels.  A design using a distributed database and generalized resources
+was described in [RFC-882, RFC-883].  Based on experience with several
+implementations, the system evolved into the scheme described in this
+memo.
+
+The terms "domain" or "domain name" are used in many contexts beyond the
+DNS described here.  Very often, the term domain name is used to refer
+to a name with structure indicated by dots, but no relation to the DNS.
+This is particularly true in mail addressing [Quarterman 86].
+
+2.2. DNS design goals
+
+The design goals of the DNS influence its structure.  They are:
+
+   - The primary goal is a consistent name space which will be used
+     for referring to resources.  In order to avoid the problems
+     caused by ad hoc encodings, names should not be required to
+     contain network identifiers, addresses, routes, or similar
+     information as part of the name.
+
+   - The sheer size of the database and frequency of updates
+     suggest that it must be maintained in a distributed manner,
+     with local caching to improve performance.  Approaches that
+
+
+
+Mockapetris                                                     [Page 2]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+     attempt to collect a consistent copy of the entire database
+     will become more and more expensive and difficult, and hence
+     should be avoided.  The same principle holds for the structure
+     of the name space, and in particular mechanisms for creating
+     and deleting names; these should also be distributed.
+
+   - Where there tradeoffs between the cost of acquiring data, the
+     speed of updates, and the accuracy of caches, the source of
+     the data should control the tradeoff.
+
+   - The costs of implementing such a facility dictate that it be
+     generally useful, and not restricted to a single application.
+     We should be able to use names to retrieve host addresses,
+     mailbox data, and other as yet undetermined information.  All
+     data associated with a name is tagged with a type, and queries
+     can be limited to a single type.
+
+   - Because we want the name space to be useful in dissimilar
+     networks and applications, we provide the ability to use the
+     same name space with different protocol families or
+     management.  For example, host address formats differ between
+     protocols, though all protocols have the notion of address.
+     The DNS tags all data with a class as well as the type, so
+     that we can allow parallel use of different formats for data
+     of type address.
+
+   - We want name server transactions to be independent of the
+     communications system that carries them.  Some systems may
+     wish to use datagrams for queries and responses, and only
+     establish virtual circuits for transactions that need the
+     reliability (e.g., database updates, long transactions); other
+     systems will use virtual circuits exclusively.
+
+   - The system should be useful across a wide spectrum of host
+     capabilities.  Both personal computers and large timeshared
+     hosts should be able to use the system, though perhaps in
+     different ways.
+
+2.3. Assumptions about usage
+
+The organization of the domain system derives from some assumptions
+about the needs and usage patterns of its user community and is designed
+to avoid many of the the complicated problems found in general purpose
+database systems.
+
+The assumptions are:
+
+   - The size of the total database will initially be proportional
+
+
+
+Mockapetris                                                     [Page 3]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+     to the number of hosts using the system, but will eventually
+     grow to be proportional to the number of users on those hosts
+     as mailboxes and other information are added to the domain
+     system.
+
+   - Most of the data in the system will change very slowly (e.g.,
+     mailbox bindings, host addresses), but that the system should
+     be able to deal with subsets that change more rapidly (on the
+     order of seconds or minutes).
+
+   - The administrative boundaries used to distribute
+     responsibility for the database will usually correspond to
+     organizations that have one or more hosts.  Each organization
+     that has responsibility for a particular set of domains will
+     provide redundant name servers, either on the organization's
+     own hosts or other hosts that the organization arranges to
+     use.
+
+   - Clients of the domain system should be able to identify
+     trusted name servers they prefer to use before accepting
+     referrals to name servers outside of this "trusted" set.
+
+   - Access to information is more critical than instantaneous
+     updates or guarantees of consistency.  Hence the update
+     process allows updates to percolate out through the users of
+     the domain system rather than guaranteeing that all copies are
+     simultaneously updated.  When updates are unavailable due to
+     network or host failure, the usual course is to believe old
+     information while continuing efforts to update it.  The
+     general model is that copies are distributed with timeouts for
+     refreshing.  The distributor sets the timeout value and the
+     recipient of the distribution is responsible for performing
+     the refresh.  In special situations, very short intervals can
+     be specified, or the owner can prohibit copies.
+
+   - In any system that has a distributed database, a particular
+     name server may be presented with a query that can only be
+     answered by some other server.  The two general approaches to
+     dealing with this problem are "recursive", in which the first
+     server pursues the query for the client at another server, and
+     "iterative", in which the server refers the client to another
+     server and lets the client pursue the query.  Both approaches
+     have advantages and disadvantages, but the iterative approach
+     is preferred for the datagram style of access.  The domain
+     system requires implementation of the iterative approach, but
+     allows the recursive approach as an option.
+
+
+
+
+
+Mockapetris                                                     [Page 4]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+The domain system assumes that all data originates in master files
+scattered through the hosts that use the domain system.  These master
+files are updated by local system administrators.  Master files are text
+files that are read by a local name server, and hence become available
+through the name servers to users of the domain system.  The user
+programs access name servers through standard programs called resolvers.
+
+The standard format of master files allows them to be exchanged between
+hosts (via FTP, mail, or some other mechanism); this facility is useful
+when an organization wants a domain, but doesn't want to support a name
+server.  The organization can maintain the master files locally using a
+text editor, transfer them to a foreign host which runs a name server,
+and then arrange with the system administrator of the name server to get
+the files loaded.
+
+Each host's name servers and resolvers are configured by a local system
+administrator [RFC-1033].  For a name server, this configuration data
+includes the identity of local master files and instructions on which
+non-local master files are to be loaded from foreign servers.  The name
+server uses the master files or copies to load its zones.  For
+resolvers, the configuration data identifies the name servers which
+should be the primary sources of information.
+
+The domain system defines procedures for accessing the data and for
+referrals to other name servers.  The domain system also defines
+procedures for caching retrieved data and for periodic refreshing of
+data defined by the system administrator.
+
+The system administrators provide:
+
+   - The definition of zone boundaries.
+
+   - Master files of data.
+
+   - Updates to master files.
+
+   - Statements of the refresh policies desired.
+
+The domain system provides:
+
+   - Standard formats for resource data.
+
+   - Standard methods for querying the database.
+
+   - Standard methods for name servers to refresh local data from
+     foreign name servers.
+
+
+
+
+
+Mockapetris                                                     [Page 5]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+2.4. Elements of the DNS
+
+The DNS has three major components:
+
+   - The DOMAIN NAME SPACE and RESOURCE RECORDS, which are
+     specifications for a tree structured name space and data
+     associated with the names.  Conceptually, each node and leaf
+     of the domain name space tree names a set of information, and
+     query operations are attempts to extract specific types of
+     information from a particular set.  A query names the domain
+     name of interest and describes the type of resource
+     information that is desired.  For example, the Internet
+     uses some of its domain names to identify hosts; queries for
+     address resources return Internet host addresses.
+
+   - NAME SERVERS are server programs which hold information about
+     the domain tree's structure and set information.  A name
+     server may cache structure or set information about any part
+     of the domain tree, but in general a particular name server
+     has complete information about a subset of the domain space,
+     and pointers to other name servers that can be used to lead to
+     information from any part of the domain tree.  Name servers
+     know the parts of the domain tree for which they have complete
+     information; a name server is said to be an AUTHORITY for
+     these parts of the name space.  Authoritative information is
+     organized into units called ZONEs, and these zones can be
+     automatically distributed to the name servers which provide
+     redundant service for the data in a zone.
+
+   - RESOLVERS are programs that extract information from name
+     servers in response to client requests.  Resolvers must be
+     able to access at least one name server and use that name
+     server's information to answer a query directly, or pursue the
+     query using referrals to other name servers.  A resolver will
+     typically be a system routine that is directly accessible to
+     user programs; hence no protocol is necessary between the
+     resolver and the user program.
+
+These three components roughly correspond to the three layers or views
+of the domain system:
+
+   - From the user's point of view, the domain system is accessed
+     through a simple procedure or OS call to a local resolver.
+     The domain space consists of a single tree and the user can
+     request information from any section of the tree.
+
+   - From the resolver's point of view, the domain system is
+     composed of an unknown number of name servers.  Each name
+
+
+
+Mockapetris                                                     [Page 6]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+     server has one or more pieces of the whole domain tree's data,
+     but the resolver views each of these databases as essentially
+     static.
+
+   - From a name server's point of view, the domain system consists
+     of separate sets of local information called zones.  The name
+     server has local copies of some of the zones.  The name server
+     must periodically refresh its zones from master copies in
+     local files or foreign name servers.  The name server must
+     concurrently process queries that arrive from resolvers.
+
+In the interests of performance, implementations may couple these
+functions.  For example, a resolver on the same machine as a name server
+might share a database consisting of the the zones managed by the name
+server and the cache managed by the resolver.
+
+3. DOMAIN NAME SPACE and RESOURCE RECORDS
+
+3.1. Name space specifications and terminology
+
+The domain name space is a tree structure.  Each node and leaf on the
+tree corresponds to a resource set (which may be empty).  The domain
+system makes no distinctions between the uses of the interior nodes and
+leaves, and this memo uses the term "node" to refer to both.
+
+Each node has a label, which is zero to 63 octets in length.  Brother
+nodes may not have the same label, although the same label can be used
+for nodes which are not brothers.  One label is reserved, and that is
+the null (i.e., zero length) label used for the root.
+
+The domain name of a node is the list of the labels on the path from the
+node to the root of the tree.  By convention, the labels that compose a
+domain name are printed or read left to right, from the most specific
+(lowest, farthest from the root) to the least specific (highest, closest
+to the root).
+
+Internally, programs that manipulate domain names should represent them
+as sequences of labels, where each label is a length octet followed by
+an octet string.  Because all domain names end at the root, which has a
+null string for a label, these internal representations can use a length
+byte of zero to terminate a domain name.
+
+By convention, domain names can be stored with arbitrary case, but
+domain name comparisons for all present domain functions are done in a
+case-insensitive manner, assuming an ASCII character set, and a high
+order zero bit.  This means that you are free to create a node with
+label "A" or a node with label "a", but not both as brothers; you could
+refer to either using "a" or "A".  When you receive a domain name or
+
+
+
+Mockapetris                                                     [Page 7]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+label, you should preserve its case.  The rationale for this choice is
+that we may someday need to add full binary domain names for new
+services; existing services would not be changed.
+
+When a user needs to type a domain name, the length of each label is
+omitted and the labels are separated by dots (".").  Since a complete
+domain name ends with the root label, this leads to a printed form which
+ends in a dot.  We use this property to distinguish between:
+
+   - a character string which represents a complete domain name
+     (often called "absolute").  For example, "poneria.ISI.EDU."
+
+   - a character string that represents the starting labels of a
+     domain name which is incomplete, and should be completed by
+     local software using knowledge of the local domain (often
+     called "relative").  For example, "poneria" used in the
+     ISI.EDU domain.
+
+Relative names are either taken relative to a well known origin, or to a
+list of domains used as a search list.  Relative names appear mostly at
+the user interface, where their interpretation varies from
+implementation to implementation, and in master files, where they are
+relative to a single origin domain name.  The most common interpretation
+uses the root "." as either the single origin or as one of the members
+of the search list, so a multi-label relative name is often one where
+the trailing dot has been omitted to save typing.
+
+To simplify implementations, the total number of octets that represent a
+domain name (i.e., the sum of all label octets and label lengths) is
+limited to 255.
+
+A domain is identified by a domain name, and consists of that part of
+the domain name space that is at or below the domain name which
+specifies the domain.  A domain is a subdomain of another domain if it
+is contained within that domain.  This relationship can be tested by
+seeing if the subdomain's name ends with the containing domain's name.
+For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ".
+
+3.2. Administrative guidelines on use
+
+As a matter of policy, the DNS technical specifications do not mandate a
+particular tree structure or rules for selecting labels; its goal is to
+be as general as possible, so that it can be used to build arbitrary
+applications.  In particular, the system was designed so that the name
+space did not have to be organized along the lines of network
+boundaries, name servers, etc.  The rationale for this is not that the
+name space should have no implied semantics, but rather that the choice
+of implied semantics should be left open to be used for the problem at
+
+
+
+Mockapetris                                                     [Page 8]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+hand, and that different parts of the tree can have different implied
+semantics.  For example, the IN-ADDR.ARPA domain is organized and
+distributed by network and host address because its role is to translate
+from network or host numbers to names; NetBIOS domains [RFC-1001, RFC-
+1002] are flat because that is appropriate for that application.
+
+However, there are some guidelines that apply to the "normal" parts of
+the name space used for hosts, mailboxes, etc., that will make the name
+space more uniform, provide for growth, and minimize problems as
+software is converted from the older host table.  The political
+decisions about the top levels of the tree originated in RFC-920.
+Current policy for the top levels is discussed in [RFC-1032].  MILNET
+conversion issues are covered in [RFC-1031].
+
+Lower domains which will eventually be broken into multiple zones should
+provide branching at the top of the domain so that the eventual
+decomposition can be done without renaming.  Node labels which use
+special characters, leading digits, etc., are likely to break older
+software which depends on more restrictive choices.
+
+3.3. Technical guidelines on use
+
+Before the DNS can be used to hold naming information for some kind of
+object, two needs must be met:
+
+   - A convention for mapping between object names and domain
+     names.  This describes how information about an object is
+     accessed.
+
+   - RR types and data formats for describing the object.
+
+These rules can be quite simple or fairly complex.  Very often, the
+designer must take into account existing formats and plan for upward
+compatibility for existing usage.  Multiple mappings or levels of
+mapping may be required.
+
+For hosts, the mapping depends on the existing syntax for host names
+which is a subset of the usual text representation for domain names,
+together with RR formats for describing host addresses, etc.  Because we
+need a reliable inverse mapping from address to host name, a special
+mapping for addresses into the IN-ADDR.ARPA domain is also defined.
+
+For mailboxes, the mapping is slightly more complex.  The usual mail
+address <local-part>@<mail-domain> is mapped into a domain name by
+converting <local-part> into a single label (regardles of dots it
+contains), converting <mail-domain> into a domain name using the usual
+text format for domain names (dots denote label breaks), and
+concatenating the two to form a single domain name.  Thus the mailbox
+
+
+
+Mockapetris                                                     [Page 9]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+HOSTMASTER@SRI-NIC.ARPA is represented as a domain name by
+HOSTMASTER.SRI-NIC.ARPA.  An appreciation for the reasons behind this
+design also must take into account the scheme for mail exchanges [RFC-
+974].
+
+The typical user is not concerned with defining these rules, but should
+understand that they usually are the result of numerous compromises
+between desires for upward compatibility with old usage, interactions
+between different object definitions, and the inevitable urge to add new
+features when defining the rules.  The way the DNS is used to support
+some object is often more crucial than the restrictions inherent in the
+DNS.
+
+3.4. Example name space
+
+The following figure shows a part of the current domain name space, and
+is used in many examples in this RFC.  Note that the tree is a very
+small subset of the actual name space.
+
+                                   |
+                                   |
+             +---------------------+------------------+
+             |                     |                  |
+            MIL                   EDU                ARPA
+             |                     |                  |
+             |                     |                  |
+       +-----+-----+               |     +------+-----+-----+
+       |     |     |               |     |      |           |
+      BRL  NOSC  DARPA             |  IN-ADDR  SRI-NIC     ACC
+                                   |
+       +--------+------------------+---------------+--------+
+       |        |                  |               |        |
+      UCI      MIT                 |              UDEL     YALE
+                |                 ISI
+                |                  |
+            +---+---+              |
+            |       |              |
+           LCS  ACHILLES  +--+-----+-----+--------+
+            |             |  |     |     |        |
+            XX            A  C   VAXA  VENERA Mockapetris
+
+In this example, the root domain has three immediate subdomains: MIL,
+EDU, and ARPA.  The LCS.MIT.EDU domain has one immediate subdomain named
+XX.LCS.MIT.EDU.  All of the leaves are also domains.
+
+3.5. Preferred name syntax
+
+The DNS specifications attempt to be as general as possible in the rules
+
+
+
+Mockapetris                                                    [Page 10]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+for constructing domain names.  The idea is that the name of any
+existing object can be expressed as a domain name with minimal changes.
+However, when assigning a domain name for an object, the prudent user
+will select a name which satisfies both the rules of the domain system
+and any existing rules for the object, whether these rules are published
+or implied by existing programs.
+
+For example, when naming a mail domain, the user should satisfy both the
+rules of this memo and those in RFC-822.  When creating a new host name,
+the old rules for HOSTS.TXT should be followed.  This avoids problems
+when old software is converted to use domain names.
+
+The following syntax will result in fewer problems with many
+applications that use domain names (e.g., mail, TELNET).
+
+<domain> ::= <subdomain> | " "
+
+<subdomain> ::= <label> | <subdomain> "." <label>
+
+<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
+
+<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
+
+<let-dig-hyp> ::= <let-dig> | "-"
+
+<let-dig> ::= <letter> | <digit>
+
+<letter> ::= any one of the 52 alphabetic characters A through Z in
+upper case and a through z in lower case
+
+<digit> ::= any one of the ten digits 0 through 9
+
+Note that while upper and lower case letters are allowed in domain
+names, no significance is attached to the case.  That is, two names with
+the same spelling but different case are to be treated as if identical.
+
+The labels must follow the rules for ARPANET host names.  They must
+start with a letter, end with a letter or digit, and have as interior
+characters only letters, digits, and hyphen.  There are also some
+restrictions on the length.  Labels must be 63 characters or less.
+
+For example, the following strings identify hosts in the Internet:
+
+A.ISI.EDU  XX.LCS.MIT.EDU  SRI-NIC.ARPA
+
+3.6. Resource Records
+
+A domain name identifies a node.  Each node has a set of resource
+
+
+
+Mockapetris                                                    [Page 11]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+information, which may be empty.  The set of resource information
+associated with a particular name is composed of separate resource
+records (RRs).  The order of RRs in a set is not significant, and need
+not be preserved by name servers, resolvers, or other parts of the DNS.
+
+When we talk about a specific RR, we assume it has the following:
+
+owner           which is the domain name where the RR is found.
+
+type            which is an encoded 16 bit value that specifies the type
+                of the resource in this resource record.  Types refer to
+                abstract resources.
+
+                This memo uses the following types:
+
+                A               a host address
+
+                CNAME           identifies the canonical name of an
+                                alias
+
+                HINFO           identifies the CPU and OS used by a host
+
+                MX              identifies a mail exchange for the
+                                domain.  See [RFC-974 for details.
+
+                NS
+                the authoritative name server for the domain
+
+                PTR
+                a pointer to another part of the domain name space
+
+                SOA
+                identifies the start of a zone of authority]
+
+class           which is an encoded 16 bit value which identifies a
+                protocol family or instance of a protocol.
+
+                This memo uses the following classes:
+
+                IN              the Internet system
+
+                CH              the Chaos system
+
+TTL             which is the time to live of the RR.  This field is a 32
+                bit integer in units of seconds, an is primarily used by
+                resolvers when they cache RRs.  The TTL describes how
+                long a RR can be cached before it should be discarded.
+
+
+
+
+Mockapetris                                                    [Page 12]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+RDATA           which is the type and sometimes class dependent data
+                which describes the resource:
+
+                A               For the IN class, a 32 bit IP address
+
+                                For the CH class, a domain name followed
+                                by a 16 bit octal Chaos address.
+
+                CNAME           a domain name.
+
+                MX              a 16 bit preference value (lower is
+                                better) followed by a host name willing
+                                to act as a mail exchange for the owner
+                                domain.
+
+                NS              a host name.
+
+                PTR             a domain name.
+
+                SOA             several fields.
+
+The owner name is often implicit, rather than forming an integral part
+of the RR.  For example, many name servers internally form tree or hash
+structures for the name space, and chain RRs off nodes.  The remaining
+RR parts are the fixed header (type, class, TTL) which is consistent for
+all RRs, and a variable part (RDATA) that fits the needs of the resource
+being described.
+
+The meaning of the TTL field is a time limit on how long an RR can be
+kept in a cache.  This limit does not apply to authoritative data in
+zones; it is also timed out, but by the refreshing policies for the
+zone.  The TTL is assigned by the administrator for the zone where the
+data originates.  While short TTLs can be used to minimize caching, and
+a zero TTL prohibits caching, the realities of Internet performance
+suggest that these times should be on the order of days for the typical
+host.  If a change can be anticipated, the TTL can be reduced prior to
+the change to minimize inconsistency during the change, and then
+increased back to its former value following the change.
+
+The data in the RDATA section of RRs is carried as a combination of
+binary strings and domain names.  The domain names are frequently used
+as "pointers" to other data in the DNS.
+
+3.6.1. Textual expression of RRs
+
+RRs are represented in binary form in the packets of the DNS protocol,
+and are usually represented in highly encoded form when stored in a name
+server or resolver.  In this memo, we adopt a style similar to that used
+
+
+
+Mockapetris                                                    [Page 13]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+in master files in order to show the contents of RRs.  In this format,
+most RRs are shown on a single line, although continuation lines are
+possible using parentheses.
+
+The start of the line gives the owner of the RR.  If a line begins with
+a blank, then the owner is assumed to be the same as that of the
+previous RR.  Blank lines are often included for readability.
+
+Following the owner, we list the TTL, type, and class of the RR.  Class
+and type use the mnemonics defined above, and TTL is an integer before
+the type field.  In order to avoid ambiguity in parsing, type and class
+mnemonics are disjoint, TTLs are integers, and the type mnemonic is
+always last. The IN class and TTL values are often omitted from examples
+in the interests of clarity.
+
+The resource data or RDATA section of the RR are given using knowledge
+of the typical representation for the data.
+
+For example, we might show the RRs carried in a message as:
+
+    ISI.EDU.        MX      10 VENERA.ISI.EDU.
+                    MX      10 VAXA.ISI.EDU.
+    VENERA.ISI.EDU. A       128.9.0.32
+                    A       10.1.0.52
+    VAXA.ISI.EDU.   A       10.2.0.27
+                    A       128.9.0.33
+
+The MX RRs have an RDATA section which consists of a 16 bit number
+followed by a domain name.  The address RRs use a standard IP address
+format to contain a 32 bit internet address.
+
+This example shows six RRs, with two RRs at each of three domain names.
+
+Similarly we might see:
+
+    XX.LCS.MIT.EDU. IN      A       10.0.0.44
+                    CH      A       MIT.EDU. 2420
+
+This example shows two addresses for XX.LCS.MIT.EDU, each of a different
+class.
+
+3.6.2. Aliases and canonical names
+
+In existing systems, hosts and other resources often have several names
+that identify the same resource.  For example, the names C.ISI.EDU and
+USC-ISIC.ARPA both identify the same host.  Similarly, in the case of
+mailboxes, many organizations provide many names that actually go to the
+same mailbox; for example Mockapetris@C.ISI.EDU, Mockapetris@B.ISI.EDU,
+
+
+
+Mockapetris                                                    [Page 14]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+and PVM@ISI.EDU all go to the same mailbox (although the mechanism
+behind this is somewhat complicated).
+
+Most of these systems have a notion that one of the equivalent set of
+names is the canonical or primary name and all others are aliases.
+
+The domain system provides such a feature using the canonical name
+(CNAME) RR.  A CNAME RR identifies its owner name as an alias, and
+specifies the corresponding canonical name in the RDATA section of the
+RR.  If a CNAME RR is present at a node, no other data should be
+present; this ensures that the data for a canonical name and its aliases
+cannot be different.  This rule also insures that a cached CNAME can be
+used without checking with an authoritative server for other RR types.
+
+CNAME RRs cause special action in DNS software.  When a name server
+fails to find a desired RR in the resource set associated with the
+domain name, it checks to see if the resource set consists of a CNAME
+record with a matching class.  If so, the name server includes the CNAME
+record in the response and restarts the query at the domain name
+specified in the data field of the CNAME record.  The one exception to
+this rule is that queries which match the CNAME type are not restarted.
+
+For example, suppose a name server was processing a query with for USC-
+ISIC.ARPA, asking for type A information, and had the following resource
+records:
+
+    USC-ISIC.ARPA   IN      CNAME   C.ISI.EDU
+
+    C.ISI.EDU       IN      A       10.0.0.52
+
+Both of these RRs would be returned in the response to the type A query,
+while a type CNAME or * query should return just the CNAME.
+
+Domain names in RRs which point at another name should always point at
+the primary name and not the alias.  This avoids extra indirections in
+accessing information.  For example, the address to name RR for the
+above host should be:
+
+    52.0.0.10.IN-ADDR.ARPA  IN      PTR     C.ISI.EDU
+
+rather than pointing at USC-ISIC.ARPA.  Of course, by the robustness
+principle, domain software should not fail when presented with CNAME
+chains or loops; CNAME chains should be followed and CNAME loops
+signalled as an error.
+
+3.7. Queries
+
+Queries are messages which may be sent to a name server to provoke a
+
+
+
+Mockapetris                                                    [Page 15]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+response.  In the Internet, queries are carried in UDP datagrams or over
+TCP connections.  The response by the name server either answers the
+question posed in the query, refers the requester to another set of name
+servers, or signals some error condition.
+
+In general, the user does not generate queries directly, but instead
+makes a request to a resolver which in turn sends one or more queries to
+name servers and deals with the error conditions and referrals that may
+result.  Of course, the possible questions which can be asked in a query
+does shape the kind of service a resolver can provide.
+
+DNS queries and responses are carried in a standard message format.  The
+message format has a header containing a number of fixed fields which
+are always present, and four sections which carry query parameters and
+RRs.
+
+The most important field in the header is a four bit field called an
+opcode which separates different queries.  Of the possible 16 values,
+one (standard query) is part of the official protocol, two (inverse
+query and status query) are options, one (completion) is obsolete, and
+the rest are unassigned.
+
+The four sections are:
+
+Question        Carries the query name and other query parameters.
+
+Answer          Carries RRs which directly answer the query.
+
+Authority       Carries RRs which describe other authoritative servers.
+                May optionally carry the SOA RR for the authoritative
+                data in the answer section.
+
+Additional      Carries RRs which may be helpful in using the RRs in the
+                other sections.
+
+Note that the content, but not the format, of these sections varies with
+header opcode.
+
+3.7.1. Standard queries
+
+A standard query specifies a target domain name (QNAME), query type
+(QTYPE), and query class (QCLASS) and asks for RRs which match.  This
+type of query makes up such a vast majority of DNS queries that we use
+the term "query" to mean standard query unless otherwise specified.  The
+QTYPE and QCLASS fields are each 16 bits long, and are a superset of
+defined types and classes.
+
+
+
+
+
+Mockapetris                                                    [Page 16]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+The QTYPE field may contain:
+
+<any type>      matches just that type. (e.g., A, PTR).
+
+AXFR            special zone transfer QTYPE.
+
+MAILB           matches all mail box related RRs (e.g. MB and MG).
+
+*               matches all RR types.
+
+The QCLASS field may contain:
+
+<any class>     matches just that class (e.g., IN, CH).
+
+*               matches aLL RR classes.
+
+Using the query domain name, QTYPE, and QCLASS, the name server looks
+for matching RRs.  In addition to relevant records, the name server may
+return RRs that point toward a name server that has the desired
+information or RRs that are expected to be useful in interpreting the
+relevant RRs.  For example, a name server that doesn't have the
+requested information may know a name server that does; a name server
+that returns a domain name in a relevant RR may also return the RR that
+binds that domain name to an address.
+
+For example, a mailer tying to send mail to Mockapetris@ISI.EDU might
+ask the resolver for mail information about ISI.EDU, resulting in a
+query for QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN.  The response's answer
+section would be:
+
+    ISI.EDU.        MX      10 VENERA.ISI.EDU.
+                    MX      10 VAXA.ISI.EDU.
+
+while the additional section might be:
+
+    VAXA.ISI.EDU.   A       10.2.0.27
+                    A       128.9.0.33
+    VENERA.ISI.EDU. A       10.1.0.52
+                    A       128.9.0.32
+
+Because the server assumes that if the requester wants mail exchange
+information, it will probably want the addresses of the mail exchanges
+soon afterward.
+
+Note that the QCLASS=* construct requires special interpretation
+regarding authority.  Since a particular name server may not know all of
+the classes available in the domain system, it can never know if it is
+authoritative for all classes.  Hence responses to QCLASS=* queries can
+
+
+
+Mockapetris                                                    [Page 17]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+never be authoritative.
+
+3.7.2. Inverse queries (Optional)
+
+Name servers may also support inverse queries that map a particular
+resource to a domain name or domain names that have that resource.  For
+example, while a standard query might map a domain name to a SOA RR, the
+corresponding inverse query might map the SOA RR back to the domain
+name.
+
+Implementation of this service is optional in a name server, but all
+name servers must at least be able to understand an inverse query
+message and return a not-implemented error response.
+
+The domain system cannot guarantee the completeness or uniqueness of
+inverse queries because the domain system is organized by domain name
+rather than by host address or any other resource type.  Inverse queries
+are primarily useful for debugging and database maintenance activities.
+
+Inverse queries may not return the proper TTL, and do not indicate cases
+where the identified RR is one of a set (for example, one address for a
+host having multiple addresses).  Therefore, the RRs returned in inverse
+queries should never be cached.
+
+Inverse queries are NOT an acceptable method for mapping host addresses
+to host names; use the IN-ADDR.ARPA domain instead.
+
+A detailed discussion of inverse queries is contained in [RFC-1035].
+
+3.8. Status queries (Experimental)
+
+To be defined.
+
+3.9. Completion queries (Obsolete)
+
+The optional completion services described in RFCs 882 and 883 have been
+deleted.  Redesigned services may become available in the future, or the
+opcodes may be reclaimed for other use.
+
+4. NAME SERVERS
+
+4.1. Introduction
+
+Name servers are the repositories of information that make up the domain
+database.  The database is divided up into sections called zones, which
+are distributed among the name servers.  While name servers can have
+several optional functions and sources of data, the essential task of a
+name server is to answer queries using data in its zones.  By design,
+
+
+
+Mockapetris                                                    [Page 18]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+name servers can answer queries in a simple manner; the response can
+always be generated using only local data, and either contains the
+answer to the question or a referral to other name servers "closer" to
+the desired information.
+
+A given zone will be available from several name servers to insure its
+availability in spite of host or communication link failure.  By
+administrative fiat, we require every zone to be available on at least
+two servers, and many zones have more redundancy than that.
+
+A given name server will typically support one or more zones, but this
+gives it authoritative information about only a small section of the
+domain tree.  It may also have some cached non-authoritative data about
+other parts of the tree.  The name server marks its responses to queries
+so that the requester can tell whether the response comes from
+authoritative data or not.
+
+4.2. How the database is divided into zones
+
+The domain database is partitioned in two ways: by class, and by "cuts"
+made in the name space between nodes.
+
+The class partition is simple.  The database for any class is organized,
+delegated, and maintained separately from all other classes.  Since, by
+convention, the name spaces are the same for all classes, the separate
+classes can be thought of as an array of parallel namespace trees.  Note
+that the data attached to nodes will be different for these different
+parallel classes.  The most common reasons for creating a new class are
+the necessity for a new data format for existing types or a desire for a
+separately managed version of the existing name space.
+
+Within a class, "cuts" in the name space can be made between any two
+adjacent nodes.  After all cuts are made, each group of connected name
+space is a separate zone.  The zone is said to be authoritative for all
+names in the connected region.  Note that the "cuts" in the name space
+may be in different places for different classes, the name servers may
+be different, etc.
+
+These rules mean that every zone has at least one node, and hence domain
+name, for which it is authoritative, and all of the nodes in a
+particular zone are connected.  Given, the tree structure, every zone
+has a highest node which is closer to the root than any other node in
+the zone.  The name of this node is often used to identify the zone.
+
+It would be possible, though not particularly useful, to partition the
+name space so that each domain name was in a separate zone or so that
+all nodes were in a single zone.  Instead, the database is partitioned
+at points where a particular organization wants to take over control of
+
+
+
+Mockapetris                                                    [Page 19]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+a subtree.  Once an organization controls its own zone it can
+unilaterally change the data in the zone, grow new tree sections
+connected to the zone, delete existing nodes, or delegate new subzones
+under its zone.
+
+If the organization has substructure, it may want to make further
+internal partitions to achieve nested delegations of name space control.
+In some cases, such divisions are made purely to make database
+maintenance more convenient.
+
+4.2.1. Technical considerations
+
+The data that describes a zone has four major parts:
+
+   - Authoritative data for all nodes within the zone.
+
+   - Data that defines the top node of the zone (can be thought of
+     as part of the authoritative data).
+
+   - Data that describes delegated subzones, i.e., cuts around the
+     bottom of the zone.
+
+   - Data that allows access to name servers for subzones
+     (sometimes called "glue" data).
+
+All of this data is expressed in the form of RRs, so a zone can be
+completely described in terms of a set of RRs.  Whole zones can be
+transferred between name servers by transferring the RRs, either carried
+in a series of messages or by FTPing a master file which is a textual
+representation.
+
+The authoritative data for a zone is simply all of the RRs attached to
+all of the nodes from the top node of the zone down to leaf nodes or
+nodes above cuts around the bottom edge of the zone.
+
+Though logically part of the authoritative data, the RRs that describe
+the top node of the zone are especially important to the zone's
+management.  These RRs are of two types: name server RRs that list, one
+per RR, all of the servers for the zone, and a single SOA RR that
+describes zone management parameters.
+
+The RRs that describe cuts around the bottom of the zone are NS RRs that
+name the servers for the subzones.  Since the cuts are between nodes,
+these RRs are NOT part of the authoritative data of the zone, and should
+be exactly the same as the corresponding RRs in the top node of the
+subzone.  Since name servers are always associated with zone boundaries,
+NS RRs are only found at nodes which are the top node of some zone.  In
+the data that makes up a zone, NS RRs are found at the top node of the
+
+
+
+Mockapetris                                                    [Page 20]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+zone (and are authoritative) and at cuts around the bottom of the zone
+(where they are not authoritative), but never in between.
+
+One of the goals of the zone structure is that any zone have all the
+data required to set up communications with the name servers for any
+subzones.  That is, parent zones have all the information needed to
+access servers for their children zones.  The NS RRs that name the
+servers for subzones are often not enough for this task since they name
+the servers, but do not give their addresses.  In particular, if the
+name of the name server is itself in the subzone, we could be faced with
+the situation where the NS RRs tell us that in order to learn a name
+server's address, we should contact the server using the address we wish
+to learn.  To fix this problem, a zone contains "glue" RRs which are not
+part of the authoritative data, and are address RRs for the servers.
+These RRs are only necessary if the name server's name is "below" the
+cut, and are only used as part of a referral response.
+
+4.2.2. Administrative considerations
+
+When some organization wants to control its own domain, the first step
+is to identify the proper parent zone, and get the parent zone's owners
+to agree to the delegation of control.  While there are no particular
+technical constraints dealing with where in the tree this can be done,
+there are some administrative groupings discussed in [RFC-1032] which
+deal with top level organization, and middle level zones are free to
+create their own rules.  For example, one university might choose to use
+a single zone, while another might choose to organize by subzones
+dedicated to individual departments or schools.  [RFC-1033] catalogs
+available DNS software an discusses administration procedures.
+
+Once the proper name for the new subzone is selected, the new owners
+should be required to demonstrate redundant name server support.  Note
+that there is no requirement that the servers for a zone reside in a
+host which has a name in that domain.  In many cases, a zone will be
+more accessible to the internet at large if its servers are widely
+distributed rather than being within the physical facilities controlled
+by the same organization that manages the zone.  For example, in the
+current DNS, one of the name servers for the United Kingdom, or UK
+domain, is found in the US.  This allows US hosts to get UK data without
+using limited transatlantic bandwidth.
+
+As the last installation step, the delegation NS RRs and glue RRs
+necessary to make the delegation effective should be added to the parent
+zone.  The administrators of both zones should insure that the NS and
+glue RRs which mark both sides of the cut are consistent and remain so.
+
+4.3. Name server internals
+
+
+
+
+Mockapetris                                                    [Page 21]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+4.3.1. Queries and responses
+
+The principal activity of name servers is to answer standard queries.
+Both the query and its response are carried in a standard message format
+which is described in [RFC-1035].  The query contains a QTYPE, QCLASS,
+and QNAME, which describe the types and classes of desired information
+and the name of interest.
+
+The way that the name server answers the query depends upon whether it
+is operating in recursive mode or not:
+
+   - The simplest mode for the server is non-recursive, since it
+     can answer queries using only local information: the response
+     contains an error, the answer, or a referral to some other
+     server "closer" to the answer.  All name servers must
+     implement non-recursive queries.
+
+   - The simplest mode for the client is recursive, since in this
+     mode the name server acts in the role of a resolver and
+     returns either an error or the answer, but never referrals.
+     This service is optional in a name server, and the name server
+     may also choose to restrict the clients which can use
+     recursive mode.
+
+Recursive service is helpful in several situations:
+
+   - a relatively simple requester that lacks the ability to use
+     anything other than a direct answer to the question.
+
+   - a request that needs to cross protocol or other boundaries and
+     can be sent to a server which can act as intermediary.
+
+   - a network where we want to concentrate the cache rather than
+     having a separate cache for each client.
+
+Non-recursive service is appropriate if the requester is capable of
+pursuing referrals and interested in information which will aid future
+requests.
+
+The use of recursive mode is limited to cases where both the client and
+the name server agree to its use.  The agreement is negotiated through
+the use of two bits in query and response messages:
+
+   - The recursion available, or RA bit, is set or cleared by a
+     name server in all responses.  The bit is true if the name
+     server is willing to provide recursive service for the client,
+     regardless of whether the client requested recursive service.
+     That is, RA signals availability rather than use.
+
+
+
+Mockapetris                                                    [Page 22]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+   - Queries contain a bit called recursion desired or RD.  This
+     bit specifies specifies whether the requester wants recursive
+     service for this query.  Clients may request recursive service
+     from any name server, though they should depend upon receiving
+     it only from servers which have previously sent an RA, or
+     servers which have agreed to provide service through private
+     agreement or some other means outside of the DNS protocol.
+
+The recursive mode occurs when a query with RD set arrives at a server
+which is willing to provide recursive service; the client can verify
+that recursive mode was used by checking that both RA and RD are set in
+the reply.  Note that the name server should never perform recursive
+service unless asked via RD, since this interferes with trouble shooting
+of name servers and their databases.
+
+If recursive service is requested and available, the recursive response
+to a query will be one of the following:
+
+   - The answer to the query, possibly preface by one or more CNAME
+     RRs that specify aliases encountered on the way to an answer.
+
+   - A name error indicating that the name does not exist.  This
+     may include CNAME RRs that indicate that the original query
+     name was an alias for a name which does not exist.
+
+   - A temporary error indication.
+
+If recursive service is not requested or is not available, the non-
+recursive response will be one of the following:
+
+   - An authoritative name error indicating that the name does not
+     exist.
+
+   - A temporary error indication.
+
+   - Some combination of:
+
+     RRs that answer the question, together with an indication
+     whether the data comes from a zone or is cached.
+
+     A referral to name servers which have zones which are closer
+     ancestors to the name than the server sending the reply.
+
+   - RRs that the name server thinks will prove useful to the
+     requester.
+
+
+
+
+
+
+Mockapetris                                                    [Page 23]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+4.3.2. Algorithm
+
+The actual algorithm used by the name server will depend on the local OS
+and data structures used to store RRs.  The following algorithm assumes
+that the RRs are organized in several tree structures, one for each
+zone, and another for the cache:
+
+   1. Set or clear the value of recursion available in the response
+      depending on whether the name server is willing to provide
+      recursive service.  If recursive service is available and
+      requested via the RD bit in the query, go to step 5,
+      otherwise step 2.
+
+   2. Search the available zones for the zone which is the nearest
+      ancestor to QNAME.  If such a zone is found, go to step 3,
+      otherwise step 4.
+
+   3. Start matching down, label by label, in the zone.  The
+      matching process can terminate several ways:
+
+         a. If the whole of QNAME is matched, we have found the
+            node.
+
+            If the data at the node is a CNAME, and QTYPE doesn't
+            match CNAME, copy the CNAME RR into the answer section
+            of the response, change QNAME to the canonical name in
+            the CNAME RR, and go back to step 1.
+
+            Otherwise, copy all RRs which match QTYPE into the
+            answer section and go to step 6.
+
+         b. If a match would take us out of the authoritative data,
+            we have a referral.  This happens when we encounter a
+            node with NS RRs marking cuts along the bottom of a
+            zone.
+
+            Copy the NS RRs for the subzone into the authority
+            section of the reply.  Put whatever addresses are
+            available into the additional section, using glue RRs
+            if the addresses are not available from authoritative
+            data or the cache.  Go to step 4.
+
+         c. If at some label, a match is impossible (i.e., the
+            corresponding label does not exist), look to see if a
+            the "*" label exists.
+
+            If the "*" label does not exist, check whether the name
+            we are looking for is the original QNAME in the query
+
+
+
+Mockapetris                                                    [Page 24]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+            or a name we have followed due to a CNAME.  If the name
+            is original, set an authoritative name error in the
+            response and exit.  Otherwise just exit.
+
+            If the "*" label does exist, match RRs at that node
+            against QTYPE.  If any match, copy them into the answer
+            section, but set the owner of the RR to be QNAME, and
+            not the node with the "*" label.  Go to step 6.
+
+   4. Start matching down in the cache.  If QNAME is found in the
+      cache, copy all RRs attached to it that match QTYPE into the
+      answer section.  If there was no delegation from
+      authoritative data, look for the best one from the cache, and
+      put it in the authority section.  Go to step 6.
+
+   5. Using the local resolver or a copy of its algorithm (see
+      resolver section of this memo) to answer the query.  Store
+      the results, including any intermediate CNAMEs, in the answer
+      section of the response.
+
+   6. Using local data only, attempt to add other RRs which may be
+      useful to the additional section of the query.  Exit.
+
+4.3.3. Wildcards
+
+In the previous algorithm, special treatment was given to RRs with owner
+names starting with the label "*".  Such RRs are called wildcards.
+Wildcard RRs can be thought of as instructions for synthesizing RRs.
+When the appropriate conditions are met, the name server creates RRs
+with an owner name equal to the query name and contents taken from the
+wildcard RRs.
+
+This facility is most often used to create a zone which will be used to
+forward mail from the Internet to some other mail system.  The general
+idea is that any name in that zone which is presented to server in a
+query will be assumed to exist, with certain properties, unless explicit
+evidence exists to the contrary.  Note that the use of the term zone
+here, instead of domain, is intentional; such defaults do not propagate
+across zone boundaries, although a subzone may choose to achieve that
+appearance by setting up similar defaults.
+
+The contents of the wildcard RRs follows the usual rules and formats for
+RRs.  The wildcards in the zone have an owner name that controls the
+query names they will match.  The owner name of the wildcard RRs is of
+the form "*.<anydomain>", where <anydomain> is any domain name.
+<anydomain> should not contain other * labels, and should be in the
+authoritative data of the zone.  The wildcards potentially apply to
+descendants of <anydomain>, but not to <anydomain> itself.  Another way
+
+
+
+Mockapetris                                                    [Page 25]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+to look at this is that the "*" label always matches at least one whole
+label and sometimes more, but always whole labels.
+
+Wildcard RRs do not apply:
+
+   - When the query is in another zone.  That is, delegation cancels
+     the wildcard defaults.
+
+   - When the query name or a name between the wildcard domain and
+     the query name is know to exist.  For example, if a wildcard
+     RR has an owner name of "*.X", and the zone also contains RRs
+     attached to B.X, the wildcards would apply to queries for name
+     Z.X (presuming there is no explicit information for Z.X), but
+     not to B.X, A.B.X, or X.
+
+A * label appearing in a query name has no special effect, but can be
+used to test for wildcards in an authoritative zone; such a query is the
+only way to get a response containing RRs with an owner name with * in
+it.  The result of such a query should not be cached.
+
+Note that the contents of the wildcard RRs are not modified when used to
+synthesize RRs.
+
+To illustrate the use of wildcard RRs, suppose a large company with a
+large, non-IP/TCP, network wanted to create a mail gateway.  If the
+company was called X.COM, and IP/TCP capable gateway machine was called
+A.X.COM, the following RRs might be entered into the COM zone:
+
+    X.COM           MX      10      A.X.COM
+
+    *.X.COM         MX      10      A.X.COM
+
+    A.X.COM         A       1.2.3.4
+    A.X.COM         MX      10      A.X.COM
+
+    *.A.X.COM       MX      10      A.X.COM
+
+This would cause any MX query for any domain name ending in X.COM to
+return an MX RR pointing at A.X.COM.  Two wildcard RRs are required
+since the effect of the wildcard at *.X.COM is inhibited in the A.X.COM
+subtree by the explicit data for A.X.COM.  Note also that the explicit
+MX data at X.COM and A.X.COM is required, and that none of the RRs above
+would match a query name of XX.COM.
+
+4.3.4. Negative response caching (Optional)
+
+The DNS provides an optional service which allows name servers to
+distribute, and resolvers to cache, negative results with TTLs.  For
+
+
+
+Mockapetris                                                    [Page 26]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+example, a name server can distribute a TTL along with a name error
+indication, and a resolver receiving such information is allowed to
+assume that the name does not exist during the TTL period without
+consulting authoritative data.  Similarly, a resolver can make a query
+with a QTYPE which matches multiple types, and cache the fact that some
+of the types are not present.
+
+This feature can be particularly important in a system which implements
+naming shorthands that use search lists beacuse a popular shorthand,
+which happens to require a suffix toward the end of the search list,
+will generate multiple name errors whenever it is used.
+
+The method is that a name server may add an SOA RR to the additional
+section of a response when that response is authoritative.  The SOA must
+be that of the zone which was the source of the authoritative data in
+the answer section, or name error if applicable.  The MINIMUM field of
+the SOA controls the length of time that the negative result may be
+cached.
+
+Note that in some circumstances, the answer section may contain multiple
+owner names.  In this case, the SOA mechanism should only be used for
+the data which matches QNAME, which is the only authoritative data in
+this section.
+
+Name servers and resolvers should never attempt to add SOAs to the
+additional section of a non-authoritative response, or attempt to infer
+results which are not directly stated in an authoritative response.
+There are several reasons for this, including: cached information isn't
+usually enough to match up RRs and their zone names, SOA RRs may be
+cached due to direct SOA queries, and name servers are not required to
+output the SOAs in the authority section.
+
+This feature is optional, although a refined version is expected to
+become part of the standard protocol in the future.  Name servers are
+not required to add the SOA RRs in all authoritative responses, nor are
+resolvers required to cache negative results.  Both are recommended.
+All resolvers and recursive name servers are required to at least be
+able to ignore the SOA RR when it is present in a response.
+
+Some experiments have also been proposed which will use this feature.
+The idea is that if cached data is known to come from a particular zone,
+and if an authoritative copy of the zone's SOA is obtained, and if the
+zone's SERIAL has not changed since the data was cached, then the TTL of
+the cached data can be reset to the zone MINIMUM value if it is smaller.
+This usage is mentioned for planning purposes only, and is not
+recommended as yet.
+
+
+
+
+
+Mockapetris                                                    [Page 27]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+4.3.5. Zone maintenance and transfers
+
+Part of the job of a zone administrator is to maintain the zones at all
+of the name servers which are authoritative for the zone.  When the
+inevitable changes are made, they must be distributed to all of the name
+servers.  While this distribution can be accomplished using FTP or some
+other ad hoc procedure, the preferred method is the zone transfer part
+of the DNS protocol.
+
+The general model of automatic zone transfer or refreshing is that one
+of the name servers is the master or primary for the zone.  Changes are
+coordinated at the primary, typically by editing a master file for the
+zone.  After editing, the administrator signals the master server to
+load the new zone.  The other non-master or secondary servers for the
+zone periodically check for changes (at a selectable interval) and
+obtain new zone copies when changes have been made.
+
+To detect changes, secondaries just check the SERIAL field of the SOA
+for the zone.  In addition to whatever other changes are made, the
+SERIAL field in the SOA of the zone is always advanced whenever any
+change is made to the zone.  The advancing can be a simple increment, or
+could be based on the write date and time of the master file, etc.  The
+purpose is to make it possible to determine which of two copies of a
+zone is more recent by comparing serial numbers.  Serial number advances
+and comparisons use sequence space arithmetic, so there is a theoretic
+limit on how fast a zone can be updated, basically that old copies must
+die out before the serial number covers half of its 32 bit range.  In
+practice, the only concern is that the compare operation deals properly
+with comparisons around the boundary between the most positive and most
+negative 32 bit numbers.
+
+The periodic polling of the secondary servers is controlled by
+parameters in the SOA RR for the zone, which set the minimum acceptable
+polling intervals.  The parameters are called REFRESH, RETRY, and
+EXPIRE.  Whenever a new zone is loaded in a secondary, the secondary
+waits REFRESH seconds before checking with the primary for a new serial.
+If this check cannot be completed, new checks are started every RETRY
+seconds.  The check is a simple query to the primary for the SOA RR of
+the zone.  If the serial field in the secondary's zone copy is equal to
+the serial returned by the primary, then no changes have occurred, and
+the REFRESH interval wait is restarted.  If the secondary finds it
+impossible to perform a serial check for the EXPIRE interval, it must
+assume that its copy of the zone is obsolete an discard it.
+
+When the poll shows that the zone has changed, then the secondary server
+must request a zone transfer via an AXFR request for the zone.  The AXFR
+may cause an error, such as refused, but normally is answered by a
+sequence of response messages.  The first and last messages must contain
+
+
+
+Mockapetris                                                    [Page 28]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+the data for the top authoritative node of the zone.  Intermediate
+messages carry all of the other RRs from the zone, including both
+authoritative and non-authoritative RRs.  The stream of messages allows
+the secondary to construct a copy of the zone.  Because accuracy is
+essential, TCP or some other reliable protocol must be used for AXFR
+requests.
+
+Each secondary server is required to perform the following operations
+against the master, but may also optionally perform these operations
+against other secondary servers.  This strategy can improve the transfer
+process when the primary is unavailable due to host downtime or network
+problems, or when a secondary server has better network access to an
+"intermediate" secondary than to the primary.
+
+5. RESOLVERS
+
+5.1. Introduction
+
+Resolvers are programs that interface user programs to domain name
+servers.  In the simplest case, a resolver receives a request from a
+user program (e.g., mail programs, TELNET, FTP) in the form of a
+subroutine call, system call etc., and returns the desired information
+in a form compatible with the local host's data formats.
+
+The resolver is located on the same machine as the program that requests
+the resolver's services, but it may need to consult name servers on
+other hosts.  Because a resolver may need to consult several name
+servers, or may have the requested information in a local cache, the
+amount of time that a resolver will take to complete can vary quite a
+bit, from milliseconds to several seconds.
+
+A very important goal of the resolver is to eliminate network delay and
+name server load from most requests by answering them from its cache of
+prior results.  It follows that caches which are shared by multiple
+processes, users, machines, etc., are more efficient than non-shared
+caches.
+
+5.2. Client-resolver interface
+
+5.2.1. Typical functions
+
+The client interface to the resolver is influenced by the local host's
+conventions, but the typical resolver-client interface has three
+functions:
+
+   1. Host name to host address translation.
+
+      This function is often defined to mimic a previous HOSTS.TXT
+
+
+
+Mockapetris                                                    [Page 29]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+      based function.  Given a character string, the caller wants
+      one or more 32 bit IP addresses.  Under the DNS, it
+      translates into a request for type A RRs.  Since the DNS does
+      not preserve the order of RRs, this function may choose to
+      sort the returned addresses or select the "best" address if
+      the service returns only one choice to the client.  Note that
+      a multiple address return is recommended, but a single
+      address may be the only way to emulate prior HOSTS.TXT
+      services.
+
+   2. Host address to host name translation
+
+      This function will often follow the form of previous
+      functions.  Given a 32 bit IP address, the caller wants a
+      character string.  The octets of the IP address are reversed,
+      used as name components, and suffixed with "IN-ADDR.ARPA".  A
+      type PTR query is used to get the RR with the primary name of
+      the host.  For example, a request for the host name
+      corresponding to IP address 1.2.3.4 looks for PTR RRs for
+      domain name "4.3.2.1.IN-ADDR.ARPA".
+
+   3. General lookup function
+
+      This function retrieves arbitrary information from the DNS,
+      and has no counterpart in previous systems.  The caller
+      supplies a QNAME, QTYPE, and QCLASS, and wants all of the
+      matching RRs.  This function will often use the DNS format
+      for all RR data instead of the local host's, and returns all
+      RR content (e.g., TTL) instead of a processed form with local
+      quoting conventions.
+
+When the resolver performs the indicated function, it usually has one of
+the following results to pass back to the client:
+
+   - One or more RRs giving the requested data.
+
+     In this case the resolver returns the answer in the
+     appropriate format.
+
+   - A name error (NE).
+
+     This happens when the referenced name does not exist.  For
+     example, a user may have mistyped a host name.
+
+   - A data not found error.
+
+     This happens when the referenced name exists, but data of the
+     appropriate type does not.  For example, a host address
+
+
+
+Mockapetris                                                    [Page 30]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+     function applied to a mailbox name would return this error
+     since the name exists, but no address RR is present.
+
+It is important to note that the functions for translating between host
+names and addresses may combine the "name error" and "data not found"
+error conditions into a single type of error return, but the general
+function should not.  One reason for this is that applications may ask
+first for one type of information about a name followed by a second
+request to the same name for some other type of information; if the two
+errors are combined, then useless queries may slow the application.
+
+5.2.2. Aliases
+
+While attempting to resolve a particular request, the resolver may find
+that the name in question is an alias.  For example, the resolver might
+find that the name given for host name to address translation is an
+alias when it finds the CNAME RR.  If possible, the alias condition
+should be signalled back from the resolver to the client.
+
+In most cases a resolver simply restarts the query at the new name when
+it encounters a CNAME.  However, when performing the general function,
+the resolver should not pursue aliases when the CNAME RR matches the
+query type.  This allows queries which ask whether an alias is present.
+For example, if the query type is CNAME, the user is interested in the
+CNAME RR itself, and not the RRs at the name it points to.
+
+Several special conditions can occur with aliases.  Multiple levels of
+aliases should be avoided due to their lack of efficiency, but should
+not be signalled as an error.  Alias loops and aliases which point to
+non-existent names should be caught and an error condition passed back
+to the client.
+
+5.2.3. Temporary failures
+
+In a less than perfect world, all resolvers will occasionally be unable
+to resolve a particular request.  This condition can be caused by a
+resolver which becomes separated from the rest of the network due to a
+link failure or gateway problem, or less often by coincident failure or
+unavailability of all servers for a particular domain.
+
+It is essential that this sort of condition should not be signalled as a
+name or data not present error to applications.  This sort of behavior
+is annoying to humans, and can wreak havoc when mail systems use the
+DNS.
+
+While in some cases it is possible to deal with such a temporary problem
+by blocking the request indefinitely, this is usually not a good choice,
+particularly when the client is a server process that could move on to
+
+
+
+Mockapetris                                                    [Page 31]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+other tasks.  The recommended solution is to always have temporary
+failure as one of the possible results of a resolver function, even
+though this may make emulation of existing HOSTS.TXT functions more
+difficult.
+
+5.3. Resolver internals
+
+Every resolver implementation uses slightly different algorithms, and
+typically spends much more logic dealing with errors of various sorts
+than typical occurances.  This section outlines a recommended basic
+strategy for resolver operation, but leaves details to [RFC-1035].
+
+5.3.1. Stub resolvers
+
+One option for implementing a resolver is to move the resolution
+function out of the local machine and into a name server which supports
+recursive queries.  This can provide an easy method of providing domain
+service in a PC which lacks the resources to perform the resolver
+function, or can centralize the cache for a whole local network or
+organization.
+
+All that the remaining stub needs is a list of name server addresses
+that will perform the recursive requests.  This type of resolver
+presumably needs the information in a configuration file, since it
+probably lacks the sophistication to locate it in the domain database.
+The user also needs to verify that the listed servers will perform the
+recursive service; a name server is free to refuse to perform recursive
+services for any or all clients.  The user should consult the local
+system administrator to find name servers willing to perform the
+service.
+
+This type of service suffers from some drawbacks.  Since the recursive
+requests may take an arbitrary amount of time to perform, the stub may
+have difficulty optimizing retransmission intervals to deal with both
+lost UDP packets and dead servers; the name server can be easily
+overloaded by too zealous a stub if it interprets retransmissions as new
+requests.  Use of TCP may be an answer, but TCP may well place burdens
+on the host's capabilities which are similar to those of a real
+resolver.
+
+5.3.2. Resources
+
+In addition to its own resources, the resolver may also have shared
+access to zones maintained by a local name server.  This gives the
+resolver the advantage of more rapid access, but the resolver must be
+careful to never let cached information override zone data.  In this
+discussion the term "local information" is meant to mean the union of
+the cache and such shared zones, with the understanding that
+
+
+
+Mockapetris                                                    [Page 32]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+authoritative data is always used in preference to cached data when both
+are present.
+
+The following resolver algorithm assumes that all functions have been
+converted to a general lookup function, and uses the following data
+structures to represent the state of a request in progress in the
+resolver:
+
+SNAME           the domain name we are searching for.
+
+STYPE           the QTYPE of the search request.
+
+SCLASS          the QCLASS of the search request.
+
+SLIST           a structure which describes the name servers and the
+                zone which the resolver is currently trying to query.
+                This structure keeps track of the resolver's current
+                best guess about which name servers hold the desired
+                information; it is updated when arriving information
+                changes the guess.  This structure includes the
+                equivalent of a zone name, the known name servers for
+                the zone, the known addresses for the name servers, and
+                history information which can be used to suggest which
+                server is likely to be the best one to try next.  The
+                zone name equivalent is a match count of the number of
+                labels from the root down which SNAME has in common with
+                the zone being queried; this is used as a measure of how
+                "close" the resolver is to SNAME.
+
+SBELT           a "safety belt" structure of the same form as SLIST,
+                which is initialized from a configuration file, and
+                lists servers which should be used when the resolver
+                doesn't have any local information to guide name server
+                selection.  The match count will be -1 to indicate that
+                no labels are known to match.
+
+CACHE           A structure which stores the results from previous
+                responses.  Since resolvers are responsible for
+                discarding old RRs whose TTL has expired, most
+                implementations convert the interval specified in
+                arriving RRs to some sort of absolute time when the RR
+                is stored in the cache.  Instead of counting the TTLs
+                down individually, the resolver just ignores or discards
+                old RRs when it runs across them in the course of a
+                search, or discards them during periodic sweeps to
+                reclaim the memory consumed by old RRs.
+
+
+
+
+
+Mockapetris                                                    [Page 33]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+5.3.3. Algorithm
+
+The top level algorithm has four steps:
+
+   1. See if the answer is in local information, and if so return
+      it to the client.
+
+   2. Find the best servers to ask.
+
+   3. Send them queries until one returns a response.
+
+   4. Analyze the response, either:
+
+         a. if the response answers the question or contains a name
+            error, cache the data as well as returning it back to
+            the client.
+
+         b. if the response contains a better delegation to other
+            servers, cache the delegation information, and go to
+            step 2.
+
+         c. if the response shows a CNAME and that is not the
+            answer itself, cache the CNAME, change the SNAME to the
+            canonical name in the CNAME RR and go to step 1.
+
+         d. if the response shows a servers failure or other
+            bizarre contents, delete the server from the SLIST and
+            go back to step 3.
+
+Step 1 searches the cache for the desired data. If the data is in the
+cache, it is assumed to be good enough for normal use.  Some resolvers
+have an option at the user interface which will force the resolver to
+ignore the cached data and consult with an authoritative server.  This
+is not recommended as the default.  If the resolver has direct access to
+a name server's zones, it should check to see if the desired data is
+present in authoritative form, and if so, use the authoritative data in
+preference to cached data.
+
+Step 2 looks for a name server to ask for the required data.  The
+general strategy is to look for locally-available name server RRs,
+starting at SNAME, then the parent domain name of SNAME, the
+grandparent, and so on toward the root.  Thus if SNAME were
+Mockapetris.ISI.EDU, this step would look for NS RRs for
+Mockapetris.ISI.EDU, then ISI.EDU, then EDU, and then . (the root).
+These NS RRs list the names of hosts for a zone at or above SNAME.  Copy
+the names into SLIST.  Set up their addresses using local data.  It may
+be the case that the addresses are not available.  The resolver has many
+choices here; the best is to start parallel resolver processes looking
+
+
+
+Mockapetris                                                    [Page 34]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+for the addresses while continuing onward with the addresses which are
+available.  Obviously, the design choices and options are complicated
+and a function of the local host's capabilities.  The recommended
+priorities for the resolver designer are:
+
+   1. Bound the amount of work (packets sent, parallel processes
+      started) so that a request can't get into an infinite loop or
+      start off a chain reaction of requests or queries with other
+      implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED
+      SOME DATA.
+
+   2. Get back an answer if at all possible.
+
+   3. Avoid unnecessary transmissions.
+
+   4. Get the answer as quickly as possible.
+
+If the search for NS RRs fails, then the resolver initializes SLIST from
+the safety belt SBELT.  The basic idea is that when the resolver has no
+idea what servers to ask, it should use information from a configuration
+file that lists several servers which are expected to be helpful.
+Although there are special situations, the usual choice is two of the
+root servers and two of the servers for the host's domain.  The reason
+for two of each is for redundancy.  The root servers will provide
+eventual access to all of the domain space.  The two local servers will
+allow the resolver to continue to resolve local names if the local
+network becomes isolated from the internet due to gateway or link
+failure.
+
+In addition to the names and addresses of the servers, the SLIST data
+structure can be sorted to use the best servers first, and to insure
+that all addresses of all servers are used in a round-robin manner.  The
+sorting can be a simple function of preferring addresses on the local
+network over others, or may involve statistics from past events, such as
+previous response times and batting averages.
+
+Step 3 sends out queries until a response is received.  The strategy is
+to cycle around all of the addresses for all of the servers with a
+timeout between each transmission.  In practice it is important to use
+all addresses of a multihomed host, and too aggressive a retransmission
+policy actually slows response when used by multiple resolvers
+contending for the same name server and even occasionally for a single
+resolver.  SLIST typically contains data values to control the timeouts
+and keep track of previous transmissions.
+
+Step 4 involves analyzing responses.  The resolver should be highly
+paranoid in its parsing of responses.  It should also check that the
+response matches the query it sent using the ID field in the response.
+
+
+
+Mockapetris                                                    [Page 35]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+The ideal answer is one from a server authoritative for the query which
+either gives the required data or a name error.  The data is passed back
+to the user and entered in the cache for future use if its TTL is
+greater than zero.
+
+If the response shows a delegation, the resolver should check to see
+that the delegation is "closer" to the answer than the servers in SLIST
+are.  This can be done by comparing the match count in SLIST with that
+computed from SNAME and the NS RRs in the delegation.  If not, the reply
+is bogus and should be ignored.  If the delegation is valid the NS
+delegation RRs and any address RRs for the servers should be cached.
+The name servers are entered in the SLIST, and the search is restarted.
+
+If the response contains a CNAME, the search is restarted at the CNAME
+unless the response has the data for the canonical name or if the CNAME
+is the answer itself.
+
+Details and implementation hints can be found in [RFC-1035].
+
+6. A SCENARIO
+
+In our sample domain space, suppose we wanted separate administrative
+control for the root, MIL, EDU, MIT.EDU and ISI.EDU zones.  We might
+allocate name servers as follows:
+
+
+                                   |(C.ISI.EDU,SRI-NIC.ARPA
+                                   | A.ISI.EDU)
+             +---------------------+------------------+
+             |                     |                  |
+            MIL                   EDU                ARPA
+             |(SRI-NIC.ARPA,       |(SRI-NIC.ARPA,    |
+             | A.ISI.EDU           | C.ISI.EDU)       |
+       +-----+-----+               |     +------+-----+-----+
+       |     |     |               |     |      |           |
+      BRL  NOSC  DARPA             |  IN-ADDR  SRI-NIC     ACC
+                                   |
+       +--------+------------------+---------------+--------+
+       |        |                  |               |        |
+      UCI      MIT                 |              UDEL     YALE
+                |(XX.LCS.MIT.EDU, ISI
+                |ACHILLES.MIT.EDU) |(VAXA.ISI.EDU,VENERA.ISI.EDU,
+            +---+---+              | A.ISI.EDU)
+            |       |              |
+           LCS   ACHILLES +--+-----+-----+--------+
+            |             |  |     |     |        |
+            XX            A  C   VAXA  VENERA Mockapetris
+
+
+
+
+Mockapetris                                                    [Page 36]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+In this example, the authoritative name server is shown in parentheses
+at the point in the domain tree at which is assumes control.
+
+Thus the root name servers are on C.ISI.EDU, SRI-NIC.ARPA, and
+A.ISI.EDU.  The MIL domain is served by SRI-NIC.ARPA and A.ISI.EDU.  The
+EDU domain is served by SRI-NIC.ARPA. and C.ISI.EDU.  Note that servers
+may have zones which are contiguous or disjoint.  In this scenario,
+C.ISI.EDU has contiguous zones at the root and EDU domains.  A.ISI.EDU
+has contiguous zones at the root and MIL domains, but also has a non-
+contiguous zone at ISI.EDU.
+
+6.1. C.ISI.EDU name server
+
+C.ISI.EDU is a name server for the root, MIL, and EDU domains of the IN
+class, and would have zones for these domains.  The zone data for the
+root domain might be:
+
+    .       IN      SOA     SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
+                            870611          ;serial
+                            1800            ;refresh every 30 min
+                            300             ;retry every 5 min
+                            604800          ;expire after a week
+                            86400)          ;minimum of a day
+                    NS      A.ISI.EDU.
+                    NS      C.ISI.EDU.
+                    NS      SRI-NIC.ARPA.
+
+    MIL.    86400   NS      SRI-NIC.ARPA.
+            86400   NS      A.ISI.EDU.
+
+    EDU.    86400   NS      SRI-NIC.ARPA.
+            86400   NS      C.ISI.EDU.
+
+    SRI-NIC.ARPA.   A       26.0.0.73
+                    A       10.0.0.51
+                    MX      0 SRI-NIC.ARPA.
+                    HINFO   DEC-2060 TOPS20
+
+    ACC.ARPA.       A       26.6.0.65
+                    HINFO   PDP-11/70 UNIX
+                    MX      10 ACC.ARPA.
+
+    USC-ISIC.ARPA.  CNAME   C.ISI.EDU.
+
+    73.0.0.26.IN-ADDR.ARPA.  PTR    SRI-NIC.ARPA.
+    65.0.6.26.IN-ADDR.ARPA.  PTR    ACC.ARPA.
+    51.0.0.10.IN-ADDR.ARPA.  PTR    SRI-NIC.ARPA.
+    52.0.0.10.IN-ADDR.ARPA.  PTR    C.ISI.EDU.
+
+
+
+Mockapetris                                                    [Page 37]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+    103.0.3.26.IN-ADDR.ARPA. PTR    A.ISI.EDU.
+
+    A.ISI.EDU. 86400 A      26.3.0.103
+    C.ISI.EDU. 86400 A      10.0.0.52
+
+This data is represented as it would be in a master file.  Most RRs are
+single line entries; the sole exception here is the SOA RR, which uses
+"(" to start a multi-line RR and ")" to show the end of a multi-line RR.
+Since the class of all RRs in a zone must be the same, only the first RR
+in a zone need specify the class.  When a name server loads a zone, it
+forces the TTL of all authoritative RRs to be at least the MINIMUM field
+of the SOA, here 86400 seconds, or one day.  The NS RRs marking
+delegation of the MIL and EDU domains, together with the glue RRs for
+the servers host addresses, are not part of the authoritative data in
+the zone, and hence have explicit TTLs.
+
+Four RRs are attached to the root node: the SOA which describes the root
+zone and the 3 NS RRs which list the name servers for the root.  The
+data in the SOA RR describes the management of the zone.  The zone data
+is maintained on host SRI-NIC.ARPA, and the responsible party for the
+zone is HOSTMASTER@SRI-NIC.ARPA.  A key item in the SOA is the 86400
+second minimum TTL, which means that all authoritative data in the zone
+has at least that TTL, although higher values may be explicitly
+specified.
+
+The NS RRs for the MIL and EDU domains mark the boundary between the
+root zone and the MIL and EDU zones.  Note that in this example, the
+lower zones happen to be supported by name servers which also support
+the root zone.
+
+The master file for the EDU zone might be stated relative to the origin
+EDU.  The zone data for the EDU domain might be:
+
+    EDU.  IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
+                            870729 ;serial
+                            1800 ;refresh every 30 minutes
+                            300 ;retry every 5 minutes
+                            604800 ;expire after a week
+                            86400 ;minimum of a day
+                            )
+                    NS SRI-NIC.ARPA.
+                    NS C.ISI.EDU.
+
+    UCI 172800 NS ICS.UCI
+                    172800 NS ROME.UCI
+    ICS.UCI 172800 A 192.5.19.1
+    ROME.UCI 172800 A 192.5.19.31
+
+
+
+
+Mockapetris                                                    [Page 38]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+    ISI 172800 NS VAXA.ISI
+                    172800 NS A.ISI
+                    172800 NS VENERA.ISI.EDU.
+    VAXA.ISI 172800 A 10.2.0.27
+                    172800 A 128.9.0.33
+    VENERA.ISI.EDU. 172800 A 10.1.0.52
+                    172800 A 128.9.0.32
+    A.ISI 172800 A 26.3.0.103
+
+    UDEL.EDU.  172800 NS LOUIE.UDEL.EDU.
+                    172800 NS UMN-REI-UC.ARPA.
+    LOUIE.UDEL.EDU. 172800 A 10.0.0.96
+                    172800 A 192.5.39.3
+
+    YALE.EDU.  172800 NS YALE.ARPA.
+    YALE.EDU.  172800 NS YALE-BULLDOG.ARPA.
+
+    MIT.EDU.  43200 NS XX.LCS.MIT.EDU.
+                      43200 NS ACHILLES.MIT.EDU.
+    XX.LCS.MIT.EDU.  43200 A 10.0.0.44
+    ACHILLES.MIT.EDU. 43200 A 18.72.0.8
+
+Note the use of relative names here.  The owner name for the ISI.EDU. is
+stated using a relative name, as are two of the name server RR contents.
+Relative and absolute domain names may be freely intermixed in a master
+
+6.2. Example standard queries
+
+The following queries and responses illustrate name server behavior.
+Unless otherwise noted, the queries do not have recursion desired (RD)
+in the header.  Note that the answers to non-recursive queries do depend
+on the server being asked, but do not depend on the identity of the
+requester.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 39]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+6.2.1. QNAME=SRI-NIC.ARPA, QTYPE=A
+
+The query would look like:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY                                     |
+               +---------------------------------------------------+
+    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
+               +---------------------------------------------------+
+    Answer     | <empty>                                           |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+The response from C.ISI.EDU would be:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
+               +---------------------------------------------------+
+    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
+               +---------------------------------------------------+
+    Answer     | SRI-NIC.ARPA. 86400 IN A 26.0.0.73                |
+               |               86400 IN A 10.0.0.51                |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+The header of the response looks like the header of the query, except
+that the RESPONSE bit is set, indicating that this message is a
+response, not a query, and the Authoritative Answer (AA) bit is set
+indicating that the address RRs in the answer section are from
+authoritative data.  The question section of the response matches the
+question section of the query.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 40]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+If the same query was sent to some other server which was not
+authoritative for SRI-NIC.ARPA, the response might be:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY,RESPONSE                            |
+               +---------------------------------------------------+
+    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
+               +---------------------------------------------------+
+    Answer     | SRI-NIC.ARPA. 1777 IN A 10.0.0.51                 |
+               |               1777 IN A 26.0.0.73                 |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+This response is different from the previous one in two ways: the header
+does not have AA set, and the TTLs are different.  The inference is that
+the data did not come from a zone, but from a cache.  The difference
+between the authoritative TTL and the TTL here is due to aging of the
+data in a cache.  The difference in ordering of the RRs in the answer
+section is not significant.
+
+6.2.2. QNAME=SRI-NIC.ARPA, QTYPE=*
+
+A query similar to the previous one, but using a QTYPE of *, would
+receive the following response from C.ISI.EDU:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
+               +---------------------------------------------------+
+    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
+               +---------------------------------------------------+
+    Answer     | SRI-NIC.ARPA. 86400 IN  A     26.0.0.73           |
+               |                         A     10.0.0.51           |
+               |                         MX    0 SRI-NIC.ARPA.     |
+               |                         HINFO DEC-2060 TOPS20     |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 41]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+If a similar query was directed to two name servers which are not
+authoritative for SRI-NIC.ARPA, the responses might be:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE                           |
+               +---------------------------------------------------+
+    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
+               +---------------------------------------------------+
+    Answer     | SRI-NIC.ARPA. 12345 IN     A       26.0.0.73      |
+               |                            A       10.0.0.51      |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+and
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE                           |
+               +---------------------------------------------------+
+    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
+               +---------------------------------------------------+
+    Answer     | SRI-NIC.ARPA. 1290 IN HINFO  DEC-2060 TOPS20      |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+Neither of these answers have AA set, so neither response comes from
+authoritative data.  The different contents and different TTLs suggest
+that the two servers cached data at different times, and that the first
+server cached the response to a QTYPE=A query and the second cached the
+response to a HINFO query.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 42]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+6.2.3. QNAME=SRI-NIC.ARPA, QTYPE=MX
+
+This type of query might be result from a mailer trying to look up
+routing information for the mail destination HOSTMASTER@SRI-NIC.ARPA.
+The response from C.ISI.EDU would be:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
+               +---------------------------------------------------+
+    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=MX          |
+               +---------------------------------------------------+
+    Answer     | SRI-NIC.ARPA. 86400 IN     MX      0 SRI-NIC.ARPA.|
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | SRI-NIC.ARPA. 86400 IN     A       26.0.0.73      |
+               |                            A       10.0.0.51      |
+               +---------------------------------------------------+
+
+This response contains the MX RR in the answer section of the response.
+The additional section contains the address RRs because the name server
+at C.ISI.EDU guesses that the requester will need the addresses in order
+to properly use the information carried by the MX.
+
+6.2.4. QNAME=SRI-NIC.ARPA, QTYPE=NS
+
+C.ISI.EDU would reply to this query with:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
+               +---------------------------------------------------+
+    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=NS          |
+               +---------------------------------------------------+
+    Answer     | <empty>                                           |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+The only difference between the response and the query is the AA and
+RESPONSE bits in the header.  The interpretation of this response is
+that the server is authoritative for the name, and the name exists, but
+no RRs of type NS are present there.
+
+6.2.5. QNAME=SIR-NIC.ARPA, QTYPE=A
+
+If a user mistyped a host name, we might see this type of query.
+
+
+
+Mockapetris                                                    [Page 43]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+C.ISI.EDU would answer it with:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE, AA, RCODE=NE             |
+               +---------------------------------------------------+
+    Question   | QNAME=SIR-NIC.ARPA., QCLASS=IN, QTYPE=A           |
+               +---------------------------------------------------+
+    Answer     | <empty>                                           |
+               +---------------------------------------------------+
+    Authority  | . SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA.      |
+               |       870611 1800 300 604800 86400                |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+This response states that the name does not exist.  This condition is
+signalled in the response code (RCODE) section of the header.
+
+The SOA RR in the authority section is the optional negative caching
+information which allows the resolver using this response to assume that
+the name will not exist for the SOA MINIMUM (86400) seconds.
+
+6.2.6. QNAME=BRL.MIL, QTYPE=A
+
+If this query is sent to C.ISI.EDU, the reply would be:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE                           |
+               +---------------------------------------------------+
+    Question   | QNAME=BRL.MIL, QCLASS=IN, QTYPE=A                 |
+               +---------------------------------------------------+
+    Answer     | <empty>                                           |
+               +---------------------------------------------------+
+    Authority  | MIL.             86400 IN NS       SRI-NIC.ARPA.  |
+               |                  86400    NS       A.ISI.EDU.     |
+               +---------------------------------------------------+
+    Additional | A.ISI.EDU.                A        26.3.0.103     |
+               | SRI-NIC.ARPA.             A        26.0.0.73      |
+               |                           A        10.0.0.51      |
+               +---------------------------------------------------+
+
+This response has an empty answer section, but is not authoritative, so
+it is a referral.  The name server on C.ISI.EDU, realizing that it is
+not authoritative for the MIL domain, has referred the requester to
+servers on A.ISI.EDU and SRI-NIC.ARPA, which it knows are authoritative
+for the MIL domain.
+
+
+
+
+
+Mockapetris                                                    [Page 44]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+6.2.7. QNAME=USC-ISIC.ARPA, QTYPE=A
+
+The response to this query from A.ISI.EDU would be:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
+               +---------------------------------------------------+
+    Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
+               +---------------------------------------------------+
+    Answer     | USC-ISIC.ARPA. 86400 IN CNAME      C.ISI.EDU.     |
+               | C.ISI.EDU.     86400 IN A          10.0.0.52      |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+Note that the AA bit in the header guarantees that the data matching
+QNAME is authoritative, but does not say anything about whether the data
+for C.ISI.EDU is authoritative.  This complete reply is possible because
+A.ISI.EDU happens to be authoritative for both the ARPA domain where
+USC-ISIC.ARPA is found and the ISI.EDU domain where C.ISI.EDU data is
+found.
+
+If the same query was sent to C.ISI.EDU, its response might be the same
+as shown above if it had its own address in its cache, but might also
+be:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 45]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
+               +---------------------------------------------------+
+    Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
+               +---------------------------------------------------+
+    Answer     | USC-ISIC.ARPA.   86400 IN CNAME   C.ISI.EDU.      |
+               +---------------------------------------------------+
+    Authority  | ISI.EDU.        172800 IN NS      VAXA.ISI.EDU.   |
+               |                           NS      A.ISI.EDU.      |
+               |                           NS      VENERA.ISI.EDU. |
+               +---------------------------------------------------+
+    Additional | VAXA.ISI.EDU.   172800    A       10.2.0.27       |
+               |                 172800    A       128.9.0.33      |
+               | VENERA.ISI.EDU. 172800    A       10.1.0.52       |
+               |                 172800    A       128.9.0.32      |
+               | A.ISI.EDU.      172800    A       26.3.0.103      |
+               +---------------------------------------------------+
+
+This reply contains an authoritative reply for the alias USC-ISIC.ARPA,
+plus a referral to the name servers for ISI.EDU.  This sort of reply
+isn't very likely given that the query is for the host name of the name
+server being asked, but would be common for other aliases.
+
+6.2.8. QNAME=USC-ISIC.ARPA, QTYPE=CNAME
+
+If this query is sent to either A.ISI.EDU or C.ISI.EDU, the reply would
+be:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
+               +---------------------------------------------------+
+    Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
+               +---------------------------------------------------+
+    Answer     | USC-ISIC.ARPA. 86400 IN CNAME      C.ISI.EDU.     |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+Because QTYPE=CNAME, the CNAME RR itself answers the query, and the name
+server doesn't attempt to look up anything for C.ISI.EDU.  (Except
+possibly for the additional section.)
+
+6.3. Example resolution
+
+The following examples illustrate the operations a resolver must perform
+for its client.  We assume that the resolver is starting without a
+
+
+
+Mockapetris                                                    [Page 46]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+cache, as might be the case after system boot.  We further assume that
+the system is not one of the hosts in the data and that the host is
+located somewhere on net 26, and that its safety belt (SBELT) data
+structure has the following information:
+
+    Match count = -1
+    SRI-NIC.ARPA.   26.0.0.73       10.0.0.51
+    A.ISI.EDU.      26.3.0.103
+
+This information specifies servers to try, their addresses, and a match
+count of -1, which says that the servers aren't very close to the
+target.  Note that the -1 isn't supposed to be an accurate closeness
+measure, just a value so that later stages of the algorithm will work.
+
+The following examples illustrate the use of a cache, so each example
+assumes that previous requests have completed.
+
+6.3.1. Resolve MX for ISI.EDU.
+
+Suppose the first request to the resolver comes from the local mailer,
+which has mail for PVM@ISI.EDU.  The mailer might then ask for type MX
+RRs for the domain name ISI.EDU.
+
+The resolver would look in its cache for MX RRs at ISI.EDU, but the
+empty cache wouldn't be helpful.  The resolver would recognize that it
+needed to query foreign servers and try to determine the best servers to
+query.  This search would look for NS RRs for the domains ISI.EDU, EDU,
+and the root.  These searches of the cache would also fail.  As a last
+resort, the resolver would use the information from the SBELT, copying
+it into its SLIST structure.
+
+At this point the resolver would need to pick one of the three available
+addresses to try.  Given that the resolver is on net 26, it should
+choose either 26.0.0.73 or 26.3.0.103 as its first choice.  It would
+then send off a query of the form:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 47]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY                                     |
+               +---------------------------------------------------+
+    Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
+               +---------------------------------------------------+
+    Answer     | <empty>                                           |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+The resolver would then wait for a response to its query or a timeout.
+If the timeout occurs, it would try different servers, then different
+addresses of the same servers, lastly retrying addresses already tried.
+It might eventually receive a reply from SRI-NIC.ARPA:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE                           |
+               +---------------------------------------------------+
+    Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
+               +---------------------------------------------------+
+    Answer     | <empty>                                           |
+               +---------------------------------------------------+
+    Authority  | ISI.EDU.        172800 IN NS       VAXA.ISI.EDU.  |
+               |                           NS       A.ISI.EDU.     |
+               |                           NS       VENERA.ISI.EDU.|
+               +---------------------------------------------------+
+    Additional | VAXA.ISI.EDU.   172800    A        10.2.0.27      |
+               |                 172800    A        128.9.0.33     |
+               | VENERA.ISI.EDU. 172800    A        10.1.0.52      |
+               |                 172800    A        128.9.0.32     |
+               | A.ISI.EDU.      172800    A        26.3.0.103     |
+               +---------------------------------------------------+
+
+The resolver would notice that the information in the response gave a
+closer delegation to ISI.EDU than its existing SLIST (since it matches
+three labels).  The resolver would then cache the information in this
+response and use it to set up a new SLIST:
+
+    Match count = 3
+    A.ISI.EDU.      26.3.0.103
+    VAXA.ISI.EDU.   10.2.0.27       128.9.0.33
+    VENERA.ISI.EDU. 10.1.0.52       128.9.0.32
+
+A.ISI.EDU appears on this list as well as the previous one, but that is
+purely coincidental.  The resolver would again start transmitting and
+waiting for responses.  Eventually it would get an answer:
+
+
+
+Mockapetris                                                    [Page 48]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
+               +---------------------------------------------------+
+    Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
+               +---------------------------------------------------+
+    Answer     | ISI.EDU.                MX 10 VENERA.ISI.EDU.     |
+               |                         MX 20 VAXA.ISI.EDU.       |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | VAXA.ISI.EDU.   172800  A  10.2.0.27              |
+               |                 172800  A  128.9.0.33             |
+               | VENERA.ISI.EDU. 172800  A  10.1.0.52              |
+               |                 172800  A  128.9.0.32             |
+               +---------------------------------------------------+
+
+The resolver would add this information to its cache, and return the MX
+RRs to its client.
+
+6.3.2. Get the host name for address 26.6.0.65
+
+The resolver would translate this into a request for PTR RRs for
+65.0.6.26.IN-ADDR.ARPA.  This information is not in the cache, so the
+resolver would look for foreign servers to ask.  No servers would match,
+so it would use SBELT again.  (Note that the servers for the ISI.EDU
+domain are in the cache, but ISI.EDU is not an ancestor of
+65.0.6.26.IN-ADDR.ARPA, so the SBELT is used.)
+
+Since this request is within the authoritative data of both servers in
+SBELT, eventually one would return:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 49]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
+               +---------------------------------------------------+
+    Question   | QNAME=65.0.6.26.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=PTR |
+               +---------------------------------------------------+
+    Answer     | 65.0.6.26.IN-ADDR.ARPA.    PTR     ACC.ARPA.      |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+6.3.3. Get the host address of poneria.ISI.EDU
+
+This request would translate into a type A request for poneria.ISI.EDU.
+The resolver would not find any cached data for this name, but would
+find the NS RRs in the cache for ISI.EDU when it looks for foreign
+servers to ask.  Using this data, it would construct a SLIST of the
+form:
+
+    Match count = 3
+
+    A.ISI.EDU.      26.3.0.103
+    VAXA.ISI.EDU.   10.2.0.27       128.9.0.33
+    VENERA.ISI.EDU. 10.1.0.52
+
+A.ISI.EDU is listed first on the assumption that the resolver orders its
+choices by preference, and A.ISI.EDU is on the same network.
+
+One of these servers would answer the query.
+
+7. REFERENCES and BIBLIOGRAPHY
+
+[Dyer 87]       Dyer, S., and F. Hsu, "Hesiod", Project Athena
+                Technical Plan - Name Service, April 1987, version 1.9.
+
+                Describes the fundamentals of the Hesiod name service.
+
+[IEN-116]       J. Postel, "Internet Name Server", IEN-116,
+                USC/Information Sciences Institute, August 1979.
+
+                A name service obsoleted by the Domain Name System, but
+                still in use.
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 50]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+[Quarterman 86] Quarterman, J., and J. Hoskins, "Notable Computer
+                Networks",Communications of the ACM, October 1986,
+                volume 29, number 10.
+
+[RFC-742]       K. Harrenstien, "NAME/FINGER", RFC-742, Network
+                Information Center, SRI International, December 1977.
+
+[RFC-768]       J. Postel, "User Datagram Protocol", RFC-768,
+                USC/Information Sciences Institute, August 1980.
+
+[RFC-793]       J. Postel, "Transmission Control Protocol", RFC-793,
+                USC/Information Sciences Institute, September 1981.
+
+[RFC-799]       D. Mills, "Internet Name Domains", RFC-799, COMSAT,
+                September 1981.
+
+                Suggests introduction of a hierarchy in place of a flat
+                name space for the Internet.
+
+[RFC-805]       J. Postel, "Computer Mail Meeting Notes", RFC-805,
+                USC/Information Sciences Institute, February 1982.
+
+[RFC-810]       E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD
+                Internet Host Table Specification", RFC-810, Network
+                Information Center, SRI International, March 1982.
+
+                Obsolete.  See RFC-952.
+
+[RFC-811]       K. Harrenstien, V. White, and E. Feinler, "Hostnames
+                Server", RFC-811, Network Information Center, SRI
+                International, March 1982.
+
+                Obsolete.  See RFC-953.
+
+[RFC-812]       K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,
+                Network Information Center, SRI International, March
+                1982.
+
+[RFC-819]       Z. Su, and J. Postel, "The Domain Naming Convention for
+                Internet User Applications", RFC-819, Network
+                Information Center, SRI International, August 1982.
+
+                Early thoughts on the design of the domain system.
+                Current implementation is completely different.
+
+[RFC-821]       J. Postel, "Simple Mail Transfer Protocol", RFC-821,
+                USC/Information Sciences Institute, August 1980.
+
+
+
+
+Mockapetris                                                    [Page 51]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+[RFC-830]       Z. Su, "A Distributed System for Internet Name Service",
+                RFC-830, Network Information Center, SRI International,
+                October 1982.
+
+                Early thoughts on the design of the domain system.
+                Current implementation is completely different.
+
+[RFC-882]       P. Mockapetris, "Domain names - Concepts and
+                Facilities," RFC-882, USC/Information Sciences
+                Institute, November 1983.
+
+                Superceeded by this memo.
+
+[RFC-883]       P. Mockapetris, "Domain names - Implementation and
+                Specification," RFC-883, USC/Information Sciences
+                Institute, November 1983.
+
+                Superceeded by this memo.
+
+[RFC-920]       J. Postel and J. Reynolds, "Domain Requirements",
+                RFC-920, USC/Information Sciences Institute
+                October 1984.
+
+                Explains the naming scheme for top level domains.
+
+[RFC-952]       K. Harrenstien, M. Stahl, 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-953]       K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",
+                RFC-953, SRI, October 1985.
+
+                This RFC contains the official specification of the
+                hostname server protocol, which is obsoleted by the DNS.
+                This TCP based protocol accesses information stored in
+                the RFC-952 format, and is used to obtain copies of the
+                host table.
+
+[RFC-973]       P. Mockapetris, "Domain System Changes and
+                Observations", RFC-973, USC/Information Sciences
+                Institute, January 1986.
+
+                Describes changes to RFC-882 and RFC-883 and reasons for
+                them.  Now obsolete.
+
+
+
+
+
+Mockapetris                                                    [Page 52]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+[RFC-974]       C. Partridge, "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.
+
+[RFC-1001]      NetBIOS Working Group, "Protocol standard for a NetBIOS
+                service on a TCP/UDP transport: Concepts and Methods",
+                RFC-1001, March 1987.
+
+                This RFC and RFC-1002 are a preliminary design for
+                NETBIOS on top of TCP/IP which proposes to base NetBIOS
+                name service on top of the DNS.
+
+[RFC-1002]      NetBIOS Working Group, "Protocol standard for a NetBIOS
+                service on a TCP/UDP transport: Detailed
+                Specifications", RFC-1002, March 1987.
+
+[RFC-1010]      J. Reynolds 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-1031]      W. Lazear, "MILNET Name Domain Transition", RFC-1031,
+                November 1987.
+
+                Describes a plan for converting the MILNET to the DNS.
+
+[RFC-1032]      M. K. Stahl, "Establishing a Domain - Guidelines for
+                Administrators", RFC-1032, November 1987.
+
+                Describes the registration policies used by the NIC to
+                administer the top level domains and delegate subzones.
+
+[RFC-1033]      M. K. Lottor, "Domain Administrators Operations Guide",
+                RFC-1033, November 1987.
+
+                A cookbook for domain administrators.
+
+[Solomon 82]    M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET
+                Name Server", Computer Networks, vol 6, nr 3, July 1982.
+
+                Describes a name service for CSNET which is independent
+                from the DNS and DNS use in the CSNET.
+
+
+
+
+
+Mockapetris                                                    [Page 53]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+Index
+
+          A   12
+          Absolute names   8
+          Aliases   14, 31
+          Authority   6
+          AXFR   17
+
+          Case of characters   7
+          CH   12
+          CNAME   12, 13, 31
+          Completion queries   18
+
+          Domain name   6, 7
+
+          Glue RRs   20
+
+          HINFO   12
+
+          IN   12
+          Inverse queries   16
+          Iterative   4
+
+          Label   7
+
+          Mailbox names   9
+          MX   12
+
+          Name error   27, 36
+          Name servers   5, 17
+          NE   30
+          Negative caching   44
+          NS   12
+
+          Opcode   16
+
+          PTR   12
+
+          QCLASS   16
+          QTYPE   16
+
+          RDATA   13
+          Recursive   4
+          Recursive service   22
+          Relative names   7
+          Resolvers   6
+          RR   12
+
+
+
+
+Mockapetris                                                    [Page 54]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+          Safety belt   33
+          Sections   16
+          SOA   12
+          Standard queries   22
+
+          Status queries   18
+          Stub resolvers   32
+
+          TTL   12, 13
+
+          Wildcards   25
+
+          Zone transfers   28
+          Zones   19
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 55]
+
diff --git a/usr.sbin/named/doc/rfc/rfc1035 b/usr.sbin/named/doc/rfc/rfc1035
new file mode 100644
index 00000000000..b1a9bf5a94b
--- /dev/null
+++ b/usr.sbin/named/doc/rfc/rfc1035
@@ -0,0 +1,3077 @@
+Network Working Group                                     P. Mockapetris
+Request for Comments: 1035                                           ISI
+                                                           November 1987
+Obsoletes: RFCs 882, 883, 973
+
+            DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
+
+
+1. STATUS OF THIS MEMO
+
+This RFC describes the details of the domain system and protocol, and
+assumes that the reader is familiar with the concepts discussed in a
+companion RFC, "Domain Names - Concepts and Facilities" [RFC-1034].
+
+The domain system is a mixture of functions and data types which are an
+official protocol and functions and data types which are still
+experimental.  Since the domain system is intentionally extensible, new
+data types and experimental behavior should always be expected in parts
+of the system beyond the official protocol.  The official protocol parts
+include standard queries, responses and the Internet class RR data
+formats (e.g., host addresses).  Since the previous RFC set, several
+definitions have changed, so some previous definitions are obsolete.
+
+Experimental or obsolete features are clearly marked in these RFCs, and
+such information should be used with caution.
+
+The reader is especially cautioned not to depend on the values which
+appear in examples to be current or complete, since their purpose is
+primarily pedagogical.  Distribution of this memo is unlimited.
+
+                           Table of Contents
+
+  1. STATUS OF THIS MEMO                                              1
+  2. INTRODUCTION                                                     3
+      2.1. Overview                                                   3
+      2.2. Common configurations                                      4
+      2.3. Conventions                                                7
+          2.3.1. Preferred name syntax                                7
+          2.3.2. Data Transmission Order                              8
+          2.3.3. Character Case                                       9
+          2.3.4. Size limits                                         10
+  3. DOMAIN NAME SPACE AND RR DEFINITIONS                            10
+      3.1. Name space definitions                                    10
+      3.2. RR definitions                                            11
+          3.2.1. Format                                              11
+          3.2.2. TYPE values                                         12
+          3.2.3. QTYPE values                                        12
+          3.2.4. CLASS values                                        13
+
+
+
+Mockapetris                                                     [Page 1]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+          3.2.5. QCLASS values                                       13
+      3.3. Standard RRs                                              13
+          3.3.1. CNAME RDATA format                                  14
+          3.3.2. HINFO RDATA format                                  14
+          3.3.3. MB RDATA format (EXPERIMENTAL)                      14
+          3.3.4. MD RDATA format (Obsolete)                          15
+          3.3.5. MF RDATA format (Obsolete)                          15
+          3.3.6. MG RDATA format (EXPERIMENTAL)                      16
+          3.3.7. MINFO RDATA format (EXPERIMENTAL)                   16
+          3.3.8. MR RDATA format (EXPERIMENTAL)                      17
+          3.3.9. MX RDATA format                                     17
+          3.3.10. NULL RDATA format (EXPERIMENTAL)                   17
+          3.3.11. NS RDATA format                                    18
+          3.3.12. PTR RDATA format                                   18
+          3.3.13. SOA RDATA format                                   19
+          3.3.14. TXT RDATA format                                   20
+      3.4. ARPA Internet specific RRs                                20
+          3.4.1. A RDATA format                                      20
+          3.4.2. WKS RDATA format                                    21
+      3.5. IN-ADDR.ARPA domain                                       22
+      3.6. Defining new types, classes, and special namespaces       24
+  4. MESSAGES                                                        25
+      4.1. Format                                                    25
+          4.1.1. Header section format                               26
+          4.1.2. Question section format                             28
+          4.1.3. Resource record format                              29
+          4.1.4. Message compression                                 30
+      4.2. Transport                                                 32
+          4.2.1. UDP usage                                           32
+          4.2.2. TCP usage                                           32
+  5. MASTER FILES                                                    33
+      5.1. Format                                                    33
+      5.2. Use of master files to define zones                       35
+      5.3. Master file example                                       36
+  6. NAME SERVER IMPLEMENTATION                                      37
+      6.1. Architecture                                              37
+          6.1.1. Control                                             37
+          6.1.2. Database                                            37
+          6.1.3. Time                                                39
+      6.2. Standard query processing                                 39
+      6.3. Zone refresh and reload processing                        39
+      6.4. Inverse queries (Optional)                                40
+          6.4.1. The contents of inverse queries and responses       40
+          6.4.2. Inverse query and response example                  41
+          6.4.3. Inverse query processing                            42
+
+
+
+
+
+
+Mockapetris                                                     [Page 2]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+      6.5. Completion queries and responses                          42
+  7. RESOLVER IMPLEMENTATION                                         43
+      7.1. Transforming a user request into a query                  43
+      7.2. Sending the queries                                       44
+      7.3. Processing responses                                      46
+      7.4. Using the cache                                           47
+  8. MAIL SUPPORT                                                    47
+      8.1. Mail exchange binding                                     48
+      8.2. Mailbox binding (Experimental)                            48
+  9. REFERENCES and BIBLIOGRAPHY                                     50
+  Index                                                              54
+
+2. INTRODUCTION
+
+2.1. Overview
+
+The goal of domain names is to provide a mechanism for naming resources
+in such a way that the names are usable in different hosts, networks,
+protocol families, internets, and administrative organizations.
+
+From the user's point of view, domain names are useful as arguments to a
+local agent, called a resolver, which retrieves information associated
+with the domain name.  Thus a user might ask for the host address or
+mail information associated with a particular domain name.  To enable
+the user to request a particular type of information, an appropriate
+query type is passed to the resolver with the domain name.  To the user,
+the domain tree is a single information space; the resolver is
+responsible for hiding the distribution of data among name servers from
+the user.
+
+From the resolver's point of view, the database that makes up the domain
+space is distributed among various name servers.  Different parts of the
+domain space are stored in different name servers, although a particular
+data item will be stored redundantly in two or more name servers.  The
+resolver starts with knowledge of at least one name server.  When the
+resolver processes a user query it asks a known name server for the
+information; in return, the resolver either receives the desired
+information or a referral to another name server.  Using these
+referrals, resolvers learn the identities and contents of other name
+servers.  Resolvers are responsible for dealing with the distribution of
+the domain space and dealing with the effects of name server failure by
+consulting redundant databases in other servers.
+
+Name servers manage two kinds of data.  The first kind of data held in
+sets called zones; each zone is the complete database for a particular
+"pruned" subtree of the domain space.  This data is called
+authoritative.  A name server periodically checks to make sure that its
+zones are up to date, and if not, obtains a new copy of updated zones
+
+
+
+Mockapetris                                                     [Page 3]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+from master files stored locally or in another name server.  The second
+kind of data is cached data which was acquired by a local resolver.
+This data may be incomplete, but improves the performance of the
+retrieval process when non-local data is repeatedly accessed.  Cached
+data is eventually discarded by a timeout mechanism.
+
+This functional structure isolates the problems of user interface,
+failure recovery, and distribution in the resolvers and isolates the
+database update and refresh problems in the name servers.
+
+2.2. Common configurations
+
+A host can participate in the domain name system in a number of ways,
+depending on whether the host runs programs that retrieve information
+from the domain system, name servers that answer queries from other
+hosts, or various combinations of both functions.  The simplest, and
+perhaps most typical, configuration is shown below:
+
+                 Local Host                        |  Foreign
+                                                   |
+    +---------+               +----------+         |  +--------+
+    |         | user queries  |          |queries  |  |        |
+    |  User   |-------------->|          |---------|->|Foreign |
+    | Program |               | Resolver |         |  |  Name  |
+    |         |<--------------|          |<--------|--| Server |
+    |         | user responses|          |responses|  |        |
+    +---------+               +----------+         |  +--------+
+                                |     A            |
+                cache additions |     | references |
+                                V     |            |
+                              +----------+         |
+                              |  cache   |         |
+                              +----------+         |
+
+User programs interact with the domain name space through resolvers; the
+format of user queries and user responses is specific to the host and
+its operating system.  User queries will typically be operating system
+calls, and the resolver and its cache will be part of the host operating
+system.  Less capable hosts may choose to implement the resolver as a
+subroutine to be linked in with every program that needs its services.
+Resolvers answer user queries with information they acquire via queries
+to foreign name servers and the local cache.
+
+Note that the resolver may have to make several queries to several
+different foreign name servers to answer a particular user query, and
+hence the resolution of a user query may involve several network
+accesses and an arbitrary amount of time.  The queries to foreign name
+servers and the corresponding responses have a standard format described
+
+
+
+Mockapetris                                                     [Page 4]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+in this memo, and may be datagrams.
+
+Depending on its capabilities, a name server could be a stand alone
+program on a dedicated machine or a process or processes on a large
+timeshared host.  A simple configuration might be:
+
+                 Local Host                        |  Foreign
+                                                   |
+      +---------+                                  |
+     /         /|                                  |
+    +---------+ |             +----------+         |  +--------+
+    |         | |             |          |responses|  |        |
+    |         | |             |   Name   |---------|->|Foreign |
+    |  Master |-------------->|  Server  |         |  |Resolver|
+    |  files  | |             |          |<--------|--|        |
+    |         |/              |          | queries |  +--------+
+    +---------+               +----------+         |
+
+Here a primary name server acquires information about one or more zones
+by reading master files from its local file system, and answers queries
+about those zones that arrive from foreign resolvers.
+
+The DNS requires that all zones be redundantly supported by more than
+one name server.  Designated secondary servers can acquire zones and
+check for updates from the primary server using the zone transfer
+protocol of the DNS.  This configuration is shown below:
+
+                 Local Host                        |  Foreign
+                                                   |
+      +---------+                                  |
+     /         /|                                  |
+    +---------+ |             +----------+         |  +--------+
+    |         | |             |          |responses|  |        |
+    |         | |             |   Name   |---------|->|Foreign |
+    |  Master |-------------->|  Server  |         |  |Resolver|
+    |  files  | |             |          |<--------|--|        |
+    |         |/              |          | queries |  +--------+
+    +---------+               +----------+         |
+                                A     |maintenance |  +--------+
+                                |     +------------|->|        |
+                                |      queries     |  |Foreign |
+                                |                  |  |  Name  |
+                                +------------------|--| Server |
+                             maintenance responses |  +--------+
+
+In this configuration, the name server periodically establishes a
+virtual circuit to a foreign name server to acquire a copy of a zone or
+to check that an existing copy has not changed.  The messages sent for
+
+
+
+Mockapetris                                                     [Page 5]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+these maintenance activities follow the same form as queries and
+responses, but the message sequences are somewhat different.
+
+The information flow in a host that supports all aspects of the domain
+name system is shown below:
+
+                 Local Host                        |  Foreign
+                                                   |
+    +---------+               +----------+         |  +--------+
+    |         | user queries  |          |queries  |  |        |
+    |  User   |-------------->|          |---------|->|Foreign |
+    | Program |               | Resolver |         |  |  Name  |
+    |         |<--------------|          |<--------|--| Server |
+    |         | user responses|          |responses|  |        |
+    +---------+               +----------+         |  +--------+
+                                |     A            |
+                cache additions |     | references |
+                                V     |            |
+                              +----------+         |
+                              |  Shared  |         |
+                              | database |         |
+                              +----------+         |
+                                A     |            |
+      +---------+     refreshes |     | references |
+     /         /|               |     V            |
+    +---------+ |             +----------+         |  +--------+
+    |         | |             |          |responses|  |        |
+    |         | |             |   Name   |---------|->|Foreign |
+    |  Master |-------------->|  Server  |         |  |Resolver|
+    |  files  | |             |          |<--------|--|        |
+    |         |/              |          | queries |  +--------+
+    +---------+               +----------+         |
+                                A     |maintenance |  +--------+
+                                |     +------------|->|        |
+                                |      queries     |  |Foreign |
+                                |                  |  |  Name  |
+                                +------------------|--| Server |
+                             maintenance responses |  +--------+
+
+The shared database holds domain space data for the local name server
+and resolver.  The contents of the shared database will typically be a
+mixture of authoritative data maintained by the periodic refresh
+operations of the name server and cached data from previous resolver
+requests.  The structure of the domain data and the necessity for
+synchronization between name servers and resolvers imply the general
+characteristics of this database, but the actual format is up to the
+local implementor.
+
+
+
+
+Mockapetris                                                     [Page 6]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+Information flow can also be tailored so that a group of hosts act
+together to optimize activities.  Sometimes this is done to offload less
+capable hosts so that they do not have to implement a full resolver.
+This can be appropriate for PCs or hosts which want to minimize the
+amount of new network code which is required.  This scheme can also
+allow a group of hosts can share a small number of caches rather than
+maintaining a large number of separate caches, on the premise that the
+centralized caches will have a higher hit ratio.  In either case,
+resolvers are replaced with stub resolvers which act as front ends to
+resolvers located in a recursive server in one or more name servers
+known to perform that service:
+
+                   Local Hosts                     |  Foreign
+                                                   |
+    +---------+                                    |
+    |         | responses                          |
+    | Stub    |<--------------------+              |
+    | Resolver|                     |              |
+    |         |----------------+    |              |
+    +---------+ recursive      |    |              |
+                queries        |    |              |
+                               V    |              |
+    +---------+ recursive     +----------+         |  +--------+
+    |         | queries       |          |queries  |  |        |
+    | Stub    |-------------->| Recursive|---------|->|Foreign |
+    | Resolver|               | Server   |         |  |  Name  |
+    |         |<--------------|          |<--------|--| Server |
+    +---------+ responses     |          |responses|  |        |
+                              +----------+         |  +--------+
+                              |  Central |         |
+                              |   cache  |         |
+                              +----------+         |
+
+In any case, note that domain components are always replicated for
+reliability whenever possible.
+
+2.3. Conventions
+
+The domain system has several conventions dealing with low-level, but
+fundamental, issues.  While the implementor is free to violate these
+conventions WITHIN HIS OWN SYSTEM, he must observe these conventions in
+ALL behavior observed from other hosts.
+
+2.3.1. Preferred name syntax
+
+The DNS specifications attempt to be as general as possible in the rules
+for constructing domain names.  The idea is that the name of any
+existing object can be expressed as a domain name with minimal changes.
+
+
+
+Mockapetris                                                     [Page 7]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+However, when assigning a domain name for an object, the prudent user
+will select a name which satisfies both the rules of the domain system
+and any existing rules for the object, whether these rules are published
+or implied by existing programs.
+
+For example, when naming a mail domain, the user should satisfy both the
+rules of this memo and those in RFC-822.  When creating a new host name,
+the old rules for HOSTS.TXT should be followed.  This avoids problems
+when old software is converted to use domain names.
+
+The following syntax will result in fewer problems with many
+
+applications that use domain names (e.g., mail, TELNET).
+
+<domain> ::= <subdomain> | " "
+
+<subdomain> ::= <label> | <subdomain> "." <label>
+
+<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
+
+<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
+
+<let-dig-hyp> ::= <let-dig> | "-"
+
+<let-dig> ::= <letter> | <digit>
+
+<letter> ::= any one of the 52 alphabetic characters A through Z in
+upper case and a through z in lower case
+
+<digit> ::= any one of the ten digits 0 through 9
+
+Note that while upper and lower case letters are allowed in domain
+names, no significance is attached to the case.  That is, two names with
+the same spelling but different case are to be treated as if identical.
+
+The labels must follow the rules for ARPANET host names.  They must
+start with a letter, end with a letter or digit, and have as interior
+characters only letters, digits, and hyphen.  There are also some
+restrictions on the length.  Labels must be 63 characters or less.
+
+For example, the following strings identify hosts in the Internet:
+
+A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
+
+2.3.2. Data Transmission Order
+
+The order of transmission of the header and data described in this
+document is resolved to the octet level.  Whenever a diagram shows a
+
+
+
+Mockapetris                                                     [Page 8]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+group of octets, the order of transmission of those octets is the normal
+order in which they are read in English.  For example, in the following
+diagram, the octets are transmitted in the order they are numbered.
+
+     0                   1
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |       1       |       2       |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |       3       |       4       |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |       5       |       6       |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+Whenever an octet represents a numeric quantity, the left most bit in
+the diagram is the high order or most significant bit.  That is, the bit
+labeled 0 is the most significant bit.  For example, the following
+diagram represents the value 170 (decimal).
+
+     0 1 2 3 4 5 6 7
+    +-+-+-+-+-+-+-+-+
+    |1 0 1 0 1 0 1 0|
+    +-+-+-+-+-+-+-+-+
+
+Similarly, whenever a multi-octet field represents a numeric quantity
+the left most bit of the whole field is the most significant bit.  When
+a multi-octet quantity is transmitted the most significant octet is
+transmitted first.
+
+2.3.3. Character Case
+
+For all parts of the DNS that are part of the official protocol, all
+comparisons between character strings (e.g., labels, domain names, etc.)
+are done in a case-insensitive manner.  At present, this rule is in
+force throughout the domain system without exception.  However, future
+additions beyond current usage may need to use the full binary octet
+capabilities in names, so attempts to store domain names in 7-bit ASCII
+or use of special bytes to terminate labels, etc., should be avoided.
+
+When data enters the domain system, its original case should be
+preserved whenever possible.  In certain circumstances this cannot be
+done.  For example, if two RRs are stored in a database, one at x.y and
+one at X.Y, they are actually stored at the same place in the database,
+and hence only one casing would be preserved.  The basic rule is that
+case can be discarded only when data is used to define structure in a
+database, and two names are identical when compared in a case
+insensitive manner.
+
+
+
+
+Mockapetris                                                     [Page 9]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+Loss of case sensitive data must be minimized.  Thus while data for x.y
+and X.Y may both be stored under a single location x.y or X.Y, data for
+a.x and B.X would never be stored under A.x, A.X, b.x, or b.X.  In
+general, this preserves the case of the first label of a domain name,
+but forces standardization of interior node labels.
+
+Systems administrators who enter data into the domain database should
+take care to represent the data they supply to the domain system in a
+case-consistent manner if their system is case-sensitive.  The data
+distribution system in the domain system will ensure that consistent
+representations are preserved.
+
+2.3.4. Size limits
+
+Various objects and parameters in the DNS have size limits.  They are
+listed below.  Some could be easily changed, others are more
+fundamental.
+
+labels          63 octets or less
+
+names           255 octets or less
+
+TTL             positive values of a signed 32 bit number.
+
+UDP messages    512 octets or less
+
+3. DOMAIN NAME SPACE AND RR DEFINITIONS
+
+3.1. Name space definitions
+
+Domain names in messages are expressed in terms of a sequence of labels.
+Each label is represented as a one octet length field followed by that
+number of octets.  Since every domain name ends with the null label of
+the root, a domain name is terminated by a length byte of zero.  The
+high order two bits of every length octet must be zero, and the
+remaining six bits of the length field limit the label to 63 octets or
+less.
+
+To simplify implementations, the total length of a domain name (i.e.,
+label octets and label length octets) is restricted to 255 octets or
+less.
+
+Although labels can contain any 8 bit values in octets that make up a
+label, it is strongly recommended that labels follow the preferred
+syntax described elsewhere in this memo, which is compatible with
+existing host naming conventions.  Name servers and resolvers must
+compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII
+with zero parity.  Non-alphabetic codes must match exactly.
+
+
+
+Mockapetris                                                    [Page 10]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+3.2. RR definitions
+
+3.2.1. Format
+
+All RRs have the same top level format shown below:
+
+                                    1  1  1  1  1  1
+      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                                               |
+    /                                               /
+    /                      NAME                     /
+    |                                               |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                      TYPE                     |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                     CLASS                     |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                      TTL                      |
+    |                                               |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                   RDLENGTH                    |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
+    /                     RDATA                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+
+where:
+
+NAME            an owner name, i.e., the name of the node to which this
+                resource record pertains.
+
+TYPE            two octets containing one of the RR TYPE codes.
+
+CLASS           two octets containing one of the RR CLASS codes.
+
+TTL             a 32 bit signed integer that specifies the time interval
+                that the resource record may be cached before the source
+                of the information should again be consulted.  Zero
+                values are interpreted to mean that the RR can only be
+                used for the transaction in progress, and should not be
+                cached.  For example, SOA records are always distributed
+                with a zero TTL to prohibit caching.  Zero values can
+                also be used for extremely volatile data.
+
+RDLENGTH        an unsigned 16 bit integer that specifies the length in
+                octets of the RDATA field.
+
+
+
+Mockapetris                                                    [Page 11]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+RDATA           a variable length string of octets that describes the
+                resource.  The format of this information varies
+                according to the TYPE and CLASS of the resource record.
+
+3.2.2. TYPE values
+
+TYPE fields are used in resource records.  Note that these types are a
+subset of QTYPEs.
+
+TYPE            value and meaning
+
+A               1 a host address
+
+NS              2 an authoritative name server
+
+MD              3 a mail destination (Obsolete - use MX)
+
+MF              4 a mail forwarder (Obsolete - use MX)
+
+CNAME           5 the canonical name for an alias
+
+SOA             6 marks the start of a zone of authority
+
+MB              7 a mailbox domain name (EXPERIMENTAL)
+
+MG              8 a mail group member (EXPERIMENTAL)
+
+MR              9 a mail rename domain name (EXPERIMENTAL)
+
+NULL            10 a null RR (EXPERIMENTAL)
+
+WKS             11 a well known service description
+
+PTR             12 a domain name pointer
+
+HINFO           13 host information
+
+MINFO           14 mailbox or mail list information
+
+MX              15 mail exchange
+
+TXT             16 text strings
+
+3.2.3. QTYPE values
+
+QTYPE fields appear in the question part of a query.  QTYPES are a
+superset of TYPEs, hence all TYPEs are valid QTYPEs.  In addition, the
+following QTYPEs are defined:
+
+
+
+Mockapetris                                                    [Page 12]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+AXFR            252 A request for a transfer of an entire zone
+
+MAILB           253 A request for mailbox-related records (MB, MG or MR)
+
+MAILA           254 A request for mail agent RRs (Obsolete - see MX)
+
+*               255 A request for all records
+
+3.2.4. CLASS values
+
+CLASS fields appear in resource records.  The following CLASS mnemonics
+and values are defined:
+
+IN              1 the Internet
+
+CS              2 the CSNET class (Obsolete - used only for examples in
+                some obsolete RFCs)
+
+CH              3 the CHAOS class
+
+HS              4 Hesiod [Dyer 87]
+
+3.2.5. QCLASS values
+
+QCLASS fields appear in the question section of a query.  QCLASS values
+are a superset of CLASS values; every CLASS is a valid QCLASS.  In
+addition to CLASS values, the following QCLASSes are defined:
+
+*               255 any class
+
+3.3. Standard RRs
+
+The following RR definitions are expected to occur, at least
+potentially, in all classes.  In particular, NS, SOA, CNAME, and PTR
+will be used in all classes, and have the same format in all classes.
+Because their RDATA format is known, all domain names in the RDATA
+section of these RRs may be compressed.
+
+<domain-name> is a domain name represented as a series of labels, and
+terminated by a label with zero length.  <character-string> is a single
+length octet followed by that number of characters.  <character-string>
+is treated as binary information, and can be up to 256 characters in
+length (including the length octet).
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 13]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+3.3.1. CNAME RDATA format
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                     CNAME                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+CNAME           A <domain-name> which specifies the canonical or primary
+                name for the owner.  The owner name is an alias.
+
+CNAME RRs cause no additional section processing, but name servers may
+choose to restart the query at the canonical name in certain cases.  See
+the description of name server logic in [RFC-1034] for details.
+
+3.3.2. HINFO RDATA format
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                      CPU                      /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                       OS                      /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+CPU             A <character-string> which specifies the CPU type.
+
+OS              A <character-string> which specifies the operating
+                system type.
+
+Standard values for CPU and OS can be found in [RFC-1010].
+
+HINFO records are used to acquire general information about a host.  The
+main use is for protocols such as FTP that can use special procedures
+when talking between machines or operating systems of the same type.
+
+3.3.3. MB RDATA format (EXPERIMENTAL)
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                   MADNAME                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+MADNAME         A <domain-name> which specifies a host which has the
+                specified mailbox.
+
+
+
+Mockapetris                                                    [Page 14]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+MB records cause additional section processing which looks up an A type
+RRs corresponding to MADNAME.
+
+3.3.4. MD RDATA format (Obsolete)
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                   MADNAME                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+MADNAME         A <domain-name> which specifies a host which has a mail
+                agent for the domain which should be able to deliver
+                mail for the domain.
+
+MD records cause additional section processing which looks up an A type
+record corresponding to MADNAME.
+
+MD is obsolete.  See the definition of MX and [RFC-974] for details of
+the new scheme.  The recommended policy for dealing with MD RRs found in
+a master file is to reject them, or to convert them to MX RRs with a
+preference of 0.
+
+3.3.5. MF RDATA format (Obsolete)
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                   MADNAME                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+MADNAME         A <domain-name> which specifies a host which has a mail
+                agent for the domain which will accept mail for
+                forwarding to the domain.
+
+MF records cause additional section processing which looks up an A type
+record corresponding to MADNAME.
+
+MF is obsolete.  See the definition of MX and [RFC-974] for details ofw
+the new scheme.  The recommended policy for dealing with MD RRs found in
+a master file is to reject them, or to convert them to MX RRs with a
+preference of 10.
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 15]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+3.3.6. MG RDATA format (EXPERIMENTAL)
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                   MGMNAME                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+MGMNAME         A <domain-name> which specifies a mailbox which is a
+                member of the mail group specified by the domain name.
+
+MG records cause no additional section processing.
+
+3.3.7. MINFO RDATA format (EXPERIMENTAL)
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                    RMAILBX                    /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                    EMAILBX                    /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+RMAILBX         A <domain-name> which specifies a mailbox which is
+                responsible for the mailing list or mailbox.  If this
+                domain name names the root, the owner of the MINFO RR is
+                responsible for itself.  Note that many existing mailing
+                lists use a mailbox X-request for the RMAILBX field of
+                mailing list X, e.g., Msgroup-request for Msgroup.  This
+                field provides a more general mechanism.
+
+
+EMAILBX         A <domain-name> which specifies a mailbox which is to
+                receive error messages related to the mailing list or
+                mailbox specified by the owner of the MINFO RR (similar
+                to the ERRORS-TO: field which has been proposed).  If
+                this domain name names the root, errors should be
+                returned to the sender of the message.
+
+MINFO records cause no additional section processing.  Although these
+records can be associated with a simple mailbox, they are usually used
+with a mailing list.
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 16]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+3.3.8. MR RDATA format (EXPERIMENTAL)
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                   NEWNAME                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+NEWNAME         A <domain-name> which specifies a mailbox which is the
+                proper rename of the specified mailbox.
+
+MR records cause no additional section processing.  The main use for MR
+is as a forwarding entry for a user who has moved to a different
+mailbox.
+
+3.3.9. MX RDATA format
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                  PREFERENCE                   |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                   EXCHANGE                    /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+PREFERENCE      A 16 bit integer which specifies the preference given to
+                this RR among others at the same owner.  Lower values
+                are preferred.
+
+EXCHANGE        A <domain-name> which specifies a host willing to act as
+                a mail exchange for the owner name.
+
+MX records cause type A additional section processing for the host
+specified by EXCHANGE.  The use of MX RRs is explained in detail in
+[RFC-974].
+
+3.3.10. NULL RDATA format (EXPERIMENTAL)
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                  <anything>                   /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+Anything at all may be in the RDATA field so long as it is 65535 octets
+or less.
+
+
+
+
+Mockapetris                                                    [Page 17]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+NULL records cause no additional section processing.  NULL RRs are not
+allowed in master files.  NULLs are used as placeholders in some
+experimental extensions of the DNS.
+
+3.3.11. NS RDATA format
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                   NSDNAME                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+NSDNAME         A <domain-name> which specifies a host which should be
+                authoritative for the specified class and domain.
+
+NS records cause both the usual additional section processing to locate
+a type A record, and, when used in a referral, a special search of the
+zone in which they reside for glue information.
+
+The NS RR states that the named host should be expected to have a zone
+starting at owner name of the specified class.  Note that the class may
+not indicate the protocol family which should be used to communicate
+with the host, although it is typically a strong hint.  For example,
+hosts which are name servers for either Internet (IN) or Hesiod (HS)
+class information are normally queried using IN class protocols.
+
+3.3.12. PTR RDATA format
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                   PTRDNAME                    /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+PTRDNAME        A <domain-name> which points to some location in the
+                domain name space.
+
+PTR records cause no additional section processing.  These RRs are used
+in special domains to point to some other location in the domain space.
+These records are simple data, and don't imply any special processing
+similar to that performed by CNAME, which identifies aliases.  See the
+description of the IN-ADDR.ARPA domain for an example.
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 18]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+3.3.13. SOA RDATA format
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                     MNAME                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                     RNAME                     /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                    SERIAL                     |
+    |                                               |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                    REFRESH                    |
+    |                                               |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                     RETRY                     |
+    |                                               |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                    EXPIRE                     |
+    |                                               |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                    MINIMUM                    |
+    |                                               |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+MNAME           The <domain-name> of the name server that was the
+                original or primary source of data for this zone.
+
+RNAME           A <domain-name> which specifies the mailbox of the
+                person responsible for this zone.
+
+SERIAL          The unsigned 32 bit version number of the original copy
+                of the zone.  Zone transfers preserve this value.  This
+                value wraps and should be compared using sequence space
+                arithmetic.
+
+REFRESH         A 32 bit time interval before the zone should be
+                refreshed.
+
+RETRY           A 32 bit time interval that should elapse before a
+                failed refresh should be retried.
+
+EXPIRE          A 32 bit time value that specifies the upper limit on
+                the time interval that can elapse before the zone is no
+                longer authoritative.
+
+
+
+
+
+Mockapetris                                                    [Page 19]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+MINIMUM         The unsigned 32 bit minimum TTL field that should be
+                exported with any RR from this zone.
+
+SOA records cause no additional section processing.
+
+All times are in units of seconds.
+
+Most of these fields are pertinent only for name server maintenance
+operations.  However, MINIMUM is used in all query operations that
+retrieve RRs from a zone.  Whenever a RR is sent in a response to a
+query, the TTL field is set to the maximum of the TTL field from the RR
+and the MINIMUM field in the appropriate SOA.  Thus MINIMUM is a lower
+bound on the TTL field for all RRs in a zone.  Note that this use of
+MINIMUM should occur when the RRs are copied into the response and not
+when the zone is loaded from a master file or via a zone transfer.  The
+reason for this provison is to allow future dynamic update facilities to
+change the SOA RR with known semantics.
+
+
+3.3.14. TXT RDATA format
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                   TXT-DATA                    /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+TXT-DATA        One or more <character-string>s.
+
+TXT RRs are used to hold descriptive text.  The semantics of the text
+depends on the domain where it is found.
+
+3.4. Internet specific RRs
+
+3.4.1. A RDATA format
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                    ADDRESS                    |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+ADDRESS         A 32 bit Internet address.
+
+Hosts that have multiple Internet addresses will have multiple A
+records.
+
+
+
+
+
+Mockapetris                                                    [Page 20]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+A records cause no additional section processing.  The RDATA section of
+an A line in a master file is an Internet address expressed as four
+decimal numbers separated by dots without any imbedded spaces (e.g.,
+"10.2.0.52" or "192.0.5.6").
+
+3.4.2. WKS RDATA format
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                    ADDRESS                    |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |       PROTOCOL        |                       |
+    +--+--+--+--+--+--+--+--+                       |
+    |                                               |
+    /                   <BIT MAP>                   /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+ADDRESS         An 32 bit Internet address
+
+PROTOCOL        An 8 bit IP protocol number
+
+<BIT MAP>       A variable length bit map.  The bit map must be a
+                multiple of 8 bits long.
+
+The WKS record is used to describe the well known services supported by
+a particular protocol on a particular internet address.  The PROTOCOL
+field specifies an IP protocol number, and the bit map has one bit per
+port of the specified protocol.  The first bit corresponds to port 0,
+the second to port 1, etc.  If the bit map does not include a bit for a
+protocol of interest, that bit is assumed zero.  The appropriate values
+and mnemonics for ports and protocols are specified in [RFC-1010].
+
+For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP port
+25 (SMTP).  If this bit is set, a SMTP server should be listening on TCP
+port 25; if zero, SMTP service is not supported on the specified
+address.
+
+The purpose of WKS RRs is to provide availability information for
+servers for TCP and UDP.  If a server supports both TCP and UDP, or has
+multiple Internet addresses, then multiple WKS RRs are used.
+
+WKS RRs cause no additional section processing.
+
+In master files, both ports and protocols are expressed using mnemonics
+or decimal numbers.
+
+
+
+
+Mockapetris                                                    [Page 21]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+3.5. IN-ADDR.ARPA domain
+
+The Internet uses a special domain to support gateway location and
+Internet address to host mapping.  Other classes may employ a similar
+strategy in other domains.  The intent of this domain is to provide a
+guaranteed method to perform host address to host name mapping, and to
+facilitate queries to locate all gateways on a particular network in the
+Internet.
+
+Note that both of these services are similar to functions that could be
+performed by inverse queries; the difference is that this part of the
+domain name space is structured according to address, and hence can
+guarantee that the appropriate data can be located without an exhaustive
+search of the domain space.
+
+The domain begins at IN-ADDR.ARPA and has a substructure which follows
+the Internet addressing structure.
+
+Domain names in the IN-ADDR.ARPA domain are defined to have up to four
+labels in addition to the IN-ADDR.ARPA suffix.  Each label represents
+one octet of an Internet address, and is expressed as a character string
+for a decimal value in the range 0-255 (with leading zeros omitted
+except in the case of a zero octet which is represented by a single
+zero).
+
+Host addresses are represented by domain names that have all four labels
+specified.  Thus data for Internet address 10.2.0.52 is located at
+domain name 52.0.2.10.IN-ADDR.ARPA.  The reversal, though awkward to
+read, allows zones to be delegated which are exactly one network of
+address space.  For example, 10.IN-ADDR.ARPA can be a zone containing
+data for the ARPANET, while 26.IN-ADDR.ARPA can be a separate zone for
+MILNET.  Address nodes are used to hold pointers to primary host names
+in the normal domain space.
+
+Network numbers correspond to some non-terminal nodes at various depths
+in the IN-ADDR.ARPA domain, since Internet network numbers are either 1,
+2, or 3 octets.  Network nodes are used to hold pointers to the primary
+host names of gateways attached to that network.  Since a gateway is, by
+definition, on more than one network, it will typically have two or more
+network nodes which point at it.  Gateways will also have host level
+pointers at their fully qualified addresses.
+
+Both the gateway pointers at network nodes and the normal host pointers
+at full address nodes use the PTR RR to point back to the primary domain
+names of the corresponding hosts.
+
+For example, the IN-ADDR.ARPA domain will contain information about the
+ISI gateway between net 10 and 26, an MIT gateway from net 10 to MIT's
+
+
+
+Mockapetris                                                    [Page 22]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+net 18, and hosts A.ISI.EDU and MULTICS.MIT.EDU.  Assuming that ISI
+gateway has addresses 10.2.0.22 and 26.0.0.103, and a name MILNET-
+GW.ISI.EDU, and the MIT gateway has addresses 10.0.0.77 and 18.10.0.4
+and a name GW.LCS.MIT.EDU, the domain database would contain:
+
+    10.IN-ADDR.ARPA.           PTR MILNET-GW.ISI.EDU.
+    10.IN-ADDR.ARPA.           PTR GW.LCS.MIT.EDU.
+    18.IN-ADDR.ARPA.           PTR GW.LCS.MIT.EDU.
+    26.IN-ADDR.ARPA.           PTR MILNET-GW.ISI.EDU.
+    22.0.2.10.IN-ADDR.ARPA.    PTR MILNET-GW.ISI.EDU.
+    103.0.0.26.IN-ADDR.ARPA.   PTR MILNET-GW.ISI.EDU.
+    77.0.0.10.IN-ADDR.ARPA.    PTR GW.LCS.MIT.EDU.
+    4.0.10.18.IN-ADDR.ARPA.    PTR GW.LCS.MIT.EDU.
+    103.0.3.26.IN-ADDR.ARPA.   PTR A.ISI.EDU.
+    6.0.0.10.IN-ADDR.ARPA.     PTR MULTICS.MIT.EDU.
+
+Thus a program which wanted to locate gateways on net 10 would originate
+a query of the form QTYPE=PTR, QCLASS=IN, QNAME=10.IN-ADDR.ARPA.  It
+would receive two RRs in response:
+
+    10.IN-ADDR.ARPA.           PTR MILNET-GW.ISI.EDU.
+    10.IN-ADDR.ARPA.           PTR GW.LCS.MIT.EDU.
+
+The program could then originate QTYPE=A, QCLASS=IN queries for MILNET-
+GW.ISI.EDU. and GW.LCS.MIT.EDU. to discover the Internet addresses of
+these gateways.
+
+A resolver which wanted to find the host name corresponding to Internet
+host address 10.0.0.6 would pursue a query of the form QTYPE=PTR,
+QCLASS=IN, QNAME=6.0.0.10.IN-ADDR.ARPA, and would receive:
+
+    6.0.0.10.IN-ADDR.ARPA.     PTR MULTICS.MIT.EDU.
+
+Several cautions apply to the use of these services:
+   - Since the IN-ADDR.ARPA special domain and the normal domain
+     for a particular host or gateway will be in different zones,
+     the possibility exists that that the data may be inconsistent.
+
+   - Gateways will often have two names in separate domains, only
+     one of which can be primary.
+
+   - Systems that use the domain database to initialize their
+     routing tables must start with enough gateway information to
+     guarantee that they can access the appropriate name server.
+
+   - The gateway data only reflects the existence of a gateway in a
+     manner equivalent to the current HOSTS.TXT file.  It doesn't
+     replace the dynamic availability information from GGP or EGP.
+
+
+
+Mockapetris                                                    [Page 23]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+3.6. Defining new types, classes, and special namespaces
+
+The previously defined types and classes are the ones in use as of the
+date of this memo.  New definitions should be expected.  This section
+makes some recommendations to designers considering additions to the
+existing facilities.  The mailing list NAMEDROPPERS@SRI-NIC.ARPA is the
+forum where general discussion of design issues takes place.
+
+In general, a new type is appropriate when new information is to be
+added to the database about an existing object, or we need new data
+formats for some totally new object.  Designers should attempt to define
+types and their RDATA formats that are generally applicable to all
+classes, and which avoid duplication of information.  New classes are
+appropriate when the DNS is to be used for a new protocol, etc which
+requires new class-specific data formats, or when a copy of the existing
+name space is desired, but a separate management domain is necessary.
+
+New types and classes need mnemonics for master files; the format of the
+master files requires that the mnemonics for type and class be disjoint.
+
+TYPE and CLASS values must be a proper subset of QTYPEs and QCLASSes
+respectively.
+
+The present system uses multiple RRs to represent multiple values of a
+type rather than storing multiple values in the RDATA section of a
+single RR.  This is less efficient for most applications, but does keep
+RRs shorter.  The multiple RRs assumption is incorporated in some
+experimental work on dynamic update methods.
+
+The present system attempts to minimize the duplication of data in the
+database in order to insure consistency.  Thus, in order to find the
+address of the host for a mail exchange, you map the mail domain name to
+a host name, then the host name to addresses, rather than a direct
+mapping to host address.  This approach is preferred because it avoids
+the opportunity for inconsistency.
+
+In defining a new type of data, multiple RR types should not be used to
+create an ordering between entries or express different formats for
+equivalent bindings, instead this information should be carried in the
+body of the RR and a single type used.  This policy avoids problems with
+caching multiple types and defining QTYPEs to match multiple types.
+
+For example, the original form of mail exchange binding used two RR
+types one to represent a "closer" exchange (MD) and one to represent a
+"less close" exchange (MF).  The difficulty is that the presence of one
+RR type in a cache doesn't convey any information about the other
+because the query which acquired the cached information might have used
+a QTYPE of MF, MD, or MAILA (which matched both).  The redesigned
+
+
+
+Mockapetris                                                    [Page 24]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+service used a single type (MX) with a "preference" value in the RDATA
+section which can order different RRs.  However, if any MX RRs are found
+in the cache, then all should be there.
+
+4. MESSAGES
+
+4.1. Format
+
+All communications inside of the domain protocol are carried in a single
+format called a message.  The top level format of message is divided
+into 5 sections (some of which are empty in certain cases) shown below:
+
+    +---------------------+
+    |        Header       |
+    +---------------------+
+    |       Question      | the question for the name server
+    +---------------------+
+    |        Answer       | RRs answering the question
+    +---------------------+
+    |      Authority      | RRs pointing toward an authority
+    +---------------------+
+    |      Additional     | RRs holding additional information
+    +---------------------+
+
+The header section is always present.  The header includes fields that
+specify which of the remaining sections are present, and also specify
+whether the message is a query or a response, a standard query or some
+other opcode, etc.
+
+The names of the sections after the header are derived from their use in
+standard queries.  The question section contains fields that describe a
+question to a name server.  These fields are a query type (QTYPE), a
+query class (QCLASS), and a query domain name (QNAME).  The last three
+sections have the same format: a possibly empty list of concatenated
+resource records (RRs).  The answer section contains RRs that answer the
+question; the authority section contains RRs that point toward an
+authoritative name server; the additional records section contains RRs
+which relate to the query, but are not strictly answers for the
+question.
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 25]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+4.1.1. Header section format
+
+The header contains the following fields:
+
+                                    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|   Z    |   RCODE   |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                    QDCOUNT                    |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                    ANCOUNT                    |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                    NSCOUNT                    |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                    ARCOUNT                    |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+ID              A 16 bit identifier assigned by the program that
+                generates any kind of query.  This identifier is copied
+                the corresponding reply and can be used by the requester
+                to match up replies to outstanding queries.
+
+QR              A one bit field that specifies whether this message is a
+                query (0), or a response (1).
+
+OPCODE          A four bit field that specifies kind of query in this
+                message.  This value is set by the originator of a query
+                and copied into the response.  The values are:
+
+                0               a standard query (QUERY)
+
+                1               an inverse query (IQUERY)
+
+                2               a server status request (STATUS)
+
+                3-15            reserved for future use
+
+AA              Authoritative Answer - this bit is valid in responses,
+                and specifies that the responding name server is an
+                authority for the domain name in question section.
+
+                Note that the contents of the answer section may have
+                multiple owner names because of aliases.  The AA bit
+
+
+
+Mockapetris                                                    [Page 26]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+                corresponds to the name which matches the query name, or
+                the first owner name in the answer section.
+
+TC              TrunCation - specifies that this message was truncated
+                due to length greater than that permitted on the
+                transmission channel.
+
+RD              Recursion Desired - this bit may be set in a query and
+                is copied into the response.  If RD is set, it directs
+                the name server to pursue the query recursively.
+                Recursive query support is optional.
+
+RA              Recursion Available - this be is set or cleared in a
+                response, and denotes whether recursive query support is
+                available in the name server.
+
+Z               Reserved for future use.  Must be zero in all queries
+                and responses.
+
+RCODE           Response code - this 4 bit field is set as part of
+                responses.  The values have the following
+                interpretation:
+
+                0               No error condition
+
+                1               Format error - The name server was
+                                unable to interpret the query.
+
+                2               Server failure - The name server was
+                                unable to process this query due to a
+                                problem with the name server.
+
+                3               Name Error - Meaningful only for
+                                responses from an authoritative name
+                                server, this code signifies that the
+                                domain name referenced in the query does
+                                not exist.
+
+                4               Not Implemented - The name server does
+                                not support the requested kind of query.
+
+                5               Refused - The name server refuses to
+                                perform the specified operation for
+                                policy reasons.  For example, a name
+                                server may not wish to provide the
+                                information to the particular requester,
+                                or a name server may not wish to perform
+                                a particular operation (e.g., zone
+
+
+
+Mockapetris                                                    [Page 27]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+                                transfer) for particular data.
+
+                6-15            Reserved for future use.
+
+QDCOUNT         an unsigned 16 bit integer specifying the number of
+                entries in the question section.
+
+ANCOUNT         an unsigned 16 bit integer specifying the number of
+                resource records in the answer section.
+
+NSCOUNT         an unsigned 16 bit integer specifying the number of name
+                server resource records in the authority records
+                section.
+
+ARCOUNT         an unsigned 16 bit integer specifying the number of
+                resource records in the additional records section.
+
+4.1.2. Question section format
+
+The question section is used to carry the "question" in most queries,
+i.e., the parameters that define what is being asked.  The section
+contains QDCOUNT (usually 1) entries, each of the following format:
+
+                                    1  1  1  1  1  1
+      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                                               |
+    /                     QNAME                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                     QTYPE                     |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                     QCLASS                    |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+QNAME           a domain name represented as a sequence of labels, where
+                each label consists of a length octet followed by that
+                number of octets.  The domain name terminates with the
+                zero length octet for the null label of the root.  Note
+                that this field may be an odd number of octets; no
+                padding is used.
+
+QTYPE           a two octet code which specifies the type of the query.
+                The values for this field include all codes valid for a
+                TYPE field, together with some more general codes which
+                can match more than one type of RR.
+
+
+
+Mockapetris                                                    [Page 28]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+QCLASS          a two octet code that specifies the class of the query.
+                For example, the QCLASS field is IN for the Internet.
+
+4.1.3. Resource record format
+
+The answer, authority, and additional sections all share the same
+format: a variable number of resource records, where the number of
+records is specified in the corresponding count field in the header.
+Each resource record has the following format:
+                                    1  1  1  1  1  1
+      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                                               |
+    /                                               /
+    /                      NAME                     /
+    |                                               |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                      TYPE                     |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                     CLASS                     |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                      TTL                      |
+    |                                               |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                   RDLENGTH                    |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
+    /                     RDATA                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+NAME            a domain name to which this resource record pertains.
+
+TYPE            two octets containing one of the RR type codes.  This
+                field specifies the meaning of the data in the RDATA
+                field.
+
+CLASS           two octets which specify the class of the data in the
+                RDATA field.
+
+TTL             a 32 bit unsigned integer that specifies the time
+                interval (in seconds) that the resource record may be
+                cached before it should be discarded.  Zero values are
+                interpreted to mean that the RR can only be used for the
+                transaction in progress, and should not be cached.
+
+
+
+
+
+Mockapetris                                                    [Page 29]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+RDLENGTH        an unsigned 16 bit integer that specifies the length in
+                octets of the RDATA field.
+
+RDATA           a variable length string of octets that describes the
+                resource.  The format of this information varies
+                according to the TYPE and CLASS of the resource record.
+                For example, the if the TYPE is A and the CLASS is IN,
+                the RDATA field is a 4 octet ARPA Internet address.
+
+4.1.4. Message compression
+
+In order to reduce the size of messages, the domain system utilizes a
+compression scheme which eliminates the repetition of domain names in a
+message.  In this scheme, an entire domain name or a list of labels at
+the end of a domain name is replaced with a pointer to a prior occurance
+of the same name.
+
+The pointer takes the form of a two octet sequence:
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    | 1  1|                OFFSET                   |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+The first two bits are ones.  This allows a pointer to be distinguished
+from a label, since the label must begin with two zero bits because
+labels are restricted to 63 octets or less.  (The 10 and 01 combinations
+are reserved for future use.)  The OFFSET field specifies an offset from
+the start of the message (i.e., the first octet of the ID field in the
+domain header).  A zero offset specifies the first byte of the ID field,
+etc.
+
+The compression scheme allows a domain name in a message to be
+represented as either:
+
+   - a sequence of labels ending in a zero octet
+
+   - a pointer
+
+   - a sequence of labels ending with a pointer
+
+Pointers can only be used for occurances of a domain name where the
+format is not class specific.  If this were not the case, a name server
+or resolver would be required to know the format of all RRs it handled.
+As yet, there are no such cases, but they may occur in future RDATA
+formats.
+
+If a domain name is contained in a part of the message subject to a
+length field (such as the RDATA section of an RR), and compression is
+
+
+
+Mockapetris                                                    [Page 30]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+used, the length of the compressed name is used in the length
+calculation, rather than the length of the expanded name.
+
+Programs are free to avoid using pointers in messages they generate,
+although this will reduce datagram capacity, and may cause truncation.
+However all programs are required to understand arriving messages that
+contain pointers.
+
+For example, a datagram might need to use the domain names F.ISI.ARPA,
+FOO.F.ISI.ARPA, ARPA, and the root.  Ignoring the other fields of the
+message, these domain names might be represented as:
+
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    20 |           1           |           F           |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    22 |           3           |           I           |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    24 |           S           |           I           |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    26 |           4           |           A           |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    28 |           R           |           P           |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    30 |           A           |           0           |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    40 |           3           |           F           |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    42 |           O           |           O           |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    44 | 1  1|                20                       |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    64 | 1  1|                26                       |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    92 |           0           |                       |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+The domain name for F.ISI.ARPA is shown at offset 20.  The domain name
+FOO.F.ISI.ARPA is shown at offset 40; this definition uses a pointer to
+concatenate a label for FOO to the previously defined F.ISI.ARPA.  The
+domain name ARPA is defined at offset 64 using a pointer to the ARPA
+component of the name F.ISI.ARPA at 20; note that this pointer relies on
+ARPA being the last label in the string at 20.  The root domain name is
+
+
+
+Mockapetris                                                    [Page 31]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+defined by a single octet of zeros at 92; the root domain name has no
+labels.
+
+4.2. Transport
+
+The DNS assumes that messages will be transmitted as datagrams or in a
+byte stream carried by a virtual circuit.  While virtual circuits can be
+used for any DNS activity, datagrams are preferred for queries due to
+their lower overhead and better performance.  Zone refresh activities
+must use virtual circuits because of the need for reliable transfer.
+
+The Internet supports name server access using TCP [RFC-793] on server
+port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP
+port 53 (decimal).
+
+4.2.1. UDP usage
+
+Messages sent using UDP user server port 53 (decimal).
+
+Messages carried by UDP are restricted to 512 bytes (not counting the IP
+or UDP headers).  Longer messages are truncated and the TC bit is set in
+the header.
+
+UDP is not acceptable for zone transfers, but is the recommended method
+for standard queries in the Internet.  Queries sent using UDP may be
+lost, and hence a retransmission strategy is required.  Queries or their
+responses may be reordered by the network, or by processing in name
+servers, so resolvers should not depend on them being returned in order.
+
+The optimal UDP retransmission policy will vary with performance of the
+Internet and the needs of the client, but the following are recommended:
+
+   - The client should try other servers and server addresses
+     before repeating a query to a specific address of a server.
+
+   - The retransmission interval should be based on prior
+     statistics if possible.  Too aggressive retransmission can
+     easily slow responses for the community at large.  Depending
+     on how well connected the client is to its expected servers,
+     the minimum retransmission interval should be 2-5 seconds.
+
+More suggestions on server selection and retransmission policy can be
+found in the resolver section of this memo.
+
+4.2.2. TCP usage
+
+Messages sent over TCP connections use server port 53 (decimal).  The
+message is prefixed with a two byte length field which gives the message
+
+
+
+Mockapetris                                                    [Page 32]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+length, excluding the two byte length field.  This length field allows
+the low-level processing to assemble a complete message before beginning
+to parse it.
+
+Several connection management policies are recommended:
+
+   - The server should not block other activities waiting for TCP
+     data.
+
+   - The server should support multiple connections.
+
+   - The server should assume that the client will initiate
+     connection closing, and should delay closing its end of the
+     connection until all outstanding client requests have been
+     satisfied.
+
+   - If the server needs to close a dormant connection to reclaim
+     resources, it should wait until the connection has been idle
+     for a period on the order of two minutes.  In particular, the
+     server should allow the SOA and AXFR request sequence (which
+     begins a refresh operation) to be made on a single connection.
+     Since the server would be unable to answer queries anyway, a
+     unilateral close or reset may be used instead of a graceful
+     close.
+
+5. MASTER FILES
+
+Master files are text files that contain RRs in text form.  Since the
+contents of a zone can be expressed in the form of a list of RRs a
+master file is most often used to define a zone, though it can be used
+to list a cache's contents.  Hence, this section first discusses the
+format of RRs in a master file, and then the special considerations when
+a master file is used to create a zone in some name server.
+
+5.1. Format
+
+The format of these files is a sequence of entries.  Entries are
+predominantly line-oriented, though parentheses can be used to continue
+a list of items across a line boundary, and text literals can contain
+CRLF within the text.  Any combination of tabs and spaces act as a
+delimiter between the separate items that make up an entry.  The end of
+any line in the master file can end with a comment.  The comment starts
+with a ";" (semicolon).
+
+The following entries are defined:
+
+    <blank>[<comment>]
+
+
+
+
+Mockapetris                                                    [Page 33]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+    $ORIGIN <domain-name> [<comment>]
+
+    $INCLUDE <file-name> [<domain-name>] [<comment>]
+
+    <domain-name><rr> [<comment>]
+
+    <blank><rr> [<comment>]
+
+Blank lines, with or without comments, are allowed anywhere in the file.
+
+Two control entries are defined: $ORIGIN and $INCLUDE.  $ORIGIN is
+followed by a domain name, and resets the current origin for relative
+domain names to the stated name.  $INCLUDE inserts the named file into
+the current file, and may optionally specify a domain name that sets the
+relative domain name origin for the included file.  $INCLUDE may also
+have a comment.  Note that a $INCLUDE entry never changes the relative
+origin of the parent file, regardless of changes to the relative origin
+made within the included file.
+
+The last two forms represent RRs.  If an entry for an RR begins with a
+blank, then the RR is assumed to be owned by the last stated owner.  If
+an RR entry begins with a <domain-name>, then the owner name is reset.
+
+<rr> contents take one of the following forms:
+
+    [<TTL>] [<class>] <type> <RDATA>
+
+    [<class>] [<TTL>] <type> <RDATA>
+
+The RR begins with optional TTL and class fields, followed by a type and
+RDATA field appropriate to the type and class.  Class and type use the
+standard mnemonics, TTL is a decimal integer.  Omitted class and TTL
+values are default to the last explicitly stated values.  Since type and
+class mnemonics are disjoint, the parse is unique.  (Note that this
+order is different from the order used in examples and the order used in
+the actual RRs; the given order allows easier parsing and defaulting.)
+
+<domain-name>s make up a large share of the data in the master file.
+The labels in the domain name are expressed as character strings and
+separated by dots.  Quoting conventions allow arbitrary characters to be
+stored in domain names.  Domain names that end in a dot are called
+absolute, and are taken as complete.  Domain names which do not end in a
+dot are called relative; the actual domain name is the concatenation of
+the relative part with an origin specified in a $ORIGIN, $INCLUDE, or as
+an argument to the master file loading routine.  A relative name is an
+error when no origin is available.
+
+
+
+
+
+Mockapetris                                                    [Page 34]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+<character-string> is expressed in one or two ways: as a contiguous set
+of characters without interior spaces, or as a string beginning with a "
+and ending with a ".  Inside a " delimited string any character can
+occur, except for a " itself, which must be quoted using \ (back slash).
+
+Because these files are text files several special encodings are
+necessary to allow arbitrary data to be loaded.  In particular:
+
+                of the root.
+
+@               A free standing @ is used to denote the current origin.
+
+\X              where X is any character other than a digit (0-9), is
+                used to quote that character so that its special meaning
+                does not apply.  For example, "\." can be used to place
+                a dot character in a label.
+
+\DDD            where each D is a digit is the octet corresponding to
+                the decimal number described by DDD.  The resulting
+                octet is assumed to be text and is not checked for
+                special meaning.
+
+( )             Parentheses are used to group data that crosses a line
+                boundary.  In effect, line terminations are not
+                recognized within parentheses.
+
+;               Semicolon is used to start a comment; the remainder of
+                the line is ignored.
+
+5.2. Use of master files to define zones
+
+When a master file is used to load a zone, the operation should be
+suppressed if any errors are encountered in the master file.  The
+rationale for this is that a single error can have widespread
+consequences.  For example, suppose that the RRs defining a delegation
+have syntax errors; then the server will return authoritative name
+errors for all names in the subzone (except in the case where the
+subzone is also present on the server).
+
+Several other validity checks that should be performed in addition to
+insuring that the file is syntactically correct:
+
+   1. All RRs in the file should have the same class.
+
+   2. Exactly one SOA RR should be present at the top of the zone.
+
+   3. If delegations are present and glue information is required,
+      it should be present.
+
+
+
+Mockapetris                                                    [Page 35]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+   4. Information present outside of the authoritative nodes in the
+      zone should be glue information, rather than the result of an
+      origin or similar error.
+
+5.3. Master file example
+
+The following is an example file which might be used to define the
+ISI.EDU zone.and is loaded with an origin of ISI.EDU:
+
+@   IN  SOA     VENERA      Action\.domains (
+                                 20     ; SERIAL
+                                 7200   ; REFRESH
+                                 600    ; RETRY
+                                 3600000; EXPIRE
+                                 60)    ; MINIMUM
+
+        NS      A.ISI.EDU.
+        NS      VENERA
+        NS      VAXA
+        MX      10      VENERA
+        MX      20      VAXA
+
+A       A       26.3.0.103
+
+VENERA  A       10.1.0.52
+        A       128.9.0.32
+
+VAXA    A       10.2.0.27
+        A       128.9.0.33
+
+
+$INCLUDE <SUBSYS>ISI-MAILBOXES.TXT
+
+Where the file <SUBSYS>ISI-MAILBOXES.TXT is:
+
+    MOE     MB      A.ISI.EDU.
+    LARRY   MB      A.ISI.EDU.
+    CURLEY  MB      A.ISI.EDU.
+    STOOGES MG      MOE
+            MG      LARRY
+            MG      CURLEY
+
+Note the use of the \ character in the SOA RR to specify the responsible
+person mailbox "Action.domains@E.ISI.EDU".
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 36]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+6. NAME SERVER IMPLEMENTATION
+
+6.1. Architecture
+
+The optimal structure for the name server will depend on the host
+operating system and whether the name server is integrated with resolver
+operations, either by supporting recursive service, or by sharing its
+database with a resolver.  This section discusses implementation
+considerations for a name server which shares a database with a
+resolver, but most of these concerns are present in any name server.
+
+6.1.1. Control
+
+A name server must employ multiple concurrent activities, whether they
+are implemented as separate tasks in the host's OS or multiplexing
+inside a single name server program.  It is simply not acceptable for a
+name server to block the service of UDP requests while it waits for TCP
+data for refreshing or query activities.  Similarly, a name server
+should not attempt to provide recursive service without processing such
+requests in parallel, though it may choose to serialize requests from a
+single client, or to regard identical requests from the same client as
+duplicates.  A name server should not substantially delay requests while
+it reloads a zone from master files or while it incorporates a newly
+refreshed zone into its database.
+
+6.1.2. Database
+
+While name server implementations are free to use any internal data
+structures they choose, the suggested structure consists of three major
+parts:
+
+   - A "catalog" data structure which lists the zones available to
+     this server, and a "pointer" to the zone data structure.  The
+     main purpose of this structure is to find the nearest ancestor
+     zone, if any, for arriving standard queries.
+
+   - Separate data structures for each of the zones held by the
+     name server.
+
+   - A data structure for cached data. (or perhaps separate caches
+     for different classes)
+
+All of these data structures can be implemented an identical tree
+structure format, with different data chained off the nodes in different
+parts: in the catalog the data is pointers to zones, while in the zone
+and cache data structures, the data will be RRs.  In designing the tree
+framework the designer should recognize that query processing will need
+to traverse the tree using case-insensitive label comparisons; and that
+
+
+
+Mockapetris                                                    [Page 37]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+in real data, a few nodes have a very high branching factor (100-1000 or
+more), but the vast majority have a very low branching factor (0-1).
+
+One way to solve the case problem is to store the labels for each node
+in two pieces: a standardized-case representation of the label where all
+ASCII characters are in a single case, together with a bit mask that
+denotes which characters are actually of a different case.  The
+branching factor diversity can be handled using a simple linked list for
+a node until the branching factor exceeds some threshold, and
+transitioning to a hash structure after the threshold is exceeded.  In
+any case, hash structures used to store tree sections must insure that
+hash functions and procedures preserve the casing conventions of the
+DNS.
+
+The use of separate structures for the different parts of the database
+is motivated by several factors:
+
+   - The catalog structure can be an almost static structure that
+     need change only when the system administrator changes the
+     zones supported by the server.  This structure can also be
+     used to store parameters used to control refreshing
+     activities.
+
+   - The individual data structures for zones allow a zone to be
+     replaced simply by changing a pointer in the catalog.  Zone
+     refresh operations can build a new structure and, when
+     complete, splice it into the database via a simple pointer
+     replacement.  It is very important that when a zone is
+     refreshed, queries should not use old and new data
+     simultaneously.
+
+   - With the proper search procedures, authoritative data in zones
+     will always "hide", and hence take precedence over, cached
+     data.
+
+   - Errors in zone definitions that cause overlapping zones, etc.,
+     may cause erroneous responses to queries, but problem
+     determination is simplified, and the contents of one "bad"
+     zone can't corrupt another.
+
+   - Since the cache is most frequently updated, it is most
+     vulnerable to corruption during system restarts.  It can also
+     become full of expired RR data.  In either case, it can easily
+     be discarded without disturbing zone data.
+
+A major aspect of database design is selecting a structure which allows
+the name server to deal with crashes of the name server's host.  State
+information which a name server should save across system crashes
+
+
+
+Mockapetris                                                    [Page 38]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+includes the catalog structure (including the state of refreshing for
+each zone) and the zone data itself.
+
+6.1.3. Time
+
+Both the TTL data for RRs and the timing data for refreshing activities
+depends on 32 bit timers in units of seconds.  Inside the database,
+refresh timers and TTLs for cached data conceptually "count down", while
+data in the zone stays with constant TTLs.
+
+A recommended implementation strategy is to store time in two ways:  as
+a relative increment and as an absolute time.  One way to do this is to
+use positive 32 bit numbers for one type and negative numbers for the
+other.  The RRs in zones use relative times; the refresh timers and
+cache data use absolute times.  Absolute numbers are taken with respect
+to some known origin and converted to relative values when placed in the
+response to a query.  When an absolute TTL is negative after conversion
+to relative, then the data is expired and should be ignored.
+
+6.2. Standard query processing
+
+The major algorithm for standard query processing is presented in
+[RFC-1034].
+
+When processing queries with QCLASS=*, or some other QCLASS which
+matches multiple classes, the response should never be authoritative
+unless the server can guarantee that the response covers all classes.
+
+When composing a response, RRs which are to be inserted in the
+additional section, but duplicate RRs in the answer or authority
+sections, may be omitted from the additional section.
+
+When a response is so long that truncation is required, the truncation
+should start at the end of the response and work forward in the
+datagram.  Thus if there is any data for the authority section, the
+answer section is guaranteed to be unique.
+
+The MINIMUM value in the SOA should be used to set a floor on the TTL of
+data distributed from a zone.  This floor function should be done when
+the data is copied into a response.  This will allow future dynamic
+update protocols to change the SOA MINIMUM field without ambiguous
+semantics.
+
+6.3. Zone refresh and reload processing
+
+In spite of a server's best efforts, it may be unable to load zone data
+from a master file due to syntax errors, etc., or be unable to refresh a
+zone within the its expiration parameter.  In this case, the name server
+
+
+
+Mockapetris                                                    [Page 39]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+should answer queries as if it were not supposed to possess the zone.
+
+If a master is sending a zone out via AXFR, and a new version is created
+during the transfer, the master should continue to send the old version
+if possible.  In any case, it should never send part of one version and
+part of another.  If completion is not possible, the master should reset
+the connection on which the zone transfer is taking place.
+
+6.4. Inverse queries (Optional)
+
+Inverse queries are an optional part of the DNS.  Name servers are not
+required to support any form of inverse queries.  If a name server
+receives an inverse query that it does not support, it returns an error
+response with the "Not Implemented" error set in the header.  While
+inverse query support is optional, all name servers must be at least
+able to return the error response.
+
+6.4.1. The contents of inverse queries and responses          Inverse
+queries reverse the mappings performed by standard query operations;
+while a standard query maps a domain name to a resource, an inverse
+query maps a resource to a domain name.  For example, a standard query
+might bind a domain name to a host address; the corresponding inverse
+query binds the host address to a domain name.
+
+Inverse queries take the form of a single RR in the answer section of
+the message, with an empty question section.  The owner name of the
+query RR and its TTL are not significant.  The response carries
+questions in the question section which identify all names possessing
+the query RR WHICH THE NAME SERVER KNOWS.  Since no name server knows
+about all of the domain name space, the response can never be assumed to
+be complete.  Thus inverse queries are primarily useful for database
+management and debugging activities.  Inverse queries are NOT an
+acceptable method of mapping host addresses to host names; use the IN-
+ADDR.ARPA domain instead.
+
+Where possible, name servers should provide case-insensitive comparisons
+for inverse queries.  Thus an inverse query asking for an MX RR of
+"Venera.isi.edu" should get the same response as a query for
+"VENERA.ISI.EDU"; an inverse query for HINFO RR "IBM-PC UNIX" should
+produce the same result as an inverse query for "IBM-pc unix".  However,
+this cannot be guaranteed because name servers may possess RRs that
+contain character strings but the name server does not know that the
+data is character.
+
+When a name server processes an inverse query, it either returns:
+
+   1. zero, one, or multiple domain names for the specified
+      resource as QNAMEs in the question section
+
+
+
+Mockapetris                                                    [Page 40]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+   2. an error code indicating that the name server doesn't support
+      inverse mapping of the specified resource type.
+
+When the response to an inverse query contains one or more QNAMEs, the
+owner name and TTL of the RR in the answer section which defines the
+inverse query is modified to exactly match an RR found at the first
+QNAME.
+
+RRs returned in the inverse queries cannot be cached using the same
+mechanism as is used for the replies to standard queries.  One reason
+for this is that a name might have multiple RRs of the same type, and
+only one would appear.  For example, an inverse query for a single
+address of a multiply homed host might create the impression that only
+one address existed.
+
+6.4.2. Inverse query and response example          The overall structure
+of an inverse query for retrieving the domain name that corresponds to
+Internet address 10.1.0.52 is shown below:
+
+                         +-----------------------------------------+
+           Header        |          OPCODE=IQUERY, ID=997          |
+                         +-----------------------------------------+
+          Question       |                 <empty>                 |
+                         +-----------------------------------------+
+           Answer        |        <anyname> A IN 10.1.0.52         |
+                         +-----------------------------------------+
+          Authority      |                 <empty>                 |
+                         +-----------------------------------------+
+         Additional      |                 <empty>                 |
+                         +-----------------------------------------+
+
+This query asks for a question whose answer is the Internet style
+address 10.1.0.52.  Since the owner name is not known, any domain name
+can be used as a placeholder (and is ignored).  A single octet of zero,
+signifying the root, is usually used because it minimizes the length of
+the message.  The TTL of the RR is not significant.  The response to
+this query might be:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 41]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+                         +-----------------------------------------+
+           Header        |         OPCODE=RESPONSE, ID=997         |
+                         +-----------------------------------------+
+          Question       |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU |
+                         +-----------------------------------------+
+           Answer        |  VENERA.ISI.EDU  A IN 10.1.0.52         |
+                         +-----------------------------------------+
+          Authority      |                 <empty>                 |
+                         +-----------------------------------------+
+         Additional      |                 <empty>                 |
+                         +-----------------------------------------+
+
+Note that the QTYPE in a response to an inverse query is the same as the
+TYPE field in the answer section of the inverse query.  Responses to
+inverse queries may contain multiple questions when the inverse is not
+unique.  If the question section in the response is not empty, then the
+RR in the answer section is modified to correspond to be an exact copy
+of an RR at the first QNAME.
+
+6.4.3. Inverse query processing
+
+Name servers that support inverse queries can support these operations
+through exhaustive searches of their databases, but this becomes
+impractical as the size of the database increases.  An alternative
+approach is to invert the database according to the search key.
+
+For name servers that support multiple zones and a large amount of data,
+the recommended approach is separate inversions for each zone.  When a
+particular zone is changed during a refresh, only its inversions need to
+be redone.
+
+Support for transfer of this type of inversion may be included in future
+versions of the domain system, but is not supported in this version.
+
+6.5. Completion queries and responses
+
+The optional completion services described in RFC-882 and RFC-883 have
+been deleted.  Redesigned services may become available in the future.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 42]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+7. RESOLVER IMPLEMENTATION
+
+The top levels of the recommended resolver algorithm are discussed in
+[RFC-1034].  This section discusses implementation details assuming the
+database structure suggested in the name server implementation section
+of this memo.
+
+7.1. Transforming a user request into a query
+
+The first step a resolver takes is to transform the client's request,
+stated in a format suitable to the local OS, into a search specification
+for RRs at a specific name which match a specific QTYPE and QCLASS.
+Where possible, the QTYPE and QCLASS should correspond to a single type
+and a single class, because this makes the use of cached data much
+simpler.  The reason for this is that the presence of data of one type
+in a cache doesn't confirm the existence or non-existence of data of
+other types, hence the only way to be sure is to consult an
+authoritative source.  If QCLASS=* is used, then authoritative answers
+won't be available.
+
+Since a resolver must be able to multiplex multiple requests if it is to
+perform its function efficiently, each pending request is usually
+represented in some block of state information.  This state block will
+typically contain:
+
+   - A timestamp indicating the time the request began.
+     The timestamp is used to decide whether RRs in the database
+     can be used or are out of date.  This timestamp uses the
+     absolute time format previously discussed for RR storage in
+     zones and caches.  Note that when an RRs TTL indicates a
+     relative time, the RR must be timely, since it is part of a
+     zone.  When the RR has an absolute time, it is part of a
+     cache, and the TTL of the RR is compared against the timestamp
+     for the start of the request.
+
+     Note that using the timestamp is superior to using a current
+     time, since it allows RRs with TTLs of zero to be entered in
+     the cache in the usual manner, but still used by the current
+     request, even after intervals of many seconds due to system
+     load, query retransmission timeouts, etc.
+
+   - Some sort of parameters to limit the amount of work which will
+     be performed for this request.
+
+     The amount of work which a resolver will do in response to a
+     client request must be limited to guard against errors in the
+     database, such as circular CNAME references, and operational
+     problems, such as network partition which prevents the
+
+
+
+Mockapetris                                                    [Page 43]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+     resolver from accessing the name servers it needs.  While
+     local limits on the number of times a resolver will retransmit
+     a particular query to a particular name server address are
+     essential, the resolver should have a global per-request
+     counter to limit work on a single request.  The counter should
+     be set to some initial value and decremented whenever the
+     resolver performs any action (retransmission timeout,
+     retransmission, etc.)  If the counter passes zero, the request
+     is terminated with a temporary error.
+
+     Note that if the resolver structure allows one request to
+     start others in parallel, such as when the need to access a
+     name server for one request causes a parallel resolve for the
+     name server's addresses, the spawned request should be started
+     with a lower counter.  This prevents circular references in
+     the database from starting a chain reaction of resolver
+     activity.
+
+   - The SLIST data structure discussed in [RFC-1034].
+
+     This structure keeps track of the state of a request if it
+     must wait for answers from foreign name servers.
+
+7.2. Sending the queries
+
+As described in [RFC-1034], the basic task of the resolver is to
+formulate a query which will answer the client's request and direct that
+query to name servers which can provide the information.  The resolver
+will usually only have very strong hints about which servers to ask, in
+the form of NS RRs, and may have to revise the query, in response to
+CNAMEs, or revise the set of name servers the resolver is asking, in
+response to delegation responses which point the resolver to name
+servers closer to the desired information.  In addition to the
+information requested by the client, the resolver may have to call upon
+its own services to determine the address of name servers it wishes to
+contact.
+
+In any case, the model used in this memo assumes that the resolver is
+multiplexing attention between multiple requests, some from the client,
+and some internally generated.  Each request is represented by some
+state information, and the desired behavior is that the resolver
+transmit queries to name servers in a way that maximizes the probability
+that the request is answered, minimizes the time that the request takes,
+and avoids excessive transmissions.  The key algorithm uses the state
+information of the request to select the next name server address to
+query, and also computes a timeout which will cause the next action
+should a response not arrive.  The next action will usually be a
+transmission to some other server, but may be a temporary error to the
+
+
+
+Mockapetris                                                    [Page 44]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+client.
+
+The resolver always starts with a list of server names to query (SLIST).
+This list will be all NS RRs which correspond to the nearest ancestor
+zone that the resolver knows about.  To avoid startup problems, the
+resolver should have a set of default servers which it will ask should
+it have no current NS RRs which are appropriate.  The resolver then adds
+to SLIST all of the known addresses for the name servers, and may start
+parallel requests to acquire the addresses of the servers when the
+resolver has the name, but no addresses, for the name servers.
+
+To complete initialization of SLIST, the resolver attaches whatever
+history information it has to the each address in SLIST.  This will
+usually consist of some sort of weighted averages for the response time
+of the address, and the batting average of the address (i.e., how often
+the address responded at all to the request).  Note that this
+information should be kept on a per address basis, rather than on a per
+name server basis, because the response time and batting average of a
+particular server may vary considerably from address to address.  Note
+also that this information is actually specific to a resolver address /
+server address pair, so a resolver with multiple addresses may wish to
+keep separate histories for each of its addresses.  Part of this step
+must deal with addresses which have no such history; in this case an
+expected round trip time of 5-10 seconds should be the worst case, with
+lower estimates for the same local network, etc.
+
+Note that whenever a delegation is followed, the resolver algorithm
+reinitializes SLIST.
+
+The information establishes a partial ranking of the available name
+server addresses.  Each time an address is chosen and the state should
+be altered to prevent its selection again until all other addresses have
+been tried.  The timeout for each transmission should be 50-100% greater
+than the average predicted value to allow for variance in response.
+
+Some fine points:
+
+   - The resolver may encounter a situation where no addresses are
+     available for any of the name servers named in SLIST, and
+     where the servers in the list are precisely those which would
+     normally be used to look up their own addresses.  This
+     situation typically occurs when the glue address RRs have a
+     smaller TTL than the NS RRs marking delegation, or when the
+     resolver caches the result of a NS search.  The resolver
+     should detect this condition and restart the search at the
+     next ancestor zone, or alternatively at the root.
+
+
+
+
+
+Mockapetris                                                    [Page 45]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+   - If a resolver gets a server error or other bizarre response
+     from a name server, it should remove it from SLIST, and may
+     wish to schedule an immediate transmission to the next
+     candidate server address.
+
+7.3. Processing responses
+
+The first step in processing arriving response datagrams is to parse the
+response.  This procedure should include:
+
+   - Check the header for reasonableness.  Discard datagrams which
+     are queries when responses are expected.
+
+   - Parse the sections of the message, and insure that all RRs are
+     correctly formatted.
+
+   - As an optional step, check the TTLs of arriving data looking
+     for RRs with excessively long TTLs.  If a RR has an
+     excessively long TTL, say greater than 1 week, either discard
+     the whole response, or limit all TTLs in the response to 1
+     week.
+
+The next step is to match the response to a current resolver request.
+The recommended strategy is to do a preliminary matching using the ID
+field in the domain header, and then to verify that the question section
+corresponds to the information currently desired.  This requires that
+the transmission algorithm devote several bits of the domain ID field to
+a request identifier of some sort.  This step has several fine points:
+
+   - Some name servers send their responses from different
+     addresses than the one used to receive the query.  That is, a
+     resolver cannot rely that a response will come from the same
+     address which it sent the corresponding query to.  This name
+     server bug is typically encountered in UNIX systems.
+
+   - If the resolver retransmits a particular request to a name
+     server it should be able to use a response from any of the
+     transmissions.  However, if it is using the response to sample
+     the round trip time to access the name server, it must be able
+     to determine which transmission matches the response (and keep
+     transmission times for each outgoing message), or only
+     calculate round trip times based on initial transmissions.
+
+   - A name server will occasionally not have a current copy of a
+     zone which it should have according to some NS RRs.  The
+     resolver should simply remove the name server from the current
+     SLIST, and continue.
+
+
+
+
+Mockapetris                                                    [Page 46]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+7.4. Using the cache
+
+In general, we expect a resolver to cache all data which it receives in
+responses since it may be useful in answering future client requests.
+However, there are several types of data which should not be cached:
+
+   - When several RRs of the same type are available for a
+     particular owner name, the resolver should either cache them
+     all or none at all.  When a response is truncated, and a
+     resolver doesn't know whether it has a complete set, it should
+     not cache a possibly partial set of RRs.
+
+   - Cached data should never be used in preference to
+     authoritative data, so if caching would cause this to happen
+     the data should not be cached.
+
+   - The results of an inverse query should not be cached.
+
+   - The results of standard queries where the QNAME contains "*"
+     labels if the data might be used to construct wildcards.  The
+     reason is that the cache does not necessarily contain existing
+     RRs or zone boundary information which is necessary to
+     restrict the application of the wildcard RRs.
+
+   - RR data in responses of dubious reliability.  When a resolver
+     receives unsolicited responses or RR data other than that
+     requested, it should discard it without caching it.  The basic
+     implication is that all sanity checks on a packet should be
+     performed before any of it is cached.
+
+In a similar vein, when a resolver has a set of RRs for some name in a
+response, and wants to cache the RRs, it should check its cache for
+already existing RRs.  Depending on the circumstances, either the data
+in the response or the cache is preferred, but the two should never be
+combined.  If the data in the response is from authoritative data in the
+answer section, it is always preferred.
+
+8. MAIL SUPPORT
+
+The domain system defines a standard for mapping mailboxes into domain
+names, and two methods for using the mailbox information to derive mail
+routing information.  The first method is called mail exchange binding
+and the other method is mailbox binding.  The mailbox encoding standard
+and mail exchange binding are part of the DNS official protocol, and are
+the recommended method for mail routing in the Internet.  Mailbox
+binding is an experimental feature which is still under development and
+subject to change.
+
+
+
+
+Mockapetris                                                    [Page 47]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+The mailbox encoding standard assumes a mailbox name of the form
+"<local-part>@<mail-domain>".  While the syntax allowed in each of these
+sections varies substantially between the various mail internets, the
+preferred syntax for the ARPA Internet is given in [RFC-822].
+
+The DNS encodes the <local-part> as a single label, and encodes the
+<mail-domain> as a domain name.  The single label from the <local-part>
+is prefaced to the domain name from <mail-domain> to form the domain
+name corresponding to the mailbox.  Thus the mailbox HOSTMASTER@SRI-
+NIC.ARPA is mapped into the domain name HOSTMASTER.SRI-NIC.ARPA.  If the
+<local-part> contains dots or other special characters, its
+representation in a master file will require the use of backslash
+quoting to ensure that the domain name is properly encoded.  For
+example, the mailbox Action.domains@ISI.EDU would be represented as
+Action\.domains.ISI.EDU.
+
+8.1. Mail exchange binding
+
+Mail exchange binding uses the <mail-domain> part of a mailbox
+specification to determine where mail should be sent.  The <local-part>
+is not even consulted.  [RFC-974] specifies this method in detail, and
+should be consulted before attempting to use mail exchange support.
+
+One of the advantages of this method is that it decouples mail
+destination naming from the hosts used to support mail service, at the
+cost of another layer of indirection in the lookup function.  However,
+the addition layer should eliminate the need for complicated "%", "!",
+etc encodings in <local-part>.
+
+The essence of the method is that the <mail-domain> is used as a domain
+name to locate type MX RRs which list hosts willing to accept mail for
+<mail-domain>, together with preference values which rank the hosts
+according to an order specified by the administrators for <mail-domain>.
+
+In this memo, the <mail-domain> ISI.EDU is used in examples, together
+with the hosts VENERA.ISI.EDU and VAXA.ISI.EDU as mail exchanges for
+ISI.EDU.  If a mailer had a message for Mockapetris@ISI.EDU, it would
+route it by looking up MX RRs for ISI.EDU.  The MX RRs at ISI.EDU name
+VENERA.ISI.EDU and VAXA.ISI.EDU, and type A queries can find the host
+addresses.
+
+8.2. Mailbox binding (Experimental)
+
+In mailbox binding, the mailer uses the entire mail destination
+specification to construct a domain name.  The encoded domain name for
+the mailbox is used as the QNAME field in a QTYPE=MAILB query.
+
+Several outcomes are possible for this query:
+
+
+
+Mockapetris                                                    [Page 48]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+   1. The query can return a name error indicating that the mailbox
+      does not exist as a domain name.
+
+      In the long term, this would indicate that the specified
+      mailbox doesn't exist.  However, until the use of mailbox
+      binding is universal, this error condition should be
+      interpreted to mean that the organization identified by the
+      global part does not support mailbox binding.  The
+      appropriate procedure is to revert to exchange binding at
+      this point.
+
+   2. The query can return a Mail Rename (MR) RR.
+
+      The MR RR carries new mailbox specification in its RDATA
+      field.  The mailer should replace the old mailbox with the
+      new one and retry the operation.
+
+   3. The query can return a MB RR.
+
+      The MB RR carries a domain name for a host in its RDATA
+      field.  The mailer should deliver the message to that host
+      via whatever protocol is applicable, e.g., b,SMTP.
+
+   4. The query can return one or more Mail Group (MG) RRs.
+
+      This condition means that the mailbox was actually a mailing
+      list or mail group, rather than a single mailbox.  Each MG RR
+      has a RDATA field that identifies a mailbox that is a member
+      of the group.  The mailer should deliver a copy of the
+      message to each member.
+
+   5. The query can return a MB RR as well as one or more MG RRs.
+
+      This condition means the the mailbox was actually a mailing
+      list.  The mailer can either deliver the message to the host
+      specified by the MB RR, which will in turn do the delivery to
+      all members, or the mailer can use the MG RRs to do the
+      expansion itself.
+
+In any of these cases, the response may include a Mail Information
+(MINFO) RR.  This RR is usually associated with a mail group, but is
+legal with a MB.  The MINFO RR identifies two mailboxes.  One of these
+identifies a responsible person for the original mailbox name.  This
+mailbox should be used for requests to be added to a mail group, etc.
+The second mailbox name in the MINFO RR identifies a mailbox that should
+receive error messages for mail failures.  This is particularly
+appropriate for mailing lists when errors in member names should be
+reported to a person other than the one who sends a message to the list.
+
+
+
+Mockapetris                                                    [Page 49]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+New fields may be added to this RR in the future.
+
+
+9. REFERENCES and BIBLIOGRAPHY
+
+[Dyer 87]       S. Dyer, F. Hsu, "Hesiod", Project Athena
+                Technical Plan - Name Service, April 1987, version 1.9.
+
+                Describes the fundamentals of the Hesiod name service.
+
+[IEN-116]       J. Postel, "Internet Name Server", IEN-116,
+                USC/Information Sciences Institute, August 1979.
+
+                A name service obsoleted by the Domain Name System, but
+                still in use.
+
+[Quarterman 86] J. Quarterman, and J. Hoskins, "Notable Computer Networks",
+                Communications of the ACM, October 1986, volume 29, number
+                10.
+
+[RFC-742]       K. Harrenstien, "NAME/FINGER", RFC-742, Network
+                Information Center, SRI International, December 1977.
+
+[RFC-768]       J. Postel, "User Datagram Protocol", RFC-768,
+                USC/Information Sciences Institute, August 1980.
+
+[RFC-793]       J. Postel, "Transmission Control Protocol", RFC-793,
+                USC/Information Sciences Institute, September 1981.
+
+[RFC-799]       D. Mills, "Internet Name Domains", RFC-799, COMSAT,
+                September 1981.
+
+                Suggests introduction of a hierarchy in place of a flat
+                name space for the Internet.
+
+[RFC-805]       J. Postel, "Computer Mail Meeting Notes", RFC-805,
+                USC/Information Sciences Institute, February 1982.
+
+[RFC-810]       E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD
+                Internet Host Table Specification", RFC-810, Network
+                Information Center, SRI International, March 1982.
+
+                Obsolete.  See RFC-952.
+
+[RFC-811]       K. Harrenstien, V. White, and E. Feinler, "Hostnames
+                Server", RFC-811, Network Information Center, SRI
+                International, March 1982.
+
+
+
+
+Mockapetris                                                    [Page 50]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+                Obsolete.  See RFC-953.
+
+[RFC-812]       K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,
+                Network Information Center, SRI International, March
+                1982.
+
+[RFC-819]       Z. Su, and J. Postel, "The Domain Naming Convention for
+                Internet User Applications", RFC-819, Network
+                Information Center, SRI International, August 1982.
+
+                Early thoughts on the design of the domain system.
+                Current implementation is completely different.
+
+[RFC-821]       J. Postel, "Simple Mail Transfer Protocol", RFC-821,
+                USC/Information Sciences Institute, August 1980.
+
+[RFC-830]       Z. Su, "A Distributed System for Internet Name Service",
+                RFC-830, Network Information Center, SRI International,
+                October 1982.
+
+                Early thoughts on the design of the domain system.
+                Current implementation is completely different.
+
+[RFC-882]       P. Mockapetris, "Domain names - Concepts and
+                Facilities," RFC-882, USC/Information Sciences
+                Institute, November 1983.
+
+                Superceeded by this memo.
+
+[RFC-883]       P. Mockapetris, "Domain names - Implementation and
+                Specification," RFC-883, USC/Information Sciences
+                Institute, November 1983.
+
+                Superceeded by this memo.
+
+[RFC-920]       J. Postel and J. Reynolds, "Domain Requirements",
+                RFC-920, USC/Information Sciences Institute,
+                October 1984.
+
+                Explains the naming scheme for top level domains.
+
+[RFC-952]       K. Harrenstien, M. Stahl, 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.
+
+
+
+
+
+Mockapetris                                                    [Page 51]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+[RFC-953]       K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",
+                RFC-953, SRI, October 1985.
+
+                This RFC contains the official specification of the
+                hostname server protocol, which is obsoleted by the DNS.
+                This TCP based protocol accesses information stored in
+                the RFC-952 format, and is used to obtain copies of the
+                host table.
+
+[RFC-973]       P. Mockapetris, "Domain System Changes and
+                Observations", RFC-973, USC/Information Sciences
+                Institute, January 1986.
+
+                Describes changes to RFC-882 and RFC-883 and reasons for
+                them.
+
+[RFC-974]       C. Partridge, "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.
+
+[RFC-1001]      NetBIOS Working Group, "Protocol standard for a NetBIOS
+                service on a TCP/UDP transport: Concepts and Methods",
+                RFC-1001, March 1987.
+
+                This RFC and RFC-1002 are a preliminary design for
+                NETBIOS on top of TCP/IP which proposes to base NetBIOS
+                name service on top of the DNS.
+
+[RFC-1002]      NetBIOS Working Group, "Protocol standard for a NetBIOS
+                service on a TCP/UDP transport: Detailed
+                Specifications", RFC-1002, March 1987.
+
+[RFC-1010]      J. Reynolds, 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-1031]      W. Lazear, "MILNET Name Domain Transition", RFC-1031,
+                November 1987.
+
+                Describes a plan for converting the MILNET to the DNS.
+
+[RFC-1032]      M. Stahl, "Establishing a Domain - Guidelines for
+                Administrators", RFC-1032, November 1987.
+
+
+
+Mockapetris                                                    [Page 52]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+                Describes the registration policies used by the NIC to
+                administer the top level domains and delegate subzones.
+
+[RFC-1033]      M. Lottor, "Domain Administrators Operations Guide",
+                RFC-1033, November 1987.
+
+                A cookbook for domain administrators.
+
+[Solomon 82]    M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET
+                Name Server", Computer Networks, vol 6, nr 3, July 1982.
+
+                Describes a name service for CSNET which is independent
+                from the DNS and DNS use in the CSNET.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 53]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+Index
+
+          *   13
+
+          ;   33, 35
+
+          <character-string>   35
+          <domain-name>   34
+
+          @   35
+
+          \   35
+
+          A   12
+
+          Byte order   8
+
+          CH   13
+          Character case   9
+          CLASS   11
+          CNAME   12
+          Completion   42
+          CS   13
+
+          Hesiod   13
+          HINFO   12
+          HS   13
+
+          IN   13
+          IN-ADDR.ARPA domain   22
+          Inverse queries   40
+
+          Mailbox names   47
+          MB   12
+          MD   12
+          MF   12
+          MG   12
+          MINFO   12
+          MINIMUM   20
+          MR   12
+          MX   12
+
+          NS   12
+          NULL   12
+
+          Port numbers   32
+          Primary server   5
+          PTR   12, 18
+
+
+
+Mockapetris                                                    [Page 54]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+          QCLASS   13
+          QTYPE   12
+
+          RDATA   12
+          RDLENGTH  11
+
+          Secondary server   5
+          SOA   12
+          Stub resolvers   7
+
+          TCP   32
+          TXT   12
+          TYPE   11
+
+          UDP   32
+
+          WKS   12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 55]
+
diff --git a/usr.sbin/named/doc/rfc/rfc1101 b/usr.sbin/named/doc/rfc/rfc1101
new file mode 100644
index 00000000000..66c9d8b813b
--- /dev/null
+++ b/usr.sbin/named/doc/rfc/rfc1101
@@ -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]
+
\ No newline at end of file
diff --git a/usr.sbin/named/doc/rfc/rfc1122 b/usr.sbin/named/doc/rfc/rfc1122
new file mode 100644
index 00000000000..c14f2e50a31
--- /dev/null
+++ b/usr.sbin/named/doc/rfc/rfc1122
@@ -0,0 +1,6844 @@
+
+
+
+
+
+
+Network Working Group                    Internet Engineering Task Force
+Request for Comments: 1122                             R. Braden, Editor
+                                                            October 1989
+
+
+        Requirements for Internet Hosts -- Communication Layers
+
+
+Status of This Memo
+
+   This RFC is an official specification for the Internet community.  It
+   incorporates by reference, amends, corrects, and supplements the
+   primary protocol standards documents relating to hosts.  Distribution
+   of this document is unlimited.
+
+Summary
+
+   This is one RFC of a pair that defines and discusses the requirements
+   for Internet host software.  This RFC covers the communications
+   protocol layers: link layer, IP layer, and transport layer; its
+   companion RFC-1123 covers the application and support protocols.
+
+
+
+                           Table of Contents
+
+
+
+
+   1.  INTRODUCTION ...............................................    5
+      1.1  The Internet Architecture ..............................    6
+         1.1.1  Internet Hosts ....................................    6
+         1.1.2  Architectural Assumptions .........................    7
+         1.1.3  Internet Protocol Suite ...........................    8
+         1.1.4  Embedded Gateway Code .............................   10
+      1.2  General Considerations .................................   12
+         1.2.1  Continuing Internet Evolution .....................   12
+         1.2.2  Robustness Principle ..............................   12
+         1.2.3  Error Logging .....................................   13
+         1.2.4  Configuration .....................................   14
+      1.3  Reading this Document ..................................   15
+         1.3.1  Organization ......................................   15
+         1.3.2  Requirements ......................................   16
+         1.3.3  Terminology .......................................   17
+      1.4  Acknowledgments ........................................   20
+
+   2. LINK LAYER ..................................................   21
+      2.1  INTRODUCTION ...........................................   21
+
+
+
+Internet Engineering Task Force                                 [Page 1]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+      2.2  PROTOCOL WALK-THROUGH ..................................   21
+      2.3  SPECIFIC ISSUES ........................................   21
+         2.3.1  Trailer Protocol Negotiation ......................   21
+         2.3.2  Address Resolution Protocol -- ARP ................   22
+            2.3.2.1  ARP Cache Validation .........................   22
+            2.3.2.2  ARP Packet Queue .............................   24
+         2.3.3  Ethernet and IEEE 802 Encapsulation ...............   24
+      2.4  LINK/INTERNET LAYER INTERFACE ..........................   25
+      2.5  LINK LAYER REQUIREMENTS SUMMARY ........................   26
+
+   3. INTERNET LAYER PROTOCOLS ....................................   27
+      3.1 INTRODUCTION ............................................   27
+      3.2  PROTOCOL WALK-THROUGH ..................................   29
+         3.2.1 Internet Protocol -- IP ............................   29
+            3.2.1.1  Version Number ...............................   29
+            3.2.1.2  Checksum .....................................   29
+            3.2.1.3  Addressing ...................................   29
+            3.2.1.4  Fragmentation and Reassembly .................   32
+            3.2.1.5  Identification ...............................   32
+            3.2.1.6  Type-of-Service ..............................   33
+            3.2.1.7  Time-to-Live .................................   34
+            3.2.1.8  Options ......................................   35
+         3.2.2 Internet Control Message Protocol -- ICMP ..........   38
+            3.2.2.1  Destination Unreachable ......................   39
+            3.2.2.2  Redirect .....................................   40
+            3.2.2.3  Source Quench ................................   41
+            3.2.2.4  Time Exceeded ................................   41
+            3.2.2.5  Parameter Problem ............................   42
+            3.2.2.6  Echo Request/Reply ...........................   42
+            3.2.2.7  Information Request/Reply ....................   43
+            3.2.2.8  Timestamp and Timestamp Reply ................   43
+            3.2.2.9  Address Mask Request/Reply ...................   45
+         3.2.3  Internet Group Management Protocol IGMP ...........   47
+      3.3  SPECIFIC ISSUES ........................................   47
+         3.3.1  Routing Outbound Datagrams ........................   47
+            3.3.1.1  Local/Remote Decision ........................   47
+            3.3.1.2  Gateway Selection ............................   48
+            3.3.1.3  Route Cache ..................................   49
+            3.3.1.4  Dead Gateway Detection .......................   51
+            3.3.1.5  New Gateway Selection ........................   55
+            3.3.1.6  Initialization ...............................   56
+         3.3.2  Reassembly ........................................   56
+         3.3.3  Fragmentation .....................................   58
+         3.3.4  Local Multihoming .................................   60
+            3.3.4.1  Introduction .................................   60
+            3.3.4.2  Multihoming Requirements .....................   61
+            3.3.4.3  Choosing a Source Address ....................   64
+         3.3.5  Source Route Forwarding ...........................   65
+
+
+
+Internet Engineering Task Force                                 [Page 2]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+         3.3.6  Broadcasts ........................................   66
+         3.3.7  IP Multicasting ...................................   67
+         3.3.8  Error Reporting ...................................   69
+      3.4  INTERNET/TRANSPORT LAYER INTERFACE .....................   69
+      3.5  INTERNET LAYER REQUIREMENTS SUMMARY ....................   72
+
+   4. TRANSPORT PROTOCOLS .........................................   77
+      4.1  USER DATAGRAM PROTOCOL -- UDP ..........................   77
+         4.1.1  INTRODUCTION ......................................   77
+         4.1.2  PROTOCOL WALK-THROUGH .............................   77
+         4.1.3  SPECIFIC ISSUES ...................................   77
+            4.1.3.1  Ports ........................................   77
+            4.1.3.2  IP Options ...................................   77
+            4.1.3.3  ICMP Messages ................................   78
+            4.1.3.4  UDP Checksums ................................   78
+            4.1.3.5  UDP Multihoming ..............................   79
+            4.1.3.6  Invalid Addresses ............................   79
+         4.1.4  UDP/APPLICATION LAYER INTERFACE ...................   79
+         4.1.5  UDP REQUIREMENTS SUMMARY ..........................   80
+      4.2  TRANSMISSION CONTROL PROTOCOL -- TCP ...................   82
+         4.2.1  INTRODUCTION ......................................   82
+         4.2.2  PROTOCOL WALK-THROUGH .............................   82
+            4.2.2.1  Well-Known Ports .............................   82
+            4.2.2.2  Use of Push ..................................   82
+            4.2.2.3  Window Size ..................................   83
+            4.2.2.4  Urgent Pointer ...............................   84
+            4.2.2.5  TCP Options ..................................   85
+            4.2.2.6  Maximum Segment Size Option ..................   85
+            4.2.2.7  TCP Checksum .................................   86
+            4.2.2.8  TCP Connection State Diagram .................   86
+            4.2.2.9  Initial Sequence Number Selection ............   87
+            4.2.2.10  Simultaneous Open Attempts ..................   87
+            4.2.2.11  Recovery from Old Duplicate SYN .............   87
+            4.2.2.12  RST Segment .................................   87
+            4.2.2.13  Closing a Connection ........................   87
+            4.2.2.14  Data Communication ..........................   89
+            4.2.2.15  Retransmission Timeout ......................   90
+            4.2.2.16  Managing the Window .........................   91
+            4.2.2.17  Probing Zero Windows ........................   92
+            4.2.2.18  Passive OPEN Calls ..........................   92
+            4.2.2.19  Time to Live ................................   93
+            4.2.2.20  Event Processing ............................   93
+            4.2.2.21  Acknowledging Queued Segments ...............   94
+         4.2.3  SPECIFIC ISSUES ...................................   95
+            4.2.3.1  Retransmission Timeout Calculation ...........   95
+            4.2.3.2  When to Send an ACK Segment ..................   96
+            4.2.3.3  When to Send a Window Update .................   97
+            4.2.3.4  When to Send Data ............................   98
+
+
+
+Internet Engineering Task Force                                 [Page 3]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+            4.2.3.5  TCP Connection Failures ......................  100
+            4.2.3.6  TCP Keep-Alives ..............................  101
+            4.2.3.7  TCP Multihoming ..............................  103
+            4.2.3.8  IP Options ...................................  103
+            4.2.3.9  ICMP Messages ................................  103
+            4.2.3.10  Remote Address Validation ...................  104
+            4.2.3.11  TCP Traffic Patterns ........................  104
+            4.2.3.12  Efficiency ..................................  105
+         4.2.4  TCP/APPLICATION LAYER INTERFACE ...................  106
+            4.2.4.1  Asynchronous Reports .........................  106
+            4.2.4.2  Type-of-Service ..............................  107
+            4.2.4.3  Flush Call ...................................  107
+            4.2.4.4  Multihoming ..................................  108
+         4.2.5  TCP REQUIREMENT SUMMARY ...........................  108
+
+   5.  REFERENCES .................................................  112
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                 [Page 4]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+1.  INTRODUCTION
+
+   This document is one of a pair that defines and discusses the
+   requirements for host system implementations of the Internet protocol
+   suite.  This RFC covers the communication protocol layers:  link
+   layer, IP layer, and transport layer.  Its companion RFC,
+   "Requirements for Internet Hosts -- Application and Support"
+   [INTRO:1], covers the application layer protocols.  This document
+   should also be read in conjunction with "Requirements for Internet
+   Gateways" [INTRO:2].
+
+   These documents are intended to provide guidance for vendors,
+   implementors, and users of Internet communication software.  They
+   represent the consensus of a large body of technical experience and
+   wisdom, contributed by the members of the Internet research and
+   vendor communities.
+
+   This RFC enumerates standard protocols that a host connected to the
+   Internet must use, and it incorporates by reference the RFCs and
+   other documents describing the current specifications for these
+   protocols.  It corrects errors in the referenced documents and adds
+   additional discussion and guidance for an implementor.
+
+   For each protocol, this document also contains an explicit set of
+   requirements, recommendations, and options.  The reader must
+   understand that the list of requirements in this document is
+   incomplete by itself; the complete set of requirements for an
+   Internet host is primarily defined in the standard protocol
+   specification documents, with the corrections, amendments, and
+   supplements contained in this RFC.
+
+   A good-faith implementation of the protocols that was produced after
+   careful reading of the RFC's and with some interaction with the
+   Internet technical community, and that followed good communications
+   software engineering practices, should differ from the requirements
+   of this document in only minor ways.  Thus, in many cases, the
+   "requirements" in this RFC are already stated or implied in the
+   standard protocol documents, so that their inclusion here is, in a
+   sense, redundant.  However, they were included because some past
+   implementation has made the wrong choice, causing problems of
+   interoperability, performance, and/or robustness.
+
+   This document includes discussion and explanation of many of the
+   requirements and recommendations.  A simple list of requirements
+   would be dangerous, because:
+
+   o    Some required features are more important than others, and some
+        features are optional.
+
+
+
+Internet Engineering Task Force                                 [Page 5]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+   o    There may be valid reasons why particular vendor products that
+        are designed for restricted contexts might choose to use
+        different specifications.
+
+   However, the specifications of this document must be followed to meet
+   the general goal of arbitrary host interoperation across the
+   diversity and complexity of the Internet system.  Although most
+   current implementations fail to meet these requirements in various
+   ways, some minor and some major, this specification is the ideal
+   towards which we need to move.
+
+   These requirements are based on the current level of Internet
+   architecture.  This document will be updated as required to provide
+   additional clarifications or to include additional information in
+   those areas in which specifications are still evolving.
+
+   This introductory section begins with a brief overview of the
+   Internet architecture as it relates to hosts, and then gives some
+   general advice to host software vendors.  Finally, there is some
+   guidance on reading the rest of the document and some terminology.
+
+   1.1  The Internet Architecture
+
+      General background and discussion on the Internet architecture and
+      supporting protocol suite can be found in the DDN Protocol
+      Handbook [INTRO:3]; for background see for example [INTRO:9],
+      [INTRO:10], and [INTRO:11].  Reference [INTRO:5] describes the
+      procedure for obtaining Internet protocol documents, while
+      [INTRO:6] contains a list of the numbers assigned within Internet
+      protocols.
+
+      1.1.1  Internet Hosts
+
+         A host computer, or simply "host," is the ultimate consumer of
+         communication services.  A host generally executes application
+         programs on behalf of user(s), employing network and/or
+         Internet communication services in support of this function.
+         An Internet host corresponds to the concept of an "End-System"
+         used in the OSI protocol suite [INTRO:13].
+
+         An Internet communication system consists of interconnected
+         packet networks supporting communication among host computers
+         using the Internet protocols.  The networks are interconnected
+         using packet-switching computers called "gateways" or "IP
+         routers" by the Internet community, and "Intermediate Systems"
+         by the OSI world [INTRO:13].  The RFC "Requirements for
+         Internet Gateways" [INTRO:2] contains the official
+         specifications for Internet gateways.  That RFC together with
+
+
+
+Internet Engineering Task Force                                 [Page 6]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+         the present document and its companion [INTRO:1] define the
+         rules for the current realization of the Internet architecture.
+
+         Internet hosts span a wide range of size, speed, and function.
+         They range in size from small microprocessors through
+         workstations to mainframes and supercomputers.  In function,
+         they range from single-purpose hosts (such as terminal servers)
+         to full-service hosts that support a variety of online network
+         services, typically including remote login, file transfer, and
+         electronic mail.
+
+         A host is generally said to be multihomed if it has more than
+         one interface to the same or to different networks.  See
+         Section 1.1.3 on "Terminology".
+
+      1.1.2  Architectural Assumptions
+
+         The current Internet architecture is based on a set of
+         assumptions about the communication system.  The assumptions
+         most relevant to hosts are as follows:
+
+         (a)  The Internet is a network of networks.
+
+              Each host is directly connected to some particular
+              network(s); its connection to the Internet is only
+              conceptual.  Two hosts on the same network communicate
+              with each other using the same set of protocols that they
+              would use to communicate with hosts on distant networks.
+
+         (b)  Gateways don't keep connection state information.
+
+              To improve robustness of the communication system,
+              gateways are designed to be stateless, forwarding each IP
+              datagram independently of other datagrams.  As a result,
+              redundant paths can be exploited to provide robust service
+              in spite of failures of intervening gateways and networks.
+
+              All state information required for end-to-end flow control
+              and reliability is implemented in the hosts, in the
+              transport layer or in application programs.  All
+              connection control information is thus co-located with the
+              end points of the communication, so it will be lost only
+              if an end point fails.
+
+         (c)  Routing complexity should be in the gateways.
+
+              Routing is a complex and difficult problem, and ought to
+              be performed by the gateways, not the hosts.  An important
+
+
+
+Internet Engineering Task Force                                 [Page 7]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+              objective is to insulate host software from changes caused
+              by the inevitable evolution of the Internet routing
+              architecture.
+
+         (d)  The System must tolerate wide network variation.
+
+              A basic objective of the Internet design is to tolerate a
+              wide range of network characteristics -- e.g., bandwidth,
+              delay, packet loss, packet reordering, and maximum packet
+              size.  Another objective is robustness against failure of
+              individual networks, gateways, and hosts, using whatever
+              bandwidth is still available.  Finally, the goal is full
+              "open system interconnection": an Internet host must be
+              able to interoperate robustly and effectively with any
+              other Internet host, across diverse Internet paths.
+
+              Sometimes host implementors have designed for less
+              ambitious goals.  For example, the LAN environment is
+              typically much more benign than the Internet as a whole;
+              LANs have low packet loss and delay and do not reorder
+              packets.  Some vendors have fielded host implementations
+              that are adequate for a simple LAN environment, but work
+              badly for general interoperation.  The vendor justifies
+              such a product as being economical within the restricted
+              LAN market.  However, isolated LANs seldom stay isolated
+              for long; they are soon gatewayed to each other, to
+              organization-wide internets, and eventually to the global
+              Internet system.  In the end, neither the customer nor the
+              vendor is served by incomplete or substandard Internet
+              host software.
+
+              The requirements spelled out in this document are designed
+              for a full-function Internet host, capable of full
+              interoperation over an arbitrary Internet path.
+
+
+      1.1.3  Internet Protocol Suite
+
+         To communicate using the Internet system, a host must implement
+         the layered set of protocols comprising the Internet protocol
+         suite.  A host typically must implement at least one protocol
+         from each layer.
+
+         The protocol layers used in the Internet architecture are as
+         follows [INTRO:4]:
+
+
+         o  Application Layer
+
+
+
+Internet Engineering Task Force                                 [Page 8]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+              The application layer is the top layer of the Internet
+              protocol suite.  The Internet suite does not further
+              subdivide the application layer, although some of the
+              Internet application layer protocols do contain some
+              internal sub-layering.  The application layer of the
+              Internet suite essentially combines the functions of the
+              top two layers -- Presentation and Application -- of the
+              OSI reference model.
+
+              We distinguish two categories of application layer
+              protocols:  user protocols that provide service directly
+              to users, and support protocols that provide common system
+              functions.  Requirements for user and support protocols
+              will be found in the companion RFC [INTRO:1].
+
+              The most common Internet user protocols are:
+
+                o  Telnet (remote login)
+                o  FTP    (file transfer)
+                o  SMTP   (electronic mail delivery)
+
+              There are a number of other standardized user protocols
+              [INTRO:4] and many private user protocols.
+
+              Support protocols, used for host name mapping, booting,
+              and management, include SNMP, BOOTP, RARP, and the Domain
+              Name System (DNS) protocols.
+
+
+         o  Transport Layer
+
+              The transport layer provides end-to-end communication
+              services for applications.  There are two primary
+              transport layer protocols at present:
+
+                o Transmission Control Protocol (TCP)
+                o User Datagram Protocol (UDP)
+
+              TCP is a reliable connection-oriented transport service
+              that provides end-to-end reliability, resequencing, and
+              flow control.  UDP is a connectionless ("datagram")
+              transport service.
+
+              Other transport protocols have been developed by the
+              research community, and the set of official Internet
+              transport protocols may be expanded in the future.
+
+              Transport layer protocols are discussed in Chapter 4.
+
+
+
+Internet Engineering Task Force                                 [Page 9]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+         o  Internet Layer
+
+              All Internet transport protocols use the Internet Protocol
+              (IP) to carry data from source host to destination host.
+              IP is a connectionless or datagram internetwork service,
+              providing no end-to-end delivery guarantees. Thus, IP
+              datagrams may arrive at the destination host damaged,
+              duplicated, out of order, or not at all.  The layers above
+              IP are responsible for reliable delivery service when it
+              is required.  The IP protocol includes provision for
+              addressing, type-of-service specification, fragmentation
+              and reassembly, and security information.
+
+              The datagram or connectionless nature of the IP protocol
+              is a fundamental and characteristic feature of the
+              Internet architecture.  Internet IP was the model for the
+              OSI Connectionless Network Protocol [INTRO:12].
+
+              ICMP is a control protocol that is considered to be an
+              integral part of IP, although it is architecturally
+              layered upon IP, i.e., it uses IP to carry its data end-
+              to-end just as a transport protocol like TCP or UDP does.
+              ICMP provides error reporting, congestion reporting, and
+              first-hop gateway redirection.
+
+              IGMP is an Internet layer protocol used for establishing
+              dynamic host groups for IP multicasting.
+
+              The Internet layer protocols IP, ICMP, and IGMP are
+              discussed in Chapter 3.
+
+
+         o  Link Layer
+
+              To communicate on its directly-connected network, a host
+              must implement the communication protocol used to
+              interface to that network.  We call this a link layer or
+              media-access layer protocol.
+
+              There is a wide variety of link layer protocols,
+              corresponding to the many different types of networks.
+              See Chapter 2.
+
+
+      1.1.4  Embedded Gateway Code
+
+         Some Internet host software includes embedded gateway
+         functionality, so that these hosts can forward packets as a
+
+
+
+Internet Engineering Task Force                                [Page 10]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+         gateway would, while still performing the application layer
+         functions of a host.
+
+         Such dual-purpose systems must follow the Gateway Requirements
+         RFC [INTRO:2]  with respect to their gateway functions, and
+         must follow the present document with respect to their host
+         functions.  In all overlapping cases, the two specifications
+         should be in agreement.
+
+         There are varying opinions in the Internet community about
+         embedded gateway functionality.  The main arguments are as
+         follows:
+
+         o    Pro: in a local network environment where networking is
+              informal, or in isolated internets, it may be convenient
+              and economical to use existing host systems as gateways.
+
+              There is also an architectural argument for embedded
+              gateway functionality: multihoming is much more common
+              than originally foreseen, and multihoming forces a host to
+              make routing decisions as if it were a gateway.  If the
+              multihomed  host contains an embedded gateway, it will
+              have full routing knowledge and as a result will be able
+              to make more optimal routing decisions.
+
+         o    Con: Gateway algorithms and protocols are still changing,
+              and they will continue to change as the Internet system
+              grows larger.  Attempting to include a general gateway
+              function within the host IP layer will force host system
+              maintainers to track these (more frequent) changes.  Also,
+              a larger pool of gateway implementations will make
+              coordinating the changes more difficult.  Finally, the
+              complexity of a gateway IP layer is somewhat greater than
+              that of a host, making the implementation and operation
+              tasks more complex.
+
+              In addition, the style of operation of some hosts is not
+              appropriate for providing stable and robust gateway
+              service.
+
+         There is considerable merit in both of these viewpoints.  One
+         conclusion can be drawn: an host administrator must have
+         conscious control over whether or not a given host acts as a
+         gateway.  See Section 3.1 for the detailed requirements.
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 11]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+   1.2  General Considerations
+
+      There are two important lessons that vendors of Internet host
+      software have learned and which a new vendor should consider
+      seriously.
+
+      1.2.1  Continuing Internet Evolution
+
+         The enormous growth of the Internet has revealed problems of
+         management and scaling in a large datagram-based packet
+         communication system.  These problems are being addressed, and
+         as a result there will be continuing evolution of the
+         specifications described in this document.  These changes will
+         be carefully planned and controlled, since there is extensive
+         participation in this planning by the vendors and by the
+         organizations responsible for operations of the networks.
+
+         Development, evolution, and revision are characteristic of
+         computer network protocols today, and this situation will
+         persist for some years.  A vendor who develops computer
+         communication software for the Internet protocol suite (or any
+         other protocol suite!) and then fails to maintain and update
+         that software for changing specifications is going to leave a
+         trail of unhappy customers.  The Internet is a large
+         communication network, and the users are in constant contact
+         through it.  Experience has shown that knowledge of
+         deficiencies in vendor software propagates quickly through the
+         Internet technical community.
+
+      1.2.2  Robustness Principle
+
+         At every layer of the protocols, there is a general rule whose
+         application can lead to enormous benefits in robustness and
+         interoperability [IP:1]:
+
+                "Be liberal in what you accept, and
+                 conservative in what you send"
+
+         Software should be written to deal with every conceivable
+         error, no matter how unlikely; sooner or later a packet will
+         come in with that particular combination of errors and
+         attributes, and unless the software is prepared, chaos can
+         ensue.  In general, it is best to assume that the network is
+         filled with malevolent entities that will send in packets
+         designed to have the worst possible effect.  This assumption
+         will lead to suitable protective design, although the most
+         serious problems in the Internet have been caused by
+         unenvisaged mechanisms triggered by low-probability events;
+
+
+
+Internet Engineering Task Force                                [Page 12]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+         mere human malice would never have taken so devious a course!
+
+         Adaptability to change must be designed into all levels of
+         Internet host software.  As a simple example, consider a
+         protocol specification that contains an enumeration of values
+         for a particular header field -- e.g., a type field, a port
+         number, or an error code; this enumeration must be assumed to
+         be incomplete.  Thus, if a protocol specification defines four
+         possible error codes, the software must not break when a fifth
+         code shows up.  An undefined code might be logged (see below),
+         but it must not cause a failure.
+
+         The second part of the principle is almost as important:
+         software on other hosts may contain deficiencies that make it
+         unwise to exploit legal but obscure protocol features.  It is
+         unwise to stray far from the obvious and simple, lest untoward
+         effects result elsewhere.  A corollary of this is "watch out
+         for misbehaving hosts"; host software should be prepared, not
+         just to survive other misbehaving hosts, but also to cooperate
+         to limit the amount of disruption such hosts can cause to the
+         shared communication facility.
+
+      1.2.3  Error Logging
+
+         The Internet includes a great variety of host and gateway
+         systems, each implementing many protocols and protocol layers,
+         and some of these contain bugs and mis-features in their
+         Internet protocol software.  As a result of complexity,
+         diversity, and distribution of function, the diagnosis of
+         Internet problems is often very difficult.
+
+         Problem diagnosis will be aided if host implementations include
+         a carefully designed facility for logging erroneous or
+         "strange" protocol events.  It is important to include as much
+         diagnostic information as possible when an error is logged.  In
+         particular, it is often useful to record the header(s) of a
+         packet that caused an error.  However, care must be taken to
+         ensure that error logging does not consume prohibitive amounts
+         of resources or otherwise interfere with the operation of the
+         host.
+
+         There is a tendency for abnormal but harmless protocol events
+         to overflow error logging files; this can be avoided by using a
+         "circular" log, or by enabling logging only while diagnosing a
+         known failure.  It may be useful to filter and count duplicate
+         successive messages.  One strategy that seems to work well is:
+         (1) always count abnormalities and make such counts accessible
+         through the management protocol (see [INTRO:1]); and (2) allow
+
+
+
+Internet Engineering Task Force                                [Page 13]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+         the logging of a great variety of events to be selectively
+         enabled.  For example, it might useful to be able to "log
+         everything" or to "log everything for host X".
+
+         Note that different managements may have differing policies
+         about the amount of error logging that they want normally
+         enabled in a host.  Some will say, "if it doesn't hurt me, I
+         don't want to know about it", while others will want to take a
+         more watchful and aggressive attitude about detecting and
+         removing protocol abnormalities.
+
+      1.2.4  Configuration
+
+         It would be ideal if a host implementation of the Internet
+         protocol suite could be entirely self-configuring.  This would
+         allow the whole suite to be implemented in ROM or cast into
+         silicon, it would simplify diskless workstations, and it would
+         be an immense boon to harried LAN administrators as well as
+         system vendors.  We have not reached this ideal; in fact, we
+         are not even close.
+
+         At many points in this document, you will find a requirement
+         that a parameter be a configurable option.  There are several
+         different reasons behind such requirements.  In a few cases,
+         there is current uncertainty or disagreement about the best
+         value, and it may be necessary to update the recommended value
+         in the future.  In other cases, the value really depends on
+         external factors -- e.g., the size of the host and the
+         distribution of its communication load, or the speeds and
+         topology of nearby networks -- and self-tuning algorithms are
+         unavailable and may be insufficient.  In some cases,
+         configurability is needed because of administrative
+         requirements.
+
+         Finally, some configuration options are required to communicate
+         with obsolete or incorrect implementations of the protocols,
+         distributed without sources, that unfortunately persist in many
+         parts of the Internet.  To make correct systems coexist with
+         these faulty systems, administrators often have to "mis-
+         configure" the correct systems.  This problem will correct
+         itself gradually as the faulty systems are retired, but it
+         cannot be ignored by vendors.
+
+         When we say that a parameter must be configurable, we do not
+         intend to require that its value be explicitly read from a
+         configuration file at every boot time.  We recommend that
+         implementors set up a default for each parameter, so a
+         configuration file is only necessary to override those defaults
+
+
+
+Internet Engineering Task Force                                [Page 14]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+         that are inappropriate in a particular installation.  Thus, the
+         configurability requirement is an assurance that it will be
+         POSSIBLE to override the default when necessary, even in a
+         binary-only or ROM-based product.
+
+         This document requires a particular value for such defaults in
+         some cases.  The choice of default is a sensitive issue when
+         the configuration item controls the accommodation to existing
+         faulty systems.  If the Internet is to converge successfully to
+         complete interoperability, the default values built into
+         implementations must implement the official protocol, not
+         "mis-configurations" to accommodate faulty implementations.
+         Although marketing considerations have led some vendors to
+         choose mis-configuration defaults, we urge vendors to choose
+         defaults that will conform to the standard.
+
+         Finally, we note that a vendor needs to provide adequate
+         documentation on all configuration parameters, their limits and
+         effects.
+
+
+   1.3  Reading this Document
+
+      1.3.1  Organization
+
+         Protocol layering, which is generally used as an organizing
+         principle in implementing network software, has also been used
+         to organize this document.  In describing the rules, we assume
+         that an implementation does strictly mirror the layering of the
+         protocols.  Thus, the following three major sections specify
+         the requirements for the link layer, the internet layer, and
+         the transport layer, respectively.  A companion RFC [INTRO:1]
+         covers application level software.  This layerist organization
+         was chosen for simplicity and clarity.
+
+         However, strict layering is an imperfect model, both for the
+         protocol suite and for recommended implementation approaches.
+         Protocols in different layers interact in complex and sometimes
+         subtle ways, and particular functions often involve multiple
+         layers.  There are many design choices in an implementation,
+         many of which involve creative "breaking" of strict layering.
+         Every implementor is urged to read references [INTRO:7] and
+         [INTRO:8].
+
+         This document describes the conceptual service interface
+         between layers using a functional ("procedure call") notation,
+         like that used in the TCP specification [TCP:1].  A host
+         implementation must support the logical information flow
+
+
+
+Internet Engineering Task Force                                [Page 15]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+         implied by these calls, but need not literally implement the
+         calls themselves.  For example, many implementations reflect
+         the coupling between the transport layer and the IP layer by
+         giving them shared access to common data structures.  These
+         data structures, rather than explicit procedure calls, are then
+         the agency for passing much of the information that is
+         required.
+
+         In general, each major section of this document is organized
+         into the following subsections:
+
+         (1)  Introduction
+
+         (2)  Protocol Walk-Through -- considers the protocol
+              specification documents section-by-section, correcting
+              errors, stating requirements that may be ambiguous or
+              ill-defined, and providing further clarification or
+              explanation.
+
+         (3)  Specific Issues -- discusses protocol design and
+              implementation issues that were not included in the walk-
+              through.
+
+         (4)  Interfaces -- discusses the service interface to the next
+              higher layer.
+
+         (5)  Summary -- contains a summary of the requirements of the
+              section.
+
+
+         Under many of the individual topics in this document, there is
+         parenthetical material labeled "DISCUSSION" or
+         "IMPLEMENTATION". This material is intended to give
+         clarification and explanation of the preceding requirements
+         text.  It also includes some suggestions on possible future
+         directions or developments.  The implementation material
+         contains suggested approaches that an implementor may want to
+         consider.
+
+         The summary sections are intended to be guides and indexes to
+         the text, but are necessarily cryptic and incomplete.  The
+         summaries should never be used or referenced separately from
+         the complete RFC.
+
+      1.3.2  Requirements
+
+         In this document, the words that are used to define the
+         significance of each particular requirement are capitalized.
+
+
+
+Internet Engineering Task Force                                [Page 16]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+         These words are:
+
+         *    "MUST"
+
+              This word or the adjective "REQUIRED" means that the item
+              is an absolute requirement of the specification.
+
+         *    "SHOULD"
+
+              This word or the adjective "RECOMMENDED" means that there
+              may exist valid reasons in particular circumstances to
+              ignore this item, but the full implications should be
+              understood and the case carefully weighed before choosing
+              a different course.
+
+         *    "MAY"
+
+              This word or the adjective "OPTIONAL" means that this item
+              is truly optional.  One vendor may choose to include the
+              item because a particular marketplace requires it or
+              because it enhances the product, for example; another
+              vendor may omit the same item.
+
+
+         An implementation is not compliant if it fails to satisfy one
+         or more of the MUST requirements for the protocols it
+         implements.  An implementation that satisfies all the MUST and
+         all the SHOULD requirements for its protocols is said to be
+         "unconditionally compliant"; one that satisfies all the MUST
+         requirements but not all the SHOULD requirements for its
+         protocols is said to be "conditionally compliant".
+
+      1.3.3  Terminology
+
+         This document uses the following technical terms:
+
+         Segment
+              A segment is the unit of end-to-end transmission in the
+              TCP protocol.  A segment consists of a TCP header followed
+              by application data.  A segment is transmitted by
+              encapsulation inside an IP datagram.
+
+         Message
+              In this description of the lower-layer protocols, a
+              message is the unit of transmission in a transport layer
+              protocol.  In particular, a TCP segment is a message.  A
+              message consists of a transport protocol header followed
+              by application protocol data.  To be transmitted end-to-
+
+
+
+Internet Engineering Task Force                                [Page 17]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+              end through the Internet, a message must be encapsulated
+              inside a datagram.
+
+         IP Datagram
+              An IP datagram is the unit of end-to-end transmission in
+              the IP protocol.  An IP datagram consists of an IP header
+              followed by transport layer data, i.e., of an IP header
+              followed by a message.
+
+              In the description of the internet layer (Section 3), the
+              unqualified term "datagram" should be understood to refer
+              to an IP datagram.
+
+         Packet
+              A packet is the unit of data passed across the interface
+              between the internet layer and the link layer.  It
+              includes an IP header and data.  A packet may be a
+              complete IP datagram or a fragment of an IP datagram.
+
+         Frame
+              A frame is the unit of transmission in a link layer
+              protocol, and consists of a link-layer header followed by
+              a packet.
+
+         Connected Network
+              A network to which a host is interfaced is often known as
+              the "local network" or the "subnetwork" relative to that
+              host.  However, these terms can cause confusion, and
+              therefore we use the term "connected network" in this
+              document.
+
+         Multihomed
+              A host is said to be multihomed if it has multiple IP
+              addresses.  For a discussion of multihoming, see Section
+              3.3.4 below.
+
+         Physical network interface
+              This is a physical interface to a connected network and
+              has a (possibly unique) link-layer address.  Multiple
+              physical network interfaces on a single host may share the
+              same link-layer address, but the address must be unique
+              for different hosts on the same physical network.
+
+         Logical [network] interface
+              We define a logical [network] interface to be a logical
+              path, distinguished by a unique IP address, to a connected
+              network.  See Section 3.3.4.
+
+
+
+
+Internet Engineering Task Force                                [Page 18]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+         Specific-destination address
+              This is the effective destination address of a datagram,
+              even if it is broadcast or multicast; see Section 3.2.1.3.
+
+         Path
+              At a given moment, all the IP datagrams from a particular
+              source host to a particular destination host will
+              typically traverse the same sequence of gateways.  We use
+              the term "path" for this sequence.  Note that a path is
+              uni-directional; it is not unusual to have different paths
+              in the two directions between a given host pair.
+
+         MTU
+              The maximum transmission unit, i.e., the size of the
+              largest packet that can be transmitted.
+
+
+         The terms frame, packet, datagram, message, and segment are
+         illustrated by the following schematic diagrams:
+
+         A. Transmission on connected network:
+           _______________________________________________
+          | LL hdr | IP hdr |         (data)              |
+          |________|________|_____________________________|
+
+           <---------- Frame ----------------------------->
+                    <----------Packet -------------------->
+
+
+         B. Before IP fragmentation or after IP reassembly:
+                    ______________________________________
+                   | IP hdr | transport| Application Data |
+                   |________|____hdr___|__________________|
+
+                    <--------  Datagram ------------------>
+                             <-------- Message ----------->
+           or, for TCP:
+                    ______________________________________
+                   | IP hdr |  TCP hdr | Application Data |
+                   |________|__________|__________________|
+
+                    <--------  Datagram ------------------>
+                             <-------- Segment ----------->
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 19]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+   1.4  Acknowledgments
+
+      This document incorporates contributions and comments from a large
+      group of Internet protocol experts, including representatives of
+      university and research labs, vendors, and government agencies.
+      It was assembled primarily by the Host Requirements Working Group
+      of the Internet Engineering Task Force (IETF).
+
+      The Editor would especially like to acknowledge the tireless
+      dedication of the following people, who attended many long
+      meetings and generated 3 million bytes of electronic mail over the
+      past 18 months in pursuit of this document: Philip Almquist, Dave
+      Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve
+      Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore),
+      John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG),
+      Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge
+      (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software).
+
+      In addition, the following people made major contributions to the
+      effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia
+      (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA),
+      Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL),
+      John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill
+      Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul
+      (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue
+      Technology), and Mike StJohns (DCA).  The following also made
+      significant contributions to particular areas: Eric Allman
+      (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic
+      (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn
+      (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann
+      (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun
+      Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen
+      (Toronto).
+
+      We are grateful to all, including any contributors who may have
+      been inadvertently omitted from this list.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 20]
+
+
+
+
+RFC1122                        LINK LAYER                   October 1989
+
+
+2. LINK LAYER
+
+   2.1  INTRODUCTION
+
+      All Internet systems, both hosts and gateways, have the same
+      requirements for link layer protocols.  These requirements are
+      given in Chapter 3 of "Requirements for Internet Gateways"
+      [INTRO:2], augmented with the material in this section.
+
+   2.2  PROTOCOL WALK-THROUGH
+
+      None.
+
+   2.3  SPECIFIC ISSUES
+
+      2.3.1  Trailer Protocol Negotiation
+
+         The trailer protocol [LINK:1] for link-layer encapsulation MAY
+         be used, but only when it has been verified that both systems
+         (host or gateway) involved in the link-layer communication
+         implement trailers.  If the system does not dynamically
+         negotiate use of the trailer protocol on a per-destination
+         basis, the default configuration MUST disable the protocol.
+
+         DISCUSSION:
+              The trailer protocol is a link-layer encapsulation
+              technique that rearranges the data contents of packets
+              sent on the physical network.  In some cases, trailers
+              improve the throughput of higher layer protocols by
+              reducing the amount of data copying within the operating
+              system.  Higher layer protocols are unaware of trailer
+              use, but both the sending and receiving host MUST
+              understand the protocol if it is used.
+
+              Improper use of trailers can result in very confusing
+              symptoms.  Only packets with specific size attributes are
+              encapsulated using trailers, and typically only a small
+              fraction of the packets being exchanged have these
+              attributes.  Thus, if a system using trailers exchanges
+              packets with a system that does not, some packets
+              disappear into a black hole while others are delivered
+              successfully.
+
+         IMPLEMENTATION:
+              On an Ethernet, packets encapsulated with trailers use a
+              distinct Ethernet type [LINK:1], and trailer negotiation
+              is performed at the time that ARP is used to discover the
+              link-layer address of a destination system.
+
+
+
+Internet Engineering Task Force                                [Page 21]
+
+
+
+
+RFC1122                        LINK LAYER                   October 1989
+
+
+              Specifically, the ARP exchange is completed in the usual
+              manner using the normal IP protocol type, but a host that
+              wants to speak trailers will send an additional "trailer
+              ARP reply" packet, i.e., an ARP reply that specifies the
+              trailer encapsulation protocol type but otherwise has the
+              format of a normal ARP reply.  If a host configured to use
+              trailers receives a trailer ARP reply message from a
+              remote machine, it can add that machine to the list of
+              machines that understand trailers, e.g., by marking the
+              corresponding entry in the ARP cache.
+
+              Hosts wishing to receive trailer encapsulations send
+              trailer ARP replies whenever they complete exchanges of
+              normal ARP messages for IP.  Thus, a host that received an
+              ARP request for its IP protocol address would send a
+              trailer ARP reply in addition to the normal IP ARP reply;
+              a host that sent the IP ARP request would send a trailer
+              ARP reply when it received the corresponding IP ARP reply.
+              In this way, either the requesting or responding host in
+              an IP ARP exchange may request that it receive trailer
+              encapsulations.
+
+              This scheme, using extra trailer ARP reply packets rather
+              than sending an ARP request for the trailer protocol type,
+              was designed to avoid a continuous exchange of ARP packets
+              with a misbehaving host that, contrary to any
+              specification or common sense, responded to an ARP reply
+              for trailers with another ARP reply for IP.  This problem
+              is avoided by sending a trailer ARP reply in response to
+              an IP ARP reply only when the IP ARP reply answers an
+              outstanding request; this is true when the hardware
+              address for the host is still unknown when the IP ARP
+              reply is received.  A trailer ARP reply may always be sent
+              along with an IP ARP reply responding to an IP ARP
+              request.
+
+      2.3.2  Address Resolution Protocol -- ARP
+
+         2.3.2.1  ARP Cache Validation
+
+            An implementation of the Address Resolution Protocol (ARP)
+            [LINK:2] MUST provide a mechanism to flush out-of-date cache
+            entries.  If this mechanism involves a timeout, it SHOULD be
+            possible to configure the timeout value.
+
+            A mechanism to prevent ARP flooding (repeatedly sending an
+            ARP Request for the same IP address, at a high rate) MUST be
+            included.  The recommended maximum rate is 1 per second per
+
+
+
+Internet Engineering Task Force                                [Page 22]
+
+
+
+
+RFC1122                        LINK LAYER                   October 1989
+
+
+            destination.
+
+            DISCUSSION:
+                 The ARP specification [LINK:2] suggests but does not
+                 require a timeout mechanism to invalidate cache entries
+                 when hosts change their Ethernet addresses.  The
+                 prevalence of proxy ARP (see Section 2.4 of [INTRO:2])
+                 has significantly increased the likelihood that cache
+                 entries in hosts will become invalid, and therefore
+                 some ARP-cache invalidation mechanism is now required
+                 for hosts.  Even in the absence of proxy ARP, a long-
+                 period cache timeout is useful in order to
+                 automatically correct any bad ARP data that might have
+                 been cached.
+
+            IMPLEMENTATION:
+                 Four mechanisms have been used, sometimes in
+                 combination, to flush out-of-date cache entries.
+
+                 (1)  Timeout -- Periodically time out cache entries,
+                      even if they are in use.  Note that this timeout
+                      should be restarted when the cache entry is
+                      "refreshed" (by observing the source fields,
+                      regardless of target address, of an ARP broadcast
+                      from the system in question).  For proxy ARP
+                      situations, the timeout needs to be on the order
+                      of a minute.
+
+                 (2)  Unicast Poll -- Actively poll the remote host by
+                      periodically sending a point-to-point ARP Request
+                      to it, and delete the entry if no ARP Reply is
+                      received from N successive polls.  Again, the
+                      timeout should be on the order of a minute, and
+                      typically N is 2.
+
+                 (3)  Link-Layer Advice -- If the link-layer driver
+                      detects a delivery problem, flush the
+                      corresponding ARP cache entry.
+
+                 (4)  Higher-layer Advice -- Provide a call from the
+                      Internet layer to the link layer to indicate a
+                      delivery problem.  The effect of this call would
+                      be to invalidate the corresponding cache entry.
+                      This call would be analogous to the
+                      "ADVISE_DELIVPROB()" call from the transport layer
+                      to the Internet layer (see Section 3.4), and in
+                      fact the ADVISE_DELIVPROB routine might in turn
+                      call the link-layer advice routine to invalidate
+
+
+
+Internet Engineering Task Force                                [Page 23]
+
+
+
+
+RFC1122                        LINK LAYER                   October 1989
+
+
+                      the ARP cache entry.
+
+                 Approaches (1) and (2) involve ARP cache timeouts on
+                 the order of a minute or less.  In the absence of proxy
+                 ARP, a timeout this short could create noticeable
+                 overhead traffic on a very large Ethernet.  Therefore,
+                 it may be necessary to configure a host to lengthen the
+                 ARP cache timeout.
+
+         2.3.2.2  ARP Packet Queue
+
+            The link layer SHOULD save (rather than discard) at least
+            one (the latest) packet of each set of packets destined to
+            the same unresolved IP address, and transmit the saved
+            packet when the address has been resolved.
+
+            DISCUSSION:
+                 Failure to follow this recommendation causes the first
+                 packet of every exchange to be lost.  Although higher-
+                 layer protocols can generally cope with packet loss by
+                 retransmission, packet loss does impact performance.
+                 For example, loss of a TCP open request causes the
+                 initial round-trip time estimate to be inflated.  UDP-
+                 based applications such as the Domain Name System are
+                 more seriously affected.
+
+      2.3.3  Ethernet and IEEE 802 Encapsulation
+
+         The IP encapsulation for Ethernets is described in RFC-894
+         [LINK:3], while RFC-1042 [LINK:4] describes the IP
+         encapsulation for IEEE 802 networks.  RFC-1042 elaborates and
+         replaces the discussion in Section 3.4 of [INTRO:2].
+
+         Every Internet host connected to a 10Mbps Ethernet cable:
+
+         o    MUST be able to send and receive packets using RFC-894
+              encapsulation;
+
+         o    SHOULD be able to receive RFC-1042 packets, intermixed
+              with RFC-894 packets; and
+
+         o    MAY be able to send packets using RFC-1042 encapsulation.
+
+
+         An Internet host that implements sending both the RFC-894 and
+         the RFC-1042 encapsulations MUST provide a configuration switch
+         to select which is sent, and this switch MUST default to RFC-
+         894.
+
+
+
+Internet Engineering Task Force                                [Page 24]
+
+
+
+
+RFC1122                        LINK LAYER                   October 1989
+
+
+         Note that the standard IP encapsulation in RFC-1042 does not
+         use the protocol id value (K1=6) that IEEE reserved for IP;
+         instead, it uses a value (K1=170) that implies an extension
+         (the "SNAP") which can be used to hold the Ether-Type field.
+         An Internet system MUST NOT send 802 packets using K1=6.
+
+         Address translation from Internet addresses to link-layer
+         addresses on Ethernet and IEEE 802 networks MUST be managed by
+         the Address Resolution Protocol (ARP).
+
+         The MTU for an Ethernet is 1500 and for 802.3 is 1492.
+
+         DISCUSSION:
+              The IEEE 802.3 specification provides for operation over a
+              10Mbps Ethernet cable, in which case Ethernet and IEEE
+              802.3 frames can be physically intermixed.  A receiver can
+              distinguish Ethernet and 802.3 frames by the value of the
+              802.3 Length field; this two-octet field coincides in the
+              header with the Ether-Type field of an Ethernet frame.  In
+              particular, the 802.3 Length field must be less than or
+              equal to 1500, while all valid Ether-Type values are
+              greater than 1500.
+
+              Another compatibility problem arises with link-layer
+              broadcasts.  A broadcast sent with one framing will not be
+              seen by hosts that can receive only the other framing.
+
+              The provisions of this section were designed to provide
+              direct interoperation between 894-capable and 1042-capable
+              systems on the same cable, to the maximum extent possible.
+              It is intended to support the present situation where
+              894-only systems predominate, while providing an easy
+              transition to a possible future in which 1042-capable
+              systems become common.
+
+              Note that 894-only systems cannot interoperate directly
+              with 1042-only systems.  If the two system types are set
+              up as two different logical networks on the same cable,
+              they can communicate only through an IP gateway.
+              Furthermore, it is not useful or even possible for a
+              dual-format host to discover automatically which format to
+              send, because of the problem of link-layer broadcasts.
+
+   2.4  LINK/INTERNET LAYER INTERFACE
+
+      The packet receive interface between the IP layer and the link
+      layer MUST include a flag to indicate whether the incoming packet
+      was addressed to a link-layer broadcast address.
+
+
+
+Internet Engineering Task Force                                [Page 25]
+
+
+
+
+RFC1122                        LINK LAYER                   October 1989
+
+
+      DISCUSSION
+           Although the IP layer does not generally know link layer
+           addresses (since every different network medium typically has
+           a different address format), the broadcast address on a
+           broadcast-capable medium is an important special case.  See
+           Section 3.2.2, especially the DISCUSSION concerning broadcast
+           storms.
+
+      The packet send interface between the IP and link layers MUST
+      include the 5-bit TOS field (see Section 3.2.1.6).
+
+      The link layer MUST NOT report a Destination Unreachable error to
+      IP solely because there is no ARP cache entry for a destination.
+
+   2.5  LINK LAYER REQUIREMENTS SUMMARY
+
+                                                  |       | | | |S| |
+                                                  |       | | | |H| |F
+                                                  |       | | | |O|M|o
+                                                  |       | |S| |U|U|o
+                                                  |       | |H| |L|S|t
+                                                  |       |M|O| |D|T|n
+                                                  |       |U|U|M| | |o
+                                                  |       |S|L|A|N|N|t
+                                                  |       |T|D|Y|O|O|t
+FEATURE                                           |SECTION| | | |T|T|e
+--------------------------------------------------|-------|-|-|-|-|-|--
+                                                  |       | | | | | |
+Trailer encapsulation                             |2.3.1  | | |x| | |
+Send Trailers by default without negotiation      |2.3.1  | | | | |x|
+ARP                                               |2.3.2  | | | | | |
+  Flush out-of-date ARP cache entries             |2.3.2.1|x| | | | |
+  Prevent ARP floods                              |2.3.2.1|x| | | | |
+  Cache timeout configurable                      |2.3.2.1| |x| | | |
+  Save at least one (latest) unresolved pkt       |2.3.2.2| |x| | | |
+Ethernet and IEEE 802 Encapsulation               |2.3.3  | | | | | |
+  Host able to:                                   |2.3.3  | | | | | |
+    Send & receive RFC-894 encapsulation          |2.3.3  |x| | | | |
+    Receive RFC-1042 encapsulation                |2.3.3  | |x| | | |
+    Send RFC-1042 encapsulation                   |2.3.3  | | |x| | |
+      Then config. sw. to select, RFC-894 dflt    |2.3.3  |x| | | | |
+  Send K1=6 encapsulation                         |2.3.3  | | | | |x|
+  Use ARP on Ethernet and IEEE 802 nets           |2.3.3  |x| | | | |
+Link layer report b'casts to IP layer             |2.4    |x| | | | |
+IP layer pass TOS to link layer                   |2.4    |x| | | | |
+No ARP cache entry treated as Dest. Unreach.      |2.4    | | | | |x|
+
+
+
+
+
+Internet Engineering Task Force                                [Page 26]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+3. INTERNET LAYER PROTOCOLS
+
+   3.1 INTRODUCTION
+
+      The Robustness Principle: "Be liberal in what you accept, and
+      conservative in what you send" is particularly important in the
+      Internet layer, where one misbehaving host can deny Internet
+      service to many other hosts.
+
+      The protocol standards used in the Internet layer are:
+
+      o    RFC-791 [IP:1] defines the IP protocol and gives an
+           introduction to the architecture of the Internet.
+
+      o    RFC-792 [IP:2] defines ICMP, which provides routing,
+           diagnostic and error functionality for IP.  Although ICMP
+           messages are encapsulated within IP datagrams, ICMP
+           processing is considered to be (and is typically implemented
+           as) part of the IP layer.  See Section 3.2.2.
+
+      o    RFC-950 [IP:3] defines the mandatory subnet extension to the
+           addressing architecture.
+
+      o    RFC-1112 [IP:4] defines the Internet Group Management
+           Protocol IGMP, as part of a recommended extension to hosts
+           and to the host-gateway interface to support Internet-wide
+           multicasting at the IP level.  See Section 3.2.3.
+
+           The target of an IP multicast may be an arbitrary group of
+           Internet hosts.  IP multicasting is designed as a natural
+           extension of the link-layer multicasting facilities of some
+           networks, and it provides a standard means for local access
+           to such link-layer multicasting facilities.
+
+      Other important references are listed in Section 5 of this
+      document.
+
+      The Internet layer of host software MUST implement both IP and
+      ICMP.  See Section 3.3.7 for the requirements on support of IGMP.
+
+      The host IP layer has two basic functions:  (1) choose the "next
+      hop" gateway or host for outgoing IP datagrams and (2) reassemble
+      incoming IP datagrams.  The IP layer may also (3) implement
+      intentional fragmentation of outgoing datagrams.  Finally, the IP
+      layer must (4) provide diagnostic and error functionality.  We
+      expect that IP layer functions may increase somewhat in the
+      future, as further Internet control and management facilities are
+      developed.
+
+
+
+Internet Engineering Task Force                                [Page 27]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+      For normal datagrams, the processing is straightforward.  For
+      incoming datagrams, the IP layer:
+
+      (1)  verifies that the datagram is correctly formatted;
+
+      (2)  verifies that it is destined to the local host;
+
+      (3)  processes options;
+
+      (4)  reassembles the datagram if necessary; and
+
+      (5)  passes the encapsulated message to the appropriate
+           transport-layer protocol module.
+
+      For outgoing datagrams, the IP layer:
+
+      (1)  sets any fields not set by the transport layer;
+
+      (2)  selects the correct first hop on the connected network (a
+           process called "routing");
+
+      (3)  fragments the datagram if necessary and if intentional
+           fragmentation is implemented (see Section 3.3.3); and
+
+      (4)  passes the packet(s) to the appropriate link-layer driver.
+
+
+      A host is said to be multihomed if it has multiple IP addresses.
+      Multihoming introduces considerable confusion and complexity into
+      the protocol suite, and it is an area in which the Internet
+      architecture falls seriously short of solving all problems.  There
+      are two distinct problem areas in multihoming:
+
+      (1)  Local multihoming --  the host itself is multihomed; or
+
+      (2)  Remote multihoming -- the local host needs to communicate
+           with a remote multihomed host.
+
+      At present, remote multihoming MUST be handled at the application
+      layer, as discussed in the companion RFC [INTRO:1].  A host MAY
+      support local multihoming, which is discussed in this document,
+      and in particular in Section 3.3.4.
+
+      Any host that forwards datagrams generated by another host is
+      acting as a gateway and MUST also meet the specifications laid out
+      in the gateway requirements RFC [INTRO:2].  An Internet host that
+      includes embedded gateway code MUST have a configuration switch to
+      disable the gateway function, and this switch MUST default to the
+
+
+
+Internet Engineering Task Force                                [Page 28]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+      non-gateway mode.  In this mode, a datagram arriving through one
+      interface will not be forwarded to another host or gateway (unless
+      it is source-routed), regardless of whether the host is single-
+      homed or multihomed.  The host software MUST NOT automatically
+      move into gateway mode if the host has more than one interface, as
+      the operator of the machine may neither want to provide that
+      service nor be competent to do so.
+
+      In the following, the action specified in certain cases is to
+      "silently discard" a received datagram.  This means that the
+      datagram will be discarded without further processing and that the
+      host will not send any ICMP error message (see Section 3.2.2) as a
+      result.  However, for diagnosis of problems a host SHOULD provide
+      the capability of logging the error (see Section 1.2.3), including
+      the contents of the silently-discarded datagram, and SHOULD record
+      the event in a statistics counter.
+
+      DISCUSSION:
+           Silent discard of erroneous datagrams is generally intended
+           to prevent "broadcast storms".
+
+   3.2  PROTOCOL WALK-THROUGH
+
+      3.2.1 Internet Protocol -- IP
+
+         3.2.1.1  Version Number: RFC-791 Section 3.1
+
+            A datagram whose version number is not 4 MUST be silently
+            discarded.
+
+         3.2.1.2  Checksum: RFC-791 Section 3.1
+
+            A host MUST verify the IP header checksum on every received
+            datagram and silently discard every datagram that has a bad
+            checksum.
+
+         3.2.1.3  Addressing: RFC-791 Section 3.2
+
+            There are now five classes of IP addresses: Class A through
+            Class E.  Class D addresses are used for IP multicasting
+            [IP:4], while Class E addresses are reserved for
+            experimental use.
+
+            A multicast (Class D) address is a 28-bit logical address
+            that stands for a group of hosts, and may be either
+            permanent or transient.  Permanent multicast addresses are
+            allocated by the Internet Assigned Number Authority
+            [INTRO:6], while transient addresses may be allocated
+
+
+
+Internet Engineering Task Force                                [Page 29]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            dynamically to transient groups.  Group membership is
+            determined dynamically using IGMP [IP:4].
+
+            We now summarize the important special cases for Class A, B,
+            and C IP addresses, using the following notation for an IP
+            address:
+
+                { <Network-number>, <Host-number> }
+
+            or
+                { <Network-number>, <Subnet-number>, <Host-number> }
+
+            and the notation "-1" for a field that contains all 1 bits.
+            This notation is not intended to imply that the 1-bits in an
+            address mask need be contiguous.
+
+            (a)  { 0, 0 }
+
+                 This host on this network.  MUST NOT be sent, except as
+                 a source address as part of an initialization procedure
+                 by which the host learns its own IP address.
+
+                 See also Section 3.3.6 for a non-standard use of {0,0}.
+
+            (b)  { 0, <Host-number> }
+
+                 Specified host on this network.  It MUST NOT be sent,
+                 except as a source address as part of an initialization
+                 procedure by which the host learns its full IP address.
+
+            (c)  { -1, -1 }
+
+                 Limited broadcast.  It MUST NOT be used as a source
+                 address.
+
+                 A datagram with this destination address will be
+                 received by every host on the connected physical
+                 network but will not be forwarded outside that network.
+
+            (d)  { <Network-number>, -1 }
+
+                 Directed broadcast to the specified network.  It MUST
+                 NOT be used as a source address.
+
+            (e)  { <Network-number>, <Subnet-number>, -1 }
+
+                 Directed broadcast to the specified subnet.  It MUST
+                 NOT be used as a source address.
+
+
+
+Internet Engineering Task Force                                [Page 30]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            (f)  { <Network-number>, -1, -1 }
+
+                 Directed broadcast to all subnets of the specified
+                 subnetted network.  It MUST NOT be used as a source
+                 address.
+
+            (g)  { 127, <any> }
+
+                 Internal host loopback address.  Addresses of this form
+                 MUST NOT appear outside a host.
+
+            The <Network-number> is administratively assigned so that
+            its value will be unique in the entire world.
+
+            IP addresses are not permitted to have the value 0 or -1 for
+            any of the <Host-number>, <Network-number>, or <Subnet-
+            number> fields (except in the special cases listed above).
+            This implies that each of these fields will be at least two
+            bits long.
+
+            For further discussion of broadcast addresses, see Section
+            3.3.6.
+
+            A host MUST support the subnet extensions to IP [IP:3].  As
+            a result, there will be an address mask of the form:
+            {-1, -1, 0} associated with each of the host's local IP
+            addresses; see Sections 3.2.2.9 and 3.3.1.1.
+
+            When a host sends any datagram, the IP source address MUST
+            be one of its own IP addresses (but not a broadcast or
+            multicast address).
+
+            A host MUST silently discard an incoming datagram that is
+            not destined for the host.  An incoming datagram is destined
+            for the host if the datagram's destination address field is:
+
+            (1)  (one of) the host's IP address(es); or
+
+            (2)  an IP broadcast address valid for the connected
+                 network; or
+
+            (3)  the address for a multicast group of which the host is
+                 a member on the incoming physical interface.
+
+            For most purposes, a datagram addressed to a broadcast or
+            multicast destination is processed as if it had been
+            addressed to one of the host's IP addresses; we use the term
+            "specific-destination address" for the equivalent local IP
+
+
+
+Internet Engineering Task Force                                [Page 31]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            address of the host.  The specific-destination address is
+            defined to be the destination address in the IP header
+            unless the header contains a broadcast or multicast address,
+            in which case the specific-destination is an IP address
+            assigned to the physical interface on which the datagram
+            arrived.
+
+            A host MUST silently discard an incoming datagram containing
+            an IP source address that is invalid by the rules of this
+            section.  This validation could be done in either the IP
+            layer or by each protocol in the transport layer.
+
+            DISCUSSION:
+                 A mis-addressed datagram might be caused by a link-
+                 layer broadcast of a unicast datagram or by a gateway
+                 or host that is confused or mis-configured.
+
+                 An architectural goal for Internet hosts was to allow
+                 IP addresses to be featureless 32-bit numbers, avoiding
+                 algorithms that required a knowledge of the IP address
+                 format.  Otherwise, any future change in the format or
+                 interpretation of IP addresses will require host
+                 software changes.  However, validation of broadcast and
+                 multicast addresses violates this goal; a few other
+                 violations are described elsewhere in this document.
+
+                 Implementers should be aware that applications
+                 depending upon the all-subnets directed broadcast
+                 address (f) may be unusable on some networks.  All-
+                 subnets broadcast is not widely implemented in vendor
+                 gateways at present, and even when it is implemented, a
+                 particular network administration may disable it in the
+                 gateway configuration.
+
+         3.2.1.4  Fragmentation and Reassembly: RFC-791 Section 3.2
+
+            The Internet model requires that every host support
+            reassembly.  See Sections 3.3.2 and 3.3.3 for the
+            requirements on fragmentation and reassembly.
+
+         3.2.1.5  Identification: RFC-791 Section 3.2
+
+            When sending an identical copy of an earlier datagram, a
+            host MAY optionally retain the same Identification field in
+            the copy.
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 32]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            DISCUSSION:
+                 Some Internet protocol experts have maintained that
+                 when a host sends an identical copy of an earlier
+                 datagram, the new copy should contain the same
+                 Identification value as the original.  There are two
+                 suggested advantages:  (1) if the datagrams are
+                 fragmented and some of the fragments are lost, the
+                 receiver may be able to reconstruct a complete datagram
+                 from fragments of the original and the copies; (2) a
+                 congested gateway might use the IP Identification field
+                 (and Fragment Offset) to discard duplicate datagrams
+                 from the queue.
+
+                 However, the observed patterns of datagram loss in the
+                 Internet do not favor the probability of retransmitted
+                 fragments filling reassembly gaps, while other
+                 mechanisms (e.g., TCP repacketizing upon
+                 retransmission) tend to prevent retransmission of an
+                 identical datagram [IP:9].  Therefore, we believe that
+                 retransmitting the same Identification field is not
+                 useful.  Also, a connectionless transport protocol like
+                 UDP would require the cooperation of the application
+                 programs to retain the same Identification value in
+                 identical datagrams.
+
+         3.2.1.6  Type-of-Service: RFC-791 Section 3.2
+
+            The "Type-of-Service" byte in the IP header is divided into
+            two sections:  the Precedence field (high-order 3 bits), and
+            a field that is customarily called "Type-of-Service" or
+            "TOS" (low-order 5 bits).  In this document, all references
+            to "TOS" or the "TOS field" refer to the low-order 5 bits
+            only.
+
+            The Precedence field is intended for Department of Defense
+            applications of the Internet protocols.  The use of non-zero
+            values in this field is outside the scope of this document
+            and the IP standard specification.  Vendors should consult
+            the Defense Communication Agency (DCA) for guidance on the
+            IP Precedence field and its implications for other protocol
+            layers.  However, vendors should note that the use of
+            precedence will most likely require that its value be passed
+            between protocol layers in just the same way as the TOS
+            field is passed.
+
+            The IP layer MUST provide a means for the transport layer to
+            set the TOS field of every datagram that is sent; the
+            default is all zero bits.  The IP layer SHOULD pass received
+
+
+
+Internet Engineering Task Force                                [Page 33]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            TOS values up to the transport layer.
+
+            The particular link-layer mappings of TOS contained in RFC-
+            795 SHOULD NOT be implemented.
+
+            DISCUSSION:
+                 While the TOS field has been little used in the past,
+                 it is expected to play an increasing role in the near
+                 future.  The TOS field is expected to be used to
+                 control two aspects of gateway operations: routing and
+                 queueing algorithms.  See Section 2 of [INTRO:1] for
+                 the requirements on application programs to specify TOS
+                 values.
+
+                 The TOS field may also be mapped into link-layer
+                 service selectors.  This has been applied to provide
+                 effective sharing of serial lines by different classes
+                 of TCP traffic, for example.  However, the mappings
+                 suggested in RFC-795 for networks that were included in
+                 the Internet as of 1981 are now obsolete.
+
+         3.2.1.7  Time-to-Live: RFC-791 Section 3.2
+
+            A host MUST NOT send a datagram with a Time-to-Live (TTL)
+            value of zero.
+
+            A host MUST NOT discard a datagram just because it was
+            received with TTL less than 2.
+
+            The IP layer MUST provide a means for the transport layer to
+            set the TTL field of every datagram that is sent.  When a
+            fixed TTL value is used, it MUST be configurable.  The
+            current suggested value will be published in the "Assigned
+            Numbers" RFC.
+
+            DISCUSSION:
+                 The TTL field has two functions: limit the lifetime of
+                 TCP segments (see RFC-793 [TCP:1], p. 28), and
+                 terminate Internet routing loops.  Although TTL is a
+                 time in seconds, it also has some attributes of a hop-
+                 count, since each gateway is required to reduce the TTL
+                 field by at least one.
+
+                 The intent is that TTL expiration will cause a datagram
+                 to be discarded by a gateway but not by the destination
+                 host; however, hosts that act as gateways by forwarding
+                 datagrams must follow the gateway rules for TTL.
+
+
+
+
+Internet Engineering Task Force                                [Page 34]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 A higher-layer protocol may want to set the TTL in
+                 order to implement an "expanding scope" search for some
+                 Internet resource.  This is used by some diagnostic
+                 tools, and is expected to be useful for locating the
+                 "nearest" server of a given class using IP
+                 multicasting, for example.  A particular transport
+                 protocol may also want to specify its own TTL bound on
+                 maximum datagram lifetime.
+
+                 A fixed value must be at least big enough for the
+                 Internet "diameter," i.e., the longest possible path.
+                 A reasonable value is about twice the diameter, to
+                 allow for continued Internet growth.
+
+         3.2.1.8  Options: RFC-791 Section 3.2
+
+            There MUST be a means for the transport layer to specify IP
+            options to be included in transmitted IP datagrams (see
+            Section 3.4).
+
+            All IP options (except NOP or END-OF-LIST) received in
+            datagrams MUST be passed to the transport layer (or to ICMP
+            processing when the datagram is an ICMP message).  The IP
+            and transport layer MUST each interpret those IP options
+            that they understand and silently ignore the others.
+
+            Later sections of this document discuss specific IP option
+            support required by each of ICMP, TCP, and UDP.
+
+            DISCUSSION:
+                 Passing all received IP options to the transport layer
+                 is a deliberate "violation of strict layering" that is
+                 designed to ease the introduction of new transport-
+                 relevant IP options in the future.  Each layer must
+                 pick out any options that are relevant to its own
+                 processing and ignore the rest.  For this purpose,
+                 every IP option except NOP and END-OF-LIST will include
+                 a specification of its own length.
+
+                 This document does not define the order in which a
+                 receiver must process multiple options in the same IP
+                 header.  Hosts sending multiple options must be aware
+                 that this introduces an ambiguity in the meaning of
+                 certain options when combined with a source-route
+                 option.
+
+            IMPLEMENTATION:
+                 The IP layer must not crash as the result of an option
+
+
+
+Internet Engineering Task Force                                [Page 35]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 length that is outside the possible range.  For
+                 example, erroneous option lengths have been observed to
+                 put some IP implementations into infinite loops.
+
+            Here are the requirements for specific IP options:
+
+
+            (a)  Security Option
+
+                 Some environments require the Security option in every
+                 datagram; such a requirement is outside the scope of
+                 this document and the IP standard specification.  Note,
+                 however, that the security options described in RFC-791
+                 and RFC-1038 are obsolete.  For DoD applications,
+                 vendors should consult [IP:8] for guidance.
+
+
+            (b)  Stream Identifier Option
+
+                 This option is obsolete; it SHOULD NOT be sent, and it
+                 MUST be silently ignored if received.
+
+
+            (c)  Source Route Options
+
+                 A host MUST support originating a source route and MUST
+                 be able to act as the final destination of a source
+                 route.
+
+                 If host receives a datagram containing a completed
+                 source route (i.e., the pointer points beyond the last
+                 field), the datagram has reached its final destination;
+                 the option as received (the recorded route) MUST be
+                 passed up to the transport layer (or to ICMP message
+                 processing).  This recorded route will be reversed and
+                 used to form a return source route for reply datagrams
+                 (see discussion of IP Options in Section 4).  When a
+                 return source route is built, it MUST be correctly
+                 formed even if the recorded route included the source
+                 host (see case (B) in the discussion below).
+
+                 An IP header containing more than one Source Route
+                 option MUST NOT be sent; the effect on routing of
+                 multiple Source Route options is implementation-
+                 specific.
+
+                 Section 3.3.5 presents the rules for a host acting as
+                 an intermediate hop in a source route, i.e., forwarding
+
+
+
+Internet Engineering Task Force                                [Page 36]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 a source-routed datagram.
+
+                 DISCUSSION:
+                      If a source-routed datagram is fragmented, each
+                      fragment will contain a copy of the source route.
+                      Since the processing of IP options (including a
+                      source route) must precede reassembly, the
+                      original datagram will not be reassembled until
+                      the final destination is reached.
+
+                      Suppose a source routed datagram is to be routed
+                      from host S to host D via gateways G1, G2, ... Gn.
+                      There was an ambiguity in the specification over
+                      whether the source route option in a datagram sent
+                      out by S should be (A) or (B):
+
+                          (A):  {>>G2, G3, ... Gn, D}     <--- CORRECT
+
+                          (B):  {S, >>G2, G3, ... Gn, D}  <---- WRONG
+
+                      (where >> represents the pointer).  If (A) is
+                      sent, the datagram received at D will contain the
+                      option: {G1, G2, ... Gn >>}, with S and D as the
+                      IP source and destination addresses.  If (B) were
+                      sent, the datagram received at D would again
+                      contain S and D as the same IP source and
+                      destination addresses, but the option would be:
+                      {S, G1, ...Gn >>}; i.e., the originating host
+                      would be the first hop in the route.
+
+
+            (d)  Record Route Option
+
+                 Implementation of originating and processing the Record
+                 Route option is OPTIONAL.
+
+
+            (e)  Timestamp Option
+
+                 Implementation of originating and processing the
+                 Timestamp option is OPTIONAL.  If it is implemented,
+                 the following rules apply:
+
+                 o    The originating host MUST record a timestamp in a
+                      Timestamp option whose Internet address fields are
+                      not pre-specified or whose first pre-specified
+                      address is the host's interface address.
+
+
+
+
+Internet Engineering Task Force                                [Page 37]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 o    The destination host MUST (if possible) add the
+                      current timestamp to a Timestamp option before
+                      passing the option to the transport layer or to
+                      ICMP for processing.
+
+                 o    A timestamp value MUST follow the rules given in
+                      Section 3.2.2.8 for the ICMP Timestamp message.
+
+
+      3.2.2 Internet Control Message Protocol -- ICMP
+
+         ICMP messages are grouped into two classes.
+
+         *
+              ICMP error messages:
+
+               Destination Unreachable   (see Section 3.2.2.1)
+               Redirect                  (see Section 3.2.2.2)
+               Source Quench             (see Section 3.2.2.3)
+               Time Exceeded             (see Section 3.2.2.4)
+               Parameter Problem         (see Section 3.2.2.5)
+
+
+         *
+              ICMP query messages:
+
+                Echo                     (see Section 3.2.2.6)
+                Information              (see Section 3.2.2.7)
+                Timestamp                (see Section 3.2.2.8)
+                Address Mask             (see Section 3.2.2.9)
+
+
+         If an ICMP message of unknown type is received, it MUST be
+         silently discarded.
+
+         Every ICMP error message includes the Internet header and at
+         least the first 8 data octets of the datagram that triggered
+         the error; more than 8 octets MAY be sent; this header and data
+         MUST be unchanged from the received datagram.
+
+         In those cases where the Internet layer is required to pass an
+         ICMP error message to the transport layer, the IP protocol
+         number MUST be extracted from the original header and used to
+         select the appropriate transport protocol entity to handle the
+         error.
+
+         An ICMP error message SHOULD be sent with normal (i.e., zero)
+         TOS bits.
+
+
+
+Internet Engineering Task Force                                [Page 38]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+         An ICMP error message MUST NOT be sent as the result of
+         receiving:
+
+         *    an ICMP error message, or
+
+         *    a datagram destined to an IP broadcast or IP multicast
+              address, or
+
+         *    a datagram sent as a link-layer broadcast, or
+
+         *    a non-initial fragment, or
+
+         *    a datagram whose source address does not define a single
+              host -- e.g., a zero address, a loopback address, a
+              broadcast address, a multicast address, or a Class E
+              address.
+
+         NOTE: THESE RESTRICTIONS TAKE PRECEDENCE OVER ANY REQUIREMENT
+         ELSEWHERE IN THIS DOCUMENT FOR SENDING ICMP ERROR MESSAGES.
+
+         DISCUSSION:
+              These rules will prevent the "broadcast storms" that have
+              resulted from hosts returning ICMP error messages in
+              response to broadcast datagrams.  For example, a broadcast
+              UDP segment to a non-existent port could trigger a flood
+              of ICMP Destination Unreachable datagrams from all
+              machines that do not have a client for that destination
+              port.  On a large Ethernet, the resulting collisions can
+              render the network useless for a second or more.
+
+              Every datagram that is broadcast on the connected network
+              should have a valid IP broadcast address as its IP
+              destination (see Section 3.3.6).  However, some hosts
+              violate this rule.  To be certain to detect broadcast
+              datagrams, therefore, hosts are required to check for a
+              link-layer broadcast as well as an IP-layer broadcast
+              address.
+
+         IMPLEMENTATION:
+              This requires that the link layer inform the IP layer when
+              a link-layer broadcast datagram has been received; see
+              Section 2.4.
+
+         3.2.2.1  Destination Unreachable: RFC-792
+
+            The following additional codes are hereby defined:
+
+                    6 = destination network unknown
+
+
+
+Internet Engineering Task Force                                [Page 39]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                    7 = destination host unknown
+
+                    8 = source host isolated
+
+                    9 = communication with destination network
+                            administratively prohibited
+
+                   10 = communication with destination host
+                            administratively prohibited
+
+                   11 = network unreachable for type of service
+
+                   12 = host unreachable for type of service
+
+            A host SHOULD generate Destination Unreachable messages with
+            code:
+
+            2    (Protocol Unreachable), when the designated transport
+                 protocol is not supported; or
+
+            3    (Port Unreachable), when the designated transport
+                 protocol (e.g., UDP) is unable to demultiplex the
+                 datagram but has no protocol mechanism to inform the
+                 sender.
+
+            A Destination Unreachable message that is received MUST be
+            reported to the transport layer.  The transport layer SHOULD
+            use the information appropriately; for example, see Sections
+            4.1.3.3, 4.2.3.9, and 4.2.4 below.  A transport protocol
+            that has its own mechanism for notifying the sender that a
+            port is unreachable (e.g., TCP, which sends RST segments)
+            MUST nevertheless accept an ICMP Port Unreachable for the
+            same purpose.
+
+            A Destination Unreachable message that is received with code
+            0 (Net), 1 (Host), or 5 (Bad Source Route) may result from a
+            routing transient and MUST therefore be interpreted as only
+            a hint, not proof, that the specified destination is
+            unreachable [IP:11].  For example, it MUST NOT be used as
+            proof of a dead gateway (see Section 3.3.1).
+
+         3.2.2.2  Redirect: RFC-792
+
+            A host SHOULD NOT send an ICMP Redirect message; Redirects
+            are to be sent only by gateways.
+
+            A host receiving a Redirect message MUST update its routing
+            information accordingly.  Every host MUST be prepared to
+
+
+
+Internet Engineering Task Force                                [Page 40]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            accept both Host and Network Redirects and to process them
+            as described in Section 3.3.1.2 below.
+
+            A Redirect message SHOULD be silently discarded if the new
+            gateway address it specifies is not on the same connected
+            (sub-) net through which the Redirect arrived [INTRO:2,
+            Appendix A], or if the source of the Redirect is not the
+            current first-hop gateway for the specified destination (see
+            Section 3.3.1).
+
+         3.2.2.3  Source Quench: RFC-792
+
+            A host MAY send a Source Quench message if it is
+            approaching, or has reached, the point at which it is forced
+            to discard incoming datagrams due to a shortage of
+            reassembly buffers or other resources.  See Section 2.2.3 of
+            [INTRO:2] for suggestions on when to send Source Quench.
+
+            If a Source Quench message is received, the IP layer MUST
+            report it to the transport layer (or ICMP processing). In
+            general, the transport or application layer SHOULD implement
+            a mechanism to respond to Source Quench for any protocol
+            that can send a sequence of datagrams to the same
+            destination and which can reasonably be expected to maintain
+            enough state information to make this feasible.  See Section
+            4 for the handling of Source Quench by TCP and UDP.
+
+            DISCUSSION:
+                 A Source Quench may be generated by the target host or
+                 by some gateway in the path of a datagram.  The host
+                 receiving a Source Quench should throttle itself back
+                 for a period of time, then gradually increase the
+                 transmission rate again.  The mechanism to respond to
+                 Source Quench may be in the transport layer (for
+                 connection-oriented protocols like TCP) or in the
+                 application layer (for protocols that are built on top
+                 of UDP).
+
+                 A mechanism has been proposed [IP:14] to make the IP
+                 layer respond directly to Source Quench by controlling
+                 the rate at which datagrams are sent, however, this
+                 proposal is currently experimental and not currently
+                 recommended.
+
+         3.2.2.4  Time Exceeded: RFC-792
+
+            An incoming Time Exceeded message MUST be passed to the
+            transport layer.
+
+
+
+Internet Engineering Task Force                                [Page 41]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            DISCUSSION:
+                 A gateway will send a Time Exceeded Code 0 (In Transit)
+                 message when it discards a datagram due to an expired
+                 TTL field.  This indicates either a gateway routing
+                 loop or too small an initial TTL value.
+
+                 A host may receive a Time Exceeded Code 1 (Reassembly
+                 Timeout) message from a destination host that has timed
+                 out and discarded an incomplete datagram; see Section
+                 3.3.2 below.  In the future, receipt of this message
+                 might be part of some "MTU discovery" procedure, to
+                 discover the maximum datagram size that can be sent on
+                 the path without fragmentation.
+
+         3.2.2.5  Parameter Problem: RFC-792
+
+            A host SHOULD generate Parameter Problem messages.  An
+            incoming Parameter Problem message MUST be passed to the
+            transport layer, and it MAY be reported to the user.
+
+            DISCUSSION:
+                 The ICMP Parameter Problem message is sent to the
+                 source host for any problem not specifically covered by
+                 another ICMP message.  Receipt of a Parameter Problem
+                 message generally indicates some local or remote
+                 implementation error.
+
+            A new variant on the Parameter Problem message is hereby
+            defined:
+              Code 1 = required option is missing.
+
+            DISCUSSION:
+                 This variant is currently in use in the military
+                 community for a missing security option.
+
+         3.2.2.6  Echo Request/Reply: RFC-792
+
+            Every host MUST implement an ICMP Echo server function that
+            receives Echo Requests and sends corresponding Echo Replies.
+            A host SHOULD also implement an application-layer interface
+            for sending an Echo Request and receiving an Echo Reply, for
+            diagnostic purposes.
+
+            An ICMP Echo Request destined to an IP broadcast or IP
+            multicast address MAY be silently discarded.
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 42]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            DISCUSSION:
+                 This neutral provision results from a passionate debate
+                 between those who feel that ICMP Echo to a broadcast
+                 address provides a valuable diagnostic capability and
+                 those who feel that misuse of this feature can too
+                 easily create packet storms.
+
+            The IP source address in an ICMP Echo Reply MUST be the same
+            as the specific-destination address (defined in Section
+            3.2.1.3) of the corresponding ICMP Echo Request message.
+
+            Data received in an ICMP Echo Request MUST be entirely
+            included in the resulting Echo Reply.  However, if sending
+            the Echo Reply requires intentional fragmentation that is
+            not implemented, the datagram MUST be truncated to maximum
+            transmission size (see Section 3.3.3) and sent.
+
+            Echo Reply messages MUST be passed to the ICMP user
+            interface, unless the corresponding Echo Request originated
+            in the IP layer.
+
+            If a Record Route and/or Time Stamp option is received in an
+            ICMP Echo Request, this option (these options) SHOULD be
+            updated to include the current host and included in the IP
+            header of the Echo Reply message, without "truncation".
+            Thus, the recorded route will be for the entire round trip.
+
+            If a Source Route option is received in an ICMP Echo
+            Request, the return route MUST be reversed and used as a
+            Source Route option for the Echo Reply message.
+
+         3.2.2.7  Information Request/Reply: RFC-792
+
+            A host SHOULD NOT implement these messages.
+
+            DISCUSSION:
+                 The Information Request/Reply pair was intended to
+                 support self-configuring systems such as diskless
+                 workstations, to allow them to discover their IP
+                 network numbers at boot time.  However, the RARP and
+                 BOOTP protocols provide better mechanisms for a host to
+                 discover its own IP address.
+
+         3.2.2.8  Timestamp and Timestamp Reply: RFC-792
+
+            A host MAY implement Timestamp and Timestamp Reply.  If they
+            are implemented, the following rules MUST be followed.
+
+
+
+
+Internet Engineering Task Force                                [Page 43]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            o    The ICMP Timestamp server function returns a Timestamp
+                 Reply to every Timestamp message that is received.  If
+                 this function is implemented, it SHOULD be designed for
+                 minimum variability in delay (e.g., implemented in the
+                 kernel to avoid delay in scheduling a user process).
+
+            The following cases for Timestamp are to be handled
+            according to the corresponding rules for ICMP Echo:
+
+            o    An ICMP Timestamp Request message to an IP broadcast or
+                 IP multicast address MAY be silently discarded.
+
+            o    The IP source address in an ICMP Timestamp Reply MUST
+                 be the same as the specific-destination address of the
+                 corresponding Timestamp Request message.
+
+            o    If a Source-route option is received in an ICMP Echo
+                 Request, the return route MUST be reversed and used as
+                 a Source Route option for the Timestamp Reply message.
+
+            o    If a Record Route and/or Timestamp option is received
+                 in a Timestamp Request, this (these) option(s) SHOULD
+                 be updated to include the current host and included in
+                 the IP header of the Timestamp Reply message.
+
+            o    Incoming Timestamp Reply messages MUST be passed up to
+                 the ICMP user interface.
+
+            The preferred form for a timestamp value (the "standard
+            value") is in units of milliseconds since midnight Universal
+            Time.  However, it may be difficult to provide this value
+            with millisecond resolution.  For example, many systems use
+            clocks that update only at line frequency, 50 or 60 times
+            per second.  Therefore, some latitude is allowed in a
+            "standard value":
+
+            (a)  A "standard value" MUST be updated at least 15 times
+                 per second (i.e., at most the six low-order bits of the
+                 value may be undefined).
+
+            (b)  The accuracy of a "standard value" MUST approximate
+                 that of operator-set CPU clocks, i.e., correct within a
+                 few minutes.
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 44]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+         3.2.2.9  Address Mask Request/Reply: RFC-950
+
+            A host MUST support the first, and MAY implement all three,
+            of the following methods for determining the address mask(s)
+            corresponding to its IP address(es):
+
+            (1)  static configuration information;
+
+            (2)  obtaining the address mask(s) dynamically as a side-
+                 effect of the system initialization process (see
+                 [INTRO:1]); and
+
+            (3)  sending ICMP Address Mask Request(s) and receiving ICMP
+                 Address Mask Reply(s).
+
+            The choice of method to be used in a particular host MUST be
+            configurable.
+
+            When method (3), the use of Address Mask messages, is
+            enabled, then:
+
+            (a)  When it initializes, the host MUST broadcast an Address
+                 Mask Request message on the connected network
+                 corresponding to the IP address.  It MUST retransmit
+                 this message a small number of times if it does not
+                 receive an immediate Address Mask Reply.
+
+            (b)  Until it has received an Address Mask Reply, the host
+                 SHOULD assume a mask appropriate for the address class
+                 of the IP address, i.e., assume that the connected
+                 network is not subnetted.
+
+            (c)  The first Address Mask Reply message received MUST be
+                 used to set the address mask corresponding to the
+                 particular local IP address.  This is true even if the
+                 first Address Mask Reply message is "unsolicited", in
+                 which case it will have been broadcast and may arrive
+                 after the host has ceased to retransmit Address Mask
+                 Requests.  Once the mask has been set by an Address
+                 Mask Reply, later Address Mask Reply messages MUST be
+                 (silently) ignored.
+
+            Conversely, if Address Mask messages are disabled, then no
+            ICMP Address Mask Requests will be sent, and any ICMP
+            Address Mask Replies received for that local IP address MUST
+            be (silently) ignored.
+
+            A host SHOULD make some reasonableness check on any address
+
+
+
+Internet Engineering Task Force                                [Page 45]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            mask it installs; see IMPLEMENTATION section below.
+
+            A system MUST NOT send an Address Mask Reply unless it is an
+            authoritative agent for address masks.  An authoritative
+            agent may be a host or a gateway, but it MUST be explicitly
+            configured as a address mask agent.  Receiving an address
+            mask via an Address Mask Reply does not give the receiver
+            authority and MUST NOT be used as the basis for issuing
+            Address Mask Replies.
+
+            With a statically configured address mask, there SHOULD be
+            an additional configuration flag that determines whether the
+            host is to act as an authoritative agent for this mask,
+            i.e., whether it will answer Address Mask Request messages
+            using this mask.
+
+            If it is configured as an agent, the host MUST broadcast an
+            Address Mask Reply for the mask on the appropriate interface
+            when it initializes.
+
+            See "System Initialization" in [INTRO:1] for more
+            information about the use of Address Mask Request/Reply
+            messages.
+
+            DISCUSSION
+                 Hosts that casually send Address Mask Replies with
+                 invalid address masks have often been a serious
+                 nuisance.  To prevent this, Address Mask Replies ought
+                 to be sent only by authoritative agents that have been
+                 selected by explicit administrative action.
+
+                 When an authoritative agent receives an Address Mask
+                 Request message, it will send a unicast Address Mask
+                 Reply to the source IP address.  If the network part of
+                 this address is zero (see (a) and (b) in 3.2.1.3), the
+                 Reply will be broadcast.
+
+                 Getting no reply to its Address Mask Request messages,
+                 a host will assume there is no agent and use an
+                 unsubnetted mask, but the agent may be only temporarily
+                 unreachable.  An agent will broadcast an unsolicited
+                 Address Mask Reply whenever it initializes, in order to
+                 update the masks of all hosts that have initialized in
+                 the meantime.
+
+            IMPLEMENTATION:
+                 The following reasonableness check on an address mask
+                 is suggested: the mask is not all 1 bits, and it is
+
+
+
+Internet Engineering Task Force                                [Page 46]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 either zero or else the 8 highest-order bits are on.
+
+      3.2.3  Internet Group Management Protocol IGMP
+
+         IGMP [IP:4] is a protocol used between hosts and gateways on a
+         single network to establish hosts' membership in particular
+         multicast groups.  The gateways use this information, in
+         conjunction with a multicast routing protocol, to support IP
+         multicasting across the Internet.
+
+         At this time, implementation of IGMP is OPTIONAL; see Section
+         3.3.7 for more information.  Without IGMP, a host can still
+         participate in multicasting local to its connected networks.
+
+   3.3  SPECIFIC ISSUES
+
+      3.3.1  Routing Outbound Datagrams
+
+         The IP layer chooses the correct next hop for each datagram it
+         sends.  If the destination is on a connected network, the
+         datagram is sent directly to the destination host; otherwise,
+         it has to be routed to a gateway on a connected network.
+
+         3.3.1.1  Local/Remote Decision
+
+            To decide if the destination is on a connected network, the
+            following algorithm MUST be used [see IP:3]:
+
+            (a)  The address mask (particular to a local IP address for
+                 a multihomed host) is a 32-bit mask that selects the
+                 network number and subnet number fields of the
+                 corresponding IP address.
+
+            (b)  If the IP destination address bits extracted by the
+                 address mask match the IP source address bits extracted
+                 by the same mask, then the destination is on the
+                 corresponding connected network, and the datagram is to
+                 be transmitted directly to the destination host.
+
+            (c)  If not, then the destination is accessible only through
+                 a gateway.  Selection of a gateway is described below
+                 (3.3.1.2).
+
+            A special-case destination address is handled as follows:
+
+            *    For a limited broadcast or a multicast address, simply
+                 pass the datagram to the link layer for the appropriate
+                 interface.
+
+
+
+Internet Engineering Task Force                                [Page 47]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            *    For a (network or subnet) directed broadcast, the
+                 datagram can use the standard routing algorithms.
+
+            The host IP layer MUST operate correctly in a minimal
+            network environment, and in particular, when there are no
+            gateways.  For example, if the IP layer of a host insists on
+            finding at least one gateway to initialize, the host will be
+            unable to operate on a single isolated broadcast net.
+
+         3.3.1.2  Gateway Selection
+
+            To efficiently route a series of datagrams to the same
+            destination, the source host MUST keep a "route cache" of
+            mappings to next-hop gateways.  A host uses the following
+            basic algorithm on this cache to route a datagram; this
+            algorithm is designed to put the primary routing burden on
+            the gateways [IP:11].
+
+            (a)  If the route cache contains no information for a
+                 particular destination, the host chooses a "default"
+                 gateway and sends the datagram to it.  It also builds a
+                 corresponding Route Cache entry.
+
+            (b)  If that gateway is not the best next hop to the
+                 destination, the gateway will forward the datagram to
+                 the best next-hop gateway and return an ICMP Redirect
+                 message to the source host.
+
+            (c)  When it receives a Redirect, the host updates the
+                 next-hop gateway in the appropriate route cache entry,
+                 so later datagrams to the same destination will go
+                 directly to the best gateway.
+
+            Since the subnet mask appropriate to the destination address
+            is generally not known, a Network Redirect message SHOULD be
+            treated identically to a Host Redirect message; i.e., the
+            cache entry for the destination host (only) would be updated
+            (or created, if an entry for that host did not exist) for
+            the new gateway.
+
+            DISCUSSION:
+                 This recommendation is to protect against gateways that
+                 erroneously send Network Redirects for a subnetted
+                 network, in violation of the gateway requirements
+                 [INTRO:2].
+
+            When there is no route cache entry for the destination host
+            address (and the destination is not on the connected
+
+
+
+Internet Engineering Task Force                                [Page 48]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            network), the IP layer MUST pick a gateway from its list of
+            "default" gateways.  The IP layer MUST support multiple
+            default gateways.
+
+            As an extra feature, a host IP layer MAY implement a table
+            of "static routes".  Each such static route MAY include a
+            flag specifying whether it may be overridden by ICMP
+            Redirects.
+
+            DISCUSSION:
+                 A host generally needs to know at least one default
+                 gateway to get started.  This information can be
+                 obtained from a configuration file or else from the
+                 host startup sequence, e.g., the BOOTP protocol (see
+                 [INTRO:1]).
+
+                 It has been suggested that a host can augment its list
+                 of default gateways by recording any new gateways it
+                 learns about.  For example, it can record every gateway
+                 to which it is ever redirected.  Such a feature, while
+                 possibly useful in some circumstances, may cause
+                 problems in other cases (e.g., gateways are not all
+                 equal), and it is not recommended.
+
+                 A static route is typically a particular preset mapping
+                 from destination host or network into a particular
+                 next-hop gateway; it might also depend on the Type-of-
+                 Service (see next section).  Static routes would be set
+                 up by system administrators to override the normal
+                 automatic routing mechanism, to handle exceptional
+                 situations.  However, any static routing information is
+                 a potential source of failure as configurations change
+                 or equipment fails.
+
+         3.3.1.3  Route Cache
+
+            Each route cache entry needs to include the following
+            fields:
+
+            (1)  Local IP address (for a multihomed host)
+
+            (2)  Destination IP address
+
+            (3)  Type(s)-of-Service
+
+            (4)  Next-hop gateway IP address
+
+            Field (2) MAY be the full IP address of the destination
+
+
+
+Internet Engineering Task Force                                [Page 49]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            host, or only the destination network number.  Field (3),
+            the TOS, SHOULD be included.
+
+            See Section 3.3.4.2 for a discussion of the implications of
+            multihoming for the lookup procedure in this cache.
+
+            DISCUSSION:
+                 Including the Type-of-Service field in the route cache
+                 and considering it in the host route algorithm will
+                 provide the necessary mechanism for the future when
+                 Type-of-Service routing is commonly used in the
+                 Internet.  See Section 3.2.1.6.
+
+                 Each route cache entry defines the endpoints of an
+                 Internet path.  Although the connecting path may change
+                 dynamically in an arbitrary way, the transmission
+                 characteristics of the path tend to remain
+                 approximately constant over a time period longer than a
+                 single typical host-host transport connection.
+                 Therefore, a route cache entry is a natural place to
+                 cache data on the properties of the path.  Examples of
+                 such properties might be the maximum unfragmented
+                 datagram size (see Section 3.3.3), or the average
+                 round-trip delay measured by a transport protocol.
+                 This data will generally be both gathered and used by a
+                 higher layer protocol, e.g., by TCP, or by an
+                 application using UDP.  Experiments are currently in
+                 progress on caching path properties in this manner.
+
+                 There is no consensus on whether the route cache should
+                 be keyed on destination host addresses alone, or allow
+                 both host and network addresses.  Those who favor the
+                 use of only host addresses argue that:
+
+                 (1)  As required in Section 3.3.1.2, Redirect messages
+                      will generally result in entries keyed on
+                      destination host addresses; the simplest and most
+                      general scheme would be to use host addresses
+                      always.
+
+                 (2)  The IP layer may not always know the address mask
+                      for a network address in a complex subnetted
+                      environment.
+
+                 (3)  The use of only host addresses allows the
+                      destination address to be used as a pure 32-bit
+                      number, which may allow the Internet architecture
+                      to be more easily extended in the future without
+
+
+
+Internet Engineering Task Force                                [Page 50]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                      any change to the hosts.
+
+                 The opposing view is that allowing a mixture of
+                 destination hosts and networks in the route cache:
+
+                 (1)  Saves memory space.
+
+                 (2)  Leads to a simpler data structure, easily
+                      combining the cache with the tables of default and
+                      static routes (see below).
+
+                 (3)  Provides a more useful place to cache path
+                      properties, as discussed earlier.
+
+
+            IMPLEMENTATION:
+                 The cache needs to be large enough to include entries
+                 for the maximum number of destination hosts that may be
+                 in use at one time.
+
+                 A route cache entry may also include control
+                 information used to choose an entry for replacement.
+                 This might take the form of a "recently used" bit, a
+                 use count, or a last-used timestamp, for example.  It
+                 is recommended that it include the time of last
+                 modification of the entry, for diagnostic purposes.
+
+                 An implementation may wish to reduce the overhead of
+                 scanning the route cache for every datagram to be
+                 transmitted.  This may be accomplished with a hash
+                 table to speed the lookup, or by giving a connection-
+                 oriented transport protocol a "hint" or temporary
+                 handle on the appropriate cache entry, to be passed to
+                 the IP layer with each subsequent datagram.
+
+                 Although we have described the route cache, the lists
+                 of default gateways, and a table of static routes as
+                 conceptually distinct, in practice they may be combined
+                 into a single "routing table" data structure.
+
+         3.3.1.4  Dead Gateway Detection
+
+            The IP layer MUST be able to detect the failure of a "next-
+            hop" gateway that is listed in its route cache and to choose
+            an alternate gateway (see Section 3.3.1.5).
+
+            Dead gateway detection is covered in some detail in RFC-816
+            [IP:11]. Experience to date has not produced a complete
+
+
+
+Internet Engineering Task Force                                [Page 51]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            algorithm which is totally satisfactory, though it has
+            identified several forbidden paths and promising techniques.
+
+            *    A particular gateway SHOULD NOT be used indefinitely in
+                 the absence of positive indications that it is
+                 functioning.
+
+            *    Active probes such as "pinging" (i.e., using an ICMP
+                 Echo Request/Reply exchange) are expensive and scale
+                 poorly.  In particular, hosts MUST NOT actively check
+                 the status of a first-hop gateway by simply pinging the
+                 gateway continuously.
+
+            *    Even when it is the only effective way to verify a
+                 gateway's status, pinging MUST be used only when
+                 traffic is being sent to the gateway and when there is
+                 no other positive indication to suggest that the
+                 gateway is functioning.
+
+            *    To avoid pinging, the layers above and/or below the
+                 Internet layer SHOULD be able to give "advice" on the
+                 status of route cache entries when either positive
+                 (gateway OK) or negative (gateway dead) information is
+                 available.
+
+
+            DISCUSSION:
+                 If an implementation does not include an adequate
+                 mechanism for detecting a dead gateway and re-routing,
+                 a gateway failure may cause datagrams to apparently
+                 vanish into a "black hole".  This failure can be
+                 extremely confusing for users and difficult for network
+                 personnel to debug.
+
+                 The dead-gateway detection mechanism must not cause
+                 unacceptable load on the host, on connected networks,
+                 or on first-hop gateway(s).  The exact constraints on
+                 the timeliness of dead gateway detection and on
+                 acceptable load may vary somewhat depending on the
+                 nature of the host's mission, but a host generally
+                 needs to detect a failed first-hop gateway quickly
+                 enough that transport-layer connections will not break
+                 before an alternate gateway can be selected.
+
+                 Passing advice from other layers of the protocol stack
+                 complicates the interfaces between the layers, but it
+                 is the preferred approach to dead gateway detection.
+                 Advice can come from almost any part of the IP/TCP
+
+
+
+Internet Engineering Task Force                                [Page 52]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 architecture, but it is expected to come primarily from
+                 the transport and link layers.  Here are some possible
+                 sources for gateway advice:
+
+                 o    TCP or any connection-oriented transport protocol
+                      should be able to give negative advice, e.g.,
+                      triggered by excessive retransmissions.
+
+                 o    TCP may give positive advice when (new) data is
+                      acknowledged.  Even though the route may be
+                      asymmetric, an ACK for new data proves that the
+                      acknowleged data must have been transmitted
+                      successfully.
+
+                 o    An ICMP Redirect message from a particular gateway
+                      should be used as positive advice about that
+                      gateway.
+
+                 o    Link-layer information that reliably detects and
+                      reports host failures (e.g., ARPANET Destination
+                      Dead messages) should be used as negative advice.
+
+                 o    Failure to ARP or to re-validate ARP mappings may
+                      be used as negative advice for the corresponding
+                      IP address.
+
+                 o    Packets arriving from a particular link-layer
+                      address are evidence that the system at this
+                      address is alive.  However, turning this
+                      information into advice about gateways requires
+                      mapping the link-layer address into an IP address,
+                      and then checking that IP address against the
+                      gateways pointed to by the route cache.  This is
+                      probably prohibitively inefficient.
+
+                 Note that positive advice that is given for every
+                 datagram received may cause unacceptable overhead in
+                 the implementation.
+
+                 While advice might be passed using required arguments
+                 in all interfaces to the IP layer, some transport and
+                 application layer protocols cannot deduce the correct
+                 advice.  These interfaces must therefore allow a
+                 neutral value for advice, since either always-positive
+                 or always-negative advice leads to incorrect behavior.
+
+                 There is another technique for dead gateway detection
+                 that has been commonly used but is not recommended.
+
+
+
+Internet Engineering Task Force                                [Page 53]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 This technique depends upon the host passively
+                 receiving ("wiretapping") the Interior Gateway Protocol
+                 (IGP) datagrams that the gateways are broadcasting to
+                 each other.  This approach has the drawback that a host
+                 needs to recognize all the interior gateway protocols
+                 that gateways may use (see [INTRO:2]).  In addition, it
+                 only works on a broadcast network.
+
+                 At present, pinging (i.e., using ICMP Echo messages) is
+                 the mechanism for gateway probing when absolutely
+                 required.  A successful ping guarantees that the
+                 addressed interface and its associated machine are up,
+                 but it does not guarantee that the machine is a gateway
+                 as opposed to a host.  The normal inference is that if
+                 a Redirect or other evidence indicates that a machine
+                 was a gateway, successful pings will indicate that the
+                 machine is still up and hence still a gateway.
+                 However, since a host silently discards packets that a
+                 gateway would forward or redirect, this assumption
+                 could sometimes fail.  To avoid this problem, a new
+                 ICMP message under development will ask "are you a
+                 gateway?"
+
+            IMPLEMENTATION:
+                 The following specific algorithm has been suggested:
+
+                 o    Associate a "reroute timer" with each gateway
+                      pointed to by the route cache.  Initialize the
+                      timer to a value Tr, which must be small enough to
+                      allow detection of a dead gateway before transport
+                      connections time out.
+
+                 o    Positive advice would reset the reroute timer to
+                      Tr.  Negative advice would reduce or zero the
+                      reroute timer.
+
+                 o    Whenever the IP layer used a particular gateway to
+                      route a datagram, it would check the corresponding
+                      reroute timer.  If the timer had expired (reached
+                      zero), the IP layer would send a ping to the
+                      gateway, followed immediately by the datagram.
+
+                 o    The ping (ICMP Echo) would be sent again if
+                      necessary, up to N times.  If no ping reply was
+                      received in N tries, the gateway would be assumed
+                      to have failed, and a new first-hop gateway would
+                      be chosen for all cache entries pointing to the
+                      failed gateway.
+
+
+
+Internet Engineering Task Force                                [Page 54]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 Note that the size of Tr is inversely related to the
+                 amount of advice available.  Tr should be large enough
+                 to insure that:
+
+                 *    Any pinging will be at a low level (e.g., <10%) of
+                      all packets sent to a gateway from the host, AND
+
+                 *    pinging is infrequent (e.g., every 3 minutes)
+
+                 Since the recommended algorithm is concerned with the
+                 gateways pointed to by route cache entries, rather than
+                 the cache entries themselves, a two level data
+                 structure (perhaps coordinated with ARP or similar
+                 caches) may be desirable for implementing a route
+                 cache.
+
+         3.3.1.5  New Gateway Selection
+
+            If the failed gateway is not the current default, the IP
+            layer can immediately switch to a default gateway.  If it is
+            the current default that failed, the IP layer MUST select a
+            different default gateway (assuming more than one default is
+            known) for the failed route and for establishing new routes.
+
+            DISCUSSION:
+                 When a gateway does fail, the other gateways on the
+                 connected network will learn of the failure through
+                 some inter-gateway routing protocol.  However, this
+                 will not happen instantaneously, since gateway routing
+                 protocols typically have a settling time of 30-60
+                 seconds.  If the host switches to an alternative
+                 gateway before the gateways have agreed on the failure,
+                 the new target gateway will probably forward the
+                 datagram to the failed gateway and send a Redirect back
+                 to the host pointing to the failed gateway (!).  The
+                 result is likely to be a rapid oscillation in the
+                 contents of the host's route cache during the gateway
+                 settling period.  It has been proposed that the dead-
+                 gateway logic should include some hysteresis mechanism
+                 to prevent such oscillations.  However, experience has
+                 not shown any harm from such oscillations, since
+                 service cannot be restored to the host until the
+                 gateways' routing information does settle down.
+
+            IMPLEMENTATION:
+                 One implementation technique for choosing a new default
+                 gateway is to simply round-robin among the default
+                 gateways in the host's list.  Another is to rank the
+
+
+
+Internet Engineering Task Force                                [Page 55]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 gateways in priority order, and when the current
+                 default gateway is not the highest priority one, to
+                 "ping" the higher-priority gateways slowly to detect
+                 when they return to service.  This pinging can be at a
+                 very low rate, e.g., 0.005 per second.
+
+         3.3.1.6  Initialization
+
+            The following information MUST be configurable:
+
+            (1)  IP address(es).
+
+            (2)  Address mask(s).
+
+            (3)  A list of default gateways, with a preference level.
+
+            A manual method of entering this configuration data MUST be
+            provided.  In addition, a variety of methods can be used to
+            determine this information dynamically; see the section on
+            "Host Initialization" in [INTRO:1].
+
+            DISCUSSION:
+                 Some host implementations use "wiretapping" of gateway
+                 protocols on a broadcast network to learn what gateways
+                 exist.  A standard method for default gateway discovery
+                 is under development.
+
+      3.3.2  Reassembly
+
+         The IP layer MUST implement reassembly of IP datagrams.
+
+         We designate the largest datagram size that can be reassembled
+         by EMTU_R ("Effective MTU to receive"); this is sometimes
+         called the "reassembly buffer size".  EMTU_R MUST be greater
+         than or equal to 576, SHOULD be either configurable or
+         indefinite, and SHOULD be greater than or equal to the MTU of
+         the connected network(s).
+
+         DISCUSSION:
+              A fixed EMTU_R limit should not be built into the code
+              because some application layer protocols require EMTU_R
+              values larger than 576.
+
+         IMPLEMENTATION:
+              An implementation may use a contiguous reassembly buffer
+              for each datagram, or it may use a more complex data
+              structure that places no definite limit on the reassembled
+              datagram size; in the latter case, EMTU_R is said to be
+
+
+
+Internet Engineering Task Force                                [Page 56]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+              "indefinite".
+
+              Logically, reassembly is performed by simply copying each
+              fragment into the packet buffer at the proper offset.
+              Note that fragments may overlap if successive
+              retransmissions use different packetizing but the same
+              reassembly Id.
+
+              The tricky part of reassembly is the bookkeeping to
+              determine when all bytes of the datagram have been
+              reassembled.  We recommend Clark's algorithm [IP:10] that
+              requires no additional data space for the bookkeeping.
+              However, note that, contrary to [IP:10], the first
+              fragment header needs to be saved for inclusion in a
+              possible ICMP Time Exceeded (Reassembly Timeout) message.
+
+         There MUST be a mechanism by which the transport layer can
+         learn MMS_R, the maximum message size that can be received and
+         reassembled in an IP datagram (see GET_MAXSIZES calls in
+         Section 3.4).  If EMTU_R is not indefinite, then the value of
+         MMS_R is given by:
+
+            MMS_R = EMTU_R - 20
+
+         since 20 is the minimum size of an IP header.
+
+         There MUST be a reassembly timeout.  The reassembly timeout
+         value SHOULD be a fixed value, not set from the remaining TTL.
+         It is recommended that the value lie between 60 seconds and 120
+         seconds.  If this timeout expires, the partially-reassembled
+         datagram MUST be discarded and an ICMP Time Exceeded message
+         sent to the source host (if fragment zero has been received).
+
+         DISCUSSION:
+              The IP specification says that the reassembly timeout
+              should be the remaining TTL from the IP header, but this
+              does not work well because gateways generally treat TTL as
+              a simple hop count rather than an elapsed time.  If the
+              reassembly timeout is too small, datagrams will be
+              discarded unnecessarily, and communication may fail.  The
+              timeout needs to be at least as large as the typical
+              maximum delay across the Internet.  A realistic minimum
+              reassembly timeout would be 60 seconds.
+
+              It has been suggested that a cache might be kept of
+              round-trip times measured by transport protocols for
+              various destinations, and that these values might be used
+              to dynamically determine a reasonable reassembly timeout
+
+
+
+Internet Engineering Task Force                                [Page 57]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+              value.  Further investigation of this approach is
+              required.
+
+              If the reassembly timeout is set too high, buffer
+              resources in the receiving host will be tied up too long,
+              and the MSL (Maximum Segment Lifetime) [TCP:1] will be
+              larger than necessary.  The MSL controls the maximum rate
+              at which fragmented datagrams can be sent using distinct
+              values of the 16-bit Ident field; a larger MSL lowers the
+              maximum rate.  The TCP specification [TCP:1] arbitrarily
+              assumes a value of 2 minutes for MSL.  This sets an upper
+              limit on a reasonable reassembly timeout value.
+
+      3.3.3  Fragmentation
+
+         Optionally, the IP layer MAY implement a mechanism to fragment
+         outgoing datagrams intentionally.
+
+         We designate by EMTU_S ("Effective MTU for sending") the
+         maximum IP datagram size that may be sent, for a particular
+         combination of IP source and destination addresses and perhaps
+         TOS.
+
+         A host MUST implement a mechanism to allow the transport layer
+         to learn MMS_S, the maximum transport-layer message size that
+         may be sent for a given {source, destination, TOS} triplet (see
+         GET_MAXSIZES call in Section 3.4).  If no local fragmentation
+         is performed, the value of MMS_S will be:
+
+            MMS_S = EMTU_S - <IP header size>
+
+         and EMTU_S must be less than or equal to the MTU of the network
+         interface corresponding to the source address of the datagram.
+         Note that <IP header size> in this equation will be 20, unless
+         the IP reserves space to insert IP options for its own purposes
+         in addition to any options inserted by the transport layer.
+
+         A host that does not implement local fragmentation MUST ensure
+         that the transport layer (for TCP) or the application layer
+         (for UDP) obtains MMS_S from the IP layer and does not send a
+         datagram exceeding MMS_S in size.
+
+         It is generally desirable to avoid local fragmentation and to
+         choose EMTU_S low enough to avoid fragmentation in any gateway
+         along the path.  In the absence of actual knowledge of the
+         minimum MTU along the path, the IP layer SHOULD use
+         EMTU_S <= 576 whenever the destination address is not on a
+         connected network, and otherwise use the connected network's
+
+
+
+Internet Engineering Task Force                                [Page 58]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+         MTU.
+
+         The MTU of each physical interface MUST be configurable.
+
+         A host IP layer implementation MAY have a configuration flag
+         "All-Subnets-MTU", indicating that the MTU of the connected
+         network is to be used for destinations on different subnets
+         within the same network, but not for other networks.  Thus,
+         this flag causes the network class mask, rather than the subnet
+         address mask, to be used to choose an EMTU_S.  For a multihomed
+         host, an "All-Subnets-MTU" flag is needed for each network
+         interface.
+
+         DISCUSSION:
+              Picking the correct datagram size to use when sending data
+              is a complex topic [IP:9].
+
+              (a)  In general, no host is required to accept an IP
+                   datagram larger than 576 bytes (including header and
+                   data), so a host must not send a larger datagram
+                   without explicit knowledge or prior arrangement with
+                   the destination host.  Thus, MMS_S is only an upper
+                   bound on the datagram size that a transport protocol
+                   may send; even when MMS_S exceeds 556, the transport
+                   layer must limit its messages to 556 bytes in the
+                   absence of other knowledge about the destination
+                   host.
+
+              (b)  Some transport protocols (e.g., TCP) provide a way to
+                   explicitly inform the sender about the largest
+                   datagram the other end can receive and reassemble
+                   [IP:7].  There is no corresponding mechanism in the
+                   IP layer.
+
+                   A transport protocol that assumes an EMTU_R larger
+                   than 576 (see Section 3.3.2), can send a datagram of
+                   this larger size to another host that implements the
+                   same protocol.
+
+              (c)  Hosts should ideally limit their EMTU_S for a given
+                   destination to the minimum MTU of all the networks
+                   along the path, to avoid any fragmentation.  IP
+                   fragmentation, while formally correct, can create a
+                   serious transport protocol performance problem,
+                   because loss of a single fragment means all the
+                   fragments in the segment must be retransmitted
+                   [IP:9].
+
+
+
+
+Internet Engineering Task Force                                [Page 59]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+              Since nearly all networks in the Internet currently
+              support an MTU of 576 or greater, we strongly recommend
+              the use of 576 for datagrams sent to non-local networks.
+
+              It has been suggested that a host could determine the MTU
+              over a given path by sending a zero-offset datagram
+              fragment and waiting for the receiver to time out the
+              reassembly (which cannot complete!) and return an ICMP
+              Time Exceeded message.  This message would include the
+              largest remaining fragment header in its body.  More
+              direct mechanisms are being experimented with, but have
+              not yet been adopted (see e.g., RFC-1063).
+
+      3.3.4  Local Multihoming
+
+         3.3.4.1  Introduction
+
+            A multihomed host has multiple IP addresses, which we may
+            think of as "logical interfaces".  These logical interfaces
+            may be associated with one or more physical interfaces, and
+            these physical interfaces may be connected to the same or
+            different networks.
+
+            Here are some important cases of multihoming:
+
+            (a)  Multiple Logical Networks
+
+                 The Internet architects envisioned that each physical
+                 network would have a single unique IP network (or
+                 subnet) number.  However, LAN administrators have
+                 sometimes found it useful to violate this assumption,
+                 operating a LAN with multiple logical networks per
+                 physical connected network.
+
+                 If a host connected to such a physical network is
+                 configured to handle traffic for each of N different
+                 logical networks, then the host will have N logical
+                 interfaces.  These could share a single physical
+                 interface, or might use N physical interfaces to the
+                 same network.
+
+            (b)  Multiple Logical Hosts
+
+                 When a host has multiple IP addresses that all have the
+                 same <Network-number> part (and the same <Subnet-
+                 number> part, if any), the logical interfaces are known
+                 as "logical hosts".  These logical interfaces might
+                 share a single physical interface or might use separate
+
+
+
+Internet Engineering Task Force                                [Page 60]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 physical interfaces to the same physical network.
+
+            (c)  Simple Multihoming
+
+                 In this case, each logical interface is mapped into a
+                 separate physical interface and each physical interface
+                 is connected to a different physical network.  The term
+                 "multihoming" was originally applied only to this case,
+                 but it is now applied more generally.
+
+                 A host with embedded gateway functionality will
+                 typically fall into the simple multihoming case.  Note,
+                 however, that a host may be simply multihomed without
+                 containing an embedded gateway, i.e., without
+                 forwarding datagrams from one connected network to
+                 another.
+
+                 This case presents the most difficult routing problems.
+                 The choice of interface (i.e., the choice of first-hop
+                 network) may significantly affect performance or even
+                 reachability of remote parts of the Internet.
+
+
+            Finally, we note another possibility that is NOT
+            multihoming:  one logical interface may be bound to multiple
+            physical interfaces, in order to increase the reliability or
+            throughput between directly connected machines by providing
+            alternative physical paths between them.  For instance, two
+            systems might be connected by multiple point-to-point links.
+            We call this "link-layer multiplexing".  With link-layer
+            multiplexing, the protocols above the link layer are unaware
+            that multiple physical interfaces are present; the link-
+            layer device driver is responsible for multiplexing and
+            routing packets across the physical interfaces.
+
+            In the Internet protocol architecture, a transport protocol
+            instance ("entity") has no address of its own, but instead
+            uses a single Internet Protocol (IP) address.  This has
+            implications for the IP, transport, and application layers,
+            and for the interfaces between them.  In particular, the
+            application software may have to be aware of the multiple IP
+            addresses of a multihomed host; in other cases, the choice
+            can be made within the network software.
+
+         3.3.4.2  Multihoming Requirements
+
+            The following general rules apply to the selection of an IP
+            source address for sending a datagram from a multihomed
+
+
+
+Internet Engineering Task Force                                [Page 61]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            host.
+
+            (1)  If the datagram is sent in response to a received
+                 datagram, the source address for the response SHOULD be
+                 the specific-destination address of the request.  See
+                 Sections 4.1.3.5 and 4.2.3.7 and the "General Issues"
+                 section of [INTRO:1] for more specific requirements on
+                 higher layers.
+
+                 Otherwise, a source address must be selected.
+
+            (2)  An application MUST be able to explicitly specify the
+                 source address for initiating a connection or a
+                 request.
+
+            (3)  In the absence of such a specification, the networking
+                 software MUST choose a source address.  Rules for this
+                 choice are described below.
+
+
+            There are two key requirement issues related to multihoming:
+
+            (A)  A host MAY silently discard an incoming datagram whose
+                 destination address does not correspond to the physical
+                 interface through which it is received.
+
+            (B)  A host MAY restrict itself to sending (non-source-
+                 routed) IP datagrams only through the physical
+                 interface that corresponds to the IP source address of
+                 the datagrams.
+
+
+            DISCUSSION:
+                 Internet host implementors have used two different
+                 conceptual models for multihoming, briefly summarized
+                 in the following discussion.  This document takes no
+                 stand on which model is preferred; each seems to have a
+                 place.  This ambivalence is reflected in the issues (A)
+                 and (B) being optional.
+
+                 o    Strong ES Model
+
+                      The Strong ES (End System, i.e., host) model
+                      emphasizes the host/gateway (ES/IS) distinction,
+                      and would therefore substitute MUST for MAY in
+                      issues (A) and (B) above.  It tends to model a
+                      multihomed host as a set of logical hosts within
+                      the same physical host.
+
+
+
+Internet Engineering Task Force                                [Page 62]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                      With respect to (A), proponents of the Strong ES
+                      model note that automatic Internet routing
+                      mechanisms could not route a datagram to a
+                      physical interface that did not correspond to the
+                      destination address.
+
+                      Under the Strong ES model, the route computation
+                      for an outgoing datagram is the mapping:
+
+                         route(src IP addr, dest IP addr, TOS)
+                                                        -> gateway
+
+                      Here the source address is included as a parameter
+                      in order to select a gateway that is directly
+                      reachable on the corresponding physical interface.
+                      Note that this model logically requires that in
+                      general there be at least one default gateway, and
+                      preferably multiple defaults, for each IP source
+                      address.
+
+                 o    Weak ES Model
+
+                      This view de-emphasizes the ES/IS distinction, and
+                      would therefore substitute MUST NOT for MAY in
+                      issues (A) and (B).  This model may be the more
+                      natural one for hosts that wiretap gateway routing
+                      protocols, and is necessary for hosts that have
+                      embedded gateway functionality.
+
+                      The Weak ES Model may cause the Redirect mechanism
+                      to fail.  If a datagram is sent out a physical
+                      interface that does not correspond to the
+                      destination address, the first-hop gateway will
+                      not realize when it needs to send a Redirect.  On
+                      the other hand, if the host has embedded gateway
+                      functionality, then it has routing information
+                      without listening to Redirects.
+
+                      In the Weak ES model, the route computation for an
+                      outgoing datagram is the mapping:
+
+                         route(dest IP addr, TOS) -> gateway, interface
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 63]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+         3.3.4.3  Choosing a Source Address
+
+            DISCUSSION:
+                 When it sends an initial connection request (e.g., a
+                 TCP "SYN" segment) or a datagram service request (e.g.,
+                 a UDP-based query), the transport layer on a multihomed
+                 host needs to know which source address to use.  If the
+                 application does not specify it, the transport layer
+                 must ask the IP layer to perform the conceptual
+                 mapping:
+
+                     GET_SRCADDR(remote IP addr, TOS)
+                                               -> local IP address
+
+                 Here TOS is the Type-of-Service value (see Section
+                 3.2.1.6), and the result is the desired source address.
+                 The following rules are suggested for implementing this
+                 mapping:
+
+                 (a)  If the remote Internet address lies on one of the
+                      (sub-) nets to which the host is directly
+                      connected, a corresponding source address may be
+                      chosen, unless the corresponding interface is
+                      known to be down.
+
+                 (b)  The route cache may be consulted, to see if there
+                      is an active route to the specified destination
+                      network through any network interface; if so, a
+                      local IP address corresponding to that interface
+                      may be chosen.
+
+                 (c)  The table of static routes, if any (see Section
+                      3.3.1.2) may be similarly consulted.
+
+                 (d)  The default gateways may be consulted.  If these
+                      gateways are assigned to different interfaces, the
+                      interface corresponding to the gateway with the
+                      highest preference may be chosen.
+
+                 In the future, there may be a defined way for a
+                 multihomed host to ask the gateways on all connected
+                 networks for advice about the best network to use for a
+                 given destination.
+
+            IMPLEMENTATION:
+                 It will be noted that this process is essentially the
+                 same as datagram routing (see Section 3.3.1), and
+                 therefore hosts may be able to combine the
+
+
+
+Internet Engineering Task Force                                [Page 64]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 implementation of the two functions.
+
+      3.3.5  Source Route Forwarding
+
+         Subject to restrictions given below, a host MAY be able to act
+         as an intermediate hop in a source route, forwarding a source-
+         routed datagram to the next specified hop.
+
+         However, in performing this gateway-like function, the host
+         MUST obey all the relevant rules for a gateway forwarding
+         source-routed datagrams [INTRO:2].  This includes the following
+         specific provisions, which override the corresponding host
+         provisions given earlier in this document:
+
+         (A)  TTL (ref. Section 3.2.1.7)
+
+              The TTL field MUST be decremented and the datagram perhaps
+              discarded as specified for a gateway in [INTRO:2].
+
+         (B)  ICMP Destination Unreachable (ref. Section 3.2.2.1)
+
+              A host MUST be able to generate Destination Unreachable
+              messages with the following codes:
+
+              4    (Fragmentation Required but DF Set) when a source-
+                   routed datagram cannot be fragmented to fit into the
+                   target network;
+
+              5    (Source Route Failed) when a source-routed datagram
+                   cannot be forwarded, e.g., because of a routing
+                   problem or because the next hop of a strict source
+                   route is not on a connected network.
+
+         (C)  IP Source Address (ref. Section 3.2.1.3)
+
+              A source-routed datagram being forwarded MAY (and normally
+              will) have a source address that is not one of the IP
+              addresses of the forwarding host.
+
+         (D)  Record Route Option (ref. Section 3.2.1.8d)
+
+              A host that is forwarding a source-routed datagram
+              containing a Record Route option MUST update that option,
+              if it has room.
+
+         (E)  Timestamp Option (ref. Section 3.2.1.8e)
+
+              A host that is forwarding a source-routed datagram
+
+
+
+Internet Engineering Task Force                                [Page 65]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+              containing a Timestamp Option MUST add the current
+              timestamp to that option, according to the rules for this
+              option.
+
+         To define the rules restricting host forwarding of source-
+         routed datagrams, we use the term "local source-routing" if the
+         next hop will be through the same physical interface through
+         which the datagram arrived; otherwise, it is "non-local
+         source-routing".
+
+         o    A host is permitted to perform local source-routing
+              without restriction.
+
+         o    A host that supports non-local source-routing MUST have a
+              configurable switch to disable forwarding, and this switch
+              MUST default to disabled.
+
+         o    The host MUST satisfy all gateway requirements for
+              configurable policy filters [INTRO:2] restricting non-
+              local forwarding.
+
+         If a host receives a datagram with an incomplete source route
+         but does not forward it for some reason, the host SHOULD return
+         an ICMP Destination Unreachable (code 5, Source Route Failed)
+         message, unless the datagram was itself an ICMP error message.
+
+      3.3.6  Broadcasts
+
+         Section 3.2.1.3 defined the four standard IP broadcast address
+         forms:
+
+           Limited Broadcast:  {-1, -1}
+
+           Directed Broadcast:  {<Network-number>,-1}
+
+           Subnet Directed Broadcast:
+                              {<Network-number>,<Subnet-number>,-1}
+
+           All-Subnets Directed Broadcast: {<Network-number>,-1,-1}
+
+         A host MUST recognize any of these forms in the destination
+         address of an incoming datagram.
+
+         There is a class of hosts* that use non-standard broadcast
+         address forms, substituting 0 for -1.  All hosts SHOULD
+_________________________
+*4.2BSD Unix and its derivatives, but not 4.3BSD.
+
+
+
+
+Internet Engineering Task Force                                [Page 66]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+         recognize and accept any of these non-standard broadcast
+         addresses as the destination address of an incoming datagram.
+         A host MAY optionally have a configuration option to choose the
+         0 or the -1 form of broadcast address, for each physical
+         interface, but this option SHOULD default to the standard (-1)
+         form.
+
+         When a host sends a datagram to a link-layer broadcast address,
+         the IP destination address MUST be a legal IP broadcast or IP
+         multicast address.
+
+         A host SHOULD silently discard a datagram that is received via
+         a link-layer broadcast (see Section 2.4) but does not specify
+         an IP multicast or broadcast destination address.
+
+         Hosts SHOULD use the Limited Broadcast address to broadcast to
+         a connected network.
+
+
+         DISCUSSION:
+              Using the Limited Broadcast address instead of a Directed
+              Broadcast address may improve system robustness.  Problems
+              are often caused by machines that do not understand the
+              plethora of broadcast addresses (see Section 3.2.1.3), or
+              that may have different ideas about which broadcast
+              addresses are in use.  The prime example of the latter is
+              machines that do not understand subnetting but are
+              attached to a subnetted net.  Sending a Subnet Broadcast
+              for the connected network will confuse those machines,
+              which will see it as a message to some other host.
+
+              There has been discussion on whether a datagram addressed
+              to the Limited Broadcast address ought to be sent from all
+              the interfaces of a multihomed host.  This specification
+              takes no stand on the issue.
+
+      3.3.7  IP Multicasting
+
+         A host SHOULD support local IP multicasting on all connected
+         networks for which a mapping from Class D IP addresses to
+         link-layer addresses has been specified (see below).  Support
+         for local IP multicasting includes sending multicast datagrams,
+         joining multicast groups and receiving multicast datagrams, and
+         leaving multicast groups.  This implies support for all of
+         [IP:4] except the IGMP protocol itself, which is OPTIONAL.
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 67]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+         DISCUSSION:
+              IGMP provides gateways that are capable of multicast
+              routing with the information required to support IP
+              multicasting across multiple networks.  At this time,
+              multicast-routing gateways are in the experimental stage
+              and are not widely available.  For hosts that are not
+              connected to networks with multicast-routing gateways or
+              that do not need to receive multicast datagrams
+              originating on other networks, IGMP serves no purpose and
+              is therefore optional for now.  However, the rest of
+              [IP:4] is currently recommended for the purpose of
+              providing IP-layer access to local network multicast
+              addressing, as a preferable alternative to local broadcast
+              addressing.  It is expected that IGMP will become
+              recommended at some future date, when multicast-routing
+              gateways have become more widely available.
+
+         If IGMP is not implemented, a host SHOULD still join the "all-
+         hosts" group (224.0.0.1) when the IP layer is initialized and
+         remain a member for as long as the IP layer is active.
+
+         DISCUSSION:
+              Joining the "all-hosts" group will support strictly local
+              uses of multicasting, e.g., a gateway discovery protocol,
+              even if IGMP is not implemented.
+
+         The mapping of IP Class D addresses to local addresses is
+         currently specified for the following types of networks:
+
+         o    Ethernet/IEEE 802.3, as defined in [IP:4].
+
+         o    Any network that supports broadcast but not multicast,
+              addressing: all IP Class D addresses map to the local
+              broadcast address.
+
+         o    Any type of point-to-point link (e.g., SLIP or HDLC
+              links): no mapping required.  All IP multicast datagrams
+              are sent as-is, inside the local framing.
+
+         Mappings for other types of networks will be specified in the
+         future.
+
+         A host SHOULD provide a way for higher-layer protocols or
+         applications to determine which of the host's connected
+         network(s) support IP multicast addressing.
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 68]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+      3.3.8  Error Reporting
+
+         Wherever practical, hosts MUST return ICMP error datagrams on
+         detection of an error, except in those cases where returning an
+         ICMP error message is specifically prohibited.
+
+         DISCUSSION:
+              A common phenomenon in datagram networks is the "black
+              hole disease": datagrams are sent out, but nothing comes
+              back.  Without any error datagrams, it is difficult for
+              the user to figure out what the problem is.
+
+   3.4  INTERNET/TRANSPORT LAYER INTERFACE
+
+      The interface between the IP layer and the transport layer MUST
+      provide full access to all the mechanisms of the IP layer,
+      including options, Type-of-Service, and Time-to-Live.  The
+      transport layer MUST either have mechanisms to set these interface
+      parameters, or provide a path to pass them through from an
+      application, or both.
+
+      DISCUSSION:
+           Applications are urged to make use of these mechanisms where
+           applicable, even when the mechanisms are not currently
+           effective in the Internet (e.g., TOS).  This will allow these
+           mechanisms to be immediately useful when they do become
+           effective, without a large amount of retrofitting of host
+           software.
+
+      We now describe a conceptual interface between the transport layer
+      and the IP layer, as a set of procedure calls.  This is an
+      extension of the information in Section 3.3 of RFC-791 [IP:1].
+
+
+      *    Send Datagram
+
+                SEND(src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt
+                     => result )
+
+           where the parameters are defined in RFC-791.  Passing an Id
+           parameter is optional; see Section 3.2.1.5.
+
+
+      *    Receive Datagram
+
+                RECV(BufPTR, prot
+                     => result, src, dst, SpecDest, TOS, len, opt)
+
+
+
+
+Internet Engineering Task Force                                [Page 69]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+           All the parameters are defined in RFC-791, except for:
+
+                SpecDest = specific-destination address of datagram
+                            (defined in Section 3.2.1.3)
+
+           The result parameter dst contains the datagram's destination
+           address.  Since this may be a broadcast or multicast address,
+           the SpecDest parameter (not shown in RFC-791) MUST be passed.
+           The parameter opt contains all the IP options received in the
+           datagram; these MUST also be passed to the transport layer.
+
+
+      *    Select Source Address
+
+                GET_SRCADDR(remote, TOS)  -> local
+
+                remote = remote IP address
+                TOS = Type-of-Service
+                local = local IP address
+
+           See Section 3.3.4.3.
+
+
+      *    Find Maximum Datagram Sizes
+
+                GET_MAXSIZES(local, remote, TOS) -> MMS_R, MMS_S
+
+                MMS_R = maximum receive transport-message size.
+                MMS_S = maximum send transport-message size.
+               (local, remote, TOS defined above)
+
+           See Sections 3.3.2 and 3.3.3.
+
+
+      *    Advice on Delivery Success
+
+                ADVISE_DELIVPROB(sense, local, remote, TOS)
+
+           Here the parameter sense is a 1-bit flag indicating whether
+           positive or negative advice is being given; see the
+           discussion in Section 3.3.1.4. The other parameters were
+           defined earlier.
+
+
+      *    Send ICMP Message
+
+                SEND_ICMP(src, dst, TOS, TTL, BufPTR, len, Id, DF, opt)
+                     -> result
+
+
+
+Internet Engineering Task Force                                [Page 70]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                (Parameters defined in RFC-791).
+
+           Passing an Id parameter is optional; see Section 3.2.1.5.
+           The transport layer MUST be able to send certain ICMP
+           messages:  Port Unreachable or any of the query-type
+           messages.  This function could be considered to be a special
+           case of the SEND() call, of course; we describe it separately
+           for clarity.
+
+
+      *    Receive ICMP Message
+
+                RECV_ICMP(BufPTR ) -> result, src, dst, len, opt
+
+                (Parameters defined in RFC-791).
+
+           The IP layer MUST pass certain ICMP messages up to the
+           appropriate transport-layer routine.  This function could be
+           considered to be a special case of the RECV() call, of
+           course; we describe it separately for clarity.
+
+           For an ICMP error message, the data that is passed up MUST
+           include the original Internet header plus all the octets of
+           the original message that are included in the ICMP message.
+           This data will be used by the transport layer to locate the
+           connection state information, if any.
+
+           In particular, the following ICMP messages are to be passed
+           up:
+
+           o    Destination Unreachable
+
+           o    Source Quench
+
+           o    Echo Reply (to ICMP user interface, unless the Echo
+                Request originated in the IP layer)
+
+           o    Timestamp Reply (to ICMP user interface)
+
+           o    Time Exceeded
+
+
+      DISCUSSION:
+           In the future, there may be additions to this interface to
+           pass path data (see Section 3.3.1.3) between the IP and
+           transport layers.
+
+
+
+
+
+Internet Engineering Task Force                                [Page 71]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+   3.5  INTERNET LAYER REQUIREMENTS SUMMARY
+
+
+                                                 |        | | | |S| |
+                                                 |        | | | |H| |F
+                                                 |        | | | |O|M|o
+                                                 |        | |S| |U|U|o
+                                                 |        | |H| |L|S|t
+                                                 |        |M|O| |D|T|n
+                                                 |        |U|U|M| | |o
+                                                 |        |S|L|A|N|N|t
+                                                 |        |T|D|Y|O|O|t
+FEATURE                                          |SECTION | | | |T|T|e
+-------------------------------------------------|--------|-|-|-|-|-|--
+                                                 |        | | | | | |
+Implement IP and ICMP                            |3.1     |x| | | | |
+Handle remote multihoming in application layer   |3.1     |x| | | | |
+Support local multihoming                        |3.1     | | |x| | |
+Meet gateway specs if forward datagrams          |3.1     |x| | | | |
+Configuration switch for embedded gateway        |3.1     |x| | | | |1
+   Config switch default to non-gateway          |3.1     |x| | | | |1
+   Auto-config based on number of interfaces     |3.1     | | | | |x|1
+Able to log discarded datagrams                  |3.1     | |x| | | |
+   Record in counter                             |3.1     | |x| | | |
+                                                 |        | | | | | |
+Silently discard Version != 4                    |3.2.1.1 |x| | | | |
+Verify IP checksum, silently discard bad dgram   |3.2.1.2 |x| | | | |
+Addressing:                                      |        | | | | | |
+  Subnet addressing (RFC-950)                    |3.2.1.3 |x| | | | |
+  Src address must be host's own IP address      |3.2.1.3 |x| | | | |
+  Silently discard datagram with bad dest addr   |3.2.1.3 |x| | | | |
+  Silently discard datagram with bad src addr    |3.2.1.3 |x| | | | |
+Support reassembly                               |3.2.1.4 |x| | | | |
+Retain same Id field in identical datagram       |3.2.1.5 | | |x| | |
+                                                 |        | | | | | |
+TOS:                                             |        | | | | | |
+  Allow transport layer to set TOS               |3.2.1.6 |x| | | | |
+  Pass received TOS up to transport layer        |3.2.1.6 | |x| | | |
+  Use RFC-795 link-layer mappings for TOS        |3.2.1.6 | | | |x| |
+TTL:                                             |        | | | | | |
+  Send packet with TTL of 0                      |3.2.1.7 | | | | |x|
+  Discard received packets with TTL < 2          |3.2.1.7 | | | | |x|
+  Allow transport layer to set TTL               |3.2.1.7 |x| | | | |
+  Fixed TTL is configurable                      |3.2.1.7 |x| | | | |
+                                                 |        | | | | | |
+IP Options:                                      |        | | | | | |
+  Allow transport layer to send IP options       |3.2.1.8 |x| | | | |
+  Pass all IP options rcvd to higher layer       |3.2.1.8 |x| | | | |
+
+
+
+Internet Engineering Task Force                                [Page 72]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+  IP layer silently ignore unknown options       |3.2.1.8 |x| | | | |
+  Security option                                |3.2.1.8a| | |x| | |
+  Send Stream Identifier option                  |3.2.1.8b| | | |x| |
+  Silently ignore Stream Identifer option        |3.2.1.8b|x| | | | |
+  Record Route option                            |3.2.1.8d| | |x| | |
+  Timestamp option                               |3.2.1.8e| | |x| | |
+Source Route Option:                             |        | | | | | |
+  Originate & terminate Source Route options     |3.2.1.8c|x| | | | |
+  Datagram with completed SR passed up to TL     |3.2.1.8c|x| | | | |
+  Build correct (non-redundant) return route     |3.2.1.8c|x| | | | |
+  Send multiple SR options in one header         |3.2.1.8c| | | | |x|
+                                                 |        | | | | | |
+ICMP:                                            |        | | | | | |
+  Silently discard ICMP msg with unknown type    |3.2.2   |x| | | | |
+  Include more than 8 octets of orig datagram    |3.2.2   | | |x| | |
+      Included octets same as received           |3.2.2   |x| | | | |
+  Demux ICMP Error to transport protocol         |3.2.2   |x| | | | |
+  Send ICMP error message with TOS=0             |3.2.2   | |x| | | |
+  Send ICMP error message for:                   |        | | | | | |
+   - ICMP error msg                              |3.2.2   | | | | |x|
+   - IP b'cast or IP m'cast                      |3.2.2   | | | | |x|
+   - Link-layer b'cast                           |3.2.2   | | | | |x|
+   - Non-initial fragment                        |3.2.2   | | | | |x|
+   - Datagram with non-unique src address        |3.2.2   | | | | |x|
+  Return ICMP error msgs (when not prohibited)   |3.3.8   |x| | | | |
+                                                 |        | | | | | |
+  Dest Unreachable:                              |        | | | | | |
+    Generate Dest Unreachable (code 2/3)         |3.2.2.1 | |x| | | |
+    Pass ICMP Dest Unreachable to higher layer   |3.2.2.1 |x| | | | |
+    Higher layer act on Dest Unreach             |3.2.2.1 | |x| | | |
+      Interpret Dest Unreach as only hint        |3.2.2.1 |x| | | | |
+  Redirect:                                      |        | | | | | |
+    Host send Redirect                           |3.2.2.2 | | | |x| |
+    Update route cache when recv Redirect        |3.2.2.2 |x| | | | |
+    Handle both Host and Net Redirects           |3.2.2.2 |x| | | | |
+    Discard illegal Redirect                     |3.2.2.2 | |x| | | |
+  Source Quench:                                 |        | | | | | |
+    Send Source Quench if buffering exceeded     |3.2.2.3 | | |x| | |
+    Pass Source Quench to higher layer           |3.2.2.3 |x| | | | |
+    Higher layer act on Source Quench            |3.2.2.3 | |x| | | |
+  Time Exceeded: pass to higher layer            |3.2.2.4 |x| | | | |
+  Parameter Problem:                             |        | | | | | |
+    Send Parameter Problem messages              |3.2.2.5 | |x| | | |
+    Pass Parameter Problem to higher layer       |3.2.2.5 |x| | | | |
+    Report Parameter Problem to user             |3.2.2.5 | | |x| | |
+                                                 |        | | | | | |
+  ICMP Echo Request or Reply:                    |        | | | | | |
+    Echo server and Echo client                  |3.2.2.6 |x| | | | |
+
+
+
+Internet Engineering Task Force                                [Page 73]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+    Echo client                                  |3.2.2.6 | |x| | | |
+    Discard Echo Request to broadcast address    |3.2.2.6 | | |x| | |
+    Discard Echo Request to multicast address    |3.2.2.6 | | |x| | |
+    Use specific-dest addr as Echo Reply src     |3.2.2.6 |x| | | | |
+    Send same data in Echo Reply                 |3.2.2.6 |x| | | | |
+    Pass Echo Reply to higher layer              |3.2.2.6 |x| | | | |
+    Reflect Record Route, Time Stamp options     |3.2.2.6 | |x| | | |
+    Reverse and reflect Source Route option      |3.2.2.6 |x| | | | |
+                                                 |        | | | | | |
+  ICMP Information Request or Reply:             |3.2.2.7 | | | |x| |
+  ICMP Timestamp and Timestamp Reply:            |3.2.2.8 | | |x| | |
+    Minimize delay variability                   |3.2.2.8 | |x| | | |1
+    Silently discard b'cast Timestamp            |3.2.2.8 | | |x| | |1
+    Silently discard m'cast Timestamp            |3.2.2.8 | | |x| | |1
+    Use specific-dest addr as TS Reply src       |3.2.2.8 |x| | | | |1
+    Reflect Record Route, Time Stamp options     |3.2.2.6 | |x| | | |1
+    Reverse and reflect Source Route option      |3.2.2.8 |x| | | | |1
+    Pass Timestamp Reply to higher layer         |3.2.2.8 |x| | | | |1
+    Obey rules for "standard value"              |3.2.2.8 |x| | | | |1
+                                                 |        | | | | | |
+  ICMP Address Mask Request and Reply:           |        | | | | | |
+    Addr Mask source configurable                |3.2.2.9 |x| | | | |
+    Support static configuration of addr mask    |3.2.2.9 |x| | | | |
+    Get addr mask dynamically during booting     |3.2.2.9 | | |x| | |
+    Get addr via ICMP Addr Mask Request/Reply    |3.2.2.9 | | |x| | |
+      Retransmit Addr Mask Req if no Reply       |3.2.2.9 |x| | | | |3
+      Assume default mask if no Reply            |3.2.2.9 | |x| | | |3
+      Update address mask from first Reply only  |3.2.2.9 |x| | | | |3
+    Reasonableness check on Addr Mask            |3.2.2.9 | |x| | | |
+    Send unauthorized Addr Mask Reply msgs       |3.2.2.9 | | | | |x|
+      Explicitly configured to be agent          |3.2.2.9 |x| | | | |
+    Static config=> Addr-Mask-Authoritative flag |3.2.2.9 | |x| | | |
+      Broadcast Addr Mask Reply when init.       |3.2.2.9 |x| | | | |3
+                                                 |        | | | | | |
+ROUTING OUTBOUND DATAGRAMS:                      |        | | | | | |
+  Use address mask in local/remote decision      |3.3.1.1 |x| | | | |
+  Operate with no gateways on conn network       |3.3.1.1 |x| | | | |
+  Maintain "route cache" of next-hop gateways    |3.3.1.2 |x| | | | |
+  Treat Host and Net Redirect the same           |3.3.1.2 | |x| | | |
+  If no cache entry, use default gateway         |3.3.1.2 |x| | | | |
+    Support multiple default gateways            |3.3.1.2 |x| | | | |
+  Provide table of static routes                 |3.3.1.2 | | |x| | |
+    Flag: route overridable by Redirects         |3.3.1.2 | | |x| | |
+  Key route cache on host, not net address       |3.3.1.3 | | |x| | |
+  Include TOS in route cache                     |3.3.1.3 | |x| | | |
+                                                 |        | | | | | |
+  Able to detect failure of next-hop gateway     |3.3.1.4 |x| | | | |
+  Assume route is good forever                   |3.3.1.4 | | | |x| |
+
+
+
+Internet Engineering Task Force                                [Page 74]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+  Ping gateways continuously                     |3.3.1.4 | | | | |x|
+  Ping only when traffic being sent              |3.3.1.4 |x| | | | |
+  Ping only when no positive indication          |3.3.1.4 |x| | | | |
+  Higher and lower layers give advice            |3.3.1.4 | |x| | | |
+  Switch from failed default g'way to another    |3.3.1.5 |x| | | | |
+  Manual method of entering config info          |3.3.1.6 |x| | | | |
+                                                 |        | | | | | |
+REASSEMBLY and FRAGMENTATION:                    |        | | | | | |
+  Able to reassemble incoming datagrams          |3.3.2   |x| | | | |
+    At least 576 byte datagrams                  |3.3.2   |x| | | | |
+    EMTU_R configurable or indefinite            |3.3.2   | |x| | | |
+  Transport layer able to learn MMS_R            |3.3.2   |x| | | | |
+  Send ICMP Time Exceeded on reassembly timeout  |3.3.2   |x| | | | |
+    Fixed reassembly timeout value               |3.3.2   | |x| | | |
+                                                 |        | | | | | |
+  Pass MMS_S to higher layers                    |3.3.3   |x| | | | |
+  Local fragmentation of outgoing packets        |3.3.3   | | |x| | |
+     Else don't send bigger than MMS_S           |3.3.3   |x| | | | |
+  Send max 576 to off-net destination            |3.3.3   | |x| | | |
+  All-Subnets-MTU configuration flag             |3.3.3   | | |x| | |
+                                                 |        | | | | | |
+MULTIHOMING:                                     |        | | | | | |
+  Reply with same addr as spec-dest addr         |3.3.4.2 | |x| | | |
+  Allow application to choose local IP addr      |3.3.4.2 |x| | | | |
+  Silently discard d'gram in "wrong" interface   |3.3.4.2 | | |x| | |
+  Only send d'gram through "right" interface     |3.3.4.2 | | |x| | |4
+                                                 |        | | | | | |
+SOURCE-ROUTE FORWARDING:                         |        | | | | | |
+  Forward datagram with Source Route option      |3.3.5   | | |x| | |1
+    Obey corresponding gateway rules             |3.3.5   |x| | | | |1
+      Update TTL by gateway rules                |3.3.5   |x| | | | |1
+      Able to generate ICMP err code 4, 5        |3.3.5   |x| | | | |1
+      IP src addr not local host                 |3.3.5   | | |x| | |1
+      Update Timestamp, Record Route options     |3.3.5   |x| | | | |1
+    Configurable switch for non-local SRing      |3.3.5   |x| | | | |1
+      Defaults to OFF                            |3.3.5   |x| | | | |1
+    Satisfy gwy access rules for non-local SRing |3.3.5   |x| | | | |1
+    If not forward, send Dest Unreach (cd 5)     |3.3.5   | |x| | | |2
+                                                 |        | | | | | |
+BROADCAST:                                       |        | | | | | |
+  Broadcast addr as IP source addr               |3.2.1.3 | | | | |x|
+  Receive 0 or -1 broadcast formats OK           |3.3.6   | |x| | | |
+  Config'ble option to send 0 or -1 b'cast       |3.3.6   | | |x| | |
+    Default to -1 broadcast                      |3.3.6   | |x| | | |
+  Recognize all broadcast address formats        |3.3.6   |x| | | | |
+  Use IP b'cast/m'cast addr in link-layer b'cast |3.3.6   |x| | | | |
+  Silently discard link-layer-only b'cast dg's   |3.3.6   | |x| | | |
+  Use Limited Broadcast addr for connected net   |3.3.6   | |x| | | |
+
+
+
+Internet Engineering Task Force                                [Page 75]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                                                 |        | | | | | |
+MULTICAST:                                       |        | | | | | |
+  Support local IP multicasting (RFC-1112)       |3.3.7   | |x| | | |
+  Support IGMP (RFC-1112)                        |3.3.7   | | |x| | |
+  Join all-hosts group at startup                |3.3.7   | |x| | | |
+  Higher layers learn i'face m'cast capability   |3.3.7   | |x| | | |
+                                                 |        | | | | | |
+INTERFACE:                                       |        | | | | | |
+  Allow transport layer to use all IP mechanisms |3.4     |x| | | | |
+  Pass interface ident up to transport layer     |3.4     |x| | | | |
+  Pass all IP options up to transport layer      |3.4     |x| | | | |
+  Transport layer can send certain ICMP messages |3.4     |x| | | | |
+  Pass spec'd ICMP messages up to transp. layer  |3.4     |x| | | | |
+     Include IP hdr+8 octets or more from orig.  |3.4     |x| | | | |
+  Able to leap tall buildings at a single bound  |3.5     | |x| | | |
+
+Footnotes:
+
+(1)  Only if feature is implemented.
+
+(2)  This requirement is overruled if datagram is an ICMP error message.
+
+(3)  Only if feature is implemented and is configured "on".
+
+(4)  Unless has embedded gateway functionality or is source routed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 76]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- UDP             October 1989
+
+
+4. TRANSPORT PROTOCOLS
+
+   4.1  USER DATAGRAM PROTOCOL -- UDP
+
+      4.1.1  INTRODUCTION
+
+         The User Datagram Protocol UDP [UDP:1] offers only a minimal
+         transport service -- non-guaranteed datagram delivery -- and
+         gives applications direct access to the datagram service of the
+         IP layer.  UDP is used by applications that do not require the
+         level of service of TCP or that wish to use communications
+         services (e.g., multicast or broadcast delivery) not available
+         from TCP.
+
+         UDP is almost a null protocol; the only services it provides
+         over IP are checksumming of data and multiplexing by port
+         number.  Therefore, an application program running over UDP
+         must deal directly with end-to-end communication problems that
+         a connection-oriented protocol would have handled -- e.g.,
+         retransmission for reliable delivery, packetization and
+         reassembly, flow control, congestion avoidance, etc., when
+         these are required.  The fairly complex coupling between IP and
+         TCP will be mirrored in the coupling between UDP and many
+         applications using UDP.
+
+      4.1.2  PROTOCOL WALK-THROUGH
+
+         There are no known errors in the specification of UDP.
+
+      4.1.3  SPECIFIC ISSUES
+
+         4.1.3.1  Ports
+
+            UDP well-known ports follow the same rules as TCP well-known
+            ports; see Section 4.2.2.1 below.
+
+            If a datagram arrives addressed to a UDP port for which
+            there is no pending LISTEN call, UDP SHOULD send an ICMP
+            Port Unreachable message.
+
+         4.1.3.2  IP Options
+
+            UDP MUST pass any IP option that it receives from the IP
+            layer transparently to the application layer.
+
+            An application MUST be able to specify IP options to be sent
+            in its UDP datagrams, and UDP MUST pass these options to the
+            IP layer.
+
+
+
+Internet Engineering Task Force                                [Page 77]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- UDP             October 1989
+
+
+            DISCUSSION:
+                 At present, the only options that need be passed
+                 through UDP are Source Route, Record Route, and Time
+                 Stamp.  However, new options may be defined in the
+                 future, and UDP need not and should not make any
+                 assumptions about the format or content of options it
+                 passes to or from the application; an exception to this
+                 might be an IP-layer security option.
+
+                 An application based on UDP will need to obtain a
+                 source route from a request datagram and supply a
+                 reversed route for sending the corresponding reply.
+
+         4.1.3.3  ICMP Messages
+
+            UDP MUST pass to the application layer all ICMP error
+            messages that it receives from the IP layer.  Conceptually
+            at least, this may be accomplished with an upcall to the
+            ERROR_REPORT routine (see Section 4.2.4.1).
+
+            DISCUSSION:
+                 Note that ICMP error messages resulting from sending a
+                 UDP datagram are received asynchronously.  A UDP-based
+                 application that wants to receive ICMP error messages
+                 is responsible for maintaining the state necessary to
+                 demultiplex these messages when they arrive; for
+                 example, the application may keep a pending receive
+                 operation for this purpose.  The application is also
+                 responsible to avoid confusion from a delayed ICMP
+                 error message resulting from an earlier use of the same
+                 port(s).
+
+         4.1.3.4  UDP Checksums
+
+            A host MUST implement the facility to generate and validate
+            UDP checksums.  An application MAY optionally be able to
+            control whether a UDP checksum will be generated, but it
+            MUST default to checksumming on.
+
+            If a UDP datagram is received with a checksum that is non-
+            zero and invalid, UDP MUST silently discard the datagram.
+            An application MAY optionally be able to control whether UDP
+            datagrams without checksums should be discarded or passed to
+            the application.
+
+            DISCUSSION:
+                 Some applications that normally run only across local
+                 area networks have chosen to turn off UDP checksums for
+
+
+
+Internet Engineering Task Force                                [Page 78]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- UDP             October 1989
+
+
+                 efficiency.  As a result, numerous cases of undetected
+                 errors have been reported.  The advisability of ever
+                 turning off UDP checksumming is very controversial.
+
+            IMPLEMENTATION:
+                 There is a common implementation error in UDP
+                 checksums.  Unlike the TCP checksum, the UDP checksum
+                 is optional; the value zero is transmitted in the
+                 checksum field of a UDP header to indicate the absence
+                 of a checksum.  If the transmitter really calculates a
+                 UDP checksum of zero, it must transmit the checksum as
+                 all 1's (65535).  No special action is required at the
+                 receiver, since zero and 65535 are equivalent in 1's
+                 complement arithmetic.
+
+         4.1.3.5  UDP Multihoming
+
+            When a UDP datagram is received, its specific-destination
+            address MUST be passed up to the application layer.
+
+            An application program MUST be able to specify the IP source
+            address to be used for sending a UDP datagram or to leave it
+            unspecified (in which case the networking software will
+            choose an appropriate source address).  There SHOULD be a
+            way to communicate the chosen source address up to the
+            application layer (e.g, so that the application can later
+            receive a reply datagram only from the corresponding
+            interface).
+
+            DISCUSSION:
+                 A request/response application that uses UDP should use
+                 a source address for the response that is the same as
+                 the specific destination address of the request.  See
+                 the "General Issues" section of [INTRO:1].
+
+         4.1.3.6  Invalid Addresses
+
+            A UDP datagram received with an invalid IP source address
+            (e.g., a broadcast or multicast address) must be discarded
+            by UDP or by the IP layer (see Section 3.2.1.3).
+
+            When a host sends a UDP datagram, the source address MUST be
+            (one of) the IP address(es) of the host.
+
+      4.1.4  UDP/APPLICATION LAYER INTERFACE
+
+         The application interface to UDP MUST provide the full services
+         of the IP/transport interface described in Section 3.4 of this
+
+
+
+Internet Engineering Task Force                                [Page 79]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- UDP             October 1989
+
+
+         document.  Thus, an application using UDP needs the functions
+         of the GET_SRCADDR(), GET_MAXSIZES(), ADVISE_DELIVPROB(), and
+         RECV_ICMP() calls described in Section 3.4.  For example,
+         GET_MAXSIZES() can be used to learn the effective maximum UDP
+         maximum datagram size for a particular {interface,remote
+         host,TOS} triplet.
+
+         An application-layer program MUST be able to set the TTL and
+         TOS values as well as IP options for sending a UDP datagram,
+         and these values must be passed transparently to the IP layer.
+         UDP MAY pass the received TOS up to the application layer.
+
+      4.1.5  UDP REQUIREMENTS SUMMARY
+
+
+                                                 |        | | | |S| |
+                                                 |        | | | |H| |F
+                                                 |        | | | |O|M|o
+                                                 |        | |S| |U|U|o
+                                                 |        | |H| |L|S|t
+                                                 |        |M|O| |D|T|n
+                                                 |        |U|U|M| | |o
+                                                 |        |S|L|A|N|N|t
+                                                 |        |T|D|Y|O|O|t
+FEATURE                                          |SECTION | | | |T|T|e
+-------------------------------------------------|--------|-|-|-|-|-|--
+                                                 |        | | | | | |
+    UDP                                          |        | | | | | |
+-------------------------------------------------|--------|-|-|-|-|-|--
+                                                 |        | | | | | |
+UDP send Port Unreachable                        |4.1.3.1 | |x| | | |
+                                                 |        | | | | | |
+IP Options in UDP                                |        | | | | | |
+ - Pass rcv'd IP options to applic layer         |4.1.3.2 |x| | | | |
+ - Applic layer can specify IP options in Send   |4.1.3.2 |x| | | | |
+ - UDP passes IP options down to IP layer        |4.1.3.2 |x| | | | |
+                                                 |        | | | | | |
+Pass ICMP msgs up to applic layer                |4.1.3.3 |x| | | | |
+                                                 |        | | | | | |
+UDP checksums:                                   |        | | | | | |
+ - Able to generate/check checksum               |4.1.3.4 |x| | | | |
+ - Silently discard bad checksum                 |4.1.3.4 |x| | | | |
+ - Sender Option to not generate checksum        |4.1.3.4 | | |x| | |
+   - Default is to checksum                      |4.1.3.4 |x| | | | |
+ - Receiver Option to require checksum           |4.1.3.4 | | |x| | |
+                                                 |        | | | | | |
+UDP Multihoming                                  |        | | | | | |
+ - Pass spec-dest addr to application            |4.1.3.5 |x| | | | |
+
+
+
+Internet Engineering Task Force                                [Page 80]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- UDP             October 1989
+
+
+ - Applic layer can specify Local IP addr        |4.1.3.5 |x| | | | |
+ - Applic layer specify wild Local IP addr       |4.1.3.5 |x| | | | |
+ - Applic layer notified of Local IP addr used   |4.1.3.5 | |x| | | |
+                                                 |        | | | | | |
+Bad IP src addr silently discarded by UDP/IP     |4.1.3.6 |x| | | | |
+Only send valid IP source address                |4.1.3.6 |x| | | | |
+UDP Application Interface Services               |        | | | | | |
+Full IP interface of 3.4 for application         |4.1.4   |x| | | | |
+ - Able to spec TTL, TOS, IP opts when send dg   |4.1.4   |x| | | | |
+ - Pass received TOS up to applic layer          |4.1.4   | | |x| | |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 81]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+   4.2  TRANSMISSION CONTROL PROTOCOL -- TCP
+
+      4.2.1  INTRODUCTION
+
+         The Transmission Control Protocol TCP [TCP:1] is the primary
+         virtual-circuit transport protocol for the Internet suite.  TCP
+         provides reliable, in-sequence delivery of a full-duplex stream
+         of octets (8-bit bytes).  TCP is used by those applications
+         needing reliable, connection-oriented transport service, e.g.,
+         mail (SMTP), file transfer (FTP), and virtual terminal service
+         (Telnet); requirements for these application-layer protocols
+         are described in [INTRO:1].
+
+      4.2.2  PROTOCOL WALK-THROUGH
+
+         4.2.2.1  Well-Known Ports: RFC-793 Section 2.7
+
+            DISCUSSION:
+                 TCP reserves port numbers in the range 0-255 for
+                 "well-known" ports, used to access services that are
+                 standardized across the Internet.  The remainder of the
+                 port space can be freely allocated to application
+                 processes.  Current well-known port definitions are
+                 listed in the RFC entitled "Assigned Numbers"
+                 [INTRO:6].  A prerequisite for defining a new well-
+                 known port is an RFC documenting the proposed service
+                 in enough detail to allow new implementations.
+
+                 Some systems extend this notion by adding a third
+                 subdivision of the TCP port space: reserved ports,
+                 which are generally used for operating-system-specific
+                 services.  For example, reserved ports might fall
+                 between 256 and some system-dependent upper limit.
+                 Some systems further choose to protect well-known and
+                 reserved ports by permitting only privileged users to
+                 open TCP connections with those port values.  This is
+                 perfectly reasonable as long as the host does not
+                 assume that all hosts protect their low-numbered ports
+                 in this manner.
+
+         4.2.2.2  Use of Push: RFC-793 Section 2.8
+
+            When an application issues a series of SEND calls without
+            setting the PUSH flag, the TCP MAY aggregate the data
+            internally without sending it.  Similarly, when a series of
+            segments is received without the PSH bit, a TCP MAY queue
+            the data internally without passing it to the receiving
+            application.
+
+
+
+Internet Engineering Task Force                                [Page 82]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+            The PSH bit is not a record marker and is independent of
+            segment boundaries.  The transmitter SHOULD collapse
+            successive PSH bits when it packetizes data, to send the
+            largest possible segment.
+
+            A TCP MAY implement PUSH flags on SEND calls.  If PUSH flags
+            are not implemented, then the sending TCP: (1) must not
+            buffer data indefinitely, and (2) MUST set the PSH bit in
+            the last buffered segment (i.e., when there is no more
+            queued data to be sent).
+
+            The discussion in RFC-793 on pages 48, 50, and 74
+            erroneously implies that a received PSH flag must be passed
+            to the application layer.  Passing a received PSH flag to
+            the application layer is now OPTIONAL.
+
+            An application program is logically required to set the PUSH
+            flag in a SEND call whenever it needs to force delivery of
+            the data to avoid a communication deadlock.  However, a TCP
+            SHOULD send a maximum-sized segment whenever possible, to
+            improve performance (see Section 4.2.3.4).
+
+            DISCUSSION:
+                 When the PUSH flag is not implemented on SEND calls,
+                 i.e., when the application/TCP interface uses a pure
+                 streaming model, responsibility for aggregating any
+                 tiny data fragments to form reasonable sized segments
+                 is partially borne by the application layer.
+
+                 Generally, an interactive application protocol must set
+                 the PUSH flag at least in the last SEND call in each
+                 command or response sequence.  A bulk transfer protocol
+                 like FTP should set the PUSH flag on the last segment
+                 of a file or when necessary to prevent buffer deadlock.
+
+                 At the receiver, the PSH bit forces buffered data to be
+                 delivered to the application (even if less than a full
+                 buffer has been received). Conversely, the lack of a
+                 PSH bit can be used to avoid unnecessary wakeup calls
+                 to the application process; this can be an important
+                 performance optimization for large timesharing hosts.
+                 Passing the PSH bit to the receiving application allows
+                 an analogous optimization within the application.
+
+         4.2.2.3  Window Size: RFC-793 Section 3.1
+
+            The window size MUST be treated as an unsigned number, or
+            else large window sizes will appear like negative windows
+
+
+
+Internet Engineering Task Force                                [Page 83]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+            and TCP will not work.  It is RECOMMENDED that
+            implementations reserve 32-bit fields for the send and
+            receive window sizes in the connection record and do all
+            window computations with 32 bits.
+
+            DISCUSSION:
+                 It is known that the window field in the TCP header is
+                 too small for high-speed, long-delay paths.
+                 Experimental TCP options have been defined to extend
+                 the window size; see for example [TCP:11].  In
+                 anticipation of the adoption of such an extension, TCP
+                 implementors should treat windows as 32 bits.
+
+         4.2.2.4  Urgent Pointer: RFC-793 Section 3.1
+
+            The second sentence is in error: the urgent pointer points
+            to the sequence number of the LAST octet (not LAST+1) in a
+            sequence of urgent data.  The description on page 56 (last
+            sentence) is correct.
+
+            A TCP MUST support a sequence of urgent data of any length.
+
+            A TCP MUST inform the application layer asynchronously
+            whenever it receives an Urgent pointer and there was
+            previously no pending urgent data, or whenever the Urgent
+            pointer advances in the data stream.  There MUST be a way
+            for the application to learn how much urgent data remains to
+            be read from the connection, or at least to determine
+            whether or not more urgent data remains to be read.
+
+            DISCUSSION:
+                 Although the Urgent mechanism may be used for any
+                 application, it is normally used to send "interrupt"-
+                 type commands to a Telnet program (see "Using Telnet
+                 Synch Sequence" section in [INTRO:1]).
+
+                 The asynchronous or "out-of-band" notification will
+                 allow the application to go into "urgent mode", reading
+                 data from the TCP connection.  This allows control
+                 commands to be sent to an application whose normal
+                 input buffers are full of unprocessed data.
+
+            IMPLEMENTATION:
+                 The generic ERROR-REPORT() upcall described in Section
+                 4.2.4.1 is a possible mechanism for informing the
+                 application of the arrival of urgent data.
+
+
+
+
+
+Internet Engineering Task Force                                [Page 84]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+         4.2.2.5  TCP Options: RFC-793 Section 3.1
+
+            A TCP MUST be able to receive a TCP option in any segment.
+            A TCP MUST ignore without error any TCP option it does not
+            implement, assuming that the option has a length field (all
+            TCP options defined in the future will have length fields).
+            TCP MUST be prepared to handle an illegal option length
+            (e.g., zero) without crashing; a suggested procedure is to
+            reset the connection and log the reason.
+
+         4.2.2.6  Maximum Segment Size Option: RFC-793 Section 3.1
+
+            TCP MUST implement both sending and receiving the Maximum
+            Segment Size option [TCP:4].
+
+            TCP SHOULD send an MSS (Maximum Segment Size) option in
+            every SYN segment when its receive MSS differs from the
+            default 536, and MAY send it always.
+
+            If an MSS option is not received at connection setup, TCP
+            MUST assume a default send MSS of 536 (576-40) [TCP:4].
+
+            The maximum size of a segment that TCP really sends, the
+            "effective send MSS," MUST be the smaller of the send MSS
+            (which reflects the available reassembly buffer size at the
+            remote host) and the largest size permitted by the IP layer:
+
+               Eff.snd.MSS =
+
+                  min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize
+
+            where:
+
+            *    SendMSS is the MSS value received from the remote host,
+                 or the default 536 if no MSS option is received.
+
+            *    MMS_S is the maximum size for a transport-layer message
+                 that TCP may send.
+
+            *    TCPhdrsize is the size of the TCP header; this is
+                 normally 20, but may be larger if TCP options are to be
+                 sent.
+
+            *    IPoptionsize is the size of any IP options that TCP
+                 will pass to the IP layer with the current message.
+
+
+            The MSS value to be sent in an MSS option must be less than
+
+
+
+Internet Engineering Task Force                                [Page 85]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+            or equal to:
+
+               MMS_R - 20
+
+            where MMS_R is the maximum size for a transport-layer
+            message that can be received (and reassembled).  TCP obtains
+            MMS_R and MMS_S from the IP layer; see the generic call
+            GET_MAXSIZES in Section 3.4.
+
+            DISCUSSION:
+                 The choice of TCP segment size has a strong effect on
+                 performance.  Larger segments increase throughput by
+                 amortizing header size and per-datagram processing
+                 overhead over more data bytes; however, if the packet
+                 is so large that it causes IP fragmentation, efficiency
+                 drops sharply if any fragments are lost [IP:9].
+
+                 Some TCP implementations send an MSS option only if the
+                 destination host is on a non-connected network.
+                 However, in general the TCP layer may not have the
+                 appropriate information to make this decision, so it is
+                 preferable to leave to the IP layer the task of
+                 determining a suitable MTU for the Internet path.  We
+                 therefore recommend that TCP always send the option (if
+                 not 536) and that the IP layer determine MMS_R as
+                 specified in 3.3.3 and 3.4.  A proposed IP-layer
+                 mechanism to measure the MTU would then modify the IP
+                 layer without changing TCP.
+
+         4.2.2.7  TCP Checksum: RFC-793 Section 3.1
+
+            Unlike the UDP checksum (see Section 4.1.3.4), the TCP
+            checksum is never optional.  The sender MUST generate it and
+            the receiver MUST check it.
+
+         4.2.2.8  TCP Connection State Diagram: RFC-793 Section 3.2,
+            page 23
+
+            There are several problems with this diagram:
+
+            (a)  The arrow from SYN-SENT to SYN-RCVD should be labeled
+                 with "snd SYN,ACK", to agree with the text on page 68
+                 and with Figure 8.
+
+            (b)  There could be an arrow from SYN-RCVD state to LISTEN
+                 state, conditioned on receiving a RST after a passive
+                 open (see text page 70).
+
+
+
+
+Internet Engineering Task Force                                [Page 86]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+            (c)  It is possible to go directly from FIN-WAIT-1 to the
+                 TIME-WAIT state (see page 75 of the spec).
+
+
+         4.2.2.9  Initial Sequence Number Selection: RFC-793 Section
+            3.3, page 27
+
+            A TCP MUST use the specified clock-driven selection of
+            initial sequence numbers.
+
+         4.2.2.10  Simultaneous Open Attempts: RFC-793 Section 3.4, page
+            32
+
+            There is an error in Figure 8: the packet on line 7 should
+            be identical to the packet on line 5.
+
+            A TCP MUST support simultaneous open attempts.
+
+            DISCUSSION:
+                 It sometimes surprises implementors that if two
+                 applications attempt to simultaneously connect to each
+                 other, only one connection is generated instead of two.
+                 This was an intentional design decision; don't try to
+                 "fix" it.
+
+         4.2.2.11  Recovery from Old Duplicate SYN: RFC-793 Section 3.4,
+            page 33
+
+            Note that a TCP implementation MUST keep track of whether a
+            connection has reached SYN_RCVD state as the result of a
+            passive OPEN or an active OPEN.
+
+         4.2.2.12  RST Segment: RFC-793 Section 3.4
+
+            A TCP SHOULD allow a received RST segment to include data.
+
+            DISCUSSION
+                 It has been suggested that a RST segment could contain
+                 ASCII text that encoded and explained the cause of the
+                 RST.  No standard has yet been established for such
+                 data.
+
+         4.2.2.13  Closing a Connection: RFC-793 Section 3.5
+
+            A TCP connection may terminate in two ways: (1) the normal
+            TCP close sequence using a FIN handshake, and (2) an "abort"
+            in which one or more RST segments are sent and the
+            connection state is immediately discarded.  If a TCP
+
+
+
+Internet Engineering Task Force                                [Page 87]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+            connection is closed by the remote site, the local
+            application MUST be informed whether it closed normally or
+            was aborted.
+
+            The normal TCP close sequence delivers buffered data
+            reliably in both directions.  Since the two directions of a
+            TCP connection are closed independently, it is possible for
+            a connection to be "half closed," i.e., closed in only one
+            direction, and a host is permitted to continue sending data
+            in the open direction on a half-closed connection.
+
+            A host MAY implement a "half-duplex" TCP close sequence, so
+            that an application that has called CLOSE cannot continue to
+            read data from the connection.  If such a host issues a
+            CLOSE call while received data is still pending in TCP, or
+            if new data is received after CLOSE is called, its TCP
+            SHOULD send a RST to show that data was lost.
+
+            When a connection is closed actively, it MUST linger in
+            TIME-WAIT state for a time 2xMSL (Maximum Segment Lifetime).
+            However, it MAY accept a new SYN from the remote TCP to
+            reopen the connection directly from TIME-WAIT state, if it:
+
+            (1)  assigns its initial sequence number for the new
+                 connection to be larger than the largest sequence
+                 number it used on the previous connection incarnation,
+                 and
+
+            (2)  returns to TIME-WAIT state if the SYN turns out to be
+                 an old duplicate.
+
+
+            DISCUSSION:
+                 TCP's full-duplex data-preserving close is a feature
+                 that is not included in the analogous ISO transport
+                 protocol TP4.
+
+                 Some systems have not implemented half-closed
+                 connections, presumably because they do not fit into
+                 the I/O model of their particular operating system.  On
+                 these systems, once an application has called CLOSE, it
+                 can no longer read input data from the connection; this
+                 is referred to as a "half-duplex" TCP close sequence.
+
+                 The graceful close algorithm of TCP requires that the
+                 connection state remain defined on (at least)  one end
+                 of the connection, for a timeout period of 2xMSL, i.e.,
+                 4 minutes.  During this period, the (remote socket,
+
+
+
+Internet Engineering Task Force                                [Page 88]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                 local socket) pair that defines the connection is busy
+                 and cannot be reused.  To shorten the time that a given
+                 port pair is tied up, some TCPs allow a new SYN to be
+                 accepted in TIME-WAIT state.
+
+         4.2.2.14  Data Communication: RFC-793 Section 3.7, page 40
+
+            Since RFC-793 was written, there has been extensive work on
+            TCP algorithms to achieve efficient data communication.
+            Later sections of the present document describe required and
+            recommended TCP algorithms to determine when to send data
+            (Section 4.2.3.4), when to send an acknowledgment (Section
+            4.2.3.2), and when to update the window (Section 4.2.3.3).
+
+            DISCUSSION:
+                 One important performance issue is "Silly Window
+                 Syndrome" or "SWS" [TCP:5], a stable pattern of small
+                 incremental window movements resulting in extremely
+                 poor TCP performance.  Algorithms to avoid SWS are
+                 described below for both the sending side (Section
+                 4.2.3.4) and the receiving side (Section 4.2.3.3).
+
+                 In brief, SWS is caused by the receiver advancing the
+                 right window edge whenever it has any new buffer space
+                 available to receive data and by the sender using any
+                 incremental window, no matter how small, to send more
+                 data [TCP:5].  The result can be a stable pattern of
+                 sending tiny data segments, even though both sender and
+                 receiver have a large total buffer space for the
+                 connection.  SWS can only occur during the transmission
+                 of a large amount of data; if the connection goes
+                 quiescent, the problem will disappear.  It is caused by
+                 typical straightforward implementation of window
+                 management, but the sender and receiver algorithms
+                 given below will avoid it.
+
+                 Another important TCP performance issue is that some
+                 applications, especially remote login to character-at-
+                 a-time hosts, tend to send streams of one-octet data
+                 segments.  To avoid deadlocks, every TCP SEND call from
+                 such applications must be "pushed", either explicitly
+                 by the application or else implicitly by TCP.  The
+                 result may be a stream of TCP segments that contain one
+                 data octet each, which makes very inefficient use of
+                 the Internet and contributes to Internet congestion.
+                 The Nagle Algorithm described in Section 4.2.3.4
+                 provides a simple and effective solution to this
+                 problem.  It does have the effect of clumping
+
+
+
+Internet Engineering Task Force                                [Page 89]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                 characters over Telnet connections; this may initially
+                 surprise users accustomed to single-character echo, but
+                 user acceptance has not been a problem.
+
+                 Note that the Nagle algorithm and the send SWS
+                 avoidance algorithm play complementary roles in
+                 improving performance.  The Nagle algorithm discourages
+                 sending tiny segments when the data to be sent
+                 increases in small increments, while the SWS avoidance
+                 algorithm discourages small segments resulting from the
+                 right window edge advancing in small increments.
+
+                 A careless implementation can send two or more
+                 acknowledgment segments per data segment received.  For
+                 example, suppose the receiver acknowledges every data
+                 segment immediately.  When the application program
+                 subsequently consumes the data and increases the
+                 available receive buffer space again, the receiver may
+                 send a second acknowledgment segment to update the
+                 window at the sender.  The extreme case occurs with
+                 single-character segments on TCP connections using the
+                 Telnet protocol for remote login service.  Some
+                 implementations have been observed in which each
+                 incoming 1-character segment generates three return
+                 segments: (1) the acknowledgment, (2) a one byte
+                 increase in the window, and (3) the echoed character,
+                 respectively.
+
+         4.2.2.15  Retransmission Timeout: RFC-793 Section 3.7, page 41
+
+            The algorithm suggested in RFC-793 for calculating the
+            retransmission timeout is now known to be inadequate; see
+            Section 4.2.3.1 below.
+
+            Recent work by Jacobson [TCP:7] on Internet congestion and
+            TCP retransmission stability has produced a transmission
+            algorithm combining "slow start" with "congestion
+            avoidance".  A TCP MUST implement this algorithm.
+
+            If a retransmitted packet is identical to the original
+            packet (which implies not only that the data boundaries have
+            not changed, but also that the window and acknowledgment
+            fields of the header have not changed), then the same IP
+            Identification field MAY be used (see Section 3.2.1.5).
+
+            IMPLEMENTATION:
+                 Some TCP implementors have chosen to "packetize" the
+                 data stream, i.e., to pick segment boundaries when
+
+
+
+Internet Engineering Task Force                                [Page 90]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                 segments are originally sent and to queue these
+                 segments in a "retransmission queue" until they are
+                 acknowledged.  Another design (which may be simpler) is
+                 to defer packetizing until each time data is
+                 transmitted or retransmitted, so there will be no
+                 segment retransmission queue.
+
+                 In an implementation with a segment retransmission
+                 queue, TCP performance may be enhanced by repacketizing
+                 the segments awaiting acknowledgment when the first
+                 retransmission timeout occurs.  That is, the
+                 outstanding segments that fitted would be combined into
+                 one maximum-sized segment, with a new IP Identification
+                 value.  The TCP would then retain this combined segment
+                 in the retransmit queue until it was acknowledged.
+                 However, if the first two segments in the
+                 retransmission queue totalled more than one maximum-
+                 sized segment, the TCP would retransmit only the first
+                 segment using the original IP Identification field.
+
+         4.2.2.16  Managing the Window: RFC-793 Section 3.7, page 41
+
+            A TCP receiver SHOULD NOT shrink the window, i.e., move the
+            right window edge to the left.  However, a sending TCP MUST
+            be robust against window shrinking, which may cause the
+            "useable window" (see Section 4.2.3.4) to become negative.
+
+            If this happens, the sender SHOULD NOT send new data, but
+            SHOULD retransmit normally the old unacknowledged data
+            between SND.UNA and SND.UNA+SND.WND.  The sender MAY also
+            retransmit old data beyond SND.UNA+SND.WND, but SHOULD NOT
+            time out the connection if data beyond the right window edge
+            is not acknowledged.  If the window shrinks to zero, the TCP
+            MUST probe it in the standard way (see next Section).
+
+            DISCUSSION:
+                 Many TCP implementations become confused if the window
+                 shrinks from the right after data has been sent into a
+                 larger window.  Note that TCP has a heuristic to select
+                 the latest window update despite possible datagram
+                 reordering; as a result, it may ignore a window update
+                 with a smaller window than previously offered if
+                 neither the sequence number nor the acknowledgment
+                 number is increased.
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 91]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+         4.2.2.17  Probing Zero Windows: RFC-793 Section 3.7, page 42
+
+            Probing of zero (offered) windows MUST be supported.
+
+            A TCP MAY keep its offered receive window closed
+            indefinitely.  As long as the receiving TCP continues to
+            send acknowledgments in response to the probe segments, the
+            sending TCP MUST allow the connection to stay open.
+
+            DISCUSSION:
+                 It is extremely important to remember that ACK
+                 (acknowledgment) segments that contain no data are not
+                 reliably transmitted by TCP.  If zero window probing is
+                 not supported, a connection may hang forever when an
+                 ACK segment that re-opens the window is lost.
+
+                 The delay in opening a zero window generally occurs
+                 when the receiving application stops taking data from
+                 its TCP.  For example, consider a printer daemon
+                 application, stopped because the printer ran out of
+                 paper.
+
+            The transmitting host SHOULD send the first zero-window
+            probe when a zero window has existed for the retransmission
+            timeout period (see Section 4.2.2.15), and SHOULD increase
+            exponentially the interval between successive probes.
+
+            DISCUSSION:
+                 This procedure minimizes delay if the zero-window
+                 condition is due to a lost ACK segment containing a
+                 window-opening update.  Exponential backoff is
+                 recommended, possibly with some maximum interval not
+                 specified here.  This procedure is similar to that of
+                 the retransmission algorithm, and it may be possible to
+                 combine the two procedures in the implementation.
+
+         4.2.2.18  Passive OPEN Calls:  RFC-793 Section 3.8
+
+            Every passive OPEN call either creates a new connection
+            record in LISTEN state, or it returns an error; it MUST NOT
+            affect any previously created connection record.
+
+            A TCP that supports multiple concurrent users MUST provide
+            an OPEN call that will functionally allow an application to
+            LISTEN on a port while a connection block with the same
+            local port is in SYN-SENT or SYN-RECEIVED state.
+
+            DISCUSSION:
+
+
+
+Internet Engineering Task Force                                [Page 92]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                 Some applications (e.g., SMTP servers) may need to
+                 handle multiple connection attempts at about the same
+                 time.  The probability of a connection attempt failing
+                 is reduced by giving the application some means of
+                 listening for a new connection at the same time that an
+                 earlier connection attempt is going through the three-
+                 way handshake.
+
+            IMPLEMENTATION:
+                 Acceptable implementations of concurrent opens may
+                 permit multiple passive OPEN calls, or they may allow
+                 "cloning" of LISTEN-state connections from a single
+                 passive OPEN call.
+
+         4.2.2.19  Time to Live: RFC-793 Section 3.9, page 52
+
+            RFC-793 specified that TCP was to request the IP layer to
+            send TCP segments with TTL = 60.  This is obsolete; the TTL
+            value used to send TCP segments MUST be configurable.  See
+            Section 3.2.1.7 for discussion.
+
+         4.2.2.20  Event Processing: RFC-793 Section 3.9
+
+            While it is not strictly required, a TCP SHOULD be capable
+            of queueing out-of-order TCP segments.  Change the "may" in
+            the last sentence of the first paragraph on page 70 to
+            "should".
+
+            DISCUSSION:
+                 Some small-host implementations have omitted segment
+                 queueing because of limited buffer space.  This
+                 omission may be expected to adversely affect TCP
+                 throughput, since loss of a single segment causes all
+                 later segments to appear to be "out of sequence".
+
+            In general, the processing of received segments MUST be
+            implemented to aggregate ACK segments whenever possible.
+            For example, if the TCP is processing a series of queued
+            segments, it MUST process them all before sending any ACK
+            segments.
+
+            Here are some detailed error corrections and notes on the
+            Event Processing section of RFC-793.
+
+            (a)  CLOSE Call, CLOSE-WAIT state, p. 61: enter LAST-ACK
+                 state, not CLOSING.
+
+            (b)  LISTEN state, check for SYN (pp. 65, 66): With a SYN
+
+
+
+Internet Engineering Task Force                                [Page 93]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                 bit, if the security/compartment or the precedence is
+                 wrong for the segment, a reset is sent.  The wrong form
+                 of reset is shown in the text; it should be:
+
+                   <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
+
+
+            (c)  SYN-SENT state, Check for SYN, p. 68: When the
+                 connection enters ESTABLISHED state, the following
+                 variables must be set:
+                    SND.WND <- SEG.WND
+                    SND.WL1 <- SEG.SEQ
+                    SND.WL2 <- SEG.ACK
+
+
+            (d)  Check security and precedence, p. 71: The first heading
+                 "ESTABLISHED STATE" should really be a list of all
+                 states other than SYN-RECEIVED: ESTABLISHED, FIN-WAIT-
+                 1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, and
+                 TIME-WAIT.
+
+            (e)  Check SYN bit, p. 71:  "In SYN-RECEIVED state and if
+                 the connection was initiated with a passive OPEN, then
+                 return this connection to the LISTEN state and return.
+                 Otherwise...".
+
+            (f)  Check ACK field, SYN-RECEIVED state, p. 72: When the
+                 connection enters ESTABLISHED state, the variables
+                 listed in (c) must be set.
+
+            (g)  Check ACK field, ESTABLISHED state, p. 72: The ACK is a
+                 duplicate if SEG.ACK =< SND.UNA (the = was omitted).
+                 Similarly, the window should be updated if: SND.UNA =<
+                 SEG.ACK =< SND.NXT.
+
+            (h)  USER TIMEOUT, p. 77:
+
+                 It would be better to notify the application of the
+                 timeout rather than letting TCP force the connection
+                 closed.  However, see also Section 4.2.3.5.
+
+
+         4.2.2.21  Acknowledging Queued Segments: RFC-793 Section 3.9
+
+            A TCP MAY send an ACK segment acknowledging RCV.NXT when a
+            valid segment arrives that is in the window but not at the
+            left window edge.
+
+
+
+
+Internet Engineering Task Force                                [Page 94]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+            DISCUSSION:
+                 RFC-793 (see page 74) was ambiguous about whether or
+                 not an ACK segment should be sent when an out-of-order
+                 segment was received, i.e., when SEG.SEQ was unequal to
+                 RCV.NXT.
+
+                 One reason for ACKing out-of-order segments might be to
+                 support an experimental algorithm known as "fast
+                 retransmit".   With this algorithm, the sender uses the
+                 "redundant" ACK's to deduce that a segment has been
+                 lost before the retransmission timer has expired.  It
+                 counts the number of times an ACK has been received
+                 with the same value of SEG.ACK and with the same right
+                 window edge.  If more than a threshold number of such
+                 ACK's is received, then the segment containing the
+                 octets starting at SEG.ACK is assumed to have been lost
+                 and is retransmitted, without awaiting a timeout.  The
+                 threshold is chosen to compensate for the maximum
+                 likely segment reordering in the Internet.  There is
+                 not yet enough experience with the fast retransmit
+                 algorithm to determine how useful it is.
+
+      4.2.3  SPECIFIC ISSUES
+
+         4.2.3.1  Retransmission Timeout Calculation
+
+            A host TCP MUST implement Karn's algorithm and Jacobson's
+            algorithm for computing the retransmission timeout ("RTO").
+
+            o    Jacobson's algorithm for computing the smoothed round-
+                 trip ("RTT") time incorporates a simple measure of the
+                 variance [TCP:7].
+
+            o    Karn's algorithm for selecting RTT measurements ensures
+                 that ambiguous round-trip times will not corrupt the
+                 calculation of the smoothed round-trip time [TCP:6].
+
+            This implementation also MUST include "exponential backoff"
+            for successive RTO values for the same segment.
+            Retransmission of SYN segments SHOULD use the same algorithm
+            as data segments.
+
+            DISCUSSION:
+                 There were two known problems with the RTO calculations
+                 specified in RFC-793.  First, the accurate measurement
+                 of RTTs is difficult when there are retransmissions.
+                 Second, the algorithm to compute the smoothed round-
+                 trip time is inadequate [TCP:7], because it incorrectly
+
+
+
+Internet Engineering Task Force                                [Page 95]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                 assumed that the variance in RTT values would be small
+                 and constant.  These problems were solved by Karn's and
+                 Jacobson's algorithm, respectively.
+
+                 The performance increase resulting from the use of
+                 these improvements varies from noticeable to dramatic.
+                 Jacobson's algorithm for incorporating the measured RTT
+                 variance is especially important on a low-speed link,
+                 where the natural variation of packet sizes causes a
+                 large variation in RTT.  One vendor found link
+                 utilization on a 9.6kb line went from 10% to 90% as a
+                 result of implementing Jacobson's variance algorithm in
+                 TCP.
+
+            The following values SHOULD be used to initialize the
+            estimation parameters for a new connection:
+
+            (a)  RTT = 0 seconds.
+
+            (b)  RTO = 3 seconds.  (The smoothed variance is to be
+                 initialized to the value that will result in this RTO).
+
+            The recommended upper and lower bounds on the RTO are known
+            to be inadequate on large internets.  The lower bound SHOULD
+            be measured in fractions of a second (to accommodate high
+            speed LANs) and the upper bound should be 2*MSL, i.e., 240
+            seconds.
+
+            DISCUSSION:
+                 Experience has shown that these initialization values
+                 are reasonable, and that in any case the Karn and
+                 Jacobson algorithms make TCP behavior reasonably
+                 insensitive to the initial parameter choices.
+
+         4.2.3.2  When to Send an ACK Segment
+
+            A host that is receiving a stream of TCP data segments can
+            increase efficiency in both the Internet and the hosts by
+            sending fewer than one ACK (acknowledgment) segment per data
+            segment received; this is known as a "delayed ACK" [TCP:5].
+
+            A TCP SHOULD implement a delayed ACK, but an ACK should not
+            be excessively delayed; in particular, the delay MUST be
+            less than 0.5 seconds, and in a stream of full-sized
+            segments there SHOULD be an ACK for at least every second
+            segment.
+
+            DISCUSSION:
+
+
+
+Internet Engineering Task Force                                [Page 96]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                 A delayed ACK gives the application an opportunity to
+                 update the window and perhaps to send an immediate
+                 response.  In particular, in the case of character-mode
+                 remote login, a delayed ACK can reduce the number of
+                 segments sent by the server by a factor of 3 (ACK,
+                 window update, and echo character all combined in one
+                 segment).
+
+                 In addition, on some large multi-user hosts, a delayed
+                 ACK can substantially reduce protocol processing
+                 overhead by reducing the total number of packets to be
+                 processed [TCP:5].  However, excessive delays on ACK's
+                 can disturb the round-trip timing and packet "clocking"
+                 algorithms [TCP:7].
+
+         4.2.3.3  When to Send a Window Update
+
+            A TCP MUST include a SWS avoidance algorithm in the receiver
+            [TCP:5].
+
+            IMPLEMENTATION:
+                 The receiver's SWS avoidance algorithm determines when
+                 the right window edge may be advanced; this is
+                 customarily known as "updating the window".  This
+                 algorithm combines with the delayed ACK algorithm (see
+                 Section 4.2.3.2) to determine when an ACK segment
+                 containing the current window will really be sent to
+                 the receiver.  We use the notation of RFC-793; see
+                 Figures 4 and 5 in that document.
+
+                 The solution to receiver SWS is to avoid advancing the
+                 right window edge RCV.NXT+RCV.WND in small increments,
+                 even if data is received from the network in small
+                 segments.
+
+                 Suppose the total receive buffer space is RCV.BUFF.  At
+                 any given moment, RCV.USER octets of this total may be
+                 tied up with data that has been received and
+                 acknowledged but which the user process has not yet
+                 consumed.  When the connection is quiescent, RCV.WND =
+                 RCV.BUFF and RCV.USER = 0.
+
+                 Keeping the right window edge fixed as data arrives and
+                 is acknowledged requires that the receiver offer less
+                 than its full buffer space, i.e., the receiver must
+                 specify a RCV.WND that keeps RCV.NXT+RCV.WND constant
+                 as RCV.NXT increases.  Thus, the total buffer space
+                 RCV.BUFF is generally divided into three parts:
+
+
+
+Internet Engineering Task Force                                [Page 97]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+
+                 |<------- RCV.BUFF ---------------->|
+                      1             2            3
+             ----|---------|------------------|------|----
+                        RCV.NXT               ^
+                                           (Fixed)
+
+             1 - RCV.USER =  data received but not yet consumed;
+             2 - RCV.WND =   space advertised to sender;
+             3 - Reduction = space available but not yet
+                             advertised.
+
+
+                 The suggested SWS avoidance algorithm for the receiver
+                 is to keep RCV.NXT+RCV.WND fixed until the reduction
+                 satisfies:
+
+                      RCV.BUFF - RCV.USER - RCV.WND  >=
+
+                             min( Fr * RCV.BUFF, Eff.snd.MSS )
+
+                 where Fr is a fraction whose recommended value is 1/2,
+                 and Eff.snd.MSS is the effective send MSS for the
+                 connection (see Section 4.2.2.6).  When the inequality
+                 is satisfied, RCV.WND is set to RCV.BUFF-RCV.USER.
+
+                 Note that the general effect of this algorithm is to
+                 advance RCV.WND in increments of Eff.snd.MSS (for
+                 realistic receive buffers:  Eff.snd.MSS < RCV.BUFF/2).
+                 Note also that the receiver must use its own
+                 Eff.snd.MSS, assuming it is the same as the sender's.
+
+         4.2.3.4  When to Send Data
+
+            A TCP MUST include a SWS avoidance algorithm in the sender.
+
+            A TCP SHOULD implement the Nagle Algorithm [TCP:9] to
+            coalesce short segments.  However, there MUST be a way for
+            an application to disable the Nagle algorithm on an
+            individual connection.  In all cases, sending data is also
+            subject to the limitation imposed by the Slow Start
+            algorithm (Section 4.2.2.15).
+
+            DISCUSSION:
+                 The Nagle algorithm is generally as follows:
+
+                      If there is unacknowledged data (i.e., SND.NXT >
+                      SND.UNA), then the sending TCP buffers all user
+
+
+
+Internet Engineering Task Force                                [Page 98]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                      data (regardless of the PSH bit), until the
+                      outstanding data has been acknowledged or until
+                      the TCP can send a full-sized segment (Eff.snd.MSS
+                      bytes; see Section 4.2.2.6).
+
+                 Some applications (e.g., real-time display window
+                 updates) require that the Nagle algorithm be turned
+                 off, so small data segments can be streamed out at the
+                 maximum rate.
+
+            IMPLEMENTATION:
+                 The sender's SWS avoidance algorithm is more difficult
+                 than the receivers's, because the sender does not know
+                 (directly) the receiver's total buffer space RCV.BUFF.
+                 An approach which has been found to work well is for
+                 the sender to calculate Max(SND.WND), the maximum send
+                 window it has seen so far on the connection, and to use
+                 this value as an estimate of RCV.BUFF.  Unfortunately,
+                 this can only be an estimate; the receiver may at any
+                 time reduce the size of RCV.BUFF.  To avoid a resulting
+                 deadlock, it is necessary to have a timeout to force
+                 transmission of data, overriding the SWS avoidance
+                 algorithm.  In practice, this timeout should seldom
+                 occur.
+
+                 The "useable window" [TCP:5] is:
+
+                      U = SND.UNA + SND.WND - SND.NXT
+
+                 i.e., the offered window less the amount of data sent
+                 but not acknowledged.  If D is the amount of data
+                 queued in the sending TCP but not yet sent, then the
+                 following set of rules is recommended.
+
+                 Send data:
+
+                 (1)  if a maximum-sized segment can be sent, i.e, if:
+
+                           min(D,U) >= Eff.snd.MSS;
+
+
+                 (2)  or if the data is pushed and all queued data can
+                      be sent now, i.e., if:
+
+                          [SND.NXT = SND.UNA and] PUSHED and D <= U
+
+                      (the bracketed condition is imposed by the Nagle
+                      algorithm);
+
+
+
+Internet Engineering Task Force                                [Page 99]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                 (3)  or if at least a fraction Fs of the maximum window
+                      can be sent, i.e., if:
+
+                          [SND.NXT = SND.UNA and]
+
+                                  min(D.U) >= Fs * Max(SND.WND);
+
+
+                 (4)  or if data is PUSHed and the override timeout
+                      occurs.
+
+                 Here Fs is a fraction whose recommended value is 1/2.
+                 The override timeout should be in the range 0.1 - 1.0
+                 seconds.  It may be convenient to combine this timer
+                 with the timer used to probe zero windows (Section
+                 4.2.2.17).
+
+                 Finally, note that the SWS avoidance algorithm just
+                 specified is to be used instead of the sender-side
+                 algorithm contained in [TCP:5].
+
+         4.2.3.5  TCP Connection Failures
+
+            Excessive retransmission of the same segment by TCP
+            indicates some failure of the remote host or the Internet
+            path.  This failure may be of short or long duration.  The
+            following procedure MUST be used to handle excessive
+            retransmissions of data segments [IP:11]:
+
+            (a)  There are two thresholds R1 and R2 measuring the amount
+                 of retransmission that has occurred for the same
+                 segment.  R1 and R2 might be measured in time units or
+                 as a count of retransmissions.
+
+            (b)  When the number of transmissions of the same segment
+                 reaches or exceeds threshold R1, pass negative advice
+                 (see Section 3.3.1.4) to the IP layer, to trigger
+                 dead-gateway diagnosis.
+
+            (c)  When the number of transmissions of the same segment
+                 reaches a threshold R2 greater than R1, close the
+                 connection.
+
+            (d)  An application MUST be able to set the value for R2 for
+                 a particular connection.  For example, an interactive
+                 application might set R2 to "infinity," giving the user
+                 control over when to disconnect.
+
+
+
+
+Internet Engineering Task Force                               [Page 100]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+            (d)  TCP SHOULD inform the application of the delivery
+                 problem (unless such information has been disabled by
+                 the application; see Section 4.2.4.1), when R1 is
+                 reached and before R2.  This will allow a remote login
+                 (User Telnet) application program to inform the user,
+                 for example.
+
+            The value of R1 SHOULD correspond to at least 3
+            retransmissions, at the current RTO.  The value of R2 SHOULD
+            correspond to at least 100 seconds.
+
+            An attempt to open a TCP connection could fail with
+            excessive retransmissions of the SYN segment or by receipt
+            of a RST segment or an ICMP Port Unreachable.  SYN
+            retransmissions MUST be handled in the general way just
+            described for data retransmissions, including notification
+            of the application layer.
+
+            However, the values of R1 and R2 may be different for SYN
+            and data segments.  In particular, R2 for a SYN segment MUST
+            be set large enough to provide retransmission of the segment
+            for at least 3 minutes.  The application can close the
+            connection (i.e., give up on the open attempt) sooner, of
+            course.
+
+            DISCUSSION:
+                 Some Internet paths have significant setup times, and
+                 the number of such paths is likely to increase in the
+                 future.
+
+         4.2.3.6  TCP Keep-Alives
+
+            Implementors MAY include "keep-alives" in their TCP
+            implementations, although this practice is not universally
+            accepted.  If keep-alives are included, the application MUST
+            be able to turn them on or off for each TCP connection, and
+            they MUST default to off.
+
+            Keep-alive packets MUST only be sent when no data or
+            acknowledgement packets have been received for the
+            connection within an interval.  This interval MUST be
+            configurable and MUST default to no less than two hours.
+
+            It is extremely important to remember that ACK segments that
+            contain no data are not reliably transmitted by TCP.
+            Consequently, if a keep-alive mechanism is implemented it
+            MUST NOT interpret failure to respond to any specific probe
+            as a dead connection.
+
+
+
+Internet Engineering Task Force                               [Page 101]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+            An implementation SHOULD send a keep-alive segment with no
+            data; however, it MAY be configurable to send a keep-alive
+            segment containing one garbage octet, for compatibility with
+            erroneous TCP implementations.
+
+            DISCUSSION:
+                 A "keep-alive" mechanism periodically probes the other
+                 end of a connection when the connection is otherwise
+                 idle, even when there is no data to be sent.  The TCP
+                 specification does not include a keep-alive mechanism
+                 because it could:  (1) cause perfectly good connections
+                 to break during transient Internet failures; (2)
+                 consume unnecessary bandwidth ("if no one is using the
+                 connection, who cares if it is still good?"); and (3)
+                 cost money for an Internet path that charges for
+                 packets.
+
+                 Some TCP implementations, however, have included a
+                 keep-alive mechanism.  To confirm that an idle
+                 connection is still active, these implementations send
+                 a probe segment designed to elicit a response from the
+                 peer TCP.  Such a segment generally contains SEG.SEQ =
+                 SND.NXT-1 and may or may not contain one garbage octet
+                 of data.  Note that on a quiet connection SND.NXT =
+                 RCV.NXT, so that this SEG.SEQ will be outside the
+                 window.  Therefore, the probe causes the receiver to
+                 return an acknowledgment segment, confirming that the
+                 connection is still live.  If the peer has dropped the
+                 connection due to a network partition or a crash, it
+                 will respond with a RST instead of an acknowledgment
+                 segment.
+
+                 Unfortunately, some misbehaved TCP implementations fail
+                 to respond to a segment with SEG.SEQ = SND.NXT-1 unless
+                 the segment contains data.  Alternatively, an
+                 implementation could determine whether a peer responded
+                 correctly to keep-alive packets with no garbage data
+                 octet.
+
+                 A TCP keep-alive mechanism should only be invoked in
+                 server applications that might otherwise hang
+                 indefinitely and consume resources unnecessarily if a
+                 client crashes or aborts a connection during a network
+                 failure.
+
+
+
+
+
+
+
+Internet Engineering Task Force                               [Page 102]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+         4.2.3.7  TCP Multihoming
+
+            If an application on a multihomed host does not specify the
+            local IP address when actively opening a TCP connection,
+            then the TCP MUST ask the IP layer to select a local IP
+            address before sending the (first) SYN.  See the function
+            GET_SRCADDR() in Section 3.4.
+
+            At all other times, a previous segment has either been sent
+            or received on this connection, and TCP MUST use the same
+            local address is used that was used in those previous
+            segments.
+
+         4.2.3.8  IP Options
+
+            When received options are passed up to TCP from the IP
+            layer, TCP MUST ignore options that it does not understand.
+
+            A TCP MAY support the Time Stamp and Record Route options.
+
+            An application MUST be able to specify a source route when
+            it actively opens a TCP connection, and this MUST take
+            precedence over a source route received in a datagram.
+
+            When a TCP connection is OPENed passively and a packet
+            arrives with a completed IP Source Route option (containing
+            a return route), TCP MUST save the return route and use it
+            for all segments sent on this connection.  If a different
+            source route arrives in a later segment, the later
+            definition SHOULD override the earlier one.
+
+         4.2.3.9  ICMP Messages
+
+            TCP MUST act on an ICMP error message passed up from the IP
+            layer, directing it to the connection that created the
+            error.  The necessary demultiplexing information can be
+            found in the IP header contained within the ICMP message.
+
+            o    Source Quench
+
+                 TCP MUST react to a Source Quench by slowing
+                 transmission on the connection.  The RECOMMENDED
+                 procedure is for a Source Quench to trigger a "slow
+                 start," as if a retransmission timeout had occurred.
+
+            o    Destination Unreachable -- codes 0, 1, 5
+
+                 Since these Unreachable messages indicate soft error
+
+
+
+Internet Engineering Task Force                               [Page 103]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                 conditions, TCP MUST NOT abort the connection, and it
+                 SHOULD make the information available to the
+                 application.
+
+                 DISCUSSION:
+                      TCP could report the soft error condition directly
+                      to the application layer with an upcall to the
+                      ERROR_REPORT routine, or it could merely note the
+                      message and report it to the application only when
+                      and if the TCP connection times out.
+
+            o    Destination Unreachable -- codes 2-4
+
+                 These are hard error conditions, so TCP SHOULD abort
+                 the connection.
+
+            o    Time Exceeded -- codes 0, 1
+
+                 This should be handled the same way as Destination
+                 Unreachable codes 0, 1, 5 (see above).
+
+            o    Parameter Problem
+
+                 This should be handled the same way as Destination
+                 Unreachable codes 0, 1, 5 (see above).
+
+
+         4.2.3.10  Remote Address Validation
+
+            A TCP implementation MUST reject as an error a local OPEN
+            call for an invalid remote IP address (e.g., a broadcast or
+            multicast address).
+
+            An incoming SYN with an invalid source address must be
+            ignored either by TCP or by the IP layer (see Section
+            3.2.1.3).
+
+            A TCP implementation MUST silently discard an incoming SYN
+            segment that is addressed to a broadcast or multicast
+            address.
+
+         4.2.3.11  TCP Traffic Patterns
+
+            IMPLEMENTATION:
+                 The TCP protocol specification [TCP:1] gives the
+                 implementor much freedom in designing the algorithms
+                 that control the message flow over the connection --
+                 packetizing, managing the window, sending
+
+
+
+Internet Engineering Task Force                               [Page 104]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                 acknowledgments, etc.  These design decisions are
+                 difficult because a TCP must adapt to a wide range of
+                 traffic patterns.  Experience has shown that a TCP
+                 implementor needs to verify the design on two extreme
+                 traffic patterns:
+
+                 o    Single-character Segments
+
+                      Even if the sender is using the Nagle Algorithm,
+                      when a TCP connection carries remote login traffic
+                      across a low-delay LAN the receiver will generally
+                      get a stream of single-character segments.  If
+                      remote terminal echo mode is in effect, the
+                      receiver's system will generally echo each
+                      character as it is received.
+
+                 o    Bulk Transfer
+
+                      When TCP is used for bulk transfer, the data
+                      stream should be made up (almost) entirely of
+                      segments of the size of the effective MSS.
+                      Although TCP uses a sequence number space with
+                      byte (octet) granularity, in bulk-transfer mode
+                      its operation should be as if TCP used a sequence
+                      space that counted only segments.
+
+                 Experience has furthermore shown that a single TCP can
+                 effectively and efficiently handle these two extremes.
+
+                 The most important tool for verifying a new TCP
+                 implementation is a packet trace program.  There is a
+                 large volume of experience showing the importance of
+                 tracing a variety of traffic patterns with other TCP
+                 implementations and studying the results carefully.
+
+
+         4.2.3.12  Efficiency
+
+            IMPLEMENTATION:
+                 Extensive experience has led to the following
+                 suggestions for efficient implementation of TCP:
+
+                 (a)  Don't Copy Data
+
+                      In bulk data transfer, the primary CPU-intensive
+                      tasks are copying data from one place to another
+                      and checksumming the data.  It is vital to
+                      minimize the number of copies of TCP data.  Since
+
+
+
+Internet Engineering Task Force                               [Page 105]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                      the ultimate speed limitation may be fetching data
+                      across the memory bus, it may be useful to combine
+                      the copy with checksumming, doing both with a
+                      single memory fetch.
+
+                 (b)  Hand-Craft the Checksum Routine
+
+                      A good TCP checksumming routine is typically two
+                      to five times faster than a simple and direct
+                      implementation of the definition.  Great care and
+                      clever coding are often required and advisable to
+                      make the checksumming code "blazing fast".  See
+                      [TCP:10].
+
+                 (c)  Code for the Common Case
+
+                      TCP protocol processing can be complicated, but
+                      for most segments there are only a few simple
+                      decisions to be made.  Per-segment processing will
+                      be greatly speeded up by coding the main line to
+                      minimize the number of decisions in the most
+                      common case.
+
+
+      4.2.4  TCP/APPLICATION LAYER INTERFACE
+
+         4.2.4.1  Asynchronous Reports
+
+            There MUST be a mechanism for reporting soft TCP error
+            conditions to the application.  Generically, we assume this
+            takes the form of an application-supplied ERROR_REPORT
+            routine that may be upcalled [INTRO:7] asynchronously from
+            the transport layer:
+
+               ERROR_REPORT(local connection name, reason, subreason)
+
+            The precise encoding of the reason and subreason parameters
+            is not specified here.  However, the conditions that are
+            reported asynchronously to the application MUST include:
+
+            *    ICMP error message arrived (see 4.2.3.9)
+
+            *    Excessive retransmissions (see 4.2.3.5)
+
+            *    Urgent pointer advance (see 4.2.2.4).
+
+            However, an application program that does not want to
+            receive such ERROR_REPORT calls SHOULD be able to
+
+
+
+Internet Engineering Task Force                               [Page 106]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+            effectively disable these calls.
+
+            DISCUSSION:
+                 These error reports generally reflect soft errors that
+                 can be ignored without harm by many applications.  It
+                 has been suggested that these error report calls should
+                 default to "disabled," but this is not required.
+
+         4.2.4.2  Type-of-Service
+
+            The application layer MUST be able to specify the Type-of-
+            Service (TOS) for segments that are sent on a connection.
+            It not required, but the application SHOULD be able to
+            change the TOS during the connection lifetime.  TCP SHOULD
+            pass the current TOS value without change to the IP layer,
+            when it sends segments on the connection.
+
+            The TOS will be specified independently in each direction on
+            the connection, so that the receiver application will
+            specify the TOS used for ACK segments.
+
+            TCP MAY pass the most recently received TOS up to the
+            application.
+
+            DISCUSSION
+                 Some applications (e.g., SMTP) change the nature of
+                 their communication during the lifetime of a
+                 connection, and therefore would like to change the TOS
+                 specification.
+
+                 Note also that the OPEN call specified in RFC-793
+                 includes a parameter ("options") in which the caller
+                 can specify IP options such as source route, record
+                 route, or timestamp.
+
+         4.2.4.3  Flush Call
+
+            Some TCP implementations have included a FLUSH call, which
+            will empty the TCP send queue of any data for which the user
+            has issued SEND calls but which is still to the right of the
+            current send window.  That is, it flushes as much queued
+            send data as possible without losing sequence number
+            synchronization.  This is useful for implementing the "abort
+            output" function of Telnet.
+
+
+
+
+
+
+
+Internet Engineering Task Force                               [Page 107]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+         4.2.4.4  Multihoming
+
+            The user interface outlined in sections 2.7 and 3.8 of RFC-
+            793 needs to be extended for multihoming.  The OPEN call
+            MUST have an optional parameter:
+
+                OPEN( ... [local IP address,] ... )
+
+            to allow the specification of the local IP address.
+
+            DISCUSSION:
+                 Some TCP-based applications need to specify the local
+                 IP address to be used to open a particular connection;
+                 FTP is an example.
+
+            IMPLEMENTATION:
+                 A passive OPEN call with a specified "local IP address"
+                 parameter will await an incoming connection request to
+                 that address.  If the parameter is unspecified, a
+                 passive OPEN will await an incoming connection request
+                 to any local IP address, and then bind the local IP
+                 address of the connection to the particular address
+                 that is used.
+
+                 For an active OPEN call, a specified "local IP address"
+                 parameter will be used for opening the connection.  If
+                 the parameter is unspecified, the networking software
+                 will choose an appropriate local IP address (see
+                 Section 3.3.4.2) for the connection
+
+      4.2.5  TCP REQUIREMENT SUMMARY
+
+                                                 |        | | | |S| |
+                                                 |        | | | |H| |F
+                                                 |        | | | |O|M|o
+                                                 |        | |S| |U|U|o
+                                                 |        | |H| |L|S|t
+                                                 |        |M|O| |D|T|n
+                                                 |        |U|U|M| | |o
+                                                 |        |S|L|A|N|N|t
+                                                 |        |T|D|Y|O|O|t
+FEATURE                                          |SECTION | | | |T|T|e
+-------------------------------------------------|--------|-|-|-|-|-|--
+                                                 |        | | | | | |
+Push flag                                        |        | | | | | |
+  Aggregate or queue un-pushed data              |4.2.2.2 | | |x| | |
+  Sender collapse successive PSH flags           |4.2.2.2 | |x| | | |
+  SEND call can specify PUSH                     |4.2.2.2 | | |x| | |
+
+
+
+Internet Engineering Task Force                               [Page 108]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+    If cannot: sender buffer indefinitely        |4.2.2.2 | | | | |x|
+    If cannot: PSH last segment                  |4.2.2.2 |x| | | | |
+  Notify receiving ALP of PSH                    |4.2.2.2 | | |x| | |1
+  Send max size segment when possible            |4.2.2.2 | |x| | | |
+                                                 |        | | | | | |
+Window                                           |        | | | | | |
+  Treat as unsigned number                       |4.2.2.3 |x| | | | |
+  Handle as 32-bit number                        |4.2.2.3 | |x| | | |
+  Shrink window from right                       |4.2.2.16| | | |x| |
+  Robust against shrinking window                |4.2.2.16|x| | | | |
+  Receiver's window closed indefinitely          |4.2.2.17| | |x| | |
+  Sender probe zero window                       |4.2.2.17|x| | | | |
+    First probe after RTO                        |4.2.2.17| |x| | | |
+    Exponential backoff                          |4.2.2.17| |x| | | |
+  Allow window stay zero indefinitely            |4.2.2.17|x| | | | |
+  Sender timeout OK conn with zero wind          |4.2.2.17| | | | |x|
+                                                 |        | | | | | |
+Urgent Data                                      |        | | | | | |
+  Pointer points to last octet                   |4.2.2.4 |x| | | | |
+  Arbitrary length urgent data sequence          |4.2.2.4 |x| | | | |
+  Inform ALP asynchronously of urgent data       |4.2.2.4 |x| | | | |1
+  ALP can learn if/how much urgent data Q'd      |4.2.2.4 |x| | | | |1
+                                                 |        | | | | | |
+TCP Options                                      |        | | | | | |
+  Receive TCP option in any segment              |4.2.2.5 |x| | | | |
+  Ignore unsupported options                     |4.2.2.5 |x| | | | |
+  Cope with illegal option length                |4.2.2.5 |x| | | | |
+  Implement sending & receiving MSS option       |4.2.2.6 |x| | | | |
+  Send MSS option unless 536                     |4.2.2.6 | |x| | | |
+  Send MSS option always                         |4.2.2.6 | | |x| | |
+  Send-MSS default is 536                        |4.2.2.6 |x| | | | |
+  Calculate effective send seg size              |4.2.2.6 |x| | | | |
+                                                 |        | | | | | |
+TCP Checksums                                    |        | | | | | |
+  Sender compute checksum                        |4.2.2.7 |x| | | | |
+  Receiver check checksum                        |4.2.2.7 |x| | | | |
+                                                 |        | | | | | |
+Use clock-driven ISN selection                   |4.2.2.9 |x| | | | |
+                                                 |        | | | | | |
+Opening Connections                              |        | | | | | |
+  Support simultaneous open attempts             |4.2.2.10|x| | | | |
+  SYN-RCVD remembers last state                  |4.2.2.11|x| | | | |
+  Passive Open call interfere with others        |4.2.2.18| | | | |x|
+  Function: simultan. LISTENs for same port      |4.2.2.18|x| | | | |
+  Ask IP for src address for SYN if necc.        |4.2.3.7 |x| | | | |
+    Otherwise, use local addr of conn.           |4.2.3.7 |x| | | | |
+  OPEN to broadcast/multicast IP Address         |4.2.3.14| | | | |x|
+  Silently discard seg to bcast/mcast addr       |4.2.3.14|x| | | | |
+
+
+
+Internet Engineering Task Force                               [Page 109]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                                                 |        | | | | | |
+Closing Connections                              |        | | | | | |
+  RST can contain data                           |4.2.2.12| |x| | | |
+  Inform application of aborted conn             |4.2.2.13|x| | | | |
+  Half-duplex close connections                  |4.2.2.13| | |x| | |
+    Send RST to indicate data lost               |4.2.2.13| |x| | | |
+  In TIME-WAIT state for 2xMSL seconds           |4.2.2.13|x| | | | |
+    Accept SYN from TIME-WAIT state              |4.2.2.13| | |x| | |
+                                                 |        | | | | | |
+Retransmissions                                  |        | | | | | |
+  Jacobson Slow Start algorithm                  |4.2.2.15|x| | | | |
+  Jacobson Congestion-Avoidance algorithm        |4.2.2.15|x| | | | |
+  Retransmit with same IP ident                  |4.2.2.15| | |x| | |
+  Karn's algorithm                               |4.2.3.1 |x| | | | |
+  Jacobson's RTO estimation alg.                 |4.2.3.1 |x| | | | |
+  Exponential backoff                            |4.2.3.1 |x| | | | |
+  SYN RTO calc same as data                      |4.2.3.1 | |x| | | |
+  Recommended initial values and bounds          |4.2.3.1 | |x| | | |
+                                                 |        | | | | | |
+Generating ACK's:                                |        | | | | | |
+  Queue out-of-order segments                    |4.2.2.20| |x| | | |
+  Process all Q'd before send ACK                |4.2.2.20|x| | | | |
+  Send ACK for out-of-order segment              |4.2.2.21| | |x| | |
+  Delayed ACK's                                  |4.2.3.2 | |x| | | |
+    Delay < 0.5 seconds                          |4.2.3.2 |x| | | | |
+    Every 2nd full-sized segment ACK'd           |4.2.3.2 |x| | | | |
+  Receiver SWS-Avoidance Algorithm               |4.2.3.3 |x| | | | |
+                                                 |        | | | | | |
+Sending data                                     |        | | | | | |
+  Configurable TTL                               |4.2.2.19|x| | | | |
+  Sender SWS-Avoidance Algorithm                 |4.2.3.4 |x| | | | |
+  Nagle algorithm                                |4.2.3.4 | |x| | | |
+    Application can disable Nagle algorithm      |4.2.3.4 |x| | | | |
+                                                 |        | | | | | |
+Connection Failures:                             |        | | | | | |
+  Negative advice to IP on R1 retxs              |4.2.3.5 |x| | | | |
+  Close connection on R2 retxs                   |4.2.3.5 |x| | | | |
+  ALP can set R2                                 |4.2.3.5 |x| | | | |1
+  Inform ALP of  R1<=retxs<R2                    |4.2.3.5 | |x| | | |1
+  Recommended values for R1, R2                  |4.2.3.5 | |x| | | |
+  Same mechanism for SYNs                        |4.2.3.5 |x| | | | |
+    R2 at least 3 minutes for SYN                |4.2.3.5 |x| | | | |
+                                                 |        | | | | | |
+Send Keep-alive Packets:                         |4.2.3.6 | | |x| | |
+  - Application can request                      |4.2.3.6 |x| | | | |
+  - Default is "off"                             |4.2.3.6 |x| | | | |
+  - Only send if idle for interval               |4.2.3.6 |x| | | | |
+  - Interval configurable                        |4.2.3.6 |x| | | | |
+
+
+
+Internet Engineering Task Force                               [Page 110]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+  - Default at least 2 hrs.                      |4.2.3.6 |x| | | | |
+  - Tolerant of lost ACK's                       |4.2.3.6 |x| | | | |
+                                                 |        | | | | | |
+IP Options                                       |        | | | | | |
+  Ignore options TCP doesn't understand          |4.2.3.8 |x| | | | |
+  Time Stamp support                             |4.2.3.8 | | |x| | |
+  Record Route support                           |4.2.3.8 | | |x| | |
+  Source Route:                                  |        | | | | | |
+    ALP can specify                              |4.2.3.8 |x| | | | |1
+      Overrides src rt in datagram               |4.2.3.8 |x| | | | |
+    Build return route from src rt               |4.2.3.8 |x| | | | |
+    Later src route overrides                    |4.2.3.8 | |x| | | |
+                                                 |        | | | | | |
+Receiving ICMP Messages from IP                  |4.2.3.9 |x| | | | |
+  Dest. Unreach (0,1,5) => inform ALP            |4.2.3.9 | |x| | | |
+  Dest. Unreach (0,1,5) => abort conn            |4.2.3.9 | | | | |x|
+  Dest. Unreach (2-4) => abort conn              |4.2.3.9 | |x| | | |
+  Source Quench => slow start                    |4.2.3.9 | |x| | | |
+  Time Exceeded => tell ALP, don't abort         |4.2.3.9 | |x| | | |
+  Param Problem => tell ALP, don't abort         |4.2.3.9 | |x| | | |
+                                                 |        | | | | | |
+Address Validation                               |        | | | | | |
+  Reject OPEN call to invalid IP address         |4.2.3.10|x| | | | |
+  Reject SYN from invalid IP address             |4.2.3.10|x| | | | |
+  Silently discard SYN to bcast/mcast addr       |4.2.3.10|x| | | | |
+                                                 |        | | | | | |
+TCP/ALP Interface Services                       |        | | | | | |
+  Error Report mechanism                         |4.2.4.1 |x| | | | |
+  ALP can disable Error Report Routine           |4.2.4.1 | |x| | | |
+  ALP can specify TOS for sending                |4.2.4.2 |x| | | | |
+    Passed unchanged to IP                       |4.2.4.2 | |x| | | |
+  ALP can change TOS during connection           |4.2.4.2 | |x| | | |
+  Pass received TOS up to ALP                    |4.2.4.2 | | |x| | |
+  FLUSH call                                     |4.2.4.3 | | |x| | |
+  Optional local IP addr parm. in OPEN           |4.2.4.4 |x| | | | |
+-------------------------------------------------|--------|-|-|-|-|-|--
+-------------------------------------------------|--------|-|-|-|-|-|--
+
+FOOTNOTES:
+
+(1)  "ALP" means Application-Layer program.
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                               [Page 111]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+5.  REFERENCES
+
+INTRODUCTORY REFERENCES
+
+
+[INTRO:1] "Requirements for Internet Hosts -- Application and Support,"
+     IETF Host Requirements Working Group, R. Braden, Ed., RFC-1123,
+     October 1989.
+
+[INTRO:2]  "Requirements for Internet Gateways,"  R. Braden and J.
+     Postel, RFC-1009, June 1987.
+
+[INTRO:3]  "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006,
+     (three volumes), SRI International, December 1985.
+
+[INTRO:4]  "Official Internet Protocols," J. Reynolds and J. Postel,
+     RFC-1011, May 1987.
+
+     This document is republished periodically with new RFC numbers; the
+     latest version must be used.
+
+[INTRO:5]  "Protocol Document Order Information," O. Jacobsen and J.
+     Postel, RFC-980, March 1986.
+
+[INTRO:6]  "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010, May
+     1987.
+
+     This document is republished periodically with new RFC numbers; the
+     latest version must be used.
+
+[INTRO:7] "Modularity and Efficiency in Protocol Implementations," D.
+     Clark, RFC-817, July 1982.
+
+[INTRO:8] "The Structuring of Systems Using Upcalls," D. Clark, 10th ACM
+     SOSP, Orcas Island, Washington, December 1985.
+
+
+Secondary References:
+
+
+[INTRO:9]  "A Protocol for Packet Network Intercommunication," V. Cerf
+     and R. Kahn, IEEE Transactions on Communication, May 1974.
+
+[INTRO:10]  "The ARPA Internet Protocol," J. Postel, C. Sunshine, and D.
+     Cohen, Computer Networks, Vol. 5, No. 4, July 1981.
+
+[INTRO:11]  "The DARPA Internet Protocol Suite," B. Leiner, J. Postel,
+     R. Cole and D. Mills, Proceedings INFOCOM 85, IEEE, Washington DC,
+
+
+
+Internet Engineering Task Force                               [Page 112]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+     March 1985.  Also in: IEEE Communications Magazine, March 1985.
+     Also available as ISI-RS-85-153.
+
+[INTRO:12] "Final Text of DIS8473, Protocol for Providing the
+     Connectionless Mode Network Service," ANSI, published as RFC-994,
+     March 1986.
+
+[INTRO:13] "End System to Intermediate System Routing Exchange
+     Protocol," ANSI X3S3.3, published as RFC-995, April 1986.
+
+
+LINK LAYER REFERENCES
+
+
+[LINK:1] "Trailer Encapsulations," S. Leffler and M. Karels, RFC-893,
+     April 1984.
+
+[LINK:2] "An Ethernet Address Resolution Protocol," D. Plummer, RFC-826,
+     November 1982.
+
+[LINK:3] "A Standard for the Transmission of IP Datagrams over Ethernet
+     Networks," C. Hornig, RFC-894, April 1984.
+
+[LINK:4] "A Standard for the Transmission of IP Datagrams over IEEE 802
+     "Networks," J. Postel and J. Reynolds, RFC-1042, February 1988.
+
+     This RFC contains a great deal of information of importance to
+     Internet implementers planning to use IEEE 802 networks.
+
+
+IP LAYER REFERENCES
+
+
+[IP:1] "Internet Protocol (IP)," J. Postel, RFC-791, September 1981.
+
+[IP:2] "Internet Control Message Protocol (ICMP)," J. Postel, RFC-792,
+     September 1981.
+
+[IP:3] "Internet Standard Subnetting Procedure," J. Mogul and J. Postel,
+     RFC-950, August 1985.
+
+[IP:4]  "Host Extensions for IP Multicasting," S. Deering, RFC-1112,
+     August 1989.
+
+[IP:5] "Military Standard Internet Protocol," MIL-STD-1777, Department
+     of Defense, August 1983.
+
+     This specification, as amended by RFC-963, is intended to describe
+
+
+
+Internet Engineering Task Force                               [Page 113]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+     the Internet Protocol but has some serious omissions (e.g., the
+     mandatory subnet extension [IP:3] and the optional multicasting
+     extension [IP:4]).  It is also out of date.  If there is a
+     conflict, RFC-791, RFC-792, and RFC-950 must be taken as
+     authoritative, while the present document is authoritative over
+     all.
+
+[IP:6] "Some Problems with the Specification of the Military Standard
+     Internet Protocol," D. Sidhu, RFC-963, November 1985.
+
+[IP:7] "The TCP Maximum Segment Size and Related Topics," J. Postel,
+     RFC-879, November 1983.
+
+     Discusses and clarifies the relationship between the TCP Maximum
+     Segment Size option and the IP datagram size.
+
+[IP:8] "Internet Protocol Security Options,"  B. Schofield, RFC-1108,
+     October 1989.
+
+[IP:9] "Fragmentation Considered Harmful," C. Kent and J. Mogul, ACM
+     SIGCOMM-87, August 1987.  Published as ACM Comp Comm Review, Vol.
+     17, no. 5.
+
+     This useful paper discusses the problems created by Internet
+     fragmentation and presents alternative solutions.
+
+[IP:10] "IP Datagram Reassembly Algorithms," D. Clark, RFC-815, July
+     1982.
+
+     This and the following paper should be read by every implementor.
+
+[IP:11] "Fault Isolation and Recovery," D. Clark, RFC-816, July 1982.
+
+SECONDARY IP REFERENCES:
+
+
+[IP:12] "Broadcasting Internet Datagrams in the Presence of Subnets," J.
+     Mogul, RFC-922, October 1984.
+
+[IP:13] "Name, Addresses, Ports, and Routes," D. Clark, RFC-814, July
+     1982.
+
+[IP:14] "Something a Host Could Do with Source Quench: The Source Quench
+     Introduced Delay (SQUID)," W. Prue and J. Postel, RFC-1016, July
+     1987.
+
+     This RFC first described directed broadcast addresses.  However,
+     the bulk of the RFC is concerned with gateways, not hosts.
+
+
+
+Internet Engineering Task Force                               [Page 114]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+UDP REFERENCES:
+
+
+[UDP:1] "User Datagram Protocol," J. Postel, RFC-768, August 1980.
+
+
+TCP REFERENCES:
+
+
+[TCP:1] "Transmission Control Protocol," J. Postel, RFC-793, September
+     1981.
+
+
+[TCP:2] "Transmission Control Protocol," MIL-STD-1778, US Department of
+     Defense, August 1984.
+
+     This specification as amended by RFC-964 is intended to describe
+     the same protocol as RFC-793 [TCP:1].  If there is a conflict,
+     RFC-793 takes precedence, and the present document is authoritative
+     over both.
+
+
+[TCP:3] "Some Problems with the Specification of the Military Standard
+     Transmission Control Protocol," D. Sidhu and T. Blumer, RFC-964,
+     November 1985.
+
+
+[TCP:4] "The TCP Maximum Segment Size and Related Topics," J. Postel,
+     RFC-879, November 1983.
+
+
+[TCP:5] "Window and Acknowledgment Strategy in TCP," D. Clark, RFC-813,
+     July 1982.
+
+
+[TCP:6] "Round Trip Time Estimation," P. Karn & C. Partridge, ACM
+     SIGCOMM-87, August 1987.
+
+
+[TCP:7] "Congestion Avoidance and Control," V. Jacobson, ACM SIGCOMM-88,
+     August 1988.
+
+
+SECONDARY TCP REFERENCES:
+
+
+[TCP:8] "Modularity and Efficiency in Protocol Implementation," D.
+     Clark, RFC-817, July 1982.
+
+
+
+Internet Engineering Task Force                               [Page 115]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+[TCP:9] "Congestion Control in IP/TCP," J. Nagle, RFC-896, January 1984.
+
+
+[TCP:10] "Computing the Internet Checksum," R. Braden, D. Borman, and C.
+     Partridge, RFC-1071, September 1988.
+
+
+[TCP:11] "TCP Extensions for Long-Delay Paths," V. Jacobson & R. Braden,
+     RFC-1072, October 1988.
+
+
+Security Considerations
+
+   There are many security issues in the communication layers of host
+   software, but a full discussion is beyond the scope of this RFC.
+
+   The Internet architecture generally provides little protection
+   against spoofing of IP source addresses, so any security mechanism
+   that is based upon verifying the IP source address of a datagram
+   should be treated with suspicion.  However, in restricted
+   environments some source-address checking may be possible.  For
+   example, there might be a secure LAN whose gateway to the rest of the
+   Internet discarded any incoming datagram with a source address that
+   spoofed the LAN address.  In this case, a host on the LAN could use
+   the source address to test for local vs. remote source.  This problem
+   is complicated by source routing, and some have suggested that
+   source-routed datagram forwarding by hosts (see Section 3.3.5) should
+   be outlawed for security reasons.
+
+   Security-related issues are mentioned in sections concerning the IP
+   Security option (Section 3.2.1.8), the ICMP Parameter Problem message
+   (Section 3.2.2.5), IP options in UDP datagrams (Section 4.1.3.2), and
+   reserved TCP ports (Section 4.2.2.1).
+
+Author's Address
+
+   Robert Braden
+   USC/Information Sciences Institute
+   4676 Admiralty Way
+   Marina del Rey, CA 90292-6695
+
+   Phone: (213) 822 1511
+
+   EMail: Braden@ISI.EDU
+
+
+
+
+
+
+
+Internet Engineering Task Force                               [Page 116]
+
diff --git a/usr.sbin/named/doc/rfc/rfc1123 b/usr.sbin/named/doc/rfc/rfc1123
new file mode 100644
index 00000000000..51cdf83c984
--- /dev/null
+++ b/usr.sbin/named/doc/rfc/rfc1123
@@ -0,0 +1,5782 @@
+
+
+
+
+
+
+Network Working Group                    Internet Engineering Task Force
+Request for Comments: 1123                             R. Braden, Editor
+                                                            October 1989
+
+
+       Requirements for Internet Hosts -- Application and Support
+
+Status of This Memo
+
+   This RFC is an official specification for the Internet community.  It
+   incorporates by reference, amends, corrects, and supplements the
+   primary protocol standards documents relating to hosts.  Distribution
+   of this document is unlimited.
+
+Summary
+
+   This RFC is one of a pair that defines and discusses the requirements
+   for Internet host software.  This RFC covers the application and
+   support protocols; its companion RFC-1122 covers the communication
+   protocol layers: link layer, IP layer, and transport layer.
+
+
+
+                           Table of Contents
+
+
+
+
+   1.  INTRODUCTION ...............................................    5
+      1.1  The Internet Architecture ..............................    6
+      1.2  General Considerations .................................    6
+         1.2.1  Continuing Internet Evolution .....................    6
+         1.2.2  Robustness Principle ..............................    7
+         1.2.3  Error Logging .....................................    8
+         1.2.4  Configuration .....................................    8
+      1.3  Reading this Document ..................................   10
+         1.3.1  Organization ......................................   10
+         1.3.2  Requirements ......................................   10
+         1.3.3  Terminology .......................................   11
+      1.4  Acknowledgments ........................................   12
+
+   2.  GENERAL ISSUES .............................................   13
+      2.1  Host Names and Numbers .................................   13
+      2.2  Using Domain Name Service ..............................   13
+      2.3  Applications on Multihomed hosts .......................   14
+      2.4  Type-of-Service ........................................   14
+      2.5  GENERAL APPLICATION REQUIREMENTS SUMMARY ...............   15
+
+
+
+
+Internet Engineering Task Force                                 [Page 1]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+   3.  REMOTE LOGIN -- TELNET PROTOCOL ............................   16
+      3.1  INTRODUCTION ...........................................   16
+      3.2  PROTOCOL WALK-THROUGH ..................................   16
+         3.2.1  Option Negotiation ................................   16
+         3.2.2  Telnet Go-Ahead Function ..........................   16
+         3.2.3  Control Functions .................................   17
+         3.2.4  Telnet "Synch" Signal .............................   18
+         3.2.5  NVT Printer and Keyboard ..........................   19
+         3.2.6  Telnet Command Structure ..........................   20
+         3.2.7  Telnet Binary Option ..............................   20
+         3.2.8  Telnet Terminal-Type Option .......................   20
+      3.3  SPECIFIC ISSUES ........................................   21
+         3.3.1  Telnet End-of-Line Convention .....................   21
+         3.3.2  Data Entry Terminals ..............................   23
+         3.3.3  Option Requirements ...............................   24
+         3.3.4  Option Initiation .................................   24
+         3.3.5  Telnet Linemode Option ............................   25
+      3.4  TELNET/USER INTERFACE ..................................   25
+         3.4.1  Character Set Transparency ........................   25
+         3.4.2  Telnet Commands ...................................   26
+         3.4.3  TCP Connection Errors .............................   26
+         3.4.4  Non-Default Telnet Contact Port ...................   26
+         3.4.5  Flushing Output ...................................   26
+      3.5.  TELNET REQUIREMENTS SUMMARY ...........................   27
+
+   4.  FILE TRANSFER ..............................................   29
+      4.1  FILE TRANSFER PROTOCOL -- FTP ..........................   29
+         4.1.1  INTRODUCTION ......................................   29
+         4.1.2.  PROTOCOL WALK-THROUGH ............................   29
+            4.1.2.1  LOCAL Type ...................................   29
+            4.1.2.2  Telnet Format Control ........................   30
+            4.1.2.3  Page Structure ...............................   30
+            4.1.2.4  Data Structure Transformations ...............   30
+            4.1.2.5  Data Connection Management ...................   31
+            4.1.2.6  PASV Command .................................   31
+            4.1.2.7  LIST and NLST Commands .......................   31
+            4.1.2.8  SITE Command .................................   32
+            4.1.2.9  STOU Command .................................   32
+            4.1.2.10  Telnet End-of-line Code .....................   32
+            4.1.2.11  FTP Replies .................................   33
+            4.1.2.12  Connections .................................   34
+            4.1.2.13  Minimum Implementation; RFC-959 Section .....   34
+         4.1.3  SPECIFIC ISSUES ...................................   35
+            4.1.3.1  Non-standard Command Verbs ...................   35
+            4.1.3.2  Idle Timeout .................................   36
+            4.1.3.3  Concurrency of Data and Control ..............   36
+            4.1.3.4  FTP Restart Mechanism ........................   36
+         4.1.4  FTP/USER INTERFACE ................................   39
+
+
+
+Internet Engineering Task Force                                 [Page 2]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+            4.1.4.1  Pathname Specification .......................   39
+            4.1.4.2  "QUOTE" Command ..............................   40
+            4.1.4.3  Displaying Replies to User ...................   40
+            4.1.4.4  Maintaining Synchronization ..................   40
+         4.1.5   FTP REQUIREMENTS SUMMARY .........................   41
+      4.2  TRIVIAL FILE TRANSFER PROTOCOL -- TFTP .................   44
+         4.2.1  INTRODUCTION ......................................   44
+         4.2.2  PROTOCOL WALK-THROUGH .............................   44
+            4.2.2.1  Transfer Modes ...............................   44
+            4.2.2.2  UDP Header ...................................   44
+         4.2.3  SPECIFIC ISSUES ...................................   44
+            4.2.3.1  Sorcerer's Apprentice Syndrome ...............   44
+            4.2.3.2  Timeout Algorithms ...........................   46
+            4.2.3.3  Extensions ...................................   46
+            4.2.3.4  Access Control ...............................   46
+            4.2.3.5  Broadcast Request ............................   46
+         4.2.4  TFTP REQUIREMENTS SUMMARY .........................   47
+
+   5.  ELECTRONIC MAIL -- SMTP and RFC-822 ........................   48
+      5.1  INTRODUCTION ...........................................   48
+      5.2  PROTOCOL WALK-THROUGH ..................................   48
+         5.2.1  The SMTP Model ....................................   48
+         5.2.2  Canonicalization ..................................   49
+         5.2.3  VRFY and EXPN Commands ............................   50
+         5.2.4  SEND, SOML, and SAML Commands .....................   50
+         5.2.5  HELO Command ......................................   50
+         5.2.6  Mail Relay ........................................   51
+         5.2.7  RCPT Command ......................................   52
+         5.2.8  DATA Command ......................................   53
+         5.2.9  Command Syntax ....................................   54
+         5.2.10  SMTP Replies .....................................   54
+         5.2.11  Transparency .....................................   55
+         5.2.12  WKS Use in MX Processing .........................   55
+         5.2.13  RFC-822 Message Specification ....................   55
+         5.2.14  RFC-822 Date and Time Specification ..............   55
+         5.2.15  RFC-822 Syntax Change ............................   56
+         5.2.16  RFC-822  Local-part ..............................   56
+         5.2.17  Domain Literals ..................................   57
+         5.2.18  Common Address Formatting Errors .................   58
+         5.2.19  Explicit Source Routes ...........................   58
+      5.3  SPECIFIC ISSUES ........................................   59
+         5.3.1  SMTP Queueing Strategies ..........................   59
+            5.3.1.1 Sending Strategy ..............................   59
+            5.3.1.2  Receiving strategy ...........................   61
+         5.3.2  Timeouts in SMTP ..................................   61
+         5.3.3  Reliable Mail Receipt .............................   63
+         5.3.4  Reliable Mail Transmission ........................   63
+         5.3.5  Domain Name Support ...............................   65
+
+
+
+Internet Engineering Task Force                                 [Page 3]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+         5.3.6  Mailing Lists and Aliases .........................   65
+         5.3.7  Mail Gatewaying ...................................   66
+         5.3.8  Maximum Message Size ..............................   68
+      5.4  SMTP REQUIREMENTS SUMMARY ..............................   69
+
+   6. SUPPORT SERVICES ............................................   72
+      6.1 DOMAIN NAME TRANSLATION .................................   72
+         6.1.1 INTRODUCTION .......................................   72
+         6.1.2  PROTOCOL WALK-THROUGH .............................   72
+            6.1.2.1  Resource Records with Zero TTL ...............   73
+            6.1.2.2  QCLASS Values ................................   73
+            6.1.2.3  Unused Fields ................................   73
+            6.1.2.4  Compression ..................................   73
+            6.1.2.5  Misusing Configuration Info ..................   73
+         6.1.3  SPECIFIC ISSUES ...................................   74
+            6.1.3.1  Resolver Implementation ......................   74
+            6.1.3.2  Transport Protocols ..........................   75
+            6.1.3.3  Efficient Resource Usage .....................   77
+            6.1.3.4  Multihomed Hosts .............................   78
+            6.1.3.5  Extensibility ................................   79
+            6.1.3.6  Status of RR Types ...........................   79
+            6.1.3.7  Robustness ...................................   80
+            6.1.3.8  Local Host Table .............................   80
+         6.1.4  DNS USER INTERFACE ................................   81
+            6.1.4.1  DNS Administration ...........................   81
+            6.1.4.2  DNS User Interface ...........................   81
+            6.1.4.3 Interface Abbreviation Facilities .............   82
+         6.1.5  DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY ...........   84
+      6.2  HOST INITIALIZATION ....................................   87
+         6.2.1  INTRODUCTION ......................................   87
+         6.2.2  REQUIREMENTS ......................................   87
+            6.2.2.1  Dynamic Configuration ........................   87
+            6.2.2.2  Loading Phase ................................   89
+      6.3  REMOTE MANAGEMENT ......................................   90
+         6.3.1  INTRODUCTION ......................................   90
+         6.3.2  PROTOCOL WALK-THROUGH .............................   90
+         6.3.3  MANAGEMENT REQUIREMENTS SUMMARY ...................   92
+
+   7.  REFERENCES .................................................   93
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                 [Page 4]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+1.  INTRODUCTION
+
+   This document is one of a pair that defines and discusses the
+   requirements for host system implementations of the Internet protocol
+   suite.  This RFC covers the applications layer and support protocols.
+   Its companion RFC, "Requirements for Internet Hosts -- Communications
+   Layers" [INTRO:1] covers the lower layer protocols: transport layer,
+   IP layer, and link layer.
+
+   These documents are intended to provide guidance for vendors,
+   implementors, and users of Internet communication software.  They
+   represent the consensus of a large body of technical experience and
+   wisdom, contributed by members of the Internet research and vendor
+   communities.
+
+   This RFC enumerates standard protocols that a host connected to the
+   Internet must use, and it incorporates by reference the RFCs and
+   other documents describing the current specifications for these
+   protocols.  It corrects errors in the referenced documents and adds
+   additional discussion and guidance for an implementor.
+
+   For each protocol, this document also contains an explicit set of
+   requirements, recommendations, and options.  The reader must
+   understand that the list of requirements in this document is
+   incomplete by itself; the complete set of requirements for an
+   Internet host is primarily defined in the standard protocol
+   specification documents, with the corrections, amendments, and
+   supplements contained in this RFC.
+
+   A good-faith implementation of the protocols that was produced after
+   careful reading of the RFC's and with some interaction with the
+   Internet technical community, and that followed good communications
+   software engineering practices, should differ from the requirements
+   of this document in only minor ways.  Thus, in many cases, the
+   "requirements" in this RFC are already stated or implied in the
+   standard protocol documents, so that their inclusion here is, in a
+   sense, redundant.  However, they were included because some past
+   implementation has made the wrong choice, causing problems of
+   interoperability, performance, and/or robustness.
+
+   This document includes discussion and explanation of many of the
+   requirements and recommendations.  A simple list of requirements
+   would be dangerous, because:
+
+   o    Some required features are more important than others, and some
+        features are optional.
+
+   o    There may be valid reasons why particular vendor products that
+
+
+
+Internet Engineering Task Force                                 [Page 5]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+        are designed for restricted contexts might choose to use
+        different specifications.
+
+   However, the specifications of this document must be followed to meet
+   the general goal of arbitrary host interoperation across the
+   diversity and complexity of the Internet system.  Although most
+   current implementations fail to meet these requirements in various
+   ways, some minor and some major, this specification is the ideal
+   towards which we need to move.
+
+   These requirements are based on the current level of Internet
+   architecture.  This document will be updated as required to provide
+   additional clarifications or to include additional information in
+   those areas in which specifications are still evolving.
+
+   This introductory section begins with general advice to host software
+   vendors, and then gives some guidance on reading the rest of the
+   document.  Section 2 contains general requirements that may be
+   applicable to all application and support protocols.  Sections 3, 4,
+   and 5 contain the requirements on protocols for the three major
+   applications: Telnet, file transfer, and electronic mail,
+   respectively. Section 6 covers the support applications: the domain
+   name system, system initialization, and management.  Finally, all
+   references will be found in Section 7.
+
+   1.1  The Internet Architecture
+
+      For a brief introduction to the Internet architecture from a host
+      viewpoint, see Section 1.1 of [INTRO:1].  That section also
+      contains recommended references for general background on the
+      Internet architecture.
+
+   1.2  General Considerations
+
+      There are two important lessons that vendors of Internet host
+      software have learned and which a new vendor should consider
+      seriously.
+
+      1.2.1  Continuing Internet Evolution
+
+         The enormous growth of the Internet has revealed problems of
+         management and scaling in a large datagram-based packet
+         communication system.  These problems are being addressed, and
+         as a result there will be continuing evolution of the
+         specifications described in this document.  These changes will
+         be carefully planned and controlled, since there is extensive
+         participation in this planning by the vendors and by the
+         organizations responsible for operations of the networks.
+
+
+
+Internet Engineering Task Force                                 [Page 6]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+         Development, evolution, and revision are characteristic of
+         computer network protocols today, and this situation will
+         persist for some years.  A vendor who develops computer
+         communication software for the Internet protocol suite (or any
+         other protocol suite!) and then fails to maintain and update
+         that software for changing specifications is going to leave a
+         trail of unhappy customers.  The Internet is a large
+         communication network, and the users are in constant contact
+         through it.  Experience has shown that knowledge of
+         deficiencies in vendor software propagates quickly through the
+         Internet technical community.
+
+      1.2.2  Robustness Principle
+
+         At every layer of the protocols, there is a general rule whose
+         application can lead to enormous benefits in robustness and
+         interoperability:
+
+                "Be liberal in what you accept, and
+                 conservative in what you send"
+
+         Software should be written to deal with every conceivable
+         error, no matter how unlikely; sooner or later a packet will
+         come in with that particular combination of errors and
+         attributes, and unless the software is prepared, chaos can
+         ensue.  In general, it is best to assume that the network is
+         filled with malevolent entities that will send in packets
+         designed to have the worst possible effect.  This assumption
+         will lead to suitable protective design, although the most
+         serious problems in the Internet have been caused by
+         unenvisaged mechanisms triggered by low-probability events;
+         mere human malice would never have taken so devious a course!
+
+         Adaptability to change must be designed into all levels of
+         Internet host software.  As a simple example, consider a
+         protocol specification that contains an enumeration of values
+         for a particular header field -- e.g., a type field, a port
+         number, or an error code; this enumeration must be assumed to
+         be incomplete.  Thus, if a protocol specification defines four
+         possible error codes, the software must not break when a fifth
+         code shows up.  An undefined code might be logged (see below),
+         but it must not cause a failure.
+
+         The second part of the principle is almost as important:
+         software on other hosts may contain deficiencies that make it
+         unwise to exploit legal but obscure protocol features.  It is
+         unwise to stray far from the obvious and simple, lest untoward
+         effects result elsewhere.  A corollary of this is "watch out
+
+
+
+Internet Engineering Task Force                                 [Page 7]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+         for misbehaving hosts"; host software should be prepared, not
+         just to survive other misbehaving hosts, but also to cooperate
+         to limit the amount of disruption such hosts can cause to the
+         shared communication facility.
+
+      1.2.3  Error Logging
+
+         The Internet includes a great variety of host and gateway
+         systems, each implementing many protocols and protocol layers,
+         and some of these contain bugs and mis-features in their
+         Internet protocol software.  As a result of complexity,
+         diversity, and distribution of function, the diagnosis of user
+         problems is often very difficult.
+
+         Problem diagnosis will be aided if host implementations include
+         a carefully designed facility for logging erroneous or
+         "strange" protocol events.  It is important to include as much
+         diagnostic information as possible when an error is logged.  In
+         particular, it is often useful to record the header(s) of a
+         packet that caused an error.  However, care must be taken to
+         ensure that error logging does not consume prohibitive amounts
+         of resources or otherwise interfere with the operation of the
+         host.
+
+         There is a tendency for abnormal but harmless protocol events
+         to overflow error logging files; this can be avoided by using a
+         "circular" log, or by enabling logging only while diagnosing a
+         known failure.  It may be useful to filter and count duplicate
+         successive messages.  One strategy that seems to work well is:
+         (1) always count abnormalities and make such counts accessible
+         through the management protocol (see Section 6.3); and (2)
+         allow the logging of a great variety of events to be
+         selectively enabled.  For example, it might useful to be able
+         to "log everything" or to "log everything for host X".
+
+         Note that different managements may have differing policies
+         about the amount of error logging that they want normally
+         enabled in a host.  Some will say, "if it doesn't hurt me, I
+         don't want to know about it", while others will want to take a
+         more watchful and aggressive attitude about detecting and
+         removing protocol abnormalities.
+
+      1.2.4  Configuration
+
+         It would be ideal if a host implementation of the Internet
+         protocol suite could be entirely self-configuring.  This would
+         allow the whole suite to be implemented in ROM or cast into
+         silicon, it would simplify diskless workstations, and it would
+
+
+
+Internet Engineering Task Force                                 [Page 8]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+         be an immense boon to harried LAN administrators as well as
+         system vendors.  We have not reached this ideal; in fact, we
+         are not even close.
+
+         At many points in this document, you will find a requirement
+         that a parameter be a configurable option.  There are several
+         different reasons behind such requirements.  In a few cases,
+         there is current uncertainty or disagreement about the best
+         value, and it may be necessary to update the recommended value
+         in the future.  In other cases, the value really depends on
+         external factors -- e.g., the size of the host and the
+         distribution of its communication load, or the speeds and
+         topology of nearby networks -- and self-tuning algorithms are
+         unavailable and may be insufficient.  In some cases,
+         configurability is needed because of administrative
+         requirements.
+
+         Finally, some configuration options are required to communicate
+         with obsolete or incorrect implementations of the protocols,
+         distributed without sources, that unfortunately persist in many
+         parts of the Internet.  To make correct systems coexist with
+         these faulty systems, administrators often have to "mis-
+         configure" the correct systems.  This problem will correct
+         itself gradually as the faulty systems are retired, but it
+         cannot be ignored by vendors.
+
+         When we say that a parameter must be configurable, we do not
+         intend to require that its value be explicitly read from a
+         configuration file at every boot time.  We recommend that
+         implementors set up a default for each parameter, so a
+         configuration file is only necessary to override those defaults
+         that are inappropriate in a particular installation.  Thus, the
+         configurability requirement is an assurance that it will be
+         POSSIBLE to override the default when necessary, even in a
+         binary-only or ROM-based product.
+
+         This document requires a particular value for such defaults in
+         some cases.  The choice of default is a sensitive issue when
+         the configuration item controls the accommodation to existing
+         faulty systems.  If the Internet is to converge successfully to
+         complete interoperability, the default values built into
+         implementations must implement the official protocol, not
+         "mis-configurations" to accommodate faulty implementations.
+         Although marketing considerations have led some vendors to
+         choose mis-configuration defaults, we urge vendors to choose
+         defaults that will conform to the standard.
+
+         Finally, we note that a vendor needs to provide adequate
+
+
+
+Internet Engineering Task Force                                 [Page 9]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+         documentation on all configuration parameters, their limits and
+         effects.
+
+
+   1.3  Reading this Document
+
+      1.3.1  Organization
+
+         In general, each major section is organized into the following
+         subsections:
+
+         (1)  Introduction
+
+         (2)  Protocol Walk-Through -- considers the protocol
+              specification documents section-by-section, correcting
+              errors, stating requirements that may be ambiguous or
+              ill-defined, and providing further clarification or
+              explanation.
+
+         (3)  Specific Issues -- discusses protocol design and
+              implementation issues that were not included in the walk-
+              through.
+
+         (4)  Interfaces -- discusses the service interface to the next
+              higher layer.
+
+         (5)  Summary -- contains a summary of the requirements of the
+              section.
+
+         Under many of the individual topics in this document, there is
+         parenthetical material labeled "DISCUSSION" or
+         "IMPLEMENTATION".  This material is intended to give
+         clarification and explanation of the preceding requirements
+         text.  It also includes some suggestions on possible future
+         directions or developments.  The implementation material
+         contains suggested approaches that an implementor may want to
+         consider.
+
+         The summary sections are intended to be guides and indexes to
+         the text, but are necessarily cryptic and incomplete.  The
+         summaries should never be used or referenced separately from
+         the complete RFC.
+
+      1.3.2  Requirements
+
+         In this document, the words that are used to define the
+         significance of each particular requirement are capitalized.
+         These words are:
+
+
+
+Internet Engineering Task Force                                [Page 10]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+         *    "MUST"
+
+              This word or the adjective "REQUIRED" means that the item
+              is an absolute requirement of the specification.
+
+         *    "SHOULD"
+
+              This word or the adjective "RECOMMENDED" means that there
+              may exist valid reasons in particular circumstances to
+              ignore this item, but the full implications should be
+              understood and the case carefully weighed before choosing
+              a different course.
+
+         *    "MAY"
+
+              This word or the adjective "OPTIONAL" means that this item
+              is truly optional.  One vendor may choose to include the
+              item because a particular marketplace requires it or
+              because it enhances the product, for example; another
+              vendor may omit the same item.
+
+
+         An implementation is not compliant if it fails to satisfy one
+         or more of the MUST requirements for the protocols it
+         implements.  An implementation that satisfies all the MUST and
+         all the SHOULD requirements for its protocols is said to be
+         "unconditionally compliant"; one that satisfies all the MUST
+         requirements but not all the SHOULD requirements for its
+         protocols is said to be "conditionally compliant".
+
+      1.3.3  Terminology
+
+         This document uses the following technical terms:
+
+         Segment
+              A segment is the unit of end-to-end transmission in the
+              TCP protocol.  A segment consists of a TCP header followed
+              by application data.  A segment is transmitted by
+              encapsulation in an IP datagram.
+
+         Message
+              This term is used by some application layer protocols
+              (particularly SMTP) for an application data unit.
+
+         Datagram
+              A [UDP] datagram is the unit of end-to-end transmission in
+              the UDP protocol.
+
+
+
+
+Internet Engineering Task Force                                [Page 11]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+         Multihomed
+              A host is said to be multihomed if it has multiple IP
+              addresses to connected networks.
+
+
+
+   1.4  Acknowledgments
+
+      This document incorporates contributions and comments from a large
+      group of Internet protocol experts, including representatives of
+      university and research labs, vendors, and government agencies.
+      It was assembled primarily by the Host Requirements Working Group
+      of the Internet Engineering Task Force (IETF).
+
+      The Editor would especially like to acknowledge the tireless
+      dedication of the following people, who attended many long
+      meetings and generated 3 million bytes of electronic mail over the
+      past 18 months in pursuit of this document: Philip Almquist, Dave
+      Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve
+      Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore),
+      John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG),
+      Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge
+      (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software).
+
+      In addition, the following people made major contributions to the
+      effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia
+      (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA),
+      Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL),
+      John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill
+      Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul
+      (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue
+      Technology), and Mike StJohns (DCA).  The following also made
+      significant contributions to particular areas: Eric Allman
+      (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic
+      (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn
+      (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann
+      (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun
+      Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen
+      (Toronto).
+
+      We are grateful to all, including any contributors who may have
+      been inadvertently omitted from this list.
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 12]
+
+
+
+
+RFC1123              APPLICATIONS LAYER -- GENERAL          October 1989
+
+
+2.  GENERAL ISSUES
+
+   This section contains general requirements that may be applicable to
+   all application-layer protocols.
+
+   2.1  Host Names and Numbers
+
+      The syntax of a legal Internet host name was specified in RFC-952
+      [DNS:4].  One aspect of host name syntax is hereby changed: the
+      restriction on the first character is relaxed to allow either a
+      letter or a digit.  Host software MUST support this more liberal
+      syntax.
+
+      Host software MUST handle host names of up to 63 characters and
+      SHOULD handle host names of up to 255 characters.
+
+      Whenever a user inputs the identity of an Internet host, it SHOULD
+      be possible to enter either (1) a host domain name or (2) an IP
+      address in dotted-decimal ("#.#.#.#") form.  The host SHOULD check
+      the string syntactically for a dotted-decimal number before
+      looking it up in the Domain Name System.
+
+      DISCUSSION:
+           This last requirement is not intended to specify the complete
+           syntactic form for entering a dotted-decimal host number;
+           that is considered to be a user-interface issue.  For
+           example, a dotted-decimal number must be enclosed within
+           "[ ]" brackets for SMTP mail (see Section 5.2.17).  This
+           notation could be made universal within a host system,
+           simplifying the syntactic checking for a dotted-decimal
+           number.
+
+           If a dotted-decimal number can be entered without such
+           identifying delimiters, then a full syntactic check must be
+           made, because a segment of a host domain name is now allowed
+           to begin with a digit and could legally be entirely numeric
+           (see Section 6.1.2.4).  However, a valid host name can never
+           have the dotted-decimal form #.#.#.#, since at least the
+           highest-level component label will be alphabetic.
+
+   2.2  Using Domain Name Service
+
+      Host domain names MUST be translated to IP addresses as described
+      in Section 6.1.
+
+      Applications using domain name services MUST be able to cope with
+      soft error conditions.  Applications MUST wait a reasonable
+      interval between successive retries due to a soft error, and MUST
+
+
+
+Internet Engineering Task Force                                [Page 13]
+
+
+
+
+RFC1123              APPLICATIONS LAYER -- GENERAL          October 1989
+
+
+      allow for the possibility that network problems may deny service
+      for hours or even days.
+
+      An application SHOULD NOT rely on the ability to locate a WKS
+      record containing an accurate listing of all services at a
+      particular host address, since the WKS RR type is not often used
+      by Internet sites.  To confirm that a service is present, simply
+      attempt to use it.
+
+   2.3  Applications on Multihomed hosts
+
+      When the remote host is multihomed, the name-to-address
+      translation will return a list of alternative IP addresses.  As
+      specified in Section 6.1.3.4, this list should be in order of
+      decreasing preference.  Application protocol implementations
+      SHOULD be prepared to try multiple addresses from the list until
+      success is obtained.  More specific requirements for SMTP are
+      given in Section 5.3.4.
+
+      When the local host is multihomed, a UDP-based request/response
+      application SHOULD send the response with an IP source address
+      that is the same as the specific destination address of the UDP
+      request datagram.  The "specific destination address" is defined
+      in the "IP Addressing" section of the companion RFC [INTRO:1].
+
+      Similarly, a server application that opens multiple TCP
+      connections to the same client SHOULD use the same local IP
+      address for all.
+
+   2.4  Type-of-Service
+
+      Applications MUST select appropriate TOS values when they invoke
+      transport layer services, and these values MUST be configurable.
+      Note that a TOS value contains 5 bits, of which only the most-
+      significant 3 bits are currently defined; the other two bits MUST
+      be zero.
+
+      DISCUSSION:
+           As gateway algorithms are developed to implement Type-of-
+           Service, the recommended values for various application
+           protocols may change.  In addition, it is likely that
+           particular combinations of users and Internet paths will want
+           non-standard TOS values.  For these reasons, the TOS values
+           must be configurable.
+
+           See the latest version of the "Assigned Numbers" RFC
+           [INTRO:5] for the recommended TOS values for the major
+           application protocols.
+
+
+
+Internet Engineering Task Force                                [Page 14]
+
+
+
+
+RFC1123              APPLICATIONS LAYER -- GENERAL          October 1989
+
+
+   2.5  GENERAL APPLICATION REQUIREMENTS SUMMARY
+
+                                               |          | | | |S| |
+                                               |          | | | |H| |F
+                                               |          | | | |O|M|o
+                                               |          | |S| |U|U|o
+                                               |          | |H| |L|S|t
+                                               |          |M|O| |D|T|n
+                                               |          |U|U|M| | |o
+                                               |          |S|L|A|N|N|t
+                                               |          |T|D|Y|O|O|t
+FEATURE                                        |SECTION   | | | |T|T|e
+-----------------------------------------------|----------|-|-|-|-|-|--
+                                               |          | | | | | |
+User interfaces:                               |          | | | | | |
+  Allow host name to begin with digit          |2.1       |x| | | | |
+  Host names of up to 635 characters           |2.1       |x| | | | |
+  Host names of up to 255 characters           |2.1       | |x| | | |
+  Support dotted-decimal host numbers          |2.1       | |x| | | |
+  Check syntactically for dotted-dec first     |2.1       | |x| | | |
+                                               |          | | | | | |
+Map domain names per Section 6.1               |2.2       |x| | | | |
+Cope with soft DNS errors                      |2.2       |x| | | | |
+   Reasonable interval between retries         |2.2       |x| | | | |
+   Allow for long outages                      |2.2       |x| | | | |
+Expect WKS records to be available             |2.2       | | | |x| |
+                                               |          | | | | | |
+Try multiple addr's for remote multihomed host |2.3       | |x| | | |
+UDP reply src addr is specific dest of request |2.3       | |x| | | |
+Use same IP addr for related TCP connections   |2.3       | |x| | | |
+Specify appropriate TOS values                 |2.4       |x| | | | |
+  TOS values configurable                      |2.4       |x| | | | |
+  Unused TOS bits zero                         |2.4       |x| | | | |
+                                               |          | | | | | |
+                                               |          | | | | | |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 15]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+3.  REMOTE LOGIN -- TELNET PROTOCOL
+
+   3.1  INTRODUCTION
+
+      Telnet is the standard Internet application protocol for remote
+      login.  It provides the encoding rules to link a user's
+      keyboard/display on a client ("user") system with a command
+      interpreter on a remote server system.  A subset of the Telnet
+      protocol is also incorporated within other application protocols,
+      e.g., FTP and SMTP.
+
+      Telnet uses a single TCP connection, and its normal data stream
+      ("Network Virtual Terminal" or "NVT" mode) is 7-bit ASCII with
+      escape sequences to embed control functions.  Telnet also allows
+      the negotiation of many optional modes and functions.
+
+      The primary Telnet specification is to be found in RFC-854
+      [TELNET:1], while the options are defined in many other RFCs; see
+      Section 7 for references.
+
+   3.2  PROTOCOL WALK-THROUGH
+
+      3.2.1  Option Negotiation: RFC-854, pp. 2-3
+
+         Every Telnet implementation MUST include option negotiation and
+         subnegotiation machinery [TELNET:2].
+
+         A host MUST carefully follow the rules of RFC-854 to avoid
+         option-negotiation loops.  A host MUST refuse (i.e, reply
+         WONT/DONT to a DO/WILL) an unsupported option.  Option
+         negotiation SHOULD continue to function (even if all requests
+         are refused) throughout the lifetime of a Telnet connection.
+
+         If all option negotiations fail, a Telnet implementation MUST
+         default to, and support, an NVT.
+
+         DISCUSSION:
+              Even though more sophisticated "terminals" and supporting
+              option negotiations are becoming the norm, all
+              implementations must be prepared to support an NVT for any
+              user-server communication.
+
+      3.2.2  Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858
+
+         On a host that never sends the Telnet command Go Ahead (GA),
+         the Telnet Server MUST attempt to negotiate the Suppress Go
+         Ahead option (i.e., send "WILL Suppress Go Ahead").  A User or
+         Server Telnet MUST always accept negotiation of the Suppress Go
+
+
+
+Internet Engineering Task Force                                [Page 16]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+         Ahead option.
+
+         When it is driving a full-duplex terminal for which GA has no
+         meaning, a User Telnet implementation MAY ignore GA commands.
+
+         DISCUSSION:
+              Half-duplex ("locked-keyboard") line-at-a-time terminals
+              for which the Go-Ahead mechanism was designed have largely
+              disappeared from the scene.  It turned out to be difficult
+              to implement sending the Go-Ahead signal in many operating
+              systems, even some systems that support native half-duplex
+              terminals.  The difficulty is typically that the Telnet
+              server code does not have access to information about
+              whether the user process is blocked awaiting input from
+              the Telnet connection, i.e., it cannot reliably determine
+              when to send a GA command.  Therefore, most Telnet Server
+              hosts do not send GA commands.
+
+              The effect of the rules in this section is to allow either
+              end of a Telnet connection to veto the use of GA commands.
+
+              There is a class of half-duplex terminals that is still
+              commercially important: "data entry terminals," which
+              interact in a full-screen manner.  However, supporting
+              data entry terminals using the Telnet protocol does not
+              require the Go Ahead signal; see Section 3.3.2.
+
+      3.2.3  Control Functions: RFC-854, pp. 7-8
+
+         The list of Telnet commands has been extended to include EOR
+         (End-of-Record), with code 239 [TELNET:9].
+
+         Both User and Server Telnets MAY support the control functions
+         EOR, EC, EL, and Break, and MUST support AO, AYT, DM, IP, NOP,
+         SB, and SE.
+
+         A host MUST be able to receive and ignore any Telnet control
+         functions that it does not support.
+
+         DISCUSSION:
+              Note that a Server Telnet is required to support the
+              Telnet IP (Interrupt Process) function, even if the server
+              host has an equivalent in-stream function (e.g., Control-C
+              in many systems).  The Telnet IP function may be stronger
+              than an in-stream interrupt command, because of the out-
+              of-band effect of TCP urgent data.
+
+              The EOR control function may be used to delimit the
+
+
+
+Internet Engineering Task Force                                [Page 17]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+              stream.  An important application is data entry terminal
+              support (see Section 3.3.2).  There was concern that since
+              EOR had not been defined in RFC-854, a host that was not
+              prepared to correctly ignore unknown Telnet commands might
+              crash if it received an EOR.  To protect such hosts, the
+              End-of-Record option [TELNET:9] was introduced; however, a
+              properly implemented Telnet program will not require this
+              protection.
+
+      3.2.4  Telnet "Synch" Signal: RFC-854, pp. 8-10
+
+         When it receives "urgent" TCP data, a User or Server Telnet
+         MUST discard all data except Telnet commands until the DM (and
+         end of urgent) is reached.
+
+         When it sends Telnet IP (Interrupt Process), a User Telnet
+         SHOULD follow it by the Telnet "Synch" sequence, i.e., send as
+         TCP urgent data the sequence "IAC IP IAC DM".  The TCP urgent
+         pointer points to the DM octet.
+
+         When it receives a Telnet IP command, a Server Telnet MAY send
+         a Telnet "Synch" sequence back to the user, to flush the output
+         stream.  The choice ought to be consistent with the way the
+         server operating system behaves when a local user interrupts a
+         process.
+
+         When it receives a Telnet AO command, a Server Telnet MUST send
+         a Telnet "Synch" sequence back to the user, to flush the output
+         stream.
+
+         A User Telnet SHOULD have the capability of flushing output
+         when it sends a Telnet IP; see also Section 3.4.5.
+
+         DISCUSSION:
+              There are three possible ways for a User Telnet to flush
+              the stream of server output data:
+
+              (1)  Send AO after IP.
+
+                   This will cause the server host to send a "flush-
+                   buffered-output" signal to its operating system.
+                   However, the AO may not take effect locally, i.e.,
+                   stop terminal output at the User Telnet end, until
+                   the Server Telnet has received and processed the AO
+                   and has sent back a "Synch".
+
+              (2)  Send DO TIMING-MARK [TELNET:7] after IP, and discard
+                   all output locally until a WILL/WONT TIMING-MARK is
+
+
+
+Internet Engineering Task Force                                [Page 18]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+                   received from the Server Telnet.
+
+                   Since the DO TIMING-MARK will be processed after the
+                   IP at the server, the reply to it should be in the
+                   right place in the output data stream.  However, the
+                   TIMING-MARK will not send a "flush buffered output"
+                   signal to the server operating system.  Whether or
+                   not this is needed is dependent upon the server
+                   system.
+
+              (3)  Do both.
+
+              The best method is not entirely clear, since it must
+              accommodate a number of existing server hosts that do not
+              follow the Telnet standards in various ways.  The safest
+              approach is probably to provide a user-controllable option
+              to select (1), (2), or (3).
+
+      3.2.5  NVT Printer and Keyboard: RFC-854, p. 11
+
+         In NVT mode, a Telnet SHOULD NOT send characters with the
+         high-order bit 1, and MUST NOT send it as a parity bit.
+         Implementations that pass the high-order bit to applications
+         SHOULD negotiate binary mode (see Section 3.2.6).
+
+
+         DISCUSSION:
+              Implementors should be aware that a strict reading of
+              RFC-854 allows a client or server expecting NVT ASCII to
+              ignore characters with the high-order bit set.  In
+              general, binary mode is expected to be used for
+              transmission of an extended (beyond 7-bit) character set
+              with Telnet.
+
+              However, there exist applications that really need an 8-
+              bit NVT mode, which is currently not defined, and these
+              existing applications do set the high-order bit during
+              part or all of the life of a Telnet connection.  Note that
+              binary mode is not the same as 8-bit NVT mode, since
+              binary mode turns off end-of-line processing.  For this
+              reason, the requirements on the high-order bit are stated
+              as SHOULD, not MUST.
+
+              RFC-854 defines a minimal set of properties of a "network
+              virtual terminal" or NVT; this is not meant to preclude
+              additional features in a real terminal.  A Telnet
+              connection is fully transparent to all 7-bit ASCII
+              characters, including arbitrary ASCII control characters.
+
+
+
+Internet Engineering Task Force                                [Page 19]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+              For example, a terminal might support full-screen commands
+              coded as ASCII escape sequences; a Telnet implementation
+              would pass these sequences as uninterpreted data.  Thus,
+              an NVT should not be conceived as a terminal type of a
+              highly-restricted device.
+
+      3.2.6  Telnet Command Structure: RFC-854, p. 13
+
+         Since options may appear at any point in the data stream, a
+         Telnet escape character (known as IAC, with the value 255) to
+         be sent as data MUST be doubled.
+
+      3.2.7  Telnet Binary Option: RFC-856
+
+         When the Binary option has been successfully negotiated,
+         arbitrary 8-bit characters are allowed.  However, the data
+         stream MUST still be scanned for IAC characters, any embedded
+         Telnet commands MUST be obeyed, and data bytes equal to IAC
+         MUST be doubled.  Other character processing (e.g., replacing
+         CR by CR NUL or by CR LF) MUST NOT be done.  In particular,
+         there is no end-of-line convention (see Section 3.3.1) in
+         binary mode.
+
+         DISCUSSION:
+              The Binary option is normally negotiated in both
+              directions, to change the Telnet connection from NVT mode
+              to "binary mode".
+
+              The sequence IAC EOR can be used to delimit blocks of data
+              within a binary-mode Telnet stream.
+
+      3.2.8  Telnet Terminal-Type Option: RFC-1091
+
+         The Terminal-Type option MUST use the terminal type names
+         officially defined in the Assigned Numbers RFC [INTRO:5], when
+         they are available for the particular terminal.  However, the
+         receiver of a Terminal-Type option MUST accept any name.
+
+         DISCUSSION:
+              RFC-1091 [TELNET:10] updates an earlier version of the
+              Terminal-Type option defined in RFC-930.  The earlier
+              version allowed a server host capable of supporting
+              multiple terminal types to learn the type of a particular
+              client's terminal, assuming that each physical terminal
+              had an intrinsic type.  However, today a "terminal" is
+              often really a terminal emulator program running in a PC,
+              perhaps capable of emulating a range of terminal types.
+              Therefore, RFC-1091 extends the specification to allow a
+
+
+
+Internet Engineering Task Force                                [Page 20]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+              more general terminal-type negotiation between User and
+              Server Telnets.
+
+   3.3  SPECIFIC ISSUES
+
+      3.3.1  Telnet End-of-Line Convention
+
+         The Telnet protocol defines the sequence CR LF to mean "end-
+         of-line".  For terminal input, this corresponds to a command-
+         completion or "end-of-line" key being pressed on a user
+         terminal; on an ASCII terminal, this is the CR key, but it may
+         also be labelled "Return" or "Enter".
+
+         When a Server Telnet receives the Telnet end-of-line sequence
+         CR LF as input from a remote terminal, the effect MUST be the
+         same as if the user had pressed the "end-of-line" key on a
+         local terminal.  On server hosts that use ASCII, in particular,
+         receipt of the Telnet sequence CR LF must cause the same effect
+         as a local user pressing the CR key on a local terminal.  Thus,
+         CR LF and CR NUL MUST have the same effect on an ASCII server
+         host when received as input over a Telnet connection.
+
+         A User Telnet MUST be able to send any of the forms: CR LF, CR
+         NUL, and LF.  A User Telnet on an ASCII host SHOULD have a
+         user-controllable mode to send either CR LF or CR NUL when the
+         user presses the "end-of-line" key, and CR LF SHOULD be the
+         default.
+
+         The Telnet end-of-line sequence CR LF MUST be used to send
+         Telnet data that is not terminal-to-computer (e.g., for Server
+         Telnet sending output, or the Telnet protocol incorporated
+         another application protocol).
+
+         DISCUSSION:
+              To allow interoperability between arbitrary Telnet clients
+              and servers, the Telnet protocol defined a standard
+              representation for a line terminator.  Since the ASCII
+              character set includes no explicit end-of-line character,
+              systems have chosen various representations, e.g., CR, LF,
+              and the sequence CR LF.  The Telnet protocol chose the CR
+              LF sequence as the standard for network transmission.
+
+              Unfortunately, the Telnet protocol specification in RFC-
+              854 [TELNET:1] has turned out to be somewhat ambiguous on
+              what character(s) should be sent from client to server for
+              the "end-of-line" key.  The result has been a massive and
+              continuing interoperability headache, made worse by
+              various faulty implementations of both User and Server
+
+
+
+Internet Engineering Task Force                                [Page 21]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+              Telnets.
+
+              Although the Telnet protocol is based on a perfectly
+              symmetric model, in a remote login session the role of the
+              user at a terminal differs from the role of the server
+              host.  For example, RFC-854 defines the meaning of CR, LF,
+              and CR LF as output from the server, but does not specify
+              what the User Telnet should send when the user presses the
+              "end-of-line" key on the terminal; this turns out to be
+              the point at issue.
+
+              When a user presses the "end-of-line" key, some User
+              Telnet implementations send CR LF, while others send CR
+              NUL (based on a different interpretation of the same
+              sentence in RFC-854).  These will be equivalent for a
+              correctly-implemented ASCII server host, as discussed
+              above.  For other servers, a mode in the User Telnet is
+              needed.
+
+              The existence of User Telnets that send only CR NUL when
+              CR is pressed creates a dilemma for non-ASCII hosts: they
+              can either treat CR NUL as equivalent to CR LF in input,
+              thus precluding the possibility of entering a "bare" CR,
+              or else lose complete interworking.
+
+              Suppose a user on host A uses Telnet to log into a server
+              host B, and then execute B's User Telnet program to log
+              into server host C.  It is desirable for the Server/User
+              Telnet combination on B to be as transparent as possible,
+              i.e., to appear as if A were connected directly to C.  In
+              particular, correct implementation will make B transparent
+              to Telnet end-of-line sequences, except that CR LF may be
+              translated to CR NUL or vice versa.
+
+         IMPLEMENTATION:
+              To understand Telnet end-of-line issues, one must have at
+              least a general model of the relationship of Telnet to the
+              local operating system.  The Server Telnet process is
+              typically coupled into the terminal driver software of the
+              operating system as a pseudo-terminal.  A Telnet end-of-
+              line sequence received by the Server Telnet must have the
+              same effect as pressing the end-of-line key on a real
+              locally-connected terminal.
+
+              Operating systems that support interactive character-at-
+              a-time applications (e.g., editors) typically have two
+              internal modes for their terminal I/O: a formatted mode,
+              in which local conventions for end-of-line and other
+
+
+
+Internet Engineering Task Force                                [Page 22]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+              formatting rules have been applied to the data stream, and
+              a "raw" mode, in which the application has direct access
+              to every character as it was entered.  A Server Telnet
+              must be implemented in such a way that these modes have
+              the same effect for remote as for local terminals.  For
+              example, suppose a CR LF or CR NUL is received by the
+              Server Telnet on an ASCII host.  In raw mode, a CR
+              character is passed to the application; in formatted mode,
+              the local system's end-of-line convention is used.
+
+      3.3.2  Data Entry Terminals
+
+         DISCUSSION:
+              In addition to the line-oriented and character-oriented
+              ASCII terminals for which Telnet was designed, there are
+              several families of video display terminals that are
+              sometimes known as "data entry terminals" or DETs.  The
+              IBM 3270 family is a well-known example.
+
+              Two Internet protocols have been designed to support
+              generic DETs: SUPDUP [TELNET:16, TELNET:17], and the DET
+              option [TELNET:18, TELNET:19].  The DET option drives a
+              data entry terminal over a Telnet connection using (sub-)
+              negotiation.  SUPDUP is a completely separate terminal
+              protocol, which can be entered from Telnet by negotiation.
+              Although both SUPDUP and the DET option have been used
+              successfully in particular environments, neither has
+              gained general acceptance or wide implementation.
+
+              A different approach to DET interaction has been developed
+              for supporting the IBM 3270 family through Telnet,
+              although the same approach would be applicable to any DET.
+              The idea is to enter a "native DET" mode, in which the
+              native DET input/output stream is sent as binary data.
+              The Telnet EOR command is used to delimit logical records
+              (e.g., "screens") within this binary stream.
+
+         IMPLEMENTATION:
+              The rules for entering and leaving native DET mode are as
+              follows:
+
+              o    The Server uses the Terminal-Type option [TELNET:10]
+                   to learn that the client is a DET.
+
+              o    It is conventional, but not required, that both ends
+                   negotiate the EOR option [TELNET:9].
+
+              o    Both ends negotiate the Binary option [TELNET:3] to
+
+
+
+Internet Engineering Task Force                                [Page 23]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+                   enter native DET mode.
+
+              o    When either end negotiates out of binary mode, the
+                   other end does too, and the mode then reverts to
+                   normal NVT.
+
+
+      3.3.3  Option Requirements
+
+         Every Telnet implementation MUST support the Binary option
+         [TELNET:3] and the Suppress Go Ahead option [TELNET:5], and
+         SHOULD support the Echo [TELNET:4], Status [TELNET:6], End-of-
+         Record [TELNET:9], and Extended Options List [TELNET:8]
+         options.
+
+         A User or Server Telnet SHOULD support the Window Size Option
+         [TELNET:12] if the local operating system provides the
+         corresponding capability.
+
+         DISCUSSION:
+              Note that the End-of-Record option only signifies that a
+              Telnet can receive a Telnet EOR without crashing;
+              therefore, every Telnet ought to be willing to accept
+              negotiation of the End-of-Record option.  See also the
+              discussion in Section 3.2.3.
+
+      3.3.4  Option Initiation
+
+         When the Telnet protocol is used in a client/server situation,
+         the server SHOULD initiate negotiation of the terminal
+         interaction mode it expects.
+
+         DISCUSSION:
+              The Telnet protocol was defined to be perfectly
+              symmetrical, but its application is generally asymmetric.
+              Remote login has been known to fail because NEITHER side
+              initiated negotiation of the required non-default terminal
+              modes.  It is generally the server that determines the
+              preferred mode, so the server needs to initiate the
+              negotiation; since the negotiation is symmetric, the user
+              can also initiate it.
+
+         A client (User Telnet) SHOULD provide a means for users to
+         enable and disable the initiation of option negotiation.
+
+         DISCUSSION:
+              A user sometimes needs to connect to an application
+              service (e.g., FTP or SMTP) that uses Telnet for its
+
+
+
+Internet Engineering Task Force                                [Page 24]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+              control stream but does not support Telnet options.  User
+              Telnet may be used for this purpose if initiation of
+              option negotiation is  disabled.
+
+      3.3.5  Telnet Linemode Option
+
+         DISCUSSION:
+              An important new Telnet option, LINEMODE [TELNET:12], has
+              been proposed.  The LINEMODE option provides a standard
+              way for a User Telnet and a Server Telnet to agree that
+              the client rather than the server will perform terminal
+              character processing.  When the client has prepared a
+              complete line of text, it will send it to the server in
+              (usually) one TCP packet.  This option will greatly
+              decrease the packet cost of Telnet sessions and will also
+              give much better user response over congested or long-
+              delay networks.
+
+              The LINEMODE option allows dynamic switching between local
+              and remote character processing.  For example, the Telnet
+              connection will automatically negotiate into single-
+              character mode while a full screen editor is running, and
+              then return to linemode when the editor is finished.
+
+              We expect that when this RFC is released, hosts should
+              implement the client side of this option, and may
+              implement the server side of this option.  To properly
+              implement the server side, the server needs to be able to
+              tell the local system not to do any input character
+              processing, but to remember its current terminal state and
+              notify the Server Telnet process whenever the state
+              changes.  This will allow password echoing and full screen
+              editors to be handled properly, for example.
+
+   3.4  TELNET/USER INTERFACE
+
+      3.4.1  Character Set Transparency
+
+         User Telnet implementations SHOULD be able to send or receive
+         any 7-bit ASCII character.  Where possible, any special
+         character interpretations by the user host's operating system
+         SHOULD be bypassed so that these characters can conveniently be
+         sent and received on the connection.
+
+         Some character value MUST be reserved as "escape to command
+         mode"; conventionally, doubling this character allows it to be
+         entered as data.  The specific character used SHOULD be user
+         selectable.
+
+
+
+Internet Engineering Task Force                                [Page 25]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+         On binary-mode connections, a User Telnet program MAY provide
+         an escape mechanism for entering arbitrary 8-bit values, if the
+         host operating system doesn't allow them to be entered directly
+         from the keyboard.
+
+         IMPLEMENTATION:
+              The transparency issues are less pressing on servers, but
+              implementors should take care in dealing with issues like:
+              masking off parity bits (sent by an older, non-conforming
+              client) before they reach programs that expect only NVT
+              ASCII, and properly handling programs that request 8-bit
+              data streams.
+
+      3.4.2  Telnet Commands
+
+         A User Telnet program MUST provide a user the capability of
+         entering any of the Telnet control functions IP, AO, or AYT,
+         and SHOULD provide the capability of entering EC, EL, and
+         Break.
+
+      3.4.3  TCP Connection Errors
+
+         A User Telnet program SHOULD report to the user any TCP errors
+         that are reported by the transport layer (see "TCP/Application
+         Layer Interface" section in [INTRO:1]).
+
+      3.4.4  Non-Default Telnet Contact Port
+
+         A User Telnet program SHOULD allow the user to optionally
+         specify a non-standard contact port number at the Server Telnet
+         host.
+
+      3.4.5  Flushing Output
+
+         A User Telnet program SHOULD provide the user the ability to
+         specify whether or not output should be flushed when an IP is
+         sent; see Section 3.2.4.
+
+         For any output flushing scheme that causes the User Telnet to
+         flush output locally until a Telnet signal is received from the
+         Server, there SHOULD be a way for the user to manually restore
+         normal output, in case the Server fails to send the expected
+         signal.
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 26]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+   3.5.  TELNET REQUIREMENTS SUMMARY
+
+
+                                                 |        | | | |S| |
+                                                 |        | | | |H| |F
+                                                 |        | | | |O|M|o
+                                                 |        | |S| |U|U|o
+                                                 |        | |H| |L|S|t
+                                                 |        |M|O| |D|T|n
+                                                 |        |U|U|M| | |o
+                                                 |        |S|L|A|N|N|t
+                                                 |        |T|D|Y|O|O|t
+FEATURE                                          |SECTION | | | |T|T|e
+-------------------------------------------------|--------|-|-|-|-|-|--
+                                                 |        | | | | | |
+Option Negotiation                               |3.2.1   |x| | | | |
+  Avoid negotiation loops                        |3.2.1   |x| | | | |
+  Refuse unsupported options                     |3.2.1   |x| | | | |
+  Negotiation OK anytime on connection           |3.2.1   | |x| | | |
+  Default to NVT                                 |3.2.1   |x| | | | |
+  Send official name in Term-Type option         |3.2.8   |x| | | | |
+  Accept any name in Term-Type option            |3.2.8   |x| | | | |
+  Implement Binary, Suppress-GA options          |3.3.3   |x| | | | |
+  Echo, Status, EOL, Ext-Opt-List options        |3.3.3   | |x| | | |
+  Implement Window-Size option if appropriate    |3.3.3   | |x| | | |
+  Server initiate mode negotiations              |3.3.4   | |x| | | |
+  User can enable/disable init negotiations      |3.3.4   | |x| | | |
+                                                 |        | | | | | |
+Go-Aheads                                        |        | | | | | |
+  Non-GA server negotiate SUPPRESS-GA option     |3.2.2   |x| | | | |
+  User or Server accept SUPPRESS-GA option       |3.2.2   |x| | | | |
+  User Telnet ignore GA's                        |3.2.2   | | |x| | |
+                                                 |        | | | | | |
+Control Functions                                |        | | | | | |
+  Support SE NOP DM IP AO AYT SB                 |3.2.3   |x| | | | |
+  Support EOR EC EL Break                        |3.2.3   | | |x| | |
+  Ignore unsupported control functions           |3.2.3   |x| | | | |
+  User, Server discard urgent data up to DM      |3.2.4   |x| | | | |
+  User Telnet send "Synch" after IP, AO, AYT     |3.2.4   | |x| | | |
+  Server Telnet reply Synch to IP                |3.2.4   | | |x| | |
+  Server Telnet reply Synch to AO                |3.2.4   |x| | | | |
+  User Telnet can flush output when send IP      |3.2.4   | |x| | | |
+                                                 |        | | | | | |
+Encoding                                         |        | | | | | |
+  Send high-order bit in NVT mode                |3.2.5   | | | |x| |
+  Send high-order bit as parity bit              |3.2.5   | | | | |x|
+  Negot. BINARY if pass high-ord. bit to applic  |3.2.5   | |x| | | |
+  Always double IAC data byte                    |3.2.6   |x| | | | |
+
+
+
+Internet Engineering Task Force                                [Page 27]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+  Double IAC data byte in binary mode            |3.2.7   |x| | | | |
+  Obey Telnet cmds in binary mode                |3.2.7   |x| | | | |
+  End-of-line, CR NUL in binary mode             |3.2.7   | | | | |x|
+                                                 |        | | | | | |
+End-of-Line                                      |        | | | | | |
+  EOL at Server same as local end-of-line        |3.3.1   |x| | | | |
+  ASCII Server accept CR LF or CR NUL for EOL    |3.3.1   |x| | | | |
+  User Telnet able to send CR LF, CR NUL, or LF  |3.3.1   |x| | | | |
+    ASCII user able to select CR LF/CR NUL       |3.3.1   | |x| | | |
+    User Telnet default mode is CR LF            |3.3.1   | |x| | | |
+  Non-interactive uses CR LF for EOL             |3.3.1   |x| | | | |
+                                                 |        | | | | | |
+User Telnet interface                            |        | | | | | |
+  Input & output all 7-bit characters            |3.4.1   | |x| | | |
+  Bypass local op sys interpretation             |3.4.1   | |x| | | |
+  Escape character                               |3.4.1   |x| | | | |
+     User-settable escape character              |3.4.1   | |x| | | |
+  Escape to enter 8-bit values                   |3.4.1   | | |x| | |
+  Can input IP, AO, AYT                          |3.4.2   |x| | | | |
+  Can input EC, EL, Break                        |3.4.2   | |x| | | |
+  Report TCP connection errors to user           |3.4.3   | |x| | | |
+  Optional non-default contact port              |3.4.4   | |x| | | |
+  Can spec: output flushed when IP sent          |3.4.5   | |x| | | |
+  Can manually restore output mode               |3.4.5   | |x| | | |
+                                                 |        | | | | | |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 28]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+4.  FILE TRANSFER
+
+   4.1  FILE TRANSFER PROTOCOL -- FTP
+
+      4.1.1  INTRODUCTION
+
+         The File Transfer Protocol FTP is the primary Internet standard
+         for file transfer.  The current specification is contained in
+         RFC-959 [FTP:1].
+
+         FTP uses separate simultaneous TCP connections for control and
+         for data transfer.  The FTP protocol includes many features,
+         some of which are not commonly implemented.  However, for every
+         feature in FTP, there exists at least one implementation.  The
+         minimum implementation defined in RFC-959 was too small, so a
+         somewhat larger minimum implementation is defined here.
+
+         Internet users have been unnecessarily burdened for years by
+         deficient FTP implementations.  Protocol implementors have
+         suffered from the erroneous opinion that implementing FTP ought
+         to be a small and trivial task.  This is wrong, because FTP has
+         a user interface, because it has to deal (correctly) with the
+         whole variety of communication and operating system errors that
+         may occur, and because it has to handle the great diversity of
+         real file systems in the world.
+
+      4.1.2.  PROTOCOL WALK-THROUGH
+
+         4.1.2.1  LOCAL Type: RFC-959 Section 3.1.1.4
+
+            An FTP program MUST support TYPE I ("IMAGE" or binary type)
+            as well as TYPE L 8 ("LOCAL" type with logical byte size 8).
+            A machine whose memory is organized into m-bit words, where
+            m is not a multiple of 8, MAY also support TYPE L m.
+
+            DISCUSSION:
+                 The command "TYPE L 8" is often required to transfer
+                 binary data between a machine whose memory is organized
+                 into (e.g.) 36-bit words and a machine with an 8-bit
+                 byte organization.  For an 8-bit byte machine, TYPE L 8
+                 is equivalent to IMAGE.
+
+                 "TYPE L m" is sometimes specified to the FTP programs
+                 on two m-bit word machines to ensure the correct
+                 transfer of a native-mode binary file from one machine
+                 to the other.  However, this command should have the
+                 same effect on these machines as "TYPE I".
+
+
+
+
+Internet Engineering Task Force                                [Page 29]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+         4.1.2.2  Telnet Format Control: RFC-959 Section 3.1.1.5.2
+
+            A host that makes no distinction between TYPE N and TYPE T
+            SHOULD implement TYPE T to be identical to TYPE N.
+
+            DISCUSSION:
+                 This provision should ease interoperation with hosts
+                 that do make this distinction.
+
+                 Many hosts represent text files internally as strings
+                 of ASCII characters, using the embedded ASCII format
+                 effector characters (LF, BS, FF, ...) to control the
+                 format when a file is printed.  For such hosts, there
+                 is no distinction between "print" files and other
+                 files.  However, systems that use record structured
+                 files typically need a special format for printable
+                 files (e.g., ASA carriage control).   For the latter
+                 hosts, FTP allows a choice of TYPE N or TYPE T.
+
+         4.1.2.3  Page Structure: RFC-959 Section 3.1.2.3 and Appendix I
+
+            Implementation of page structure is NOT RECOMMENDED in
+            general. However, if a host system does need to implement
+            FTP for "random access" or "holey" files, it MUST use the
+            defined page structure format rather than define a new
+            private FTP format.
+
+         4.1.2.4  Data Structure Transformations: RFC-959 Section 3.1.2
+
+            An FTP transformation between record-structure and file-
+            structure SHOULD be invertible, to the extent possible while
+            making the result useful on the target host.
+
+            DISCUSSION:
+                 RFC-959 required strict invertibility between record-
+                 structure and file-structure, but in practice,
+                 efficiency and convenience often preclude it.
+                 Therefore, the requirement is being relaxed.  There are
+                 two different objectives for transferring a file:
+                 processing it on the target host, or just storage.  For
+                 storage, strict invertibility is important.  For
+                 processing, the file created on the target host needs
+                 to be in the format expected by application programs on
+                 that host.
+
+                 As an example of the conflict, imagine a record-
+                 oriented operating system that requires some data files
+                 to have exactly 80 bytes in each record.  While STORing
+
+
+
+Internet Engineering Task Force                                [Page 30]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+                 a file on such a host, an FTP Server must be able to
+                 pad each line or record to 80 bytes; a later retrieval
+                 of such a file cannot be strictly invertible.
+
+         4.1.2.5  Data Connection Management: RFC-959 Section 3.3
+
+            A User-FTP that uses STREAM mode SHOULD send a PORT command
+            to assign a non-default data port before each transfer
+            command is issued.
+
+            DISCUSSION:
+                 This is required because of the long delay after a TCP
+                 connection is closed until its socket pair can be
+                 reused, to allow multiple transfers during a single FTP
+                 session.  Sending a port command can avoided if a
+                 transfer mode other than stream is used, by leaving the
+                 data transfer connection open between transfers.
+
+         4.1.2.6  PASV Command: RFC-959 Section 4.1.2
+
+            A server-FTP MUST implement the PASV command.
+
+            If multiple third-party transfers are to be executed during
+            the same session, a new PASV command MUST be issued before
+            each transfer command, to obtain a unique port pair.
+
+            IMPLEMENTATION:
+                 The format of the 227 reply to a PASV command is not
+                 well standardized.  In particular, an FTP client cannot
+                 assume that the parentheses shown on page 40 of RFC-959
+                 will be present (and in fact, Figure 3 on page 43 omits
+                 them).  Therefore, a User-FTP program that interprets
+                 the PASV reply must scan the reply for the first digit
+                 of the host and port numbers.
+
+                 Note that the host number h1,h2,h3,h4 is the IP address
+                 of the server host that is sending the reply, and that
+                 p1,p2 is a non-default data transfer port that PASV has
+                 assigned.
+
+         4.1.2.7  LIST and NLST Commands: RFC-959 Section 4.1.3
+
+            The data returned by an NLST command MUST contain only a
+            simple list of legal pathnames, such that the server can use
+            them directly as the arguments of subsequent data transfer
+            commands for the individual files.
+
+            The data returned by a LIST or NLST command SHOULD use an
+
+
+
+Internet Engineering Task Force                                [Page 31]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+            implied TYPE AN, unless the current type is EBCDIC, in which
+            case an implied TYPE EN SHOULD be used.
+
+            DISCUSSION:
+                 Many FTP clients support macro-commands that will get
+                 or put files matching a wildcard specification, using
+                 NLST to obtain a list of pathnames.  The expansion of
+                 "multiple-put" is local to the client, but "multiple-
+                 get" requires cooperation by the server.
+
+                 The implied type for LIST and NLST is designed to
+                 provide compatibility with existing User-FTPs, and in
+                 particular with multiple-get commands.
+
+         4.1.2.8  SITE Command: RFC-959 Section 4.1.3
+
+            A Server-FTP SHOULD use the SITE command for non-standard
+            features, rather than invent new private commands or
+            unstandardized extensions to existing commands.
+
+         4.1.2.9  STOU Command: RFC-959 Section 4.1.3
+
+            The STOU command stores into a uniquely named file.  When it
+            receives an STOU command, a Server-FTP MUST return the
+            actual file name in the "125 Transfer Starting" or the "150
+            Opening Data Connection" message that precedes the transfer
+            (the 250 reply code mentioned in RFC-959 is incorrect).  The
+            exact format of these messages is hereby defined to be as
+            follows:
+
+                125 FILE: pppp
+                150 FILE: pppp
+
+            where pppp represents the unique pathname of the file that
+            will be written.
+
+         4.1.2.10  Telnet End-of-line Code: RFC-959, Page 34
+
+            Implementors MUST NOT assume any correspondence between READ
+            boundaries on the control connection and the Telnet EOL
+            sequences (CR LF).
+
+            DISCUSSION:
+                 Thus, a server-FTP (or User-FTP) must continue reading
+                 characters from the control connection until a complete
+                 Telnet EOL sequence is encountered, before processing
+                 the command (or response, respectively).  Conversely, a
+                 single READ from the control connection may include
+
+
+
+Internet Engineering Task Force                                [Page 32]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+                 more than one FTP command.
+
+         4.1.2.11  FTP Replies: RFC-959 Section 4.2, Page 35
+
+            A Server-FTP MUST send only correctly formatted replies on
+            the control connection.  Note that RFC-959 (unlike earlier
+            versions of the FTP spec) contains no provision for a
+            "spontaneous" reply message.
+
+            A Server-FTP SHOULD use the reply codes defined in RFC-959
+            whenever they apply.  However, a server-FTP MAY use a
+            different reply code when needed, as long as the general
+            rules of Section 4.2 are followed. When the implementor has
+            a choice between a 4xx and 5xx reply code, a Server-FTP
+            SHOULD send a 4xx (temporary failure) code when there is any
+            reasonable possibility that a failed FTP will succeed a few
+            hours later.
+
+            A User-FTP SHOULD generally use only the highest-order digit
+            of a 3-digit reply code for making a procedural decision, to
+            prevent difficulties when a Server-FTP uses non-standard
+            reply codes.
+
+            A User-FTP MUST be able to handle multi-line replies.  If
+            the implementation imposes a limit on the number of lines
+            and if this limit is exceeded, the User-FTP MUST recover,
+            e.g., by ignoring the excess lines until the end of the
+            multi-line reply is reached.
+
+            A User-FTP SHOULD NOT interpret a 421 reply code ("Service
+            not available, closing control connection") specially, but
+            SHOULD detect closing of the control connection by the
+            server.
+
+            DISCUSSION:
+                 Server implementations that fail to strictly follow the
+                 reply rules often cause FTP user programs to hang.
+                 Note that RFC-959 resolved ambiguities in the reply
+                 rules found in earlier FTP specifications and must be
+                 followed.
+
+                 It is important to choose FTP reply codes that properly
+                 distinguish between temporary and permanent failures,
+                 to allow the successful use of file transfer client
+                 daemons.  These programs depend on the reply codes to
+                 decide whether or not to retry a failed transfer; using
+                 a permanent failure code (5xx) for a temporary error
+                 will cause these programs to give up unnecessarily.
+
+
+
+Internet Engineering Task Force                                [Page 33]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+                 When the meaning of a reply matches exactly the text
+                 shown in RFC-959, uniformity will be enhanced by using
+                 the RFC-959 text verbatim.  However, a Server-FTP
+                 implementor is encouraged to choose reply text that
+                 conveys specific system-dependent information, when
+                 appropriate.
+
+         4.1.2.12  Connections: RFC-959 Section 5.2
+
+            The words "and the port used" in the second paragraph of
+            this section of RFC-959 are erroneous (historical), and they
+            should be ignored.
+
+            On a multihomed server host, the default data transfer port
+            (L-1) MUST be associated with the same local IP address as
+            the corresponding control connection to port L.
+
+            A user-FTP MUST NOT send any Telnet controls other than
+            SYNCH and IP on an FTP control connection. In particular, it
+            MUST NOT attempt to negotiate Telnet options on the control
+            connection.  However, a server-FTP MUST be capable of
+            accepting and refusing Telnet negotiations (i.e., sending
+            DONT/WONT).
+
+            DISCUSSION:
+                 Although the RFC says: "Server- and User- processes
+                 should follow the conventions for the Telnet
+                 protocol...[on the control connection]", it is not the
+                 intent that Telnet option negotiation is to be
+                 employed.
+
+         4.1.2.13  Minimum Implementation; RFC-959 Section 5.1
+
+            The following commands and options MUST be supported by
+            every server-FTP and user-FTP, except in cases where the
+            underlying file system or operating system does not allow or
+            support a particular command.
+
+                 Type: ASCII Non-print, IMAGE, LOCAL 8
+                 Mode: Stream
+                 Structure: File, Record*
+                 Commands:
+                    USER, PASS, ACCT,
+                    PORT, PASV,
+                    TYPE, MODE, STRU,
+                    RETR, STOR, APPE,
+                    RNFR, RNTO, DELE,
+                    CWD,  CDUP, RMD,  MKD,  PWD,
+
+
+
+Internet Engineering Task Force                                [Page 34]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+                    LIST, NLST,
+                    SYST, STAT,
+                    HELP, NOOP, QUIT.
+
+            *Record structure is REQUIRED only for hosts whose file
+            systems support record structure.
+
+            DISCUSSION:
+                 Vendors are encouraged to implement a larger subset of
+                 the protocol.  For example, there are important
+                 robustness features in the protocol (e.g., Restart,
+                 ABOR, block mode) that would be an aid to some Internet
+                 users but are not widely implemented.
+
+                 A host that does not have record structures in its file
+                 system may still accept files with STRU R, recording
+                 the byte stream literally.
+
+      4.1.3  SPECIFIC ISSUES
+
+         4.1.3.1  Non-standard Command Verbs
+
+            FTP allows "experimental" commands, whose names begin with
+            "X".  If these commands are subsequently adopted as
+            standards, there may still be existing implementations using
+            the "X" form.  At present, this is true for the directory
+            commands:
+
+                RFC-959   "Experimental"
+
+                  MKD        XMKD
+                  RMD        XRMD
+                  PWD        XPWD
+                  CDUP       XCUP
+                  CWD        XCWD
+
+            All FTP implementations SHOULD recognize both forms of these
+            commands, by simply equating them with extra entries in the
+            command lookup table.
+
+            IMPLEMENTATION:
+                 A User-FTP can access a server that supports only the
+                 "X" forms by implementing a mode switch, or
+                 automatically using the following procedure: if the
+                 RFC-959 form of one of the above commands is rejected
+                 with a 500 or 502 response code, then try the
+                 experimental form; any other response would be passed
+                 to the user.
+
+
+
+Internet Engineering Task Force                                [Page 35]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+         4.1.3.2  Idle Timeout
+
+            A Server-FTP process SHOULD have an idle timeout, which will
+            terminate the process and close the control connection if
+            the server is inactive (i.e., no command or data transfer in
+            progress) for a long period of time.  The idle timeout time
+            SHOULD be configurable, and the default should be at least 5
+            minutes.
+
+            A client FTP process ("User-PI" in RFC-959) will need
+            timeouts on responses only if it is invoked from a program.
+
+            DISCUSSION:
+                 Without a timeout, a Server-FTP process may be left
+                 pending indefinitely if the corresponding client
+                 crashes without closing the control connection.
+
+         4.1.3.3  Concurrency of Data and Control
+
+            DISCUSSION:
+                 The intent of the designers of FTP was that a user
+                 should be able to send a STAT command at any time while
+                 data transfer was in progress and that the server-FTP
+                 would reply immediately with status -- e.g., the number
+                 of bytes transferred so far.  Similarly, an ABOR
+                 command should be possible at any time during a data
+                 transfer.
+
+                 Unfortunately, some small-machine operating systems
+                 make such concurrent programming difficult, and some
+                 other implementers seek minimal solutions, so some FTP
+                 implementations do not allow concurrent use of the data
+                 and control connections.  Even such a minimal server
+                 must be prepared to accept and defer a STAT or ABOR
+                 command that arrives during data transfer.
+
+         4.1.3.4  FTP Restart Mechanism
+
+            The description of the 110 reply on pp. 40-41 of RFC-959 is
+            incorrect; the correct description is as follows.  A restart
+            reply message, sent over the control connection from the
+            receiving FTP to the User-FTP, has the format:
+
+                110 MARK ssss = rrrr
+
+            Here:
+
+            *    ssss is a text string that appeared in a Restart Marker
+
+
+
+Internet Engineering Task Force                                [Page 36]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+                 in the data stream and encodes a position in the
+                 sender's file system;
+
+            *    rrrr encodes the corresponding position in the
+                 receiver's file system.
+
+            The encoding, which is specific to a particular file system
+            and network implementation, is always generated and
+            interpreted by the same system, either sender or receiver.
+
+            When an FTP that implements restart receives a Restart
+            Marker in the data stream, it SHOULD force the data to that
+            point to be written to stable storage before encoding the
+            corresponding position rrrr.  An FTP sending Restart Markers
+            MUST NOT assume that 110 replies will be returned
+            synchronously with the data, i.e., it must not await a 110
+            reply before sending more data.
+
+            Two new reply codes are hereby defined for errors
+            encountered in restarting a transfer:
+
+              554 Requested action not taken: invalid REST parameter.
+
+                 A 554 reply may result from a FTP service command that
+                 follows a REST command.  The reply indicates that the
+                 existing file at the Server-FTP cannot be repositioned
+                 as specified in the REST.
+
+              555 Requested action not taken: type or stru mismatch.
+
+                 A 555 reply may result from an APPE command or from any
+                 FTP service command following a REST command.  The
+                 reply indicates that there is some mismatch between the
+                 current transfer parameters (type and stru) and the
+                 attributes of the existing file.
+
+            DISCUSSION:
+                 Note that the FTP Restart mechanism requires that Block
+                 or Compressed mode be used for data transfer, to allow
+                 the Restart Markers to be included within the data
+                 stream.  The frequency of Restart Markers can be low.
+
+                 Restart Markers mark a place in the data stream, but
+                 the receiver may be performing some transformation on
+                 the data as it is stored into stable storage.  In
+                 general, the receiver's encoding must include any state
+                 information necessary to restart this transformation at
+                 any point of the FTP data stream.  For example, in TYPE
+
+
+
+Internet Engineering Task Force                                [Page 37]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+                 A transfers, some receiver hosts transform CR LF
+                 sequences into a single LF character on disk.   If a
+                 Restart Marker happens to fall between CR and LF, the
+                 receiver must encode in rrrr that the transfer must be
+                 restarted in a "CR has been seen and discarded" state.
+
+                 Note that the Restart Marker is required to be encoded
+                 as a string of printable ASCII characters, regardless
+                 of the type of the data.
+
+                 RFC-959 says that restart information is to be returned
+                 "to the user".  This should not be taken literally.  In
+                 general, the User-FTP should save the restart
+                 information (ssss,rrrr) in stable storage, e.g., append
+                 it to a restart control file.  An empty restart control
+                 file should be created when the transfer first starts
+                 and deleted automatically when the transfer completes
+                 successfully.  It is suggested that this file have a
+                 name derived in an easily-identifiable manner from the
+                 name of the file being transferred and the remote host
+                 name; this is analogous to the means used by many text
+                 editors for naming "backup" files.
+
+                 There are three cases for FTP restart.
+
+                 (1)  User-to-Server Transfer
+
+                      The User-FTP puts Restart Markers <ssss> at
+                      convenient places in the data stream.  When the
+                      Server-FTP receives a Marker, it writes all prior
+                      data to disk, encodes its file system position and
+                      transformation state as rrrr, and returns a "110
+                      MARK ssss = rrrr" reply over the control
+                      connection.  The User-FTP appends the pair
+                      (ssss,rrrr) to its restart control file.
+
+                      To restart the transfer, the User-FTP fetches the
+                      last (ssss,rrrr) pair from the restart control
+                      file, repositions its local file system and
+                      transformation state using ssss, and sends the
+                      command "REST rrrr" to the Server-FTP.
+
+                 (2)  Server-to-User Transfer
+
+                      The Server-FTP puts Restart Markers <ssss> at
+                      convenient places in the data stream.  When the
+                      User-FTP receives a Marker, it writes all prior
+                      data to disk, encodes its file system position and
+
+
+
+Internet Engineering Task Force                                [Page 38]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+                      transformation state as rrrr, and appends the pair
+                      (rrrr,ssss) to its restart control file.
+
+                      To restart the transfer, the User-FTP fetches the
+                      last (rrrr,ssss) pair from the restart control
+                      file, repositions its local file system and
+                      transformation state using rrrr, and sends the
+                      command "REST ssss" to the Server-FTP.
+
+                 (3)  Server-to-Server ("Third-Party") Transfer
+
+                      The sending Server-FTP puts Restart Markers <ssss>
+                      at convenient places in the data stream.  When it
+                      receives a Marker, the receiving Server-FTP writes
+                      all prior data to disk, encodes its file system
+                      position and transformation state as rrrr, and
+                      sends a "110 MARK ssss = rrrr" reply over the
+                      control connection to the User.  The User-FTP
+                      appends the pair (ssss,rrrr) to its restart
+                      control file.
+
+                      To restart the transfer, the User-FTP fetches the
+                      last (ssss,rrrr) pair from the restart control
+                      file, sends "REST ssss" to the sending Server-FTP,
+                      and sends "REST rrrr" to the receiving Server-FTP.
+
+
+      4.1.4  FTP/USER INTERFACE
+
+         This section discusses the user interface for a User-FTP
+         program.
+
+         4.1.4.1  Pathname Specification
+
+            Since FTP is intended for use in a heterogeneous
+            environment, User-FTP implementations MUST support remote
+            pathnames as arbitrary character strings, so that their form
+            and content are not limited by the conventions of the local
+            operating system.
+
+            DISCUSSION:
+                 In particular, remote pathnames can be of arbitrary
+                 length, and all the printing ASCII characters as well
+                 as space (0x20) must be allowed.  RFC-959 allows a
+                 pathname to contain any 7-bit ASCII character except CR
+                 or LF.
+
+
+
+
+
+Internet Engineering Task Force                                [Page 39]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+         4.1.4.2  "QUOTE" Command
+
+            A User-FTP program MUST implement a "QUOTE" command that
+            will pass an arbitrary character string to the server and
+            display all resulting response messages to the user.
+
+            To make the "QUOTE" command useful, a User-FTP SHOULD send
+            transfer control commands to the server as the user enters
+            them, rather than saving all the commands and sending them
+            to the server only when a data transfer is started.
+
+            DISCUSSION:
+                 The "QUOTE" command is essential to allow the user to
+                 access servers that require system-specific commands
+                 (e.g., SITE or ALLO), or to invoke new or optional
+                 features that are not implemented by the User-FTP.  For
+                 example, "QUOTE" may be used to specify "TYPE A T" to
+                 send a print file to hosts that require the
+                 distinction, even if the User-FTP does not recognize
+                 that TYPE.
+
+         4.1.4.3  Displaying Replies to User
+
+            A User-FTP SHOULD display to the user the full text of all
+            error reply messages it receives.  It SHOULD have a
+            "verbose" mode in which all commands it sends and the full
+            text and reply codes it receives are displayed, for
+            diagnosis of problems.
+
+         4.1.4.4  Maintaining Synchronization
+
+            The state machine in a User-FTP SHOULD be forgiving of
+            missing and unexpected reply messages, in order to maintain
+            command synchronization with the server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 40]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+      4.1.5   FTP REQUIREMENTS SUMMARY
+
+                                           |               | | | |S| |
+                                           |               | | | |H| |F
+                                           |               | | | |O|M|o
+                                           |               | |S| |U|U|o
+                                           |               | |H| |L|S|t
+                                           |               |M|O| |D|T|n
+                                           |               |U|U|M| | |o
+                                           |               |S|L|A|N|N|t
+                                           |               |T|D|Y|O|O|t
+FEATURE                                    |SECTION        | | | |T|T|e
+-------------------------------------------|---------------|-|-|-|-|-|--
+Implement TYPE T if same as TYPE N         |4.1.2.2        | |x| | | |
+File/Record transform invertible if poss.  |4.1.2.4        | |x| | | |
+User-FTP send PORT cmd for stream mode     |4.1.2.5        | |x| | | |
+Server-FTP implement PASV                  |4.1.2.6        |x| | | | |
+  PASV is per-transfer                     |4.1.2.6        |x| | | | |
+NLST reply usable in RETR cmds             |4.1.2.7        |x| | | | |
+Implied type for LIST and NLST             |4.1.2.7        | |x| | | |
+SITE cmd for non-standard features         |4.1.2.8        | |x| | | |
+STOU cmd return pathname as specified      |4.1.2.9        |x| | | | |
+Use TCP READ boundaries on control conn.   |4.1.2.10       | | | | |x|
+                                           |               | | | | | |
+Server-FTP send only correct reply format  |4.1.2.11       |x| | | | |
+Server-FTP use defined reply code if poss. |4.1.2.11       | |x| | | |
+  New reply code following Section 4.2     |4.1.2.11       | | |x| | |
+User-FTP use only high digit of reply      |4.1.2.11       | |x| | | |
+User-FTP handle multi-line reply lines     |4.1.2.11       |x| | | | |
+User-FTP handle 421 reply specially        |4.1.2.11       | | | |x| |
+                                           |               | | | | | |
+Default data port same IP addr as ctl conn |4.1.2.12       |x| | | | |
+User-FTP send Telnet cmds exc. SYNCH, IP   |4.1.2.12       | | | | |x|
+User-FTP negotiate Telnet options          |4.1.2.12       | | | | |x|
+Server-FTP handle Telnet options           |4.1.2.12       |x| | | | |
+Handle "Experimental" directory cmds       |4.1.3.1        | |x| | | |
+Idle timeout in server-FTP                 |4.1.3.2        | |x| | | |
+    Configurable idle timeout              |4.1.3.2        | |x| | | |
+Receiver checkpoint data at Restart Marker |4.1.3.4        | |x| | | |
+Sender assume 110 replies are synchronous  |4.1.3.4        | | | | |x|
+                                           |               | | | | | |
+Support TYPE:                              |               | | | | | |
+  ASCII - Non-Print (AN)                   |4.1.2.13       |x| | | | |
+  ASCII - Telnet (AT) -- if same as AN     |4.1.2.2        | |x| | | |
+  ASCII - Carriage Control (AC)            |959 3.1.1.5.2  | | |x| | |
+  EBCDIC - (any form)                      |959 3.1.1.2    | | |x| | |
+  IMAGE                                    |4.1.2.1        |x| | | | |
+  LOCAL 8                                  |4.1.2.1        |x| | | | |
+
+
+
+Internet Engineering Task Force                                [Page 41]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+  LOCAL m                                  |4.1.2.1        | | |x| | |2
+                                           |               | | | | | |
+Support MODE:                              |               | | | | | |
+  Stream                                   |4.1.2.13       |x| | | | |
+  Block                                    |959 3.4.2      | | |x| | |
+                                           |               | | | | | |
+Support STRUCTURE:                         |               | | | | | |
+  File                                     |4.1.2.13       |x| | | | |
+  Record                                   |4.1.2.13       |x| | | | |3
+  Page                                     |4.1.2.3        | | | |x| |
+                                           |               | | | | | |
+Support commands:                          |               | | | | | |
+  USER                                     |4.1.2.13       |x| | | | |
+  PASS                                     |4.1.2.13       |x| | | | |
+  ACCT                                     |4.1.2.13       |x| | | | |
+  CWD                                      |4.1.2.13       |x| | | | |
+  CDUP                                     |4.1.2.13       |x| | | | |
+  SMNT                                     |959 5.3.1      | | |x| | |
+  REIN                                     |959 5.3.1      | | |x| | |
+  QUIT                                     |4.1.2.13       |x| | | | |
+                                           |               | | | | | |
+  PORT                                     |4.1.2.13       |x| | | | |
+  PASV                                     |4.1.2.6        |x| | | | |
+  TYPE                                     |4.1.2.13       |x| | | | |1
+  STRU                                     |4.1.2.13       |x| | | | |1
+  MODE                                     |4.1.2.13       |x| | | | |1
+                                           |               | | | | | |
+  RETR                                     |4.1.2.13       |x| | | | |
+  STOR                                     |4.1.2.13       |x| | | | |
+  STOU                                     |959 5.3.1      | | |x| | |
+  APPE                                     |4.1.2.13       |x| | | | |
+  ALLO                                     |959 5.3.1      | | |x| | |
+  REST                                     |959 5.3.1      | | |x| | |
+  RNFR                                     |4.1.2.13       |x| | | | |
+  RNTO                                     |4.1.2.13       |x| | | | |
+  ABOR                                     |959 5.3.1      | | |x| | |
+  DELE                                     |4.1.2.13       |x| | | | |
+  RMD                                      |4.1.2.13       |x| | | | |
+  MKD                                      |4.1.2.13       |x| | | | |
+  PWD                                      |4.1.2.13       |x| | | | |
+  LIST                                     |4.1.2.13       |x| | | | |
+  NLST                                     |4.1.2.13       |x| | | | |
+  SITE                                     |4.1.2.8        | | |x| | |
+  STAT                                     |4.1.2.13       |x| | | | |
+  SYST                                     |4.1.2.13       |x| | | | |
+  HELP                                     |4.1.2.13       |x| | | | |
+  NOOP                                     |4.1.2.13       |x| | | | |
+                                           |               | | | | | |
+
+
+
+Internet Engineering Task Force                                [Page 42]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+User Interface:                            |               | | | | | |
+  Arbitrary pathnames                      |4.1.4.1        |x| | | | |
+  Implement "QUOTE" command                |4.1.4.2        |x| | | | |
+  Transfer control commands immediately    |4.1.4.2        | |x| | | |
+  Display error messages to user           |4.1.4.3        | |x| | | |
+    Verbose mode                           |4.1.4.3        | |x| | | |
+  Maintain synchronization with server     |4.1.4.4        | |x| | | |
+
+Footnotes:
+
+(1)  For the values shown earlier.
+
+(2)  Here m is number of bits in a memory word.
+
+(3)  Required for host with record-structured file system, optional
+     otherwise.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 43]
+
+
+
+
+RFC1123                  FILE TRANSFER -- TFTP              October 1989
+
+
+   4.2  TRIVIAL FILE TRANSFER PROTOCOL -- TFTP
+
+      4.2.1  INTRODUCTION
+
+         The Trivial File Transfer Protocol TFTP is defined in RFC-783
+         [TFTP:1].
+
+         TFTP provides its own reliable delivery with UDP as its
+         transport protocol, using a simple stop-and-wait acknowledgment
+         system.  Since TFTP has an effective window of only one 512
+         octet segment, it can provide good performance only over paths
+         that have a small delay*bandwidth product.  The TFTP file
+         interface is very simple, providing no access control or
+         security.
+
+         TFTP's most important application is bootstrapping a host over
+         a local network, since it is simple and small enough to be
+         easily implemented in EPROM [BOOT:1, BOOT:2].  Vendors are
+         urged to support TFTP for booting.
+
+      4.2.2  PROTOCOL WALK-THROUGH
+
+         The TFTP specification [TFTP:1] is written in an open style,
+         and does not fully specify many parts of the protocol.
+
+         4.2.2.1  Transfer Modes: RFC-783, Page 3
+
+            The transfer mode "mail" SHOULD NOT be supported.
+
+         4.2.2.2  UDP Header: RFC-783, Page 17
+
+            The Length field of a UDP header is incorrectly defined; it
+            includes the UDP header length (8).
+
+      4.2.3  SPECIFIC ISSUES
+
+         4.2.3.1  Sorcerer's Apprentice Syndrome
+
+            There is a serious bug, known as the "Sorcerer's Apprentice
+            Syndrome," in the protocol specification.  While it does not
+            cause incorrect operation of the transfer (the file will
+            always be transferred correctly if the transfer completes),
+            this bug may cause excessive retransmission, which may cause
+            the transfer to time out.
+
+            Implementations MUST contain the fix for this problem: the
+            sender (i.e., the side originating the DATA packets) must
+            never resend the current DATA packet on receipt of a
+
+
+
+Internet Engineering Task Force                                [Page 44]
+
+
+
+
+RFC1123                  FILE TRANSFER -- TFTP              October 1989
+
+
+            duplicate ACK.
+
+            DISCUSSION:
+                 The bug is caused by the protocol rule that either
+                 side, on receiving an old duplicate datagram, may
+                 resend the current datagram.  If a packet is delayed in
+                 the network but later successfully delivered after
+                 either side has timed out and retransmitted a packet, a
+                 duplicate copy of the response may be generated.  If
+                 the other side responds to this duplicate with a
+                 duplicate of its own, then every datagram will be sent
+                 in duplicate for the remainder of the transfer (unless
+                 a datagram is lost, breaking the repetition).  Worse
+                 yet, since the delay is often caused by congestion,
+                 this duplicate transmission will usually causes more
+                 congestion, leading to more delayed packets, etc.
+
+                 The following example may help to clarify this problem.
+
+                     TFTP A                  TFTP B
+
+                 (1)  Receive ACK X-1
+                      Send DATA X
+                 (2)                          Receive DATA X
+                                              Send ACK X
+                        (ACK X is delayed in network,
+                         and  A times out):
+                 (3)  Retransmit DATA X
+
+                 (4)                          Receive DATA X again
+                                              Send ACK X again
+                 (5)  Receive (delayed) ACK X
+                      Send DATA X+1
+                 (6)                          Receive DATA X+1
+                                              Send ACK X+1
+                 (7)  Receive ACK X again
+                      Send DATA X+1 again
+                 (8)                          Receive DATA X+1 again
+                                              Send ACK X+1 again
+                 (9)  Receive ACK X+1
+                      Send DATA X+2
+                 (10)                         Receive DATA X+2
+                                              Send ACK X+3
+                 (11) Receive ACK X+1 again
+                      Send DATA X+2 again
+                 (12)                         Receive DATA X+2 again
+                                              Send ACK X+3 again
+
+
+
+
+Internet Engineering Task Force                                [Page 45]
+
+
+
+
+RFC1123                  FILE TRANSFER -- TFTP              October 1989
+
+
+                 Notice that once the delayed ACK arrives, the protocol
+                 settles down to duplicate all further packets
+                 (sequences 5-8 and 9-12).  The problem is caused not by
+                 either side timing out, but by both sides
+                 retransmitting the current packet when they receive a
+                 duplicate.
+
+                 The fix is to break the retransmission loop, as
+                 indicated above.  This is analogous to the behavior of
+                 TCP.  It is then possible to remove the retransmission
+                 timer on the receiver, since the resent ACK will never
+                 cause any action; this is a useful simplification where
+                 TFTP is used in a bootstrap program.  It is OK to allow
+                 the timer to remain, and it may be helpful if the
+                 retransmitted ACK replaces one that was genuinely lost
+                 in the network.  The sender still requires a retransmit
+                 timer, of course.
+
+         4.2.3.2  Timeout Algorithms
+
+            A TFTP implementation MUST use an adaptive timeout.
+
+            IMPLEMENTATION:
+                 TCP retransmission algorithms provide a useful base to
+                 work from.  At least an exponential backoff of
+                 retransmission timeout is necessary.
+
+         4.2.3.3  Extensions
+
+            A variety of non-standard extensions have been made to TFTP,
+            including additional transfer modes and a secure operation
+            mode (with passwords).  None of these have been
+            standardized.
+
+         4.2.3.4  Access Control
+
+            A server TFTP implementation SHOULD include some
+            configurable access control over what pathnames are allowed
+            in TFTP operations.
+
+         4.2.3.5  Broadcast Request
+
+            A TFTP request directed to a broadcast address SHOULD be
+            silently ignored.
+
+            DISCUSSION:
+                 Due to the weak access control capability of TFTP,
+                 directed broadcasts of TFTP requests to random networks
+
+
+
+Internet Engineering Task Force                                [Page 46]
+
+
+
+
+RFC1123                  FILE TRANSFER -- TFTP              October 1989
+
+
+                 could create a significant security hole.
+
+      4.2.4  TFTP REQUIREMENTS SUMMARY
+
+                                                 |        | | | |S| |
+                                                 |        | | | |H| |F
+                                                 |        | | | |O|M|o
+                                                 |        | |S| |U|U|o
+                                                 |        | |H| |L|S|t
+                                                 |        |M|O| |D|T|n
+                                                 |        |U|U|M| | |o
+                                                 |        |S|L|A|N|N|t
+                                                 |        |T|D|Y|O|O|t
+FEATURE                                          |SECTION | | | |T|T|e
+-------------------------------------------------|--------|-|-|-|-|-|--
+Fix Sorcerer's Apprentice Syndrome               |4.2.3.1 |x| | | | |
+Transfer modes:                                  |        | | | | | |
+  netascii                                       |RFC-783 |x| | | | |
+  octet                                          |RFC-783 |x| | | | |
+  mail                                           |4.2.2.1 | | | |x| |
+  extensions                                     |4.2.3.3 | | |x| | |
+Use adaptive timeout                             |4.2.3.2 |x| | | | |
+Configurable access control                      |4.2.3.4 | |x| | | |
+Silently ignore broadcast request                |4.2.3.5 | |x| | | |
+-------------------------------------------------|--------|-|-|-|-|-|--
+-------------------------------------------------|--------|-|-|-|-|-|--
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 47]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+5.  ELECTRONIC MAIL -- SMTP and RFC-822
+
+   5.1  INTRODUCTION
+
+      In the TCP/IP protocol suite, electronic mail in a format
+      specified in RFC-822 [SMTP:2] is transmitted using the Simple Mail
+      Transfer Protocol (SMTP) defined in RFC-821 [SMTP:1].
+
+      While SMTP has remained unchanged over the years, the Internet
+      community has made several changes in the way SMTP is used.  In
+      particular, the conversion to the Domain Name System (DNS) has
+      caused changes in address formats and in mail routing.  In this
+      section, we assume familiarity with the concepts and terminology
+      of the DNS, whose requirements are given in Section 6.1.
+
+      RFC-822 specifies the Internet standard format for electronic mail
+      messages.  RFC-822 supercedes an older standard, RFC-733, that may
+      still be in use in a few places, although it is obsolete.  The two
+      formats are sometimes referred to simply by number ("822" and
+      "733").
+
+      RFC-822 is used in some non-Internet mail environments with
+      different mail transfer protocols than SMTP, and SMTP has also
+      been adapted for use in some non-Internet environments.  Note that
+      this document presents the rules for the use of SMTP and RFC-822
+      for the Internet environment only; other mail environments that
+      use these protocols may be expected to have their own rules.
+
+   5.2  PROTOCOL WALK-THROUGH
+
+      This section covers both RFC-821 and RFC-822.
+
+      The SMTP specification in RFC-821 is clear and contains numerous
+      examples, so implementors should not find it difficult to
+      understand.  This section simply updates or annotates portions of
+      RFC-821 to conform with current usage.
+
+      RFC-822 is a long and dense document, defining a rich syntax.
+      Unfortunately, incomplete or defective implementations of RFC-822
+      are common.  In fact, nearly all of the many formats of RFC-822
+      are actually used, so an implementation generally needs to
+      recognize and correctly interpret all of the RFC-822 syntax.
+
+      5.2.1  The SMTP Model: RFC-821 Section 2
+
+         DISCUSSION:
+              Mail is sent by a series of request/response transactions
+              between a client, the "sender-SMTP," and a server, the
+
+
+
+Internet Engineering Task Force                                [Page 48]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+              "receiver-SMTP".  These transactions pass (1) the message
+              proper, which is composed of header and body, and (2) SMTP
+              source and destination addresses, referred to as the
+              "envelope".
+
+              The SMTP programs are analogous to Message Transfer Agents
+              (MTAs) of X.400.  There will be another level of protocol
+              software, closer to the end user, that is responsible for
+              composing and analyzing RFC-822 message headers; this
+              component is known as the "User Agent" in X.400, and we
+              use that term in this document.  There is a clear logical
+              distinction between the User Agent and the SMTP
+              implementation, since they operate on different levels of
+              protocol.  Note, however, that this distinction is may not
+              be exactly reflected the structure of typical
+              implementations of Internet mail.  Often there is a
+              program known as the "mailer" that implements SMTP and
+              also some of the User Agent functions; the rest of the
+              User Agent functions are included in a user interface used
+              for entering and reading mail.
+
+              The SMTP envelope is constructed at the originating site,
+              typically by the User Agent when the message is first
+              queued for the Sender-SMTP program.  The envelope
+              addresses may be derived from information in the message
+              header, supplied by the user interface (e.g., to implement
+              a bcc: request), or derived from local configuration
+              information (e.g., expansion of a mailing list).  The SMTP
+              envelope cannot in general be re-derived from the header
+              at a later stage in message delivery, so the envelope is
+              transmitted separately from the message itself using the
+              MAIL and RCPT commands of SMTP.
+
+              The text of RFC-821 suggests that mail is to be delivered
+              to an individual user at a host.  With the advent of the
+              domain system and of mail routing using mail-exchange (MX)
+              resource records, implementors should now think of
+              delivering mail to a user at a domain, which may or may
+              not be a particular host.  This DOES NOT change the fact
+              that SMTP is a host-to-host mail exchange protocol.
+
+      5.2.2  Canonicalization: RFC-821 Section 3.1
+
+         The domain names that a Sender-SMTP sends in MAIL and RCPT
+         commands MUST have been  "canonicalized," i.e., they must be
+         fully-qualified principal names or domain literals, not
+         nicknames or domain abbreviations.  A canonicalized name either
+         identifies a host directly or is an MX name; it cannot be a
+
+
+
+Internet Engineering Task Force                                [Page 49]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         CNAME.
+
+      5.2.3  VRFY and EXPN Commands: RFC-821 Section 3.3
+
+         A receiver-SMTP MUST implement VRFY and SHOULD implement EXPN
+         (this requirement overrides RFC-821).  However, there MAY be
+         configuration information to disable VRFY and EXPN in a
+         particular installation; this might even allow EXPN to be
+         disabled for selected lists.
+
+         A new reply code is defined for the VRFY command:
+
+              252 Cannot VRFY user (e.g., info is not local), but will
+                  take message for this user and attempt delivery.
+
+         DISCUSSION:
+              SMTP users and administrators make regular use of these
+              commands for diagnosing mail delivery problems.  With the
+              increasing use of multi-level mailing list expansion
+              (sometimes more than two levels), EXPN has been
+              increasingly important for diagnosing inadvertent mail
+              loops.  On the other hand,  some feel that EXPN represents
+              a significant privacy, and perhaps even a security,
+              exposure.
+
+      5.2.4  SEND, SOML, and SAML Commands: RFC-821 Section 3.4
+
+         An SMTP MAY implement the commands to send a message to a
+         user's terminal: SEND, SOML, and SAML.
+
+         DISCUSSION:
+              It has been suggested that the use of mail relaying
+              through an MX record is inconsistent with the intent of
+              SEND to deliver a message immediately and directly to a
+              user's terminal.  However, an SMTP receiver that is unable
+              to write directly to the user terminal can return a "251
+              User Not Local" reply to the RCPT following a SEND, to
+              inform the originator of possibly deferred delivery.
+
+      5.2.5  HELO Command: RFC-821 Section 3.5
+
+         The sender-SMTP MUST ensure that the <domain> parameter in a
+         HELO command is a valid principal host domain name for the
+         client host.  As a result, the receiver-SMTP will not have to
+         perform MX resolution on this name in order to validate the
+         HELO parameter.
+
+         The HELO receiver MAY verify that the HELO parameter really
+
+
+
+Internet Engineering Task Force                                [Page 50]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         corresponds to the IP address of the sender.  However, the
+         receiver MUST NOT refuse to accept a message, even if the
+         sender's HELO command fails verification.
+
+         DISCUSSION:
+              Verifying the HELO parameter requires a domain name lookup
+              and may therefore take considerable time.  An alternative
+              tool for tracking bogus mail sources is suggested below
+              (see "DATA Command").
+
+              Note also that the HELO argument is still required to have
+              valid <domain> syntax, since it will appear in a Received:
+              line; otherwise, a 501 error is to be sent.
+
+         IMPLEMENTATION:
+              When HELO parameter validation fails, a suggested
+              procedure is to insert a note about the unknown
+              authenticity of the sender into the message header (e.g.,
+              in the "Received:"  line).
+
+      5.2.6  Mail Relay: RFC-821 Section 3.6
+
+         We distinguish three types of mail (store-and-) forwarding:
+
+         (1)  A simple forwarder or "mail exchanger" forwards a message
+              using private knowledge about the recipient; see section
+              3.2 of RFC-821.
+
+         (2)  An SMTP mail "relay" forwards a message within an SMTP
+              mail environment as the result of an explicit source route
+              (as defined in section 3.6 of RFC-821).  The SMTP relay
+              function uses the "@...:" form of source route from RFC-
+              822 (see Section 5.2.19 below).
+
+         (3)  A mail "gateway" passes a message between different
+              environments.  The rules for mail gateways are discussed
+              below in Section 5.3.7.
+
+         An Internet host that is forwarding a message but is not a
+         gateway to a different mail environment (i.e., it falls under
+         (1) or (2)) SHOULD NOT alter any existing header fields,
+         although the host will add an appropriate Received: line as
+         required in Section 5.2.8.
+
+         A Sender-SMTP SHOULD NOT send a RCPT TO: command containing an
+         explicit source route using the "@...:" address form.  Thus,
+         the relay function defined in section  3.6 of RFC-821 should
+         not be used.
+
+
+
+Internet Engineering Task Force                                [Page 51]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         DISCUSSION:
+              The intent is to discourage all source routing and to
+              abolish explicit source routing for mail delivery within
+              the Internet environment.  Source-routing is unnecessary;
+              the simple target address "user@domain" should always
+              suffice.  This is the result of an explicit architectural
+              decision to use universal naming rather than source
+              routing for mail.  Thus, SMTP provides end-to-end
+              connectivity, and the DNS provides globally-unique,
+              location-independent names.  MX records handle the major
+              case where source routing might otherwise be needed.
+
+         A receiver-SMTP MUST accept the explicit source route syntax in
+         the envelope, but it MAY implement the relay function as
+         defined in section 3.6 of RFC-821.  If it does not implement
+         the relay function, it SHOULD attempt to deliver the message
+         directly to the host to the right of the right-most "@" sign.
+
+         DISCUSSION:
+              For example, suppose a host that does not implement the
+              relay function receives a message with the SMTP command:
+              "RCPT TO:<@ALPHA,@BETA:joe@GAMMA>", where ALPHA, BETA, and
+              GAMMA represent domain names.  Rather than immediately
+              refusing the message with a 550 error reply as suggested
+              on page 20 of RFC-821, the host should try to forward the
+              message to GAMMA directly, using: "RCPT TO:<joe@GAMMA>".
+              Since this host does not support relaying, it is not
+              required to update the reverse path.
+
+              Some have suggested that source routing may be needed
+              occasionally for manually routing mail around failures;
+              however, the reality and importance of this need is
+              controversial.  The use of explicit SMTP mail relaying for
+              this purpose is discouraged, and in fact it may not be
+              successful, as many host systems do not support it.  Some
+              have used the "%-hack" (see Section 5.2.16) for this
+              purpose.
+
+      5.2.7  RCPT Command: RFC-821 Section 4.1.1
+
+         A host that supports a receiver-SMTP MUST support the reserved
+         mailbox "Postmaster".
+
+         The receiver-SMTP MAY verify RCPT parameters as they arrive;
+         however, RCPT responses MUST NOT be delayed beyond a reasonable
+         time (see Section 5.3.2).
+
+         Therefore, a "250 OK" response to a RCPT does not necessarily
+
+
+
+Internet Engineering Task Force                                [Page 52]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         imply that the delivery address(es) are valid.  Errors found
+         after message acceptance will be reported by mailing a
+         notification message to an appropriate address (see Section
+         5.3.3).
+
+         DISCUSSION:
+              The set of conditions under which a RCPT parameter can be
+              validated immediately is an engineering design choice.
+              Reporting destination mailbox errors to the Sender-SMTP
+              before mail is transferred is generally desirable to save
+              time and network bandwidth, but this advantage is lost if
+              RCPT verification is lengthy.
+
+              For example, the receiver can verify immediately any
+              simple local reference, such as a single locally-
+              registered mailbox.  On the other hand, the "reasonable
+              time" limitation generally implies deferring verification
+              of a mailing list until after the message has been
+              transferred and accepted, since verifying a large mailing
+              list can take a very long time.  An implementation might
+              or might not choose to defer validation of addresses that
+              are non-local and therefore require a DNS lookup.  If a
+              DNS lookup is performed but a soft domain system error
+              (e.g., timeout) occurs, validity must be assumed.
+
+      5.2.8  DATA Command: RFC-821 Section 4.1.1
+
+         Every receiver-SMTP (not just one that "accepts a message for
+         relaying or for final delivery" [SMTP:1]) MUST insert a
+         "Received:" line at the beginning of a message.  In this line,
+         called a "time stamp line" in RFC-821:
+
+         *    The FROM field SHOULD contain both (1) the name of the
+              source host as presented in the HELO command and (2) a
+              domain literal containing the IP address of the source,
+              determined from the TCP connection.
+
+         *    The ID field MAY contain an "@" as suggested in RFC-822,
+              but this is not required.
+
+         *    The FOR field MAY contain a list of <path> entries when
+              multiple RCPT commands have been given.
+
+
+         An Internet mail program MUST NOT change a Received: line that
+         was previously added to the message header.
+
+
+
+
+
+Internet Engineering Task Force                                [Page 53]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         DISCUSSION:
+              Including both the source host and the IP source address
+              in the Received: line may provide enough information for
+              tracking illicit mail sources and eliminate a need to
+              explicitly verify the HELO parameter.
+
+              Received: lines are primarily intended for humans tracing
+              mail routes, primarily of diagnosis of faults.  See also
+              the discussion under 5.3.7.
+
+         When the receiver-SMTP makes "final delivery" of a message,
+         then it MUST pass the MAIL FROM: address from the SMTP envelope
+         with the message, for use if an error notification message must
+         be sent later (see Section 5.3.3).  There is an analogous
+         requirement when gatewaying from the Internet into a different
+         mail environment; see Section 5.3.7.
+
+         DISCUSSION:
+              Note that the final reply to the DATA command depends only
+              upon the successful transfer and storage of the message.
+              Any problem with the destination address(es) must either
+              (1) have been reported in an SMTP error reply to the RCPT
+              command(s), or (2) be reported in a later error message
+              mailed to the originator.
+
+         IMPLEMENTATION:
+              The MAIL FROM: information may be passed as a parameter or
+              in a Return-Path: line inserted at the beginning of the
+              message.
+
+      5.2.9  Command Syntax: RFC-821 Section 4.1.2
+
+         The syntax shown in RFC-821 for the MAIL FROM: command omits
+         the case of an empty path:  "MAIL FROM: <>" (see RFC-821 Page
+         15).  An empty reverse path MUST be supported.
+
+      5.2.10  SMTP Replies:  RFC-821 Section 4.2
+
+         A receiver-SMTP SHOULD send only the reply codes listed in
+         section 4.2.2 of RFC-821 or in this document.  A receiver-SMTP
+         SHOULD use the text shown in examples in RFC-821 whenever
+         appropriate.
+
+         A sender-SMTP MUST determine its actions only by the reply
+         code, not by the text (except for 251 and 551 replies); any
+         text, including no text at all, must be acceptable.  The space
+         (blank) following the reply code is considered part of the
+         text.  Whenever possible, a sender-SMTP SHOULD test only the
+
+
+
+Internet Engineering Task Force                                [Page 54]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         first digit of the reply code, as specified in Appendix E of
+         RFC-821.
+
+         DISCUSSION:
+              Interoperability problems have arisen with SMTP systems
+              using reply codes that are not listed explicitly in RFC-
+              821 Section 4.3 but are legal according to the theory of
+              reply codes explained in Appendix E.
+
+      5.2.11  Transparency: RFC-821 Section 4.5.2
+
+         Implementors MUST be sure that their mail systems always add
+         and delete periods to ensure message transparency.
+
+      5.2.12  WKS Use in MX Processing: RFC-974, p. 5
+
+         RFC-974 [SMTP:3] recommended that the domain system be queried
+         for WKS ("Well-Known Service") records, to verify that each
+         proposed mail target does support SMTP.  Later experience has
+         shown that WKS is not widely supported, so the WKS step in MX
+         processing SHOULD NOT be used.
+
+      The following are notes on RFC-822, organized by section of that
+      document.
+
+      5.2.13  RFC-822 Message Specification: RFC-822 Section 4
+
+         The syntax shown for the Return-path line omits the possibility
+         of a null return path, which is used to prevent looping of
+         error notifications (see Section 5.3.3).  The complete syntax
+         is:
+
+             return = "Return-path"  ":" route-addr
+                    / "Return-path"  ":" "<" ">"
+
+         The set of optional header fields is hereby expanded to include
+         the Content-Type field defined in RFC-1049 [SMTP:7].  This
+         field "allows mail reading systems to automatically identify
+         the type of a structured message body and to process it for
+         display accordingly".  [SMTP:7]  A User Agent MAY support this
+         field.
+
+      5.2.14  RFC-822 Date and Time Specification: RFC-822 Section 5
+
+         The syntax for the date is hereby changed to:
+
+            date = 1*2DIGIT month 2*4DIGIT
+
+
+
+
+Internet Engineering Task Force                                [Page 55]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         All mail software SHOULD use 4-digit years in dates, to ease
+         the transition to the next century.
+
+         There is a strong trend towards the use of numeric timezone
+         indicators, and implementations SHOULD use numeric timezones
+         instead of timezone names.  However, all implementations MUST
+         accept either notation.  If timezone names are used, they MUST
+         be exactly as defined in RFC-822.
+
+         The military time zones are specified incorrectly in RFC-822:
+         they count the wrong way from UT (the signs are reversed).  As
+         a result, military time zones in RFC-822 headers carry no
+         information.
+
+         Finally, note that there is a typo in the definition of "zone"
+         in the syntax summary of appendix D; the correct definition
+         occurs in Section 3 of RFC-822.
+
+      5.2.15  RFC-822 Syntax Change: RFC-822 Section 6.1
+
+         The syntactic definition of "mailbox" in RFC-822 is hereby
+         changed to:
+
+            mailbox =  addr-spec            ; simple address
+                    / [phrase] route-addr   ; name & addr-spec
+
+         That is, the phrase preceding a route address is now OPTIONAL.
+         This change makes the following header field legal, for
+         example:
+
+             From: <craig@nnsc.nsf.net>
+
+      5.2.16  RFC-822  Local-part: RFC-822 Section 6.2
+
+         The basic mailbox address specification has the form: "local-
+         part@domain".  Here "local-part", sometimes called the "left-
+         hand side" of the address, is domain-dependent.
+
+         A host that is forwarding the message but is not the
+         destination host implied by the right-hand side "domain" MUST
+         NOT interpret or modify the "local-part" of the address.
+
+         When mail is to be gatewayed from the Internet mail environment
+         into a foreign mail environment (see Section 5.3.7), routing
+         information for that foreign environment MAY be embedded within
+         the "local-part" of the address.  The gateway will then
+         interpret this local part appropriately for the foreign mail
+         environment.
+
+
+
+Internet Engineering Task Force                                [Page 56]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         DISCUSSION:
+              Although source routes are discouraged within the Internet
+              (see Section 5.2.6), there are non-Internet mail
+              environments whose delivery mechanisms do depend upon
+              source routes.  Source routes for extra-Internet
+              environments can generally be buried in the "local-part"
+              of the address (see Section 5.2.16) while mail traverses
+              the Internet.  When the mail reaches the appropriate
+              Internet mail gateway, the gateway will interpret the
+              local-part and build the necessary address or route for
+              the target mail environment.
+
+              For example, an Internet host might send mail to:
+              "a!b!c!user@gateway-domain".  The complex local part
+              "a!b!c!user" would be uninterpreted within the Internet
+              domain, but could be parsed and understood by the
+              specified mail gateway.
+
+              An embedded source route is sometimes encoded in the
+              "local-part" using "%" as a right-binding routing
+              operator.  For example, in:
+
+                 user%domain%relay3%relay2@relay1
+
+              the "%" convention implies that the mail is to be routed
+              from "relay1" through "relay2", "relay3", and finally to
+              "user" at "domain".  This is commonly known as the "%-
+              hack".  It is suggested that "%" have lower precedence
+              than any other routing operator (e.g., "!") hidden in the
+              local-part; for example, "a!b%c" would be interpreted as
+              "(a!b)%c".
+
+              Only the target host (in this case, "relay1") is permitted
+              to analyze the local-part "user%domain%relay3%relay2".
+
+      5.2.17  Domain Literals: RFC-822 Section 6.2.3
+
+         A mailer MUST be able to accept and parse an Internet domain
+         literal whose content ("dtext"; see RFC-822) is a dotted-
+         decimal host address.  This satisfies the requirement of
+         Section 2.1 for the case of mail.
+
+         An SMTP MUST accept and recognize a domain literal for any of
+         its own IP addresses.
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 57]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+      5.2.18  Common Address Formatting Errors: RFC-822 Section 6.1
+
+         Errors in formatting or parsing 822 addresses are unfortunately
+         common.  This section mentions only the most common errors.  A
+         User Agent MUST accept all valid RFC-822 address formats, and
+         MUST NOT generate illegal address syntax.
+
+         o    A common error is to leave out the semicolon after a group
+              identifier.
+
+         o    Some systems fail to fully-qualify domain names in
+              messages they generate.  The right-hand side of an "@"
+              sign in a header address field MUST be a fully-qualified
+              domain name.
+
+              For example, some systems fail to fully-qualify the From:
+              address; this prevents a "reply" command in the user
+              interface from automatically constructing a return
+              address.
+
+              DISCUSSION:
+                   Although RFC-822 allows the local use of abbreviated
+                   domain names within a domain, the application of
+                   RFC-822 in Internet mail does not allow this.  The
+                   intent is that an Internet host must not send an SMTP
+                   message header containing an abbreviated domain name
+                   in an address field.  This allows the address fields
+                   of the header to be passed without alteration across
+                   the Internet, as required in Section 5.2.6.
+
+         o    Some systems mis-parse multiple-hop explicit source routes
+              such as:
+
+                  @relay1,@relay2,@relay3:user@domain.
+
+
+         o    Some systems over-qualify domain names by adding a
+              trailing dot to some or all domain names in addresses or
+              message-ids.  This violates RFC-822 syntax.
+
+
+      5.2.19  Explicit Source Routes: RFC-822 Section 6.2.7
+
+         Internet host software SHOULD NOT create an RFC-822 header
+         containing an address with an explicit source route, but MUST
+         accept such headers for compatibility with earlier systems.
+
+         DISCUSSION:
+
+
+
+Internet Engineering Task Force                                [Page 58]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+              In an understatement, RFC-822 says "The use of explicit
+              source routing is discouraged".  Many hosts implemented
+              RFC-822 source routes incorrectly, so the syntax cannot be
+              used unambiguously in practice.  Many users feel the
+              syntax is ugly.  Explicit source routes are not needed in
+              the mail envelope for delivery; see Section 5.2.6.  For
+              all these reasons, explicit source routes using the RFC-
+              822 notations are not to be used in Internet mail headers.
+
+              As stated in Section 5.2.16, it is necessary to allow an
+              explicit source route to be buried in the local-part of an
+              address, e.g., using the "%-hack", in order to allow mail
+              to be gatewayed into another environment in which explicit
+              source routing is necessary.  The vigilant will observe
+              that there is no way for a User Agent to detect and
+              prevent the use of such implicit source routing when the
+              destination is within the Internet.  We can only
+              discourage source routing of any kind within the Internet,
+              as unnecessary and undesirable.
+
+   5.3  SPECIFIC ISSUES
+
+      5.3.1  SMTP Queueing Strategies
+
+         The common structure of a host SMTP implementation includes
+         user mailboxes, one or more areas for queueing messages in
+         transit, and one or more daemon processes for sending and
+         receiving mail.  The exact structure will vary depending on the
+         needs of the users on the host and the number and size of
+         mailing lists supported by the host.  We describe several
+         optimizations that have proved helpful, particularly for
+         mailers supporting high traffic levels.
+
+         Any queueing strategy MUST include:
+
+         o    Timeouts on all activities.  See Section 5.3.2.
+
+         o    Never sending error messages in response to error
+              messages.
+
+
+         5.3.1.1 Sending Strategy
+
+            The general model of a sender-SMTP is one or more processes
+            that periodically attempt to transmit outgoing mail.  In a
+            typical system, the program that composes a message has some
+            method for requesting immediate attention for a new piece of
+            outgoing mail, while mail that cannot be transmitted
+
+
+
+Internet Engineering Task Force                                [Page 59]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+            immediately MUST be queued and periodically retried by the
+            sender.  A mail queue entry will include not only the
+            message itself but also the envelope information.
+
+            The sender MUST delay retrying a particular destination
+            after one attempt has failed.  In general, the retry
+            interval SHOULD be at least 30 minutes; however, more
+            sophisticated and variable strategies will be beneficial
+            when the sender-SMTP can determine the reason for non-
+            delivery.
+
+            Retries continue until the message is transmitted or the
+            sender gives up; the give-up time generally needs to be at
+            least 4-5 days.  The parameters to the retry algorithm MUST
+            be configurable.
+
+            A sender SHOULD keep a list of hosts it cannot reach and
+            corresponding timeouts, rather than just retrying queued
+            mail items.
+
+            DISCUSSION:
+                 Experience suggests that failures are typically
+                 transient (the target system has crashed), favoring a
+                 policy of two connection attempts in the first hour the
+                 message is in the queue, and then backing off to once
+                 every two or three hours.
+
+                 The sender-SMTP can shorten the queueing delay by
+                 cooperation with the receiver-SMTP.  In particular, if
+                 mail is received from a particular address, it is good
+                 evidence that any mail queued for that host can now be
+                 sent.
+
+                 The strategy may be further modified as a result of
+                 multiple addresses per host (see Section 5.3.4), to
+                 optimize delivery time vs. resource usage.
+
+                 A sender-SMTP may have a large queue of messages for
+                 each unavailable destination host, and if it retried
+                 all these messages in every retry cycle, there would be
+                 excessive Internet overhead and the daemon would be
+                 blocked for a long period.  Note that an SMTP can
+                 generally determine that a delivery attempt has failed
+                 only after a timeout of a minute or more; a one minute
+                 timeout per connection will result in a very large
+                 delay if it is repeated for dozens or even hundreds of
+                 queued messages.
+
+
+
+
+Internet Engineering Task Force                                [Page 60]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+            When the same message is to be delivered to several users on
+            the same host, only one copy of the message SHOULD be
+            transmitted.  That is, the sender-SMTP should use the
+            command sequence: RCPT, RCPT,... RCPT, DATA instead of the
+            sequence: RCPT, DATA, RCPT, DATA,... RCPT, DATA.
+            Implementation of this efficiency feature is strongly urged.
+
+            Similarly, the sender-SMTP MAY support multiple concurrent
+            outgoing mail transactions to achieve timely delivery.
+            However, some limit SHOULD be imposed to protect the host
+            from devoting all its resources to mail.
+
+            The use of the different addresses of a multihomed host is
+            discussed below.
+
+         5.3.1.2  Receiving strategy
+
+            The receiver-SMTP SHOULD attempt to keep a pending listen on
+            the SMTP port at all times.  This will require the support
+            of multiple incoming TCP connections for SMTP.  Some limit
+            MAY be imposed.
+
+            IMPLEMENTATION:
+                 When the receiver-SMTP receives mail from a particular
+                 host address, it could notify the sender-SMTP to retry
+                 any mail pending for that host address.
+
+      5.3.2  Timeouts in SMTP
+
+         There are two approaches to timeouts in the sender-SMTP:  (a)
+         limit the time for each SMTP command separately, or (b) limit
+         the time for the entire SMTP dialogue for a single mail
+         message.  A sender-SMTP SHOULD use option (a), per-command
+         timeouts.  Timeouts SHOULD be easily reconfigurable, preferably
+         without recompiling the SMTP code.
+
+         DISCUSSION:
+              Timeouts are an essential feature of an SMTP
+              implementation.  If the timeouts are too long (or worse,
+              there are no timeouts), Internet communication failures or
+              software bugs in receiver-SMTP programs can tie up SMTP
+              processes indefinitely.  If the timeouts are too short,
+              resources will be wasted with attempts that time out part
+              way through message delivery.
+
+              If option (b) is used, the timeout has to be very large,
+              e.g., an hour, to allow time to expand very large mailing
+              lists.  The timeout may also need to increase linearly
+
+
+
+Internet Engineering Task Force                                [Page 61]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+              with the size of the message, to account for the time to
+              transmit a very large message.  A large fixed timeout
+              leads to two problems:  a failure can still tie up the
+              sender for a very long time, and very large messages may
+              still spuriously time out (which is a wasteful failure!).
+
+              Using the recommended option (a), a timer is set for each
+              SMTP command and for each buffer of the data transfer.
+              The latter means that the overall timeout is inherently
+              proportional to the size of the message.
+
+         Based on extensive experience with busy mail-relay hosts, the
+         minimum per-command timeout values SHOULD be as follows:
+
+         o    Initial 220 Message: 5 minutes
+
+              A Sender-SMTP process needs to distinguish between a
+              failed TCP connection and a delay in receiving the initial
+              220 greeting message.  Many receiver-SMTPs will accept a
+              TCP connection but delay delivery of the 220 message until
+              their system load will permit more mail to be processed.
+
+         o    MAIL Command: 5 minutes
+
+
+         o    RCPT Command: 5 minutes
+
+              A longer timeout would be required if processing of
+              mailing lists and aliases were not deferred until after
+              the message was accepted.
+
+         o    DATA Initiation: 2 minutes
+
+              This is while awaiting the "354 Start Input" reply to a
+              DATA command.
+
+         o    Data Block: 3 minutes
+
+              This is while awaiting the completion of each TCP SEND
+              call transmitting a chunk of data.
+
+         o    DATA Termination: 10 minutes.
+
+              This is while awaiting the "250 OK" reply. When the
+              receiver gets the final period terminating the message
+              data, it typically performs processing to deliver the
+              message to a user mailbox.  A spurious timeout at this
+              point would be very wasteful, since the message has been
+
+
+
+Internet Engineering Task Force                                [Page 62]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+              successfully sent.
+
+         A receiver-SMTP SHOULD have a timeout of at least 5 minutes
+         while it is awaiting the next command from the sender.
+
+      5.3.3  Reliable Mail Receipt
+
+         When the receiver-SMTP accepts a piece of mail (by sending a
+         "250 OK" message in response to DATA), it is accepting
+         responsibility for delivering or relaying the message.  It must
+         take this responsibility seriously, i.e., it MUST NOT lose the
+         message for frivolous reasons, e.g., because the host later
+         crashes or because of a predictable resource shortage.
+
+         If there is a delivery failure after acceptance of a message,
+         the receiver-SMTP MUST formulate and mail a notification
+         message.  This notification MUST be sent using a null ("<>")
+         reverse path in the envelope; see Section 3.6 of RFC-821.  The
+         recipient of this notification SHOULD be the address from the
+         envelope return path (or the Return-Path: line).  However, if
+         this address is null ("<>"),  the receiver-SMTP MUST NOT send a
+         notification.  If the address is an explicit source route, it
+         SHOULD be stripped down to its final hop.
+
+         DISCUSSION:
+              For example, suppose that an error notification must be
+              sent for a message that arrived with:
+              "MAIL FROM:<@a,@b:user@d>".  The notification message
+              should be sent to: "RCPT TO:<user@d>".
+
+              Some delivery failures after the message is accepted by
+              SMTP will be unavoidable.  For example, it may be
+              impossible for the receiver-SMTP to validate all the
+              delivery addresses in RCPT command(s) due to a "soft"
+              domain system error or because the target is a mailing
+              list (see earlier discussion of RCPT).
+
+         To avoid receiving duplicate messages as the result of
+         timeouts, a receiver-SMTP MUST seek to minimize the time
+         required to respond to the final "." that ends a message
+         transfer.  See RFC-1047 [SMTP:4] for a discussion of this
+         problem.
+
+      5.3.4  Reliable Mail Transmission
+
+         To transmit a message, a sender-SMTP determines the IP address
+         of the target host from the destination address in the
+         envelope.  Specifically, it maps the string to the right of the
+
+
+
+Internet Engineering Task Force                                [Page 63]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         "@" sign into an IP address.  This mapping or the transfer
+         itself may fail with a soft error, in which case the sender-
+         SMTP will requeue the outgoing mail for a later retry, as
+         required in Section 5.3.1.1.
+
+         When it succeeds, the mapping can result in a list of
+         alternative delivery addresses rather than a single address,
+         because of (a) multiple MX records, (b) multihoming, or both.
+         To provide reliable mail transmission, the sender-SMTP MUST be
+         able to try (and retry) each of the addresses in this list in
+         order, until a delivery attempt succeeds.  However, there MAY
+         also be a configurable limit on the number of alternate
+         addresses that can be tried.  In any case, a host SHOULD try at
+         least two addresses.
+
+         The following information is to be used to rank the host
+         addresses:
+
+         (1)  Multiple MX Records -- these contain a preference
+              indication that should be used in sorting.  If there are
+              multiple destinations with the same preference and there
+              is no clear reason to favor one (e.g., by address
+              preference), then the sender-SMTP SHOULD pick one at
+              random to spread the load across multiple mail exchanges
+              for a specific organization; note that this is a
+              refinement of the procedure in [DNS:3].
+
+         (2)  Multihomed host -- The destination host (perhaps taken
+              from the preferred MX record) may be multihomed, in which
+              case the domain name resolver will return a list of
+              alternative IP addresses.  It is the responsibility of the
+              domain name resolver interface (see Section 6.1.3.4 below)
+              to have ordered this list by decreasing preference, and
+              SMTP MUST try them in the order presented.
+
+         DISCUSSION:
+              Although the capability to try multiple alternative
+              addresses is required, there may be circumstances where
+              specific installations want to limit or disable the use of
+              alternative addresses.  The question of whether a sender
+              should attempt retries using the different addresses of a
+              multihomed host has been controversial.  The main argument
+              for using the multiple addresses is that it maximizes the
+              probability of timely delivery, and indeed sometimes the
+              probability of any delivery; the counter argument is that
+              it may result in unnecessary resource use.
+
+              Note that resource use is also strongly determined by the
+
+
+
+Internet Engineering Task Force                                [Page 64]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+              sending strategy discussed in Section 5.3.1.
+
+      5.3.5  Domain Name Support
+
+         SMTP implementations MUST use the mechanism defined in Section
+         6.1 for mapping between domain names and IP addresses.  This
+         means that every Internet SMTP MUST include support for the
+         Internet DNS.
+
+         In particular, a sender-SMTP MUST support the MX record scheme
+         [SMTP:3].  See also Section 7.4 of [DNS:2] for information on
+         domain name support for SMTP.
+
+      5.3.6  Mailing Lists and Aliases
+
+         An SMTP-capable host SHOULD support both the alias and the list
+         form of address expansion for multiple delivery.  When a
+         message is delivered or forwarded to each address of an
+         expanded list form, the return address in the envelope
+         ("MAIL FROM:") MUST be changed to be the address of a person
+         who administers the list, but the message header MUST be left
+         unchanged; in particular, the "From" field of the message is
+         unaffected.
+
+         DISCUSSION:
+              An important mail facility is a mechanism for multi-
+              destination delivery of a single message, by transforming
+              or "expanding" a pseudo-mailbox address into a list of
+              destination mailbox addresses.  When a message is sent to
+              such a pseudo-mailbox (sometimes called an "exploder"),
+              copies are forwarded or redistributed to each mailbox in
+              the expanded list.  We classify such a pseudo-mailbox as
+              an "alias" or a "list", depending upon the expansion
+              rules:
+
+              (a)  Alias
+
+                   To expand an alias, the recipient mailer simply
+                   replaces the pseudo-mailbox address in the envelope
+                   with each of the expanded addresses in turn; the rest
+                   of the envelope and the message body are left
+                   unchanged.  The message is then delivered or
+                   forwarded to each expanded address.
+
+              (b)  List
+
+                   A mailing list may be said to operate by
+                   "redistribution" rather than by "forwarding".  To
+
+
+
+Internet Engineering Task Force                                [Page 65]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+                   expand a list, the recipient mailer replaces the
+                   pseudo-mailbox address in the envelope with each of
+                   the expanded addresses in turn. The return address in
+                   the envelope is changed so that all error messages
+                   generated by the final deliveries will be returned to
+                   a list administrator, not to the message originator,
+                   who generally has no control over the contents of the
+                   list and will typically find error messages annoying.
+
+
+      5.3.7  Mail Gatewaying
+
+         Gatewaying mail between different mail environments, i.e.,
+         different mail formats and protocols, is complex and does not
+         easily yield to standardization.  See for example [SMTP:5a],
+         [SMTP:5b].  However, some general requirements may be given for
+         a gateway between the Internet and another mail environment.
+
+         (A)  Header fields MAY be rewritten when necessary as messages
+              are gatewayed across mail environment boundaries.
+
+              DISCUSSION:
+                   This may involve interpreting the local-part of the
+                   destination address, as suggested in Section 5.2.16.
+
+                   The other mail systems gatewayed to the Internet
+                   generally use a subset of RFC-822 headers, but some
+                   of them do not have an equivalent to the SMTP
+                   envelope.  Therefore, when a message leaves the
+                   Internet environment, it may be necessary to fold the
+                   SMTP envelope information into the message header.  A
+                   possible solution would be to create new header
+                   fields to carry the envelope information (e.g., "X-
+                   SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this would
+                   require changes in mail programs in the foreign
+                   environment.
+
+         (B)  When forwarding a message into or out of the Internet
+              environment, a gateway MUST prepend a Received: line, but
+              it MUST NOT alter in any way a Received: line that is
+              already in the header.
+
+              DISCUSSION:
+                   This requirement is a subset of the general
+                   "Received:" line requirement of Section 5.2.8; it is
+                   restated here for emphasis.
+
+                   Received: fields of messages originating from other
+
+
+
+Internet Engineering Task Force                                [Page 66]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+                   environments may not conform exactly to RFC822.
+                   However, the most important use of Received: lines is
+                   for debugging mail faults, and this debugging can be
+                   severely hampered by well-meaning gateways that try
+                   to "fix" a Received: line.
+
+                   The gateway is strongly encouraged to indicate the
+                   environment and protocol in the "via" clauses of
+                   Received field(s) that it supplies.
+
+         (C)  From the Internet side, the gateway SHOULD accept all
+              valid address formats in SMTP commands and in RFC-822
+              headers, and all valid RFC-822 messages.  Although a
+              gateway must accept an RFC-822 explicit source route
+              ("@...:" format) in either the RFC-822 header or in the
+              envelope, it MAY or may not act on the source route; see
+              Sections 5.2.6 and 5.2.19.
+
+              DISCUSSION:
+                   It is often tempting to restrict the range of
+                   addresses accepted at the mail gateway to simplify
+                   the translation into addresses for the remote
+                   environment.  This practice is based on the
+                   assumption that mail users have control over the
+                   addresses their mailers send to the mail gateway.  In
+                   practice, however, users have little control over the
+                   addresses that are finally sent; their mailers are
+                   free to change addresses into any legal RFC-822
+                   format.
+
+         (D)  The gateway MUST ensure that all header fields of a
+              message that it forwards into the Internet meet the
+              requirements for Internet mail.  In particular, all
+              addresses in "From:", "To:", "Cc:", etc., fields must be
+              transformed (if necessary) to satisfy RFC-822 syntax, and
+              they must be effective and useful for sending replies.
+
+
+         (E)  The translation algorithm used to convert mail from the
+              Internet protocols to another environment's protocol
+              SHOULD try to ensure that error messages from the foreign
+              mail environment are delivered to the return path from the
+              SMTP envelope, not to the sender listed in the "From:"
+              field of the RFC-822 message.
+
+              DISCUSSION:
+                   Internet mail lists usually place the address of the
+                   mail list maintainer in the envelope but leave the
+
+
+
+Internet Engineering Task Force                                [Page 67]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+                   original message header intact (with the "From:"
+                   field containing the original sender).  This yields
+                   the behavior the average recipient expects: a reply
+                   to the header gets sent to the original sender, not
+                   to a mail list maintainer; however, errors get sent
+                   to the maintainer (who can fix the problem) and not
+                   the sender (who probably cannot).
+
+         (F)  Similarly, when forwarding a message from another
+              environment into the Internet, the gateway SHOULD set the
+              envelope return path in accordance with an error message
+              return address, if any, supplied by the foreign
+              environment.
+
+
+      5.3.8  Maximum Message Size
+
+         Mailer software MUST be able to send and receive messages of at
+         least 64K bytes in length (including header), and a much larger
+         maximum size is highly desirable.
+
+         DISCUSSION:
+              Although SMTP does not define the maximum size of a
+              message, many systems impose implementation limits.
+
+              The current de facto minimum limit in the Internet is 64K
+              bytes.  However, electronic mail is used for a variety of
+              purposes that create much larger messages.  For example,
+              mail is often used instead of FTP for transmitting ASCII
+              files, and in particular to transmit entire documents.  As
+              a result, messages can be 1 megabyte or even larger.  We
+              note that the present document together with its lower-
+              layer companion contains 0.5 megabytes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 68]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+   5.4  SMTP REQUIREMENTS SUMMARY
+
+                                               |          | | | |S| |
+                                               |          | | | |H| |F
+                                               |          | | | |O|M|o
+                                               |          | |S| |U|U|o
+                                               |          | |H| |L|S|t
+                                               |          |M|O| |D|T|n
+                                               |          |U|U|M| | |o
+                                               |          |S|L|A|N|N|t
+                                               |          |T|D|Y|O|O|t
+FEATURE                                        |SECTION   | | | |T|T|e
+-----------------------------------------------|----------|-|-|-|-|-|--
+                                               |          | | | | | |
+RECEIVER-SMTP:                                 |          | | | | | |
+  Implement VRFY                               |5.2.3     |x| | | | |
+  Implement EXPN                               |5.2.3     | |x| | | |
+    EXPN, VRFY configurable                    |5.2.3     | | |x| | |
+  Implement SEND, SOML, SAML                   |5.2.4     | | |x| | |
+  Verify HELO parameter                        |5.2.5     | | |x| | |
+    Refuse message with bad HELO               |5.2.5     | | | | |x|
+  Accept explicit src-route syntax in env.     |5.2.6     |x| | | | |
+  Support "postmaster"                         |5.2.7     |x| | | | |
+  Process RCPT when received (except lists)    |5.2.7     | | |x| | |
+      Long delay of RCPT responses             |5.2.7     | | | | |x|
+                                               |          | | | | | |
+  Add Received: line                           |5.2.8     |x| | | | |
+      Received: line include domain literal    |5.2.8     | |x| | | |
+  Change previous Received: line               |5.2.8     | | | | |x|
+  Pass Return-Path info (final deliv/gwy)      |5.2.8     |x| | | | |
+  Support empty reverse path                   |5.2.9     |x| | | | |
+  Send only official reply codes               |5.2.10    | |x| | | |
+  Send text from RFC-821 when appropriate      |5.2.10    | |x| | | |
+  Delete "." for transparency                  |5.2.11    |x| | | | |
+  Accept and recognize self domain literal(s)  |5.2.17    |x| | | | |
+                                               |          | | | | | |
+  Error message about error message            |5.3.1     | | | | |x|
+  Keep pending listen on SMTP port             |5.3.1.2   | |x| | | |
+  Provide limit on recv concurrency            |5.3.1.2   | | |x| | |
+  Wait at least 5 mins for next sender cmd     |5.3.2     | |x| | | |
+  Avoidable delivery failure after "250 OK"    |5.3.3     | | | | |x|
+  Send error notification msg after accept     |5.3.3     |x| | | | |
+    Send using null return path                |5.3.3     |x| | | | |
+    Send to envelope return path               |5.3.3     | |x| | | |
+    Send to null address                       |5.3.3     | | | | |x|
+    Strip off explicit src route               |5.3.3     | |x| | | |
+  Minimize acceptance delay (RFC-1047)         |5.3.3     |x| | | | |
+-----------------------------------------------|----------|-|-|-|-|-|--
+
+
+
+Internet Engineering Task Force                                [Page 69]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+                                               |          | | | | | |
+SENDER-SMTP:                                   |          | | | | | |
+  Canonicalized domain names in MAIL, RCPT     |5.2.2     |x| | | | |
+  Implement SEND, SOML, SAML                   |5.2.4     | | |x| | |
+  Send valid principal host name in HELO       |5.2.5     |x| | | | |
+  Send explicit source route in RCPT TO:       |5.2.6     | | | |x| |
+  Use only reply code to determine action      |5.2.10    |x| | | | |
+  Use only high digit of reply code when poss. |5.2.10    | |x| | | |
+  Add "." for transparency                     |5.2.11    |x| | | | |
+                                               |          | | | | | |
+  Retry messages after soft failure            |5.3.1.1   |x| | | | |
+    Delay before retry                         |5.3.1.1   |x| | | | |
+    Configurable retry parameters              |5.3.1.1   |x| | | | |
+    Retry once per each queued dest host       |5.3.1.1   | |x| | | |
+  Multiple RCPT's for same DATA                |5.3.1.1   | |x| | | |
+  Support multiple concurrent transactions     |5.3.1.1   | | |x| | |
+    Provide limit on concurrency               |5.3.1.1   | |x| | | |
+                                               |          | | | | | |
+  Timeouts on all activities                   |5.3.1     |x| | | | |
+    Per-command timeouts                       |5.3.2     | |x| | | |
+    Timeouts easily reconfigurable             |5.3.2     | |x| | | |
+    Recommended times                          |5.3.2     | |x| | | |
+  Try alternate addr's in order                |5.3.4     |x| | | | |
+    Configurable limit on alternate tries      |5.3.4     | | |x| | |
+    Try at least two alternates                |5.3.4     | |x| | | |
+  Load-split across equal MX alternates        |5.3.4     | |x| | | |
+  Use the Domain Name System                   |5.3.5     |x| | | | |
+    Support MX records                         |5.3.5     |x| | | | |
+    Use WKS records in MX processing           |5.2.12    | | | |x| |
+-----------------------------------------------|----------|-|-|-|-|-|--
+                                               |          | | | | | |
+MAIL FORWARDING:                               |          | | | | | |
+  Alter existing header field(s)               |5.2.6     | | | |x| |
+  Implement relay function: 821/section 3.6    |5.2.6     | | |x| | |
+    If not, deliver to RHS domain              |5.2.6     | |x| | | |
+  Interpret 'local-part' of addr               |5.2.16    | | | | |x|
+                                               |          | | | | | |
+MAILING LISTS AND ALIASES                      |          | | | | | |
+  Support both                                 |5.3.6     | |x| | | |
+  Report mail list error to local admin.       |5.3.6     |x| | | | |
+                                               |          | | | | | |
+MAIL GATEWAYS:                                 |          | | | | | |
+  Embed foreign mail route in local-part       |5.2.16    | | |x| | |
+  Rewrite header fields when necessary         |5.3.7     | | |x| | |
+  Prepend Received: line                       |5.3.7     |x| | | | |
+  Change existing Received: line               |5.3.7     | | | | |x|
+  Accept full RFC-822 on Internet side         |5.3.7     | |x| | | |
+  Act on RFC-822 explicit source route         |5.3.7     | | |x| | |
+
+
+
+Internet Engineering Task Force                                [Page 70]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+  Send only valid RFC-822 on Internet side     |5.3.7     |x| | | | |
+  Deliver error msgs to envelope addr          |5.3.7     | |x| | | |
+  Set env return path from err return addr     |5.3.7     | |x| | | |
+                                               |          | | | | | |
+USER AGENT -- RFC-822                          |          | | | | | |
+  Allow user to enter <route> address          |5.2.6     | | | |x| |
+  Support RFC-1049 Content Type field          |5.2.13    | | |x| | |
+  Use 4-digit years                            |5.2.14    | |x| | | |
+  Generate numeric timezones                   |5.2.14    | |x| | | |
+  Accept all timezones                         |5.2.14    |x| | | | |
+  Use non-num timezones from RFC-822           |5.2.14    |x| | | | |
+  Omit phrase before route-addr                |5.2.15    | | |x| | |
+  Accept and parse dot.dec. domain literals    |5.2.17    |x| | | | |
+  Accept all RFC-822 address formats           |5.2.18    |x| | | | |
+  Generate invalid RFC-822 address format      |5.2.18    | | | | |x|
+  Fully-qualified domain names in header       |5.2.18    |x| | | | |
+  Create explicit src route in header          |5.2.19    | | | |x| |
+  Accept explicit src route in header          |5.2.19    |x| | | | |
+                                               |          | | | | | |
+Send/recv at least 64KB messages               |5.3.8     |x| | | | |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 71]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+6. SUPPORT SERVICES
+
+   6.1 DOMAIN NAME TRANSLATION
+
+      6.1.1 INTRODUCTION
+
+         Every host MUST implement a resolver for the Domain Name System
+         (DNS), and it MUST implement a mechanism using this DNS
+         resolver to convert host names to IP addresses and vice-versa
+         [DNS:1, DNS:2].
+
+         In addition to the DNS, a host MAY also implement a host name
+         translation mechanism that searches a local Internet host
+         table.  See Section 6.1.3.8 for more information on this
+         option.
+
+         DISCUSSION:
+              Internet host name translation was originally performed by
+              searching local copies of a table of all hosts.  This
+              table became too large to update and distribute in a
+              timely manner and too large to fit into many hosts, so the
+              DNS was invented.
+
+              The DNS creates a distributed database used primarily for
+              the translation between host names and host addresses.
+              Implementation of DNS software is required.  The DNS
+              consists of two logically distinct parts: name servers and
+              resolvers (although implementations often combine these
+              two logical parts in the interest of efficiency) [DNS:2].
+
+              Domain name servers store authoritative data about certain
+              sections of the database and answer queries about the
+              data.  Domain resolvers query domain name servers for data
+              on behalf of user processes.  Every host therefore needs a
+              DNS resolver; some host machines will also need to run
+              domain name servers.  Since no name server has complete
+              information, in general it is necessary to obtain
+              information from more than one name server to resolve a
+              query.
+
+      6.1.2  PROTOCOL WALK-THROUGH
+
+         An implementor must study references [DNS:1] and [DNS:2]
+         carefully.  They provide a thorough description of the theory,
+         protocol, and implementation of the domain name system, and
+         reflect several years of experience.
+
+
+
+
+
+Internet Engineering Task Force                                [Page 72]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+         6.1.2.1  Resource Records with Zero TTL: RFC-1035 Section 3.2.1
+
+            All DNS name servers and resolvers MUST properly handle RRs
+            with a zero TTL: return the RR to the client but do not
+            cache it.
+
+            DISCUSSION:
+                 Zero TTL values are interpreted to mean that the RR can
+                 only be used for the transaction in progress, and
+                 should not be cached; they are useful for extremely
+                 volatile data.
+
+         6.1.2.2  QCLASS Values: RFC-1035 Section 3.2.5
+
+            A query with "QCLASS=*" SHOULD NOT be used unless the
+            requestor is seeking data from more than one class.  In
+            particular, if the requestor is only interested in Internet
+            data types, QCLASS=IN MUST be used.
+
+         6.1.2.3  Unused Fields: RFC-1035 Section 4.1.1
+
+            Unused fields in a query or response message MUST be zero.
+
+         6.1.2.4  Compression: RFC-1035 Section 4.1.4
+
+            Name servers MUST use compression in responses.
+
+            DISCUSSION:
+                 Compression is essential to avoid overflowing UDP
+                 datagrams; see Section 6.1.3.2.
+
+         6.1.2.5  Misusing Configuration Info: RFC-1035 Section 6.1.2
+
+            Recursive name servers and full-service resolvers generally
+            have some configuration information containing hints about
+            the location of root or local name servers.  An
+            implementation MUST NOT include any of these hints in a
+            response.
+
+            DISCUSSION:
+                 Many implementors have found it convenient to store
+                 these hints as if they were cached data, but some
+                 neglected to ensure that this "cached data" was not
+                 included in responses.  This has caused serious
+                 problems in the Internet when the hints were obsolete
+                 or incorrect.
+
+
+
+
+
+Internet Engineering Task Force                                [Page 73]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+      6.1.3  SPECIFIC ISSUES
+
+         6.1.3.1  Resolver Implementation
+
+            A name resolver SHOULD be able to multiplex concurrent
+            requests if the host supports concurrent processes.
+
+            In implementing a DNS resolver, one of two different models
+            MAY optionally be chosen: a full-service resolver, or a stub
+            resolver.
+
+
+            (A)  Full-Service Resolver
+
+                 A full-service resolver is a complete implementation of
+                 the resolver service, and is capable of dealing with
+                 communication failures, failure of individual name
+                 servers, location of the proper name server for a given
+                 name, etc.  It must satisfy the following requirements:
+
+                 o    The resolver MUST implement a local caching
+                      function to avoid repeated remote access for
+                      identical requests, and MUST time out information
+                      in the cache.
+
+                 o    The resolver SHOULD be configurable with start-up
+                      information pointing to multiple root name servers
+                      and multiple name servers for the local domain.
+                      This insures that the resolver will be able to
+                      access the whole name space in normal cases, and
+                      will be able to access local domain information
+                      should the local network become disconnected from
+                      the rest of the Internet.
+
+
+            (B)  Stub Resolver
+
+                 A "stub resolver" relies on the services of a recursive
+                 name server on the connected network or a "nearby"
+                 network.  This scheme allows the host to pass on the
+                 burden of the resolver function to a name server on
+                 another host.  This model is often essential for less
+                 capable hosts, such as PCs, and is also recommended
+                 when the host is one of several workstations on a local
+                 network, because it allows all of the workstations to
+                 share the cache of the recursive name server and hence
+                 reduce the number of domain requests exported by the
+                 local network.
+
+
+
+Internet Engineering Task Force                                [Page 74]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+                 At a minimum, the stub resolver MUST be capable of
+                 directing its requests to redundant recursive name
+                 servers.  Note that recursive name servers are allowed
+                 to restrict the sources of requests that they will
+                 honor, so the host administrator must verify that the
+                 service will be provided.  Stub resolvers MAY implement
+                 caching if they choose, but if so, MUST timeout cached
+                 information.
+
+
+         6.1.3.2  Transport Protocols
+
+            DNS resolvers and recursive servers MUST support UDP, and
+            SHOULD support TCP, for sending (non-zone-transfer) queries.
+            Specifically, a DNS resolver or server that is sending a
+            non-zone-transfer query MUST send a UDP query first.  If the
+            Answer section of the response is truncated and if the
+            requester supports TCP, it SHOULD try the query again using
+            TCP.
+
+            DNS servers MUST be able to service UDP queries and SHOULD
+            be able to service TCP queries.  A name server MAY limit the
+            resources it devotes to TCP queries, but it SHOULD NOT
+            refuse to service a TCP query just because it would have
+            succeeded with UDP.
+
+            Truncated responses MUST NOT be saved (cached) and later
+            used in such a way that the fact that they are truncated is
+            lost.
+
+            DISCUSSION:
+                 UDP is preferred over TCP for queries because UDP
+                 queries have much lower overhead, both in packet count
+                 and in connection state.  The use of UDP is essential
+                 for heavily-loaded servers, especially the root
+                 servers.  UDP also offers additional robustness, since
+                 a resolver can attempt several UDP queries to different
+                 servers for the cost of a single TCP query.
+
+                 It is possible for a DNS response to be truncated,
+                 although this is a very rare occurrence in the present
+                 Internet DNS.  Practically speaking, truncation cannot
+                 be predicted, since it is data-dependent.  The
+                 dependencies include the number of RRs in the answer,
+                 the size of each RR, and the savings in space realized
+                 by the name compression algorithm.  As a rule of thumb,
+                 truncation in NS and MX lists should not occur for
+                 answers containing 15 or fewer RRs.
+
+
+
+Internet Engineering Task Force                                [Page 75]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+                 Whether it is possible to use a truncated answer
+                 depends on the application.  A mailer must not use a
+                 truncated MX response, since this could lead to mail
+                 loops.
+
+                 Responsible practices can make UDP suffice in the vast
+                 majority of cases.  Name servers must use compression
+                 in responses.  Resolvers must differentiate truncation
+                 of the Additional section of a response (which only
+                 loses extra information) from truncation of the Answer
+                 section (which for MX records renders the response
+                 unusable by mailers).  Database administrators should
+                 list only a reasonable number of primary names in lists
+                 of name servers, MX alternatives, etc.
+
+                 However, it is also clear that some new DNS record
+                 types defined in the future will contain information
+                 exceeding the 512 byte limit that applies to UDP, and
+                 hence will require TCP.  Thus, resolvers and name
+                 servers should implement TCP services as a backup to
+                 UDP today, with the knowledge that they will require
+                 the TCP service in the future.
+
+            By private agreement, name servers and resolvers MAY arrange
+            to use TCP for all traffic between themselves.  TCP MUST be
+            used for zone transfers.
+
+            A DNS server MUST have sufficient internal concurrency that
+            it can continue to process UDP queries while awaiting a
+            response or performing a zone transfer on an open TCP
+            connection [DNS:2].
+
+            A server MAY support a UDP query that is delivered using an
+            IP broadcast or multicast address.  However, the Recursion
+            Desired bit MUST NOT be set in a query that is multicast,
+            and MUST be ignored by name servers receiving queries via a
+            broadcast or multicast address.  A host that sends broadcast
+            or multicast DNS queries SHOULD send them only as occasional
+            probes, caching the IP address(es) it obtains from the
+            response(s) so it can normally send unicast queries.
+
+            DISCUSSION:
+                 Broadcast or (especially) IP multicast can provide a
+                 way to locate nearby name servers without knowing their
+                 IP addresses in advance.  However, general broadcasting
+                 of recursive queries can result in excessive and
+                 unnecessary load on both network and servers.
+
+
+
+
+Internet Engineering Task Force                                [Page 76]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+         6.1.3.3  Efficient Resource Usage
+
+            The following requirements on servers and resolvers are very
+            important to the health of the Internet as a whole,
+            particularly when DNS services are invoked repeatedly by
+            higher level automatic servers, such as mailers.
+
+            (1)  The resolver MUST implement retransmission controls to
+                 insure that it does not waste communication bandwidth,
+                 and MUST impose finite bounds on the resources consumed
+                 to respond to a single request.  See [DNS:2] pages 43-
+                 44 for specific recommendations.
+
+            (2)  After a query has been retransmitted several times
+                 without a response, an implementation MUST give up and
+                 return a soft error to the application.
+
+            (3)  All DNS name servers and resolvers SHOULD cache
+                 temporary failures, with a timeout period of the order
+                 of minutes.
+
+                 DISCUSSION:
+                      This will prevent applications that immediately
+                      retry soft failures (in violation of Section 2.2
+                      of this document) from generating excessive DNS
+                      traffic.
+
+            (4)  All DNS name servers and resolvers SHOULD cache
+                 negative responses that indicate the specified name, or
+                 data of the specified type, does not exist, as
+                 described in [DNS:2].
+
+            (5)  When a DNS server or resolver retries a UDP query, the
+                 retry interval SHOULD be constrained by an exponential
+                 backoff algorithm, and SHOULD also have upper and lower
+                 bounds.
+
+                 IMPLEMENTATION:
+                      A measured RTT and variance (if available) should
+                      be used to calculate an initial retransmission
+                      interval.  If this information is not available, a
+                      default of no less than 5 seconds should be used.
+                      Implementations may limit the retransmission
+                      interval, but this limit must exceed twice the
+                      Internet maximum segment lifetime plus service
+                      delay at the name server.
+
+            (6)  When a resolver or server receives a Source Quench for
+
+
+
+Internet Engineering Task Force                                [Page 77]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+                 a query it has issued, it SHOULD take steps to reduce
+                 the rate of querying that server in the near future.  A
+                 server MAY ignore a Source Quench that it receives as
+                 the result of sending a response datagram.
+
+                 IMPLEMENTATION:
+                      One recommended action to reduce the rate is to
+                      send the next query attempt to an alternate
+                      server, if there is one available.  Another is to
+                      backoff the retry interval for the same server.
+
+
+         6.1.3.4  Multihomed Hosts
+
+            When the host name-to-address function encounters a host
+            with multiple addresses, it SHOULD rank or sort the
+            addresses using knowledge of the immediately connected
+            network number(s) and any other applicable performance or
+            history information.
+
+            DISCUSSION:
+                 The different addresses of a multihomed host generally
+                 imply different Internet paths, and some paths may be
+                 preferable to others in performance, reliability, or
+                 administrative restrictions.  There is no general way
+                 for the domain system to determine the best path.  A
+                 recommended approach is to base this decision on local
+                 configuration information set by the system
+                 administrator.
+
+            IMPLEMENTATION:
+                 The following scheme has been used successfully:
+
+                 (a)  Incorporate into the host configuration data a
+                      Network-Preference List, that is simply a list of
+                      networks in preferred order.  This list may be
+                      empty if there is no preference.
+
+                 (b)  When a host name is mapped into a list of IP
+                      addresses, these addresses should be sorted by
+                      network number, into the same order as the
+                      corresponding networks in the Network-Preference
+                      List.  IP addresses whose networks do not appear
+                      in the Network-Preference List should be placed at
+                      the end of the list.
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 78]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+         6.1.3.5  Extensibility
+
+            DNS software MUST support all well-known, class-independent
+            formats [DNS:2], and SHOULD be written to minimize the
+            trauma associated with the introduction of new well-known
+            types and local experimentation with non-standard types.
+
+            DISCUSSION:
+                 The data types and classes used by the DNS are
+                 extensible, and thus new types will be added and old
+                 types deleted or redefined.  Introduction of new data
+                 types ought to be dependent only upon the rules for
+                 compression of domain names inside DNS messages, and
+                 the translation between printable (i.e., master file)
+                 and internal formats for Resource Records (RRs).
+
+                 Compression relies on knowledge of the format of data
+                 inside a particular RR.  Hence compression must only be
+                 used for the contents of well-known, class-independent
+                 RRs, and must never be used for class-specific RRs or
+                 RR types that are not well-known.  The owner name of an
+                 RR is always eligible for compression.
+
+                 A name server may acquire, via zone transfer, RRs that
+                 the server doesn't know how to convert to printable
+                 format.  A resolver can receive similar information as
+                 the result of queries.  For proper operation, this data
+                 must be preserved, and hence the implication is that
+                 DNS software cannot use textual formats for internal
+                 storage.
+
+                 The DNS defines domain name syntax very generally -- a
+                 string of labels each containing up to 63 8-bit octets,
+                 separated by dots, and with a maximum total of 255
+                 octets.  Particular applications of the DNS are
+                 permitted to further constrain the syntax of the domain
+                 names they use, although the DNS deployment has led to
+                 some applications allowing more general names.  In
+                 particular, Section 2.1 of this document liberalizes
+                 slightly the syntax of a legal Internet host name that
+                 was defined in RFC-952 [DNS:4].
+
+         6.1.3.6  Status of RR Types
+
+            Name servers MUST be able to load all RR types except MD and
+            MF from configuration files.  The MD and MF types are
+            obsolete and MUST NOT be implemented; in particular, name
+            servers MUST NOT load these types from configuration files.
+
+
+
+Internet Engineering Task Force                                [Page 79]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+            DISCUSSION:
+                 The RR types MB, MG, MR, NULL, MINFO and RP are
+                 considered experimental, and applications that use the
+                 DNS cannot expect these RR types to be supported by
+                 most domains.  Furthermore these types are subject to
+                 redefinition.
+
+                 The TXT and WKS RR types have not been widely used by
+                 Internet sites; as a result, an application cannot rely
+                 on the the existence of a TXT or WKS RR in most
+                 domains.
+
+         6.1.3.7  Robustness
+
+            DNS software may need to operate in environments where the
+            root servers or other servers are unavailable due to network
+            connectivity or other problems.  In this situation, DNS name
+            servers and resolvers MUST continue to provide service for
+            the reachable part of the name space, while giving temporary
+            failures for the rest.
+
+            DISCUSSION:
+                 Although the DNS is meant to be used primarily in the
+                 connected Internet, it should be possible to use the
+                 system in networks which are unconnected to the
+                 Internet.  Hence implementations must not depend on
+                 access to root servers before providing service for
+                 local names.
+
+         6.1.3.8  Local Host Table
+
+            DISCUSSION:
+                 A host may use a local host table as a backup or
+                 supplement to the DNS.  This raises the question of
+                 which takes precedence, the DNS or the host table; the
+                 most flexible approach would make this a configuration
+                 option.
+
+                 Typically, the contents of such a supplementary host
+                 table will be determined locally by the site.  However,
+                 a publically-available table of Internet hosts is
+                 maintained by the DDN Network Information Center (DDN
+                 NIC), with a format documented in [DNS:4].  This table
+                 can be retrieved from the DDN NIC using a protocol
+                 described in [DNS:5].  It must be noted that this table
+                 contains only a small fraction of all Internet hosts.
+                 Hosts using this protocol to retrieve the DDN NIC host
+                 table should use the VERSION command to check if the
+
+
+
+Internet Engineering Task Force                                [Page 80]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+                 table has changed before requesting the entire table
+                 with the ALL command.  The VERSION identifier should be
+                 treated as an arbitrary string and tested only for
+                 equality; no numerical sequence may be assumed.
+
+                 The DDN NIC host table includes administrative
+                 information that is not needed for host operation and
+                 is therefore not currently included in the DNS
+                 database; examples include network and gateway entries.
+                 However, much of this additional information will be
+                 added to the DNS in the future.  Conversely, the DNS
+                 provides essential services (in particular, MX records)
+                 that are not available from the DDN NIC host table.
+
+      6.1.4  DNS USER INTERFACE
+
+         6.1.4.1  DNS Administration
+
+            This document is concerned with design and implementation
+            issues in host software, not with administrative or
+            operational issues.  However, administrative issues are of
+            particular importance in the DNS, since errors in particular
+            segments of this large distributed database can cause poor
+            or erroneous performance for many sites.  These issues are
+            discussed in [DNS:6] and [DNS:7].
+
+         6.1.4.2  DNS User Interface
+
+            Hosts MUST provide an interface to the DNS for all
+            application programs running on the host.  This interface
+            will typically direct requests to a system process to
+            perform the resolver function [DNS:1, 6.1:2].
+
+            At a minimum, the basic interface MUST support a request for
+            all information of a specific type and class associated with
+            a specific name, and it MUST return either all of the
+            requested information, a hard error code, or a soft error
+            indication.  When there is no error, the basic interface
+            returns the complete response information without
+            modification, deletion, or ordering, so that the basic
+            interface will not need to be changed to accommodate new
+            data types.
+
+            DISCUSSION:
+                 The soft error indication is an essential part of the
+                 interface, since it may not always be possible to
+                 access particular information from the DNS; see Section
+                 6.1.3.3.
+
+
+
+Internet Engineering Task Force                                [Page 81]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+            A host MAY provide other DNS interfaces tailored to
+            particular functions, transforming the raw domain data into
+            formats more suited to these functions.  In particular, a
+            host MUST provide a DNS interface to facilitate translation
+            between host addresses and host names.
+
+         6.1.4.3 Interface Abbreviation Facilities
+
+            User interfaces MAY provide a method for users to enter
+            abbreviations for commonly-used names.  Although the
+            definition of such methods is outside of the scope of the
+            DNS specification, certain rules are necessary to insure
+            that these methods allow access to the entire DNS name space
+            and to prevent excessive use of Internet resources.
+
+            If an abbreviation method is provided, then:
+
+            (a)  There MUST be some convention for denoting that a name
+                 is already complete, so that the abbreviation method(s)
+                 are suppressed.  A trailing dot is the usual method.
+
+            (b)  Abbreviation expansion MUST be done exactly once, and
+                 MUST be done in the context in which the name was
+                 entered.
+
+
+            DISCUSSION:
+                 For example, if an abbreviation is used in a mail
+                 program for a destination, the abbreviation should be
+                 expanded into a full domain name and stored in the
+                 queued message with an indication that it is already
+                 complete.  Otherwise, the abbreviation might be
+                 expanded with a mail system search list, not the
+                 user's, or a name could grow due to repeated
+                 canonicalizations attempts interacting with wildcards.
+
+            The two most common abbreviation methods are:
+
+            (1)  Interface-level aliases
+
+                 Interface-level aliases are conceptually implemented as
+                 a list of alias/domain name pairs. The list can be
+                 per-user or per-host, and separate lists can be
+                 associated with different functions, e.g. one list for
+                 host name-to-address translation, and a different list
+                 for mail domains.  When the user enters a name, the
+                 interface attempts to match the name to the alias
+                 component of a list entry, and if a matching entry can
+
+
+
+Internet Engineering Task Force                                [Page 82]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+                 be found, the name is replaced by the domain name found
+                 in the pair.
+
+                 Note that interface-level aliases and CNAMEs are
+                 completely separate mechanisms; interface-level aliases
+                 are a local matter while CNAMEs are an Internet-wide
+                 aliasing mechanism which is a required part of any DNS
+                 implementation.
+
+            (2)  Search Lists
+
+                 A search list is conceptually implemented as an ordered
+                 list of domain names.  When the user enters a name, the
+                 domain names in the search list are used as suffixes to
+                 the user-supplied name, one by one, until a domain name
+                 with the desired associated data is found, or the
+                 search list is exhausted.  Search lists often contain
+                 the name of the local host's parent domain or other
+                 ancestor domains.  Search lists are often per-user or
+                 per-process.
+
+                 It SHOULD be possible for an administrator to disable a
+                 DNS search-list facility.  Administrative denial may be
+                 warranted in some cases, to prevent abuse of the DNS.
+
+                 There is danger that a search-list mechanism will
+                 generate excessive queries to the root servers while
+                 testing whether user input is a complete domain name,
+                 lacking a final period to mark it as complete.  A
+                 search-list mechanism MUST have one of, and SHOULD have
+                 both of, the following two provisions to prevent this:
+
+                 (a)  The local resolver/name server can implement
+                      caching  of negative responses (see Section
+                      6.1.3.3).
+
+                 (b)  The search list expander can require two or more
+                      interior dots in a generated domain name before it
+                      tries using the name in a query to non-local
+                      domain servers, such as the root.
+
+                 DISCUSSION:
+                      The intent of this requirement is to avoid
+                      excessive delay for the user as the search list is
+                      tested, and more importantly to prevent excessive
+                      traffic to the root and other high-level servers.
+                      For example, if the user supplied a name "X" and
+                      the search list contained the root as a component,
+
+
+
+Internet Engineering Task Force                                [Page 83]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+                      a query would have to consult a root server before
+                      the next search list alternative could be tried.
+                      The resulting load seen by the root servers and
+                      gateways near the root would be multiplied by the
+                      number of hosts in the Internet.
+
+                      The negative caching alternative limits the effect
+                      to the first time a name is used.  The interior
+                      dot rule is simpler to implement but can prevent
+                      easy use of some top-level names.
+
+
+      6.1.5  DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY
+
+                                               |           | | | |S| |
+                                               |           | | | |H| |F
+                                               |           | | | |O|M|o
+                                               |           | |S| |U|U|o
+                                               |           | |H| |L|S|t
+                                               |           |M|O| |D|T|n
+                                               |           |U|U|M| | |o
+                                               |           |S|L|A|N|N|t
+                                               |           |T|D|Y|O|O|t
+FEATURE                                        |SECTION    | | | |T|T|e
+-----------------------------------------------|-----------|-|-|-|-|-|--
+GENERAL ISSUES                                 |           | | | | | |
+                                               |           | | | | | |
+Implement DNS name-to-address conversion       |6.1.1      |x| | | | |
+Implement DNS address-to-name conversion       |6.1.1      |x| | | | |
+Support conversions using host table           |6.1.1      | | |x| | |
+Properly handle RR with zero TTL               |6.1.2.1    |x| | | | |
+Use QCLASS=* unnecessarily                     |6.1.2.2    | |x| | | |
+  Use QCLASS=IN for Internet class             |6.1.2.2    |x| | | | |
+Unused fields zero                             |6.1.2.3    |x| | | | |
+Use compression in responses                   |6.1.2.4    |x| | | | |
+                                               |           | | | | | |
+Include config info in responses               |6.1.2.5    | | | | |x|
+Support all well-known, class-indep. types     |6.1.3.5    |x| | | | |
+Easily expand type list                        |6.1.3.5    | |x| | | |
+Load all RR types (except MD and MF)           |6.1.3.6    |x| | | | |
+Load MD or MF type                             |6.1.3.6    | | | | |x|
+Operate when root servers, etc. unavailable    |6.1.3.7    |x| | | | |
+-----------------------------------------------|-----------|-|-|-|-|-|--
+RESOLVER ISSUES:                               |           | | | | | |
+                                               |           | | | | | |
+Resolver support multiple concurrent requests  |6.1.3.1    | |x| | | |
+Full-service resolver:                         |6.1.3.1    | | |x| | |
+  Local caching                                |6.1.3.1    |x| | | | |
+
+
+
+Internet Engineering Task Force                                [Page 84]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+  Information in local cache times out         |6.1.3.1    |x| | | | |
+  Configurable with starting info              |6.1.3.1    | |x| | | |
+Stub resolver:                                 |6.1.3.1    | | |x| | |
+  Use redundant recursive name servers         |6.1.3.1    |x| | | | |
+  Local caching                                |6.1.3.1    | | |x| | |
+  Information in local cache times out         |6.1.3.1    |x| | | | |
+Support for remote multi-homed hosts:          |           | | | | | |
+  Sort multiple addresses by preference list   |6.1.3.4    | |x| | | |
+                                               |           | | | | | |
+-----------------------------------------------|-----------|-|-|-|-|-|--
+TRANSPORT PROTOCOLS:                           |           | | | | | |
+                                               |           | | | | | |
+Support UDP queries                            |6.1.3.2    |x| | | | |
+Support TCP queries                            |6.1.3.2    | |x| | | |
+  Send query using UDP first                   |6.1.3.2    |x| | | | |1
+  Try TCP if UDP answers are truncated         |6.1.3.2    | |x| | | |
+Name server limit TCP query resources          |6.1.3.2    | | |x| | |
+  Punish unnecessary TCP query                 |6.1.3.2    | | | |x| |
+Use truncated data as if it were not           |6.1.3.2    | | | | |x|
+Private agreement to use only TCP              |6.1.3.2    | | |x| | |
+Use TCP for zone transfers                     |6.1.3.2    |x| | | | |
+TCP usage not block UDP queries                |6.1.3.2    |x| | | | |
+Support broadcast or multicast queries         |6.1.3.2    | | |x| | |
+  RD bit set in query                          |6.1.3.2    | | | | |x|
+  RD bit ignored by server is b'cast/m'cast    |6.1.3.2    |x| | | | |
+  Send only as occasional probe for addr's     |6.1.3.2    | |x| | | |
+-----------------------------------------------|-----------|-|-|-|-|-|--
+RESOURCE USAGE:                                |           | | | | | |
+                                               |           | | | | | |
+Transmission controls, per [DNS:2]             |6.1.3.3    |x| | | | |
+  Finite bounds per request                    |6.1.3.3    |x| | | | |
+Failure after retries => soft error            |6.1.3.3    |x| | | | |
+Cache temporary failures                       |6.1.3.3    | |x| | | |
+Cache negative responses                       |6.1.3.3    | |x| | | |
+Retries use exponential backoff                |6.1.3.3    | |x| | | |
+  Upper, lower bounds                          |6.1.3.3    | |x| | | |
+Client handle Source Quench                    |6.1.3.3    | |x| | | |
+Server ignore Source Quench                    |6.1.3.3    | | |x| | |
+-----------------------------------------------|-----------|-|-|-|-|-|--
+USER INTERFACE:                                |           | | | | | |
+                                               |           | | | | | |
+All programs have access to DNS interface      |6.1.4.2    |x| | | | |
+Able to request all info for given name        |6.1.4.2    |x| | | | |
+Returns complete info or error                 |6.1.4.2    |x| | | | |
+Special interfaces                             |6.1.4.2    | | |x| | |
+  Name<->Address translation                   |6.1.4.2    |x| | | | |
+                                               |           | | | | | |
+Abbreviation Facilities:                       |6.1.4.3    | | |x| | |
+
+
+
+Internet Engineering Task Force                                [Page 85]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+  Convention for complete names                |6.1.4.3    |x| | | | |
+  Conversion exactly once                      |6.1.4.3    |x| | | | |
+  Conversion in proper context                 |6.1.4.3    |x| | | | |
+  Search list:                                 |6.1.4.3    | | |x| | |
+    Administrator can disable                  |6.1.4.3    | |x| | | |
+    Prevention of excessive root queries       |6.1.4.3    |x| | | | |
+      Both methods                             |6.1.4.3    | |x| | | |
+-----------------------------------------------|-----------|-|-|-|-|-|--
+-----------------------------------------------|-----------|-|-|-|-|-|--
+
+1.   Unless there is private agreement between particular resolver and
+     particular server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 86]
+
+
+
+
+RFC1123            SUPPORT SERVICES -- INITIALIZATION       October 1989
+
+
+   6.2  HOST INITIALIZATION
+
+      6.2.1  INTRODUCTION
+
+         This section discusses the initialization of host software
+         across a connected network, or more generally across an
+         Internet path.  This is necessary for a diskless host, and may
+         optionally be used for a host with disk drives.  For a diskless
+         host, the initialization process is called "network booting"
+         and is controlled by a bootstrap program located in a boot ROM.
+
+         To initialize a diskless host across the network, there are two
+         distinct phases:
+
+         (1)  Configure the IP layer.
+
+              Diskless machines often have no permanent storage in which
+              to store network configuration information, so that
+              sufficient configuration information must be obtained
+              dynamically to support the loading phase that follows.
+              This information must include at least the IP addresses of
+              the host and of the boot server.  To support booting
+              across a gateway, the address mask and a list of default
+              gateways are also required.
+
+         (2)  Load the host system code.
+
+              During the loading phase, an appropriate file transfer
+              protocol is used to copy the system code across the
+              network from the boot server.
+
+         A host with a disk may perform the first step, dynamic
+         configuration.  This is important for microcomputers, whose
+         floppy disks allow network configuration information to be
+         mistakenly duplicated on more than one host.  Also,
+         installation of new hosts is much simpler if they automatically
+         obtain their configuration information from a central server,
+         saving administrator time and decreasing the probability of
+         mistakes.
+
+      6.2.2  REQUIREMENTS
+
+         6.2.2.1  Dynamic Configuration
+
+            A number of protocol provisions have been made for dynamic
+            configuration.
+
+            o    ICMP Information Request/Reply messages
+
+
+
+Internet Engineering Task Force                                [Page 87]
+
+
+
+
+RFC1123            SUPPORT SERVICES -- INITIALIZATION       October 1989
+
+
+                 This obsolete message pair was designed to allow a host
+                 to find the number of the network it is on.
+                 Unfortunately, it was useful only if the host already
+                 knew the host number part of its IP address,
+                 information that hosts requiring dynamic configuration
+                 seldom had.
+
+            o    Reverse Address Resolution Protocol (RARP) [BOOT:4]
+
+                 RARP is a link-layer protocol for a broadcast medium
+                 that allows a host to find its IP address given its
+                 link layer address.  Unfortunately, RARP does not work
+                 across IP gateways and therefore requires a RARP server
+                 on every network.  In addition, RARP does not provide
+                 any other configuration information.
+
+            o    ICMP Address Mask Request/Reply messages
+
+                 These ICMP messages allow a host to learn the address
+                 mask for a particular network interface.
+
+            o    BOOTP Protocol [BOOT:2]
+
+                 This protocol allows a host to determine the IP
+                 addresses of the local host and the boot server, the
+                 name of an appropriate boot file, and optionally the
+                 address mask and list of default gateways.  To locate a
+                 BOOTP server, the host broadcasts a BOOTP request using
+                 UDP.  Ad hoc gateway extensions have been used to
+                 transmit the BOOTP broadcast through gateways, and in
+                 the future the IP Multicasting facility will provide a
+                 standard mechanism for this purpose.
+
+
+            The suggested approach to dynamic configuration is to use
+            the BOOTP protocol with the extensions defined in "BOOTP
+            Vendor Information Extensions" RFC-1084 [BOOT:3].  RFC-1084
+            defines some important general (not vendor-specific)
+            extensions.  In particular, these extensions allow the
+            address mask to be supplied in BOOTP; we RECOMMEND that the
+            address mask be supplied in this manner.
+
+            DISCUSSION:
+                 Historically, subnetting was defined long after IP, and
+                 so a separate mechanism (ICMP Address Mask messages)
+                 was designed to supply the address mask to a host.
+                 However, the IP address mask and the corresponding IP
+                 address conceptually form a pair, and for operational
+
+
+
+Internet Engineering Task Force                                [Page 88]
+
+
+
+
+RFC1123            SUPPORT SERVICES -- INITIALIZATION       October 1989
+
+
+                 simplicity they ought to be defined at the same time
+                 and by the same mechanism, whether a configuration file
+                 or a dynamic mechanism like BOOTP.
+
+                 Note that BOOTP is not sufficiently general to specify
+                 the configurations of all interfaces of a multihomed
+                 host.  A multihomed host must either use BOOTP
+                 separately for each interface, or configure one
+                 interface using BOOTP to perform the loading, and
+                 perform the complete initialization from a file later.
+
+                 Application layer configuration information is expected
+                 to be obtained from files after loading of the system
+                 code.
+
+         6.2.2.2  Loading Phase
+
+            A suggested approach for the loading phase is to use TFTP
+            [BOOT:1] between the IP addresses established by BOOTP.
+
+            TFTP to a broadcast address SHOULD NOT be used, for reasons
+            explained in Section 4.2.3.4.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 89]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+   6.3  REMOTE MANAGEMENT
+
+      6.3.1  INTRODUCTION
+
+         The Internet community has recently put considerable effort
+         into the development of network management protocols.  The
+         result has been a two-pronged approach [MGT:1, MGT:6]:  the
+         Simple Network Management Protocol (SNMP) [MGT:4] and the
+         Common Management Information Protocol over TCP (CMOT) [MGT:5].
+
+         In order to be managed using SNMP or CMOT, a host will need to
+         implement an appropriate management agent.  An Internet host
+         SHOULD include an agent for either SNMP or CMOT.
+
+         Both SNMP and CMOT operate on a Management Information Base
+         (MIB) that defines a collection of management values.  By
+         reading and setting these values, a remote application may
+         query and change the state of the managed system.
+
+         A standard MIB [MGT:3] has been defined for use by both
+         management protocols, using data types defined by the Structure
+         of Management Information (SMI) defined in [MGT:2].  Additional
+         MIB variables can be introduced under the "enterprises" and
+         "experimental" subtrees of the MIB naming space [MGT:2].
+
+         Every protocol module in the host SHOULD implement the relevant
+         MIB variables.  A host SHOULD implement the MIB variables as
+         defined in the most recent standard MIB, and MAY implement
+         other MIB variables when appropriate and useful.
+
+      6.3.2  PROTOCOL WALK-THROUGH
+
+         The MIB is intended to cover both hosts and gateways, although
+         there may be detailed differences in MIB application to the two
+         cases.  This section contains the appropriate interpretation of
+         the MIB for hosts.  It is likely that later versions of the MIB
+         will include more entries for host management.
+
+         A managed host must implement the following groups of MIB
+         object definitions: System, Interfaces, Address Translation,
+         IP, ICMP, TCP, and UDP.
+
+         The following specific interpretations apply to hosts:
+
+         o    ipInHdrErrors
+
+              Note that the error "time-to-live exceeded" can occur in a
+              host only when it is forwarding a source-routed datagram.
+
+
+
+Internet Engineering Task Force                                [Page 90]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+         o    ipOutNoRoutes
+
+              This object counts datagrams discarded because no route
+              can be found.  This may happen in a host if all the
+              default gateways in the host's configuration are down.
+
+         o    ipFragOKs, ipFragFails, ipFragCreates
+
+              A host that does not implement intentional fragmentation
+              (see "Fragmentation" section of [INTRO:1]) MUST return the
+              value zero for these three objects.
+
+         o    icmpOutRedirects
+
+              For a host, this object MUST always be zero, since hosts
+              do not send Redirects.
+
+         o    icmpOutAddrMaskReps
+
+              For a host, this object MUST always be zero, unless the
+              host is an authoritative source of address mask
+              information.
+
+         o    ipAddrTable
+
+              For a host, the "IP Address Table" object is effectively a
+              table of logical interfaces.
+
+         o    ipRoutingTable
+
+              For a host, the "IP Routing Table" object is effectively a
+              combination of the host's Routing Cache and the static
+              route table described in "Routing Outbound Datagrams"
+              section of [INTRO:1].
+
+              Within each ipRouteEntry, ipRouteMetric1...4 normally will
+              have no meaning for a host and SHOULD always be -1, while
+              ipRouteType will normally have the value "remote".
+
+              If destinations on the connected network do not appear in
+              the Route Cache (see "Routing Outbound Datagrams section
+              of [INTRO:1]), there will be no entries with ipRouteType
+              of "direct".
+
+
+         DISCUSSION:
+              The current MIB does not include Type-of-Service in an
+              ipRouteEntry, but a future revision is expected to make
+
+
+
+Internet Engineering Task Force                                [Page 91]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+              this addition.
+
+              We also expect the MIB to be expanded to allow the remote
+              management of applications (e.g., the ability to partially
+              reconfigure mail systems).  Network service applications
+              such as mail systems should therefore be written with the
+              "hooks" for remote management.
+
+      6.3.3  MANAGEMENT REQUIREMENTS SUMMARY
+
+                                               |           | | | |S| |
+                                               |           | | | |H| |F
+                                               |           | | | |O|M|o
+                                               |           | |S| |U|U|o
+                                               |           | |H| |L|S|t
+                                               |           |M|O| |D|T|n
+                                               |           |U|U|M| | |o
+                                               |           |S|L|A|N|N|t
+                                               |           |T|D|Y|O|O|t
+FEATURE                                        |SECTION    | | | |T|T|e
+-----------------------------------------------|-----------|-|-|-|-|-|--
+Support SNMP or CMOT agent                     |6.3.1      | |x| | | |
+Implement specified objects in standard MIB    |6.3.1      | |x| | | |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 92]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+7.  REFERENCES
+
+   This section lists the primary references with which every
+   implementer must be thoroughly familiar.  It also lists some
+   secondary references that are suggested additional reading.
+
+   INTRODUCTORY REFERENCES:
+
+
+   [INTRO:1] "Requirements for Internet Hosts -- Communication Layers,"
+        IETF Host Requirements Working Group, R. Braden, Ed., RFC-1122,
+        October 1989.
+
+   [INTRO:2]  "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006,
+        (three volumes), SRI International, December 1985.
+
+   [INTRO:3]  "Official Internet Protocols," J. Reynolds and J. Postel,
+        RFC-1011, May 1987.
+
+        This document is republished periodically with new RFC numbers;
+        the latest version must be used.
+
+   [INTRO:4]  "Protocol Document Order Information," O. Jacobsen and J.
+        Postel, RFC-980, March 1986.
+
+   [INTRO:5]  "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010,
+        May 1987.
+
+        This document is republished periodically with new RFC numbers;
+        the latest version must be used.
+
+
+   TELNET REFERENCES:
+
+
+   [TELNET:1]  "Telnet Protocol Specification," J. Postel and J.
+        Reynolds, RFC-854, May 1983.
+
+   [TELNET:2]  "Telnet Option Specification," J. Postel and J. Reynolds,
+        RFC-855, May 1983.
+
+   [TELNET:3]  "Telnet Binary Transmission," J. Postel and J. Reynolds,
+        RFC-856, May 1983.
+
+   [TELNET:4]  "Telnet Echo Option," J. Postel and J. Reynolds, RFC-857,
+        May 1983.
+
+   [TELNET:5]  "Telnet Suppress Go Ahead Option," J. Postel and J.
+
+
+
+Internet Engineering Task Force                                [Page 93]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+        Reynolds, RFC-858, May 1983.
+
+   [TELNET:6]  "Telnet Status Option," J. Postel and J. Reynolds, RFC-
+        859, May 1983.
+
+   [TELNET:7]  "Telnet Timing Mark Option," J. Postel and J. Reynolds,
+        RFC-860, May 1983.
+
+   [TELNET:8]  "Telnet Extended Options List," J. Postel and J.
+        Reynolds, RFC-861, May 1983.
+
+   [TELNET:9]  "Telnet End-Of-Record Option," J. Postel, RFC-855,
+        December 1983.
+
+   [TELNET:10] "Telnet Terminal-Type Option," J. VanBokkelen, RFC-1091,
+        February 1989.
+
+        This document supercedes RFC-930.
+
+   [TELNET:11] "Telnet Window Size Option," D. Waitzman, RFC-1073,
+        October 1988.
+
+   [TELNET:12] "Telnet Linemode Option," D. Borman, RFC-1116, August
+        1989.
+
+   [TELNET:13] "Telnet Terminal Speed Option," C. Hedrick, RFC-1079,
+        December 1988.
+
+   [TELNET:14] "Telnet Remote Flow Control Option," C. Hedrick, RFC-
+        1080, November 1988.
+
+
+   SECONDARY TELNET REFERENCES:
+
+
+   [TELNET:15] "Telnet Protocol," MIL-STD-1782, U.S. Department of
+        Defense, May 1984.
+
+        This document is intended to describe the same protocol as RFC-
+        854.  In case of conflict, RFC-854 takes precedence, and the
+        present document takes precedence over both.
+
+   [TELNET:16] "SUPDUP Protocol," M. Crispin, RFC-734, October 1977.
+
+   [TELNET:17] "Telnet SUPDUP Option," M. Crispin, RFC-736, October
+        1977.
+
+   [TELNET:18] "Data Entry Terminal Option," J. Day, RFC-732, June 1977.
+
+
+
+Internet Engineering Task Force                                [Page 94]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+   [TELNET:19] "TELNET Data Entry Terminal option -- DODIIS
+        Implementation," A. Yasuda and T. Thompson, RFC-1043, February
+        1988.
+
+
+   FTP REFERENCES:
+
+
+   [FTP:1]  "File Transfer Protocol," J. Postel and J. Reynolds, RFC-
+        959, October 1985.
+
+   [FTP:2]  "Document File Format Standards," J. Postel, RFC-678,
+        December 1974.
+
+   [FTP:3]  "File Transfer Protocol," MIL-STD-1780, U.S. Department of
+        Defense, May 1984.
+
+        This document is based on an earlier version of the FTP
+        specification (RFC-765) and is obsolete.
+
+
+   TFTP REFERENCES:
+
+
+   [TFTP:1]  "The TFTP Protocol Revision 2," K. Sollins, RFC-783, June
+        1981.
+
+
+   MAIL REFERENCES:
+
+
+   [SMTP:1]  "Simple Mail Transfer Protocol," J. Postel, RFC-821, August
+        1982.
+
+   [SMTP:2]  "Standard For The Format of ARPA Internet Text Messages,"
+        D. Crocker, RFC-822, August 1982.
+
+        This document obsoleted an earlier specification, RFC-733.
+
+   [SMTP:3]  "Mail Routing and the Domain System," C. Partridge, RFC-
+        974, January 1986.
+
+        This RFC describes the use of MX records, a mandatory extension
+        to the mail delivery process.
+
+   [SMTP:4]  "Duplicate Messages and SMTP," C. Partridge, RFC-1047,
+        February 1988.
+
+
+
+
+Internet Engineering Task Force                                [Page 95]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+   [SMTP:5a]  "Mapping between X.400 and RFC 822," S. Kille, RFC-987,
+        June 1986.
+
+   [SMTP:5b]  "Addendum to RFC-987," S. Kille, RFC-???, September 1987.
+
+        The two preceding RFC's define a proposed standard for
+        gatewaying mail between the Internet and the X.400 environments.
+
+   [SMTP:6]  "Simple Mail Transfer Protocol,"  MIL-STD-1781, U.S.
+        Department of Defense, May 1984.
+
+        This specification is intended to describe the same protocol as
+        does RFC-821.  However, MIL-STD-1781 is incomplete; in
+        particular, it does not include MX records [SMTP:3].
+
+   [SMTP:7]  "A Content-Type Field for Internet Messages," M. Sirbu,
+        RFC-1049, March 1988.
+
+
+   DOMAIN NAME SYSTEM REFERENCES:
+
+
+   [DNS:1]  "Domain Names - Concepts and Facilities," P. Mockapetris,
+        RFC-1034, November 1987.
+
+        This document and the following one obsolete RFC-882, RFC-883,
+        and RFC-973.
+
+   [DNS:2]  "Domain Names - Implementation and Specification," RFC-1035,
+        P. Mockapetris, November 1987.
+
+
+   [DNS:3]  "Mail Routing and the Domain System," C. Partridge, RFC-974,
+        January 1986.
+
+
+   [DNS:4]  "DoD Internet Host Table Specification," K. Harrenstein,
+        RFC-952, M. Stahl, E. Feinler, October 1985.
+
+        SECONDARY DNS REFERENCES:
+
+
+   [DNS:5]  "Hostname Server," K. Harrenstein, M. Stahl, E. Feinler,
+        RFC-953, October 1985.
+
+   [DNS:6]  "Domain Administrators Guide," M. Stahl, RFC-1032, November
+        1987.
+
+
+
+
+Internet Engineering Task Force                                [Page 96]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+   [DNS:7]  "Domain Administrators Operations Guide," M. Lottor, RFC-
+        1033, November 1987.
+
+   [DNS:8]  "The Domain Name System Handbook," Vol. 4 of Internet
+        Protocol Handbook, NIC 50007, SRI Network Information Center,
+        August 1989.
+
+
+   SYSTEM INITIALIZATION REFERENCES:
+
+
+   [BOOT:1] "Bootstrap Loading Using TFTP," R. Finlayson, RFC-906, June
+        1984.
+
+   [BOOT:2] "Bootstrap Protocol (BOOTP)," W. Croft and J. Gilmore, RFC-
+        951, September 1985.
+
+   [BOOT:3] "BOOTP Vendor Information Extensions," J. Reynolds, RFC-
+        1084, December 1988.
+
+        Note: this RFC revised and obsoleted RFC-1048.
+
+   [BOOT:4] "A Reverse Address Resolution Protocol," R. Finlayson, T.
+        Mann, J. Mogul, and M. Theimer, RFC-903, June 1984.
+
+
+   MANAGEMENT REFERENCES:
+
+
+   [MGT:1]  "IAB Recommendations for the Development of Internet Network
+        Management Standards," V. Cerf, RFC-1052, April 1988.
+
+   [MGT:2]  "Structure and Identification of Management Information for
+        TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1065,
+        August 1988.
+
+   [MGT:3]  "Management Information Base for Network Management of
+        TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1066,
+        August 1988.
+
+   [MGT:4]  "A Simple Network Management Protocol," J. Case, M. Fedor,
+        M. Schoffstall, and C. Davin, RFC-1098, April 1989.
+
+   [MGT:5]  "The Common Management Information Services and Protocol
+        over TCP/IP," U. Warrier and L. Besaw, RFC-1095, April 1989.
+
+   [MGT:6]  "Report of the Second Ad Hoc Network Management Review
+        Group," V. Cerf, RFC-1109, August 1989.
+
+
+
+Internet Engineering Task Force                                [Page 97]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+Security Considerations
+
+   There are many security issues in the application and support
+   programs of host software, but a full discussion is beyond the scope
+   of this RFC.  Security-related issues are mentioned in sections
+   concerning TFTP (Sections 4.2.1, 4.2.3.4, 4.2.3.5), the SMTP VRFY and
+   EXPN commands (Section 5.2.3), the SMTP HELO command (5.2.5), and the
+   SMTP DATA command (Section 5.2.8).
+
+Author's Address
+
+   Robert Braden
+   USC/Information Sciences Institute
+   4676 Admiralty Way
+   Marina del Rey, CA 90292-6695
+
+   Phone: (213) 822 1511
+
+   EMail: Braden@ISI.EDU
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 98]
+
diff --git a/usr.sbin/named/doc/rfc/rfc1183 b/usr.sbin/named/doc/rfc/rfc1183
new file mode 100644
index 00000000000..6f080448bc7
--- /dev/null
+++ b/usr.sbin/named/doc/rfc/rfc1183
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                        C. Everhart
+Request for Comments: 1183                                      Transarc
+Updates: RFCs 1034, 1035                                      L. Mamakos
+                                                  University of Maryland
+                                                              R. Ullmann
+                                                          Prime Computer
+                                                  P. Mockapetris, Editor
+                                                                     ISI
+                                                            October 1990
+
+
+                         New DNS RR Definitions
+
+Status of this Memo
+
+   This memo defines five new DNS types for experimental purposes.  This
+   RFC describes an Experimental Protocol for the Internet community,
+   and requests discussion and suggestions for improvements.
+   Distribution of this memo is unlimited.
+
+Table of Contents
+
+   Introduction....................................................    1
+   1. AFS Data Base location.......................................    2
+   2. Responsible Person...........................................    3
+   2.1. Identification of the guilty party.........................    3
+   2.2. The Responsible Person RR..................................    4
+   3. X.25 and ISDN addresses, Route Binding.......................    6
+   3.1. The X25 RR.................................................    6
+   3.2. The ISDN RR................................................    7
+   3.3. The Route Through RR.......................................    8
+   REFERENCES and BIBLIOGRAPHY.....................................    9
+   Security Considerations.........................................   10
+   Authors' Addresses..............................................   11
+
+Introduction
+
+   This RFC defines the format of new Resource Records (RRs) for the
+   Domain Name System (DNS), and reserves corresponding DNS type
+   mnemonics and numerical codes.  The definitions are in three
+   independent sections: (1) location of AFS database servers, (2)
+   location of responsible persons, and (3) representation of X.25 and
+   ISDN addresses and route binding.  All are experimental.
+
+   This RFC assumes that the reader is familiar with the DNS [3,4].  The
+   data shown is for pedagogical use and does not necessarily reflect
+   the real Internet.
+
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                        [Page 1]
+
+RFC 1183                 New DNS RR Definitions             October 1990
+
+
+1. AFS Data Base location
+
+   This section defines an extension of the DNS to locate servers both
+   for AFS (AFS is a registered trademark of Transarc Corporation) and
+   for the Open Software Foundation's (OSF) Distributed Computing
+   Environment (DCE) authenticated naming system using HP/Apollo's NCA,
+   both to be components of the OSF DCE.  The discussion assumes that
+   the reader is familiar with AFS [5] and NCA [6].
+
+   The AFS (originally the Andrew File System) system uses the DNS to
+   map from a domain name to the name of an AFS cell database server.
+   The DCE Naming service uses the DNS for a similar function: mapping
+   from the domain name of a cell to authenticated name servers for that
+   cell.  The method uses a new RR type with mnemonic AFSDB and type
+   code of 18 (decimal).
+
+   AFSDB has the following format:
+
+   <owner> <ttl> <class> AFSDB <subtype> <hostname>
+
+   Both RDATA fields are required in all AFSDB RRs.  The <subtype> field
+   is a 16 bit integer.  The <hostname> field is a domain name of a host
+   that has a server for the cell named by the owner name of the RR.
+
+   The format of the AFSDB RR is class insensitive.  AFSDB records cause
+   type A additional section processing for <hostname>.  This, in fact,
+   is the rationale for using a new type code, rather than trying to
+   build the same functionality with TXT RRs.
+
+   Note that the format of AFSDB in a master file is identical to MX.
+   For purposes of the DNS itself, the subtype is merely an integer.
+   The present subtype semantics are discussed below, but changes are
+   possible and will be announced in subsequent RFCs.
+
+   In the case of subtype 1, the host has an AFS version 3.0 Volume
+   Location Server for the named AFS cell.  In the case of subtype 2,
+   the host has an authenticated name server holding the cell-root
+   directory node for the named DCE/NCA cell.
+
+   The use of subtypes is motivated by two considerations.  First, the
+   space of DNS RR types is limited.  Second, the services provided are
+   sufficiently distinct that it would continue to be confusing for a
+   client to attempt to connect to a cell's servers using the protocol
+   for one service, if the cell offered only the other service.
+
+   As an example of the use of this RR, suppose that the Toaster
+   Corporation has deployed AFS 3.0 but not (yet) the OSF's DCE.  Their
+   cell, named toaster.com, has three "AFS 3.0 cell database server"
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                        [Page 2]
+
+RFC 1183                 New DNS RR Definitions             October 1990
+
+
+   machines: bigbird.toaster.com, ernie.toaster.com, and
+   henson.toaster.com.  These three machines would be listed in three
+   AFSDB RRs.  These might appear in a master file as:
+
+   toaster.com.   AFSDB   1 bigbird.toaster.com.
+   toaster.com.   AFSDB   1 ernie.toaster.com.
+   toaster.com.   AFSDB   1 henson.toaster.com.
+
+   As another example use of this RR, suppose that Femto College (domain
+   name femto.edu) has deployed DCE, and that their DCE cell root
+   directory is served by processes running on green.femto.edu and
+   turquoise.femto.edu.  Furthermore, their DCE file servers also run
+   AFS 3.0-compatible volume location servers, on the hosts
+   turquoise.femto.edu and orange.femto.edu.  These machines would be
+   listed in four AFSDB RRs, which might appear in a master file as:
+
+   femto.edu.   AFSDB   2 green.femto.edu.
+   femto.edu.   AFSDB   2 turquoise.femto.edu.
+   femto.edu.   AFSDB   1 turquoise.femto.edu.
+   femto.edu.   AFSDB   1 orange.femto.edu.
+
+2. Responsible Person
+
+   The purpose of this section is to provide a standard method for
+   associating responsible person identification to any name in the DNS.
+
+   The domain name system functions as a distributed database which
+   contains many different form of information.  For a particular name
+   or host, you can discover it's Internet address, mail forwarding
+   information, hardware type and operating system among others.
+
+   A key aspect of the DNS is that the tree-structured namespace can be
+   divided into pieces, called zones, for purposes of distributing
+   control and responsibility.  The responsible person for zone database
+   purposes is named in the SOA RR for that zone.  This section
+   describes an extension which allows different responsible persons to
+   be specified for different names in a zone.
+
+2.1. Identification of the guilty party
+
+   Often it is desirable to be able to identify the responsible entity
+   for a particular host.  When that host is down or malfunctioning, it
+   is difficult to contact those parties which might resolve or repair
+   the host.  Mail sent to POSTMASTER may not reach the person in a
+   timely fashion.  If the host is one of a multitude of workstations,
+   there may be no responsible person which can be contacted on that
+   host.
+
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                        [Page 3]
+
+RFC 1183                 New DNS RR Definitions             October 1990
+
+
+   The POSTMASTER mailbox on that host continues to be a good contact
+   point for mail problems, and the zone contact in the SOA record for
+   database problem, but the RP record allows us to associate a mailbox
+   to entities that don't receive mail or are not directly connected
+   (namespace-wise) to the problem (e.g., GATEWAY.ISI.EDU might want to
+   point at HOTLINE@BBN.COM, and GATEWAY doesn't get mail, nor does the
+   ISI zone administrator have a clue about fixing gateways).
+
+2.2. The Responsible Person RR
+
+   The method uses a new RR type with mnemonic RP and type code of 17
+   (decimal).
+
+   RP has the following format:
+
+   <owner> <ttl> <class> RP <mbox-dname> <txt-dname>
+
+   Both RDATA fields are required in all RP RRs.
+
+   The first field, <mbox-dname>, is a domain name that specifies the
+   mailbox for the responsible person.  Its format in master files uses
+   the DNS convention for mailbox encoding, identical to that used for
+   the RNAME mailbox field in the SOA RR.  The root domain name (just
+   ".") may be specified for <mbox-dname> to indicate that no mailbox is
+   available.
+
+   The second field, <txt-dname>, is a domain name for which TXT RR's
+   exist.  A subsequent query can be performed to retrieve the
+   associated TXT resource records at <txt-dname>.  This provides a
+   level of indirection so that the entity can be referred to from
+   multiple places in the DNS.  The root domain name (just ".") may be
+   specified for <txt-dname> to indicate that the TXT_DNAME is absent,
+   and no associated TXT RR exists.
+
+   The format of the RP RR is class insensitive.  RP records cause no
+   additional section processing.  (TXT additional section processing
+   for <txt-dname> is allowed as an option, but only if it is disabled
+   for the root, i.e., ".").
+
+   The Responsible Person RR can be associated with any node in the
+   Domain Name System hierarchy, not just at the leaves of the tree.
+
+   The TXT RR associated with the TXT_DNAME contain free format text
+   suitable for humans.  Refer to [4] for more details on the TXT RR.
+
+   Multiple RP records at a single name may be present in the database.
+   They should have identical TTLs.
+
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                        [Page 4]
+
+RFC 1183                 New DNS RR Definitions             October 1990
+
+
+   EXAMPLES
+
+   Some examples of how the RP record might be used.
+
+   sayshell.umd.edu. A     128.8.1.14
+                     MX    10 sayshell.umd.edu.
+                     HINFO NeXT UNIX
+                     WKS   128.8.1.14 tcp ftp telnet smtp
+                     RP    louie.trantor.umd.edu.  LAM1.people.umd.edu.
+
+   LAM1.people.umd.edu. TXT (
+         "Louis A. Mamakos, (301) 454-2946, don't call me at home!" )
+
+   In this example, the responsible person's mailbox for the host
+   SAYSHELL.UMD.EDU is louie@trantor.umd.edu.  The TXT RR at
+   LAM1.people.umd.edu provides additional information and advice.
+
+   TERP.UMD.EDU.    A     128.8.10.90
+                    MX    10 128.8.10.90
+                    HINFO MICROVAX-II UNIX
+                    WKS   128.8.10.90 udp domain
+                    WKS   128.8.10.90 tcp ftp telnet smtp domain
+                    RP    louie.trantor.umd.edu. LAM1.people.umd.edu.
+                    RP    root.terp.umd.edu. ops.CS.UMD.EDU.
+
+   TRANTOR.UMD.EDU. A     128.8.10.14
+                    MX    10 trantor.umd.edu.
+                    HINFO MICROVAX-II UNIX
+                    WKS   128.8.10.14 udp domain
+                    WKS   128.8.10.14 tcp ftp telnet smtp domain
+                    RP    louie.trantor.umd.edu. LAM1.people.umd.edu.
+                    RP    petry.netwolf.umd.edu. petry.people.UMD.EDU.
+                    RP    root.trantor.umd.edu. ops.CS.UMD.EDU.
+                    RP    gregh.sunset.umd.edu.  .
+
+   LAM1.people.umd.edu.  TXT   "Louis A. Mamakos (301) 454-2946"
+   petry.people.umd.edu. TXT   "Michael G. Petry (301) 454-2946"
+   ops.CS.UMD.EDU.       TXT   "CS Operations Staff (301) 454-2943"
+
+   This set of resource records has two hosts, TRANTOR.UMD.EDU and
+   TERP.UMD.EDU, as well as a number of TXT RRs.  Note that TERP.UMD.EDU
+   and TRANTOR.UMD.EDU both reference the same pair of TXT resource
+   records, although the mail box names (root.terp.umd.edu and
+   root.trantor.umd.edu) differ.
+
+   Here, we obviously care much more if the machine flakes out, as we've
+   specified four persons which might want to be notified of problems or
+   other events involving TRANTOR.UMD.EDU.  In this example, the last RP
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                        [Page 5]
+
+RFC 1183                 New DNS RR Definitions             October 1990
+
+
+   RR for TRANTOR.UMD.EDU specifies a mailbox (gregh.sunset.umd.edu),
+   but no associated TXT RR.
+
+3. X.25 and ISDN addresses, Route Binding
+
+   This section describes an experimental representation of X.25 and
+   ISDN addresses in the DNS, as well as a route binding method,
+   analogous to the MX for mail routing, for very large scale networks.
+
+   There are several possible uses, all experimental at this time.
+   First, the RRs provide simple documentation of the correct addresses
+   to use in static configurations of IP/X.25 [11] and SMTP/X.25 [12].
+
+   The RRs could also be used automatically by an internet network-layer
+   router, typically IP.  The procedure would be to map IP address to
+   domain name, then name to canonical name if needed, then following RT
+   records, and finally attempting an IP/X.25 call to the address found.
+   Alternately, configured domain names could be resolved to identify IP
+   to X.25/ISDN bindings for a static but periodically refreshed routing
+   table.
+
+   This provides a function similar to ARP for wide area non-broadcast
+   networks that will scale well to a network with hundreds of millions
+   of hosts.
+
+   Also, a standard address binding reference will facilitate other
+   experiments in the use of X.25 and ISDN, especially in serious
+   inter-operability testing.  The majority of work in such a test is
+   establishing the n-squared entries in static tables.
+
+   Finally, the RRs are intended for use in a proposal [13] by one of
+   the authors for a possible next-generation internet.
+
+3.1. The X25 RR
+
+   The X25 RR is defined with mnemonic X25 and type code 19 (decimal).
+
+   X25 has the following format:
+
+   <owner> <ttl> <class> X25 <PSDN-address>
+
+   <PSDN-address> is required in all X25 RRs.
+
+   <PSDN-address> identifies the PSDN (Public Switched Data Network)
+   address in the X.121 [10] numbering plan associated with <owner>.
+   Its format in master files is a <character-string> syntactically
+   identical to that used in TXT and HINFO.
+
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                        [Page 6]
+
+RFC 1183                 New DNS RR Definitions             October 1990
+
+
+   The format of X25 is class insensitive.  X25 RRs cause no additional
+   section processing.
+
+   The <PSDN-address> is a string of decimal digits, beginning with the
+   4 digit DNIC (Data Network Identification Code), as specified in
+   X.121. National prefixes (such as a 0) MUST NOT be used.
+
+   For example:
+
+   Relay.Prime.COM.  X25       311061700956
+
+3.2. The ISDN RR
+
+   The ISDN RR is defined with mnemonic ISDN and type code 20 (decimal).
+
+   An ISDN (Integrated Service Digital Network) number is simply a
+   telephone number.  The intent of the members of the CCITT is to
+   upgrade all telephone and data network service to a common service.
+
+   The numbering plan (E.163/E.164) is the same as the familiar
+   international plan for POTS (an un-official acronym, meaning Plain
+   Old Telephone Service).  In E.166, CCITT says "An E.163/E.164
+   telephony subscriber may become an ISDN subscriber without a number
+   change."
+
+   ISDN has the following format:
+
+   <owner> <ttl> <class> ISDN <ISDN-address> <sa>
+
+   The <ISDN-address> field is required; <sa> is optional.
+
+   <ISDN-address> identifies the ISDN number of <owner> and DDI (Direct
+   Dial In) if any, as defined by E.164 [8] and E.163 [7], the ISDN and
+   PSTN (Public Switched Telephone Network) numbering plan.  E.163
+   defines the country codes, and E.164 the form of the addresses.  Its
+   format in master files is a <character-string> syntactically
+   identical to that used in TXT and HINFO.
+
+   <sa> specifies the subaddress (SA).  The format of <sa> in master
+   files is a <character-string> syntactically identical to that used in
+   TXT and HINFO.
+
+   The format of ISDN is class insensitive.  ISDN RRs cause no
+   additional section processing.
+
+   The <ISDN-address> is a string of characters, normally decimal
+   digits, beginning with the E.163 country code and ending with the DDI
+   if any.  Note that ISDN, in Q.931, permits any IA5 character in the
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                        [Page 7]
+
+RFC 1183                 New DNS RR Definitions             October 1990
+
+
+   general case.
+
+   The <sa> is a string of hexadecimal digits.  For digits 0-9, the
+   concrete encoding in the Q.931 call setup information element is
+   identical to BCD.
+
+   For example:
+
+   Relay.Prime.COM.   IN   ISDN      150862028003217
+   sh.Prime.COM.      IN   ISDN      150862028003217 004
+
+   (Note: "1" is the country code for the North American Integrated
+   Numbering Area, i.e., the system of "area codes" familiar to people
+   in those countries.)
+
+   The RR data is the ASCII representation of the digits.  It is encoded
+   as one or two <character-string>s, i.e., count followed by
+   characters.
+
+   CCITT recommendation E.166 [9] defines prefix escape codes for the
+   representation of ISDN (E.163/E.164) addresses in X.121, and PSDN
+   (X.121) addresses in E.164.  It specifies that the exact codes are a
+   "national matter", i.e., different on different networks.  A host
+   connected to the ISDN may be able to use both the X25 and ISDN
+   addresses, with the local prefix added.
+
+3.3. The Route Through RR
+
+   The Route Through RR is defined with mnemonic RT and type code 21
+   (decimal).
+
+   The RT resource record provides a route-through binding for hosts
+   that do not have their own direct wide area network addresses.  It is
+   used in much the same way as the MX RR.
+
+   RT has the following format:
+
+   <owner> <ttl> <class> RT <preference> <intermediate-host>
+
+   Both RDATA fields are required in all RT RRs.
+
+   The first field, <preference>, is a 16 bit integer, representing the
+   preference of the route.  Smaller numbers indicate more preferred
+   routes.
+
+   <intermediate-host> is the domain name of a host which will serve as
+   an intermediate in reaching the host specified by <owner>.  The DNS
+   RRs associated with <intermediate-host> are expected to include at
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                        [Page 8]
+
+RFC 1183                 New DNS RR Definitions             October 1990
+
+
+   least one A, X25, or ISDN record.
+
+   The format of the RT RR is class insensitive.  RT records cause type
+   X25, ISDN, and A additional section processing for <intermediate-
+   host>.
+
+   For example,
+
+   sh.prime.com.      IN   RT   2    Relay.Prime.COM.
+                      IN   RT   10   NET.Prime.COM.
+   *.prime.com.       IN   RT   90   Relay.Prime.COM.
+
+   When a host is looking up DNS records to attempt to route a datagram,
+   it first looks for RT records for the destination host, which point
+   to hosts with address records (A, X25, ISDN) compatible with the wide
+   area networks available to the host.  If it is itself in the set of
+   RT records, it discards any RTs with preferences higher or equal to
+   its own.  If there are no (remaining) RTs, it can then use address
+   records of the destination itself.
+
+   Wild-card RTs are used exactly as are wild-card MXs.  RT's do not
+   "chain"; that is, it is not valid to use the RT RRs found for a host
+   referred to by an RT.
+
+   The concrete encoding is identical to the MX RR.
+
+REFERENCES and BIBLIOGRAPHY
+
+   [1] Stahl, M., "Domain Administrators Guide", RFC 1032, Network
+       Information Center, SRI International, November 1987.
+
+   [2] Lottor, M., "Domain Administrators Operations Guide", RFC 1033,
+       Network Information Center, SRI International, November, 1987.
+
+   [3] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC
+       1034, USC/Information Sciences Institute, November 1987.
+
+   [4] Mockapetris, P., "Domain Names - Implementation and
+       Specification", RFC 1035, USC/Information Sciences Institute,
+       November 1987.
+
+   [5] Spector A., and M. Kazar, "Uniting File Systems", UNIX Review,
+       7(3), pp. 61-69, March 1989.
+
+   [6] Zahn, et al., "Network Computing Architecture", Prentice-Hall,
+       1989.
+
+   [7] International Telegraph and Telephone Consultative Committee,
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                        [Page 9]
+
+RFC 1183                 New DNS RR Definitions             October 1990
+
+
+       "Numbering Plan for the International Telephone Service", CCITT
+       Recommendations E.163., IXth Plenary Assembly, Melbourne, 1988,
+       Fascicle II.2 ("Blue Book").
+
+   [8] International Telegraph and Telephone Consultative Committee,
+       "Numbering Plan for the ISDN Era", CCITT Recommendations E.164.,
+       IXth Plenary Assembly, Melbourne, 1988, Fascicle II.2 ("Blue
+       Book").
+
+   [9] International Telegraph and Telephone Consultative Committee.
+       "Numbering Plan Interworking in the ISDN Era", CCITT
+       Recommendations E.166., IXth Plenary Assembly, Melbourne, 1988,
+       Fascicle II.2 ("Blue Book").
+
+  [10] International Telegraph and Telephone Consultative Committee,
+       "International Numbering Plan for the Public Data Networks",
+       CCITT Recommendations X.121., IXth Plenary Assembly, Melbourne,
+       1988, Fascicle VIII.3 ("Blue Book"); provisional, Geneva, 1978;
+       amended, Geneva, 1980, Malaga-Torremolinos, 1984 and Melborne,
+       1988.
+
+  [11] Korb, J., "Standard for the Transmission of IP datagrams Over
+       Public Data Networks", RFC 877, Purdue University, September
+       1983.
+
+  [12] Ullmann, R., "SMTP on X.25", RFC 1090, Prime Computer, February
+       1989.
+
+  [13] Ullmann, R., "TP/IX: The Next Internet", Prime Computer
+       (unpublished), July 1990.
+
+  [14] Mockapetris, P., "DNS Encoding of Network Names and Other Types",
+       RFC 1101, USC/Information Sciences Institute, April 1989.
+
+Security Considerations
+
+   Security issues are not addressed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                       [Page 10]
+
+RFC 1183                 New DNS RR Definitions             October 1990
+
+
+Authors' Addresses
+
+   Craig F. Everhart
+   Transarc Corporation
+   The Gulf Tower
+   707 Grant Street
+   Pittsburgh, PA  15219
+
+   Phone: +1 412 338 4467
+
+   EMail: Craig_Everhart@transarc.com
+
+
+   Louis A. Mamakos
+   Network Infrastructure Group
+   Computer Science Center
+   University of Maryland
+   College Park, MD 20742-2411
+
+   Phone: +1-301-405-7836
+
+   Email: louie@Sayshell.UMD.EDU
+
+
+   Robert Ullmann 10-30
+   Prime Computer, Inc.
+   500 Old Connecticut Path
+   Framingham, MA 01701
+
+   Phone: +1 508 620 2800 ext 1736
+
+   Email: Ariel@Relay.Prime.COM
+
+
+   Paul Mockapetris
+   USC Information Sciences Institute
+   4676 Admiralty Way
+   Marina del Rey, CA 90292
+
+   Phone: 213-822-1511
+
+   EMail: pvm@isi.edu
+
+
+
+
+
+
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                       [Page 11]
+
\ No newline at end of file
diff --git a/usr.sbin/named/doc/rfc/rfc1535 b/usr.sbin/named/doc/rfc/rfc1535
new file mode 100644
index 00000000000..03bddeebedc
--- /dev/null
+++ b/usr.sbin/named/doc/rfc/rfc1535
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                          E. Gavron
+Request for Comments: 1535                            ACES Research Inc.
+Category: Informational                                     October 1993
+
+
+              A Security Problem and Proposed Correction
+                   With Widely Deployed DNS Software
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard.  Distribution of this memo is
+   unlimited.
+
+Abstract
+
+   This document discusses a flaw in some of the currently distributed
+   name resolver clients.  The flaw exposes a security weakness related
+   to the search heuristic invoked by these same resolvers when users
+   provide a partial domain name, and which is easy to exploit (although
+   not by the masses).  This document points out the flaw, a case in
+   point, and a solution.
+
+Background
+
+   Current Domain Name Server clients are designed to ease the burden of
+   remembering IP dotted quad addresses.  As such they translate human-
+   readable names into addresses and other resource records.  Part of
+   the translation process includes understanding and dealing with
+   hostnames that are not fully qualified domain names (FQDNs).
+
+   An absolute "rooted" FQDN is of the format {name}{.} A non "rooted"
+   domain name is of the format {name}
+
+   A domain name may have many parts and typically these include the
+   host, domain, and type.  Example:  foobar.company.com or
+   fooschool.university.edu.
+
+Flaw
+
+   The problem with most widely distributed resolvers based on the BSD
+   BIND resolver is that they attempt to resolve a partial name by
+   processing a search list of partial domains to be added to portions
+   of the specified host name until a DNS record is found.  This
+   "feature" is disabled by default in the official BIND 4.9.2 release.
+
+   Example: A TELNET attempt by    User@Machine.Tech.ACES.COM
+                             to    UnivHost.University.EDU
+
+
+
+Gavron                                                          [Page 1]
+
+RFC 1535               DNS Software Enhancements            October 1993
+
+
+   The resolver client will realize that since "UnivHost.University.EDU"
+   does not end with a ".", it is not an absolute "rooted" FQDN.  It
+   will then try the following combinations until a resource record is
+   found:
+
+                UnivHost.University.EDU.Tech.ACES.COM.
+                UnivHost.University.EDU.ACES.COM.
+                UnivHost.University.EDU.COM.
+                UnivHost.University.EDU.
+
+Security Issue
+
+   After registering the EDU.COM domain, it was discovered that an
+   unliberal application of one wildcard CNAME record would cause *all*
+   connects from any .COM site to any .EDU site to terminate at one
+   target machine in the private edu.com sub-domain.
+
+   Further, discussion reveals that specific hostnames registered in
+   this private subdomain, or any similarly named subdomain may be used
+   to spoof a host.
+
+        Example:        harvard.edu.com.        CNAME   targethost
+
+   Thus all connects to Harvard.edu from all .com sites would end up at
+   targthost, a machine which could provide a Harvard.edu login banner.
+
+   This is clearly unacceptable.  Further, it could only be made worse
+   with domains like COM.EDU, MIL.GOV, GOV.COM, etc.
+
+Public vs. Local Name Space Administration
+
+   The specification of the Domain Name System and the software that
+   implements it provides an undifferentiated hierarchy which permits
+   delegation of administration for subordinate portions of the name
+   space.  Actual administration of the name space is divided between
+   "public" and "local" portions.  Public administration pertains to all
+   top-level domains, such as .COM and .EDU.  For some domains, it also
+   pertains to some number of sub-domain levels.  The multi-level nature
+   of the public administration is most evident for top-level domains
+   for countries.  For example in the Fully Qualified Domain Name,
+   dbc.mtview.ca.us., the portion "mtview.ca.us" represents three levels
+   of public administration.  Only the left-most portion is subject to
+   local administration.
+
+
+
+
+
+
+
+
+Gavron                                                          [Page 2]
+
+RFC 1535               DNS Software Enhancements            October 1993
+
+
+   The danger of the heuristic search common in current practise is that
+   it it is possible to "intercept" the search by matching against an
+   unintended value while walking up the search list.  While this is
+   potentially dangerous at any level, it is entirely unacceptable when
+   the error impacts users outside of a local administration.
+
+   When attempting to resolve a partial domain name, DNS resolvers use
+   the Domain Name of the searching host for deriving the search list.
+   Existing DNS resolvers do not distinguish the portion of that name
+   which is in the locally administered scope from the part that is
+   publically administered.
+
+Solution(s)
+
+   At a minimum, DNS resolvers must honor the BOUNDARY between local and
+   public administration, by limiting any search lists to locally-
+   administered portions of the Domain Name space.  This requires a
+   parameter which shows the scope of the name space controlled by the
+   local administrator.
+
+   This would permit progressive searches from the most qualified to
+   less qualified up through the locally controlled domain, but not
+   beyond.
+
+   For example, if the local user were trying to reach:
+
+        User@chief.admin.DESERTU.EDU from
+        starburst,astro.DESERTU.EDU,
+
+   it is reasonable to permit the user to enter just chief.admin, and
+   for the search to cover:
+
+        chief.admin.astro.DESERTU.EDU
+        chief.admin.DESERTU.EDU
+
+   but not
+
+        chief.admin.EDU
+
+   In this case, the value of "search" should be set to "DESERTU.EDU"
+   because that's the scope of the name space controlled by the local
+   DNS administrator.
+
+   This is more than a mere optimization hack.  The local administrator
+   has control over the assignment of names within the locally
+   administered domain, so the administrator can make sure that
+   abbreviations result in the right thing.  Outside of the local
+   control, users are necessarily at risk.
+
+
+
+Gavron                                                          [Page 3]
+
+RFC 1535               DNS Software Enhancements            October 1993
+
+
+   A more stringent mechanism is implemented in BIND 4.9.2, to respond
+   to this problem:
+
+   The DNS Name resolver clients narrows its IMPLICIT search list IF ANY
+   to only try the first and the last of the examples shown.
+
+   Any additional search alternatives must be configured into the
+   resolver EXPLICITLY.
+
+   DNS Name resolver software SHOULD NOT use implicit search lists in
+   attempts to resolve partial names into absolute FQDNs other than the
+   hosts's immediate parent domain.
+
+   Resolvers which continue to use implicit search lists MUST limit
+   their scope to locally administered sub-domains.
+
+   DNS Name resolver software SHOULD NOT come pre-configured with
+   explicit search lists that perpetuate this problem.
+
+   Further, in any event where a "." exists in a specified name it
+   should be assumed to be a fully qualified domain name (FQDN) and
+   SHOULD be tried as a rooted name first.
+
+   Example:  Given  user@a.b.c.d connecting to e.f.g.h  only two tries
+             should be attempted as a result of using an implicit
+             search list:
+
+                e.f.g.h.  and e.f.g.h.b.c.d.
+
+             Given user@a.b.c.d. connecting to host those same two
+             tries would appear as:
+
+                x.b.c.d.  and x.
+
+   Some organizations make regular use of multi-part, partially
+   qualified Domain Names.  For example, host foo.loc1.org.city.state.us
+   might be used to making references to bar.loc2, or mumble.loc3, all
+   of which refer to whatever.locN.org.city.state.us
+
+   The stringent implicit search rules for BIND 4.9.2 will now cause
+   these searches to fail.  To return the ability for them to succeed,
+   configuration of the client resolvers must be changed to include an
+   explicit search rule for org.city.state.us.  That is, it must contain
+   an explicit rule for any -- and each -- portion of the locally-
+   administered sub-domain that it wishes to have as part of the search
+   list.
+
+
+
+
+
+Gavron                                                          [Page 4]
+
+RFC 1535               DNS Software Enhancements            October 1993
+
+
+References
+
+   [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
+       RFC 1034, USC/Information Sciences Institute, November 1987.
+
+   [2] Mockapetris, P., "Domain Names Implementation and Specification",
+       STD 13, RFC 1035, USC/Information Sciences Institute, November
+       1987.
+
+   [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
+       974, CSNET CIC BBN, January 1986.
+
+   [4] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller,
+       "Common DNS Implementation Errors and Suggested Fixes", RFC 1536,
+       USC/Information Sciences Institute, USC, October 1993.
+
+   [5] Beertema, P., "Common DNS Data File Configuration Errors", RFC
+       1537, CWI, October 1993.
+
+Security Considerations
+
+   This memo indicates vulnerabilities with all too-forgiving DNS
+   clients.  It points out a correction that would eliminate the future
+   potential of the problem.
+
+Author's Address
+
+   Ehud Gavron
+   ACES Research Inc.
+   PO Box 14546
+   Tucson, AZ 85711
+
+   Phone: (602) 743-9841
+   EMail: gavron@aces.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gavron                                                          [Page 5]
+
diff --git a/usr.sbin/named/doc/rfc/rfc1536 b/usr.sbin/named/doc/rfc/rfc1536
new file mode 100644
index 00000000000..5ff2b25d037
--- /dev/null
+++ b/usr.sbin/named/doc/rfc/rfc1536
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                           A. Kumar
+Request for Comments: 1536                                     J. Postel
+Category: Informational                                        C. Neuman
+                                                                     ISI
+                                                               P. Danzig
+                                                               S. Miller
+                                                                     USC
+                                                            October 1993
+
+
+          Common DNS Implementation Errors and Suggested Fixes
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard.  Distribution of this memo is
+   unlimited.
+
+Abstract
+
+   This memo describes common errors seen in DNS implementations and
+   suggests some fixes. Where applicable, violations of recommendations
+   from STD 13, RFC 1034 and STD 13, RFC 1035 are mentioned. The memo
+   also describes, where relevant, the algorithms followed in BIND
+   (versions 4.8.3 and 4.9 which the authors referred to) to serve as an
+   example.
+
+Introduction
+
+   The last few years have seen, virtually, an explosion of DNS traffic
+   on the NSFnet backbone. Various DNS implementations and various
+   versions of these implementations interact with each other, producing
+   huge amounts of unnecessary traffic. Attempts are being made by
+   researchers all over the internet, to document the nature of these
+   interactions, the symptomatic traffic patterns and to devise remedies
+   for the sick pieces of software.
+
+   This draft is an attempt to document fixes for known DNS problems so
+   people know what problems to watch out for and how to repair broken
+   software.
+
+1. Fast Retransmissions
+
+   DNS implements the classic request-response scheme of client-server
+   interaction. UDP is, therefore, the chosen protocol for communication
+   though TCP is used for zone transfers. The onus of requerying in case
+   no response is seen in a "reasonable" period of time, lies with the
+   client. Although RFC 1034 and 1035 do not recommend any
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                          [Page 1]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+   retransmission policy, RFC 1035 does recommend that the resolvers
+   should cycle through a list of servers. Both name servers and stub
+   resolvers should, therefore, implement some kind of a retransmission
+   policy based on round trip time estimates of the name servers. The
+   client should back-off exponentially, probably to a maximum timeout
+   value.
+
+   However, clients might not implement either of the two. They might
+   not wait a sufficient amount of time before retransmitting or they
+   might not back-off their inter-query times sufficiently.
+
+   Thus, what the server would see will be a series of queries from the
+   same querying entity, spaced very close together. Of course, a
+   correctly implemented server discards all duplicate queries but the
+   queries contribute to wide-area traffic, nevertheless.
+
+   We classify a retransmission of a query as a pure Fast retry timeout
+   problem when a series of query packets meet the following conditions.
+
+      a. Query packets are seen within a time less than a "reasonable
+         waiting period" of each other.
+
+      b. No response to the original query was seen i.e., we see two or
+         more queries, back to back.
+
+      c. The query packets share the same query identifier.
+
+      d. The server eventually responds to the query.
+
+A GOOD IMPLEMENTATION:
+
+   BIND (we looked at versions 4.8.3 and 4.9) implements a good
+   retransmission algorithm which solves or limits all of these
+   problems.  The Berkeley stub-resolver queries servers at an interval
+   that starts at the greater of 4 seconds and 5 seconds divided by the
+   number of servers the resolver queries. The resolver cycles through
+   servers and at the end of a cycle, backs off the time out
+   exponentially.
+
+   The Berkeley full-service resolver (built in with the program
+   "named") starts with a time-out equal to the greater of 4 seconds and
+   two times the round-trip time estimate of the server.  The time-out
+   is backed off with each cycle, exponentially, to a ceiling value of
+   45 seconds.
+
+
+
+
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                          [Page 2]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+FIXES:
+
+      a. Estimate round-trip times or set a reasonably high initial
+         time-out.
+
+      b. Back-off timeout periods exponentially.
+
+      c. Yet another fundamental though difficult fix is to send the
+         client an acknowledgement of a query, with a round-trip time
+         estimate.
+
+   Since UDP is used, no response is expected by the client until the
+   query is complete.  Thus, it is less likely to have information about
+   previous packets on which to estimate its back-off time.  Unless, you
+   maintain state across queries, so subsequent queries to the same
+   server use information from previous queries.  Unfortunately, such
+   estimates are likely to be inaccurate for chained requests since the
+   variance is likely to be high.
+
+   The fix chosen in the ARDP library used by Prospero is that the
+   server will send an initial acknowledgement to the client in those
+   cases where the server expects the query to take a long time (as
+   might be the case for chained queries).  This initial acknowledgement
+   can include an expected time to wait before retrying.
+
+   This fix is more difficult since it requires that the client software
+   also be trained to expect the acknowledgement packet. This, in an
+   internet of millions of hosts is at best a hard problem.
+
+2. Recursion Bugs
+
+   When a server receives a client request, it first looks up its zone
+   data and the cache to check if the query can be answered. If the
+   answer is unavailable in either place, the server seeks names of
+   servers that are more likely to have the information, in its cache or
+   zone data. It then does one of two things. If the client desires the
+   server to recurse and the server architecture allows recursion, the
+   server chains this request to these known servers closest to the
+   queried name. If the client doesn't seek recursion or if the server
+   cannot handle recursion, it returns the list of name servers to the
+   client assuming the client knows what to do with these records.
+
+   The client queries this new list of name servers to get either the
+   answer, or names of another set of name servers to query. This
+   process repeats until the client is satisfied. Servers might also go
+   through this chaining process if the server returns a CNAME record
+   for the queried name. Some servers reprocess this name to try and get
+   the desired record type.
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                          [Page 3]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+   However, in certain cases, this chain of events may not be good. For
+   example, a broken or malicious name server might list itself as one
+   of the name servers to query again. The unsuspecting client resends
+   the same query to the same server.
+
+   In another situation, more difficult to detect, a set of servers
+   might form a loop wherein A refers to B and B refers to A. This loop
+   might involve more than two servers.
+
+   Yet another error is where the client does not know how to process
+   the list of name servers returned, and requeries the same server
+   since that is one (of the few) servers it knows.
+
+   We, therefore, classify recursion bugs into three distinct
+   categories:
+
+      a. Ignored referral: Client did not know how to handle NS records
+         in the AUTHORITY section.
+
+      b. Too many referrals: Client called on a server too many times,
+         beyond a "reasonable" number, with same query. This is
+         different from a Fast retransmission problem and a Server
+         Failure detection problem in that a response is seen for every
+         query.  Also, the identifiers are always different. It implies
+         client is in a loop and should have detected that and broken
+         it.  (RFC 1035 mentions that client should not recurse beyond
+         a certain depth.)
+
+      c. Malicious Server: a server refers to itself in the authority
+         section. If a server does not have an answer now, it is very
+         unlikely it will be any better the next time you query it,
+         specially when it claims to be authoritative over a domain.
+
+      RFC 1034 warns against such situations, on page 35.
+
+      "Bound the amount of work (packets sent, parallel processes
+       started) so that a request can't get into an infinite loop or
+       start off a chain reaction of requests or queries with other
+       implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED
+       SOME DATA."
+
+A GOOD IMPLEMENTATION:
+
+   BIND fixes at least one of these problems. It places an upper limit
+   on the number of recursive queries it will make, to answer a
+   question.  It chases a maximum of 20 referral links and 8 canonical
+   name translations.
+
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                          [Page 4]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+FIXES:
+
+      a. Set an upper limit on the number of referral links and CNAME
+         links you are willing to chase.
+
+         Note that this is not guaranteed to break only recursion loops.
+         It could, in a rare case, prune off a very long search path,
+         prematurely.  We know, however, with high probability, that if
+         the number of links cross a certain metric (two times the depth
+         of the DNS tree), it is a recursion problem.
+
+      b. Watch out for self-referring servers. Avoid them whenever
+         possible.
+
+      c. Make sure you never pass off an authority NS record with your
+         own name on it!
+
+      d. Fix clients to accept iterative answers from servers not built
+         to provide recursion. Such clients should either be happy with
+         the non-authoritative answer or be willing to chase the
+         referral links themselves.
+
+3. Zero Answer Bugs:
+
+   Name servers sometimes return an authoritative NOERROR with no
+   ANSWER, AUTHORITY or ADDITIONAL records. This happens when the
+   queried name is valid but it does not have a record of the desired
+   type. Of course, the server has authority over the domain.
+
+   However, once again, some implementations of resolvers do not
+   interpret this kind of a response reasonably. They always expect an
+   answer record when they see an authoritative NOERROR. These entities
+   continue to resend their queries, possibly endlessly.
+
+A GOOD IMPLEMENTATION
+
+   BIND resolver code does not query a server more than 3 times. If it
+   is unable to get an answer from 4 servers, querying them three times
+   each, it returns error.
+
+   Of course, it treats a zero-answer response the way it should be
+   treated; with respect!
+
+FIXES:
+
+      a. Set an upper limit on the number of retransmissions for a given
+         query, at the very least.
+
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                          [Page 5]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+      b. Fix resolvers to interpret such a response as an authoritative
+         statement of non-existence of the record type for the given
+         name.
+
+4. Inability to detect server failure:
+
+   Servers in the internet are not very reliable (they go down every
+   once in a while) and resolvers are expected to adapt to the changed
+   scenario by not querying the server for a while. Thus, when a server
+   does not respond to a query, resolvers should try another server.
+   Also, non-stub resolvers should update their round trip time estimate
+   for the server to a large value so that server is not tried again
+   before other, faster servers.
+
+   Stub resolvers, however, cycle through a fixed set of servers and if,
+   unfortunately, a server is down while others do not respond for other
+   reasons (high load, recursive resolution of query is taking more time
+   than the resolver's time-out, ....), the resolver queries the dead
+   server again! In fact, some resolvers might not set an upper limit on
+   the number of query retransmissions they will send and continue to
+   query dead servers indefinitely.
+
+   Name servers running system or chained queries might also suffer from
+   the same problem. They store names of servers they should query for a
+   given domain. They cycle through these names and in case none of them
+   answers, hit each one more than one. It is, once again, important
+   that there be an upper limit on the number of retransmissions, to
+   prevent network overload.
+
+   This behavior is clearly in violation of the dictum in RFC 1035 (page
+   46)
+
+      "If a resolver gets a server error or other bizarre response
+       from a name server, it should remove it from SLIST, and may
+       wish to schedule an immediate transmission to the next
+       candidate server address."
+
+   Removal from SLIST implies that the server is not queried again for
+   some time.
+
+   Correctly implemented full-service resolvers should, as pointed out
+   before, update round trip time values for servers that do not respond
+   and query them only after other, good servers. Full-service resolvers
+   might, however, not follow any of these common sense directives. They
+   query dead servers, and they query them endlessly.
+
+
+
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                          [Page 6]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+A GOOD IMPLEMENTATION:
+
+   BIND places an upper limit on the number of times it queries a
+   server.  Both the stub-resolver and the full-service resolver code do
+   this.  Also, since the full-service resolver estimates round-trip
+   times and sorts name server addresses by these estimates, it does not
+   query a dead server again, until and unless all the other servers in
+   the list are dead too!  Further, BIND implements exponential back-off
+   too.
+
+FIXES:
+
+      a. Set an upper limit on number of retransmissions.
+
+      b. Measure round-trip time from servers (some estimate is better
+         than none). Treat no response as a "very large" round-trip
+         time.
+
+      c. Maintain a weighted rtt estimate and decay the "large" value
+         slowly, with time, so that the server is eventually tested
+         again, but not after an indefinitely long period.
+
+      d. Follow an exponential back-off scheme so that even if you do
+         not restrict the number of queries, you do not overload the
+         net excessively.
+
+5. Cache Leaks:
+
+   Every resource record returned by a server is cached for TTL seconds,
+   where the TTL value is returned with the RR. Full-service (or stub)
+   resolvers cache the RR and answer any queries based on this cached
+   information, in the future, until the TTL expires. After that, one
+   more query to the wide-area network gets the RR in cache again.
+
+   Full-service resolvers might not implement this caching mechanism
+   well. They might impose a limit on the cache size or might not
+   interpret the TTL value correctly. In either case, queries repeated
+   within a TTL period of a RR constitute a cache leak.
+
+A GOOD/BAD IMPLEMENTATION:
+
+   BIND has no restriction on the cache size and the size is governed by
+   the limits on the virtual address space of the machine it is running
+   on. BIND caches RRs for the duration of the TTL returned with each
+   record.
+
+   It does, however, not follow the RFCs with respect to interpretation
+   of a 0 TTL value. If a record has a TTL value of 0 seconds, BIND uses
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                          [Page 7]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+   the minimum TTL value, for that zone, from the SOA record and caches
+   it for that duration. This, though it saves some traffic on the
+   wide-area network, is not correct behavior.
+
+FIXES:
+
+      a. Look over your caching mechanism to ensure TTLs are interpreted
+         correctly.
+
+      b. Do not restrict cache sizes (come on, memory is cheap!).
+         Expired entries are reclaimed periodically, anyway. Of course,
+         the cache size is bound to have some physical limit. But, when
+         possible, this limit should be large (run your name server on
+         a machine with a large amount of physical memory).
+
+      c. Possibly, a mechanism is needed to flush the cache, when it is
+         known or even suspected that the information has changed.
+
+6. Name Error Bugs:
+
+   This bug is very similar to the Zero Answer bug. A server returns an
+   authoritative NXDOMAIN when the queried name is known to be bad, by
+   the server authoritative for the domain, in the absence of negative
+   caching. This authoritative NXDOMAIN response is usually accompanied
+   by the SOA record for the domain, in the authority section.
+
+   Resolvers should recognize that the name they queried for was a bad
+   name and should stop querying further.
+
+   Some resolvers might, however, not interpret this correctly and
+   continue to query servers, expecting an answer record.
+
+   Some applications, in fact, prompt NXDOMAIN answers! When given a
+   perfectly good name to resolve, they append the local domain to it
+   e.g., an application in the domain "foo.bar.com", when trying to
+   resolve the name "usc.edu" first tries "usc.edu.foo.bar.com", then
+   "usc.edu.bar.com" and finally the good name "usc.edu". This causes at
+   least two queries that return NXDOMAIN, for every good query. The
+   problem is aggravated since the negative answers from the previous
+   queries are not cached.  When the same name is sought again, the
+   process repeats.
+
+   Some DNS resolver implementations suffer from this problem, too. They
+   append successive sub-parts of the local domain using an implicit
+   searchlist mechanism, when certain conditions are satisfied and try
+   the original name, only when this first set of iterations fails. This
+   behavior recently caused pandemonium in the Internet when the domain
+   "edu.com" was registered and a wildcard "CNAME" record placed at the
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                          [Page 8]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+   top level. All machines from "com" domains trying to connect to hosts
+   in the "edu" domain ended up with connections to the local machine in
+   the "edu.com" domain!
+
+GOOD/BAD IMPLEMENTATIONS:
+
+   Some local versions of BIND already implement negative caching. They
+   typically cache negative answers with a very small TTL, sufficient to
+   answer a burst of queries spaced close together, as is typically
+   seen.
+
+   The next official public release of BIND (4.9.2) will have negative
+   caching as an ifdef'd feature.
+
+   The BIND resolver appends local domain to the given name, when one of
+   two conditions is met:
+
+      i.  The name has no periods and the flag RES_DEFNAME is set.
+      ii. There is no trailing period and the flag RES_DNSRCH is set.
+
+   The flags RES_DEFNAME and RES_DNSRCH are default resolver options, in
+   BIND, but can be changed at compile time.
+
+   Only if the name, so generated, returns an NXDOMAIN is the original
+   name tried as a Fully Qualified Domain Name. And only if it contains
+   at least one period.
+
+FIXES:
+
+      a. Fix the resolver code.
+
+      b. Negative Caching. Negative caching servers will restrict the
+         traffic seen on the wide-area network, even if not curb it
+         altogether.
+
+      c. Applications and resolvers should not append the local domain to
+         names they seek to resolve, as far as possible. Names
+         interspersed with periods should be treated as Fully Qualified
+         Domain Names.
+
+         In other words, Use searchlists only when explicitly specified.
+         No implicit searchlists should be used. A name that contains
+         any dots should first be tried as a FQDN and if that fails, with
+         the local domain name (or searchlist if specified) appended. A
+         name containing no dots can be appended with the searchlist right
+         away, but once again, no implicit searchlists should be used.
+
+
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                          [Page 9]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+   Associated with the name error bug is another problem where a server
+   might return an authoritative NXDOMAIN, although the name is valid. A
+   secondary server, on start-up, reads the zone information from the
+   primary, through a zone transfer. While it is in the process of
+   loading the zones, it does not have information about them, although
+   it is authoritative for them.  Thus, any query for a name in that
+   domain is answered with an NXDOMAIN response code. This problem might
+   not be disastrous were it not for negative caching servers that cache
+   this answer and so propagate incorrect information over the internet.
+
+BAD IMPLEMENTATION:
+
+   BIND apparently suffers from this problem.
+
+   Also, a new name added to the primary database will take a while to
+   propagate to the secondaries. Until that time, they will return
+   NXDOMAIN answers for a good name. Negative caching servers store this
+   answer, too and aggravate this problem further. This is probably a
+   more general DNS problem but is apparently more harmful in this
+   situation.
+
+FIX:
+
+      a. Servers should start answering only after loading all the zone
+         data. A failed server is better than a server handing out
+         incorrect information.
+
+      b. Negative cache records for a very small time, sufficient only
+         to ward off a burst of requests for the same bad name. This
+         could be related to the round-trip time of the server from
+         which the negative answer was received. Alternatively, a
+         statistical measure of the amount of time for which queries
+         for such names are received could be used. Minimum TTL value
+         from the SOA record is not advisable since they tend to be
+         pretty large.
+
+      c. A "PUSH" (or, at least, a "NOTIFY") mechanism should be allowed
+         and implemented, to allow the primary server to inform
+         secondaries that the database has been modified since it last
+         transferred zone data.  To alleviate the problem of "too many
+         zone transfers" that this might cause, Incremental Zone
+         Transfers should also be part of DNS.  Also, the primary should
+         not NOTIFY/PUSH with every update but bunch a good number
+         together.
+
+
+
+
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                         [Page 10]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+7. Format Errors:
+
+   Some resolvers issue query packets that do not necessarily conform to
+   standards as laid out in the relevant RFCs. This unnecessarily
+   increases net traffic and wastes server time.
+
+FIXES:
+
+      a. Fix resolvers.
+
+      b. Each resolver verify format of packets before sending them out,
+         using a mechanism outside of the resolver. This is, obviously,
+         needed only if step 1 cannot be followed.
+
+References
+
+   [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
+       RFC 1034, USC/Information Sciences Institute, November 1987.
+
+   [2] Mockapetris, P., "Domain Names Implementation and Specification",
+       STD 13, RFC 1035, USC/Information Sciences Institute, November
+       1987.
+
+   [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
+       974, CSNET CIC BBN, January 1986.
+
+   [4] Gavron, E., "A Security Problem and Proposed Correction With
+       Widely Deployed DNS Software", RFC 1535, ACES Research Inc.,
+       October 1993.
+
+   [5] Beertema, P., "Common DNS Data File Configuration Errors", RFC
+       1537, CWI, October 1993.
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                         [Page 11]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+Authors' Addresses
+
+   Anant Kumar
+   USC Information Sciences Institute
+   4676 Admiralty Way
+   Marina Del Rey CA 90292-6695
+
+   Phone:(310) 822-1511
+   FAX:  (310) 823-6741
+   EMail: anant@isi.edu
+
+
+   Jon Postel
+   USC Information Sciences Institute
+   4676 Admiralty Way
+   Marina Del Rey CA 90292-6695
+
+   Phone:(310) 822-1511
+   FAX:  (310) 823-6714
+   EMail: postel@isi.edu
+
+
+   Cliff Neuman
+   USC Information Sciences Institute
+   4676 Admiralty Way
+   Marina Del Rey CA 90292-6695
+
+   Phone:(310) 822-1511
+   FAX:  (310) 823-6714
+   EMail: bcn@isi.edu
+
+
+   Peter Danzig
+   Computer Science Department
+   University of Southern California
+   University Park
+
+   EMail: danzig@caldera.usc.edu
+
+
+   Steve Miller
+   Computer Science Department
+   University of Southern California
+   University Park
+   Los Angeles CA 90089
+
+   EMail: smiller@caldera.usc.edu
+
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                         [Page 12]
+
diff --git a/usr.sbin/named/doc/rfc/rfc1537 b/usr.sbin/named/doc/rfc/rfc1537
new file mode 100644
index 00000000000..81b97683156
--- /dev/null
+++ b/usr.sbin/named/doc/rfc/rfc1537
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                        P. Beertema
+Request for Comments: 1537                                           CWI
+Category: Informational                                     October 1993
+
+
+               Common DNS Data File Configuration Errors
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard.  Distribution of this memo is
+   unlimited.
+
+Abstract
+
+   This memo describes errors often found in DNS data files. It points
+   out common mistakes system administrators tend to make and why they
+   often go unnoticed for long periods of time.
+
+Introduction
+
+   Due to the lack of extensive documentation and automated tools, DNS
+   zone files have mostly been configured by system administrators, by
+   hand. Some of the rules for writing the data files are rather subtle
+   and a few common mistakes are seen in domains worldwide.
+
+   This document is an attempt to list "surprises" that administrators
+   might find hidden in their zone files. It describes the symptoms of
+   the malady and prescribes medicine to cure that. It also gives some
+   general recommendations and advice on specific nameserver and zone
+   file issues and on the (proper) use of the Domain Name System.
+
+1. SOA records
+
+   A problem I've found in quite some nameservers is that the various
+   timers have been set (far) too low. Especially for top level domain
+   nameservers this causes unnecessary traffic over international and
+   intercontinental links.
+
+   Unfortunately the examples given in the BIND manual, in RFC's and in
+   some expert documents give those very short timer values, and that's
+   most likely what people have modeled their SOA records after.
+
+   First of all a short explanation of the timers used in the SOA
+   record:
+
+
+
+
+
+
+Beertema                                                        [Page 1]
+
+RFC 1537       Common DNS Data File Configuration Errors    October 1993
+
+
+        - Refresh: The SOA record of the primary server is checked
+                   every "refresh" time by the secondary servers;
+                   if it has changed, a zone transfer is done.
+
+        - Retry: If a secondary server cannot reach the primary
+                 server, it tries it again every "retry" time.
+
+        - Expire: If for "expire" time the primary server cannot
+                  be reached, all information about the zone is
+                  invalidated on the secondary servers (i.e., they
+                  are no longer authoritative for that zone).
+
+        - Minimum TTL: The default TTL value for all records in the
+                       zone file; a different TTL value may be given
+                       explicitly in a record when necessary.
+                       (This timer is named "Minimum", and that's
+                       what it's function should be according to
+                       STD 13, RFC 1035, but most (all?)
+                       implementations take it as the default value
+                       exported with records without an explicit TTL
+                       value).
+
+   For top level domain servers I would recommend the following values:
+
+          86400 ; Refresh     24 hours
+           7200 ; Retry        2 hours
+        2592000 ; Expire      30 days
+         345600 ; Minimum TTL  4 days
+
+   For other servers I would suggest:
+
+          28800 ; Refresh     8 hours
+           7200 ; Retry       2 hours
+         604800 ; Expire      7 days
+          86400 ; Minimum TTL 1 day
+
+   but here the frequency of changes, the required speed of propagation,
+   the reachability of the primary server etc. play a role in optimizing
+   the timer values.
+
+2. Glue records
+
+   Quite often, people put unnecessary glue (A) records in their zone
+   files. Even worse is that I've even seen *wrong* glue records for an
+   external host in a primary zone file! Glue records need only be in a
+   zone file if the server host is within the zone and there is no A
+   record for that host elsewhere in the zone file.
+
+
+
+
+Beertema                                                        [Page 2]
+
+RFC 1537       Common DNS Data File Configuration Errors    October 1993
+
+
+   Old BIND versions ("native" 4.8.3 and older versions) showed the
+   problem that wrong glue records could enter secondary servers in a
+   zone transfer.
+
+3. "Secondary server surprise"
+
+   I've seen it happen on various occasions that hosts got bombarded by
+   nameserver requests without knowing why. On investigation it turned
+   out then that such a host was supposed to (i.e., the information was
+   in the root servers) run secondary for some domain (or reverse (in-
+   addr.arpa)) domain, without that host's nameserver manager having
+   been asked or even been told so!
+
+   Newer BIND versions (4.9 and later) solved this problem.  At the same
+   time though the fix has the disadvantage that it's far less easy to
+   spot this problem.
+
+   Practice has shown that most domain registrars accept registrations
+   of nameservers without checking if primary (!) and secondary servers
+   have been set up, informed, or even asked.  It should also be noted
+   that a combination of long-lasting unreachability of primary
+   nameservers, (therefore) expiration of zone information, plus static
+   IP routing, can lead to massive network traffic that can fill up
+   lines completely.
+
+4. "MX records surprise"
+
+   In a sense similar to point 3. Sometimes nameserver managers enter MX
+   records in their zone files that point to external hosts, without
+   first asking or even informing the systems managers of those external
+   hosts.  This has to be fought out between the nameserver manager and
+   the systems managers involved. Only as a last resort, if really
+   nothing helps to get the offending records removed, can the systems
+   manager turn to the naming authority of the domain above the
+   offending domain to get the problem sorted out.
+
+5. "Name extension surprise"
+
+   Sometimes one encounters weird names, which appear to be an external
+   name extended with a local domain. This is caused by forgetting to
+   terminate a name with a dot: names in zone files that don't end with
+   a dot are always expanded with the name of the current zone (the
+   domain that the zone file stands for or the last $ORIGIN).
+
+   Example: zone file for foo.xx:
+
+   pqr          MX 100  relay.yy.
+   xyz          MX 100  relay.yy           (no trailing dot!)
+
+
+
+Beertema                                                        [Page 3]
+
+RFC 1537       Common DNS Data File Configuration Errors    October 1993
+
+
+   When fully written out this stands for:
+
+      pqr.foo.xx.  MX 100  relay.yy.
+      xyz.foo.xx.  MX 100  relay.yy.foo.xx.   (name extension!)
+
+6. Missing secondary servers
+
+   It is required that there be a least 2 nameservers for a domain. For
+   obvious reasons the nameservers for top level domains need to be very
+   well reachable from all over the Internet. This implies that there
+   must be more than just 2 of them; besides, most of the (secondary)
+   servers should be placed at "strategic" locations, e.g., close to a
+   point where international and/or intercontinental lines come
+   together.  To keep things manageable, there shouldn't be too many
+   servers for a domain either.
+
+   Important aspects in selecting the location of primary and secondary
+   servers are reliability (network, host) and expedient contacts: in
+   case of problems, changes/fixes must be carried out quickly.  It
+   should be considered logical that primary servers for European top
+   level domains should run on a host in Europe, preferably (if
+   possible) in the country itself. For each top level domain there
+   should be 2 secondary servers in Europe and 2 in the USA, but there
+   may of course be more on either side.  An excessive number of
+   nameservers is not a good idea though; a recommended maximum is 7
+   nameservers.  In Europe, EUnet has offered to run secondary server
+   for each European top level domain.
+
+7. Wildcard MX records
+
+   Wildcard MX records should be avoided where possible. They often
+   cause confusion and errors: especially beginning nameserver managers
+   tend to overlook the fact that a host/domain listed with ANY type of
+   record in a zone file is NOT covered by an overall wildcard MX record
+   in that zone; this goes not only for simple domain/host names, but
+   also for names that cover one or more domains. Take the following
+   example in zone foo.bar:
+
+         *            MX 100  mailhost
+         pqr          MX 100  mailhost
+         abc.def      MX 100  mailhost
+
+   This makes pqr.foo.bar, def.foo.bar and abd.def.foo.bar valid
+   domains, but the wildcard MX record covers NONE of them, nor anything
+   below them.  To cover everything by MX records, the required entries
+   are:
+
+
+
+
+
+Beertema                                                        [Page 4]
+
+RFC 1537       Common DNS Data File Configuration Errors    October 1993
+
+
+         *            MX 100  mailhost
+         pqr          MX 100  mailhost
+         *.pqr        MX 100  mailhost
+         abc.def      MX 100  mailhost
+         *.def        MX 100  mailhost
+         *.abc.def    MX 100  mailhost
+
+   An overall wildcard MX record is almost never useful.
+
+   In particular the zone file of a top level domain should NEVER
+   contain only an overall wildcard MX record (*.XX). The effect of such
+   a wildcard MX record can be that mail is unnecessarily sent across
+   possibly expensive links, only to fail at the destination or gateway
+   that the record points to. Top level domain zone files should
+   explicitly list at least all the officially registered primary
+   subdomains.
+
+   Whereas overall wildcard MX records should be avoided, wildcard MX
+   records are acceptable as an explicit part of subdomain entries,
+   provided they are allowed under a given subdomain (to be determined
+   by the naming authority for that domain).
+
+   Example:
+
+         foo.xx.      MX 100  gateway.xx.
+                      MX 200  fallback.yy.
+         *.foo.xx.    MX 100  gateway.xx.
+                      MX 200  fallback.yy.
+8. Hostnames
+
+   People appear to sometimes look only at STD 11, RFC 822 to determine
+   whether a particular hostname is correct or not. Hostnames should
+   strictly conform to the syntax given in STD 13, RFC 1034 (page 11),
+   with *addresses* in addition conforming to RFC 822. As an example
+   take "c&w.blues" which is perfectly legal according to RFC 822, but
+   which can have quite surprising effects on particular systems, e.g.,
+   "telnet c&w.blues" on a Unix system.
+
+9. HINFO records
+
+   There appears to be a common misunderstanding that one of the data
+   fields (usually the second field) in HINFO records is optional. A
+   recent scan of all reachable nameservers in only one country revealed
+   some 300 incomplete HINFO records. Specifying two data fields in a
+   HINFO record is mandatory (RFC 1033), but note that this does *not*
+   mean that HINFO records themselves are mandatory.
+
+
+
+
+
+Beertema                                                        [Page 5]
+
+RFC 1537       Common DNS Data File Configuration Errors    October 1993
+
+
+10. Safety measures and specialties
+
+   Nameservers and resolvers aren't flawless. Bogus queries should be
+   kept from being forwarded to the root servers, since they'll only
+   lead to unnecessary intercontinental traffic. Known bogus queries
+   that can easily be dealt with locally are queries for 0 and broadcast
+   addresses.  To catch such queries, every nameserver should run
+   primary for the 0.in-addr.arpa and 255.in-addr.arpa zones; the zone
+   files need only contain a SOA and an NS record.
+
+   Also each nameserver should run primary for 0.0.127.in-addr.arpa;
+   that zone file should contain a SOA and NS record and an entry:
+
+         1    PTR     localhost.
+
+   There has been extensive discussion about whether or not to append
+   the local domain to it. The conclusion was that "localhost." would be
+   the best solution; reasons given were:
+
+   - "localhost" itself is used and expected to work on some systems.
+
+   - translating 127.0.0.1 into "localhost.my_domain" can cause some
+     software to connect to itself using the loopback interface when
+     it didn't want to.
+
+   Note that all domains that contain hosts should have a "localhost" A
+   record in them.
+
+   People maintaining zone files with the Serial number given in dotted
+   decimal notation (e.g., when SCCS is used to maintain the files)
+   should beware of a bug in all BIND versions: if the serial number is
+   in Release.Version (dotted decimal) notation, then it is virtually
+   impossible to change to a higher release: because of the wrong way
+   that notation is turned into an integer, it results in a serial
+   number that is LOWER than that of the former release.
+
+   For this reason and because the Serial is an (unsigned) integer
+   according to STD 13, RFC 1035, it is recommended not to use the
+   dotted decimal notation. A recommended notation is to use the date
+   (yyyymmdd), if necessary with an extra digit (yyyymmddn) if there is
+   or can be more than one change per day in a zone file.
+
+   Very old versions of DNS resolver code have a bug that causes queries
+   for A records with domain names like "192.16.184.3" to go out. This
+   happens when users type in IP addresses and the resolver code does
+   not catch this case before sending out a DNS query. This problem has
+   been fixed in all resolver implementations known to us but if it
+   still pops up it is very serious because all those queries will go to
+
+
+
+Beertema                                                        [Page 6]
+
+RFC 1537       Common DNS Data File Configuration Errors    October 1993
+
+
+   the root servers looking for top level domains like "3" etc. It is
+   strongly recommended to install the latest (publicly) available BIND
+   version plus all available patches to get rid of these and other
+   problems.
+
+   Running secondary nameserver off another secondary nameserver is
+   possible, but not recommended unless really necessary: there are
+   known cases where it has led to problems like bogus TTL values. This
+   can be caused by older or flawed implementations, but secondary
+   nameservers in principle should always transfer their zones from the
+   official primary nameserver.
+
+11. Some general points
+
+   The Domain Name System and nameserver are purely technical tools, not
+   meant in any way to exert control or impose politics. The function of
+   a naming authority is that of a clearing house. Anyone registering a
+   subdomain under a particular (top level) domain becomes naming
+   authority and therewith the sole responsible for that subdomain.
+   Requests to enter MX or NS records concerning such a subdomain
+   therefore always MUST be honored by the registrar of the next higher
+   domain.
+
+   Examples of practices that are not allowed are:
+
+      - imposing specific mail routing (MX records) when registering
+        a subdomain.
+
+      - making registration of a subdomain dependent on to the use of
+        certain networks or services.
+
+      - using TXT records as a means of (free) commercial advertising.
+
+   In the latter case a network service provider could decide to cut off
+   a particular site until the offending TXT records have been removed
+   from the site's zone file.
+
+   Of course there are obvious cases where a naming authority can refuse
+   to register a particular subdomain and can require a proposed name to
+   be changed in order to get it registered (think of DEC trying to
+   register a domain IBM.XX).
+
+   There are also cases were one has to probe the authority of the
+   person: sending in the application - not every systems manager should
+   be able to register a domain name for a whole university.  The naming
+   authority can impose certain extra rules as long as they don't
+   violate or conflict with the rights and interest of the registrars of
+   subdomains; a top level domain registrar may e.g., require that there
+
+
+
+Beertema                                                        [Page 7]
+
+RFC 1537       Common DNS Data File Configuration Errors    October 1993
+
+
+   be primary subdomain "ac" and "co" only and that subdomains be
+   registered under those primary subdomains.
+
+   The naming authority can also interfere in exceptional cases like the
+   one mentioned in point 4, e.g., by temporarily removing a domain's
+   entry from the nameserver zone files; this of course should be done
+   only with extreme care and only as a last resort.
+
+   When adding NS records for subdomains, top level domain nameserver
+   managers should realize that the people setting up the nameserver for
+   a subdomain often are rather inexperienced and can make mistakes that
+   can easily lead to the subdomain becoming completely unreachable or
+   that can cause unnecessary DNS traffic (see point 1). It is therefore
+   highly recommended that, prior to entering such an NS record, the
+   (top level) nameserver manager does a couple of sanity checks on the
+   new nameserver (SOA record and timers OK?, MX records present where
+   needed? No obvious errors made? Listed secondary servers
+   operational?). Things that cannot be caught though by such checks
+   are:
+
+      - resolvers set up to use external hosts as nameservers
+
+      - nameservers set up to use external hosts as forwarders
+        without permission from those hosts.
+
+   Care should also be taken when registering 2-letter subdomains.
+   Although this is allowed, an implication is that abbreviated
+   addressing (see STD 11, RFC 822, paragraph 6.2.2) is not possible in
+   and under that subdomain.  When requested to register such a domain,
+   one should always notify the people of this consequence. As an
+   example take the name "cs", which is commonly used for Computer
+   Science departments: it is also the name of the top level domain for
+   Czecho-Slovakia, so within the domain cs.foo.bar the user@host.cs is
+   ambiguous in that in can denote both a user on the host
+   host.cs.foo.bar and a user on the host "host" in Czecho-Slovakia.
+   (This example does not take into account the recent political changes
+   in the mentioned country).
+
+References
+
+   [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
+       RFC 1034, USC/Information Sciences Institute, November 1987.
+
+   [2] Mockapetris, P., "Domain Names Implementation and Specification",
+       STD 13, RFC 1035, USC/Information Sciences Institute, November
+       1987.
+
+
+
+
+
+Beertema                                                        [Page 8]
+
+RFC 1537       Common DNS Data File Configuration Errors    October 1993
+
+
+   [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
+       974, CSNET CIC BBN, January 1986.
+
+   [4] Gavron, E., "A Security Problem and Proposed Correction With
+       Widely Deployed DNS Software", RFC 1535, ACES Research Inc.,
+       October 1993.
+
+   [5] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller,
+       "Common DNS Implementation Errors and Suggested Fixes", RFC 1536,
+       USC/Information Sciences Institute, USC, October 1993.
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+Author's Address
+
+   Piet Beertema
+   CWI
+   Kruislaan 413
+   NL-1098 SJ Amsterdam
+   The Netherlands
+
+   Phone: +31 20 592 4112
+   FAX:   +31 20 592 4199
+   EMail: Piet.Beertema@cwi.nl
+
+
+Editor's Address
+
+   Anant Kumar
+   USC Information Sciences Institute
+   4676 Admiralty Way
+   Marina Del Rey CA 90292-6695
+
+   Phone:(310) 822-1511
+   FAX:  (310) 823-6741
+   EMail: anant@isi.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+Beertema                                                        [Page 9]
+
\ No newline at end of file
diff --git a/usr.sbin/named/doc/rfc/rfc1591 b/usr.sbin/named/doc/rfc/rfc1591
new file mode 100644
index 00000000000..89e0a254a23
--- /dev/null
+++ b/usr.sbin/named/doc/rfc/rfc1591
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                          J. Postel
+Request for Comments: 1591                                           ISI
+Category: Informational                                       March 1994
+
+
+              Domain Name System Structure and Delegation
+
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+1. Introduction
+
+   This memo provides some information on the structure of the names in
+   the Domain Name System (DNS), specifically the top-level domain
+   names; and on the administration of domains.  The Internet Assigned
+   Numbers Authority (IANA) is the overall authority for the IP
+   Addresses, the Domain Names, and many other parameters, used in the
+   Internet.  The day-to-day responsibility for the assignment of IP
+   Addresses, Autonomous System Numbers, and most top and second level
+   Domain Names are handled by the Internet Registry (IR) and regional
+   registries.
+
+2.  The Top Level Structure of the Domain Names
+
+   In the Domain Name System (DNS) naming of computers there is a
+   hierarchy of names.  The root of system is unnamed.  There are a set
+   of what are called "top-level domain names" (TLDs).  These are the
+   generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT), and the two
+   letter country codes from ISO-3166.  It is extremely unlikely that
+   any other TLDs will be created.
+
+   Under each TLD may be created a hierarchy of names.  Generally, under
+   the generic TLDs the structure is very flat.  That is, many
+   organizations are registered directly under the TLD, and any further
+   structure is up to the individual organizations.
+
+   In the country TLDs, there is a wide variation in the structure, in
+   some countries the structure is very flat, in others there is
+   substantial structural organization.  In some country domains the
+   second levels are generic categories (such as, AC, CO, GO, and RE),
+   in others they are based on political geography, and in still others,
+   organization names are listed directly under the country code.  The
+   organization for the US country domain is described in RFC 1480 [1].
+
+
+
+
+Postel                                                          [Page 1]
+
+RFC 1591      Domain Name System Structure and Delegation     March 1994
+
+
+   Each of the generic TLDs was created for a general category of
+   organizations.  The country code domains (for example, FR, NL, KR,
+   US) are each organized by an administrator for that country.  These
+   administrators may further delegate the management of portions of the
+   naming tree.  These administrators are performing a public service on
+   behalf of the Internet community.  Descriptions of the generic
+   domains and the US country domain follow.
+
+   Of these generic domains, five are international in nature, and two
+   are restricted to use by entities in the United States.
+
+   World Wide Generic Domains:
+
+   COM - This domain is intended for commercial entities, that is
+         companies.  This domain has grown very large and there is
+         concern about the administrative load and system performance if
+         the current growth pattern is continued.  Consideration is
+         being taken to subdivide the COM domain and only allow future
+         commercial registrations in the subdomains.
+
+   EDU - This domain was originally intended for all educational
+         institutions.  Many Universities, colleges, schools,
+         educational service organizations, and educational consortia
+         have registered here.  More recently a decision has been taken
+         to limit further registrations to 4 year colleges and
+         universities.  Schools and 2-year colleges will be registered
+         in the country domains (see US Domain, especially K12 and CC,
+         below).
+
+   NET - This domain is intended to hold only the computers of network
+         providers, that is the NIC and NOC computers, the
+         administrative computers, and the network node computers.  The
+         customers of the network provider would have domain names of
+         their own (not in the NET TLD).
+
+   ORG - This domain is intended as the miscellaneous TLD for
+         organizations that didn't fit anywhere else.  Some non-
+         government organizations may fit here.
+
+   INT - This domain is for organizations established by international
+         treaties, or international databases.
+
+   United States Only Generic Domains:
+
+   GOV - This domain was originally intended for any kind of government
+         office or agency.  More recently a decision was taken to
+         register only agencies of the US Federal government in this
+         domain.  State and local agencies are registered in the country
+
+
+
+Postel                                                          [Page 2]
+
+RFC 1591      Domain Name System Structure and Delegation     March 1994
+
+
+         domains (see US Domain, below).
+
+   MIL - This domain is used by the US military.
+
+   Example country code Domain:
+
+   US - As an example of a country domain, the US domain provides for
+        the registration of all kinds of entities in the United States
+        on the basis of political geography, that is, a hierarchy of
+        <entity-name>.<locality>.<state-code>.US.  For example,
+        "IBM.Armonk.NY.US".  In addition, branches of the US domain are
+        provided within each state for schools (K12), community colleges
+        (CC), technical schools (TEC), state government agencies
+        (STATE), councils of governments (COG),libraries (LIB), museums
+        (MUS), and several other generic types of entities (see RFC 1480
+        for details [1]).
+
+   To find a contact for a TLD use the "whois" program to access the
+   database on the host rs.internic.net.  Append "-dom" to the name of
+   TLD you are interested in.  For example:
+
+                       whois -h rs.internic.net us-dom
+      or
+                       whois -h rs.internic.net edu-dom
+
+3.  The Administration of Delegated Domains
+
+   The Internet Assigned Numbers Authority (IANA) is responsible for the
+   overall coordination and management of the Domain Name System (DNS),
+   and especially the delegation of portions of the name space called
+   top-level domains.  Most of these top-level domains are two-letter
+   country codes taken from the ISO standard 3166.
+
+   A central Internet Registry (IR) has been selected and designated to
+   handled the bulk of the day-to-day administration of the Domain Name
+   System.  Applications for new top-level domains (for example, country
+   code domains) are handled by the IR with consultation with the IANA.
+   The central IR is INTERNIC.NET.  Second level domains in COM, EDU,
+   ORG, NET, and GOV are registered by the Internet Registry at the
+   InterNIC.  The second level domains in the MIL are registered by the
+   DDN registry at NIC.DDN.MIL.  Second level names in INT are
+   registered by the PVM at ISI.EDU.
+
+   While all requests for new top-level domains must be sent to the
+   Internic (at hostmaster@internic.net), the regional registries are
+   often enlisted to assist in the administration of the DNS, especially
+   in solving problems with a country administration.  Currently, the
+   RIPE NCC is the regional registry for Europe and the APNIC is the
+
+
+
+Postel                                                          [Page 3]
+
+RFC 1591      Domain Name System Structure and Delegation     March 1994
+
+
+   regional registry for the Asia-Pacific region, while the INTERNIC
+   administers the North America region, and all the as yet undelegated
+   regions.
+
+      The contact mailboxes for these regional registries are:
+
+         INTERNIC        hostmaster@internic.net
+         APNIC           hostmaster@apnic.net
+         RIPE NCC        ncc@ripe.net
+
+   The policy concerns involved when a new top-level domain is
+   established are described in the following.  Also mentioned are
+   concerns raised when it is necessary to change the delegation of an
+   established domain from one party to another.
+
+   A new top-level domain is usually created and its management
+   delegated to a "designated manager" all at once.
+
+   Most of these same concerns are relevant when a sub-domain is
+   delegated and in general the principles described here apply
+   recursively to all delegations of the Internet DNS name space.
+
+   The major concern in selecting a designated manager for a domain is
+   that it be able to carry out the necessary responsibilities, and have
+   the ability to do a equitable, just, honest, and competent job.
+
+   1) The key requirement is that for each domain there be a designated
+      manager for supervising that domain's name space.  In the case of
+      top-level domains that are country codes this means that there is
+      a manager that supervises the domain names and operates the domain
+      name system in that country.
+
+      The manager must, of course, be on the Internet.  There must be
+      Internet Protocol (IP) connectivity to the nameservers and email
+      connectivity to the management and staff of the manager.
+
+      There must be an administrative contact and a technical contact
+      for each domain.  For top-level domains that are country codes at
+      least the administrative contact must reside in the country
+      involved.
+
+   2) These designated authorities are trustees for the delegated
+      domain, and have a duty to serve the community.
+
+      The designated manager is the trustee of the top-level domain for
+      both the nation, in the case of a country code, and the global
+      Internet community.
+
+
+
+
+Postel                                                          [Page 4]
+
+RFC 1591      Domain Name System Structure and Delegation     March 1994
+
+
+      Concerns about "rights" and "ownership" of domains are
+      inappropriate.  It is appropriate to be concerned about
+      "responsibilities" and "service" to the community.
+
+   3) The designated manager must be equitable to all groups in the
+      domain that request domain names.
+
+      This means that the same rules are applied to all requests, all
+      requests must be processed in a non-discriminatory fashion, and
+      academic and commercial (and other) users are treated on an equal
+      basis.  No bias shall be shown regarding requests that may come
+      from customers of some other business related to the manager --
+      e.g., no preferential service for customers of a particular data
+      network provider.  There can be no requirement that a particular
+      mail system (or other application), protocol, or product be used.
+
+      There are no requirements on subdomains of top-level domains
+      beyond the requirements on higher-level domains themselves.  That
+      is, the requirements in this memo are applied recursively.  In
+      particular, all subdomains shall be allowed to operate their own
+      domain name servers, providing in them whatever information the
+      subdomain manager sees fit (as long as it is true and correct).
+
+   4) Significantly interested parties in the domain should agree that
+      the designated manager is the appropriate party.
+
+      The IANA tries to have any contending parties reach agreement
+      among themselves, and generally takes no action to change things
+      unless all the contending parties agree; only in cases where the
+      designated manager has substantially mis-behaved would the IANA
+      step in.
+
+      However, it is also appropriate for interested parties to have
+      some voice in selecting the designated manager.
+
+      There are two cases where the IANA and the central IR may
+      establish a new top-level domain and delegate only a portion of
+      it: (1) there are contending parties that cannot agree, or (2) the
+      applying party may not be able to represent or serve the whole
+      country.  The later case sometimes arises when a party outside a
+      country is trying to be helpful in getting networking started in a
+      country -- this is sometimes called a "proxy" DNS service.
+
+      The Internet DNS Names Review Board (IDNB), a committee
+      established by the IANA, will act as a review panel for cases in
+      which the parties can not reach agreement among themselves.  The
+      IDNB's decisions will be binding.
+
+
+
+
+Postel                                                          [Page 5]
+
+RFC 1591      Domain Name System Structure and Delegation     March 1994
+
+
+   5) The designated manager must do a satisfactory job of operating the
+      DNS service for the domain.
+
+      That is, the actual management of the assigning of domain names,
+      delegating subdomains and operating nameservers must be done with
+      technical competence.  This includes keeping the central IR (in
+      the case of top-level domains) or other higher-level domain
+      manager advised of the status of the domain, responding to
+      requests in a timely manner, and operating the database with
+      accuracy, robustness, and resilience.
+
+      There must be a primary and a secondary nameserver that have IP
+      connectivity to the Internet and can be easily checked for
+      operational status and database accuracy by the IR and the IANA.
+
+      In cases when there are persistent problems with the proper
+      operation of a domain, the delegation may be revoked, and possibly
+      delegated to another designated manager.
+
+   6) For any transfer of the designated manager trusteeship from one
+      organization to another, the higher-level domain manager (the IANA
+      in the case of top-level domains) must receive communications from
+      both the old organization and the new organization that assure the
+      IANA that the transfer in mutually agreed, and that the new
+      organization understands its responsibilities.
+
+      It is also very helpful for the IANA to receive communications
+      from other parties that may be concerned or affected by the
+      transfer.
+
+4. Rights to Names
+
+   1) Names and Trademarks
+
+      In case of a dispute between domain name registrants as to the
+      rights to a particular name, the registration authority shall have
+      no role or responsibility other than to provide the contact
+      information to both parties.
+
+      The registration of a domain name does not have any Trademark
+      status.  It is up to the requestor to be sure he is not violating
+      anyone else's Trademark.
+
+   2) Country Codes
+
+      The IANA is not in the business of deciding what is and what is
+      not a country.
+
+
+
+
+Postel                                                          [Page 6]
+
+RFC 1591      Domain Name System Structure and Delegation     March 1994
+
+
+      The selection of the ISO 3166 list as a basis for country code
+      top-level domain names was made with the knowledge that ISO has a
+      procedure for determining which entities should be and should not
+      be on that list.
+
+5. Security Considerations
+
+   Security issues are not discussed in this memo.
+
+6. Acknowledgements
+
+   Many people have made comments on draft version of these descriptions
+   and procedures.  Steve Goldstein and John Klensin have been
+   particularly helpful.
+
+7. Author's Address
+
+   Jon Postel
+   USC/Information Sciences Institute
+   4676 Admiralty Way
+   Marina del Rey, CA  90292
+
+   Phone: 310-822-1511
+   Fax:   310-823-6714
+   EMail: Postel@ISI.EDU
+
+7. References
+
+   [1] Cooper, A., and J. Postel, "The US Domain", RFC 1480,
+       USC/Information Sciences Institute, June 1993.
+
+   [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
+       USC/Information Sciences Institute, July 1992.
+
+   [3] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
+       13, RFC 1034, USC/Information Sciences Institute, November 1987.
+
+   [4] Mockapetris, P., "Domain Names - Implementation and
+       Specification", STD 13, RFC 1035, USC/Information Sciences
+       Institute, November 1987.
+
+   [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
+       974, CSNET CIC BBN, January 1986.
+
+   [7] Braden, R., Editor, "Requirements for Internet Hosts --
+       Application and Support", STD 3, RFC 1123, Internet Engineering
+       Task Force, October 1989.
+
+
+
+
+Postel                                                          [Page 7]
+
diff --git a/usr.sbin/named/doc/rfc/rfc1597 b/usr.sbin/named/doc/rfc/rfc1597
new file mode 100644
index 00000000000..a9d747c06c5
--- /dev/null
+++ b/usr.sbin/named/doc/rfc/rfc1597
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                        Y. Rekhter
+Request for Comments: 1597       T.J. Watson Research Center, IBM Corp.
+Category: Informational                                    B. Moskowitz
+                                                         Chrysler Corp.
+                                                          D. Karrenberg
+                                                               RIPE NCC
+                                                            G. de Groot
+                                                               RIPE NCC
+                                                             March 1994
+
+
+                Address Allocation for Private Internets
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+1. Introduction
+
+   This RFC describes methods to preserve IP address space by not
+   allocating globally unique IP addresses to hosts private to an
+   enterprise while still permitting full network layer connectivity
+   between all hosts inside an enterprise as well as between all public
+   hosts of different enterprises. The authors hope, that using these
+   methods, significant savings can be made on allocating IP address
+   space.
+
+   For the purposes of this memo, an enterprise is an entity
+   autonomously operating a network using TCP/IP and in particular
+   determining the addressing plan and address assignments within that
+   network.
+
+2. Motivation
+
+   With the proliferation of TCP/IP technology worldwide, including
+   outside the Internet itself, an increasing number of non-connected
+   enterprises use this technology and its addressing capabilities for
+   sole intra-enterprise communications, without any intention to ever
+   directly connect to other enterprises or the Internet itself.
+
+   The current practice is to assign globally unique addresses to all
+   hosts that use TCP/IP.  There is a growing concern that the finite IP
+   address space might become exhausted.  Therefore, the guidelines for
+   assigning IP address space have been tightened in recent years [1].
+   These rules are often more conservative than enterprises would like,
+   in order to implement and operate their networks.
+
+
+
+Rekhter, Moskowitz, Karrenberg & de Groot                       [Page 1]
+
+RFC 1597        Address Allocation for Private Internets      March 1994
+
+
+   Hosts within enterprises that use IP can be partitioned into three
+   categories:
+
+      - hosts that do not require access to hosts in other enterprises
+        or the Internet at large;
+
+      - hosts that need access to a limited set of outside services
+        (e.g., E-mail, FTP, netnews, remote login) which can be handled
+        by application layer gateways;
+
+      - hosts that need network layer access outside the enterprise
+        (provided via IP connectivity);
+
+      - hosts within the first category may use IP addresses that are
+        unambiguous within an enterprise, but may be ambiguous between
+        enterprises.
+
+   For many hosts in the second category an unrestricted external access
+   (provided via IP connectivity) may be unnecessary and even
+   undesirable for privacy/security reasons.  Just like hosts within the
+   first category, such hosts may use IP addresses that are unambiguous
+   within an enterprise, but may be ambiguous between enterprises.
+
+   Only hosts in the last category require IP addresses that are
+   globally unambiguous.
+
+   Many applications require connectivity only within one enterprise and
+   do not even need external connectivity for the majority of internal
+   hosts.  In larger enterprises it is often easy to identify a
+   substantial number of hosts using TCP/IP that do not need network
+   layer connectivity outside the enterprise.
+
+   Some examples, where external connectivity might not be required,
+   are:
+
+      - A large airport which has its arrival/departure displays
+        individually addressable via TCP/IP. It is very unlikely that
+        these displays need to be directly accessible from other
+         networks.
+
+      - Large organisations like banks and retail chains are switching
+        to TCP/IP for their internal communication.  Large numbers of
+        local workstations like cash registers, money machines, and
+        equipment at clerical positions rarely need to have such
+        connectivity.
+
+
+
+
+
+
+Rekhter, Moskowitz, Karrenberg & de Groot                       [Page 2]
+
+RFC 1597        Address Allocation for Private Internets      March 1994
+
+
+      - For security reasons, many enterprises use application layer
+        gateways (e.g., firewalls) to connect their internal network to
+        the Internet.  The internal network usually does not have direct
+        access to the Internet, thus only one or more firewall hosts are
+        visible from the Internet.  In this case, the internal network
+        can use non-unique IP numbers.
+
+      - If two enterprises communicate over their own private link,
+        usually only a very limited set of hosts is mutually reachable
+        from the other enterprise over this link. Only those hosts need
+        globally unique IP numbers.
+
+      - Interfaces of routers on an internal network usually do not
+        need to be directly accessible from outside the enterprise.
+
+3. Private Address Space
+
+   The Internet Assigned Numbers Authority (IANA) has reserved the
+   following three blocks of the IP address space for private networks:
+
+        10.0.0.0        -   10.255.255.255
+        172.16.0.0      -   172.31.255.255
+        192.168.0.0     -   192.168.255.255
+
+   We will refer to the first block as "24-bit block", the second as
+   "20-bit block, and to the third as "16-bit" block.  Note that the
+   first block is nothing but a single class A network number, while the
+   second block is a set of 16 contiguous class B network numbers, and
+   third block is a set of 255 contiguous class C network numbers.
+
+   An enterprise that decides to use IP addresses out of the address
+   space defined in this document can do so without any coordination
+   with IANA or an Internet registry.  The address space can thus be
+   used by many enterprises.  Addresses within this private address
+   space will only be unique within the enterprise.
+
+   As before, any enterprise that needs globally unique address space is
+   required to obtain such addresses from an Internet registry.  An
+   enterprise that requests IP addresses for its external connectivity
+   will never be assigned addresses from the blocks defined above.
+
+   In order to use private address space, an enterprise needs to
+   determine which hosts do not need to have network layer connectivity
+   outside the enterprise in the foreseeable future.  Such hosts will be
+   called private hosts, and will use the private address space defined
+   above.  Private hosts can communicate with all other hosts inside the
+   enterprise, both public and private.  However, they cannot have IP
+   connectivity to any external host.  While not having external network
+
+
+
+Rekhter, Moskowitz, Karrenberg & de Groot                       [Page 3]
+
+RFC 1597        Address Allocation for Private Internets      March 1994
+
+
+   layer connectivity private hosts can still have access to external
+   services via application layer relays.
+
+   All other hosts will be called public and will use globally unique
+   address space assigned by an Internet Registry.  Public hosts can
+   communicate with other hosts inside the enterprise both public and
+   private and can have IP connectivity to external public hosts.
+   Public hosts do not have connectivity to private hosts of other
+   enterprises.
+
+   Moving a host from private to public or vice versa involves a change
+   of IP address.
+
+   Because private addresses have no global meaning, routing information
+   about private networks shall not be propagated on inter-enterprise
+   links, and packets with private source or destination addresses
+   should not be forwarded across such links.  Routers in networks not
+   using private address space, especially those of Internet service
+   providers, are expected to be configured to reject (filter out)
+   routing information about private networks.  If such a router
+   receives such information the rejection shall not be treated as a
+   routing protocol error.
+
+   Indirect references to such addresses should be contained within the
+   enterprise.  Prominent examples of such references are DNS Resource
+   Records and other information referring to internal private
+   addresses.  In particular, Internet service providers should take
+   measures to prevent such leakage.
+
+4. Advantages and Disadvantages of Using Private Address Space
+
+   The obvious advantage of using private address space for the Internet
+   at large is to conserve the globally unique address space by not
+   using it where global uniqueness is not required.
+
+   Enterprises themselves also enjoy a number of benefits from their
+   usage of private address space: They gain a lot of flexibility in
+   network design by having more address space at their disposal than
+   they could obtain from the globally unique pool.  This enables
+   operationally and administratively convenient addressing schemes as
+   well as easier growth paths.
+
+   For a variety of reasons the Internet has already encountered
+   situations where an enterprise that has not between connected to the
+   Internet had used IP address space for its hosts without getting this
+   space assigned from the IANA.  In some cases this address space had
+   been already assigned to other enterprises.  When such an enterprise
+   later connects to the Internet, it could potentially create very
+
+
+
+Rekhter, Moskowitz, Karrenberg & de Groot                       [Page 4]
+
+RFC 1597        Address Allocation for Private Internets      March 1994
+
+
+   serious problems, as IP routing cannot provide correct operations in
+   presence of ambiguous addressing.  Using private address space
+   provides a safe choice for such enterprises, avoiding clashes once
+   outside connectivity is needed.
+
+   One could argue that the potential need for renumbering represents a
+   significant drawback of using the addresses out of the block
+   allocated for private internets.  However, we need to observe that
+   the need is only "potential", since many hosts may never move into
+   the third category, and an enterprise may never decide to
+   interconnect (at IP level) with another enterprise.
+
+   But even if renumbering has to happen, we have to observe that with
+   Classless Inter-Domain Routing (CIDR) an enterprise that is connected
+   to the Internet may be encouraged to renumber its public hosts, as it
+   changes its Network Service Providers.  Thus renumbering is likely to
+   happen more often in the future, regardless of whether an enterprise
+   does or does not use the addresses out of the block allocated for
+   private networks.  Tools to facilitate renumbering (e.g., DHCP) would
+   certainly make it less of a concern.
+
+   Also observe that the clear division of public and private hosts and
+   the resulting need to renumber makes uncontrolled outside
+   connectivity more difficult, so to some extend the need to renumber
+   could be viewed as an advantage.
+
+5. Operational Considerations
+
+   A recommended strategy is to design the private part of the network
+   first and use private address space for all internal links.  Then
+   plan public subnets at the locations needed and design the external
+   connectivity.
+
+   This design is not fixed permanently.  If a number of hosts require
+   to change status later this can be accomplished by renumbering only
+   the hosts involved and installing another physical subnet if
+   required.
+
+   If a suitable subnetting scheme can be designed and is supported by
+   the equipment concerned, it is advisable to use the 24-bit block of
+   private address space and make an addressing plan with a good growth
+   path.  If subnetting is a problem, the 16-bit class C block, which
+   consists of 255 contiguous class C network numbers, can be used.
+
+   Using multiple IP (sub)nets on the same physical medium has many
+   pitfalls. We recommend to avoid it unless the operational problems
+   are well understood and it is proven that all equipment supports this
+   properly.
+
+
+
+Rekhter, Moskowitz, Karrenberg & de Groot                       [Page 5]
+
+RFC 1597        Address Allocation for Private Internets      March 1994
+
+
+   Moving a single host between private and public status will involve a
+   change of address and in most cases physical connectivity.  In
+   locations where such changes can be foreseen (machine rooms etc.)  it
+   may be advisable to configure separate physical media for public and
+   private subnets to facilitate such changes.
+
+   Changing the status of all hosts on a whole (sub)network can be done
+   easily and without disruption for the enterprise network as a whole.
+   Consequently it is advisable to group hosts whose connectivity needs
+   might undergo similar changes in the future on their own subnets.
+
+   It is strongly recommended that routers which connect enterprises to
+   external networks are set up with appropriate packet and routing
+   filters at both ends of the link in order to prevent packet and
+   routing information leakage.  An enterprise should also filter any
+   private networks from inbound routing information in order to protect
+   itself from ambiguous routing situations which can occur if routes to
+   the private address space point outside the enterprise.
+
+   Groups of organisations which foresee a big need for mutual
+   communication can consider forming an enterprise by designing a
+   common addressing plan supported by the necessary organisational
+   arrangements like a registry.
+
+   If two sites of the same enterprise need to be connected using an
+   external service provider, they can consider using an IP tunnel to
+   prevent packet leaks form the private network.
+
+   A possible approach to avoid leaking of DNS RRs is to run two
+   nameservers, one external server authoritative for all globally
+   unique IP addresses of the enterprise and one internal nameserver
+   authoritative for all IP addresses of the enterprise, both public and
+   private.  In order to ensure consistency both these servers should be
+   configured from the same data of which the external nameserver only
+   receives a filtered version.
+
+   The resolvers on all internal hosts, both public and private, query
+   only the internal nameserver.  The external server resolves queries
+   from resolvers outside the enterprise and is linked into the global
+   DNS.  The internal server forwards all queries for information
+   outside the enterprise to the external nameserver, so all internal
+   hosts can access the global DNS.  This ensures that information about
+   private hosts does not reach resolvers and nameservers outside the
+   enterprise.
+
+
+
+
+
+
+
+Rekhter, Moskowitz, Karrenberg & de Groot                       [Page 6]
+
+RFC 1597        Address Allocation for Private Internets      March 1994
+
+
+6. References
+
+   [1] Gerich, E., "Guidelines for Management of IP Address Space", RFC
+       1466, Merit Network, Inc., May 1993.
+
+7. Security Considerations
+
+   While using private address space can improve security, it is not a
+   substitute for dedicated security measures.
+
+8. Conclusion
+
+   With the described scheme many large enterprises will need only a
+   relatively small block of addresses from the globally unique IP
+   address space.  The Internet at large benefits through conservation
+   of globally unique address space which will effectively lengthen the
+   lifetime of the IP address space. The enterprises benefit from the
+   increased flexibility provided by a relatively large private address
+   space.
+
+9. Acknowledgments
+
+   We would like to thank Tony Bates (RIPE NCC), Jordan Becker (ANS),
+   Hans-Werner Braun (SDSC), Ross Callon (Wellfleet), John Curran
+   (NEARNET), Vince Fuller (Barrnet), Tony Li (cisco Systems), Anne Lord
+   (RIPE NCC), Milo Medin (NSI), Marten Terpstra (RIPE NCC), and Geza
+   Turchanyi (RIPE NCC) for their review and constructive comments.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rekhter, Moskowitz, Karrenberg & de Groot                       [Page 7]
+
+RFC 1597        Address Allocation for Private Internets      March 1994
+
+
+10. Authors' Addresses
+
+   Yakov Rekhter
+   T.J. Watson Research Center, IBM Corp.
+   P.O. Box 218
+   Yorktown Heights, NY, 10598
+
+   Phone: +1 914 945 3896
+   Fax: +1 914 945 2141
+   EMail: yakov@watson.ibm.com
+
+
+   Robert G Moskowitz
+   Chrysler Corporation
+   CIMS: 424-73-00
+   25999 Lawrence Ave
+   Center Line, MI 48015
+
+   Phone: +1 810 758 8212
+   Fax: +1 810 758 8173
+   EMail: 3858921@mcimail.com
+
+
+   Daniel Karrenberg
+   RIPE Network Coordination Centre
+   Kruislaan 409
+   1098 SJ Amsterdam, the Netherlands
+
+   Phone: +31 20 592 5065
+   Fax: +31 20 592 5090
+   EMail: Daniel.Karrenberg@ripe.net
+
+
+   Geert Jan de Groot
+   RIPE Network Coordination Centre
+   Kruislaan 409
+   1098 SJ Amsterdam, the Netherlands
+
+   Phone: +31 20 592 5065
+   Fax: +31 20 592 5090
+   EMail: GeertJan.deGroot@ripe.net
+
+
+
+
+
+
+
+
+
+
+Rekhter, Moskowitz, Karrenberg & de Groot                       [Page 8]
+
diff --git a/usr.sbin/named/doc/rfc/rfc1627 b/usr.sbin/named/doc/rfc/rfc1627
new file mode 100644
index 00000000000..cbfc9fa244e
--- /dev/null
+++ b/usr.sbin/named/doc/rfc/rfc1627
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                            E. Lear
+Request for Comments: 1627                        Silicon Graphics, Inc.
+Category: Informational                                          E. Fair
+                                                    Apple Computer, Inc.
+                                                              D. Crocker
+                                                  Silicon Graphics, Inc.
+                                                              T. Kessler
+                                                  Sun Microsystems, Inc.
+                                                               July 1994
+
+
+                     Network 10 Considered Harmful
+                 (Some Practices Shouldn't be Codified)
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+SUMMARY
+
+   Re-use of Internet addresses for private IP networks is the topic of
+   the recent RFC 1597 [1].  It reserves a set of IP network numbers,
+   for (re-)use by any number of organizations, so long as those
+   networks are not routed outside any single, private IP network.  RFC
+   1597 departs from the basic architectural rule that IP addresses must
+   be globally unique, and it does so without having had the benefit of
+   the usual, public review and approval by the IETF or IAB.  This
+   document restates the arguments for maintaining a unique address
+   space.  Concerns for Internet architecture and operations, as well as
+   IETF procedure, are explored.
+
+INTRODUCTION
+
+   Growth in use of Internet technology and in attachments to the
+   Internet have taken us to the point that we now are in danger of
+   running out of unassigned IP network numbers.  Initially, numbers
+   were formally assigned only when a network was about to be attached
+   to the Internet.  This caused difficulties when initial use of IP
+   substantially preceded the decision and permission to attach to the
+   Internet.  In particular, re-numbering was painful.  The lesson that
+   we learned was that every IP address ought to be globally unique,
+   independent of its attachment to the Internet.  This makes it
+   possible for any two network entities to communicate, no matter where
+   either might be located.  This model is the result of a decades-long
+   evolution, through which the community realized how painful it can be
+   to convert a network of computers to use an assigned number after
+
+
+
+Lear, Fair, Crocker & Kessler                                   [Page 1]
+
+RFC 1627             Network 10 Considered Harmful             July 1994
+
+
+   using random or default addresses found on computers just out of the
+   box.  RFC 1597 abrogates this model without benefit of general IETF
+   community discussion and consensus, leaving policy and operational
+   questions unasked and unanswered.
+
+KEEP OUR EYES ON THE PRIZE:  AN ARCHITECTURAL GOAL AND VIOLATION
+
+   A common -- if not universal -- ideal for the future of IP is for
+   every system to be globally accessible, given the proper security
+   mechanisms.  Whether such systems comprise toasters, light switches,
+   utility power poles, field medical equipment, or the classic examples
+   of "computers", our current model of assignment is to ensure that
+   they can interoperate.
+
+   In order for such a model to work there must exist a globally unique
+   addressing system.  A common complaint throughout the community is
+   that the existing security in host software does not allow for every
+   (or even many) hosts in a corporate environment to have direct IP
+   access.  When this problem is addressed through proper privacy and
+   authentication standards, non-unique IP addresses will become a
+   bottleneck to easy deployment if the recommendations in RFC 1597 are
+   followed.
+
+   The IP version 4 (IPv4) address space will be exhausted.  The
+   question is simply:  when?
+
+   If we assert that all IP addresses must be unique globally, connected
+   or not, then we will run out of IP address space soon.
+
+   If we assert that only IP addresses used on the world-wide Internet
+   need to be globally unique, then we will run out of IP address space
+   later.
+
+   It is absolutely key to keep the Internet community's attention
+   focused on the efforts toward IP next generation (IPng), so that we
+   may transcend the limitations of IPv4.  RFC 1597 produces apparent
+   relief from IPv4 address space exhaustion by masking those networks
+   that are not connecting to the Internet, today.  However, this
+   apparent relief will likely produce two results: complacency on the
+   large part of the community that does not take the long term view,
+   and a very sudden IP address space exhaustion at some later date.
+
+   Prior to IPng deployment, it is important to preserve all the
+   semantics that make both the Internet and Internet technology so very
+   valuable for interoperability.  Apple Computer, IBM, and Motorola
+   could not collaborate as easily as they have to produce the PowerPC
+   without uniquely assigned IP addresses. The same can be said of the
+   Silicon Graphics merger with MIPS. There are many, many more examples
+
+
+
+Lear, Fair, Crocker & Kessler                                   [Page 2]
+
+RFC 1627             Network 10 Considered Harmful             July 1994
+
+
+   that can be cited.
+
+   It should be noted that a scheme similar to RFC 1597 can be
+   implemented at the time that we actually run out of assignable IPv4
+   address space; it simply requires that those organizations which have
+   been assigned addresses but are not yet connected to the Internet
+   return their addresses to IANA. It is important that the IAB (and
+   IANA as its agent) reassert their ownership of the IP address space
+   now, to preclude challenges to this type of reassignment.
+
+OPERATIONAL ISSUES
+
+RFC 1597 Implementations
+
+   Methods are needed to ensure that the remaining addresses are
+   allocated and used frugally.  Due to the current problems, Internet
+   service providers have made it increasingly difficult for
+   organizations to acquire public IP network numbers.  Private networks
+   have always had the option of using addresses not assigned to them by
+   appropriate authorities.  We do not know how many such networks
+   exist, because by their nature they do not interact with the global
+   Internet.  By using a random address, a company must take some care
+   to ensure it is able to route to the properly registered owner of
+   that network.
+
+   RFC 1597 proposes to solve the routing problem by assigning numbers
+   that will never be used outside of private environments.  Using such
+   standard numbers introduces a potential for clashes in another way.
+   If two private networks follow RFC 1597 and then later wish to
+   communicate with each other, one will have to renumber.  The same
+   problem occurs if a private network wishes to become public.  The
+   likely cost of renumbering is linear to the number of hosts on a
+   network.  Thus, a large company with 10,000 hosts on a network could
+   incur considerable expense if it either merged with another company
+   or joined the Internet in such a way as to allow all hosts to
+   directly access the outside network.
+
+   The probability of address clashes occurring over time approach 100%
+   with RFC 1597.  Picking a random network number reduces the chances
+   of having to renumber hosts, but introduces the routing problems
+   described above.  Best of all, retrieving assigned numbers from the
+   appropriate authority in the first place eliminates both existing and
+   potential address conflicts at the cost of using a part of the
+   address space.
+
+   Apple Computer once believed that none of its internal systems would
+   ever speak IP directly to the outside world, and as such, network
+   operations picked IP class A network 90 out of thin air to use.
+
+
+
+Lear, Fair, Crocker & Kessler                                   [Page 3]
+
+RFC 1627             Network 10 Considered Harmful             July 1994
+
+
+   Apple is only now recovering from this error, having renumbered some
+   5,000 hosts to provide them with "desktop" Internet access.  Unless
+   the Internet community reaffirms its commitment to a globally unique
+   address space, we condemn many thousands of organizations to similar
+   pain when they too attempt to answer the call of the global Internet.
+
+   Another timely example of problems caused by RFC 1597 is Sun's use of
+   Internet multicasting.  Sun selectively relays specific multicast
+   conferences.  This has the effect of making many hosts at Sun visible
+   to the Internet, even though they are not addressable via IP unicast
+   routing.  If they had non-global addresses this would not work at
+   all.  It is not possible to predict which machines need global
+   addresses in advance.  Silicon Graphics has a similar configuration,
+   as is likely for others, as well.
+
+   Some might argue that assigning numbers to use for private networks
+   will prevent accidental leaks from occurring through some sort of
+   convention a'la Martian packets.  While the proposal attempts to
+   create a standard for "private" address use, there is absolutely no
+   way to ensure that other addresses are not also used.
+
+   Hence, the "standard" becomes nothing but a misleading heuristic.  In
+   fact, it is essential that routers to the global Internet advertise
+   networks based only on explicit permission, rather than refusing to
+   advertise others based on implicit prohibition, as supported by the
+   policy formally created in RFC 1597.
+
+Security Issues
+
+   Administrators will have a hard time spotting unauthorized networks,
+   when their network has been breached (either intentionally or
+   unintentionally) because the other networks might have the same
+   numbers as those normally in the routing tables.  More over, an
+   inadvertent connection could possibly have a double whammy effect of
+   partitioning two operational networks.
+
+   It is worth emphasizing that IP providers should filter out all but
+   authorized networks.  Such a practice would not only prevent
+   accidents but also enhance the security of the Internet by reducing
+   the potential number of points of attack.
+
+   Internet multicasting adds a new dimension to security.  In some
+   cases it may possible to allow multicasting through firewalls that
+   completely restrict unicast routing.  Otherwise unconnected networks
+   might well need unique addresses, as illustrated in the example
+   above.
+
+
+
+
+
+Lear, Fair, Crocker & Kessler                                   [Page 4]
+
+RFC 1627             Network 10 Considered Harmful             July 1994
+
+
+Problems with Examples
+
+   RFC 1597 gives several examples of IP networks that need not have
+   globally unique address spaces.  Each of those cases is plausible,
+   but that does not make it legitimate to ENCOURAGE non-uniqueness of
+   the addresses.  In fact, it is equally plausible that globally unique
+   IP addresses will be required, for every one of the scenarios
+   described in RFC 1597:
+
+   - Airport displays are public information and multicasting beyond the
+     airport might be useful.
+
+   - An organization's machines which, today, do not need global
+     connectivity might need it tomorrow.  Further, merging
+     organizations creates havoc when the addresses collide.
+
+   - Current use of firewalls is an artifact of limitations in the
+     technology.  Let's fix the problem, not the symptom.
+
+   - Inter-organization private links do not generate benefit from being
+     any more correct in guessing which machines want to interact than
+     is true for general Internet access.
+
+   This is another point that warrants repetition: the belief that
+   administrators can predict which machines will need Internet access
+   is quite simply wrong.  We need to reduce or eliminate the penalties
+   associated with that error, in order to encourage as much Internet
+   connectivity as operational policies and technical security permit.
+   RFC 1597 works very much against this goal.
+
+Problems With "Advantages" And More Disadvantages
+
+   RFC 1597 claims that Classless Inter-Domain Routing (CIDR) will
+   require enterprises to renumber their networks.  In the general case,
+   this will only involve those networks that are routed outside of
+   enterprises.  Since RFC 1597 addresses private enterprise networks,
+   this argument does not apply.
+
+   The authors mention that DCHP-based tools [2] might help network
+   number transition.  However, it is observed that by and large such
+   tools are currently only "potential" in nature.
+
+   Additionally, with the onslaught of ISDN, slip, and PPP in host
+   implementations, the potential for a workstation to become a router
+   inadvertently has never been greater.  Use of a common set of
+   addresses for private networks virtually assures administrators of
+   having their networks partitioned, if they do not take care to
+   carefully control modem connections.
+
+
+
+Lear, Fair, Crocker & Kessler                                   [Page 5]
+
+RFC 1627             Network 10 Considered Harmful             July 1994
+
+
+   Finally, RFC 1597 implies that it may be simple to change a host's IP
+   address.  For a variety of reasons this may not be the case, and it
+   is not the norm today.  For example, a host may be well known within
+   a network.  It may have long standing services such as NFS, which
+   would cause problems for clients were its address changed.  A host
+   may have software licenses locked by IP address.  Thus, migrating a
+   host from private to global addressing may prove difficult.  At the
+   very least, one should be careful about addressing well known hosts.
+
+POLICY ISSUES
+
+IANA Has Overstepped Their Mandate
+
+   For many years, IANA has followed an assignment policy based on the
+   expectation of Internet connectivity for ALL assignees.  As such it
+   serves to encourage interconnectivity.  IANA assignment of the
+   network numbers listed in RFC 1597 serves to formally authorize
+   behavior contrary to this accepted practice.  Further, this change
+   was effected without benefit of community review and approval.
+
+   RFC 1597 specifies a new operational requirement explicitly: network
+   service providers must filter the IANA assigned network numbers
+   listed in RFC 1597 from their routing tables.  This address space
+   allocation is permanently removed from being used on the Internet.
+
+   As we read RFC 1601 [3], this action is not within the purview of
+   IANA, which should only be assigning numbers within the current
+   standards and axioms that underlie the Internet.  IP network numbers
+   are assigned uniquely under the assumption that they will be used on
+   the Internet at some future date.  Such assignments violate that
+   axiom, and constitute an architectural change to the Internet.  RFC
+   1602 [4] and RFC 1310 [5] also contain identical wording to this
+   effect in the section that describes IANA.
+
+   While RFC 1597 contains a view worthy of public debate, it is not
+   ready for formal authorization.  Hence, we strongly encourage IANA to
+   withdraw its IP address assignments documented by RFC 1597 forthwith.
+
+   The IAB should review the address assignment policies and procedures
+   that compose IANA's mandate, and reaffirm the commitment to a
+   globally unique IP address space.
+
+COMMENTS AND CONCLUSIONS
+
+   The Internet technology and service is predicated on a global address
+   space.  Members of the Internet community have already experienced
+   and understood the problems and pains associated with uncoordinated
+   private network number assignments.  In effect the proposal attempts
+
+
+
+Lear, Fair, Crocker & Kessler                                   [Page 6]
+
+RFC 1627             Network 10 Considered Harmful             July 1994
+
+
+   to codify uncoordinated behavior and alter the accepted Internet
+   addressing model.  Hence, it needs to be considered much more
+   thoroughly.
+
+   RFC 1597 gives the illusion of remedying a problem, by creating
+   formal structure to a long-standing informal practice.  In fact, the
+   structure distracts us from the need to solve these very real
+   problems and does not even provide substantive aid in the near-term.
+
+   In the past we have all dreaded the idea of having any part of the
+   address space re-used.  Numerous luminaries have both written and
+   spoke at length, explaining why it is we want direct connections from
+   one host to another.  Before straying from the current architectural
+   path, we as a community should revisit the reasoning behind the
+   preaching of unique addressing.  While RFC 1597 attempts to change
+   this model, its costs and limitations for enterprises can be
+   enormous, both in the short and long term.
+
+REFERENCES
+
+   [1]  Rekhter, Y., Moskowitz, B., Karrenberg, D., and G. de Groot,
+        "Address Allocation for Private Internets", T.J. Watson Research
+        Center, IBM Corp., Chrysler Corp., RIPE NCC, RFC 1597, March
+        1994.
+
+   [2]  Droms, R., "Dynamic Host Configuration Protocol", RFC 1541,
+        Bucknell University, October 1993.
+
+   [3]  Huitema, C., "Charter of the Internet Architecture Board (IAB)",
+        RFC 1601, IAB, March 1994.
+
+   [4]  Internet Architecture Board, Internet Engineering Steering
+        Group, "The Internet Standards Process -- Revision 2", IAB,
+        IESG, RFC 1602, March 1994.
+
+   [5]  Internet Activities Board, "The Internet Standards Process", RFC
+        1310, IAB, March 1992.
+
+   [6]  Internet Activities Board, "Summary of Internet Architecture
+        Discussion", Notes available from ISI, [ftp.isi.edu:
+        pub/IAB/IABmins.jan91Arch.txt], IAB, January 1991.
+
+SECURITY CONSIDERATIONS
+
+   See the section, "Security Issues".
+
+
+
+
+
+
+Lear, Fair, Crocker & Kessler                                   [Page 7]
+
+RFC 1627             Network 10 Considered Harmful             July 1994
+
+
+AUTHORS' ADDRESSES
+
+   Eliot Lear
+   Silicon Graphics, Inc.
+   2011 N. Shoreline Blvd.
+   Mountain View, CA
+   94043-1389
+
+   Phone: +1 415 390 2414
+   EMail: lear@sgi.com
+
+
+   Erik Fair
+   Apple Computer, Inc.
+   1 Infinite Loop
+   Cupertino, CA 95014
+
+   Phone: +1 408 974 1779
+   EMail: fair@apple.com
+
+
+   Dave Crocker
+   Silicon Graphics, Inc.
+   2011 N. Shoreline Blvd.
+   Mountain View, CA
+   94043-1389
+
+   Phone: +1 415 390 1804
+   EMail: dcrocker@sgi.com
+
+
+   Thomas Kessler
+   Sun Microsystems Inc.
+   Mail Stop MTV05-44
+   2550 Garcia Ave.
+   Mountain View, CA 94043
+
+   Phone: +1 415 336 3145
+   EMail: kessler@eng.sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+Lear, Fair, Crocker & Kessler                                   [Page 8]
+
diff --git a/usr.sbin/named/doc/rfc/rfc1637 b/usr.sbin/named/doc/rfc/rfc1637
new file mode 100644
index 00000000000..24f18b736ed
--- /dev/null
+++ b/usr.sbin/named/doc/rfc/rfc1637
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                         B. Manning
+Request for Comments: 1637                               Rice University
+Obsoletes: 1348                                               R. Colella
+Category: Experimental                                              NIST
+                                                               June 1994
+
+
+                       DNS NSAP Resource Records
+
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  This memo does not specify an Internet standard of any
+   kind.  Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Abstract
+
+   The Internet is moving towards the deployment of an OSI lower layers
+   infrastructure. This infrastructure comprises the connectionless
+   network protocol (CLNP) and supporting routing protocols. Also
+   required as part of this infrastructure is support in the Domain Name
+   System (DNS) for mapping between names and NSAP addresses.
+
+   This document defines the format of one new Resource Record (RR) for
+   the DNS for domain name-to-NSAP mapping. The RR may be used with any
+   NSAP address format. This document supercedes RFC 1348.
+
+   NSAP-to-name translation is accomplished through use of the PTR RR
+   (see STD 13, RFC 1035 for a description of the PTR RR). This paper
+   describes how PTR RRs are used to support this translation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Manning & Colella                                               [Page 1]
+
+RFC 1637                      DNS NSAP RRs                     June 1994
+
+
+1.  Introduction
+
+   The Internet is moving towards the deployment of an OSI lower layers
+   infrastructure. This infrastructure comprises the connectionless
+   network protocol (CLNP) [6] and supporting routing protocols. Also
+   required as part of this infrastructure is support in the Domain Name
+   System (DNS) [8] [9] for mapping between domain names and OSI Network
+   Service Access Point (NSAP) addresses [7] [Note: NSAP and NSAP
+   address are used interchangeably throughout this memo].
+
+   This document defines the format of one new Resource Record (RR) for
+   the DNS for domain name-to-NSAP mapping. The RR may be used with any
+   NSAP address format.
+
+   NSAP-to-name translation is accomplished through use of the PTR RR
+   (see RFC 1035 for a description of the PTR RR). This paper describes
+   how PTR RRs are used to support this translation.
+
+   This memo assumes that the reader is familiar with the DNS. Some
+   familiarity with NSAPs is useful; see [2] or [7] for additional
+   information.
+
+2.  Background
+
+   The reason for defining DNS mappings for NSAPs is to support CLNP in
+   the Internet. Debugging with CLNP ping and traceroute is becoming
+   more difficult with only numeric NSAPs as the scale of deployment
+   increases. Current debugging is supported by maintaining and
+   exchanging a configuration file with name/NSAP mappings similar in
+   function to hosts.txt. This suffers from the lack of a central
+   coordinator for this file and also from the perspective of scaling.
+   The former is the most serious short-term problem. Scaling of a
+   hosts.txt-like solution has well-known long-term scaling
+   difficiencies.
+
+   A second reason for this work is the proposal to use CLNP as an
+   alternative to IP: "TCP and UDP with Bigger Addresses (TUBA), A
+   Simple Proposal for Internet Addressing and Routing" [1]. For this to
+   be practical, the DNS must be capable of supporting CLNP addresses.
+
+3.  Scope
+
+   The methods defined in this paper are applicable to all NSAP formats.
+   This includes support for the notion of a custom-defined NSAP format
+   based on an AFI obtained by the IAB for use in the Internet.
+
+   As a point of reference, there is a distinction between registration
+   and publication of addresses. For IP addresses, the IANA is the root
+
+
+
+Manning & Colella                                               [Page 2]
+
+RFC 1637                      DNS NSAP RRs                     June 1994
+
+
+   registration authority and the DNS a publication method. For NSAPs,
+   addendum two of the network service definition, ISO8348/Ad2 [7] is
+   the root registration authority and this memo defines how the DNS is
+   used as a publication method.
+
+4.  Structure of NSAPs
+
+   NSAPs are hierarchically structured to allow distributed
+   administration and efficient routing. Distributed administration
+   permits subdelegated addressing authorities to, as allowed by the
+   delegator, further structure the portion of the NSAP space under
+   their delegated control.  Accomodating this distributed authority
+   requires that there be little or no a priori knowledge of the
+   structure of NSAPs built into DNS resolvers and servers.
+
+   For the purposes of this memo, NSAPs can be thought of as a tree of
+   identifiers. The root of the tree is ISO8348/Ad2 [7], and has as its
+   immediately registered subordinates the one-octet Authority and
+   Format Identifiers (AFIs) defined there. The size of subsequently-
+   defined fields depends on which branch of the tree is taken. The
+   depth of the tree varies according to the authority responsible for
+   defining subsequent fields.
+
+   An example is the authority under which U.S. GOSIP defines NSAPs [3].
+   Under the AFI of 47, NIST (National Institute of Standards and
+   Technology) obtained a value of 0005 (the AFI of 47 defines the next
+   field as being two octets consisting of four BCD digits from the
+   International Code Designator space [4]). NIST defined the subsequent
+   fields in [3], as shown in Figure 1. The field immediately following
+   0005 is a format identifier for the rest of the U.S. GOSIP NSAP
+   structure, with a hex value of 80. Following this is the three-octet
+   field, values for which are allocated to network operators; the
+   registration authority for this field is delegated to GSA (General
+   Services Administration).
+
+   The last octet of the NSAP is the NSelector (NSel). In practice, the
+   NSAP minus the NSel identifies the CLNP protocol machine on a given
+   system, and the NSel identifies the CLNP user. Since there can be
+   more than one CLNP user (meaning multiple NSel values for a given
+   "base" NSAP), the representation of the NSAP should be CLNP-user
+   independent. To achieve this, an NSel value of zero shall be used
+   with all NSAP values stored in the DNS. An NSAP with NSel=0
+   identifies the network layer itself. It is left to the application
+   retrieving the NSAP to determine the appropriate value to use in that
+   instance of communication.
+
+
+
+
+
+
+Manning & Colella                                               [Page 3]
+
+RFC 1637                      DNS NSAP RRs                     June 1994
+
+
+              |--------------|
+              | <-- IDP -->  |
+              |--------------|-------------------------------------|
+              | AFI |  IDI   |            <-- DSP -->              |
+              |-----|--------|-------------------------------------|
+              | 47  |  0005  | DFI | AA |Rsvd | RD |Area | ID |Sel |
+              |-----|--------|-----|----|-----|----|-----|----|----|
+       octets |  1  |   2    |  1  | 3  |  2  | 2  |  2  | 6  | 1  |
+              |-----|--------|-----|----|-----|----|-----|----|----|
+
+                    IDP    Initial Domain Part
+                    AFI    Authority and Format Identifier
+                    IDI    Initial Domain Identifier
+                    DSP    Domain Specific Part
+                    DFI    DSP Format Identifier
+                    AA     Administrative Authority
+                    Rsvd   Reserved
+                    RD     Routing Domain Identifier
+                    Area   Area Identifier
+                    ID     System Identifier
+                    SEL    NSAP Selector
+
+                  Figure 1: GOSIP Version 2 NSAP structure.
+
+
+   When CLNP is used to support TCP and UDP services, the NSel value
+   used is the appropriate IP PROTO value as registered with the IANA.
+   For "standard" OSI, the selection of NSel values is left as a matter
+   of local administration. Administrators of systems that support the
+   OSI transport protocol [5] in addition to TCP/UDP must select NSels
+   for use by OSI Transport that do not conflict with the IP PROTO
+   values.
+
+   In the NSAP RRs in Master Files and in the printed text in this memo,
+   NSAPs are often represented as a string of "."-separated hex values.
+   The values correspond to convenient divisions of the NSAP to make it
+   more readable. For example, the "."-separated fields might correspond
+   to the NSAP fields as defined by the appropriate authority (ISOC,
+   RARE, U.S. GOSIP, ANSI, etc.). The use of this notation is strictly
+   for readability. The "."s do not appear in DNS packets and DNS
+   servers can ignore them when reading Master Files. For example, a
+   printable representation of the first four fields of a U.S. GOSIP
+   NSAP might look like
+
+                             47.0005.80.005a00
+
+
+
+
+
+
+Manning & Colella                                               [Page 4]
+
+RFC 1637                      DNS NSAP RRs                     June 1994
+
+
+   and a full U.S. GOSIP NSAP might appear as
+
+             47.0005.80.005a00.0000.1000.0020.00800a123456.00.
+
+   Other NSAP formats have different lengths and different
+   administratively defined field widths to accomodate different
+   requirements. For more information on NSAP formats in use see RFC
+   1629 [2].
+
+5.  The NSAP RR
+
+   The NSAP RR is defined with mnemonic "NSAP" and TYPE code 22
+   (decimal) and is used to map from domain names to NSAPs. Name-to-NSAP
+   mapping in the DNS using the NSAP RR operates analogously to IP
+   address lookup. A query is generated by the resolver requesting an
+   NSAP RR for a provided domain name.
+
+   NSAP RRs conform to the top level RR format and semantics as defined
+   in Section 3.2.1 of RFC 1035.
+
+                                            1  1  1  1  1  1
+              0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+           |                                               |
+           /                                               /
+           /                        NAME                   /
+           |                                               |
+           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+           |                    TYPE = NSAP                |
+           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+           |                    CLASS = IN                 |
+           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+           |                        TTL                    |
+           |                                               |
+           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+           |                      RDLENGTH                 |
+           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+           /                       RDATA                   /
+           /                                               /
+           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   where:
+
+   *  NAME: an owner name, i.e., the name of the node to which this
+      resource record pertains.
+
+   *  TYPE: two octets containing the NSAP RR TYPE code of 22 (decimal).
+
+
+
+
+Manning & Colella                                               [Page 5]
+
+RFC 1637                      DNS NSAP RRs                     June 1994
+
+
+   *  CLASS: two octets containing the RR IN CLASS code of 1.
+
+   *  TTL: a 32 bit signed integer that specifies the time interval in
+      seconds that the resource record may be cached before the source
+      of the information should again be consulted. Zero values are
+      interpreted to mean that the RR can only be used for the
+      transaction in progress, and should not be cached. For example,
+      SOA records are always distributed with a zero TTL to prohibit
+      caching. Zero values can also be used for extremely volatile data.
+
+   *  RDLENGTH: an unsigned 16 bit integer that specifies the length in
+      octets of the RDATA field.
+
+   *  RDATA: a variable length string of octets containing the NSAP.
+      The value is the binary encoding of the NSAP as it would appear in
+      the CLNP source or destination address field. A typical example of
+      such an NSAP (in hex) is shown below. For this NSAP, RDLENGTH is
+      20 (decimal); "."s have been omitted to emphasize that they don't
+      appear in the DNS packets.
+
+                 39840f80005a0000000001e13708002010726e00
+
+5.1  Additional Section Processing
+
+   [The specification in this section is necessary for completeness in
+   describing name server support for TUBA. For the time being, name
+   servers participating in TUBA demonstrations MAY ELECT to implement
+   this behavior; it SHOULD NOT be the default behavior of name servers
+   because the IPng sweepstakes are still outstanding and further
+   consideration is required for truncation and other issues.]
+
+   RFC 1035 describes the additional section processing (ASP) required
+   when servers encounter NS records during query processing. From
+   Section 3.3.11, "NS RDATA format":
+
+      NS records cause both the usual additional section processing to
+      locate a type A record, and, when used in a referral, a special
+      search of the zone in which they reside for glue information.
+
+   For TUBA, identical ASP is required on type NSAP records to support
+   servers and resolvers that use CLNP, either because of preference or
+   because it is the only internetworking protocol available (i.e., in
+   the absense of IPv4). Thus, NS records cause ASP which locates a type
+   NSAP record in addition to a type A record. Both type A and NSAP
+   records should be returned, if available.
+
+
+
+
+
+
+Manning & Colella                                               [Page 6]
+
+RFC 1637                      DNS NSAP RRs                     June 1994
+
+
+6.  NSAP-to-name Mapping Using the PTR RR
+
+   The PTR RR is defined in RFC 1035. This RR is typically used under
+   the "IN-ADDR.ARPA" domain to map from IPv4 addresses to domain names.
+
+   Similarly, the PTR RR is used to map from NSAPs to domain names under
+   the "NSAP.INT" domain. A domain name is generated from the NSAP
+   according to the rules described below. A query is sent by the
+   resolver requesting a PTR RR for the provided domain name.
+
+   A domain name is generated from an NSAP by reversing the hex nibbles
+   of the NSAP, treating each nibble as a separate subdomain, and
+   appending the top-level subdomain name "NSAP.INT" to it. For example,
+   the domain name used in the reverse lookup for the NSAP
+
+             47.0005.80.005a00.0000.0001.e133.ffffff000162.00
+
+   would appear as
+
+     0.0.2.6.1.0.0.0.f.f.f.f.f.f.3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0. \
+                         0.8.5.0.0.0.7.4.NSAP.INT.
+
+   [Implementation note: For sanity's sake user interfaces should be
+   designed to allow users to enter NSAPs using their natural order,
+   i.e., as they are typically written on paper. Also, arbitrary "."s
+   should be allowed (and ignored) on input.]
+
+7.  Master File Format
+
+   The format of NSAP RRs (and NSAP-related PTR RRs) in Master Files
+   conforms to Section 5, "Master Files," of RFC 1035. Below are
+   examples of the use of these RRs in Master Files to support name-to-
+   NSAP and NSAP-to-name mapping.
+
+   The NSAP RR introduces a new hex string format for the RDATA field.
+   The format is "0x" (i.e., a zero followed by an 'x' character)
+   followed by a variable length string of hex characters (0 to 9, a to
+   f). The hex string is case-insensitive. "."s (i.e., periods) may be
+   inserted in the hex string anywhere after the "0x" for readability.
+   The "."s have no significance other than for readability and are not
+   propagated in the protocol (e.g., queries or zone transfers).
+
+
+
+
+
+
+
+
+
+
+Manning & Colella                                               [Page 7]
+
+RFC 1637                      DNS NSAP RRs                     June 1994
+
+
+   ;;;;;;
+   ;;;;;; Master File for domain nsap.nist.gov.
+   ;;;;;;
+
+
+   @      IN     SOA    emu.ncsl.nist.gov.  root.emu.ncsl.nist.gov. (
+                                     1994041800   ; Serial  - date
+                                     1800         ; Refresh - 30 minutes
+                                     300          ; Retry   - 5 minutes
+                                     604800       ; Expire  - 7 days
+                                     3600 )       ; Minimum - 1 hour
+          IN     NS     emu.ncsl.nist.gov.
+          IN     NS     tuba.nsap.lanl.gov.
+   ;
+   ;
+   $ORIGIN nsap.nist.gov.
+   ;
+   ;     hosts
+   ;
+   bsdi1    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000161.00
+            IN  A      129.6.224.161
+            IN  HINFO PC_486    BSDi1.1(TUBA)
+   ;
+   bsdi2    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000162.00
+            IN  A      129.6.224.162
+            IN  HINFO PC_486    BSDi1.1(TUBA)
+   ;
+   cursive  IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000171.00
+            IN  A      129.6.224.171
+            IN  HINFO PC_386    DOS_5.0/NCSA_Telnet(TUBA)
+   ;
+   infidel  IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000164.00
+            IN  A      129.6.55.164
+            IN  HINFO PC/486    BSDi1.0(TUBA)
+   ;
+   ;     routers
+   ;
+   cisco1   IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.aaaaaa000151.00
+            IN  A      129.6.224.151
+            IN  A      129.6.225.151
+            IN  A      129.6.229.151
+   ;
+   3com1    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.aaaaaa000111.00
+            IN  A      129.6.224.111
+            IN  A      129.6.225.111
+            IN  A      129.6.228.111
+
+
+
+
+
+Manning & Colella                                               [Page 8]
+
+RFC 1637                      DNS NSAP RRs                     June 1994
+
+
+   ;;;;;;
+   ;;;;;; Master File for reverse mapping of NSAPs under the
+   ;;;;;;     NSAP prefix:
+   ;;;;;;
+   ;;;;;;          47.0005.80.005a00.0000.0001.e133
+   ;;;;;;
+
+
+   @      IN     SOA    emu.ncsl.nist.gov.  root.emu.ncsl.nist.gov. (
+                                     1994041800   ; Serial  - date
+                                     1800         ; Refresh - 30 minutes
+                                     300          ; Retry   - 5 minutes
+                                     604800       ; Expire  - 7 days
+                                     3600 )       ; Minimum - 1 hour
+          IN     NS     emu.ncsl.nist.gov.
+          IN     NS     tuba.nsap.lanl.gov.
+   ;
+   ;
+   $ORIGIN 3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0.0.8.5.0.0.0.7.4.NSAP.INT.
+   ;
+   0.0.1.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  bsdi1.nsap.nist.gov.
+   ;
+   0.0.2.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  bsdi2.nsap.nist.gov.
+   ;
+   0.0.1.7.1.0.0.0.f.f.f.f.f.f  IN    PTR  cursive.nsap.nist.gov.
+   ;
+   0.0.4.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  infidel.nsap.nist.gov.
+   ;
+   0.0.1.5.1.0.0.0.a.a.a.a.a.a  IN    PTR  cisco1.nsap.nist.gov.
+   ;
+   0.0.1.1.1.0.0.0.a.a.a.a.a.a  IN    PTR  3com1.nsap.nist.gov.
+
+8.  Security Considerations
+
+   Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Manning & Colella                                               [Page 9]
+
+RFC 1637                      DNS NSAP RRs                     June 1994
+
+
+9.  Authors' Addresses
+
+   Bill Manning
+   Rice University -- ONCS
+   P.O. Box 1892
+   6100 South Main
+   Houston, Texas 77251-1892
+   USA
+
+   Phone: +1.713.285.5415
+   EMail: bmanning@rice.edu
+
+
+   Richard Colella
+   National Institute of Standards and Technology
+   Technology/B217
+   Gaithersburg, MD 20899
+   USA
+
+   Phone: +1 301-975-3627
+   Fax: +1 301 590-0932
+   EMail: colella@nist.gov
+
+10.  References
+
+   [1] Callon R., "TCP and UDP with Bigger Addresses (TUBA), A Simple
+       Proposal for Internet Addressing and Routing", RFC 1347, DEC,
+       June 1992.
+
+   [2] Colella, R., Gardner, E., Callon, R., and Y. Rekhter, "Guidelines
+       for OSI NSAP Allocation inh the Internet", RFC 1629, NIST,
+       Wellfleet, Mitre, T.J. Watson Research Center, IBM Corp., May
+       1994.
+
+   [3] GOSIP Advanced Requirements Group.  Government Open Systems
+       Interconnection Profile (GOSIP) Version 2. Federal Information
+       Processing Standard 146-1, U.S. Department of Commerce, National
+       Institute of Standards and Technology, Gaithersburg, MD, April
+       1991.
+
+   [4] ISO/IEC.  Data interchange - structures for the identification of
+       organization.  International Standard 6523, ISO/IEC JTC 1,
+       Switzerland, 1984.
+
+   [5] ISO/IEC. Connection oriented transport protocol specification.
+       International Standard 8073, ISO/IEC JTC 1, Switzerland, 1986.
+
+
+
+
+
+Manning & Colella                                              [Page 10]
+
+RFC 1637                      DNS NSAP RRs                     June 1994
+
+
+   [6] ISO/IEC.  Protocol for Providing the Connectionless-mode Network
+       Service.  International Standard 8473, ISO/IEC JTC 1,
+       Switzerland, 1986.
+
+   [7] ISO/IEC. Information Processing Systems -- Data Communications --
+       Network Service Definition Addendum 2: Network Layer Addressing.
+       International Standard 8348/Addendum 2, ISO/IEC JTC 1,
+       Switzerland, 1988.
+
+   [8] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
+       13, RFC 1034, USC/Information Sciences Institute, November 1987.
+
+   [9] Mockapetris, P., "Domain Names -- Implementation and
+       Specification", STD 13, RFC 1035, USC/Information Sciences
+       Institute, November 1987.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Manning & Colella                                              [Page 11]
+
diff --git a/usr.sbin/named/doc/rfc/rfc1713 b/usr.sbin/named/doc/rfc/rfc1713
new file mode 100644
index 00000000000..7562454e615
--- /dev/null
+++ b/usr.sbin/named/doc/rfc/rfc1713
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group                                           A. Romao
+Request for Comments: 1713                                          FCCN
+FYI: 27                                                    November 1994
+Category: Informational
+
+
+                        Tools for DNS debugging
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   Although widely used (and most of the times unnoticed), DNS (Domain
+   Name System) is too much overlooked, in the sense that people,
+   especially administrators, tend to ignore possible anomalies as long
+   as applications that need name-to-address mapping continue to work.
+   This document presents some tools available for domain administrators
+   to detect and correct those anomalies.
+
+1. Introduction
+
+   Today more than 3,800,000 computers are inter-connected in a global
+   Internet [1], comprising several millions of end-users, able to reach
+   any of those machines just by naming it.  This facility is possible
+   thanks to the world widest distributed database, the Domain Name
+   System, used to provide distributed applications various services,
+   the most notable one being translating names into IP addresses and
+   vice-versa.  This happens when you do an FTP or Telnet, when your
+   gopher client follows a link to some remote server, when you click on
+   a hypertext item and have to reach a server as defined by the URL,
+   when you talk to someuser@some.host, when your mail has to be routed
+   through a set to gateways before it reaches the final recipient, when
+   you post an article to Usenet and want it propagated all over the
+   world.  While these may be the most visible uses of DNS, a lot more
+   applications rely on this system to operate, e.g., network security,
+   monitoring and accounting tools, just to mention a few.
+
+   DNS owes much of its success to its distributed administration.  Each
+   component (called a zone, the same as a domain in most cases), is
+   seen as an independent entity, being responsible for what happens
+   inside its domain of authority, how and what information changes and
+   for letting the tree grow downwards, creating new components.
+
+
+
+
+
+Romao                                                           [Page 1]
+
+RFC 1713                Tools for DNS debugging            November 1994
+
+
+   On the other hand, many inconsistencies arise from this distributed
+   nature: many administrators make mistakes in the way they configure
+   their domains and when they delegate authority to sub-domains; many
+   of them don't even know how to do these things properly, letting
+   problems last and propagate.  Also, many problems occur due to bad
+   implementations of both DNS clients and servers, especially very old
+   ones, either by not following the standards or by being error prone,
+   creating or allowing many of the above problems to happen.
+
+   All these anomalies make DNS less efficient than it could be, causing
+   trouble to network operations, thus affecting the overall Internet.
+   This document tries to show how important it is to have DNS properly
+   managed, including what is already in place to help administrators
+   taking better care of their domains.
+
+2. DNS debugging
+
+   To help finding problems in DNS configurations and/or implementations
+   there is a set of tools developed specifically for this purpose.
+   There is probably a lot of people in charge of domain administration
+   having no idea of these tools (and, worse, not aware of the anomalies
+   that may exist in their configurations).  What follows is a
+   description of some of these programs, their scope, motivations and
+   availability, and is hoped to serve as an introduction to the subject
+   of DNS debugging, as well as a guide to those who are looking for
+   something to help them finding out how healthy their domains and
+   servers are.
+
+   Some prior knowledge from the reader is assumed, both on DNS basics
+   and some other tools (e.g., dig and nslookup), which are not analyzed
+   in detail here; hopefully they are well-known enough from daily
+   usage.
+
+2.1. Host
+
+   Host is a program used to retrieve DNS information from name servers.
+   This information may be used simply to get simple things like
+   address-to-name mapping, or some more advanced purposes, e.g.,
+   performing sanity checks on the data.  It was created at Rutgers
+   University, but then Eric Wassenaar from Nikhef did a major rewrite
+   and still seems to be actively working on improving it.  The program
+   is available from ftp://ftp.nikhef.nl/pub/network/host_YYMMDD.tar.Z
+   (YYMMDD is the date of the latest release).
+
+   By default, host just maps host names to Internet addresses, querying
+   the default servers or some specific one.  It is possible, though, to
+   get any kind of data (resource records) by specifying different query
+   types and classes and asking for verbose or debugging output, from
+
+
+
+Romao                                                           [Page 2]
+
+RFC 1713                Tools for DNS debugging            November 1994
+
+
+   any name server.  You can also control several parameters like
+   recursion, retry times, timeouts, use of virtual circuits vs.
+   datagrams, etc., when talking to name servers.  This way you can
+   simulate a resolver behavior, in order to find any problems
+   associated with resolver operations (which is to say, any application
+   using the resolver library).  As a query program it may be as
+   powerful as others like nslookup or dig.
+
+   As a debugger, host analyzes some set of the DNS space (e.g., an
+   entire zone) and produces reports with the results of its operation.
+   To do this, host first performs a zone transfer, which may be
+   recursive, getting information from a zone and all its sub-zones.
+   This data is then analyzed as requested by the arguments given on the
+   command line.  Note that zone transfers are done by contacting
+   authoritative name servers for that zone, so it must be possible to
+   make this kind of request from such servers: some of them refuse zone
+   transfers (except from secondaries) to avoid congestion.
+
+   With host you may look for anomalies like those concerning authority
+   (e.g., lame delegations, described below) or some more exotic cases
+   like extrazone hosts (a host of the form host.some.dom.ain, where
+   some.dom.ain is not a delegated zone of dom.ain).  These errors are
+   produced upon explicit request on the command line, but you may get a
+   variety of other error messages as a result of host's operations,
+   something like secondary effects.  These may be mere warnings (which
+   may be suppressed) or serious errors - in fact, warning messages are
+   not that simple, most of them are due to misconfigured zones, so it
+   might not be a good idea to just ignore them.
+
+   Error messages have to do with serious anomalies, either with the
+   packets exchanged with the queried servers (size errors, invalid
+   ancounts, nscounts and the like), or others related to the DNS
+   information itself (also called "status messages" in the program's
+   documentation): inconsistencies between SOA records as shown by
+   different servers for a domain, unexpected address-to-name mappings,
+   name servers not responding, not reachable, not running or not
+   existing at all, and so on.
+
+   Host performs all its querying on-line, i.e., it only works with data
+   received from name servers, which means you have to query a name
+   server more than once if you want to get different kinds of reports
+   on some particular piece of data.  You can always arrange arguments
+   in such a way that you get all information you want by running it
+   once, but if you forget something or for any reason have to run it
+   again, this means extra zone transfers, extra load on name servers,
+   extra DNS traffic.
+
+
+
+
+
+Romao                                                           [Page 3]
+
+RFC 1713                Tools for DNS debugging            November 1994
+
+
+   Host is an excellent tool, if used carefully.  Like most other
+   querying programs it may generate lots of traffic, just by issuing a
+   simple command.  Apart from that, its resolver simulation and debug
+   capabilities make it useful to find many common and some not so
+   common DNS configuration errors, as well as generate useful reports
+   and statistics about the DNS tree.  As an example, RIPE (Reseaux IP
+   Europeens) NCC uses it to generate a monthly european hostcount,
+   giving an overview of the Internet usage evolution in Europe.  Along
+   with these counts, error reports are generated, one per country, and
+   the whole information is made available in the RIPE archive.
+
+2.2. Dnswalk
+
+   Dnswalk is a DNS debugger written in Perl by David Barr, from
+   Pennsylvania State University.  You'll find the latest version at
+   ftp://ftp.pop.psu.edu/pub/src/dnswalk.  With the software comes a
+   small document where the author points some useful advice so it may
+   be worth reading it.
+
+   The program checks domain configurations stored locally, with data
+   arranged hierarchically in directories, resembling the DNS tree
+   organization of domains.  To set up this information dnswalk may
+   first perform zone transfers from authoritative name servers. You can
+   have a recursive transfer of a domain and its sub-domains, though you
+   should be careful when doing this, as it may generate a great amount
+   of traffic.  If the data is already present, dnswalk may skip these
+   transfers, provided that it is up to date.
+
+   Dnswalk looks for inconsistencies in resource records, such as MX and
+   aliases pointing to aliases or to unknown hosts, incoherent PTR, A
+   and CNAME records, invalid characters in names, missing trailing
+   dots, unnecessary glue information, and so on.  It also does some
+   checking on authority information, namely lame delegations and
+   domains with only one name server.  It is easy to use, you only have
+   to specify the domain to analyze and some optional parameters and the
+   program does the rest.  Only one domain (and its sub-domains, if
+   that's the case) can be checked at a time, though.
+
+   While in the process of checking data, dnswalk uses dig and resolver
+   routines (gethostbyXXXX from the Perl library) a lot, to get such
+   data as authority information from the servers of the analyzed
+   domains, names from IP addresses so as to verify the existence of PTR
+   records, aliases and so on.  So, besides the zone transfers you may
+   count on some more extra traffic (maybe not negligible if you are
+   debugging a relatively large amount of data and care about query
+   retries and timeouts), just by running the program.
+
+
+
+
+
+Romao                                                           [Page 4]
+
+RFC 1713                Tools for DNS debugging            November 1994
+
+
+2.3. Lamers
+
+   A lame delegation is a serious error in DNS configurations, yet a
+   (too) common one.  It happens when a name server is listed in the NS
+   records for some domain and in fact it is not a server for that
+   domain.  Queries are thus sent to the wrong servers, who don't know
+   nothing (at least not as expected) about the queried domain.
+   Furthermore, sometimes these hosts (if they exist!) don't even run
+   name servers.  As a result, queries are timed out and resent, only to
+   fail, thus creating (more) unnecessary traffic.
+
+   It's easy to create a lame delegation: the most common case happens
+   when an administrator changes the NS list for his domain, dropping
+   one or more servers from that list, without informing his parent
+   domain administration, who delegated him authority over the domain.
+   From now on the parent name server announces one or more servers for
+   the domain, which will receive queries for something they don't know
+   about.  (On the other hand, servers may be added to the list without
+   the parent's servers knowing, thus hiding valuable information from
+   them - this is not a lame delegation, but shouldn't happen either.)
+   Other examples are the inclusion of a name in an NS list without
+   telling the administrator of that host, or when a server suddenly
+   stops providing name service for a domain.
+
+   To detect and warn DNS administrators all over the world about this
+   kind of problem, Bryan Beecher from University of Michigan wrote
+   lamers, a program to analyze named (the well-known BIND name server)
+   logging information [2].  To produce useful logs, named was applied a
+   patch to detect and log lame delegations (this patch was originally
+   written by Don Lewis from Silicon Systems and is now part of the
+   latest release of BIND thanks to Bryan Beecher, so it is expected to
+   be widely available in the near future).  Lamers is a small shell
+   script that simply scans these logs and reports the lame delegations
+   found.  This reporting is done by sending mail to the hostmasters of
+   the affected domains, as stated in the SOA record for each of them.
+   If this is not possible, the message is sent to the affected name
+   servers' postmasters instead.  Manual processing is needed in case of
+   bounces, caused by careless setup of those records or invalid
+   postmaster addresses.  A report of the errors found by the U-M
+   servers is also posted twice a month on the USENET newsgroup
+   comp.protocols.tcp-ip.domains.
+
+   If you ever receive such a report, you should study it carefully in
+   order to find and correct problems in your domain, or see if your
+   servers are being affected by the spreading of erroneous information.
+   Better yet, lamers could be run on your servers to detect more lame
+   delegations (U-M can't see them all!).  Also, if you receive mail
+   reporting a lame delegation affecting your domain or some of your
+
+
+
+Romao                                                           [Page 5]
+
+RFC 1713                Tools for DNS debugging            November 1994
+
+
+   hosts, please don't just ignore it or flame the senders.  They're
+   really trying to help!
+
+   You can get lamers from ftp://terminator.cc.umich.edu/dns/lame-
+   delegations.
+
+2.4. DOC
+
+   Authority information is one of the most significant parts of the DNS
+   data, as the whole mechanism depends on it to correctly traverse the
+   domain tree.  Incorrect authority information leads to problems such
+   as lame delegations or even, in extreme cases, the inaccessibility of
+   a domain.  Take the case where the information given about all its
+   name servers is incorrect: being unable to contact the real servers
+   you may end up being unable to reach anything inside that domain.
+   This may be exaggerated, but if you're on the DNS business long
+   enough you've probably have seen some enlightened examples of this
+   scenario.
+
+   To look for this kind of problems Paul Mockapetris and Steve Hotz,
+   from the Information Sciences Institute, wrote a C-shell script
+   called DOC (Domain Obscenity Control), an automated domain testing
+   tool that uses dig to query the appropriate name servers about
+   authority for a domain and analyzes the responses.
+
+   DOC limits its analysis to authority data since the authors
+   anticipated that people would complain about such things as invasion
+   of privacy.  Also, at the time it was written most domains were so
+   messy that they thought there wouldn't be much point in checking
+   anything deeper until the basic problems weren't fixed.
+
+   Only one domain is analyzed each time: the program checks if all the
+   servers for the parent domain agree about the delegation information
+   for the domain.  DOC then picks a list of name servers for the domain
+   (obtained from one of the parent's servers) and starts checking on
+   their information, querying each of them: looks for the SOA record,
+   checks if the response is authoritative, compares the various records
+   retrieved, gets each one's list of NS, compares the lists (both among
+   these servers and the parent's), and for those servers inside the
+   domain the program looks for PTR records for them.
+
+   Due to several factors, DOC seems to have frozen since its first
+   public release, back in 1990.  Within the distribution there is an
+   RFC draft about automated domain testing, which was never published.
+   Nevertheless, it may provide useful reading.  The software can be
+   fetched from ftp://ftp.uu.net/networking/ip/dns/doc.2.0.tar.Z.
+
+
+
+
+
+Romao                                                           [Page 6]
+
+RFC 1713                Tools for DNS debugging            November 1994
+
+
+2.5. DDT
+
+   DDT (Domain Debug Tools) is a package of programs to scan DNS
+   information for error detection, developed originally by Jorge Frazao
+   from PUUG - Portuguese UNIX Users Group and later rewritten by the
+   author, at the time at the Faculty of Sciences of University of
+   Lisbon.  Each program is specialized in a given set of anomalies: you
+   have a checker for authority information, another for glue data, mail
+   exchangers, reverse-mappings and miscellaneous errors found in all
+   kinds of resource records.  As a whole, they do a rather extensive
+   checking on DNS configurations.
+
+   These tools work on cached DNS data, i.e., data stored locally after
+   performing zone transfers (presently done by a slightly modified
+   version of BIND's named-xfer, called ddt-xfer, which allows recursive
+   transfers) from the appropriate servers, rather than querying name
+   servers on-line each time they run.  This option was taken for
+   several reasons [3]: (1) efficiency, since it reads data from disk,
+   avoiding network transit delays, (2) reduced network traffic, data
+   has to be fetched only once and then run the programs over it as many
+   times as you wish and (3) accessibility - in countries with limited
+   Internet access, as was the case in Portugal by the time DDT was in
+   its first stages, this may be the only practical way to use the
+   tools.
+
+   Point (2) above deserves some special considerations: first, it is
+   not entirely true that there aren't additional queries while
+   processing the information, one of the tools, the authority checker,
+   queries (via dig) each domain's purported name servers in order to
+   test the consistency of the authority information they provide about
+   the domain.  Second, it may be argued that when the actual tests are
+   done the information used may be out of date.  While this is true,
+   you should note that this is the DNS nature, if you obtain some piece
+   of information you can't be sure that one second later it is still
+   valid.  Furthermore, if your source was not the primary for the
+   domain then you can't even be sure of the validity in the exact
+   moment you got it in the first place.  But experience shows that if
+   you see an error, it is likely to be there in the next version of the
+   domain information (and if it isn't, nothing was lost by having
+   detected it in the past).  On the other side, of course there's
+   little point in checking one month old data...
+
+   The list of errors looked for includes lame delegations, version
+   number mismatches between servers (this may be a transient problem),
+   non-existing servers, domains with only one server, unnecessary glue
+   information, MX records pointing to hosts not in the analyzed domain
+   (may not be an error, it's just to point possibly strange or
+   expensive mail-routing policies), MX records pointing to aliases, A
+
+
+
+Romao                                                           [Page 7]
+
+RFC 1713                Tools for DNS debugging            November 1994
+
+
+   records without the respective PTR and vice-versa, missing trailing
+   dots, hostnames with no data (A or CNAME records), aliases pointing
+   to aliases, and some more.  Given the specialized nature of each
+   tool, it is possible to look for a well defined set of errors,
+   instead of having the data analyzed in all possible ways.
+
+   Except for ddt-xfer, all the programs are written in Perl.  A new
+   release may come into existence in a near future, after a thorough
+   review of the methods used, the set of errors checked for and some
+   bug fixing (in particular, a Perl version of ddt-xfer is expected).
+   In the mean time, the latest version is available from
+   ftp://ns.dns.pt/pub/dns/ddt-2.0.1.tar.gz.
+
+2.6. The Checker Project
+
+   The problem of the huge amount of DNS traffic over the Internet is
+   getting researchers close attention for quite some time, mainly
+   because most of it is unnecessary.  Observations have shown that DNS
+   consumes something like twenty times more bandwidth than it should
+   [4].  Some causes for this undoubtedly catastrophic scenario lie on
+   deficient resolver and name server implementations spread all over
+   the world, from personal to super-computers, running all sorts of
+   operating systems.
+
+   While the panacea is yet to be found (claims are made that the latest
+   official version of BIND is a great step forward [5]), work has been
+   done in order to identify sources of anomalies, as a first approach
+   in the search for a solution.  The Checker Project is one such
+   effort, developed at the University of Southern California [6].  It
+   consists of a set of C code patched into BIND's named, for monitoring
+   server activity, building a database with the history of that
+   operation (queries and responses).  It is then possible to generate
+   reports from the database summarizing activity and identifying
+   behavioral patterns from client requests, looking for anomalies.  The
+   named code alteration is small and simple unless you want do have PEC
+   checking enabled (see below).  You may find sources and documentation
+   at ftp://catarina.usc.edu/pub/checker.
+
+   Checker only does this kind of collection and reporting, it does not
+   try to enforce any rules on the administrators of the defective sites
+   by any means whatsoever.  Authors hope that the simple exhibition of
+   the evidences is a reason strong enough for those administrators to
+   have their problems fixed.
+
+   An interesting feature is PEC (proactive error checking): the server
+   pretends to be unresponsive for some queries by randomly choosing
+   some name and start refusing replies for queries on that name during
+   a pre-determined period.  Those queries are recorded, though, to try
+
+
+
+Romao                                                           [Page 8]
+
+RFC 1713                Tools for DNS debugging            November 1994
+
+
+   to reason about the retry and timeout schemes used by name servers
+   and resolvers.  It is expected that properly implemented clients will
+   choose another name server to query, while defective ones will keep
+   on trying with the same server.  This feature seems to be still under
+   testing as it is not completely clear yet how to interpret the
+   results.  A PEC-only error checker is available from USC that is much
+   simpler than the full error checker.  It examines another name server
+   client every 30 minutes to see if this client causes excessive load.
+
+   Presently Checker has been running on a secondary for the US domain
+   for more than a year with little trouble.  Authors feel confident it
+   should run on any BSD platform (at least SunOS) without problems, and
+   is planned to be included as part of the BIND name server.
+
+   Checker is part of a research project lead by Peter Danzig from USC,
+   aimed to implement probabilistic error checking mechanisms like PEC
+   on distributed systems [7].  DNS is one such system and it was chosen
+   as the platform for testing the validity of these techniques over the
+   NSFnet.  It is hoped to achieve enough knowledge to provide means to
+   improve performance and reliability of distributed systems.
+   Anomalies like undetected server failures, query loops, bad
+   retransmission backoff algorithms, misconfigurations and resubmission
+   of requests after negative replies are some of the targets for these
+   checkers to detect.
+
+2.7. Others
+
+   All the tools described above are the result of systematic work on
+   the issue of DNS debugging, some of them included in research
+   projects.  For the sake of completeness several other programs are
+   mentioned here.  These, though just as serious, seem to have been
+   developed in a somewhat ad-hoc fashion, without an implicit intention
+   of being used outside the environments where they were born.  This
+   impression is, of course, arguable, nevertheless there was no
+   necessity of dedicating an entire section to any of them.  This
+   doesn't mean they are not valuable contributions, in some cases they
+   may be just what you are looking for, without having to install a
+   complete package to do some testings on your domain.
+
+   The reference taken was the contrib directory in the latest BIND
+   distribution (where some of the above programs can also be found).
+   There you will find tools for creating your DNS configuration files
+   and NIS maps from /etc/hosts and vice-versa or generate PTR from A
+   records (these things may be important as a means of avoiding common
+   typing errors and inconsistencies between those tables), syntax
+   checkers for zone files, programs for querying and monitoring name
+   servers, all the small programs presented in [8], and more.  It is
+   worth spending some time looking at them, maybe you'll find that
+
+
+
+Romao                                                           [Page 9]
+
+RFC 1713                Tools for DNS debugging            November 1994
+
+
+   program you were planning to write yourself.  The latest public
+   version of BIND can be found at
+   ftp://gatekeeper.dec.com/pub/misc/vixie/4.9.2-940221.tar.gz.  As of
+   this writing BIND-4.9.3 is in its final beta stages and a public
+   release is expected soon, also at gatekeeper.dec.com.
+
+   You may also want to consider using a version control system like
+   SCCS or RCS to maintain your configuration files consistent through
+   updates, or use tools like M4 macros to generate those files.  As
+   stated above, it's important to avoid human-generated errors,
+   creating problems that are difficult to track down, since they're
+   often hidden behind some mistyped name.  Errors like this may end up
+   in many queries for a non-existing name, just to mention the less
+   serious kind.  See [9] for a description of the most common errors
+   made while configuring domains.
+
+3. Why look after DNS?
+
+   Several pieces of software were presented to help people administer
+   and debug their name services.  They exhibit many differences in
+   their way of doing things, scope and requirements and it may be
+   difficult just to choose one of them to work with.  For one thing,
+   people's expectations from these tools vary according to their kind
+   of involvement with DNS.  If you are responsible for a big domain,
+   e.g., a top-level one or a big institution with many hosts and sub-
+   domains, you probably want to see how well is the tree below your
+   node organized, since the consequences of errors tend to propagate
+   upwards, thus affecting your own domain and servers.  For that you
+   need some program that recursively descends the domain tree and
+   analyzes each domain per se and the interdependencies between them
+   all.  You will have to consider how deep you want your analysis to
+   be, the effects it will have on the network infrastructure, i.e.,
+   will it generate traffic only inside a campus network, no matter how
+   big it is, or will it be spread over, say, a whole country (of
+   course, your kind of connectivity plays an important role here).
+
+   You may simply want to perform some sanity checks on your own domain,
+   without any further concerns.  Or you may want to participate in some
+   kind of global effort to monitor name server traffic, either for
+   research purposes or just to point out the "trouble-queries" that
+   flow around.
+
+   Whatever your interest may be, you can almost surely find a tool to
+   suit it.  Eliminating problems like those described in this document
+   is a major contribution for the efficiency of an important piece of
+   the Internet mechanism.  Just to have an idea of this importance,
+   think of all the applications that depend on it, not just to get
+   addresses out of names.  Many systems rely on DNS to store, retrieve
+
+
+
+Romao                                                          [Page 10]
+
+RFC 1713                Tools for DNS debugging            November 1994
+
+
+   and spread the information they need: Internet electronic mail was
+   already mentioned (see [10] for details) and work is in progress to
+   integrate X.400 operations with DNS [11]; others include "remote
+   printing" services [12], distributed file systems and network routing
+   purposes, among others.  These features may be accomplished by some
+   standard, well-known resource records [13], or by new, experimental
+   ones [14, 15].  Even if some of them won't succeed, one may well
+   expect some more load on the DNS burden.
+
+   The ubiquitous DNS thus deserves a great deal of attention, perhaps
+   much more than it generally has.  One may say that it is a victim of
+   its own success: if a user triggers an excessive amount of queries
+   only to have one request satisfied, he won't worry about it (in fact,
+   he won't notice it), won't complain to his system administrator, and
+   things will just go on like this.  Of course, DNS was designed to
+   resist and provide its services despite all these anomalies.  But by
+   doing so it is frequently forgotten, as long as people can Telnet or
+   ftp.  As DNS will be given new responsibilities, as pointed in the
+   above paragraph, the problems described in this text will grow more
+   serious and new ones may appear (notably security ones [16], with a
+   lot of work being presently in progress addressing security in DNS),
+   if nothing is done to purge them.
+
+References
+
+   [1] Lottor, M., "Internet Domain Survey, October 1994",
+       http://www.nw.com/zone/WWW/report.html, October 1994.
+
+   [2] Beecher, B., "Dealing With Lame Delegations", Univ. Michigan,
+       LISA VI, October 1992.
+
+   [3] Frazao, J. and J. L. Martins, "Ddt - Domain Debug Tools, A
+       Package to Debug the DNS Tree", Dept. Informatica Faculdade
+       Ciencias Univ. Lisboa, DI-FCUL-1992-04, January 1992.
+
+   [4] Danzig, P., "Probabilistic Error Checkers: Fixing DNS", Univ.
+       Southern California, Technical Report, February 1992.
+
+   [5] Kumar, A., J. Postel, C. Neuman, P. Danzig and S. Miller, "Common
+       DNS Implementation Errors and Suggested Fixes", RFC 1536,
+       USC/Information Sciences Institute, October 1993.
+
+   [6] Miller, S. and P. Danzig, "The Checker Project, Installation and
+       Operator's Manual", Univ. Southern California, TR CS94-560, 1994.
+
+   [7] Danzig, P., K. Obraczka and A. Kumar, "An Analisys of Wide-Area
+       Name Server Traffic", Univ. Southern California, TR 92-504, 1992.
+
+
+
+
+Romao                                                          [Page 11]
+
+RFC 1713                Tools for DNS debugging            November 1994
+
+
+   [8] Albitz, P. and C. Liu, "DNS and BIND", O'Reilly and Associates
+       Inc., October 1992.
+
+   [9] Beertema, P., "Common DNS Data File Configuration Errors", RFC
+       1537, CWI, October 1993.
+
+  [10] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
+       974, CSNET CIC BBN Laboratories Inc., January 1986.
+
+  [11] Allocchio, C., A. Bonito, B. Cole, S. Giordano and R. Hagens,
+       "Using the Internet DNS to Distribute RFC1327 Mail Address
+       Mapping Tables", RFC 1664, GARR, Cisco Systems Inc., Centro
+       Svizzero Calcolo Scientifico, ANS, August 1994.
+
+  [12] Malamud, C. and M. Rose, "Principles of Operation for the TPC.INT
+       Subdomain: General Principles and Policy", RFC 1530, Internet
+       Multicasting Service, Dover Beach Consulting Inc., October 1993.
+
+  [13] Rosenbaum, R., "Using the Domain Name System to Store Arbitrary
+       String Attributes", RFC 1464, Digital Equipment Corporation, May
+       1993.
+
+  [14] Everhart, C., L. Mamakos, R. Ullmann and P. Mockapetris (Ed.),
+       "New DNS RR Definitions", RFC 1183, Transarc, Univ. Maryland,
+       Prime Computer, Information Sciences Institute, October 1990.
+
+  [15] Manning, B., and R. Colella, "DNS NSAP Resource Records", RFC
+       1706, USC/Information Sciences Institute, NIST, October 1994.
+
+  [16] Gavron, E., "A Security Problem and Proposed Correction With
+       Widely Deployed DNS Software", RFC 1535, ACES Research Inc.,
+       October 1993
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Romao                                                          [Page 12]
+
+RFC 1713                Tools for DNS debugging            November 1994
+
+
+Security Considerations
+
+   Security issues are not discussed in this memo (although security is
+   briefly mentioned at the end of section 3).
+
+Author's Address
+
+   Artur Romao
+   DI - Faculdade de Ciencias e Tecnologia
+   Universidade Nova de Lisboa
+   Quinta da Torre
+   P-2825 Monte de Caparica
+   Portugal
+
+   Phone: +351 1 294 28 44
+   Fax:   +351 1 295 77 86
+   EMail: artur@fct.unl.pt
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Romao                                                          [Page 13]
+
diff --git a/usr.sbin/named/doc/rfc/rfc1794 b/usr.sbin/named/doc/rfc/rfc1794
new file mode 100644
index 00000000000..53a98472fb3
--- /dev/null
+++ b/usr.sbin/named/doc/rfc/rfc1794
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                          T. Brisco
+Request for Comments: 1794                            Rutgers University
+Category: Informational                                       April 1995
+
+
+                     DNS Support for Load Balancing
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+1. Introduction
+
+   This RFC is meant to first chronicle a foray into the IETF DNS
+   Working Group, discuss other possible alternatives to
+   provide/simulate load balancing support for DNS, and to provide an
+   ultimate, flexible solution for providing DNS support for balancing
+   loads of many types.
+
+2. History
+
+   The history of this probably dates back well before my own time - so
+   undoubtedly some holes are here.  Hopefully they can be filled in by
+   other authors.
+
+   Initially; "load balancing" was intended to permit the Domain Name
+   System (DNS) [1] agents to support the concept of "clusters" (derived
+   from the VMS usage) of machines - where all machines were
+   functionally similar or the same, and it didn't particularly matter
+   which machine was picked - as long as the load of the processing was
+   reasonably well distributed across a series of actual different
+   hosts.  Around 1986 a number of different schemes started surfacing
+   as hacks to the Berkeley Internet Name Domain server (BIND)
+   distribution.  Probably the most widely distributed of these were the
+   "Shuffle Address" (SA) modifications by Bryan Beecher, or possibly
+   Marshall Rose's "Round Robin" code.
+
+   The SA records, however, did a round-robin ordering of the Address
+   resource records, and didn't do much with regard to the particular
+   loads on the target machines.  Matt Madison (of TGV) implemented some
+   changes that used VMS facilities to review the system loads, and
+   return A RRs in the order of least-loaded to most loaded.
+
+   The problem was with SAs was that load was not actually a factor, and
+   TGV's relied on VMS specific facilities to order the records.  The SA
+   RRs required changes to the DNS specification (in file syntax and in
+
+
+
+Brisco                                                          [Page 1]
+
+RFC 1794             DNS Support for Load Balancing           April 1995
+
+
+   record processing).  These were both viewed as drawbacks and not as
+   general solutions.
+
+   Most of the Internet waited in anticipation of an IETF approved
+   method for simulating "clusters".
+
+   Through a few IETF DNS Working Group sessions (Chaired by Rob Austein
+   of Epilogue), it was collectively agreed upon that a number of
+   criteria must be met:
+
+       A) Backwards compatibility with the existing DNS RFC.
+
+       B) Information changes frequently.
+
+       C) Multiple addresses should be sent out.
+
+       D) Must interact with other RRs appropriately.
+
+       E) Must be able to represent many types of "loads"
+
+       F) Must be fast.
+
+   (A) would ensure that the installed base of BIND and other DNS
+   implementations would continue to operate and interoperate properly.
+
+   (B) would permit very fast update times - to enable modeling of
+   real-time data.  Five minutes was thought as a normal interval,
+   though changes as fast as every sixty seconds could be imagined.
+
+   (C) would cover the possibility of a host's address being advertised
+   as optimal, yet the machine crashed during the period within the TTL
+   of the RR.  The second-most preferable address would be advertised
+   second, the third-most preferable third, and so on.  This would allow
+   a reasonable stab at recovery during machine failures.
+
+   (D) would ensure correct handling of all ancillary information - such
+   as MX, RP, and TXT information, as well as reverse lookup
+   information.  It needed to be ensured that such processes as mail
+   handling continued to work in an unsurprising and predictable manner.
+
+   (E) would ensure the flexibility that everyone wished.  A breadth of
+   "loads" were wished to be represented by various members of the DNS
+   Working Group.  Some "loads" were fairly eclectic - such as the
+   address ordering by the RTT to the host, some were pragmatic - such
+   as balancing the CPU load evenly across a series of hosts.  All
+   represented valid concerns within their own context, and the idea of
+   having separate RR types for each was unthinkable (primarily; it
+   would violate goal A).
+
+
+
+Brisco                                                          [Page 2]
+
+RFC 1794             DNS Support for Load Balancing           April 1995
+
+
+   (F) needed to ensure a few things.  Primarily that the time to
+   calculate the information to order the addressing information did not
+   exceed the TTL of the information distributed - i.e., that elements
+   with a TTL of five minutes didn't take six minutes to calculate.
+   Similarly; it seems a fairly clear goal in the DNS RFC that clients
+   should not be kept waiting - that request processing should continue
+   regardless of the state of any other processing occurring.
+
+3. Possible Alternatives
+
+   During various discussions with the DNS Working Group and with the
+   Load Balancing Committee, it was noted that no existing solution
+   dealt with all wishes appropriately.  One of the major successes of
+   the DNS is its flexibility - and it was felt that this needed to be
+   retained in all aspects.  It was conceived that perhaps not only
+   address information would need to be changed rapidly, but other
+   records may also need to change rapidly (at least this could not be
+   ruled out - who knows what technologies lurk in the future).
+
+   Of primary concern to many was the ability to interact with older
+   implementations of DNS.  The DNS is implemented widely now, and
+   changes to critical portions of the protocol could cause havoc for
+   years.  It became rapidly apparent through conversations with Jon
+   Postel and Dave Crocker (Area Director) that modifications to the
+   protocol would be viewed dimly.
+
+4. A Flexible Model
+
+   During many hours of discussions, it arose upon suggestion from Rob
+   Austein that the changes could be implemented without changes to the
+   protocol; if zone transfer behavior could be subtly changed, then the
+   zone transfer process could accommodate the changing of various RR
+   information.  What was needed was a smarter program to do the zone
+   transfers.  Pursuant to this, changes were made to BIND that would
+   permit the specification of the program to do the zone transfers for
+   particular zones.
+
+   There is no specification that a secondary has to receive updates
+   from its primary server in any specific manner - only that it needs
+   to check periodically, and obtain new zone copies when changes have
+   been made.  Conceivably the zone transfer agent could obtain the
+   information from any number of sources (e.g., a load average daemon,
+   a round-robin sorter) and present the information back to the
+   nameserver for distribution.
+
+   A number of questions arose from this concept, and all seem to have
+   been dealt with accordingly.  Primarily, the DNS protocol doesn't
+   guarantee ordering.  While the DNS protocol doesn't guarantee
+
+
+
+Brisco                                                          [Page 3]
+
+RFC 1794             DNS Support for Load Balancing           April 1995
+
+
+   ordering, it is clear that the ordering is predictive - that
+   information read in twice in the same order will be presented twice
+   in the same order to clients.  Clients, of course, may reorder this
+   information, but that is deemed as a "local issue" as it is
+   configurable by the remote systems administrators (e.g., sortlists,
+   etc).  The zone transfer agent would have to account for any "mis-
+   ordering" that may occur locally, but remote reordering (e.g., client
+   side sortlists) of RRs is is impossible to predict.  Since local
+   mis-ordering is consistent, the zone transfer agents could easily
+   account for this.
+
+   Secondarily, but perhaps more subtly, the problem arises that zone
+   transfers aren't used by primary nameservers, only by secondary
+   nameservers.  To clarify this, the idea of "fast" or "volatile"
+   subzones must be dealt with.  In a volatile environment (where
+   address or other RR ordering changes rapidly), the refresh rate of a
+   zone must be set very low, and the TTL of the RRs handed out must
+   similarly be very low.  There is no use in handing out information
+   with TTLs of an hour, when the conditions for ordering the RRs
+   changes minutely.  There must be a relatively close relationship
+   between the refresh rates and TTLs of the information.  Of course,
+   with very low refresh rates, zone transfers between the primary and
+   secondary would have to occur frequently.  Given that primary and
+   secondary nameservers should be topologically and geographically far
+   apart, moving that much data that frequently is seen as prohibitive.
+   Also; the longer the propagation time between the primary and
+   secondary, the larger the window in which circumstances can change -
+   thus invalidating the secondary's information.  It is generally
+   thought that passing volatile information on to a secondary is fairly
+   useless - if secondaries want accurate information, then they should
+   calculate it themselves and not obtain it via zone transfers.  This
+   avoids the problem with secondaries losing contact with the primaries
+   (but access to the targets of the volatile domain are still
+   reachable), but the secondary has information that is growing stale.
+
+   What is essentially necessary is a secondary (with no primary) which
+   can calculate the necessary ordering of the RR data for itself (which
+   also avoids the problem of different versions of domain servers
+   predictively ordering RR information in different predictive
+   fashions).  For a volatile zone, there is no primary DNS agent, but
+   rather a series of autonomous secondary agents.  Each autonomous
+   secondary agent is, of course, capable of calculating the ordering or
+   content of the volatile RRs itself.
+
+
+
+
+
+
+
+
+Brisco                                                          [Page 4]
+
+RFC 1794             DNS Support for Load Balancing           April 1995
+
+
+5. Implementation
+
+   With some help from Masataka Ohta (Tokyo Institute of Technology), I
+   implemented modifications to BIND to permit the specification of the
+   zone transfer program (zone transfer agent) for particular domains:
+
+           transfer        <domain-name>       <program-name>
+
+   Currently I define a separate subdomain that has a few hosts defined
+   in it - all volatile information.  The zone has a refresh rate of
+   300, and a minimum TTL of 300 indicated.  The configuration file is
+   indicated as "volatile.hosts".  Every 300 seconds a program "doAxfer"
+   is run to do the zone transfer.  The program "doAxfer" reads the file
+   "volatile.hosts.template" and the file "volatile.hosts.list".  The
+   addresses specified in volatile.hosts.list are rotated a random
+   number of times, and then substituted (in order) into
+   volatile.hosts.template to generate the file volatile.hosts.  The
+   program "doAxfer" then exits with a value of 1 - to indicate to the
+   nameserver that the zone transfer was successful, and that the file
+   should be read in, and the information distributed.  This results in
+   a host having multiple addresses, and the addresses are randomized
+   every five minutes (300 seconds).
+
+   Two bugs continue to plague us in this endeavor.  BIND currently
+   considers any TTL under 300 seconds as "irrational", and substitutes
+   in the value of 300 instead.  This greatly hampers the functionality
+   of volatile zones.  In the fastest of all cases - a 0 TTL -
+   information would be used once, and then thrown away.  Presumably the
+   new RR information could be calculated every 5 seconds, and the RRs
+   handed out with a TTL of 0.  It must be considered that one
+   limitation of the speed of a zone is going to be the ability of a
+   machine to calculate new information fast enough.
+
+   The other bug that also effects this is that, as with TTLs, BIND
+   considers any zone refresh rate under 15 minutes to be similarly
+   irrational.  Obviously zone refresh rates of 15 minutes is
+   unacceptable for this sort of applications.
+
+   For a work-around, the current code sets these same hard-coded values
+   to 60 seconds.  Sixty seconds is still large enough to avoid any
+   residual bugs associated with small timer values, but is also short
+   enough to allow fast subzones to be of use.
+
+   This version of BIND is currently in release within Rutgers
+   University, operating in both "fast" and normal zones.
+
+
+
+
+
+
+Brisco                                                          [Page 5]
+
+RFC 1794             DNS Support for Load Balancing           April 1995
+
+
+6. Performance
+
+   While the performance of fast zones isn't exactly stellar, it is not
+   much more than the normal CPU loads induced by BIND.  Testing was
+   performed on a Sun Sparc-2 being used as a normal workstation, but no
+   resolvers were using the name server - essentially the nameserver was
+   idle.  For a configuration with no fast subzones, BIND accrued 11 CPU
+   seconds in 24 hours.  For a configuration with one fast zone, six
+   address records, and being refreshed every 300 seconds (5 minutes),
+   BIND accrued 1 minute 4 seconds CPU time.  For the same previous
+   configuration, but being refreshed every sixty seconds, BIND accrued
+   5 minutes and 38 seconds of CPU time.
+
+   As is no great surprise, the CPU load on the serving machine was
+   linear to the frequency of the refresh time.  The sixty second
+   refresh configuration used approximately five times as much CPU time
+   as did the 300 second refresh configuration.  One can easily
+   extrapolate that the overall CPU utilization would be linear to the
+   number of zones and the frequency of the refresh period.  All of this
+   is based on a shell script that always indicated that a zone update
+   was necessary, a more intelligent program should realize when the
+   reordering of the RRs was unnecessary and avoid such periodic zone
+   reloads.
+
+7. Acknowledgments
+
+   Most of the ideas in this document are the results of conversations
+   and proposals from many, many people - including, but not limited to,
+   Robert Austein, Stuart Vance, Masataka Ohta, Marshall Rose, and the
+   members of the IETF DNS Working Group.
+
+8. References
+
+   [1] Mockapetris, P., "Domain Names - Implementation and
+       Specification", STD 13, RFC 1035, USC/Information Sciences
+       Institute, November 1987.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Brisco                                                          [Page 6]
+
+RFC 1794             DNS Support for Load Balancing           April 1995
+
+
+9.  Security Considerations
+
+   Security issues are not discussed in this memo.
+
+10. Author's Address
+
+   Thomas P. Brisco
+   Associate Director for Network Operations
+   Rutgers University
+   Computing Services, Telecommunications Division
+   Hill Center for the Mathematical Sciences
+   Busch Campus
+   Piscataway, New Jersey 08855-0879
+   USA
+
+   Phone: +1-908-445-2351
+   EMail: brisco@rutgers.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Brisco                                                          [Page 7]
+
diff --git a/usr.sbin/named/doc/rfc/rfc1876 b/usr.sbin/named/doc/rfc/rfc1876
new file mode 100644
index 00000000000..a289cffece2
--- /dev/null
+++ b/usr.sbin/named/doc/rfc/rfc1876
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                           C. Davis
+Request for Comments: 1876                             Kapor Enterprises
+Updates: 1034, 1035                                             P. Vixie
+Category: Experimental                                 Vixie Enterprises
+                                                              T. Goodwin
+                                                            FORE Systems
+                                                            I. Dickinson
+                                                   University of Warwick
+                                                            January 1996
+
+
+ A Means for Expressing Location Information in the Domain Name System
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  This memo does not specify an Internet standard of any
+   kind.  Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+1. Abstract
+
+   This memo defines a new DNS RR type for experimental purposes.  This
+   RFC describes a mechanism to allow the DNS to carry location
+   information about hosts, networks, and subnets.  Such information for
+   a small subset of hosts is currently contained in the flat-file UUCP
+   maps.  However, just as the DNS replaced the use of HOSTS.TXT to
+   carry host and network address information, it is possible to replace
+   the UUCP maps as carriers of location information.
+
+   This RFC defines the format of a new Resource Record (RR) for the
+   Domain Name System (DNS), and reserves a corresponding DNS type
+   mnemonic (LOC) and numerical code (29).
+
+   This RFC assumes that the reader is familiar with the DNS [RFC 1034,
+   RFC 1035].  The data shown in our examples is for pedagogical use and
+   does not necessarily reflect the real Internet.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davis, et al                  Experimental                      [Page 1]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+2. RDATA Format
+
+       MSB                                           LSB
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      0|        VERSION        |         SIZE          |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      2|       HORIZ PRE       |       VERT PRE        |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      4|                   LATITUDE                    |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      6|                   LATITUDE                    |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      8|                   LONGITUDE                   |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+     10|                   LONGITUDE                   |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+     12|                   ALTITUDE                    |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+     14|                   ALTITUDE                    |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+   (octet)
+
+where:
+
+VERSION      Version number of the representation.  This must be zero.
+             Implementations are required to check this field and make
+             no assumptions about the format of unrecognized versions.
+
+SIZE         The diameter of a sphere enclosing the described entity, in
+             centimeters, expressed as a pair of four-bit unsigned
+             integers, each ranging from zero to nine, with the most
+             significant four bits representing the base and the second
+             number representing the power of ten by which to multiply
+             the base.  This allows sizes from 0e0 (<1cm) to 9e9
+             (90,000km) to be expressed.  This representation was chosen
+             such that the hexadecimal representation can be read by
+             eye; 0x15 = 1e5.  Four-bit values greater than 9 are
+             undefined, as are values with a base of zero and a non-zero
+             exponent.
+
+             Since 20000000m (represented by the value 0x29) is greater
+             than the equatorial diameter of the WGS 84 ellipsoid
+             (12756274m), it is therefore suitable for use as a
+             "worldwide" size.
+
+HORIZ PRE    The horizontal precision of the data, in centimeters,
+             expressed using the same representation as SIZE.  This is
+             the diameter of the horizontal "circle of error", rather
+
+
+
+Davis, et al                  Experimental                      [Page 2]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+             than a "plus or minus" value.  (This was chosen to match
+             the interpretation of SIZE; to get a "plus or minus" value,
+             divide by 2.)
+
+VERT PRE     The vertical precision of the data, in centimeters,
+             expressed using the sane representation as for SIZE.  This
+             is the total potential vertical error, rather than a "plus
+             or minus" value.  (This was chosen to match the
+             interpretation of SIZE; to get a "plus or minus" value,
+             divide by 2.)  Note that if altitude above or below sea
+             level is used as an approximation for altitude relative to
+             the [WGS 84] ellipsoid, the precision value should be
+             adjusted.
+
+LATITUDE     The latitude of the center of the sphere described by the
+             SIZE field, expressed as a 32-bit integer, most significant
+             octet first (network standard byte order), in thousandths
+             of a second of arc.  2^31 represents the equator; numbers
+             above that are north latitude.
+
+LONGITUDE    The longitude of the center of the sphere described by the
+             SIZE field, expressed as a 32-bit integer, most significant
+             octet first (network standard byte order), in thousandths
+             of a second of arc, rounded away from the prime meridian.
+             2^31 represents the prime meridian; numbers above that are
+             east longitude.
+
+ALTITUDE     The altitude of the center of the sphere described by the
+             SIZE field, expressed as a 32-bit integer, most significant
+             octet first (network standard byte order), in centimeters,
+             from a base of 100,000m below the [WGS 84] reference
+             spheroid used by GPS (semimajor axis a=6378137.0,
+             reciprocal flattening rf=298.257223563).  Altitude above
+             (or below) sea level may be used as an approximation of
+             altitude relative to the the [WGS 84] spheroid, though due
+             to the Earth's surface not being a perfect spheroid, there
+             will be differences.  (For example, the geoid (which sea
+             level approximates) for the continental US ranges from 10
+             meters to 50 meters below the [WGS 84] spheroid.
+             Adjustments to ALTITUDE and/or VERT PRE will be necessary
+             in most cases.  The Defense Mapping Agency publishes geoid
+             height values relative to the [WGS 84] ellipsoid.
+
+
+
+
+
+
+
+
+
+Davis, et al                  Experimental                      [Page 3]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+3. Master File Format
+
+   The LOC record is expressed in a master file in the following format:
+
+   <owner> <TTL> <class> LOC ( d1 [m1 [s1]] {"N"|"S"} d2 [m2 [s2]]
+                               {"E"|"W"} alt["m"] [siz["m"] [hp["m"]
+                               [vp["m"]]]] )
+
+   (The parentheses are used for multi-line data as specified in [RFC
+   1035] section 5.1.)
+
+   where:
+
+       d1:     [0 .. 90]            (degrees latitude)
+       d2:     [0 .. 180]           (degrees longitude)
+       m1, m2: [0 .. 59]            (minutes latitude/longitude)
+       s1, s2: [0 .. 59.999]        (seconds latitude/longitude)
+       alt:    [-100000.00 .. 42849672.95] BY .01 (altitude in meters)
+       siz, hp, vp: [0 .. 90000000.00] (size/precision in meters)
+
+   If omitted, minutes and seconds default to zero, size defaults to 1m,
+   horizontal precision defaults to 10000m, and vertical precision
+   defaults to 10m.  These defaults are chosen to represent typical
+   ZIP/postal code area sizes, since it is often easy to find
+   approximate geographical location by ZIP/postal code.
+
+4. Example Data
+
+;;;
+;;; note that these data would not all appear in one zone file
+;;;
+
+;; network LOC RR derived from ZIP data.  note use of precision defaults
+cambridge-net.kei.com.        LOC   42 21 54 N 71 06 18 W -24m 30m
+
+;; higher-precision host LOC RR.  note use of vertical precision default
+loiosh.kei.com.               LOC   42 21 43.952 N 71 5 6.344 W
+                                    -24m 1m 200m
+
+pipex.net.                    LOC   52 14 05 N 00 08 50 E 10m
+
+curtin.edu.au.                LOC   32 7 19 S 116 2 25 E 10m
+
+rwy04L.logan-airport.boston.  LOC   42 21 28.764 N 71 00 51.617 W
+                                    -44m 2000m
+
+
+
+
+
+
+Davis, et al                  Experimental                      [Page 4]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+5. Application use of the LOC RR
+
+5.1 Suggested Uses
+
+   Some uses for the LOC RR have already been suggested, including the
+   USENET backbone flow maps, a "visual traceroute" application showing
+   the geographical path of an IP packet, and network management
+   applications that could use LOC RRs to generate a map of hosts and
+   routers being managed.
+
+5.2 Search Algorithms
+
+   This section specifies how to use the DNS to translate domain names
+   and/or IP addresses into location information.
+
+   If an application wishes to have a "fallback" behavior, displaying a
+   less precise or larger area when a host does not have an associated
+   LOC RR, it MAY support use of the algorithm in section 5.2.3, as
+   noted in sections 5.2.1 and 5.2.2.  If fallback is desired, this
+   behaviour is the RECOMMENDED default, but in some cases it may need
+   to be modified based on the specific requirements of the application
+   involved.
+
+   This search algorithm is designed to allow network administrators to
+   specify the location of a network or subnet without requiring LOC RR
+   data for each individual host.  For example, a computer lab with 24
+   workstations, all of which are on the same subnet and in basically
+   the same location, would only need a LOC RR for the subnet.
+   (However, if the file server's location has been more precisely
+   measured, a separate LOC RR for it can be placed in the DNS.)
+
+5.2.1 Searching by Name
+
+   If the application is beginning with a name, rather than an IP
+   address (as the USENET backbone flow maps do), it MUST check for a
+   LOC RR associated with that name.  (CNAME records should be followed
+   as for any other RR type.)
+
+   If there is no LOC RR for that name, all A records (if any)
+   associated with the name MAY be checked for network (or subnet) LOC
+   RRs using the "Searching by Network or Subnet" algorithm (5.2.3).  If
+   multiple A records exist and have associated network or subnet LOC
+   RRs, the application may choose to use any, some, or all of the LOC
+   RRs found, possibly in combination.  It is suggested that multi-homed
+   hosts have LOC RRs for their name in the DNS to avoid any ambiguity
+   in these cases.
+
+
+
+
+
+Davis, et al                  Experimental                      [Page 5]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+   Note that domain names that do not have associated A records must
+   have a LOC RR associated with their name in order for location
+   information to be accessible.
+
+5.2.2 Searching by Address
+
+   If the application is beginning with an IP address (as a "visual
+   traceroute" application might be) it MUST first map the address to a
+   name using the IN-ADDR.ARPA namespace (see [RFC 1034], section
+   5.2.1), then check for a LOC RR associated with that name.
+
+   If there is no LOC RR for the name, the address MAY be checked for
+   network (or subnet) LOC RRs using the "Searching by Network or
+   Subnet" algorithm (5.2.3).
+
+5.2.3 Searching by Network or Subnet
+
+   Even if a host's name does not have any associated LOC RRs, the
+   network(s) or subnet(s) it is on may.  If the application wishes to
+   search for such less specific data, the following algorithm SHOULD be
+   followed to find a network or subnet LOC RR associated with the IP
+   address.  This algorithm is adapted slightly from that specified in
+   [RFC 1101], sections 4.3 and 4.4.
+
+   Since subnet LOC RRs are (if present) more specific than network LOC
+   RRs, it is best to use them if available.  In order to do so, we
+   build a stack of network and subnet names found while performing the
+   [RFC 1101] search, then work our way down the stack until a LOC RR is
+   found.
+
+   1. create a host-zero address using the network portion of the IP
+      address (one, two, or three bytes for class A, B, or C networks,
+      respectively).  For example, for the host 128.9.2.17, on the class
+      B network 128.9, this would result in the address "128.9.0.0".
+
+   2. Reverse the octets, suffix IN-ADDR.ARPA, and query for PTR and A
+      records.  Retrieve:
+
+               0.0.9.128.IN-ADDR.ARPA.  PTR    isi-net.isi.edu.
+                                        A      255.255.255.0
+
+      Push the name "isi-net.isi.edu" onto the stack of names to be
+      searched for LOC RRs later.
+
+
+
+
+
+
+
+
+Davis, et al                  Experimental                      [Page 6]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+   3. 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
+
+      Push the name "div2-subnet.isi.edu" onto the stack of names to be
+      searched for LOC RRs later.
+
+   4. 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.
+
+      Push the name "inc-subsubnet.isi.edu" onto the stack of names to
+      be searched for LOC RRs later.
+
+   5. Since no A RR is present at 16.2.9.128.IN-ADDR.ARPA., there are no
+      more subnet levels to search.  We now pop the top name from the
+      stack and check for an associated LOC RR.  Repeat until a LOC RR
+      is found.
+
+      In this case, assume that inc-subsubnet.isi.edu does not have an
+      associated LOC RR, but that div2-subnet.isi.edu does.  We will
+      then use div2-subnet.isi.edu's LOC RR as an approximation of this
+      host's location.  (Note that even if isi-net.isi.edu has a LOC RR,
+      it will not be used if a subnet also has a LOC RR.)
+
+5.3 Applicability to non-IN Classes and non-IP Addresses
+
+   The LOC record is defined for all RR classes, and may be used with
+   non-IN classes such as HS and CH.  The semantics of such use are not
+   defined by this memo.
+
+   The search algorithm in section 5.2.3 may be adapted to other
+   addressing schemes by extending [RFC 1101]'s encoding of network
+   names to cover those schemes.  Such extensions are not defined by
+   this memo.
+
+
+
+
+
+
+
+
+
+
+
+Davis, et al                  Experimental                      [Page 7]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+6. References
+
+   [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
+              STD 13, RFC 1034, USC/Information Sciences Institute,
+              November 1987.
+
+   [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
+              Specification", STD 13, RFC 1035, USC/Information Sciences
+              Institute, November 1987.
+
+   [RFC 1101] Mockapetris, P., "DNS Encoding of Network Names and Other
+              Types", RFC 1101, USC/Information Sciences Institute,
+              April 1989.
+
+   [WGS 84] United States Department of Defense; DoD WGS-1984 - Its
+            Definition and Relationships with Local Geodetic Systems;
+            Washington, D.C.; 1985; Report AD-A188 815 DMA; 6127; 7-R-
+            138-R; CV, KV;
+
+7. Security Considerations
+
+   High-precision LOC RR information could be used to plan a penetration
+   of physical security, leading to potential denial-of-machine attacks.
+   To avoid any appearance of suggesting this method to potential
+   attackers, we declined the opportunity to name this RR "ICBM".
+
+8. Authors' Addresses
+
+   The authors as a group can be reached as <loc@pipex.net>.
+
+   Christopher Davis
+   Kapor Enterprises, Inc.
+   238 Main Street, Suite 400
+   Cambridge, MA 02142
+
+   Phone: +1 617 576 4532
+   EMail: ckd@kei.com
+
+
+   Paul Vixie
+   Vixie Enterprises
+   Star Route Box 159A
+   Woodside, CA 94062
+
+   Phone: +1 415 747 0204
+   EMail: paul@vix.com
+
+
+
+
+
+Davis, et al                  Experimental                      [Page 8]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+   Tim Goodwin
+   Public IP Exchange Ltd (PIPEX)
+   216 The Science Park
+   Cambridge CB4 4WA
+   UK
+
+   Phone: +44 1223 250250
+   EMail: tim@pipex.net
+
+
+   Ian Dickinson
+   FORE Systems
+   2475 The Crescent
+   Solihull Parkway
+   Birmingham Business Park
+   B37 7YE
+   UK
+
+   Phone: +44 121 717 4444
+   EMail: idickins@fore.co.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davis, et al                  Experimental                      [Page 9]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+Appendix A: Sample Conversion Routines
+
+/*
+ * routines to convert between on-the-wire RR format and zone file
+ * format.  Does not contain conversion to/from decimal degrees;
+ * divide or multiply by 60*60*1000 for that.
+ */
+
+static unsigned int poweroften[10] = {1, 10, 100, 1000, 10000, 100000,
+                                 1000000,10000000,100000000,1000000000};
+
+/* takes an XeY precision/size value, returns a string representation.*/
+static const char *
+precsize_ntoa(prec)
+        u_int8_t prec;
+{
+        static char retbuf[sizeof("90000000.00")];
+        unsigned long val;
+        int mantissa, exponent;
+
+        mantissa = (int)((prec >> 4) & 0x0f) % 10;
+        exponent = (int)((prec >> 0) & 0x0f) % 10;
+
+        val = mantissa * poweroften[exponent];
+
+        (void) sprintf(retbuf,"%d.%.2d", val/100, val%100);
+        return (retbuf);
+}
+
+/* converts ascii size/precision X * 10**Y(cm) to 0xXY. moves pointer.*/
+static u_int8_t
+precsize_aton(strptr)
+        char **strptr;
+{
+        unsigned int mval = 0, cmval = 0;
+        u_int8_t retval = 0;
+        register char *cp;
+        register int exponent;
+        register int mantissa;
+
+        cp = *strptr;
+
+        while (isdigit(*cp))
+                mval = mval * 10 + (*cp++ - '0');
+
+        if (*cp == '.') {               /* centimeters */
+                cp++;
+                if (isdigit(*cp)) {
+
+
+
+Davis, et al                  Experimental                     [Page 10]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+                        cmval = (*cp++ - '0') * 10;
+                        if (isdigit(*cp)) {
+                                cmval += (*cp++ - '0');
+                        }
+                }
+        }
+        cmval = (mval * 100) + cmval;
+
+        for (exponent = 0; exponent < 9; exponent++)
+                if (cmval < poweroften[exponent+1])
+                        break;
+
+        mantissa = cmval / poweroften[exponent];
+        if (mantissa > 9)
+                mantissa = 9;
+
+        retval = (mantissa << 4) | exponent;
+
+        *strptr = cp;
+
+        return (retval);
+}
+
+/* converts ascii lat/lon to unsigned encoded 32-bit number.
+ *  moves pointer. */
+static u_int32_t
+latlon2ul(latlonstrptr,which)
+        char **latlonstrptr;
+        int *which;
+{
+        register char *cp;
+        u_int32_t retval;
+        int deg = 0, min = 0, secs = 0, secsfrac = 0;
+
+        cp = *latlonstrptr;
+
+        while (isdigit(*cp))
+                deg = deg * 10 + (*cp++ - '0');
+
+        while (isspace(*cp))
+                cp++;
+
+        if (!(isdigit(*cp)))
+                goto fndhemi;
+
+        while (isdigit(*cp))
+                min = min * 10 + (*cp++ - '0');
+
+
+
+
+Davis, et al                  Experimental                     [Page 11]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+        while (isspace(*cp))
+                cp++;
+
+        if (!(isdigit(*cp)))
+                goto fndhemi;
+
+        while (isdigit(*cp))
+                secs = secs * 10 + (*cp++ - '0');
+
+        if (*cp == '.') {               /* decimal seconds */
+                cp++;
+                if (isdigit(*cp)) {
+                        secsfrac = (*cp++ - '0') * 100;
+                        if (isdigit(*cp)) {
+                                secsfrac += (*cp++ - '0') * 10;
+                                if (isdigit(*cp)) {
+                                        secsfrac += (*cp++ - '0');
+                                }
+                        }
+                }
+        }
+
+        while (!isspace(*cp))   /* if any trailing garbage */
+                cp++;
+
+        while (isspace(*cp))
+                cp++;
+
+ fndhemi:
+        switch (*cp) {
+        case 'N': case 'n':
+        case 'E': case 'e':
+                retval = ((unsigned)1<<31)
+                        + (((((deg * 60) + min) * 60) + secs) * 1000)
+                        + secsfrac;
+                break;
+        case 'S': case 's':
+        case 'W': case 'w':
+                retval = ((unsigned)1<<31)
+                        - (((((deg * 60) + min) * 60) + secs) * 1000)
+                        - secsfrac;
+                break;
+        default:
+                retval = 0;     /* invalid value -- indicates error */
+                break;
+        }
+
+        switch (*cp) {
+
+
+
+Davis, et al                  Experimental                     [Page 12]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+        case 'N': case 'n':
+        case 'S': case 's':
+                *which = 1;     /* latitude */
+                break;
+        case 'E': case 'e':
+        case 'W': case 'w':
+                *which = 2;     /* longitude */
+                break;
+        default:
+                *which = 0;     /* error */
+                break;
+        }
+
+        cp++;                   /* skip the hemisphere */
+
+        while (!isspace(*cp))   /* if any trailing garbage */
+                cp++;
+
+        while (isspace(*cp))    /* move to next field */
+                cp++;
+
+        *latlonstrptr = cp;
+
+        return (retval);
+}
+
+/* converts a zone file representation in a string to an RDATA
+ * on-the-wire representation. */
+u_int32_t
+loc_aton(ascii, binary)
+        const char *ascii;
+        u_char *binary;
+{
+        const char *cp, *maxcp;
+        u_char *bcp;
+
+        u_int32_t latit = 0, longit = 0, alt = 0;
+        u_int32_t lltemp1 = 0, lltemp2 = 0;
+        int altmeters = 0, altfrac = 0, altsign = 1;
+        u_int8_t hp = 0x16;    /* default = 1e6 cm = 10000.00m = 10km */
+        u_int8_t vp = 0x13;    /* default = 1e3 cm = 10.00m */
+        u_int8_t siz = 0x12;   /* default = 1e2 cm = 1.00m */
+        int which1 = 0, which2 = 0;
+
+        cp = ascii;
+        maxcp = cp + strlen(ascii);
+
+        lltemp1 = latlon2ul(&cp, &which1);
+
+
+
+Davis, et al                  Experimental                     [Page 13]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+        lltemp2 = latlon2ul(&cp, &which2);
+
+        switch (which1 + which2) {
+        case 3:                 /* 1 + 2, the only valid combination */
+                if ((which1 == 1) && (which2 == 2)) { /* normal case */
+                        latit = lltemp1;
+                        longit = lltemp2;
+                } else if ((which1 == 2) && (which2 == 1)) {/*reversed*/
+                        longit = lltemp1;
+                        latit = lltemp2;
+                } else {        /* some kind of brokenness */
+                        return 0;
+                }
+                break;
+        default:                /* we didn't get one of each */
+                return 0;
+        }
+
+        /* altitude */
+        if (*cp == '-') {
+                altsign = -1;
+                cp++;
+        }
+
+        if (*cp == '+')
+                cp++;
+
+        while (isdigit(*cp))
+                altmeters = altmeters * 10 + (*cp++ - '0');
+
+        if (*cp == '.') {               /* decimal meters */
+                cp++;
+                if (isdigit(*cp)) {
+                        altfrac = (*cp++ - '0') * 10;
+                        if (isdigit(*cp)) {
+                                altfrac += (*cp++ - '0');
+                        }
+                }
+        }
+
+        alt = (10000000 + (altsign * (altmeters * 100 + altfrac)));
+
+        while (!isspace(*cp) && (cp < maxcp))
+                                           /* if trailing garbage or m */
+                cp++;
+
+        while (isspace(*cp) && (cp < maxcp))
+                cp++;
+
+
+
+Davis, et al                  Experimental                     [Page 14]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+        if (cp >= maxcp)
+                goto defaults;
+
+        siz = precsize_aton(&cp);
+
+        while (!isspace(*cp) && (cp < maxcp))/*if trailing garbage or m*/
+                cp++;
+
+        while (isspace(*cp) && (cp < maxcp))
+                cp++;
+
+        if (cp >= maxcp)
+                goto defaults;
+
+        hp = precsize_aton(&cp);
+
+        while (!isspace(*cp) && (cp < maxcp))/*if trailing garbage or m*/
+                cp++;
+
+        while (isspace(*cp) && (cp < maxcp))
+                cp++;
+
+        if (cp >= maxcp)
+                goto defaults;
+
+        vp = precsize_aton(&cp);
+
+ defaults:
+
+        bcp = binary;
+        *bcp++ = (u_int8_t) 0;  /* version byte */
+        *bcp++ = siz;
+        *bcp++ = hp;
+        *bcp++ = vp;
+        PUTLONG(latit,bcp);
+        PUTLONG(longit,bcp);
+        PUTLONG(alt,bcp);
+
+        return (16);            /* size of RR in octets */
+}
+
+/* takes an on-the-wire LOC RR and prints it in zone file
+ * (human readable) format. */
+char *
+loc_ntoa(binary,ascii)
+        const u_char *binary;
+        char *ascii;
+{
+
+
+
+Davis, et al                  Experimental                     [Page 15]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+        static char tmpbuf[255*3];
+
+        register char *cp;
+        register const u_char *rcp;
+
+        int latdeg, latmin, latsec, latsecfrac;
+        int longdeg, longmin, longsec, longsecfrac;
+        char northsouth, eastwest;
+        int altmeters, altfrac, altsign;
+
+        const int referencealt = 100000 * 100;
+
+        int32_t latval, longval, altval;
+        u_int32_t templ;
+        u_int8_t sizeval, hpval, vpval, versionval;
+
+        char *sizestr, *hpstr, *vpstr;
+
+        rcp = binary;
+        if (ascii)
+                cp = ascii;
+        else {
+                cp = tmpbuf;
+        }
+
+        versionval = *rcp++;
+
+        if (versionval) {
+                sprintf(cp,"; error: unknown LOC RR version");
+                return (cp);
+        }
+
+        sizeval = *rcp++;
+
+        hpval = *rcp++;
+        vpval = *rcp++;
+
+        GETLONG(templ,rcp);
+        latval = (templ - ((unsigned)1<<31));
+
+        GETLONG(templ,rcp);
+        longval = (templ - ((unsigned)1<<31));
+
+        GETLONG(templ,rcp);
+        if (templ < referencealt) { /* below WGS 84 spheroid */
+                altval = referencealt - templ;
+                altsign = -1;
+        } else {
+
+
+
+Davis, et al                  Experimental                     [Page 16]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+                altval = templ - referencealt;
+                altsign = 1;
+        }
+
+        if (latval < 0) {
+                northsouth = 'S';
+                latval = -latval;
+        }
+        else
+                northsouth = 'N';
+
+        latsecfrac = latval % 1000;
+        latval = latval / 1000;
+        latsec = latval % 60;
+        latval = latval / 60;
+        latmin = latval % 60;
+        latval = latval / 60;
+        latdeg = latval;
+
+        if (longval < 0) {
+                eastwest = 'W';
+                longval = -longval;
+        }
+        else
+                eastwest = 'E';
+
+        longsecfrac = longval % 1000;
+        longval = longval / 1000;
+        longsec = longval % 60;
+        longval = longval / 60;
+        longmin = longval % 60;
+        longval = longval / 60;
+        longdeg = longval;
+
+        altfrac = altval % 100;
+        altmeters = (altval / 100) * altsign;
+
+        sizestr = savestr(precsize_ntoa(sizeval));
+        hpstr = savestr(precsize_ntoa(hpval));
+        vpstr = savestr(precsize_ntoa(vpval));
+
+        sprintf(cp,
+                "%d %.2d %.2d.%.3d %c %d %.2d %.2d.%.3d %c %d.%.2dm
+                %sm %sm %sm",
+                latdeg, latmin, latsec, latsecfrac, northsouth,
+                longdeg, longmin, longsec, longsecfrac, eastwest,
+                altmeters, altfrac, sizestr, hpstr, vpstr);
+
+
+
+
+Davis, et al                  Experimental                     [Page 17]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+        free(sizestr);
+        free(hpstr);
+        free(vpstr);
+
+        return (cp);
+}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davis, et al                  Experimental                     [Page 18]
+
diff --git a/usr.sbin/named/doc/rfc/rfc1884 b/usr.sbin/named/doc/rfc/rfc1884
new file mode 100644
index 00000000000..335a7ab543a
--- /dev/null
+++ b/usr.sbin/named/doc/rfc/rfc1884
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                       R. Hinden, Ipsilon Networks
+Request for Comments: 1884                       S. Deering, Xerox PARC
+Category: Standards Track                                       Editors
+                                                          December 1995
+
+
+                  IP Version 6 Addressing Architecture
+
+
+
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+
+Abstract
+
+   This specification defines the addressing architecture of the IP
+   Version 6 protocol [IPV6].  The document includes the IPv6 addressing
+   model, text representations of IPv6 addresses, definition of IPv6
+   unicast addresses, anycast addresses, and multicast addresses, and an
+   IPv6 nodes required addresses.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                     [Page 1]
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+Table of Contents
+
+   1. Introduction................................................3
+
+   2. IPv6 Addressing.............................................3
+      2.1 Addressing Model........................................4
+      2.2 Text Representation of Addresses........................4
+      2.3 Address Type Representation.............................5
+      2.4 Unicast Addresses.......................................7
+        2.4.1 Unicast Address Example.............................8
+        2.4.2 The Unspecified Address.............................9
+        2.4.3 The Loopback Address................................9
+        2.4.4 IPv6 Addresses with Embedded IPv4 Addresses.........9
+        2.4.5 NSAP Addresses......................................10
+        2.4.6 IPX Addresses.......................................10
+        2.4.7 Provider-Based Global Unicast Addresses.............10
+        2.4.8 Local-use IPv6 Unicast Addresses....................11
+      2.5 Anycast Addresses.......................................12
+        2.5.1 Required Anycast Address............................13
+      2.6 Multicast Addresses.....................................14
+        2.6.1 Pre-Defined Multicast Addresses.....................15
+      2.7 A Node's Required Addresses.............................17
+
+   REFERENCES.....................................................18
+
+   SECURITY CONSIDERATIONS........................................18
+
+   DOCUMENT EDITOR'S ADDRESSES....................................18
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                     [Page 2]
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+1.0 INTRODUCTION
+
+   This specification defines the addressing architecture of the IP
+   Version 6 protocol.  It includes a detailed description of the
+   currently defined address formats for IPv6 [IPV6].
+
+   The editors would like to acknowledge the contributions of Paul
+   Francis, Jim Bound, Brian Carpenter, Deborah Estrin, Peter Ford, Bob
+   Gilligan, Christian Huitema, Tony Li, Greg Minshall, Erik Nordmark,
+   Yakov Rekhter, Bill Simpson, and Sue Thomson.
+
+2.0 IPv6 ADDRESSING
+
+   IPv6 addresses are 128-bit identifiers for interfaces and sets of
+   interfaces.  There are three types of addresses:
+
+
+       Unicast:   An identifier for a single interface.  A packet sent
+                  to a unicast address is delivered to the interface
+                  identified by that address.
+
+       Anycast:   An identifier for a set of interfaces (typically
+                  belonging to different nodes).  A packet sent to an
+                  anycast address is delivered to one of the interfaces
+                  identified by that address (the "nearest" one,
+                  according to the routing protocols' measure of
+                  distance).
+
+       Multicast: An identifier for a set of interfaces (typically
+                  belonging to different nodes).  A packet sent to a
+                  multicast address is delivered to all interfaces
+                  identified by that address.
+
+   There are no broadcast addresses in IPv6, their function being
+   superseded by multicast addresses.
+
+   In this document, fields in addresses are given a specific name, for
+   example "subscriber".  When this name is used with the term "ID" for
+   identifier after the name (e.g., "subscriber ID"), it refers to the
+   contents of the named field.  When it is used with the term "prefix"
+   (e.g., "subscriber prefix") it refers to all of the address up to and
+   including this field.
+
+   In IPv6, all zeros and all ones are legal values for any field,
+   unless specifically excluded.  Specifically, prefixes may contain
+   zero-valued fields or end in zeros.
+
+
+
+
+
+Hinden & Deering            Standards Track                     [Page 3]
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+   2.1 Addressing Model
+
+   IPv6 Addresses of all types are assigned to interfaces, not nodes.
+   Since each interface belongs to a single node, any of that node's
+   interfaces' unicast addresses may be used as an identifier for the
+   node.
+
+   An IPv6 unicast address refers to a single interface.  A single
+   interface may be assigned multiple IPv6 addresses of any type
+   (unicast, anycast, and multicast).  There are two exceptions to this
+   model.  These are:
+
+     1) A single address may be assigned to multiple physical interfaces
+        if the implementation treats the multiple physical interfaces as
+        one interface when presenting it to the internet layer.  This is
+        useful for load-sharing over multiple physical interfaces.
+
+     2) Routers may have unnumbered interfaces (i.e., no IPv6 address
+        assigned to the interface) on point-to-point links to eliminate
+        the necessity to manually configure and advertise the addresses.
+        Addresses are not needed for point-to-point interfaces on
+        routers if those interfaces are not to be used as the origins or
+        destinations of any IPv6 datagrams.
+
+   IPv6 continues the IPv4 model that a subnet is associated with one
+   link.  Multiple subnets may be assigned to the same link.
+
+
+   2.2 Text Representation of Addresses
+
+   There are three conventional forms for representing IPv6 addresses as
+   text strings:
+
+     1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the
+        hexadecimal values of the eight 16-bit pieces of the address.
+        Examples:
+
+                   FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
+
+                   1080:0:0:0:8:800:200C:417A
+
+        Note that it is not necessary to write the leading zeros in an
+        individual field, but there must be at least one numeral in
+        every field (except for the case described in 2.).
+
+     2. Due to the method of allocating certain styles of IPv6
+        addresses, it will be common for addresses to contain long
+        strings of zero bits.  In order to make writing addresses
+
+
+
+Hinden & Deering            Standards Track                     [Page 4]
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+        containing zero bits easier a special syntax is available to
+        compress the zeros.  The use of "::" indicates multiple groups
+        of 16-bits of zeros.  The "::" can only appear once in an
+        address.  The "::" can also be used to compress the leading
+        and/or trailing zeros in an address.
+
+        For example the following addresses:
+
+             1080:0:0:0:8:800:200C:417A  a unicast address
+             FF01:0:0:0:0:0:0:43         a multicast address
+             0:0:0:0:0:0:0:1             the loopback address
+             0:0:0:0:0:0:0:0             the unspecified addresses
+
+        may be represented as:
+
+             1080::8:800:200C:417A       a unicast address
+             FF01::43                    a multicast address
+             ::1                         the loopback address
+             ::                          the unspecified addresses
+
+     3. An alternative form that is sometimes more convenient when
+        dealing with a mixed environment of IPv4 and IPv6 nodes is
+        x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values
+        of the six high-order 16-bit pieces of the address, and the 'd's
+        are the decimal values of the four low-order 8-bit pieces of the
+        address (standard IPv4 representation).  Examples:
+
+             0:0:0:0:0:0:13.1.68.3
+
+             0:0:0:0:0:FFFF:129.144.52.38
+
+        or in compressed form:
+
+             ::13.1.68.3
+
+             ::FFFF:129.144.52.38
+
+
+   2.3 Address Type Representation
+
+   The specific type of an IPv6 address is indicated by the leading bits
+   in the address.  The variable-length field comprising these leading
+   bits is called the Format Prefix (FP).  The initial allocation of
+   these prefixes is as follows:
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                     [Page 5]
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+        Allocation                         Prefix         Fraction of
+                                           (binary)       Address Space
+        -------------------------------    --------       -------------
+        Reserved                           0000 0000      1/256
+        Unassigned                         0000 0001      1/256
+
+        Reserved for NSAP Allocation       0000 001       1/128
+        Reserved for IPX Allocation        0000 010       1/128
+
+        Unassigned                         0000 011       1/128
+        Unassigned                         0000 1         1/32
+        Unassigned                         0001           1/16
+        Unassigned                         001            1/8
+
+        Provider-Based Unicast Address     010            1/8
+
+        Unassigned                         011            1/8
+
+        Reserved for Geographic-
+        Based Unicast Addresses            100            1/8
+
+        Unassigned                         101            1/8
+        Unassigned                         110            1/8
+        Unassigned                         1110           1/16
+        Unassigned                         1111 0         1/32
+        Unassigned                         1111 10        1/64
+        Unassigned                         1111 110       1/128
+
+        Unassigned                         1111 1110 0    1/512
+
+        Link Local Use Addresses           1111 1110 10   1/1024
+        Site Local Use Addresses           1111 1110 11   1/1024
+
+        Multicast Addresses                1111 1111      1/256
+
+        Note: The "unspecified address" (see section 2.4.2), the
+        loopback address (see section 2.4.3), and the IPv6 Addresses
+        with Embedded IPv4 Addresses (see section 2.4.4), are assigned
+        out of the 0000 0000 format prefix space.
+
+
+   This allocation supports the direct allocation of provider addresses,
+   local use addresses, and multicast addresses.  Space is reserved for
+   NSAP addresses, IPX addresses, and geographic addresses.  The
+   remainder of the address space is unassigned for future use.  This
+   can be used for expansion of existing use (e.g., additional provider
+   addresses, etc.) or new uses (e.g., separate locators and
+   identifiers).  Fifteen percent of the address space is initially
+
+
+
+Hinden & Deering            Standards Track                     [Page 6]
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+   allocated.  The remaining 85% is reserved for future use.
+
+   Unicast addresses are distinguished from multicast addresses by the
+   value of the high-order octet of the addresses: a value of FF
+   (11111111) identifies an address as a multicast address; any other
+   value identifies an address as a unicast address.  Anycast addresses
+   are taken from the unicast address space, and are not syntactically
+   distinguishable from unicast addresses.
+
+
+   2.4 Unicast Addresses
+
+   The IPv6 unicast address is contiguous bit-wise maskable, similar to
+   IPv4 addresses under Class-less Interdomain Routing [CIDR].
+
+   There are several forms of unicast address assignment in IPv6,
+   including the global provider based unicast address, the geographic
+   based unicast address, the NSAP address, the IPX hierarchical
+   address, the site-local-use address, the link-local-use address, and
+   the IPv4-capable host address.  Additional address types can be
+   defined in the future.
+
+   IPv6 nodes may have considerable or little knowledge of the internal
+   structure of the IPv6 address, depending on the role the node plays
+   (for instance, host versus router).  At a minimum, a node may
+   consider that unicast addresses (including its own) have no internal
+   structure:
+
+    |                           128 bits                              |
+    +-----------------------------------------------------------------+
+    |                          node address                           |
+    +-----------------------------------------------------------------+
+
+
+   A slightly sophisticated host (but still rather simple) may
+   additionally be aware of subnet prefix(es) for the link(s) it is
+   attached to, where different addresses may have different values for
+   n:
+
+    |                         n bits                 |   128-n bits   |
+    +------------------------------------------------+----------------+
+    |                   subnet prefix                | interface ID   |
+    +------------------------------------------------+----------------+
+
+
+   Still more sophisticated hosts may be aware of other hierarchical
+   boundaries in the unicast address.  Though a very simple router may
+   have no knowledge of the internal structure of IPv6 unicast
+
+
+
+Hinden & Deering            Standards Track                     [Page 7]
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+   addresses, routers will more generally have knowledge of one or more
+   of the hierarchical boundaries for the operation of routing
+   protocols.  The known boundaries will differ from router to router,
+   depending on what positions the router holds in the routing
+   hierarchy.
+
+
+   2.4.1 Unicast Address Examples
+
+   An example of a Unicast address format which will likely be common on
+   LANs and other environments where IEEE 802 MAC addresses are
+   available is:
+
+
+    |              n bits            | 80-n bits |     48 bits        |
+    +--------------------------------+-----------+--------------------+
+    |        subscriber prefix       | subnet ID |   interface ID     |
+    +--------------------------------+-----------+--------------------+
+
+   Where the 48-bit Interface ID is an IEEE-802 MAC address.  The use of
+   IEEE 802 MAC addresses as a interface ID is expected to be very
+   common in environments where nodes have an IEEE 802 MAC address.  In
+   other environments, where IEEE 802 MAC addresses are not available,
+   other types of link layer addresses can be used, such as E.164
+   addresses, for the interface ID.
+
+   The inclusion of a unique global interface identifier, such as an
+   IEEE MAC address, makes possible a very simple form of auto-
+   configuration of addresses.  A node may discover a subnet ID by
+   listening to Router Advertisement messages sent by a router on its
+   attached link(s), and then fabricating an IPv6 address for itself by
+   using its IEEE MAC address as the interface ID on that subnet.
+
+   Another unicast address format example is where a site or
+   organization requires additional layers of internal hierarchy.  In
+   this example the subnet ID is divided into an area ID and a subnet
+   ID.  Its format is:
+
+    |         s bits       | n bits  |   m bits     | 128-s-n-m bits  |
+    +----------------------+---------+--------------+-----------------+
+    |   subscriber prefix  | area ID |  subnet ID   |  interface ID   |
+    +----------------------+---------+--------------+-----------------+
+
+   This technique can be continued to allow a site or organization to
+   add additional layers of internal hierarchy.  It may be desirable to
+   use an interface ID smaller than a 48-bit IEEE 802 MAC address to
+   allow more space for the additional layers of internal hierarchy.
+   These could be interface IDs which are administratively created by
+
+
+
+Hinden & Deering            Standards Track                     [Page 8]
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+   the site or organization.
+
+
+   2.4.2 The Unspecified Address
+
+   The address 0:0:0:0:0:0:0:0 is called the unspecified address.  It
+   must never be assigned to any node.  It indicates the absence of an
+   address.  One example of its use is in the Source Address field of
+   any IPv6 datagrams sent by an initializing host before it has learned
+   its own address.
+
+   The unspecified address must not be used as the destination address
+   of IPv6 datagrams or in IPv6 Routing Headers.
+
+
+   2.4.3 The Loopback Address
+
+   The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
+   It may be used by a node to send an IPv6 datagram to itself.  It may
+   never be assigned to any interface.
+
+   The loopback address must not be used as the source address in IPv6
+   datagrams that are sent outside of a single node.  An IPv6 datagram
+   with a destination address of loopback must never be sent outside of
+   a single node.
+
+
+   2.4.4 IPv6 Addresses with Embedded IPv4 Addresses
+
+   The IPv6 transition mechanisms include a technique for hosts and
+   routers to dynamically tunnel IPv6 packets over IPv4 routing
+   infrastructure.  IPv6 nodes that utilize this technique are assigned
+   special IPv6 unicast addresses that carry an IPv4 address in the
+   low-order 32-bits.  This type of address is termed an "IPv4-
+   compatible IPv6 address" and has the format:
+
+
+    |                80 bits               | 16 |      32 bits        |
+    +--------------------------------------+--------------------------+
+    |0000..............................0000|0000|    IPv4 address     |
+    +--------------------------------------+----+---------------------+
+
+
+   A second type of IPv6 address which holds an embedded IPv4 address is
+   also defined.  This address is used to represent the addresses of
+   IPv4-only nodes (those that *do not* support IPv6) as IPv6 addresses.
+   This type of address is termed an "IPv4-mapped IPv6 address" and has
+   the format:
+
+
+
+Hinden & Deering            Standards Track                     [Page 9]
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+
+    |                80 bits               | 16 |      32 bits        |
+    +--------------------------------------+--------------------------+
+    |0000..............................0000|FFFF|    IPv4 address     |
+    +--------------------------------------+----+---------------------+
+
+
+
+   2.4.5 NSAP Addresses
+
+   This mapping of NSAP address into IPv6 addresses is as follows:
+
+
+    |   7   |                   121 bits                              |
+    +-------+---------------------------------------------------------+
+    |0000001|                 to be defined                           |
+    +-------+---------------------------------------------------------+
+
+   The draft definition, motivation, and usage are under study [NSAP].
+
+
+   2.4.6 IPX Addresses
+
+   This mapping of IPX address into IPv6 addresses is as follows:
+
+
+    |   7   |                   121 bits                              |
+    +-------+---------------------------------------------------------+
+    |0000010|                 to be defined                           |
+    +-------+---------------------------------------------------------+
+
+   The draft definition, motivation, and usage are under study.
+
+
+   2.4.7 Provider-Based Global Unicast Addresses
+
+   The global provider-based unicast address is assigned as described in
+   [ALLOC].  This initial assignment plan for these unicast addresses is
+   similar to assignment of IPv4 addresses under the CIDR scheme [CIDR].
+   The IPv6 global provider-based unicast address format is as follows:
+
+
+    | 3 |  n bits   |  m bits   |   o bits    |   125-n-m-o bits   |
+    +---+-----------+-----------+-------------+--------------------+
+    |010|registry ID|provider ID|subscriber ID|  intra-subscriber  |
+    +---+-----------+-----------+-------------+--------------------+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 10]
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+   The high-order part of the address is assigned to registries, who
+   then assign portions of the address space to providers, who then
+   assign portions of the address space to subscribers, etc.
+
+   The registry ID identifies the registry which assigns the provider
+   portion of the address.  The term "registry prefix" refers to the
+   high-order part of the address up to and including the registry ID.
+
+   The provider ID identifies a specific provider which assigns the
+   subscriber portion of the address.  The term "provider prefix" refers
+   to the high-order part of the address up to and including the
+   provider ID.
+
+   The subscriber ID distinguishes among multiple subscribers attached
+   to the provider identified by the provider ID.  The term "subscriber
+   prefix" refers to the high-order part of the address up to and
+   including the subscriber ID.
+
+   The intra-subscriber portion of the address is defined by an
+   individual subscriber and is organized according to the subscribers
+   local internet topology.  It is likely that many subscribers will
+   choose to divide the intra-subscriber portion of the address into a
+   subnet ID and an interface ID.  In this case the subnet ID identifies
+   a specific physical link and the interface ID identifies a single
+   interface on that subnet.
+
+
+   2.4.8 Local-use IPv6 Unicast Addresses
+
+   There are two types of local-use unicast addresses defined.  These
+   are Link-Local and Site-Local.  The Link-Local is for use on a single
+   link and the Site-Local is for use in a single site.  Link-Local
+   addresses have the following format:
+
+    |   10     |
+    |  bits    |        n bits           |       118-n bits           |
+    +----------+-------------------------+----------------------------+
+    |1111111010|           0             |       interface ID         |
+    +----------+-------------------------+----------------------------+
+
+   Link-Local addresses are designed to be used for addressing on a
+   single link for purposes such as auto-address configuration, neighbor
+   discovery, or when no routers are present.
+
+   Routers MUST not forward any packets with link-local source
+   addresses.
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 11]
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+   Site-Local addresses have the following format:
+
+    |   10     |
+    |  bits    | n bits  |    m bits     |       118-n-m bits         |
+    +----------+---------+---------------+----------------------------+
+    |1111111011|    0    |   subnet ID   |       interface ID         |
+    +----------+---------+---------------+----------------------------+
+
+
+   Site-Local addresses may be used for sites or organizations that are
+   not (yet) connected to the global Internet.  They do not need to
+   request or "steal" an address prefix from the global Internet address
+   space.  IPv6 site-local addresses can be used instead.  When the
+   organization connects to the global Internet, it can then form global
+   addresses by replacing the site-local prefix with a subscriber
+   prefix.
+
+   Routers MUST not forward any packets with site-local source addresses
+   outside of the site.
+
+   2.5 Anycast Addresses
+
+   An IPv6 anycast address is an address that is assigned to more than
+   one interface (typically belonging to different nodes), with the
+   property that a packet sent to an anycast address is routed to the
+   "nearest" interface having that address, according to the routing
+   protocols' measure of distance.
+
+   Anycast addresses are allocated from the unicast address space, using
+   any of the defined unicast address formats.  Thus, anycast addresses
+   are syntactically indistinguishable from unicast addresses.  When a
+   unicast address is assigned to more than one interface, thus turning
+   it into an anycast address, the nodes to which the address is
+   assigned must be explicitly configured to know that it is an anycast
+   address.
+
+   For any assigned anycast address, there is a longest address prefix P
+   that identifies the topological region in which all interfaces
+   belonging to that anycast address reside.  Within the region
+   identified by P, each member of the anycast set must be advertised as
+   a separate entry in the routing system (commonly referred to as a
+   "host route"); outside the region identified by P, the anycast
+   address may be aggregated into the routing advertisement for prefix
+   P.
+
+   Note that in, the worst case, the prefix P of an anycast set may be
+   the null prefix, i.e., the members of the set may have no topological
+   locality.  In that case, the anycast address must be advertised as a
+
+
+
+Hinden & Deering            Standards Track                    [Page 12]
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+   separate routing entry throughout the entire internet, which presents
+   a severe scaling limit on how many such "global" anycast sets may be
+   supported.  Therefore, it is expected that support for global anycast
+   sets may be unavailable or very restricted.
+
+   One expected use of anycast addresses is to identify the set of
+   routers belonging to an internet service provider.  Such addresses
+   could be used as intermediate addresses in an IPv6 Routing header, to
+   cause a packet to be delivered via a particular provider or sequence
+   of providers.  Some other possible uses are to identify the set of
+   routers attached to a particular subnet, or the set of routers
+   providing entry into a particular routing domain.
+
+   There is little experience with widespread, arbitrary use of internet
+   anycast addresses, and some known complications and hazards when
+   using them in their full generality [ANYCST].  Until more experience
+   has been gained and solutions agreed upon for those problems, the
+   following restrictions are imposed on IPv6 anycast addresses:
+
+      o An anycast address MUST NOT be used as the source address of an
+        IPv6 packet.
+
+      o An anycast address MUST NOT be assigned to an IPv6 host, that
+        is, it may be assigned to an IPv6 router only.
+
+
+   2.5.1 Required Anycast Address
+
+   The Subnet-Router anycast address is predefined.  It's format is as
+   follows:
+
+
+    |                         n bits                 |   128-n bits   |
+    +------------------------------------------------+----------------+
+    |                   subnet prefix                | 00000000000000 |
+    +------------------------------------------------+----------------+
+
+
+   The "subnet prefix" in an anycast address is the prefix which
+   identifies a specific link.  This anycast address is syntactically
+   the same as a unicast address for an interface on the link with the
+   interface identifier set to zero.
+
+   Packets sent to the Subnet-Router anycast address will be delivered
+   to one router on the subnet.  All routers are required to support the
+   Subnet-Router anycast addresses for the subnets which they have
+   interfaces.
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 13]
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+   The subnet-router anycast address is intended to be used for
+   applications where a node needs to communicate with one of a set of
+   routers on a remote subnet.  For example when a mobile host needs to
+   communicate with one of the mobile agents on it's "home" subnet.
+
+
+   2.6 Multicast Addresses
+
+   An IPv6 multicast address is an identifier for a group of nodes.  A
+   node may belong to any number of multicast groups.  Multicast
+   addresses have the following format:
+
+    |   8    |  4 |  4 |                  112 bits                   |
+    +------ -+----+----+---------------------------------------------+
+    |11111111|flgs|scop|                  group ID                   |
+    +--------+----+----+---------------------------------------------+
+
+        11111111 at the start of the address identifies the address as
+        being a multicast address.
+
+                                      +-+-+-+-+
+        flgs is a set of 4 flags:     |0|0|0|T|
+                                      +-+-+-+-+
+
+             The high-order 3 flags are reserved, and must be
+             initialized to 0.
+
+             T = 0 indicates a permanently-assigned ("well-known")
+             multicast address, assigned by the global internet
+             numbering authority.
+
+             T = 1 indicates a non-permanently-assigned ("transient")
+             multicast address.
+
+        scop is a 4-bit multicast scope value used to limit the scope of
+        the multicast group.  The values are:
+
+             0  reserved
+             1  node-local scope
+             2  link-local scope
+             3  (unassigned)
+             4  (unassigned)
+             5  site-local scope
+             6  (unassigned)
+             7  (unassigned)
+             8  organization-local scope
+             9  (unassigned)
+             A  (unassigned)
+
+
+
+Hinden & Deering            Standards Track                    [Page 14]
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+             B  (unassigned)
+             C  (unassigned)
+             D  (unassigned)
+             E  global scope
+             F  reserved
+
+        group ID identifies the multicast group, either permanent or
+        transient, within the given scope.
+
+   The "meaning" of a permanently-assigned multicast address is
+   independent of the scope value.  For example, if the "NTP servers
+   group" is assigned a permanent multicast address with a group ID of
+   43 (hex), then:
+
+        FF01:0:0:0:0:0:0:43 means all NTP servers on the same node as
+        the sender.
+
+        FF02:0:0:0:0:0:0:43 means all NTP servers on the same link as
+        the sender.
+
+        FF05:0:0:0:0:0:0:43 means all NTP servers at the same site as
+        the sender.
+
+        FF0E:0:0:0:0:0:0:43 means all NTP servers in the internet.
+
+   Non-permanently-assigned multicast addresses are meaningful only
+   within a given scope.  For example, a group identified by the non-
+   permanent, site-local multicast address FF15:0:0:0:0:0:0:43 at one
+   site bears no relationship to a group using the same address at a
+   different site, nor to a non-permanent group using the same group ID
+   with different scope, nor to a permanent group with the same group
+   ID.
+
+   Multicast addresses must not be used as source addresses in IPv6
+   datagrams or appear in any routing header.
+
+
+   2.6.1 Pre-Defined Multicast Addresses
+
+   The following well-known multicast addresses are pre-defined:
+
+        Reserved Multicast Addresses:   FF00:0:0:0:0:0:0:0
+                                        FF01:0:0:0:0:0:0:0
+                                        FF02:0:0:0:0:0:0:0
+                                        FF03:0:0:0:0:0:0:0
+                                        FF04:0:0:0:0:0:0:0
+                                        FF05:0:0:0:0:0:0:0
+                                        FF06:0:0:0:0:0:0:0
+
+
+
+Hinden & Deering            Standards Track                    [Page 15]
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+                                        FF07:0:0:0:0:0:0:0
+                                        FF08:0:0:0:0:0:0:0
+                                        FF09:0:0:0:0:0:0:0
+                                        FF0A:0:0:0:0:0:0:0
+                                        FF0B:0:0:0:0:0:0:0
+                                        FF0C:0:0:0:0:0:0:0
+                                        FF0D:0:0:0:0:0:0:0
+                                        FF0E:0:0:0:0:0:0:0
+                                        FF0F:0:0:0:0:0:0:0
+
+   The above multicast addresses are reserved and shall never be
+   assigned to any multicast group.
+
+        All Nodes Addresses:    FF01:0:0:0:0:0:0:1
+                                FF02:0:0:0:0:0:0:1
+
+   The above multicast addresses identify the group of all IPv6 nodes,
+   within scope 1 (node-local) or 2 (link-local).
+
+        All Routers Addresses:   FF01:0:0:0:0:0:0:2
+                                 FF02:0:0:0:0:0:0:2
+
+   The above multicast addresses identify the group of all IPv6 routers,
+   within scope 1 (node-local) or 2 (link-local).
+
+        DHCP Server/Relay-Agent: FF02:0:0:0:0:0:0:C
+
+   The above multicast addresses identify the group of all IPv6 DHCP
+   Servers and Relay Agents within scope 2 (link-local).
+
+        Solicited-Node Address:  FF02:0:0:0:0:1:XXXX:XXXX
+
+   The above multicast address is computed as a function of a node's
+   unicast and anycast addresses.  The solicited-node multicast address
+   is formed by taking the low-order 32 bits of the address (unicast or
+   anycast) and appending those bits to the 96-bit prefix FF02:0:0:0:0:1
+   resulting in a multicast address in the range
+
+           FF02:0:0:0:0:1:0000:0000
+
+   to
+
+           FF02:0:0:0:0:1:FFFF:FFFF
+
+   For example, the solicited node multicast address corresponding to
+   the IPv6 address 4037::01:800:200E:8C6C is FF02::1:200E:8C6C.  IPv6
+   addresses that differ only in the high-order bits, e.g., due to
+   multiple high-order prefixes associated with different providers,
+
+
+
+Hinden & Deering            Standards Track                    [Page 16]
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+   will map to the same solicited-node address thereby reducing the
+   number of multicast addresses a node must join.
+
+   A node is required to compute and support a Solicited-Node multicast
+   addresses for every unicast and anycast address it is assigned.
+
+   2.7 A Node's Required Addresses
+
+   A host is required to recognize the following addresses as
+   identifying itself:
+
+      o Its Link-Local Address for each interface
+      o Assigned Unicast Addresses
+      o Loopback Address
+      o All-Nodes Multicast Address
+      o Solicited-Node Multicast Address for each of its assigned
+        unicast and anycast addresses
+      o Multicast Addresses of all other groups which the host belongs.
+
+   A router is required to recognize the following addresses as
+   identifying itself:
+
+      o Its Link-Local Address for each interface
+      o Assigned Unicast Addresses
+      o Loopback Address
+      o The Subnet-Router anycast addresses for the links it has
+        interfaces.
+      o All other Anycast addresses with which the router has been
+        configured.
+      o All-Nodes Multicast Address
+      o All-Router Multicast Address
+      o Solicited-Node Multicast Address for each of its assigned
+        unicast and anycast addresses
+      o Multicast Addresses of all other groups which the router
+        belongs.
+
+   The only address prefixes which should be predefined in an
+   implementation are the:
+
+      o Unspecified Address
+      o Loopback Address
+      o Multicast Prefix (FF)
+      o Local-Use Prefixes (Link-Local and Site-Local)
+      o Pre-Defined Multicast Addresses
+      o IPv4-Compatible Prefixes
+
+   Implementations should assume all other addresses are unicast unless
+   specifically configured (e.g., anycast addresses).
+
+
+
+Hinden & Deering            Standards Track                    [Page 17]
+
+RFC 1884              IPv6 Addressing Architecture         December 1995
+
+
+REFERENCES
+
+     [ALLOC] Rekhter, Y., and T. Li, "An Architecture for IPv6 Unicast
+             Address Allocation", RFC 1887, cisco Systems, December
+             1995.
+
+     [ANYCST] Partridge, C., Mendez, T., and W. Milliken, "Host
+             Anycasting Service", RFC 1546, BBN, November 1993.
+
+     [CIDR] Fuller, V., Li, T., Varadhan, K., and J. Yu, "Supernetting:
+             an Address Assignment and Aggregation Strategy", RFC 1338,
+             BARRNet, cisco, Merit, OARnet, June 1992.
+
+     [IPV6] Deering, S., and R. Hinden, Editors, "Internet Protocol,
+             Version 6 (IPv6) Specification", RFC 1883, Xerox PARC,
+             Ipsilon Networks, December 1995.
+
+     [MULT] Deering, S., "Host Extensions for IP multicasting", STD 5,
+             RFC 1112, Stanford University, August 1989.
+
+     [NSAP] Carpenter, B., Editor, "Mechanisms for OSIN SAPs, CLNP and
+             TP over IPv6", Work in Progress.
+
+
+
+SECURITY CONSIDERATIONS
+
+   Security issues are not discussed in this document.
+
+
+DOCUMENT EDITOR'S ADDRESSES
+
+   Robert M. Hinden                     Stephen E. Deering
+   Ipsilon Networks, Inc.               Xerox Palo Alto Research Center
+   2191 E. Bayshore Road, Suite 100     3333 Coyote Hill Road
+   Palo Alto, CA 94303                  Palo Alto, CA 94304
+   USA                                  USA
+
+   Phone: +1 415 846 4604               Phone: +1 415 812 4839
+   Fax:   +1 415 855 1414               Fax:   +1 415 812 4471
+   EMail: hinden@ipsilon.com            EMail: deering@parc.xerox.com
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 18]
+
diff --git a/usr.sbin/named/doc/rfc/rfc1886 b/usr.sbin/named/doc/rfc/rfc1886
new file mode 100644
index 00000000000..9874fddb17a
--- /dev/null
+++ b/usr.sbin/named/doc/rfc/rfc1886
@@ -0,0 +1,268 @@
+
+
+
+
+
+
+Network Working Group                                         S. Thomson
+Request for Comments: 1886                                      Bellcore
+Category: Standards Track                                     C. Huitema
+                                                                   INRIA
+                                                           December 1995
+
+
+                DNS Extensions to support IP version 6
+
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+
+Abstract
+
+   This document defines the changes that need to be made to the Domain
+   Name System to support hosts running IP version 6 (IPv6).  The
+   changes include a new resource record type to store an IPv6 address,
+   a new domain to support lookups based on an IPv6 address, and updated
+   definitions of existing query types that return Internet addresses as
+   part of additional section processing.  The extensions are designed
+   to be compatible with existing applications and, in particular, DNS
+   implementations themselves.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thompson & Huitema          Standards Track                    [Page 1]
+
+RFC 1886                  IPv6 DNS Extensions              December 1995
+
+
+1. INTRODUCTION
+
+   Current support for the storage of Internet addresses in the Domain
+   Name System (DNS)[1,2] cannot easily be extended to support IPv6
+   addresses[3] since applications assume that address queries return
+   32-bit IPv4 addresses only.
+
+   To support the storage of IPv6 addresses we define the following
+   extensions:
+
+      o A new resource record type is defined to map a domain name to an
+        IPv6 address.
+
+      o A new domain is defined to support lookups based on address.
+
+      o Existing queries that perform additional section processing to
+        locate IPv4 addresses are redefined to perform additional
+        section processing on both IPv4 and IPv6 addresses.
+
+   The changes are designed to be compatible with existing software. The
+   existing support for IPv4 addresses is retained. Transition issues
+   related to the co-existence of both IPv4 and IPv6 addresses in DNS
+   are discussed in [4].
+
+
+2. NEW RESOURCE RECORD DEFINITION AND DOMAIN
+
+   A new record type is defined to store a host's IPv6 address. A host
+   that has more than one IPv6 address must have more than one such
+   record.
+
+
+2.1 AAAA record type
+
+   The AAAA resource record type is a new record specific to the
+   Internet class that stores a single IPv6 address.
+
+   The value of the type is 28 (decimal).
+
+
+2.2 AAAA data format
+
+   A 128 bit IPv6 address is encoded in the data portion of an AAAA
+   resource record in network byte order (high-order byte first).
+
+
+
+
+Thompson & Huitema          Standards Track                    [Page 2]
+
+RFC 1886                  IPv6 DNS Extensions              December 1995
+
+
+2.3 AAAA query
+
+   An AAAA query for a specified domain name in the Internet class
+   returns all associated AAAA resource records in the answer section of
+   a response.
+
+   A type AAAA query does not perform additional section processing.
+
+
+2.4 Textual format of AAAA records
+
+   The textual representation of the data portion of the AAAA resource
+   record used in a master database file is the textual representation
+   of a IPv6 address as defined in [3].
+
+
+2.5 IP6.INT Domain
+
+   A special domain is defined to look up a record given an address. The
+   intent of this domain is to provide a way of mapping an IPv6 address
+   to a host name, although it may be used for other purposes as well.
+   The domain is rooted at IP6.INT.
+
+   An IPv6 address is represented as a name in the IP6.INT domain by a
+   sequence of nibbles separated by dots with the suffix ".IP6.INT". The
+   sequence of nibbles is encoded in reverse order, i.e. the low-order
+   nibble is encoded first, followed by the next low-order nibble and so
+   on. Each nibble is represented by a hexadecimal digit. For example,
+   the inverse lookup domain name corresponding to the address
+
+       4321:0:1:2:3:4:567:89ab
+
+   would be
+
+b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.INT.
+
+
+
+3. MODIFICATIONS TO EXISTING QUERY TYPES
+
+   All existing query types that perform type A additional section
+   processing, i.e. name server (NS), mail exchange (MX) and mailbox
+   (MB) query types, must be redefined to perform both type A and type
+   AAAA additional section processing. These new definitions mean that a
+   name server must add any relevant IPv4 addresses and any relevant
+
+
+
+Thompson & Huitema          Standards Track                    [Page 3]
+
+RFC 1886                  IPv6 DNS Extensions              December 1995
+
+
+   IPv6 addresses available locally to the additional section of a
+   response when processing any one of the above queries.
+
+
+4. SECURITY CONSIDERATIONS
+
+   Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thompson & Huitema          Standards Track                    [Page 4]
+
+RFC 1886                  IPv6 DNS Extensions              December 1995
+
+
+5. REFERENCES
+
+
+   [1]  Mockapetris, P., "Domain Names - Concepts and Facilities", STD
+        13, RFC 1034, USC/Information Sciences Institute, November 1987.
+
+   [2]  Mockapetris, P., "Domain Names - Implementation and Specifica-
+        tion", STD 13, RFC 1035, USC/Information Sciences Institute,
+        November 1987.
+
+   [3]  Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing
+        Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December
+        1995.
+
+
+   [4]  Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6
+        Hosts and Routers", Work in Progress.
+
+
+Authors' Addresses
+
+   Susan Thomson
+   Bellcore
+   MRE 2P343
+   445 South Street
+   Morristown, NJ 07960
+   U.S.A.
+
+   Phone: +1 201-829-4514
+   EMail: set@thumper.bellcore.com
+
+
+   Christian Huitema
+   INRIA, Sophia-Antipolis
+   2004 Route des Lucioles
+   BP 109
+   F-06561 Valbonne Cedex
+   France
+
+   Phone: +33 93 65 77 15
+   EMail: Christian.Huitema@MIRSA.INRIA.FR
+
+
+
+
+
+
+
+Thompson & Huitema          Standards Track                    [Page 5]
+
diff --git a/usr.sbin/named/doc/rfc/rfc1912 b/usr.sbin/named/doc/rfc/rfc1912
new file mode 100644
index 00000000000..8ace7d26748
--- /dev/null
+++ b/usr.sbin/named/doc/rfc/rfc1912
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                            D. Barr
+Request for Comments: 1912             The Pennsylvania State University
+Obsoletes: 1537                                            February 1996
+Category: Informational
+
+
+            Common DNS Operational and Configuration Errors
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   This memo describes errors often found in both the operation of
+   Domain Name System (DNS) servers, and in the data that these DNS
+   servers contain.  This memo tries to summarize current Internet
+   requirements as well as common practice in the operation and
+   configuration of the DNS.  This memo also tries to summarize or
+   expand upon issues raised in [RFC 1537].
+
+1. Introduction
+
+   Running a nameserver is not a trivial task.  There are many things
+   that can go wrong, and many decisions have to be made about what data
+   to put in the DNS and how to set up servers.  This memo attempts to
+   address many of the common mistakes and pitfalls that are made in DNS
+   data as well as in the operation of nameservers.  Discussions are
+   also made regarding some other relevant issues such as server or
+   resolver bugs, and a few political issues with respect to the
+   operation of DNS on the Internet.
+
+2. DNS Data
+
+   This section discusses problems people typically have with the DNS
+   data in their nameserver, as found in the zone data files that the
+   nameserver loads into memory.
+
+2.1 Inconsistent, Missing, or Bad Data
+
+   Every Internet-reachable host should have a name.  The consequences
+   of this are becoming more and more obvious.  Many services available
+   on the Internet will not talk to you if you aren't correctly
+   registered in the DNS.
+
+
+
+
+
+Barr                         Informational                      [Page 1]
+
+RFC 1912                   Common DNS Errors               February 1996
+
+
+   Make sure your PTR and A records match.  For every IP address, there
+   should be a matching PTR record in the in-addr.arpa domain.  If a
+   host is multi-homed, (more than one IP address) make sure that all IP
+   addresses have a corresponding PTR record (not just the first one).
+   Failure to have matching PTR and A records can cause loss of Internet
+   services similar to not being registered in the DNS at all.  Also,
+   PTR records must point back to a valid A record, not a alias defined
+   by a CNAME.  It is highly recommended that you use some software
+   which automates this checking, or generate your DNS data from a
+   database which automatically creates consistent data.
+
+   DNS domain names consist of "labels" separated by single dots.  The
+   DNS is very liberal in its rules for the allowable characters in a
+   domain name.  However, if a domain name is used to name a host, it
+   should follow rules restricting host names.  Further if a name is
+   used for mail, it must follow the naming rules for names in mail
+   addresses.
+
+   Allowable characters in a label for a host name are only ASCII
+   letters, digits, and the `-' character.  Labels may not be all
+   numbers, but may have a leading digit  (e.g., 3com.com).  Labels must
+   end and begin only with a letter or digit.  See [RFC 1035] and [RFC
+   1123].  (Labels were initially restricted in [RFC 1035] to start with
+   a letter, and some older hosts still reportedly have problems with
+   the relaxation in [RFC 1123].)  Note there are some Internet
+   hostnames which violate this rule (411.org, 1776.com).  The presence
+   of underscores in a label is allowed in [RFC 1033], except [RFC 1033]
+   is informational only and was not defining a standard.  There is at
+   least one popular TCP/IP implementation which currently refuses to
+   talk to hosts named with underscores in them.  It must be noted that
+   the language in [1035] is such that these rules are voluntary -- they
+   are there for those who wish to minimize problems.  Note that the
+   rules for Internet host names also apply to hosts and addresses used
+   in SMTP (See RFC 821).
+
+   If a domain name is to be used for mail (not involving SMTP), it must
+   follow the rules for mail in [RFC 822], which is actually more
+   liberal than the above rules.  Labels for mail can be any ASCII
+   character except "specials", control characters, and whitespace
+   characters.  "Specials" are specific symbols used in the parsing of
+   addresses.  They are the characters "()<>@,;:\".[]".  (The "!"
+   character wasn't in [RFC 822], however it also shouldn't be used due
+   to the conflict with UUCP mail as defined in RFC 976)  However, since
+   today almost all names which are used for mail on the Internet are
+   also names used for hostnames, one rarely sees addresses using these
+   relaxed standard, but mail software should be made liberal and robust
+   enough to accept them.
+
+
+
+
+Barr                         Informational                      [Page 2]
+
+RFC 1912                   Common DNS Errors               February 1996
+
+
+   You should also be careful to not have addresses which are valid
+   alternate syntaxes to the inet_ntoa() library call.  For example 0xe
+   is a valid name, but if you were to type "telnet 0xe", it would try
+   to connect to IP address 0.0.0.14.  It is also rumored that there
+   exists some broken inet_ntoa() routines that treat an address like
+   x400 as an IP address.
+
+   Certain operating systems have limitations on the length of their own
+   hostname.  While not strictly of issue to the DNS, you should be
+   aware of your operating system's length limits before choosing the
+   name of a host.
+
+   Remember that many resource records (abbreviated RR) take on more
+   than one argument.  HINFO requires two arguments, as does RP.  If you
+   don't supply enough arguments, servers sometime return garbage for
+   the missing fields.  If you need to include whitespace within any
+   data, you must put the string in quotes.
+
+2.2 SOA records
+
+   In the SOA record of every zone, remember to fill in the e-mail
+   address that will get to the person who maintains the DNS at your
+   site (commonly referred to as "hostmaster").  The `@' in the e-mail
+   must be replaced by a `.' first.  Do not try to put an `@' sign in
+   this address.  If the local part of the address already contains a
+   `.' (e.g., John.Smith@widget.xx), then you need to quote the `.' by
+   preceding it with `\' character.  (e.g., to become
+   John\.Smith.widget.xx) Alternately (and preferred), you can just use
+   the generic name `hostmaster', and use a mail alias to redirect it to
+   the appropriate persons.  There exists software which uses this field
+   to automatically generate the e-mail address for the zone contact.
+   This software will break if this field is improperly formatted.  It
+   is imperative that this address get to one or more real persons,
+   because it is often used for everything from reporting bad DNS data
+   to reporting security incidents.
+
+   Even though some BIND versions allow you to use a decimal in a serial
+   number, don't.  A decimal serial number is converted to an unsigned
+   32-bit integer internally anyway.  The formula for a n.m serial
+   number is n*10^(3+int(0.9+log10(m))) + m which translates to
+   something rather unexpected.  For example it's routinely possible
+   with a decimal serial number (perhaps automatically generated by
+   SCCS) to be incremented such that it is numerically larger, but after
+   the above conversion yield a serial number which is LOWER than
+   before.  Decimal serial numbers have been officially deprecated in
+   recent BIND versions.  The recommended syntax is YYYYMMDDnn
+   (YYYY=year, MM=month, DD=day, nn=revision number.  This won't
+   overflow until the year 4294.
+
+
+
+Barr                         Informational                      [Page 3]
+
+RFC 1912                   Common DNS Errors               February 1996
+
+
+   Choose logical values for the timer values in the SOA record (note
+   values below must be expressed as seconds in the zone data):
+
+      Refresh: How often a secondary will poll the primary server to see
+          if the serial number for the zone has increased (so it knows
+          to request a new copy of the data for the zone).  Set this to
+          how long your secondaries can comfortably contain out-of-date
+          data.  You can keep it short (20 mins to 2 hours) if you
+          aren't worried about a small increase in bandwidth used, or
+          longer (2-12 hours) if your Internet connection is slow or is
+          started on demand.  Recent BIND versions (4.9.3) have optional
+          code to automatically notify secondaries that data has
+          changed, allowing you to set this TTL to a long value (one
+          day, or more).
+
+      Retry: If a secondary was unable to contact the primary at the
+          last refresh, wait the retry value before trying again.  This
+          value isn't as important as others, unless the secondary is on
+          a distant network from the primary or the primary is more
+          prone to outages.  It's typically some fraction of the refresh
+          interval.
+
+
+      Expire: How long a secondary will still treat its copy of the zone
+          data as valid if it can't contact the primary.  This value
+          should be greater than how long a major outage would typically
+          last, and must be greater than the minimum and retry
+          intervals, to avoid having a secondary expire the data before
+          it gets a chance to get a new copy.  After a zone is expired a
+          secondary will still continue to try to contact the primary,
+          but it will no longer provide nameservice for the zone.  2-4
+          weeks are suggested values.
+
+      Minimum: The default TTL (time-to-live) for resource records --
+          how long data will remain in other nameservers' cache.  ([RFC
+          1035] defines this to be the minimum value, but servers seem
+          to always implement this as the default value)  This is by far
+          the most important timer.  Set this as large as is comfortable
+          given how often you update your nameserver.  If you plan to
+          make major changes, it's a good idea to turn this value down
+          temporarily beforehand.  Then wait the previous minimum value,
+          make your changes, verify their correctness, and turn this
+          value back up.  1-5 days are typical values.  Remember this
+          value can be overridden on individual resource records.
+
+
+
+
+
+
+
+Barr                         Informational                      [Page 4]
+
+RFC 1912                   Common DNS Errors               February 1996
+
+
+   As you can see, the typical values above for the timers vary widely.
+   Popular documentation like [RFC 1033] recommended a day for the
+   minimum TTL, which is now considered too low except for zones with
+   data that vary regularly.  Once a DNS stabilizes, values on the order
+   of 3 or more days are recommended.  It is also recommended that you
+   individually override the TTL on certain RRs which are often
+   referenced and don't often change to have very large values (1-2
+   weeks).  Good examples of this are the MX, A, and PTR records of your
+   mail host(s), the NS records of your zone, and the A records of your
+   nameservers.
+
+2.3 Glue A Records
+
+   Glue records are A records that are associated with NS records to
+   provide "bootstrapping" information to the nameserver.  For example:
+
+           podunk.xx.      in      ns      ns1.podunk.xx.
+                           in      ns      ns2.podunk.xx.
+           ns1.podunk.xx.  in      a       1.2.3.4
+           ns2.podunk.xx.  in      a       1.2.3.5
+
+   Here, the A records are referred to as "Glue records".
+
+   Glue records are required only in forward zone files for nameservers
+   that are located in the subdomain of the current zone that is being
+   delegated.  You shouldn't have any A records in an in-addr.arpa zone
+   file (unless you're using RFC 1101-style encoding of subnet masks).
+
+   If your nameserver is multi-homed (has more than one IP address), you
+   must list all of its addresses in the glue to avoid cache
+   inconsistency due to differing TTL values, causing some lookups to
+   not find all addresses for your nameserver.
+
+   Some people get in the bad habit of putting in a glue record whenever
+   they add an NS record "just to make sure".  Having duplicate glue
+   records in your zone files just makes it harder when a nameserver
+   moves to a new IP address, or is removed. You'll spend hours trying
+   to figure out why random people still see the old IP address for some
+   host, because someone forgot to change or remove a glue record in
+   some other file.  Newer BIND versions will ignore these extra glue
+   records in local zone files.
+
+   Older BIND versions (4.8.3 and previous) have a problem where it
+   inserts these extra glue records in the zone transfer data to
+   secondaries.  If one of these glues is wrong, the error can be
+   propagated to other nameservers.  If two nameservers are secondaries
+   for other zones of each other, it's possible for one to continually
+   pass old glue records back to the other.  The only way to get rid of
+
+
+
+Barr                         Informational                      [Page 5]
+
+RFC 1912                   Common DNS Errors               February 1996
+
+
+   the old data is to kill both of them, remove the saved backup files,
+   and restart them.  Combined with that those same versions also tend
+   to become infected more easily with bogus data found in other non-
+   secondary nameservers (like the root zone data).
+
+2.4 CNAME records
+
+   A CNAME record is not allowed to coexist with any other data.  In
+   other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you
+   can't also have an MX record for suzy.podunk.edu, or an A record, or
+   even a TXT record.  Especially do not try to combine CNAMEs and NS
+   records like this!:
+
+
+           podunk.xx.      IN      NS      ns1
+                           IN      NS      ns2
+                           IN      CNAME   mary
+           mary            IN      A       1.2.3.4
+
+
+   This is often attempted by inexperienced administrators as an obvious
+   way to allow your domain name to also be a host.  However, DNS
+   servers like BIND will see the CNAME and refuse to add any other
+   resources for that name.  Since no other records are allowed to
+   coexist with a CNAME, the NS entries are ignored.  Therefore all the
+   hosts in the podunk.xx domain are ignored as well!
+
+   If you want to have your domain also be a host, do the following:
+
+           podunk.xx.      IN      NS      ns1
+                           IN      NS      ns2
+                           IN      A       1.2.3.4
+           mary            IN      A       1.2.3.4
+
+   Don't go overboard with CNAMEs.  Use them when renaming hosts, but
+   plan to get rid of them (and inform your users).  However CNAMEs are
+   useful (and encouraged) for generalized names for servers -- `ftp'
+   for your ftp server, `www' for your Web server, `gopher' for your
+   Gopher server, `news' for your Usenet news server, etc.
+
+   Don't forget to delete the CNAMEs associated with a host if you
+   delete the host it is an alias for.  Such "stale CNAMEs" are a waste
+   of resources.
+
+
+
+
+
+
+
+
+Barr                         Informational                      [Page 6]
+
+RFC 1912                   Common DNS Errors               February 1996
+
+
+   Don't use CNAMEs in combination with RRs which point to other names
+   like MX, CNAME, PTR and NS.  (PTR is an exception if you want to
+   implement classless in-addr delegation.)  For example, this is
+   strongly discouraged:
+
+           podunk.xx.      IN      MX      mailhost
+           mailhost        IN      CNAME   mary
+           mary            IN      A       1.2.3.4
+
+
+   [RFC 1034] in section 3.6.2 says this should not be done, and [RFC
+   974] explicitly states that MX records shall not point to an alias
+   defined by a CNAME.  This results in unnecessary indirection in
+   accessing the data, and DNS resolvers and servers need to work more
+   to get the answer.  If you really want to do this, you can accomplish
+   the same thing by using a preprocessor such as m4 on your host files.
+
+   Also, having chained records such as CNAMEs pointing to CNAMEs may
+   make administration issues easier, but is known to tickle bugs in
+   some resolvers that fail to check loops correctly.  As a result some
+   hosts may not be able to resolve such names.
+
+   Having NS records pointing to a CNAME is bad and may conflict badly
+   with current BIND servers.  In fact, current BIND implementations
+   will ignore such records, possibly leading to a lame delegation.
+   There is a certain amount of security checking done in BIND to
+   prevent spoofing DNS NS records.  Also, older BIND servers reportedly
+   will get caught in an infinite query loop trying to figure out the
+   address for the aliased nameserver, causing a continuous stream of
+   DNS requests to be sent.
+
+2.5 MX records
+
+   It is a good idea to give every host an MX record, even if it points
+   to itself!  Some mailers will cache MX records, but will always need
+   to check for an MX before sending mail.  If a site does not have an
+   MX, then every piece of mail may result in one more resolver query,
+   since the answer to the MX query often also contains the IP addresses
+   of the MX hosts.  Internet SMTP mailers are required by [RFC 1123] to
+   support the MX mechanism.
+
+   Put MX records even on hosts that aren't intended to send or receive
+   e-mail.  If there is a security problem involving one of these hosts,
+   some people will mistakenly send mail to postmaster or root at the
+   site without checking first to see if it is a "real" host or just a
+   terminal or personal computer that's not set up to accept e-mail.  If
+   you give it an MX record, then the e-mail can be redirected to a real
+   person.  Otherwise mail can just sit in a queue for hours or days
+
+
+
+Barr                         Informational                      [Page 7]
+
+RFC 1912                   Common DNS Errors               February 1996
+
+
+   until the mailer gives up trying to send it.
+
+   Don't forget that whenever you add an MX record, you need to inform
+   the target mailer if it is to treat the first host as "local".  (The
+   "Cw" flag in sendmail, for example)
+
+   If you add an MX record which points to an external host (e.g., for
+   the purposes of backup mail routing) be sure to ask permission from
+   that site first.  Otherwise that site could get rather upset and take
+   action (like throw your mail away, or appeal to higher authorities
+   like your parent DNS administrator or network provider.)
+
+2.6 Other Resource Records
+
+2.6.1 WKS
+
+   WKS records are deprecated in [RFC 1123].  They serve no known useful
+   function, except internally among LISP machines.  Don't use them.
+
+2.6.2 HINFO
+
+   On the issue HINFO records, some will argue that these is a security
+   problem (by broadcasting what vendor hardware and operating system
+   you so people can run systematic attacks on known vendor security
+   holes).  If you do use them, you should keep up to date with known
+   vendor security problems.  However, they serve a useful purpose.
+   Don't forget that HINFO requires two arguments, the hardware type,
+   and the operating system.
+
+   HINFO is sometimes abused to provide other information.  The record
+   is meant to provide specific information about the machine itself.
+   If you need to express other information about the host in the DNS,
+   use TXT.
+
+2.6.3 TXT
+
+   TXT records have no specific definition.  You can put most anything
+   in them.  Some use it for a generic description of the host, some put
+   specific information like its location, primary user, or maybe even a
+   phone number.
+
+2.6.4 RP
+
+   RP records are relatively new.  They are used to specify an e-mail
+   address (see first paragraph of section 2.2)  of the "Responsible
+   Person" of the host, and the name of a TXT record where you can get
+   more information.  See [RFC 1183].
+
+
+
+
+Barr                         Informational                      [Page 8]
+
+RFC 1912                   Common DNS Errors               February 1996
+
+
+2.7 Wildcard records
+
+   Wildcard MXs are useful mostly for non IP-connected sites.  A common
+   mistake is thinking that a wildcard MX for a zone will apply to all
+   hosts in the zone.  A wildcard MX will apply only to names in the
+   zone which aren't listed in the DNS at all.  e.g.,
+
+           podunk.xx.      IN      NS      ns1
+                           IN      NS      ns2
+           mary            IN      A       1.2.3.4
+           *.podunk.xx.    IN      MX      5 sue
+
+   Mail for mary.podunk.xx will be sent to itself for delivery.  Only
+   mail for jane.podunk.xx or any hosts you don't see above will be sent
+   to the MX.  For most Internet sites, wildcard MX records are not
+   useful.  You need to put explicit MX records on every host.
+
+   Wildcard MXs can be bad, because they make some operations succeed
+   when they should fail instead.  Consider the case where someone in
+   the domain "widget.com" tries to send mail to "joe@larry".  If the
+   host "larry" doesn't actually exist, the mail should in fact bounce
+   immediately.  But because of domain searching the address gets
+   resolved to "larry.widget.com", and because of the wildcard MX this
+   is a valid address according to DNS.  Or perhaps someone simply made
+   a typo in the hostname portion of the address.  The mail message then
+   gets routed to the mail host, which then rejects the mail with
+   strange error messages like "I refuse to talk to myself" or "Local
+   configuration error".
+
+   Wildcard MX records are good for when you have a large number of
+   hosts which are not directly Internet-connected (for example, behind
+   a firewall) and for administrative or political reasons it is too
+   difficult to have individual MX records for every host, or to force
+   all e-mail addresses to be "hidden" behind one or more domain names.
+   In that case, you must divide your DNS into two parts, an internal
+   DNS, and an external DNS.  The external DNS will have only a few
+   hosts and explicit MX records, and one or more wildcard MXs for each
+   internal domain.  Internally the DNS will be complete, with all
+   explicit MX records and no wildcards.
+
+   Wildcard As and CNAMEs are possible too, and are really confusing to
+   users, and a potential nightmare if used without thinking first.  It
+   could result (due again to domain searching) in any telnet/ftp
+   attempts from within the domain to unknown hosts to be directed to
+   one address.  One such wildcard CNAME (in *.edu.com) caused
+   Internet-wide loss of services and potential security nightmares due
+   to unexpected interactions with domain searching.  It resulted in
+   swift fixes, and even an RFC ([RFC 1535]) documenting the problem.
+
+
+
+Barr                         Informational                      [Page 9]
+
+RFC 1912                   Common DNS Errors               February 1996
+
+
+2.8 Authority and Delegation Errors (NS records)
+
+   You are required to have at least two nameservers for every domain,
+   though more is preferred.  Have secondaries outside your network.  If
+   the secondary isn't under your control, periodically check up on them
+   and make sure they're getting current zone data from you.  Queries to
+   their nameserver about your hosts should always result in an
+   "authoritative" response.  If not, this is called a "lame
+   delegation".  A lame delegations exists when a nameserver is
+   delegated responsibility for providing nameservice for a zone (via NS
+   records) but is not performing nameservice for that zone (usually
+   because it is not set up as a primary or secondary for the zone).
+
+   The "classic" lame delegation can be illustrated in this example:
+
+           podunk.xx.      IN      NS      ns1.podunk.xx.
+                           IN      NS      ns0.widget.com.
+
+   "podunk.xx" is a new domain which has recently been created, and
+   "ns1.podunk.xx" has been set up to perform nameservice for the zone.
+   They haven't quite finished everything yet and haven't made sure that
+   the hostmaster at "ns0.widget.com" has set up to be a proper
+   secondary, and thus has no information about the podunk.xx domain,
+   even though the DNS says it is supposed to.  Various things can
+   happen depending on which nameserver is used.  At best, extra DNS
+   traffic will result from a lame delegation.  At worst, you can get
+   unresolved hosts and bounced e-mail.
+
+   Also, sometimes a nameserver is moved to another host or removed from
+   the list of secondaries.  Unfortunately due to caching of NS records,
+   many sites will still think that a host is a secondary after that
+   host has stopped providing nameservice.  In order to prevent lame
+   delegations while the cache is being aged, continue to provide
+   nameservice on the old nameserver for the length of the maximum of
+   the minimum plus refresh times for the zone and the parent zone.
+   (See section 2.2)
+
+   Whenever a primary or secondary is removed or changed, it takes a
+   fair amount of human coordination among the parties involved.  (The
+   site itself, it's parent, and the site hosting the secondary)  When a
+   primary moves, make sure all secondaries have their named.boot files
+   updated and their servers reloaded.  When a secondary moves, make
+   sure the address records at both the primary and parent level are
+   changed.
+
+   It's also been reported that some distant sites like to pick popular
+   nameservers like "ns.uu.net" and just add it to their list of NS
+   records in hopes that they will magically perform additional
+
+
+
+Barr                         Informational                     [Page 10]
+
+RFC 1912                   Common DNS Errors               February 1996
+
+
+   nameservice for them.  This is an even worse form of lame delegation,
+   since this adds traffic to an already busy nameserver.  Please
+   contact the hostmasters of sites which have lame delegations.
+   Various tools can be used to detect or actively find lame
+   delegations.  See the list of contributed software in the BIND
+   distribution.
+
+   Make sure your parent domain has the same NS records for your zone as
+   you do.  (Don't forget your in-addr.arpa zones too!).  Do not list
+   too many (7 is the recommended maximum), as this just makes things
+   harder to manage and is only really necessary for very popular top-
+   level or root zones.  You also run the risk of overflowing the 512-
+   byte limit of a UDP packet in the response to an NS query.  If this
+   happens, resolvers will "fall back" to using TCP requests, resulting
+   in increased load on your nameserver.
+
+   It's important when picking geographic locations for secondary
+   nameservers to minimize latency as well as increase reliability.
+   Keep in mind network topologies.  For example if your site is on the
+   other end of a slow local or international link, consider a secondary
+   on the other side of the link to decrease average latency.  Contact
+   your Internet service provider or parent domain contact for more
+   information about secondaries which may be available to you.
+
+3. BIND operation
+
+   This section discusses common problems people have in the actual
+   operation of the nameserver (specifically, BIND).  Not only must the
+   data be correct as explained above, but the nameserver must be
+   operated correctly for the data to be made available.
+
+3.1 Serial numbers
+
+   Each zone has a serial number associated with it.  Its use is for
+   keeping track of who has the most current data.  If and only if the
+   primary's serial number of the zone is greater will the secondary ask
+   the primary for a copy of the new zone data (see special case below).
+
+   Don't forget to change the serial number when you change data!  If
+   you don't, your secondaries will not transfer the new zone
+   information.  Automating the incrementing of the serial number with
+   software is also a good idea.
+
+   If you make a mistake and increment the serial number too high, and
+   you want to reset the serial number to a lower value, use the
+   following procedure:
+
+
+
+
+
+Barr                         Informational                     [Page 11]
+
+RFC 1912                   Common DNS Errors               February 1996
+
+
+      Take the `incorrect' serial number and add 2147483647 to it.  If
+      the number exceeds 4294967296, subtract 4294967296.  Load the
+      resulting number.  Then wait 2 refresh periods to allow the zone
+      to propagate to all servers.
+
+      Repeat above until the resulting serial number is less than the
+      target serial number.
+
+      Up the serial number to the target serial number.
+
+   This procedure won't work if one of your secondaries is running an
+   old version of BIND (4.8.3 or earlier).  In this case you'll have to
+   contact the hostmaster for that secondary and have them kill the
+   secondary servers, remove the saved backup file, and restart the
+   server.  Be careful when editing the serial number -- DNS admins
+   don't like to kill and restart nameservers because you lose all that
+   cached data.
+
+3.2 Zone file style guide
+
+   Here are some useful tips in structuring your zone files.  Following
+   these will help you spot mistakes, and avoid making more.
+
+   Be consistent with the style of entries in your DNS files. If your
+   $ORIGIN is podunk.xx., try not to write entries like:
+
+           mary            IN      A       1.2.3.1
+           sue.podunk.xx.  IN      A       1.2.3.2
+
+   or:
+
+           bobbi           IN      A       1.2.3.2
+                           IN      MX      mary.podunk.xx.
+
+
+   Either use all FQDNs (Fully Qualified Domain Names) everywhere or
+   used unqualified names everywhere.  Or have FQDNs all on the right-
+   hand side but unqualified names on the left.  Above all, be
+   consistent.
+
+   Use tabs between fields, and try to keep columns lined up.  It makes
+   it easier to spot missing fields (note some fields such as "IN" are
+   inherited from the previous record and may be left out in certain
+   circumstances.)
+
+
+
+
+
+
+
+Barr                         Informational                     [Page 12]
+
+RFC 1912                   Common DNS Errors               February 1996
+
+
+   Remember you don't need to repeat the name of the host when you are
+   defining multiple records for one host.  Be sure also to keep all
+   records associated with a host together in the file.  It will make
+   things more straightforward when it comes time to remove or rename a
+   host.
+
+   Always remember your $ORIGIN.  If you don't put a `.' at the end of
+   an FQDN, it's not recognized as an FQDN.  If it is not an FQDN, then
+   the nameserver will append $ORIGIN to the name.  Double check, triple
+   check, those trailing dots, especially in in-addr.arpa zone files,
+   where they are needed the most.
+
+   Be careful with the syntax of the SOA and WKS records (the records
+   which use parentheses).  BIND is not very flexible in how it parses
+   these records.  See the documentation for BIND.
+
+3.3 Verifying data
+
+   Verify the data you just entered or changed by querying the resolver
+   with dig (or your favorite DNS tool, many are included in the BIND
+   distribution) after a change.  A few seconds spent double checking
+   can save hours of trouble, lost mail, and general headaches.  Also be
+   sure to check syslog output when you reload the nameserver.  If you
+   have grievous errors in your DNS data or boot file, named will report
+   it via syslog.
+
+   It is also highly recommended that you automate this checking, either
+   with software which runs sanity checks on the data files before they
+   are loaded into the nameserver, or with software which checks the
+   data already loaded in the nameserver.  Some contributed software to
+   do this is included in the BIND distribution.
+
+4. Miscellaneous Topics
+
+4.1 Boot file setup
+
+   Certain zones should always be present in nameserver configurations:
+
+           primary         localhost               localhost
+           primary         0.0.127.in-addr.arpa    127.0
+           primary         255.in-addr.arpa        255
+           primary         0.in-addr.arpa          0
+
+   These are set up to either provide nameservice for "special"
+   addresses, or to help eliminate accidental queries for broadcast or
+   local address to be sent off to the root nameservers.  All of these
+   files will contain NS and SOA records just like the other zone files
+   you maintain, the exception being that you can probably make the SOA
+
+
+
+Barr                         Informational                     [Page 13]
+
+RFC 1912                   Common DNS Errors               February 1996
+
+
+   timers very long, since this data will never change.
+
+   The "localhost" address is a "special" address which always refers to
+   the local host.  It should contain the following line:
+
+           localhost.      IN      A       127.0.0.1
+
+   The "127.0" file should contain the line:
+
+           1    PTR     localhost.
+
+   There has been some extensive discussion about whether or not to
+   append the local domain to it.  The conclusion is that "localhost."
+   would be the best solution.  The reasons given include:
+
+      "localhost" by itself is used and expected to work in some
+      systems.
+
+      Translating 127.0.0.1 into "localhost.dom.ain" can cause some
+      software to connect back to the loopback interface when it didn't
+      want to because "localhost" is not equal to "localhost.dom.ain".
+
+   The "255" and "0" files should not contain any additional data beyond
+   the NS and SOA records.
+
+   Note that future BIND versions may include all or some of this data
+   automatically without additional configuration.
+
+4.2 Other Resolver and Server bugs
+
+   Very old versions of the DNS resolver have a bug that cause queries
+   for names that look like IP addresses to go out, because the user
+   supplied an IP address and the software didn't realize that it didn't
+   need to be resolved.  This has been fixed but occasionally it still
+   pops up.  It's important because this bug means that these queries
+   will be sent directly to the root nameservers, adding to an already
+   heavy DNS load.
+
+   While running a secondary nameserver off another secondary nameserver
+   is possible, it is not recommended unless necessary due to network
+   topologies.  There are known cases where it has led to problems like
+   bogus TTL values.  While this may be caused by older or flawed DNS
+   implementations, you should not chain secondaries off of one another
+   since this builds up additional reliability dependencies as well as
+   adds additional delays in updates of new zone data.
+
+
+
+
+
+
+Barr                         Informational                     [Page 14]
+
+RFC 1912                   Common DNS Errors               February 1996
+
+
+4.3 Server issues
+
+   DNS operates primarily via UDP (User Datagram Protocol) messages.
+   Some UNIX operating systems, in an effort to save CPU cycles, run
+   with UDP checksums turned off.  The relative merits of this have long
+   been debated.  However, with the increase in CPU speeds, the
+   performance considerations become less and less important.  It is
+   strongly encouraged that you turn on UDP checksumming to avoid
+   corrupted data not only with DNS but with other services that use UDP
+   (like NFS).  Check with your operating system documentation to verify
+   that UDP checksumming is enabled.
+
+References
+
+   [RFC 974] Partridge, C., "Mail routing and the domain system", STD
+              14, RFC 974, CSNET CIC BBN Laboratories Inc, January 1986.
+
+   [RFC 1033] Lottor, M, "Domain Administrators Operations Guide", RFC
+              1033, USC/Information Sciences Institute, November 1987.
+
+   [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
+              STD 13, RFC 1034, USC/Information Sciences Institute,
+              November 1987.
+
+   [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
+              Specification", STD 13, RFC 1035, USC/Information Sciences
+              Institute, November 1987.
+
+   [RFC 1123] Braden, R., "Requirements for Internet Hosts --
+              Application and Support", STD 3, RFC 1123, IETF, October
+              1989.
+
+   [RFC 1178] Libes, D., "Choosing a Name for Your Computer", FYI 5, RFC
+              1178, Integrated Systems Group/NIST, August 1990.
+
+   [RFC 1183] Ullman, R., Mockapetris, P., Mamakos, L, and C. Everhart,
+              "New DNS RR Definitions", RFC 1183, October 1990.
+
+   [RFC 1535] Gavron, E., "A Security Problem and Proposed Correction
+              With Widely Deployed DNS Software", RFC 1535, ACES
+              Research Inc., October 1993.
+
+   [RFC 1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S.
+              Miller, "Common DNS Implementation Errors and Suggested
+              Fixes", RFC 1536, USC/Information Sciences Institute, USC,
+              October 1993.
+
+
+
+
+
+Barr                         Informational                     [Page 15]
+
+RFC 1912                   Common DNS Errors               February 1996
+
+
+   [RFC 1537] Beertema, P., "Common DNS Data File Configuration Errors",
+              RFC 1537, CWI, October 1993.
+
+   [RFC 1713] A. Romao, "Tools for DNS debugging", RFC 1713, FCCN,
+              November 1994.
+
+   [BOG] Vixie, P, et. al., "Name Server Operations Guide for BIND",
+              Vixie Enterprises, July 1994.
+
+5. Security Considerations
+
+   Security issues are not discussed in this memo.
+
+6. Author's Address
+
+   David Barr
+   The Pennsylvania State University
+   Department of Mathematics
+   334 Whitmore Building
+   University Park, PA 16802
+
+   Voice: +1 814 863 7374
+   Fax: +1 814 863-8311
+   EMail: barr@math.psu.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barr                         Informational                     [Page 16]
+
diff --git a/usr.sbin/named/doc/rfc/rfc1995 b/usr.sbin/named/doc/rfc/rfc1995
new file mode 100644
index 00000000000..b50bdc60487
--- /dev/null
+++ b/usr.sbin/named/doc/rfc/rfc1995
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                            M. Ohta
+Request for Comments: 1995                 Tokyo Institute of Technology
+Updates: 1035                                                August 1996
+Category: Standards Track
+
+
+                    Incremental Zone Transfer in DNS
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+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
+
+   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.
+
+
+
+
+
+Ohta                        Standards Track                     [Page 1]
+
+RFC 1995            Incremental Zone Transfer in DNS         August 1996
+
+
+   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
+   containing the SOA record of client's version of the zone.
+
+
+
+
+
+
+
+
+Ohta                        Standards Track                     [Page 2]
+
+RFC 1995            Incremental Zone Transfer in DNS         August 1996
+
+
+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
+   of storage required is at most twice that of the current zone
+   information.
+
+
+
+Ohta                        Standards Track                     [Page 3]
+
+RFC 1995            Incremental Zone Transfer in DNS         August 1996
+
+
+   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.
+      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
+
+
+
+Ohta                        Standards Track                     [Page 4]
+
+RFC 1995            Incremental Zone Transfer in DNS         August 1996
+
+
+   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>                                           |
+                 +---------------------------------------------------+
+
+
+
+
+
+
+
+
+
+
+Ohta                        Standards Track                     [Page 5]
+
+RFC 1995            Incremental Zone Transfer in DNS         August 1996
+
+
+   or with the following 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=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>                                           |
+                 +---------------------------------------------------+
+
+
+
+
+
+
+
+
+Ohta                        Standards Track                     [Page 6]
+
+RFC 1995            Incremental Zone Transfer in DNS         August 1996
+
+
+   or, if UDP packet overflow occurs, with the following message:
+
+                 +---------------------------------------------------+
+      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", RFC 1996, August 1996.
+
+   [STD13] Mockapetris, P., "Domain Name System", STD 13, RFC 1034 and
+   RFC 1035), 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Ohta                        Standards Track                     [Page 7]
+
+RFC 1995            Incremental Zone Transfer in DNS         August 1996
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ohta                        Standards Track                     [Page 8]
+
diff --git a/usr.sbin/named/doc/rfc/rfc1996 b/usr.sbin/named/doc/rfc/rfc1996
new file mode 100644
index 00000000000..b08f2007972
--- /dev/null
+++ b/usr.sbin/named/doc/rfc/rfc1996
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                           P. Vixie
+Request for Comments: 1996                                           ISC
+Updates: 1035                                                August 1996
+Category: Standards Track
+
+
+    A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This memo 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.
+
+   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].
+
+
+
+
+
+
+
+
+
+Vixie                       Standards Track                     [Page 1]
+
+RFC 1996                       DNS NOTIFY                    August 1996
+
+
+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).
+
+   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
+
+
+
+Vixie                       Standards Track                     [Page 2]
+
+RFC 1996                       DNS NOTIFY                    August 1996
+
+
+   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.
+
+   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.
+
+
+
+Vixie                       Standards Track                     [Page 3]
+
+RFC 1996                       DNS NOTIFY                    August 1996
+
+
+   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.
+
+   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
+
+
+
+Vixie                       Standards Track                     [Page 4]
+
+RFC 1996                       DNS NOTIFY                    August 1996
+
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie                       Standards Track                     [Page 5]
+
+RFC 1996                       DNS NOTIFY                    August 1996
+
+
+   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.
+
+   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.
+
+
+
+
+
+Vixie                       Standards Track                     [Page 6]
+
+RFC 1996                       DNS NOTIFY                    August 1996
+
+
+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.
+
+6. References
+
+   [RFC1035]
+      Mockapetris, P., "Domain Names - Implementation and
+      Specification", STD 13, RFC 1035, November 1987.
+
+   [IXFR]
+      Ohta, M., "Incremental Zone Transfer", RFC 1995, August 1996.
+
+7. Author's Address
+
+   Paul Vixie
+   Internet Software Consortium
+   Star Route Box 159A
+   Woodside, CA 94062
+
+   Phone: +1 415 747 0204
+   EMail: paul@vix.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie                       Standards Track                     [Page 7]
+
diff --git a/usr.sbin/named/doc/rfc/rfc2010 b/usr.sbin/named/doc/rfc/rfc2010
new file mode 100644
index 00000000000..7e43bfce1d4
--- /dev/null
+++ b/usr.sbin/named/doc/rfc/rfc2010
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                         B. Manning
+Request for Comments: 2010                                           ISI
+Category: Informational                                         P. Vixie
+                                                                     ISC
+                                                            October 1996
+
+
+               Operational Criteria for Root Name Servers
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   This document specifies the operational requirements of root name
+   servers, including host hardware capacities, name server software
+   revisions, network connectivity, and physical environment.
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Manning & Vixie              Informational                      [Page 1]
+
+RFC 2010                    DNSSVR Criteria                 October 1996
+
+
+   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.
+
+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.
+
+
+
+
+
+
+Manning & Vixie              Informational                      [Page 2]
+
+RFC 2010                    DNSSVR Criteria                 October 1996
+
+
+   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.
+
+   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.
+
+
+
+
+
+Manning & Vixie              Informational                      [Page 3]
+
+RFC 2010                    DNSSVR Criteria                 October 1996
+
+
+     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.
+
+   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.
+
+
+
+
+
+
+
+
+Manning & Vixie              Informational                      [Page 4]
+
+RFC 2010                    DNSSVR Criteria                 October 1996
+
+
+     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.
+
+   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.
+
+
+
+
+
+
+
+
+Manning & Vixie              Informational                      [Page 5]
+
+RFC 2010                    DNSSVR Criteria                 October 1996
+
+
+     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).
+
+4 - Security Considerations
+
+   See section 2.7.
+
+5 - References
+
+   [RFC1035]
+      Mockapetris, P., "Domain Names - Implementation and Specification",
+      STD 13, RFC 1035, USC/Information Sciences Institute, November
+      1987.
+
+   [Postel96]
+      Postel, J., "New Registries and the Delegation of International Top
+      Level Domains", Work in Progress.
+
+   [IXFR]
+      Ohta, M., "Incremental Zone Transfer", RFC 1995, August 1996.
+
+   [NOTIFY]
+      Vixie, P., "A Mechanism for Prompt Notification of Zone Changes",
+      RFC 1996, August 1996.
+
+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.
+
+
+
+
+Manning & Vixie              Informational                      [Page 6]
+
+RFC 2010                    DNSSVR Criteria                 October 1996
+
+
+7 - Authors' Addresses
+
+     Bill Manning
+     USC/ISI
+     4676 Admiralty Way
+     Marina del Rey, CA 90292
+
+     Phone: +1 310 822 1511
+     EMail: bmanning@isi.edu
+
+
+     Paul Vixie
+     Internet Software Consortium
+     Star Route Box 159A
+     Woodside, CA 94062
+
+     Phone: +1 415 747 0204
+     EMail: paul@vix.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Manning & Vixie              Informational                      [Page 7]
+
diff --git a/usr.sbin/named/doc/rfc/rfc2052 b/usr.sbin/named/doc/rfc/rfc2052
new file mode 100644
index 00000000000..9fbccb627e3
--- /dev/null
+++ b/usr.sbin/named/doc/rfc/rfc2052
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                     A. Gulbrandsen
+Request for Comments: 2052                            Troll Technologies
+Updates: 1035, 1183                                             P. Vixie
+Category: Experimental                                 Vixie Enterprises
+                                                            October 1996
+
+
+       A DNS RR for specifying the location of services (DNS SRV)
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  This memo does not specify an Internet standard of any
+   kind.  Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Abstract
+
+   This document describes a DNS RR which specifies the location of the
+   server(s) for a specific protocol and domain (like a more general
+   form of MX).
+
+Overview and rationale
+
+   Currently, one must either know the exact address of a server to
+   contact it, or broadcast a question.  This has led to, for example,
+   ftp.whatever.com aliases, the SMTP-specific MX RR, and using MAC-
+   level broadcasts to locate servers.
+
+   The SRV RR allows administrators to use several servers for a single
+   domain, to move services from host to host with little fuss, and to
+   designate some hosts as primary servers for a service and others as
+   backups.
+
+   Clients ask for a specific service/protocol for a specific domain
+   (the word domain is used here in the strict RFC 1034 sense), and get
+   back the names of any available servers.
+
+Introductory example
+
+   When a SRV-cognizant web-browser wants to retrieve
+
+      http://www.asdf.com/
+
+   it does a lookup of
+
+      http.tcp.www.asdf.com
+
+
+
+
+Gulbrandsen & Vixie           Experimental                      [Page 1]
+
+RFC 2052                       DNS SRV RR                   October 1996
+
+
+   and retrieves the document from one of the servers in the reply.  The
+   example zone file near the end of the memo contains answering RRs for
+   this query.
+
+The format of the SRV RR
+
+   Here is the format of the SRV RR, whose DNS type code is 33:
+
+        Service.Proto.Name TTL Class SRV Priority Weight Port Target
+
+        (There is an example near the end of this document.)
+
+   Service
+        The symbolic name of the desired service, as defined in Assigned
+        Numbers or locally.
+
+        Some widely used services, notably POP, don't have a single
+        universal name.  If Assigned Numbers names the service
+        indicated, that name is the only name which is legal for SRV
+        lookups.  Only locally defined services may be named locally.
+        The Service is case insensitive.
+
+   Proto
+        TCP and UDP are at present the most useful values
+        for this field, though any name defined by Assigned Numbers or
+        locally may be used (as for Service).  The Proto is case
+        insensitive.
+
+   Name
+        The domain this RR refers to.  The SRV RR is unique in that the
+        name one searches for is not this name; the example near the end
+        shows this clearly.
+
+   TTL
+        Standard DNS meaning.
+
+   Class
+        Standard DNS meaning.
+
+   Priority
+        As for MX, the priority of this target host.  A client MUST
+        attempt to contact the target host with the lowest-numbered
+        priority it can reach; target hosts with the same priority
+        SHOULD be tried in pseudorandom order.  The range is 0-65535.
+
+
+
+
+
+
+
+Gulbrandsen & Vixie           Experimental                      [Page 2]
+
+RFC 2052                       DNS SRV RR                   October 1996
+
+
+   Weight
+        Load balancing mechanism.  When selecting a target host among
+        the those that have the same priority, the chance of trying this
+        one first SHOULD be proportional to its weight.  The range of
+        this number is 1-65535.  Domain administrators are urged to use
+        Weight 0 when there isn't any load balancing to do, to make the
+        RR easier to read for humans (less noisy).
+
+   Port
+        The port on this target host of this service.  The range is
+        0-65535.  This is often as specified in Assigned Numbers but
+        need not be.
+
+   Target
+        As for MX, the domain name of the target host.  There MUST be
+        one or more A records for this name. Implementors are urged, but
+        not required, to return the A record(s) in the Additional Data
+        section.  Name compression is to be used for this field.
+
+        A Target of "." means that the service is decidedly not
+        available at this domain.
+
+Domain administrator advice
+
+   Asking everyone to update their telnet (for example) clients when the
+   first internet site adds a SRV RR for Telnet/TCP is futile (even if
+   desirable).  Therefore SRV will have to coexist with A record lookups
+   for a long time, and DNS administrators should try to provide A
+   records to support old clients:
+
+      - Where the services for a single domain are spread over several
+        hosts, it seems advisable to have a list of A RRs at the same
+        DNS node as the SRV RR, listing reasonable (if perhaps
+        suboptimal) fallback hosts for Telnet, NNTP and other protocols
+        likely to be used with this name.  Note that some programs only
+        try the first address they get back from e.g. gethostbyname(),
+        and we don't know how widespread this behaviour is.
+
+      - Where one service is provided by several hosts, one can either
+        provide A records for all the hosts (in which case the round-
+        robin mechanism, where available, will share the load equally)
+        or just for one (presumably the fastest).
+
+      - If a host is intended to provide a service only when the main
+        server(s) is/are down, it probably shouldn't be listed in A
+        records.
+
+
+
+
+
+Gulbrandsen & Vixie           Experimental                      [Page 3]
+
+RFC 2052                       DNS SRV RR                   October 1996
+
+
+      - Hosts that are referenced by backup A records must use the port
+        number specified in Assigned Numbers for the service.
+
+   Currently there's a practical limit of 512 bytes for DNS replies.
+   Until all resolvers can handle larger responses, domain
+   administrators are strongly advised to keep their SRV replies below
+   512 bytes.
+
+   All round numbers, wrote Dr. Johnson, are false, and these numbers
+   are very round: A reply packet has a 30-byte overhead plus the name
+   of the service ("telnet.tcp.asdf.com" for instance); each SRV RR adds
+   20 bytes plus the name of the target host; each NS RR in the NS
+   section is 15 bytes plus the name of the name server host; and
+   finally each A RR in the additional data section is 20 bytes or so,
+   and there are A's for each SRV and NS RR mentioned in the answer.
+   This size estimate is extremely crude, but shouldn't underestimate
+   the actual answer size by much.  If an answer may be close to the
+   limit, using e.g. "dig" to look at the actual answer is a good idea.
+
+The "Weight" field
+
+   Weight, the load balancing field, is not quite satisfactory, but the
+   actual load on typical servers changes much too quickly to be kept
+   around in DNS caches.  It seems to the authors that offering
+   administrators a way to say "this machine is three times as fast as
+   that one" is the best that can practically be done.
+
+   The only way the authors can see of getting a "better" load figure is
+   asking a separate server when the client selects a server and
+   contacts it.  For short-lived services like SMTP an extra step in the
+   connection establishment seems too expensive, and for long-lived
+   services like telnet, the load figure may well be thrown off a minute
+   after the connection is established when someone else starts or
+   finishes a heavy job.
+
+The Port number
+
+   Currently, the translation from service name to port number happens
+   at the client, often using a file such as /etc/services.
+
+   Moving this information to the DNS makes it less necessary to update
+   these files on every single computer of the net every time a new
+   service is added, and makes it possible to move standard services out
+   of the "root-only" port range on unix.
+
+
+
+
+
+
+
+Gulbrandsen & Vixie           Experimental                      [Page 4]
+
+RFC 2052                       DNS SRV RR                   October 1996
+
+
+Usage rules
+
+   A SRV-cognizant client SHOULD use this procedure to locate a list of
+   servers and connect to the preferred one:
+
+        Do a lookup for QNAME=service.protocol.target, QCLASS=IN,
+        QTYPE=SRV.
+
+        If the reply is NOERROR, ANCOUNT>0 and there is at least one SRV
+        RR which specifies the requested Service and Protocol in the
+        reply:
+
+             If there is precisely one SRV RR, and its Target is "."
+             (the root domain), abort.
+
+             Else, for all such RR's, build a list of (Priority, Weight,
+             Target) tuples
+
+             Sort the list by priority (lowest number first)
+
+             Create a new empty list
+
+             For each distinct priority level
+                  While there are still elements left at this priority
+                  level
+                       Select an element randomly, with probability
+                       Weight, and move it to the tail of the new list
+
+             For each element in the new list
+
+                  query the DNS for A RR's for the Target or use any
+                  RR's found in the Additional Data secion of the
+                  earlier SRV query.
+
+                  for each A RR found, try to connect to the (protocol,
+                  address, service).
+
+        else if the service desired is SMTP
+
+             skip to RFC 974 (MX).
+
+        else
+
+             Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A
+
+             for each A RR found, try to connect to the (protocol,
+             address, service)
+
+
+
+
+Gulbrandsen & Vixie           Experimental                      [Page 5]
+
+RFC 2052                       DNS SRV RR                   October 1996
+
+
+   Notes:
+
+      - Port numbers SHOULD NOT be used in place of the symbolic service
+        or protocol names (for the same reason why variant names cannot
+        be allowed: Applications would have to do two or more lookups).
+
+      - If a truncated response comes back from an SRV query, and the
+        Additional Data section has at least one complete RR in it, the
+        answer MUST be considered complete and the client resolver
+        SHOULD NOT retry the query using TCP, but use normal UDP queries
+        for A RR's missing from the Additional Data section.
+
+      - A client MAY use means other than Weight to choose among target
+        hosts with equal Priority.
+
+      - A client MUST parse all of the RR's in the reply.
+
+      - If the Additional Data section doesn't contain A RR's for all
+        the SRV RR's and the client may want to connect to the target
+        host(s) involved, the client MUST look up the A RR(s).  (This
+        happens quite often when the A RR has shorter TTL than the SRV
+        or NS RR's.)
+
+      - A future standard could specify that a SRV RR whose Protocol was
+        TCP and whose Service was SMTP would override RFC 974's rules
+        with regard to the use of an MX RR.  This would allow firewalled
+        organizations with several SMTP relays to control the load
+        distribution using the Weight field.
+
+      - Future protocols could be designed to use SRV RR lookups as the
+        means by which clients locate their servers.
+
+Fictional example
+
+   This is (part of) the zone file for asdf.com, a still-unused domain:
+
+        $ORIGIN asdf.com.
+        @               SOA server.asdf.com. root.asdf.com. (
+                            1995032001 3600 3600 604800 86400 )
+                        NS  server.asdf.com.
+                        NS  ns1.ip-provider.net.
+                        NS  ns2.ip-provider.net.
+        ftp.tcp         SRV 0 0 21 server.asdf.com.
+        finger.tcp      SRV 0 0 79 server.asdf.com.
+        ; telnet - use old-slow-box or new-fast-box if either is
+        ; available, make three quarters of the logins go to
+        ; new-fast-box.
+        telnet.tcp      SRV 0 1 23 old-slow-box.asdf.com.
+
+
+
+Gulbrandsen & Vixie           Experimental                      [Page 6]
+
+RFC 2052                       DNS SRV RR                   October 1996
+
+
+                        SRV 0 3 23 new-fast-box.asdf.com.
+        ; if neither old-slow-box or new-fast-box is up, switch to
+        ; using the sysdmin's box and the server
+                        SRV 1 0 23 sysadmins-box.asdf.com.
+                        SRV 1 0 23 server.asdf.com.
+        ; HTTP - server is the main server, new-fast-box is the backup
+        ; (On new-fast-box, the HTTP daemon runs on port 8000)
+        http.tcp        SRV 0 0 80 server.asdf.com.
+                        SRV 10 0 8000 new-fast-box.asdf.com.
+        ; since we want to support both http://asdf.com/ and
+        ; http://www.asdf.com/ we need the next two RRs as well
+        http.tcp.www    SRV 0 0 80 server.asdf.com.
+                        SRV 10 0 8000 new-fast-box.asdf.com.
+        ; SMTP - mail goes to the server, and to the IP provider if
+        ; the net is down
+        smtp.tcp        SRV 0 0 25 server.asdf.com.
+                        SRV 1 0 25 mailhost.ip-provider.net.
+        @               MX  0 server.asdf.com.
+                        MX  1 mailhost.ip-provider.net.
+        ; NNTP - use the IP providers's NNTP server
+        nntp.tcp        SRV 0 0 119 nntphost.ip-provider.net.
+        ; IDB is an locally defined protocol
+        idb.tcp         SRV  0 0 2025 new-fast-box.asdf.com.
+        ; addresses
+        server          A   172.30.79.10
+        old-slow-box    A   172.30.79.11
+        sysadmins-box   A   172.30.79.12
+        new-fast-box    A   172.30.79.13
+        ; backup A records - new-fast-box and old-slow-box are
+        ; included, naturally, and server is too, but might go
+        ; if the load got too bad
+        @               A   172.30.79.10
+                        A   172.30.79.11
+                        A   172.30.79.13
+        ; backup A RR for www.asdf.com
+        www             A       172.30.79.10
+        ; NO other services are supported
+        *.tcp           SRV  0 0 0 .
+        *.udp           SRV  0 0 0 .
+
+   In this example, a telnet connection to "asdf.com." needs an SRV
+   lookup of "telnet.tcp.asdf.com." and possibly A lookups of "new-
+   fast-box.asdf.com." and/or the other hosts named.  The size of the
+   SRV reply is approximately 365 bytes:
+
+      30 bytes general overhead
+      20 bytes for the query string, "telnet.tcp.asdf.com."
+      130 bytes for 4 SRV RR's, 20 bytes each plus the lengths of "new-
+
+
+
+Gulbrandsen & Vixie           Experimental                      [Page 7]
+
+RFC 2052                       DNS SRV RR                   October 1996
+
+
+        fast-box", "old-slow-box", "server" and "sysadmins-box" -
+        "asdf.com" in the query section is quoted here and doesn't
+        need to be counted again.
+      75 bytes for 3 NS RRs, 15 bytes each plus the lengths of
+        "server", "ns1.ip-provider.net." and "ns2" - again, "ip-
+        provider.net." is quoted and only needs to be counted once.
+      120 bytes for the 6 A RR's mentioned by the SRV and NS RR's.
+
+Refererences
+
+   RFC 1918: Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G.,
+        and E.  Lear, "Address Allocation for Private Internets",
+        RFC 1918, February 1996.
+
+   RFC 1916 Berkowitz, H., Ferguson, P, Leland, W. and P. Nesser,
+        "Enterprise Renumbering: Experience and Information
+        Solicitation", RFC 1916, February 1996.
+
+   RFC 1912 Barr, D., "Common DNS Operational and Configuration
+        Errors", RFC 1912, February 1996.
+
+   RFC 1900: Carpenter, B., and Y. Rekhter, "Renumbering Needs Work",
+        RFC 1900, February 1996.
+
+   RFC 1920: Postel, J., "INTERNET OFFICIAL PROTOCOL STANDARDS",
+        STD 1, RFC 1920, March 1996.
+
+   RFC 1814: Gerich, E., "Unique Addresses are Good", RFC 1814, June
+             1995.
+
+   RFC 1794: Brisco, T., "DNS Support for Load Balancing", April 1995.
+
+   RFC 1713: Romao, A., "Tools for DNS debugging", November 1994.
+
+   RFC 1712: Farrell, C., Schulze, M., Pleitner, S., and D. Baldoni,
+        "DNS Encoding of Geographical Location", RFC 1712, November
+        1994.
+
+   RFC 1706: Manning, B. and R. Colella, "DNS NSAP Resource Records",
+        RFC 1706, October 1994.
+
+   RFC 1700: Reynolds, J., and J. Postel, "ASSIGNED NUMBERS",
+        STD 2, RFC 1700, October 1994.
+
+   RFC 1183: Ullmann, R., Mockapetris, P., Mamakos, L., and
+        C. Everhart, "New DNS RR Definitions", RFC 1183, November
+        1990.
+
+
+
+
+Gulbrandsen & Vixie           Experimental                      [Page 8]
+
+RFC 2052                       DNS SRV RR                   October 1996
+
+
+   RFC 1101: Mockapetris, P., "DNS encoding of network names and other
+        types", RFC 1101, April 1989.
+
+   RFC 1035: Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   RFC 1034: Mockapetris, P., "Domain names - concepts and
+        facilities", STD 13, RFC 1034, November 1987.
+
+   RFC 1033: Lottor, M., "Domain administrators operations guide",
+        RFC 1033, November 1987.
+
+   RFC 1032: Stahl, M., "Domain administrators guide", RFC 1032,
+        November 1987.
+
+   RFC 974: Partridge, C., "Mail routing and the domain system",
+        STD 14, RFC 974, January 1986.
+
+Security Considerations
+
+   The authors believes this RR to not cause any new security problems.
+   Some problems become more visible, though.
+
+      - The ability to specify ports on a fine-grained basis obviously
+        changes how a router can filter packets.  It becomes impossible
+        to block internal clients from accessing specific external
+        services, slightly harder to block internal users from running
+        unautorised services, and more important for the router
+        operations and DNS operations personnel to cooperate.
+
+      - There is no way a site can keep its hosts from being referenced
+        as servers (as, indeed, some sites become unwilling secondary
+        MXes today).  This could lead to denial of service.
+
+      - With SRV, DNS spoofers can supply false port numbers, as well as
+        host names and addresses.  The authors do not see any practical
+        effect of this.
+
+   We assume that as the DNS-security people invent new features, DNS
+   servers will return the relevant RRs in the Additional Data section
+   when answering an SRV query.
+
+
+
+
+
+
+
+
+
+
+Gulbrandsen & Vixie           Experimental                      [Page 9]
+
+RFC 2052                       DNS SRV RR                   October 1996
+
+
+Authors' Addresses
+
+   Arnt Gulbrandsen
+   Troll Tech
+   Postboks 6133 Etterstad
+   N-0602 Oslo
+   Norway
+
+   Phone: +47 22646966
+   EMail: agulbra@troll.no
+
+
+   Paul Vixie
+   Vixie Enterprises
+   Star Route 159A
+   Woodside, CA  94062
+
+   Phone: (415) 747-0204
+   EMail: paul@vix.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gulbrandsen & Vixie           Experimental                     [Page 10]
+
diff --git a/usr.sbin/named/doc/rfc/rfc819 b/usr.sbin/named/doc/rfc/rfc819
new file mode 100644
index 00000000000..d66f8d91448
--- /dev/null
+++ b/usr.sbin/named/doc/rfc/rfc819
@@ -0,0 +1,1044 @@
+
+
+Network Working Group                                  Zaw-Sing Su (SRI)
+Request for Comments: 819                               Jon Postel (ISI)
+                                                             August 1982
+
+
+
+      The Domain Naming Convention for Internet User Applications
+
+
+
+
+1.  Introduction
+
+   For many years, the naming convention "<user>@<host>" has served the
+   ARPANET user community for its mail system, and the substring
+   "<host>" has been used for other applications such as file transfer
+   (FTP) and terminal access (Telnet).  With the advent of network
+   interconnection, this naming convention needs to be generalized to
+   accommodate internetworking.  A decision has recently been reached to
+   replace the simple name field, "<host>", by a composite name field,
+   "<domain>" [2].  This note is an attempt to clarify this generalized
+   naming convention, the Internet Naming Convention, and to explore the
+   implications of its adoption for Internet name service and user
+   applications.
+
+   The following example illustrates the changes in naming convention:
+
+      ARPANET Convention:   Fred@ISIF
+      Internet Convention:  Fred@F.ISI.ARPA
+
+   The intent is that the Internet names be used to form a
+   tree-structured administrative dependent, rather than a strictly
+   topology dependent, hierarchy.  The left-to-right string of name
+   components proceeds from the most specific to the most general, that
+   is, the root of the tree, the administrative universe, is on the
+   right.
+
+   The name service for realizing the Internet naming convention is
+   assumed to be application independent.  It is not a part of any
+   particular application, but rather an independent name service serves
+   different user applications.
+
+2.  The Structural Model
+
+   The Internet naming convention is based on the domain concept.  The
+   name of a domain consists of a concatenation of one or more <simple
+   names>.  A domain can be considered as a region of jurisdiction for
+   name assignment and of responsibility for name-to-address
+   translation.  The set of domains forms a hierarchy.
+
+   Using a graph theory representation, this hierarchy may be modeled as
+   a directed graph.  A directed graph consists of a set of nodes and a
+
+
+Su & Postel                                                     [Page 1]
+
+
+
+RFC 819                                                     August 1982;
+
+
+   collection of arcs, where arcs are identified by ordered pairs of
+   distinct nodes [1].  Each node of the graph represents a domain.  An
+   ordered pair (B, A), an arc from B to A, indicates that B is a
+   subdomain of domain A, and B is a simple name unique within A.  We
+   will refer to B as a child of A, and A a parent of B.  The directed
+   graph that best describes the naming hierarchy is called an
+   "in-tree", which is a rooted tree with all arcs directed towards the
+   root (Figure 1). The root of the tree represents the naming universe,
+   ancestor of all domains.  Endpoints (or leaves) of the tree are the
+   lowest-level domains.
+
+                         U
+                       / | \
+                     /   |   \          U -- Naming Universe
+                    ^    ^    ^         I -- Intermediate Domain
+                    |    |    |         E -- Endpoint Domain
+                    I    E    I
+                  /   \       |
+                 ^     ^      ^
+                 |     |      |
+                 E     E      I
+                            / | \
+                           ^  ^  ^
+                           |  |  |
+                           E  E  E
+
+                                Figure 1
+                 The In-Tree Model for Domain Hierarchy
+
+   The simple name of a child in this model is necessarily unique within
+   its parent domain.  Since the simple name of the child's parent is
+   unique within the child's grandparent domain, the child can be
+   uniquely named in its grandparent domain by the concatenation of its
+   simple name followed by its parent's simple name.
+
+      For example, if the simple name of a child is "C1" then no other
+      child of the same parent may be named "C1".  Further, if the
+      parent of this child is named "P1", then "P1" is a unique simple
+      name in the child's grandparent domain.  Thus, the concatenation
+      C1.P1 is unique in C1's grandparent domain.
+
+   Similarly, each element of the hierarchy is uniquely named in the
+   universe by its complete name, the concatenation of its simple name
+   and those for the domains along the trail leading to the naming
+   universe.
+
+   The hierarchical structure of the Internet naming convention supports
+   decentralization of naming authority and distribution of name service
+   capability.  We assume a naming authority and a name server
+
+
+Su & Postel                                                     [Page 2]
+
+
+
+RFC 819                                                     August 1982;
+
+
+   associated with each domain.  In Sections 5 and 6 respectively the
+   name service and the naming authority are discussed.
+
+   Within an endpoint domain, unique names are assigned to <user>
+   representing user mailboxes.  User mailboxes may be viewed as
+   children of their respective domains.
+
+   In reality, anomalies may exist violating the in-tree model of naming
+   hierarchy.  Overlapping domains imply multiple parentage, i.e., an
+   entity of the naming hierarchy being a child of more than one domain.
+   It is conceivable that ISI can be a member of the ARPA domain as well
+   as a member of the USC domain (Figure 2).  Such a relation
+   constitutes an anomaly to the rule of one-connectivity between any
+   two points of a tree.  The common child and the sub-tree below it
+   become descendants of both parent domains.
+
+                                 U
+                               / | \
+                             /   .   \
+                           .     .   ARPA
+                         .       .     | \
+                                USC    |   \
+                                   \   |     .
+                                     \ |       .
+                                      ISI
+
+                                Figure 2
+                      Anomaly in the In-Tree Model
+
+   Some issues resulting from multiple parentage are addressed in
+   Appendix B.  The general implications of multiple parentage are a
+   subject for further investigation.
+
+3.  Advantage of Absolute Naming
+
+   Absolute naming implies that the (complete) names are assigned with
+   respect to a universal reference point.  The advantage of absolute
+   naming is that a name thus assigned can be universally interpreted
+   with respect to the universal reference point.  The Internet naming
+   convention provides absolute naming with the naming universe as its
+   universal reference point.
+
+   For relative naming, an entity is named depending upon the position
+   of the naming entity relative to that of the named entity.  A set of
+   hosts running the "unix" operating system exchange mail using a
+   method called "uucp".  The naming convention employed by uucp is an
+   example of relative naming.  The mail recipient is typically named by
+   a source route identifying a chain of locally known hosts linking the
+
+
+
+Su & Postel                                                     [Page 3]
+
+
+
+RFC 819                                                     August 1982;
+
+
+   sender's host to the recipient's.  A destination name can be, for
+   example,
+
+      "alpha!beta!gamma!john",
+
+   where "alpha" is presumably known to the originating host, "beta" is
+   known to "alpha", and so on.
+
+   The uucp mail system has demonstrated many of the problems inherent
+   to relative naming.  When the host names are only locally
+   interpretable, routing optimization becomes impossible.  A reply
+   message may have to traverse the reverse route to the original sender
+   in order to be forwarded to other parties.
+
+   Furthermore, if a message is forwarded by one of the original
+   recipients or passed on as the text of another message, the frame of
+   reference of the relative source route can be completely lost.  Such
+   relative naming schemes have severe problems for many of the uses
+   that we depend upon in the ARPA Internet community.
+
+4.  Interoperability
+
+   To allow interoperation with a different naming convention, the names
+   assigned by a foreign naming convention need to be accommodated.
+   Given the autonomous nature of domains, a foreign naming environment
+   may be incorporated as a domain anywhere in the hierarchy.  Within
+   the naming universe, the name service for a domain is provided within
+   that domain.  Thus, a foreign naming convention can be independent of
+   the Internet naming convention.  What is implied here is that no
+   standard convention for naming needs to be imposed to allow
+   interoperations among heterogeneous naming environments.
+
+      For example:
+
+         There might be a naming convention, say, in the FOO world,
+         something like "<user>%<host>%<area>".  Communications with an
+         entity in that environment can be achieved from the Internet
+         community by simply appending ".FOO" on the end of the name in
+         that foreign convention.
+
+            John%ISI-Tops20-7%California.FOO
+
+      Another example:
+
+         One way of accommodating the "uucp world" described in the last
+         section is to declare it as a foreign system.  Thus, a uucp
+         name
+
+            "alpha!beta!gamma!john"
+
+
+Su & Postel                                                     [Page 4]
+
+
+
+RFC 819                                                     August 1982;
+
+
+         might be known in the Internet community as
+
+            "alpha!beta!gamma!john.UUCP".
+
+      Communicating with a complex subdomain is another case which can
+      be treated as interoperation.  A complex subdomain is a domain
+      with complex internal naming structure presumably unknown to the
+      outside world (or the outside world does not care to be concerned
+      with its complexity).
+
+   For the mail system application, the names embedded in the message
+   text are often used by the destination for such purpose as to reply
+   to the original message.  Thus, the embedded names may need to be
+   converted for the benefit of the name server in the destination
+   environment.
+
+   Conversion of names on the boundary between heterogeneous naming
+   environments is a complex subject.  The following example illustrates
+   some of the involved issues.
+
+      For example:
+
+         A message is sent from the Internet community to the FOO
+         environment.  It may bear the "From" and "To" fields as:
+
+            From: Fred@F.ISI.ARPA
+            To:   John%ISI-Tops20-7%California.FOO
+
+         where "FOO" is a domain independent of the Internet naming
+         environment.  The interface on the boundary of the two
+         environments may be represented by a software module.  We may
+         assume this interface to be an entity of the Internet community
+         as well as an entity of the FOO community.  For the benefit of
+         the FOO environment, the "From" and "To" fields need to be
+         modified upon the message's arrival at the boundary. One may
+         view naming as a separate layer of protocol, and treat
+         conversion as a protocol translation.  The matter is
+         complicated when the message is sent to more than one
+         destination within different naming environments; or the
+         message is destined within an environment not sharing boundary
+         with the originating naming environment.
+
+   While the general subject concerning conversion is beyond the scope
+   of this note, a few questions are raised in Appendix D.
+
+
+
+
+
+
+
+Su & Postel                                                     [Page 5]
+
+
+
+RFC 819                                                     August 1982;
+
+
+5.  Name Service
+
+   Name service is a network service providing name-to-address
+   translation.  Such service may be achieved in a number of ways.  For
+   a simple networking environment, it can be accomplished with a single
+   central database containing name-to-address correspondence for all
+   the pertinent network entities, such as hosts.
+
+   In the case of the old ARPANET host names, a central database is
+   duplicated in each individual host.  The originating module of an
+   application process would query the local name service (e.g., make a
+   system call) to obtain network address for the destination host. With
+   the proliferation of networks and an accelerating increase in the
+   number of hosts participating in networking, the ever growing size,
+   update frequency, and the dissemination of the central database makes
+   this approach unmanageable.
+
+   The hierarchical structure of the Internet naming convention supports
+   decentralization of naming authority and distribution of name service
+   capability.  It readily accommodates growth of the naming universe.
+   It allows an arbitrary number of hierarchical layers.  The addition
+   of a new domain adds little complexity to an existing Internet
+   system.
+
+   The name service at each domain is assumed to be provided by one or
+   more name servers.  There are two models for how a name server
+   completes its work, these might be called "iterative" and
+   "recursive".
+
+      For an iterative name server there may be two kinds of responses.
+      The first kind of response is a destination address.  The second
+      kind of response is the address of another name server.  If the
+      response is a destination address, then the query is satisfied. If
+      the response is the address of another name server, then the query
+      must be repeated using that name server, and so on until a
+      destination address is obtained.
+
+      For a recursive name server there is only one kind of response --
+      a destination address.  This puts an obligation on the name server
+      to actually make the call on another name server if it can't
+      answer the query itself.
+
+   It is noted that looping can be avoided since the names presented for
+   translation can only be of finite concatenation.  However, care
+   should be taken in employing mechanisms such as a pointer to the next
+   simple name for resolution.
+
+   We believe that some name servers will be recursive, but we don't
+   believe that all will be.  This means that the caller must be
+
+
+Su & Postel                                                     [Page 6]
+
+
+
+RFC 819                                                     August 1982;
+
+
+   prepared for either type of server.  Further discussion and examples
+   of name service is given in Appendix C.
+
+   The basic name service at each domain is the translation of simple
+   names to addresses for all of its children.  However, if only this
+   basic name service is provided, the use of complete (or fully
+   qualified) names would be required.  Such requirement can be
+   unreasonable in practice.  Thus, we propose the use of partial names
+   in the context in which their uniqueness is preserved.  By
+   construction, naming uniqueness is preserved within the domain of a
+   common ancestry. Thus, a partially qualified name is constructed by
+   omitting from the complete name ancestors common to the communicating
+   parties. When a partially qualified name leaves its context of
+   uniqueness it must be additionally qualified.
+
+   The use of partially qualified names places a requirement on the
+   Internet name service.  To satisfy this requirement, the name service
+   at each domain must be capable of, in addition to the basic service,
+   resolving simple names for all of its ancestors (including itself)
+   and their children.  In Appendix B, the required distinction among
+   simple names for such resolution is addressed.
+
+6.  Naming Authority
+
+   Associated with each domain there must be a naming authority to
+   assign simple names and ensure proper distinction among simple names.
+
+   Note that if the use of partially qualified names is allowed in a
+   sub-domain, the uniqueness of simple names inside that sub-domain is
+   insufficient to avoid ambiguity with names outside the subdomain.
+   Appendix B discusses simple name assignment in a sub-domain that
+   would allow the use of partially qualified names without ambiguity.
+
+   Administratively, associated with each domain there is a single
+   person (or office) called the registrar.  The registrar of the naming
+   universe specifies the top-level set of domains and designates a
+   registrar for each of these domains.  The registrar for any given
+   domain maintains the naming authority for that domain.
+
+7.  Network-Oriented Applications
+
+   For user applications such as file transfer and terminal access, the
+   remote host needs to be named.  To be compatible with ARPANET naming
+   convention, a host can be treated as an endpoint domain.
+
+   Many operating systems or programming language run-time environments
+   provide functions or calls (JSYSs, SVCs, UUOs, SYSs, etc.) for
+   standard services (e.g., time-of-day, account-of-logged-in-user,
+   convert-number-to-string).  It is likely to be very helpful if such a
+
+
+Su & Postel                                                     [Page 7]
+
+
+
+RFC 819                                                     August 1982;
+
+
+   function or call is developed for translating a host name to an
+   address.  Indeed, several systems on the ARPANET already have such
+   facilities for translating an ARPANET host name into an ARPANET
+   address based on internal tables.
+
+   We recommend that this provision of a standard function or call for
+   translating names to addresses be extended to accept names of
+   Internet convention.  This will promote a consistent interface to the
+   users of programs involving internetwork activities.  The standard
+   facility for translating Internet names to Internet addresses should
+   include all the mechanisms available on the host, such as checking a
+   local table or cache of recently checked names, or consulting a name
+   server via the Internet.
+
+8.  Mail Relaying
+
+   Relaying is a feature adopted by more and more mail systems.
+   Relaying facilitates, among other things, interoperations between
+   heterogeneous mail systems.  The term "relay" is used to describe the
+   situation where a message is routed via one or more intermediate
+   points between the sender and the recipient.  The mail relays are
+   normally specified explicitly as relay points in the instructions for
+   message delivery. Usually, each of the intermediate relays assume
+   responsibility for the relayed message [3].
+
+      A point should be made on the basic difference between mail
+      relaying and the uucp naming system.  The difference is that
+      although mail relaying with absolute naming can also be considered
+      as a form of source routing, the names of each intermediate points
+      and that of the destination are universally interpretable, while
+      the host names along a source route of the uucp convention is
+      relative and thus only locally interpretable.
+
+   The Internet naming convention explicitly allows interoperations
+   among heterogeneous systems.  This implies that the originator of a
+   communication may name a destination which resides in a foreign
+   system.  The probability is that the destination network address may
+   not be comprehensible to the transport system of the originator.
+   Thus, an implicit relaying mechanism is called for at the boundary
+   between the domains.  The function of this implicit relay is the same
+   as the explicit relay.
+
+
+
+
+
+
+
+
+
+
+Su & Postel                                                     [Page 8]
+
+
+
+RFC 819                                                     August 1982;
+
+
+9.  Implementation
+
+   The Actual Domains
+
+      The initial set of top-level names include:
+
+         ARPA
+
+            This represents the set of organizations involved in the
+            Internet system through the authority of the U.S. Defense
+            Advanced Research Projects Agency.  This includes all the
+            research and development hosts on the ARPANET and hosts on
+            many other nets as well.  But note very carefully that the
+            top-level domain "ARPA" does not map one-to-one with the
+            ARPANET -- domains are administrative, not topological.
+
+   Transition
+
+      In the transition from the ARPANET naming convention to the
+      Internet naming convention, a host name may be used as a simple
+      name for an endpoint domain.  Thus, if "USC-ISIF" is an ARPANET
+      host name, then "USC-ISIF.ARPA" is the name of an Internet domain.
+
+10.  Summary
+
+   A hierarchical naming convention based on the domain concept has been
+   adopted by the Internet community.  It is an absolute naming
+   convention defined along administrative rather than topological
+   boundaries.  This naming convention is adaptive for interoperations
+   with other naming conventions.  Thus, no standard convention needs to
+   be imposed for interoperations among heterogeneous naming
+   environments.
+
+   This Internet naming convention allows distributed name service and
+   naming authority functions at each domain.  We have specified these
+   functions required at each domain.  Also discussed are implications
+   on network-oriented applications, mail systems, and administrative
+   aspects of this convention.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Su & Postel                                                     [Page 9]
+
+
+
+RFC 819                                                     August 1982;
+
+
+APPENDIX A
+
+   The BNF Specification
+
+   We present here a rather detailed "BNF" definition of the allowed
+   form for a computer mail "mailbox" composed of a "local-part" and a
+   "domain" (separated by an at sign).  Clearly, the domain can be used
+   separately in other network-oriented applications.
+
+   <mailbox> ::= <local-part> "@" <domain>
+
+   <local-part> ::= <string> | <quoted-string>
+
+   <string> ::= <char> | <char> <string>
+
+   <quoted-string> ::=  """ <qtext> """
+
+   <qtext> ::=  "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext>
+
+   <char> ::= <c> | "\" <x>
+
+   <domain> ::= <naming-domain> | <naming-domain> "." <domain>
+
+   <naming-domain> ::=  <simple-name> | <address>
+
+   <simple-name> ::= <a> <ldh-str> <let-dig>
+
+   <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
+
+   <let-dig> ::= <a> | <d>
+
+   <let-dig-hyp> ::= <a> | <d> | "-"
+
+   <address> :: =  "#" <number> | "[" <dotnum> "]"
+
+   <number> ::= <d> | <d> <number>
+
+   <dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>
+
+   <snum> ::= one, two, or three digits representing a decimal integer
+   value in the range 0 through 255
+
+   <a> ::= any one of the 52 alphabetic characters A through Z in upper
+   case and a through z in lower case
+
+   <c> ::= any one of the 128 ASCII characters except <s> or <SP>
+
+   <d> ::= any one of the ten digits 0 through 9
+
+
+
+Su & Postel                                                    [Page 10]
+
+
+
+RFC 819                                                     August 1982;
+
+
+   <q> ::= any one of the 128 ASCII characters except CR, LF, quote ("),
+   or backslash (\)
+
+   <x> ::= any one of the 128 ASCII characters (no exceptions)
+
+   <s> ::= "<", ">", "(", ")", "[", "]", "\", ".", ",", ";", ":", "@",
+   """, and the control characters (ASCII codes 0 through 31 inclusive
+   and 127)
+
+   Note that the backslash, "\", is a quote character, which is used to
+   indicate that the next character is to be used literally (instead of
+   its normal interpretation).  For example, "Joe\,Smith" could be used
+   to indicate a single nine character user field with comma being the
+   fourth character of the field.
+
+   The simple names that make up a domain may contain both upper and
+   lower case letters (as well as digits and hyphen), but these names
+   are not case sensitive.
+
+   Hosts are generally known by names.  Sometimes a host is not known to
+   the translation function and communication is blocked.  To bypass
+   this barrier two forms of addresses are also allowed for host
+   "names". One form is a decimal integer prefixed by a pound sign, "#".
+   Another form, called "dotted decimal", is four small decimal integers
+   separated by dots and enclosed by brackets, e.g., "[123.255.37.2]",
+   which indicates a 32-bit ARPA Internet Address in four 8-bit fields.
+   (Of course, these numeric address forms are specific to the Internet,
+   other forms may have to be provided if this problem arises in other
+   transport systems.)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Su & Postel                                                    [Page 11]
+
+
+
+RFC 819                                                     August 1982;
+
+
+APPENDIX B
+
+   An Aside on the Assignment of Simple Names
+
+   In the following example, there are two naming hierarchies joining at
+   the naming universe 'U'.  One consists of domains (S, R, N, J, P, Q,
+   B, A); and the other (L, E, F, G, H, D, C, K, B, A). Domain B is
+   assumed to have multiple parentage as shown.
+
+                                U
+                              /   \
+                            /       \
+                          J           L
+                        /               \
+                      N                   E
+                    /   \               /   \
+                  R       P           D       F
+                /           \         | \      \
+              S               Q       C  (X)     G
+                                \   /   \          \
+                                  B       K          H
+                                /
+                              A
+
+                                Figure 3
+    Illustration of Requirements for the Distinction of Simple Names
+
+   Suppose someone at A tries to initiate communication with destination
+   H.  The fully qualified destination name would be
+
+      H.G.F.E.L.U
+
+   Omitting common ancestors, the partially qualified name for the
+   destination would be
+
+      H.G.F
+
+   To permit the case of partially qualified names, name server at A
+   needs to resolve the simple name F, i.e., F needs to be distinct from
+   all the other simple names in its database.
+
+   To enable the name server of a domain to resolve simple names, a
+   simple name for a child needs to be assigned distinct from those of
+   all of its ancestors and their immediate children.  However, such
+   distinction would not be sufficient to allow simple name resolution
+   at lower-level domains because lower-level domains could have
+   multiple parentage below the level of this domain.
+
+      In the example above, let us assume that a name is to be assigned
+
+
+Su & Postel                                                    [Page 12]
+
+
+
+RFC 819                                                     August 1982;
+
+
+      to a new domain X by D.  To allow name server at D to resolve
+      simple names, the name for X must be distinct from L, E, D, C, F,
+      and J.  However, allowing A to resolve simple names, X needs to be
+      also distinct from A, B, K, as well as from Q, P, N, and R.
+
+   The following observations can be made.
+
+      Simple names along parallel trails (distinct trails leading from
+      one domain to the naming universe) must be distinct, e.g., N must
+      be distinct from E for B or A to properly resolve simple names.
+
+      No universal uniqueness of simple names is called for, e.g., the
+      simple name S does not have to be distinct from that of E, F, G,
+      H, D, C, K, Q, B, or A.
+
+      The lower the level at which a domain occurs, the more immune it
+      is to the requirement of naming uniqueness.
+
+   To satisfy the required distinction of simple names for proper
+   resolution at all levels, a naming authority needs to ensure the
+   simple name to be assigned distinct from those in the name server
+   databases at the endpoint naming domains within its domain.  As an
+   example, for D to assign a simple name for X, it would need to
+   consult databases at A and K.  It is, however, acceptable to have
+   simple names under domain A identical with those under K.  Failure of
+   such distinct assignment of simple names by naming authority of one
+   domain would jeopardize the capability of simple name resolution for
+   entities within the subtree under that domain.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Su & Postel                                                    [Page 13]
+
+
+
+RFC 819                                                     August 1982;
+
+
+APPENDIX C
+
+   Further Discussion of Name Service and Name Servers
+
+   The name service on a system should appear to the programmer of an
+   application program simply as a system call or library subroutine.
+   Within that call or subroutine there may be several types of methods
+   for resolving the name string into an address.
+
+      First, a local table may be consulted.  This table may be a
+      complete table and may be updated frequently, or it may simply be
+      a cache of the few latest name to address mappings recently
+      determined.
+
+      Second, a call may be made to a name server to resolve the string
+      into a destination address.
+
+      Third, a call may be made to a name server to resolve the string
+      into a relay address.
+
+   Whenever a name server is called it may be a recursive server or an
+   interactive server.
+
+      If the server is recursive, the caller won't be able to tell if
+      the server itself had the information to resolve the query or
+      called another server recursively (except perhaps for the time it
+      takes).
+
+      If the server is iterative, the caller must be prepared for either
+      the answer to its query, or a response indicating that it should
+      call on a different server.
+
+   It should be noted that the main name service discussed in this memo
+   is simply a name string to address service.  For some applications
+   there may be other services needed.
+
+      For example, even within the Internet there are several procedures
+      or protocols for actually transferring mail.  One need is to
+      determine which mail procedures a destination host can use.
+      Another need is to determine the name of a relay host if the
+      source and destination hosts do not have a common mail procedure.
+      These more specialized services must be specific to each
+      application since the answers may be application dependent, but
+      the basic name to address translation is application independent.
+
+
+
+
+
+
+
+Su & Postel                                                    [Page 14]
+
+
+
+RFC 819                                                     August 1982;
+
+
+APPENDIX D
+
+   Further Discussion of Interoperability and Protocol Translations
+
+   The translation of protocols from one system to another is often
+   quite difficult.  Following are some questions that stem from
+   considering the translations of addresses between mail systems:
+
+      What is the impact of different addressing environments (i.e.,
+      environments of different address formats)?
+
+      It is noted that the boundary of naming environment may or may not
+      coincide with the boundary of different mail systems. Should the
+      conversion of naming be independent of the application system?
+
+      The boundary between different addressing environments may or may
+      not coincide with that of different naming environments or
+      application systems.  Some generic approach appears to be
+      necessary.
+
+      If the conversion of naming is to be independent of the
+      application system, some form of interaction appears necessary
+      between the interface module of naming conversion with some
+      application level functions, such as the parsing and modification
+      of message text.
+
+      To accommodate encryption, conversion may not be desirable at all.
+      What then can be an alternative to conversion?
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Su & Postel                                                    [Page 15]
+
+
+
+RFC 819                                                     August 1982;
+
+
+GLOSSARY
+
+   address
+
+      An address is a numerical identifier for the topological location
+      of the named entity.
+
+   name
+
+      A name is an alphanumeric identifier associated with the named
+      entity.  For unique identification, a name needs to be unique in
+      the context in which the name is used.  A name can be mapped to an
+      address.
+
+   complete (fully qualified) name
+
+      A complete name is a concatenation of simple names representing
+      the hierarchical relation of the named with respect to the naming
+      universe, that is it is the concatenation of the simple names of
+      the domain structure tree nodes starting with its own name and
+      ending with the top level node name.  It is a unique name in the
+      naming universe.
+
+   partially qualified name
+
+      A partially qualified name is an abbreviation of the complete name
+      omitting simple names of the common ancestors of the communicating
+      parties.
+
+   simple name
+
+      A simple name is an alphanumeric identifier unique only within its
+      parent domain.
+
+   domain
+
+      A domain defines a region of jurisdiction for name assignment and
+      of responsibility for name-to-address translation.
+
+   naming universe
+
+      Naming universe is the ancestor of all network entities.
+
+   naming environment
+
+      A networking environment employing a specific naming convention.
+
+
+
+
+
+Su & Postel                                                    [Page 16]
+
+
+
+RFC 819                                                     August 1982;
+
+
+   name service
+
+      Name service is a network service for name-to-address mapping.
+
+   name server
+
+      A name server is a network mechanism (e.g., a process) realizing
+      the function of name service.
+
+   naming authority
+
+      Naming authority is an administrative entity having the authority
+      for assigning simple names and responsibility for resolving naming
+      conflict.
+
+   parallel relations
+
+      A network entity may have one or more hierarchical relations with
+      respect to the naming universe.  Such multiple relations are
+      parallel relations to each other.
+
+   multiple parentage
+
+      A network entity has multiple parentage when it is assigned a
+      simple name by more than one naming domain.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Su & Postel                                                    [Page 17]
+
+
+
+RFC 819                                                     August 1982;
+
+
+REFERENCES
+
+   [1]  F. Harary, "Graph Theory", Addison-Wesley, Reading,
+   Massachusetts, 1969.
+
+   [2]  J. Postel, "Computer Mail Meeting Notes", RFC-805,
+   USC/Information Sciences Institute, 8 February 1982.
+
+   [3]  J. Postel, "Simple Mail Transfer Protocol", RFC-821,
+   USC/Information Sciences Institute, August 1982.
+
+   [4]  D. Crocker, "Standard for the Format of ARPA Internet Text
+   Messages", RFC-822, Department of Electrical Engineering, University
+   of Delaware, August 1982.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Su & Postel                                                    [Page 18]
+
diff --git a/usr.sbin/named/doc/rfc/rfc920 b/usr.sbin/named/doc/rfc/rfc920
new file mode 100644
index 00000000000..661b8301006
--- /dev/null
+++ b/usr.sbin/named/doc/rfc/rfc920
@@ -0,0 +1,798 @@
+
+
+Network Working Group                                          J. Postel
+Request for Comments: 920                                    J. Reynolds
+                                                                     ISI
+                                                            October 1984
+
+                          Domain Requirements
+
+
+Status of this Memo
+
+   This memo is a policy statement on the requirements of establishing a
+   new domain in the ARPA-Internet and the DARPA research community.
+   This is an official policy statement of the IAB and the DARPA.
+   Distribution of this memo is unlimited.
+
+Introduction
+
+   This memo restates and refines the requirements on establishing a
+   Domain first described in RFC-881 [1].  It adds considerable detail
+   to that discussion, and introduces the limited set of top level
+   domains.
+
+The Purpose of Domains
+
+   Domains are administrative entities.  The purpose and expected use of
+   domains is to divide the name management required of a central
+   administration and assign it to sub-administrations.  There are no
+   geographical, topological, or technological constraints on a domain.
+   The hosts in a domain need not have common hardware or software, nor
+   even common protocols.  Most of the requirements and limitations on
+   domains are designed to ensure responsible administration.
+
+   The domain system is a tree-structured global name space that has a
+   few top level domains.  The top level domains are subdivided into
+   second level domains.  The second level domains may be subdivided
+   into third level domains, and so on.
+
+   The administration of a domain requires controlling the assignment of
+   names within that domain and providing access to the names and name
+   related information (such as addresses) to users both inside and
+   outside the domain.
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                               [Page 1]
+
+
+
+RFC 920                                                     October 1984
+Domain Requirements
+
+
+General Purpose Domains
+
+   While the initial domain name "ARPA" arises from the history of the
+   development of this system and environment, in the future most of the
+   top level names will be very general categories like "government",
+   "education", or "commercial".  The motivation is to provide an
+   organization name that is free of undesirable semantics.
+
+   After a short period of initial experimentation, all current
+   ARPA-Internet hosts will select some domain other than ARPA for their
+   future use.  The use of ARPA as a top level domain will eventually
+   cease.
+
+Initial Set of Top Level Domains
+
+   The initial top level domain names are:
+
+      Temporary
+
+         ARPA  =  The current ARPA-Internet hosts.
+
+      Categories
+
+         GOV  =  Government, any government related domains meeting the
+                 second level requirements.
+
+         EDU  =  Education, any education related domains meeting the
+                 second level requirements.
+
+         COM  =  Commercial, any commercial related domains meeting the
+                 second level requirements.
+
+         MIL  =  Military, any military related domains meeting the
+                 second level requirements.
+
+         ORG  =  Organization, any other domains meeting the second
+                 level requirements.
+
+      Countries
+
+         The English two letter code (alpha-2) identifying a country
+         according the the ISO Standard for "Codes for the
+         Representation of Names of Countries" [5].
+
+
+
+
+
+
+Postel & Reynolds                                               [Page 2]
+
+
+
+RFC 920                                                     October 1984
+Domain Requirements
+
+
+      Multiorganizations
+
+         A multiorganization may be a top level domain if it is large,
+         and is composed of other organizations; particularly if the
+         multiorganization can not be easily classified into one of the
+         categories and is international in scope.
+
+Possible Examples of Domains
+
+   The following examples are fictions of the authors' creation, any
+   similarity to the real world is coincidental.
+
+   The UC Domain
+
+      It might be that a large state wide university with, say, nine
+      campuses and several laboratories may want to form a domain.  Each
+      campus or major off-campus laboratory might then be a subdomain,
+      and within each subdomain, each department could be further
+      distinguished.  This university might be a second level domain in
+      the education category.
+
+      One might see domain style names for hosts in this domain like
+      these:
+
+         LOCUS.CS.LA.UC.EDU
+         CCN.OAC.LA.UC.EDU
+         ERNIE.CS.CAL.UC.EDU
+         A.S1.LLNL.UC.EDU
+         A.LAND.LANL.UC.EDU
+         NMM.LBL.CAL.UC.EDU
+
+   The MIT Domain
+
+      Another large university may have many hosts using a variety of
+      machine types, some even using several families of protocols.
+      However, the administrators at this university may see no need for
+      the outside world to be aware of these internal differences.  This
+      university might be a second level domain in the education
+      category.
+
+      One might see domain style names for hosts in this domain like
+      these:
+
+         APIARY-1.MIT.EDU
+         BABY-BLUE.MIT.EDU
+         CEZANNE.MIT.EDU
+         DASH.MIT.EDU
+
+
+Postel & Reynolds                                               [Page 3]
+
+
+
+RFC 920                                                     October 1984
+Domain Requirements
+
+
+         MULTICS.MIT.EDU
+         TAC.MIT.EDU
+         XX.MIT.EDU
+
+   The CSNET Domain
+
+      There may be a consortium of universities and industry research
+      laboratories called, say, "CSNET".  This CSNET is not a network
+      per se, but rather a computer mail exchange using a variety of
+      protocols and network systems.  Therefore, CSNET is not a network
+      in the sense of the ARPANET, or an Ethernet, or even the
+      ARPA-Internet, but rather a community.  Yet it does, in fact, have
+      the key property needed to form a domain; it has a responsible
+      administration.  This consortium might be large enough and might
+      have membership that cuts across the categories in such a way that
+      it qualifies under the "multiorganization rule" to be a top level
+      domain.
+
+      One might see domain style names for hosts in this domain like
+      these:
+
+         CIC.CSNET
+         EMORY.CSNET
+         GATECH.CSNET
+         HP-LABS.CSNET
+         SJ.IBM.CSNET
+         UDEL.CSNET
+         UWISC.CSNET
+
+General Requirements on a Domain
+
+   There are several requirements that must be met to establish a
+   domain.  In general, it must be responsibly managed.  There must be a
+   responsible person to serve as an authoritative coordinator for
+   domain related questions.  There must be a robust domain name lookup
+   service, it must be of at least a minimum size, and the domain must
+   be registered with the central domain administrator (the Network
+   Information Center (NIC) Domain Registrar).
+
+   Responsible Person:
+
+      An individual must be identified who has authority for the
+      administration of the names within the domain, and who seriously
+      takes on the responsibility for the behavior of the hosts in the
+      domain, plus their interactions with hosts outside the domain.
+      This person must have some technical expertise and the authority
+      within the domain to see that problems are fixed.
+
+
+Postel & Reynolds                                               [Page 4]
+
+
+
+RFC 920                                                     October 1984
+Domain Requirements
+
+
+      If a host in a given domain somehow misbehaves in its interactions
+      with hosts outside the domain (e.g., consistently violates
+      protocols), the responsible person for the domain must be
+      competent and available to receive reports of problems, take
+      action on the reported problems, and follow through to eliminate
+      the problems.
+
+   Domain Servers:
+
+      A robust and reliable domain server must be provided.  One way of
+      meeting this requirement is to provide at least two independent
+      domain servers for the domain.  The database can, of course, be
+      the same.  The database can be prepared and copied to each domain
+      server.  But, the servers should be in separate machines on
+      independent power supplies, et cetera; basically as physically
+      independent as can be.  They should have no common point of
+      failure.
+
+      Some domains may find that providing a robust domain service can
+      most easily be done by cooperating with another domain where each
+      domain provides an additional server for the other.
+
+      In other situations, it may be desirable for a domain to arrange
+      for domain service to be provided by a third party, perhaps on
+      hosts located outside the domain.
+
+      One of the difficult problems in operating a domain server is the
+      acquisition and maintenance of the data.  In this case, the data
+      are the host names and addresses.  In some environments this
+      information changes fairly rapidly and keeping up-to-date data may
+      be difficult.  This is one motivation for sub-domains.  One may
+      wish to create sub-domains until the rate of change of the data in
+      a sub-domain domain server database is easily managed.
+
+      In the technical language of the domain server implementation the
+      data is divided into zones.  Domains and zones are not necessarily
+      one-to-one.  It may be reasonable for two or more domains to
+      combine their data in a single zone.
+
+      The responsible person or an identified technical assistant must
+      understand in detail the procedures for operating a domain server,
+      including the management of master files and zones.
+
+      The operation of a domain server should not be taken on lightly.
+      There are some difficult problems in providing an adequate
+      service, primarily the problems in keeping the database up to
+      date, and keeping the service operating.
+
+
+Postel & Reynolds                                               [Page 5]
+
+
+
+RFC 920                                                     October 1984
+Domain Requirements
+
+
+      The concepts and implementation details of the domain server are
+      given in RFC-882 [2] and RFC-883 [3].
+
+   Minimum Size:
+
+      The domain must be of at least a minimum size.  There is no
+      requirement to form a domain because some set of hosts is above
+      the minimum size.
+
+      Top level domains must be specially authorized.  In general, they
+      will only be authorized for domains expected to have over 500
+      hosts.
+
+      The general guideline for a second level domain is that it have
+      over 50 hosts.  This is a very soft "requirement".  It makes sense
+      that any major organization, such as a university or corporation,
+      be allowed as a second level domain -- even if it has just a few
+      hosts.
+
+   Registration:
+
+      Top level domains must be specially authorized and registered with
+      the NIC domain registrar.
+
+      The administrator of a level N domain must register with the
+      registrar (or responsible person) of the level N-1 domain.  This
+      upper level authority must be satisfied that the requirements are
+      met before authorization for the domain is granted.
+
+      The registration procedure involves answering specific questions
+      about the prospective domain.  A prototype of what the NIC Domain
+      Registrar may ask for the registration of a second level domain is
+      shown below.  These questions may change from time to time.  It is
+      the responsibility of domain administrators to keep this
+      information current.
+
+      The administrator of a domain is required to make sure that host
+      and sub-domain names within that jurisdiction conform to the
+      standard name conventions and are unique within that domain.
+
+      If sub-domains are set up, the administrator may wish to pass
+      along some of his authority and responsibility to a sub-domain
+      administrator.  Even if sub-domains are established, the
+      responsible person for the top-level domain is ultimately
+      responsible for the whole tree of sub-domains and hosts.
+
+      This does not mean that a domain administrator has to know the
+
+
+Postel & Reynolds                                               [Page 6]
+
+
+
+RFC 920                                                     October 1984
+Domain Requirements
+
+
+      details of all the sub-domains and hosts to the Nth degree, but
+      simply that if a problem occurs he can get it fixed by calling on
+      the administrator of the sub-domain containing the problem.
+
+Top Level Domain Requirements
+
+   There are very few top level domains, each of these may have many
+   second level domains.
+
+   An initial set of top level names has been identified.  Each of these
+   has an administrator and an agent.
+
+   The top level domains:
+
+      ARPA =  The ARPA-Internet   *** TEMPORARY ***
+
+         Administrator:  DARPA
+         Agent:          The Network Information Center
+         Mailbox:        HOSTMASTER@SRI-NIC.ARPA
+
+      GOV  =  Government
+
+         Administrator:  DARPA
+         Agent:          The Network Information Center
+         Mailbox:        HOSTMASTER@SRI-NIC.ARPA
+
+      EDU  =  Education
+
+         Administrator:  DARPA
+         Agent:          The Network Information Center
+         Mailbox:        HOSTMASTER@SRI-NIC.ARPA
+
+      COM  =  Commercial
+
+         Administrator:  DARPA
+         Agent:          The Network Information Center
+         Mailbox:        HOSTMASTER@SRI-NIC.ARPA
+
+      MIL  =  Military
+
+         Administrator:  DDN-PMO
+         Agent:          The Network Information Center
+         Mailbox:        HOSTMASTER@SRI-NIC.ARPA
+
+
+
+
+
+
+Postel & Reynolds                                               [Page 7]
+
+
+
+RFC 920                                                     October 1984
+Domain Requirements
+
+
+      ORG  =  Organization
+
+         Administrator:  DARPA
+         Agent:          The Network Information Center
+         Mailbox:        HOSTMASTER@SRI-NIC.ARPA
+
+      Countries
+
+         The English two letter code (alpha-2) identifying a country
+         according the the ISO Standard for "Codes for the
+         Representation of Names of Countries" [5].
+
+         As yet no country domains have been established.  As they are
+         established information about the administrators and agents
+         will be made public, and will be listed in subsequent editions
+         of this memo.
+
+      Multiorganizations
+
+         A multiorganization may be a top level domain if it is large,
+         and is composed of other organizations; particularly if the
+         multiorganization can not be easily classified into one of the
+         categories and is international in scope.
+
+         As yet no multiorganization domains have been established.  As
+         they are established information about the administrators and
+         agents will be made public, and will be listed in subsequent
+         editions of this memo.
+
+      Note:  The NIC is listed as the agent and registrar for all the
+      currently allowed top level domains.  If there are other entities
+      that would be more appropriate agents and registrars for some or
+      all of these domains then it would be desirable to reassign the
+      responsibility.
+
+Second Level Domain Requirements
+
+   Each top level domain may have many second level domains.  Every
+   second level domain must meet the general requirements on a domain
+   specified above, and be registered with a top level domain
+   administrator.
+
+
+
+
+
+
+
+
+Postel & Reynolds                                               [Page 8]
+
+
+
+RFC 920                                                     October 1984
+Domain Requirements
+
+
+Third through Nth Level Domain Requirements
+
+   Each second level domain may have many third level domains, etc.
+   Every third level domain (through Nth level domain) must meet the
+   requirements set by the administrator of the immediately higher level
+   domain.  Note that these may be more or less strict than the general
+   requirements.  One would expect the minimum size requirements to
+   decrease at each level.
+
+The ARPA Domain
+
+   At the time the implementation of the domain concept was begun it was
+   thought that the set of hosts under the administrative authority of
+   DARPA would make up a domain.  Thus the initial domain selected was
+   called ARPA.  Now it is seen that there is no strong motivation for
+   there to be a top level ARPA domain.  The plan is for the current
+   ARPA domain to go out of business as soon as possible.  Hosts that
+   are currently members of the ARPA domain should make arrangements to
+   join another domain.  It is likely that for experimental purposes
+   there will be a second level domain called ARPA in the ORG domain
+   (i.e., there will probably be an ARPA.ORG domain).
+
+The DDN Hosts
+
+   DDN hosts that do not desire to participate in this domain naming
+   system will continue to use the HOSTS.TXT data file maintained by the
+   NIC for name to address translations.  This file will be kept up to
+   date for the DDN hosts.  However, all DDN hosts will change their
+   names from "host.ARPA" to (for example) "host.DDN.MIL" some time in
+   the future.  The schedule for changes required in DDN hosts will be
+   established by the DDN-PMO.
+
+Impact on Hosts
+
+   What is a host administrator to do about all this?
+
+      For existing hosts already operating in the ARPA-Internet, the
+      best advice is to sit tight for now.  Take a few months to
+      consider the options, then select a domain to join.  Plan
+      carefully for the impact that changing your host name will have on
+      both your local users and on their remote correspondents.
+
+      For a new host, careful thought should be given (as discussed
+      below).  Some guidance can be obtained by comparing notes on what
+      other hosts with similar administrative properties have done.
+
+   The owner of a host may decide which domain to join, and the
+
+
+Postel & Reynolds                                               [Page 9]
+
+
+
+RFC 920                                                     October 1984
+Domain Requirements
+
+
+   administrator of a domain may decide which hosts to accept into his
+   domain.  Thus the owner of a host and a domain administrator must
+   come to an understanding about the host being in the domain.  This is
+   the foundation of responsible administration.
+
+      For example, a host "XYZ" at MIT might possible be considered as a
+      candidate for becoming any of XYZ.ARPA.ORG, XYZ.CSNET, or
+      XYZ.MIT.EDU.
+
+         The owner of host XYZ may choose which domain to join,
+         depending on which domain administrators are willing to have
+         him.
+
+   The domain is part of the host name.  Thus if USC-ISIA.ARPA changes
+   its domain affiliation to DDN.MIL to become USC-ISIA.DDN.MIL, it has
+   changed its name.  This means that any previous references to
+   USC-ISIA.ARPA are now out of date.  Such old references may include
+   private host name to address tables, and any recorded information
+   about mailboxes such as mailing lists, the headers of old messages,
+   printed directories, and peoples' memories.
+
+   The experience of the DARPA community suggests that changing the name
+   of a host is somewhat painful.  It is recommended that careful
+   thought be given to choosing a new name for a host - which includes
+   selecting its place in the domain hierarchy.
+
+The Roles of the Network Information Center
+
+   The NIC plays two types of roles in the administration of domains.
+   First,  the NIC is the registrar of all top level domains.  Second
+   the NIC is the administrator of several top level domains (and the
+   registrar for second level domains in these).
+
+   Top Level Domain Registrar
+
+      As the registrar for top level domains, the NIC is the contact
+      point for investigating the possibility of establishing a new top
+      level domain.
+
+   Top Level Domain Administrator
+
+      For the top level domains designated so far, the NIC is the
+      administrator of each of these domains.  This means the NIC is
+      responsible for the management of these domains and the
+      registration of the second level domains or hosts (if at the
+      second level) in these domains.
+
+
+
+Postel & Reynolds                                              [Page 10]
+
+
+
+RFC 920                                                     October 1984
+Domain Requirements
+
+
+      It may be reasonable for the administration of some of these
+      domains to be taken on by other authorities in the future.  It is
+      certainly not desired that the NIC be the administrator of all top
+      level domains forever.
+
+Prototypical Questions
+
+   To establish a domain, the following information must be provided to
+   the NIC Domain Registrar (HOSTMASTER@SRI-NIC.ARPA):
+
+      Note:  The key people must have computer mail mailboxes and
+      NIC-Idents.  If they do not at present, please remedy the
+      situation at once.  A NIC-Ident may be established by contacting
+      NIC@SRI-NIC.ARPA.
+
+   1)  The name of the top level domain to join.
+
+      For example:  EDU
+
+   2)  The name, title, mailing address, phone number, and organization
+   of the administrative head of the organization.  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.  The online mailbox and NIC-Ident of this person should
+   also be included.
+
+      For example:
+
+         Administrator
+
+            Organization  USC/Information Sciences Institute
+            Name          Keith Uncapher
+            Title         Executive Director
+            Mail Address  USC/ISI
+                          4676 Admiralty Way, Suite 1001
+                          Marina del Rey, CA. 90292-6695
+            Phone Number  213-822-1511
+            Net Mailbox   Uncapher@USC-ISIB.ARPA
+            NIC-Ident     KU
+
+   3)  The name, title, mailing address, phone number, and organization
+   of the domain technical contact.  The online mailbox and NIC-Ident of
+   the domain technical contact should also be included.  This is the
+   contact point for problems with the domain and for updating
+   information about the domain.  Also, the domain technical contact may
+   be responsible for hosts in this domain.
+
+
+
+Postel & Reynolds                                              [Page 11]
+
+
+
+RFC 920                                                     October 1984
+Domain Requirements
+
+
+      For example:
+
+         Technical Contact
+
+            Organization  USC/Information Sciences Institute
+            Name          Craig Milo Rogers
+            Title         Researcher
+            Mail Address  USC/ISI
+                          4676 Admiralty Way, Suite 1001
+                          Marina del Rey, CA. 90292-6695
+            Phone Number  213-822-1511
+            Net Mailbox   Rogers@USC-ISIB.ARPA
+            NIC-Ident     CMR
+
+   4)  The name, title, mailing address, phone number, and organization
+   of the zone technical contact.  The online mailbox and NIC-Ident of
+   the zone technical contact should also be included.  This is the
+   contact point for problems with the zone and for updating information
+   about the zone.  In many cases the zone technical contact and the
+   domain technical contact will be the same person.
+
+      For example:
+
+         Technical Contact
+
+            Organization  USC/Information Sciences Institute
+            Name          Craig Milo Rogers
+            Title         Researcher
+            Mail Address  USC/ISI
+                          4676 Admiralty Way, Suite 1001
+                          Marina del Rey, CA. 90292-6695
+            Phone Number  213-822-1511
+            Net Mailbox   Rogers@USC-ISIB.ARPA
+            NIC-Ident     CMR
+
+   5)  The name of the domain (up to 12 characters).  This is the name
+   that will be used in tables and lists associating the domain and the
+   domain server addresses.  [While technically domain names can be
+   quite long (programmers beware), shorter names are easier for people
+   to cope with.]
+
+      For example:  ALPHA-BETA
+
+   6)  A description of the servers that provides the domain service for
+   translating name to address for hosts in this domain, and the date
+   they will be operational.
+
+
+
+Postel & Reynolds                                              [Page 12]
+
+
+
+RFC 920                                                     October 1984
+Domain Requirements
+
+
+      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 server operated by
+         the NIC, and will be installed and made operational on
+         1-November-84.
+
+   7)  A description of the server machines, including:
+
+      (a) hardware and software (using keywords from the Assigned
+      Numbers)
+
+      (b) addresses (what host on what net for each connected net)
+
+      For example:
+
+         (a) hardware and software
+
+            VAX-11/750  and  UNIX,    or
+            IBM-PC      and  MS-DOS,  or
+            DEC-1090    and  TOPS-20
+
+         (b) address
+
+            10.9.0.193 on ARPANET
+
+   8)  An estimate of the number of hosts that will be in the domain.
+
+      (a) initially,
+      (b) within one year,
+      (c) two years, and
+      (d) five years.
+
+      For example:
+
+         (a) initially  =   50
+         (b) one year   =  100
+         (c) two years  =  200
+         (d) five years =  500
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 13]
+
+
+
+RFC 920                                                     October 1984
+Domain Requirements
+
+
+Acknowledgment
+
+   We would like to thank the many people who contributed to this memo,
+   including the participants in the Namedroppers Group, the ICCB, the
+   PCCB, and especially the staff of the Network Information Center,
+   particularly J. Feinler and K. Harrenstien.
+
+References
+
+   [1]  Postel, J., "The Domain Names Plan and Schedule", RFC-881, USC
+        Information Sciences Institute, November 1983.
+
+   [2]  Mockapetris, P., "Domain Names - Concepts and Facilities",
+        RFC-882, USC Information Sciences Institute, November 1983.
+
+   [3]  Mockapetris, P., "Domain Names - Implementation and
+        Specification", RFC-883, USC Information Sciences Institute,
+        November 1983.
+
+   [4]  Postel, J., "Domain Name System Implementation Schedule",
+        RFC-897, USC Information Sciences Institute, February 1984.
+
+   [5]  ISO, "Codes for the Representation of Names of Countries",
+        ISO-3166, International Standards Organization, May 1981.
+
+   [6]  Postel, J., "Domain Name System Implementation Schedule -
+        Revised", RFC-921, USC Information Sciences Institute, October
+        1984.
+
+   [7]  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 1984.
+
+   [8]  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.
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 14]
+
diff --git a/usr.sbin/named/doc/rfc/rfc974 b/usr.sbin/named/doc/rfc/rfc974
new file mode 100644
index 00000000000..97d79a4fa4c
--- /dev/null
+++ b/usr.sbin/named/doc/rfc/rfc974
@@ -0,0 +1,399 @@
+
+
+Network Working Group                                    Craig Partridge
+Request for Comments: 974                 CSNET CIC BBN Laboratories Inc
+                                                            January 1986
+
+                   MAIL ROUTING AND THE DOMAIN SYSTEM
+
+
+Status of this Memo
+
+   This RFC presents a description of how mail systems on the Internet
+   are expected to route messages based on information from the domain
+   system described in RFCs 882, 883 and 973.  Distribution of this memo
+   is unlimited.
+
+Introduction
+
+   The purpose of this memo is to explain how mailers are to decide how
+   to route a message addressed to a given Internet domain name.  This
+   involves a discussion of how mailers interpret MX RRs, which are used
+   for message routing.  Note that this memo makes no statement about
+   how mailers are to deal with MB and MG RRs, which are used for
+   interpreting mailbox names.
+
+   Under RFC-882 and RFC-883 certain assumptions about mail addresses
+   have been changed.  Up to now, one could usually assume that if a
+   message was addressed to a mailbox, for example, at LOKI.BBN.COM,
+   that one could just open an SMTP connection to LOKI.BBN.COM and pass
+   the message along.  This system broke down in certain situations,
+   such as for certain UUCP and CSNET hosts which were not directly
+   attached to the Internet, but these hosts could be handled as special
+   cases in configuration files (for example, most mailers were set up
+   to automatically forward mail addressed to a CSNET host to
+   CSNET-RELAY.ARPA).
+
+   Under domains, one cannot simply open a connection to LOKI.BBN.COM,
+   but must instead ask the domain system where messages to LOKI.BBN.COM
+   are to be delivered. And the domain system may direct a mailer to
+   deliver messages to an entirely different host, such as SH.CS.NET.
+   Or, in a more complicated case, the mailer may learn that it has a
+   choice of routes to LOKI.BBN.COM.  This memo is essentially a set of
+   guidelines on how mailers should behave in this more complex world.
+
+   Readers are expected to be familiar with RFCs 882, 883, and the
+   updates to them (e.g., RFC-973).
+
+
+
+
+
+
+
+
+
+Partridge                                                       [Page 1]
+
+
+
+RFC 974                                                     January 1986
+Mail Routing and the Domain System
+
+
+What the Domain Servers Know
+
+   The domain servers store information as a series of resource records
+   (RRs), each of which contains a particular piece of information about
+   a given domain name (which is usually, but not always, a host).  The
+   simplest way to think of a RR is as a typed pair of datum, a domain
+   name matched with relevant data, and stored with some additional type
+   information to help systems determine when the RR is relevant.  For
+   the purposes of message routing, the system stores RRs known as MX
+   RRs. Each MX matches a domain name with two pieces of data, a
+   preference value (an unsigned 16-bit integer), and the name of a
+   host.  The preference number is used to indicate in what order the
+   mailer should attempt deliver to the MX hosts, with the lowest
+   numbered MX being the one to try first.  Multiple MXs with the same
+   preference are permitted and have the same priority.
+
+   In addition to mail information, the servers store certain other
+   types of RR's which mailers may encounter or choose to use.  These
+   are: the canonical name (CNAME) RR, which simply states that the
+   domain name queried for is actually an alias for another domain name,
+   which is the proper, or canonical, name; and the Well Known Service
+   (WKS) RR, which stores information about network services (such as
+   SMTP) a given domain name supports.
+
+General Routing Guidelines
+
+   Before delving into a detailed discussion of how mailers are expected
+   to do mail routing, it would seem to make sense to give a brief
+   overview of how this memo is approaching the problems that routing
+   poses.
+
+   The first major principle is derived from the definition of the
+   preference field in MX records, and is intended to prevent mail
+   looping.  If the mailer is on a host which is listed as an MX for the
+   destination host, the mailer may only deliver to an MX which has a
+   lower preference count than its own host.
+
+   It is also possible to cause mail looping because routing information
+   is out of date or incomplete.  Out of date information is only a
+   problem when domain tables are changed.  The changes will not be
+   known to all affected hosts until their resolver caches time out.
+   There is no way to ensure that this will not happen short of
+   requiring mailers and their resolvers to always send their queries to
+   an authoritative server, and never use data stored in a cache.  This
+   is an impractical solution, since eliminating resolver caching would
+   make mailing inordinately expensive.  What is more, the out-of-date
+   RR problem should not happen if, when a domain table is changed,
+
+
+Partridge                                                       [Page 2]
+
+
+
+RFC 974                                                     January 1986
+Mail Routing and the Domain System
+
+
+   affected hosts (those in the list of MXs) have their resolver caches
+   flushed. In other words, given proper precautions, mail looping as a
+   result of domain information should be avoidable, without requiring
+   mailers to query authoritative servers.  (The appropriate precaution
+   is to check with a host's administrator before adding that host to a
+   list of MXs).
+
+   The incomplete data problem also requires some care when handling
+   domain queries.  If the answer section of a query is incomplete
+   critical MX RRs may be left out.  This may result in mail looping, or
+   in a message being mistakenly labelled undeliverable.  As a result,
+   mailers may only accept responses from the domain system which have
+   complete answer sections.  Note that this entire problem can be
+   avoided by only using virtual circuits for queries, but since this
+   situation is likely to be very rare and datagrams are the preferred
+   way to interact with the domain system, implementors should probably
+   just ensure that their mailer will repeat a query with virtual
+   circuits should the truncation bit ever be set.
+
+Determining Where to Send a Message
+
+   The explanation of how mailers should decide how to route a message
+   is discussed in terms of the problem of a mailer on a host with
+   domain name LOCAL trying to deliver a message addressed to the domain
+   name REMOTE. Both LOCAL and REMOTE are assumed to be syntactically
+   correct domain names.  Furthermore, LOCAL is assumed to be the
+   official name for the host on which the mailer resides (i.e., it is
+   not a alias).
+
+Issuing a Query
+
+   The first step for the mailer at LOCAL is to issue a query for MX RRs
+   for REMOTE.  It is strongly urged that this step be taken every time
+   a mailer attempts to send the message.  The hope is that changes in
+   the domain database will rapidly be used by mailers, and thus domain
+   administrators will be able to re-route in-transit messages for
+   defective hosts by simply changing their domain databases.
+
+   Certain responses to the query are considered errors:
+
+      Getting no response to the query.  The domain server the mailer
+      queried never sends anything back.  (This is distinct from an
+      answer which contains no answers to the query, which is not an
+      error).
+
+      Getting a response in which the truncation field of the header is
+
+
+
+Partridge                                                       [Page 3]
+
+
+
+RFC 974                                                     January 1986
+Mail Routing and the Domain System
+
+
+      set.  (Recall discussion of incomplete queries above).  Mailers
+      may not use responses of this type, and should repeat the query
+      using virtual circuits instead of datagrams.
+
+      Getting a response in which the response code is non-zero.
+
+   Mailers are expected to do something reasonable in the face of an
+   error.  The behaviour for each type of error is not specified here,
+   but implementors should note that different types of errors should
+   probably be treated differently.  For example, a response code of
+   "non-existent domain" should probably cause the message to be
+   returned to the sender as invalid, while a response code of "server
+   failure" should probably cause the message to be retried later.
+
+   There is one other special case.  If the response contains an answer
+   which is a CNAME RR, it indicates that REMOTE is actually an alias
+   for some other domain name. The query should be repeated with the
+   canonical domain name.
+
+   If the response does not contain an error response, and does not
+   contain aliases, its answer section should be a (possibly zero
+   length) list of MX RRs for domain name REMOTE (or REMOTE's true
+   domain name if REMOTE was a alias).  The next section describes how
+   this list is interpreted.
+
+Interpreting the List of MX RRs
+
+   NOTE: This section only discusses how mailers choose which names to
+   try to deliver a message to, working from a list of RR's.  It does
+   not discuss how the mailers actually make delivery.  Where ever
+   delivering a message is mentioned, all that is meant is that the
+   mailer should do whatever it needs to do to transfer a message to a
+   remote site, given a domain name for that site.  (For example, an
+   SMTP mailer will try to get an address for the domain name, which
+   involves another query to the domain system, and then, if it gets an
+   address, connect to the SMTP TCP port).  The mechanics of actually
+   transferring the message over the network to the address associated
+   with a given domain name is not within the scope of this memo.
+
+   It is possible that the list of MXs in the response to the query will
+   be empty.  This is a special case.  If the list is empty, mailers
+   should treat it as if it contained one RR, an MX RR with a preference
+   value of 0, and a host name of REMOTE.  (I.e., REMOTE is its only
+   MX).  In addition, the mailer should do no further processing on the
+   list, but should attempt to deliver the message to REMOTE.  The idea
+
+
+
+
+Partridge                                                       [Page 4]
+
+
+
+RFC 974                                                     January 1986
+Mail Routing and the Domain System
+
+
+   here is that if a domain fails to advertise any information about a
+   particular name we will give it the benefit of the doubt and attempt
+   delivery.
+
+   If the list is not empty, the mailer should remove irrelevant RR's
+   from the list according to the following steps.  Note that the order
+   is significant.
+
+      For each MX, a WKS query should be issued to see if the domain
+      name listed actually supports the mail service desired.  MX RRs
+      which list domain names which do not support the service should be
+      discarded.  This step is optional, but strongly encouraged.
+
+      If the domain name LOCAL is listed as an MX RR, all MX RRs with a
+      preference value greater than or equal to that of LOCAL's must be
+      discarded.
+
+   After removing irrelevant RRs, the list can again be empty.  This is
+   now an error condition and can occur in several ways.  The simplest
+   case is that the WKS queries have discovered that none of the hosts
+   listed supports the mail service desired.  The message is thus deemed
+   undeliverable, though extremely persistent mail systems might want to
+   try a delivery to REMOTE's address (if it exists) before returning
+   the message. Another, more dangerous, possibility is that the domain
+   system believes that LOCAL is handling message for REMOTE, but the
+   mailer on LOCAL is not set up to handle mail for REMOTE.  For
+   example, if the domain system lists LOCAL as the only MX for REMOTE,
+   LOCAL will delete all the entries in the list.  But LOCAL is
+   presumably querying the domain system because it didn't know what to
+   do with a message addressed to REMOTE. Clearly something is wrong.
+   How a mailer chooses to handle these situations is to some extent
+   implementation dependent, and is thus left to the implementor's
+   discretion.
+
+   If the list of MX RRs is not empty, the mailer should try to deliver
+   the message to the MXs in order (lowest preference value tried
+   first).  The mailer is required to attempt delivery to the lowest
+   valued MX.  Implementors are encouraged to write mailers so that they
+   try the MXs in order until one of the MXs accepts the message, or all
+   the MXs have been tried.  A somewhat less demanding system, in which
+   a fixed number of MXs is tried, is also reasonable.  Note that
+   multiple MXs may have the same preference value.  In this case, all
+   MXs at with a given value must be tried before any of a higher value
+   are tried.  In addition, in the special case in which there are
+   several MXs with the lowest preference value,  all of them should be
+   tried before a message is deemed undeliverable.
+
+
+
+Partridge                                                       [Page 5]
+
+
+
+RFC 974                                                     January 1986
+Mail Routing and the Domain System
+
+
+Minor Special Issues
+
+   There are a couple of special issues left out of the preceding
+   section because they complicated the discussion.  They are treated
+   here in no particular order.
+
+   Wildcard names, those containing the character '*' in them, may be
+   used for mail routing.  There are likely to be servers on the network
+   which simply state that any mail to a domain is to be routed through
+   a relay. For example, at the time that this RFC is being written, all
+   mail to hosts in the domain IL is routed through RELAY.CS.NET.  This
+   is done by creating a wildcard RR, which states that *.IL has an MX
+   of RELAY.CS.NET.  This should be transparent to the mailer since the
+   domain servers will hide this wildcard match. (If it matches *.IL
+   with HUJI.IL for example, a domain server will return an RR
+   containing HUJI.IL, not *.IL). If by some accident a mailer receives
+   an RR with a wildcard domain name in its name or data section it
+   should discard the RR.
+
+   Note that the algorithm to delete irrelevant RRs breaks if LOCAL has
+   a alias and the alias is listed in the MX records for REMOTE.  (E.g.
+   REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL).  This
+   can be avoided if aliases are never used in the data section of MX
+   RRs.
+
+   Implementors should understand that the query and interpretation of
+   the query is only performed for REMOTE.  It is not repeated for the
+   MX RRs listed for REMOTE.  You cannot try to support more extravagant
+   mail routing by building a chain of MXs.  (E.g. UNIX.BBN.COM is an MX
+   for RELAY.CS.NET and RELAY.CS.NET is an MX for all the hosts in .IL,
+   but this does not mean that UNIX.BBN.COM accepts any responsibility
+   for mail for .IL).
+
+   Finally, it should be noted that this is a standard for routing on
+   the Internet.  Mailers serving hosts which lie on multiple networks
+   will presumably have to make some decisions about which network to
+   route through. This decision making is outside the scope of this
+   memo, although mailers may well use the domain system to help them
+   decide.  However, once a mailer decides to deliver a message via the
+   Internet it must apply these rules to route the message.
+
+
+
+
+
+
+
+
+
+Partridge                                                       [Page 6]
+
+
+
+RFC 974                                                     January 1986
+Mail Routing and the Domain System
+
+
+Examples
+
+   To illustrate the discussion above, here are three examples of how
+   mailers should route messages.  All examples work with the following
+   database:
+
+      A.EXAMPLE.ORG    IN    MX    10    A.EXAMPLE.ORG
+      A.EXAMPLE.ORG    IN    MX    15    B.EXAMPLE.ORG
+      A.EXAMPLE.ORG    IN    MX    20    C.EXAMPLE.ORG
+      A.EXAMPLE.ORG    IN    WKS   10.0.0.1    TCP    SMTP
+
+      B.EXAMPLE.ORG    IN    MX    0      B.EXAMPLE.ORG
+      B.EXAMPLE.ORG    IN    MX    10     C.EXAMPLE.ORG
+      B.EXAMPLE.ORG    IN    WKS   10.0.0.2    TCP    SMTP
+
+      C.EXAMPLE.ORG    IN    MX    0     C.EXAMPLE.ORG
+      C.EXAMPLE.ORG    IN    WKS   10.0.0.3    TCP    SMTP
+
+      D.EXAMPLE.ORG    IN    MX    0     D.EXAMPLE.ORG
+      D.EXAMPLE.ORG    IN    MX    0     C.EXAMPLE.ORG
+      D.EXAMPLE.ORG    IN    WKS   10.0.0.4    TCP    SMTP
+
+   In the first example, an SMTP mailer on D.EXAMPLE.ORG is trying to
+   deliver a message addressed to A.EXAMPLE.ORG. From the answer to its
+   query, it learns that A.EXAMPLE.ORG has three MX RRs.  D.EXAMPLE.ORG
+   is not one of the MX RRs and all three MXs support SMTP mail
+   (determined from the WKS entries), so none of the MXs are eliminated.
+   The mailer is obliged to try to deliver to A.EXAMPLE.ORG as the
+   lowest valued MX.  If it cannot reach A.EXAMPLE.ORG it can (but is
+   not required to) try B.EXAMPLE.ORG. and if B.EXAMPLE.ORG is not
+   responding, it can try C.EXAMPLE.ORG.
+
+   In the second example, the mailer is on B.EXAMPLE.ORG, and is again
+   trying to deliver a message addressed to A.EXAMPLE.ORG.  There are
+   once again three MX RRs for A.EXAMPLE.ORG, but in this case the
+   mailer must discard the RRs for itself and C.EXAMPLE.ORG (because the
+   MX RR for C.EXAMPLE.ORG has a higher preference value than the RR for
+   B.EXAMPLE.ORG).  It is left only with the RR for A.EXAMPLE.ORG, and
+   can only try delivery to A.EXAMPLE.ORG.
+
+   In the third example, consider a mailer on A.EXAMPLE.ORG trying to
+   deliver a message to D.EXAMPLE.ORG.  In this case there are only two
+   MX RRs, both with the same preference value.  Either MX will accept
+   messages for D.EXAMPLE.ORG. The mailer should try one MX first (which
+   one is up to the mailer, though D.EXAMPLE.ORG seems most reasonable),
+   and if that delivery fails should try the other MX (e.g.
+   C.EXAMPLE.ORG).
+
+
+Partridge                                                       [Page 7]
+