RFC1101

Network Working Group P. Mockapetris Request for Comments: 1101 ISI Updates: RFCs 1034, 1035 April 1989

            DNS Encoding of Network Names and Other Types

1. STATUS OF THIS MEMO

  This RFC proposes two extensions to the Domain Name System:

     - A specific method for entering and retrieving RRs which map
       between network names and numbers.

     - Ideas for a general method for describing mappings between
       arbitrary identifiers and numbers.

  The method for mapping between network names and addresses is a
  proposed standard, the ideas for a general method are experimental.

  This RFC assumes that the reader is familiar with the DNS [RFC 1034,
  RFC 1035] and its use.  The data shown is for pedagogical use and
  does not necessarily reflect the real Internet.

  Distribution of this memo is unlimited.

2. INTRODUCTION

  The DNS is extensible and can be used for a virtually unlimited
  number of data types, name spaces, etc.  New type definitions are
  occasionally necessary as are revisions or deletions of old types
  (e.g., MX replacement of MD and MF [RFC 974]), and changes described
  in [RFC 973].  This RFC describes changes due to the general need to
  map between identifiers and values, and a specific need for network
  name support.

  Users wish to be able to use the DNS to map between network names and
  numbers.  This need is the only capability found in HOSTS.TXT which
  is not available from the DNS.  In designing a method to do this,
  there were two major areas of concern:

     - Several tradeoffs involving control of network names, the
       syntax of network names, backward compatibility, etc.

     - A desire to create a method which would be sufficiently
       general to set a good precedent for future mappings,
       for example, between TCP-port names and numbers,

Mockapetris [Page 1]

RFC 1101 DNS Encoding of Network Names and Other Types April 1989

       autonomous system names and numbers, X.500 Relative
       Distinguished Names (RDNs) and their servers, or whatever.

  It was impossible to reconcile these two areas of concern for network
  names because of the desire to unify network number support within
  existing IP address to host name support.  The existing support is
  the IN-ADDR.ARPA section of the DNS name space.  As a result this RFC
  describes one structure for network names which builds on the
  existing support for host names, and another family of structures for
  future yellow pages (YP) functions such as conversions between TCP-
  port numbers and mnemonics.

  Both structures are described in following sections.  Each structure
  has a discussion of design issues and specific structure
  recommendations.

  We wish to avoid defining structures and methods which can work but
  do not because of indifference or errors on the part of system
  administrators when maintaining the database.  The WKS RR is an
  example.  Thus, while we favor distribution as a general method, we
  also recognize that centrally maintained tables (such as HOSTS.TXT)
  are usually more consistent though less maintainable and timely.
  Hence we recommend both specific methods for mapping network names,
  addresses, and subnets, as well as an instance of the general method
  for mapping between allocated network numbers and network names.
  (Allocation is centrally performed by the SRI Network Information
  Center, aka the NIC).

3. NETWORK NAME ISSUES AND DISCUSSION

  The issues involved in the design were the definition of network name
  syntax, the mappings to be provided, and possible support for similar
  functions at the subnet level.

3.1. Network name syntax

  The current syntax for network names, as defined by [RFC 952] is an
  alphanumeric string of up to 24 characters, which begins with an
  alpha, and may include "." and "-" except as first and last
  characters.  This is the format which was also used for host names
  before the DNS.  Upward compatibility with existing names might be a
  goal of any new scheme.

  However, the present syntax has been used to define a flat name
  space, and hence would prohibit the same distributed name allocation
  method used for host names.  There is some sentiment for allowing the
  NIC to continue to allocate and regulate network names, much as it
  allocates numbers, but the majority opinion favors local control of

Mockapetris [Page 2]

RFC 1101 DNS Encoding of Network Names and Other Types April 1989

  network names.  Although it would be possible to provide a flat space
  or a name space in which, for example, the last label of a domain
  name captured the old-style network name, any such approach would add
  complexity to the method and create different rules for network names
  and host names.

  For these reasons, we assume that the syntax of network names will be
  the same as the expanded syntax for host names permitted in [HR].
  The new syntax expands the set of names to allow leading digits, so
  long as the resulting representations do not conflict with IP
  addresses in decimal octet form.  For example, 3Com.COM and 3M.COM
  are now legal, although 26.0.0.73.COM is not.  See [HR] for details.

  The price is that network names will get as complicated as host
  names.  An administrator will be able to create network names in any
  domain under his control, and also create network number to name
  entries in IN-ADDR.ARPA domains under his control.  Thus, the name
  for the ARPANET might become NET.ARPA, ARPANET.ARPA or Arpa-
  network.MIL., depending on the preferences of the owner.

