On January 30 at 18:20 (MSK), users experienced a massive failure of host detection in the RU domain zone, caused by an error when changing the keys used to verify the validity of the RU zone via DNSSEC. As a result of the incident, all domains in the “.ru” zone were no longer detected on DNS servers that use DNSSEC to verify data authenticity. The problem only affected users using ISP DNS resolvers or public DNS services such as 8.8.8.8, which verify the validity of queries using DNSSEC. Users of DNS resolvers with DNSSEC disabled were not affected.
The incident is reminiscent of last year's incident with InternetNZ, the registrar responsible for the .NZ domain zone, which led to a resolution failure. domain names In the ".nz" zone, the incident occurred due to an error in the rotation of KSK (Key Signing Key) keys used to digitally sign DNSKEY records containing the Zone Signing Key (ZSK). In the case of InternetNZ, the error was related to a change in the key format during the transition to the registrar's new information system. The cause of the incident in the .RU zone has not yet been detailed—the .RU Domain Coordination Center has only generally confirmed that the issue is related to DNSSEC reconfiguration.
Judging by external manifestations, the failure occurred as a result of an attempt to replace the key used to verify the RU zone. This key is the root of trust for other keys used in second-level domains, and, in turn, uses the domain key “.” as a superior to confirm his trust. On January 26, in the DNSEC settings of the RU zone, in addition to the main key with identifier 44301, an additional key 52263 appeared.
Yesterday at approximately 18:20, the new key was used to verify records in the RU zone, but after switching to the new key, due to an error, authentication stopped happening.
The signature with the old key was returned around 21:22 (MSK), and the first correct response was recorded by the dnsviz.net service at 07:XNUMX (MSK). The faulty settings were present for approximately two and a half hours, but due to the accumulation of erroneous records in the caches of DNS servers, additional time is required for a complete recovery unless the cache on the recursive DNS servers is forcibly cleared. Some providers solved the problem more quickly and radically by temporarily disabling verification via DNSSEC in the settings of their resolvers.
Source: opennet.ru
