一种共享Hosts文件的应用方法、设备和系统

摘要

本申请公开了一种共享Hosts文件的应用方法、设备和系统，通过应用本申请实施例的技术方案，客户端可以在需要进行域名解析时，通过DNS代理服务器向数据库服务器查询与该客户端相对应的共享Hosts文件，并进行相应的域名解析，获取IP地址，从而，可以通过数据库服务器进行共享Hosts文件的统一存储和管理，将Hosts文件的内容在多个相对应的客户端之间实现共享，避免了对多个客户端进行同样的Hosts文件的重复配置，降低了配置和维护操作的成本，简化了操作处理的过程。

说明书

技术领域

本申请涉及网络技术领域，特别是涉及一种共享Hosts文件的应用方法、 设备和系统。

背景技术

DNS(Domain Name System，域名系统)业务是互联网的一项核心业务， DNS作为能够将域名和IP(Internet Protocol，网络之间互连的协议)地址相互 映射的一个分布式数据库，能够使互联网用户更方便的访问互联网，而不用去 记住用于计算机读取的IP地址。

Hosts是一个用于存储互联网络中各节点信息的计算机文件，这个文件负 责将域名(或主机名)映射到相应的IP地址。Hosts文件通常用于补充或取代 网络中DNS的功能。当用户在浏览器中输入一个需要登录的网址(域名)时， 系统会首先自动从Hosts文件中查找该域名对应的IP地址，一旦找到，系统会 立即根据此IP地址打开对应网页，如果没有找到，则系统会将该域名提交给 DNS域名解析服务器进行IP地址的解析，以得到对应的IP地址。和DNS不 同的是，Hosts文件一般被配置到各个计算机中，可以直接在计算机上进行修 改。

在实现本申请的过程中，发明人发现现有技术至少存在如下问题：

在某些应用场景(如开发、测试、功能演示、预发布等应用场景)中，多 个客户端可能需要配置相同的域名与IP地址的对应关系，同一域名在不同的 项目中对应的IP地址可能不同。基于上述情况，在登录网址的过程中，如果 采用配置在客户端上Hosts文件进行IP地址获取，则需要各个客户端重复配置 相同的Hosts文件，且切换项目后，要对Hosts文件重新进行配置，配置过程 过于复杂，效率低下；如果通过DNS服务器进行IP地址获取，由于DNS服 务器无法针对不同项目对同一域名解析出不同的IP，需要布置多个不同的DNS 服务器，这样布置不但过于复杂，而且成本过高。

发明内容

本申请实施例提供一种共享Hosts文件的应用方法、设备和系统，解决在 现有技术中存在的Hosts文件的配置操作复杂，重复操作率高的问题。

为达到上述目的，本申请实施例一方面提供了一种共享Hosts文件的应用 方法，至少包括以下步骤：

DNS代理服务器接收客户端发送的域名解析请求，其中，所述域名解析请 求中携带所述客户端的标识信息和待解析域名信息；

所述DNS代理服务器查询数据库服务器中是否存在与所述客户端的标识 信息相对应的共享Hosts文件，其中，所述数据库服务器中存储有共享Hosts 文件，以及各共享Hosts文件和不同的客户端的标识信息之间的映射关系；

如果存在，所述DNS代理服务器根据所述共享Hosts文件，解析获取与所 述待解析域名信息所对应的IP地址；

如果获取成功，所述DNS代理服务器将获取到的与所述待解析域名信息 所对应的IP地址发送给所述客户端。

另一方面，本申请实施例还提供了一种DNS代理服务器，至少包括：

接收模块，用于接收客户端发送的域名解析请求，其中，所述域名解析请 求中携带所述客户端的标识信息和待解析域名信息；

查询模块，用于查询数据库服务器中是否存在与所述客户端的标识信息相 对应的共享Hosts文件，其中，所述数据库服务器中存储有共享Hosts文件， 以及各共享Hosts文件和不同的客户端的标识信息之间的映射关系；

获取模块，用于在所述查询模块的查询结果为存在时，根据查询到的所述 共享Hosts文件，解析获取与所述待解析域名信息所对应的IP地址；

