Method, electronic device and medium for determining an authoritative domain name root server node
Patent Information
- Application Number
- CN202311280384.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-09-28
- Publication Date
- 2026-10-27
- Estimated Expiration
- 2043-09-28
AI Technical Summary
然而,由于用户并不知道是由哪个域名根服务器节点提供了服务,因此无法知晓是由授权域名根服务器节点还是授权域名根服务器节点提供了服务,因而可能遭受非授权域名根服务器节点带来的安全隐患
[0009]利用根据公开的技术方案,提供了一种用于确定授权域名根服务器节点并且进而确定非授权域名根服务器节点的方法。利用该方法的技术方案,可以基于也可以被称为关键路由点的域名根服务器节点路由信息和域名根服务器节点标识信息来确定预定地区中的授权域名根服务器节点集合,进而确定预定地区中的非授权域名根服务器节点集合,并且还可以对非授权域名根服务器节点集合中的非授权域名根服务器节点进行例如根区文件副本完整性检测、根区文件副本时效性检测和域名系统安全扩展(DNSSEC)可用性检测等安全性检测,从而可以减少非授权域名根服务器节点对使用域名系统服务的用户所造成的安全隐患,进而可以提高使用域名系统服务的用户的用户体验。
Smart Images

Figure CN117278293B_ABST
Abstract
Description
Technical Field
[0001] The embodiments of this disclosure generally relate to the field of Internet technology, and more particularly to methods, electronic devices, and non-transient computer-readable media for determining authorized domain name root server nodes. Background Technology
[0002] The Domain Name System (DNS) is one of the most important infrastructures of the Internet. It not only provides the mapping function from domain names to Internet Protocol (IP) addresses, but also provides the security foundation for Internet applications such as domain name certificate authorization and email. Domain name resolution is the process of converting domain names back into IP addresses, which is usually performed by intelligent DNS servers. The root servers of the DNS system, also known as root name servers or domain root servers, are located at the top of the hierarchical structure of the domain name space and are the starting point for almost all domain name resolution processes, making them crucial to the security and stability of the Internet.
[0003] Root name servers employ an anycast mechanism to ensure their stability and security. Specifically, the root zone files of the root name servers are managed uniformly by the Internet Assigned Numbers Authority (IANA). Thirteen root server identifiers, represented by the letters A through M, have been established for each root name server, and their operation and management are handled by 12 independent organizations. VeriSign manages two identifiers. Since 2002, these organizations have gradually adopted anycast technology to deploy root name server nodes globally to ensure the stability and security of domain name resolution. Root name server nodes can also be called root server instances or root nodes, and can be understood as mirrors of root name servers. These nodes are authorized and published by IANA and the aforementioned 12 organizations, and are located worldwide. Therefore, queries for the 13 root server identifiers can be routed to approximately 1700 root name server nodes globally for resolution, but generally, users are unaware of which root name server node is providing the service.
[0004] In addition to the officially authorized root server nodes mentioned above, some ISPs or network tenants may maintain their own unauthorized root server nodes. However, since users do not know which root server node is providing the service, they cannot determine whether the service is provided by an authorized root server node or not, and therefore may suffer from security risks posed by unauthorized root server nodes. Summary of the Invention
[0005] Embodiments of this disclosure provide methods, electronic devices, and non-transient computer-readable media for determining authorized domain name root server nodes.
[0006] In a first aspect of this disclosure, a method for determining authoritative domain name root server nodes is provided, the method comprising: sending a set of tasks related to obtaining identity identifiers of domain name root server nodes in a set of domain name root server nodes via a set of task interaction nodes, wherein the set of task interaction nodes and the set of domain name root server nodes are located in a predetermined region; obtaining a set of responses made by the set of domain name root server nodes to the set of tasks via the set of task interaction nodes, the response set including a set of identity identifiers of domain name root server nodes; and determining the set of authoritative domain name root server nodes in the set of domain name root server nodes based on the set of identity identifiers if the number of identity identifiers in the identity identifier set exceeds a first threshold number of identity identifiers.
[0007] In a second aspect of this disclosure, an electronic device is provided. The electronic device includes: at least one processing unit; and at least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit. When executed by the at least one processing unit, the instructions cause the device to perform actions, including: sending a set of tasks related to obtaining the identity identifiers of domain name root server nodes in a set of domain name root server nodes via a set of task interaction nodes, wherein the set of task interaction nodes and the set of domain name root server nodes are located in a predetermined region; obtaining a set of responses from the set of domain name root server nodes to the task set via the set of task interaction nodes, the response set including a set of identity identifiers of the domain name root server nodes; and determining a set of authorized domain name root server nodes in the set of domain name root server nodes based on the set of identity identifiers if the number of identity identifiers in the identity identifier set exceeds a first threshold number of identity identifiers.
[0008] In a third aspect of this disclosure, a non-transitory computer-readable medium is provided. This non-transitory computer-readable medium stores machine-executable instructions that, when executed, cause a machine to perform any step of the method described in the first aspect of this disclosure.
[0009] Based on a publicly available technical solution, a method is provided for determining authoritative domain name root server nodes and, consequently, non-authoritative domain name root server nodes. This method determines the set of authoritative domain name root server nodes in a predetermined region based on routing information and identification information of the domain name root server nodes, also known as key routing points. Furthermore, it performs security checks on the non-authoritative domain name root server nodes in the non-authoritative domain name root server node set, such as root zone file copy integrity checks, root zone file copy timeliness checks, and Domain Name System Security Extensions (DNSSEC) availability checks. This reduces the security risks posed by non-authoritative domain name root server nodes to users of Domain Name System services, thereby improving the user experience.
[0010] The summary section is provided to present the chosen concepts in a simplified form, which will be further described in the detailed description below. The summary section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of the embodiments of this disclosure. Attached Figure Description
[0011] The above and other objects, features and advantages of this disclosure will become more apparent from the accompanying drawings, in which like reference numerals generally denote like parts.
[0012] Figure 1 A schematic diagram of an environment 100 for determining authoritative domain name root server nodes, in which some embodiments of the present disclosure may be implemented, is shown;
[0013] Figure 2 A flowchart of a method 200 for determining an authoritative domain name root server node according to an embodiment of the present disclosure is shown;
[0014] Figure 3 A schematic block diagram of an apparatus 300 for determining an authorized domain name root server node according to an embodiment of the present disclosure is shown.
[0015] Figure 4 A schematic diagram of another environment 400 for determining authoritative domain name root server nodes, in which some embodiments of this disclosure may be implemented, is shown;
[0016] Figure 5 A flowchart of another method 500 for determining an authoritative domain name root server node according to an embodiment of the present disclosure is shown; and
[0017] Figure 6A schematic block diagram of an example device 600 that can be used to implement embodiments of the present disclosure is shown.
[0018] In the various figures, the same or corresponding reference numerals indicate the same or corresponding parts. Detailed Implementation
[0019] Preferred embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While preferred embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that the present disclosure will be thorough and complete, and will fully convey the scope of the present disclosure to those skilled in the art.
[0020] The term "comprising" and its variations as used herein indicate an open-ended inclusion, for example, "including but not limited to". Unless otherwise stated, the term "or" means "and / or". The term "based on" means "at least partially based on". The terms "an example embodiment" and "an embodiment" mean "at least one embodiment". The term "another embodiment" means "at least one additional embodiment". The terms "first", "second", etc., may refer to different or the same objects. Other explicit and implicit definitions may also be included below.
[0021] As described in the background section above, queries for the 13 root server identifiers can be routed to authoritative domain name root server nodes for resolution. However, some ISPs or network tenants may also maintain their own non-authoritative domain name root server nodes. Since users do not know which domain name root server node provides the service, they cannot determine whether the service is provided by an authoritative domain name root server node or not, and therefore may be vulnerable to security risks posed by non-authoritative domain name root server nodes.
[0022] Specifically, because the services provided by authorized root server nodes are public and can be referred to as root zone copies, non-authoritative root server nodes can be easily constructed by replicating the services of authorized root nodes. Non-authoritative root server nodes typically only serve the region where they are located. Since non-authoritative root server nodes are outside the management of the official root name server system, they possess considerable power. For example, they can control the entire domain name space of users within their influence area, tamper with domain name resolution results, and even further manipulate user network traffic. Therefore, non-authoritative root server nodes pose a series of security risks. Thus, identifying authorized root server nodes, and subsequently non-authoritative root server nodes, determining their deployment locations, and detecting their security vulnerabilities are crucial for maintaining the stable operation of the Internet and ensuring network security.
[0023] Currently, both academia and industry lack the technology to detect unauthorized root server nodes. On one hand, unauthorized root server nodes often employ transparent route hijacking or response snatching to take over user domain name resolution requests to the root server node. This transparent hijacking not only makes it undetectable to users but also evades detection to some extent. On the other hand, the behavior of unauthorized root server nodes can be very similar to that of authorized root server nodes, and they do not necessarily engage in malicious behavior. Therefore, distinguishing between unauthorized and authorized root server nodes in the context of anycast deployment is challenging. In 2016, foreign researchers proposed a method to identify unauthorized root server nodes using resolution latency. This method targeted the B root name server, taking advantage of the fact that the B root name server had not yet adopted anycast deployment at that time. However, since 2017, all 13 root servers have adopted anycast deployment, rendering this method ineffective. Therefore, there is currently no technology for detecting both authorized and unauthorized root server nodes.
[0024] To at least partially address one or more of the aforementioned problems and other potential issues, embodiments of this disclosure propose a method for determining authoritative domain name root server nodes and, consequently, non-authoritative domain name root server nodes. This method allows for the determination of a set of authoritative domain name root server nodes in a predetermined region based on root server node routing information and root server node identification information. Furthermore, it enables security checks on the non-authoritative root server nodes within the non-authoritative root server node set, thereby reducing security risks posed by non-authoritative root server nodes to users of Domain Name System (DNS) services and ultimately improving the user experience.
[0025] Figure 1 A schematic diagram is shown of an environment 100 for determining authoritative domain name root server nodes, in which some embodiments of the present disclosure may be implemented. According to embodiments of the present disclosure, the environment 100 for determining authoritative domain name root server nodes may be a cloud environment.
[0026] like Figure 1As shown, the environment 100 used to determine the authoritative domain name root server nodes includes a computing device 110 and regions 1 120, 2 130, and 3 140. Region 1 120 includes task interaction nodes 121-1, 121-2, and 121-3, which can also be referred to as exit nodes, and domain name root server nodes 122-1 and 122-2. Task interaction nodes 121-1, 121-2, and 121-3 can be collectively referred to as task interaction node 121, and domain name root server nodes 122-1 and 122-2 can be collectively referred to as domain name root server node 122. Region 2 130 includes task interaction nodes 131-1, 131-2, and 131-3, and domain name root server nodes 132-1, 132-2, and 132-3. Task interaction nodes 131-1, 131-2, and 131-3 can be collectively referred to as task interaction node 131, and domain name root server nodes 132-1, 132-2, and 132-3 can be collectively referred to as domain name root server node 132. Region 3 140 includes task interaction node 141, and domain name root server nodes 142-1 and 142-2. Domain name root server nodes 142-1 and 142-2 can be collectively referred to as domain name root server node 142.
[0027] It should be understood that, Figure 1 The three regions, seven task interaction nodes, and eight domain name root server nodes shown are for illustrative purposes only. Depending on the actual situation, the environment 100 used to determine the authoritative domain name root server nodes may include more or fewer regions, task interaction nodes, and domain name root server nodes, and each region may also include more or fewer task interaction nodes and domain name root server nodes. According to embodiments of this disclosure, the computing device 110 may be, for example, a desktop computer or a server, and may be physical or virtual.
[0028] like Figure 1 As shown, the computing device 110 can interact with seven task interaction nodes located in three regions, and each task interaction node in a region can interact with a domain name root server node in the same region.
[0029] According to some embodiments of this disclosure, computing device 110 can send tasks related to obtaining the identity identifiers, also referred to as fingerprints, of domain name root server nodes 122, 132, and 142 via task interaction nodes 121, 131, and 141, and can obtain responses from domain name root server nodes 122, 132, and 142 to the tasks via task interaction nodes 121, 131, and 141. The responses include the identity identifiers of domain name root server nodes 122, 132, and 142, and computing device 110 can determine, based on the identity identifiers, which of the domain name root server nodes 122, 132, and 142 are authoritative domain name root server nodes, and further determine the non-authoritative domain name root server nodes among the domain name root server nodes 122, 132, and 142.
[0030] Subsequently, according to some embodiments of this disclosure, the computing device 110 may also perform security checks on the identified unauthorized domain name root server nodes among the domain name root server nodes 122, 132 and 142.
[0031] According to embodiments of this disclosure, in Figure 1 In the environment 100 shown for determining the root server nodes of the authoritative domain name, the interactions between the computing device 110 and the task interaction nodes 121, 131 and 141, as well as the interactions between the task interaction nodes 121, 131 and 141 and the root server nodes 122, 132 and 142, can all be conducted over the network.
[0032] Figure 2 A flowchart of a method 200 for determining an authoritative domain name root server node according to an embodiment of the present disclosure is shown. The method 200 for determining an authoritative domain name root server node can be implemented by a computing device 110 in an environment 100 for determining authoritative domain name root server nodes, or by other suitable devices. It should be understood that the method 200 for determining an authoritative domain name root server node may also include additional steps not shown and / or the steps shown may be omitted, and the scope of the embodiments of the present disclosure is not limited in this respect. The specific steps of the method 200 for determining an authoritative domain name root server node are described below using examples of the computing device 110 in the environment 100 for determining authoritative domain name root server nodes, regions 1 120, 2 130 and 3 140, task interaction nodes 121, 131 and 141 in the regions, and domain name root server nodes 122, 132 and 142.
[0033] In box 202, computing device 110 sends a set of tasks related to obtaining the identity of the domain name root server node in the set of domain name root server nodes via a set of task interaction nodes.
[0034] According to embodiments of this disclosure, the task interaction node set may include, for example, task interaction nodes 121, 131, and 141 located in one or more regions, and the domain name root server node set may include, for example, domain name root server nodes 122, 132, and 142 located in one or more regions. Since a task interaction node in a region only interacts with a domain name root server node in the same region, the task interaction node set and the domain name root server node set are located in the same one or more regions.
[0035] According to embodiments of this disclosure, computing device 110 may determine the correctness test of task interaction nodes in the task interaction node set before sending a task set related to obtaining the identity of the domain name root server node in the domain name root server node set via the task interaction node set.
[0036] For example, if computing device 110 is to send a set of tasks related to obtaining the identity of domain name root server nodes 122-1 and 122-2 in region 1 120 via task interaction node 121-1 in region 1 120, it can first initiate a customized query to a predetermined domain name system server through task interaction node 121-1 to perform a correctness test on task interaction node 121-1, and after task interaction node 121-1 passes the correctness test, it can then send the set of tasks related to obtaining the identity of domain name root server nodes 122-1 and 122-2 in region 1 120 via task interaction node 121-1.
[0037] According to embodiments of this disclosure, computing device 110 can perform a correctness test on task interaction node 121-1 by determining that task interaction node 121-1 can correctly execute a set of functions. The set of functions may include, for example, the following: initiating a Domain Name System (DNS) query to a specified Internet Protocol (IP) address; receiving a corresponding DNS response from a specified IP address; supporting the sending of EDNS0 extended messages; supporting the sending of CHAOS type messages; supporting the modification of the Time-to-Live (TTL) field in the IP header of a DNS message; and supporting the sending of messages related to DNS security extensions.
[0038] In box 204, computing device 110 obtains a set of responses from the set of domain name root server nodes to the task set via a set of task interaction nodes. According to embodiments of this disclosure, the response set includes a set of identity identifiers of the domain name root server nodes, and the identity identifiers of the domain name root server nodes can be used to distinguish different domain name root server nodes.
[0039] According to some embodiments of this disclosure, the identity of a domain name root server node may include domain name root server node routing information and domain name root server node identification information. Since the domain name root server node routing information and domain name root server node identification information of authorized domain name root server nodes are not publicly disclosed, they can be obtained through the following methods.
[0040] The computing device 110 can obtain domain name root server node routing information, for example, by including a DNS-based route tracing task in the set of tasks sent.
[0041] Unlike traditional route tracing based on Internet Control Message Protocol (ICMP) and User Datagram Protocol (UDP), DNS-based route tracing methods can more accurately trace the routing path of DNS traffic. For example, a DNS-based route tracing task may include issuing measurement messages, and these measurement messages may still be DNS messages. However, according to some embodiments of this disclosure, in the DNS message issued by computing device 110, the Time-to-Live (TTL) field in the IP header of the DNS message can be modified to increment sequentially from 1 until the set of domain name root server nodes responds to the task set with a return message or the maximum value of 64 is reached.
[0042] Unlike traditional route tracing methods, the route tracing method used in this disclosure sends messages with normal application-layer functionality. Therefore, when passing through middleware, they are processed as DNS messages, and thus are more likely to reflect the true routing path of DNS traffic compared to traditional route tracing methods.
[0043] During the DNS-based route tracing task, computing device 110 can sequentially initiate DNS-based route tracing to the 13 root server letters. The obtained domain name root server node routing information can be represented by a tuple p =<root_letter,penultimate_hop> This indicates that `root_letter` is the identifier letter of the root name server being tested, and `penultimate_hop` is the IP address of the penultimate hop in the route tracing path. If the penultimate hop IP address is not obtained within a preset time, `penultimate_hop` can also be a timeout.
[0044] According to some embodiments of this disclosure, computing device 110 may obtain domain name root server node identification information, for example, by including a special DNS request task, such as a DNS server identification request, in the set of tasks sent.
[0045] Authoritative domain name root server nodes can correctly identify and respond to DNS server identifier requests, and the server identifiers of authoritative domain name root server nodes follow strict naming conventions. Therefore, four types of DNS server identifiers can be detected: server.id, hostname.bind, version.bind, and nsid.
[0046] During the process of sending a DNS server identifier request, computing device 110 can sequentially send requests for the aforementioned four types of DNS server identifiers to the 13 root server letters. The obtained domain name root server node identifier information can be represented by a triple i =<root_letter,type,response> This indicates that root_letter is the identifier letter of the root name server being tested, type is one of the four types of DNS server identifiers mentioned above, and response is the response of the server of the domain name root server node. This response can be a server identifier string or an unresolved raw response message.
[0047] In box 206, computing device 110 determines whether the number of identity identifiers in the identity identifier set obtained in box 204 exceeds a first threshold number of identity identifiers, and if the number of identity identifiers exceeds the first threshold number of identity identifiers, computing device 110 determines the set of authorized domain name root server nodes in the domain name root server node set based on the identity identifier set.
[0048] As mentioned earlier, there are currently around 1700 authorized domain name root server nodes, and the number of authorized domain name root server nodes located in a particular region is usually smaller. For example, there are 8 authorized domain name root server nodes in the Beijing area and 1 authorized domain name root server node in the Shenyang area.
[0049] Furthermore, according to embodiments of this disclosure, since authorized domain name root server nodes are generally quite standardized, the identity identifiers obtained for the same authorized domain name root server node are the same or equivalent for the multiple tasks sent by the computing device 110 related to obtaining the identity identifiers of the domain name root server nodes in the set of domain name root server nodes.
[0050] Furthermore, since the number of authorized domain name root server nodes is usually much greater than the number of non-authoritative domain name root server nodes, the number of identity identifiers for authorized domain name root server nodes in the identity identifier set obtained by computing device 110 will also be much greater than the number of identity identifiers for non-authoritative domain name root server nodes. For example, if the obtained identity identifier set includes 10,000 identity identifiers, it is possible that 9,995 identity identifiers correspond to authorized domain name root server nodes, while only 5 identity identifiers correspond to non-authoritative domain name root server nodes.
[0051] Therefore, once the number of identity identifiers in the identity identifier set reaches a certain scale, it becomes possible to distinguish which identity identifiers correspond to authorized domain name root server nodes and which identity identifiers correspond to non-authoritative domain name root server nodes (if they exist).
[0052] According to embodiments of this disclosure, the setting of the first threshold number of identifiers can reflect the discrimination accuracy for domain name root server nodes. The larger the first threshold number of identifiers, the greater the discrimination accuracy. However, since the number of tasks sent by the computing device 110 will also be larger, the execution time of the process will be longer. Therefore, the first threshold number of identifiers can be set from 1,000-2,000 to 80,000-100,000, or even millions or more.
[0053] Therefore, according to embodiments of this disclosure, the computing device 110 may not determine the set of authorized domain name root server nodes in the domain name root server node set before obtaining the identity identifiers for the first threshold number of identity identifiers. After the computing device 110 obtains the identity identifiers for the first threshold number of identity identifiers, since the identity identifiers obtained for the same authorized domain name root server node are the same or equivalent, the set of authorized domain name root server nodes in the domain name root server node set can be determined based on the identity identifier set.
[0054] According to some embodiments of this disclosure, in the process of determining the set of authorized domain name root server nodes in the set of domain name root server nodes based on the set of identity identifiers, the computing device 110 may first determine the following subset of identity identifiers in the set of identity identifiers, wherein the identity identifiers in the subset of identity identifiers are the same or equivalent. Then, if the number of identity identifiers in the subset of identity identifiers exceeds a second threshold number of identity identifiers, the domain name root server node corresponding to the identity identifier in the subset of identity identifiers is determined as the authorized domain name root server node.
[0055] As mentioned earlier, since the number of authorized domain name root server nodes is usually much greater than the number of unauthorized domain name root server nodes, the number of authorized domain name root server node identity identifiers in the identity identifier set acquired by computing device 110 will also be much greater than the number of unauthorized domain name root server node identity identifiers. Therefore, if the number of identity identifiers in the identity identifier subset is too small, it is possible that the identity identifier subset corresponds to an unauthorized domain name root server node. Therefore, a second threshold identity identifier number can be set to avoid misidentifying unauthorized domain name root server nodes as authorized domain name root server nodes. According to embodiments of this disclosure, the second threshold identity identifier number can be set based on the first threshold identity identifier number, and can be set to a fraction of the first threshold identity identifier number based on the number of authorized domain name root server nodes in the region to be detected. For example, if there are 10 authorized domain name root server nodes in the same region, the second threshold identity identifier number can be set to a number less than one-tenth of the first threshold identity identifier number, for example, to one-twentieth to one-eleventh of the first threshold identity identifier number.
[0056] According to embodiments of this disclosure, the equivalence of two corresponding identity identifiers for two domain name root server nodes may include equivalent domain name root server node routing information for the two identity identifiers and identical domain name root server node identification information. Furthermore, the equivalence of domain name root server node routing information for the two identity identifiers may include one of the following: the domain name root server node routing information is completely identical; the domain name root server node routing information corresponds to the same Internet Protocol address whose network representation bit width in the subnet mask is 24 bits; and the domain name root server node routing information corresponds to the ISP and geographical location of the Internet Protocol address.
[0057] For example, regarding the routing information of two domain name root server nodes, since it can use...<root_letter,penultimate_hop> Therefore, if the root_letter of the routing information of two domain name root server nodes is the same, and the penultimate_hop of the routing information of two domain name root server nodes is exactly the same, or the IP address is located in the same / 24 network segment, or the IP address is located in the same geographical location and carrier network, then the routing information of the two domain name root server nodes can be considered equivalent.
[0058] Therefore, computing device 110 can determine the set of authoritative domain name root server nodes in the set of domain name root server nodes based on the set of identity identifiers. At this time, computing device 110 can perform performance analysis and security analysis on the authoritative domain name root server nodes in the set of authoritative domain name root server nodes, and can also provide feedback or warnings after performing performance analysis and security analysis.
[0059] According to embodiments of this disclosure, after determining the set of authorized domain name root server nodes in a set of domain name root server nodes in a region based on the set of identity identifiers, the computing device 110 can further determine the set of unauthorized domain name root server nodes in the same region.
[0060] According to some embodiments of this disclosure, computing device 110 may further send a first task related to obtaining the identity of a domain name root server node in the domain name root server node set from a first task interaction node in the task interaction node set.
[0061] Then, the computing device 110 can obtain the first response made by the first domain name root server node in the set of domain name root server nodes to the first task, and the first response includes the first identity identifier of the first domain name root server node.
[0062] Furthermore, the computing device 110 can determine whether the first identity identifier is the same as the identity identifier of any authorized domain name root server node in the set of authorized domain name root server nodes. If the first identity identifier is different from the identity identifier of any authorized domain name root server node in the set of authorized domain name root server nodes, the computing device 110 determines the first domain name root server node as a non-authoritative domain name root server node. This is because, after identifying all authorized domain name root server nodes in a region, if it is further found that the identity identifier of a certain domain name root server node is different from the identity identifiers of all authorized domain name root server nodes, then this domain name root server node will be a non-authoritative domain name root server node.
[0063] Therefore, the purpose of these embodiments is to determine non-authoritative domain name root server nodes by sending a new task. This can be applied to situations where, during the previous confirmation process, all domain name root server nodes in a region were found to be authoritative domain name root server nodes. In this case, based on the already determined set of authoritative domain name root server nodes, a new task can be sent to detect whether any new non-authoritative domain name root server nodes exist in this region.
[0064] According to other embodiments of this disclosure, computing device 110 can determine whether the second identity of a second domain name root server node in the set of domain name root server nodes is the same as the identity of any authorized domain name root server node in the set of authorized domain name root server nodes. If the second identity is different from the identity of any authorized domain name root server node in the set of authorized domain name root server nodes, computing device 110 can determine the second domain name root server node as a non-authoritative domain name root server node. This is because, after all authorized domain name root server nodes in a region have been identified, the domain name root server nodes in the set of domain name root server nodes in that region that have not been identified as authorized domain name root server nodes will be non-authoritative domain name root server nodes.
[0065] Therefore, the purpose of these embodiments is to determine non-authoritative domain name root server nodes based on tasks that have already been sent. This can be applied to situations where other domain name root server nodes exist in a set of domain name root server nodes within a region, in addition to the authorized domain name root server nodes. In this case, based on the determined set of authorized domain name root server nodes, the identity information of the domain name root server nodes not identified as authorized domain name root server nodes can be used to determine whether these domain name root server nodes are non-authoritative domain name root server nodes.
[0066] According to some embodiments of this disclosure, after determining the root server node of an unauthorized domain name, the computing device 110 can perform security testing on the determined root server node of the unauthorized domain name. The security testing may include at least one of the following: root zone file copy integrity testing; root zone file copy timeliness testing; and Domain Name System Security Extensions availability testing.
[0067] The root zone file copy is the configuration file for the domain name root server node, and it directly affects the response content provided by the domain name root server node to users. Once the operator of an unauthorized domain name root server node tampers with the root zone file copy, they can completely control the domain name resolution of affected users, and thus hijack other user traffic.
[0068] Therefore, according to embodiments of this disclosure, computing device 110 can send a resolution request for a key domain name (second-level domain name) to a non-authoritative domain name root server node, and after obtaining the authorization information returned by the node, compare the authorization information with the root zone file officially published by IANA to determine whether the root zone file copy of the non-authoritative domain name root server node is complete. If the integrity of the root zone file copy of the non-authoritative domain name root server node is problematic, the potential risk factor of the non-authoritative domain name root server node is high.
[0069] Authoritative domain name root server nodes are typically required to update their root zone file copies promptly. For authoritative domain name root server nodes, once the root zone file is updated, the official root name server system usually immediately executes a dynamic update mechanism, notifying the authoritative domain name root server nodes to update their root zone file copies.
[0070] However, for non-authoritative domain name root server nodes, since they are not located in the official root name server system, their root zone file copies rely on manual updates by the operators. If the root zone file copies are not updated in a timely manner, then when the root zone file changes, if users of non-authoritative domain name root server nodes are still using outdated domain name authorization information, it could potentially lead to service unavailability and security risks.
[0071] Therefore, according to embodiments of this disclosure, computing device 110 can, for example, query a non-authoritative domain name root server node for a non-existent top-level domain (e.g., random_string1.random_string2) to obtain a Start of Authority (SOA) record containing a root zone file copy sequence number. Computing device 110 can then compare this sequence number with the most recently published root zone file sequence number to determine whether the root zone file copy of the non-authoritative domain name root server node is time-sensitive. If the timeliness of the root zone file copy of the non-authoritative domain name root server node is problematic, the potential risk factor of the non-authoritative domain name root server node is high.
[0072] DNSSEC provides integrity authentication for DNS queries and is one of the best practices for preventing domain hijacking and cache poisoning attacks. Furthermore, the root name servers are the starting point of the DNSSEC trust chain. Therefore, if DNSSEC verification on the root name server nodes becomes unavailable, it will create a serious security vulnerability.
[0073] Therefore, according to embodiments of this disclosure, computing device 110 can send a query with a DNSSEC verification request to a non-authoritative domain name root server node to check whether the DNSSEC verification function of the non-authoritative domain name root server node is working properly, that is, whether it has DNSSEC verification availability. The check may include: whether a response is generated, whether DNSSEC is supported, and whether the returned signature information and key information are correct. If the availability of DNSSEC verification of the non-authoritative domain name root server node is problematic, the potential risk factor of the non-authoritative domain name root server node is high.
[0074] See above Figure 1 and Figure 2Details are described of an environment 100 for determining authoritative domain name root server nodes, in which certain embodiments of the present disclosure may be implemented, and a method 200 for determining authoritative domain name root server nodes according to embodiments of the present disclosure. See below for further details. Figure 3 Describe the various modules in apparatus 300 used to determine the root server node of an authorized domain name.
[0075] Figure 3 A schematic block diagram of an apparatus 300 for determining an authoritative domain name root server node according to an embodiment of the present disclosure is shown. Figure 3 As shown, the apparatus 300 for determining authorized domain name root server nodes may include: a first task set sending module 310, configured to send a task set related to obtaining the identity identifiers of domain name root server nodes in the domain name root server node set via a task interaction node set, wherein the task interaction node set and the domain name root server node set are located in a predetermined region; a first response set obtaining module 320, configured to obtain a response set made by the domain name root server node set to the task set via the task interaction node set, the response set including the identity identifier set of the domain name root server nodes; and a first authorized domain name root server node set determining module 330, configured to determine the authorized domain name root server node set in the domain name root server node set based on the identity identifier set if the number of identity identifiers in the identity identifier set exceeds a first threshold number of identity identifiers.
[0076] In one or more embodiments, the first task set sending module 310 includes: a second task set sending module, configured to send the first task in the task set via the first task interaction node if it is determined that the first task interaction node can correctly execute the function set by initiating a customized query to the predetermined domain name system server via the first task interaction node in the task interaction node set.
[0077] In one or more embodiments, the set of functions includes: the ability to initiate a Domain Name System (DNS) query to a specified Internet Protocol (IP) address; the ability to receive a corresponding DNS response from a specified IP address; the ability to support sending EDNS0 extended messages; the ability to support sending CHAOS type messages; the ability to support changing the Time-to-Live (TTL) field in the IP header of a DNS message; and the ability to support sending messages related to DNS security extensions.
[0078] In one or more embodiments, the identity identifiers in the identity identifier set include: domain name root server node routing information; and domain name root server node identification information.
[0079] In one or more embodiments, the first authorized domain name root server node set determination module 330 includes: an identity identifier subset determination module, configured to determine an identity identifier subset in the identity identifier set, wherein the domain name root server node routing information of the identity identifiers in the identity identifier subset is equivalent and the domain name root server node identification information is the same; and an authorized domain name root server node determination module, configured to determine the domain name root server node corresponding to the identity identifier in the identity identifier subset as the authorized domain name root server node if the number of identity identifiers in the identity identifier subset exceeds a second threshold number of identity identifiers.
[0080] In one or more embodiments, the domain name root server node routing information of the identity identifier is equivalent to one of the following: the domain name root server node routing information is exactly the same; the domain name root server node routing information corresponds to the same Internet Protocol address in the subnet mask where the binary number of bits representing the network is 24 bits; and the domain name root server node routing information corresponds to the operator and geographical location of the Internet Protocol address.
[0081] In one or more embodiments, the apparatus 300 for determining authorized domain name root server nodes further includes: a task sending module configured to send a first task related to obtaining the identity identifier of a domain name root server node in the domain name root server node set from a first task interaction node in a task interaction node set; a response obtaining module configured to obtain a first response made by the first domain name root server node in the domain name root server node set to the first task, the first response including a first identity identifier of the first domain name root server node; and a first non-authoritative domain name root server node determining module configured to determine the first domain name root server node as a non-authoritative domain name root server node if the first identity identifier is not the same as the identity identifier of any authorized domain name root server node in the authorized domain name root server node set.
[0082] In one or more embodiments, the apparatus 300 for determining authorized domain name root server nodes further includes: a second non-authoritative domain name root server node determining module, configured to determine the second domain name root server node as a non-authoritative domain name root server node if the second identity identifier of the second domain name root server node in the set of domain name root server nodes is different from the identity identifier of any authorized domain name root server node in the set of authorized domain name root server nodes.
[0083] In one or more embodiments, the apparatus 300 for determining authorized domain name root server nodes further includes: a security detection module configured to perform security detection on non-authoritative domain name root server nodes, the security detection including at least one of the following: root zone file copy integrity detection; root zone file copy timeliness detection; and Domain Name System Security Extensions availability detection.
[0084] Figure 4 A schematic diagram of another environment 400 for determining the root server node of an authorized domain name is shown, in which certain embodiments of the present disclosure may be implemented.
[0085] Figure 4 The environment 400 used to determine the root server nodes for authoritative domain names also includes region 1 120, region 2 130, and region 3 140. Furthermore... Figure 4 Regions 1120, 2130, and 3140, along with the task interaction nodes and domain name root server nodes included therein, are also related to... Figure 1 The same as shown.
[0086] Figure 4 The environment 400 and 400 used to determine the root server node of the authoritative domain name Figure 1 The difference in the environment 100 used to determine the root server node of the authoritative domain name is that it does not include computing device 110, but includes: scheduler 410; hosts 420-1, 420-2, 420-3, 420-4 and 420-5 that interact with scheduler 410 and can be collectively referred to as hosts 420; accounts 430-1 used by host 420-1, accounts 430-2 used by host 420-2, accounts 430-3 used by hosts 420-3 and 420-4 and accounts 430-4 and accounts 430-5 used by host 420-5 that can be collectively referred to as accounts 430; and proxies 440-1 used by accounts 430-1 and 430-2, proxies 440-2 used by accounts 430-3 and 430-4 and proxies 440-3 used by account 430-5 that can be collectively referred to as proxies 440.
[0087] like Figure 4 As shown, hosts 420-1 and 420-2 use proxy 440-1 through accounts 430-1 and 430-2 respectively; hosts 420-3 and 420-4 jointly use proxy 440-2 through account 430-3; and host 420-5 uses proxies 440-2 and 440-3 through two accounts 430-4 and 430-5 respectively. Simultaneously, proxy 440-1 interacts with task interaction nodes 121-1, 121-2, and 121-3 in region 1 120; proxy 440-2 interacts with task interaction nodes 131-1, 131-2, and 131-3 in region 2 130; and proxy 440-3 interacts with task interaction node 141 in region 3 140.
[0088] It should be understood that, Figure 4The diagram showing one scheduler, five hosts, five accounts, three proxies, three regions, seven task interaction nodes, and eight domain name root server nodes is for illustrative purposes only. Depending on the actual situation, the environment 400 used to determine the authorized domain name root server nodes may include more or fewer schedulers, hosts, accounts, proxies, regions, task interaction nodes, and domain name root server nodes. Each scheduler may interact with more or fewer hosts, each host may use one or more proxies through one or more accounts, multiple hosts may share one proxy through one account, each proxy may interact with more or fewer task interaction nodes in one or more regions, and each region may also include more or fewer task interaction nodes and domain name root server nodes. According to embodiments of this disclosure, the scheduler 410, host 420, and proxy 440 may be devices such as desktop computers or servers, and may be physical or virtual.
[0089] According to embodiments of this disclosure, the scheduler 410 can accept a task list as input and can progressively distribute each task in the task list to each host 420 for completion, and then receive the results of the tasks from the host 420. The tasks in the task list can include two types: task switching interaction node tasks and measurement tasks. Task switching interaction node tasks require the host 420 to switch the currently used task interaction node 121. Measurement tasks can be tuples.<mission,target> This represents a measurement mission performed towards a specified target. Upon receiving the measurement mission results from the host 420, the scheduler 410 can perform subsequent operations based on the received results.
[0090] Host 420 can be a physical computer or server, or a virtual computer or server instance. Host 420 receives and executes tasks from scheduler 410. To send measurement messages from task interaction nodes that can be located globally, host 420 can access agent 440 using account 430 (used for logging in and accessing the agent's network) to use the services provided by agent 440 to send measurement messages from the task interaction node. When a task interaction node switching task is received, host 420 sends a task interaction node switching request to agent 440, and agent 440 changes the currently used task interaction node. When a measurement task is received, host 420 sends measurement messages, which are then sent by agent 440 through the task interaction node. After completing the measurement task, host 420 sends the measurement results to scheduler 410; the measurement results can be a quadruple.<egress_ip,mission,target,result> When host 420 uses the task interaction node egress_ip, it executes the measurement task mission to the target and obtains the measurement result result.
[0091] Agent 440 maintains task interaction nodes located around the world as observation nodes, thereby providing network proxy services to host 420. Different agents 440 can maintain task interaction nodes in different regions or geographical locations, and host 420 can request agents 440 to switch to task interaction nodes in different regions or geographical locations supported by agents 440 at any time.
[0092] As described above, host 420 forwards measurement data packets to the task interaction node via proxy 440. The task interaction node then sends these packets to a domain name root server node located in the same region or geographical location as the task interaction node. After receiving the measurement data packets, the domain name root server node responds, and the task interaction node returns the corresponding packets to host 420 via proxy 440. According to embodiments of this disclosure, to ensure the integrity of the measurement packets, only task interaction nodes supporting Point-to-Point Tunneling Protocol (PPTP) or Layer Two Tunneling Protocol (L2TP) proxy network protocols can be selected.
[0093] According to embodiments of this disclosure, in Figure 4In the environment 400 shown for determining the root server nodes of the authorized domain name, the interactions between the scheduler 410, host 420, agent 440 and task interaction nodes 121, 131 and 141, as well as the interactions between task interaction nodes 121, 131 and 141 and the root server nodes 122, 132 and 142, can all be conducted over the network.
[0094] Figure 5 A flowchart of another method 500 for determining an authoritative domain name root server node according to an embodiment of the present disclosure is shown. The method 500 for determining an authoritative domain name root server node can be implemented by a scheduler 410, host 420, and agent 440 in an environment 400 for determining authoritative domain name root server nodes, or by other suitable devices. It should be understood that the method 500 for determining an authoritative domain name root server node may also include additional steps not shown and / or the steps shown may be omitted; the scope of the embodiments of the present disclosure is not limited in this respect. The specific steps of the method 500 for determining an authoritative domain name root server node are described below using the scheduler 410, host 420, agent 440, region 1 120, region 2 130, and region 3 140 in the environment 400 for determining authoritative domain name root server nodes, task interaction nodes 121, 131, and 141 in the regions, and domain name root server nodes 122, 132, and 142 as examples.
[0095] In box 502, scheduler 410 uses host 420 and agent 440 to determine whether the task interaction node can correctly execute the set of functions. The specific details of this step are similar to those described above in method 200 for determining authoritative domain name root server nodes, where the computing device 110 can perform a correctness test on task interaction node 121-1 by determining that task interaction node 121-1 can correctly execute the set of functions, and will not be repeated here.
[0096] When it is determined that the task interaction node cannot correctly execute the function set, method 500 proceeds to box 504; when it is determined that the task interaction node can correctly execute the function set, method 500 proceeds to box 506.
[0097] In box 504, scheduler 410, through host 420, instructs agent 440 to switch task interaction nodes, and method 500 returns to box 502 to determine whether the switched task interaction node can correctly execute the set of functions.
[0098] In box 506, scheduler 410 performs DNS-based route tracing via host 420 and agent 440 to obtain routing information for the root domain name server node and obtain the identification information of the root domain name server node, thereby forming the identity of the root domain name server node and storing it in the baseline identity database.
[0099] According to embodiments of this disclosure, during the execution of DNS-based route tracing, DNS-based route tracing can be initiated sequentially towards the 13 root server letters. The obtained domain name root server node routing information can be represented by a tuple p =<root_letter,penultimate_hop> This indicates that requests for the four DNS server identifiers can be sent sequentially to the 13 root server letters. The obtained domain name root server node identifier information can be represented by a triple i=<root_letter,type,response> This indicates that the obtained domain name root server node routing information and domain name root server node identification information can then be used to form the identity identifier of the domain name root server node, and the formed identity identifier can be stored in the baseline identity identifier database.
[0100] According to embodiments of this disclosure, the scheduler 410 is uniformly responsible for reading and writing to the baseline identity database, and the baseline identity database may include two data tables: a domain name root server node routing information table and a domain name root server node identification information table. The domain name root server node routing information table may include the fields root_letter and penultimate_hop, where root_letter is of type char and penultimate_hop is of type string. The domain name root server node identification information table may include the fields root_letter, type, and response, where type and response are both of type string. During operation, the scheduler 410 stores the identity identifiers obtained through the currently used task interaction nodes in the baseline identity database.
[0101] In box 508, scheduler 410 determines whether the number of identities formed and stored in the baseline identity database exceeds the threshold number of identities (threshold_data). If it is determined that the number of identities does not exceed the threshold number of identities, method 500 proceeds to box 504; if it is determined that the number of identities exceeds the threshold number of identities, method 500 proceeds to box 510.
[0102] The specific details of this step are similar to those described above in the method 200 for determining the root server node of an authorized domain name, which allows the computing device 110 to determine whether the number of identity identifiers in the acquired identity identifier set exceeds a first threshold number of identity identifiers, and will not be repeated here.
[0103] In box 510, scheduler 410 determines whether the difference between the identity of the first domain name root server node and the identity in the baseline identity database exceeds a difference threshold. When it is determined that the difference between the identity of the first domain name root server node and the identity in the baseline identity database does not exceed the difference threshold, method 500 proceeds to box 504; when it is determined that the difference between the identity of the first domain name root server node and the identity in the baseline identity database exceeds the difference threshold, method 500 proceeds to box 512.
[0104] When determining whether the difference between the identity identifier of the first domain name root server node and the identity identifier in the baseline identity identifier database exceeds the difference threshold, for a task interaction node currently in use by a single host, the scheduler 410 sequentially traverses the 13 root server letters. For the currently traversed root server letter now_root_letter, it filters the identity identifier nr_p obtained by the current task interaction node.<now_root_letter,nr_penultimate_hop> ,nr_i=<now_root_letter,type,nr_response> Then, scheduler 410 searches the baseline identity database, filters all identities root_letter == now_root_letter, and for each nr_penultimate_hop and nr_response, checks whether there exists at least threshold_identical+1 equivalent identity (because this identity has been inserted once in the previous process).
[0105] For the routing information of the domain name root server node, the existence of an equivalent identity identifier indicates that it exists in the baseline identity identifier database.<now_root_letter,eq_nr_penultimate_hop> eq_nr_penultimate_hop can be exactly the same as nr_penultimate_hop, or it can be an IP address located in the same / 24 network segment as nr_penultimate_hop, or an IP address located in the same geographical location and carrier network as nr_penultimate_hop; for the domain name root server node identification information, the existence of an equivalent identity indicates that it exists in the baseline identity database.<now_root_letter,type,nr_response> That is, completely identical records.
[0106] In box 512, scheduler 410 identifies the first domain name root server node as an unauthorized domain name root server node. According to embodiments of this disclosure, when the difference between the identity identifier of the first domain name root server node and the identity identifier in the baseline identity identifier database exceeds a difference threshold, scheduler 410 can determine that the task interaction node currently used by the host is being hijacked by the unauthorized domain name root server node (now_root_letter), and therefore can identify the first domain name root server node as an unauthorized domain name root server node. At this time, according to embodiments of this disclosure, scheduler 410 can output the geographical location, network operator, and autonomous system information of the task interaction node, and can also output the root name server identifier letter hijacked by the unauthorized domain name root server node.
[0107] In box 512, scheduler 410 performs a security check on the first domain name root server node. The specific details of this step are similar to those described above in method 200 for determining authoritative domain name root server nodes, where computing device 110 performs a security check on the determined non-authoritative domain name root server node after it has been determined, and will not be repeated here. After scheduler 410 performs the security check on the first domain name root server node, method 500 proceeds to box 504, where scheduler 410, through host 420, instructs agent 440 to switch the task interaction node.
[0108] The above is for reference only. Figures 1 to 5 This document describes an environment 100 for determining an authoritative domain name root server node, in which certain embodiments of the present disclosure may be implemented; a method 200 for determining an authoritative domain name root server node, in which embodiments of the present disclosure may be implemented; an apparatus 300 for determining an authoritative domain name root server node, in which embodiments of the present disclosure may be implemented; another environment 400 for determining an authoritative domain name root server node, in which certain embodiments of the present disclosure may be implemented; and another method 500 for determining an authoritative domain name root server node, in which embodiments of the present disclosure may be implemented. It should be understood that the above description is intended to better illustrate the content described in the embodiments of the present disclosure and is not intended to be limiting in any way.
[0109] It should be understood that the number and size of various elements used in the embodiments and accompanying drawings of this disclosure are merely examples and are not intended to limit the scope of protection of the embodiments of this disclosure. The aforementioned numbers and sizes can be arbitrarily set as needed without affecting the normal implementation of the embodiments of this disclosure.
[0110] Based on the above references Figures 1 to 5 As described above, the technical solutions according to the embodiments of this disclosure have many advantages over conventional solutions.
[0111] First, the technical solution disclosed herein can accurately detect unauthorized domain name root server nodes. Specifically, the technical solution disclosed herein can establish a baseline identity database based on multi-dimensional information to screen unauthorized domain name root server nodes. Furthermore, the technical solution disclosed herein can be designed according to the deployment characteristics of unauthorized domain name root server nodes to effectively identify different types of transparent root server hijacking, thereby accurately locating the network and geographical location of the unauthorized domain name root server nodes.
[0112] Furthermore, the technical solution disclosed herein can effectively detect security vulnerabilities. Specifically, the technical solution disclosed herein can be used to examine three important security indicators of domain name root server nodes. By conducting targeted detection of unauthorized domain name root server nodes, the technical solution disclosed herein can effectively identify the potential security risks posed by unauthorized domain name root server nodes to user network security.
[0113] Furthermore, the technical solution disclosed herein also offers the advantage of high system operating efficiency. Specifically, according to the technical solution disclosed herein, a large number of proxies and task interaction nodes can be used to process tasks based on a distributed architecture. Therefore, the technical solution disclosed herein can efficiently connect to task interaction nodes provided by different proxy vendors, utilize a large number of task interaction nodes in parallel, and process tasks asynchronously, thereby effectively improving the detection efficiency of unauthorized domain name root server nodes.
[0114] Furthermore, the technical solution disclosed herein also has the advantage of strong method adaptability. Specifically, according to the technical solution disclosed herein, there is no need to manually specify the baseline identity identifiers in the baseline identity identifier database. Instead, it can establish baseline identity identifiers for domain name root server nodes in real time during batch measurements, thereby identifying unauthorized domain name root server nodes based on these identity identifiers. For example, the technical solution disclosed herein can flexibly adapt to different user detection accuracy requirements and cost constraints. For instance, the technical solution disclosed herein provides two adjustable parameters (threshold_data and threshold_identical). For example, if the user has high detection accuracy requirements and ample cost constraints, they can select higher threshold_data and threshold_identical to obtain more identity identifiers as baselines and output results with lower recall rates. At the same time, the technical solution disclosed herein can adopt a distributed design, allowing users to freely choose the host architecture according to resource constraints, such as physical machines or virtual machine instances, or even a hybrid deployment. Furthermore, since each host can use at least one account, theoretically, the number of hosts can support the use of services provided by the same or even more resellers. This allows users to fully leverage the coverage advantages of different resellers' task interaction nodes. For example, different domestic, North American, and European resellers can be used simultaneously to obtain globally covered task interaction nodes. Therefore, the detection accuracy of the technical solution disclosed herein is not affected by changes in the deployment of unauthorized domain name root server nodes, and it can also adapt to different user detection accuracy requirements and cost constraints, demonstrating strong adaptability.
[0115] Figure 6 The figure illustrates a schematic block diagram of an example device 600 that can be used to implement embodiments of the present disclosure. According to embodiments of the present disclosure, Figure 1 The computing device 110 shown Figure 3 The apparatus 300 shown is for determining the root server node of the authoritative domain name. Figure 4 The scheduler 410 and host 420 shown can be implemented as example device 600. As shown, device 600 includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes according to computer program instructions stored in read-only memory (ROM) 602 or loaded from storage unit 608 into random access memory (RAM) 603. Various programs and data required for the operation of device 600 can also be stored in RAM 603. CPU 601, ROM 602, and RAM 603 are interconnected via bus 604. Input / output (I / O) interface 605 is also connected to bus 604.
[0116] Multiple components in device 600 are connected to I / O interface 605, including: input unit 606, such as keyboard, mouse, etc.; output unit 607, such as various types of monitors, speakers, etc.; storage unit 608, such as disk, optical disk, etc.; and communication unit 609, such as network card, modem, wireless transceiver, etc. Communication unit 609 allows device 600 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.
[0117] The various processes and procedures described above, such as methods 200 and 500, can be executed by processing unit 601. For example, in some embodiments, methods 200 and 500 can be implemented as computer software programs, which are tangibly contained in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program can be loaded and / or installed on device 600 via ROM 602 and / or communication unit 609. When the computer program is loaded into RAM 603 and executed by CPU 601, one or more actions of methods 200 and 500 described above can be performed.
[0118] Embodiments of this disclosure may relate to methods, apparatus, systems, and / or computer program products. A computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for performing various aspects of embodiments of this disclosure.
[0119] Computer-readable storage media can be tangible devices capable of holding and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. More specific examples of computer-readable storage media, as a non-exhaustive list, include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination thereof. The computer-readable storage media used herein are not to be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, such as light pulses propagating through waveguides or other transmission media via fiber optic cables, or electrical signals transmitted via wires.
[0120] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, a local area network (LAN), a wide area network (WAN), and / or a wireless network, to an external computer or external storage device. The network may include copper cables, fiber optic cables, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media within the respective computing / processing device.
[0121] Computer program instructions used to perform the operations of embodiments of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages such as Smalltalk, C++, etc., and conventional procedural programming languages such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on a user's computer, partially on a user's computer, as a standalone software package, partially on a user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer via an internet connection, for example, using an internet service provider. In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing state information from the computer-readable program instructions. This electronic circuitry can execute the computer-readable program instructions to implement various aspects of embodiments of this disclosure.
[0122] Various aspects of embodiments of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus / systems, and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.
[0123] These computer-readable program instructions can be provided to a processing unit of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processing unit of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner. Thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.
[0124] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.
[0125] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.
[0126] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, and are not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical applications, or technical improvements to the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.
Claims
1. A method for determining the root server node of an authoritative domain name, comprising: A set of tasks related to obtaining the identity of the domain root server node in the domain root server node set is sent via a set of task interaction nodes, wherein the set of task interaction nodes and the set of domain root server nodes are located in a predetermined region. The set of responses made by the set of domain name root server nodes to the task set is obtained through the set of task interaction nodes, and the set of responses includes the set of identity identifiers of the domain name root server nodes; as well as If the number of identity identifiers in the identity identifier set exceeds the first threshold number of identity identifiers, then the set of authorized domain name root server nodes in the domain name root server node set is determined based on the identity identifier set.
2. The method of claim 1, wherein sending the task comprises: If a customized query is initiated to the predetermined domain name system server via the first task interaction node in the task interaction node set, and it is determined that the first task interaction node can correctly execute the function set, then the first task in the task set is sent via the first task interaction node.
3. The method according to claim 2, wherein the functional set includes: The function to initiate a Domain Name System (DNS) query to a specified Internet Protocol (IP) address; The function of receiving the corresponding Domain Name System (DNS) response from the specified Internet Protocol (IP) address; Supports the function of sending EDNS0 extended messages; Supports the function of sending CHAOS type messages; Supports the ability to modify the Time-to-Live (TTL) field in the Internet Protocol header of Domain Name System (DNS) messages; and It supports the function of sending messages related to Domain Name System security extensions.
4. The method according to claim 1, wherein the identity identifiers in the identity identifier set include: Domain name root server node routing information; as well as Domain name root server node identification information.
5. The method according to claim 4, wherein determining the set of authorized domain name root server nodes includes: A subset of identity identifiers is determined from the set of identity identifiers, wherein the domain name root server node routing information of the identity identifiers in the subset of identity identifiers is equivalent and the domain name root server node identifier information is the same; as well as If the number of identity identifiers in the subset of identity identifiers exceeds the second threshold number of identity identifiers, then the domain name root server node corresponding to the identity identifier in the subset of identity identifiers is determined as the authorized domain name root server node.
6. The method according to claim 5, wherein the domain name root server node routing information of the identity identifier is equivalent to one of the following: The routing information of the domain name root server nodes is exactly the same; The domain name root server node routing information corresponds to the same Internet Protocol address in the subnet mask, where the binary representation of the network is 24 bits; and The routing information of the domain name root server node corresponds to the operator and geographical location of the Internet Protocol address.
7. The method according to claim 1, further comprising: Send a first task related to obtaining the identity identifier of the domain name root server node in the domain name root server node set from the first task interaction node in the task interaction node set; Obtain a first response from the first domain root server node in the set of domain root server nodes to the first task, wherein the first response includes the first identity identifier of the first domain root server node. as well as If the first identity identifier is different from the identity identifier of any authorized domain root server node in the set of authorized domain root server nodes, then the first domain root server node is determined to be a non-authorized domain root server node.
8. The method according to claim 1, further comprising: If the second identity of the second domain root server node in the set of domain root server nodes is different from the identity of any authorized domain root server node in the set of authorized domain root server nodes, then the second domain root server node is determined to be a non-authorized domain root server node.
9. The method according to claim 7 or 8, further comprising: A security check is performed on the unauthorized domain name root server node, and the security check includes at least one of the following: Integrity check of root area file copies; Root zone file copy timeliness detection; as well as Domain Name System Security Extension Availability Detection.
10. An electronic device, comprising: At least one processing unit; as well as At least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions, when executed by the at least one processing unit, causing the device to perform an action, the action including: A set of tasks related to obtaining the identity of the domain root server node in the domain root server node set is sent via a set of task interaction nodes, wherein the set of task interaction nodes and the set of domain root server nodes are located in a predetermined region. The task interaction node set obtains a set of responses from the domain name root server node set to the task set, the response set including the identity set of the domain name root server nodes; and If the number of identity identifiers in the identity identifier set exceeds the first threshold number of identity identifiers, then the set of authorized domain name root server nodes in the domain name root server node set is determined based on the identity identifier set.
11. The electronic device of claim 10, wherein sending the task comprises: If a customized query is initiated to the predetermined domain name system server via the first task interaction node in the task interaction node set, and it is determined that the first task interaction node can correctly execute the function set, then the first task in the task set is sent via the first task interaction node.
12. The electronic device of claim 11, wherein the set of functions includes: The function to initiate a Domain Name System (DNS) query to a specified Internet Protocol (IP) address; The function of receiving the corresponding Domain Name System (DNS) response from the specified Internet Protocol (IP) address; Supports the function of sending EDNS0 extended messages; Supports the function of sending CHAOS type messages; Supports the ability to modify the Time-to-Live (TTL) field in the Internet Protocol header of Domain Name System (DNS) messages; and It supports the function of sending messages related to Domain Name System security extensions.
13. The electronic device of claim 10, wherein the identity identifiers in the identity identifier set include: Domain name root server node routing information; as well as Domain name root server node identification information.
14. The electronic device of claim 13, wherein determining the set of authorized domain name root server nodes includes: A subset of identity identifiers is determined from the set of identity identifiers, wherein the domain name root server node routing information of the identity identifiers in the subset of identity identifiers is equivalent and the domain name root server node identifier information is the same; as well as If the number of identity identifiers in the subset of identity identifiers exceeds the second threshold number of identity identifiers, then the domain name root server node corresponding to the identity identifier in the subset of identity identifiers is determined as the authorized domain name root server node.
15. The electronic device of claim 14, wherein the domain name root server node routing information of the identity identifier is equivalent to one of the following: The routing information of the domain name root server nodes is exactly the same; The domain name root server node routing information corresponds to the same Internet Protocol address in the subnet mask, where the binary representation of the network is 24 bits; and The routing information of the domain name root server node corresponds to the operator and geographical location of the Internet Protocol address.
16. The electronic device according to claim 10, further comprising: Send a first task related to obtaining the identity identifier of the domain name root server node in the domain name root server node set from the first task interaction node in the task interaction node set; Obtain a first response from the first domain root server node in the set of domain root server nodes to the first task, wherein the first response includes the first identity identifier of the first domain root server node. as well as If the first identity identifier is different from the identity identifier of any authorized domain root server node in the set of authorized domain root server nodes, then the first domain root server node is determined to be a non-authorized domain root server node.
17. The electronic device according to claim 10, further comprising: If the second identity of the second domain root server node in the set of domain root server nodes is different from the identity of any authorized domain root server node in the set of authorized domain root server nodes, then the second domain root server node is determined to be a non-authorized domain root server node.
18. The electronic device according to claim 16 or 17, wherein the action further comprises: A security check is performed on the unauthorized domain name root server node, and the security check includes at least one of the following: Integrity check of root area file copies; Root zone file copy timeliness detection; as well as Domain Name System Security Extension Availability Detection.
19. A non-transient computer-readable medium storing machine-executable instructions that, when executed, cause a machine to perform the steps of the method according to any one of claims 1 to 9.
Citation Information
Patent Citations
Cache optimization method and system for resisting continuous variable-domain name prefix attack
CN104618354A
Blockchain multi-party shared-governance-based system for maintaining domain name information
US20210135867A1