CN111953678B

CN111953678B - Method and system for verifying DNS request security

Info

Publication number: CN111953678B
Application number: CN202010801720.3A
Authority: CN
Inventors: 谭有轩; 李武夷; 李恩琦; 李威奇; 王琳燕
Original assignee: Fuzhou Polytechnic
Current assignee: Fuzhou Polytechnic
Priority date: 2020-08-11
Filing date: 2020-08-11
Publication date: 2022-04-12
Anticipated expiration: 2040-08-11
Also published as: CN111953678A

Abstract

The invention provides a method and a system for verifying DNS request security.A client establishes a WebSocket connection channel with a server through a TLS security component and stores the WebSocket Secure connection channel in a connection pool; the client receives a DNS request data packet and sends the DNS request data packet to the server through a non-busy WebSocket Secure connection channel in the connection pool; the server receives the DNS request data packet, acquires a response packet corresponding to the DNS request data packet, extracts suspected factors in the DNS request data packet and the response packet, and calculates pollution scores corresponding to the suspected factors according to a preset weighted value; the server compares the pollution score with a first threshold value, and if the pollution score is larger than the first threshold value, returns verification failure information to the client; the security verification is carried out on the DNS request data packet and the corresponding response packet, instead of directly returning the response packet, so that the security of the client is further ensured, and the security and the accuracy of the DNS response received by the client are further ensured.

Description

Method and system for verifying DNS request security

Technical Field

The invention relates to the field of webpage access, in particular to a method and a system for verifying DNS request security.

Background

The Domain Name System (DNS) is an internet-based service, and is a distributed database service that maps Domain names and IP addresses to each other, and resolves Domain names to corresponding IP addresses, so that people can access the internet more conveniently. However, the DNS uses 53 ports of TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) to perform plaintext query, and does not have a check mechanism. The DNS inquiry can be hijacked and attacked by pollution, and the purposes of stealing user privacy information, phishing fraud and surfing records are achieved by intercepting and forging DNS data packets to guide users to wrong websites or snooping user DNS requests.

In order to solve the problem of low Security of plaintext query, a DNS Security scheme DNSSEC (DNS Security Extensions) based on signature verification and DNS over HTTPS and DNS over TLS based on encryption are proposed in the prior art; the DNSSEC only checks the data packets, the data packets which fail to be checked are discarded, the data packets are still plaintext, malicious third parties can still snoop DNS query data of users or intercept specific data packets, and the problem cannot be solved fundamentally; DNS over HTTPS and DNS over TLS are based on secure communication protocols such as HTTPS and TLS, and multiple handshakes are required, where please refer to fig. 4, which is a communication process of DNS Over TLS (DOT), and a dotted line divides a step included in a single DNS request access, so that it can be seen that a TLS (Transport Layer Security) handshake requires 4 RTTs (Round-Trip Time, Round-Trip delay), a request delay is theoretically four times of a non-encrypted query, and generally there is no connection maintaining mechanism, the TLS (Transport Layer Security) handshake needs to be disconnected after the query is completed, each communication needs to be reconnected and the TLS handshake is repeated, an increase in overlap request delay is large, and access to network resources is affected to a certain extent, and the above schemes are only to check or encrypt an identity of an original DNS request, and cannot find an unsafe factor in the original DNS request.

Disclosure of Invention

The technical problem to be solved by the invention is as follows: a method and a system for verifying the security of a DNS request are provided, which realize connection maintenance and the security of the DNS request.

In order to solve the technical problems, the invention adopts a technical scheme that:

a method of verifying DNS request security, comprising the steps of:

s1, establishing a WebSocket Secure connection channel with the server side through the TLS security component by the client side, and storing the WebSocket Secure connection channel in a connection pool;

s2, the client receives a DNS request data packet, and sends the DNS request data packet to the server through the non-busy WebSocket Secure connection channel in the connection pool;

