RFC1035(中文)域名-实现及标准

本文翻译者：weicq2000(2012-10-9，[e-mail])NetworkWorkingGroupP.MockapetrisRequestforComments:1035ISINovember1987Obsoletes:RFCs882,883,973域名---实现及标准目录第1章本备忘录状态第2章序言2-1综述2-2一般配置2-3惯例2-3-1首选的名称句法2-3-2数据传送顺序2-3-3字符大小写2-3-4大小限制第3章域名空间和资源记录(RR)定义3-1名称空间定义3-2资源记录定义3-2-1格式3-2-2TYPE值3-2-3QTYPE值3-2-4CLASS值3-2-5QCLASS值3-3标准RRs3-3-1CNAMERDATA格式3-3-2HINFORDATA格式3-3-3MBRDATA格式(试验)3-3-4MDRDATA格式(废止)3-3-5MFRDATA格式(废止)3-3-6MGRDATA格式(试验)3-3-7MINFORDATA格式(试验)3-3-8MRRDATA格式(试验)3-3-9MXRDATA格式3-3-10NULLRDATA格式(试验)3-3-11NSRDATA格式3-3-12PTRRDATA格式3-3-13SOARDATA格式3-3-14TXTRDATA格式3-4ARPA互联网特定RRs3-4-1ARDATA格式3-4-2WKSRDATA格式3-5IN-ADDR.ARPA域3-6定义新的类型、类和专用名称空间第4章消息4-1格式4-1-1首部部分格式4-1-2问题部分格式4-1-3资源记录格式4-1-4消息压缩4-2传送4-2-1UDP应用4-2-2TCP应用第5章主文件5-1格式5-2定义区域的主文件的应用5-3主文件举例第6章名称服务器实现6-1架构6-1-1控制6-1-2数据库6-1-3时间6-2标准查询处理6-3区域更新和重新加载处理6-4反向查询(可选)6-4-1反向查询和响应的内容6-4-2反向查询和响应举例6-4-3反向查询处理6-5完整查询和响应第7章解析器实现7-1将用户请求转换为查询7-2发送查询7-3处理响应7-4使用缓存器第8章邮件支持8-1邮件交换绑定8-2邮箱绑定(试验)第9章参考文献和参考书目原文索引第1章本备忘录状态本RFC介绍域系统和协议细节，并假设读者熟悉在姊妹篇RFC“域名-概念和设施”[RFC-1034]中讨论的概念。域系统是正式协议的功能和数据类型的混合体，域系统是仍然处于试验中的功能和数据类型的混合体。因为域系统有意做成可扩展的，应当总是希望新的数据类型和试验行为成为超出正式协议的系统的组成部分。正式协议部分包括标准查询、响应和互联网类RR数据格式(例如，主机地址)。自从以前的一些RFC发表以来，几个定义已经改变，所以某些以前的定义已被废除。在这些RFCs中，清晰标出了试验的和废除的特征，应当谨慎使用这些信息。读者应特别小心，不能依赖在目前或完成的例子中出现的值，因为这些举例的目的主要是教学。这个备忘录的分发不受限制。第2章序言2-1综述域名的目标是采用这样一种方法(采用这种方法，名称可以用于不同主机、网络、协议族、互连网络和管理组织。)，提供命名资源的机制。从用户的观点，域名作为参数，对于称为解析器的本地代理是有用的，解析器检索与域名关联的信息。于是，用户或许询问与特定域名关联的主机地址或邮件信息。为使用户能够请求特定类型的信息，适当的查询类型被传递给有该域名的解析器。对于用户来说，域树是单一信息空间；解析器负责隐藏来自用户的、名称服务器间的数据分布。从解析器的观点，构成域空间的数据库在不同的名称服务器间分布。尽管特定的数据项被重复保存在两个或多个名称服务器中，域空间的不同部分保存在不同的名称服务器中。开始时解析器至少有一个名称服务器的知识。当解析器处理用户查询时，它针对用户查询的信息询问已知的名称服务器；作为回报，解析器或者收到想要的信息，或者收到去另一个名称服务器的转介。使用这些转介，解析器了解其他名称服务器的身份和内容。解析器负责处理域空间的分布，负责通过咨询在其他服务器中的冗余数据库，应对名称服务器失效的影响。名称服务器管理两种数据。第一种是在设置中被约束的称为区域(zone)的数据；每个区域是域空间特定“被切断的(pruned)”子树的完整数据库。这个数据被称为权威的。名称服务器定期检验，以便确认它的区域是最新的，如果不是这样，从保存在本地或另一个名称服务器中的主文件中获得被更新区域的新副本。第二种数据是由本地解析器获得的缓存数据。这个数据可能是不完整的，但是当重复访问非本地数据时它可以改善检索处理的性能。缓存数据最终被超时机制抛弃。这个功能性结构隔离了用户接口问题、失败恢复问题和在解析器中分发的问题，隔离了名称服务器中数据库更新问题和刷新问题。2-2一般配置主机能够以多种方法分享域名服务器，取决于或者主机运行检索来自域系统的信息的程序、运行检索来自名称服务器(这些服务器回答来自其他主机的查询)信息的程序，或者主机运行两种程序功能的各种组合。最简单和或许也是最典型的配置如图1所示。用户程序解析器用户查询用户响应查询响应外地名称服务器本地主机外地缓存器缓存添加参考图1最简单和最典型的配置用户程序通过解析器与名称空间互动；用户查询和响应格式是主机和主机操作系统特有的。用户查询一般是操作系统调用，解析器和它的缓存器是主机操作系统的一部分。能力较弱的主机可以选择将解析器作为子例行程序，该子例行程序被挂到每个需要它的服务的程序上。解析器用它们通过查询本地缓存器和外地名称服务器获得的信息回答用户查询。注意，解析器或许必须对几个不同的外地名称服务器进行多个查询，以便回答特定用户的查询，因此，用户查询的解析可能涉及对几个网络的访问，和任意长的时间。对外地名称服务器的查询和相应的响应采用本备忘录中介绍的标准格式，可能是数据报。根据名称服务器的能力，它可以是在专用计算机上的独立程序，或在大型分时主机上的一个或多个进程。一种简单配置或许如图2所示。名称服务器响应查询外地解析器本地主机外地主文件图2一种简单配置这里，主名称服务器通过从它的本地文件系统读主文件，获得有关一个或多个区域的信息，并回答从外地解析器传来的有关那些区域的查询。此DNS请求由不止一个名称服务器冗余支持的所有区域。指定的辅助服务器们可以获得区域，并使用DNS区域传送协议，根据主服务器，检查更新。这个配置如图3所示。名称服务器响应查询外地解析器本地主机外地主文件外地名称服务器维护查询维护响应图3DNS请求由多个名称服务器冗余支持的所有区域配置在这个配置中，名称服务器定期建立到外地名称服务器的虚电路，以便获得区域的副本或证实现有的副本没有改变。发送用于这些维护行动的消息遵循与查询和响应使用的相同的格式，但是消息序列有所不同。全面支持域名系统各个方面的主机中的信息流如图4所示。用户程序解析器用户查询用户响应查询响应外地名称服务器本地主机外地共享数据库缓存添加参考刷新参考名称服务器主文件外地解析器外地名称服务器响应查询维护查询维护响应图4全面支持域名系统各个方面的主机中的信息流共享数据库持有本地名称服务器和解析器的域空间数据。共享数据库的内容一般是由名称服务器定期更新操作维护的权威数据，和来自先前解析器请求的缓存数据的混合体。域数据的结构，以及名称服务器和解析器之间同步的必要性暗示这个数据库的一般特点，但是实际格式取决于本地实现者。信息流也可能被裁减，以便一组主机共同进行优化行动。有时，这样做是为了给能力较弱主机卸载，以便它们不必执行整个解析器。这样做可能是适当的，尤其是对PC或希望尽量减小被要求的新网络代码的数量的主机。根据集中缓存有更高命中率的假设，这一方案也使得一组主机能够共享少量缓存器，而不是维护大量独立的缓存器。在这两种情况，在一个或多个已知执行那项业务的名称服务器中，解析器被用末梢解析器取代，末梢解析器充当到位于递归服务器的解析器的前端。带末梢解析器的信息流结构如图5所示。末梢解析器递归查询响应外地名称服务器本地主机外地递归服务器末梢解析器中心缓存响应查询递归查询响应图5带末梢解析器的信息流结构注意，在任何情况，考虑到可靠性，只要有可能，域成员总是被复制。2-3惯例域系统有几个处理低层次(但是更基础)问题的惯例。虽然实现者在他自己的系统内有不遵守这些惯例的自由，然而，在所有可由其他主机观察到的行为中，他必须遵守这些惯例。2-3-1首选的名称句法此DNS规范打算使构建的域名规则尽可能通用。这一想法的精髓是任何现有对象的名称，经过尽量小的改变，能够表述为域名。然而，当为对象分配域名时，谨慎的用户将选择既满足域系统规则，又满足对象任何现有的规则的名称，无论这些规则是公开出版的还是由现有程序暗示的。例如，当命名邮件域时，用户应当既满足本备忘录的规则，又满足RFC-822中的规则。当设置新的主机名时，应当遵守旧的HOSTS.TXT规则。这可避免当旧软件被转换为用户域名时出现的问题。就许多使用域名的应用(例如，邮件，TELNET)来说，下述句法产生的问题很少。domain::=subdomain|subdomain::=label|subdomain.labellabel::=letter[[ldh-str]let-dig]ldh-str::=let-dig-hyp|let-dig-hypldh-strlet-dig-hyp::=let-dig|-let-dig::=letter|digitletter::=52个字母表字符中的任何一个(A到Z的大写和a到z的小写)digit::=0到9十个数字中的任何一个注意，尽管在域名中大小写字母是允许的，但是对大小写不做区别。即，两个名称有相同的拼写，但有不同的大小写，被看作是相同的。标签必须遵守ARPANET主机名称规则。它们必须以字母开始，以字母或数字结束，内部字符仅可以是字母、数字和连字符号。对长度也有某些限制。标签必须是63个字符或更少。例如，下述字符串等同于互联网中的主机：A.ISI.EDUXX.LCS.MIT.EDUSRI-NIC.ARPA2-3-2数据传送顺序在本文件中介绍的首部和数据的传送顺序被分解到八位位组层次。每当图表显示一组八位位组时，这些八位位组的发送顺序采用以英语阅读它们时通常采用的顺序。例如，在图6中，八位位组以它们编号的顺序发送。101234567890123450123456图6八位位组的发送顺序每当八位位组代表数字量时，图中最左边位是高阶或最高有效位。即，标记为0的位是最高有效位。例如，图7是值170(十进制)的二进制值表示。1010101001234567图7值170(十进制)的二进制值表示类似，每当多八位位组字段代表数字量时，整个字段的最左边位是最高有效位。当传送多八位位组量时，首先传送最高有效八位位组。2-3-3字符的大小写作为此正式协议一部分的DNS的所有部分，字符串(例如，标签，域名，等)间的所有比较均不区分大小写。目前，这个规则在整个域系统执行，没有例外。然而，将来超出目前应用的添加，可能需要在名称中使用完全的二进制八位位组的能力，所以，尝试用7位ASCII码保存域名，或者尝试使用特殊字节终止标签，等，应当避免。当数据进入域系统时，只要有可能，它的原始大小写应当被保留。在有些情况下这难以做到。例如，如果两个RRs被保存在数据库中，一个为x.y，另一个为X.Y，它们实际上被保存在该数据库的同一位置，因此，只有一种大小写被保存。基本原则是：仅当数据用于在数据库中定义结构时可以不顾及大小写，以及当以不区分大小写的方式比较时两个名称相同。必须尽量不丢失区分大小写的数据。因此，当x.y和X.Y数据都可能在x.y或X.Y单一位置下保存时，决不能将a.x和B.X数据保存在A.x、A.X、b.x或b.X下。一般来说，这保存了域名的第一个标签的大小写，但是强制内部节点标签的标准化。输入数据到域数据库的系统管理员应当务