Domain name system vulnerability processing method and device and related equipment

Abstract

This application discloses a method, apparatus, and related equipment for handling vulnerabilities in the Domain Name System (DNS). The method involves: acquiring a set of vulnerabilities in the DNS; combining vulnerabilities in the set to obtain at least one combined vulnerability path, which represents the order in which multiple vulnerabilities in the set are attacked; performing attack tests on at least one combined vulnerability path to obtain test results for each combined vulnerability path; determining target combined vulnerability paths whose test results satisfy the attack objectives based on the test results for each combined vulnerability path; and generating a defense strategy. Thus, by identifying target combined vulnerability paths with practical attack feasibility from combined vulnerability paths corresponding to different vulnerability compositions or different attack sequences, and generating corresponding defense strategies for these target combined vulnerability paths, the method improves the DNS's ability to identify risks from combined vulnerability path attacks and enhances the targeting of the defense strategy.

Description

Technical Field

[0001] This application relates to the field of computer network security technology, and in particular to a method, apparatus and related equipment for handling domain name system vulnerabilities. Background Technology

[0002] With the development of internet services, users typically access websites, application servers, or other network services through domain names. The Domain Name System (DNS) is used to resolve user-input domain names into corresponding network addresses and is a fundamental support system for internet access. The DNS typically involves recursive resolvers, authoritative servers, resolution software, DNS resource records, and multi-level resolution nodes. Its security affects the correctness of domain name resolution results and the accessibility of network services.

[0003] Existing domain name system security testing methods typically include vulnerability scanning, security configuration verification, protocol specification validation, DNS resolution traffic monitoring, and manual security testing. These methods can monitor the operational status of domain name resolution services and, to some extent, identify security issues within the domain name system.

[0004] However, the Domain Name System (DNS) operates in a complex environment, and the version of the DNS resolution software, its configuration, the protocol interaction status, and the status of the DNS nodes can all affect DNS resolution security. Existing security detection methods typically have limited efficiency and coverage in large-scale DNS scenarios, making it difficult to detect potential security risks in the DNS system in a timely manner. Summary of the Invention

[0005] This invention provides a method, apparatus, and related equipment for handling vulnerabilities in the Domain Name System (DNS) to improve the accuracy of identifying combined vulnerability paths in the DNS and to enhance the targeting of defense strategies against combined vulnerability attacks.

[0006] Firstly, embodiments of this application provide a method for handling vulnerabilities in the Domain Name System (DNS). This method is applied to the DNS. Specifically, when executing this vulnerability handling method, a vulnerability set of the DNS is obtained, which may include multiple vulnerabilities already identified in the DNS. The vulnerabilities in the vulnerability set are combined to obtain at least one combined vulnerability path. The combined vulnerability path represents the order in which multiple vulnerabilities in the vulnerability set are attacked sequentially; different combined vulnerability paths may include different vulnerabilities, or the attack order indicated by different combined vulnerability paths may differ. After obtaining at least one combined vulnerability path, attack tests are performed on the at least one combined vulnerability path to obtain test results corresponding to each combined vulnerability path. Then, based on the test results corresponding to each combined vulnerability path, a target combined vulnerability path is determined. The target combined vulnerability path is the combined vulnerability path whose test results satisfy the attack target among the at least one combined vulnerability path. Subsequently, a defense strategy is generated for the target combined vulnerability path, which is a strategy for security handling of the vulnerabilities in the target combined vulnerability path.

[0007] This application combines multiple vulnerabilities from a vulnerability set to form combined vulnerability paths that characterize the sequential attack order of these vulnerabilities. Therefore, it can identify the risks of attacking these combined vulnerability paths under different vulnerability combinations or attack orders, thereby improving the Domain Name System's ability to identify such attacks. Furthermore, after obtaining the combined vulnerability paths, attack tests are conducted on each combined vulnerability path, and the target combined vulnerability path that meets the attack objectives is determined based on the test results. Thus, paths with practical attack feasibility can be selected from multiple combined vulnerability paths, reducing misjudgments caused by relying solely on vulnerability combination relationships and improving the accuracy of target combined vulnerability path determination. In addition, defense strategies are generated for the target combined vulnerability paths, ensuring that these strategies match the target combined vulnerability paths that have passed attack tests, thereby improving the targeting of the Domain Name System's defense strategies for combined vulnerability paths.

[0008] In one possible implementation, when combining vulnerabilities in a vulnerability set to obtain at least one combined vulnerability path, specifically, each vulnerability in the vulnerability set can be attacked and tested to obtain a test result for each vulnerability. Then, based on the test results of each vulnerability, the vulnerabilities in the vulnerability set can be combined to obtain at least one combined vulnerability path. This combined vulnerability path is a path obtained by combining vulnerabilities in the vulnerability set whose test results have passed attack verification. Thus, before generating combined vulnerability paths, each vulnerability in the vulnerability set can be attacked and verified, and vulnerabilities that pass the attack verification can be selected. Combined vulnerability paths are then generated based on these verified vulnerabilities. This reduces invalid combined paths generated by vulnerabilities that have not passed attack verification, improving the accuracy and effectiveness of combined vulnerability path generation.

[0009] In one possible implementation, when generating a defense strategy for a target combined vulnerability path, the specific approach involves determining the path risk characteristics of the target combined vulnerability path. These path risk characteristics include attack step scripts or dependency graphs. The attack step scripts instruct the simulated attack process of each vulnerability in the target combined vulnerability path, while the dependency graph represents the dependencies between vulnerabilities in the target combined vulnerability path. Then, a defense strategy for the target combined vulnerability path is generated based on these path risk characteristics. In this way, the path risk characteristics of the target combined vulnerability path can be used as the basis for generating the defense strategy. This allows the defense strategy to target not only individual vulnerabilities in the target combined vulnerability path but also the attack steps or vulnerability dependencies within the target combined vulnerability path, thereby improving the specificity, interpretability, and effectiveness of the defense strategy against combined vulnerability attacks.

[0010] In one possible implementation, when obtaining source code vulnerabilities from the vulnerability set of the Domain Name System (DNS), a first intelligent agent can be used to obtain the source code of the DNS resolution software and construct a code attribute graph from the source code. This code attribute graph includes at least one of an abstract syntax tree, a control flow graph, and a data flow graph. Then, based on the code attribute graph, vulnerability analysis is performed on the source code to obtain the source code vulnerabilities from the DNS vulnerability set. In this way, the source code of the resolution software can be converted into a code attribute graph that can represent the code structure, execution flow, or data dependencies, and the first intelligent agent can perform source code vulnerability analysis based on the code attribute graph. Compared to methods that directly identify vulnerabilities based on the source code text, this implementation allows the first intelligent agent to construct a code attribute graph from the source code to identify source code vulnerabilities, thereby improving the efficiency and accuracy of source code vulnerability identification.

[0011] In one possible implementation, after generating a defense strategy for the target combined vulnerability path, training data can be added to the training dataset based on the target combined vulnerability path, the corresponding test results, and the defense strategy. This training dataset is a collection of training data. Then, the first agent is fine-tuned based on the added training dataset. In this way, the verified target combined vulnerability path, the corresponding attack test results, and the defense strategy generated for that path can be fed back as new training data to the first agent's fine-tuning process, enabling the first agent to optimize based on the verified vulnerability handling results. This allows the first agent's source code vulnerability discovery process to have continuous optimization capabilities, improving the accuracy and adaptability of subsequent source code vulnerability identification.

[0012] In one possible implementation, when obtaining topological vulnerabilities from the vulnerability set of the Domain Name System (DNS), a second intelligent agent can be used to acquire DNS resolution topology data and behavioral data. This topology data is the resolution data obtained through DNS resolution. Based on the topology data, the DNS resolution topology structure is determined, including multiple resolution nodes and the dependencies connecting these nodes. Then, based on the behavioral data and the DNS resolution topology structure, the topological vulnerabilities in the vulnerability set are obtained. In this way, the resolution nodes in the DNS system and the dependencies between them can be determined through the topology data, and abnormal situations in the DNS resolution process can be analyzed in conjunction with the behavioral data. Therefore, the second intelligent agent can not only identify vulnerabilities based on individual resolution nodes but also identify topological vulnerabilities based on the dependencies between resolution nodes and the resolution behavior, thereby improving the accuracy and effectiveness of topological vulnerability identification.

[0013] In one possible implementation, after generating a defense strategy for the target combined vulnerability path, training data can be added to the training dataset based on the target combined vulnerability path, the corresponding test results, and the defense strategy. This training dataset is a collection of training data. Then, the second agent is retrained based on the added training dataset. In this way, the verified target combined vulnerability path, the corresponding attack test results, and the defense strategy generated for that path can be fed back as new training data to the second agent's training process, enabling the agent to update based on the verified vulnerability handling results. Therefore, the second agent's topology vulnerability identification capability can be continuously optimized with the accumulation of vulnerability handling results, thereby improving the accuracy and adaptability of subsequent topology vulnerability identification.

[0014] Secondly, embodiments of this application provide a Domain Name System (DNS) vulnerability processing apparatus. This apparatus, applied to the DNS, includes an acquisition module, a combination module, a testing module, a determination module, and a generation module. The acquisition module acquires a vulnerability set of the DNS. The combination module combines vulnerabilities from the vulnerability set to obtain at least one combined vulnerability path. This combined vulnerability path represents the order in which multiple vulnerabilities in the vulnerability set are attacked sequentially. Different combined vulnerability paths may include different vulnerabilities, or the attack order indicated by different combined vulnerability paths may differ. The testing module performs attack tests on the at least one combined vulnerability path to obtain test results corresponding to each combined vulnerability path. The determination module determines a target combined vulnerability path based on the test results corresponding to each combined vulnerability path. This target combined vulnerability path is the combined vulnerability path whose test results satisfy the attack target among the at least one combined vulnerability path. The generation module generates a defense strategy for the target combined vulnerability path, which is a strategy for security processing of the vulnerabilities in the target combined vulnerability path.