s3, the server receives the DNS request data packet, acquires a response packet corresponding to the DNS request data packet, extracts suspected factors in the DNS request data packet and the response packet, and calculates pollution scores corresponding to the suspected factors according to a preset weighted value;

and S4, the server compares the pollution score with a first threshold value, and if the pollution score is larger than the first threshold value, returns verification failure information to the client.

In order to solve the technical problem, the invention adopts another technical scheme as follows:

a system for verifying DNS request security comprises a client and a server, wherein the client comprises a first memory, a first processor and a first computer program which is stored on the first memory and can run on the first processor; the server comprises a second memory, a second processor and a second computer program which is stored on the second memory and can run on the second processor, and the first processor realizes the following steps when executing the first computer program:

s11, establishing a WebSocket Secure connection channel with a server side through a TLS security component, and storing the WebSocket Secure connection channel in a connection pool;

s12, receiving a DNS request data packet, and sending the DNS request data packet to the server through the non-busy WebSocket Secure connection channel in the connection pool;

the second processor, when executing the second computer program, implements the steps of:

s23, receiving the DNS request data packet, acquiring a response packet corresponding to the DNS request data packet, extracting suspected factors in the DNS request data packet and the response packet, and calculating pollution scores corresponding to the suspected factors according to a preset weighted value;

and S24, comparing the pollution score with a first threshold value, and if the pollution score is larger than the first threshold value, returning verification failure information to the client.

The invention has the beneficial effects that: the client side and the DNS server side are connected through WebSocket Secure, the DNS server receives the DNS request data packet sent by the client side and inquires and obtains a corresponding response packet, the response packet is not directly sent to the client side, but extracts the suspected factors from the response packet and the DNS request data packet, calculates the pollution score, returns the information that the verification fails if the pollution score exceeds a first preset value, the security verification is carried out on the DNS request data packet and the corresponding response packet, the security of the client is further ensured, the security and the accuracy of the DNS response received by the client are further ensured, meanwhile, the security in the DNS query communication process is ensured by using WebSocket Secure through TLS encryption, and by utilizing a WebSocket mechanism, the lasting full duplex communication can be established only by one-time handshake, so that the use experience of a user is considered while the communication safety is improved.

Drawings

FIG. 1 is a flowchart illustrating steps of a method for verifying security of a DNS request according to an embodiment of the present invention;

fig. 2 is a schematic structural diagram of a system for verifying DNS request security according to an embodiment of the present invention;

FIG. 3 is a schematic diagram of the client and server according to an embodiment of the present invention;

FIG. 4 is a diagram illustrating a communication process of a DNS over TLS in the prior art;

FIG. 5 is a schematic diagram of a communication process of DNS over WebSocket Secure according to the present invention;

description of reference numerals:

3. a system for verifying DNS request security; 1. a client; 1.1, a first processor; 1.2, a first memory; 2. a server side; 2.1 a second processor; 2.2 second memory.

Detailed Description

In order to explain technical contents, achieved objects, and effects of the present invention in detail, the following description is made with reference to the accompanying drawings in combination with the embodiments.

Referring to fig. 1, fig. 3, fig. 4 and fig. 5, a method for verifying DNS request security includes the steps of:

From the above description, the beneficial effects of the present invention are: the client side and the DNS server side are connected through WebSocket Secure, the DNS server receives the DNS request data packet sent by the client side and inquires and obtains a corresponding response packet, the response packet is not directly sent to the client side, but extracts the suspected factors from the response packet and the DNS request data packet, calculates the pollution score, returns the information that the verification fails if the pollution score exceeds a first preset value, the security verification is carried out on the DNS request data packet and the corresponding response packet, the security of the client is further ensured, the security and the accuracy of the DNS response received by the client are further ensured, meanwhile, the security in the DNS query communication process is ensured by using WebSocket Secure through TLS encryption, and by utilizing a WebSocket mechanism, the lasting full duplex communication can be established only by one-time handshake, so that the use experience of a user is considered while the communication safety is improved.

