Домен не работает, а хостинг жив: как записи DNS роняют сайт

Записи DNS роняют сайт тише и надёжнее, чем любой сбой хостинга: сервер жив, файлы на месте, база отвечает, а браузер упрямо пишет «Не удаётся получить доступ к сайту». Владелец звонит хостеру, хостер отвечает «у нас всё работает» — и формально он прав. Между вводом адреса в строку браузера и открытием страницы есть отдельный слой, за который хостинг не отвечает вообще: система доменных имён. Если сломалось там, сайт исчезает не для всех сразу и возвращается тоже не для всех сразу — часть посетителей и поисковых роботов сутками попадает в никуда, пока вы смотрите на работающую копию у себя в браузере. За двадцать лет практики (я в SEO с 2005 года) я видел, как из-за одной строчки в панели регистратора коммерческий сайт терял неделю показов и потом ещё месяц возвращал позиции. Ниже — как устроена эта цепочка, что ломается в каждой записи, как переехать на другой хостинг без простоя и что успеть сделать в первые часы. Если разбираться самому некогда, можно просто заказать SEO-продвижение сайта и передать технический контроль мне.

Что происходит между вводом адреса и открытием сайта

Компьютеры не умеют работать с буквами. Им нужен IP-адрес — набор цифр вроде 185.12.34.56. Доменное имя существует только для людей, и вся система DNS занимается одним: переводит имя в адрес. Проблема в том, что перевод делается не в одном месте, а по цепочке из четырёх звеньев, и любое из них может ответить неправильно или не ответить вовсе.

Когда посетитель вводит адрес, происходит следующее. Сначала браузер смотрит в собственный кэш и в файл hosts на компьютере. Не нашёл — обращается к резолверу: это DNS-сервер вашего интернет-провайдера или публичный сервис вроде 8.8.8.8. Резолвер, если у него нет свежего ответа в памяти, идёт к корневым серверам — их немного, они знают только одно: кто отвечает за зону .ru. Корневой сервер отправляет резолвер к серверам зоны верхнего уровня. Те смотрят в реестре домена и отвечают: за vashsite.ru отвечают NS-серверы вот с такими именами — обычно это серверы вашего регистратора или хостинга. И только на четвёртом шаге резолвер спрашивает у этих NS-серверов конкретную запись: какой IP у сайта, куда слать почту, какие есть подтверждения владения.

Важная деталь, которую почти никто не держит в голове: реестр домена хранит не IP сайта, а только имена NS-серверов. Сами записи A, MX, TXT лежат уже на этих NS-серверах. Отсюда два принципиально разных типа поломки. Первый — вы сменили NS-серверы (переехали на другой хостинг и указали его серверы имён), но на новых серверах зона ещё не заполнена: домен резолвится в пустоту. Второй — NS-серверы правильные, но внутри зоны кто-то стёр или исправил A-запись: домен резолвится, но не туда.

Отдельная категория — когда NS-серверы прописаны на поддоменах самого домена, например ns1.vashsite.ru. Тогда в реестре обязаны быть склеивающие записи (glue records) с IP этих серверов, иначе получается замкнутый круг: чтобы узнать адрес ns1, надо спросить у ns1. Такие конфигурации ломаются при смене IP сервера, если IP поменяли на хостинге, а в панели регистратора забыли.

TTL и кэш резолвера: почему правка «расходится» не мгновенно

Если бы каждый браузер каждый раз проходил всю цепочку от корневых серверов, интернет работал бы втрое медленнее. Поэтому у каждой записи DNS есть параметр TTL — время жизни в секундах. Он говорит резолверам: «запомни этот ответ и не переспрашивай столько-то времени». Типичные значения — 300 (пять минут), 3600 (час), 14400 (четыре часа), 86400 (сутки). Значение по умолчанию у большинства хостингов — час или четыре часа.

