CN116319676B

CN116319676B - Domain name resolution method, device, storage medium and system

Info

Publication number: CN116319676B
Application number: CN202310589563.8A
Authority: CN
Inventors: 张晓军; 刘志辉
Original assignee: Alibaba Cloud Computing Ltd
Current assignee: Alibaba Cloud Computing Ltd
Priority date: 2023-05-23
Filing date: 2023-05-23
Publication date: 2023-10-20
Anticipated expiration: 2043-05-23
Also published as: CN116319676A

Abstract

The application provides a domain name resolution method, device, storage medium and system, wherein the method comprises the following steps: responding to an analysis request of a target domain name of an application provider by a client, if a first domain name server corresponding to the target domain name is determined to be faulty, sending the analysis request to a second domain name server corresponding to the target domain name, receiving an IP address of the target application server determined by the second domain name server in at least one group of IP addresses corresponding to the target domain name, and feeding back the IP address of the target application server to the client. The first domain name server is private to the application provider, the second domain name server is located in a public cloud, and domain name resolution service software in the first domain name server and the second domain name server are different. The heterogeneous second domain name server on the public cloud can be used as a disaster recovery alternative when the first domain name server fails, so that the reliability of domain name resolution service is ensured.

Description

Domain name resolution method, device, storage medium and system

Technical Field

The present application relates to the field of internet technologies, and in particular, to a domain name resolution method, device, storage medium, and system.

Background

When a client accesses an application, the domain name system (Domain Name System, DNS for short) first needs to query the IP address of an application server corresponding to the domain name of the application, and after the domain name resolution process is completed, accesses the application server based on the obtained IP address of the application server.

In some implementations, an enterprise may deploy one or more domain name servers locally to schedule ingress traffic for an application provided by the enterprise. For example, the enterprise registers a domain name of an application, and sets IP addresses of a plurality of application servers corresponding to the domain name, so as to provide the application for users to access through the application servers. The domain name resolution request triggered by the client side to the application is received by the domain name server and the resolution processing of the domain name to the IP address of the application server is completed. If the enterprise private domain name server is abnormal, for example, the domain name servers are all failed due to the influence of malformed packages, the stability and reliability of the domain name resolution capability cannot be ensured.

Disclosure of Invention

The embodiment of the invention provides a domain name resolution method, device, storage medium and system, which are used for ensuring the reliability of domain name resolution capability.

In a first aspect, an embodiment of the present invention provides a domain name resolution method, where the method includes:

responding to an analysis request of a target domain name of an application provider by a client, if a first domain name server corresponding to the target domain name is determined to be faulty, sending the analysis request to a second domain name server corresponding to the target domain name, wherein the first domain name server is a domain name server private to the application provider, the second domain name server is located in public cloud, and first domain name analysis service software in the first domain name server is different from second domain name analysis service software in the second domain name server;

receiving an IP address of a target application server determined by the second domain name server in at least one group of IP addresses corresponding to the target domain name, wherein each group of IP addresses comprises the IP address of at least one application server corresponding to the target domain name;

and feeding back the IP address of the target application server to the client so that the client accesses the target application server.

In a second aspect, an embodiment of the present invention provides a domain name resolution apparatus, including:

the system comprises a determining module, a judging module and a judging module, wherein the determining module is used for responding to an analysis request of a target domain name of an application provider of a client, if a first domain name server corresponding to the target domain name is determined to be faulty, the analysis request is sent to a second domain name server corresponding to the target domain name, the first domain name server is a domain name server private to the application provider, the second domain name server is located in public cloud, and first domain name analysis service software in the first domain name server is different from second domain name analysis service software in the second domain name server;

The receiving module is used for receiving the IP address of the target application server determined by the second domain name server in at least one group of IP addresses corresponding to the target domain name, wherein each group of IP addresses comprises the IP address of at least one application server corresponding to the target domain name;

and the sending module is used for feeding back the IP address of the target application server to the client so that the client accesses the target application server.

In a third aspect, an embodiment of the present invention provides an electronic device, including: a memory, a processor, a communication interface; wherein the memory has executable code stored thereon which, when executed by the processor, causes the processor to perform the domain name resolution method of the first aspect.

In a fourth aspect, embodiments of the present invention provide a non-transitory machine-readable storage medium having executable code stored thereon, which when executed by a processor of an electronic device, causes the processor to at least implement a domain name resolution method as described in the first aspect.

In a fifth aspect, an embodiment of the present invention provides a domain name resolution system, including:

A first domain name server and a second domain name server corresponding to a target domain name of an application provider, and a third domain name server serving as a traffic inlet of the first domain name server and the second domain name server; the first domain name server is a domain name server private to the application provider, the second domain name server is located in public cloud, and first domain name resolution service software in the first domain name server is different from second domain name resolution service software in the second domain name server;

the third domain name server is configured to perform the domain name resolution method according to the first aspect.

In the embodiment of the invention, for an application provided by an application provider (such as an enterprise), two sets of domain name servers may be provided, one is a first domain name server private to the application provider, and the other is a second domain name server located in public cloud, where the first domain name resolution service software provided in the first domain name server is different from the second domain name resolution service software provided in the second domain name server, that is, heterogeneous, such as different adopted programming languages, protocol stacks, development architecture, and the like. However, the first domain name resolution service software and the second domain name resolution service software provide the same domain name resolution function and have the same configuration data associated with the domain name resolution function.

And when the third domain name server serving as a traffic inlet of the first domain name server and the second domain name server receives the resolution request of the client for the target domain name of the application provider, if the first domain name server corresponding to the target domain name is determined to be faulty, the resolution request is sent to the second domain name server corresponding to the target domain name. The second domain name server determines the IP address of the target application server in at least one group of IP addresses corresponding to the target domain name and feeds the IP address back to the third domain name server. And the third domain name server feeds back the IP address of the target application server to the client so that the client accesses the target application server.

Because the domain name resolution service software in the first domain name server and the second domain name server is heterogeneous, and the second domain name server is located in public cloud, stable service quality can be obtained based on rich and elastic computing power resources of the public cloud, so that when the first domain name server is influenced by malformed packets and the service is down, the heterogeneous second domain name server cannot be influenced by the malformed packets, and the heterogeneous second domain name server is switched to the public cloud to provide domain name resolution service, so that the reliability and stability of the domain name resolution service can be ensured.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for the description of the embodiments will be briefly described below, and it is obvious that the drawings in the following description are some embodiments of the present invention, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

Fig. 1 is a schematic diagram of a domain name resolution system according to an embodiment of the present invention;

FIG. 2 is a schematic diagram of functional alignment of two sets of domain name servers according to an embodiment of the present invention;

FIG. 3 is a schematic diagram of configuration data consistency provided by an embodiment of the present invention;

fig. 4 is a schematic diagram of application server health status detection according to an embodiment of the present invention;

FIG. 5 is a flow chart of a domain name resolution method according to an embodiment of the present invention;

fig. 6a and fig. 6b are schematic diagrams illustrating a domain name resolution process in a primary and backup disaster recovery service mode according to an embodiment of the present invention;