Further, the S1 specifically includes:

establishing DNS monitoring at a local 53 port, establishing the WebSocket Secure connection channel with a server through a TLS security component, storing the WebSocket Secure connection channel in a connection pool, and finishing handshaking with the server.

As can be seen from the above description, establishing a WebSocket Secure connection between the client and the server can implement bidirectional communication between the client and the server, establish monitoring at a local specific port without consuming excessive port resources, and further ensure security and data integrity of DNS query communication through encryption by the TLS security component.

Further, the S2 specifically includes:

s21, receiving the DNS request data packet, judging whether a response data packet corresponding to the DNS request data packet exists in a local cache module, if so, directly returning the response data packet, and if not, executing S22;

s22, polling is carried out through a query queue, whether a non-busy WebSocket Secure connection channel exists in the connection pool or not is judged, if yes, the DNS request data packet is sent to the server through the non-busy WebSocket Secure connection channel, and if not, S23 is executed;

and S23, judging whether the connection quantity in the connection pool exceeds a second threshold value, if so, returning to S22, otherwise, creating a new WebSocket Secure connection channel, and sending the DNS request data packet to the server through the new WebSocket Secure connection channel.

From the above description, it can be known that an asynchronous parallel query mechanism based on multi-path connection is realized, the problem of communication channel or thread congestion occurring when a large number of queries are received by single-line single-path query is avoided, connection multiplexing is realized, and further, the recovery of connections with idle time exceeding a threshold value can be set, so that serious connection delay caused by repeated handshake requests and consumption of ports, network resources and memories caused by keeping connection restricted are avoided.

Further, the S3 specifically includes:

receiving the DNS request data packet, acquiring a response packet corresponding to the DNS request data packet, if the DNS request data packet does not contain a DNSSEC signature, extracting a request record type, a TTL life cycle and a protocol in the DNS request data packet, and simultaneously extracting an EDNS extension implementation part, a query type indication, a data packet truncation indication and a recursion indication in the response packet;

if the request record type is inconsistent/invalid derivative, or the TTL life cycle exceeds a preset range, or one of a protocol header/a protocol sentence tail in the protocol is invalid, or the EDNS extension part is invalid, or the query type indicates inconsistent/invalid derivative, or the data packet truncation indication is invalid, or the recursion indication is invalid, and if the above conditions meet one item, the pollution score is increased by a corresponding preset weighted value;

the S4 further includes:

if the pollution score is smaller than a first threshold and larger than a third threshold, performing active pollution inquiry test on the response packet, if the pollution score is not smaller than the first threshold and larger than the third threshold, discarding the response packet, and if the pollution score is larger than the third threshold, returning the response packet to the client, wherein the first threshold is larger than the third threshold;

and if the pollution score is smaller than a third threshold value, returning the response packet to the client.

As can be seen from the above description, after receiving a DNS request data packet and acquiring a corresponding response packet, the DNS request data packet is not immediately forwarded to a client, but a corresponding verification is performed first to obtain a pollution score, and different subsequent processing is performed according to a relationship between the pollution score and a threshold, so that security that a client returns a response packet to a server and the server returns a response packet to the client is achieved, privacy of DNS query by a user through the client is guaranteed, reliability of a response packet acquired by recursive query is guaranteed, trustworthiness of the server is achieved, and it is guaranteed that a request of the client is not attacked by pollution without DNSSEC signature.

Further, the S4 further includes sending a response packet to the client;

after S4, the method further includes:

the client acquires first information corresponding to a target domain in the DNS request data packet and second information corresponding to an address in the response packet through a WHOIS database;

according to the first information and the second information, carrying out threat analysis on the target domain and the address to obtain a threat score;

judging whether the threat score is larger than a fourth threshold value, if so, returning verification failure information to the webpage end;

otherwise, returning the address to the webpage end.

