rfc1183.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 619 行 · 第 1/2 页
TXT
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.
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?