一种域名解析数据质量评估反馈和数据优化方法及系统

摘要

本发明公开了一种域名解析数据质量评估反馈和数据优化方法及系统。本方法为：1)客户端上的解析器向DNS服务器发起协商请求，该协商请求中包含若干待评估的域名；2)DNS服务器接收到解析器的协商请求时，将设定域名的DNS数据返回给该解析器；3)该解析器从收到的DNS域名数据中解析出每一设定域名对应的DNS应用服务器，然后根据设定域名的历史使用方式向对应DNS应用服务器发起服务请求，获取服务的质量反馈数据；4)解析器根据该质量反馈数据生成评估报告，并将其发送给DNS服务器；5)DNS服务器根据该评估报告优化DNS数据，为该客户端定制DNS数据。本发明能够提高域名服务器的解析数据的质量和其服务质量。

说明书

技术领域

本发明涉及一种域名解析数据质量评估反馈和数据优化方法及系统，属于网络技术领域。

背景技术

DNS域名系统是互联网络的基础设施，它将域名和IP地址做映射解析，支撑着互联网络 的正常运行。其中，客户端和域名服务器是DNS系统中两个很重要的角色，前者向后者请求 域名解析，后者为前者提供域名数据。

一个域名的某类型数据一般对应多条，相应地，DNS服务器将这些数据提供给客户端，并 最终传播给最终用户。在一定短的时间内，域名服务器对同一客户端的同一个域名多次请求， 返回的域名数据的排列顺序要么是固定的，要么是轮询的，要么是随机的。具有智能解析功 能的递归服务器和权威服务器会根据一定的策略为用户定制域名数据，给用户部分域名数据， 将认为更好的域名数据条目往前放。

最终用户在收到域名服务器的应答数据后，尝试访问DNS应用服务器，根据域名服务器 发送来的数据顺序依次访问应用服务器，如果访问的站点无法访问就访问下一个服务器。经 验证明，服务质量更好的站点往往没有排在前面，客户端第一时间访问的站点很多时候是质 量相对较差的站点。因此，域名服务器虽然是考虑到域名数据质量定制域名数据，但是域名 服务器没有办法知道客户端使用定制的域名数据的使用效果。

作为DNS数据的最终使用者，客户端对域名数据的质量最有发言权。而域名数据的质量 取决于用户的DNS体验，但用户的DNS体验和域名数据质量却没有方式和途径反馈给服务器， 递归服务器也就不能根据这些实际数据做域名数据的定制和缓存数据的调整。

发明内容

本发明的目的是解决以上提到的域名质量无法得到用户反馈的问题，提供一种域名解析 数据质量评估反馈和数据优化方法及系统，从而提高域名服务器的解析数据的质量和其服务 质量。

本发明提供了域名数据质量评估反馈和数据优化协议：位于用户机器上的解析器尝试向 服务器端发起DNS数据优化的协商请求，服务器端如果支持这种协商，就向其发送允许响应。 解析器向服务器端请求常用域名，服务器从本地区数据中或解析获取到的DNS数据返回给解 析器，解析器将评估这份数据，并将评估数据返回给服务器端。

本发明的技术方案为：

一种域名解析数据质量评估反馈和数据优化方法，其步骤为：

1)客户端上的解析器向DNS服务器发起协商请求，该协商请求中包含若干待评估的域名；

2)DNS服务器接收到解析器的协商请求时，将设定域名的DNS数据返回给该解析器；

3)该解析器从收到的DNS域名数据中解析出每一设定域名对应的DNS应用服务器，然后 根据设定域名的历史使用方式向对应DNS应用服务器发起服务请求，获取服务的质量 反馈数据；

4)解析器根据该质量反馈数据生成评估报告，并将其发送给DNS服务器；

5)DNS服务器根据该评估报告优化DNS数据，为该客户端或者其邻居定制DNS数据。

一种域名解析数据质量评估反馈和数据优化方法，其步骤为：

1)客户端上的解析器向评估服务器发起协商请求，该协商请求中包含若干待评估的域 名；

2)评估服务器接收到解析器的协商请求时，从DNS服务器获取设定域名的DNS数据并将 其返回给该解析器；

3)该解析器从收到的DNS域名数据中解析出每一设定域名对应的DNS应用服务器，然后 根据设定域名的历史使用方式向对应DNS应用服务器发起服务请求，获取服务的质量 反馈数据；

4)解析器根据该质量反馈数据生成评估报告，并将其发送给评估服务器；

5)评估服务器根据该评估报告优化DNS数据，为该客户端或者其邻居定制DNS数据，然 后将定制的DNS数据缓存到DNS服务器。

