A domain name risk assessment method and device, electronic equipment and storage medium

Abstract

This application provides a domain name risk assessment method, apparatus, electronic device, and storage medium, relating to, but not limited to, the field of data processing technology. The method includes: determining a DNS resolution dependency path tree corresponding to a target domain name; performing a depth-first search on the DNS resolution dependency path tree to determine each DNS resolution dependency path of the target domain name; obtaining attribute risk indicators of node risk attributes for each node in the DNS resolution dependency path tree; calculating path risk indicators for each DNS resolution dependency path based on the DNS resolution dependency paths and each attribute risk indicator; and determining the target risk indicator for the target domain name based on the path risk indicators corresponding to the target domain name. This application's embodiments diagnose domain name risks from a management perspective, supplementing and improving existing DNS resolution-side risks. Furthermore, based on the dependency path tree, it enables further analysis of various dependency risks in the DNS resolution process, thereby improving the accuracy and efficiency of domain name risk assessment.

Description

Technical Field

[0001] This application relates to, but is not limited to, the field of data processing technology, and in particular to a domain name risk assessment method, apparatus, electronic device, and storage medium. Background Technology

[0002] Current Domain Name System (DNS) risk analysis primarily focuses on the risks associated with DNS resolution results, particularly analyzing various security attacks on the DNS resolution side, including hijacking and cache poisoning. It lacks assessment of risks on the management side, which often propagate to the user side, affecting normal domain name resolution. Furthermore, because DNS resolution is top-down, it relies on upstream domain resources at various levels. Existing risk analyses often present complex representations of these dependencies, making it difficult to assess the risks involved in the DNS resolution process. In other words, current DNS risk analysis emphasizes the assessment of existing risks, neglecting the potential impact of management-side risks on DNS resolution and lacking analysis of DNS resolution dependencies. This results in low accuracy and efficiency in DNS risk assessment. Therefore, a new method for DNS risk assessment is urgently needed to improve both accuracy and efficiency. Summary of the Invention

[0003] This application provides a domain name risk assessment method, apparatus, electronic device, and storage medium, aiming to improve the accuracy and efficiency of domain name risk assessment.

[0004] In a first aspect, embodiments of this application provide a domain name risk assessment method, the domain name risk assessment method comprising:

[0005] Obtain the target domain name to be assessed for risk;

[0006] Based on the target domain name, determine the DNS dependency path tree corresponding to the target domain name;

[0007] A depth-first search is performed on the resolution dependency path tree to determine each resolution dependency path of the target domain name;

[0008] Obtain the attribute risk index of the node risk attribute of each node on the parsed dependency path tree;

[0009] Based on the parsing dependency paths and the risk indicators of each attribute, the path risk indicators of each parsing dependency path are calculated.

[0010] The target risk indicators for the target domain name are determined based on the risk indicators of each path corresponding to the target domain name.

[0011] Secondly, embodiments of this application provide a domain name risk assessment device, the domain name risk assessment device comprising:

[0012] The first acquisition module is used to acquire the target domain name to be assessed for risk.

[0013] The determination module is used to determine the DNS dependency path tree corresponding to the target domain name based on the target domain name;

[0014] The search module is used to perform a depth-first search on the resolution dependency path tree to determine each resolution dependency path of the target domain name;

[0015] The second acquisition module is used to acquire the attribute risk index of the node risk attribute of each node on the parsed dependency path tree.

[0016] The path risk index determination module is used to calculate the path risk index of each parsing dependency path based on the parsing dependency path and each attribute risk index.

[0017] The target risk indicator module is used to determine the target risk indicator of the target domain name based on the risk indicators of each path corresponding to the target domain name.

[0018] Thirdly, embodiments of this application provide an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the domain name risk assessment method as described in the first aspect.

[0019] Fourthly, embodiments of this application provide a computer-readable storage medium, including computer-executable instructions stored thereon, the computer-executable instructions being executed by a processor as described in the first aspect of the domain name risk assessment method.

[0020] The embodiments of this application have at least the following beneficial effects: by calculating path risk indicators for each resolution dependency path of each target domain name and determining the target risk indicator based on each path risk indicator, domain name risks can be diagnosed from a management perspective, supplementing and improving existing resolution-side risks and enhancing the accuracy of risk assessment. Furthermore, by using a dependency resolution dependency path tree to further analyze various dependency risks in the resolution process, resolution efficiency is higher. Therefore, compared with related technologies, the embodiments of this application can improve the accuracy and efficiency of domain name risk assessment. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of the device module corresponding to the domain name risk assessment method in this application embodiment;

[0022] Figure 2This is a flowchart illustrating the domain name risk assessment method according to an embodiment of this application;

[0023] Figure 3 This is a flowchart illustrating one embodiment of the domain name risk assessment method of this application.

[0024] Figure 4 This is a schematic diagram illustrating the dependency resolution in one embodiment of the domain name risk assessment method of this application.

[0025] Figure 5 This is a schematic diagram illustrating the construction of a dependency path resolution method in one embodiment of the domain name risk assessment method of this application.

[0026] Figure 6 This is a schematic diagram illustrating the resolution of the dependency path tree in one embodiment of the domain name risk assessment method of this application.

[0027] Figure 7 This is a schematic diagram of the hardware structure corresponding to the domain name risk assessment method in the application embodiment. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0029] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application. The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0030] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this disclosure. However, those skilled in the art will recognize that the technical solutions of this disclosure can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this disclosure.

[0031] Past research on DNS security risks has focused on the user side, including attacks targeting DNS and attacks on other network entities using DNS. The main threats or challenges facing DNS are shown in Table 1. As Table 1 shows, the threats or challenges to DNS primarily affect the user side. On the management side, current research focuses on the risks of root-centralized management. However, centralized root service management can lead to the following risks of power abuse: 1) "Blinding Risk": Root servers may fail to provide resolution services or provide abnormal resolution data to recursive resolvers and users in specific network zones, leaving targeted users in a "blinded" state. 2) "Disappearance Risk": The root zone's publishing center may delete or tamper with data submitted by a specific top-level domain (TLD) registry, rendering domain names under that TLD inaccessible, effectively causing the TLD to disappear from the domain name space. These risks on the DNS management side often propagate to the user side, affecting the normal resolution of domain names. Furthermore, since domain name resolution is top-down, it involves dependencies on upstream domain name resources at various levels. Although existing risk analyses can assess the risks associated with these dependencies, their expression is complex, making it difficult to ensure the accuracy and efficiency of domain name risk assessment. They also lack analysis of risks during the domain name resolution process itself. Therefore, this application focuses on the management side of the domain name system, analyzing the risk factors of DNS management and their impact on DNS users. It proposes a domain name management risk assessment model based on a resolution dependency search tree, diagnosing domain name risks from a management perspective. This model supplements and improves existing resolution-side risk assessment methods and provides a simple and efficient analysis method for the domain name resolution process based on the proposed resolution dependency search tree. The dependency search tree allows for further analysis of various dependency risks in the resolution process. Table 1 is shown below:

[0032]

[0033] Table 1

[0034] Reference Figure 1 As shown, a domain name risk assessment device provided according to an embodiment of this application includes:

[0035] The first acquisition module 100 is used to acquire the target domain name to be risk assessed.

[0036] The determination module 200 is used to determine the DNS dependency path tree corresponding to the target domain name based on the target domain name;

[0037] The search module 300 is used to perform a depth-first search on the resolution dependency path tree to determine the resolution dependency paths of the target domain name.

[0038] The second acquisition module 400 is used to acquire the attribute risk index of the node risk attribute of each node in the parsing dependency path tree.

[0039] The path risk indicator determination module 500 is used to calculate the path risk indicator of each parsing dependency path based on the parsing dependency path and the risk indicators of each attribute.

[0040] The Target Risk Indicator Module 600 is used to determine the target risk indicator of the target domain name based on the risk indicators of each path corresponding to the target domain name.

[0041] The device can be deployed independently of the Domain Name System (DNS) or it can be a device already deployed within the DNS for real-time risk assessment. In some embodiments, when the DNS risk assessment device determines that a target risk indicator exceeds a threshold, it outputs a prompt message or processes the DNS based on a security policy. This application embodiment does not elaborate on the processing operations for target risk indicators exceeding thresholds.

[0042] It is understood that the above modules can be merged or reorganized as needed, and the embodiments of this application do not impose any restrictions on this.

[0043] Reference Figure 2 As shown, it can be understood that, according to the embodiments of this application, a domain name risk assessment method includes:

[0044] Step S100: Obtain the target domain name to be assessed for risk;

[0045] Step S200: Determine the DNS dependency path tree corresponding to the target domain name;

[0046] Step S300: Perform a depth-first search on the resolution dependency path tree to determine each resolution dependency path of the target domain name;

[0047] Step S400: Obtain the attribute risk index of the node risk attribute of each node on the parsing dependency path tree;

[0048] Step S500: Calculate the path risk index of each resolution dependency path based on the resolution dependency path and the risk index of each attribute.

[0049] Step S600: Determine the target risk indicators for the target domain name based on the risk indicators of each path corresponding to the target domain name.

[0050] Therefore, by calculating path risk indicators for each resolution dependency path of each target domain name and determining the target risk indicator based on each path risk indicator, domain name risk can be diagnosed from a management perspective, supplementing and improving existing resolution-side risks and enhancing the accuracy of risk assessment. Furthermore, by using a dependency resolution path tree to further analyze various dependency risks in the resolution process, resolution efficiency is higher. Therefore, compared with related technologies, the embodiments of this application can improve the accuracy and efficiency of domain name risk assessment.

[0051] It is understood that the domain name risk assessment method in this application embodiment can be used for offline risk assessment of domain names or for online risk assessment of domain names. This application embodiment does not limit this, and those skilled in the art can selectively set it according to the actual situation.

