brian@ucsd.EDU (Brian Kantor) (02/26/88)
--- empty cache wouldn't be helpful. The resolver would recognize that it needed to query foreign servers and try to determine the best servers to query. This search would look for NS RRs for the domains ISI.EDU, EDU, and the root. These searches of the cache would also fail. As a last resort, the resolver would use the information from the SBELT, copying it into its SLIST structure. At this point the resolver would need to pick one of the three available addresses to try. Given that the resolver is on net 26, it should choose either 26.0.0.73 or 26.3.0.103 as its first choice. It would then send off a query of the form: Mockapetris [Page 47] RFC 1034 Domain Concepts and Facilities November 1987 +---------------------------------------------------+ Header | OPCODE=SQUERY | +---------------------------------------------------+ Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX | +---------------------------------------------------+ Answer | <empty> | +---------------------------------------------------+ Authority | <empty> | +---------------------------------------------------+ Additional | <empty> | +---------------------------------------------------+ The resolver would then wait for a response to its query or a timeout. If the timeout occurs, it would try different servers, then different addresses of the same servers, lastly retrying addresses already tried. It might eventually receive a reply from SRI-NIC.ARPA: +---------------------------------------------------+ Header | OPCODE=SQUERY, RESPONSE | +---------------------------------------------------+ Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX | +---------------------------------------------------+ Answer | <empty> | +---------------------------------------------------+ Authority | ISI.EDU. 172800 IN NS VAXA.ISI.EDU. | | NS A.ISI.EDU. | | NS VENERA.ISI.EDU.| +---------------------------------------------------+ Additional | VAXA.ISI.EDU. 172800 A 10.2.0.27 | | 172800 A 128.9.0.33 | | VENERA.ISI.EDU. 172800 A 10.1.0.52 | | 172800 A 128.9.0.32 | | A.ISI.EDU. 172800 A 26.3.0.103 | +---------------------------------------------------+ The resolver would notice that the information in the response gave a closer delegation to ISI.EDU than its existing SLIST (since it matches three labels). The resolver would then cache the information in this response and use it to set up a new SLIST: Match count = 3 A.ISI.EDU. 26.3.0.103 VAXA.ISI.EDU. 10.2.0.27 128.9.0.33 VENERA.ISI.EDU. 10.1.0.52 128.9.0.32 A.ISI.EDU appears on this list as well as the previous one, but that is purely coincidental. The resolver would again start transmitting and waiting for responses. Eventually it would get an answer: Mockapetris [Page 48] RFC 1034 Domain Concepts and Facilities November 1987 +---------------------------------------------------+ Header | OPCODE=SQUERY, RESPONSE, AA | +---------------------------------------------------+ Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX | +---------------------------------------------------+ Answer | ISI.EDU. MX 10 VENERA.ISI.EDU. | | MX 20 VAXA.ISI.EDU. | +---------------------------------------------------+ Authority | <empty> | +---------------------------------------------------+ Additional | VAXA.ISI.EDU. 172800 A 10.2.0.27 | | 172800 A 128.9.0.33 | | VENERA.ISI.EDU. 172800 A 10.1.0.52 | | 172800 A 128.9.0.32 | +---------------------------------------------------+ The resolver would add this information to its cache, and return the MX RRs to its client. 6.3.2. Get the host name for address 26.6.0.65 The resolver would translate this into a request for PTR RRs for 65.0.6.26.IN-ADDR.ARPA. This information is not in the cache, so the resolver would look for foreign servers to ask. No servers would match, so it would use SBELT again. (Note that the servers for the ISI.EDU domain are in the cache, but ISI.EDU is not an ancestor of 65.0.6.26.IN-ADDR.ARPA, so the SBELT is used.) Since this request is within the authoritative data of both servers in SBELT, eventually one would return: Mockapetris [Page 49] RFC 1034 Domain Concepts and Facilities November 1987 +---------------------------------------------------+ Header | OPCODE=SQUERY, RESPONSE, AA | +---------------------------------------------------+ Question | QNAME=65.0.6.26.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=PTR | +---------------------------------------------------+ Answer | 65.0.6.26.IN-ADDR.ARPA. PTR ACC.ARPA. | +---------------------------------------------------+ Authority | <empty> | +---------------------------------------------------+ Additional | <empty> | +---------------------------------------------------+ 6.3.3. Get the host address of poneria.ISI.EDU This request would translate into a type A request for poneria.ISI.EDU. The resolver would not find any cached data for this name, but would find the NS RRs in the cache for ISI.EDU when it looks for foreign servers to ask. Using this data, it would construct a SLIST of the form: Match count = 3 A.ISI.EDU. 26.3.0.103 VAXA.ISI.EDU. 10.2.0.27 128.9.0.33 VENERA.ISI.EDU. 10.1.0.52 A.ISI.EDU is listed first on the assumption that the resolver orders its choices by preference, and A.ISI.EDU is on the same network. One of these servers would answer the query. 7. REFERENCES and BIBLIOGRAPHY [Dyer 87] Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical Plan - Name Service, April 1987, version 1.9. Describes the fundamentals of the Hesiod name service. [IEN-116] J. Postel, "Internet Name Server", IEN-116, USC/Information Sciences Institute, August 1979. A name service obsoleted by the Domain Name System, but still in use. Mockapetris [Page 50] RFC 1034 Domain Concepts and Facilities November 1987 [Quarterman 86] Quarterman, J., and J. Hoskins, "Notable Computer Networks",Communications of the ACM, October 1986, volume 29, number 10. [RFC-742] K. Harrenstien, "NAME/FINGER", RFC-742, Network Information Center, SRI International, December 1977. [RFC-768] J. Postel, "User Datagram Protocol", RFC-768, USC/Information Sciences Institute, August 1980. [RFC-793] J. Postel, "Transmission Control Protocol", RFC-793, USC/Information Sciences Institute, September 1981. [RFC-799] D. Mills, "Internet Name Domains", RFC-799, COMSAT, September 1981. Suggests introduction of a hierarchy in place of a flat name space for the Internet. [RFC-805] J. Postel, "Computer Mail Meeting Notes", RFC-805, USC/Information Sciences Institute, February 1982. [RFC-810] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD Internet Host Table Specification", RFC-810, Network Information Center, SRI International, March 1982. Obsolete. See RFC-952. [RFC-811] K. Harrenstien, V. White, and E. Feinler, "Hostnames Server", RFC-811, Network Information Center, SRI International, March 1982. Obsolete. See RFC-953. [RFC-812] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812, Network Information Center, SRI International, March 1982. [RFC-819] Z. Su, and J. Postel, "The Domain Naming Convention for Internet User Applications", RFC-819, Network Information Center, SRI International, August 1982. Early thoughts on the design of the domain system. Current implementation is completely different. [RFC-821] J. Postel, "Simple Mail Transfer Protocol", RFC-821, USC/Information Sciences Institute, August 1980. Mockapetris [Page 51] RFC 1034 Domain Concepts and Facilities November 1987 [RFC-830] Z. Su, "A Distributed System for Internet Name Service", RFC-830, Network Information Center, SRI International, October 1982. Early thoughts on the design of the domain system. Current implementation is completely different. [RFC-882] P. Mockapetris, "Domain names - Concepts and Facilities," RFC-882, USC/Information Sciences Institute, November 1983. Superceeded by this memo. [RFC-883] P. Mockapetris, "Domain names - Implementation and Specification," RFC-883, USC/Information Sciences Institute, November 1983. Superceeded by this memo. [RFC-920] J. Postel and J. Reynolds, "Domain Requirements", RFC-920, USC/Information Sciences Institute October 1984. Explains the naming scheme for top level domains. [RFC-952] K. Harrenstien, M. Stahl, 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-953] K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server", RFC-953, SRI, October 1985. This RFC contains the official specification of the hostname server protocol, which is obsoleted by the DNS. This TCP based protocol accesses information stored in the RFC-952 format, and is used to obtain copies of the host table. [RFC-973] P. Mockapetris, "Domain System Changes and Observations", RFC-973, USC/Information Sciences Institute, January 1986. Describes changes to RFC-882 and RFC-883 and reasons for them. Now obsolete. Mockapetris [Page 52] RFC 1034 Domain Concepts and Facilities November 1987 [RFC-974] C. Partridge, "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. [RFC-1001] NetBIOS Working Group, "Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and Methods", RFC-1001, March 1987. This RFC and RFC-1002 are a preliminary design for NETBIOS on top of TCP/IP which proposes to base NetBIOS name service on top of the DNS. [RFC-1002] NetBIOS Working Group, "Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed Specifications", RFC-1002, March 1987. [RFC-1010] J. Reynolds 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-1031] W. Lazear, "MILNET Name Domain Transition", RFC-1031, November 1987. Describes a plan for converting the MILNET to the DNS. [RFC-1032] M. K. Stahl, "Establishing a Domain - Guidelines for Administrators", RFC-1032, November 1987. Describes the registration policies used by the NIC to administer the top level domains and delegate subzones. [RFC-1033] M. K. Lottor, "Domain Administrators Operations Guide", RFC-1033, November 1987. A cookbook for domain administrators. [Solomon 82] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET Name Server", Computer Networks, vol 6, nr 3, July 1982. Describes a name service for CSNET which is independent from the DNS and DNS use in the CSNET. Mockapetris [Page 53] RFC 1034 Domain Concepts and Facilities November 1987 Index A 12 Absolute names 8 Aliases 14, 31 Authority 6 AXFR 17 Case of characters 7 CH 12 CNAME 12, 13, 31 Completion queries 18 Domain name 6, 7 Glue RRs 20 HINFO 12 IN 12 Inverse queries 16 Iterative 4 Label 7 Mailbox names 9 MX 12 Name error 27, 36 Name servers 5, 17 NE 30 Negative caching 44 NS 12 Opcode 16 PTR 12 QCLASS 16 QTYPE 16 RDATA 13 Recursive 4 Recursive service 22 Relative names 7 Resolvers 6 RR 12 Mockapetris [Page 54] RFC 1034 Domain Concepts and Facilities November 1987 Safety belt 33 Sections 16 SOA 12 Standard queries 22 Status queries 18 Stub resolvers 32 TTL 12, 13 Wildcards 25 Zone transfers 28 Zones 19 Mockapetris [Page 55]