RFC1034(域名 - 概念和设施)
DOMAIN NAMES - CONCEPTS AND FACILITIES(域名-概念和设施)
1. STATUS OF THIS MEMO(本备忘录的状态)
This RFC is an introduction to the Domain Name System (DNS), and omits
many details which can be found in a companion RFC, “Domain Names -
Implementation and Specification” [RFC-1035]. That RFC assumes that the
reader is familiar with the concepts discussed in this memo.
该 RFC 是对域名系统 (DNS) 的介绍，省略了许多细节，这些细节可以在配套 RFC中找到,RFC1035。 该 RFC 假定读者熟悉本备忘录中讨论的概念。
A subset of DNS functions and data types constitute an official
protocol. The official protocol includes standard queries and their
responses and most of the Internet class data formats (e.g., host
addresses).
However, the domain system is intentionally extensible. Researchers are
continuously proposing, implementing and experimenting with new data
types, query types, classes, functions, etc. Thus while the components
of the official protocol are expected to stay essentially unchanged and
operate as a production service, experimental behavior should always be
expected in extensions beyond the official protocol. Experimental or
obsolete features are clearly marked in these RFCs, and such information
should be used with caution.
The reader is especially cautioned not to depend on the values which
appear in examples to be current or complete, since their purpose is
primarily pedagogical. Distribution of this memo is unlimited.
2. INTRODUCTION
This RFC introduces domain style names, their use for Internet mail and
host address support, and the protocols and servers used to implement
domain name facilities.
2.1. The history of domain names
The impetus for the development of the domain system was growth in the
Internet:
Host name to address mappings were maintained by the Network
Information Center (NIC) in a single file (HOSTS.TXT) which
was FTPed by all hosts [RFC-952, RFC-953]. The total network
bandwidth consumed in distributing a new version by this
scheme is proportional to the square of the number of hosts in
the network, and even when multiple levels of FTP are used,
the outgoing FTP load on the NIC host is considerable.
Explosive growth in the number of hosts didn’t bode well for
the future.The network population was also changing in character. The
timeshared hosts that made up the original ARPANET were being
replaced with local networks of workstations. Local
organizations were administering their own names and
addresses, but had to wait for the NIC to change HOSTS.TXT to
make changes visible to the Internet at large. Organizations
also wanted some local structure on the name space.The applications on the Internet were getting more
sophisticated and creating a need for general purpose name
service.
The result was several ideas about name spaces and their management
[IEN-116, RFC-799, RFC-819, RFC-830]. The proposals varied, but a
common thread was the idea of a hierarchical name space, with the
hierarchy roughly corresponding to organizational structure, and names
using “.” as the character to mark the boundary between hierarchy
levels. A design using a distributed database and generalized resources
was described in [RFC-882, RFC-883]. Based on experience with several
implementations, the system evolved into the scheme described in this
memo.
The terms “domain” or “domain name” are used in many contexts beyond the
DNS described here. Very often, the term domain name is used to refer
to a name with structure indicated by dots, but no relation to the DNS.
This is particularly true in mail addressing [Quarterman 86].
2.2. DNS design goals(DNS设计目标)
The design goals of the DNS influence its structure. They are:
DNS 的设计目标影响其结构。 他们是:
- The primary goal is a consistent name space which will be used for referring to resources. In order to avoid the problems caused by ad hoc encodings, names should not be required to contain network identifiers, addresses, routes, or similar information as part of the name.
*主要目标是用于引用资源的一致的名称空间。 为了避免临时编码引起的问题，不应要求名称包含网络标识符、地址、路由或类似信息作为名称的一部分。*
The sheer size of the database and frequency of updates suggest that it must be maintained in a distributed manner, with local caching to improve performance. Approaches that attempt to collect a consistent copy of the entire database will become more and more expensive and difficult, and hence should be avoided. The same principle holds for the structure of the name space, and in particular mechanisms for creating and deleting names; these should also be distributed.
数据库的庞大规模和更新频率表明必须以分布式方式维护它，并使用本地缓存来提高性能。 尝试收集整个数据库的一致副本的方法将变得越来越昂贵和困难，因此应该避免。 同样的原则也适用于名称空间的结构，特别是创建和删除名称的机制； 这些也应该分发。
Where there tradeoffs between the cost of acquiring data, the speed of updates, and the accuracy of caches, the source of the data should control the tradeoff.
当获取数据的成本、更新速度和缓存的准确性之间存在权衡时，数据源应该控制权衡。
The costs of implementing such a facility dictate that it be generally useful, and not restricted to a single application. We should be able to use names to retrieve host addresses, mailbox data, and other as yet undetermined information. All data associated with a name is tagged with a type, and queries can be limited to a single type.
实施这种设施的成本决定了它通常是有用的，并且不限于单个应用程序。 我们应该能够使用名称来检索主机地址、邮箱数据和其他尚未确定的信息。 与名称关联的所有数据都用类型标记，并且查询可以限制为单一类型。
Because we want the name space to be useful in dissimilar networks and applications, we provide the ability to use the same name space with different protocol families or management. For example, host address formats differ between protocols, though all protocols have the notion of address. The DNS tags all data with a class as well as the type, so that we can allow parallel use of different formats for data of type address.
因为我们希望名称空间在不同的网络和应用程序中有用，所以我们提供了在不同协议族或管理中使用相同名称空间的能力。 例如，尽管所有协议都有地址的概念，但协议之间的主机地址格式有所不同。 DNS 用类别和类型标记所有数据，以便我们可以允许并行使用地址类型数据的不同格式。
We want name server transactions to be independent of the communications system that carries them. Some systems may wish to use datagrams for queries and responses, and only establish virtual circuits for transactions that need the reliability (e.g., database updates, long transactions); other systems will use virtual circuits exclusively.
我们希望名称服务器事务独立于承载它们的通信系统。 有些系统可能希望使用数据报进行查询和响应，并且只为需要可靠性的事务（例如数据库更新、长事务）建立虚拟电路； 其他系统将专门使用虚拟电路。
The system should be useful across a wide spectrum of host capabilities. Both personal computers and large timeshared hosts should be able to use the system, though perhaps in different ways.
该系统应该适用于广泛的主机功能。 个人计算机和大型分时主机都应该能够使用该系统，尽管方式可能不同。
2.3. Assumptions about usage(使用假设)
The organization of the domain system derives from some assumptions about the needs and usage patterns of its user community and is designed to avoid many of the the complicated problems found in general purpose database systems.
域系统的组织源于对其用户社区的需求和使用模式的一些假设，并且旨在避免通用数据库系统中发现的许多复杂问题。
The assumptions are:(假设如下:)
The size of the total database will initially be proportional to the number of hosts using the system, but will eventually grow to be proportional to the number of users on those hosts as mailboxes and other information are added to the domain system.
总数据库的大小最初将与使用系统的主机数量成正比，但随着邮箱和其他信息添加到域系统中，最终将与这些主机上的用户数量成正比。Most of the data in the system will change very slowly (e.g., mailbox bindings, host addresses), but that the system should be able to deal with subsets that change more rapidly (on the order of seconds or minutes).
系统中的大多数数据将非常缓慢地变化（例如，邮箱绑定、主机地址），但是系统应该能够处理变化更快的子集（大约以秒或分钟为单位）。The administrative boundaries used to distribute responsibility for the database will usually correspond to organizations that have one or more hosts. Each organization that has responsibility for a particular set of domains will provide redundant name servers, either on the organization’s own hosts or other hosts that the organization arranges to use.
用于分配数据库职责的管理边界通常对应于拥有一台或多台主机的组织。 负责一组特定域的每个组织都将在该组织自己的主机上或该组织安排使用的其他主机上提供冗余名称服务器。Clients of the domain system should be able to identify trusted name servers they prefer to use before accepting referrals to name servers outside of this “trusted” set.
域系统的客户端应该能够在接受对此“受信任”集合之外的名称服务器的引用之前识别他们更喜欢使用的受信任名称服务器。Access to information is more critical than instantaneous updates or guarantees of consistency. Hence the update process allows updates to percolate out through the users of the domain system rather than guaranteeing that all copies are simultaneously updated. When updates are unavailable due to network or host failure, the usual course is to believe old information while continuing efforts to update it. The general model is that copies are distributed with timeouts for refreshing. The distributor sets the timeout value and the recipient of the distribution is responsible for performing the refresh. In special situations, very short intervals can be specified, or the owner can prohibit copies.
获取信息比即时更新或保证一致性更重要。 因此，更新过程允许更新通过域系统的用户渗透出去，而不是保证所有副本同时更新。 当由于网络或主机故障而无法进行更新时，通常的做法是相信旧信息，同时继续努力更新它。 一般模型是分发副本并设置超时刷新。 分发者设置超时值，分发的接收者负责执行刷新。 在特殊情况下，可以指定非常短的间隔，或者所有者可以禁止复制。In any system that has a distributed database, a particular name server may be presented with a query that can only be answered by some other server. The two general approaches to dealing with this problem are “recursive”, in which the first server pursues the query for the client at another server, and “iterative”, in which the server refers the client to another server and lets the client pursue the query. Both approaches have advantages and disadvantages, but the iterative approach is preferred for the datagram style of access. The domain system requires implementation of the iterative approach, but allows the recursive approach as an option.
在任何具有分布式数据库的系统中，特定的名称服务器可能会收到只能由其他服务器回答的查询。 处理此问题的两种通用方法是”recursive(递归)”，其中第一个服务器在另一台服务器上执行客户端的查询；以及“iterative(迭代)”，其中服务器将客户端引用到另一台服务器并让客户端执行查询 询问。 两种方法都有优点和缺点，但对于数据报样式的访问，迭代方法是首选。 域系统需要迭代方法的实现，但允许递归方法作为选项。
The domain system assumes that all data originates in master files scattered through the hosts that use the domain system. These master files are updated by local system administrators. Master files are text files that are read by a local name server, and hence become available through the name servers to users of the domain system. The user programs access name servers through standard programs called resolvers.
域系统假定所有数据都源自分散在使用域系统的主机中的主文件。 这些主文件由本地系统管理员更新。 主文件是由本地名称服务器读取的文本文件，因此可以通过名称服务器供域系统的用户使用。 用户程序通过称为解析器的标准程序访问名称服务器。
The standard format of master files allows them to be exchanged between hosts (via FTP, mail, or some other mechanism); this facility is useful when an organization wants a domain, but doesn’t want to support a name server. The organization can maintain the master files locally using a text editor, transfer them to a foreign host which runs a name server, and then arrange with the system administrator of the name server to get the files loaded.
主文件的标准格式允许它们在主机之间交换（通过 FTP、邮件或其他一些机制）； 当组织想要域但不想支持名称服务器时，此功能非常有用。 组织可以使用文本编辑器在本地维护主文件，将它们传输到运行名称服务器的外部主机，然后与名称服务器的系统管理员安排加载文件。
Each host’s name servers and resolvers are configured by a local system administrator [RFC-1033]. For a name server, this configuration data includes the identity of local master files and instructions on which non-local master files are to be loaded from foreign servers. The name server uses the master files or copies to load its zones. For resolvers, the configuration data identifies the name servers which should be the primary sources of information.
每个主机的名称服务器和解析器均由本地系统管理员配置[RFC-1033]。 对于名称服务器，此配置数据包括本地主文件的标识以及从外部服务器加载非本地主文件的指令。 名称服务器使用主文件或副本来加载其区域。 对于解析器，配置数据标识名称服务器，该名称服务器应该是主要信息源。
The domain system defines procedures for accessing the data and for referrals to other name servers. The domain system also defines procedures for caching retrieved data and for periodic refreshing of data defined by the system administrator.
域系统定义了访问数据和引用其他名称服务器的过程。 域系统还定义了用于缓存检索到的数据和定期刷新由系统管理员定义的数据的过程。
The system administrators provide:
系统管理员提供：
The definition of zone boundaries.
区域边界的定义。Master files of data.
主数据文件。Updates to master files.
主文件更新Statements of the refresh policies desired.
所需刷新策略的声明。
The domain system provides:
域系统提供：
Standard formats for resource data.
资源数据的标准格式。Standard methods for querying the database.
查询数据库的标准方法。Standard methods for name servers to refresh local data from foreign name servers.
名称服务器从外部名称服务器刷新本地数据的标准方法。
2.4. Elements of the DNS（DNS元素）
The DNS has three major components:
DNS 有三个主要组件：
The DOMAIN NAME SPACE and RESOURCE RECORDS, which are specifications for a tree structured name space and data associated with the names. Conceptually, each node and leaf of the domain name space tree names a set of information, and query operations are attempts to extract specific types of information from a particular set. A query names the domain name of interest and describes the type of resource information that is desired. For example, the Internet uses some of its domain names to identify hosts; queries for address resources return Internet host addresses.
域名空间和资源记录，它们是树结构名称空间和与名称相关的数据的规范。 从概念上讲，域名空间树的每个节点和叶子命名了一组信息，而查询操作是尝试从特定集合中提取特定类型的信息。 查询命名感兴趣的域名并描述所需的资源信息的类型。 例如，互联网使用一些域名来识别主机； 地址资源查询返回互联网主机地址。NAME SERVERS are server programs which hold information about the domain tree’s structure and set information. A name server may cache structure or set information about any part of the domain tree, but in general a particular name server has complete information about a subset of the domain space, and pointers to other name servers that can be used to lead to information from any part of the domain tree. Name servers know the parts of the domain tree for which they have complete information; a name server is said to be an AUTHORITY for these parts of the name space. Authoritative information is organized into units called ZONEs, and these zones can be automatically distributed to the name servers which provide redundant service for the data in a zone.
名称服务器是保存有关域树结构和设置信息的服务器程序。 名称服务器可以缓存有关域树任何部分的结构或设置信息，但通常特定的名称服务器具有有关域空间子集的完整信息，以及指向其他名称服务器的指针，这些指针可用于从 域树的任何部分。 名称服务器知道域树中它们拥有完整信息的部分； 名称服务器被认为是名称空间这些部分的权威。 权威信息被组织成称为“区域”的单元，这些区域可以自动分发到为区域中的数据提供冗余服务的名称服务器。RESOLVERS are programs that extract information from name servers in response to client requests. Resolvers must be able to access at least one name server and use that name server’s information to answer a query directly, or pursue the query using referrals to other name servers. A resolver will typically be a system routine that is directly accessible to user programs; hence no protocol is necessary between the resolver and the user program.
解析器是从名称服务器中提取信息以响应客户端请求的程序。 解析器必须能够访问至少一个名称服务器并使用该名称服务器的信息直接回答查询，或者使用对其他名称服务器的引用来执行查询。 解析器通常是用户程序可以直接访问的系统例程； 因此解析器和用户程序之间不需要任何协议。
These three components roughly correspond to the three layers or views of the domain system:
这三个组件大致对应于领域系统的三个层或视图：
From the user’s point of view, the domain system is accessed through a simple procedure or OS call to a local resolver. The domain space consists of a single tree and the user can request information from any section of the tree.
从用户的角度来看，域系统是通过简单的过程或操作系统调用本地解析器来访问的。 域空间由一棵树组成，用户可以从树的任何部分请求信息。From the resolver’s point of view, the domain system is composed of an unknown number of name servers. Each name server has one or more pieces of the whole domain tree’s data, but the resolver views each of these databases as essentially static.
从解析器的角度来看，域系统由未知数量的名称服务器组成。 每个名称服务器都有整个域树的一个或多个数据，但解析器将每个数据库视为本质上静态的。From a name server’s point of view, the domain system consists of separate sets of local information called zones. The name server has local copies of some of the zones. The name server must periodically refresh its zones from master copies in local files or foreign name servers. The name server must concurrently process queries that arrive from resolvers.
从名称服务器的角度来看，域系统由称为区域的独立本地信息集组成。 名称服务器具有某些区域的本地副本。 名称服务器必须定期从本地文件或外部名称服务器中的主副本刷新其区域。 名称服务器必须同时处理来自解析器的查询。
In the interests of performance, implementations may couple these functions. For example, a resolver on the same machine as a name server might share a database consisting of the the zones managed by the name server and the cache managed by the resolver.
为了性能的考虑，实现可以耦合这些功能。 例如，与名称服务器位于同一计算机上的解析器可能共享一个数据库，该数据库由名称服务器管理的区域和解析器管理的缓存组成。
3. DOMAIN NAME SPACE and RESOURCE RECORDS(域名空间和资源记录)
3.1. Name space specifications and terminology(命名空间规范和术语)
The domain name space is a tree structure. Each node and leaf on the tree corresponds to a resource set (which may be empty). The domain system makes no distinctions between the uses of the interior nodes and leaves, and this memo uses the term “node” to refer to both.
域名空间是一个树形结构。 树上的每个节点和叶子对应一个资源集（可能为空）。 域系统对内部节点和叶子的使用没有区别，本备忘录使用术语“节点”来指代两者。
Each node has a label, which is zero to 63 octets in length. Brother nodes may not have the same label, although the same label can be used for nodes which are not brothers. One label is reserved, and that is the null (i.e., zero length) label used for the root.
每个节点都有一个标签，长度为 0~63 个字节。 兄弟节点可能不具有相同的标签，尽管相同的标签可以用于非兄弟的节点。 保留一个标签，即用于根的空（即零长度）标签。
The domain name of a node is the list of the labels on the path from the node to the root of the tree. By convention, the labels that compose a domain name are printed or read left to right, from the most specific (lowest, farthest from the root) to the least specific (highest, closest to the root).
节点的域名是从该节点到树根的路径上的标签列表。 按照惯例，组成域名的标签是从左到右打印或读取的，从最具体的（最低的，距离根最远的）到最不具体的（最高的，最接近根的）。
Internally, programs that manipulate domain names should represent them as sequences of labels, where each label is a length octet followed by an octet string. Because all domain names end at the root, which has a null string for a label, these internal representations can use a length byte of zero to terminate a domain name.
在内部，操作域名的程序应将它们表示为标签序列，其中每个标签是一个长度八位位组，后跟一个八位位组字符串。 由于所有域名都以根结尾，并且其标签为空字符串，因此这些内部表示可以使用长度为零的字节来终止域名。
By convention, domain names can be stored with arbitrary case, but domain name comparisons for all present domain functions are done in a case-insensitive manner, assuming an ASCII character set, and a high order zero bit. This means that you are free to create a node with label “A” or a node with label “a”, but not both as brothers; you could refer to either using “a” or “A”. When you receive a domain name or label, you should preserve its case. The rationale for this choice is that we may someday need to add full binary domain names for new services; existing services would not be changed.
按照惯例，域名可以任意大小写存储，但所有现有域函数的域名比较都是以不区分大小写的方式完成的，假设使用 ASCII 字符集和高阶零位。 这意味着您可以自由创建标签为“A”的节点或标签为“a”的节点，但不能两者都是兄弟； 您可以参考使用“a”或“A”。 当您收到域名或标签时，应保留其大小写。 这种选择的理由是，有一天我们可能需要为新服务添加完整的二进制域名； 现有服务不会改变。
When a user needs to type a domain name, the length of each label is omitted and the labels are separated by dots (“.”). Since a complete domain name ends with the root label, this leads to a printed form which ends in a dot. We use this property to distinguish between:
当用户需要输入域名时，每个标签的长度被省略，并且标签之间用点（“.”）分隔。 由于完整的域名以根标签结尾，因此这会导致打印形式以点结尾。 我们使用这个属性来区分：
a character string which represents a complete domain name (often called “absolute”). For example, “poneria.ISI.EDU.”
代表完整域名的字符串（通常称为“绝对”）。 例如，“poneria.ISI.EDU”。a character string that represents the starting labels of a domain name which is incomplete, and should be completed by local software using knowledge of the local domain (often called “relative”). For example, “poneria” used in the ISI.EDU domain.
表示域名起始标签的字符串，该字符串不完整，应由本地软件使用本地域的知识（通常称为“相对”）来完成。 例如，ISI.EDU 域中使用的“poneria”。
Relative names are either taken relative to a well known origin, or to a list of domains used as a search list. Relative names appear mostly at the user interface, where their interpretation varies from implementation to implementation, and in master files, where they are relative to a single origin domain name. The most common interpretation uses the root “.” as either the single origin or as one of the members of the search list, so a multi-label relative name is often one where the trailing dot has been omitted to save typing.
相对名称要么相对于众所周知的来源，要么相对于用作搜索列表的域列表。 相对名称主要出现在用户界面中，其中它们的解释因实现而异，并且出现在主文件中，其中它们与单个原始域名相关。 最常见的解释是使用词根“.”。 作为单一来源或作为搜索列表的成员之一，因此多标签相对名称通常是省略尾随点以节省输入的名称。
To simplify implementations, the total number of octets that represent a domain name (i.e., the sum of all label octets and label lengths) is limited to 255.
为了简化实现，表示域名的八位字节总数（即所有标签八位字节和标签长度的总和）限制为 255。
A domain is identified by a domain name, and consists of that part of the domain name space that is at or below the domain name which specifies the domain. A domain is a subdomain of another domain if it is contained within that domain. This relationship can be tested by seeing if the subdomain’s name ends with the containing domain’s name. For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and “ “.
域由域名标识，并且由域名空间中位于或低于指定该域的域名的部分组成。 如果一个域包含在另一个域中，则该域是另一个域的子域。 可以通过查看子域的名称是否以包含域的名称结尾来测试这种关系。 例如，A.B.C.D 是 B.C.D、C.D、D 和“ ”的子域。
3.2. Administrative guidelines on use(使用管理指南)
As a matter of policy, the DNS technical specifications do not mandate a particular tree structure or rules for selecting labels; its goal is to be as general as possible, so that it can be used to build arbitrary applications. In particular, the system was designed so that the name space did not have to be organized along the lines of network boundaries, name servers, etc. The rationale for this is not that the name space should have no implied semantics, but rather that the choice of implied semantics should be left open to be used for the problem at hand, and that different parts of the tree can have different implied semantics. For example, the IN-ADDR.ARPA domain is organized and distributed by network and host address because its role is to translate from network or host numbers to names; NetBIOS domains [RFC-1001, RFC-1002] are flat because that is appropriate for that application.
However, there are some guidelines that apply to the “normal” parts of the name space used for hosts, mailboxes, etc., that will make the name space more uniform, provide for growth, and minimize problems as software is converted from the older host table. The political decisions about the top levels of the tree originated in RFC-920. Current policy for the top levels is discussed in [RFC-1032]. MILNET conversion issues are covered in [RFC-1031].
然而，有一些准则适用于用于主机、邮箱等的名称空间的“正常”部分，这些准则将使名称空间更加统一、提供增长并最大限度地减少软件从旧版本转换时出现的问题。 主机表。 有关树顶层的政治决策源自 RFC-920。 [RFC-1032] 中讨论了当前针对高层的政策。 [RFC-1031] 中涵盖了 MILNET 转换问题。
Lower domains which will eventually be broken into multiple zones should provide branching at the top of the domain so that the eventual decomposition can be done without renaming. Node labels which use special characters, leading digits, etc., are likely to break older software which depends on more restrictive choices.
最终将被分成多个区域的较低域应该在域的顶部提供分支，以便最终可以在不重命名的情况下完成分解。 使用特殊字符、前导数字等的节点标签可能会破坏依赖于更严格选择的旧软件。
3.3. Technical guidelines on use(使用技术指南)
Before the DNS can be used to hold naming information for some kind of object, two needs must be met:
在 DNS 可用于保存某种对象的命名信息之前，必须满足两个需求：
A convention for mapping between object names and domain names. This describes how information about an object is accessed.
对象名称和域名之间映射的约定。 这描述了如何访问有关对象的信息。RR types and data formats for describing the object.
用于描述对象的RR类型和数据格式。
These rules can be quite simple or fairly complex. Very often, the designer must take into account existing formats and plan for upward compatibility for existing usage. Multiple mappings or levels of mapping may be required.
这些规则可以非常简单，也可以非常复杂。 很多时候，设计者必须考虑现有格式并规划现有用途的向上兼容性。 可能需要多个映射或映射级别。
For hosts, the mapping depends on the existing syntax for host names which is a subset of the usual text representation for domain names, together with RR formats for describing host addresses, etc. Because we need a reliable inverse mapping from address to host name, a special mapping for addresses into the IN-ADDR.ARPA domain is also defined.
对于主机，映射取决于主机名的现有语法，主机名是常用文本表示形式的子集，以及用于描述主机地址的 RR 格式等。因为我们需要从地址到主机名的可靠逆映射， 还定义了地址到 IN-ADDR.ARPA 域的特殊映射。
For mailboxes, the mapping is slightly more complex. The usual mail address
对于邮箱，映射稍微复杂一些。 通常的邮件地址
The typical user is not concerned with defining these rules, but should understand that they usually are the result of numerous compromises between desires for upward compatibility with old usage, interactions between different object definitions, and the inevitable urge to add new features when defining the rules. The way the DNS is used to support some object is often more crucial than the restrictions inherent in the DNS.
典型的用户不关心定义这些规则，但应该理解，它们通常是与旧用法向上兼容的愿望、不同对象定义之间的交互以及定义规则时不可避免地添加新功能的冲动之间众多妥协的结果 。 DNS 用于支持某些对象的方式通常比 DNS 固有的限制更为重要。
3.4. Example name space(命名空间示例)
The following figure shows a part of the current domain name space, and is used in many examples in this RFC. Note that the tree is a very small subset of the actual name space.
下图显示了当前域名空间的一部分，并在本 RFC 的许多示例中使用。 请注意，树是实际名称空间的一个非常小的子集。
1 | |
In this example, the root domain has three immediate subdomains: MIL, EDU, and ARPA. The LCS.MIT.EDU domain has one immediate subdomain named XX.LCS.MIT.EDU. All of the leaves are also domains.
在此示例中，根域具有三个直接子域：MIL、EDU 和 ARPA。 LCS.MIT.EDU 域有一个名为 XX.LCS.MIT.EDU 的直接子域。 所有的叶子也是域。
3.5. Preferred name syntax(首选名称语法)
The DNS specifications attempt to be as general as possible in the rules for constructing domain names. The idea is that the name of any existing object can be expressed as a domain name with minimal changes. However, when assigning a domain name for an object, the prudent user will select a name which satisfies both the rules of the domain system and any existing rules for the object, whether these rules are published or implied by existing programs.
DNS 规范试图在构建域名的规则中尽可能通用。 这个想法是任何现有对象的名称都可以表示为域名，只需进行最少的更改。 然而，当为对象分配域名时，谨慎的用户将选择既满足域系统的规则又满足该对象的任何现有规则的名称，无论这些规则是公开的还是由现有程序暗示的。
For example, when naming a mail domain, the user should satisfy both the rules of this memo and those in RFC-822. When creating a new host name, the old rules for HOSTS.TXT should be followed. This avoids problems when old software is converted to use domain names.
例如，在命名邮件域时，用户应同时满足本备忘录的规则和RFC-822中的规则。创建新主机名时，应遵循 HOSTS.TXT 的旧规则。 这可以避免旧软件转换为使用域名时出现问题。
The following syntax will result in fewer problems with many applications that use domain names (e.g., mail, TELNET).
以下语法将减少许多使用域名的应用程序（例如邮件、TELNET）的问题。
1 | |
Note that while upper and lower case letters are allowed in domain names, no significance is attached to the case. That is, two names with the same spelling but different case are to be treated as if identical.
请注意，虽然域名中允许使用大小写字母，但大小写没有任何意义。 也就是说，拼写相同但大小写不同的两个名称将被视为相同。
The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less.
标签必须遵循 ARPANET 主机名的规则。 它们必须以字母开头，以字母或数字结尾，并且内部字符只能是字母、数字和连字符。 长度也有一些限制。 标签不得超过 63 个字符。
For example, the following strings identify hosts in the Internet:
例如，以下字符串标识 Internet 中的主机：
A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
3.6. Resource Records(资源记录)
A domain name identifies a node. Each node has a set of resource information, which may be empty. The set of resource information associated with a particular name is composed of separate resource records (RRs). The order of RRs in a set is not significant, and need not be preserved by name servers, resolvers, or other parts of the DNS.
一个域名标识一个节点。 每个节点都有一组资源信息，该信息可能为空。 与特定名称关联的资源信息集由单独的资源记录 (RR) 组成。 集合中 RR 的顺序并不重要，并且不需要由名称服务器、解析器或 DNS 的其他部分保存。
When we talk about a specific RR, we assume it has the following:
当我们谈论特定的 RR 时，我们假设它具有以下内容：
1 | |
The owner name is often implicit, rather than forming an integral part of the RR. For example, many name servers internally form tree or hash structures for the name space, and chain RRs off nodes. The remaining RR parts are the fixed header (type, class, TTL) which is consistent for all RRs, and a variable part (RDATA) that fits the needs of the resource being described.
所有者名称通常是隐含的，而不是形成 RR 的组成部分。 例如，许多名称服务器在内部形成名称空间的树形或散列结构，并将 RR 链接到节点上。 其余的 RR 部分是对所有 RR 一致的固定标头（类型、类、TTL）和适合所描述资源的需要的可变部分（RDATA）。
The meaning of the TTL field is a time limit on how long an RR can be kept in a cache. This limit does not apply to authoritative data in zones; it is also timed out, but by the refreshing policies for the zone. The TTL is assigned by the administrator for the zone where the data originates. While short TTLs can be used to minimize caching, and a zero TTL prohibits caching, the realities of Internet performance suggest that these times should be on the order of days for the typical host. If a change can be anticipated, the TTL can be reduced prior to the change to minimize inconsistency during the change, and then increased back to its former value following the change.
TTL字段的含义是限制RR在缓存中保存的时间。 此限制不适用于区域内的权威数据； 它也超时了，但是由于该区域的刷新策略。 TTL 由数据来源区域的管理员分配。 虽然短 TTL 可用于最大程度地减少缓存，而 TTL 为0则禁止缓存，但 Internet 性能的实际情况表明，对于典型主机来说，这些时间应为几天左右。 如果可以预期发生更改，则可以在更改之前减小 TTL，以最大程度地减少更改期间的不一致，然后在更改后将其恢复到之前的值。
The data in the RDATA section of RRs is carried as a combination of binary strings and domain names. The domain names are frequently used as “pointers” to other data in the DNS.
RR 的 RDATA 部分中的数据以二进制字符串和域名的组合形式传送。 域名经常用作指向 DNS 中其他数据的“指针”。
3.6.1. Textual expression of RRs(RR 的文本表达)
RRs are represented in binary form in the packets of the DNS protocol,
and are usually represented in highly encoded form when stored in a name
server or resolver. In this memo, we adopt a style similar to that used
in master files in order to show the contents of RRs. In this format,
most RRs are shown on a single line, although continuation lines are
possible using parentheses.
The start of the line gives the owner of the RR. If a line begins with
a blank, then the owner is assumed to be the same as that of the
previous RR. Blank lines are often included for readability.
Following the owner, we list the TTL, type, and class of the RR. Class
and type use the mnemonics defined above, and TTL is an integer before
the type field. In order to avoid ambiguity in parsing, type and class
mnemonics are disjoint, TTLs are integers, and the type mnemonic is
always last. The IN class and TTL values are often omitted from examples
in the interests of clarity.
The resource data or RDATA section of the RR are given using knowledge
of the typical representation for the data.
For example, we might show the RRs carried in a message as:
1 | |
The MX RRs have an RDATA section which consists of a 16 bit number
followed by a domain name. The address RRs use a standard IP address
format to contain a 32 bit internet address.
This example shows six RRs, with two RRs at each of three domain names.
Similarly we might see:
1 | |
This example shows two addresses for XX.LCS.MIT.EDU, each of a different
class.
3.6.2. Aliases and canonical names(别名和规范名称)
In existing systems, hosts and other resources often have several names that identify the same resource. For example, the names C.ISI.EDU and USC-ISIC.ARPA both identify the same host. Similarly, in the case of mailboxes, many organizations provide many names that actually go to the same mailbox; for example Mockapetris@C.ISI.EDU, Mockapetris@B.ISI.EDU, and PVM@ISI.EDU all go to the same mailbox (although the mechanism behind this is somewhat complicated).
在现有系统中，主机和其他资源通常有多个名称来标识同一资源。 例如，名称 C.ISI.EDU 和 USC-ISIC.ARPA 都标识同一主机。 同样，就邮箱而言，许多组织提供了许多实际上发送到同一个邮箱的名称； 例如，Mockapetris@C.ISI.EDU、Mockapetris@B.ISI.EDU 和 PVM@ISI.EDU 都发送到同一个邮箱（尽管其背后的机制有些复杂）。
Most of these systems have a notion that one of the equivalent set of names is the canonical or primary name and all others are aliases.
这些系统中的大多数都有一个概念，即等效名称集之一是规范名称或主要名称，所有其他名称都是别名。
The domain system provides such a feature using the canonical name (CNAME) RR. A CNAME RR identifies its owner name as an alias, and specifies the corresponding canonical name in the RDATA section of the RR. If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different. This rule also insures that a cached CNAME can be used without checking with an authoritative server for other RR types.
域系统使用规范名称 (CNAME) RR 提供此类功能。 CNAME RR 将其所有者名称标识为别名，并在 RR 的 RDATA 部分中指定相应的规范名称。 如果节点上存在 CNAME RR，则不应存在其他数据； 这确保规范名称及其别名的数据不能不同。 此规则还确保可以使用缓存的 CNAME，而无需与权威服务器检查其他 RR 类型。
CNAME RRs cause special action in DNS software. When a name server fails to find a desired RR in the resource set associated with the domain name, it checks to see if the resource set consists of a CNAME record with a matching class. If so, the name server includes the CNAME record in the response and restarts the query at the domain name specified in the data field of the CNAME record. The one exception to this rule is that queries which match the CNAME type are not restarted.
CNAME RR 会导致 DNS 软件采取特殊操作。 当名称服务器无法在与域名关联的资源集中找到所需的 RR 时，它会检查该资源集是否包含具有匹配类的 CNAME 记录。 如果是，则名称服务器在响应中包含 CNAME 记录，并在 CNAME 记录的数据字段中指定的域名重新启动查询。 此规则的一个例外是与 CNAME 类型匹配的查询不会重新启动。
For example, suppose a name server was processing a query with for USC-ISIC.ARPA, asking for type A information, and had the following resource records:
例如，假设名称服务器正在处理 USC-ISIC.ARPA 的查询，请求类型 A 信息，并具有以下资源记录：
1 | |
Both of these RRs would be returned in the response to the type A query, while a type CNAME or * query should return just the CNAME.
这两个 RR 都将在 A 类型查询的响应中返回，而 CNAME 或 * 类型查询应仅返回 CNAME。
Domain names in RRs which point at another name should always point at the primary name and not the alias. This avoids extra indirections in accessing information. For example, the address to name RR for the above host should be:
RR 中指向另一个名称的域名应始终指向(ptr记录)主名称而不是别名。 这避免了访问信息时的额外间接。 例如，上述主机的名为 RR 的地址应为：
1 | |
rather than pointing at USC-ISIC.ARPA. Of course, by the robustness principle, domain software should not fail when presented with CNAME chains or loops; CNAME chains should be followed and CNAME loops signalled as an error.
而不是指向 USC-ISIC.ARPA。 当然，根据稳健性原则，域软件在出现 CNAME 链或循环时不应失败； 应遵循 CNAME 链，并将 CNAME 循环标记为错误。
3.7. Queries
Queries are messages which may be sent to a name server to provoke a
response. In the Internet, queries are carried in UDP datagrams or over
TCP connections. The response by the name server either answers the
question posed in the query, refers the requester to another set of name
servers, or signals some error condition.
In general, the user does not generate queries directly, but instead
makes a request to a resolver which in turn sends one or more queries to
name servers and deals with the error conditions and referrals that may
result. Of course, the possible questions which can be asked in a query
does shape the kind of service a resolver can provide.
DNS queries and responses are carried in a standard message format. The
message format has a header containing a number of fixed fields which
are always present, and four sections which carry query parameters and
RRs.
The most important field in the header is a four bit field called an
opcode which separates different queries. Of the possible 16 values,
one (standard query) is part of the official protocol, two (inverse
query and status query) are options, one (completion) is obsolete, and
the rest are unassigned.
The four sections are:
1 | |
Note that the content, but not the format, of these sections varies with
header opcode.
3.7.1. Standard queries
A standard query specifies a target domain name (QNAME), query type
(QTYPE), and query class (QCLASS) and asks for RRs which match. This
type of query makes up such a vast majority of DNS queries that we use
the term “query” to mean standard query unless otherwise specified. The
QTYPE and QCLASS fields are each 16 bits long, and are a superset of
defined types and classes.
The QTYPE field may contain:
1 | |
Using the query domain name, QTYPE, and QCLASS, the name server looks
for matching RRs. In addition to relevant records, the name server may
return RRs that point toward a name server that has the desired
information or RRs that are expected to be useful in interpreting the
relevant RRs. For example, a name server that doesn’t have the
requested information may know a name server that does; a name server
that returns a domain name in a relevant RR may also return the RR that
binds that domain name to an address.
For example, a mailer tying to send mail to Mockapetris@ISI.EDU might
ask the resolver for mail information about ISI.EDU, resulting in a
query for QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN. The response’s answer
section would be:
1 | |
while the additional section might be:
1 | |
Because the server assumes that if the requester wants mail exchange
information, it will probably want the addresses of the mail exchanges
soon afterward.
Note that the QCLASS=* construct requires special interpretation
regarding authority. Since a particular name server may not know all of
the classes available in the domain system, it can never know if it is
authoritative for all classes. Hence responses to QCLASS=* queries can
never be authoritative.
3.7.2. Inverse queries (Optional)(反向查询（可选）)
Name servers may also support inverse queries that map a particular resource to a domain name or domain names that have that resource. For example, while a standard query might map a domain name to a SOA RR, the corresponding inverse query might map the SOA RR back to the domain name.
名称服务器还可以支持将特定资源映射到具有该资源的一个或多个域名的反向查询。 例如，虽然标准查询可能将域名映射到 SOA RR，但相应的逆查询可能将 SOA RR 映射回域名。
Implementation of this service is optional in a name server, but all name servers must at least be able to understand an inverse query message and return a not-implemented error response.
在名称服务器中，此服务的实现是可选的，但所有名称服务器必须至少能够理解反向查询消息并返回未实现的错误响应。
The domain system cannot guarantee the completeness or uniqueness of inverse queries because the domain system is organized by domain name rather than by host address or any other resource type. Inverse queries are primarily useful for debugging and database maintenance activities.
域系统不能保证逆向查询的完整性或唯一性，因为域系统是按域名而不是按主机地址或任何其他资源类型组织的。 反向查询主要用于调试和数据库维护活动。
Inverse queries may not return the proper TTL, and do not indicate cases where the identified RR is one of a set (for example, one address for a host having multiple addresses). Therefore, the RRs returned in inverse queries should never be cached.
反向查询可能不会返回正确的 TTL，并且不会指示所识别的 RR 是一组中的一个的情况（例如，具有多个地址的主机的一个地址）。 因此，在反向查询中返回的 RR 永远不应该被缓存。
Inverse queries are NOT an acceptable method for mapping host addresses to host names; use the IN-ADDR.ARPA domain instead.
反向查询不是将主机地址映射到主机名的可接受的方法； 请改用 IN-ADDR.ARPA 域。
A detailed discussion of inverse queries is contained in [RFC-1035].
反向查询的详细讨论包含在 [RFC-1035] 中。
3.8. Status queries (Experimental) (实验性的状态查询)
To be defined.
3.9. Completion queries (Obsolete)
The optional completion services described in RFCs 882 and 883 have been
deleted. Redesigned services may become available in the future, or the
opcodes may be reclaimed for other use.
4. NAME SERVERS(名称服务器)
4.1. Introduction(介绍)
Name servers are the repositories of information that make up the domain database. The database is divided up into sections called zones, which are distributed among the name servers. While name servers can have several optional functions and sources of data, the essential task of a name server is to answer queries using data in its zones. By design, name servers can answer queries in a simple manner; the response can always be generated using only local data, and either contains the answer to the question or a referral to other name servers “closer” to the desired information.
名称服务器是构成域数据库的信息存储库。 数据库被分为称为区域的部分，这些部分分布在名称服务器之间。 虽然名称服务器可以具有多种可选功能和数据源，但名称服务器的基本任务是使用其区域中的数据来回答查询。 按照设计，名称服务器可以以简单的方式回答查询； 响应始终可以仅使用本地数据生成，并且包含问题的答案或对“更接近”所需信息的其他名称服务器的引用。
A given zone will be available from several name servers to insure its availability in spite of host or communication link failure. By administrative fiat, we require every zone to be available on at least two servers, and many zones have more redundancy than that.
尽管主机或通信链路发生故障，给定区域仍可从多个名称服务器获得，以确保其可用性。 根据管理命令，我们要求每个区域在至少两台服务器上可用，并且许多区域具有比这更多的冗余。
A given name server will typically support one or more zones, but this gives it authoritative information about only a small section of the domain tree. It may also have some cached non-authoritative data about other parts of the tree. The name server marks its responses to queries so that the requester can tell whether the response comes from authoritative data or not.
给定的名称服务器通常支持一个或多个区域，但这仅为其提供有关域树的一小部分的权威信息。 它还可能有一些关于树其他部分的缓存非权威数据。 名称服务器标记其对查询的响应，以便请求者可以判断响应是否来自权威数据。
4.2. How the database is divided into zones(数据库是怎么拆分为区域的)
The domain database is partitioned in two ways: by class, and by “cuts” made in the name space between nodes.
域数据库以两种方式分区：按class分区，以及按节点间的名称空间中的”cuts”分区。
The class partition is simple. The database for any class is organized, delegated, and maintained separately from all other classes. Since, by convention, the name spaces are the same for all classes, the separate classes can be thought of as an array of parallel namespace trees. Note that the data attached to nodes will be different for these different parallel classes. The most common reasons for creating a new class are the necessity for a new data format for existing types or a desire for a separately managed version of the existing name space.
class划分很简单。 任何class的数据库都是与所有其他class分开组织、委托和维护的。 由于按照惯例，所有class的名称空间都是相同的，因此可以将单独的类视为并行名称空间树的数组。 请注意，对于这些不同的并行class，附加到节点的数据将有所不同。 创建新class的最常见原因是现有类型需要新的数据格式或需要现有名称空间的单独管理版本。
Within a class, “cuts” in the name space can be made between any two adjacent nodes. After all cuts are made, each group of connected name space is a separate zone. The zone is said to be authoritative for all names in the connected region. Note that the “cuts” in the name space may be in different places for different classes, the name servers may be different, etc.
在class中，可以在任意两个相邻节点之间进行名称空间的”cuts”。 完成所有切割后，每组连接的名称空间都是一个单独的区域。 据说该区域对所连接区域中的所有名称具有权威性。 请注意，名称空间中的”cuts”对于不同的类可能位于不同的位置，名称服务器可能不同，等等。
These rules mean that every zone has at least one node, and hence domain name, for which it is authoritative, and all of the nodes in a particular zone are connected. Given, the tree structure, every zone has a highest node which is closer to the root than any other node in the zone. The name of this node is often used to identify the zone.
这些规则意味着每个区域至少有一个节点，因此也有一个具有权威的域名，并且特定区域中的所有节点都是连接的。 鉴于树结构，每个区域都有一个最高节点，该节点比该区域中的任何其他节点更接近根。 该节点的名称通常用于标识区域。
It would be possible, though not particularly useful, to partition the name space so that each domain name was in a separate zone or so that all nodes were in a single zone. Instead, the database is partitioned at points where a particular organization wants to take over control of a subtree. Once an organization controls its own zone it can unilaterally change the data in the zone, grow new tree sections connected to the zone, delete existing nodes, or delegate new subzones under its zone.
尽管不是特别有用，但可以对名称空间进行分区，以便每个域名位于单独的区域中，或者使所有节点位于单个区域中。 相反，数据库在特定组织想要接管子树控制权的点上进行分区。 一旦组织控制了自己的区域，它就可以单方面更改区域中的数据、生成连接到该区域的新树部分、删除现有节点或在其区域下委派新的子区域。
If the organization has substructure, it may want to make further internal partitions to achieve nested delegations of name space control. In some cases, such divisions are made purely to make database maintenance more convenient.
如果组织有子结构，它可能希望进行进一步的内部分区以实现名称空间控制的嵌套委托。 在某些情况下，这样的划分纯粹是为了使数据库维护更加方便。
4.2.1. Technical considerations(技术上的考虑)
The data that describes a zone has four major parts:
描述区域的数据有四个主要部分：
- Authoritative data for all nodes within the zone.
区域内所有节点的权威数据。
- Data that defines the top node of the zone (can be thought of as part of the authoritative data).
定义区域顶部节点的数据（可以认为是权威数据的一部分）。
- Data that describes delegated subzones, i.e., cuts around the bottom of the zone.
描述委托子区域的数据，即围绕区域底部的切割。
- Data that allows access to name servers for subzones (sometimes called “glue” data).
允许访问子区域的名称服务器的数据（有时称为”glue”数据）。
All of this data is expressed in the form of RRs, so a zone can be
completely described in terms of a set of RRs. Whole zones can be
transferred between name servers by transferring the RRs, either carried
in a series of messages or by FTPing a master file which is a textual
representation.
The authoritative data for a zone is simply all of the RRs attached to
all of the nodes from the top node of the zone down to leaf nodes or
nodes above cuts around the bottom edge of the zone.
Though logically part of the authoritative data, the RRs that describe
the top node of the zone are especially important to the zone’s
management. These RRs are of two types: name server RRs that list, one
per RR, all of the servers for the zone, and a single SOA RR that
describes zone management parameters.
The RRs that describe cuts around the bottom of the zone are NS RRs that
name the servers for the subzones. Since the cuts are between nodes,
these RRs are NOT part of the authoritative data of the zone, and should
be exactly the same as the corresponding RRs in the top node of the
subzone. Since name servers are always associated with zone boundaries,
NS RRs are only found at nodes which are the top node of some zone. In
the data that makes up a zone, NS RRs are found at the top node of the
zone (and are authoritative) and at cuts around the bottom of the zone
(where they are not authoritative), but never in between.
One of the goals of the zone structure is that any zone have all the
data required to set up communications with the name servers for any
subzones. That is, parent zones have all the information needed to
access servers for their children zones. The NS RRs that name the
servers for subzones are often not enough for this task since they name
the servers, but do not give their addresses. In particular, if the
name of the name server is itself in the subzone, we could be faced with
the situation where the NS RRs tell us that in order to learn a name
server’s address, we should contact the server using the address we wish
to learn. To fix this problem, a zone contains “glue” RRs which are not
part of the authoritative data, and are address RRs for the servers.
These RRs are only necessary if the name server’s name is “below” the
cut, and are only used as part of a referral response.
4.2.2. Administrative considerations(管理上的考虑)
When some organization wants to control its own domain, the first step
is to identify the proper parent zone, and get the parent zone’s owners
to agree to the delegation of control. While there are no particular
technical constraints dealing with where in the tree this can be done,
there are some administrative groupings discussed in [RFC-1032] which
deal with top level organization, and middle level zones are free to
create their own rules. For example, one university might choose to use
a single zone, while another might choose to organize by subzones
dedicated to individual departments or schools. [RFC-1033] catalogs
available DNS software an discusses administration procedures.
Once the proper name for the new subzone is selected, the new owners
should be required to demonstrate redundant name server support. Note
that there is no requirement that the servers for a zone reside in a
host which has a name in that domain. In many cases, a zone will be
more accessible to the internet at large if its servers are widely
distributed rather than being within the physical facilities controlled
by the same organization that manages the zone. For example, in the
current DNS, one of the name servers for the United Kingdom, or UK
domain, is found in the US. This allows US hosts to get UK data without
using limited transatlantic bandwidth.
As the last installation step, the delegation NS RRs and glue RRs
necessary to make the delegation effective should be added to the parent
zone. The administrators of both zones should insure that the NS and
glue RRs which mark both sides of the cut are consistent and remain so.
4.3. Name server internals (名称服务器内部结构)
4.3.1. Queries and responses (查询和应答)
The principal activity of name servers is to answer standard queries.
Both the query and its response are carried in a standard message format
which is described in [RFC-1035]. The query contains a QTYPE, QCLASS,
and QNAME, which describe the types and classes of desired information
and the name of interest.
The way that the name server answers the query depends upon whether it
is operating in recursive mode or not:
名称服务器回答查询的方式取决于它是否以递归模式运行：
The simplest mode for the server is non-recursive, since it
can answer queries using only local information: the response
contains an error, the answer, or a referral to some other
server “closer” to the answer. All name servers must
implement non-recursive queries.The simplest mode for the client is recursive, since in this
mode the name server acts in the role of a resolver and
returns either an error or the answer, but never referrals.
This service is optional in a name server, and the name server
may also choose to restrict the clients which can use
recursive mode.
Recursive service is helpful in several situations:
递归服务在多种情况下很有用：
- a relatively simple requester that lacks the ability to use anything other than a direct answer to the question.
相对简单的请求者，除了直接回答问题之外无法使用任何其他内容。
- a request that needs to cross protocol or other boundaries and can be sent to a server which can act as intermediary.
需要跨越协议或其他边界并且可以发送到可以充当中介的服务器的请求。
- a network where we want to concentrate the cache rather than having a separate cache for each client.
我们希望集中缓存而不是为每个客户端提供单独的缓存的网络。
Non-recursive service is appropriate if the requester is capable of pursuing referrals and interested in information which will aid future requests.
如果请求者能够寻求推荐并且对有助于未来请求的信息感兴趣，则非递归服务是合适的。
The use of recursive mode is limited to cases where both the client and the name server agree to its use. The agreement is negotiated through the use of two bits in query and response messages:
递归模式的使用仅限于客户端和名称服务器都同意其使用的情况。 该协议是通过使用查询和响应消息中的两个位来协商的：
- The recursion available, or RA bit, is set or cleared by a name server in all responses. The bit is true if the name server is willing to provide recursive service for the client, regardless of whether the client requested recursive service. That is, RA signals availability rather than use.
可用递归或 RA 位由名称服务器在所有响应中设置或清除。 如果名称服务器愿意为客户端提供递归服务，则该位为真，无论客户端是否请求递归服务。也就是说，RA 表示可用性而不是使用。
- Queries contain a bit called recursion desired or RD. This bit specifies specifies whether the requester wants recursive service for this query. Clients may request recursive service from any name server, though they should depend upon receiving it only from servers which have previously sent an RA, or servers which have agreed to provide service through private agreement or some other means outside of the DNS protocol.
查询包含一个称为所需递归或 RD 的位。 该位指定请求者是否希望为此查询提供递归服务。 客户端可以从任何名称服务器请求递归服务，尽管它们应该依赖于仅从先前发送过 RA 的服务器或同意通过私有协议或 DNS 协议之外的其他方式提供服务的服务器接收递归服务。
The recursive mode occurs when a query with RD set arrives at a server
which is willing to provide recursive service; the client can verify
that recursive mode was used by checking that both RA and RD are set in
the reply. Note that the name server should never perform recursive
service unless asked via RD, since this interferes with trouble shooting
of name servers and their databases.
If recursive service is requested and available, the recursive response
to a query will be one of the following:
The answer to the query, possibly preface by one or more CNAME
RRs that specify aliases encountered on the way to an answer.A name error indicating that the name does not exist. This
may include CNAME RRs that indicate that the original query
name was an alias for a name which does not exist.A temporary error indication.
If recursive service is not requested or is not available, the non-
recursive response will be one of the following:
An authoritative name error indicating that the name does not
exist.A temporary error indication.
Some combination of:
RRs that answer the question, together with an indication
whether the data comes from a zone or is cached.A referral to name servers which have zones which are closer
ancestors to the name than the server sending the reply.RRs that the name server thinks will prove useful to the
requester.
4.3.2. Algorithm(算法)
The actual algorithm used by the name server will depend on the local OS and data structures used to store RRs. The following algorithm assumes that the RRs are organized in several tree structures, one for each zone, and another for the cache:
名称服务器使用的实际算法将取决于本地操作系统和用于存储 RR 的数据结构。 以下算法假设 RR 被组织成多个树结构，一个用于每个区域，另一个用于缓存：
Set or clear the value of recursion available in the response
depending on whether the name server is willing to provide
recursive service. If recursive service is available and
requested via the RD bit in the query, go to step 5,
otherwise step 2.Search the available zones for the zone which is the nearest
ancestor to QNAME. If such a zone is found, go to step 3,
otherwise step 4.Start matching down, label by label, in the zone. The
matching process can terminate several ways:a. If the whole of QNAME is matched, we have found the
node. If the data at the node is a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR into the answer section of the response, change QNAME to the canonical name in the CNAME RR, and go back to step 1. Otherwise, copy all RRs which match QTYPE into the answer section and go to step 6.b. If a match would take us out of the authoritative data,
we have a referral. This happens when we encounter a node with NS RRs marking cuts along the bottom of a zone. Copy the NS RRs for the subzone into the authority section of the reply. Put whatever addresses are available into the additional section, using glue RRs if the addresses are not available from authoritative data or the cache. Go to step 4.c. If at some label, a match is impossible (i.e., the
corresponding label does not exist), look to see if a the "*" label exists. If the "*" label does not exist, check whether the name we are looking for is the original QNAME in the query or a name we have followed due to a CNAME. If the name is original, set an authoritative name error in the response and exit. Otherwise just exit. If the "*" label does exist, match RRs at that node against QTYPE. If any match, copy them into the answer section, but set the owner of the RR to be QNAME, and not the node with the "*" label. Go to step 6.Start matching down in the cache. If QNAME is found in the
cache, copy all RRs attached to it that match QTYPE into the
answer section. If there was no delegation from
authoritative data, look for the best one from the cache, and
put it in the authority section. Go to step 6.Using the local resolver or a copy of its algorithm (see
resolver section of this memo) to answer the query. Store
the results, including any intermediate CNAMEs, in the answer
section of the response.Using local data only, attempt to add other RRs which may be
useful to the additional section of the query. Exit.
4.3.3. Wildcards(通配符)
In the previous algorithm, special treatment was given to RRs with owner
names starting with the label “*”. Such RRs are called wildcards.
Wildcard RRs can be thought of as instructions for synthesizing RRs.
When the appropriate conditions are met, the name server creates RRs
with an owner name equal to the query name and contents taken from the
wildcard RRs.
This facility is most often used to create a zone which will be used to
forward mail from the Internet to some other mail system. The general
idea is that any name in that zone which is presented to server in a
query will be assumed to exist, with certain properties, unless explicit
evidence exists to the contrary. Note that the use of the term zone
here, instead of domain, is intentional; such defaults do not propagate
across zone boundaries, although a subzone may choose to achieve that
appearance by setting up similar defaults.
The contents of the wildcard RRs follows the usual rules and formats for
RRs. The wildcards in the zone have an owner name that controls the
query names they will match. The owner name of the wildcard RRs is of
the form “.
authoritative data of the zone. The wildcards potentially apply to
descendants of
to look at this is that the “
label and sometimes more, but always whole labels.
Wildcard RRs do not apply:
When the query is in another zone. That is, delegation cancels
the wildcard defaults.When the query name or a name between the wildcard domain and
the query name is know to exist. For example, if a wildcard
RR has an owner name of “*.X”, and the zone also contains RRs
attached to B.X, the wildcards would apply to queries for name
Z.X (presuming there is no explicit information for Z.X), but
not to B.X, A.B.X, or X.
A * label appearing in a query name has no special effect, but can be
used to test for wildcards in an authoritative zone; such a query is the
only way to get a response containing RRs with an owner name with * in
it. The result of such a query should not be cached.
Note that the contents of the wildcard RRs are not modified when used to
synthesize RRs.
To illustrate the use of wildcard RRs, suppose a large company with a
large, non-IP/TCP, network wanted to create a mail gateway. If the
company was called X.COM, and IP/TCP capable gateway machine was called
A.X.COM, the following RRs might be entered into the COM zone:
1 | |
This would cause any MX query for any domain name ending in X.COM to return an MX RR pointing at A.X.COM. Two wildcard RRs are required since the effect of the wildcard at *.X.COM is inhibited in the A.X.COM subtree by the explicit data for A.X.COM. Note also that the explicit MX data at X.COM and A.X.COM is required, and that none of the RRs above would match a query name of XX.COM.
这将导致任何以 X.COM 结尾的 MX 查询都返回指向 A.X.COM 的 RR。其中的两个通配符 RR 是必要，因为 *.X.COM 处的通配符的影响在 A.X.COM 子树中被 A.X.COM 的显式数据所抑制。 另请注意，X.COM 和 A.X.COM 处的显式 MX 数据是必需的，并且以上 RR 均不会与 XX.COM 的查询名称匹配。
4.3.4. Negative response caching (Optional)(否定响应缓存)
The DNS provides an optional service which allows name servers to
distribute, and resolvers to cache, negative results with TTLs. For
example, a name server can distribute a TTL along with a name error
indication, and a resolver receiving such information is allowed to
assume that the name does not exist during the TTL period without
consulting authoritative data. Similarly, a resolver can make a query
with a QTYPE which matches multiple types, and cache the fact that some
of the types are not present.
This feature can be particularly important in a system which implements
naming shorthands that use search lists beacuse a popular shorthand,
which happens to require a suffix toward the end of the search list,
will generate multiple name errors whenever it is used.
The method is that a name server may add an SOA RR to the additional
section of a response when that response is authoritative. The SOA must
be that of the zone which was the source of the authoritative data in
the answer section, or name error if applicable. The MINIMUM field of
the SOA controls the length of time that the negative result may be
cached.
Note that in some circumstances, the answer section may contain multiple
owner names. In this case, the SOA mechanism should only be used for
the data which matches QNAME, which is the only authoritative data in
this section.
Name servers and resolvers should never attempt to add SOAs to the
additional section of a non-authoritative response, or attempt to infer
results which are not directly stated in an authoritative response.
There are several reasons for this, including: cached information isn’t
usually enough to match up RRs and their zone names, SOA RRs may be
cached due to direct SOA queries, and name servers are not required to
output the SOAs in the authority section.
This feature is optional, although a refined version is expected to
become part of the standard protocol in the future. Name servers are
not required to add the SOA RRs in all authoritative responses, nor are
resolvers required to cache negative results. Both are recommended.
All resolvers and recursive name servers are required to at least be
able to ignore the SOA RR when it is present in a response.
Some experiments have also been proposed which will use this feature.
The idea is that if cached data is known to come from a particular zone,
and if an authoritative copy of the zone’s SOA is obtained, and if the
zone’s SERIAL has not changed since the data was cached, then the TTL of
the cached data can be reset to the zone MINIMUM value if it is smaller.
This usage is mentioned for planning purposes only, and is not
recommended as yet.
4.3.5. Zone maintenance and transfers(区域维护和转移)
Part of the job of a zone administrator is to maintain the zones at all
of the name servers which are authoritative for the zone. When the
inevitable changes are made, they must be distributed to all of the name
servers. While this distribution can be accomplished using FTP or some
other ad hoc procedure, the preferred method is the zone transfer part
of the DNS protocol.
The general model of automatic zone transfer or refreshing is that one
of the name servers is the master or primary for the zone. Changes are
coordinated at the primary, typically by editing a master file for the
zone. After editing, the administrator signals the master server to
load the new zone. The other non-master or secondary servers for the
zone periodically check for changes (at a selectable interval) and
obtain new zone copies when changes have been made.
To detect changes, secondaries just check the SERIAL field of the SOA
for the zone. In addition to whatever other changes are made, the
SERIAL field in the SOA of the zone is always advanced whenever any
change is made to the zone. The advancing can be a simple increment, or
could be based on the write date and time of the master file, etc. The
purpose is to make it possible to determine which of two copies of a
zone is more recent by comparing serial numbers. Serial number advances
and comparisons use sequence space arithmetic, so there is a theoretic
limit on how fast a zone can be updated, basically that old copies must
die out before the serial number covers half of its 32 bit range. In
practice, the only concern is that the compare operation deals properly
with comparisons around the boundary between the most positive and most
negative 32 bit numbers.
The periodic polling of the secondary servers is controlled by
parameters in the SOA RR for the zone, which set the minimum acceptable
polling intervals. The parameters are called REFRESH, RETRY, and
EXPIRE. Whenever a new zone is loaded in a secondary, the secondary
waits REFRESH seconds before checking with the primary for a new serial.
If this check cannot be completed, new checks are started every RETRY
seconds. The check is a simple query to the primary for the SOA RR of
the zone. If the serial field in the secondary’s zone copy is equal to
the serial returned by the primary, then no changes have occurred, and
the REFRESH interval wait is restarted. If the secondary finds it
impossible to perform a serial check for the EXPIRE interval, it must
assume that its copy of the zone is obsolete an discard it.
When the poll shows that the zone has changed, then the secondary server
must request a zone transfer via an AXFR request for the zone. The AXFR
may cause an error, such as refused, but normally is answered by a
sequence of response messages. The first and last messages must contain
the data for the top authoritative node of the zone. Intermediate
messages carry all of the other RRs from the zone, including both
authoritative and non-authoritative RRs. The stream of messages allows
the secondary to construct a copy of the zone. Because accuracy is
essential, TCP or some other reliable protocol must be used for AXFR
requests.
Each secondary server is required to perform the following operations
against the master, but may also optionally perform these operations
against other secondary servers. This strategy can improve the transfer
process when the primary is unavailable due to host downtime or network
problems, or when a secondary server has better network access to an
“intermediate” secondary than to the primary.
5. RESOLVERS(解析器)
5.1. Introduction（介绍）
Resolvers are programs that interface user programs to domain name servers. In the simplest case, a resolver receives a request from a user program (e.g., mail programs, TELNET, FTP) in the form of a subroutine call, system call etc., and returns the desired information in a form compatible with the local host’s data formats.
解析器是将用户程序连接到域名服务器的程序。 在最简单的情况下，解析器以子程序调用、系统调用等形式接收来自用户程序（例如邮件程序、TELNET、FTP）的请求，并以与本地主机兼容形式的数据格式返回所需信息。
The resolver is located on the same machine as the program that requests the resolver’s services, but it may need to consult name servers on other hosts. Because a resolver may need to consult several name servers, or may have the requested information in a local cache, the amount of time that a resolver will take to complete can vary quite a bit, from milliseconds to several seconds.
解析器与请求解析器服务的程序位于同一台机器上，但它可能需要咨询其他主机上的名称服务器。 由于解析器可能需要咨询多个名称服务器，或者可能在本地缓存中具有所请求的信息，因此解析器完成所需的时间可能会有很大差异，从几毫秒到几秒不等。
A very important goal of the resolver is to eliminate network delay and name server load from most requests by answering them from its cache of prior results. It follows that caches which are shared by multiple processes, users, machines, etc., are more efficient than non-shared caches.
解析器的一个非常重要的目标是通过从先前结果的缓存中应答大多数请求来消除网络延迟和名称服务器负载。 由此可见，由多个进程、用户、机器等共享的缓存比非共享缓存更有效。
5.2. Client-resolver interface(客户端-解析器接口)
5.2.1. Typical functions(典型功能)
The client interface to the resolver is influenced by the local host’s conventions, but the typical resolver-client interface has three functions:
解析器的客户端接口受本地主机约定的影响，但典型的解析器-客户端接口具有三个功能：
1. Host name to host address translation.(主机名到主机地址的转换)
This function is often defined to mimic a previous HOSTS.TXT based function. Given a character string, the caller wants one or more 32 bit IP addresses. Under the DNS, it translates into a request for type A RRs. Since the DNS does not preserve the order of RRs, this function may choose to sort the returned addresses or select the "best" address if the service returns only one choice to the client. Note that a multiple address return is recommended, but a single address may be the only way to emulate prior HOSTS.TXT services.
此函数通常定义为模仿先前基于 HOSTS.TXT 的函数。 给定一个字符串，调用者需要一个或多个 32 位 IP 地址。 在 DNS 下，它会转换为 A 类 RR 的请求。 由于 DNS 不保留 RR 的顺序，因此该函数可以选择对返回的地址进行排序，或者如果服务仅向客户端返回一种选择，则选择“最佳”地址。 请注意，建议返回多个地址，但单个地址可能是模拟先前 HOSTS.TXT 服务的唯一方法。
2. Host address to host name translation(主机地址到主机名的转换)
This function will often follow the form of previous functions. Given a 32 bit IP address, the caller wants a character string. The octets of the IP address are reversed, used as name components, and suffixed with "IN-ADDR.ARPA". A type PTR query is used to get the RR with the primary name of the host. For example, a request for the host name corresponding to IP address 1.2.3.4 looks for PTR RRs for domain name "4.3.2.1.IN-ADDR.ARPA".
该函数通常遵循先前函数的形式。 给定一个 32 位 IP 地址，调用者需要一个字符串。 IP 地址的八位字节被反转，用作名称组件，并带有“IN-ADDR.ARPA”后缀。 PTR 类型查询用于获取带有主机主名称的 RR。 例如，对与IP地址1.2.3.4对应的主机名的请求查找域名“4.3.2.1.IN-ADDR.ARPA”的PTR RR。
3. General lookup function(通用查找功能)
This function retrieves arbitrary information from the DNS, and has no counterpart in previous systems. The caller supplies a QNAME, QTYPE, and QCLASS, and wants all of the matching RRs. This function will often use the DNS format for all RR data instead of the local host's, and returns all RR content (e.g., TTL) instead of a processed form with local quoting conventions.
该函数从 DNS 检索任意信息，并且在以前的系统中没有对应的函数。 调用者提供 QNAME、QTYPE 和 QCLASS，并需要所有匹配的 RR。 该函数通常对所有 RR 数据使用 DNS 格式而不是本地主机的格式，并返回所有 RR 内容（例如 TTL）而不是具有本地引用约定的处理形式。
When the resolver performs the indicated function, it usually has one of the following results to pass back to the client:
当解析器执行指定的功能时，它通常会将以下结果之一传回客户端：
1. One or more RRs giving the requested data.(一个或多个 RR 提供所请求的数据。)
In this case the resolver returns the answer in the appropriate format.
在这种情况下，解析器会以适当的格式返回答案。
2. A name error (NE).(名称错误)
This happens when the referenced name does not exist. For example, a user may have mistyped a host name.'
当引用的名称不存在时会发生这种情况。 例如，用户可能输错了主机名。
3. A data not found error.(未找到数据错误)
This happens when the referenced name exists, but data of the appropriate type does not. For example, a host address function applied to a mailbox name would return this error since the name exists, but no address RR is present.
当引用的名称存在但适当类型的数据不存在时，就会发生这种情况。 例如，应用于邮箱名称的主机地址函数将返回此错误，因为该名称存在，但不存在地址 RR。
It is important to note that the functions for translating between host names and addresses may combine the “name error” and “data not found” error conditions into a single type of error return, but the general function should not. One reason for this is that applications may ask first for one type of information about a name followed by a second request to the same name for some other type of information; if the two errors are combined, then useless queries may slow the application.
需要注意的是，用于在主机名和地址之间进行转换的函数可能会将“名称错误”和“未找到数据”错误条件合并为单一类型的错误返回，但通用函数不应该这样做。 原因之一是应用程序可能首先请求有关名称的一种类型的信息，然后再请求相同名称的其他类型的信息； 如果这两个错误结合在一起，那么无用的查询可能会减慢应用程序的速度。
5.2.2. Aliases(别名)
While attempting to resolve a particular request, the resolver may find that the name in question is an alias. For example, the resolver might find that the name given for host name to address translation is an alias when it finds the CNAME RR. If possible, the alias condition should be signalled back from the resolver to the client.
在尝试解析特定请求时，解析器可能会发现所讨论的名称是别名。 例如，解析器在找到 CNAME RR 时可能会发现为主机名到地址转换指定的名称是别名。 如果可能，别名条件应从解析器发回客户端。
In most cases a resolver simply restarts the query at the new name when it encounters a CNAME. However, when performing the general function, the resolver should not pursue aliases when the CNAME RR matches the query type. This allows queries which ask whether an alias is present. For example, if the query type is CNAME, the user is interested in the CNAME RR itself, and not the RRs at the name it points to.
在大多数情况下，解析器在遇到 CNAME 时只是以新名称重新启动查询。 然而，在执行一般功能时，当 CNAME RR 与查询类型匹配时，解析器不应追求别名。 这允许查询询问别名是否存在。 例如，如果查询类型是 CNAME，则用户对 CNAME RR 本身感兴趣，而不是它所指向的名称处的 RR。
Several special conditions can occur with aliases. Multiple levels of aliases should be avoided due to their lack of efficiency, but should not be signalled as an error. Alias loops and aliases which point to non-existent names should be caught and an error condition passed back to the client.
别名可能会出现一些特殊情况。 应避免使用多级别名，因为它们缺乏效率，但不应将其标记为错误。 应捕获别名循环和指向不存在名称的别名，并将错误条件传递回客户端。
5.2.3. Temporary failures(临时故障)
In a less than perfect world, all resolvers will occasionally be unable to resolve a particular request. This condition can be caused by a resolver which becomes separated from the rest of the network due to a link failure or gateway problem, or less often by coincident failure or unavailability of all servers for a particular domain.
在不太完美的世界中，所有解析器有时都无法解决特定请求。 这种情况可能是由解析器引起的，该解析器由于链路故障或网关问题而与网络的其余部分分离，或者很少由于特定域的所有服务器同时发生故障或不可用而引起。
It is essential that this sort of condition should not be signalled as a name or data not present error to applications. This sort of behavior is annoying to humans, and can wreak havoc when mail systems use the DNS.
重要的是，这种情况不应作为名称或数据不存在错误向应用程序发出信号。 这种行为对人类来说很烦人，并且当邮件系统使用 DNS 时可能会造成严重破坏。
While in some cases it is possible to deal with such a temporary problem by blocking the request indefinitely, this is usually not a good choice, particularly when the client is a server process that could move on to other tasks. The recommended solution is to always have temporary failure as one of the possible results of a resolver function, even though this may make emulation of existing HOSTS.TXT functions more difficult.
虽然在某些情况下可以通过无限期地阻止请求来处理此类临时问题，但这通常不是一个好的选择，特别是当客户端是可以继续执行其他任务的服务器进程时。 建议的解决方案是始终将临时故障作为解析器函数的可能结果之一，即使这可能会使现有 HOSTS.TXT 函数的模拟变得更加困难。
5.3. Resolver internals(解析器内部结构)
Every resolver implementation uses slightly different algorithms, and typically spends much more logic dealing with errors of various sorts than typical occurances. This section outlines a recommended basic strategy for resolver operation, but leaves details to [RFC-1035].
- 每个解析器实现都使用略有不同的算法，并且与典型事件处理相比将花费更多的逻辑来处理各种类型的错误。 本节概述了推荐的解析器操作基本策略，但将详细信息留给[RFC-1035]。 *
5.3.1. Stub resolvers(存根解析器-即缓存解析器)
One option for implementing a resolver is to move the resolution function out of the local machine and into a name server which supports recursive queries. This can provide an easy method of providing domain service in a PC which lacks the resources to perform the resolver
function, or can centralize the cache for a whole local network or organization.
*实现解析器的一种选择是将解析功能从本地计算机移出并移至支持递归查询的名称服务器中。 这可以提供一种在缺乏执行解析器功能的资源的 PC 中提供域服务的简单方法，或者可以集中整个本地网络或组织的缓存。 *
All that the remaining stub needs is a list of name server addresses that will perform the recursive requests. This type of resolver presumably needs the information in a configuration file, since it probably lacks the sophistication to locate it in the domain database. The user also needs to verify that the listed servers will perform the recursive service; a name server is free to refuse to perform recursive services for any or all clients. The user should consult the local system administrator to find name servers willing to perform the service.
存根解析器只需要拥有递归请求的名称服务器地址列表即可。 这种类型的解析器可能需要配置文件中的信息，因为它可能缺乏在域数据库中定位它的复杂性。 用户还需要验证列出的服务器是否会执行递归服务； 名称服务器可以自由拒绝为任何或所有客户端执行递归服务。 用户应咨询本地系统管理员以查找愿意执行该服务的名称服务器。
This type of service suffers from some drawbacks. Since the recursive requests may take an arbitrary amount of time to perform, the stub may have difficulty optimizing retransmission intervals to deal with both lost UDP packets and dead servers; the name server can be easily overloaded by too zealous a stub if it interprets retransmissions as new requests. Use of TCP may be an answer, but TCP may well place burdens on the host’s capabilities which are similar to those of a real resolver.
这种类型的服务有一些缺点。 由于递归请求可能需要任意时间来执行，因此存根可能难以优化重传间隔来处理丢失的 UDP 数据包和失效的服务器； 如果名称服务器将重传解释为新请求，则名称服务器很容易因过于热心的存根而过载。 使用 TCP 可能是一个答案，但 TCP 很可能会给主机的能力带来负担，这与真正的解析器的能力类似。
5.3.2. Resources(资源)
In addition to its own resources, the resolver may also have shared access to zones maintained by a local name server. This gives the resolver the advantage of more rapid access, but the resolver must be careful to never let cached information override zone data. In this discussion the term “local information” is meant to mean the union of the cache and such shared zones, with the understanding that authoritative data is always used in preference to cached data when both are present.
除了其自己的资源之外，解析器还可以共享对本地名称服务器维护的区域的访问。 这为解析器提供了更快速访问的优势，但解析器必须小心，切勿让缓存的信息覆盖区域数据。 在本讨论中，术语“本地信息”意指高速缓存和此类共享区域的联合，并理解当两者都存在时，权威数据总是优先于高速缓存数据使用。
The following resolver algorithm assumes that all functions have been converted to a general lookup function, and uses the following data structures to represent the state of a request in progress in the
resolver:
以下解析器算法假设所有函数都已转换为通用查找函数，并使用以下数据结构来表示解析器中正在进行的请求的状态
| 结构体名 | 说明 |
|---|---|
| SNAME | the domain name we are searching for. 正在搜索的域名 |
| STYPE | the QTYPE of the search request. 搜索请求的QTYPE |
| SCLASS | the QCLASS of the search request. 搜索请求的QCLASS |
| SLIST | a structure which describes the name servers and the zone which the resolver is currently trying to query. This structure keeps track of the resolver’s current best guess about which name servers hold the desired information; it is updated when arriving information changes the guess. This structure includes the equivalent of a zone name, the known name servers for the zone, the known addresses for the name servers, and history information which can be used to suggest which server is likely to be the best one to try next. The zone name equivalent is a match count of the number of labels from the root down which SNAME has in common with the zone being queried; this is used as a measure of how “close” the resolver is to SNAME. 描述名称服务器和解析器当前尝试查询的区域的结构。 该结构跟踪解析器当前对哪些名称服务器保存所需信息的最佳猜测； 当到达的信息改变猜测时，它就会更新。 该结构包括区域名称的等效项、该区域的已知名称服务器、名称服务器的已知地址以及可用于建议哪个服务器可能是下一步尝试的最佳服务器的历史信息。 区域名称等效项是从根向下的标签数量的匹配计数，SNAME 与正在查询的区域有共同点； 这用于衡量解析器与 SNAME 的“接近”程度。 |
| SBELT | a “safety belt” structure of the same form as SLIST, which is initialized from a configuration file, and lists servers which should be used when the resolver doesn’t have any local information to guide name server selection. The match count will be -1 to indicate that no labels are known to match. 与 SLIST 形式相同的“安全带”结构，它从配置文件初始化，并列出当解析器没有任何本地信息来指导名称服务器选择时应使用的服务器。 匹配计数将为 -1，表示没有已知的匹配标签。 |
| CACHE | A structure which stores the results from previous responses. Since resolvers are responsible for discarding old RRs whose TTL has expired, most implementations convert the interval specified in arriving RRs to some sort of absolute time when the RR is stored in the cache. Instead of counting the TTLs down individually, the resolver just ignores or discards old RRs when it runs across them in the course of a search, or discards them during periodic sweeps to reclaim the memory consumed by old RRs. 存储先前响应结果的结构。 由于解析器负责丢弃 TTL 已过期的旧 RR，因此大多数实现会将到达 RR 中指定的间隔转换为 RR 存储在缓存中时的某种绝对时间。 解析器不是单独对 TTL 进行计数，而是在搜索过程中遇到旧 RR 时忽略或丢弃它们，或者在定期扫描期间丢弃它们以回收旧 RR 消耗的内存。 |
5.3.3. Algorithm(算法)
The top level algorithm has four steps:
顶层算法有四个步骤：
1 | |
Step 1 searches the cache for the desired data. If the data is in the cache, it is assumed to be good enough for normal use. Some resolvers have an option at the user interface which will force the resolver to ignore the cached data and consult with an authoritative server. This is not recommended as the default. If the resolver has direct access to a name server’s zones, it should check to see if the desired data is present in authoritative form, and if so, use the authoritative data in preference to cached data.
步骤1: 在缓存中搜索所需数据。 如果数据在缓存中，则认为它足以满足正常使用。 某些解析器在用户界面上有一个选项，该选项将强制解析器忽略缓存的数据并咨询权威服务器。 不建议将此作为默认值。 如果解析器可以直接访问名称服务器的区域，则它应该检查所需的数据是否以权威形式存在，如果是，则优先使用权威数据而不是缓存数据。
Step 2 looks for a name server to ask for the required data. The general strategy is to look for locally-available name server RRs, starting at SNAME, then the parent domain name of SNAME, the grandparent, and so on toward the root. Thus if SNAME were Mockapetris.ISI.EDU, this step would look for NS RRs for Mockapetris.ISI.EDU, then ISI.EDU, then EDU, and then . (the root). These NS RRs list the names of hosts for a zone at or above SNAME. Copy the names into SLIST. Set up their addresses using local data. It may be the case that the addresses are not available. The resolver has many choices here; the best is to start parallel resolver processes looking for the addresses while continuing onward with the addresses which are available. Obviously, the design choices and options are complicated and a function of the local host’s capabilities. The recommended priorities for the resolver designer are:
步骤2:查找名称服务器以请求所需的数据。 一般策略是寻找本地可用的名称服务器 RR，从 SNAME 开始，然后是 SNAME 的父域名、祖父域名，依此类推，直至root(根)。 因此，如果 SNAME 是 Mockapetris.ISI.EDU，则此步骤将查找 Mockapetris.ISI.EDU 的 NS 资源记录(RR)，然后是 ISI.EDU，然后是 EDU，最后是.(即根)。 这些 NS 资源记录(RR) 列出了 SNAME 或以上区域的主机名称。 将名称复制到 SLIST 中。 使用本地数据设置他们的地址。 可能是地址不可用的情况。 解析器在这里有很多选择； 最好的方法是启动并行解析器进程来查找地址，同时继续查找可用的地址。 显然，设计选择和选项很复杂，并且取决于本地主机的功能。 优先推荐的解析器设计是:
Bound the amount of work (packets sent, parallel processes started) so that a request can’t get into an infinite loop or start off a chain reaction of requests or queries with other implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED SOME DATA.
限制工作量（发送数据包、启动并行进程），以便请求无法进入无限循环或启动请求或查询与其他实现的连锁反应，即使有人错误地配置了某些数据。Get back an answer if at all possible.
如果可能的话，请返回答案。Avoid unnecessary transmissions.
避免不必要的传输。Get the answer as quickly as possible.
尽快得到答案。
If the search for NS RRs fails, then the resolver initializes SLIST from the safety belt SBELT. The basic idea is that when the resolver has no idea what servers to ask, it should use information from a configuration file that lists several servers which are expected to be helpful. Although there are special situations, the usual choice is two of the root servers and two of the servers for the host’s domain. The reason for two of each is for redundancy. The root servers will provide eventual access to all of the domain space. The two local servers will allow the resolver to continue to resolve local names if the local network becomes isolated from the internet due to gateway or link failure.
如果搜索 NS RR(资源记录) 失败，则解析器从’安全带 ‘SBELT 初始化 SLIST。 基本思想是，当解析器不知道要询问哪些服务器时，它应该使用配置文件中的信息，该配置文件列出了预计有帮助的几个服务器。 尽管有特殊情况，但通常的选择是两台根服务器和两台主机域服务器。 各两个的原因是为了冗余。 根服务器将提供对所有域空间的最终访问。 如果本地网络由于网关或链路故障而与互联网隔离，这两个本地服务器将允许解析器继续解析本地名称。
In addition to the names and addresses of the servers, the SLIST data structure can be sorted to use the best servers first, and to insure that all addresses of all servers are used in a round-robin manner. The sorting can be a simple function of preferring addresses on the local network over others, or may involve statistics from past events, such as previous response times and batting averages.
除了服务器的名称和地址之外，还可以对SLIST数据结构进行排序，以首先使用最好的服务器，并确保以循环方式使用所有服务器的所有地址。 排序可以是优先选择本地网络上的地址而不是其他地址的简单功能，也可以涉及过去事件的统计数据，例如先前的响应时间和成功率。
Step 3 sends out queries until a response is received. The strategy is to cycle around all of the addresses for all of the servers with a timeout between each transmission. In practice it is important to use all addresses of a multihomed host, and too aggressive a retransmission policy actually slows response when used by multiple resolvers contending for the same name server and even occasionally for a single resolver. SLIST typically contains data values to control the timeouts and keep track of previous transmissions.
步骤3:发出查询，直到收到响应。 该策略是循环所有服务器的所有地址，并在每次传输之间设置超时。 实际上，使用多宿主主机的所有地址非常重要，当多个解析器争用同一名称服务器时，甚至偶尔争用单个解析器时，过于激进的重传策略实际上会减慢响应速度。 SLIST 通常包含用于控制超时并跟踪先前传输的数据值。
Step 4 involves analyzing responses. The resolver should be highly paranoid in its parsing of responses. It should also check that the response matches the query it sent using the ID field in the response.
**步骤4: 响应分析。 解析器在解析响应时应该高度偏执。 它还应该使用响应中的 ID 字段检查响应是否与其发送的查询匹配。 **
The ideal answer is one from a server authoritative for the query which either gives the required data or a name error. The data is passed back to the user and entered in the cache for future use if its TTL is greater than zero.
理想的答案是来自对查询具有权威性的服务器的答案，该服务器要么给出所需的数据，要么给出名称错误。 如果数据的 TTL 大于零，则数据将传回用户并输入到缓存中以供将来使用。
If the response shows a delegation, the resolver should check to see that the delegation is “closer” to the answer than the servers in SLIST are. This can be done by comparing the match count in SLIST with that computed from SNAME and the NS RRs in the delegation. If not, the reply is bogus and should be ignored. If the delegation is valid the NS delegation RRs and any address RRs for the servers should be cached. The name servers are entered in the SLIST, and the search is restarted.
如果响应显示是一个代理，则解析器应检查代理是否比 SLIST 中的服务器“更接近”答案。 可以通过将 SLIST 中的匹配计数与从 SNAME 和委派中的 NS 资源记录（RRs）计算得出的匹配计数进行比较来实现。 如果不是，则该回复是假的，应被忽略。 如果委派有效，则应缓存 NS 委派 RR 和服务器的任何地址 RR。 名称服务器将输入 SLIST，然后重新启动搜索。
If the response contains a CNAME, the search is restarted at the CNAME unless the response has the data for the canonical name or if the CNAME is the answer itself.
如果响应包含 CNAME，则搜索将在 CNAME 处重新启动，除非响应具有规范名称的数据或者 CNAME 就是答案本身。
Details and implementation hints can be found in [RFC-1035].
详细信息和实现提示可以在 [RFC-1035] 中找到。
6. A SCENARIO(一个场景)
In our sample domain space, suppose we wanted separate administrative
control for the root, MIL, EDU, MIT.EDU and ISI.EDU zones. We might
allocate name servers as follows:
|(C.ISI.EDU,SRI-NIC.ARPA
| A.ISI.EDU)
+---------------------+------------------+
| | |
MIL EDU ARPA
|(SRI-NIC.ARPA, |(SRI-NIC.ARPA, |
| A.ISI.EDU | C.ISI.EDU) |
+-----+-----+ | +------+-----+-----+
| | | | | | |
BRL NOSC DARPA | IN-ADDR SRI-NIC ACC
|
+--------+------------------+---------------+--------+
| | | | |
UCI MIT | UDEL YALE
|(XX.LCS.MIT.EDU, ISI
|ACHILLES.MIT.EDU) |(VAXA.ISI.EDU,VENERA.ISI.EDU,
+---+---+ | A.ISI.EDU)
| | |
LCS ACHILLES +--+-----+-----+--------+
| | | | | |
XX A C VAXA VENERA Mockapetris
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 C.ISI.EDU, SRI-NIC.ARPA, and
A.ISI.EDU. The MIL domain is served by SRI-NIC.ARPA and A.ISI.EDU. The
EDU domain is served by SRI-NIC.ARPA. and C.ISI.EDU. Note that servers
may have zones which are contiguous or disjoint. In this scenario,
C.ISI.EDU has contiguous zones at the root and EDU domains. A.ISI.EDU
has contiguous zones at the root and MIL domains, but also has a non-
contiguous zone at ISI.EDU.
6.1. C.ISI.EDU name server
C.ISI.EDU is a name server for the root, MIL, and EDU domains of the IN
class, and would have zones for these domains. The zone data for the
root domain might be:
. IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
870611 ;serial
1800 ;refresh every 30 min
300 ;retry every 5 min
604800 ;expire after a week
86400) ;minimum of a day
NS A.ISI.EDU.
NS C.ISI.EDU.
NS SRI-NIC.ARPA.
MIL. 86400 NS SRI-NIC.ARPA.
86400 NS A.ISI.EDU.
EDU. 86400 NS SRI-NIC.ARPA.
86400 NS C.ISI.EDU.
SRI-NIC.ARPA. A 26.0.0.73
A 10.0.0.51
MX 0 SRI-NIC.ARPA.
HINFO DEC-2060 TOPS20
ACC.ARPA. A 26.6.0.65
HINFO PDP-11/70 UNIX
MX 10 ACC.ARPA.
USC-ISIC.ARPA. CNAME C.ISI.EDU.
73.0.0.26.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.
65.0.6.26.IN-ADDR.ARPA. PTR ACC.ARPA.
51.0.0.10.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.
52.0.0.10.IN-ADDR.ARPA. PTR C.ISI.EDU.
103.0.3.26.IN-ADDR.ARPA. PTR A.ISI.EDU.
A.ISI.EDU. 86400 A 26.3.0.103
C.ISI.EDU. 86400 A 10.0.0.52
This data is represented as it would be in a master file. Most RRs are
single line entries; the sole exception here is the SOA RR, which uses
“(“ to start a multi-line RR and “)” to show the end of a multi-line RR.
Since the class of all RRs in a zone must be the same, only the first RR
in a zone need specify the class. When a name server loads a zone, it
forces the TTL of all authoritative RRs to be at least the MINIMUM field
of the SOA, here 86400 seconds, or one day. The NS RRs marking
delegation of the MIL and EDU domains, together with the glue RRs for
the servers host addresses, are not part of the authoritative data in
the zone, and hence have explicit TTLs.
Four RRs are attached to the root node: the SOA which describes the root
zone and the 3 NS RRs which list the name servers for the root. The
data in the SOA RR describes the management of the zone. The zone data
is maintained on host SRI-NIC.ARPA, and the responsible party for the
zone is HOSTMASTER@SRI-NIC.ARPA. A key item in the SOA is the 86400
second minimum TTL, which means that all authoritative data in the zone
has at least that TTL, although higher values may be explicitly
specified.
The NS RRs for the MIL and EDU domains mark the boundary between the
root zone and the MIL and EDU zones. Note that in this example, the
lower zones happen to be supported by name servers which also support
the root zone.
The master file for the EDU zone might be stated relative to the origin
EDU. The zone data for the EDU domain might be:
EDU. IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
870729 ;serial
1800 ;refresh every 30 minutes
300 ;retry every 5 minutes
604800 ;expire after a week
86400 ;minimum of a day
)
NS SRI-NIC.ARPA.
NS C.ISI.EDU.
UCI 172800 NS ICS.UCI
172800 NS ROME.UCI
ICS.UCI 172800 A 192.5.19.1
ROME.UCI 172800 A 192.5.19.31
ISI 172800 NS VAXA.ISI
172800 NS A.ISI
172800 NS VENERA.ISI.EDU.
VAXA.ISI 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 172800 A 26.3.0.103
UDEL.EDU. 172800 NS LOUIE.UDEL.EDU.
172800 NS UMN-REI-UC.ARPA.
LOUIE.UDEL.EDU. 172800 A 10.0.0.96
172800 A 192.5.39.3
YALE.EDU. 172800 NS YALE.ARPA.
YALE.EDU. 172800 NS YALE-BULLDOG.ARPA.
MIT.EDU. 43200 NS XX.LCS.MIT.EDU.
43200 NS ACHILLES.MIT.EDU.
XX.LCS.MIT.EDU. 43200 A 10.0.0.44
ACHILLES.MIT.EDU. 43200 A 18.72.0.8
Note the use of relative names here. The owner name for the ISI.EDU. is
stated using a relative name, as are two of the name server RR contents.
Relative and absolute domain names may be freely intermixed in a master
6.2. Example standard queries
The following queries and responses illustrate name server behavior.
Unless otherwise noted, the queries do not have recursion desired (RD)
in the header. Note that the answers to non-recursive queries do depend
on the server being asked, but do not depend on the identity of the
requester.
6.2.1. QNAME=SRI-NIC.ARPA, QTYPE=A
The query would look like:
+---------------------------------------------------+
Header | OPCODE=SQUERY |
+---------------------------------------------------+
Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A |
+---------------------------------------------------+
Answer | <empty> |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
The response from C.ISI.EDU would be:
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE, AA |
+---------------------------------------------------+
Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A |
+---------------------------------------------------+
Answer | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 |
| 86400 IN A 10.0.0.51 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
The header of the response looks like the header of the query, except
that the RESPONSE bit is set, indicating that this message is a
response, not a query, and the Authoritative Answer (AA) bit is set
indicating that the address RRs in the answer section are from
authoritative data. The question section of the response matches the
question section of the query.
If the same query was sent to some other server which was not
authoritative for SRI-NIC.ARPA, the response might be:
+---------------------------------------------------+
Header | OPCODE=SQUERY,RESPONSE |
+---------------------------------------------------+
Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A |
+---------------------------------------------------+
Answer | SRI-NIC.ARPA. 1777 IN A 10.0.0.51 |
| 1777 IN A 26.0.0.73 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
This response is different from the previous one in two ways: the header
does not have AA set, and the TTLs are different. The inference is that
the data did not come from a zone, but from a cache. The difference
between the authoritative TTL and the TTL here is due to aging of the
data in a cache. The difference in ordering of the RRs in the answer
section is not significant.
6.2.2. QNAME=SRI-NIC.ARPA, QTYPE=*
A query similar to the previous one, but using a QTYPE of *, would
receive the following response from C.ISI.EDU:
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE, AA |
+---------------------------------------------------+
Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* |
+---------------------------------------------------+
Answer | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 |
| A 10.0.0.51 |
| MX 0 SRI-NIC.ARPA. |
| HINFO DEC-2060 TOPS20 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
If a similar query was directed to two name servers which are not
authoritative for SRI-NIC.ARPA, the responses might be:
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+
Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* |
+---------------------------------------------------+
Answer | SRI-NIC.ARPA. 12345 IN A 26.0.0.73 |
| A 10.0.0.51 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
and
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+
Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* |
+---------------------------------------------------+
Answer | SRI-NIC.ARPA. 1290 IN HINFO DEC-2060 TOPS20 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
Neither of these answers have AA set, so neither response comes from
authoritative data. The different contents and different TTLs suggest
that the two servers cached data at different times, and that the first
server cached the response to a QTYPE=A query and the second cached the
response to a HINFO query.
6.2.3. QNAME=SRI-NIC.ARPA, QTYPE=MX
This type of query might be result from a mailer trying to look up
routing information for the mail destination HOSTMASTER@SRI-NIC.ARPA.
The response from C.ISI.EDU would be:
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE, AA |
+---------------------------------------------------+
Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=MX |
+---------------------------------------------------+
Answer | SRI-NIC.ARPA. 86400 IN MX 0 SRI-NIC.ARPA.|
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 |
| A 10.0.0.51 |
+---------------------------------------------------+
This response contains the MX RR in the answer section of the response.
The additional section contains the address RRs because the name server
at C.ISI.EDU guesses that the requester will need the addresses in order
to properly use the information carried by the MX.
6.2.4. QNAME=SRI-NIC.ARPA, QTYPE=NS
C.ISI.EDU would reply to this query with:
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE, AA |
+---------------------------------------------------+
Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=NS |
+---------------------------------------------------+
Answer | <empty> |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
The only difference between the response and the query is the AA and
RESPONSE bits in the header. The interpretation of this response is
that the server is authoritative for the name, and the name exists, but
no RRs of type NS are present there.
6.2.5. QNAME=SIR-NIC.ARPA, QTYPE=A
If a user mistyped a host name, we might see this type of query.
C.ISI.EDU would answer it with:
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE, AA, RCODE=NE |
+---------------------------------------------------+
Question | QNAME=SIR-NIC.ARPA., QCLASS=IN, QTYPE=A |
+---------------------------------------------------+
Answer | <empty> |
+---------------------------------------------------+
Authority | . SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. |
| 870611 1800 300 604800 86400 |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
This response states that the name does not exist. This condition is
signalled in the response code (RCODE) section of the header.
The SOA RR in the authority section is the optional negative caching
information which allows the resolver using this response to assume that
the name will not exist for the SOA MINIMUM (86400) seconds.
6.2.6. QNAME=BRL.MIL, QTYPE=A
If this query is sent to C.ISI.EDU, the reply would be:
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+
Question | QNAME=BRL.MIL, QCLASS=IN, QTYPE=A |
+---------------------------------------------------+
Answer | <empty> |
+---------------------------------------------------+
Authority | MIL. 86400 IN NS SRI-NIC.ARPA. |
| 86400 NS A.ISI.EDU. |
+---------------------------------------------------+
Additional | A.ISI.EDU. A 26.3.0.103 |
| SRI-NIC.ARPA. A 26.0.0.73 |
| A 10.0.0.51 |
+---------------------------------------------------+
This response has an empty answer section, but is not authoritative, so
it is a referral. The name server on C.ISI.EDU, realizing that it is
not authoritative for the MIL domain, has referred the requester to
servers on A.ISI.EDU and SRI-NIC.ARPA, which it knows are authoritative
for the MIL domain.
6.2.7. QNAME=USC-ISIC.ARPA, QTYPE=A
The response to this query from A.ISI.EDU would be:
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE, AA |
+---------------------------------------------------+
Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A |
+---------------------------------------------------+
Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. |
| C.ISI.EDU. 86400 IN A 10.0.0.52 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
Note that the AA bit in the header guarantees that the data matching
QNAME is authoritative, but does not say anything about whether the data
for C.ISI.EDU is authoritative. This complete reply is possible because
A.ISI.EDU happens to be authoritative for both the ARPA domain where
USC-ISIC.ARPA is found and the ISI.EDU domain where C.ISI.EDU data is
found.
If the same query was sent to C.ISI.EDU, its response might be the same
as shown above if it had its own address in its cache, but might also
be:
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE, AA |
+---------------------------------------------------+
Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A |
+---------------------------------------------------+
Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. |
+---------------------------------------------------+
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 |
+---------------------------------------------------+
This reply contains an authoritative reply for the alias USC-ISIC.ARPA,
plus a referral to the name servers for ISI.EDU. This sort of reply
isn’t very likely given that the query is for the host name of the name
server being asked, but would be common for other aliases.
6.2.8. QNAME=USC-ISIC.ARPA, QTYPE=CNAME
If this query is sent to either A.ISI.EDU or C.ISI.EDU, the reply would
be:
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE, AA |
+---------------------------------------------------+
Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A |
+---------------------------------------------------+
Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
Because QTYPE=CNAME, the CNAME RR itself answers the query, and the name
server doesn’t attempt to look up anything for C.ISI.EDU. (Except
possibly for the additional section.)
6.3. Example resolution
The following examples illustrate the operations a resolver must perform
for its client. We assume that the resolver is starting without a
cache, as might be the case after system boot. We further assume that
the system is not one of the hosts in the data and that the host is
located somewhere on net 26, and that its safety belt (SBELT) data
structure has the following information:
Match count = -1
SRI-NIC.ARPA. 26.0.0.73 10.0.0.51
A.ISI.EDU. 26.3.0.103
This information specifies servers to try, their addresses, and a match
count of -1, which says that the servers aren’t very close to the
target. Note that the -1 isn’t supposed to be an accurate closeness
measure, just a value so that later stages of the algorithm will work.
The following examples illustrate the use of a cache, so each example
assumes that previous requests have completed.
6.3.1. Resolve MX for ISI.EDU.
Suppose the first request to the resolver comes from the local mailer,
which has mail for PVM@ISI.EDU. The mailer might then ask for type MX
RRs for the domain name ISI.EDU.
The resolver would look in its cache for MX RRs at ISI.EDU, but the
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:
+---------------------------------------------------+
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:
+---------------------------------------------------+
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:
1 | |
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
1 | |
本博客所有文章除特别声明外，均采用 CC BY-SA 4.0 协议 ，转载请注明出处！