📄 rfc882.txt
字号:
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 searchMockapetris [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 this name server received a query of the form QNAME=UCI.CSNET, QTYPE=MAILA, and QCLASS=CS, the name server would return: UCI.CSNET MD CS UCI.CSNET UCI.CSNET A CS 714-555-0000 Note that although this scheme allows for forwarding of all mail addressed as <anything>.CSNET, it doesn't help with names that have more than two components, e.g. A.B.CSNET. Although this problem could be "fixed" by a series of MF entries for *.*.CSNET,Mockapetris [Page 24] RFC 882 November 1983 Domain Names - Concepts and Facilities *.*.*.CSNET, etc, a more tasteful solution would be to introduce a cleverer pattern matching algorithm in the CSNET name server. Summary of requirements for name servers The requirements for a name server are as follows: 1. It must be recognized by its parent. 2. It must have complete resource information for all domain names for which it is the authority. 3. It must periodically refresh authoritative information from a master file or name server which holds the master. 4. If it caches information it must also handle TTL managemen⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -