CN109413219A - 一种域名解析方法和装置、服务器及存储介质 - Google Patents

Abstract

本申请提供一种域名解析方法，包括：接收客户端发送的QUIC流，其中，每个QUIC流携带有一个第一域名解析请求消息；获取与该第一域名解析请求消息对应的域名解析响应数据；根据所述域名解析响应数据构造域名解析响应消息；将所述域名解析响应消息添加至所述QUIC流并发送至客户端。本申请提供的域名解析方法，通过将客户端的域名解析请求消息携带于QUIC流中，将域名解析响应数据构造域名解析响应消息并添加至QUIC流中发送至客户端，从而利用了QUIC协议中数据传输的保密性，保证客户端在域名解析过程中发送和接收数据的安全性和隐私性。本申请提供一种域名解析装置、服务器及存储介质。

Description

一种域名解析方法和装置、服务器及存储介质

技术领域

本申请涉及网络通信技术领域，特别涉及一种域名解析方法和装置、服务器及存储介质。

背景技术

网域名称系统(Domain Name System，DNS)是互联网的一项服务，作为将域名和IP地址相互映射的一个分布式数据库，能够使上网者方便地访问互联网，而不用去记忆枯燥繁琐的IP地址数串，为众多网络应用提供基本的支撑。

随着对安全和隐私的日益重视，许多站点逐渐使用安全套接字层超文本传输协议(HTTPS，Hyper Text Transfer Protocol over Secure Socket Layer)协议代替原有的超文本传输协议(HTTP，HyperText Transfer Protocol)协议。但无论使用HTTPS还是HTTP协议，在网络请求过程中均需要经历域名解析过程。如图1所示，客户端20与解析服务器21使用HTTPS协议进行通信，解析服务器21与权威服务器22之间通过网域名称系统安全扩展(DNSSEC，DomainNameSystemSecurityExtensions)协议或DNS协议进行通信。在进行域名解析过程中，客户端20与解析服务器21之间存在许多的安全和隐私方面的问题，如被窃听、被阻断、被篡改，且用户无法阻止，也无法校验域名解析响应数据的结果。

如何保证客户端在域名解析过程中发送和接收数据的安全性和隐私性，是目前需要解决的技术问题。

发明内容

有鉴于此，本申请实施例提供了一种域名解析方法和装置、服务器及存储介质，以解决现有技术中存在的技术缺陷。

根据本申请的一个方面，公开了一种域名解析方法，包括：

接收客户端发送的快速用户数据包协议网络连接(Quick User DatagramProtocol Internet Connections，QUIC)流，其中，每个QUIC流携带有一个第一域名解析请求消息；

获取与该第一域名解析请求消息对应的域名解析响应数据；

根据所述域名解析响应数据构造域名解析响应消息；

将所述域名解析响应消息添加至所述QUIC流并发送至客户端。

可选地，获取与该第一域名解析请求消息对应的域名解析响应数据包括：

解析所述QUIC流并得到其对应的第一域名解析请求消息；

若本地缓存有与该第一域名解析请求消息对应的域名解析响应数据，则执行根据所述域名解析响应数据构造域名解析响应消息的步骤；

若本地未缓存与该第一域名解析请求消息对应的域名解析响应数据，则构造并发送第二域名解析请求至权威服务器，并在收到所述权威服务器发送的域名解析响应数据后，执行根据所述域名解析响应数据构造域名解析响应消息的步骤。

可选地，所述第一域名解析请求消息包括：类型字段，流标识字段，内边距属性长度字段，内边距属性字段，以及域名请求字段。

可选地，所述域名解析响应消息包括：类型字段，流标识字段，内边距属性长度字段，内边距属性字段，以及域名响应字段。

可选地，在接收客户端发送的QUIC流之前，还包括：与客户端之间建立QUIC，并接收客户端定时发送的冗余数据，以维持QUIC有效。

根据本申请的一个方面，本申请实施例还提供了一种域名解析装置，包括：

流接收模块，接收客户端发送的快速用户数据包协议网络连接(Quick UserDatagram Protocol Internet Connections，QUIC)流，其中，每个QUIC流携带有一个第一域名解析请求消息；

响应数据获取模块，获取与该第一域名解析请求消息对应的域名解析响应数据；

响应消息构造模块，根据所述域名解析响应数据构造域名解析响应消息；

响应消息发送模块，将所述域名解析响应消息添加至所述QUIC流并发送至客户端。

可选地，所述响应数据获取模块包括：

流解析模块，解析所述QUIC流并得到其对应的第一域名解析请求消息；

缓存查看模块，若本地缓存有与该第一域名解析请求消息对应的域名解析响应数据，则通知响应消息构造模块动作；若本地未缓存与该第一域名解析请求消息对应的域名解析响应数据，则通知响应数据请求模块动作；

响应数据请求模块，构造并发送第二域名解析请求至权威服务器，并在收到所述权威服务器发送的域名解析响应数据后，通知响应消息构造模块动作。

可选地，所述第一域名解析请求消息包括：类型字段，流标识字段，内边距属性长度字段，内边距属性字段，以及域名请求字段。

可选地，所述域名解析响应消息包括：类型字段，流标识字段，内边距属性长度字段，内边距属性字段，以及域名响应字段。

可选地，在所述流接收模块之前，还包括：

连接建立模块，与客户端之间建立QUIC，并接收客户端定时发送的冗余数据，以维持QUIC有效。

本申请实施例还提供了一种服务器，包括处理器、以及存储器，所述存储器中存储有计算机指令；

在所述应用程序启动时，所述处理器读取所述计算机指令并实现如上所述的域名解析方法。

本申请实施例还提供了一种存储介质，存储有计算机指令，所述计算机指令被执行时实现如上所述的域名解析方法。

本申请提供的域名解析方法和装置、服务器及存储介质，通过将客户端的域名解析请求消息携带于QUIC流中，将域名解析响应数据构造域名解析响应消息并添加至QUIC流中发送至客户端，从而利用了QUIC协议中数据传输的保密性，保证客户端在域名解析过程中发送和接收数据的安全性和隐私性。

附图说明

根据下述参照附图进行的详细描述，本申请的上述和其他目的、特征和优点将变得更加显而易见。

在附图中：

图1是现有技术中的客户端进行域名解析及响应的示意图；

图2是本申请一实施例的客户端进行域名解析及响应的示意图；

图3是本申请一实施例的域名解析方法的流程示意图；

图4是本申请一实施例的域名解析方法的步骤a2的流程示意图；

图5a是本申请一实施例的域名解析帧的格式示意图；

图5b是本申请一实施例中的域名解析字段的结构示意图；

图6是本申请又一实施例的域名解析方法的详细示意图；

图7是本申请一实施例的域名解析装置的结构示意图；

图8是本申请一实施例中的响应数据获取模块的具体结构图；

图9是本申请又一实施例的域名解析装置的结构示意图。

在所有附图中相同的标号指示相似或相应的特征或功能。

具体实施方式

下面结合附图对本申请的具体实施方式进行描述。应该明白的是，本文的教导可以以多种形式具体体现，并且在本文中公开的任何具体结构、功能或两者仅仅是代表性的。基于本实施例的教导，本领域技术人员应该明白的是，本实施例所公开的一个方面可以独立于任何其他方面实现，并且这些方面中的两个或多个方面可以按照各种方式组合。例如，可以使用本文中所阐述的任何数目的方面，实现装置或实践方法。另外，可以使用其他结构、功能、或除了本文所阐述的一个或多个方面之外或不是本文所阐述的一个或多个方面的结构和功能，实现这种装置或实践这种方法。此外，本文所描述的任何方面可以包括权利要求的至少一个元素。

为了克服在HTTPS协议下域名解析过程中的发送和接收数据时存在的安全隐患，本申请实施例公开了一种域名解析方法，以保证客户端在域名解析过程中发送和接收数据的安全性和隐私性。

为了实现上述目的，本申请通过在客户端与解析服务器之间通过QUIC协议通信，以替代现有技术中的HTTPS协议通信。

在详细介绍本实施例的域名解析方法之前，首先对QUIC协议进行介绍。

QUIC协议是谷歌制定的一种基于用户数据包协议(UDP，User DatagramProtocol)的低时延的互联网传输层协议。我们知道，TCP/IP协议族是互联网的基础。其中传输层协议包括TCP和UDP协议。与TCP协议相比，UDP协议更为轻量，但是错误校验也要少得多。这意味着UDP协议往往效率更高(不经常跟服务器端通信查看数据包是否送达或者按序)，但是可靠性比不上TCP协议。通常游戏、流媒体以及VoIP等应用均采用UDP协议，而网页、邮件、远程登录等大部分的应用均采用TCP协议。

