Domain name resolution method and device and related product

Abstract

The invention discloses a domain name resolution method and device and a related product. After domain name information needing to be analyzed is determined, whether DNS cache information corresponding to the domain name information exists locally or not is inquired; and if so, further judging the validity and credibility of the information. For effective DNS cache information, in order to improve smooth access of a user, the downloaded use experience can be directly reused. In the scheme, whether domain name resolution needs to be requested again or not is evaluated according to credibility or not, DNS cache information of the domain name information is refreshed, and the DNS resolution request of the same domain name is supported by the newly stored DNS cache information. According to the mode of refreshing the DNS cache information according to the credibility, the DNS cache information with high credibility is fully prepared and provided, and the purpose of responding to continuous URL requests more quickly can be achieved. Therefore, the smooth experience of the user during video playing, video downloading, file downloading or service access is improved.

Description

Technical Field

[0001] This application relates to the field of computer technologies, and in particular, to a domain name resolution method, apparatus, and related products. Background Art

[0002] In a general Domain Name System (DNS) resolution solution, each request for a Uniform Resource Locator (URL) requires DNS resolution of the domain name. In practical applications, under weak network conditions, the problem of long DNS resolution time is likely to occur. The long time-consuming single resolution request can easily block subsequent URL requests.

[0003] Time-To-Live (TTL) refers to the time that a domain name resolution record is retained in a DNS server. When the DNS server receives a resolution request, it sends a resolution request to the Name Server (NS) specified by the domain name to obtain the domain name resolution record, which contains the domain name resolution result. After obtaining this record, the DNS server saves the record for a period of TTL. During the saved time, if a resolution request for this domain name is received again, the DNS server does not send a request to the NS but directly returns the domain name resolution result in the obtained domain name resolution record. Currently, although the DNS cache reuse solution based on TTL can reduce the frequency of DNS resolution, when the domain name resolution record expires after reaching TTL, it is still impossible to avoid DNS resolution of the domain name when accessing a URL. Therefore, the DNS cache reuse solution based on TTL may still cause the problem of URL request blocking, affecting the user's access experience. For example, when a user operates video playback, video download, file download, or service access, due to the too slow DNS resolution speed, data reception is delayed, and content playback is stuck or the download fails. Summary of the Invention

[0004] Embodiments of this application provide a domain name resolution method, apparatus, and related products, aiming to respond to URL requests faster and enhance the smooth experience of users when performing video playback, video download, file download, or service access through URL requests.

[0005] In a first aspect of this application, a domain name resolution method is provided. The method includes:

[0006] Determine the domain name information in the URL request;

[0007] Query whether there is corresponding DNS cache information for the domain name information currently;

[0008] If the domain name information currently has corresponding DNS cache information, determine the validity and credibility of the DNS cache information according to the storage time information of the DNS cache information;

[0009] If the DNS cache information is valid, reuse the DNS cache information and return the DNS cache information to the invoker of the URL request. Under the condition that the DNS cache information is not credible, send a domain name resolution request to the DNS server according to the domain name information to refresh the DNS cache information of the domain name information;

[0010] If the DNS cache information is invalid, send a domain name resolution request to the DNS server according to the domain name information, cache the received DNS resolution result as the DNS cache information corresponding to the domain name information, and return the received DNS resolution result to the invoker of the URL request.

[0011] The second aspect of the present application provides a domain name resolution device, which includes:

[0012] A domain name determination unit, configured to determine the domain name information in the URL request;

[0013] A query unit, configured to query whether the domain name information currently has corresponding DNS cache information;

[0014] A storage time comparison unit, configured to determine the validity and credibility of the DNS cache information according to the storage time information of the DNS cache information under the condition that the domain name information currently has corresponding DNS cache information;

[0015] A first sending unit, configured to reuse the DNS cache information and return the DNS cache information to the invoker of the URL request under the condition that the DNS cache information is valid; and, under the condition that the DNS cache information is invalid, return the DNS cache information with valid DNS for the domain name information after a domain name resolution request to the invoker of the URL request;

[0016] A second sending unit, configured to send a domain name resolution request to the DNS server according to the domain name information after reusing and sending the DNS cache information under the condition that the DNS cache information is valid and not credible; and, under the condition that the DNS cache information is invalid, send a domain name resolution request to the DNS server according to the domain name information;

[0017] A storage unit, configured to cache the latest received DNS resolution result as the DNS cache information corresponding to the domain name information.

[0018] A third aspect of the present application provides a requesting device, which includes a processor and a memory:

[0019] The memory is used to store a computer program and transmit the computer program to the processor;

[0020] The processor is used to execute the steps of the domain name resolution method provided in the first aspect according to the instructions in the computer program.

[0021] A fourth aspect of the present application provides a computer-readable storage medium, which is used to store a computer program. When the computer program is executed by a requesting device, the steps of the domain name resolution method provided in the first aspect are implemented.

[0022] A fifth aspect of the present application provides a computer program product, which includes a computer program. When the computer program is executed by a requesting device, the steps of the domain name resolution method provided in the first aspect are implemented.

[0023] From the above technical solutions, it can be seen that the embodiments of the present application have the following advantages:

[0024] In the technical solution of the present application, after determining the domain name information to be resolved, the requesting device (which can also be understood as the local machine) can first query whether there is DNS cache information corresponding to the domain name information locally. If it exists, it is necessary to further determine its validity and credibility. In practical applications, DNS cache information has a certain retention time limit, which also means that it can be used to determine the validity of DNS cache information for a domain name. For valid DNS cache information, in order to improve the user experience of smooth access and download, it can be directly reused. In addition, in this solution, it is also evaluated whether it is necessary to re-request domain name resolution from the DNS server to refresh the DNS cache information of the domain name information, so as to support future possible DNS resolution requests for the same domain name with the newly stored DNS cache information. The method of refreshing DNS cache information according to credibility in this solution fully prepares and provides highly credible DNS cache information, and can achieve the purpose of faster response to consecutive URL requests. Thus, the smooth experience of users during video playback, video download, file download or service access is improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 It is an application scenario architecture diagram provided by an embodiment of the present application;

[0026] Figure 2 It is a flowchart of a domain name resolution method provided by an embodiment of the present application;

[0027] Figure 3 It is a schematic diagram of the stages of the URL request process;

[0028] Figure 4 A scenario architecture diagram for URL access provided by an embodiment of this application;

[0029] Figure 5 A schematic diagram of the browser interface of a requesting device during the process of requesting a link and obtaining and playing a video resource;

[0030] Figure 6 Another flowchart of the domain name resolution method provided by an embodiment of this application;

[0031] Figure 7 Another flowchart of the domain name resolution method provided by an embodiment of this application;