发送模块，用于在所述获取模块成功获取到与所述待解析域名信息所对应 的IP地址时，将所述IP地址发送给所述客户端。

另一方面，本申请实施例还提供了一种域名解析系统，至少包括客户端、 DNS代理服务器、数据库服务器和上级DNS服务器：

所述客户端，用于向所述DNS代理服务器发送的域名解析请求，并接收 所述DNS代理服务器返回的IP地址，其中，所述域名解析请求中携带所述客 户端的标识信息和待解析域名信息；

所述DNS代理服务器，用于根据所述域名解析请求，在所述数据库服务 器中查询与所述客户端的标识信息相对应的共享Hosts文件，并根据所述共享 Hosts文件，解析获取与所述待解析域名信息所对应的IP地址，并将获取到的 IP地址发送给所述客户端；

所述数据库服务器，用于存储共享Hosts文件，以及各共享Hosts文件和 不同的客户端的标识信息之间的映射关系；

所述上级DNS服务器，用于接收所述DNS代理服务器在不能从所述数据 库服务器解析获取到相应的IP地址时所发送的携带待解析域名信息的域名解 析请求，解析所述待解析域名信息得到相对应的IP地址，并通过所述DNS代 理服务器将所述IP地址发送给所述客户端。

与现有技术相比，本申请实施例具有以下优点：

通过应用本申请实施例的技术方案，客户端可以在需要进行域名解析时， 通过DNS代理服务器向数据库服务器查询与该客户端相对应的共享Hosts文 件，并进行相应的域名解析，获取IP地址，从而，可以通过数据库服务器进 行共享Hosts文件的统一存储和管理，将Hosts文件的内容在多个相对应的客 户端之间实现共享，避免了对多个客户端进行同样的Hosts文件的重复配置， 降低了配置和维护操作的成本，简化了操作处理的过程。

附图说明

图1为本申请实施例提供的一种共享Hosts文件的应用方法的流程示意图；

图2为本申请实施例提供的共享Hosts文件的应用方法的网络系统架构图；

图3为本申请实施例提供的基于上述网络系统架构的内部组件图；

图4为本申请实施例提供的各内部组件间的信令交互示意图；

图5为本申请实施例提供的一种DNS代理服务器的结构示意图；

图6为本申请实施例提供的一种域名解析系统的结构示意图。

具体实施方式

如背景技术所述，在现有的Hosts文件配置方案中，由于无法做到配置文 件的共享，需要逐一的进行配置，不仅配置工作量巨大，而且在后续的维护过 程中，也需要进行大量的重配置操作，处理效率低下，成本消耗高昂。

为了解决这样的问题，本申请提出了一种通过共享Hosts文件实现多个客 户端使用同一个Hosts文件的方案，通过数据库服务器进行共享Hosts文件的 统一存储和管理，将Hosts文件的内容在多个相对应的客户端之间实现共享， 避免了对多个客户端进行同样的Hosts文件的重复配置，降低了配置和维护操 作的成本，简化了操作处理的过程。

如图1所示，为本申请实施例提供的一种共享Hosts文件的应用方法的流 程示意图，包括：

步骤S101、DNS代理服务器接收客户端发送的域名解析请求。

其中，所述域名解析请求中携带所述客户端的标识信息和待解析域名信 息。

在具体的实施场景中，上述的待解析域名信息具体为需要进行域名解析的 对象，而客户端的标识信息则相当于具体的解析操作的索引，DNS代理服务器 根据客户端的标识信息，通过后续步骤在相应的数据库服务器中进行具体的共 享Hosts文件的检索。

步骤S102、所述DNS代理服务器查询数据库服务器中是否存在与所述客 户端的标识信息相对应的共享Hosts文件。

其中，所述数据库服务器中存储有共享Hosts文件，以及各共享Hosts文 件和不同的客户端的标识信息之间的映射关系。

如果存在，则执行步骤S103；

如果不存在，则执行步骤S105。

具体的，此处的映射关系实现了步骤S101中所接收到的客户端的标识信 息的索引操作，DNS代理服务器可以据此查找相应的共享Hosts文件，并继续 后续操作。