3.2. Mappings

  The desired mappings, ranked by priority with most important first,
  are:

     - Mapping a IP address or network number to a network name.

       This mapping is for use in debugging tools and status displays
       of various sorts.  The conversion from IP address to network
       number is well known for class A, B, and C IP addresses, and
       involves a simple mask operation.  The needs of other classes
       are not yet defined and are ignored for the rest of this RFC.

     - Mapping a network name to a network address.

       This facility is of less obvious application, but a
       symmetrical mapping seems desirable.

     - Mapping an organization to its network names and numbers.

       This facility is useful because it may not always be possible
       to guess the local choice for network names, but the
       organization name is often well known.

     - Similar mappings for subnets, even when nested.

       The primary application is to be able to identify all of the
       subnets involved in a particular IP address.  A secondary

Mockapetris [Page 3]

RFC 1101 DNS Encoding of Network Names and Other Types April 1989

       requirement is to retrieve address mask information.

3.3. Network address section of the name space

  The network name syntax discussed above can provide domain names
  which will contain mappings from network names to various quantities,
  but we also need a section of the name space, organized by network
  and subnet number to hold the inverse mappings.

  The choices include:

     - The same network number slots already assigned and delegated
       in the IN-ADDR.ARPA section of the name space.

       For example, 10.IN-ADDR.ARPA for class A net 10,
       2.128.IN-ADDR.ARPA for class B net 128.2, etc.

     - Host-zero addresses in the IN-ADDR.ARPA tree.  (A host field
       of all zero in an IP address is prohibited because of
       confusion related to broadcast addresses, et al.)

       For example, 0.0.0.10.IN-ADDR.ARPA for class A net 10,
       0.0.2.128.IN-ADDR.arpa for class B net 128.2, etc.  Like the
       first scheme, it uses in-place name space delegations to
       distribute control.

       The main advantage of this scheme over the first is that it
       allows convenient names for subnets as well as networks.  A
       secondary advantage is that it uses names which are not in use
       already, and hence it is possible to test whether an
       organization has entered this information in its domain
       database.

     - Some new section of the name space.

       While this option provides the most opportunities, it creates
       a need to delegate a whole new name space.  Since the IP
       address space is so closely related to the network number
       space, most believe that the overhead of creating such a new
       space is overwhelming and would lead to the WKS syndrome.  (As
       of February, 1989, approximately 400 sections of the
       IN-ADDR.ARPA tree are already delegated, usually at network
       boundaries.)

Mockapetris [Page 4]

RFC 1101 DNS Encoding of Network Names and Other Types April 1989

4. SPECIFICS FOR NETWORK NAME MAPPINGS

  The proposed solution uses information stored at:

     - Names in the IN-ADDR.ARPA tree that correspond to host-zero IP
       addresses.  The same method is used for subnets in a nested
       fashion.  For example, 0.0.0.10.IN-ADDR.ARPA. for net 10.

       Two types of information are stored here: PTR RRs which point
       to the network name in their data sections, and A RRs, which
       are present if the network (or subnet) is subnetted further.
       If a type A RR is present, then it has the address mask as its
       data.  The general form is:

       <reversed-host-zero-number>.IN-ADDR.ARPA. PTR <network-name>
       <reversed-host-zero-number>.IN-ADDR.ARPA. A   <subnet-mask>

       For example:

       0.0.0.10.IN-ADDR.ARPA.  PTR     ARPANET.ARPA.

       or

       0.0.2.128.IN-ADDR.ARPA. PTR     cmu-net.cmu.edu.
                               A       255.255.255.0

       In general, this information will be added to an existing
       master file for some IN-ADDR.ARPA domain for each network
       involved.  Similar RRs can be used at host-zero subnet
       entries.

     - Names which are network names.

       The data stored here is PTR RRs pointing at the host-zero
       entries.  The general form is:

       <network-name> ptr <reversed-host-zero-number>.IN-ADDR.ARPA

       For example:

       ARPANET.ARPA.           PTR     0.0.0.10.IN-ADDR.ARPA.

       or

       isi-net.isi.edu.        PTR     0.0.9.128.IN-ADDR.ARPA.

       In general, this information will be inserted in the master
       file for the domain name of the organization; this is a