[0032] Figure 8 A schematic structural diagram of a domain name resolution device provided by an embodiment of this application;

[0033] Figure 9 A schematic structural diagram of a requesting device in an embodiment of this application. Detailed implementation manners

[0034] In terms of domain name resolution, currently, the resolution requests are generally made in a serial manner. Specifically, on the premise of currently promoting IPv6, the IPv6 address is generally resolved first. The Linux system natively provides serial requests for IPv4 and IPv6, which is very likely to have the problem of long DNS resolution time under weak network conditions. Once a single request takes too long, it is very likely to affect other subsequent URL requests. Currently, the TTL solution essentially needs to reissue a resolution request when a URL request for the same domain name is received after the DNS cache expires, and it cannot avoid the problem of blocking caused by long request time. Moreover, the continuous existence of this problem to a certain extent affects the user's access, viewing, and downloading experiences, and affects the user retention rate.

[0035] In view of the above problems, in this application, a domain name resolution method, device, and related products are provided to measure the availability of the DNS cache of a domain name in terms of effectiveness and credibility, and confirm whether it needs to be refreshed. Through this solution, more sufficient and effective support is provided for user URL access and data download, ensuring a smooth experience for users during product use. With a higher DNS resolution speed, the competitiveness of the product is enhanced.

[0036] To facilitate the reading and understanding of the technical solution of this application, first, several noun terms that may be involved in the following embodiments of this application are explained.

[0037] DNS: The Domain Name System (DNS) is a service on the Internet. As a distributed database that maps domain names and IP addresses to each other, it enables people to access the Internet more conveniently.

[0038] Domain Name Resolution: Domain name resolution is a service that points a domain name to the IP of a website space, enabling people to conveniently access the website through the registered domain name. An IP address is a digital address that identifies a site on the network. To facilitate memory, a domain name is used to replace the IP address to identify the site address. Domain name resolution is the process of converting a domain name to an IP address. The resolution of domain names is completed by DNS servers.

[0039] URL: Uniform Resource Locator (English: Uniform Resource Locator), also known as Uniform Resource Locator, Location Address, URL Address, commonly known as web page address or simply website address. A URL is the standard address of a resource on the Internet.

[0040] IPv4: Internet Protocol version 4 (English: Internet Protocol version 4), also known as the fourth revision of the Internet Protocol. IPv4 is the fourth revised version in the development process of the Internet Protocol and the first version of this protocol to be widely deployed and used.

[0041] IPv6: Internet Protocol version 6 (English: Internet Protocol version 6) is the latest version of the Internet Protocol and is used as the protocol for the Internet. IPv6 is used to replace IPv4, mainly to solve the problem of IPv4 address exhaustion. At the same time, IPv6 also has many improvements over IPv4 in other aspects. Although IPv6 is designed to replace IPv4, for a long time, IPv4 still occupies a dominant position in Internet traffic, and the growth of IPv6 usage is slow.

[0042] TTL: TTL is the abbreviation of Time-To-Live in English, which means the retention time of a domain name resolution record in a DNS server. When DNS servers around the world receive a resolution request, they will send a resolution request to the NS server specified by the domain name to obtain the resolution record; after obtaining this record, the record will be saved in the DNS server for a period of time. During this period, if the resolution request for this domain name is received again, the DNS server will no longer send a request to the NS, but directly return the record obtained just now. The time this record is retained on the DNS server is the TTL value.

[0043] Figure 1 This is an application scenario architecture diagram provided for the embodiments of this application. In Figure 1The requesting device, DNS server, and NS are shown. In the embodiments of the present application, the requesting device may be a terminal device, including but not limited to mobile phones, desktop computers, tablet computers, laptop computers, handheld computers, intelligent voice interaction devices, intelligent home appliances, vehicle-mounted terminals, aircraft, etc. In specific applications, for example, in a driving environment, a user in the vehicle initiates a URL request through a mobile phone or a vehicle-mounted terminal, and can smoothly experience data playback and resource access by applying the technical solution of the present application. Another example is that in a shopping page displayed in a live broadcast room, a user can select a product of interest by himself and click on the product picture, which is equivalent to initiating a browsing request for the product page of the product, and then jumps to display the page details of the product, such as a display video of the usage method of the product, or pictures of more angles of the product, etc.

[0044] Figure 1 Only a mobile phone is taken as an example form of the requesting device. After receiving the call of the URL request, the requesting device determines the domain name information therein based on this, and queries the local DNS cache in combination with the domain name information. If the requesting device itself caches valid DNS cache information for the domain name information, it can return it to the caller for the caller to access or download data according to the IP address in the received information.

[0045] When necessary, the requesting device also sends a domain name resolution request regarding the domain name information to the DNS server. The DNS server then sends a domain name resolution request to the NS and returns the DNS resolution result to the requesting device. The requesting device caches the latest received DNS resolution result corresponding to the domain name information, and the latest received DNS resolution result is used as DNS cache information for subsequent queries or reuse. For the case where the requesting device originally has DNS cache information for the domain name information, by refreshing the DNS cache of the domain name information, the TTL of the DNS cache of the DNS server regarding the domain name information is also refreshed. For the case where the requesting device originally does not have DNS cache information for the domain name information, the above operations directly fill the blank of the DNS cache information lacking the domain name information.

[0046] In Figure 1 the shown DNS server and NS, each of them can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers. In addition, the DNS server or NS can also be a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, as well as big data and artificial intelligence platforms.

[0047] Figure 2 is a flowchart of a domain name resolution method provided by an embodiment of the present application. As Figure 2The domain name resolution method shown can be applied to a requesting device, and the method may include the following steps:

[0048] S201. Determine the domain name information in the URL request.

[0049] The URL request can be triggered when the user enters a website address or clicks on a link in an application that supports the network of the requesting device.

[0050] Taking a browser as an example for illustration below, the URL request process refers to the communication process between the browser and the server when the user enters a website address or clicks on a link in the browser. Figure 3 is a schematic diagram of the stages of the URL request process. According to Figure 3 shown, the URL request may include the following stages:

[0051] The first stage: DNS resolution.

[0052] DNS resolution is the process of converting the domain name information in the URL into an IP address. Therefore, the purpose of DNS resolution is to find the IP address of the server storing the data required by the URL request.

[0053] The second stage: Establish a TCP connection.

[0054] Before the requesting device communicates with the server corresponding to the IP address, a reliable connection needs to be established. In the example, the browser can establish a TCP connection with the server according to the host name in the website address. Figure 4 shows the scenario architecture of URL access. As Figure 4 shown, after the requesting device 401 obtains the IP address corresponding to the domain name, it can establish a TCP connection with the server 402 corresponding to the IP address and request data. As an example, the browser can send a synchronous data packet to the server 402 to request the establishment of a TCP connection, and the server 402 responds to the browser to agree to the connection after receiving the request, thus establishing the TCP connection.

