CN107528862A - 域名解析的方法及装置 - Google Patents

Abstract

本发明公开一种域名解析的方法及装置，该方法包括：配置能够解析待解析域名的超文本传输协议域名解析服务器HTTPDNS的地址的地址列表；从所述地址列表中确定目标HTTPDNS的地址；向所述目标HTTPDNS的地址发起包括待解析的域名的HTTP请求，以获取到所述目标HTTPDNS返回的解析结果，本发明实施例通过确定的目标HTTPDNS进行域名解析，基于HTTP现有的安全机制，有效防止了域名劫持，提高了域名解析的安全性和效率。

Description

域名解析的方法及装置

技术领域

本发明涉及计算机技术领域，具体而言，涉及一种域名解析的方法及装置。

背景技术

域名是为了方便记忆而专门建立的一套地址转换系统，要访问一台互联网上的服务器，最终还必须通过IP地址来实现，域名解析(Domain name resolution，DNS)就是将域名重新转换为IP地址的过程。一个域名对应一个IP地址，一个IP地址可以对应多个域名；所以多个域名可以同时被解析到一个IP地址。域名解析需要由专门的域名解析服务器(DNS)来完成。

域名解析通常作为一次网络连接的先导，将便于人们记忆的计算机名称解析成适合计算机处理的网络地址，几乎所有需要网络连接的应用都需要解析域名。

域名系统的本质是一个以域名为索引，存储域名对应主机信息的数据库，每个域名由字符标签(label)和点号(.)间隔组成，全体域名构成了域名空间，这个域名空间可以看作是一颗由域名标签逆向生成的树。树的根节点是长度为0的空标签。节点所代表的域名是从节点本身开始，沿路径向上并由点号分隔路径上各个标签生成的字符串。

目前，当应用过程需要将一个主机域名映射为IP地址时，就调用域名解析函数，解析函数将待转换的域名放在DNS请求中，以UDP报文方式发给本地域名服务器(Local DNS)。本地的域名服务器查到域名后，将对应的IP地址放在应答报文中返回。同时域名服务器还必须具有连向其他服务器的信息以支持不能解析时的转发。若域名服务器不能回答该请求，则此域名服务器就暂成为DNS中的另一个客户，向根域名服务器发出请求解析，根域名服务器一定能找到下面的所有二级域名的域名服务器，这样以此类推，一直向下解析，直到查询到所请求的域名。

在实现本发明的过程中，发明人发现现有技术中的域名解析方案至少存在以下技术问题：

(1)域名劫持

攻击者在用户在访问正常服务时，通过影响该服务的DNS解析结果将服务恶意引向其他地址，用户正常访问服务时，却被引向了广告页面或者钓鱼网站等。域名解析作为互联网访问的第一跳，劫持的价值最大。同时，DNS协议缺乏安全保护，劫持的代价很小。比如进行动态主机配置协议(Dynamic Host Configuration Protocol，DHCP)欺骗，在终端接入网络时，使得终端上的DNS地址配置为“黑色DNS”的IP，随心所欲的控制域名解析结果；还有攻击者在局域网中通过地址解析协议(Address Resolution Protocol，ARP)欺骗伪装成出口网关，当局域网内正常用户访问外网服务时，截取DNS请求，返回欺骗性的解析结果；或者更直接的侵入网络监听，当发现有特定DNS请求时，迅速回复该DNS请求的欺骗性应答，这对于UDP基础上的明文传输代价并不高，在攻击者距离用户比真实DNS更近时有很高成功率。另外，当前国内骨干网间结算的方式甚至使有的运营商为了保证流量本网转发，直接修改Local DNS上的解析结果。

(2)智能解析不精准

智能解析是指DNS服务器根据一定的策略，对同一域名作出各不相同的解析应答。通过DNS智能解析，可以对业务流量进行全局的调度。在最常见的情况下，服务提供者若要提高业务访问的质量，应在多地、多AS域内部署服务集群，并将业务访问引导至距离用户最近的集群上。由于ednsclient-subnet协议的支持程度并不高，权威DNS一般通过LocalDNS的出口IP来判断用户当前的地理位置以及运营商信息，结合GSLB策略，将最合适该用户的业务集群地址作为解析结果返回给用户。该方案的关键在于权威DNS要能够通过Local DNS的出口IP准确识别用户的信息，但实际上这严重依赖于运营商Local DNS的具体部署。

