Domain name risk detection method, device, equipment, storage medium and product

Abstract

The application relates to the technical field of Internet security, and discloses a domain name risk detection method, device, equipment, storage medium and product. The method comprises the following steps: in response to an input question, determining a to-be-detected domain name based on the input question, querying an associated domain name corresponding to the to-be-detected domain name in a multi-relation graph, obtaining a query result, the multi-relation graph comprising domain name nodes and relations between the domain name nodes, the relations comprising multiple relation levels, wherein at least one relation level is subjected to a propagation constraint that cannot form a high-risk disposal conclusion alone, and generating a risk detection result of the to-be-detected domain name according to the query result. According to the application, the differentiated semantics of different relation levels are retained in the multi-relation graph, and the propagation constraint is applied to weak relations, so that the risk label can be prevented from being diffused along the weak relations, the probability that a normal website is misjudged as a high risk can be reduced, and the accuracy of domain name risk detection can be improved.

Description

Technical Field

[0001] This application relates to the field of internet security technology, and in particular to a domain name risk detection method, device, equipment, storage medium, and product. Background Technology

[0002] Currently, internet domain name governance involves a massive number of websites, constantly changing pages, and infrastructure information. A single domain name may be associated with other domain names through various relationships such as the registration entity, site icon, root domain or trunk, page title, and IP address, and simultaneously possesses attributes such as index volume, business category, community affiliation, and historical changes. Therefore, relevant domain name risk detection methods typically require risk aggregation based on the relationships between domain names when conducting risk detection.

[0003] However, risk detection methods for related domains often treat relationships with varying degrees of evidence equally when aggregating risks. This can lead to risk labels being incorrectly propagated along weak relationships, causing legitimate websites to be misjudged. For example, in scenarios involving shared hosting, content delivery networks, or proxy networks, multiple websites without direct control relationships may share an IP address. If shared IP addresses are treated the same as strong relationships such as shared registration entities or shared icons, risk labels may be incorrectly propagated along weak relationships, causing legitimate websites to be misjudged. Summary of the Invention

[0004] The main purpose of this application is to provide a domain name risk detection method, device, equipment, storage medium and product, which aims to solve the technical problem that related domain name risk detection methods usually treat relationships with different strengths of evidence equally when performing risk aggregation, which may lead to the erroneous spread of risk labels along weak relationships and cause misjudgment of normal websites.

[0005] To achieve the above objectives, this application provides a domain name risk detection method, which includes: In response to the input question, the domain name to be detected is determined based on the input question; The associated domains corresponding to the domain to be detected are queried in the multi-relationship graph to obtain the query results. The multi-relationship graph includes domain nodes and the relationships between each domain node. The relationships include multiple relationship levels, wherein at least one relationship level is subject to the propagation constraint that a high-risk disposal conclusion cannot be formed independently. The risk detection result of the domain name to be detected is generated based on the query result.

[0006] Optionally, querying the associated domains corresponding to the domain name to be detected in the multi-relationship graph to obtain the query results includes: Invoke a constrained agent, which is configured to have read-only access to the multi-relationship graph but not write access. The constrained agent queries the associated domains corresponding to the domain to be detected in the multi-relationship graph to obtain the query results.

[0007] Optionally, obtaining query results by querying the associated domains corresponding to the domain name to be detected in the multi-relationship graph through the constrained agent includes: The constrained agent queries the associated domains corresponding to the domain to be detected in the multi-relationship graph to obtain a set of candidate domains. For each candidate domain name in the candidate domain name set, generate a corresponding structured conclusion; The structured conclusions are subjected to partition consistency verification, and the structured conclusions that pass the partition consistency verification are determined as query results.

[0008] Optionally, generating a corresponding structured conclusion for each candidate domain name in the candidate domain name set includes: For each candidate domain name in the candidate domain name set, obtain the corresponding set of evidence objects; The disposal partition of the candidate domain name is determined based on the relationship level and evidence type of each piece of evidence in the evidence object set; Structured conclusions are generated based on the disposal partitions, which include a trusted zone, a gray zone, and a deletion candidate zone.

[0009] Optionally, the partition consistency check includes at least one of completeness check, mutual exclusion check, and constraint check, and the partition consistency check of the structured conclusion includes at least one of the following: Verify that each candidate domain in the candidate domain set has a corresponding structured conclusion; Verify that the processing partitions of each structured conclusion are pairwise disjoint, and that the union of all processing partitions covers the candidate domain name set; The verification showed that weak relation level evidence in the structured conclusions was not used alone to identify candidate domains as deletion candidate areas.

[0010] Optionally, the step of obtaining a candidate domain name set by querying the associated domain names corresponding to the domain name to be detected in the multi-relationship graph through the constrained agent includes: The constrained agent queries the associated domains corresponding to the domain to be detected in the multi-relationship graph to obtain the returned evidence objects. The returned evidence object is compared with the expected evidence to generate evidence gap information; The query continues based on the evidence gap information, and a set of candidate domain names is generated based on the results of the continued query.

[0011] Optionally, determining the structured conclusion passed by the partition consistency check as the query result includes: Extract verifiable numerical claims from the structured conclusions of the partition consistency check, wherein the verifiable numerical claims include at least one of index size, ranking, number of nodes, and community size; The verifiable numerical claims are matched and verified with the original numerical values ​​in the corresponding evidence objects according to the domain name identifier and field type; If the matching verification passes, the structured conclusion that passes the partition consistency verification will be determined as the query result.

[0012] Optionally, before obtaining the candidate domain name set by querying the associated domain names corresponding to the domain name to be detected in the multi-relationship graph through the constrained agent, the method further includes: Based on the input question and the preset tool catalog, the constrained intelligent agent generates a tool invocation plan; Accordingly, the step of obtaining a candidate domain name set by querying the associated domain names corresponding to the domain name to be detected in the multi-relationship graph through the constrained intelligent agent includes: Based on the tool invocation plan, the constrained agent queries the associated domains corresponding to the domain to be detected in the multi-relationship graph to obtain a set of candidate domains.

[0013] Optionally, the domain name risk detection method further includes: In response to the update completion signal of the multi-relationship graph, an inspection agent is triggered to perform a full-graph inspection of the multi-relationship graph. The inspection agent is configured to have only read-only access to the multi-relationship graph and operates independently of the constrained agent.

[0014] Optionally, the triggering inspection agent performs a full-graph inspection of the multi-relationship graph, including: The inspection agent is triggered to perform data quality verification on the multi-relationship graph. If the data quality verification result is unsuccessful, a data alarm will be generated and the full map inspection will be stopped. If the data quality verification result is passed, an inspection report is generated based on the multi-relationship graph that passed the data quality verification.

[0015] Optionally, if the data quality verification result is passed, an inspection report is generated based on the multi-relationship graph that passed the data quality verification, including: If the data quality verification result is passed, a global indicator snapshot is generated for the multi-relationship graph that has passed the data quality verification. The global metric snapshot is compared with the historical baseline, and anomaly candidates are determined based on the comparison results; The abnormal candidate is subjected to secondary evidence collection. Based on the results of the secondary evidence collection, the abnormal candidate is converted into an inspection case, and an inspection report is generated based on the inspection case.

[0016] Furthermore, to achieve the above objectives, this application also proposes a domain name risk detection device, which includes: The domain name determination module is used to determine the domain name to be detected based on the input question in response to the input question. The domain name detection module is used to query the associated domain names corresponding to the domain name to be detected in the multi-relationship graph and obtain the query results. The multi-relationship graph includes domain name nodes and the relationships between each domain name node. The relationships include multiple relationship levels, wherein at least one relationship level is subject to the propagation constraint that it cannot form a high-risk disposal conclusion on its own. The result generation module is used to generate risk detection results for the domain name to be detected based on the query results.

[0017] Optionally, the domain name detection module is further configured to invoke a constrained agent, which is configured to have read-only access to the multi-relationship graph but not write access; and to query the associated domain names corresponding to the domain name to be detected in the multi-relationship graph through the constrained agent to obtain the query results.

[0018] Optionally, the domain name detection module is further configured to query the associated domain names corresponding to the domain name to be detected in the multi-relationship graph through the constrained agent to obtain a set of candidate domain names; generate a corresponding structured conclusion for each candidate domain name in the set of candidate domain names; perform partition consistency verification on the structured conclusions; and determine the structured conclusions that pass the partition consistency verification as the query result.

[0019] Optionally, the domain name detection module is further configured to obtain a corresponding set of evidence objects for each candidate domain name in the candidate domain name set; determine the disposal partition of the candidate domain name according to the relationship level and evidence type of each piece of evidence in the set of evidence objects; and generate a structured conclusion based on the disposal partition, wherein the disposal partition includes a trusted zone, a gray zone, and a candidate deletion zone.

