> Тут задача из разряда "кто даст правильный ответ - тот получит 10 лет".

ага, "кто купит билетов пачку" ... XD

Обратим внимание на данное утверждение:

"""
что главной причиной сбоя стало несовершенство программного обеспечения, используемого при создании ключей шифрования.
"""

Вопрос, какого ПО? Сделаю предположение - самописного, своего рода "панель управления", в которой можно сгенерить ключ для зоны и подписать записи. Отсюда:

"""
Как и любое другое технологическое решение, DNSSEC требует усовершенствования с течением времени, чтобы исправить обнаруживаемые ошибки работы.
"""

Вопрос, так DNSSEC требует усовершенствование или ваше "самопальное" ПО?

"""
Возникшая коллизия ключей
"""

Предполагаем возникновение коллизии созданного ключа. Как вы заметили, коллизия с хешем может быть от ключа, но с каким другим ключом? При генерации нового ключа (ZSK) существует ОДИН текущий актуальный активный ключ. Вероятно их ПО при запросе на переподписывании выбирало ключ из (где они там хранят ключи - не знаю) "базы" по хешу ключа, и напоролась на актуальный активный текущий ключ, взяла его и переподписала зону. Если коллизия произошла именно с этим ключем, то в чем проблема? Разве подпись ресурсных записей должна была быть невалидной? Ключ ведь актуальный активный никто ведь не удалял. Может key_tag неверный был у ресурсных записей? - НЕТ. Судя по dnsviz второй ключ был добавлен еще числа 26-го.

256 3 8 AwEAAbjj3GP0TUwaNI7BIIw/fvwKTmdR +oZsEPk64pl8VYn4dfdbGHWpYIooxcgEbuBEYrnC/oqnKhad38nTxrZ9SAK3qV5qShntFdgozS5IKs5m1ebNmg2sotlhXRhJ4vqgH+BQh/lw6T4vdB8FE5tHGE1vwPs9Vhj0vLTBhX8TwB6/ ; key tag = 52263

256 3 8 AwEAAcBtr/w2hP6OQjiCacPFzK6xh0pR 7QsHV9lxprIXG9WBoBB5XWPVc5q17F3yt3wpJ7xmedt80gxVMaicPYNYAa8YUFyMxTGVBDVQlz5gCmXQKlr0yImI78sdwzWNmgKHap0BLypTBVxAKxpcvuwTmqXQUSONkjq9werHvogrvkUb ; key tag = 44301

key tag - по сути должен храниться вместе с ключевой парой, и ситуация с коллизией описанной выше, по идее должна была выставить в качестве key tag в RRSIG не новый key tag = 52263, а "старый" текущий актуальный key tag = 44301.

НО - судя по dnsviz

NS 8 1 345600 20240305102631 20240130141847 52263 ru. kw9oqgvi/l0MZp/6FY0Ha+VZDWRR3+iDUCYqAY5W7D2wCfIXXdOOvdd58nNY7z/3b4fRK6tlTF3wQpCDSpeKrmkWmric4kcUptaj1rp71lC0GHXHmGwDsx8Zi/lvo6sJEk0guBbJYBJkzKqeseD4u1Pw29jkRHhQEJKk2seP+Zk=

у битой сигнатуры был выставлен key tag = 52263 - нового ключа, так почему же она оказалась битой?

Представим примитивное хранение ключевых пар

key_tag, pub_key, priv_key, hash

  44301, pub_cur, priv_cur, hash_cur
  52263, pub_new, priv_new, hash_new

Ну вот тут если hash_cur==hash_new и сделать выборку по hash, то какая разница какой из ключей выбрался бы, результат был бы - валидная сигнатура, ибо ситуация возьми priv_cur (текущий приватный ключ) и выстави key tag от ключа priv_new - ИСКЛЮЧАЕТСЯ!!!.

Так в чем же причина битой сигнатуры? А теперь допустим куда реалистичную ситуацию. Опять представим примитивное хранение ключевых пар:

key_tag, pub_key, priv_key, hash

  44301, pub_cur, priv_cur, hash_cur
  52263, pub_new, priv_new, hash_new
  12345, pub_old, priv_old, hash_old
  22222, pub_001, priv_001, hash_001
  33333, pub_002, priv_002, hash_002
  52263, pub_123, priv_123, hash_123

Допускаем, что они не удаляли старые ключевые пары, и среди ключей коллизия должна была быть не только по hash, но и одновременно по key_tag, так как key_tag в битых сигнатурах был от якобы нового опубликованного ключа. Но коллизия по hash двух 1024 битовых rsa ключевых пар мне кажется мало вероятной, склоняюсь к тому, что коллизия могла произойти по key_tag.

Вывод: Читаем внимательно https://datatracker.ietf.org/doc/html/rfc4034#appendix-B
  
key_tag не обязан быть уникальным, отсюда вся беда с коллизией в том, что НАКОЙ ХРАНИТЬ СТАРЫЕ КЛЮЧИ?