RFC1035(中文)域名-实现及标准.pdf
《RFC1035(中文)域名-实现及标准.pdf》由会员分享，可在线阅读，更多相关《RFC1035(中文)域名-实现及标准.pdf（35页珍藏版）》请在冰点文库上搜索。
本文翻译者：
weicq2000（2012-10-9，）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）来说，下述句法产生的问题很少。
:
=|:
=|.:
=:
=|:
=|-:
=|:
=52个字母表字符中的任何一个（A到Z的大写和a到z的小写）:
=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下。
一般来说，这保存了域名的第一个标签的大小写，但是强制内部节点标签的标准化。
输入数据到域数据库的系统管理员应当务必指出他们以大小写一致的方式提供给域系统的数据，如果他们的系统是区分大小写的。
在域系统中的数据分发系统将确保采用一致的表示法。
2-3-4大小限制DNS中的各种对象和参数均有大小限制。
列示它们如下。
其中一些能够方便地改变，其他的更为基础。
标签63个八位位组或低于名称255个八位位组或低于TTL有正负号的32位数的正值UDP消息512个八位位组或低于第3章域名空间和资源记录（RR）定义3-1名称空间定义消息中的域名用标签序列来表示。
每个标签被表示为一个八位位组长度字段，再加上那个八位位组的数目。
因为每个域名用根的空标签结束，域名由零长度字节终结。
每个长度八位位组的高阶2位必定是零，此长度字段的其余6位限制标签为63个八位位组或更少。
为了简化实现，域名的总长度（即，标签八位位组和标签长度八位位组）被限制在255个八位位组或更少。
虽然标签可以包括任何采用八位位组（这些八位位组构成标签）的8位值，强烈建议标签遵循在本备忘录其他部分介绍的首选句法，它与现有的主机命名约定兼容。
名称服务器和解析器必须采用不区分大小写的方式比较标签（即，A=a），假设采用零奇偶校验的ASCII。
非字母代码必须严格匹配。
3-2资源记录定义3-2-1格式所有RRs有相同的顶层格式，如图8所示。
TYPE0123456789012345111111NAMECLASSTTLRDLENGTHRDATA图8RRs顶层格式图8中：
NAME所有者名称，即，这个资源记录匹配的节点的名称。
TYPE包含RRTYPE代码之一的2个八位位组。
CLASS包含RRCLASS代码之一的2个八位位组。
TTL32位有正负号整数，它规定应当再次咨询信息源之前此资源记录可以被缓存的时间间隔。
零值被解释为该RR仅能用于正在进行的业务，不应当被缓存。
例如，总是将零TTL分配给SOA记录，以便禁止缓存。
零值也可以用于极短暂的数据。
RDLENGTH无正负号16位整数，它规定以八位位组计的RDATA字段的长度。
RDATA可变长度八位位组串，它描述资源。
这个信息的格式按照资源记录的TYPE和CLASS改变。
3-2-2TYPE值TYPE字段用于资源记录。
注意，这些类型是QTYPEs的子集。
TYPE值和含意A1，主机地址NS2，权威名称服务器MD3，邮件目的地（被废弃，使用MX）MF4，邮件转发器（被废弃，使用MX）CNAME5，别名的正则名称SOA6，标记权威区域的开始MB7，邮箱域名（试验）MG8，邮件组成员（试验）MR9，邮件重新命名域名（试验）NULL10，空RR（试验）WKS11，众所周知的业务描述PTR12，域名指针HINFO13，主机信息MINFO14，邮箱或邮件列表信息MX15，邮件交换TXT16，文本字符串3-2-3QTYPE值QTYPE字段出现在查询的问题部分。
QTYPE是TYPEs的超集，因此所有TYPEs是合法的QTYPEs。
此外，定义有下述QTYPEs：
AXFR252，请求整个区域传送MAILB253，请求相关邮箱记录（MB、MG或MR）MAILA254，请求邮件代理RRs（被废弃，参阅MX）*255，请求所有记录3-2-4CLASS值CLASS字段出现在资源记录中。
定义有下述CLASS助记符和值：
IN1，互联网CS2，CSNET类（被废弃，仅在某些被废弃的RFCs中用于举例）CH3，CHAOS类HS4，赫西奥德（Hesiod）Dyer873-2-5QCLASS值QCLASS字段出现在查询的问题部分。
QCLASS值是CLASS值的超集；每一个CLASS都是合法的QCLASS。
除了CLASS值以外，定义有下述QCLASes：
*5，任何类3-3标准RRs在所有类中，下述RR定义预期会出现，至少有可能。
尤其是，NS、SOA、CNAME和PTR将在所有类中使用，并且在所有类中有相同格式。
因为它们的RDATA格式是已知的，在这些RRs的RDATA部分中的所有域名可以压缩。
是表示为一系列标签的域名，并被零长度标签终止。
是单一长度八位位组，再加上那些字符的数目。
被看作是二进制信息，其长度最多可达256个字符（包括长度八位位组）。
3-3-1CNAMERDATA格式CNAMERDATA格式如图9所示。
CNAME图9CNAMERDATA格式图9中：
CNAME一个，它规定所有者的正则或主要名称。
该所有者名称是别名。
CNAMERRs不引起附加部分处理，但是在某些情况下，名称服务器可以选择以正则名称重新开始查询。
更详细内容请参阅RFC-1034中有关名称服务器逻辑的介绍。
3-3-2HINFORDATA格式HINFORDATA格式如图10所示。
CPUOS图10HINFORDATA格式图10中：
CPU一个，它规定CPU的类型。
OS一个，它规定操作系统的类型。
CPU和OS的标准值可在RFC-1010中找到。
HINFO记录用于捕获关于主机的一般信息。
主要用于诸如FTP等协议，当同样类型的计算机之间或操作系统之间交谈时，FTP协议可以使用特殊的程序。
3-3-3MBRDATA格式（试验）MBRDATA格式（试验）如图11所示。
MADNAME图11MBRDATA格式图11中：
MADNAME一个，它规定有指定邮箱的主机。
MB记录引起附加部分处理，该处理查找对应MADNAME的A类RRs。
3-3-4MDRDATA格式（被废弃）MDRDATA格式（被废弃）如图12所示。
MADNAME图12MDRDATA格式（被废弃）图12中：
MADNAME一个，它规定有该域的邮件代理的主机，该邮件代理应当能够交付该域的邮件。
MD记录引起附加部分处理，该处理查找对应MADNAME的A类记录。
MD已经被废弃。
新机制的细节请参阅MX的定义和RFC-974。
处理主文件中发现的MDRRs的推荐策略是拒绝它们，或者将它们转换为具有优先权为0的MXRRs。
3-3-5MFRDATA格式（被废弃）MFRDATA格式如图13所示。
MADNAME图13MFRDATA格式（被废弃）图13中：
MADNAME一个，它规定有该域的邮件代理的主机，该邮件代理将接收转发到该域的邮件。
MF记录引起附加部分处理，该处理查找对应MADNAME的A类记录。
MF被废弃。
新机制的细节请参阅MX的定义和RFC-974。
处理主文件中发现的MDRRs的推荐策略是拒绝它们，或者将它们转换为具有优先权为10的MXRRs。
3-3-6MGRDATA格式（试验）MGRDATA格式如图14所示。
MGMNAME图14MGRDATA格式图14中：
MGMNAME一个，它规定邮箱，该邮箱是由域名规定的邮件组的成员。
MG记录不引起附加部分处理。
3-3-7MINFORDATA格式（试验）MINFORDATA格式如图15所示。
RMAILBXEMAILBX图15MINFORDATA格式图15中：
RMAILBX一个，它规定负责邮件列表或邮箱的邮箱。
如果这个域名命名根，MINFORR的所有者负责它自己。
注意，许多现有的邮件列表对于邮件列表X的RMAILBX字段使用邮箱X-请求，例如，Msgroup的Msgroup-请求。
这个字段提供更多的通用机制。
EMAILBX一个，它规定邮箱，该邮箱将接收与邮件列表或由MINFORR的所有者指定的邮箱有关的出错消息（类似ERRORS-TO：
已经被建议的字段）。
如果这个域名命名根，应当将错误返回给消息发送者。
MINFO记录不引起附加部分处理。
虽然这些记录能够与简单的邮箱联系起来，通常用邮件列表使用它们。
3-3-8MRRDATA格式（试验）MRRDATA格式如图16所示。
NEWNAME图16MRRDATA格式图16中：
NEWNAME一个，它规定邮箱，该邮箱是指定邮箱的适当重新命名。
MR记录不引起附加部分处理。
MR的主要应用是作为用户（该用户已经移动到不同的邮箱）的转发条目。
3-3-9MXRDATA格式MXRDATA格式如图17所示。
EXCHANGEPREFERENCE图17MXRDATA格式图17中：
PREFERENCE16位整数，它规定在同一所有者内，众多RR间，给与这个RR的优先权。
值越低优先权越高。
EXCHANGE一个，它指定愿意为所有者名称充当邮件交换的主机。
MX记录引起针对由EXCHANGE指定的主机的、A类型附加部分处理。
MXRRs的使用在RFC-974中详细介绍。
3-3-10NULLRDATA格式（试验）NULLRDATA格式如图18所示。
图18NULLRDATA格式在RDATA字段中可以放任何东西，只要它小于等于65535个八位位组。
NULL记录不引起附加部分处理。
在主文件中不允许存在NULLRRs。
在某些DNS的试验性扩展中，NULLs用作占位符。
3-3-11NSRDATA格式NSRDATA格式如图19所示。
NSDNAME图19NSRDATA格式图19中：
NSDNAME一个，它规定主机，对于指定的类和域，该主机应当是权威的。
NS记录不仅引起定位A类型记录的通常的附加部分处理，而且当在转介中使用时，引起特定区域（在该区域内，NS记录作为胶信息驻留。
）搜索。
NSRR表明应当期盼命名的主机有以指定类的所有者名称开始的区域。
注意，该类可以不指出应当用于与该主机通信的协议族，尽管该类一般是强烈暗示。
例如，作为或者是互联网（IN）或者是Hesiod（HS）类信息的名称服务器的主机，当它被查询时，一般使用IN类协议。
3-3-12PTRRDATA格式PTRRDATA格式如图20所示。
PTRDNAME图20PTRRDATA格式图20中：
PTRDNAME一个，它在域名空间中指向某个位置。
PTR记录不引起附加部分处理。
这些RRs在特定的域中使用，以便在域空间中指向某个其他位置。
这些记录是简单的数据，它们不暗示任何类似由CNAME（它标识别名）执行的处理的特殊处理。
具体举例，请参阅IN-ADDR.ARPA域介绍。
3-3-13SOARDATA格式SOARDATA格式如图21所示。
MNAMESERIALRNAMEREFRESHRETRYEXPIREMINIMUM图21SOARDATA格式图21中：
MNAME名称服务器的，该名称服务器是这个区域的数据的起源或主要源。
RNAME一个，它规定负责这个区域的个人的邮箱。
SERIAL该区域的原始副本的无正负号32位版本号。
区域传递保存这个值。
这个值叠起（wrap），并且应当使用系列空间算法比较这个值。
REFRESH区域应当被刷新前的32位时间间隔。
RETRY应当重试失败的刷新前，应当消逝的32位时间间隔。
EXPIRE32位时间值，它规定时间间隔（即，在区域不再是权威的之前可以消逝的时间间隔）的上限。
MINIMUM无正负号32位最小值
升级会员 