[0055] The third stage: Send an HTTP request.

[0056] After establishing the TCP connection, the browser sends an HTTP request to the server 402. The request information of the HTTP request may include the request method, URL, HTTP protocol version, request headers, and request body, etc.

[0057] The fourth stage: The server processes the request.

[0058] After receiving the HTTP request from the browser, server 402 executes the corresponding business logic. For example, server 402 can search for the data resources requested by the browser and return the data. The ways for server 402 to process the request can include one or more of the following actions: searching for the requested resources, processing the request, dynamically generating data, returning data, etc. After processing is completed, an HTTP response is returned to the browser.

[0059] The fifth stage: The browser receives and parses the response.

[0060] After receiving the HTTP response, the browser parses it. The content to be parsed can include the response header and the response body. The specific data returned by server 402 can be included in the response body. Metadata information such as the status code, response time, content type, etc. can be included in the response header.

[0061] For example, the purpose of the URL request of the requesting device 401 is to obtain the video resources of the video to be played. When the requesting device 401 obtains the IP address of server 402 storing the video resources, it establishes a TCP connection with server 402 and sends an HTTP request to request the video resources from server 402 at this IP address. After obtaining the video resources, the requesting device 401 displays them to the user for viewing through its own display module in the browser interface. Figure 5 It is a schematic diagram of the browser interface of the requesting device during the process from triggering the link to obtaining and playing the video resources.

[0062] Such as Figure 5 shown, a search box and multiple TV drama web page links, etc. are displayed in the browser. Only the web page links of TV drama A, TV drama B, and TV drama C are shown as examples in the figure. When the user triggers the web page link of TV drama B in the browser, this device, as the requesting device, first sends a URL request to the DNS server for DNS resolution to obtain the IP address of the server corresponding to the resource. After establishing a TCP connection with the server corresponding to the resource based on this IP address and obtaining the resource through an HTTP request, it can be as Figure 5 shown in the right part, and the play resources of TV drama B are displayed in the browser. The user can trigger the play of TV drama B in this browser interface, and can also perform operations such as posting comments in the comment area, browsing comments, and liking comments.

[0063] Since the solution introduced in the embodiments of this application mainly focuses on Figure 3In the first stage shown, therefore, in step S201, it is primarily necessary to determine the domain name information, so that in subsequent steps, the domain name information can be used as the basis for DNS resolution. A complete URL generally includes the following parts: protocol part, domain name part, port part, virtual directory part, file name part, parameter part, and anchor part. Each of the above parts has its corresponding characteristics. Based on these characteristics for analysis, the domain name information can be obtained by parsing the domain name part of the URL.

[0064] S202. Query whether there is corresponding DNS cache information for the current domain name information. If there is corresponding DNS cache information for the current domain name information, then proceed to S203.

[0065] Generally speaking, if the requesting device has sent a resolution request for a certain domain name to the DNS server and successfully obtained the DNS resolution result of that domain name, then the requesting device should have performed the behavior of storing the DNS resolution result or have a DNS resolution record of the DNS resolution result of that domain name. In S202, after the requesting device determines the domain name information for the current URL request, it first queries whether there is corresponding DNS cache information for that domain name information locally.

[0066] In the situation where there is no corresponding DNS cache information for the domain name information, obviously, a domain name resolution request should be sent to the DNS server to meet the current DNS resolution requirement, cache the received DNS resolution result as the DNS cache information corresponding to the domain name information, and return the received DNS resolution result to the caller of the URL request.

[0067] For the case where there is currently corresponding DNS cache information for the domain name information, it is necessary to more carefully judge the availability of the DNS cache information in different situations. The analysis of the availability of the DNS cache information involves validity and credibility. The following S203 mainly analyzes the availability of the existing DNS cache information through validity.

[0068] S203. Determine whether the DNS cache information is valid according to the storage time information of the DNS cache information. If the DNS cache information is valid, then proceed to S204; if it is invalid, then proceed to S207.

[0069] In the embodiment of the present application, the maximum retention time (abbreviated as T_m, also known as the maximum TTL) of the domain name resolution record in the DNS server can be set.

[0070] If the storage time information indicates that the storage time of the DNS cache information is greater than the maximum retention time of the domain name resolution record in the DNS server, it is determined that the DNS cache information on the local machine is invalid. T_u is used to represent the storage time indicated by the storage time information of the DNS cache information. The above judgment logic can be expressed as: if the condition of T_u>T_m is met, it means that the DNS cache information has been retained in the DNS server for too long, and the cache information on the local machine is determined to be invalid. Therefore, T_m can also be regarded as the upper limit of the time for judging the validity of the DNS cache information on the local machine. If the storage time exceeds the upper limit, it is invalid, and entering S207 requires a new request and updating the DNS cache information corresponding to the domain name information on the local machine with the newly received DNS resolution result. On the other hand, if the storage time information indicates that the storage time of the DNS cache information is less than or equal to the maximum retention time (T_u≤T_m), it is determined that the DNS cache information is valid, and entering S204 to apply the cache information.

[0071] S204: Reuse the DNS cache information and return the DNS cache information to the caller of the URL request.

[0072] The caller of the URL request is the user of the DNS cache. It can refer to any application that has a network request, such as a browser, applet, or APP that initiates an access request for the URL. After the judgment of S203, it is determined that the DNS cache information is valid, indicating that the DNS cache information can be provided to the caller of the URL request to enable it to achieve a faster and smoother URL request process, thereby promoting the progress from the second stage to the fifth stage. The reuse of DNS cache information reduces the frequency of sending DNS resolution requests, avoiding the problem of long waiting times due to resolution requests or the problem of blocking subsequent requests due to time-consuming requests.

[0073] S205. Determine whether the DNS cache information is credible based on the storage time information of the DNS cache information. If the DNS cache information is not credible, proceed to S206. If it is credible, end the resolution process.

[0074] In the case where the DNS cache information is valid, it is necessary to further determine the credibility of the DNS cache information. By determining whether it is credible or not, its potential for availability in subsequent periods is evaluated. If the credibility is not up to standard, it indicates that it has low potential for availability. The IP information it reflects is relatively old and may not match the actual situation. In the subsequent period, the effectiveness issues may affect the fluency of subsequent URL requests for the same domain name. If the credibility is up to standard, it indicates that it has high potential for availability. The IP information it reflects is relatively new and has a high match with the actual situation. In the subsequent period, it can more stably guarantee the fluency of URL requests for the same domain name.

