Network Working Group P. Mockapetris Request for Comments: 1035 ISI November 1987 Obsoletes: RFCs 882, 883, 973
DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
1. STATUS OF THIS MEMO
This RFC describes the details of the domain system and protocol, and assumes that the reader is familiar with the concepts discusd in a companion RFC, "Domain Names - Concepts and Facilities" [RFC-1034].
The domain system is a mixture of functions and data types which are an official protocol and functions and data types which are still experimental. Since the domain system is intentionally extensible, new data types and experimental behavior should always be expected in parts of the system beyond the official protocol. The official protocol parts include standard queries, respons and the Internet class RR data formats (e.g., host address). Since the previous RFC t, veral definitions have changed, so some previous definitions are obsolete. Experimental or obsolete features are clearly marked in the RFCs, and such information should be ud with caution.
The reader is especially cautioned not to depend on the values which appear in examples to be current or complete, since their purpo is primarily pedagogical. Distribution of this memo is unlimited.
Table of Contents
1. STATUS OF THIS MEMO 1
2. INTRODUCTION 3 2.1. Overview 3 2.2. Common configurations 4 2.
3. Conventions 7 2.3.1. Preferred name syntax 7 2.3.2. Data Transmission Order 8 2.3.3. Character Ca 9
2.3.4. Size limits 10
3. DOMAIN NAME SPACE AND RR DEFINITIONS 10 3.1. Name space definitions 10 3.2. RR definitions 11 3.2.1. Format 11 3.2.2. TYPE values 12 3.
2.3. QTYPE values 12 3.2.
4. CLASS values 13 Mockapetris [Page 1]
RFC 1035 Domain Implementation and Specification November 1987 3.2.5. QCLASS values 13 3.3. Standard RRs 13 3.3.1. CNAME RDATA format 14 3.3.2. HINFO RDATA format 14 3.3.3. MB RDATA format (EXPERIMENTAL) 14 3.3.4. MD RDATA format (Obsolete) 15 3.3.5. MF RDATA format (Obsolete) 15 3.3.6. MG RDATA format (EXPERIMENTAL) 16 3.3.7. MINFO RDATA format (EXPERIMENTAL) 16 3.3.8. MR RDATA format (EXPERIMENTAL) 17 3.3.9. MX RDATA format 17 3.3.10. NULL RDATA format (EXPERIMENTAL) 17 3.3.11. NS RDATA format 18 3.3.12. PTR RDATA format 18 3.3.13. SOA RDATA format 19 3.3.14. TXT RDATA format 20 3.4. ARPA Internet specific RRs 20 3.4.1. A RDATA format 20 3.4.2. WKS RDATA format 21 3.5. IN-ADDR.ARPA domain 22
3.6. Defining new types, class, and special namespaces 24
4. MESSAGES 25 4.1. Format 25 4.1.1. Header ction format 26 4.1.2. Question ction format 28 4.1.3. Resource record format 29 4.1.4. Message compression 30 4.2. Transport 32 4.2.1. UDP usage 32
4.2.2. TCP usage 32
5. MASTER FILES 33 5.1. Format 33 5.2. U of master files to define zones 35
5.3. Master file example 36
6. NAME SERVER IMPLEMENTATION 37 6.1. Architecture 37 6.1.1. Control 37 6.1.2. Databa 37 6.1.3. Time 39 6.2. Standard query processing 39 6.3. Zone refresh and reload processing 39 6.4. Inver queries (Optional) 40 6.4.1. The contents of inver queries and respons 40 6.4.2. Inver query and respon example 41 6.4.3. Inv
er query processing 42 Mockapetris [Page 2]
RFC 1035 Domain Implementation and Specification November 1987
6.5. Completion queries and respons 42
7. RESOLVER IMPLEMENTATION 43 7.1. Transforming a ur request into a query 43 7.2. Sending the queries 44 7.3. Processing respons 46
7.4. Using the cache 47
8. MAIL SUPPORT 47 8.1. Mail exchange binding 48
8.2. Mailbox binding (Experimental) 48
9. REFERENCES and BIBLIOGRAPHY 50 Index 54 2. INTRODUCTION
2.1. Overview
The goal of domain names is to provide a mechanism for naming resources in such a way that the names are usable in different hosts, networks, protocol families, internets, and administrative organizations.
From the ur’s point of view, domain names are uful as arguments to a local agent, called a resolver, which retrieves information associated with the domain name. Thus a ur might ask for the host address or
mail information associated with a particular domain name. To enable
the ur to request a particular type of information, an appropriate query type is pasd to the resolver with the domain name. To the ur, the domain tree is a single information space; the resolver is
responsible for hiding the distribution of data among name rvers from the ur.
东亚杯中国对澳大利亚From the resolver’s point of view, the databa that makes up the domain space is distributed among various name rvers. Different parts of the domain space are stored in different name rvers, although a particular data item will be stored redundantly in two or more name rvers. The
resolver starts with knowledge of at least one name rver. When the resolver process a ur query it asks a known name rver for the information; in return, the resolver either receives the desired information or a referral to another name rver. Using the
referrals, resolvers learn the identities and contents of other name rvers. Resolvers are responsible for dealing with the distribution of the domain space and dealing with the effects of name rver failure by consulting redundant databas in other rvers.
Name rvers manage two kinds of data. The first kind of data held in ts called zones; each zone is the complete databa for a particular "pruned" subtree of the domain space. This data is called
authoritative. A name rver periodically checks to make sure that its zones are up to date, and if not, obtains a new copy of updated zones Mockapetris [Page 3]
RFC 1035 Domain Implementation and Specification November 1987 from master files stored locally or in another name rver. The cond kind of data is cached data which was acquired by a local resolver.
This data may be incomplete, but improves the performance of the
cia是什么意思
retrieval process when non-local data is repeatedly accesd. Cached data is eventually discarded by a timeout mechanism.
This functional structure isolates the problems of ur interface,
failure recovery, and distribution in the resolvers and isolates the databa update and refresh problems in the name rvers.
2.2. Common configurations
A host can participate in the domain name system in a number of ways, depending on whether the host runs programs that retrieve information from the domain system, name rvers that answer queries from other hosts, or various combinations of both functions. The simplest, and perhaps most typical, configuration is shown below:
Local Host | Foreign
|
+---------+ +----------+ | +--------+pangaea
| | ur queries | |queries | | |
| Ur |-------------->| |---------|->|Foreign |
| Program | | Resolver | | | Name |
| |<--------------| |<--------|--| Server |
| | ur respons| |respons| | |
+---------+ +----------+ | +--------+
| A |
cache additions | | references |
V | |
+----------+ |
| cache | |
2011年中考满分作文
+----------+ |
Ur programs interact with the domain name space through resolvers; the format of ur queries and ur respons is specific to the host and
北京农学院研究生院
its operating system. Ur queries will typically be operating system calls, and the resolver and its cache will be part of the host operating system. Less capable hosts may choo to implement the resolver as a subroutine to be linked in with every program that needs its rvices. Resolvers answer ur queries with information they acquire via queries to foreign name rvers and the local cache.
Note that the resolver may have to make veral queries to veral different foreign name rvers to answer a particular ur query, and hence the resolution of a ur query may involve veral network
access and an arbitrary amount of time. The queries to foreign name rvers and the corresponding respons have a standard format described Mockapetris [Page 4]
RFC 1035 Domain Implementation and Specification November 1987 in this memo, and may be datagrams.
Depending on its capabilities, a name rver could be a stand alone program on a dedicated machine or a process or process on a large timeshared host. A simple configuration might be:
Local Host | Foreign
|
学习催眠+---------+ |
/ /| |
+---------+ | +----------+ | +--------+
| | | | |respons| | |
| | | | Name |---------|->|Foreign |
| Master |-------------->| Server | | |Resolver|
| files | | | |<--------|--| |
| |/ | | queries | +--------+
+---------+ +----------+ |
Here a primary name rver acquires information about one or more zones by reading master files from its local file system, and answers queries about tho zones that arrive from foreign resolvers.
The DNS requires that all zones be redundantly supported by more than one name rver. Designated condary rvers can acquire zones and check for updates from the primary rver using the zone transfer
protocol of the DNS. This configuration is shown below:
Local Host | Foreign
|
+---------+ |
/
/| |crawling
+---------+ | +----------+ | +--------+
| | | | |respons| | |
| | | | Name |---------|->|Foreign |
| Master |-------------->| Server | | |Resolver|
| files | | | |<--------|--| |
| |/ | | queries | +--------+
上海留学中介+---------+ +----------+ |
A |maintenance | +--------+
| +------------|->| |
| queries | |Foreign |
| | | Name |
明确英语+------------------|--| Server |
maintenance respons | +--------+
In this configuration, the name rver periodically establishes a
雅思成绩virtual circuit to a foreign name rver to acquire a copy of a zone or to check that an existing copy has not changed. The messages nt for Mockapetris [Page 5]
