Aren
/
NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

we don't need these files either.

This commit is contained in:
mrg 1997-04-13 09:55:08 +00:00
parent 5be792e647
commit 6c5a8afbd7
7 changed files with 0 additions and 10148 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

781
usr.sbin/named/doc/rfc1032.lpr
View File

@ -1,781 +0,0 @@
Network Working Group M. Stahl
Request for Comments: 1032 SRI International
November 1987
DOMAIN ADMINISTRATORS GUIDE
STATUS OF THIS MEMO
This memo describes procedures for registering a domain with the
Network Information Center (NIC) of Defense Data Network (DDN), and
offers guidelines on the establishment and administration of a domain
in accordance with the requirements specified in RFC-920. It is
intended for use by domain administrators. This memo should be used
in conjunction with RFC-920, which is an official policy statement of
the Internet Activities Board (IAB) and the Defense Advanced Research
Projects Agency (DARPA). Distribution of this memo is unlimited.
BACKGROUND
Domains are administrative entities that provide decentralized
management of host naming and addressing. The domain-naming system
is distributed and hierarchical.
The NIC is designated by the Defense Communications Agency (DCA) to
provide registry services for the domain-naming system on the DDN and
DARPA portions of the Internet.
As registrar of top-level and second-level domains, as well as
administrator of the root domain name servers on behalf of DARPA and
DDN, the NIC is responsible for maintaining the root server zone
files and their binary equivalents. In addition, the NIC is
responsible for administering the top-level domains of "ARPA," "COM,"
"EDU," "ORG," "GOV," and "MIL" on behalf of DCA and DARPA until it
becomes feasible for other appropriate organizations to assume those
responsibilities.
It is recommended that the guidelines described in this document be
used by domain administrators in the establishment and control of
second-level domains.
THE DOMAIN ADMINISTRATOR
The role of the domain administrator (DA) is that of coordinator,
manager, and technician. If his domain is established at the second
level or lower in the tree, the DA must register by interacting with
the management of the domain directly above his, making certain that
Stahl [Page 1]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
his domain satisfies all the requirements of the administration under
which his domain would be situated. To find out who has authority
over the name space he wishes to join, the DA can ask the NIC
Hostmaster. Information on contacts for the top-level and second-
level domains can also be found on line in the file NETINFO:DOMAIN-
CONTACTS.TXT, which is available from the NIC via anonymous FTP.
The DA should be technically competent; he should understand the
concepts and procedures for operating a domain server, as described
in RFC-1034, and make sure that the service provided is reliable and
uninterrupted. It is his responsibility or that of his delegate to
ensure that the data will be current at all times. As a manager, the
DA must be able to handle complaints about service provided by his
domain name server. He must be aware of the behavior of the hosts in
his domain, and take prompt action on reports of problems, such as
protocol violations or other serious misbehavior. The administrator
of a domain must be a responsible person who has the authority to
either enforce these actions himself or delegate them to someone
else.
Name assignments within a domain are controlled by the DA, who should
verify that names are unique within his domain and that they conform
to standard naming conventions. He furnishes access to names and
name-related information to users both inside and outside his domain.
He should work closely with the personnel he has designated as the
"technical and zone" contacts for his domain, for many administrative
decisions will be made on the basis of input from these people.
THE DOMAIN TECHNICAL AND ZONE CONTACT
A zone consists of those contiguous parts of the domain tree for
which a domain server has complete information and over which it has
authority. A domain server may be authoritative for more than one
zone. The domain technical/zone contact is the person who tends to
the technical aspects of maintaining the domain's name server and
resolver software, and database files. He keeps the name server
running, and interacts with technical people in other domains and
zones to solve problems that affect his zone.
POLICIES
Domain or host name choices and the allocation of domain name space
are considered to be local matters. In the event of conflicts, it is
the policy of the NIC not to get involved in local disputes or in the
local decision-making process. The NIC will not act as referee in
disputes over such matters as who has the "right" to register a
particular top-level or second-level domain for an organization. The
NIC considers this a private local matter that must be settled among
Stahl [Page 2]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
the parties involved prior to their commencing the registration
process with the NIC. Therefore, it is assumed that the responsible
person for a domain will have resolved any local conflicts among the
members of his domain before registering that domain with the NIC.
The NIC will give guidance, if requested, by answering specific
technical questions, but will not provide arbitration in disputes at
the local level. This policy is also in keeping with the distributed
hierarchical nature of the domain-naming system in that it helps to
distribute the tasks of solving problems and handling questions.
Naming conventions for hosts should follow the rules specified in
RFC-952. From a technical standpoint, domain names can be very long.
Each segment of a domain name may contain up to 64 characters, but
the NIC strongly advises DAs to choose names that are 12 characters
or fewer, because behind every domain system there is a human being
who must keep track of the names, addresses, contacts, and other data
in a database. The longer the name, the more likely the data
maintainer is to make a mistake. Users also will appreciate shorter
names. Most people agree that short names are easier to remember and
type; most domain names registered so far are 12 characters or fewer.
Domain name assignments are made on a first-come-first-served basis.
The NIC has chosen not to register individual hosts directly under
the top-level domains it administers. One advantage of the domain
naming system is that administration and data maintenance can be
delegated down a hierarchical tree. Registration of hosts at the
same level in the tree as a second-level domain would dilute the
usefulness of this feature. In addition, the administrator of a
domain is responsible for the actions of hosts within his domain. We
would not want to find ourselves in the awkward position of policing
the actions of individual hosts. Rather, the subdomains registered
under these top-level domains retain the responsibility for this
function.
Countries that wish to be registered as top-level domains are
required to name themselves after the two-letter country code listed
in the international standard ISO-3166. In some cases, however, the
two-letter ISO country code is identical to a state code used by the
U.S. Postal Service. Requests made by countries to use the three-
letter form of country code specified in the ISO-3166 standard will
be considered in such cases so as to prevent possible conflicts and
confusion.
Stahl [Page 3]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
HOW TO REGISTER
Obtain a domain questionnaire from the NIC hostmaster, or FTP the
file NETINFO:DOMAIN-TEMPLATE.TXT from host SRI-NIC.ARPA.
Fill out the questionnaire completely. Return it via electronic mail
to HOSTMASTER@SRI-NIC.ARPA.
The APPENDIX to this memo contains the application form for
registering a top-level or second-level domain with the NIC. It
supersedes the version of the questionnaire found in RFC-920. The
application should be submitted by the person administratively
responsible for the domain, and must be filled out completely before
the NIC will authorize establishment of a top-level or second-level
domain. The DA is responsible for keeping his domain's data current
with the NIC or with the registration agent with which his domain is
registered. For example, the CSNET and UUCP managements act as
domain filters, processing domain applications for their own
organizations. They pass pertinent information along periodically to
the NIC for incorporation into the domain database and root server
files. The online file NETINFO:ALTERNATE-DOMAIN-PROCEDURE.TXT
outlines this procedure. It is highly recommended that the DA review
this information periodically and provide any corrections or
additions. Corrections should be submitted via electronic mail.
WHICH DOMAIN NAME?
The designers of the domain-naming system initiated several general
categories of names as top-level domain names, so that each could
accommodate a variety of organizations. The current top-level
domains registered with the DDN Network Information Center are ARPA,
COM, EDU, GOV, MIL, NET, and ORG, plus a number of top-level country
domains. To join one of these, a DA needs to be aware of the purpose
for which it was intended.
"ARPA" is a temporary domain. It is by default appended to the
names of hosts that have not yet joined a domain. When the system
was begun in 1984, the names of all hosts in the Official DoD
Internet Host Table maintained by the NIC were changed by adding
of the label ".ARPA" in order to accelerate a transition to the
domain-naming system. Another reason for the blanket name changes
was to force hosts to become accustomed to using the new style
names and to modify their network software, if necessary. This
was done on a network-wide basis and was directed by DCA in DDN
Management Bulletin No. 22. Hosts that fall into this domain will
eventually move to other branches of the domain tree.
Stahl [Page 4]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
"COM" is meant to incorporate subdomains of companies and
businesses.
"EDU" was initiated to accommodate subdomains set up by
universities and other educational institutions.
"GOV" exists to act as parent domain for subdomains set up by
government agencies.
"MIL" was initiated to act as parent to subdomains that are
developed by military organizations.
"NET" was introduced as a parent domain for various network-type
organizations. Organizations that belong within this top-level
domain are generic or network-specific, such as network service
centers and consortia. "NET" also encompasses network
management-related organizations, such as information centers and
operations centers.
"ORG" exists as a parent to subdomains that do not clearly fall
within the other top-level domains. This may include technical-
support groups, professional societies, or similar organizations.
One of the guidelines in effect in the domain-naming system is that a
host should have only one name regardless of what networks it is
connected to. This implies, that, in general, domain names should
not include routing information or addresses. For example, a host
that has one network connection to the Internet and another to BITNET
should use the same name when talking to either network. For a
description of the syntax of domain names, please refer to Section 3
of RFC-1034.
VERIFICATION OF DATA
The verification process can be accomplished in several ways. One of
these is through the NIC WHOIS server. If he has access to WHOIS,
the DA can type the command "whois domain <domain name><return>".
The reply from WHOIS will supply the following: the name and address
of the organization "owning" the domain; the name of the domain; its
administrative, technical, and zone contacts; the host names and
network addresses of sites providing name service for the domain.
Stahl [Page 5]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
Example:
@whois domain rice.edu<Return>
Rice University (RICE-DOM)
Advanced Studies and Research
Houston, TX 77001
Domain Name: RICE.EDU
Administrative Contact:
Kennedy, Ken (KK28) Kennedy@LLL-CRG.ARPA (713) 527-4834
Technical Contact, Zone Contact:
Riffle, Vicky R. (VRR) rif@RICE.EDU
(713) 527-8101 ext 3844
Domain servers:
RICE.EDU 128.42.5.1
PENDRAGON.CS.PURDUE.EDU 128.10.2.5
Alternatively, the DA can send an electronic mail message to
SERVICE@SRI-NIC.ARPA. In the subject line of the message header, the
DA should type "whois domain <domain name>". The requested
information will be returned via electronic mail. This method is
convenient for sites that do not have access to the NIC WHOIS
service.
The initial application for domain authorization should be submitted
via electronic mail, if possible, to HOSTMASTER@SRI-NIC.ARPA. The
questionnaire described in the appendix may be used or a separate
application can be FTPed from host SRI-NIC.ARPA. The information
provided by the administrator will be reviewed by hostmaster
personnel for completeness. There will most likely be a few
exchanges of correspondence via electronic mail, the preferred method
of communication, prior to authorization of the domain.
HOW TO GET MORE INFORMATION
An informational table of the top-level domains and their root
servers is contained in the file NETINFO:DOMAINS.TXT online at SRI-
NIC.ARPA. This table can be obtained by FTPing the file.
Alternatively, the information can be acquired by opening a TCP or
UDP connection to the NIC Host Name Server, port 101 on SRI-NIC.ARPA,
and invoking the command "ALL-DOM".
Stahl [Page 6]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
The following online files, all available by FTP from SRI-NIC.ARPA,
contain pertinent domain information:
- NETINFO:DOMAINS.TXT, a table of all top-level domains and the
network addresses of the machines providing domain name
service for them. It is updated each time a new top-level
domain is approved.
- NETINFO:DOMAIN-INFO.TXT contains a concise list of all
top-level and second-level domain names registered with the
NIC and is updated monthly.
- NETINFO:DOMAIN-CONTACTS.TXT also contains a list of all the
top level and second-level domains, but includes the
administrative, technical and zone contacts for each as well.
- NETINFO:DOMAIN-TEMPLATE.TXT contains the questionnaire to be
completed before registering a top-level or second-level
domain.
For either general or specific information on the domain system, do
one or more of the following:
1. Send electronic mail to HOSTMASTER@SRI-NIC.ARPA
2. Call the toll-free NIC hotline at (800) 235-3155
3. Use FTP to get background RFCs and other files maintained
online at the NIC. Some pertinent RFCs are listed below in
the REFERENCES section of this memo.
Stahl [Page 7]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
REFERENCES
The references listed here provide important background information
on the domain-naming system. Path names of the online files
available via anonymous FTP from the SRI-NIC.ARPA host are noted in
brackets.
1. Defense Communications Agency DDN Defense Communications
System, DDN Management Bulletin No. 22, Domain Names
Transition, March 1984.
[ DDN-NEWS:DDN-MGT-BULLETIN-22.TXT ]
2. Defense Communications Agency DDN Defense Communications
System, DDN Management Bulletin No. 32, Phase I of the Domain
Name Implementation, January 1987.
[ DDN-NEWS:DDN-MGT-BULLETIN-32.TXT ]
3. Harrenstien, K., M. Stahl, and E. Feinler, "Hostname
Server", RFC-953, DDN Network Information Center, SRI
International, October 1985. [ RFC:RFC953.TXT ]
4. Harrenstien, K., M. Stahl, and E. Feinler, "Official DoD
Internet Host Table Specification", RFC-952, DDN Network
Information Center, SRI International, October 1985.
[ RFC:RFC952.TXT ]
5. ISO, "Codes for the Representation of Names of Countries",
ISO-3166, International Standards Organization, May 1981.
[ Not online ]
6. Lazear, W.D., "MILNET Name Domain Transition", RFC-1031,
Mitre Corporation, October 1987. [ RFC:RFC1031.TXT ]
7. Lottor, M.K., "Domain Administrators Operations Guide",
RFC-1033, DDN Network Information Center, SRI International,
July 1987. [ RFC:RFC1033.TXT ]
8. Mockapetris, P., "Domain Names - Concepts and Facilities",
RFC-1034, USC Information Sciences Institute, October 1987.
[ RFC:RFC1034.TXT ]
9. Mockapetris, P., "Domain Names - Implementation and
Specification", RFC-1035, USC Information Sciences Institute,
October 1987. [ RFC:RFC1035.TXT ]
10. Mockapetris, P., "The Domain Name System", Proceedings of the
IFIP 6.5 Working Conference on Computer Message Services,
Nottingham, England, May 1984. Also as ISI/RS-84-133, June
Stahl [Page 8]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
1984. [ Not online ]
11. Mockapetris, P., J. Postel, and P. Kirton, "Name Server
Design for Distributed Systems", Proceedings of the Seventh
International Conference on Computer Communication, October
30 to November 3 1984, Sidney, Australia. Also as
ISI/RS-84-132, June 1984. [ Not online ]
12. Partridge, C., "Mail Routing and the Domain System", RFC-974,
CSNET-CIC, BBN Laboratories, January 1986.
[ RFC:RFC974.TXT ]
13. Postel, J., "The Domain Names Plan and Schedule", RFC-881,
USC Information Sciences Institute, November 1983.
[ RFC:RFC881.TXT ]
14. Reynolds, J., and Postel, J., "Assigned Numbers", RFC-1010
USC Information Sciences Institute, May 1986.
[ RFC:RFC1010.TXT ]
15. Romano, S., and Stahl, M., "Internet Numbers", RFC-1020,
SRI, November 1987.
[ RFC:RFC1020.TXT ]
Stahl [Page 9]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
APPENDIX
The following questionnaire may be FTPed from SRI-NIC.ARPA as
NETINFO:DOMAIN-TEMPLATE.TXT.
---------------------------------------------------------------------
To establish a domain, the following information must be sent to the
NIC Domain Registrar (HOSTMASTER@SRI-NIC.ARPA):
NOTE: The key people must have electronic mailboxes and NIC
"handles," unique NIC database identifiers. If you have access to
"WHOIS", please check to see if you are registered and if so, make
sure the information is current. Include only your handle and any
changes (if any) that need to be made in your entry. If you do not
have access to "WHOIS", please provide all the information indicated
and a NIC handle will be assigned.
(1) The name of the top-level domain to join.
For example: COM
(2) The NIC handle of the administrative head of the organization.
Alternately, the person's name, title, mailing address, phone number,
organization, and network mailbox. This is the contact point for
administrative and policy questions about the domain. In the case of
a research project, this should be the principal investigator.
For example:
Administrator
Organization The NetWorthy Corporation
Name Penelope Q. Sassafrass
Title President
Mail Address The NetWorthy Corporation
4676 Andrews Way, Suite 100
Santa Clara, CA 94302-1212
Phone Number (415) 123-4567
Net Mailbox Sassafrass@ECHO.TNC.COM
NIC Handle PQS
(3) The NIC handle of the technical contact for the domain.
Alternately, the person's name, title, mailing address, phone number,
organization, and network mailbox. This is the contact point for
problems concerning the domain or zone, as well as for updating
information about the domain or zone.
Stahl [Page 10]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
For example:
Technical and Zone Contact
Organization The NetWorthy Corporation
Name Ansel A. Aardvark
Title Executive Director
Mail Address The NetWorthy Corporation
4676 Andrews Way, Suite 100
Santa Clara, CA. 94302-1212
Phone Number (415) 123-6789
Net Mailbox Aardvark@ECHO.TNC.COM
NIC Handle AAA2
(4) The name of the domain (up to 12 characters). This is the name
that will be used in tables and lists associating the domain with the
domain server addresses. [While, from a technical standpoint, domain
names can be quite long (programmers beware), shorter names are
easier for people to cope with.]
For example: TNC
(5) A description of the servers that provide the domain service for
translating names to addresses for hosts in this domain, and the date
they will be operational.
A good way to answer this question is to say "Our server is
supplied by person or company X and does whatever their standard
issue server does."
For example: Our server is a copy of the one operated by
the NIC; it will be installed and made operational on
1 November 1987.
(6) Domains must provide at least two independent servers for the
domain. Establishing the servers in physically separate locations
and on different PSNs is strongly recommended. A description of the
server machine and its backup, including
Stahl [Page 11]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
(a) Hardware and software (using keywords from the Assigned
Numbers RFC).
(b) Host domain name and network addresses (which host on which
network for each connected network).
(c) Any domain-style nicknames (please limit your domain-style
nickname request to one)
For example:
- Hardware and software
VAX-11/750 and UNIX, or
IBM-PC and MS-DOS, or
DEC-1090 and TOPS-20
- Host domain names and network addresses
BAR.FOO.COM 10.9.0.193 on ARPANET
- Domain-style nickname
BR.FOO.COM (same as BAR.FOO.COM 10.9.0.13 on ARPANET)
(7) Planned mapping of names of any other network hosts, other than
the server machines, into the new domain's naming space.
For example:
BAR-FOO2.ARPA (10.8.0.193) -> FOO2.BAR.COM
BAR-FOO3.ARPA (10.7.0.193) -> FOO3.BAR.COM
BAR-FOO4.ARPA (10.6.0.193) -> FOO4.BAR.COM
(8) An estimate of the number of hosts that will be in the domain.
(a) Initially
(b) Within one year
(c) Two years
(d) Five years.
For example:
(a) Initially = 50
(b) One year = 100
(c) Two years = 200
(d) Five years = 500
Stahl [Page 12]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
(9) The date you expect the fully qualified domain name to become
the official host name in HOSTS.TXT.
Please note: If changing to a fully qualified domain name (e.g.,
FOO.BAR.COM) causes a change in the official host name of an
ARPANET or MILNET host, DCA approval must be obtained beforehand.
Allow 10 working days for your requested changes to be processed.
ARPANET sites should contact ARPANETMGR@DDN1.ARPA. MILNET sites
should contact HOSTMASTER@SRI-NIC.ARPA, 800-235-3155, for
further instructions.
(10) Please describe your organization briefly.
For example: The NetWorthy Corporation is a consulting
organization of people working with UNIX and the C language in an
electronic networking environment. It sponsors two technical
conferences annually and distributes a bimonthly newsletter.
---------------------------------------------------------------------
This example of a completed application corresponds to the examples
found in the companion document RFC-1033, "Domain Administrators
Operations Guide."
(1) The name of the top-level domain to join.
COM
(2) The NIC handle of the administrative contact person.
NIC Handle JAKE
(3) The NIC handle of the domain's technical and zone
contact person.
NIC Handle DLE6
(4) The name of the domain.
SRI
(5) A description of the servers.
Our server is the TOPS20 server JEEVES supplied by ISI; it
will be installed and made operational on 1 July 1987.
Stahl [Page 13]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
(6) A description of the server machine and its backup:
(a) Hardware and software
DEC-1090T and TOPS20
DEC-2065 and TOPS20
(b) Host domain name and network address
KL.SRI.COM 10.1.0.2 on ARPANET, 128.18.10.6 on SRINET
STRIPE.SRI.COM 10.4.0.2 on ARPANET, 128.18.10.4 on SRINET
(c) Domain-style nickname
None
(7) Planned mapping of names of any other network hosts, other than
the server machines, into the new domain's naming space.
SRI-Blackjack.ARPA (128.18.2.1) -> Blackjack.SRI.COM
SRI-CSL.ARPA (192.12.33.2) -> CSL.SRI.COM
(8) An estimate of the number of hosts that will be directly within
this domain.
(a) Initially = 50
(b) One year = 100
(c) Two years = 200
(d) Five years = 500
(9) A date when you expect the fully qualified domain name to become
the official host name in HOSTS.TXT.
31 September 1987
(10) Brief description of organization.
SRI International is an independent, nonprofit, scientific
research organization. It performs basic and applied research
for government and commercial clients, and contributes to
worldwide economic, scientific, industrial, and social progress
through research and related services.
Stahl [Page 14]