Практический вывод: когда вы меняете A-запись, старый IP продолжает жить в памяти резолверов ровно столько, сколько указано в TTL, и отсчёт у каждого резолвера свой — он начался в момент, когда этот конкретный резолвер последний раз спрашивал запись. Поэтому изменение «расходится» волной: у кого-то новый адрес появится через минуту, у кого-то — через четыре часа, а у абонента провайдера с агрессивным кэшированием и через сутки. Это и есть та самая ситуация, когда владелец говорит «у меня открывается», а половина клиентов видит старый сервер или ошибку.

Ещё коварнее отрицательное кэширование. Если резолвер спросил запись и получил ответ «такого имени нет» (NXDOMAIN), он тоже это запоминает — на время, заданное в SOA-записи зоны, обычно от 300 до 3600 секунд, но иногда и на сутки. Именно поэтому домен, который вы уже починили, может ещё несколько часов не открываться у тех, кто пытался зайти во время аварии. С точки зрения бизнеса это отдельная потеря: вы всё исправили, а заявки не идут.

Обновление NS-серверов в зоне верхнего уровня — самый долгий процесс из всех. Записи о делегировании обновляются по регламенту регистратуры и подхватываются мировыми резолверами обычно в пределах суток. Поэтому смену NS никогда не делают «на вечер пятницы»: если что-то пошло не так, откат тоже займёт сутки.

Полезно знать, как сбросить кэш локально, чтобы не путать свою машину с реальной картиной. На Windows — ipconfig /flushdns, на macOS — sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder, в Chrome дополнительно есть внутренняя страница chrome://net-internals/#dns с кнопкой очистки. Но помните: чистка кэша у себя не влияет ни на кэш провайдера, ни на кэш робота Яндекса.

Записи DNS: за что отвечает каждая и что ломается при ошибке

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

Запись	За что отвечает	Что ломается при ошибке	Как это выглядит для владельца
A	Связывает домен с IPv4-адресом сервера	Сайт не открывается или открывается чужой/старый сайт	«Не удаётся получить доступ», заглушка хостинга, чужая страница
AAAA	То же, но для IPv6	Часть посетителей с IPv6 уходит на мёртвый адрес, остальные заходят нормально	«У меня работает, а у клиента нет» — самый трудноуловимый случай
CNAME	Псевдоним: одно имя указывает на другое имя	Петля псевдонимов, конфликт с другими записями на том же имени	Поддомен не открывается, почта или SSL перестают работать
MX	Куда доставлять почту для домена	Письма с форм сайта и заявки не доходят, отправители получают отбойники	«Заявок нет вторую неделю» при живом сайте
TXT	Текстовые подтверждения: SPF, DKIM, DMARC, права на домен, проверка выпуска сертификата	Почта уходит в спам, не выпускается SSL, слетает подтверждение прав в сервисах	Письма в спаме, ошибка сертификата, отвалилась верификация
NS	Какие серверы имён обслуживают зону домена	Домен уходит на серверы с пустой зоной — не резолвится ничего	Полное исчезновение сайта и почты, откат занимает до суток
CAA	Разрешает выпуск сертификатов только указанным удостоверяющим центрам	Ваш центр не в списке — сертификат не выпускается и не продлевается	Через 90 дней сайт открывается с ошибкой безопасности
SOA	Служебные параметры зоны, в том числе время кэширования отрицательных ответов	Ошибки «домена нет» держатся дольше, чем нужно	Всё починили, а у части людей сайт ещё не работает
SRV	Адрес и порт служб — телефония, мессенджеры, корпоративные сервисы	Перестают подключаться сторонние сервисы	Не работает виджет звонка или корпоративная почта в клиенте

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

Сломанная MX — сайт работает, а заявки исчезли

