Method and system for correcting abnormal data of domain name registration information and medium

Abstract

The invention provides a domain name registration information abnormal data correction method and system and a medium, and the method comprises the steps: obtaining a storage state of first information through a mode type, the mode type comprises an active mode and a passive mode, the first information is stored domain name registration information, and the mode type comprises the active mode and the passive mode; the storage state comprises storage success and storage failure; if the storage state is storage failure, second information is obtained through a first query command, and the second information is object information of a registration bureau; and correcting the first information based on the second information. Monitoring is carried out in the process of storing domain name registration information, when it is found that local data are inconsistent with data of a registration bureau, the local data are corrected through a return result of a query command, and then the problem that gateway service local registration information is inconsistent with registration information of the registration bureau is solved.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a method, system and medium for correcting abnormal data in domain name registration information. Background Art

[0002] Domain name registrars provide domain name registration services to users. Registrars interact with registries through the EPP protocol (Extensible Provisioning Protocol) to perform domain name registration, renewal, transfer and other operations. Some registrars cannot directly connect to the registry due to technical limitations or policies and regulations. These registrars communicate with the registry through a third-party gateway service, which is used to forward EPP commands and responses to ensure smooth communication between the registrar and the registry.

[0003] After the domain name transaction is completed, the registry will generate the transaction results. In order to facilitate query, audit, statistics, analysis and other functions, the transaction results will be saved locally, and queries based on local data can also improve the system's responsiveness.

[0004] Domain users have high requirements for the response time of transaction results. Since the domain name transaction has actually been completed, local storage should be completed as soon as possible to reduce delays. However, due to network or server failures or local program abnormalities, the transaction results may be lost. After the transaction results are lost, the domain name registration information cannot be matched. Changes to some domain name registration information are performed by the registry itself, not by the registrar through the gateway. Therefore, the gateway will not have relevant change information. In summary, the above situations all lead to inconsistencies between the local registration information of the gateway service and the registration information of the registry. Summary of the invention

[0005] The present application provides a method, system and medium for correcting abnormal data in domain name registration information, so as to solve the problem of inconsistency between local registration information of a gateway service and registration information of a registry.

[0006] In a first aspect, the present application provides a method for correcting abnormal data in domain name registration information, comprising:

[0007] Acquire a storage status of the first information through a mode category, wherein the mode category includes an active mode and a passive mode, the first information is stored domain name registration information, and the storage status includes storage success and storage failure;

[0008] If the storage status is storage failure, obtaining second information through a first query command, where the second information is object information of the registry;

[0009] The first information is modified based on the second information.

[0010] In some feasible embodiments, obtaining the storage state of the first information by mode category includes:

[0011] When the mode category is a passive mode, obtaining a transaction result;

[0012] If the transaction result is successful, obtain the first information;

[0013] The first information is stored, and a storage status of the first information is obtained.

[0014] In some feasible embodiments, obtaining the storage state of the first information by mode category includes:

[0015] When the mode category is active mode, construct a command list, wherein the command list is used to record the change command sent to the registry and the sending time;

[0016] A preset response timeout, where the response timeout is the timeout response time of the registry;

[0017] Calculating a deadline, where the deadline is the sum of the sending time and a response timeout time;

[0018] If the retrieval time is later than the deadline, a correction instruction is triggered to output the storage status of the first information, the storage status is storage failure, and the retrieval time is the time for retrieving the change command in the command list.

[0019] In some feasible embodiments, the acquiring the second information through the first query command includes:

[0020] Obtain a first query command, where the first query command is used to query object information, where the object is a domain name or a host;

[0021] The first query command is sent to a registry, so that the registry returns second information, where the second information is domain name information or host information.

[0022] In some feasible embodiments, the method further includes:

[0023] If the second information includes host information, retrieving the host information from the stored information;

[0024] If the host information is not retrieved, construct a second query command, where the second query command is used to query the host information;

[0025] A second query command is sent to the registry, so that the registry returns second information.

[0026] In some feasible embodiments, the mode category further includes a receiving mode;