(3)解析变更生效慢

为降低权威DNS一侧的解析压力，Local DNS上通常会有一层缓存。Local DNS会将此前的查询结果缓存一段时间，这段时间内如果Local DNS再收到同样的解析请求，会将缓存的结果作为解析应答。因此在缓存有效的时间段内，如果权威DNS的解析内容发生变化，该Local DNS所服务的用户是不感知的。另外，一些运营商为了节省流量结算费用，将缓存有效期强制延长甚至数小时之久。显而易见，这会导致业务提供者基于DNS解析的全局流量调度灵敏性严重下降，在基于DNS解析的灾备切换场景中，还会导致对应用户长时间的业务不可用。

基于以上问题，本发明提出了一种新的域名解析的方法及装置。

在所述背景技术部分公开的上述信息仅用于加强对本发明的背景的理解，因此它可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

有鉴于此，本发明提供一种域名解析的方法及装置，通过确定的目标HTTPDNS进行域名解析，基于HTTP现有的安全机制，有效防止了域名劫持，提高了域名解析的安全性和效率。

本发明的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本发明的实践而习得。

根据本发明的第一方面，提供一种域名解析的方法，其中，所述方法包括：

配置能够解析待解析域名的超文本传输协议域名解析服务器HTTPDNS的地址的地址列表；

从所述地址列表中确定目标HTTPDNS的地址；

向所述目标HTTPDNS的地址发起包括待解析的域名的HTTP请求，以获取到所述目标HTTPDNS返回的解析结果。

根据一些实施例，所述方法还包括：向所述地址列表中的HTTPDNS的地址发送目标域名为所述HTTPDNS本身的HTTP域名解析请求的地址的HTTP请求；根据所述HTTPDNS返回的地址更新所述地址列表。

根据一些实施例，所述方法还包括：当所述地址列表中的所有HTTPDNS的地址不可达或者所有HTTPDNS解析失败时，向权威域名解析服务器DNS发送域名解析请求；根据所述权威DNS返回的地址更新所述地址列表。

根据一些实施例，所述从所述地址列表中确定目标HTTPDNS的地址，包括：分别对所述地址列表中的每个HTTPDNS的地址进行响应测速，将测速结果最快的HTTPDNS的地址作为目标HTTPDNS的地址。

根据一些实施例，所述方法还包括：当所述目标HTTPDNS的地址不可达或者所述目标HTTPDNS域名解析失败时，向所述地址列表中的其他HTTPDNS的地址发送目标域名为所述HTTPDNS本身的HTTP域名解析请求，以获取到所述其他HTTPDNS返回的HTTPDNS的地址；根据所述HTTPDNS的地址更新所述地址列表。

根据一些实施例，所述方法还包括：当所述地址列表中的所有HTTPDNS的地址不可达或者所有HTTPDNS域名解析失败时，向所述权威DNS发送域名解析请求，以获取到所述权威DNS返回的HTTPDNS的地址；根据所述HTTPDNS的地址更新所述地址列表。

根据本发明的第二方面，提供一种域名解析的装置，其中，所述装置包括：

配置模块，用于配置能够解析待解析域名的超文本传输协议域名解析服务器HTTPDNS的地址的地址列表；

确定模块，用于从所述地址列表中确定目标HTTPDNS的地址；

解析模块，用于向所述目标HTTPDNS的地址发起包括待解析的域名的HTTP请求，以获取到所述HTTPDNS返回的解析结果。

根据一些实施例，所述装置包括：发送模块，用于向所述地址列表中的HTTPDNS的地址发送目标域名为所述HTTPDNS本身的HTTP域名解析请求；更新模块，用于根据所述HTTPDNS返回的地址更新所述地址列表。

根据一些实施例，所述发送模块，还用于当所述地址列表中的所有HTTPDNS的地址不可达或者所有HTTPDNS解析失败时，向权威域名解析服务器DNS发送域名解析请求；所述更新模块，还用于根据所述权威DNS返回的地址更新所述地址列表。

根据一些实施例，所述确定模块，用于分别对所述地址列表中的每个HTTPDNS的地址进行响应测速，将测速结果最快的HTTPDNS的地址作为目标HTTPDNS的地址。

根据本发明的第三方面，提供一种计算机可读存储介质，其上存储有计算机程序，其中，该程序被处理器执行时实现如第一方面所述的方法步骤。

