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

Abstract

The application discloses a DNSKEY smooth change-based authoritative server abnormal change detection method and system, and belongs to the DNS security field. The application is based on the rule that DNSKEY cannot be directly updated along with the change of the authoritative server of a domain name, uses trusted DS records to verify DNSKEY, thereby verifying the authenticity of the change of the authoritative server of the domain name, and accurately identifying the abnormal change of the authoritative server. A DNSKEY smooth change-based authoritative server abnormal change detection system is constructed, can perform timed detection on the domain name, accurately identifies the abnormal change of the authoritative server of the domain name, and avoids the adverse effects of the domain name on internet users after the domain name is maliciously tampered with.

Description

Technical Field

[0001] The present 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] The current DNS system faces the risk of power centralization. The power imbalance between upper-level and lower-level domains allows upper-level domains to maliciously tamper with the authorization information of lower-level domains, causing service unavailability for lower-level domains. For example, during DNS resolution for "www.baidu.com," a DNS server queries the root server, the ".com" authoritative server, and the "baidu.com" authoritative server, ultimately obtaining the resolution result for "www.baidu.com." During this 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, for example, that ".com" intends to attack "baidu.com." They could replace the "baidu.com" authoritative server information with forged information on the ".com" authoritative server, pointing it to a malicious server. Internet users searching for "www.baidu.com" would then receive a malicious resolution result. This could have serious consequences, such as the possibility of leaking user information.

[0003] Existing technologies have proposed a root zone change model for analyzing abnormal top-level domain (TLD) changes. This model is primarily based on rules for TLD disappearance, TLD authoritative server name changes, and TLD authoritative server IP address changes. By observing TLD information in the current root zone version and historically accumulated TLD information, the authenticity of TLD changes is determined based on these three rules. However, this method cannot perfectly distinguish between normal and abnormal TLD changes and has limited applicability. Summary of the Invention

[0004] The present invention aims to solve the problem that the existing technology 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 in authoritative servers based on smooth changes in DNSKEYs includes the following steps:

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

[0007] Step 2: Extract the current detection task and query the DS record of the upper-level authoritative server of the domain name to be detected;

[0008] Step three, query the DS record of the original server or domain name owner of the domain name as the original trust anchor;

[0009] Step four, compare the DS record in step two with the original trust anchor in step three, if they are the same, there are two cases;

[0010] If the authoritative server information changes, step five is performed;

[0011] If the authoritative server information does not change, skip the detection and end the task;

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

[0013] If the authoritative server information does not change, step six is performed;

[0014] If the authoritative server information changes, step seven is performed;

[0015] Step five, use the trust anchor 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 key signing key ZSK to verify the resource record signature record RRSIG, if all keys are successfully signed, the verification is successful, and the detection is ended; if any step fails, step seven is performed;

[0016] Step six, 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 fails, step seven is performed;

[0017] Step seven, alarm for the domain name with abnormal change of the authoritative server.

[0018] An authoritative server abnormal change detection system based on DNSKEY smooth change, comprising a monitoring domain name list 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 comprises a task queue unit, a task starter unit, a detection unit, a trust anchor update verification unit, and an authoritative server authenticity verification unit;

[0020] The monitoring domain name list configuration module is used for transmitting the information of the new domain name to be monitored, and reading the domain name into the trust anchor database after transmission;

[0021] The authoritative server abnormal change detection module is used for monitoring the change of the authoritative server of each domain name and verifying the authenticity of the change of the authoritative server, and if the change is authentic, the data is transmitted to the trust anchor database, and if the change is not authentic, the data is transmitted to the abnormal alarm module.

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

[0023] The task queue unit is used for storing timing tasks and starting the detection of the authoritative server of the domain name at a timing time, and is connected with the task initiator unit.

[0024] The task initiator unit is used for extracting the detection task at the current time in the task queue and transmitting the detection task to the detection unit.

[0025] The detection unit is used for completing the detection task, first reading the trust anchor of the domain name to be detected from the trust anchor database, and then comparing the trust anchor with the DS record of the domain name.

[0026] The trust anchor update verification unit is used for verifying the authenticity of the new DS record, verifying the key signing key KSK of the domain name by using the new DS record, verifying the zone signing key ZSK by using the key signing key KSK, and finally verifying the resource record signature record RRSIG by using the zone signing key ZSK, and if all the verifications are successful, updating the trust anchor information in the trust anchor database; if any step of the verification fails, transmitting data to the abnormal alarm module.