It can be known from the above description that when a client sends a target domain to a server for query, the client also obtains relevant information corresponding to the target domain through a WHOIS database, and if a response packet returned by the server is received, obtains an address therein, and also queries in the WHOIS database, and performs threat analysis on a result obtained by the query to obtain a threat score, and when the threat score is smaller than a threshold, returns a corresponding result to a web page, so that the security from the client to the web site is ensured, i.e., the reliability of a user accessing the web site is ensured, interception, snooping, tampering and interception, and the like of recursive query due to robbing pollution are avoided, the client queries relevant information corresponding to the target domain in advance before returning the query result, and the user is prevented from accessing the threat domain.

Referring to fig. 2, a system for verifying DNS request security includes a client and a server, where the client includes a first memory, a first processor, and a first computer program stored in the first memory and executable on the first processor; the server comprises a second memory, a second processor and a second computer program which is stored on the second memory and can run on the second processor, and the first processor realizes the following steps when executing the first computer program:

Further, the S11 specifically includes:

Further, the S12 specifically includes:

s121, receiving the DNS request data packet, judging whether a response data packet corresponding to the DNS request data packet exists in a local cache module, if so, directly returning the response data packet, and if not, executing S22;

s122, polling is carried out by a query queue, whether a non-busy WebSocket Secure connection channel exists in the connection pool is judged, if yes, the DNS request data packet is sent to the server through the non-busy WebSocket Secure connection channel, and if not, S23 is executed;

and S123, judging whether the connection quantity in the connection pool exceeds a second threshold value, if so, returning to S22, otherwise, creating a new WebSocket Secure connection channel, and sending the DNS request data packet to the server through the new WebSocket Secure connection channel.

Further, the S23 specifically includes:

the S24 further includes:

Further, the S24 further includes sending a response packet to the client;

after S24, the method further includes:

when the first processor executes the first computer program, first information corresponding to a target domain in the DNS request data packet and second information corresponding to an address in the response packet are obtained through a WHOIS database;

otherwise, returning the address to the webpage end.

It can be known from the above description that when a client sends a target domain to a server for query, the client also obtains relevant information corresponding to the target domain through a WHOIS database, if a response packet returned by the server is received, the address in the response packet is obtained, the query is also performed in the WHOIS database, the threat analysis is performed on the result obtained by the query to obtain a threat score, when the threat score is smaller than a threshold value, the corresponding result is returned to a webpage end, the security from the client to the website is ensured, namely, the reliability of the website accessed by a user is ensured, the interception, snooping, tampering and interception of the client query are avoided, the supply chain attack and the cache virus exposure caused by the robbing and pollution of the recursive query are also avoided, the client queries relevant information corresponding to the target domain in advance before the query result is returned, and the user is prevented from accessing the threat domain

Referring to fig. 1, fig. 3 and fig. 5, a first embodiment of the present invention is:

a method for verifying DNS request security specifically comprises:

the method specifically comprises the following steps:

a local monitoring module of a client establishes DNS monitoring at a local 53 port, establishes a WebSocket Secure connection channel with a server through a TLS (Security transport layer protocol) security component, stores the WebSocket Secure connection channel in a connection pool, and completes handshake with the server;

referring to fig. 5, after the handshake is completed, the server and the client may directly perform data transmission without establishing a connection when data transmission is required each time;

the method specifically comprises the following steps:

s21, the local monitoring module in the client receives the DNS request data packet, judges whether a response data packet corresponding to the DNS request data packet exists in the local cache module, if yes, the response data packet is directly returned, and if not, S22 is executed;

s23, judging whether the connection quantity in the connection pool exceeds a second threshold value, if so, returning to S22, otherwise, creating a new WebSocket Secure connection channel, and sending the DNS request data packet to the server through the new WebSocket Secure connection channel;

the method also comprises the steps of carrying out recovery polling on the connection pool at the background, judging whether a WebSocket Secure connection channel with the non-busy time exceeding the preset time exists or not, and if so, closing the WebSocket Secure connection channel;

