rfc882.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,379 行 · 第 1/5 页
TXT
1,379 行
Domain Names - Concepts and Facilities
A scenario
In our sample domain space, suppose we wanted separate
administrative control for the root, DDN, ARPA, CSNET, MIT and ISI
domains. We might allocate name servers as follows:
|(B.ISI.ARPA)
|(UDEL.CSNET)
+------------------+------------------+
| | |
DDN ARPA CSNET
|(JCS.DDN) |(F.ISI.ARPA) |(UDEL.ARPA)
+-----+-----+ |(A.ISI.ARPA)+-----+-----+
| | | | | |
JCS ARMY NAVY | UDEL UCI
|
+--------+---------------+---------------+--------+
| | | | |
DTI MIT ISI UDEL NBS
|(AI.MIT.ARPA) |(F.ISI.ARPA)
+---+---+ +---+---+
| | | | |
DMS AI A B F
In this example the authoritative name server is shown in
parentheses at the point in the domain tree at which is assumes
control.
Thus the root name servers are on B.ISI.ARPA and UDEL.CSNET, the
DDN name server is on JCS.DDN, the CSNET domain server is on
UDEL.ARPA, etc.
In an actual system, all domains should have redundant name
servers, but in this example only the ARPA domain has redundant
servers A.ISI.ARPA and F.ISI.ARPA. (The B.ISI.ARPA and UDEL.CSNET
name servers happen to be not redundant because they handle
different classes.) The F.ISI.ARPA name server has authority over
the ARPA domain, but delegates authority over the MIT.ARPA domain
to the name server on AI.MIT.ARPA. The A.ISI.ARPA name server
also has authority over the ARPA domain, but delegates both the
ISI.ARPA and MIT.ARPA domains to other name servers.
Mockapetris [Page 20]
RFC 882 November 1983
Domain Names - Concepts and Facilities
B.ISI.ARPA Name server for " "
B.ISI.ARPA has the root name server for the IN class. Its
database might contain:
Domain Resource Record
" " SOA IN A.ISI.ARPA
DDN NS IN JCS.DDN
ARPA NS IN F.ISI.ARPA
CSNET NS IN UDEL.ARPA
" " NS IN B.ISI.ARPA
" " NS CS UDEL.CSNET
JCS.DDN A IN 9.0.0.1
F.ISI.ARPA A IN 10.2.0.52
UDEL.CSNET A CS 302-555-0000
UDEL.ARPA A IN 10.0.0.96
The SOA record for the root is necessary so that the name server
knows that it is authoritative for the root domain for class IN.
The contents of the SOA resource record point back to A.ISI.ARPA
and denote that the master data for the zone of authority is
originally from this host. The first three NS records denote
delegation of authority. The NS root entry for the B.ISI.ARPA
name server is necessary so that this name server knows about
itself, and can respond correctly to a query for NS information
about the root (for which it is an authority). The root entry for
class CS denotes that UDEL.CSNET is the authoritative name server
for the CS class root. UDEL.CSNET and UDEL.ARPA may or may not
refer to the same name server; from this information it is
impossible to tell.
If this name server was sent a query specifying QTYPE=MAILA,
QCLASS=IN, QNAME=F.ISI.ARPA, it would begin processing (using the
previous algorithm) by determining that it was not an authority
for F.ISI.ARPA. The test would note that it had authority at " ",
but would also note that the authority was delegated at ARPA and
never reestablished via another SOA. Thus the response would
return the NS record for the domain ARPA.
Any queries presented to this server with QCLASS=CS would result
in the UDEL.CSNET NS record being returned in the response.
Mockapetris [Page 21]
RFC 882 November 1983
Domain Names - Concepts and Facilities
F.ISI.ARPA Name server for ARPA and ISI.ARPA
In the same domain space, the F.ISI.ARPA database for the domains
ARPA and ISI.ARPA might be:
Domain Resource Record
" " NS IN B.ISI.ARPA
" " NS CS CSNET.UDEL
ARPA SOA IN B.ISI.ARPA
ARPA NS IN A.ISI.ARPA
ARPA NS IN F.ISI.ARPA
MIT.ARPA NS IN AI.MIT.ARPA
ISI.ARPA SOA IN F.ISI.ARPA
ISI.ARPA NS IN F.ISI.ARPA
A.ISI.ARPA MD IN A.ISI.ARPA
ISI.ARPA MD IN F.ISI.ARPA
A.ISI.ARPA MF IN F.ISI.ARPA
B.ISI.ARPA MD IN B.ISI.ARPA
B.ISI.ARPA MF IN F.ISI.ARPA
F.ISI.ARPA MD IN F.ISI.ARPA
F.ISI.ARPA MF IN A.ISI.ARPA
DTI.ARPA MD IN DTI.ARPA
NBS.ARPA MD IN NBS.ARPA
UDEL.ARPA MD IN UDEL.ARPA
A.ISI.ARPA A IN 10.1.0.32
F.ISI.ARPA A IN 10.2.0.52
B.ISI.ARPA A IN 10.3.0.52
DTI.ARPA A IN 10.0.0.12
AI.MIT.ARPA A IN 10.2.0.6
DMS.MIT.ARPA A IN 10.1.0.6
NBS.ARPA A IN 10.0.0.19
UDEL.ARPA A IN 10.0.0.96
For the IN class, the SOA RR for ARPA denotes that this name
server is authoritative for the domain ARPA, and that the master
file for this authority is stored on B.ISI.ARPA. This zone
extends to ISI.ARPA, where the database delegates authority back
to this name server in another zone, and doesn't include the
domain MIT.ARPA, which is served by a name server on AI.MIT.ARPA.
This name server is not authoritative for any data in the CS
class. It has a pointer to the root server for CS data which
could be use to resolve CS class queries.
Suppose this name server received a query of the form
QNAME=A.ISI.ARPA, QTYPE=A, and QCLASS=IN. The authority search
Mockapetris [Page 22]
RFC 882 November 1983
Domain Names - Concepts and Facilities
would notice the NS record for " ", its SOA at ARPA, a delegation
at ISI.ARPA, and the reassumption of authority at ISI.ARPA. Hence
it would know that it was an authority for this query. It would
then find the A record for A.ISI.ARPA, and return a datagram
containing this record.
Another query might be QNAME=B.ISI.ARPA, QTYPE=MAILA, QCLASS=*.
In this case the name server would know that it cannot be
authoritative because of the "*" value of QCLASS, and would look
for records for domain B.ISI.ARPA that match. Assuming that the
name server performs the additional record inclusion mentioned in
the name server algorithm, the returned datagram would include:
ISI.ARPA NS IN F.ISI.ARPA
" " NS CS UDEL.CSNET
B.ISI.ARPA MD IN B.ISI.ARPA
B.ISI.ARPA MF IN F.ISI.ARPA
B.ISI.ARPA A IN 10.3.0.52
F.ISI.ARPA A IN 10.2.0.52
If the query were QNAME=DMS.MIT.ARPA, QTYPE=MAILA, QCLASS=IN, the
name server would discover that AI.MIT.ARPA was the authoritative
name server and return the following:
MIT.ARPA NS IN AI.MIT.ARPA
AI.MIT.ARPA A IN 10.2.0.6
In this case, the requestor is directed to seek information from
the MIT.ARPA domain name server residing on AI.MIT.ARPA.
Mockapetris [Page 23]
RFC 882 November 1983
Domain Names - Concepts and Facilities
UDEL.ARPA and UDEL.CSNET name server
In the previous discussion of the sample domain, we stated that
UDEL.CSNET and UDEL.ARPA might be the same name server. In this
example, we assume that this is the case. As such, the name
server is an authority for the root for class CS, and an authority
for the CSNET domain for class IN.
This name server deals with mail forwarding between the ARPA
Internet and CSNET systems. Its RRs illustrate one approach to
solving this problem. The name server has the following resource
records:
" " SOA CS UDEL.CSNET
" " NS CS UDEL.CSNET
" " NS IN B.ISI.ARPA
CSNET SOA IN UDEL.ARPA
CSNET NS IN UDEL.ARPA
ARPA NS IN A.ISI.ARPA
*.CSNET MF IN UDEL.ARPA
UDEL.CSNET MD CS UDEL.CSNET
UCI.CSNET MD CS UCI.CSNET
UDEL.ARPA MD IN UDEL.ARPA
B.ISI.ARPA A IN 10.3.0.52
UDEL.ARPA A IN 10.0.0.96
UDEL.CSNET A CS 302-555-0000
UCI.CSNET A CS 714-555-0000
Suppose this name server received a query of the form
QNAME=UCI.CSNET, QTYPE=MAILA, and QCLASS=IN. The name server
would discover it was authoritative for the CSNET domain under
class IN, but would find no explicit mail data for UCI.CSNET.
However, using the *.CSNET record, it would construct a reply:
UCI.CSNET MF IN UDEL.ARPA
UDEL.ARPA A IN 10.0.0.96
If th⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?