根据本发明的第四方面，提高一种电子设备，其中，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如第一方面所述的方法步骤。

本发明实施例中，通过确定的目标HTTPDNS进行域名解析，基于HTTP现有的安全机制，有效防止了域名劫持，提高了域名解析的安全性和效率。

附图说明

通过参照附图详细描述其示例实施例，本发明的上述和其它目标、特征及优点将变得更加显而易见。

图1是根据一示例性实施例示出的一种利用BGP部署的域名解析的示意图；

图2是根据一示例性实施例示出的一种域名解析的方法的流程图；

图3是根据一示例性实施例示出的一种域名解析系统的示意图；

图4是根据一示例性实施例示出的一种域名解析的装置的结构图；

图5是根据一示例性实施例示出的一种电子设备的结构示意图。

具体实施方式

现在将参考附图更全面地描述示例实施例。然而，示例实施例能够以多种形式实施，且不应被理解为限于在此阐述的实施例；相反，提供这些实施例使得本发明将全面和完整，并将示例实施例的构思全面地传达给本领域的技术人员。在图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本发明的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本发明的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本发明的各方面。

附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

需要说明的是，本申请中的提出的域名解析方法是通过在客户端直接内置了HTTPDNS服务IP地址列表，并确定出目标HTTPDNS实现域名解析，虽然现有技术中的DNS域名解析也能够配置DNS服务IP，但在实际场景中目前最常见的是在接入运营商网络时，通过DHCP发现自动配置上附近的Local DNS，Local DNS多点部署缓存域名解析数据提高了响应速度，降低了权威DNS的性能开销。

因此相对于现有技术中的DNS的解析方案，HTTPDNS对解析的吞吐量和服务的可靠性以及响应速度方面有更高的要求。

现有技术中的边界网关协议(BGP)是运行于TCP上的一种自治系统的路由协议。BGP是唯一一个用来处理像因特网大小的网络的协议，也是唯一能够妥善处理好不相关路由域间的多路连接的协议。BGP系统的主要功能是和其他的BGP系统交换网络可达信息。网络可达信息包括列出的自治系统(AS)的信息。这些信息有效地构造了AS互联的拓朴图并由此清除了路由环路，同时在AS级别上可实施策略决策。

例如，图1是根据一示例性实施例示出的一种利用BGP部署的域名解析的示意图。

如图1所示，HTTPDNS部署方采用支持BGP的路由器Router G与Router C建立BGP邻居关系，与自治域AS_1进行路由交换，HTTPDNS的服务IP(1.1.1.1)接入到Router G，并由Router G由自治域AS_3向自治域AS_1宣告。

为了提高解析的吞吐量、服务的可靠性以及响应速度，在AS 6中复制在AS_3中的部署，由Router J在自治域AS_6上宣告HTTPDNS的服务IP(1.1.1.1)。

BGP选路会比较BGP路由规则的属性，优先选择AS_PATH较短的进行路由。上述两条BGP路由在全网传播之后，理想的情况下，客户端A通过内置的IP(1.1.1.1)访问HTTPDNS服务时，请求会通过AS_4至AS_1至AS_3发送到AS_3中的HTTPDNS上；客户端B通过内置的IP(1.1.1.1)访问HTTPDNS服务时，请求会通过AS_5至AS_2至AS_6被发送到AS_6中的HTTPDNS上。

上述方案中通过BGP实现了网络层的anycast，客户端具体访问的是HTTPDNS依赖于网络层的路由调度，从而实现全局范围内的负载均衡，提高了服务的整体吞吐量，在服务部署时，考虑到地域位置和上联的AS的ISP，合理分布服务节点，通过BGP路由的优选特性，能够降低服务的平均响应时延，当AS_3中的服务节点网络故障或者下线迁移，Router G会自动撤销此前所发布的路由，Cl ient A又可以通过AS_4至AS_1至AS_2至AS_6正常访问到HTTPDNS服务，通过分布服务保证了系统的伸缩性，提高了系统的可靠性。

但是上述技术方案中会存在以下问题：

(1)部署成本高

首先，HTTPDNS部署方在宣告路由时，与上联自治域建立邻居关系需要部署选型合适支持BGP的路由器，与接入运营商做EBGP交互，接入层次较高，会导致投资增加。

其次，更关键的是使用此方案来实现多线路需要申请IDC自己的IP地址段和自治域号，国内目前自治域号还属于较稀缺资源，申请门槛很高。