进一步的，DNS服务器定制DNS数据的方法为：DNS服务器从该评估报告里以域名为 单位抽取域名、域名数据及其质量反馈数据，根据质量反馈数据对每个域名的域名数据设置 优先级；在客户端向DNS服务器做DNS请求时，DNS服务器优先将优先级高的域名数据返给 客户端。

进一步的，所述质量反馈数据包括域名是否可访问以及访问时延、传输速率、丢包率。

进一步的，所述DNS服务器收到该评估报告后，首先检测该评估报告中的域名数据是否 为DNS服务器缓存中或本地区数据中的域名数据集的子集；如果是，则根据该评估报告优化 DNS数据；否则丢弃该评估报告。

进一步的，所述DNS服务器丢弃客户端的评估报告时，标记该客户端本次行为为恶意行 为；如果在设定时间内该客户端的恶意行为次数超过设定阈值，则限制或禁止该客户端一段 时间内做数据优化的请求或者将其放到黑名单中。

进一步的，解析器发出协商请求后，如果在设定时间阈值范围没有收到DNS服务器的响 应或DNS服务器拒绝返回DNS数据，则停止向该DNS服务器发送协商请求。

一种域名解析数据质量评估反馈和数据优化系统，其特征在于，包括若干通过网络连接 的客户端和服务器；其中

客户端上的解析器包括一协商模块和一评估模块；协商模块用于向服务器端发起协商 请求，并等待协商响应，该协商请求中包含若干待评估的域名；评估模块用于从协商模 块接收的DNS域名数据中解析出每一设定域名对应的DNS应用服务器，然后根据设定域 名的历史使用方式向对应DNS应用服务器发起服务请求，获取服务的质量反馈数据，然 后根据该质量反馈数据生成评估报告，并将其发送给服务器；

服务器包括解析模块、协商模块、定制优化模块和缓存控制模块；解析模块用于域名 解析；协商模块用于对接收的协商请求返回协商响应，以及接收评估报告并将其转发给 定制优化模块；定制优化模块用于根据收到的评估报告为客户端或者其邻居定制DNS数 据，并发送给缓存控制模块以更新缓存。

进一步的，服务器从该评估报告里以域名为单位抽取域名、域名数据及其质量反馈数据， 根据质量反馈数据对每个域名的域名数据设置优先级；在客户端向DNS服务器做DNS请求时， DNS服务器优先将优先级高的域名数据返给客户端。

进一步的，所述质量反馈数据包括域名是否可访问以及访问时延、传输速率、丢包率。

与现有技术相比，本发明的优点：

本发明通过将解析器对域名数据质量的反馈进行评估优化，提高域名服务器的域名数据 的质量，从而提高其服务质量，最终提高用户的域名服务和网络服务的体验。

附图说明

图1为本发明的协议时序图；

图2为本发明的系统模块图。

具体实施方式

本发明采用的技术方案为：位于用户机器上的解析器尝试向服务器端发起DNS数据评估 反馈优化的协商请求，如果服务器端支持这种请求，就向其发送响应。解析器向服务器端请 求常用域名，服务器从本地区数据中或解析获取到的DNS数据返回给解析器，解析器将评估 这份数据，并将评估数据返回给服务器端。

其中，现有传统解析器要被升级以具备域名质量的评估和反馈功能；服务器既可以是被 升级而具有该功能的DNS服务器，也可以是与DNS服务器相独立的但可以控制DNS服务器的 评估服务器。

1协商评估优化过程

协商评估优化过程报告的步骤有：协商请求、协商响应、评估域名数据、评估报告发送、 评估数据检验、反馈响应和定制优化DNS数据等，如图1所示。

1.1协商请求

解析器发起协商请求，请求中包含评估的域名个数，以及希望评估的域名列表。两者可 以只有且至少有一个存在。域名个数可以小于等于域名列表中域名的个数。

如果客户端和服务器端之间的中间设备不支持这样的协商请求或者认为这样的协商请求 是异常的，可能会丢弃这样的协商请求数据包，从而无法到达服务器端。客户端如果在一定 时间阈值范围没有收到数据或者收到formerr或者refused等应答，就应该认定服务器端不 支持该协议，就不应该继续向服务器端发送协商请求了。

客户端应该记住这样的服务器端，至少是一段时间。在这段时间里，不要继续向服务器 端发送协商请求了。

1.2协商响应

