On January 30 at 18:20 (MSK), users experienced a massive failure in host resolution within the RU domain zone, caused by an error in changing the keys used to authenticate the RU zone via DNSSEC. As a result of the incident, all domains in the '.ru' zone ceased to be resolved on DNS servers that use DNSSEC for data validation. The issue only affected users utilizing DNS resolvers from providers or public DNS services like 8.8.8.8, which validate requests using DNSSEC. Users of DNS resolvers with DNSSEC disabled were unaffected.
The incident recalls last year's event with the registrar InternetNZ, responsible for the '.NZ' domain zone, which led to resolution failures domain names in the '.nz' zone due to an error in the rotation of KSK keys (Key Signing Key) used for the digital signing of DNSKEY records containing keys for signing the domain zone (ZSK, Zone Signing Key). In the case of InternetNZ, the error was related to a change in the key format during the transition to a new registrar information system. The causes of the incident in the RU zone have not yet been detailed — The Coordination Center for RU domains has only generally confirmed that the issue is linked to DNSSEC reconfiguration.
Judging by the 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 the other keys used in second-level domains, and, in turn, it uses the key of the '.' domain as a superior for confirming its trust. On January 26, in the DNSSEC settings for the RU zone, in addition to the main key with ID 44301, an additional key with ID 52263 appeared.
Yesterday around 18:20, the new key was activated for validating records in the RU zone, but after the transition to the new key, authentication checks failed due to an error.
The signature with the old key was returned around 9 PM (MSK), while the first valid response was recorded by the dnsviz.net service at 10:07 PM (MSK). The faulty settings were present for about two and a half hours, but due to the lingering erroneous records in the caches of DNS servers, additional time is required for full recovery unless the cache on the recursive DNS servers is forcibly cleared. Some providers resolved the issue more quickly and drastically by temporarily disabling DNSSEC verification in their resolver settings.
Source: opennet.ru
