WO2019061522A1

WO2019061522A1 - Domain name resolution method, client, edge node, and domain name resolution system

Info

Publication number: WO2019061522A1
Application number: PCT/CN2017/105083
Authority: WO
Inventors: 王华涛
Original assignee: 深圳前海达闼云端智能科技有限公司
Priority date: 2017-09-30
Filing date: 2017-09-30
Publication date: 2019-04-04
Also published as: CN108353095B; CN108353095A

Abstract

The present application relates to the technical field of communications, and specifically relates to a domain name resolution method, a client, an edge node, and a domain name resolution system. The domain name resolution method comprises: sending a first Http(s) domain name resolution request to a central domain name server, and when a domain name to be resolved of the first Http(s) domain name resolution request is of a distributed type, receiving a jump status code and a jump URL returned by the central domain name server, the jump URL pointing to serving an edge node of an area where the client is located; sending a second Http(s) domain name resolution request to the edge node according to the jump status code, so that the edge node resolves, according to the second Http(s) domain name resolution request, an IP address corresponding to the domain name to be resolved; and receiving the IP address returned by the edge node. Because the edge node knows the status of each content service node, the resolution result is more accurate. Therefore, an optimal IP address can be recommended for the client.

Description

Domain name resolution method, client, edge node and domain name resolution system

Technical field

The present application relates to the field of communications technologies, and in particular, to a domain name resolution method, a client, an edge node, and a domain name resolution system.

Background technique

In the current mobile Internet technology architecture, the use of Http(s) domain name server for domain name resolution has become more and more widely used. Many Internet operators support the use of http(s) for domain name resolution. The Http(s) domain name server is a mobile application that uses the HTTP protocol to send a domain name resolution request to the Http(s) domain name server, which replaces the traditional way of initiating a resolution request to the operator LocalDNS based on the DNS protocol. Therefore, it can avoid the domain name caused by LocalDNS. Hijacking and cross-network access issues solve the problems caused by abnormal domain name resolution in mobile Internet services.

In the process of implementing the present application, the applicant found that the conventional technology has at least the following problem: the node that returns the IP to the client is not necessarily the optimal node. In distributed services, centralized scheduling is a more common scheduling method. Because the Http(s) domain name server cannot obtain the running status and node usage of each global service node, the simple centralized scheduling results in inaccurate domain name resolution.

Application content

An object of the present application is to provide a domain name resolution method, a client, an edge node, and a domain name resolution system, which solve the technical problem that the analysis result of the domain name is not accurate enough in the conventional technology.

In a first aspect, the embodiment of the present application provides a domain name resolution method, which is applied to a client, and the method includes: sending a first Http(s) domain name resolution request to a central domain name server, where the first Http(s) And receiving, by the central domain name server, a jump status code and a jump URL, where the domain name to be resolved is a distributed type, and the jump URL points to an edge node serving the area where the client is located; The jump status code sends a second Http(s) domain name resolution request to the edge node, so that the edge node parses the IP address corresponding to the to-be-resolved domain name according to the second Http(s) domain name resolution request. Receiving the IP address returned by the edge node.

In a second aspect, the embodiment of the present application provides a domain name parsing method, which is applied to an edge node. The method includes: receiving a second Http(s) domain name resolution request sent by the client; parsing an IP address corresponding to the domain name to be resolved according to the second Http(s) domain name resolution request, and returning the IP address.

In a third aspect, the embodiment of the present application provides a domain name resolution method, which is applied to a central domain name server, and the method includes: receiving a first Http(s) domain name resolution request sent by a client, the first Http(s) The domain name resolution request includes a domain name to be resolved; when the domain name to be resolved of the first Http(s) domain name resolution request belongs to a distributed type, returning a jump status code and a jump URL to the client, the jump URL Point to the edge node that serves the area where the client is located.

In a fourth aspect, an embodiment of the present application provides a domain name resolution apparatus, which is applied to a client. The domain name resolution device includes: a first sending module, configured to send a first Http(s) domain name resolution request to the central domain name server; and a first receiving module, configured to: in the first Http(s) domain name resolution request to be parsed When the domain name belongs to a distributed type, the jump status code and the jump URL returned by the central domain name server are received, and the jump URL points to an edge node serving the area where the client is located; and the second sending module is configured to The jump status code sends a second Http(s) domain name resolution request to the edge node, so that the edge node parses the IP corresponding to the to-be-resolved domain name according to the second Http(s) domain name resolution request. The second receiving module is configured to receive the IP address returned by the edge node.

In a fifth aspect, the embodiment of the present application provides a domain name resolution device, which is applied to an edge node, where the domain name resolution device includes: a third receiving module, configured to receive a second Http(s) domain name resolution request sent by the client; The parsing module is configured to parse an IP address corresponding to the domain name to be resolved according to the second Http(s) domain name resolution request, and return the IP address to the client.