[0075] As an example, if the storage time information of the DNS cache information indicates that the storage duration of the DNS cache information is less than or equal to the product of the trust coefficient and the maximum retention time, then it is determined that the DNS cache information is trustworthy; if the storage time information of the DNS cache information indicates that the storage duration of the DNS cache information is greater than the product, and the storage duration is less than or equal to the maximum retention time, then it is determined that the DNS cache information is untrustworthy. Among them, the trust coefficient is a set value greater than 0 and less than 1. For example, this trust coefficient can be represented by K, and the value of K can be 0.5, 0.6 or 0.8, etc. The trust coefficient K can be set according to the strictness of the credibility control. For example, if it is necessary to strictly guarantee the credibility of the used DNS cache information, a relatively small K value can be set; if considering controlling the resolution frequency and the control of credibility is relatively loose, a relatively high K value can be set.

[0076] If K = 0.8 is set, the conditions for judging whether the DNS cache information is trustworthy can be expressed as:

[0077] If T_m * 0.8 < T_u ≤ T_m, then it is judged that the DNS cache information is untrustworthy; if T_ * 0.8 ≥ T_u, then it is judged that the DNS cache information is trustworthy. It can be understood that the greater the gap between T_m and T_u, the higher the credibility of the DNS cache information.

[0078] Regarding the untrustworthy DNS cache information, similar to the situation where the DNS cache information expires, it is necessary to send a domain name resolution request to the DNS server and cache the DNS resolution result. For the untrustworthy situation, caching is performed to refresh the internal DNS cache information, and the TTL of the DNS cache information of the latest cache is updated asynchronously for subsequent use, see S206. For the expired situation, caching the DNS resolution result fills the blank of the DNS cache information lacking the domain name information on the local machine of the previous requesting device, and it is necessary to return it to the caller of the URL request, see S207 below.

[0079] S206. Send a domain name resolution request to the DNS server according to the domain name information to refresh the DNS cache information of the domain name information.

[0080] S207. Send a domain name resolution request to the DNS server according to the domain name information, cache the received DNS resolution result as the DNS cache information corresponding to the domain name information, and return the received DNS resolution result to the caller of the URL request.

[0081] Here, caching the received DNS resolution result as the DNS cache information corresponding to the domain name information means replacing the original invalid DNS cache information with the newly received valid DNS resolution result, achieving the update of the DNS cache information of the domain name information from "invalid" to "valid".

[0082] It should be noted that in this application, the execution order of each step of the method is not limited. For example, Figure 2 The execution order of the method steps shown is only taken as an example, and the execution order of some steps can be swapped or adjusted in other ways.

[0083] In the technical solution of this application, after determining the domain name information to be resolved, first query whether there is DNS cache information corresponding to the domain name information on the local device of the requesting device. If it exists, it is necessary to further judge its validity and credibility. In actual applications, DNS cache information has a certain retention time limit, which also means that it can be used to determine the validity of DNS cache information for a domain name. For valid DNS cache information, in order to improve the user's smooth access and download experience, it can be directly reused. In addition, in this solution, it is also evaluated whether it is necessary to request DNS resolution from the DNS server again to refresh the DNS cache information of the domain name information, so as to support future possible DNS resolution requests for the same domain name with the newly stored DNS cache information. The method of refreshing DNS cache information according to credibility in this solution can fully prepare and provide highly credible DNS cache information, and can achieve the purpose of faster response to continuous URL requests. Thus, the smooth experience of users during video playback, video download, file download or service access is improved.

[0084] In the embodiments introduced above, the judgment of the credibility and non-credibility of DNS cache information occurs after reusing the DNS cache information and returning the DNS cache information to the invoker of the URL request. See Figure 2 the execution order of S204 and S205 shown in. In actual applications, other execution orders can also be adopted. For example, first judge the validity and credibility of DNS cache information, and perform the operation of "reusing DNS cache information and returning the DNS cache information to the invoker of the URL request" after meeting the relevant conditions. Figure 6 This is another flowchart of the domain name resolution method provided by the embodiments of this application. In Figure 6 the execution order of the steps of this example implementation method is shown.

[0085] S601. The requesting device determines the domain name information in the URL request.

[0086] S602. The requesting device queries whether there is corresponding DNS cache information for the domain name information currently. If there is corresponding DNS cache information for the domain name information currently, proceed to S603. If there is no corresponding DNS cache information for the domain name information currently, proceed to S607.

[0087] S603. The requesting device determines whether the DNS cache information is valid according to the storage time information of the DNS cache information. If the DNS cache information is valid, proceed to S604. If it is invalid, proceed to S607.

[0088] S604. The requesting device determines whether the DNS cache information is trustworthy according to the storage time information of the DNS cache information. If the DNS cache information is trustworthy, proceed to S605. If the DNS cache information is not trustworthy, proceed to S605 and S606 successively.

[0089] In Figure 6 For the branch cases determined to be trustworthy after S604, the processing flow is indicated by a solid line, and for the cases determined to be untrustworthy, the processing flow is indicated by a dashed line.

[0090] S605. The requesting device reuses the DNS cache information and returns the DNS cache information to the caller of the URL request.

[0091] S606. The requesting device sends a domain name resolution request to the DNS server according to the domain name information to refresh the DNS cache information of the domain name information.

[0092] S607. The requesting device sends a domain name resolution request to the DNS server according to the domain name information, caches the received DNS resolution result as the DNS cache information corresponding to the domain name information, and returns the received DNS resolution result to the caller of the URL request.

[0093] Each of the above steps has been introduced in the method flow shown above for Figure 2 The difference from Figure 6 is in the sequence of reusing the DNS cache information and performing the credibility judgment of the DNS cache information. As shown in the example in Figure 2 , specifically, the credibility is judged first and then the DNS cache information is reused. It should be noted that in the examples in Figure 6 and Figure 2 and Figure 6 , for the case where the DNS cache information is untrustworthy, the DNS cache information is reused first and then a domain name resolution request is sent to the DNS server to obtain the latest DNS resolution result to update the cache.

[0094] In the previous embodiments, for example Figure 2 S206 and S207 in Figure 6In S606 and S607, both involve sending a domain name resolution request to the DNS server according to the domain name information. Additionally, for the case where the requesting device does not currently have the DNS cache information corresponding to the domain name information, it is also necessary to send a domain name resolution request to the DNS server according to the domain name resolution request. The implementation method of sending this domain name resolution request will be introduced below.

