Distributed verification method, device, medium and equipment for domain name system configuration

Abstract

The present disclosure provides a distributed verification method, apparatus, medium, and device for a domain name system (DNS) configuration. The method comprises: determining, based on a received verification request for a target zone file, the attribute type to be verified corresponding to the target zone file and its corresponding verification process parameters; generating a corresponding behavior tree based on the target zone file; traversing the behavior tree using symbolic execution to generate a set of local equivalence classes; and querying and verifying the set of local equivalence classes based on the attribute type to be verified and the verification process parameters. The technical solutions of the embodiments of the present application can improve the pertinence of DNS configuration verification and ensure the accuracy of DNS configuration verification.

Description

Technical Field

[0001] The present disclosure belongs to the technical field of domain name systems, and in particular relates to a distributed verification method, apparatus, medium, and device for domain name system configuration. Background Art

[0002] DNS (Domain Name System) is one of the largest distributed systems used on the Internet today. It implements the basic service of name resolution, which is to convert user-friendly domain names into IP addresses for network communication. The management of the DNS database is partitioned across multiple authoritative servers, which can be maintained by different organizations and referenced by their own domain names. Specifically, the authoritative server includes a set of zones, each of which contains DNS records that provide information for resolving a specific domain name and some of its possible subdomains. To ensure that domain names can be effectively resolved and correctly mapped to the corresponding IP addresses, administrators need to configure each zone file, such as adding or modifying domain name records. However, due to the scale and complexity of DNS, DNS configuration errors are common in practice.

[0003] Current technical solutions often employ a centralized static analysis of DNS configuration files using the Groot validator, which proactively and exhaustively detects errors before DNS configuration deployment. However, processing configuration file data from all servers in this manner not only imposes significant computational and communication overhead on the configuration verification process, but also halts the entire DNS configuration verification system if the validator fails. Consequently, improving the relevance and accuracy of DNS configuration verification has become a pressing technical challenge. Summary of the Invention

[0004] The embodiments of the present application provide a distributed verification method, apparatus, medium, and device for a domain name system configuration, thereby improving the pertinence of the domain name system configuration verification and ensuring the accuracy of the domain name system configuration verification, at least to a certain extent.

[0005] Other features and advantages of the present application will become apparent from the following detailed description, or may be learned in part by practice of the present application.

[0006] According to one aspect of an embodiment of the present application, a distributed verification method for a domain name system configuration is provided, which is applied to a DNS authoritative server. The method includes:

[0007] Determining, according to the received verification request for the target zone file, a to-be-verified attribute type corresponding to the target zone file and a corresponding verification process parameter;

[0008] Generate a corresponding behavior tree based on the target region file;

[0009] Traversing the behavior tree using symbolic execution to generate a set of local equivalence classes;

[0010] The local equivalence class set is queried and verified according to the attribute type to be verified and the verification process parameters.

[0011] According to one aspect of an embodiment of the present application, a distributed verification device for a domain name system configuration is provided, which is applied to a DNS authoritative server, and includes:

[0012] a determination module, configured to determine, according to a received verification request for a target zone file, a to-be-verified attribute type corresponding to the target zone file and a corresponding verification process parameter;

[0013] A generation module, configured to generate a corresponding behavior tree based on the target region file;

[0014] an execution module, configured to traverse the behavior tree using symbolic execution to generate a local equivalence class set;

[0015] A processing module is used to query and verify the local equivalence class set according to the attribute type to be verified and the verification process parameters.

[0016] According to one aspect of an embodiment of the present application, a computer-readable medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the distributed verification method of the domain name system configuration as described in the above embodiment is implemented.

[0017] According to one aspect of an embodiment of the present application, an electronic device is provided, comprising: one or more processors; a storage device for storing one or more programs, which, when executed by the one or more processors, enables the one or more processors to implement the distributed verification method for the domain name system configuration as described in the above embodiments.

[0018] According to one aspect of an embodiment of the present application, a computer program product or computer program is provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the distributed verification method for a domain name system configuration provided in the above-described embodiment.