[0052] It is understood that each target domain name has a unique corresponding DNS dependency path tree. This application does not limit how the DNS dependency path tree is determined. For example, the DNS dependency tree can be constructed in real time based on the various zones involved in the DNS resolution process of the target domain name and the relationship between the zones and the authoritative server. Alternatively, it can be input by the user. This application does not limit this approach, and those skilled in the art can selectively configure it according to actual circumstances.

[0053] The DNS dependency path tree represents the resolution process of the corresponding target domain name. Each DNS dependency path tree has at least one DNS dependency path; each node in the DNS dependency path tree corresponds to an authoritative server, which can be an intra-domain server or an extra-domain server. Node risk attributes are the attributes that a corresponding node may have that cause DNS resolution risk. For example, if the resolution risk is caused by the server operator, then the node risk attribute includes the server operator attribute; similarly, if the resolution risk is caused by the network operator, then the node risk attribute includes the network operator attribute. Those skilled in the art can selectively set these attributes according to actual circumstances. The attribute risk index represents the probability that the corresponding node risk attribute will cause DNS resolution risk. This index can be manually set or dynamically determined based on the historical DNS resolution data of the node in the domain name system. Those skilled in the art can selectively set this attribute according to actual needs.

[0054] When multiple resolution paths exist, ensuring that only some paths are available is sufficient to guarantee the target domain name can be resolved normally. Therefore, it is necessary to comprehensively consider the risk indicators of each path corresponding to the target domain name to determine the target risk indicator of the target domain name. This application does not limit how the comprehensive approach is used; for example, an average can be taken, or the m lowest-risk probabilities can be averaged or weighted, or one can be selected from multiple paths as the target risk indicator of the target domain name.

[0055] Understandably, in some embodiments, risk factors affecting the risk of each node on the dependency path tree are also subscribed to and resolved. These risk factors include the type of node risk attributes (e.g., an increase / decrease in type indicates a change in risk factors), the attribute risk index of node risk attributes (e.g., an increase / decrease in attribute risk index indicates a change in risk factors), and the relationships between nodes (e.g., an increase / decrease in node attributes or a change in node dependencies both indicate a change in risk factors). A change flag is set to indicate whether a risk factor has changed, and the target risk index calculated in real time for each instance is saved. When a target domain search is triggered, and the change flag indicates a change in risk factors, the target risk index is determined in real time based on steps S200 to S600. When a target domain search is triggered, and the change flag indicates no change in risk factors, the historical target risk index is directly read as the target risk index for the current moment. In other embodiments, when a risk factor changes, a real-time update of the target risk index is initiated during idle periods. This allows the already updated target risk index to be directly retrieved when a target domain search is triggered, thus enabling more timely determination of the target risk index.

[0056] It is understood that the embodiments of this application do not limit the number of node risk attributes in step S400, and those skilled in the art can selectively set them according to actual needs.

[0057] Understandably, based on the resolution dependency paths and the risk indicators of each attribute, the path risk indicators for each resolution dependency path are calculated, including:

[0058] Based on the attribute risk index of each node's node risk attribute, determine the node risk index of each node in each parsing dependency path.

[0059] Based on the node risk indicators, determine the security indicators for each node;

[0060] The path security index of each resolution dependency path is determined by performing a product operation on the security indices of each node on the same resolution dependency path.

[0061] Based on the security indicators of each path, determine the path risk indicators of each resolution dependency path.

[0062] A node risk attribute can be set to at least one. When only one node risk attribute is set, the node risk index is the attribute risk index. When multiple node risk attributes are set, the node risk index can be obtained by weighting the multiple attribute risk indices, or by summing the multiple attribute risk indices. This application does not impose any restrictions on how the node risk index is determined.

[0063] Security risk indicators characterize the security probability of a corresponding node. Let the node risk indicator be p(nodei If ), then the security index is 1-p(node). i ).

[0064] By first calculating the security indicators of the nodes, and then calculating the path security indicators of the path dependent paths based on the security indicators of each node, the accuracy of the path risk indicators can be further ensured based on the path security indicators.

[0065] The product of safety indicators can be calculated using either a product operation or a direct product operation, such as p(path). i ) = 1 - ∏ 1<=j<=n (1- p(node j )); where j represents the node index, node j This represents the j-th node on the dependency path.

[0066] Understandably, node risk attributes include institutional attributes, server operation attributes, and network operator attributes. Based on the attribute risk indicators of each node's node risk attributes, the node risk indicators for each node in each resolution dependency path are determined, including:

[0067] Risk factors for obtaining organizational attributes, server operation attributes, and network operator attributes;

[0068] The node risk index of each node in each parsing dependency path is determined by weighted calculation based on the risk coefficients and attribute risk indicators of the same node.

[0069] It is understood that this application does not limit how the risk coefficient is set; those skilled in the art can set it based on experience or determine it based on the parsed data at that node. It is understood that the risk coefficients for the institutional attributes, server operation attributes, and network operator attributes at the same node can be set according to the importance of each attribute. For example, using the analytic hierarchy process (AHP), the importance can be determined as w. m >w s >w n w m For the risk coefficient of institutional attributes, w s The risk factor for server operation attributes, w n Risk coefficient for network operator attributes.

[0070] For example, suppose the risk probabilities of institutional attributes, server operation attributes, and network operator attributes are represented as p. m p s and p nIn some embodiments, when the country of origin of the management organization attribute is inconsistent with the country of origin of the domain name resource registrant, the risk probability of the organization attribute of the node can be set to 1, otherwise it is 0. In this case, the risk index of the node is calculated as shown in the following formula (1). Assume a path i The nodes are (node1, node2, ..., node n The path risk index is calculated as shown in formula (2). In some embodiments, the path risk indices of all resolution dependent paths can be sorted from high to low probability, and the path risk index of the 80th path can be taken to represent the overall management risk probability (i.e., the target risk index) of the target domain name. The 80% proportion mainly considers that as long as 20% of the resolution paths are available, the domain name resolution can be guaranteed. Therefore, the risk probability of the 80th proportion of paths ensures that 20% of the path risk probabilities are less than or equal to this risk probability. In practical applications, 80% can be gradually adjusted in actual analysis and operation to find a path position that reasonably reflects the overall risk probability of the domain name. This application embodiment does not limit how to gradually adjust, and those skilled in the art can selectively set it according to their needs.

[0071] p(node i ) = w m p m + w s p s + w n p n Formula (1);

[0072] p(path i ) = 1 - ∏ 1<=j<=n (1- p(node j ))Formula (2);

[0073] Understandably, the risk factors associated with acquiring information about the organization, server operation, and network operator include:

[0074] If the node risk index of the node to be calculated at the current moment is not found in the preset cache, the risk coefficients of the organization attribute, server operation attribute and network operator attribute are obtained; the cache is used to cache the node risk index of the nodes that have been calculated on each resolution dependency path.

[0075] After determining the node risk index of each node in each parsing dependency path by weighted calculation based on the risk coefficients and attribute risk indicators of the same node, the method further includes:

[0076] Associate the node risk indicators with the node and store them in the cache.

[0077] By associating node risk indicators with nodes and storing them in the cache, the calculation of node risk indicators for the same node can be reduced when multiple resolution dependency paths share a node.

[0078] In some embodiments, after the target risk indicator is output, the risk indicators of each node that participated in the calculation process of the target risk indicator can be cleared from the cache to ensure that the cache area contains the node risk indicators of each node under the current time of parsing the dependency path tree.

[0079] Understandably, the target risk indicators for the target domain are determined based on the risk indicators of each path corresponding to the target domain, including:

[0080] The path risk indicators of the target domain name are sorted from high to low to obtain the path risk sequence;

[0081] Obtain the path security threshold ratio;

[0082] The target location is determined based on the path security threshold ratio and the total number of paths that the target domain name depends on for resolution.

[0083] Select the path risk indicator corresponding to the target location from the path risk sequence as the target risk indicator.

[0084] The path safety threshold ratio can be selectively set according to actual needs. A path safety threshold ratio can be set, and in actual operation, the path safety threshold can be dynamically adjusted according to the accuracy of the target risk indicator assessment.

[0085] Understandably, the dependency path tree is determined through the following steps:

[0086] The target domain name is split into different regions to obtain the regions of the target domain name and the region dependencies.

[0087] Based on each region and the preset authoritative servers, determine the resolution dependency paths of the target domain name;

[0088] Construct a resolution dependency path tree for all resolution dependency paths of the target domain.

[0089] Region dependencies indicate the hierarchical relationships between regions. The relationship between each region and the authoritative server is pre-configured; therefore, region-authoritative dependencies can be obtained based on each region and each authoritative server.

[0090] Understandably, in some embodiments, the redundancy of each resolution dependency path can be calculated, and resolution dependency paths with redundancy exceeding a preset threshold can be removed to reduce the number of resolution dependency paths involved in construction and improve the efficiency of subsequent real-time target risk indicator calculation. Correspondingly, the original regions, region dependencies, and region authority dependencies are saved so that the resolution dependency path tree can be updated in real time when changes to the original regions, region dependencies, and region authority dependencies are detected.

[0091] Understandably, based on the target domain's regional dependencies and regional authority dependencies, a DNS dependency path tree is constructed, including:

[0092] Based on the region dependency, the regions of the target domain are traversed level by level.

[0093] Based on the regional authority dependency relationship, determine the target authority server for each traversed region. The target authority server is the authority server that did not participate in the resolution of dependency path construction.

[0094] Once all zones of the target domain have been traversed, the authoritative servers obtained from the traversal are connected sequentially according to a preset hierarchical order to construct a resolution dependency path for the target domain.

[0095] If there are authoritative servers in the region dependency relationship that did not participate in building and resolving the dependency path, jump to the step of traversing each region of the target domain name level by level according to the region dependency relationship;

[0096] When all authoritative servers in a region dependency relationship participate in building the dependency resolution path, the dependency resolution path tree is obtained based on the already built dependency resolution paths.

[0097] For example, refer to Figures 3 to 6 The method for domain name evaluation described in this application is referred to Figure 3 As shown, the details are as follows:

[0098] Step 1: Determine the management role type:

[0099] The hierarchical domain name system is managed by different organizations from top to bottom. The hierarchy of the target domain name's zones in the domain name system is as follows:

[0100] The top level of the domain name system is the root domain. The management of the root domain consists of two parts: the management of the root domain's naming center, also known as root zone management, and the management of the publishing center and resolution center, also known as root server management.

[0101] The next level down from the root domain is the top-level domain (TLD). ICANN categorizes TLDs into different types based on the site's purpose, owner, and geographic location. There are five formal types of TLDs: General Top-Level Domains (gTLDs), Sponsored Top-Level Domains (sTLDs), Country Code Top-Level Domains (ccTLDs), Infrastructure Top-Level Domains (ARPA), and Test Top-Level Domains (tTLDs). General Top-Level Domains are the most popular and familiar domain extension type, with common examples including ".org", ".com", and ".net". Sponsored Top-Level Domains are special domain suffixes that receive sponsorship from specific organizations the domain will serve; common examples include ".edu" and ".gov". Country Code Top-Level Domains (ccTLDs) are identified using two-letter strings; common examples include ".cn", ".us", and ".ru". Infrastructure Top-Level Domains contain only one TLD: the Address and Routing Parameters section (".arpa"), used solely for technical infrastructure purposes, such as DNS reverse lookups. Test top-level domains are reserved for documentation and local testing and cannot be published to the root zone. These include the four top-level domains ".example", ".invalid", ".localhost", and ".test". The governing body of a top-level domain is also called a registry, which manages the database of top-level domain names, maintains a database of all registered domain names under that domain, and ensures the uniqueness and accuracy of the domain names. The registry also collaborates with domain registrars to provide domain name registration services to the public, handling domain name registration, renewal, and transfer requests. Furthermore, the registry manages or hosts authoritative servers for top-level domains operated by professional DNS operators; these organizations that operate and manage authoritative DNS servers are also called authoritative server operators.

[0102] The next level below a top-level domain (TLD) is a subdomain (SLD). Subdomains are typically registered by users themselves through a domain registrar with the top-level domain registry. Therefore, the management and maintenance of subdomain registration information is generally handled on the domain registrar's platform, including registration applications, domain renewals, domain transfers, and domain cancellations. The domain registrar initiates management requests for registered domains to the registry based on standard domain name protocols such as EPP, ensuring that changes to the subdomain take effect in the registry's domain name database and are published to the top-level domain's authoritative servers.

[0103] The authoritative servers for second-level domains are typically operated and managed by the registered users themselves or entrusted to a DNS hosting service provider. As defined above, DNS hosting service providers are also known as DNS authoritative server operators, and they undertake two responsibilities: maintaining the authoritative records of the subdomains of the second-level domain and providing authoritative record resolution services.

[0104] The next level down from a second-level domain is a third-level domain. Third-level domains are generally custom domains defined by the organization that registered the second-level domain, including regular domains (fully qualified domains, FQDNs) and subdomains. The authoritative servers for third-level domains are also self-managed and hosted. For certain specific second-level domains, such as "com.cn", they are registered by the "cn" registry CNNIC, which provides open registration for third-level domains; therefore, domain registration is not limited to second-level domains.

[0105] In summary, the management roles in the Domain Name System, ranked from top to bottom according to the domain hierarchy, are: root zone management authority, root service management authority, top-level domain registry, domain registrar, authoritative server operator, and network operator where the server is located.

[0106] Among them, network operators of the networks where root servers and authoritative domain name servers at all levels are deployed have the ability to impose network restrictions on servers deployed on their networks, thereby affecting the root servers and authoritative servers from providing resolution services to the outside world.

[0107] Step 2: Resolve and construct the dependency path tree. The specific steps are as follows:

[0108] Domain name resolution dependencies can be broken down into two types: domain zone dependencies and authoritative server dependencies. Domains can be structured into multi-level parent-child zone dependencies based on their zone affiliation, with authoritative servers providing domain name resolution within that zone. Therefore, a resolution dependency is established between the zone and the authoritative server.

[0109] 1) Determine region dependencies:

[0110] Based on the management role type in Step 1, the DNS domain name hierarchy, from top to bottom, includes the root zone, top-level domain, and all levels of domain names under the top-level domain. By splitting the domain names into zones, parent-child zone dependencies can be constructed for the target domain name. Although the root zone is not the parent domain of the top-level domain from a hierarchical perspective, it still has a zone resolution dependency relationship. Therefore, for consistency, this application also refers to the relationship between the root zone and the top-level domain as a parent-child zone relationship. Here, the parent-child zone relationship is one-to-many, meaning one parent zone contains multiple child zones, and each child zone belongs to only one parent zone. For example, such as... Figure 4 As shown, the target domain name "www.example.com" is split into regional hierarchies, from bottom to top as "www.example.com", "example.com.", "com.", and ".". The parent domain of "www.example.com" is "example.com.", the parent domain of "example.com." is "com", and the parent domain of "com" is ".".

[0111] 2) Regional authority dependency relationship:

[0112] The authoritative dependency relationship between a zone and an authoritative server is categorized into intra-zone authoritative dependency and extra-zone authoritative dependency based on the authoritative server's domain name type. Intra-zone authoritative dependency means the authoritative server's domain name is within the zone, while extra-zone authoritative dependency means the authoritative server's domain name is outside the zone. Zone authoritative dependency is a many-to-many relationship, meaning one zone can depend on multiple authoritative servers, and authoritative servers can provide DNS resolution for multiple zones. For example, assuming the zone "example.com" has two authoritative servers with domain names "ns1.example.com" and "ns2.dns.net", then "ns1.example.com" is an intra-zone authoritative dependency, and "ns2.dns.net" is an extra-zone authoritative dependency.