[0027] The acquiring the storage state of the first information by the mode category includes:

[0028] Starting the receiving mode;

[0029] Based on the receiving mode, a correction instruction is received, where the correction instruction is used to obtain a storage state of the first information.

[0030] In some feasible embodiments, the acquiring the second information through the first query command includes:

[0031] Acquire an object without authorization information, where the object without authorization information is an object that cannot send a first query command;

[0032] Matching the authorization requester of the object without authorization information, so as to send a first query command through the authorization requester;

[0033] The second information is obtained through the first query command.

[0034] In some feasible embodiments, the acquiring the second information through the first query command includes:

[0035] Identify the first query command to determine the command type;

[0036] If the command type is an info command, parse the info command and extract parameters of the info command;

[0037] A command processor is generated according to the parameters to obtain second information, and the command processor is used to process the second information.

[0038] In a second aspect, the present application provides a system for correcting abnormal data of domain name registration information, including:

[0039] A correction module, configured to obtain a storage status of first information according to a mode category, wherein the first information is stored domain name registration information, the mode category includes an active mode and a passive mode, and the storage status includes a storage success and a storage failure;

[0040] The correction module includes an executor. If the storage status is storage failure, the executor is used to obtain second information through a first query command, where the second information is object information of the registry; and is also used to correct the first information based on the second information.

[0041] In a third aspect, the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are loaded and executed by a processor, the method for correcting abnormal data in domain name registration information is implemented.

[0042] It can be seen from the above technical solutions that the present application provides a method, system and medium for correcting abnormal data in domain name registration information, the method comprising: obtaining the storage status of the first information through the mode category, the mode category comprising active mode and passive mode, the first information is the stored domain name registration information, the storage status comprises storage success and storage failure; if the storage status is storage failure, obtaining the second information through the first query command, the second information is the object information of the registry; correcting the first information based on the second information. By monitoring during the storage of domain name registration information, when it is found that the local data is inconsistent with the data of the registry, the local data is corrected through the return result of the query command, thereby solving the problem of inconsistency between the local registration information of the gateway service and the registration information of the registry. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] In order to more clearly illustrate the technical solution of the present application, the drawings required for use in the embodiments are briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0044] Figure 1 A flowchart of a method for correcting abnormal data in domain name registration information provided in an embodiment of the present application;

[0045] Figure 2 A schematic diagram of the active mode flow chart provided in an embodiment of the present application;

[0046] Figure 3 A schematic diagram of a passive mode flow chart provided in an embodiment of the present application;

[0047] Figure 4 A flow chart of an object that does not have the capability to send a first query command provided in an embodiment of the present application;

[0048] Figure 5 A schematic diagram of a flow chart of an execution module scheduling info command provided in an embodiment of the present application;

[0049] Figure 6 A schematic diagram of the structure of an asynchronous storage component provided in an embodiment of the present application. DETAILED DESCRIPTION

[0050] The following embodiments are described in detail, and examples thereof are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementations described in the following embodiments do not represent all implementations consistent with the present application. They are only examples of systems and methods consistent with some aspects of the present application as detailed in the claims.

[0051] After the domain name transaction is completed, the transaction results will be generated. Due to various factors, such as improving query efficiency, realizing audit and statistical analysis functions, etc., the registration gateway service needs to save the domain name registration information corresponding to these transaction results locally. When the registrar or domain name user needs to query the status of the domain name, the domain name registration information can be obtained from the local database without initiating a request to the registry every time, which can not only improve the system's response speed, but also reduce the burden on the registry.

[0052] During the domain name registration process, not all registrars can be directly connected to the registry. Due to technical limitations, policy and regulatory constraints or other reasons, some registrars cannot establish direct communication with the registry. In some embodiments, the registrar and the registry can be connected through a gateway service, so that registrars that cannot be directly connected can complete domain name registration and transactions through the gateway service.