同时，大范围部署BGP anycast还会造成路由聚合困难。在实际应用中，具有相同前缀的IP对应相同的NEXT_HOP才可以在路由表中聚合为一项。anycast的结点分布在不同的位置，路由表会分多个路由项存储路由信息。如果BGP anycast广泛部署，会导致路由表增大降低路由效率。

最后，当前大多运营商仅接受掩码长度小于24的网段的BGP路由宣告，这意味着在实际应用中部署一个BGP anycast会造成256个IP同时变为BGP anycast IP，如不能对其他地址合理利用，将造成公网地址的浪费。

(2)存在分布式节点故障判断不及时的风险

业务流量的调度依赖于网络层路由器的合理路由，当网络层以下的故障时发生时，比如宕机或者网络接口故障，路由器能够及时捕获故障并撤销此前发布的BGP宣告，使流量被迁移到其他节点。如果HTTPDNS服务网络层工作正常但应用层故障时，路由器是无法感知的，此时原有流量还将涌入故障节点，使服务成功率下降。

较可行的方法是进行应用层状态的监控，当发现应用层故障时，手动撤销路由器此前的BGP路由宣告，但这会导致故障时间严重依赖于服务的运维水平。

(3)监控网络部署复杂

由于anycast的原因，如需部署监控节点通过服务地址监控HTTPDNS服务的运行状态则显得不那么可行，监控网络不能了解到被BGP宣告的服务地址到底是哪一个服务节点。如需接入监控系统，一般会在每个HTTPDNS节点机房单独部署监控节点，可能涉及监控系统的改造。

基于以上问题，本发明实施例中提出了一种域名解析的方法，在利用HTTPDNS实现域名解析的情况下，通过配置能够解析待解析域名的超文本传输协议域名解析服务器HTTPDNS的地址的地址列表；从所述地址列表中确定目标HTTPDNS的地址；向所述目标HTTPDNS的地址发起包括待解析的域名的HTTP请求，以获取到所述目标HTTPDNS返回的解析结果，不仅能够取得利用HTTPDNS实现域名解析的有益效果，还能够解决利用BGP技术部署HTTPDNS所造成的上述问题。

图2是根据一示例性实施例示出的一种域名解析的方法的流程图。

如图2所示，该方法包括以下步骤：

在S210中，配置能够解析待解析域名的HTTPDNS的地址的地址列表。

需要说明的是，运营人员可以预先部署多个HTTPDNS，同时发布某待解析域名指向上述多个HTTPDNS的地址，从而设置上述多个HTTPDNS能够解析该待解析域名，并同时在上述多个HTTPDNS中的每个HTTPDNS和权威DNS以及客户端中记录能够解析上述待解析域名的多个HTTPDNS的地址的地址列表。例如，配置能够解析待解析域名的HTTPDNS的地址的地址列表中包括两个IP地址(1.1.1.1与2.2.2.2)。

在S220中，从所述地址列表中确定目标HTTPDNS的地址。

根据示例实施例，可以分别对所述地址列表中的每个HTTPDNS的地址进行响应测速，将测速结果最快的HTTPDNS的地址作为目标HTTPDNS的地址。

例如，在进行响应测速时，可以分别向每个HTTPDNS的地址发送http请求，将向客户端返回响应消息的速度最快的HTTPDNS的地址作为目标HTTPDNS的地址。

需要说明的是，客户端向每个HTTPDNS的地址发送的http请求可以是包括待解析域名的HTTP请求，也可以是任意的HTTP请求。

图3是根据一示例性实施例示出的一种域名解析系统的示意图。如图所示，配置能够解析待解析域名的两个HTTPDNS的地址分别为1.1.1.1与2.2.2.2，在客户端上配置HTTPDNS的地址列表为1.1.11和2.2.2.2，在1.1.1.1和2.2.2.2对应的HTTPDNS以及权威DNS上建立域名映射，将标识HTTPDNS本身的域名解析为1.1.1.1和2.2.2.2。客户端分别向1.1.1.1与2.2.2.2发送HTTP请求，通过比较1.1.1.1与2.2.2.2对应的HTTPDNS返回的响应消息，确定1.1.1.1对应的HTTPDNS的测速结果最快，为目标HTTPDNS，则客户端通过向1.1.1.1发送包括待解析的域名的HTTP请求，以获取到1.1.1.1对应的HTTPDNS返回的解析结果。