FIG. 7 is a flowchart of a domain name resolution method according to an embodiment of the present invention;

fig. 8a and fig. 8b are schematic diagrams illustrating a domain name resolution process in a cloud load service mode according to an embodiment of the present invention;

Fig. 9 is a schematic structural diagram of a domain name resolution device according to an embodiment of the present invention;

fig. 10 is a schematic structural diagram of an electronic device according to the present embodiment.

Detailed Description

For the purpose of making the objects, technical solutions and advantages of the embodiments of the present invention more apparent, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention, and it is apparent that the described embodiments are some embodiments of the present invention, but not all embodiments of the present invention. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention. In addition, the sequence of steps in the method embodiments described below is only an example and is not strictly limited.

It should be noted that, the user information (including but not limited to user equipment information, user personal information, etc.) and the data (including but not limited to data for analysis, stored data, presented data, etc.) related to the embodiments of the present invention are information and data authorized by the user or fully authorized by each party, and the collection, use and processing of the related data need to comply with the related laws and regulations and standards of the related country and region, and provide corresponding operation entries for the user to select authorization or rejection.

Global traffic management (Global Traffic Manage, GTM for short): the load scheduling strategy based on the DNS is used for scheduling the application server when the analysis request of the application domain name triggered by the client is received, for example, the request of the client is scheduled to an effective application server nearby according to the source address of the client, the state of the application server and the set load scheduling strategy.

Isomorphic domain name resolution service software: meaning that multiple domain name resolution service software are identical, equivalent to multiple copies of the same software. If a certain enterprise user deploys a plurality of domain name servers to form a high-availability cluster, domain name resolution service software deployed in each domain name server in the cluster is isomorphic, and if a data packet corresponding to a domain name resolution request is a malformed packet, the malformed packet causes one set of software to fail, and because the software is of the same architecture, all domain name servers in the cluster finally fail; or the cluster is subject to DDoS (Distributed Denial of Service ) attacks, resulting in failure of the domain name server to provide domain name resolution services normally.

Heterogeneous domain name resolution service software: it is meant that the plurality of domain name resolution services are software products of different architecture, such as programming language, development architecture, protocol stack used, etc., are different.

Domain name resolution service software: simply software that performs the function of resolving the application domain name to the IP address of the application server. In the embodiment of the present invention, optionally, the GTM function may be provided in the domain name resolution service software, that is, the scheduling of the application server and the domain name resolution function are completed based on the set load scheduling policy, so it can be seen that the underlying basis of the GTM function is the domain name resolution function, and the GTM function may be considered to integrate the domain name resolution function. Of course, the scheduling mechanism adopted in the domain name resolution service software may be other scheduling mechanisms different from the GTM, which is not limited in the embodiment of the present invention.

Deformity package: in the embodiment of the invention, the domain name resolution request triggered by the client is organized into a data packet, the data packet comprises a packet header and a packet body (or load), and if the two parts are missing and a complete and correct data packet cannot be formed, the obtained data packet can be regarded as a malformed packet. When a domain name server running a certain domain name resolution service software receives the malformed packet, the domain name server cannot complete normal domain name resolution processing, so that the domain name server is in fault and service is down. Such as the malformed package, may cause domain name resolution service software in a programming language to fail.

Assuming that an enterprise provides an application, in order to provide access to a wide range of users, the enterprise needs to register a domain name of the application and an IP address of a locally set domain name server providing domain name resolution service in a domain name management system, and configure a correspondence between the domain name and the IP address of an application server of the application in the domain name server. To provide high availability of applications, the IP addresses of multiple application servers are typically increased. Similarly, in order to provide high availability of domain name resolution services, it is also possible to set up a domain name server cluster locally. The domain name management system comprises a root domain name server and domain name servers of all levels.

GTM has become an important means for supporting high-availability disaster recovery scheduling between different data centers or different regions based on DNS, and many enterprises provide domain name resolution scheduling service oriented to Internet through locally deployed self-built GTM systems. The self-built GTM system comprises at least one domain name server with a GTM function, and the domain name servers often adopt isomorphic domain name resolution service software, so that when facing the malformed packet request and the DDOS attack, the self-built GTM system cannot guarantee the persistence of domain name resolution scheduling service, and even can cause service downtime to influence the reliable service of the application.

Therefore, in the embodiment of the invention, a domain name resolution scheduling scheme is provided by combining an enterprise self-built GTM system and a heterogeneous public cloud GTM system, the scheme aims at solving the problem that a malformed packet request and a DDOS attack can damage domain name resolution service in a scene of providing domain name resolution scheduling service for an end user, and can provide high availability and continuous service of GTM scheduling by switching the public cloud GTM system and the enterprise self-built GTM system, and supports seamless switching of the public cloud GTM system and the enterprise self-built GTM system, and the domain name resolution scheduling effect is consistent.

Since at least one domain name server supporting the GTM service is included in the GTM system, only the concept of the domain name server will be described hereinafter.

An application provider (such as an enterprise) can set another set of domain name servers in public cloud aiming at the domain name of an application, domain name resolution service software in the set of domain name servers is heterogeneous with domain name resolution service software in the domain name servers private to the application provider, and the two sets of domain name servers private to the application provider and public cloud can provide disaster-tolerant domain name resolution service for the application servers so as to ensure reliable and stable access of the application.

Fig. 1 is a schematic diagram of a domain name resolution system according to an embodiment of the present invention, as shown in fig. 1, where the domain name resolution system includes: the application provider comprises a first domain name server and a second domain name server corresponding to target domain names of the application provider, and a third domain name server serving as traffic portals of the first domain name server and the second domain name server.

The first domain name server is a domain name server private to the application provider, the second domain name server is located in public cloud, and first domain name resolution service software in the first domain name server is different from second domain name resolution service software in the second domain name server so as to be heterogeneous.

In fact, as shown in fig. 1, when a certain client triggers a domain name resolution request for the target domain name, if there is no cache record corresponding to the target domain name in the browser and the operating system local to the client, the domain name resolution request is sent to a "local domain name server (localDNS)" of the client, that is, the third domain name server.

The third domain name server is a default domain name server when the client performs domain name resolution, and there are common local domain name servers of various network operators.

The first domain name server may be any one of local clusters formed by one or more domain name servers built locally by an application provider, or may be any one of domain name server clusters built on a private cloud. The second domain name server may be located in a cluster of domain name servers built on a public cloud. Only the domain name resolution service software running in the first domain name server and the second domain name server is heterogeneous.

It can be appreciated that the domain name server cluster built on the public cloud or the private cloud can provide the same virtual IP address externally, so that the third domain name server accessing the cluster does not sense the existence of each domain name server in the cluster.

To ensure consistent scheduling results, whether based on the second domain name server or the first domain name server, the first domain name resolution service software and the second domain name resolution service software provide the same domain name resolution function and have the same configuration data associated with the domain name resolution function. In general terms, the domain name resolution function includes, for example, the following sub-functions: load scheduling policies, probing protocols and probing policies, setting policies for IP address groups, etc. The configuration data includes parameters involved in the respective functions described above, the IP address of the application server included in each IP address group, and the like.