当服务器接收到客户端的协商请求时，如果服务器没有这个功能，就立即发送formerr 或者refused的否定响应或者压根不响应等，否则服务器从本地区数据中或解析获取到的、 希望该客户端评估的域名的设定DNS数据返回给客户端。也就是说，协商请求中的域名个数 和域名列表对服务器端来说仅仅是一个参考而已，评估多少域名以及评估哪些域名是由服务 器端最终决定的。除了客户端的协商请求中的这两个信息外，服务器端的决定还取决于本地 的策略。服务器端可以从协商请求中的域名列表中挑选全部或部分域名，也可以选择其他域 名用于评估。

当客户端接收到否定响应时，表示服务器不支持该协议，当没有收到响应的时候，可能 是响应包被链路上的路由设备给丢弃了。

1.3评估域名数据

客户端从服务器端收到域名数据之后，就从域名数据中根据不同的待评估IP地址分析出 该域名对应的多个应用服务器，客户端根据该域名的历史使用方式，如mail、web或者其他 方式，重新按照此方式向域名数据中的DNS应用服务器发起服务请求，并获取服务的可用性 数据(即质量反馈数据)，比如是否可以访问，如果可以访问，获取服务数据的时延。

如果不能访问，那么可用性数据就是空，否则就用时延来衡量。协议要规定统一的评估 结果的时延单位。只要单位统一，评估结果中可以不带单位。

1.4评估报告发送

当客户端评估完域名数据之后，要将评估报告发送给服务器端。如果经过评估之后，发 现域名数据的某个(些)数据指定的应用服务器服务不可用，那么可以不将该域名数据及其 性能(此时为空)发给服务器。

域名数据评估报告里包含评估请求中的域名数据以及与之相关的可用性数据。每个可用 性数据是一个可用性指标的集合。可用性指标可以是访问延迟，传输速率，丢包率等。

1.5评估数据检验

当服务器收到客户端的评估报告之后，检验评估报告是否是合法的。从客户端返回的评 估数据必须是缓存中或本地区数据中域名数据集的子集，如果不是就丢弃，并认为客户端的 此次优化有恶意性，返回给客户端“数据错误”的响应，如果在一定时间内接收到客户端的 恶意优化DNS数据次数超过某一个特定阈值，就限制或禁止该客户端一段时间内做数据优化 的请求，或者直接将其放到黑名单中。

1.6反馈响应

当检验评估数据发现是合法的，服务器端就发送一个成功的响应；否则，就发送一个失 败的响应。

1.7定制优化DNS数据

当检验评估数据发现是合法的，服务器端根据该评估优化DNS数据，为该客户端或者其 邻居定制DNS数据，并缓存它们。客户端发送的评估数据中如果有的域名数据性能是空，那 么定制的域名数据中就不要包含它(们)。

服务器端从收到的域名数据评估报告里以域名为单位抽取域名、域名数据及其可用性数 据，根据域名数据的可用性数据对每个域名的域名数据设置优先级，可用性好的域名数据优 先级要比可用性差的优先级高。在客户端向服务器端做正常DNS请求的时候，服务器端优先 将优先级高的域名数据返给客户端。

另外，服务器可以收集和记录客户端的域名反馈数据，并根据这些数据挖掘和判断它们 的“喜好”。比如，通过分析某个客户端的反馈数据，发现它多数时候访问联通的DNS应用服 务器体验更好，这样即使客户端请求了一个之前未请求过的域名解析时，服务器也能根据之 前的分析数据定制和缓存响应数据。

如果服务器就是具有质量反馈优化功能的DNS服务器，那么就直接通过其内部优化方法 优化。如果将域名质量反馈优化功能实现成一个独立的系统，那么该系统必须有访问控制DNS 服务器的权限。

2安全

域名数据优化反馈能够提高服务质量，但是要保证域名服务器的正常解析，因为在保证 正常解析的前提下才有意义。服务不能正常提供，数据优化就无从谈起。因此，要考虑的因 素如下。

(1)协商频率。协商请求和质量评估的频率不能太大，否则对服务器是有压力的，要间 隔30分钟以上协商一次。如果客户端发送了过多的域名评估请求，那么服务器直接将其丢弃， 并发送拒绝响应。而且，客户端应该缓存协商记录，并设定记录的TTL为30分钟。当该记录 失效之后，再与服务器端发起协商请求，以评估和优化域名数据。

(2)协商域名个数。同样为了减少对服务器端的压力，每次协商的域名个数也要有限制。 协商请求中包含协商的域名个数，服务器端返回的协商响应中包含服务器端设定的协商域名 的个数，此数要小于或等于协商请求中的域名个数。