[0020] Optionally, the partition consistency check includes at least one of completeness check, mutual exclusion check, and constraint check; the domain name detection module is further used to check that each candidate domain name in the candidate domain name set has a corresponding structured conclusion; to check that the processing partitions of each structured conclusion are pairwise disjoint, and that the union of all processing partitions covers the candidate domain name set; and to check that the weak relation level evidence in the structured conclusion is not used alone to determine the candidate domain name as a deletion candidate area.

[0021] Optionally, the domain name detection module is further configured to query the associated domain names corresponding to the domain name to be detected in the multi-relationship graph through the constrained agent to obtain the returned evidence objects; compare the returned evidence objects with the expected evidence to generate evidence gap information; continue to execute the query based on the evidence gap information, and generate a candidate domain name set based on the results of the continued query.

[0022] In addition, to achieve the above objectives, this application also proposes a domain name risk detection device, which includes a memory, a processor, and a domain name risk detection program stored in the memory and executable on the processor. The domain name risk detection program is configured to implement the domain name risk detection method described above.

[0023] In addition, to achieve the above objectives, this application also proposes a storage medium storing a domain name risk detection program, which, when executed by a processor, implements the domain name risk detection method as described above.

[0024] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a domain name risk detection program. When the domain name risk detection program is executed by a processor, it implements the domain name risk detection method as described above.

[0025] One or more technical solutions proposed in this application have at least the following technical effects: This application discloses a method for responding to an input question, determining the domain name to be detected based on the input question, querying the associated domain names corresponding to the domain name to be detected in a multi-relationship graph, and obtaining query results. The multi-relationship graph includes domain name nodes and the relationships between each domain name node. The relationships include multiple relationship levels, wherein at least one relationship level is subject to the propagation constraint that it cannot independently form a high-risk disposal conclusion. The risk detection result of the domain name to be detected is generated based on the query results. This application can avoid the erroneous spread of risk labels along weak relationships by preserving the differentiated semantics of different relationship levels in the multi-relationship graph and imposing propagation constraints on weak relationships, thereby reducing the probability of normal websites being misjudged as high-risk and improving the accuracy of domain name risk detection. Attached Figure Description

[0026] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0027] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 This is a flowchart illustrating the first embodiment of the domain name risk detection method of this application; Figure 2 This is a flowchart illustrating the second embodiment of the domain name risk detection method of this application; Figure 3 This is a flowchart illustrating the third embodiment of the domain name risk detection method of this application; Figure 4 This is a flowchart illustrating the fourth embodiment of the domain name risk detection method of this application; Figure 5 This is a diagram illustrating the overall structure of a domain name risk management system according to an embodiment of the domain name risk detection method of this application. Figure 6 This is a schematic diagram of the module structure of the domain name risk detection device according to an embodiment of this application; Figure 7 This is a schematic diagram of the hardware operating environment involved in the domain name risk detection method in this application embodiment.

[0029] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0030] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0031] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0032] This application provides a domain name risk detection method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the domain name risk detection method of this application.

[0033] In the first embodiment, the domain name risk detection method includes: Step S10: In response to the input question, determine the domain name to be detected based on the input question.

[0034] It should be noted that the execution subject of this embodiment can be a domain name risk detection device with data processing, network communication and program running functions, such as a server, computer, or other electronic devices that can achieve the same or similar functions. This embodiment does not limit this.

[0035] It should be understood that the input question can refer to a query request related to domain name risk submitted by the user to the system in the form of natural language or structured instructions. For example, querying whether a domain name is risky or analyzing the risk status of domain names under a certain category. The domain name to be detected can refer to the specific domain name that needs to be used as the object of risk detection, as determined by the semantics of the input question.

[0036] In the specific implementation, the system receives input questions submitted by users and performs intent recognition and semantic parsing on the input questions to extract the domain name identifier, business category, community scope, or other limiting conditions involved. Based on the parsing results, the system determines the type of input question. For questions that directly specify a domain name, the specified domain name is determined as the domain name to be detected. For questions that involve category ranking, community analysis, etc., without directly specifying a domain name, a set of candidate domain names is first obtained through deterministic query, and then the domain names in the candidate set are determined one by one as the domain names to be detected.

[0037] Step S20: Query the associated domains corresponding to the domain to be detected in the multi-relationship graph to obtain the query results. The multi-relationship graph includes domain nodes and the relationships between each domain node. The relationships include multiple relationship levels, wherein at least one relationship level is subject to the propagation constraint that a high-risk disposal conclusion cannot be formed independently.

[0038] Understandably, a domain node can refer to a node representing a single domain in a multi-relationship graph. A domain node can contain attributes such as domain identifier, latest index (latest_index), business category, community identifier (community_id), filing status, page characteristics, data date, and data source. The domain identifier can use a normalized domain name string or its stable hash value to avoid differences in case sensitivity, internationalized domain names, and trailing dots.

[0039] A relationship can refer to an association between two domain name nodes. A relationship can include at least one of the following: shared ICP (Internet Registration Certificate), shared site icon (SHARE_ICON), shared root domain (SHARE_ROOT), shared page title (SHARE_TITLE), shared trunk feature (SHARE_TRUNK), and shared IP address (SHARE_IP). Each relationship record includes information such as relationship type, direction, generation time, data source, relationship value, and confidence level.

[0040] Relationship level refers to the classification of relationships based on the strength of evidence. Relationship levels can be divided into strong relationships (e.g., shared registration entity, shared icon, shared root domain), medium relationships (e.g., shared title, shared trunk), and weak relationships (e.g., shared IP). Relationship level is not a fixed value; it can be adjusted based on data source reliability, relationship stability time, number of neighbors, whether it hits shared infrastructure, and human feedback to increase relationship confidence. However, regardless of changes in confidence, weak relationships are subject to pre-defined, separate determination limitations. In practice, relationship levels can be as shown in Table 1: Table 1 Relationship Level Table

[0041] It should be understood that propagation constraints can refer to restrictive rules imposed on specific relationship levels during the risk propagation process. A high-risk handling conclusion can refer to a conclusive judgment that a domain name requires high-level handling measures such as deletion or blocking. Related domains can refer to other domains that have at least one relationship with the domain to be detected in a multi-relationship graph.

[0042] In the specific implementation, starting with the domain name to be detected, the system traverses the relationship edges directly or indirectly connected to the domain name node in the multi-relationship graph. It retrieves associated paths such as shared registration entity, shared site icon, shared root domain, shared page title, shared trunk characteristics, and shared IP address according to the relationship type. During the traversal, each relationship edge is labeled with its relationship level (strong, medium, weak), and relationship levels subject to propagation constraints (such as weak relationships with shared IP addresses) are specially marked, recording the constraint attribute that the relationship cannot be used alone as a basis for high-risk handling. The retrieved associated domain names are deduplicated, sorted, and truncated to avoid excessively large returned results. All associated domain names and their corresponding relationship types, relationship levels, relationship paths, data sources, confidence levels, and other information are assembled into structured query results and normalized into a unified evidence object output.

[0043] Step S30: Generate the risk detection result of the domain name to be detected based on the query result.

[0044] It is understandable that risk detection results can refer to a comprehensive judgment output based on the query results regarding the risk status of the domain name to be detected, which may include risk level, risk cause, supporting evidence, and disposal suggestions.

[0045] In its implementation, the system receives query results from multi-relationship graph query methods, analyzes the risk status of each associated domain name, and counts the number and combinations of strong, medium, and weak relationships between the domain to be detected and the risk domain. Risk scoring is performed based on the evidentiary strength corresponding to the relationship level. Strong relationships directly support a higher risk judgment, medium relationships serve as supplementary evidence, and weak relationships are only used as reference signals and cannot independently form a high-risk handling conclusion. Combining the domain's own attribute information (such as index volume, business classification, filing status, etc.) with associated risk evidence, a structured risk conclusion is formed, including risk level, risk cause code, supporting evidence identifier, confidence level, and whether manual review is required. The risk conclusion undergoes consistency verification; after confirming that weak relationships have not been used alone for high-risk handling and that there are no duplicate or omitted candidate domains, the risk detection result is output.

[0046] This embodiment preserves the differentiated semantics of different relationship levels in the multi-relation graph and imposes propagation constraints on weak relationships, thereby preventing risk labels from being erroneously spread along weak relationships. This reduces the probability of normal websites being misjudged as high-risk and improves the accuracy of domain name risk detection.

[0047] Reference Figure 2 , Figure 2 This is a flowchart illustrating the second embodiment of the domain name risk detection method of this application, based on the above. Figure 1 The first embodiment shown presents a second embodiment of the domain name risk detection method of this application.

[0048] In the second embodiment, step S20 includes: Step S201: Invoke the constrained agent, which is configured to have read-only access to the multi-relationship graph but not write access.