The IP address group refers to an application corresponding to a target domain name by an application provider, may set IP addresses of a plurality of application servers, and may group the IP addresses of the application servers according to one or more setting policies. Different packets may contain IP addresses of the same application server.

For example, as shown in fig. 1, assuming that the packets are grouped according to two policies of a deployment area of an application server and a network type accessed by the application server, there may be provided an IP address group 1 corresponding to a first network type, an IP address group 2 corresponding to a second network type, an IP address group 3 corresponding to the first deployment area, and an IP address group 4 corresponding to the second deployment area. When an application server accesses a network of a first network type and is located in a second deployment area, the IP address of the application server is contained in both the IP address group 1 corresponding to the first network type and the IP address group 4 corresponding to the second deployment area.

The load scheduling policy described above generally describes how to select a set of IP addresses and select an IP address of a target application server within the selected set of IP addresses for responding to a domain name resolution request. When a weight-based, sequential scheduling policy is involved in the scheduling policy, the corresponding scheduling parameters include, for example, a weight setting parameter, a sequence number, and the like. The load scheduling policy is not an important point in the embodiment of the present invention, and will not be described in detail.

The detection protocol and the detection policy are used for detecting the health status of the application server in each IP address group. The corresponding probing parameters include, for example, probing time interval, probing protocol type, etc.

In practice, based on the application of the application provider, the cloud vendor may configure, in its public cloud resources, a plurality of domain name servers for the application provider, where the domain name resolution service software run by the plurality of domain name servers is heterogeneous, and the second domain name server is any one of them. Assuming that a cloud vendor can provide three heterogeneous domain name resolution service software, namely domain name resolution service software a, domain name resolution service software B and domain name resolution service software C, one of the three heterogeneous domain name resolution service software, namely domain name resolution service software a, can be provided for an application provider, so that the application provider can be deployed in a first local domain name server of the application provider, and the application provider can deploy domain name resolution service software B and domain name resolution service software C in a plurality of domain name servers corresponding to a public cloud. For the application provider, although multiple heterogeneous domain name servers can be built locally, the deployment cost is high, such as purchasing machines, performing relevant configuration, networking and other processes, and subsequent maintenance is required. But for application providers, heterogeneous domain name servers are deployed in public clouds at lower cost.

Based on the deployment of the first domain name server, the second domain name server, and the third domain name server, in practical application, the domain name resolution flow may be as follows:

and the third domain name server receives an analysis request triggered by the target domain name of the application provider of the client, and if the first domain name server corresponding to the target domain name is determined to be faulty, the analysis request is sent to the second domain name server corresponding to the target domain name. And the second domain name server feeds back the IP address of the target application server to the third domain name server according to the IP address of the target application server determined in at least one group of IP addresses corresponding to the target domain name. And the third domain name server feeds back the IP address of the target application server to the client so that the client accesses the target application server.

In fact, when the third domain name server receives the resolution request, it will first inquire whether the local cache stores the cache record corresponding to the target domain name, if yes, the forwarding of the resolution request is performed according to the cache record, if not, the domain name management system is inquired to determine the IP address of the domain name server corresponding to the target domain name, forwarding is performed according to the inquiry result, and the inquiry result is stored in the cache.

In this embodiment, it is assumed that after the third domain name server previously sends a resolution request to the first domain name server, the first domain name server is determined to be faulty based on the response information of the first domain name server, or after the resolution request received this time is sent to the first domain name server, the first domain name server is determined to be faulty based on the response information of the first domain name server, and then the resolution request received this time is switched to the second domain name server sent to the public cloud.

And determining a first domain name server fault, such as receiving an instruction indicating service downtime fed back by the first domain name server, or determining that the response time exceeds a set threshold according to the response information of the first domain name server.

And after the second domain name server receives the resolution request, determining the IP address of the target application server from the at least one group of locally configured IP addresses based on the local second domain name resolution service software.

Because the domain name resolution service software in the first domain name server and the second domain name server is heterogeneous, and the second domain name server is located in public cloud, stable service quality can be obtained based on rich and elastic computing power resources of the public cloud, so that when the first domain name server is influenced by malformed packets and the service is down, the heterogeneous second domain name server cannot be influenced by the malformed packets, and the heterogeneous second domain name server is switched to the public cloud to provide domain name resolution service, so that the reliability and stability of the domain name resolution service can be ensured. In addition, the first domain name resolution service software and the second domain name resolution service software provide the same domain name resolution function and have the same configuration data related to the domain name resolution function, so that a user cannot perceive the switching, and a consistent dispatching effect before and after the switching can be obtained.

As described above, the first domain name server and the second domain name server are to provide the same domain name resolution function and have the same configuration data associated with the domain name resolution function.

First, the first domain name server and the second domain name server provide the same domain name resolution function, that is, the first domain name server and the second domain name server are configured in a consistent manner, so that the domain name resolution functions (such as a load dispatching strategy, an IP address group setting strategy, a probing protocol, a probing strategy and the like) on private and public clouds of an application provider are guaranteed to be completely consistent.

In practical applications, the domain name resolution service software locally deployed by the application provider may be provided by a cloud vendor, where the cloud vendor provides multiple heterogeneous domain name resolution service software in a public cloud, so as shown in fig. 2, a statistical function scheduling node may be set in the public cloud (where the node may be set in a control device below or may be set independently), and for the application provider, different domain name resolution service software is deployed in at least one cloud server of the public cloud as at least one domain name server corresponding to the application provider in the public cloud, for example, in fig. 2, domain name resolution service software a, domain name resolution service software B and domain name resolution service software C are respectively issued to different cloud servers, so as to form three domain name servers corresponding to the application provider in the public cloud. In addition, one of the three types can be sent to the application provider for deployment in the local first domain name server.

It will be appreciated that the heterogeneous domain name resolution service software described above, although implemented differently, provides the same functionality.

Secondly, the second domain name server of the public cloud and the first domain name server private to the application provider are uniformly managed, and consistency of configuration data at two ends is guaranteed. Since the first domain name server and the second domain name server are actually two independent systems, other operations may be performed in addition to performing the domain name resolution function, and to avoid blocking other operations, a unified control device may be provided in which an asynchronous task manager is established to asynchronously perform alignment processing of configuration data of the first domain name server and the second domain name server. In addition, a reconciliation mechanism of the configuration data at the two ends is also provided to ensure the consistency of the configuration data at the two ends. As described above, the domain name resolution service software provides a plurality of specific functions, each function has related configuration data, such as configuration data related to a policy of resolving a domain name to an IP address group, configuration data related to resolving a domain name to an IP address of an application server in the IP address group (such as polling, a weight-based load balancing policy, etc.), configuration data related to health detection of the application server (such as detection period, an index for evaluating health status, a weight of each index, etc.), and all configuration data at both ends need to be compared to ensure consistency of all configuration data. A correction reference object, such as configuration data of public cloud, may be set as the correction reference object, and if the configuration data of the first domain name server local to the application provider is inconsistent with the configuration data of the second domain name server of public Yun Di, unified updating is performed based on the public cloud. As shown in fig. 3, the control device, upon receiving the above configuration data provided by the application provider for the target domain name, issues to the first domain name server and the second domain name server to maintain consistency of both.