QUIC协议很好地解决了当今传输层和应用层面临的各种需求，包括处理更多的连接、安全性、和低延迟。QUIC协议融合了包括TCP、HTTP/2等协议的特性，但基于UDP协议传输。QUIC协议的一个主要目标就是减少连接延迟，当客户端第一次连接服务器时，QUIC协议只需要1个来回通信延迟时间(RTT，Round-Trip Time)的延迟就可以建立可靠安全的连接，相对于TCP+TLS的1-3次RTT要更加快捷。之后客户端可以在本地缓存加密的认证信息，在再次与服务器建立连接时可以实现0个RTT的连接建立延迟。QUIC协议同时复用了HTTP/2协议的多路复用功能(Multiplexing)，但由于QUIC协议基于UDP协议，所以避免了HTTP/2的线头阻塞(Head-of-Line Blocking)问题。因为QUIC协议基于UDP协议，运行在用户域而不是系统内核，使得QUIC协议可以快速地更新和部署，从而很好地解决了TCP协议部署及更新的困难。

而现有技术中，客户端和解析服务器之间建立HTTPS连接时，客户端需要建立安全套接层(Secure Sockets Layer，SSL)连接，在发起域名解析服务前，需额外消耗2个RTT。在较好的网络中，1个RTT大约为60ms，在网络环境较差时，1个RTT会多达数秒，性能成为其主要瓶颈。

所以，QUIC协议相比于HTTPS协议，优势如下：

1)QUIC协议基于UDP协议，因此客户端与解析服务器之间无需建立TCP连接，只需要在客户端与服务器首次通信时耗费1个RTT，其余情况可直接发送请求数据，无需等待连接建立；而HTTPS协议下的域名解析方案则需要等待2个RTT用于建立连接。

2)QUIC协议可包含传输加密层，保证传输数据的保密性，避免了被窃听、篡改等中间人攻击。

3)QUIC协议可以减轻服务器占用系统资源压力，有更优的流量控制和拥塞控制机制。

下面以将本实施例的域名解析方法应用于解析服务器中为例，对本申请实施例的域名解析方法进行详细的说明。如图2所示，客户端20与解析服务器21之间通过QUIC协议通信，解析服务器21与权威服务器22之间通过DNSSEC/DNS协议通信。

具体地，本申请实施例的域名解析方法参见图3，包括以下步骤a1～a4：

a1、接收客户端发送的QUIC流，其中，每个QUIC流携带有一个第一域名解析请求消息。

其中需要说明的是，QUIC流，为一个连接中传递数据的潜在的许多数据传输信道中的一个。一个流是双向的。在流中的数据自动被分解为帧，然后在接收端重新组装。

本申请中，一个QUIC流对应着一次域名解析请求和响应。

a2、获取与该第一域名解析请求消息对应的域名解析响应数据。

具体地，参见图4，步骤a2包括：

a21、解析所述QUIC流并得到其对应的第一域名解析请求消息；

a22、查看本地是否缓存有与该第一域名解析请求消息对应的域名解析响应数据，若是，执行步骤a3；若否，执行步骤a23。

a23、构造并发送第二域名解析请求至权威服务器，并在收到所述权威服务器发送的域名解析响应数据后，执行步骤a3。

本实施例中，与权威服务器之间的通信可以沿用现有的网域名称系统(DNS，DomainNameSystem)协议或网域名称系统安全扩展(DNSSEC，DomainNameSystemSecurityExtensions)协议，第二域名解析请求的格式符合DNS协议或DNSSEC协议的定义。

需要说明的是，在本实施例中，“第一”、“第二”的描述仅用于彼此的区分，而非表示重要程度及顺序、以及互为存在的前提等。

a3、根据所述域名解析响应数据构造域名解析响应消息。其目的是在得到域名解析响应数据后，按照QUIC协议加密数据而得到构造域名解析响应消息，以保证数据传输的保密性。

a4、将所述域名解析响应消息添加至所述QUIC流并发送至客户端。

步骤a4通过将域名解析响应消息添加至QUIC流，从而保证一次域名解析的请求和响应均与一个QUIC流相关联。在处理下一次域名解析请求时，需要另一个QUIC流。

上述步骤a1～a4为对本实施例的域名解析方法的说明。本申请提供的域名解析方法，通过将客户端的域名解析请求消息携带于QUIC流中，将域名解析响应数据构造域名解析响应消息并添加至QUIC流中发送至客户端，从而利用了QUIC协议中数据传输的保密性，保证客户端在域名解析过程中发送和接收数据的安全性和隐私性。