s3, the server receives the DNS request data packet, checks a target domain in the DNS request data packet through a checking module, and sends the DNS request data packet to a scheduling module to be added into a recursive query queue, the scheduling module polls a thread pool, if a non-busy thread exists in the thread pool, recursive query processing is carried out, and a response packet corresponding to the DNS request data packet is obtained; if no non-busy thread exists in the thread pool, waiting for next polling;

after a response packet corresponding to a DNS request data packet is obtained, doubtful factors in the DNS request data packet and the response packet are extracted, and a pollution score corresponding to the doubtful factors is calculated according to a preset weighted value;

the method specifically comprises the following steps:

receiving the DNS request data packet, acquiring a response packet corresponding to the DNS request data packet, judging whether the DNS request data packet contains a DNSSEC (Domain Name System Security Extensions) signature, if so, verifying whether the DNSSEC signature is valid, if so, normally returning a recursive resolution record (response packet), setting Answer Authenticated (corresponding response is verified), and if not, discarding the response packet and returning error information BADSIG (signature verification fails);

if the DSN request data packet does not contain the DNSSEC signature, the DNSSEC deployment is not carried out in a target domain, the request Record Type (Record Type), the TTL life cycle and the protocol in the DNS request data packet are extracted, and the EDNS extension part implementation, the query Type indication, the data packet truncation indication and the recursion indication in the response packet are extracted;

if the request record type is inconsistent or invalid derivative, or the TTL life cycle exceeds a preset range, or one of a protocol header/a protocol tail in the protocol is invalid, that is, a response packet is incomplete, or the EDNS extension part performs invalidation, or the query type indicates inconsistent or invalid derivative, or the data packet truncation indicates invalid, or the recursion indication is invalid, or an address in a response packet is an unexpected address when a record in the response packet is an a record, an AAAA record, or a CNAME record, if the above conditions are met, the pollution score is increased by a corresponding preset weighted value;

wherein the preset range of the TTL life cycle is 60-86400; the query type is indicated as OpCode; the packet truncation indication is Truncated; recursion indications are Recursion Desired and Recursion Available;

s4, the server compares the pollution score with a first threshold value, and if the pollution score is larger than the first threshold value, returns verification failure information to the client;

if the pollution score is smaller than a third threshold value, returning the response packet to the client;

in an alternative embodiment, the weight of each case is 1, that is, the pollution score is increased by 1 every time one is satisfied, and if the pollution score is higher than the first threshold 5, the response packet is discarded and a query record error code NotAuth (verification failed) is returned to the client;

if the pollution score is less than the first threshold 5 and greater than the third threshold 3, performing an active pollution query test, specifically, querying a target domain through any IP address in a reserved IP address segment (CDIR representation is 198.18.0.1/24, i.e. after a broadcast address is excluded, an available address is 198.18.0.1-198.18.0.254) of the BGP route, if any response is made, indicating that the target domain is polluted by DNS virus injection/response, discarding a response packet corresponding to the target domain, and returning a query record error code NotAuth to the client; if the active pollution inquiry test has no response, returning a response packet to the client;

if the pollution score is smaller than the third threshold value 3, returning a response packet to the client;

specifically, the server side returns an encrypted response packet to the client side through the WebSocket Secure connection channel, and the client side decrypts the response packet and returns the response packet to the local 53 port to complete the query;

and the client local cache module judges whether the response packet conforms to a preset cache rule, and if so, the response packet is added into the local response cache.

The second embodiment of the invention is as follows:

a method for verifying security of DNS request, which is different from the first embodiment, further comprising the steps of:

otherwise, returning the address to the webpage end;