Mockapetris [Page 5]

RFC 1101 DNS Encoding of Network Names and Other Types April 1989

       different file from that which holds the information below
       IN-ADDR.ARPA.  Similar PTR RRs can be used at subnet names.

     - Names corresponding to organizations.

       The data here is one or more PTR RRs pointing at the
       IN-ADDR.ARPA names corresponding to host-zero entries for
       networks.

       For example:

       ISI.EDU.        PTR     0.0.9.128.IN-ADDR.ARPA.

       MCC.COM.        PTR     0.167.5.192.IN-ADDR.ARPA.
                       PTR     0.168.5.192.IN-ADDR.ARPA.
                       PTR     0.169.5.192.IN-ADDR.ARPA.
                       PTR     0.0.62.128.IN-ADDR.ARPA.

4.1. A simple example

  The ARPANET is a Class A network without subnets.  The RRs which
  would be added, assuming the ARPANET.ARPA was selected as a network
  name, would be:

  ARPA.                   PTR     0.0.0.10.IN-ADDR.ARPA.

  ARPANET.ARPA.           PTR     0.0.0.10.IN-ADDR.ARPA.

  0.0.0.10.IN-ADDR.ARPA.  PTR     ARPANET.ARPA.

  The first RR states that the organization named ARPA owns net 10 (It
  might also own more network numbers, and these would be represented
  with an additional RR per net.)  The second states that the network
  name ARPANET.ARPA. maps to net 10.  The last states that net 10 is
  named ARPANET.ARPA.

  Note that all of the usual host and corresponding IN-ADDR.ARPA
  entries would still be required.

4.2. A complicated, subnetted example

  The ISI network is 128.9, a class B number.  Suppose the ISI network
  was organized into two levels of subnet, with the first level using
  an additional 8 bits of address, and the second level using 4 bits,
  for address masks of x'FFFFFF00' and X'FFFFFFF0'.

  Then the following RRs would be entered in ISI's master file for the
  ISI.EDU zone:

Mockapetris [Page 6]

RFC 1101 DNS Encoding of Network Names and Other Types April 1989

  ; Define network entry
  isi-net.isi.edu.                PTR  0.0.9.128.IN-ADDR.ARPA.

  ; Define first level subnets
  div1-subnet.isi.edu.            PTR  0.1.9.128.IN-ADDR.ARPA.
  div2-subnet.isi.edu.            PTR  0.2.9.128.IN-ADDR.ARPA.

  ; Define second level subnets
  inc-subsubnet.isi.edu.          PTR  16.2.9.128.IN-ADDR.ARPA.

  in the 9.128.IN-ADDR.ARPA zone:

  ; Define network number and address mask
  0.0.9.128.IN-ADDR.ARPA.         PTR  isi-net.isi.edu.
                                  A    255.255.255.0  ;aka X'FFFFFF00'

  ; Define one of the first level subnet numbers and masks
  0.1.9.128.IN-ADDR.ARPA.         PTR  div1-subnet.isi.edu.
                                  A    255.255.255.240 ;aka X'FFFFFFF0'

  ; Define another first level subnet number and mask
  0.2.9.128.IN-ADDR.ARPA.         PTR  div2-subnet.isi.edu.
                                  A    255.255.255.240 ;aka X'FFFFFFF0'

  ; Define second level subnet number
  16.2.9.128.IN-ADDR.ARPA.        PTR  inc-subsubnet.isi.edu.

  This assumes that the ISI network is named isi-net.isi.edu., first
  level subnets are named div1-subnet.isi.edu. and div2-
  subnet.isi.edu., and a second level subnet is called inc-
  subsubnet.isi.edu.  (In a real system as complicated as this there
  would be more first and second level subnets defined, but we have
  shown enough to illustrate the ideas.)