[0053] In order to meet the user's requirements for transaction result response time, in some embodiments, the registration gateway service will adopt an asynchronous storage method. That is, while the transaction results are forwarded to the user, the gateway service will concurrently complete the local storage of the domain name registration information in the background, which can ensure the timely delivery of the transaction results without affecting the integrity of the local data storage.

[0054] The domain name registration information includes EPP commands, transaction results, result receiving time and other related information. Since the domain name registration information is generated at each stage of the transaction, the domain name registration information can only be stored locally after the transaction is completed.

[0055] Although the registration gateway service uses asynchronous storage and concurrent processing to minimize the impact on transaction result forwarding, domain name registration information may be lost or damaged during transmission or storage due to network failures, server abnormalities, or local program errors.

[0056] During the domain name registration process, some changes to the domain name registration information are performed by the registry itself, rather than by the registrar through the gateway. In some embodiments, the registry may directly modify the status of the domain name, such as activation, locking, unlocking, etc., based on internal policies or external requirements, and these operations will not be passed to the registrar through the gateway. For example, if a domain name is locked by the registry due to violation of regulations, but the gateway does not receive relevant notification, the domain name status in the local storage will still be "activated".

[0057] Some jurisdictions may order changes to the ownership or status of a domain name, and these changes are executed directly by the registry. For example, a domain name needs to be transferred to another party, and the registry executes the transfer according to the order, but the gateway is not aware of it, so the local data still shows the original owner information.

[0058] In some emergency situations, the registry may take special measures, such as temporarily freezing a domain name or changing its settings, to respond to security threats or other emergencies. For example, if a domain name is found to be used for malicious activities, the registry may suspend the service of the domain name and investigate it, and these actions will not be notified to the gateway through normal channels.

[0059] In summary, the above situations will cause the local data of the gateway service to be inconsistent with the data of the registry.

[0060] In order to solve the problem of inconsistency between the local data of the gateway service and the data of the registry, some embodiments of the present application provide a method for correcting abnormal data in domain name registration information. The method monitors the process of storing domain name registration information. When it is found that the local data is inconsistent with the data of the registry, the local data is corrected according to the return result of the query command, thereby improving the consistency between the local data and the data of the registry.

[0061] like Figure 1 As shown, the steps include:

[0062] S100: Acquire a storage state of first information according to a mode category.

[0063] The mode categories include active mode and passive mode. The active mode is to actively initiate data operations, such as regularly checking, updating or correcting data. The passive mode is to perform data operations only after receiving specific trigger conditions, such as error reports, user requests, and certain instructions.

[0064] The first information is the stored domain name registration information, including EPP command, transaction result, result receiving time and other related information. Among them, the EPP command is the EPP command sent to the registry, and the transaction result is the transaction result returned by the registry, including transaction status (success or failure), error code (if any), registration date, expiration date, etc. The result receiving time is the timestamp of receiving the transaction result. Other related information may include transaction ID, client transaction ID, transaction type, etc.

[0065] It is understandable that the stored domain name registration information may include one or more of the EPP command, transaction result, result receipt time and other related information, and may also not be stored, that is, although a change instruction is sent to the registry, the domain name registration information is not stored locally.

[0066] In the process of storing the first information, the stored data may be inconsistent with the data of the registry due to various reasons. That is, the storage status includes successful storage and failed storage. When the storage is successful, the domain name registration information is stored locally, such as in a local database, without further detection or retrieval.

[0067] In this embodiment, the active mode is a mode of periodically retrieving change commands through self-checking, and the passive mode is a mode of discovering inconsistency between local data and registry data through other components or modules, such as a component storing domain name registration information.

[0068] like Figure 2 As shown, for the active mode, in some embodiments, when the mode category is the active mode, a command list is constructed, the change command in the command list is retrieved, and the sending time of the change command is recorded, and the response timeout time of the registry is obtained to calculate the deadline for receiving the response, wherein the deadline is the superposition of the sending time and the response timeout time, and then compared with the retrieval time, and the retrieval time is the time to perform the check. If the deadline is earlier than the retrieval time, a correction instruction is triggered to output the storage status of the first information. At this time, the storage status is storage failure, wherein the correction instruction is used to start an instruction to correct the domain name registration information, and update or modify the registration information.

