CN115118700A - 一种通信方法及通信系统 - Google Patents

一种通信方法及通信系统 Download PDF

Info

Publication number
CN115118700A
CN115118700A CN202210735491.9A CN202210735491A CN115118700A CN 115118700 A CN115118700 A CN 115118700A CN 202210735491 A CN202210735491 A CN 202210735491A CN 115118700 A CN115118700 A CN 115118700A
Authority
CN
China
Prior art keywords
dns
request message
server
dns request
dns64
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202210735491.9A
Other languages
English (en)
Other versions
CN115118700B (zh
Inventor
关佳
卞传旭
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Topsec Technology Co Ltd
Beijing Topsec Network Security Technology Co Ltd
Beijing Topsec Software Co Ltd
Original Assignee
Beijing Topsec Technology Co Ltd
Beijing Topsec Network Security Technology Co Ltd
Beijing Topsec Software Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Topsec Technology Co Ltd, Beijing Topsec Network Security Technology Co Ltd, Beijing Topsec Software Co Ltd filed Critical Beijing Topsec Technology Co Ltd
Priority to CN202210735491.9A priority Critical patent/CN115118700B/zh
Publication of CN115118700A publication Critical patent/CN115118700A/zh
Application granted granted Critical
Publication of CN115118700B publication Critical patent/CN115118700B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08—Protocols for interworking; Protocol conversion

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请涉及一种通信方法及通信系统，应用于请求报文接收模块的通信方法包括：接收IPv6客户端发送的DNS请求报文；根据所述DNS请求报文中携带的相关信息，判断是否需要对所述DNS请求报文进行DNS64处理；若需要，将所述DNS请求报文转发至DNS64服务器；若不需要，将所述DNS请求报文转发至DNS服务器。本申请实施例提供的通信方法及通信系统能够实现IPv6网络和IPv4网络的可靠互访，并提高网络访问的安全性。

Description

一种通信方法及通信系统
技术领域
本申请涉及网络通信技术领域，具体涉及一种通信方法及通信系统。
背景技术
IPv6网络的发展过程中，面临的最大问题是IPv6与IPv4的不兼容，无法实现两种不兼容网络之间的互访。为了实现IPv6与IPv4的互访，设计了DNS64和NAT64技术。目前针对IPv6与IPv4网络互访已有的方案有：IPv6客户端访问IPv4服务器时，通过DNS64进行域名解析(包括前缀合成)，然后通过NAT64实现IPv6与IPv4地址和协议的转换，进而将对应的报文转发给IPv4服务器，实现IPv6和IPv4的网络互访。
现有技术在实现时，需要将IPv6客户端的DNS请求转发到DNS64服务器上，这就需要修改IPv6客户端的DNS地址，如果客户端数量庞大，那么修改配置会带来工作量的增加；如果网络设备商没有权限去修改客户端配置时，就会影响IPv6与IPv4网络互访；且修改IPv6客户端的配置容易被用户察觉。另外，现有技术中，在DNS64服务器上有缓存的情况下，客户端获取到的域名解析结果来自于缓存记录，可能会存在网络访问不通的情况，无法实现IPv6与IPv4的网络互访。
发明内容
鉴于现有技术存在的上述问题，本申请的目的在于提供一种通信方法及通信系统，能够解决现有技术中IPv6与IPv4网络互访受限的技术问题。
为了实现上述目的，本申请实施例提供一种通信方法，应用于请求报文接收模块，所述方法包括：
接收IPv6客户端发送的DNS请求报文；
根据所述DNS请求报文中携带的相关信息，判断是否需要对所述DNS请求报文进行DNS64处理；
若需要，将所述DNS请求报文转发至DNS64服务器；若不需要，将所述DNS请求报文转发至DNS服务器。
在一些实施例中，根据所述DNS请求报文中携带的相关信息，判断是否需要对所述DNS请求报文进行DNS64处理，包括：
若所述DNS请求报文中的携带的源地址是IPv6地址，且所述DNS请求报文对应的DNS请求为A记录或AAAA记录，确定需要对所述DNS请求报文进行DNS64处理。
在一些实施例中，所述方法还包括：
在每次确定需要对所述DNS请求报文进行DNS64处理时，对每次所述确定进行计数；
累计记录需要对所述DNS请求报文进行DNS64处理的次数。
本申请实施例还提供一种通信方法，应用于DNS64服务器，所述方法包括：
接收IPv6客户端发送的DNS请求报文；
判断是否存在所述DNS请求报文对应的缓存记录；
若不存在，将所述DNS请求报文转发至DNS服务器，并将所述DNS服务器返回的第一应答报文转发至所述IPv6客户端；若存在，根据所述DNS请求报文的域名解析次数将对应的第二应答报文转发至所述IPv6客户端。
在一些实施例中，若所述DNS64服务器存在对应的缓存记录，所述方法还包括：
判断所述DNS请求报文的域名解析次数是否达到预设阈值；
若未达到，将所述缓存记录作为所述第二应答报文转发至所述IPv6客户端；若达到，将所述DNS请求报文转发至DNS服务器，并将所述DNS服务器返回的第三应答报文作为所述第二应答报文转发至所述IPv6客户端。
在一些实施例中，所述方法还包括：
确定需要将所述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请求报文；
根据发送的所述DNS请求报文与接收的所述DNS服务器返回的DNS应答报文之间的往返时延确定最优DNS服务器。
在一些实施例中，所述方法还包括：
在第三预设时间内，若对所述DNS请求报文进行至少两次域名解析，获取进行域名解析后的IP地址，其中，所述至少两次域名解析通过与所述DNS64服务器连接的请求报文接收模块确定，所述IP地址通过与所述DNS64服务器连接的DNS服务器获取；
判断所述IP地址是否可达；
若所述IP地址不可达，删除所述DNS请求报文对应的缓存记录，并重新向所述DNS服务器发送所述DNS请求报文，以获取可达的IP地址。
本申请实施例还提供一种通信系统，包括：
请求报文接收模块，配置为：接收IPv6客户端发送的DNS请求报文；根据所述DNS请求报文中携带的相关信息，判断是否需要对所述DNS请求报文进行DNS64处理；若需要，将所述DNS请求报文转发至DNS64服务器；若不需要，将所述DNS请求报文转发至DNS服务器；
所述DNS64服务器，配置为：接收所述请求报文接收模块转发的所述DNS请求报文；判断是否存在所述DNS请求报文对应的缓存记录；若不存在，将所述DNS请求报文转发至DNS服务器，并将所述DNS服务器返回的第一应答报文转发至所述IPv6客户端；若存在，根据所述DNS请求报文的域名解析次数将对应的第二应答报文转发至所述IPv6客户端。
与现有技术相比较，本申请实施例提供的通信方法及通信系统，通过请求报文接收模块判断接收到DNS请求报文是否需要进行DNS64处理，并进行对应的报文转发，可以保证网络连接的畅通，无需更改用户配置即可实现IPv6客户端到IPv4服务器的访问，提高了网络部署的灵活性，且对于想要访问IPv4网络的用户而言是无感的，能够提高用户体验和网络访问效率；同时，还可以针对IPv6客户端的IP和域名进行访问控制，提高了网络访问的安全性。通过DNS64服务器在接收到IPv6客户端发送的DNS请求报文后，判断DNS64服务器是否存在缓存记录，并进行相应的处理，可以保证网络畅通、保障通信正常，实现IPv6网络和IPv4网络的可靠互访。
附图说明
在不一定按比例绘制的附图中，相同的附图标记可以在不同的视图中描述相似的部件。具有字母后缀或不同字母后缀的相同附图标记可以表示相似部件的不同实例。附图大体上通过举例而不是限制的方式示出各种实施例，并且与说明书以及权利要求书一起用于对所申请的实施例进行说明。在适当的时候，在所有附图中使用相同的附图标记指代同一或相似的部分。这样的实施例是例证性的，而并非旨在作为本装置或方法的穷尽或排他实施例。
图1为NAT64与DNS64的网络部署场景示意图；
图2为本申请实施例的通信方法的流程图；
图3为本申请实施例的另一通信方法的流程图；
图4为本申请实施例的DNS64服务器的自学习流程图。
具体实施方式
下面，结合附图对本申请的具体实施例进行详细的描述，但不作为本申请的限定。
应理解的是，可以对此处公开的实施例做出各种修改。因此，上述说明书不应该视为限制，而仅是作为实施例的范例。本领域的技术人员将想到在本申请的范围和精神内的其他修改。
包含在说明书中并构成说明书的一部分的附图示出了本申请的实施例，并且与上面给出的对本申请的大致描述以及下面给出的对实施例的详细描述一起用于解释本申请的原理。
通过下面参照附图对给定为非限制性实例的实施例的优选形式的描述，本申请的这些和其它特征将会变得显而易见。
还应当理解，尽管已经参照一些具体实例对本申请进行了描述，但本领域技术人员能够确定地实现本申请的很多其它等效形式，它们具有如权利要求所述的特征并因此都位于借此所限定的保护范围内。
当结合附图时，鉴于以下详细说明，本申请的上述和其他方面、特征和优势将变得更为显而易见。
此后参照附图描述本申请的具体实施例；然而，应当理解，所公开的实施例仅仅是本申请的实例，其可采用多种方式实施。熟知和/或重复的功能和结构并未详细描述以避免不必要或多余的细节使得本申请模糊不清。因此，本文所公开的具体的结构性和功能性细节并非意在限定，而是仅仅作为权利要求的基础和代表性基础用于教导本领域技术人员以实质上任意合适的详细结构多样地使用本申请。
首先对本申请实施例所涉及的通过DNS64和nat64技术实现IPv6与IPv4网络互访进行简要说明。
图1示出了NAT64与DNS64的网络部署场景示意图(图中实线表示IPv6连线，虚线表示IPv4连线)。如图1所示，IPv6客户端访问IPv4服务器时，通过DNS64服务器进行前缀合成，Pref64::/n(用于进行IPv4地址到IPv6地址合成和NAT64转换的前缀)网段的流量将被路由转发至NAT64路由器上，从而实现IPv6与IPv4地址和协议的转换，可以通过IPv6客户端访问IPv4网络中的资源，与IPv4服务器进行交互。
NAT64是一种有状态的网络地址与协议转换技术，NAT64有两种实现方式：一种是动态NAT64，只适用于IPv6网络侧用户主动发起访问IPv4服务器。另一种是静态NAT64，它是通过静态配置IPv6和IPv4地址之间的映射关系，不仅可以实现IPv6用户访问IPv4服务器，也可以实现IPv4用户访问IPv6。NAT64可实现TCP、UDP、ICMP协议下的IPv6与IPv4网络地址和协议转换。
DNS64主要是配合NAT64工作，进行域名解析，将DNS查询信息中的A记录(IPv4地址)合成到AAAA记录(IPv6地址)中，返回合成的AAAA记录用户给IPv6侧用户(客户端)。具体来说，客户端发送DNS查询到一个DNS64服务器，从DNS请求一个IPv6地址。当IPv6地址被找到时，它就会立即传回给客户端。但是，如果IPv6地址没有找到，DNS64服务器就会转而请求一个IPv4地址。然后DNS64服务器使用IP v4地址的前缀合成一个IPv6地址，并传回给客户端。这样，客户端始终会收到一个IPv6地址。另外，DNS64还可以缓存域名解析结果。
域名系统(DNS)是互联网中提供域名与IP地址互相映射的分布式数据库，域名系统为Internet上的主机分配域名地址和IP地址。用户使用域名地址，域名系统就会自动把域名地址转为IP地址。域名服务是运行域名系统的Internet工具；执行域名服务的服务器称之为DNS服务器，通过DNS服务器来应答域名服务的查询，进而实现网络访问。
图2为本申请实施例的一通信方法的流程图。如图2所示，本申请实施例提供了一种通信方法，应用于请求报文接收模块，所述方法包括：
S101：接收IPv6客户端发送的DNS请求报文。
具体地，用户在IPv6客户端输入url域名(网址)时，确定向请求报文接收模块发起DNS请求，请求报文接收模块接收到对应的DNS请求报文后对其进行解析。
DNS请求报文中可以携带有用户在IPv6客户端输入的url域名，还可以携带有其他与IPv6客户端访问IPv4服务器相关的信息。
S102：根据所述DNS请求报文中携带的相关信息，判断是否需要对所述DNS请求报文进行DNS64处理。
具体地，步骤S102中，根据所述DNS请求报文中携带的相关信息，判断是否需要对所述DNS请求报文进行DNS64处理，包括：
S1021：若所述DNS请求报文中的携带的源地址是IPv6地址，且所述DNS请求报文对应的DNS请求为A记录或AAAA记录，确定需要对所述DNS请求报文进行DNS64处理。
请求报文接收模块可以根据DNS请求报文中携带的源地址信息和对应的DNS请求的类别判断是否需要进行DNS64处理。
步骤S102中，无需修改IPv6客户端的配置，请求报文接收模块接收到的DNS请求报文中的目的地址即为IPv6客户端的DNS服务器地址。
在一些实施例中，步骤S102还包括：
判断所述IPv6客户端的IPv6地址是否在预设的转发名单；或者
判断所述DNS请求报文携带的域名是否在预设的转发名单中。
通过判断IPv6地址或域名是否在预设的转发名单中，可以针对IP和域名对IPv6客户端的访问进行访问控制，提高网络访问的安全性。
S103：若需要，将所述DNS请求报文转发至DNS64服务器；若不需要，将所述DNS请求报文转发至DNS服务器。
请求报文接收模块对DNS请求报文的相关信息进行判断，如果确定需要进行DNS64处理，请求报文接收模块将该DNS请求报文转发至DNS64服务器，利用DNS64服务器对DNS请求报文进行DNS64域名解析等相应处理。如果不需要进行DNS64处理，可以直接根据步骤S102中确定的DNS服务器地址将DNS请求报文转发至对应的IPv4DNS服务器(简称DNS服务器)，以通过DNS服务器进行域名解析，从而得到url域名对应的IP地址，以便用户通过IPv6客户端访问IPv4服务器，实现IPv6网络和IPv4网络的互访。
现有的实现方式中需要将IPv6客户端的DNS地址指定为防火墙接口地址，再通过其DNS64功能，将接收到的DNS报文转发给上游DNS服务器。这样看似容易，但实际使用时，会受限于用户使用环境，例如用户环境中DNS服务器地址往往是自动获取的，客户端数量庞大，或者运维人员没有权限更改客户端配置时，采用现有的实现方式无法实现IPv6和IPv4网络互访。
本申请实施例提供的通信方法中，通过请求报文接收模块判断接收到DNS请求报文是否需要进行DNS64处理，并进行对应的报文转发，可以保证网络连接的畅通，无需更改用户配置即可实现IPv6客户端到IPv4服务器的访问，提高了网络部署的灵活性，且对于想要访问IPv4网络的用户而言是无感的(感知不到DNS64服务器的存在)，能够提高用户体验和网络访问效率；同时，还可以针对IPv6客户端的IP和域名进行访问控制，提高了网络访问的安全性。
需要说明的是，请求报文接收模块可以为网络系统(包括IPv6客户端、IPv4服务器、DNS64服务器、DNS服务器、NAT64路由器等组成的网络)中独立的网络设备，例如可以为一网关，也可以为部署在DNS64服务器等的独立模块，具体的部署方式可以根据实际需要确定，本实施例不具体限定。
在一些实施例中，所述方法还包括：
S201：在每次确定需要对所述DNS请求报文进行DNS64处理时，对每次所述确定进行计数；
S202：累计记录需要对所述DNS请求报文进行DNS64处理的次数。
具体地，根据DNS请求报文中的域名信息，在该域名对应的每次DNS请求需要将DNS请求报文转发至DNS64服务器(需要进行DNS64处理)时，对其进行计数，并统计该域名需要向DNS64服务器进行报文转发的累计次数(需要进行DNS64处理的累计处理次数)，以便后续DNS64服务器进行处理时，采用对应的方式进行DNS64处理，保证IPv6客户端对IPv4服务器的可靠访问。
图3为本申请实施例的另一通信方法的流程图。如图3所示，本申请实施例提供了一种通信方法，应用于DNS64服务器，所述方法包括：
S301：接收IPv6客户端发送的DNS请求报文。
其中，DNS请求报文为IPv6客户端通过请求报文接收模块转发至DNS64服务器的报文。用户在IPv6客户端输入url域名(网址)时，确定向请求报文接收模块发起DNS请求，请求报文接收模块根据DNS请求报文中携带的相关信息确定需要对DNS请求报文进行DNS64处理后，将该DNS请求报文转发至DNS64服务器。
S302：判断是否存在所述DNS请求报文对应的缓存记录。
DNS64服务器接收到该DNS请求报文后，根据DNS请求报文中的域名信息，判断DNS64服务器是否存在对应的缓存记录。
S303：若不存在，将所述DNS请求报文转发至DNS服务器，并将所述DNS服务器返回的第一应答报文转发至所述IPv6客户端；若存在，根据所述DNS请求报文的域名解析次数将对应的第二应答报文转发至所述IPv6客户端。
具体地，如果DNS64服务器不存在对应的缓存记录，确定DNS64服务器之前未向IPv4 DNS服务器发起DNS请求，此时，将DNS请求报文转发至DNS服务器，待DNS服务器返回第一应答报文后，如果是AAAA记录的应答报文，直接将报文转发给IPv6客户端，如果是A记录的应答报文，通过前缀地址合成技术，先将A记录转换成AAAA记录，再将该第一应答报文转发给IPv6客户端。如果DNS64服务器存在缓存记录，可以确定DNS64服务器之前向IPv4 DNS服务器发起过DNS请求，进而根据DNS请求报文的域名解析次数确定对应的第二应答报文，并将其转发至IPv6客户端。
在DNS64服务器上有缓存记录的情况下，客户端获取到的域名解析结果来自于缓存记录，可能会存在网络访问不通的情况，之后再次请求向DNS64服务器发起请求，因为DNS64服务器上已有缓存记录，所以不会重新向DNS服务器发起请求，这会导致网络长时间不通。
本申请实施例提供的通信方法，通过DNS64服务器在接收到IPv6客户端发送的DNS请求报文后，判断DNS64服务器是否存在缓存记录，并进行相应的处理，可以保证网络畅通、保障通信正常，实现IPv6网络和IPv4网络的可靠互访。
在一些实施例中，若所述DNS64服务器存在对应的缓存记录，所述方法还包括：
S3031：判断所述DNS请求报文的域名解析次数是否达到预设阈值；
S3032：若未达到，将所述缓存记录作为所述第二应答报文转发至所述IPv6客户端；若达到，将所述DNS请求报文转发至DNS服务器，并将所述DNS服务器返回的第三应答报文作为所述第二应答报文转发至所述IPv6客户端。
如果DNS64服务器中存在DNS请求报文对应的缓存记录，通过判断所述DNS请求报文的域名解析次数是否达到预设阈值，在该域名解析的次数未达到预设阈值时，可以直接利用该缓存记录对应的域名解析结果进行网络访问；在该域名解析的次数达到预设阈值时，采用与不存在缓存记录时相同的处理方法，重新向DNS服务器发送DNS请求报文，以获取对应的域名解析结果，可以保证网络畅通。
现有技术中，DNS64服务器接收到DNS请求报文后，通常仅仅是简单的查找缓存，如果域名IP被修改，在DNS64服务器已有缓存的时候，IPv6客户端获取不到正确的域名IP，导致网络访问不通。本实施例中，通过记录域名解析请求次数并判断域名解析次数是否达到预设阈值，可以在缓存记录(根据域名解析次数是否达到预设阈值确定)老化前，防止服务器地址变更带来的网络不通问题，及早的更新缓存记录，保障通信正常。
本实施例中，域名解析的次数可以根据请求报文接收模块记录的需要对所述DNS请求报文进行DNS64处理的次数确定(步骤S201和S202)。
在一些实施例中，所述方法还包括：
S401：确定需要将所述DNS请求报文转发至多个DNS服务器；
S402：确定多个所述DNS服务器中存在最优DNS服务器，向所述最优DNS服务器发送所述DNS请求报文；
S403：在第一预设时间内未接收到所述最优DNS服务器返回的DNS应答报文的情况下，向多个所述DNS服务器中的次优DNS服务器发送所述DNS请求报文。
DNS64服务器转发DNS请求报文，往往是向多个DNS服务器上转发，如果DNS64服务器每次都向所有的DNS服务器发起DNS请求，会造成资源利用率不高、系统响应时间增加等。
通过步骤S401至S403，可以优先将DNS请求报文转发至最优DNS服务器，并在最优DNS服务器未进行响应时，将DNS请求报文转发至次优DNS服务器，即在转发DNS请求报文时将DNS请求报文转发至特定的DNS服务器进行域名解析，无需向全部的DNS服务器转发DNS请求报文，提高资源利用率(例如减少网络通信所需带宽、流量等)，并减少系统响应时间(例如无需等待全部的服务器响应或者是由于最优DNS服务器存在故障造成网络响应延迟)，提高网络访问效率。
本实施例中，可以根据DNS服务器的性能对各DNS服务器进行排序，将性能最佳的服务器确定为最优DNS服务器，将性能次佳的服务器确定为次优DNS服务器，依次类推。在对各DNS服务器进行排序得到服务器性能目录后，优先向最优DNS服务器发送DNS请求报文，在第一预设时间内接收到最优DNS服务器返回的DNS应答报文后，确定DNS域名解析成功，可以利用该DNS服务器返回的IP地址实现IPv6客户端对IPv4服务器的访问；若在第一预设时间内未接收到最优DNS服务器返回的DNS应答报文(最优DNS服务器存在故障)，将DNS请求报文转发至次优DNS服务器进行域名解析，依次类推，直至接收到对应DNS服务器返回的DNS应答报文，避免出现故障时一直等待最优DNS服务器响应，提高系统响应速率。当未收到任何DNS应答报文时，DNS64服务器可以报警，提示运维人员DNS服务器或DNS64服务器可能存在故障，及时处理。
DNS服务器的性能可以为DNS服务器解析效率、解析准确率(例如可以根据多次的域名解析结果确定出其中最准确的DNS服务器)、响应速率等。
在一些实施例中，所述方法还包括：
S4031：确定在向所述次优DNS服务器发送所述DNS请求报文后的第二预设时间内，接收到所述次优DNS服务器返回的DNS应答报文；
S4032：更新基于多个DNS服务器确定的最优DNS服务器目录，将所述次优DNS服务器确定为最优DNS服务器。
本实施例中，若在向所述次优DNS服务器发送所述DNS请求报文后的第二预设时间内，接收到所述次优DNS服务器返回的DNS应答报文，确定该次优DNS服务器对域名进行成功解析，可以更新最优DNS服务器目录，将该次优DNS服务器确定为最优DNS服务器；同时，将该次优DNS服务器从对应的次优DNS服务器目录中删除。即本实施例中，可以及时更新DNS服务器，并将DNS请求报文转发至更新后的特定DNS服务器，提高网络访问效率。
进一步地，所述方法还包括：
S4033：确定在向所述次优DNS服务器发送所述DNS请求报文后的第二预设时间内，未接收到所述次优DNS服务器返回的DNS应答报文；
S4034：向所有DNS服务器发送所述DNS请求报文；
S4035：根据发送的所述DNS请求报文与接收的所述DNS服务器返回的DNS应答报文之间的往返时延确定最优DNS服务器。
本实施例中，预先确定出最优DNS服务器和次优DNS服务器，然后在最优DNS服务器和次优DNS服务器均存在故障(通过步骤S403和S4033确定)时，通过步骤S4034和S4035，向全部的DNS服务器转发该DNS请求报文，根据发送的所述DNS请求报文与接收的DNS服务器返回的DNS应答报文之间的往返时延从中重新确定出最优DNS服务器和次优DNS服务器。即本实施例中，无需对全部的DNS服务器进行排序，只要更新其中的最优DNS服务器和次优DNS服务器，可以提高DNS64服务器的处理效率。
最优DNS服务器和次优DNS服务器通过DNS64服务器的自学习确定。具体地，如图4所示，DNS64服务器的自学习过程是在DNS64服务器向DNS服务器转发DNS请求报文开始，在收到DNS服务器返回的DNS应答报文时结束。
DNS64服务器接收到发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服务器和次优DNS服务器)转发DNS请求，计算DNS请求报文和DNS应答报文之间的往返时延，进一步确定最优DNS服务器和次优DNS服务器。类似地，如果不存在最优DNS服务器，也不存在次优DNS服务器，向所有服务器转发DNS请求报文，计算DNS请求报文和DNS应答报文之间的往返时延。
根据DNS请求报文和DNS应答报文之间的往返时延确定最优DNS服务器和次优DNS服务器的自学习过程如下：
根据往返时延确定最优、次优DNS服务器。假设有N个DNS服务器，tXi向第i个DNS服务器发送了请求报文，tRi收到第i个DNS服务器的应答报文，通过探测域名IP，确认地址可达后，计算得出第i个DNS服务器的往返时延Ti＝tRi-tXi，如果探测到域名IP不可达，不做计算。然后通过比较T1、T2...TN的大小，得出最小值Tm、次小值tq，第m个DNS服务器作为最优DNS服务器，第q个DNS服务器作为次优DNS服务器。根据往返时延设置预期时间，如：最优DNS服务器的预期时间是(1+α)Tm，次优DNS服务器的预期时间是(1+β)Tq，其中α、β作为系数，取值区间(0，1)。至此，自学习过程结束。例如，可以将最优DNS服务器的预期时间设为(1+20％)Tm，将次优DNS服务器的预期时间设为(1+30％)。
本实施例中，通过比较每个DNS服务器的往返时延，将用时最短且域名解析结果正确的两个服务器作为最优、次优DNS服务器，分别记录在最优DNS服务器目录和次优DNS服务器目录(最优DNS服务器和次优DNS服务器可以为多个)中，更新最优DNS服务器目录和次优DNS服务器目录。
在一些实施例中，所述方法还包括：
S501：在第三预设时间内，若对所述DNS请求报文进行至少两次域名解析，获取进行域名解析后的IP地址，其中，所述至少两次域名解析通过与所述DNS64服务器连接的请求报文接收模块确定，所述IP地址通过与所述DNS64服务器连接的DNS服务器获取；
S502：判断所述IP地址是否可达；
S503：若所述IP地址不可达，删除所述DNS请求报文对应的缓存记录，并重新向所述DNS服务器发送所述DNS请求报文，以获取可达的IP地址。
本实施例中，缓存记录中记录的主要是域名与IP地址的对应关系、最优DNS服务器的AAAA记录应答结果、或者是根据最优DNS服务器A记录应答合成得出的AAAA记录结果等。
当一段时间内，同一IPv6客户端频繁发起相同域名的DNS请求时，例如，某个域名在短时间(几分钟，如3min)内需要进行两次DNS64处理(域名解析)，触发DNS64服务器的探测机制，DNS64服务器通过探测该域名对应的IP地址，确认不可达后，删除该域名对应的缓存记录，然后重新进行域名解析(重新向DNS服务器发起请求)，将可达的IP地址返回给客户端，并在DNS64服务器上更新该域名的缓存记录，防止因DNS服务器地址变更带来的网络不通问题。即本实施例中，在域名解析后确定网络不通时，可以及时更新域名对应的缓存记录，保证网络畅通。
另外，DNS64服务器可以主动定期更新、维护缓存记录。具体通过定期探测域名对应的IP地址来实现，如果域名对应的IP地址不可达，同样会删除DNS64服务器中该域名对应的缓存记录，然后重新进行域名解析，将可达的域名对应的IP地址记录下来，更新缓存记录，以保证网络畅通。
可以理解的是，由于IPv6主要是为了解决IPv4耗尽问题而提出的，随着越来越多的客户端使用IP v6，网络供应商现在不需同时支持IP v4和IPv6，因此，本实施例中，主要对IPv6客户端到IPv4服务器的访问进行了详细说明。IPv4客户端到IPv6服务器的访问可以参考现有技术，例如当IPv4客客户端发送一个请求到IPv6服务器，任何为合成地址指定的IPv6数据包，都会自动的通过NAT64网关进行路由。该网关执行IPv6到IPv4地址的转换，以及对请求的协议转换；同时，还为了IPv6服务器的响应，执行IP v4到IPv6的转换。
基于上述应用于请求报文接收模块的通信方法，本申请实施例还提供一种请求报文接收模块，包括：
接收单元，配置为接收IPv6客户端发送的DNS请求报文；
判断单元，配置为根据所述DNS请求报文中携带的相关信息，判断是否需要对所述DNS请求报文进行DNS64处理；
处理单元，配置为若需要，将所述DNS请求报文转发至DNS64服务器；若不需要，将所述DNS请求报文转发至DNS服务器。
本申请实施例还提供一种通信装置，包括上述的请求报文接收模块，通信装置可以包括网络安全设备(例如防火墙)、交换机、路由器、服务器、计算机等通信装置。
本领域技术人员可以理解，通信装置可以包括更多或更少的部件，例如，还可包括通信接口等，或者组合某些部件，或者不同的部件布置。
需要说明的是，本申请实施例提供的请求报文接收模块和通信装置与上述实施例中应用于请求报文接收模块的通信方法相对应，基于上述的通信方法，本领域的技术人员能够了解本申请实施例中请求报文接收模块和通信装置具体实施方式以及其各种变化形式，通信方法实施例中的任何可选项也适用于请求报文接收模块和通信装置，在此不再赘述。
基于上述应用于DNS64服务器的通信方法，本申请实施例还提供一种DNS64服务器，包括：
接收单元，配置为接收IPv6客户端发送的DNS请求报文；
判断单元，配置为判断是否存在所述DNS请求报文对应的缓存记录；
处理单元，配置为若不存在，将所述DNS请求报文转发至DNS服务器，并将所述DNS服务器返回的第一应答报文转发至所述IPv6客户端；若存在，根据所述DNS请求报文的域名解析次数将对应的第二应答报文转发至所述IPv6客户端。
需要说明的是，本申请实施例提供的DNS64服务器与上述实施例中应用于DNS64服务器的通信方法相对应，基于上述的通信方法，本领域的技术人员能够了解本申请实施例中DNS64服务器具体实施方式以及其各种变化形式，通信方法实施例中的任何可选项也适用于DNS64服务器，在此不再赘述。
本申请实施例还提供一种通信系统，包括：
请求报文接收模块，配置为：接收IPv6客户端发送的DNS请求报文；根据所述DNS请求报文中携带的相关信息，判断是否需要对所述DNS请求报文进行DNS64处理；若需要，将所述DNS请求报文转发至DNS64服务器；若不需要，将所述DNS请求报文转发至DNS服务器；
所述DNS64服务器，配置为：接收所述请求报文接收模块转发的所述DNS请求报文；判断是否存在所述DNS请求报文对应的缓存记录；若不存在，将所述DNS请求报文转发至DNS服务器，并将所述DNS服务器返回的第一应答报文转发至所述IPv6客户端；若存在，根据所述DNS请求报文的域名解析次数将对应的第二应答报文转发至所述IPv6客户端。
本申请实施例提供的通信系统与上述实施例中应用于请求报文接收模块的通信方法和应用于DNS64服务器的通信方法相对应，基于上述的通信方法，本领域的技术人员能够了解本申请实施例中通信系统具体实施方式以及其各种变化形式，通信方法实施例中的任何可选项也适用于通信系统，在此不再赘述。
本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机可执行指令，所述计算机可执行指令由处理器执行时，实现上述的通信方法。
以上实施例仅为本申请的示例性实施例，不用于限制本申请，本申请的保护范围由权利要求书限定。本领域技术人员可以在本申请的实质和保护范围内，对本申请做出各种修改或等同替换，这种修改或等同替换也应视为落在本申请的保护范围内。