4.3. Procedure for using an IP address to get network name

  Depending on whether the IP address is class A, B, or C, mask off the
  high one, two, or three bytes, respectively.  Reverse the octets,
  suffix IN-ADDR.ARPA, and do a PTR query.

  For example, suppose the IP address is 10.0.0.51.

     1. Since this is a class A address, use a mask x'FF000000' and
        get 10.0.0.0.

     2. Construct the name 0.0.0.10.IN-ADDR.ARPA.

     3. Do a PTR query.  Get back

Mockapetris [Page 7]

RFC 1101 DNS Encoding of Network Names and Other Types April 1989

        0.0.0.10.IN-ADDR.ARPA.  PTR     ARPANET.ARPA.

     4. Conclude that the network name is "ARPANET.ARPA."

  Suppose that the IP address is 128.9.2.17.

     1. Since this is a class B address, use a mask of x'FFFF0000'
        and get 128.9.0.0.

     2. Construct the name 0.0.9.128.IN-ADDR.ARPA.

     3. Do a PTR query.  Get back

        0.0.9.128.IN-ADDR.ARPA.       PTR     isi-net.isi.edu

     4. Conclude that the network name is "isi-net.isi.edu."

4.4. Procedure for finding all subnets involved with an IP address

  This is a simple extension of the IP address to network name method.
  When the network entry is located, do a lookup for a possible A RR.
  If the A RR is found, look up the next level of subnet using the
  original IP address and the mask in the A RR.  Repeat this procedure
  until no A RR is found.

  For example, repeating the use of 128.9.2.17.

     1. As before construct a query for 0.0.9.128.IN-ADDR.ARPA.
        Retrieve:

        0.0.9.128.IN-ADDR.ARPA.  PTR    isi-net.isi.edu.
                                 A      255.255.255.0

     2. Since an A RR was found, repeat using mask from RR
        (255.255.255.0), constructing a query for
        0.2.9.128.IN-ADDR.ARPA.  Retrieve:

        0.2.9.128.IN-ADDR.ARPA.  PTR    div2-subnet.isi.edu.
                                 A      255.255.255.240

     3. Since another A RR was found, repeat using mask
        255.255.255.240 (x'FFFFFFF0').  constructing a query for
        16.2.9.128.IN-ADDR.ARPA.  Retrieve:

        16.2.9.128.IN-ADDR.ARPA. PTR    inc-subsubnet.isi.edu.

     4. Since no A RR is present at 16.2.9.128.IN-ADDR.ARPA., there
        are no more subnet levels.

Mockapetris [Page 8]

RFC 1101 DNS Encoding of Network Names and Other Types April 1989

5. YP ISSUES AND DISCUSSION

  The term "Yellow Pages" is used in almost as many ways as the term
  "domain", so it is useful to define what is meant herein by YP.  The
  general problem to be solved is to create a method for creating
  mappings from one kind of identifier to another, often with an
  inverse capability.  The traditional methods are to search or use a
  precomputed index of some kind.

  Searching is impractical when the search is too large, and
  precomputed indexes are possible only when it is possible to specify
  search criteria in advance, and pay for the resources necessary to
  build the index.  For example, it is impractical to search the entire
  domain tree to find a particular address RR, so we build the IN-
  ADDR.ARPA YP.  Similarly, we could never build an Internet-wide index
  of "hosts with a load average of less than 2" in less time than it
  would take for the data to change, so indexes are a useless approach
  for that problem.

  Such a precomputed index is what we mean by YP, and we regard the
  IN-ADDR.ARPA domain as the first instance of a YP in the DNS.
  Although a single, centrally-managed YP for well-known values such as
  TCP-port is desirable, we regard organization-specific YPs for, say,
  locally defined TCP ports as a natural extension, as are combinations
  of YPs using search lists to merge the two.

  In examining Internet Numbers [RFC 997] and Assigned Numbers [RFC
  1010], it is clear that there are several mappings which might be of
  value.  For example:

  <assigned-network-name> <==> <IP-address>
  <autonomous-system-id>  <==> <number>
  <protocol-id>           <==> <number>
  <port-id>               <==> <number>
  <ethernet-type>         <==> <number>
  <public-data-net>       <==> <IP-address>

  Following the IN-ADDR example, the YP takes the form of a domain tree
  organized to optimize retrieval by search key and distribution via
  normal DNS rules.  The name used as a key must include:

     1. A well known origin.  For example, IN-ADDR.ARPA is the
        current IP-address to host name YP.

     2. A "from" data type.  This identifies the input type of the
        mapping.  This is necessary because we may be mapping
        something as anonymous as a number to any number of
        mnemonics, etc.