1229
usr.sbin/named/doc/rfc1033.lpr
View File

File diff suppressed because it is too large Load Diff

3077
usr.sbin/named/doc/rfc1034.lpr
View File

File diff suppressed because it is too large Load Diff

3077
usr.sbin/named/doc/rfc1035.lpr
View File

File diff suppressed because it is too large Load Diff

787
usr.sbin/named/doc/rfc1101.lpr
View File

@ -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]

798
usr.sbin/named/doc/rfc920.lpr
View File

@ -1,798 +0,0 @@
Network Working Group J. Postel
Request for Comments: 920 J. Reynolds
ISI
October 1984
Domain Requirements
Status of this Memo
This memo is a policy statement on the requirements of establishing a
new domain in the ARPA-Internet and the DARPA research community.
This is an official policy statement of the IAB and the DARPA.
Distribution of this memo is unlimited.
Introduction
This memo restates and refines the requirements on establishing a
Domain first described in RFC-881 [1]. It adds considerable detail
to that discussion, and introduces the limited set of top level
domains.
The Purpose of Domains
Domains are administrative entities. The purpose and expected use of
domains is to divide the name management required of a central
administration and assign it to sub-administrations. There are no
geographical, topological, or technological constraints on a domain.
The hosts in a domain need not have common hardware or software, nor
even common protocols. Most of the requirements and limitations on
domains are designed to ensure responsible administration.
The domain system is a tree-structured global name space that has a
few top level domains. The top level domains are subdivided into
second level domains. The second level domains may be subdivided
into third level domains, and so on.
The administration of a domain requires controlling the assignment of
names within that domain and providing access to the names and name
related information (such as addresses) to users both inside and
outside the domain.
Postel & Reynolds [Page 1]
RFC 920 October 1984
Domain Requirements
General Purpose Domains
While the initial domain name "ARPA" arises from the history of the
development of this system and environment, in the future most of the
top level names will be very general categories like "government",
"education", or "commercial". The motivation is to provide an
organization name that is free of undesirable semantics.
After a short period of initial experimentation, all current
ARPA-Internet hosts will select some domain other than ARPA for their
future use. The use of ARPA as a top level domain will eventually
cease.
Initial Set of Top Level Domains
The initial top level domain names are:
Temporary
ARPA = The current ARPA-Internet hosts.
Categories
GOV = Government, any government related domains meeting the
second level requirements.
EDU = Education, any education related domains meeting the
second level requirements.
COM = Commercial, any commercial related domains meeting the
second level requirements.
MIL = Military, any military related domains meeting the
second level requirements.
ORG = Organization, any other domains meeting the second
level requirements.
Countries
The English two letter code (alpha-2) identifying a country
according the the ISO Standard for "Codes for the
Representation of Names of Countries" [5].
Postel & Reynolds [Page 2]
RFC 920 October 1984
Domain Requirements
Multiorganizations
A multiorganization may be a top level domain if it is large,
and is composed of other organizations; particularly if the
multiorganization can not be easily classified into one of the
categories and is international in scope.
Possible Examples of Domains
The following examples are fictions of the authors' creation, any
similarity to the real world is coincidental.
The UC Domain
It might be that a large state wide university with, say, nine
campuses and several laboratories may want to form a domain. Each
campus or major off-campus laboratory might then be a subdomain,
and within each subdomain, each department could be further
distinguished. This university might be a second level domain in
the education category.
One might see domain style names for hosts in this domain like
these:
LOCUS.CS.LA.UC.EDU
CCN.OAC.LA.UC.EDU
ERNIE.CS.CAL.UC.EDU
A.S1.LLNL.UC.EDU
A.LAND.LANL.UC.EDU
NMM.LBL.CAL.UC.EDU
The MIT Domain
Another large university may have many hosts using a variety of
machine types, some even using several families of protocols.
However, the administrators at this university may see no need for
the outside world to be aware of these internal differences. This
university might be a second level domain in the education
category.
One might see domain style names for hosts in this domain like
these:
APIARY-1.MIT.EDU
BABY-BLUE.MIT.EDU
CEZANNE.MIT.EDU
DASH.MIT.EDU
Postel & Reynolds [Page 3]
RFC 920 October 1984
Domain Requirements
MULTICS.MIT.EDU
TAC.MIT.EDU
XX.MIT.EDU
The CSNET Domain
There may be a consortium of universities and industry research
laboratories called, say, "CSNET". This CSNET is not a network
per se, but rather a computer mail exchange using a variety of
protocols and network systems. Therefore, CSNET is not a network
in the sense of the ARPANET, or an Ethernet, or even the
ARPA-Internet, but rather a community. Yet it does, in fact, have
the key property needed to form a domain; it has a responsible
administration. This consortium might be large enough and might
have membership that cuts across the categories in such a way that
it qualifies under the "multiorganization rule" to be a top level
domain.
One might see domain style names for hosts in this domain like
these:
CIC.CSNET
EMORY.CSNET
GATECH.CSNET
HP-LABS.CSNET
SJ.IBM.CSNET
UDEL.CSNET
UWISC.CSNET
General Requirements on a Domain
There are several requirements that must be met to establish a
domain. In general, it must be responsibly managed. There must be a
responsible person to serve as an authoritative coordinator for
domain related questions. There must be a robust domain name lookup
service, it must be of at least a minimum size, and the domain must
be registered with the central domain administrator (the Network
Information Center (NIC) Domain Registrar).
Responsible Person:
An individual must be identified who has authority for the
administration of the names within the domain, and who seriously
takes on the responsibility for the behavior of the hosts in the
domain, plus their interactions with hosts outside the domain.
This person must have some technical expertise and the authority
within the domain to see that problems are fixed.
Postel & Reynolds [Page 4]
RFC 920 October 1984
Domain Requirements
If a host in a given domain somehow misbehaves in its interactions
with hosts outside the domain (e.g., consistently violates
protocols), the responsible person for the domain must be
competent and available to receive reports of problems, take
action on the reported problems, and follow through to eliminate
the problems.
Domain Servers:
A robust and reliable domain server must be provided. One way of
meeting this requirement is to provide at least two independent
domain servers for the domain. The database can, of course, be
the same. The database can be prepared and copied to each domain
server. But, the servers should be in separate machines on
independent power supplies, et cetera; basically as physically
independent as can be. They should have no common point of
failure.
Some domains may find that providing a robust domain service can
most easily be done by cooperating with another domain where each
domain provides an additional server for the other.
In other situations, it may be desirable for a domain to arrange
for domain service to be provided by a third party, perhaps on
hosts located outside the domain.
One of the difficult problems in operating a domain server is the
acquisition and maintenance of the data. In this case, the data
are the host names and addresses. In some environments this
information changes fairly rapidly and keeping up-to-date data may
be difficult. This is one motivation for sub-domains. One may
wish to create sub-domains until the rate of change of the data in
a sub-domain domain server database is easily managed.
In the technical language of the domain server implementation the
data is divided into zones. Domains and zones are not necessarily
one-to-one. It may be reasonable for two or more domains to
combine their data in a single zone.
The responsible person or an identified technical assistant must
understand in detail the procedures for operating a domain server,
including the management of master files and zones.
The operation of a domain server should not be taken on lightly.
There are some difficult problems in providing an adequate
service, primarily the problems in keeping the database up to
date, and keeping the service operating.
Postel & Reynolds [Page 5]
RFC 920 October 1984
Domain Requirements
The concepts and implementation details of the domain server are
given in RFC-882 [2] and RFC-883 [3].
Minimum Size:
The domain must be of at least a minimum size. There is no
requirement to form a domain because some set of hosts is above
the minimum size.
Top level domains must be specially authorized. In general, they
will only be authorized for domains expected to have over 500
hosts.
The general guideline for a second level domain is that it have
over 50 hosts. This is a very soft "requirement". It makes sense
that any major organization, such as a university or corporation,
be allowed as a second level domain -- even if it has just a few
hosts.
Registration:
Top level domains must be specially authorized and registered with
the NIC domain registrar.
The administrator of a level N domain must register with the
registrar (or responsible person) of the level N-1 domain. This
upper level authority must be satisfied that the requirements are
met before authorization for the domain is granted.
The registration procedure involves answering specific questions
about the prospective domain. A prototype of what the NIC Domain
Registrar may ask for the registration of a second level domain is
shown below. These questions may change from time to time. It is
the responsibility of domain administrators to keep this
information current.
The administrator of a domain is required to make sure that host
and sub-domain names within that jurisdiction conform to the
standard name conventions and are unique within that domain.
If sub-domains are set up, the administrator may wish to pass
along some of his authority and responsibility to a sub-domain
administrator. Even if sub-domains are established, the
responsible person for the top-level domain is ultimately
responsible for the whole tree of sub-domains and hosts.
This does not mean that a domain administrator has to know the
Postel & Reynolds [Page 6]
RFC 920 October 1984
Domain Requirements
details of all the sub-domains and hosts to the Nth degree, but
simply that if a problem occurs he can get it fixed by calling on
the administrator of the sub-domain containing the problem.
Top Level Domain Requirements
There are very few top level domains, each of these may have many
second level domains.
An initial set of top level names has been identified. Each of these
has an administrator and an agent.
The top level domains:
ARPA = The ARPA-Internet *** TEMPORARY ***
Administrator: DARPA
Agent: The Network Information Center
Mailbox: HOSTMASTER@SRI-NIC.ARPA
GOV = Government
Administrator: DARPA
Agent: The Network Information Center
Mailbox: HOSTMASTER@SRI-NIC.ARPA
EDU = Education
Administrator: DARPA
Agent: The Network Information Center
Mailbox: HOSTMASTER@SRI-NIC.ARPA
COM = Commercial
Administrator: DARPA
Agent: The Network Information Center
Mailbox: HOSTMASTER@SRI-NIC.ARPA
MIL = Military
Administrator: DDN-PMO
Agent: The Network Information Center
Mailbox: HOSTMASTER@SRI-NIC.ARPA
Postel & Reynolds [Page 7]
RFC 920 October 1984
Domain Requirements
ORG = Organization
Administrator: DARPA
Agent: The Network Information Center
Mailbox: HOSTMASTER@SRI-NIC.ARPA
Countries
The English two letter code (alpha-2) identifying a country
according the the ISO Standard for "Codes for the
Representation of Names of Countries" [5].
As yet no country domains have been established. As they are
established information about the administrators and agents
will be made public, and will be listed in subsequent editions
of this memo.
Multiorganizations
A multiorganization may be a top level domain if it is large,
and is composed of other organizations; particularly if the
multiorganization can not be easily classified into one of the
categories and is international in scope.
As yet no multiorganization domains have been established. As
they are established information about the administrators and
agents will be made public, and will be listed in subsequent
editions of this memo.
Note: The NIC is listed as the agent and registrar for all the
currently allowed top level domains. If there are other entities
that would be more appropriate agents and registrars for some or
all of these domains then it would be desirable to reassign the
responsibility.
Second Level Domain Requirements
Each top level domain may have many second level domains. Every
second level domain must meet the general requirements on a domain
specified above, and be registered with a top level domain
administrator.
Postel & Reynolds [Page 8]
RFC 920 October 1984
Domain Requirements
Third through Nth Level Domain Requirements
Each second level domain may have many third level domains, etc.
Every third level domain (through Nth level domain) must meet the
requirements set by the administrator of the immediately higher level
domain. Note that these may be more or less strict than the general
requirements. One would expect the minimum size requirements to
decrease at each level.
The ARPA Domain
At the time the implementation of the domain concept was begun it was
thought that the set of hosts under the administrative authority of
DARPA would make up a domain. Thus the initial domain selected was
called ARPA. Now it is seen that there is no strong motivation for
there to be a top level ARPA domain. The plan is for the current
ARPA domain to go out of business as soon as possible. Hosts that
are currently members of the ARPA domain should make arrangements to
join another domain. It is likely that for experimental purposes
there will be a second level domain called ARPA in the ORG domain
(i.e., there will probably be an ARPA.ORG domain).
The DDN Hosts
DDN hosts that do not desire to participate in this domain naming
system will continue to use the HOSTS.TXT data file maintained by the
NIC for name to address translations. This file will be kept up to
date for the DDN hosts. However, all DDN hosts will change their
names from "host.ARPA" to (for example) "host.DDN.MIL" some time in
the future. The schedule for changes required in DDN hosts will be
established by the DDN-PMO.
Impact on Hosts
What is a host administrator to do about all this?
For existing hosts already operating in the ARPA-Internet, the
best advice is to sit tight for now. Take a few months to
consider the options, then select a domain to join. Plan
carefully for the impact that changing your host name will have on
both your local users and on their remote correspondents.
For a new host, careful thought should be given (as discussed
below). Some guidance can be obtained by comparing notes on what
other hosts with similar administrative properties have done.
The owner of a host may decide which domain to join, and the
Postel & Reynolds [Page 9]
RFC 920 October 1984
Domain Requirements
administrator of a domain may decide which hosts to accept into his
domain. Thus the owner of a host and a domain administrator must
come to an understanding about the host being in the domain. This is
the foundation of responsible administration.
For example, a host "XYZ" at MIT might possible be considered as a
candidate for becoming any of XYZ.ARPA.ORG, XYZ.CSNET, or
XYZ.MIT.EDU.
The owner of host XYZ may choose which domain to join,
depending on which domain administrators are willing to have
him.
The domain is part of the host name. Thus if USC-ISIA.ARPA changes
its domain affiliation to DDN.MIL to become USC-ISIA.DDN.MIL, it has
changed its name. This means that any previous references to
USC-ISIA.ARPA are now out of date. Such old references may include
private host name to address tables, and any recorded information
about mailboxes such as mailing lists, the headers of old messages,
printed directories, and peoples' memories.
The experience of the DARPA community suggests that changing the name
of a host is somewhat painful. It is recommended that careful
thought be given to choosing a new name for a host - which includes
selecting its place in the domain hierarchy.
The Roles of the Network Information Center
The NIC plays two types of roles in the administration of domains.
First, the NIC is the registrar of all top level domains. Second
the NIC is the administrator of several top level domains (and the
registrar for second level domains in these).
Top Level Domain Registrar
As the registrar for top level domains, the NIC is the contact
point for investigating the possibility of establishing a new top
level domain.
Top Level Domain Administrator
For the top level domains designated so far, the NIC is the
administrator of each of these domains. This means the NIC is
responsible for the management of these domains and the
registration of the second level domains or hosts (if at the
second level) in these domains.
Postel & Reynolds [Page 10]
RFC 920 October 1984
Domain Requirements
It may be reasonable for the administration of some of these
domains to be taken on by other authorities in the future. It is
certainly not desired that the NIC be the administrator of all top
level domains forever.
Prototypical Questions
To establish a domain, the following information must be provided to
the NIC Domain Registrar (HOSTMASTER@SRI-NIC.ARPA):
Note: The key people must have computer mail mailboxes and
NIC-Idents. If they do not at present, please remedy the
situation at once. A NIC-Ident may be established by contacting
NIC@SRI-NIC.ARPA.
1) The name of the top level domain to join.
For example: EDU
2) The name, title, mailing address, phone number, and organization
of the administrative head of the organization. This is the contact
point for administrative and policy questions about the domain. In
the case of a research project, this should be the Principal
Investigator. The online mailbox and NIC-Ident of this person should
also be included.
For example:
Administrator
Organization USC/Information Sciences Institute
Name Keith Uncapher
Title Executive Director
Mail Address USC/ISI
4676 Admiralty Way, Suite 1001
Marina del Rey, CA. 90292-6695
Phone Number 213-822-1511
Net Mailbox Uncapher@USC-ISIB.ARPA
NIC-Ident KU
3) The name, title, mailing address, phone number, and organization
of the domain technical contact. The online mailbox and NIC-Ident of
the domain technical contact should also be included. This is the
contact point for problems with the domain and for updating
information about the domain. Also, the domain technical contact may
be responsible for hosts in this domain.
Postel & Reynolds [Page 11]
RFC 920 October 1984
Domain Requirements
For example:
Technical Contact
Organization USC/Information Sciences Institute
Name Craig Milo Rogers
Title Researcher
Mail Address USC/ISI
4676 Admiralty Way, Suite 1001
Marina del Rey, CA. 90292-6695
Phone Number 213-822-1511
Net Mailbox Rogers@USC-ISIB.ARPA
NIC-Ident CMR
4) The name, title, mailing address, phone number, and organization
of the zone technical contact. The online mailbox and NIC-Ident of
the zone technical contact should also be included. This is the
contact point for problems with the zone and for updating information
about the zone. In many cases the zone technical contact and the
domain technical contact will be the same person.
For example:
Technical Contact
Organization USC/Information Sciences Institute
Name Craig Milo Rogers
Title Researcher
Mail Address USC/ISI
4676 Admiralty Way, Suite 1001
Marina del Rey, CA. 90292-6695
Phone Number 213-822-1511
Net Mailbox Rogers@USC-ISIB.ARPA
NIC-Ident CMR
5) The name of the domain (up to 12 characters). This is the name
that will be used in tables and lists associating the domain and the
domain server addresses. [While technically domain names can be
quite long (programmers beware), shorter names are easier for people
to cope with.]
For example: ALPHA-BETA
6) A description of the servers that provides the domain service for
translating name to address for hosts in this domain, and the date
they will be operational.
Postel & Reynolds [Page 12]
RFC 920 October 1984
Domain Requirements
A good way to answer this question is to say "Our server is
supplied by person or company X and does whatever their standard
issue server does".
For example: Our server is a copy of the server operated by
the NIC, and will be installed and made operational on
1-November-84.
7) A description of the server machines, including:
(a) hardware and software (using keywords from the Assigned
Numbers)
(b) addresses (what host on what net for each connected net)
For example:
(a) hardware and software
VAX-11/750 and UNIX, or
IBM-PC and MS-DOS, or
DEC-1090 and TOPS-20
(b) address
10.9.0.193 on ARPANET
8) An estimate of the number of hosts that will be in the domain.
(a) initially,
(b) within one year,
(c) two years, and
(d) five years.
For example:
(a) initially = 50
(b) one year = 100
(c) two years = 200
(d) five years = 500
Postel & Reynolds [Page 13]
RFC 920 October 1984
Domain Requirements
Acknowledgment
We would like to thank the many people who contributed to this memo,
including the participants in the Namedroppers Group, the ICCB, the
PCCB, and especially the staff of the Network Information Center,
particularly J. Feinler and K. Harrenstien.
References
[1] Postel, J., "The Domain Names Plan and Schedule", RFC-881, USC
Information Sciences Institute, November 1983.
[2] Mockapetris, P., "Domain Names - Concepts and Facilities",
RFC-882, USC Information Sciences Institute, November 1983.
[3] Mockapetris, P., "Domain Names - Implementation and
Specification", RFC-883, USC Information Sciences Institute,
November 1983.
[4] Postel, J., "Domain Name System Implementation Schedule",
RFC-897, USC Information Sciences Institute, February 1984.
[5] ISO, "Codes for the Representation of Names of Countries",
ISO-3166, International Standards Organization, May 1981.
[6] Postel, J., "Domain Name System Implementation Schedule -
Revised", RFC-921, USC Information Sciences Institute, October
1984.
[7] Mockapetris, P., "The Domain Name System", Proceedings of the
IFIP 6.5 Working Conference on Computer Message Services,
Nottingham, England, May 1984. Also as ISI/RS-84-133,
June 1984.
[8] Mockapetris, P., J. Postel, and P. Kirton, "Name Server Design
for Distributed Systems", Proceedings of the Seventh
International Conference on Computer Communication, October 30
to November 3 1984, Sidney, Australia. Also as ISI/RS-84-132,
June 1984.
Postel & Reynolds [Page 14]