in an optional implementation manner, a client sends a DNS request data packet to a server, and simultaneously queries a target domain in the DNS request data packet in a WHOIS database, queries a domain name registrar, an NS server corresponding to a domain name, a domain name contact, registration time, TLD (top level domain) open time, and keywords, judges the keywords, and analyzes whether the keywords include counterfeit keywords or phishing threat keywords for a known website; after the client acquires the response packet, inquiring IP owner corresponding to the IP address in the response packet, ASN (access network node) to which the IP belongs and BGP (border gateway protocol) routing target country or region through the WHOIS data block, verifying whether a domain name registrar is consistent with the IP owner, matching the rest information of the target domain and the IP address according to a matching rule for threat analysis, intercepting and modifying a recursive inquiry response packet sent by the server if the matching result is that the threat score is greater than a threshold value, returning an inquiry record error code NotAuth to the webpage end, and normally returning the response packet to the webpage end if the threat score is less than the threshold value;

in an alternative embodiment, the matching rule is: (1) whether the target domain registration time has been greater than 90 days (2) TLD open time has been greater than 180 days (3) whether the target domain NS server is not on threat list (4) whether domain name contact information is valid or not on threat list (5) whether domain name contact addresses are valid or not on threat list (6) whether the contact and target domain do not contain (malicious, phishing threat) keywords (7) whether the domain name is not from a particular potentially abused Registrar (regastrar) or whether the domain name registry (NIC) (8) target domain and contact are compliant with known DGA (domain name generation algorithm) rules, each of which is not satisfied, the threat score is increased by a corresponding weight value.

Referring to fig. 2, a third embodiment of the present invention is:

a system 3 for verifying security of DNS requests, comprising a client 1 and a server 2, said client 1 comprising a first memory 1.2, a first processor 1.1 and a first computer program stored on said first memory 1.2 and executable on said first processor 1.1; the server 2 comprises a second memory 2.2, a second processor 2.1 and a second computer program stored on the second memory 2.2 and operable on the second processor 2.1, and the first processor implements the steps implemented by the client in the first embodiment or the second embodiment when executing the first computer program;

the second processor implements the steps implemented by the server in the first embodiment or the second embodiment when executing the second computer program.

In summary, the invention provides a method and a system for verifying DNS request security, which ensure DNS query communication security through TLS encrypted transmission by WebSocket Secure, avoid DNS hijacking, spoofing and pollution problems, and only one handshake needs to be completed between a client and a server, a persistent connection can be established between the client and the server, and full duplex communication can be provided, a connection maintenance and an ultra-long connection are supported by default, persistent bidirectional data transmission can be performed after one connection, then streaming data is protected by TLS security and only 1 RTT is needed, and the round trip of RTT is relatively close to non-encrypted plaintext transmission, and relatively small loss on communication performance is caused; the WebSocket connection channel adopting the asynchronous mechanism realizes the parallel asynchronous query adopting multiple paths, reduces the load between a single connection and a single thread, and avoids the possibility of blocking caused by the frequent bidirectional data transmission on the single connection; the method and the device have the advantages that the connection pool mechanism can multiplex the existing idle connection and recycle the long-time idle connection and the overtime connection, polling management of a large number of connections in the connection pool is realized, unnecessary resource waste and network delay improvement are avoided, and serious connection delay caused by repeated handshake requests and consumption of ports, network resources and memories caused by keeping the idle connection are avoided; the content format of the DNS protocol is compatible with standard DNS query, the universality and the equipment compatibility are guaranteed, in addition, the snooping and the interception of a data packet are prevented by the encrypted channel transmission, the communication performance of the safe DNS query is optimized, the connection delay is reduced, and the user use experience of the safe DNS is improved; the communication safety from a client to a server is realized, the recursion trusty of the server is also realized, the recursion query analysis response is checked through DNSSEC signatures, when a target domain does not deploy DNSSEC, an active DNS pollution characteristic identification scheme is used, DNS errors are realized or the realization is incomplete by using DNS robbery, a cache virus tool and PoC (in order to achieve the purpose of reaching before the real response, the request cannot be completely analyzed and correspondingly processed like the behavior of a real NS server, the realization of EDNS, OpCode, trunked and protocol structures by most DNS polluted robbery and virus response packets is incomplete), or in order to achieve a specific purpose, part of parameters are a value which is not consistent with the rules unexpectedly (for example, the TTL for realizing cache virus exposure is too large to exceed 86400 a day, so as to realize the long-term DNS hijack of cache records, or for realizing that an IP hijack address of a website is an unexpected address, record Type may ignore that the client request is hard coded as a etc.) as a risk factor for these implementation-incompleted defects and possibly unexpected unreasonable values for the purpose, if the answer time is higher than the doubtful threshold value, the inquiry is carried out on a non-existent NS server, a malicious answering end can also carry out answering and virus exposure on the inquiry to the non-existent NS server unavoidably, and a response which is completely unavailable under a normal condition is returned (the answering end cannot judge whether the source NS exists or not, if the NS exists, the answering end also needs to carry out inquiry, so that the time exceeds the time for answering TTL (time to live) is exceeded, the true response reaches the request target), the identification and the abandon of DNS pollution are realized by utilizing the unique characteristic of the unavoidable DNS pollution, and the possibility that recursive records are polluted and suffer supply chain/upstream attack is prevented; the risk analysis of the website is realized through the WHOIS database, the implementation is easy, the cost is low, meanwhile, the safety risk is carried out by adopting asynchronous utilization sub-threads, the interference on main recursive query logic is small, the query delay is not easily influenced, the extra delay caused by the risk analysis can be ignored, the safety strategy matching is realized, and the influence on the user experience is small.

