WO2023040070A1 - 一种域名接管漏洞的检测方法和装置 - Google Patents

一种域名接管漏洞的检测方法和装置 Download PDF

Info

Publication number
WO2023040070A1
WO2023040070A1 PCT/CN2021/135680 CN2021135680W WO2023040070A1 WO 2023040070 A1 WO2023040070 A1 WO 2023040070A1 CN 2021135680 W CN2021135680 W CN 2021135680W WO 2023040070 A1 WO2023040070 A1 WO 2023040070A1
Authority
WO
WIPO (PCT)
Prior art keywords
domain name
dns
server
record
takeover
Prior art date
Application number
PCT/CN2021/135680
Other languages
English (en)
French (fr)
Inventor
侯贺明
Original Assignee
武汉绿色网络信息服务有限责任公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 武汉绿色网络信息服务有限责任公司 filed Critical 武汉绿色网络信息服务有限责任公司
Publication of WO2023040070A1 publication Critical patent/WO2023040070A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1433—Vulnerability analysis
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]

Definitions

  • the invention relates to the technical field of the Internet, in particular to a method and device for detecting domain name takeover vulnerabilities.
  • Domain takeover is a vulnerability in itself, and it has similarities to domain hijacking, but there are also significant differences.
  • Domain name hijacking generally translated as domain hijack, means that when a user accesses a domain name, the attacker uses his own control over the network to redirect the access to this domain name to a fake server.
  • the most common situation is to hijack the domain name at the DNS resolution level.
  • the real server IP address of the domain name is A.
  • the server IP address corresponding to the domain name becomes B.
  • Domain name hijacking is generally achieved by hijacking the DNS resolution process, such as DNS cache poisoning, DNS resolution hijacking, etc.
  • Domain name takeover generally translated as domain takeover, means that the attacker uses some errors in the DNS configuration of the target domain name to direct access to the target domain name to a fake server.
  • Domain name takeover itself is a kind of vulnerability, which is caused by a problem with the DNS system configuration of the target domain name itself. Attacks can be carried out against this vulnerability to achieve the purpose of controlling the domain name; and domain name hijacking itself is an attack.
  • the attack is not based on a certain vulnerability, but on the basis that the attacker has certain control authority over the network. For example, the attacker has control authority over network devices, can modify DNS traffic packets, and return false DNS resolution records for the victim; or the attacker Has the control authority of the DNS recursive resolution server, and can modify the DNS cache records.
  • domain name hijacking and domain name takeover does not depend on the control authority of the network, but on the DNS configuration error of the target domain name. If domain name hijacking is not performed on the target domain name, then the target domain name will not have any resolution errors and problems, and DNS resolution and access are normal; There is a problem that it cannot be parsed normally, but at this time it will not be maliciously parsed to the IP address controlled by the attacker.
  • a CNAME record is a resource record in the DNS protocol, also called an alias record. It stores the alias of the current domain name.
  • the most common usage scenario for this record is to direct traffic to a third-party service.
  • There are many usage scenarios of CNAME the most common are two types of applications, the first type is basic network services and products, such as CDN, load balancing, web application firewall based on cloud architecture, anti-DDoS attack products based on cloud architecture, etc.;
  • the second category is some third-party SaaS services.
  • the main domain name is example.com, and it wants to use the third-party chat service chat.com, then it can apply for a service portal example.chat.com from the third-party service provider, At the same time, use the DNS CNAME record to add an alias record for your own subdomain chat.example.com, pointing to example.chat.com, so that all traffic visiting chat.example.com will be directed to example.chat.com.
  • DNS CNAME itself points the original domain name to another domain name, which means that the resolution authority of the IP address is also handed over to the new domain name at the same time. Take over the loophole.
  • the most typical vulnerability scenario is that the target domain name uses a third-party service, so the CNAME record is used to point to the domain name of the third-party service, but later due to the expiration of the third-party service, the target domain name forgets to modify it in its own DNS system in time This alias record, which will result in a dangling CNAME record. This kind of dangling CNAME record will cause a domain name takeover vulnerability.
  • the manifestation of this vulnerability is directly related to the third-party service. After the third-party service expires, some third-party services will no longer resolve the relevant domain name directly, and some choose to resolve to Some default error pages.
  • the traditional way of detecting domain name takeover vulnerabilities is generally based on CNAME keywords and the default error page keywords of third-party service providers, that is, collecting the CNAME domain name keyword list of third-party services, and checking whether the CNAME alias record of the target domain name matches these keywords.
  • Word list to determine whether the target domain name uses relevant third-party services; at the same time, collect the display information of the default error page of the third-party service provider to form a list of error message keywords, according to whether the default web page content of the target domain name matches the error message key Word list to determine whether the third-party service of the target domain name is unavailable.
  • the traditional CNAME-based detection method has a defect, that is, this method can only detect the normal DNS resolution, if the domain name itself cannot be resolved, then this method will fail. Specifically, since this method is to match CNAME keywords and third-party error message keywords, it requires that the target domain name must be able to resolve to an IP address, and then obtain webpage files from the target IP address, so as to further match keywords. If the DNS resolution is unsuccessful, whether the domain name does not exist or the domain name resolution process is wrong, this method cannot handle it.
  • the present invention proposes a new detection method, which does not rely on the CNAME keyword and the error message keyword of the third-party service, but detects the DNS NS record and the response status code of the DNS interaction protocol to detect domain name takeover vulnerabilities.
  • NS record is a kind of DNS resource record, which is the abbreviation of name server, which means the authoritative domain name server of the domain name, which is responsible for storing DNS resource records and is the server that is really responsible for domain name resolution.
  • the NS record is generally configured by the domain name service provider, and it must be a domain name itself, not an IP address.
  • the NS service can be built by itself, or a third-party service can be used.
  • DNSPod in China is a professional DNS resolution service provider.
  • more and more vendors provide external DNS resolution services, such as the Router53 service of Amazon cloud computing vendors, the Azure DNS service of Microsoft cloud services, and so on.
  • DNS records When using a third-party DNS resolution service, DNS records will be stored on the third-party platform, and these DNS records form a record file, which is called a DNS Zone file; when the user no longer uses the third-party DNS resolution service, the third-party The platform will delete the DNS Zone file corresponding to this domain name. If the NS record of the target domain name is not updated in time at this time, a domain name takeover vulnerability will occur, resulting in the DNS resolution authority of the entire domain of the target domain name being taken over.
  • the DNS resolution authority of the entire domain When the DNS resolution authority of the entire domain is taken over, it will cause great harm, because it is not just an independent domain name that is taken over, but the resolution authority of the entire domain is taken over, and the attacker can The domain name is analyzed, so that it can implement fraudulent certificates, receive and send emails related to this domain name, and other attacks.
  • the technical problem to be solved by the invention is how to realize the detection of domain name takeover loopholes.
  • the present invention adopts following technical scheme:
  • the present invention provides a method for detecting domain name takeover vulnerabilities, including:
  • DOMAIN_1 and NS_1 will appear in the DNS response content of the NS_0 server, and the DNS response content of NS_0 is an NS record, indicating that the NS server of DOMAIN_1 is NS_1;
  • the DNS NS record of DOMAIN_1 to the NS_1 server, if the returned DNS response status code is REFUSED, then it is determined that there is a domain name takeover vulnerability.
  • the method also includes:
  • IP_0 is equal to IP_1. If they are consistent, there is no vulnerability; if they are inconsistent, there is a domain name takeover vulnerability.
  • said querying the DNS A record of the target domain name to the NS server specifically includes:
  • the queried NS server is the NS server responsible for DNS A resolution of the target domain name, then it will be the result of querying the DNS A record of the target domain name returned by the first NS server;
  • the queried NS server is not the NS server responsible for DNS A resolution of the target domain name, but the root server, or the top-level domain name server, it will return the NS record so that the DNS request client can go to the next-level NS server according to the NS record send.
  • the NS server is obtained step by step in a recursive manner until the first NS server is reached, and the result of the query returned by the first NS server to the DNS A record of the target domain name is obtained, specifically: if it is resolved normally, return the result The IP address obtained by parsing the DNS A record of the target domain name.
  • the method further includes: if the parsing fails, returning a status code of NXDOMAIN or SERVFAIL.
  • the status code is SERVFAIL, it is specifically: one or more of: the recursive analysis server cannot be connected to the Internet, the DNSSEC check fails, the NS server is unreachable, and there is no DNS ZONE file corresponding to the domain name on the NS server.
  • said querying the DNS A record of the target domain name to the recursive resolution server is initiated by the domain name takeover vulnerability detection device.
  • the domain name takeover vulnerability detection device collects DNS records in the network, and completes the domain name takeover vulnerability detection by periodically querying the DNS records one by one from the recursive analysis server.
  • the present invention also provides a domain name takeover vulnerability detection device, which is used to implement the domain name takeover vulnerability detection method described in the first aspect, and the device includes:
  • the at least one processor and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the processor for The method for detecting the domain name takeover vulnerability described in the first aspect is implemented.
  • the present invention also provides a non-volatile computer storage medium, the computer storage medium stores computer-executable instructions, and the computer-executable instructions are executed by one or more processors to complete the first The detection method of the domain name takeover vulnerability described in the aspect.
  • the present invention uses the respective data maintenance characteristics of the current-level NS server and its upper-level NS server, and analyzes the problem of the domain name takeover vulnerability under the situation that the resolution of the DNS A record of the target domain name fails; overcomes the problem of this problem in the prior art When this happens, the problems in this situation are usually missed.
  • FIG. 1 is a schematic diagram of a domain name architecture provided by an embodiment of the present invention
  • FIG. 2 is a schematic flowchart of a detection method for a domain name takeover vulnerability provided by an embodiment of the present invention
  • Fig. 3 is a schematic flowchart of a detection method for a domain name takeover vulnerability provided by an embodiment of the present invention
  • Fig. 4 is a schematic diagram of a superior NS glue recording code provided by an embodiment of the present invention.
  • Fig. 5 is a schematic structural diagram of a detection device for a domain name takeover vulnerability provided by an embodiment of the present invention.
  • DNS resolution process many roles are involved, including: DNS client, forwarding DNS, recursive DNS and authoritative DNS.
  • a DNS client is a role that initiates a DNS request, such as a browser.
  • Forwarding DNS does not do DNS recursive query itself, but forwards DNS requests to recursive DNS for query; typical forwarding DNS, such as a home router, often has an IP address of 192.168.1.1.
  • Recursive DNS also called DNS resolver
  • DNS resolver is a recursive resolution server responsible for recursively querying the DNS tree structure.
  • DNS server it is usually said to configure a DNS server for the computer.
  • the DNS server here is strictly speaking incorrect. It should be called recursive DNS or forwarding DNS.
  • Authoritative DNS server also called NS server, authoritative domain name server, is a node in the DNS tree structure and is responsible for the DNS records of a certain domain name area.
  • the authoritative domain name server In the authoritative domain name server, it records all the DNS resolution records in the domain name area that it is responsible for. The most common types of records are: A record, the IP address of the domain name; NS record, the authoritative domain name server address of the domain name; MX record, the email address of the domain name Server address; TXT record, the text record of the domain name.
  • the root domain name is ., get 13 root domain name servers, select the first a.root-servers.net;
  • a node at each level represents a DNS area, which is responsible for resolving all subdomain names in this area. If there are nodes at the next level, then the next level The node is responsible for parsing the corresponding subdomain name.
  • the target domain name is www.example.com
  • the third-level node example.com is responsible for resolving it
  • the target domain name is www.test.example.com
  • the fourth-level node is responsible for resolving it Level-level node test.example.com
  • the target domain name is abc.test2.test.example.com
  • the fifth-level node test2.test.example.com is responsible for parsing it.
  • example.com is responsible for resolving *.example.com, unless there is a lower-level node that explicitly undertakes part of the sub-domain name resolution work, for example, there is a lower-level node test.example.com, which is responsible for *.test.example .com for parsing. If the NS record of a domain name is a subdomain name of this domain name, the recursive server will fall into a loop when resolving the domain name.
  • NS server For example, if the domain name is example.com, and the corresponding NS server is ns.example.com, then in the process of recursive resolution of example.com by the recursive resolution server, it will first ask the NS server corresponding to com, and com corresponds to The NS server tells the recursive analysis server that the NS server corresponding to example.com is ns.example.com, and then the recursive analysis server will go to this step again when locating the IP address of ns.example.com, forming a cycle . To solve this problem, a glue record is created.
  • a glue record is a special DNS resource record.
  • the glue record is a record in the NS server corresponding to com, which directly records the IP address of ns.example.com.
  • the NS server of com not only returns The NS of example.com is ns.example.com, and it also returns the IP address of ns.example.com.
  • the NS record connects the upper and lower nodes of the DNS tree structure, and is closely related to the glue record.
  • the NS record of example.com will exist in both the NS server of example.com and the NS server of com. Under normal circumstances, both It should be consistent, if not, only the records in com's NS server will work during the DNS recursive resolution process.
  • the detection method proposed by the present invention mainly has the following steps. First, initiate a DNS query to the recursive analysis server, query the DNS A record of the target domain name, and then observe the status code field in the DNS response message to check whether it is SERVFAIL; secondly, locate the domain name at this level in the DNS tree system, and at the same time Find the authoritative domain name server of the domain name at this level; then, initiate a DNS request to the authoritative domain name server of the domain name at this level, and the query target is the DNS NS record of the domain name at this level; finally check the received DNS response message, and check the DNS response on the one hand Whether the status code is REFUSED, on the other hand, compare the NS record and A record returned by the NS server of the target domain name, and the NS record and A record returned from the upper-level node to comprehensively determine whether there is a domain name takeover vulnerability.
  • the target domain name to be checked is test2.test.example.com
  • the recursive resolution server here is the so-called DNS server, such as the public 114.114. 114.114, Google's 8.8.8.8, or the default DNS servers provided by major operators.
  • the specific operation is to first initiate a DNS A record query for the target domain name to the root server, and the root server will return the NS record of the com domain name, recorded as NS_com, and then initiate a query to NS_com, and return the NS record of example.com, record NS_example. com, and then query to NS_example.com, the NS record of test.example.com will be returned, recorded as NS_test.example.com, and then query to NS_test.example.com, if everything is normal, it will return test2.test.example The IP address of .com. If there is a DNS configuration error in the target domain name, a DNS error message such as REFUSED may be returned here.
  • the DNS request is to request the A record of the target domain name test2.test.example.com.
  • the target domain name is test2.test.example.com.
  • the node domain name of com in the DNS system tree structure is test.example.com, or the DNS Zone domain is test.example.com
  • the NS of the node domain name at this level is NS_test.example.com
  • the upper-level domain name is example.com
  • the upper-level domain name NS is NS_example.com.
  • the glue record To check the glue record, first obtain the NS server domain name of the target domain name and the DNS ZONE domain name responsible for resolution, and then check whether the NS domain name is a subdomain name of the DNS ZONE domain name, and if so, further check the glue record.
  • the method is to obtain the glue record from the upper-level NS node, and then obtain the A record of the NS domain name from the current-level NS node, and compare the two. If they are consistent, there is no problem. Otherwise, there is a DNS configuration error and a domain name takeover vulnerability.
  • the detection method proposed by the present invention has the following characteristics. One is to detect based on the NS record of the DNS, rather than based on the CNAME record.
  • the traditional CNAME-based detection method is from the perspective of the DNS client, and simply requests the recursive resolution server to resolve the domain name to an IP address.
  • the specific recursive resolution process is completed by the recursive resolution server, which is not directly related to Dealing with the DNS tree structure; this method is from the perspective of the recursive resolution server, and will directly initiate a query to the DNS tree structure system, which will involve a large number of NS records.
  • the traditional methods for checking domain name takeover vulnerabilities, there is a method for checking NS records.
  • This method is to check the validity of the NS domain name, whether the domain name has expired, and whether it can be registered. If the NS domain name can be maliciously registered by attackers, it is natural The corresponding domain name can be taken over, but this method is fundamentally different from the method of using NS records in the present invention.
  • the second is to detect the situation that the DNS cannot be resolved normally, and the traditional method is only to detect the situation that the DNS is normally resolved.
  • the traditional detection method can only deal with the normal situation of the resolution.
  • Embodiment 1 of the present invention provides a detection method for a domain name takeover vulnerability, as shown in FIG. 2 , including:
  • step 201 query the DNS A record of the target domain name to the recursive resolution server.
  • step 202 obtain the response message of DNS, when checking that its DNS response status code is SERVFAIL, query the DNS A record of the target domain name to the NS server.
  • the status code is SERVFAIL, indicating that the recursive analysis server cannot be connected to the Internet, the DNSSEC check fails, the NS server is unreachable, and there is no DNS ZONE file corresponding to the domain name on the NS server.
  • step 203 the result of querying the DNS A record of the target domain name returned by the first NS server is obtained, and the first NS server is recorded as NS_1; the domain that the NS_1 server is responsible for is recorded as DOMAIN_1; the first NS server is recorded as DOMAIN_1; The NS server one level above the NS server is recorded as NS_0.
  • DOMAIN_1 and NS_1 will appear in the DNS response content of the NS_0 server, and the DNS response content of NS_0 is an NS record, indicating that the NS server of DOMAIN_1 is NS_1.
  • step 204 query the DNS NS record of DOMAIN_1 from the NS_1 server, and compare it with the obtained DNS NS record and NS_1, if they do not match, it is determined that there is a domain name takeover vulnerability.
  • the DNS NS record of DOMAIN_1 is queried from the NS_1 server. If the returned DNS response status code is REFUSED, it is determined that there is a domain name takeover vulnerability.
  • the present invention uses the respective data maintenance characteristics of the current-level NS server and its upper-level NS server, and analyzes the problem of domain name takeover loopholes when the resolution of the DNS A record of the target domain name fails; overcomes this problem in the prior art The problem with this situation is often missed when it occurs.
  • the DNS A record of the query target domain name to the NS server specifically includes two situations:
  • the queried NS server is the NS server responsible for DNS A resolution of the target domain name, then it will be the result of querying the DNS A record of the target domain name returned by the first NS server.
  • the queried NS server is not the NS server responsible for DNS A resolution of the target domain name, but the root server, or the top-level domain name server, it will return the NS record so that the DNS request client can send the next Level NS server sends.
  • the present invention usually involves obtaining NS servers step by step in a recursive manner until reaching the first NS server, and obtaining the result of querying the DNS A record of the target domain name returned by the first NS server, specifically It is: if the resolution is normal, the returned result is the IP address obtained by the resolution of the DNS A record of the target domain name; if the resolution fails, the returned result is NXDOMAIN, SERVFAIL and other status codes.
  • the method further includes:
  • IP_0 is equal to IP_1. If they are consistent, there is no vulnerability; if they are inconsistent, there is a domain name takeover vulnerability.
  • a record of the target domain name to the recursive analysis server is initiated by the domain name takeover vulnerability detection device; wherein, the domain name takeover vulnerability detection device collects DNS records in the network, and periodically queries the DNS one by one to the recursive analysis server The detection of domain name takeover vulnerabilities is completed by recording.
  • the embodiment of the present invention gathers several possible domain name takeover vulnerabilities into a complete analysis logic for presentation from a relatively complete analysis logic, as shown in Figure 3, including the following steps :
  • Step S101 querying the DNS A record of the target domain name from the recursive analysis server;
  • the recursive resolution server here refers to DNS Resolver, such as the public 114.114.114.114, Google's 8.8.8.8, or the default DNS resolution servers provided by major operators.
  • DNS server we usually configure for computers on the Internet is also called “DNS server”, strictly speaking, this name is wrong.
  • DNS server it should be called a recursive resolution server ( Or called DNS Resolver), and the authoritative domain name server in the DNS system is called DNS Server (also called NS server) in the DNS system specification. Therefore, in the embodiment of the present invention, the recursive resolution server refers to the DNS Resolver, and the authoritative domain name server refers to the NS server, also called DNS Server.
  • Step S102 obtain the DNS response message, check whether the DNS response status code is SERVFAIL, if yes, it means that the recursive analysis server has an error when querying the DNS tree system, and enter the step S103, otherwise, directly return no loopholes .
  • This step is to check the DNS response content returned by the recursive analysis server in step S101.
  • One item in the DNS response content is a status code.
  • This status code indicates that when the recursive analysis server is querying the DNS system, An error has occurred. There are many situations that may cause this error. For example, the recursive resolution server cannot be connected to the Internet, the DNSSEC verification fails, the NS server is unreachable, and there is no DNS ZONE file corresponding to the domain name on the NS server.
  • Step S103 query the DNS A record of the target domain name from the root domain name server.
  • This step is to directly initiate a DNS query request to the root domain name server of the DNS system to query the DNS A record of the target domain name, that is, to resolve the target domain name to an IP address.
  • the root domain name server is the root node in the tree structure of the DNS system, and is essentially an NS server.
  • the DNS system is a tree structure, in which each node is an NS server, also called an authoritative domain name server.
  • the first layer of nodes is called the root server, root name server, and the second layer of nodes is called the top level domain name server, top level domain name server.
  • the domain that the root domain name server is responsible for resolving is a dot ".”
  • the domain that the top-level domain name server is responsible for resolving is "com.”, "net.”, and so on.
  • Step S104 check whether the DNS response is an NS record.
  • This step is to check the DNS response returned by the NS server. If the NS server is the authoritative domain name server responsible for the resolution of the target domain name, then the returned DNS response content is the answer to the A record request; if the NS server queried is not the target domain name NS server, but the root server, or top-level domain name server, etc., then the NS record will be returned, the purpose is to tell the DNS requesting client, who should go to the next step to query. If the DNS response returns an NS record, then enter step S105, otherwise enter step S107, indicating that the NS server of the current level is the NS server to which the target domain name DNS A record belongs.
  • Step S105 acquiring a next-level NS server.
  • This step is to analyze the DNS response content in step S104. If the response content is an NS record, then it means that the current NS server is not the NS server of the target domain name, and the current NS server is directing to the next-level NS server. This step It is to obtain the next-level NS server.
  • Step S106 query the DNS A record of the target domain name to the next-level NS server.
  • This step is to initiate a DNS request to the NS server obtained in step S105, and query the DNS A record of the target domain name, that is, resolve the target domain name to an IP address.
  • Step S106 and step S105 constitute a recursive analysis process.
  • step S107 the current NS server is obtained, which is recorded as NS_1; the domain that the NS_1 server is responsible for is recorded as DOMAIN_1; and the upper-level NS server is recorded as NS_0.
  • the NS server that responds at this time is already the authoritative domain name server of the target domain name, that is, the NS server. Record this value as NS_1, and record the domain that the NS server is responsible for.
  • DOMAIN_1 and NS_1 will appear in the DNS response content of the NS_0 server, and the DNS response content of NS_0 is an NS record, indicating that the NS server of DOMAIN_1 is NS_1.
  • Step S108 query the DNS NS record of DOMAIN_1 from the NS_1 server.
  • NS_1 here refers to the NS server of the target domain name obtained in step S107, that is, the authoritative domain name server of the target domain name.
  • querying NS_1 for the DNS NS record of DOMAIN_1 is actually querying the NS server of the target domain name for the DNS ZONE domain name.
  • NS records, in the normal DNS recursive resolution process, this query step will not appear.
  • the upper-level NS server informs the NS server of the DNS ZONE domain name.
  • Step S109 check whether the DNS response is REFUSED.
  • the DNS response content in step S108 check whether its DNS status code is REFUSED, if yes, directly return high risk; otherwise, go to step S110.
  • the technical principle behind this step is that the NS server of each domain has the DNS ZONE file of this domain. If the NS server is queried for the DNS record of the domain that it is not responsible for parsing, it will return REFUSED, indicating a denial of service. .
  • this step means that in the DNS system, the tree nodes are still there, and the upper-level nodes still point to the current-level nodes, but inside the current-level nodes, the configuration of the target domain has been deleted. This situation is essentially a configuration error.
  • the upper-level node points to the record of this level.
  • DNS resource records are configured in the NS server, and the NS records point to the domain name of the NS server.
  • Step S110 obtain the value of NS in the DNS response, denoted as NS_2.
  • NS_2 the value of NS in the DNS response
  • step S108 is the NS record queried, so the DNS response content is also an NS record, and record this NS value as NS_2.
  • the principle behind this step is that there will be two copies of the NS record of the domain name in the DNS tree system, one in the upper-level NS server and one in the current-level NS server.
  • the target domain name is www.example.com
  • the corresponding domain is example.com
  • the corresponding NS is ns.example.com
  • the upper-level NS is ns.com
  • the responsible domain is com.
  • this NS record " example.com IN NS ns.example.com” will appear in the configuration of the NS server ns.com and the configuration of the NS server ns.example.com at the same time.
  • the commands executed by using the dig tool are as follows :
  • NS_1 is called parent NS
  • NS_2 is called local NS.
  • the NS_2 record is a very special record. It must be configured and must be consistent with NS_1, but it does not play a role in the normal DNS resolution process. That is to say, if NS_2 and NS_1 are inconsistent, then DNS resolution is based on NS_1 Whichever prevails.
  • Step S111 check whether NS_1 and NS_2 are the same, if they are the same, go to step S112, otherwise return to medium risk.
  • Both NS_1 and NS_2 here represent the authoritative domain name server of the target domain name, that is, the NS server, but NS_1 is obtained by querying the upper-level node when recursively querying in the DNS system tree structure, and NS_2 is directly to the NS of the target domain name obtained from the server query. If these two values are the same, it means that there is no problem with the configuration of the NS record. Go to step S112 to continue other checks. Otherwise, it means that there is a configuration error. Under normal circumstances, NS_1 and NS_2 are consistent. If they are inconsistent, it means that there is a configuration error. Error, NS_1 is the NS record configured on the domain name service provider, and NS_2 is the NS record configured on the NS server that you are responsible for.
  • Step S112 check whether NS_1 is a subdomain name of DOMAIN_1, this step is to determine whether the domain name of the NS server of the target domain name is a subdomain name of the DNS ZONE domain that the NS server is responsible for. For example, this is the case if the NS record for example.com is ns.example.com, and not the case if the NS record for example.com is ns.nowhere.com. If yes, then proceed to step S113 to continue checking, otherwise return to No Risk.
  • the domain name of the NS server corresponding to the target domain name www.example.com is ns.example.com
  • the IP address of the NS server is 1.1.1.1
  • the responsible domain is example.com
  • the upper-level NS is ns.com, responsible for The domain name is com.
  • the glue record is "ns.example.com IN A1.1.1.1".
  • This DNS record exists on both the NS server ns.com and the NS server ns.example.com on the server.
  • Step S113 query the DNS A record of NS_1 from NS_0, record it as IP_0.
  • This step is to query the glue record of the node at the upper level. For example, if the NS record of example.com is ns.example.com, and the NS record of the upper node com is ns.com, the operation performed here is to ns.com queries the IP address of ns.example.com, and the command to use the dig tool is "dig ns.example.com@ns.com".
  • Step S114 query the DNS A record of NS_1 from NS_1, record it as IP_1.
  • This step is to query the IP address of the node at the current level. For example, if the NS record of example.com is ns.example.com, the operation performed here is to query ns.example from ns.example.com. com's IP address.
  • the IP_0 in step S113 is actually the glue record, and the IP_1 here is actually the corresponding glue record that is queried on the NS server at the current level.
  • Step S115 check whether IP_0 is equal to IP_1, here is to compare whether IP_0 obtained in step S113 is equal to IP_1 in step S114.
  • IP_0 comes from the glue record of the upper-level NS node
  • IP_1 comes from the configuration record of the current-level NS node. If there are multiple IP_0 and IP_1, set comparison is performed, that is, to compare whether the two sets are equal. Under normal circumstances, the two should be consistent, and there is no loophole in the return; if the two are inconsistent, it means that there is a DNS configuration error and there is a domain name takeover vulnerability.
  • FIG. 5 it is a schematic structural diagram of a detection device for a domain name takeover vulnerability according to an embodiment of the present invention.
  • the device for detecting a domain name takeover vulnerability in this embodiment includes one or more processors 21 and a memory 22 . Wherein, one processor 21 is taken as an example in FIG. 5 .
  • the processor 21 and the memory 22 may be connected through a bus or in other ways.
  • connection through a bus is taken as an example.
  • the memory 22 as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs and non-volatile computer-executable programs, such as the domain name takeover vulnerability detection method in Embodiment 1.
  • the processor 21 runs the non-volatile software programs and instructions stored in the memory 22 to execute the method for detecting domain name takeover vulnerabilities.
  • the memory 22 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid-state storage devices.
  • the memory 22 may optionally include a memory that is remotely located relative to the processor 21, and these remote memories may be connected to the processor 21 through a network. Examples of the aforementioned networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.
  • the program instructions/modules are stored in the memory 22, and when executed by the one or more processors 21, the method for detecting the domain name takeover vulnerability in the above-mentioned embodiment 1 is executed, for example, executing the above-described Figure 2 And the various steps shown in Figure 3.
  • the program can be stored in a computer-readable storage medium, and the storage medium can include: only Read memory (ROM, Read Only Memory), random access memory (RAM, Random Access Memory), disk or CD, etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明涉及互联网技术领域，提供了一种域名接管漏洞的检测方法和装置。方法包括向递归解析服务器查询目标域名DNS A记录；获取DNS的响应报文，检查其DNS响应状态码是SERVFAIL时,向NS服务器查询目标域名DNS A记录；向NS_1服务器查询DOMAIN_1的DNS NS记录，并根据获取到的DNS NS记录和NS_1进行比对,若不匹配则认定为存在域名接管漏洞。本发明通过当前级NS服务器，以及其上级NS服务器各自的数据维护特点，并在目标域名DNS A记录解析失败的情况下分析出域名接管漏洞的问题所在。

