📄 00000004.htm
字号:
<HTML><HEAD> <TITLE>BBS水木清华站∶精华区</TITLE></HEAD><BODY><CENTER><H1>BBS水木清华站∶精华区</H1></CENTER>Network Working Group P. Mockapetris <BR>Request for Comments: 1034 ISI <BR>Obsoletes: RFCs 882, 883, 973 November 1987 <BR> <BR> <BR> DOMAIN NAMES - CONCEPTS AND FACILITIES <BR> <BR> <BR> <BR>1. STATUS OF THIS MEMO <BR> <BR>This RFC is an introduction to the Domain Name System (DNS), and omits <BR>many details which can be found in a companion RFC, "Domain Names - <BR>Implementation and Specification" [RFC-1035]. That RFC assumes that the <BR>reader is familiar with the concepts discussed in this memo. <BR> <BR>A subset of DNS functions and data types constitute an official <BR>protocol. The official protocol includes standard queries and their <BR>responses and most of the Internet class data formats (e.g., host <BR>addresses). <BR> <BR>However, the domain system is intentionally extensible. Researchers are <BR>continuously proposing, implementing and experimenting with new data <BR>types, query types, classes, functions, etc. Thus while the components <BR>of the official protocol are expected to stay essentially unchanged and <BR>operate as a production service, experimental behavior should always be <BR>expected in extensions beyond the official protocol. Experimental or <BR>obsolete features are clearly marked in these RFCs, and such information <BR>should be used with caution. <BR> <BR>The reader is especially cautioned not to depend on the values which <BR>appear in examples to be current or complete, since their purpose is <BR>primarily pedagogical. Distribution of this memo is unlimited. <BR> <BR>2. INTRODUCTION <BR> <BR>This RFC introduces domain style names, their use for Internet mail and <BR>host address support, and the protocols and servers used to implement <BR>domain name facilities. <BR> <BR>2.1. The history of domain names <BR> <BR>The impetus for the development of the domain system was growth in the <BR>Internet: <BR> <BR> - Host name to address mappings were maintained by the Network <BR> Information Center (NIC) in a single file (HOSTS.TXT) which <BR> was FTPed by all hosts [RFC-952, RFC-953]. The total network <BR> <BR> <BR> <BR>Mockapetris [Page 1] <BR> <BR>RFC 1034 Domain Concepts and Facilities November 1987 <BR> <BR> <BR> bandwidth consumed in distributing a new version by this <BR> scheme is proportional to the square of the number of hosts in <BR> the network, and even when multiple levels of FTP are used, <BR> the outgoing FTP load on the NIC host is considerable. <BR> Explosive growth in the number of hosts didn't bode well for <BR> the future. <BR> <BR> - The network population was also changing in character. The <BR> timeshared hosts that made up the original ARPANET were being <BR> replaced with local networks of workstations. Local <BR> organizations were administering their own names and <BR> addresses, but had to wait for the NIC to change HOSTS.TXT to <BR> make changes visible to the Internet at large. Organizations <BR> also wanted some local structure on the name space. <BR> <BR> - The applications on the Internet were getting more <BR> sophisticated and creating a need for general purpose name <BR> service. <BR> <BR> <BR>The result was several ideas about name spaces and their management <BR>[IEN-116, RFC-799, RFC-819, RFC-830]. The proposals varied, but a <BR>common thread was the idea of a hierarchical name space, with the <BR>hierarchy roughly corresponding to organizational structure, and names <BR>using "." as the character to mark the boundary between hierarchy <BR>levels. A design using a distributed database and generalized resources <BR>was described in [RFC-882, RFC-883]. Based on experience with several <BR>implementations, the system evolved into the scheme described in this <BR>memo. <BR> <BR>The terms "domain" or "domain name" are used in many contexts beyond the <BR>DNS described here. Very often, the term domain name is used to refer <BR>to a name with structure indicated by dots, but no relation to the DNS. <BR>This is particularly true in mail addressing [Quarterman 86]. <BR> <BR>2.2. DNS design goals <BR> <BR>The design goals of the DNS influence its structure. They are: <BR> <BR> - The primary goal is a consistent name space which will be used <BR> for referring to resources. In order to avoid the problems <BR> caused by ad hoc encodings, names should not be required to <BR> contain network identifiers, addresses, routes, or similar <BR> information as part of the name. <BR> <BR> - The sheer size of the database and frequency of updates <BR> suggest that it must be maintained in a distributed manner, <BR> with local caching to improve performance. Approaches that <BR> <BR> <BR> <BR>Mockapetris [Page 2] <BR> <BR>RFC 1034 Domain Concepts and Facilities November 1987 <BR> <BR> <BR> attempt to collect a consistent copy of the entire database <BR> will become more and more expensive and difficult, and hence <BR> should be avoided. The same principle holds for the structure <BR> of the name space, and in particular mechanisms for creating <BR> and deleting names; these should also be distributed. <BR> <BR> - Where there tradeoffs between the cost of acquiring data, the <BR>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -