Method and system for detecting abnormal change of authoritative server based on DNSKEY smooth change

Abstract

The invention discloses an authoritative server abnormal change detection method and system based on DNSKEY smooth change, and belongs to the field of DNS security. According to the method, the DNSKEY is verified by using the trusted DS record based on the rule that the DNSKEY cannot be directly updated along with the change of the authoritative server of the domain name, so that the authenticity of the change of the authoritative server of the domain name is verified, and the abnormal change of the authoritative server is accurately identified. According to the method and the system, the authoritative server abnormal change detection system based on DNSKEY smooth change is constructed, the domain name can be regularly detected, the abnormal change of the domain name authoritative server is accurately identified, and the adverse effect on Internet users after the domain name is maliciously tampered is avoided.

Description

Technical Field

[0001] The invention relates to a method and system for detecting abnormal changes of an authoritative server based on smooth changes of DNSKEY, and belongs to the field of DNS security. Background Art

[0002] At present, the DNS system has the risk of power centralization. The power of the upper-level domain name and the lower-level domain name is not equal. The upper-level domain name has the ability to maliciously tamper with the authorization information of the lower-level domain name, resulting in the lower-level domain name being unavailable. Taking "www.baidu.com" as an example, when actually performing DNS resolution, the DNS server will query the root server, the ".com" authoritative server, and the "baidu.com" authoritative server in turn, and finally obtain the resolution result of "www.baidu.com". During the query process, the ".com" authoritative server obtains information from the root server, and the "baidu.com" authoritative server obtains information from the ".com" authoritative server. Suppose now that ".com" wants to attack "baidu.com", it can replace the information of the "baidu.com" authoritative server with forged information in the ".com" authoritative server and point it to a malicious server. Then, the Internet user will finally query "www.baidu.com" and get a malicious resolution result. This will have serious consequences, such as malicious servers may leak user information.

[0003] The prior art proposes a root zone change model for analyzing abnormal changes in top-level domains, mainly based on the rules for the disappearance of top-level domains, the rules for the change of the names of top-level domain authoritative servers, and the rules for the change of the IP addresses of top-level domain authoritative servers. By observing the top-level domain information in the current root zone version and the top-level domain information accumulated historically, the authenticity of the top-level domain changes is judged according to the three rules. However, this method cannot perfectly distinguish between normal changes and abnormal changes in top-level domains, and its applicability is limited. Summary of the invention

[0004] The present invention aims to solve the problem that the prior art cannot accurately identify abnormal changes and normal changes of the top-level domain authoritative server of a domain name, and provides a method and system for detecting abnormal changes of the authoritative server based on smooth changes of DNSKEY.

[0005] A method for detecting abnormal changes of authoritative servers based on smooth changes of DNSKEY, comprising the following steps:

[0006] Step 1: Start the detection task of the authoritative server of the domain name regularly;

[0007] Step 2: Extract the detection task at the current moment and query the DS record from the superior authoritative server of the domain name to be detected;

[0008] Step 3: Query the original server or domain name owner of the domain name for the DS record as the original trust anchor;

[0009] Step 4: Compare the DS record in step 2 with the original trust anchor in step 3. If the two are the same, there are two cases.

[0010] If the authoritative server information changes, execute step 5;

[0011] If the authoritative server information remains unchanged, skip the detection and end the task;

[0012] If the two are different, there are two cases:

[0013] If the authoritative server information has not changed, proceed to step 6;

[0014] If the authoritative server information changes, execute step 7;

[0015] Step 5: Use the trust anchor to verify the domain name's key signing key KSK, then use the key signing key KSK to verify the zone signing key ZSK, and finally use the key signing key ZSK to verify the resource record signature record RRSIG. If all keys are successfully signed, the verification is successful and the test ends; if any step of the verification fails, go to step 7;

[0016] Step 6: Use the new DS record to verify the key signing key KSK of the domain name, then use the key signing key KSK to verify the zone signing key ZSK, and finally use the zone signing key ZSK to verify the resource record signature record RRSIG. If all keys are successfully signed, the verification is successful and the trust anchor information is updated; if any step of the verification fails, execute step 7;

