万网DNS协议概述.docx
《万网DNS协议概述.docx》由会员分享，可在线阅读，更多相关《万网DNS协议概述.docx（34页珍藏版）》请在冰豆网上搜索。
万网DNS协议概述
DNS协议概述
域名的概念与机制
1.介绍
本文主要介绍域名（DNS）的一些机制及实现方法，下面我们就具体看一下它的情况。
1.1.域名的历史
产生域名的的根本动机在于管理方便，原来的主机名与IP地址映射是保存在NIC的hosts.txt文件中的，当时因为主机数量少，这个文件也不经常变化，因此其它主机几天一次从NIC的主机上下载这个文件进行主机名和IP地址映射就可以了。
但随着网络的发展，这种方法变得无法使用，因为经常会有主机要求下载，对NIC的主机造成巨大的压力，而且也不能保证服务的质量。
许多局域网用户希望自己管理自己的主机名，而不希望等NIC许多天把自己的主机名加在hosts.txt文件中，有些组织也希望有自己的名字空间配置。
是需要一个能够简单管理的方法了。
最后决定使用层次式的名字空间组织方案，以.为分隔标准不同的层次。
整个名字空间以分布式数据库管理。
请看阅读前不要把平常的域名和这里的域名系统混在一起。
最好的方法就是把原来的观念忘记了，看现在的新东西。
1.2.DNS设计目标
DNS的设置目标影响了它的结构，主要目标是对资源有一个一致的名字空间，为了避免不同编码带来的问题，需要包括网络标记，地址，路由或其它信息作为名字的一部分。
出于对实验数据的分析，看来分布式的存储条件是必须的。
要在获取数据的代价和数据准确性之间有一个平衡。
需要对名字所代表的资源类型有一个标记。
要支持多协议访问。
名字服务器操作独立于通信系统。
应该能够使用不同的机器都能够使用这一系统，使用的方法可能不同，但是都要能够使用。
1.3.基于使用的一些假设
设计系统时是基于下面假设进行的：
数据库的初始大小和使用系统的主机成正比，但最后数据库的大小会和用户的数目成正比，这一过程会发生在一些资源（如邮箱和其它一些要加入到域名系统中的信息）进入系统开始；大部分的数据改变比较慢，但系统能够对改变有一些快速的适应。
由相应的组织负责分布式数据库的维护。
域名系统的用户可以选择自己喜欢的主机。
因为其中的数据十分敏感而且重要，因此一定要保证正确性，如果因为主机或网络失败而造成无法为用户服务，用户要以原来的数据为准，不要自己胡乱想一个数据就用。
在查询的时候要避免循环查询，一种方法是将未找到这一信息返回给用户，让用户再找新的主机寻找相应的地址，一种是由主机找别的主机寻找相应的地址，找到后由相应的主机返回地址给用户，这两个方法各有好处。
域名系统假设所有的数据是在一个主文件中保存，这个主文件的内容分布存储于系统中的各台主机上。
用户通过标准的查询程序resolover查询。
主文件的标准形式使得它可以在不同主机间进行传输（利用FTP，电子邮件等方式）。
本地可以使用文本编辑器进行管理，然后将这个文件传输到名字服务器那里，然后通知名字服务器的管理员加载这个文件就是了。
对于resolver来说，配置好的名字服务器是地址信息的主要来源。
域名系统定义了访问数据的过程和访问其它名字服务器的方法，它还定义了缓冲的大小和更新缓冲的时间等配置信息。
系统管理员需要提供：
区域（zone）边界定义
主文件数据
主文件的更新
更新策略描述
域名系统需要提供：
源数据的标准格式
查询数据库的标准方法
多其它名字服务器上更新数据的标准方法
1.4.DNS组成
DNS由下面三个部分组成：
域名空间和资源记录，域名空间是一个树状结构，资源记录是与名字相关的一些数据。
从概念上说，每个结点和域名空间树的叶子结点都有一定的信息，而查询是要查询出一些与之相关的特定信息。
名字服务器是服务器程序，它保留域名树结构和相应的信息，它可以缓冲各种数据，保存域名树中的任何部分，但是通常它保存域名空间的一个子集，如果需要查询其它信息可以通过指向其它名字服务器的地址寻找。
这个名字服务器是这一部分的认证权威，所有的认证信息组成一个单元称为区，这些区可以分布于不同的服务器上以保证数据的冗余。
resolver是向名字服务器提出查询请求并将结果返回给客户的程序，它必须可以访问至少一个名字服务器，并将结果直接返回给用户或向别的名字服务器查询。
它通常是用户可以访问的系统方法，在resolver和用户程序之间不需要协议。
下面我们通过三个不同的角度来看看它们的相互关系：
从用户的角度，域名系统可以通过简单的过程或操作系统调用来调用本地resolver进行查询。
域名空间包括一个单独的树，用户可以从树中的任何一个部分查询信息。
从resolver的角度，域名系统由一些名字服务器组成，每个服务器有域树的整个或部分数据，resolver将这些数据库视为基本是静态的。
从名字服务器的角度，域名系统由称为区（zone）的本地数据集组成，名字服务器必须定期从主备份上更新自己区内的数据，它还必须处理从resovler传送来的查询请求。
2.域名空间和资源记录
2.1.定义和名词
域名空间是树状结构，每个结点和资源集相对应（这个资源集可能为空），域名系统不区别树内结点和叶子结点，统称为结点。
每个结点有一个标记，这个标记的长度为0到63个字节。
不同的结点可以使用相同的标记。
0长度的标记（空标记）为根记录保留。
结点的域名是从结点到根的标记组成的。
这些标记对大小写不敏感，这就是说，A和a对域名是等效的。
但是你在收到域名时最好保留它的大小写状态以便以后的服务扩展便于使用。
用户需要输入域名时，每个节点的标记长度不管多长，总要以点分隔。
绝对域名的最后总以点结束，例如"poneria.ISI.EDU."，而相对域名则不这样，它由本地域指明位置即可。
相对域名相对于一个公认的域名或相对于用作搜索列的一串域名。
相对名通常在用户接口出现，在用户接口，表示方法因实现不同而不同，相对域名也出现在主文件中，主文件相对于一个源域名而设立。
为了简化实现，整个域名的长度不得大于255个字节。
域由域名标记，它由其下的域组成。
如果一个域包括在另一域中，则称它为这个域的子域。
我们可能通过表示很直观的看出。
如A.B.C.D是B.C.D，C.D，D和""的子域。
2.2.管理规范
作为策略，DNS技术说明未说明一个特定的树结构或什么规则来选择标记，此说明希望达到的目的是越简单越好。
应用程序的开发可以不管名字空间的边界和名字服务器的存在。
这不是说没有规矩地乱来，而是把规则制定得开放以便于处理问题，树的不同部分可以有不同的规则。
例如IN-ADDR.ARPA分布在网络各处，用于将网络或主机号转换为主机名，而NetBIOS域是平面式的，原因很简单，这样便于应用。
但是，对于名字空间的通常部分，我们还是有规定的，目的是为了应用起来比较方便。
低层域名最终被分为多个区，这样的域应该在顶层域上提供一个标记使最终的解析可能不必重名字就可以完成。
在管理的时候，老的软件可能不支持结点标记中的数字，特殊字符。
2.3.技术规范
在DNS能够被用来为某些种类的结点保存名字信息前，必须满足下面两个条件：
要有在对象名和域之间映射的规则，这个规则描述了关于对象的信息如何被访问
需要有描述对象的RR类型和数据格式
这些规则可烦可简，规则者要考虑到对现在格式和以后格式的兼容问题。
多映射或映射分层是必须的。
对于主机，映射取决于主机名的现有格式，它是通常文本表示域名的子集，加上描述主机地址的RR格式。
因为我们需要从地址到主机的可靠映射，所以定义了将地址映射到IN-ADDR.ARPA域的方法。
对了邮箱，映射会复杂一些。
通常的邮件地址@，可以通过将转换为一个单独的标记，不要管里面的点，将通过平常的域名解析方法进行解析，这两部分组合形成一个域名。
因此邮件地址HOSTMASTER@SRI-NIC.ARPA，会变为HOSTMASTER.SRI-NIC.ARPA。
通常的用户不关心这些定义的规则，但用户应该理解它们使用的是一种的许多要求的综合产物，有要求兼容老产品的，有要求添加新功能的。
2.4.例子
下图是现在域名系统的一个部分，它在本文中还会经常被用到。
请注意，这个树只是实际树的一个小小的子树。
|
+---------------------+------------------+
|||
MILEDUARPA
|||
+-----+-----+|+------+-----+-----+
|||||||
BRLNOSCDARPA|IN-ADDRSRI-NICACC
|
+--------+------------------+---------------+--------+
|||||
UCIMIT|UDELYALE
|ISI
||
+---+---+|
|||
LCSACHILLES+--+-----+-----+--------+
||||||
XXACVAXAVENERAMockapetris
在此例中，根域有三个子域：
MIL，EDU和ARPA，而LCS.MIT.EDU域有一个子域XX.LCS.MIT.EDU，其它的节点也是域。
2.5.命名规则
DNS的命名规则是为了使对域名的命名比较统一。
也就是要将任何现存的对象都可以在最小改动的情况下变为域名。
谨慎的使用者会选择域名适合域名系统和应用程序。
例如在命名邮件域名时，使用者会同时遵守相应的邮件协议。
这就使对老软件的兼容性提高了。
下面的规则是一个较少引起问题的规则:
:
:
=|""
:
:
=
:
=[[]]
:
:
=|
:
:
=|"-"
:
:
=|
:
:
=大小写的A到Z，共52个
:
:
=0到9
请注意：
域名内不分大小写。
标记必须遵守ARPANET主机名规则，它要求主机名必须以字母开始，以字母或数字结束，中间的可以是数字字母或连字符，长度没有限制。
但标记必须少于63个字符。
下面的字符串就表示了APARNET中的主机：
A.ISI.EDUXX.LCS.MIT.EDUSRI-NIC.ARPA
2.6.资源记录
域名标记结点，每个结点都有资源信息集，些集可以为空。
资源信息集和由分离资源集（RR）的特殊名字相关联。
在集中的RR顺序没有关系，标记有这东西就是了，它不用由名字服务器，resovler或DNS的其它部分保存，只在这儿有。
特定的RR我们认为有以下几个：
owner
RR能够被找到的域名
它是一个16位值，指定RR内的资源类型，它指一个抽象资源，具体的标记有以下几个：
A
主机地址
CNAME
一个拟名的统一命名
HINFO
标记由主机使用折CPU和OS
MX
标记用于域的邮件交换资源
NS
此域的权威认证名字服务器
PTR
指向其它域名空间的指针
SOA
标记区认证权威的开始
class
它是一个16位值，标记协议族或某一个协议实例，本文中使用IN代表internet系统，CH代表Chaos系统
TTL
它是RR的生存时间，它是32位整数，单位是秒，它主要用于resolver缓存RR多长时间
它是一种类型，有时是依赖于数据的类，它描述了以下资源：
A
对于class是IN的，它是一个32位IP地址，对于CH，它是后面跟一个16位八进制Chaos地址的域名
CNAME
域名
MX
作为一个域的邮件服务资源的主机名，主机名后有一个16位的配置值
NS
主机名
PTR
域名
SOA
一些域
拥有资源的名字通常是隐式的，不构成RR的一部分。
TTL时间只影响缓冲内的数据，不影响区内的已经保存的认证数据。
TTL通常由管理员设置，TTL=0表示禁止缓冲。
RDATA内的数据是二进制串和域名的混合。
域名通常使用指针指向DNS内的其它数据。
2.6.1.RR的文本表示
RR在DNS中是以二进制形式表示的，而在名字服务器或resolver中保存的时是经过压缩编码处理的。
本文中我们采用相同于主文件中表示的表示方法，也就是不压缩的方法，以便显示RR的内容。
行开始时给出谁拥有RR，如果这一位置空出，就表示本行RR的拥有者和上面RR的拥有者是一个。
其后是TTL，type和RR的class。
RR的RDATA部分是在当前数据的表示类型的基础上得到的。
下面是一些RR的例子：
ISI.EDU.MX10VENERA.ISI.EDU.
MX10VAXA.ISI.EDU.
VENERA.ISI.EDU.A128.9.0.32
A10.1.0.52
VAXA.ISI.EDU.A10.2.0.27
A128.9.0.33
其中我们注意到MX那一部分，它的RDATA部分有是一个16位数后面跟一个域名组成。
其它的也就不说了。
本例子显示了6个RR，第三个域名有两个RR。
下面是一个例子，它显示在不同的class下如何表示：
XX.LCS.MIT.EDU.INA10.0.0.44
CHAMIT.EDU.2420
2.6.2.别名和统一命名
现存的系统中有时会对相同的资源有不同的命名，不但主机是这样，邮箱也是这样，不同的名字指向的是同一个位置。
大部分系统都能够对多个名字指定一个是统一命名的结果，另外的是别名。
域名系统提供使用统一命名的机制（CNAMERR），CNAMERR标记它的owner名为别名，并指出在RDATA部分的相应统一命名。
如果一个结点存在CNAMERR，不应该有其它的数据，这保证了统一命名和它的别名不能不同。
这也使得缓冲的CNAME可以不用检索认证权威服务器就可以提供服务。
在有CNAMERR时，DNS软件如果查询不到与域名相关的资源，它会检查资源集中是不是有一个有匹配class的CNAME，如果有，名字服务器返回的应答中包括这个CNAME记录，并根据在CNAME中指定的数据开始新的查询。
下面我们看一个例子，假设名字服务器处理对USC-ISIC.ARPA的查询，它要求查询A信息，下面是RR的内容：
USC-ISIC.ARPAINCNAMEC.ISI.EDU
C.ISI.EDUINA10.0.0.52
这两个RR都作为响应返回，而只查询CNAME的*查询则只返回CNAME。
RR中指向其它名字的域名应该指向主名而不是别名，这就避免了查询中过多的转向查询。
例如，对于上面的RR，它的IN-ADDR.ARPA记录应该是：
52.0.0.10.IN-ADDR.ARPAINPTRC.ISI.EDU
最后指向的是C.ISI.EDU，而不是USC-ISIC.ARPA，当然一个健壮的域名软件不会因为提供了循环的CNAME而失败。
2.7.查询
查询就是发向名字服务器要求响应的一个请求。
在Internet上，这种请求以UDP或TCP传输，名字服务器的响应可以是查询结果，或是另一个名字名字器地址，要么就是一个错误信息。
通常用户并不直接发送请求，而是向resolver发送请求，由resolver依次将一个或多个请求发向名字服务器，并负责处理错误情况。
请求和响应有标准格式，它们包括一个头和数个固定的域，然后是包括查询参数和RR的四个部分。
头中最重要的域是称为操作符的东西，它指出要进行什么操作。
在所有可能的16个值中，标准查询是必须的，反向查询和状态查询是可选的，有一个完全查询已经过时，其它的还未指定。
而上面的提到的四个部分如下：
Question
包括查询名和其它参数
Answer
包括查询结果的RR
Authority
包括一个RR，但这个RR包括的是另一个名字服务器
Additional
包括了一个些在其它部分中使用RR时会有用的信息
请注意：
因头中操作符（码）的不同，这些部分的内容可能不同，但格式可是一样的。
2.7.1.标准查询
标准查询指定一个目标域名（QNAME），查询类型（QTYPE）和查询类（QCLASS），然后寻找相应的RR，这类的查询占了DNS查询的绝大部分，如果未有特殊说明，一般都指这种查询。
QTYPE和QCLASS域为16位，是定义的type和class的超集。
QTYPE域可以包括：
：
和相应类型相匹配的RRmatchesjustthattype.（e.g.,A,PTR）.
AXFR：
由QTYPE指定的特定区
MAILB：
和RR相关的所有邮箱
*：
所有RR类型
QCLASS域可以包括：
：
和相应类相匹配的RR
*：
所有的RR类
使用查询域名，QTYPE和QCLASS，名字服务器就会检查相应的RR，服务器可以返回一个可能包括相应RR的服务器名。
例如：
希望向Mockapetris@ISI.EDU发邮件，应用程序会向resolver要求了解关于ISI.EDU的信息，会产生下面的查询：
QNAME=ISI.EDU，QTYPE=MX，QCLASS=IN，可能产生响应的区可能是：
ISI.EDU.MX10VENERA.ISI.EDU.
MX10VAXA.ISI.EDU.
随此以外还有：
VAXA.ISI.EDU.A10.2.0.27
A128.9.0.33
VENERA.ISI.EDU.A10.1.0.52
A128.9.0.32
服务器假设如果请求者希望得到邮件交换（exchange）信息，它会马上请求交换服务器的地址，所以找到两个。
这里需要注意QCLASS=*类型的查询，因为服务器不可能知道了解域名系统中所有类的可用信息，它也不是所有类的认证权威，因此这类查询不能得到认证。
2.7.2.反向查询（可选）
名字服务器可以反映资源和域名之间的映射关系。
标准查询可以对将域名映射到SOARR，相应的反向查询则映射SOARR到域名。
对于名字服务器来说这种实现是可选的，但是所有的名字服务器必须至少能够理解反向查询消息，不能说发来的消息当不知道。
域名系统不保证反向查询的完全和唯一性，因为系统是按照域名而非主机地址或其它资源类型安排的。
反向查询主要用于调试，以及和数据库支持相关的活动中。
反向查询可以不返回正确的TTL，也不标明RR是某个集合中的一员，我们不知道它是不是唯一的，因此反向查询的结果不缓冲。
反向查询对于映射主机地址到主机名是不合适的，此时要用IN-ADDR.ARPA域。
2.8.状态查询（实验中）
没有定义
2.9.完整查询（过时的）
这里就不说了，以后可能会支持重设计（redegsign）服务。
3.名字服务器
3.1.介绍
名字服务器保存了许多信息，这些信息组成了域数据库。
数据库被分为区，这些区在不同的服务器上保存。
服务器可以有不同的可选函数和数据源，它最基本的工作是响应查询，它的响应是是一种简单的形式进行的，响应可以仅根据本地数据作出，也可以根据其它相关服务器而做出。
一个给定的区可以根据不同的服务器来保证其有效性，通过管理命令，用户可以查询由至少两台服务器保存的一个区上的数据，多台服务器保存信息保证了适当的冗余。
给定的名字服务器通常支持一个或多个区，但只充当域树一小部分的认证权威。
它有一些缓冲的非认证信息，这些信息是域树其它部分的，在响应查询时名字服务器会给出什么时它认证的，什么是它缓冲的。
3.2.数据库如何被划分为区
划分数据库有两种方法，一种是根据class，另一种是在名字空间的结点间进行分隔，而产生，我们称这种分隔为cut。
class（以下我们称为类）分隔比较简单，在传统上，名字空间和所有类是一回事，分隔的类可被认为是一系列平行的名字空间树。
创建新类的通常理由是要为已有的类型创建新的数据格式，或是为了对已有的名字空间进行分隔管理。
在一个类中可在两个相邻的结点进行cut（以下我们称为切分），在所有的切分完成后，相连空间的每个组就是一个独立的区。
此区是在相连区域内所有数据的认证权威。
这种方法意味着所有的区至少有一个结点，域名和所有特定区内的结点是相连的。
给定的树型结构一定有一个点更加靠近根，我们用这个点标记这个区。
虽然可能没什么用，也可以将每个域名分在不同的区中，也可以让所有的结点在一个区中。
另外，数据库也可根据不同企业对名字的控制进行划分，有些企业可能希望自己管理某一部分域名子树，这时这个企业就可以对域名进行相应的增加或删除操作，可以自己加入自己的下一级域名。
当然，这个企业也可以对自己管理的名字空间进行进一步划分。
3.2.1.技术问题
描述一个区的数据有四部分：
区中所有结点的认证数据
定义区内顶结点的数据（此数据可被认为是认证数据的一部分）
描述代表子区的数据
访问服务器子区的数据（我们也称为?
#30456;关?
#65288;glue）数据）
所有这些数据以RR的形式表示，所有区可以被RR集的形式描述。
通过传输RR，可以传输整个区，具体的方法可以是通过FTP传输相应的文本文件，或是通过网络消息的形式传输。
一个区的认证数据是所有的RR，这些RR和树中所有的结点是关联的，要么就是切分后的结点关联。
描述顶结点的RR对于区的管理特别重要，这些RR有两种类型，名字服务器RR，它描述了区中的服务器列表；另一种是SOARR，它描述的区的管理参数。
描述切分的RR是NSRR，因为切分是在结点间进行的，所有RR不是区认证数据的一部分，它应该和相应的在子区内的顶结点一致。
因为名字服务器通常和区边界相关，NSRR只在一些区的顶结点上有。
在组成一个区的数据中，NSRR在顶层结点和在边界底的切分处出现，不在其它地方。
区结构所要实现的一个目标是任何区都有足够的数据可以和任何子区建立通信。
也就是说，父区有足够的信息可以访问子区中的任何一台名字服务器。
NSRR命名了子区服务器，它不足以完成上面的要求，因此有了名字但仍然不知道地址。
特别地，如果名字服务器的名字在子区内是它自己，我们就无法知道通过它的任何信息了。
为了解决这一问题，区中包括了一个关联RR，它不是认证权威数据的一部分，但它表示了服务器的地址。
如果名字服务器名在切分下，就需要这些RR了。
3.2.2.管理问题
当有些组织希望掌握自己的域时，第一步是标记合适的父区，然后取得父区中管理结点的许可来管理。
管理的时候没有什么具体的技术问题，可是还是有一些规则的，对
升级会员 