In addition to ensuring the consistency of the functions and the consistency of the configuration data of the public Yun Di two domain name servers and the first domain name server private to the application provider, in order to better ensure that the domain name servers at the two ends can obtain the consistency scheduling effect, a mechanism for summarizing the health detection results of the two ends to each application server is provided.

As shown in fig. 4, the above-mentioned control device, and a first detector and a second detector coupled to the control device may also be included in the domain name resolution system; the first detector is located at the side of the first domain name server, and the second detector is located at the side of the second domain name server. The second detector is located on the public cloud side, and the first detector is located on the private cloud side where the first domain name server is located or local to the application provider.

The first detector is used for detecting first health state information of each application server contained in at least one group of IP addresses corresponding to the target domain name, and sending the first health state information to the control equipment. Similarly, the second detector is configured to detect second health status information of each application server included in the at least one set of IP addresses, and send the second health status information to the control device. The control device correspondingly determines target health state information of each application server according to the first health state information and the second health state information of each application server, and sends the target health state information of each application server to the first domain name server and the second domain name server.

As described above, both ends have the same probing strategy, e.g. the probing period is 1 minute. The probe objects are application servers included in the IP address groups.

The control device synchronizes the finally determined target health status information of each application server to the first domain name server and the second domain name server, so that the sensing results of the first domain name server and the second domain name server for the health status of the same application server are consistent, and the load scheduling strategies executed based on the first domain name server and the second domain name server are consistent, so that whether the first domain name server or the second domain name server is consistent for the same resolution request, the finally fed back target application server is consistent, the same scheduling effect is obtained, and the difference of the services provided by the first domain name server or the second domain name server is not obviously sensed for the client.

Aiming at the first health state information and the second health state information detected by the first detector and the second detector at the same time aiming at a certain application server, the control equipment gathers corresponding target health state information. Summarization may be achieved, for example, by:

One or more indicators for assessing health status are preset, each indicator may have the same or different weights, and thresholds for distinguishing health from unhealthy are set. The detectors at the two ends respectively detect the values of the indexes of the application server, and the control equipment performs weighted summation on a plurality of index values detected by the first detector according to the weight of each index to obtain a first health score; carrying out weighted summation on the plurality of index values detected by the second detector to obtain a second health score; the application server is indicated to be healthy if both the first health score and the second health score are greater than the threshold, and unhealthy if at least one of the first health score and the second health score is less than the threshold.

The above summary is merely exemplary, and is not limited thereto.

Assuming that the control device determines that a certain application server is unhealthy, and notifies the first domain name server and the second domain name server of the determination result, it can be understood that the IP address of the application server is not resolved as a response to the resolution request regardless of whether the current resolution request is sent to the first domain name server or the second domain name server.

In sum, the first domain name server private to the application provider and the second domain name server of the public cloud are subjected to function alignment and configuration data unified management, and data consistency at two ends is ensured through the control equipment of the public cloud. And carrying out data fusion on the health state information detected by each application server by using the detectors at the two ends, carrying out overall calculation, and scheduling the application servers by using the domain name servers at the two ends based on the overall calculation result, so as to ensure the consistency of a scheduling triggering mechanism. The second domain name server of the public cloud provides heterogeneous disaster recovery for the first domain name server of the local application provider, and when the first domain name server of the local application provider is down or suffers DDOS attack, the domain name resolution request is switched to the second domain name server of the public cloud, so that seamless switching is realized.

In the embodiment of the invention, the application provider can have two different use scenes for using the second domain name server of the public cloud, namely a main disaster recovery service mode and a standby disaster recovery service mode, and a cloud load service mode.

In the primary and backup disaster recovery service mode, a first domain name server private by an application provider is used as a primary domain name server; the second domain name server is used as a standby domain name server when the first domain name server fails, and is switched back to the first domain name server when the first domain name server returns to normal.

In the cloud service mode, the first domain name server and the second domain name server provide domain name resolution service together, when the first domain name server fails, the second domain name server provides service, and after the first domain name server returns to normal, the first domain name server and the second domain name server provide domain name resolution service together.

The implementation process of the domain name resolution method provided by the embodiment of the invention is illustrated based on the two application scenarios.

Fig. 5 is a flowchart of a domain name resolution method according to an embodiment of the present invention, where the method may be performed by the third domain name server, as shown in fig. 5, and the method includes the following steps:

501. responding to the resolution request of the client for the target domain name of the application provider, and if the IP address of the domain name server corresponding to the target domain name is queried from a local cache or a domain name management system and comprises the IP address of the first domain name server and the IP address of the second domain name server, determining a first response delay parameter value corresponding to the first domain name server and a second response delay parameter value corresponding to the second domain name server.

502. And if the first response delay parameter value is smaller than the second response delay parameter value, sending the resolution request to the first domain name server.

503. If the first domain name server is determined to be faulty according to the response information of the first domain name server, updating the response delay parameter value corresponding to the first domain name server in a punishment setting mode to obtain a third response delay parameter value, wherein the third response delay parameter value is larger than the second response delay parameter value.

504. And sending the resolution request to a second domain name server according to the third response delay parameter value and the second response delay parameter value.

505. And receiving the IP address of the target application server determined by the second domain name server in at least one group of IP addresses corresponding to the target domain name, and feeding back the IP address of the target application server to the client.

The execution process of the third domain name server in this embodiment may correspond to the above-mentioned primary and backup disaster recovery service modes. In fact, in the primary and backup disaster recovery service modes and the cloud load service mode, the execution process of the third domain name server is essentially the same.

Firstly, it should be noted that whether the second domain name server works in the active-standby disaster recovery service mode or in the cloud load service mode is set autonomously by the application provider.

Specifically, if the second domain name server is intended to operate in the active-standby disaster recovery service mode, for the target domain name, the IP address of the first domain name server and the IP address of the second domain name server are registered in the domain name management system in advance, that is, the correspondence between the IP address of the first domain name server and the IP address of the second domain name server and the target domain name is registered.

In practical application, since the first domain name server is a device owned by the application provider, optionally, the application provider may perform a registration operation of the domain name server on the first domain name server. Based on the trigger of the application provider, a service mode configuration interface including options of a primary and a backup disaster recovery service mode can be displayed on the first domain name server. In response to selection of the primary and backup disaster recovery service modes, the first domain name server may output prompt information prompting registration of the IP address of the first domain name server and correspondence of the IP address of the first domain name server with the target domain name in the domain name management system, and the application provider registers the IP address of the first domain name server and correspondence of the IP address of the first domain name server with the target domain name in the domain name management system according to the prompt information.