具体地，为了实现域名解析的请求和响应在QUIC协议下的有效传输，在QUIC协议的基础上扩展了域名解析帧，上述第一域名解析请求消息以及域名解析响应消息均遵循域名解析帧的格式。

域名解析帧的格式如图5a所示。

其中，Type为类型字段；

Stream ID为流标识字段；

Padding length为内边距属性长度字段；

Padding为内边距属性字段；

DNS message为域名解析消息字段，可以实现域名解析的请求和响应。DNSmessage的字段格式沿用现有的DNS查询及应答协议，参见图5b。

DNS message主要包括五个部分：

头部，包括标识、标志、问题数、资源记录数、授权资源记录数、额外资源记录数；

域名请求，用于承载域名请求字段；

域名响应，用于承载域名响应字段；

授权；

额外信息。

具体地，第一域名解析请求消息包括：类型字段，流标识字段，内边距属性长度字段，内边距属性字段，以及域名请求字段；

域名解析响应消息包括：类型字段，流标识字段，内边距属性长度字段，内边距属性字段，以及域名响应字段。

实际使用时，解析服务器约定QUIC协议下扩展的域名解析帧使用UDP协议下的端口953，以区别于现有技术的UDP协议下对于普通DNS帧的约定端口53。解析服务器根据接口来判断其是普通DNS帧还是本实施例中的QUIC协议下扩展的域名解析帧。

在本申请的一个实施例中，参见图6，除去公开了上述步骤a1～a4，为了维持与客户端之间的QUIC有效，在步骤a1之前，还包括步骤：

a0、与客户端之间建立QUIC，并接收客户端定时发送的冗余数据，以维持QUIC有效。

其中，客户端定时发送冗余数据可以通过设置定时器的方式。定时器的时间可以为任意，以能保证QUIC有效，例如设置为4秒。

由上可见，本申请提供的域名解析方法，在保证客户端在域名解析过程中发送和接收数据的安全性和隐私性的同时，也提升了通信的性能，降低了服务器的运营成本。

本申请实施例还公开了一种域名解析装置10，如图7所示，包括：

流接收模块101，接收客户端发送的快速用户数据包协议网络连接(QuickUserDatagram Protocol Internet Connections，QUIC)流，其中，每个QUIC流携带有一个第一域名解析请求消息；

响应数据获取模块102，获取与该第一域名解析请求消息对应的域名解析响应数据；

响应消息构造模块103，根据所述域名解析响应数据构造域名解析响应消息；

响应消息发送模块104，将所述域名解析响应消息添加至所述QUIC流并发送至客户端。

本申请实施例的域名解析装置10，通过将客户端的域名解析请求消息携带于QUIC流中，将域名解析响应数据构造域名解析响应消息并添加至QUIC流中发送至客户端，从而利用了QUIC协议中数据传输的保密性，保证客户端在域名解析过程中发送和接收数据的安全性和隐私性。

可选地，参见图8，响应数据获取模块102包括：

流解析模块1021，解析所述QUIC流并得到其对应的第一域名解析请求消息；

缓存查看模块1022，若本地缓存有与该第一域名解析请求消息对应的域名解析响应数据，则通知响应消息构造模块103动作；若本地未缓存与该第一域名解析请求消息对应的域名解析响应数据，则通知响应数据请求模块1023动作；

响应数据请求模块1023，构造并发送第二域名解析请求至权威服务器，并在收到所述权威服务器发送的域名解析响应数据后，通知响应消息构造模块103动作。

可选地，第一域名解析请求消息包括：类型字段，流标识字段，内边距属性长度字段，内边距属性字段，以及域名请求字段。

可选地，域名解析响应消息包括：类型字段，流标识字段，内边距属性长度字段，内边距属性字段，以及域名响应字段。

在本申请的一个实施例中，参见图9，本申请的域名解析装置10除去包括上述模块101～104以外，在流接收模块101之前，还包括：连接建立模块100，用于与客户端之间建立QUIC，并接收客户端定时发送的冗余数据，以维持QUIC有效。

需要说明的是，该域名解析装置与上述的域名解析的方法的技术方案属于同一构思。域名解析装置的技术方案未详细描述的细节内容，均可以参见上述域名解析方法的技术方案的描述。

本发明实施例还公开了一种服务器，包括处理器、以及存储器，所述存储器中存储有计算机指令；在所述应用程序启动时，所述处理器读取所述计算机指令并实现如上所述的域名解析方法。