[0019] In the technical solutions provided in some embodiments of the present application, a distributed verification method for a domain name system configuration is applied to a DNS authoritative server. The method determines the attribute type to be verified corresponding to the target zone file and its corresponding verification process parameters based on a received verification request for a target zone file, and generates a corresponding behavior tree based on the target zone file. Subsequently, symbolic execution is used to traverse the behavior tree to generate a local equivalence class set, and then the local equivalence class set is queried and verified based on the attribute type to be verified and the verification process parameters.

[0020] Therefore, configuration verification based on a single zone file in a single DNS authoritative server can not only reduce the huge overhead caused by processing configuration data of multiple servers at the same time, but also, when a new zone file exists, configuration verification can be performed only on the new zone file without verifying all configuration data, thereby improving the targetedness of domain name system configuration verification; and, a behavior tree is generated according to the target zone file, and symbolic execution is used to generate the corresponding local equivalence class set, and query verification is then performed based on the local equivalence class set, thereby ensuring the accuracy of the domain name system configuration verification result. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The accompanying drawings are incorporated into and constitute a part of the specification, illustrating embodiments consistent with the present application and, together with the specification, explaining the principles of the present application. Obviously, the drawings described below are only some embodiments of the present application, and those skilled in the art can derive other drawings based on these drawings without inventive effort. In the drawings:

[0022] Figure 1 A schematic diagram illustrating a flow chart of a distributed verification method for a domain name system configuration according to an embodiment of the present application is shown;

[0023] Figure 2 A schematic diagram showing a zone file according to an embodiment of the present application is shown;

[0024] Figure 3 A schematic diagram illustrating the structure of adding label nodes and type nodes when generating a behavior tree according to an embodiment of the present application is shown;

[0025] Figure 4 A schematic diagram of a structure after a tree is modified according to a record type of a type node according to an embodiment of the present application is shown;

[0026] Figure 5 A schematic diagram of the structure after adding sub-nodes and pre-defined nodes according to an embodiment of the present application is shown;

[0027] Figure 6A schematic diagram of a symbolic execution process according to an embodiment of the present application is shown;

[0028] Figure 7 A block diagram showing a distributed device for configuring a domain name system according to an embodiment of the present application is shown;

[0029] Figure 8 A schematic diagram of the structure of a computer system suitable for implementing an electronic device according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0030] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this application will be thorough and complete and will fully convey the concepts of the example embodiments to those skilled in the art.

[0031] In addition, described feature, structure or characteristic can be combined in one or more embodiments in any suitable manner.In the following description, many specific details are provided so as to provide a full understanding of the embodiments of the present application. However, it will be appreciated by those skilled in the art that the technical scheme of the present application can be put into practice without one or more of the specific details, or other methods, components, devices, steps etc. can be adopted. In other cases, known methods, devices, implementations or operations are not shown or described in detail to avoid blurring the various aspects of the application.

[0032] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically separate entities. That is, these functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0033] The flowcharts shown in the accompanying drawings are for illustrative purposes only and do not necessarily include all contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps may be decomposed, while others may be combined or partially combined. Therefore, the actual execution order may vary depending on the actual situation.

[0034] The following is an explanation of the terms involved in this application to facilitate subsequent understanding:

[0035] Query: User q:<d,t> The query is sent to the DNS server in the format of , where d represents the domain name to be queried and t represents the type of resource record to be queried;

[0036] Resource Record: Think of a resource record as a five-tuple<d,t,c,τ,v> Where d and t have the same meaning as in the query, c represents the network type, τ represents the TTL (time-to-live) of the record, and v represents the data that the user is interested in.

[0037] Action z (q)= <x,{<ν> |<d,t,c,τ,v> ∈RelR(q)}> represents the action generated for query q in zone z, where RelR(q) is the record associated with q. x represents the type of DNS answer, where x∈Ans, AnsQ, Ref, NX, Refused, or ServFail. v represents the data of interest to the user (i.e., the query result value) in the resource record associated with query q. This definition states that an action is a combination of the answer type and the query result value returned by the DNS query.

