As per Relevance of the word mappings, we have this rfc below:
Network Working Group P.
Request for Comments: 1101
Updates: RFCs 1034, 1035 April 1989
DNS Encoding of Network Names and Other
1. STATUS OF THIS
This RFC proposes two extensions to the Domain Name System
- A specific method for entering and retrieving RRs which
between network names and numbers
- Ideas for a general method for describing mappings
arbitrary identifiers and numbers
The method for mapping between network names and addresses is
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
does not necessarily reflect the real Internet
Distribution of this memo is unlimited
2.
The DNS is extensible and can be used for a virtually
number of data types, name spaces, etc. New type definitions
occasionally necessary as are revisions or deletions of old
(e.g., MX replacement of MD and MF [RFC 974]), and changes
in [RFC 973]. This RFC describes changes due to the general need
map between identifiers and values, and a specific need for
name support
Users wish to be able to use the DNS to map between network names
numbers. This need is the only capability found in HOSTS.TXT
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,
syntax of network names, backward compatibility, etc
- A desire to create a method which would be
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
Distinguished Names (RDNs) and their servers, or whatever
It was impossible to reconcile these two areas of concern for
names because of the desire to unify network number support
existing IP address to host name support. The existing support
the IN-ADDR.ARPA section of the DNS name space. As a result this
describes one structure for network names which builds on
existing support for host names, and another family of structures
future yellow pages (YP) functions such as conversions between TCP
port numbers and mnemonics
Both structures are described in following sections. Each
has a discussion of design issues and specific
recommendations
We wish to avoid defining structures and methods which can work
do not because of indifference or errors on the part of
administrators when maintaining the database. The WKS RR is
example. Thus, while we favor distribution as a general method,
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
for mapping between allocated network numbers and network names
(Allocation is centrally performed by the SRI Network
Center, aka the NIC).
3. NETWORK NAME ISSUES AND
The issues involved in the design were the definition of network
syntax, the mappings to be provided, and possible support for
functions at the subnet level
3.1. Network name
The current syntax for network names, as defined by [RFC 952] is
alphanumeric string of up to 24 characters, which begins with
alpha, and may include "." and "-" except as first and
characters. This is the format which was also used for host
before the DNS. Upward compatibility with existing names might be
goal of any new scheme
However, the present syntax has been used to define a flat
space, and hence would prohibit the same distributed name
method used for host names. There is some sentiment for allowing
NIC to continue to allocate and regulate network names, much as
allocates numbers, but the majority opinion favors local control
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
or a name space in which, for example, the last label of a
name captured the old-style network name, any such approach would
complexity to the method and create different rules for network
and host names
For these reasons, we assume that the syntax of network names will
the same as the expanded syntax for host names permitted in [HR].
The new syntax expands the set of names to allow leading digits,
long as the resulting representations do not conflict with
addresses in decimal octet form. For example, 3Com.COM and 3M.
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
names. An administrator will be able to create network names in
domain under his control, and also create network number to
entries in IN-ADDR.ARPA domains under his control. Thus, the
for the ARPANET might become NET.ARPA, ARPANET.ARPA or Arpa
network.MIL., depending on the preferences of the owner
3.2.
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
of various sorts. The conversion from IP address to
number is well known for class A, B, and C IP addresses,
involves a simple mask operation. The needs of other
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
symmetrical mapping seems desirable
- Mapping an organization to its network names and numbers
This facility is useful because it may not always be
to guess the local choice for network names, but
organization name is often well known
- Similar mappings for subnets, even when nested
The primary application is to be able to identify all of
subnets involved in a particular IP address. A
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
The network name syntax discussed above can provide domain
which will contain mappings from network names to various quantities
but we also need a section of the name space, organized by
and subnet number to hold the inverse mappings
The choices include
- The same network number slots already assigned and
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
of all zero in an IP address is prohibited because
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
first scheme, it uses in-place name space delegations
distribute control
The main advantage of this scheme over the first is that
allows convenient names for subnets as well as networks.
secondary advantage is that it uses names which are not in
already, and hence it is possible to test whether
organization has entered this information in its
database
- Some new section of the name space
While this option provides the most opportunities, it
a need to delegate a whole new name space. Since the
address space is so closely related to the network
space, most believe that the overhead of creating such a
space is overwhelming and would lead to the WKS syndrome. (
of February, 1989, approximately 400 sections of
IN-ADDR.ARPA tree are already delegated, usually at
boundaries.)
Mockapetris [Page 4]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
4. SPECIFICS FOR NETWORK NAME
The proposed solution uses information stored at
- Names in the IN-ADDR.ARPA tree that correspond to host-zero
addresses. The same method is used for subnets in a
fashion. For example, 0.0.0.10.IN-ADDR.ARPA. for net 10.
Two types of information are stored here: PTR RRs which
to the network name in their data sections, and A RRs,
are present if the network (or subnet) is subnetted further
If a type A RR is present, then it has the address mask as
data. The general form is
<reversed-host-zero-number>.IN-ADDR.ARPA. PTR
<reversed-host-zero-number>.IN-ADDR.ARPA. A
For example
0.0.0.10.IN-ADDR.ARPA. PTR ARPANET.ARPA
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
master file for some IN-ADDR.ARPA domain for each
involved. Similar RRs can be used at host-zero
entries
- Names which are network names
The data stored here is PTR RRs pointing at the host-
entries. The general form is
ptr <reversed-host-zero-number>.IN-ADDR.
For example
ARPANET.ARPA. PTR 0.0.0.10.IN-ADDR.ARPA
isi-net.isi.edu. PTR 0.0.9.128.IN-ADDR.ARPA
In general, this information will be inserted in the
file for the domain name of the organization; this is
Mockapetris [Page 5]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
different file from that which holds the information
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
IN-ADDR.ARPA names corresponding to host-zero entries
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
The ARPANET is a Class A network without subnets. The RRs
would be added, assuming the ARPANET.ARPA was selected as a
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 (
might also own more network numbers, and these would be
with an additional RR per net.) The second states that the
name ARPANET.ARPA. maps to net 10. The last states that net 10
named ARPANET.ARPA
Note that all of the usual host and corresponding IN-ADDR.
entries would still be required
4.2. A complicated, subnetted
The ISI network is 128.9, a class B number. Suppose the ISI
was organized into two levels of subnet, with the first level
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
ISI.EDU zone
Mockapetris [Page 6]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
; Define network
isi-net.isi.edu. PTR 0.0.9.128.IN-ADDR.ARPA
; Define first level
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
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
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
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
0.2.9.128.IN-ADDR.ARPA. PTR div2-subnet.isi.edu
A 255.255.255.240 ;aka X'FFFFFFF0'
; Define second level subnet
16.2.9.128.IN-ADDR.ARPA. PTR inc-subsubnet.isi.edu
This assumes that the ISI network is named isi-net.isi.edu.,
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
would be more first and second level subnets defined, but we
shown enough to illustrate the ideas.)
4.3. Procedure for using an IP address to get network
Depending on whether the IP address is class A, B, or C, mask off
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'
get 10.0.0.0.
2. Construct the name 0.0.0.10.IN-ADDR.ARPA
3. Do a PTR query. Get
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
0.0.9.128.IN-ADDR.ARPA. PTR isi-net.isi.
4. Conclude that the network name is "isi-net.isi.edu."
4.4. Procedure for finding all subnets involved with an IP
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
original IP address and the mask in the A RR. Repeat this
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
(255.255.255.0), constructing a query
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
255.255.255.240 (x'FFFFFFF0'). constructing a query
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.,
are no more subnet levels
Mockapetris [Page 8]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
5. YP ISSUES AND
The term "Yellow Pages" is used in almost as many ways as the
"domain", so it is useful to define what is meant herein by YP.
general problem to be solved is to create a method for
mappings from one kind of identifier to another, often with
inverse capability. The traditional methods are to search or use
precomputed index of some kind
Searching is impractical when the search is too large,
precomputed indexes are possible only when it is possible to
search criteria in advance, and pay for the resources necessary
build the index. For example, it is impractical to search the
domain tree to find a particular address RR, so we build the IN
ADDR.ARPA YP. Similarly, we could never build an Internet-wide
of "hosts with a load average of less than 2" in less time than
would take for the data to change, so indexes are a useless
for that problem
Such a precomputed index is what we mean by YP, and we regard
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
TCP-port is desirable, we regard organization-specific YPs for, say
locally defined TCP ports as a natural extension, as are
of YPs using search lists to merge the two
In examining Internet Numbers [RFC 997] and Assigned Numbers [
1010], it is clear that there are several mappings which might be
value. For example
<assigned-network-name> <==>
<autonomous-system-id> <==>
<protocol-id> <==>
<==>
<ethernet-type> <==>
<==>
Following the IN-ADDR example, the YP takes the form of a domain
organized to optimize retrieval by search key and distribution
normal DNS rules. The name used as a key must include
1. A well known origin. For example, IN-ADDR.ARPA is
current IP-address to host name YP
2. A "from" data type. This identifies the input type of
mapping. This is necessary because we may be
something as anonymous as a number to any number
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
mnemonic <==> number mappings, this is also necessary
This ordering reflects the natural scoping of control, and hence
order of the components in a domain name. Thus domain names would
of the form
...
To make this work, we need to define well-know strings for each
these metavariables, as well as encoding rules for converting
into a domain name. We might define
:=
:=TCP-port | IN-ADDR | Number |
Assigned-network-number |
:=
Note that "YP" is NOT a valid country code under [ISO 3166] (
we may want to worry about the future), and the existence of
syntactically valid . pair does
imply that a meaningful mapping exists, or is even possible
The encoding rules might be
TCP-port Six character
IN-ADDR Reversed 4-octet decimal
Number decimal
Assigned-network-
Reversed 4-octet decimal
Name Domain
6. SPECIFICS FOR YP
6.1. TCP-
$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
PTR RRs, one for each direction of the mapping
6.2. Assigned
Network numbers are assigned by the NIC and reported in "
Numbers" RFCs. To create a YP, the NIC would set up two domains
Name.Assigned-network-number.YP and Assigned-network-number.
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
in the first half of this RFC since they map between ASSIGNED
names and numbers, not those allocated by the
themselves. That is, they document the NIC's decisions
allocating network numbers but do not automatically track
renaming performed by the new owners
As a practical matter, we might want to create both of these
to enable users on the Internet to experiment with
maintained support as well as the distributed version, or might
to implement only the allocated number to name mapping and
organizations to convert their allocated network names to the
names described in the distributed model
6.3. Operational
We could imagine that all conversion routines using these YPs
be instructed to use "YP." followed by "YP." as
search list. Thus, if the organization ISI.EDU wished to
locally meaningful TCP-PORT, it would define the domains
and .
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,
the .. nodes to point to
YP tree, rather than being the YP tree directly. This would
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
which map back and forth by deleting the origin. This could be
either by allowing the domain name in the RDATA portion to
identify a real domain name, or by defining a new RR which used
simple text string rather than a domain name
Thus, we might
$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
$origin Assigned-network-number.Name.YP
SATNET. PTR 0.0.0.4.
ARPANET. PTR 0.0.0.10.
$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.
Drew Perkins, Mark Lottor, and Rob Austein contributed several of
ideas in this RFC. Numerous contributions, criticisms,
compromises were produced in the IETF Domain working group and
NAMEDROPPERS mailing list
Mockapetris [Page 12]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
8.
[HR] Braden, B., editor, "Requirements for Internet Hosts",
RFC in preparation
[ISO 3166] ISO, "Codes for the Representation of Names
Countries", 1981.
[RFC 882] Mockapetris, P., "Domain names - Concepts
Facilities", RFC 882, USC/Information Sciences Institute
November 1983.
Superseded by RFC 1034.
[RFC 883] Mockapetris, P.,"Domain names - Implementation
Specification", RFC 883, USC/Information
Institute, November 1983.
Superceeded by RFC 1035.
[RFC 920] Postel, J. and J. Reynolds, "Domain Requirements",
920, October 1984.
Explains the naming scheme for top level domains
[RFC 952] Harrenstien, K., M. Stahl, and E. Feinler, "DoD
Host Table Specification", RFC 952, SRI, October 1985.
Specifies the format of HOSTS.TXT, the host/address
replaced by the
[RFC 973] Mockapetris, P., "Domain System Changes
Observations", RFC 973, USC/Information
Institute, January 1986.
Describes changes to RFCs 882 and 883 and reasons
them
[RFC 974] Partridge, C., "Mail routing and the domain system",
974, CSNET CIC BBN Labs, January 1986.
Describes the transition from HOSTS.TXT based
addressing to the more powerful MX system used with
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",
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
Facilities", RFC 1034, USC/Information
Institute, November 1987.
Introduction/overview of the DNS
[RFC 1035] Mockapetris, P., "Domain names - Implementation
Specification", RFC 1035, USC/Information
Institute, November 1987.
DNS implementation instructions
Author's Address
Paul
USC/Information Sciences
4676 Admiralty
Marina del Rey, CA 90292
Phone: (213) 822-1511
Email: PVM@ISI.
Mockapetris [Page 14]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