需要说明的是，所述终端可以为桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。本领域技术人员可以理解的是，终端为用于接收数据并进行处理后输出结构的设备。上述举例并非是对终端的限定，为在某些场合，终端还可以包括输入输出设备、网络接入设备、总线等。

所述处理器可以为中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，所述处理器是所述终端的控制中心，利用各种接口和线路连接整个终端的各个部分。

所述存储器主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如硬盘、内存、插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

本发明实施例还公开了一种存储介质，存储有计算机指令，所述计算机指令被执行时实现如上所述的域名解析方法。

所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

上面结合附图对本申请优选的具体实施方式和实施例作了详细说明，但是本申请并不限于上述实施方式和实施例，在本领域技术人员所具备的知识范围内，还可以在不脱离本申请构思的前提下做出各种变化。

Claims (12)

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

接收客户端发送的快速用户数据包协议网络连接(Quick User Datagram ProtocolInternet Connections，QUIC)流，其中，每个QUIC流携带有一个第一域名解析请求消息；

获取与该第一域名解析请求消息对应的域名解析响应数据；

根据所述域名解析响应数据构造域名解析响应消息；

将所述域名解析响应消息添加至所述QUIC流并发送至客户端。

2.根据权利要求1所述的域名解析方法，其特征在于，获取与该第一域名解析请求消息对应的域名解析响应数据包括：

解析所述QUIC流并得到其对应的第一域名解析请求消息；

若本地缓存有与该第一域名解析请求消息对应的域名解析响应数据，则执行根据所述域名解析响应数据构造域名解析响应消息的步骤；

若本地未缓存与该第一域名解析请求消息对应的域名解析响应数据，则构造并发送第二域名解析请求至权威服务器，并在收到所述权威服务器发送的域名解析响应数据后，执行根据所述域名解析响应数据构造域名解析响应消息的步骤。

3.根据权利要求1或2所述的域名解析方法，其特征在于，所述第一域名解析请求消息包括：类型字段，流标识字段，内边距属性长度字段，内边距属性字段，以及域名请求字段。

4.根据权利要求1或2所述的域名解析方法，其特征在于，所述域名解析响应消息包括：类型字段，流标识字段，内边距属性长度字段，内边距属性字段，以及域名响应字段。

5.根据权利要求1所述的域名解析方法，其特征在于，在接收客户端发送的QUIC流之前，还包括：

与客户端之间建立QUIC，并接收客户端定时发送的冗余数据，以维持QUIC有效。

6.一种域名解析装置，其特征在于，包括：

流接收模块，接收客户端发送的快速用户数据包协议网络连接(Quick User DatagramProtocol Internet Connections，QUIC)流，其中，每个QUIC流携带有一个第一域名解析请求消息；

响应数据获取模块，获取与该第一域名解析请求消息对应的域名解析响应数据；

响应消息构造模块，根据所述域名解析响应数据构造域名解析响应消息；

响应消息发送模块，将所述域名解析响应消息添加至所述QUIC流并发送至客户端。

7.根据权利要求6所述的域名解析装置，其特征在于，所述响应数据获取模块包括：

流解析模块，解析所述QUIC流并得到其对应的第一域名解析请求消息；

缓存查看模块，若本地缓存有与该第一域名解析请求消息对应的域名解析响应数据，则通知响应消息构造模块动作；若本地未缓存与该第一域名解析请求消息对应的域名解析响应数据，则通知响应数据请求模块动作；

响应数据请求模块，构造并发送第二域名解析请求至权威服务器，并在收到所述权威服务器发送的域名解析响应数据后，通知响应消息构造模块动作。

8.根据权利要求6或7所述的域名解析装置，其特征在于，所述第一域名解析请求消息包括：类型字段，流标识字段，内边距属性长度字段，内边距属性字段，以及域名请求字段。

9.根据权利要求6或7所述的域名解析装置，其特征在于，所述域名解析响应消息包括：类型字段，流标识字段，内边距属性长度字段，内边距属性字段，以及域名响应字段。

10.根据权利要求6所述的域名解析装置，其特征在于，在所述流接收模块之前，还包括：

连接建立模块，与客户端之间建立QUIC，并接收客户端定时发送的冗余数据，以维持QUIC有效。

11.一种服务器，其特征在于，包括处理器、以及存储器，所述存储器中存储有计算机指令；

在所述应用程序启动时，所述处理器读取所述计算机指令并实现如权利要求1-5任一项所述的域名解析方法。

12.一种存储介质，其特征在于，存储有计算机指令，所述计算机指令被执行时实现如权利要求1-5任一项所述的域名解析方法。