[0095] In the existing solutions for the scenario of performing DNS resolution in multiple protocol stacks, generally, a serial request method is adopted. For example, first, request IPv6 address resolution. After obtaining the IPv6 DNS resolution result, then request IPv4 address resolution to obtain the IPv4 DNS resolution result. If the default DNS system interface resolution (serial method) is used, the time consumed for one DNS resolution request is: T4 + T6, and the time consumed for N DNS resolution requests is: N * (T4 + T6). Among them, T4 represents the time consumed by the DNS system interface to resolve the IPv4 address, and T6 represents the time consumed by the DNS system interface to resolve the IPv6 address. It can be seen that the time consumption is relatively long, and it is relatively easy for the resolution time of individual requests to interfere with the normal resolution of other requests in the subsequent serial request queue. In this solution, a parallel request method is proposed to perform DNS resolution requests on the domain name information.

[0096] Specifically, sending a domain name resolution request to the DNS server according to the domain name information may include:

[0097] Adding a DNS resolution request for the domain name information to the DNS resolution request queue; when the DNS resolution task reaches the DNS resolution request for the domain name information in the DNS resolution request queue, splitting the DNS resolution request for the domain name information into an IPv4 DNS resolution request and an IPv6 DNS resolution request for the domain name information; and independently sending the IPv4 DNS resolution request and the IPv6 DNS resolution request respectively.

[0098] The independent sending of the IPv4 DNS resolution request and the IPv6 DNS resolution request respectively includes two optional implementation solutions.

[0099] ① One of the implementation methods for independently sending the IPv4 DNS resolution request and the IPv6 DNS resolution request:

[0100] Add the IPv4 DNS resolution request and the IPv6 DNS resolution request to the thread pool respectively; send the IPv4 DNS resolution request and the IPv6 DNS resolution request in parallel through two idle threads in the thread pool. The thread pool can poll the current idle thread queue in real time and poll the request queue. For the DNS requests newly entered into the request queue, select an idle thread in the thread pool to initiate a DNS resolution request. The IPv4 DNS resolution request is accessed through the protocol outlet bound to IPv4, and the IPv6 DNS resolution request is accessed through the protocol outlet bound to IPv6. The asynchronous parallel requests can also speed up the DNS resolution speed.

[0101] In this implementation, the capacity of the thread pool can also be dynamically adjusted, for example, dynamically adjusted according to the actual situation of the request queue. If there are more request tasks, the number of threads is dynamically expanded; if there are fewer request tasks, the capacity can be dynamically reduced. In this way, it can better match the requirements of the request tasks.

[0102] ② The second implementation method of independently sending IPv4 DNS resolution requests and IPv6 DNS resolution requests:

[0103] Send the IPv4 DNS resolution request through the first network card by binding to the first network card; send the IPv6 DNS resolution request through the second network card by binding to the second network card. Among them, the first network card is a network card that supports at least the IPv4 protocol stack, and the second network card is a network card that supports at least the IPv6 protocol stack. In the example, the first network card can be a WiFi network card, and the second network card can be a cellular network card. Surfing the Internet via WiFi can be simply understood as wireless Internet access. Almost all smartphones, tablets and laptops support Wi-Fi Internet access, which is one of the most widely used wireless network transmission technologies today. In fact, it is to convert the wired network signal into a wireless signal and use a wireless router for related computers, mobile phones, tablets, etc. that support its technology to receive. The cellular network (Cellular network), also known as the mobile network (mobile network), is a mobile communication hardware architecture, which is divided into an analog cellular network and a digital cellular network. Since the signal coverage of each communication base station that constitutes the network coverage is hexagonal, the entire network gets its name because it resembles a honeycomb. Multiple network cards independently send IPv4 DNS resolution requests and IPv6 DNS resolution requests. Compared with a single serial request channel, it can significantly save the time-consuming of the resolution requests.

[0104] For the scenario of reusing DNS cache information, if it contains IPv4 DNS resolution results and IPv6 DNS resolution results, returning the DNS cache information to the caller of the URL request may include: reusing the IPv6 DNS resolution results in the DNS cache information and returning the IPv6 DNS resolution results to the caller of the URL request. By reusing the IPv6 DNS resolution results and preferentially returning the IPv6 DNS results, the purpose of fast DNS resolution can be achieved, and the utilization rate of IPv6 can also be guaranteed, meeting the current requirements for the promotion and popularization of IPv6.

[0105] If the domain name information currently does not have corresponding DNS cache information, or if the DNS cache information is invalid, returning the received DNS resolution results to the caller of the URL request includes: returning the fastest received DNS resolution result among the IPv4 DNS resolution result and the IPv6 DNS resolution result received after the latest domain name resolution request is sent to the caller of the URL request.

[0106] For example, the first thread and the second thread are respectively responsible for sending IPv6 DNS resolution requests and IPv6 DNS resolution requests. When the task of the first thread is completed, the IPv4 DNS resolution result is returned for use by the service layer, stored in the cache and returned to the caller of the URL request. Similarly, when the task of the second thread is completed, the IPv6 DNS resolution result is returned for use by the service layer, stored in the cache and returned to the caller of the URL request. In the IPv6 - priority scenario, the first - time resolution depends on the DNS resolution race between IPv4 and IPv6. The result of the fastest - completed resolution is returned to the caller of the URL request. That is, if the first thread completes the task faster than the second thread, the IPv4 DNS resolution result is preferentially returned during the first - time resolution; conversely, if the second thread completes the task faster than the first thread, the IPv6 DNS resolution result is preferentially returned during the first - time resolution. If there is valid DNS cache information (including DNS resolution results) for the domain name information in the cache, then when the same domain name requests DNS resolution subsequently, the IPv6 DNS resolution result is preferentially returned to ensure the utilization rate of IPv6.

[0107] Combined with the above analysis, if the DNS resolution of the present solution is used, the time taken for one DNS request is: MIN(T4, T6), and the time taken for N DNS resolution requests is: MIN(T4, T6). It can be seen that compared with the conventional serial - request DNS resolution scheme, the present solution reduces the DNS resolution time by nearly half for each DNS resolution request and has no additional overall time consumption for multiple DNS resolution requests.

[0108] Figure 7Another flowchart of the domain name resolution method provided by the embodiments of the present application. In Figure 7 Taking the trust coefficient K = 0.8 as an example, it shows the operation of selecting idle threads from the thread pool to parallelly process IPv4 DNS resolution tasks and IPv6 DNS resolution tasks. As Figure 7 shown, the obtained IPv4 DNS resolution result and IPv6 DNS resolution result can be stored in the cache respectively, and returned to the caller of the URL request.

[0109] Based on the domain name resolution method introduced in the foregoing embodiments, correspondingly, the embodiments of the present application further provide a domain name resolution device. As Figure 8 shown, this figure is a schematic structural diagram of a domain name resolution device. As Figure 8 shown, the domain name resolution device 800 includes:

[0110] A domain name determination unit 801, configured to determine the domain name information in the URL request;

[0111] A query unit 802, configured to query whether there is corresponding DNS cache information for the domain name information currently;

[0112] A storage time comparison unit 803, configured to determine the validity and credibility of the DNS cache information according to the storage time information of the DNS cache information under the condition that there is corresponding DNS cache information for the domain name information currently;

[0113] A first sending unit 804, configured to reuse the DNS cache information and return the DNS cache information to the caller of the URL request under the condition that the DNS cache information is valid; and, configured to return to the caller of the URL request after the domain name information has valid DNS cache information through a domain name resolution request under the condition that the DNS cache information is invalid;

[0114] A second sending unit 805, configured to send a domain name resolution request to the DNS server according to the domain name information after multiplexing and sending the DNS cache information under the condition that the DNS cache information is valid and untrusted; and, configured to send a domain name resolution request to the DNS server according to the domain name information under the condition that the DNS cache information is invalid;

[0115] A storage unit 806, configured to cache the latest received DNS resolution result and refresh the DNS cache information corresponding to the domain name information.

[0116] In an optional implementation manner, the storage time comparison unit 803 is specifically configured to:

[0117] If the stored time information indicates that the storage duration of the DNS cache information is greater than the maximum retention time of the domain name resolution record in the DNS server, determine that the DNS cache information is invalid; if the stored time information indicates that the storage duration of the DNS cache information is less than or equal to the maximum retention time, determine that the DNS cache information is valid;

[0118] If the stored time information indicates that the storage duration of the DNS cache information is less than or equal to the product of the trust coefficient and the maximum retention time, determine that the DNS cache information is trustworthy; if the stored time information indicates that the storage duration of the DNS cache information is greater than the product and less than or equal to the maximum retention time, determine that the DNS cache information is untrustworthy; the trust coefficient is a set value greater than 0 and less than 1.

[0119] In an alternative implementation, the second sending unit 805 is further configured to, when there is currently no corresponding DNS cache information for the domain name information, send a domain name resolution request according to the domain name information; the storage unit 806 is further configured to cache the received DNS resolution result as the DNS cache information corresponding to the domain name information; the first sending unit 804 is further configured to return the DNS cache information to the caller of the URL request.

[0120] In an alternative implementation, the second sending unit 805 is specifically configured to:

[0121] Add a DNS resolution request for the domain name information to the DNS resolution request queue;

[0122] When the DNS resolution task executes the DNS resolution request for the domain name information in the DNS resolution request queue, split the DNS resolution request for the domain name information into an IPv4 DNS resolution request for the domain name information and an IPv6 DNS resolution request for the domain name information;

[0123] Independently send the IPv4 DNS resolution request and the IPv6 DNS resolution request respectively.

[0124] Among them, the independently sending the IPv4 DNS resolution request and the IPv6 DNS resolution request respectively includes:

[0125] Add the IPv4 DNS resolution request and the IPv6 DNS resolution request to the thread pool respectively;

[0126] Send the IPv4 DNS resolution request and the IPv6 DNS resolution request in parallel through two idle threads in the thread pool.

[0127] Alternatively, the separately and independently sending of the IPv4 DNS resolution request and the IPv6 DNS resolution request includes:

[0128] By binding to a first network card, sending the IPv4 DNS resolution request using the first network card; by binding to a second network card, sending the IPv6 DNS resolution request using the second network card; the first network card supports at least the IPv4 protocol stack, and the second network card supports at least the IPv6 protocol stack.

[0129] In an alternative implementation, the DNS cache information includes an IPv4 DNS resolution result and an IPv6 DNS resolution result; the first sending unit 804 is specifically configured to reuse the IPv6 DNS resolution result in the DNS cache information and return the IPv6 DNS resolution result to the caller of the URL request.

[0130] If the domain name information currently does not have corresponding DNS cache information, or if the DNS cache information is invalid, the first sending unit 804 is specifically configured to: return the fastest received DNS resolution result among the IPv4 DNS resolution result and the IPv6 DNS resolution result received after the latest sending of the domain name resolution request to the caller of the URL request.

[0131] An embodiment of the present application provides a requesting device. The requesting device can be a terminal device such as a mobile phone, a desktop computer, a tablet computer, a laptop computer, a handheld computer, a smart voice interaction device, a smart home appliance, a vehicle-mounted terminal, an aircraft, etc. As Figure 9 shown, for the sake of convenience of description, only the parts related to the embodiment of the present application are shown. For the specific technical details not disclosed, please refer to the method part of the embodiment of the present application. Taking the terminal device as a mobile phone as an example:

[0132] Figure 9 What is shown is a block diagram of some structures in the mobile phone provided by the embodiment of the present application. Referring to Figure 9 , the mobile phone includes: a radio frequency (full English name: Radio Frequency, English abbreviation: RF) circuit 1010, a memory 1020, an input unit 1030, a display unit 1040, a sensor 1050, an audio circuit 1060, a wireless fidelity (full English name: wireless fidelity, English abbreviation: WiFi) module 1070, a processor 1080, and a power supply 1090 and other components. Those skilled in the art can understand that Figure 9 the mobile phone structure shown in

[0133] does not constitute a limitation on the mobile phone, and may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements. Figure 9Specifically introduce each component of the mobile phone:

[0134] The RF circuit 1010 can be used for receiving and transmitting signals during information reception or call processes. Specifically, after receiving the downlink information from the base station, it is sent to the processor 1080 for processing; in addition, the uplink data is sent to the base station. Generally, the RF circuit 1010 includes but is not limited to antennas, at least one amplifier, a transceiver, a coupler, a low-noise amplifier (Full English name: LowNoise Amplifier, English abbreviation: LNA), a duplexer, etc. In addition, the RF circuit 1010 can also communicate with the network and other devices through wireless communication. The above wireless communication can use any communication standard or protocol, including but not limited to the Global System of Mobile communication (Full English name: Global System of Mobile communication, English abbreviation: GSM), General Packet Radio Service (Full English name: General Packet Radio Service, GPRS), CodeDivision Multiple Access (Full English name: CodeDivision Multiple Access, English abbreviation: CDMA), Wideband CodeDivision Multiple Access (Full English name: Wideband CodeDivision Multiple Access, English abbreviation: WCDMA), Long TermEvolution (Full English name: Long TermEvolution, English abbreviation: LTE), email, Short Messaging Service (Full English name: Short Messaging Service, SMS), etc.