399
usr.sbin/named/doc/rfc974.lpr
View File

@ -1,399 +0,0 @@
Network Working Group Craig Partridge
Request for Comments: 974 CSNET CIC BBN Laboratories Inc
January 1986
MAIL ROUTING AND THE DOMAIN SYSTEM
Status of this Memo
This RFC presents a description of how mail systems on the Internet
are expected to route messages based on information from the domain
system described in RFCs 882, 883 and 973. Distribution of this memo
is unlimited.
Introduction
The purpose of this memo is to explain how mailers are to decide how
to route a message addressed to a given Internet domain name. This
involves a discussion of how mailers interpret MX RRs, which are used
for message routing. Note that this memo makes no statement about
how mailers are to deal with MB and MG RRs, which are used for
interpreting mailbox names.
Under RFC-882 and RFC-883 certain assumptions about mail addresses
have been changed. Up to now, one could usually assume that if a
message was addressed to a mailbox, for example, at LOKI.BBN.COM,
that one could just open an SMTP connection to LOKI.BBN.COM and pass
the message along. This system broke down in certain situations,
such as for certain UUCP and CSNET hosts which were not directly
attached to the Internet, but these hosts could be handled as special
cases in configuration files (for example, most mailers were set up
to automatically forward mail addressed to a CSNET host to
CSNET-RELAY.ARPA).
Under domains, one cannot simply open a connection to LOKI.BBN.COM,
but must instead ask the domain system where messages to LOKI.BBN.COM
are to be delivered. And the domain system may direct a mailer to
deliver messages to an entirely different host, such as SH.CS.NET.
Or, in a more complicated case, the mailer may learn that it has a
choice of routes to LOKI.BBN.COM. This memo is essentially a set of
guidelines on how mailers should behave in this more complex world.
Readers are expected to be familiar with RFCs 882, 883, and the
updates to them (e.g., RFC-973).
Partridge [Page 1]
RFC 974 January 1986
Mail Routing and the Domain System
What the Domain Servers Know
The domain servers store information as a series of resource records
(RRs), each of which contains a particular piece of information about
a given domain name (which is usually, but not always, a host). The
simplest way to think of a RR is as a typed pair of datum, a domain
name matched with relevant data, and stored with some additional type
information to help systems determine when the RR is relevant. For
the purposes of message routing, the system stores RRs known as MX
RRs. Each MX matches a domain name with two pieces of data, a
preference value (an unsigned 16-bit integer), and the name of a
host. The preference number is used to indicate in what order the
mailer should attempt deliver to the MX hosts, with the lowest
numbered MX being the one to try first. Multiple MXs with the same
preference are permitted and have the same priority.
In addition to mail information, the servers store certain other
types of RR's which mailers may encounter or choose to use. These
are: the canonical name (CNAME) RR, which simply states that the
domain name queried for is actually an alias for another domain name,
which is the proper, or canonical, name; and the Well Known Service
(WKS) RR, which stores information about network services (such as
SMTP) a given domain name supports.
General Routing Guidelines
Before delving into a detailed discussion of how mailers are expected
to do mail routing, it would seem to make sense to give a brief
overview of how this memo is approaching the problems that routing
poses.
The first major principle is derived from the definition of the
preference field in MX records, and is intended to prevent mail
looping. If the mailer is on a host which is listed as an MX for the
destination host, the mailer may only deliver to an MX which has a
lower preference count than its own host.
It is also possible to cause mail looping because routing information
is out of date or incomplete. Out of date information is only a
problem when domain tables are changed. The changes will not be
known to all affected hosts until their resolver caches time out.
There is no way to ensure that this will not happen short of
requiring mailers and their resolvers to always send their queries to
an authoritative server, and never use data stored in a cache. This
is an impractical solution, since eliminating resolver caching would
make mailing inordinately expensive. What is more, the out-of-date
RR problem should not happen if, when a domain table is changed,
Partridge [Page 2]
RFC 974 January 1986
Mail Routing and the Domain System
affected hosts (those in the list of MXs) have their resolver caches
flushed. In other words, given proper precautions, mail looping as a
result of domain information should be avoidable, without requiring
mailers to query authoritative servers. (The appropriate precaution
is to check with a host's administrator before adding that host to a
list of MXs).
The incomplete data problem also requires some care when handling
domain queries. If the answer section of a query is incomplete
critical MX RRs may be left out. This may result in mail looping, or
in a message being mistakenly labelled undeliverable. As a result,
mailers may only accept responses from the domain system which have
complete answer sections. Note that this entire problem can be
avoided by only using virtual circuits for queries, but since this
situation is likely to be very rare and datagrams are the preferred
way to interact with the domain system, implementors should probably
just ensure that their mailer will repeat a query with virtual
circuits should the truncation bit ever be set.
Determining Where to Send a Message
The explanation of how mailers should decide how to route a message
is discussed in terms of the problem of a mailer on a host with
domain name LOCAL trying to deliver a message addressed to the domain
name REMOTE. Both LOCAL and REMOTE are assumed to be syntactically
correct domain names. Furthermore, LOCAL is assumed to be the
official name for the host on which the mailer resides (i.e., it is
not a alias).
Issuing a Query
The first step for the mailer at LOCAL is to issue a query for MX RRs
for REMOTE. It is strongly urged that this step be taken every time
a mailer attempts to send the message. The hope is that changes in
the domain database will rapidly be used by mailers, and thus domain
administrators will be able to re-route in-transit messages for
defective hosts by simply changing their domain databases.
Certain responses to the query are considered errors:
Getting no response to the query. The domain server the mailer
queried never sends anything back. (This is distinct from an
answer which contains no answers to the query, which is not an
error).
Getting a response in which the truncation field of the header is
Partridge [Page 3]
RFC 974 January 1986
Mail Routing and the Domain System
set. (Recall discussion of incomplete queries above). Mailers
may not use responses of this type, and should repeat the query
using virtual circuits instead of datagrams.
Getting a response in which the response code is non-zero.
Mailers are expected to do something reasonable in the face of an
error. The behaviour for each type of error is not specified here,
but implementors should note that different types of errors should
probably be treated differently. For example, a response code of
"non-existent domain" should probably cause the message to be
returned to the sender as invalid, while a response code of "server
failure" should probably cause the message to be retried later.
There is one other special case. If the response contains an answer
which is a CNAME RR, it indicates that REMOTE is actually an alias
for some other domain name. The query should be repeated with the
canonical domain name.
If the response does not contain an error response, and does not
contain aliases, its answer section should be a (possibly zero
length) list of MX RRs for domain name REMOTE (or REMOTE's true
domain name if REMOTE was a alias). The next section describes how
this list is interpreted.
Interpreting the List of MX RRs
NOTE: This section only discusses how mailers choose which names to
try to deliver a message to, working from a list of RR's. It does
not discuss how the mailers actually make delivery. Where ever
delivering a message is mentioned, all that is meant is that the
mailer should do whatever it needs to do to transfer a message to a
remote site, given a domain name for that site. (For example, an
SMTP mailer will try to get an address for the domain name, which
involves another query to the domain system, and then, if it gets an
address, connect to the SMTP TCP port). The mechanics of actually
transferring the message over the network to the address associated
with a given domain name is not within the scope of this memo.
It is possible that the list of MXs in the response to the query will
be empty. This is a special case. If the list is empty, mailers
should treat it as if it contained one RR, an MX RR with a preference
value of 0, and a host name of REMOTE. (I.e., REMOTE is its only
MX). In addition, the mailer should do no further processing on the
list, but should attempt to deliver the message to REMOTE. The idea
Partridge [Page 4]
RFC 974 January 1986
Mail Routing and the Domain System
here is that if a domain fails to advertise any information about a
particular name we will give it the benefit of the doubt and attempt
delivery.
If the list is not empty, the mailer should remove irrelevant RR's
from the list according to the following steps. Note that the order
is significant.
For each MX, a WKS query should be issued to see if the domain
name listed actually supports the mail service desired. MX RRs
which list domain names which do not support the service should be
discarded. This step is optional, but strongly encouraged.
If the domain name LOCAL is listed as an MX RR, all MX RRs with a
preference value greater than or equal to that of LOCAL's must be
discarded.
After removing irrelevant RRs, the list can again be empty. This is
now an error condition and can occur in several ways. The simplest
case is that the WKS queries have discovered that none of the hosts
listed supports the mail service desired. The message is thus deemed
undeliverable, though extremely persistent mail systems might want to
try a delivery to REMOTE's address (if it exists) before returning
the message. Another, more dangerous, possibility is that the domain
system believes that LOCAL is handling message for REMOTE, but the
mailer on LOCAL is not set up to handle mail for REMOTE. For
example, if the domain system lists LOCAL as the only MX for REMOTE,
LOCAL will delete all the entries in the list. But LOCAL is
presumably querying the domain system because it didn't know what to
do with a message addressed to REMOTE. Clearly something is wrong.
How a mailer chooses to handle these situations is to some extent
implementation dependent, and is thus left to the implementor's
discretion.
If the list of MX RRs is not empty, the mailer should try to deliver
the message to the MXs in order (lowest preference value tried
first). The mailer is required to attempt delivery to the lowest
valued MX. Implementors are encouraged to write mailers so that they
try the MXs in order until one of the MXs accepts the message, or all
the MXs have been tried. A somewhat less demanding system, in which
a fixed number of MXs is tried, is also reasonable. Note that
multiple MXs may have the same preference value. In this case, all
MXs at with a given value must be tried before any of a higher value
are tried. In addition, in the special case in which there are
several MXs with the lowest preference value, all of them should be
tried before a message is deemed undeliverable.
Partridge [Page 5]
RFC 974 January 1986
Mail Routing and the Domain System
Minor Special Issues
There are a couple of special issues left out of the preceding
section because they complicated the discussion. They are treated
here in no particular order.
Wildcard names, those containing the character '*' in them, may be
used for mail routing. There are likely to be servers on the network
which simply state that any mail to a domain is to be routed through
a relay. For example, at the time that this RFC is being written, all
mail to hosts in the domain IL is routed through RELAY.CS.NET. This
is done by creating a wildcard RR, which states that *.IL has an MX
of RELAY.CS.NET. This should be transparent to the mailer since the
domain servers will hide this wildcard match. (If it matches *.IL
with HUJI.IL for example, a domain server will return an RR
containing HUJI.IL, not *.IL). If by some accident a mailer receives
an RR with a wildcard domain name in its name or data section it
should discard the RR.
Note that the algorithm to delete irrelevant RRs breaks if LOCAL has
a alias and the alias is listed in the MX records for REMOTE. (E.g.
REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This
can be avoided if aliases are never used in the data section of MX
RRs.
Implementors should understand that the query and interpretation of
the query is only performed for REMOTE. It is not repeated for the
MX RRs listed for REMOTE. You cannot try to support more extravagant
mail routing by building a chain of MXs. (E.g. UNIX.BBN.COM is an MX
for RELAY.CS.NET and RELAY.CS.NET is an MX for all the hosts in .IL,
but this does not mean that UNIX.BBN.COM accepts any responsibility
for mail for .IL).
Finally, it should be noted that this is a standard for routing on
the Internet. Mailers serving hosts which lie on multiple networks
will presumably have to make some decisions about which network to
route through. This decision making is outside the scope of this
memo, although mailers may well use the domain system to help them
decide. However, once a mailer decides to deliver a message via the
Internet it must apply these rules to route the message.
Partridge [Page 6]
RFC 974 January 1986
Mail Routing and the Domain System
Examples
To illustrate the discussion above, here are three examples of how
mailers should route messages. All examples work with the following
database:
A.EXAMPLE.ORG IN MX 10 A.EXAMPLE.ORG
A.EXAMPLE.ORG IN MX 15 B.EXAMPLE.ORG
A.EXAMPLE.ORG IN MX 20 C.EXAMPLE.ORG
A.EXAMPLE.ORG IN WKS 10.0.0.1 TCP SMTP
B.EXAMPLE.ORG IN MX 0 B.EXAMPLE.ORG
B.EXAMPLE.ORG IN MX 10 C.EXAMPLE.ORG
B.EXAMPLE.ORG IN WKS 10.0.0.2 TCP SMTP
C.EXAMPLE.ORG IN MX 0 C.EXAMPLE.ORG
C.EXAMPLE.ORG IN WKS 10.0.0.3 TCP SMTP
D.EXAMPLE.ORG IN MX 0 D.EXAMPLE.ORG
D.EXAMPLE.ORG IN MX 0 C.EXAMPLE.ORG
D.EXAMPLE.ORG IN WKS 10.0.0.4 TCP SMTP
In the first example, an SMTP mailer on D.EXAMPLE.ORG is trying to
deliver a message addressed to A.EXAMPLE.ORG. From the answer to its
query, it learns that A.EXAMPLE.ORG has three MX RRs. D.EXAMPLE.ORG
is not one of the MX RRs and all three MXs support SMTP mail
(determined from the WKS entries), so none of the MXs are eliminated.
The mailer is obliged to try to deliver to A.EXAMPLE.ORG as the
lowest valued MX. If it cannot reach A.EXAMPLE.ORG it can (but is
not required to) try B.EXAMPLE.ORG. and if B.EXAMPLE.ORG is not
responding, it can try C.EXAMPLE.ORG.
In the second example, the mailer is on B.EXAMPLE.ORG, and is again
trying to deliver a message addressed to A.EXAMPLE.ORG. There are
once again three MX RRs for A.EXAMPLE.ORG, but in this case the
mailer must discard the RRs for itself and C.EXAMPLE.ORG (because the
MX RR for C.EXAMPLE.ORG has a higher preference value than the RR for
B.EXAMPLE.ORG). It is left only with the RR for A.EXAMPLE.ORG, and
can only try delivery to A.EXAMPLE.ORG.
In the third example, consider a mailer on A.EXAMPLE.ORG trying to
deliver a message to D.EXAMPLE.ORG. In this case there are only two
MX RRs, both with the same preference value. Either MX will accept
messages for D.EXAMPLE.ORG. The mailer should try one MX first (which
one is up to the mailer, though D.EXAMPLE.ORG seems most reasonable),
and if that delivery fails should try the other MX (e.g.
C.EXAMPLE.ORG).
Partridge [Page 7]