[0017] Step 7: Issue an alert for domain names with abnormal changes in authoritative servers.

[0018] An authoritative server abnormal change detection system based on DNSKEY smooth change, including a domain name list monitoring configuration module, an authoritative server abnormal change detection module, a trust anchor database, and an abnormal alarm module;

[0019] The authoritative server abnormal change detection module includes a task queue unit, a task launcher unit, a detection unit, a trust anchor update verification unit, and an authoritative server authenticity verification unit;

[0020] Monitoring domain name list configuration module: used to transmit the information of the newly added domain names to be monitored, and transfer the domain names into the trust anchor database after reading;

[0021] Authoritative server abnormal change detection module: used to monitor the authoritative server changes of each domain name and verify the authenticity of the authoritative server changes. If true, the data is transmitted to the trust anchor database; if false, the data is transmitted to the abnormal alarm module;

[0022] The authoritative server abnormal change detection module includes:

[0023] Task queue unit: used to store scheduled tasks, start authoritative server detection for domain names at regular intervals, and is connected to the task launcher unit;

[0024] Task initiator unit: used to extract the current detection task in the task queue and transmit it to the detection unit;

[0025] Detection unit: used to complete the detection task, first read the trust anchor of the domain name to be detected from the trust anchor database, and then compare it with the authoritative server DS record of the domain name;

[0026] Trust anchor update verification unit: used to verify the authenticity of the new DS record, use the new DS record to verify the key signing key KSK of the domain name, then use the key signing key KSK to verify the zone signing key ZSK, and finally use the zone signing key ZSK to verify the resource record signature record RRSIG. If all verifications are successful, the trust anchor information in the trust anchor database is updated; if any step of verification fails, the data is transmitted to the abnormal alarm module;

[0027] Authoritative server authenticity verification unit: used to verify the authenticity of the new authoritative server, use the trust anchor to verify the domain name's key signing key KSK, then use the key signing key KSK to verify the zone signing key ZSK, and finally use the key signing key ZSK to verify the resource record signature record RRSIG. If all verifications are successful, the detection ends. If any step of the verification fails, the data is transmitted to the abnormal alarm module.

[0028] Trust anchor database: used to maintain the original trust anchor information of each domain name. When the detection unit performs detection, it reads information from the trust anchor database. When the trust anchor update verification unit updates the trust anchor, it transmits information to the trust anchor database.

[0029] Abnormal alarm module: Issue an alarm for domain names with abnormal changes in authoritative servers.

[0030] The detection unit compares the trust anchor with the DS record of the domain name in the following cases:

[0031] If the two are the same, the DS record of the domain name has not changed. There are two situations:

[0032] If the authoritative server information changes, transmit the data to the authoritative server authenticity verification module;

[0033] If the authoritative server information remains unchanged, skip the detection and end the task;

[0034] If the two are different, the DS record of the domain name has changed, which can be divided into two situations:

[0035] If the authoritative server information has not changed, transmit the data to the trust anchor update verification unit;

[0036] If the authoritative server information changes, the data is transmitted to the abnormal alarm module.

[0037] The beneficial effects of the present invention are:

[0038] Based on the rule that DNSKEY will not be directly updated with the change of the authoritative server of the domain name, the present invention uses the trusted DS record to verify DNSKEY, thereby checking the authenticity of the change of the authoritative server of the domain name and accurately identifying the abnormal change of the authoritative server. An abnormal change detection system for the authoritative server based on the smooth change of DNSKEY is constructed, which can perform regular detection of domain names, accurately identify abnormal changes of the authoritative server of the domain name, and avoid the adverse effects of the domain name on Internet users after being maliciously tampered with. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 This is a schematic diagram of detecting abnormal changes in authoritative servers based on smooth changes in DNSKEY;

[0040] Figure 2 This is the architecture diagram of the authoritative server abnormal change detection system based on DNSKEY smooth change;

[0041] Figure 3 The initial state of the test environment of the embodiment;

[0042] Figure 4 To simulate the root server attack, update the DS record of the "cn" top-level domain;

[0043] Figure 5 To simulate the root server attack on the "cn" top-level domain without updating the DS record. DETAILED DESCRIPTION Specific implementation method one:

[0045] This embodiment is a method for detecting abnormal changes of authoritative servers based on smooth changes of DNSKEY. Smooth changes of DNSKEY mean that DNSKEY will not be directly updated as the authoritative server of the domain name changes, that is, KSK and the authoritative server will not change at the same time. The method includes the following steps:

[0046] Step 1: Start the detection task of the authoritative server of the domain name regularly;

[0047] Step 2: Extract the detection task at the current moment and query the DS record from the superior authoritative server of the domain name to be detected. There are two types of DNSKEY in DNSSEC, namely the key signing key KSK and the zone signing key ZSK. KSK is used to sign ZSK and save the hash value of KSK in its parent domain, that is, DS record, so the DS record can be used to verify the public key of KSK.

[0048] Step 3: Query the original server of the domain name or the domain name owner for the DS record as the original trust anchor. This is because the rule based on this scheme is that the DNSKEY will not be directly updated as the authoritative server of the domain name changes, that is, the KSK and the authoritative server will not change at the same time. Therefore, the authenticity of the authoritative server can be verified through the original trust anchor.

[0049] Step 4: Compare the DS record in step 2 with the original trust anchor in step 3.

[0050] If the two are the same, there are two cases:

[0051] If the authoritative server information changes, execute step 5;

[0052] If the authoritative server information remains unchanged, skip the check and end the task.

[0053] If the two are different, there are two cases:

[0054] If the authoritative server information has not changed, proceed to step 6;

[0055] If the authoritative server information changes, go to step 7.

[0056] Step 5. Use the trust anchor to verify the domain name's key signing key KSK. If the verification is successful, it can ensure that the public key of the key signing key KSK has not changed. Then use the key signing key KSK to verify the zone signing key ZSK, because only the key signing key KSK private key can successfully sign the zone signing key ZSK. If the verification is successful, it can ensure that the authoritative server holds the correct key signing key KSK private key. Finally, use the zone signing key ZSK to verify the resource record signature record RRSIG. If all public keys can be successfully signed, it means that the verification is successful and this change is an active change of the domain name owner. If any step of the verification fails, go to step 7.

[0057] Step 6: Use the new DS record to verify the domain name's key signing key KSK, then use the key signing key KSK to verify the zone signing key ZSK, and finally use the zone signing key ZSK to verify the resource record signature record RRSIG. If all keys are successfully signed, the verification is successful and the trust anchor information is updated. If any step of the verification fails, go to step 7.

[0058] Step 7: Issue an alert for domain names with abnormal changes in authoritative servers. Specific implementation method 2:

[0060] This implementation is a system for detecting abnormal changes in authoritative servers based on smooth changes in DNSKEY, including: a domain name list monitoring configuration module, an abnormal change detection module for authoritative servers, a trust anchor database, and an abnormal alarm module.

[0061] The authoritative server abnormal change detection module includes a task queue unit, a task launcher unit, a detection unit, a trust anchor update verification unit, and an authoritative server authenticity verification unit.

[0062] Monitoring domain name list configuration module: used to transmit the information of the newly added domain names to be monitored, and transfer the domain names into the trust anchor database after reading;

[0063] Authoritative server abnormal change detection module: used to monitor the authoritative server changes of each domain name and verify the authenticity of the authoritative server changes. If true, the data is transmitted to the trust anchor database; if false, the data is transmitted to the abnormal alarm module.

[0064] The authoritative server abnormal change detection module includes:

[0065] Task queue unit: used to store scheduled tasks, start authoritative server detection for domain names at regular intervals, and is connected to the task launcher unit;

[0066] Among them, the scheduled task needs to set the time interval. First, obtain the TTL value of the authoritative information of the current domain name, then set a minimum interval minTTL and a maximum interval maxTTL, and then take min{max{TTL, minTTL}, maxTTL} as the measurement interval.

[0067] Task initiator unit: used to extract the current detection task in the task queue and transmit it to the detection unit.

[0068] Detection unit: used to complete the detection task, first read the trust anchor of the domain name to be detected from the trust anchor database, and then compare it with the authoritative server DS record of the domain name;