[0113] By using region dependencies and region authority dependencies, a complete domain name resolution dependency graph can be constructed, such as... Figure 4 As shown. Among them, as Figure 4 The middle zone "example.com" has an external authoritative server "ns2.dns.net"; its parent zone "com" has an internal authoritative server "ns1.com"; the parent zone root of "com" has an internal authoritative server "a.dns.root". At this time, the resolution dependency path from top to bottom can be obtained as "a.dns.root" -> "ns1.com" -> "a.dns.root" -> "ns1.net" -> "dnsx.net".

[0114] Assuming the target domain name is d, let DNRG(d) represent the DNS dependency graph of d. According to... Figure 4 As can be seen, the dependency graph contains two types of entities and three types of relationships. The two types of entities are domain names / zones and authoritative servers, and the three types of relationships are zone parent-child relationships, intra-zone authoritative dependencies, and inter-zone authoritative dependencies. The zone entity is represented using z... i This means that the set of zone entities contained in domain name d is represented as Zones(d), z i and z j The parent-child relationship of a region is represented as ZoneRel(z i ,z j ZRLIST(d) represents the set of parent-child region relationships included in the DNS resolution dependencies of the target domain d. i S represents the authoritative server for a single address. iSLIST(d) represents a set of authoritative servers that share a common domain name. It represents the set of authoritative servers managing the DNS resolution dependencies for the target domain d. This set does not include authoritative servers resolving domain names outside the domain; these authoritative servers are recorded in the external authoritative dependency list. AuRel(z) i ,S j ) represents region z i and authoritative server S i Intradomain authority dependency relationships, OAuRel(z i ,S j ) represents region z i and authoritative server S i The domain-specific authoritative dependencies are defined by ARLIST(d) and OARLIST(d), which represent the sets of intra-domain and extra-domain authoritative dependencies included in the domain name d's resolution dependencies, respectively. Then, using the set of regions as the traversal object, the resolution paths of authoritative servers can be constructed from top to bottom, resulting in... Figure 5 The dependency path graph shown.

[0115] Understandably, when a zone name corresponds to multiple authoritative servers (which may include one authoritative server within the domain and one authoritative server outside the domain; or multiple authoritative servers within the domain, etc.), multiple resolution dependency paths can be constructed based on the domain name resolution dependency relationship of the same target domain name. These paths constitute a domain name resolution path set, which allows for the assessment of management risk during domain name management risk analysis by evaluating the management risk of each resolution path in the domain name resolution path set. By combining the risks of all paths, an overall management risk assessment result for the domain name can be obtained.

[0116] Representing the set of domain name resolution dependency paths by constructing a domain name resolution dependency path tree, and obtaining all resolution paths through a depth-first search of the tree, allows for more efficient risk assessment of the same target domain name without changing the network system architecture. Risk assessments can be performed directly based on the previous domain name resolution dependency path tree. The resolution dependency path tree can be structured as follows: Figure 6 As shown, the dashed circles represent the vertices of the tree (or subtree), represented by virtual nodes. Although a virtual node is represented as an independent node in the tree, it does not need to participate in the risk assessment of the resolution path; it can be filtered during the assessment. Each non-virtual node contains three management information attributes. The first is the authority attribute of the authoritative server's resolution zone. For a non-virtual node that is a root server, this is the root zone management authority; for a top-level domain, it is the registry; and for a subdomain, it is the registrar. The second attribute is the service operation attribute, and the third attribute is the network operator attribute. The leaf nodes of the tree are the endpoints of the domain name resolution path. Therefore, using a depth-first search algorithm, the nodes traversed each time a leaf node is reached constitute a resolution path. Figure 6In the parse path tree shown, a depth-first search traversal can obtain the first parse path as (a.dns.root / 198.41.0.4, ns1.com / 192.5.6.30, a.dns.root / 198.41.0.4, ns1.net / 192.26.92.30, dns.net / 192.55.83.30).

[0117] Step 3: Conduct a risk assessment of the target domain name based on the DNS dependency path tree. The specific steps are as follows:

[0118] (1) A depth-first search based on the domain name resolution dependency path tree can be used to obtain the domain name resolution dependency path set. To calculate the domain name resolution management risk, the management risk of each domain name resolution path can be calculated first, with p(path) as the threshold. i ) represents path i The risk of a path is determined by the risk of the nodes along that path; therefore, it is necessary to first calculate the risk probability of each node along the path, expressed as p(node ​​risk probability). i ) represents a node i The risk probability is calculated. Since multiple paths share some nodes, the risk of each node in the parsed path tree can be calculated and cached, reducing redundant calculations when calculating path risk. The management risk of a node is calculated based on three management attributes of the node. First, weights are assigned to the risks of the three management attributes, w... m w s w n The risk weights for the node's organization, the authoritative server operator, and the network operator are respectively calculated using the analytic hierarchy process (AHP) based on the importance of these three management attributes, ranked according to their degree of importance m. w >w s >w n The risk probabilities of institutional attributes, server operation attributes, and network operator attributes are respectively represented by p. m p s and p n When the country of origin of the organization included in the above-mentioned organizational attribute is inconsistent with the country of origin of the registrant of the domain name resource, the risk probability of this management attribute of the node is 1; otherwise, it is 0. The risk probability of the node is calculated as shown in formula (1). Assume a path iThe nodes are (node1, node2, ..., noden), and the risk probability of the path is calculated as shown in formula (2). Calculate the risk probability of all paths, sort them from high to low, and take the risk probability of the 80th path to represent the overall management risk probability of the domain name. The 80% ratio mainly considers that as long as 20% of the paths are available, the domain name resolution can be guaranteed to be available. Therefore, the risk probability of the 80th path ensures that 20% of the paths have a risk probability less than or equal to this risk probability. Of course, this is just a predefined threshold, which can be gradually adjusted in actual analysis and operation to find a path position that reasonably reflects the overall risk probability of the domain name.

[0119] Therefore, the domain name management-side risk analysis method based on domain name resolution dependency search tree in this application can expand the existing domain name risk analysis focusing on resolution-side risks, making the domain name risk analysis more complete and providing a new scope of attention for addressing domain name risks. For example, in addition to the various attack risks faced by domain names during resolution, it also considers the risks arising from the domain name's dependence on other resources during registration and operation, especially the impact of dependent foreign resources such as foreign registrars and foreign top-level domain registries. On the other hand, the domain name dependency search tree analysis method proposed in this application not only provides a simple and efficient dependency analysis method for domain name risk analysis, but also provides a simple and efficient expression and use of domain name dependencies for the analysis of other dimensions of the domain name resolution process.

[0120] Reference Figure 7 As shown, one embodiment of this application also provides an electronic device, including:

[0121] One or more processors 701;

[0122] The memory 702 stores one or more programs that, when executed by one or more processors 701, cause the one or more processors 701 to implement the methods provided in any embodiment of this application.

[0123] The memory 702, as a non-transitory network system, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, the memory 702 may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 702 may optionally include remotely located memories 702 relative to the processor 701, which can be connected to the processor 701 via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0124] The memory 702 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 702 can store the operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 702 and is called and executed by the processor 701.

[0125] The processor 701 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0126] In some embodiments, the electronic device further includes:

[0127] Input / output interfaces are used to implement information input and output;

[0128] The communication interface is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0129] The bus transmits information between various components of the device (such as processor 701, memory 702, input / output interface, and communication interface);

[0130] The processor 701, memory 702, input / output interface, and communication interface can communicate with each other within the device via a bus.

[0131] An embodiment of this application also provides a computer-readable storage medium storing computer-executable instructions for performing the methods provided in any embodiment of this application.

[0132] One embodiment of this application also provides a computer program product, including a computer program or computer instructions stored in a computer-readable storage medium. The processor of an electronic device reads the computer program or computer instructions from the computer-readable storage medium and executes the computer program or computer instructions, causing the electronic device to perform the method provided in any embodiment of this application.

[0133] The system architecture and application scenarios described in this application are intended to more clearly illustrate the technical solutions of this application and do not constitute a limitation on the technical solutions provided in this application. Those skilled in the art will understand that as system architectures evolve and new application scenarios emerge, the technical solutions provided in this application are also applicable to similar technical problems.

[0134] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0135] In hardware implementations, the division between functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, as is known to those skilled in the art, communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0136] The terms “component,” “module,” “system,” etc., used in this specification are used to refer to computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, a program, or a computer. As illustrated, applications running on computing devices and computing devices can both be components. One or more components may reside in a process or execution thread, and components may be located on a single computer or distributed among two or more computers. Furthermore, these components can be executed from various computer-readable media on which various data structures are stored. Components can communicate, for example, via local or remote processes based on signals having one or more data packets (e.g., data from two components interacting with another component between a local system, a distributed system, or a network, such as the Internet interacting with other systems via signals).

[0137] The above description, with reference to the accompanying drawings, illustrates some embodiments of this application, but does not limit the scope of the invention. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and spirit of this invention should be considered within the scope of this application.