需要进行说明的是，在执行步骤之前，首先需要在数据库服务器中进行共 享Hosts文件的配置，其具体的配置方式包括：

(1)DNS后台管理服务器接收管理终端发送的共享Hosts文件的配置消 息。

其中，所述共享Hosts文件的配置消息中至少包括共享Hosts文件的配置 信息，以及共享Hosts文件与项目的对应关系。

需要说明的是，所述DNS后台管理服务器接收管理终端发送的共享Hosts 文件的配置消息的方式，具体可以为通过Web方式获取。

具体的，DNS后台管理服务器与各管理终端同处于同一个局域网，DNS 后台管理服务器向各管理终端提供Web服务，而各管理终端具体通过Web页 面登陆DNS后台管理服务器，并输入或直接提交相应的配置信息。

当然，通过Web方式进行配置信息的提交只是本申请实施例所提出的一种 具体方案，在实际应用中，也可以通过无线通信，文件传输等方式进行相应的 配置操作，这样的变化并不影响本发明的保护范围。

(2)所述DNS后台管理服务器根据所述共享Hosts文件的配置信息生成 共享Hosts文件，并在所述数据库服务器中按照不同的项目存储相对应的所述 共享Hosts文件。

在具体的应用场景下，所述DNS后台管理服务器根据所述共享Hosts文件 的配置信息所生成的共享Hosts文件，具体可以包括以下三种方式中的一种或 多种：

方式一、通过当前系统配置的标准方式表示域名信息与IP地址的对应关 系的共享Hosts文件。

方式二、通过通配符方式表示域名信息与IP地址的对应关系的共享Hosts 文件。

方式三、通过正则表达式方式表示域名信息与IP地址的对应关系的共享 Hosts文件。

当然，除了上述的三种方式，其他能够明确表示域名信息和IP地址的对 应关系的方式同样可以应用于本申请的技术方案，这样的变化并不影响本发明 的保护范围。

需要进行说明的是，上述的(1)和(2)的操作流程，所对应的实际上是 共享Hosts文件配置到数据库服务器中，并进行生成的操作流程，在实际应用 中，在共享Hosts文件生成后，如果要对其进行具体的应用，首先需要将其绑 定在具体的客户端上，即一个客户端在具体应用一个共享Hosts文件之前，首 先需要请求数据库服务器将该客户端与已经存在的一个共享Hosts文件进行绑 定，具体的操作流程如下：

A、所述DNS后台管理服务器接收客户端发送的共享Hosts文件绑定请求。

其中，所述共享Hosts文件绑定请求中包括所述客户端的标识信息和请求 进行绑定的共享Hosts文件所对应的项目信息。

需要说明的是，所述DNS后台管理服务器接收客户端发送的共享Hosts 文件绑定请求的方式，具体可以为通过Web方式获取。

具体的，DNS后台管理服务器与各客户端同处于同一个局域网，DNS后 台管理服务器向各客户端提供Web服务，而各客户端具体通过Web页面登陆 DNS后台管理服务器，并输入或直接提交相应的绑定请求。

具体的操作方式，可以是各客户端分别在数据库服务器所提供的已经存储 的共享Hosts文件列表中进行选择，也可以是数据库服务器根据各客户端所输 入的参数进行共享Hosts文件的匹配。

当然，通过Web方式进行配置信息的提交只是本申请实施例所提出的一种 具体方案，在实际应用中，也可以通过无线通信，文件传输等方式进行相应的 配置操作，这样的变化并不影响本发明的保护范围。

B、所述DNS后台管理服务器根据所述项目信息在所述数据库服务器中查 询相应的共享Hosts文件，并在所述数据库服务器中记录所述共享Hosts文件 和所述客户端的标识信息之间的映射关系。

步骤S 103、所述DNS代理服务器根据所述共享Hosts文件，解析获取与 所述待解析域名信息所对应的IP地址。

如果获取成功，则执行步骤S104；

如果获取失败，则执行步骤S105。

步骤S104、所述DNS代理服务器将获取到的与所述待解析域名信息所对 应的IP地址发送给所述客户端。