[0015] In one possible implementation, the acquisition module is configured to: perform attack tests on each vulnerability in the vulnerability set to obtain test results for each vulnerability; and combine the vulnerabilities in the vulnerability set according to the test results for each vulnerability to obtain at least one combined vulnerability path, wherein the combined vulnerability path is a path obtained by combining vulnerabilities in the vulnerability set whose test results have been verified by attack.

[0016] In one possible implementation, the generation module is configured to: determine the path risk characteristics of the target combined vulnerability path based on the target combined vulnerability path, wherein the path risk characteristics include an attack step script or a dependency graph, wherein the attack step script is used to instruct the process of simulating attacks on each vulnerability in the target combined vulnerability path according to the path, and the dependency graph is used to characterize the dependency relationships between each vulnerability in the target combined vulnerability path; and generate a defense strategy for the target combined vulnerability path based on the path risk characteristics.

[0017] In one possible implementation, the acquisition module is configured to: acquire the source code of the DNS resolution software using a first intelligent agent; construct a code attribute graph from the source code using the first intelligent agent, the code attribute graph including at least one of an abstract syntax tree, a control flow graph, and a data flow graph; and perform vulnerability analysis on the source code based on the code attribute graph using the first intelligent agent to obtain source code vulnerabilities in the vulnerability set of the DNS.

[0018] In one possible implementation, the Domain Name System vulnerability processing device further includes: a training module, configured to add training data to a training dataset based on the target combined vulnerability path, the test results corresponding to the target combined vulnerability path, and the defense strategy, wherein the training dataset is a collection of training data; and to fine-tune the first agent based on the added training dataset.

[0019] In one possible implementation, the acquisition module is configured to: acquire the DNS resolution topology data and behavioral data of the domain name system using a second intelligent agent, wherein the DNS resolution topology data is the resolution data obtained through domain name resolution; determine the domain name resolution topology structure based on the DNS resolution topology data using the second intelligent agent, wherein the domain name resolution topology structure includes multiple resolution nodes and dependencies connecting the multiple resolution nodes; and obtain topological vulnerabilities in the vulnerability set using the second intelligent agent based on the behavioral data and the domain name resolution topology structure.

[0020] In one possible implementation, the training module is further configured to: add training data to the training dataset based on the target combined vulnerability path, the test results corresponding to the target combined vulnerability path, and the defense strategy, wherein the training dataset is a collection of training data; and retrain the second agent based on the added training dataset.

[0021] Since the domain name system vulnerability processing device provided in the second aspect corresponds to the domain name system vulnerability processing method provided in the first aspect, the technical effects of the domain name system vulnerability processing device provided in the second aspect can be referred to the technical effects of the domain name system vulnerability processing method provided in the first aspect, and will not be repeated here.

[0022] Thirdly, embodiments of this application provide a computer device cluster, which includes at least one computer device. Each computer device includes a processor and a memory. The memory stores computer instructions. When the computer device cluster is running, the processor executes the instructions stored in the memory to cause the computer device cluster to perform the Domain Name System vulnerability processing method described in the first aspect and any possible implementation thereof. It should be noted that the memory may be integrated into the processor or may be independent of the processor. The computer device may also include a bus. The processor is connected to the memory via the bus. The memory may include readable storage and random access memory.

[0023] Fourthly, embodiments of this application provide a computer-readable storage medium storing instructions that, when executed on a computing device, cause the computing device to perform the Domain Name System vulnerability handling method described in the first aspect and any possible implementation thereof.

[0024] Fifthly, embodiments of this application provide a computer program product, which includes a computer program or instructions. When the computer program product is run on a computing device, it causes the computing device to execute the Domain Name System vulnerability handling method described in the first aspect and any possible implementation thereof.

[0025] Furthermore, the technical effects of any of the implementation methods in the second to fifth aspects can be found in the technical effects of different implementation methods in the first aspect, and will not be repeated here.

[0026] Based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods. Attached Figure Description

[0027] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments are briefly introduced below. The accompanying drawings described below are only some embodiments recorded in this application, and those skilled in the art can obtain other drawings based on these drawings.

[0028] Figure 1 This is a schematic diagram of a hardware deployment environment in an embodiment of this application; Figure 2 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of this application; Figure 3 This is a flowchart illustrating a domain name system vulnerability handling method in an embodiment of this application; Figure 4 This is a schematic diagram of a vulnerability set acquisition process in an embodiment of this application; Figure 5 This is a schematic diagram of a closed-loop training and update process in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a domain name system vulnerability processing device in an embodiment of this application. Detailed Implementation

[0029] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. The described embodiments are some, but not all, embodiments of this application. Other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are all within the scope of protection of this application.

[0030] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate; this is merely a method of distinction used in describing objects with the same attributes in the embodiments of this application.

[0031] The first, second, or third intelligent agent in the embodiments of this application can be a functional entity implemented by a computer device. The intelligent agent can be implemented by computer program instructions, model parameters, rule data, and execution logic stored in memory. When the processor executes the corresponding computer program instructions, it can perform functions such as data acquisition, rule matching, model reasoning, task planning, attack testing, vulnerability identification, path generation, or policy generation.

[0032] The Domain Name System (DNS) vulnerability handling system in this embodiment may include a knowledge layer, a skill layer, and a target layer. The knowledge layer may include a knowledge base, which may include data sources, rule bases, expert databases, or risk databases, providing data support for vulnerability acquisition, path combination, attack testing, or defense strategy generation. The skill layer, based on data from the knowledge layer, may utilize a first agent to perform source code vulnerability identification, a second agent to perform topology vulnerability identification, and a third agent to perform attack plan generation, vulnerability exploitability verification, or combined vulnerability path generation. The target layer may be used to drive attack testing of combined vulnerability paths, determination of target combined vulnerability paths, or generation of defense strategies. Target combined vulnerability paths, test results, and defense strategies may also be used to update the knowledge layer and to fine-tune or update the corresponding agents.

[0033] The Domain Name System (DNS) in this application embodiment may include one or more of the following: a recursive resolver, an authoritative server, DNS resolution software, DNS resource records, and resolution configuration. The DNS may also correspond to DNS resolution topology data and resolution behavior data. The DNS may serve one or more domain name spaces or one or more business systems. Vulnerabilities in the DNS may include one or more of the following: source code vulnerabilities, topology vulnerabilities, configuration vulnerabilities, resolution path defects, or unpatched known vulnerabilities; abnormal protocol behavior can be used as a basis for identifying corresponding vulnerabilities.

[0034] See Figure 1 , Figure 1This illustration shows a schematic diagram of a Domain Name System (DNS) vulnerability handling system 100 according to an embodiment of this application. The DNS vulnerability handling system 100 includes at least one computer device, and may include computer device 110, computer device 120, computer device 130, and computer device 140. The computer devices can be used to implement their corresponding functions or services, such as deploying intelligent agent services, deploying test sandboxes, deploying knowledge base services, or deploying task scheduling services, etc., without limitation. Furthermore, all functions or services can be deployed by a single computer device, or multiple computer devices can deploy functions or services separately. Figure 1 The deployment method described herein is merely an example and is not intended to be limiting. At least one computer device can connect to the Domain Name System 160 via the communication network 150. The Domain Name System 160 may include a recursive resolver, an authoritative server, and resolution software deployed in the recursive resolver or authoritative server; the Domain Name System 160 may also correspond to resolution topology data, which is used to characterize the resolution nodes formed during the domain name resolution process and the dependencies between the resolution nodes, and is not limited in this respect.

[0035] In practical applications, Figure 1 The multiple computer devices shown can be deployed in the same data center, the same cloud resource pool, or computing resources in multiple regions. These computer devices can interact with each other via local area networks, leased networks, the Internet, or other communication networks. Figure 2 The computer device 200 shown can be Figure 1 Any computer device in the above can also be other computer devices with the same or similar hardware structure, and there is no limitation in this regard.

[0036] like Figure 2 As shown, the computer device 200 may include a processor 210, a memory 220, and a bus 230. The processor 210 can be connected to the memory 220 via the bus 230. The memory 220 can store computer instructions. The processor 210 can execute the computer instructions to perform the Domain Name System vulnerability handling method provided in this application embodiment.

[0037] It is understood that the structure illustrated in this embodiment does not constitute a specific limitation on the computer device 200. In another embodiment, the computer device 200 may include more or fewer components than illustrated; for example, the computer device 200 may also include communication interfaces, input / output interfaces, etc.

[0038] Processor 210 may include one or more processing units, such as a central processing unit (CPU), graphics processing unit (GPU), neural processing unit (NPU), data processing unit (DPU), digital signal processor (DSP), application-specific integrated circuit (ASIC), programmable logic device (PLD), field-programmable gate array (FPGA), system-on-chip (SoC), or at least other processing units with instruction execution capabilities. Different processing units may be independent devices or integrated into one or more processors; this is not limited.

[0039] The memory 220 may include volatile memory and non-volatile memory, such as random access memory (RAM), read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD), etc., and is not limited thereto.

[0040] The processor 210 and the memory 220 can be connected via a bus 230 or a signal transmission line. This bus can be, for example, a universal asynchronous receiver-transmitter (UART) bus, an inter-integrated circuit (I2C) bus, a serial peripheral interface (SPI) bus, a universal serial bus (USB), or a controller area network (CAN) bus, etc., and is not limited thereto.

[0041] Understandable Figure 2 The architecture of the computer device 200 shown is merely an example architecture provided in this application embodiment. Other possible domain name system vulnerability handling systems may include a greater number of memories or processors, or modules with other functions.

[0042] In practical applications, Domain Name System (DNS) 160 is used to resolve domain names to their corresponding network addresses. DNS 160 may include recursive resolvers, authoritative servers, resolution software, DNS resource records, resolution configurations, and multiple resolution nodes. Because DNS 160 involves various factors such as source code implementation, resolution configuration, protocol interaction states, resolution topology relationships, and resolution behavior data, it may contain security risks such as source code vulnerabilities, topology vulnerabilities, configuration vulnerabilities, abnormal protocol behavior, or unpatched known vulnerabilities.