In addition, based on the selection of the primary and standby disaster recovery service modes by the user, the first domain name server also informs the second domain name server to work in the primary and standby disaster recovery service modes. Based on the notification, if the second domain name server receives the resolution request sent by the third domain name server before receiving the start notification sent by the first domain name server, the second domain name server feeds back a response failure notification (such as a servfail notification) to the third domain name server, that is, the second domain name server sets its domain name resolution service to a disabled state based on the notification.

And if the third domain name server receives an analysis request containing the target domain name sent by a certain client and determines that the cache record corresponding to the target domain name is not stored in the local cache, querying a domain name management system to obtain the IP address of the domain name server corresponding to the target domain name. Based on the registration result, determining that the IP address of the domain name server corresponding to the target domain name is the IP address of the first domain name server and the IP address of the second domain name server, and storing the corresponding relation between the IP address of the first domain name server and the target domain name and the corresponding relation between the IP address of the second domain name server and the target domain name into a local cache. The life cycle of the two cache records is set to be long, such as 24 hours. Thus, when the subsequent third domain name server receives the resolution request containing the target domain name, the IP address of the first domain name server and the IP address of the second domain name server corresponding to the target domain name can be known based on the caching result.

After determining the IP addresses of the two domain name servers, if it is determined that the first domain name server has not failed, the third domain name server needs to determine whether to send the received resolution request to the first domain name server or the second domain name server. Specifically, the third domain name server determines which domain name server of the above resolution request is transmitted to, based on the response delay parameter values corresponding to each of the first domain name server and the second domain name server.

In the initial case, after the first domain name server and the second domain name server are added to the cache, the third domain name server may initialize the response delay parameter values corresponding to the first domain name server and the second domain name server, store the response delay parameter values in the local cache correspondingly, and send the resolution request to the domain name server with smaller response delay parameter values according to the comparison result of the response delay parameter values corresponding to the first domain name server and the second domain name server.

After initialization, the third domain name server is assumed to receive an analysis request corresponding to the target domain name, and after the first domain name server and the second domain name server are obtained by inquiring from a local cache or a domain name management system, a first response delay parameter value corresponding to the first domain name server and a second response delay parameter value corresponding to the second domain name server are determined.

In the first case, the resolution request is sent to the first domain name server assuming that the first response delay parameter value is smaller than the second response delay parameter value at this time.

In practical application, after the third domain name server sends the resolution request to the first domain name server, the updated response delay parameter value of the current first domain name server may be determined according to the response information of the first domain name server. The response information may be divided into the following three cases: firstly, normal response information which is lower than the set response time length comprises an IP address of an application server determined by a first domain name server from at least one group of IP addresses corresponding to a target domain name; second, the response information is higher than the response time length, and the response information comprises the IP address of an application server determined by the first domain name server from at least one group of IP addresses corresponding to the target domain name; thirdly, an instruction indicating that the first domain name server is down is received.

Wherein, the second and third cases are regarded as first domain name server faults. Such a response situation may occur if, for example, the first domain name server is subject to a DDOS attack: after sending the resolution request to the first domain name server, the response information can not be received until a long time. The first domain name server may fail in a third scenario when it encounters a malformed package request.

The response delay parameter value may be determined according to a response delay indicator, where if normal response information is received, the response delay parameter value of the current first domain name server is determined according to a corresponding actual response delay indicator; if the first domain name server is determined to be faulty, the response delay parameter value of the current first domain name server is determined according to the set punishment mode, such as overlapping a larger punishment value.

The response delay index is, for example, round-Trip Time (RTT), and the response delay parameter is, for example, smooth Round-Trip Time (SRTT).

In practical applications, for example, after the first domain name server and the second domain name server are added to the local cache, a response delay parameter value corresponding to the first domain name server and a response delay parameter value corresponding to the second domain name server may be randomly initialized within a set value range (for example, [0,32us ]). Where us represents nanoseconds.

For example, for the first domain name server, if the normal response information is received, that is, the response information carrying the IP address of the first domain name server is received within a set duration, then the formula is according to: updating the response delay parameter value corresponding to the first domain name server by 0.7old_srtt+0.3curr_rtt, wherein old_srtt is the response delay parameter value corresponding to the first domain name server before updating, curr_rtt is the round trip time determined according to the response information of this time, in short, if the analysis request is sent at the time of T1, and the response information is received at the time of T2, then T2-T2 is regarded as the round trip time. And 0.7 and 0.3 are set weight values, and can be customized.

If the response information of the first domain name server is received over time (i.e. after the time period is longer than the set time period), or the response information of the first domain name server is received as an instruction for indicating that the service is down, the response delay parameter value of the current first domain name server may be determined according to a set larger penalty value, for example, a penalty value set by 0.7×old_srtt+0.3×e.g. 300000 us.

In the second case, the resolution request is sent to the second domain name server assuming that the first response delay parameter value is greater than the second response delay parameter value. However, it should be noted that, in the active/standby disaster recovery service mode, the first domain name server notifies the second domain name server to operate in the active/standby disaster recovery service mode in advance as described above. Based on the notification, if the second domain name server receives the resolution request sent by the third domain name server before receiving the start notification sent by the first domain name server, the second domain name server feeds back a response failure notification (such as a servfail notification) to the third domain name server, that is, the second domain name server sets its domain name resolution service to a disabled state based on the notification.

Based on the response failure notification, when the second domain name server receives the resolution request, if the start notification sent by the first domain name server is not received yet, the third domain name server feeds back a response delay parameter value corresponding to the second domain name server to obtain a fourth response delay parameter value, and the third domain name server resends the resolution request to the first domain name server based on the response failure notification and updates the response delay parameter value corresponding to the second domain name server in a punishment setting mode.

Assuming that at some later time, the third domain name server determines, based on the response delay parameter values (assuming that the first response delay parameter value and the second response delay parameter value are respectively) corresponding to the first domain name server and the second domain name server at that time, to send the resolution request corresponding to the currently received target domain name to the first domain name server, and determines that the first domain name server fails according to the response information of the first domain name server, as described above, the response delay parameter value corresponding to the first domain name server is updated in a penalty setting manner (such as overlapping a larger penalty value) to obtain the third response delay parameter value.

That is, it is assumed that the first domain name server fails at the above-described timing. In practice, the first domain name server detects its own health status in real time to determine whether a failure occurs, for example, if a Query Per Second (QPS) is found to exceed a set threshold, or if a downtime of the domain name resolution service is detected, it determines that a failure occurs. In the primary and backup disaster recovery service mode, when the first domain name server detects own faults, a start notification is sent to the second domain name server, and the second domain name server is informed of starting domain name resolution service based on the start notification, so that resolution requests corresponding to target domain names sent by the third domain name server can be responded normally.

After the third domain name server determines that the first domain name server fails, updating the response delay parameter value corresponding to the first domain name server into a third response delay parameter value in a punishment setting mode, and retransmitting the resolution request to the second domain name server when the third response delay parameter value is larger than the second response delay parameter value corresponding to the second domain name server. Therefore, the purpose of seamlessly switching to the second domain name server of the public cloud when the first domain name server fails is achieved.