[0049] It should be understood that a constrained agent can refer to an agent program that runs within preset permission boundaries and resource limits. The constrained agent is configured to have read-only access to multiple relation graphs but no write access. It can adaptively select and call graph query tools according to the input question, but it may not modify, delete or add any graph data.

[0050] Read-only access permissions allow for operations such as reading, querying, and retrieving data from a multi-relationship graph that do not alter the graph's data state. Write permissions, on the other hand, allow for operations such as adding nodes, modifying attributes, and creating or deleting relationship edges from a multi-relationship graph that change the graph's data state.

[0051] In the specific implementation, after receiving the domain name to be detected, the runtime environment of the constrained agent is initialized, and an independent runtime identifier, session state, execution budget, and tool directory are assigned to the constrained agent. Permissions are configured for the constrained agent, limiting its access to the multi-relationship graph to read-only mode and blocking all write, modify, and delete interfaces to ensure that the agent cannot make any changes to the graph data during operation. Parameters such as the domain name to be detected, input problem summary, graph data date, and maximum number of execution steps are passed to the constrained agent to trigger its start-up and execution. The running status of the constrained agent is monitored, and its input, output, time consumption, and remaining budget for each step are recorded to ensure that it completes the query task within the preset resource limit.

[0052] Step S202: The constrained agent queries the associated domain name corresponding to the domain name to be detected in the multi-relationship graph to obtain the query result.

[0053] In the specific implementation, the constrained agent generates a query plan based on the domain name to be detected and the input question. The planning module determines the type of graph query tool to be called (such as domain name details query, neighbor query by relationship type, subgraph query, etc.) and corresponding parameters. The tool execution module calls the multi-relationship graph through a read-only access interface. Starting from the domain name to be detected, it traverses all kinds of relationship edges connected to the domain name node and retrieves the associated domain names under the associated paths such as shared filing entity, shared site icon, shared root domain, shared page title, shared trunk features, and shared IP address. The original results returned by the query are converted into a unified evidence object. The associated domain names are deduplicated, sorted, and truncated in size. The type, level, path, data source, and confidence level of each relationship are marked. The review module judges whether the obtained evidence is sufficient. If there is a gap in the evidence, a supplementary query action is generated to continue the query. If the evidence is sufficient or the execution limit is reached, the query is stopped and the query results are output.

[0054] This embodiment limits the agent's operations on the multi-relationship graph to read-only permissions, thereby ensuring that the agent can complete the associated domain name query and evidence collection, while eliminating the risk of the agent accidentally modifying or deleting the graph data from the permission level, and thus ensuring the integrity and security of the original multi-relationship graph data.

[0055] Furthermore, to separate natural language reasoning from database facts and prevent the model from altering the original values ​​in subsequent steps, all tool outputs are normalized into evidence objects before entering the agent's context. These evidence objects include at least: evidence identifier, query identifier, data date, target domain name, evidence type, original result, relation path, relation level, data source, generation time, and verification status. In a specific implementation, evidence objects can be as shown in Table 2. Table 2. List of Evidence Objects

[0056] Reference Figure 3 , Figure 3 This is a flowchart illustrating the third embodiment of the domain name risk detection method of this application. Based on the above embodiments, the third embodiment of the domain name risk detection method of this application is proposed.

[0057] In the third embodiment, step S202 includes: Step S2021: The constrained agent queries the associated domains corresponding to the domain to be detected in the multi-relationship graph to obtain a set of candidate domains.

[0058] It should be understood that the candidate domain name set can refer to the set of domain names that need to be risk-assessed and partitioned by the constrained agent in the multi-relationship graph.

[0059] In its implementation, the constrained agent starts with the domain name to be detected and traverses various relational edges directly or indirectly connected to the domain name node in the multi-relationship graph. It retrieves associated domain names under related paths such as shared filing entities, shared site icons, shared root domains, shared page titles, shared trunk features, and shared IP addresses. The retrieved associated domain names are then filtered, with only the target domain name explicitly specified by the user, the domain name marked as the investigation target in the plan, the domain name that meets the risk threshold and has at least one non-weak evidence, and the domain name cited in the inspection case included in the candidate domain name set. Neighboring domain names that only appear as background evidence are excluded. The domain names in the candidate domain name set are deduplicated to ensure that each domain name appears uniquely in the set. A unified query identifier is assigned to the candidate domain name set, and the source type and corresponding relational evidence of each domain name in the set are recorded as input for the subsequent generation of structured conclusions.

[0060] Step S2022: Generate a corresponding structured conclusion for each candidate domain name in the candidate domain name set.

[0061] It is understandable that structured conclusions can refer to conclusive data tuples with fixed field formats generated for each candidate domain name. These tuples may include fields such as domain identifier, disposition, reason codes, supporting evidence IDs, confidence level, and whether manual review is required. These fields are used to separate natural language reasoning from database facts and avoid ambiguity in the expression of conclusions.

[0062] In the specific implementation, each candidate domain in the candidate domain set is traversed, and all relationship evidence, its own attribute information, and historical risk records corresponding to that domain are retrieved. Risk assessment is conducted according to the evidentiary strength corresponding to the relationship level. Among them, strong relationships (such as shared filing entity, shared icon, shared root domain) can directly support a higher risk judgment, medium relationships (such as shared title, shared trunk) serve as auxiliary evidence, and weak relationships (such as shared IP) serve only as reference signals and cannot form a high-risk disposal conclusion on their own. A structured conclusion tuple is generated for each candidate domain, and the following fields are filled in sequentially: domain identifier (domain), disposal partition (disposition, which takes the value of one of the trusted zone / grey zone / deleted candidate zone), risk reason code (reason_codes), supporting evidence IDs (supporting_evidence_ids), confidence level (confidence), and whether manual review is required (requires_review). The structured conclusions of all candidate domains are summarized into a conclusion set, and the generation time, model version, and data date of each conclusion are recorded to ensure that the conclusions are traceable.

[0063] Step S2023: Perform a partition consistency check on the structured conclusion, and determine the structured conclusion that passes the partition consistency check as the query result.

[0064] In the specific implementation, it checks whether each candidate domain in the candidate domain set has been generated and only one structured conclusion has been generated. If there are omissions or duplicates, it triggers regeneration or deduplication. It verifies whether the three partitions of trusted zone, gray zone, and deletion candidate zone are mutually exclusive, that is, the same candidate domain cannot be classified into two or more partitions at the same time. It verifies whether the union of the three partitions is equal to the candidate domain set to ensure that no candidate domain is omitted from the partitions. It verifies whether candidate domains with only weak evidence of shared IP are incorrectly classified into the deletion candidate zone. If so, they are downgraded to the gray zone. It then verifies whether whitelisted or high-value sites need to be forced into the manual review process. The structured conclusion set that passes all the above verification items is determined as the final query result. For conclusions that fail the verification, the abnormal reasons are recorded and regeneration or manual intervention is triggered.

[0065] This embodiment transforms the associated domain names obtained from the graph query into a structured set of conclusions with a fixed field format and satisfying complete mutual exclusion constraints. This avoids problems such as missing candidate domain names, duplicate attribution, weak relationship determination, and contradictory partitions, thereby ensuring the accuracy, consistency, and interpretability of the query results.

[0066] Furthermore, in order to efficiently complete the retrieval of related domain names within the preset resource limit, while ensuring the traceability and controllability of the query process, before step S2021, the method further includes: generating a tool invocation plan through the constrained agent based on the input question and the preset tool directory; correspondingly, step S2021 includes: querying the related domain names corresponding to the domain name to be detected in the multi-relationship graph through the constrained agent based on the tool invocation plan, and obtaining a set of candidate domain names.

[0067] It should be understood that the preset tool catalog can refer to a pre-configured list of tools that can be called by constrained intelligent agents, which includes at least graph query tools, community query tools, ranking query tools, and historical query tools.

[0068] A tool invocation plan can refer to an ordered sequence of actions generated by the planning module of a constrained agent based on an input problem and a preset tool catalog, which guides the execution of subsequent tools. Each step in the plan includes at least the tool name, parameters, expected evidence, stopping conditions, and degradation actions after failure. The plan does not need to generate a fixed complete link at once, but can be dynamically adjusted according to the evidence obtained.

[0069] In its implementation, the constrained agent receives input questions and performs semantic parsing to extract the target domain name, investigation intent (such as relationship investigation, risk interpretation, community analysis, etc.), and limiting conditions. The planning module reads a preset tool catalog, matches the applicable tool type according to the question intent, and prioritizes the tool action with the highest information gain. For each step in the plan, the module fills in the tool name, calling parameters, expected evidence type, stopping conditions (such as sufficient evidence, reaching the maximum number of steps, etc.), and degradation actions after failure (such as switching to a backup query when the tool times out). The generated tool calling plan is stored in the agent's running state, and the plan generation time, model version, and corresponding input question identifier are recorded as the basis for subsequent tool execution. The plan can be dynamically supplemented or adjusted during execution based on the review results.

[0070] The constrained agent reads the tool invocation plan, executing the steps sequentially. Each step calls the corresponding graph query tool (such as domain name details query, neighbor query by relationship type, subgraph query, etc.) and passes in the parameters specified in the plan. The tool execution module calls the multi-relationship graph through a read-only access interface, starting with the domain name to be detected, traversing various relationship edges connected to the domain name node, and retrieving associated domain names under related paths such as shared filing entity, shared site icon, shared root domain, shared page title, shared trunk features, and shared IP address. The raw results returned by the query are converted into a unified evidence object, and the associated domain names are deduplicated, sorted, and truncated in size. The type, level, path, data source, and confidence level of each relationship are marked. The review module compares the obtained evidence with the expected evidence in the plan. If there is an evidence gap, a supplementary query action is generated and added to the plan for continued execution. If the tool fails, the pre-set degradation action in the plan is triggered. When the stopping conditions are met (sufficient evidence, reaching the maximum number of execution steps, or the continuous failure limit), the associated domain names obtained by the query are filtered according to the candidate domain name screening rules to form a candidate domain name set.

[0071] Furthermore, in order to enable the constrained agent to dynamically identify insufficient evidence and adaptively supplement the query during the query process, thereby ensuring that the relational evidence on which the candidate domain name set is based is sufficient and complete within the preset resource limit and improving the reliability of subsequent risk assessment, step S2021 includes: querying the associated domain name corresponding to the domain name to be detected in the multi-relationship graph through the constrained agent to obtain the returned evidence object; comparing the returned evidence object with the expected evidence to generate evidence gap information; continuing to execute the query based on the evidence gap information, and generating a candidate domain name set based on the results of the continued query.

[0072] Understandably, expected evidence can refer to the types and scope of evidence that are pre-defined in the tool's query plan for each step of the query, and the information expected to be obtained through that query. Evidence gap information can refer to the types of evidence that have not yet been obtained or are insufficient, and the corresponding domain names to be investigated, identified after comparing the returned evidence objects with the expected evidence.

[0073] In the specific implementation, the constrained agent, according to the tool invocation plan, invokes the graph query tool to perform an association query in the multi-relation graph starting from the domain name to be detected, traversing all kinds of relationship edges connected to the domain name node; the tool execution module receives the raw results returned by the graph query, including information such as the list of associated domain names, relationship type, relationship value, data source and confidence level; the raw results are normalized into evidence objects in a unified format, and fields such as evidence identifier, query identifier, data date, target domain name, evidence type, raw result, relationship path, relationship level, data source, generation time and verification status are filled in sequentially; the returned evidence objects are stored in the evidence buffer of the agent's running state, and the return size is limited to avoid context overflow.

[0074] The review module reads the expected evidence preset in the tool's call plan for the current query step, clarifying the expected evidence type (such as shared filing entity, shared icon, shared root domain, etc.) and corresponding target domain name; it traverses the returned evidence objects, performs matching statistics according to evidence type and target domain name, and determines which expected evidence has been obtained, which has not been obtained, or which has been obtained insufficiently; it analyzes the unobtained evidence types, distinguishing whether the relationship does not exist in the graph, the query path does not cover the relationship, or the returned results are truncated, resulting in omission; it generates evidence gap information, recording the evidence type corresponding to the gap, the domain name to be investigated, the reason for the gap, and the suggested direction for supplementary investigation, as the basis for subsequent continued queries, and outputs the decision judgment of "continue", "supplementary investigation", "modify investigation" or "stop".

[0075] Based on the evidence gap information, the constrained agent generates tool invocation actions for supplementary or modified investigations through the planning module, selects the corresponding graph query tool that can fill the gap, and sets the parameters. The tool execution module calls the supplementary investigation tool to continue the query in the multi-relationship graph, and retrieves the missing relationship type evidence for the domain name under investigation involved in the evidence gap. For example, when there is only weak evidence of shared IP, it supplements the investigation of the filing entity, icon, or root domain relationship. The results returned by the continued query are also normalized into evidence objects, merged with existing evidence objects to remove duplicates, and the review module is triggered again to determine whether there is still an evidence gap. When the evidence gap has been filled, the maximum number of execution steps has been reached, the consecutive failure limit has been reached, or the evidence is sufficient, the query stops. All domain names that meet the candidate domain name screening rules in all query results (target domain names explicitly specified by the user, domain names marked as investigation targets in the plan, domain names that meet the risk threshold and have at least one non-weak evidence, and domain names cited in the inspection case) are summarized to generate a candidate domain name set.

[0076] Furthermore, in order to differentiate the candidate domain names based on relationship level and evidence type and impose separate determination restrictions on weak relationships, avoid misjudgments caused by treating weak relationships such as shared IPs as the same as strong relationships such as shared filing entities, ensure that the formation of high-risk disposal conclusions is supported by sufficient evidence, and improve the accuracy and security of domain name risk partitioning decisions, step S2022 includes: obtaining a corresponding set of evidence objects for each candidate domain name in the candidate domain name set; determining the disposal partition of the candidate domain name according to the relationship level and evidence type of each piece of evidence in the evidence object set; and generating a structured conclusion based on the disposal partition, wherein the disposal partition includes a trusted zone, a gray zone, and a candidate deletion zone.

[0077] It should be understood that the evidence object set can refer to the set of all evidence objects directly related to a candidate domain name, selected from all returned evidence objects. The disposal partition can refer to the risk level classification of candidate domain names based on the relationship level and evidence type of each piece of evidence in the evidence object set, including three partitions: a trusted zone, a gray zone, and a candidate deletion zone. These three partitions are pairwise disjoint, and their union equals the set of candidate domain names.

[0078] The "Trusted Zone" refers to a zone within the handling area that indicates a low risk for the domain and requires no further action. The "Gray Zone" refers to a zone within the handling area that indicates an unclear risk for the domain and requires further observation or manual review. The "Deletion Candidate Zone" refers to a zone within the handling area that indicates a high risk for the domain and recommends taking high-level handling measures such as deletion.

[0079] In the specific implementation, each candidate domain name in the candidate domain name set is traversed, and the domain name identifier of the candidate domain name is used as the search key. From all the evidence objects stored in the agent's running state, all evidence objects that match the target domain name field with the candidate domain name identifier are selected, including various relationship evidence between the candidate domain name and other domain names and attribute evidence of the domain name itself. The selected evidence objects are classified and statistically analyzed according to relationship level (strong, medium, weak) and evidence type (shared filing entity, shared icon, shared root domain, shared title, shared trunk, shared IP, etc.), and the relationship path, data source, confidence level and generation time of each piece of evidence are recorded. The classified and organized evidence objects are summarized into the evidence object set corresponding to the candidate domain name, which serves as the input for subsequent disposal partition determination, ensuring that the partition decision of each candidate domain name is based on complete and traceable evidence facts.

[0080] The system reads the evidence set corresponding to the candidate domain name, counts the number and specific types of evidence for strong, medium, and weak relationships, and identifies whether the peer domain name associated with each piece of evidence is a known risk domain name. Risk assessment is conducted based on the evidentiary validity corresponding to the relationship level. Strong relationships (such as shared registration entity, shared icon, shared root domain) directly support a higher risk judgment, medium relationships (such as shared title, shared trunk) serve as auxiliary evidence, and weak relationships (such as shared IP) serve only as reference signals. The system determines the disposal zone according to the zoning rules: if a candidate domain name has at least one strong relationship piece of evidence, or if medium relationship evidence is combined with other evidence, it is determined to be in the deletion candidate zone; if no risk-related evidence or evidence indicating normal business is found for the candidate domain name, it is determined to be in the trusted zone; if it cannot be confirmed, there are evidence conflicts, or it only has weak relationship level evidence, it is determined to be in the gray zone. Propagation constraints are executed to verify whether candidate domain names with only weak relationship level evidence are incorrectly classified into the deletion candidate zone. If so, they are forcibly downgraded to the gray zone to ensure that weak relationships do not alone form a high-risk disposal conclusion.

[0081] For each candidate domain, based on the determined disposal partition, fill in the following fields of the structured conclusion tuple in sequence: Domain identifier (domain) is the normalized identifier of the candidate domain; Disposition partition (disposition) is one of the trusted zone, gray zone, or candidate deletion zone; Risk cause codes (reason_codes) are encoded according to the relationship type and risk pattern hit in the evidence object set; Supporting evidence identifiers (supporting_evidence_ids) reference the unique identifier of each piece of evidence in the evidence object set corresponding to the candidate domain; Confidence is quantified and assigned according to the strength of evidence, the number of evidence, and the reliability of the data source; Whether manual review is required (requires_review) is marked according to the partitioning results and whether whitelists, high-value sites, or evidence conflicts are involved; Record the generation time, model version, and corresponding data date for each structured conclusion to ensure the traceability of the conclusions; Summarize the structured conclusions of all candidate domains into a conclusion set, ensuring that each candidate domain appears exactly once, the three partitions are pairwise disjoint, and the union of the three partitions equals the candidate domain set, which serves as the input for subsequent partition consistency verification.

[0082] Furthermore, in order to systematically verify the structured conclusions from multiple dimensions, ensure the integrity, consistency, and security of the partitioning decision results, and provide a reliable basis for subsequent risk management, the partitioning consistency verification includes at least one of completeness verification, mutual exclusion verification, and constraint verification. The partitioning consistency verification of the structured conclusions includes at least one of the following: verifying that each candidate domain name in the candidate domain name set has a corresponding structured conclusion; verifying that the disposal partitions of each structured conclusion are pairwise disjoint, and that the union of all disposal partitions covers the candidate domain name set; verifying that the weak relation level evidence in the structured conclusions has not been used alone to determine the candidate domain name as a deletion candidate region.

[0083] In the specific implementation, the completeness verification method takes the following steps: read the candidate domain name set, extract the domain name identifiers of all candidate domain names to form a list of domain names to be verified; traverse all structured conclusions, extract the domain name identifier field in each conclusion, and count the number of structured conclusions corresponding to each domain name identifier; compare the list of domain names to be verified with the domain name identifiers in the structured conclusions one by one to check whether there are any omissions where no structured conclusions have been generated for candidate domain names, and whether there are any duplicates where the same candidate domain name corresponds to multiple structured conclusions; if an omission is found, trigger the supplementary generation process to generate structured conclusions for the missing domain names; if a duplicate is found, retain the conclusion with the highest confidence and delete the remaining duplicate conclusions to ensure that each candidate domain name in the candidate domain name set corresponds to a unique structured conclusion.

[0084] The specific steps of the mutual exclusion verification method are as follows: Group all structured conclusions into disposal partitions (trusted zone, gray zone, and deletion candidate zone), and count the candidate domain name identifiers contained in each partition; verify whether there is an intersection between the domain name identifiers of each partition, that is, whether the same candidate domain name appears in two or more partitions at the same time. If there is an intersection, it is determined to be a mutual exclusion violation; take the union of the domain name identifiers of the three partitions and compare it with the candidate domain name set to verify whether the union completely covers all domain names in the candidate domain name set. If there are candidate domain names that are not covered by any partition, it is determined to be incomplete coverage; for domain names that violate mutual exclusion, redetermine the unique partition according to the strength of evidence. For domain names with incomplete coverage, they are defaulted to the gray zone to ensure that the disposal partitions of each structured conclusion are not intersecting pairwise and that the union of all disposal partitions covers the candidate domain name set.

[0085] The specific steps of the constraint verification method are as follows: traverse all structured conclusions in the disposal partition designated as a deletion candidate area, retrieve the set of supporting evidence objects corresponding to each conclusion, and check whether it contains only weak-relationship level evidence (such as shared IP relationship). If a candidate domain name only has weak-relationship level evidence but is classified into the deletion candidate area, it is judged as a constraint violation and downgraded to the gray area; read the preset whitelist domain name list and high-value domain name list, traverse all structured conclusions, and check whether all domain names in the list are marked as requiring manual review (requires_review field is true). If not marked, a manual review mark is forcibly added; for candidate domain names with evidence conflicts or confidence levels lower than the preset threshold, they are also marked as requiring manual review; record all constraint verification adjustment items and adjustment reasons to ensure that weak-relationship level evidence is not used alone to determine candidate domain names as deletion candidate areas, and that preset whitelist domain names or high-value domain names are all marked as requiring manual review.

[0086] Furthermore, to prevent language models from fabricating or rewriting database values, and to ensure that the values ​​in the query results are consistent with the original values ​​in the evidence objects, thereby improving the factual reliability and auditability of the risk detection results, the step of determining the structured conclusion that passed the partition consistency check as the query result includes: extracting verifiable numerical claims from the structured conclusion that passed the partition consistency check, wherein the verifiable numerical claims include at least one of index size, ranking, number of nodes, and community size; matching and verifying the verifiable numerical claims with the original values ​​in the corresponding evidence objects according to domain name identifier and field type; and if the matching and verification pass, determining the structured conclusion that passed the partition consistency check as the query result.

[0087] In the specific implementation, all structured conclusions that have passed the partition consistency check are read, and the risk cause code, supporting evidence description, and derived natural language answer text in each conclusion are traversed. Using regular expressions or semantic recognition methods, all numerical statements are extracted from the above content, and it is determined whether they belong to the category of verifiable numerical claims (at least one of the following: index size, ranking, number of nodes, and community size). For each extracted verifiable numerical claim, its corresponding domain name identifier, field type, claim value, and contextual location are recorded. All verifiable numerical claims are summarized into a list to be verified, which serves as input for subsequent numerical matching verification, ensuring that each numerical claim has a clear domain name and field attribution.

[0088] Iterate through each item in the list of verifiable numerical claims to be verified, and retrieve the matching original value from the original result field of the corresponding evidence object based on its domain name identifier and field type; verify whether the value in the verifiable numerical claim is consistent with the original value in the evidence object, and also verify whether the data dates of the two are the same. If there is a difference in the value, determine whether it is within the preset tolerance range; for claims that cannot find the corresponding original value in the evidence object, mark them as unmatched; summarize the verification results. If all verifiable numerical claims are successfully matched and the data dates are consistent and the values ​​are within the tolerance range, the matching verification is determined to be passed. If there are cases of unmatched, inconsistent data dates, or values ​​exceeding the tolerance, the matching verification is determined to be failed, and the specific failure items and reasons are recorded.

[0089] The system receives the results of numerical matching verification. If the matching verification passes, all structured conclusions that pass the partition consistency verification are determined as the final query results, and a unified query identifier and data date are assigned to the query results. If the matching verification fails, appropriate actions are taken based on the type of failure: for values ​​exceeding the tolerance, the values ​​in the structured conclusions are replaced with the original values ​​in the evidence objects; for unmatched values ​​or inconsistent data dates, output is blocked and the answer is regenerated or replaced with a program verification table; numerical matching verification is performed again on the processed structured conclusions until the verification passes; the final determined query results are stored in the session storage, and all adjustments and reasons during the verification process are recorded to ensure that the values ​​in the query results are consistent with the original values ​​in the evidence objects, are traceable and verifiable.

[0090] For ease of understanding, the following example is provided, but it does not limit this application. As an example, after receiving a problem, the system does not directly grant the interactive agent full graph or unlimited tool permissions, but instead executes the following steps in a state machine. Each step records input, output, time consumption, exceptions, and remaining budget. The specific steps include: Step 1: Receive user questions, session ID (session_id), request ID (request_id), model selection, graph data date, and maximum execution steps.

[0091] Step 2: Execute Intent Routing: For questions that can be answered directly by deterministic queries, such as current index ranking and number of categories, enter the direct query path; for complex questions such as relationship investigation, risk interpretation, and community analysis, enter the agent path.

[0092] Step 3: The planning module generates a first-step or multi-step plan based on the problem and tool catalog. Each step in the plan must include at least the tool name, parameters, expected evidence, stopping conditions, and degradation actions in case of failure.

[0093] Step 4: The tool execution module calls the graph query, community query, ranking query, or historical query tools to convert the results into a unified evidence object and limit the return size.

[0094] Step 5: The review module compares the obtained evidence with the expected evidence and outputs options to continue, supplement the investigation, modify the investigation, or stop. If continued, the next action is generated; if the maximum number of steps is reached, there are consecutive failures, or the evidence is sufficient, the process stops.

[0095] Step 6: The conclusion module generates structured conclusion tuples for candidate domains. The tuples include domain, disposition, reason_codes, supporting_evidence_ids, confidence, and requirements_review.

[0096] Step 7: The consistency verification module checks whether the conclusion is consistent with the three partitions, whether the candidate domain name is complete, whether there is duplicate ownership, whether weak relationships are used alone for deletion, and whether whitelisted or high-value sites need to be forcibly reviewed.

[0097] Step 8: The fact-checking module performs program verification on the numerical values ​​such as index count, ranking, and community ID in the answer, and then outputs the natural language answer, partitioning results, evidence citations, execution trajectory, and session identifier.

[0098] The session storage module stores user questions, final answers, structured conclusions, evidence identifiers, and manual corrections using the session_id. The next round of planning only loads historical summaries and unresolved issues related to the current question, avoiding repeatedly writing all historical text into the context. When a domain is manually moved from one partition to another, the system saves the partitions before and after the correction, the reason, the operator, the time, the data date, and the model version, rather than simply saving it locally in the browser.