In a sixth aspect, the embodiment of the present application provides a domain name resolution device, which is applied to a central domain name server, and the domain name resolution device includes: a fourth receiving module, configured to receive a first Http(s) domain name resolution request sent by a client The first Http(s) domain name resolution request includes a domain name to be resolved, and the first returning module is configured to: when the domain name to be resolved of the first Http(s) domain name resolution request belongs to a distributed type, to the client The terminal returns a jump status code and a jump URL, and the jump URL points to an edge node serving the area where the client is located.

The beneficial effect of the present application is that, when resolving a domain name, first, the client sends a first Http(s) domain name resolution request to the central domain name server, so that the central domain name server returns a jump URL according to the first Http(s) domain name resolution request. Jump status code, the first Http(s) domain name resolution request includes the domain name to be resolved. Again, the client sends the second Http(s) domain name to the edge node pointed to by the jump URL according to the jump status code. Parsing the request, so that the edge node parses the IP address corresponding to the domain to be resolved according to the second Http(s) domain name resolution request, and returns an IP address. Since the edge node knows the state of each content service node, the analysis result is more accurate, so it can recommend the optimal IP address for the client.

DRAWINGS

The one or more embodiments are exemplified by the accompanying drawings in the accompanying drawings, and FIG. The figures in the drawings do not constitute a scale limitation unless otherwise stated.

1 is a schematic structural diagram of a conventional domain name resolution according to an embodiment of the present application;

2 is a schematic diagram of another conventional domain name resolution architecture provided by an embodiment of the present application;

3 is a schematic structural diagram of a domain name resolution system according to an embodiment of the present application;

4 is a signaling diagram of a domain name resolution method according to an embodiment of the present application;

FIG. 5 is a signaling diagram of a method for parsing a domain name of an edge node according to an embodiment of the present application;

FIG. 6 is a schematic structural diagram of a client according to an embodiment of the present application;

FIG. 7 is a schematic structural diagram of a domain name resolution apparatus according to an embodiment of the present application;

FIG. 8 is a schematic structural diagram of a domain name resolution apparatus according to another embodiment of the present application;

FIG. 9 is a schematic structural diagram of a domain name resolution apparatus according to still another embodiment of the present application;

FIG. 10 is a schematic structural diagram of a domain name resolution apparatus according to still another embodiment of the present application;

FIG. 11 is a schematic flowchart diagram of a domain name resolution method according to an embodiment of the present application;

FIG. 12 is a schematic flowchart of a domain name resolution method according to another embodiment of the present application;

FIG. 13 is a schematic flowchart diagram of a domain name parsing method according to still another embodiment of the present application;

FIG. 14 is a schematic flowchart diagram of a method for analyzing a domain name according to still another embodiment of the present application;

Figure 15 is a schematic flow chart of step 82 in Figure 4;

FIG. 16 is a schematic flowchart diagram of a method for analyzing a domain name according to still another embodiment of the present application.

Detailed ways

In order to make the objects, technical solutions, and advantages of the present application more comprehensible, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It is understood that the specific embodiments described herein are merely illustrative of the application and are not intended to be limiting.

Domain Name is a specific one on the Internet consisting of a string of characters separated by "dot". The name of a computer or group of computers, for example, the domain name is www.ddd.com. In the Internet, an Internet Service Provider (ISP) can match a domain name to a corresponding IP address. For example, the IP address corresponding to the domain name www.ddd.com is 11.22.33.44.

The domain name is in a tree structure. The domain name server to the direct service DNS server (Domain Name Server) is divided into multiple levels. For example, www.heli.edu.cn is a domain name. The domain name is divided into four levels. It is the host name "www", the third-level domain name is "heli", the second-level domain name is "edu", and the top-level domain name is "cn".

Since most of the communication between Internet devices is based on the TCP/IP protocol (Transmission Control Protocol/Internet Protocol), the TCP/IP protocol completes the connection between the two parties based on the IP address. Therefore, when an Internet device communicates on the network, it can only recognize an IP address such as "196.168.31.21" but cannot recognize the domain name. Moreover, for the user, it is impossible to accurately remember the website with more than 10 IP addresses. Therefore, when the user visits the website, it is more to enter the domain name in the address bar of the browser to complete the acquisition of the desired content page. In the process of obtaining the desired content page, the DNS server can "translate" the domain name accessed by the user into a corresponding IP address, and then retrieve the desired content page from the IP address again.

A DNS server is a computer and network service naming system organized into a domain hierarchy for use in a TCP/IP network. The services it provides are used to translate host names and domain names into IP addresses. The DNS server includes an authoritative DNS and a non-authoritative DNS. The authoritative DNS has a mapping corresponding to the DNS request in the database. The non-authoritative DNS has no corresponding mapping, and the corresponding cache query result exists.