It can be understood that in the active-standby disaster recovery service mode, when the first domain name server fails, even if the third domain name server sends a certain resolution request to the second domain name server, a response failure notification fed back by the second domain name server is received, so that the response delay parameter value corresponding to the second domain name server is updated to a larger value, so that a subsequent resolution request is sent to the first domain name server with the response delay parameter value updated gradually and the updated result being smaller than the response delay parameter value corresponding to the second domain name server, and the effect that the resolution request is sent to the first domain name server for processing when the first domain name server fails is achieved. Assuming that the response delay parameter value of the second domain name server is turned up at time T1, and the first domain name server fails at time T2 after a period of time, during which the response delay parameter value corresponding to the first domain name server has been turned up gradually, so after the response delay parameter value corresponding to the first domain name server is further turned up at time T2, the update result of the response delay parameter value corresponding to the first domain name server is often higher than the response delay parameter value corresponding to the second domain name server at this time, thereby seamlessly switching the resolution request to the second domain name server.

It can be understood that, since the third response delay parameter value of the first domain name server is relatively large, after the first domain name server fails, until the first domain name server returns to normal, as long as the second response delay parameter value corresponding to the second domain name server is not updated to be greater than the third response delay parameter value corresponding to the first domain name server, the resolution request for the target domain name is forwarded to the second domain name server. Even if the second response delay parameter value corresponding to the second domain name server is updated to be greater than the third response delay parameter value corresponding to the first domain name server before the first domain name server is restored to be normal, when forwarding the resolution request to the first domain name server, the third response delay parameter value of the first domain name server is updated to be a greater value again based on abnormal response information (such as a timeout response or an instruction indicating service downtime) of the first domain name server, thereby causing the resolution request to be retransmitted to the second domain name server.

In the primary and backup disaster recovery service mode, when the first domain name server detects self fault recovery, a notification indicating that the second domain name server does not start domain name resolution service is sent to the second domain name server, so that when the second domain name server receives a resolution request corresponding to a target domain name, a feedback response failure notification is sent to the third domain name server. Thus, when the third domain name server receives the resolution request after the first domain name server returns to normal and transmits the resolution request to the second domain name server, the resolution request is retransmitted to the first domain name server based on the received response failure notification. It will be appreciated that at this time, the third domain name server will update the response delay parameter value corresponding to the second domain name server to a larger value in a penalty manner.

Therefore, in the primary and standby disaster recovery service mode, the third domain name server can switch the resolution request of the target domain name to the second domain name server which is the alternative of the public cloud when the first domain name server fails based on response delay parameter values (such as SRTT) of different domain name servers, and the second domain name server dominates the resolution scheduling of the target domain name; and when the first domain name server is recovered from faults, switching the resolution request of the target domain name back to the first domain name server which is local to the application provider and is used as a main choice.

In order to more intuitively see the switching process of the first domain name server and the second domain name server in the active/standby disaster recovery service mode, the switching process is illustrated in fig. 6a and fig. 6 b. In fig. 6a, it is illustrated that the first domain name server normally sends a resolution request to the first domain name server. In fig. 6b, it is shown that in case of failure of the first domain name server, the resolution request is sent to the second domain name server. The broken line in the figure indicates a branch that is not taken.

Fig. 7 is a flowchart of a domain name resolution method according to an embodiment of the present invention, where the method may be performed by the third domain name server, as shown in fig. 7, and the method includes the following steps:

701. And responding to the resolution request of the client for the target domain name of the application provider, and if the IP address of the domain name server corresponding to the target domain name is queried from the local cache or the domain name management system and comprises the IP address of the first domain name server and the IP address of the second domain name server, determining a fifth response delay parameter value corresponding to the first domain name server and a sixth response delay parameter value corresponding to the second domain name server.

702. And if the fifth response delay parameter value is smaller than the sixth response delay parameter value, sending the resolution request to the first domain name server.

703. If the first domain name server is determined to be faulty according to the response information of the first domain name server, updating the response delay parameter value corresponding to the first domain name server in a punishment setting mode to obtain a seventh response delay parameter value, wherein the seventh response delay parameter value is larger than the sixth response delay parameter value.

704. And retransmitting the resolution request to the second domain name server according to the seventh response delay parameter value and the sixth response delay parameter value.

705. And receiving the IP address of the target application server determined by the second domain name server in at least one group of IP addresses corresponding to the target domain name, and feeding back the IP address of the target application server to the client.

In this embodiment, the execution process of the third domain name server may correspond to the cloud load service mode. In the cloud load service mode, the second domain name server and the first domain name server together provide resolution services of the target domain name. In this mode, initially, the application provider registers the IP address of the first domain name server and the correspondence between the IP address of the second domain name server and the target domain name together in the domain name management system. In the initial case, the second domain name server is notified to turn on the domain name resolution service.

In practical application, since the first domain name server is a device owned by the application provider, optionally, the application provider may perform a registration operation of the domain name server on the first domain name server. Based on this, based on the triggering of the application provider, a service mode configuration interface may be displayed on the first domain name server, where the service mode configuration interface includes an option to load a service mode at the cloud. In response to selection of the cloud load service mode, the first domain name server may output prompt information prompting a corresponding relationship between an IP address of the first domain name server and an IP address of the second domain name server registered in the domain name management system and the target domain name, and the application provider registers the corresponding relationship between the IP address of the first domain name server and the target domain name and the corresponding relationship between the IP address of the second domain name server and the target domain name in the domain name management system according to the prompt information.

Then, the resolution request triggered by the target domain name can be completed based on the registered first domain name server and the second domain name server. In a simple way, it is: initially, if the third domain name server receives an resolution request including a target domain name sent by a certain client, and determines that a cache record corresponding to the target domain name is not stored in the local cache, the domain name management system is queried to obtain an IP address of the domain name server corresponding to the target domain name. And determining the IP address of the domain name server corresponding to the target domain name as the IP address of the first domain name server and the IP address of the second domain name server based on the registration result. The correspondence between the target domain name and the IP address of the first domain name server and the IP address of the second domain name server may be added to the local cache, the set duration is stored, the response delay parameter values corresponding to the first domain name server and the second domain name server are initialized, and it is assumed that the first domain name server corresponds to the fifth response delay parameter value and the second domain name server corresponds to the sixth response delay parameter value. And sending the resolution request to the domain name server with small value according to the magnitude relation between the fifth response delay parameter value and the sixth response delay parameter value. Here, assuming that the fifth response delay parameter value is smaller than the sixth response delay parameter value, the resolution request is sent to the first domain name server. And then, the first domain name server determines the IP address of an application server in at least one group of IP addresses corresponding to the target domain name, feeds the IP address back to a third domain name server, and feeds the IP address back to the client side by the third domain name server. In addition, the third domain name server updates the response delay parameter value of the first domain name server based on the response information of the first domain name server, and the updating strategy is as described above.