Claims (10)

1.一种通信方法，其特征在于，所述方法应用于请求报文接收模块，所述方法包括：
接收IPv6客户端发送的DNS请求报文；
根据所述DNS请求报文中携带的相关信息，判断是否需要对所述DNS请求报文进行DNS64处理；
若需要，将所述DNS请求报文转发至DNS64服务器；若不需要，将所述DNS请求报文转发至DNS服务器。
2.根据权利要求1所述的方法，其特征在于，根据所述DNS请求报文中携带的相关信息，判断是否需要对所述DNS请求报文进行DNS64处理，包括：
若所述DNS请求报文中的携带的源地址是IPv6地址，且所述DNS请求报文对应的DNS请求为A记录或AAAA记录，确定需要对所述DNS请求报文进行DNS64处理。
3.根据权利要求1所述的方法，其特征在于，所述方法还包括：
在每次确定需要对所述DNS请求报文进行DNS64处理时，对每次所述确定进行计数；
累计记录需要对所述DNS请求报文进行DNS64处理的次数。
4.一种通信方法，应用于DNS64服务器，其特征在于，所述方法包括：
接收IPv6客户端发送的DNS请求报文；
判断是否存在所述DNS请求报文对应的缓存记录；
若不存在，将所述DNS请求报文转发至DNS服务器，并将所述DNS服务器返回的第一应答报文转发至所述IPv6客户端；若存在，根据所述DNS请求报文的域名解析次数将对应的第二应答报文转发至所述IPv6客户端。
5.根据权利要求4所述的方法，其特征在于，若所述DNS64服务器存在对应的缓存记录，所述方法还包括：
判断所述DNS请求报文的域名解析次数是否达到预设阈值；
若未达到，将所述缓存记录作为所述第二应答报文转发至所述IPv6客户端；若达到，将所述DNS请求报文转发至DNS服务器，并将所述DNS服务器返回的第三应答报文作为所述第二应答报文转发至所述IPv6客户端。
6.根据权利要求4所述的方法，其特征在于，所述方法还包括：
确定需要将所述DNS请求报文转发至多个DNS服务器；
确定多个所述DNS服务器中存在最优DNS服务器，向所述最优DNS服务器发送所述DNS请求报文；
在第一预设时间内未接收到所述最优DNS服务器返回的DNS应答报文的情况下，向多个所述DNS服务器中的次优DNS服务器发送所述DNS请求报文。
7.根据权利要求6所述的方法，其特征在于，所述方法还包括：
确定在向所述次优DNS服务器发送所述DNS请求报文后的第二预设时间内，接收到所述次优DNS服务器返回的DNS应答报文；
更新基于多个DNS服务器确定的最优DNS服务器目录，将所述次优DNS服务器确定为最优DNS服务器。
8.根据权利要求6所述的方法，其特征在于，所述方法还包括：
确定在向所述次优DNS服务器发送所述DNS请求报文后的第二预设时间内，未接收到所述次优DNS服务器返回的DNS应答报文；
向所有DNS服务器发送所述DNS请求报文；
根据发送的所述DNS请求报文与接收的所述DNS服务器返回的DNS应答报文之间的往返时延确定最优DNS服务器。
9.根据权利要求6所述的方法，其特征在于，所述方法还包括：
在第三预设时间内，若对所述DNS请求报文进行至少两次域名解析，获取进行域名解析后的IP地址，其中，所述至少两次域名解析通过与所述DNS64服务器连接的请求报文接收模块确定，所述IP地址通过与所述DNS64服务器连接的DNS服务器获取；
判断所述IP地址是否可达；
若所述IP地址不可达，删除所述DNS请求报文对应的缓存记录，并重新向所述DNS服务器发送所述DNS请求报文，以获取可达的IP地址。
10.一种通信系统，其特征在于，包括：
请求报文接收模块，配置为：接收IPv6客户端发送的DNS请求报文；根据所述DNS请求报文中携带的相关信息，判断是否需要对所述DNS请求报文进行DNS64处理；若需要，将所述DNS请求报文转发至DNS64服务器；若不需要，将所述DNS请求报文转发至DNS服务器；
所述DNS64服务器，配置为：接收所述请求报文接收模块转发的所述DNS请求报文；判断是否存在所述DNS请求报文对应的缓存记录；若不存在，将所述DNS请求报文转发至DNS服务器，并将所述DNS服务器返回的第一应答报文转发至所述IPv6客户端；若存在，根据所述DNS请求报文的域名解析次数将对应的第二应答报文转发至所述IPv6客户端。
CN202210735491.9A 2022-06-27 2022-06-27 一种通信方法及通信系统 Active CN115118700B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210735491.9A CN115118700B (zh) 2022-06-27 2022-06-27 一种通信方法及通信系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210735491.9A CN115118700B (zh) 2022-06-27 2022-06-27 一种通信方法及通信系统

