New DNS RR Definitions
RFC 1183
|
| Document |
Type |
|
RFC - Experimental
(October 1990; Errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Legacy
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
| IESG |
IESG state |
|
RFC 1183 (Experimental)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
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.
Show full document text