[0038] Action Trie (AT): A behavior tree is a representation of LEC (local equivalence class).

[0039] Figure 1 A flow chart of a distributed verification method for a domain name system configuration according to an embodiment of the present application is shown.

[0040] This method can be applied to DNS authoritative servers, that is, each DNS authoritative server can independently run the distributed verification method for domain name system configuration provided by this application, so that a specific zone file in a single DNS authoritative server can be configured and verified separately.

[0041] Please refer to Figure 1 The distributed verification method for the domain name system configuration includes at least steps S110 to S140, which are described in detail as follows:

[0042] In step S110, according to the received verification request for the target zone file, the attribute type to be verified corresponding to the target zone file and the corresponding verification process parameters are determined.

[0043] Among them, the verification request can be information used to request configuration verification of the zone file. In one example, the verification request can include identification information of the zone file to be configured and verified, so that the DNS authoritative server can obtain the identification information after receiving the verification request, and then determine the target zone file to be configured and verified.

[0044] In this embodiment, the verification request can be manually generated by the user according to actual needs. For example, when the administrator configures a zone file, such as modifying or adding domain name records, after the configuration is completed, the user can request configuration verification of the corresponding zone file to ensure the validity of the configuration results.

[0045] The verification request can also be automatically generated by the system. For example, the system can perform configuration verification on each zone file at a predetermined interval, or randomly select a zone file for configuration verification. Alternatively, the system can detect each zone file, and when it detects that a zone file has been modified, the system can automatically perform configuration verification on the zone file, and so on.

[0046] When the DNS authoritative server receives a verification request for a target zone file, it can receive the attributes of the zone file that need to be verified (i.e., the attribute type to be verified) specified by the user to verify it, and, based on the attribute type to be verified, the user can specify corresponding verification process parameters.

[0047] It is worth noting that the verification method provided by the present application can support verification of one or more attributes of the zone file. In one example, the attribute type to be verified may include at least one of a chain attribute and a tree attribute. Among them, the chain attribute refers to an error caused by one or more configuration errors on the query path, such as the DNS resolution response is NXDOMAIN (Non-Existent Domain), which is caused by an error in the upstream configuration file forwarding or insufficient redundancy in the downstream configuration file; the tree attribute is the opposite of the chain attribute. The tree attribute cannot be determined by only a single path, but is an error caused by multiple paths, such as the inconsistency of the DNS resolution response caused by different forwarding paths generating inconsistent results for the same query.

[0048] Verification process parameters may be information required for configuration verification of different attributes of a zone file. In one example, the verification process parameters may include at least one of a data packet format and corresponding error handling logic. The data packet format may be a data storage format, and the error handling logic may be a strategy for identifying or handling corresponding configuration errors based on the stored information. It should be understood that the verification process parameters corresponding to different attribute types to be verified may be the same or different, and this is not particularly limited.

[0049] Please continue to refer to Figure 1 In step S120, a corresponding behavior tree is generated based on the target area file.

[0050] In this embodiment, after the target region file is determined, a behavior tree may be constructed for the region file. It should be understood that the behavior tree is a tree structure containing hierarchical nodes.

[0051] In one embodiment, the behavior tree includes a label node, a type node, and a behavior node.

[0052] Specifically, a Label Node (LN) contains a set of labels that are used to match the domain name field of the query q. If qd does not match completely, it will try to match it with the next LN. If the match is successful, it will try to match it with TN using qt. If neither qd nor qt matches successfully, the query is dropped and treated as NX.

[0053] A Type Node (TN) contains a set of types that match a qt. It has one and only one AN (Action Node) as its child. When a qt matches a TN, it automatically enters the corresponding AN.

[0054] The action node is used to indicate how to process the matched query q. It can provide the value required by the query q, or modify the content of the query q and forward it further.

[0055] In one embodiment of the present application, generating a corresponding behavior tree based on the target region file includes:

[0056] Based on each resource record in the target zone file, splitting the domain name in each resource record into at least one domain name label;