[0043] Typically, security checks on the Domain Name System 160 can be performed through methods such as vulnerability scanning, security configuration verification, DNS protocol compliance checks, DNS resolution traffic monitoring, or manual security testing. However, these methods usually focus on detecting individual vulnerabilities, configuration items, or resolution behaviors, and are unlikely to discover combined vulnerability paths formed when multiple vulnerabilities are exploited sequentially in a specific attack order.

[0044] Therefore, in this embodiment of the application, a computer device 200 can be used as an example for illustrative purposes. The computer device 200 obtains a set of vulnerabilities in the Domain Name System 160. This set of vulnerabilities may include one or more of the following: source code vulnerabilities, topology vulnerabilities, configuration vulnerabilities, or unpatched known vulnerabilities.

[0045] After obtaining the vulnerability set, the computer device 200 combines the vulnerabilities in the vulnerability set to obtain at least one combined vulnerability path. The combined vulnerability path is used to characterize the order in which multiple vulnerabilities in the vulnerability set are attacked. Different combined vulnerability paths may include different vulnerabilities, or they may include the same vulnerability but with different attack orders.

[0046] After obtaining at least one combined vulnerability path, the computer device 200 performs attack tests on at least one combined vulnerability path and obtains the test results corresponding to each combined vulnerability path. The computer device 200 executes the test tasks sequentially according to the vulnerability attack order indicated by the combined vulnerability path, and records the input status, output status, response results, and exception information of each test step.

[0047] Subsequently, computer device 200 determines the target combined vulnerability path based on the test results corresponding to each combined vulnerability path. The target combined vulnerability path is a combined vulnerability path in which at least one test result satisfies the attack target. The attack target may include one or more of the following: abnormal modification of parsing results, decreased availability of parsing services, cascading impact on critical parsing nodes, abnormal cache state, generation of unexpected responses, or an abnormal response code ratio reaching the target condition.

[0048] After determining the target combination of vulnerability paths, the computer device 200 generates a defense strategy targeting these paths. Specifically, the computer device 200 determines path risk characteristics based on the target combination of vulnerability paths and generates a defense strategy accordingly. Path risk characteristics may include attack step scripts or dependency graphs. The computer device 200 generates abnormal packet detection rules, log parsing monitoring rules, or risk retesting tasks based on the attack step scripts. It may also generate configuration hardening suggestions, patch repair suggestions, parsing path adjustment strategies, or critical node protection strategies based on the dependency graph.

[0049] Thus, the computer device 200 sequentially completes the acquisition of vulnerability sets, generation of combined vulnerability paths, attack testing of combined vulnerability paths, determination of target combined vulnerability paths, and generation of defense strategies. Compared to the method of independently detecting only a single vulnerability, this embodiment of the application can identify combined vulnerability paths formed by combining multiple vulnerabilities in a specific attack order, and generate defense strategies for target combined vulnerability paths that have been verified through attack testing, thereby improving the domain name system 160's ability to identify risks from combined vulnerability path attacks and the targeting of defense strategies.

[0050] To make the above-mentioned objectives, features, and advantages of this application more apparent and understandable, various non-limiting embodiments of the present application will be described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0051] See Figure 3 , Figure 3 A flowchart illustrating a domain name system vulnerability handling method according to an embodiment of this application is shown. This method can be... Figure 2 The method can be executed by computer device 200, or by other computer devices with the same or similar hardware structure. The following description uses computer device 200 executing the method as an example. The method may include steps S301 to S305.

[0052] S301: A set of vulnerabilities in computer device 200 that allow access to Domain Name System 160.

[0053] A vulnerability set can include one or more vulnerabilities. Each vulnerability can include data such as vulnerability identifier, vulnerability type, vulnerability source, affected objects, triggering conditions, scope of impact, exploitation prerequisites, remediation status, associated rules, associated expert knowledge, associated historical vulnerabilities, or trust rating. The source of the vulnerability can include source code analysis results, topology behavior analysis results, known vulnerability database synchronization results, configuration verification results, protocol rule verification results, or manual confirmation results.

[0054] In this embodiment, the following three non-limiting implementation methods for obtaining vulnerability sets are provided.

[0055] In a first implementation, computer device 200 can obtain source code vulnerabilities through a first intelligent agent. The first intelligent agent can obtain the source code of the DNS resolution software in the Domain Name System 160. The resolution software may include recursive resolver software, authoritative server software, forwarding resolution software, or caching resolution software. The first intelligent agent can construct a code attribute graph from the source code. The code attribute graph may include at least one of an abstract syntax tree, a control flow graph, or a data flow graph. The first intelligent agent can perform vulnerability analysis on the source code based on the code attribute graph to obtain source code vulnerabilities in a vulnerability set.

[0056] The first intelligent agent can query a knowledge base when analyzing source code. This knowledge base can include one or more of the following: data source, rule base, expert base, or risk base. The data source can store the parsing software source code repository, the parsing topology database, and the behavior database. For example, the parsing software source code repository can periodically pull official repositories from BIND, Unbound, PowerDNS, and Knot using a Git repository synchronizer, including all branches and tags. For instance, the source code can be stored in MinIO object storage, organized by software name / version / file path. Simultaneously, an abstract syntax tree (AST) for each language is generated using a language recognition tool, and the AST is imported into the Neo4j graph database. Nodes are treated as functions, variables, and basic blocks, and edges are treated as call relationships, control flow edges, and data flow edges. During each incremental update, only the changed files are re-parsed and the graph structure is updated. The parsing topology database and behavior database can be constructed using an active probing system to create a full-path topology and behavior database for domain name resolution. The rule base stores DNS protocol rules, security encoding rules, and resolution configuration rules. Rules in the rule base can be broken down into atomic constraints and stored as structured entries. The rule base can collect all DNS-related request for comments (RFCs), national standards, and industry standards from the Internet Engineering Task Force (IETF). Web crawlers are used to automatically crawl and parse these documents, breaking each rule down into atomic constraints; for example, NS records must point to a domain name, not a CNAME record. Each constraint entry is stored as a text block in Elasticsearch, and a vector generated using a model is stored in a vector database, labeled with the rule type, source, and version. The rule type can include strong constraints, recommended constraints, or prohibited items. The expert database stores experiential knowledge, email discussions, or rule explanations in the DNS security field. The expert database periodically and incrementally crawls the entire history and new emails of the working group's mailing list, using a large model for email cleaning, topic clustering, and key point extraction. For example, email discussions are transformed into structured knowledge, including elements such as topics, viewpoints, points of contention, and conclusions. Each email and the knowledge extracted from it are stored in a vector database. At the same time, entities are extracted to build a knowledge graph, such as vulnerability number, RFC number, person name, and software name.The risk database stores known DNS vulnerabilities, affected software versions, vulnerability types, triggering conditions, exploitation methods, remediation plans, patch information, and historical attack patterns. It can be synchronized daily with known DNS vulnerabilities through the National Vulnerability Database Application Programming Interface (NVD API), the China National Vulnerability Database (CNVD), and the official interface of the National Vulnerability Database (NVDB). Simultaneously, it crawls papers from top security conferences and preprint platforms, using a generation of bibliographic data (Grobid) tool to parse portable document format (PDF) and extract vulnerability descriptions. These are uniformly modeled as structured entries, including common vulnerabilities and exposures (CVE) numbers, affected software versions, vulnerability types, triggering conditions, exploitation methods, remediation plans, publication dates, and reference links. Vulnerability-related patch commits extract pre- and post-modification code snippets, store them in a graph database, and associate them with function nodes in the source code repository. The first intelligent agent can match protocol constraints in the rule base with function calls, state transitions, exception handling branches, or data flow paths in the code attribute graph, and can output candidate risk functions, candidate risk code snippets, and risk explanation information.

[0057] In the second implementation, computer device 200 can acquire topology vulnerabilities through a second intelligent agent. The second intelligent agent can acquire DNS resolution topology data and behavioral data of the Domain Name System 160. The resolution topology data may include domain name nodes, name server (NS) record nodes, internet protocol (IP) address nodes, canonical name (CNAME) relationships, parent-child domain relationships, authority relationships, and resolution dependencies. The behavioral data may include response code distribution, resolution latency, server reachability, NS change frequency, query failure rate, time-to-live (TTL) changes, abnormal response rate, and differences between different probe nodes.

[0058] The second intelligent agent can determine the domain name resolution topology based on the resolution topology data. The domain name resolution topology can include multiple resolution nodes and dependencies connecting them. The second intelligent agent can obtain topological vulnerabilities from the vulnerability set based on behavioral data and the domain name resolution topology. For example, the second intelligent agent can identify NS relationships that violate protocol rules, abnormal CNAME links, abnormally concentrated resolution failures, cascading effects caused by critical NS node failures, and topological subgraphs similar to historical risk patterns. The second intelligent agent can query a knowledge base when analyzing the resolution topology and behavioral data. The knowledge base can include one or more of the following: data source, rule base, expert base, and risk base. Data sources can include the source code library of the DNS software, the resolution topology database, and the behavioral database. The rule base can store DNS protocol rules, resolution dependency rules, NS record rules, CNAME redirection rules, or resolution configuration rules. Rules in the rule base can be broken down into atomic constraints and stored in a structured entry format. The expert base can store experiential knowledge in the DNS security field, email discussions, explanations of unconventional resolution behaviors, or rule explanations. The risk base can be used to store known DNS vulnerabilities, affected software versions, vulnerability types, triggering conditions, exploitation methods, patching schemes, patch information, or historical attack patterns. The second intelligent agent can match the protocol constraints in the rule base with the resolution nodes, edge types, resolution dependencies, or behavior time series in the domain name resolution topology, and can output candidate risk nodes, candidate risk edges, candidate risk resolution paths, or risk explanation information.

[0059] In a third implementation, computer device 200 may also add vulnerabilities from a known vulnerability database to the vulnerability set. The known vulnerability database may include publicly available vulnerability databases, industry vulnerability databases, internal risk databases, or confirmed historical vulnerability records. Computer device 200 may associate known vulnerabilities with objects in the Domain Name System 160 based on software version resolution, service fingerprint, configuration characteristics, or topology location. Successfully associated known vulnerabilities can be used as candidate vulnerabilities in the vulnerability set.