[0099] Feedback logs are used to adjust relationship thresholds, evaluate alarm accuracy, or construct subsequent training sets, but production rules or online models must not be changed immediately without review to prevent erroneous feedback from becoming self-reinforcing.

[0100] After accumulating reliable labels and continuous historical data, a relationship graph encoder and a time encoder can be added to the evidence layer of this application. This enhanced implementation is not a necessary condition for this application; without deploying a deep model, the system can still use rules, statistics, and constrained agents to complete evidence collection and inspection.

[0101] The graph encoder can employ a graph convolutional network (R-GCN) or a relational attention network. The temporal encoder can use a gated recurrent unit (GRU), taking into input stable features for each domain name over N consecutive days, including index change rate, number of strong, medium, and weak relationships, proportion of risky neighbors, community changes, and historical risk scores, and outputting a trend representation and anomaly score. If the graph encoding vector is used as the GRU input daily, the same fixed version of the graph encoder should be used to generate the daily vectors to avoid representation coordinate drift caused by daily retraining.

[0102] The fusion module concatenates or weights the graph risk representation, time trend representation, and deterministic rule features, outputting graph_risk_score, trend_risk_score, and fusion_risk_score. The model scores are only used for candidate ranking and determining whether further investigation is needed; they cannot skip evidence verification and directly lead to a deletion decision.

[0103] Graph access is decoupled from agent tools via the GraphStore interface. The interface provides at least domain details, neighbor queries by relation type, community queries, ranking queries, subgraph queries, statistical queries, and health checks. The underlying layer can use Neo4j, NebulaGraph, or other property graph databases; the adapter is responsible for converting Cypher, nGQL, or other query results into unified evidence objects.

[0104] In graph databases that use directed edge storage, two edges, one forward and one reverse, can be stored for undirected business relationships, or bidirectional traversal can be used during queries. Regardless of the implementation, the adapter must ensure consistency in deduplication, sorting, truncation, data dates, and relational semantics, so that upper-layer agents and decision-making processes are not dependent on a specific database.

[0105] Reference Figure 4 , Figure 4 This is a flowchart illustrating the fourth embodiment of the domain name risk detection method of this application. Based on the above embodiments, the fourth embodiment of the domain name risk detection method of this application is proposed.

[0106] In the fourth embodiment, the domain name risk detection method further includes: Step S40: In response to the update completion signal of the multi-relationship graph, the inspection agent is triggered to perform a full-graph inspection of the multi-relationship graph. The inspection agent is configured to have only read-only access to the multi-relationship graph and to operate independently of the constrained agent.

[0107] It should be understood that the update completion signal can refer to a notification signal issued by the system after the entire data update process of the multi-relationship graph has been completed. The inspection agent can refer to an agent program that performs periodic monitoring of the complete graph.

[0108] In its implementation, the inspection agent executes data quality gatekeeping, checking data date, number of nodes and edges, field null value rate, relation import volume, duplicate edges, self-loops, isolated nodes, and index validity. If gatekeeping fails, the risk inspection is aborted and a data alarm is generated. A global snapshot is executed, saving daily metrics aggregated by category, relation type, community, and risk status, and comparing them with yesterday's and the baseline of the past seven days. Parallel detection of structural anomalies, relation anomalies, community anomalies, and time trend anomalies is performed, outputting anomaly candidates with a unified format, and prioritizing candidates based on severity, impact scope, strength of evidence, magnitude of change, and historical repetition count. High-priority anomalies are then addressed by... Secondary evidence is collected using domain details, neighbor relationships, community summaries, and historical change tools. Verified anomalies are saved as Findings and Cases, recording affected domains, indicator changes, evidence identifiers, confidence levels, suggested actions, and manual review status. Daily reports are generated based on data quality, graph health, major changes, key communities, key domains, items pending review, and failures. Each number in the report references structured inspection results. Throughout the inspection process, the inspection agent remains read-only and must not directly delete nodes or relationships or automatically change the final disposal status. When modifications are required, an action pending approval must be generated, manually confirmed, and executed through an independent write interface.

[0109] This embodiment automatically starts an independently running read-only inspection agent to perform systematic monitoring of the entire graph after each update of the multi-relationship graph. This expands domain name risk governance from passive interactive Q&A to proactive continuous monitoring, timely detecting data quality problems, relationship anomalies, community changes, and risk group expansion in the graph, thereby improving the comprehensiveness and timeliness of domain name risk governance.

[0110] Furthermore, to set data quality gates at the beginning of the full-map inspection, promptly alert and stop the inspection of map data with quality defects, thereby avoiding unreliable risky inspection conclusions based on incomplete or abnormal map data, ensuring the integrity and validity of the data basis on which the inspection report is based, and improving the reliability and credibility of the full-map inspection results, the triggering inspection agent to perform a full-map inspection of the multi-relationship graph includes: triggering the inspection agent to perform data quality verification on the multi-relationship graph; if the data quality verification result is unsuccessful, a data alarm is generated and the full-map inspection is stopped; if the data quality verification result is successful, an inspection report is generated based on the multi-relationship graph that has passed the data quality verification.

[0111] It should be understood that the inspection report can refer to the daily report generated after performing a full-map inspection based on the multi-relationship graph that has passed the data quality verification when the data quality verification result is passed.

[0112] Furthermore, to expand passive interactive Q&A into proactive continuous monitoring, promptly detect structural anomalies, relationship mutations, community changes, and risk group expansions in the graph, and form traceable and verifiable inspection cases and daily reports, thereby improving the comprehensiveness and foresight of domain name risk governance, if the data quality verification result is passed, an inspection report is generated based on the multi-relationship graph that has passed the data quality verification. This includes: if the data quality verification result is passed, generating a global indicator snapshot for the multi-relationship graph that has passed the data quality verification; comparing the global indicator snapshot with the historical baseline and determining anomaly candidates based on the comparison results; conducting secondary evidence collection on the anomaly candidates; converting the anomaly candidates into inspection cases based on the secondary evidence collection results; and generating an inspection report based on the inspection cases.

[0113] Understandably, a global indicator snapshot refers to a one-time saving of global statistical indicators of a multi-relationship graph that has passed data quality verification on a specific data date. This includes indicators aggregated by dimensions such as business classification, relationship type, community, and risk status for that day. A historical baseline refers to a set of reference indicators calculated based on historical data from the multi-relationship graph. This can include statistical values ​​of yesterday's indicators and those from the past seven days (such as mean, variance, quantiles, etc.), used to measure whether the current global indicator snapshot deviates from the normal fluctuation range.

[0114] Anomaly candidates refer to potential abnormal objects or phenomena identified based on comparison results, whose indicator changes exceed the normal fluctuation range. These include structural anomalies, relational anomalies, community anomalies, and time trend anomalies. Secondary evidence collection refers to the in-depth investigation conducted by the inspection agent on high-priority anomaly candidates, using tools such as domain name details, relational neighbors, community summaries, and historical changes. This investigation is used to verify the authenticity of the anomaly candidates, supplement evidence details, and eliminate false alarms caused by data updates or normal business fluctuations.

[0115] For ease of understanding, the following example is provided, but it does not limit this application. As an example, the inspection agent is triggered by a periodic scheduler, preferably running after the daily graph update is completed and a consistent snapshot is generated. The inspection agent shares the read-only graph tool with the interactive agent, but has independent `patrol_run_id`, `data_date`, budget, state repository, and report output. The inspection agent is read-only by default and must not directly delete nodes or relationships or automatically change the final disposal status. When it needs to modify the graph or batch adjust partitions, it must generate an action pending approval, which must be manually confirmed and executed through a separate write interface, with audit logs recorded. Specific steps include: Step 1: Data Quality Governance: Check data date, number of nodes and edges, field null value rate, relation import volume, duplicate edges, self-loops, orphaned nodes, and index validity. If the gate fails, the risk inspection is suspended and a data alert is generated.

[0116] Step 2: Global Snapshot: Save the daily metrics aggregated by category, relationship type, community, and risk status, and compare them with yesterday's and the baseline of the past seven days.

[0117] Step 3: Anomaly Detection: Perform structural anomaly, relational anomaly, community anomaly, and time trend anomaly detection in parallel, and output anomaly candidates with a uniform format.

[0118] Step 4: Anomaly ranking: Candidate priorities are formed based on severity, scope of impact, strength of evidence, magnitude of change, and number of historical recurrences.

[0119] Step 5: Coordinated Evidence Collection: The inspection agent conducts secondary evidence collection for high-priority abnormal calls using tools such as domain name details, neighbor relationships, community summaries, and historical changes.

[0120] Step 6: Case Processing: Save the verified anomalies as Findings and Cases, recording the affected domains, indicator changes, evidence identifiers, confidence levels, suggested actions, and manual review status.