After the third domain name server subsequently receives the resolution request of the target domain name, the local cache is queried to find two cache records of the first domain name server and the second domain name server, and the domain name server to which the resolution request received at the moment is sent is still determined based on the corresponding response delay parameter values.

And if the third domain name server receives the resolution request of the client to the target domain name at a certain time later, and determines that the first domain name server fails according to the response information of the first domain name server after the resolution request is sent to the first domain name server, then the third domain name server updates the response delay parameter value corresponding to the first domain name server in a punishment setting mode at the moment, and the updated result at the moment is assumed to be a seventh response delay parameter value. The third domain name server resends the resolution request to the second domain name server because the greater penalty would cause the seventh response delay parameter value to be greater than the sixth response delay parameter value corresponding to the previous second domain name server. The second domain name server feeds back the IP address of the target application server to the third domain name server, and the third domain name server feeds back the IP address of the target application server to the client.

After the first domain name server is recovered from the fault, the system is switched to a state in which the first domain name server and the second domain name server jointly provide services.

In order to more intuitively see the switching process of the first domain name server and the second domain name server in the cloud load service mode, an example is illustrated in fig. 8a and fig. 8 b. In fig. 8a, it is illustrated that the first domain name server normally sends a resolution request to the first domain name server or to the second domain name server, which is determined according to the respective response delay parameter value. 8b illustrates that in case of failure of the first domain name server, the resolution request is sent to the second domain name server. The broken line in the figure indicates a branch that is not taken.

It should be noted that, because the second domain name server is located in the public cloud, it is assumed that the second domain name server is located in a cloud server of the public cloud in the initial period, if the cloud server fails, the cloud manufacturer can instantly migrate the second domain name server to another cloud server, and the public cloud has abundant resources and can be flexibly deployed, so that the domain name server of the public cloud is considered to be not as likely to fail as the domain name server of the local application provider in the embodiment of the invention.

Based on the scheme provided by the embodiment of the invention, a cloud manufacturer can provide a cloud side and end side (terminal side, namely, local application provider) integrated domain name resolution scheduling scheme for an application provider, domain name resolution service software locally used by the application provider can be provided by the cloud manufacturer, the cloud manufacturer side maintains various heterogeneous domain name resolution service software, the functions of the cloud side and the end side are consistent, configuration data are consistent, and when the functions or the configuration data are updated, the public cloud can uniformly update the domain name resolution service software, so that the application provider does not need to spend more cost for maintenance. And the scheduling effect of the two sets of domain name servers at the cloud side and the end side is consistent, so that the user experience is ensured. The domain name server based on public cloud heterogeneous can ensure that domain name resolution service is provided locally in a normal state, disaster recovery service is provided by the domain name server of public cloud in an abnormal state, and stability of traffic scheduling of an entrance of an application provider is ensured. And the capability of providing domain name resolution service at the same time at the cloud side and the end side in a normal state can be provided, and a more flexible and comprehensive scheduling scene is provided.

Communication devices of one or more embodiments of the present invention will be described in detail below. Those skilled in the art will appreciate that these means may be configured by the steps taught by the present solution using commercially available hardware components.

Fig. 9 is a schematic structural diagram of a domain name resolution device according to an embodiment of the present invention, where the device is applied to the third domain name server, as shown in fig. 9, and the device includes: a determining module 11, a receiving module 12 and a transmitting module 13.

The determining module 11 is configured to respond to a resolution request of a target domain name of an application provider from a client, and if it is determined that a first domain name server corresponding to the target domain name fails, send the resolution request to a second domain name server corresponding to the target domain name, where the first domain name server is a domain name server private to the application provider, the second domain name server is located in a public cloud, and first domain name resolution service software in the first domain name server is different from second domain name resolution service software in the second domain name server.

And the receiving module 12 is configured to receive an IP address of a target application server determined by the second domain name server in at least one group of IP addresses corresponding to the target domain name, where each group of IP addresses includes an IP address of at least one application server corresponding to the target domain name.

And the sending module 13 is used for feeding back the IP address of the target application server to the client so that the client accesses the target application server.

Optionally, the IP address of the first domain name server and the IP address of the second domain name server corresponding to the target domain name are registered together in a domain name management system.

Optionally, the first domain name server and the second domain name server are configured to operate in a primary and backup disaster recovery service mode, wherein in the primary and backup disaster recovery service mode, the second domain name server is enabled when the first domain name server fails. At this time, the determining module 11 specifically is configured to: responding to an analysis request of a target domain name of an application provider from a client, and if the IP address of a domain name server corresponding to the target domain name is queried from a local cache or a domain name management system and comprises the IP address of the first domain name server and the IP address of the second domain name server, determining a first response delay parameter value corresponding to the first domain name server and a second response delay parameter value corresponding to the second domain name server; if the first response delay parameter value is smaller than the second response delay parameter value, the analysis request is sent to the first domain name server; if the first domain name server is determined to be faulty according to the response information of the first domain name server, updating the response delay parameter value corresponding to the first domain name server in a punishment setting mode to obtain a third response delay parameter value, wherein the third response delay parameter value is larger than the second response delay parameter value; when the first domain name server fails, a start notification indicating to start domain name resolution service is sent to the second domain name server, so that the second domain name server normally responds to the received resolution request; and sending the resolution request to the second domain name server according to the third response delay parameter value and the second response delay parameter value.

Optionally, the determining module 11 is further configured to: if the first response delay parameter value is greater than the second response delay parameter value, the resolution request is sent to the second domain name server; receiving a response failure notification fed back by the second domain name server; and sending the analysis request to the first domain name server, and updating the response delay parameter value corresponding to the second domain name server in a punishment setting mode to obtain a fourth response delay parameter value.

Optionally, the first domain name server and the second domain name server are configured to operate in a cloud load service mode, wherein in the cloud load service mode, services are provided by the first domain name server and the second domain name server together when the first domain name server is not failed. At this time, the determining module 11 is further configured to: responding to an analysis request of a target domain name of an application provider from a client, and if the IP address of a domain name server corresponding to the target domain name is queried from a local cache or a domain name management system and comprises the IP address of the first domain name server and the IP address of the second domain name server, determining a fifth response delay parameter value corresponding to the first domain name server and a sixth response delay parameter value corresponding to the second domain name server; if the fifth response delay parameter value is smaller than the sixth response delay parameter value, the resolution request is sent to the first domain name server; if the first domain name server is determined to be faulty according to the response information of the first domain name server, updating a response delay parameter value corresponding to the first domain name server in a punishment setting mode to obtain a seventh response delay parameter value, wherein the seventh response delay parameter value is larger than the sixth response delay parameter value; and sending the resolution request to the second domain name server according to the seventh response delay parameter value and the sixth response delay parameter value.

The apparatus shown in fig. 9 may perform the steps performed by the third domain name server in the foregoing embodiment, and the detailed performing process and technical effects are referred to the descriptions in the foregoing embodiment, which are not repeated herein.

An embodiment of the present invention further provides an electronic device, as shown in fig. 10, where the electronic device may include: a processor 21, a memory 22, a communication interface 23. Wherein the memory 22 has stored thereon executable code which, when executed by the processor 21, causes the processor 21 to implement a domain name resolution method as performed by the third domain name server in the previous embodiments.