Publications (2)

Publication Number Publication Date
CN115118700A true CN115118700A (zh) 2022-09-27
CN115118700B CN115118700B (zh) 2024-03-15

Family

ID=83331056

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210735491.9A Active CN115118700B (zh) 2022-06-27 2022-06-27 一种通信方法及通信系统

Country Status (1)

Country Link
CN (1) CN115118700B (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114143230A (zh) * 2020-09-02 2022-03-04 中国移动通信集团安徽有限公司 双栈用户dns解析时长计算方法及装置

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102340549A (zh) * 2010-07-22 2012-02-01 中国移动通信集团公司 一种域名解析方法及装置
CN102739809A (zh) * 2011-04-07 2012-10-17 中国电信股份有限公司 DNS64数据库、服务器、系统和IPv4/IPv6通信方法
CN103023787A (zh) * 2011-09-26 2013-04-03 百度在线网络技术（北京）有限公司 数据中心系统及装置和提供服务的方法
CN103957283A (zh) * 2011-09-29 2014-07-30 北京奇虎科技有限公司 一种域名系统dns的最优应用服务器选取方法和装置
CN105939398A (zh) * 2015-08-14 2016-09-14 杭州迪普科技有限公司 一种IPv6过渡方法及装置
CN105991347A (zh) * 2015-04-30 2016-10-05 杭州迪普科技有限公司 Dns请求报文的重定向方法和装置
CN106790766A (zh) * 2017-02-17 2017-05-31 郑州云海信息技术有限公司 一种用于客户端的dns服务器智能配置方法
CN109842566A (zh) * 2019-01-10 2019-06-04 杭州迪普科技股份有限公司 一种dns解析方法及装置
CN110784562A (zh) * 2019-10-25 2020-02-11 新华三信息安全技术有限公司 报文转发、域名地址查询方法、装置、设备及介质
CN111049945A (zh) * 2019-12-19 2020-04-21 浙江学海教育科技有限公司 基于http协议的网络请求优化方法、装置、设备及介质

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102340549A (zh) * 2010-07-22 2012-02-01 中国移动通信集团公司 一种域名解析方法及装置
CN102739809A (zh) * 2011-04-07 2012-10-17 中国电信股份有限公司 DNS64数据库、服务器、系统和IPv4/IPv6通信方法
CN103023787A (zh) * 2011-09-26 2013-04-03 百度在线网络技术（北京）有限公司 数据中心系统及装置和提供服务的方法
CN103957283A (zh) * 2011-09-29 2014-07-30 北京奇虎科技有限公司 一种域名系统dns的最优应用服务器选取方法和装置
CN105991347A (zh) * 2015-04-30 2016-10-05 杭州迪普科技有限公司 Dns请求报文的重定向方法和装置
CN105939398A (zh) * 2015-08-14 2016-09-14 杭州迪普科技有限公司 一种IPv6过渡方法及装置
CN106790766A (zh) * 2017-02-17 2017-05-31 郑州云海信息技术有限公司 一种用于客户端的dns服务器智能配置方法
CN109842566A (zh) * 2019-01-10 2019-06-04 杭州迪普科技股份有限公司 一种dns解析方法及装置
CN110784562A (zh) * 2019-10-25 2020-02-11 新华三信息安全技术有限公司 报文转发、域名地址查询方法、装置、设备及介质
CN111049945A (zh) * 2019-12-19 2020-04-21 浙江学海教育科技有限公司 基于http协议的网络请求优化方法、装置、设备及介质

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
庞镭，赵宇: ""高校校园网IPv6到IPv4转换策略探讨及实现"", 《中国新通信》, 5 September 2019 (2019-09-05) *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114143230A (zh) * 2020-09-02 2022-03-04 中国移动通信集团安徽有限公司 双栈用户dns解析时长计算方法及装置
CN114143230B (zh) * 2020-09-02 2023-07-21 中国移动通信集团安徽有限公司 双栈用户dns解析时长计算方法及装置

Also Published As

Publication number Publication date
CN115118700B (zh) 2024-03-15

Similar Documents

Publication Publication Date Title
US11909639B2 (en) Request routing based on class
CN111262938B (zh) 一种dns服务器选择方法和代理服务器
US7653747B2 (en) Resolving virtual network names
EP2266064B1 (en) Request routing
US7711800B2 (en) Network connectivity determination
US8160062B2 (en) Network connectivity determination based on passive analysis of connection-oriented path information
US10313299B2 (en) Domain name system (DNS) and domain name service method based on user information
KR20110040875A (ko) 네트워크 연산 요소들을 이용한 요청 라우팅
CN115118700B (zh) 一种通信方法及通信系统
CN114374669A (zh) Vpn客户端代理dns解析方法及系统
JP5283271B2 (ja) ネットワークにおけるサーバ選択方法，選択システム及びプログラム

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant