【YD通讯标准】 基于无线应用协议(WAP)的无线域名系统技术要求

ICS33.030
中华人民共和国通信行业标准
YD/T2141-2010
基于无线应用协议（WAP）
的无线域名系统技术要求
Technical reguirement for wireless profiled domain name system inWAP
2010-12-29 发布
2011-01-01实施
中华人民共和国工业和信息化部发布前言
1范围·
2规范性引用文件
3术语，定义和缩略语
3.1 术语和定义
3.2．缩略语…
4概述·
5W-DNS的总体框架结构·
5.1W-DNS的普通功能性框架·
6W-DNS 提供DNS 服务...
7W-DNS提供和IETF协议保持一致的解析器-7.1
解析器·
7.2全W-DNS 解折器·
7.3LPV6 W-DNS解析器
8W-DNS 的特性
8.1基下终端的解析器
8.2W-DNS允许的查询模式
8.3W-DNS客户应用禁止发送多播和广播查询.8.4W-DNS应能够缀存DNS行为响应9W-DNS技术实现要求
9.1要求说明-
9.2主机要求·
9.3在封闭服务域中限制接入要求9.4优化 TTL 属性要求
9.5安全要求
附录A（规范性附录）静态一致性要求·参考文献·
HTYKANIKa-
YD/T 2141-2010
YD/T2141-2010
本标准是参考了开放移动联盟的无线域名解析系统标准（OMA-WAP-DNS-V1_0-20060606-A）以及参考DNS其他相关标准而制定。
本标准附录A是规范性附录，B是资料性附录。本标准白中国通信标谁化协会提出。本标推白中国通信标化协会归。本标准起草单位：北京邮电大学，工业和信息化部电信研究院，中国普天信息产业集团公司，华为技术有限公司。
本标准主要起草人：王、莉、李缺、晓炬、刘、博、杨健、王、雷、丁丹志、孙、毅、李晓炜、下琼，
1范围
YD/T 2141-2010
基于无线应用协议（WAP）的无线域名系统技术要求本标准定义了死线DNS的总体框架服务和终端的DNS客户端功能，并和互联网工程任务组（IFTF）规范保持一致。
本标准适用予基于无线应用协议应用的互操作。2规范性引用文件
下列文件中的条款通过本标准的引用而成为本标推的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准。然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注明日期的引用文件，其最新版本适月于本标准。WAP Forum
IETFRFC1034
ETFRFC1035
ETFRFC1886
IETF RFC2119
IETFRFC2308
WAP-221-CREQ-20010425-a无线应用协议的·-致性要求规范SpecificationofWAPConformance Requirements
域名概念和设施 Domain Nanes -Concepts and Facilitics,November 1987域名—实现与规范 Domain Names - Implementation and Specification,November 1987支持IPy6的DNS扩展DNSExtensionstoSupportIPvcrsion6,December1995用RFC中指示要求级别的关键词Keywords foruseinRFCs toIndicateRequirement Levels,March 1997拒绝缓存的 DNS 查询 Negative Caching of DNS Queries (DNS NCACHE),March 19983术语、定义和缩略语
3.1术语和定义
密钥Key
用以分配DNS网络实体公共密钥的DNS安全扩展资源记录。3.1.3
轻量型域名系统LightweightDNSETF规定的无线和终端资源使用最小化的DNS。3.1.4
给定的域名系统服务器Provisioned DNS Server给出的DNS客户端连接点的DNS服务器。3.1.5
签名SIG
DNSSec签名记录。
域名空间DomainName Space
域名空问是一个树状结构，瓷源记录是与名字相关的一些数据。从概念上说：每个结点利域名空间1
HTYKANIKa-
YD/T 2141-2010
树的叶子结点都有一定的信息，而查询是要查询出·-些与之相关的特定信息。3.1.7
名字服务器Name Server
服务器程序，它保留域名树结构和相应的信息，可以缓冲各种数据，保存域名树中的任何部分，但是通常它保存域名空问的一个子集，如果要查询其他信息可以通过指向其他名字服务器的地址寻找。这个名字服务器是这一部分的认证权威，所有的认证信息纽成一个单元称为区，这些区川以分布不司的服务器上以保证数据的亢余。3.1.8
解析器Resolvan
向名字服务器提出查询请求并将结果返回给客户的程序，它应可以访问至少一个名字服务器，并将结果直接返回给川户或向别的名字服务器查询。它通常是用户可以访问的系统方法。在解析器和月广程序之间不需婆协议。
根解析器Stub Resolver
根解析器没有缓存，它依赖于主机上的DNS服务器缓存来完成服务。根解析器只能处理递归查询。3.1.10
完全解析器FullResolver
和根解析器相比，完全解析器不仪可以处理递归查询，而且可以处理迭代查询。3.1.11
递归查询RecursiveQuerying
DNS查询以各种不同的方式进行解析，客户端可以使用缓存倍息就地应答查谢。DNS服务器可使用其自身的资源记录信息缓存来应答查询，它也可代表请求落户端查询或联系其他DNS服务器，以便完全解析该名称，并随后将应答返回至客户端。这个过程称为递归查询。3.1.12
送代查询IterativeQuerying
和递归查询模式不同的是，客户端自身也可尝试联系其他的DNS服务器米解析名称。当客户端自行查找吋，它会根掂米自服务器的参考信息，使用基他的独立查询，该过程称作选迭代查询。3.2缩略语
下列缩略语适用丁本标。
DNSSec
Dynamic Host Configuration ProtocoDomain Name System
DNSSecurity
File Transfer Protocol
InternetEngineering TaskForceInternct Protocol
Internct Protocol Control ProtocolPoint-to-Point Protocol
动态主机配置协议
域名系统
域名系统安全性
文本传输协议
互联网工程任务组
万联网协议
互联网协议控制协议
点对点协议
W-HTTP
4概述
Request for Comments
Resource Record
Subscriber Identity Module
Secure Shell
Transmission Control ProtocolTransaction Signature
Time-to-Live
User Datagram Protocol
Wireless Application ProtocolWireless Profiled DNSWww.bzxZ.net
WAP Identity Module
WirelessHypertextTransferProtocolWireless Profiled TCP
请求注解
资源记录
YD/T 2141-2010
签署者认证模块
安全外荒
传输控制协议
交易签名
存活时间
用户数据报协议
无线应用协议
无线域名系统
无线应用协议识别模块
无线超文本传输协议
无线传输控制协议
域名系统RFC1034][RFC1035]是一个复制的分等级的分布式数据库系统。域名系统主要由三个部分组成，分别是域名空间、名学服务器和解析器。域名系统提供对互联网操作的基本信息，它的生要间标是对资源有一个一致的名学空间，例如域名与地址。目前的无线网络中，用户对Internet网络的访问过程当中一般都会需要无线应刃协议代理网关的支持。而网络服务提供商可能选择不安装无线应用协议代理网关，或者不允许用户使间接访问无线应用协议代理网关的方式来访问Intermet。然而，对于没有可用的无线应用协议代理网关的情况下，无线应用协议终端必须能够白行执行DNS的查找功能。如本标准第一部分所述，本标准的H的在于支持无线应用协议框架规范WAPARCH中说明的直接接入场景下的IP地址解析。本标推主要从框架上描述了终端执行无线域名系统功能需求。出于无线域名系统客户端能够通过已存在的DNS服务器进行DNS查找，所以对于DNS服务器如何与DNS客户端进行交万并没有进行详细的描述。逆过控制终端上DNS客户端的行为，整个系统的无线资源的使用可以达到最小化。DNS客户端将提高DNS服务器返回无线终端所适应的响应类型。为了使得对丁缓存个数、存储、处理器的要求最小化，在任何可能的情况下都推荐使用轻量型域名系统客户端。其体的操作与终端软件开发者以及网络提供商相关。5W-DNS的总体框架结构
5.1W-DNS的普通功能性框架
W-DNS能够在WAPARCH中给出的如图1所示直接接入框架下，对P地划解析域名时产生适当的请求/响应行为。图1中给定的可连接的DNS服务器可以在本地网络内、外部网络或者互联网的其他地方找到。图1没有阐述DNS所提供的具体方法。尽管这个框架没有代理，服务器端的执行可以选择在网络中整合网关功能，如接入控制和负载管理。为了阐明普通使用情况，图1没有说明附加功能。3
HTYKANIKa-
YD/T 2141-2010
无线应用环境
解折器
W_HTTP
W_TCP/UIp
Weh服务器
无线应用环境
TCP/LDP
6W-DNS提供DNS服务
无线IP路电器
私有网络
给定的LNS服务器
DNS服务
NS服务
TINS客户
TCP/UDE
图1直接接入DNS框架
互联网
Web服务器
光战应用环境
TCP/UDP
给定的DNS服务器
DNS服务
DNS服务
DNS客J
TCP/UDP
当具备W-DNS功能的终端需要请求DNS服务时，W-DNS应该提供相应的机制为终端的DNS客户端配置请求DNS服务的第一·个IP地址。这种功能可以通过执行下面列出的任意-一个机制来实现：WIM/主动的 SIM/用户自定义设置参见 WAP Forum WAP-185-ProvUAB-20010314a 和 WAPForum_.WAP-186-ProvSC-20010710-a:由无线应用协议客户端提供参见WAPForumWAP-184-ProvBoot-20010314-a、WAPForumWAP-183-ProvCont-20010724-aWAP Forum WAP-185-ProvUAB-20010314-a 和WAP Forum_:WAP-186-ProvSC-20010710-a:
PPP/IPCP或者DHCP（依赖于承载，并且由服务侧提供实现），参见ETFRFC1332和ETFRFC2132。
这些机制所配置的信息可以被存储在SIM或者终端设备上。W-DNS的用户代理米决定使/这些机制的优先顺序。参见WAPForumWAP-185-ProvUAB-20010314-a。7W-DNS提供和IETF协议保持一致的解析器7.1解析器
7.1.1把一个用户请求转化为一个查询为了适合本地操作系绕的一种格式，解析器应该采取的第一步是把客户请求转化成为资源记录查询的格式。这种格式需要有一个符合特定查询类型和查询类相匹配的名称。4
YD/T2141-2010
解析器有效地完成它的功能，应能够复用多个请求，所以一般情说下每个未决的请求都在一些状态信息的板块中表现山来。这个状态板块通常含有三个部分，一个表明请求开始时问的时间戳、用来限制请求将要完成的工作量的一些参数、RFC-1034中讨论的SLIST数据结构。时问戳主要用来决定数据库中资源记录是否能够使用。SLIST主要解释了名字服务器和解析器试图查谢的区域。7.t.2发送查询
解析器的基本任务是形成一个能够解析客户请求的查询，并且能够把这个查询指向能够提供信息的名字服务器。解析器通常只会对询问的服务器以权威认证名字服务器资源记录的形式提示，也可能在解析域名统一命名的过程中重建查询，或者重建解析器询问的名学服务器的集合：从丽授权响应给邪些距离解析器期望信息比较近的名字服务器。除了客户请求的信息以外，解析器也应响应自已的服务，来决定它将要沟通的名学服务器的地址。7.1.3处理响应
在处理到达的响应数据报时，第一步是解析该响应，第二步是把响应与当前的解析请求树对应。第一步程序主要包括三个步骤，分别是：a）妥善检查报文头。如果响应是预期的，那么就丢弃那些有问题的数据报。b）解析报文部分，并确定所有的RR的格式都正确。c）可选步骤：检查到达数据的TTL，查找带有长度过大TTL的资源记录。如果资源记录有过长的TTL，例如，一周，那么去奔整个响应，或者把响应中所有TTL都局限到一周。第二步程序主要包括三个步骤，分别是a）一些名字服务器从不同于接受查询地址剂多个地址发送响应。这意味着，解析器不能依赖于来自发送相关香询地址的响应。这个名字服务器的bug在UNIX系统中经常遇到。b）如果解析器反复传送某请求到一-个名字服务器，那么它应该能够使用其中任何一个发送中的崩应。然而，如果它正在使刊响应来估计接入名字服务器的往返时问，那么它必须能够决定哪个发送与响应匹配（并为每个发送出去的报文保持传送次数），或者仅仅根据原始传输计算往返时问。c）名服务器偶尔可能没有某区域的当前拷贝，那么解析器应该把名字服务器从前SLIST中册除并继续。
7.1.4 使用缓存
通常希望解析器能够缓存它在响应中接收的所有数据：因为这些数据可能在应答未来的客户请求时有用。当解析器在一个响应中有一系列棚同名字的资源记录时，在把这些资源记录缓存之前，应该先检查一下缓存中已经存在的资源记录。根据具体情况来决定是否保存响应中的数据。如果响应中的数据有解析过程中是优先级比较高数据，那么它始终是优先考虑的。7.2全W-DNS解析器
为了可以和传统的、普通的DNS服务器进行互操作，W-DNS解析器遵循IETFRFC 1034、IETF RFC1035、ETFRFC2038。另外，w-DNS解析器必须和第8章节所描述的规范保持一致，以便产生一个轻量型协议。
W一DNS解析器只能被安装在支持Pv4网络层或者IPv6网络层或者两者都支持的终端上。7.3[Pv6 W-DNS解析器
安装在支持IPv6的终端上的W-DNS解析器遵循正TFRFC18865
HYYKANiKca
YD/T 2141-2010
8W-DNS的特性
8.1基于终端的解析器
RFC1035中表明，基于终端的解析器可以在根解析器和完全解析器之问进行选择。根解析器没有缓存，它依赖于主机的DNS服务器级存来完成服务。为了便给定的DNS服务器便于进行DNS查询，并且出于对开销最小化的考虑，W-DNS 客户端应至少支持一个根解析器。W-DNS 应用在一个可以保存区域数据的场景下时，也可以支持一个完全服务解析器。8.2W-DNS充许的查询模式
通过使用递归查询模式，而以使解析器和DNS目录服务间的交互最小化，这种方式比选代模式查询使用更少的无线资源。W-DNS客户应首先使用递归查询模式，如果递归查询失效，并月在客户端支持选代查谢模式的情况下，也而以使用迭代查询模式。本标推推祥服务端在接入服务时，宜为DNS客户提供能够递归的DNS服务器。如果服务器端的应用不支持递归查询模式，则要进行选代查询。但因为根解析器只支持递归查询模式，因此为了避免失败，可以在提供服务接入时在客户端使用完全解析器。8.3W-DNS客户应用禁止发送多播和广播查询多播或者广播查询可以导致多重响应，这样会造成无线资源的消耗。因此终端的W-DNS客户端应该禁止发送多播或著广播查询。
8.4W-DNS应能够缓存DNS行为响应频繁地查询相同域名的IP地址浪费无线资源。W-DNS功能终端必须能够将接收到的DNS响应中的新的DNS记录保存在终端本地，并且执行本标准规定的DNS记录保存方法。如果已经存储的所有DNS记录的大小高于预先设置的存储门限，那么删除一部分已经存储的DNS记录（存在已经过期记录则删除已经过期的DNS记录，如剩余的DNS记录的人小仍然高丁或等于存储门限，则再次删除最临近过期的一部分DNS记录：或一个域名对应的多个IP地址的所有DNS记录中选择部分DNS记录删除：或按照保存的顺序依次删除DNS记录；或刷除使用率低的一部分DNS记录），以使剩余的DNS的大小低于所述存储门限。服务器端的应用在发送频繁使用的无线服务（例如，入口，信息服务和搜索设施）的资源记录时可以考虑更长的持续TTL值。为了保持：致，终端的本地缓存必须能够存储至少一条DNS记录。木标准推荐采用终端本地缓存多条DNS记录的方式，性能优化和存储器分配的大小决定了允许的存储记录容量。终端可以通过设定门限的方式动态地删除所存储的DNS记录，以达到性能优化和提高存储记录容量的目的。终端的W-DNS客户禁止为本地存储的DNS记录修改TTL值。这是因为，终端收到的DNS记录当中的TTL很可能已经被服务器端的应用进行过优化，因此客户端对TTL值的调整可能会导致终端更加频繁地连接无效的P地址，这容易造成整个无线资源的使用效率降低。9W-DNS技术实现要求
9.1要求说明
本部分的意图是告知网络提供商可能要考患的应用优化。这些应用优化是推荐，而不是无线应用协议一致的要求。
9.2主机要求
W-DNS没有说明主机要求或是DNS服务器的行为，然而W-DNS在考虑网络应用时参见[ETFRFC6
1123 和 LETF RFC 2181.
YD/T2141-2010
本标准同时推荐服务器端应用，宜保证在给定的DNS服务器上，能够处理递归查询以支持W-DNS终端。递归查询使无线资源利用最小化，提高吞吐量，因为迭代查询不是W-DNS终端必需的，所以服务器端应用成安装能够递归查询的DNS服务器。9.3在封闭服务域中限制接入要求一些服务器端配置希望执行封闭服务域。替如在一个单个私有网络或者一个虚拟秘有网络，只允许特定用户接入相关联的服务，而其他网络上的用广不允许接入这些服务。建议准备执行封闭服务域的服务器端，应该断开它们给定的DNS服务器和公共DNS服务器网络的连接，隔离给定的DNS服务器网络，并丑不允许其他网络的用户解析受限制服务的域名。其他安全机制也应考虑，如配置防火瑙方案实施。9.4优化 TTL属性要求
为了使得无线资源利用最小化，提供给定DNS服务的服务器端的应用应该占动计算和优化TTL扇性。存储在DNS数据库中的数据是和每个DNS入口相关的实时属性，并且在资源记录响应叶发送给DNS客户。
9.5安全要求
9.5.1安全要求范围
在一个典型的无线应用协议环境巾，不必保护大规模的Internet规模的DNS数据传送。但保护本地（-个区域内）的DNS传送，网络管理员限制DNS服务器只与授权户交互，并且保证区域数据只被授权的代理修改是非常有必要的9.5.2DNSSec描述
终端首先向DNS服务器发送DNS查询请求，其包含用丁标识业务类型的业务标识或者标识用户身份的用户信感，DNS服务器根据所述业务标识和/或用户信恩可以为所述终端选择至少-一个地址将所述选择的IP地址返回给终端时，还要将用于安全认证的鉴权数据提供给终端。服务器间的本地（区域内）数据传送是可以使用任意一个DNSScc机制来保护闷。尽管对于小规模区域，非DNSSec机制，安全FTP/SSH传送也可能逛合，但区域数据的更新应该使用安全动态更新机制鉴权和授权，参见ETFRFC3007
为了评估服务器的应，解析器首先应该向使川SIG（0）或者TSIG的优先服务器发出简易查询解析器可能要求服务器对给定的 SIG、可能的KEY、SIG(KEY)格式进行的查询给子响应。在RFC2931中规定：SIG（0）对DNS交易和请求提供保护。安全DNS的原始数据认证服务提供数据资源记录或者对其存在性进行鉴权，不提供对DNS请求的保护，不提供对基丁间的消息头的保护，不提供对全面完整性的保护。这个规定要求优先的服务器列表、共享的密钥以及TS1G一起使用。除非有更低开销的DNSSec机制可用，否则DNSSec不应该在无线应用协议环境rit使用，9.5.3DNSSec机制
9.5.3.1域名解析方法与密钥分配为了把密钥和DNS名字联系起米，定义了一种资源记录形式。这种形式允许DNS被当成一种公钥分配机制来使用，从而支持DNS本身的安全性利其他一些协议。密钊资源记录的语法中包含了一种算法标识符、实际的公钥参数和多种标志，这些标志指示了与密7
HTYKAONIKAa-
YD/T2141-2010
钥相关实体的类型，或表明没有与实体相关的密。9.5.3.2数据来源认证和完整性
在DNS中，认证是由与资源记录相关的装置提供的，以密码的形式生成数字签名的。一殿的，会有一个单一私钥来认证整个区域，但是不同的算法、签名人等可能会有多个密钥。如果安全性可知的解析器问靠地得到了区域的一个公钥，那么它就可以认证从这个区域读取的数据，就是说它已经被授权了。对于区域的私钥而言，最安全的实现方法是保证它始终是脱机的，而丑周期性的把区域内所有记录全部重新标注。然而，在许多情况下DNS的私钥都是需要在线的，如动态更新，数据来源认证密钥是与区域相关的，而不是与存放着数据备份的服务器相关。这意味着，如果秘钥保持悦机，即使副服务器，其至是区域的主服务器被破坏都不会必然影响解析器的可信度，这个解析器决定了数据是否是真的。
解析器得到一个区域的一个公钥的方式从DNS处读取，或者静态地配置这个公钥。为了能可靠地从DNS处读取公钊，公钥本身必须有解析器信任的钥匙的标志。解析器必须用至少一个公钥来配置，这个公销把一个区域作为一个起始点来认证。如果DNS树中相关区域是安全的而且其已标示密钥是可理解的，那么从这个起始点开始，可以安全的读取这些区域的公钥。添加数据米源认证和完整性，除了添加密钥分配时必须的签名资源类型利密钥资源类型之外，不必改变“on-the-wire\DNS协议，数据不存在的认证也带要下一个资源记录。如果他们能够提供对额外的资源类型的支持，这个服务可以由现存的解析器和缀存服务器来实现。惟一例外的情况是，当一个安个区域内的统一的域名提名来源于一个安全性不可知的服务器时，那么它将不能被认证。如果在重新找到签名认证的信息时，签名是单独被找回和核实的，那么服务器将会有更多的操作。安全性可知的服务器通过发送必要的签名来减轻这种影响。9.5.3.3DNS事务和请求认证
数据来源认证服务保护重新找到的资源记录和资源记录不存在属性，但对DNS或报文头不提供保护的方法。如果头比特被一个坏服务器设置错误了，那么就无法使用数据来源认证服务。但是即使如此，然可以提供请求认证。
请求认证意味着解析器能够保证，至少可以从它所要询问的服务器得到信息，并且这些信息是对其询问的回答。例如，在传输过程中没有被欺骗的报文。用户可以通过在把服务器的应答和解析器的查询串联起来向复的结尾选择添加一个特殊的SIG资源记录来达成上述的效果。请求也而以通过在结尾包含特殊的SIG资源记录，使得白已被认证。在旧的DNS服务器中，认证请求不提供任何功能，而且携带有一个非穿额外信息段的请求会产生错误回复，其至会被许多服务器忽略。但是，现在这种标识请求的格式被定义为一种认证安企的动态更新请求或者需要认证的末米请求的方法。为了传输安全性，私钥属于回复的一部分，而不与区域相关。请求认证可能与主机或其他组成请求的事物相关联，或者与其他私钥相关联。具体与谁相关联是出要建立的请求权限决定的。为了用丁认证，相应的公钥正常情况下会在DNS 中存放和找回。由于清求和同复是多变的，消息认证SIG不能被预先计算出来，因此必须保证私钥在线。例如私钥放在软件或一个直接与网络机连的硬件.上。9.5.4安全缺陷说明
额外的安全一定有缺陷。鉴权的数据通常在一段时问后“过期”，并且交换信息的成员（客户和服8
YD/T214t-2010
务器）必须维持他们的安全关系。TSIG（TransactionSignatures），参见IETFRFC2845，通过使用“共享的密钥\避免了公共密钥的性能影响。因为TSIG包含了安装在请求端和服务端的密钥，这个密钥的存在表明其他端知道TSIG，并且很可能也安装了间样的密钥。另外，TSIG用了相对运算量不太大的钥匙散列认证代码。因此，如果相应的请求被授权，月TSIG授权请求和响应是狠正常的，但是共享密钥的安个分发仍然是问题。
YKANKAa
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。