RFC1034(中文)_域名-概念和设施

本文翻译者：weicq2000 (2012-10-9，weicq2000@sina.com) Network Working Group P. Mockapetris Request for Comments: 1034 ISI Obsoletes: RFCs 882, 883, 973 November 1987 域名 --- 概念和设施 目录 第 1 章 本备忘录状态 第 2 章 序言 2-1 域名的历史 2-2 DNS设计目标 2-3 有关应用的假设 2-4 DNS组成部分 第3章 域名空间和资源记录 3-1 名称空间和术语 3-2 有关应用的管理准则 3-3 有关应用的技术准则 3-4 名称空间举例 3-5 优先选用的名称句法 3-6 资源记录 3-6-1 RRs的文本表示 3-6-2 别名和正则名称 3-7 查询 3-7-1 标准查询 3-7-2 反向查询(可选) 3-8 状态查询(试验中) 3-9 完整查询(放弃) 第4章 名称服务器 4-1 序言 4-2 怎样将数据库划分成区域 4-2-1 技术上的考虑 4-2-2 管理上的考虑 4-3 名称服务器内部 4-3-1 查询和响应 4-3-2 算法 4-3-3 通配符 4-3-4 否定响应缓存(可选) 4-3-5 区域维护和传送 第5章 解析器 5-1 序言 5-2 客户端-解析器接口 5-2-1 典型功能 5-2-2 别名 5-2-3 临时故障 5-3 解析器内部 5-3-1 末梢解析器 5-3-2 资源 5-3-3 算法 第6章 场景 6-1 C.ISI.EDU名称服务器 6-2 标准查询举例 6-2-1 QNAME=SRI-NIC.ARPA, QTYPE=A 6-2-2 QNAME=SRI-NIC.ARPA, QTYPE=* 6-2-3 QNAME=SRI-NIC.ARPA, QTYPE=MX 6-2-4 QNAME=SRI-NIC.ARPA, QTYPE=NS 6-2-5 QNAME=SIR-NIC.ARPA, QTYPE=A 6-2-6 QNAME=BRL.MIL, QTYPE=A 6-2-7 QNAME=USC-ISIC.ARPA, QTYPE=A 6-2-8 QNAME=USC-ISIC.ARPA, QTYPE=CNAME 6-3 解析举例 6-3-1 解析ISI.EDU.的MX 6-3-2 获得地址26.6.0.65的主机名 6-3-3 获得poneria.ISI.EDU的主机地址 第7章 参考文献和参考目 原文索引 第1章 本备忘录状态 本备忘录介绍域名系统(Domain Name System, DNS)，文中忽略了许多细节，这些细节 可在姊妹篇RFC“域名---实现和规范”[RFC-1035]中找到。RFC1035假设读者熟悉本备忘录 中讨论的概念。 DNS功能和数据类型子集构成正式协议。正式协议包括标准查询和它们的响应，以及大 多数互联网类数据格式(例如，主机地址)。 然而，域系统有意构建成可扩展的。研究者正在不断提出、实施和试验新的数据类型、 查询类型、类、功能，等等。因此，尽管期盼正式协议各部分保持基本不变并作为生产业务 运行，应当始终鼓励试验工作不断扩展正式协议。在这些RFCs中对试验的或作废的特性做 了明显的标记，使用这类信息应当谨慎。 读者应特别注意，不要依赖本文(目前的和完成的)举例中出现的值，因为这些值的确定 主要源于教学演示需要。本备忘录的分发不受限制。 第2章 序言 本RFC介绍域样式名称，它们在互联网邮件和主机地址支持中的应用，以及实现域名功 能的协议和业务。 2-1 域名的历史 域系统是在互联网增长的推动下发展起来的： - 主机名称到地址的映射，由单一文件(HOSTS.TXT)中的网络信息中心(Network Information Center, NIC)维护，所有主机通过文件传输协议(File Transfer Protocol, FTP)获得该文件[RFC-952、RFC-953]。按此方法分发新版本消耗的总网络带宽 正比于该网络中主机数的平方，即使当使用多层FTP时，在NIC主机上的出境FTP 负载也是相当可观的。 主机数量的爆炸性增长预计将来也不会停止。 - 网络数量也在相应改变。构成原始ARPANET的分时主机正在被本地工作站网络 替代。本地组织正在管理他们自己的名称和地址，但是必须等待NIC改变 HOSTS.TXT，以便在互联网上普遍可以看到这些改变。组织们也希望在名称空 间上实现某种本地结构。 - 在互联网上的应用正在变得更加复杂，正在产生对通用目的名称服务的需求。 结果产生几种有关名称空间和对它们进行管理的思路[IEN-116、RFC-799、RFC-819、 RFC-830]。这些建议各不相同，但是共同的主线是等级名称空间思想，采用粗略对应组织 结构的等级，使用由“.”作为标记等级层次间边界的记号的名称。使用分布式数据库和广 义资源的设计在[RFC-882、RFC-883]中介绍。根据几方面实践的经验，系统最终演进为本 备忘录中介绍的。 术语“域(domain)”或“域名(domain name)”在许多场景中使用，使用范围超出这里介 绍的DNS。更一般情况，术语域名用于指具有由圆点表示的结构的名称，但是与DNS没有关 系。在邮件寻址[Quarterman 86]中尤其是这样。 2-2 DNS设计目标 DNS的设计目标影响它的结构。这些目标是： - 主要目标是一致性名称空间，这一名称空间用于指资源。为了避免特别是由编码 引起的问题，名称应当不要求包括网络标识符、地址、路由，或作为该名称一部 分的类似信息。 - 规模庞大和频繁更新要求数据库必须采用分布式方式维护，使用本地缓存改善性 能。企图收集整个数据库的一致性复本的方法将变得越来越昂贵和困难，并且因 此应当避免。同样的道理也适用于名称空间结构，以及尤其是生成和删除名称的 机制；这些也应当是分布式的。 - 凡是需要在获得数据成本、更新速率和缓存精度间进行折中时，数据源应当控制 此折中。 - 实现成本(诸如便利性)要求DNS通常普遍可用，不被限制在单一应用。我们应当 能够使用名称来检索主机地址、邮箱数据和其他尚未确定的信息。所有与名称关 联的数据用类型(type)标记，并且可以将查询限制在单一类型。 - 因为我们希望名称空间可用于不同的网络和应用，我们提供由不同协议族或管理 使用相同 名称空间的能力。例如，尽管所有协议都有地址概念，协议间主机地 址格式不同。DNS用类以及类型标记所有数据，因此我们可以允许并行使用不同 格式类型地址的数据。 - 我们希望名称服务器业务独立于携带这些业务的通信系统。一些系统可能希望使 用数据报进行查询和响应，并且仅为强调可靠性的业务(例如，数据库更新，长 业务)建立虚拟电路；其他系统将排他性地使用虚拟电路。 - 系统应当能够适应广泛的主机能力。个人计算机和大型分时主机都应当能够使用 此系统，尽管可能采用不同方法。 2-3 有关应用的假设 域系统的组织来源于某些假设，这些假设涉及域系统用户社区的需求和使用模式，域系 统的设计致力于避免在通用数据库系统中发现的许多复杂问题。 这些假设是： - 整个数据库的大小初期正比于使用此系统的主机数量，但是当邮箱和其他信息被 添加到此域系统时，最终将发展为正比于这些主机上的用户数量。 - 系统中大多数数据变化非常缓慢(例如，邮箱绑定，主机地址)，但是系统应当能 够处理变化更为迅速的子集(在秒或分钟等级上)。 - 用于分配数据库职责的管理边界通常对应有一台或多台主机的组织。每个对特定 一组域有责任的组织将提供冗余的名称服务器，或者在组织自己的主机上提供， 或者在由该组织安排使用的其他主机上提供。 - 域系统的客户端应当能够识别值得信任的名称服务器集合，在接受转介到这个 “值得信任的”集合之外的名称服务器前，客户端优先使用这些名称服务器。 - 获取信息比即时更新或一致性担保更为关键。因此，更新处理使更新能够过滤出 域系统的用户而不是保证所有副本同时更新。当由于网络或主机故障，更新不能 进行时，通常的做法是相信旧信息同时继续努力更新它。一般模式是用刷新超时 分发副本。分发者设置超时值，分发物的接收者负责执行刷新。在特殊情况，可 能规定非常短的间隔，或者所有者可能禁止复制。 - 在任何有分布式数据库的系统中，特定名称服务器可能遇到仅可以由某个其他服 务器回答的查询。处理此问题的两个常用方法其一是“递归”，在递归中，第一 个服务器继续为客户端在另一个服务器上查询；其二是“迭代”，在迭代中，该 服务器引导客户端寻找另一个服务器，并让该客户端继续查询。两种方法各有优 缺点，但是在数据报形式的访问中优先使用迭代方法。域系统需要执行迭代方法， 但是允许将递归方法作为选项。 域系统假设，所有数据起源于使用域系统的主机散发的主文件。这些主文件被本地系统 管理员更新。主文件是文本文件，本地名称服务器读这些主文件，因此经名称服务器后，可 被该域系统的用户得到。用户程序通过称为解析器的标准程序访问名称服务器。 主文件采用标准格式因而它们能够在主机间交换(通过FTP、邮件、或某种其他机制)； 当组织想要域，但是不希望支持名称服务器时，这个特点是有用的。组织能够维护本地使用 文本编辑器的主文件，将它们传送给运行名称服务器的外地主机，接着与那个名称服务器的 系统管理者协商获得加载的文件。 本地系统管理者配置每个主机的名称服务器和解析器[RFC-1033]。对于名称服务器，这 个配置数据包括本地主文件标识，和有关从外地服务器加载非本地主文件的指令。名称服务 器使用主文件或主文件副本加载它的区域。对于解析器，此配置数据指出应当是主信息源的 名称服务器。 域系统定义访问数据和转介到其他名称服务器的流程。域系统也定义由系统管理员确定 的缓存检索数据的流程和数据周期刷新的流程。 系统管理者提供： - 区域边界定义。 - 数据的主文件。 - 对主文件的更新。 - 陈述希望的刷新策略。 域系统提供： - 资源数据的标准格式。 - 查询数据库的标准方法。 - 名称服务器刷新来自外地名称服务器的本地数据的标准方法。 2-4 DNS组成部分 DNS有三个主要部分： - 域名空间和资源记录(DOMAIN NAME SPACE和RESOURCE RECORDS)，它们 是树状结构名称空间和与这些名称关联的数据的规范。从概念上讲，每个节点和 域名空间树的叶子命名一组信息，查询操作是打算从特定集合提取特定类型信息。 查询命名感兴趣的域名和描述希望的资源信息类型。例如，互联网使用它的某个 域名标识主机；地址资源的查询返回互联网主机地址。 - 名称服务器(NAME SERVERS)，它们是服务器程序，它们保存着有关域树的结 构的信息和设置信息。名称服务器可以缓存有关域树的任何部分的结构和设置信 息，但是一般而言，特定的名称服务器有关于该域空间的子集的完整信息，有指 向其他名称服务器的指针，这些其他服务器可用于从域树的任何部分引导信息。 名称服务器们知道域树的各个部分(它们对其有完整信息)；对于名称空间的这些 部分，名称服务器被看作是权威(AUTHORITY)。权威信息被编排进称作区域 (ZONEs)的单元，这些区域可以自动分配给为区域中的数据提供冗余服务的名称 服务器。 - 解析器(RESOLVERS)，是为了响应客户端请求从名称服务器提取信息的程序。 解析器必须能够访问至少一个名称服务器，并使用那个名称服务器的信息直接回 答查询，或使用到其他名称服务器的转介，继续查询。解析器一般是系统例行程 序，它可直接访问到用户程序；因此在解析器和用户程序间不需要协议。 这三个组成部分大致对应域系统的三层或三个视野： - 从用户的观点看，通过简单的流程或OS调用本地解析器，访问域系统。域空间 由单一树构成，用户可以从该树的任何部分请求信息。 - 从解析器的观点看，域系统由未知数量的名称服务器组成。每个名称服务器有整 个域树的数据中的一条或多条数据，然而解析器将这些数据库的每一个看作基本 上是静态的。 - 从名称服务器的观点看，域系统由分离的、称作区域的本地信息集合构成。名称 服务器有某些区域的本地副本。名称服务器必须根据本地文件中的主副本或外地 名称服务器，周期刷新它的区域。名称服务器必须并发处理来自多个解析器的查 询。 从性能考虑，实现可以融合这些功能。例如，在作为名称服务器的同一计算机上的解 析器或许共享由区域构成的数据库(区域由该名称服务器管理)，以及可以共享由该解析器 管理的缓存器。 第3章 域名空间和资源记录 3-1 名称空间规范和术语 域名空间是树形结构。每个节点和树上的叶对应资源集合(资源集合可以为空)。域系统 对内部节点使用和树叶使用不加区别，本备忘录使用术语“节点(node)”指代两者。 每个节点有标签，标签长度从0到63个八位位组。兄弟节点不可以有相同的标签，尽管 相同标签可用于不是兄弟的节点。一个标签被保留，它是空(即零长度)标签，用于树根。 节点的域名是从节点到树根路径沿途各个标签的明细表。按照惯例，构成域名的标签从 左到右书写或读出，从最具体的(最低，离树根最远)到最不具体的(最高，离树根最近)。 在内部，操控域名的程序应当把域名表示为标签序列，这里每个标签是长度八位位组， 再加上八位位组字符串。因为所有域名在树跟结束，树根有标签的空字符串，这些内部表示 可以使用零长度字节来终止域名。 按照惯例，域名可以用任意大小写保存，但是对于所有现有的域功能，域名比较采用不 区分大小写的方式进行，假设采用ASCII字符集，高阶零位。这意味着您可以自由使用标记 “A”生成节点，或使用标记“a”生成节点，但是二者不能作为兄弟；您可以或者使用“a” 表示节点，或者使用“A”表示节点。当您收到域名或标签时，您应当保存它的大小写。这 样选择的理由是或许某一天我们需要为新的业务添加全二进制域名；现有的业务不改变。 当用户需要打印域名时，忽略每个标签的长度，标签被用圆点(“.”)隔开。因为完整的 域名用根标签结束，这产生以圆点结束的书写格式。我们使用这个性质相互间区别： - 代表完整域名的字符串(常称作“绝对”)。例如，“poneria.ISI.EDU.” - 代表不完整域名的开始标签的字符串，应当使用本地域知识，由本地软件完善该 字符串(常称作“相对”)。例如，使用在ISI.EDU域中的“poneria”。 选取相对名称，或者是相对于众所周知的起源选取，或者是相对于用作搜索列表的域的 明细表选取。相对名称大多出现在用户接口中，在那里，由于实现不同对相对名称的翻译也 各不相同，在主文件中，相对名称相对于单一起源域名。最通用的翻译使用根“.”作为或 者是单一起源，或者是搜索列表的成员之一，所以多标签相对名称常常是这样的相对名称， 在那里尾随的圆点因为要节省打印而被忽略掉。 为了简化实现，表示域名的八位位组的总数(即，所有标签八位位组和标签长度的和)被 限制到255。 域由域名标识，域由域名空间的那个部分组成，那个部分位于该域名中或在该域名以下， 该域名规定该域。域是另一个域的子域，如果该域被包含在另一个域中。通过观察是否子域 的名称用包含域的名称结束，可以检验这种相互关系。例如，A.B.C.D是B.C.D，C.D，D和 “”的子域。 3-2 有关应用的管理准则 作为一个策略，DNS技术规范没有规定具体的树状结构或选择标签的规则；这样做的目 的是尽可能通用，以便它能够用来建立任意应用。尤其是，将系统设计成名称空间不必沿着 网络边界线、名称服务器等构建。这样做的理由不是名称空间应当没有隐含语义，而是隐含 语义的选择应当保持开放，以便应用于被考虑的问题，以及树的不同部分可以有不同的隐含 语义。例如，IN-ADDR.ARPA域是根据网络和主机地址进行组织和分发的，因为它的作用 是从网络号或主机号翻译到名称；NetBIOS域[RFC-1001，RFC-1002]是扁平的，因为对于那 个应用这是适当的。 然而，存在一些准则，它们适合用于主机、邮箱等的名称空间的“一般”部分，这些准 则将使得名称空间更加统一，有利于其成长，以及尽量减少因软件是从较旧的主机表转换而 来引起的问题。关于树的顶层的策略决策在RFC-920中讨论。目前的顶层策略在[RFC-1032] 中讨论。MILNET转换问题在[RFC-1031]中讨论。 最终将被插入多个区域的较低的那些域应当在该域的顶部提供分支，以便无需重新命名 即可进行最终的分解。使用特定字符串、前置数字等的节点标签极有可能突破较旧的软件(旧 软件更多依赖于严格的选择)。 3-3 有关应用的技术准则 DNS能够用于保持某种对象的命名信息之前，必须满足两点： - 在对象名称和域名之间进行映射的约定。这描述如何访问有关对象的信息。 - 描述对象的RR类型和数据格式。 这些准则可能非常简单或十分复杂。常常，设计者必须顾及已有的格式，必须规划向上 兼容已有的应用。可能需要多映射或映射层级。 对于主机，映射取决于已有的主机名称句法(主机名称是域名的常用文本表示法的子集)， 以及描述主机地址的RR格式，等等。因为我们需要可靠的逆映射(从地址到主机名称)，也定 义了进入IN-ADDR.ARPA域的地址的特殊映射。 对于邮箱，映射稍微复杂一些。通过把转变为单一标签(忽略标签包含的圆 点)，使用域名的常用文本格式把转变为域名(圆点表示标签中断)，并串联两 部分形成单一的域名，通常的邮件地址@被映射成域名。于是， 邮箱HOSTMASTER@SRI-NIC.ARPA由HOSTMASTER.SRI-NIC.ARPA表示为域名。