[0069] The command list is used to record the change command sent to the registry and the sending time. The sending time is the time when the change command is sent. The change command is the command that the initiated domain name needs to be changed. It is used to create (create), update (update), delete (delete) and other operations on the domain name. The create command is used to create a new domain name. The update command is used to update the information of an existing domain name, such as changing the registrant information, modifying the name server, etc. The delete command is used to delete an existing domain name. For example, if a user needs to change the DNS server of the domain name from A to B, a change command will be generated. The change command contains the domain name information, the new DNS server address and related authentication information. This change command will be sent to the domain name registrar, requiring it to update the DNS server record.

[0070] The CLTR ID (Client Transaction ID) of the EPP command can be used as an index for the command list. The CLTR ID is a field in the EPP command that uniquely identifies each transaction initiated by the client. Using CLTR ID as an index, you can quickly retrieve specific transactions in the command list, improve retrieval efficiency, and ensure that there are no duplicate transactions in the command list to avoid duplicate processing. The CLTR ID makes it easier to manage and update the status of transactions, such as "pending", "processing", "processed", etc.

[0071] For the change commands recorded in the command list, if the search is performed every 5 minutes, the response timeout is 10 minutes, and the sending time of a change command is 4:03:13, then the deadline is 4:13:13. If the command list is searched at 4:10, if the change command has received the transaction result, it will not be retrieved. If the transaction result is not received, the command will be retrieved, but the search time is earlier than the deadline, and the checker will not process the command.

[0072] At 4:15, the command list is retrieved again. If the command still has not received a transaction result, the command will be retrieved. At this time, the retrieval time is later than the deadline, so it is determined that the command has timed out and needs to be corrected.

[0073] It is understandable that if correction is required, the change command is deleted from the command list, and if correction is not required, the change command is also deleted from the command list.

[0074] In some embodiments, the command list also supports change commands for multiple object types, such as domain names, hosts, contacts, etc. For different objects, an object type field can be added to the command list to record and process change commands according to different object types.

[0075] In active mode, by actively monitoring and managing change commands, abnormal situations can be quickly identified and handled, and the timeliness and accuracy of information can be ensured through preset response timeout judgments.

[0076] like Figure 3 As shown, for the passive mode, in some embodiments, when the mode category is the passive mode, the transaction result is obtained, if the transaction result is a successful transaction, the first information is obtained, the first information is stored, and the storage status of the first information is obtained.

[0077] According to the above, the transaction result is the transaction result returned by the registry. When the result of the successful domain name transaction fed back by the registry is received, the first information, i.e., the domain name registration information, is obtained. In some embodiments, the first information is stored in the format of a task object. For example, the domain name registration information is put into a distribution queue as a task and then stored.

[0078] In the passive mode, only if the transaction is successful will the first information be obtained. If the transaction result is a failure, the next step will not be continued.

[0079] Due to asynchronous delays, response loss caused by abnormal failures, etc., updates may fail due to data inconsistency. Due to response loss or delay, the latest data status cannot be correctly reflected. In the case of data inconsistency, new information may not be successfully updated or stored, that is, the storage status is storage failure.

[0080] In some embodiments, the mode category also includes a receiving mode, and the receiving mode can also be used as a passive mode, that is, the storage status of the first information is obtained by receiving instructions from other modules. The receiving mode is first started, and the correction instructions from other modules, such as the management module, are waited for and received, and then the correction instructions are received based on the receiving mode, wherein the correction instructions are used to obtain the storage status of the first information, and the correction instructions are instructions issued after the local data is found to be inconsistent with the data of the registry. By receiving instructions from other modules and triggering the data correction process, flexibility can be improved.

[0081] After the storage status of the first information is acquired through the active mode, the passive mode, and the receiving mode, if the storage fails, the next step is performed, and if the storage succeeds, the next step is not performed.

