rfc882.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,379 行 · 第 1/5 页
TXT
1,379 行
|<owner> | MD/MF | <class>| <domain name> |
+--------+--------+--------+----------------------------+
The <domain name> field is a domain name of the host that will
handle mail; note that this domain name may be completely
different from the domain name which names the resource record.
For example, F.ISI.ARPA might have two records of the form:
+----------+--------+--------+----------------------------+
|F.ISI.ARPA| MD | IN | F.ISI.ARPA |
+----------+--------+--------+----------------------------+
and
+----------+--------+--------+----------------------------+
|F.ISI.ARPA| MF | IN | B.ISI.ARPA |
+----------+--------+--------+----------------------------+
These records mean that mail for F.ISI.ARPA can either be
delivered to the host F.ISI.ARPA or forwarded to B.ISI.ARPA, which
will accept responsibility for its eventual delivery. In
principle, an additional name lookup is required to map the domain
name of the host to the appropriate address, in practice this
information is usually returned in the response to the mail query.
The SOA and NS types of resource records are used to define limits
Mockapetris [Page 10]
RFC 882 November 1983
Domain Names - Concepts and Facilities
of authority. The domain name given by the owner field of a SOA
record is the start of a zone; the domain name given by the owner
field of a NS record identifies a point in the name space where
authority has been delegated, and hence marks the zone boundary.
Except in the case where a name server delegates authority to
itself, the SOA identifies the top limit of authority, and NS
records define the first name outside of a zone. These resource
records have a standard format for all of the name space:
+----------+--------+--------+-----------------------------+
| <owner> | SOA | <class>| <domain name, etc> |
+----------+--------+--------+-----------------------------+
+----------+--------+--------+-----------------------------+
| <owner> | NS | <class>| <domain name> |
+----------+--------+--------+-----------------------------+
The SOA record marks the start of a zone when it is present in a
database; the NS record both marks the end of a zone started by an
SOA (if a higher SOA is present) and also points to a name server
that has a copy of the zone specified by the <owner. field of the
NS record.
The <domain name, etc> in the SOA record specifies the original
source of the information in the zone and other information used
by name servers to organize their activities. SOA records are
never cached (otherwise they would create false zones); they can
only be created in special name server maintenance operations.
The NS record says that a name server which is authoritative for
records of the given CLASS can be found at <domain name>.
Queries
Queries to a name server must include a domain name which
identifies the target resource set (QNAME), and the type and class
of desired resource records. The type and class fields in a query
can include any of the corresponding type and class fields that
are defined for resource records; in addition, the query type
(QTYPE) and query class (QCLASS) fields may contain special values
that match more than one of the corresponding fields in RRs.
For example, the QTYPE field may contain:
MAILA - matches all mail agent RRs (e.g. MD and MF).
* - matches any RR type.
Mockapetris [Page 11]
RFC 882 November 1983
Domain Names - Concepts and Facilities
The QCLASS field may contain:
* - matches any RR class.
Using the query domain name, QTYPE, and QCLASS, the name server
looks for matching RRs. In addition to relevant records, the name
server may return RRs that point toward a name server that has the
desired information or RRs that are expected to be useful in
interpreting the relevant RRs. For example a name server that
doesn't have the requested information may know a name server that
does; a name server that returns a domain name in a relevant RR
may also return the RR that binds that domain name to an address.
Note that the QCLASS=* construct requires special interpretation
regarding authority. Since a name server may not know all of the
classes available in the domain system, it can never know if it is
authoritative for all classes. Hence responses to QCLASS=*
queries can never be authoritative.
Example space
For purposes of exposition, the following name space is used for
the remainder of this memo:
|
+------------------+------------------+
| | |
DDN ARPA CSNET
| | |
+-----+-----+ | +-----+-----+
| | | | | |
JCS ARMY NAVY | UDEL UCI
|
+--------+---------------+---------------+--------+
| | | | |
DTI MIT ISI UDEL NBS
| |
+---+---+ +---+---+
| | | | |
DMS AI A B F
Mockapetris [Page 12]
RFC 882 November 1983
Domain Names - Concepts and Facilities
NAME SERVERS
Introduction
Name servers store a distributed database consisting of the
structure of the domain name space, the resource sets associated
with domain names, and other information used to coordinate
actions between name servers.
In general, a name server will be an authority for all or part of
a particular domain. The region covered by this authority is
called a zone. Name servers may be responsible for no
authoritative data, and hence have no zones, or may have several
zones. When a name server has multiple zones, the zones may have
no common borders or zones may be contiguous.
While administrators should not construct overlapping zones, and
name servers must defend against overlapping zones, overlapping is
regarded as a non-fatal flaw in the database. Hence the measures
taken to protect against it are omitted for the remainder of this
memo. A detailed discussion can be found in [14].
When presented with a query for a domain name over which it has
authority, a name server returns the desired resource information
or an indication that the query refers to a domain name or
resource that does not exist. If a name server is presented with
a query for a domain name that is not within its authority, it may
have the desired information, but it will also return a response
that points toward an authoritative name server. If a name server
is not an authority for a query, it can never return a negative
response.
There is no requirement that a name server for a domain reside in
a host which has a name in the same domain, although this will
usually be the case. There is also no restriction on the number
of name servers that can have authority over a particular domain;
most domains will have redundant authoritative name servers. The
assumption is that different authoritative copies are identical,
even though inconsistencies are possible as updates are made.
Name server functions are designed to allow for very simple
implementations of name servers. The simplest name server has a
static set of information and uses datagrams to receive queries
and return responses.
More sophisticated name server implementations can improve the
performance of their clients by caching information from other
domains. Although this information can be acquired in a number of
ways, the normal method is to store the information acquired by a
Mockapetris [Page 13]
RFC 882 November 1983
Domain Names - Concepts and Facilities
resolver when the resolver consults other name servers. In a
sophisticated host, the resolver and name server will coordinate
their actions and use a shared database. This cooperation
requires the incorporation of a time-to-live (TTL) field in all
cached resource records. Caching is discussed in the resolver
section of this memo; this section is devoted to the actions of a
name servers that don't cache.
In order to free simple name servers of the requirement of
managing these timeouts, simple name servers should only contain
resource records that are expected to remain constant over very
long periods or resource records for which the name server is an
authority. In the following discussion, the TTL field is assumed
to be stored in the resource record but is omitted in descriptions
of databases and responses in the interest of clarity.
Authority and administrative control of domains
Although we want to have the potential of delegating the
privileges of name space management at every node, we don't want
such delegation to be required.
Hence we introduce the concept of authority. Authority is vested
in name servers. A name server has authority over all of its
domain until it delegates authority for a subdomain to some other
name server.
Any administrative entity that wishes to establish its own domain
must provide a name server, and have that server accepted by the
parent name server (i.e. the name server that has authority over
the place in the domain name space that will hold the new domain).
While the principles of authority allow acceptance to be at the
discretion of parent name servers, the following criteria are used
by the root, and are recommended to all name servers because they
are responsible for their children's actions:
1. It must register with the parent administrator of domains.
2. It must identify a responsible person.
3. In must provide redundant name servers.
The domain name must be registered with the administrator to avoid
name conflicts and to make the domain related information
available to other domains. The central administrator may have
further requirements, and a domain is not registered until the
central administrator agrees that all requirements are met.
There must be a responsible person associated with each domain to
Mockapetris [Page 14]
RFC 882 November 1983
Domain Names - Concepts and Facilities
be a contact point for questions about the domain, to verify and
update the domain related information, and to resolve any problems
(e.g., protocol violations) with hosts in the domain.
The domain must provide redundant (i.e., two or more) name servers
to provide the name to address resolution service. These name
servers must be accessible from outside the domain (as well as
inside) and must resolve names for at least all the hosts in the
domain.
Once the central administrator is satisfied, he will communicate
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?