[0060] Computer device 200 can normalize vulnerabilities from different sources. Normalization may include one or more of the following: field completion, type mapping, confidence level processing, unification of affected objects, and structuring of trigger conditions. After normalization, vulnerabilities in the vulnerability set can be represented using a unified data structure. A unified data structure facilitates subsequent vulnerability combination, path searching, test task generation, or risk report generation.

[0061] It should be noted that the three methods for obtaining the vulnerability set described above are illustrative examples and are not intended to be limiting. In other embodiments, the computer device 200 may also use other methods to obtain the vulnerability set.

[0062] S302: Computer device 200 combines vulnerabilities in the vulnerability set to obtain at least one combined vulnerability path.

[0063] Combined vulnerability paths can be used to characterize the order in which multiple vulnerabilities in a vulnerability set are attacked. Different combined vulnerability paths can include different vulnerabilities, or they can include the same vulnerability but with different attack orders.

[0064] The path description information for a combined vulnerability path can include starting conditions, intermediate states, and target states. Starting conditions can characterize the access conditions or configuration state required before the vulnerability is exploited; intermediate states can characterize the change in risk state after the vulnerability is exploited; and target states can characterize the attack target or risk consequences. For example, a combined vulnerability path can include vulnerability A and vulnerability B. The access conditions or configuration state required before vulnerability A is exploited can serve as the starting condition; after vulnerability A is exploited, the access control state of the intermediate NS node can change from a normal state to a disabled state, which can serve as a prerequisite for further exploiting vulnerability B; after vulnerability B is exploited, the subdomain resolution result can be abnormally altered.

[0065] In this embodiment, a non-limiting implementation method is provided for the following three combinations of vulnerabilities.

[0066] In the first implementation, the computer device 200 can first perform single-vulnerability attack tests on each vulnerability in the vulnerability set to obtain the test results for each vulnerability. The single-vulnerability attack tests can be performed in an isolated testing environment, such as an isolated sandbox, a simulated network, or one or more authorized testing environments isolated from the production environment. The isolated testing environment can run the target parsing software version, target configuration, or simulated network, and is isolated from the production environment.

[0067] The third agent can be used to generate attack plans, verify vulnerability exploitability, and generate combined vulnerability paths. During single-vulnerability attack testing, the third agent can generate candidate attack plans based on the triggering conditions, affected objects, and exploitation preconditions of the vulnerability to be verified, and execute attack verification according to the candidate attack plans in an isolated test environment. When a candidate attack plan fails attack verification, the computer device 200 can obtain the corresponding error information and feed it back to the third agent. The third agent can adjust the candidate attack plan based on the error information, for example, by adjusting the field positions, message offset positions, or data encoding methods in the test message, and re-execute attack verification according to the adjusted candidate attack plan until the candidate vulnerability passes attack verification or the preset termination condition is met.

[0068] Test results can include whether the test passed, failed, partially met the trigger conditions, was uncertain, and the reason for the test failure. The computer device 200 can combine vulnerabilities in the vulnerability set based on the test results of each vulnerability. For example, the computer device 200 can use vulnerabilities that passed the test as candidate nodes in the combination path, or it can use vulnerabilities that partially meet the trigger conditions but can provide a prerequisite state as candidate nodes in the combination path.

[0069] In a second implementation, the computer device 200 can generate combined vulnerability paths based on the dependencies between vulnerabilities. These dependencies can include one or more of the following: access permission dependencies, topology dependencies, configuration dependencies, parsing data dependencies, parsing link dependencies, cache state dependencies, or temporal order dependencies. The computer device 200 can represent vulnerabilities as nodes in a graph and the dependencies between vulnerabilities as directed edges in the graph. The computer device 200 can perform path searches in the directed graph to obtain one or more combined vulnerability paths.

[0070] In the third implementation, the generation process of combined vulnerability paths can incorporate the planning capabilities of a third-party intelligent agent. The third-party agent can generate candidate attack steps based on the triggering conditions, affected objects, and pre-existing states in the vulnerability entry. The third-party agent can also query historical attack patterns or known exploit chains in the risk database to obtain combinations similar to the current vulnerability type; and it can query the rule base to determine whether candidate paths may involve bypassing protocol or configuration constraints. The computer device 200 can determine the execution order or priority of the candidate combined vulnerability paths based on the candidate attack steps, similar combinations, and constraint judgment results.

[0071] It should be noted that the above-described implementation of the vulnerability combination is illustrative and not intended to limit the scope. In other embodiments, the computer device 200 may also employ other methods to combine vulnerabilities.

[0072] S303: Computer device 200 performs attack tests on at least one combined vulnerability path and obtains test results corresponding to each combined vulnerability path in the at least one combined vulnerability path.

[0073] Attack tests combining vulnerability paths can be performed in an isolated testing environment. For example, an isolated testing environment can include one or more of the following: an isolated sandbox, a simulated network, or an authorized testing environment isolated from the production environment. The isolated testing environment can run the target parsing software version, target configuration, or simulated network, and is isolated from the production environment. Attack tests can be used to verify the practical feasibility of combining vulnerability paths and to reduce misjudgments that arise from determining risks solely based on theoretical analysis.

[0074] When testing a combined vulnerability path, the computer device 200 can generate test tasks according to the vulnerability order in the combined vulnerability path. Test tasks may include one or more of the following: environment building tasks, configuration loading tasks, test input generation tasks, test message generation tasks, status monitoring tasks, result comparison tasks, or log collection tasks. The computer device 200 can execute the corresponding test tasks sequentially according to the vulnerability attack order indicated by the combined vulnerability path, and record the input status, output status, response results, and exception information of each test step. For example, the combined vulnerability path includes vulnerability A and vulnerability B, where vulnerability A corresponds to a configuration defect in the intermediate NS node, and vulnerability B corresponds to an exception response handling defect in the target parsing node. The computer device 200 can first execute the test task corresponding to vulnerability A, and record the NS configuration, parsing path, and cache status before the test as input status, record the parsing path changes and NS node status after the test as output status, record the response code, response time, and parsing result as response results, and record path exceptions, response timeouts, or exception response codes as exception information. If the test results for vulnerability A meet the conditions for continuing testing, computer device 200 can continue executing the test task corresponding to vulnerability B based on the output state after the test of vulnerability A, and record the input state, output state, response result, and exception information of the target parsing node. Therefore, computer device 200 can determine whether combining vulnerability A and vulnerability B in this attack order forms a combined vulnerability path that satisfies the attack target.

[0075] Test results can include one or more of the following: path verification status, target achievement status, failure reason, impact scope, risk level, reproducibility, path execution log, or path risk characteristics. Path verification status indicates whether the combined vulnerability path passed the test. Target achievement status indicates whether the test results met the attack objective. Failure reasons can include one or more of the following: preconditions not met, vulnerability cannot be triggered, path interruption, environmental differences, unstable response, or test timeout. Path risk characteristics can include attack step scripts or dependency graphs. Attack step scripts instruct the process of simulating attacks on each vulnerability in the combined vulnerability path according to the path order. Dependency graphs characterize the dependencies between vulnerabilities in the combined vulnerability path.

[0076] Attack targets can be configured according to the purpose of the Domain Name System (DNS) 160 security test. Attack targets can include one or more of the following: abnormal changes to DNS resolution results, decreased availability of DNS services, cascading impact on critical DNS nodes, abnormal cache status, generation of unexpected responses, and a proportion of abnormal response codes reaching the target conditions. Different test tasks can use the same or different attack targets. Attack targets can be set by the task scheduler reading the policy configuration or by the security test task template.

[0077] Since attack testing can be performed in an isolated testing environment without directly affecting the production domain name system 160, computer equipment 200 can reduce the risk of the attack testing process affecting the production domain name system 160 while verifying the feasibility of the combined vulnerability path.

[0078] S304: Computer device 200 determines the target combined vulnerability path based on the test results corresponding to each combined vulnerability path.

[0079] A target combination vulnerability path is a combination vulnerability path in which the test results of at least one combination vulnerability path satisfy the attack target. The computer device 200 can determine whether the test results of the combination vulnerability path satisfy the attack target based on the target achievement status, and can filter or sort the combination vulnerability paths that satisfy the attack target by combining one or more of risk level, impact scope, reproducibility, or test confidence, thereby determining the target combination vulnerability path.

[0080] For example, the test results of both the first and second combined vulnerability paths meet the attack objective. The computer device 200 can determine the risk level score, impact scope score, and test confidence score for each combined vulnerability path, and determine the path priority score based on the weighted result of these scores. The risk level score characterizes the severity of the risk corresponding to the combined vulnerability path; the impact scope score characterizes the number of domain names, DNS nodes, or critical NS nodes affected by the combined vulnerability path; and the test confidence score characterizes the credibility of the test results for the combined vulnerability path. For example, the path priority score can be determined as follows: Path Priority Score = First Weight × Risk Level Score + Second Weight × Impact Scope Score + Third Weight × Test Confidence Score. For example, if the risk level score of the first combined vulnerability path is 0.9, the impact scope score is 0.7, and the test confidence score is 0.8; and the risk level score of the second combined vulnerability path is 0.7, the impact scope score is 0.9, and the test confidence score is 0.6, then the computer device 200 can sort the first combined vulnerability path and the second combined vulnerability path according to their path priority scores, and prioritize the combined vulnerability path with the higher path priority score as the target combined vulnerability path.

[0081] Furthermore, computer device 200 can also generate path risk characteristics based on the target combined vulnerability path. Path risk characteristics may include attack step scripts or dependency graphs, and can be used as input for generating defense strategies or as explanatory information in risk reports. Through path risk characteristics, maintainers can understand the reasons for the risks arising from the combined vulnerability path and the methods of risk propagation.

[0082] S305: Computer device 200 generates a defense strategy against the target combination of vulnerability paths.

[0083] A defense strategy can be a set of measures to securely address vulnerabilities in the target vulnerability path. A defense strategy may include one or more of the following: DNS software upgrade recommendations, patch recommendations, configuration hardening recommendations, DNS resolver configuration constraints, abnormal packet detection rules, log monitoring rules, critical NS node protection strategies, DNS path redundancy strategies, access control strategies, and risk retesting plans.

[0084] In this embodiment, the following three non-limiting implementations of the generation defense strategy are provided.

[0085] In a first implementation, the computer device 200 can determine path risk characteristics based on the target combined vulnerability path and generate a defense strategy based on these characteristics. For example, when the path risk characteristics indicate that the risk originates from a vulnerability in the parsing software source code, the computer device 200 can generate a defense strategy related to the parsing software. This defense strategy may include one or more of the following: upgrading the target software version, installing or applying patches, disabling dangerous configuration items, and adding crash monitoring rules. When the path risk characteristics indicate that the risk originates from a topology relationship defect, the computer device 200 can generate a defense strategy related to the parsing topology relationship. This defense strategy may include one or more of the following: adjusting NS records, adjusting or removing abnormal CNAME resolution dependencies, increasing authoritative server redundancy configuration, and restricting or blocking high-risk resolution links.

[0086] In the second implementation, the defense strategy may include detection rules. Computer device 200 can generate detection rules based on path risk characteristics. These detection rules can be used in one or more of a network intrusion detection system, a DNS log monitoring system, or a DNS packet anomaly detection system. Detection rules may include one or more of abnormal query types, abnormal response code combinations, abnormal NS switching patterns, abnormal TTL changes, abnormal recursive links, or abnormal source address distributions. Computer device 200 can submit these detection rules to a rule base and reuse them in subsequent vulnerability set acquisition processes.

[0087] In a third implementation, computer device 200 can generate a retest task. This retest task can be executed after the defense strategy is deployed. The retest task can reconstruct the test environment for the target combined vulnerability path and verify whether the defense strategy blocks critical steps in the path. For example, if the retest results show that the defense strategy is effective, computer device 200 can mark the defense strategy as effective. If the retest results show that the defense strategy does not achieve the desired effect, computer device 200 can generate new strategy candidates or prompt for further manual processing.

[0088] It should be noted that the above-described implementation of the defense strategy is illustrative and not intended to limit the scope. In other embodiments, the computer device 200 may also employ other methods to implement the defense strategy.

[0089] See Figure 4 , Figure 4 A schematic diagram of a vulnerability set acquisition process according to an embodiment of this application is shown. In this process, such as... Figure 4 As shown, computer device 200 utilizes a first intelligent agent to acquire and parse software source code and construct a code attribute graph. The code attribute graph may include an abstract syntax tree, a control flow graph, and a data flow graph. Then, as... Figure 4 As shown, the first intelligent agent can obtain source code vulnerabilities based on the code attribute graph.

[0090] And, as Figure 4 As shown, computer device 200 can utilize a second intelligent agent to acquire DNS resolution topology data and behavioral data, and determine the DNS resolution topology structure. The second intelligent agent can then identify topology vulnerabilities based on the behavioral data and topology structure, and integrate these vulnerabilities into a vulnerability set.

[0091] In one possible implementation, the first agent can be pre-trained based on historical source code vulnerabilities and corresponding patching information in a risk database. The computer device 200 can obtain the parsing software version, code file, function identifier, vulnerability type, or patch corresponding to a publicly disclosed vulnerability from the risk database, and construct different categories of training samples based on the code content before and after the vulnerability patch. The code content before the vulnerability patch can be used to characterize the corresponding vulnerability pattern, and the code content after the vulnerability patch can be used to characterize that the corresponding vulnerability pattern has been eliminated. Then, the computer device 200 can also generate synthetic training samples based on security coding rules, protocol constraints, or parsing configuration rules in a rule base. It can also use vectorized viewpoints from expert discussions about specific vulnerabilities as part of model prompts to guide the model to focus on relevant functions. For example, the computer device 200 can set state transitions, data flow relationships, or exception handling branches that violate preset protocol constraints in the code attribute graph, thereby forming a synthetic training sample set for training the first agent. The first agent can learn the code structure features corresponding to different vulnerabilities based on historical vulnerability samples, patched samples, and synthetic training samples.

[0092] In one possible implementation, the computer device 200 can further encode protocol constraints in the rule base into attention bias information for the first agent, thereby increasing the first agent's attention to function calls, state transitions, exception handling branches, or data flow paths related to protocol constraints when processing code attribute graphs. When the first agent performs vulnerability analysis on the source code of the target parsing software, it can determine historically patched vulnerabilities in the target parsing software based on the parsing software version and patching information in the risk base, and reduce the processing priority of code regions corresponding to these patched vulnerabilities to reduce redundant analysis of the same vulnerabilities. The first agent can generate candidate risk functions for each source code file and extract the corresponding local code attribute graphs. The local code attribute graphs can include one or more nodes among candidate risk functions and their associated functions, variables, basic blocks, conditional branches, call statements, and external inputs, as well as one or more edges among call relationships, control flow relationships, and data flow relationships. The first agent can input the local code attribute graphs into a vulnerability classification model to obtain the vulnerability probabilities corresponding to the candidate risk functions, and determine the candidate risk functions whose vulnerability probabilities satisfy preset probability conditions as risk functions. The first agent can output one or more of the following: function identifier of the risk function, code location, candidate risk code snippet, vulnerability probability, violated rule number, and similar historical vulnerability information. For example, when an external input enters the critical parsing logic along the data flow path, but the data flow path lacks input validation processing, the first agent can identify the corresponding function as a candidate risk function; when a parsing state transition lacks an exception handling branch, the first agent can identify the corresponding state transition code as a candidate risk code snippet.

[0093] Furthermore, the first intelligent agent can match the source code or version information of the target parsing software with known vulnerabilities and patches in the risk database to determine the target parsing software's patching status for known vulnerabilities. The patching status can include one of the following: patched, not patched, partially patched, uncertain, or unaffected. For known vulnerabilities with a patching status of not patched or partially patched, the computer device 200 can add the known vulnerability as a source code vulnerability to the vulnerability set.

[0094] Thus, the first intelligent agent can not only discover candidate source code vulnerabilities based on the code attribute graph, but also evaluate the target parsing software's fix for known vulnerabilities, and output the source code vulnerabilities and their fix status, code location, rule violation and risk explanation information to the vulnerability set.

[0095] like Figure 4 As shown, computer device 200 can use a second intelligent agent to obtain the resolution topology data of domain name system 160 from the resolution topology database and the behavior data of domain name system 160 from the behavior database.

[0096] Topology data can include one or more of the following: domain names, NS records, IP addresses, CNAME relationships, parent-child domain relationships, authoritative relationships, address resolution relationships, and resolution dependencies. Behavioral data can include one or more of the following: DNS query messages, DNS response messages, response codes, resolution latency, server reachability, NS change frequency, query failure rate, cache validity period changes, abnormal response rate, and differences between different probe nodes.

[0097] The second agent can extract historical domain hijacking events caused by configuration errors or protocol implementation defects from the risk database, and use their corresponding topological subgraphs and behavioral time series as anomalous positive samples. Synthetic anomalies are automatically generated using RFC constraints in the rule base. For example, after obtaining the rule that NS records cannot point to CNAMEs, edges in the real topological graph are randomly modified to generate synthetic samples that violate the rule. Then, discussions on certain unconventional parsing behaviors in the expert database are used to transform the descriptions into time-series feature templates.

[0098] The second agent can determine the domain name resolution topology based on the resolution topology data. The domain name resolution topology can include multiple resolution nodes and dependencies connecting these nodes. Resolution nodes can include one or more of the following: domain name nodes, NS record nodes, IP address nodes, resolver nodes, and authoritative server nodes; dependencies can include one or more of the following: parent-child domain name relationships, authoritative relationships, CNAME relationships, address resolution relationships, and observed resolution paths.

[0099] The second intelligent agent can analyze the resolution nodes, dependencies, or resolution paths in the Domain Name System 160 based on behavioral data and the domain name resolution topology to obtain topological vulnerabilities in the vulnerability set. For example, the second intelligent agent can identify one or more of the following: NS relationships that violate protocol rules, abnormal CNAME links, abnormally concentrated resolution failures, resolution paths that are concentrated on the same resolution node, cascading effects caused by the failure of critical NS nodes, and topological subgraphs similar to historical risk patterns.

[0100] In one possible implementation, the second intelligent agent can represent the domain name resolution topology as a heterogeneous graph. Different types of nodes in the heterogeneous graph can represent domain names, NS records, IP addresses, resolvers, or authoritative servers, respectively, and different types of edges can represent parent-child domain name relationships, authoritative relationships, CNAME relationships, or address resolution relationships, respectively. The second intelligent agent can extract the behavioral time series of each resolution node or resolution path within a preset time period, and jointly process the node features in the heterogeneous graph with the behavioral time series features to obtain anomaly scores corresponding to the resolution nodes, resolution edges, or resolution paths. The behavioral time series can include one or more of the following: response code distribution, resolution latency changes, NS change frequency, query failure ratio, server reachability changes, or cache validity time changes. When the anomaly score meets preset anomaly conditions, the second intelligent agent can identify the corresponding resolution node, resolution edge, or resolution path as a candidate risk object, and can determine the target node or target edge that caused the anomaly score to meet the preset anomaly conditions based on the feature weights corresponding to different nodes or different edges. The second intelligent agent can determine topology vulnerabilities based on candidate risk objects, target nodes, or target edges. The second intelligent agent can also query one or more of the following when analyzing the resolution topology data and behavioral data: rule base, expert base, and risk base. The second intelligent agent can match the protocol constraints in the rule base with the resolution nodes, edge types, dependencies, or behavior time series in the domain name resolution topology, and output one or more of the following: candidate risk nodes, candidate risk edges, candidate risk resolution paths, violated rules, or risk explanation information.

[0101] Furthermore, the second agent can also evaluate the effectiveness of existing defenses in the Domain Name System 160. Existing defenses may include one or more of the following: DNS resolution configuration adjustments, detection rule deployment, NS node redundancy configuration, or DNS resolution path adjustments.

[0102] The second agent can acquire parsing topology data and behavioral data before and after the implementation of existing defense measures, and compare anomaly scores, parsing success rates, parsing latency, server reachability, or anomaly response rates before and after implementation. When the comparison results meet preset validity conditions, the second agent can determine that the existing defense measures are effective; otherwise, it can determine that the existing defense measures are partially effective, ineffective, or indeterminate. The second agent can use the effectiveness assessment results of the defense measures as risk interpretation information for topology vulnerabilities, or as the basis for generating subsequent defense strategies.

[0103] For example, the second agent can extract a complete topological subgraph of the target domain name space from the topological graph. Nodes include domain names, NS (Network Name), and IP addresses, edges represent resolution dependencies, and node attributes include software version fingerprints, geographical location, etc. It extracts the behavioral sequences of each domain name or resolver over the past 30 days from time-series data, such as response code distribution, RTT jitter, and NS change frequency. A time-series graph neural network is used to embed nodes into the dynamic graph, and the embedded "vectors and behavioral features" are then input into a Transformer encoder, passing through a multi-layer perceptron (MLP) to obtain anomaly scores. For domain name nodes with anomaly scores exceeding a threshold, an attention mechanism is used to locate the edges or nodes causing the anomaly, an explanation report is generated, and specific violated clauses in the rule base are cross-referenced.

[0104] The parsing topology data in the aforementioned parsing topology database and the behavioral data in the behavioral database can be generated by an active probing system performing probing tasks on the target domain name. The following describes one method for generating parsing topology data and behavioral data.

[0105] In one possible implementation, the active probing system may include multiple probing nodes deployed in one or more geographical regions. Each probing node can construct and send DNS query messages for the target domain name, and generate resolution topology data and behavioral data based on the received DNS response messages.

[0106] When performing a probe mission, the active probe system can first initialize the probe nodes. Initialization operations may include one or more of the following: network configuration, protocol stack settings, storage space allocation, and probe function module initialization. The active probe system can also load probe configuration data. This configuration data may include one or more of the following: a list of probe targets, query type, timeout duration, number of retries, and data output location. The probe nodes can construct DNS query messages based on the probe configuration data. DNS query messages may include one or more of the following: the target domain name, query type, transaction identifier, and extended options. The query type may include one or more of the following: A record query, AAAA record query, NS record query, CNAME record query, and mail exchange record query.

[0107] After constructing a DNS query message, the probe node can determine the target NS server to receive the DNS query message based on the domain name hierarchy of the target domain. Specifically, the probe node can break down the target domain into multiple levels of domain names and start searching for available NS servers from the parent domain name closest to the target domain.

[0108] For example, for the target domain sub2.sub1.example.com, the probe node can search for the corresponding NS server in the order of sub1.example.com, example.com, com, and the root domain. If the NS server corresponding to sub1.example.com does not exist or is unreachable, the probe node can continue to search for the NS server corresponding to example.com; if the NS server corresponding to example.com still does not exist or is unreachable, the probe node can continue to search the next higher domain until it finds a usable NS server or reaches the NS server corresponding to the root domain.

[0109] The probe node can send a DNS query message to a designated target NS server and wait to receive a DNS response message from the target NS server. Upon receiving the DNS response message, the probe node can check whether the format of the DNS response message meets the preset format conditions, verify whether the transaction identifier in the DNS response message matches the transaction identifier in the DNS query message, and extract the resource record from the DNS response message.

[0110] If a probe node fails to receive a DNS response message within a preset timeout period, or receives an error response, the probe node can record the abnormal state and resend the DNS query message or switch the query path within a preset number of retries. Error responses can include server failure responses, domain name non-existent responses, rejection responses, or other unexpected responses.

[0111] When a DNS response message includes an NS record, the probe node can structure the parent-child domain relationship, the NS record, and the associated additional address records, and write them into the DNS topology database. When the NS record does not carry a corresponding additional address record, the probe node can continue to query the corresponding A record or AAAA record for the NS record and associate the obtained IP address with the NS record.

[0112] When a DNS response message includes a CNAME record, the probe node can write the association between the original domain name and the target domain name pointed to by the CNAME record into the DNS topology database, and continue probing the target domain name to obtain the corresponding NS record, A record, AAAA record, or other CNAME record. By continuing to probe the target domain name pointed to by the CNAME record, the active probe system can generate one or more recursive CNAME resolution relationships.

[0113] When a DNS response message includes an A record or an AAAA record, the probe node can write the association between the domain name and the IP address into the DNS topology database. When no A record or AAAA record that meets the preset conditions is found, the probe node can write one or more of the following into the behavior database: error response code, query timeout, network unreachable, or connection error.

[0114] If the probe results indicate that the target server is abnormal or the query times out, the probe node can re-initiate the probe within a preset number of retries and attempt to change the target NS server or query path. If no response meeting the preset conditions is obtained after the preset number of retries, the probe node can write the final failure status to the behavior database.

[0115] Through the above detection process, the proactive detection system can generate one or more DNS resolution dependency paths for the target domain name. These dependency paths can include domain name nodes, NS record nodes, IP address nodes, and the parent-child domain relationships, authority relationships, CNAME relationships, address resolution relationships, or query paths connecting these nodes.

[0116] The proactive detection system can also record one or more of the following: DNS query messages, DNS response messages, response codes, resolution latency, server reachability, query failure status, NS changes, and abnormal statuses generated along the resolution dependency path, and write the above data that changes over time into the behavior database.

[0117] The proactive detection system can perform full detection of the target domain name space according to a preset period, or perform incremental detection on active domain names, changed NS records, or resolution paths identified as abnormal, in order to update the data in the resolution topology database and behavior database.

[0118] Thus, the second intelligent agent can obtain the parsed topology data and behavioral data collected and generated by the active detection system from the parsed topology database and behavioral database, and continuously identify topology vulnerabilities in the Domain Name System 160 based on the obtained data.

[0119] In one possible implementation, the vulnerability set can be stored in a versioned manner. The computer device 200 can determine whether to generate a new version of the vulnerability set based on updates to the source code repository, parsing topology database, behavior database, rule base, expert database, or risk database. Differences between different vulnerability set versions can be used to determine the scope of incremental testing. Through versioned storage, the computer device 200 can track the changes to the vulnerability set and, after the target vulnerability combination path has been verified, can retrospectively trace the source data, identification criteria, or generation version of each vulnerability in the target vulnerability combination path.

[0120] See Figure 5 , Figure 5 A schematic diagram of a closed-loop training and update process according to an embodiment of this application is shown. Figure 5 As shown, after determining the target combination vulnerability path, obtaining test results, and generating a defense strategy, the computer device 200 can add training data to the training dataset based on the target combination vulnerability path, the corresponding test results, and the defense strategy. The added training data may include one or more of the following: vulnerability entries in the target combination vulnerability path, path dependencies, test pass / fail annotations, path risk characteristics, and defense strategy types. Furthermore, when the computer device 200 performs retesting on the defense strategy or the target combination vulnerability path, the added training data may also include the retest results. For example, this closed-loop training update can employ an asynchronous workflow engine.

[0121] In this embodiment, the following four non-limiting implementation methods for agent updating and update control are provided.

[0122] In the first implementation, such as Figure 5 As shown, after determining the target vulnerability path, obtaining test results, and generating a defense strategy, the computer device 200 can add training data to the training dataset based on the target vulnerability path, the corresponding test results, and the defense strategy. It can then fine-tune the first agent based on the added training dataset. For example, when the target vulnerability path involves source code vulnerabilities, the added training data can include one or more of the following: source code vulnerability entries, related functions, related code snippets, patch information, risk explanation information, or test results from the target vulnerability path. After fine-tuning, the first agent can improve the accuracy of subsequent source code vulnerability identification and reduce missed detections of similar source code vulnerabilities.

[0123] Furthermore, the computer device 200 can fine-tune the first agent based on incremental vulnerability data accumulated within a corresponding time period according to a preset cycle. The incremental vulnerability data may include one or more of the following: new vulnerabilities confirmed within the time period, source code corresponding to the new vulnerabilities, vulnerability verification results, and patching methods.

[0124] In the second implementation, such as Figure 5As shown, after determining the target vulnerability path, obtaining test results, and generating a defense strategy, the computer device 200 can add training data to the training dataset based on the target vulnerability path, the corresponding test results, and the defense strategy, and then retrain the second agent based on the added training dataset. For example, when the target vulnerability path involves topological vulnerabilities or behavioral anomalies, the added training data may include one or more of the following: relevant topological subgraphs, behavioral time series, anomalous nodes, anomalous edges, risk labels, or anomalous labels. After retraining, the second agent can improve the accuracy and adaptability of subsequent topological vulnerability identification.

[0125] Furthermore, the update of the second agent can include full retraining and incremental graph embedding updates. When the amount of newly added parsing topology data and behavioral data, the degree of change in the parsing topology structure, or the number of newly added abnormal samples meet the preset retraining conditions, the computer device 200 can perform full retraining of the second agent based on the updated parsing topology data and behavioral data; when the preset retraining conditions are not met, the computer device 200 can incrementally update the node embeddings, edge embeddings, or behavioral features in the domain name resolution topology structure based on the incremental parsing topology data and incremental behavioral data.

[0126] In the third implementation, the computer device 200 can periodically write one or more of the following into a prompt sample library: newly verified combined vulnerability paths, attack step scripts, dependency graphs, failure adjustment procedures, or defense strategies. When the third agent subsequently generates candidate attack plans, it can retrieve and call the newly added combined vulnerability path samples without having to completely retrain the third agent each time.