Please refer to FIG. 1. FIG. 1 is a schematic structural diagram of a conventional domain name resolution according to an embodiment of the present application. As shown in FIG. 1, the architecture 10 includes Guangdong Mobile User 11, Shanghai Telecom User 12, Guangdong Mobile LDNS13 (Local Operator Domain Name Service, Local DNS), Shanghai Telecom LDNS14, and Authoritative DNS 15.

The Guangdong mobile subscriber 11 can use the mobile terminal to send a domain name resolution request to the Guangdong Mobile LDNS 13, for example, the domain name resolution request includes the domain name www.dd.com.

The Shanghai Telecom subscriber 12 can use the mobile terminal to send a domain name resolution request to the Shanghai Telecom LDNS 14, for example, the domain name resolution request includes the domain name www.ff.com.

In general, both Guangdong Mobile LDNS13 and Shanghai Telecom LDNS14 cache corresponding domain name resolution results. When Guangdong Mobile LDNS13 or Shanghai Telecom LDNS14 receives a domain name resolution request, it retrieves the cache. Record, query whether the cache has a domain name resolution result. If cached, Guangdong Mobile LDNS13 or Shanghai Telecom LDNS14 directly returns the domain name resolution result to Guangdong Mobile User 11 or Shanghai Telecom User 12. If not cached, it initiates a DNS recursive resolution request to the authoritative DNS 15 to enable the authoritative DNS 15 to query the corresponding domain name resolution result, and will return the domain name resolution result to the Guangdong mobile user 11 or the Shanghai telecommunications user 12.

However, the traditional domain name resolution process has certain defects. For example, because the LDNS cache has domain name resolution results, it does not initiate a DNS recursive resolution request to the authoritative DNS. If the domain name is served through the http(s) protocol or other ports, User access will fail. For example: payment service, game connection to the connect server service through a designated port. Moreover, the operation and maintenance level of the LDNS is uneven, and there is a problem that the cache server fails and the user access is abnormal. Further, when the LDNS itself does not perform domain name recursive resolution, but forwards the domain name resolution request to the recursive DNS of other LDNS, it will cause the source IP of the domain name resolution request received by the authoritative DNS to become the IP of other LDNS. Eventually, user traffic is directed to the wrong I DC, and user access is slow.

Based on the shortcomings of LDNS domain name resolution, the traditional technology once again proposes to build a new domain name resolution architecture based on the Http(s) protocol. The Http(s) protocol is a secure hypertext transfer protocol, which is a protocol for secure information communication and can also be used in conjunction with the HTTP protocol. Please refer to FIG. 2. FIG. 2 is a schematic diagram of another conventional domain name resolution architecture according to an embodiment of the present application. As shown in FIG. 2, the traditional domain name resolution architecture 20 includes a user terminal 21 and an HTTP domain name server 22, wherein the Http(s) domain name server 22 supports domain name resolution of the Http(s) protocol.

The user terminal 21 initiates a domain name resolution request to the HTTP (S) domain name server, wherein the IP address of the user terminal 21 is 202.106.2.2. The Http(s) domain name server 22 finds the IP address corresponding to the domain name according to the domain name resolution request: 4.3.2.2.

As mentioned above, the Http(s) protocol is used for domain name resolution, which can avoid the problem of domain name hijacking and cross-network access caused by LocalDNS, solve the problem caused by the abnormal domain name resolution in the mobile Internet service, and the positioning is relatively accurate, and the analysis is relatively normal. .

However, as mentioned earlier, the node that the Http(s) domain name server returns to the client's IP is not necessarily the optimal node. In distributed services, centralized scheduling is a more common scheduling method. Because the Http(s) domain name server cannot obtain the running status and node usage of each global service node, the simple centralized scheduling results in inaccurate domain name resolution.

Please refer to FIG. 3 and FIG. 4 together. FIG. 3 is a schematic diagram of a domain name resolution system according to an embodiment of the present application. FIG. 4 is a signaling diagram of a domain name resolution method according to an embodiment of the present application. As shown in FIG. 3, the system 30 includes a client 31, a central domain name server 32, a mail server 33, and an edge node 34. The client 31 can communicate with the central domain name server 32, the mail server 33, the edge node 34, and the mail server 35, respectively, by wire or wirelessly. The wired transmission medium may be an optical fiber, a coaxial cable, a telephone line, a network cable, or the like, and the wireless mode may be a wireless personal area network (WPAN), a wireless local area network (WLAN), and a cellular network (Cellular Network), wherein the wireless individual The local area network includes, for example, infrared communication (IRDA), Bluetooth, ZigBee, and the wireless local area network includes, for example, the 802.11b standard, the 802.11a standard, and the 802.11g standard, and the cellular network includes, for example, GSM, CDMA, TD-SCDMA, WCDMA, and CDMA2000. .

In this embodiment, the central domain name server 32, the mail server 33, and the edge node 34 all support the resolution of the Http(s) domain name.

As shown in FIG. 4, the domain name resolution method includes:

Step 301: During communication, the client 31 sends a first Http(s) domain name resolution request to the central domain name server 32. The first Http(s) domain name resolution request includes a domain name to be resolved.

Step 302: The central domain name server 32 receives the first Http(S) domain name resolution request sent by the client, and determines whether the domain name service type of the domain name to be resolved belongs to a distributed type according to the source IP address of the client or the IP address in the parameter.

Step 303: If the domain name service type of the domain name to be resolved belongs to a non-distributed type, the central domain name server 32 returns the analysis result to the client 31 according to the first Http(s) domain name resolution request.

Step 304: The client 31 initiates an application content request to the corresponding server according to the analysis result. For example, the client 31 initiates a mailbox domain name resolution request to the central domain name server 32, and the central domain name server 32 parses out that the mailbox domain name resolution request belongs to a non-distributed type, that is, the mail application content requested by the client 31 is not distributedly stored in each Within the class application server, but stored in the proprietary mail server 33, the central domain name server 32 sends the parsing result to the client 31, so that the client 31 directly initiates the mail application content to the mail server 33 based on the parsing result.

Step 305: If the domain name service type of the domain name to be resolved belongs to a distributed type, the central domain name server 32 returns a jump status code and a jump URL (Uniform Resource Locator) to the client 31 according to the first Http(s) domain name resolution request.

Specifically, the central domain name server 32 dynamically generates a jump URL, and returns a jump status code to the client 31, and populates the jump URL into the Location field of the http(s) response, wherein the http(s) The response is a response of the central domain name server 32 in response to the first Http(s) domain name resolution request.

In this embodiment, the jump URL points to the edge node 34 serving the area where the client 31 is located, and the jump status code is used to instruct the client 31 to re-jump to the edge node 34 pointed to by the jump URL, the jump state. The code may include a status code such as 302 redirect, and the like. 302 redirection means that the response corresponding to the current request can be found on another URI, and the client should access that resource by means of GET.

Step 306: When the domain name service type of the domain name to be resolved belongs to a distributed type, and the client 31 receives the http(s) response returned by the central domain name server 32, the client 31 points to the jump URL according to the jump status code. The edge node 34 sends a second Http(s) domain name resolution request.

Step 307: The edge node 34 parses the IP address corresponding to the domain name to be resolved according to the second Http(s) domain name resolution request.

Step 308, the edge node 34 returns an IP address to the client 31.

Since the edge node 34 knows the state of each content service node, the analysis result is more accurate, and therefore, it can recommend an optimal IP address for the client.

Referring to FIG. 3, the edge node 34 includes an edge domain name server 341, an application server 342, and a scheduling server 343. The client 31 communicates with the edge domain name server 341 and the application server 342, respectively, by wire or wirelessly, and the dispatch server 343 communicates with the application server 342.

The edge name server 341 can provide the client with a channel to enter the network and communicate with other servers. Generally, the edge name server 341 is a group of servers that perform a single function, such as a firewall server, a cache server, a load balancing server, and the like.

In this embodiment, the edge domain name server 341 is located at the edge node and is capable of providing a server based on the Http(s) protocol domain name resolution function. The edge domain name server 341 communicates with the dispatch server 342, obtains an IP address by pushing or pulling, and returns the IP address to the client 31 in an HTTP response manner.

The application server 342 can provide the client 31 with a server that applies content services. When the application server 342 receives the resource query request sent by the scheduling server 342, the application server 342 queries the resource usage of the resource according to the resource query request, and feeds back the resource usage to the scheduling server 343, for example, the central processing unit (Central Processing) Unit, CPU), memory, bandwidth, number of connections, etc. Resource usage information.

The dispatch server 343 receives feedback of the resource usage of the application server 342, according to the settings The scheduling rule determines the IP address of the application server 342 that can provide the optimal service, and dynamically recommends to the edge domain name server 341, wherein the recommended manner may be active sending and/or passive sending.

In this embodiment, the edge domain name server 341 or the application server 342 or the scheduling server 343 may be a physical server or a logical server virtualized by multiple physical servers, or may be interconnected. A server group composed of servers, and each functional module associated with domain name resolution can be distributed on each server in the server group.

Please refer to FIG. 5. FIG. 5 is a signaling diagram of a method for parsing a domain name of an edge node according to an embodiment of the present application. As shown in FIG. 5, the domain name resolution method includes:

Step 501: When the client 31 receives the jump status code and the jump URL returned by the central domain name server 32, the client 31 sends the second Http(s) domain name resolution request to the edge domain name server 341 again.

Step 502: The edge domain name server 341 triggers the scheduling server 343 according to the second Http(s) domain name resolution request.

Step 503, the dispatch server 343 accesses the application server 342 to obtain the resource usage of the application server 342.

