diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc1101.txt')
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc1101.txt | 787 |
1 files changed, 0 insertions, 787 deletions
diff --git a/contrib/bind9/doc/rfc/rfc1101.txt b/contrib/bind9/doc/rfc/rfc1101.txt deleted file mode 100644 index 66c9d8b..0000000 --- a/contrib/bind9/doc/rfc/rfc1101.txt +++ /dev/null @@ -1,787 +0,0 @@ - - - - - - -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: PVM@ISI.EDU - - - - - - - - - - - - - - - - - -Mockapetris [Page 14] -
\ No newline at end of file |