[0082] S200: If the storage status is storage failure, obtain second information through a first query command.

[0083] When the storage status is storage failure, it indicates that the domain name registration information is not stored or stored incorrectly, triggering a correction process. In this embodiment, the domain name registration information is re-obtained from the registry. The second information is the object information of the registry, such as host information and domain name information. Exemplarily, the host information includes the host name, such as ns1.example.com, the IP address, which is the IP address of the host, the status, which is the status of the host, and other related information such as the administrator of the host.

[0084] Exemplarily, the domain name information includes the domain name name, such as example.com, the registration date, which is the registration date of the domain name or host, the expiration date, which is the expiration date of the domain name or host, the registrant information, which is the name and contact information of the registrant, the status, which is the status of the domain name or host, the name server, which is the DNS server list of the domain name, and other relevant information, such as the registrar of the domain name, technical contact, etc.

[0085] Although the EPP command, transaction result, result receiving time and other related information, i.e., the first information, and the detailed information returned by the registry, i.e., the second information, are different, they are related and can be used to correct local data. In the correction process, different second information is returned for different objects, hosts or domain names.

[0086] In some embodiments, a first query command is obtained, wherein the first query command is used to query object information, the first query command is an info command of EPP, the info command is used to query detailed information of a domain name, contact person, or host object, and then the first query command is sent to a registry to return second information through the registry, wherein the second information is domain name information or host information.

[0087] Exemplarily, an info command is generated, and the info command is used to query the information of a specific domain name. For example, the info command is "query domain name information: example.com", and then the info command is sent to the registry. After receiving the info command, the registry returns the relevant information of the domain name according to the request in the command. This information may include the owner of the domain name, registration time, expiration time, DNS server address, etc., and processes this information after receiving it. For example, if the storage failure is caused by incorrect domain name information, it can be corrected accordingly based on the correct domain name information obtained.

[0088] Before generating the first query command, the query object may be determined first. For example, if the query object is a domain name, then an EPP info command for querying domain name information is generated. If the query object is a host, then an EPP info command for querying host information is generated.

[0089] After the registry receives the info command, the second information returned matches the first query command. If the first query command is an EPP info command for querying domain name information, then the second information returned is the domain name information. If the first query command is an EPP info command for querying host information, then the second information returned is the host information.

[0090] It is understandable that the generation of the info command can be constructed using the XML format, including a root element, a command element, an info element, a domain name element, and a client transaction ID.

[0091] If the returned second information is host information or contains host information, but these hosts do not exist in the local storage, the EPP info command for querying the host information is sent again to obtain detailed information of the host and update it to the local storage. In some embodiments, the host information is extracted from the second information, and the host information is retrieved from the stored information. If the host information is not retrieved, a second query command is constructed, the second query command is used to query the host information, and the second query command is sent to the registry to return the second information through the registry.

[0092] Exemplarily, if the second information includes information of hosts ns1.example.com and ns2.example.com, check whether hosts ns1.example.com and ns2.example.com exist in the local storage. If ns1.example.com does not exist in the local storage, but ns2.example.com exists, construct an info command for querying the EPP of ns1.example.com, i.e., the second query command, and send the info command for querying the EPP of host ns1.example.com to the registry.

[0093] The EPP protocol info command will only return detailed information about the requested object if the necessary authorization information is available. In the EPP protocol, authorization information is information used to verify the user's identity and permissions to ensure that the user has the right to perform specific operations, such as querying, creating, updating, or deleting domain names, hosts, and other objects. If the authorization information of some objects cannot be obtained, it may result in the inability to obtain the second information.

[0094] like Figure 4 As shown, in some embodiments, an object without authorization information is obtained, and the object without authorization information is an object that cannot send a first query command. Then, the authorization requester of the object without authorization information is matched. The authorization requester can be a registrar, and the first query command is sent through the authorization requester, and then the second information is obtained through the first query command.