Step 504: Each application server 342 feeds back the respective resource usage status to the scheduling server 343. In the process, when the resources of the respective application servers 342 in the edge node 34 are unavailable, that is, the application server 342 belongs to the deactivated state, the scheduling server 343 feeds back the status of the application server 342 in the deactivated state to the edge. Domain Name Server 341. Then, the edge domain name server 341 accesses another preset edge node according to the second Http(s) domain name resolution request until accessing the preset edge node that can return the IP address to the client 31. The additional preset edge node is adjacent to the previous preset edge node.

Step 505: When resources of the application servers 342 in the edge node 34 are available, the scheduling server 343 determines an IP address of the application server 342 capable of providing an optimal service according to a preset scheduling rule.

Step 506: The scheduling server 343 returns the IP address corresponding to the domain name to be resolved to the edge domain name server 341.

Step 507: The edge domain name server 341 returns the IP address corresponding to the domain name to be resolved to the client 31.

Step 508: The client 31 sends a content service request to the application server 342 pointed to by the IP address.

Step 509: The corresponding application server 342 returns a corresponding content service to the client 31 according to the content service request.

In this embodiment, the edge domain name server 341 dynamically resolves the domain name and receives the optimal IP address fed back by the scheduling server 343, thereby recommending the optimal IP address for the client 31.

Based on the same inventive concept, referring to FIG. 6, the embodiment of the present application further provides a client. As shown in FIG. 6, the client 31 includes at least one processor 311 and a memory 312 communicatively coupled to the at least one processor 311; wherein the memory 312 stores a memory 312 that is executable by the at least one processor 311. An instruction executed by the at least one processor 311 to enable the at least one processor 311 to execute control logic for performing domain name resolution as described in various embodiments above.

In some embodiments, the edge domain name server 341 or the central domain name server 32 may adopt a hardware architecture as shown in FIG. 6 to complete the control logic of the corresponding domain name resolution, and details are not described herein again.

As another aspect of the embodiment of the present application, the embodiment of the present application provides a domain name resolution device, which is applied to a client. The domain name resolution device is a software system, which can be stored in the client 31 illustrated in FIG. 6. The domain name resolution device includes a plurality of instructions stored in a memory, the processor can access the memory, and invoke the instructions to execute to complete the domain name resolution device.

As shown in FIG. 7, the domain name resolution device 40 includes a first sending module 41, a first receiving module 42, a second sending module 43, and a second receiving module 44.

The first sending module 41 is configured to send a first Http(s) domain name resolution request to the central domain name server;

The first receiving module 42 is configured to receive a jump status code and a jump URL returned by the central domain name server when the domain to be resolved of the first Http(s) domain name resolution request belongs to a distributed type, and the jump URL points to serve the client. The edge node of the area;

The second sending module 43 is configured to send a second Http(s) domain name resolution request to the edge node according to the hop state code, so that the edge node parses the IP corresponding to the domain name to be resolved according to the second Http(s) domain name resolution request. Address and return the IP address.

The second receiving module 44 is configured to receive an IP address returned by the edge node.

Since the edge node knows the state of each content service node, the analysis result is more accurate, so it can recommend the optimal IP address for the client.

In some embodiments, as shown in FIG. 7, the domain name resolution apparatus 40 further includes: a jump module 45, wherein the jump module 45 is configured to belong to the non-distributed type of the domain name to be resolved in the first Http(s) domain name resolution request. Then, according to the Http(s) domain name resolution response returned by the central domain name server, jump to the corresponding server.

In some embodiments, as shown in FIG. 7, the domain name resolution device 40 further includes: a third sending module 46, configured to send a content service request to an edge node pointed by the IP address.

In some embodiments, the jump status code is a 302 redirected status code.

As another aspect of the embodiments of the present application, the embodiment of the present application provides a domain name resolution apparatus, which is applied to an edge node. Wherein, the domain name resolution device is a software system, which can be stored in the stated edge domain name server. The domain name resolution device includes a plurality of instructions stored in a memory, the processor can access the memory, and invoke the instructions to execute to complete the domain name resolution device.

As shown in FIG. 8, the domain name resolution device 50 includes a third receiving module 51 and a parsing module 52.

The third receiving module 51 is configured to receive a second Http(s) domain name resolution request sent by the client;

The parsing module 52 is configured to parse the IP address corresponding to the domain to be resolved according to the second Http(s) domain name resolution request, and return the IP address to the client.

In some embodiments, the edge node includes an edge domain name server, a scheduling server, and an application server. The parsing module 52 is configured to: the edge domain name server triggers the scheduling server to access the application server according to the second Http(s) domain name resolution request; and when the resource usage of the application server belongs to the available state, the scheduling server uses the resource usage of the application server and the pre- Set the scheduling rule to return the IP address corresponding to the domain name to be resolved to the edge domain name server; the edge domain name server returns the IP address to the client.

The manner in which the scheduling server returns the IP address corresponding to the domain name to be resolved includes active sending and/or passive sending.