步骤S105、所述DNS代理服务器向上级DNS服务器发送域名解析请求。

其中，所述域名解析请求中携带待解析域名信息。

需要说明的是，本步骤的执行具体为查询不到共享Hosts文件后的处理方 案，即在不能应用共享Hosts文件进行域名解析的情况下，请求上级DNS服务 器直接对步骤S101所接收到的待解析域名信息进行域名解析，从而，保证域 名解析最终可以顺利完成，即保证相应客户端能够获得准确的域名解析结果， 并进行后续操作。

步骤S106、所述DNS代理服务器接收所述上级DNS服务器返回的与所述 待解析域名信息所对应的IP地址，并将所述IP地址发送给所述客户端。

与现有技术相比，本申请实施例具有以下优点：

通过应用本申请实施例的技术方案，客户端可以在需要进行域名解析时， 通过DNS代理服务器向数据库服务器查询与该客户端相对应的共享Hosts文 件，并进行相应的域名解析，获取IP地址，从而，可以通过数据库服务器进 行共享Hosts文件的统一存储和管理，将Hosts文件的内容在多个相对应的客 户端之间实现共享，避免了对多个客户端进行同样的Hosts文件的重复配置， 降低了配置和维护操作的成本，简化了操作处理的过程。

下面将结合本申请中的附图，对本申请中的技术方案进行清楚、完整的描 述，显然，所描述的实施例是本申请的一部分实施例，而不是全部的实施例。 基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下 所获得的所有其他实施例，都属于本申请保护的范围。

具体的，结合实际的开发、测试的应用场景对本申请实施例提供的共享 Hosts文件的应用方法进行阐述。

如图2所示，为本申请实施例提供的共享Hosts文件的应用方法的网络系 统架构图，其中包括：

Datebase(数据库，即前述的数据库服务器)，用于存储多个共享Hosts文 件(用于记录Hosts信息，即域名与IP地址的对应关系，每种对应关系记录于 一个Hosts中，具体可以采用共享Hosts文件的方式实现)，并存储客户端标识 与各共享Hosts文件的对应关系。

其中，客户端标识与各共享Hosts文件的对应关系，具体可以是用户注册 账号(或者其他能够表示客户端身份的标识信息)与各共享Hosts文件的对应 关系。

DNS Back Office(DNS后台，即前述的DNS后台管理服务器)，用于通 过Web方式向各管理终端提供配置服务。

在具体的处理场景中，各管理终端所配置的内容包括：需要配置的共享 Hosts文件所包含的Hosts信息，以及各共享Hosts文件与客户端标识的对应关 系。

其中，Hosts信息的存储方式可以是：标准方式、通配符方式、正则表达 式方式等。

DNS Proxy Server(DNS代理服务器)，用于接收客户端发送的IP地址获 取请求，并根据其中所包含的客户端的标识(例如，该客户端的MAC地址、 IP地址等)，以及Datebase存储的客户端标识与各共享Hosts文件的对应关系， 确定该客户端对应的共享Hosts文件；然后，根据IP地址获取请求中携带的待 解析域名，以及该共享Hosts文件存储的Hosts信息(即域名与IP地址的对应 关系)确定该待解析域名对应的IP地址；最后，将解析得到的IP地址返回给 客户端。

优选的，当客户端对应共享Hosts文件中没有记录该域名对应的IP地址时， DNS代理服务器还可以继续向上级DNS服务器转发客户端的IP地址获取请 求，并获取相应的域名解析结果(IP地址)。

客户端，包含两方面的操作：

首先，开发测试人员可以通过客户端向DNS Proxy Server发送IP地址获 取请求，并在请求中携带域名信息和客户端标识，以获取该域名对应的IP地 址。

另一方面，开发测试人员还可以通过客户端向DNS Back Office发送关联 请求(可以通过web方式，即前述的绑定请求)，告知DNS Back Office该客户 端需要与哪个项目的共享Hosts文件对应。

在具体的处理场景中，开发测试人员还可以通过客户端选择，是通过DNS Proxy Server获取域名对应的IP地址，或是采用本地Hosts文件获取域名对应 的IP地址。

