home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1100s / rfc1183.txt < prev    next >
Text File  |  1990-10-07  |  23KB  |  619 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        C. Everhart
  8. Request for Comments: 1183                                      Transarc
  9. Updates: RFCs 1034, 1035                                      L. Mamakos
  10.                                                   University of Maryland
  11.                                                               R. Ullmann
  12.                                                           Prime Computer
  13.                                                   P. Mockapetris, Editor
  14.                                                                      ISI
  15.                                                             October 1990
  16.  
  17.  
  18.                          New DNS RR Definitions
  19.  
  20. Status of this Memo
  21.  
  22.    This memo defines five new DNS types for experimental purposes.  This
  23.    RFC describes an Experimental Protocol for the Internet community,
  24.    and requests discussion and suggestions for improvements.
  25.    Distribution of this memo is unlimited.
  26.  
  27. Table of Contents
  28.  
  29.    Introduction....................................................    1
  30.    1. AFS Data Base location.......................................    2
  31.    2. Responsible Person...........................................    3
  32.    2.1. Identification of the guilty party.........................    3
  33.    2.2. The Responsible Person RR..................................    4
  34.    3. X.25 and ISDN addresses, Route Binding.......................    6
  35.    3.1. The X25 RR.................................................    6
  36.    3.2. The ISDN RR................................................    7
  37.    3.3. The Route Through RR.......................................    8
  38.    REFERENCES and BIBLIOGRAPHY.....................................    9
  39.    Security Considerations.........................................   10
  40.    Authors' Addresses..............................................   11
  41.  
  42. Introduction
  43.  
  44.    This RFC defines the format of new Resource Records (RRs) for the
  45.    Domain Name System (DNS), and reserves corresponding DNS type
  46.    mnemonics and numerical codes.  The definitions are in three
  47.    independent sections: (1) location of AFS database servers, (2)
  48.    location of responsible persons, and (3) representation of X.25 and
  49.    ISDN addresses and route binding.  All are experimental.
  50.  
  51.    This RFC assumes that the reader is familiar with the DNS [3,4].  The
  52.    data shown is for pedagogical use and does not necessarily reflect
  53.    the real Internet.
  54.  
  55.  
  56.  
  57.  
  58. Everhart, Mamakos, Ullmann & Mockapetris                        [Page 1]
  59.  
  60. RFC 1183                 New DNS RR Definitions             October 1990
  61.  
  62.  
  63. 1. AFS Data Base location
  64.  
  65.    This section defines an extension of the DNS to locate servers both
  66.    for AFS (AFS is a registered trademark of Transarc Corporation) and
  67.    for the Open Software Foundation's (OSF) Distributed Computing
  68.    Environment (DCE) authenticated naming system using HP/Apollo's NCA,
  69.    both to be components of the OSF DCE.  The discussion assumes that
  70.    the reader is familiar with AFS [5] and NCA [6].
  71.  
  72.    The AFS (originally the Andrew File System) system uses the DNS to
  73.    map from a domain name to the name of an AFS cell database server.
  74.    The DCE Naming service uses the DNS for a similar function: mapping
  75.    from the domain name of a cell to authenticated name servers for that
  76.    cell.  The method uses a new RR type with mnemonic AFSDB and type
  77.    code of 18 (decimal).
  78.  
  79.    AFSDB has the following format:
  80.  
  81.    <owner> <ttl> <class> AFSDB <subtype> <hostname>
  82.  
  83.    Both RDATA fields are required in all AFSDB RRs.  The <subtype> field
  84.    is a 16 bit integer.  The <hostname> field is a domain name of a host
  85.    that has a server for the cell named by the owner name of the RR.
  86.  
  87.    The format of the AFSDB RR is class insensitive.  AFSDB records cause
  88.    type A additional section processing for <hostname>.  This, in fact,
  89.    is the rationale for using a new type code, rather than trying to
  90.    build the same functionality with TXT RRs.
  91.  
  92.    Note that the format of AFSDB in a master file is identical to MX.
  93.    For purposes of the DNS itself, the subtype is merely an integer.
  94.    The present subtype semantics are discussed below, but changes are
  95.    possible and will be announced in subsequent RFCs.
  96.  
  97.    In the case of subtype 1, the host has an AFS version 3.0 Volume
  98.    Location Server for the named AFS cell.  In the case of subtype 2,
  99.    the host has an authenticated name server holding the cell-root
  100.    directory node for the named DCE/NCA cell.
  101.  
  102.    The use of subtypes is motivated by two considerations.  First, the
  103.    space of DNS RR types is limited.  Second, the services provided are
  104.    sufficiently distinct that it would continue to be confusing for a
  105.    client to attempt to connect to a cell's servers using the protocol
  106.    for one service, if the cell offered only the other service.
  107.  
  108.    As an example of the use of this RR, suppose that the Toaster
  109.    Corporation has deployed AFS 3.0 but not (yet) the OSF's DCE.  Their
  110.    cell, named toaster.com, has three "AFS 3.0 cell database server"
  111.  
  112.  
  113.  
  114. Everhart, Mamakos, Ullmann & Mockapetris                        [Page 2]
  115.  
  116. RFC 1183                 New DNS RR Definitions             October 1990
  117.  
  118.  
  119.    machines: bigbird.toaster.com, ernie.toaster.com, and
  120.    henson.toaster.com.  These three machines would be listed in three
  121.    AFSDB RRs.  These might appear in a master file as:
  122.  
  123.    toaster.com.   AFSDB   1 bigbird.toaster.com.
  124.    toaster.com.   AFSDB   1 ernie.toaster.com.
  125.    toaster.com.   AFSDB   1 henson.toaster.com.
  126.  
  127.    As another example use of this RR, suppose that Femto College (domain
  128.    name femto.edu) has deployed DCE, and that their DCE cell root
  129.    directory is served by processes running on green.femto.edu and
  130.    turquoise.femto.edu.  Furthermore, their DCE file servers also run
  131.    AFS 3.0-compatible volume location servers, on the hosts
  132.    turquoise.femto.edu and orange.femto.edu.  These machines would be
  133.    listed in four AFSDB RRs, which might appear in a master file as:
  134.  
  135.    femto.edu.   AFSDB   2 green.femto.edu.
  136.    femto.edu.   AFSDB   2 turquoise.femto.edu.
  137.    femto.edu.   AFSDB   1 turquoise.femto.edu.
  138.    femto.edu.   AFSDB   1 orange.femto.edu.
  139.  
  140. 2. Responsible Person
  141.  
  142.    The purpose of this section is to provide a standard method for
  143.    associating responsible person identification to any name in the DNS.
  144.  
  145.    The domain name system functions as a distributed database which
  146.    contains many different form of information.  For a particular name
  147.    or host, you can discover it's Internet address, mail forwarding
  148.    information, hardware type and operating system among others.
  149.  
  150.    A key aspect of the DNS is that the tree-structured namespace can be
  151.    divided into pieces, called zones, for purposes of distributing
  152.    control and responsibility.  The responsible person for zone database
  153.    purposes is named in the SOA RR for that zone.  This section
  154.    describes an extension which allows different responsible persons to
  155.    be specified for different names in a zone.
  156.  
  157. 2.1. Identification of the guilty party
  158.  
  159.    Often it is desirable to be able to identify the responsible entity
  160.    for a particular host.  When that host is down or malfunctioning, it
  161.    is difficult to contact those parties which might resolve or repair
  162.    the host.  Mail sent to POSTMASTER may not reach the person in a
  163.    timely fashion.  If the host is one of a multitude of workstations,
  164.    there may be no responsible person which can be contacted on that
  165.    host.
  166.  
  167.  
  168.  
  169.  
  170. Everhart, Mamakos, Ullmann & Mockapetris                        [Page 3]
  171.  
  172. RFC 1183                 New DNS RR Definitions             October 1990
  173.  
  174.  
  175.    The POSTMASTER mailbox on that host continues to be a good contact
  176.    point for mail problems, and the zone contact in the SOA record for
  177.    database problem, but the RP record allows us to associate a mailbox
  178.    to entities that don't receive mail or are not directly connected
  179.    (namespace-wise) to the problem (e.g., GATEWAY.ISI.EDU might want to
  180.    point at HOTLINE@BBN.COM, and GATEWAY doesn't get mail, nor does the
  181.    ISI zone administrator have a clue about fixing gateways).
  182.  
  183. 2.2. The Responsible Person RR
  184.  
  185.    The method uses a new RR type with mnemonic RP and type code of 17
  186.    (decimal).
  187.  
  188.    RP has the following format:
  189.  
  190.    <owner> <ttl> <class> RP <mbox-dname> <txt-dname>
  191.  
  192.    Both RDATA fields are required in all RP RRs.
  193.  
  194.    The first field, <mbox-dname>, is a domain name that specifies the
  195.    mailbox for the responsible person.  Its format in master files uses
  196.    the DNS convention for mailbox encoding, identical to that used for
  197.    the RNAME mailbox field in the SOA RR.  The root domain name (just
  198.    ".") may be specified for <mbox-dname> to indicate that no mailbox is
  199.    available.
  200.  
  201.    The second field, <txt-dname>, is a domain name for which TXT RR's
  202.    exist.  A subsequent query can be performed to retrieve the
  203.    associated TXT resource records at <txt-dname>.  This provides a
  204.    level of indirection so that the entity can be referred to from
  205.    multiple places in the DNS.  The root domain name (just ".") may be
  206.    specified for <txt-dname> to indicate that the TXT_DNAME is absent,
  207.    and no associated TXT RR exists.
  208.  
  209.    The format of the RP RR is class insensitive.  RP records cause no
  210.    additional section processing.  (TXT additional section processing
  211.    for <txt-dname> is allowed as an option, but only if it is disabled
  212.    for the root, i.e., ".").
  213.  
  214.    The Responsible Person RR can be associated with any node in the
  215.    Domain Name System hierarchy, not just at the leaves of the tree.
  216.  
  217.    The TXT RR associated with the TXT_DNAME contain free format text
  218.    suitable for humans.  Refer to [4] for more details on the TXT RR.
  219.  
  220.    Multiple RP records at a single name may be present in the database.
  221.    They should have identical TTLs.
  222.  
  223.  
  224.  
  225.  
  226. Everhart, Mamakos, Ullmann & Mockapetris                        [Page 4]
  227.  
  228. RFC 1183                 New DNS RR Definitions             October 1990
  229.  
  230.  
  231.    EXAMPLES
  232.  
  233.    Some examples of how the RP record might be used.
  234.  
  235.    sayshell.umd.edu. A     128.8.1.14
  236.                      MX    10 sayshell.umd.edu.
  237.                      HINFO NeXT UNIX
  238.                      WKS   128.8.1.14 tcp ftp telnet smtp
  239.                      RP    louie.trantor.umd.edu.  LAM1.people.umd.edu.
  240.  
  241.    LAM1.people.umd.edu. TXT (
  242.          "Louis A. Mamakos, (301) 454-2946, don't call me at home!" )
  243.  
  244.    In this example, the responsible person's mailbox for the host
  245.    SAYSHELL.UMD.EDU is louie@trantor.umd.edu.  The TXT RR at
  246.    LAM1.people.umd.edu provides additional information and advice.
  247.  
  248.    TERP.UMD.EDU.    A     128.8.10.90
  249.                     MX    10 128.8.10.90
  250.                     HINFO MICROVAX-II UNIX
  251.                     WKS   128.8.10.90 udp domain
  252.                     WKS   128.8.10.90 tcp ftp telnet smtp domain
  253.                     RP    louie.trantor.umd.edu. LAM1.people.umd.edu.
  254.                     RP    root.terp.umd.edu. ops.CS.UMD.EDU.
  255.  
  256.    TRANTOR.UMD.EDU. A     128.8.10.14
  257.                     MX    10 trantor.umd.edu.
  258.                     HINFO MICROVAX-II UNIX
  259.                     WKS   128.8.10.14 udp domain
  260.                     WKS   128.8.10.14 tcp ftp telnet smtp domain
  261.                     RP    louie.trantor.umd.edu. LAM1.people.umd.edu.
  262.                     RP    petry.netwolf.umd.edu. petry.people.UMD.EDU.
  263.                     RP    root.trantor.umd.edu. ops.CS.UMD.EDU.
  264.                     RP    gregh.sunset.umd.edu.  .
  265.  
  266.    LAM1.people.umd.edu.  TXT   "Louis A. Mamakos (301) 454-2946"
  267.    petry.people.umd.edu. TXT   "Michael G. Petry (301) 454-2946"
  268.    ops.CS.UMD.EDU.       TXT   "CS Operations Staff (301) 454-2943"
  269.  
  270.    This set of resource records has two hosts, TRANTOR.UMD.EDU and
  271.    TERP.UMD.EDU, as well as a number of TXT RRs.  Note that TERP.UMD.EDU
  272.    and TRANTOR.UMD.EDU both reference the same pair of TXT resource
  273.    records, although the mail box names (root.terp.umd.edu and
  274.    root.trantor.umd.edu) differ.
  275.  
  276.    Here, we obviously care much more if the machine flakes out, as we've
  277.    specified four persons which might want to be notified of problems or
  278.    other events involving TRANTOR.UMD.EDU.  In this example, the last RP
  279.  
  280.  
  281.  
  282. Everhart, Mamakos, Ullmann & Mockapetris                        [Page 5]
  283.  
  284. RFC 1183                 New DNS RR Definitions             October 1990
  285.  
  286.  
  287.    RR for TRANTOR.UMD.EDU specifies a mailbox (gregh.sunset.umd.edu),
  288.    but no associated TXT RR.
  289.  
  290. 3. X.25 and ISDN addresses, Route Binding
  291.  
  292.    This section describes an experimental representation of X.25 and
  293.    ISDN addresses in the DNS, as well as a route binding method,
  294.    analogous to the MX for mail routing, for very large scale networks.
  295.  
  296.    There are several possible uses, all experimental at this time.
  297.    First, the RRs provide simple documentation of the correct addresses
  298.    to use in static configurations of IP/X.25 [11] and SMTP/X.25 [12].
  299.  
  300.    The RRs could also be used automatically by an internet network-layer
  301.    router, typically IP.  The procedure would be to map IP address to
  302.    domain name, then name to canonical name if needed, then following RT
  303.    records, and finally attempting an IP/X.25 call to the address found.
  304.    Alternately, configured domain names could be resolved to identify IP
  305.    to X.25/ISDN bindings for a static but periodically refreshed routing
  306.    table.
  307.  
  308.    This provides a function similar to ARP for wide area non-broadcast
  309.    networks that will scale well to a network with hundreds of millions
  310.    of hosts.
  311.  
  312.    Also, a standard address binding reference will facilitate other
  313.    experiments in the use of X.25 and ISDN, especially in serious
  314.    inter-operability testing.  The majority of work in such a test is
  315.    establishing the n-squared entries in static tables.
  316.  
  317.    Finally, the RRs are intended for use in a proposal [13] by one of
  318.    the authors for a possible next-generation internet.
  319.  
  320. 3.1. The X25 RR
  321.  
  322.    The X25 RR is defined with mnemonic X25 and type code 19 (decimal).
  323.  
  324.    X25 has the following format:
  325.  
  326.    <owner> <ttl> <class> X25 <PSDN-address>
  327.  
  328.    <PSDN-address> is required in all X25 RRs.
  329.  
  330.    <PSDN-address> identifies the PSDN (Public Switched Data Network)
  331.    address in the X.121 [10] numbering plan associated with <owner>.
  332.    Its format in master files is a <character-string> syntactically
  333.    identical to that used in TXT and HINFO.
  334.  
  335.  
  336.  
  337.  
  338. Everhart, Mamakos, Ullmann & Mockapetris                        [Page 6]
  339.  
  340. RFC 1183                 New DNS RR Definitions             October 1990
  341.  
  342.  
  343.    The format of X25 is class insensitive.  X25 RRs cause no additional
  344.    section processing.
  345.  
  346.    The <PSDN-address> is a string of decimal digits, beginning with the
  347.    4 digit DNIC (Data Network Identification Code), as specified in
  348.    X.121. National prefixes (such as a 0) MUST NOT be used.
  349.  
  350.    For example:
  351.  
  352.    Relay.Prime.COM.  X25       311061700956
  353.  
  354. 3.2. The ISDN RR
  355.  
  356.    The ISDN RR is defined with mnemonic ISDN and type code 20 (decimal).
  357.  
  358.    An ISDN (Integrated Service Digital Network) number is simply a
  359.    telephone number.  The intent of the members of the CCITT is to
  360.    upgrade all telephone and data network service to a common service.
  361.  
  362.    The numbering plan (E.163/E.164) is the same as the familiar
  363.    international plan for POTS (an un-official acronym, meaning Plain
  364.    Old Telephone Service).  In E.166, CCITT says "An E.163/E.164
  365.    telephony subscriber may become an ISDN subscriber without a number
  366.    change."
  367.  
  368.    ISDN has the following format:
  369.  
  370.    <owner> <ttl> <class> ISDN <ISDN-address> <sa>
  371.  
  372.    The <ISDN-address> field is required; <sa> is optional.
  373.  
  374.    <ISDN-address> identifies the ISDN number of <owner> and DDI (Direct
  375.    Dial In) if any, as defined by E.164 [8] and E.163 [7], the ISDN and
  376.    PSTN (Public Switched Telephone Network) numbering plan.  E.163
  377.    defines the country codes, and E.164 the form of the addresses.  Its
  378.    format in master files is a <character-string> syntactically
  379.    identical to that used in TXT and HINFO.
  380.  
  381.    <sa> specifies the subaddress (SA).  The format of <sa> in master
  382.    files is a <character-string> syntactically identical to that used in
  383.    TXT and HINFO.
  384.  
  385.    The format of ISDN is class insensitive.  ISDN RRs cause no
  386.    additional section processing.
  387.  
  388.    The <ISDN-address> is a string of characters, normally decimal
  389.    digits, beginning with the E.163 country code and ending with the DDI
  390.    if any.  Note that ISDN, in Q.931, permits any IA5 character in the
  391.  
  392.  
  393.  
  394. Everhart, Mamakos, Ullmann & Mockapetris                        [Page 7]
  395.  
  396. RFC 1183                 New DNS RR Definitions             October 1990
  397.  
  398.  
  399.    general case.
  400.  
  401.    The <sa> is a string of hexadecimal digits.  For digits 0-9, the
  402.    concrete encoding in the Q.931 call setup information element is
  403.    identical to BCD.
  404.  
  405.    For example:
  406.  
  407.    Relay.Prime.COM.   IN   ISDN      150862028003217
  408.    sh.Prime.COM.      IN   ISDN      150862028003217 004
  409.  
  410.    (Note: "1" is the country code for the North American Integrated
  411.    Numbering Area, i.e., the system of "area codes" familiar to people
  412.    in those countries.)
  413.  
  414.    The RR data is the ASCII representation of the digits.  It is encoded
  415.    as one or two <character-string>s, i.e., count followed by
  416.    characters.
  417.  
  418.    CCITT recommendation E.166 [9] defines prefix escape codes for the
  419.    representation of ISDN (E.163/E.164) addresses in X.121, and PSDN
  420.    (X.121) addresses in E.164.  It specifies that the exact codes are a
  421.    "national matter", i.e., different on different networks.  A host
  422.    connected to the ISDN may be able to use both the X25 and ISDN
  423.    addresses, with the local prefix added.
  424.  
  425. 3.3. The Route Through RR
  426.  
  427.    The Route Through RR is defined with mnemonic RT and type code 21
  428.    (decimal).
  429.  
  430.    The RT resource record provides a route-through binding for hosts
  431.    that do not have their own direct wide area network addresses.  It is
  432.    used in much the same way as the MX RR.
  433.  
  434.    RT has the following format:
  435.  
  436.    <owner> <ttl> <class> RT <preference> <intermediate-host>
  437.  
  438.    Both RDATA fields are required in all RT RRs.
  439.  
  440.    The first field, <preference>, is a 16 bit integer, representing the
  441.    preference of the route.  Smaller numbers indicate more preferred
  442.    routes.
  443.  
  444.    <intermediate-host> is the domain name of a host which will serve as
  445.    an intermediate in reaching the host specified by <owner>.  The DNS
  446.    RRs associated with <intermediate-host> are expected to include at
  447.  
  448.  
  449.  
  450. Everhart, Mamakos, Ullmann & Mockapetris                        [Page 8]
  451.  
  452. RFC 1183                 New DNS RR Definitions             October 1990
  453.  
  454.  
  455.    least one A, X25, or ISDN record.
  456.  
  457.    The format of the RT RR is class insensitive.  RT records cause type
  458.    X25, ISDN, and A additional section processing for <intermediate-
  459.    host>.
  460.  
  461.    For example,
  462.  
  463.    sh.prime.com.      IN   RT   2    Relay.Prime.COM.
  464.                       IN   RT   10   NET.Prime.COM.
  465.    *.prime.com.       IN   RT   90   Relay.Prime.COM.
  466.  
  467.    When a host is looking up DNS records to attempt to route a datagram,
  468.    it first looks for RT records for the destination host, which point
  469.    to hosts with address records (A, X25, ISDN) compatible with the wide
  470.    area networks available to the host.  If it is itself in the set of
  471.    RT records, it discards any RTs with preferences higher or equal to
  472.    its own.  If there are no (remaining) RTs, it can then use address
  473.    records of the destination itself.
  474.  
  475.    Wild-card RTs are used exactly as are wild-card MXs.  RT's do not
  476.    "chain"; that is, it is not valid to use the RT RRs found for a host
  477.    referred to by an RT.
  478.  
  479.    The concrete encoding is identical to the MX RR.
  480.  
  481. REFERENCES and BIBLIOGRAPHY
  482.  
  483.    [1] Stahl, M., "Domain Administrators Guide", RFC 1032, Network
  484.        Information Center, SRI International, November 1987.
  485.  
  486.    [2] Lottor, M., "Domain Administrators Operations Guide", RFC 1033,
  487.        Network Information Center, SRI International, November, 1987.
  488.  
  489.    [3] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC
  490.        1034, USC/Information Sciences Institute, November 1987.
  491.  
  492.    [4] Mockapetris, P., "Domain Names - Implementation and
  493.        Specification", RFC 1035, USC/Information Sciences Institute,
  494.        November 1987.
  495.  
  496.    [5] Spector A., and M. Kazar, "Uniting File Systems", UNIX Review,
  497.        7(3), pp. 61-69, March 1989.
  498.  
  499.    [6] Zahn, et al., "Network Computing Architecture", Prentice-Hall,
  500.        1989.
  501.  
  502.    [7] International Telegraph and Telephone Consultative Committee,
  503.  
  504.  
  505.  
  506. Everhart, Mamakos, Ullmann & Mockapetris                        [Page 9]
  507.  
  508. RFC 1183                 New DNS RR Definitions             October 1990
  509.  
  510.  
  511.        "Numbering Plan for the International Telephone Service", CCITT
  512.        Recommendations E.163., IXth Plenary Assembly, Melbourne, 1988,
  513.        Fascicle II.2 ("Blue Book").
  514.  
  515.    [8] International Telegraph and Telephone Consultative Committee,
  516.        "Numbering Plan for the ISDN Era", CCITT Recommendations E.164.,
  517.        IXth Plenary Assembly, Melbourne, 1988, Fascicle II.2 ("Blue
  518.        Book").
  519.  
  520.    [9] International Telegraph and Telephone Consultative Committee.
  521.        "Numbering Plan Interworking in the ISDN Era", CCITT
  522.        Recommendations E.166., IXth Plenary Assembly, Melbourne, 1988,
  523.        Fascicle II.2 ("Blue Book").
  524.  
  525.   [10] International Telegraph and Telephone Consultative Committee,
  526.        "International Numbering Plan for the Public Data Networks",
  527.        CCITT Recommendations X.121., IXth Plenary Assembly, Melbourne,
  528.        1988, Fascicle VIII.3 ("Blue Book"); provisional, Geneva, 1978;
  529.        amended, Geneva, 1980, Malaga-Torremolinos, 1984 and Melborne,
  530.        1988.
  531.  
  532.   [11] Korb, J., "Standard for the Transmission of IP datagrams Over
  533.        Public Data Networks", RFC 877, Purdue University, September
  534.        1983.
  535.  
  536.   [12] Ullmann, R., "SMTP on X.25", RFC 1090, Prime Computer, February
  537.        1989.
  538.  
  539.   [13] Ullmann, R., "TP/IX: The Next Internet", Prime Computer
  540.        (unpublished), July 1990.
  541.  
  542.   [14] Mockapetris, P., "DNS Encoding of Network Names and Other Types",
  543.        RFC 1101, USC/Information Sciences Institute, April 1989.
  544.  
  545. Security Considerations
  546.  
  547.    Security issues are not addressed in this memo.
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Everhart, Mamakos, Ullmann & Mockapetris                       [Page 10]
  563.  
  564. RFC 1183                 New DNS RR Definitions             October 1990
  565.  
  566.  
  567. Authors' Addresses
  568.  
  569.    Craig F. Everhart
  570.    Transarc Corporation
  571.    The Gulf Tower
  572.    707 Grant Street
  573.    Pittsburgh, PA  15219
  574.  
  575.    Phone: +1 412 338 4467
  576.  
  577.    EMail: Craig_Everhart@transarc.com
  578.  
  579.  
  580.    Louis A. Mamakos
  581.    Network Infrastructure Group
  582.    Computer Science Center
  583.    University of Maryland
  584.    College Park, MD 20742-2411
  585.  
  586.    Phone: +1-301-405-7836
  587.  
  588.    Email: louie@Sayshell.UMD.EDU
  589.  
  590.  
  591.    Robert Ullmann 10-30
  592.    Prime Computer, Inc.
  593.    500 Old Connecticut Path
  594.    Framingham, MA 01701
  595.  
  596.    Phone: +1 508 620 2800 ext 1736
  597.  
  598.    Email: Ariel@Relay.Prime.COM
  599.  
  600.  
  601.    Paul Mockapetris
  602.    USC Information Sciences Institute
  603.    4676 Admiralty Way
  604.    Marina del Rey, CA 90292
  605.  
  606.    Phone: 213-822-1511
  607.  
  608.    EMail: pvm@isi.edu
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Everhart, Mamakos, Ullmann & Mockapetris                       [Page 11]
  619.