上述实施例中，通过预置IP地址和在特定的场景下向HTTPDNS本身(或权威DNS)来获取HTTPDNS当前有哪些服务节点，再通过应用层的探测获知哪一个节点对于自己来说响应最快，实现了对预置的地址列表中的HTTPDNS的应用层探测，减小了对HTTPDNS的性能开销，从整体上提高了域名解析的效率。

需要注意的是，为减小响应测速对HTTPDNS带来的性能开销，客户端可以限制进行响应测速的场景，如仅在应用加载、接入网络地址变化、服务地址列表更新的场景下进行服务节点的探测选择。另外，为减小响应测速对客户端所带来的增加时延开销的影响，客户端可以对HTTPDNS进行“预探测”，即在未有域名解析请求发生时就预先确定目标HTTPDNS服务节点。

在S230中，向上述目标HTTPDNS的地址发起包括待解析的域名的HTTP请求，以获取到上述目标HTTPDNS返回的解析结果。

根据示例实施例，客户端可以根据确定的目标HTTPDNS的地址，向目标HTTPDNS发起包括待解析的域名的HTTP请求，该目标HTTPDNS对该待解析的域名进行解析，并将解析结果返回至该客户端。

上述实施例中，利用HTTP协议与HTTPDNS信息交互，获取到域名解析结果，代替了传统的基于UDP协议的DNS交互，能够绕开Local DNS，同时利用基于HTTP现有的安全机制，能够有效防止域名劫持。而且，绕过Local DNS还能够达到解析变更生效迅速的效果，由于HTTPDNS获取的是真实客户端IP而非Local DNS的IP，能够精确定位客户端地理位置、运营商信息，使得HTTPDNS能够有效提高业务流量调度精确性，有效的解决了DNS实际应用中面临的多种问题。同时，客户端可以根据应用场景，对HTTPDNS的解析结果做多种多样的缓存优化操作，更进一步提高域名解析的效率。本文所提出的域名解析方法，通过分布式部署的HTTPDNS，提高了解析吞吐量，保证了高可靠性，具备良好的横向伸缩性，并且易于实现，部署成本低，故障节点摘除准确灵敏。

而且相比于利用BGP技术部署的HTTPDNS进行域名解析，上述方案可以带来以下的有益效果：

(1)部署成本低

本方案中所部署的HTTPDNS均可在普通机房中，无需与运营商做EBGP交互，降低了接入层次以及成本。而且无需在特定自治域内宣告服务节点IP的BGP路由，降低了部署技术门槛和技术成本。

(2)故障节点摘除准确灵敏

相较于BGP anycast方案，本方案直接针对于HTTPDNS服务的应用层进行探测，避免了BGP anycast方案中，节点网络层状态正常但应用层故障的场景下，摘除故障服务节点不及时的现象。

当节点故障发生后，若客户端应用运行中且当前服务节点为故障节点，则会导致HTTPDNS域名解析响应超时，或者首次加载探测决定当前目标HTTPDNS为无效节点，都会触发向其他HTTPDNS或者Local DNS请求解析HTTPDNS服务域名也就是更新服务地址列表并确定目标HTTPDNS的流程，从而在地址列表中状态正常的HTTPDNS的地址中，确定出测速响应最快的目标HTTPDNS。

(3)易于监控

监控系统能够多点部署，也能够集中部署，监控系统能够通过服务IP准确区分各个节点并反馈运行状态。

(4)兼具其他分布式部署的优势

考虑到地理位置和接入运营商，合理部署服务节点，能够有效降低HTTPDNS服务的平均响应时延；多点部署提高了整个系统的容量；由于HTTPDNS本身的域名解析在HTTPDNS上和权威DNS上发布，可以方便的通过修改域名解析结果平滑的迁移和扩容系统。

下面结合具体的实施例，对本发明实施例中提出的域名解析的方法做进一步的说明。

客户端可以周期性的或者根据用户设置自动更新预设置的地址列表。例如，可以设置每次启动该客户端时更新地址列表。

根据示例实施例，客户端在更新地址列表时，可以向地址列表中的至少一个HTTPDNS的地址发送目标域名为所述HTTPDNS本身的HTTP域名解析请求，HTTPDNS接收到HTTP请求后，向客户端返回地址，客户端根据该地址更新地址列表。