Формы обратной связи на сайте почти всегда отправляют письмо на адрес в вашем же домене. Уход письма с сервера — это одна история, а вот доставка его в ваш ящик зависит от MX-записи. Убрали MX при переезде на новый хостинг, где почты нет, — и заявки перестали приходить, при этом сайт открывается, форма показывает «спасибо», статистика фиксирует отправку. Владелец видит трафик, видит цели в Метрике и не видит писем. Такая поломка живёт неделями, потому что никто не связывает молчание почты с переносом сайта. Проверять MX нужно каждый раз после любых работ с зоной, а дублировать заявки в CRM или в мессенджер — просто здоровая привычка.

Вторая половина почтовой темы живёт в TXT: SPF перечисляет серверы, которым разрешено отправлять письма от вашего домена, DKIM хранит открытый ключ подписи, DMARC говорит принимающей стороне, что делать с письмами, не прошедшими проверку. При переносе зоны на нового провайдера эти записи копируют не всегда, и письма с форм начинают массово падать в спам. Симптом тот же — «заявок стало меньше», а причина — три текстовые строчки.

SSL: почему сертификат перестал выпускаться

Бесплатные сертификаты Let’s Encrypt выдаются на 90 дней и продлеваются автоматически, но продление — это каждый раз новая проверка того, что домен ваш. Проверка идёт одним из двух способов. HTTP-проверка требует, чтобы A-запись домена указывала на тот самый сервер, где стоит сертификат, — если A-запись увела домен на другой IP, продление молча падает. DNS-проверка требует TXT-записи вида _acme-challenge в зоне — если зону перенесли и запись не воссоздали, продление тоже падает.

С CAA есть распространённое заблуждение, которое стоит развеять. Отсутствие CAA-записи ничего не ломает: если записи нет, сертификат может выпустить любой удостоверяющий центр. Ломает неверная CAA — когда запись есть, но в ней перечислен не тот центр, которым вы пользуетесь. Тогда выпуск блокируется на уровне правил, и никакие перезапуски скрипта не помогут, пока запись не поправят.

Опасность в отложенности: сертификат не перестаёт работать в день ошибки, он умирает через 90 дней после последнего успешного выпуска. То есть вы правили DNS в мае, а сайт встал с красным предупреждением браузера в августе, и связать одно с другим уже почти невозможно. Именно поэтому в мой бесплатный аудит сайта входит проверка срока действия сертификата и корректности цепочки — это одна из тех вещей, что убивает конверсию мгновенно и полностью.

Переезд на другой хостинг без простоя: по шагам

Классическая ошибка звучит так: «перенесли файлы, переключили домен, сайт лежал полдня». На самом деле переезд можно сделать так, что ни один посетитель не увидит ошибки, — потому что оба сервера какое-то время работают параллельно. Смысл в том, чтобы заранее сузить окно расхождения через TTL и не выключать старый сервер, пока по нему ещё идёт трафик. Подробности самого переноса файлов и базы я разбирал в материале про перенос сайта WordPress на другой хостинг без потери позиций; здесь — только та часть, что касается DNS.

Шаг	Когда	Что делаете	Зачем именно так
1. Понизить TTL	За 2–3 суток до переезда	Ставите TTL на A и AAAA равным 300 секунд	Чтобы к моменту переключения все резолверы уже перешли на короткий кэш и подхватили новый IP за минуты
2. Снять слепок зоны	Тогда же	Сохраняете скриншот и текстовый экспорт всех записей	Единственный способ откатиться, если новая панель потеряет часть записей
3. Поднять копию	За сутки	Разворачиваете сайт на новом сервере, открываете его по временному адресу или через файл hosts	Проверяете работоспособность до переключения, а не после
4. Заморозить контент	За несколько часов	Не публикуете записи, не принимаете заказы на старом сайте	Иначе часть данных останется на старом сервере и потеряется
5. Синхронизировать базу	Непосредственно перед	Переносите свежий дамп базы и загруженные файлы	Чтобы новый сервер стартовал с актуальными данными
6. Переключить A-запись	Час X, утро буднего дня	Меняете IP в A-записи, MX и TXT не трогаете, если почта осталась на месте	Смена A безопаснее смены NS: откат занимает минуты, а не сутки
7. Дождаться расхождения	2–24 часа	Смотрите логи обоих серверов: трафик на старом должен упасть почти до нуля	Логи — единственный честный индикатор того, что переход завершён
8. Погасить старый сервер	Через 3–7 суток	Только после этого отключаете старый хостинг	Задержавшиеся резолверы и роботы могут ходить туда ещё несколько дней
9. Вернуть TTL	После стабилизации	Поднимаете TTL обратно до 3600–14400	Короткий TTL постоянно грузит DNS лишними запросами и чуть замедляет отклик