[0057] Add the domain name label and record type corresponding to each resource record to the behavior tree to form corresponding label nodes and type nodes;

[0058] Modify the type node in the behavior tree according to the record type corresponding to the type node;

[0059] adding a behavior node as a child node to each of the modified type nodes, wherein the behavior node is used to represent the processing required when matching the corresponding resource record in the query;

[0060] Connect all label nodes to a predetermined node indicating a matching failure to obtain the target behavior tree.

[0061] In this embodiment, taking the zone old.com of the server ns1.digimedia.com as an example, when constructing the behavior tree, the target zone file (such as Figure 2The domain name in each resource record (as shown in ) is split into different labels. For example, the domain name www.google.com contains four labels: www, google, com, and the implicit empty label (ε) of the root domain.

[0062] Next, the domain name label and record type corresponding to the resource record in the target zone file are inserted into the tree to form a label node (LN) and a type node (TN) (such as Figure 3 shown).

[0063] After obtaining the label node and type node, modify the type node in the behavior tree according to the record type corresponding to the type node so that the modified behavior tree meets the RFC (Request for Comments) standard and ensures the accuracy of the query.

[0064] In one embodiment, modifying the type node in the behavior tree according to the record type corresponding to the type node includes:

[0065] When the type node is a DNAME node, delete its brother label node and its subtree, add a wildcard label node as a brother node for the type node, and add the wildcard type node as a child node of the wildcard label node;

[0066] When the type node is a CNAME node, delete its sibling type nodes and add a sibling type node for the type node, where the sibling type node is used to represent all other types except CNAME;

[0067] When the type node is an NS node, if the server domain name authorized by the resource record is the current server, no modification is made; if the server domain name authorized by the resource record is another server, the brother label node and its subtree of the type node are deleted, and a wildcard label node is added to the type node as its brother node, and the wildcard type node is added as a child node of the wildcard label node;

[0068] When the type of node is other nodes, no modification is made.

[0069] In this embodiment, please refer to Figure 3 and Figure 4 When modifying the behavior tree, delete the sibling label node of the DNAME node and its subtree, add a wildcard (*) label node as a sibling node of DNAME, and add a wildcard (*) type node as a child node of the wildcard label node;

[0070] Delete the sibling type node of the CNAME node, and then add a new sibling type node for CNAME. This node represents all other types except CNAME. We use (*-{CNAME}) to represent this type of node.

[0071] For NS nodes, if the server domain name authorized by the resource record is the current server, no further processing is done, for example Figure 2 The record f in the resource record authorizes the resolution of old.com to the server ns1.digimedia.com, which is the server where this record is located. If the server domain name authorized by this resource record is another server, delete the sibling label node of the NS node and its subtree, add the wildcard (*) label node as a sibling node of the NS node, and then add the wildcard (*) type node as a child node of the wildcard (*) label node.

[0072] For other record types (such as Figure 3 If the record type in is a type node of A), the tree is not modified.

[0073] Then, after modifying the behavior tree, you can add behavior nodes as child nodes for each modified node type (such as Figure 5 Each behavior sub-node indicates the processing required when the query matches the resource record.

[0074] Finally, each label node is connected to a predetermined node (such as Figure 5 AN0 node in ), thus obtaining the target behavior tree.

[0075] Please continue to refer to Figure 1 In step S130, the behavior tree is traversed using symbolic execution to generate a local equivalence class set.

[0076] In this embodiment, in order to achieve comprehensive coverage of all query possibilities, the present application adopts symbolic execution, thereby being able to explore various query paths and behaviors in the behavior tree without executing actual queries.

[0077] Please refer to Figure 6 , consider the forwarding scenario caused by CNAME record, check if there is any non-existent domain error in the zone old.com. Figure 6As shown, by traversing the behavior tree corresponding to zone com, multiple local equivalence classes are generated. One of the corresponding local equivalence classes generates a new query q1 and forwards it to the authoritative DNS servers ns1.digimedia.com and ns2.digimedia.com. At this point, only the former is considered. Next, due to record i, a new query q2 is generated. This query is ultimately received by ns2.digimedia.com and generates two local equivalence classes. One of the behaviors returns an NXDOMAIN error, indicating a non-existent domain error.

[0078] It is worth noting that in this query path, not all LECs in the new.com zone are generated, but only one LEC relevant to query q2 is matched and identified, that is, more efficient matching is achieved by only focusing on the relevant local equivalence classes of a specific query.

[0079] In one embodiment, the local equivalence class set satisfies the following conditions:

[0080] The intersection between any two local equivalence class sets corresponding to different region files is an empty set;

[0081] Different queries in the same local equivalence class set behave in the same way;

[0082] All possible queries are included in the same local equivalence class set;

[0083] The behaviors corresponding to queries in any two local equivalence class sets are inconsistent.

[0084] In this embodiment, when generating local equivalence classes, C = {c1, c2, ...c n} is a set of LECs (i.e., local equivalence classes) about a region z if C satisfies the following:

[0085]

[0086]

[0087] {d|<d,t> ∈c∧c∈LECs}=*

[0088] At the same time, if C also meets the following conditions:

[0089]

[0090] Then C is called the minimal set of LEC.

[0091] The above definition means that for all LECs in a region z:

[0092] The intersection of any two different groups of LECs is an empty set. That is, a query can only belong to one set of LECs.

[0093] Any two different queries belonging to the same LEC group will produce the same behavior in the same area. In other words, the behavior of all queries in the same LEC group must be consistent.

[0094] All domain names in the same group of LECs should include all possible query domain names, that is, a group of LECs must include all possible queries.

[0095] The corresponding behaviors for queries in the minimal set of any two sets of LECs must be inconsistent.

[0096] Therefore, the set of local equivalence classes that meet the above conditions can be as small as possible while covering all possible queries, thereby reducing processing overhead.

[0097] Please continue to refer to Figure 1 In step S140, the local equivalence class set is queried and verified according to the attribute type to be verified and the verification process parameters.

[0098] In this embodiment, the query verification process varies depending on the attribute type to be verified. The authoritative DNS server can execute the corresponding query verification policy on the local equivalence class set based on the attribute type to be verified and the verification process parameters specified by the user, forwarding the query downward according to the local equivalence class. During the forwarding process, each hop checks whether the specified attribute is violated (chain-based) or stores the data required for verification (tree-based) to ensure the accuracy of the query verification result.

[0099] In one embodiment of the present application, the attribute type to be verified includes at least one of a chain attribute and a tree attribute;

[0100] Performing query verification on the local equivalence class set according to the attribute type to be verified and the verification process parameters, including:

[0101] When the attribute type to be verified is a chain attribute, query and verify the local equivalence class set according to the verification process parameters, and during the query and verification process, add the verification information required to the query packet for forwarding, so as to record the query and verification process and store it in the server;

[0102] When the attribute type to be verified is a tree attribute, the local equivalence class set is queried and verified according to the verification process parameters, and during the query verification process, necessary information of the query verification process is stored in each server passed through for access by the designated server.

[0103] In this embodiment, for chain-type attributes, the information required to verify such attributes is appended to the query packet and forwarded together, thereby recording the entire process information for direct verification on each server. For tree-type attributes, the necessary information during the query forwarding process is recorded on each server, and then can be accessed and verified by the designated key server.

[0104] based on Figure 1 In the illustrated embodiment, a distributed verification method for a domain name system configuration is applied to a DNS authoritative server. The method determines, based on a received verification request for a target zone file, the attribute type to be verified corresponding to the target zone file and its corresponding verification process parameters, and generates a corresponding behavior tree based on the target zone file. Symbolic execution is then used to traverse the behavior tree to generate a local equivalence class set. The local equivalence class set is then queried and verified based on the attribute type to be verified and the verification process parameters.

[0105] Therefore, configuration verification based on a single zone file in a single DNS authoritative server can not only reduce the huge overhead caused by processing configuration data of multiple servers at the same time, but also, when a new zone file exists, configuration verification can be performed only on the new zone file without verifying all configuration data, thereby improving the targetedness of domain name system configuration verification; and, a behavior tree is generated according to the target zone file, and symbolic execution is used to generate the corresponding local equivalence class set, and query verification is then performed based on the local equivalence class set, thereby ensuring the accuracy of the domain name system configuration verification result.

[0106] The following describes an embodiment of the apparatus of the present application, which can be used to execute the distributed method for configuring the domain name system in the above-mentioned embodiment of the present application. For details not disclosed in the embodiment of the apparatus of the present application, please refer to the embodiment of the distributed method for configuring the domain name system in the above-mentioned embodiment of the present application.

[0107] Figure 7 A block diagram of a distributed device for configuring a domain name system according to an embodiment of the present application is shown.

[0108] Reference Figure 7 As shown, a distributed device for configuring a domain name system according to an embodiment of the present application is applied to a DNS authoritative server, and the device includes:

[0109] a determination module, configured to determine, according to a received verification request for a target zone file, a to-be-verified attribute type corresponding to the target zone file and a corresponding verification process parameter;

[0110] A generation module, configured to generate a corresponding behavior tree based on the target region file;

[0111] an execution module, configured to traverse the behavior tree using symbolic execution to generate a local equivalence class set;

[0112] A processing module is used to query and verify the local equivalence class set according to the attribute type to be verified and the verification process parameters.

[0113] In one embodiment of the present application, the behavior tree includes a label node, a type node, and a behavior node;

[0114] Based on the target region file, a corresponding behavior tree is generated, including:

[0115] Based on each resource record in the target zone file, splitting the domain name in each resource record into at least one domain name label;

[0116] Add the domain name label and record type corresponding to each resource record to the behavior tree to form corresponding label nodes and type nodes;

[0117] Modify the nodes in the behavior tree according to the record type corresponding to the type node;

[0118] adding a behavior node as a child node to each of the modified type nodes, wherein the behavior node is used to represent the processing required when matching the corresponding resource record in the query;

[0119] Connect all label nodes to a predetermined node indicating a matching failure to obtain the target behavior tree.

[0120] In one embodiment of the present application, modifying a type node in the behavior tree according to the record type corresponding to the type node includes:

[0121] When the type node is a DNAME node, delete its brother label node and its subtree, add a wildcard label node as a brother node for the type node, and add the wildcard type node as a child node of the wildcard label node;

[0122] When the type node is a CNAME node, delete its sibling type nodes and add a sibling type node for the type node, where the sibling type node is used to represent all other types except CNAME;

[0123] When the type node is an NS node, if the server domain name authorized by the resource record is the current server, no modification is made; if the server domain name authorized by the resource record is another server, the brother label node and its subtree of the type node are deleted, and a wildcard label node is added to the type node as its brother node, and the wildcard type node is added as a child node of the wildcard label node;

[0124] When the type of node is other nodes, no modification is made.

[0125] In one embodiment of the present application, the attribute type to be verified includes at least one of a chain attribute and a tree attribute;

[0126] Performing query verification on the local equivalence class set according to the attribute type to be verified and the verification process parameters, including:

[0127] When the attribute type to be verified is a chain attribute, query and verify the local equivalence class set according to the verification process parameters, and during the query and verification process, add the verification information required to the query packet for forwarding, so as to record the query and verification process and store it in the server;

[0128] When the attribute type to be verified is a tree attribute, the local equivalence class set is queried and verified according to the verification process parameters, and during the query verification process, necessary information of the query verification process is stored in each server passed through for access by the designated server.

[0129] In one embodiment of the present application, the local equivalence class set satisfies the following conditions:

[0130] The intersection between any two local equivalence class sets corresponding to different region files is an empty set;

[0131] Different queries in the same local equivalence class set behave in the same way;

[0132] All possible queries are included in the same local equivalence class set;

[0133] The behaviors corresponding to queries in any two local equivalence class sets are inconsistent.

[0134] In one embodiment of the present application, the verification process parameters include at least one of a data packet format and an error handling logic.

[0135] Figure 8 A schematic diagram of the structure of a computer system suitable for implementing an electronic device according to an embodiment of the present application is shown.

[0136] It should be noted that Figure 8 The computer system of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0137] like Figure 8As shown, the computer system includes a central processing unit (CPU) 801, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 802 or the program loaded from the storage part 808 into the random access memory (RAM) 803, such as executing the method described in the above embodiment. Various programs and data required for system operation are also stored in the RAM 803. The CPU 801, ROM 802 and RAM 803 are connected to each other via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0138] The following components are connected to the I / O interface 805: an input section 806 including a keyboard, a mouse, and the like; an output section 807 including devices such as a cathode ray tube (CRT), a liquid crystal display (LCD), and a speaker; a storage section 808 including a hard disk and the like; and a communication section 809 including a network interface card such as a LAN (Local Area Network) card or a modem. The communication section 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to the I / O interface 805 as needed. Removable media 811, such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, is installed in the drive 810 as needed, so that computer programs read therefrom can be installed into the storage section 808 as needed.