Mockapetris [Page 9]

RFC 1101 DNS Encoding of Network Names and Other Types April 1989

     3. A "to" data type.  Since we assume several symmetrical
        mnemonic <==> number mappings, this is also necessary.

  This ordering reflects the natural scoping of control, and hence the
  order of the components in a domain name.  Thus domain names would be
  of the form:

  <from-value>.<to-data-type>.<from-data-type>.<YP-origin>

  To make this work, we need to define well-know strings for each of
  these metavariables, as well as encoding rules for converting a
  <from-value> into a domain name.  We might define:

  <YP-origin>     :=YP
  <from-data-type>:=TCP-port | IN-ADDR | Number |
                    Assigned-network-number | Name
  <to-data-type>  :=<from-data-type>

  Note that "YP" is NOT a valid country code under [ISO 3166] (although
  we may want to worry about the future), and the existence of a
  syntactically valid <to-data-type>.<from-data-type> pair does not
  imply that a meaningful mapping exists, or is even possible.

  The encoding rules might be:

  TCP-port        Six character alphanumeric

  IN-ADDR         Reversed 4-octet decimal string

  Number          decimal integer

  Assigned-network-number
                  Reversed 4-octet decimal string

  Name            Domain name

6. SPECIFICS FOR YP MAPPINGS

6.1. TCP-PORT

  $origin Number.TCP-port.YP.

  23              PTR     TELNET.TCP-port.Number.YP.
  25              PTR     SMTP.TCP-port.Number.YP.

  $origin TCP-port.Number.YP.

  TELNET          PTR     23.Number.TCP-port.YP.

Mockapetris [Page 10]

RFC 1101 DNS Encoding of Network Names and Other Types April 1989

  SMTP            PTR     25.Number.TCP-port.YP.

  Thus the mapping between 23 and TELNET is represented by a pair of
  PTR RRs, one for each direction of the mapping.

6.2. Assigned networks

  Network numbers are assigned by the NIC and reported in "Internet
  Numbers" RFCs.  To create a YP, the NIC would set up two domains:

  Name.Assigned-network-number.YP and Assigned-network-number.YP

  The first would contain entries of the form:

  $origin Name.Assigned-network-number.YP.

  0.0.0.4         PTR     SATNET.Assigned-network-number.Name.YP.
  0.0.0.10        PTR     ARPANET.Assigned-network-number.Name.YP.

  The second would contain entries of the form:

  $origin Assigned-network-number.Name.YP.

  SATNET.         PTR     0.0.0.4.Name.Assigned-network-number.YP.
  ARPANET.        PTR     0.0.0.10.Name.Assigned-network-number.YP.

  These YPs are not in conflict with the network name support described
  in the first half of this RFC since they map between ASSIGNED network
  names and numbers, not those allocated by the organizations
  themselves.  That is, they document the NIC's decisions about
  allocating network numbers but do not automatically track any
  renaming performed by the new owners.

  As a practical matter, we might want to create both of these domains
  to enable users on the Internet to experiment with centrally
  maintained support as well as the distributed version, or might want
  to implement only the allocated number to name mapping and request
  organizations to convert their allocated network names to the network
  names described in the distributed model.

6.3. Operational improvements

  We could imagine that all conversion routines using these YPs might
  be instructed to use "YP.<local-domain>" followed by "YP."  as a
  search list.  Thus, if the organization ISI.EDU wished to define
  locally meaningful TCP-PORT, it would define the domains:

  <TCP-port.Number.YP.ISI.EDU> and <Number.TCP-port.YP.ISI.EDU>.

Mockapetris [Page 11]

