7Network Working Group P. Mockapetris
8Request for Comments: 1101 ISI
9Updates: RFCs 1034, 1035 April 1989
12 DNS Encoding of Network Names and Other Types
17 This RFC proposes two extensions to the Domain Name System:
19 - A specific method for entering and retrieving RRs which map
20 between network names and numbers.
22 - Ideas for a general method for describing mappings between
23 arbitrary identifiers and numbers.
25 The method for mapping between network names and addresses is a
26 proposed standard, the ideas for a general method are experimental.
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.
32 Distribution of this memo is unlimited.
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
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:
49 - Several tradeoffs involving control of network names, the
50 syntax of network names, backward compatibility, etc.
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,
60RFC 1101 DNS Encoding of Network Names and Other Types April 1989
63 autonomous system names and numbers, X.500 Relative
64 Distinguished Names (RDNs) and their servers, or whatever.
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.
75 Both structures are described in following sections. Each structure
76 has a discussion of design issues and specific structure
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
913. NETWORK NAME ISSUES AND DISCUSSION
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.
973.1. Network name syntax
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.
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
116RFC 1101 DNS Encoding of Network Names and Other Types April 1989
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
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.
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.
141 The desired mappings, ranked by priority with most important first,
144 - Mapping a IP address or network number to a network name.
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.
152 - Mapping a network name to a network address.
154 This facility is of less obvious application, but a
155 symmetrical mapping seems desirable.
157 - Mapping an organization to its network names and numbers.
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.
163 - Similar mappings for subnets, even when nested.
165 The primary application is to be able to identify all of the
166 subnets involved in a particular IP address. A secondary
172RFC 1101 DNS Encoding of Network Names and Other Types April 1989
175 requirement is to retrieve address mask information.
1773.3. Network address section of the name space
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.
186 - The same network number slots already assigned and delegated
187 in the IN-ADDR.ARPA section of the name space.
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.
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.)
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
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
208 - Some new section of the name space.
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
228RFC 1101 DNS Encoding of Network Names and Other Types April 1989
2314. SPECIFICS FOR NETWORK NAME MAPPINGS
233 The proposed solution uses information stored at:
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.
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:
245 <reversed-host-zero-number>.IN-ADDR.ARPA. PTR <network-name>
246 <reversed-host-zero-number>.IN-ADDR.ARPA. A <subnet-mask>
250 0.0.0.10.IN-ADDR.ARPA. PTR ARPANET.ARPA.
254 0.0.2.128.IN-ADDR.ARPA. PTR cmu-net.cmu.edu.
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
262 - Names which are network names.
264 The data stored here is PTR RRs pointing at the host-zero
265 entries. The general form is:
267 <network-name> ptr <reversed-host-zero-number>.IN-ADDR.ARPA
271 ARPANET.ARPA. PTR 0.0.0.10.IN-ADDR.ARPA.
275 isi-net.isi.edu. PTR 0.0.9.128.IN-ADDR.ARPA.
277 In general, this information will be inserted in the master
278 file for the domain name of the organization; this is a
284RFC 1101 DNS Encoding of Network Names and Other Types April 1989
287 different file from that which holds the information below
288 IN-ADDR.ARPA. Similar PTR RRs can be used at subnet names.
290 - Names corresponding to organizations.
292 The data here is one or more PTR RRs pointing at the
293 IN-ADDR.ARPA names corresponding to host-zero entries for
298 ISI.EDU. PTR 0.0.9.128.IN-ADDR.ARPA.
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.
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
311 ARPA. PTR 0.0.0.10.IN-ADDR.ARPA.
313 ARPANET.ARPA. PTR 0.0.0.10.IN-ADDR.ARPA.
315 0.0.0.10.IN-ADDR.ARPA. PTR ARPANET.ARPA.
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
323 Note that all of the usual host and corresponding IN-ADDR.ARPA
324 entries would still be required.
3264.2. A complicated, subnetted example
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'.
333 Then the following RRs would be entered in ISI's master file for the
340RFC 1101 DNS Encoding of Network Names and Other Types April 1989
343 ; Define network entry
344 isi-net.isi.edu. PTR 0.0.9.128.IN-ADDR.ARPA.
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.
350 ; Define second level subnets
351 inc-subsubnet.isi.edu. PTR 16.2.9.128.IN-ADDR.ARPA.
353 in the 9.128.IN-ADDR.ARPA zone:
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'
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'
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'
367 ; Define second level subnet number
368 16.2.9.128.IN-ADDR.ARPA. PTR inc-subsubnet.isi.edu.
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.)
3774.3. Procedure for using an IP address to get network name
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.
383 For example, suppose the IP address is 10.0.0.51.
385 1. Since this is a class A address, use a mask x'FF000000' and
388 2. Construct the name 0.0.0.10.IN-ADDR.ARPA.
390 3. Do a PTR query. Get back
396RFC 1101 DNS Encoding of Network Names and Other Types April 1989
399 0.0.0.10.IN-ADDR.ARPA. PTR ARPANET.ARPA.
401 4. Conclude that the network name is "ARPANET.ARPA."
403 Suppose that the IP address is 128.9.2.17.
405 1. Since this is a class B address, use a mask of x'FFFF0000'
408 2. Construct the name 0.0.9.128.IN-ADDR.ARPA.
410 3. Do a PTR query. Get back
412 0.0.9.128.IN-ADDR.ARPA. PTR isi-net.isi.edu
414 4. Conclude that the network name is "isi-net.isi.edu."
4164.4. Procedure for finding all subnets involved with an IP address
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.
424 For example, repeating the use of 128.9.2.17.
426 1. As before construct a query for 0.0.9.128.IN-ADDR.ARPA.
429 0.0.9.128.IN-ADDR.ARPA. PTR isi-net.isi.edu.
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:
436 0.2.9.128.IN-ADDR.ARPA. PTR div2-subnet.isi.edu.
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:
443 16.2.9.128.IN-ADDR.ARPA. PTR inc-subsubnet.isi.edu.
445 4. Since no A RR is present at 16.2.9.128.IN-ADDR.ARPA., there
446 are no more subnet levels.
452RFC 1101 DNS Encoding of Network Names and Other Types April 1989
4555. YP ISSUES AND DISCUSSION
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.
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
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.
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
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>
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:
496 1. A well known origin. For example, IN-ADDR.ARPA is the
497 current IP-address to host name YP.
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
508RFC 1101 DNS Encoding of Network Names and Other Types April 1989
511 3. A "to" data type. Since we assume several symmetrical
512 mnemonic <==> number mappings, this is also necessary.
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
518 <from-value>.<to-data-type>.<from-data-type>.<YP-origin>
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:
525 <from-data-type>:=TCP-port | IN-ADDR | Number |
526 Assigned-network-number | Name
527 <to-data-type> :=<from-data-type>
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.
534 The encoding rules might be:
536 TCP-port Six character alphanumeric
538 IN-ADDR Reversed 4-octet decimal string
540 Number decimal integer
542 Assigned-network-number
543 Reversed 4-octet decimal string
5476. SPECIFICS FOR YP MAPPINGS
551 $origin Number.TCP-port.YP.
553 23 PTR TELNET.TCP-port.Number.YP.
554 25 PTR SMTP.TCP-port.Number.YP.
556 $origin TCP-port.Number.YP.
558 TELNET PTR 23.Number.TCP-port.YP.
564RFC 1101 DNS Encoding of Network Names and Other Types April 1989
567 SMTP PTR 25.Number.TCP-port.YP.
569 Thus the mapping between 23 and TELNET is represented by a pair of
570 PTR RRs, one for each direction of the mapping.
5726.2. Assigned networks
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:
577 Name.Assigned-network-number.YP and Assigned-network-number.YP
579 The first would contain entries of the form:
581 $origin Name.Assigned-network-number.YP.
583 0.0.0.4 PTR SATNET.Assigned-network-number.Name.YP.
584 0.0.0.10 PTR ARPANET.Assigned-network-number.Name.YP.
586 The second would contain entries of the form:
588 $origin Assigned-network-number.Name.YP.
590 SATNET. PTR 0.0.0.4.Name.Assigned-network-number.YP.
591 ARPANET. PTR 0.0.0.10.Name.Assigned-network-number.YP.
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.
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.
6076.3. Operational improvements
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:
614 <TCP-port.Number.YP.ISI.EDU> and <Number.TCP-port.YP.ISI.EDU>.
620RFC 1101 DNS Encoding of Network Names and Other Types April 1989
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
628 IN-ADDR.Netname.YP. PTR IN-ADDR.ARPA.
630 to splice in YPs from other origins or existing spaces.
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.
638 Thus, we might replace
640 $origin Assigned-network-number.Name.YP.
642 SATNET. PTR 0.0.0.4.Name.Assigned-network-number.YP.
643 ARPANET. PTR 0.0.0.10.Name.Assigned-network-number.YP.
647 $origin Assigned-network-number.Name.YP.
650 ARPANET. PTR 0.0.0.10.
654 $origin Assigned-network-number.Name.YP.
656 SATNET. PTT "0.0.0.4"
657 ARPANET. PTT "0.0.0.10"
659 where PTT is a new type whose RDATA section is a text string.
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.
676RFC 1101 DNS Encoding of Network Names and Other Types April 1989
681 [HR] Braden, B., editor, "Requirements for Internet Hosts",
684 [ISO 3166] ISO, "Codes for the Representation of Names of
687 [RFC 882] Mockapetris, P., "Domain names - Concepts and
688 Facilities", RFC 882, USC/Information Sciences Institute,
691 Superseded by RFC 1034.
693 [RFC 883] Mockapetris, P.,"Domain names - Implementation and
694 Specification", RFC 883, USC/Information Sciences
695 Institute, November 1983.
697 Superceeded by RFC 1035.
699 [RFC 920] Postel, J. and J. Reynolds, "Domain Requirements", RFC
702 Explains the naming scheme for top level domains.
704 [RFC 952] Harrenstien, K., M. Stahl, and E. Feinler, "DoD Internet
705 Host Table Specification", RFC 952, SRI, October 1985.
707 Specifies the format of HOSTS.TXT, the host/address table
710 [RFC 973] Mockapetris, P., "Domain System Changes and
711 Observations", RFC 973, USC/Information Sciences
712 Institute, January 1986.
714 Describes changes to RFCs 882 and 883 and reasons for
717 [RFC 974] Partridge, C., "Mail routing and the domain system", RFC
718 974, CSNET CIC BBN Labs, January 1986.
720 Describes the transition from HOSTS.TXT based mail
721 addressing to the more powerful MX system used with the
732RFC 1101 DNS Encoding of Network Names and Other Types April 1989
735 [RFC 997] Reynolds, J., and J. Postel, "Internet Numbers", RFC 997,
736 USC/Information Sciences Institute, March 1987
738 Contains network numbers, autonomous system numbers, etc.
740 [RFC 1010] Reynolds, J., and J. Postel, "Assigned Numbers", RFC
741 1010, USC/Information Sciences Institute, May 1987
743 Contains socket numbers and mnemonics for host names,
744 operating systems, etc.
747 [RFC 1034] Mockapetris, P., "Domain names - Concepts and
748 Facilities", RFC 1034, USC/Information Sciences
749 Institute, November 1987.
751 Introduction/overview of the DNS.
753 [RFC 1035] Mockapetris, P., "Domain names - Implementation and
754 Specification", RFC 1035, USC/Information Sciences
755 Institute, November 1987.
757 DNS implementation instructions.
762 USC/Information Sciences Institute
764 Marina del Rey, CA 90292
766 Phone: (213) 822-1511