[0135] The memory 1020 can be used to store software programs and modules. The processor 1080 executes various functional applications and data processing of the mobile phone by running the software programs and modules stored in the memory 1020. The memory 1020 mainly includes a program storage area and a data storage area. Among them, the program storage area can store the operating system, application programs required for at least one function (such as the sound playback function, image playback function, etc.); the data storage area can store data created according to the use of the mobile phone (such as audio data, phone book, etc.). In addition, the memory 1020 can include high-speed random access memory and can also include non-volatile memory, such as at least one magnetic disk storage device, a flash memory device, or other non-volatile solid-state storage devices.

[0136] The input unit 1030 can be used to receive input numerical or character information, and generate key signal inputs related to the user settings and function controls of the mobile phone. Specifically, the input unit 1030 may include a touch panel 1031 and other input devices 1032. The touch panel 1031, also known as a touch screen, can collect touch operations of the user thereon or nearby (such as operations of the user using any suitable object or accessory such as a finger, a stylus, etc. on or near the touch panel 1031), and drive corresponding connection devices according to a preset program. Optionally, the touch panel 1031 may include two parts: a touch detection device and a touch controller. Among them, the touch detection device detects the touch position of the user, detects the signal brought by the touch operation, and transmits the signal to the touch controller; the touch controller receives the touch information from the touch detection device, converts it into contact coordinates, and then sends it to the processor 1080, and can receive and execute the commands sent by the processor 1080. In addition, various types such as resistive, capacitive, infrared, and surface acoustic wave can be used to implement the touch panel 1031. In addition to the touch panel 1031, the input unit 1030 may further include other input devices 1032. Specifically, the other input devices 1032 may include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control keys, power on / off keys, etc.), a trackball, a mouse, a joystick, etc.

[0137] The display unit 1040 can be used to display the information input by the user or the information provided to the user and various menus of the mobile phone. The display unit 1040 may include a display panel 1041. Optionally, the display panel 1041 can be configured in forms such as a liquid crystal display (English full name: Liquid Crystal Display, English abbreviation: LCD), an organic light-emitting diode (English full name: Organic Light-Emitting Diode, English abbreviation: OLED), etc. Further, the touch panel 1031 can cover the display panel 1041. When the touch panel 1031 detects a touch operation thereon or nearby, it is transmitted to the processor 1080 to determine the type of touch event. Subsequently, the processor 1080 provides corresponding visual output on the display panel 1041 according to the type of touch event. Although in Figure 9 the touch panel 1031 and the display panel 1041 are implemented as two independent components to realize the input and input functions of the mobile phone, in some embodiments, the touch panel 1031 and the display panel 1041 can be integrated to realize the input and output functions of the mobile phone.

[0138] The mobile phone may further include at least one sensor 1050, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor. Among them, the ambient light sensor can adjust the brightness of the display panel 1041 according to the brightness of the ambient light, and the proximity sensor can turn off the display panel 1041 and / or the backlight when the mobile phone is moved to the ear. As a kind of motion sensor, the accelerometer sensor can detect the magnitude of acceleration in various directions (generally three axes), and can detect the magnitude and direction of gravity when stationary, and can be used for applications that identify the posture of the mobile phone (such as horizontal and vertical screen switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer, tapping), etc.; as for other sensors that the mobile phone can also be configured with, such as gyroscopes, barometers, hygrometers, thermometers, infrared sensors, etc., they will not be elaborated here.

[0139] The audio circuit 1060, the speaker 1061, and the microphone 1062 can provide an audio interface between the user and the mobile phone. The audio circuit 1060 can transmit the electrical signal converted from the received audio data to the speaker 1061, and the speaker 1061 converts it into a sound signal for output; on the other hand, the microphone 1062 converts the collected sound signal into an electrical signal, which is received by the audio circuit 1060 and then converted into audio data. After the audio data is output to the processor 1080 for processing, it is sent through the RF circuit 1010 to, for example, another mobile phone, or the audio data is output to the memory 1020 for further processing.

[0140] WiFi belongs to short - range wireless transmission technology. The mobile phone can help users send and receive emails, browse the web, and access streaming media through the WiFi module 1070, which provides users with wireless broadband Internet access. Although Figure 9 the WiFi module 1070 is shown, it can be understood that it does not belong to the essential composition of the mobile phone and can be omitted completely within the scope of not changing the essence of the invention according to needs.

[0141] The processor 1080 is the control center of the mobile phone, connecting various parts of the entire mobile phone using various interfaces and lines. By running or executing software programs and / or modules stored in the memory 1020, and by calling the data stored in the memory 1020, it executes various functions of the mobile phone and processes data, thereby collecting overall data and information of the mobile phone. Optionally, the processor 1080 may include one or more processing units; preferably, the processor 1080 may integrate an application processor and a modem processor. Among them, the application processor mainly processes the operating system, user interface, and application programs, etc., and the modem processor mainly processes wireless communication. It can be understood that the above - mentioned modem processor may not be integrated into the processor 1080 either.

[0142] The mobile phone further includes a power supply 1090 (such as a battery) for powering each component. Preferably, the power supply can be logically connected to the processor 1080 through a power management system, so as to realize functions such as charging management, discharging management, and power consumption management through the power management system.

[0143] Although not shown, the mobile phone may further include a camera, a Bluetooth module, etc., which will not be elaborated here.

[0144] In the embodiment of the present application, the processor 1080 included in the mobile phone further has the following functions:

[0145] Determine the domain name information in the URL request;

[0146] Query whether there is corresponding DNS cache information for the domain name information currently;

[0147] If there is corresponding DNS cache information for the domain name information currently, determine the validity and credibility of the DNS cache information according to the storage time information of the DNS cache information;

[0148] If the DNS cache information is valid, reuse the DNS cache information and return the DNS cache information to the caller of the URL request. Under the condition that the DNS cache information is not credible, send a domain name resolution request to the DNS server according to the domain name information to refresh the DNS cache information of the domain name information;

[0149] If the DNS cache information is invalid, send a domain name resolution request to the DNS server according to the domain name information, cache the received DNS resolution result as the DNS cache information corresponding to the domain name information, and return the received DNS cache result to the caller of the URL request.

[0150] The embodiment of the present application further provides a computer-readable storage medium for storing a computer program. When the computer program runs on a requesting device, the requesting device can be enabled to execute any one of the domain name resolution methods described in the foregoing embodiments.

[0151] The embodiment of the present application further provides a computer program product including a computer program. When it runs on a requesting device, the requesting device can be enabled to execute any one of the domain name resolution methods described in the foregoing embodiments.

[0152] Those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working processes of the above-described system and device can refer to the corresponding processes in the foregoing method embodiments, which will not be elaborated here.

