CN114374669B - Vpn客户端代理dns解析方法及系统 - Google Patents

Abstract

本公开涉及一种VPN客户端代理DNS解析方法和系统。所述方法包括：接收DNS查询请求；向用户侧DNS服务器和VPN侧DNS服务器转发所述DNS查询请求；解析来自所述用户侧DNS服务器和所述VPN侧DNS服务器的DNS查询响应报文；以及采用最先接收到的且无差错的查询响应报文进行应答。能避免操作系统的DNS服务器择优机制导致的VPN内网资源访问错误问题，并且不影响访问公网域名。此外，在同时发起DNS请求的情况下，一般对于公网域名、用户侧网络私有域名而言，用户侧DNS服务器解析快，解决了跨运营商以及CDN就近性问题，VPN代理会把DNS解析结果优先返回给应用程序，用户可以快速访问网络，提升了用户上网体验。

Description

VPN客户端代理DNS解析方法及系统

技术领域

本公开涉及VPN技术领域，具体而言，涉及一种VPN客户端代理DNS解析方法及系统。

背景技术

一般用户办公网络中会搭建一个DNS服务器，主机通过配置内网DNS地址和一个公网DNS进行DNS域名解析，这样当内网DNS服务器出现问题时，会采用公网DNS服务器进行解析，内网DNS服务器可以解析客户网络私有域名以及公网域名。

用户在使用VPN时，由于部分VPN资源以域名形式发布，用户原有网络用户侧DNS服务器无法解析VPN域名资源，VPN资源域名要求使用VPN服务器侧DNS服务器进行解析。公网域名可以通过VPN服务器侧DNS服务器进行解析，也可以通过客户原有网络用户侧DNS服务器进行解析，但是客户内部私有域名需要通过原有网络用户侧DNS服务器进行解析。

使用VPN时，内网域名要求使用VPN DNS解析，公网域名要求使用公网DNS解析。在部分操作系统中，可以通过修改注册表、网卡跃点数等常规方法修改网卡的优先级，从而实现优先使用内网DNS服务器对DNS请求进行解析。但是部分操作系统使用常规方法无法修改网卡优先级，VPN在正常连接后公网DNS优先级高于VPN DNS优先级，导致内网域名被解析成公网地址或者不能被解析，从而导致用户无法正确访问内网域名。

现有VPN使用常规方法无法修改网卡优先级，VPN在正常连接后原有网络DNS服务器优先级高于VPN服务器侧DNS服务器优先级，导致VPN资源域名被解析成公网地址或者不能被解析，从而导致用户无法正确访问VPN资源。如果VPN侧DNS服务器不支持解析公网域名，当VPN侧DNS服务器解析失败后，用原有网络DNS服务器进行解析，域名经过两次解析，解析速度慢，严重影响用户体验。如果VPN侧DNS服务器支持解析公网域名，由于用户和VPN测DNS服务器地理位置、运营商等不一样，会导致解析出的IP存在跨运营商以及CDN就近性等问题。

因此，需要一种无需修改网卡优先级的VPN客户端代理DNS解析方法、系统。

发明内容

有鉴于此，本公开提供一种VPN客户端代理DNS解析方法及系统。根据本公开的一方面，提出一种VPN客户端代理DNS解析方法，该方法包括：接收DNS查询请求；向用户侧DNS服务器和VPN侧DNS服务器转发所述DNS查询请求；解析来自所述用户侧DNS服务器和所述VPN侧DNS服务器的DNS查询响应报文；以及采用最先接收到的且无差错的查询响应报文进行应答。

根据本公开的VPN客户端代理DNS解析方法，若首次接收到的查询响应报文非无差错，则缓存所述查询响应报文；在首次接收到非无差错的查询响应报文并缓存所述查询响应报文之后预定时间后，未收到其他查询响应报文时，确定响应超时；以及采用所缓存的查询响应报文进行应答。

根据本公开的VPN客户端代理DNS解析方法，若接收到的响应报文均非无差错，则采用最后接收到的查询响应报文进行应答。

根据本公开的VPN客户端代理DNS解析方法，若在预设时间段内均未接收到查询响应报文，则不进行任何应答。

根据本公开的VPN客户端代理DNS解析方法，在采用所缓存的查询响应报文进行应答之后释放缓存空间。

根据本公开的另一方面，还提出一种VPN客户端系统，该系统包括：接收请求组件，用于接收DNS查询请求；转发组件，用于向用户侧DNS服务器和VPN侧DNS服务器转发所述DNS查询请求；解析组件，用于解析来自所述用户侧DNS服务器和所述VPN侧DNS服务器的查询响应报文；应答组件，用于采用最先接收到的且无差错的查询响应报文进行应答。

