doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc1183.txt b/doc/rfc/rfc1183.txt
new file mode 100644
index 0000000..6f08044
--- /dev/null
+++ b/doc/rfc/rfc1183.txt
@@ -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