客户端配置了包括1.1.1.1与2.2.2.2的IP地址的地址列表后，运营人员配置增加一个HTTPDNS的地址3.3.3.3也能够解析该待解析域名，则1.1.1.1与2.2.2.2对应的HTTPDNS上记录的能够解析待解析域名的HTTPDNS的地址的地址列表包括：1.1.1.1、2.2.2.2和3.3.3.3。客户端在更新地址列表时，可以向IP地址1.1.1.1和/或2.2.2.2发送目标域名为HTTPDNS本身的TTP域名解析请求，IP地址1.1.1.1和/或2.2.2.2对应的HTTPDNS向客户端返回包括：1.1.1.1、2.2.2.2和3.3.3.3的地址，客户端将地址列表更新为1.1.1.1、2.2.2.2和3.3.3.3。

根据示例实施例，客户端在更新地址列表时，在向地址列表中的所有HTTPDNS的地址发送待解析域名的地址的HTTP请求后，当地址列表中的所有HTTPDNS的地址均不可达或者所有的HTTPDNS的地址对应的所有HTTPDNS解析失败时，向权威域名解析服务器DNS发送域名解析请求，并根据权威DNS返回的地址更新地址列表。

例如，客户端配置了包括1.1.1.1与2.2.2.2的IP地址的地址列表后，运营人员配置将IP地址为1.1.1.1的HTTPDNS迁移到3.3.3.3的IP地址，将IP地址为2.2.2.2的HTTPDNS迁移到4.4.4.4的IP地址。此时，客户端进行主动更新地址列表时，地址列表中的所有IP地址均不可达或者这些IP地址对应的HTTPDNS已经不能解析上述待解析域名，此时，客户端向权威DNS发送域名解析的请求，权威DNS向该客户端返回包含IP地址3.3.3.3和4.4.4.4的地址，客户端将地址列表更新为3.3.3.3和4.4.4.4。

需要说明的是，客户端在更新地址列表后，可以从更新的地址列表中确定目标HTTPDNS的地址，进而向该目标HTTPDNS的地址发起包括待解析的域名的HTTP请求，以获取到该目标HTTPDNS返回的解析结果。

需要注意的是，客户端向权威DNS发送域名解析请求时，一般需要通过Local DNS向权威DNS发送域名解析请求，并通过Local DNS接收到权威DNS返回的地址。而客户端在与Local DNS信息交互时，Local DNS容易发生域名劫持，因此，本方案中优先利用客户端的地址列表中的HTTPDNS返回的地址更新地址列表，在地址列表中的所有地址均不可用时，才会利用经过Local DNS返回的地址更新地址列表。

本发明上述实施例中，客户端自动去更新地址列表，使得客户端的地址列表与HTTPDNS以及权威DNS上的地址保持一致，实现了对地址列表中的无效地址的排除，进而避免无效地址对域名解析所造成的错误以及性能开销，另外，本发明实施例中，优先利用地址列表中的HTTPDNS的地址发送目标域名为所述HTTPDNS本身的HTTP域名解析请求，在地址列表中的所有地址均不可达或者解析错误时，才会向权威DNS发送域名解析请求，进而根据权威DNS返回的地址更新地址列表，降低了权威DNS返回的地址被域名劫持的可能性，提高系统的安全可靠性。

需要说明的是，客户端不仅可以在确定目标HTTPDNS的地址之前主动更新地址列表，也可以在确定目标HTTPDNS的地址后，更新地址列表。

根据示例实施例，当客户端从地址列表中确定目标HTTPDNS的地址后，如果该目标HTTPDNS的地址不可达或者该目标HTTPDNS域名解析失败时，客户端可以向地址列表中的其他HTTPDNS的地址发送目标域名为所述HTTPDNS本身的HTTP域名解析请求，以获取到所述其他HTTPDNS返回的HTTPDNS的地址。

例如，当客户端配置了包括1.1.1.1与2.2.2.2的IP地址的地址列表，通过响应测速，1.1.1.1为目标HTTPDNS的地址。而此时运营人员配置将IP地址为1.1.1.1的HTTPDNS迁移到3.3.3.3的IP地址，则2.2.2.2IP的地址对应的HTTPDNS上记录的能够解析待解析域名的HTTPDNS的地址的地址列表包括：2.2.2.2和3.3.3.3。当客户端向地址为1.1.1.1的标HTTPDNS发送HTTP请求，会出现该请求不可达或者目标HTTPDNS响应超时等错误。此时，该客户端向2.2.2.2的IP地址发送目标域名为所述HTTPDNS本身的HTTP域名解析请求，进而客户端可以从IP地址为2.2.2.2的HTTPDNS处获取到能够解析待解析域名的HTTPDNS的地址2.2.2.2和3.3.3.3，客户端将地址列表更新为2.2.2.2和3.3.3.3。