[0095] For example, check whether the host ns1.example.com has authorization information. If there is no authority to send the EPP info command of the host ns1.example.com, notify the registrar XYZ-Registrar to send the EPP info command to query the host ns1.example.com. After the registry processes the EPP info command, it returns a response containing detailed information of the host ns1.example.com.

[0096] like Figure 5 As shown, in particular, support for the first query command can also be directly added. In some embodiments, the first query command is identified to determine the command type, if the command type is an info command, the info command is parsed, and parameters of the info command are extracted, and a command processor is generated according to the parameters to obtain the second information, and the command processor is used to process the second information.

[0097] Registrars can send create and update commands, or they can send info commands, which will be forwarded to the registry through the forwarding component to get detailed feedback. Under normal circumstances, the transaction component will only forward modification-related commands to the asynchronous storage component. Info is a query-related command, so it will not forward the info command. In the process of abnormal data correction, the registrar sends the info command. If the normal result of the command is received, the relevant information (response information) of the special query command info will also be forwarded accordingly.

[0098] By adding corresponding logic, i.e. command processor, the information queried by the info command is updated and stored in the database. The distribution module can distribute the info command result to the correction module for processing, or it can be directly processed in the execution module.

[0099] S300: Correct the first information based on the second information.

[0100] After obtaining the second information from the registry, the first information is corrected or updated by comparing the second information with the first information. If the local data is inconsistent with the registry data, the first information can be corrected; if there is no data locally, that is, it is not stored, the first information can be updated, that is, the obtained second information is stored locally as the first information.

[0101] The method provided in the present application detects the storage status of domain name registration information through a specific pattern category. If storage failure is found, the abnormal data is corrected by querying the object information of the registry, thereby solving the problem of inconsistency between the local registration information of the gateway service and the registration information of the registry.

[0102] Based on the above embodiment of a method for correcting abnormal data in domain name registration information, Figure 6 As shown, some embodiments of the present application also provide a system for correcting abnormal data of domain name registration information, including:

[0103] A correction module, configured to obtain a storage status of first information according to a mode category, wherein the first information is stored domain name registration information, the mode category includes an active mode and a passive mode, and the storage status includes a storage success and a storage failure;

[0104] If the storage status is storage failure, the executor is used to obtain second information through a first query command, and the correction module includes an executor second information is object information of the registry; and is also used to correct the first information based on the second information.

[0105] In some embodiments, the system includes an asynchronous storage component and a transaction component. The asynchronous storage component is a functional component for completing asynchronous storage of domain name registration information. The transaction component is a component for receiving, verifying, forwarding commands and receiving and processing responses. When the transaction component receives the result of a successful domain name transaction returned by the registry, the domain name registration information is placed as a task in the distribution queue of the asynchronous storage component, and the result can be returned to the requester, completing the storage operation without waiting for the transaction result.

[0106] The transaction component acts as a gateway. For example, after receiving the transaction result from the registry, the transaction component forwards the result to the user to ensure that the user can quickly obtain confirmation. The transaction component encapsulates the domain name registration information into a task object and sends it to the asynchronous storage component. The asynchronous storage component receives the task object and adds it to the task queue to wait for processing. The asynchronous storage component takes the task object from the task queue and uses multi-threading or multi-process to process multiple tasks concurrently. The asynchronous storage component records the processing results of each task, including the processing time and status, for subsequent auditing and troubleshooting.

[0107] like Figure 6 As shown, in some embodiments, the asynchronous storage component includes a distribution module and an execution module. The distribution module is used to assign storage tasks to the execution module, and the execution module is used to format the task data and save it to a persistent device, for example, to a database.

[0108] The data that the execution module needs to store is the domain name registration information that has been successfully traded. When abnormalities occur in the network, server, application and other hardware and software, there is a possibility that the transaction results cannot be stored or the storage process fails, resulting in inconsistencies between local data and the registry data.

[0109] When the execution component executes storage, some data inconsistencies may cause the storage process to fail to execute. For example, when saving the registration data of the update command, there is no corresponding data in the local storage. This may be caused by the failure to correctly store the transaction result of the corresponding create command. In this case, the correction module is triggered to execute the info command of the corresponding object to obtain the latest detailed data of the object to correct the data of the local object.

