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