Additionally, embodiments of the present invention provide a non-transitory machine-readable storage medium having executable code stored thereon, which when executed by a processor of an electronic device, causes the processor to at least implement a domain name resolution method as provided in the previous embodiments.

The apparatus embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separate. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment. Those of ordinary skill in the art will understand and implement the present invention without undue burden.

From the above description of the embodiments, it will be apparent to those skilled in the art that the embodiments may be implemented by adding necessary general purpose hardware platforms, or may be implemented by a combination of hardware and software. Based on such understanding, the foregoing aspects, in essence and portions contributing to the art, may be embodied in the form of a computer program product, which may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present invention, and are not limiting; although the invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method of domain name resolution, the method comprising:

responding to a resolution request of a target domain name of an application provider by a client, if a first domain name server corresponding to the target domain name is determined to be faulty, sending the resolution request to a second domain name server corresponding to the target domain name, wherein the first domain name server is a domain name server private to the application provider, the second domain name server is located in a public cloud, first domain name resolution service software in the first domain name server is different from second domain name resolution service software in the second domain name server, and the first domain name resolution service software and the second domain name resolution service software provide the same domain name resolution function and have the same configuration data related to the domain name resolution function;

2. The method of claim 1, wherein the IP address of the first domain name server and the IP address of the second domain name server corresponding to the target domain name are co-registered in a domain name management system.

3. The method of claim 2, wherein the first domain name server and the second domain name server are configured to operate in a primary-backup disaster recovery service mode, wherein in the primary-backup disaster recovery service mode, the second domain name server is enabled upon failure of the first domain name server;

the responding to the resolution request of the client for the target domain name of the application provider, if determining that the first domain name server corresponding to the target domain name fails, sending the resolution request to the second domain name server corresponding to the target domain name, including:

responding to an analysis request of a target domain name of an application provider from a client, and if the IP address of a domain name server corresponding to the target domain name is queried from a local cache or a domain name management system and comprises the IP address of the first domain name server and the IP address of the second domain name server, determining a first response delay parameter value corresponding to the first domain name server and a second response delay parameter value corresponding to the second domain name server;

If the first response delay parameter value is smaller than the second response delay parameter value, the analysis request is sent to the first domain name server;

if the first domain name server is determined to be faulty according to the response information of the first domain name server, updating the response delay parameter value corresponding to the first domain name server in a punishment setting mode to obtain a third response delay parameter value, wherein the third response delay parameter value is larger than the second response delay parameter value; when the first domain name server fails, a start notification indicating to start domain name resolution service is sent to the second domain name server, so that the second domain name server normally responds to the received resolution request;

and sending the resolution request to the second domain name server according to the third response delay parameter value and the second response delay parameter value.

4. A method according to claim 3, characterized in that the method further comprises:

if the first response delay parameter value is greater than the second response delay parameter value, the resolution request is sent to the second domain name server;

receiving a response failure notification fed back by the second domain name server;

And sending the analysis request to the first domain name server, and updating the response delay parameter value corresponding to the second domain name server in a punishment setting mode to obtain a fourth response delay parameter value.

5. The method of claim 2, wherein the first domain name server and the second domain name server are configured to operate in a cloud load service mode, wherein in the cloud load service mode, services are provided by the first domain name server and the second domain name server together when the first domain name server is not down;

responding to an analysis request of a target domain name of an application provider from a client, and if the IP address of a domain name server corresponding to the target domain name is queried from a local cache or a domain name management system and comprises the IP address of the first domain name server and the IP address of the second domain name server, determining a fifth response delay parameter value corresponding to the first domain name server and a sixth response delay parameter value corresponding to the second domain name server;

If the fifth response delay parameter value is smaller than the sixth response delay parameter value, the resolution request is sent to the first domain name server;

if the first domain name server is determined to be faulty according to the response information of the first domain name server, updating a response delay parameter value corresponding to the first domain name server in a punishment setting mode to obtain a seventh response delay parameter value, wherein the seventh response delay parameter value is larger than the sixth response delay parameter value;

and sending the resolution request to the second domain name server according to the seventh response delay parameter value and the sixth response delay parameter value.

6. An electronic device, comprising: a memory, a processor, a communication interface; wherein the memory has stored thereon executable code which, when executed by the processor, causes the processor to perform the domain name resolution method of any of claims 1 to 5.

7. A non-transitory machine-readable storage medium having stored thereon executable code, which when executed by a processor of an electronic device, causes the processor to perform the domain name resolution method of any of claims 1 to 5.

8. A domain name resolution system, comprising:

a first domain name server and a second domain name server corresponding to a target domain name of an application provider, and a third domain name server serving as a traffic inlet of the first domain name server and the second domain name server; the first domain name server is a domain name server private to the application provider, the second domain name server is located in public cloud, first domain name resolution service software in the first domain name server is different from second domain name resolution service software in the second domain name server, and the first domain name resolution service software and the second domain name resolution service software provide the same domain name resolution function and have the same configuration data related to the domain name resolution function;

the third domain name server is configured to perform the domain name resolution method according to any one of claims 1 to 5.

9. The system of claim 8, further comprising:

a control device coupled to the first and second detectors of the control device; the first detector is located at the first domain name server side, and the second detector is located at the second domain name server side;

The first detector is configured to detect first health status information of each application server included in the at least one set of IP addresses, and send the first health status information to the control device;

the second detector is configured to detect second health status information of each application server included in the at least one set of IP addresses, and send the second health status information to the control device;

the control device is configured to correspondingly determine target health status information of each application server according to the first health status information and the second health status information of each application server, and send the target health status information of each application server to the first domain name server and the second domain name server.

10. The system of claim 8, wherein the first domain name server is further configured to: displaying a service mode configuration interface, wherein the service mode configuration interface comprises a main disaster recovery service mode and a standby disaster recovery service mode; responding to the selection of the main and standby disaster recovery service modes, outputting prompt information for prompting the corresponding relation between the IP address of the first domain name server and the IP address of the second domain name server registered in a domain name management system and the target domain name respectively, and notifying the second domain name server to work in the main and standby disaster recovery service modes; and sending a start notification indicating that the domain name resolution service is started to the second domain name server when the first domain name server is detected to be faulty, so that the second domain name server normally responds to the received resolution request.

11. The system of claim 10, wherein the first domain name server is further configured to: and sending a notification indicating that the domain name resolution service is not started to the second domain name server when the first domain name server is detected to recover from the fault.

12. The system of claim 8, wherein the first domain name server is further configured to: displaying a service mode configuration interface, wherein the service mode configuration interface comprises a cloud load service mode; responding to the selection of the cloud load service mode, outputting prompt information for prompting the registration of the corresponding relation between the IP address of the first domain name server and the IP address of the second domain name server and the target domain name in a domain name management system, and informing the second domain name server to work in the cloud load service mode so that the second domain name server normally responds to the received analysis request.