[0110] Among them, the correction module is set in the asynchronous storage component to handle data anomalies and correct or complete inconsistent data. The correction module uses the info command of the EPP protocol to obtain the latest data from the registry and correct the local data. EPP domain names (RFC5731), hosts (RFC5732) and other objects support the info command and can return detailed information of the corresponding objects.

[0111] Taking the application scenario in a single-machine system as an example, the asynchronous storage component and the transaction component are implemented in the same process using a memory queue and multi-threaded model. Among them, the distribution module, execution module, correction module, and management module are all run by independent threads, the queue uses a non-blocking memory queue, and the storage system is a relational database.

[0112] In some embodiments, for active mode, the correction module further includes a checker, such as Figure 2 As shown in the figure, the checker of the correction module has a self-checking function, which can realize automatic data correction. The transaction component provides a command list. Each change command sent to the registry is recorded in the list, and the sending time of the change command is recorded. By constructing the command list, presetting the response timeout, calculating the deadline, and regularly retrieving the command list, the status of the change command sent to the registry can be effectively monitored. If the deadline of the command is earlier than the retrieval time, that is, the retrieval time is later than the deadline, and no response is received, the command is considered lost; conversely, if the deadline is later than the retrieval time, the command is still waiting for a response and has not exceeded the preset response timeout.

[0113] For change commands whose deadline is earlier than the retrieval time and are still in the command list, that is, commands with storage problems, their response information may have been lost for some reason. If the transaction results of these change commands are successful, there will be deviations between the local data and the registry data. The checker retrieves the change commands from the command list regularly, uses the info command of the EPP protocol to obtain the corresponding data from the registry, compares it with the local data, and stores it locally after correction.

[0114] The executor of the correction module is used to perform data correction. For the specified object, the executor uses the info command of the EPP protocol to obtain the object data from the registry, compares it with the local data, and then corrects it. EPP domain names, hosts, and other objects all support the info command and can return corresponding detailed information.

[0115] In particular, if the detailed information returned by the domain name's info command contains the host information used by the domain name, and the host does not exist in the local storage, the correction module should continue to send the corresponding info command for the host to obtain the detailed information of the host and update it locally; the same process is performed for the contact information in the domain name information.

[0116] For passive mode, the correction module can be notified to perform corrections without the participation of the checker, such as Figure 3As shown in the figure, after the transaction component obtains the successful response of the change transaction sent by the registry, it sends the domain name registration information as a task to the asynchronous storage component, and the execution module updates the data corresponding to the task to the local storage. Due to asynchronous delays, response loss caused by abnormal failures, etc., the update may fail due to inconsistent data. In this case, the execution module transfers the task to the correction module to perform data correction.

[0117] After receiving the task, the executor of the correction module uses the info command of the EPP protocol to obtain detailed data of the corresponding object from the registry, compares it with the local data and updates it, completes the correction of the local data and then stores it locally through the execution module.

[0118] If inconsistencies in local data are discovered through other means, in some embodiments, the asynchronous storage component may also include a management module, which is connected to the correction module. The management module may receive correction instructions from maintenance personnel and then notify the correction module to perform data correction of the specified object.

[0119] like Figure 4 As shown, for an object without authorization information and unable to send an info command, the system can notify the requesting party with the object authorization to send an info command to complete the data correction. In some embodiments, when the system finds that the data is inconsistent, it notifies the registrar to send an info command. The transaction component completes the forwarding processing of the info command and sends the query result to the asynchronous storage component. The distribution module performs special processing on non-change commands such as info and forwards it to the correction module. The correction module compares the query result with the local data and updates it to complete the correction of the local data.

[0120] like Figure 5 As shown, in particular, the distribution module may not perform special processing on the info command, but directly pass it to the execution module, and the execution module schedules the info command. In this case, the support for info is directly added to the execution module, and the registry data is updated to the local storage.