[0139] In particular, according to an embodiment of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a computer program for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 809, and / or installed from a removable medium 811. When the computer program is executed by the central processing unit (CPU) 801, the various functions defined in the system of the present application are executed.

[0140] It should be noted that the computer-readable medium shown in the embodiments of the present application may be a computer-readable signal medium or a computer-readable storage medium or any combination of the two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or component, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device. In the present application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries a computer-readable computer program. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. A computer program embodied on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, or any suitable combination thereof.

[0141] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. Among them, each box in the flowchart or block diagram can represent a module, program segment, or part of the code, and the above-mentioned module, program segment, or part of the code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0142] The units involved in the embodiments described in this application may be implemented by software or hardware, and the units described may also be set in a processor. In some cases, the names of these units do not constitute limitations on the units themselves.

[0143] As another aspect, the present application further provides a computer-readable medium, which may be included in the electronic device described in the above embodiments, or may exist independently without being incorporated into the electronic device. The computer-readable medium carries one or more programs, and when the one or more programs are executed by the electronic device, the electronic device implements the method described in the above embodiments.

[0144] It should be noted that, although several modules or units of the device for action execution are mentioned in the above detailed description, this division is not mandatory. In fact, according to the embodiment of the application, the features and functions of two or more modules or units described above can be concretized in one module or unit. On the contrary, the features and functions of one module or unit described above can be further divided into multiple modules or units to be concretized.