[0069] If the two are the same, it means that the DS record of the domain name has not changed. There are two situations:

[0070] If the authoritative server information changes, transmit the data to the authoritative server authenticity verification module;

[0071] If the authoritative server information remains unchanged, skip the check and end the task.

[0072] If the two are different, it means that the DS record of the domain name has changed, which can be divided into two situations:

[0073] If the authoritative server information has not changed, transmit the data to the trust anchor update verification unit;

[0074] If the authoritative server information changes, the data is transmitted to the abnormal alarm module.

[0075] Trust anchor update verification unit: used to verify the authenticity of the new DS record, use the new DS record to verify the key signing key KSK of the domain name, then use the key signing key KSK to verify the zone signing key ZSK, and finally use the zone signing key ZSK to verify the resource record signature record RRSIG. If all verifications are successful, the trust anchor information in the trust anchor database is updated. If any step of verification fails, the data is transmitted to the abnormal alarm module.

[0076] Authoritative server authenticity verification unit: used to verify the authenticity of the new authoritative server, using the trust anchor to verify the domain name's key signing key KSK, then using the key signing key KSK to verify the zone signing key ZSK, and finally using the key signing key ZSK to verify the resource record signature record RRSIG. If all verifications are successful, the detection ends. If any step of the verification fails, the data is transmitted to the abnormal alarm module.

[0077] Trust anchor database: used to maintain the original trust anchor information of each domain name. When the detection unit performs detection, it reads information from the trust anchor database, and when the trust anchor update verification unit works, it transmits information to the trust anchor database. The trust anchor database obtains the original trust anchor by querying the DS record from the original server of the domain name or the owner of the domain name.

[0078] Abnormal alarm module: Issue an alarm for domain names with abnormal changes in authoritative servers.

[0079] Example:

[0080] This example simulates the DNS root server to maliciously tamper with the ".cn" server to verify the effectiveness of this system. The experimental steps are as follows:

[0081] Put the experimental environment into the initial state, such as Figure 3As shown, add the information of the real ".cn" authoritative server to the root server, add the information of the real "gov.cn" authoritative server to the real ".cn" authoritative server, add the real IPv4 address record of "www.gov.cn" to the zone file of the real "gov.cn" authoritative server, and configure the DNSKEY information at all levels;

[0082] Start the authoritative server abnormal change detection system based on DNSKEY smooth change, configure ".cn" in the monitoring domain name list, and add the DS record of ".cn" at this time as a trust anchor to the trust anchor database;

[0083] Simulate the root server to attack the ".cn" top-level domain, tamper with the authoritative server information of ".cn", point the ".cn" authoritative information in the root zone to the fake ".cn" authoritative server, and further point the "gov.cn" in the fake ".cn" authoritative server zone file to the fake "gov.cn" authoritative server, and finally forge the IPv4 address record of "www.gov.cn".

[0084] There are two situations for DNSSEC updates. Figure 4 As shown in the figure, the DS record of ".cn" in the root zone is directly updated to regenerate KSK and ZSK for the fake ".cn". Figure 5 As shown, the DS record of ".cn" in the root zone remains unchanged, and DNSSEC verification fails at this time.

[0085] The above two situations are to verify whether the two-stage judgment in the anomaly detection system based on DNSKEY smooth change can be correctly identified. The first is whether the trust anchor has changed, and the second is whether the trust anchor can successfully verify the information of the new authoritative server in combination with the current KSK and ZSK information.

[0086] Observe the results of the authoritative server abnormal change detection system based on DNSKEY smooth change to verify whether it recognizes the abnormal change of the ".cn" top-level domain.

[0087] The abnormal alarm module issued an alarm message about the malicious tampering of ".cn". This system can successfully detect abnormal changes in the authoritative server.

Claims