[0127] In the fourth implementation, the computer device 200 can trigger agent updates according to a preset update cycle, or when the data source, rule base, expert base, risk base, or training dataset is updated. Different agents can use the same or different update cycles and triggering conditions. After the first or second agent completes fine-tuning or retraining, the computer device 200 can evaluate the performance of the updated agent using historical test datasets. Performance evaluation metrics may include one or more of recall, precision, false positive rate, false negative rate, anomaly localization accuracy, or combined vulnerability path verification success rate. The computer device 200 can compare the performance evaluation metrics corresponding to the updated agent with the performance evaluation metrics corresponding to the previous model version or a preset performance threshold.

[0128] When the updated performance evaluation metrics meet the preset performance conditions, the computer device 200 can designate the updated model version as the current version. When the updated performance evaluation metrics do not meet the preset performance conditions, the computer device 200 can stop using the updated model version and roll back to the previous model version.

[0129] Furthermore, the computer device 200 can also generate model update alarm information. The model update alarm information may include one or more of the following: agent identifier, model version before update, model version after update, performance evaluation index that does not meet preset performance conditions, and model rollback result.

[0130] By evaluating the effectiveness of the updated agent and rolling back the model when the evaluation metrics do not meet the preset performance conditions, the risk of a decline in the agent's vulnerability identification ability caused by abnormal training data or new training samples can be reduced, thereby improving the reliability of the closed-loop training and update process.

[0131] It should be noted that the above-described implementation of the intelligent agent update and update control is illustrative and not intended to limit the scope. In other embodiments, the computer device 200 may also employ other methods to update and control the intelligent agent.

[0132] The computer device 200 can also write newly generated defense strategies or security rules into the rule base, newly confirmed vulnerabilities and attack patterns into the risk base, and explanation information related to rule interpretation, attack pattern interpretation, or risk cause interpretation during testing into the expert base. For successfully verified combined vulnerability paths, the computer device 200 can also write the corresponding attack step scripts, dependency graphs, or attack chain examples into the hint sample base. After the knowledge base is updated, the computer device 200 can use the updated knowledge in the next round of vulnerability set acquisition, combined vulnerability path generation, and combined vulnerability path attack testing. Through this closed-loop update method, the vulnerability handling process can form a continuous optimization capability.

[0133] In one possible implementation, the computer device 200 can uniformly manage one or more of the following tasks: new vulnerability discovery tasks, risk assessment tasks, or new attack pattern and defense strategy generation tasks, through a task scheduler. The task scheduler can be implemented based on a workflow engine, for example, based on the Temporal workflow engine. The aforementioned tasks can be triggered according to a preset cycle, triggered in response to task instructions, or automatically triggered when preset event triggering conditions are met.

[0134] In this embodiment, the following three tasks and their triggering methods are provided as non-limiting examples.

[0135] In the first example task, the task scheduler can execute a new vulnerability discovery task. This task can be automatically triggered at a preset cycle, for example, once a week. After the task is triggered, the first agent can acquire and analyze the updated parsing software versions and their source code that occurred within the corresponding time period to identify candidate source code vulnerabilities; the second agent can acquire and analyze the parsing topology data and behavioral data obtained from incremental probing within the corresponding time period to identify candidate topology vulnerabilities.

[0136] Computer device 200 can merge the candidate vulnerabilities output by the first and second intelligent agents to obtain a candidate vulnerability list, and match the candidate vulnerability list with vulnerabilities already included in the risk database to exclude vulnerabilities already included in the risk database. For candidate vulnerabilities not included in the risk database, the third intelligent agent can generate corresponding candidate attack plans and perform attack verification on the candidate vulnerabilities in an isolated testing environment.

[0137] When a candidate vulnerability passes attack verification, the computer device 200 may identify it as a newly discovered vulnerability and determine its risk level based on its impact scope, exploitation conditions, attack results, or reproducibility. Candidate vulnerabilities that fail attack verification may not be identified as newly discovered vulnerabilities, or they may be marked as candidate vulnerabilities awaiting further verification.

[0138] New vulnerability discovery tasks can output vulnerability reports. Vulnerability reports can include one or more of the following: affected software, affected software version, affected domain pattern, vulnerability triggering conditions, verification script, verification log, vulnerability risk level, and recommended remediation solutions.

[0139] Furthermore, when performing the aforementioned new vulnerability discovery task, for the target DNS software version that has been updated within the corresponding time period, the first agent can update the corresponding code attribute graph based on the changed source code files, and identify newly added or changed candidate risk functions based on the updated code attribute graph. The second agent can obtain the domain name resolution topology and behavior data corresponding to the DNS nodes deploying the target DNS software version, and determine the DNS nodes, resolution paths, or domain name ranges that may be affected by the candidate source code vulnerabilities corresponding to the candidate risk functions based on the domain name resolution topology and behavior data. The computer device 200 can associate the candidate source code vulnerabilities with the actual deployment environment to determine the affected objects and scope of the candidate source code vulnerabilities.

[0140] After a candidate vulnerability is verified through attack, the third-party agent can also attempt to combine the candidate vulnerability with a topology vulnerability or a configuration vulnerability based on the triggering conditions, affected objects, and exploitation prerequisites of the candidate vulnerability, in order to generate a candidate combined vulnerability path.

[0141] When a candidate combination of vulnerability paths fails attack verification, the computer device 200 can record the corresponding reason for failure and use the reason for failure to adjust the candidate attack plan or the generation process of subsequent combination of vulnerability paths. When a candidate combination of vulnerability paths passes attack verification, the computer device 200 can determine the candidate combination of vulnerability paths as the target combination of vulnerability paths and generate a defense strategy based on the target combination of vulnerability paths.

[0142] Newly discovered vulnerabilities, target combination vulnerability paths, test results, or defense strategies can also be used as new training data to update the first, second, or third agent. The above attack verification can be performed in the isolated test environment described in step S303, and will not be elaborated further here.

[0143] In the second example task, computer device 200 can perform a risk assessment task targeting a specific domain name space or a specific DNS resolution software version. The task scheduler can obtain the target domain name space or the target DNS resolution software version and retrieve related known vulnerabilities from a risk database. For each known vulnerability retrieved, a third agent can perform attack verification by combining the current DNS resolution topology, resolution configuration, behavioral data, and vulnerability remediation status to determine whether the corresponding known vulnerability is exploitable in the current environment.

[0144] Computer device 200 can determine exploitable vulnerabilities based on attack verification results and use the domain name resolution topology to determine the risk propagation scope of the exploitable vulnerabilities. For example, when a critical NS node has an exploitable vulnerability, computer device 200 can mark the subdomains that depend on the critical NS node as having cascading risks.

[0145] Furthermore, the computer device 200 can combine vulnerabilities that have passed attack verification or partially meet the triggering conditions and can provide a preliminary state to generate candidate combined vulnerability paths. For example, when an intermediate NS node has a configuration defect and the resolution path in the target domain name space depends on the intermediate NS node, the computer device 200 can combine the configuration defect with another vulnerability or anomaly in resolution behavior to generate candidate combined vulnerability paths.

[0146] Computer device 200 can simulate the domain name resolution topology and configuration of the target domain name space in an isolated testing environment, and verify whether candidate combination vulnerability paths will lead to abnormal resolution results, decreased availability of resolution services, or cascading impact on critical resolution nodes. When the test results corresponding to the candidate combination vulnerability path meet the attack objective, computer device 200 can determine the candidate combination vulnerability path as the target combination vulnerability path, and determine the risk propagation scope and path risk characteristics based on the target combination vulnerability path.

[0147] Computer device 200 can generate a risk assessment report based on exploitable vulnerabilities, the scope of cascading risks, the target combination vulnerability path, and the path risk characteristics. This risk assessment report may include one or more of the following: a risk index, a list of high-risk domains, a risk propagation path diagram, and recommended defense strategies.

[0148] In the third example task, the task scheduler can execute a task to generate new attack patterns and defense strategies. When the third agent verifies a target combination vulnerability path not included in the risk database, the task scheduler can automatically trigger the task to generate new attack patterns and defense strategies based on the successful verification event.

[0149] After the task is triggered, the computer device 200 can generate an attack mode identifier for the target combined vulnerability path, and write one or more of the following into the risk database: attack mode identifier, vulnerability entry, attack step script, dependency graph, test results or risk impact corresponding to the target combined vulnerability path.

[0150] The computer device 200 can also invoke the defense strategy generation module to generate detection rules and hardening suggestions based on the path risk characteristics of the target combined vulnerability path. Detection rules may include one or more of the following: abnormal packet detection rules, parsing log monitoring rules, or abnormal parsing behavior detection rules; hardening suggestions may include one or more of the following: parsing software upgrade suggestions, patch repair suggestions, parsing configuration hardening suggestions, critical NS node protection suggestions, or parsing path adjustment suggestions.

[0151] The computer device 200 can write the generated detection rules or security rules into a rule base. When the target combined vulnerability path involves a new bypass method on existing RFC specifications, protocol constraints, or configuration constraints, the computer device 200 can generate risk analysis information based on the target combined vulnerability path, test results, and bypass method, and write this risk analysis information into an expert database. For example, the computer device 200 can generate simulated discussion records based on the risk analysis information to characterize vulnerability issues, bypass methods, technical viewpoints, and analysis conclusions, and store the simulated discussion records in the expert database for use by the first, second, or third intelligent agent in subsequent training or inference processes.

[0152] It should be noted that the triggering methods, execution processes, and output content of the above three tasks are for illustrative purposes only and are not intended to limit the scope of the task. In other embodiments, the computer device 200 may also adopt other task triggering methods, task execution methods, or task output formats according to actual processing needs.

[0153] Furthermore, embodiments of this application also provide a domain name system vulnerability processing device. See also Figure 6 , Figure 6A schematic diagram of a Domain Name System (DNS) vulnerability processing device according to an embodiment of this application is shown. The DNS vulnerability processing device 600 can be applied to the DNS system or deployed in computer equipment or computer equipment clusters used to maintain DNS security. The DNS vulnerability processing device 600 may include an acquisition module 610, a combination module 620, a testing module 630, a determination module 640, and a generation module 650.

[0154] Module 610 is used to obtain a set of vulnerabilities in the Domain Name System.