RFC 1101 DNS Encoding of Network Names and Other Types April 1989

  We could add another level of indirection in the YP lookup, defining
  the <to-data-type>.<from-data-type>.<YP-origin> nodes to point to the
  YP tree, rather than being the YP tree directly.  This would enable
  entries of the form:

  IN-ADDR.Netname.YP.   PTR     IN-ADDR.ARPA.

  to splice in YPs from other origins or existing spaces.

  Another possibility would be to shorten the RDATA section of the RRs
  which map back and forth by deleting the origin.  This could be done
  either by allowing the domain name in the RDATA portion to not
  identify a real domain name, or by defining a new RR which used a
  simple text string rather than a domain name.

  Thus, we might replace

  $origin Assigned-network-number.Name.YP.

  SATNET.         PTR     0.0.0.4.Name.Assigned-network-number.YP.
  ARPANET.        PTR     0.0.0.10.Name.Assigned-network-number.YP.

  with

  $origin Assigned-network-number.Name.YP.

  SATNET.         PTR     0.0.0.4.
  ARPANET.        PTR     0.0.0.10.

  or

  $origin Assigned-network-number.Name.YP.

  SATNET.         PTT     "0.0.0.4"
  ARPANET.        PTT     "0.0.0.10"

  where PTT is a new type whose RDATA section is a text string.

7. ACKNOWLEDGMENTS

  Drew Perkins, Mark Lottor, and Rob Austein contributed several of the
  ideas in this RFC.  Numerous contributions, criticisms, and
  compromises were produced in the IETF Domain working group and the
  NAMEDROPPERS mailing list.

Mockapetris [Page 12]

RFC 1101 DNS Encoding of Network Names and Other Types April 1989

8. REFERENCES

  [HR]        Braden, B., editor, "Requirements for Internet Hosts",
              RFC in preparation.

  [ISO 3166]  ISO, "Codes for the Representation of Names of
              Countries", 1981.

  [RFC 882]   Mockapetris, P., "Domain names - Concepts and
              Facilities", RFC 882, USC/Information Sciences Institute,
              November 1983.

              Superseded by RFC 1034.

  [RFC 883]   Mockapetris, P.,"Domain names - Implementation and
              Specification", RFC 883, USC/Information Sciences
              Institute, November 1983.

              Superceeded by RFC 1035.

  [RFC 920]   Postel, J. and J. Reynolds, "Domain Requirements", RFC
              920, October 1984.

              Explains the naming scheme for top level domains.

  [RFC 952]   Harrenstien, K., M. Stahl, and E. Feinler, "DoD Internet
              Host Table Specification", RFC 952, SRI, October 1985.

              Specifies the format of HOSTS.TXT, the host/address table
              replaced by the DNS

  [RFC 973]   Mockapetris, P., "Domain System Changes and
              Observations", RFC 973, USC/Information Sciences
              Institute, January 1986.

              Describes changes to RFCs 882 and 883 and reasons for
              them.

  [RFC 974]   Partridge, C., "Mail routing and the domain system", RFC
              974, CSNET CIC BBN Labs, January 1986.

              Describes the transition from HOSTS.TXT based mail
              addressing to the more powerful MX system used with the
              domain system.

Mockapetris [Page 13]

RFC 1101 DNS Encoding of Network Names and Other Types April 1989

  [RFC 997]   Reynolds, J., and J. Postel, "Internet Numbers", RFC 997,
              USC/Information Sciences Institute, March 1987

              Contains network numbers, autonomous system numbers, etc.

  [RFC 1010]  Reynolds, J., and J. Postel, "Assigned Numbers", RFC
              1010, USC/Information Sciences Institute, May 1987

              Contains socket numbers and mnemonics for host names,
              operating systems, etc.

  [RFC 1034]  Mockapetris, P., "Domain names - Concepts and
              Facilities", RFC 1034, USC/Information Sciences
              Institute, November 1987.

              Introduction/overview of the DNS.

  [RFC 1035]  Mockapetris, P., "Domain names - Implementation and
              Specification", RFC 1035, USC/Information Sciences
              Institute, November 1987.

              DNS implementation instructions.

Author's Address:

  Paul Mockapetris
  USC/Information Sciences Institute
  4676 Admiralty Way
  Marina del Rey, CA 90292

  Phone: (213) 822-1511

  Email: [email protected]

Mockapetris [Page 14]