In some embodiments, the parsing module 52 is further configured to: when the resource usage of the application server belongs to the deactivated state, the edge domain name server returns the IP address according to the second Http(s) domain name resolution request until the access to the client Another preset edge node.

As another aspect of the embodiment of the present application, the embodiment of the present application provides a domain name resolution device, which is applied to a central domain name server. The domain name resolution device is a software system that can be stored in the central name server that is described. The domain name resolution device includes a plurality of instructions stored in a memory, the processor can access the memory, and invoke the instructions to execute to complete the domain name resolution device.

As shown in FIG. 9, the domain name resolution device 60 includes a fourth receiving module 61 and a first returning module 62.

The fourth receiving module 61 is configured to receive a first Http(s) domain name resolution request sent by the client, where the first Http(s) domain name resolution request includes a domain name to be resolved.

The first returning module 62 is configured to return a jump status code and a jump URL to the client when the domain to be resolved of the first Http(s) domain name resolution request belongs to a distributed type, and the jump URL points to the area where the client is located. Edge node. The jump status code is the 302 redirected status code.

In some embodiments, as shown in FIG. 10, the domain name resolution device 60 further includes a second returning module 63, and the second returning module 63 is configured to: the domain name to be resolved in the first Http(s) domain name resolution request belongs to a non-distributed domain. When the type is returned, the Http(s) domain name resolution response is returned to the client, so that the client jumps to the corresponding server.

The device embodiment and the foregoing embodiments are based on the same concept, and the content of the device embodiment may refer to the foregoing embodiments, and the details are not described herein.

As another aspect of the embodiment of the present application, the embodiment of the present application provides a plurality of domain name resolution methods (refer to the domain name resolution method described in the following embodiments). The function of the domain name resolution method of the embodiment of the present application is performed by the software system of the domain name resolution device described above with reference to FIG. 7 or FIG. 8 or FIG. 9 and FIG. 10, which can also be executed by means of a hardware platform. For example, the domain name resolution method can be executed in an electronic device of a suitable type of processor having a computing capability, such as a single chip microcomputer, a digital signal processing (DSP), or the like.

The functions corresponding to the domain name resolution method of the following embodiments are stored in the form of instructions on the memory of the client or the edge domain name server or the central domain name server. When the functions corresponding to the domain name resolution methods of the following embodiments are to be executed, The processor of the client or the edge name server or the central domain name server accesses the memory, and retrieves and executes the corresponding instructions to implement the functions corresponding to the domain name resolution methods of the following embodiments.

The memory is a non-volatile computer readable storage medium and can be used for storing a non-volatile software program, a non-volatile computer executable program, and a module, such as the domain name resolution device 40 or the domain name resolution device 50 in the above embodiment. Or the program instruction/module corresponding to the domain name resolution device 60, or the step corresponding to the domain name resolution method of the following embodiment. The processor executes various functional applications and data processing of the domain name resolution device 40 or the domain name resolution device 50 or the domain name resolution device 60 by running non-volatile software programs, instructions, and modules stored in the memory, that is, implementing the above embodiments. The functions of the functions of the respective modules and units of the domain name resolution device 40 or the domain name resolution device 50 or the domain name resolution device 60, or the steps corresponding to the domain name resolution method of the following embodiment.

The memory may include a high speed random access memory, and may also include a non-volatile memory such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid state storage device. In some embodiments, the memory optionally includes a memory remotely located relative to the processor, the remote memory being connectable to the processor over a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The program instructions/modules are stored in the memory, and when executed by the one or more processors, perform a domain name resolution method in any of the above method embodiments, for example, performing FIG. 11 described in the following embodiments. The steps shown in Fig. 13 or Fig. 14 and Fig. 15 or Fig. 16 are shown.

In a first aspect, please refer to FIG. 11. FIG. 11 is a schematic flowchart diagram of a domain name resolution method according to an embodiment of the present application. As shown in FIG. 11, the domain name resolution method 70 includes:

Step 71: Send a first Http(s) domain name resolution request to the central domain name server, so that the central domain name server returns the jump status code and the hop when the to-be-resolved domain name of the first Http(s) domain name resolution request belongs to a distributed type. Transfer URL, the jump URL points to the edge node serving the client's area;

Step 72: Send a second Http(s) domain name resolution request to the edge node according to the jump status code, so that the edge node parses the IP address corresponding to the domain name to be resolved according to the second Http(s) domain name resolution request, and returns an IP address. .

In step 71, the jump status code may be a 302 redirected status code.

In some embodiments, as shown in FIG. 12, the domain name resolution method 70 further includes:

Step 73: When the domain name to be resolved of the first Http(s) domain name resolution request belongs to a non-distributed type, the Http(s) domain name resolution response returned by the central domain name server is redirected to the corresponding server.

In some embodiments, as shown in FIG. 13, the domain name resolution method 70 further includes:

Step 74: Send a content service request to an edge node pointed to by the IP address.

In a second aspect, please refer to FIG. 14. FIG. 14 is a schematic flowchart diagram of a domain name resolution method according to still another embodiment of the present application. As shown in FIG. 14, the domain name resolution method 80 includes:

Step 81: Receive a second Http(s) domain name resolution request sent by the client.

Step 82: Parse the IP address corresponding to the domain name to be resolved according to the second Http(s) domain name resolution request, and return the IP address to the client.

Since the edge node knows the state of each content service node, the analysis result is more accurate, therefore, It can recommend the best IP address for the client.

In some embodiments, the edge node includes an edge domain name server, a scheduling server, and an application server. As shown in Figure 15, step 82 includes:

Step 821: The edge domain name server triggers the scheduling server to access the application server according to the second Http(s) domain name resolution request.

Step 822: Determine whether the resource usage of the application server is in an available state.

Step 823: When the resource usage of the application server is in an available state, the scheduling server returns an IP address corresponding to the domain to be resolved to the edge domain name server according to the resource usage of the application server and the preset scheduling rule.

Step 823: The edge domain name server returns the IP address to the client.

Step 824: When the resource usage of the application server is in the deactivated state, the edge domain name server resolves the request according to the second Http(s) domain name until accessing another preset edge node that can return the IP address to the client.

In a third aspect, please refer to FIG. 16. FIG. 16 is a schematic flowchart diagram of a domain name resolution method according to still another embodiment of the present application. As shown in FIG. 16, the domain name resolution method 90 includes:

Step 91: Receive a first Http(s) domain name resolution request sent by the client, where the first Http(s) domain name resolution request includes the domain name to be resolved.

Step 92: Determine whether the domain name service type of the domain name to be resolved belongs to a distributed type.

Step 93: If the domain name service type of the domain name to be resolved belongs to a distributed type, return a jump status code and a jump URL to the client according to the first Http(s) domain name resolution request, and the jump URL points to the area where the client is located. Edge node

The jump status code is a 302 redirected status code.

Step 94: If the domain name service type of the domain name to be resolved belongs to a non-distributed type, return an Http(s) domain name resolution response to the client, so that the client jumps to the corresponding server.

The content of each method embodiment and the foregoing embodiments are based on the same concept, and the content of each method embodiment may refer to the foregoing embodiments, and details are not described herein.

As still another aspect of the embodiments of the present application, an embodiment of the present application provides a non-transitory computer readable storage medium, where the non-transitory computer readable storage medium stores computer executable instructions, The computer executable instructions are for causing an electronic device to perform the domain name resolution method of any of the above.

Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, and are not limited thereto; in the idea of the present application, the technical features in the above embodiments or different embodiments may also be combined. The steps may be carried out in any order, and there are many other variations of the various aspects of the present application as described above, which are not provided in the details for the sake of brevity; although the present application has been described in detail with reference to the foregoing embodiments, The skilled person should understand that the technical solutions described in the foregoing embodiments may be modified, or some of the technical features may be equivalently replaced; and the modifications or substitutions do not deviate from the embodiments of the present application. The scope of the technical solution.

Claims

A domain name resolution method is applied to a client, and is characterized by:

Sending a first Http(s) domain name resolution request to the central domain name server;

Receiving, by the central domain name server, a jump status code and a jump URL, where the to-be-resolved domain name of the first Http(s) domain name resolution request belongs to a distributed type, where the jump URL points to serve the client The edge node of the area where the end is located;

Sending a second Http(s) domain name resolution request to the edge node according to the jump state code, so that the edge node parses the corresponding domain name to be resolved according to the second Http(s) domain name resolution request. IP address;

Receiving the IP address returned by the edge node.
The method of claim 1 further comprising:

When the to-be-resolved domain name of the first Http(s) domain name resolution request belongs to a non-distributed type, the Http(s) domain name resolution response returned by the central domain name server is redirected to the corresponding server.
The method of claim 1 further comprising:

Sending a content service request to the edge node pointed to by the IP address.
The method according to any one of claims 1 to 3, wherein the jump status code is a 302 redirected status code.
A domain name resolution method is applied to an edge node, and includes:

Receiving a second Http(s) domain name resolution request sent by the client;

And parsing the IP address corresponding to the domain to be resolved according to the second Http(s) domain name resolution request, and returning the IP address to the client.
The method according to claim 5, wherein the edge node comprises an edge domain name server, a scheduling server, and an application server;

And parsing the IP address corresponding to the domain name to be resolved according to the second Http(s) domain name resolution request, and returning the IP address to the client, including:

The edge domain name server triggers the scheduling server to access the application server according to the second Http(s) domain name resolution request;

When the resource usage of the application server is in an available state, the scheduling server returns to the edge domain name server according to the resource usage of the application server and a preset scheduling rule. The IP address corresponding to the domain name to be resolved;