[0121] Step 7: Report Generation: Generate a daily report based on data quality, graph health, major changes, key communities, key domains, items pending review, and failures. Each figure in the report references structured inspection results.

[0122] In practical implementation, for example, after the daily update, the inspection system finds that the number of domain names in a certain community has increased compared to the previous day, and the proportion of risk candidates has risen significantly from the historical baseline. The coordinating agent first queries the list of newly added domain names and the distribution of relationship types. If the new connections are mainly formed by shared IPs, the system identifies them as possible shared infrastructure expansion; if the new domain name also has a shared filing entity, icon, and root domain, then a high-priority community risk expansion case is generated.

[0123] The case records include the metrics before and after the change, the affected domains, relationship evidence, query identifiers, and data dates, and are listed as items awaiting manual review in the daily report. If it is manually confirmed that the anomaly was caused by normal business migration, the feedback record is used to adjust subsequent thresholds, but historical evidence is not retroactively modified.

[0124] For ease of understanding, please refer to Figure 5 This explanation is provided, but does not limit the scope of this application. Figure 5This is a diagram illustrating the overall structure of a domain risk governance system according to an embodiment of the domain risk detection method of this application. This example divides the system into a data access layer, a multi-relationship graph and evidence layer, a constrained agent layer, an active inspection layer, and an output and governance layer. Interactive agents perform evidence collection and partitioning decisions for single-issue problems, while inspection agents perform periodic monitoring of the complete graph. Both types of agents share graph tools and evidence protocols but have independent operating identifiers, states, budgets, and output storage.

[0125] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the domain name risk detection method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0126] This application also provides a domain name risk detection device; please refer to... Figure 6 The domain name risk detection device includes: Domain name determination module 10 is used to determine the domain name to be detected based on the input question in response to the input question; Domain name detection module 20 is used to query the associated domain name corresponding to the domain name to be detected in the multi-relationship graph and obtain the query result. The multi-relationship graph includes domain name nodes and the relationship between each domain name node. The relationship includes multiple relationship levels, wherein at least one relationship level is subject to the propagation constraint that a high-risk disposal conclusion cannot be formed independently. The result generation module 30 is used to generate a risk detection result for the domain name to be detected based on the query result.

[0127] The domain name risk detection device provided in this application, employing the domain name risk detection method described in the above embodiments, can solve the technical problem that related domain name risk detection methods often treat relationships with different strengths of evidence equally during risk aggregation, leading to the erroneous propagation of risk labels along weak relationships and causing misjudgments of legitimate websites. Compared with the prior art, the beneficial effects of the domain name risk detection device provided in this application are the same as those of the domain name risk detection method provided in the above embodiments, and other technical features in the domain name risk detection device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0128] This application provides a domain name risk detection device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the domain name risk detection method in the above embodiment 1.

[0129] The following is for reference. Figure 7The diagram illustrates a structural schematic suitable for implementing the domain name risk detection device in the embodiments of this application. The domain name risk detection device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 7 The domain name risk detection device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0130] like Figure 7 As shown, the domain name risk detection device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in ROM (Read Only Memory) 1002 or a program loaded from storage device 1003 into RAM (Random Access Memory) 1004. RAM 1004 also stores various programs and data required for the operation of the domain name risk detection device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touch screens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, LCDs (Liquid Crystal Displays), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the domain name risk detection device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows domain name risk detection devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0131] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0132] The domain name risk detection device provided in this application, employing the domain name risk detection method described in the above embodiments, can solve the technical problem that related domain name risk detection methods often treat relationships with different strengths of evidence equally when performing risk aggregation, leading to the erroneous propagation of risk labels along weak relationships and causing misjudgments of legitimate websites. Compared with the prior art, the beneficial effects of the domain name risk detection device provided in this application are the same as those of the domain name risk detection method provided in the above embodiments, and other technical features of this domain name risk detection device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0133] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0134] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0135] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the domain name risk detection method in the above embodiments.

[0136] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the aforementioned domain name risk detection method. This addresses the technical problem that related domain name risk detection methods often treat relationships with different strengths of evidence equally during risk aggregation, leading to the potential erroneous propagation of risk labels along weak relationships and causing misjudgments of legitimate websites. Compared to existing technologies, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the domain name risk detection method provided in the above embodiments, and will not be elaborated upon here.

[0137] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the domain name risk detection method described above.

[0138] The computer program product provided in this application can solve the technical problem that related domain name risk detection methods often treat relationships with different strengths of evidence equally when aggregating risks, which may lead to the erroneous spread of risk labels along weak relationships and cause misjudgments of legitimate websites. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the domain name risk detection method provided in the above embodiments, and will not be repeated here.

[0139] The above description is only a part of the embodiments of this application and does not limit the scope of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included within the protection scope of this application.

[0140] It should be noted that the data collection, tag management, rule setting, and push decision-making processes involved in this application are designed to work with other technical features to solve technical problems. They do not involve or support any illegal activities. Any data processing that may violate laws and regulations (such as unauthorized collection of privacy data, generation of discriminatory tags, setting unfair rules, or pushing illegal information) is not within the scope of protection of this application's technical solution. Of course, the user data in this application will be encrypted, anonymized, or de-identified before storage to ensure user data security.

[0141] This application discloses A1, a domain name risk detection method, the domain name risk detection method comprising: In response to the input question, the domain name to be detected is determined based on the input question; The associated domains corresponding to the domain to be detected are queried in the multi-relationship graph to obtain the query results. The multi-relationship graph includes domain nodes and the relationships between each domain node. The relationships include multiple relationship levels, wherein at least one relationship level is subject to the propagation constraint that a high-risk disposal conclusion cannot be formed independently. The risk detection result of the domain name to be detected is generated based on the query result.

[0142] A2. The domain risk detection method as described in A1, wherein querying the associated domains corresponding to the domain to be detected in the multi-relationship graph to obtain the query results includes: Invoke a constrained agent, which is configured to have read-only access to the multi-relationship graph but not write access. The constrained agent queries the associated domains corresponding to the domain to be detected in the multi-relationship graph to obtain the query results.

[0143] A3. The domain name risk detection method as described in A2, wherein the step of querying the associated domain names corresponding to the domain name to be detected in the multi-relationship graph by the constrained agent to obtain the query results includes: The constrained agent queries the associated domains corresponding to the domain to be detected in the multi-relationship graph to obtain a set of candidate domains. For each candidate domain name in the candidate domain name set, generate a corresponding structured conclusion; The structured conclusions are subjected to partition consistency verification, and the structured conclusions that pass the partition consistency verification are determined as query results.

[0144] A4. The domain name risk detection method as described in A3, wherein generating a corresponding structured conclusion for each candidate domain name in the candidate domain name set includes: For each candidate domain name in the candidate domain name set, obtain the corresponding set of evidence objects; The disposal partition of the candidate domain name is determined based on the relationship level and evidence type of each piece of evidence in the evidence object set; Structured conclusions are generated based on the disposal partitions, which include a trusted zone, a gray zone, and a deletion candidate zone.

[0145] A5. The domain name risk detection method as described in A3, wherein the partition consistency verification includes at least one of completeness verification, mutual exclusion verification, and constraint verification, and the partition consistency verification of the structured conclusion includes at least one of the following: Verify that each candidate domain in the candidate domain set has a corresponding structured conclusion; Verify that the processing partitions of each structured conclusion are pairwise disjoint, and that the union of all processing partitions covers the candidate domain name set; The verification showed that weak relation level evidence in the structured conclusions was not used alone to identify candidate domains as deletion candidate areas.

[0146] A6. The domain name risk detection method as described in A3, wherein the step of obtaining a candidate domain name set by querying the associated domain names corresponding to the domain name to be detected in a multi-relationship graph by the constrained intelligent agent includes: The constrained agent queries the associated domains corresponding to the domain to be detected in the multi-relationship graph to obtain the returned evidence objects. The returned evidence object is compared with the expected evidence to generate evidence gap information; The query continues based on the evidence gap information, and a set of candidate domain names is generated based on the results of the continued query.

[0147] A7. The domain name risk detection method as described in A3, wherein determining the structured conclusion obtained through the partition consistency check as the query result includes: Extract verifiable numerical claims from the structured conclusions of the partition consistency check, wherein the verifiable numerical claims include at least one of index size, ranking, number of nodes, and community size; The verifiable numerical claims are matched and verified with the original numerical values ​​in the corresponding evidence objects according to the domain name identifier and field type; If the matching verification passes, the structured conclusion that passes the partition consistency verification will be determined as the query result.