根据本公开的VPN客户端代理DNS解析系统，其还包括：缓存组件，用于若首次接收到的响应报文非无差错，则缓存所述查询响应报文；超时检测组件，用于在首次接收到非无差错的查询响应报文并缓存所述查询响应报文之后预定时间后，未收到其他查询响应报文时，确定响应超时；以及所述应答组件，还用于采用所缓存的查询响应报文进行应答。

根据本公开的VPN客户端代理DNS解析系统，其中所述应答组件在接收到的响应报文均非无差错时采用最后接收到的查询响应报文进行应答。

根据本公开的VPN客户端代理DNS解析系统，其中所述应答组件在预设时间段内均未接收到查询响应报文时不进行任何应答。

根据本公开的VPN客户端代理DNS解析系统，其还包括：回收资源组件，用于在采用所缓存的查询响应报文进行应答之后释放缓存空间。

综上所述，采用本公开的VPN客户端代理DNS解析方法和系统，无需要设置网卡优先级，通过VPN客户端监听本地端口，代理本机所有的DNS查询请求，完成DNS请求解析。具体而言，就是当用户端发起DNS查询请求时，VPN客户端收到DNS请求报文，解析请求报文，并代理DNS客户端将DNS查询请求同时转发发给VPN服务器侧DNS服务器和用户侧DNS服务器，并通过解析响应报文将最先到达的正确响应报文反馈给DNS客户端，从而避免部分操作系统的DNS服务器择优机制导致访问VPN内网资源错误，并且不影响访问公网域名。此外，在同时发起DNS请求的情况下，一般对于公网域名、用户侧网络私有域名而言，用户侧DNS服务器解析快，解决了跨运营商以及CDN就近性问题，VPN代理会把DNS解析结果优先返回给应用程序，用户可以快速访问网络，提升了用户上网体验。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本公开。

附图说明

通过参照附图详细描述其示例实施例，本公开的上述和其它目标、特征及优点将变得更加显而易见。下面描述的附图仅仅是本公开的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1所示的是根据本公开实施例的VPN客户端代理DNS解析方法和系统的应用实例示意图。

图2所示的是根据本公开实施例的VPN客户端代理DNS解析方法的流程图。

图3所示的是本公开实施例所采用的DNS报文的结构示意图。

图4所示的是本公开实施例所采用的DNS报文中的标志字段示意图。

图5所示的是根据本公开实施例的VPN客户端代理DNS解析方法的应答过程示意图。

图6所示的是根据本公开实施例的VPN客户端的原理示意图。

具体实施方式

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

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

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

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

本领域技术人员可以理解，附图只是示例实施例的示意图，附图中的模块或流程并不一定是实施本公开所必须的，因此不能用于限制本公开的保护范围。

图1所示的是根据本公开实施例的VPN客户端代理DNS解析方法和系统的应用实例示意图。如图1所示，在VPN(虚拟专用网)的应用环境中，由于部分VPN资源以域名形式发布，用户访问这些资源需要访问VPN侧的DNS(域名系统)服务器，以解析VPN资源域名。访问公用网络和用户内部私有网络上的资源则需要访问原有网络的用户侧的DNS服务器，以解析公网域名和私有网络域名。

VPN资源域名要求使用VPN侧DNS服务器进行解析，用户侧DNS服务器无法解析。公网域名可以通过VPN侧DNS服务器进行解析，也可以通过用户侧DNS服务器进行解析，但是用户私有网络域名需要通过用户侧DNS服务器进行解析。主机在配置DNS服务器时，会配置一个VPN侧DNS服务器的地址和一个公网DNS服务器的地址，以当VPN侧DNS服务器出现问题时，采用公网DNS服务器进行解析。

使用VPN时，内网域名要求使用VPN DNS解析，公网域名要求使用公网DNS解析。为此，有些VPN环境中，人们通常通过修改注册表、网卡跃点数等常规方法修改网卡的优先级，从而实现优先使用内网DNS服务器对DNS请求进行解析。使用常规方法修改网卡优先级比较困难，VPN在正常连接后公网DNS优先级高于VPN DNS优先级，导致内网域名被解析成公网地址或者不能被解析，从而导致用户无法正确访问内网域名。这为人们带来不好的体验，修改网卡优先级对普通用户而言是一项难以克服的技术障碍。因此，本公开提出了一种VPN客户端代理DNS解析方法。