[0155] The combination module 620 is used to combine the vulnerabilities in the vulnerability set to obtain at least one combined vulnerability path. The combined vulnerability path is used to characterize the order in which multiple vulnerabilities in the vulnerability set are attacked. Different combined vulnerability paths include different vulnerabilities, or the attack order indicated by different combined vulnerability paths is different.

[0156] The testing module 630 is used to perform attack tests on the at least one combined vulnerability path and obtain the test results corresponding to each combined vulnerability path in the at least one combined vulnerability path.

[0157] The determination module 640 is used to determine the target combined vulnerability path based on the test results corresponding to each combined vulnerability path, wherein the target combined vulnerability path is the combined vulnerability path in which the test results of the at least one combined vulnerability path satisfy the attack target.

[0158] The generation module 650 is used to generate a defense strategy for the target combined vulnerability path, wherein the defense strategy is a strategy for security handling of vulnerabilities in the target combined vulnerability path.

[0159] In one possible implementation, the acquisition module 610 is used for: Attack tests are performed on each vulnerability in the vulnerability set to obtain the test results for each vulnerability; Based on the test results of each vulnerability, the vulnerabilities in the vulnerability set are combined to obtain at least one combined vulnerability path. The combined vulnerability path is the path obtained by combining the vulnerabilities in the vulnerability set whose test results have been verified by attack.

[0160] In one possible implementation, the generation module 650 is used for: Based on the target combined vulnerability path, the path risk characteristics of the target combined vulnerability path are determined. The path risk characteristics include an attack step script or a dependency graph. The attack step script is used to instruct the process of simulating the attack on each vulnerability in the target combined vulnerability path according to the path. The dependency graph is used to characterize the dependency relationship between each vulnerability in the target combined vulnerability path. Based on the path risk characteristics, a defense strategy is generated for the target combination of vulnerability paths.

[0161] In one possible implementation, the acquisition module 610 is used for: The source code of the domain name system's resolution software is obtained using a first intelligent agent; Using a first intelligent agent, the source code is constructed into a code attribute graph, which includes at least one of an abstract syntax tree, a control flow graph, and a data flow graph; Using a first intelligent agent, vulnerability analysis is performed on the source code based on the code attribute graph to obtain source code vulnerabilities in the vulnerability set of the domain name system.

[0162] In one possible implementation, the Domain Name System vulnerability handling device 600 further includes: The training module is used to add training data to the training dataset based on the target combination vulnerability path, the test results corresponding to the target combination vulnerability path, and the defense strategy. The training dataset is a collection of training data. The first agent is fine-tuned based on the increased training dataset.

[0163] In one possible implementation, the acquisition module 610 is used for: The second intelligent agent is used to obtain the resolution topology data and behavior data of the domain name system, wherein the resolution topology data is the resolution data obtained through domain name resolution. Using a second intelligent agent, a domain name resolution topology is determined based on the resolution topology data. The domain name resolution topology includes multiple resolution nodes and the dependency relationships connecting the multiple resolution nodes. Using a second intelligent agent, topological vulnerabilities in the vulnerability set are obtained based on the behavioral data and the domain name resolution topology.

[0164] In one possible implementation, the training module is further configured to: Based on the target combination vulnerability path, the test results corresponding to the target combination vulnerability path, and the defense strategy, training data is added to the training dataset, which is a collection of training data. The second agent is retrained based on the increased training dataset.

[0165] The domain name system vulnerability processing device 600 provided in this embodiment corresponds to the above-mentioned... Figure 3 and Figure 4 The domain name system vulnerability handling method in the illustrated embodiment is described above. Therefore, the functions of each module and its technical effects in this embodiment can be found in the foregoing. Figure 3 and Figure 4The relevant descriptions in the illustrated embodiments will not be repeated here.

[0166] In addition, this application also provides a computer device cluster. The computer device cluster may include at least one computer device. Each computer device may include a processor and a memory. The memory may store computer instructions. The processor may execute the Domain Name System (DNS) vulnerability handling method provided in this application according to the computer instructions. Multiple computer devices in the computer device cluster may divide tasks such as vulnerability set acquisition, path combination, path testing, defense strategy or generation model update.

[0167] In addition, embodiments of this application also provide a computer-readable storage medium. Instructions can be stored in the computer-readable storage medium. When the instructions are executed on a computer device, the computer device can perform the Domain Name System vulnerability handling method provided in embodiments of this application.

[0168] Additionally, this application also provides a computer program product. The computer program product may include computer instructions. When the computer program product is run on a computer device, it can cause the computer device to execute the Domain Name System vulnerability handling method provided in this application.

[0169] Based on the above description of the embodiments, those skilled in the art will understand that all or part of the steps in the embodiments of this application can be implemented using software plus a general-purpose hardware platform, or can be implemented using dedicated hardware. Based on this understanding, the technical solution of this application can be embodied in the form of a software product. This software product can be stored in a computer-readable storage medium and may include several instructions to cause a computer device to execute the methods in the various embodiments of this application.

[0170] The above description is merely an exemplary embodiment of this application and is not intended to limit the scope of protection of this application. Any equivalent substitutions, modifications, or improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for handling vulnerabilities in the Domain Name System, characterized in that, The method is applied to the Domain Name System and includes: Obtain the vulnerability set of the domain name system; The vulnerabilities in the vulnerability set are combined to obtain at least one combined vulnerability path. The combined vulnerability path is used to characterize the attack order of multiple vulnerabilities in the vulnerability set. Different combined vulnerability paths include different vulnerabilities, or the attack order indicated by different combined vulnerability paths is different. Attack tests are performed on the at least one combined vulnerability path to obtain the test results corresponding to each combined vulnerability path in the at least one combined vulnerability path; Based on the test results corresponding to each combined vulnerability path, a target combined vulnerability path is determined. The target combined vulnerability path is a combined vulnerability path in which the test results of the at least one combined vulnerability path satisfy the attack target. Generate a defense strategy for the target combined vulnerability path, wherein the defense strategy is a strategy for security handling of vulnerabilities in the target combined vulnerability path.

2. The method according to claim 1, characterized in that, The combination of vulnerabilities in the vulnerability set to obtain at least one combined vulnerability path includes: Attack tests are performed on each vulnerability in the vulnerability set to obtain the test results for each vulnerability; Based on the test results of each vulnerability, the vulnerabilities in the vulnerability set are combined to obtain at least one combined vulnerability path. The combined vulnerability path is the path obtained by combining the vulnerabilities in the vulnerability set whose test results have been verified by attack.

3. The method according to claim 1, characterized in that, The generation of a defense strategy targeting the combined vulnerability path of the target includes: Based on the target combined vulnerability path, the path risk characteristics of the target combined vulnerability path are determined. The path risk characteristics include an attack step script or a dependency graph. The attack step script is used to instruct the process of simulating the attack on each vulnerability in the target combined vulnerability path according to the path. The dependency graph is used to characterize the dependency relationship between each vulnerability in the target combined vulnerability path. Based on the path risk characteristics, a defense strategy is generated for the target combination of vulnerability paths.

4. The method according to claim 1, characterized in that, The acquisition of the vulnerability set of the domain name system includes: The source code of the domain name system's resolution software is obtained using a first intelligent agent; Using a first intelligent agent, the source code is constructed into a code attribute graph, which includes at least one of an abstract syntax tree, a control flow graph, and a data flow graph; Using a first intelligent agent, vulnerability analysis is performed on the source code based on the code attribute graph to obtain source code vulnerabilities in the vulnerability set of the domain name system.

5. The method according to claim 4, characterized in that, After generating a defense strategy for the target combination of vulnerability paths, the following is also included: Based on the target combination vulnerability path, the test results corresponding to the target combination vulnerability path, and the defense strategy, training data is added to the training dataset, which is a collection of training data. The first agent is fine-tuned based on the increased training dataset.

6. The method according to claim 1, characterized in that, The acquisition of the vulnerability set of the domain name system includes: The second intelligent agent is used to obtain the resolution topology data and behavior data of the domain name system, wherein the resolution topology data is the resolution data obtained through domain name resolution. Using a second intelligent agent, a domain name resolution topology is determined based on the resolution topology data. The domain name resolution topology includes multiple resolution nodes and the dependency relationships connecting the multiple resolution nodes. Using a second intelligent agent, topological vulnerabilities in the vulnerability set are obtained based on the behavioral data and the domain name resolution topology.

7. The method according to claim 6, characterized in that, After generating a defense strategy for the target combination of vulnerability paths, the following is also included: Based on the target combination vulnerability path, the test results corresponding to the target combination vulnerability path, and the defense strategy, training data is added to the training dataset, which is a collection of training data. The second agent is retrained based on the increased training dataset.

8. A domain name system vulnerability processing device, characterized in that, The device is applied to the domain name system and includes: The acquisition module is used to acquire the vulnerability set of the domain name system; The combination module is used to combine vulnerabilities in the vulnerability set to obtain at least one combined vulnerability path. The combined vulnerability path is used to characterize the attack order of multiple vulnerabilities in the vulnerability set. Different combined vulnerability paths include different vulnerabilities, or the attack order indicated by different combined vulnerability paths is different. The testing module is used to perform attack tests on the at least one combined vulnerability path and obtain the test results corresponding to each combined vulnerability path in the at least one combined vulnerability path. The determination module is used to determine the target combined vulnerability path based on the test results corresponding to each combined vulnerability path, wherein the target combined vulnerability path is the combined vulnerability path in which the test results of the at least one combined vulnerability path satisfy the attack target; The generation module is used to generate a defense strategy for the target combined vulnerability path, wherein the defense strategy is a strategy for security handling of vulnerabilities in the target combined vulnerability path.

9. A computer equipment cluster, characterized in that, The computer device cluster includes at least one computer device, each computer device comprising a processor and a memory for storing computer instructions; the processor is configured to execute the computer instructions to cause the computer device cluster to perform the operational steps of the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed on a computing device, cause the computing device to perform the method as described in any one of claims 1 to 7.

11. A computer program product, characterized in that, When it is run on a computing device, it causes the computing device to perform the method as described in any one of claims 1 to 7.

Images