管理终端，开发测试管理人员可以通过管理终端连接DNS Back Office对 不同项目(开发项目、测试项目)的Hosts信息以及各共享Hosts文件与客户 端的标识的对应关系进行配置管理。

其中，每个项目中可以有多个Hosts文件。开发测试管理人员也可以在其 他终端登录管理账号进行相应的管理工作。

基于上述的网络架构，本申请实施例提供的共享Hosts文件的应用方法的 具体流程包括：

DNS Back Office接收管理终端发送的不同项目(开发项目、测试项目) 的Hosts文件。每个项目中可以有多个共享Hosts文件。

DNS Back Office向客户端提供共享Hosts文件，并接收客户端发送的共享 Hosts文件选择信息，并将该客户端的客户端标识与其选择的共享Hosts文件的 对应关系记录在Datebase中。

将客户端的DNS服务器的IP地址设置为DNS Proxy Server的IP地址。

DNS Proxy Server接收客户端发送的携带有域名和客户端标识的IP地址获 取请求。

DNS Proxy Server在Datebase存储的该客户端标识对应的共享Hosts文件 中查找该域名对应的IP地址。

DNS Proxy Server将查找到的IP地址返回给客户端。

进一步的，如图3所示，为本申请实施例提出的基于上述网络系统架构的 内部组件图，其中：

Hosts，用于维护一组域名与IP地址的对应关系信息，Hosts信息包括以下 三种存储方式：

(1)StandardHosts，标准方式。

即操作系统提供的Hosts文件的格式。

(2)WildcardHosts，通配符方式。

例如：通过记录*.cn.XXXXXXX.com与IP1的对应关系，可以将一组域名 与IP1对应绑定起来。

(3)RegularHosts，正则表达式方式。

例如：通过记录www.[name1|name2].XXXXXXX.com与IP2的对应关系， 可以将一组域名与IP2对应绑定起来。

ClientHostsMapping，用于维护客户端(或者注册账号)与共享Hosts文件 的对应关系。其中，一个共享Hosts文件可以与多个客户端标识对应。

DnsProtocol，用于进行DNS协议转换，对客户端发送的IP地址获取请求 以及向客户端返回的IP地址信息进行协议转换。

DnsResolver，是DNS Proxy Server内部入口组件，用于协调上述各内部组 件的工作。

各内部组件间的信令交互图可参见图4，具体包括以下步骤：

步骤S401、DnsResolver接收客户端发送的IP地址获取请求。

步骤S402、DnsResolver向DnsProtocol转发该IP地址获取请求，并进行 相应的DNS协议转换。

步骤S403、DnsResolver向ClientHostsMapping请求获取该客户端与共享 Hosts文件的对应关系。

步骤S404、DnsResolver根据获取到的对应关系，向Hosts获取IP地址获 取请求所携带的待解析域名所对应的IP地址信息。

步骤S405、DnsResolver向DnsProtocol转发所获取到的IP地址信息，并 进行相应的DNS协议转换。

步骤S406、DnsResolver向客户端返回相应的IP地址信息。

与现有技术相比，本申请实施例具有以下优点：

通过应用本申请实施例的技术方案，客户端可以在需要进行域名解析时， 通过DNS代理服务器向数据库服务器查询与该客户端相对应的共享Hosts文 件，并进行相应的域名解析，获取IP地址，从而，可以通过数据库服务器进 行共享Hosts文件的统一存储和管理，将Hosts文件的内容在多个相对应的客 户端之间实现共享，避免了对多个客户端进行同样的Hosts文件的重复配置， 降低了配置和维护操作的成本，简化了操作处理的过程。

为了实现上述的技术方案，本申请实施例提供了一种DNS代理服务器， 其结构示意图如图5所示，至少包括：

接收模块51，用于接收客户端发送的域名解析请求，其中，所述域名解析 请求中携带所述客户端的标识信息和待解析域名信息；

查询模块52，用于查询数据库服务器中是否存在与所述客户端的标识信息 相对应的共享Hosts文件，其中，所述数据库服务器中存储有共享Hosts文件， 以及各共享Hosts文件和不同的客户端的标识信息之间的映射关系；

