CN112600796A - Anti-hijacking DNS over HTTP method and system - Google Patents

Abstract

The application relates to a DNS over HTTP method and system for preventing hijacking; the method comprises the following steps: generating a first digital signature according to a preset encryption algorithm according to the request domain name, the time parameter and the secret key; filling a request domain name, a time parameter and a first digital signature into a request data packet, and sending the request data packet to a server; extracting an IP list and a second digital signature from the acquired response data packet; the response data packet is generated and sent by the server side according to the request data packet; verifying the second digital signature according to the secret key; and if the verification is passed, caching the IP list to the local, and performing service linkage according to the IP list. The scheme of the application adopts HTTP plaintext transmission, only generates the encryption information related to the transmission content at this time through the secret key, ensures the correctness of the transmission information source, and can meet the safety requirement, thereby realizing the purpose of anti-hijacking; the risk of high delay and high system load of the DNS over HTTPS is solved, system resources are saved, and higher performance is provided.

Description

Anti-hijacking DNS over HTTP method and system

Technical Field

The application relates to the technical field of domain name resolution, in particular to a method and a system for preventing hijacking of a DNS over HTTP (hyper text transport protocol).

Background

The DNS over HTTP is one of the more popular subjects in the DNS field at present, and it is intended to use HTTP as the transport layer of DNS (in contrast, the traditional DNS uses UDP as the transport layer), so as to effectively prevent the DNS resolution result from being hijacked by local DNS. But since HTTP is also a clear text transmission, it may also be tampered with by the traffic system. The traditional solution is to use HTTPS as the transport layer, the so-called DNS over HTTPS (RFC 8484: HTTPS:// tools. ietf. org/html/RFC 8484). The DNS over HTTPS solves the problem of data tampering, but also causes the problems of increased transmission delay, increased transmission data, increased system consumption and the like.

In the related art, the DNS over HTTP is a plaintext transmission, and may be tampered by a traffic system; compared with DNS over HTTP, the DNS over HTTPS is used for one more TLS handshake mechanism and one CA authentication process, so that the problems of larger interaction delay, increased transmission data and the like are caused.

Disclosure of Invention

In order to overcome the problems in the related technology at least to a certain extent, the application provides a DNS over HTTP method and system with high performance, low delay and anti-hijacking capability, so that the problems that the existing DNS over HTTP data is hijacked and replayed are solved, and the problems that the DNS over HTTPS analysis delay is high, the analysis data volume is large and the system consumption is heavy are solved.

According to a first aspect of embodiments of the present application, there is provided a DNS over HTTP method for anti-hijacking, comprising:

generating a first digital signature according to a preset encryption algorithm according to the request domain name, the time parameter and the secret key;

filling a request domain name, a time parameter and a first digital signature into a request data packet, and sending the request data packet to a server;

extracting an IP list and a second digital signature from the acquired response data packet; the response data packet is generated and sent by the server side according to the request data packet;

verifying the second digital signature according to the secret key;

and if the verification is passed, caching the IP list to the local, and performing service linkage according to the IP list.

Further, the method further comprises:

and sending registration information to a server through an HTTPS protocol to obtain a unique user ID and a corresponding secret key.

Further, the generating the first digital signature according to the preset encryption algorithm includes:

and splicing the request domain name, the time parameter and the secret key into a character string, and generating a first digital signature by using the character string according to a preset encryption algorithm.

Further, the verifying the second digital signature according to the key includes:

generating an IPS character string according to the IP list;

splicing the first digital signature, the IPS character string and the secret key into a character string, and generating a signature to be verified by the character string according to a preset encryption algorithm;

comparing the second digital signature with the signature to be verified;

if the two data packets are the same, the verification is passed, and if the two data packets are not the same, the response data packet is discarded.

According to a second aspect of the embodiments of the present application, there is provided a DNS over HTTP method for preventing hijacking, including:

extracting a request domain name and a first digital signature from the acquired request data packet; the request data packet is generated and sent after the client fills in the request domain name, the time parameter and the first digital signature;

verifying the first digital signature according to the secret key;

if the verification is passed, inquiring a corresponding IP list according to the request domain name, and generating a second digital signature according to the first digital signature, the IP list and the secret key;

and filling the IP list and the second digital signature into a response data packet, and sending the response data packet to the client.

Further, the method further comprises:

extracting a user ID from the acquired request data packet, and judging the validity of the user ID;

if the ID is valid, inquiring a secret key corresponding to the user ID; if not, the request packet is discarded.

Further, the method further comprises:

extracting UTC time from the acquired request data packet;

comparing the UTC time with a current time;

if the time difference is larger than a preset time threshold, discarding the request data packet; if the time difference is not greater than the preset time threshold, the verification is passed.

Further, the verifying the first digital signature according to the key includes:

splicing the request domain name, the time parameter and the secret key into a character string, and generating a signature to be verified by the character string according to a preset encryption algorithm;

comparing the first digital signature with a signature to be verified;

if the two data packets are the same, the verification is passed, and if the two data packets are not the same, the request data packet is discarded.

According to a third aspect of the embodiments of the present application, there is provided an anti-hijacking DNS over HTTP system, including:

a client for: generating a first digital signature according to a preset encryption algorithm according to the request domain name, the time parameter and the secret key; filling a request domain name, a time parameter and a first digital signature into a request data packet, and sending the request data packet to a server;

a server configured to: extracting a request domain name and a first digital signature from a request data packet; verifying the first digital signature according to the secret key; if the verification is passed, inquiring a corresponding IP list according to the request domain name, and generating a second digital signature according to the first digital signature, the IP list and the secret key; filling an IP list and a second digital signature into a response data packet, and sending the response data packet to a client;

the client is further configured to: extracting the IP list and the second digital signature from the response data packet; verifying the second digital signature according to the secret key; and if the verification is passed, caching the IP list to the local, and performing service linkage according to the IP list.

According to a fourth aspect of embodiments of the present application, there is provided a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the operational steps of the method according to any one of the above embodiments.

The technical scheme provided by the embodiment of the application has the following beneficial effects:

the data transmission is plaintext transmission, only the encryption information related to the transmission content is generated through a secret key, the correctness of the transmission information source is ensured, the safety requirement can be met, and the anti-hijacking purpose is realized; by adopting HTTP plaintext transmission, the risk of higher delay and high system load of DNS over HTTPS is solved, system resources are saved, and higher performance is provided.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and together with the description, serve to explain the principles of the application.

Fig. 1 is a flow diagram illustrating a DNS over HTTP method for anti-hijacking of a client according to an example embodiment.

Fig. 2 is a flowchart illustrating a DNS over HTTP method applied to anti-hijacking of a server according to an exemplary embodiment.

Fig. 3 is a data flow diagram illustrating a client obtaining a key according to an example embodiment.

FIG. 4 is a data flow diagram illustrating a client querying in accordance with an exemplary embodiment.

Fig. 5 is a flowchart illustrating the operation of an anti-hijacking DNS over HTTP system in accordance with an exemplary embodiment.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of methods and systems consistent with certain aspects of the present application, as detailed in the appended claims.

Fig. 1 is a flow diagram illustrating an anti-hijacking DNS over HTTP method in accordance with an exemplary embodiment. The method is applied to the client and can comprise the following steps:

step 101: generating a first digital signature according to a preset encryption algorithm according to the request domain name, the time parameter and the secret key;

step 102: filling a request domain name, a time parameter and a first digital signature into a request data packet, and sending the request data packet to a server;

step 103: extracting an IP list and a second digital signature from the acquired response data packet; the response data packet is generated and sent by the server side according to the request data packet;

step 104: verifying the second digital signature according to the secret key;

step 105: and if the verification is passed, caching the IP list to the local, and performing service linkage according to the IP list.

The scheme of the application is plaintext transmission during data transmission, only the encryption information related to the transmission content at this time is generated through the secret key, the correctness of the transmission information source is ensured, the safety requirement can be met, and the anti-hijacking purpose is realized; by adopting HTTP plaintext transmission, the risk of higher delay and high system load of DNS over HTTPS is solved, system resources are saved, and higher performance is provided.

In some embodiments, the method further comprises:

and sending registration information to a server through an HTTPS protocol to obtain a unique user ID and a corresponding secret key.

Before domain name resolution, a client needs to register with a server to obtain a unique UUID (64bit) and a check secret key (1024 bit); the UUID is the user ID. To ensure the security of this process, transmission over HTTPS is required. In the subsequent communication process of domain name resolution, the requirement can be met only by HTTP transmission.

In some embodiments, the generating the first digital signature according to the preset encryption algorithm includes:

and splicing the request domain name, the time parameter and the secret key into a character string, and generating a first digital signature by using the character string according to a preset encryption algorithm.

Specifically, the time parameter may be UTC seconds; other parameters related to the current time are also possible. The preset encryption algorithm can be an SHA256 algorithm which cannot be reversely cracked and is high in safety.

In some embodiments, the verifying the second digital signature according to the key includes:

generating an IPS character string according to the IP list;

splicing the first digital signature, the IPS character string and the secret key into a character string, and generating a signature to be verified by the character string according to a preset encryption algorithm;

comparing the second digital signature with the signature to be verified;

if the two data packets are the same, the verification is passed, and if the two data packets are not the same, the response data packet is discarded.

Fig. 2 is a flow diagram illustrating a method of anti-hijacking DNS over HTTP, according to an example embodiment. The method is applied to a server and can comprise the following steps:

step 201: extracting a request domain name and a first digital signature from the acquired request data packet; the request data packet is generated and sent after the client fills in the request domain name, the time parameter and the first digital signature;

step 202: verifying the first digital signature according to the secret key;

step 203: if the verification is passed, inquiring a corresponding IP list according to the request domain name, and generating a second digital signature according to the first digital signature, the IP list and the secret key;

step 204: and filling the IP list and the second digital signature into a response data packet, and sending the response data packet to the client.

It should be noted that the server includes two modules: an HTTP module and a DNS module. The HTTP module is an external module responsible for interacting with clients (including user registration interactions, and HTTP dns interactions); the DNS module is an internal module that provides standard DNS protocols (RFC1034, RFC 1035).

The overall work flow of the server is as follows: the HTTP module interacts with the client and receives a request data packet; then the HTTP module requests an IP address of a certain domain name from the DNS module through a standard DNS protocol; the DNS module receives the information and then carries out IP list query and responds to the HTTP module for the corresponding IP address; and finally, the HTTP module sends the response data packet to the client.

In some embodiments, the method further comprises:

extracting a user ID from the acquired request data packet, and judging the validity of the user ID;

if the ID is valid, inquiring a secret key corresponding to the user ID; if not, the request packet is discarded.

In some embodiments, the method further comprises:

extracting UTC time from the acquired request data packet;

comparing the UTC time with a current time;

if the time difference is larger than a preset time threshold, discarding the request data packet; if the time difference is not greater than the preset time threshold, the verification is passed.

In some embodiments, the verifying the first digital signature from the key comprises:

splicing the request domain name, the time parameter and the secret key into a character string, and generating a signature to be verified by the character string according to a preset encryption algorithm;

comparing the first digital signature with a signature to be verified;

if the two data packets are the same, the verification is passed, and if the two data packets are not the same, the request data packet is discarded.

It should be understood that although the various steps in the flow charts of fig. 1-2 are shown in order as indicated by the arrows, the steps are not necessarily performed in order as indicated by the arrows. The steps are not performed in the exact order shown and described, and may be performed in other orders, unless explicitly stated otherwise. Moreover, at least some of the steps in fig. 1-2 may include multiple sub-steps or multiple stages that are not necessarily performed at the same time, but may be performed at different times, and the order of performance of the sub-steps or stages is not necessarily sequential, but may be performed in turn or alternating with other steps or at least some of the sub-steps or stages of other steps.

The application also provides an anti-hijacking DNS over HTTP system, which comprises a client and a server.

The client is used for: generating a first digital signature according to a preset encryption algorithm according to the request domain name, the time parameter and the secret key; and filling the request domain name, the time parameter and the first digital signature into a request data packet, and sending the request data packet to a server.

The server is used for: extracting a request domain name and a first digital signature from a request data packet; verifying the first digital signature according to the secret key; if the verification is passed, inquiring a corresponding IP list according to the request domain name, and generating a second digital signature according to the first digital signature, the IP list and the secret key; and filling the IP list and the second digital signature into a response data packet, and sending the response data packet to the client.

The client is further configured to: extracting the IP list and the second digital signature from the response data packet; verifying the second digital signature according to the secret key; and if the verification is passed, caching the IP list to the local, and performing service linkage according to the IP list.

The following describes the scheme of the present application in an expanded manner with reference to a specific application scenario.

The communication flow of the DNS over HTTP system comprises the following steps:

1.1, referring to fig. 3, the client registers information with the server, obtains a unique UUID (64bit) and a check key (1024bit), and needs to transmit through HTTPS to ensure the security of the process.

1.2, referring to fig. 4, when the client needs to resolve the domain name, a digital signature is generated according to a predetermined data encryption algorithm (see section 3.1 for details), and a request data packet to be sent is generated according to a predetermined communication protocol and sent to the server.

1.3, the server receives the user request, and judges the correctness and timeliness of the query according to a predetermined data verification method (see the part 3.2 in detail); if so, discarding the query; and if the DNS data is correct, obtaining DNS data queried by the user from the local DNS cache system, and sending the data to the client.

Second, communication protocol of the system

2.1, the format of the request protocol is as follows:

http://httpdns.zdns.cn/id/${UUID}/name/${QUERY_NAME}/type/${TYPE}/utc/${UTC_SEC}/signature/${SIGNATURE}

the HTTP method comprises the following steps: GET (GET tool)

Description of the drawings: UUID: the user applies for the unique UUID from the server;

QUERY _ NAME: the domain name (such as www.zdns.cn, must be filled out) queried by the user at this time by the DNS;

TYPE: type of query (must be A or AAAA, choose to fill, default to A if not filled);

UTC _ SEC: the current UTC seconds of the client;

SIGNATURE: a signature string generated using the encryption algorithm described in section 3.1.

2.2, response protocol; the portion of the response is placed in the body field of HTTP using JSON format.

The format of the response protocol is:

{“name”:”${QUERY_NAME}”,”type”:”${TYPE}”,”ttl”:${TTL},”rrs”:[“$IP1”,”$IP2”……],”signature”:”${RESP_SIGNATURE}”}

description of fields:

QUERY _ NAME: the domain name (type: character string) queried by the user at this time by the DNS;

TYPE: the type of query (type: string);

TTL: life cycle of record (type: value, unit is second);

RRS: the recorded IP addresses can be a plurality of IP addresses separated by commas;

RESP _ SIGNATURE: the signature string of the response (generated using the encryption algorithm described in section 3.2).

Third, the data encryption/verification algorithm of the system

3.1, Client end sending flow, refer to fig. 5:

A. the client acquires the current time, and fills the UTC part in the request format after UTC seconds are acquired;

B. the client fills the UUID of the client into the UUID part of the request;

C. the client splices QUERY _ NAME + UTC + SECRET, uses SHA256 to perform summary operation on the spliced character string, uses base64 to perform encoding, and puts the generated character string into the requested SIGNATURE part;

D. and after the operation is finished, sending the request to the server side.

3.2, Server end receiving and answering flow, referring to FIG. 5:

A. after receiving the user request, the server first acquires the UUDI of the client and judges the validity of the UUID; if invalid, directly discarding; otherwise, acquiring a secret key (secret) corresponding to the UUID;

B. obtaining UTC time from the request, then obtaining local time, comparing the difference between the UTC time and the local time, if the difference between the UTC time and the local time is within plus or minus 30 seconds, indicating that the time check ok is reached, and entering the next verification; otherwise, discarding;

C. encrypting the secret obtained in A and the QUERY _ NAME and UTC in the request by using the algorithm in 3.1C, comparing the encrypted secret with the SIGNATURE in the request, and if the encrypted secret and the SIGNATURE are different, discarding the encrypted secret; otherwise, entering the flow of D;

D. the server side acquires a record value corresponding to QUERY _ NAME + TYPE in the request from a local DNS cache, and fills a QUEYR _ NAME, TYPE and IP list corresponding to the record value into the RRS;

E. sorting (ascending) the character strings of the IP list in the D, and connecting to form an IPS character string for subsequent signature;

F. and (3) performing digest calculation on the IPS character string + user UUID corresponding secret in the IPS character string + user UUID in the SIGNATURE + E carried in the request by using sha256, encoding by using base64, putting into RESP _ SIGNATURE of response, and sending the whole response data packet to the client.

3.3, Client end receives response, refer to FIG. 5:

A. sorting (ascending) the IP addresses in the RRS in the response, and linking to form an IPS character string;

B. conducting sha256 summarization on the IPS character string in the SIGNATURE + A in the previous request and the secret used by the client, using base64 for coding, and comparing with RESP _ SIGNATURE in the response, if different, directly discarding; otherwise, the response is correct, the result in the response is cached locally, and the first IP is used for linking the service.

This application adopts above technical scheme, has following beneficial effect:

1. adopting a mode of separating user management from data transmission: and the HTTPS safe transmission is adopted during key distribution, so that the key is prevented from being hijacked, and the authentication is only carried out according to the key during data transmission after the key is obtained, thereby ensuring the efficiency of data transmission.

2. The data transmission is still plaintext transmission, and the encryption information related to the transmission content is generated only through the secret key, so that the correctness of the transmission information source is ensured, and the requirement can be met.

3. The risk of client DNS over HTTP data being hijacked is solved (client): since RESP _ signal in the response needs to use the signal sent by the user, and the result of parsing the data is also referred to. If any link or variable in the whole chain is changed, the verification cannot be passed.

4. anti-DDoS attack (server): as the client side needs to use the UUID and the secret corresponding to the UUID for signature when sending, the block is invisible to external attackers, and the SHA256 algorithm cannot be reversely decomposed, the protocol of the system cannot be constructed for DDoS attack, and the DDoS attack can be effectively prevented.

5. The risk of old data replay (old data replay) attack is partially solved (server side): since the current time of the client is included in the algorithm, and the time check needs to be controlled within plus or minus 30 seconds of the current time. Therefore, the old data replay attack in a certain time is directly discarded, and the protection capability of the system is improved.

6. The risks of high delay and high system load of DNS over HTTPS are addressed (client and server): compared with the traditional two-time data interaction of the DNS over HTTPS, the system only has one-time data interaction, and can obviously solve the problem of analysis delay of the client; meanwhile, a private key signature mode is used, so that compared with a TLS mode, system resources are saved, and higher performance is provided.

The present application also provides a computer-readable storage medium having stored thereon a computer program that, when executed by a processor, implements an anti-hijacking DNS over HTTP method, comprising: generating a first digital signature according to a preset encryption algorithm according to the request domain name, the time parameter and the secret key; filling a request domain name, a time parameter and a first digital signature into a request data packet, and sending the request data packet to a server; extracting an IP list and a second digital signature from the acquired response data packet; the response data packet is generated and sent by the server side according to the request data packet; verifying the second digital signature according to the secret key; and if the verification is passed, caching the IP list to the local, and performing service linkage according to the IP list.

The present application also provides a computer-readable storage medium having stored thereon a computer program that, when executed by a processor, implements an anti-hijacking DNS over HTTP method, comprising: extracting a request domain name and a first digital signature from the acquired request data packet; the request data packet is generated and sent after the client fills in the request domain name, the time parameter and the first digital signature; verifying the first digital signature according to the secret key; if the verification is passed, inquiring a corresponding IP list according to the request domain name, and generating a second digital signature according to the first digital signature, the IP list and the secret key; and filling the IP list and the second digital signature into a response data packet, and sending the response data packet to the client.

It is understood that the same or similar parts in the above embodiments may be mutually referred to, and the same or similar parts in other embodiments may be referred to for the content which is not described in detail in some embodiments.

It should be noted that, in the description of the present application, the terms "first", "second", etc. are used for descriptive purposes only and are not to be construed as indicating or implying relative importance. Further, in the description of the present application, the meaning of "a plurality" means at least two unless otherwise specified.

Any process or method descriptions in flow charts or otherwise described herein may be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps of the process, and the scope of the preferred embodiments of the present application includes other implementations in which functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those reasonably skilled in the art of the present application.

It should be understood that portions of the present application may be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, the various steps or methods may be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, any one or combination of the following techniques, which are known in the art, may be used: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application specific integrated circuit having an appropriate combinational logic gate circuit, a Programmable Gate Array (PGA), a Field Programmable Gate Array (FPGA), or the like.

It will be understood by those skilled in the art that all or part of the steps carried by the method for implementing the above embodiments may be implemented by hardware related to instructions of a program, which may be stored in a computer readable storage medium, and when the program is executed, the program includes one or a combination of the steps of the method embodiments.

In addition, functional units in the embodiments of the present application may be integrated into one processing module, or each unit may exist alone physically, or two or more units are integrated into one module. The integrated module can be realized in a hardware mode, and can also be realized in a software functional module mode. The integrated module, if implemented in the form of a software functional module and sold or used as a stand-alone product, may also be stored in a computer readable storage medium.

The storage medium mentioned above may be a read-only memory, a magnetic or optical disk, etc.

In the description herein, reference to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the application. In this specification, the schematic representations of the terms used above do not necessarily refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

Although embodiments of the present application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present application, and that variations, modifications, substitutions and alterations may be made to the above embodiments by those of ordinary skill in the art within the scope of the present application.

Claims (10)

1. An anti-hijacking DNS over HTTP method, comprising:

generating a first digital signature according to a preset encryption algorithm according to the request domain name, the time parameter and the secret key;

filling a request domain name, a time parameter and a first digital signature into a request data packet, and sending the request data packet to a server;

extracting an IP list and a second digital signature from the acquired response data packet; the response data packet is generated and sent by the server side according to the request data packet;

verifying the second digital signature according to the secret key;

and if the verification is passed, caching the IP list to the local, and performing service linkage according to the IP list.

2. The method of claim 1, further comprising:

and sending registration information to a server through an HTTPS protocol to obtain a unique user ID and a corresponding secret key.

3. The method according to claim 1 or 2, wherein the generating the first digital signature according to the preset encryption algorithm comprises:

and splicing the request domain name, the time parameter and the secret key into a character string, and generating a first digital signature by using the character string according to a preset encryption algorithm.

4. The method of claim 3, wherein verifying the second digital signature from the key comprises:

generating an IPS character string according to the IP list;

splicing the first digital signature, the IPS character string and the secret key into a character string, and generating a signature to be verified by the character string according to a preset encryption algorithm;

comparing the second digital signature with the signature to be verified;

if the two data packets are the same, the verification is passed, and if the two data packets are not the same, the response data packet is discarded.

5. An anti-hijacking DNS over HTTP method, comprising:

extracting a request domain name and a first digital signature from the acquired request data packet; the request data packet is generated and sent after the client fills in the request domain name, the time parameter and the first digital signature;

verifying the first digital signature according to the secret key;

if the verification is passed, inquiring a corresponding IP list according to the request domain name, and generating a second digital signature according to the first digital signature, the IP list and the secret key;

and filling the IP list and the second digital signature into a response data packet, and sending the response data packet to the client.

6. The method of claim 5, further comprising:

extracting a user ID from the acquired request data packet, and judging the validity of the user ID;

if the ID is valid, inquiring a secret key corresponding to the user ID; if not, the request packet is discarded.

7. The method of claim 6, further comprising:

extracting UTC time from the acquired request data packet;

comparing the UTC time with a current time;

if the time difference is larger than a preset time threshold, discarding the request data packet; if the time difference is not greater than the preset time threshold, the verification is passed.

8. The method of any of claims 5-7, wherein verifying the first digital signature from the key comprises:

splicing the request domain name, the time parameter and the secret key into a character string, and generating a signature to be verified by the character string according to a preset encryption algorithm;

comparing the first digital signature with a signature to be verified;

if the two data packets are the same, the verification is passed, and if the two data packets are not the same, the request data packet is discarded.

9. An anti-hijacking DNS over HTTP system, comprising:

a client for: generating a first digital signature according to a preset encryption algorithm according to the request domain name, the time parameter and the secret key; filling a request domain name, a time parameter and a first digital signature into a request data packet, and sending the request data packet to a server;

a server configured to: extracting a request domain name and a first digital signature from a request data packet; verifying the first digital signature according to the secret key; if the verification is passed, inquiring a corresponding IP list according to the request domain name, and generating a second digital signature according to the first digital signature, the IP list and the secret key; filling an IP list and a second digital signature into a response data packet, and sending the response data packet to a client;

the client is further configured to: extracting the IP list and the second digital signature from the response data packet; verifying the second digital signature according to the secret key; and if the verification is passed, caching the IP list to the local, and performing service linkage according to the IP list.

10. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out the operational steps of the method of any one of claims 1 to 4 or 5 to 8.

Images