[0027] The authoritative server authenticity verification unit is used for verifying the authenticity of the new authoritative server, verifying the key signing key KSK of the domain name by using the trust anchor, verifying the zone signing key ZSK by using the key signing key KSK, and finally verifying the resource record signature record RRSIG by using the key signing key ZSK, and if all the verifications are successful, ending the detection, and if any step of the verification fails, transmitting data to the abnormal alarm module.

[0028] The trust anchor database is used for maintaining the original trust anchor information of each domain name, reading the information from the trust anchor database when the detection unit detects, and transmitting the information to the trust anchor database when the trust anchor update verification unit updates the trust anchor.

[0029] The abnormal alarm module alarms the domain name with the abnormal change of the authoritative server.

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

[0031] If the two are the same, the DS record of the domain name has not changed, which includes two cases:

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

[0033] If the authoritative server information does not change, skip the detection, and end the task;

[0034] If the two are different, the DS record of the domain name has changed, and is divided into two cases:

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

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

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

[0038] The present application is based on the rule that DNSKEY will not be directly updated with the change of the authoritative server of the domain name, uses the trusted DS record to verify DNSKEY, thereby verifying the authenticity of the change of the authoritative server of the domain name, and accurately identifying the abnormal change of the authoritative server. The abnormal change detection system of the authoritative server based on DNSKEY smooth change is constructed, can detect the domain name regularly, accurately identify the abnormal change of the authoritative server of the domain name, and avoid the adverse effects on the Internet users after the domain name is maliciously tampered with. BRIEF DESCRIPTION OF DRAWINGS

[0039] Figure 1 It is an abnormal change detection diagram of the authoritative server based on DNSKEY smooth change;

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

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

[0042] Figure 4 It is the case of simulating the root server attack "cn" top-level domain to update the DS record;

[0043] Figure 5 It is the case of simulating the root server attack "cn" top-level domain to not update the DS record. DETAILED DESCRIPTION Detailed implementation one:

[0045] The present embodiment is an abnormal change detection method of the authoritative server based on DNSKEY smooth change, the DNSKEY smooth change refers to that DNSKEY will not be directly updated with the change of the authoritative server of the domain name, that is, the KSK and the authoritative server will not be changed at the same time, and the method comprises the following steps:

[0046] Step one, timing to open the detection task of the authoritative server of domain name;

[0047] Step two, extract the detection task of the current time, query the DS record to the superior authoritative server of the domain name to be detected. There are two DNSKEYs in DNSSEC, which are key signing key KSK and zone signing key ZSK. KSK is used to sign ZSK, and the hash value of KSK is saved in its parent domain, that is, DS record, so that the public key of KSK can be verified using the DS record.

[0048] Step three, query the DS record to the original server or domain name owner of the domain name as the original trust anchor, because the rule based on this scheme is that DNSKEY will not be directly updated with the change of the authoritative server of domain name, that is, KSK and authoritative server will not be changed at the same time, so the authenticity of the authoritative server can be verified through the original trust anchor.

[0049] Step four, compare the DS record in step two with the original trust anchor in step three,

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

[0051] If the authoritative server information changes, step five is executed;

[0052] If the authoritative server information does not change, skip the detection and end the task.

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

[0054] If the authoritative server information does not change, step six is executed;

[0055] If the authoritative server information changes, step seven is executed.

[0056] Step five, use the trust anchor to verify the key signing key KSK of the domain name. If the verification is successful, it can be ensured 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 be ensured 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 the active change of the domain name owner. If any step fails, step seven is executed.

[0057] Step six, using the new DS record to verify the key signature key KSK, and then use the key signature key KSK to verify the region signature key ZSK, and finally use the region signature key ZSK to verify the resource record signature record RRSIG, if all the keys are successfully signed, the verification is successful, and the trust anchor information is updated. If any step fails, step seven is performed.

[0058] Step seven, alarm for the domain name of the authoritative server abnormal change. Specific implementation two:

[0060] The embodiment is an authoritative server abnormal change detection system based on DNSKEY smooth change, comprising: a monitoring domain name list configuration module, an authoritative server abnormal change detection module, a trust anchor database, and an abnormal alarm module.

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

[0062] The monitoring domain name list configuration module is used to transmit the information of the new domain name to be monitored, and after reading, the domain name is transmitted to the trust anchor database;

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

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

[0065] The task queue unit is used to store the timing task, and the timing task is started to detect the authoritative server of the domain name, and is connected with the task starter unit.