获取模块53，用于在所述查询模块52的查询结果为存在时，根据查询到 的所述共享Hosts文件，解析获取与所述待解析域名信息所对应的IP地址；

发送模块54，用于在所述获取模块53成功获取到与所述待解析域名信息 所对应的IP地址时，将所述IP地址发送给所述客户端。

在实际的应用场景中，所述发送模块54，还用于：

在所述查询模块52的查询结果为不存在，或在所述获取模块53没有成功 获取到与所述待解析域名信息所对应的IP地址时，向上级DNS服务器发送域 名解析请求，并在所述接收模块51接收到所述上级DNS服务器返回的与所述 待解析域名信息所对应的IP地址后，将所述IP地址发送给所述客户端；

其中，所述域名解析请求中携带待解析域名信息。

进一步的，本申请实施例还提出了一种域名解析系统，其结构示意图如图 6所示，至少包括客户端61、DNS代理服务器62、数据库服务器63和上级 DNS服务器64：

所述客户端61，用于向所述DNS代理服务器62发送的域名解析请求，并 接收所述DNS代理服务器62返回的IP地址，其中，所述域名解析请求中携 带所述客户端61的标识信息和待解析域名信息；

所述DNS代理服务器62，用于根据所述域名解析请求，在所述数据库服 务器63中查询与所述客户端61的标识信息相对应的共享Hosts文件，并根据 所述共享Hosts文件，解析获取与所述待解析域名信息所对应的IP地址，并将 获取到的IP地址发送给所述客户端61；

所述数据库服务器63，用于存储共享Hosts文件，以及各共享Hosts文件 和不同的客户端61的标识信息之间的映射关系；

所述上级DNS服务器64，用于接收所述DNS代理服务器62在不能从所 述数据库服务器63解析获取到相应的IP地址时所发送的携带待解析域名信息 的域名解析请求，解析所述待解析域名信息得到相对应的IP地址，并通过所 述DNS代理服务器62将所述IP地址发送给所述客户端61。

进一步的，上述的域名解析系统还包括管理终端65和DNS后台管理服务 器66：

所述管理终端65，用于向DNS后台管理服务器66发送共享Hosts文件的 配置消息，其中，所述共享Hosts文件的配置消息中至少包括共享Hosts文件 的配置信息，以及共享Hosts文件与项目的对应关系；

所述客户端61，还用于向DNS后台管理服务器66发送共享Hosts文件绑 定请求，其中，所述共享Hosts文件绑定请求中包括所述客户端61的标识信息 和请求进行绑定的共享Hosts文件所对应的项目信息；

所述DNS后台管理服务器66，用于根据所述共享Hosts文件的配置消息 生成共享Hosts文件，并在所述数据库服务器63中按照不同的项目存储相对应 的所述共享Hosts文件，还用于根据所述共享Hosts文件绑定请求，在所述数 据库服务器63中查询相应的共享Hosts文件，并在所述数据库服务器63中记 录所述共享Hosts文件和所述客户端61的标识信息之间的映射关系。

与现有技术相比，本申请实施例具有以下优点：

通过应用本申请实施例的技术方案，客户端可以在需要进行域名解析时， 通过DNS代理服务器向数据库服务器查询与该客户端相对应的共享Hosts文 件，并进行相应的域名解析，获取IP地址，从而，可以通过数据库服务器进 行共享Hosts文件的统一存储和管理，将Hosts文件的内容在多个相对应的客 户端之间实现共享，避免了对多个客户端进行同样的Hosts文件的重复配置， 降低了配置和维护操作的成本，简化了操作处理的过程。

本领域技术人员可以理解实施例中的装置中的模块可以按照实施例描述 进行分布于实施例的装置中，也可以进行相应变化位于不同于本实施例的一个 或多个装置中。上述实施例的模块可以合并为一个模块，也可以进一步拆分成 多个子模块。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请 可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很 多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上 或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机 软件产品存储在一个存储介质中，包括若干指令用以使得一台终端设备(可以 是手机，个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述 的方法。

以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通 技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰， 这些改进和润饰也应视本申请的保护范围。