Поводом для этой статьи стал майский инцидент с доменной зоной .de. 12 июня 2026 года DENIC опубликовала итоговый отчет, 8 мая появился первичный технический разбор, а Cloudflare отдельно описала, что видели валидирующие резолверы во время сбоя. Для владельца сайта это полезный сигнал: сервер может быть жив, приложение может отвечать, а пользователи все равно будут видеть недоступность, если ломается цепочка доверия DNSSEC.
Если говорить простыми словами, DNSSEC нужен для того, чтобы DNS-ответам можно было доверять. Но у этой защиты есть обратная сторона: если подпись или связка ключей настроены неверно, часть резолверов перестает отдавать корректный ответ. Внешне это часто выглядит как «сайт упал», хотя проблема может быть не в коде, не в CMS и даже не в хостинге.
Если сайт важен для заявок, оплаты или личного кабинета, сначала отделите DNS-проблему от сбоя приложения. Ниже есть быстрый чек-лист, а для внешней HTTP-проверки можно использовать форму Web-Puls в конце страницы.
Что такое DNSSEC простыми словами
Обычный DNS отвечает на вопрос, куда вести пользователя по доменному имени. DNSSEC добавляет к этим ответам криптографическую подпись. Резолвер проверяет, что ответ не подменен и действительно относится к нужной зоне.
Пока все настроено правильно, владелец сайта ничего не замечает. Но если после смены DNS-провайдера, регистратора, CDN или ключей в зоне появляется несоответствие, проверяющий резолвер начинает считать ответ недостоверным. Тогда вместо открытия сайта пользователь может получить ошибку разрешения имени, SERVFAIL или бесконечную загрузку.
Важно понимать: DNSSEC сам по себе не "ломает" сайт. Он строго блокирует ответы, которые не проходят проверку. Поэтому сбой часто связан не с атакой, а с ошибкой в настройке или в процессе обновления ключей.
Почему ошибка DNSSEC выглядит как «сайт упал»
Для бизнеса это один из самых неудобных сценариев. В панели хостинга сервер может быть зеленым. Nginx или Apache отвечают. Приложение работает. Мониторинг по прямому IP тоже может проходить. Но клиент открывает домен и видит, что сайт недоступен.
Типичный пример
Интернет-магазин переносит DNS-обслуживание к новому провайдеру. Записи A и AAAA переехали корректно, но DS-запись у регистратора осталась от старого ключа. В результате часть резолверов считает ответы недействительными. Внутри офиса сайт у кого-то еще открывается из кэша, а новые посетители уже получают сбой.
Из-за этого команда часто тратит время не туда:
- проверяет CMS и плагины;
- перезапускает PHP и базу данных;
- ищет DDoS;
- откатывает последний релиз, хотя релиз ни при чем.
Как понять, что проблема именно в DNSSEC, а не в хостинге
Ниже признаки, которые полезно проверить до того, как вы начнете хаотично менять записи.
1. Сайт по домену не открывается, а по IP отвечает
Такое бывает не всегда, но это сильный сигнал, что проблема выше уровня веб-сервера. Если по прямому IP вы видите страницу, а по доменному имени нет, сначала проверьте DNS-цепочку.
2. У разных пользователей разная картина
Один клиент пишет, что сайт не открывается вообще. У вас в офисе он работает. На мобильном интернете ситуация отличается от домашнего провайдера. Такое расхождение часто говорит о разных резолверах и кэше, а не о стабильной работе сайта.
3. Появляется SERVFAIL
Если есть доступ к терминалу, полезно выполнить:
- dig example.com
- dig +dnssec example.com
- dig @1.1.1.1 example.com
- dig @8.8.8.8 example.com
Если авторитативные серверы отвечают, но публичные резолверы возвращают SERVFAIL или не могут подтвердить подпись, версия с DNSSEC становится очень вероятной.
4. Проблема началась после изменений у DNS-провайдера или регистратора
Хороший вопрос для команды: что меняли в последние часы или сутки? Переезд DNS, включение DNSSEC, ротация ключей, перевод домена, подключение CDN, изменение NS или DS-записей часто оказываются ближе к причине, чем код сайта.
Что делать владельцу сайта пошагово
Первое правило: не удаляйте записи наугад и не пытайтесь "перекликать" все настройки подряд. При DNSSEC хаотичные действия часто только удлиняют простой.
- Зафиксируйте симптомы. Откуда именно сайт не открывается, какой домен затронут, есть ли ошибка SERVFAIL, работает ли почта и открываются ли поддомены.
- Проверьте, были ли недавние изменения в DNS. Нужны не общие слова, а конкретика: кто менял NS, кто включал DNSSEC, кто трогал DS-запись у регистратора.
- Сравните данные у регистратора и в зоне. Если DS у родительской зоны указывает на старый ключ, валидаторы будут отклонять ответы.
- Проверьте домен через несколько внешних резолверов и из разных сетей. Так вы быстрее поймете, это локальный кэш или глобальная проблема.
- Свяжитесь с тем, кто реально управляет зоной. Это может быть не разработчик сайта, а регистратор, DNS-провайдер, CDN или хостинг.
- После исправления дождитесь повторной проверки. Даже когда ошибка устранена, разные кэши и TTL могут еще некоторое время влиять на картину.
Практический сценарий
Допустим, сайт компании открывается у администратора, но жалобы уже пошли из рекламы и продаж. В такой ситуации полезно не спорить «у меня работает», а собрать короткий чек-лист:
- домен и поддомены;
- время начала проблемы;
- ответы разных резолверов;
- список последних изменений;
- контакт владельца DNS и регистратора.
С таким набором данных техподдержка или подрядчик быстрее переходят к исправлению, а не к долгому сбору вводных.
Чем опасен DNSSEC-сбой для бизнеса
Проблема редко ограничивается одной страницей. Если ломается разрешение имени, могут перестать открываться:
- основной сайт;
- checkout или личный кабинет на поддомене;
- формы заявок;
- почтовые сервисы, если затронуты связанные записи;
- API, на которые завязаны интеграции.
Особенно неприятно, что такой сбой выглядит "неровным". Кто-то видит сайт, кто-то нет. Из-за этого руководитель может решить, что инцидент несерьезный, и потерять время. На практике именно такие частичные отказы дольше всего диагностируются вручную.
Почему одной ручной проверки недостаточно
Если вы открыли сайт один раз из офиса и он загрузился, это еще не означает, что проблема закончилась. Ваш браузер мог взять данные из кэша, а резолвер провайдера мог еще не обновиться. Клиенты в другом регионе или с другим DNS уже видят другую картину.
Именно поэтому полезна регулярная внешняя проверка доступности, а не только ручное открытие главной страницы. Web-Puls помогает быстрее заметить, что сайт перестал открываться для пользователей, и не ждать первых жалоб от клиентов или отдела продаж.
Сначала можно проверить URL в форме ниже: это быстрый способ увидеть HTTP-ответ, время реакции и отделить проблему веб-сервера от ситуации, где запрос даже не доходит до сайта из-за DNS.
Если URL нужно поставить на регулярный контроль, добавьте его в мониторинг Web-Puls: сервис будет хранить историю HTTP-ответов, времени реакции и восстановления. Если DNSSEC-сбой уже влияет на заявки, рекламу или личный кабинет, передайте симптомы через форму оценки задачи: укажите домен, время начала, ответы резолверов и последние изменения в DNS.
Когда подключать поддержку
Если инцидент связан не только с наблюдением, но и с разбором DNS, регистратора, хостинга или серверных настроек, не меняйте DS, NS и ключи наугад. Соберите домен, время начала проблемы, ответы разных резолверов и список последних изменений.
После этого можно оставить заявку на профессиональную поддержку через форму Web-Puls или использовать контакты. Так специалисту проще сразу проверить цепочку DNSSEC, делегирование, хостинг и приложение, а не начинать с долгого сбора вводных.
Вывод
Сбой DNSSEC опасен тем, что маскируется под обычное "сайт упал", хотя сам веб-сервер может быть исправен. Майский инцидент с .de и последующие разборы DENIC и Cloudflare хорошо напомнили об этом: одна ошибка в цепочке доверия может сделать домен недоступным для большого числа пользователей.
Если сайт перестал открываться после изменений в DNS, у регистратора или у CDN, проверьте не только хостинг и код, но и DNSSEC-цепочку. Чем раньше вы отделите проблему разрешения имени от проблемы приложения, тем быстрее вернете сайт в работу без лишних действий и простоев.