В мире системного администрирования 2026 года существует негласное правило: если сервис не доступен, сначала проверь DNS, потом — всё остальное. Но что делать, когда «не доступен» сам провайдер? Когда исчезает не просто ваш сайт, а вся экосистема хостера: от главной страницы до панели управления выделенными серверами и биллинга? Инцидент с Inoventica (invs.ru), начавшийся 12 января 2026 года, стал для меня точкой невозврата в оценке российских облачных сервисов. Это история о том, как просроченная цифровая подпись превратила крупного игрока рынка в «цифрового призрака» на 48 часов, и почему профессиональная деградация техподдержки опаснее любых DDoS-атак.
Глава 1. Хроника «черного воскресенья»: 48 часов в вакууме
Первые признаки катастрофы я зафиксировал 12 января. Это было воскресенье — день, когда любой админ рассчитывает на тишину в мониторинге. Но тишина оказалась абсолютной. Попытка зайти в панель управления дедиками закончилась ошибкой резолва. Попытка открыть основной сайт invs.ru — тот же результат. Биллинг? Мертв.
Важно понимать масштаб проблемы: когда у хостера падает DNS, вы становитесь заложником. Вы не можете перегрузить сервер через IPMI (если он завязан на домен), вы не можете проверить баланс, вы не можете даже написать тикет, потому что тикетница живет за тем же доменным именем, которое только что аннигилировалось. Двое суток я наблюдал за тем, как инфраструктура провайдера медленно исчезает из кэшей мировых резолверов. Только 14 января, когда ситуация стала критической, я пробился в поддержку, используя «костыли» и прямые IP-адреса.
Глава 2. Техническая база: Что такое DNSSEC и почему он убивает
Чтобы понять глубину факапа, нужно обратиться к RFC 4033, 4034 и 4035. DNSSEC (DNS Security Extensions) — это надстройка над классическим DNS, призванная защитить нас от подмены ответов. Она работает по принципу цепочки доверия: каждая запись подписывается ключом зоны (ZSK), а тот, в свою очередь, ключом ключей (KSK).
Но у этой защиты есть ахиллесова пята — время. Каждая подпись RRSIG имеет жесткий срок действия. В этом и заключается суть инцидента. Провайдер внедрил технологию защиты, но забыл внедрить культуру эксплуатации. DNSSEC без автоматического переподписывания зон — это не безопасность, это механизм самоуничтожения. Если вы не обновили подписи, ваш домен становится «токсичным». Любой современный резолвер (Google, Cloudflare) видит просроченную подпись и, следуя букве протокола, выдает SERVFAIL. Для интернета вы больше не существуете.
Глава 3. Первый контакт: Стена из скриптов
14 января я наконец-то достучался до поддержки. Диалог, который последовал далее, заслуживает места в музее некомпетентности.
Игорь (12:57): «А что у вас с dns? Ваши домены не доступны из под cf и google»
Андрей Л. (13:07): «Скорее всего это блокировки со стороны google или РКН блокирует доступ к google, проблема не с нашей стороны. Используйте Яндекс днс.»
Вдумайтесь в серьезность этого заявления. Сотрудник провайдера обвиняет Google и РКН в том, что его собственные домены не резолвятся. Это классическая попытка переложить ответственность на «внешний фактор», который сейчас модно использовать как универсальную затычку для любых дыр в администрировании. Но логи говорят об обратном.
Глава 4. Лабораторная диагностика: Разбор улик
Когда поддержка начала кормить меня сказками про РКН, я провел независимый аудит из нескольких географических точек, включая Латвию (узел 568). Результат везде был идентичен: Temporary failure in name resolution.
Улика №1: Прямой допрос NS-серверов
Я решил миновать посредников и спросить авторитативные серверы Inoventica напрямую:
root@stream:~# dig bill.invs.ru @ns01.invs.group ;; communications error to 195.128.124.68#53: timed out
Это первый системный провал. Один из двух «столбов» DNS (NS01) просто не отвечал. Резервирование? Нет, не слышали. Вся зона держалась на честном слове второго сервера.
Улика №2: Приговор Google DNS
Запрос к Google DNS с расширенными кодами ошибок (EDE) поставил точку в споре:
root@stream:~# dig +dnssec bill.invs.ru @8.8.8.8 ... ;; EDE: 7 (Signature Expired): (Expired RRSIG found for bill.invs.ru/a (keytag=12885))
Код 7 (Signature Expired). Подпись истекла. Тэг ключа 12885. Дата истечения: 12 января 2026 года. Google не блокировал Inoventica — Google защищал меня от провайдера, который не может уследить за своими ключами.
Глава 5. Сетевой шторм: Джиттер как симптом
Проблема не ограничилась только DNS. Анализ сетевого уровня (L3) выявил нестабильность маршрутизации внутри самой сети хостера. Пинги до биллинга (195.128.126.13) прыгали от 0.4 мс до 102 мс. Для внутреннего сегмента ДЦ это катастрофа. Такой джиттер обычно свидетельствует о перегрузке CPU на маршрутизаторах или о том, что сеть «штормит» из-за некорректно настроенных таблиц маршрутизации, которые пытаются найти путь к упавшим DNS-серверам.
Глава 6. Игнорирование как корпоративная стратегия
Самый болезненный этап — это тишина, последовавшая за моими доказательствами. Как только в тикет упали логи dig +trace, показывающие просрочку подписи на двое суток, поддержка «ушла в закат». С 14:24 и до ночи — ни одного внятного комментария.
Это и есть «индустриальный пофигизм». Когда вы ловите профессионала на детской ошибке, он либо извиняется и чинит, либо делает вид, что вас не существует. В случае с Inoventica мы увидели второй вариант. Мы готовы простить ошибку, но мы не можем простить игнорирование фактов, которые напрямую влияют на безопасность наших данных.
Глава 7. Почему мы готовы помочь, но нас не слышат
Я неоднократно предлагал помощь в диагностике. В сообществе админов принято помогать друг другу, даже если один из них — клиент, а другой — провайдер. Мы все в одной лодке. Настройка мониторинга DNSSEC — это не ракетостроение. Это пара скриптов на Python или просто грамотно настроенный Zabbix, который проверит поле RRSIG и пришлет алерт за 5 дней до катастрофы.
Если провайдеру не хватает квалификации — мы готовы подсказать. Но для этого нужна открытость. Пока нам твердят про «блокировки Google», мы видим только стену непрофессионализма.
Глава 8. Анатомия «Гнилого звена»
Этот инцидент заставляет пересмотреть всю стратегию размещения. Мы выбираем хостинг по железу, по аптайму каналов, по цене. Но мы забываем про уровень управления (L7). Если админы хостера не умеют готовить DNSSEC — ваше «честное железо» превращается в бесполезный груз. В 2026 году DNS — это фундамент. Если фундамент гнилой, дом рухнет, даже если он построен из лучшего бетона.
Глава 9. Как выжить, когда ваш провайдер ослеп?
Мой опыт этих трех суток вылился в четкий алгоритм для тех, кто может оказаться в подобной ситуации:
- Hosts-файлы: Всегда держите список критических IP ваших серверов и биллинга хостера. В случае падения DNS это единственный способ пробиться в панель управления.
- Независимый DNS: Никогда не делегируйте свои боевые домены на NS-серверы хостера. Используйте Selectel, Cloudflare или собственные узлы в разных ДЦ.
- Внешний мониторинг: Настройте проверку валидности DNSSEC через внешние API. Вы должны узнать о проблеме раньше, чем ваша зона исчезнет из Google.
Глава 10. Будущее автономности
Инцидент с invs.ru подтвердил правильность моего пути к полной автономности. Мы уходим от «сервисов как услуги» в сторону «железа как ресурса». Мы забираем управление DNS, почтой и маршрутизацией на себя. Только так можно гарантировать, что ваш проект не умрет из-за того, что кто-то на другом конце провода забыл нажать кнопку sign.
Заключение: Приговор и надежда
Лонгрид «Смерть по неосторожности» — это не попытка похоронить бренд. Это попытка вскрыть нарыв. Я зафиксировал инцидент еще 12 января, но только 14 января, после жесткого технического допроса, проблема была признана косвенно.
Инфраструктура должна быть прозрачной. Логи должны быть истиной. А поддержка должна быть инженерной, а не скриптовой. Мы продолжаем работу, но наши бэкапы теперь летят еще дальше от Ревяк. Потому что безопасность — это не технологии. Безопасность — это внимание к деталям.