DNS encoding of network names and other types
RFC 1101

   ; 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: PVM@ISI.EDU

Mockapetris                                                    [Page 14]