[0148] A8. The domain name risk detection method as described in A3, before obtaining the candidate domain name set by querying the associated domain names corresponding to the domain name to be detected in the multi-relationship graph through the constrained intelligent agent, further includes: Based on the input question and the preset tool catalog, the constrained intelligent agent generates a tool invocation plan; Accordingly, the step of obtaining a candidate domain name set by querying the associated domain names corresponding to the domain name to be detected in the multi-relationship graph through the constrained intelligent agent includes: Based on the tool invocation plan, the constrained agent queries the associated domains corresponding to the domain to be detected in the multi-relationship graph to obtain a set of candidate domains.

[0149] A9. The domain name risk detection method as described in any one of A1 to A8, wherein the domain name risk detection method further includes: In response to the update completion signal of the multi-relationship graph, an inspection agent is triggered to perform a full-graph inspection of the multi-relationship graph. The inspection agent is configured to have only read-only access to the multi-relationship graph and operates independently of the constrained agent.

[0150] A10. The domain name risk detection method as described in A9, wherein the triggering inspection agent performs a full-graph inspection of the multi-relationship graph, including: The inspection agent is triggered to perform data quality verification on the multi-relationship graph. If the data quality verification result is unsuccessful, a data alarm will be generated and the full map inspection will be stopped. If the data quality verification result is passed, an inspection report is generated based on the multi-relationship graph that passed the data quality verification.

[0151] A11. The domain name risk detection method as described in A10, wherein if the data quality verification result is passed, an inspection report is generated based on the multi-relationship graph that passed the data quality verification, including: If the data quality verification result is passed, a global indicator snapshot is generated for the multi-relationship graph that has passed the data quality verification. The global metric snapshot is compared with the historical baseline, and anomaly candidates are determined based on the comparison results; The abnormal candidate is subjected to secondary evidence collection. Based on the results of the secondary evidence collection, the abnormal candidate is converted into an inspection case, and an inspection report is generated based on the inspection case.

[0152] This application also discloses B12, a domain name risk detection device, the domain name risk detection device comprising: The domain name determination module is used to determine the domain name to be detected based on the input question in response to the input question. The domain name detection module is used to query the associated domain names corresponding to the domain name to be detected in the multi-relationship graph and obtain the query results. The multi-relationship graph includes domain name nodes and the relationships between each domain name node. The relationships include multiple relationship levels, wherein at least one relationship level is subject to the propagation constraint that it cannot form a high-risk disposal conclusion on its own. The result generation module is used to generate risk detection results for the domain name to be detected based on the query results.

[0153] B13. The domain name risk detection device as described in B12, wherein the domain name detection module is further configured to invoke a constrained intelligent agent, the constrained intelligent agent being configured to have read-only access permissions to the multi-relationship graph but not write permissions; and to obtain query results by querying the associated domain names corresponding to the domain name to be detected in the multi-relationship graph through the constrained intelligent agent.

[0154] B14. The domain name risk detection device as described in B13, wherein the domain name detection module is further configured to query the associated domain names corresponding to the domain name to be detected in the multi-relationship graph through the constrained intelligent agent to obtain a set of candidate domain names; generate a corresponding structured conclusion for each candidate domain name in the set of candidate domain names; perform partition consistency verification on the structured conclusions, and determine the structured conclusions that pass the partition consistency verification as the query result.

[0155] B15. The domain name risk detection device as described in B14, wherein the domain name detection module is further configured to obtain a corresponding set of evidence objects for each candidate domain name in the candidate domain name set; determine the disposal partition of the candidate domain name according to the relationship level and evidence type of each piece of evidence in the set of evidence objects; and generate a structured conclusion based on the disposal partition, wherein the disposal partition includes a trusted zone, a gray zone, and a candidate deletion zone.

[0156] B16. The domain name risk detection device as described in B14, wherein the partition consistency verification includes at least one of completeness verification, mutual exclusion verification, and constraint verification; the domain name detection module is further configured to verify that each candidate domain name in the candidate domain name set has a corresponding structured conclusion; verify that the processing partitions of each structured conclusion are pairwise disjoint, and that the union of all processing partitions covers the candidate domain name set; and verify that the weak relation level evidence in the structured conclusion is not used alone to determine the candidate domain name as a deletion candidate area.

[0157] B17. The domain name risk detection device as described in B14, wherein the domain name detection module is further configured to query the associated domain name corresponding to the domain name to be detected in the multi-relationship graph through the constrained intelligent agent to obtain the returned evidence object; compare the returned evidence object with the expected evidence to generate evidence gap information; continue to execute the query based on the evidence gap information, and generate a candidate domain name set based on the continued query results.

[0158] This application also discloses C18, a domain name risk detection device, the domain name risk detection device comprising: a memory, a processor, and a domain name risk detection program stored on the memory and executable on the processor, wherein the domain name risk detection program, when executed by the processor, implements the domain name risk detection method as described above.

[0159] This application also discloses D19, a storage medium storing a domain name risk detection program, which, when executed by a processor, implements the domain name risk detection method as described above.

[0160] This application also discloses E20, a computer program product including a domain name risk detection program, which, when executed by a processor, implements the domain name risk detection method as described above.

Claims

1. A domain name risk detection method, characterized in that, The domain name risk detection method includes: In response to the input question, the domain name to be detected is determined based on the input question; The associated domains corresponding to the domain to be detected are queried in the multi-relationship graph to obtain the query results. The multi-relationship graph includes domain nodes and the relationships between each domain node. The relationships include multiple relationship levels, wherein at least one relationship level is subject to the propagation constraint that a high-risk disposal conclusion cannot be formed independently. The risk detection result of the domain name to be detected is generated based on the query result.

2. The domain name risk detection method as described in claim 1, characterized in that, The step of querying the associated domains corresponding to the domain to be detected in the multi-relationship graph to obtain the query results includes: Invoke a constrained agent, which is configured to have read-only access to the multi-relationship graph but not write access. The constrained agent queries the associated domains corresponding to the domain to be detected in the multi-relationship graph to obtain the query results.

3. The domain name risk detection method as described in claim 2, characterized in that, The step of obtaining query results by querying the associated domains corresponding to the domain name to be detected in the multi-relationship graph through the constrained intelligent agent includes: The constrained agent queries the associated domains corresponding to the domain to be detected in the multi-relationship graph to obtain a set of candidate domains. For each candidate domain name in the candidate domain name set, generate a corresponding structured conclusion; The structured conclusions are subjected to partition consistency verification, and the structured conclusions that pass the partition consistency verification are determined as query results.

4. The domain name risk detection method as described in claim 3, characterized in that, The step of generating a corresponding structured conclusion for each candidate domain in the candidate domain set includes: For each candidate domain name in the candidate domain name set, obtain the corresponding set of evidence objects; The disposal partition of the candidate domain name is determined based on the relationship level and evidence type of each piece of evidence in the evidence object set; Structured conclusions are generated based on the disposal partitions, which include a trusted zone, a gray zone, and a deletion candidate zone.

5. The domain name risk detection method as described in claim 3, characterized in that, The partition consistency check includes at least one of completeness check, mutual exclusion check, and constraint check, and the partition consistency check of the structured conclusion includes at least one of the following: Verify that each candidate domain in the candidate domain set has a corresponding structured conclusion; Verify that the processing partitions of each structured conclusion are pairwise disjoint, and that the union of all processing partitions covers the candidate domain name set; The verification showed that weak relation level evidence in the structured conclusions was not used alone to identify candidate domains as deletion candidate areas.

6. The domain name risk detection method as described in claim 3, characterized in that, The step of obtaining a candidate domain name set by querying the associated domain names corresponding to the domain name to be detected in the multi-relationship graph through the constrained intelligent agent includes: The constrained agent queries the associated domains corresponding to the domain to be detected in the multi-relationship graph to obtain the returned evidence objects. The returned evidence object is compared with the expected evidence to generate evidence gap information; The query continues based on the evidence gap information, and a set of candidate domain names is generated based on the results of the continued query.

7. A domain name risk detection device, characterized in that, The domain name risk detection device includes: The domain name determination module is used to determine the domain name to be detected based on the input question in response to the input question. The domain name detection module is used to query the associated domain names corresponding to the domain name to be detected in the multi-relationship graph and obtain the query results. The multi-relationship graph includes domain name nodes and the relationships between each domain name node. The relationships include multiple relationship levels, wherein at least one relationship level is subject to the propagation constraint that it cannot form a high-risk disposal conclusion on its own. The result generation module is used to generate risk detection results for the domain name to be detected based on the query results.

8. A domain name risk detection device, characterized in that, The domain name risk detection device includes: a memory, a processor, and a domain name risk detection program stored in the memory and executable on the processor. When the domain name risk detection program is executed by the processor, it implements the domain name risk detection method as described in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium stores a domain name risk detection program, which, when executed by a processor, implements the domain name risk detection method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a domain name risk detection program, which, when executed by a processor, implements the domain name risk detection method as described in any one of claims 1 to 6.

Images