Если сайт перестал открываться, первая мысль обычно одна: упал хостинг или сломался сервер. Но на практике часть аварий начинается выше по цепочке: у регистратора, у DNS-провайдера, на уровне доменной зоны или при ошибке в DNSSEC. В таком сценарии сам сайт может продолжать работать, база данных может быть в порядке, а пользователи все равно будут видеть недоступность.
В июне 2026 года DENIC опубликовал финальный отчет о крупном майском сбое в зоне .de, а до этого выпустил первичный разбор. Отдельно Cloudflare описал, как на инцидент реагировали валидирующие резолверы. Для владельца сайта это полезный сигнал: иногда проблема находится не в коде, не в CMS и не в сервере, а в доменной инфраструктуре, от которой зависит открытие сайта у клиентов.
Что показал сбой в доменной зоне
История с .de важна не потому, что большинству российских сайтов нужна именно эта зона. Она важна как модель аварии. Во время штатного процесса, связанного с DNSSEC, в зоне появились некорректные подписи. В результате валидирующие резолверы начали отклонять ответы, а пользователи получали недоступность, хотя сами сайты как таковые не обязательно были сломаны.
Для бизнеса это означает простую вещь: если доменное имя перестало корректно разрешаться, посетитель не дойдет до сайта, даже если сервер отвечает, панель хостинга работает, а разработчик не видит ошибок в приложении. Поэтому проверка только хостинга или только логов веб-сервера не всегда дает правильный ответ.
Как понять, что проблема может быть у регистратора, DNS или в доменной зоне
Есть несколько признаков, которые заставляют смотреть именно в сторону доменной инфраструктуры.
Признаки со стороны посетителей
- сайт то открывается, то не открывается;
- у одних пользователей страница доступна, у других нет;
- в одном регионе сайт работает, а в другом не работает;
- браузер показывает ошибку слишком рано, как будто не может найти или проверить адрес сайта;
- почта на домене тоже начинает работать нестабильно.
Признаки со стороны владельца сайта
- сервер доступен по IP или по техническому адресу, но основной домен не открывается;
- в панели хостинга нет аварии, а жалобы от клиентов уже есть;
- мониторинг сервера выглядит нормальным, но доступность домена проседает;
- DNS-ответы отличаются в зависимости от резолвера;
- проверка DNSSEC, NS или делегирования показывает ошибки.
Отдельно стоит насторожиться, если одновременно возникают проблемы не только у сайта, но и у формы обратной связи, почты на домене, поддоменов и API на том же доменном имени. Это часто указывает не на поломку одного приложения, а на проблему уровнем выше.
Что проверить вручную в первые 10-15 минут
Ниже последовательность, которая помогает быстро сузить круг причин.
- Сравните доступность сайта из нескольких сетей и через несколько DNS-резолверов. Если у вас сайт открывается, а у клиента нет, это еще не значит, что проблемы нет. Часть резолверов может отвечать из кэша, а часть уже возвращает ошибку.
- Проверьте, открывается ли сайт по IP или по техническому имени, если такой адрес у вас есть. Если origin жив, а домен не резолвится, это сильный аргумент в пользу DNS-проблемы.
- Посмотрите NS-записи, DS-записи и актуальность делегирования. Если используется DNSSEC, проверьте, нет ли сбоев в цепочке доверия.
- Сверьтесь со статусом регистратора, DNS-провайдера, CDN и реестра доменной зоны, если они публикуют уведомления об инцидентах.
- Сопоставьте логи приложения и веб-сервера с реальным временем жалоб. Если в логах нет всплеска ошибок, а пользователи уже не могут открыть сайт, причина может быть до входа трафика на сервер.
Практический пример: интернет-магазин жалуется, что карточки товара недоступны, но разработчик видит главную страницу и считает, что все в порядке. При проверке выясняется, что сайт открывается только у части пользователей, а у другой части домен не проходит нормальное разрешение. В такой ситуации бессмысленно начинать с очистки кэша CMS или перезапуска PHP-FPM. Сначала нужно исключить DNS и делегирование.
Еще один пример: корпоративный сайт открывается по IP, а домен нет. Хостинг не сообщает об аварии, база отвечает, админ-панель доступна по внутреннему адресу. Это уже не похоже на типичную ошибку 500 или 503. Здесь нужно идти в проверку DNS-записей, NS, DNSSEC и статуса регистратора.
Почему ручной проверки часто недостаточно
Во время DNS-инцидентов ситуация может быть неравномерной. Один резолвер продолжает отдавать старые данные из кэша, другой уже возвращает ошибку. Один сотрудник пишет, что сайт работает, другой показывает скриншот недоступности. Из-за этого команда тратит время на спор о симптомах вместо диагностики.
Именно поэтому полезно сочетать ручную проверку с внешним мониторингом. Он помогает увидеть момент начала сбоя, частоту ошибок, повторяемость проблемы и историю восстановления. Если домен недоступен только части аудитории или проблема плавающая, такие данные особенно важны.
Для ручной диагностики также полезно держать под рукой базовые материалы: DNS SERVFAIL: почему сайт не открывается и что проверить, Сайт открывается по IP, но не по домену: что проверить и Как понять, что сайт действительно упал.
Что особенно важно контролировать на проектах с DNSSEC
DNSSEC повышает доверие к DNS-ответам, но делает инфраструктуру чувствительнее к ошибкам в подписи, ключах и делегировании. Это не аргумент против DNSSEC. Это аргумент в пользу аккуратной эксплуатации.
Владельцу сайта стоит заранее понимать:
- кто управляет DNS-зоной и кто отвечает за изменения;
- где включен DNSSEC и кто контролирует его продление или ротацию;
- есть ли у команды понятный порядок действий на случай массового SERVFAIL;
- можно ли быстро проверить сайт извне, а не только из офиса или через VPN;
- кто принимает решение, если нужно срочно эскалировать вопрос к регистратору или DNS-провайдеру.
Если эти пункты не проговорены заранее, даже короткий сбой может растянуться просто из-за долгих согласований.
Как Web-Puls помогает заметить такую проблему быстрее
Когда проблема находится не внутри сайта, а на уровне DNS или доступности домена, особенно полезны внешние проверки из независимой точки. Web-Puls помогает регулярно проверять доступность сайта и быстрее узнавать, если он перестал открываться. Это снижает риск ситуации, когда команда узнает о сбое только после жалоб клиентов или проваленной рекламной кампании.
На практике полезно смотреть не на одну проверку, а на связку сигналов: доступность сайта, поведение SSL, история ошибок и время начала инцидента. Тогда проще отличить локальную жалобу от системной проблемы.
Когда лучше сразу обращаться за поддержкой
Если вы видите признаки сбоя у регистратора, DNS-провайдера, в DNSSEC, делегировании или доменной зоне, важно не затягивать с эскалацией. Особенно если сайт приносит заявки, продажи или обращения в поддержку прямо сейчас.
В такой ситуации можно собрать минимум фактов: когда началась проблема, у кого именно сайт не открывается, какие проверки уже выполнены, открывается ли origin по IP, есть ли ошибки вида SERVFAIL и затронута ли почта на домене. После этого проще передать задачу специалистам без лишней переписки.
Если проблему нужно не только заметить, но и разобрать технически, можно отправить заявку на профессиональную поддержку через форму Web-Puls: https://web-puls.ru/support/. Если удобнее связаться напрямую, используйте контакты: https://web-puls.ru/contacts/.
Вывод
Не каждая недоступность сайта означает падение хостинга. Иногда сайт остается рабочим, а ломается путь к нему: делегирование, DNS, DNSSEC или инфраструктура регистратора. Именно такие аварии особенно опасны, потому что они сбивают с толку и владельца, и подрядчика.
Хорошая практика здесь простая: не ограничиваться проверкой из одного браузера, уметь быстро отделять проблему домена от проблемы сервера и иметь под рукой внешний мониторинг. Тогда даже сложный DNS-инцидент не превращается в долгий поиск виноватого.