The above description is only an embodiment of the present invention, and not intended to limit the scope of the present invention, and all equivalent changes made by using the contents of the present specification and the drawings, or applied directly or indirectly to the related technical fields, are included in the scope of the present invention.

Claims

1. A method of verifying DNS request security, comprising the steps of:

s4, the server compares the pollution score with a first threshold value, and if the pollution score is larger than the first threshold value, verification failure information is returned to the client;

the S4 further includes:

2. The method according to claim 1, wherein the S1 is specifically configured to:

3. The method according to claim 1, wherein the S2 is specifically configured to:

4. The method according to claim 1, wherein the S3 is specifically configured to: receiving the DNS request data packet, acquiring a response packet corresponding to the DNS request data packet, if the DNS request data packet does not contain a DNSSEC signature, extracting a request record type, a TTL life cycle and a protocol in the DNS request data packet, and simultaneously extracting an EDNS extension implementation part, a query type indication, a data packet truncation indication and a recursion indication in the response packet;

if the request record type is inconsistent/invalid derivative, or the TTL life cycle exceeds a preset range, or one of a protocol header/a protocol sentence tail in the protocol is invalid, or the EDNS extension part is invalid, or the query type indicates inconsistent/invalid derivative, or the data packet truncation indication is invalid, or the recursion indication is invalid, and if the above conditions meet one item, the pollution score is increased by a corresponding preset weighted value.

5. The method for verifying security of DNS request according to claim 1, wherein said S4 further comprises

Sending a response packet to the client;

after S4, the method further includes:

otherwise, returning the address to the webpage end.

6. A system for verifying DNS request security comprises a client and a server, wherein the client comprises a first memory, a first processor and a first computer program which is stored on the first memory and can run on the first processor; the server includes a second memory, a second processor, and a second computer program stored in the second memory and executable on the second processor, wherein the first processor implements the following steps when executing the first computer program:

s12, receiving a DN S request data packet, and sending the DN S request data packet to the server through the non-busy WebSocket Secure connection channel in the connection pool;

s24, comparing the pollution score with a first threshold value, and if the pollution score is larger than the first threshold value, returning verification failure information to the client;

the S24 further includes:

7. The system according to claim 6, wherein the S11 is specifically configured to:

8. The system according to claim 6, wherein the S12 is specifically configured to:

9. The system according to claim 6, wherein the S23 is specifically configured to:

10. The system for verifying security of DNS requests according to claim 6, wherein said S24 further includes sending a response packet to said client;

after S24, the method further includes:

otherwise, returning the address to the webpage end.