Три правила, которые я соблюдаю всегда. Первое: менять A-запись, а не NS-серверы, если есть такая возможность — при смене NS вы перевозите всю зону целиком и рискуете потерять почтовые записи. Второе: переключаться утром вторника или среды, чтобы у вас был полный рабочий день на откат и сутки в запасе. Третье: старый сервер не выключать, а оставить рабочим с тем же контентом — тогда даже те, кто пришёл по старому кэшу, увидят нормальный сайт, а не ошибку. Отслеживать хвост трафика на старом сервере удобно по логам сервера: там видно и живых людей, и роботов, которые ещё не узнали о переезде.

Отдельно про DNSSEC. Если у домена включена криптографическая подпись зоны, а вы меняете NS-серверы, подписи перестают сходиться — и резолверы с проверкой DNSSEC начинают отдавать ошибку вместо адреса. Причём именно ошибку, а не «нет записи»: сайт исчезает жёстко. Перед сменой NS DNSSEC отключают, ждут распространения и включают заново уже на новой стороне.

Что видит робот Яндекса, когда домен не резолвится

Здесь ключевая мысль, ради которой стоило читать всё предыдущее: неотвечающий DNS опаснее упавшего сервера, хотя со стороны кажется, что разницы нет.

Когда сервер лежит, но домен резолвится, робот получает код ответа — 500, 502, 503. Это внятный сигнал «сайт временно недоступен, приходи позже». Поисковая система понимает его как временную проблему: страницы остаются в индексе, обход возобновляется, позиции держатся. Разницу между аварией хостинга и ошибкой в коде я разбирал в статье про ошибку 500 на WordPress — там как раз про то, что 5xx это ещё не катастрофа.

Когда домен не резолвится, кода ответа нет вообще. Робот не может установить соединение, потому что не знает, куда стучаться. Для него это не «сайт лежит», а «сайта нет». Дальше включается цепочка последствий. Робот не может скачать robots.txt — а без доступного robots.txt Яндекс откладывает обход целиком, потому что не знает, что ему разрешено. Не может проверить ни одну страницу — и при длительной недоступности начинает исключать их из индекса с пометкой о невозможности подключения. В Вебмастере это выпадает в «Диагностике» как критичная ошибка недоступности сайта или ошибка DNS, и туда же приходит уведомление на почту — если, конечно, почта домена не легла вместе с ним, что при поломке зоны бывает регулярно.

Восстановление после такого выпадения несимметрично падению. Домен вы почините за час, а вот возврат страниц в индекс — это несколько обходов робота, то есть от нескольких дней до нескольких недель на среднем коммерческом сайте. Про механику выпадения и возврата страниц я подробно писал в материале о том, почему Яндекс перестал индексировать новые страницы. Отсюда практическое правило: любая недоступность домена дольше нескольких часов требует после починки не только выдоха, но и переобхода — отправьте главные страницы в «Переобходе страниц» Вебмастера, чтобы робот пришёл не через неделю, а завтра.

Ещё одна деталь, о которой забывают: пока домен не резолвится, не работают и все сервисы, привязанные к нему через DNS. Метрика перестаёт собирать данные, потому что счётчику некуда грузиться, — и в отчётах остаётся провал, который потом искажает всю годовую динамику. Отчёты о позициях за этот период тоже становятся мусорными: съём показывает не ваши позиции, а факт недоступности.