图2所示的是根据本公开实施例的VPN客户端代理DNS解析方法的流程图。域名解析总体可分为两步：首先，本机向域名服务器发出一个DNS请求报文，报文里携带需要查询的域名；之后，域名服务器向本机回应一个DNS响应报文，里面包含域名对应的IP地址。在VPN环境下，VPN客户端会代理本机向域名服务器转发DNS查询请求报文以及接受来自域名服务器的DNS响应报文。

在VPN环境下，VPN客户端启动后，由于DNS协议的默认端口号为53号，VPN客户端即开始监听本机53端口，以代理本机所有的DNS解析。然后将用户侧DNS服务器地址进行保存，并设置物理网卡和虚拟网卡的DNS服务器地址为127.0.0.1。

如图2所示，在S202中，接收DNS查询请求。所述DNS查询请求可以是请求解析VPN资源域名或者公网域名，来自于VPN客户端本身或者是用户需要进行网络通讯的各种应用程序，例如网页浏览应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件、购物类应用等。DNS报文分为请求报文和响应报文。DNS请求报文和DNS响应报文的格式基本相同。图3为DNS报文的结构示意图。

更具体的，当用户端应用程序发起DNS请求时，会发送DNS查询请求报文至本机53端口，此时VPN客户端可新建进程UDP Socket1，通过UDP Socket1接收本机53端口的DNS查询请求，并对所述DNS查询请求进行解析，包括提取请求解析的域名信息。

在S204中，向用户侧DNS服务器和VPN侧DNS服务器转发所述DNS查询请求。更具体的，VPN客户端进程可新建两个UDP Socket：UDP Socket2和UDP Socket3。可用UDP Socket2向用户侧DNS服务器转发DNS查询请求，用UDP Socket3向VPN侧DNS服务器转发DNS查询请求。

在S206中，解析来自所述用户侧DNS服务器和VPN侧DNS服务器的DNS查询响应报文。图4为DNS报文的标志字段的结构示意图。rcode(Reply code)为应答码字段，用于表示响应的差错状态。当值为0时，表示没有错误；当值为1时，表示报文格式错误(Formaterror)，服务器不能理解请求的报文；当值为2时，表示域名服务器失败(Server failure)，因为服务器的原因导致没办法处理这个请求；当值为3时，表示名字错误(Name Error)，只有对授权域名解析服务器有意义，指出解析的域名不存在；当值为4时，表示查询类型不支持(Not Implemented)，即域名服务器不支持查询类型；当值为5时，表示拒绝(Refused)，一般是服务器由于设置的策略拒绝给出应答，如服务器不希望对某些请求者给出应答。

在S208中，采用最先接收到的且无差错的查询响应报文进行应答。更具体的，可根据查询响应报文的应答码是否为0来判断响应报文有无差错。若应答码为0，代表响应报文无差错；若应答码不为0，代表响应报文有差错。将最先接收到的且应答码为0的查询响应报文通过UDP Socket1转发给应用程序。

图5所示的是根据本公开实施例的VPN客户端代理DNS解析方法的应答过程示意图。

如图5所示，在一个实施例中，VPN客户端代理DNS解析方法在步骤S504中判断是否收到第一个响应报文。第一个响应报文可能来自用户侧DNS服务器，也可能来自VPN侧DNS服务器。更具体的，可借助检测与DNS查询请求相对应的应答标志位和缓存标志位的设置情况进行判断。应答标志位和缓存标志位的初始状态均为未设置状态。VPN客户端接收到响应报文后，检测应答标志位和缓存标志位的状态，若应答标志位和缓存标志位均为未设置，则所述报文为第一个收到的响应报文。

在S506中，判断所述第一个响应报文是否无差错。更具体的，检测所述第一个响应报文的应答码。若应答码为0，表示响应报文无差错；若应答码不为0，表示响应报文非无差错。

在S508中，若第一个响应报文无差错，采用第一个响应报文进行应答。更具体的，若检测到所述第一个响应报文的应答码为0，表示所述第一个响应报文无差错，则采用所述第一个响应报文进行应答，应答过程结束。对应答标志位进行设置，以将在后续收到响应报文时，将所收到的响应报文直接丢弃。更具体的，可通过UDP Socket1将所述第一个响应报文转发给应用程序。

在S510中，若第一个响应报文有差错，则缓存第一个收到的响应报文。更具体的，若检测到第一个响应报文的应答码不为0，表示所述第一个响应报文有差错，则缓存所述第一个收到的响应报文。对缓存标志位进行设置。

