СИСТЕМНЫЙ ПАРАЛИЧ: ДВОЙНОЙ ДЕФОЛТ DNSSEC ИЛИ КАК INOVENTICA (INVS.RU) ХОРОНИТ ДОВЕРИЕ К РОССИЙСКОМУ IAAS

В системном администрировании есть жесткое правило: инцидент, повторившийся дважды по одной и той же причине — это не случайность. Это архитектурный диагноз. Ровно два месяца назад, в январе 2026 года, я опубликовал подробный разбор «Смерть по неосторожности», где на базе логов задокументировал 48-часовой коллапс инфраструктуры Inoventica (invs.ru). Тогда провайдер полностью выпал из глобальной сети из-за просроченной подписи DNSSEC (EDE: 7 Signature Expired).

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

Сегодня, 26 марта 2026 года, мы фиксируем рецидив. invs.ru снова превратился в «цифрового призрака» для всех строго валидирующих резолверов. Только на этот раз ошибка свидетельствует о еще более глубокой деградации процессов.

Глава 1. RAW-данные: От просрочки к потере ключей

Перейдем к фактам. Проблема DNSSEC всегда диагностируется за пару минут при наличии базового понимания криптографии. Проверяем состояние родительской зоны:

root@phoenix901:~# dig DS invs.ru +short
5945 8 2 D9AD8A490386FCF163FFDC90E54533CCEBB8C134292320607570BA1A DD8BC008

Вывод подтверждает: зона .ru содержит делегированную DS-запись (Digital Signer) с тегом ключа 5945. Этот «замок» сообщает всем мировым DNS-серверам: любые ответы от домена invs.ru должны быть подписаны ключом, математический хэш которого совпадает с этой записью. Если совпадения нет — ответ считается поддельным и отбрасывается.

Теперь запрашиваем саму зону через публичный валидирующий резолвер Google (8.8.8.8), требуя проверку DNSSEC:

root@phoenix901:~# dig SOA invs.ru @8.8.8.8 +dnssec
...
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 18431
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
...
; EDE: 9 (DNSKEY Missing): (No DNSKEY matches DS RRs of invs.ru)

Мы получаем статус SERVFAIL и расширенный код ошибки EDE: 9 (DNSKEY Missing). Это классический DS Mismatch. Если в январе они просто забыли обновить время жизни подписи (RRSIG), то сейчас ситуация хуже: родительская зона ссылается на ключ 5945, а авторитативные серверы Inoventica либо отдают совершенно другой набор ключей (DNSKEY), либо вообще перестали их отдавать, сломав конфигурацию демона.

Цепочка доверия разорвана на физическом уровне. Для протокола это означает, что зона скомпрометирована.

Глава 2. Индустриальный сюрреализм и маркетинг на руинах

Самый циничный аспект этого рецидива вскрывается при анализе маркетинговой активности провайдера. Пока их DNS-инфраструктура бьется в конвульсиях, на главной странице продаются услуги категории Enterprise.

В новостном блоке от конца декабря 2025 года они анонсируют повышение цен с 1 января, оправдывая это «ростом НДС до 22% и мировым дефицитом оперативной памяти и дисков на рынке электроники из-за роста спроса на ИИ». Они готовы закладывать в тарифы глобальный дефицит кремния, но экономят на квалификации персонала, способного написать bash-скрипт для мониторинга статуса ключей KSK (Key Signing Key) и ZSK (Zone Signing Key).

Они публикуют отзывы от технологических компаний, благодарящих за «безопасность персональных данных» и «защиту по 152-ФЗ». Но как можно всерьез обсуждать защиту ИСПДн (информационных систем персональных данных) на базе инфраструктуры, которая регулярно отстреливает себе ногу на уровне L7-протоколов из-за ручного управления криптографией?

Глава 3. Цепная реакция: Вы заложники, а не клиенты

Падение корпоративного домена хостера — это не просто недоступность лендинга. Это каскадный отказ. Вместе с invs.ru в небытие отправляются их NS-серверы, биллинг, тикет-система и панели управления выделенными серверами (IPMI/KVM), завязанные на этот домен.

Если ваши собственные домены делегированы на NS-серверы Inoventica — в момент их дефолта по DNSSEC ложится и ваш бизнес. Вы физически отрезаны от управления своими ресурсами. Техподдержка, которая должна спасать ситуацию, в таких случаях традиционно прячется за отписками про «блокировки РКН» или «проблемы маршрутизации у Google».

Глава 4. Стратегия автономности: Как не стать жертвой

Два фатальных сбоя за квартал — это приговор процессам эксплуатации внутри компании. Для системных инженеров и владельцев бизнеса вывод должен быть однозначным:

1. Децентрализация управления: Никогда не делегируйте боевые домены на NS-серверы хостинг-провайдера, предоставляющего вам вычислительные мощности. Используйте независимые Anycast-сети (Selectel, Cloudflare) или разворачивайте собственные кластеры PowerDNS/Bind.
2. Внешний мониторинг: Доверять нельзя никому. Мониторинг валидности DNSSEC и сроков RRSIG должен быть внедрен в ваш Zabbix или Prometheus. Вы должны получать алерты о деградации зоны до того, как кэши мировых резолверов обновятся.
3. Резервные каналы: Всегда храните прямые IP-адреса критически важных узлов (панели управления, шлюзы) в локальных hosts файлах изолированных машин администрирования.

Инфраструктура не прощает дилетантов. Если ваш провайдер второй раз за сезон выпадает из сети из-за неспособности совладать с базовой криптографией — вам пора менять не DNS-записи. Вам пора менять провайдера.