Диагностика: nslookup, dig и проверка через сторонние DNS

Первое, что нужно сделать при подозрении на DNS, — перестать доверять собственному браузеру. «У меня открывается» не значит ничего: у вас может быть свежий кэш, старый кэш, запись в hosts, VPN или другой провайдер. Нужна проверка с нескольких независимых точек.

Что проверяем	Команда или инструмент	Что означает результат
Резолвится ли домен вообще	nslookup vashsite.ru	Пустой ответ или NXDOMAIN — проблема в делегировании или домен не продлён
Ответ независимого резолвера Google	nslookup vashsite.ru 8.8.8.8	Здесь есть, а у провайдера нет — значит, дело в кэше провайдера, надо просто ждать
Ответ резолвера Яндекса	nslookup vashsite.ru 77.88.8.8	Ближе всего к тому, что видят российские пользователи и робот Яндекса
Текущий IP коротко	dig vashsite.ru A +short	Одна строчка с адресом — сверяете с IP, который выдал хостинг
Кто обслуживает зону	dig vashsite.ru NS +short	Если тут не те серверы, что в панели регистратора, — зона переехала, а вы правите не ту панель
Вся цепочка от корня	dig +trace vashsite.ru	Видно, на каком именно звене цепочка обрывается
Почтовые записи	dig vashsite.ru MX +short и dig vashsite.ru TXT +short	Пусто в MX — заявки с форм не дойдут; пусто в TXT — проблемы со спамом и SSL
Ограничения на сертификаты	dig vashsite.ru CAA +short	Запись есть и центр в ней не ваш — сертификат не продлится
Оставшийся TTL в кэше	dig vashsite.ru A — колонка перед типом записи	Столько секунд ещё будет отдаваться старый ответ
Дата окончания домена	whois vashsite.ru, поле paid-till или Expiry Date	Дата в прошлом — причина найдена, дальше только к регистратору
Расхождение по миру	Онлайн-сервисы проверки распространения записей: dnschecker.org, whatsmydns.net, 2ip.ru	Карта с точками показывает, в каких регионах уже новый IP, а где ещё старый

Практическая логика чтения результатов. Если публичные резолверы отдают правильный IP, а у части посетителей сайт не открывается — паниковать не нужно, это кэш, он рассосётся за время TTL. Если публичные резолверы отдают старый IP — значит, ваша правка не сохранилась или вы правите зону не на тех NS-серверах. Если публичные резолверы вообще ничего не отдают, а whois показывает нормальную дату окончания — смотрите делегирование: скорее всего, NS-серверы указывают на площадку, где зоны нет. И если whois показывает дату в прошлом, дальше диагностировать нечего.

Полезная привычка — держать текущий IP сайта записанным. Если вы не помните, куда должен указывать домен, любая проверка становится бессмысленной: вы видите адрес и не понимаете, правильный он или чужой. Как посмотреть и зафиксировать это заранее, я показывал в заметках про то, как проверить IP сайта и как узнать хостинг сайта по домену.

Домен не продлили: льготный период, redemption и цена ошибки

Самая обидная причина суточного простоя — забытое продление. Обидная, потому что предотвращается одной галочкой, а стоит иногда дороже годового хостинга. Механика после даты окончания различается у российских и международных зон, и путать их нельзя.

Стадия	Зоны .RU и .РФ	Международные зоны (.COM, .NET, .ORG)	Что видит посетитель
Дата окончания	Делегирование снимается практически сразу	Обычно включается автопродление регистратора, домен ещё работает	В .RU сайт исчезает в тот же день
Льготный период	30 дней преимущественного права продления для текущего администратора	Auto-Renew Grace Period, около 30 дней, продление по обычной цене	Сайт не открывается, почта не ходит
Период выкупа	Отдельной стадии нет, после 30 дней домен освобождается	Redemption Period, около 30 дней, восстановление с повышенной платой	Домен занят, но недоступен никому
Удаление	Освобождение, часто через аукцион регистратора	Pending Delete, около 5 дней, затем свободная регистрация	Домен может купить кто угодно, включая конкурента