Description

一种域名接管漏洞的检测方法和装置 【技术领域】
本发明涉及互联网技术领域，特别是涉及一种域名接管漏洞的检测方法和装置。
【背景技术】
随着云计算技术的不断发展和成熟，各种网络设施正在逐步迁移到云上面，传统的网络架构发生了巨大的变革。在传统的技术框架之下，公司如果要部署一个网站，往往需要自己来购买域名，配置DNS解析，购买IP地址或者网络空间服务，如果网站需要数据存储，则需要自己搭建数据库服务，如果需要处理大量并发访问，需要搭建负载均衡或者CDN网络。而现在随着虚拟化技术的发展，云计算公司提供各式各样的服务，几乎涵盖了所有的应用场景，举例来说，亚马逊云计算公司对外提供云服务器服务，DNS解析服务，负载均衡服务，CDN服务，数据库服务，存储桶服务等等，使得构建复杂的IT设施变得非常灵活和简单。一方面，IT基础设施迁移到云上之后，使用起来更便捷，更易扩展，健壮性更好；另一方面，随着各种基础组件越来越模块化，各种组件之间的交互越来越多，配置出错的概率越来越大。
域名接管本身是一种漏洞，它和域名劫持有相似的地方，但是也有显著的区别。
域名劫持，一般翻译为domain hijack，是指当用户访问一个域名时，攻击者利用自身对网络的控制，把针对此域名的访问重定向到虚假服务器上面。最常见的情况是，对域名进行DNS解析层面的劫持，比如域名真实的服务器IP地址为A，经过劫持之后，域名对应的服务器IP地址变为B。域名劫持一般是通过劫持DNS解析过程实现的，如DNS缓存投毒，DNS解析劫持等。
域名接管，一般翻译为domain takeover,是指攻击者利用目标域名DNS配置的一些错误，把针对目标域名的访问定向到虚假服务器上面。域名接管本身是一种漏洞，它产生的原因是目标域名自身的DNS系统配置出现了问题，针对这种漏洞可以进行攻击，达到控制域名的目的；而域名劫持，本身是一种攻击，这种攻击并不是基于某种漏洞，而是基于攻击者对网络有某种控制权限，如攻击者拥有网络设备控制权限，可以修改DNS流量报文，为受害者返回虚假DNS解析记录；或者是攻击者拥有DNS递归解析服务器的控制权限，可以修改DNS缓存记录。
域名劫持和域名接管的相似之处在于，最终表现出来的效果都是把目标域名解析到了攻击者控制的IP地址上面；不同之处在于，域名劫持往往要利用攻击者对网络设备的控制权限，如网关，路由器，DNS递归解析服务器等，域名接管不依赖对网络的控制权限，而是依赖于目标域名的DNS配置出现错误。如果不对目标域名进行域名劫持，那么目标域名不会出现任何解析错误和问题，DNS解析和访问都是正常的；如果不对目标域名进行域名接管，那么目标域名本身由于DNS解析配置的错误，也会出现不能正常解析的问题，只不过此时不会被恶意解析到攻击者控制的IP地址上面而已。
CNAME记录是DNS协议中的一种资源记录，也叫做别名记录，它存储的内容是当前域名的别名，此记录最常见的使用场景，是把流量导向第三方服务。CNAME的使用场景有很多，最常见的有两类应用，第一类是网络基础服务和产品，如CDN，负载均衡，基于云架构的WEB应用防火墙，基于云架构的防DDoS攻击产品等等；第二类是一些第三方的SaaS服务，比如主域名为example.com，它想使用第三方的聊天服务chat.com，那么它可以在第三方服务商那里申请一个服务入口example.chat.com,同时使用DNS CNAME记录为自身的子域名chat.example.com添加一个别名记录，指向example.chat.com，这样一来凡是访问chat.example.com的流量会全部导向example.chat.com。CNAME本身是把原始域名指向了另一个域名，这意味着同时把IP地址的解析权限也交给了新域名，CNAME本身是两种域名系统的衔接器，而一旦衔接出现问题，就会导致域名 接管漏洞。最典型的漏洞场景为，目标域名使用了第三方的服务，所以使用CNAME记录指向到了第三方服务的域名，但是后来由于第三方服务到期终止，但是目标域名忘记在自身的DNS系统中及时修改此别名记录，这样就会导致一条悬空的CNAME记录。此种悬空的CNAME记录会造成域名接管漏洞，这种漏洞的表现形式直接和第三方的服务有关，在第三方服务过期之后，有些第三方服务会直接不再解析相关域名，有些则选择解析到一些默认的错误页面。
传统的对于域名接管漏洞的检测思路一般是基于CNAME关键字和第三方服务厂商的默认错误页面关键字，即收集第三方服务的CNAME域名关键字列表，根据目标域名的CNAME别名记录是否匹配这些关键字列表，来判断目标域名是否使用了相关的第三方服务；同时收集第三方服务厂商的默认错误页面的显示信息，形成错误信息关键字列表，根据目标域名的默认网页内容是否匹配此错误信息关键字列表，来判断目标域名的第三方服务是否已经不可用。传统的基于CNAME的检测方法有一种缺陷，那就是此方法只能检测DNS解析正常的情况，如果域名本身不能解析，那么此方法就会失效。具体来说，由于此方法是匹配CNAME关键字和第三方的错误信息关键字，那么它要求目标域名必须能够解析到IP地址，进而从目标IP地址上获取网页文件，如此才能进一步匹配关键字。如果DNS解析不成功，无论是此域名不存在，或者是域名解析过程出错，此种方法都是不能处理的。针对此种情况，本发明提出了一种新的检测方法，此方法不依赖于CNAME关键字和第三方服务的错误信息关键字，而是通过检测DNS NS记录，以及DNS交互协议的响应状态码来检测域名接管漏洞。
NS记录是DNS资源记录的一种，是name server的缩写，表示域名的权威域名服务器，负责存储DNS资源记录的，是真正负责域名解析的服务器。NS记录一般是在域名服务商那里配置，它本身必须是域名，不能是IP地址。NS服务可以自己搭建，也可以使用第三方的服务，比如国内的DNSPod便是专业的DNS解析服务提供商。随着云计算的发展，越来越多的厂商对外提供DNS解析服务，亚马逊云计算厂商的Router53服务，微软云服务的Azure DNS服务等等。当使用第三方的DNS解析服务时，便会在第三方平台上存储DNS记录，这些DNS记 录形成一个记录文件，这个文件叫做DNS Zone文件；当用户不再使用第三方DNS解析服务时，第三方平台则会删除此域名对应的DNS Zone文件，如果此时目标域名的NS记录并没有及时更新，则会出现域名接管漏洞，导致目标域名整个域的DNS解析权限被接管。当整个域的DNS解析权限被接管之后，导致的危害极大，因为这里不仅仅是接管了某个独立的域名，而是接管了整个域的解析权限，攻击者可以对此域下面的所有子域名进行解析，从而可以实施冒领证书，接收和发送此域名相关的邮件等等攻击行为。
鉴于此，克服该现有技术所存在的缺陷是本技术领域亟待解决的问题。
【发明内容】
本发明要解决的技术问题是如何实现对域名接管漏洞的检测。
本发明采用如下技术方案：
第一方面，本发明提供了一种域名接管漏洞的检测方法，包括：
向递归解析服务器查询目标域名DNS A记录；
获取DNS的响应报文，检查其DNS响应状态码是SERVFAIL时,向NS服务器查询目标域名DNS A记录；
获取第一NS服务器返回的查询到目标域名DNS A记录的结果，将所述第一NS服务器，记做NS_1；把NS_1服务器负责的域，记做DOMAIN_1；把所述第一NS服务器上一级的NS服务器记做NS_0；
其中，DOMAIN_1和NS_1会出现在NS_0服务器的DNS响应内容中，NS_0的DNS响应内容就是一条NS记录，表明DOMAIN_1的NS服务器是NS_1；
向NS_1服务器查询DOMAIN_1的DNS NS记录，并根据获取到的DNS NS记录和NS_1进行比对,若不匹配则认定为存在域名接管漏洞。
优选的，向NS_1服务器查询DOMAIN_1的DNS NS记录，如果返回的DNS响应状态码为REFUSED，则认定为存在域名接管漏洞。
优选的，所述方法还包括：
向NS_0查询NS_1的DNS A记录，记做IP_0；
向NS_1查询NS_1的DNS A记录，记做IP_1；
检查IP_0是否等于IP_1，若一致，则说明无漏洞；若不一致，则说明存在域名接管漏洞。
优选的，所述向NS服务器查询目标域名DNS A记录，具体包括：
若查询的NS服务器是负责目标域名DNS A解析的NS服务器，那么作为第一NS服务器返回的查询到目标域名DNS A记录的结果；
若查询的NS服务器，并不是负责目标域名DNS A解析的NS服务器，而是根服务器，或者顶级域名服务器，则会返回NS记录，以便DNS请求客户端根据所述NS记录向下一级NS服务器发送。
优选的，以递归的方式逐级获取NS服务器，直到抵达所述第一NS服务器，所述获取第一NS服务器返回的查询到目标域名DNS A记录的结果，具体为：如果正常解析，返回结果为目标域名的DNS A记录解析得到的IP地。
优选的，方法还包括：如果解析失败，返回结果为NXDOMAIN或SERVFAIL状态码。
优选的，所述状态码是SERVFAIL时，具体为：递归解析服务器不能联网、DNSSEC校验未通过、NS服务器不可达、NS服务器上没有对应域名的DNS ZONE文件中的一种或者多种。
优选的，所述向递归解析服务器查询目标域名DNS A记录，是由域名接管漏洞检测设备发起。
优选的，域名接管漏洞检测设备搜集有网络中的DNS记录，并通过周期性的向递归解析服务器逐条查询DNS记录方式完成域名接管漏洞的检测。
第二方面，本发明还提供了一种域名接管漏洞的检测装置，用于实现第一方面所述的域名接管漏洞的检测方法，所述装置包括：
至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述处理器执行，用于执行第一方面所述的域名接管漏洞的检测方法。
第三方面，本发明还提供了一种非易失性计算机存储介质，所述计算机存 储介质存储有计算机可执行指令，该计算机可执行指令被一个或多个处理器执行，用于完成第一方面所述的域名接管漏洞的检测方法。
本发明通过当前级NS服务器，以及其上级NS服务器各自的数据维护特点，并在目标域名DNS A记录解析失败的情况下分析出域名接管漏洞的问题所在；克服了现有技术中对于此问题的发生时，通常会漏掉此种情形的问题。
【附图说明】
为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所需要使用的附图作简单地介绍。显而易见地，下面所描述的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本发明实施例提供的一种域名架构示意图；
图2是本发明实施例提供的一种域名接管漏洞的检测方法流程示意图；
图3是本发明实施例提供的一种域名接管漏洞的检测方法流程示意图；
图4是本发明实施例提供的一种上级NS胶水记录代码示意图；
图5是本发明实施例提供的一种域名接管漏洞的检测装置结构示意图。
【具体实施方式】
为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
在DNS解析过程中，涉及到众多角色，包括：DNS客户端、转发DNS、递归DNS和权威DNS。
DNS客户端，就是发起DNS请求的角色，如浏览器。
转发DNS，本身不做DNS递归查询，而是把DNS请求转发给递归DNS，来进行查询；典型的转发DNS，如家用的路由器，IP地址往往是192.168.1.1。
递归DNS，也叫DNS resolver,递归解析服务器，负责递归查询DNS树形结构。
通常所说的为电脑配置DNS服务器，这里的DNS服务器严格来说叫法并不 正确，应该叫做递归DNS，或者是转发DNS。
权威DNS服务器，也叫NS server,权威域名服务器，是DNS树形结构中的节点，负责某个域名区域的DNS记录。
此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。
在权威域名服务器中，记录了自身负责域名区域内所有的DNS解析记录，最常见的记录类型有：A记录，域名的IP地址；NS记录，域名的权威域名服务器地址；MX记录，域名的邮件服务器地址；TXT记录，域名的文本记录。
比如说，你的网站域名是www.testqqsg.tk,DNS递归请求流程如下：
找到根域名的NS服务器，根域名是.，得到13个根域名服务器，选择第一个a.root-servers.net；
向a.root-servers.net.发起目标域名www.testqqsg.tk的A记录请求，返回顶级域名tk.的NS记录为c.ns.tk；
向c.ns.tk发起目标域名www.testqqsg.tk的A记录请求，返回域名testqqsg.tk的NS记录ns.testqqsg.tk；
向ns.testqqsg.tk发起目标域名www.testqqsg.tk的A记录请求，得到www.testqqsg.tk的IP地址。
DNS树形结构如图1所示，每一层的一个节点，代表着一个DNS区域，负责对本区域内的所有子域名做解析，如果本层节点还有下一个层级节点，那么由下一级的节点负责对相应的子域名做解析。举例如下，目标域名如果是www.example.com,那么负责解析它的是第三级的节点example.com；目标域名如果是www.test.example.com,那么负责对它进行解析的是第四级节点test.example.com；如果目标域名是abc.test2.test.example.com,那么负责对它进行解析的是第五级节点test2.test.example.com。换句话说，example.com负责解析*.example.com，除非是有下级节点明确承担了一部分子域名解析工作，比如这里就是存在一个下级节点test.example.com，它负责对*.test.example.com进行解析。如果一个域名的NS记录是本域名的子域名时， 递归服务器在解析域名时，会陷入循环中。比如说的域名为example.com,对应的NS服务器是ns.example.com，那么在递归解析服务器对example.com进行递归解析的过程中，它会先询问com对应的NS服务器，此时com对应的NS服务器告诉递归解析服务器，example.com对应的NS服务器是ns.example.com,然后递归解析服务器在定位ns.example.com的IP地址时，又会重新走到这一步，就形成了循环。为了解决这个问题，胶水记录就产生了，胶水记录是一条特殊的DNS资源记录，它存在的目的就是打破一个域名的NS记录是自身的一个子域名这种情况产生的循环死锁。举例来说，胶水记录就是存在com对应的NS服务器中的一条记录，它直接记录了ns.example.com的IP地址，当递归解析服务器向com对应的NS服务器查询时，com的NS服务器不仅返回example.com的NS是ns.example.com，同时也返回ns.example.com的IP地址。NS记录连接了DNS树形结构的上下两级节点，并且和胶水记录密切相关，example.com的NS记录会同时存在example.com的NS服务器中，以及com的NS服务器中，正常情况下两者应该保持一致，如果不一致，在DNS递归解析过程中，只有com的NS服务器中的记录会起作用。
本发明提出的检测方法，主要有以下几个步骤。首先，向递归解析服务器发起DNS查询，查询目标域名的DNS A记录，此时观察DNS响应报文中的状态码字段，查看是否是SERVFAIL；其次，在DNS树形系统中定位本层级域名，同时找到本层级域名的权威域名服务器；然后，向本层级域名的权威域名服务器，发起DNS请求，查询目标是本层级域名的DNS NS记录；最后检查收到的DNS响应报文，一方面查看DNS响应状态码是否是REFUSED，另一方面对比目标域名的NS服务器返回的NS记录和A记录，以及从上一级节点返回的NS记录和A记录，综合来判断是否存在域名接管漏洞。举例如下，假如要检查的目标域名是test2.test.example.com,首先需要向递归解析服务器查询目标域名的DNS A记录，这里的递归解析服务器就是通常所说的DNS服务器，比如公共的114.114.114.114，谷歌的8.8.8.8，或者是各大运营商提供的默认DNS服务器。然后检查DNS的响应报文，观察其DNS响应状态码是否是SERVFAIL,如果是的 话，则开始定位目标域名在DNS树形系统中的本层级域名。具体操作是，首先向根服务器发起针对目标域名的DNS A记录查询，根服务器会返回com域名的NS记录，记做NS_com，然后向NS_com发起查询，会返回example.com的NS记录，记录NS_example.com，然后向NS_example.com发起查询，会返回test.example.com的NS记录，记做NS_test.example.com,然后向NS_test.example.com发起查询，如果一切正常则会返回test2.test.example.com的IP地址，如果目标域名存在DNS配置错误，这里可能会返回DNS错误信息，如REFUSED。在所有的查询中，DNS请求都是请求目标域名test2.test.example.com的A记录，当整个查询过程结束，得到了以下信息，在DNS树形系统中，目标域名test2.test.example.com在DNS系统树形结构中的节点域名为test.example.com,或者叫做DNS Zone域为test.example.com，本级节点域名的NS为NS_test.example.com,上级域名为example.com,上级域名NS为NS_example.com。接下来，向NS_test.example.com查询test.example.com的DNS NS记录，查看其返回结果中DNS响应状态码是否为REFUSED，如果是的话，则说明存在域名接管漏洞；如果不是的话，则进一步对比DNS响应内容的值是否是NS_test.example.com，如果不是，则说明NS记录在DNS树形结构中的上下两级节点中的值不一致，说明存在配置错误，存在域名接管漏洞；反之则进一步检查胶水记录。胶水记录的检查，首先获取目标域名的NS服务器域名以及负责解析的DNS ZONE域名，然后检查NS域名是否是DNS ZONE域名的一个子域名，如果是的话，就进一步检查胶水记录。方法是，从上级NS节点获取胶水记录，然后从本级NS节点获取NS域名的A记录，对二者进行比较，如果一致则说明没问题，反之则说明存在DNS配置错误，存在域名接管漏洞。
本发明提出的检测方法和传统的检测方法相比有以下几个特点，一是基于DNS的NS记录来检测，而不是基于CNAME记录。传统的基于CNAME的检测方法是站在DNS客户端的角度，只是单纯的向递归解析服务器请求把域名解析到IP地址，具体的递归解析过程都是由递归解析服务器来完成的，本身并不直接和 DNS树形结构打交道；本方法是站在递归解析服务器的角度，会直接向DNS树形结构系统发起查询，会大量涉及到NS记录。在传统的检查域名接管漏洞的方法中，有一种针对NS记录的检查方法，此方法是检查NS域名的有效性，域名是否过期，是否可以被注册，如果NS域名可以被攻击者恶意注册，自然可以接管对应的域名，不过这种方法和本发明中对NS记录的使用方法有着本质的区别。二是对DNS不能正常解析的情况进行检测，传统方法只是针对DNS正常解析的情况进行检测。DNS响应状态码有四种，NXDOMAIN表示域名不存在，NOERROR表示解析正常，SERVFAIL表示服务器出错，REFUSED表示拒绝服务，传统的检测方式只能处理解析正常的情况，如果DNS解析出现了错误，就不能处理了；本方法针对DNS解析出现错误的情况，进一步区分错误的详细类型，进而检测是否存在域名接管漏洞；三是对胶水记录和NS记录的理解和使用上。胶水记录是一种特殊的记录，只有域名的NS记录是自己的子域名时，才存在胶水记录；比胶水记录更重要的是NS记录，它连接了DNS树形结构的上下级节点。对于NS记录和胶水记录来说，它们实际上会同时存在两份，一份在本级节点域名的权威域名服务器上，另一份在上级节点域名的权威域名服务器上，而且真正起作用的是上级节点域名的权威域名服务器中的配置，而本级节点域名权威域名服务器的配置虽然存在，也可以查询，但是在正常的DNS解析流程中并不发挥作用。正常DNS解析流程中，是不会向本级域名NS服务器查询本级域名的NS记录的，举个通俗的例子，正常的DNS解析流程就像是，你会向张三的上级询问“谁是张三”，但是却不会向张三本人询问“谁是张三”，但是“谁是张三”这个记录同时存在于张三本人和张三上级两个人的记录档案里。本文的检测流程中会向张三上级和张三本人询问，如果发现答案不一致，则说明存在DNS配置错误，存在域名接管的风险。
实施例1:
本发明实施例1提供了一种域名接管漏洞的检测方法，如图2所示，包括：
在步骤201中，向递归解析服务器查询目标域名的DNS A记录。
在步骤202中，获取DNS的响应报文，检查其DNS响应状态码是SERVFAIL 时,向NS服务器查询目标域名的DNS A记录。
其中，所述状态码是SERVFAIL，表明递归解析服务器不能联网、DNSSEC校验未通过、NS服务器不可达、NS服务器上没有对应域名的DNS ZONE文件中的一种或者多种。
在步骤203中，获取第一NS服务器返回的查询到目标域名的DNS A记录的结果，将所述第一NS服务器，记做NS_1；把NS_1服务器负责的域，记做DOMAIN_1；把所述第一NS服务器上一级的NS服务器记做NS_0。
其中，DOMAIN_1和NS_1会出现在NS_0服务器的DNS响应内容中，NS_0的DNS响应内容就是一条NS记录，表明DOMAIN_1的NS服务器是NS_1。
在步骤204中，向NS_1服务器查询DOMAIN_1的DNS NS记录，并根据获取到的DNS NS记录和NS_1进行比对,若不匹配则认定为存在域名接管漏洞。
其中，向NS_1服务器查询DOMAIN_1的DNS NS记录，如果返回的DNS响应状态码为REFUSED，则认定为存在域名接管漏洞。
本发明通过当前级NS服务器，以及其上级NS服务器各自的数据维护特点，并在目标域名的DNS A记录解析失败的情况下分析出域名接管漏洞的问题所在；克服了现有技术中对于此问题的发生时，通常会漏掉此种情形的问题。
现有的技术依赖对CNAME关键字和网页信息关键字的匹配，前提是要求域名可以正常解析，如果域名不能解析，就不能继续进行处理。现有的技术需要获取到目标域名的DNS CNAME记录和目标域名的DNS A记录，而要获取到这两个记录，需要DNS响应状态码必须是NOERROR，而不能是NXDOMAIN，SERVFAIL，REFUSED等。只有当DNS响应状态码是NOERROR时，才意味着域名可以正常解析，其它情况下意味着域名解析出错。传统的检测技术中，对域名解析部分都是依靠递归解析服务器来完成，并不会直接和DNS树形结构系统交互，本文提出的方法除了查询递归DNS服务器，同时也查询DNS树形结构系统，直接和NS服务器进行交互，从而可以检测出来一些隐蔽的DNS配置错误导致的域名接管漏洞。
在本发明实施例，所述向NS服务器查询目标域名的DNS A记录，具体包括两种情况：
第一、若查询的NS服务器是负责目标域名的DNS A解析的NS服务器，那么作为第一NS服务器返回的查询到目标域名的DNS A记录的结果。
第二、若查询的NS服务器，并不是负责目标域名DNS A解析的NS服务器，而是根服务器，或者顶级域名服务器，则会返回NS记录，以便DNS请求客户端根据所述NS记录向下一级NS服务器发送。
在本发明实施例中，通常会涉及以递归的方式逐级获取NS服务器，直到抵达所述第一NS服务器，所述获取第一NS服务器返回的查询到目标域名的DNS A记录的结果，具体为：如果正常解析，返回结果为目标域名的DNS A记录解析得到的IP地；如果解析失败，返回结果为NXDOMAIN，SERVFAIL等状态码。
结合本发明实施例，还存在一种优选的扩展方案，所述方法还包括：
向NS_0查询NS_1的DNS A记录，记做IP_0；
向NS_1查询NS_1的DNS A记录，记做IP_1；
检查IP_0是否等于IP_1，若一致，则说明无漏洞；若不一致，则说明存在域名接管漏洞。
所述向递归解析服务器查询目标域名的DNS A记录，是由域名接管漏洞检测设备发起；其中，域名接管漏洞检测设备搜集有网络中的DNS记录，并通过周期性的向递归解析服务器逐条查询DNS记录方式完成域名接管漏洞的检测。
实施例2：
本发明实施例基于实施例1提出的解决方案基础上，从一个较为完整的分析逻辑，将几种可能域名接管漏洞集中到了一个完整的分析逻辑中进行呈现，如图3所示，包括以下步骤：
步骤S101，向递归解析服务器查询目标域名的DNS A记录；
这里的递归解析服务器是指DNS Resolver，比如公共的114.114.114.114，谷歌的8.8.8.8，或者是各大运营商提供的默认DNS解析服务器。
这里需要对概念和名词做出澄清，我们平时上网给电脑配置的DNS服务器，虽然也称作“DNS服务器”，但是严格来说这种叫法是错误的，按照DNS规范应该叫做递归解析服务器(或者叫做DNS Resolver)，而DNS系统里面的权威域名 服务器，在DNS系统规范中叫做DNS Server(也叫做NS服务器)。所以本发明实施例中，递归解析服务器就是指DNS Resolver,权威域名服务器就是指NS服务器，也叫做DNS Server。
步骤S102，获取DNS的响应报文，检查其DNS响应状态码是否是SERVFAIL,如果是的话，表示递归解析服务器在向DNS树形系统查询时发生错误，进入S103步骤，否则的话，直接返回无漏洞。
此步骤是检查步骤S101中，递归解析服务器返回的DNS响应内容，DNS响应内容中有一项为状态码，这里是要检查状态码是否是SERVFAIL，这个状态码表示递归解析服务器在查询DNS系统时，发生了错误，有多种情况可能会引发这种错误，比如递归解析服务器不能联网，DNSSEC校验未通过，NS服务器不可达，NS服务器上没有对应域名的DNS ZONE文件等等。
步骤S103，向根域名服务器查询目标域名的DNS A记录。
此步骤是直接向DNS系统的根域名服务器发起DNS查询请求，查询目标域名的DNS A记录，也就是把目标域名解析到IP地址。根域名服务器，是DNS系统树形结构中的根节点，本质上是NS服务器。
DNS系统是一个树形结构，其中每个节点都是一个NS服务器，也叫做权威域名服务器，其中的第一层节点叫做根服务器，root name server,第二层节点叫做顶级域名服务器，top level domain name server。比如根域名服务器负责解析的域就是一个点“.”,顶级域名服务器负责解析的域是“com.”,“net.”等等。
步骤S104，检查DNS响应是否是NS记录。
此步骤是，检查NS服务器返回的DNS响应，如果NS服务器是负责目标域名解析的权威域名服务器，那么返回的DNS响应内容就是针对A记录请求的答案；如果查询的NS服务器，并不是目标域名的NS服务器，而是根服务器，或者顶级域名服务器等等，那么则会返回NS记录，目的是告诉DNS请求客户端，下一步应该去找谁去查询。如果DNS响应返回的是NS记录，则进入步骤S105，否则进入步骤S107，表明当前级的NS服务器是目标域名DNS A记录所属的NS 服务器。
步骤S105，获取下一级NS服务器。
此步骤是解析步骤S104中的DNS响应内容，如果响应内容是NS记录，那么则说明，当前的NS服务器并不是目标域名的NS服务器，当前NS服务器把指引到了下一级的NS服务器，此步骤就是获取到下一级的NS服务器。
步骤S106，向下一级NS服务器查询目标域名的DNS A记录。
此步骤是向步骤S105种获取到的NS服务器发起DNS请求，查询目标域名的DNS A记录，也就是把目标域名解析到IP地址。步骤S106和步骤S105组成了递归解析的过程。
步骤S107，获取当前的NS服务器，记做NS_1；把NS_1服务器负责的域，记做DOMAIN_1；把上一级的NS服务器记做NS_0。能够进入此步骤说明DNS响应内容已经不是NS记录，此时响应的NS服务器，已经是目标域名的权威域名服务器，也就是NS服务器，把此值记做NS_1，同时把此NS服务器负责的域记做DOMAIN_1，把上级节点的NS服务器记做NS_0。DOMAIN_1和NS_1会出现在NS_0服务器的DNS响应内容中，NS_0的DNS响应内容就是一条NS记录，表明DOMAIN_1的NS服务器是NS_1。
步骤S108，向NS_1服务器查询DOMAIN_1的DNS NS记录。这里的NS_1就是指步骤S107中获取到的目标域名的NS服务器，也就是目标域名的权威域名服务器，此时向NS_1查询DOMAIN_1的DNS NS记录，其实就是向目标域名的NS服务器查询DNS ZONE域名的NS记录，在正常的DNS递归解析过程中，是不会出现这个查询步骤的，正常的查询流程中，是由上一级的NS服务器告知DNS ZONE域名的NS服务器的。
步骤S109，检查DNS响应是否是REFUSED。这里是检查步骤S108中的DNS响应内容，查看其DNS状态码是否是REFUSED，如果是的话，直接返回高风险；否则进入步骤S110。这个步骤背后的技术原理是，每个域的NS服务器中，都有此域的DNS ZONE文件，如果向此NS服务器查询它不负责解析的域的DNS记录，那么就会返回REFUSED，表示拒绝服务。
如果到达这个步骤，说明在DNS系统中，树形节点还在，上一层级的节点仍然指向本级节点，但是本级节点内部，已经删除了目标域的配置。这种情况本质上属于一种配置错误，上层级节点指向本层级的记录是保存在上层级节点中的，这个配置信息，是在域名服务商那里进行配置，就是配置域名的NS记录，而具体的DNS资源记录是在NS服务器里面进行配置的，NS记录指向了NS服务器的域名。
步骤S110，获取DNS响应中NS的值，记做NS_2。这里是对步骤S108中的DNS响应内容做解析，因为步骤S108是查询的NS记录，所以DNS响应内容也是NS记录，把这个NS值记做NS_2。
此步骤背后的原理是，域名的NS记录在DNS树形系统中会存在两份，一份在上一级NS服务器中，一份在本层级NS服务器中。比如目标域名是www.example.com,对应的域是example.com,对应的NS是ns.example.com；上一级NS是ns.com，负责的域是com.，那么这一条NS记录“example.com IN NS ns.example.com”会同时出现在ns.com这台NS服务器的配置中，以及ns.example.com这台NS服务器的配置中。我们获取的NS_1就是从ns.com这台NS服务器中获取到的NS记录，这里的NS_2就是从ns.example.com这台NS服务器中获取到的NS记录，使用dig工具执行的命令如下所示：
获取NS_1:dig example.com ns@ns.com
获取NS_2:dig example.com ns@ns.example.com
在一些英文技术文献中，把NS_1叫做parent NS,把NS_2叫做local NS。其中NS_2记录是很特殊的一条记录，它必须配置，而且要和NS_1保持一致，但是在正常的DNS解析过程中并不发挥作用，也就是说如果NS_2和NS_1不一致，那么DNS解析时是以NS_1为准的。
步骤S111，检查NS_1和NS_2是否相同，如果相同，则进入步骤S112，否则返回中风险。这里的NS_1和NS_2都代表了目标域名的权威域名服务器，也就是NS服务器，不过NS_1是通过在DNS系统树形结构中递归查询时，查询上级节点得到的，而NS_2是直接向目标域名的NS服务器查询得到的。如果这两 个值相同，则说明NS记录配置没有问题，进入步骤S112继续进行其它检查，反之则说明有配置错误，这里正常情况下，NS_1和NS_2是一致的，如果不一致，则说明出现了配置错误，NS_1是在域名服务商那里进行配置的NS记录，NS_2是在自己负责的NS服务器里配置的NS记录。
步骤S112，检查NS_1是否是DOMAIN_1的子域名，此步骤是确定目标域名的NS服务器域名是否是NS服务器所负责的DNS ZONE域的子域名。举例来说，如果example.com的NS记录是ns.example.com，那么就属于这种情况，如果example.com的NS记录是ns.nowhere.com，那么就不属于这种情况。如果是的话，则进入步骤S113继续检查，否则返回无风险。这里背后的原理是，如果一个域名的NS记录是自己的子域名，那么就会引入胶水记录，就要检查胶水记录在上级节点中和当前节点中的配置是否一致，如果不一致则说明有配置错误，有域名接管漏洞。
举例来说，目标域名为www.example.com对应的NS服务器域名是ns.example.com，NS服务器的IP地址是1.1.1.1，负责的域是example.com,上级NS是ns.com,负责的域是com.,此时胶水记录是“ns.example.com IN A1.1.1.1”，这条DNS记录同时存在于ns.com这台NS服务器上，和ns.example.com这台NS服务器上。
步骤S113，向NS_0查询NS_1的DNS A记录，记做IP_0。此步骤就是向上级节点，查询本级节点的胶水记录，举例来说，如果example.com的NS记录是ns.example.com，上级节点com的NS记录是ns.com，这里执行的操作就是向ns.com查询ns.example.com的IP地址,使用dig工具的命令为“dig ns.example.com@ns.com”。
步骤S114，向NS_1查询NS_1的DNS A记录，记做IP_1。此步骤就是向本级节点，查询本级节点的IP地址，举例来说，如果example.com的NS记录是ns.example.com，这里执行的操作就是向ns.example.com查询ns.example.com的IP地址。步骤S113种的IP_0其实就是胶水记录，而这里的IP_1其实就是在本级NS服务器查询对应的胶水记录，使用dig命令查询为“dig  ns.example.com@ns.example.com”。需要注意的是，向本级NS查询NS的目标域名的DNS A记录，返回结果中会自动携带上级NS的胶水记录，参考图4所示代码，因为在确定NS的IP地址的过程中会有一个递归查询过程，此过程会查询上级NS服务器。
步骤S115，检查IP_0是否等于IP_1，这里是比较从步骤S113中获取的IP_0和步骤S114中的IP_1是否相等。IP_0来源于上级NS节点的胶水记录，IP_1来源于本级NS节点的配置记录，IP_0和IP_1如果数量是多个的话，则进行集合比较，即比较两个集合是否相等。正常情况下二者应该是一致的，返回无漏洞；如果二者不一致，说明出现了DNS配置错误，存在域名接管漏洞。
实施例3：
如图5所示，是本发明实施例的域名接管漏洞的检测装置的架构示意图。本实施例的域名接管漏洞的检测装置包括一个或多个处理器21以及存储器22。其中，图5中以一个处理器21为例。
处理器21和存储器22可以通过总线或者其他方式连接，图5中以通过总线连接为例。
存储器22作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序和非易失性计算机可执行程序，如实施例1中的域名接管漏洞的检测方法。处理器21通过运行存储在存储器22中的非易失性软件程序和指令，从而执行域名接管漏洞的检测方法。
存储器22可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中，存储器22可选包括相对于处理器21远程设置的存储器，这些远程存储器可以通过网络连接至处理器21。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
所述程序指令/模块存储在所述存储器22中，当被所述一个或者多个处理器21执行时，执行上述实施例1中的域名接管漏洞的检测方法，例如，执行以上描述的图2和图3所示的各个步骤。
值得说明的是，上述装置和系统内的模块、单元之间的信息交互、执行过程等内容，由于与本发明的处理方法实施例基于同一构思，具体内容可参见本发明方法实施例中的叙述，此处不再赘述。
本领域普通技术人员可以理解实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器(ROM，Read Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁盘或光盘等。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (10)

  1. 一种域名接管漏洞的检测方法，其特征在于，包括：
    向递归解析服务器查询目标域名DNS A记录；
    获取DNS的响应报文，检查其DNS响应状态码是SERVFAIL时,向NS服务器查询目标域名DNS A记录；
    获取第一NS服务器返回的查询到目标域名DNS A记录的结果，将所述第一NS服务器，记做NS_1；把NS_1服务器负责的域，记做DOMAIN_1；把所述第一NS服务器上一级的NS服务器记做NS_0；
    其中，DOMAIN_1和NS_1会出现在NS_0服务器的DNS响应内容中，NS_0的DNS响应内容就是一条NS记录，表明DOMAIN_1的NS服务器是NS_1；
    向NS_1服务器查询DOMAIN_1的DNS NS记录，并根据获取到的DNS NS记录和NS_1进行比对,若不匹配则认定为存在域名接管漏洞。
  2. 根据权利要求1所述的域名接管漏洞的检测方法，其特征在于，向NS_1服务器查询DOMAIN_1的DNS NS记录，如果返回的DNS响应状态码为REFUSED，则认定为存在域名接管漏洞。
  3. 根据权利要求1所述的域名接管漏洞的检测方法，其特征在于，所述方法还包括：
    向NS_0查询NS_1的DNS A记录，记做IP_0；
    向NS_1查询NS_1的DNS A记录，记做IP_1；
    检查IP_0是否等于IP_1，若一致，则说明无漏洞；若不一致，则说明存在域名接管漏洞。
  4. 根据权利要求1所述的域名接管漏洞的检测方法，其特征在于，所述向NS服务器查询目标域名DNS A记录，具体包括：
    若查询的NS服务器是负责目标域名DNS A解析的NS服务器，那么作为第 一NS服务器返回的查询到DNS A记录的结果；
    若查询的NS服务器，并不是负责目标域名DNS A解析的NS服务器，而是根服务器，或者顶级域名服务器，则会返回NS记录，以便DNS请求客户端根据所述NS记录向下一级NS服务器发送。
  5. 根据权利要求4所述的域名接管漏洞的检测方法，其特征在于，以递归的方式逐级获取NS服务器，直到抵达所述第一NS服务器，所述获取第一NS服务器返回的查询到DNS A记录的结果，具体为：如果正常解析，返回结果为目标域名的DNS A记录解析得到的IP地。
  6. 根据权利要求5所述的域名接管漏洞的检测方法，其特征在于，方法还包括：如果解析失败，返回结果为NXDOMAIN或SERVFAIL状态码。
  7. 根据权利要求1-6任一所述的域名接管漏洞的检测方法，其特征在于，所述状态码是SERVFAIL时，具体为：递归解析服务器不能联网、DNSSEC校验未通过、NS服务器不可达、NS服务器上没有对应域名的DNS ZONE文件中的一种或者多种。
  8. 根据权利要求1-6任一所述的域名接管漏洞的检测方法，其特征在于，所述向递归解析服务器查询DNS A记录，是由域名接管漏洞检测设备发起。
  9. 根据权利要求8所述的域名接管漏洞的检测方法，其特征在于，域名接管漏洞检测设备搜集有网络中的DNS记录，并通过周期性的向递归解析服务器逐条查询DNS记录方式完成域名接管漏洞的检测。
  10. 一种域名接管漏洞的检测装置，其特征在于，所述装置包括：
    至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中， 所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述处理器执行，用于执行权利要求1-9任一所述的域名接管漏洞的检测方法。
PCT/CN2021/135680 2021-09-16 2021-12-06 一种域名接管漏洞的检测方法和装置 WO2023040070A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202111085914.9 2021-09-16
CN202111085914.9A CN113839938B (zh) 2021-09-16 2021-09-16 一种域名接管漏洞的检测方法和装置

Publications (1)

Publication Number Publication Date
WO2023040070A1 true WO2023040070A1 (zh) 2023-03-23

Family

ID=78959504

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/135680 WO2023040070A1 (zh) 2021-09-16 2021-12-06 一种域名接管漏洞的检测方法和装置

Country Status (2)

Country Link
CN (1) CN113839938B (zh)
WO (1) WO2023040070A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230130115A1 (en) * 2021-10-26 2023-04-27 Palo Alto Networks, Inc. Inline identify and block dangling dns records

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104113447A (zh) * 2014-07-10 2014-10-22 北京蓝汛通信技术有限责任公司 监测域名解析污染的方法、装置及系统
US20170171242A1 (en) * 2015-12-15 2017-06-15 Microsoft Technology Licensing, Llc Defense against nxdomain hijacking in domain name systems
CN107222492A (zh) * 2017-06-23 2017-09-29 网宿科技股份有限公司 一种dns防攻击方法、设备和系统
CN110493224A (zh) * 2019-08-20 2019-11-22 杭州安恒信息技术股份有限公司 一种子域名劫持漏洞探测方法、装置及设备
CN110572390A (zh) * 2019-09-06 2019-12-13 深圳平安通信科技有限公司 检测域名劫持的方法、装置、计算机设备和存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104113447A (zh) * 2014-07-10 2014-10-22 北京蓝汛通信技术有限责任公司 监测域名解析污染的方法、装置及系统
US20170171242A1 (en) * 2015-12-15 2017-06-15 Microsoft Technology Licensing, Llc Defense against nxdomain hijacking in domain name systems
CN107222492A (zh) * 2017-06-23 2017-09-29 网宿科技股份有限公司 一种dns防攻击方法、设备和系统
CN110493224A (zh) * 2019-08-20 2019-11-22 杭州安恒信息技术股份有限公司 一种子域名劫持漏洞探测方法、装置及设备
CN110572390A (zh) * 2019-09-06 2019-12-13 深圳平安通信科技有限公司 检测域名劫持的方法、装置、计算机设备和存储介质

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230130115A1 (en) * 2021-10-26 2023-04-27 Palo Alto Networks, Inc. Inline identify and block dangling dns records

Also Published As

Publication number Publication date
CN113839938A (zh) 2021-12-24
CN113839938B (zh) 2022-07-08

Similar Documents

Publication Publication Date Title
US11606388B2 (en) Method for minimizing the risk and exposure duration of improper or hijacked DNS records
US11310132B2 (en) System and method of identifying internet-facing assets
US9300623B1 (en) Domain name system cache integrity check
AU2020386847B2 (en) Asset search and discovery system using graph data structures
US9628442B2 (en) DNS snooping to create IP address-based trust database used to select deep packet inspection and storage of IP packets
US9053320B2 (en) Method of and apparatus for identifying requestors of machine-generated requests to resolve a textual identifier
US10708226B2 (en) Domain name resolution
CN110855636B (zh) 一种dns劫持的检测方法和装置
US20090320131A1 (en) Method and System for Preventing Malicious Communication
US10469499B2 (en) Website filtering using bifurcated domain name system
CN110324295A (zh) 一种域名系统泛洪攻击的防御方法和装置
WO2023040070A1 (zh) 一种域名接管漏洞的检测方法和装置
CN114666245A (zh) B/S系统的IPv6单栈支持度确定方法及相关设备
US12041095B2 (en) System and method for DNS misuse detection
US10462180B1 (en) System and method for mitigating phishing attacks against a secured computing device
Zhang et al. ResolverFuzz: Automated Discovery of DNS Resolver Vulnerabilities with Query-Response Fuzzing
Liao et al. A comprehensive study of dns operational issues by mining dns forums
CN116938875A (zh) 域名检测方法、域名解析器、电子设备和存储介质
KR101645222B1 (ko) 어드밴스드 도메인 네임 시스템 및 운용 방법
CN115913583A (zh) 业务数据访问方法、装置和设备及计算机存储介质
US20240297837A1 (en) Detecting and alerting on dns related risk of data tampering
Naab et al. Gotta Query'Em All, Again! Repeatable Name Resolution with Full Dependency Provenance
CN115665086A (zh) 基于网管设备的域名解析方法及其装置、电子设备
CN116866306A (zh) 域名的解析方法及装置、相关设备
Schomp Complexity and Security of the Domain Name System

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21957334

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21957334

Country of ref document: EP

Kind code of ref document: A1