[0145] Through the description of the above embodiments, it is easy for those skilled in the art to understand that the example embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solution according to the embodiments of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which can be a personal computer, a server, a touch terminal, or a network device, etc.) to execute the method according to the embodiments of the present application.

[0146] Those skilled in the art will readily conceive of other embodiments of the present application after considering the specification and practicing the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present application that follow the general principles of this application and include common knowledge or customary techniques in the art that are not disclosed herein.

[0147] It should be understood that the present application is not limited to the exact structures described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A distributed verification method for domain name system configuration, characterized in that: Applied to a DNS authoritative server, the method includes: Determining, according to the received verification request for the target zone file, a to-be-verified attribute type corresponding to the target zone file and a corresponding verification process parameter; Generate a corresponding behavior tree based on the target region file; Traversing the behavior tree using symbolic execution to generate a set of local equivalence classes; Perform query verification on the local equivalence class set according to the attribute type to be verified and the verification process parameters; The behavior tree includes a label node, a type node, and a behavior node; Based on the target region file, a corresponding behavior tree is generated, including: Based on each resource record in the target zone file, splitting the domain name in each resource record into at least one domain name label; Add the domain name label and record type corresponding to each resource record to the behavior tree to form corresponding label nodes and type nodes; Modify the nodes in the behavior tree according to the record type corresponding to the type node; adding a behavior node as a child node to each of the modified type nodes, wherein the behavior node is used to represent the processing required when matching the corresponding resource record in the query; Connect all label nodes to a predetermined node indicating a match failure to obtain a target behavior tree; Modifying the type node in the behavior tree according to the record type corresponding to the type node includes: When the type node is a DNAME node, delete its brother label node and its subtree, add a wildcard label node as a brother node for the type node, and add the wildcard type node as a child node of the wildcard label node; When the type node is a CNAME node, delete its sibling type nodes and add a sibling type node for the type node, where the sibling type node is used to represent all other types except CNAME; When the type node is an NS node, if the server domain name authorized by the resource record is the current server, no modification is made; if the server domain name authorized by the resource record is another server, the brother label node and its subtree of the type node are deleted, and a wildcard label node is added to the type node as its brother node, and the wildcard type node is added as a child node of the wildcard label node; When the type of node is other nodes, no modification is made.