在S512中，判断是否收到第二个响应报文。更具体的，VPN客户端接收到响应报文后，检测应答标志位和缓存标志位的状态。此时，缓存标志位为已设置，表示收到了第一个响应报文且所述第一个响应报文非无差错，此时收到的响应报文为第二个收到的响应报文。

若收到第二个响应报文，则在S514处采用第二个响应报文进行应答。更具体的，此时，缓存标志位为已设置，表示第一个响应报文有差错，即：返回所述第一个响应报文的那一侧的DNS服务器未能成功解析DNS请求报文中的域名。此时，所述第二个响应报文的应答码为0，表示所述第二个响应报文无差错，则采用所述第二个响应报文进行应答，以保证采用最先收到且无差错的响应报文进行应答，应答过程结束。更具体的，可通过UDP Socket1将所述第二个响应报文转发给应用程序。

可选择地，在一个实施例中，VPN客户端代理DNS解析方法还对响应报文的响应时间进行计时。在VPN客户端转发DNS查询请求开始，针对该DNS查询请求的响应时间进行计时。

如图5所示，在步骤S502处，令t＝0，计时器开始计时。在步骤S504处判断是否收到第一个响应报文的结果为“否”时，进入步骤S520。当在步骤S520中确定t>T时，则表示在预设时间内未收到用户侧DNS服务器和VPN侧DNS服务器响应报文，因此，确定响应超时。因此，在步骤S522，VPN客户端不进行任何应答。即当在预设时间内未收到任何一侧的DNS服务器的响应报文，则不进行任何应答。进而，在步骤S520处确定t小于给定超时阈值T时，VPN客户端会反馈到步骤S504进一步判断是否接收第一个响应报文，并等待第一个响应报文。

可选择地，在步骤S504处判断是否收到第一个响应报文的结果为“是”而在步骤S506处判断是否第一个响应报文无差错的结果为“否”时，还会在步骤S512的判断是否收到第二个响应报文的结果为“否”的情况下确定等待响应是否超时。具体而言，当在步骤S516处确定t>T时，则意味着在超过预定的时间T之后依然未收到第二个响应报文，确定响应超时。同样，在在步骤S516处确定t小于给定超时阈值T时，则VPN客户端会反馈到步骤S512进一步判断是否接收第二个响应报文并等待第二个响应报文。

若在步骤S516处确定t>T，即在等待第二个响应报文的时间超时的情况下，则在步骤S518处采用所缓存的第一响应报文进行应答。更具体的，此时缓存标志位为已设置，表示第一个收到的响应报文有差错，即：返回所述第一个响应报文的那一侧的DNS服务器未能成功解析DNS请求报文中的域名，并且在预设时间内未收到第二个响应报文，则采用缓存的第一个响应报文进行应答。更具体的，可通过UDP Socket1将所述缓存的第一个响应报文转发给应用程序。

可选择地，在步骤S518处采用所缓存的第一响应报文进行应答之后，在步骤S524处，释放缓存空间。更具体的，在确定超时后，检测应答标志位和缓存标志位的状态。此时应答标志位未设置且缓存标志位已设置，表示收到了第一个响应报文且预定时间内未收到第二个响应报文，将缓存的所述第一个响应报文通过UDP Socket1转发给应用程序后，将缓存空间进行释放。

图6所示的是根据本公开实施例的VPN客户端的原理示意图。

如图6所示，VPN客户端系统60包括接收请求组件602、转发组件604、解析组件608和应答组件610。接收请求组件602，用于接收DNS查询请求。转发组件604，用于向用户侧DNS服务器和VPN侧DNS服务器转发所述DNS查询请求。解析组件606，用于解析来自用户侧DNS服务器和VPN侧DNS服务器的查询响应报文。应答组件608，用于采用最先接收到的且无差错的查询响应报文进行应答。

如图6所示，在一个实施例中，VPN客户端系统还可以包括缓存组件610和超时检测组件612。缓存组件610，用于若首次接收到的响应报文非无差错，则缓存所述查询响应报文；超时检测组件612，用于在首次接收到非无差错的查询响应报文并缓存所述查询响应报文之后预定时间后，未收到其他查询响应报文时，确定响应超时；以及应答组件608，还用于采用所缓存的查询响应报文进行应答。

在一个实施例中，如图6所示，VPN客户端系统的应答组件608，还用于若接收到的响应报文均非无差错，则采用最后接收到的查询响应报文进行应答。应答组件608在预设时间段T内均未接收到查询响应报文不进行任何应答。

