diff options
Diffstat (limited to 'doc/rfc/rfc1183.txt')
| -rw-r--r-- | doc/rfc/rfc1183.txt | 619 |
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 |