Return to rfc1101.lpr CVS log

Up to [CSRG BSD Unix] / 43BSDReno / usr.sbin / named / doc

Annotation of 43BSDReno/usr.sbin/named/doc/rfc1101.lpr, revision 1.1

1.1     ! root        1: 
        !             2: 
        !             3: 
        !             4: 
        !             5: 
        !             6: 
        !             7: Network Working Group                                     P. Mockapetris
        !             8: Request for Comments: 1101                                           ISI
        !             9: Updates: RFCs 1034, 1035                                      April 1989
        !            10: 
        !            11: 
        !            12:              DNS Encoding of Network Names and Other Types
        !            13: 
        !            14: 
        !            15: 1. STATUS OF THIS MEMO
        !            16: 
        !            17:    This RFC proposes two extensions to the Domain Name System:
        !            18: 
        !            19:       - A specific method for entering and retrieving RRs which map
        !            20:         between network names and numbers.
        !            21: 
        !            22:       - Ideas for a general method for describing mappings between
        !            23:         arbitrary identifiers and numbers.
        !            24: 
        !            25:    The method for mapping between network names and addresses is a
        !            26:    proposed standard, the ideas for a general method are experimental.
        !            27: 
        !            28:    This RFC assumes that the reader is familiar with the DNS [RFC 1034,
        !            29:    RFC 1035] and its use.  The data shown is for pedagogical use and
        !            30:    does not necessarily reflect the real Internet.
        !            31: 
        !            32:    Distribution of this memo is unlimited.
        !            33: 
        !            34: 2. INTRODUCTION
        !            35: 
        !            36:    The DNS is extensible and can be used for a virtually unlimited
        !            37:    number of data types, name spaces, etc.  New type definitions are
        !            38:    occasionally necessary as are revisions or deletions of old types
        !            39:    (e.g., MX replacement of MD and MF [RFC 974]), and changes described
        !            40:    in [RFC 973].  This RFC describes changes due to the general need to
        !            41:    map between identifiers and values, and a specific need for network
        !            42:    name support.
        !            43: 
        !            44:    Users wish to be able to use the DNS to map between network names and
        !            45:    numbers.  This need is the only capability found in HOSTS.TXT which
        !            46:    is not available from the DNS.  In designing a method to do this,
        !            47:    there were two major areas of concern:
        !            48: 
        !            49:       - Several tradeoffs involving control of network names, the
        !            50:         syntax of network names, backward compatibility, etc.
        !            51: 
        !            52:       - A desire to create a method which would be sufficiently
        !            53:         general to set a good precedent for future mappings,
        !            54:         for example, between TCP-port names and numbers,
        !            55: 
        !            56: 
        !            57: 
        !            58: Mockapetris                                                     [Page 1]
        !            59: 
        !            60: RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
        !            61: 
        !            62: 
        !            63:         autonomous system names and numbers, X.500 Relative
        !            64:         Distinguished Names (RDNs) and their servers, or whatever.
        !            65: 
        !            66:    It was impossible to reconcile these two areas of concern for network
        !            67:    names because of the desire to unify network number support within
        !            68:    existing IP address to host name support.  The existing support is
        !            69:    the IN-ADDR.ARPA section of the DNS name space.  As a result this RFC
        !            70:    describes one structure for network names which builds on the
        !            71:    existing support for host names, and another family of structures for
        !            72:    future yellow pages (YP) functions such as conversions between TCP-
        !            73:    port numbers and mnemonics.
        !            74: 
        !            75:    Both structures are described in following sections.  Each structure
        !            76:    has a discussion of design issues and specific structure
        !            77:    recommendations.
        !            78: 
        !            79:    We wish to avoid defining structures and methods which can work but
        !            80:    do not because of indifference or errors on the part of system
        !            81:    administrators when maintaining the database.  The WKS RR is an
        !            82:    example.  Thus, while we favor distribution as a general method, we
        !            83:    also recognize that centrally maintained tables (such as HOSTS.TXT)
        !            84:    are usually more consistent though less maintainable and timely.
        !            85:    Hence we recommend both specific methods for mapping network names,
        !            86:    addresses, and subnets, as well as an instance of the general method
        !            87:    for mapping between allocated network numbers and network names.
        !            88:    (Allocation is centrally performed by the SRI Network Information
        !            89:    Center, aka the NIC).
        !            90: 
        !            91: 3. NETWORK NAME ISSUES AND DISCUSSION
        !            92: 
        !            93:    The issues involved in the design were the definition of network name
        !            94:    syntax, the mappings to be provided, and possible support for similar
        !            95:    functions at the subnet level.
        !            96: 
        !            97: 3.1. Network name syntax
        !            98: 
        !            99:    The current syntax for network names, as defined by [RFC 952] is an
        !           100:    alphanumeric string of up to 24 characters, which begins with an
        !           101:    alpha, and may include "." and "-" except as first and last
        !           102:    characters.  This is the format which was also used for host names
        !           103:    before the DNS.  Upward compatibility with existing names might be a
        !           104:    goal of any new scheme.
        !           105: 
        !           106:    However, the present syntax has been used to define a flat name
        !           107:    space, and hence would prohibit the same distributed name allocation
        !           108:    method used for host names.  There is some sentiment for allowing the
        !           109:    NIC to continue to allocate and regulate network names, much as it
        !           110:    allocates numbers, but the majority opinion favors local control of
        !           111: 
        !           112: 
        !           113: 
        !           114: Mockapetris                                                     [Page 2]
        !           115: 
        !           116: RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
        !           117: 
        !           118: 
        !           119:    network names.  Although it would be possible to provide a flat space
        !           120:    or a name space in which, for example, the last label of a domain
        !           121:    name captured the old-style network name, any such approach would add
        !           122:    complexity to the method and create different rules for network names
        !           123:    and host names.
        !           124: 
        !           125:    For these reasons, we assume that the syntax of network names will be
        !           126:    the same as the expanded syntax for host names permitted in [HR].
        !           127:    The new syntax expands the set of names to allow leading digits, so
        !           128:    long as the resulting representations do not conflict with IP
        !           129:    addresses in decimal octet form.  For example, 3Com.COM and 3M.COM
        !           130:    are now legal, although 26.0.0.73.COM is not.  See [HR] for details.
        !           131: 
        !           132:    The price is that network names will get as complicated as host
        !           133:    names.  An administrator will be able to create network names in any
        !           134:    domain under his control, and also create network number to name
        !           135:    entries in IN-ADDR.ARPA domains under his control.  Thus, the name
        !           136:    for the ARPANET might become NET.ARPA, ARPANET.ARPA or Arpa-
        !           137:    network.MIL., depending on the preferences of the owner.
        !           138: 
        !           139: 3.2. Mappings
        !           140: 
        !           141:    The desired mappings, ranked by priority with most important first,
        !           142:    are:
        !           143: 
        !           144:       - Mapping a IP address or network number to a network name.
        !           145: 
        !           146:         This mapping is for use in debugging tools and status displays
        !           147:         of various sorts.  The conversion from IP address to network
        !           148:         number is well known for class A, B, and C IP addresses, and
        !           149:         involves a simple mask operation.  The needs of other classes
        !           150:         are not yet defined and are ignored for the rest of this RFC.
        !           151: 
        !           152:       - Mapping a network name to a network address.
        !           153: 
        !           154:         This facility is of less obvious application, but a
        !           155:         symmetrical mapping seems desirable.
        !           156: 
        !           157:       - Mapping an organization to its network names and numbers.
        !           158: 
        !           159:         This facility is useful because it may not always be possible
        !           160:         to guess the local choice for network names, but the
        !           161:         organization name is often well known.
        !           162: 
        !           163:       - Similar mappings for subnets, even when nested.
        !           164: 
        !           165:         The primary application is to be able to identify all of the
        !           166:         subnets involved in a particular IP address.  A secondary
        !           167: 
        !           168: 
        !           169: 
        !           170: Mockapetris                                                     [Page 3]
        !           171: 
        !           172: RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
        !           173: 
        !           174: 
        !           175:         requirement is to retrieve address mask information.
        !           176: 
        !           177: 3.3. Network address section of the name space
        !           178: 
        !           179:    The network name syntax discussed above can provide domain names
        !           180:    which will contain mappings from network names to various quantities,
        !           181:    but we also need a section of the name space, organized by network
        !           182:    and subnet number to hold the inverse mappings.
        !           183: 
        !           184:    The choices include:
        !           185: 
        !           186:       - The same network number slots already assigned and delegated
        !           187:         in the IN-ADDR.ARPA section of the name space.
        !           188: 
        !           189:         For example, 10.IN-ADDR.ARPA for class A net 10,
        !           190:         2.128.IN-ADDR.ARPA for class B net 128.2, etc.
        !           191: 
        !           192:       - Host-zero addresses in the IN-ADDR.ARPA tree.  (A host field
        !           193:         of all zero in an IP address is prohibited because of
        !           194:         confusion related to broadcast addresses, et al.)
        !           195: 
        !           196:         For example, 0.0.0.10.IN-ADDR.ARPA for class A net 10,
        !           197:         0.0.2.128.IN-ADDR.arpa for class B net 128.2, etc.  Like the
        !           198:         first scheme, it uses in-place name space delegations to
        !           199:         distribute control.
        !           200: 
        !           201:         The main advantage of this scheme over the first is that it
        !           202:         allows convenient names for subnets as well as networks.  A
        !           203:         secondary advantage is that it uses names which are not in use
        !           204:         already, and hence it is possible to test whether an
        !           205:         organization has entered this information in its domain
        !           206:         database.
        !           207: 
        !           208:       - Some new section of the name space.
        !           209: 
        !           210:         While this option provides the most opportunities, it creates
        !           211:         a need to delegate a whole new name space.  Since the IP
        !           212:         address space is so closely related to the network number
        !           213:         space, most believe that the overhead of creating such a new
        !           214:         space is overwhelming and would lead to the WKS syndrome.  (As
        !           215:         of February, 1989, approximately 400 sections of the
        !           216:         IN-ADDR.ARPA tree are already delegated, usually at network
        !           217:         boundaries.)
        !           218: 
        !           219: 
        !           220: 
        !           221: 
        !           222: 
        !           223: 
        !           224: 
        !           225: 
        !           226: Mockapetris                                                     [Page 4]
        !           227: 
        !           228: RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
        !           229: 
        !           230: 
        !           231: 4. SPECIFICS FOR NETWORK NAME MAPPINGS
        !           232: 
        !           233:    The proposed solution uses information stored at:
        !           234: 
        !           235:       - Names in the IN-ADDR.ARPA tree that correspond to host-zero IP
        !           236:         addresses.  The same method is used for subnets in a nested
        !           237:         fashion.  For example, 0.0.0.10.IN-ADDR.ARPA. for net 10.
        !           238: 
        !           239:         Two types of information are stored here: PTR RRs which point
        !           240:         to the network name in their data sections, and A RRs, which
        !           241:         are present if the network (or subnet) is subnetted further.
        !           242:         If a type A RR is present, then it has the address mask as its
        !           243:         data.  The general form is:
        !           244: 
        !           245:         <reversed-host-zero-number>.IN-ADDR.ARPA. PTR <network-name>
        !           246:         <reversed-host-zero-number>.IN-ADDR.ARPA. A   <subnet-mask>
        !           247: 
        !           248:         For example:
        !           249: 
        !           250:         0.0.0.10.IN-ADDR.ARPA.  PTR     ARPANET.ARPA.
        !           251: 
        !           252:         or
        !           253: 
        !           254:         0.0.2.128.IN-ADDR.ARPA. PTR     cmu-net.cmu.edu.
        !           255:                                 A       255.255.255.0
        !           256: 
        !           257:         In general, this information will be added to an existing
        !           258:         master file for some IN-ADDR.ARPA domain for each network
        !           259:         involved.  Similar RRs can be used at host-zero subnet
        !           260:         entries.
        !           261: 
        !           262:       - Names which are network names.
        !           263: 
        !           264:         The data stored here is PTR RRs pointing at the host-zero
        !           265:         entries.  The general form is:
        !           266: 
        !           267:         <network-name> ptr <reversed-host-zero-number>.IN-ADDR.ARPA
        !           268: 
        !           269:         For example:
        !           270: 
        !           271:         ARPANET.ARPA.           PTR     0.0.0.10.IN-ADDR.ARPA.
        !           272: 
        !           273:         or
        !           274: 
        !           275:         isi-net.isi.edu.        PTR     0.0.9.128.IN-ADDR.ARPA.
        !           276: 
        !           277:         In general, this information will be inserted in the master
        !           278:         file for the domain name of the organization; this is a
        !           279: 
        !           280: 
        !           281: 
        !           282: Mockapetris                                                     [Page 5]
        !           283: 
        !           284: RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
        !           285: 
        !           286: 
        !           287:         different file from that which holds the information below
        !           288:         IN-ADDR.ARPA.  Similar PTR RRs can be used at subnet names.
        !           289: 
        !           290:       - Names corresponding to organizations.
        !           291: 
        !           292:         The data here is one or more PTR RRs pointing at the
        !           293:         IN-ADDR.ARPA names corresponding to host-zero entries for
        !           294:         networks.
        !           295: 
        !           296:         For example:
        !           297: 
        !           298:         ISI.EDU.        PTR     0.0.9.128.IN-ADDR.ARPA.
        !           299: 
        !           300:         MCC.COM.        PTR     0.167.5.192.IN-ADDR.ARPA.
        !           301:                         PTR     0.168.5.192.IN-ADDR.ARPA.
        !           302:                         PTR     0.169.5.192.IN-ADDR.ARPA.
        !           303:                         PTR     0.0.62.128.IN-ADDR.ARPA.
        !           304: 
        !           305: 4.1. A simple example
        !           306: 
        !           307:    The ARPANET is a Class A network without subnets.  The RRs which
        !           308:    would be added, assuming the ARPANET.ARPA was selected as a network
        !           309:    name, would be:
        !           310: 
        !           311:    ARPA.                   PTR     0.0.0.10.IN-ADDR.ARPA.
        !           312: 
        !           313:    ARPANET.ARPA.           PTR     0.0.0.10.IN-ADDR.ARPA.
        !           314: 
        !           315:    0.0.0.10.IN-ADDR.ARPA.  PTR     ARPANET.ARPA.
        !           316: 
        !           317:    The first RR states that the organization named ARPA owns net 10 (It
        !           318:    might also own more network numbers, and these would be represented
        !           319:    with an additional RR per net.)  The second states that the network
        !           320:    name ARPANET.ARPA. maps to net 10.  The last states that net 10 is
        !           321:    named ARPANET.ARPA.
        !           322: 
        !           323:    Note that all of the usual host and corresponding IN-ADDR.ARPA
        !           324:    entries would still be required.
        !           325: 
        !           326: 4.2. A complicated, subnetted example
        !           327: 
        !           328:    The ISI network is 128.9, a class B number.  Suppose the ISI network
        !           329:    was organized into two levels of subnet, with the first level using
        !           330:    an additional 8 bits of address, and the second level using 4 bits,
        !           331:    for address masks of x'FFFFFF00' and X'FFFFFFF0'.
        !           332: 
        !           333:    Then the following RRs would be entered in ISI's master file for the
        !           334:    ISI.EDU zone:
        !           335: 
        !           336: 
        !           337: 
        !           338: Mockapetris                                                     [Page 6]
        !           339: 
        !           340: RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
        !           341: 
        !           342: 
        !           343:    ; Define network entry
        !           344:    isi-net.isi.edu.                PTR  0.0.9.128.IN-ADDR.ARPA.
        !           345: 
        !           346:    ; Define first level subnets
        !           347:    div1-subnet.isi.edu.            PTR  0.1.9.128.IN-ADDR.ARPA.
        !           348:    div2-subnet.isi.edu.            PTR  0.2.9.128.IN-ADDR.ARPA.
        !           349: 
        !           350:    ; Define second level subnets
        !           351:    inc-subsubnet.isi.edu.          PTR  16.2.9.128.IN-ADDR.ARPA.
        !           352: 
        !           353:    in the 9.128.IN-ADDR.ARPA zone:
        !           354: 
        !           355:    ; Define network number and address mask
        !           356:    0.0.9.128.IN-ADDR.ARPA.         PTR  isi-net.isi.edu.
        !           357:                                    A    255.255.255.0  ;aka X'FFFFFF00'
        !           358: 
        !           359:    ; Define one of the first level subnet numbers and masks
        !           360:    0.1.9.128.IN-ADDR.ARPA.         PTR  div1-subnet.isi.edu.
        !           361:                                    A    255.255.255.240 ;aka X'FFFFFFF0'
        !           362: 
        !           363:    ; Define another first level subnet number and mask
        !           364:    0.2.9.128.IN-ADDR.ARPA.         PTR  div2-subnet.isi.edu.
        !           365:                                    A    255.255.255.240 ;aka X'FFFFFFF0'
        !           366: 
        !           367:    ; Define second level subnet number
        !           368:    16.2.9.128.IN-ADDR.ARPA.        PTR  inc-subsubnet.isi.edu.
        !           369: 
        !           370:    This assumes that the ISI network is named isi-net.isi.edu., first
        !           371:    level subnets are named div1-subnet.isi.edu. and div2-
        !           372:    subnet.isi.edu., and a second level subnet is called inc-
        !           373:    subsubnet.isi.edu.  (In a real system as complicated as this there
        !           374:    would be more first and second level subnets defined, but we have
        !           375:    shown enough to illustrate the ideas.)
        !           376: 
        !           377: 4.3. Procedure for using an IP address to get network name
        !           378: 
        !           379:    Depending on whether the IP address is class A, B, or C, mask off the
        !           380:    high one, two, or three bytes, respectively.  Reverse the octets,
        !           381:    suffix IN-ADDR.ARPA, and do a PTR query.
        !           382: 
        !           383:    For example, suppose the IP address is 10.0.0.51.
        !           384: 
        !           385:       1. Since this is a class A address, use a mask x'FF000000' and
        !           386:          get 10.0.0.0.
        !           387: 
        !           388:       2. Construct the name 0.0.0.10.IN-ADDR.ARPA.
        !           389: 
        !           390:       3. Do a PTR query.  Get back
        !           391: 
        !           392: 
        !           393: 
        !           394: Mockapetris                                                     [Page 7]
        !           395: 
        !           396: RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
        !           397: 
        !           398: 
        !           399:          0.0.0.10.IN-ADDR.ARPA.  PTR     ARPANET.ARPA.
        !           400: 
        !           401:       4. Conclude that the network name is "ARPANET.ARPA."
        !           402: 
        !           403:    Suppose that the IP address is 128.9.2.17.
        !           404: 
        !           405:       1. Since this is a class B address, use a mask of x'FFFF0000'
        !           406:          and get 128.9.0.0.
        !           407: 
        !           408:       2. Construct the name 0.0.9.128.IN-ADDR.ARPA.
        !           409: 
        !           410:       3. Do a PTR query.  Get back
        !           411: 
        !           412:          0.0.9.128.IN-ADDR.ARPA.       PTR     isi-net.isi.edu
        !           413: 
        !           414:       4. Conclude that the network name is "isi-net.isi.edu."
        !           415: 
        !           416: 4.4. Procedure for finding all subnets involved with an IP address
        !           417: 
        !           418:    This is a simple extension of the IP address to network name method.
        !           419:    When the network entry is located, do a lookup for a possible A RR.
        !           420:    If the A RR is found, look up the next level of subnet using the
        !           421:    original IP address and the mask in the A RR.  Repeat this procedure
        !           422:    until no A RR is found.
        !           423: 
        !           424:    For example, repeating the use of 128.9.2.17.
        !           425: 
        !           426:       1. As before construct a query for 0.0.9.128.IN-ADDR.ARPA.
        !           427:          Retrieve:
        !           428: 
        !           429:          0.0.9.128.IN-ADDR.ARPA.  PTR    isi-net.isi.edu.
        !           430:                                   A      255.255.255.0
        !           431: 
        !           432:       2. Since an A RR was found, repeat using mask from RR
        !           433:          (255.255.255.0), constructing a query for
        !           434:          0.2.9.128.IN-ADDR.ARPA.  Retrieve:
        !           435: 
        !           436:          0.2.9.128.IN-ADDR.ARPA.  PTR    div2-subnet.isi.edu.
        !           437:                                   A      255.255.255.240
        !           438: 
        !           439:       3. Since another A RR was found, repeat using mask
        !           440:          255.255.255.240 (x'FFFFFFF0').  constructing a query for
        !           441:          16.2.9.128.IN-ADDR.ARPA.  Retrieve:
        !           442: 
        !           443:          16.2.9.128.IN-ADDR.ARPA. PTR    inc-subsubnet.isi.edu.
        !           444: 
        !           445:       4. Since no A RR is present at 16.2.9.128.IN-ADDR.ARPA., there
        !           446:          are no more subnet levels.
        !           447: 
        !           448: 
        !           449: 
        !           450: Mockapetris                                                     [Page 8]
        !           451: 
        !           452: RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
        !           453: 
        !           454: 
        !           455: 5. YP ISSUES AND DISCUSSION
        !           456: 
        !           457:    The term "Yellow Pages" is used in almost as many ways as the term
        !           458:    "domain", so it is useful to define what is meant herein by YP.  The
        !           459:    general problem to be solved is to create a method for creating
        !           460:    mappings from one kind of identifier to another, often with an
        !           461:    inverse capability.  The traditional methods are to search or use a
        !           462:    precomputed index of some kind.
        !           463: 
        !           464:    Searching is impractical when the search is too large, and
        !           465:    precomputed indexes are possible only when it is possible to specify
        !           466:    search criteria in advance, and pay for the resources necessary to
        !           467:    build the index.  For example, it is impractical to search the entire
        !           468:    domain tree to find a particular address RR, so we build the IN-
        !           469:    ADDR.ARPA YP.  Similarly, we could never build an Internet-wide index
        !           470:    of "hosts with a load average of less than 2" in less time than it
        !           471:    would take for the data to change, so indexes are a useless approach
        !           472:    for that problem.
        !           473: 
        !           474:    Such a precomputed index is what we mean by YP, and we regard the
        !           475:    IN-ADDR.ARPA domain as the first instance of a YP in the DNS.
        !           476:    Although a single, centrally-managed YP for well-known values such as
        !           477:    TCP-port is desirable, we regard organization-specific YPs for, say,
        !           478:    locally defined TCP ports as a natural extension, as are combinations
        !           479:    of YPs using search lists to merge the two.
        !           480: 
        !           481:    In examining Internet Numbers [RFC 997] and Assigned Numbers [RFC
        !           482:    1010], it is clear that there are several mappings which might be of
        !           483:    value.  For example:
        !           484: 
        !           485:    <assigned-network-name> <==> <IP-address>
        !           486:    <autonomous-system-id>  <==> <number>
        !           487:    <protocol-id>           <==> <number>
        !           488:    <port-id>               <==> <number>
        !           489:    <ethernet-type>         <==> <number>
        !           490:    <public-data-net>       <==> <IP-address>
        !           491: 
        !           492:    Following the IN-ADDR example, the YP takes the form of a domain tree
        !           493:    organized to optimize retrieval by search key and distribution via
        !           494:    normal DNS rules.  The name used as a key must include:
        !           495: 
        !           496:       1. A well known origin.  For example, IN-ADDR.ARPA is the
        !           497:          current IP-address to host name YP.
        !           498: 
        !           499:       2. A "from" data type.  This identifies the input type of the
        !           500:          mapping.  This is necessary because we may be mapping
        !           501:          something as anonymous as a number to any number of
        !           502:          mnemonics, etc.
        !           503: 
        !           504: 
        !           505: 
        !           506: Mockapetris                                                     [Page 9]
        !           507: 
        !           508: RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
        !           509: 
        !           510: 
        !           511:       3. A "to" data type.  Since we assume several symmetrical
        !           512:          mnemonic <==> number mappings, this is also necessary.
        !           513: 
        !           514:    This ordering reflects the natural scoping of control, and hence the
        !           515:    order of the components in a domain name.  Thus domain names would be
        !           516:    of the form:
        !           517: 
        !           518:    <from-value>.<to-data-type>.<from-data-type>.<YP-origin>
        !           519: 
        !           520:    To make this work, we need to define well-know strings for each of
        !           521:    these metavariables, as well as encoding rules for converting a
        !           522:    <from-value> into a domain name.  We might define:
        !           523: 
        !           524:    <YP-origin>     :=YP
        !           525:    <from-data-type>:=TCP-port | IN-ADDR | Number |
        !           526:                      Assigned-network-number | Name
        !           527:    <to-data-type>  :=<from-data-type>
        !           528: 
        !           529:    Note that "YP" is NOT a valid country code under [ISO 3166] (although
        !           530:    we may want to worry about the future), and the existence of a
        !           531:    syntactically valid <to-data-type>.<from-data-type> pair does not
        !           532:    imply that a meaningful mapping exists, or is even possible.
        !           533: 
        !           534:    The encoding rules might be:
        !           535: 
        !           536:    TCP-port        Six character alphanumeric
        !           537: 
        !           538:    IN-ADDR         Reversed 4-octet decimal string
        !           539: 
        !           540:    Number          decimal integer
        !           541: 
        !           542:    Assigned-network-number
        !           543:                    Reversed 4-octet decimal string
        !           544: 
        !           545:    Name            Domain name
        !           546: 
        !           547: 6. SPECIFICS FOR YP MAPPINGS
        !           548: 
        !           549: 6.1. TCP-PORT
        !           550: 
        !           551:    $origin Number.TCP-port.YP.
        !           552: 
        !           553:    23              PTR     TELNET.TCP-port.Number.YP.
        !           554:    25              PTR     SMTP.TCP-port.Number.YP.
        !           555: 
        !           556:    $origin TCP-port.Number.YP.
        !           557: 
        !           558:    TELNET          PTR     23.Number.TCP-port.YP.
        !           559: 
        !           560: 
        !           561: 
        !           562: Mockapetris                                                    [Page 10]
        !           563: 
        !           564: RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
        !           565: 
        !           566: 
        !           567:    SMTP            PTR     25.Number.TCP-port.YP.
        !           568: 
        !           569:    Thus the mapping between 23 and TELNET is represented by a pair of
        !           570:    PTR RRs, one for each direction of the mapping.
        !           571: 
        !           572: 6.2. Assigned networks
        !           573: 
        !           574:    Network numbers are assigned by the NIC and reported in "Internet
        !           575:    Numbers" RFCs.  To create a YP, the NIC would set up two domains:
        !           576: 
        !           577:    Name.Assigned-network-number.YP and Assigned-network-number.YP
        !           578: 
        !           579:    The first would contain entries of the form:
        !           580: 
        !           581:    $origin Name.Assigned-network-number.YP.
        !           582: 
        !           583:    0.0.0.4         PTR     SATNET.Assigned-network-number.Name.YP.
        !           584:    0.0.0.10        PTR     ARPANET.Assigned-network-number.Name.YP.
        !           585: 
        !           586:    The second would contain entries of the form:
        !           587: 
        !           588:    $origin Assigned-network-number.Name.YP.
        !           589: 
        !           590:    SATNET.         PTR     0.0.0.4.Name.Assigned-network-number.YP.
        !           591:    ARPANET.        PTR     0.0.0.10.Name.Assigned-network-number.YP.
        !           592: 
        !           593:    These YPs are not in conflict with the network name support described
        !           594:    in the first half of this RFC since they map between ASSIGNED network
        !           595:    names and numbers, not those allocated by the organizations
        !           596:    themselves.  That is, they document the NIC's decisions about
        !           597:    allocating network numbers but do not automatically track any
        !           598:    renaming performed by the new owners.
        !           599: 
        !           600:    As a practical matter, we might want to create both of these domains
        !           601:    to enable users on the Internet to experiment with centrally
        !           602:    maintained support as well as the distributed version, or might want
        !           603:    to implement only the allocated number to name mapping and request
        !           604:    organizations to convert their allocated network names to the network
        !           605:    names described in the distributed model.
        !           606: 
        !           607: 6.3. Operational improvements
        !           608: 
        !           609:    We could imagine that all conversion routines using these YPs might
        !           610:    be instructed to use "YP.<local-domain>" followed by "YP."  as a
        !           611:    search list.  Thus, if the organization ISI.EDU wished to define
        !           612:    locally meaningful TCP-PORT, it would define the domains:
        !           613: 
        !           614:    <TCP-port.Number.YP.ISI.EDU> and <Number.TCP-port.YP.ISI.EDU>.
        !           615: 
        !           616: 
        !           617: 
        !           618: Mockapetris                                                    [Page 11]
        !           619: 
        !           620: RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
        !           621: 
        !           622: 
        !           623:    We could add another level of indirection in the YP lookup, defining
        !           624:    the <to-data-type>.<from-data-type>.<YP-origin> nodes to point to the
        !           625:    YP tree, rather than being the YP tree directly.  This would enable
        !           626:    entries of the form:
        !           627: 
        !           628:    IN-ADDR.Netname.YP.   PTR     IN-ADDR.ARPA.
        !           629: 
        !           630:    to splice in YPs from other origins or existing spaces.
        !           631: 
        !           632:    Another possibility would be to shorten the RDATA section of the RRs
        !           633:    which map back and forth by deleting the origin.  This could be done
        !           634:    either by allowing the domain name in the RDATA portion to not
        !           635:    identify a real domain name, or by defining a new RR which used a
        !           636:    simple text string rather than a domain name.
        !           637: 
        !           638:    Thus, we might replace
        !           639: 
        !           640:    $origin Assigned-network-number.Name.YP.
        !           641: 
        !           642:    SATNET.         PTR     0.0.0.4.Name.Assigned-network-number.YP.
        !           643:    ARPANET.        PTR     0.0.0.10.Name.Assigned-network-number.YP.
        !           644: 
        !           645:    with
        !           646: 
        !           647:    $origin Assigned-network-number.Name.YP.
        !           648: 
        !           649:    SATNET.         PTR     0.0.0.4.
        !           650:    ARPANET.        PTR     0.0.0.10.
        !           651: 
        !           652:    or
        !           653: 
        !           654:    $origin Assigned-network-number.Name.YP.
        !           655: 
        !           656:    SATNET.         PTT     "0.0.0.4"
        !           657:    ARPANET.        PTT     "0.0.0.10"
        !           658: 
        !           659:    where PTT is a new type whose RDATA section is a text string.
        !           660: 
        !           661: 7. ACKNOWLEDGMENTS
        !           662: 
        !           663:    Drew Perkins, Mark Lottor, and Rob Austein contributed several of the
        !           664:    ideas in this RFC.  Numerous contributions, criticisms, and
        !           665:    compromises were produced in the IETF Domain working group and the
        !           666:    NAMEDROPPERS mailing list.
        !           667: 
        !           668: 
        !           669: 
        !           670: 
        !           671: 
        !           672: 
        !           673: 
        !           674: Mockapetris                                                    [Page 12]
        !           675: 
        !           676: RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
        !           677: 
        !           678: 
        !           679: 8. REFERENCES
        !           680: 
        !           681:    [HR]        Braden, B., editor, "Requirements for Internet Hosts",
        !           682:                RFC in preparation.
        !           683: 
        !           684:    [ISO 3166]  ISO, "Codes for the Representation of Names of
        !           685:                Countries", 1981.
        !           686: 
        !           687:    [RFC 882]   Mockapetris, P., "Domain names - Concepts and
        !           688:                Facilities", RFC 882, USC/Information Sciences Institute,
        !           689:                November 1983.
        !           690: 
        !           691:                Superseded by RFC 1034.
        !           692: 
        !           693:    [RFC 883]   Mockapetris, P.,"Domain names - Implementation and
        !           694:                Specification", RFC 883, USC/Information Sciences
        !           695:                Institute, November 1983.
        !           696: 
        !           697:                Superceeded by RFC 1035.
        !           698: 
        !           699:    [RFC 920]   Postel, J. and J. Reynolds, "Domain Requirements", RFC
        !           700:                920, October 1984.
        !           701: 
        !           702:                Explains the naming scheme for top level domains.
        !           703: 
        !           704:    [RFC 952]   Harrenstien, K., M. Stahl, and E. Feinler, "DoD Internet
        !           705:                Host Table Specification", RFC 952, SRI, October 1985.
        !           706: 
        !           707:                Specifies the format of HOSTS.TXT, the host/address table
        !           708:                replaced by the DNS
        !           709: 
        !           710:    [RFC 973]   Mockapetris, P., "Domain System Changes and
        !           711:                Observations", RFC 973, USC/Information Sciences
        !           712:                Institute, January 1986.
        !           713: 
        !           714:                Describes changes to RFCs 882 and 883 and reasons for
        !           715:                them.
        !           716: 
        !           717:    [RFC 974]   Partridge, C., "Mail routing and the domain system", RFC
        !           718:                974, CSNET CIC BBN Labs, January 1986.
        !           719: 
        !           720:                Describes the transition from HOSTS.TXT based mail
        !           721:                addressing to the more powerful MX system used with the
        !           722:                domain system.
        !           723: 
        !           724: 
        !           725: 
        !           726: 
        !           727: 
        !           728: 
        !           729: 
        !           730: Mockapetris                                                    [Page 13]
        !           731: 
        !           732: RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
        !           733: 
        !           734: 
        !           735:    [RFC 997]   Reynolds, J., and J. Postel, "Internet Numbers", RFC 997,
        !           736:                USC/Information Sciences Institute, March 1987
        !           737: 
        !           738:                Contains network numbers, autonomous system numbers, etc.
        !           739: 
        !           740:    [RFC 1010]  Reynolds, J., and J. Postel, "Assigned Numbers", RFC
        !           741:                1010, USC/Information Sciences Institute, May 1987
        !           742: 
        !           743:                Contains socket numbers and mnemonics for host names,
        !           744:                operating systems, etc.
        !           745: 
        !           746: 
        !           747:    [RFC 1034]  Mockapetris, P., "Domain names - Concepts and
        !           748:                Facilities", RFC 1034, USC/Information Sciences
        !           749:                Institute, November 1987.
        !           750: 
        !           751:                Introduction/overview of the DNS.
        !           752: 
        !           753:    [RFC 1035]  Mockapetris, P., "Domain names - Implementation and
        !           754:                Specification", RFC 1035, USC/Information Sciences
        !           755:                Institute, November 1987.
        !           756: 
        !           757:                DNS implementation instructions.
        !           758: 
        !           759: Author's Address:
        !           760: 
        !           761:    Paul Mockapetris
        !           762:    USC/Information Sciences Institute
        !           763:    4676 Admiralty Way
        !           764:    Marina del Rey, CA 90292
        !           765: 
        !           766:    Phone: (213) 822-1511
        !           767: 
        !           768:    Email: [email protected]
        !           769: 
        !           770: 
        !           771: 
        !           772: 
        !           773: 
        !           774: 
        !           775: 
        !           776: 
        !           777: 
        !           778: 
        !           779: 
        !           780: 
        !           781: 
        !           782: 
        !           783: 
        !           784: 
        !           785: 
        !           786: Mockapetris                                                    [Page 14]
        !           787: 

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.