评价

LEC评价法下载LEC评价法下载评价量规免费下载学院评价表文档下载学院评价表文档下载

这 种设计背后的原因也必须考虑邮件交换的方案[RFC-974]。 普通用户不关心定义这些规则，但是应当理解这些规则通常是下述方面大量互动的结果， 即，向上兼容旧有应用愿望之间的妥协，不同的对象定义之间的相互影响，以及当定义这些 规则时不可避免的添加新特征冲动。使用DNS支持某些对象的方法常常比在DNS中固有的限 制更为关键。 3-4 名称空间举例 图1显示当前域名空间的一部分，该图在本RFC的许多举例中使用。注意，此树是实际 名称空间的非常小的子集。 MIL EDU ARPA BRL NOSC DARPA IN-ADDR SRI-NIC ACC UCI MIT YALEUDEL ISI LCS ACHILLES XX A C VAXA VENERA Mockapetris 图1 域名空间一部分举例 在这个例子中，根域有三个直接子域：MIL、EDU和ARPA。LCS.MIT.EDU域有一个名 为XX.LCS.MIT.EDU的直接子域。所有叶子也是域。 3-5 优先选用的名称句法 DNS规范力争在构建域名规则方面尽可能通用。具体思路是：任何已有对象的名称，能 够以尽可能小的改动表示为域名。然而，当为对象分配域名时，谨慎的用户将选择既满足域 名系统规则，又满足对象任何已有的规则的名称，无论这些规则已公开发表，还是隐含在已 有程序中。 例如，当命名邮件域时，用户应当既满足本备忘录的规则，又满足RFC-822中的规则。 当生成新的主机名称时，应当遵守旧的HOSTS.TXT规则。这可以避免当旧的软件转换为使 用域名时可能出现的问题。 下述句法很少出现与使用域名的许多应用(例如：邮件，TELNET)有关的问题。 ::= | " " ::= | "." ::= [ [ ] ] ::= | ::= | "-" ::= | < letter> ::= 52个字母字符，大写的A到Z和小写的a到z，中的任何一个。 < digit> ::= 十进制数字0到9中的任何一个。 注意，尽管在域名中大、小写字母都是允许的，但是区别大小写没有意义。即，两个有 相同拼写，不同大小写的名称被看作同一名称。 标签必须遵循ARPANET主机名称规则。它们必须以字母开始，以字母或数字结束，中 间的字符只能是字母、数字和连字符。对长度也有一些限制。标签必须少于等于63个字符。 例如，下述字符串标识互联网中的主机： A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA 3-6 资源记录 域名标识节点。每个节点有一组资源信息，资源信息可以为空。与特定名称关联的资源 信息集合由分开的资源记录(RRs)构成。在集合中RRs的次序没有意义，并且不需要由名称 服务器、解析器、或DNS的其他部分保存。 当我们谈论特定RR时，我们假设它有下述内容： 所有者(owner) 它是域名，在该域名中RR被发现。 类型(type) 它是编码的16位值，该值规定在这个资源记录中的资源的类型。类 型指抽象的资源。 本备忘录使用下述类型： A 主机地址 CNAME 标记别名(alias)的正则(canonical)名称 HINFO 标记主机使用的CPU和OS MX 标记域的邮件交换。更多内容参阅[RFC-974]。 NS 该域的权威名称服务器 PTR 到域名空间别的部分的指针 SOA 标识权威区域的开始 类(class) 它是编码的16位值，该值标识协议族或协议实例。 本备忘录使用下述类： IN 互联网系统 CH 混沌(Chaos)系统 TTL 它是RR的生存时间。这个字段是32位整数，以秒为单位，主要由 解析器缓存RRs时使用。TTL描述在RR应当被抛弃前，它能够被 缓存多长时间。 RDATA 它可以是类型或类，取决于描述该资源的数据： A 对于IN类，是32位IP地址。 对于CH类，是域名，再加上16位八进制Chaos地址。 CNAME 域名 MX 16位首选项值(越低越好。)，再加上愿意充当所有 者域邮件交换的主机名称。 NS 主机名称 PTR 域名 SOA 几个字段 所有者名称常常是隐式的，不属于RR不可分割的一部分。例如，许多名称服务器在内 部形成名称空间的树或哈希结构，束缚离开节点的RRs。其余RR部分是固定首部(类型、类、 TTL)和可变部分(RDATA)，固定首部与所有RRs一致，RDATA适合正在被描述的资源的需 要。 TTL字段的含义是关于RR能够被缓存多长时间的限制。这个限制对区域中的权威数据 不适用；权威数据也会超时，但是使用该区域的刷新策略。管理员为数据起源区域分配TTL。 虽然短TTLs能够用于尽量减少缓存，零TTL禁止缓存，互联网性能的现实暗示，对于典型 的主机，这些时间应当设置为几天的数量级比较合适。如果能够预测到有改变，在改变前可 以将TTL减少，以便尽量减小改变期间的不一致，然后随着改变，增加并返回到它的先前值。 在RRs的RDATA部分中的数据被作为二进制串和域名的组合携带。域名被频繁用作指向 DNS中其他数据的“指针”。 3-6-1 RRs的文本表示 在DNS协议的分组中，RRs用二进制形式表示，当存储在名称服务器或解析器中时，RRs 通常用高度编码的形式表示。在本备忘录中，我们采用类似在主文件中使用的体裁，以便显 示RRs的内容。在此格式中，大多数RRs在一行上显示，然而可以使用圆括号连续显示几行。 在行的一开始给出RR的所有者。如果行以空格开始，那么，假设所有者与前一个RR的相同。 为了方便阅读常常包括空行。 在所有者之后，我们列出RR的TTL、类型和类。类和类型使用上面定义的助记符，TTL 是类型字段前的整数。为了避免