[0153] In the embodiments of the present application, the term "module" or "unit" refers to a computer program with a predetermined function or a part of a computer program, which works together with other related parts to achieve a predetermined goal, and can be fully or partially implemented by using software, hardware (such as a processing circuit or a memory), or a combination thereof. Similarly, one processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be a part of the overall module or unit that includes the function of the module or unit.

[0154] In several embodiments provided by the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments and server embodiments described above are merely illustrative. For example, the division of the devices and servers is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units can be combined or integrated into another device or server, or some features can be ignored or not executed. Another point is that the displayed or discussed couplings or direct couplings or communication connections to each other can be through some interfaces. The indirect couplings or communication connections of the devices or units can be in electrical, mechanical or other forms.

[0155] The devices described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they can be located in one place or distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0156] In addition, in each embodiment of the present application, the functional units can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above integrated units can be implemented in the form of hardware or in the form of software functional units.

[0157] When the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of this application. The foregoing storage medium includes: various media that can store computer programs, such as USB flash drives, mobile hard disks, read-only memories (English full name: Read-Only Memory, English abbreviation: ROM), random access memories (English full name: Random Access Memory, English abbreviation: RAM), magnetic disks, or optical discs.

[0158] The above embodiments are only used to illustrate the technical solutions of this application, rather than to limit them; although this application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of various embodiments of this application.

Claims

1. A domain name resolution method, characterized in that Including: Determine the domain name information in the URL request; Query whether there is corresponding DNS cache information for the domain name information currently; If there is corresponding DNS cache information for the domain name information currently, determine the validity and credibility of the DNS cache information according to the storage time information of the DNS cache information; If the DNS cache information is valid, reuse the DNS cache information and return the DNS cache information to the caller of the URL request. Under the condition that the DNS cache information is not credible, send a domain name resolution request to the DNS server according to the domain name information to refresh the DNS cache information of the domain name information; If the DNS cache information is invalid, send a domain name resolution request to the DNS server according to the domain name information, cache the received DNS resolution result as the DNS cache information corresponding to the domain name information, and return the received DNS resolution result to the caller of the URL request.

2. The method according to claim 1, wherein The determining the validity and credibility of the DNS cache information according to the storage time information of the DNS cache information includes: If the storage time information indicates that the storage duration of the DNS cache information is greater than the maximum retention time of the domain name resolution record in the DNS server, determine that the DNS cache information is invalid; if the storage time information indicates that the storage duration of the DNS cache information is less than or equal to the maximum retention time, determine that the DNS cache information is valid; If the storage time information indicates that the storage duration of the DNS cache information is less than or equal to the product of the credibility factor and the maximum retention time, determine that the DNS cache information is credible; if the storage time information indicates that the storage duration of the DNS cache information is greater than the product and the storage duration is less than or equal to the maximum retention time, determine that the DNS cache information is not credible; the credibility factor is a set value greater than 0 and less than 1.

3. The method according to claim 1, wherein The method further includes: If there is no corresponding DNS cache information for the domain name information currently, send a domain name resolution request to the DNS server according to the domain name information, cache the received DNS resolution result as the DNS cache information corresponding to the domain name information, and return the received DNS resolution result to the caller of the URL request.

4. The method according to any one of claims 1 to 3, characterized in that, Sending a domain name resolution request to the DNS server according to the domain name information includes: Add a DNS resolution request for the domain name information to the DNS resolution request queue; When the DNS resolution task executes to the DNS resolution request for the domain name information in the DNS resolution request queue, split the DNS resolution request for the domain name information into an IPv4 DNS resolution request for the domain name information and an IPv6 DNS resolution request for the domain name information; Send the IPv4 DNS resolution request and the IPv6 DNS resolution request independently respectively.

5. The method according to claim 4, wherein The sending the IPv4 DNS resolution request and the IPv6 DNS resolution request independently respectively includes: Add the IPv4 DNS resolution request and the IPv6 DNS resolution request to the thread pool respectively; Send the IPv4 DNS resolution request and the IPv6 DNS resolution request in parallel through two idle threads in the thread pool.

6. The method according to claim 4, wherein The separately and independently sending the IPv4 DNS resolution request and the IPv6 DNS resolution request includes: Bind to the first network card and send the IPv4 DNS resolution request through the first network card; bind to the second network card and send the IPv6 DNS resolution request through the second network card; the first network card supports at least the IPv4 protocol stack, and the second network card supports at least the IPv6 protocol stack.

7. The method according to claim 4, characterized in that, The DNS cache information includes IPv4 DNS resolution results and IPv6 DNS resolution results; the reusing the DNS cache information and returning the DNS cache information to the caller of the URL request includes: Reuse the IPv6 DNS resolution result in the DNS cache information and return the IPv6 DNS resolution result to the caller of the URL request.

8. The method according to claim 4, characterized in that If the domain name information currently does not have corresponding DNS cache information, or if the DNS cache information is invalid, return the received DNS resolution result to the caller of the URL request, including: Return the fastest received DNS resolution result among the IPv4 DNS resolution result and the IPv6 DNS resolution result received after the latest domain name resolution request to the caller of the URL request.

9. A domain name resolution device, characterized in that: Includes: A domain name determination unit for determining the domain name information in the URL request; A query unit for querying whether the domain name information currently has corresponding DNS cache information; A storage time comparison unit for determining the validity and credibility of the DNS cache information according to the storage time information of the DNS cache information under the condition that the domain name information currently has corresponding DNS cache information; A first sending unit for reusing the DNS cache information and returning the DNS cache information to the caller of the URL request under the condition that the DNS cache information is valid; And, for returning the DNS cache information with valid DNS cache information obtained after the domain name resolution request to the caller of the URL request under the condition that the DNS cache information is invalid; A second sending unit for, under the condition that the DNS cache information is valid but not credible, sending the DNS cache information after reusing and then sending a domain name resolution request to the DNS server according to the domain name information; and, for sending a domain name resolution request to the DNS server according to the domain name information under the condition that the DNS cache information is invalid; A storage unit for caching the latest received DNS resolution result as the DNS cache information corresponding to the domain name information.

10. A requesting device, characterized in that: Includes: A processor and a memory: The memory is used to store a computer program and transmit the computer program to the processor; The processor is configured to execute the steps of the domain name resolution method according to any one of claims 1 to 8 based on the instructions in the computer program.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium is configured to store a computer program, and when the computer program is executed by the requesting device, the steps of the domain name resolution method according to any one of claims 1 to 8 are implemented.

12. A computer program product, characterized in that It includes a computer program, and when the computer program is executed by the requesting device, the steps of the domain name resolution method according to any one of claims 1 to 8 are implemented.

Images