需要说明的是，在确定目标HTTPDNS时，可以根据地址列表中的各个HTTPDNS的测速结果，对各个HTTPDNS进行排序，在目标HTTPDNS的地址不可达或者该目标HTTPDNS域名解析失败时，可以利用测速结果第二的HTTPDNS进行域名解析，或者客户端可以向该测速结果第二的HTTPDNS的地址发送目标域名为该测速结果第二的HTTPDNS本身的HTTP域名解析请求，以获取到该测速结果第二的HTTPDNS返回的HTTPDNS的地址。

进一步的，当客户端从地址列表中确定目标HTTPDNS的地址后，如果该目标HTTPDNS的地址不可达或者该目标HTTPDNS域名解析失败时，且地址列表中的其他地址也不可达或者该目标HTTPDNS域名解析失败时，也就是当地址列表中的所有HTTPDNS的地址不可达或者所有HTTPDNS域名解析失败时，客户端可以向权威DNS发送域名解析请求，以获取到所述权威DNS返回的HTTPDNS的地址，并根据所述HTTPDNS的地址更新所述地址列表。

本发明上述实施例中，在确定的目标HTTPDNS的地址不可达或者该目标HTTPDNS域名解析失败时，客户端根据地址列表中的其他HTTPDNS的地址更新地址列表，实现了对无效的目标HTTPDNS的地址的排除，在更新地址列表后，重新确定目标HTTPDNS的地址，从而利用测速结果最快的HTTPDNS的地址进行域名解析，提高了域名解析的效率，另外，本发明实施例中，优先利用地址列表中的HTTPDNS的地址发送目标域名为所述HTTPDNS本身的HTTP域名解析请求，在地址列表中的所有地址均不可达或者解析错误时，才会向权威DNS发送域名解析请求，进而根据权威DNS返回的地址更新地址列表。

下面介绍本发明实施例提供的装置实施例，其中与前述方法相同的内容将不再重复。

图4是根据一示例性实施例示出的一种域名解析的装置的结构图。

如图4所示，装置400包括：

配置模块410，用于配置能够解析待解析域名的超文本传输协议域名解析服务器HTTPDNS的地址的地址列表；

确定模块420，用于从所述地址列表中确定目标HTTPDNS的地址；

解析模块430，用于向所述目标HTTPDNS的地址发起包括待解析的域名的HTTP请求，以获取到所述HTTPDNS返回的解析结果。

根据示例实施例，所述装置400包括：

发送模块440，用于向所述地址列表中的HTTPDNS的地址发送目标域名为所述HTTPDNS本身的HTTP域名解析请求；

更新模块450，用于根据所述HTTPDNS返回的地址更新所述地址列表。

根据示例实施例，所述发送模块440，还用于当所述地址列表中的所有HTTPDNS的地址不可达或者所有HTTPDNS解析失败时，向权威域名解析服务器DNS发送域名解析请求；

所述更新模块450，还用于根据所述权威DNS返回的地址更新所述地址列表。

根据一些实施例，所述确定模块420，用于分别对所述地址列表中的每个HTTPDNS的地址进行响应测速，将测速结果最快的HTTPDNS的地址作为目标HTTPDNS的地址。

本发明实施例中，通过确定的目标HTTPDNS进行域名解析，基于HTTP现有的安全机制，有效防止了域名劫持，提高了域名解析的安全性和效率。

作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备可以执行：从视图中选择一个控件作为第一控件；根据所述第一控件的控件类型，在所述第一控件上增加第二控件；其中，所述第二控件是基于用户输入的文本生成的。

图5是根据一示例性实施例示出的一种电子设备的结构示意图。需要说明的是，图5示出的电子设备仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图5所示，计算机系统500包括中央处理单元(CPU)501，其可以根据存储在只读存储器(ROM)502中的程序或者从存储部分508加载到随机访问存储器(RAM)503中的程序而执行各种适当的动作和处理。在RAM 503中，还存储有系统500操作所需的各种程序和数据。CPU501、ROM 502以及RAM 503通过总线504彼此相连。输入/输出(I/O)接口505也连接至总线504。