Claims

1. A domain name risk assessment method, characterized in that, The domain name risk assessment method includes: Obtain the target domain name to be assessed for risk; Based on the target domain name, determine the DNS dependency path tree corresponding to the target domain name; A depth-first search is performed on the resolution dependency path tree to determine each resolution dependency path of the target domain name; each resolution dependency path represents a resolution process for the corresponding target domain name; Obtain the attribute risk index of the node risk attribute of each node on the parsed dependency path tree; Based on the parsing dependency paths and the risk indicators of each attribute, the path risk indicators of each parsing dependency path are calculated. The path risk indicators of the target domain name are sorted from high to low to obtain a path risk sequence; Obtain the path security threshold ratio. The target location is determined based on the path security threshold ratio and the total number of paths that the target domain name depends on for resolution. Select the path risk indicator corresponding to the target location from the path risk sequence as the target risk indicator.

2. The domain name risk assessment method according to claim 1, characterized in that, The step of calculating the path risk index for each resolution dependency path based on the resolution dependency path and each attribute risk index includes: Based on the attribute risk index of the node risk attribute of each node, determine the node risk index of each node in each of the parsing dependency paths. Based on the node risk indicators, determine the security indicators for each node; The path security index of each of the nodes of the same resolution dependency path is determined by performing a product operation. Based on the path security indicators described, determine the path risk indicators for each of the parsing dependency paths.

3. The domain name risk assessment method according to claim 2, characterized in that, The node risk attributes include institutional attributes, server operation attributes, and network operator attributes. The step of determining the node risk index for each node in each of the resolved dependency paths based on the attribute risk indexes of each node's node risk attributes includes: Obtain the risk coefficients of the institutional attributes, the server operation attributes, and the network operator attributes; The node risk index of each node in each of the parsing dependency paths is determined by weighted calculation based on the risk coefficients and attribute risk indicators of the same node.

4. The domain name risk assessment method according to claim 3, characterized in that, The risk coefficients for obtaining the institutional attributes, server operation attributes, and network operator attributes include: If the node risk index of the node to be calculated at the current moment is not found in the preset cache area, the risk coefficients of the organization attribute, the server operation attribute, and the network operator attribute are obtained; wherein, the cache area is used to cache the node risk index of each node that has been calculated on each of the resolution dependency paths. After determining the node risk index of each node in each of the parsing dependency paths by weighted calculation based on the risk coefficients and attribute risk indices of the same node, the method further includes: The node risk index of the node is associated with the node and stored in the cache.

5. The domain name risk assessment method according to claim 1, characterized in that, The dependency path tree is determined through the following steps: The target domain name is split into regions to obtain the regions of the target domain name and the region dependencies; Based on each region and each preset authoritative server, the regional authority dependency relationship is obtained; Based on the regional dependency relationship and regional authority dependency relationship of the target domain name, construct the resolution dependency path tree.

6. The domain name risk assessment method according to claim 5, characterized in that, The step of constructing a DNS dependency path tree based on the regional dependency relationship and regional authority dependency relationship of the target domain name includes: Based on the region dependency relationship, the regions of the target domain name are traversed level by level. Based on the regional authority dependency relationship, the target authority server for each traversed region is determined. The target authority server is the authority server that did not participate in the construction of the dependency path resolution. Once all zones of the target domain have been traversed, the authoritative servers obtained from the traversal are connected sequentially according to a preset hierarchical order to construct a resolution dependency path for the target domain. If there is an authoritative server in the region dependency relationship that did not participate in building and resolving the dependency path, jump to the step of traversing each region of the target domain name level by level according to the region dependency relationship; When all authoritative servers in the aforementioned regional dependency relationship participate in constructing the dependency resolution path, the dependency resolution path tree is obtained based on the constructed dependency resolution paths.

7. A domain name risk assessment device, characterized in that, The first acquisition module is used to acquire the target domain name for risk assessment; The determination module is used to determine the DNS dependency path tree corresponding to the target domain name based on the target domain name; The search module is used to perform a depth-first search on the resolution dependency path tree to determine each resolution dependency path of the target domain name; each resolution dependency path represents a resolution process of the corresponding target domain name; The second acquisition module is used to acquire the attribute risk index of the node risk attribute of each node on the parsed dependency path tree. The path risk index determination module is used to calculate the path risk index of each parsing dependency path based on the parsing dependency path and each attribute risk index. The target risk indicator module is used to sort the various path risk indicators of the target domain name from high to low to obtain a path risk sequence. Obtain the path security threshold ratio, and determine the target location based on the path security threshold ratio and the total number of paths that the target domain name depends on; Select the path risk indicator corresponding to the target location from the path risk sequence as the target risk indicator.

8. An electronic device, comprising: A memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, when the processor executes the computer program, it implements the domain name risk assessment method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, It includes storing computer-executable instructions, which are executed by a processor to implement the domain name risk assessment method as described in any one of claims 1 to 6.

Images