|
发信人: sage.cao(sage) 整理人: amac(2002-05-05 08:55:44), 站内信件 |
| 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域的方法。 对了邮箱，映射会复杂一些。通常的邮件地址<local-part>@<mail-domain>，可以通过将<local-part>转换为一个单独的标记，不要管里面的点，将<mail-domain>通过平常的域名解析方法进行解析，这两部分组合形成一个域名。因此邮件地址[email protected]，会变为HOSTMASTER.SRI-NIC.ARPA。通常的用户不关心这些定义的规则，但用户应该理解它们使用的是一种的许多要求的综合产物，有要求兼容老产品的，有要求添加新功能的。 2.4. 例子 下图是现在域名系统的一个部分，它在本文中还会经常被用到。请注意，这个树只是实际树的一个小小的子树。 | +---------------------+------------------+ | | | MIL EDU ARPA | | | +-----+-----+ | +------+-----+-----+ | | | | | | | BRL NOSC DARPA | IN-ADDR SRI-NIC ACC | +--------+------------------+---------------+--------+ | | | | | UCI MIT | UDEL YALE | ISI | | +---+---+ | | | | LCS ACHILLES +--+-----+-----+--------+ | | | | | | XX A C VAXA VENERA Mockapetris 在此例中，根域有三个子域：MIL，EDU和ARPA，而LCS.MIT.EDU域有一个子域XX.LCS.MIT.EDU，其它的节点也是域。 2.5. 命名规则 DNS的命名规则是为了使对域名的命名比较统一。也就是要将任何现存的对象都可以在最小改动的情况下变为域名。谨慎的使用者会选择域名适合域名系统和应用程序。例如在命名邮件域名时，使用者会同时遵守相应的邮件协议。这就使对老软件的兼容性提高了。下面的规则是一个较少引起问题的规则: <domain> ::= <subdomain> | " " <subdomain> ::= <label> | <subdomain> "." <label> <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ] <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str> <let-dig-hyp> ::= <let-dig> | "-" <let-dig> ::= <letter> | <digit> <letter> ::= 大小写的A到Z，共52个 <digit> ::= 0到9 请注意：域名内不分大小写。标记必须遵守ARPANET主机名规则，它要求主机名必须以字母开始，以字母或数字结束，中间的可以是数字字母或连字符，长度没有限制。但标记必须少于63个字符。下面的字符串就表示了APARNET中的主机： A.ISI.EDU XX.LCS.MIT.EDU SRI-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. 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那一部分，它的RDATA部分有是一个16位数后面跟一个域名组成。其它的也就不说了。本例子显示了6个RR，第三个域名有两个RR。下面是一个例子，它显示在不同的class下如何表示： XX.LCS.MIT.EDU. IN A 10.0.0.44 CH A MIT.EDU. 2420 2.6.2. 别名和统一命名 现存的系统中有时会对相同的资源有不同的命名，不但主机是这样，邮箱也是这样，不同的名字指向的是同一个位置。大部分系统都能够对多个名字指定一个是统一命名的结果，另外的是别名。域名系统提供使用统一命名的机制（CNAME RR），CNAME RR标记它的owner名为别名，并指出在RDATA部分的相应统一命名。如果一个结点存在CNAME RR，不应该有其它的数据，这保证了统一命名和它的别名不能不同。这也使得缓冲的CNAME可以不用检索认证权威服务器就可以提供服务。在有CNAME RR时，DNS软件如果查询不到与域名相关的资源，它会检查资源集中是不是有一个有匹配class的CNAME，如果有，名字服务器返回的应答中包括这个CNAME记录，并根据在CNAME中指定的数据开始新的查询。下面我们看一个例子，假设名字服务器处理对USC-ISIC.ARPA的查询，它要求查询A信息，下面是RR的内容： USC-ISIC.ARPA IN CNAME C.ISI.EDU C.ISI.EDU IN A 10.0.0.52 这两个RR都作为响应返回，而只查询CNAME的*查询则只返回CNAME。 RR中指向其它名字的域名应该指向主名而不是别名，这就避免了查询中过多的转向查询。例如，对于上面的RR，它的IN-ADDR.ARPA记录应该是： 52.0.0.10.IN-ADDR.ARPA IN PTR C.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域可以包括： <any type>：和相应类型相匹配的RR matches just that type. (e.g., A, PTR). AXFR：由QTYPE指定的特定区 MAILB：和RR相关的所有邮箱 *：所有RR类型 QCLASS域可以包括： <any class>：和相应类相匹配的RR *：所有的RR类 使用查询域名，QTYPE和QCLASS，名字服务器就会检查相应的RR，服务器可以返回一个可能包括相应RR的服务器名。例如：希望向[email protected]发邮件，应用程序会向resolver要求了解关于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 服务器假设如果请求者希望得到邮件交换（exchange）信息，它会马上请求交换服务器的地址，所以找到两个。这里需要注意QCLASS=*类型的查询，因为服务器不可能知道了解域名系统中所有类的可用信息，它也不是所有类的认证权威，因此这类查询不能得到认证。 2.7.2. 反向查询（可选） 名字服务器可以反映资源和域名之间的映射关系。标准查询可以对将域名映射到SOA RR，相应的反向查询则映射SOA RR到域名。 对于名字服务器来说这种实现是可选的，但是所有的名字服务器必须至少能够理解反向查询消息，不能说发来的消息当不知道。域名系统不保证反向查询的完全和唯一性，因为系统是按照域名而非主机地址或其它资源类型安排的。反向查询主要用于调试，以及和数据库支持相关的活动中。反向查询可以不返回正确的TTL，也不标明RR是某个集合中的一员，我们不知道它是不是唯一的，因此反向查询的结果不缓冲。反向查询对于映射主机地址到主机名是不合适的，此时要用IN-ADDR.ARPA域。 2.8. 状态查询（实验中） 没有定义 2.9. 完整查询（过时的） 这里就不说了，以后可能会支持重设计（redegsign）服务。 ----   
SAGE = Semi-Automatic Ground Environment 半自动地面防空警备系统[装置]，最早的网络系统 Sage[ seidV ] adj.贤明的, 明智的, 审慎的 n.贤人, 圣人 sage n. 鼠尾草(花语:尊敬，轰轰烈烈的爱......) |
|
[关闭][返回] |