2. The distributed verification method for domain name system configuration according to claim 1, characterized in that: The attribute type to be verified includes at least one of a chain attribute and a tree attribute; Performing query verification on the local equivalence class set according to the attribute type to be verified and the verification process parameters, including: When the attribute type to be verified is a chain attribute, query and verify the local equivalence class set according to the verification process parameters, and during the query and verification process, add the verification information required to the query packet for forwarding, so as to record the query and verification process and store it in the server; When the attribute type to be verified is a tree attribute, the local equivalence class set is queried and verified according to the verification process parameters, and during the query verification process, necessary information of the query verification process is stored in each server passed through for access by the designated server.

3. The distributed verification method for domain name system configuration according to claim 1 or 2, characterized in that: The local equivalence class set satisfies the following conditions: The intersection between any two local equivalence class sets corresponding to different region files is an empty set; Different queries in the same local equivalence class set behave in the same way; All possible queries are included in the same local equivalence class set; The behaviors corresponding to queries in any two local equivalence class sets are inconsistent.

4. The distributed verification method for domain name system configuration according to claim 1 or 2, characterized in that: The verification process parameters include at least one of a data packet format and an error handling logic.

5. A distributed verification device for a domain name system configuration, characterized in that: Applied to a DNS authoritative server, the distributed verification device includes: a determination module, configured to determine, according to a received verification request for a target zone file, a to-be-verified attribute type corresponding to the target zone file and a corresponding verification process parameter; A generation module, configured to generate a corresponding behavior tree based on the target region file; an execution module, configured to traverse the behavior tree using symbolic execution to generate a local equivalence class set; A processing module, configured to query and verify the local equivalence class set according to the attribute type to be verified and the verification process parameters; The behavior tree includes a label node, a type node, and a behavior node; Based on the target region file, a corresponding behavior tree is generated, including: Based on each resource record in the target zone file, splitting the domain name in each resource record into at least one domain name label; Add the domain name label and record type corresponding to each resource record to the behavior tree to form corresponding label nodes and type nodes; Modify the type node in the behavior tree according to the record type corresponding to the type node; Adding a behavior node to each of the modified type nodes, wherein the behavior node is used to represent the processing required when matching the corresponding resource record in the query; Connect all label nodes to a predetermined node indicating a match failure to obtain a target behavior tree; Modifying the type node in the behavior tree according to the record type corresponding to the type node includes: When the type node is a DNAME node, delete its brother label node and its subtree, add a wildcard label node as a brother node for the type node, and add the wildcard type node as a child node of the wildcard label node; When the type node is a CNAME node, delete its sibling type nodes and add a sibling type node for the type node, where the sibling type node is used to represent all other types except CNAME; When the type node is an NS node, if the server domain name authorized by the resource record is the current server, no modification is made; if the server domain name authorized by the resource record is another server, the brother label node and its subtree of the type node are deleted, and a wildcard label node is added to the type node as its brother node, and the wildcard type node is added as a child node of the wildcard label node; When the type of node is other nodes, no modification is made.

6. A computer-readable medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the distributed verification method for a domain name system configuration according to any one of claims 1 to 4 is implemented.

7. An electronic device, characterized in that: include: one or more processors; A storage device for storing one or more programs, which, when executed by the one or more processors, enables the one or more processors to implement the distributed verification method for the domain name system configuration according to any one of claims 1 to 4.

Images