contrib/bind9/doc/rfc/rfc1183.txt

   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 \f
  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 \f
 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 \f
 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 \f
 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 \f
 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 \f
 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 \f
 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 \f
 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 \f
 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 \f
 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 \f