分析

定性数据统计分析pdf销售业绩分析模板建筑结构震害分析销售进度分析表京东商城竞争战略分析

上的歧义，类型助记符和类助记符不相交，TTLs是整 数，类型助记符总是位于最后。在意思表达清晰的情况下，举例中常常忽略IN类值和TTL 值。 使用数据的典型表示法知识，给出资源数据或RR的RDATA部分。 例如，我们或许将消息中携带的RRs显示为： ISI.EDU. MX 10 VENERA.ISI.EDU. MX 10 VAXA.ISI.EDU. VENERA.ISI.EDU. A 128.9.0.32 A 10.1.0.52 VAXA.ISI.EDU. A 10.2.0.27 A 128.9.0.33 MX RRs有RDATA部分，该部分由16位数构成，再加上域名。地址RRs使用标准IP地址 格式，包括32位网络互联地址。 此例显示6个RRs，3个域名中的每一个有2个RRs。 类似，我们或许看到： XX.LCS.MIT.EDU. IN A 10.0.0.44 CH A MIT.EDU. 2420 此例显示XX.LCS.MIT.EDU的2个地址，每个具有不同的类。 3-6-2 别名和正则名称 在现有系统中，主机和其他资源常常有几个名称，这些名称标识同一资源。例如，名称 C.ISI.EDU 和USC-ISIC.ARPA都标识同一个主机。类似，在邮箱情况，许多组织提供多个名 称，这些名称实际上去相同邮箱；例如，Mockapetris@C.ISI.EDU、Mockapetris@B.ISI.EDU、 和 PVM@ISI.EDU都去同一邮箱(尽管在此背后的机制有些复杂)。 这些系统中的大多数有这样的共识，即，等同的名称集合中的一个名称是正则的 (canonical)或主要的名称，所有其他的都是别名。 域名系统提供使用正则名称(CNAME)RR的特征。CNAME RR标识它的所有者名称为别 名，并在RR的RDATA部分规定相应的正则名称。如果节点中存在CNAME RR，不应当存在 其他数据；这确保正则名称和它的别名的数据不会有不同。这个规则也确保缓存的CNAME 可以不加检验就可以由其他RR类型的权威服务器使用。 在DNS软件中，CNAME RRs引起特殊行动。当名称服务器不能在与该域名关联的资源 集合中发现期望的RR时，名称服务器检验是否资源集合与具有匹配类的CNAME记录一致。 如果一致，名称服务器在响应中包括此CNAME记录，并且在此CNAME记录的数据字段中 规定的域名重新开始查询。此规则的一个例外是：不重新开始匹配此CNAME类型的那些查 询。 例如，假设名称服务器正在处理针对USCISIC.ARPA的查询，询问A类型信息，并有下 述资源记录： USC-ISIC.ARPA IN CNAME C.ISI.EDU C.ISI.EDU IN A 10.0.0.52 这两个RRs将在对A类型查询的响应中返回，而CANME类型或*查询应当仅返回 CNAME。 在RRs中的域名(这些域名指向另一个名称)应当总是指向主(正则)名称，而不是指向别名。 这可以避免访问信息中的额外迂回。例如，对于上面的主机，到名称RR的地址应当是： 52.0.0.10.IN-ADDR.ARPA IN PTR C.ISI.EDU 而不指向USC-ISIC.ARPA。当然，由稳健性原则，当存在CNAME链或环时，域软件不 应当失败；应当接受CNAME链，CNAME环预示着出错。 3-7 查询 查询是消息，这些消息可以被发送到名称服务器，激发响应。在互联网中，查询由UDP 数据报携带，或在TCP连接上传送。名称服务器的响应或者回答查询中提出的问题，引导提 问者到另一组名称服务器，或者提示某个错误条件。 一般讲，用户不会直接生成查询，但是会向解析器提出请。解析器依次发送一个或多个 查询给名称服务器，解析器处理错误条件和处理可能出现的转介。当然，在查询中能够被询 问的可能问题就形成解析器能够提供的业务种类。 DNS查询和响应用标准的消息格式携带。此消息格式有包括众多固定字段(这些字段总 是存在)的首部，和携带查询参数和RRs的4个部分。 首部中最重要的字段是称作操作码的字段，它有4位，用来区分不同的查询。具有16个 可能值，1(标准查询)是正式协议的一部分，2(反向查询和状态查询)是选项，1(完整)是被废 弃的，其余部分没有分配。 4个部分是： 问题 携带查询名称和其他查询参数。 回答 携带直接回答查询的RRs。 权威 携带描述其他权威服务器的RRs。可以选择在回答部分携带权威数 据的SOA RR。 附加 携带在其他部分中使用RRs时，可能有帮助的RRs。 注意，这些部分中的内容，不是格式，会随首部操作码改变。 3-7-1 标准查询 标准查询规定目标域名(QNAME)、查询类型(QTYPE)和查询类(QCLASS)，以及询问匹 配的RRs。查询的这个类型形成DNS查询的绝大多数，除非另有规定，我们使用术语“查询” 指标准查询。QTYPE字段和QCLASS字段都是16位长，是定义的类型和定义的类的超集。 QTYPE字段可能包括： < any type> 仅匹配那个类型(例如，A、PTR) AXFR 传递QTYPE的特定区域 MAILB 匹配所有与RRs有关的邮箱(例如，MB和MG) * 匹配所有RR类 QCLASS字段可能包括： < any class> 仅匹配那个类(例如，IN、CH) * 匹配所有RR类 使用查询域名、QTYPE和QCLASS，名称服务器查找匹配的RRs。除了相关的记录以外， 名称服务器可能返回RRs，这些RRs指向有想要的信息的名称服务器，或者这些RRs被认为 有助于解释相关RRs。例如，没有所请求信息的名称服务器可能知道某个名称服务器有该信 息；在相关RR中返回域名的名称服务器也可能返回绑定那个域名到地址的RR。 例如，尝试发送邮件到Mockapetris@ISI.EDU的邮件收发程序或许向解析器询问关于 ISI.EDU的邮件信息，这导致对QNAME=ISI.EDU、QTYPE=MX、QCLASS=IN的查询。该 响应的回答部分或许是： ISI.EDU. MX 10 VENERA.ISI.EDU. MX 10 VAXA.ISI.EDU. 而附加部分或许是： VAXA.ISI.EDU. A 10.2.0.27 A 128.9.0.33 VENERA.ISI.EDU. A 10.1.0.52 A 128.9.0.32 因为服务器假设，如果请求者想要邮件交换信息，请求者不久的将来或许也想要该邮件 交换地址。 注意，QCLASS=*结构要求关于权威的特殊解释。因为特定名称服务器可能不知道域系 统中所有可用的类，该特定名称服务器可能决不会知道是否对于所有类，它是权威的。因此， 对QCLASS=*查询的响应可能绝不是权威的。 3-7-2 反向查询(可选) 名称服务器也可以支持反向查询，反向查询映射具体的资源到域名或一些域名(它们都 有那个资源)。例如，当标准查询映射域名到SOA RR时，相应的反向查询映射SOA RR回到 该域名。 这个业务的实现在名称服务器中是可选项，但是所有名称服务器必须至少能够理解反向 查询消息，并返回说明不能实现的出错响应。 域系统不能保证反向查询的完整性或唯一性，因为域系统是由域名而不是由主机地址或 其它任何资源类型构成的。反向查询主要用于调试和数据库维护。 反向查询可能不返回适当的TTL，反向查询不指出这样的情况，即，标识的RR是一组 中的一个(例如，有多个地址的主机的一个地址)。因此，绝不应当缓存在反向查询中返回的 RRs。 对于映射主机地址到主机域名，反向查询不是可接受的方法；使用IN-ADDR.ARPA域 代替之。 有关反向查询的详细讨论参阅[RFC-1035]。 3-8 状态查询(试验中) 将要对其定义。 3-9 完整查询(放弃) 在RFC 882和RFC 883中介绍的可选的完整业务已经被删除。将来重新设计的该业务或 许可以应用，或者收回操作码给其他业务使用。 第4章 名称服务器 4-1 序言 名称服务器是构成域数据库的信息仓库。域数据库被划分成称为区域(zone)的部分，区 域在众多名称服务器间分配。虽然名称服务器可以有几个可选的功能和数据源，它的基本任 务是：使用在它的区域中的数据回答查询。通过设计，名称服务器能够用简单的方法回答查 询；响应总可以仅使用本地数据产生，响应或者包含对问题的回答，或者包含到其他“更接 近”想要信息的名称服务器的转介。 可从几个名称服务器得到给定的区域，从而确保给定区域的可用性，无论主机或通信链 路是否有故障。通过管理命令，我们要求每一个区域至少可在两台服务器上得到，许多区域 有比此更高的冗余度。 给定的名称服务器典型支持一个或多个区域，但是这仅给予名称服务器有关域树的小部 分的权威信息。名称服务器也可能有某些缓存的有关该树的其他部分的非权威数据。名称服 务器标记它的查询响应，以便请求者能够识别响应来自权威数据，或不是。 4-2 怎样将数据库划分成区域 有两种方法划分域数据库：其一是按类，其二是在节点间的名称空间中进行“切割(cut)”。 按类划分简单。任何类数据库的组织、授权和维护独立于所有其他类。因为，按照惯例， 名称空间对于所有类是相同的，分开的类可被视为并行名称空间树的阵列。注意，对于这些 不同的并行类，附属于节点的数据是不同的。产生新类的最普通理由是现有类型的新数据格 式所必须的，或对现有名称空间实行分开管理的愿望。 在类中，在名称空间内的“切割”可以在任何两个毗邻节点间进行。完成所有切割后， 每个连接名称空间的组是独立的区域。对于连接的区间(region)内的所有名称，该区域被认 为是权威的。注意，名称空间内的“切割”可以位于不同类的不同位置，名称服务器可以不 同，等等。 这些规则意味着每个区域至少有一个节点，因此域名(对于域名区域是权威的)，以及特 定区域内的所有节点被连接。假设，树状结构，每个区域有最高的节点(在该区域内该节点 比任何其他节点都更靠近树根)。这个节点的名称常用来标识该区域。 有可能的是，虽然不是特别有用，划分名称空间造成每个域名位于独立的区域，或造成 所有节点位于单一区域。反之，数据库被在一些点上划分，在这些点上特定的组织希望接管 对子树的控制。一旦组织控制它自己的区域，组织能够单方面改变该区域中的数据，生长连 接到该区域的新树部分，删除现有的节点，或在他的区域下授权新的子区域。 如果组织有子结构，组织可能希望做进一步的内部划分，以便实现名称空间控制的嵌套 授权。在某些情况，这种划分纯粹是为了方便数据库维护。 4-2-1 技术上的考虑 描述区域的数据有4个主要部分： - 区域内所有节点的权威数据。 - 定义区域的顶层节点的数据(可被视为权威数据的一部分)。 - 描述授权的子区域(即，靠近区域底部的切割)的数据。 - 允许访问子区域的名称服务器的数据(有时称为“胶(glue)”数据)。 这个数据的所有部分都以RRs形式表示，所以借助一组RRs能够完整描述区域。通过传 送RRs，整个区域可以在名称服务器之间传送，或者是在一系列消息中携带，或者是通过FTP 发送文本方式表示的主文件传送。 区域的权威数据就是附属于所有节点的所有RRs，这些节点包括从区域的顶层节点向下 到叶节点，或者向下到靠近区域底部边缘的切割(cut)上面的节点。 虽然逻辑上是权威数据的一部分，描述区域顶层节点的RRs对于区域管理特别重要。这 些RRs有两个类型：名称服务器RRs，它列出区域的所有服务器(每个RR列出一个)；单SOA RR， 它描述区域管理参数。 描述靠近区域底部的切割的RRs是NS RRs，它命名子区域的服务器。因为切割位于节点 之间，这些RRs不是区域权威数据的一部分，这些RRs应当与子区域顶层节点中相应RRs精 确相同。因为名称服务器总是与区域边界关联，NS RRs仅在这样的节点出现，这些节点是 某个区域的顶层节点。在形成区域的数据内，NS RRs在区域的顶层节点出现(并且是权威的)， 以及出现在靠近区域的底部的切割中(在哪里，这些NS RRs不是权威的)，但是NS RRs绝不 出现在二者之间。 区域结构的目标之一是：任何区域都有建立与任何子区域的名称服务器通信需要的所有 数据。即，父区域有访问他们子区域的服务器所需要的所有信息。命名子区域服务器的NS RRs常常不足以完成这项任务，因为NS RRs命名这些服务器，但是不给出它们的地址。尤其 是，如果子区域中名称服务器的名称是它自己时，我们可能面对这样的情况，那里NS RRs 告诉我们，为了学习名称服务器的地址，我们应当使用我们希望学习的地址去联系该服务器。 为了解决这个问题，区域包括“胶(glue)”RRs，它们不是权威数据的一部分，它们是那些 服务器的地址RRs。如果名称服务器的名称“低于”切割时这些RRs才是必须的，并且这些 RRs仅用作转介响应的一部分。 4-2-2 管理上的考虑 当某个组织希望控制它自己的域时，第一步要做的是标识适当的父区域，获得父区域所 有者同意控制授权。虽然对在树中的哪里可以这样做没有特别的技术限制，在[RFC-1032] 中讨论了一些管理上的分组，这些分组与顶层组织打交道，中层区域可自由创立它们自己的 规则。例如，一所大学或许选择使用单一区域，而另一所大学或许选择专门针对各个系或学 院的子区域进行组织。[RFC-1033]归类了可用的DNS软件，并讨论了管理流程。 一旦为新的子区域选择了适当的名称，应当要求新的所有者证实支持冗余名称服务器。 注意，没有要求区域的服务器驻留在在那个域有域名的主机上。在许多情况，如果区域的服 务器们广泛分布，而不是位于由管理该区域的同一组织控制的物理设备内，区域更容易方便 地由互连网络访问。例如，在目前的DNS中，英国(或UK域)的名称服务器之一在美国出现。 这使得美国主机不必使用有限的跨大西洋带宽，就能够获得UK数据。 作为最后的安装步骤，应当添加使授权生效必须的授权NS RRs和胶(glue)RRs到父区域。 两个区域的管理者应当确保NS RRs和glue RRs(它们标记切割的两边)一致并保持一致。 4-3 名称服务器内部 4-3-1 查询和响应 名称服务器的主要活动是回答标准查询。采用[RFC-1035]中介绍的标准消息格式携带查 询和查询的响应。查询包括QTYPE、QCLASS和QNAME，它们描述期望信息和感兴趣名称 的类型和类。 名称服务器回答查询的方法取决于查询正在以递归模式运行，或者不是： - 对服务器来说，最简单模式是非递归，因为服务器可以仅使用本地信息回答查询： 响应包括出错、回答，或到某个“更接近”该回答的其他服务器的转介。所有名 称服务器必须执行非递归查询。 - 对客户端来说，最简单模式是递归，因为在这种模式中，名称服务器充当解析器 的角色，返回的内容或者是出错，或者是回答，但绝不是转介。在名称服务器中， 这个业务是可选的，并且名称服务器也可能选择限制能够使用递归模式的客户端。 递归业务在以下几种情况是有用的： - 相对简单的请求者，该请求者缺乏使用除了对问题的直接回答以外的任何东西的 能力。 - 需要跨协议或跨其它边界的请求，以及能够被发送到可以充当中继的服务器的请 求。 - 网络，在该网络中，我们希望集中缓存，而不是每个客户端有独立的缓存器。 如果请求者有能力跟踪转介，以及对有助于将来的请求的信息感兴趣，非递归业务是适 当的。 递归模式的使用限定在一些场景，在那里，客户端和名称服务器一致同意使用递归模式。 在查询消息和响应消息中，通过两个位的使用，对是否同意可以协商： - RA位，由名称服务器在所有响应中置1，递归可以使用；或置0，递归不可以使用。如 果名称服务器愿意为该客户端提供递归业务，此位为真，无论是否该客户端请求了递归业 务。即，RA暗示可用性而不是使用。 - 查询包括称作希望递归(recursion desired)或RD的位。此位规定是否请求者希望这 个查询使用递归业务。客户端可以请求来自任何名称服务器的递归业务，尽管客 户端们应当仅相信从下述服务器接收的递归业务，这些服务器先前已经发送了 RA，或者这些服务器已经同意通过私有协定或某些DNS协议以外的其他方法提 供业务。 当带有RD置1的查询到达服务器(该服务器愿意提供递归业务)时，递归模式发生；通过 检验在此响应中RA和RD都被置1，客户端可以证实使用了递归模式。注意，除非经RD要求， 名称服务器绝不应执行递归业务，因为这会干扰名称服务器和它们的数据库的故障排查。 如果要求递归业务并且可以使用，查询的递归响应将是下列之一： - 对查询的回答，可能由一个或多个CNAME RRs开始，这些CNAME RRs规定在到 达回答的路径上遇到的别名。 - 指出名称不存在的名称错误。它可能包括CNAME RRs，这些CNAME RRs指出起 源的查询名称是不存在的名称的别名。 - 临时错误指示。 如果没有要求递归业务，或者不能获得递归业务，非递归响应将是下列之一： - 权威名称错误，它指出该名称不存在。 - 临时错误指示。 - 下述的某个组合： 回答问题的RRs，连同是否数据来自区域或被缓存的指示。 到这样的名称服务器们的转介，与发送该响应的服务器相比，这些名称服务器有更接 近于到该名称的祖宗们的区域。 - 名称服务器认为这些RRs将对请求者有用。 4-3-2 算法 名称服务器使用的实际算法取决于本地OS和存储RRs的数据结构。下述算法假设用几个 树状结构组织RRs，一个树状结构用于每个区域，别的树状结构用于缓存： 1、根据名称服务器是否愿意提供递归业务，响应中递归可用的值被置1或置0。如 果递归业务可用，并且在查询中经RD位请求递归业务，转到步骤5，否则到步 骤2。 2、针对最接近到QNAME祖宗的区域，搜索可用区域，如果找到这样的区域，转 到步骤3，否则到步骤4。 3、在该区域中，开始逐标签地向下匹配。此匹配处理可以终止下述几种情况： a、如果整个QNAME匹配，我们找到该节点。 如果在该节点中的数据是CNAME，并且QTYPE不匹配CNAME，复制此 CNAME RR进响应的回答部分，改变QNAME到在CNAME RR中的正则名 称，返回到步骤1。 否则，将所有匹配QTYPE的RRs复制进回答部分并转到步骤6。 b、如果匹配从我们中除去权威数据，我们有转介。当我们遇到有NS RRs(该 NS RRs标记沿区域底部的切割)的节点时，这种情况发生。 将此子区域的NS RRs复制进响应的权威部分。将无论什么样的可得到地址 放进附加部分，如果这些地址不能从权威数据或缓存器中获得，使用胶RRs。 转到步骤4。 c、如果在某个标签中，匹配是不可能的(即，相应的标签不存在)，查看是否 “*”标签存在。 如果“*”标签不存在，验证或者我们正在寻找的名称是该查询中的起源 QNAME，或者我们正在寻找的名称是我们基于CNAME跟踪的名称。如果 该名称是起源的，在响应中设置权威名称错误并退出。否则，仅仅退出。