在一个实施例中，如图6所示，VPN客户端系统还包括回收资源组件612，用于在采用所缓存的查询响应报文进行应答之后释放缓存空间。

综上所述，采用本公开的VPN客户端代理DNS解析方法和系统，无需要设置网卡优先级，通过VPN客户端监听本地端口，代理本机所有的DNS查询请求，完成DNS请求解析。具体而言，就是当用户端发起DNS查询请求时，VPN客户端收到DNS请求报文，解析请求报文，并代理DNS客户端将DNS查询请求同时转发发给VPN服务器侧DNS服务器和用户侧DNS服务器，并通过解析响应报文将最先到达的正确响应报文反馈给DNS客户端，从而避免部分操作系统的DNS服务器择优机制导致访问VPN内网资源错误，并且不影响访问公网域名。此外，在同时发起DNS请求的情况下，一般对于公网域名、用户侧网络私有域名而言，用户侧DNS服务器解析快，解决了跨运营商以及CDN就近性问题，VPN代理会把DNS解析结果优先返回给应用程序，用户可以快速访问网络，提升了用户上网体验。

以上结合具体实施例描述了本公开的基本原理，但是，需要指出的是，对本领域的普通技术人员而言，能够理解本公开的方法和装置的全部或者任何步骤或者部件，可以在任何计算装置(包括处理器、存储介质等)或者计算装置的网络中，以硬件、固件、软件或者它们的组合加以实现，这是本领域普通技术人员在阅读了本公开的说明的情况下运用他们的基本编程技能就能实现的。

因此，本公开的目的还可以通过在任何计算装置上运行一个程序或者一组程序来实现。所述计算装置可以是公知的通用装置。因此，本公开的目的也可以仅仅通过提供包含实现所述方法或者装置的程序代码的程序产品来实现。也就是说，这样的程序产品也构成本公开，并且存储有这样的程序产品的存储介质也构成本公开。显然，所述存储介质可以是任何公知的存储介质或者将来所开发出来的任何存储介质。

还需要指出的是，在本公开的装置和方法中，显然，各部件或各步骤是可以分解和/或重新组合的。这些分解和/或重新组合应视为本公开的等效方案。并且，执行上述系列处理的步骤可以自然地按照说明的顺序按时间顺序执行，但是并不需要一定按照时间顺序执行。某些步骤可以并行或彼此独立地执行。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。

Claims (6)

1.一种VPN客户端代理DNS解析方法，包括：

接收DNS查询请求；

向用户侧DNS服务器和VPN侧DNS服务器转发所述DNS查询请求；

解析来自所述用户侧DNS服务器和所述VPN侧DNS服务器的DNS查询响应报文；以及

采用最先接收到的且无差错的查询响应报文进行应答；

若首次接收到的查询响应报文非无差错，则缓存所述查询响应报文，在首次接收到非无差错的查询响应报文并缓存所述查询响应报文之后预定时间后，未收到其他查询响应报文时，确定响应超时，并采用所缓存的查询响应报文进行应答；以及

若接收到的响应报文均非无差错，则采用最后接收到的查询响应报文进行应答。

2.根据权利要求1所述的方法，还包括：

若在预设时间段内均未接收到查询响应报文，则不进行任何应答。

3.根据权利要求1所述的方法，还包括：

在采用所缓存的查询响应报文进行应答之后释放缓存空间。

4.一种VPN客户端系统，包括：

接收请求组件，用于接收DNS查询请求；

转发组件，用于向用户侧DNS服务器和VPN侧DNS服务器转发所述DNS查询请求；

解析组件，用于解析来自所述用户侧DNS服务器和所述VPN侧DNS服务器的查询响应报文；

应答组件，用于采用最先接收到的且无差错的查询响应报文进行应答；

缓存组件，用于若首次接收到的响应报文非无差错，则缓存所述查询响应报文；

超时检测组件，用于在首次接收到非无差错的查询响应报文并缓存所述查询响应报文之后预定时间后，未收到其他查询响应报文时，确定响应超时，其中所述应答组件采用所缓存的查询响应报文进行应答，以及所述应答组件在接收到的响应报文均非无差错时采用最后接收到的查询响应报文进行应答。

5.根据权利要求4所述的系统，其中,

所述应答组件，还用于若在预设时间段内均未接收到查询响应报文，则不进行任何应答。

6.根据权利要求4所述的系统，还包括：

回收资源组件，用于在采用所缓存的查询响应报文进行应答之后释放缓存空间。