以下部件连接至I/O接口505：包括键盘、鼠标等的输入部分506；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分507；包括硬盘等的存储部分508；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分509。通信部分509经由诸如因特网的网络执行通信处理。驱动器510也根据需要连接至I/O接口505。可拆卸介质511，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器510上，以便于从其上读出的计算机程序根据需要被安装入存储部分508。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分509从网络上被下载和安装，和/或从可拆卸介质511被安装。在该计算机程序被中央处理单元(CPU)701执行时，执行本申请的系统中限定的上述功能。

需要说明的是，本申请所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括配置模块、确定模块、解析模块。其中，这些模块的名称在某种情况下并不构成对该模块本身的限定。

以上具体示出和描述了本发明的示例性实施例。应可理解的是，本发明不限于这里描述的详细结构、设置方式或实现方法；相反，本发明意图涵盖包含在所附权利要求的精神和范围内的各种修改和等效设置。

Claims (12)

1.一种域名解析的方法，其特征在于，所述方法包括：

配置能够解析待解析域名的超文本传输协议域名解析服务器HTTPDNS的地址的地址列表；

从所述地址列表中确定目标HTTPDNS的地址；

向所述目标HTTPDNS的地址发起包括待解析的域名的HTTP请求，以获取到所述目标HTTPDNS返回的解析结果。

2.如权利要求1所述的方法，其特征在于，所述方法还包括：

向所述地址列表中的HTTPDNS的地址发送目标域名为所述HTTPDNS本身的HTTP域名解析请求；

根据所述HTTPDNS返回的地址更新所述地址列表。

3.如权利要求2所述的方法，其特征在于，所述方法还包括：

当所述地址列表中的所有HTTPDNS的地址不可达或者所有HTTPDNS解析失败时，向权威域名解析服务器DNS发送域名解析请求；

根据所述权威DNS返回的地址更新所述地址列表。

4.如权利要求3所述的方法，其特征在于，所述从所述地址列表中确定目标HTTPDNS的地址，包括：

分别对所述地址列表中的每个HTTPDNS的地址进行响应测速，将测速结果最快的HTTPDNS的地址作为目标HTTPDNS的地址。

5.如权利要求4所述的方法，其特征在于，所述方法还包括：

当所述目标HTTPDNS的地址不可达或者所述目标HTTPDNS域名解析失败时，向所述地址列表中的其他HTTPDNS的地址发送包括目标域名为所述HTTPDNS本身的HTTP域名解析请求，以获取到所述其他HTTPDNS返回的HTTPDNS的地址；

根据所述HTTPDNS的地址更新所述地址列表。

6.如权利要求5所述的方法，其特征在于，所述方法还包括：

当所述地址列表中的所有HTTPDNS的地址不可达或者所有HTTPDNS域名解析失败时，向所述权威DNS发送域名解析请求，以获取到所述权威DNS返回的HTTPDNS的地址；

根据所述HTTPDNS的地址更新所述地址列表。

7.一种域名解析的装置，其特征在于，所述装置包括：

配置模块，用于配置能够解析待解析域名的超文本传输协议域名解析服务器HTTPDNS的地址的地址列表；

确定模块，用于从所述地址列表中确定目标HTTPDNS的地址；

解析模块，用于向所述目标HTTPDNS的地址发起包括待解析的域名的HTTP请求，以获取到所述HTTPDNS返回的解析结果。

8.如权利要求7所述的装置，其特征在于，所述装置包括：

发送模块，用于向所述地址列表中的HTTPDNS的地址发送目标域名为所述HTTPDNS本身的HTTP域名解析请求；

更新模块，用于根据所述HTTPDNS返回的地址更新所述地址列表。

9.如权利要求8所述的装置，其特征在于，

所述发送模块，还用于当所述地址列表中的所有HTTPDNS的地址不可达或者所有HTTPDNS解析失败时，向权威域名解析服务器DNS发送域名解析请求；

所述更新模块，还用于根据所述权威DNS返回的地址更新所述地址列表。

10.如权利要求9所述的装置，其特征在于，

所述确定模块，用于分别对所述地址列表中的每个HTTPDNS的地址进行响应测速，将测速结果最快的HTTPDNS的地址作为目标HTTPDNS的地址。

11.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-6任一项所述的方法步骤。

12.一种电子设备，其特征在于，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如权利要求1-6中任一项所述的方法步骤。