[0066] The timing task needs to set a time interval, first acquires the TTL value of the current authoritative information of the domain name, then sets a minimum interval minTTL and a maximum interval maxTTL, and then takes min{max{TTL, minTTL}, maxTTL} as the measurement interval.

[0067] The task starter unit is used to extract the detection task of the current time in the task queue and transmit it to the detection unit.

[0068] The detection unit is used to complete the detection task, first reads the trust anchor of the domain name to be detected from the trust anchor database, and then compares with the DS record of the authoritative server of the domain name;

[0069] If they are the same, it means that the DS record of the domain name has not changed, and there are two cases:

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

[0071] If the authoritative server information does not change, skip the detection and end the task.

[0072] The difference between the two indicates that the DS record of the domain name has changed, which is divided into two cases:

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

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

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

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

[0077] The trust anchor database is used to maintain the original trust anchor information of each domain name, and reads the information from the trust anchor database when the detection unit detects, and transmits the information to the trust anchor database when the trust anchor update verification unit works. The original trust anchor database obtains the original trust anchor in the following way: query the DS record from the original server of the domain name or the owner of the domain name.

[0078] The abnormal alarm module alarms the domain name with abnormal changes in the authoritative server.

[0079] Embodiment:

[0080] This embodiment simulates the malicious tampering of the DNS root server to the ".cn" server, and verifies the effectiveness of the system. The experimental steps are as follows:

[0081] Place the experimental environment in the initial state, such as Figure 3As shown, the root server adds the information of the real ".cn" authoritative server, the real ".cn" authoritative server adds the information of the real "gov.cn" authoritative server, the real "gov.cn" authoritative server adds the real IPv4 address record of "www.gov.cn" in the zone file, and the DNSKEY information of each level is configured;

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

[0083] The root server attacks the ".cn" top-level domain, tampers with the authoritative server information of ".cn", points the ".cn" authoritative information in the root zone to the fake ".cn" authoritative server, further points "gov.cn" in the zone file of the fake ".cn" authoritative server to the fake "gov.cn" authoritative server, and finally realizes the fake IPv4 address record of "www.gov.cn".

[0084] There are two cases of DNSSEC update, one is Figure 4 As shown, the DS record of ".cn" in the root zone is directly updated, the KSK and ZSK of the fake ".cn" are regenerated. The second is Figure 5 As shown, the DS record of ".cn" in the root zone remains unchanged, and the DNSSEC verification cannot pass.

[0085] The above two cases are to verify whether the two-stage judgment in the abnormal detection system based on DNSKEY smooth change can correctly identify, one is whether the trust anchor changes, and the second is whether the trust anchor can successfully verify the information of the new authoritative server combined with the current KSK and ZSK information.

[0086] Observe the result of the authoritative server abnormal change detection system based on DNSKEY smooth change, and verify whether it can identify the abnormal change of the ".cn" top-level domain.

[0087] The abnormal alarm module sends the alarm information of ".cn" being maliciously tampered with, and the system can successfully detect the abnormal change of the authoritative server.

Claims

1. A method for detecting abnormal changes in authoritative servers based on smooth changes in DNSKEY, characterized in that: The method comprises the following steps: Step 1: Start the detection task of the authoritative server of the domain name regularly; Step 2: Extract the current detection task and query the DS record of the upper-level authoritative server of the domain name to be detected; Step 3: Query the origin 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 they are the same, there are two cases: If the authoritative server information changes, proceed to step 5; If the authoritative server information remains unchanged, skip the check 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, proceed to 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 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. Step 7: Issue an alert for domain names with abnormal changes in the authoritative server.

2. A system for detecting abnormal changes in authoritative servers based on smooth changes in DNSKEY, characterized in that: Including monitoring domain name list configuration module, authoritative server abnormal change detection module, trust anchor database, 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 newly added domain names to be monitored, and after reading, the domain names are transferred to the trust anchor database; Authoritative server abnormal change detection module: used to monitor changes in the authoritative server 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, regularly start the detection of the authoritative server of the domain name, 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 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 verifications are successful, the trust anchor information in the trust anchor database is updated; if any verification step 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, 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 verification step 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: issues an alarm for domain names with abnormal changes in authoritative servers.

3. The authoritative server abnormal change detection system based on DNSKEY smooth change according to claim 2 is characterized in that: 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.

4. The authoritative server abnormal change detection system based on DNSKEY smooth change according to claim 2 is characterized in that: The detection unit compares the trust anchor with the DS record of the domain name in the following situations: 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 check 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