Ключевое различие: в .ru сайт падает в день окончания, без всякой отсрочки. В международных зонах у вас чаще всего есть несколько дней запаса за счёт автопродления регистратора, но полагаться на это нельзя — политика у регистраторов разная. Восстановление на стадии redemption всегда стоит в разы дороже обычного продления: это отдельная услуга реестра, и цена там измеряется тысячами рублей вместо сотен. Точные суммы смотрите в тарифах своего регистратора, они меняются.

Что делать, чтобы этого не случилось. Включить автопродление и, что важнее, привязать к нему рабочую карту с достаточным балансом — автопродление с истёкшей картой не работает и уведомляет вас письмом, которое уходит на почту в том же домене. Убедиться, что контактный e-mail в панели регистратора — не корпоративный ящик на этом же домене: когда домен упадёт, письмо о падении вы не получите. Продлевать не на год, а сразу на два-три: домен дешевле любого простоя. И проверять, что домен зарегистрирован на вас или на вашу компанию, а не на подрядчика, который делал сайт пять лет назад и с тех пор пропал — это, пожалуй, самая частая мина в моей практике. Похожая история с оплатой инфраструктуры описана в заметке о том, как просроченная оплата хостинга обрушила позиции сайта.

Когда дело не в DNS: как быстро отсечь эту версию

Прежде чем ломать зону догадками, стоит потратить пять минут и убедиться, что проблема вообще там. Правило простое: если nslookup отдаёт правильный IP, DNS свою работу сделал, и дальше копать надо в другом месте. Ниже — типичные ситуации, которые выглядят как DNS, но ею не являются.

Симптом	Похоже на DNS, но на самом деле	Быстрая проверка
Сайт не грузится, IP резолвится верно	Сервер не отвечает или упёрся в лимиты	ping и curl -I по домену: есть ли вообще ответ и какой код
Белый экран или ошибка 500	Плагин, тема или PHP на стороне сайта	Смотрите лог ошибок хостинга, отключайте последние изменения
Сайт открывается медленно, но открывается	Медленный сервер или тяжёлые запросы к базе	Замер времени до первого байта, а не глазами
Открывается только у вас	Запись в файле hosts, оставшаяся после переезда	Откройте файл hosts и уберите строчку с доменом
Не открывается только у вас	Ваш IP забанен фаерволом хостинга после неудачных входов	Проверьте с мобильного интернета или через VPN
Сайт пропал из выдачи, но открывается	Запрет в robots.txt, метатег noindex или фильтр	Проверка страницы в Вебмастере, а не в браузере
Открывается заглушка «сайт припаркован»	DNS в порядке, но хостинг заблокировал аккаунт за неоплату	Личный кабинет хостинга и почта от него
Ошибка сертификата у всех	Сертификат истёк или отдаётся неполная цепочка	Онлайн-проверка SSL, срок и промежуточные сертификаты
Часть страниц 404 после переноса	Не перенеслись правила редиректов, а не зона	Файл .htaccess или конфиг nginx на новом сервере

Отдельно упомяну ситуацию, когда сайт вроде бы работает, но отдаёт данные подозрительно долго и нестабильно. Это не DNS: время резолва измеряется десятками миллисекунд и в общем времени загрузки почти не заметно. Разбирать надо серверную часть — как именно, я показывал в статье о том, куда исчезает секунда до первого байта. Ускорить DNS-ответ можно, но выигрыш там измеряется миллисекундами и почти никогда не является решением проблемы скорости.

Коротко