The edge domain name server returns the IP address to the client.
The method according to claim 6, wherein the manner in which the scheduling server returns the IP address corresponding to the domain name to be resolved includes active sending and/or passive sending.
The method according to claim 6, wherein the IP address corresponding to the domain name to be resolved is parsed according to the second Http(s) domain name resolution request, and the IP address is returned to the client, include:

When the resource usage of the application server is in a deactivated state, the edge domain name server according to the second Http(s) domain name resolution request until accessing another preset that can return the IP address to the client Edge node.
A domain name resolution method is applied to a central domain name server, and is characterized in that:

Receiving a first Http(s) domain name resolution request sent by the client, where the first Http(s) domain name resolution request includes a domain name to be resolved;

And when the to-be-resolved domain name of the first Http(s) domain name resolution request belongs to a distributed type, returning a jump status code and a jump URL to the client, where the jump URL points to serve the client The edge node of the region.
The method of claim 9 wherein the method further comprises:

When the to-be-resolved domain name of the first Http(s) domain name resolution request belongs to a non-distributed type, the Http(s) domain name resolution response is returned to the client, so that the client jumps to the corresponding server.
The method of claim 9, wherein the jump status code is a 302 redirected status code.
A domain name resolution device is applied to a client, and includes:

a first sending module, configured to send a first Http(s) domain name resolution request to the central domain name server;

a first receiving module, configured to receive a jump status code and a jump URL returned by the central domain name server when the to-be-resolved domain name of the first Http(s) domain name resolution request belongs to a distributed type, where the jump The URL points to an edge node serving the area where the client is located;

a second sending module, configured to send a second Http(s) domain name resolution request to the edge node according to the jump status code, so that the edge node parses out according to the second Http(s) domain name resolution request The IP address corresponding to the domain name to be resolved;

And a second receiving module, configured to receive the IP address returned by the edge node.
The device of claim 12, wherein the device further comprises:

a jump module, configured to: when the domain name to be resolved of the first Http(s) domain name resolution request belongs to a non-distributed type, according to the Http(s) domain name resolution response returned by the central domain name server, jump to the corresponding server.
The device of claim 12, wherein the device further comprises:

And a third sending module, configured to send a content service request to the edge node pointed by the IP address.
The apparatus according to any one of claims 12 to 14, wherein the jump status code is a 302 redirected status code.
A domain name resolution device is applied to an edge node, and includes:

a third receiving module, configured to receive a second Http(s) domain name resolution request sent by the client;

The parsing module is configured to parse an IP address corresponding to the domain name to be resolved according to the second Http(s) domain name resolution request, and return the IP address to the client.
The apparatus according to claim 16, wherein the edge node comprises an edge domain name server, a scheduling server, and an application server;

The parsing module is configured to: the edge domain name server triggers the scheduling server to access the application server according to the second Http(s) domain name resolution request; and when the resource usage of the application server belongs to an available state, the Returning, by the scheduling server, the IP address corresponding to the domain to be resolved to the edge domain name server according to the resource usage of the application server and the preset scheduling rule; the edge domain name server returns the IP address to the client .
The apparatus according to claim 17, wherein the manner in which the scheduling server returns an IP address corresponding to the domain name to be resolved includes active sending and/or passive sending.
The apparatus according to claim 17, wherein the parsing module is further configured to:

When the resource usage of the application server is in a deactivated state, the edge domain name server according to the second Http(s) domain name resolution request until accessing another preset that can return the IP address to the client Edge node.
A domain name resolution device is applied to a central domain name server, and includes:

a fourth receiving module, configured to receive a first Http(s) domain name resolution request sent by the client, where the first Http(s) domain name resolution request includes a domain name to be resolved;

a first returning module, configured to: when the domain name to be resolved of the first Http(s) domain name resolution request belongs to a distributed type, return a jump status code and a jump URL to the client, where the jump URL points Service An edge node in the area where the client is located.
The device of claim 20, wherein the device further comprises:

a second returning module, configured to: when the domain name to be resolved of the first Http(s) domain name resolution request belongs to a non-distributed type, return a response of the Http(s) domain name resolution request to the client, so that the client Jump to the corresponding server.
The apparatus of claim 20 wherein said jump status code is a 302 redirected status code.
A client, comprising:

At least one processor;

a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to cause the at least one processing The device can be used to perform the domain name resolution method according to any one of claims 1 to 4.
An edge node, comprising:

At least one processor;

a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to cause the at least one processing The device can be used to perform the domain name resolution method according to any one of claims 5 to 8.
A central domain name server, characterized by comprising:

At least one processor;

a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to cause the at least one processing The device can be used to perform the domain name resolution method according to any one of claims 9 to 11.
A domain name resolution system, comprising:

The client of claim 23;

The edge node of claim 24, communicating with the client;

The central domain name server of claim 25 in communication with said client.