服务器发送的协商响应包中的域名个数要小于等于客户端发送的协商请求中的域名个 数。客户端发送的协商请求中设置了域名个数为N，服务器端返回给客户端的响应里的域名 个数可以是0到N的的数值。

(3)限制优化评估的客户端数量。如果数量过大，就会对服务器的性能产生不好的影响。 建议500个会话。如果超过数量，服务器端可以拒绝评估请求。为了保存资源和正常服务， (由于资源限制)服务器有权利随时关闭协商的连接。

3性能要求

为了提高反馈的效率，减少客户端和服务器端的资源消耗，可采用以下技术。

3.1DNS请求和响应管道发送

DNS优化请求和响应都是可以不必停等的，多个优化请求可以同时发送并等待应答，当应 答返回并接收到时，能够准确匹配请求。

3.2无序

DNS优化请求和响应是无序的，当一个客户端和服务器端在进行优化和评估的会话时，如 果协商评估多个域名，那么客户端可以并行发送多个域名给服务器端，服务器端返回给客户 端域名数据，客户端同样并行评估域名数据然后将评估报告发送给服务器端，服务器端根据 评估报告优化域名数据并缓存它们。

4数据传输

不管是优化请求和响应都是要做数据的传输，数据传输可以使用加密的方式，也可以不 加密的方式；可以使用新的协议，也可以继续使用DNS协议；可以继续使用DNS协议53端口， 也可以采用新的端口。

4.1保密性

如果认为客户端和服务器端之间的链路是不安全的，想保证域名数据的真实性，可通过 DNSSEC等签名方式，如果想保证数据的保密性，就用一些保密措施；如果认为链路是安全的， DNS优化请求和评估响应可以是明文传输。

特别地，如果需要做一些保密措施，那么可以采用几种手段：

(1)通过TLS传输数据。TLS是一种最近流行的有效防窃听数据传输方式，通过TLS方 式，可以将优化请求和评估响应保密。

(2)在不修改核心DNS协议的前提下，引入加密类型的资源记录。将DNS请求和响应中 的资源记录使用双方协商的共享密钥和公钥加密资源记录，并存放到加密类型的资源记录中。

(3)将DNS报文封装到另一种保密的协议报文中，如http、https等协议报文。

4.2协议修改

如果基于的传输层协议或者应用层协议(如TCP、HTTP等)是可靠的，那么匹配就依赖 于传输层协议。如果基于的传输层协议或应用层协议(如UDP、DNS等)是不可靠的，那么 就要设置合理的标识。

可以使用新的协议，可以通过在DNS里放置数据，如引入新型资源记录，将协商过程中 的来往数据都封装到该类型记录中；也可以基于已有协议，如http、https等传输数据。

4.3基于端口的优化

如果将优化数据封装在其他协议里，肯定是使用了非53端口。除此之外，也可以使用新 的端口传输请求和响应。不过这种方式，容易被路径上的过滤设备和路由设备丢弃或者清洗 掉。

5系统实现

系统由解析器端和服务器端组成。

5.1解析器端实现

解析器端由两部分组成——协商模块和评估模块。

(1)协商模块

协商模块向服务器端发起协商请求，并等待协商响应。如果超时时间内没有接收到响应 或者接收到拒绝等否定响应时，就在一定时间内不再向服务器端发起协商请求。

如果接收到协商响应，就将接收到的域名数据传送给评估模块，以评估域名数据对应的 应用服务器的可用性。

(2)评估模块

评估模块从协商模块接收到域名数据后，就从域名数据中根据不同的IP地址分析出该域 名对应的多个应用服务器，并根据该域名的历史使用方式，重新按照此方式向域名数据中的 DNS应用服务器发起服务请求，并获取服务的可用性数据。

当评估完之后，要将评估报告发送给服务器端。

5.2服务器端实现

服务器端由三部分组成——解析模块、定制优化模块和缓存控制模块。

(1)解析模块

解析模块是具有正常的域名解析模块。

(2)协商模块

当接收解析器端的协商请求，并返回协商响应。与此同时，当收到解析器的评估报告时， 检验评估报告是否是合法的，当检验评估数据发现是合法的，服务器端就发送一个成功的响 应，并且向定制优化模块转发评估报告，以定制优化域名数据；否则，就发送一个失败的响 应。

(3)定制优化模块

定制优化模块接受到协商模块发送来的评估报告之后，就根据该报告为该用户或者其邻 居定制DNS数据，并发送给缓存控制模块以更新缓存。

(4)缓存控制模块

接受到定制优化模块的缓存控制请求之后，就根据该请求控制区文件或缓存以更新数据。