• DNS — отдельный слой между доменом и хостингом. Хостинг может быть прав, когда говорит «у нас всё работает».
• Реестр домена хранит только NS-серверы. Сами A, MX, TXT лежат на этих серверах, и править их надо там, куда домен реально делегирован.
• TTL определяет, сколько резолверы помнят старый ответ. Поэтому правка расходится волной от минут до суток, и «у меня открывается» ничего не доказывает.
• Отрицательное кэширование держит ошибку «домена нет» ещё несколько часов после починки — заявок не будет даже тогда, когда всё уже исправлено.
• Сломанная MX убивает заявки с форм при полностью живом сайте. Неверная CAA или потерянная TXT-запись убивают автопродление SSL — но не сразу, а через 90 дней.
• Переезд без простоя: понизить TTL за 2–3 дня, поднять и проверить копию, переключить A-запись утром буднего дня, дождаться падения трафика на старом сервере по логам, погасить его через несколько суток.
• Для робота нерезолвящийся домен хуже 500-й ошибки: кода ответа нет вообще, robots.txt недоступен, обход останавливается, страницы начинают выпадать из индекса.
• Диагностика занимает пять минут: nslookup через 8.8.8.8 и 77.88.8.8, dig +trace, whois на дату окончания, онлайн-карта распространения записей.
• В зоне .ru сайт падает в день окончания регистрации. Автопродление плюс живая карта плюс контактный e-mail на чужом домене — три обязательные настройки.

Чеклист владельца: что проверить в панели регистратора раз в год

Этот список я прохожу по всем проектам, которые веду, — он занимает минут двадцать и снимает почти все сценарии внезапного исчезновения сайта.

Что проверить	Где смотреть	Норма
Владелец домена	Карточка домена у регистратора	Вы или ваша компания, не подрядчик и не бывший сотрудник
Доступ в личный кабинет	Вход по логину и паролю	Вы можете войти сами, без звонка кому-либо
Дата окончания	Карточка домена или whois	Больше полугода в запасе
Автопродление	Настройки домена	Включено, привязана действующая карта
Контактный e-mail	Профиль регистратора	Почта на стороннем домене, не на этом же
Телефон для восстановления	Профиль регистратора	Ваш действующий номер, не подрядчика
NS-серверы	Делегирование домена	Совпадают с тем, где вы реально правите зону
A и AAAA	Редактор зоны	Указывают на текущий сервер; лишнюю AAAA лучше убрать, чем оставить мёртвой
MX и почтовые TXT	Редактор зоны	MX на месте, SPF и DKIM не потерялись при последнем переносе
CAA	Редактор зоны	Либо записи нет, либо в ней указан ваш удостоверяющий центр
Срок SSL-сертификата	Панель хостинга или браузер	Продлевается автоматически, до окончания больше 30 дней
Резервная копия зоны	Ваш архив	Экспорт или скриншот всех записей лежит там, где вы его найдёте
Мониторинг доступности	Внешний сервис	Проверка домена раз в 1–5 минут, уведомление в мессенджер, а не на почту домена

Последний пункт стоит отдельно. Владелец узнаёт о падении сайта в среднем через несколько часов — от клиента, который не смог оформить заказ. Внешний мониторинг сокращает это до минут и, что важно, отличает недоступность DNS от недоступности сервера уже в тексте уведомления. Как выстроить такой контроль без лишних сервисов, я описывал в заметке про контроль работы хостинга.

Если сайт лежит прямо сейчас и разбираться некогда — не тратьте часы на угадывание. Соберите три факта: что отдаёт nslookup через 8.8.8.8, что показывает whois в поле с датой окончания и что говорит панель хостинга о статусе аккаунта. Этого почти всегда хватает, чтобы понять, чья зона ответственности. А если факты противоречат друг другу, напишите мне через форму обратной связи — посмотреть делегирование и зону быстрее, чем описывать проблему словами.