[0121] An embodiment of the present invention further provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are loaded and executed by a processor, the method for correcting abnormal data of domain name registration information is implemented.

[0122] Since the embodiments of the computer-readable storage medium part correspond to the embodiments of the domain name registration information abnormal data correction method part, the embodiments of the storage medium part refer to the description of the embodiments of the domain name registration information abnormal data correction method part, which will not be repeated here.

[0123] Similar parts between the embodiments provided in this application can be referenced to each other. The specific implementation methods provided above are only a few examples under the general concept of this application and do not constitute a limitation on the protection scope of this application. For those skilled in the art, any other implementation methods expanded based on the scheme of this application without creative work belong to the protection scope of this application.

Claims

1. A method for correcting abnormal data in domain name registration information, characterized in that: include: Acquire a storage status of the first information through a mode category, wherein the mode category includes an active mode and a passive mode, the first information is stored domain name registration information, and the storage status includes storage success and storage failure; If the storage status is storage failure, obtaining second information through a first query command, where the second information is object information of the registry; The first information is modified based on the second information.

2. The method for correcting abnormal data in domain name registration information according to claim 1, characterized in that: The acquiring the storage state of the first information by the mode category includes: When the mode category is a passive mode, obtaining a transaction result; If the transaction result is successful, obtain the first information; The first information is stored, and a storage status of the first information is obtained.

3. The method for correcting abnormal data in domain name registration information according to claim 1, characterized in that: The acquiring the storage state of the first information by the mode category includes: When the mode category is active mode, construct a command list, wherein the command list is used to record the change command sent to the registry and the sending time; A preset response timeout, where the response timeout is the timeout response time of the registry; Calculating a deadline, where the deadline is the sum of the sending time and a response timeout time; If the retrieval time is later than the deadline, a correction instruction is triggered to output the storage status of the first information, the storage status is storage failure, and the retrieval time is the time for retrieving the change command in the command list.

4. The method for correcting abnormal data in domain name registration information according to claim 1, characterized in that: The acquiring the second information through the first query command includes: Obtain a first query command, where the first query command is used to query object information, where the object is a domain name or a host; The first query command is sent to a registry, so that the registry returns second information, where the second information is domain name information or host information.

5. The method for correcting abnormal data in domain name registration information according to claim 4, characterized in that: The method further comprises: If the second information includes host information, retrieving the host information from the stored information; If the host information is not retrieved, construct a second query command, where the second query command is used to query the host information; A second query command is sent to the registry, so that the registry returns second information.

6. The method for correcting abnormal data in domain name registration information according to claim 1, characterized in that: The mode category also includes receiving mode; The acquiring the storage state of the first information by the mode category includes: Starting the receiving mode; Based on the receiving mode, a correction instruction is received, where the correction instruction is used to obtain a storage state of the first information.

7. The method for correcting abnormal data in domain name registration information according to claim 1, characterized in that: The acquiring the second information through the first query command includes: Acquire an object without authorization information, where the object without authorization information is an object that cannot send a first query command; Matching the authorization requester of the object without authorization information, so as to send a first query command through the authorization requester; The second information is obtained through the first query command.

8. The method for correcting abnormal data in domain name registration information according to claim 1, characterized in that: The acquiring the second information through the first query command includes: Identify the first query command to determine the command type; If the command type is an info command, parse the info command and extract parameters of the info command; A command processor is generated according to the parameters to obtain second information, and the command processor is used to process the second information.

9. A system for correcting abnormal data of domain name registration information, characterized in that: include: A correction module, configured to obtain a storage status of first information according to a mode category, wherein the first information is stored domain name registration information, the mode category includes an active mode and a passive mode, and the storage status includes a storage success and a storage failure; The correction module includes an executor. If the storage status is storage failure, the executor is used to obtain second information through a first query command, where the second information is object information of the registry; and is also used to correct the first information based on the second information.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are loaded and executed by the processor, the method for correcting abnormal data in domain name registration information according to any one of claims 1 to 8 is implemented.

Images