1. A method for detecting abnormal changes in authoritative servers based on smooth changes in DNSKEY, characterized in that: The program includes the following steps: Step 1: Start the detection task of the authoritative server of the domain name regularly; Step 2: Extract the detection task at the current moment and query the DS record from the superior authoritative server of the domain name to be detected; Step 3: Query the original server or domain name owner of the domain name for the DS record as the original trust anchor; Step 4: Compare the DS record in step 2 with the original trust anchor in step 3. If the two are the same, there are two cases: If the authoritative server information changes, execute step 5; If the authoritative server information remains unchanged, skip the detection and end the task; If the two are different, there are two cases: If the authoritative server information has not changed, proceed to step 6; If the authoritative server information changes, execute step 7; Step 5: Use the trust anchor to verify the domain name's key signing key KSK, then use the key signing key KSK to verify the zone signing key ZSK, and finally use the key signing key ZSK to verify the resource record signature record RRSIG. If all keys are successfully signed, the verification is successful and the test ends; if any step of the verification fails, go to step 7; Step 6: Use the new DS record to verify the key signing key KSK of the domain name, then use the key signing key KSK to verify the zone signing key ZSK, and finally use the zone signing key ZSK to verify the resource record signature record RRSIG. If all keys are successfully signed, the verification is successful and the trust anchor information is updated; if any step of the verification fails, execute step 7; Step 7: Issue an alert for domain names with abnormal changes in authoritative servers.

2. A system for detecting abnormal changes in authoritative servers based on smooth changes in DNSKEY, characterized in that: It includes monitoring domain name list configuration module, authoritative server abnormal change detection module, trust anchor database, and abnormal alarm module; The authoritative server abnormal change detection module includes a task queue unit, a task launcher unit, a detection unit, a trust anchor update verification unit, and an authoritative server authenticity verification unit; Monitoring domain name list configuration module: used to transmit the information of the newly added domain names to be monitored, and transfer the domain names into the trust anchor database after reading; Authoritative server abnormal change detection module: used to monitor the authoritative server changes of each domain name and verify the authenticity of the authoritative server changes. If true, the data is transmitted to the trust anchor database; if false, the data is transmitted to the abnormal alarm module; The authoritative server abnormal change detection module includes: Task queue unit: used to store scheduled tasks, start authoritative server detection for domain names at regular intervals, and is connected to the task launcher unit; Task initiator unit: used to extract the current detection task in the task queue and transmit it to the detection unit; Detection unit: used to complete the detection task, first read the trust anchor of the domain name to be detected from the trust anchor database, and then compare it with the authoritative server DS record of the domain name; Trust anchor update verification unit: used to verify the authenticity of the new DS record, use the new DS record to verify the key signing key KSK of the domain name, then use the key signing key KSK to verify the zone signing key ZSK, and finally use the zone signing key ZSK to verify the resource record signature record RRSIG. If all verifications are successful, the trust anchor information in the trust anchor database is updated; if any step of verification fails, the data is transmitted to the abnormal alarm module; Authoritative server authenticity verification unit: used to verify the authenticity of the new authoritative server, use the trust anchor to verify the domain name's key signing key KSK, then use the key signing key KSK to verify the zone signing key ZSK, and finally use the key signing key ZSK to verify the resource record signature record RRSIG. If all verifications are successful, the detection ends. If any step of the verification fails, the data is transmitted to the abnormal alarm module. Trust anchor database: used to maintain the original trust anchor information of each domain name. When the detection unit performs detection, it reads information from the trust anchor database. When the trust anchor update verification unit updates the trust anchor, it transmits information to the trust anchor database. Abnormal alarm module: Issue an alarm for domain names with abnormal changes in authoritative servers.

3. According to claim 2, a system for detecting abnormal changes in authoritative servers based on smooth changes in DNSKEY, characterized in that: The trust anchor database obtains the original trust anchor in the following manner: querying the DS record from the original server of the domain name or the owner of the domain name.

4. According to claim 2, a system for detecting abnormal changes in authoritative servers based on smooth changes in DNSKEY, characterized in that: The detection unit compares the trust anchor with the DS record of the domain name in the following cases: If the two are the same, the DS record of the domain name has not changed. There are two situations: If the authoritative server information changes, transmit the data to the authoritative server authenticity verification module; If the authoritative server information remains unchanged, skip the detection and end the task; If the two are different, the DS record of the domain name has changed, which can be divided into two situations: If the authoritative server information has not changed, transmit the data to the trust anchor update verification unit; If the authoritative server information changes, the data is transmitted to the abnormal alarm module.

Images